Desenho Lógico de DW
A Business Analysis
Framework

Quatro perspectivas no desenho de um DW:

Top-down: permite a selecção da informação relevante
necessária para armazenar no DW

Fontes de dados: expõe a informação que foi capturada,
armazenada e gerida pelos sistemas operacionais

Data warehouse: consiste nas tabelas de factos e
dimensões e representa informação armazenada no DW

Interrogações do negócio: acesso aos dados do DW do
ponto de vista do utilizador final
SAD Tagus 2004/05
H. Galhardas
Processo de desenho
do DW

Bottom-up:




Top-down:




Começa c/ experiências e protótipos (rápida)
Deriva o esquema do DW a partir dos esquemas das fontes
de dados
Permite avançar a baixo custo e avaliar os benefícios, mas
é mais difícil de crescer
Começa com desenho e planeamento completo e maduro
Primeiro, chega ao esquema conceptual do DW e depois
converte o esquema das fontes de dados no esquema
global
Robusto mas lento e caro
Combinação
de ambas H. Galhardas
SAD Tagus 2004/05
Processo de desenho do DW
(ESW)
Cascata (Waterfall): análise estruturada e
sistemática em cada passo antes de
prosseguir para o próximo
Espiral (Spiral): geração rápida e de
sistemas funcionais cada vez mais ricos,
em curtos intevalos de tempo,
SAD Tagus 2004/05
H. Galhardas
Inconvenientes do modelo
em cascata para DW




Elevados prazos de implementação porque
exige conhecimento prévio da generalidade dos
requisitos
Não é flexível para ambientes de elevada
incerteza de desenho
Não garante o envolvimento contínuo dos
utilizadores no processo de desenvolvimento
Não se apercebe da total complexidade dos
problemas de carregamento de dados
SAD Tagus 2004/05
H. Galhardas
Três modelos de DW
Enterprise warehouse

Colleciona toda a informação sobre os processos de
negócio de toda a organização
Data Mart


Subcjto dos dados da organização que são
interessantes para um grupo específico de utilizadores
(ex: marketing)
Independentes vs. dependentes (directly from
warehouse)
Virtual warehouse
Cjto de vistas sobre as fontes de dados operacionais
 Só
algumas vistas sumarizadas
são materializadas
H. Galhardas
SAD Tagus
2004/05

Desenvolvimento incremental de
um DW
Multi-Tier Data
Warehouse
Distributed
Data Marts
Data
Mart
Enterprise
Data
Warehouse
Data
Mart
Model refinement
Model refinement
Define a high-level corporate data model
SAD Tagus 2004/05
H. Galhardas
Business Dimensional
Lifecycle
SAD Tagus 2004/05
H. Galhardas
DW Bus Architecture Matrix



Ferramenta de planeamento top-down
para desenho do DW
Obriga a nomear todos os data marts (ou
processos de negócio) possíveis e
nomear todas as dimensões envolvidas
nesses data marts
Depois, podemos passar ao desenho das
tabelas de factos individuais envolvidas
em cada data mart.
SAD Tagus 2004/05
H. Galhardas
Estrutura da Matriz
Linhas: data marts
Colunas: dimensões
Intersecções: onde uma dimensão existe
para um data mart
Uma linha indica o nº de dimensões para
um dado data mart
Uma coluna com muitas intersecções indica
que é importante e deve ser conforme
SAD Tagus 2004/05
H. Galhardas
Extended 4-step design
methodology (Kimball)

Processo de desenho de DW típico:
1.
2.
3.
4.
Escolher o processo de negócio a modelizar
(ex: encomendas, recebimentos, etc)
Escolher o grão (nível de dados atómico) do
processo de negócio
Identificar e tornar conformes as dimensões
que se aplicam a cada registo da tabela de
factos
Escolher os factos que vão popular cada
registo da tabela de factos
SAD Tagus 2004/05
H. Galhardas
Extended 4-step design
method (Kimball) (cont.)
5.
6.
7.
8.
9.
Armazenar medidas pré-calculadas na
tabela de factos
Enriquecer as tabelas de dimensões
Escolher o período de duração do DW
Monitorizar as slowly changing dimensions
Decidir prioridades de interrogação e modos
de interrogação
SAD Tagus 2004/05
H. Galhardas
1. Escolher o processo
Degenerate dimension: usually occur in line item-oriented
fact table designs
SAD Tagus 2004/05
H. Galhardas
2. Escolher o grão
O grão é a linha em cada recibo do cliente
SAD Tagus 2004/05
H. Galhardas
3. Identificar e tornar
conformes as dimensões
SAD Tagus 2004/05
H. Galhardas
Dimensões conformes

As dimensões são os pontos de entrada num
data mart. Determinam:




Os critérios de navegação
Os cabeçalhos dos relatórios
Vocabulário da organização para os utilizadores
Dimensões conformes: significam a mesma
coisa e guardam a mesma informação
independentemente da tabela de factos a que
estão ligadas.
SAD Tagus 2004/05
H. Galhardas
4. Escolher os factos




O grão da tabela de factos determina que
factos usar num data mart
Todos os factos têm que ser especificados ao
mesmo nível determinado pelo grão
Os factos devem ser o mais aditivos possíveis
Podem ser adicionados factos suplementares
desde que sejam consistentes com o grão.
SAD Tagus 2004/05
H. Galhardas
Bad vs good fact table
SAD Tagus 2004/05
H. Galhardas
Categorização dos factos ou
medidas

Aditiva: podem ser somadas através de todas as
dimensões; são medidas de actividade


Semi-aditiva: só podem somadas ao longo de
algumas dimensões; são fotografias no tempo


E.g.: unidades_vendidas, dolares_vendidos
E.g.: saldo_conta, quantidade de um inventário não
podem ser somadas ao longo do tempo
Não aditiva: não podem ser somadas de todo

E.g.: temperatura, taxas de juro
SAD Tagus 2004/05
H. Galhardas
Medidas aditivas

F : A x B  C é aditiva sobre A sse:


F (a1 + a2, b) = F (a1, b) + F (a2, b)
F é aditiva se é aditiva sobre todos os seus
argumentos
Exemplo : conta(contaID, clienteID, data, saldo)
saldo : contaID x clienteID x data  saldo
?
saldo (x, y, [t0 , t2 ]) = saldo (x, y, [t0 , t1]) + saldo (x, y, [t1 ,
t2])
?
saldo (x1  x2, y, t ) = saldo (x1, y, t) saldo (x2, y, t2)
SAD Tagus 2004/05
H. Galhardas
Factless facts (1)



Facts that do not go into a “normal” fact
table since they do not measure anything
Describe events and coverage
Ex:
Student traking system that detects each
student attendance at a college
Fact table: Student Attendance with attribute
attendance (0/1)
Dimensions: Time, Course, Student, Teacher
SAD Tagus 2004/05
H. Galhardas
Factless facts (2)

Ex:
Sales Promotion fact table that records the
sales of products in stores on particular days
under each promotion condition
Fact table: Promotion Coverage
Dimensions: Time, Store, Product, Promotion
SAD Tagus 2004/05
H. Galhardas
5. Storing precalculations
(derived facts) in the fact
table
Derived data : computed from facts applying a
function
 Some derived data are required to be
explicitly stored
Aggregate data: usually modeled in specific
fact tables.
Advantage: speed up OLAP queries
Inconvenient: slows down DW refreshment and
increases DW size
SAD Tagus 2004/05
H. Galhardas
Fact table with derived data
SAD Tagus 2004/05
H. Galhardas
Fact table with aggregate
data
Customer Table
Cust_id
Cust_name
Store Table
Store_id
District_id
Sales Fact Table
Unit Sell Price
Dollar Sales
Unit Sales
Dollar Cost
Time Table
Week_id
Period_id
Year_id
SAD Tagus 2004/05
Product Table
Product_id
Product_desc
H. Galhardas
Summary for Product,
Store, and Time for all
Customers
Customer Summary
Cust_id
Total Sales
Highest Sales Value
Average Sales
6. Enrich the dimension
tables



Return to the dimension tables and
exhaustively add text-like descriptors
No abbreviations should be used
Important dimensions typically should
have 50 text-like attributes
SAD Tagus 2004/05
H. Galhardas
7. Choosing the duration of
the DW


Measures how far back in time the fact
table goes
Very long fact table durations pose two
kinds of problems:
Difficult to get and interpret source old data
(old files, old tapes)
 Old versions of important dimensions must be
used instead of current ones

SAD Tagus 2004/05
H. Galhardas
8. Tracking slowly changing
dimensions


The operational data source that feeds
dimensions changes: keys are kept but
descriptive attributes change
Three types of solutions:
1.
2.
3.
Overwrite the dimension record with new
values
Create a new additional dimension record
using a new value of the surrogate key
Create an “old” field in the dimension record
to store previous attribute value
SAD Tagus 2004/05
H. Galhardas
9. Deciding query priorities
and query modes

Physical design issues:
Physical sort order of the fact table
 Pre-stored aggregations
 Indexing
 ...

SAD Tagus 2004/05
H. Galhardas
Bibliografia



(Livro) Data Mining: Concepts and Techniques, J.
Han & M. Kamber, Morgan Kaufmann, 2001 (parte
da Secção 2.3)
(Livro) The Data Warehouse Lifecycle Toolkit, R.
Kimball, Wiley 1998 (Cap. 5, 6 e 7)
(Artigo) Letting the Users Sleep Part 1 and 2, R.
Kimball, DBMS – Dec. 1996 and Jan. 1997,
http://www.dbmsmag.com/9612d05.html
http://www.dbmsmag.com/9701d05.html
SAD Tagus 2004/05
H. Galhardas