Artigo SQL Magazine 13 - Modelagem de Data Warehouses e Data Marts – Parte 1

De uma forma simples, data warehouses e data marts existem para responder questões que as pessoas têm sobre os negócios. São uma base de informações consolidadas, integrada e não volátil, para apoiar os processos de tomada de decisões estratégicas, táticas e também operacionais de organizações. Esta função contrasta fortemente com o propósito dos sistemas transacionais (sistemas que apoiam a operação da empresa) e requer que o desenho ou o modelo de dados do data warehouse siga princípios completamente diferentes. Vários aspectos considerados de extrema importância na modelagem de sistemas transacionais como a aplicação de rígidas regras de normalização são, muitas vezes, deixados de lado ao se modelar um data warehouse ou data mart.

Este artigo tem por objetivo mostrar os detalhes que envolvem uma das técnicas utilizadas para a modelagem dos dados em data warehouses e também em data marts, a modelagem dimensional. Essa técnica segue a chamada escola Ralph Kimball, introdutor do conceito do star schema. Na segunda parte deste artigo, a ser publicada em edição futura da SQL Magazine, apresentaremos detalhadamente o “star schema” e sua variação normalizada: o snowflake schema. Na terceira parte, abordaremos outra técnica utilizada para modelagem apenas de data warehouses, a modelagem relacional diversificado, que segue a chamada escola Bill Inmon, considerado o “pai” do conceito de data warehouse.

A modelagem dimensional e suas implementações

As técnicas de modelagem dimensional de um data warehouse, se aplicadas corretamente, garantem que o desenho do data warehouse reflita a forma de pensar dos analistas de negócio e gerentes da empresa e possa ser usado eficazmente para atender os seus requisitos de negócio. Aliás, este é o princípio básico da modelagem de um data warehouse: discutir diretamente com o usuário final sua visão do modelo de negócios e fazer com que esta visão seja refletida na base de informações.

Saiba mais: Curso de Python

O data warehouse deve ser desenhado para transpor os limites de cada um dos sistemas transacionais. Ele é construído para responder questões que não estão limitadas às transações ou aos sistemas individuais, apresentando, desta forma, uma visão integrada e completa dos negócios. Uma das técnicas utilizadas para se obter um modelo para o data warehouse que identifique e represente as informações importantes para o modelo de negócios é a modelagem dimensional ou multidimensional. Quando bem definido, o modelo dimensional pode ser uma ajuda de valor incalculável para as áreas de negócio, apoiando e otimizando todo o processo de tomada de decisões. O modelo dimensional representa:

• Os indicadores importantes para uma área de negócios, que são chamados de fatos ou métricas;
• Os parâmetros através dos quais estas métricas são analisadas pelos usuários, que são chamados de dimensões (as dimensões de negócios).

A Figura 1 apresenta um modelo dimensional simplificado para um processo de pedidos. As métricas definidas neste modelo estão no quadro central e as dimensões estão representadas nos quadros ao redor das métricas. As métricas são sumariadas (agregadas) ou detalhadas de acordo com o interesse da análise a ser feita sobre os dados. Este modelo é fácil de ser entendido por uma pessoa da área de negócios, já que “as coisas que eu avalio” estão na parte central do diagrama e “as formas de se olhar para elas” estão nos quadros em volta.

Fica fácil perceber que estes quadros facilmente se transformarão em tabelas (com alguns atributos adicionais) utilizadas para armazenar toda a informação necessária. Um modelo como este não muda muito ao ser implementado em um banco de dados relacional (RDBMS). Cada quadro com os atributos de uma dimensão se torna uma tabela, chamada de tabela dimensão, e o quadro central se torna uma grande tabela, chamada tabela fato, que contém, por vezes, milhões ou bilhões de linhas.

Porém, os modelos dimensionais nem sempre são implementados em bases de dados relacionais. Existem no mercado bancos de dados multidimensionais (MDDBS), que armazenam informações em um formato diferente, frequentemente chamado de cubos. Os cubos são construídos de tal forma que, cada combinação de atributos das dimensões com uma métrica, é calculado antecipadamente ou é calculado muito rapidamente.

Entretanto, a natureza de um banco de dados multidimensional também significa que não é possível manipular volumes de dados extremamente grandes já que uma transação de análise dos dados, com uma ferramenta OLAP (Online Analytical Processing), que envolva um grande volume de dados vai consumir grande quantidade de memória ou simplesmente não se efetuará. Além disso, o número de atributos dimensionais armazenados em um cubo pode impactar o tempo de carga, o tamanho e o desempenho do cubo.

Uma das alternativas para solucionar estes problemas pode ser a implementação do modelo dimensional em um banco de dados relacional e, após isto, utilizá-lo como fonte para carga posterior de subconjuntos de dados nos cubos. Esta abordagem é muito utilizada em empresas que querem executar análises em subconjuntos de um grande conjunto de dados armazenados em um data warehouse. Quando esta abordagem é implementada, o data warehouse como um todo fica armazenado no banco de dados relacional, enquanto que partes ou segmentos deste data warehouse são copiadas e armazenadas em cubos, que são chamados de data marts. Estas arquiteturas básicas de implementação estão representadas nas Figuras 2 e 3.

Nesta parte do artigo ainda não iremos nos preocupar com as tecnologias de implementação física dos modelos de dados, mas apenas analisaremos as etapas de modelagem necessárias para atender qualquer tipo de implementação, seja em um banco relacional ou multidimensional.

Os passos para a modelagem

O processo de modelagem dimensional é composto por algumas etapas cujo objetivo é levantar e representar as necessidades de análise e de informações dos usuários de determinada área de negócios. A Tabela 1 apresenta uma visão geral deste processo. Nas seções seguintes discutiremos cada uma destas etapas.

Passo 1 – Definindo os fatos ou métricas

Este passo vai definir o que queremos avaliar no data warehouse/data mart, ou seja, os fatos. Estes fatos são os números que serão medidos e analisados através das diferentes dimensões de negócios (que serão definidas no passo 2). A seleção dos fatos que irão compor o modelo do data warehouse é relativamente simples. Uma vez definida a área de negócios que estamos modelando, a lista de fatos a serem utilizados responde à questão: “O que estamos avaliando?”. Estes fatos são os números com os quais o usuário lida. Para exemplificar todo o processo de modelagem utilizaremos um modelo para a área comercial. Nosso usuário pode ser um gerente comercial de uma rede de lojas que tem por necessidade avaliar, por exemplo, a quantidade de itens vendidos, o valor de venda, o custo de cada um dos itens e a margem produzida. Note que estes valores devem ser trazidos dos sistemas transacionais onde é mantida cada uma destas métricas. Nem sempre as métricas são originadas em um só sistema. Por esta razão, é necessário bastante cuidado ao se definir os processos que farão extração, transformação e carga (ETL) destes valores, dos sistemas transacionais para o data warehouse.

Em nosso exemplo da área comercial, o gestor quer analisar também, além das métricas realizadas, os valores que haviam sido planejados (devem ser trazidos provavelmente de um sistema de planejamento e orçamento), bem como valores calculados do planejado sobre o realizado.

Algumas das métricas poderão ser calculadas durante o processo de extração, transformação e carga e serão armazenadas no data warehouse já calculadas ou então poderão ser calculadas diretamente, em tempo de consulta, pelas ferramentas OLAP. Nesta etapa da modelagem, todas as métricas (calculadas ou trazidas da base transacional) serão tratadas da mesma forma.

Assim, em nosso exemplo, as métricas ou fatos que este usuário necessita avaliar são:

• Valor da venda – realizado;
• Valor da venda – previsto;
• Quantidade de itens – realizada;
• Quantidade de itens – prevista;
• Preço médio de venda;
• Custo médio;
• Margem de venda;
• % de variação entre o realizado e o planejado.

Passo 2 – Definindo as dimensões de negócios

Após termos definido as métricas que serão armazenadas no data warehouse/data mart, passamos a definir cada uma das dimensões relacionadas às métricas. Nesta etapa vamos perguntar ao usuário “Como as métricas serão analisadas?”, ou seja, sob quais dimensões de negócio avaliaremos os fatos? Por exemplo, cada uma das métricas precisa ser analisada ao longo do tempo. Isto significa analisar a quantidade de itens vendidos por mês, ou talvez até mesmo por dia. Poderemos também comparar períodos de vendas analisando, por exemplo, a quantidade de itens vendidos no último mês em comparação com o mesmo mês no ano anterior. Através de sugestões e exemplos, vamos dando “dicas” para que o usuário entenda o que estamos querendo identificar, ao mesmo tempo que ele vai nos informando suas necessidades de análise das informações.

Em nosso exemplo, as dimensões de negócio a serem implementadas (conforme necessidades especificadas pelo usuário) serão:

• Dimensão Tempo: que indica os períodos de tempo para a análise;
• Dimensão Produto: que indica quais produtos estão relacionados com as métricas;
• Dimensão Geografia: que indica a região geográfica onde se encontram as lojas que efetuam as vendas.

Agora temos que verificar se cada métrica se relaciona com todas as dimensões definidas, já que cada conjunto de métricas deve ser analisado através do mesmo conjunto de dimensões. Para isto, podemos perguntar se cada métrica pode ser analisado ao longo de cada dimensão, por exemplo: “Faz sentido analisar o valor das vendas por produto? E por loja? E ao longo do tempo?”.

Passo 3 – Definindo a granularidade das informações em cada dimensão

Uma vez definidas as dimensões de negócio através das quais as métricas serão analisadas, é importante saber qual o nível de detalhe, ou granularidade, mais baixo que será avaliado. Em nosso exemplo, podemos começar pela dimensão Tempo. Podemos questionar o usuário da seguinte forma: “Qual o nível de detalhe desejado? Faz sentido avaliar a métrica quantidade vendida por dia?”. Assim, para cada uma das métricas definidas, vamos identificar qual o nível mais baixo de detalhe que será armazenado no data warehouse. Se, para a dimensão Tempo o nível mais baixo de detalhe for dia, então todas as métricas deverão ser obtidas com valores por dia. Para o nosso exemplo consideraremos o nível de granularidade mais baixo como sendo:

• Dia: para a dimensão Tempo;
• Item de produto: para a dimensão Produto;
• Loja: para a dimensão Geografia.

Assim, os processos de ETL que irão trazer as informações dos sistemas transacionais para o data warehouse devem fazê-lo no nível mais baixo de granularidade especificado para cada uma das dimensões. Desta forma, para a métrica valor da venda devemos trazer o valor de venda realizado para cada item de produto, em cada dia e em cada loja. A Tabela 2 mostra um subconjunto das informações necessárias para se preparar o data warehouse do nosso exemplo.

Note que apesar do usuário desejar um determinado nível de granularidade, é importante saber se a informação está disponível neste nível de detalhe nos sistemas transacionais. Por exemplo, de nada adianta o usuário querer analisar as informações de vendas diárias se os sistemas transacionais não têm estas informações disponíveis.

Como mostrado na Tabela 2, será preparada uma linha para cada loja, em cada dia com as vendas de cada item de produto e os valores somados ou calculados para cada métrica. Por exemplo, na primeira linha temos, para o dia 5 de janeiro de 2004, do produto Lápis n° 2 Faver Carel, na Loja 04, o valor total das vendas, a quantidade total de itens vendidos e assim sucessivamente para as outras métricas.

Passo 4 – Definindo a hierarquia de agrupamento de informações

Os dados estarão armazenados no data warehouse no nível de detalhe estabelecido, porém, normalmente o usuário desejará analisar agrupamentos destas informações como: “Qual o total de canetas vendidas, nas lojas do estado de São Paulo, no último semestre?”. Esta pergunta já indica que deveremos nos preocupar com o agrupamento, ou sumarização das informações armazenadas no data warehouse. Para isto, é necessário então definir quais as possibilidades de agrupamento das informações que o usuário deseja, especificando a hierarquia destes agrupamentos em cada uma das dimensões de negócio.

Uma hierarquia que parece natural em nosso exemplo é a que se apresenta na dimensão tempo. Meses normalmente são agrupados em bimestres ou trimestres, que por sua vez são agrupados em semestres e em anos. Apesar de ser natural, é importante saber o que o usuário necessita já que alguns modelos de negócio requerem agrupamentos temporais diferentes e mesmo para uma hierarquia tão natural quanto esta, ainda assim é necessário modelar o data warehouse para que seja possível efetuar este tipo de agrupamento. Em nosso exemplo, vamos considerar as seguintes hierarquias:

• Dimensão Tempo: dia ‐ mês ‐ semestre ‐ ano;
• Dimensão Produto: item de produto ‐ linha de produto ‐ categoria;
• Dimensão Geografia: loja ‐ cidade ‐ estado ‐ região.

A visão lógica do data warehouse

Com estas informações em mãos, podemos iniciar a modelagem do data warehouse/data mart, partindo de uma visão lógica baseada nas informações obtidas com os usuários. Uma forma de representação bastante simples, porém muito eficaz é a apresentada na Figura 4. Com este diagrama, é possível discutir diretamente com o usuário e validar as informações obtidas.

Até o momento ainda não iniciamos realmente a modelagem da base de dados que irá conter o data warehouse, porém, todas as atividades realizadas até agora são de extrema importância para entender o modelo de negócios que iremos representar. É importante envolver os usuários finais na validação da visão que obtivemos até este ponto pois, como em todos os tipos de sistemas, qualquer erro pode ser corrigido neste momento ainda com um custo muito baixo.

Na segunda parte deste artigo iremos discutir os dois esquemas mais utilizados na modelagem dimensional de data warehouses e data marts: o Star Schema e o Snowflake Schema com suas principais variações, dando continuidade ao exemplo aqui analisado.