Data Warehousing para Mineração de Dados

1. Data Warehousing para Mineração de Dados Jacques Robin CIn-UFPE

2. Integração de dados: integração de plataformas (1-3) integração de modelos de dados (1-3) integração de esquemas (1) integração de valores(nomes, unidades, etc, 2,3) Transformação de dados: re-modelagem de dados (1) discretização de dados (1-3) normalização de escala e distribuição (1-3) Limpeza de dados (2,3) Seleção de dados seleção de atributos (1-3) amostragem de registros (2,3) Derivação de novos dados: novos atributos (1-3) novas relações (1-3) hierarquias conceituais (1-3) Consolidação de dados construção de novos índices (2-4) materialização de visões (2-4) agregação de valores (2-4) Funcionalidades do data warehouse Etapas: 1. Criação do esquema do data warehouse 2. Carga inicial dos dados 3. Atualização periódica dos dados 4. Processamento de consultas Tarefas:

3. Integração de dados • Objetivo: • fornecer para usuário e software externo interface de consultae manipulação de dados homogêneo • escondendo heterogeneidade subjacente das fontes de dados • Dimensões de heterogeneidade: • Modelo de dados: relacional, O-R, OO, multi-dimensional, semi-estruturado, dedutivo, temporal, ... • Esquema: relações, atributos, chaves, restrições de integridade • Codificação dos valores: unidades, nomes • Linguagem de consulta e manipulação • SGBD • Sistema operacional • Hardware

4. Integrar vários BD OLTP relacionais no data warehouse: integração de plataforma • SGBD diferentes: • Largamente resolvido pela adoção de padrões • linguagem de consulta: SQL-92, SQL-99 • API encapsulando todos os serviços de um SGBD relacional: ODBC, OLE DB • Sistemas operacionais diferentes: • Largamente resolvido • pela escassez de opções: Windows, Unix • pelo fornecimento da parte do vendedores de SGBD de versões para a maioria dos sistemas operacionais • Hardware diferentes: • Largamente abstraído pelo sistema operacional ou SGBD

5. Integrar vários BD OLTP relacionais no data warehouse: integração de esquema • Heterogeneidade semântica: • Homonímia: • relação ou atributo com mesmo nome em 2 bancos • porém com semântica diferente, i.e., associados a conceitos do mundo real diferente na cabeça dos 2 DBAs • ex, atributo tipo em BD1 pode ser marcaem BD2 e modeloem BD3 • Polisemia: • relação ou atributo com mesma semântica • porém com nomes diferente em cada esquema • se não identificado pode gerar redundância e inconsistência • Redundância: • tabela ou atributo de BD1 pode ser derivada a partir das tabelas ou atributo de BD2, via visões ou agregações

6. Integrar vários BD OLTP relacionais no data warehouse: integração de esquema • Heterogeneidade esquemática: • mesmos conceitos modelados como atributos em BD1e como valores em BD2 • Heterogeneidade estrutural: • Relações e atributos com mesma semântica • porém estruturados diferentemente • ex, repartição diferente dos atributos entre as relações

7. Integrar vários BD OLTP relacionais no data warehouse: integração de esquema • Restrições de integridades: • tipos diferentes para mesmo atributo • ex, tipo do atributo mês: • tipo pré-definido mês, string, inteiro, {“Janeiro”, ..., “Dezembro”}, {“Jan”, ..., “Dez”}, {“January”, ..., “December”}, {1, .., 12}, {01, ... , 12} • valores autorizadas diferentes para mesmo atributo • relevância de um atributo em função do valor de um outro codificado em BD1 e não em BD2 • ex,numero de parto quando sexo = masculino

8. Integrar vários BD OLTP relacionais no data warehouse: integração de valores • Atributos categóricos: • conflitos de nomes • ex, “Internacional Business Machine” x “IBM” x “I.B.M.” • Atributos numéricos: • unidades implíticas • ex, 35o Celsius? Farenheit? Kelvin?

9. Integrar vários BD OLTP relacionais no data warehouse: técnicas • GUI integrado para: • edição de esquemas • visualização e busca de dados • cálculo de estatísticas sobre dados • acesso a recursos lingüísticos de grande porte • dicionário de siglas, abreviações, nome próprios, sinônimos • wordnets, terminologias especializadas • acesso a ontologias gerais e especializadas • Meta-dados: • já existentes nas fonte • ou então criadas para a integração • Mineração de dados: • análise de correlação • indução de esquema com programação em lógica indutiva

10. Integrar BD O-R e OO no data warehouse: integração de modelos de dados • Modelos O-R e OO são semanticamente mais ricos do que o modelo relacional • Modelo integrado O-R ou OO: • Como construir hierarquias conceituais para conversão E-R  O-R ou OO ? • Como gerar oids ? • Como gerar ligações entre oids a partir de chaves entre tabelas ? • Modelo integrado E-R: • Como achatar hierarquias conceituais para conversão O-R ou OO  E-R ? • Como gerar chaves entre tabelas a partir de oids entre objetos ? • Porque perder informação ?

11. Divergência de modelo: relacional x O-R/OO

12. Integrar flat files no data warehouse: integração de modelos de dados • Sistemas de arquivos não fornece serviços de BD: • linguagem de consulta declarativa (sério para DW) • acesso otimizado a memória segundaria (inconveniente para DW) • transações (irrelevante para DW) • Abordagens: • criar um esquema de BD a partir dos atributos do flat e povoar BD com os dados do flat • manter gerenciamento dos dados no arquivo chato via re-implementação ad-hoc da alguns dos serviços de BD • ambos requer desenvolvimento de um parser do flat

13. Integrar flat files no data warehouse: integração de modelos de dados • Modelo flat semanticamente mais pobre do que o modelo relacional • representa única entidade em um formato desnormalizado • precisa quebrar tabela única em várias? como? • não representa restrições de integridade • como gerá-las automaticamente? • como garantir seu respeito no sistema de arquivso sub-jacente?

14. Integrar BD semi-estruturado no data warehouse: integração de modelos de dados • Modelo semi-estruturado x modelo relacional • tipágem fraco no lugar de forte • esquema pulverizado dentro dos dados (dados auto-descritivas) • atributos compartilhados no lugar de chaves • Modelo integrado semi-estruturado: • como pulverizar esquema sem perder informação ? • como representar tipágem forte e restrições de integridade ? • Modelo integrado relacional: • como construir esquema unificado, externo aos dados a partir dos esquema pulverizado, embutido nos dados ? • como criar tipagem forte a partir de tipagem fraco ? • como criar atributos compartilhados a partir de chaves ?

15. Divergência de modelo: relacional x semi-estruturado {livro: &l1{isbn string: ”1-556860”, título string: “Data Mining: Concept and Techniques”, autor {string: “J. Han”, string: “M. Kamber”} ano integer: 2001}, livro: &l2{isbn integer: 1988360, título string: “Benchmark Handbook for Databases”, editor string: “Jim Gray”}}

16. Arquiteturas de data warehouse

17. Metodologias de desenvolvimento de data warehouse

18. Projeto lógico de data warehouse: especificação do esquema analítico • Selecionar as tabelas operacionais relevantes das fontes subjacentes para o modelo analítico • Selecionar os atributos relevantes dessas tabelas • Possivelmente definir atributos e relações (tabelas) derivados de granularidade suficiente para descoberta de insights por OLAP ou mineração • Escolher um modelo de dados analítico • estrala, floco de neve, constelação • Particionar os atributos relevantes e derivados em: • atributos da(s) tabela(s) de fatos do modelo analítico • atributos das tabelas de dimensões do modelo analítico • atributos não dimensionais (i.e., ao longo dos quais não há agregação) • chaves ligando as tabelas • Definir as funções de agregação para cada par (medida,dimensão) • Definir as hierarquias conceituais de cada dimensão

19. Projeto lógico de data warehouse: exemplo

20. ROLAP: Armazena dados em tabelas relacionais Lento porém versátil Acesso a células de cuboid envolve muitas junções, varrimento MOLAP: Armazena dados em arrays de dimensões N Sem acesso a granularidade mínima (i.e., única transações) Acesso a células de cuboid direto (complexidade constante?) HOLAP (OLAP Híbrido): Duplica dados Tabelas para dados atômicos Arrays para agregados Flexível e rápido de execução Custoso em memória e desenvolvimento Questões: até que nível de granularidade duplicar dados no array ? que agregados calcular com antecedência ? Projeto físico de data warehouse:tabelas x arrays

