A concepção da dimensão data num sistema de BI ? Parte I

A dimensão mais comum e mais utilizada em praticamente todos os sistemas de Business Intelligence (BI) é a dimensão data ou DimData. São várias as propostas de implementação relativas a esta dimensão, mas normalmente desactualizadas, complexas ou algumas apesar de interessantes, aplicam-se apenas a contextos específicos sem um enquadramento face a um sistema de BI.

Este artigo tem como objectivo explicar de forma clara e objectiva a criação da dimensão data ou tempo num sistema de BI. É uma dimensão/perspectiva de análise utilizada em praticamente todos os modelos dimensionais e muitas vezes ?reciclada? numa mesma base de dados. Ou seja, fisicamente é criada apenas uma única tabela, mas em termos lógicos pode existir mais que uma, como por exemplo a data de uma venda, data de uma entrega de encomenda, data de contratação, entre outras normalmente conhecidas como role-play dimensions

A estrutura de uma dimensão data é caracterizada na grande maioria dos casos por uma única tabela desnormalizada que apesar da consequente redundância, permite uma maior intuição e melhor performance nas consultas realizadas pelo utilizado final.


Figura 01. Estrutura de dimensão data proposta


Neste artigo, a dimensão data inclui os atributos normalmente mais utilizados como ano, trimestre, mês, semana e dia, para além de duas hierarquias CalendarioPorMes e CalendarioPorSemana. Este exemplo poderá ser a base para mais complexas implementações como inclusão do ano fiscal, atributos como feriados, nome dias da semana (terça-feira, domingo?) ou ainda outras especificações dependendo naturalmente dos requisitos necessários de cada sistema.

É boa prática na modelação dimensional recorrer-se a criação de chaves substitutas nas dimensões/perspectivas de análise, contudo a sua implementação não é obrigatória, excepto no caso de aplicação da técnica apresentada por Ralph Kimball para dimensões de variação lenta tipo 2: SCD2. Esta chave substituta para a dimensão data é também conhecida por ser uma chave substituta smartkey, onde o seu valor possui informação (dados com contexto), ou seja, através por exemplo do número inteiro 20091203, rapidamente percebemos que esta chave corresponde a um registo correspondente da data de 3 de Dezembro de 2009. Caso fosse um inteiro Identity sequencial (normalmente utilizado em restantes chaves substitutas de outras dimensões) na visualização da tabela de factos, seria necessário realizar sempre uma junção (join) com a dimensão data para ter a correspondência entre esse número inteiro Identity sequencial (ex:4890) e a data correspondente.

Apesar de terem existido várias abordagens relativamente à chave da dimensão data, o uso desta smartkey é hoje em dia praticamente unânime sendo as suas vantagens reais principalmente na:

1. 1. Contextualização de cada registo na tabela de factos
   2. Na redução de risco na passagem entre ambientes (desenvolvimento/qualidade/produção), evitando a existência de chaves diferentes para uma mesma data.
   3. Para processamento das partições do cubo multidimensional na base dados OLAP
   4. Aplicação das técnicas de data mining através de ferramentas Microsoft onde é sugerido o formato YYYYMMDD.

A figura seguinte representa a estrutura de dados normalizada aplicada neste artigo para a dimensão data. Através desta estrutura será mais fácil compreender as duas hierarquias existentes, bem como compreender as chaves únicas que devem estar associadas a cada nível de uma hierarquia de modo a garantir a relação de um-para-muitos existente em qualquer hierarquia.



Figura 02. Exemplo de uma estrutura de dados normalizada para a dimensão data


No final, a dimensão data terá então uma estrutura desnormalizada, onde as hierarquias assumem um papel fundamental, permitindo o drill-down e o roll-up sobre a informação armazenada na tabela de factos.



Figura 03. Exemplo de uma estrutura de dados desnormalizada para a dimensão data


Naturalmente que os campos chaves que permitem criar as hierarquias, podem ser escondidos do utilizador final, que apenas tem interesse pelos descritivos como a data, a semana, mês, trimestre e ano. Estes descritivos poderão inclusivamente ser alterados face ao proposto neste artigo, tendo apenas em atenção a actualização do seu comprimento em caso de alteração. (Ex: ?T1? para ?2009 T1? ou ?Janeiro? para ?Janeiro 09??)

O processo de povoamento de um Data Warehouse refere-se a todo o trabalho realizado na extracção, transformação e carregamento dos dados operacionais num repositório central normalmente designado por Data Warehouse ou Data Mart no caso de um âmbito mais reduzido. Este processo de povoamento é normalmente caracterizado por dois tipos de povoamento: o povoamento inicial, onde é preparado todo o sistema com o carregamento inicial de todas as estruturas de dados do Data Warehouse, e o povoamento regular ou periódico, onde é realizado periodicamente a actualização da informação armazenada no Data Warehouse (dependendo dos requisitos do negócio, poderá ser necessária uma actualização de hora em hora, diária, semanal, mensal, entre outros?)

Relativamente à dimensão data, será descrita de seguida uma abordagem possível para o processo de povoamento da mesma. Naturalmente algum ajustamento poderá ser equacionado, não só para reflectir os requisitos de negócio, como também para reflectir a arquitectura técnica que irá suportar o sistema de Business Intelligence a implementar.

Este processo de povoamento requer praticamente em todos os casos, de uma área de retenção (Staging Area) que poderá ser uma área em memória ou uma área física como abordada neste artigo. No caso de optar por não utilizar esta memoria fisica, poderá alojar a tabela ?preDimData? directamente no Data Mart criado neste artigo. A inclusão ou não de uma base de dados para suporte ao processo de povoamento, requer uma análise de custo-beneficio, pois a sua manutenção implica custos que poderão ser justificados pelo volume/complexidade de cada sistema a implementar.

Esta abordagem caracteriza-se numa primeira fase pelo carregamento inicial das datas a considerar no sistema, e depois uma segunda fase de actualização periódica com a inserção das últimas datas em falta no período. A figura 04 descreve de uma forma mais clara a abordagem seguida:


Figura 04. Arquitectura proposta para a dimensão data

Esta abordagem considera a existência de uma área de apoio ao ETL (Data Staging Area), caso contrário a tabela ?preDimData? poderia estar alojada directamente no Data Mart.

No passo 01 (através do script 01.Criação Tabela preDimData.sql), é criada fisicamente a tabela ?preDimData?, onde todas as suas colunas são calculadas automaticamente através de computed columns, excepto a coluna data que é a base de cálculo das anteriores. No passo 02 (através do script 02.Carregamento Inicial Tabela preDimData.sql) é realizado o carregamento desta mesma tabela, que poderá inclusivamente carregar datas de próximos anos no caso de não pretender actualizar periodicamente a dimensão data com as datas em falta no período. No passo 03 (através do script 03.Criar DimData.sql) é criada fisicamente a tabela DimData no Data Mart.

Se optar pela actualização periódica desta dimensão, poderá faze-lo automáticamente através da stored procedure do passo 4 descrito na figura 04. Depois de actualizada a tabela ?preDimData? será necessário reflectir a actualização também na tabela DimData existente no Data Mart em estudo. Uma possibilidade será pela criação de um simples lookup, ou por algo mais elaborado recorrendo à de Change Data Capture que automáticamente recolhe as alterações ocorridas desde a ultima actualização.

Caso pretenda criar e carregar uma única vez a dimensão data com todos os anos actuais e futuros (sem necessidade de actualização periodica) poderá ficar apenas pelos passos 01 e 02. (renomeando naturalmente a tabela de preDimData para um nome mais elucidativo como DimData)

Pretendeu-se com este artigo exemplificar a concepção da dimensão data e o seu enquadramento num sistema de BI. O objectivo foi simplificar e contribuir com uma base de ?trabalho? para futuras implementações que deverão adaptadas à realidade de cada projecto. Como terá reparado, várias possibilidades poderão ser agora seguidas com base neste artigo.

Na segunda parte deste artigo será descrita a implementação desta dimensão numa base de dados OLAP através dpo SQL Analysis Services (SSAS).

Scripts de SQL

01.Criação Tabela preDimData.sql

02.Carregamento Inicial Tabela preDimData.sql

03.Criar DimData.sql

04.Carregamento Periodico Tabela preDimData.sql

Reduzir esta imagemExpandir esta imagem

RENUNCIA LEGAL DE SOLUCIONES DE LA COMUNIDAD
NI MICROSOFT IBÉRICA S.R.L. ("MICROSOFT") NI SUS RESPECTIVOS PROVEEDORES GARANTIZAN LA IDONEIDAD, FIABILIDAD NI EXACTITUD DE LA INFORMACIÓN Y LOS GRÁFICOS INCLUIDOS. TODA LA INFORMACIÓN Y LOS GRÁFICOS RELACIONADOS SE PROPORCIONAN "TAL CUAL" SIN GARANTÍA DE NINGUNA CLASE. SIN PERJUICIO DE NINGUNA GARANTÍA IMPUESTA POR CUALQUIER LEY DE APLICACIÓN OBLIGADA, MICROSOFT Y/O SUS RESPECTIVOS PROVEEDORES RENUNCIAN POR LA PRESENTE A TODA GARANTÍA Y CONDICIÓN RESPECTO A ESTA INFORMACIÓN Y LOS GRÁFICOS RELACIONADOS, INCLUIDA CUALQUIER GARANTÍA Y CONDICIÓN IMPLÍCITA DE COMERCIABILIDAD, IDONEIDAD PARA UN DETERMINADO FIN, ESFUERZO RAZONABLE, TITULARIDAD Y AUSENCIA DE INFRACCIÓN. USTED ADMITE EXPRESAMENTE QUE, SIN PERJUICIO DE LOS CASOS EN LOS CUALES LA LEY VIGENTE PROHÍBA LA EXCLUSIÓN DE RESPONSABILIDAD POR DAÑOS, BAJO NINGÚN CONCEPTO, NI MICROSOFT NI SUS PROVEEDORES ACEPTARÁN RESPONSABILIDAD ALGUNA POR DAÑOS DIRECTOS O INDIRECTOS DE CUALQUIER ÍNDOLE U ORIGEN (INCLUYENDO, ENTRE OTROS, LOS DAÑOS POR PÉRDIDA DE USO, INFORMACIÓN O BENEFICIOS) QUE SE DERIVEN O ESTÉN RELACIONADOS CON EL USO O INCAPACIDAD DE USO DE LA INFORMACIÓN Y LOS GRÁFICOS RELACIONADOS INCLUIDOS.

Nota Este é um artigo de ?PUBLICAÇÃO RÁPIDA? criado directamente a partir da organização de suporte da Microsoft. As informações contidas neste artigo são fornecidas ?tal como estão? em resposta a problemas recentes. Devido à urgência em disponibilizar este artigo, os materiais poderão incluir erros tipográficos e ser revistos em qualquer altura sem aviso prévio. Consulte os Termos de Utilização (http://go.microsoft.com/fwlink/?LinkId=151500) para outras considerações.