Modelagem

Modelagem de dados

Modelagem

Como no caso dos Bancos de Dados de produção (BD), a necessidade de rapidez nas recuperações SQL é muito grande, mas, no caso dos DW, essa necessidade é maior. Essa necessidade se deve ao fato da quantidade de dados ser muito maior no DW que no BD. Justamente por isso que os bancos de DW não são totalmente normalizados, como no caso dos BD. Essa normalização é extremamente útil na economia de espaço no armazenamento de dados, pois tem justamente o objetivo de diminuir as duplicidades. Mas essa normalização envolve a criação de mais tabelas e torna as consultas mais complexas, por isso, essas consultas ficam mais lentas e, para as consultas ganharem performance, o DW não é totalmente normalizado, ou seja, permite alguns tipos de duplicidades nos dados.

Em um BD, os dados são armazenados em tabelas, no data warehouse os dados ficam armazenados em um formato de cubo, o cubos de dados. O cubo é a figura que representa as várias dimensões de dados inter-relacionadas, própria de um sistema multidimensional.

Modelagem Dimensional

Num DW, a modelagem deve ser estudada para atender as necessidades do negócio. Não existe um modelo certo ou errado. Para que essa modelagem seja feita da melhor maneira, uma das alternativas é o uso da modelagem dimensional.

Essa modelagem dimensional consiste em uma técnica de projeto lógico que procura apresentar dados em uma forma comum que é intuitiva para as pessoas que acessam e permita acesso de alto desempenho.

É diferente da modelagem Entidade-Relacionamento (E-R), que procura eliminar redundâncias de forma a economizar espaço. Essa eliminação de redundâncias tem como efeito a criação de diversas entidades dentro da modelagem, o que torna mais difícil a compreensão do modelo por usuários que não tenham nível avançado. A modelagem E-R faz com que as recuperações SQL possuam “joins” mais complexos, com a união de diversas tabelas, o que torna o resultado mais demorado.

São componentes do modelo dimensional:

• Fatos: são observações decorrentes do andar do negócio. Não são conhecidas de antemão, ou seja, não se sabe o seu valor até que se tenha acontecido. Compõe-se basicamente de campos numéricos. Ex: “quantidade de produtos vendidos”.
• Atributos do negócio: são as descrições das características do negócio. São conhecidos previamente e são caracterizados por campos textuais. Ex: nome do produto.

Tabelas do modelo dimensional:

• Tabelas Fato: são as tabelas que guardam os dados do negócio. Todas as informações decorrentes do andamento do negócio que não são conhecidas previamente. Os fatos podem ser aditivos, ou seja, podem ser acumulados, além de terem valores contínuos.
• Tabelas Dimensão: são as tabelas que guardam os atributos do negócio. Elas podem ser usadas para restringir as pesquisas feitas nos tabelas Fato e servem como títulos em colunas.

Existem várias formas de representação para os dados em ambientes de banco de dados convencionais. Podemos generalizar sem perder informações da seguinte maneira:

• Datas e Horas: uma das principais características de um DW através das suas operações é poder analisar historicamente os dados. Como as possibilidades de análise são atribuídas a restrições das dimensões e possibilidade de agrupar os dados, então as datas e horas são sempre bom indício de atributos de dimensão, não de fatos.
• Textuais: os dados textuais são descrições de fácil compreensão humana, logo é natural que sejam utilizados para descrição de elementos do negócio. Como as possibilidades de análise são atribuídas a restrições das dimensões e possibilidade de agrupar os dados, então as descrições textuais são sempre bom indício de atributos de dimensão, não de fatos.
• Fatos Aditivos: são numéricos e podem ser somados em relação às dimensões existentes, pois sua semântica permite tais operações. Sempre que em uma modelagem um dado numérico for apresentado então este será um bom indício de um atributo em fatos. Em geral, fatos aditivos representam medidas de atividade do negócio. Ex. Valor Venda, Quantidade de produtos vendidos.
• Fatos Semi-Aditivos: também são numéricos, mas não podem ser somados em relação a todas dimensões existentes, pois sua semântica não permite. Em geral, fatos semi-aditivos representam leituras medidas de intensidade do negócio. São snapshots destas leituras que entram no DW. O valor atual já leva em consideração valores passados. Ex. Nível de Estoque, Fechamento diário/mensal de conta.
• Fatos Não-Aditivos: algumas observações não são numéricas que também não são datas/horas podem eventualmente ser fatos dos eventos. Campos textuais de livre formato são ruins quer seja para dimensões ou fatos. Em geral, campos como “obs” são exemplos desta situação, pois o domínio é irrestrito. Ex. Em um DW para registrar acidentes de transito temos: carro 1, carro 2, moto 1, moto 2., hora/data, descrição do acidente, descrição do tempo (chuva,...) e descrição da pista.

Aditivos	Semi-Aditivos	Não-Aditivos
Numéricos Somas Bons Fatos Fácil Browsing	Numéricos Média Fatos Razoáveis Browsing Médio	Textual e Lógico Contagem Fatos Ruins Browsing Médio

Granularidade

Granularidade é o nível de representação mais específico utilizado para armazenar os dados. Cada Grânulo representa, em suma, uma entidade dentro da modelagem E-R. Em muitas situações, existem hierarquias de conceitos, onde a modelagem é o nível mais inferior. Um banco de maior granularidade é um banco de dados extremamente normalizado.

O nível de granularidade de um DW deve ser estudado de forma a deixá-lo de entendimento e uso mais simples, para qualquer usuário. Quanto mais baixo o nível escolhido para a granularidade no DW, maior será a quantidade de dados armazenados (próximo ao transacional). A escolha da granularidade do DW não precisa ser a mesma da utilizada no operacional, por isso sempre será igual ou superior (agregado).

Esquema Estrela

Um esquema do tipo estrela, também conhecido por “star” possui uma entidade que contém o identificador de instância, os valores das dimensões descritivas para cada instância, e os valores dos fatos, ou medidas, para aquela instância. Essa entidade é a chamada Tabela Fato. Essa tabela fato terá pelo menos uma Tabela Dimensão, que, conforme a definição acima, irá armazenar os dados sobre os atributos do negócio. Em um caso bem simples, a Tabela Dimensão tem uma linha para cada valor válido da dimensão. Esses valores correspondem a valores encontrados na coluna referente àquela dimensão na Tabela Fato.

A figura acima mostra um exemplo desse esquema Estrela, onde você possui uma Tabela Fato, no centro, e, nas extremidades, você possui as Tabelas Dimensão. Enquanto que a Tabela Fato se liga com as demais Tabelas Dimensão por diversas ligações, as Tabelas Dimensão se ligam somente a Tabela Fato e por uma ligação simples.

A Tabela Fato é onde as medidas numéricas do fato representado estão armazenadas. Cada uma destas medidas é tomada segundo a interseção de todas as dimensões. No caso do exemplo, uma consulta típica selecionaria fatos da tabela FATOSVENDAS a partir de valores fornecidos relativos a cada dimensão.

Abaixo segue uma pequena explicação sobre as variações do Esquema Estrela:

• Esquema Estrela com múltiplas tabela fato: acontece quando existem fatos não relacionados tornando possível existir mais de uma tabela fato ou quando a freqüência de carga dos dados operacionais é distinta. Ex. tabela fato de vendas e tabela fato de vendas previstas.

• Tabelas Associativas: algumas chaves podem ser desdobradas na tabela fato quando existem relacionamentos muitos-para-muitos.

• Esquema Estrela com tabelas Externas: nesse esquema uma ou mais tabelas dimensão podem conter uma chave estrangeira que referencia a chave primária de outra tabela dimensão, podendo também ser chamada de tabela dimensão secundária.

• Esquema floco de neve: o esquema floco de neve é uma variação do esquema estrela no qual todas as tabelas dimensão são normalizadas na terceira forma normal (3FN). Reduzem a redundância, mas aumentam a complexidade do esquema e conseqüentemente a compreensão por parte dos usuários. Elas dificultam as implementações de ferramentas de visualização dos dados. Impossibilitam o uso de esquemas de indexação mais eficientes como o bitmap indexing.

• Tabela Multi-Estrela: são assim chamadas quando a chave da tabela fato é complementada por mais campos que não são dimensões.

• Constelações: quando existem múltiplas tabelas fato que compartilham as mesmas dimensões, dizemos que o esquema de constelações de fatos. Isto acontece quando as medidas nas tabelas fatos possuem diferenças em relação aos eventos geradores: Ex: vendas realizadas x vendas previstas ou venda unitária x desconto por venda conjunta.

Vantagens do modelo estrela:

• O modelo Estrela tem uma arquitetura padrão e previsível. As ferramentas de consulta e interfaces do usuário podem se valer disso para fazer suas interfaces mais amigáveis e fazer um processamento mais eficiente;
• Todas as dimensões do modelo são equivalentes, ou seja, podem ser vistas como pontos de entrada simétricos para a tabela de fatos. As interfaces do usuário são simétricas, as estratégias de consulta são simétricas, e o SQL gerado, baseado no modelo, é simétrico;
• O modelo dimensional é totalmente flexível para suportar a inclusão de novos elementos de dados, bem como mudanças que ocorram no projeto. Essa flexibilidade se expressa de várias formas, dentre as quais temos:

o Todas as tabelas de fato e dimensões podem ser alteradas simplesmente acrescentando novas colunas a tabelas;

o Nenhuma ferramenta de consulta ou relatório precisa ser alterada de forma a acomodar as mudanças;

o Todas as aplicações que existiam antes das mudanças continuam rodando sem problemas;

• Existe um conjunto de abordagens padrões para tratamento de situações comuns no mundo dos negócios. Cada uma destas tem um conjunto bem definido de alternativas que podem então ser especificamente programadas em geradores de relatórios, ferramentas de consulta e outras interfaces do usuário. Dentre estas situações temos:

o Mudanças lentas das dimensões: ocorre quando uma determinada dimensão evolui de forma lenta e assíncrona;

o Produtos heterogêneos: quando um negócio, tal como um banco, precisa controlar diferentes linhas de negócio juntas, dentro de um conjunto comum de atributos e fatos, mas ao mesmo tempo esta precisa descrever e medir as linhas individuais de negócio usando medidas incompatíveis;

• Outra vantagem é o fato de um número cada vez maior de utilitários administrativos e processo de software serem capazes de gerenciar e usar agregados, que são de suma importância para a boa performance de respostas em um data warehouse.

Banco de dados Multidimensionais

Abaixo segue as figuras que representam o modo tradicional de representação de um BD relacional e a representação de uma matriz bidimensional.

BD Relacional
Modelo	Cor	Vendas
Van	Azul	6
Van	Vermelha	5
Van	Branca	4
Coupe	Azul	3
Coupe	Vermelha	5
Coupe	Branca	5
Sedan	Azul	4
Sedan	Vermelha	3
Sedan	Branca	2

Matriz Bidimensional
Modelo	Azul	Vermelha	Branca
Van	6	5	4
Coupe	3	5	5
Sedan	4	3	2

Como é possível observar, na primeira tabela, os dados estão dispostos de maneira relacional tradicional. Fica evidente que a segunda opção é mais clara e de fácil entendimento, pois os valores de venda se encontram nas intersecções entre os eixos X e Y, formando um matriz bidimensional 3X3.

Numa matriz bidimensional valores são muito facilmente armazenados. Para isso, basta somente adicionar mais uma coluna, ou uma linha.

Um array multidimensional tem um número fixo de dimensões. As posições segundo uma dimensão são também chamadas de elementos ou membros. As dimensões podem ser compostas por múltiplos níveis, segundo os quais os dados podem ser grupados. Os membros do nível mais baixo da hierarquia de uma dimensão são chamados de membros de entrada.

Modelos de dados

A modelagem de dados é muito importante no desenvolvimento do DW e quando ela é feita de maneira uniforme em todos os aspectos do desenvolvimento, a manutenção é muito mais simples e o esforço necessário será muito menor quando for necessário unir todos os modelos de dados envolvidos no projeto todo, pois todos os componentes do sistema estarão usando a mesma estrutura de dados.