Faculdade - BI, Data Warehouse, Data Mart

Prévia do material em texto

BI, Data Warehouse, Data Mart (Tema 2) 
Business Intelligence (BI) 
É um conjunto de ferramentas e técnicas que visam coletar, tratar e analisar dados para transformar 
informações brutas em insights valiosos para a tomada de decisões estratégicas dentro da 
organização. 
Pontos principais e fundamentais: 
1. Objetivo do BI: O foco é transformar dados em informações úteis que ajudem na formação 
de estratégias e na tomada de decisões. Isso é essencial para que as organizações possam 
identificar oportunidades e monitorar seu desempenho. 
2. Ambiente Analítico: O BI cria um espaço onde relatórios e dashboards interativos permitem 
que as empresas realizem análises profundas, facilitando a visualização de dados e insights. 
3. Integração de Dados: Um dos grandes benefícios do BI é a capacidade de integrar dados 
de diversas fontes, o que permite uma análise mais abrangente e uma visão unificada da 
situação da empresa. 
4. Exemplo Prático: Um gestor de supermercado pode utilizar dados dos últimos três anos 
sobre os produtos mais vendidos entre os meses de dezembro a março para que o estoque 
não fique zerado no verão. É a análise de eventos passados ajudando a formular estratégias 
eficazes para a demanda futura. 
Tipos de Análise em BI: 
● Análise Diagnóstica: o que aconteceu? Foca no que aconteceu, analisando eventos 
passados para entender causas e consequências. 
● Análise Descritiva: o que está acontecendo? Avalia o que está acontecendo atualmente, 
fornecendo uma visão do desempenho atual. 
● Análise Preditiva: o que acontecerá? Utiliza dados históricos e modelos estatísticos para 
prever o que pode acontecer no futuro. 
● Análise Prescritiva: o que pode ser feito para alcançar um objetivo? Sugere ações a serem 
tomadas com base em análises preditivas e descritivas, frequentemente empregando 
técnicas avançadas como machine learning. 
Data Warehouse (DW) 
O Data Warehouse (DW) é uma peça fundamental dentro do ecossistema de Business Intelligence, 
servindo como um repositório central para dados a longo prazo, provenientes de diversas fontes 
dentro de uma organização, permitindo que as empresas utilizem seus dados de forma eficaz para 
tomada de decisões estratégicas. Ele é crucial para realizar análises detalhadas e gerar relatórios e 
dashboards, funcionando como um sistema de informação gerencial. 
 
 
 
 
Principais características do Data Warehouse: 
● Orientação a Assunto: Os dados são organizados em temas específicos, facilitando 
análises mais intuitivas e focadas em áreas de interesse, como vendas, finanças ou 
marketing. 
● Integração de Dados: Reúne informações de diferentes sistemas e fontes, proporcionando 
uma visão unificada da organização, o que é essencial para uma análise completa e 
informada. 
● Imutabilidade (não volátil): Os dados no DW são mantidos de forma imutável, ou seja, uma 
vez que são armazenados, não são alterados. Isso preserva a integridade dos registros 
históricos, permitindo análises precisas ao longo do tempo. 
● Armazenamento Histórico: O DW mantém dados ao longo do tempo, possibilitando 
análises temporais e a identificação de tendências, o que é vital para entender o 
comportamento passado e projetar o futuro. 
Data Mart (DM) 
Enquanto o Data Warehouse atende a organização como um todo, o Data Mart (DM) é uma extensão 
do conceito de Data Warehouse, focando em atender necessidades específicas de departamentos ou 
segmentos dentro de uma organização. Cada DM contém dados relevantes que facilitam a tomada 
de decisões em áreas específicas (marketing, vendas…) 
Por exemplo, em uma locadora de veículos, um DW pode conter todos os dados da empresa, 
enquanto os DM’s podem se concentrar em áreas específicas, como vendas e compras, permitindo 
que cada departamento tenha acesso a informações relevantes sem a sobrecarga de dados 
desnecessários. 
Abordagens de Desenvolvimento: 
1. Top-Down (Inmon): Nesta abordagem, o Data Warehouse é construído primeiro, e os DM’s 
são extraídos dele. Isso garante que todos os DM’s compartilhem uma base comum de 
dados, promovendo consistência e integridade. 
2. Bottom-Up (Kimball): Aqui, os DMs são criados primeiro, e o Data Warehouse é 
desenvolvido com base neles. Essa abordagem é mais ágil e permite atender rapidamente 
às necessidades de departamentos específicos, tornando-a útil em ambientes dinâmicos. 
Processos: 
● Origens dos Dados: Dados provenientes de diversas fontes, como ERP, CRM e arquivos 
CSV, que são fundamentais para alimentar tanto o DW quanto os DM’s. 
● Integração dos Dados: O processo ETL (Extração, Transformação e Carregamento) é 
essencial para integrar e preparar os dados, garantindo que estejam prontos para análise. 
● Armazenamento de Dados: Os dados são armazenados no Data Warehouse, servindo 
como a base para análises posteriores. 
● Análise de Dados: OLAP (Online Analytical Processing) é utilizado para realizar análises 
complexas, permitindo que os usuários explorem os dados de maneira interativa. 
● Visualização de Dados: Dashboards são ferramentas essenciais para a visualização, 
apresentando os insights de maneira clara e acessível, facilitando a interpretação e a tomada 
de decisões. 
Sistema de apoio operacional x sistema de apoio à decisão 
● Sistema de apoio operacional ou transacional (OLTP). Baseado em volatilidade, Atende 
a necessidade do dia a dia registrando eventos ocorridos a cada operação realizada. 
(inclusão, alteração e remoção de compras…). As estruturas de dados são normalizadas 
garantindo eficiência e velocidade nas operações diárias. Exemplo: Registros de vendas em 
um ponto de venda, onde cada compra é registrada imediatamente. 
● Sistema de apoio à decisão (OLAP). Os dados estarão disponíveis para responder 
perguntas com eficiência, sem concorrer com operações transacionais. Projetado para 
análises de dados extensivas em um DW ou DM, permitindo consultas rápidas e eficientes 
em grandes volumes de dados históricos, sem interferir nas operações diárias. Exemplo: Um 
analista que precisa revisar as compras de um cliente específico nos últimos dois anos, 
obtendo insights sobre padrões de consumo e tendências. 
 
