Engenharia de Dados: MySQL para Modelagem Multidimensional e Data Warehousing

Fundamentos de Data Warehouse e Modelagem Multidimensional - Apresentação

Apresentando o curso e o instrutor

Olá! Seja bem-vinda e bem-vindo a este curso de MySQL para modelo multidimensional e Data Warehouse. Meu nome é Vitorino Villa e, neste treinamento, vamos muito além de simplesmente escrever consultas SQL.

Audiodescrição: Vitorino é um homem branco, de cabelo castanho curto e olhos castanhos. Ele veste uma camisa azul e está em um ambiente de escritório, com uma estante de livros ao fundo.

Explorando o conceito de Data Warehouse

O foco aqui é entender como um Data Warehouse é pensado, construído e mantido em ambientes corporativos reais. Vamos aprender por que um Data Warehouse é diferente de um banco transacional, como modelar dados de forma multidimensional, como construir dimensões, fatos e processos GTL, e como transformar dados brutos em informação.

Ao longo do curso, partiremos dos fundamentos básicos, como o que é uma modelagem multidimensional, o que são dimensões, fatos, granularidade e chaves. Avançaremos para temas essenciais do dia a dia, abordando tudo que uma pessoa engenheira de dados realmente vivencia.

Aplicando técnicas avançadas de Data Warehouse

Neste curso, veremos na prática como funcionam lockups, surrogate keys (chaves substitutas), dimensões e slowly changing dimensions (dimensões que mudam lentamente) dos tipos 1 e 2. Exploraremos processos completos de carga e consultas analíticas avançadas, além de aplicarmos CTEs (Common Table Expressions) a Data Warehouses. Também utilizaremos funções de janela, ranking, análise de Pareto e janelas móveis.

Abordando temas críticos e estratégicos

Abordaremos temas críticos em projetos reais, como otimização de performance, uso correto de índices, views, particionamento de tabelas e análises de planos de execução. Nos módulos finais, avançaremos para um nível mais estratégico, discutindo governança de dados, qualidade, linhagem, conformidade e o papel da inteligência artificial aplicada ao Data Warehouse.

Conectando teoria à prática com estudo de caso

Tudo isso será sempre conectado a um estudo de caso real, com um Data Warehouse completo, modelado, carregado e consultado como se fosse uma empresa de grande porte. Se desejamos evoluir do nível de apenas escrever SQL para pensar como uma pessoa engenheira de dados ou arquiteta de business intelligence, este curso foi feito para nós.

Vamos começar? Até o próximo vídeo.

Fundamentos de Data Warehouse e Modelagem Multidimensional - Porque o Data Warehouse é diferente do banco transacional

Introduzindo a diferença entre bancos de dados transacionais e gerenciais

Vamos iniciar este curso respondendo a uma pergunta fundamental que costuma gerar muitos erros em projetos reais: por que os relatórios gerenciais voltados à tomada de decisão não podem e não devem ser construídos no mesmo banco do sistema transacional? Essa diferença não é apenas conceitual; ela afeta diretamente a modelagem, os índices de performance, os históricos e até mesmo a disponibilidade dos sistemas.

Vamos relembrar rapidamente o papel de um banco de dados relacional voltado ao controle das transações da empresa. Esse banco é conhecido pela sigla OLTP, que vem de Online Transaction Process (Processamento de Transações Online). Um banco de dados relacional transacional existe para registrar os eventos do negócio em tempo real. Ele precisa ser extremamente eficiente para inserir dados, atualizar registros, garantir integridade e responder rapidamente a operações pontuais. Por isso, costuma ser altamente normalizado. Cada relação referente a cada entidade do modelo estará na sua devida tabela, com suas propriedades relacionadas a outras tabelas através de chaves estrangeiras e controlando a inclusão dos registros através de chaves primárias. Essas relações conferem ao banco de dados características mais rígidas de consistência e integridade, com foco em transações curtas e frequentes. No OLTP, o maior inimigo é a latência da escrita.

Explicando o propósito dos Data Warehouses

Já o banco de dados gerencial para geração de relatórios e tomada de decisão nasce com um objetivo completamente diferente. O foco não é escrever rapidamente, mas sim ler grandes volumes de dados, cruzar informações, agregar, resumir e analisar. Esses bancos de dados gerenciais são chamados de Data Warehouses (Armazéns de Dados). As consultas de um Data Warehouse são longas, complexas e exploratórias. Chegamos, então, ao ponto-chave: essas consultas não podem competir com as transações do dia a dia do sistema transacional, afinal, o sistema transacional está controlando o andamento da empresa.

Temos, então, um banco de dados gerenciando as transações do dia a dia em um local. Ao mesmo tempo, a gerência da empresa está consultando dados através da geração de relatórios complexos. Se essas informações forem geradas no mesmo banco da transação, isso pode comprometer a administração e o controle da empresa no seu dia a dia. Pode-se questionar, neste momento, que se temos dois bancos — um para controlar a empresa, alimentado pelas transações do dia a dia, e outro completamente diferente para gerar relatórios — significa que o relatório que a gerência consultar estará diferente das informações no banco do dia a dia. Afinal, o banco de dados transacional está evoluindo e mudando a cada minuto, enquanto o banco de dados dos relatórios está ali parado, apenas gerando informações. Discutiremos esse ponto mais à frente neste vídeo.

Destacando as características dos Data Warehouses

Voltando às características do Data Warehouse, podemos mencionar algumas importantes. Primeiro, as estruturas do Data Warehouse são desnormalizadas, ou seja, pode haver redundância, os dados podem se repetir, pois é necessário ter performance na geração dos relatórios. Os Data Warehouses precisam armazenar dados históricos, porque o passado é importante para a tomada de decisão. Em um banco de dados transacional, que controla a transação do dia a dia da empresa, o mais importante é saber o que está ocorrendo no momento.

Outro ponto importante é a baixa taxa de atualização. Claro que, se temos um banco de dados que controla as operações do dia a dia e outro de relatórios, em algum momento precisamos atualizar o banco de dados gerencial com as informações do banco transacional. Esse processo não ocorrerá minuto a minuto, mas pontualmente, fazendo com que o Data Warehouse tenha uma taxa de atualização ocorrendo apenas em determinados momentos, mantendo seu conteúdo congelado na maior parte do tempo. As otimizações devem ser realizadas quase que exclusivamente para a leitura, pois é necessário gerar os relatórios de forma rápida.

Comparando relatórios operacionais e gerenciais

Isso não significa que o banco de dados transacional, que controla a empresa no dia a dia, não possuirá relatórios.

Os relatórios nos bancos de dados transacionais são voltados para informações operacionais, com o objetivo de auxiliar as operações diárias. No caso do Suprema Bank, um banco de investimentos que será nosso estudo de caso, algumas perguntas que o OLTP (Online Transaction Processing) deve responder incluem: qual o crédito que um cliente possui? Essa é uma informação operacional, pois o gerente do banco, antes de decidir quanto dinheiro emprestar a um cliente, precisa verificar o crédito disponível naquele momento. Um caixa precisa saber, na hora, o saldo do cliente antes de autorizar um saque.

Por outro lado, se desejarmos informações mais abrangentes, como o volume de dinheiro emprestado pelo banco ao longo do ano, comparando com o ano anterior, ou o volume consolidado de dinheiro depositado no banco até o momento para cumprir regras do Banco Central, essas são informações pontuais. Assim, voltamos ao ponto de que os dois bancos de dados não precisam estar atualizados simultaneamente. O fato de terem informações diferentes por um período não é crucial, pois para relatórios gerenciais, se quisermos saber o dinheiro emprestado pelo banco durante o ano para tomar uma decisão estratégica, não faz diferença ter dados atualizados no dia do relatório. Se tivermos dados até o fechamento do dia anterior, o resultado consolidado não afetará uma tendência ou informação que nos levará a uma decisão estratégica.

Introduzindo o conceito de OLAP

Neste momento, introduzimos outra sigla e conceito: OLAP (Online Analytical Processing). Assim como chamamos os bancos de dados transacionais de OLTP, os bancos de dados voltados para análise são chamados de OLAP. Essa diferença de nomenclatura não é apenas conceitual, mas reflete objetivos completamente diferentes entre os dois tipos de bancos de dados. Em ambientes OLAP, as consultas normalmente envolvem grandes volumes de dados, múltiplos cruzamentos, agregações e consolidações históricas. Por isso, a principal preocupação não é inserir ou atualizar dados constantemente, mas sim ler e analisar informações de forma eficiente. É exatamente por esse motivo que os Data Warehouses são classificados como ambientes OLAP. Eles existem para transformar dados operacionais em informações analíticas, acessíveis e confiáveis para a tomada de decisão.

Discutindo os problemas de misturar OLTP e OLAP

O que acontece quando misturamos OLTP e OLAP? Se tentarmos misturar cargas transacionais com consultas analíticas no mesmo banco, enfrentaremos problemas. Primeiro, locks e deadlocks causados por consultas longas. As consultas do OLAP podem demorar muito tempo, travando as tabelas que estão sendo atualizadas pelos processos diários. Segundo, haverá lentidão perceptível no sistema para o cliente final. Imagine que o sistema OLTP está gerenciando a tela onde o cliente saca dinheiro no caixa eletrônico e, ao consultar o saldo, o sistema demora porque está concorrendo com um grande relatório gerencial que o diretor do banco está gerando naquele momento.

Além disso, há dificuldade em manter o histórico, pois os OLTPs são projetados para controlar transações diárias e nem sempre armazenam o histórico. Já no banco de dados OLAP, é necessário manter o histórico, e a performance degrada progressivamente conforme os dados crescem. Os OLAPs são bancos muito maiores em termos de volume do que os OLTPs, então, se tivermos as duas informações no mesmo banco, o grande volume das informações gerenciais degradará a performance do processo transacional. Isso afeta não apenas a performance, mas também a segurança, estabilidade do sistema, experiência do cliente e riscos operacionais.

Concluindo com a importância dos Data Warehouses

O ponto mais importante é entender que um Data Warehouse não é apenas outro banco, mas sim um modelo de banco com regras completamente diferentes de um banco de dados para transações. No próximo vídeo, daremos um passo adiante para entender como a modelagem multidimensional surge dessa necessidade de separar o banco gerencial do banco operacional. Esse será o tema do nosso próximo vídeo. Até mais!

Fundamentos de Data Warehouse e Modelagem Multidimensional - Fundamentos da modelagem multidimensional

Introduzindo a modelagem multidimensional

No vídeo anterior, compreendemos por que um Data Warehouse não deve compartilhar a mesma estrutura do banco operacional. Agora, o próximo passo é responder a outra pergunta: se o Data Warehouse é diferente, como ele deve ser modelado? É aqui que entra a modelagem multidimensional, uma técnica criada especificamente para análise de dados, e não para transações. Diferente da modelagem relacional tradicional, que é orientada a entidades e processos operacionais, a modelagem dimensional ou multidimensional é orientada a perguntas de negócio. Ela parte de um princípio simples, mas poderoso: o que queremos analisar e como queremos analisar.

Vamos formalizar isso. Em um Data Warehouse, tudo gira em torno de duas ideias: indicadores, que respondem ao que queremos analisar, e dimensões, que respondem ao como queremos analisar. Os indicadores são métricas, números, valores mensuráveis. Dimensões são as perspectivas pelas quais esses números serão observados.

Exemplificando indicadores e dimensões

Vamos a alguns exemplos no contexto do Suprema Bank, que será nosso estudo de caso. O total de transações é um indicador. Observamos o total de transações por cliente, por data, por agência. Logo, cliente, data e agência são dimensões. O volume movimentado é um indicador, analisado por canal, por produto, por período, que são dimensões. O ticket médio é um indicador, analisado por faixa etária, por região, por tipo de conta, que são dimensões.

As dimensões são tabelas descritivas. Elas respondem à pergunta: como queremos olhar para os dados? Uma dimensão contém atributos descritivos, como nomes curtos ou longos, classificações que podem ser números, datas ou outras formas de representar esses atributos, e hierarquias, ou seja, relações com níveis hierárquicos superiores. Um exemplo clássico é a dimensão tempo, que possui uma hierarquia de ano, mês e dia. No caso do Suprema Bank, temos dimensões como cliente, conta, agência, canal e tempo, e podemos ter uma hierarquização, como, por exemplo, conta está dentro de agência, que está dentro de cidade, que está dentro de estado, que está dentro de região. São essas dimensões que estruturam a forma como o dado será analisado.

Detalhando níveis hierárquicos e tabelas de fato

Podemos mencionar que a dimensão é composta de níveis hierárquicos. Esses níveis hierárquicos possuem uma relação de 1 para n, ou seja, um membro de uma dimensão no nível hierárquico superior se relaciona com n membros da dimensão do nível abaixo. Normalmente, o membro que está em um determinado nível é composto de um código e de uma identificação. As identificações podem ser nomes curtos ou longos, e associadas a cada um desses níveis hierárquicos, temos propriedades, chamadas de atributos, que podem ser textos, números ou datas.

Além dos indicadores e das dimensões, temos o que chamamos de tabelas de fato. Elas representam os eventos de negócio e respondem à pergunta: o que aconteceu? Exemplos típicos de fatos são as transações financeiras, os pagamentos, as inadimplências e os créditos aprovados. Um ponto crítico aqui é o que chamamos de granularidade da tabela de fato. Quanto mais detalhado o fato, maior o volume dos dados, mas também maior será o potencial analítico. Além disso, as métricas presentes em uma tabela de fato serão sempre numéricas, podendo ser métricas aditivas, semi-aditivas ou não aditivas. Aditivas são aquelas cujo valor no nível superior da hierarquia será a soma dos níveis inferiores. Semi-aditivas são aquelas cujo valor do nível superior será uma média ou um máximo/mínimo dos membros inferiores. As não aditivas, normalmente, estão ligadas a valores que vêm de divisões ou percentuais, onde não podemos afirmar que o valor do nível superior é uma operação matemática do nível inferior.

Comparando modelos estrela e snowflake

A forma mais comum de organizar os fatos e as dimensões é com um modelo que chamamos de modelo estrela. O que estamos vendo na tela é um modelo estrela.

Nós temos uma tabela central, que é a tabela de fato, onde temos o código do nível mais inferior da hierarquia de cada dimensão, um campo que representa o tempo e os indicadores. Cercando essa tabela de fato, estão as tabelas de dimensões desnormalizadas. No modelo estrela, todos os dados referentes à dimensão, ou seja, os níveis hierárquicos e seus atributos, estão na mesma tabela, com uma série de redundâncias, como, por exemplo, o nome. Se tivermos o nome de uma cidade e 1.000 clientes que estão naquela cidade, o nome da cidade se repetirá 1.000 vezes. Isso seria inadequado em um banco OLTP, que controla transações, mas em um banco de dados OLAP, é normal.

O outro modelo é o que chamamos de snowflake (flocos de neve). Nesse modelo, cada um dos níveis hierárquicos faz parte de uma tabela isolada. A tabela de dimensão tem cada nível em sua própria tabela, e há uma chave estrangeira ligando cada nível. Para realizar a atualização dos dados, ou seja, a manutenção das dimensões, o snowflake é mais fácil. Porém, em termos de performance, o modelo estrela é melhor. Muitas vezes, podemos montar um modelo misto, onde algumas dimensões têm dimensões estrela e outras dimensões snowflake.

Explorando o modelo pai-filho e hierarquias irregulares

Um terceiro modelo é chamado de tabela pai-filho. Tanto no modelo estrela quanto no snowflake, quando temos uma hierarquia, ela é uma hierarquia regular. Isso significa que qualquer nível folha da hierarquia, que é o nível mais baixo da dimensão e tem a relação com a fato, sempre tem o mesmo número de níveis antecedentes. Por exemplo, em uma hierarquia ano, mês e dia, todos os dias têm um mês e todos os meses têm um ano. Não há um dia que esteja ligado diretamente ao ano; sempre uma data deve passar por um mês para chegar ao ano. Este é um caso de uma dimensão com hierarquia regular. Em uma dimensão regular, o número de níveis antecedentes é igual.

Podemos também ter uma dimensão irregular, onde, para o nível folha chegar ao nível mais alto, depende dele. Por exemplo, um nível pode passar por dois níveis para chegar ao superior, enquanto outro tem uma relação direta. Um exemplo seria um cliente do Suprema Bank que tem um endereço, e esse endereço tem uma cidade, que está ligada a um estado, que está ligada a uma região geográfica, e a região geográfica está ligada a um país e a um continente. Ou seja, uma hierarquia com cinco níveis: cidade, estado, região, país, continente. Todo cliente teria sempre esses cinco níveis gravados em seu cadastro. Agora, suponha que haja um cliente que não mora no Brasil, um cliente internacional. Ele tem conta no Suprema Bank, mas o endereço dele é fora do país, e o país onde mora não tem estado, apenas uma cidade e o país. Nesse caso, essa dimensão seria irregular. Se montarmos isso no modelo snowflake ou modelo estrela, teríamos que transformar essa dimensão irregular em regular. Poderíamos criar um estado chamado "estado não definido" ou um membro a nível de estado que seria igual ao próprio país, para que tudo se regularizasse. No modelo pai-filho, conseguimos montar essa hierarquia.

Concluindo a introdução à modelagem multidimensional

Neste vídeo, entendemos a lógica por trás da modelagem multidimensional. Vamos parar por aqui e, nos próximos vídeos, sairemos do conceito e entraremos na prática, começando pelas dimensões, suas hierarquias, níveis e atributos que serão aplicados ao nosso estudo de caso, o Suprema Bank. Até o próximo vídeo.

Sobre o curso Engenharia de Dados: MySQL para Modelagem Multidimensional e Data Warehousing

O curso Engenharia de Dados: MySQL para Modelagem Multidimensional e Data Warehousing possui 421 minutos de vídeos, em um total de 86 atividades. Gostou? Conheça nossos outros cursos de Engenharia de Dados em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos de Data Warehouse e Modelagem Multidimensional
• Estrutura de um Data Warehouse na Prática
• Processo de ETL e Dimensões
• Carga do Data Warehouse
• Consultas Analíticas
• Consultas Avançadas e KPIs
• Análises Avançadas, Performance e Governança