Apostila Texto - ADD (1) Datawarehouse

Análise dimensional e Data Warehouse
Fernando Hadad Zaidan
2016
Análise Dimensional e Data Warehouse
Fernando Hadad Zaidan
©Copyright do Instituto de Gestão em Tecnologia da Informação.
Todos os direitos reservados.
Análise dimensional e Data Warehouse . 2

Sumário
Capítulo 1 – Revisão da Modelagem Relacional .............................................................................................4

Introdução ...............................................................................................................................................4
Modelo e modelagem de dados ...................................................................................................................4
Modelagem relacional ................................................................................................................................5
MER: Modelo de Entidades e Relacionamentos ..............................................................................................5
Normalização ......................................................................................................................................... 10
Capítulo 2 – Fundamentos do design dimensional ........................................................................................ 11

Introdução ............................................................................................................................................. 11
Tabelas fato e dimensões ......................................................................................................................... 12
Fases da modelagem dimensional ............................................................................................................. 13
Estruturas do modelo dimensional ............................................................................................................. 14
Capítulo 3 – Arquitetura do Data Warehouse ............................................................................................... 16

Introdução ............................................................................................................................................. 16
Data Warehouse ..................................................................................................................................... 17
Granularidade, métricas e indicadores ....................................................................................................... 20
Dimensões conformadas e chaves no modelo dimensional ............................................................................ 22
Capítulo 4 – Tabelas dimensionais e design das dimensões ........................................................................... 23

Fundamentos e conceitos ......................................................................................................................... 23
Hierarquias em dimensões ....................................................................................................................... 24
Dimensões compartilhadas ....................................................................................................................... 25
Dimensões típicas e seus atributos ............................................................................................................ 25
Capítulo 5 – Tabelas Fato ......................................................................................................................... 27

Conceitos ............................................................................................................................................... 27
Métricas e granularidade .......................................................................................................................... 27
Fatos e seus dados.................................................................................................................................. 27
Dados heterogêneos na tabela Fato ........................................................................................................... 28
OLAP ..................................................................................................................................................... 29
Conceitos de Cubos ................................................................................................................................. 30
Capítulo 6 – Cubos .................................................................................................................................. 31

O cubo .................................................................................................................................................. 31
Slice X Dice ............................................................................................................................................ 32
Capítulo 7 – Construção do DW ................................................................................................................ 33

As fases para construção de um DW .......................................................................................................... 33
A construção de um DW........................................................................................................................... 33
Erros comuns a serem evitados na modelagem dimensional e considerações finais ......................................... 35
Referências ............................................................................................................................................ 37

Capítulo 1 – Revisão da Modelagem Relacional
Introdução
Atualmente, armazenar, buscar e tratar informação são etapas cruciais

em qualquer área do conhecimento. Praticamente todas as atividades da
vida moderna envolvem sistemas de informação. E a maioria destes está
relacionada aos bancos de dados.
Um banco de dados é uma coleção de dados relacionados. Quanto
maior a quantidade e a complexidade das informações, mais difícil fica a
manipulação destas. Para racionalizar os processos de coleta,
armazenagem, busca e manipulação de dados, existem diversos tipos de
BD.
Modelo e modelagem de dados
Um modelo é uma representação simplificada de algum fenômeno do

mundo real. Facilita a compreensão de relações complexas. Os modelos
podem substituir complexidade por simplicidade.
Deve-se procurar modelos que possam representar precisamente as
ações que necessitamos. O modelo melhora em valor e aumenta a
habilidade de quem o utiliza, na medida em que descreve com precisão
aquilo que procura representar.
A modelagem de dados é o processo de especificação das estruturas de
dados e regras de negócio para a definição de um sistema de informação.
A modelagem de dados produz o chamado modelo conceitual de dados.
Esse modelo pode ser utilizado tanto no projeto de um sistema, quanto
no projeto de banco de dados relacional. Não podemos projetar o banco
de dados sem antes modelar os dados. A modelagem de dados é essencial
no processo de análise e projeto de sistemas. Ela é usada no
planejamento, na análise estruturada e no projeto de banco de dados.

Modelagem relacional
A modelagem relacional resultou de um estudo teórico realizado por

Edgar Frank Codd (Ted Codd), apresentado em um artigo publicado em
1970 e implementado somente nos anos 1980. Tem por base a teoria dos
conjuntos e álgebra relacional.
O Modelo relacional revelou-se ser o mais adequado e flexível para
solucionar diversos problemas que se colocam no nível da concepção e
implementação da base de dados.
Um modelo relacional é representado por um banco de dados como um
conjunto de relações. Surgiu devido às seguintes necessidades:
- Aumentar a independência dos dados nos SGDB (sistemas gerenciadores
de banco de dados)
- Prover um conjunto de funções apoiados na álgebra relacional para
armazenamento e recuperação de dados.
Na modelagem relacional os caminhos não são pré-definidos para fazer

acesso aos dados como nos modelos anteriores. Ele implementa
estruturas de dados organizadas em relações. Para trabalhar com as
tabelas, algumas restrições precisaram ser impostas para evitar
problemas indesejáveis, como:
- Repetição de informação
- Perda de informação
- Incapacidade de representar parte da informação
MER: Modelo de Entidades e Relacionamentos
Trata-se de um modelo de dados conceitual de alto-nível dos dados,

além de muito popular. O mundo real pode ser visto como um conjunto
de entidades e de relacionamentos entre as mesmas – visão abstrata.
Todos os dados são visualizados como fatos específicos sobre entidades,

relacionamentos e atributos. Através do MER podemos ter uma fotografia
do sistema. Os principais elementos do modelo que descrevem as regras
de negócio:
• Entidades
• Relacionamentos
• Atributos

Os elementos gráficos do MER são:
Entidade
Relacionamento
Atributos identificadores
Atributo qualificador

Entidade:
“Coisas” ou objetos do mundo real. Uma entidade é algo do mundo real,
com existência física ou lógica, sobre o qual se deseja armazenar
informações na base de dados. É onde os dados são armazenados e é
Representada por um conjunto de atributos. Ex.: empresa, empregado,
pessoa, lugar, cliente, nota fiscal... etc.
Atributo:
Abstração de uma propriedade de uma entidade ou de um
relacionamento.
- Nada mais é do que a informação associada à entidade ou relacionamento.
- Os atributos são os dados referentes à entidade.
Os atributos que nunca se repetem em uma entidade, chamamos
de atributo-identificador, que são candidatos à chave-primária das
tabelas.
Relacionamento:
Associação entre diferentes entidades. A ligação conceitual entre as
entidades é chamada de relacionamento. Definimos relacionamento como
o fato, o acontecimento que liga dois objetos, duas “coisas” do mundo
real. Os relacionamentos são os elementos que nos dão o sentido da
existência destes objetos e suas interrelações.
Cardinalidade:
Expressa o número de entidades às quais outra entidade pode estar
associada. Ex:
- um para um (1-1);
- um para muitos ou muitos para um (1-N) ou (N-1);
- muitos para muitos (N-N).

A seguir uma imagem com os conceitos do MER:
E abaixo temos um MER de duas entidades e a notação de suas

cardinalidades:
Agora temos mais um exemplo quando transformamos um

relacionamento em uma entidade associativa, pois o relacionamento N-N
entre entidades exige esta modelagem.

Outro exemplo de MER de um pequeno sistema de biblioteca onde os
alunos solicitam o empréstimo de livros:
Normalização
A normalização é uma técnica que visa agrupar os itens de dados em

entidades onde estes atributos são totalmente dependentes da chave
primária dessa entidade. É uma forma de organizar e simplificar o
conteúdo das entidades. O produto final da normalização é chamado de
relações normalizadas, o qual produz formas de arquivamento mais
simples que contém as mesmas informações da entidade original, sem os
defeitos que a entidade possa apresentar. Divide-se em três formas
normais:
• 1ª forma normal (1FN): não contém grupos repetitivos de itens de
dados.
• 2ª forma normal (2FN): uma relação está na 2ª FN quando os
valores de cada domínio dependem da chave inteira da relação e não de
parte da chave.
• 3ª forma NORMAL (3FN): uma relação está na 3FN se todos os
domínios que não são chave são dependentes exclusivamente da chave
e de nenhum outro.
Outras formas normais: Existem ainda duas outras Formas Normais, a
quarta e a quinta. Porém, estas formas normais têm aplicação somente
em casos muito específicos. Na prática, considera-se que as relações que
estejam na Terceira Forma Normal já apresentam simplicidade e ausência
de redundância, suficientes para um bom projeto.

Capítulo 2 – Fundamentos do design dimensional
Introdução
A modelagem dimensional é a técnica utilizada para ter uma visão

multidimensional dos dados e não uma visão simplista, como na modelagem
relacional. Abaixo temos dois comparativos do modelo relacional com o
modelo dimensional.
Aplicativos transacionais Sistemas analíticos

(Modelo relacional) (Modelo dimensional)
Visão do atual e do real Visão histórica e de tendência
Solução para requisitos conhecidos Permitir a identificação de
fatos desconhecidos
Abrangência restrita Abrangência ampla
Informação produzida por Informação produzida pelo
profissionais de informática próprio usuário
Custo e tempo para obtenção da Informação obtida com baixo custo
informação altos
Informação disponível a poucos Informação democratizada
usuários
Aplicativos transacionais Sistemas analíticos

Característica
(Modelo relacional) (Modelo dimensional)
Atualizações Mais frequentes Menos frequentes
Tipo de informação Detalhes Agrupamento
Quantidade de
Poucos Muitos
Dados
Precisão Dados atuais Dados históricos
Complexidade Baixa Alta
Consistência Microscópica Global
EIS (Executive
Exemplos CRM, ERP, Supply Chain
Information System)
Dimensões, Medidas e
Terminologia Linhas e colunas
Fatos
Tabelas fato e dimensões
A modelagem dimensional é constituída basicamente de dois tipos

