Já estudamos a definição antes, gostaria de falar de dois bancos de dados um relacional OLTP AdventureWorks2017 e o outro Data Warehouse OLAP AdventureWorksDW2017
OLTP AdventureWorks2017
Ambiente relacional evita o consumo de espaço dividindo os dados em tabelas e facilitando a escrita.
Clica com o botão direito em Diagramas de Banco de Dados >> Criar >> Seleciona todas as tabelas >> Adicionar
Observe que o diagrama tem muitas tabelas por consequência muitos joins, diminui a redundância de dados mais a performance não é muito boa. Não é uma boa prática plugar o Power BI direto em um ambiente relacional, caso sua empresa não tenha condições de ter DW exporte os dados para o Excel e conecte o Power Bi.
OLAP
AdventureWorksDW2017
Ambiente analítico desnormaliza os dados em menos tabelas, aumentado o espaço ocupado em disco, mas deixando a leitura mais rápida.
Clica com o botão direito em Diagramas de Banco de Dados >> Criar >> Seleciona todas as tabelas >> Adicionar
Observe que tem poucas tabelas, sendo que esse modelo é Snowflake.
Modelagem Dimensional – Star Schema e Snowflake Schema
Se na modelagem tradicional o foco está na normalização dos dados e no modelo dimensional trabalhamos com dados desnormalizados, quer dizer então que podemos construir o modelo de qualquer maneira? A resposta é não!
Existem tipos ou padrões que devem ser seguidos para garantir que nossa modelagem irá suportar o volume de consultas e permitir a entrega correta de informações.
Os tipos de modelagem são:
Star Schema (Modelo Estrela)
Snowflake Schema (Floco de Neve)
Fact Constellation (Constelação de Fatos), que na verdade é uma mescla entre o Star Schema e o Snowflake Schema e que não vamos nos aprofundar.
O Star Schema é, sem dúvidas, o modelo mais difundido e utilizado na criação de um Data Warehouse (DW). Este foi um modelo proposto por Ralph Kimball com o objetivo de simplificar a visualização dimensional, facilitando a distinção entre as dimensões e aos fatos. Não vamos detalhar os tipos de fatos e dimensões, mas podemos reforçar os conceitos.
Fatos são métricas (algo que pode ser medido ou quantificado) resultantes de um evento do processo de negócio. Ou seja, um acontecimento do negócio, que traz uma métrica (ou medida) associada a ele. Uma tabela Fato armazena as métricas relacionadas a determinado evento, por exemplo, uma fato de Vendas pode armazenar quantidade de itens vendidos, valor dos itens vendidos, entre outras métricas. Já as dimensões representam os contextos para análise de um fato, proporcionando diferentes perspectivas de análise para o usuário e normalmente interpretadas como os “filtros possíveis” para determinada tabela fato.
Se por um lado o Star Schema busca a simplicidade, o Snowflake Schema adiciona complexidade ao modelo, com o objetivo de reduzir a redundância no armazenamento.
Essa complexidade não é apenas em nível de armazenamento, mas também na consulta e extração das informações, pois este modelo tende a aproximar novamente a modelagem dimensional da modelagem utilizada nos sistemas transacionais e isto dificulta o entendimento por parte dos usuários de negócio. Este modelo é considerado também uma decomposição de uma ou mais dimensões que possuem hierarquias, ao contrário do Star Schema, que possui apenas ligações entre fatos e dimensões, neste caso existem ligações entre dimensões.
Lembrando que o Snowflake é mais indicado para ferramentas robustas como Microsoft Analysis Services.
Durante o processo de modelagem dimensional há um ponto que muitos profissionais encontram dificuldades, que é a declaração/definição da granularidade. A granularidade está diretamente ligada na criação das fatos, impactando e definindo o volume de dados a ser armazenado e processado em cada fato. Sendo assim, entendemos que granularidade diz respeito ao nível de detalhamento (Figura 3) dos dados que vamos armazenar em uma determinada fato, onde quanto maior a granularidade, menor o nível de detalhamento e quanto menor a granularidade, maior o nível de detalhamento.
Como exemplo de definição de granularidade podemos utilizar um cenário de vendas de uma loja varejista, onde em uma fato com baixa granularidade teremos o armazenamento de dados de vendas em nível de cupom fiscal, resultando em um grande número de linhas armazenadas, porém possibilitando a visualização individual de cada venda. Já em uma fato determinada com alta granularidade, poderíamos armazenar os dados de vendas consolidados por dia, assim reduziríamos a quantidade de linhas armazenadas na tabela, mas perderíamos a capacidade de ver detalhadamente cada venda. É possível ainda ter os dois cenários dentro do mesmo modelo, onde a fato seria selecionada de acordo com a necessidade da consulta, permitindo assim tornar o modelo mais eficiente.
Após conhecer os principais fundamentos da modelagem dimensional, podemos traçar um pequeno roteiro, onde vamos elencar as quatro principais decisões de negócio que devem ser tomadas durante a modelagem dimensional:
Definição dos processos de negócio;
Declaração/definição da granularidade;
Identificação das Fatos;
Identificação das Dimensões;
Baseados nestes 04 itens citados acima, podemos definir nossa modelagem dimensional e criarmos um DW que atenda às necessidades do negócio e principalmente seja um modelo durável, suportando os níveis de carga e consultas adequadamente por um longo período.
Cada decisão na modelagem dimensional é muito importante e pode impactar o modelo a longo prazo, então antes de sairmos criando tabelas e fazendo cargas de dados, devemos dedicar parte do nosso tempo para esta etapa de definição e identificação, fomentando ainda mais o sucesso do projeto.
Ambientes OLAP e o OLTP
Já estudamos a definição antes, gostaria de falar de dois bancos de dados um relacional OLTP AdventureWorks2017 e o outro Data Warehouse OLAP AdventureWorksDW2017
OLTP AdventureWorks2017 Ambiente relacional evita o consumo de espaço dividindo os dados em tabelas e facilitando a escrita. Clica com o botão direito em Diagramas de Banco de Dados >> Criar >> Seleciona todas as tabelas >> Adicionar
Observe que o diagrama tem muitas tabelas por consequência muitos joins, diminui a redundância de dados mais a performance não é muito boa. Não é uma boa prática plugar o Power BI direto em um ambiente relacional, caso sua empresa não tenha condições de ter DW exporte os dados para o Excel e conecte o Power Bi.
OLAP AdventureWorksDW2017 Ambiente analítico desnormaliza os dados em menos tabelas, aumentado o espaço ocupado em disco, mas deixando a leitura mais rápida. Clica com o botão direito em Diagramas de Banco de Dados >> Criar >> Seleciona todas as tabelas >> Adicionar
Observe que tem poucas tabelas, sendo que esse modelo é Snowflake.
Modelagem Dimensional – Star Schema e Snowflake Schema
Se na modelagem tradicional o foco está na normalização dos dados e no modelo dimensional trabalhamos com dados desnormalizados, quer dizer então que podemos construir o modelo de qualquer maneira? A resposta é não! Existem tipos ou padrões que devem ser seguidos para garantir que nossa modelagem irá suportar o volume de consultas e permitir a entrega correta de informações. Os tipos de modelagem são:
O Star Schema é, sem dúvidas, o modelo mais difundido e utilizado na criação de um Data Warehouse (DW). Este foi um modelo proposto por Ralph Kimball com o objetivo de simplificar a visualização dimensional, facilitando a distinção entre as dimensões e aos fatos. Não vamos detalhar os tipos de fatos e dimensões, mas podemos reforçar os conceitos. Fatos são métricas (algo que pode ser medido ou quantificado) resultantes de um evento do processo de negócio. Ou seja, um acontecimento do negócio, que traz uma métrica (ou medida) associada a ele. Uma tabela Fato armazena as métricas relacionadas a determinado evento, por exemplo, uma fato de Vendas pode armazenar quantidade de itens vendidos, valor dos itens vendidos, entre outras métricas. Já as dimensões representam os contextos para análise de um fato, proporcionando diferentes perspectivas de análise para o usuário e normalmente interpretadas como os “filtros possíveis” para determinada tabela fato.
Se por um lado o Star Schema busca a simplicidade, o Snowflake Schema adiciona complexidade ao modelo, com o objetivo de reduzir a redundância no armazenamento. Essa complexidade não é apenas em nível de armazenamento, mas também na consulta e extração das informações, pois este modelo tende a aproximar novamente a modelagem dimensional da modelagem utilizada nos sistemas transacionais e isto dificulta o entendimento por parte dos usuários de negócio. Este modelo é considerado também uma decomposição de uma ou mais dimensões que possuem hierarquias, ao contrário do Star Schema, que possui apenas ligações entre fatos e dimensões, neste caso existem ligações entre dimensões. Lembrando que o Snowflake é mais indicado para ferramentas robustas como Microsoft Analysis Services.
Durante o processo de modelagem dimensional há um ponto que muitos profissionais encontram dificuldades, que é a declaração/definição da granularidade. A granularidade está diretamente ligada na criação das fatos, impactando e definindo o volume de dados a ser armazenado e processado em cada fato. Sendo assim, entendemos que granularidade diz respeito ao nível de detalhamento (Figura 3) dos dados que vamos armazenar em uma determinada fato, onde quanto maior a granularidade, menor o nível de detalhamento e quanto menor a granularidade, maior o nível de detalhamento.
Como exemplo de definição de granularidade podemos utilizar um cenário de vendas de uma loja varejista, onde em uma fato com baixa granularidade teremos o armazenamento de dados de vendas em nível de cupom fiscal, resultando em um grande número de linhas armazenadas, porém possibilitando a visualização individual de cada venda. Já em uma fato determinada com alta granularidade, poderíamos armazenar os dados de vendas consolidados por dia, assim reduziríamos a quantidade de linhas armazenadas na tabela, mas perderíamos a capacidade de ver detalhadamente cada venda. É possível ainda ter os dois cenários dentro do mesmo modelo, onde a fato seria selecionada de acordo com a necessidade da consulta, permitindo assim tornar o modelo mais eficiente. Após conhecer os principais fundamentos da modelagem dimensional, podemos traçar um pequeno roteiro, onde vamos elencar as quatro principais decisões de negócio que devem ser tomadas durante a modelagem dimensional: