Helton Santa Cruz

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 !!!