de tabelas:
Tabelas fatos
• Contêm valores (métricas)
• E as chaves
• Podem existir várias no modelo
• Pk=concatenação de Fk das dimensões
• Uso de chaves sequenciais

Tabelas dimensões
• Pontos de entrada
• Hierarquias e níveis de quebra
• Granularidade coerente com fato
Fases da modelagem dimensional
As fases da modelagem dimensional são de extrema importância

para serem cumpridas em um projeto de BI. As fases podem ser divididas
em:
 Contato e definição da área de negócios
 Levantamento das necessidades
 Planejamento do projeto
 Objetivos
 Dificuldades para encontrar as informações almejadas
 Indicadores estratégicos
 Métricas iniciais
 Restrições de informações
 Estrutura e tecnologia
No levantamento das necessidades, deve ser considerado:
– Dificuldades e restrições
• Indicadores, métricas e comparativos
• Sempre observar as dimensões e as combinações
– Importante ter o modelo de dados existentes:
– MER
– Arquivos, dados manuais, planilhas eletrônicas.

Estruturas do modelo dimensional
A estrutura de um modelo dimensional é importante no que tange aos

seguintes aspectos:
- Quantidade de tabelas
- Disposição das tabelas
- Normalização ou desnormalização
- Acesso
- Desempenho
- Hierarquias
- Cascateamento das tabelas
Existem quatro modelos, cada com suas características, como mostra a

figura a seguir:
- Star Schema (estrela)
- Snowflake (flocos de neve)
- Starflake
- Galaxy
Desnormalização:
Na modelagem do banco de dados relacional aplicamos a normalização
(formas normais). Contudo, no DW ou Data Marts faz-se necessário, em
alguns casos, desnormalizar as tabelas. Visa obter o grau de desempenho
elevado ao reduzir o número de junções das tabelas. Agilidade na
consolidação também é uma característica da desnormalização.


 SCHEMA ESTRELA
– Dimensões desnormalizadas
– Voltado para acessos com mais performance
– Hierarquias achatadas
– Uma tabela fato ao centro e as dimensões ligadas a ela.
 SCHEMA SNOWFLAKE (flocos de neve)

– Modelo similar a Entidades e Relacionamentos
– Tabelas em cascata
– Normalizado
– Hierarquias mantidas
– Muitas tabelas
– Muitas junções-1:n
 SCHEMA STARFLAKE
– Combinação das duas anteriores
– Dimensões com N x N com outras tabelas
 GALAXY SCHEMA
– Várias fatos
– As dimensões podem estar dispostas de formas diversas
– As tabelas fatos não se relacionam
Capítulo 3 – Arquitetura do Data Warehouse
Introdução
A teoria de banco de dados foi difundida e está disponível há alguns

anos. Nesta teoria, os dados eram armazenados com o propósito maior de
realizar operações transacionais, seja em tempo real, seja em um
intervalo de tempo programado. Mas também eram utilizados, em menor
frequência, para a execução de processos analíticos.
O conceito de Data Warehouse (armazém de dados) surgiu no início
da década de 80, quando os sistemas gerenciadores de banco de dados
(SGBD) apareceram como facilitadores da computação de dados, e
consequentemente, facilitadores na tomada de decisão. Alguns autores
dizem que Inmon é o “pai do Data Warehouse”, isto pelo fato de Inmon
ter observado que os dados poderiam ser organizados em um ativo
corporativo que o mesmo nomeou de Data Warehouse.
Data Warehouse é uma coleção de dados orientada por assuntos,
integrada, variante ao tempo, e não volátil, que tem por objetivo dar
suporte aos processos de tomada de decisão.
Orientado por assunto: a primeira característica do DW é que ela é
orientada em torno dos grandes assuntos da empresa.
• Integrado: os dados encontrados dentro do armazém de dados
serão sempre, sem possibilidades de exceção, integrados.
• Não volátil: modificações nos dados já existentes não ocorrem no data
warehouse.
• Variante no tempo: os dados no Data Warehouse podem ser
apresentados em tempos determinados.
Temos duas estratégias para elaboração de um DW, que são
defendidas pelos dois principais autores:
Monolítica - tudo de uma vez
• Bill Inmon - DW

Incremental - passo a passo
• Ralph Kimball - Data Marts
Também podemos pensar em uma convergência destes dois mundos:

– Data Marts com plano de integração definido para o DW
– Integração evolutiva – implementação gradativa
Data Warehouse
Os dados disponíveis nos Data Warehouses poderão ser acessados

pelos gerentes, analistas e usuários finais, possibilitando a realização de
várias tarefas, tais como processamento analítico (OLAP) ou inteligência
empresarial (BI – Business Intelligence).
O Data Warehouse - armazém de dados - armazena o acúmulo de

