O documento discute as funcionalidades de um data warehouse, incluindo integração, transformação e limpeza de dados de diferentes fontes, seleção de atributos e registros relevantes, e derivação de novos dados. As principais etapas de um projeto de data warehouse são apresentadas como a criação do esquema, carga inicial dos dados e atualizações periódicas.
2. Funcionalidades do data warehouse
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)
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 consulta
e 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 marca em BD2 e modelo em 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 BD1
e como valores em BD2
Professor Inteligência
Artificial
Mineração
de Dados
Banco de
Dados
Carol no no yes
Geber yes no no
Jacques yes yes no
Prof Curso
acs BD
glr IA
jr IA
jr Mineração de Dados
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
ISBN Título Autor Editor Ano
inteiro string string string year
1-556860 Data Mining: Concepts and Techniques J. Han NULL 2001
1-556860 Data Mining: Concepts and Techniques M. Kamber NULL 2001
1-988360 Benchmark Handbook for Databases NULL Jim Gray NULL
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. ISBN Título Autor Editor Ano
inteiro string string string year
1-556860 Data Mining: Concepts and Techniques J. Han NULL 2001
1-556860 Data Mining: Concepts and Techniques M. Kamber NULL 2001
1-988360 Benchmark Handbook for Databases NULL Jim Gray NULL
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
Query/report Analysis Data mining
OLAPserver OLAPserver
Top tier:
front-end tools
Middle tier:
OLAPserver
Bottom tier:
data warehouse
server
Data
Output
Extract
Clean
Transform
Load
Refresh
Data warehouse Data martsMonitoring
Metadata repository
Operational databases External sources
Administration
17. Metodologias de desenvolvimento
de data warehouse
Enterprise
data
warehouse
Multi-tier
data
warehouse
Distributed
data marts
Data
mart
Define a high-level corporate data model
Data
mart
Model refinement Model refinement
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
customer
cust_ID
C1
. . .
. . .
name
Smith, Sandy
. . .
. . .
address
5463 E Hastings, Burnaby,
BC V5A 4S9, Canada
. . .
age
21
. . .
. . .
income
$27000
. . .
. . .
credit_info
1
. . .
. . .
. . .
. . .
. . .
. . .
employee
empl_ID
E55
. . .
name
Jones, Jane
. . .
category
home entertainment
. . .
group
manager
. . .
salary
$18,000
. . .
commission
2%
. . .
branch
branch_ID
B1
. . .
name
City Square
. . .
address
369 Cambie St., Vancouver, BC V5L 3A2, Canada
. . .
purchases
trans_ID
T100
. . .
cust_ID
C1
. . .
empl_ID
E55
. . .
date
09/21/98
. . .
time
15:45
. . .
method_paid
Visa
. . .
amount
$1357.00
. . .
items_sold
trans_ID
T100
T100
. . .
item_ID
I3
I8
. . .
qty
1
2
. . .
works_at
empl_ID
E55
. . .
branch_ID
B1
. . .
item
item_ID
13
18
. . .
name
high-res-TV
multidisc-
CDplay
brand
Toshiba
Sanyo
. . .
category
high resolution
multidisc
. . .
type
TV
CD player
. . .
price
$988.00
$369.00
. . .
place_made
Japan
Japan
. . .
supplier
NikoX
MusicFront
. . .
cost
$600.00
$120.00
. . .
time
dimension table
time_key
day
day_of_week
month
quarter
year
sales
fact table
time_key
item_key
branch_key
location_key
dollars_sold
units_sold
item
dimension table
item_key
item_name
brand
type
supplier_key
branch
dimension table
branch_key
branch_name
branch_type
location
dimension table
location_key
street
city_key
supplier
dimension table
supplier_key
supplier_type
city
dimension table
city_key
city
province_or_state
country
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. RID item city
R1
R2
R3
R4
R5
R6
R7
R8
H
C
P
S
H
C
P
S
V
V
V
V
T
T
T
T
RID H C
R1
R2
R3
R4
R5
R6
R7
R8
1
0
0
0
1
0
0
0
0
1
0
0
0
1
0
0
P S
0
0
1
0
0
0
1
0
0
0
0
1
0
0
0
1
RID V T
R1
R2
R3
R4
R5
R6
R7
R8
1
1
1
1
0
0
0
0
0
0
0
0
1
1
1
1
Base table Item bitmap index table City bitmap index table
Note: Hfor Òhome entertainment,Ó C for Òcomputer,Ó Pfor Òphone,Ó Sfor Òsecurity,Ó
V for ÒVancouver,Ó Tfor ÒToronto.Ó
Projeto físico de data warehouse:
índices bitmap 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
Join index table for
location/sales
location sales_key
. . .
Main Street
Main Street
Main Street
. . .
. . .
T57
T238
T884
. . .
Join index table for
item/sales
item sales_key
. . .
Sony-TV
Sony-TV
. . .
. . .
T57
T459
. . .
Join index table linking two dimensions
location/item/sales
itemlocation sales_key
. . .
Main Street
. . .
. . .
Sony-TV
. . .
. . .
T57
. . .
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
a b c
d e f
g h i
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ódica
de 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
supplier
all
time, item, location, supplier
item, locationtime, location
item, suppliertime, supplier
time, location, supplier
item, location,
supplier
location,
supplier
time, item, supplier
time
item location
time, item
time, item, location
0-D (apex) cuboid
1-D cuboids
2-D cuboids
3-D cuboids
4-D (base) cuboid
29. Sistema de Informação Federados (SIF)
Arquivos
Estruturados
Interfaces em
formulários
BD
Relacional
BD orientado
a objetos
Internet
Programa
de interface
Programa
de interface
Programa
de interface
Programa
de interface
Máquina de Execução
30. Visões do mundo
Descrições
das fontes:
- conteúdo
- capacidades
Máquina de execução
select, project, join, ...
Gerador
de
Planos
Interface com o
Usuário
Raciocínio relevante
Planejamento lógico
Planejam. de execução
Plano de execução
Consulta
Respostas
Sistema de Informação Federados (SIF)
31. Sistema de Informação Federado (SIF)
com arquitetura data warehouse
cliente cliente cliente
servidor
dados
servidor
dados
servidor
dados
consulta
resposta
atualização
dados
warehouse
dados
32. Sistema de Informação Federado (SIF)
com arquitetura de mediadores
cliente cliente cliente
servidor
dados
servidor
dados
servidor
dados
consulta
resposta
mediador
consulta
resposta
33. SI Federado: arquitetura
fortamente acouplada
Esquema
Exportado 1
Esquema
Exportado 2
Esquema
Exportado n
Esquema
Componente 1
Esquema
Componente n
Esquema
Global
Esquema
Externo 1
Esquema
Externo 2
Esquema
Externo n
Esquema Local 1 Esquema Local n
DBS Componente 1 DBS Componente n
…
…
…
…
…
34. SI Federado: arquitetura
fracamente acouplada
Mediador 1 Mediador 2
Tradutor 1 Tradutor 2 Tradutor 3
BD1 BD2 BD3
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