Fundamentos e Projeto de Big Data Tema 3 Conceitos básicos de modelagem dimensional de dados

Prévia do material em texto

DESCRIÇÃO
Conceitos do modelo dimensional de dados, tabelas de fatos e dimensões, abordagens do esquema
estrela (star schema) e floco de neve (snowflake schema), processo de modelagem para a construção
do modelo dimensional de dados.
PROPÓSITO
Compreender o objetivo das consultas analíticas em um Data Warehouse, dominar as técnicas e
ferramentas de modelagem dimensional e saber desenvolver modelos de dados para atender às
análises organizacionais de forma simples e rápida são competências esperadas do profissional de
Business Intelligence.
PREPARAÇÃO
O exemplo realizado neste conteúdo foi construído na ferramenta SQL Power Architect, que pode ser
utilizada opcionalmente para acompanhar o exercício e viabilizar ao aluno exercitar seu entendimento da
parte prática. Em relação à dimensão Data, foi utilizada a especificação original de Ralph Kimball, em
planilha disponível para download no website do livro do autor, que contém os comandos SQL para
criação da tabela e as instruções de inserção para popular a dimensão Data. A planilha original em
inglês pode ser baixada aqui.
OBJETIVOS
MÓDULO 1
Definir o modelo dimensional de dados e seus elementos principais: fatos e dimensões
MÓDULO 2
Descrever o processo de modelagem dimensional
INTRODUÇÃO
Em uma organização, existem diferentes níveis de tomada de decisão e, geralmente, os níveis
gerenciais mais altos tomam decisões cruciais para o direcionamento estratégico e a sobrevivência
organizacional. Esses problemas exigem, inclusive, o uso do chamado bom senso, visto que, por vezes,
não existem processos mapeados pela organização, e envolvem cenários complexos, não totalmente
claros, sem procedimentos bem-compreendidos ou predefinidos. Nesse cenário, os sistemas de apoio à
decisão provêm consultas analíticas oriundas de diversas fontes, servindo como apoio na tomada de
decisão.
Devido à sobrecarga informacional dos bancos de dados para Business Intelligence, sob forma de Data
Warehouse (DW)/Data Marts (DM), bastante volumosos por consolidar dados históricos, a análise de
dados requer alto desempenho para prover suporte aos diversos tipos de decisão em tempo hábil.
Nesse contexto, o paradigma do modelo relacional de banco de dados, utilizado largamente em grande
parte dos sistemas transacionais, não performa satisfatoriamente, por ser otimizado para o
processamento de transação.
A abordagem denominada modelagem dimensional faz uso de princípios diferentes do paradigma
relacional, trazendo vantagens para o suporte à decisão, pois facilitam a leitura dos dados,
particularmente dados agregados e na montagem de consultas analíticas.
Neste conteúdo, vamos compreender os principais conceitos da modelagem dimensional e suas
abordagens, bem como realizar, a partir de um cenário de análise, a construção do modelo dimensional
baseado nos requisitos levantados nesse caso hipotético.
MÓDULO 1
 Definir o modelo dimensional de dados e seus elementos principais: fatos e dimensões
LIGANDO OS PONTOS
Você sabe o que é um modelo dimensional? Qual estratégia você adotaria para organizar os
dados de um data warehouse para dar suporte às análises de negócios?
Para respondermos a essas perguntas, vamos analisar algumas situações práticas.
Em vários cenários, tomar decisões pode ser uma tarefa muito complexa. Isso ocorre porque existem
inúmeros fatores que influenciam no resultado, e boa parte deles está fora de nosso controle. Então, ter
uma base de dados confiável é muito importante, pois, com eles, conseguimos ter uma visão mais clara
do que podemos realizar e a que risco estamos expostos.
De fato, ter dados confiáveis é o passo inicial para realizar análises, mas precisamos avançar nesse
processo. Nesse contexto, entra o modelo multidimensional de dados, que organiza os dados de forma a
possibilitar o estudo detalhado de um processo. Há duas formas de realizar a modelagem
multidimensional: modelo estrela e modelo floco de neve.
No modelo estrela, os dados são organizados entre tabelas de dimensão e fato. A tabela fato trata do
processo que estamos analisando. Por exemplo, ela pode se referir ao processo de vendas de uma loja
virtual. É essa tabela que vai nos ajudar a responder perguntas como:
Quais foram os produtos mais vendidos em determinado período?
Existe uma relação forte do aumento de vendas com campanhas promocionais?
Para fornecer dados a essas tabelas fato, usamos as tabelas de dimensão.
O modelo floco de neve também utiliza uma tabela fato, mas com uma estrutura de normalização para
organizar as tabelas de dimensão.
As duas modelagens têm o mesmo objetivo, diferenciando-se entre si apenas na forma como os dados
são organizados. No entanto, a escolha de como fazer essa modelagem não é apenas uma questão de
preferência.
O modelo estrela é indicado quando são feitas poucas atualizações nas tabelas de dimensão, enquanto
o modelo floco de neve deve ser escolhido quando essas atualizações são realizadas frequentemente.
O principal impacto desses modelos está no tempo necessário para atualizar e consultar os dados.
Existem muitas ferramentas de modelagem multidimensional disponíveis no mercado, como: IBM
Cognos, Pentaho BI e Microsoft Analysis Services. Todas elas possuem vantagens e desvantagens. O
ponto mais importante é a qualificação do profissional que vai utilizá-las, pois as suas escolhas é que
farão a diferença para um projeto de modelagem multidimensional ser bem-sucedido.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
3. SUPONHA, AGORA, QUE VOCÊ É O RESPONSÁVEL PELO
DESENVOLVIMENTO DE UM SISTEMA QUE DEVE APOIAR A
DECISÃO DE PARAR OU NÃO EQUIPAMENTOS DE
MINERAÇÃO DE FERRO PARA FAZER MANUTENÇÃO
PREVENTIVA. OS DADOS DE QUE DISPÕE SÃO AQUELES
DOS SISTEMAS DE MANUTENÇÃO E DE MONITORAMENTO
DE CONDIÇÕES GERADOS POR SENSORES DOS
PRÓPRIOS EQUIPAMENTOS. NESSE CENÁRIO, QUAIS
SERIAM SUAS ESTRATÉGIAS PARA DESENVOLVER ESSE
SISTEMA DE APOIO À TOMADA DE DECISÃO?
RESPOSTA
javascript:void(0)
Inicialmente, é necessário ter um conhecimento detalhado do negócio que será modelado, pois o objetivo do
sistema é dar apoio à tomada de decisão. Isso só será possível se a modelagem dos processos for
adequada. Em seguida, é preciso construir um data warehouse que fornecerá dados confiáveis para o
sistema de modelagem multidimensional que será desenvolvido. As tabelas fato devem reproduzir etapas
essenciais do estado dos equipamentos, a fim de que a análise proporcione informações relevantes para a
decisão de parar preventivamente ou não um equipamento para manutenção.
MODELAGEM DIMENSIONAL DE DADOS
A modelagem dimensional, também chamada de multidimensional, é uma técnica que visa organizar
os dados de forma adequada, para facilitar a leitura destes e a montagem das consultas analíticas. Ela
difere da modelagem de dados para sistemas de apoio operacional, que não possuem o objetivo de
gerar consultas analíticas, pois são voltados aos processos transacionais. A principal diferença entre
eles é que o modelo dos sistemas transacionais é normalizado, com restrições de integridade e sem
redundância de dados, enquanto o modelo dimensional não é rígido nesse aspecto, e pode se
apresentar desnormalizado, composto por tabelas dimensão e tabelas fato, com redundância de dados
A normalização em uma base de dados visa eliminar ou reduzir a redundância de dados, manter a
integridade destes e reduzir o espaço de armazenamento.
O objetivo é diminuir problemas durante a inserção, exclusão e alteração dos registros nas tabelas e
facilitar a manutenção dos dados. Já um modelo dimensional não tem essas preocupações, pois seu
foco principal é responder as consultas analíticas de forma rápida e com eficiência.
No modelo desnormalizado, os dados nas tabelas de dimensões podem se repetir, porque não são
sujeitos a mudanças frequentes. Essa abordagem ocupa mais espaço de armazenamento, mas
responde de forma mais rápida às consultas, por evitar as operações de junção dastabelas de
dimensões com a tabela de fato.
A imagem a seguir ilustra um exemplo de dimensão Produto com tabelas normalizadas e tabela
desnormalizada.
 ATENÇÃO
Nas tabelas normalizadas, os dados da Categoria do Produto estão em uma tabela separada dos
dados do Produto, visando evitar redundância de dados.
 Esquema normalizado x desnormalizado.
A tabela Categoria do Produto é composta pelos campos de identificação da categoria e descrição da
categoria. O campo SK Categoria é o campo de identificação das categorias e ele é o campo de ligação
com a tabela Produto.
No exemplo de tabela desnormalizada, a descrição da categoria está contida na tabela Produto,
dispensando a tabela Categoria do Produto e gerando, em consequência, redundância dos dados de
descrição da categoria (e outros dados próprios da categoria) para todo produto pertencente à mesma
categoria.
Por estarem todos os dados em uma única tabela Produto, evita-se a junção entre tabelas, melhorando
o desempenho das consultas que envolvam categorias de produtos.
Por outro lado, a tabela Produto ocupará mais espaço de armazenamento e estará sujeita a anomalias
de atualização que ocorrem em tabelas desnormalizadas.
Como a frequência de mudanças nas tabelas de dimensão é baixa (no exemplo, é rara a mudança de
categoria de um produto), essa desvantagem é largamente compensada pela melhoria no desempenho
das consultas.
 COMENTÁRIO
Note que as soluções de tabela Produto desnormalizada ou de normalização em tabelas Categoria e
Produto não são as únicas modelagens possíveis para a dimensão Produto. Dependendo das análises
requeridas pelo negócio, a melhor alternativa talvez seja considerar Categoria e Produto como
dimensões separadas que não se relacionam diretamente, mas através de suas ligações com os fatos
registrados na tabela de fatos, como se verá ao longo deste conteúdo.
A seguir, será apresentada a metodologia 5W3H, que tem por objetivo auxiliar na identificação das
tabelas do modelo dimensional.
5W3H − IDENTIFICANDO AS TABELAS DO
MODELO DIMENSIONAL DE DADOS
A metodologia 5W3H é uma técnica gerencial, que tem por objetivo auxiliar na modelagem de processos
de negócios de maneira fácil e organizada, reconhecendo as ações, definindo responsabilidades,
métodos de execuções, prazos e recursos associados.
No contexto de Business Intelligence, é usada no mapeamento de atividades organizacionais e auxilia o
entendimento e a identificação das tabelas do modelo dimensional de dados.
 5W3H − Esquema estrela (star schema).