dados históricos. Pode conter dados por muitos anos, com tamanho de
armazenamento muito grande. Normalmente, depois de completadas as
transações comerciais na aplicação ou no armazenamento de dados
operacionais, elas são transferidas para o warehouse. Também pode-se
estabelecer uma periodicidade adequada para esta transferência dos
dados.
Para o funcionamento da inteligência empresarial, os dados brutos
operacionais, mantidos nos bancos de dados corporativos, espalhados por
vários sistemas da organização e em fontes heterogêneas, são colocados
(processo de ETL – extração, transformação e carga) em um Data
Warehouse. Usando ferramentas de inteligência nos negócios, são feitas
consultas, relatórios diversos, ou quaisquer outras análises, como gráfico
e relatórios. Pode ser iniciado também o processo de Data Mining -
mineração de dados.
No Data Mining são fornecidas percepções dos dados corporativos que
não podem ser obtidos com o OLAP. São feitas descobertas de padrões e
relacionamentos ocultos em grandes bancos de dados e inferindo regras a
partir deles para prever comportamentos futuros. Tais modelos e regras
são utilizados para guiar o processo de decisão e prever o efeito de
decisões. Os tipos de informações que são obtidos com o data mining
incluem: associações; sequências; classificações; aglomerações e
prognósticos. Esses sistemas podem realizar análises de alto nível quanto
a padrões ou tendências, mas também podem esmiuçar os dados para
revelar mais detalhes, se forem necessários.
Figura: Como funciona a inteligência empresarial. Fonte: TURBAN, RAINER.
Normalmente, o Business Intelligence possui quatro grandes

componentes: o Data warehouse (DW), que é a fonte de dados; a análise
de negócios, formada por uma colação de ferramentas para manipular e
analisar os dados do Data warehouse e o Business performance
management (BMP), para monitorar e analisar o desempenho e uma
interface de usuário. A figura abaixo faz esta representação.
Uma arquitetura de alto nível do B.I. Fonte: Turban et al. ,2004, p.30
O Data Warehouse (DW) é um componente central de uma
infraestrutura de Business intelligence (BI), funciona como um repositório,
ou seja, um armazém de análise de informações numéricas estáveis e
verificáveis.
O projeto de DW mais conhecido é denominado banco de dados
dimensional. Este banco de dados trabalha com tabelas denominadas fato
e dimensão. Os fatos armazenam valores detalhados de medidas e as
tabelas de dimensão, que armazenam os membros das dimensões,
denominados atributos. O quadro 1 demonstra a comparação entre o
modelo dimensional com o modelo relacional.
Quadro 1 – Comparação entre modelos relacionais, E/R e modelos dimensionais

Modelo dimensional Modelo relacional – ER
Padrão de estrutura mais Modelo mais complexo
fácil e intuitiva
Anterior ao MER, anos 60 Ênfase nos bancos de dados
relacionais, anos 70
Tabela fato e tabela Tabelas que representam
dimensão dados e relacionamento
Tabelas de fatos são o Todas as tabelas são
núcleo normatizadas normatizadas
Tabelas de dimensão são os As tabelas são
pontos de entrada indistintamente acessadas e
de filtros iniciais
Tabelas de dimensão Todas as tabelas são
opcionalmente normatizadas
normatizadas
Modelo facilmente “joined” Maior dificuldade de “join“
pelo número maior de
tabelas
Leitura mais fácil do modelo Maior dificuldade de leitura
por usuários não por usuários não
especializados especializados
Fonte: Barbieri, 2002, p. 38
De forma geral, e como é demonstrado na figura abaixo, a estrutura do

DW está em evolução. A evolução pode ser considerada como uma
resposta à complexidade deste ambiente e à dificuldade de integrar todos

os componentes. Os sistemas transacionais (OLTP) dão o início a esta
construção incremental.
Figura: Forma geral da evolução da arquitetura do Data Warehouse.
Observa-se nesta figura os Data Marts. São pequenos DW que atendem

a certas áreas específicas das organizações. As vantagens de se trabalhar
com Data Marts são: custo mais baixo, testes facilitados, menor tempo de
implantação.
Granularidade, métricas e indicadores
O Grão é a unidade de medida de um indicador para serem obtidos

resultados de desempenho. Tem o nível atômico de dados nas tabelas
fato e dimensão. Considerações que devem ser levadas em conta:
 Volumes de dados
Necessidade de informações para o negócio
Disponibilidade do dado fonte
Algumas possibilidades de granularidade:

• Nível de transações (Documento da NF)
• Nível de item de um documento (Item da NF, da OS, do Pedido)
• Tempo:
– Nível diário
– Nível semanal
– Nível mensal, etc.
A granularidade da tabela Fato está diretamente relacionada com as
granularidades das tabelas dimensões. Para implantação eficiente de todos
os conceitos do BI, a utilização de indicadores de desempenho é
fundamental como instrumento estratégico para o processo de tomada de
decisão. Os indicadores permitem, por meio de análise e interpretação de
dados, a evidência de fatos que facilitam o processo.
As medidas de desempenho podem focalizar o futuro e não apenas o
registro do desempenho passado. O estudo dos indicadores é
fundamental para uma projeção futura, com elaboração de tendências e
metas.
Segundo Leme Filho, “os indicadores de desempenho têm como principal
objetivo apresentar de forma clara a situação de determinados assuntos de
negócios que a empresa considera como vitais”. O autor mostra que, para
serem intuitivos, os indicadores de desempenho devem ser representados
através de gráficos e cores, com poucas informações escritas e números.
Sendo assim, a representação visual facilita o entendimento por parte
dos gestores da evolução e projeção dos resultados obtidos pelas
empresas e permite um ganho no processo de tomada de decisão, além
de fornecer uma interface mais amigável para o mesmo.
As métricas são as medicas colocadas na tabela fato para obtenção das
análises. São ligados à granularidade. Escolher para a tabela Fato os
atributos numéricos. Os típicos são:
• Quantidade
• Valor
• Custo do produto
• Lucro
• Consumo
• Etc.

Dimensões conformadas e chaves no modelo dimensional
Assim como a granularidade, o conceito de dimensões conformadas

é um dos pilares da modelagem dimensional. Diz respeito às entidades
(dimensões) que servem de perspectivas de análise para qualquer assunto
da organização. Ou seja, as dimensões estão em conformidade com os
assuntos escolhidos.
Modelar dimensões conformadas significa que seus atributos não são
conflitantes com um ou mais Data Marts ou com o Data Warehouse. Ex.:
se estivermos falando de unidades vendidas (métrica) de uma loja
(dimensão) em um mês (dimensão), estamos falando do mesmo dado de
um produto (dimensão).
A modelagem dimensional tem por meta construir DW com
dimensões conformadas e fatos com granularidade mais próximos
possíveis.
No intuito de criar maior estabilidade, as chaves no modelo
dimensional tem um princípio diferente do modelo relacional. No
relacional utilizamos muito chaves inteligentes, que carregam significado
nas mesmas. Já no modelo dimensional, para dimensões e fatos,
utilizamos Surrogate Key. Surrogate Key = chave numérica sequencial.
Sem nenhum sentido embutido, evitando conflito de mudanças de
chave
Contudo, nas tabelas dimensões, mantemos as chaves inteligentes do
modelo relacional para a identificação dos registros

Capítulo 4 – Tabelas dimensionais e design das dimensões
Modelar corretamente o DW será um diferencial para o BI. As análises

dependem diretamente de como o DW foi modelado.
Fundamentos e conceitos
As tabelas dimensão são pontos de entradas da estrutura do DW. A

principal função é reunir os atributos que serão utilizados para qualificar e
sumarizar as consultas analíticas. São compostas de atributos textuais.
Dimensões e seus atributos servem também como filtros e como
cabeçalho (header) dos relatórios. Dimensões típicas:
– Produto/serviço: o que vendo
– Fornecedor: quem vende
– Cliente: quem compra
– Tempo: quando foi feito a compra
– Local: loja, cidade, estado, etc. – onde
Abaixo temos uma modelagem Estrela de um DW. Ao centro a tabela
foto (fenda). E conectado a ela as dimensões (d_vendedor; d_tempo;
d_filial; d_produto).

Características das dimensões
As dimensões são criadas para descrever todos os atributos necessários.

Devem ter atributos descritivos, porém sem campos nulos. Normalmente
um DW ou Data Mart tem entre 4-15 dimensões:
• Menos: faltou observação (tempo-espaço-tipo)

• Mais: dimensões supérfluas ou necessita a divisão do DW
As dimensões são os descritores das Fatos. Aplica o conceito de

SK (surrogate key – chave sequencial) – para independência. Não se
esquecendo de manter, como atributo, a chave inteligente do BD
Relacional.
Hierarquias em dimensões
As dimensões normalmente têm hierarquias, e as hierarquias tem

níveis. Tipos de hierarquias - relacionamentos 1:N. As dimensões podem
ser relacionadas com mais de uma tabela fato, ou mesmo com mais de
uma dimensão no mesmo DW. O relacionamento entre as dimensões são
feitas dependendo de JOINS, o que compromete a performance das
consultas analíticas.
As operações de hierarquias são roll-up e drill-down. Estas operações
são normalmente realizadas segundo as hierarquias (1:N) das Dimensões,
mas não necessariamente. Ex:
– Tempo: dia  semana  quinzena  mês  trimestre  ano
– Produto: produto  sub categoria  categoria 
departamento
– Fornecedor: fornecedor  cidade  região
– EquipeDeVenda: equipe  região

Dimensões compartilhadas
As dimensões podem ser compartilhadas entre vários projetos de DW

ou Data Marts. É fundamental para a integração, pois será o ponto de
conexão entre as Fatos.
 Observar sempre a granularidade necessária para as dimensões:
– Tempo=> ano-semestre-trimestre-mês-dia
– Cliente=> tipo de cliente-cliente
– Geografia==>pais-região-estado-cidade-loja
Dimensões típicas e seus atributos
Sempre (ou na maioria dos casos) a dimensão TEMPO estará presente

nos DW. Os servidores tratam a dimensão tempo como especial:
– Podem ser obtidas diretamente de uma fonte simples: campo data de
uma tabela
– Podem ser obtidas de uma tabela fonte: dimensão tempo bem projetada
com dia, feriados, tags de fim de semana, etc.
Normalmente, define-se tempo como uma dimensão a ser

compartilhada com todos os Data Marts.
 Tabela dimensão TEMPO padrão:

– Chave SK – surrogate key (PK)
– Campo de data (chave inteligente do BD relacional)

– Dia-semana
– Número-do-dia-mês
– Número-dia-geral (corrido no ano - 01 a 365)
– número-semana-ano (01 a 52)
– Mês
– Trimestre
– Período – fiscal

 Estes atributos são apenas sugestivos para a tabela dimensão Tempo,
pois dependerá do levantamento das necessidades da organização.
 Tabela dimensão CLIENTE padrão:
– Chave SK (Pk)
– Chave inteligente do BD relacional
– Prenome e meio-nome
– Sobrenome
– Sexo
– Profissão
– Data nascimento
– Etc.
 Estes atributos são apenas sugestivos para a tabela dimensão Cliente,

pois dependerá da necessidade da organização.
 Algumas dicas quanto aos atributos:
- Escolher com cuidado os campos
- Campos candidatos a remoção:
 Campos usados por poucos usuários
 Campos que não tenham valor de negócio
 Campos de dimensões degeneradas, como número de
ordem/pedidos, caso a granularidade seja o item dessas
entidades

Capítulo 5 – Tabelas Fato
Conceitos
É tabela dominante (principal) em um modelo de DW - podem existir

várias no mesmo DW. Fica rodeada pelas tabelas Dimensão. O
armazenamento de valores das medidas e o volume de dados históricos é
muito grande. Para as PKs usa chaves SK (surrogate key – numérico,
sequencial, sem significado), e é a concatenação das FKs das Dimensões.
As tabelas Fato são compostas basicamente pelas chaves (atributos
qualitativos das tabelas Dimensão) e pelas métricas (atributos
quantitativos).
Métricas e granularidade
Escolher para a tabela Fato os atributos numéricos. Típicos:
• Quantidade
• Valor
• Custo do produto
• Lucro
• Consumo
• Etc.
Decidir a granularidade pensando nas dimensões. Ex: Hora ou Dia? As

dimensões deverão estar em conformidade (servir de perspectivas para
as análises). Ex: De acordo com a escolha (Hora ou Dia), dados das
dimensões deverão estar preparados.
Fatos e seus dados
Manter conformidade/coerência também entre fatos e as

medidas/valores, com o mesmo sentido, fórmulas de cálculos, etc. Lembre-
se, porém: as tabelas Fatos são gigantescas (alto volume) e isso requer
compromissos na escolha de seus campos. Compromisso entre performance
e armazenamento. Campos candidatos a remoção:

– Campos usados por poucos usuários
– Campos que não tenham valor de negócio
– Campos potencialmente derivados (conceito de elementos virtuais)
Ex: valor total (valor unitário * quantidade do item)
Dados heterogêneos na tabela Fato
Exemplo: Produtos heterogêneos na indústria financeira - Conta

corrente, seguro, empréstimo, poupança, habitação, etc. Diferentes fatos
e dados para cada linha de negócio. Dimensões comuns (clientes,
agências, tempo). Estratégia:
– Múltiplas tabelas fato e dados específicos
– Dimensões únicas e conformes

OLAP
OLAP: On-line Analytical Processing
Processamento analítico on-line. Refere-se ao conjunto de processos

para criação, gerência e manipulação de dados multimensionais para
análise e visualização pelo usuário em busca de uma maior compreensão
destes dados. É usual a expressão “ferramenta” OLAP, referindo-se aos
sistemas com estas funcionalidades e que são juntamente com o SGBD, a
base do ambiente de DW.
OLTP: On-line Transaction Processing
 Dados orientados a transações (T)
 Ambiente com alta taxa de transações
 Dados são atualizados
 Dados relacionais
OLAP: On-line Analytical Processing

 Dados orientados a análise (A) de informação
 Ambiente de baixa taxa de transações
 Dados são consultados
 Dados são atualizados em períodos de tempo
 Dados dimensionais
Conceitos de Cubos
Cubos são estruturas dinâmicas para gerar os relatórios OLAP. Podem

ter várias dimensões: tempo, região, produto, etc. Nossa visão consegue
perceber até três dimensões no Cubo, mas podem ter mais. Cubos
diferem de relatórios tradicionais (Transacionais) que são estáticos.

Capítulo 6 – Cubos
São estruturas de dados que formam um subconjunto de um banco de

dados grande (DW). Podem ser manipulados e visualizados por inúmeros
ângulos e diferentes níveis de agregação, onde é possível, através
de suas dimensões (faces ou eixos), analisar uma determinada situação.
Um cubo é criado tendo em mente o tipo de consulta que um
gerente de projeto deseja fazer. Ao projetar um cubo é importante levar
em conta as prováveis consultas que poderão ser feitas. O projeto de um
cubo deve priorizar a escolha e a organização das dimensões que podem
influenciar nas medidas relacionadas para a tomada de decisão.
DW e Data Marts são compostos por N cubos, porém o cubo é
implementado separadamente. Cada cubo é uma visão dimensional
de dados formado por:
– Uma tabela fato e N tabelas dimensões
– Pode ter mais de uma tabela fato, mas nunca interligadas – as
dimensões que as interligam
Cubos como visão dimensional podem ser materializados/ implementados
em:
– Consultas OLAP
– Forma física de tabelas relacionais vistas como estruturas dimensionais
Operações especiais permitem decompor um cubo de N dimensões em
sub-cubos de até três dimensões.
O cubo
Abaixo uma imagem característica do Cubo. Neste caso, está indicando

