1
Helton Santa Cruz
Ferramentas CASE de Projeto de BD
Multidimensional
2
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
3
• 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
Motivação
4
• 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
Motivação
5
• 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
Motivação
6
• 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
Motivação
7
• 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
Ferramentas Case
8
• 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
Fases do projeto de DW
9
• 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
Análise do sistema de informação
10
• 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
Especificação dos Requisitos
11
• 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
Projeto Conceitual
12
• 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
Dimensional Fact Model
13
• Consiste de um conjunto de esquemas de fatos• Um fato expressa um relacionamento many-to-
many ao longo de dimensões • Cada combinação de valores de dimensões define
um fact instance
Dimensional Fact Model
14
Dimensional Fact Model
15
• 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
Dimensional Fact Model
16
• Atributos são additives ao longo de todas as dimensões por default
• Semi- additive e non-additive são representados explicitamente
DFM - Additive
17
• 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
DFM - Sobrepondo esquemas de fatos compatíveis
18
• 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
DFM - Sobrepondo esquemas de fatos compatíveis
19
DFM - Sobrepondo esquemas de fatos compatíveis
20
• 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
DFM - Query Pattern
21
• 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"
DFM - Query Pattern
22
• 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
DFM - De esquemas E/R para esquemas de fatos
23
• A metodologia utilizada constrói um esquema dimensional seguindo os passos:
– 1. Definir fatos– 2. para cada fato:
a. Construir a árvore de atributosb. Prunning e grafting a árvore de atributosc. Definir dimensõesd. Definir atributos de fatose. Definir hierarquias
DFM - De esquemas E/R para esquemas de fatos
24
DFM - De esquemas E/R para esquemas de fatos
25
• 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
Definindo fatos
26
DFM - De esquemas E/R para esquemas de fatos
27
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:
28
Construir a árvore de atributos
29
• 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
“Prunning” e “grafting” a árvore de atributo
30
“Prunning” e “grafting” a árvore de atributo
31
• 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
Definindo dimensões
32
• 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
Definindo atributos de fatos
33
• 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 dimensão
Definindo Hierarquias
34
Esquema de fato final
35
• 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
Projeto Lógico
36
• 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.
Projeto Lógico
37
• 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)
Projeto Lógico
38
• 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
Projeto Físico
39
• 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
Conclusões
40
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
41
Obrigado pela atenção !!!