EussouShAd / PowerBI

0 stars 0 forks source link

Conhecendo os ambientes OLAP e o OLTP #26

Open EussouShAd opened 1 year ago

EussouShAd commented 1 year ago

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 image 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. image

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 image Observe que tem poucas tabelas, sendo que esse modelo é Snowflake. image

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.

image

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. image

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. image

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: