Helton Santa Cruz

1. Ferramentas CASE de Projeto de BD Multidimensional Helton Santa Cruz

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

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. Dimensional Fact Model • 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

14. Dimensional Fact Model

15. 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

16. DFM - Additive • Atributos são additives ao longo de todas as dimensões por default • Semi- additive e non-additive são representados explicitamente

17. 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

18. 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

19. DFM - Sobrepondo esquemas de fatos compatíveis

20. 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

21. 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"

22. 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

23. 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: • Construir a árvore de atributos • Prunning e grafting a árvore de atributos • Definir dimensões • Definir atributos de fatos • Definir hierarquias

24. DFM - De esquemas E/R para esquemas de fatos

25. 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

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. “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

30. “Prunning” e “grafting” a árvore de atributo

31. 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

32. 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

33. 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 dimensão

34. Esquema de fato final

35. 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

36. 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.

37. 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)

38. 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

39. 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

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