Manifesto à Modelagem Dimensional

Leia esse Manifesto de Ralph Kimball, em defesa da Modelagem Dimensional!

Ralph Kimball sempre foi um defensor da Modelagem Dimensional – Dimensional Modeling DM. Muitos são os textos por ele publicados em seu site e em outros sites técnicos. Iniciarei a nossa apresentação destas publicações, com o Manifesto escrito por Kimball, sobre a Modelagem Dimensional em conparação com a Modelagem Relacional. O texto foi por mim traduzido, de forma livre.    Vamos lá…      

 1 – Modelo Dimensional – DM   

Modelo Dimensional – DM (do inglês Dimensional Modeling) é o nome de uma técnica de desenho lógico, comumente usada para Data Warehouse. É diferente e contrastante com o Modelo Entidade Relacionamento – ER (do inglês Entity-Relation Modeling). Este artigo aponta as muitas diferenças entre estas duas técnicas, e traça uma linha divisória. DM é uma técnica viável somente para bases de dados desenhadas para suportar consultas de usuários finais em um Data Warehouse. ER é muito útil para capturar transações e na fase de administração dos dados, durante a construção de um Data Warehouse, mas deve ser evitada para o usuário final.    

  [1]Cabe aqui, uma apresentação dos conceitos de Ralph Kimball sobre Data Warehouse, até mesmo para tornar este artigo mais inteligível.   


[1] Complemento inserido pelo Tradutor


      

 Data Warehouse Segundo Ralph Kimball          

  

  • Staging Area:
    • Parte do Data Warehouse responsável por receber a extração, transformação e carga (ETL) das informações dos sistemas transacionais legados, para posterior geração dos Data Marts de destino.
    • A Staging Area é considerada área fora do acesso dos usuários.
    • A Staging Area não deve suportar queries dos Usuários.
    • Ela pode ser composta por flat files (arquivos textos) ou tabelas de banco de dados na terceira forma normal (normalizadas).
  • Data Presentation Area:
    • Área responsável pela apresentação dos dados, não deve ser utilizada para limpeza ou transformação de dados.
    • Organizada em Data Marts, orientados a processos de negócios, e não a unidades de negócio, departamentos ou funções específicas.
    • Um Data Mart é composto por dados atômicos e dados sumarizados para uma melhor performance.

 O que é ER?     

ER é uma técnica de desenho lógico que busca remover a redundância de dados. Imaginemos ter um negócio que recebe pedidos e vende produtos a clientes. Nos dias iniciais da computação (muito antes dos Bancos de dados Relacionais), onde fizemos as primeiras transferências de dados para um computador, nós, provavelmente, capturaríamos a ordem de venda (Pedido) original, em papel, como um único registro, com muitos campos. Esse tipo de registro poderia, facilmente, ter 1.000 bytes distribuídos entre 50 campos. As linhas de item dessa ordem de venda eram representadas, provavelmente, como um conjunto repetido de campos encapsulado com o registro mestre. Ter esses dados no computador era muito útil, mas nós, rapidamente, aprendemos algumas lições básicas sobre armazenamento e manipulação de dados. Uma dessas lições que aprendemos era que dados nessa forma de armazenamento apresentavam uma grande dificuldade em se manter consistentes, pois cada registro ‘suportava’ a si mesmo, ou seja, o nome do cliente e o seu endereço, por exemplo, apareciam várias vezes, porque esses dados se repetiam a cada ordem de venda realizada.  Inconsistências nos dados não eram verificadas, porque todas as solicitações de um cliente eram independentes e atualizar os dados desse cliente era muito complicado.       

 Mesmo nos primórdios da computação, aprendemos a separar os dados redundantes em tabelas distintas, como Clientes, Produtos – Dados principais, mas pagamos um preço por isso. Nossos sistemas, para recuperar e manipular esses dados, era complexo e ineficiente, porque necessitavam uma atenção cuidadosa no processo dos algoritmos para ligar esses conjuntos de tabelas. Precisávamos de um sistema de base de dados que fosse muito bom em ligar essas tabelas. Isso pavimentou o caminho para a revolução das bases de dados relacionais, onde a base de dados era devotada a apenas essa tarefa.     

A revolução da [1]base de dados relacional estourou no meio dos anos 80. Muitos de nós aprendemos sobre bases relacionais lendo livros sobre o assunto, como por exemplo, [2]An Introduction to Relational Databases (Addison-Wesley), primeira publicação do começo dos anos 80. Vimos em suas páginas, como trabalhar com todos os exemplos de bases de dados para Material, Fornecedores, e Cidades. Não ocorreu, a muitos de nós, perguntar se os dados estavam completamente ‘normalizados’ ou se qualquer uma das tabelas poderia ser [3] “snowflaked,” e o autor não desenvolveu nenhum desses tópicos. Em minha opinião, o autor estava tentando explicar mais os fundamentos conceituais do que como pensar em tabelas relacionais juntas (Joined).  Modelagem ER e Normalização foram desenvolvidas anos depois, quando a indústria focou os processos transacionais.      

