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