Ferramentas CASE de
Projeto de BD
Multidimensional
Helton Santa Cruz
1
Sumário
• Motivação
• Ferramentas Case
• Framework
– Fases do projeto de DW
• Análise do sistema de informação
• Especificação de requisitos
• Projeto conceitual
– DFM
• Projeto lógico
• Projeto físico
• Conclusões
• Bibliografia
2
Motivação
• As empresas, investiram muito tempo e recursos
construindo SIs grandes e complexos
• Agora necessita de suporte para obter, de forma
rápida, informação sumarizada que pode ajudar a
gerentes a planejar e tomar decisões importantes
• Sistema de DW habilitam gerentes de empresas a
adquirir e integrar informações de fontes
heterogêneas e consultar muitas base de dados
grandes de forma eficiente
3
Motivação
• Construir sistemas de DW requer projeto e
técnicas de implementação completamente
diferentes daquelas de sistemas de informação
operacionais
• A maioria dos documentos que envolve DW foca
em assuntos específicos como modelos de dados
multidimensional, materialização de visões, e
seleção de índices
4
Motivação
• A maioria dos interesses tem focado nos assuntos
práticos que determinam principalmente
performances de DW
• DW foi inicialmente inventada dentro do mundo
industrial, onde usuários não dão importância a
assuntos conceituais
5
Motivação
• Pouco é informado sobre como realizar o projeto
conceitual a partir dos requisitos do usuário
• Um framework metodológico é um requisito
essencial para garantir o sucesso do projeto
6
Ferramentas Case
• Ferramenta ou conjunto de ferramentas que
automatizam tarefas que compõem o processo de
desenvolvimento de software
• Será mostrado um framework metodológico geral
para projeto de DW
• O projeto conceitual é baseado no Dimensional
Fact Model
7
Fases do projeto de DW
• As fases básicas no projeto de DW são:
–
–
–
–
–
Análise do sistema de informação
Especificação de requisitos
Projeto conceitual
Projeto lógico
Projeto físico
8
Análise do sistema de informação
• A documentação do sistema de informação préexistente
• Requer bases de dados existentes
• Envolve o designer e pessoas que gerenciam os
SIs
• A análise vai requerer a maior parte do tempo
devido a sua complexidade e ao alto volume de
dados que devem ser integrados
9
Especificação dos Requisitos
• Consiste em coletar e filtrar os requisitos dos
usuários
• Envolve o designer e os usuários finais da DW
• Produz na saída as especificações das escolhas de
fatos de interesse e indicações preliminares de
workload
• A escolha de fatos á baseada na documentação
produzida no passo anterior
10
Projeto Conceitual
• O projeto conceitual é um dos assuntos
menos discutidos na literatura que envolve
DW
• Esse modelo conceitual que será
apresentado de um DW consiste de um
conjunto de esquemas de fatos
• Os componentes básicos de esquemas de
fatos são: facts, dimensions e hierarchies
11
Dimensional Fact Model
• A representação da realidade usando DFM é
chamada de esquema dimensional
• O DFM é apontado para:
– Efetivamente suportar projeto conceitual
– Provê um ambiente expressivo onde o usuário possa
intuitivamente formular queries
– Permitir ao designer e aos usuários discutir
construtivamente no sentido de refinar a especificação
de requisitos
– Representar uma plataforma sólida para a fase de
projeto lógico
– Provê uma documentação não ambígua e expressiva a
posterior
12
Dimensional Fact Model
• Consiste de um conjunto de esquemas de fatos
• Um fato expressa um relacionamento many-tomany ao longo de dimensões
• Cada combinação de valores de dimensões define
um fact instance
13
Dimensional Fact Model
14
Dimensional Fact Model
• Um esquema de fatos pode também não ter
atributos de fatos: nesse caso, cada fact instance
registra a ocorrência de um evento
Exemplo: considere um fact ATTENDANCE com
dimensões date,student, course e teacher: um fact
instance representa o fato que, para uma date
dada, um student assiste um course dado por um
teacher
15
DFM - Additive
• Atributos são additives ao longo de todas as
dimensões por default
• Semi- additive e non-additive são representados
explicitamente
16
DFM - Sobrepondo esquemas de
fatos compatíveis
• Diferentes fatos são representado em diferentes
esquemas de fatos
• Parte das queries que o usuário formula sobre a
DW pode requerer atributos de fatos pegos de
esquemas distintos
• Dois esquemas de fatos são ditos compatíveis se
eles compartilham no mínimo um atributo de
dimensão
17
DFM - Sobrepondo esquemas de
fatos compatíveis
• No caso mais simples, em que as dependências do
inter-atributo está em dois esquemas não são
conflitantes:
– o conjunto dos atributos de fatos em H é a união dos
conjuntos em F e G
– as dimensões em H são a interseção daquelas em F e G,
assumindo que a dimensão dada é comum para F e G se
no mínimo um atributo de dimensão é compartilhado
– cada hierarquia em H inclui todos e somente os
atributos de dimensão incluídos nas hierarquias
correspondentes de F e G
18
DFM - Sobrepondo esquemas de
fatos compatíveis
19
DFM - Query Pattern
• Uma query pode ser representada por uma query
pattern
• Consiste num conjunto de marcadores colocados
sobre os atributos de dimensão
• Um ou mais marcadores podem ser colocados
dentro de cada hierarquia
• Uma dimensão podem não conter marcadores,
para indicar que nenhum de seus atributos esta
envolvido na query
• Atributos não dimensionais não precisam ser
mostrados sobre a query pattern
20
DFM - Query Pattern
• A figura abaixo mostra a query pattern
representando a seguinte query: “total quantity sold
and average returns per unit sold for each week and
for each type of product"
21
DFM - De esquemas E/R para
esquemas de fatos
• A maioria dos SIs implementados em
empreendimentos da ultima década são relacionais
• Na maioria dos casos, sua documentação de
análise consiste de esquemas E/R
• Vamos derivar o modelo conceitual de um DW de
esquemas E/R existentes
22
DFM - De esquemas E/R para
esquemas de fatos
•
A metodologia utilizada constrói um
esquema dimensional seguindo os passos:
–
–
1. Definir fatos
2. para cada fato:
a.
b.
c.
d.
e.
Construir a árvore de atributos
Prunning e grafting a árvore de atributos
Definir dimensões
Definir atributos de fatos
Definir hierarquias
23
DFM - De esquemas E/R para
esquemas de fatos
24
Definindo fatos
•
Um fato pode ser representado no esquema E/R
ou por uma entidade F ou por um
relacionamento entre entidades
•
Cada fato identificado no esquema E/R se torna
a raiz de um diferente esquema de fatos
•
Os atributos do relacionamento se tornam
atributos do fato
25
DFM - De esquemas E/R para
esquemas de fatos
26
Construir a árvore de atributos
•Seja F a entidade escolhida para representar um
fato, a árvore de atributos é construída usando o
seguinte algorítmo:
27
Construir a árvore de atributos
28
“Prunning” e “grafting” a árvore
de atributo
•
Nem todos os atributos representados na arvore
de atributo são interessantes para a DW
•
Algumas sub-árvores da árvore são apagadas
–
•
Os atributos apagados não serão incluídos no
esquema de fatos
“Grafting” é utilizado quando o vértice da árvore
expressa uma informação não interessante, seus
descendentes podem ser preservados
29
“Prunning” e “grafting” a árvore
de atributo
30
Definindo dimensões
•
•
•
•
Dimensões determinam como fact instances
podem ser agregados
As dimensões devem ser escolhidas numa árvore
de atributos entre os vértices filhos da raiz
A escolha deles é crucial para o projeto de DW
desde que ele determina a granularidade de fact
instances
No exemplo de Sale, os atributos escolhidos são
product, store e week
31
Definindo atributos de fatos
•
•
Atributos de fatos são ou count do numero de
instances de F ou a
sum/average/maximum/minimum de expressões
envolvendo atributos numéricos da arvore de
atributo
É útil para a fase de projeto lógico construir um
glossário que associa cada atributo de fato a uma
expressão descrevendo como ele pode ser
calculado dos atributos do esquema E/R
32
Definindo Hierarquias
•
•
•
•
Ao longo de cada hierarquia, atributos
podem ser arranjados numa árvore tal que
um relacionamento x-to-one existe entre
cada nodo e seus descendentes
A árvore de atributo mostra a organização
para hierarquias
Ainda é possível “prunnig” e “grafting” a
árvore para eliminar detalhes irrelevantes
Os atributos que deveriam ser usados
somente para propósitos informativos devem
ser identificados como atributos sem
33
dimensão
Esquema de fato final
34
Projeto Lógico
•
•
•
O projeto lógico recebe de entrada um
esquema dimensional, um workload e um
conjunto de informações adicionais
É necessário escolher o objetivo do
modelo lógico, relacional ou
multidimensional
Um esquema dimensional pode ser
mapeado para um modelo relacional
adotando o bem conhecido esquema
estrela
35
Projeto Lógico
•
Uma alternativa divisão-e-conquista deve
ser adotada devido ao grande custo
computacional de uma solução integrada
•
Envolveria técnicas de View
Materialization, Translation into Tables
etc.
36
Projeto Lógico
•
Utilizando o esquema estrela por exemplo,
para o exemplo SALE resultaria nas
seguintes tabelas:
–
–
–
–
FT_SALE(prodKey,dateKey,storeKey,
qtySold,returns)
DT_PROD(prodKey,product,type,size,
category,manufacturer)
DT_DATE(dateKey,week,month)
DT_STORE(storeKey,salesManager,city,
state,address)
37
Projeto Físico
•
•
•
O principal assunto no projeto físico se
preocupa com a seleção ótima de índices
Requer as estruturas de acesso especificas
providas pelo DBMS para serem levadas
em conta
Devido a essa alta complexidade, o
projeto físico deve ser realizado utilizando
algoritmos heurísticos
38
Conclusões
• Um modelo conceitual para o projeto de DW e
uma metodologia semi-automática para derivar ele
de uma documentação E/R descrevendo o SI de
uma empresa
• O DFM é independente do modelo lógico
alvo(multidimensional ou relacional)
• Há necessidade de uma metodologia para os
projetos lógicos e físicos
• Desenvolver a metodologia para o projeto lógico e
físico e implementá-lo numa ferramenta
automatizada
39
Bibliografia
•
M. Golfarelli, D. Maio, and S. Rizzi,
“Conceiptual design of data warehouses from
E/R schemes”, Proc. HICSS-31, VII, Kona,
Hawaii, 1998, pp. 334-343
•
M. Golfarelli, D. Maio, and S. Rizzi,
“Designing the Data Warehouse: Key Steps
and Crucial Issues”, Journal of Computer
Science and Information Management, Vol. 2,
N. 3, 1999
40
Obrigado pela atenção !!!
41