Arquitetura de um Data Warehouse / Data Marts 
Passos importantes para construção de um BI 
Fornece insights e facilita a tomada de decisões com base nos dados armazenados, 
utilizando análises e visualizações. A implementação deve acontecer quando a empresa precisa 
reunir e analisar dados para entender seu desempenho ao longo do tempo e tomar decisões 
informadas. 
● Sistema transacional: Esse é o ponto de partida, onde as transações diárias da empresa 
são registradas. São dados para análise futura. 
● Sistema ETL: Extract (coleta de dados em qq formato), Transform (tratamento desses dados 
limpando e padronizando para melhor compreensão) e Load( inseridos em um repositório 
definitivo (DW ou DM). 
● Área de apresentação de dados: onde os dados são organizados no modelo dimensional 
(estrela ou floco de neve) para facilitar a análise, e disponibilizados para os usuários. Os 
dados estão prontos para uso em tomada de decisão. 
● Aplicação BI: Criados os dashboards e relatórios que apresentam os dados de forma visual. 
Passos importantes para a construção de um DW/DM 
Repositório organizado e integrado de dados 
● Entendimento do Negócio: Será criado baseado em identificar as necessidades da 
organização e dos stakeholders. 
● Mapeamento dos Dados: Verificar disponibilidade e a viabilidade dos dados para 
construção das análises, evitando surpresa no processo de ETL. 
● Área de Manobra dos Dados: Atividades preliminares como análise de qualidade dos 
dados, limpeza inicial, enriquecimento e formatação. 
● Processo ETL: atividade mais formal para garantir que os dados estejam prontos, 
consistentes e disponíveis para os usuários finais, permitindo análises eficientes. 
● Área de Apresentação/ construção de análises: Onde os dados organizados são 
acessados pelos usuários. 
 
Conceitos importantes:Metadados 
Os metadados (dados sobre os dados) - dicionário de dados são informações sobre os dados, 
como, onde estão armazenados e como foram tratados. Eles ajudam a entender melhor os dados 
disponíveis. 
Data warehouse / Data Marts self-service: 
OBS: quando a equipe de BI não consegue atender a alta demanda de dados surge o conceito de 
sef-service onde o próprio usuário pode acessar, modelar e analisar sem a equipe de BI, agilizando o 
processo para uma melhor tomada de decisão. Os dados são descentralizados, não havendo 
desenvolvimento de metadados os dados podem apresentar inconsistência, e assim tomadas 
decisões erradas. 
Data Mining - mineração de dados 
É uma das etapas da Descoberta de conhecimento em base de Dados (KDD - Knowledge Discovery 
in Databases) que é um processo para encontrar informações valiosas que podem ser usadas para 
apoiar a tomada de decisões em diversos contextos, como negócios, saúde, ciência, etc. Este 
conceito abrange várias etapas que transformam dados brutos em conhecimento aplicável. 
No exemplo do Supermercado, o DW fornece consultas sobre o volume de compras realizadas 
pelos clientes e os processos de KDD podem descobrir padrões existentes nas compras realizadas. 
No caso onde na sexta-feira cervejas e fraldas eram compradas em grande quantidade, o gerente 
organizou os dois produtos juntos, alavancando as vendas. 
Resumo final 
Business Intelligence ajuda a entender a empresa; o Data Warehouse armazena grandes volumes de 
dados, e o Data Mart foca em informações específicas. Esses sistemas ajudam na análise e na 
tomada de decisões, tornando as empresas mais eficientes. 
 
 
 
 
 
Projeto de DW: especificação de requisitos (Tema 3) 
Ciclo de vida do Data Warehouse (por kimball) 
Data warehouse - O gerente de projetos é o responsável por acompanhar todo o ciclo de vida 
atuando como um facilitador. 
 
Fases do ciclo de vida do DW : 
● Planejamento - Escopo do projeto (o que será desenvolvido), a viabilidade de recursos (se 
os recursos estarão disponíveis até o final do projeto), às tarefas a serem desenvolvidas no 
projeto e o encadeamento delas 
● Definição de requisitos de negócios - Levantamento das necessidades dos usuários para 
o desenvolvimento do DW, definindo quais dados devem ser coletados e a frequência das 
atualizações. 
Depois divide-se em 3 trilhas: 
● Primeira trilha (análise técnica): 
○ Arquitetura do DW - infraestrutura, tecnologias para construção de um DW. 
○ Seleção e instalação de produtos - ferramentas utilizadas 
● Segunda trilha (modelagem dimensional): 
○ Modelagem dimensional - analises no ambiente analitico 
○ Projeto físico - modelo de dados dimensional (nomenclaturas, ambiente..) 
○ Especificação e desenvolvimentos de ETL - extract, transform e load 
● Terceira trilha (aplicações de BI): 
○ Especificação de Aplicação de BI - visualização dos dados 
○ Desenvolvimento das Aplicações de BI - construção das consultas 
● Implementação - é a união das tarefas desenvolvidas em cada trilha, devendo ocorrer 
quando todas as tarefas estiverem concluídas. 
● Crescimento - contínua expansão baseada em novas necessidades dos usuários 
● manutenção - ajustes e melhorias ao longo do tempo 
Levantamento de Requisitos 
Aplica-se para qualquer tipo de projeto. Esse processo é essencial para o sucesso do 
projeto. Sem a clara definição de objetivos e requisitos, o DW pode ser mal implementado ou não 
atender às necessidades da organização. O levantamento de requisitos deve ser feito por analistas 
de negócios, que entrevistam usuários para identificar os dados necessários e a periodicidade de 
carga no DW. O objetivo é garantir que o sistema seja capaz de fornecer as análises e indicadores 
necessários para a tomada de decisões. 
Questionamentos feitos para o levantamento de requisitos: 
1. Entender as necessidades do negócio - É realizado pelo analista de negócios investigando 
as dores dos usuários ou stakeholders, para traduzir em requisitos. Utiliza técnicas como 
entrevistas, reuniões com grupos e utilização do BABOK (Business Analysis Body of 
Knowledge) - guia com os principais conceitos de apoio para análise de negócios - para 
identificar as atividades realizadas pelos usuários e as perspectivas de análise e indicadores. 
A periodicidade de carga dos Dados é definida, registrado em um documento de 
especificação do projeto, pela organização da frequência da carga dos dados (diária, 
semanal, on time…). A extração do ETL depende da necessidade do negócio e da 
organização: por dia, à noite; por mês, após o fechamento mensal… 
2. Elaborar documento de Perspectivas de Análises (Visões) - Perspectivas de análise são 
representadas pelas tabelas de Dimensões (visão) no modelo de dados do DW. Exemplo: 
Visões como Produto e Tempo são usadas para descrever medidas como Quantidade de 
Produtos Vendidos. Documentação detalhada das visões com atributos, conceitos, exemplos 
e observações. É a tabela de descrição de atributos. 
3. Documentação de Medidas (Indicadores) - Indicadores organizados em tabelas Fato, 
representando os fatos ocorridos (ex: Quantidade Vendida, Lucro). Documentação de 
indicadores com nome, conceito, fórmula de cálculo e observações. 
a. matriz de granularidade: Relação entre Visões (Atributos) e Indicadores, permitindo 
visualizar análises possíveis como cruzamento de informações. A matriz de 
granularidade auxilia o entendimento das análises que poderão ser realizadas no 
DW/DM. Em formato de matriz, organiza as visões (atributos) e os indicadores que 
estão relacionados com elas e apresenta o grão de análise do DW/DM que informa 
qual o nível de detalhe em que os dados poderão ser analisados. Quanto maior o 
grão, maior o detalhe. 
4. Documento que descreva as análises desejadas (Consultas) - Contém layout de 
consultas predefinidas pelos usuários. Desenhos de dashboards e de relatórios para 
alinhamento de expectativas com o cliente. Descrição das análises com objetivo, atributos, 
indicadores e filtros. 
5. Documento de Apontamento das Origens dos Dados - Mapeamento detalhado das 
origens dos dados (sistemas transacionais) identificados nas fases anteriores. Checagem 
pelo analista da existência dos dados e indicadores no sistema de origem, identificando a 
tabela, nome, tamanho e tipo de dados do campo. Em sistemas antigos ou sem 
documentação, esse processo pode revelar desafios. Informações não disponíveis ou não 
extraíveis devem ser comunicadas ao gestor. 
 
Metadados 
O banco de metadados (dados sobre os dados) organiza informações sobre os dados, como 
tipo, origem e relações. Os metadados podem ser de negócios (contextualização), técnicos/físicos 
(estrutura e tamanho), e operacionais (processos e rotinas associadas). 
Esse banco facilita a construção e manutenção do ambiente de Data Warehouse (DW), servindo 
como um dicionário de referência para analistas e usuários. O levantamento de requisitos, iniciado no 
início do projeto, alimenta esse banco e deve ser mantido ao longo de todo o ciclo de vida do DW. 
Resumo final 
Vimos a importância do levantamento de requisitos para um projeto de DW/DM, como realizar o 
entendimento sobre a necessidade dos usuários e a importância de documentar o conhecimento 
adquirido. Vimos também que os documentos elaborados são utilizados pelos analistas que 
participam da construção do DW/DM, pelos usuários que farão suas análises no ambiente e pelas 
pessoas que futuramente possam interagir com o ambiente analítico. 
Projeto de DW: Modelagem de dados dimensional 
- Esquema lógico (tema 4) 
Uma modelagem de dados dimensional para um projeto de DW pode ser dividida em três 
momentos: o modelo conceitual, que representa o entendimento sobre o negócio e o relacionamento 
entre as tabelas; o modelo de dados lógico, que considera algumas restrições, o padrão e a 
nomenclatura, chaves primárias e estrangeiras, entre outros (que será abordado aqui); e o modelo 
físico que considera os padrões do SGBDescolhido. 
Modelagem de dados dimensional 
● É o primeiro passo para a segunda trilha de dados do ciclo de vida do DW, que 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 de dados dimensional pode ser construído. 
● Também chamada de multidimensional, visa organizar os dados de forma simples e eficiente 
para facilitar sua leitura e a montagem das consultas analíticas, e seu modelo de dados é 
normalmente desnormalizado, composto por tabelas Dimensão e tabelas Fato. Por exemplo, 
a Dimensão Produto pode incluir atributos como código, nome, fabricante e categoria, e a 
Dimensão Data, considerada essencial por Kimball, pode ser construída previamente para 
facilitar a análise temporal. 
● O foco principal é responder às consultas de forma rápida e com eficiência e evitar funções 
de join. 
● Diferente dos modelos operacionais/transacionais onde as consultas não precisam ser 
analíticas, nesta técnica os dados são organizados para facilitar a leitura e as consultas 
analíticas. 
● Após definir as dimensões, a tabela Fato é criada para armazenar as métricas centrais, 
como quantidade de produtos vendidos e preço. A modelagem finaliza com a ligação das 
dimensões à tabela Fato, formando um esquema estrela que reflete a relação entre os 
dados para uma análise eficiente. 
Identificação das tabelas no modelo de dados dimensional 
Neste modelo, as perguntas 5W e as 3H (usadas na modelagem de processo de negócios), 
são usadas para o mapeamento e identificação das tabelas. 
Tabela dimensões 
● Armazenam os elementos textuais que descrevem os fatos ocorridos. Respondem às 
perguntas de como ocorreu um fato: O quê?, Quem?, Quando?, Onde?, Por exemplo: Fato 
ocorrido: Venda do Produto. 
● Contém uma PK Surrogate (chave automática do sistema), a chave natural e os outros 
atributos que representam a tabela. 
● De acordo Kimball, são tabelas com muitas colunas desnormalizadas, com muitos atributos 
de texto de baixa cardinalidade. 
● É normal apresentar maior (drill-down) ou menor nível de detalhe (drill-up). por exemplo em 
uma tabela de vendas por mês, a tabela venda por ano seria drill-up e a tabela venda por dia, 
drill-down. Por exemplo, em um drill-down: Região, estado, cidade e bairro. 
● estão relacionadas com a tabela fatos muito-para-um. 
● não há limites de quantidade de tabelas dimensão 
Tabela fato 
● relacionam-se no mínimo com duas tabelas dimensões. 
● É criada com um conjunto de Fk’s para as tabelas dimensões, e atributos métricos dos fatos 
ocorridos que respondem às perguntas “quanto?”. 
OBS: 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. 
Tipos de tabela fato: 
● Fato transacional: é a mais comum, armazena o nível mais detalhado do fato, quanto mais 
detalhado o dado, mais linhas terá a tabela. 
● Fato snapshot periódico: é igual ao fato transacional mas por período (dia, mês e ano) 
● Fato snapshot acumulado: descreve um processo de negócio acumulado. A cada nova 
etapa o registro sofre uma alteração. 
● Fato agregada: granularidade mais elevada, diminuindo a quantidade de linhas 
relacionadas. Objetivo é ter consultas mais rápidas. Se precisar de mais detalhamento, 
faz-se uso da tabela transacional. 
● Fato sem fato: só utiliza as FK’s sem um fato consumado. 
Esquema estrela 
● Desnormalizado. Pode haver problemas de integridade mas apresenta mais velocidade e 
eficiência. 
● No centro a tabela fato e em torno as as tabelas dimensão 
● exemplo: 
○ Tabela Fato: Vendas (contém dados como quantidade vendida, valor total...) 
○ Tabelas Dimensão: Produto, Cliente, Tempo, Local. 
 
Esquema floco de neve 
● Derivação mais complexa do esquema estrela. 
● Nele os dados ficam normalizados evitando redundância e as tabelas dimensão ficam em 
hierarquia. Com isso, uma tabela pode ser dividida em mais tabelas. Mas a recuperação de 
dados é mais custosa pois precisa fazer mais consultas de junção. 
● exemplo: 
○ Tabela Fato: Vendas. 
○ Tabelas Dimensão: Produto (que pode ser dividida em subdimensões como 
CategoriaProduto, Marca). 
 
 
Representação em cubo 
● representação para visualização tridimensional dos dados 
● Permite que a visualização de múltiplas dimensões (ou categorias) simultaneamente. Por 
exemplo, você pode analisar vendas por tempo, local e produto ao mesmo tempo. 
● Mais utilizado em OLAP 
● Análise de grande volume de dados em várias dimensões ao mesmo tempo 
● Cada célula no cubo contém um valor agregado, como uma soma ou contagem, baseada em 
combinações das dimensões. 
● Exemplo: 
○ Um cubo pode ter dimensões Tempo, Produto e Local, e os dados em cada célula 
representam o total de vendas com base nessas três variáveis. 
 
Resumo final 
O Projeto de Data Warehouse (DW) com modelagem dimensional organiza dados para facilitar 
consultas analíticas eficientes, dividindo-se em três fases: modelo conceitual (entendimento do 
negócio), lógico (definição de restrições e chaves) e físico (adaptação ao SGBD). As tabelas Fato 
armazenam métricas (como vendas), enquanto as tabelas de Dimensão contêm dados descritivos 
(como produto e cliente), formando o esquema estrela, que é simples e eficiente, ou o esquema 
floco de neve, mais normalizado, porém com consultas mais lentas. A modelagem visa respostas 
rápidas a perguntas de negócio, com diferentes tipos de tabelas Fato, como transacional e agregada. 
Projeto de DW: Modelagem de dados dimensional 
- Esquema físico (tema 5) 
É o segundo passo da trilha de dados do ciclo de vida de projetos de DW/DM. Nesta fase a 
implementação do modelo responderá de forma eficiente as consultas dos usuários com um bom 
desempenho. É onde os dados serão “acomodados”. 
É construído com base nos padrões estabelecidos, nas regras de negócio e considera as 
características do SGBD. 
Aqui, considera-se: 
● Estrutura de armazenamento: Decidir entre o SGBD; Deve ser avaliado pelo especialista (DA 
ou DBA) o espaço em disco disponível, processos de backup, particionamento, entre outros. 
● Padrões de nomenclatura para tabelas, colunas, índices: Usar alguns padrões de nomes 
como: para tabela dimensão = dim_; tabela fato = ft_; tabela temporária = tmp_; coluna 
chave identificadora = sk_; coluna código = cd_; coluna descrição = ds_; coluna valor = 
vl_; coluna nomes = nm_; coluna data = dt_; bem como definido se os nomes das colunas 
serão em letras maiusculas ou minúsculas bem como o uso de “_”. 
● Informações de restrições e valores nulos: Criação de índices para otimizar o 
desempenho das consultas, acelerando o acesso a dados frequentemente consultados. E 
garantindo que as relações importantes sejam respeitadas. 
● Decidir se terá drill up ou drill down: Estratégias para dividir grandes tabelas em partes 
menores, facilitando o gerenciamento e melhorando o desempenho. 
● Tabelas temporárias ou tabela de manobra: porta de entrada para Staging Area, que é 
uma área de suporte ao processo de ETL, mantendo-o eficiente e organizado. Ela atua como 
um espaço intermediário (repositório temporário) onde os dados são armazenados após 
serem extraídos, serem transformados e carregados no data warehouse. É tudo que existe 
entre fonte de dados (data source) e área de apresentação (presentation area) 
OBS: Para cada tabela dimensão e fato, terá uma tabela temporária para suportar o processo de 
validação dos dados. Elas não estarão ligadas ao esquema estrela, mas sim ficarão como base para 
validação. 
 
Implementação do Modelo de Dados Dimensional 
Algumas ferramentas de modelagem podemser usadas como o Ql Power Architect que permite a 
escolha do banco de dados no qual o modelo será fiscalizado. 
 
Com o andamento do projeto e até mesmo depois da conclusão, novas necessidades podem surgir e 
então o modelo criado pode sofrer alterações para atender às novas demandas. Esse trabalho deve 
ser feito com cautela para assegurar que o modelo criado e os dados nele contidos não sofram 
perdas devido ao crescimento do ambiente. 
Dimensões e Hierarquias, Tabelas Fato e 
Agregações tema 6 
Tanto no esquema Floco de Neve (onde as dimensoes sao criadas hierarquicamente e normalizadas 
em varias tabelas menores - normalizadas) e quanto no esquema Estrela (onde as dimensoes ficam 
em tabelas desnormalizadas, com a estrutura hierarquica implicita na mesma tabela) podem ter 
hierarquias além de técnicas de agregação e consolidação de dados para otimizar consultas 
analíticas no Data Warehouse (DW). 
Dimensões 
As tabelas Dimensões descrevem fatos e possuem colunas de texto com baixa cardinalidade, 
fundamentais para filtragem e agregação de dados. Dimensões podem ser normalizadas (Floco de 
Neve) ou desnormalizadas (Estrela), permitindo a especialização em hierarquias. 
Hierarquia 
As hierarquias organizam dados em níveis, permitindo visualizações agrupadas ou detalhadas. 
Exemplo: na dimensão Data, temos a hierarquia Dia, Mês e Ano. As hierarquias facilitam operações 
como Drill-Up e Drill-Down. 
Uma hierarquia estabelece a relação entre elementos de um conjunto de dados de um contexto. As 
hierarquias são organizadas em níveis, em que o nível mais alto é o elemento que agrupa os demais, 
que estão abaixo. Isso permite que os dados da tabela Fato sejam visualizados conforme a 
navegação na hierarquia, de modo agrupado (nível mais alto) ou detalhado (nível mais baixo). 
Exemplo a dimensão Data possui uma hierarquia formada pelos elementos Dia, Mês e Ano. E ainda 
pode ter elementos intermediários entre Ano e Mês (Trimestre) e Mês e Dia (Semana). Outro 
exemplo poderia ser em uma estrutura organizacional numa empresa: Na tabela contendo, 
cd_funcionario, nm_funcionario, cargo, cd_superior, o cd_superior pode determinar o nivel 
hierarquico de cada cargo. 
lembrando que no esquema estrela os dados ficam desnormalizados em uma única tabela de 
dimensões, como ocorre no exemplo anterior. 
OBS: As hierarquias são muito úteis para a navegação dos dados e possibilitam realizar as 
operações de Drill-Up (menos detalhamento) e Drill Down (mais detalhamento), detalhando mais ou 
menos os dados contidos na tabela Fato, conforme vimos em aula anterior. 
Carga das dimensões 
As dimensões são carregadas a partir de tabelas do banco de dados transacional. A primeira carga 
dos dados no Data Warehouse deve inserir todos os elementos existentes na tabela Origem, 
considerando algumas regras que possam existir, como por exemplo carregar no DW somente os 
registros ativos. (A VIVO que vende pacote telefônico, que precisa vender para clientes diariamente, 
precisa ser atualizado com a situação atual). 
Dimensões históricas 
Podem ser aplicadas para dar suporte a questões históricas (ao longo do tempo), como criar uma 
tabela de suporte que armazene as informações históricas dos atributos, relacionando a dimensão e 
quais são as alterações realizadas, como por exemplo data de início e data de fim de vigência. 
obs: As tabelas Fatos armazenam as métricas que serão descritas pelas Dimensões. Quanto maior a 
granularidade da tabela Fato, maior a quantidade de registros nela contidos. O grão atômico 
armazenado na tabela fato garante que qualquer consulta submetida pelo usuário poderá ser 
respondida. 
Tabela Fato Agregada 
As tabelas Fato armazenam métricas e a granularidade impacta na quantidade de registros. 
Agregações de dados são realizadas para melhorar o desempenho das consultas, aplicando funções 
como SUM, MIN, MAX, e AVG. Mas em uma tabela com milhões de registros, fica muito custoso para 
visualização em um dashboard levando um certo tempo para exibir os resultados. Por isso, podemos 
usar funções de agregação que visam um bom desempenho das consultas do DW. 
Elas armazenam informações pré-calculadas com menor volume e maior nível de granularidade em 
comparação às tabelas Fato Transacionais. A agregação evita custos adicionais em hardware e 
melhora o desempenho. 
Tabelas Fato Consolidada 
Combina dados de múltiplas tabelas de fato, unindo métricas relacionadas a diferentes contextos ou 
eventos em uma única tabela. Essa consolidação permite uma análise mais abrangente e facilita o 
acesso a dados que, de outra forma, estariam dispersos em várias tabelas. Como por exemplo uma 
tabela de fato consolidada pode unir dados de vendas de diferentes regiões ou produtos, permitindo 
análises agregadas sem a necessidade de consultar várias tabelas separadamente. 
Para que os dados de tabelas Fatos Transacionais possam ser consolidados é necessário ter pelo 
menos uma visão em comum entre elas e o nível de granularidade precisa ser o mesmo para serem 
consolidados. As tabelas Fato devem possuir uma visão comum aos dois assuntos e os dados 
consolidados devem estar no mesmo nível de granularidade. 
Resumo 
1. Quanto mais detalhes existirem, mais baixo será o nível de granularidade. Quanto menos 
detalhes existirem, mais alto será o nível de granularidade. 
2. Quando há um nível de granularidade muito alto, o espaço em disco e o número de índices 
necessários se tornam bem menores, mas há uma correspondente diminuição da 
possibilidade de utilização dos dados para 
3. Um exemplo de floco de neve especializando tabelas dimensão por decomposição 
hierárquica. 
 
4. Se fosse estrela, não teria subdivisões já que este esquema é desnormalizado. 
 
 
Processo de ETL - Extração dos dados tema 7 
● Seguindo a trilha do ciclo de vida de projetos de DW/DM, o ETL é o responsável por extrair 
os dados no sistema de origem, tratar e carregar definitivamente nas tabelas de DW/DM. 
● Esta etapa é uma das partes mais custosas do desenvolvimento(captação dos dados, 
integração dos dados de várias fontes.) 
● A construção é baseada nos insumos coletados no levantamento de requisitos, podendo, na 
evolução do projeto, adicionar mais requisitos. 
● O ETL acaba sendo um filtro de problemas encontrados nos dados para corrigi-los. 
● Segurança: avaliação de usuários que terão acesso a esses dados. 
Passos: 
1. Extração: Onde os dados são extraídos de sistemas de origem (estruturados ou não). 
Processo: acessa os dados na tabela de origem, copia e insere nas tabelas temporárias. 
2. Transformação: Aplicação de regras de negócios e tratamento dos dados, conforme as 
necessidades de qualidade e conformidade. Processo: acessa as tabelas temporárias, altera 
os dados conforme as regras definidas. 
3. Carga: Inserção dos dados transformados nas tabelas definitivas. Processo: lê os dados 
tratados nas tabelas temporárias, e insere-os nas tabelas dimensão e fatos,definidas na 
etapa no modelo de dados dimensional. 
OBS: Na Extração, obtém os dados e transfere para tabelas temporárias que servirão para manipular 
as tabelas na Transformação e depois transferir (realizar a carga) para as tabelas Dimensão e Fato 
definitiva. Mas para isso precisamos identificar as fontes de dados. 
Como por exemplo, posso ter 3 tabelas: Uma tabela de extração de dados, uma temporária (na 
transformação) e uma tabela pra onde eu vou levar esses dados. (em modelagem dimensional) 
Fontes de Dados: 
1. Estruturados: Bancos de dados relacionais, com dados organizados em tabelas. 
2. Semiestruturados: Dados com alguma organização (e.g., XML, JSON). 
3. Não estruturados: Dados sem formato definido (e.g., textos, vídeos). 
Métodos de extração: 
 O processo ETL pode ser feito por meio de linguagem procedural e por ferramentas que 
auxiliam o desenvolvimento das tarefas. A ferramenta de ETL conecta-se à base de dados de origem 
de onde os dados devem ser lidos, copia os dados, insere-os emuma área temporária, executa 
tarefas de tratamento e carrega os dados na base de dados de destino. 
Ferramentas de ETL: 
A ferramenta Pentaho Data Integrator (PDI) é usada para gerenciar o processo ETL, com 
sua interface gráfica Spoon, que permite a criação de transformações e jobs. Outros programas 
como PAN e Kitchen são usados para execução em lote de transformações e jobs (sequência de 
transformações). 
Periodicidade: 
A frequência da extração de dados varia conforme as necessidades da organização. Pode ser diária, 
semanal, ou até mesmo em tempo real, dependendo da demanda. 
 
Processo ETL – Transformação e Carga dos 
Dados - Tabela Dimensão tema 8 
Transformação dos dados 
● aplicada as regras de negócios definidas no levantamento de requisitos 
● transformações para adequar os dados a serem carregados no DW/DM. 
Passos para realização da transformação: 
● Selecionar as colunas necessárias; 
● identificar o significados dos dados (1 para Masculino, 0 para feminino) 
● Construção de colunas com métricas de cálculo (média do preço, a partir da coluna preco / 
quantidade de itens) 
● Junção de dados que possuem o mesmo conceito 
● Criação de chaves auxiliares (Surrogate - SK) - chaves com índice automático 
● Rotação ou transposição: transformar linhas em colunas ou colunas em linhas 
● Divisão de dados: desmembrar colunas (coluna data, para as colunas dia, mês e ano) 
● Agregações ou sumarização de dados 
Neste processo, aplica-se testes de qualidade de dados como por exemplo valores nulos, datas, 
elementos existentes… Até a devida correção, o processo fica parado ou coloca-se o valor “não 
informado”. 
Problemas encontrados em sistemas de dados geralmente são registrados em uma tabela de log, 
indicando a tabela ou dimensão onde ocorreu o erro, o registro problemático, e o tipo de erro, 
permitindo rastrear sua origem. Alguns sistemas notificam os gestores e responsáveis, evitando que 
os erros sejam esquecidos. 
A validação de dados visa garantir que os dados estejam de acordo com as regras estabelecidas. Em 
tabelas Dimensões, verifica-se se o registro já existe ou precisa ser atualizado, enquanto nas tabelas 
Fatos, verifica-se a validade da chave primária e a ausência de duplicação. Após esses processos, 
os dados são transformados e prontos para serem carregados nas tabelas definitivas. 
Carga dos dados 
Aqui é verificado se os dados estão prontos para serem carregados nas tabelas Dimensões e 
Fatos, conforme o modelo dimensional definido para o projeto. A periodicidade de carga varia 
conforme a necessidade da organização, e a latência dos dados — o tempo que leva para os dados 
do sistema de origem estarem disponíveis no DW/DM — deve ser analisada para atender às 
demandas da organização. 
Em alguns casos, os dados precisam ser apagados e recarregados, enquanto em outros, 
novos dados são apenas incrementados e os antigos, atualizados. Grandes sistemas rastreiam cada 
mudança nos dados, o que é útil para auditorias e compreensão das modificações realizadas. Esses 
aspectos devem ser cuidadosamente analisados e implementados conforme as necessidades de 
cada organização e contexto. 
 
A transformação e carga dos dados na ferramenta de ETL 
Steps são etapas que realizam tarefas específicas e que representam ações aplicadas aos dados ao 
longo do processo de ETL, formando um fluxo de trabalho que extrai, transforma e carrega os dados 
ao destino final. 
Steps utilizados para tratar dados: 
● Table input - extrai os dados do banco de dados 
● Filter Rows - Filtra linhas com base em instrução lógica 
● add sequence - Adiciona uma coluna com incremento (id por exemplo) 
● modified javascript value – Aplicar transformações customizadas aos dados 
● insert/update - Insere ou atualiza uma operação no banco de dados 
● text file output - Salva os dados transformados em um arquivo de texto(csv ou txt) 
Steps para transformação: 
 
● S1: Leitura de arquivo CSV 
● S2: Calculadora de valores 
● S3: Split de Colunas 
 
Processo ETL – Transformação e Carga dos 
Dados - Tabelas Fato tema 9 
A tabela fato armazena dados mensuráveis do negócio como quantidade e valores 
(numéricos) proporcionando análises de atividade de um empresa., além de armazenar a relação 
com as tabelas dimensões por meio da chave primária (SK). 
OBS: A carga dos dados em uma tabela Fato acontece após a carga das dimensões, pois é 
necessário que as chaves das dimensões existam antes de serem inseridas na tabela Fato, 
garantindo a integridade referencial. Para isso, as chaves são validadas e adicionadas a uma tabela 
temporária. 
Steps com exemplo real de vendas: 
● Table Input: Acessa a base de dados e extrai os dados necessários da tabela de vendas. 
● Filter Rows: Filtra os registros para incluir apenas as vendas que ocorreram dentro do 
período desejado (dia, mês ou ano). 
● Add Sequence: Gera as chaves SK (chaves primárias) para a tabela temporária, que será 
utilizada para associar as dimensões. 
● Table Output (Tabela Fato Temporária): Insere os registros filtrados e as chaves SK geradas 
na tabela Fato temporária. 
● Atualização das Chaves: As chaves válidas são então atualizadas na tabela temporária da 
tabela Fato, assegurando que todas as dimensões referenciadas estejam corretamente 
ligadas. 
● Table Input (Seleção para Inserção): Seleciona os dados da tabela Fato temporária que 
serão inseridos na tabela Fato definitiva. 
● Table Output (Tabela Fato Definitiva): Insere os dados validados e prontos na tabela Fato 
definitiva, completando assim o processo de carga. 
Carga da Tabela Fato Agregada 
A Tabela Fato Agregada contém dados sumarizados para análises em níveis superiores de 
granularidade. Por exemplo, a tabela Fato agregada de vendas pode armazenar informações 
mensais, onde as quantidades de produtos vendidos são somadas e o valor total calculado. 
Carga da Tabela Fato Consolidada 
A Tabela Fato Consolidada une dados de várias tabelas Fato, como vendas e estoque, para análises 
abrangentes. Um exemplo é calcular o lucro por fabricante, usando dados de vendas e estoque. 
Expurgo de Dados 
O expurgo de dados envolve a remoção de dados antigos ou raramente acessados da base de 
dados do DW/DM, armazenando-os em mídia para recuperação dos dados caso seja necessário. 
Isso é feito para otimizar o armazenamento e garantir a eficiência do sistema. Uma transformação 
deve ser criada para identificar quais dados expurgar e definir um período para arquivamento. 
Gerenciamento dos Processos 
oferece: 
● Confiabilidade - os processos serão executados de forma consistente 
● Disponibilidades - garantir que o ambiente esteja pronto para uso quando preciso 
● Gerenciabilidade: suporta a confiabilidade do ambiente e sua disponibilidade. 
O processo de ETL precisa ser orquestrado por um scheduler que definirá o momento em que o 
processo irá iniciar (cada próxima tarefa obedece a execução da antecessora). Se a ordem das 
tarefas não for respeitada, possíveis erros podem ser apresentados e o objetivo principal de todo o 
projeto, que é a disponibilidade do ambiente analítico, não será alcançado. 
 
 
 
Aplicações BI - o que é OLAP? tema 10
 
A última trilha de atividades no ciclo de vida de um projeto de DW é composta pela atividade de 
definição, Especificação de Aplicação de BI (BI Application Design), e construção da camada de 
visualização dos dados, Desenvolvimento das Aplicações de BI (BI Application Development). 
As consultas analíticas principais foram definidas no levantamento de requisitos. No entanto novas 
consultas poderão ser desenvolvidas posteriormente por usuários. 
As ferramentas devem apresentar recursos que atendam as necessidades do dinamismo das 
consultas em um DW/DM, diferente das ferramentas para ambientes operacionais (OLTP) que 
trabalham com alta velocidade mas ineficientes quanto a consulta e manipulação de dados em 
sistemas analíticos. 
OLAP (On-line Analytical Processing): OLAPé um sistema que permite analisar grandes volumes 
de dados de forma multidimensional, processando operações de cálculos complexos, essencial para 
BI (Business Intelligence). Ferramentas OLAP facilitam a análise com operações como: 
● Slice - seleção de dados de uma dimensão. “ seleciona as vendas realizadas em 2023” 
● Dice - fatia de dados de várias dimensões. “selecionar as vendas de 2023 na região sul” 
● Drill-down - aumentar o nivel de detalhe. “ total de vendas por trimestre ou mês” 
● Roll-up - reduzir o nível de detalhe. “ total de vendas por ano” 
● Drill-across - comparar dados de diferentes fatos. “ comparar vendas e devoluções” 
● Drill-through - detalhar informações além do DW. “ acessar vendas fora deste DW.” 
● Pivoting - mudar o eixo das dimensões. O filtro Região como coluna e Produto como linha 
vira Região como linha e produto como coluna. 
Características de ferramentas OLAP 
Desempenho, acessibilidade, arquitetura cliente/servidor e manipulação intuitiva são algumas das 12 
características, descritas por Edgar Codd, que ferramentas OLAP devem ter. 
Ferramentas OLAP 
Existem diversas no mercado, e podem ser classificadas como: 
● ROLAP: utiliza bancos de dados relacionais para armazenar dados. 
● MOLAP: utiliza bd's multidimensionais (cubos) para superior desempenho de consultas 
● HOLAP: combina ROLAP com MOLAP. dados resumidos ficam em um MOLAP enquanto os 
dados detalhados ficam em um ROLAP 
● DOLAP: ambiente de desktop. dados armazenados localmente ou em uma rede local, 
permitindo que usuários realizem análises diretamente em suas máquinas. 
 
Microsoft Power BI: Power BI é uma ferramenta popular de BI que permite visualizações interativas 
e fácil criação de análises. É acessível com uma versão gratuita, embora sem controle de acesso, e 
uma versão paga (Pro) com segurança de dados. O Power BI permite conectar-se a diversas fontes 
de dados, inclusive PostgreSQL, para criar relatórios e dashboards personalizados. 
Uso no Power BI: 
● Obter Dados: Conecta à base de dados para importar as tabelas necessárias (dimensões e 
fatos). 
● Modelo de Dados: Permite visualizar as tabelas e definir relacionamentos, criando um 
modelo dimensional que facilita a análise. 
diferença entre OLAP X OLTP 
Característica OLAP OLTP 
Performance otimização para leitura e geração de análise alta velocidade na manipulação de dados 
operacionais. ineficiente para geração de 
analise gerencial 
Permissões apenas inserção e leitura. usuário apenas leitura pode ser feita todas as operações de 
CRUD 
Estrutura dos dados armazenamento feito em DW com otimização de 
desempenho com grandes volumes de dados 
armazenamento feito em bancos de 
dados convencionais pelos sistemas de 
informação da organização. 
Foco nível estratégico da organização. análise e tomada 
de decisão. 
nível operacional da organização 
Volatilidade dados históricos e não voláteis não sofrem alteração dados voláteis passíveis de alteração 
e/ou exclusão 
Com relação ao OLTP, o OLAP tem uma menor frequência das atualizações, grande quantidade de 
dados e dados históricos trabalhados. 
Aplicações BI - construção de análise/ consulta no 
power Bi tema 11 
Análises OLAP: 
● O Power BI é uma ferramenta OLAP que permite criar visualizações interativas e análises 
dimensionais. 
● Consultas predefinidas são baseadas em necessidades mapeadas, como identificar produtos 
mais vendidos, clientes potenciais e gerenciamento de estoque. 
Funções M e DAX: 
o Power BI utiliza dois tipos de funções para criação de recursos: 
● Função M: Utilizada na preparação e transformação de dados (ETL) no Power Query, dentro 
no Power BI permitindo operações como dividir colunas e mesclar consultas. 
● Função DAX: Usada para cálculos analíticos, com funções como SUM, IF, AVERAGE e 
DISTINCTCOUNT. 
 
Exemplo de Aplicação: 
● Criação de uma coluna "Dia do Ano" na tabela de dados e agrupamento por estações do ano 
usando a função SWITCH (trabalha de maneira semelhante ao IF). 
OBS: o Power Query é uma ferramenta contida no BI que realiza transformações nos dados contidos 
no modelo de dados. 
Medidas: 
● Organizar medidas em uma pasta específica no Power BI para fácil acesso, utilizando 
funções como SUM para calcular a quantidade de produtos vendidos e receita. 
Visualizações e Filtros: 
● Construção de visualizações, como gráficos de rosca e barras empilhadas, e aplicação de 
filtros para análises específicas de anos e estações do ano. 
Conclusão: 
● O uso do Power BI permite análises interativas e a criação de relatórios dinâmicos que 
podem ser publicados online. 
 
 
 
	BI, Data Warehouse, Data Mart (Tema 2) 
	Business Intelligence (BI) 
	Pontos principais e fundamentais: 
	Tipos de Análise em BI: 
	Data Warehouse (DW) 
	Principais características do Data Warehouse: 
	Data Mart​ (DM) 
	Abordagens de Desenvolvimento: 
	Processos: 
	Sistema de apoio operacional x sistema de apoio à decisão 
	Arquitetura de um Data Warehouse / Data Marts 
	Passos importantes para construção de um BI 
	Passos importantes para a construção de um DW/DM 
	Conceitos importantes: 
	Metadados 
	Data warehouse / Data Marts self-service: 
	Data Mining - mineração de dados 
	Resumo final 
	Projeto de DW: especificação de requisitos (Tema 3) 
	Ciclo de vida do Data Warehouse (por kimball) 
	Fases do ciclo de vida do DW : 
	Levantamento de Requisitos 
	Metadados 
	Resumo final 
	Projeto de DW: Modelagem de dados dimensional - Esquema lógico ​​​​​​ (tema 4) 
	Modelagem de dados dimensional 
	Identificação das tabelas no modelo de dados dimensional 
	Tabela dimensões 
	Tabela fato 
	Esquema estrela 
	Esquema floco de neve 
	Representação em cubo 
	Resumo final 
	Projeto de DW: Modelagem de dados dimensional - Esquema físico ​​​​​​ (tema 5) 
	Implementação do Modelo de Dados Dimensional 
	Dimensões e Hierarquias, Tabelas Fato e Agregações​​​​​​​​​tema 6 
	Dimensões 
	Hierarquia 
	Carga das dimensões 
	Dimensões históricas 
	Tabela Fato Agregada 
	Tabelas Fato Consolidada 
	Resumo 
	Processo de ETL - Extração dos dados ​​ tema 7 
	Fontes de Dados: 
	Métodos de extração: 
	Ferramentas de ETL: 
	Periodicidade: 
	Processo ETL – Transformação e Carga dos Dados - Tabela Dimensão​​​ ​​tema 8 
	Transformação dos dados 
	Carga dos dados 
	A transformação e carga dos dados na ferramenta de ETL 
	Processo ETL – Transformação e Carga dos Dados - Tabelas Fato​​​ ​​tema 9 
	Carga da Tabela Fato Agregada 
	Carga da Tabela Fato Consolidada 
	Expurgo de Dados 
	Gerenciamento dos Processos 
	Aplicações BI - o que é OLAP?​​​​tema 10​ ​​ 
	Características de ferramentas OLAP 
	Ferramentas OLAP 
	Aplicações BI - construção de análise/ consulta no power Bi​​​​​​​​​ tema 11 
	Análises OLAP: 
	Funções M e DAX: 
	Exemplo de Aplicação: 
	Visualizações e Filtros: