Banco de Dados

27 abr, 2012

Seria a modelagem dimensional uma “bala de prata”?

Publicidade

A discussão entorno das diferentes abordagens de modelagem para data warehouses não é um assunto novo, mas continua causando confusão nas cabeças de quem está conhecendo o assunto agora e até mesmo de quem já o conhece. O objetivo aqui não é comparar as abordagens de Kimball versus Inmon, como é muito comum encontrar nas bibliografias sobre Business Intelligence.

O nosso objetivo é apresentar o manifesto sobre a modelagem dimensional, publicado por Ralph Kimball, em 1997, com uma pequena introdução ao assunto e os questionamentos sobre suas polêmicas declarações, apresentando pós e contras de dois profissionais e pesquisadores especialistas no assunto, Bill Inmon e Rob Armstrong. 

A modelagem dimensional tem sido amplamente utilizada nos projetos de BI e data warehouse de grandes a pequenas organizações. Vamos tentar mostrar que não há uma “bala de prata” (como aquelas que matam lobisomens) para projetos de data warehouses, mas, sim, deve haver um bom senso na sua modelagem, sempre com a visão da necessidade do negócio.

O manifesto de Ralph Kimball sobre modelagem dimensional

Modelagem dimensional (dimensional modeling – DM) é o nome de uma técnica de design lógico frequentemente utilizada em data warehouses. Ela é diferente e contrasta com a modelagem do tipo entidade-relacionamentos (entity relationship – ER). Modelagem ER é uma técnica de design lógico que visa remover a redundância de dados.

O estado da arte na modelagem ER é a remoção de toda a redundância de dados, que é altamente benéfico para o processamento de transações. O sucesso do processamento de transações em bancos de dados relacionais é, principalmente, devido à técnica de modelagem ER.

Para Kimball, em nosso zelo em tornar altamente eficiente o processamento de transações, acabamos por criar bases de dados que não podem ser consultadas. Simples modelos de dados tornam-se difíceis de compreender. O modelo ER das organizações possui centenas, ou até milhares de entidades lógicas. Kimball argumenta que diante desse cenário, os usuários finais não conseguem entender ou lembrar-se do modelo ER e, ainda, não podem navegar no modelo, softwares não podem consultar um modelo ER com facilidade e, por fim, o uso do modelo ER vai de encontro com o “fascínio” do data warehousing, que é a recuperação de dados de forma intuitiva e de alta performance.

Modelagem dimensional (MD) é uma técnica de design lógico que busca apresentar os dados dentro de um padrão, um framework intuitivo que permite um acesso aos dados com alta performance. É naturalmente dimensional e adere ao modelo relacional com algumas importantes restrições. Cada modelo dimensional é composto de uma tabela de chave composta, chamada de tabela de fatos, e um conjunto de tabelas chamadas de dimensão. Cada tabela de dimensão possui uma chave que corresponde a uma das chaves da tabela de fatos. Essa estrutura em estrela é comumente chamada de star-join (ou star-schema – modelo estrela).

Os fatos mais úteis e uma tabela de fatos são numéricos e aditivos. Para Kimball a aditividade é crucial, pois os sistemas de data warehouse quase nunca recuperam um registro de cada vez de uma tabela de fatos, e em vez disso, buscam centenas de milhares de registros ao mesmo tempo e a única coisa útil a fazer com tantos registros é sumarizá-los.

Já as tabelas de dimensão, na maioria das vezes, contêm informações descritivas em forma de texto. Os atributos de uma tabela de dimensão são utilizados como a maior fonte de constraints em consultas no data warehouse e são quase sempre a fonte das linhas de cabeçalho de um conjunto de dados retornados por uma consulta SQL.

Kimball aponta algumas forças do modelo dimensional:

  • O MD é previsível e possui um framework padrão e exatamente por isso, oferece grandes vantagens de processamento;
  • O MD é resistente a mudanças inesperadas no comportamento do usuário. Cada dimensão é equivalente e todas elas podem ser pensadas como pontos de entrada simetricamente iguais na tabela de fatos. O projeto lógico pode ser feito independente de padrões de consulta previstos. As interfaces de usuário e as estratégias de consulta são, ambas, simétricas, e o SQL gerado contra o modelo dimensional é simétrico;
  • O MD é extensível para acomodar novos elementos de dados e novos modelos de decisões;
  • No MD há um corpo de abordagens padrão para a manipulação de situações comuns de modelagem no mundo dos negócios;
  • Crescente número de ferramentas e utilitários que manipulam e utilizam as agregações. Segundo Kimball, se o MD não for utilizado, não há como beneficiar-se de tais ferramentas.

Kimball aponta ainda alguns mitos sobre o modelo dimensional e responde a cada uma das questões:

  • “Implementar um modelo dimensional levará a um afunilamento dos sistemas de suporte a decisão”. Este mito culpa a desnormalização para suportar somente aplicações específicas, que não podem ser alteradas. Para Kimball isto ocorre devido a uma visão míope do designer que modelou a tabela de fatos com dados prematuramente agregados;
  • “Ninguém entende de modelagem dimensional”. Um absurdo para Kimball, que relata que existem centenas de milhares de modelos dimensionais por todo o mundo.
  • “Modelos dimensionais trabalham apenas como bancos de dados de varejo”. Este mito está enraizado nas origens históricas da modelagem dimensional, mas não na sua realidade atual. A modelagem dimensional tem sido aplicada em diversas áreas de negócio;
  • “Snowflaking é uma alternativa para a modelagem dimensional”. Kimball acredita que snowflaking é um enfeite para a limpeza do modelo básico dimensional. O argumento de que snowflaking ajuda na manutenção da tabela de dimensão é ilusório. Problemas de manutenção são realmente aproveitados por disciplinas ER, mas tudo isso acontece no banco de dados de armazenamento de dados operacionais (ODS – operational data store), antes dos dados serem carregados no esquema dimensional;
  • “Modelagem dimensional só funciona para certos tipos de data-marts de um único tipo de assunto”. Para Kimball, isto é uma tentativa de marginalizar a modelagem dimensional por pessoas que não entendem o seu poder fundamental e aplicabilidade. Modelagem dimensional é a técnica apropriada para o projeto global de um completo data warehouse de nível empresarial.

Kimball acredita firmemente que “a modelagem dimensional é a única técnica viável para projetar bancos de dados entregáveis aos usuários finais” e que “ER anula a entrega ao usuário final e não pode ser utilizado para este propósito”, pois a modelagem ER não possui “regras de negócio”, e sim “regras de dados”.

Em seu manifesto, Kimball o encerra afirmando que “o modelo dimensional é a única técnica viável para alcançar o entendimento do usuário e o alto desempenho de consulta em face de questões em constante mudança do usuário”.

As respostas de Armstrong e Inmon para o manifesto de Kimball

Para Rob Armstrong, toda a questão do custo de junções de tabelas e sumarização de grandes volumes de dados levou ao conceito que diz que o modelo dimensional é necessário para o acesso ao usuário final. O maior problema com o modelo dimensional é que eles são projetados com base em fatores que são bem conhecidos e não são adaptáveis a novos relacionamentos, que podem ser descobertos e de fato desencorajam a descoberta de tais relações. A abordagem DM não suporta metas de longo prazo do data warehouse. Em contrapartida, o modelo ER fornece a base para a natureza transacional do data warehouse e nas mãos de um banco de dados capaz, permite a verdadeira análise exploratória, tal como mineração de dados (data mining).

Armstrong questiona os seguintes pontos do manifesto de Kimball: 

  • “Modelos ER não possuem regras de negócio, mas sim regras de dados”. A finalidade de um modelo de dados é para modelar as entidades dos dados e as relações que ligam essas entidades. Cabe ao usuário decidir como ele gostaria de manipular e explorar essas relações e conduzir ao poder de mineração de dados;
  • “O star-join (aquele em que o produto cartesiano das dimensões é usado para acessar o fato tabela) é uma técnica mais eficaz”. Apesar de ser uma união é valiosa, restringir o modelo para permitir apenas este tipo de acesso é um erro. O star-join é uma técnica de junção não uma abordagem de modelagem;
  • “Os usuários não podem navegar por um modelo ER”. Usuários finais não precisam saber como navegar em um modelo de dados. Estes devem preocupar-se com as ferramentas que acessam as bases de dados. A falta de boas ferramentas de navegação que é o problema;
  • “O uso da modelagem ER acaba com o fascínio do data warehouse, que é intuitivo e de alta performance na recuperação de dados”. As técnicas de data warehousing trabalham com capacidade e não performance. O verdadeiro data warehousing permite aos usuários fazer perguntas desconhecidas. O verdadeiro fascínio do data warehousing é que os usuários podem fazer novas perguntas e ter novas ideias.

Armstrong concorda com Kimball quando ele diz que a modelagem dimensional deve ser utilizada em data marts conhecidos, onde haverá consultas repetitivas que podem ser previamente planejadas e necessitam de um tempo de resposta rápido. Ao construir um data mart, um trade-off deve ocorrer, se o usuário identificar que sumarizar dados, possuir caminhos de agregação e rápida respostas nas consultas são fatores mais importantes que flexibilidade no acesso e busca de conhecimento em seus dados, então DM é o mais apropriado.

Bill Inmon concorda que, em termos de requisitos de captura para a análise de sistemas de suporte à decisão, o modelo dimensional é, sem dúvida, a melhor técnica para o projeto que existe. Os star-joins são ótimos para representar as visões que as pessoas têm em suas mentes, mas diferentes grupos de pessoas querem seus próprios star-joins. O modelo estrela é desenhado de acordo com os requisitos do usuário e os requisitos podem variar de um usuário para outro dentro da organização, logo diferentes modelos podem ser ideais para diferentes tipos de usuários.

Para Inmon, há uma série de razões onde cada departamento dentro da organização precisa de seu próprio modelo estrela, como a sequência e definição dos dados, granularidade, relacionamento entre dados e tempo. Inmon é categórico ao dizer que a maneira que diferentes departamentos dentro da organização visualiza o negócio é como seis homens cegos descrevem um elefante, isto porque cada um toca uma parte do elefante. Assim é com os departamentos de uma organização, cada um executa uma parte do negócio da sua forma.

O modelo estrela ideal para um departamento é quase ideal (ou reconhecível) para outro departamento. O resultado é que devido à natureza em que o negócio é executado, diferentes departamentos necessitam de diferentes modelos estrela. Quando há uma proliferação de modelos estrela dentro da organização, diversos problemas começam a surgir como a replicação dos mesmos dados entre os modelos, gerando crescimento desnecessário de dados, resultados inconsistentes entre os modelos e perda de controle sobre as aplicações que consomem os dados dos diferentes modelos.

Para Inmon, o modelo dimensional se encaixa muito bem na criação de data-marts, onde requisitos para o processamento são conhecidos antes da construção da infra-estrutura, mas não se encaixa em todos os lugares. Quando se trata de dados fundamentais, a história é outra.

Conclusão

O modelo dimensional não é uma “bala de prata”. Conforme Inmon e Armstrong apontaram, existem questões discutíveis na essência do modelo dimensional, que é uma abordagem factível e ideal para a construção de data-marts, quando os requisitos são conhecidos e orientados a um segmento do negócio, não para o data warehouse.

Analisando a semântica do termo data warehouse, onde este banco de dados é um verdadeiro “armazém” de dados, este armazém não deve ser orientado a qualquer processo de negócio dentro da organização. O seu objetivo é acomodar historicamente os dados da organização e a partir dele fornecer subsídios para o suporte à tomada de decisões. A abordagem deste suporte pode ser através de abordagens como data-mart, que é orientado a processos de negócio, data mining, para descoberta de padrões e conhecimento ou qualquer outra, que melhor se encaixe nas necessidades do negócio.

Ao implantar um projeto de data warehouse, ao invés de fazer perguntas como “como vamos construir o data warehouse?” ou “qual abordagem iremos utilizar?”, deve-se perguntar “qual é a necessidade do negócio?” ou “quais problemas de negócio iremos resolver?”. É importante sempre ter em mente que o data warehouse é o pilar de sustentação dos sistemas de suporte à decisão dentro da organização. O caminho para a resolução dos problemas da organização vai variar de acordo com a necessidade do negócio.

Referências

  • A Dimensional Modeling Manifesto, KIMBALL, R., 1997;
  • Responding to Raph: A Rebuttal to the Dimensional Modeling Manifesto, ARMSTRONG, R., 1997;
  • The Problem with Dimensional Modeling, INMONN, W., 2000.