(um cubo branco) as vendas (métricas) na localização RJ (eixo Z), do
produto Bavária (eixo Y) no tempo T4 (eixo X).

Slice X Dice
Seleção e projeção do cubo de dados

Slice (fatia): seleção / projeção com variação de valores (fatia) de uma
ou mais dimensões. Exemplo: as vendas da região Norte, no ano 2011,
de todos os Produtos.
Dice (dados): seleção / projeção de valores fixos em todas as dimensões.

Exemplo: as vendas da região Norte, no ano 2011, do Produto X.

Capítulo 7 – Construção do DW
As fases para construção de um DW
É importante enumerar as fases de um projeto para construção de

um DW:
 Contato e definição da área de negócios
 Levantamento das necessidades
 Modelagem do DW
 Definição sobre a estrutura - estrutura (Star, Snowflake, etc.)
 Definição da granularidade
Menor – mais espaço
Maior – menos espaço
 Métricas
 Definição das dimensões e seus atributos
 Definição das chaves
 Relacionamentos das tabelas dimensão
 Tabelas Fatos
 Cubos
As fases que seguem são a implementação em uma ferramenta de
BI.
A construção de um DW
Vamos partir de um modelo relacional para mostrar a construção de um

DW. Abaixo temos um modelo clássico de um sistema de vendas (DER),
com seis tabelas. A empresa tem filiais, que possuem vendedores. Estes
realizam as vendas com seus respectivos itens. Os itens possuem produtos
que estão ligados à categorias dos produtos.

No levantamento das necessidades decidiu-se pela performance do DW
e o modelo estrela foi escolhido. Os gestores indicaram:
- os atributos que desejavam visualizar no DW
- as métricas (quantidade da venda e valor da venda)
De posse destas informações colhidas junto aos gestores, começou-se a
elaborar o DW. As chaves surrogate key (SK) foram fortemente
modeladas e as chaves inteligentes do DER foram preservadas.
Observa-se no modelo do DW abaixo, modelado a partir do DER anterior:
- escolha da estrutura Star (estrela)
- as chaves das dimensões são SK, como id-vendedor da tabela dimensão
d_vendedor
- presença das chaves inteligentes, como cod_vendedor da dimensão
d_vendedor
- atributos qualificadores, como nome_vendedor da tabela d_vendedor;
- presença da tabela tempo, padrão em um DW: d_tempo
- desnormalização realizada na tabela d_produto em função do modelo
estrela
- formação da chave primária composta da tabela fato (f_venda) a partir
das chaves das tabelas Dimensão, todas SK: id_vendedor + id_filial +
id_produto + id_tempo

- presença de mais um campo (cod_venda) para compor a chave primária
composta da Fato f_venda: este campo torna-se necessário na medida
em que a composição da chave for apenas dos 4 campos (id_vendedor +
id_filial + id_produto + id_tempo), haverá Key Violation na chave
primária. Portanto, o cod_venda preservará a unicidade da chave primária
da tabela Fato
- Presença na tabela fato das métricas: que_venda_prod e
valor_venda_prod
Erros comuns a serem evitados na modelagem dimensional e considerações finais
Aceitar a premissa de que os responsáveis pelos sistemas transacionais

da organização são muito importantes e ocupados para gastar tempo
com a equipe da modelagem dimensional.
Projetar o modelo dimensional baseado em um relatório específico.
 Não conversar com os usuários de negócio.
Não definir uma equipe que preserve o conhecimento após o término do
projeto.
 Não obter patrocinadores fortes.
 Os objetivos não são diretos com os negócios da organização.
 Não desenvolver uma forma eficiente de comunicar bem o projeto.
Definir uma metodologia que não seja prática e interativa, com
entregas em tempo razoável.
Colocar atributos de texto usados para restrições e agrupamento
numa tabela de fatos.

 Limitar atributos em dimensões para economizar espaço.
Ignorar a necessidade de cuidar de mudanças em atributos de
dimensões.
 Resolver todos os problemas de desempenho de consultas adicionando
mais hardware.
 Usar chaves operacionais ou “inteligentes” para junções de tabelas de
dimensão com tabela de fatos.

Referências
ADAMSON, Christopher. Star schema: the complete reference. McGraw