A Técnica de Modelagem ER é a disciplina usada para iluminar o microscópico relacionamento entre os elementos de dados. O estado da arte da modelagem ER é remover todas as redundâncias de dados. Isso é imensamente benéfico aos processos transacionais porque as transações são feitas de forma determinada e de forma muito simples. A transação para atualizar o endereço de um cliente pode se resumir em uma única [4]‘olhada’ (lookup) na tabela master de Endereços do Cliente. Essa ‘olhada’ é controlada por chaves de controle do endereço do cliente, e permita um acesso indexado que é extremamente rápida. É seguro dizer que o sucesso dos processos transacionais é devido, em muito, à modelagem ER.      

Contudo, em nosso zelo por fazer um processo transacional eficiente, perdemos de vista o nosso inicial e mais importante objetivo. Nós criamos Bases de Dados que não podiam ser consultadas!      

 

Figura 1 – Uma visão do modelo ER de alto nível. Cada caixa, no diagrama, é, na verdade, várias entidades. Cada processo de negócio mostrado é, provavelmente, uma aplicação legada separada. O desenho DM equivalente, deverá isolar cada processo de negócio e cercá-lo das dimensões relevantes.       

Mesmo o nosso simples exemplo ‘tirador de pedidos’ criará uma base de dados com dúzias de tabelas que são ligadas por uma selvagem teia de aranha de [5]joins (Veja a figura1 acima).        

Todos nós estamos familiarizados com os grandes gráficos na parede de nossa sala, representando as bases de dados dos nossos sistemas de informação. O modelo ER para o empreendimento tem centenas de entidades lógicas! Os sistemas high-end, como o SAP, têm milhares de entidades. Cada uma dessas entidades, usualmente, se transforma em uma tabela física quando a base de dados é implementada. Esta situação não é apenas irritante, é digna de aplausos:      

  • Os usuários finais não podem entender ou lembrar-se do modelo ER. Os usuários finais não podem navegar pelo modelo ER. Não existe nenhuma interface gráfica (do inglês GUI – Grafical User Interface) que torna o modelo ER utilizável.
  • Os softwares não podem, de forma prática, consultar um modelo ER. Otimizadores baseados em custo que tentam fazer essa tarefa são notoriamente conhecidos por suas escolhas erradas, causando desastres na performance.
  • O uso da técnica de modelagem ER desafia o atrativo básico do Data Warehousing, que é a recuperação rápida de informações.

Desde o começo da revolução das bases de dados relacionais, Desenvolvedores de sistemas de informação tem notificado esse problema. Muitos deles que tentaram entregar dados ao usuário final, reconheceram a impossibilidade de apresentar esses imensos e complexos esquemas aos usuários finais, e desses desenvolvedores voltaram a antigos passos para tentar simplificar esse desenho. “Eu acho impressionante que esses desenhos simplificados sejam todos similares! Quase todos esses desenhos simplificados podem passar como sendo ‘dimensionais’”. De um modo natural, quase inconsciente, centenas de projetistas de Sistemas de Informação retornaram á raiz, às origens, do modelo relacional por saberem que bases de dados não podem ser usadas a menos que empacotadas de forma simples. Provavelmente, é acurado dizer que essa visão natural de dimensão não foi inventada por uma única pessoa. É uma força irresistível no desenho de bases de dados que ira aparecer sempre que o projetista coloca o fácil entendimento e alta performance como os mais altos objetivos. Estamos, agora, prontos para definir a visão (approach) DM.      

O que é DM?      

 DM é uma técnica de desenho lógico que procura apresentar os dados com um padrão, encapsulamento ([6]framework) intuitivo que permite acessos com grande performance.  É disponibilizado dimensionalmente, e adere a uma disciplina que usa o modelo relacional com algumas restrições importantes.  Todo modelo dimensional é composto por uma tabela multi chaves, chamada de FATO, e um conjunto de pequenas tabelas chamadas DIMENSÃO. Cada tabela dimensão tem uma única primary key que corresponde a exatamente um dos componentes da multi chave da tabela fato. Veja a figura 2 abaixo.      

  

Figura 2 – Um modelo dimensional detalhado, para um ponto de vendas de retalhos. Números de 1 a 4 mostram lugares onde o desenho pode ser graciosamente estendido.      

A figura acima caracteriza uma estrutura parecida com uma estrela, usualmente chamada de [7]‘star join’. Esse termo remonta aos dias iniciais das bases de dados relacionais.      

Uma tabela fato, por ter uma primary key composta, feita por duas ou mais foreign keys, irá expressar sempre, um relacionamento muitos-para-muitos.  Usualmente, as tabelas fatos contêm uma ou mais medidas numéricas (fatos) que ocorre para a combinação de chaves que definem cada registro. Na figura 2, acima, as medidas ou ‘fatos’ são Dollars Sold, Units Sold, e Dollars Cost. Usualmente, as medidas ou ‘fatos’ são numéricos e aditivos.  A ‘aditividade’ é crucial porque as aplicações Data Warehouse quase nunca recuperam um único registro ou linha; pelo contrário, recuperam centenas, milhares ou até mesmo milhões de linhas de uma vez, e a única coisa útil a se fazer com tantas linhas é somá-las.      

Tabelas Dimensão, por contraste, contêm, no mais das vezes, informações descritivas e textuais. Os atributos da dimensão são usados como uma origem de muitas das mais interessantes restrições em consultas ao Data Warehouse e são sempre, virtualmente, a origem do cabeçalho das linhas em um conjunto de consultas SQL. Na figura 2, acima, podemos restringir os produtos sabor limão, usando o atributo Flavor da tabela Product, e nas promoções via Radio, usando o atributo AdType na tabela Promotion. Deve ser obvio que o poder da base de dados na figura 2 é proporcional à qualidade e profundidade das tabelas dimensão.      

O charme do desenho das bases de dados da figura 2 é que ela e facilmente reconhecida pelos usuários finais para o negócio em particular. Temos observado que centenas de [8]instances onde o usuário final imediatamente concorda, ao ver o modelo, que ‘esse é o seu negócio’.      


 

[1] Entendamos como Banco de Dados(N.T.)      

[2] Um dos primeiros livros editados sobre Banco de Dados Relacional(N.T.)      

[3] Tipo de modelagem onde temos dimensões associadas a dimensões, criando um desenho semelhante a um floco de neve (SnowFlake) (N.T.)      

[4] Lookup é uma expressão muito usada para designar um acesso, via chave, a uma tabela(N.T.)      

[5] Nome técnico do comando SQL que faz a ligação da tabela origem, via primary key, a uma tabela destino, via foreigner key. (N.T.)      

[6] Uma estrutura para suportar ou encapsular alguma coisa,  especialmente um suporte usado como base para alguma coisa que esteja sendo construído; Plataforma de trabalho externa; Estrutura fundamental para um trabalho escrito; Um conjunto de entendimentos, conceitos, valores e práticas que constituem um modo de ver a realidade. (N.T.)      

[7] Modelo de união entre dimensões que lembra uma estrela. Também conhecida como STAR SCHEMA. (N.T.)      

[8] Pode-se definir como uma solicitação para uma série de eventos. O ambiente aonde um Banco de Dados esta sendo rodado é conhecido como instance (Instance Oracle)      


DM vs. ER      

 Obviamente, as figuras 1 e 2 são completamente diferentes. Muitos projetistas reagem a isso dizendo “Tem que haver menos informações em um Star Join” ou “O star join é apenas usado como sumário”. Ambos os comentários são falsos.      

A chave para entender o relacionamento entre DM e ER é que um único diagrama ER se quebra em múltiplos diagramas DM.  Pense em um grande diagrama ER que represente todas as possibilidades de processos de negócio na empresa. O diagrama ER master pode ter as Vendas, Entrada de Ordens de Venda, Notas Fiscais, Pagamentos e Retorno de Produtos, todos no mesmo diagrama. De certa forma, o próprio diagrama ER presta a si mesmo, um desserviço por representar em um único diagrama, múltiplos processos que nunca coexistirão em um único conjunto de dados em um único ponto consistente no tempo. Portanto, não é de se estranhar que o diagrama ER é extremamente complexo. Assim, o primeiro passo na conversão de um diagrama ER para um conjunto de diagramas DM, é separar o diagrama ER em cada um de seus processos de negócio.      

O Segundo passo é selecionar aqueles relacionamentos muitos-para-muitos no modelo ER, contendo colunas (fatos) numéricos e aditivos, que não sejam chave, para designá-las como tabelas fato. O terceiro passo é desnormalizar todas as tabelas restantes, em tabelas tipo flat, com uma única chave que será conectada às tabelas fato. Essas tabelas se tornarão dimensões. Em casos em que a dimensão se conecta a mais de uma tabela fato, representaremos essas mesmas dimensões em ambos os esquemas, e nos referiremos à dimensão como sendo uma CONFORMED DIMENSION, pois ela esta em conformidade com ambos os fatos.      

O Modelo DM [1]master, resultante de um Data Warehouse para uma grande empresa irá consistir de algo entre 10 e 25 esquemas star join, bastante similares. Cada esquema star join irá conter entre 4 a 12 dimensões. Se o desenho foi feito de forma correta, muitas dessas dimensões serão compartilhadas entre tabelas fatos. Aplicações que utilizam [2]drill down irão, simplesmente, adicionar mais atributos das dimensões no conjunto de consultas SQL dentro de um único star join. Aplicações que utilizarão o [3]drill across irão simplesmente ser ligadas em fatos separados através das dimensões ‘conformed’.  Mesmo que do começo ao final do modelo DM da empresa, tenhamos um alto grau de complexidade, o processo de consulta (query) será muito previsível porque, no mais baixo nível, recomendamos que cada tabela fato seja consultada de forma independente.      

      


[1] Mestre, principal. (N.T.)      

[2] Descer a um nível maior de informação, dentro de uma mesma dimensão associada a um fato. (N.T.)      

[3] Descer a um nível maior de informação, entre diferentes dimensões/fatos. (N.T.)      


 Bom, continuamos essa apresentação em nosso próximo encontro. Até lá!

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: