Kimball University: As 10 Regras Essenciais para a Modelagem de Dados Dimensional

Margy Ross Presidente Kimball Group Maio de 2009, Intelligent Enterprise.com Traduo livre para a lngua portuguesa por BI Experts Um estudante participando de uma aula recente de modelagem dimensional do Kimball Group perguntou-me se existia uma lista de recomendaes Kimball para a modelagem dimensional. Abstendo-se de utilizar uma terminologia religiosa, podemos dizer que as regras a seguir no devem ser quebradas e tambm existem algumas regras de ouro no to severas a serem seguidas. Regra #1: Carregue dados detalhados para as estruturas dimensionais. Modelos dimensionais devem ser populados com um alicerce de dados detalhados para suportar os requisitos imprevisveis de filtragem e agrupamento necessrias para atender as consultas dos usurios de negcios. Usurios normalmente no precisam visualizar um registro por vez, mas impossvel prever em quais diferentes maneiras eles pretendem ver os dados e acessar os detalhes. Se apenas dados agregados estiverem disponveis, ento voc j deve ter se deparado com padres de utilizao dos dados que levaram os usurios a chegar a uma barreira intransponvel quando eles querem acessar os detalhes. claro, dados detalhados pdem ser complementados por modelos dimensionais agregados que trazem vantagens de desempenho para consultas frequentes de dados sumarizados, mas os usurios de negcios no conseguem viver apenas dos dados agregados; eles precisam dos detalhes sangrentos para responder seus diferentes questionamentos. Regra #2: Estruture os modelos dimensionais em torno dos processos de negcios. Os processos de negcios so as atividades desenvolvidas por sua empresa; elas representam eventos mensurveis, como registrar um pedido ou emitir uma fatura

para um consumidor. Processos de negcios normalmente capturam ou geram mtricas nicas de desempenho associadas a cada evento. Estas mtricas traduzidas em fatos, com cada processo de negcios representado por uma nica tabela fato. Alm destas tabelas fato para cada processo, tabelas fato consolidadas s vezes so criadas para combinar mtricas de vrios processos em uma tabela fato com um nvel padronizado de detalhe. Novamente, tabelas fato agregadas so um complemento para as tabelas fato detalhadas relacionadas aos processos de negcio, e no um substituto para elas. Regra #3: Tenha certeza de que cada tabela fato tenha uma dimenso de data associada. Os eventos mensurveis descritos na Regra #2 sempre tem uma data de algum tipo associada a eles, sejam eles um balancete mensal ou uma transferncia de dinheiro registrada em seu centsimo de segundo. Cada tabela fato deve ter ao menos uma chave estrangeira associada a uma tabela de dimenso data, cuja granularidade cada nico dia, com os atributos de calendrio e suas caractersticas no padronizadas relacionadas a data do evento, como o perodo fiscal ou um indicador corporativo de feriado. s vezes multiplas chaves estrangeiras de data esto ligadas em uma nica tabela fato. Regra #4: Certifique-se que todos os fatos em uma nica tabela fato esto na mesma granularidade ou nvel de detalhe. Existem trs granularidades fundamentais para classificar todas as tabelas fato: transacional, snapshot peridico, ou snapshot acumulado. Independente de sua granularidade, cada mtrica em uma tabela fato deve estar exatamente no mesmo nvel de detalhe. Quando voc mistura fatos representando muitos nveis de granularidade em uma mesma tabela fato, voc estar criando confuso para os usurios de negcios e tornando as aplicaes de BI vulnerveis a erros de valores ou outros resultados incorretos. Regra #5: Resolva relacionamentos muitos-para-muitos em tabelas fato. Como uma tabela fato guarda os resultados de um evento de um processo de