Hill, 2010.
BARBIERI, Carlos. BI - Business Intelligence - Modelagem & Tecnologia.
São Paulo: Axcel Books, 2002.
BARBIERI, Carlos. Bi2 - Business Intelligence - modelagem e qualidade.
Rio de Janeiro: Editora Campus Elsevier, 2011.
INMON, W. H. Building the Data Warehouse. Wiley, 3a ed. 2002.
JACOBSON, Reed; MISNER, Stacia; CONSULTING, Hitachi. Microsoft SQL
Server 2005 Analysis Services passo a passo. Porto Alegre, Bookman,
2007.
KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit: The
Complete Guide to Dimension Modeling (2a Edition). John Wiley & Sons,
 2002.
LAUDON, K. C.; LAUDON J. P. Sistemas de informação gerenciais:

administrando a empresa digital. 7. ed. São Paulo: Prentice Hall, 2007.
LEME FILHO, Trajano. Business Intelligence no Microsoft Excel. Rio de
Janeiro: Axcel Books do Brasil, 2004.
MACHADO, Filipe Nery Rodrigues. Tecnologia e projeto de Data
Warehouse: uma visão multidimensional. São Paulo: Érica, 2004.
TAVARES, Mauro Calixta. Gestão estratégica. São Paulo: Atlas, 2005.
TURBAN, Efraim; RAINER JR, R. K.; POTTER, E. P. Administração de
tecnologia da informação: teoria e prática. 3aed. Rio de Janeiro: Elsevier,
2005.

Apostila Texto - ADD (1) Datawarehouse

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Apostila Texto - ADD (1) Datawarehouse

Încărcat de

Drepturi de autor:

Formate disponibile

Análise dimensional e Data Warehouse

Fernando Hadad Zaidan

Análise dimensional e Data Warehouse . 2

Capítulo 1 – Revisão da Modelagem Relacional .............................................................................................4

Capítulo 2 – Fundamentos do design dimensional ........................................................................................ 11

Capítulo 3 – Arquitetura do Data Warehouse ............................................................................................... 16

Capítulo 4 – Tabelas dimensionais e design das dimensões ........................................................................... 23

Capítulo 5 – Tabelas Fato ......................................................................................................................... 27

Capítulo 6 – Cubos .................................................................................................................................. 31

Capítulo 7 – Construção do DW ................................................................................................................ 33

Análise dimensional e Data Warehouse . 3

Atualmente, armazenar, buscar e tratar informação são etapas cruciais

Modelo e modelagem de dados

Um modelo é uma representação simplificada de algum fenômeno do

Análise dimensional e Data Warehouse . 4

A modelagem relacional resultou de um estudo teórico realizado por

Na modelagem relacional os caminhos não são pré-definidos para fazer

MER: Modelo de Entidades e Relacionamentos

Trata-se de um modelo de dados conceitual de alto-nível dos dados,

Análise dimensional e Data Warehouse . 5

Análise dimensional e Data Warehouse . 6

Análise dimensional e Data Warehouse . 7

Análise dimensional e Data Warehouse . 8

E abaixo temos um MER de duas entidades e a notação de suas

Agora temos mais um exemplo quando transformamos um

Análise dimensional e Data Warehouse . 9

A normalização é uma técnica que visa agrupar os itens de dados em

Análise dimensional e Data Warehouse . 10

A modelagem dimensional é a técnica utilizada para ter uma visão

Aplicativos transacionais Sistemas analíticos

Aplicativos transacionais Sistemas analíticos

A modelagem dimensional é constituída basicamente de dois tipos

Análise dimensional e Data Warehouse . 12

Fases da modelagem dimensional

As fases da modelagem dimensional são de extrema importância

Análise dimensional e Data Warehouse . 13

A estrutura de um modelo dimensional é importante no que tange aos

Existem quatro modelos, cada com suas características, como mostra a

Análise dimensional e Data Warehouse . 14

 SCHEMA SNOWFLAKE (flocos de neve)

A teoria de banco de dados foi difundida e está disponível há alguns

Análise dimensional e Data Warehouse . 16

Também podemos pensar em uma convergência destes dois mundos:

Os dados disponíveis nos Data Warehouses poderão ser acessados

O Data Warehouse - armazém de dados - armazena o acúmulo de

Figura: Como funciona a inteligência empresarial. Fonte: TURBAN, RAINER.

Normalmente, o Business Intelligence possui quatro grandes

Quadro 1 – Comparação entre modelos relacionais, E/R e modelos dimensionais

De forma geral, e como é demonstrado na figura abaixo, a estrutura do

Análise dimensional e Data Warehouse . 19

Figura: Forma geral da evolução da arquitetura do Data Warehouse.

Observa-se nesta figura os Data Marts. São pequenos DW que atendem

Granularidade, métricas e indicadores

O Grão é a unidade de medida de um indicador para serem obtidos

Algumas possibilidades de granularidade:

Análise dimensional e Data Warehouse . 21

Assim como a granularidade, o conceito de dimensões conformadas

Análise dimensional e Data Warehouse . 22

Modelar corretamente o DW será um diferencial para o BI. As análises

As tabelas dimensão são pontos de entradas da estrutura do DW. A

Análise dimensional e Data Warehouse . 23

As dimensões são criadas para descrever todos os atributos necessários.

• Menos: faltou observação (tempo-espaço-tipo)