Data Warehouse – Modelagem Dimensional

Nos posts anteriores dessa série já expliquei sobre o que é um Data Warehouse, para que ele serve e porque você deve aprender mais sobre ele.

Agora vou te explicar melhor sobre por onde você deve começar, que é a modelagem dimensional.

Mas antes de começarmos você precisa entender a diferença entre dados normalizados e desnormalizados.

 

Dados normalizados X dados desnormalizados

Os dados normalizados estão na terceira forma normal, utilizada em banco de dados relacional. Se você fez alguma faculdade em TI, provavelmente aprendeu sobre esse tipo de modelagem.

Eles permitem um armazenamento consistente e acesso eficiente aos dados. Essa forma reduz a redundância de dados e as chances de inconsistência. Esse estilo de banco tem como foco inserir, alterar e deletar os dados.

Já os desnormalizados, que é com o que nós trabalhamos, têm foco na consulta.

As consultas feitas em bancos de dados totalmente normalizados têm um mau desempenho, e para isso se usa a desnormalização: para melhorar o desempenho das consultas.

Mas claro, com um custo: com ela não temos a garantia de consistências dos dados, além de termos um banco muito maior.

O objetivo dos dados desnormalizados é entregar informação, é um sistema informacional, feito para ter uma consulta rápida. Vai ter redundância de dados, mas vai ser mais rápido.

 

Mas como funciona isso?

Em um banco normalizado, ou relacional, temos diversas tabelas, cada uma com sua chave primária e informações. Por exemplo, temos uma tabela “cidade” com o ID da cidade e o nome dela, e outra tabela “cliente” com o ID do cliente, o nome dele e a cidade onde mora. Mas nesse último item, ao invés de termos o nome da cidade registrado, temos o ID referente àquela cidade na tabela “cidade”.

Isso serve para evitar a redundância, evitando a repetição do mesmo nome diversas vezes e garantindo que o nome da cidade estará escrito sempre da mesma forma para todos os clientes.

No caso dos dados desnormalizados, nós temos o nome da cidade registrado na tabela de clientes, uma vez para cada cliente que morar naquela mesma cidade, o que aumenta muito o tamanho do banco e não garante tanta consistência dos dados.

Num modelo transacional, ou sistema operacional, você tem que ter integridade dos dados, eles não podem se repetir. Já no modelo dimensional, eles podem. Na verdade, eles devem.

Os mesmos dados se repetem em vários lugares, porque nesse caso ele é desenhado para melhorar o desempenho das consultas, porque o Data Warehouse é feito para consulta, enquanto o operacional é feito para transação.

 

Entendi. Mas e a modelagem dimensional?

Modelo dimensional é uma das técnicas e conhecimentos mais importantes que você precisa ter para modelar o Data Warehouse, o Data Mart ou o que for.

O modelo dimensional existe há muito mais tempo que você imagina, e provavelmente, você que não conhece modelo dimensional, já até usou e não sabe.

Até para utilizar ferramentas, na parte de modelar os metadados ou cubos OLAP, você vai precisar entender de modelagem dimensional, a não ser que você utilize outro tipo de arquitetura de modelo de dados.

Existem dois tipos de metodologias de modelagem de dados usadas no Data Warehouse, a Snowflake e a Star Schema, que é a mais utilizada.

 

Star o quê?

O conceito de Star Schema, ou modelo estrela, foi idealizado por Ralph Kimball.

A ideia dele é propor uma visão para modelagem de base de dados para sistemas de apoio à decisão. Lembra que o Data Warehouse suporta a tomada de decisão e a modelagem dimensional também? O Star Schema, na sua essência, é isso.

star schema

O modelo estrela é composto no centro por uma tabela fato, que é rodeada por dimensões. Por isso que tem o nome de Star Schema, porque parece uma estrela.

Todo esse nome bonito, modelagem dimensional, para eu te mostrar uma estrela? Pois é.

O mercado complica muito as coisas. Para quem já me conhece, sabe que eu não gosto de enrolação, gosto da coisa muito prática e objetiva. Tem por aí muita gente que adora uma teoria, mas a base fundamental é o modelo Star Schema.

 

E aquelas tabelas fato e dimensão?

No Star Schema os dados são modelados em tabelas dimensionais, ligadas a uma fato.

As tabelas dimensão contêm as características de um evento. Por exemplo, quando eu faço uma venda, quero saber por onde a venda foi feita, que produto foi vendido, ou para quem.

Já a tabela fato armazena o que ocorreu, é o fato propriamente dito, por isso ela tem esse nome, porque é o fato ocorrido. A tabela fato está sempre ligada a duas ou mais dimensões, não existe tabela fato com menos de duas dimensões.

A tabela fato conecta com as dimensões e isso forma o modelo dimensional. Ela também é a principal tabela no modelo dimensional.

Quando são feitas consultas, elas ocorrem primeiro nas tabelas de dimensão e depois na fato. É comum quem trabalha com BI acreditar que a consulta começa pela fato, mas você não vai cometer esse erro.

É na tabela fato onde as métricas são armazenadas. Mas isso é conversa para outra hora.

Por enquanto, você precisa entender bem o conceito da modelagem dimensional, para então começar a se aprofundar mais no modelo Star Schema, nos tipos de fatos, de dimensões, métricas, grão, hierarquia e por aí vai, aqui está só o começo.

Fica de olho que nos próximos posts eu vou entrar em mais detalhes sobre isso.

 

Ah, e se quiser que eu te avise dos novos posts conforme eles forem saindo, é só deixar seu e-mail abaixo!

 

 

 

 

Deixe um comentário 🙂

Leia também: