O que é Star Schema

Data Warehouse – O Que É Star Schema?

A modelagem dimensional é utilizada para melhorar a performance de sistemas voltados para consulta. E o modelo mais utilizado para isso é o Star Schema ou Modelo Estrela, que foi idealizado por Ralph Kimball para dar suporte à tomada de decisão.

O modelo estrela é composto no centro por uma tabela fato que é rodeada por tabelas de dimensão, ficando parecido com a forma de uma estrela (que é de onde vem o nome do modelo).

A ideia do Kimball é propor uma visão para modelagem de base de dados para sistemas de apoio à decisão, que é o caso do Data Warehouse.

As metodologias usadas para criação de Data Warehouse são Star Schema e Snowflake, que é defendido pelo Bill Inmon.

O Snowflake também é projetado para suportar tomada de decisão, mas economizando espaço em disco. Para o Star Schema, o Snowflake é apenas mais um tipo de dimensão.

Embora o Star Schema ocupe mais espaço em disco, ele é mais fácil de implementar e acabou sendo mais utilizado porque além de hoje em dia o espaço ser muito barato, ele permite entregar projetos por pedacinhos. Você pode criar um assunto ou departamento em uma estrela para só depois projetar outro, e assim por diante.

Na maioria esmagadora dos projetos, Star Schema é uma excelente escolha.

 

Onde isso entra no Data Warehouse?

O Data Warehouse é um conjunto de modelos, vários modelos estrelas.

Embora os Star Schemas sejam feitos pensando em um modelo de entrega rápido, o foco é sempre no Data Warehouse, para depois conectar as dimensões, porque você não pode ter dimensões iguais.

No modelo de Star Schema você pode entender que o Data Mart é uma coisa mais processual, focado em um assunto só.

 

E o que vai em um Star Schema?

Tabela Fato

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 fato é a principal tabela do Data Warehouse, e você pode ter uma ou mais tabelas fato.

Tabela Fato

Essa tabela armazena 2 coisas:

  • Os fatos ocorridos, ou seja, as métricas
  • As chaves para as dimensões

Ou seja, a fato é composta por alguma métrica e os códigos das dimensões.

 

E o que é métrica?

Métrica é também chamada de quantificador ou medida. Alguns chamam de KPI, mas KPI também pode ser considerado um cálculo entre duas métricas.

Elas são utilizadas para metrificar algo e sempre são números, porque precisam ser contáveis. Esses números são provenientes de transações da empresa.

Por exemplo:
Hoje eu tomei 5 cafés
Métrica: quantidade de cafés bebidos (5 nesse caso)

Dá para fazer uma análise com ela, por exemplo, no tempo: nos últimos 30 dias, que dias eu tomei mais café?

Tudo que a empresa for mensurar é uma métrica. Na maioria das vezes, a métrica vai ser o que o usuário quer medir.

Pergunta para o usuário: o que tu quer medir, que informação quer ver na tela?

Normalmente o cara vai responder: quero ver as vendas, meus seguidores no twitter, quanto que a gente tem de fluxo de caixa etc…

Você identifica muito fácil quais são as métricas só com essas perguntas.

 

Então qual que é a diferença de uma métrica para um KPI?

O KPI na sua essência são duas métricas relacionadas entre si, pode ter sido uma dividida ou multiplicada pela outra, e geralmente precisa ter meta.

Por exemplo:
a quantidade de café que eu tomo por dia dividido pela quantidade de horas que eu durmo.
Porque quanto mais café eu tomo, menos eu durmo.
Dá para criar um KPI do meu sono de acordo com a quantidade de café que eu tomo.

 

Tabela dimensão

Dimensão, também chamado de qualificador, descreve o fato ocorrido, ela contém as características do evento.

Por exemplo, quando eu faço uma venda, quero saber por onde a venda foi feita, que produto foi vendido ou para quem.

Elas vão qualificar, classificar ou descrever os dados que estão nas fatos, ou seja, as métricas.

Para identificar as dimensões, normalmente perguntamos pelo que o usuário quer mensurar uma informação. Elas vão ser toda e qualquer informação que qualifique uma métrica ou medida.

Por exemplo:
Preciso medir as vendas.
Ótimo, mas pelo quê?
Pela empresa / pelo produto / pelas filiais / por dia

