Olá, boa noite!
Seja bem-vindo a mais um post da sessão “Contando História com Dados“.
Nesta sessão, você encontrará posts relacionados a área de dados, destacando ao longo dos anos como este elemento atualmente reconhecimento como o mais importante em nossas vidas, conseguiu evoluir, conquistar o seu espaço, tornando-se cada vez mais vital para nossa evolução.
Em adicional, estarei compartilhando sempre que possível, um documento, apresentação ou resumo do conteúdo aqui compartilhado, o qual conterá o meu ponto de vista, conhecimento e aprendizados obtidos ao longo dos estudos realizados para elaboração do referido post.
Neste sexto post, destaco de forma breve outros conceitos relacionados a Modelagem de Dados aplicada em ambientes de Data Warehouse, em especial Dimensões Descaracterizadas e Modelo Snowflake.
Introdução
Podemos dizer que uma dimensão retrata um conjunto de informações de referência sobre um evento mensurável.
As tabelas de dimensões categorizam e descrevem os fatos e as medidas do Data Warehouse (Armazém de Dados formado para Apoio a Decisão – Componente de uma Solução de Business Intelligence) de maneiras que suportam respostas significativas a questões de negócios, com base, nos dados armazenados em suas estruturas.
Em outro contexto, o esquema ou modelo floco de neve (snowflake) denota-se por representar uma variação do esquema estrela, no qual todas as tabelas de dimensão são normalizadas na terceira forma normal (3FN), ou seja, são retirados das tabelas os campos que são funcionalmente dependentes de outros campos que não são chaves.
Dimensões Descaracterizadas
As dimensões descaracterizadas, também conhecidas como dimensões degeneradas, são tipos de atributos normalmente empregados em tabelas fatos onde a granularidade da tabela representa uma transação propriamente dita ou uma linha de item da transação, podendo ser usada para agrupar itens de linha em uma única ordem. Podem também representam um identificador de registro.
São representadas na tabela de fatos como chaves de dimensão sem que exista a tabela de dimensão. Muitas vezes dimensões descaracterizadas compõem a chave primária da tabela de fatos junto com as chaves estrangeiras das outras dimensões.
A Figura 1 ilustra um exemplo de dimensão descaracterizada na tabela de fatos Vendas, com o atributo número da venda. Como as outras informações, como Cliente e Data, já estão em outra dimensão, o número da venda se torna uma dimensão descaracterizada:
Figura 1 – Dimensão descaracterizada “código da venda” na tabela de fatos Vendas.
Esquema ou Modelo Floco de Neve (Snowflake)
O esquema ou modelo do floco de neve é uma variante do esquema estrela, o qual, apresenta a tabela fato centralizada conectada a múltiplas dimensões.
No esquema de floco de neve, as dimensões estão presentes de forma normalizada em várias tabelas relacionadas. Sua composição apresenta um modelo estrela, contendo dimensões detalhadas e altamente estruturadas, formado por vários níveis de relação, e as tabelas filhas possuem várias tabelas pai.
O efeito floco de neve afeta apenas as tabelas de dimensões e não afeta as tabelas de fatos.
Um esquema de floco de neve é um tipo de técnica de modelagem de dados usada em data warehouse para representar dados de forma estruturada e otimizada para consultar grandes quantidades de dados de forma eficiente.
Um esquema floco de neve, evidencia as tabelas de dimensão de forma normalizada em várias tabelas relacionadas, criando uma estrutura hierárquica ou “floco de neve”.
A tabela fato fica localizada no centro do esquema, cercada pelas tabelas de dimensão. No entanto, cada tabela de dimensões é dividida em várias tabelas relacionadas, criando uma estrutura hierárquica que se assemelha a um floco de neve, conforme apresenta a Figura 2 que ilustra o modelo de Dados de um sistema de vendas de lojas de departamento:
Figura 2: Exemplo modelo Snowflake.
Recomenda-se utilizar o esquema floco de neve apenas quando a linha de dimensão ficar muito longa e começar a ser relevante do ponto de vista de armazenamento. Se as tabelas de dimensão forem normalizadas podem surgir alguns problemas. A complexidade do modelo de dados aumenta e, consequentemente, diminui a compreensão desse modelo por parte dos usuários.
A implementação do floco de neve frustra o uso de esquemas de indexação mais eficientes como o índice de mapa de bits [KIMBALL, 2002].
William H. Inmon
Esses índices são muito úteis para indexar campos de baixa cardinalidade, agilizam muito o desempenho de uma consulta ou restrição à única coluna em questão, sendo assim ideais para tabelas desnormalizadas. Esse esquema inevitavelmente interfere na possibilidade de exploração dessa técnica de ajuste de desempenho.
O desempenho durante a fase de atualização dos dados do data warehouse será
melhor com as tabelas normalizadas, mas isso não é tão importante em sistemas de apoio à decisão, uma vez que esta operação é feita normalmente durante a noite ou em momentos em que não estejam sendo executadas consultas por parte dos usuários.
Mesmo assim, alguns projetistas utilizam o argumento de melhorar este desempenho para justificarem a necessidade de normalizar as dimensões.
No entanto, a performance das consultas realizadas pelos usuários tende a diminuir devido o aumento do número de junções, e essa sim pode ser crucial para o sucesso do ambiente visto que os usuários que esperam retornos cada vez mais rápidos.
Kimball [1996] aconselha os projetistas “bem-intencionados” a resistirem à tentação de transformar esquemas estrela em esquemas floco de neve, devido ao impacto da complexidade deste tipo de estrutura sobre o usuário final, enquanto que o ganho em termos
Ralph Kimball
de espaço de armazenamento seria pouco relevante.
A decisão de optar pelo esquema estrela ou pelo floco de neve deve ser tomada levando-se em consideração o volume de dados, o SGBD, as ferramentas utilizadas, etc.
Outra possibilidade é mesclar o esquema estrela com o esquema floco de neve, normalizando apenas algumas dimensões. Essas dimensões normalizadas podem ou não ter um relacionamento direto com a tabela de fatos.
Download
Referências
INMON, W.H. Como construir o Data Warehouse. Rio de Janeiro: Editora Campus, 1997. 388p.
INMON, W.H, WELCH, J. D., GLASSEY, K. L. Gerenciando Data Warehouse. São Paulo: Makron Books, 1999. 375p.
PEDERSEN, T. B., JENSEN, C. S. Multimensional Database Technology. Revista
Computer, 2001.
KIMBALL, Ralph. Data Warehouse Toolkit. São Paulo: Makron Books, 1996-b. 388 p.
KIMBALL, Ralph, REEVES, Laura, ROSS, Margy, THORNTHWAITE, Warren. TheIData Warehouse Lifecycle Toolkit – Expert Methods for Designing, Developing andIDeploying Data Warehouses. New York: John Wiley & Sons, Inc., 1998. 771 p.
KIMBALL, Ralph, ROSS, Margy. The Data Warehouse Toolkit (Segunda Edição). Rio de Janeiro: Editora Campus, 2002. 494 p.
Agradecimento
Obrigado por sua visita a mais este post do meu blog!
Espero que este post e todos os demais aqui compartilhados possam lhe ajudar ao longo das mais diversas necessidades da sua vida profissional e acadêmica.
“Aproveite, para viver cada dia, observando como você pode transformá-la em uma nova história repleta de dados.“
Um forte abraço.
Junior Galvão - MVP - Data Platform 