Como observado na imagem anterior, no centro do desenho estão as perguntas que tratam os dados
mensuráveis (How many?/How much?), no modelo dimensional, representados pela tabela fato, que
responderá, por exemplo, quantos produtos foram vendidos e por qual valor.
As perguntas ao redor da tabela fato auxiliam a identificação das tabelas dimensões, que fornecem
descrições do fato ocorrido:
WHEN – QUANDO?
Sugere a dimensão temporal muito utilizada em DW/DM, por tratar de dados históricos (por exemplo, a
data de uma venda).
WHERE – ONDE?
Sugere a dimensão espacial, descrevendo o local onde aconteceu o fato (por exemplo, em qual loja
ocorreu uma venda).
WHAT – O QUÊ?
Sugere a dimensão objetiva, descrevendo o objeto do fato ocorrido (por exemplo, qual produto foi
vendido).
WHO – QUEM?
Sugere a dimensão subjetiva, descrevendo o(s) sujeito(s) que participou(aram) do fato (por exemplo, o
cliente que comprou o produto ou o vendedor que realizou a venda).
WHY – POR QUÊ?
Sugere a dimensão causal, explicando o motivo pelo qual o fato ocorreu (por exemplo, porque o cliente
comprou o produto).
HOW – COMO?
Sugere a dimensão formal, explicando a forma pela qual o fato ocorreu (por exemplo, como foi feito o
pagamento pela venda).
O desenho em forma de estrela, com o fato no centro e as dimensões nas pontas, originou a
denominação dos tipos mais usuais de esquemas do modelo dimensional:
Estrela (star schema);
Floco de neve (snowflake schema).
Os tipos de dimensão mais comuns na modelagem dimensional são:
WHAT (O QUÊ)
WHEN (QUANDO)
WHERE (ONDE)
WHO (QUEM)
ESQUEMA ESTRELA (STAR SCHEMA)
Neste esquema, como podemos observar nas imagens anteriores, temos no centro os dados
mensuráveis, contidos na tabela fato, e, ao redor, são organizadas as tabelas dimensão.
Simplificadamente, podemos definir que as dimensões descrevem ou explicam os fatos ocorridos. Essas
dimensões podem representar hierarquia de dados e, no esquema estrela, essa hierarquia fica contida
na tabela de dimensão, deixando os dados desnormalizados, à custa de redundância de dados,
conforme foi apresentado na imagem Esquema Normalizado x Desnormalizado.
ESQUEMA FLOCO DE NEVE (SNOWFLAKE SCHEMA)
O esquema floco de neve é uma derivação do esquema estrela, e apresenta as tabelas dimensões em
hierarquia. Nesse esquema, os dados ficam normalizados, evitando redundância nas dimensões e
problemas de integridade de dados.
A imagem a seguir ilustra genericamente o esquema floco de neve, no qual as dimensões 2 e 3 estão
ligadas à dimensão 1.
 Esquema floco de neve (snowflake schema).
A recuperação dos dados no esquema floco de neve é mais custosa para a montagem das consultas,
em tempo de processamento, pois a quantidade de junções resultantes dos relacionamentos entre as
dimensões é maior. Além disso, pode dificultar o entendimento do usuário e a implementação das
consultas nas ferramentas de análise OLAP (do inglês On Line Analytical Processing ou Processamento
Analítico On-line).
 COMENTÁRIO
Como mencionado anteriormente, a desnormalização pode ocasionar problemas na integridade dos
dados decorrentes da redundância na tabela de dimensões. No entanto, o esquema estrela apresenta
maior velocidade na recuperação dos dados, facilitando o entendimento do usuário e a montagem das
consultas.
Há, ainda, modelos que utilizam a combinação dos dois esquemas, de forma a aplicar os benefícios que
cada um oferece e elaborar a melhor solução para as necessidades de análise da organização.
Nesses casos, cabe um estudo sobre o trade-off que existe entre:
Normalizar
Quando a frequência de atualizações da tabela de dimensão for alta.
OU
Desnormalizar
Quando essa frequência for baixa.
Esse trade-off deve ser resolvido mediante a comparação dos tempos de processamento de consulta
com a tabela de dimensão normalizada ou desnormalizada. Assim, algumas dimensões serão
normalizadas, adotando o esquema floco de neve, enquanto outras serão desnormalizadas, adotando o
esquema estrela.
 DICA