Você também pode usar a pergunta de quais filtros o usuário gostaria de ter naquela visão.

Por que filtros?

Imagina que você tem uma tela com um menuzinho e o usuário pode escolher: eu quero um relatório por produto.

Aí ele clica naquela setinha e tem a lista de todos os produtos. Ele seleciona um deles e mostra um gráfico com as vendas só de tênis, por exemplo.

Esses filtros na maioria dos casos vão ser as dimensões. E embora nem todo filtro seja uma dimensão, podem ser dimensões candidatas, que ainda não foram colocadas no modelo mas são candidatas a se tornar dimensões.

Tabela Dimensão

As dimensões armazenam 3 coisas:

  • A Surrogate Key
  • A Natural Key
  • Os atributos

O quê?

Para ser rápida, a fato só armazena os número brutos. O atributo é o que qualifica as métricas, porque elas jogadas lá na fato sozinhas não servem de nada, não dá para tomar decisão nenhuma.

Os atributos podem ser campos como cidade, estado, país etc.

Quanto às chaves, a Surrogate Key é uma Primary Key na dimensão. É uma chave artificial auto incremental, ou seja, toda vez que ela é chamada, adiciona um número e vai somando.

Já a Natural Key é a Primary Key daquele dado na origem ou legado, é o que você vai usar para identificar de onde aquele dado veio.

 

E o que você precisa saber antes de poder criar essas tabelas

Hierarquia

Hierarquia é o conjunto de atributos que possui uma ordem lógica do maior ao menor nível.

A hierarquia balanceada, que é a mais utilizada, é qualquer classificação que tenha como base as relações entre superiores e dependentes.

Por exemplo, do avô ao neto ou do general ao soldado.

Ela requer sempre uma relação de pai-filho, onde o superior pode ter zero, um ou muitos dependentes, mas os dependentes devem ter um e um único superior.

A hierarquia existe apenas nas dimensões, porque a métrica é só um valor, e quem vai dizer se esse valor está correspondendo a um determinado nível da hierarquia é o atributo.

O comum é existir apenas uma hierarquia por dimensão, mas pode existir múltiplas se for necessário.

 

Grão

O grão, também chamado de detalhe, é o menor nível da hierarquia da dimensão. É a informação base, o menor detalhe da informação.

É extremamente importante entender o que é o grão e como definir ele, porque se for mal planejado, vai acabar com todo o projeto.

Mas o que é esse grão?

Em uma dimensão de tempo, nós podemos ter uma hierarquia com ano, mês e dia. O dia é o menor nível, isso é o grão.

Em uma dimensão com diretoria, gerência, departamento e pessoa, a pessoa é o menor nível de detalhamento.

E por que é tão importante?

Ele é o nível mais atômico, o mais detalhado, e é no nível mais atômico em que será armazenada a informação, sem a oportunidade de “descer” mais um nível.

Imagina que o mês seja meu grão. Nesse caso, só posso contemplar ano e mês. Se depois lá na frente perceber que preciso descer para dia, não vai dar.

Aí precisa mexer em tudo, refazer as cargas e rever todo o modelo, porque o grão parou no mês.

Você precisa identificar qual o menor dado necessário, porque quanto menor for o nível do grão, mais ETL terá para fazer e mais demorado será, então não adianta colocar sempre o menor possível para tentar evitar o erro.

 

E como isso tudo se encontra?

Depois que você definiu suas dimensões, vai fazer um join com a tabela fato. É nesse momento que a Foreign Key da fato vai lá e conecta na Surrogate Key da dimensão.

Fica assim:

Tabela Fato + Tabela Dimensão

Agora você sabe que aquele “200,00”, que é a métrica, pertence ao produto de chave “2” na dimensão de produto.

E assim você vai pegando as Surrogate Keys de todas as dimensões e dando sentido àquela métrica na tabela fato.

É importante você entender todos esses conceitos antes de começar a pôr a mão na massa, pois mesmo utilizando ferramentas, você ainda vai precisar entender a teoria para modelar o Star Schema.

Então primeiro entende bem essa parte que no próximo post vou aprofundar um pouco mais no assunto e trazer um passo a passo para a criação do Data Warehouse.

 

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:

mautic is open source marketing automation