Modelagem Multidimensional

Fala pessoal!!! Salve, salveeee 😉

Bom, neste artigo vou abordar alguns conceitos sobre Modelagem Multidimensional, conteúdo relacionado aos tópicos que envolvem conhecimento sobre Data Warehouse(DW) e Business Intelligence(BI).

Vem comigo!

O que você precisa inicialmente assimilar é que no Modelo Multidimensional os dados são praticamente os mesmos que existem no modelo relacional normalizado, porém de uma outra forma.

O usuário deste tipo de modelo é um usuário diferente dos sistemas OLTP (Online Transaction Processing) , ou seja, ele não opera os dados do dia a dia, ele na verdade consome estes dados com a possibilidade de fazer uma série de combinações entre eles, afim de conseguir captar cenários que o ajudem a tomar uma decisão, seja numa lista, numa tabela ou em gráficos, ou até mesmo no conjunto de todos estes itens, através do uso de ferramentas OLAP(On-line Analytical Processing).

Enquanto o usuário de sistemas OLTP (Online Transaction Processing) está preocupado com a operação de cadastrar, alterar, editar e excluir dados, o tomador de decisão está preocupado em obter dados que possam mostrar para ele uma situação presente, com base em históricos passados e ter a possibilidade de prever o que poderá ser feito no futuro.

Os profissionais que cuidam da modelagem multidimensional ficam atentos a estas necessidades para fins de melhor modelar a solução DW que irá ser disponibilizada com acesso por meio de ferramentas amigáveis para estes usuários.

É com base neste panorama, que iremos agora continuar, porém aumentando o nível de detalhes. Respira fundo e vem comigo! 🙂

Tabelas Fatos e Dimensões

O modelo de armazenamento multidimensional evolve dois tipos de tabelas:

Tabelas de Fatos

É a tabela central do projeto dimensional, armazenando medições numéricas de negócio. Possui chaves de múltiplas partes, sendo que cada chave é uma chave externa para uma tabela de dimensão. Cada medição recebe como o valor o resultado da interseção com as dimensões. Consultas realizadas nas tabelas fato podem retornar milhares de registros.

Em uma tabela fato podem existir vários fatos, ou seja, cada linha corresponde a alguma medição da área de negócio, sendo esta medição demonstrada em uma granularidade específica. Um exemplo, em um contexto de licitação, seria que cada linha represente um item do edital de licitação e seu valor de referência.

Quando se vai levantar os requisitos para uma tabela fato, não se olha para o relatório final desejado, mas o que ela representa dentro de um evento físico observável. Se em um edital de licitação eu tenho itens, com seus quantitativos e valor de referência, isto corresponderá na forma de um-para-um com uma linha na tabela fato, sendo este um princípio importante para uma modelagem dimensional.

Quanto as suas medições ou dados de medidas, as tabelas fatos podem ser de vários tipos:

Aditivas: É o resultado da soma dos valores gerados pela seleção dos membros das dimensões, sendo o resultado desta soma mostrado como métrica da tabela fato. Podem ser agrupadas com qualquer das dimensões associadas à tabela de fatos. Ex: Valor Licitado.
Semi-aditivas: É a soma resultante de partes das suas dimensões, ou seja, se agrupam em algumas dimensões, mas não em todas. Ex: Quantidade em Estoque, saldo, não podendo se relacionar com a dimensão tempo, por exemplo.
Não aditivas: São medidas que não podem ser somadas em nenhuma dimensão. Ex: Percentual de Desconto, Taxa de Juros

É possível perceber que nem todo valor numérico pode ser somado ou agregado de alguma forma.

As tabelas fato possuem dois ou mais atributos chaves estrangeiras, que são relacionados com chaves primárias nas tabelas de dimensão. Veja o exemplo abaixo.

Pontos de atenção sobre Tabelas Fatos

Nas tabelas fatos é possível ocorrer medidas com valores nulos, no entanto, os valores nulos devem ser evitados em chaves estrangeiras da tabela de fatos, para evitar possível violação de integridade referencial.

As tabelas de dimensão, para evitar o uso de chave estrangeira nula, utiliza uma linha padrão (com uma surrogate key) que representa a condição desconhecida ou não aplicável. Assim sendo, quando uma tabela origem de uma dimensão possui uma chave composta para a identificação única da linha na tabela, usamos uma Surrogate Key única para representar essa primary key composta. Mesmo que não tenhamos uma chave composta no sistema de origem, criamos uma Surrogate Key na dimensão (com a finalidade de Primary Key), para permitir um controle histórico dos dados.

Resumindo, a Surrogate Key é um atributo chave, que não faz parte da relação original, sendo considerada chave substituta para fins de facilitar os relacionamentos e respeitando as propriedades de uma chave primária.

Nos SGBDs é comum o uso de atributos primários usando sequence, são atributos que criam um valor sequencial automático e único, este atributo não tem relação com o negócio, apenas garante de forma simplificada os relacionamentos e a integridade referencial.

Tabelas de Dimensões

É a representação do contexto relevante para o negócio da organização ou departamento. Apresentam o contexto descritivo. Um exemplo seria uma tabela fato COMPRAS com tabelas de dimensão FORNECEDOR, MATERIAL e LOCAL. As tabelas de dimensão podem possuir membros e serem organizadas por hierarquia.

Membros: Um exemplo de membros na dimensão FORNECEDOR seria: “nome, CNPJ, telefone”.
Hierarquia: Um exemplo do uso de hierarquia na dimensão MATERIAL seria: “Grupo ->Classe->Item”.

A tabelas dimensões são formadas por atributos descritivos, que são utilizados pelas aplicações OLAP, para realizar filtros e agrupamentos das tabelas fatos. Uma vez que tenha definido qual será a granularidade de uma tabela fato, fica mais fácil definir e identificar a possíveis dimensões.

Um detalhe importante é que uma mesma dimensão pode ser compartilhada com diferentes tabelas fatos, como é o exemplo abaixo onde a Dimensão 3 e Dimensão 4 são compartilhadas com as tabelas fatos.