Aprofundando em Data Warehouse…
Olá pessoal!
Esse artigo tem como objetivo dá uma visão geral sobre Data Warehouse que é, vamos assim dizer, a base para o Business Intelligence tradicional… iremos apresentar alguns conceitos e técnicas utilizadas no dia a dia… mas antes disso, vamos comentar um pouco sobre BI (Business Intelligence).
#Dica1 — Power BI, Tableau… não são BI. BI é conceito, não é ferramenta…
O que é Business Intelligence?
Termo usado para descrever decisões gerenciais tomadas com base em evidências e fatos (dados).
Outra definição para BI: é responsável por utilizar estrategicamente dados nas organizações a partir da coleta, tratamento e análise de todo e qualquer tipo de informação relevante, possibilitando as melhores decisões para os negócios.
A figura acima, mostra que BI é um conceito bem amplo, rodeado por vários outros conceitos e técnicas mais específicos, vamos assim dizer.
Abrindo um parêntese (em relação a #Dica1): O Power BI, Tableau entram no conceito específico na imagem acima denominado: Self-service BI
Business Intelligence, não é APENAS uma visualização com efeitos e animações, mas é também… Dados com qualidade (dados consistentes, completos, padronizados, com precisão numérica…), que tenham um Catálogo de dados e com um Data Warehouse (modelagem multidimensional — fato | dimensões) bem feito e documentado… Tudo isso visando atender a necessidade dos tomadores de decisões, gerando análises e insights que realmente agregam valor ao negócio.
Dashboards bonitos, cheios de animações, cores e etc, se não geram valor ao negócio, é simplesmente uma métrica de vaidade.
Os dashboards oferecem exibições visuais de importantes informações consolidadas e organizadas numa única tela, para que possam ser digeridas num simples relance e facilmente exploradas e aprofundadas.
Data Warehousing
Um Data warehouse (armazém de dados) é uma coleção de dados produzidos para embasar a tomada de decisões; trata-se também de um repositório central de dados históricos e correntes de potencial interesse para gestores de toda a organização.
Data Warehouse é como um banco de dados relacional projetado e otimizado para necessidades analíticas (OLAP).
Data Warehousing é o ato de organizar e armazenar dados de forma a tornar sua recuperação eficiente e perspicaz. Também é chamado de processo de transformação de dados em informações.
Tem como explicar essa imagem ai?
Sim, tem como… vamos lá…
Data Sources, são as múltiplas fontes de dados que temos em nossa organização, podem ser banco de dados (on-premise ou em cloud), planilhas e etc, esses dados são Extraídos, Transformados e Carregados (ETL) para um repositório temporário chamado ODS (Operational Data Store, por muitos também chamado de Stage area)e em seguida é realizado todo o processo e aplicação de técnicas da Modelagem Dimensional (OLAP) para criar as tabelas otimizadas para análise no Data Warehouse (os Data Warehouse (DW), podem ser divididos em Data Marts, uma espécie de DW setorial) e por último, os usuários utilizam esse Data Warehouse ou Data Marts para realizarem suas análises e gerar seus insights.
Vamos agora a alguns conceitos que permeiam o Data Warehouse, não entrarei muito a fundo, mas servirá de guia para seus estudos..
OLAP x OLTP
OLAP — Online analytical processing
É a capacidade para manipular e analisar um grande volume de dados sob múltiplas perspectivas (cubos).
Um Data Warehouse é modelado no conceito de OLAP, enquanto os bancos de dados tradicionais (relacionais) é modelado no conceito de OLTP (Online Transaction Processing — esse é otimizado para inserções, atualizações, deleções, ou seja, para as necessidades do dia a dia da operação dos seus sistemas: ERP, CRM, Contábil, Financeiro e etc).
Granularidade
A granularidade dos dados em um modelo dimensional representa o que cada fato pode nos dizer. Para melhor entender este conceito, precisamos recorrer à forma como sistemas transacionais armazenam dados durante a execução dos processos de negócio.
Sistema transacional (Online Transaction Processing — OLTP) é todo aquele que dá suporte à execução dos processos de negócio, registrando todo o detalhamento necessário a sua correta consecução (normalmente utilizando modelos relacionais). Desta forma, ao consultar os dados armazenados, teremos o menor detalhamento possível, ou seja, o nível atômico daquele fato registrado (granularidade atômica).
É o que ocorre, por exemplo, quando registramos uma Venda em um Sistema ERP. Tal Venda traz todo o detalhamento necessário para que o produto possa chegar até o endereço de entrega cumprindo todos os requisitos legais, de qualidade e de segurança definidos. Mas se mudarmos a perspectiva e o objetivo atribuído aos dados transacionais, agora olhando em um viés analítico (OLAP), considerando responder a perguntas como “Quantas entregas foram realizadas para a cidade X aos sábados?”, podemos pensar na possibilidade de agregar dados de ordens de compra a partir das chaves de cidade e dia da semana em que a entrega ocorreu. Mudamos então a granularidade dos dados, pois se assim forem agregados, não iremos mais conseguir responder qual foi o horário da entrega de uma ordem específica.
Mas afinal, por que o nível de granularidade (detalhamento) dos dados importa? Bem, importa por duas razões principais: custo e velocidade. Quando maior o detalhamento dos dados, maior será o volume armazenado e, por conseguinte, maior será o tempo necessário que que consultas sejam processadas. Ou seja, o custo computacional é diretamente impactado pela granularidade dos dados. Logo, a escolha equilibrada do nível de detalhamento é uma decisão chave para o sucesso de qualquer projeto de análise de dados.
Abordagens de desenvolvimento de data warehouses
• O modelo de Inmon: abordagem EDW (de cima para baixo)
• O modelo de Kimball: abordagem por data mart (de baixo para cima)
Qual modelo é o melhor?
O que atender a necessidade do seu negócio.
Detalhando um pouco as abordagens…
Top Down (Inmon)
Faz um todo, que irá atender a todos os setores
• Vantagens: centralização, visão globalização
• Desvantagem: implementação lenta e risco alto
Botton Up (Kimball)
Faz por setores e depois sobe para um todo
• Vantagens: implementação e retorno rápido
• Desvantagem: integrações entre áreas, descentralização
Combinada
Planejamento Top Down e Desenvolvimento Botton Up
• Planejamento como um todo (e não apenas setorial) e a implementação (desenvolvimento) feita setorialmente e não como um todo.
Modelagem Dimensional
Um Data Warehouse é montado utilizando Modelagem Dimensional (ou Multidimensional), ou seja, um sistema baseado em recuperação de dados que suporta alto volume de acesso via consultas.
Multidimensionalidade
A capacidade de organizar, apresentar e analisar dados (fatos — vendas por exemplo) por várias dimensões, como: por regiões, por produtos, por vendedores e por tempo (quatro dimensões, no exemplo)
Apresentação multidimensional:
- Dimensões: produtos, vendas, mercado, segmentos, unidades de negócios, localizações geográficas, canais de distribuição, países ou indústrias
- Tempo: diário, semanal, mensal, bimestral, trimestral, semestral ou anual
Elementos da Modelagem Dimensional:
- Tabelas de Fatos
- Tabelas Dimensões
Tabelas de Fato
Fatos ou Tabela Fato, são registros de medidas resultantes dos eventos de negócio [1]. Seus valores são geralmente numéricos e sempre estarão intrinsecamente associados com o grão estabelecido. Ou seja, devemos registrar as medidas conforme o nível de detalhamento estabelecido.
- A tabela de fatos sintetiza o relacionamento existente entre as diversas dimensões. Isto ocorre porque a chave da tabela de fatos é a associação das chaves primárias das tabelas de dimensões.
- Geralmente este tipo de tabela possui um ou mais fatos numéricos (ex. chaves, datas, valores, quantidades) de “fatos” que ocorreram (ex. de uma venda, compra, produção), além das chaves para as dimensões (ex. cliente, produto, vendedor) que fazem parte daquele “fato”.
Dimensões
Dimensões são tabelas que oferecem um contexto descritivo ao evento de negócio registrado. Respondem a questões como quando, quem, o que, por que, como e onde, por exemplo [1]. Dados de dimensão são utilizados para filtrar e agrupar os fatos, permitindo observar os fatos a partir de diferentes perspectivas. Seus valores não podem ter duplicidades (exemplo: cada linha representa um produto específico, um cliente especifico…)
Uma dimensão é uma coleção de atributos textuais que são altamente correlacionados entre si.
Alguns exemplos:
- Produto (nome do produto, detalhe do produto, linha do produto, unidade de venda do produto…)
- Cliente (nome cliente, cpf, cnpj, endereço, cidade, estado…)
Observe a imagem acima, onde apresentamos um modelo simplificado para armazenar informações de vendas. Nele estão presentes quatro dimensões (dim_objeto, dim_vendedor, dim_data e dim_cliente), que nos permitem responder perguntas como “Qual foi o faturamento do mês de março de 2022 do Produto X para os clientes X,Y e Z“.
- estas respostas, são dadas aplicando as operações OLAP (que explicaremos na sequencia) nos dados.
Tabela de Dimensões — Data
Um recurso valioso sem sombra de dúvida é uma boa dimensão Data (ou ainda calendário ou tempo). Ainda que uma estrela (um conjunto fato-dimensões) seja em si mesma um grande recurso analítico, ela é pouco útil se não agregar a capacidade de analisar os dados contra o tempo (Ano, Semestre, Mês, Semana, dia…)O que o Kimball Group diz… | Gerando pelo SQL | Gerando pelo Power BI usando DAX
Métricas
Métricas são quantificações atribuídas a um registro de fato. É o que representam as colunas “QuantidadeVenda * ValorUnitarioVenda” na tabela fato que apresentamos anteriormente. E sobre essas quantificações, aplicam-se funções agregadores, que permitem consolidar as métricas sobre o olhar de uma ou mais dimensões. Observe nossa tabela de exemplo e imagine como poderíamos responder perguntas como: Qual foi o faturamento de vendas no ano de 2018 via o vendedor X? Quais são os clientes o maior número de compras em 2022?
As principais características de métricas são:
- São valores quantitativos (numéricos)
- Estão sempre associados com um agregador, orientado pelas dimensões utilizadas
Podem ser de três tipos:
- Aditivas: podem ser sumarizadas através de todas as dimensões, sem restrição. Um exemplo poderia ser o valor de venda de um e-commerce.
- Não-aditivas: não podem ser sumarizadas através de nenhuma dimensão. Um exemplo seria percentual de desconto de venda de produtos, por exemplo.
- Semi-aditivas: podem ser sumarizadas através de algumas dimensões, já outras não. É o caso do saldo bancário, por exemplo.
Quando pensamos em métricas em uma perspectiva visual, costumamos representar através de um cubo, conforme o da imagem abaixo. Nele, temos várias métricas obtidas na intersecção entre as dimensões de produto e tempo (como no exemplo abaixo).
Operações OLAP em Cubos
Anteriormente, vimos que um Data Warehouse é modelado no conceito de OLAP, depois de modelado, podemos fazer algumas operações em suas dimensões, claro, sempre baseado em um Fato…
Vamos utilizar o cubo abaixo para demostrarmos algumas das operações, ele contém 3 dimensões: Location, Time e Items…
Segmentar ou fatiar (Slice)
Ele seleciona uma única dimensão do cubo OLAP que resulta na criação de um novo subcubo (“corte para um valor fixo”). Com base no cubo de estudo fornecido, o Slice é executado na dimensão Time = “Q1” (Trimestre).
Dividir ou picar (dice)
Ele retorna um subcubo do cubo OLAP selecionando duas ou mais dimensões (“seleção de faixas de valores”).
Aumentar/diminuir o foco (drill-down / roll-up)
O usuário navega através de níveis de dados, indo desde os mais resumidos (menos foco — roll-up) até os mais detalhados (mais foco drill-down)
Na operação de drill down, os dados menos detalhados são convertidos em dados altamente detalhados. Pode ser feito por:
- Descendo na hierarquia do conceito
- Adicionando uma nova dimensão
Já na roll up, é justamente o contrário do anterior. Ele executa a agregação no cubo OLAP. Pode ser feito por:
- Subindo na hierarquia do conceito
- Reduzindo as dimensões
Fazer o pivô (pivot)
Usado para modificar a orientação dimensional de um relatório ou de uma página de exibição de consulta. Também é conhecida como operação de rotação , pois gira a visão atual para obter uma nova visão da representação. No subcubo obtido após a operação de slice, a execução da operação de pivô fornece uma nova visão do mesmo.
Representação de dados (Tipos de Modelos)
- Esquema em estrela (Star Schema)
- Esquema em floco de neve (Snow flake Schema)
- Esquema Galaxy (Galaxy Schema)
Modelo Star Schema
Aqui iremos aprofundar um pouco mais no esquema Estrela…
É um modelo dimensional comumente implantado em banco de dados relacionais. Caracteriza-se por tabelas fatos associadas à dimensões por meio de chaves estrangeiras. A sua estruturação otimiza consultas em grandes volumes de dados. Um ponto importante a considerar é que star schemas são modelos não normalizados de dados, que adicionam certa redundância (dimensões) em prol de ganhos de performance no momento das consultas.
O nome “estrela” se dá devido à disposição em que se encontram as tabelas, sendo a tabela fato centralizada relacionando-se com diversas outras tabelas de dimensão. Veja um exemplo da estrutura do Star Schema a seguir. Nesse modelo os dados são “desnormalizados” para evitar joins entre tabelas, diminuindo o tempo de consultas, no entanto devido a repetição de dados, utiliza mais espaço em disco.
Vantagem desse modelo é a eficiência na extração de dados, o que é um grande diferencial em se tratando de um data warehouse
Modelo Snow Flake
É uma variação do modelo star schema em que criam-se hierarquias de dimensões (normalizadas) sempre que necessário. Um dos benefícios desta estratégica de modelagem é otimizar o armazenamento, visto que as redundancias de dados são minimizados (ou mesmo removidas). Todavia, acrescenta-se complexidade nas consultas pela maior quantidade de tabelas e relacionamentos envolvidos. Há também o custo computacional associado com uma maior quantidade de junções entre tabelas, que podem impactar negativamente no tempo de resposta às consultas do usuário.
Modelo Galaxy
Também conhecido como esquema de Constelação de Fatos. Contém mais de 1 tabela de fatos. As dimensões que são compartilhadas são chamadas de dimensões conformadas.
Este não irei entrar em muito detalhe, mas fica a dica de que existe mais esta opção.
Técnicas de Modelagem Multidimensional
Aqui vou mostrar uma sequência de imagens de como transformar uma Modelagem Relacional — OLTP (base de dados relacional — operacional) para uma Modelagem Multidimensional (OLAP).
Do relacional para o Multidimensional:
Modelo Relacional (OLTP)
Modelo que é utilizado nas bases de dados operacionais (ERP, CRM…).
No nosso exemplo, temos uma modelagem relacional de uma base de dados de vendas.
Exemplo 1 — Dimensões envolvendo Pessoa
- Do Relacional …
- para o Multidimensional
Exemplo 2 — dimensão Objeto
- Do Relacional para o Multidimensional
Exemplo 3 — fato Vendas
- Do Relacional para o Multidimensional
Exemplo 4 — completo
Aqui é o modelo completo, transformando uma Modelagem Relacional (OLTP) para uma Modelagem Multidimensional
- Do Relacional
- para o Multidimensional
Outros pontos importantes relacionados:
Slowly Changing Dimensions
(Dimensões que Mudam Lentamente, em português) e retrata as dimensões que sofrem atualizações em seus campos e os classifica pelo tipo de mudança existente em cada uma delas. Vários tipos de SCD podem ser identificados no DW, variando de acordo com as características de atualizações das dimensões. As alternativas mais comuns de SCD são o SCD Tipo 1, SCD Tipo 2, SCD Tipo 3 e o SCD Híbrido.
Visualização de dados
É a apresentação de informações em formato imagético ou gráfico. Ela permite que tomadores de decisão vejam os resultados de análises visualmente, para que possam compreender conceitos difíceis ou identificar novos padrões.
Storytelling
Contar histórias é a descrição detalhada de conceitos, opiniões e experiências pessoais por meio de narrativas que provocam respostas emocionais e insights. Trata-se de aproveitar as histórias para envolver seu público ou esclarecer qualquer coisa. E é uma das maneiras mais fáceis de levar o público junto para tornar uma conversa animada e envolvente
Segurança
Segurança e privacidade de informações são as principais preocupações de um profissional de data warehouse
• Proteger os ativos mais valiosos
• Regras governamentais (LGPD, etc.)
• Deve ser explicitamente planejado e executado
Data Warehouses massivos e escalabilidade
Escalabilidade — As principais questões envolvendo a escalabilidade são:
- quantidade de dados no data warehouse;
- o ritmo esperado de crescimento;
- a quantidade de usuários concomitantes;
- a complexidade de suas consultas.
Possuir boa escalabilidade significa que consultas e outras funções de acesso a dados crescerão linearmente (na melhor das hipóteses) em relação ao tamanho do data warehouse.
Sei que não é tudo maravilha… quais os problemas mais comuns no dia a dia?
Falta
- Documentação
- Não tem Diagramas de Entidade e Relacionamento
- Não tem Dicionário de dados — Gerar dicionário (SQL Server)
- Na maior parte das vezes, temos apenas as tabelas do banco de dados
- “Data Warehouses” pegando dados direto de produção
- “Data Warehouses” sem utilizar modelagem multidimensional
Problemas na implementação de data warehouses
- Começar pela cadeia errada de patrocínio
- Estabelecer expectativas que você não pode cumprir
- Comportar-se de forma politicamente ingênua
- Carregar o data warehouse com informações só porque estão disponíveis
- Acreditar que projetar bases de dados com data warehouses é o mesmo que projetar bases de dados transacionais
- Escolher um gestor de data warehouse voltado para a tecnologia, em vez de voltado aos usuários
Referência
Apresentação sobre Dados, Modelagem Dimensional, Ferramentas, Power BI e Ciência de Dados
Agradeço pela leitura e espero que tenha sido útil…
Obrigado! Antes de você ir:
· 👏 Deixe suas palmas o story e me siga para mais assuntos
· 📰 Vejam mais conteúdos como este Blog do Souza
· 📰🚀 Diariamente dicas rápidas sobre dados 👉Alex Souza
· 💰 Venham conhecer a Comunidade de Análise de Dados
· 🔔 Sigam: Twitter (X) | LinkedIn | Instagram | Youtube | mais…