21. Projeto físico de data warehouse:índicesbitmap para OLAP • Adequado para atributos com poucas valores possíveis • Conciso: 1 bit para cada valor • Rápido: comparação, junção e agregação por aritmética binária • Para atributos com muitos valores: • compressão no pré-processamento permite usar índices bitmap

22. Projeto físico de data warehouse:índices de junção para OLAP • Permite acesso direto ao valor de uma medida a partir de coordenadas multi-dimensionais • “Simula” array multi-dimensional com tabelas • Economize custosos varrimentos e junções

23. Projeto físico de data warehouse:criação de índices para mineração de dados • índices invertidos: • armazenar juntas na memória colunas no lugar de linhas • a,d,g,b,e,h,c,f,i no lugar de a,b,c,d,e,f,g • junto com índices bitmap chega a acelerar 100 vezes • índices aleatórios (random) • coluna suplementar na criação/atualização do warehouse • permite rápida extração de amostras aleatória durante processamento • striding index • para extraír amostras representativa da distribuição de valores no banco

24. Projeto físico de data warehouse:visões virtuais x materializadas • Materializar: • junções freqüentes em tabelas redundantes • agregações em tabelas redundantes • i.e., desnormalizar • Problema: • compromisso tempo x espaço • definir quais junções e agregações materializar

25. Projeto físico de data warehouse:armazenamento de valores agregados

26. Carga inicial e atualização periódicade dados: problemática e abordagens • Como não atrapalhar o rendimento das fontes OLTP? • Continuamente mantém no background uma cópia histórica de curto prazo • Essa cópia é usada para a carga e a atualização • Atualização incremental ? • Manutenção da consistência e validade dos dados derivados: • atributos derivados • relações derivadas (visões materializadas) • agregações derivadas

27. Processamento eficiente de consultas OLAP: problemática e abordagens • Tradução ingênua das consultas OLAP em SQL ineficiente • Ordem das junções • em último junção com tabela de fato • já ela ocupa a maioria esmagadora do espaço no banco • junções de N tabelas simultaneamente como operação sub-jacente (no lugar do que aninhamento de junções binárias) • Ordem de cálculo dos sub-cuboids no reticulado de cuboids

28. Reticulado de Cuboides

29. Máquinade Execução Programa de interface Programa de interface Programa de interface Programa de interface Internet Arquivos Estruturados BD Relacional BD orientado a objetos Interfaces em formulários Sistema de Informação Federados (SIF)

30. Interface com o Usuário Respostas Consulta Visões do mundo Raciocínio relevante Descrições das fontes: - conteúdo - capacidades Gerador de Planos Planejamento lógico Planejam. de execução Plano de execução Máquina de execução select, project, join, ... Sistema de Informação Federados (SIF)

31. cliente cliente cliente resposta consulta warehouse dados atualização dados servidor dados servidor dados servidor dados Sistema de Informação Federado (SIF) com arquitetura data warehouse

32. cliente cliente cliente resposta consulta mediador consulta resposta servidor dados servidor dados servidor dados Sistema de Informação Federado (SIF) com arquitetura de mediadores

33. Esquema Global SI Federado: arquitetura fortamente acouplada Esquema Externo 1 Esquema Externo 2 Esquema Externo n … Esquema Exportado 1 Esquema Exportado 2 Esquema Exportado n … Esquema Componente 1 Esquema Componente n … Esquema Local 1 Esquema Local n … DBS Componente 1 DBS Componente n …

34. Consultas através de mediadores: 1.As consultas são submetidas ao sistema, via mediador, e este as transforma em subconsultas a serem enviadas às bases de dados. 2. As subconsultas geradas pelo mediador devem ser traduzidas para linguagens de consultas de cada SGBD componente. 3. Os resultados das consultas são traduzidos e a resposta é devolvida ao usuário SI Federado: arquitetura fracamente acouplada Mediador 1 Mediador 2 Tradutor 1 Tradutor 2 Tradutor 3 BD1 BD2 BD3

35. Tipologia dos meta-dados do data warehouse

36. Dimensões descritivas dos data warehouses

37. BD federados: definição e aplicações

38. BD federados: abordagens

39. Data warehouse x BD federado:problemática comum

40. Data warehouse x BD federado:diferenças chaves

41. BD temporais: definição e aplicações

42. BD temporais: abordagens

43. BD temporais: exemplo

44. Data warehouse x BD temporal: problemática comum

45. Data warehouse x BD temporal: diferenças chaves