helton santa cruz
DESCRIPTION
Ferramentas CASE de Projeto de BD Multidimensional. Helton Santa Cruz. 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. - PowerPoint PPT PresentationTRANSCRIPT
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 atributos
b. Prunning e grafting a árvore de atributos
c. Definir dimensões
d. Definir atributos de fatos
e. 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 !!!