Modelo de dados do Data Warehouse

Modelo de dados do Data Warehouse Ricardo Andreatto O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforços de desenvolvimentos são baseados em um único modelo de dados sempre que for necessário unir estes esforços os níveis de sobreposição de trabalho e desenvolvimento desconexo serão muito baixos, pois todos os componentes do sistema estarão utilizando a mesma estrutura de dados. Existe um grande número de enfoques sobre modelagem de dados já desenvolvidos por vários autores, a maioria deles pode ser usada para construir um data warehouse. Dentre estes modelos apenas o multidimensional será apresentado neste trabalho. A Questão das Dimensões Obter respostas a questões típicas de análise dos negócios de uma empresa geralmente requer a visualização dos dados segundo diferentes perspectivas. Como exemplo, imagine-se uma agência de automóveis que esteja querendo melhorar o desempenho de seu negócio. Para isso, necessita examinar os dados sobre as vendas disponíveis na empresa. Uma avaliação deste tipo requer uma visão histórica do volume de vendas sob múltiplas perspectivas, como por exemplo: volume de vendas por modelo, volume de vendas por cor, volume de vendas por fabricante, volume de vendas por período de tempo. Uma análise do volume de vendas utilizando uma ou mais destas perspectivas, permitiria responder questões do tipo: Qual a tendência em termos de volume de vendas para o mês de dezembro para modelos Volvo Sedan preto? A capacidade de responder a este tipo de questão em tempo hábil é o que permite aos gerentes e altos executivos das empresas formular estratégias efetivas, identificar tendências e melhorar sua habilidade de tomar decisões de negócio. O ambiente tradicional de bancos de dados relacional certamente pode atender a este tipo de consulta. No entanto, usuários finais que necessitam de consultas deste tipo via acesso interativo aos bancos de dados, mostram-se seguidamente frustrados por tempos de resposta ruins e pela falta de flexibilidade oferecida por ferramentas de consulta baseadas no SQL. Daí a necessidade de utilizar abordagens específicas para atender a estas consultas. Para compreender melhor os conceitos envolvidos, examinemos em maior detalhe o exemplo acima. Chamaremos de dimensões as diferentes perspectivas envolvidas, no caso, modelo, loja, fabricante, mês. Estas dimensões usualmente correspondem a campos não numéricos em um banco de dados. Consideremos também um conjunto de medidas, tal como vendas ou despesas com promoção. Estas medidas correspondem geralmente a campos numéricos em um banco de dados. A seguir, avaliam-se agregações destas medidas segundo as diversas dimensões e as armazenamos para acesso futuro. Por exemplo, calcula-se a média de todas as vendas por todos os meses por loja. A forma como estas agregações são armazenadas pode ser vista em termos de dimensões e coordenadas, dando origem ao termo multidimensional. 1/10

Intuitivamente, cada eixo no espaço multidimensional é um campo/coluna de uma tabela relacional e cada ponto um valor correspondente à interseção das colunas. Assim, o valor para o campo vendas, correspondente a mês igual a maio e loja igual a Iguatemi é um ponto com coordenada [maio, Iguatemi]. Neste caso, mês e loja são duas dimensões e vendas é uma medida. Teoricamente, quaisquer dados podem ser considerados multidimensionais. Entretanto, o termo normalmente se refere a dados representando objetos ou eventos que podem ser descritos, e, portanto, classificados por dois ou mais de seus atributos. Estruturas relacionais podem ser usadas para a representação e o armazenamento de dados multidimensionais. Neste caso, as abordagens encontradas incluem desde a adoção de formas específicas de modelagem (os chamados esquemas estrela e floco de neve) até mecanismos sofisticados de indexação. Esquemas do tipo Estrela e Floco de Neve Em um esquema do tipo estrela ou "star" as instâncias são armazenadas em uma tabela contendo o identificador de instância, valores das dimensões descritivas para cada instância, e valores dos fatos, ou medidas, para aquela instância (tabela de fatos). Além disso, pelo menos uma tabela é usada, para cada dimensão, para armazenar dados sobre a dimensão (tabela de dimensão). No caso mais simples, a tabela de 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 de fatos. Este esquema é chamado de estrela, por apresentar a tabela de fatos "dominante" no centro do esquema e as tabelas de dimensões nas extremidades. A tabela de fatos é ligada às demais tabelas por múltiplas junções, enquanto as tabelas de dimensões se ligam apenas à tabela central por uma única junção. A figura abaixo mostra um exemplo de um modelo tipo estrela. 2/10

Modelo Estrela A tabela de fatos é 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. Outro tipo de estrutura bastante comum é o esquema do tipo floco de neve ou "snowflake", que consiste em uma extensão do esquema estrela onde cada uma das "pontas" da estrela passa a ser o centro de outras estrelas. Isto porque cada tabela de dimensão seria normalizada, "quebrando-se" a tabela original ao longo de hierarquias existentes em seus atributos. No caso do exemplo, a dimensão produto possui uma hierarquia definida onde categoria se divide em marca e marca se divide em produtos (veja figura). Da mesma forma, a dimensão tempo inclui ano que contem mês e mês que contem dia-do-mes. Cada um destes relacionamentos muitos-para-1 geraria uma nova tabela em um esquema floco de neve. 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 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 o o Todas as tabelas de fato e dimensões podem ser alteradas simplesmente acrescentando novas colunas a tabelas; Nenhuma ferramenta de consulta ou relatório precisa ser alterada de forma a acomodar as mudanças; Todas as aplicações que existiam antes das mudanças continuam rodando sem problemas; 3/10

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 o Mudanças lentas das dimensões: ocorre quando uma determinada dimensão evolui de forma lenta e assíncrona; 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. Bancos de Dados Multidimensionais Embora seja viável utilizar estruturas relacionais na representação de dados multidimensionais, a solução não é ideal. Na figura a seguir, é fácil verificar como uma matriz bidimensional representa mais claramente os dados armazenados na forma relacional tradicional. Na matriz, os valores de vendas estão localizados nas interseções dos eixos X e Y da matriz 3x3. Cada eixo corresponde a uma dimensão, e cada elemento dentro de uma dimensão corresponde a uma posição. Um array agrupa informações semelhantes em colunas e linhas. Além disso, na representação multidimensional, totais consolidados são facilmente obtidos e armazenados, bastando simplesmente adicionar totais de colunas e fileiras [CAM99]. 4/10

Conversão do modelo E-R para o modelo do data warehouse Para tal, W. H. Inmon fornece então alguns passos que podem ser seguidos, não se esquecendo de que o fundamental é que as decisões de transformação devem ser tomadas levando-se em consideração os requisitos específicos da empresa. Os passos básicos são: Remoção dos dados puramente operacionais A primeira ação consiste em remover os dados que são usados apenas no ambiente operacional, como vemos no exemplo da figura abaixo. Neste, atributos tais como mensagem, descrição e status são retirados, pois é muito pouco provável que estes sejam utilizados no processo de tomada de decisão. Neste momento, pode ser que se pense em manter todos os atributos, pois talvez algum destes seja necessário para alguma decisão específica. Entretanto, deve-se levar em conta o custo para gerenciar grandes volumes de dados. Adição de um elemento de tempo na estrutura da chave A segunda modificação a ser feita no modelo corporativo é adicionar um elemento de tempo a chave das tabelas, se estas já não o tiverem. No exemplo da figura a seguir, o campo Data_Snapshot foi adicionado como parte da chave. Enquanto no modelo corporativo a chave é apenas a identificação do consumidor, no modelo do data warehouse a data do instantâneo deve fazer parte da chave, já que com o passar do tempo os dados do consumidor podem se alterar. Esta técnica é apenas uma forma de tirar instantâneos dos dados. Outra forma de fazê-lo é adicionar dois campos do tipo data, um marcando o início e outro o fim de um determinado intervalo de tempo. Esta técnica é melhor por representar faixas contínuas de tempo ao invés de pontos ou datas específicas. 5/10

Introdução de dados derivados O próximo passo é adicionar dados derivados ao modelo, como mostrado na figura a seguir, já que por regra geral estes não existem no modelo corporativo. Devem ser adicionados os dados derivados que serão usados habitualmente de forma que estes sejam calculados apenas uma vez. Dessa forma, haverá uma redução no processamento que deve ser feito para acessar os dados derivados ou sumarizados. Outra razão para o armazenamento de dados derivados é que uma vez calculados e armazenados, a integridade destes aumenta, uma vez que se torna impossível a utilização de diferentes algoritmos para o cálculo destes derivados. Transformação de Relacionamentos entre dados em artefatos dos dados Os relacionamentos encontrados nas modelagens de dados clássicas assumem que há um e somente um valor de negócio no relacionamento. Levando-se em consideração que nos sistemas operacionais o dado estar integro no momento da transação, esta abordagem é correta. Entretanto, o data warehouse por sua característica de armazenar dados históricos, tem muitos valores para um dado relacionamento entre duas tabelas. Dessa forma a melhor maneira de representar o relacionamento entre duas tabelas no data warehouse é através da criação de artefatos. Um artefato de um relacionamento é somente a parte do relacionamento que é óbvia e tangível no momento do instantâneo. Em outras palavras, quando o instantâneo é feito os dados associados com o relacionamento que são úteis e óbvios serão colocados no data warehouse. O artefato pode incluir chaves estrangeiras e outros dados relevantes, tais como colunas de tabelas associadas, ou este pode incluir somente os dados relevantes, sem incluir as 6/10

chaves estrangeiras. Como exemplo, consideremos as tabelas e o relacionamento entre estas na figura a seguir. Nesta existe um relacionamento entre produto e fornecedor, onde cada produto tem um fornecedor principal. Se fossemos fazer então um instantâneo deste relacionamento, teríamos que considerar a informação do fornecedor principal que está relacionado ao produto. Além disso, outras informações de artefato relacionadas com o fornecedor deveriam então ser capturadas. A tabela de produtos no modelo do data warehouse ficaria então como a mostrada na figura abaixo. Acomodação dos diferentes níveis de granularidade Dependendo do caso, o nível de granularidade do sistema transacional pode ser o mesmo do data warehouse ou não. Quando o nível de granularidade se altera, o modelo do data warehouse deve representar esta mudança, como no exemplo da figura a seguir. No exemplo, o modelo de dados corporativo mostra dados da atividade de envio de um determinado produto que são armazenadas toda vez que uma entrega é feita. Quando este é passado para o data warehouse, duas agregações são feitas, alterando então a granularidade. Na primeira, o total de entregas é agregado mensalmente, fazendo com que a granularidade seja o mês, já na segunda, existe uma agregação das entregas feitas por mês e local de origem, fazendo então com que a granularidade seja o mês associado ao fornecedor. 7/10

União dos dados comuns de diferentes tabelas Nesta fase, deve-se considerar a possibilidade de combinar duas ou mais tabelas do modelo corporativo em uma única tabela do modelo do data warehouse. Para que esta junção possa ser feita, as seguintes condições devem ser verdadeiras: As tabelas compartilham uma chave comum (ou chave parcial); Os dados das diferentes tabelas geralmente são usados juntos; Padrão de inserção nas tabelas é o mesmo. Como exemplo, consideremos a figura a seguir, onde temos as tabelas NOTAS e ITENS DAS NOTAS. Quando estas são colocadas no modelo do data warehouse, estas vão para uma mesma tabela. Dessa forma, a junção entre estas tabelas passa a não ser mais necessária quando uma consulta for feita. Neste caso, podemos ver que as três condições são atendidas: as tabelas compartilham parte da chave, ID da Nota; estas duas tabelas geralmente são usadas juntas; e o padrão de inserção é o mesmo, ou seja, sempre que uma nota é inserida seus itens também o são. 8/10

Criação de arrays de dados Os dados no modelo corporativo geralmente estão normalizados, onde a existência de grupos repetitivos não é permitida. Entretanto, em algumas situações no ambiente de data warehouse pode haver grupos repetitivos de dados. As condições para existência destes são: Quando o número de ocorrências do dado é previsível; Quando a ocorrência do dado é relativamente pequena (em termos de tamanho físico); Quando as ocorrências do dado geralmente são usadas juntas; Quando o padrão de inserção e remoção dos dados é estável; A figura abaixo mostra uma tabela no modelo corporativo com as previsões de gasto mensais. Quando esta é colocada no modelo do data warehouse, os dados são armazenados de forma que cada mês do ano é uma ocorrência no array. 9/10

Separação dos atributos de dados de acordo com sua estabilidade A próxima atividade de projeto, referente à passagem do modelo de dados da empresa para o modelo de dados do data warehouse, consiste em realizar a análise de "estabilidade". A análise de estabilidade é uma tarefa que consiste em agrupar atributos de dados segundo sua propensão a alterações. A figura abaixo ilustra a análise de estabilidade de uma tabela de produtos. Neste exemplo é possível perceber que os dados que raramente sofrem alterações são agrupados com outros dados que apresentam essa mesma característica, dados que às vezes são alterados são agrupados com outros dados que às vezes são alterados e dados que freqüentemente são alterados são agrupados com outros dados freqüentemente alterados. O resultado final da análise de estabilidade é a criação de grupos de dados que apresentem características semelhantes. 10/10