1) Uma data warehouse é uma coleção de dados integrados e não voláteis destinados a suportar o processo de tomada de decisão. 2) As dimensões fornecem informações contextuais sobre os fatos e são ligadas a estas através de chaves estrangeiras. 3) O processo ETL extrai, transforma e carrega dados de fontes operacionais para a data warehouse.

1. Data Warehouse
Uma data warehouse é uma colecção de dados temáticos,
integrados, que variam ao longo do tempoe não voláteis
destinados a suportar o processo de tomada de decisão.‖—W. H.
Inmon
Facto: Dado de interesse para a análise
Medidas: Atributos, normalmente numéricos, que descrevem os factos de diferentes pontos
de vista.
Tipos de factos:
1. Factos aditivos: São factos em que as suas medidas se podem somar.
2. Factos semi-aditivos: São factos que expressam medidas de intensidade (AVG)
e como tal não se podem somar.
3. Factos não aditivos : São factos que servem para expressar eventos e/ou
ocorrências.
Dimensões: São tabelas com chaves simples que se ligam às tabelas dos factos.
ETL (Extract Transform Load)
Antes de se colocar a informação na data warehouse á que passa-la pela “Staging Area” onde
sobre um conjunto de processos. A necessidade de fazer este processo vem do facto de que
nem sempre queremos informação de todas as fontes que temos disponíveis e nem sempre a
queremos como ela esta nas bases de dados operacionais (OLTP).
 EXTRACT : Processo que extrair os dados das fontes operacionais
 TRANSFORM
 Conversão: Normalizar os tipos de dados das múltiplas fontes e para um único
modelo convencionado para a datawarehouse
 Sumarização: Por vezes não é necessário ter os dados com a menor
granularidade , que o sistema operacional nos pode dar, na data warehouse .
Para isso , é preciso fazer agregação dos dados recolhidos na fase de extração.
 Enriquecimento: Colocação de metadados para melhorar o sistema de analise.
 LOAD: Processo de carregamento da informação para o DW
BrianSupra www.briansupra.blogspot.com

2. Modelos para uma DataWarehouse
Modelo em estrela: Existe uma factual que se liga ás varias dimensões através de chaves
estrangeiras.
Modelo Snowflake: Neste modelo as dimensões estam normalizadas até a 3FN. Ou seja, na
tabela das dimensões todos os atributos são atómicos, dependem da chave como um todo.
Mais, os atributos que não fazem parte da chave não tem dependências transitivas - quando
um atributo determina outro que não esta na chave - entre si.
Modelo de Constelação: Existem várias tabelas factuais que se ligam ás suas dimensões, sendo
que algumas dimensões são partilhadas entre as algumas factuais. Para que isto possa ser
possível, as dimensões têm de ser conformes. ( Dimensão conforme é uma dimensão que tem
o mesmo significado , independentemente da tabela factual a que se ligue).
Surrogate keys
As dimensões tem chave primaria única. Para as dimensões deve utilizar-se uma primary key
que não tenha nada a ver com as primary keys das tabelas dos sistemas operacionais que lhe
deram origem. Vejamos o exemplo que mostra a problemática das primary keys das
dimensões. Numa base de dados operacional guarda-se o nome dos clientes. Sendo que cada
cliente tem um ID. Imaginemos que o cliente com ID=3543 deixa de ser cliente e é retirado da
base de dados. Retira-se o registo com ID=3543 da tabela de cliente. Quando um novo cliente
é registado no sistema, o mesmo dá-lhe o ID=3543( que estava vazio). Se o ID for a primary key
da tabela dimensão “cliente” da DW , toda a informação do antigo cliente que saiu da base de
dados fica associada ao novo cliente. Como não queremos que as informações dos clientes (
do antigo e do novo ) se misturem temos de colocar uma Primary Key na dimensão “cliente “
diferente da utilizada na tabela clientes da base de dados operacional. Assim aparecem as
Surrogate Keys . São Chaves primarias nas dimensões da DW com significado apenas para a
DW e com valor independente das primary keys na base de dados operacional.
BrianSupra www.briansupra.blogspot.com

3. Slowly changing dimension
Estas dimensões têm a particularidade do seu conteúdo ir mudando ao longo do tempo de
forma assíncrona. Por exemplo: numa dimensão de nome “Fornecedor” temos todos os
fornecedores de uma determinada empresa. Como devemos proceder se um fornecedor
mudar de morada? Temos 3 modos de actuar:
1. Não registamos a alteração
2. Alteramos o registo do fornecedor em causa, no atributo morada
3. Criamos um novo tuplo com a nova informação do Fornecedor
Numa slowly changing dimension, a opcao 3 é a que uilizada . Assim, na tabela dos
fornecedores existe um ou mais atributos - “versao”,”data_inicio” e “data_fim” que
identificam o tuplo actual. Assim podemos fazer análise do histórico, nunca perdendo
informação.
Data Mart
Uma data Mart é um subconjunto de uma data Warehouse e têm informação apenas acerca
de uma parte do negocio. A DW, no modelo do Kimball(Bottom-up), é uma soma de Data
Marts. Pode-se construir a DW a partir de data marts através da arquitectura BUS. Esta
arquitectura assenta em dimensões conformes que são partilhadas por mais do que uma
tabela factual de diferentes data marts.
OLAP
O OLAP (online analytical process ) é uma forma de explorar a informação que está numa Data
Warehouse. O OLAP pode agregar os dados que estão numa Data Warehouse, aumentando-
lhes a granularidade (roll up). A granularidade mínima que se pode pedir a um sistema de
exploração OLAP é a mínima granularidade que esta na Data Warehouse. No modelo OLAP , a
informação é mantida , conceptualmente, em cubos que guardam as medidas, as medidas são
identificadas por duas ou mais dimensões . Cada dimensão do cubo dá uma perspectiva
diferente das medidas que estão no cubo.
Arquitecturas OLAP
As diferentes variantes do OLAP diferem umas das outras na maneira como fazem o
armazenamento da informação no cubo
ROLAP- Sistema de analise construído em cima de uma base de dados relacional. Para não
denunciar a estrutura da base de dados original, os dados passam da DW para o servidor
ROLAP mas é-lhe acrescentado metadados. Depois os dados são apresentados ao utilizador
soba a forma multidimensional (cubos). O utilizador tem sempre uma visão multidimensional
dos dados. Os cubos são criados dinamicamente á medida que o utilizador vai pedindo
informação. Suporta grande volume de dados.
BrianSupra www.briansupra.blogspot.com

4. MOLAP- O sistema de análise é construído em cima de uma base de dados
multidimensional. Os dados passam da data warehouse para um servidor MOLAP que tem
uma base de dados multidimensional. Na migração dos dados tem se executar processos
específicos de conversão do modelo relacional para o modelo Multidimensional. No servidor
os dados que estam no modelo multidimensional são mostrados sob a forma de cubos ao
utilizador, para que ele efectue as suas pesquisas. Esta arquitectura suporta um volume
moderado de dados.
BrianSupra www.briansupra.blogspot.com