Data WareHOuse

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

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:

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

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

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

 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

 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

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?

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

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 ?

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

Integrar flat files no data warehouse:
 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

Integrar flat files no data warehouse:
 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?

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 ?

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”}}

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

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

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

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

 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

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

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

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

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

armazenamento de valores agregados

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

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

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

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

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)

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

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

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

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

Tipologia dos meta-dados do data warehouse

Dimensões descritivas dos data warehouses

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

Data warehouse x BD federado:
problemática comum

Data warehouse x BD federado:
diferenças chaves

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

Data warehouse x BD temporal:
problemática comum

Data warehouse x BD temporal:
diferenças chaves

Data WareHOuse

Mais conteúdo relacionado

Mais procurados

Semelhante a Data WareHOuse

Data WareHOuse