A especificidade dos projetos de Data Warehouse, em comparação com as aplicações de gestão tradicionais, reflete-se também numa técnica diferente de modelagem de dados. No ambiente decisório, os dados são organizados de forma a responder diretamente às consultas típicas do usuário final. Para baixar o texto completo e obter mais informações, clique AQUI
Suponhamos, por exemplo, que o objetivo do usuário seja monitorar ao longo do tempo o planejamento e a realização dos projetos de investimento que utilizam financiamentos públicos, localizados em várias áreas do território nacional, ligados a diferentes setores de atividade. De forma simplificada, pode-se imaginar representar esta atividade através de um cubo, cujos lados reproduzem as variáveis tempo, localidade e classificação da atividade, relativamente aos projetos. Cada ponto dentro do cubo é a interseção das coordenadas definidas pelos lados do cubo e representa a medida do fato de interesse (o projeto e o respectivo financiamento) para aquela combinação particular de localidade, setor de atividade, tempo, que representam as dimensões da análise. No contexto de Data Warehouse, fala-se então de modelagem dimensional de dados. O modelo dimensional e o tradicional modelo entidade-relacionamento são potencialmente capazes de armazenar as mesmas informações. A diferença está relacionada à busca por desempenho ideal nos dois tipos de ambientes. Em ambientes operacionais é fundamental adotar técnicas de normalização que, eliminando redundâncias, permitem que um grande número de transações repetitivas interroguem e atualizem as informações em um único ponto do banco de dados. Os sistemas de suporte à decisão, por sua vez, são caracterizados por um número reduzido de transações, que operam de forma transversal na base de dados, requerendo acesso em leitura a um grande volume de dados para serem unidos (join). O uso de técnicas de normalização, portanto, mostra-se contraproducente no planejamento de um sistema de Data Warehouse. Em ambiente decisório, é mais correto projetar o banco de dados de maneira a satisfazer diretamente e de forma simplificada as necessidades específicas dos usuários finais, inclusive por meio de dados denormalizados e agregados. É importante dedicar muita atenção à análise do modelo conceitual, prevendo todas as dimensões da análise e para cada dimensão seus respectivos atributos. Os atributos das tabelas dimensionais são usados diretamente como condições de busca nas consultas ao Data Warehouse e como cabeçalhos das colunas nos relatórios dos usuários finais. O uso de dados pré-agregados e de síntese limita o número de operações necessárias para reconstruir a informação solicitada. O star schema, além de ser otimizado para consultas, apresenta a vantagem adicional de permitir uma representação gráfica do negócio mais compreensível para o usuário final. Diferentemente do esquema entidade-relacionamento, em que todas as entidades são representadas da mesma forma, o star schema é assimétrico. No centro do diagrama há uma tabela dominante de grande dimensão, que é a única a possuir múltiplas ligações, concretizadas em campos-chave nela contidos, para as outras tabelas. As outras tabelas representam as dimensões de análise pelas quais se examina o “fato” de interesse. Tecnicamente definem-se “fact table” a tabela central e “dimension table” as demais. A fact table é a tabela onde são armazenadas as medidas numéricas do fato (no exemplo, o valor do financiamento do projeto de investimento), cada uma representando a interseção de todas as dimensões e quantificando uma ou mais variáveis. Normalmente é a única tabela normalizada. As outras tabelas representam as dimensões de análise pelas quais se examina o “fato” e contêm atributos do tipo descritivo. A cardinalidade dessas tabelas, normalmente denormalizadas, é limitada. Entre as tabelas dimensionais, a tabela da dimensão tempo está sempre presente nos modelos dimensionais, independentemente do negócio a ser representado. Isso deriva da característica dos sistemas de Data Warehouse que também gerenciam informações históricas. Às vezes, para melhorar ainda mais a interpretabilidade do modelo, as tabelas dimensionais também são normalizadas, explicitando hierarquias. Isso dá origem a um esquema denominado “floco de neve” ou Snowflake Schema. A navegação dos dados através do modelo snowflake é menos eficiente que no Star Schema porque aumenta o número de tabelas nas quais realizar as junções. Deve-se considerar que, se por um lado a desnormalização garante melhor desempenho nas operações de consulta, por outro lado torna mais onerosa a atualização e o carregamento dos dados. De modo mais geral, as operações de manutenção do modelo de dados multidimensional, como a extensão a novas dimensões de análise, requerem o carregamento “ex novo” da base de dados. Por isso, de caso a caso, é preciso avaliar o trade-off entre essas duas necessidades e adotar, conforme o caso, o Star Schema ou o Snowflake Schema. Deve-se ainda acrescentar que, para modelos muito complexos, com diversas fact tables que compartilham várias dimensões, torna-se difícil adotar a técnica dimensional, também porque nem sempre fica claro quais são as tabelas de fatos e quais as de dimensões. Para o desenho conceitual do Enterprise Data Warehouse, parece preferível, portanto, um modelo de dados Entidade-Relacionamento devidamente desnormalizado. A modelagem dimensional é certamente mais adequada para a representação de dados dos Data Marts. Os modelos dimensionais podem ser implementados tanto em DBMS relacionais quanto em DBMS multidimensionais específicos. REPRODUÇÃO RESERVADA
Pubblicato in Negócios
Seja o primeiro a comentar