Uma tabela de dimensão que não deve ser normalizada é a tabela de Data, pois os dados descritivos de
uma data (dia da semana, do mês, do trimestre, do semestre, do ano etc.), assim como outros dados
específicos (feriados, datas festivas etc.), são praticamente imutáveis e pouco sujeitos a alterações.
Como vimos, tanto no esquema estrela quanto no esquema floco de neve, o modelo dimensional
organiza os dados em tabelas dimensão e tabelas fato. Uma forma de organização em um modelo
dimensional que facilita a visualização é a representação como um cubo de dados (ou hipercubos, pois
podem ter número ilimitado de dimensões). Neles, as dimensões estão localizadas nos eixos do cubo, e
as medidas, contidas na tabela fato, estão localizadas na interseção das dimensões.
 Representação de fatos e dimensões em cubo.
A organização dos dados em um modelo dimensional visto como um cubo permite realizar consultas
sobre um fato por diversas visões.
 EXEMPLO
A quantidade de um determinado produto, vendido para um determinado cliente, em uma determinada
data.
No próximo módulo, vamos estudar esses dois tipos de tabelas, conhecer sua estrutura e entender
como ocorre sua implementação no modelo dimensional de dados.
O MODELO DIMENSIONAL DE DADOS
No vídeo a seguir, o especialista apresentará conceito de modelo dimensional, os esquemas estrela e
snowflake, além das principais diferenças ao modelo transacional.
VERIFICANDOO APRENDIZADO
MÓDULO 2
 Descrever o processo de modelagem dimensional
LIGANDO OS PONTOS
Você sabe como funciona o processo de modelagem dimensional? Como as escolhas desse
processo impactam na utilização prática de um modelo multidimensional de dados?
Para entendermos esse conceito na prática, vamos analisar uma situação.
Não há dúvidas sobre os benefícios que a modelagem multidimensional pode gerar para os negócios
das empresas dos diversos setores da sociedade. Muitas dessas empresas, inclusive, já têm a cultura
de utilizar esses modelos em seu cotidiano. No entanto, ainda há algumas empresas que não adotaram
a prática de aplicar técnicas de BI para realizar a análise de negócios, mas que querem passar a usá-
las. Nesse caso, é natural a pergunta: por onde começar a estruturar um sistema de modelagem
multidimensional?
Antes de tudo, é fundamental entender que a modelagem multidimensional é um instrumento para
auxiliar a obtenção de melhores resultados mais rapidamente. Mas ela não substitui os projetistas do
sistema nem mesmo os profissionais que vão utilizá-la no dia a dia para realizar análises. Portanto, é
essencial contar com mão de obra qualificada, que tenha domínio teórico e prático de técnicas e
ferramentas de análise, além de ter conhecimento do negócio em si.
Um sistema multidimensional de dados inicia com a determinação das metas que se pretende atingir.
Por exemplo:
Que estratégias devem ser adotadas para aumentar as vendas de determinado produto?
Como reduzir o tempo em que os equipamentos ficam fora de operação?
Como aumentar a velocidade de entrega de funcionalidades dos produtos de uma fábrica de
software?
Após a determinação dos objetivos, vem a construção das tabelas fato e dimensionais, que têm como
propósito fornecer subsídios para atingir os objetivos preestabelecidos na etapa anterior. No processo de
construção dessas tabelas, utilizamos os dados que estão no data warehouse. Às vezes, precisamos
submetê-los a um processo de ETL, para que fiquem em um formato que nos permita utilizá-los.
Tudo isso envolve tempo e muito estudo, e é natural que algumas etapas sejam revistas. É por isso que
a utilização de metodologias ágeis é muito bem-vinda, pois reduzem as chances de necessidade de
fazer grandes correções na etapa final do projeto e de realizar entregas gradualmente.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
3. CONSIDERE O SEGUINTE CENÁRIO: VOCÊ É O
RESPONSÁVEL POR FAZER A MODELAGEM
MULTIDIMENSIONAL DE UM SISTEMA DE MONITORAMENTO
DE EQUIPAMENTOS DE PERFURAÇÃO DE POÇOS DE
PETRÓLEO. ESSES EQUIPAMENTOS SÃO MUITO CAROS, E
É MUITO DIFÍCIL SUBSTITUÍ-LOS. POR ISSO, A
MANUTENÇÃO DELES PRECISA SER REALIZADA COM
EXCELÊNCIA. NESSE CONTEXTO, QUE ESTRATÉGIA VOCÊ
ADOTARIA PARA FAZER A MODELAGEM
MULTIDIMENSIONAL DO SISTEMA?
RESPOSTA
A primeira etapa a ser cumprida é determinar o objetivo principal do sistema: garantir que a manutenção seja
realizada com grande qualidade. Equipamentos de grande porte já têm um processo de manutenção
preventiva estabelecido pelos fabricantes, mas, dependendo da utilização durante a operação deles, pode
ser necessário reduzir a periodicidade com que devem passar por manutenções. Portanto, é fundamental
mapear todas as fontes de dados que forneçam informações sobre as condições dos equipamentos, para
javascript:void(0)
que sejam agregadas no data warehouse e, posteriormente, alimentem as tabelas multidimensionais do
sistema. Dessa forma, os analistas poderão observar detalhadamente o estado dos equipamentos e estudar
a necessidade de aplicar manutenções preventivas antes da ocorrência de uma situação que envolva grande
risco.
TABELAS DIMENSÃO
As dimensões são tabelas que armazenam os elementos textuais que descrevem os fatos ocorridos.
Elas respondem às perguntas: O quê?; Quem?; Quando?; Onde?; entre outros.
 EXEMPLO
Fato ocorrido: venda do produto.
O que foi comprado? Resposta: O produto leite em pó.
Quem comprou esse produto? Resposta: O cliente José.
Quando o produto foi comprado? Resposta: No dia 14/05/2020.
Onde o produto foi comprado? Resposta: Na loja do bairro Centro da cidade do Rio de Janeiro.
A tabela dimensão possui uma coluna que identifica um elemento univocamente na tabela. Essa coluna
é a chave primária (PK – primary key), também conhecida como surrogate key (SK) ou chave artificial,
do tipo numérico e normalmente preenchida por um número sequencial incremental (tipo inteiro de 4
bytes).
 ATENÇÃO
Note que o inteiro de 4 bytes possui limite superior de +2.147.483.647, número mais do que suficiente
para conter a quantidade de linhas das tabelas de dimensão usuais − não é razoável se pensar em uma
dimensão contendo mais de 2 bilhões de produtos ou clientes.
Para dimensões com poucas ocorrências, por questão de economia de espaço, principalmente na tabela
de fato, pode-se optar por usar o tipo smallint ou equivalente, com 2 bytes, que possui limite superior de
+32.767. Isso pode se aplicar, por exemplo, para dimensões como lojas ou departamentos.
A chave primária da tabela de dimensão serve como a ligação entre a dimensão e a tabela fato.
 Exemplo da tabela dimensão Produto.
A imagem anterior ilustra a dimensão Produto, na qual a coluna "SK Produto" é a chave da dimensão,
"Codigo Produto" é o código do produto no sistema origem, "Descricao Produto" é a descrição do
produto (nome) e "Descricao Fabricante" é o nome do fabricante.
Caso a modelagem fosse normalizada, a coluna "Descricao Fabricante" daria lugar à coluna "SK
Fabricante", representando a chave primária da "Dimensão Fabricante".
De acordo com Kimball (2013), as dimensões são tabelas geralmente largas, isto é, com várias colunas,
planas e desnormalizadas, com muitos atributos de texto de baixa cardinalidade. Isso porque a
dimensão pode conter diversas colunas descritivas, baixa quantidade de registros, colunas que agrupam
os elementos da tabela e colunas com pouca variação no seu conteúdo. Mas, apesar de largas, as
dimensões são tabelas curtas, isto é, possuem poucas linhas − raramente chegando à casa dos milhões
−, se comparadas às tabelas fato, que podem chegar à casa dos bilhões.
 COMENTÁRIO
Imagine o DW de uma rede gigantesca de lojas de varejo, com fatos de vendas de cada produto, em
cada loja, ao longo de décadas de histórico das vendas!
As colunas da tabela dimensão são chamadas de atributos.
 EXEMPLO
Na dimensão Produto, há 4 atributos além da chave primária SK Produto. Esta identifica um elemento na
dimensão e se relaciona com a tabela fato.
A relação da dimensão com a tabela fato é do tipo um para muitos, ou seja, um elemento da dimensão
Produto pode estar ligado a N (vários) registros da tabela fato.
Os elementos contidos nas dimensões qualificam as consultas, agrupam e sumarizam os fatos contidos
na tabela fato. Os elementos atuam como filtros, consolidando milhares de linhas da tabela fato em
algumas linhas.
 EXEMPLO
A tabela fato Vendas possui 2 milhões de linhas, que detalham as vendas dos produtos no ano de 2019.
Uma consulta para exibir o valor de produtos vendidos por mês no ano de 2019 apresentará apenas 12
linhas, uma para cada mês.
Assim, as dimensões apresentam maior ou menor detalhe dos dados nas consultas em que são
utilizadas. Esse movimento é realizado pelas operações de análise sobre os dados. Por exemplo: drill
down, quando detalhamos o dado; e drill up ou roll up, quando agregamos o dado.
 Exemplo de operações de drill up e drill down.
Conforme ilustrado na figura anterior, as operações de drill down e drill up podem ser observadas em
hierarquias de atributos, nas quais um atributo pode ser agrupado por outro. Por exemplo, os produtos
podem ser agrupados em categorias de produtos, no qual o produto sabonete faz parte da categoria
Higiene.
Com a hierarquia de atributos da visão de datas, podemos realizar a operação de drill down, detalhando
a venda de produtos por dia, ou agrupar os dados, aplicandoa operação drill up. O relatório apresenta
os sabonetes vendidos por mês, o drill up realizado para o ano e o drill down realizado para o dia.
TABELAS FATOS
As tabelas fatos ficam no centro do modelo dimensional de dados e se relacionam com no mínimo duas
tabelas dimensões.
As tabelas armazenam as medidas/métricas dos fatos ocorridos que são descritos pelas dimensões.
As chaves primárias das tabelas dimensão são adicionadas na tabela fato como chaves estrangeiras, e
a combinação delas forma a identificação dos registros (chave primária) na tabela fato.
As colunas que representam as chaves das tabelas dimensão são numéricas, como já foi visto (inteiros
de 2 ou 4 bytes), e as colunas que representam as medidas/métricas, também chamadas de fatos, são,
em geral, também do tipo numérico, representando quantidades ou valores que respondem a questões
do tipo “Quanto?”.
Em algumas situações, colunas de outros tipos podem estar na tabela fato para resolver questões
pontuais do negócio − por exemplo, um dado alfanumérico representando um objeto do sistema
transacional, como uma nota fiscal, denominado de dimensão degenerada, por não haver uma tabela de
dimensão correspondente.
A tabela fato possui muitas linhas, que são agregadas pelos atributos das dimensões. Ela pode conter
medidas aditivas, semiaditivas e não aditivas.
Os fatos aditivos são dados numéricos que podem ser sumarizados por todas as visões do DW/DM
que fazem parte do contexto da tabela fato sob a forma de tabelas de dimensões. Por exemplo, a
Quantidade Vendida de Produtos pode ser somada pelas dimensões Produto, Data, Loja.
Os fatos semiaditivos são também dados numéricos, mas não podem ser somados por todas as visões
do DW/DM, devido à sua semântica. Por exemplo, a quantidade em estoque de um produto pode ser
somada pela dimensão Loja (estoque de um determinado produto em várias lojas), mas não faz sentido
se somarmos o estoque pela dimensão Data (Data do Estoque).
Os fatos não aditivos são dados que, mesmo sendo numéricos, não podem ser sumarizados pelas
visões do DW/DM. Por exemplo, uma coluna que contenha o percentual de desconto oferecido aos
clientes.
Além desses três tipos, temos a medida derivada. Ela é calculada com base em outras medidas
contidas na tabela fato. Como exemplo, o lucro de um produto vendido, em que pode haver uma medida
calculada com base nas medidas Preço do Produto Vendido e Preço do Produto Comprado do
Fabricante.
O GRÃO DO FATO
Durante a fase de levantamento de requisitos, devemos levar em consideração a matriz de
granularidade, que ajuda a identificar o grão em que as medidas serão armazenadas na tabela fato.
 ATENÇÃO
Esse grão é muito importante para a agregação e apresentação dos dados; em outras palavras, o grão
de uma tabela fato representa o quão detalhado está o dado naquela tabela.
O grão atômico é referente ao dado no nível mais baixo extraído do sistema transacional.
Quanto mais baixo o nível de granularidade dos dados, mais detalhado será o dado, e isso pode garantir
que as perguntas feitas pelo usuário serão respondidas. Por exemplo, na visão de data, temos
informado que as medidas de quantidade de produtos vendidos e o valor da venda podem ser
analisadas no grão dia, de uma hierarquia que possui dia, mês e ano.
 ATENÇÃO
É importante que os fatos contidos em uma tabela fato estejam no mesmo nível de granularidade.
Durante o levantamento de requisitos, vimos que a quantidade de produtos vendidos está no grão dia, e
que a quantidade de produtos comprados do fabricante está no grão mês. Isso significa que só será
possível avaliar as duas medidas pelo grão mínimo mês. Logo, essas duas medidas não podem estar
em uma mesma tabela fato.
TIPOS DE TABELA FATO
A partir do entendimento da importância do grão do fato, podemos elencar os tipos de tabelas fato
possíveis.
A tabela fato transacional é a mais comum no DW/DM. Ela armazena o nível mais detalhado do fato,
considerando o grão definido para a tabela fato. O dado é extraído do sistema de origem no nível de
detalhe estabelecido e é carregado na tabela fato. É importante observar que, quanto mais detalhado for
o dado, mais linhas serão armazenadas na tabela fato. Um exemplo típico é a tabela que registra cada
venda de produto por filial, por vendedor, por dia.
A tabela de snapshot periódico registra dados em um período predefinido; por exemplo: diariamente,
semanalmente ou mensalmente. É uma fotografia da tabela de fato transacional em um período a ser
capturado. Um exemplo típico é a tabela que registra o estoque corrente de cada produto por dia, por
filial.
A tabela de snapshot acumulado descreve um processo de negócios com data de início, datas de
marco intermediário e data de fim. A cada etapa concluída, o registro sofre atualização para adicionar o
novo marco. Um exemplo típico é a tabela que registra o processo de recebimento, inspeção,
armazenagem e liberação para venda de produtos em cada armazém ou depósito.
A tabela fato agregada representa um nível de granularidade mais elevado. Os dados são sumarizados
pelas visões do contexto, diminuindo a quantidade de linhas na tabela e, às vezes, diminuindo a
quantidade de dimensões relacionadas à tabela fato. O objetivo de tabelas agregadas é oferecer
análises mais rápidas para visões com um objetivo mais específico. Por exemplo, volume de vendas por
mês, por filial, por produto. O menor nível de análise será o mês. Caso seja necessário avaliar um
determinado dia do mês, a análise deve ser submetida à tabela fato transacional, que é mais detalhada.
Nos sistemas de banco de dados, o recurso usado para criar a tabela fato agregada é a visão (VIEW),
que nada mais é do que uma consulta à tabela fato transacional realizando a sumarização desejada. Um
trade-off que existe no projeto de DW/DM é a decisão sobre armazenar ou não o resultado da visão, ou
seja, materializar ou não a consulta criada com a VIEW como uma nova tabela no banco de dados. Note
que o conteúdo da tabela fato agregada pode depender do momento da execução da VIEW sobre a
tabela fato transacional. Isso significa que, nesses casos, quando houver a atualização da tabela fato
transacional com a inserção de novos fatos, a tabela fato agregada pode se tornar obsoleta, requerendo
uma nova execução da VIEW para recriar a tabela. A decisão sobre armazenar ou não a tabela fato
agregada dependerá de estudo de desempenho do sistema quanto ao espaço de armazenamento
necessário (que pode ser exponencial) e ao tempo de execução da reorganização do banco de dados
sempre que uma recarga das tabelas fato transacionais ocorrerem no sistema.
A tabela fato sem fato é chamada dessa forma porque ela não possui uma coluna contendo medida do
fato. Ela estabelece a relação entre dimensões que respondem a uma determinada análise de
ocorrência de evento. Um exemplo é a tabela que registra matrículas de alunos em turmas de disciplinas
de um curso ministradas por um determinado professor, com a finalidade de contagem do tamanho da
turma, para viabilizar uma oferta.
INICIANDO A MODELAGEM DIMENSIONAL DE
DADOS
Agora que você está familiarizado com os termos utilizados, é hora de organizar as etapas para a
construção do modelo dimensional de dados.
Olhando o ciclo de vida de um projeto de DW, na figura a seguir, vemos que o modelo dimensional de
dados está na trilha central, que é realizada após o levantamento de requisitos do negócio. Essa trilha
se dedica ao tratamento dos dados e encadeia as fases modelagem dimensional, a definição do projeto
físico e a especificação de ETL. Com base nas informações documentadas nas fases de levantamento
de requisitos e mapeamento das fontes de dados, o modelo dimensional pode ser construído.
 Ciclo de vida de um projeto de Data Warehouse.
CENÁRIO DE ANÁLISE
Durante o processo de análise de um supermercado, foram identificados os requisitos de negócio.
As análises desejadas são:
Quais são os produtos mais vendidos no verão?
Quais sãoos clientes com maior potencial de compras em uma determinada categoria de produtos?
O estoque fica zerado em quais lojas?
Quais são os fabricantes dos produtos que oferecem maior lucro na comercialização dos seus itens?
As visões ou dimensões de análise são:
Produto (referente a qual produto
Categoria do produto (referente a qual grupo de produto)
Fabricante do produto (referente a qual fabricante)
Cliente (referente a quais clientes)
Data (referente a quando foi realizada a venda, quando foi comprado do fabricante e as vendas
ocorridas durante o verão)
Os assuntos são:
Vendas de produtos
Estoque de produtos
As medidas são:
Quantidade de produtos vendidos
Quantidade de produto no estoque
Preço do produto vendido
Preço do produto comprado do fabricante
Lucro do produto vendido
Ainda sobre o modelo de dados, ele pode ser divido em três momentos:
MODELO CONCEITUAL
Que representa o entendimento sobre o negócio e o relacionamento entre as tabelas.
MODELO DE DADOS LÓGICO
Que considera algumas restrições, o padrão e a nomenclatura, chaves primárias e estrangeiras, entre
outros.
MODELO FÍSICO
Que considera os padrões do SGBD escolhido.
MODELO DIMENSIONAL DE DADOS
A concepção do modelo dimensional de dados reúne os requisitos levantados e os organiza por assunto,
desenhando as dimensões e a tabela fato que expressa o relacionamento entre elas.
 COMENTÁRIO
O esquema estrela facilita o entendimento para todos os envolvidos no projeto, principalmente para os
usuários do negócio, devido a sua simplicidade.
javascript:void(0)
javascript:void(0)
javascript:void(0)
O modelo dimensional pode ser desenhado de maneira inicial e mais abstrata na fase de levantamento
de requisitos, com o objetivo de auxiliar a compreensão sobre o negócio e facilitar o entendimento da
relação que os dados possuem. Utiliza as técnicas de modelagem de dados − que envolve entidades,
atributos, relacionamentos, cardinalidade etc. − e o conhecimento dos requisitos identificados na fase de
levantamento de requisitos para a construção do Data Warehouse.
Com a união desses conhecimentos, podemos elaborar o modelo dimensional do assunto Vendas de
Produtos.
As visões listadas no cenário de análise serão as dimensões do modelo:
Produto;
Categoria do produto;
Fabricante do produto;
Cliente;
Data.
A visão Produto no sistema origem contém os dados Código do Produto, a descrição do Produto, o
nome do Fabricante do Produto, a descrição da Categoria do Produto, o Código de Barras do Produto e
a Data de Validade do Produto. No entanto, conforme o levantamento realizado, os dados necessários
para as análises são: Código do Produto, Descrição do Produto, o nome do Fabricante do Produto e a
descrição da Categoria do Produto. Logo, somente esses dados serão adicionados na dimensão
Produto.
Como visto anteriormente, podemos modelar a visão Produto de forma normalizada e desnormalizada. A
imagem a seguir ilustra a modelagem normalizada para as visões Produto e Categoria:
 Esquema normalizado das tabelas Categoria e Produto.
A leitura da cardinalidade na notação da imagem anterior, de acordo com a definição do modelo
entidades e relacionamentos, é a seguinte:
Uma categoria pode não ter produtos ou pode ter vários produtos.
Um produto pode estar ligado a apenas uma categoria e deve sempre estar ligado a uma categoria.
A ferramenta utilizada para fazer o modelo representa a relação pela linha que liga as duas tabelas. Isso
significa que, durante o desenvolvimento do processo de carga, essas críticas precisam ser validadas.
Outras soluções para esse relacionamento podem ser aplicadas colocando a descrição da Categoria
dentro da visão Produto, ou, ainda, ligar a dimensão Categoria do Produto diretamente na tabela fato.
Segundo Kimball (2013), a dimensão Data é uma dimensão especial, por sua presença nos modelos
dimensionais ser quase certa, em razão do DW ser um banco de dados históricos. Isso se deve ao fato
de a maioria das análises estarem relacionadas ao tempo. Em projetos modernos, a dimensão Data
utiliza a chave primária com a formação de ano, mês e dia (YYYYMMDD), que garante unicidade e
sequência.
 VOCÊ SABIA
Antigamente, no início da modelagem dimensional, eram utilizadas as chaves surrogate key como
identificador da tabela de tempo.
A dimensão Data pode ser criada de forma prévia, pois sua natureza independe de dados de sistemas
origens. A dimensão possui um conjunto de atributos que atende a várias necessidades, mas você pode
adicionar novos atributos de acordo com o projeto a ser desenvolvido.
Vamos utilizar a dimensão Data definida por Kimball (2013) em nossos exercícios, descrita na fase de
preparação deste tema. Você poderá adicionar a tabela ao modelo dimensional de dados ou deixar para
criar e relacionar com a tabela fato após a implementação do modelo físico.
Depois de conhecer as vantagens e desvantagens dos tipos de modelagens, você pode escolher qual se
encaixa melhor na solução que está construindo.
Vamos praticar? Construa a modelagem das visões contidas no levantamento.
 ATENÇÃO
Não esqueça de incluir as visões Produto, Categoria e Fabricante!
IMPLEMENTANDO O MODELO DIMENSIONAL
DE VENDAS A VAREJO
Acompanhe no vídeo o especialista implementar o modelo dimensional apresentado no cenário de
análise, utilizando a ferramenta SQL Power Architect.
A imagem a seguir demonstra o resultado esperado. Após o desenho das dimensões, devemos
acrescentar a tabela fato ao modelo.
Para a tabela fato Vendas, devem ser consideradas as medidas do assunto Vendas, e as dimensões
devem ser ligadas a ela. A tabela fato conterá as medidas Quantidade de Produtos Vendidos e Preço do
Produto Vendido.
 Esquema dimensional (estrela) de Vendas a Varejo.
Note que a solução adotada no esquema estrela da imagem anterior considerou a separação das
dimensões Categoria e Produto, que se relacionam por meio do fato Vendas.
Outra solução possível seria considerar os dados de Categoria como atributos de Produto; neste caso,
apenas a tabela Produto seria uma dimensão relacionada à tabela fato, estando os dados sobre
Categoria embutidos na tabela de dimensão Produto desnormalizada.
VERIFICANDO O APRENDIZADO
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Ao longo deste conteúdo, trabalhamos os conceitos de modelagem dimensional de dados e os
esquemas estrela e floco de neve. Em seguida, vimos a noção de grão, muito importante para definir o
nível de detalhamento dos dados, além de fundamentos essenciais para a construção das tabelas
dimensão e fato.
Por fim, compreendemos o processo de modelagem conceitual dos dados e realizamos a construção do
modelo dimensional de dados, utilizando a ferramenta SQL Power Architect.
 PODCAST
Muito bem! Estamos encerrando o tema conceitos básicos de modelagem dimensional de dados, mas
antes de finalizar, ouça o podcast que preparamos sobre o assunto.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
BARBIERI, C. BI2 Business Intelligence: modelagem e qualidade. 1. ed. Rio de Janeiro: Elsevier,
2011.
KIMBALL R.; ROSS, M. The Data Warehouse toolkit: the definitive guide to dimensional modeling. 3.
ed. Nova Jersey: John Wiley & Sons, 2013.
KIMBALL R.; ROSS, M. The Kimball Group Reader: remastered edition. Nova Jersey: John Wiley &
Sons, 2016.
NAVATHE, S. B.; ELMASRI, R. Sistemas de banco de dados. 6. ed. São Paulo: Pearson Addison
Wesley, 2011.
PITON, R. Data Warehouse passo a passo: o guia prático de como construir um Data Warehouse do
zero. Porto Alegre: Raizzer, 2018.
SANTOS, V. G. Arquitetura de Data Warehouse e Data Marts. Rio de Janeiro: YDUQS, 2020.
EXPLORE+
Para saber mais sobre os assuntos tratados neste conteúdo, procure na internet e leia o artigo:
Tabela Dimensão: os 5 tipos que você deve conhecer, de Rafael Piton.
Explore as ferramentas disponíveis na internet:
Aplicativo IBM Rational Rose.
Dbdesigner.
brModelo.
MySQL Workbench.
SQL Power Architect Community Edition.
Pesquise na internet:
As referências a artigos e dicas de projetodo site do Kimball Group.
CONTEUDISTA
Conteúdo original: Vivian Gabriela Santos Monteiro
Adaptação e conversão: Antonio Felipe Podgorski Bezerra