negcios, existem inerentemente relacionamentos muitos-para-muitos (M:M) entre suas chaves estrangeiras, como diferentes produtos vendidos em diferentes lojas em diferentes dias. Estes campos de chaves estrangeiras nunca devem conter valores nulos. s vezes dimenses pdem ter valores diferentes para uma nico mtrica, como diferentes diagnsticos associados com uma consulta mdica ou diferentes clientes de uma conta bancria. Nestes cados, seria irracional resolver as dimenses multi-valoradas diretamente na tabela fato, pois isto poderia violar a granularidade natural da mtrica. Neste caso, podemos usar um relacionamento muitos-para-muitos, com uma tabela de relacionamento em conjunto com a tabela fato. Regra #6: Resolva os relacionamentos muitos-para-um nas tabelas de dimenses. Hierarquicamente, relacionamentos muitos-para-um (M:1) entre atributos so normalmente desnormalizados ou concentrados em uma nica tabela dimenso. Caso voc no queira passar a maior parte de sua carreira desenhando modelos entidaderelacionamento para sistemas transacionais, voc precisa resistir a sua instintiva tendncia a normalizar ou criar um snowflake com subdimenses menores para cada relacionamento M:1; desnormalizao de dimenses a regra do jogo na modelagem dimensional. bastante comum ter muitos relacionamentos M:1 em uma nica tabela dimenso. Relacionamentos um-para-um, como uma nica descrio de produto associada a um cdigo de produto, tambm so encontradas em uma tabela dimenso. Ocasionalmente relacionamentos muitos-para-um so resolvidos na tabela fato, como no caso de uma tabela de dimenso detalhada com milhes de linhas e com atributos frequentemente atualizados. Entretanto, usar a tabela fato para resolver relacionamentos M:1 deve ser feito de forma moderada. Regra #7: Gravar nomes de relatrios e valores de domnios de filtros em tabelas dimenso. Os cdigos e, mais importante ainda, as decodificaes e descries associadas a eles usadas como nomes de colunas em relatrios e como filtros em consultas devem ser gravadas em tabelas dimensionais. Evite gravar campos com cdigos criptogrficos ou volumosos campos descritivos na prpria tabela fato; da mesma forma, no grave

apenas o cdigo na tabela de dimenso e assuma que os usurios no precisam das decodificaes descritivas ou que elas pdem ser resolvidas na aplicao de BI. Se a informao for um nome de linha/coluna ou um filtro de menu, ento ela deve ser tratada como um atributo de dimenso. Embora tenhamos dito na Regra #5 que as chaves estrangeiras de tabelas fato nunca devem ser nulas, tambm aconselhvel evitar nulos em campos de atributos de tabelas dimenso trocando o valor nulo por um valor como "NA" (no se aplica) ou algum outro valor padro, determinado pela administrao de dados, para reduzir a confuso entre os usurios se possvel. Regra #8: Tenha certeza de que as tabelas dimenso usam uma chave artificial. Chaves artificiais, sem significado e sequenciais (exceto para a dimenso data, onde chaves cronolgicamente definidas e mais inteligveis so aceitveis) provm um grande nmero de benefcios operacionais; chaves menores significam menores tabelas fato, menores ndices, e desempenho melhorado. Chaves artificiais so absolutamente necessrias no caso de voc estar registrando as alteraes dos atributos da dimenso com uma nova linha para cada mudana. Mesmo que seus usurios de negcios inicialmente no visualizem o valor de registrar as alteraes nos atributos, usar chaves artificiais tornar uma futura alterao de poltica menos onerosa. As chaves artificiais tambm permitem mapear mltiplas chaves transacionais para um nico perfil, adcionalmente protegendo contra atividades operacionais inesperadas, como a reutilizao de um cdigo de produto obsoleto ou a aquisio de uma outra empresa com suas prprias regras de codificao. Regra #9: Crie dimenses padronizadas para integrar os dados na empresa. Dimenses padronizadas (tambm conhecidas por dimenses comuns, principais, ou de referncia) so essenciais para o data warehousing empresarial. Gerenciadas no sistema de ETL e ento reutilizadas associadas a diversas tabelas fato; dimenses padronizadas trazem atributos descritivos consistentes para os modelos dimensionais e permitem a habilidade de navegar atravs dos dados integrados de diferentes processos de negcios. A matriz de negcios da empresa o diagrama de arquitetura chave para representar os processos de negcios principais da organizao e suas

dimenses associadas. A reutilizao das dimenses padronizadas finalmente diminui o tempo de desenvolvimento eliminando o desenho redundante e o esforo de desenvolvimento; entretanto, dimenses padronizadas requerem um compromisso e investimento em administrao de dados e governncia, desta forma voc no precisa que cada pessoa concorde com cada uma das dimenses para atingir a conformidade. Regra #10: Avalie requisitos e realidade continuamente para desenvolver uma soluo de DW/BI que seja aceita pelos usurios de negcios e suporte seu processo de tomada de decises. Os responsveis pela modelagem dimensional devem constantemente balancear os requisitos do usurios de negcios com as realidades inerentes aos dados de origem associados para desenvolver um modelo que possa ser implantado, e que, mais importante ainda; tenha uma boa chance de ser til aos negcios. A avaliao dos requisitos-verus-realidades parte da tarefa dos desenvolvedors de DW/BI, apesar de voc estar focado na modelagem dimensional, estratgia do projeto, arquiteturas tcnica/ETL/BI ou implantao/planejamento de manuteno. Se voc tem lido nossos artigos na Intelligent Enterprise, os livros Toolkit ou as dicas de Arquitetura mensais, estas regras no devem ser novas para voc, mas aqui voc as tem consolidadas em um nico local que pde ser utilizado como referncia para quando voc estiver envolvido no desenho ou reviso de seus modelos. Boa sorte!