Desenho Lógico de DW. SAD Tagus 2004/05 H. Galhardas A Business Analysis Framework Quatro perspectivas no desenho de um DW: Quatro perspectivas no desenho.

Apresentação em tema: "Desenho Lógico de DW. SAD Tagus 2004/05 H. Galhardas A Business Analysis Framework Quatro perspectivas no desenho de um DW: Quatro perspectivas no desenho."— Transcrição da apresentação:

1 Desenho Lógico de DW

2 SAD Tagus 2004/05 H. Galhardas A Business Analysis Framework Quatro perspectivas no desenho de um DW: Quatro perspectivas no desenho de um DW: Top-down: permite a selecção da informação relevante necessária para armazenar no DW Fontes de dados: expõe a informação que foi capturada, armazenada e gerida pelos sistemas operacionais Data warehouse: consiste nas tabelas de factos e dimensões e representa informação armazenada no DW Interrogações do negócio: acesso aos dados do DW do ponto de vista do utilizador final

3 SAD Tagus 2004/05 H. Galhardas Processo de desenho do DW Bottom-up: Bottom-up: Começa c/ experiências e protótipos (rápida) Deriva o esquema do DW a partir dos esquemas das fontes de dados Permite avançar a baixo custo e avaliar os benefícios, mas é mais difícil de crescer Top-down: Top-down: Começa com desenho e planeamento completo e maduro Primeiro, chega ao esquema conceptual do DW e depois converte o esquema das fontes de dados no esquema global Robusto mas lento e caro Combinação de ambas Combinação de ambas

4 SAD Tagus 2004/05 H. Galhardas Processo de desenho do DW (ESW) Cascata (Waterfall): análise estruturada e sistemática em cada passo antes de prosseguir para o próximo Espiral (Spiral): geração rápida e de sistemas funcionais cada vez mais ricos, em curtos intevalos de tempo,

5 SAD Tagus 2004/05 H. Galhardas Inconvenientes do modelo em cascata para DW Elevados prazos de implementação porque exige conhecimento prévio da generalidade dos requisitos Elevados prazos de implementação porque exige conhecimento prévio da generalidade dos requisitos Não é flexível para ambientes de elevada incerteza de desenho Não é flexível para ambientes de elevada incerteza de desenho Não garante o envolvimento contínuo dos utilizadores no processo de desenvolvimento Não garante o envolvimento contínuo dos utilizadores no processo de desenvolvimento Não se apercebe da total complexidade dos problemas de carregamento de dados Não se apercebe da total complexidade dos problemas de carregamento de dados

6 SAD Tagus 2004/05 H. Galhardas Três modelos de DW Enterprise warehouse Colleciona toda a informação sobre os processos de negócio de toda a organização Data Mart Subcjto dos dados da organização que são interessantes para um grupo específico de utilizadores (ex: marketing) Independentes vs. dependentes (directly from warehouse) Virtual warehouse Cjto de vistas sobre as fontes de dados operacionais Só algumas vistas sumarizadas são materializadas

7 SAD Tagus 2004/05 H. Galhardas Desenvolvimento incremental de um DW Define a high-level corporate data model Data Mart Distributed Data Marts Multi-Tier Data Warehouse Enterprise Data Warehouse Model refinement

8 SAD Tagus 2004/05 H. Galhardas Business Dimensional Lifecycle

9 SAD Tagus 2004/05 H. Galhardas DW Bus Architecture Matrix Ferramenta de planeamento top-down para desenho do DW Ferramenta de planeamento top-down para desenho do DW Obriga a nomear todos os data marts (ou processos de negócio) possíveis e nomear todas as dimensões envolvidas nesses data marts Obriga a nomear todos os data marts (ou processos de negócio) possíveis e nomear todas as dimensões envolvidas nesses data marts Depois, podemos passar ao desenho das tabelas de factos individuais envolvidas em cada data mart. Depois, podemos passar ao desenho das tabelas de factos individuais envolvidas em cada data mart.

10 SAD Tagus 2004/05 H. Galhardas Estrutura da Matriz Linhas: data marts Colunas: dimensões Intersecções: onde uma dimensão existe para um data mart Uma linha indica o nº de dimensões para um dado data mart Uma coluna com muitas intersecções indica que é importante e deve ser conforme

11 SAD Tagus 2004/05 H. Galhardas Extended 4-step design methodology (Kimball) Processo de desenho de DW típico: Processo de desenho de DW típico: 1. Escolher o processo de negócio a modelizar (ex: encomendas, recebimentos, etc) 2. Escolher o grão (nível de dados atómico) do processo de negócio 3. Identificar e tornar conformes as dimensões que se aplicam a cada registo da tabela de factos 4. Escolher os factos que vão popular cada registo da tabela de factos

12 SAD Tagus 2004/05 H. Galhardas Extended 4-step design method (Kimball) (cont.) 5. Armazenar medidas pré-calculadas na tabela de factos 6. Enriquecer as tabelas de dimensões 7. Escolher o período de duração do DW 8. Monitorizar as slowly changing dimensions 9. Decidir prioridades de interrogação e modos de interrogação

13 SAD Tagus 2004/05 H. Galhardas 1. Escolher o processo usually occur in line item-oriented Degenerate dimension: usually occur in line item-oriented fact table designs

14 SAD Tagus 2004/05 H. Galhardas 2. Escolher o grão O grão é a linha em cada recibo do cliente

15 SAD Tagus 2004/05 H. Galhardas 3. Identificar e tornar conformes as dimensões

16 SAD Tagus 2004/05 H. Galhardas Dimensões conformes As dimensões são os pontos de entrada num data mart. Determinam: As dimensões são os pontos de entrada num data mart. Determinam: Os critérios de navegação Os cabeçalhos dos relatórios Vocabulário da organização para os utilizadores Dimensões conformes: significam a mesma coisa e guardam a mesma informação independentemente da tabela de factos a que estão ligadas. Dimensões conformes: significam a mesma coisa e guardam a mesma informação independentemente da tabela de factos a que estão ligadas.

17 SAD Tagus 2004/05 H. Galhardas 4. Escolher os factos O grão da tabela de factos determina que factos usar num data mart O grão da tabela de factos determina que factos usar num data mart Todos os factos têm que ser especificados ao mesmo nível determinado pelo grão Todos os factos têm que ser especificados ao mesmo nível determinado pelo grão Os factos devem ser o mais aditivos possíveis Os factos devem ser o mais aditivos possíveis Podem ser adicionados factos suplementares desde que sejam consistentes com o grão. Podem ser adicionados factos suplementares desde que sejam consistentes com o grão.

18 SAD Tagus 2004/05 H. Galhardas Bad vs good fact table

19 SAD Tagus 2004/05 H. Galhardas Categorização dos factos ou medidas Aditiva: podem ser somadas através de todas as dimensões; são medidas de actividade Aditiva: podem ser somadas através de todas as dimensões; são medidas de actividade E.g.: unidades_vendidas, dolares_vendidos Semi-aditiva: só podem somadas ao longo de algumas dimensões; são fotografias no tempo Semi-aditiva: só podem somadas ao longo de algumas dimensões; são fotografias no tempo E.g.: saldo_conta, quantidade de um inventário não podem ser somadas ao longo do tempo Não aditiva: não podem ser somadas de todo Não aditiva: não podem ser somadas de todo E.g.: temperatura, taxas de juro

20 SAD Tagus 2004/05 H. Galhardas F : A x B  C é aditiva sobre A sse: F : A x B  C é aditiva sobre A sse: F (a 1 + a 2, b) = F (a 1, b)  F (a 2, b) F é aditiva se é aditiva sobre todos os seus argumentos Exemplo : conta(contaID, clienteID, data, saldo) saldo : contaID x clienteID x data  saldo saldo (x, y, [t 0, t 2 ]) = saldo (x, y, [t 0, t 1 ])  saldo (x, y, [t 1, t 2 ]) saldo (x 1  x 2, y, t ) = saldo (x 1, y, t)  saldo (x 2, y, t 2 ) Medidas aditivas ? ?

21 SAD Tagus 2004/05 H. Galhardas Factless facts (1) Facts that do not go into a “normal” fact table since they do not measure anything Facts that do not go into a “normal” fact table since they do not measure anything Describe events and coverage Describe events and coverage Ex: Ex: Student traking system that detects each student attendance at a college Fact table: Student Attendance with attribute attendance (0/1) Dimensions: Time, Course, Student, Teacher

22 SAD Tagus 2004/05 H. Galhardas Factless facts (2) Ex: Ex: Sales Promotion fact table that records the sales of products in stores on particular days under each promotion condition Fact table: Promotion Coverage Dimensions: Time, Store, Product, Promotion

23 SAD Tagus 2004/05 H. Galhardas 5. Storing precalculations (derived facts) in the fact table Derived data : computed from facts applying a function Some derived data are required to be explicitly stored Some derived data are required to be explicitly stored Aggregate data: usually modeled in specific fact tables. Advantage: speed up OLAP queries Inconvenient: slows down DW refreshment and increases DW size

24 SAD Tagus 2004/05 H. Galhardas Fact table with derived data

25 SAD Tagus 2004/05 H. Galhardas Fact table with aggregate data Customer Summary Cust_id Total Sales Highest Sales Value Average Sales Store Table Store_id District_id Customer Table Cust_id Cust_name Time Table Week_id Period_id Year_id Product Table Product_id Product_desc Sales Fact Table Unit Sell Price Dollar Sales Unit Sales Dollar Cost Summary for Product, Store, and Time for all Customers

26 SAD Tagus 2004/05 H. Galhardas 6. Enrich the dimension tables Return to the dimension tables and exhaustively add text-like descriptors Return to the dimension tables and exhaustively add text-like descriptors No abbreviations should be used No abbreviations should be used Important dimensions typically should have 50 text-like attributes Important dimensions typically should have 50 text-like attributes

27 SAD Tagus 2004/05 H. Galhardas 7. Choosing the duration of the DW Measures how far back in time the fact table goes Measures how far back in time the fact table goes Very long fact table durations pose two kinds of problems: Very long fact table durations pose two kinds of problems: Difficult to get and interpret source old data (old files, old tapes) Old versions of important dimensions must be used instead of current ones

28 SAD Tagus 2004/05 H. Galhardas 8. Tracking slowly changing dimensions The operational data source that feeds dimensions changes: keys are kept but descriptive attributes change The operational data source that feeds dimensions changes: keys are kept but descriptive attributes change Three types of solutions: Three types of solutions: 1. Overwrite the dimension record with new values 2. Create a new additional dimension record using a new value of the surrogate key 3. Create an “old” field in the dimension record to store previous attribute value

29 SAD Tagus 2004/05 H. Galhardas 9. Deciding query priorities and query modes Physical design issues: Physical design issues: Physical sort order of the fact table Pre-stored aggregations Indexing...

30 SAD Tagus 2004/05 H. Galhardas Bibliografia (Livro) Data Mining: Concepts and Techniques, J. Han & M. Kamber, Morgan Kaufmann, 2001 (parte da Secção 2.3) (Livro) Data Mining: Concepts and Techniques, J. Han & M. Kamber, Morgan Kaufmann, 2001 (parte da Secção 2.3) (Livro) The Data Warehouse Lifecycle Toolkit, R. Kimball, Wiley 1998 (Cap. 5, 6 e 7) (Livro) The Data Warehouse Lifecycle Toolkit, R. Kimball, Wiley 1998 (Cap. 5, 6 e 7) (Artigo) Letting the Users Sleep Part 1 and 2, R. Kimball, DBMS – Dec. 1996 and Jan. 1997, http://www.dbmsmag.com/9612d05.html (Artigo) Letting the Users Sleep Part 1 and 2, R. Kimball, DBMS – Dec. 1996 and Jan. 1997, http://www.dbmsmag.com/9612d05.html http://www.dbmsmag.com/9612d05.html http://www.dbmsmag.com/9701d05.html