SistemasApoioDecisao BaseadosDataWarehouse PDF

P
R
O
J
E
T
A
N
D
O

S
I
S
T
E
M
A
S

D
E

A
P
O
I
O

D
E
C
I
S
O
B
A
S
E
A
D
O
S

E
M

D
A
T
A

W
A
R
E
H
O
U
S
E
PROJETANDO SISTEMAS
DE APOIO DECISO
BASEADOS EM
DATA WAREHOUSE
Methanias Colao Jnior
M
e
t
h
a
n
i
a
s

C
o
l
a
o

J
n
i
o
r
Fruto da experincia de vrios profissionais especialistas nas reas de Banco de Dados, Business
Intelligence, Marketing, Data Warehouse (DW) e Data Mining, este livro traduz as potencialidades de um DW como
a base para sistemas de suporte deciso. Atravs de uma linguagem simples e com foco em aspectos essen-
ciais, o leitor adquire um conhecimento slido sobre Sistemas de Apoio Deciso (SADs) e passa a conhecer as
caractersticas fundamentais de todas as ferramentas envolvidas neste processo. So abordados conceitos sobre
ferramentas de Business Intelligence tais como as ferramentas OLAP, EIS, ERP, CRM, Database Marketing e Data
Mining.
Alm de preparar conceitualmente o leitor, apresentada uma metodologia de desenvolvimento e documentao
de um projeto de ambiente de suporte deciso. Muitos dos exemplos apresentados no se prendem aos con-
ceitos bsicos, mas agregam conhecimento e criatividade por parte do seu autor e colaboradores, inclusive esten-
dendo a UML para documentao de um DW. H um cuidado especial para no apresentar um Data Warehouse
como a resoluo de todos os problemas, mas sim apresentar solues que podem ser utilizadas por gerentes
de um projeto como este. Gerncia de metadados e projeto fsico de banco de dados tambm so abordados e
todos os captulos do livro so finalizados com um resumo, para fixao e simples reviso do que foi abordado.
O livro beneficia profissionais e estudantes de Informtica em matrias como Banco de Dados e Tpicos Espe-
ciais, e direcionado para estudantes e profissionais de Administrao, Marketing, Publicidade, Contabilidade e
Economia, envolvidos profissionalmente com a rea gerencial ou academicamente com disciplinas como Tecno-
logia da Informao, Sistemas de Informao, Contabilidade Gerencial, CRM, entre outras.
Os profissionais de Marketing tambm podero encontrar neste livro a base para a implantao de aplicaes de
Database Marketing.
Methanias Colao Jnior M.Sc. em Informtica pela Universidade Federal de Campina Grande (UFCG) na
rea de Sistemas de Informao e Banco de Dados. Especialista em Cincia da Computao e Tecnologia da
Informao, membro da equipe de Sistemas de Apoio Deciso do Banco do Estado de Sergipe e professor da
Universidade Tiradentes e da Faculdade Sergipana (UNIP). Atua como consultor de empresas na rea de DW,
prestando servios Secretaria Municipal de Finanas de Aracaju, Secretaria de Estado da Fazenda de Sergipe e
Companhia Alagoana de Refrigerantes (Coca-Cola/SE). Ministra treinamentos e presta consultoria em Engenharia
de Software, Banco de Dados, Oracle e ferramentas de BI.
Andr Vincius Nascimento graduado em Cincia da Computao pela Univer-
sidade Federal de Sergipe e M.Sc. em Informtica pela UFCG na rea de Sistemas de
Informao e Banco de Dados. membro da equipe de Sistemas de Apoio Deciso
do Banco do Estado de Sergipe e professor da Universidade Federal de Sergipe, alm
de ministrar aulas em curso de ps-graduao em Administrao de Banco de Dados.
Maria de Ftima Almeida graduada em Cincia da Computao pela Universi-
dade Federal de Sergipe e M.Sc. em Informtica pela UFCG na rea de Sistemas de
Informao e Banco de Dados. Membro da equipe de Sistemas de Apoio Deciso
do Banco do Estado de Sergipe e professora de curso de ps-graduao em Admi-
nistrao de Banco de Dados e da Universidade Tiradentes.
PROJETANDO SISTEMAS DE APOIO DECISO
BASEADOS EM DATA WAREHOUSE
w
w
w
.
a
x
c
e
l
.
c
o
m
.
b
r
297
Pirataria crime contra os direitos autorais, com penas para os infratores
de acordo com a Lei 9.610 de 19 de fevereiro de 1998.
Este e-book no pode ser vendido e/ou distribudo em CD-ROM, DVD-ROM ou por programas
de compartilhamento P2P. A forma correta de obter este arquivo adquirindo-o atravs dos
sites da Editora Axcel (www.axcel.com.br) e de Jlio Battisti (www.juliobattisti.com.br).
Se voc adquiriu este documento atravs dos meios legais descritos acima, no distribua ou
venda este produto. Voc estar cometendo um crime contra o autor da obra.
Se voc adquiriu este e-book por intermdio de terceiros, regularize sua situao entrando em
contato pelo e-mail editora@axcel.com.br, para que no seja alvo das penalizaes previstas em
Lei. Usar cpia ilegal tambm crime de violao dos direitos autorais.
REPRODUO PROIBIDA PELA LEI DO DIREITO AUTORAL.
Projetando Sistemas de Apoio Deciso Baseados em Data Warehouse
II
Copyright 2004 by Methanias Colao Jnior
Copyright 2004 by Axcel Books do Brasil Editora Ltda.
Nenhuma parte desta publicao poder ser reproduzida
sem autorizao prvia e escrita de Axcel Books do Brasil Editora.
Editora de Produo: Gisella Narcisi
Editor Responsvel: Ricardo Reinprecht
Projeto Grfico: Axcel Books
Equipe Axcel: Alberto Baptista Garcia, Carlos Alberto S Ferreira,
Fagner Silva Henrique e Ingo Bertelli
Axcel Books do Brasil Editora
Av. Paris, 571 Bonsucesso
21041-020 Rio de Janeiro RJ
Tel.: (21) 2564-0085 Fax: (21) 2564-1607
E-mail: editora@axcel.com.br
Web Site: http://www.axcel.com.br
Projetando Sistemas de Apoio a Deciso Baseados em Data Warehouse
ISBN: 85-7323-208-0
Os originais de livros enviados para avaliao pela Editora sero destrudos,
quando no aprovados. No ser feita sua devoluo em nenhuma hiptese.
Os conceitos emitidos nesta obra so de inteira responsabilidade do Autor.
Para uso pessoal. Este material no pode ser utilizado em Salas de Aula e para ministrar treinamentos.
III
Sumrio
A chave para ter sucesso nos negcios ter
informaes que ningum mais tem.
Aristteles Onassis
IV
Agradecimentos
Em primeiro lugar agradeo a Deus, pelas constantes bnos derramadas. Na nossa
vida, devemos fazer tudo na dependncia Dele.
Agradecimentos a todos da minha famlia e em especial: ao meu pai Methanias e
minha me Valdice, responsveis diretos pela minha formao; minha irm Mahely e
ao meu cunhado Marco pelo incentivo; e aos meus primos queridos Gardnia, Tici, S,
Edmilson Jnior, Alexsandro e Jonatas, pela admirao.
Agradeo, com o corao cheio de orgulho e felicidade, aos meus melhores ex-alunos de
Banco de Dados, e agora meus colegas e professores, Andr Vincius Nascimento e Maria
de Ftima Almeida. Colaboradores diretos e indispensveis deste livro, eles so um
exemplo de amor, profissionalismo e dedicao rdua tarefa de dominar conhecimentos
da rea de Informtica.
Gerente de Marketing rika Celestino pela contribuio quanto aplicao prtica de
marketing nas organizaes.
Ao Designer Jonatas Lemos Rodrigues pela arte final das ilustraes.
Aos meus queridos alunos e ex-alunos, maiores motivos da escrita deste livro.
Aos professores Asterio Tanaka, Eduardo Bernardes e Marcus Sampaio pela experincia
transmitida e pela confiana em mim depositada.
Aos irmos em Cristo, que sempre oram pela minha vida.
A todos os amigos e profissionais que contriburam para realizao desta obra.
V
Sumrio Prefcio
Sobre o Autor
Methanias Colao Jnior M.Sc. em Informtica pela Universidade Federal de Campina
Grande (UFCG) na rea de Sistemas de Informao e Banco de Dados. Especialista em
Cincia da Computao e Tecnologia da Informao, membro da equipe de Sistemas
de Apoio Deciso do Banco do Estado de Sergipe e professor da Universidade Tiradentes
e da Faculdade Sergipana (UNIP). Atua como consultor de empresas na rea de DW,
prestando servios Secretaria Municipal de Finanas de Aracaju, Secretaria de Estado
da Fazenda de Sergipe e Companhia Alagoana de Refrigerantes (Coca-Cola/SE). Ministra
treinamentos e presta consultoria em Engenharia de Software, Banco de Dados, Oracle e
ferramentas de BI.
Colaboradores
Andr Vincius Nascimento graduado em Cincia da Computao pela Universidade
Federal de Sergipe e M.Sc. em Informtica pela UFCG na rea de Sistemas de Informao
e Banco de Dados. membro da equipe de Sistemas de Apoio Deciso do Banco do
Estado de Sergipe e professor da Universidade Federal de Sergipe, alm de ministrar
aulas em curso de ps-graduao em Administrao de Banco de Dados.
Maria de Ftima Almeida graduada em Cincia da Computao pela Universidade
Federal de Sergipe e M.Sc. em Informtica pela UFCG na rea de Sistemas de Informao
e Banco de Dados. Membro da equipe de Sistemas de Apoio Deciso do Banco do
Estado de Sergipe e professora de curso de ps-graduao em Administrao de Banco
de Dados e da Universidade Tiradentes.
Colaboraram em trs captulos deste livro.
VI
Apresentao
A globalizao da economia, a mutao dos mercados e o acirramento da concorrncia
tornaram a informao o bem mais valioso para as organizaes, e estas passaram a
tratar seus dados no mais como meros resultados de transaes, mas como propulsores
para atingir melhores resultados. A partir dos anos 90, o termo Data Warehouse (DW)
passou a ser crucial quando o tema era anlise de negcios, crescimento e capacidade de
prever novas oportunidades.
As informaes contidas em um Data Warehouse possuem caractersticas especficas que
as distinguem das informaes existentes em projetos de bancos de dados convencionais.
Grandes volumes de dados, dados histricos e bases no normalizadas so algumas das
peculiaridades que impedem a utilizao das metodologias tradicionais de anlise de
sistemas. Ao deparar-se com esse quadro, a indstria de software, aliada a pesquisadores
da rea, passou a investir na concepo de um paradigma que pudesse atender a essa
demanda. Desse trabalho, surgiram livros e artigos que sempre tentaram mostrar o caminho
das pedras para a concepo de um ambiente de Data Warehousing bem-sucedido.
Infelizmente, a realidade mostra que muitos projetos de Data Warehouse fracassaram
completamente ou causaram frustrao nas expectativas de seus usurios (administradores,
contadores gerenciais, economistas, executivos, diretores, etc.) devido falta de
conhecimento das pessoas envolvidas e principalmente falta de uma literatura clara e
concisa, baseada em experincia acadmica e prtica, do caminho a ser seguido para o
sucesso de um projeto como esse.
Ao implantar um DW, os administradores esperam alcanar benefcios, tais como:
Recursos para acessar de modo rpido e flexvel as informaes do negcio.
Disponibilidade de mecanismos que incorporam a inteligncia do negcio e permitem
efetuar o acompanhamento do desempenho e identificar as excees no padro de
comportamento esperado.
Facilidades para a definio de estratgias microssegmentadas, a partir do conhecimento
relacionado com o comportamento dos clientes.
Criao de conhecimento com base na anlise de diversos cenrios e identificao de
padres de comportamento ou preferncias/hbitos de consumo.
VII
Sumrio
Reduo de riscos associados ao negcio, atravs das facilidades de anlise de risco e
avaliao de alternativas.
Rapidez na percepo de probabilidade de ocorrncia de inadimplncia e de riscos
associados composio do negcio, aliada possibilidade de adoo de novas tticas
para a correo de desvios.
Implementao de um efetivo marketing de relacionamento, permitindo a definio
de estratgias com foco nos clientes e atendimento das suas expectativas, visando
elevao da taxa de reteno dos mesmos.
Esse livro, fruto da experincia de vrios profissionais especialistas nas reas de Banco de
Dados, Marketing, Data Warehouse e Data Mining, traduz as potencialidades de um Data
Warehouse como a base para Sistemas de Suporte Deciso. Atravs de uma linguagem simples
e com foco em aspectos essenciais, o leitor adquire um conhecimento slido sobre Sistemas de
Apoio Deciso e passa a conhecer as caractersticas fundamentais de todas as ferramentas
envolvidas neste processo. So abordados conceitos sobre ferramentas de apoio deciso tais
como as ferramentas OLAP, EIS, ERP, CRM, Database Marketing e Data Mining.
Alm de preparar conceitualmente o leitor, apresentamos uma metodologia de
desenvolvimento e documentao de um projeto de ambiente de suporte deciso. Muitos
dos exemplos apresentados no se prendem aos conceitos bsicos, mas agregam
conhecimento e criatividade por parte do seu autor e colaboradores, inclusive estendendo
a UML para documentao de um DW. Tivemos um cuidado especial para no apresentar
um Data Warehouse como a resoluo de todos os problemas, mas sim apresentar solues
que podem ser utilizadas por gerentes de um projeto como este. A maioria dos exemplos
do livro baseia-se em uma rede nacional de restaurantes fictcia e todos os captulos do
livro so finalizados com um resumo para fixao e simples reviso do que foi abordado.
O primeiro captulo do livro introduz o leitor no domnio dos Sistemas de Informao
relacionados com o Apoio Deciso. Especificamos todas as solues criadas para gerao
de informaes gerenciais, bem como suas nomenclaturas especficas que hoje perfazem
o jargo dos sistemas que servem alta gerncia.
No Captulo 2, apresentamos o conceito de Data Warehouse (DW) e o encaixamos no do
contexto dos ambientes de suporte deciso modernos. O leitor poder caracterizar e
diferenciar um DW dos bancos de dados convencionais.
Apresentao
VIII
O Captulo 3 descreve as principais ferramentas de apoio deciso (ou ferramentas de
Business Intelligence (BI)) utilizadas no mercado. Elucidamos as caractersticas
fundamentais de uma ferramenta OLAP e preparamos o leitor para avaliar ferramentas de
apoio deciso, averiguando exigncias da rea de negcios para este tipo de ferramenta.
Alm das ferramentas OLAP, pela importncia mercadolgica, conceituamos CRM e Da-
tabase Marketing, relacionando-os com um projeto de DW. Discutimos aspectos importantes
para a construo de um DW que apoiar uma poltica de relacionamento com clientes.
No Captulo 4, enfatizamos o esquema de dados utilizado em Data Warehouses
relacionais. Procuramos dirimir as principais dvidas de projeto surgidas na
construo de esquemas-estrela.
O Captulo 5 discute e apresenta concluses de todo o contexto que envolve uma
arquitetura para gerncia e armazenamento de metadados. Analisamos os requisitos de
uma boa arquitetura, o processo de concepo de um repositrio de metadados e sugerimos
o armazenamento de alguns atributos e entidades indispensveis sobrevivncia de um
projeto de DW.
Os Captulos 6 e 7 so a espinha dorsal do livro. No Captulo 6, apresentamos uma
metodologia clara de desenvolvimento de um DW e, no Captulo 7, uma extenso UML
para documentar todas as etapas do processo.
O Captulo 8 prov o embasamento terico necessrio para a elaborao de um projeto
fsico de dados para Data Warehouse; e serve de base para a escolha de um SGBD que
apresente caractersticas que dem suporte criao e evoluo de um banco de dados
voltado para suporte deciso.
Por fim, no Captulo 9, so apresentados conceitos de Data Mining e sua importncia
como auxlio para a tomada de deciso. O Processo de Descoberta de Conhecimento
abordado em detalhes, seguido de uma discusso sobre as principais tcnicas de Minerao
de Dados. O captulo finalizado com uma explicao detalhada de um algoritmo de
gerao de regras de associao, uma das mais importantes tcnicas de Data Mining, e
uma discusso sobre a importncia de integrar as tcnicas de minerao aos Sistemas
Gerenciadores de Bancos de Dados.
IX
Sumrio
Objetivos
Com este livro, o leitor alcanar os seguintes objetivos:
Familiarizar-se com todos os conceitos, regras e expresses do domnio de Sistemas
de Apoio Deciso.
Entender o que um Data Warehouse (DW) e sua relevncia no atual mercado
competitivo.
Aprender a iniciar e gerenciar um projeto de DW com sucesso, bem como documentar
todas as etapas do processo (inclusive utilizando UML Unified Modeling Language
ou linguagem de modelagem unificada).
Identificar os requisitos para gerncia e armazenamento de metadados em um DW.
Conhecer as principais ferramentas de BI (Business Intelligence, ou Inteligncia
Aplicada aos Negcios).
Valorizar a importncia de uma poltica de marketing e entender como conduzir um
projeto de DW para beneficiar o marketing estratgico das organizaes.
Dominar a configurao ideal de Sistemas Gerenciadores de Bancos de Dados
utilizados em projetos de DW.
Compreender os benefcios e funcionamento de um processo de minerao de dados
(Data Mining) em bancos de dados histricos.
Pblico-Alvo
Este livro interessa a qualquer pessoa envolvida na produo, implantao, manuteno,
gerncia e utilizao (inclusive diretores e executivos) de Sistemas de Informaes
Gerenciais ou de Apoio Deciso.
Alm de beneficiar profissionais e estudantes de Informtica em matrias como Banco
de Dados e Tpicos Especiais, o livro direcionado para estudantes e profissionais de
Administrao, Publicidade, Contabilidade e Economia, envolvidos profissionalmente
Apresentao
X
com a rea gerencial ou academicamente com disciplinas como Tecnologia da Informao,
Sistemas de Informao, Contabilidade Gerencial e etc.
Os profissionais de Marketing tambm podero encontrar neste livro a base para a
implantao de aplicaes de Database Marketing.
Como Usar Este Livro
Para alunos e profissionais de informtica, sugerimos uma leitura linear deste livro. Uma
ateno especial deve ser dedicada aos Captulos 4, 6, 7 e 8, que apresentam
responsabilidades especficas destes profissionais em projetos de DW.
Os demais acadmicos e profissionais de outras reas podem comear pela leitura dos
Captulos 1, 2, 3 e 9, enfatizando aspectos relacionados aos negcios. No Captulo 9, por
exemplo, possvel entender como funciona o processo de minerao de dados em dois
nveis. Um nvel para aqueles que desejam saber o que e quais os benefcios da minerao
para os negcios, e, para os interessados, um nvel de conhecimento de como funcionam
os processos de minerao.
Os Captulos 4, 5, 6 e 7 so importantssimos para servirem de guia para administradores
e diretores de reas de sistemas de informao. Estes captulos fornecem ao gestor um
embasamento para o acompanhamento de projetos de DW, visando eliminar a frustrao
de expectativas.
XI
Sumrio
Sumrio
Captulo 1: Introduo .................................................................................................... 1
Evoluo dos Sistemas de Informao .......................................................................... 2
Sistemas de Informao Gerenciais ............................................................................... 5
Sistemas de Informao Executivos .............................................................................. 6
Sistemas de Apoio Deciso ........................................................................................ 7
Resumo ...................................................................................................................... 10
Captulo 2: Sistemas de Apoio Deciso Baseados em Data Warehouse .................... 13
Conceito de Data Warehouse ..................................................................................... 16
Caractersticas de um Data Warehouse ....................................................................... 16
Orientado por Temas ............................................................................................ 16
Integrado.............................................................................................................. 16
Variante no Tempo................................................................................................ 17
No Voltil ............................................................................................................ 17
Data Marts ................................................................................................................. 18
Arquitetura Bsica de um Data Warehouse ................................................................. 18
Data Warehouse X Enterprise Resource Planning (ERP) ............................................... 21
Resumo ...................................................................................................................... 22
Captulo 3: Ferramentas de Apoio Deciso ................................................................ 25
Ferramentas OLAP...................................................................................................... 26
OLAP X OLTP ........................................................................................................ 28
Caractersticas ....................................................................................................... 29
Conjunto de Operaes OLAP............................................................................... 30
Ranging ................................................................................................................ 31
Drilling.................................................................................................................. 32
Drill Down ............................................................................................................ 32
Drill Across ............................................................................................................ 33
Drill Up ................................................................................................................. 34
Rotation ................................................................................................................ 34
Ranking ................................................................................................................ 34
OLAP Multidimensional (MOLAP) ......................................................................... 35
OLAP Relacional (ROLAP) ...................................................................................... 37
Tendncias ............................................................................................................ 37
CRM .......................................................................................................................... 38
Fidelizao ............................................................................................................ 40
As Relaes Virtuais Atravs da Internet ................................................................. 41
Database Marketing .............................................................................................. 42
XII
Resumo ...................................................................................................................... 45
Captulo 4: Modelagem de Dados Para Data Warehouses ........................................... 47
Por que No Usar o Modelo Entidade e Relacionamento Tradicional? ......................... 48
Star Schema (Esquema Estrela) ................................................................................... 49
Tipos de Dimenso ............................................................................................... 52
Dimenso Tipo 1 ............................................................................................. 52
Dimenso Tipo 2 ............................................................................................. 52
Dimenso Tipo 3 ............................................................................................. 53
Dimenses descaracterizadas ........................................................................... 55
Chaves Artificiais .............................................................................................. 56
Dimenso Tempo.................................................................................................. 57
Hierarquias............................................................................................................ 58
Agregados ............................................................................................................ 59
Tipos de indicadores para as tabelas de fatos ........................................................ 60
Um Estudo de Caso Para Definio dos Passos da Modelagem Dimensional ............... 60
Dvidas comuns de projetistas de DW ....................................................................... 62
Resumo ...................................................................................................................... 64
Captulo 5: Gerncia de Metadados em um Data Warehouse ..................................... 67
Metadados em um processo de Data Warehousing .................................................... 68
Metadados Operacionais ............................................................................................ 71
Metadados de Negcio .............................................................................................. 73
Uma Arquitetura Bsica de Metadados ....................................................................... 74
Tipos de Arquitetura de Metadados ............................................................................ 75
Requisitos de uma Arquitetura de Metadados............................................................. 77
Integrao ............................................................................................................ 77
Extensibilidade ...................................................................................................... 77
Robustez ............................................................................................................... 78
Abertura ............................................................................................................... 78
Automatizao e Reutilizao de Processos ........................................................... 78
Padronizao do Processo de Integrao............................................................... 79
Flexibilidade.......................................................................................................... 80
Gerenciamento de Mltiplas Verses de Metadados .............................................. 80
Facilidades de Atualizao ..................................................................................... 81
Arquitetura Multicamadas ..................................................................................... 81
Gerenciamento de segurana................................................................................ 81
Funcionalidade de um Repositrio de Metadados ...................................................... 82
Proviso de Informao......................................................................................... 82
Metamodelo ......................................................................................................... 83
Acesso ao Repositrio............................................................................................ 83
Administrao de Verso e Configurao .............................................................. 83
XIII
Sumrio
Anlise de Impacto ............................................................................................... 84
Notificao ........................................................................................................... 84
Metadados Tcnicos e Qualidade de Dados em Metadados ....................................... 84
Controle de Metadados em um Projeto Evolutivo de Construo de DW.................... 89
Padronizao de Metadados ...................................................................................... 91
O Metamodelo CWM ........................................................................................... 92
Resumo ...................................................................................................................... 94
Concluses ................................................................................................................. 96
Captulo 6: Uma Metodologia para Implementao de um Data Warehouse ............. 99
Diferenas entre a Anlise Tradicional
e a Anlise de Sistemas de Apoio Deciso .............................................................. 102
Entrevistas ................................................................................................................ 104
Caractersticas a serem Analisadas no Ambiente de Informaes Existente........... 105
Disponibilidade de Informaes ..................................................................... 105
Acesso s informaes disponveis.................................................................. 105
Acuracidade................................................................................................... 105
Modelos de Tabelas Geradas em Entrevistas com os Usurios e Analistas ............ 106
Tcnicas .............................................................................................................. 109
Equipe ..................................................................................................................... 110
Ambiente de Hardware e Software ........................................................................... 113
Esquema de Carga ................................................................................................... 116
Sistema de Carga ................................................................................................ 119
Pontos de Verificao para Garantia de Qualidade .................................................... 121
Cronograma de Implementao............................................................................... 123
Resumo .................................................................................................................... 125
Captulo 7: Estendendo a UML Para Documentar um Data Warehouse .................... 129
Projeto Arquitetural .................................................................................................. 130
Documentao de Data Marts .................................................................................. 132
Viso Esttica ...................................................................................................... 132
Viso Dinmica ................................................................................................... 133
Transformao de atributos............................................................................ 133
Transformao de atributos em mais de um atributo ..................................... 134
Tabela se transforma em outra sem alterao de atributos ............................. 134
Atributos novos nas tabelas ............................................................................ 135
Atributos que Deixam de ser Usados .............................................................. 135
Chaves Artificias ............................................................................................. 135
Esteretipos Para Dimenso, Tabela de Fatos e Tabelas Auxiliares ................... 136
Hierarquias, Agregados e Tipos de Indicadores .............................................. 137
Documentao da Configurao Fsica e de Relatrios OLAP .................................... 138
Resumo .................................................................................................................... 139
XIV
Captulo 8: Otimizao da Configurao Fsica de
um Banco de Dados Para Data Warehouse ................................................................ 141
Bloco de Dados ........................................................................................................ 143
Tamanho de Bloco de Dados .............................................................................. 145
Tamanho da rea Livre........................................................................................ 146
Separao Fsica de Tipos de Dados.......................................................................... 146
Particionamento....................................................................................................... 148
Vises Particionadas ............................................................................................ 149
Tabelas e ndices Particionados............................................................................ 149
Vantagens do Particionamento............................................................................ 149
ndices ..................................................................................................................... 150
ndices de rvore B ............................................................................................. 150
ndices de Bitmap ............................................................................................... 151
Carregamento de Dados Para o Data Warehouse ..................................................... 153
Resumo .................................................................................................................... 154
Captulo 9: Data Mining e a Descoberta de Informaes
Para Alavancagem do Negcio ................................................................................... 157
Minerao de Dados: alguns conceitos ..................................................................... 158
O Processo de Descoberta do Conhecimento ........................................................... 161
Preparao dos Dados ................................................................................... 162
Data Mining e Customer Relationship Management (CRM) ..................................... 163
Como o Data Mining Ajuda o Database Marketing .................................................. 163
Principais Tcnicas de Minerao de Dados .............................................................. 165
Classificao........................................................................................................ 165
Regras de Associao .......................................................................................... 167
Gerao de Regras de Associao: o algoritmo Apriori .............................................. 171
Gerao dos Conjuntos .................................................................................. 172
Fase de Poda ....................................................................................................... 173
Contagem de Suporte......................................................................................... 174
Gerao de Regras .............................................................................................. 175
O Algoritmo Apriori Quantitativo: uma nova abordagem.................................... 176
Integrao de Minerao de Dados e SGBDs ........................................................... 177
Abordagens de Integrao .................................................................................. 178
Categoria Convencional Fracamente Acoplada............................................ 178
Categoria Fortemente Acoplada .................................................................. 180
Categoria Caixa Preta .................................................................................... 180
Resumo .................................................................................................................... 181
Bibliografia .................................................................................................................. 183
Glossrio ...................................................................................................................... 191
ndice Remissivo .......................................................................................................... 193
1
Captulo 1: Introduo
1
C A P T U L O
I n t r o d u o
2
Evoluo dos Sistemas de Informao
O cenrio de competio no mundo dos negcios tem assistido a profundas mudanas
nos ltimos anos. As empresas esto sendo impulsionadas a rpidas e contnuas adaptaes
para sobreviverem e crescerem no mercado. necessrio conquistar novos clientes, manter
os j existentes, ampliar o ramo de negcios com qualidade e inov-lo conforme as
tendncias mercadolgicas. Produtos devem ser concebidos com alta economicidade e
com seus empreendedores aplicando um excelente grau de efetividade.
Para levar as corporaes a um lugar de destaque, os administradores precisam ter a capacidade
de analisar os dados disponveis e tomar decises rpidas e seguras. Diante desta necessidade
crescente, os sistemas de informao (SI) tm evoludo nas ltimas dcadas e buscado alternativas
para o fornecimento otimizado de informaes para apoio deciso. Os dados esto sendo
utilizados como verdadeiros recursos empresariais, porm no foi sempre assim. Para chegar ao
estado atual, os sistemas de informao passaram por longos anos de aperfeioamento, que
culminaram com a viso de executivos modernos e visionrios da informtica como uma forma
imbatvel de alavancagem de negcios. Resumiremos adiante como se deu esta evoluo.
Nos anos 60 os sistemas eram criados como verdadeiras ilhas de informao. As aplicaes
mantinham seus dados independentes e isolados das outras. Os dados comuns entre
aplicaes eram redundantes e, na maioria das vezes, inconsistentes. Um cadastro de
funcionrios, por exemplo, repetia-se no sistema de recursos humanos e no sistema de
emprstimos de ferramentas em uma indstria. Assim, se fosse necessria a criao de
uma nova aplicao que utilizasse informaes de funcionrios, um arquivo era gerado
especificamente para esta finalidade. Se os dados nele contidos fossem necessrios a outros
fins, criava-se um novo arquivo, onde, mais uma vez, repetiam-se os dados em comum. Os
dados se voltavam para o fornecimento de resultados especficos, relativos a problemas
especficos, gerados por dados tambm especficos. No existiam mtodos de gerenciamento
de dados como um recurso e nem para o recolhimento dos benefcios resultantes.
Foi em 1970 que aconteceu o advento do armazenamento em disco. Diferente do
armazenamento em fita magntica, os dados poderiam ser acessados diretamente e o tempo
de processamento era bem menor. Nesta poca, surgiu o termo OLTP
1
Processamento de
1
On Line Transaction Processing.
3
Captulo 1: Introduo
Transaes On Line para definir o processamento efetuado pelos sistemas de informao
transacionais ou operacionais. Estes sistemas de informao so tambm identificados
pela expresso Eletronic Data Processing (EDP), e so necessrios para o controle
operacional das organizaes. Sistemas OLTP fornecem agilidade, segurana e eficincia
na insero dos dados em bancos de dados, porm a maioria deles falha no fornecimento
de anlises significativas e levam muito tempo na recuperao de dados gerenciais.
Os Problemas da Redundncia...
Muitas empresas tiveram prejuzos srios devido presena de redundncia de dados e conseqente
inconsistncia dos mesmos. Podemos citar o exemplo do funcionrio de uma indstria demitido.
Na maioria das vezes, seu cadastro era excludo apenas do sistema de recursos humanos e, por
uma falta de integrao de sistemas, erroneamente mantido no sistema de emprstimos de
ferramentas. Nada impedia que a insatisfao com a demisso levasse a pessoa a visitar a oficina,
retirar as ferramentas mais caras e nunca mais voltar com as mesmas. A redundncia pode
transformar uma coisa simples em um verdadeiro caos para a organizao.
Paralelamente ao advento do OLTP, surgiram os Sistemas de Gerenciamento de Bancos de
Dados (SGBD). Os SGBDs foram softwares criados para fornecer acesso s informaes
e atualizao das mesmas, garantindo a segurana e a integridade de um banco de dados.
O surgimento dos Sistemas de Gerenciamento de Banco de Dados tinha como objetivos:
potencializar o gerenciamento dos dados como recursos e eliminar as redundncias de
informaes existentes nos sistemas desenvolvidos anteriormente (Figura 1.1). Podemos
afirmar que nenhum dos objetivos foi atingido totalmente, pois, mesmo usando
softwares gerenciadores de banco de dados, as empresas continuaram criando sistemas
isolados em termos de compartilhamento de dados comuns (Figura 1.2). Alm disso,
os profissionais de informtica da poca, apesar de serem pessoas competentes,
desenvolviam sistemas sem nenhuma viso metodolgica e com uma preocupao
extrema na estruturao e reestruturao do hardware das organizaes. At as mudanas
mais recentes, a engenharia de software era emprica e foram produzidos softwares
sob demanda, sem nenhuma preocupao com a gerao futura de informaes
integradas e estratgicas.
4
Figura 1.1: Arquitetura Simples de um SGBD.
Conclumos ento que faltaram dois requisitos essenciais da engenharia de software
moderna: administrao de dados e uma metodologia de desenvolvimento. Nosso livro
no pretende discutir problemas de metodologia, nem tampouco a crise do software, mas
fica claro que, sem administrao de dados, os sistemas podem continuar sendo
desenvolvidos sem a conscincia da importncia da integrao para a produo de
informaes gerenciais. Exemplificando, uma simples tabela de feriados pode ser repetida
em diversos sistemas, causando problemas de atualizao e inconsistncia. Imaginemos
clculos de juros semelhantes, sendo feitos com base em tabelas de feriados diferentes
ou desatualizadas.
Executivos sempre sofreram ao solicitarem relatrios gerenciais de sistemas distintos e
encontrarem resultados diferentes sobre assuntos comuns. Dos anos 80 at os dias atuais,
solues foram criadas para resolver os problemas decorrentes da falta de administrao
de dados e para produzir informaes gerenciais com uma nica verso da verdade.
Analisaremos estas solues a seguir.
5
Captulo 1: Introduo
Figura 1.2: Teia causada pela falta de integrao.
Sistemas de Informao Gerenciais
Depois da implantao de diversos sistemas de informao transacionais, as empresas
tendem naturalmente a desenvolver sistemas que forneam informaes integradas e
sumarizadas. Estas informaes podem ser oriundas dos diversos sistemas transacionais
existentes, bem como podem ser extradas de um nico sistema transacional, limitadas
ao escopo do mesmo. Atualmente, engenheiros de software competentes sempre
incorporam funcionalidades gerenciais em seus sistemas.
Informaes gerenciais tm a capacidade de prover insumo para anlise, planejamento e
suporte deciso, alm de possibilitarem, ao nvel ttico da organizao, a visualizao
do desempenho de um departamento e at mesmo de toda a corporao. Sistemas que
possuem essas informaes so geralmente chamados de Management Information
Systems (MIS) ou Sistemas de Informao Gerenciais (SIG).
6
Os SIGs comeam a surgir quando os gerentes sentem a necessidade de informaes
rpidas, em quantidade, com qualidade e, principalmente, integradas. o conhecido
estgio de controle e integrao de uma corporao. Nesta fase, os diretores e gerentes
costumam alavancar o desenvolvimento de sistemas com caractersticas gerenciais.
Um Sistema de Informao Gerencial verdadeiro deve fornecer informaes para os
planejamentos operacional, ttico e at mesmo estratgico da organizao, comparando
o desempenho atual da organizao com o que foi planejado. Os gerentes devem ser
capazes de analisar despesas e a compatibilidade das mesmas com o oramento planejado.
notrio que SIGs, apesar de no serem considerados Sistemas de Apoio Deciso,
auxiliam gerentes no processo de tomada de deciso e podem perfeitamente fazer parte
de um ambiente completo de suporte deciso. Na seo Sistemas de Apoio Deciso
diferenciaremos um Sistema de Informao Gerencial de um Sistema de Apoio Deciso.
Sistemas de Informao Executivos
Unindo informaes dos Sistemas Transacionais s informaes dos SIGs possvel
construir sistemas de informao voltados para executivos. Sistemas deste tipo tambm
podem agregar informaes coletadas de fontes externas organizao e prover os resultados
em formato interativo, diminuindo o esforo da alta gerncia para anlise dos mesmos.
Sistemas construdos para dinamizar o trabalho dos executivos so sugestivamente
chamados de Executive Information Systems (EISs), ou Sistemas de Informao
Executivos. No existem maiores diferenas conceituais em relao a um Sistema de
Apoio Deciso. O que diferencia , em geral, a interface com o usurio, que deve
permitir que um executivo utilize um EIS com facilidade. Estes sistemas provm aos
executivos informaes comparativas atravs de mapas, grficos e dados estatsticos
fceis de entender. Alm disso, agregam funcionalidades de correio eletrnico,
teleconferncias, calendrios, agendas, gerenciamento de projetos, tarefas e pessoas.
Na verdade, podemos considerar um Sistema de Informaes Executivo como um Sistema
de Informaes Gerenciais acrescido de caractersticas que do ao executivo a vantagem
de poder analisar informaes e organizar o seu trabalho em um nico ambiente.
7
Captulo 1: Introduo
Somente organizaes maduras e com boa administrao de dados conseguem desenvolver
e/ou implantar um Sistema de Informao Executivo. necessrio que os sistemas de
informao existentes reflitam o fluxo de informaes da organizao. A metodologia
de desenvolvimento adotada deve prever participao do usurio em todas as fases e a
organizao tem que vislumbrar sempre a informao como recurso e patrimnio. Em
outras palavras, os sistemas de informao passam a ser a base para o planejamento
estratgico, e todas as decises passam a depender destes sistemas.
Os Sistemas de Informao Executivos so confundidos com outras ferramentas de apoio
deciso, mas tm como principal diferena a facilidade. Ainda hoje, a maioria dos executivos
prefere ter uma tela EIS com botes mgicos para gerao de relatrios, a usar uma
ferramenta que necessite de apoio investigativo e intuio. Estas telas EIS fornecem dados
detalhados sobre o passado, presente e tendncias futuras das unidades de negcios em relao
ao mercado, alm de auxiliarem o processo de planejamento e de controle da organizao.
Um Sistema de Informao Executivo autntico deve permitir a navegao de dados
sintticos para dados mais detalhados, e pode fazer parte do conjunto de ferramentas e
sistemas que consultam uma base de dados histrica existente.
Sistemas de Apoio Deciso
O conceito de Sistemas de Apoio Deciso (SADs), ou Decision Support Systems (DSSs),
est na realidade relacionado com um ambiente complexo, projetado para fornecer
subsdios para que a alta gerncia tome decises.
Autores de livros de informtica voltados para as reas de administrao, economia e
contabilidade costumam definir SADs de forma ambgua, sem clara diferena entre um
Sistema de Apoio Deciso e um Sistema de Informao Gerencial, por exemplo. Nossa
obra tambm pretende contribuir para a formao de administradores modernos,
elucidando definies nebulosas da literatura existente.
A maioria dos conceitos enunciados sobre SADs os coloca como sistemas de informao
que apiam qualquer processo de tomada de deciso nos nveis ttico, estratgico e
operacional. Isto no suficiente, pois qualquer SI pode ser til ao nvel gerencial e, nem
por isso, todo Sistema de Informao ser um Sistema de Apoio Deciso. Um Sistema de
8
Informaes Gerenciais tambm pode apoiar qualquer processo de tomada de deciso ttica.
Um EIS apia decises estratgicas e at um Sistema de Informao Transacional pode
apoiar decises de nvel operacional. A pergunta : Qual a diferena ?.
O famoso exemplo das fraldas e da cerveja...
Atravs de um ambiente de suporte deciso bem projetado e utilizando Minerao de
Dados, uma rede de supermercados descobriu que a maioria dos pais que iam comprar
fraldas para seus filhos levava cerveja. O pessoal de marketing, muito inteligente, colocou
a cerveja e as fraldas prximas, com batata fritas entre elas, aumentando consideravelmente
a venda dos trs produtos. Muitas vezes, o cliente nem pretende levar a cerveja, mas o faz
quando v a tentao do lado das fraldas.
Existem vrias explicaes para o caso, como por exemplo a presena do beb significar falta de
tempo para ir a uma boate noite para beber. O fato que a deciso de reposicionamento do
estoque foi diretamente influenciada pela informao descoberta. H vrios outros exemplos
curiosos, como a venda de colrios em feriados e etc.
A diferena reside no fato de os Sistemas de Apoio Deciso no s fornecerem informaes
para tomada de decises, mas tambm contriburem e influenciarem o processo. Um SAD
deve fornecer e analisar alternativas, pesquisar histricos de decises tomadas e auxiliar a
resoluo de problemas estruturados. Estes sistemas podem simular impactos de investimentos
em um novo produto ou um novo projeto, baseados em bancos de dados de custos e rendimentos
e em algum modelo para anlise de risco em investimentos de capital.
Atualmente, algumas empresas j proporcionam que um gerente possa tomar uma deciso
baseada em um simples relatrio estatstico ou tomar outra completamente diferente,
baseada na descoberta de uma informao escondida na base histrica (veja o quadro O
famoso exemplo das fraldas e da cerveja...). A descoberta de informaes escondidas
atravs de Minerao de Dados (Data Mining) abordada no Captulo 9.
Entendendo a diferena, podemos conceituar um SAD como um ambiente projetado
para apoiar, contribuir e influenciar o processo de tomada de deciso (Figura 1.3). Este
ambiente formado pelos seguintes componentes:
Banco de Dados (BD): No podemos confundir o conceito de Banco de Dados com o
conceito de Sistema Gerenciador de Banco de Dados. Um Banco de Dados no est
necessariamente relacionado com armazenamento eletrnico. Bancos de dados podem
ser vistos como colees de dados inter-relacionados. Em um ambiente de suporte
9
Captulo 1: Introduo
deciso, podem ser formados por informaes internas e externas organizao, por
conhecimentos e experincias de especialistas e por informaes histricas acerca das
decises tomadas. Um Data Warehouse, objetivo principal do nosso livro, pode fazer
parte, ou ser o banco de dados principal de um ambiente de suporte deciso. A
princpio e simplificadamente, podemos conceituar um Data Warehouse como um
Banco de Dados projetado para armazenar informaes integradas de toda organizao,
mantendo um histrico das mesmas.
Sistema Gerenciador de Banco de Dados (SGBD): Como discutido anteriormente,
um SGBD uma coleo de programas que permitem aos usurios definir,
construir e manipular Bancos de Dados para as mais diversas finalidades. Os
dados num Banco de Dados devem ser integrados e compartilhados. Um Sistema
Gerenciador de Banco de Dados pode representar a unif icao de diversos
arquivos que, de outra forma, seriam distintos, eliminando-se total ou
parcialmente a redundncia entre os mesmos. J o compartilhamento no significa
apenas que as aplicaes existentes podem compartilhar dados do Banco de
Dados, mas tambm que novas aplicaes podem ser desenvolvidas para operar
sobre os mesmos dados armazenados.
Aplicativos com caractersticas gerenciais (AGs): So aplicativos com funes
gerenciais de anlise acrescidas. Aplicativos com estas funcionalidades podem fazer
parte do grande ambiente de suporte deciso.
Ferramentas de apoio deciso (FADs): Tambm chamadas de ferramentas de BI
(Business Intelligence, ou Inteligncia Aplicada aos Negcios), so softwares
desenvolvidos para apresentar graficamente as informaes, auxiliando a simulao
de situaes, fornecendo capacidade de anlise, ou descobrindo conhecimento. Alm
disso, existem ferramentas no mercado que facilitam a implementao de funes
especficas, tais como o Gerenciamento de Risco de Crdito, Rentabilidade de Clientes,
Database Marketing, etc.
Neste livro, abordaremos excelentes e importantes exemplos de FADs. No Captulo 3,
discutiremos sobre as ferramentas OLAP (abreviao de Analytic Processing On-Line,
ou processamento analtico on-line) de apoio deciso, bem como sobre ferramentas de
10
Figura 1.3: Ambiente de apoio deciso.
Resumo
Paulatinamente ao longo das trs ltimas dcadas, os sistemas de tecnologia da informao
tm se preocupado muito com problemas de negcios. Esta preocupao reside na
necessidade de competio das empresas no mercado globalizado. As organizaes devem
ser capazes de analisar os dados disponveis e tomar decises rpidas e seguras.
Solues para gerao de informaes gerenciais foram criadas, recebendo uma
nomeclatura especfica que hoje perfaz o jargo dos sistemas de informao que servem
alta gerncia. Enumeremo-las:
Sistemas de Informaes Gerenciais (SIG): Sistemas que geram informaes com a
capacidade de prover insumo para anlise, planejamento e suporte deciso, alm de
possibilitarem, ao nvel ttico da organizao, a visualizao do desempenho de um
departamento e at mesmo de toda a corporao.
Sistemas de Informao Executivos (EIS): Geram informaes gerenciais como os
SIGs e dinamizam o trabalho dos executivos atravs da agregao de funcionalidades
Database Marketing e CRM (Customer Relationship Management, ou gerncia da relao
com os clientes). No Captulo 9, esmiuaremos o conceito e caractersticas de um processo
de minerao de dados (Data Mining).
11
Captulo 1: Introduo
como correio eletrnico, teleconferncias, calendrios, agendas, gerenciamento de
projetos, tarefas e pessoas.
Sistemas de Apoio Deciso (SAD): Ambiente projetado para apoiar, contribuir e
influenciar o processo de tomada de deciso.
Os sistemas de informao envolvidos com o processo de tomada de deciso podem ser,
na realidade, ppeis assumidos por aplicaes criadas exclusiva ou parcialmente para
esse propsito.
13
Captulo 2: Sistemas de Apoio Deciso Baseados em Data Warehouse
2
C A P T U L O
Sistemas de Apoio
Deciso Baseados em
Data Warehouse
14
Os Sistemas de Apoio Deciso tradicionais eram concebidos atravs do desenvolvimento
de Ferramentas de Apoio Deciso (FAD) (ver Captulo 1) para produo e distribuio
de informaes teis para gerentes, executivos e analistas do conhecimento. Para a
produo destas informaes, as FADs acessavam os bancos de dados operacionais da
organizao, gerando um forte acoplamento entre Sistemas de Informaes Transacionais
e Sistemas de Apoio Deciso (Figura 2.1).
Como a quantidade de dados gerados nas empresas cresce em progresso geomtrica, o
acoplamento passou a ser um problema e, para que as aplicaes continuassem com um
bom desempenho, era preciso separar os dados mais antigos da base de dados acessada
pelas aplicaes transacionais, pois a concorrncia entre as consultas gerenciais e as
funes desempenhadas pelos Sistemas de Informao Transacionais aumentava o tempo
de resposta de qualquer servidor de banco de dados que estivesse sendo utilizado.
Figura 2.1: Acoplamento entre SIGs e Sistemas Fontes.
Assim, os dados histricos passaram a ser armazenados separadamente e restaurados
quando preciso. Porm, a confiana e desempenho tambm eram comprometidos pelo
15
fato de os dados no estarem adequados para o suporte deciso, ou seja, tanto estavam
desintegrados (Captulo 1), como tambm no foram modelados para otimizar o
desempenho de consultas gerenciais (discutiremos modelagem de dados para apoio
deciso no Captulo 4 deste livro).
Aliadas s necessidades supracitadas, consultas a esses dados histricos passaram a ser
constantes e nem sempre os mesmos eram restaurados com sucesso. O problema era, e
ainda em muitas empresas, o longo tempo de espera para restaurao e acesso a essas
informaes. A maioria dos gerentes passava dias para obter uma informao gerencial
e ainda assim no confiava na acuracidade da mesma.
Objetivando integrar dados de mltiplas fontes, um processo de anlise com informao
de qualidade sem impacto para o ambiente operacional e um atendimento a diferentes
tipos de usurios com agilidade e flexiblidade, surgiu o conceito de Data Warehouse
(Armazm de Dados) (Figura 2.2).
Figura 2.2: Integrao com um Data Warehouse.
16
Conceito de Data Warehouse
Data Warehouse (DW) um banco de dados histrico, separado lgica e fisicamente do
ambiente de produo da organizao, concebido para armazenar dados extrados deste
ambiente. Antes de serem armazenados no DW, os dados so selecionados, integrados e
organizados para que possam ser acessados da forma mais eficiente, auxiliando assim o
processo de tomada de deciso.
Segundo W. H. Inmon, especialista e pioneiro no assunto, um Data Warehouse um conjunto
de dados, no voltil, orientado a tpicos, integrado, que varia com o passar do tempo e que
serve de suporte para o processo de tomada de decises da gerncia. (W. H. Inmon, 1996).
Analisaremos as caractersticas enunciadas por Inmon a seguir.
Caractersticas de um Data Warehouse
Orientado por Temas
O Data Warehouse armazena informaes necessrias para o processo de suporte
deciso. Essas informaes so organizadas pelos temas importantes para o negcio da
empresa. Em uma rede de restaurantes, por exemplo, os temas so: produtos, clientes,
funcionrios, etc.
Cada tema pode envolver vrias tabelas. Considerando o tema cliente, podem existir
tabelas com as informaes gerais (nome, endereo, telefone, e-mail), outra com os clientes
que tiveram conta inferior a R$200,00, outra com os clientes com contas superiores a
R$300,00. Alm destas, podem existir tabelas cumulativas com os clientes que mais
consumiram no perodo de 1999 a 2003, e tabelas detalhadas que armazenaro o cdigo
do cliente, a data da venda, os produtos consumidos e o valor da despesa. Portanto,
percebe-se que, para o mesmo tema, podem existir vrios nveis de detalhamento.
Integrado
O Data Warehouse deve consolidar dados de diversas origens, o que geralmente envolve
diferentes codificaes. Os dados devem ser perfeitamente integrados para que ao serem
armazenados assumam uma nica conveno. Exemplificando: uma aplicao pode
17
codificar o sexo como M e F, outra pode codificar com 0 e 1, e uma outra pode usar
H e M. Quando os dados so extrados para o Data Warehouse devem assumir uma
nica codificao.
Variante no Tempo
Os dados em produo so atualizados de acordo com as mudanas necessrias, e com
isso os dados histricos so perdidos. Em consultas, so capturados os dados vlidos
no momento do acesso. Por exemplo, o estado civil de um cliente X que em 2000 era
solteiro e passa hoje para casado. No momento da consulta feita hoje, ser apenas mostrado
que o cliente casado, perdendo as informaes anteriores.
Em um Data Warehouse os dados so carregados como fotos da base de dados operacional
do momento, ou seja, cada ocorrncia e cada mudana so consideradas como um novo
registro. Os dados no so atualizados e podem ser comparados ao longo do tempo. Ao
consultar o cliente X do exemplo anterior em 2000, viro os dados da poca de solteiro.
No Voltil
Teoricamente, depois que os dados esto no Data Warehouse (DW) no podero ser
atualizados ou alterados, apenas acessados. Os novos dados sero absorvidos, integrando-
se com os dados existentes. O Data Warehouse permite apenas a carga inicial dos dados
e a consulta aos mesmos. Contraditoriamente, existe no ambiente operacional uma grande
volatilidade, visto que os dados so atualizados registro a registro a qualquer momento.
Escrevemos teoricamente, pelo fato de algumas situaes especficas exigirem
atualizao dos dados carregados para o DW. Podemos tomar como exemplo a carga
de dados contbeis. Como saldos contbeis normalmente sofrem atualizaes, pois
podem existir lanamentos de valores errados, tambm necessrio corrigir esses
valores carregados para o DW.
A caracterstica da no volatilidade pode ser aceita totalmente devido ao fato de o banco
de dados de um DW ser configurado fisicamente para otimizao de incluses e consultas
(analisaremos otimizao fsica no Captulo 8), ou seja, no deve ser um banco preparado
para atualizaes. Desta forma, melhor remover a carga errada e carregar os dados
novamente do que realizar updates (atualizaes) na base do DW.
18
Data Marts
O Data Mart geralmente descrito como um subconjunto dos dados contidos em um
Data Warehouse extrado para um ambiente separado. Data Marts so muito teis nas
seguintes condies:
Os dados devem estar segregados para melhorar o desempenho do sistema do ponto
de vista do usurio.
Deve existir uma cpia dos dados onde s pessoas com autorizao devem ter o
privilgio de acess-las.
Em um ambiente corporativo, importante fortalecer o conceito de propriedade
dentro do banco de dados. Diferentes setores sero responsveis por diferentes Data
Marts. Segundo Kimball, especialista no assunto:
Um Data Mart, tambm conhecido como Warehouse Departamental, uma abordagem
descentralizada do conceito de Data Warehouse (Kimball et al., 1998).
Esses ambientes fisicamente distintos trazem benefcios, mas existe um preo a se pagar.
Com a presena de muitos Data Marts pode haver o risco de redundncia. A construo
de Data Marts deve ter sempre a preocupao de compartilhamento de dados, tabelas e
relatrios em comum entre os departamentos. A dificuldade de evitar a redundncia de
dados pode ir contra o paradigma de um Data Warehouse j que a separao fsica em
diferentes grupos diminui essa habilidade de organizao. Fica clara a necessidade de
preservao da consistncia das informaes presentes nos Data Marts atravs da
eliminao de redundncias, pois relatrios em comum no podem possuir valores
diferentes. Isto uma caracterstica da maioria dos Sistemas Transacionais das corporaes
e deve ser eliminada com a presena de um DW.
Arquitetura Bsica de um Data Warehouse
Descreveremos resumidamente o funcionamento de uma arquitetura padro de Data
Warehouse (Figura 2.3).
Os dados vm dos diversos Sistemas Transacionais e geralmente so tratados por uma
ferramenta ETL
2
. Ferramentas ETL so responsveis pela extrao, transformao e
2
Extraction, Transformation and Load, ou extrao, transformao e carga.
19
carregamento dos dados no DW. Num projeto de construo de um Data Warehouse, os
processos ETL consomem mais de 70% do tempo de desenvolvimento. Todo este processo
normalmente desenvolvido especificamente para cada empresa, devido diversidade
existente em termos de estruturas de dados nos sistemas fontes transacionais e tambm
falta de conhecimento e documentao dos mesmos.
Figura 2.3: Arquitetura bsica de DW.
O fluxo de dados comea nas aplicaes fontes, e passa por uma rea intermediria
de armazenamento chamada de Staging rea (rea de Estgio). Na Staging rea os
dados sofrem integrao, limpeza e depois so exportados para o DW. A integrao
consiste na consolidao dos dados de diversas origens, o que geralmente envolve
diferentes codificaes. Os dados devem ser perfeitamente integrados para que ao
serem armazenados assumam uma nica conveno (ver seo Integrado neste
captulo). A limpeza a rejeio de valores invlidos, chaves repetidas ou registros
com outros tipos de erro. Estas aes constituem a tarefa mais crtica na gerao de
um Data Warehouse (descreveremos em detalhes a implementao de um processo
ETL no Captulo 6).
Segundo Kimball, alm da Staging rea, o ideal que exista uma segunda rea intermediria
antes da carga definitiva para o DW. Esta segunda rea, chamada de ODS (Operational
Data Store), deve ser uma base de dados com utilizao previsvel, parcialmente estruturada
20
e analtica cujo histrico de apenas 30 ou 60 dias e cujas informaes esto organizadas
por rea de negcio (Figura 2.4). um retrato da base obtida da extrao, transformao e
limpeza de dados dos sistemas fontes operacionais da empresa e no incio de sua concepo
era visto como sendo um tipo de DW (Kimbal et al., 1998).
Na realidade, no ODS, os dados so mantidos como no ambiente operacional, ou seja, no
esto modelados ainda para consultas gerenciais, porm podem ser teis para recupero
de cargas de dados problemticas. Com um ODS, no necessrio refazer toda a extrao
para corrigir eventuais problemas na transferncia dos dados para o DW. Muitos projetos
de DW possuem ODS e utilizam esta rea para fazer validao de regras de negcio, ou
seja, na Staging rea a limpeza se resume em verificar chaves repetidas e problemas de
integridade referencial; verificaes de regra de negcio so feitas no ODS.
Por economia de espao de armazenamento em disco muitos DWs so implementados
sem ODS. No h implicaes graves nisto, pois cargas problemticas podem ser refeitas.
A nica implicao ser um maior tempo para correo de cargas erradas.
Figura 2.4: Arquitetura de DW segundo Kimball.
21
Somente aps a integrao e limpeza os dados so exportados para o DW. Depois os
dados so transmitidos para Data Marts (Figura 2.5) ou, numa abordagem centralizada,
so consultados diretamente pelos usurios atravs de uma Ferramenta de Apoio
Deciso, por exemplo.
Figura 2.5: DW e Data Marts.
Data Warehouse X Enterprise
Resource Planning (ERP)
Antes da implantao de DWs as empresas j buscavam a integrao dos dados acessados
por seus sistemas e agilizao dos seus processos. Foram criados softwares multi-
modulares para auxiliar gestores em todas as fases do negcio.
Sistemas capazes de facilitar o fluxo de informaes entre todas as atividades de uma
empresa, como fabricao, logstica, finanas e recursos humanos, so chamados de
ERP (Enterprise Resource Planning ou Sistemas de Gesto Empresarial). Um ERP ,
geralmente, composto por um banco de dados nico, operando em uma plataforma comum
que interage com um conjunto de aplicaes.
Um banco de dados ERP pode ser confundido com um DW, porm existem diferenas
bsicas. Apesar de fornecerem uma estrutura integrada, sem redundncia de
informaes, Sistemas de Gesto Empresarial (ERP) utilizam o mesmo banco de dados
22
para armazenamento de dados operacionais e para armazenamento de dados histricos
utilizados como fonte de informaes gerenciais. Nos deparamos, mais uma vez, com
o problema da concorrncia. Consultas gerenciais so feitas no mesmo ambiente
operacional e provavelmente sero mais lentas do que consultas feitas em um DW
separado. Alm disso, os dados tambm no esto modelados para um maior
desempenho destes tipos de consulta.
Na nossa opinio, um ERP uma excelente soluo para gesto das empresas, desde que
seja escalvel, ou seja, que se integre facilmente com outros aplicativos e possa ser
estendido facilmente medida que a corporao cresce e necessita da automatizao de
outras funcionalidades.
Sistemas ERP fornecem excelentes relatrios gerenciais; todavia, no podemos descartar
a presena de um DW. Por possuir uma base de dados integrada, um ERP pode ser a fonte
ideal para um DW projetado para fornecer informaes gerenciais com agilidade e sem
concorrncia com o ambiente operacional.
Resumo
Mesmo com a tendncia natural de crescimento da integrao entre aplicaes operacionais,
decises de nvel estratgico e ttico exigem um contedo mais rico do que aquele encontrado
no ambiente operacional, o qual apresenta inmeros obstculos para o processamento
analtico. As empresas precisam de um ambiente exclusivo que armazene adequadamente
os dados extrados das diversas bases, disponibilizando as informaes a qualquer instante.
O banco de dados deste ambiente, que surgiu como soluo para prover informaes
gerenciais para a tomada de decises, foi denominado de Data Warehouse.
Um DW um banco de dados histrico, separado lgica e fisicamente do ambiente de
produo da organizao, concebido para armazenar dados extrados deste ambiente.
Antes de serem armazenados no DW, os dados so selecionados, integrados e organizados
para que possam ser acessados da forma mais eficiente, auxiliando assim o processo de
tomada de deciso.
A dificuldade de implementao de um DW completo imediatamente fez surgir o conceito
de Data Mart, ou Warehouse Departamental. Um Data Mart um subconjunto lgico de
um DW, um DW setorial.
23
Para serem carregados em um DW os dados devem passar por processos ETL. Estes
processos consomem mais de 70% do tempo de desenvolvimento do projeto de um DW
e so responsveis pela extrao, integrao, limpeza e posterior carga dos dados para o
DW. A integrao consiste na consolidao dos dados de diversas origens, o que geralmente
envolve diferentes codificaes. Os dados devem ser perfeitamente integrados para que
ao serem armazenados assumam uma nica conveno. A limpeza a rejeio de valores
invlidos, chaves repetidas ou registros com outros tipos de erro. Estas aes constituem
a tarefa mais crtica na gerao de um Data Warehouse.
Sistemas ERP podem ser excelentes fontes de informaes para um DW. Isto possvel
pelo fato de um banco de dados nico interagir com todos os aplicativos deste tipo de
sistema. Desta forma, elimina-se a redundncia de informaes e redigitao de dados, o
que assegura a integridade das informaes obtidas.
25
Captulo 3: Ferramentas de Apoio Deciso
3
C A P T U L O
Ferramentas de Apoio Deciso
26
As Ferramentas de Apoio Deciso esto relacionadas com o conceito de BI (Business
Intelligence, ou Inteligncia Aplicada aos Negcios). Podemos dizer que BI um conjunto
de tecnologias que permitem o cruzamento de informaes e suportam a anlise dos
indicadores de desempenho de um negcio. Portanto, as ferramentas de apoio deciso
que fazem inferncias em um banco de dados histrico, um DW por exemplo, so tambm
chamadas de ferramentas de BI.
Neste captulo, analisaremos dois tipos de Ferramentas de Apoio Deciso. Pela maior
popularidade do uso, destacaremos as ferramentas OLAP e introduziremos o conceito
de CRM. Ressaltamos que trataremos de ferramentas de Data Mining para apoio deciso
em um captulo especial, o Captulo 9.
Ferramentas OLAP
Uma das tarefas mais solicitadas ao pessoal de TI (tecnologia da informao) nas
organizaes a produo de consultas que descrevam de forma clara e concisa
informaes sobre os negcios da empresa. Essas consultas ou relatrios apresentam-se
desde simples listagens de funcionrios ou produtos a complexos mapas de demonstrao
de crescimento financeiro. Independente de seu objetivo final, a verdade que, nem
sempre, possvel prever durante o projeto ou compra de sistemas quais informaes
necessitaro ser extradas. Essa incapacidade de previso, algo perfeitamente aceitvel
quando o assunto refere-se a negcios, faz surgir a necessidade de mecanismos auxiliares,
adjacentes aos sistemas utilizados, para a gerao de novos relatrios.
A primeira soluo da indstria de software para atender a essa demanda foi o desenvolvimento
de ferramentas de gerao de relatrios. Porm, a partir do momento em que a informao
passou a ser o bem mais valioso para as organizaes e com o surgimento de toda a infra-
estrutura dos Data Warehouses, surgiu a necessidade da criao de ferramentas com uma
capacidade de anlise maior do que a dos geradores de relatrios tradicionais. Ou seja, embora
a infra-estrutura necessria para armazenar milhares de informaes estivesse pronta, um
novo problema tornar-se-ia o mais novo pesadelo para o pessoal de TI. Como apresentar
essas informaes? Como fornecer a capacidade de anlise para essas informaes?
As informaes contidas em um Data Warehouse possuem caractersticas especficas
que as distinguem das informaes existentes em projetos de bancos de dados
27
convencionais. Grandes volumes de dados, dados histricos e bases no normalizadas
so algumas das peculiaridades que impedem a utilizao das ferramentas convencionais
para gerao de relatrios. Ao deparar-se com esse quadro, a indstria de software, aliada
a pesquisadores da rea, tambm passou a investir na concepo de um paradigma de
ferramenta que pudesse atender a essa demanda. Desse trabalho, surgiu o que chamamos
de tecnologia OLAP (Analytic Processing On-Line ou processamento analtico on-line)
que caracteriza o conjunto de tcnicas utilizadas para tratar informaes contidas em um
Data Warehouse. O termo foi criado em 1993, pelo Dr. E.F. (Ted) Codd, em um ensaio
intitulado Providing OLAP to User-Analysts: An IT Mandate. Pouco tempo depois da
publicao desse ensaio, a palavra OLAP transformou-se em uma buzzword no cenrio
de bancos de dados, e todo profissional de sistemas esforava-se para compreend-la, e
como ela se encaixava no paradigma de aplicaes de suporte deciso.
No entanto, OLAP, conforme definida pelo Dr. Codd, no uma nova tecnologia e
alguns produtos j existiam h tempos no mercado. Por fora deste mesmo mercado,
as ferramentas que apresentavam caractersticas OLAP passaram a ser referenciadas
como ferramentas OLAP.
Atualmente, as linguagens de programao e as principais empresas de Sistemas Gerenciadores
de Banco de Dados oferecem APIs
3
e componentes como solues prontas para a criao de
aplicaes de Business Inlelligence (termo utilizado atualmente para definir aplicaes voltadas
alavancagem dos negcios), passando a falsa impresso da simplicidade por trs de uma
ferramenta verdadeiramente OLAP. Essa tendncia tem encorajado gerentes de projeto a
embarcarem em uma viagem sem fim: o desenvolvimento de uma ferramenta OLAP. Essa
escolha vai de encontro ao grande conselho dado pelos mais experientes consultores na rea:
Dont Build, Buy It . Ou seja, o investimento e o tempo despendido na construo de uma
soluo caseira no traz resultados aparentes e, em sua maioria, resulta em projetos fracassados
ou produtos com carncia interminvel de manuteno.
O ideal adquirir uma ferramenta OLAP com as caractersticas e particularidades que
analisaremos adiante. importante conhecer o que uma verdadeira ferramenta OLAP
deve prover aos seus usurios.
3
Application Program Interface Um conjunto de funes predefinidas, documentadas e disponibilizadas por um
software que servem de interface para outras aplicaes interagirem com o mesmo. Um Software A pode
fornecer uma API e a mesma ser usada por um Software B, possibilitando uma interface (ligao) entre eles.
28
OLAP X OLTP
Os bancos de dados desenvolvidos para OLTP (On-Line Transaction Processing, ou
processamento de transaes on-line) geralmente so considerados inapropriados para
Data Warehouses. Eles no podem ser repositrios de fatos e dados histricos, no atendem
satisfatoriamente a consultas e a recuperao rpida dos dados praticamente impossvel.
Os dados esto em constante mudana. Basicamente, os bancos OLTP oferecem grandes
quantidades de dados brutos que no so facilmente compreendidos.
Em contraste com os sistemas OLTP, as ferramentas OLAP oferecem um grande potencial de
recuperao e anlise de informaes rpida e fcil. O processamento OLAP prov acesso
aos dados corporativos de um Data Warehouse com total segurana e controle, e prov aos
usurios todas as flexibilidades existentes em programas dedicados anlise de dados.
A tecnologia OLAP dispe de um conjunto de operaes e ferramentas que torna o
usurio capaz de lidar com a complexidade das planilhas. possvel analisar tendncias,
fazer comparaes, destacar problemas e manipular as informaes em qualquer ordem.
Vejamos as principais diferenas entre os processamentos OLAP e OLTP na tabela a seguir.
OLAP OLTP
Relevncia para dados histricos Mantm usualmente a situao corrente.
Necessidade de ver o dado sob Voltado para velocidade e automao de
diferentes perspectivas: aplicaes funes repetitivas.
dinmicas
Atualizaes quase inexistentes, apenas Atualizaes em grande nmero.
novas inseres
Baseado em dados histricos, Baseado em transaes
consolidados e freqentemente
totalizados
Operaes de agregao e cruzamentos Alto nvel de detalhe
Tabela 3.1: Diferenas entre OLAP e OLTP
29
Caractersticas
A principal caracterstica dos sistemas OLAP permitir uma viso conceitual multidi-
mensional dos dados de uma empresa. Os dados so modelados numa estrutura conhecida
por cubo (Figura 3.1), onde cada dimenso representa os temas mais importantes da
empresa como produto, cliente, funcionrio e tempo.
Figura 3.1: Cubo de 4 dimenses
Muitos usurios se perguntam por que uma simples planilha no pode ser considerada
uma ferramenta OLAP. Sabemos que o termo planilha vem de plano (duas dimenses
apenas), no permitindo, em linhas gerais, uma viso multidimensional dos dados. Alm
da viso multidimensional dos dados da empresa, existem tambm 11 regras criadas
pelo Dr. Codd em 1993 que servem para avaliar uma ferramenta considerada OLAP. No
total temos 12 regras que so descritas a seguir:
Viso conceitual multidimensional: os dados so modelados em diversas dimenses
podendo haver cruzamento de todos os tipos de informaes.
Transparncia: OLAP deve atender a todas as solicitaes do analista, no
importando de onde os dados viro. Todas as implicaes devem ser transparentes
para os usurios finais.
30
Acessibilidade: as ferramentas OLAP devem permitir conexo com todas as bases de
dados legadas. A distribuio de informaes deve ser mapeada para permitir o acesso
a qualquer base.
Desempenho de informaes consistentes: as ferramentas OLAP devem possuir
conhecimento sobre todas as informaes armazenadas para que possa disponibilizar,
sem complexidade para o usurio final, qualquer tipo de consulta.
Arquitetura cliente/servidor: OLAP deve ser construda em arquitetura cliente/ servidor
para que possa atender a qualquer usurio em qualquer ambiente operacional.
Dimensionalidade genrica: deve ser capaz de tratar informaes em qualquer
quantidade de dimenses.
Manipulao de dados dinmicos: devido ao grande volume de informaes
armazenadas nas diversas dimenses de um modelo multidimensional, comum a
espacidade dos dados, e ento essas clulas nulas devem ser tratadas para evitar custos
com memria.
Suporte a Multiusurios: nas grandes organizaes comum vrios analistas
trabalharem com a mesma massa de dados.
Operaes ilimitadas em dimenses cruzadas: as ferramentas OLAP devem ser capazes
de navegar nas diversas dimenses existentes.
Manipulao intuitiva dos dados: o usurio dever ser capaz de manipular os dados
livremente, sem necessitar de qualquer tipo de ajuda.
Flexibilidade nas consultas: o usurio dever ter a flexibilidade para efetuar qualquer
tipo de consulta.
Nveis de dimenso e agregao ilimitados: devido s vrias dimenses existentes,
deve haver vrios nveis de agregao dos dados.
Conjunto de Operaes OLAP
Geralmente, ao iniciar uma consulta, o usurio tem perguntas como: Qual o vinho mais
vendido no perodo de 2001 a 2003?. Para que essa pergunta seja traduzida de forma
inteligvel ao computador, devem ser oferecidos aos usurios meios para realizar tal
tarefa. Os fabricantes OLAP adotaram diversas solues.
31
Uma primeira tentativa foi a de oferecer uma tela com interface grfica, onde botes,
listas e marcadores compem o cenrio da anlise. Essa soluo no se mostrou eficiente
para uma primeira consulta, pois o usurio fica restrito a uma interface predefinida.
Essa abordagem eficiente para modificao de um cenrio atual produzido a partir de
consultas iniciais e intuitivas. O usurio tem a liberdade de incrementar a consulta com
o uso desta interface.
Em uma segunda tentativa foi implementado um conjunto de instrues para compor
uma extenso SQL
4
, onde o usurio monta o cenrio conforme a digitao de comandos.
Essa abordagem a mais flexvel, embora no seja a mais popular, j que geralmente os
usurios OLAP no detm os pormenores tcnicos das linguagens de programao.
Aps a montagem do cenrio de uma consulta, freqentemente o analista de negcios
deseja mudar o resultado da anlise. De nada adiantaria a montagem se no houvesse
meios de manipulao. Atualmente as ferramentas OLAP fornecem suporte para funes
de derivao de dados complexos, que recebe o nome de Slice and Dice.
O suporte Slice and Dice uma das principais caractersticas de uma ferramenta OLAP.
Ele serve para modificar a ordem das dimenses, alterar linhas por colunas de maneira a
facilitar a compreenso dos usurios. Essa caracterstica de extrema importncia, pois
com ela podemos analisar as informaes de diferentes prismas, permitindo ao usurio
investigar diferentes inter-relacionamentos. O Slice and Dice compreende quatro
operaes: Ranging, Drilling, Rotation e Ranking.
Ranging
a operao responsvel por, a qualquer momento, alterar o resultado das consultas,
inserindo novas posies ou removendo as que esto em foco. Para que isto ocorra
preciso que o usurio informe o que est modificando e o que ser feito. Por exemplo, a
insero de um novo produto em uma consulta. O resultado desse Ranging ser
considerado para todas as demais operaes, ou seja, pode-se encarar o resultado como
um novo cubo gerado a partir do cubo original.
4
SQL Structured Query Language Linguagem de manipulao e definio de dados de um Banco de
Dados Relacional.
32
Drilling
Aps escolher o que deseja analisar, o analista ainda pode mudar o escopo do que est
analisando, porm essas informaes podem encontrar-se agregadas em diversos nveis.
O Drilling permite navegao por entre estes nveis. Existem trs operaes OLAP que
permitem ao analista mudar o escopo dos dados: Drill Down, Drill Up e Drill Across.
Figura 3.2: Exemplo de hierarquia de uma dimenso Produto
para uma organizao de restaurantes, onde podem
ser efetuadas as operaes de Drilling.
Drill Down
Esta operao navega verticalmente na hierarquia no sentido em que os dados so mais
atmicos. Considerando a Figura 2.4 possvel analisar as vendas de todos os produtos
do restaurante. Mas se a pergunta fosse: Por que as vendas de Massas foram maiores do
que as vendas de Carnes em Maio de 1999?.
Para responder a essa pergunta, o usurio precisa montar o seguinte cenrio:
Uma viso com os tipos de produtos
Uma outra viso com o total de vendas de todos os pratos
Posio: Ms: Maio, Ano: 1999
33
Figura 3.3: Resultado (Para Ms = Maio e Ano = 1999).
Com esse resultado o analista no pode tomar nenhuma deciso. Para que os dados
sejam mais especficos ser preciso utilizar o conceito de Drilling, para que seja alterado
o escopo da anlise.
A fim de conseguir informaes mais detalhadas sobre os pratos de Massas e Carnes, o
analista precisar navegar ao longo das hierarquias de cada dimenso, at chegar no nvel
mais especfico de cada prato. Executando o DrillDown em Massas obtm-se o seguinte:
O primeiro resultado poderia ser do tipo:
Figura 3.4: Resultado do DrillDown em massas.
O resultado mostra que o motivo da elevao das vendas de Massas foi gerado pela
notvel sada de Pizzas.
Drill Across
Esta operao permite navegar transversalmente no eixo da rvore hierrquica. O Drill
Across uma operao de grande utilidade, pois permite inserir e retirar posies do
cenrio corrente.
Continuando com o exemplo anterior, se quisermos comparar a vendagem de Pizzas
com os demais pratos de Carnes, precisaramos navegar no mesmo nvel de detalhe das
posies da dimenso. Neste caso, o resultado seria o seguinte:
34
Figura 3.5: Resultado do Drill Across.
Drill Up
A ltima operao do Drilling realiza a funo inversa do Drill Down. Ela permite ao
usurio uma viso mais agregada das informaes. Nesta tcnica podemos navegar nos
diversos nveis at o mais sumarizado.
Aplicando Drill Up no exemplo acima poderamos obter:
Figura 3.6: Resultado do Drill Up.
Rotation
Alm de mudar as posies em foco, o analista tambm tem a flexibilidade de alterar a forma de
visualizao das informaes. O Rotation permite ao analista mudar a viso que est tendo dos
dados. Vale salientar que o Rotation no adiciona nem retira posies do cenrio. A grande
vantagem do Rotation que no h operaes de disco no servidor para que os dados sejam
vistos de forma diferente. O que muda apenas como os dados sero dispostos para o usurio.
O exemplo anterior est analisando os tipos de produtos e seus totais. Aplicando o Rotation
possvel obter uma anlise com os tipos de produtos e seus respectivos preos.
Ranking
Com esta operao o analista pode filtrar as informaes que ele deseja ver. possvel
fazer uma classificao dos dados obtidos e operar diretamente sobre os valores das
35
clulas. Vale frisar que as operaes anteriores atuavam apenas sobre as posies ou
dimenses dos dados. Atravs do Ranking, o analista pode executar diversos tipos de
filtros, eliminando assim as informaes desnecessrias.
Figura 3.7: Resultado sem aplicao de Ranking.
Utilizando a planilha acima, podemos aplicar o ranking de Quais os 3 pratos mais
vendidos?, e como resultado teremos:
Figura 3.8: Resultado com aplicao de Ranking.
Pelo exemplo acima, percebemos que no s 3 clulas ficaram preenchidas, e sim as que tiveram
os maiores valores. Em todos os meses a vendagem de pizza foi superior de outras massas.
OLAP Multidimensional (MOLAP)
A primeira categoria de ferramentas chama-se OLAP Multidimensional (MOLAP). Essas
ferramentas utilizam um modelo multidimensional de dados e permitem a navegao de
um nvel de detalhamento para outro mais baixo ou mais alto em tempo real.
36
Os bancos de dados multidimensionais surgiram para melhorar a relao custo/benefcio
na implantao OLAP. Em resumo o MOLAP uma classe de sistemas que permite a
execuo de anlises sofisticadas e explorao de dados usando como gerenciador um
banco de dados multidimensional.
Em um banco de dados MOLAP os dados so mantidos em arranjos que simulam um
cubo com n dimenses e indexados de maneira a prover um timo desempenho no acesso
a qualquer elemento. Combinando as dimenses, o usurio pode ter uma viso geral de
todos os dados da empresa num excelente desempenho.
Um array multidimensional tem um nmero fixo de dimenses e os valores so
armazenados nas clulas. Cada dimenso consiste de um nmero de elementos. Em outras
palavras, o cubo (Figura 3.9) , de fato, apenas uma metfora visual, uma representao
intuitiva do evento, pois todas as dimenses coexistem para todo ponto no cubo e so
independentes umas das outras.
Figura 3.9: Viso multidimensional do volume de
vendas de uma rede de concessionrias.
37
OLAP Relacional (ROLAP)
Como a maioria das empresas utiliza os Bancos de Dados Relacionais
5
, tambm surgiu,
paralelamente ao conceito de MOLAP, o conceito de ROLAP (Relacional OLAP) como
uma grande soluo para o aproveitamento de uma tecnologia aberta e padronizada que
se beneficia de uma grande diversidade de plataformas e paralelismo de hardware.
Os sistemas ROLAP permitem anlise multidimensional dos dados que esto armazenados
em uma base de dados relacional, podendo ser feito todo o processamento no servidor da
base de dados e depois gerados os comandos SQL e as tabelas temporrias. De forma
inversa podem ser executados os comandos SQL para recuperao dos dados e posterior
processamento no servidor OLAP.
Os servidores ROLAP, alm de possurem as caractersticas dos sistemas OLAP, utilizam-
se de metadados (Captulo 5), dados sobre dados, para descreverem o modelo dos dados
e auxiliarem a construo de consultas. Tambm so criados comandos SQL otimizados
para bancos de dados, ajudando o analista na utilizao desta tecnologia.
Nas ferramentas ROLAP, o uso de uma camada semntica acima do esquema relacional permite
que os dados sejam apresentados ao usurio atravs do modelo multidimensional. Logo, interfaces
ou servidores ROLAP so definidos como sistemas OLAP que traduzem operaes e consultas
realizadas em um esquema multidimensional para um esquema relacional. Contudo, algumas
ferramentas exigem que os dados estejam estruturados em um esquema relacional particular
que facilite a traduo de consultas entre os dois modelos. Este esquema, denominado de esquema
estrela, permite a simulao de um Banco de Dados Multidimensional numa base relacional.
No Captulo 4, estenderemos a explicao do esquema estrela.
Ferramentas ROLAP tm um menor desempenho em relao s ferramentas MOLAP,
sendo um fator crtico em grandes DWs.
Tendncias
Atualmente, a maioria das ferramentas OLAP consegue acessar mais de um tipo de banco de
dados, ou seja, as mesmas so capazes de fazer uma espcie de processamento hbrido (ROLAP
5
Bancos de Dados Relacionais so bancos de dados onde os usurios vem os dados como um conjunto de tabelas.
38
e MOLAP). Em outras palavras, as ferramentas conseguem acessar Bancos de Dados
Relacionais, Bancos de Dados Multidimensionais e at outros modelos de banco de dados.
Uma tendncia natural que todas as ferramentas OLAP do mercado atinjam esse patamar.
Uma outra tendncia, que deve ser meta dos modernos Sistemas Gerenciadores de Banco
de Dados, a presena, em um s pacote de software, de uma arquitetura relacional, ou
outra qualquer, e uma arquitetura multidimensional, ou seja, os SGBDs devem incorporar
uma base multidimensional para prover facilidades a ambientes de suporte deciso.
Quando um SGBD proporciona tecnologia multidimensional dentro do seu banco de
dados, facilita o processo de escolha de uma organizao, entre um banco de dados
multidimensional OLAP e um Banco de Dados Relacional. A idia principal
proporcionar o desempenho e a flexibilidade de um Banco de Dados Multidimensional e
manter a gerenciabilidade, escalabilidade
6
, confiana e acessibilidade j conquistadas
pelos Bancos de Dados Relacionais.
A unio de dois modelos em um nico banco proporciona reduo do tempo de atualizao,
pois permite o armazenamento em tabelas relacionais ou multidimensionais. Assim, os
dados no so replicados em duas bases de dados. Tipicamente usam-se dois passos no
processo de manuteno (atualizao do Data Warehouse, geralmente relacional, e
atualizao do banco de dados multidimensional). Com um banco hbrido, o tempo entre
os dados serem disponibilizados pelos sistemas fonte e estarem prontos para serem
analisados menor. Ganha-se tambm em acuracidade, porque os dados no precisam
ser replicados entre tabelas relacionais e tabelas multidimensionais, isto , no h
sincronizao. Todos os usurios tm acesso a uma nica verso dos dados quando os
mesmos so alterados e gravados no banco de dados.
CRM
Atualmente, a maioria das empresas ainda possui problemas de viso de marketing. Mesmo
aquelas totalmente informatizadas e com processos bem definidos possuem falhas nos
processos de adaptao, comunicao, avaliao e anlise dos seus mercados.
6
Escalabilidade a capacidade que um sistema apresenta de poder adaptar-se facilmente a uma carga
crescente de recursos e servios.
39
Para continuar a existir e crescer no mercado, as organizaes devem conhecer a si mesmas
e principalmente conhecer, criar e manter os seus clientes. Administrar hoje um exerccio
constante de quebra de tradies tericas estabelecidas. Nos ltimos anos, grandes
corporaes vm concentrando esforos, independente da rea em que atuam, para
conhecer bem os hbitos dos seus clientes. Todos aqueles que compem a empresa devem
ter o objetivo nico de oferecer o melhor para os consumidores dos seus produtos. O
cliente precisa ser visto por todos os departamentos da mesma maneira e a comercializao
no deve estar focada nos produtos, mas nas necessidades de cada consumidor.
Assim, numa empresa todos devem ser vendedores. Todos devem ter conscincia de
que a sobrevivncia e o sucesso da empresa dependem de cada um e no apenas do
Departamento de Vendas ou do Marketing. Exemplificando, at as pessoas da
contabilidade devem ser vendedores e fazer a diferena. A telefonista passa a ser
importantssima, pois, s vezes, o primeiro contato do cliente com a empresa.
Essa importante viso de marketing foi empacotada na sigla CRM (Customer Relationship
Management ou gerenciamento das relaes com o cliente). O principal objetivo do CRM
conquistar a fidelidade dos clientes satisfazendo suas reais necessidades de consumo.
Estamos diante de uma verdadeira revoluo nos modelos tradicionais de vendas e market-
ing. A venda como arte, bem como malas diretas oferecendo produtos s pessoas erradas,
passam a ter seus dias contados. Passamos da era do produto para a era do cliente e da era
do marketing de massa para o marketing individualizado (one-to-one).
Vender deixou de ser apenas falar e passou a ser uma prestao de servios. A venda
sinnimo da administrao eficaz das contingncias de compra. Para alcanar esse
patamar, a informao deve ser o principal produto. Vende quem sabe o que o cliente
quer, como ele quer e quando ele quer.
As empresas devero ouvir os seus clientes, pois esta a melhor maneira de
compreender o mercado; todavia, nem sempre o cliente sabe o que ele quer. Atravs
de uma boa anlise de mercado, as organizaes devero ser capazes de surpreender
e entusiasmar o cliente. Quem ficar fazendo apenas o que o cliente pede, correr o
risco de perd-lo para um concorrente que o surpreenda e o encante com um produto
ou servio novo e diferente.
40
Muitas empresas e produtos que fizeram sucesso no foram pedidos de clientes. Ns no
pedimos o telefone celular e vivemos hoje na dependncia dele. No pedimos sistemas
de computador com interface grfica e estamos todos mal-acostumados com janelinhas
e botes amigveis nas telas de computador.
Como no poderia deixar de ser, a tecnologia da informao desempenha e desempenhar
um dos papis mais importantes neste processo de conquista e fidelizao dos clientes.
Para aplicar o conceito de CRM, como veremos a seguir, as empresas devero ter bancos
de dados (idealmente Data Warehouses) organizados e estruturados para servirem de
base na manuteno dos clientes.
Fidelizao
Utilizaremos o termo fidelizar, porm sabemos que no existem clientes verdadeiramente
fiis. Na verdade, as empresas devem buscar a agregao de novos valores s suas marcas,
pois clientes permanecem consumindo um produto ou servio enquanto existem vantagens
para eles. Podemos metaforizar e dizer que clientes so gatos e no cachorros, ou seja,
eu continuo com voc enquanto a situao estiver confortvel para mim.
Portanto, fidelizar um cliente significa conquist-lo, valorizando a relao para manter
por mais tempo. A base do CRM est na segmentao. A partir da faz-se uma
diferenciao no tratamento. O resultado a fidelidade.
Os clientes no podem ser tratados da mesma forma. Os que trazem mais rentabilidade,
ou maior volume, so clientes valiosos, que devem ter um tratamento diferenciado. Muitos
clientes optam por um produto inferior na qualidade apenas pelo fato de serem bem
tratados. A individualizao faz a diferena, pois tambm existem casos de clientes que
deixam de consumir um produto no pelo maltrato e sim pela indiferena.
O pacote CRM traz um conjunto de processos para identificar o cliente certo, oferecer-
lhe o que interessa, no momento em que ele precisa, atravs do canal adequado. Vender
para um novo cliente custa bem mais do que a venda para um cliente antigo.
Mesmo os clientes menores devem ser considerados importantes. Imaginem um casal
que comprou po e leite durante 25 anos em uma padaria. Se este casal gastou em mdia
um dlar por dia, isto representou, ao longo dos 25 anos, US$ 9.125,00 para o dono da
41
padaria. Alm disso, quantos clientes no foram conquistados com as recomendaes do
casal? Cliente fiel significa cliente vendedor.
Para vender, o cliente, mais uma vez, precisa ser surpreendido. Ningum vai ao cinema
e diz que viu uma tela gigante. O cliente fala do que o surpreendeu. Neste momento, os
leitores so nossos clientes. O nosso objetivo escrever um livro que agrade e surpreenda
o leitor positivamente atravs de uma leitura fcil e compreensiva de assuntos mistificados
por muitos. Se os leitores gostarem deste livro, esperamos isso, recomendaro o mesmo
a amigos, colegas de profisso e de universidade. Um cliente satisfeito comenta com
cerca de 4 pessoas e um insatisfeito comenta com cerca de 10.
As Relaes Virtuais Atravs da Internet
Nos prximos anos, estaremos comprando todos os produtos e servios de que precisamos
atravs da internet. Empresas transacionando eletronicamente no conceito chamado B2B
(Business to Business), ou consumidores interagindo com empresas (B2C Business to
Customer), j se tornaram elementos comuns da nossa sociedade.
Portanto, o CRM deve ser aplicado tambm na relao virtual. Adoramos entrar em um
site e termos um tratamento personalizado. importante que sejam oferecidos os produtos
que nos interessam e fundamentalmente precisamos de facilidade e agilidade na escolha
destes produtos. Estatsticas mercadolgicas mostram que mais de 60% dos clientes
internet desistem de suas compras pela demora e dificuldade dos sites.
As empresas devem fornecer boas informaes sobre os produtos que esto sendo
vendidos, diminuindo a incerteza do cliente e conseqentemente diminuindo tambm o
nmero de desistncias. Tambm importante planejar a entrega dos produtos que esto
sendo vendidos, o chamado SCM SupplyChain Management, pois empresas podem ter
sua imagem denegrida pela incapacidade de entrega de produtos vendidos via internet
ou atravs de outro canal. Todo o processo de entrega e o prprio acesso s compras
devem oferecer segurana ao cliente.
A tendncia que as organizaes faam parcerias para entrega e armazenamento dos
seus produtos. O custo dos produtos no cai, mas o custo da compra sim. Toda competncia
ser transferida para a venda, ou seja, informaes de qualidade, em abundncia e com o
mnimo custo para acesso.
42
Para descobrir os interesses dos clientes (traar o perfil) e oferecer os produtos certos em
sites internet, novamente, as corporaes devero ter Data Warehouses (Captulo 2)
armazenando o histrico das compras dos clientes, suas reclamaes, sugestes e etc.
Isto traz um novo conceito, o Database Marketing.
Database Marketing
Podemos definir marketing como o exerccio de estar atento s tendncias do mercado,
para identificar e produzir, rapidamente, aquilo que o cliente quer. Database Marketing
(DBMKT) o termo que est sendo usado por especialistas para definir a aplicao de
marketing com o auxlio de Data Warehouses. A integrao a palavra-chave neste
processo, para que se tire proveito das informaes j existentes sobre clientes, utilizadas
para uma realimentao eficiente do banco de dados de relacionamento.
O Data Warehouse para ser usado por ferramentas de Database Marketing deve
transformar todo o histrico de relacionamento entre clientes e fornecedores, contido na
base de dados operacional, em transformaes segmentadas sobre o pblico da empresa,
pois no podemos nos relacionar com quem ns no conhecemos.
Todos os conceitos de BI (Business Inteligence) vistos at agora devem ser utilizados. O
passo inicial construir um DW, em que informaes dimensionais (tempo, produto,
cliente e etc.) facilitem aspectos de segmentao, permitindo um foco mais objetivo
sobre campanhas de marketing. Os conceitos de Data Mining (Captulo 9), ou Minerao
de Dados, tambm podero ser aplicados para descoberta de informao sobre clientes.
Aps a construo do DW, o passo seguinte manter o foco no cliente como diretriz
para alcanar os objetivos do negcio. O conhecimento do cliente em todas as dimenses
o componente fundamental do processo, sendo portanto necessrio dispor de grande
variedade de dados e informaes, dentre as quais podem ser citadas:
Dados cadastrais completos ou primrios.
Informaes sobre a composio familiar.
Histrico do relacionamento com a empresa.
Aspectos que caracterizam o cliente como uma entidade individualizada.
Hbitos e preferncias de consumo, considerando produtos e servios de um modo geral.
43
O processo de planejamento do negcio efetuado de acordo com o mercado alvo em
que a organizao deseja atuar. O perfil dos clientes permitir que seja realizada a
segmentao dos clientes e seja feita a anlise do risco associado operao geral da
empresa. Este processo cclico e sua preciso apresenta uma estreita relao com a
disponibilidade de uma ampla gama de dados atuais e histricos, alm de projees
sobre a evoluo dos tpicos considerados durante os processos de anlise e de simulao.
Os mecanismos de acompanhamento e de controle permitiro a monitorao do alcance
das metas estabelecidas, a identificao da ocorrncia de eventuais desvios e a execuo
de aes corretivas e/ou proativas adequadas para cada rea de atuao.
Figura 3.10: Viso do relacionamento existente entre o
foco no cliente e o processo do negcio pretendido.
O foco no cliente exige que as informaes sejam geradas a partir da combinao dos
dados tratados por diversos aplicativos existentes no ambiente convencional. A eficincia
do processo de negcio est intimamente ligada disponibilidade de recursos para a
anlise de alternativas e avaliao do risco associado com cada uma delas.
44
Focar no cliente significa basicamente tratar clientes diferentes de forma diferente. Os
principais objetivos so:
Identificar os clientes que do prejuzo empresa. Como eles nunca vo desaparecer,
no adianta desprez-los. A empresa deve descobrir quanto custa atend-los para
diminuir ou eliminar este custo;
Figura 3.11: Processo de negcio.
Identificar e manter clientes mais lucrativos. Conhecendo as preferncias individuais
de seus melhores clientes, as empresas podem personalizar sua oferta de servios e
produtos para os mesmos;
Identificar e desenvolver relacionamentos com clientes de maior potencial. O cliente
pode ter necessidades que so satisfeitas pela concorrncia.
45
As empresas devero focar inicialmente nos clientes que j so fiis para depois continuar
na busca incessante por novos clientes, pois mais barato manter do que conquistar
novos clientes. Atingir este foco no simples e pode significar mudanas na estrutura
de toda a organizao, principalmente no modo de pensar das pessoas.
Resumo
Em 1993, o Dr. E.F. (Ted) Codd criou o termo OLAP em um ensaio intitulado Providing
OLAP to User-Analysts: An IT Mandate. Pouco tempo depois da publicao desse ensaio,
a palavra OLAP transformou-se em uma buzzword no cenrio de bancos de dados, e
todo profissional de sistemas esforava-se para compreender a OLAP e como ela se
encaixava no paradigma de aplicaes de suporte deciso.
Alm de definir OLAP, o Dr. Codd tambm criou 12 regras para OLAP. No entanto,
OLAP, conforme definida pelo Dr. Codd, no uma nova tecnologia e alguns produtos j
existiam h tempos no mercado. Basicamente, um sistema OLAP qualquer sistema que
capture informaes sumarizadas, e permita que essas sumarizaes sejam apresentadas
com suporte para funes de derivao de dados complexos. Este suporte recebe o nome
de Slice and Dice.
O suporte Slice and Dice uma das principais caractersticas de uma ferramenta OLAP.
Ele serve para modificar a ordem das dimenses e alterar linhas por colunas de maneira
a facilitar a compreenso dos usurios. Essa caracterstica de extrema importncia,
pois com ela podemos analisar as informaes de diferentes prismas, permitindo ao
usurio investigar diferentes inter-relacionamentos. O Slice and Dice compreende quatro
operaes: Ranging, Drilling, Rotation e Ranking.
Alm das ferramentas OLAP as empresas esto investindo em aplicaes voltadas para o
conhecimento do mercado e dos seus clientes. Essa importante viso de marketing foi
empacotada na sigla CRM (Customer Relationship Management ou gerenciamento das
relaes com o cliente). O principal objetivo do CRM conquistar a fidelidade dos clientes
satisfazendo suas reais necessidades de consumo. Estamos diante de uma verdadeira
revoluo nos modelos tradicionais de vendas e marketing. A venda como arte, bem como
malas diretas oferecendo produtos s pessoas erradas, passam a ter seus dias contados.
46
Database Marketing (DBMKT) o termo que est sendo usado por especialistas
para definir a aplicao de marketing com o auxlio de Data Warehouses. A integrao
a palavra-chave neste processo, para que se tire proveito das informaes j
existentes sobre clientes, utilizadas para uma realimentao eficiente do banco de
dados de relacionamento.
O Data Warehouse, para ser usado por ferramentas de Database Marketing, deve
transformar todo o histrico de relacionamento entre clientes e fornecedores, contido na
base de dados operacional, em transformaes segmentadas sobre o pblico da empresa,
pois no podemos nos relacionar com quem ns no conhecemos.
47
Captulo 4: Modelagem de Dados Para Data Warehouses
4
C A P T U L O
Modelagem de Dados
Para Data Warehouses
48
Por que No Usar o Modelo
Entidade e Relacionamento Tradicional?
Como vimos no Captulo 3, em 1993, o Dr. E.F. (Ted) Codd criou o termo Online Ana-
lytical Processing (OLAP) em um ensaio intitulado Providing OLAP (Online Analytical
Processing) to User-Analysts: An IT Mandate. At a publicao do ensaio de 1993 do Dr.
Codd, os projetistas de banco de dados tentavam encontrar uma maneira mais eficaz de
estruturar tabelas, de forma a garantir uma redundncia muito baixa. As regras de
normalizao de Codd orientavam o projetista a criar uma estrutura lgica de tabelas
sem qualquer redundncia.
Em 1976, Peter Chen introduziu o famoso Diagrama Entidade e Relacionamento (DER),
que foi refinado por pesquisadores posteriormente. No contexto dos bancos de dados
relacionais, o DER foi o responsvel pela melhora fenomenal na velocidade de
processamento das aplicaes transacionais a partir de 1980. O segredo dessa modelagem
remover qualquer redundncia dos dados, pois em havendo qualquer insero, alterao
ou excluso de dados ser preciso uma atuao em apenas um ponto do banco de dados.
Quando definimos um Modelo Entidade e Relacionamento (modelo conceitual) de um
sistema para projetar seu banco de dados, buscamos representar grfica (DER) e
textualmente as estruturas, operadores e regras que definem os dados. Os princpios
bsicos so identificar os itens relevantes, geradores de informao para o processamento
do sistema (objetivos), identificar a manipulao dessas informaes (entradas e sadas)
e identificar as regras que regem o surgimento das informaes (restries). Ao
desenharmos um DER (principal componente do Modelo Entidade e Relacionamento)
criamos uma abstrao dos dados e representamo-la graficamente.
Essa modelagem eficiente para as aplicaes transacionais, onde os dados so acessados
individualmente, mas quando se trata das complexas consultas do mundo dos negcios,
esse modelo falha.
Nesse modelo, os dados so divididos em vrias entidades distintas (retngulos) e cada
entidade transformada em uma tabela (vide Figura 4.1). Essa caracterstica gera alguns
problemas que fazem o diagrama ficar complexo e de difcil visualizao e memorizao,
tanto pelo usurio final quanto pelos projetistas.
49
Figura 4.1: Parte de um Diagrama Entidade e Relacionamento (DER)
de um Sistema de Vendas para Restaurantes.
Devido ao grande nmero de tabelas, fica impraticvel realizar consultas complexas, j
que preciso fazer um grande nmero de conexes entre as mesmas. Outro grande
problema a simetria do modelo, pois as tabelas so muito parecidas, muitas vezes no
so povoadas e possivelmente poder haver diferentes respostas para consultas com
objetivos idnticos, elaboradas sem o total conhecimento da semntica do modelo. No
possvel distinguir quais as tabelas mais importantes ou dominantes no modelo (simetria).
Alm desses problemas, esse modelo no foi projetado para armazenar dados histricos.
Constantemente h atualizao na base de dados e informaes histricas so perdidas.
Na projeo de bases de dados para Data Warehouses, deve-se quebrar o paradigma da
eliminao de redundncias em um modelo de dados (normalizao) e buscar armazenamento
histrico. Desnormalizando algumas tabelas, o projetista do DW busca ganhar desempenho
nas consultas. Contudo, no se deve introduzir redundncia em qualquer lugar do modelo. A
redundncia sempre traz um preo a ser pago, seja o custo de armazenamento em disco ou o
custo da manuteno de um esquema de atualizao em paralelo.
Star Schema (Esquema Estrela)
Sendo rigorosamente fiis aos conceitos de bancos de dados, no chamaremos o esquema
estrela de modelo, pois o mesmo apenas uma forma de dispor as tabelas do modelo
relacional para a simulao de um banco de dados multidimensional.
50
O conceito Star Schema foi criado pelo Dr. Ralph Kimball e tem como caracterstica
bsica a presena de dados altamente redundantes para se obter um melhor desempenho.
Essa desnormalizao ocorre devido a junes de tabelas para que no haja necessidade
de ocorrerem estas junes em tempo de execuo.
O nome Star Schema foi adotado pela semelhana com uma estrela. Este esquema
composto de um tabela dominante, chamada tabela de fatos, no centro, rodeada por
tabelas auxiliares, chamadas de tabelas de dimenso. A tabela de fatos conecta-se s
demais por mltiplas junes e as tabelas de dimenses se conectam com apenas uma
juno tabela de fatos (vide Figura 4.2).
Figura 4.2: Exemplo de Esquema Estrela
Neste esquema a consulta ocorre inicialmente nas tabelas de dimenso e depois na tabela
de fatos, assegurando assim a preciso dos dados atravs de uma estrutura completa de
chaves onde no preciso percorrer todas as tabelas. Isso garante um acesso mais eficiente
e o mais alto desempenho possvel.
As tabelas dimensionais so desnormalizadas para aumentar o desempenho e armazenam
as informaes a respeito das dimenses dos dados. Cada coluna dever conter descries
textuais significativas para os usurios e devero ser apropriadas para relatrios.
Dimenso Tempo
Id_Tempo
Dia
Ms
Ano
Dia_Semana
Feriado
Semestre
Trimestre
Fatos Vendas
Id_Tempo
Id_Produto
Id_Funcionrio
Unid_Vendida
Valor_Vendas
Dimenso Produto
Id_Produto
Descrio
Tipo
Preo
Dimenso Funcionrio
Id_Funcionrio
Nome
Endereo
Telefone
RG
CPF
51
Figura 4.3: Exemplo de tabela de dimenso.
A tabela de fatos armazena grande quantidade (tabelas de dimenso so menores) de
dados histricos (normalmente numricos) em funo do tempo, obtidos a partir da
interseco de todas as dimenses da estrela. Cada dimenso tem uma chave primria
7
que corresponde a um dos campos da chave da tabela de fatos. A dimenso tempo
sempre integrante da chave primria e na tabela de fatos onde armazenamos os
indicadores de desempenho (medidas) do negcio.
Figura 4.4: Exemplo de tabela de fatos.
Ao contrrio do modelo entidade e relacionamento tradicional, o esquema estrela
assimtrico, pois podemos perceber nitidamente a tabela de fatos como dominante. Alm
disso, este esquema flexvel para suportar a incluso de novos elementos de dados,
bem como mudanas que ocorram no projeto. Essa flexibilidade se d na medida em que
todas as tabelas de fatos e dimenses podem ser alteradas simplesmente acrescentando
novas colunas s mesmas e nenhuma ferramenta de consulta ou relatrio precisa ser
alterada de forma a acomodar essas mudanas.
7
Chave primria qualquer subconjunto de campos que identifica univocamente uma linha da tabela. Por
exemplo, o campo CPF em uma tabela de clientes um candidato a chave primria.
52
Tipos de Dimenso
As dimenses em um esquema estrela representam entidades que evoluem ao longo do
tempo. A descrio e a formulao de produtos evoluem, pessoas modificam seus nomes,
casam-se e divorciam-se, aumentam o nmero de filhos e trocam de endereo, etc. Assim,
deve-se decidir o que fazer quando estas mudanas ocorrem.
Se quisermos acrescentar estas modificaes tabela de fatos ou criarmos dependncias
entre a dimenso tempo e as demais dimenses, estaremos retornando a uma estrutura
altamente relacionada e perderemos desempenho. Como a maioria das dimenses
constante ao longo do tempo, podemos optar por trs formas de tratamento destas
modificaes como veremos a seguir.
Dimenso Tipo 1
Quando o histrico no relevante, substitumos valores antigos dos registros da
dimenso e, portanto, perdemos a capacidade de rastrear o histrico passado.
Exemplificando, suponhamos que o funcionrio Joaquim tenham casado; simplesmente
substitumos o valor contido no campo Estado Civil do registro de Joaquim por
Casado. No necessrio fazer outras modificaes no registro da dimenso, e
nenhuma chave do banco de dados ser alterada.
Dimenso Tipo 2
Adicionamos um registro dimenso contendo os novos valores do atributo no momento
da mudana, com o intuito de segmentar o histrico entre a descrio antiga e a nova
descrio. Chaves artificiais so de extrema importncia neste caso (vide seo Chaves
Artificiais). Vejamos o exemplo do produto cocktail em uma cadeia de restaurantes.
Para o cocktail, imaginaremos que o registro da dimenso produto represente um
determinado cdigo nico. A partir de algum ponto no tempo, digamos 20 de maro de
2000, a formulao do contedo do cocktail muda de com lcool para sem lcool,
refletindo uma alterao significativa nos ingredientes da bebida. No segmento dos
restaurantes essa situao ocorre com freqncia e rotineiramente criado um novo
cdigo nico para descrever o produto alterado. Nesse contexto, notamos que o cdigo
nada mais que uma chave lgica, mantida pelo fabricante da bebida.
53
Quando observamos o banco de dados de vendas do restaurante, no notamos uma diviso
do histrico. O antigo cocktail continuar a ser vendido no restaurante aps 20 de maro
de 2000, at o final do estoque. Isso variar de restaurante para restaurante. Os novos
cocktails sero comercializados a partir de 20 de maro de 2000 e gradualmente
substituiro os antigos. Haver um perodo de transio em que os dois tipos de cocktail
sero vendidos nos restaurantes. Os caixas reconhecero os dois cdigos e no encontraro
dificuldades em manipular a venda de cada uma das bebidas. Assim, o uso de registros
separados na dimenso divide a tabela de fatos automaticamente e o usurio no precisa
preocupar-se com as duas formulaes do cocktail, a menos que esteja usando o campo
Contedo de lcool.
Como o histrico dividido no poderemos usar o novo valor de um atributo no histrico
antigo, ou vice-versa. Se criarmos a restrio em uma consulta Contedo de lcool =
Nenhum, no veremos nenhum cocktail antes de 20 de maro de 2000. De modo geral
o que desejamos. Raramente queremos saber qual seria o histrico caso a alterao no
tivesse ocorrido. Observe na Figura 4.5 que criado um novo Id Produto (chave artifi-
cial) e so atualizadas as datas de incio e fim de validade do registro.
Figura 4.5: Dimenso Tipo 2.
Dimenso Tipo 3
Se quisermos usar um novo valor de atributo para consulta em um histrico antigo, criamos
novos campos atuais no registro original da dimenso para incluir os novos valores,
mantendo tambm seus valores originais. Desta forma, permitimos a descrio do histrico
anterior e o posterior mudana tanto em relao aos valores originais do atributo quanto
aos valores atuais. Em anlises de vendas, quando um mercado muda, inicialmente
sempre vivel rastrear tanto os valores antigos como os modificados do mercado ao
longo do tempo. No criamos um novo registro, mas adicionamos um campo no atributo
modificado do mercado. No caso de uma mudana de estado civil, por exemplo,
54
adicionamos um novo campo denominado Estado Civil Atual e provavelmente
mudaremos o nome do campo Estado Civil Antigo para Estado Civil Original.
Adicionamos tambm um campo Data de Incio do Estado Civil. Sempre que houver
uma modificao do Estado Civil substitumos o valor do campo Estado Civil Atual
e mudaremos a Data de Incio. Nunca modificamos o Estado Civil Original. Dessa
forma, podemos rastrear todo o histrico relativo ao campo Estado Civil Original como
o campo Estado Civil Atual. Como a tabela de fatos considerada apenas um valor de
chave, a nica forma para dividir o histrico com base na modificao ser por meio do
campo Data de Incio.
A dimenso de tipo 3 no pode ser utilizada para descrever com preciso modificaes
como o exemplo da bebida cocktail. impossvel saber com preciso quantos restaurantes
esgotaram o estoque dos cocktails antigos. Isso ocorre comumente quando o fabricante
muda a formulao de um produto, mas no cria um novo cdigo nico. Nesse caso, os
relatrios de vendas obtidos por meio do campo no tm como distinguir as formulaes.
Com o tipo 3 podemos manipular apenas o valor original e o atual do atributo modificado.
Os valores intermedirios so perdidos. Caso haja necessidade de dividir o histrico com
preciso, deve-se optar pelo tipo 2 e toda a gama de modificaes poder ser rastreada. No
vivel combinar os tipos 2 e 3, pois isso resultar em um aumento da complexidade das
aplicaes. O tipo 3 tambm aumenta a complexidade e s deve ser utilizado em casos de
necessidade extrema, pois, em muitos casos, nomes de atributos anteriores so geralmente
esquecidos e abandonam-se as comparaes com valores originais do mercado.
Pequenas Dimenses Para
Auxlio de Dimenses Grandes
Para aumentar o desempenho de pesquisas e restries, podemos acrescentar ao modelo
dimenses pequenas que auxiliaro no registro de modificaes de dimenses
relativamente grandes como a de clientes, por exemplo. O objetivo no penalizar a
consulta na tabela de fatos utilizando uma grande e cara dimenso.
Transferimos para a pequena dimenso os atributos que se modificam ao longo do tempo
e cujos valores precisam ser rastreados. Exemplificando (vide Figura 4.6), se quisermos
segmentar clientes pelo nvel salarial e escolaridade, colocamos na pequena dimenso
todas as combinaes possveis de nveis salariais e escolaridade; desta forma, quando
ocorrer uma modificao do perfil de um cliente, bastar mudarmos para uma chave de
55
Instruo (pequena dimenso) diferente, medida que carregamos os registros da tabela
de fatos em perodos regulares. No precisamos criar um novo registro na dimenso
cliente porque a pequena dimenso contm todos os perfis salariais de que necessitamos.
Incluindo a chave de Instruo na tabela cliente, seria necessrio criar um novo registro
cliente para rastrear a correspondncia entre as instrues modif icadas. No
recomendamos isso, pois o ideal substituir a chave Instruo nos novos fatos sempre
que houver uma modificao. Dessa forma, podemos pesquisar o perfil salarial atual
juntamente com os outros atributos do cliente a qualquer momento. O histrico passado
de perfis pode ser construdo sempre que necessrio, consultando-se a tabela de fatos e
selecionando o Id do cliente e sua chave Instruo, que de modo geral ser diferente
da chave instruo atual.
Figura 4.6: Estrela com pequena dimenso.
Dimenses Descaracterizadas
Chamamos de dimenses descaracterizadas chaves de dimenso sem uma tabela de
dimenso correspondente. Podemos ter nmeros de controle, como por exemplo nmeros
de notas fiscais e/ou pedidos representados como dimenses descaracterizadas. Migramos
o nmero do pedido ou nota fiscal para a tabela de fatos e cada linha desta tabela ir
representar o documento propriamente dito ou uma linha de item do documento (vide
Figura 4.7).
Fatos Vendas
Id_Tempo
Id_Instruo
Id_Cliente
Unid_Vendida
Valor_Vendas
Dimenso Instruo
Id_Instruo
Nvel_Salarial
Escolaridade
Dimenso Cliente
Id_Cliente
Nome
Endereo
Telefone
RG
CPF
56
Figura 4.7: Dimenso Descaracterizada Pedido.
Chaves Artificiais
Quando projetamos um DW no podemos cometer o erro de utilizar a mesma chave
significativa utilizada no sistema fonte para as dimenses. Quando utilizamos a mesma
chave, reduzimos a flexibilidade do esquema, diminumos o desempenho e aumentamos
o trabalho de manuteno.
Ao utilizarmos chaves artificiais (Ids nos exemplos deste livro) geradas que no possuam
relao significativa com os dados que descrevem, ganhamos flexibilidade e um melhor
desempenho do Data Warehouse.
As diferenas entre chaves significativas e chaves no significativas existem em diversos
nveis. Atravs da normalizao de dados em sistemas fontes transacionais, as chaves
significativas, tambm chamadas de lgicas, so freqentemente representadas por mais
de uma coluna, dependendo do nvel de sumarizao que representam. Todavia, as chaves
artificiais so sempre uma nica coluna por dimenso. A utilizao de chaves artificiais
em vez de chaves lgicas traz diversas vantagens, tais como:
Se surgirem novos nveis de sumarizao, a estrutura fsica das tabelas que
compartilham da chave artificial no se modifica, s muda o contedo das chaves e o
nmero de linhas.
Uma reduo no tamanho da chave primria indexada, aumentando o desempenho
(vide Captulo 8).
Facilidade no armazenamento de histrico em dimenses do tipo 2, pois quando
uma atualizao feita no registro de uma dimenso, uma nova chave gerada com
os novos dados e a anterior permanece fazendo referncia ao valor histrico. Por
57
exemplo, na mudana do Estado Civil de um cliente, so armazenados os dados da
poca de solteiro e o registro atual de casado. Isso mantm um histrico total da
vida do cliente.
Devemos ignorar as chaves lgicas e gerar nmeros inteiros seqenciais, ou seja, as
colunas que formam a chave lgica permanecem e acrescentamos um seqencial que
ser a chave artificial da tabela (vide tabela da Figura 4.8 como exemplo).
Figura 4.8: Tabela com estrutura de chaves geradas pelo sistema.
Dimenso Tempo
A princpio, um projetista de DW pode questionar se realmente necessrio criar uma
tabela de dimenso tempo. O questionamento baseia-se na pergunta: Se eu coloco uma
data na minha tabela de fatos, no posso extrair qualquer informao relativa ao tempo
atravs do banco de dados?.
Com a dimenso tempo procuramos armazenar descries que no podemos extrair
utilizando funes nativas dos bancos de dados. Um banco de dados, por exemplo, no
pode informar-nos se em um determinado dia era feriado ou no (vide Figura 4.9).
Alm disso, o armazenamento de descritivos na dimenso tempo aumenta o desempenho
das consultas, pois no h necessidade do uso de funes do banco de dados para gerar
estas descries.
58
Figura 4.9: Exemplo de dimenso tempo.
A dimenso tempo tambm pode descrever perodos fiscais, temporadas e etc.
Hierarquias
Como ferramentas OLAP suportam que as hierarquias sejam representadas em uma nica
tabela de dimenso, vivel adotar esta soluo. Para o exemplo de produtos, podemos
ter registros em nveis mais altos de granularidade (grupo), ou seja, com alguns campos
nulos, e registros nos nvel mais baixo (produto) com todos os campos preenchidos.
Vejamos o exemplo da Figura 4.10:
Figura 4.10: Exemplo de dimenso com hierarquia.
Alguns projetistas optam por criar tabelas de dimenso derivadas para representar cada nvel
hierrquico como uma tabela fsica diferente no banco de dados. Isto pode ser interessante
quando membros da hierarquia possuem propriedades relevantes e quando anlises realizam
consultas diretas por valores destes membros. A tabela de dimenso principal permanece
inalterada, mantendo a hierarquia completa, criando-se tabelas derivadas (tipo, por exemplo)
para facilitar agrupamentos por valores de membros especficos. Supondo que haja necessidade
de recuperar os totais de vendas de massas verdes, haver inicialmente uma filtragem na
tabela de tipos (tabela normalizada menor redundncia) e depois a busca na tabela de fatos,
j que o Id da tabela derivada tambm migrado para a mesma.
59
No costumamos usar esta abordagem, pois ela aumenta o nmero de tabelas no esquema.
Agregados
Em um DW, chamamos de granularidade o nvel de detalhe das tabelas. Quanto maior o
nvel de detalhe, menor a granularidade.
A agregao o processo de resumir dados granulares ou detalhados e de armazenar
fisicamente as agregaes na tabela de fatos ao longo de uma hierarquia. Toda sumarizao
uma redundncia por excelncia, porm a agregao de dados detalhados
antecipadamente diminui os tempos de acesso e acelera processos como o de procura.
Ainda utilizando exemplo dos produtos (Figura 4.11), podemos ter uma tabela de fatos
que armazena os dados em nvel de granularidade de produto e uma tabela de fatos
agregada que armazena dados em nvel de grupo. Isto vivel se muitas consultas so
feitas por totais de Grupo. Neste caso, as somas dos valores das vendas por grupo j vo
estar prontas, agilizando assim estas consultas.
Figura 4.11: Estrela com agregado.
Em casos muito crticos, podemos optar por acrescentar o campo grupo na tabela com
menor granularidade com intuito de otimizar o desempenho da agregao por grupo.
Isto comum em casos com dimenses descaracterizadas. Se tivermos notas ficais como
60
sendo integrantes de um pedido, podemos construir uma tabela de fatos de notas fiscais,
acrescentando o nmero do pedido, e uma tabela agregada de pedidos que ir servir para
comparar o que foi pedido (total) e o que foi realmente vendido.
A gerao de muitas agregaes pode resultar em uma exploso do tamanho do Data
Warehouse. Por este motivo, muitas ferramentas OLAP incorporam uma tecnologia de
agregao que resolve de modo eficiente as questes quanto determinao de quando
recuperar um valor agregado armazenado ou quando recuperar o dado de detalhe e realizar
uma agregao on-line (no momento da consulta).
Tipos de Indicadores Para as Tabelas de Fatos
Indicadores em uma tabela de fatos podem ser:
Aditivos: podem ser adicionados ao longo das dimenses como o nmero de unidades
vendidas, por exemplo.
Semi-Aditivos: podem ser adicionados ao longo de algumas dimenses. Podemos citar
como exemplos nveis de estoque e medies de intensidade como temperatura. No
faz sentindo somar temperaturas, porm faz sentido calcular uma mdia.
No-aditivos: no podem ser somados de forma alguma. So exemplos: tipo de
vendedor ou tipo de cliente. Um fato como esse usado na realizao de contagens
para resumo de registros ou para anlise um a um dos registros do fato. Se
acrescentarmos a uma tabela de fatos o indicador total de vendas at o momento, no
podemos somar estes valores ao longo dos dias.
Um Estudo de Caso Para Definio
dos Passos da Modelagem Dimensional
Suponhamos que temos uma rede de restaurantes composta de 50 filiais localizadas em
vrios estados. Cada filial oferece mais de 1000 produtos diferentes entre bebidas e
pratos. A direo do restaurante pretende analisar as vendas, custos e lucros. Festivais
(promoes) so utilizados para atrair clientes e potencializar as vendas.
Para projetar estrelas com intuito de gerar informaes gerenciais, o engenheiro de soft-
ware deve identificar qual subconjunto do modelo de negcio ser usado. No Captulo 7
apresentamos uma metodologia para especificao de requisitos de um DW.
61
Neste caso especfico, optaremos por verificar o movimento dirio de cada produto. O
objetivo verificar os produtos vendidos, preos e filiais que efetuaram a venda ao
longo do tempo.
Depois de definida a parte do modelo de negcio a ser analisada, devemos decidir qual
granularidade ser usada para a parte escolhida. No nosso caso poderamos analisar os dados
em nvel de nota fiscal e verificar o movimento dirio e/ou mensal dos produtos por filial.
Figura 4.12: Estrela Vendas de uma rede de restaurantes.
62
O terceiro passo definir as dimenses que participaram da estrela. Quando escolhemos
o nvel de granularidade da tabela de fatos, dimenses podem surgir naturalmente. Ao
escolher uma dimenso vivel verificar se todas podem ser relacionadas ao nvel de
granularidade escolhido sem gerar duplicaes e se as dimenses correspondem ao que
foi quantificado na tabela de fatos.
Por fim, escolhemos os fatos mensurveis que iro popular cada registro da tabela de
fatos. No nosso exemplo, podemos ter como indicadores para a tabela de fatos o total de
vendas, unidades vendidas, total do custo, etc.
A Figura 4.12 representa uma estrela para responder aos questionamentos diretivos da
rede de restaurantes.
Dvidas Comuns de Projetistas de DW
Qual a granularidade que devo adotar? Na dvida, escolha sempre o nvel de
detalhamento menor. Desta forma, a tabela de fatos pode ser facilmente estendida
pela adio de novos fatos, novos atributos de dimenso ou adio de nova dimenso
completa. Seu esquema no ficar limitado e no haver arrependimento futuro.
Quantas dimenses meu esquema pode ter no mximo? Geralmente temos de 4 a 15
dimenses. Esquemas com mais de 20 dimenses aparentam ter dimenses que
poderiam ser combinadas a outras, eliminando-as.
Posso acrescentar novos indicadores na tabela de fatos? Sem problemas, desde que
os mesmos correspondam s dimenses do esquema.
Em que momento atualizar uma dimenso do tipo 2? Se ao carregar os fatos tambm
so carregadas as novas alteraes da tabela de dimenses, no h problema algum,
ou seja, podemos tranqilamente s atualizar as dimenses na hora da carga dos fatos
que normalmente diria. O contrrio que no pode, pois sero geradas
inconsistncias temporais.
Em dimenses do tipo 2. Como verificar se um registro de dimenso sofreu alterao
e necessita de um novo registro que atenda a nova verso, preservando o antigo para
efeitos histricos? Devemos ter uma chave lgica eleita que servir de base para a
comparao das mudanas: matrcula do funcionrio, por exemplo. Comeamos a
carga pelas dimenses e depois carregamos os fatos. Se houver problema em qualquer
dimenso de uma estrela, a carga deve ser abortada.
63
Como armazenar fatos de um produto que no est em promoo? Criamos um registro
na dimenso Promoo com o valor descritivo Sem promoo;
Se s armazeno produtos que foram vendidos, como recuperar informaes de produtos
que estavam em promoo e no foram vendidos? Podemos preencher a tabela de
fatos com zeros para este caso, porm vamos expandi-la enormemente. A recuperao
pode ser feita atravs da diferena da lista de produtos em promoo no dia e a lista de
produtos vendidos.
Posso ter mais de uma tabela de fatos em um mesmo esquema estrela? Claro. Podemos
ter tabelas de fatos que se relacionam com as mesmas dimenses e possuem uma
semntica diferente. Em um esquema para anlise de vendas, pode existir uma tabela
de fatos para as vendas concretizadas e outra idntica para as vendas previstas;
Se um produto pertence a mais de um grupo e um grupo pode ter mais de um produto,
como representar esta dimenso no esquema estrela? Basta criar uma dimenso
derivada Grupo que ter um relacionamento de muitos para muitos com a dimenso
Produto. Como resultado, teremos uma tabela de fatos Grupo X Produto. Esta
tabela conter os IDs do grupo e de produto. Podemos aplicar esta soluo em
qualquer caso semelhante.
Como identificar dimenses? Dimenses podem corresponder a um atributo de uma
entidade, a uma entidade com todos ou alguns atributos, ou a entidades relacionadas
com todos ou alguns de seus atributos. As dimenses so identificadas nas perguntas
feitas pela rea diretiva. Uma dimenso um participante de um fato explicitamente
indicado na pergunta, no evolui com freqncia e no possui indicadores analticos
associados. Na pergunta: Qual o desempenho das filiais em cada estado?,
identificamos a necessidade de anlise por filial e por estado. As dimenses respondem
a perguntas do tipo O que? (sofre a ao venda de um Produto), Quem? (agente
associado venda por um funcionrio), Onde? (local venda na filial x) e Quando?
(tempo vendas mensais ou dirias).
Como identificar fatos? Tambm identificamos fatos na perguntas: Qual o desempenho
das filiais em cada estado?. Geralmente numricos, os fatos so evolutivos, mudando
seus valores com freqncia.
Como os DERs dos sistemas fontes podem direcionar o projeto de um esquema estrela?
Podemos acompanhar as seguintes dicas:
64
Relacionamentos de um para muitos podem indicar a presena de uma dimenso.
Relacionamentos de muitos para muitos possuem tabelas intermedirias, e estas
podem conter valores nmericos que indicam fatos.
Entidades para representar documentos como Nota Fiscal e Pedido podem indicar
fatos e dimenses descaracterizadas.
Geralmente as entidades fortes indicam dimenses.
A minha ferramenta OLAP no possui suporte intuitivo para executar contagem de
registros na tabela de fatos, como posso contar os registros facilmente? Acrescentando
um campo numrico tabela de fatos que conter sempre o valor 1. Para contar os
registros, basta somar este campo.
Resumo
Em 1993, o Dr. E.F. (Ted) Codd criou o termo Online Analytical Processing (OLAP) em
um ensaio intitulado Providing OLAP (Online Analytical Processing) to User-Analysts:
An IT Mandate. At a publicao do ensaio de 1993 do Dr. Codd os projetistas de banco
de dados tentavam encontrar uma maneira mais eficaz de estruturar tabelas, de forma a
garantir uma redundncia muito baixa. As regras de normalizao de Codd orientavam o
projetista a criar uma estrutura lgica de tabelas sem qualquer redundncia. No entanto,
devido a questes de desempenho, abria-se espao para a introduo de dados duplicados
para garantir um acesso mais rpido.
Contudo, o projetista de dados de DW no deve introduzir redundncia em qualquer
lugar do modelo. A redundncia sempre traz um preo a ser pago, seja o custo de
armazenamento em disco ou o custo da manuteno de um esquema de atualizao
em paralelo.
Aceitando-se, ento, a introduo de redundncia ao modelo de dados, chegamos tcnica
de projeto em esquema estrela (Star Schema).
A tcnica Star Schema foi concebida pelo Dr. Ralph Kimball como uma forma alternativa
de projeto de dados para aplicaes de DW. O nome estrela (Star) devido forma de
projeto, onde uma grande tabela de fatos reside no centro do modelo, rodeada por vrios
pontos, ou tabelas de referncia.
65
O princpio bsico por trs do Star Schema a introduo de dados altamente redundantes
por questes de desempenho. O Dr. Kimball descreve as desnormalizaes como pr-
junes de tabelas, de forma que as aplicaes no precisem fazer a juno das tabelas
em tempo de execuo. No centro do Star Schema, a tabela de fatos normalmente
composta de chaves e dados puros. Uma tabela de fatos , geralmente, muito extensa e
contm milhes de linhas.
67
Captulo 5: Gerncia de Metadados em um Data Warehouse
5
C A P T U L O
Gerncia de Metadados
em um Data Warehouse
68
Metadados em um Processo
de Data Warehousing
8
Os metadados so definidos como dados sobre dados, porm a complexidade desses dados
no Data Warehouse aumenta muito. Num sistema OLTP geram-se documentos somente
sobre o levantamento dos dados, banco de dados e o sistema que alimenta o mesmo. No
Data Warehouse, alm do banco, gera-se uma documentao muito maior. Alm de descrever
sobre o levantamento de dados e o banco, temos ainda o levantamento dos relatrios a
serem gerados, de onde vm os dados para alimentar o DW, processos de extrao, tratamento
e rotinas de carga dos dados. Ainda podem ser gerados metadados sobre as regras de negcio
da empresa e todas as mudanas que elas podem ter sofrido, e tambm a freqncia de
acesso aos dados. Os metadados englobam o DW e mantm as informaes sobre localizao
dos dados (Figura 5.1). So exemplos de metadados para um DW:
A estrutura dos dados segundo a viso do programador.
A estrutura dos dados segundo a viso dos analistas de negcio.
A fonte de dados que alimenta o DW.
A transformao sofrida pelos dados no momento de sua migrao para o DW.
O modelo de dados.
O relacionamento entre o modelo de dados e o DW.
O histrico das extraes de dados.
Acrescentamos ainda os dados referentes aos relatrios que so gerados pelas ferramentas
OLAP, assim como os que so gerados nas camadas semnticas.
Os metadados podem surgir de vrios locais durante o decorrer do projeto. Eles provm
de repositrios de ferramentas de modelagem, os quais geralmente j esto estruturados,
facilitando a integrao da origem dos metadados e um repositrio dos mesmos. Essa
fonte de metadados riqussima. Outros dados que devem ser considerados metadados
so os materiais que surgiro das entrevistas com os usurios. Destas entrevistas podem
obter-se informaes preciosas que no esto documentadas em nenhum outro lugar
alm de regras para validao dos dados depois de carregados no Data Warehouse.
8
Chamamos de Data Warehousing (Dwing) a soluo completa desde a coleta dos dados at a sua
transformao em informao.
69
Figura 5.1: Abragncia dos Metadados em um processo de DWing.
As pesquisas na rea de metadados para DW esto aumentando em funo da necessidade
extrema das organizaes de conhecer melhor os dados que elas mantm, e tambm
conhecer com mais detalhes os dados de outras organizaes, atravs de intranets e
extranets. Sem uma documentao eficiente dos dados, dificultada aos usurios a
localizao de dados necessrios para suas aplicaes. Tambm, os dados ficam sujeitos
superposio de esforos de coleta e manuteno, e vulnerveis a problemas de
inconsistncias. O no uso ou uso imprprio da informao ser altssimo.
Dentro do contexto de DW podemos dividir os metadados em duas categorias bsicas:
metadados tcnicos e metadados de negcio.
Metadados tcnicos provem conf iabilidade na acuracidade do DW para os
desenvolvedores. Descrevem os dados necessrios pelas vrias ferramentas utilizadas
para armazenar, manipular ou movimentar dados. So altamente estruturados e geralmente
tratados via uma ferramenta de repositrio. Adicionalmente, os metadados tcnicos
70
suportam a manuteno do DW permitindo sobretudo fcil escalabilidade ao mesmo.
Temos como exemplos de metadados tcnicos:
Controles de Auditoria.
Nomes das tabelas do DW (em caso de DW relacional).
Metadados de negcio perfazem a juno entre o mundo codificado de um DW e o mundo
do usurio de negcios. Este tipo de metadado permite facilitar a utilizao do DW pelos
usurios, auxiliando-os em suas consultas ad hoc. So tanto no-estruturados quanto
estruturados, tornando-se difceis de serem tratados e integrados por uma ferramenta
estruturada tipo repositrio. Podemos citar como exemplos de metadados de negcio:
Mapeamento dos campos das tabelas de um DW relacional para atributos conceituais.
Regras para operaes de DW drill-down, drill-up e drill-across, conhecidas como
operaes OLAP.
Informaes sobre sumrios e transformaes de dados.
Nomenclaturas para os dados que possam ser facilmente entendidas pelos analistas de
negcios ou executivos.
Existem diversos problemas a serem enfrentados com o uso e gerncia de metadados em
ambientes de DW. Em primeiro lugar, necessrio delimitar o escopo de atuao, pois a
deciso de quais metadados devem ser coletados e mantidos complexa. Os principais
problemas pertinentes gerncia de metadados esto relacionados com:
Redundncia: diversas ferramentas de um ambiente de DW ainda armazenam seus
prprios metadados em formato proprietrio.
Sries histricas: o conceito de um dado pode evoluir, ou o ramo estratgico do negcio
pode mudar completamente.
Falta de estruturao de alguns metadados: aquisio e transferncia de metadados
de negcios no-estruturados que contextualizam eventos externos e internos empresa,
os quais provocam discrepncias nas informaes estratgicas. Residem em agendas
particulares, e-mails, mdias alternativas, imagens e etc.
Solues particulares: em se tratando de metadados de negcios, no existe uma
soluo nica.
71
Suporte a usurios de diferentes perfis: diferentes comunidades iro propor, projetar e
ser responsveis por diferentes tipos de metadados.
Criao de novos conjuntos de metadados (evoluo do DW).
Interoperabilidade de diferentes sistemas.
Metadados Operacionais
Os metadados operacionais fazem parte do conjunto de metadados tcnicos de um
processo de Data Warehousing. Estes metadados exercem uma influncia no ambiente
de entrada de um Data Warehouse, determinam a aceitabilidade dos dados que so
transmitidos para o Data Warehouse e controlam o processo pelo qual a transmisso
feita. fundamental para a natureza de um ambiente de Data Warehouse que o escopo
do sistema esteja em constante fluxo. Mudanas em relao a negcios, novas telas,
ferramentas de anlise oferecendo novas maneiras de anlise de dados, e a consistncia
e completeza oferecidas por um Data Warehouse podem significar benefcios que iro
contribuir para uma constante evoluo.
Os metadados operacionais, para suportarem essa constante evoluo do Data Ware-
house, devem possuir um conjunto de classes mnimas tais como:
Aplicao: Define qualquer sistema que atue como fonte de dados.
Fluxo dos dados: Define a relao de fluxo do comeo ao fim, para um segmento de
trabalho independente, dentro do carregamento de um Data Warehouse.
Ordem de Transferncia: Uma subdiviso do Fluxo de Dados, permitindo ao
desenvolvedor entender como a transferncia vai funcionar, a ordem em que as tarefas
sero executadas, e sob quais circunstncias ela poder dar certo.
Transformao: uma atividade que, no nvel de Ordem de Transferncia, muda a
estrutura ou contedo de alguma parte do dado que est sendo transferido.
Classes Fonte: Definem os objetos que existem dentro da aplicao de origem e que
so acessados para procurar os dados que sero transferidos para o Data Warehouse.
Aributos Fonte: Atributos individuais que so usados como dados de origem nas
Classes Fonte.
Classe Destino: Prov uma definio para cada classe dentro do ambiente de DW.
72
Atributo Destino: Prov uma definio em nvel de atributo para cada item do dado.
Armazenamento Fsico: Fonte atual, intermediria e os objetos de destino usados na
transferncia.
Regras: Definem as regras que esto alocadas em cada item do dado (geralmente em
nvel de atributo) enquanto passa pelo ambiente de Data Warehouse, possivelmente
fazendo a validao, medio, dependncias complexas com outros atributos,
dependncias com data e hora, e outros efeitos externos.
Dependncias: Dependncias existentes na Ordem de Transferncia adicionando
sofisticao para o conceito de fluxo de trabalho, permitindo ao desenvolvedor definir
a ordem de cada passo. Na verdade uma implementao mais moderna dessa
caracterstica seria possvel com uma ferramenta de gerenciamento de projetos. Vale
tambm considerar que a ferramenta ETL ir permitir a gravao e o controle desses
modelos de trabalho.
Os elementos citados acima so basicamente estticos. Eles no so afetados pelo banco
de dados ou por outras influncias externas. Muitas companhias oferecem ferramentas
que possam aumentar a capacidade de gerenciar metadados operacionais. Em alguns
casos, as ferramentas combinam gerenciamento de metadado tcnico com a capacidade
de uma ETL, definindo sua Staging Area como seu escopo.
Esses tipos de ferramentas confiam muito na captura e no gerenciamento dos metadados.
Elas so vendidas como eficientes mecanismos para desenvolvimento e controle de
seqncias ETL, mas so na verdade avanos significativos na rea de gerenciamento de
metadados automativos. Em alguns casos, modelos de metadados bsicos tm sido
estendidos para incluso de caractersticas dinmicas que provm informaes como
volume de dados, volatilidade, tempo de carga e marcadores para transferncia de dados.
Estticos ou dinmicos, os metadados que controlam a extrao, transformao e
carregamento dos dados devem idealmente ser capturados por uma interface grfica,
permitindo ao desenvolvedor ver o dado sendo carregado a partir de um diagrama, criando
tarefas independentes, identificando e escolhendo a partir dos menus os campos de dados
de origem. Por outro lado, sem um robusto modelo de metadados, impossvel controlar
a carga, no importando o nvel de modernidade que o front-end de uma ferramenta ETL
possa oferecer.
73
Metadados de Negcio
Os metadados de negcio englobam informaes requeridas pelos usurios finais para
balano e sobre como usar o contedo de um Data Warehouse para suprir suas
necessidades. Essencialmente, metadados de negcio asseguram que cada usurio tenha
um ambiente de Data Warehouse consistente bem entendido, e que possam usar isto para
formular um mtodo apropriado para encontrar suas necessidades de negcios. Em
conseqncia disso, os metadados de negcio devem responder perguntas como: O
rendimento inclui ou exclui taxas de venda?; Quando algum de outro departamento fala
sobre tipos de produtos, a que ele ou ela est se referindo? Qual a frmula usada para
encontrar o resultado final da empresa?
A capacidade de entender e analisar deve ser grande para responder estes tipos de perguntas
citadas acima. funo dos metadados de negcio controlar e gerar respostas para estas
perguntas, e assegurar que os usurios do DW e Data Marts estejam trabalhando de
acordo com as regras da empresa.
Para o controle de metadados de negcio tambm necessrio possuir um conjunto
mnimo de classes, tais como:
Apelidos: Nomes secundrios para classes e atributos assegurando que exista um
entendimento comum das regras de negcio.
Domnios
Volumes
Cardinalidade
Volatilidade
Perspectivas do negcio
Medidas
Atributos sem medidas
Escopos de anlise
Itens do negcio: Definio de item de negcio para um determinado setor. Faz-se
necessrio um controle dos responsveis pela incluso de valores de atributo. Em
diversos casos a interpretao dos dados feita de maneira diferente em cada grupo
da organizao, pois cada departamento tem suas prprias regras e conceitos.
74
Data de incio, data de fim e status: Atributos temporais necessrios para o controle
de versionamento dos metadados. So respectivamente: Data de incio de validade do
metadado, data de fim de validade do metadado e situao do metadado (vlido ou
invlido atualmente). Desta forma possvel manter um histrico da evoluo da
semntica dos dados, um requisito indispensvel aos analistas de negcio.
Uma Arquitetura Bsica de Metadados
Para a definio de uma arquitetura bsica de metadados devemos sempre ressaltar a
inevitvel presena de diversas fontes de metadados em um ambiente de Data Ware-
house. Em virtude disto, necessria a presena de uma ferramenta de integrao de
metadados para unir as vrias fontes de metadados (Figura 5.2).
Figura 5.2: Uma arquitetura bsica de metadados.
Para o uso da ferramenta de integrao, precisa-se saber quais os metadados genricos e
se a mesma suportar todos os outros metadados existentes no processo. A identificao
das fontes e de seus requisitos de integrao fundamental para a visualizao de possveis
75
necessidades de mudanas no modelo da base de metadados suportado pela ferramenta
de integrao de dados.
Deve haver compatibilidade entre o repositrio e as ferramentas ETL e de modelagem.
J o processo de integrao com um dicionrio de dados pode ser feito atravs da escrita
de um programa complexo para moldar o dicionrio de dados a um formato que possa
ser integrado ferramenta do repositrio ou, idealmente, o modelo de metadados suportado
pela ferramenta de integrao de metadados deve possuir os campos necessrios para
suportar esses metadados.
Finalmente, pode ser usada uma ferramenta OLAP para acessar a informao no
repositrio ou at mesmo ser desenvolvida uma interface Web para acesso atravs de
uma intranet, por exemplo.
Tipos de Arquitetura de Metadados
Podemos definir 4 tipos de arquitetura de metadados. So eles:
Metadados Centralizados: O conceito de arquitetura de metadados centralizada um
modelo uniforme e consistente onde o esquema de definio e organizao de vrios
metadados seja armazenado em um repositrio global de metadados.
Metadados Descentralizados: O objetivo de uma arquitetura descentralizada um
modelo uniforme e consistente onde o esquema de definio e organizao de vrios
metadados seja armazenado em um repositrio global de metadados e em elementos
de metadados que apaream em repositrios locais. Todo metadado que compartilhado
e reutilizado entre os vrios repositrios primeiro deve passar pelo repositrio central.
Porm, o compartilhamento e o acesso ao metadado local so independentes do
repositrio central. O repositrio central o conjunto dos metadados armazenados em
repositrios locais. Essa arquitetura muito desejvel para aquelas empresas que tm
linhas de negcio diferentes e no-relacionadas, pois h o compartilhamento dos
metadados entre mltiplos repositrios e tambm cada repositrio local autnomo
para com seu contedo e requisitos administrativos.
Metadados Bidirecionais: Uma arquitetura de metadado bidirecional permite que o
metadado seja modificado no repositrio para depois ser transportado para seu lugar
de origem. Por exemplo, se um usurio acessa o repositrio e muda o nome de um
76
atributo para um dos Data Marts, a mudana repetida na ferramenta de modelo de
dados para atualizar o modelo fsico para aquele Data Mart especfico. Apesar de
complexa, esta arquitetura bem desejada, pois permite que as ferramentas
compartilhem os metadados e tambm permite que as empresas detectem modificaes
nos metadados, o que extremamente atrativo para organizaes que querem
implementar um repositrio de metadados em um nvel mais elevado.
Existem 3 (trs) desafios para implementao de metadados bidirecionais:
O repositrio de metadados deve sempre ter a ltima verso da fonte de metadados
que ir ser alimentada.
As mudanas precisam ser capturadas e resolvidas, pois um usurio pode estar
mudando o metadado no repositrio enquanto outro usurio muda o mesmo metadado
em sua fonte.
Mais interfaces precisam ser modeladas para o envio dos metadados do repositrio s
suas fontes.
Metadados Rotativos: O metadado rotativo permite que o repositrio envie seu
metadado de volta ao sistema de informao operacional da empresa. Essa arquitetura
parecida com a bidirecional, mas nesse caso o repositrio envia seu metadado para o
sistema fonte operacional e no para dentro de outras aplicaes. Metadados rotativos
esto ganhando popularidade entre as organizaes que querem implementar um
repositrio de grande escala, pois permitem fazer mudanas globais no repositrio e
ter essas mudanas detectadas dentro do sistema fonte operacional da empresa.
Metadados rotativos possuem as mesmas complexidades dos bidirecionais. O
repositrio ter que possuir a ltima verso dos metadados, no caso de esse metadado
ser enviado do repositrio para o sistema fonte operacional. Se o repositrio no
possuir a ltima verso, no h garantia de que o usurio atualize a ltima verso.
Alm disso, um usurio pode fazer mudanas nos metadados no repositrio ao mesmo
tempo em que outro est mudando no sistema fonte operacional. Esses conflitos
devem ser detectados e interfaces construdas para unir os metadados a sistemas
fontes operacionais. Apesar de poucas empresas estarem usando uma arquitetura
rotativa, um grande progresso em repositrios de metadados.
77
Requisitos de uma
Arquitetura de Metadados
Integrao
O maior desafio em construir um DW integrar todos os seus dispositivos de dados e
transformar esses dados em informaes valiosas. O mesmo acontece para um repositrio
de metadados. Por exemplo, uma organizao deseja mostrar a seus usurios a definio
de um campo que aparece em um relatrio, e digamos que esse campo veio de uma
planilha eletrnica. O processo de integrao dos metadados deve criar um link entre os
metadados do relatrio e o campo da planilha. A integrao dos dados a tarefa mais
complexa na implementao de um repositrio de metadados.
Extensibilidade
Se a integrao a caracterstica mais difcil a ser atingida, a escalabilidade a mais
importante. Um repositrio de metadados que no foi feito para crescer constantemente
breve ficar obsoleto. Trs fatores esto levando os repositrios a esse crescimento:
Crescimento contnuo de sistemas de suporte deciso: normal que o tamanho de um DW
e o nmero de usurios que acessam esse DW dobrem em um s ano. Se esses sistemas de
suporte deciso crescem, o repositrio tem que crescer para atender esse crescimento.
Reconhecimento do valor de um uso mais amplo dos metadados: Durante os ltimos
cinco anos as empresas comearam a notar a importncia de ter um repositrio de
metadados. Essas empresas no esto utilizando o repositrio s para suporte deciso,
mas tambm para outros fins.
Maior confiana no gerenciamento do conhecimento: Gerenciar conhecimento consiste
em identificar, capturar e compartilhar todos os recursos da empresa. Em resumo o
conceito de gerenciamento do conhecimento a captura dos recursos e disponibilizao
dos mesmos na rede da organizao.Nos ltimos anos, as organizaes comearam a
entender que o repositrio de metadados a principal estrutura para implementar o
gerenciamento do conhecimento.
A ferramenta que gerencia o repositrio tambm deve ser transportvel entre sistemas
operacionais, pois a mudana de um sistema operacional na organizao no pode devastar
um projeto de repositrio de metadados.
78
Robustez
Como qualquer sistema, um repositrio de metadados deve ter funcionalidade e desempenho
suficiente para atender as necessidades da sua empresa. Deve atender os usurios tcnicos
como tambm os usurios de negcios, e ter mais algumas caractersticas como:
Capacidade de importao e exportao de metadados.
Configurao segura e facilidades de permisso de acesso aos dados.
Arquivamento e backup simplificados.
Habilidade de gerar relatrios tcnicos e de negcios.
Abertura
A tecnologia usada para a integrao de metadados e acessos deve ser aberta e flexvel.
Por exemplo, os bancos de dados usados para guardar metadados so geralmente
relacionais, mas a arquitetura de metadados tem que ser suficientemente flexvel a ponto
de permitir que a organizao mude de um banco de dados relacional para outro tipo de
arquitetura. A abertura tambm diz respeito ao acesso ao repositrio, ou seja, as
organizaes geralmente desejam fornecer seus relatrios aos seus usurios via Web direto
de qualquer browser. Um bom gerente de metadados deve permitir isso.
Automatizao e Reutilizao de Processos
O processo de carregar e manter o repositrio de metadados deve ser o mais automatizado
possvel. Implementaes que contm muitos processos manuais em sua arquitetura
diminuem o desempenho do repositrio, ou muitas vezes o tornam inativo. Com uma
anlise cuidadosa e alguns esforos, esses processos podem ser automatizados.
Infelizmente alguns desses processos precisam ser feitos de forma manual para funcionar,
e precisam de tempo para ser completados. Nessas situaes, mais fcil desenvolver
um front-end para os usurios e deix-los criar e manter seus prprios metadados. Mesmo
que esses usurios no se sintam vontade em criar seus metadados, pelo menos at o
repositrio estar funcionando, um bom front-end e uma boa assistncia da equipe de
desenvolvedores poderiam encoraj-los nesta tarefa.
79
Padronizao do Processo de Integrao
O processo de integrar dispositivos de metadados baseado no mesmo conceito de ETL
(Extrao, transformao, carregamento) em um DW. O processo ETL divide-se em:
Camada de Extrao (Aquisio de Dados): A principal atividade da camada de
extrao adquirir dados de vrias fontes sem causar impacto algum nessas fontes.
Duas transformaes ocorrem ao dado nesta camada. O repositrio deve decidir se a
seleo de gravao deve ser usada nessa camada ou na camada de transformao.
Geralmente bom evitar critrio de gravao nesse ponto, ao menos que os dados no
metadado sejam bastante volumosos e essa quantidade que ser carregada no repositrio
seja um subconjunto menor. Logo aps, o desenvolvedor pode adicionar campos
especficos para serem usados no repositrio.
Camada de Transformao: A camada de transformao a espinha dorsal do
repositrio. A mais importante atividade do repositrio de metadados acontece nessa
etapa: integrao e limpeza da fonte de metadados. Aps esta tarefa, os metadados
ficam prontos para serem carregados no repositrio. A transformao e limpeza devem
acontecer na mesma plataforma fsica do repositrio de metadados. Desse modo,
enquanto as requisies ao repositrio crescem, toda fonte de metadados pode ser
integrada na mesma rea fsica, portanto minimizando mudanas na camada de extrao
e reduzindo os pedidos fonte de metadados.
As funes de transformao e limpeza podem ocorrer no mesmo programa ou
processo, ou em vrios processos, mas os arquivos gerados provenientes dos processos
de transformao devem sempre se igualar aos das classes de metadados, de onde ele
foi carregado. Qualquer erro que possa ocorrer quando o repositrio estiver sendo
carregado acontece nessa camada. Isso importante para criar procedimentos de
recuperao no caso de a leitura ter que parar.
Camada de Leitura: A camada de leitura captura os arquivos que so gerados na camada
de transformao e os leva ao repositrio. Procedimentos de recuperao tambm so
importantes nessa camada caso haja algum problema no processo de leitura. Geralmente
usa-se o mecanismo de leitura de volume padro e bancos de dados relacionais. Se no
futuro houver a necessidade de ligar tabelas relacionais, os processos nas camadas de
extrao e transformao no sero afetados, mas os processos nesta camada tero
que ser modificados. Como poucos processos acorrem nesta camada, as modificaes
so relativamente fceis.
80
Existem 2 (duas) grandes vantagens em separar a camada de extrao da camada de
transformao:
Sincronismo: A camada de extrao mantm o metadado no repositrio em sincronismo.
Digamos que temos 3 classes que precisam de dados da mesma fonte de metadados.
Se existisse um processo para ler cada uma das classes diretamente do mesmo metadado,
os dados presentes no metadado poderiam mudar ao longo do processo de montar as
classes. Isso pode acontecer se o dispositivo de metadado for dinmico, e ocorre porque
a leitura dos metadados feita em diferentes instncias. Assim, a informao no
repositrio de metadados no estar em sincronizao. Criando um arquivo de extrao
no processo de integrao, todas as classes podem ser construdas a partir desse arquivo,
que eliminaria qualquer problema de sincronismo.
Backup: A criao de um arquivo de extrao prov uma cpia da fonte de metadados.
Entretanto, se alguma coisa fizer parar o processo de integrao de metadados, pode
ser feita uma recuperao das mudanas sem causar nenhum dano.
Flexibilidade
Modelos de metadados geralmente usam um esquema orientado a objetos para representao
conceitual da organizao dos repositrios. O modelo de metadados prov uma estrutura para
estabelecer um protocolo para acesso aos metadados, administrao e intercmbio de informaes
entre os softwares que acessam o repositrio. O modelo de metadados deve ser capaz de capturar
o que for de interesse das aplicaes que fazem uso do repositrio. Por exemplo, em um DW ou
ambiente de suporte deciso temos como metadados chave: objetos relacionais e no-
relacionais, conceitos multidimensionais, lgicas de transformao, regras de negcio e
programas de trabalho. Todos esses metadados devem ser manipulados pelo repositrio. A
metodologia de modelagem de metadados deve ser capaz de acomodar vrios tipos de
relacionamentos, como um-pra-um, um-pra-muitos, muitos-pra-muitos, agregao e herana.
Gerenciamento de Mltiplas
Verses de Metadados
No momento em que o metadado prov um contexto para interpretao do significado
da informao, o repositrio tem a funo de gerenciar a estrutura dos dados de um DW
por um longo espao de tempo. Por esta razo, preciso saber o perodo de tempo em
81
que o metadado armazenado no repositrio. Para realizar isso, as classes do modelo de
metadados devem ter atributos com a data inicial e a data final. Estas datas permitem que
o usurio facilmente consulte verses antigas do metadado.
Facilidades de Atualizao
Inevitavelmente, podem ocorrer mudanas nas aplicaes que acessam o repositrio a
partir do momento que ele for carregado. A equipe que implementou o repositrio tem
que decidir em que momento atualizar o repositrio para cada fonte de metadados. Como
regra geral, a maioria dos repositrios atualizada mensalmente. Na maioria das fontes
de metadados, no necessria uma atualizao do repositrio para cada mudana que
ocorra. Por exemplo, se for adicionado um ndice em uma tabela de um sistema fonte,
no necessria a atualizao, mas se algo de mais abrangente acontecer como a
eliminao de uma entidade de um sistema fonte, o repositrio tem que ser atualizado
para incorporar os novos modelos de dados, definies de negcios, e assim por diante.
Claro que alguns tipos de metadados, como por exemplo as estatsticas de leitura de um
DW e acesso dos usurios, so constantemente atualizados.
Arquitetura Multicamadas
A maioria dos repositrios de metadados baseada em arquitetura de duas camadas, cliente-
servidor, da mesma forma que um servidor de banco de dados funciona, sendo acessado
por vrias aplicaes. Mas uma arquitetura multicamadas prov uma arquitetura mais aberta
e extensvel para gravao, leitura e modificao dos metadados. Essa arquitetura inclui
um servidor de repositrio que encapsula um sistema de gerenciamento fsico de banco de
dados (seja relacional ou orientado a objetos) e fornece vrios componentes para manipular
inmeras interfaces (XMI, XML, COM+, etc.). Tambm deve haver proviso de mecanismos
para acesso e gerenciamento de metadados em redes locais e de longa distncia para
acomodar ambientes de distribuio. Com o crescimento da internet e comrcio eletrnico,
uma arquitetura multicamadas um importante requisito para um repositrio de metadados.
Gerenciamento de Segurana
importante salientar que o metadado um recurso inestimvel em uma organizao.
O acesso ao metadado deve ser cuidadosamente controlado para projetar recursos
82
intelectuais e assegurar a validao e integridade do metadado para todos os usurios
ao mesmo tempo.
O esquema de gerenciamento de segurana para o repositrio de metadados parecido
com a maioria dos SGBDs, mas deve ser projetado para necessidades especficas dos
criadores de metadados, usurios e administradores. Alm disso, o acesso deve ser restrito
ao metadado de acordo com o tipo, ou as operaes que os usurios ou administradores
dos metadados pretendem fazer. Um esquema de gerenciamento de segurana robusto
um requisito essencial para o repositrio de metadados.
Funcionalidade de um
Repositrio de Metadados
Para alcanar seus objetivos, o repositrio de metadados deve prover certa funcionalidade
como: proviso de informao baseada em um metamodelo, acesso automtico,
administrao de verso e configurao, anlise de impacto e notificao.
Proviso de Informao
O repositrio tem que oferecer mecanismos para exame, filtro e navegao de modo a
satisfazer as necessidades de informao dos usurios. O esquema do repositrio deve
prover consultas sob certas condies como, por exemplo, fazer consultas selecionando
apenas o processo de atualizao, ou todos os metadados lgicos que se relacionam com
o objeto de negcio scio.
A estrutura do repositrio tambm deve permitir seleo de metadados de acordo com
sua origem, propsito e tempo de produo. Isto exige que os metadados possuam chaves
que contm os valores apropriados (por exemplo, em terminologia relacional atributos
para propsito, origem e etc. devem existir).
Um repositrio no s deve prover informaes explcitas sobre relacionamentos entre
metadados como tambm implcitas. Em conseqncia disso, uma exigncia de
funcionalidade essencial a navegao dentro da coleo de metadados. Comeando
com um certo elemento, o usurio pode navegar por outros elementos ao longo de
relaes existentes. Esta navegao dirigida pelo esquema especificado em um nvel
conceitual do repositrio.
83
Com relao filtragem o ideal que alm do exame de atributos fixos seja possvel
tambm a procura de palavras-chave dentro de descries textuais. Desta forma, toda
informao relacionada com um tpico pode ser provida.
Com relao navegao extremamente necessria uma interface amigvel para o
usurio interagir com o repositrio. Cada usurio deve ter seu ponto de partida de
navegao baseado nos seus direitos de visibilidade (vises do usurio).
Metamodelo
Para prover a funcionalidade necessria, um metamodelo apropriado deve ser escolhido.
Um metamodelo o esquema conceitual do repositrio de metadados. Especifica
elementos de metadados e relacionamentos entre eles.
O metamodelo requer elementos para representar metadados em nveis diferentes de
abstrao e deve ser extensvel para que usurios possam definir aplicaes com elementos
de metadados especficos.
Acesso ao Repositrio
Para ser utilizvel, o repositrio tem que ser atualizado. S podem ser garantidos o uso
prspero e longevidade do repositrio se interfaces para interoperabilidade com outros
repositrios estiverem disponveis. Para isso necessrio que um padro de intercmbio
seja adotado e uma API seja fornecida para acesso por outras ferramentas.
Administrao de Verso e Configurao
Mudanas importantes de metadados como atualizao de esquemas de fontes
operacionais requerem criao de verses diferentes e conseqente armazenamento
no repositrio. Porm, problemas podem surgir com vnculos incompatveis, ou
descries no nvel conceitual que no so mais vlidas. Desta forma o repositrio
deve prover mecanismos de notificao para descobrir tais erros de estrutura e
validade dos metadados.
84
Anlise de Impacto
Esta caracterstica deve permitir que administradores possam avaliar o impacto de
mudanas no DW antes que eles sejam feitos. Simulaes so feitas para descobrir quais
partes do sistema so afetadas quando a aplicao requer mudanas. Por exemplo,
mudanas de esquemas fontes podem ter conseqncias para regras de transformao.
Notificao
O repositrio deve prover mecanismos de notificao para usurios e/ou ferramentas
interessadas em mudanas significantes.
Metadados Tcnicos e
Qualidade de Dados em Metadados
Poucos DWs exploram as vantagens de incorporar metadados tcnicos especializados
em seu modelo de dados de suporte deciso e processos ETL. Isso sempre leva a uma
reduo na flexibilidade do DW, causando perda de tempo, dinheiro com manuteno,
aquisio de dados e auditoria de informao. Pode tambm levar os usurios a
interpretarem de maneira errada as informaes do DW. Nesse tipo de situao,
necessrio rever o repositrio de metadados e procurar aprimorar a identificao e
qualidade dos dados. importante entender como o uso do metadado controla a qualidade
da informao guardada em um DW.
Sabemos que muitas empresas usam um repositrio para acessar informaes tcnicas e
de negcio. Por esse aspecto, o repositrio serve como um catlogo de informaes para
um ambiente de suporte a deciso, sendo como um guia para a informao armazenada
no DW. Apesar dessa importante caracterstica, o repositrio ainda pode ser expandido
para uma participao ativa no processamento dos dados.
O repositrio de metadados mantm informaes do modelo de suporte deciso, sistemas
fontes operacionais, processos ETL, e estatsticas de leitura que abrangem o DW. A
integrao desses componentes no repositrio est em um nvel razoavelmente alto. Por
exemplo, a informao do repositrio pode ser usada para determinar que um sistema
operacional de gerenciamento seja a fonte que alimenta uma tabela especfica em DW
relacional. Revendo as estatsticas de leitura do repositrio, pode-se determinar como e
85
com que freqncia o DW atualizado. Essa informao permite aos usurios terem
uma boa viso do ambiente de suporte a deciso, mas esse nvel de informao
insuficiente quando um usurio tcnico ou de negcio precisa ter uma viso mais detalhada
dos dados de um DW.
Para alcanar uma viso mais detalhada da informao contida no DW, o arquiteto do
repositrio, o modelador dos dados e os desenvolvedores usam o metadado tcnico que
foi estendido para forjar um relacionamento mais prximo entre o repositrio e o banco
de dados de suporte a deciso. Isso realizado incorporando o metadado tcnico no DW.
Essa tcnica usada para estender o projeto e a arquitetura de um DW, para aumentar o
processo de otimizao para aquisio dos dados, atividades de manuteno e medidas
para qualidade dos dados.
Para fazer do metadado tcnico uma ponte entre o repositrio e o modelo de dados de um
DW, o projetista deve incluir operadores no modelo de dados fsico. O metadado tcnico,
ao contrrio da informao guardada no repositrio, referenciado de maneira livre no
DW. Essas marcaes de metadados tcnicos provem um bom detalhamento da
informao contida no DW. Essa associao direta do metadado para cada informao
no DW, o que distingue o metadado estendido.
Para escolher os operadores, o sistema fonte operacional une os dados ao metadado
tcnico estendido durante o processo ETL. O metadado tcnico se une aos dados no DW
provendo um significado semntico mais claro para o dado. Por exemplo, a tabela de
lojas deriva sua informao de duas fontes operacionais. A informao retirada tanto
de uma aplicao de vendas quanto de uma aplicao de recursos humanos, dependendo
da disponibilidade. Sem o metadado tcnico estendido na tabela, a informao s pode
ser usada do jeito que est, sem o sistema fonte operacional que a prov. O metadado
tcnico marcado permite determinar quais dados foram derivados das duas fontes.
O projetista do repositrio, o modelador dos dados e desenvolvedores precisam
calmamente considerar o plano usado pelos metadados tcnicos no modelo de suporte
deciso. Usurios de negcio e tcnicos do DW devem identificar e concordar com um
claro e consistente mtodo de marcao dos dados originrios do sistema fonte
operacional. Qualquer metadado tcnico amarrado aos dados deve ser aplicvel por
completo, no s a maioria dos atributos da classe.
86
Prefere-se manter metadados tcnicos amarrados a mnimos modelos de dados
dimensionais, como aqueles que so s uma ou duas classes, onde uma simples fonte
alimenta o DW, ou quando vrios sistemas fontes operacionais precisam ser integrados
para carregar uma classe de suporte deciso. Esquemas complicados fazem da sada
dos metadados do sistema, fonte operacional mais desafiadora.
A equipe do DW responsvel por avaliar o projeto e o impacto de manuteno causado
pelo uso de metadados amarrados ao repositrio, processos ETL, modelo de dados,
tamanho do banco de dados, e o front-end para acesso aos dados. Por exemplo, o mesmo
front-end da ferramenta OLAP requer uma aderncia rgida no modelo de suporte
deciso para que funcione completamente e apropriadamente. Isso pode impedir o uso
de alguns ou todas as marcaes de metadados tcnicos em certas dimenses como a
dimenso tempo de um DW. Certos tipos de metadados estendidos podem precisar de
que processos adicionais de ETL ocorram, o que poderia causar lentido na carga.
Uma variedade de marcaes do metadado tcnico pode ser incorporada ao projeto do
modelo de dados de suporte a deciso para melhorar o detalhamento de informaes de
um DW. Dependendo dos requisitos da aplicao, do nmero de sistemas fontes
operacionais alimentando o DW, ou da complexidade do modelo de suporte deciso, a
incluso de marcaes de metadados tcnicos pode ou no fazer sentido. Por exemplo,
adicionar uma coluna a uma tabela de dimenso em um DW relacional para identificar o
sistema fonte operacional, onde s uma pequena fonte de informao existe para preencher
a tabela, pode parecer pouco produtivo ou prover pouco valor. Mas tem que se considerar
os possveis efeitos de no incorporar essa marcao de metadado. Primeiro, o fato de o
DW ter uma s fonte hoje no assegura que amanh ele v continuar assim. Segundo, se
o DW realmente evoluir e o nmero de sistemas fontes aumentar, difcil mudar a tabela
de um DW depois de ela ter sido carregada. E por ltimo, sendo o sistema fonte operacional
ligado a todas as tabelas, indiferentemente do nmero de fontes, estamos provendo
consistncia para modelos de suporte deciso e gerando disciplina na implementao
da metodologia de desenvolvimento adotada.
A incorporao de metadados tcnicos em um modelo de DW relacional, por exemplo,
acontece durante a transformao do modelo de dados de negcio. Durante essa
modelagem, as colunas fsicas so adicionadas s tabelas apropriadas como foi
determinado pelos requisitos de negcios e avaliao tcnica previamente completa. O
87
metadado tcnico incorporado no modelo fsico baseado no tipo de tabela que est
sendo endereado.
Dependendo dos requisitos de negcio de um projeto, os seguintes atributos dos metadados
tcnicos sero muito teis:
Data de Leitura: Uma das diferenas fundamentais entre um modelo de dados de um
sistema fonte operacional normal e o modelo de DW a adio da data em todos os
dados. Um dos atributos mais usados dos metadados tcnicos o atributo Data de
Leitura. Este atributo mostra quando (data ou hora) uma informao foi carregada
pelo DW. Essa data instantnea usada para manter a integridade temporal do dado
em um DW no momento em que as informaes so inseridas e atualizadas. Esse
atributo pode ser referenciado pelo administrador do DW para identificar possveis
dados que precisem ser arquivados ou deletados. Usurios finais s podem usar esse
atributo para reconciliar e fazer auditorias no DW. Existem casos em que a data em
que o dado foi carregado para o DW tem pouca relevncia para o cenrio de negcios.
A data efetiva dos dados extrados do sistema fonte operacional pode ser mais
importante. necessrio observar estes detalhes quando for feita a determinao de
que marcaes de metadados tcnicos adicionar ao modelo de dados.
Data de Atualizao: Outro atributo comum dos metadados tcnicos a Data de
atualizao. Esse atributo indica quando um registro foi atualizado pela ltima vez
durante seu ciclo. Esse atributo tambm usado para manter a integridade temporal
das informaes em um DW.
Identificador de Ciclo de Leitura: Esse atributo um identificador seqencial nomeado
durante cada ciclo de leitura em um DW, no importa a freqncia. Como um
identificador seqencial, pode ser usado facilmente para remover dados de um
determinado ciclo caso haja ruptura dos dados ou qualquer outro erro que possa
aparecer. O Identificador de Ciclo de Leitura bem usado em conjunto com uma
classe do repositrio de metadados que descreva outras estatsticas operacionais sobre
o ciclo de leitura. Usando somente o repositrio de metadados, pode-se determinar
quando e quantos ciclos ocorrero no DW. Usando o identificador, pode-se determinar
at quando e quais registros foram lidos.
Indicador de Verso: O atributo Indicador de Verso identifica a ltima verso de
um registro numa tabela de um DW relacional, por exemplo. Alm de ser importante
88
para manter histrico, esse atributo tambm muito til para esquemas que no sejam
tipo estrela, onde o modelo de dados como um DW atmico e as estruturas tendem
para a terceira forma normal. Em vez de pesquisar na tabela pelo campo de data mais
antiga, o processo ETL nomeia N para o campo mais antigo e S para o mais atual.
Isso permite que os usurios consultem dados histricos e atuais do DW.
Identificador do Sistema Fonte Operacional: Uma das mais teis tcnicas em termos
de campos de metadados tanto para administradores, quanto para usurios finais, o
uso do Identificador do Sistema Fonte Operacional. Esse atributo usado para
identificar a fonte original dos dados e permite identificar individualmente, para cada
linha da tabela de um DW relacional, por exemplo, quais fontes foram usadas na sua
construo. Os usurios de negcio podero questionar a qualidade ou a validade dos
dados em um DW para devolver a informao ao sistema de informao operacional
de origem, que forneceu a informao. Em alguns casos, os administradores podem
usar esse atributo para identificar e remover dados corrompidos de um ou mais sistemas
fontes operacionais.
Identificador de Chaves: Esse identificador indica se as chaves em um DW ainda
continuam ativas em seus sistemas fontes operacionais de origem. O Identificador
de Chaves prov uma anlise alternativa para pesquisas no DW. Esse atributo pode
ser usado efetivamente em uma variedade de atividades de anlise para identificar
quais dados deveriam estar em relatrios. Por exemplo, o Identificador de Chaves
pode ser usado para identificar e filtrar as contas contbeis que esto inativas em
um certo banco.
Indicador de Nvel de Secreto: Uma das tcnicas mais controversas o atributo
Indicador de Nvel Secreto. Esse atributo usado para indicar que regras de negcio
ou suposies foram aplicadas em um dado em particular durante o processo ETL.
Esse atributo possibilita ao usurio medir o nvel de credibilidade de um dado baseado
em um processo de transformao que foi executado. O Indicador de Nvel Secreto
freqentemente usado para identificar problemas de qualidade de dados do sistema
fonte operacional e facilitar a correo desses problemas. O Indicador de Nvel
Secreto tambm usado para identificar dados que tiveram que ser estimados, previstos
ou tendenciados. Desta forma, um DW pode ter, por exemplo, nveis de estabilidade:
um determinado nvel representa dados considerados mais volteis, fceis de limpar
89
ou relativamente moderados para definir; outro nvel pode representar dados que fo-
ram considerados mais problemticos para definir; um terceiro nvel pode consistir de
dados que no vieram de nenhum dos sistemas fontes operacionais mas sim de alguma
planilha, e um quarto nvel para marcar os dados de fontes externas como novos servios
ou fontes comerciais.
Vale salientar que incorporar marcao de metadados tcnicos faz possvel uma variedade
de otimizaes na aquisio dos dados, atividades de manuteno e informaes de
auditoria dos usurios finais no DW. Como exemplo podemos citar a possibilidade de
eliminao de uma carga corrompida ou suspeita de um DW com maior facilidade, pois
antes de os atributos de metadados tcnicos serem incorporados dentro do modelo de
dados, os desenvolvedores tinham opes limitadas de isolamento e remoo de
informaes corrompidas. A marcao de metadados tcnicos permite aos
desenvolvedores serem seletivos em seus mtodos de remoo de dados do banco.
Em resumo, a incorporao de atributos de metadados tcnicos em um DW permite a
usurios de negcios e administradores resolverem problemas administrativos e de qualidade
de dados. Os principais objetivos so: Medidas de qualidade de dados; Amostragem de
resultados do ciclo de leitura do processo ETL; Administrao e manuteno.
Controle de Metadados em um
Projeto Evolutivo de Construo de DW
Para um DW abranger toda a corporao inicialmente, a mesma deve ser totalmente
informatizada e integrada, alm do fato de o projeto ser extremamente complexo e com
alta probabilidade de insucesso.
Para diminuir os riscos de fracasso de construo de um DW e como a integrao
total rara de ser encontrada ainda hoje, deve-se aproveitar a estrutura operacional
disponvel e desenvolver um Data Mart de cada vez. Esta tcnica de desenvolvimento
evolutiva fez surgir o conceito de Federated Data Warehouse (FDW). Nesse modelo,
os Data Marts devem ser controlados por um bloco nico de metadados e coexistir
com um EDW (Enterprise Data Warehouse) dependendo dos mesmos metadados.
Em outras palavras, o FDW a composio de todos os Data Marts e o EDW (ou
Data Warehouse Corporativo).
90
O desenvolvimento de um FDW, devido sua complexidade, o mais dependente do
controle de metadados para dar certo. Os metadados sero usados para assegurar que
toda informao dever ser enviada para todos os Data Marts, sendo eles independentes
ou no do EDW.
Em linhas gerais, os metadados englobam as maiores funes de cada ciclo de vida dos
dados dentro de um Federated Data Warehouse. Os metadados provem uma linguagem
comum para definir o comportamento dos dados. A sintaxe formal dos metadados permite
definio robusta de regras de negcio e significados associados com os dados que esto
sendo transferidos do sistema de informao operacional de origem para o EDW e
eventualmente para dependentes ou independentes Data Marts. Isso se aproxima da viso
tradicional dos metadados, descrevendo como vendas e clientes se relacionam,
assegurando a consistncia do grupo de clientes, definies universais, valores usados
para moeda, entre outros.
Os metadados tambm controlam o fluxo dos dados. Os metadados tcnicos vo conter
no s definies dos dados, como tambm descries formais da ocorrncia dos fluxos,
regras de transformao de dados, dependncias entre as transformaes, e fatores de
tempo que afetam a transferncia dos dados.
Finalmente, os metadados vo comunicar a natureza dos dados dentro do Data Warehouse
para os usurios e desenvolvedores com a necessidade de entender a base dos negcios.
Essa habilidade de acessar a definio e o controle dos dados vital para que a proliferao
dos metadados ao longo das comunidades tcnicas e no-tcnicas seja efetiva e entendida.
O EDW pode suprir papis diferentes nesse tipo de arquitetura. Ele prov um seguro e
completo mecanismo pelo qual a qualidade dos dados pode ser posta em controle de
consistncia dentro dos Data Marts, mas evidentemente apresenta um nvel significante
de redundncia de dados. Cada item incluso no EDW estar no mnimo em uma das
estruturas dos Data Marts.
Todas as regras de negcio impostas pelo EDW ou pelos metadados tcnicos dentro da
Staging Area sero herdadas pelos Data Marts, em um caso ideal. Os metadados tcnicos
definem e controlam as regras de negcio que so aplicadas nos dados quando os
mesmos entram em um ambiente de Data Warehouse. Uma vez dentro do ambiente, a
interpretao que posta sobre o dado pelos usurios controlada pelos metadados de
91
negcio, que tambm asseguram que o comportamento do dado em diferentes Data
Marts seja consistente.
Na prtica, isto implica que os metadados devem ser gerenciados de acordo com os
seguintes aspectos:
As regras contidas dentro dos metadados tcnicos devem ser controladas para assegurar
que elas estejam corretas. Regras sem necessidade devem ser omitidas e as regras
ditas universais no devem ser parciais.
As regras dentro dos metadados de negcio devem estar presentes em um formulrio
de fcil entendimento pelo usurio final daquele dado o principal propsito desses
metadados assegurar que o usurio possa acessar e manipular o dado eficientemente
e corretamente. Isso no vai acontecer a menos que os metadados de negcio sejam
robustos e presentes nos termos de negcio.
O mecanismo de controle deve assegurar que os nveis dos metadados de negcio e
tcnicos estejam consistentes. Se isso no acontecer, os metadados vo piorar a
qualidade dos dados ao invs de melhorar.
Padronizao de Metadados
A globalizao das corporaes em um ambiente de negcios altamente competitivo
exige um fluxo de informaes rpido e eficiente. Para isso, necessria a integrao
de informaes e seu conseqente gerenciamento como forma de diminuir o custo e o
tempo despendido na implementao de novas solues. Contudo, esse gerenciamento
integrado encontra obstculos na proliferao de ferramentas de gerenciamento e
manipulao de dados que, em sua maioria, processam metadados de maneira
proprietria. A soluo para esse problema apresenta-se na forma de padres para
definio e troca de metadados, o que permite a reutilizao de dados entre diferentes
aplicaes. Podemos citar dois principais padres que possuem esse objetivo: MDIS
(Metadata Interchange Specification) e OIM (Open Information Model) ambos
pertencentes Metadata Coalition, um consrcio no-lucrativo de vendedores e usurios
finais que tem como objetivo prover uma especificao no proprietria dos metadados
corporativos. O MDIS prov conceitos para suportar a troca de metadados relacionados
com diferentes tipos de repositrios de dados: relacionais, multidimensionais, em rede,
hierrquicos e baseados em arquivos. Contudo, sua especificao restringe-se aos
92
relacionamentos existentes em um esquema de dados. Em contrapartida, o OIM
apresenta modelos de informaes que englobam todas as fases do desenvolvimento
de sistemas de informao. Um desses modelos o modelo de banco de dados, que
fornece conceitos relativos a provedores de dados relacionais.
Mesmo assim a padronizao de metadados ainda no est estabilizada, pois padres
para aplicaes especficas requerem um alto grau de detalhe e regulamentao mais
precisa que padres de propsito geral.
Seguindo na busca por padronizao diversas empresas como a Oracle e Unisys deixaram a
Metadata Coalition e esto propondo o CWM (Common Warehouse Metadata). O mecanismo
baseado no Intercmbio XML
9
de Metadados (XMI) especificamente. XMI usa os padres
da XML. Em outras palavras, todo atributo de um metamodelo representado na Definio
de Tipo de Documento (DTD) por um elemento de XML cujo nome o atributo. Cada
associao entre duas metaclasses representada por dois elementos de XML que representam
os papis na associao. As multiplicidades da associao esto em multiplicidades de XML
que so vlidas para especificar os modelos de elementos de XML.
Ainda no se sabe qual nvel de detalhe e cobertura pode ser esperado pelo mesmo, ou seja,
at agora no est claro se o mesmo ser um padro estrutural que define um metamodelo
para Data Warehouse ou apenas um padro de troca. O CWM no a soluo para a integrao
funcional dos repositrios de dados, mas pode vir a facilitar esta tarefa por fornecer metadados
padronizados. Comparando o CWM com o OIM temos como principal diferena a amarrao
do pacote OLAP do OIM ao modelo relacional. As diferenas so interessantes de serem
vistas, porm j sabido que a Metadata Coalition forneceu suas especificaes para o CWM
e parece ter desistido de continuar com a tarefa rdua de construir um padro.
O Metamodelo CWM
O principal objetivo do CWM facilitar a troca de metadados em um ambiente de DW
distribudo. O CWM pode ser classificado como um padro para representao e troca
de metadados. Nele especificado um metamodelo que pode ser visto como um esquema
conceitual para representao de metadados.
9
XML eXtensible Markup Language linguagem de marcao (Markup Language) extensvel e flexvel, cujos
dados so delimitados por tags. A XML foi projetada para descrever o contedo dos dados.
93
O padro CWM uma proposta do OMG (Object Management Group) que se baseia em
outros trs padres do mesmo grupo.
O Object Management Group (OMG) uma organizao internacional, fundada em
1989, que hoje formada por mais de 800 membros, dentre eles fabricantes de software
e usurios. O objetivo maior do OMG promover a interoperao de sistemas heterogneos
distribudos utilizando tecnologia orientada a objetos. Seu principal produto consiste em
especificaes voltadas para a indstria de software e independentes de fabricante.
Dentre as vrias especificaes (e padres) desenvolvidas/adotadas pelo OMG esto o
MOF (Meta Object Facility), a UML (Unified Modeling Language) e o XMI (XML
Metadata Interchange) que, juntos, formam o ncleo da arquitetura de metamodelagem
do OMG, na qual o CWM est inserido, sendo um metamodelo de domnio especfico.
O CWM constitudo de vrios submetamodelos, que representam metadados comuns
s principais reas da tecnologia de Data Warehousing. Essas reas funcionais foram
classificadas em:
Resources: suporta a definio de vrios tipos de dados fontes e alvos, composta por
metamodelos que representam fontes relacionais, orientadas a objetos, registros,
multidimensionais e XML.
Analysis: define as transformaes e processamentos analticos que ocorrem nas fontes
de dados. Abrange os metamodelos que representam transformaes de dados, OLAP,
minerao de dados, visualizao de informaes e nomenclatura de negcios.
Management: utilizado quando na definio de metadados para registrar informaes
de scheduling e detalhes operacionais tais como o resultado de transformaes. Consiste
dos metamodelos Warehouse process e Warehouse operation.
Foundation: prov os tipos de metadados para representao de conceitos e estruturas
que so compartilhados por outros pacotes do CWM.
Object Model: neste pacote esto definidos os construtores bsicos para a criao e
descrio de todas as classes do metamodelo em todos os outros pacotes. O Object
Model um subconjunto da UML que inclui apenas as caractersticas necessrias para
criar e descrever o CWM.
Se o CWM for aceito verdadeiramente como padro, habilitar produtos de apoio deciso
a compartilhar dados e informao. Isto, em troca, proveria aos Data Warehouses uma
94
estrutura aberta, comum a todas as ferramentas envolvidas no processo. Havendo um
metamodelo padronizado para todas as ferramentas a comunicao entre elas torna-se
basicamente vivel.
Resumo
As pesquisas na rea de metadados para DW esto aumentando em funo da necessidade
extrema das organizaes de conhecer melhor os dados que elas mantm, e tambm
conhecer com mais detalhes os dados de outras organizaes, atravs de intranets e
extranets. Sem uma documentao eficiente dos dados, dificultada aos usurios a
localizao de dados necessrios para suas aplicaes. Tambm, os dados ficam sujeitos
superposio de esforos de coleta e manuteno, e vulnerveis a problemas de
inconsistncias. O no uso ou uso imprprio da informao ser altssimo.
Dentro do contexto de DW podemos dividir os metadados em duas categorias bsicas:
metadados tcnicos e metadados de negcio.
Metadados tcnicos provem conf iabilidade na acuracidade do DW para os
desenvolvedores.
Metadados de negcio perfazem a juno entre o mundo codificado de um DW e o
mundo do usurio de negcios.
Para a definio de uma arquitetura bsica de metadados devemos sempre ressaltar a
inevitvel presena de diversas fontes de metadados em um ambiente de Data Warehouse.
Em virtude disto, necessria a presena de uma ferramenta de integrao de metadados
para unir as vrias fontes de metadados.
Podemos citar 4 tipos de arquitetura de metadados. So elas: Metadados centralizados;
Metadados descentralizados; Metadados bidirecionais; Metadados rotativos.
Para a construo de uma arquitetura de metadados o repositrio dos mesmos deve atender
a requisitos bsicos tais como: Integrao; Extensibilidade; Robustez; Abertura;
Automatizao e reutilizao de processos; Padronizao do processo de integrao;
Flexibilidade; Gerenciamento de mltiplas verses de metadados; Facilidades de
atualizao; Ser multicamadas; Gerenciamento de segurana.
95
Em se tratando de funcionalidades, desejvel que um repositrio de metadados proveja
certas funcionalidades como: proviso de informao baseada em um metamodelo, acesso
automtico, administrao de verso e configurao, anlise de impacto e notificao.
Alm de explorar um repositrio de metadados, um projeto de DW pode explorar as
vantagens de incorporar metadados tcnicos especializados em seu modelo de dados de
suporte deciso e processos ETL.
Para alcanar uma viso mais detalhada da informao contida no DW, o arquiteto do
repositrio, o modelador dos dados e os desenvolvedores usam o metadado tcnico que
foi estendido para forjar um relacionamento mais prximo entre o repositrio e o banco
de dados de suporte a deciso. Isso realizado incorporando o metadado tcnico no DW.
Essa tcnica usada para estender o design e a arquitetura de um DW, para aumentar o
processo de otimizao para aquisio dos dados, atividades de manuteno e medidas
para qualidade dos dados.
Para fazer do metadado tcnico uma ponte entre o repositrio e o modelo de dados de um
DW, o projetista deve incluir operadores no modelo de dados fsico. O metadado tcnico,
ao contrrio da informao guardada no repositrio, referenciado de maneira livre no
DW. Essas marcaes de metadados tcnicos provem um bom detalhamento da
informao contida no DW. Essa associao direta do metadado para cada informao
no DW o que distingue o metadado estendido.
Para escolher os operadores, o sistema fonte operacional une os dados ao metadado tcnico
estendido durante o processo ETL. O metadado tcnico se une aos dados no DW provendo
um significado semntico mais claro para o dado. Por exemplo, a tabela de um cliente
deriva sua informao de duas fontes operacionais. A informao retirada tanto de uma
aplicao de automao de venda quanto de uma aplicao de planejamento de recursos,
dependendo da disponibilidade. Sem o metadado tcnico estendido na tabela, a informao
s pode ser usada do jeito que est, sem o sistema fonte operacional que a prov. O metadado
tcnico marcado permite determinar quais dados foram derivados das duas fontes.
Dependendo dos requisitos de negcio de um projeto, os seguintes atributos dos metadados
tcnicos sero muito teis: Data de leitura; Data de atualizao; Identificador de ciclo de
leitura; Indicador de verso; Identificador do sistema fonte operacional; Identificador de
chaves; Indicador de nvel secreto.
96
O conceito de Federated Data Warehouse (FDW) surgiu com o objetivo de diminuir os
riscos de fracasso de um projeto de DW. Nesse modelo, os Data Marts independentes
devem ser controlados por um bloco nico de metadados e coexistir com um EDW
(Enterprise Data Warehouse) dependendo dos mesmos metadados.
O desenvolvimento de um FDW, devido sua complexidade, o mais dependente do
controle de metadados para dar certo. Os metadados sero usados para assegurar que
toda informao dever ser enviada para todos os Data Marts, sendo eles independentes
ou no do EDW.
Finalmente, os repositrios de metadados caminham para uma padronizao da
representao e troca de metadados. O principal objetivo facilitar a troca de metadados
em um ambiente de DW distribudo. Atualmente, o metamodelo com maior aceitao
o CWM. Nele especificado um metamodelo que pode ser visto como um esquema
conceitual para representao de metadados.
Concluses
Os benefcios que um Repositrio de Metadados pode oferecer a um ambiente de
Tecnologia da Informao, tais como histrico de informaes e o grande aumento de
qualidade nas pesquisas, so notrios. Todavia, a utilizao do mesmo em empresas
ainda est longe de ser uma tarefa fcil e de baixo custo. A tecnologia envolvida necessita
de mo-de-obra qualificada e escassa, e atualmente s grandes empresas tm capital e
estrutura para usufruir de tamanha qualidade na administrao de informaes. Devido a
estes fatores, empresas de vrias categorias esto tentando desenvolver seu prprio
repositrio utilizando-se de seus prprios conhecimentos e experincias. Isso certamente
resultar no desenvolvimento de Repositrios que possam ser acessveis financeiramente
a pequenas e mdias empresas.
Em se tratando de arquitetura, idealmente, uma empresa deveria ter um nico repositrio
para administrar seus metadados, porm a centralizao no condiz com a realidade
por diversas razes, como evoluo de diversos departamentos que implica
desenvolvimento assncrono de repositrio. Em outras palavras e fazendo uma anologia
com a construo de um DW, um repositrio de metadados construdo idealmente
numa metodologia bottom-up. Ou seja, o repositrio evolui gradativamente at abranger
97
os metadados de toda a corporao de uma forma centralizada, assim como os Data
Marts formam o DW corporativo.
Analisando a questo da extenso dos metadados tcnicos, podemos concluir que
atributos de metadados tcnicos no devem sempre ser incorporados nas classes de um
DW. O projetista do repositrio, o modelador e o desenvolvedor precisam trabalhar
juntos para determinar o que ser preciso incorporar em uma classe ou projeto. Adicionar
esses atributos no modelo de dados pode afetar o processo ETL, o repositrio e as
ferramentas de front-end.
99
Captulo 6: Uma Metodologia Para Implementao de um Data Warehouse
6
C A P T U L O
Uma Metodologia Para
Implementao de um
Data Warehouse
100
Por onde comeamos?. Esta uma das principais perguntas feitas pelos engenheiros
de software quando planejam implementar um DW. So vrias as opes: DW
Corporativo, DWs departamentais, DWs funcionais (marketing, f inanceiro,
administrativo), DWs para projetos especiais, etc.
Como um projeto de DW conceitualmente pressupe uma arquitetura centralizada, sua
implementao no uma tarefa fcil. A implementao de um DW completo requer uma
metodologia rigorosa e uma completa compreenso dos negcios da empresa. Esta abordagem
pode ser longa e dispendiosa e por isto sua implementao exige um planejamento bem
detalhado (em outras palavras: tempo longo). Neste contexto e com a necessidade de agilizao
de implantao dos projetos de DW, o Data Mart passou a ser uma opo de arquitetura
interessante, pois os mesmos podem ser desenvolvidos para cada rea da corporao num
processo paulatino e gradativo. Em um projeto de DW, a cada desenvolvimento de um novo
Data Mart a equipe adquire experincia e elimina os erros de implementaes anteriores.
A tecnologia usada tanto no DW como no Data Mart a mesma, as variaes que ocorrem
so mnimas, sendo em volume de dados e na complexidade de carga. A principal diferena
a de que os Data Marts so voltados somente para uma determinada rea; j o DW
voltado para os assuntos da empresa toda.
Segundo o Dr. Kimball, existem duas maneiras distintas de criao de DW: top-down e
bottom-up (Kimball, 1996).
Top-down: Uma perspectiva Top-down considera que um DW completo, centralizado
deva ser desenvolvido antes que partes dele, sumariadas, possam ser derivadas na
forma de Data Marts. A organizao cria um DW e depois parte para a segmentao,
ou seja, divide o DW em reas menores gerando assim pequenos bancos orientados
por assuntos departamentalizados.
Bottom-up: Na perspectiva Bottom-up temos uma situao inversa. A organizao,
por desconhecer a tecnologia, prefere primeiro criar um banco de dados para somente
uma rea. Com isso os custos so bem inferiores aos de um projeto de DW completo.
A partir da visualizao dos primeiros resultados parte para outra rea e assim
sucessivamente at resultar em um Data Warehouse completo.
Em ambas existem desvantagens. O desenvolvimento Top-down a partir de um DW
j existente resulta em um alto custo de implementao, complexidade na
101
modelagem e acarreta dificuldades polticas e financeiras ao decorrer do projeto.
J no desenvolvimento Bottom-up na ausncia de um DW central e coordenado, a
flexibilidade certamente no ser alcanada; alm do mais, os pr-requisitos para
desenvolver Data Marts independentes levariam estes ao uso de sistemas de
informao operacionais individuais, contradizendo com a necessidade de uma
viso mais ampla.
Como alternativa para as desvantagens apresentadas acima surgiu o conceito de Feder-
ated Data Warehouse (FDW), que busca combinar as tcnicas de desenvolvimento bot-
tom-up e top-down, enquanto diminuem os riscos de fracasso de um projeto de DW. As
idias principais so apagar o mito de que um DW til deve abranger toda a empresa e
conceber um projeto evolutivo dando enfoque inicial aos aspectos mais crticos.
Para um DW abranger toda a corporao inicialmente, a mesma deve ser totalmente
informatizada e integrada, alm do fato de o projeto ser extremamente complexo e
com alta probabilidade de insucesso. Como a integrao total rara de ser encontrada
ainda hoje, deve-se aproveitar a estrutura operacional disponvel e desenvolver um
Data Mart de cada vez.
Os resultados so atingidos em ciclos mdios de 6 meses (dependendo do tamanho da
equipe) e os Data Marts devem ser encarados de forma evolutiva, analisando-se a
complexidade do modelo, investimentos e volume de dados.
Um relevante desafio manter a coerncia entre os vrios Data Marts. Para garantir
essa coerncia, o projeto deve prever uma estrutura de metadados compartilhada,
como vimos no Captulo 5 (seo Controle de Metadados em um Projeto Evolutivo
de Contruo de DW).
Como prioridade, uma aconselhvel escolha o desenvolvimento de um Data Mart
baseado nos sistemas de informao contbeis da organizao. Sob uma perspectiva
gerencial, os dados contbeis so excelentes fontes de informaes que subsidiem os
gestores das organizaes no processo decisrio, facilitando o planejamento, controle e
avaliao de desempenho. Dados contbeis so considerados formais, cientficos e
universais, sendo portanto capazes de atender necessidade empresarial de tomada de
deciso. Alm disso, sabemos que todos os eventos e indicadores de desempenho do
negcio relevantes so registrados nos sistemas contbeis.
102
Independente do tipo de Data Mart escolhido, em cada novo ciclo, deve-se seguir uma
metodologia de desenvolvimento bem definida como veremos nas prximas sees.
Diferenas entre a Anlise Tradicional
e a Anlise de Sistemas de Apoio Deciso
Existem vrias diferenas entre a anlise tradicional de sistemas e a anlise de sistemas
de apoio deciso (SAD). Na anlise tradicional de sistemas, o objetivo documentar
todos os processos lgicos, descrevendo transformaes de dados, repositrios de dados,
e entradas e sadas externas do sistema existente para o sistema proposto.
Por outro lado, a anlise de SADs est focada na determinao de requisitos de dados e
fontes de dados de um sistema, e em documentar como extrair e disponibilizar esses
dados para os usurios finais.
A primeira diferena importante entre a anlise para sistemas OLTP e SADs est nas
descries das interfaces com os usurios. Na anlise tradicional, um cuidado especial
tomado com o mtodo atravs do qual o usurio final ir interagir com o sistema. Na
anlise de SADs, os desenvolvedores esperam que a maioria, se no todas, as consultas
feitas sejam adhoc
10
. Sendo assim, os desenvolvedores de sistemas de apoio deciso
esto mais interessados em especificar os dados para a base de informaes do que
especificar os mtodos de acessos aos dados.
Outra distino bsica entre sistemas tradicionais e sistemas de apoio deciso o objetivo
da fase de anlise. Anlises de sistemas de apoio deciso so orientadas a dados,
diferentemente de sistemas tradicionais que colocam a lgica de processo como foco
principal. Na anlise de SADs, as bases de dados fonte j existem e esto claramente
definidas. Sendo assim, os objetivos da anlise de sistemas de apoio deciso so:
compreender quais dados so de interesse dos usurios finais, como extrair esses dados
das bases operacionais e como disponibilizar essas informaes para os usurios finais.
Basicamente, a anlise de SADs envolve os seguintes processos:
10
Do latim, adhoc significa: para isto, para um determinado ato. Uma consulta adhoc feita
intuitivamente e sem planejamento, ou seja, a consulta surge por demanda.
103
Anlise de Processo: define os processos de carga e extrao.
Anlise de Fontes de Dados: descreve os itens de dados que so de interesse do usurio
final. Essa fase descreve tambm como os dados sero editados, limpados, agregados
e sumarizados.
Anlise de Carga de Dados: concentra-se em descrever como os dados sero carregados
dentro da base de dados do Data Warehouse.
Anlise de Consultas de Dados: importa em como os usurios finais iro usar os dados.
Os dois ltimos processos so de importncia significativa para uma implementao
de SAD correta.
A anlise de carga de dados envolve a compreenso de como os dados sero extrados do
sistema fonte, como esses dados sero limpos e validados e como esses dados sero
carregados, agregados e sumarizados na base de dados alvo. Nesse aspecto, a integridade
referencial pode ser utilizada para garantir que valores de dados vlidos sejam inseridos,
e para garantir que todos os relacionamentos de dados sejam mantidos. Devido ao fato
de a integridade referencial ser usada apenas nos momentos de carga e excluso, ela no
acarreta nenhum problema de desempenho para a base de dados do DW, especialmente
porque a carga, normalmente, deve ser feita em horrios fora de pico.
A anlise de consultas de dados refere-se a como os dados devem ser logicamente
armazenados para otimizar a velocidade das consultas. Nessa fase, os desenvolvedores
necessitam conhecer muito bem os tipos de consulta que os usurios finais planejam
usar. Diferentemente dos sistemas OLTP, que podem ter centenas de tipos de consultas,
praticamente todas as consultas dentro de sistemas de apoio decisio recaem em uma
das quatro categorias a seguir:
Anlise estatstica: clculos de somatrios, mdias, etc.
Anlise multivarivel: comparaes entre classes de objetos para analisar padres.
Simulao e modelagem: utilizao do SAD para validao de hipteses.
Previso: utilizar o sistema de apoio deciso para previso de valores futuros.
Essa categorizao ir ajudar a modelar os relacionamentos e entidades envolvidos no SAD.
104
Entrevistas
O conhecimento do negcio e a compreenso das necessidades de informao das diversas
reas da organizao so fundamentais para a concepo de um ambiente de suporte
deciso que permita subsidiar as atividades de controle do negcio, definio de estratgias
e elaborao de planejamento.
O ambiente de informao convencional fornece os dados que sero utilizados para gerar
as informaes disponibilizadas pelo ambiente de suporte deciso.
O levantamento da infra-estrutura de sistemas relacionada com as operaes dos clientes
deve ser feito junto a representantes da rea de tecnologia durante reunies de trabalho e
deve considerar aspectos relacionados com a infra-estrutura tecnolgica existente.
O principal objetivo da realizao de entrevistas iniciais com representantes das diversas
reas da organizao entender as caractersticas do ambiente de informao utilizado
pelas mesmas. As reunies para entrevistas devem sempre contar com uma equipe fixa,
formada por pessoas que tenham um conhecimento da organizao como um todo.
Idealmente so escolhidas duas pessoas, uma representante da rea executiva ou diretoria
e outra da rea de tecnologia da informao (TI). O importante que estas pessoas tenham
uma viso geral do negcio da corporao.
Os dados coletados devem ser consolidados para traar o perfil das necessidades que
iro nortear o planejamento do modelo para a implementao do ambiente de suporte
deciso. Dados relativos aos sistemas de informao devem ser levantados junto s equipes
de desenvolvimento e produo (TI). O foco deste levantamento deve ser a identificao
do contedo e volume das bases de dados existentes.
Finalmente, a ltima atividade da etapa de identificao do ambiente de negcios a
discusso e validao do sumrio das informaes levantadas e premissas para o modelo
com o corpo executivo da organizao.
105
Caractersticas a Serem Analisadas
no Ambiente de Informaes Existente
Disponibilidade de Informaes
Deve-se analisar o volume de informaes disponveis para os usurios finais e quais os sistemas
que as geram. Esta anlise deve averiguar a existncia de informaes que permitam a
segmentao de clientes e destacar a importncia do cadastro de todos os clientes da organizao.
Outro ponto de verificao importante a possibilidade de existncia de informaes
divergentes quando analisadas de diferentes fontes.
Acesso s Informaes Disponveis
Verificar se o acesso realizado atravs de consultas on-line e/ou relatrios e se existe
dificuldade para a obteno de informaes cruzadas (por exemplo, entre produtos x
filiais x clientes). Este fato leva um grande nmero de empresas a redigitarem em planilhas
(microinformtica) alguns dados obtidos em relatrios para a obteno da informao
desejada (ou no formato desejado).
Esta prtica aumenta o prazo da disponibilizao de informaes estratgicas para os
nveis diretivos, gerando ainda sobrecarga para muitas reas, que em algumas situaes
precisam se desviar de suas atribuies para garantir a liberao de relatrios.
Acuracidade
Extrair o sentimento dos usurios em geral (grupo de entrevistados) com relao
acuracidade das informaes obtidas. Um fator que contribui para isto a necessidade
de redigitao de dados para obteno de algumas informaes. Outro a situao tpica
de sistemas transacionais onde o momento em que a informao obtida pode influenciar
em seu valor (os dados esto corretos, mas foram obtidos em momentos diferentes, levando
a resultados igualmente diferentes).
106
Modelos de Tabelas Geradas em
Entrevistas com os Usurios e Analistas
Durante o processo de entrevistas devem ser geradas tabelas que iro identificar as
necessidades de informao relativas corporao como um todo, informaes relativas
a reas especficas e tambm necessidades comuns. A tabela da Figura 6.1 um exemplo
de como elencar as necessidades de informao (necessidades de uma cadeia de
restaurantes) e cruz-las com as reas da organizao.
Figura 6.1: Necessidades de Informao X reas.
Outra tabela importante a ser gerada a que identifica os sistemas fontes que possuem as
informaes necessrias dos usurios. A tabela da Figura 6.2 um exemplo.
Usurios internos utilizam um conjunto de aplicativos corporativos ou desenvolvidos
para a rea visando apoiar a execuo das atividades que esto sob sua responsabilidade.
107
Figura 6.2: Relacionamento entre informaes
necessrias e fontes de dados para sua gerao.
Aplicativos corporativos so responsveis pelo tratamento das transaes relacionadas
aos produtos oferecidos pela organizao. De um modo geral, eles atendem s necessidades
de informao operacional, atravs de consultas e de relatrios previamente definidos.
Aplicativos departamentais so desenvolvidos para atender as necessidades das reas
que, normalmente, esto relacionadas com controles locais ou com o tratamento de dados
gerados por vrios sistemas corporativos.
Para efeito de levantamento, devem ser considerados os aplicativos responsveis por informaes
necessrias implementao do Data Warehouse. A tabela da Figura 6.3 exemplifica como
relacionar os aplicativos avaliados. Esta avaliao deve ser composta por macrofluxo do sistema,
documentao da base de dados, caractersticas de processamento e etc.
Figura 6.3: Relao de aplicativos analisados.
As entrevistas tambm devem identificar os volumes de dados dos sistemas fontes para
fins de projeo do espao em disco que dever existir no servidor de Data Warehouse.
Os volumes devem ser obtidos a partir de dados do ambiente de produo e representar
um dia ou ms aleatrios, podendo haver desvios (a maior ou a menor) em relao ao
valor mdio. No entanto, para fins de avaliao de volume total de armazenamento em
disco necessrio, estes desvios no afetaro a ordem de grandeza da capacidade necessria.
108
Outro fato a considerar que os volumes de dados devem ser multiplicados por 3 (fator
recomendado pela maioria dos fornecedores de SGBD) para obteno da capacidade de
disco necessria para a implementao da estrutura de dados que ir suportar o Ambiente
de Suporte Deciso. A tabela da Figura 6.4 demonstra como documentar estes volumes.
Figura 6.4: Volumes identificados.
Por fim, importante gerar tabelas de disponibilidade de arquivos que ilustrem os horrios
da disponibilizao dos arquivos (ou tabelas) necessrios para a carga do Data Warehouse.
No cabealho destas tabelas podemos ter:
Horrio: Trmino do processamento.
Momento: Indica quando os dados esto disponveis (antes ou depois da execuo de
determinado programa).
Interceptar: Indica o programa que libera ou utiliza o arquivo.
Os horrios de trmino de processamento dos sistemas corporativos iro influenciar
diretamente a janela de tempo para carga de informaes no Data Warehouse, assim
como o perodo de atualizao (D-1 ou D-2), ou seja, o DW poder ter informaes
histricas atualizadas at o dia anterior ou, na pior das hipteses, at dois dias anteriores.
109
Tcnicas
Todas as tcnicas bsicas podem ser utilizadas. As entrevistas devem ser conduzidas
colocando os usurios (principalmente os gestores) como se estivessem em um ambiente
perfeito e pudessem obter todas as informaes que desejam. O objetivo extrair toda e
qualquer necessidade importante de informao gerencial. O entrevistador deve tentar
absorver destas pessoas a viso que tm em relao s tarefas que executam, o que elas
acham que devem fazer e como o fazem. Deve-se tomar cuidado com respostas agradveis,
pois muitas vezes os entrevistados do essas respostas com o intuito de auxiliar o
entrevistador e acabam mascarando alguma informao relevante.
Entrevistas eficazes dependem de uma cuidadosa preparao. Devemos comear definindo
a finalidade, identificando perguntas, fatores e informaes que faltam.
Como necessrio entrevistar vrias pessoas, a escolha das mesmas um ponto
importante. Devemos encontrar quem melhor poder responder s perguntas. Uma das
melhores maneiras investigar o organograma da empresa e identificar as pessoas
responsveis pelas reas em questo. Gerentes podem deter informaes preciosas e/
ou indicar quem poder t-las.
Ao comear as entrevistas pelos gerentes, praticamos uma tcnica poltica, pois as pessoas
hesitam menos em conceder o seu tempo se o chefe estiver a par da entrevista e a tiver
aprovado. Quando entrevistamos algum, devemos saber sua posio no organograma e
conhecer as funes bsicas de seu departamento ou de seu grupo. Entrevistadores
despreparados fazem os entrevistados (no nosso caso, pessoas cheias de tarefas) perderem
tempo e conseqentemente ficam desacreditados.
Outro fator importante o roteiro (orientao) da entrevista, deve ser planejado antes.
Devemos ter sempre em mente perguntas para dar seqncia ao assunto se houver
desvio do objetivo-chave.
A entrevista deve ser aberta com uma atmosfera descontrada para que o estabelecimento
da comunicao seja favorvel. Podemos iniciar com uma conversa sobre algo ldico,
clima e etc. Contudo, no se pode perder muito tempo com isso e deve haver um cuidado
para essa tcnica no atrapalhar a entrevista.
110
Em seguida, o entrevistador deve iniciar o processo com uma pergunta ou pedido genrico
do tipo: Por favor, explique-me este modelo de negcio. Depois de explicaes do
usurio, sempre bom resumir o que foi absorvido para verificar se a compreenso do
assunto est sendo correta, pois se houver discrepncia o entrevistado ir discordar.
Em todo o decorrer da entrevista devemos ser polticos, ou seja, evitar crticas ao ambiente
de informaes atual e manter a concentrao nas respostas, valorizando-as por mais
insignificantes que algumas possam parecer.
Finalmente, importante ter bom senso e no promover reunies muito longas, pois no final das
mesmas a produtividade baixa e usurios de Data Warehouses geralmente so ocupadssimos.
Equipe
Considerando as anlises necessrias para implementao de um Data Warehouse, a
equipe do projeto relaciona-se com usurios finais e equipes de desenvolvimento dos
sistemas legados (Figura 6.5).
Se no possvel obter as informaes sobre os dados, tambm no ser possvel construir
corretamente as referncias de metadados.
Por outro lado, a equipe tambm ter uma grande dependncia da agilidade e
disponibilidade das equipes dos sistemas legados, para obter os arquivos (ou tabelas)
extrados de acordo com os cronogramas de implementao.
ainda necessrio estabelecer acordos com os responsveis pelo planejamento da
produo, para que os arquivos (ou tabelas) sejam extrados e transmitidos para o servidor
de Data Warehouse em um tempo adequado para manter as informaes atualizadas.
Assim, fica evidente que, mesmo possuindo os conhecimentos necessrios e facilidades
de negociao, o resultado final e dirio depende de que as demais reas atuem de forma
a garantir os acordos estabelecidos. Por isso, comum que a equipe de DW esteja
subordinada a uma estrutura com poder de deciso ou de grande relacionamento com os
ambientes de desenvolvimento e produo.
Outro ponto a considerar a necessidade de relacionamento com os usurios. Alm do
perfil necessrio, a equipe (especialmente aquela voltada ao planejamento do ambiente)
111
deve ter acesso aos responsveis pelas reas usurias, para garantir um perfeito
entendimento das necessidades e, novamente, estabelecer acordo de prazos de liberao
ou de acesso s informaes.
Figura 6.5: Relacionamentos da equipe de DW
A quantidade de componentes da equipe ir variar muito, dependendo da utilizao ou no de
ferramentas que facilitem os processos. Por exemplo, a gerao e manuteno de metadados
pode ser uma tarefa muito complicada caso no haja uma ferramenta com esta finalidade.
Outra tarefa que pode ser minimizada a programao para consultas e relatrios. Se
forem utilizadas ferramentas adequadas, a equipe do projeto dever preocupar-se apenas
com o suporte ferramenta disponibilizada aos usurios, que passariam a ter a
responsabilidade sobre criar seus acessos aos dados (respeitando-se a os limites
estabelecidos pela poltica de segurana de acesso). Nossa experincia mostra que este
suporte sempre maior do que o esperado pela equipe DW. A maioria dos usurios ainda
no capaz de construir consultas intuitivamente e criar seu prprios relatrios gerenciais
de acordo com a demanda. Os usurios preferem ter uma estrutura EIS (vide Captulo 1),
ou seja, relatrios gerenciais prontos acionados via um simples boto grfico.
Equipes de Desenvolvimento
dos Sistemas Legados
Acordos para extrao de dados
Entendimentos da formao dos
dados
Usurios Finais
Entendimento de necessidades de informao
Definio de indicadores de desempenho
Definio de necessidades de acesso
Coordenadores Ambiente
de Produo
Acordos de Janela de Tempo
Acordos para processos de
transferncia de dados
Equipe DW
112
Sendo assim, ao definir a equipe, deve-se levar em conta a possibilidade da alocao
de um ou mais profissionais para construir os relatrios gerenciais solicitados pelos
usurios e posterior disponibilizao para os mesmos. Este profissional deve ser
treinado na ferramenta escolhida (OLAP, por exemplo) e ter um bom relacionamento
com a rea diretiva. Como as ferramentas no conseguem gerar consultas complexas
automaticamente, o profissional tambm deve conhecer a linguagem de consulta do
SGBD escolhido e o modelo de dados, capacitando-o para produzir consultas
complexas especficas.
A averso dos antigos gerentes aos computadores...
Vrios projetos j passaram por altos nveis de frustrao pelo pouco uso ou desuso total do DW
aps a sua implementao. incrvel, mas ainda existem diretores e gestores de empresas que
se negam a usar uma ferramenta OLAP disponibilizada e preferem continuar fazendo seus
clculos no papel ou em planilhas eletrnicas. Alm disso, ainda no comum uma cultura de
criao dos relatrios gerenciais pelos prprios diretores. Para conseguir sucesso na utilizao
do DW, deve existir uma poltica de marketing do produto, convencendo os usurios da
acuracidade e valiosidade das informaes geradas. Os mais pessimistas dizem que isso s ser
totalmente possvel quando a atual gerao de diretores aposentar-se e renovar-se com
administradores modernos e estrategistas.
O Gerenciador de Banco de Dados escolhido tambm excerce influncia, na medida em
que os SGBDs especializados possuem recursos que facilitam a implementao das
tabelas, interface com as ferramentas de acesso e etc.
Quanto organizao, a equipe poderia estar assim orientada:
Grupo de profissionais com profundos conhecimentos das necessidades dos usurios
e das ferramentas de visualizao.
Grupo de profissionais encarregado dos modelos de dados do Data Warehouse e Data
Marts, com amplos conhecimentos das estruturas de dados da organizao, assim
como do Sistema Gerenciador de Banco de Dados e demais softwares para criao e
manuteno dos repositrios de informao.
Evidentemente haver conhecimentos que devero ser compartilhados entre os dois
grupos, visando o melhor aproveitamento do ambiente.
113
Ambiente de Hardware e Software
Por questes de desempenho, o servidor de DW dever estar separado fisicamente
dos demais e, com base nos volumes identificados, possuir algumas caractersticas
importantes tais como: escalabilidade de memria, arquitetura SMP
11
(Symmetric
Multi-Processor), recursos para acesso de grandes volumes de informao
simultaneamente, etc.
Deve-se observar que a implementao de um ambiente de suporte deciso baseado em
Data Warehouse tende a aumentar significativamente o volume de dados trafegados na
rede. Desta forma, deve ser mantido um constante monitoramento deste volume atravs
de recursos de gerenciamento de rede. Este gerenciamento dever prever o momento de
congestionamento (o que provocaria aumentos indesejveis nos tempos de resposta),
permitindo que seja expandida a capacidade dos canais de alta velocidade antes da
ocorrncia de congestionamento.
Outro ponto a ressaltar que o tempo de resposta das consultas realizadas sobre um
Data Warehouse ser tambm decorrncia do volume de informaes acessadas.
Dependendo da pesquisa, o tempo de resposta poder ser de alguns minutos,
independentemente da velocidade do canal de atendimento.
Para a implementao de um DW ser necessria a utilizao de um conjunto
mnimo de softwares, composto por um Sistema Gerenciador de Banco de Dados,
software para gerao do modelo multidimensional (pode estar acoplado
ferramenta de acesso ou no) e ferramenta de acesso para os usurios f inais
(geralmente OLAP) (Figura 6.6).
Aps a existncia de um mnimo de informaes histricas, podero ser
consideradas tambm ferramentas para Data Mining e Database Marketing. Estas
ferramentas devero tambm ser analisadas, considerando-se a rapidez de
implementao destas funes.
11
SMP uma arquitetura de processamento paralelo onde um grupo de processadores trabalha
conjuntamente, sendo possvel qualquer um deles executar uma parte do programa.
114
Figura 6.6: Arquitetura bsica de hardware e software
Devido ao volume de informaes armazenadas (e investimentos necessrios em
disco), aliado ao fato de que as consultas efetuadas no caracterizam uma aplicao
de misso crtica, no necessrio o contingenciamento a partir de duplicidade dos
componentes do ambiente.
No entanto, necessrio investir em ferramentas (hardware e software) para a realizao
de backups
12
das estruturas de dados. A finalidade destes backups ser minimizar o
tempo de restaurao do ambiente, em caso de falha em qualquer um dos componentes.
Os principais SGBDs especializados em Data Warehouse possuem rotinas especficas
para este fim, permitindo backups incrementais (somente alterao), backups de estruturas,
backups de imagem de discos, etc.
Da mesma forma, os servidores especializados tambm disponibilizam estaes de salva
(robtica) visando facilitar esta atividade. Um rob pode trocar uma fita automaticamente
quando a mesma esgota sua capacidade de armazenamento, no havendo assim a
necessidade de interveno humana para continuidade do backup.
12
Backups so cpias de segurana de um sistema.
115
Durante a implementao da primeira fase de um DW, normalmente seu servidor
est totalmente dedicado s atividades de desenvolvimento e testes. No entanto, a
partir da liberao da primeira fase para os usurios finais, e por toda a vida do Data
Warehouse, os desenvolvedores necessitaro de um ambiente exclusivo para
desenvolvimento e testes, j que esta atividade incompatvel com o acesso aos
dados executado pelos usurios finais.
Dependendo do servidor contratado, poder ser feita uma expanso que ser
configurada como ambiente independente do ambiente de produo, isto , aquele
ambiente sendo utilizado para consultas.
Por outro lado, outros equipamentos no possuiro esta caracterstica, exigindo a
disponibilizao de um servidor exclusivamente para esta finalidade. Deve-se observar,
aqui, que este servidor e o SGBD utilizado devem ser totalmente compatveis com os
utilizados no ambiente principal, evitando-se assim retrabalho e dificuldades na
implementao das novas fases.
Por fim, a infra-estrutura de hardware e software disponibilizada para o DW deve possuir
as seguintes caractersticas:
Integrao com o ambiente transacional existente.
Organizao das informaes por assuntos relevantes para o negcio.
Informaes no volteis usadas como base para anlises e projees.
Interface grfica amigvel.
Disponibilidade de ferramentas de consulta de fcil utilizao e flexibilidade para
apresentao de resultados.
Dicionrio de dados (metadados) para facilitar a referncia s informaes disponveis
(Ex.: significado da informao e regras para tratamento).
Sries histricas de informaes consolidadas, com diversos nveis de agregao,
atualizadas com a periodicidade adequada para cada tipo de informao (Ex.: evoluo
diria do valor de compra de um produto).
Tratamento de informaes em diversas dimenses (Ex.: volume de vendas realizadas
por regio, por tipo de produto, por gerente, por ms).
Tratamento de grandes volumes de informaes em cada consulta.
116
Combinao de consultas predefinidas e consultas no previstas antecipadamente.
Consultas iterativas e seqenciais, com salvas intermedirias de resultados para
simplificar a lgica de tratamento da informao (Ex.: seleo de contratos com valor
superior a R$10.000, classificao por loja e subtotal por gerente de conta).
Interoperabilidade das diversas ferramentas responsveis por funes especficas (Ex.:
consulta, anlise de risco, simulaes, etc.).
Esquema de Carga
Como ferramentas ETL ainda so relativamente caras, pequenas, mdias e at mesmo
grandes empresas tendem a construir um sistema de carga prprio para o DW. Sendo assim,
descreveremos aqui os componentes bsicos que um sistema como esse deve possuir.
Praticamente todos os dados armazenados em um Data Warehouse se originam de sistemas
externos. A colocao destes dados e a preparao completa de modo a poder utiliz-los
uma das principais etapas em um Data Warehouse.
Muitas etapas so necessrias para transformar dados no processados de origem externa
em informaes prontas para serem acessadas pelo usurio final e para serem utilizadas
no processo de tomada de decises comerciais. Enumeramo-las:
Metadados precisam ser atualizados.
Os dados precisam ser lidos diretamente a partir de uma variedade de fontes, inclusive
arquivos de disco, linhas de rede, conexes de canal de mainframe e fitas magnticas.
O dados precisam ser convertidos para o formato interno do banco de dados escolhido
para o DW a partir de uma variedade de representaes externas, incluindo registros
de comprimento varivel e fixo, formatos de caracteres e binrios e etc.
Os dados precisam ser filtrados de modo a rejeitarem valores invlidos, chaves repetidas
ou registros com outros tipos de erro.
Os registros precisam ser reorganizados a partir de representaes dos Flat Files
13
de
modo a ficarem compatveis com o esquema do DW. Quando o sistema fonte utiliza
um banco de dados diferente ou imcompatvel, ou at mesmo utiliza outra estrutura de
13
Flat File um arquivo plano geralmente do tipo texto, formatado para converso de outro banco de dados. O Flat
File possui registros de tamanho nico, onde cada registro de detalhe gera uma incluso no banco de dados.
117
arquivos diferente de um SGBD, o mesmo deve gerar Flat Files com os dados a serem
carregados no DW. Explicaremos a estrutura de um Flat File adiante.
Os registros precisam ser gravados fisicamente, observando as exigncias de
configuraes para particionamento de dados, balanceamento de discos e etc.
Os registros precisam ser verificados em relao ao banco de dados existente de modo
a assegurar consistncias, mantendo uma integridade referencial completa.
Os registros precisam estar corretamente indexados.
A Figura 6.7 representa as etapas bsicas de um fluxo de carga:
Figura 6.7: Esquema bsico de carga de um Data Warehouse.
118
Uma atualizao de Data Warehouse no estar completa at que todas as etapas tenham
sido finalizadas de maneira bem-sucedida. A transmisso dos Flat Files dos computadores
em que esto instalados os sistemas legados para o servidor de DW pode ser feita de
vrias formas como via FTP (File Transfer Protocol ou protocolo de transferncia de
arquivo), por exemplo. Vale salientar que Flat Files so dispensveis em organizaes
que possuem uma estrutura unificada de banco de dados e so formados por:
Header: Primeiro registro do arquivo, que serve para identificar o mesmo. O header
armazena a data e a hora de processamento, a data de referncia, o sistema de origem
e o tipo deste arquivo que geralmente texto.
Detail: So os registros de detalhe provenientes dos sistemas legados, onde cada registro
d origem a uma linha no banco de dados.
Trailler: ltimo registro do arquivo, onde feita a totalizao de registros com o
intuito de verificar se no houve nenhum problema na transmisso do Flat File. Ao
ser dada a carga, o sistema verifica se a quantidade de registros lidos igual
especificada no trailler.
Na Staging Area (vide Captulo 2) encontram-se tabelas que so a cpia dos Flat Files e
as tabelas de violao de dados, para cada uma destas tabelas. Estas tabelas de violao
so, por sua vez, a cpia das originais mais um atributo de diagnstico. So exemplos de
tipos de diagnstico:
Violao de chave estrangeira
14
: um contrato para um cliente que no existe.
Violao de chave primria: dois produtos com o mesmo cdigo.
No repositrio ou ODS (vide Captulo 2) encontram-se tabelas de dimenso (com seus
histricos completos) e de fatos com um histrico menor. Tambm podem existir tabelas
normalizadas para validao como cargos, cidade, estado. O repositrio serve para filtrar
os dados livrando-os de inconsistncias tipo funcionrio cujo salrio igual zero.
O contedo do repositrio no igual ao do Data Warehouse. Por exemplo, os fatos
armazenados podem ser de apenas os ltimos trs meses. Muitas empresas no adotam o
14
Chave estrangeira um campo qualquer da tabela que permite representar a associao lgica entre
linhas de duas tabelas. Exemplificando, uma tabela de contratos individuais deve possuir um campo
cdigo do cliente, que representa o cliente que fez o contrato. Este tipo de campo chamado de chave
estrangeira, pois uma chave primria exportada da tabela de clientes.
119
ODS e fazem todas as verificaes de violaes de chaves e de regras de negcio na
prpria Staging Area sem armazenar histrico (Figura 6.8). O ODS traz a vantagem de
quando h problemas numa carga os dados serem recarregados novamente de banco
para banco, ou seja, j esto no formato compatvel do banco de dados do DW.
Figura 6.8: Esquema de carga de um
Data Warehouse sem ODS.
Sistema de Carga
Ao construir um Sistema de Controle de Carga o mesmo deve ser responsvel, no mnimo,
pela execuo, controle e oferta dos recursos de monitoramento dos processos de carga
no Data Warehouse. O sistema deve ser totalmente operado a partir de menus no servidor
de Data Warehouse e pode ser implementado em qualquer linguagem de programao.
120
A operao de um Sistema de Carga consiste basicamente na Montagem de uma Agenda
de Carga, Liberao da Agenda e Monitorao da Carga.
Periodicamente (diariamente, mensalmente, etc.) os arquivos (Flat Files) contendo as
informaes dos sistemas legados so enviados para o servidor de Data Warehouse. A
agenda deve ser montada para a data qual se referem os arquivos a serem carregados.
Arquivos pendentes de dias anteriores devero ser carregados antes dos arquivos do
dia. A carga deve ser dada por sistema, ou seja, todos os Flat Files de um sistema,
depois de outro e assim sucessivamente, obedecendo, para cada sistema, uma ordem
predefinida estabelecida no procedimento de carga. Idealmente, somente aps a chegada
de todos os Flat Files o processo de carga deve ser iniciado. Tambm deve ser possvel
excluir um sistema (conjunto de Flat Files) da agenda, evitando assim o carregamento
do mesmo em dias especficos. O processo como um todo consiste em carregar os Flat
Files para tabelas temporrias no banco de dados (Staging Area e ODS), e destas para
as tabelas definitivas do Data Warehouse.
Um sistema de carga deve possuir basicamente as seguintes tabelas:
Tabela de carga: contendo os sistemas que geram Flat Files para o DW, marcando a
periodicidade e a data da ltima carga.
Tabela de sistemas e seus respectivos Flat Files gerados: contendo os Flat Files que
cada sistema gera, bem como as rotinas de carga de cada um, nas diversas fases do
processo. As rotinas de carga so geralmente escritas na linguagem do banco de dados
escolhido e/ou empregando utilitrios de converso de banco de dados.
Tabela de tarefas: contm os arquivos de cada sistema que sero carregados diariamente
e a data de movimento. Tambm deve haver um campo para controlar as diversas
situaes do aquivo ou tabela, tais como: em espera, carregado na staging Area,
carregado no ODS, carregado no DW, carregado com erro e invalidado.
Tabela de dependncia de arquivos: deve conter as dependncias entre arquivos para a
seqncia correta da carga. Alguns arquivos no podem ser carregados antes de outros.
Tabela de controle de fim de carga: contm os nomes de todos os arquivos j carregados.
Para carregar os dados nas diversas camadas, o sistema dever exibir a relao de sistemas
com suas respectivas datas de processamento. O operador poder fazer alguma alterao
nas datas antes de o processo comear, montando assim a tabela de carga. A partir das
121
tabelas de carga e de sistemas montada a tabela de tarefas (to do list), ou seja, a lista de
sistemas que sero carregados no dia.
Excetuando a carga na Staging Area, onde se acrescenta o esvaziamento das tabelas
temporrias no incio do processo e ignoram-se as dependncias entre arquivos, o sistema
deve fazer basicamente o seguinte: buscar tarefas em espera, disparar as rotinas de cargas
respectivas de acordo com a dependncia entre arquivos e verificar se houve violaes.
Geralmente, as violaes so checadas pelas rotinas de carga construdas no banco de dados.
Estas rotinas geram uma exceo para o sistema de carga que fica responsvel em alertar o
operador. Aconselhamos mtodos como o envio de e-mails para os analistas responsveis.
Pontos de Verificao
Para Garantia de Qualidade
Determinadas caractersticas do ambiente de informao antes da implementao do DW
podero dificultar a implementao de alguns conceitos, frustrando expectativas. Dessa forma,
recomendamos que seja analisada a melhor alternativa para suprimir estas dificuldades.
De modo geral, as principais situaes a serem consideradas so:
Verificar se informaes significativas para os processos de segmentao de clientes
esto no cadastro e se todos os clientes possuem cadastro. Esta prtica comum em
muitas organizaes; somente fazer o cadastro quando o cliente solicita um produto que
necessita de maiores garantias. Porm, o grupo sem cadastro ficar excludo de qualquer
anlise setorial que envolva as informaes do cadastro. Num ambiente pleno de suporte
deciso toda informao que permita categorizar o cliente fundamental, seja para
planejamento de campanhas, seja para anlise da pulverizao do risco por segmento.
Verificar se informaes tpicas para segmentao de clientes fazem parte das bases
de dados de clientes da empresa. Existem informaes (tais como renda familiar,
nmero de filhos, idade dos filhos, etc.) que podem no ser trabalhadas pela organizao
em suas anlises de segmento.
Averiguar as informaes que se encontram em microcomputadores (digitadas
diretamente pelo departamento gestor da informao). Este tipo de dado de difcil
extrao para alimentao do DW. Devem ser consideradas alternativas para envio
destas informaes para sistemas corporativos.
122
Se possvel, diminuir as janelas de tempo para extraes de dados e carga no DW.
Alguns sistemas podem terminar seu processamento somente na manh seguinte
data de seu movimento, o que pode inviabilizar a manuteno do DW com informaes
em D-1 (do dia anterior). pertinente uma anlise para verificao da possibilidade
de diminuio da janela de tempo.
Um ambiente ideal de suporte deciso deveria possuir, no mnimo, as seguintes
caractersticas:
Integrao com o ambiente de dados convencional: o ambiente de suporte deciso
ser um complemento do ambiente de aplicativos convencional. As informaes
disponibilizadas pelo novo ambiente sero geradas a partir dos dados tratados pelos
sistemas aplicativos e que refletem as transaes realizadas pela organizao;
Flexibilidade para consulta de informaes e para apresentao de resultados: o
acesso s informaes dever ser interativo e flexvel, permitindo que, atravs de
comandos simples, o usurio submeta suas consultas e selecione a forma de
apresentao (relatrio colunar, grficos de diversos tipos ou uma combinao de
ambos) que melhor satisfaa suas necessidades.
Detalhamento seletivo de informaes: dever existir a possibilidade de detalhar as
informaes, partindo de um elevado grau de consolidao e podendo chegar at o
dado que as originou (Ex.: o volume de vendas de uma regional, passando pelo vol-
ume referente a um estado especfico e chegando ao volume de uma cidade selecionada).
Normalmente, este procedimento estar associado ocorrncia de distores nos
resultados esperados.
Gerenciamento por exceo: devero estar disponveis mecanismos que permitam a
gerao de avisos de alerta em caso da ocorrncia de desvios nos valores estabelecidos
para itens que foram selecionados para acompanhamento (Ex. taxa mdia de juros
praticada por uma loja, diferente daquela recomendada).
Indicadores de desempenho e ndices de gesto: devero existir indicadores que
permitam avaliar o desempenho de entidades (Ex.: volume de vendas por loja) ou de
grupos (Ex.: taxa de inadimplncia por Regional), com base em critrios previamente
definidos. Adicionalmente, devero estar disponveis ndices que permitam fazer a
gesto do negcio (Ex.: custo mdio da captao de recursos).
123
Acesso a informaes externas: o acesso a informaes externas permitir a
identificao de tendncias do mercado e a avaliao da situao da empresa perante
seus concorrentes. A identificao dos concorrentes potenciais ser feita com base no
perfil dos clientes e dos produtos oferecidos.
Modelos de simulao: devero estar disponveis ferramentas que permitam
desenvolver modelos destinados a simular a implementao das diversas alternativas
existentes e fazer a anlise comparativa dos resultados gerados por cada uma delas
(Ex.: avaliar o impacto de duas taxas de juros diferentes para a concesso de crdito;
composio da base de clientes para atingir um dado crescimento percentual).
Segurana de acesso ao ambiente: a natureza do ambiente de suporte deciso e das
informaes tratadas exigir a disponibilidade de mecanismos que assegurem o controle
de acesso de acordo com os critrios de segurana estabelecidos.
Cronograma de Implementao
A implementao de DW dever ser gradual e constituda por etapas consecutivas. Em
cada fase devero ser disponibilizadas as informaes e os recursos destinados a apoiar
as atividades de uma rea alvo.
O processo de implementao dever contemplar a adequao do ambiente de informao
convencional, com o intuito de:
Incorporar os dados tratados pelos aplicativos departamentais.
Compatibilizar o significado de um mesmo dado quando tratado por mais de um
aplicativo.
Disponibilizar os dados adicionais necessrios para gerar certos tipos de informaes
previstas pelo ambiente de suporte deciso.
O cronograma de implementao poder seguir uma abordagem interativa e incremen-
tal, ou seja, cada nova fase (ou cada novo incremento) possuir atividades em comum,
acrescentando sempre novas fontes de informao e gerando novos Data Marts.
Inicialmente, so necessrias 12 atividades, com durao total varivel e diretamente
proporcional disponibilidade de recursos humanos. Esta durao deve prever ainda a
total disponibilidade dos recursos necessrios de hardware e software.
124
O cronograma abaixo ilustra e d orientao para atividades que podem ser feitas
concomitantemente.
Figura 6.9: Cronograma de implementao.
125
Nos demais incrementos, haver uma repetio de atividades, sendo que algumas sero
bastante simplificadas. Dependendo de decises da equipe de projeto, atividades podero
ser divididas em subatividades. Assim, a durao de cada atividade ser definida de
acordo com o escopo adotado e recursos alocados.
Incrementos posteriores podem ser conduzidos resumidamente assim:
Treinamento em informtica: somente ser necessrio se includas novas ferramentas
(Data Mining, por exemplo).
Modelo lgico/fsico: necessrio pela incluso de novas estruturas de dados no novo
incremento.
Detalhar fontes e tratamento dos novos dados.
Novas rotinas de extrao.
Procedimentos de backup: apenas validar os procedimentos definidos no primeiro
incremento.
Novas estruturas de dados.
Controles de carga: adequar os controles de carga para os novos arquivos extrados e
estruturas implementadas.
Carga de dados: iniciar as cargas dirias de dados. As primeiras em situaes de teste,
validando as rotinas desenvolvidas. Recomendamos trabalhar inicialmente em ambiente
de teste (desenvolvimento).
Ferramentas para usurios: em princpio, instalar a ferramenta para novos usurios,
se houverem. Exceto se houver nova ferramenta (por exemplo, Data Mining).
Treinamento de usurios: em caso de novos usurios ou nova ferramenta, treinamento
completo. Caso sejam mantidos os mesmos usurios, dever haver apenas treinamento
esclarecendo sobre as novas informaes implementadas;
Laboratrio: com base nos novos dados carregados, acompanhar os usurios nas
primeiras consultas ao Data Warehouse.
Resumo
Ao planejarem construir um SAD as organizaes devem buscar um projeto evolutivo,
pois para um DW abranger toda corporao inicialmente, a mesma deve ser totalmente
126
informatizada e integrada, alm do fato de o projeto ser extremamente complexo e
com alta probabilidade de insucesso. Como a integrao total rara de ser encontrada
ainda hoje, deve-se aproveitar a estrutura operacional disponvel e desenvolver um
Data Mart de cada vez.
Os resultados so atingidos em ciclos mdios de 6 meses (dependendo do tamanho da
equipe) e os Data Marts devem ser encarados de forma paulatina, analisando-se
complexidade do modelo, investimentos e volume de dados.
Construir Data Marts representa seguir um linha diferente da anlise de sistemas
tradicional, pois anlises de sistemas de apoio deciso so orientadas a dados,
diferentemente de sistemas tradicionais que colocam a lgica de processo como
foco principal. Na anlise de SADs, as bases de dados fonte j existem e esto
claramente definidas. Sendo assim, os objetivos da anlise de sistemas de apoio
deciso so: compreender quais dados so de interesse dos usurios finais, como
extrair esses dados das bases operacionais e como disponibilizar essas informaes
para os usurios finais.
Enrevistas com usurios finais durante o decorrer do projeto so de grande importncia
para o entendimento das caractersticas do ambiente de informao existente. Podem ser
usadas todas as tcnicas tradicionais de entrevistas, coletando assim dados consolidados
para traar o perfil das necessidades que iro nortear o planejamento do modelo para a
implementao do ambiente de suporte deciso.
A equipe de projeto para construo do DW tem seu tamanho influenciado pela utilizao
ou no de ferramentas que facilitem todos os processos envolvidos. Independente do
tamanho, a equipe se divide em dois grupos bsicos: grupo de profissionais com profundos
conhecimentos das necessidades dos usurios e das ferramentas de visualizao e grupo
de profissionais encarregado dos modelos de dados do Data Warehouse e Data Marts,
com amplos conhecimentos das estruturas de dados.
Por questes de desempenho, o servidor de DW dever estar separado fisicamente dos
demais e com base nos volumes identificados possuir algumas caractersticas importantes,
tais como: escalabilidade de memria e recursos para acesso de grandes volumes de
informao simultaneamente. Em se tratando de software, um DW necessita de um Sistema
Gerenciador de Banco de Dados, de um software para gerao do modelo multidimen-
127
sional (pode estar acoplado ferramenta de acesso ou no) e de uma ferramenta de
acesso para os usurios finais (geralmente OLAP).
Ferramentas ETL tambm so softwares importantssimos em um processo de Data
Warehousing e pode ser vivel constru-las especificamente para cada caso. Um sistema
ETL deve ser responsvel, no mnimo, pela execuo, controle e oferta dos recursos de
monitoramento dos processos de carga no Data Warehouse. O sistema deve ser totalmente
operado a partir de menus no servidor de Data Warehouse e pode ser implementado em
qualquer linguagem de programao.
Para garantir a qualidade do DW e evitar frustraes, alguns cuidados bsicos podem
diminuir os riscos de fracasso do projeto, tais como: verificar se informaes tpicas
para segmentao de clientes fazem parte das bases de dados de clientes da empresa;
disponibilizar mecanismos que permitam a gerao de avisos de alerta em caso da
ocorrncia de desvios nos valores estabelecidos para itens que foram selecionados
para acompanhamento, etc.
O cronograma de implementao do projeto poder seguir uma abordagem interativa e
incremental, ou seja, cada nova fase (ou cada novo incremento) possuir atividades em
comum, acrescentando sempre novas fontes de informao e gerando novos Data Marts.
129
Captulo 7: Estendendo a UML Para Documentar um Data Warehouse
7
C A P T U L O
Estendendo a UML
Para Documentar um
Data Warehouse
130
Documentar um Data Warehouse significa buscar a adequao de artefatos
+
da anlise
de sistemas moderna para especificar os dados de interesse dos usurios finais, como
extrair esses dados das bases operacionais e como disponibilizar essas informaes para
estes usurios. Por questes de compatibilidade com as atuais metodologias de
desenvolvimento de software e para reaproveitar os modelos utilizados pelas ferramentas
CASE
15
, devemos buscar a utilizao da linguagem UML (Unified Modeling Language
ou linguagem de modelagem unificada) como mecanismo de representao para
especificar e documentar as diversas fases do desenvolvimento de um DW. De nada
adianta termos uma metodologia que apresenta novas simbologias e notaes que no
possuem suporte das ferramentas CASE significativas do mercado.
A linguagem de modelagem UML o resultado final da sntese de mtodos de anlise e
projeto orientados a objetos que surgiram no final dos anos 80 e incio dos anos 90.
Tendo sua primeira verso lanada em 1997, a UML representa, principalmente, a
unificao dos mtodos propostos por Booch, Rumbaugh e Jacobson. A UML, ao contrrio
de seus ancestrais diretos, no especifica um processo a ser seguido, mas limita-se a
constituir-se de uma linguagem de modelagem para visualizao, especificao,
construo, documentao e gerenciamento de sistemas de software.
Vista como padro hoje, a UML compreende uma srie de artefatos que so utilizados
para anlise de requisitos e projeto de um sistema de software. O leitor interessado
em uma documentao mais completa e especf ica deve consultar livros
especializados em UML.
Projeto Arquitetural
O projeto arquitetural visa decompor um sistema em subsistemas menores para reduzir a
complexidade do problema original. So identificadas e definidas camadas (subsistemas),
mdulos (partes de subsistemas) e interdependncias.
+
Nesse contexto, o termo artefato refere-se a um resultado tangvel de um processo de desenvolvimento. A
UML oferece uma srie de artefatos de documentao que podem ser utilizados nas diversas fases de um
processo de desenvolvimento de sistemas de software.
15
CASE - Computer Aided Software Engineering Toda ferramenta que ajude no processo de construo de
um software seja ela lgica ou fsica, documentao ou teste.
131
Uma estrutura em camadas algo desejvel em qualquer sistema, pois aumenta a
escalabilidade e reduz o escopo do problema. Uma camada um subsistema que interage
somente com uma camada vizinha. Dentro das camadas temos os mdulos (pacotes). Os
mdulos agrupam unidades funcionais (classes) que tm correlaes.
No projeto arquitetural, definem-se modelos grficos com a disposio das camadas em
sistemas computacionais. Para as camadas que esto em sistemas computacionais distintos
deve-se elucidar como feita a comunicao entre elas (ODBC
16
, etc.).
O critrio de particionamento dos subsistemas em mdulos de acordo com o nvel de
acoplamento das funcionalidades. Portanto, dentro dos mdulos as classes tm um maior
nvel de acoplamento. J o acoplamento entre as classes dos mdulos externos mais
fraco, isolando assim a complexidade. O objetivo criar uma arquitetura em que o projeto
a ser desenvolvido esteja preparado para sofrer manutenes evolutivas de forma que
uma alterao no cause problemas no esperados.
16
ODBC (Open DataBase Connectivity) uma especificao Microsoft para permitir que aplicaes Windows
acessem a mltiplos dados atravs de um mtodo simples, sem considerar os diversos formatos dos
arquivos de dados.
Figura 7.1: Projeto arquitetural de um DW.
132
Em um DW, exemplificando uma estrutura bsica sem ODS, temos uma arquitetura
distribuda, sendo composta de um repositrio de dados central (o prprio Data
Warehouse), que acessado por mquinas clientes em diversos setores da organizao,
conforme mostrado no projeto arquitetural representado pela Figura 7.1.
Documentando a arquitetura do DW possvel identificar facilmente as decises tomadas
em alto nvel, tais como: modularizao, estrutura de comunicao e controle, estratgia
de persistncia e paradigmas de bancos de dados usados. importante descrever e elucidar
o funcionamento de cada mdulo.
Documentao de Data Marts
Para cada novo Data Mart implementado, deve-se gerar um documento contendo todas
as informaes que especificam a total funcionalidade do mesmo. Podemos citar como
indispensveis em uma documentao os seguintes itens:
Objetivo do Data Mart;
Descrio do funcionamento bsico.
Viso Esttica
Em se tratando de viso esttica dos dados, importante acrescentar documentao o
modelo conceitual de dados da Staging Area e o modelo conceitual da camada de dados
(DW) propriamente dita. Alm disso, se houver, importante descrever a definio dos
Flat Files, obedecendo a uma padronizao de nome, o qual pode ser formado por um
identificador (Ex.: SRH14, onde SRH a sigla do sistema que gerou o arquivo), acrescido
da data de referncia do arquivo (Ex.: SRH1420030818).
Para as tabelas auxiliares localizadas na rea de Staging e tabelas do DW importante
descrever o objetivo de cada uma, bem como os atributos das mesmas. Para as fontes
de dados podem ser criadas tabelas associando a base de dados legada com o Flat File
gerado a partir da mesma e com o programa utilizado para gerao (vide exemplo na
tabela da Figura 7.2)
133
Figura 7.2: Bases de dados fontes
e Flat Files associados.
Viso Dinmica
Para documentao de procedimentos ou mtodos criados para efetuar carga e
transformao de dados no DW vivel descrever:
Objetivo
Parmetros
Origem de dados
Tabelas afetadas
Pseudocdigo bsico do funcionamento.
Em relao representao grfica da transformao de atributos, possvel criar, atravs
da UML, uma semntica especfica para DW como veremos a seguir:
Transformao de Atributos
Atributos podem ser transformados em outros a partir de pesquisas. Exemplificando
(vide Figura 7.3), podemos ter o atributo cd_loja, existente em tb_aux_fatos_vendas,
Figura 7.3: Representao de transformao simples de atributos.
134
transformando-se em id_dependncia, atravs de uma consulta dimenso
tb_dim_dependncia. O atributo resultante far parte da tabela tb_fatos_vendas.
Transformao de Atributos
em Mais de um Atributo
Existem situaes similares ao caso anterior onde um atributo transformado em mais de um
atributo. Nestes casos, os atributos novos podem ser representados como na Figura 7.4.
Figura 7.4: Representao da transformao em mais de um atributo.
Tabela se Transforma em Outra
sem Alterao de Atributos
Transformaes desse tipo (vide Figura 7.5) indicam que todos os atributos da primeira
tabela tambm existem na segunda.
Figura 7.5: Representao da transformao de tabelas.
135
Atributos Novos nas Tabelas
Atributos novos podem ser representados com um sinal + para indicar a adio de um
algo novo na transformao. Na Figura 7.6 os atributos id_produto e dt_inicio foram
acrescentados tabela tb_dim_produto.
Figura 7.6: Representao do surgimento
de novos atributos.
Atributos que Deixam de ser Usados
Atributos que passaro a no existir em uma tabela alvo podem ser representados com um sinal
- para indicar a excluso na transformao. Na Figura 7.7 o atributo hora no exportado.
Figura 7.7: Representao de atributos que deixam de ser usados.
Chaves Artificias
Podemos ressaltar chaves artificiais com um indicador de seqncia, seguido do rtulo
que contm o nome do atributo correspondente chave. Na Figura 7.8 o atributo
id_produto de tb_fatos_vendas uma chave artificial (vide Captulo 4).
136
Figura 7.8: Representao de chaves artificiais.
Esteretipos Para Dimenso,
Tabela de Fatos e Tabelas Auxiliares
A UML oferece um grau de liberdade para que seja possvel ajust-la a
necessidades especficas. Um esteretipo est relacionado com a introduo de novos
elementos para permitir que o usurio estenda a capacidade de modelagem da linguagem.
Figura 7.9: Representao de tabelas
auxiliares e dimenses.
137
O uso de esteretipos, no nosso caso, facilita a visualizao e entendimento das tabelas
nas suas respectivas camadas. Tabelas de dimenso podem ser representadas pelo esteretipo
<<Dimenso>> seguido de um nmero que representa o tipo da dimenso (1, 2 ou 3) (vide
Captulo 4). Tabelas auxiliares (Staging Area) e tabelas de fatos sero representadas por
<<Aux>> e <<Fato>> respectivamente. Observe no exemplo da Figura 7.9.
Hierarquias, Agregados
e Tipos de Indicadores
Tipos de indicadores podem ser representados com os smbolos (A), (N) e (S)
para caracterizar indicadores aditivos, no-aditivos e semi-aditivos respectivamente.
Figura 7.10: Representao de hierarquias, agregados e indicadores.
138
Como agregados no deixam de ser tabelas de fatos, podemos acrescentar ao esteretipo
<<Fato>> o esteretipo <<Agregado>>. Os campos utilizados para agregao podem
ser representados pela ligao das dimenses com a tabela de fatos agregada. Estas ligaes
representaram os campos de agregao utilizados. Tambm possvel especificar a funo
de agregao (vide na Figura 7.10 a funo Soma()).
As hierarquias podem ser documentadas com notas indicando os campos envolvidos e
seus respectivos nveis na mesma.
Documentao da Configurao
Fsica e de Relatrios OLAP
O gerenciamento de grandes volumes de dados causa muitos problemas
administrativos e de desempenho, o que pode ser minimizado a partir de tcnicas
como particionamento de tabelas e de ndices (vide Captulo 8). A documentao do
projeto deve especificar todas as tcnicas utilizadas, com o intuito de orientar futuras
manutenes aditivas e at corretivas.
Outro ponto de destaque na documentao de um DW a especificao dos relatrios
OLAP construdos. Na engenharia de software tradicional, se no houver uma rigorosa
poltica de gerenciamento de projeto e de processo de desenvolvimento, surgem
verdadeiros donos de programas, ou seja, softwares que s podem ser mantidos pelos
programadores que os criaram. Na construo de um ambiente de suporte deciso o
gerente de projeto deve tomar cuidado para no comearem a surgir donos de relatrios.
Alguns relatrios podem possuir caractersticas especiais e um alto nvel de complexidade,
dificultando ou impossibilitando a manuteno dos mesmos. Assim, deve existir uma
exigncia da documentao.
Quando um relatrio for construdo, deve-se elucidar o uso de comandos especficos da
linguagem de consulta (comandos que no foram gerados automaticamente pela
ferramenta OLAP) e artifcios, tais como funes e procedimentos armazenados,
construdos no SGBD, exclusivamente para dar suporte a relatrios complexos. Para
documentar estas funes e programas, pode ser utilizada a mesma estrutura apresentada
na seo Viso Dinmica, tambm utilizada para documentar procedimentos ou mtodos
criados para efetuar carga e transformao de dados no DW.
139
Resumo
Por questes de compatibilidade com as atuais metodologias de desenvolvimento de
software e para reaproveitar os modelos utilizados pelas ferramentas CASE, devemos
buscar a utilizao da linguagem UML (Unified Modeling Language ou linguagem de
modelagem unificada) como mecanismo de representao para especificar e documentar
as diversas fases do desenvolvimento de um DW.
relevante documentar a arquitetura do DW para possibilitar a fcil identificao das
decises tomadas em alto nvel, tais como: modularizao, estrutura de comunicao e
controle, estratgia de persistncia e paradigmas de banco de dados usados. importante
descrever e elucidar o funcionamento de cada mdulo.
Para cada novo Data Mart implementado, deve-se gerar um documento contendo todas
as informaes que especificam a total funcionalidade do mesmo. Com relao viso
esttica dos dados, os tradicionais artefatos UML para representao de modelos
conceituais podem ser usados para documentao do modelo de dados da Staging Area e
do modelo da camada de dados (DW) propriamente dita.
Para documentao da viso dinmica descrevemos procedimentos ou mtodos
criados para efetuar carga e transformao de dados e, em relao representao
grfica da transformao de atributos, possvel criar, atravs da UML, uma semntica
especfica para DW.
A documentao do projeto tambm deve especificar todas as tcnicas utilizadas para
otimizao fsica do DW e relatrios construdos nas ferramentas OLAP. Devemos facilitar
manutenes corretivas e aditivas no banco de dados, bem como evitar o nascimento de
donos de relatrios impossveis de serem mantidos.
141
Captulo 8: Otimizao da Configurao Fsica de um Banco de Dados...
8
C A P T U L O
Otimizao da Configurao
Fsica de um Banco de Dados
Para Data Warehouse
142
Conforme foi visto no Captulo 2, um Sistema de Suporte Deciso baseado em Data
Warehouse caracterizado pela consolidao de dados provenientes de diferentes fontes,
armazenados por longos perodos de tempo com o objetivo de fornecer informaes em
nveis estratgico e gerencial. Grande volume de dados e exigncia de desempenho em
processos de carga e processamento de consultas so, tambm, pontos que distinguem
um SAD de um Sistema de Processamento On-Line. Em funo dessas diferenas, o
projeto fsico de um Data Warehouse difere de um projeto fsico para bases de dados
operacionais, e sua perfeita criao e otimizao representam novos desafios para Analistas
e Administradores de Banco de Dados (DBAs) que, a partir de agora, precisam lidar com
esse novo tipo de aplicao.
Embora a maioria das tcnicas de projeto fsico utilizadas para Sistemas OLTP sirva
para o ambiente de Data Warehouse, elas no so suficientes para solucionar os problemas
inerentes ao volume de dados trabalhado em um Data Warehouse e atender s presses
por consultas mais rpidas. A combinao desses fatores tem contribudo, cada vez mais,
para o desenvolvimento de novas caractersticas nos SGBDs a fim de suportar as
exigncias impostas por aplicaes baseadas em DW. Em conseqncia, faz-se necessria
a reciclagem tcnica dos DBAs que passaro a ser responsveis por grandes repositrios
de dados para que os mesmos tenham conhecimento das principais tcnicas e solues
disponveis atualmente para essa nova classe de aplicao. Somente atravs dessa
conscincia, poder ser possvel desenvolver projetos fsicos que traduzam segurana,
disponibilidade e alto desempenho.
Decises de projeto fsico, a exemplo da escolha de ndices e estratgias de
particionamento, possuem profundo impacto nos processos de um ambiente de Data
Warehouse. Por esse motivo, dedicamos um captulo a esse tema, procurando abordar o
assunto da maneira mais prtica, apresentando os principais conceitos e enumerando um
check list de decises a serem tomadas em todas as fases do desenvolvimento de um
projeto de Data Warehouse.
Este captulo, portanto, possui dois principais propsitos: Prover embasamento terico
necessrio para a elaborao de um projeto fsico de dados para Data Warehouse; e
servir de base para a escolha de um SGBD que apresente caractersticas que dem suporte
criao e evoluo de um banco de dados voltado para suporte deciso. No representa
nosso objetivo substituir a experincia de um DBA, mas apontar questes cruciais que
143
devem ser conscientemente discutidas levando-se em conta os principais objetivos e
exigncias de um projeto de SAD.
Bloco de Dados
A grande maioria dos Sistemas Gerenciadores de Banco de Dados armazena seus dados
em uma unidade lgica chamada bloco de dados ou pgina. Uma tabela, por exemplo,
formada por vrios blocos que so responsveis por armazenar seus registros. Um bloco
representa a menor unidade de Entrada e Sada (E/S) para um SGBD e, geralmente,
consiste de um ou mais blocos contguos do Sistema Operacional. De maneira geral, um
bloco de dados em um SGBD dividido em trs partes distintas (Figura 8.1): Cabealho,
rea de Dados e rea Livre.
Figura 8.1: Representao genrica de um
bloco de dados em SGBDs
O cabealho armazena informaes, tais como:
Identificador do bloco.
Controle transacional.
Diretrio contendo o deslocamento de cada registro no bloco.
Indicador de tempo referente ao ltimo acesso.
Apontadores para outros blocos.
144
A rea de Dados representa o espao do bloco destinado ao armanezamento dos registros
de tabelas ou ndices. Cada registro em um bloco representado por um componente de
registro que armazena todas as informaes relacionadas a uma linha de tabela ou ndice.
Um componente de registro, por sua vez, subdividido em: Cabealho de Registro e
Informaes do Registro (Figura 8.2).
Figura 8.2: Detalhamento de
um componente de registro.
A parte Cabealho do Registro armazena informaes como:
Identificador do registro.
Nmero de colunas do registro.
Apontador para outros registros.
A parte Informaes do Registro contm as colunas do registro e seus respectivos
tamanhos, sendo essa parte a responsvel por armazenar os dados propriamente ditos.
A rea Livre representa a poro do bloco reservada para a manuteno de registros j
existentes. Quando a rea de Dados totalmente preenchida, no possvel inserir novos
registros em um bloco. A partir desse momento, a rea Livre funciona como uma reserva
de espao destinada s alteraes efetuadas nos registros do bloco. Como exemplo de
alterao, podemos imaginar um registro com uma coluna do tipo CHARACTER
145
VARYING
17
que no momento de insero encontrava-se com valor nulo e, em um dado
momento, recebeu uma cadeia de caracteres de tamanho 50. Caso no existisse essa
reserva de espao para acomodar a cadeia de caracteres inserida, um componente de
registro seria alocado em outro bloco e ocorreria o que chamamos de encadeamento de
blocos. Tal ocorrncia degrada o desempenho, pois aumenta o nmero de operaes de
E/S uma vez que para ler o registro ser necessrio acessar dois blocos de dados.
Uma vez esclarecido o conceito de bloco de dados, vamos verificar qual a influncia
desse componente no projeto fsico de um Data Warehouse.
Tamanho de Bloco de Dados
Durante a criao de um novo banco de dados o DBA precisa determinar o tamanho do
bloco de dados a ser utilizado. Tal deciso totalmente dependente das caractersticas
fsicas das tabelas do banco a ser criado e do tipo de aplicao.
Aplicaes OLTP lidam, normalmente, com conjuntos de resultado pequenos, ou seja,
poucas linhas so acessadas por vez. Logo, possuir blocos com tamanho pequeno
economiza espao em memria durante o acesso a dados. por essa razo que se
recomenda para ambientes operacionais tamanhos de bloco entre 2 e 8 Kbytes.
Data Warehouses, ao contrrio, possuem tabelas com grande nmero de colunas
(dimenses) e suas consultas resultam, em sua maioria, em grandes quantidades de
dados. A primeira caracterstica, tabelas com nmero elevado de colunas, sugere um
bloco de dados que seja suficientemente grande para acomodar um nmero razovel
de linhas, reduzindo, dessa forma, o nmero de operaes de E/S. A segunda
caracterstica, conjuntos de resultado com volume grande de dados, tambm favorece
operaes de E/S em funo do aumento no tamanho do bloco de dados. Nesse caso,
recomenda-se tamanhos de bloco entre 16 e 64 Kbytes. A Figura 8.3 apresenta a
recomendao para o tamanho de bloco a depender do tipo de aplicao. Nela, pode-se
observar que quanto mais uma aplicao aproxima-se de um Sistema de Suporte
Deciso maior deve ser o seu bloco de dados.
17
CHARACTER VARYING um tipo de dado que representa uma cadeia de caracteres de tamanho varivel.
146
Figura 8.3: Relao entre tamanho
de bloco e tipo de aplicao.
Tamanho da rea Livre
Em um ambiente OLTP, fica evidente a necessidade de certo espao reservado para a rea
Livre do bloco de dados, uma vez que os dados so bastante volteis. Porm, uma vez no
Data Warehouse, os dados no mais sofrem alteraes e suas mudanas so capturadas
atravs de novos registros. Logo, com o objetivo de economizar espao em disco e maximizar
o nmero de linhas por bloco, pode-se reservar muito pouco espao ou nenhum para a rea
Livre nos blocos de dados de um banco voltado para Data Warehouse.
Separao Fsica de Tipos de Dados
Em geral, os SGBDs apresentam um conceito, que chamaremos genericamente de
Espao de Tabela, que representa um agrupamento fsico de objetos do banco de dados.
O Espao de Tabela tem por objetivo agrupar objetos correlatos de maneira a facilitar
tarefas administrativas como manuteno e backup, evitar fragmentaes, e melhorar
o desempenho do banco atravs da reduo de conteno
18
para recursos de E/S. A
seguir, apontaremos algumas diretrizes a serem seguidas para o planejamento do lay-
out fsico do banco de dados. Embora essas diretrizes sejam comuns aos dois tipos de
aplicaes: OLTP e DW, no ambiente de Data Warehouse, em funo do volume de
dados, elas so fatores determinantes do desempenho de consultas e cruciais para as
atividades de administrao.
Como diretrizes para Espao de Tabelas, podemos apontar:
a) O banco de dados deve possuir Espaos de Tabelas diferentes para:
Objetos de dicionrio de dados
17
Nesse contexto, conteno uma espera resultante da concorrncia por recursos de Entrada e Sada.
147
Tabelas
ndices
Caso no haja mudanas estruturais, os objetos do dicionrio de dados so, relativamente,
estticos, e devem sempre estar disponveis para o perfeito funcionamento do SGBD.
Por esse motivo, deve-se evitar agrupar objetos pertencentes ao dicionrio e objetos
pertinentes s aplicaes em um nico Espao de Tabela.
Tabelas e ndices so objetos com caractersticas fsicas diferentes. ndices so objetos
volteis que tm como principal objetivo prover um caminho de acesso rpido aos dados
contidos em tabelas. Em decorrncia de operaes de insero, remoo e alterao, as
estruturas de dados que formam os ndices tendem a ficar desordenadas, necessitando de
uma reorganizao. Essa atividade de reorganizar as estruturas de dados faz com que
espaos de memria no Espao de Tabela sejam desocupados e novos espaos sejam
utilizados. Isso acarreta no aparecimento de buracos no Espao de Tabela que degradam
desempenho e minimizam a utilizao do espao livre em disco.
b) Os arquivos relacionados aos Espaos de Tabelas devem ser distribudos entre
controladoras e dispositivos de discos de modo a evitar conteno de E/S.
O dicionrio de dados, as tabelas e seus ndices correspondentes so, muitas vezes,
inseridos e lidos simultaneamente. Logo, uma distribuio de Espaos de Tabelas desses
objetos entre diferentes discos contribuir para reduo da concorrncia entre recursos
de E/S e, conseqentemente, melhor desempenho.
Devemos abusar na utilizao de espaos de tabela...
No ambiente OLTP existe uma forte tendncia por parte dos Administradores de Banco de Dados
em utilizar Espaos de Tabela para agrupar tabelas pertencentes a um mesmo sistema. Embora
essa abordagem alcance bons resultados para o ambiente operacional, ela no pode ser propagada
para o ambiente de DW. Nesse, existe a necessidade real de utilizar Espaos de Tabelas para cada
tabela de Fatos, uma vez que essas estruturas possuem caractersticas fsicas diferentes mesmo
estando vinculadas a um mesmo Data Mart. Um segundo motivo para criar uma relao de 1
para 1 entre tabela de Fatos e Espao de Tabela o volume de dados geralmente ocupado por
essas estruturas. Atravs desse isolamento, pode-se alcanar melhor desempenho e facilidade em
tarefas administrativas como backup e restaurao.
148
Particionamento
Um Data Warehouse, por definio, representa um banco de dados histrico com grande
volume de dados. Tal caracterstica traz consigo problemas relacionados ao gerenciamento
de estruturas com centenas de gigabytes e at terabytes de dados. Consideremos o seguinte
cenrio: uma tabela de fatos com, aproximadamente, 300 Gbytes de dados relativos a
uma dcada de informaes transacionais que so acessadas constantemente como
mecanismo de planejamento estratgico e gerencial.
Como otimizar consultas em estruturas de tal tamanho?
Como reconstruir ndices para uma estrutura to grande em um espao de tempo aceitvel?
Como minimizar o tempo de indisponibilidade devido necessidade de restaurar backups?
Como gerenciar rotinas de corte para eliminar dados anteriores a determinado perodo?
Como balancear E/S se uma nica estrutura ocupa centenas de Gigabytes?
Para solucionar essas questes, os SGBDs passaram a oferecer mecanismos para o suporte
a grandes estruturas de dados para sistemas de misso crtica e Data Warehouses. O
principal mecanismo oferecido, atualmente, o Particionamento. Embora os SGBDs
apresentem diferentes implementaes, todos compartilham da mesma idia: decompor
uma estrutura em estruturas menores (Figura 8.4) que possam ser mais facilmente
gerenciadas e que possam oferecer melhor desempenho. Na Figura 8.4 podemos observar
uma tabela de vendas que contm dados histricos divididos pelo ano em 11 parties.
Figura 8.4: Tabela de vendas particionada pelo atributo dt_venda.
Basicamente, existem dois tipos de mecanismos de Particionamento oferecidos pelos
atuais SGBDs que podem ser utilizados para gerenciar estruturas como uma tabela de
fatos de centenas de Gbytes: Vises Particionadas e Tabelas e ndices Particionados.
149
Vises Particionadas
Tambm conhecido com pseudoparticionamento ou particionamento manual, esse
mecanismo, ainda presente como o nico em muitos SGBDs, representou a primeira
soluo para o problema de grandes estruturas de dados. Esse tipo de particionamento
alcanado atravs de duas atividades. A primeira consiste em dividir uma tabela em
diversas tabelas com estruturas idnticas e, atravs de restries, separar os dados
pertinentes a cada uma delas. A segunda atividade a criao de uma viso de banco de
dados que faa a unio dos dados de todas as estruturas idnticas. Uma vez definida a
viso, consultas direcionadas mesma e que contenham restries no atributo de diviso,
faro referncia, apenas, s estruturas efetivamente necessrias.
Tabelas e ndices Particionados
O Particionamento de Tabelas e ndices, muitas vezes referenciado com particionamento
nativo, representa o mecanismo mais moderno de particionamento oferecido pelos
SGBDs. Nesse modelo, os SGBDs disponibilizam objetos, como tabelas e ndices, que
podem ser particionados. A vantagem desse tipo de particionamento que ele inerente
ao objeto, deixando transparente para o usurio todo o controle de separao de dados.
Vantagens do Particionamento
O Particionamento de estruturas, sejam elas tabelas ou ndices, apresenta as seguintes
vantagens:
Reduo do tempo de execuo de consultas: O Otimizador de consultas pode,
automaticamente, eliminar parties que no atendem ao critrio de consulta.
Reduo do tempo de indisponibilidade em funo de tarefas de manuteno: Algumas
tarefas de manuteno como criao e reconstruo de ndices, e eliminao de dados
referentes a determinado perodo so altamente favorecidas pelo Particionamento,
pois parties isoladas de uma tabela podem ser acessadas mesmo que outras parties
estejam indisponveis.
Reduo do tempo para execuo de backups e restaurao: Parties podem ser
armazenadas em reas de armazenamento individuais (Espaos de Tabela), o que pode
facilitar operaes de gerenciamento como backup e restaurao.
150
Desempenho de operaes de Entrada e Sada: Atravs do uso de parties possvel
balancear operaes de Entrada e Sada atravs da distribuio de parties entre
dispositivos fsicos. Pode-se, por exemplo, distribuir parties mais recentes em
dispositivos mais rpidos e mover parties com dados histricos pouco acessados
para dispositivos mais lentos.
ndices
ndices so estruturas opcionais associadas a tabelas que tm por objetivo aumentar o
desempenho da execuo de consultas. ndices para tabelas funcionam de forma
semelhante ao ndice desse livro para a busca de informaes. Alm de auxiliar na busca
de dados, ndices so os principais responsveis pela reduo de operaes de E/S.
Os dados em um DW so organizados para que possam ser acessados da forma mais
eficiente possvel, auxiliando assim o processo de tomada de deciso. Essa organizao,
traduzida pelo Star Schema (ver Captulo 4), precisa ser auxiliada por estruturas como
ndices para que seja alcanado um alto grau de desempenho na execuo de consultas.
A seguir, sero apresentados os principais tipos de ndices utilizados em bancos de dados
voltados para a atividade de suporte deciso.
ndices de rvore B
ndices de rvore B so os ndices mais comuns encontrados na maioria dos SGBDs.
Sua estrutura de dados, como o prprio nome traduz, uma rvore B, na qual os ns de
nvel mais baixo possuem os dados reais e apontadores para as linhas correspondentes.
Esse tipo de ndice, em Data Warehoses, mais apropriado para indexar chaves nicas
ou quase nicas. Logo, como direcionamento para a criao de ndices de rvore B em
um Star Schema, podemos afirmar que:
Deve-se criar um ndice para os atributos chave das dimenses.
Deve-se criar um ndice para os atributos chave da tabela de fatos.
Deve-se criar um ndice para cada atributo ou conjunto de atributos das dimenses
que sejam utilizados como restries em consultas e que apresentem alta seletividade.
151
ndices de Bitmap
Em funo da necessidade de consultas cada vez mais eficientes sob bases de dados cada
vez maiores, a indstria de SGBDs desenvolveu um tipo de ndice especialmente projetado
para atender a aplicaes baseadas em Data Warehouse. ndices de Bitmap (ou mapa de
bits) provem a mesma funcionalidade que ndices convencionais, a exemplo dos ndices
baseados em rvore B, porm utilizam uma representao interna diferente que os torna
mais rpidos e mais eficientes na economia de espao.
Para explicar e exemplificar o uso de ndices de Bitmap, vamos considerar uma tabela de
clientes que contenha os seguintes atributos: Nome, Sexo, Endereo e Regio, onde os
possveis valores para Sexo so M e F, e os possveis valores para Regio so Norte,
Nordeste e Sudeste. Utilizando os dados da Tabela 8.1, vamos criar ndices de Bitmap
para os atributos Sexo e Regio.
Nome Endereo Sexo Regio
Chris Robin Rua Jos M Norte
James Stuart Av. Joo F Sudeste
Russel Lamark Rua JK M Nordeste
Tim Tompson Rua Duque F Norte
David Av. Sabin... M Nordeste
Um ndice de Bitmap para o atributo Sexo teria dois vetores de bits, um para cada valor de
Sexo, com o comprimento igual a 5, que o nmero total de linhas da tabela (Tabela 8.2).
Valor Vetor de Bits
M 10101
F 01010
Tabela 8.2: Representao do ndice de Bitmap para o atributo Sexo.
Tabela 8.1: Tabela de Clientes.
152
Em cada vetor da Tabela 8.2, as ocorrncias do valor 1 indicam em quais registros o
valor correspondente aparece. Como exemplo, vamos examinar o vetor 10101 relacionado
ao valor M. A primeira ocorrncia do valor 1 (da esquerda para a direita) no vetor indica
que o primeiro registro da tabela contm M como valor do atributo Sexo. Em
contrapartida, a primeira ocorrncia do valor 0 indica que o segundo registro da tabela
contm F como valor do atributo Sexo.
A partir da Tabela 8.2, podemos observar que o mapa de bits criado para um atributo
composto por um vetor de bits para cada valor assumido pelo atributo, e cada vetor apresenta
um tamanho igual ao nmero de linhas da tabela. Esse mapa de bits pode ser utilizado para
responder, com alto desempenho, consultas com restries no atributo Sexo.
Vamos criar um outro ndice de Bitmap para o atributo Regio (Tabela 8.3).
Tabela 8.3: Representao do ndice de Bitmap para o atributo Regio.
Valor Vetor de Bits
Norte 10010
Nordeste 00101
Sudeste 01000
A partir de agora podemos utilizar a potencialidade dos ndices de Bitmap para responder
questes do tipo: Quais os clientes do Sexo Masculino que vivem na regio Nordeste?
Para responder a consulta anterior, o primeiro passo encontrarmos o vetor de bits que
representa o Sexo Masculino: 10101, e o vetor de bits que representa a regio Nordeste:
00101. O segundo passo executar a operao AND bit a bit dos dois vetores: 10101
AND 00101 = 00101. O vetor de bits resultante, 00101, representa resposta nossa
consulta. Nele, podemos observar que os registros de nmeros 3 e 5 so os que satisfazem
nossas restries (Tabela 8.4).
153
Tabela 8.4: Resultado da consulta utilizando ndices de Bitmap.
Uma vez entendido o funcionamento dos ndices de Bitmap, podemos apontar suas
principais vantagens:
Operaes envolvendo comparaes, junes e agregaes so reduzidas aritmtica
binria com uma melhoria dramtica no tempo de processamento.
Reduo substancial do espao utilizado comparado a outras tcnicas de indexao.
Ganho dramtico de desempenho mesmo para equipamentos com nmero relativamente
pequeno de CPUs e pouca quantidade de memria.
Carregamento de Dados Para
o Data Warehouse
Ao iniciar as cargas de um DW, administradores de bancos de dados podem se deparar
(dependendo do volume de dados) com um longo tempo para finalizao diria das
mesmas. Com o andamento do projeto, logo surge a seguinte pergunta: Como posso
diminuir o tempo de carga dos dados para o Data Warehouse?
Nessa seo, recomendaremos uma srie de medidas que podem ser utilizadas para
aumentar o desempenho da carga de dados para uma rea de Staging no ambiente de
Data Warehouse.
Emprego de utilitrios para leitura de Flat Files: Considere o emprego de utilitrios
de carga oferecidos pelos SGBDs. Esses utilitrios apresentam excelente desempenho
para a leitura de Flat Files, podendo carregar milhares de registros por segundo.
Nome Endereo Sexo Regio
Chris Robin Rua Jos M Norte
James Stuart Av. Joo F Sudeste
Russel Lamark Rua JK M Nordeste
Tim Tompson Rua Duque F Norte
David Av. Sabin... M Nordeste
154
Desabilitar ndices: Ao carregar os Flat Files os ndices necessrios para operaes
posteriores de transformao podem ser desabilitados, aumentando o desempenho da
carga. Vale ressaltar que estamos nos referindo apenas aos ndices das tabelas da Stag-
ing Area.
Desabilitar log: Ao efetuarmos uma carga com problemas, corrigimos o erro e
executamos a carga novamente, ou seja, no existe a necessidade de um controle
transacional. Assim, podemos desabilitar mecanismos para recuperao de dados tais
como arquivos de log utilizados para desfazer alteraes ocorridas, pois estes
mecanismos retardam o processo de incluso de dados no DW medida em que
registram todas as inseres ocorridas.
Habilitar diretiva APPEND para insero de dados em blocos de dados vazios: Alguns
SGBDs possuem uma diretiva de insero, comumente chamada de APPEND, que faz
com que novos registros sejam inseridos no ltimo bloco fsico onde se encontram os
dados da tabela, ou seja, os novos registros sero inseridos no bloco seguinte ao usado
pela ltima vez. Por exemplo, se uma tabela usa 20 blocos no banco de dados, ento
uma insero que use a diretiva APPEND dever iniciar a gravao destes novos
registros no 21 bloco. Isto aumenta o desempenho da carga, pois os processos que
controlam a insero no precisam procurar por espaos vazios nos blocos j utilizados.
Resumo
Embora a maioria das tcnicas de projeto fsico utilizadas para Sistemas OLTP sirva
para o ambiente de Data Warehouse, elas no so suficientes para solucionar os problemas
inerentes ao volume de dados trabalhado em um Data Warehouse e atender s presses
por consultas mais rpidas. A combinao desses fatores tem contribudo, cada vez mais,
para o desenvolvimento de novas caractersticas nos SGBDs a fim de suportar as
exigncias impostas por aplicaes baseadas em DW.
Decises de projeto fsico, a exemplo da escolha de ndices e estratgias de
particionamento, possuem profundo impacto nos processos de um ambiente de Data
Warehouse. Resumiremos estas decises a seguir:
Blocos de dados: so recomendados tamanhos entre 16 e 64 Kbytes.
Tamanho de rea livre: pode-se reservar muito pouco espao ou nenhum para a rea
Livre nos blocos de dados de um banco voltado para Data Warehouse.
155
Espaos de tabelas: o banco de dados deve possuir Espaos de Tabelas diferentes para
objetos de dicionrio de dados, tabelas e ndices.
Particionamento: devemos particionar tabelas e ndices para alcanarmos os seguintes
objetivos:
Reduo do tempo de execuo de consultas.
Reduo do tempo de indisponibilidade em funo de tarefas de manuteno.
Reduo do tempo para execuo de backups e restaurao.
Melhorar desempenho de operaes de Entrada e Sada.
Uso de ndices: Os dados em um DW so organizados para que possam ser acessados
da forma mais eficiente possvel, auxiliando assim o processo de tomada de deciso.
Essa organizao, traduzida pelo Star Schema, precisa ser auxiliada por estruturas
como ndices para que seja alcanado um alto grau de desempenho na execuo de
consultas.
Carregamento de dados para o DW: uma srie de medidas pode ser utilizada para
aumentar o desempenho da carga de dados para uma rea de Staging no ambiente de
Data Warehouse. So elas:
Emprego de utilitrios para leitura de Flat Files.
Desabilitar ndices de tabelas auxiliares da Staging Area.
Desabilitar log.
Habilitar diretiva APPEND para insero de dados em blocos de dados vazios.
157
Captulo 9: Data Mining e a Descoberta de Informaes Para Alavancagem do Negcio
9
C A P T U L O
Data Mining e a Descoberta
de Informaes Para Alavancagem
do Negcio
158
Como vimos anteriormente, a recente exploso da informao e a disponibilidade de
meios de armazenamento a um baixo custo tem tornado possvel coletar dados
maciamente durante as ltimas dcadas.
Ao mesmo tempo, a forma de interao entre as empresas e seus clientes tem mudado de
forma drstica. Os vendedores de hoje encaram uma situao muito complexa, com uma
variedade enorme de produtos e, conseqentemente, maior concorrncia. A continuidade
dos negcios com o cliente no est mais garantida e lealdade coisa do passado. Os
clientes esto aumentando o seu nvel de exigncia e querem coisas que vo ao encontro
de suas exatas necessidades.
Como resultado destas profundas mudanas, as empresas tm descoberto que precisam
entender melhor seus clientes, dando respostas s suas vontades e necessidades de forma
gil, sem esperar que os sinais de insatisfao sejam bvios para se tomar as aes. Para
ter sucesso, as organizaes devem ser proativas e antecipar os desejos dos clientes.
Todo este cenrio faz surgir a necessidade de novas estratgias de negcio e os tomadores
de deciso modernos precisam de ferramentas para enfrentar as profundas mudanas.
Uma das vantagens da coleta intensiva de dados o uso destas informaes para ganhar
vantagens competitivas. O objetivo passa a ser, atravs da anlise de dados, guiar o processo
de tomada de deciso.
Tcnicas de Minerao de Dados (em ingls, Data Mining) podem ajudar a resolver
temas delicados de interaes com clientes. Entretanto, importante frisar que Data
Mining somente uma parte de todo o processo de explorao da informao, e precisa-
se trabalhar com outras tecnologias (por exemplo, Data Warehouse e automao de mar-
keting), bem como com as prticas de negcio j estabelecidas.
Minerao de Dados: Alguns Conceitos
Tcnicas e ferramentas que ajudam a explorar os dados em busca de informaes valiosas
comearam a surgir e visam descobrir tendncias ou padres (patterns) conhecimento
em dados. Um conhecimento descoberto pode ser utilizado como uma previso a respeito
de dados futuros, que, dentro de uma margem de erro quantificada, continuariam seguindo
159
o mesmo padro. importante, no entanto, que os padres descobertos sejam realmente
teis, no podendo ser nem bvios e nem desinteressantes.
Dentro deste contexto, surgiu um conjunto de tecnologias conhecido por Minerao de
Dados que consiste basicamente em, utilizando uma das vrias tcnicas disponveis,
extrair de grandes bases de dados da organizao informaes teis e relevantes para a
tomada de deciso.
Afinal, o que Data Mining?
Definindo de forma simples, Data Mining automatiza a deteco de padres relevantes em um
banco de dados. Por exemplo, um padro poderia indicar que homens casados com crianas tm
duas vezes mais chances de dirigir um carro esporte especfico do que homens casados sem
crianas. Para um gerente de marketing de uma indstria automobilstica, esse padro
surpreendente poderia ser bastante valioso.
Minerao de Dados consiste em utilizar tcnicas de estatstica e de inteligncia artifi-
cial bem estabelecidas para construir modelos que predizem o comportamento do
cliente. Hoje, a tecnologia automatiza os processos de busca e os integra com os Data
Warehouses comerciais, apresentando os resultados de uma maneira interessante aos
usurios. Depois disto, analistas de negcio devem avaliar os modelos e validar a
relevncia das predies realizadas.
Diferentemente das tradicionais consultas a bancos de dados com SQL
1 9
, nas quais deve
ser explicitado tudo o que se deseja obter, um algoritmo de minerao de dados capaz
de descobrir informaes escondidas do usurio. Neste ponto, podemos voltar ao
clssico exemplo das fraldas e da cerveja (Captulo 1): a venda associada destes dois
produtos s poderia ser descoberta, sem o auxlio de tcnicas de minerao, atravs de
uma consulta explcita ao banco de dados, na qual deveria ser especificado que o inter-
esse era verificar em quantas transaes do supermercado os produtos apareceram jun-
tos. fcil perceber que isto no seria nada intuitivo, visto que difcil imaginar que
possa haver alguma associao na venda dos dois itens. Um algoritmo de Minerao de
Dados deve ser capaz por si s de descobrir padres como este.
19
Structured Query Language - Linguagem de consulta a bancos de dados.
160
importante frisar que Minerao de Dados apenas uma das etapas do chamado Processo
de Descoberta de Conhecimento em Bancos de Dados (KDD Knowledge Discovery in
Databases), explicado na seo O Processo de Descoberta do Conhecimento.
O Diferencial das Tcnicas de Data Mining
O resultado da utilizao de Data Mining diferente de outros processos de negcio baseados
em dados. Na maioria das tcnicas de explorao dos dados, os resultados apresentados so
coisas j conhecidas. Por exemplo, um relatrio mostrando a diminuio das vendas de certa
linha de produtos em uma regio pode ser direto para o usurio porque ele intuitivamente sabe
que esse tipo de informao j existe no banco de dados.
Tcnicas de Data Mining, por outro lado, extraem informao til, valiosa e previamente
desconhecida.
Para entendermos ainda mais a importncia das tcnicas de minerao, imaginemos um
gerente de marketing de uma empresa de telefonia regional, responsvel pelo
gerenciamento dos relacionamentos com os clientes de telefonia celular da empresa.
Uma de suas atuais preocupaes a perda de clientes (conhecida como churn).
preciso encontrar uma maneira de manter o cliente, para no ter que precisar tentar traz-
lo de volta no futuro, o que pode ser uma tarefa muito mais difcil.
A tradicional abordagem para resolver este problema escolher alguns clientes e tentar
convenc-los a assinar um plano por mais algum tempo de servio. Esta tentativa poderia
envolver algum tipo de brinde ou talvez um desconto no plano tarifrio. O problema,
entretanto, descobrir quais clientes deveriam ser includos nesta soluo. Por exemplo,
um cliente que utiliza as funcionalidades topo de linha dos aparelhos e sempre contrata
servios especiais pode querer um novo aparelho, ainda mais moderno, ou outro brinde
para manter-se fiel por mais outro ano. A chave determinar com qual tipo de cliente a
empresa est lidando. Neste ponto, as tcnicas de Minerao de Dados so empregadas
como auxlio a uma das tarefas mais rduas: traar o perfil dos clientes que devem ser
encaixados em determinadas estratgias.
A seguir, trataremos inicialmente das fases do processo de KDD e ressaltamos como
tcnicas de minerao podem ser teis ao serem utilizadas em conjunto com CRM e
161
Database Marketing (ver Captulo 3). Depois disto, sero apresentadas duas das mais
disseminadas tcnicas de minerao de dados. O tpico seguinte explica em detalhes um
algoritmo de minerao bastante disseminado. Finalmente so tratadas questes de
integrao de Data Mining e Sistemas Gerenciadores de Banco de Dados.
O Processo de Descoberta
do Conhecimento
O processo de descoberta de conhecimento envolve vrias fases, mostradas na Figura 9.1.
O objetivo extrair de grandes bases de dados, sem nenhuma formulao prvia de hipteses,
informaes desconhecidas, vlidas e acionveis, teis para a tomada de deciso.
De forma breve, o processo envolve trs etapas iniciais: seleo, pr-processamento e
transformao, as quais compem o que denominado de preparao dos dados. Em
seguida vem a fase de Minerao de Dados, corao do processo e foco principal deste
captulo. Por fim, o conhecimento gerado dever ser analisado, o que acontece na etapa
de anlise e assimilao dos resultados.
Figura 9.1: Etapas de um processo de KDD.
162
Preparao dos Dados
Esta fase compreende trs etapas menores, explicadas a seguir:
Seleo de Dados: nesta etapa devero ser identificadas as bases de dados a serem
utilizadas para a descoberta de conhecimento, levando-se em considerao os objetivos
do processo. Por exemplo, caso o objetivo seja descobrir associao entre itens vendidos,
a base de dados que armazena as transaes do supermercado ser a escolhida.
Pr-processamento de Dados: como a informao pode vir de vrias bases distintas,
alguns problemas de integrao devem ser resolvidos, o que ser feito nesta etapa.
Exemplificando, suponha que a informao sobre o sexo do cliente esteja armazenada
em uma base como M e F e, em outra, como H e M, ou 0 e 1. Assim, ser
necessrio um tratamento especial nos dados. Outro bom exemplo o caso em que se
deseja trabalhar com idades dos clientes, mas esta informao est em forma de data
de nascimento, o que obriga a realizao de um pr-processamento sobre tais dados.
Desta forma, a etapa resume-se em resolver inconsistncias, problemas de integrao
e adaptao dos dados ao formato desejado.
Transformao de Dados: o objetivo desta etapa transformar os dados pr-
processados, de modo a torn-los compatveis com as entradas dos diversos algoritmos
de minerao existentes.
Minerao de Dados: Esta fase o corao do processo e caracteriza-se pela escolha
e aplicao da tcnica e do algoritmo de minerao. Entre as principais tcnicas podem
ser destacadas: Regras de Associao, Classificao e Agrupamento (Clustering),
cada uma podendo envolver um ou mais algoritmos.
Anlise e Assimilao dos Resultados: Nesta etapa o conhecimento gerado deve ser
analisado de maneira a verificar se realmente til tomada de deciso. Se a resposta
no for satisfatria, ento ser necessrio repetir todo ou parte do processo de KDD.
importante frisar que o processo interativo e semi-automtico, isto porque
indispensvel a interao com o usurio, que participar desde a definio dos dados a
serem analisados, at a anlise do conhecimento gerado, de maneira a verificar se este
realmente til e previamente desconhecido. Alm disso, se a empresa j possui um banco
de dados integrado como, por exemplo, um Data Warehouse, precisar apenas aproveitar
a estrutura existente e explorar os dados atravs de um algoritmo de minerao.
163
Data Mining e Customer
Relationship Management (CRM)
Customer Relationship Management (ver Captulo 3) um processo que gerencia as
interaes entre a empresa e seus clientes. Os usurios primrios das aplicaes de CRM
so o pessoal de Banco de Dados e de Marketing, que procuram automatizar os processos
de interao com os clientes. necessrio para estas equipes a identificao de segmentos
contendo clientes com alto potencial de lucro. A partir da, so construdas e executadas
campanhas que impactam favoravelmente o comportamento desses clientes.
Segmentar clientes e traar seus perfis requer uma quantidade significativa de dados
sobre os mesmos e seus comportamentos de compra. Entretanto, o armazenamento
massivo de dados torna difcil filtrar a base em busca das informaes valiosas. Desta
forma, as aplicaes de Data Mining tm servido para automatizar os processos de procura
nas montanhas de dados de maneira a encontrar padres que sejam bons preditores de
comportamentos de compra. Depois disso, providncias so tomadas levando em
considerao os segmentos de mercado definidos.
Como o Data Mining
Ajuda o Database Marketing
O Database Marketing (ver Captulo 3) habilita as empresas a enviar, no momento correto,
pertinentes e coordenadas mensagens e propostas de valor (ofertas ou brindes valiosos)
para clientes efetivos e em potencial. Por exemplo, para persuadir clientes a manterem seu
dinheiro no banco, gerentes podem identificar imediatamente os grandes depsitos e produzir
uma resposta rpida. O sistema deve automaticamente agendar uma mala direta ou promoo
de telemarketing assim que o saldo do cliente exceda uma quantia predeterminada. Baseado
no tamanho do depsito, a promoo engatilhada pode, ento, prover um incentivo
apropriado que encoraje o cliente a investir seu dinheiro em outros produtos do banco.
As tcnicas de minerao de dados ajudam os usurios de Marketing a focar campanhas
de maneira mais precisa e tambm a alinhar as necessidades, desejos e atitudes de clientes.
Se a informao necessria existe no banco de dados, o processo de Data Mining pode
modelar virtualmente qualquer atividade do cliente. A chave encontrar padres relevantes
para problemas correntes de negcio.
164
Algumas questes tpicas de que as tcnicas de Data Mining tratam podem incluir
respostas a difceis questes, como:
Quais clientes so mais provveis de adquirir um determinado produto?
Qual a probabilidade de um cliente comprar um valor predeterminado de mercadoria
atravs de um catlogo enviado pelo correio?
Qual a probabilidade de o cliente adquirir certos produtos juntos?
Qual o impacto sobre as vendas de uma determinada empresa caso ela deixe de
comercializar determinado produto?
Qual o produto mais indicado para um determinado perfil de cliente?
Respostas a essas questes podem ajudar a reter clientes e aumentar as taxas de respostas
de campanhas, que, em seguida, aumentam as compras, vendas amarradas e retorno de
investimentos.
Algumas reas de Aplicaes Potenciais
Tcnicas de Data Mining podem ser utilizadas nas mais diversas reas. Sem a inteno de
esgotar as possibilidades, mas com intuito de destacar algumas aplicaes importantes,
minerao de dados pode ser utilizada em segmentos como:
Vendas e Marketing: ajuda a identificar padres de comportamento de consumidores; associar
comportamentos a caractersticas demogrficas; ajuda a definir campanhas de marketing direto e
fidelizar clientes.
Bancos: a tcnica ajuda a identificar padres de fraudes (cartes de crdito); identificar
caractersticas de correntistas; minimizar prejuzos atravs de crdito a clientes.
Mdica: identificar comportamento de pacientes, terapias de sucessos para diferentes tratamentos,
fraudes em planos de sade e planos diferenciados por perfil do paciente.
Principais Tcnicas
de Minerao de Dados
Existem vrios modelos de descoberta de padro ou de conhecimento. A escolha de um
modelo juntamente com um algoritmo que extrai conhecimento segundo o modelo
165
depende de um problema particular. Cada um dos modelos apresenta o conhecimento
descoberto em uma forma geralmente de fcil entendimento e anlise.
Dois modelos bem disseminados so Classificao e Regras de Associao, explicados
nas sees Classificao e Regras de Associao, respectivamente.
Classificao
O objetivo desta tcnica a organizao de dados em classes, baseando-se em propriedades
(atributos) comuns entre um conjunto de objetos em uma base de dados.
Como bons exemplos de aplicabilidade podemos citar: diagnstico mdico, visando
classificar os pacientes, baseando-se em caractersticas e sintomas, e facilitando o
tratamento; avaliao de risco de crdito, tentando descobrir a probabilidade de prejuzos
por classe de clientes.
As abordagens de classificao normalmente usam um conjunto de treinamento em que
todos os objetos esto j associados a determinadas classes. Um algoritmo de classificao
aprende regras de classificao do conjunto de treinamento. Um conjunto de testes analisa
se as classificaes pelo algoritmo batem com as classes reais dos objetos, o que
denominado classificao supervisionada. O modelo aprovado ento usado para
classificar novos objetos.
Um algoritmo de classificao pode apresentar o resultado sob a forma de rvore de
deciso, como parcialmente apresentado na Figura 9.2. Nela, as pessoas so classificadas
em confiveis ou no confiveis para a concesso de crdito, baseando-se no grau de
escolaridade e na faixa de renda anual.
A interpretao de um dos galhos que uma pessoa que possui mestrado e ganha acima
de dez mil reais por ano paga seus emprstimos, sendo, portanto, classificada como uma
pessoa confivel. J uma pessoa com o ttulo de mestrado e com uma renda anual menor
que 10 mil reais no confivel para se conceder um emprstimo. Tal conhecimento
extrado da massa de dados de uma empresa permite ao gerente, por exemplo, tomar a
deciso de fazer novos emprstimos com uma maior segurana.
166
Figura 9.2: rvore de deciso.
Os ramos da rvore podem crescer de maneira diferente. Isto pode ocorrer porque, por
exemplo, para um determinado grau de escolaridade como o 1 grau, possvel que no
existam emprstimos realizados a clientes com tal atributo. Alm disso, todas as regras
geradas a partir de uma rvore tero que conter o atributo raiz em seu antecedente. No
exemplo, como o grau de escolaridade o atributo raiz escolhido, no h como se ter
uma regra do tipo: Se Ra > 50 ento confivel.
Existem alguns algoritmos de classificao que, ao invs de montarem uma rvore de
deciso, expressam o conhecimento extrado atravs de regras do tipo Se condio ento
classe ou X, Y Z, chamadas simplesmente de Regras de Classificao. Cada galho
de uma rvore de classificao representa uma regra. A seguir, so exemplificadas as
mesmas regras da Figura 9.2, sob a forma de regras de classificao:
... Se (Grau de Escolaridade = Mestrado), (Ra <= 10) no confivel
Se (Grau de Escolaridade = Mestrado), (10 < Ra <= 50) confivel
Se (Grau de Escolaridade = Mestrado), (Ra > 50) confivel...
Concluindo, uma regra de classificao ter sempre no seu conseqente uma resposta ao
fato de as condies satisfazerem ou no a uma determinada classe previamente definida.
Uma outra tcnica de Minerao de Dados o Agrupamento ou Clustering. Como a
classificao supervisionada, agrupamento a organizao de uma base de dados em
167
classes. Entretanto, diferentemente de classificao supervisionada, as classes no so
definidas previamente, cabendo ao algoritmo defini-las dinamicamente, o que podemos
denominar de classificao no supervisionada.
Regras de Associao
Entre os diversos modelos de conhecimento, aqueles que geram regras de associao so
bastante poderosos e flexveis, alm de provavelmente serem os mais usados em problemas
prticos. A tcnica tem sido intensamente pesquisada e seu principal objetivo realizar
associaes entre os itens, com o intuito de estabelecer correlaes entre eles.
Um bom exemplo verificar quais produtos costumam ser colocados juntos em um
carrinho de supermercado, e da surgiu o termo Anlise de Market Basket. As
cadeias de varejo usam associao para planejar a disposio dos produtos nas
prateleiras das lojas ou em um catlogo, de modo que os itens geralmente adquiridos
na mesma compra sejam vistos prximos entre si ou agrupados em uma promoo.
Aqui podemos recordar mais uma vez o clssico exemplo da rede de supermercados
americana (Captulo 1). A descoberta de que o aumento do consumo de fraldas
infantis nas tardes de sexta-feira tambm causava o aumento do consumo de cerveja
no de modo algum trivial e invivel de ser descoberta a partir de uma inspeo
manual ao banco de dados. O ramo de livraria tambm tem utilizado esta tcnica
com freqncia para descobrir quais ttulos so geralmente adquiridos juntos. A
partir da, o cliente pode ser sugerido a comprar novos exemplares, promoes podem
ser modeladas, etc.
Formalmente uma regra de associao definida como:
Se X ento Y ou X Y, onde X e Y so conjuntos de termos e X Y = .
Diz-se que X o antecedente da regra, enquanto Y o seu conseqente. Uma regra pode
ter vrios itens tanto no antecedente quanto no conseqente. Um algoritmo baseado em
regras de associao consiste em descobrir regras desse tipo entre os dados preparados
para a minerao. A seguir, um exemplo prtico de regra de associao:
{Po} {Leite, Manteiga}
168
A regra pode ser lida da seguinte forma: Se Po, ento Leite e Manteiga. Isto indica
que clientes compraram os itens Po, Leite e Manteiga juntos. Alm disso, em muitas
compras onde aparecia o produto Po, os itens Leite e Manteiga tambm foram vendidos.
Podemos perceber que uma regra de associao ento uma regra de classificao
generalizada. A generalizao consiste no fato de que Y, o conseqente na regra de
associao, uma conjuno de termos com quaisquer atributos, enquanto que, nas regras
de classificao, este s um termo envolvendo unicamente o atributo de classificao.
importante salientar que um algoritmo de regras de associao pode gerar uma exploso
de regras, uma vez que muitas combinaes de itens so possveis. Para evit-la, dois
parmetros so passados para o algoritmo: suporte mnimo e confiana mnima. O suporte
visa calcular com que freqncia os itens que compem a regra apareceram juntos na
base de transaes. J a confiana tem o objetivo de descobrir a correlao entre o
antecedente e o conseqente: quanto mais forte a correlao, mais expressiva ou mais
confivel a regra. As definies de suporte e confiana so mostradas formalmente nas
Figuras 9.3 e 9.4, respectivamente. Em seguida, estes parmetros so mais bem detalhados.
Para uma base de dados T, o suporte de um conjunto de itens X o percentual de transaes
que verifica X, conforme Figura 9.3:
Figura 9.3: Definio do suporte de uma regra.
A definio formal de confiana trazida na Figura 9.4, onde X denota o antecedente e
Y o conseqente da regra:
Figura 9.4: Definio da confiana de uma regra
Para entender como estas medidas funcionam, veja a Tabela 9.1, que representa dados de
uma mercearia para minerao. A primeira coluna indica o cdigo da transao e as demais,
169
os itens ou produtos de venda. Cada linha representa uma transao feita para um cliente e
identificada a partir do identificador de transao. Se um cliente comprou um item, o
valor da coluna correspondendo ao item 1, e caso contrrio, 0. Por exemplo, a primeira
transao indica que um cliente comprou leite e manteiga, mas no comprou po.
Tabela 9.1 Transaes de vendas de uma mercearia.
Transao Leite Manteiga Po
1 1 1 0
2 1 0 1
3 1 1 1
4 1 1 1
5 0 1 1
6 1 1 1
7 1 1 1
8 1 0 1
9 1 1 1
10 1 1 1
Considere a regra:
{po, leite} {manteiga} /* Se po e leite ento manteiga */
Pode-se constatar que os itens Po, Leite e Manteiga foram comprados juntos em 6 das
10 transaes da Tabela 9.1. Podemos dizer ento que a regra tem suporte (coverage)
de 0,60 (6/10) ou 60%. Por outro lado, o antecedente aparece em 8 transaes; destas 8,
6 contm o conseqente. Desta forma a confiana da regra de 0,75 (6/8) ou 75%.
Os valores de suporte e conf iana devem ser passados para o algoritmo de
minerao. Desta forma, o usurio poder aumentar ou diminuir o nmero de regras
geradas. Sintetizando, o objetivo procurar regras expressivas, aquelas que
satisfazem as duas condies:
170
freqente, ou seja, tem suporte acima de um mnimo considerado aceitvel.
a correlao entre antecedente e conseqente, medida pela confiana, forte ou acima
de um mnimo considerado aceitvel.
A representao completa da regra ento:
{po, leite} {manteiga} [0,60 0,75]
Que lida assim: 60% dos clientes compraram po, leite e manteiga; 75% dos clientes
que compraram po e leite tambm compraram manteiga.
Utilizando o exemplo da mercearia, algumas perguntas podem ser respondidas a partir
dessas regras como: Quais regras possuem po como antecedente? Isso pode ajudar a
entender, por exemplo, que itens podero ter suas vendas influenciadas caso o
estabelecimento deixe de vender po. Outra pergunta pode ser: Quais regras possuem
manteiga como conseqente? Essa informao uma maneira de descobrir como aumentar
as vendas deste produto atravs de sua comercializao associada a outros produtos.
Para se ter uma idia, tcnicas de minerao de dados, ainda no contexto da mercearia,
podem levar a concluses como qual a melhor organizao das prateleiras, de maneira
que produtos que geralmente so comprados juntos sejam disponibilizados tambm jun-
tos para os clientes, estimulando um possvel aumento nas vendas.
Voltamos a frisar que, diferentemente das tradicionais consultas a bancos de dados nas quais
o usurio expressa exatamente tudo o que quer consultar e como os resultados devem ser
apresentados (o que aqui chamamos de consulta fechada), um algoritmo de minerao de
dados capaz de descobrir informaes escondidas na massa de dados (consulta aberta).
Exemplificando, para descobrir quantas transaes tiveram dois produtos quaisquer associados,
a consulta precisaria ser escrita explicitamente. Com a utilizao de um algoritmo de minerao,
o mximo que precisa ser feito especificar o tipo de tcnica que dever ser utilizada; neste
caso, regras de associao. O algoritmo seria ento executado recebendo os valores de suporte
e confiana mnimos e todas as possveis associaes de itens (regras) so geradas
automaticamente, sem necessidade de especificao de nenhuma consulta prvia.
Aqui devemos lembrar que o objetivo dos algoritmos de minerao descobrir
informaes no previstas. fcil perceber que a venda de po geralmente est associada
de leite, por exemplo. Entretanto, muito dificilmente um gerente de um supermercado
171
iria prever que a venda de fraldas pudesse ter alguma relao com a de cervejas. Assim,
praticamente impossvel descobrir associaes realmente relevantes e previamente
desconhecidas entre os itens sem a utilizao de um algoritmo de regras de associao.
Muitos algoritmos foram desenvolvidos com o objetivo de descobrir regras de associao
entre itens. Podem ser citados: LargeKItemSets, Apriori, AprioriTid. Desses, o mais
disseminado o seminal Apriori, pois deu origem a vrios outros. O algoritmo e seu
funcionamento so detalhados na seo abaixo.
Gerao de Regras de
Associao: O Algoritmo Apriori
O algoritmo Apriori foi introduzido por Agrawal e Srikant. O problema de descobrir
regras de associao pode ser decomposto em dois subproblemas:
Encontrar todos os conjuntos ou combinaes de itens (itemsets) que tm suporte acima
do suporte mnimo, os quais so chamados de Grandes Conjuntos (Large Itemsets).
Usar os grandes conjuntos para gerar as regras com confiana acima do valor mnimo
estabelecido.
A Tabela 9.2 contm algumas notaes importantes utilizadas pelos diversos algoritmos
de regras de associao.
Tabela 9.2: Algumas notaes usadas no Apriori.
Notao Descrio
k-itemset Um conjunto com k itens
L
k
Unio de grandes conjuntos de tamanho k.
Cada grande conjunto tem dois atributos:
i) conjunto de itens
ii) suporte
C
k
Unio de conjuntos candidatos
(potencialmente grandes) de tamanho k.
Cada conjunto candidato tem dois atributos:
i) conjunto de itens
ii) suporte
172
O algoritmo aparece na Figura 9.5. Nas prximas trs subsees, explicamos em detalhes
seu funcionamento.
Figura 9.5: O algoritmo Apriori
Gerao dos Conjuntos
Nesta fase, todas as possveis combinaes de itens sero geradas: so os chamados
Conjuntos Candidatos. Em seguida, aqueles que no atingirem o suporte mnimo so
descartados ou, utilizando a terminologia do algoritmo, podados. A gerao dos candidatos
ser mostrada nesta seo e a poda logo em seguida.
O algoritmo para descobrir os grandes conjuntos faz muitas passagens pelos dados. Na
primeira, o suporte para cada item individual existente contado e, a partir deste valor,
verifica-se quais conjuntos de tamanho 1 so grandes.
Utilizando a base de dados mostrada na Tabela 9.1, o algoritmo geraria os conjuntos
candidatos mostrados na Figura 9.6(a). A partir da, aqueles que obedecerem ao suporte
mnimo so considerados grandes. Usando aqui um suporte de 0,7, todos os candidatos
seriam considerados grandes. Esta fase est representada na Figura 9.5 atravs da linha 1.
A partir da segunda passagem pelos dados, cada passo se inicia com um conjunto semente
de itens, o qual ir gerar novos conjuntos potenciais, ou seja, novos candidatos.
Exemplificando, se os itens {Leite} e {Po} inidvidualmente so grandes conjuntos,
ento a combinao dos dois forma um conjunto candidato de tamanho 2. Da mesma
forma, os candidatos de tamanho 3 so gerados a partir das combinaes de grandes
conjuntos de tamanho 2. Assim, sendo {Leite, Po} e {Leite, Manteiga} grandes conjuntos,
ento {Leite, Manteiga, Po} formam um conjunto candidato.
173
Sintetizando, aps a gerao dos grandes conjuntos de tamanho 1, devem-se gerar os de
tamanhos 2, 3, 4,..n. Para gerar os candidatos de tamanho 2, preciso produzir todas as
combinaes possveis de grandes conjuntos de tamanho 1, encontrados na fase anterior. O
processo continua at que nenhum grande conjunto seja encontrado. Os grandes conjuntos
de tamanho 2 e 3 so mostrados nas Figuras 9.6(b) e 9.6(c), respectivamente. Percebemos
que todos os candidatos de tamanho 2 obedecem ao suporte mnimo sendo, portanto,
considerados grandes, o que no acontece com o nico candidato de tamanho 3.
Figura 9.6: Conjuntos candidatos de um, dois e trs elementos.
Essa estratgia de fazer vrias passagens pelos dados est representada no algoritmo a
partir do lao na linha 2, Figura 9.5. Nela est sendo mostrado que o processo continua
at que nenhum grande conjunto seja encontrado na passagem anterior. Dentro do lao
feita a gerao dos candidatos e posterior contagem do suporte de cada um deles (linhas
3 a 8). A linha 9 indica que os candidatos de tamanho k que atingirem o suporte passaro
a compor os grandes conjuntos deste mesmo tamanho denominados de L
k
.
Cabe ressaltar que a ordem dos itens no faz diferena para o algoritmo. Por exemplo, o conjunto
{Leite, Po} idntico ao {Po, Leite}, visto que os dois teriam o mesmo suporte. Justamente
por isso que s um candidato de tamanho 3 foi gerado, qual seja, {Leite, Manteiga, Po}.
Fase de Poda
Esta fase ir mostrar quando um conjunto deve ser descartado. Aqui devemos lembrar
que pode existir uma combinao muito grande de itens. Imagine em um supermercado
174
quantas combinaes de 2 ou mais itens podem ser geradas. Desta forma, quanto mais
cedo um candidato que no atinge o suporte mnimo for descartado, melhor para o
desempenho do algoritmo. Assim, grande parte do esforo de otimizao dos algoritmos
para gerao de regras de associao est concentrado nesta etapa. De uma maneira
geral, a otimizao consiste em descartar o quanto antes todos os conjuntos candidatos
que no obedecem ao suporte mnimo. Aps esta etapa, a gerao das regras torna-se
uma tarefa extremamente simples.
A fase de poda executada em dois momentos distintos a cada interao do algoritmo. A
primeira poda feita aps a contagem do suporte dos candidatos de tamanho 1, onde so
naturalmente descartados aqueles que no atingem o suporte mnimo.
Alguns candidatos podero ser podados antes mesmo de terem seu suporte contado,
constituindo a segunda forma de descarte de conjuntos. Isso acontece porque qualquer
subconjunto de um grande conjunto ter que ser necessariamente grande. Ora, para que
{Leite, Manteiga} obedea ao suporte mnimo, os itens {Leite} e {Manteiga}
individualmente tambm devem satisfaz-lo. Assim, se um candidato tem algum subconjunto
que no grande ter sua poda antecipada. O passo de poda ento remove todos os itemsets
c C
k
que contm algum (k-1)-subconjunto de c que no est em L
k-1.
Desta forma, a
segunda parte da poda executada sempre imediatamente aps a gerao dos candidatos e
antes da contagem do suporte. Esta poda executada a partir da gerao dos candidatos de
tamanho 3, visto que, para os de tamanho 2, eles necessariamente foram gerados a partir de
dois grandes conjuntos de tamanho 1.
Exemplificando, seja L
2
= {Leite, Manteiga}, {Leite, Po}, os grandes conjuntos de
tamanho 2. Desta forma, ser gerado o candidato C
3
= {Leite, Manteiga, Po}. O passo
de poda ir descart-lo logo aps sua gerao, visto que um dos seus subconjuntos, qual
seja, {Manteiga, Po}, no grande. Desta forma, o suporte ser contado apenas para os
conjuntos que passaram por esta poda.
Contagem de Suporte
Esta fase resume-se a passar por todas as transaes, verificando a existncia ou
no do candidato. Caso exista, seu suporte incrementado (linhas 4 a 7 do algoritmo
na Figura 9.5).
175
Gerao de Regras
A ltima parte do algoritmo Apriori a gerao das regras (linha 11, Figura 9.5), partindo
dos grandes conjuntos com seus respectivos suportes j encontrados, no exigindo,
portanto, passagem pelos dados. Aqui, a confiana mnima aceitvel passa a ser
considerada. O processo de gerao visto como:
Para todo Large Itemset l, encontre todos os subconjuntos no vazios de l. Para cada
subconjunto a, gerar a regra no formato a (l - a), se a diviso do suporte(l) pelo
suporte(a) for pelo menos igual confiana mnima estabelecida (MinConf).
Por exemplo, para o grande conjunto {Leite, Manteiga, Po}, considerando os
subconjuntos {Leite, Manteiga} e {Po} com respectivos suportes de 0,7 e 0,9, e
considerando ainda que o suporte de {Leite, Manteiga, Po} de 0,6, a confiana da
regra seria de 0,6/0,7 = 0,85. Estabelecendo uma confiana mnima aceitvel de 0,8,
somente as regras sombreadas na Tabela 9.3 so geradas.
Tabela 9.3: As regras geradas pelo Apriori
Regra Fator de Confiana
{Leite} {Manteiga} 0,77
{Manteiga} {Leite} 0,88
{Leite} {Po} 0,77
{Po} {Leite} 0,88
{Manteiga} {Po} 0,88
{Po} {Manteiga} 0,77
{Leite, Manteiga} {Po} 0,85
{Po} {Leite, Manteiga} 0,66
{Leite, Po} {Manteiga} 0,75
{Manteiga} {Leite, Po} 0,75
{Manteiga, Po} {Leite} 0,85
{Leite} {Manteiga, Po} 0,66
176
A tcnica de gerao de regras de associao bem flexvel e poderosa, na medida em
que muitas associaes entre os itens podem ser descobertas. Uma das grandes vantagens
do algoritmo Apriori que, atravs das medidas de suporte e confiana, a quantidade de
regras e a especificidade das mesmas podem aumentar ou diminuir. Dessa forma, podem
ser geradas muitas regras ou o nmero pode ser filtrado para gerar apenas as mais
relevantes no contexto das transaes analisadas.
Entretanto, o nmero de conjuntos candidatos pode ser enorme, podendo at impedir
a execuo do algoritmo e a exploso de regras. Na prtica, o custo do algoritmo
depende criticamente da base de dados utilizada e do suporte mnimo especificado.
A confiana tem menos influncia, pois, para calcul-la, no mais necessria a
varredura das transaes.
Os esforos de otimizao de algoritmos de regras de associao esto praticamente
concentrados na preocupao de tentar descobrir cada vez mais cedo que um candidato
pode ser podado antes mesmo de ter seu suporte contado.
O Algoritmo Apriori Quantitativo:
Uma Nova Abordagem
Na proposta inicial de Agrawal a quantidade adquirida de cada item ignorada. Isto
significa que a transao gerada por um cliente que comprou 2 litros de leite e 10 pes
idntica de outro que comprou apenas 1 litro de leite e 3 pes, por exemplo. Algumas
alternativas foram ento propostas nas quais a quantificao dos dados levada em
considerao. Como o prprio nome sugere, este o caso do Apriori Quantitativo.
Considerando o estudo de caso da mercearia, uma regra quantitativa : 70% das pessoas
que compram entre 1 e 3 litros de leite tambm compram de 5 a 10 pes.
As medidas de suporte e confiana continuam sendo importantes no Apriori Quantitativo.
O problema, de uma maneira geral, ainda encontrar todas as regras que satisfazem ao
suporte e confiana mnimos exigidos.
Como se pode perceber, os passos bsicos so semelhantes aos do Apriori tradicional,
mas a informao extra das quantidades adiciona uma nova dimenso nas regras geradas.
O algoritmo mudado basicamente no passo de poda, onde as informaes quantitativas
so levadas em conta, para que o corte seja mais eficiente.
177
Integrao de Minerao
de Dados e SGBDs
As pesquisas iniciais em Data Mining concentraram-se em definir novas operaes de
minerao e desenvolver algoritmos para as mesmas, os quais lem dados a partir de
arquivos isolados no normalizados (Flat Files), especialmente preparados com esta
finalidade. A maioria das aplicaes foi desenvolvida em sistemas de arquivos com
estruturas de dados e estratgias de gerenciamento de memria especializadas.
Por outro lado, muito investimento em pesquisa e desenvolvimento tem sido feito para o
contnuo aprimoramento dos SGBDs. Entre suas numerosas caractersticas importantes,
destacamos: robustez, escalabilidade, controle de acessos concorrentes e otimizao de
consultas. Alm disso, cada vez mais as empresas armazenam seus dados sob a gerncia
de robustos SGBDs. A tecnologia de SGDB ento oferece vrias funcionalidades que a
tornam valiosa ao implementar aplicaes de minerao de dados. Por exemplo, possvel
trabalhar com conjuntos de dados consideravelmente maiores que a memria principal,
uma vez que o SGBD por si s o responsvel por grande parte do manuseio das
informaes. Com a maturidade alcanada pelos SGBDs para armazenar, manter e
recuperar informaes de grandes bancos de dados de forma eficiente, essas tcnicas de
otimizao poderiam ser incorporadas aos algoritmos de minerao de dados.
Apesar disto, grande parte das aplicaes atuais de minerao ainda tem uma fraca conexo
com SGBDs: em grande parte das aplicaes, eles so utilizados apenas como repositrios, a
partir dos quais os dados so extrados e preparados para minerao. Fica claro que SGBDs e
algoritmos de minerao de dados deveriam se complementar, os primeiros tratando da gerncia
dos dados a minerar, enquanto os ltimos cuidariam da minerao propriamente dita.
Atualmente, esforos esto tambm se concentrando em integrar minerao de dados e
SGBDs, visando somar as vantagens desses dois mundos, aliando o potencial das tcnicas
de minerao s conhecidas vantagens dos SGBDs. O algoritmo de regras de associao
utilizado tem sido o clssico Apriori, j apresentado e discutido.
Muitos fabricantes de SGBD j trazem solues para utilizao de tcnicas de minerao
de dados completamente integradas a seus produtos. Outros fornecedores propem
ferramentas que possam ser integradas a bancos existentes no mercado. Alm disso,
aplicaes para minerao podem ser implementadas e integradas a SGBDs de vrias
maneiras, como mostram as prximas sees deste livro.
178
Abordagens de Integrao
Vrias propostas para integrao de minerao de dados e SGBDs tm sido estudadas.
Na grande maioria dos trabalhos, a classificao das abordagens divide-se basicamente
em: convencional, fortemente acoplada e caixa preta.
Categoria Convencional Fracamente Acoplada
Na categoria convencional, tambm chamada de fracamente acoplada, no existe nenhum
tipo de integrao entre o SGBD e a aplicao. A maioria das atividades de minerao de
dados reside fora do controle do SGBD. Este serve, na melhor das hipteses, como
repositrio para armazenamento dos dados.
A implementao pode ocorrer de duas formas: alternativa loose coupling e alternativa
cache mining.
Na primeira, os dados sob um SGBD so lidos tupla a tupla, atravs de um cursor SQL
20
.
Esta alternativa caracteriza-se pelo desenvolvimento de aplicaes que usam a linguagem
SQL e uma linguagem de programao de propsito geral linguagem hospedeira. A
base de dados nunca copiada para um sistema de arquivo no disco local. Todo o acesso
feito atravs de uma rede, resultando em alguns casos em problemas de desempenho.
O maior atrativo da abordagem a flexibilidade de programao, visto que o algoritmo
de minerao implementado completamente no lado aplicao. Alm disso, qualquer
aplicao de minerao de dados pode facilmente passar a utilizar dados sob a gerncia
de um SGBD.
Em contrapartida, um problema potencial com esta alternativa o alto custo da troca de
contexto entre o SGBD e o processo de minerao, j que eles esto em diferentes espaos
de endereamento. Nenhuma das facilidades para grandes bancos de dados oferecidas
por um SGBD (paralelismo, otimizao de consultas, escalabilidade, controle de acesso
concorrente, etc.) aproveitada, apesar de serem de extrema importncia para aplicaes
de minerao, visto que estas geralmente lidam com grandes volumes de dados.
A Figura 9.7 ilustra uma alternativa loose coupling:
20
Um cursor recebe o resultado da consulta permitindo que o mesmo seja tratado linha a linha.
179
Figura 9.7: Minerao de dados com acoplamento fraco.
A segunda alternativa da categoria convencional uma variao da primeira, na qual os
dados provenientes de um SGBD so armazenados temporariamente em um arquivo fora
do banco (Flat File), especialmente preparado para minerao. Essa estratgia
denominada Cache-Mine. Neste caso, a base de dados lida do banco de dados apenas
uma vez e copiada em disco, conforme ilustra a Figura 9.8. Os dados armazenados podem
ser transformados para um formato que possibilite acessos eficientes e so descartados
quando a execuo completada.
Comparada com a alternativa anterior, pode significar uma melhora no desempenho,
porm continua sem tirar proveito das facilidades do SGBD, alm de requerer espao
extra de armazenamento. Esta variao da abordagem fracamente acoplada tem como
vantagem aumentar a eficincia de acesso aos dados depois de armazenados no arquivo
auxiliar, porm requer espao em disco adicional para armazenamento e consumo de
tempo na preparao e busca completa dos dados.
A Figura 9.8 ilustra a alternativa Cache-Mining:
Figura 9.8: Acoplamento fraco: alternativa cache-mining.
180
Categoria Fortemente Acoplada
Na categoria fortemente acoplada, parte do algoritmo de minerao pode ser codificado e
processado no ncleo de um SGBD lado servidor , atravs de stored procedures e funes
definidas pelo usurio. Desta forma, as operaes de acesso a dados, que consomem mais
tempo so mapeadas para SQL e executadas no lado servidor. A aplicao de minerao de
dados comporta-se ento como uma aplicao cliente, ficando com a tarefa de visualizar o
conhecimento minerado no lado servidor. Fica ento evidenciado que, desta forma, a aplicao
de minerao como um todo pode se beneficiar de vantagens prprias de um SGBD, como
otimizao de consultas e todas as demais vantagens anteriormente mencionadas.
Para uma aplicao fortemente acoplada, o objetivo no retornar do servidor banco de
dados cada vez que um registro buscado. Deseja-se retornar apenas depois que todos
os registros tenham sido processados. Ao invs de trazer os registros do banco de dados
para o programa de aplicao, insere-se, seletivamente, partes do programa aplicao
que realizam a computao sobre registros recuperados no SGBD, evitando assim a
degradao de performance ocorrida na categoria fracamente acoplada.
Figura 9.9: Arquitetura Fortemente Acoplada
Na Figura 9.9 o algoritmo mapeado em cdigo SQL e a forma como a consulta
processada ser determinada pelo otimizador de consultas, que escolhe o plano timo
dentre os vrios planos de execuo que possam ser usados para processar a consulta.
Categoria Caixa-Preta
Finalmente, na categoria caixa-preta, aos olhos do usurio o algoritmo de minerao
completamente encapsulado dentro do SGBD. A aplicao envia uma simples requisio
181
solicitando a extrao de algum conhecimento e recebe o resultado final como resposta.
Note que se trata tambm de uma integrao fortemente acoplada, na qual todo o algoritmo
encapsulado no SGBD.
Pode-se at dizer que, do ponto de vista do desempenho, esta a melhor alternativa,
visto que todos os recursos do SGBD so explorados.
A desvantagem potencial que a integrao escrava do particular algoritmo de minerao
implementado e sabe-se que nenhum algoritmo de minerao o mais adequado para
todos os conjuntos de dados a minerar.
Figura 9.10: Arquitetura Caixa-Preta
Embora a alternativa caixa-preta seja uma forma particular de acoplamento estreito,
que se beneficia completamente das caractersticas do SGBD, o desenvolvedor de
aplicaes fica restrito a utilizar o algoritmo implementado no servidor, ou seja, s
as alternativas propostas pelo fornecedor podem ser utilizadas. claro que, medida
que as ferramentas completamente integradas comearem a evoluir, este problema
tender a ser minimizado.
Resumo
O crescimento da concorrncia e a conseqente mudana do perfil do cliente, que
passa a ser mais exigente, faz surgir a necessidade de novas estratgias de negcio e os
tomadores de deciso modernos precisam de subsdios para encarar as mudanas. Ao
mesmo tempo, existe uma enorme quantidade de informao potencialmente importante
guardada nos bancos de dados, mas que ainda no foi descoberta, ou seja, est escondida
e raramente tornada explcita.
182
Tcnicas de Minerao de Dados surgem ento como auxlio no processo de tomada de
deciso. Algoritmos de minerao de dados extraem, de grandes bases de dados e sem
prvia formulao de hipteses, tendncias, padres e correlaes entre os dados
conhecimento , os quais devem ser teis tomada de deciso. Sendo assim, a utilizao
do processo de minerao de dados de extrema importncia, visto que, atravs dela,
muitos dados armazenados em poderosos SGBDs podem ser transformados em informaes
relevantes que podem ser utilizadas de vrias formas no processo de tomada de deciso.
Minerao de dados pode ser utilizada nos mais variados segmentos do mercado e auxilia
em processos para analisar e determinar o perfil dos clientes, analisar vendas, traar
estratgias de marketing, entre outros aspectos.
Vrias tcnicas de minerao de dados podem ser encontradas, dentre as quais se destacam:
Regras de Associao e Classificao. Especificamente falando da gerao de regras de
associao, a capacidade de descobrir correlao entre produtos vendidos
extraordinariamente importante ao processo de tomada de deciso nas empresas de
comrcio varejista. Esta tcnica geralmente utilizada para descobrir vendas associadas
de produtos nos mais diversos ramos. J a classificao procura formar classes a partir
dos dados minerados. Por exemplo, a partir desta tcnica possvel saber que clientes
tero mais chances de no pagar um determinado emprstimo no banco.
Uma grande vertente das pesquisas em minerao de dados se preocupa com a
integrao entre algoritmos de minerao de dados e SGBDs, somando as vantagens
de cada uma das tecnologias. At pouco tempo, as bases de dados utilizadas pelos
algoritmos de minerao de dados tinham sido sob a forma de arquivos completamente
desintegrados de SGBDs e preparados especialmente para minerao. Recentemente
j podem ser encontradas ferramentas completamente integradas a SGBDs,
disponibilizadas pelos prprios fabricantes.
183
Bibliografia
B I B L I O G R A F I A
184
AGRAWAL R. & GUPTA A. & SARAWAGI S., Modeling Multidimensional
Databases, IBM, 1999.
AGRAWAL, Rakesh; IMIELINSKI, T.; SWAMI, A. Mining Association Rules
between Sets of Items in Large Databases, SIGMOD 5/93, 207-216, Washington,
USA, 1993.
AGRAWAL, Rakesh; SRIKANT, Ramakrishnan. Fast Algorithms for Mining As-
sociation Rules, In: 20th VLDB Conference, 487-498, Santiago, Chile, 1994.
AGRAWAL, Rakesh; SHIN, K. Developing Tightly-coupled Data Mining Applica-
tions on a Relational Database System. In Proc. Of the 2nd Intl Conference on Knowl-
edge Discovery in databases and Data Mining, Portland, Oregon, August, 1996.
AGRAWAL, Rakesh; IMIELINSKI, T.; SWAMI, A. Database Mining: A perfor-
mance perspective. In IEEE Transactions on Knowledge and Data Engineering, Decem-
ber 1993.
AGRAWAL, R. ; IMIELINSKI, T.; SWAMI, A. Mining Associations between Sets
of Items in Massive Databases, Proc. of the ACM-SIGMOD 1993 Intl Conference on
Management of Data, Washington D.C., May 1993, 207-216.
AGRAWAL, Rakesh; SRIKANT, R. Mining quantitative Association Rules in Large
Relational Tables. In Proceedings of the ACM SIGMOD, June 1996.
BARQUIN, R. C. et al. Planning and Designing The Data Warehouse. New Jersey:
Prentice Hall, 1997.
BERSON A.; SMITH S.; THEARLING K. Building Data Mining Applications for
CRM. McGraw Hill, 2000.
BEZERRA, E. et al. An Analysis of the Integration between Data Mining Applications
and Database Systems. In: INTERNATIONAL CONFERENCE ON DATA MINING, 2nd,
2000, Cambridge-UK. Proceedings. Cambridge: WIT Press, 2000. p. 151-160.
BHARGAVA, H., POWER, D. J. Power. Decision Support Systems and Web Technologies:
A Status Report. Prepared for AMCIS 2001, Americas Conference on Information Systems,
Boston, Massachusetts, August 3th 5th, 2001, Decision Support Systems Mini Track.
(URL http://dssresources.com/papers/dsstrackoverview.pdf).
185
Bibliografia
BOBROWSKI S., Oracle8 Architecture, McGraw-Hill, 1998.
BOOCH, G. et al. The Unified Modeling Language User Guide. Addison-Wesley, 1999.
BRAY, T., PAOLI, J., McQUEEN C. M. S., MALER, E. Extensible Markup Lan-
guage. Word Wide Web, , Novembro 2001
CANTOR, M. R. Object Oriented Project Management with UML. John Wiley &
Sons, 1998.
CARVALHO, Juliano Varella de; SAMPAIO, Marcus Costa; MONGIOVI, Giuseppe.
Utilizao de Tcnicas de Data Mining para o Reconhecimento de Caracteres Manuscritos,
In: XIV Simpsio Brasileiro de Banco de Dados, 235-249, Florianpolis, Santa Catarina,
Brasil, 1999.
CHANG, Ben, SCARDINA, Mark, KARUN, K., KIRITZON, Stefan, MACKY,
Ian, NOVOSELSKY, Anguel, RAMAKRISHNAN, Nirajan. Oracle XML. O Manual
Oficial. Rio de Janeiro: Campus, 2001.
CHAUDHURI, S., DAYAL, U. An Overview of Data Warehousing and
OLAP Technology. SIGMOD Record, vol. 26, n
o
. 1, pp. 65-74, March 1997.
DINTER, B. et al. The OLAP Market: State of the Art and Research
Issues. Proceedings of the ACM 1st International Workshop on Data Warehousing
and OLAP, pp. 22-27, Washington, United States, 1998.
ELMASRI, R., NAVATHE, S. B. Fundamentals of Database Systems. 2nd edition.
CA: Benjamim/Cummings, 1994.
FIRESTONE J. M., Object-Oriented Data Warehousing Information Systems, Inc.,
White Paper, 1997.
FOWLER, M., SCOTT, K. UML Distilled: A Brief Guide to the Standard
Object Modeling Language. 2nd edition. Addison Wesley Longman, 1999.
FOWLER, Martin. Dealing with Roles, World Wide Web, http://www.martinfowler.com/
apsupp/roles.pdf, 1999.
186
GARCIA-MOLINA H. ULLMAN J.; WIDOM J. Database System Implementa-
tion. Prentice-Hall, 2000.
GIOVINAZZO,William. Introduction to CWM Oracle site (http://oracle.com/
oramag/oracle/00-jul/o40ind.html).
GOLFARELLI, M., MAIO, D., RIZZI, S. Conceptual Design of Data Warehouses
from E/R Schemes. IEEE Proceedings of the Hawaii International Conference On Systems
Sciences, January 1998.
GRAND M., Patterns in Java: a catalog of reusable design patterns illustrated
with UML, Volume I, John Wiley & Sons, 1998.
GUPTA, V. R. An Introduction to Data Warehousing. System Services Corporation,
August 1997. http://www.system-services.com/dwintro.htm.
HAMMER J. et al. The Stanford Data Warehousing Project. Computer Science
Departament, Stanford University, 1995.
HARDING, J.M. Metadata Management; Vision Unlimited, 1998.
HUYNH, T. N., MANGISENGI, O., TJOA, A. M, Metadata for Object-Relational
Data Warehouse. Proc. of the Int. Workshop on Design and Management of Data
Warehouses (DMDW2000), pages (3-1)-(3-9), 2000.
INMON, W. H., ZACHMAN, John A. Data Stores Data Warehousing and the
Zachman Framework Managing Enterprise Knowledge. Editora Campus, 1996.
INMON, W. H. Como Construir o Data Warehouse. Traduo da segunda edio.
Rio de Janeiro: Campus, 1997.
IYENGAR, Sridhar. CWM Audio Briefing: The Key to Integrating Business Intel-
ligence OMG Site (http://www.omg.org/technology/cwm/index.htm), 2000.
JARKE, M. et al. Fundamentals of Data Warehouses. New York: Springer-Verlag, 1999.
KIMBALL, R. The Data Warehouse Toolkit. New York: John Wiley & Sons, 1996.
KIMBALL, R. Aggregate Navigation With (Almost) No Metadata. DBMS Data
Warehouse Supplement, August 1996.
187
Bibliografia
KIMBALL, R. A Dimensional Modeling Manifesto. DBMS and Internet Systems,
July 1997.
KIMBALL, R. et al. The Data Warehouse Lifecycle Toolkit. New York: John Wiley
& Sons, 1998.
KITCHEN, Philip J., SCHULTZ, Don E. Raising the Corporate Umbrella. Corpo-
rate communications in the 21st century. Great Britain, Palgrave, 2001.
KLEIN L. Z. A Tecnologia Objeto-Relacional em Ambientes de Data Warehouses:
Uso de Sries Temporais como Tipo de Dado No Convencional, M. L. M. Campos & A.
K. Tanaka, Anais do XIV SBBD, Florianpolis-SC, 1999, 365-378.
KRZYSTON, Michael. A real marketing database, or dynamic customer
management, is much different than the single mailing list approach followed by many
consumer good companies. Direct Marketing, feb. 1996.
LEHMANN, P., JASZEWSKI, J. Business Terms as a Critical Success Factor for
Data Warehousing. Proceedings of the International Workshop on Design and
Management of Data Warehouses, Heidelberg, Germany, 1999.
McCORNEL, Graeme. Direct Database Marketing. Kogan Page, 1998.
MARCO, David. Building and Managing the Meta Data Repository: A Full Lifecycle
Guide. Wiley Computer Publishing, 2000.
OMG. World Wide Web, www.omg.org/technology/cwm/index.htm, 2001.
ORACLE CORPORATION, Oracle9i Data Mining Concepts Release 9.0.1, June
2001 Part No. A90389-01.
POE, V. et al. Building a Data Warehouse for Decision Support. Prentice Hall PTR, 1998.
POSSAS, B.; MEIRA W.; CARVALHO, M.; RESENDE, R. Using Quantitative
Information for Efficient Association Rule Generation. XV SBBD, Joo Pessoa-PB,
2000, 361-374.
POWER, D. J. Justifying a Data Warehouse Project. The On-Line Executive Jour-
nal for Data-Intensive Decision Support, vol. 2, n
o
5, February 1998.
188
POWER, D. J. Supporting Decision-Makers: An Expanded Framework.
DSSREsources.COM, World Wide Web, http://dssresources.com/papers/supportingdm/
sld001.htm, 2000.
RADEN, N. Modeling the Data Warehouse. World Wide Web, http://user.aol.com/
nraden/iw0196_1.htm, 1996.
RAJAMANI, K., IYER, B., COX A., CHADHA A. Efficient Mining for Associa-
tion Rules with Relational database Systems. Proceedings of the International Database
Engineering and Applications Symposium (IDEAS99), August 1999.
RAMAKRISHNAN, R. Database Management Systems. USA: WBC/McGraw-Hill, 1998.
RATIONAL. World Wide Web, http://www.rational.com/uml/index.htmpl, 1999.
RUDLOFF, D. Terminological Reasoning and Conceptual Modeling for
Datawarehouse. KRDB-96, Budapest.
RUMBAUGH, J. et al. Object Oriented Modeling and Design. Prentice Hall, 1991.
SACHDEVA, S. Metadata for Data Warehouse. Sybase, Inc. World Wide Web,
http://www.sybase.com/services/dwpractice/meta.html, 1999.
SARAWAGI S., THOMAS S., AGRAWAL R. Integrating association rule mining with
relational database systems: Alternatives and implications. Proc. ACM-SIGMOD, 1998.
SARAWAGI S., AGRAWAL R. Integrating Association Rule Mining with Rela-
tional Database Systems: Alternatives and implications. Research Report RJ 10107
(91923), IBM Almaden Research Center, San Jose, CA 95120, March 1998. Available
from http://www.almaden.ibm.com/cs/quest.
SHERMAN, R. P. Metadata: The Missing Link Business Information Directories
Catalog Decision-Support Information Throughout the Enterprise. DBMS and Internet
Systems, August 1997.
STHR, T., MLLER, R., RAHM, E. An Integrative and Uniform Model for Metadata
Management in Data Warehousing Environments. Proceedings of the International
Workshop on Design and Management of Data Warehouses, Heidelberg, Germany, 1999.
189
Bibliografia
SRIVASTAVA, J., CHEN P. Warehouse Creation: A Potential Roadblock to Data
Warehousing. IEEE Transactions on Knowledge and Data Engineering, vol. 11, n
o
1, pp.
118-126, February 1999.
ULLMAN, J. D., WIDOW, J. A First Course in Database Systems. New
Jersey: Prentice Hall, 1997.
VETTERLI T. & VADUVA, A. & STAUDT M. Metadata Standards for Data Ware-
housing: Open Information Model vs. Common Warehouse Metadata, SIGMOD Record,
Vol 29, n
o
3, 2000.
191
Bibliografia
G L O S S R I O
192
API: Aplication Programming Interface
BD: Banco de Dados
BI: Business Intelligence
CASE: Computer-Aided Software Engineering
DW: Data Warehouse
DWing: Data Warehousing
EDW: Enterprise Data Warehouse
ER: Entidade-Relacionamento
FDW: Federated Data Warehouse
FTP: File Transfer Protocol
HTTP: Hipertext Transfer Protocol
MDIS: Metadata Interchange Specification
MOF: Meta Object Facility
MOLAPMultidimensional: OLAP
ODBC: Open Database Connectivity
ODS: Operational Data Store
OIM: Open Information Model
OLAP: On-Line Analytical Processing
OLTP: On-Line Transaction Processing
OO: Orientao a Objetos
ROLAP: Relational OLAP
SGBD: Sistema Gerenciador de Banco de Dados
SQL: Structured Query Language
UML: Unified Modeling Language
XML: eXtensible Markup Language
XMI: XML Metadata Interchange
193
ndice Remissivo
N D I C E R E M I S S I V O
194
A
Administrao de Dados, 4, 7
Administrador de Banco de Dados, 142, 147
Administradores, 2, 7, 39, 84, 88, 89, 100, 112, 147
AG, 9
Agregado, 29, 30, 32, 34, 59, 60, 80, 103, 115,
137, 138, 153
Anlise de Sistemas, 102, 126, 130
Apriori, 171, 172, 175, 176, 177
Arquivo de log, 154, 155
rvore de deciso, 165, 166
B
Backup, 78, 80, 114, 125, 146, 155
Banco de Dados, 3, 8, 14, 16, 21, 26, 36, 42,
46, 48, 52, 57, 68, 72, 78, 81, 85, 92, 112, 116,
132, 142, 159, 179
Administrador de, 142, 147
BD, 8
BI, 9, 26, 42
Bloco de Dados, 143, 154
Business Intelligence (BI), 9, 26
C
Carga, 17, 19, 23, 68, 72, 86, 89, 100, 103, 108,
116, 125, 127, 133, 138, 153
Carga de Dados, 103, 125, 153, 155
Chave,
Estrangeira, 118
Primria, 51, 56, 118
Chaves Artificiais, 52, 53, 56, 57, 135, 136
Classes, 71, 73, 80, 86, 131, 165, 166
Classificao, 162, 165
Regra de, 166, 167, 168, 182
Clustering, 162, 166
Confiana, 168, 175
CRM, 9, 38, 45, 163
Cronograma, 110, 123, 127
CWM, 92, 95
D
Dados,
Administrao de, 4, 7
Banco de, 3, 8, 14, 16, 21, 26, 36, 42, 46, 48,
52, 57, 68, 72, 78, 81, 85, 92, 112, 116, 132,
142, 159, 179
Bloco de, 143, 154
Dicionrio de, 75, 115, 146, 147, 155
Minerao de, 8, 10, 42, 93, 158, 164, 166-
170, 177-182
Volume de, 72, 100, 101, 113, 126, 142, 146,
147, 148, 153, 154
Data Mart, 18, 21, 22, 73, 76, 89, 90, 91, 96, 97,
100, 101,102, 112, 123, 126, 127, 132,139, 147
Data Mining, 8, 10, 26, 42, 113, 125, 157, 158,
159, 160,161, 163, 164, 165, 167, 169, 171, 173,
175, 177, 179
Data Warehouse, 9, 15, 16, 17, 18, 19, 21, 22,
23, 26, 27, 28, 38, 40, 42, 46, 49, 56, 60, 68, 71,
72, 73, 74, 89
Data Warehousing, 68, 71, 93, 127
Database Marketing, 9, 42, 46, 113, 161, 163
DBA, 142, 145
Deciso,
rvore de, 165, 166
Ferramentas de apoio , 7, 9, 25
195
ndice Remissivo
Suporte , 5, 6-9, 10, 15, 16, 27, 38, 45, 77,
80, 84-86, 95, 104, 108, 113, 121-126, 138,
142, 145, 150
DER, 48, 49
Descoberta de Conhecimento, 160, 161, 162
Desempenho, 14, 15, 18, 22, 37, 38, 49, 50, 52,
54, 56, 57, 59, 64, 103, 113, 138, 142, 145 -
155, 174, 178-181
Indicadores de, 26, 51, 101, 122
Dimenso, 29, 30, 31-36, 42, 45, 50-64, 86, 115,
118, 134-138, 145, 150, 176
Descaracterizada, 55, 56, 59, 64
Tempo, 29, 42, 51, 52, 57, 58, 63, 86
Documentao, 19, 68, 69, 94, 107, 130, 132,
133, 138, 139
E
EDW, 89, 90, 96
EIS, 6, 7, 8, 10, 111
Enterprise Data Warehouse (EDW), 89, 96
Enterprise Resource Planning (ERP), 21
Entrevista, 68, 104 - 110, 126
Equipe, 78, 81, 86, 100, 101, 104, 110-112, 125,
126, 163
ERP, 21, 22, 23
Espao de Tabela, 146, 147
Esquema de dados, 37, 62-64, 83-88, 92, 116
Esquemas-estrela, 37, 49-65, 88
Estimativa de espao, 20, 107, 108, 109, 113,
146, 152, 153, 179
Executivos, 2, 4, 6, 7, 10, 14, 70
F
FAD, 9, 14
Fato, 28, 50, 118, 136, 137, 147, 150
Fatos,
Tabela de, 50-65, 136, 138, 147, 148, 150
Federated Data Warehouse (FDW), 89, 90, 96
Ferramentas de apoio deciso, 7, 9, 25
Fidelizao, 40
Flat Files, 116, 120, 132, 153, 177
FTP, 118
G H
Gerncia de metadados, 67
Hierarquia, 32, 58, 137
I
Incremental, 123, 127
Indicadores de Desempenho, 26, 51, 101, 122
ndices, 81, 122, 138, 144, 147, 150
ndices de rvore B, 150
ndices de Bitmap, 151
ndices Particionados, 149
Informao,
Tecnologia da, 10, 26, 40, 96, 104
Integrao, 3, 15, 19, 21, 42, 46, 68, 74, 77, 84,
89, 91, 94, 101, 115, 122, 126, 162, 177
Integraao Data Mining e SGBD, 177
Interativo, 6, 122, 162
Internet, 41, 81
K M
KDD, 160
Marketing, 8, 9, 38, 42, 45, 46, 100, 112, 113,
158-161, 163
MDIS, 91
196
Metamodelo, 82, 92-96
Metodologia de Desenvolvimento, 4, 7, 86, 96,
102, 130, 139
Minerao de Dados, 8, 10, 42, 93, 158, 164,
166-170, 177-182
MIS, 5
Modelagem Dimensional, 60
Modelo,
Conceitual, 48, 92, 132
Entidade e Relacionamento, 48, 51
Fsico, 76, 87, 125
Lgico, 125
Relacional, 49, 92
MOF, 93
MOLAP, 35-38
Multidimensional, 29, 35-38, 49, 80, 91, 93,113
N
Negcio, 2,7,9,16,20,26, 31, 42-44, 48, 60, 68-
75,80-82,84-91, 104, 110, 119, 122, 158
Normalizao, 27, 48, 49, 50, 54, 56, 58, 62,
64, 65, 70, 118, 177
O
Objetos, 71, 80-82, 93, 103, 130, 146-149, 155, 165
ODS, 19, 118-120, 132
OIM, 91
OLAP, 9,19, 26-32, 35-38, 48, 58, 60, 64, 68,
70, 75, 86, 92, 112, 127, 138
Multidimensional (MOLAP), 35
Relacional (ROLAP), 37
OLTP, 2, 28, 68, 102, 142, 145-147
Orientao a Objetos, 80, 93, 130
Otimizao, 17, 85, 95, 139,141-143, 145, 174,
176-180
Otimizador de Consulta, 149,180
P
Particionamento, 117, 131, 138, 142, 148, 149,
154, 155
Processo de Descoberta de Conhecimento, 160, 161
Projeto,
Arquitetural, 130-132
conceitual, 48, 80, 82, 83, 92, 96, 132
fsico, 142, 145, 154,
fsico de dados, 142
Q
Qualidade, 2, 6, 15, 40, 41, 84, 85-90, 95, 96,
121, 127
R
Redundncia, 3, 9, 18, 21, 23, 48, 49, 58, 59,
64, 70, 90
Regra,
de associao, 159, 162, 165, 167-182
de classificao, 162, 165, 166, 167, 168, 182
Relatrios, 4, 7, 18, 22, 26, 27, 50, 54, 68, 78,
88, 105, 107, 111, 112, 138, 139
Repositrio de metadados, 76-87, 95, 96
Restaurao, 15, 114, 147, 149, 155
ROLAP, 37
S
SAD, 7, 8, 11, 102, 103, 125, 126, 142, 143
Segurana, 3, 28, 41, 81, 82, 94, 111, 114, 123,
142, 165
197
ndice Remissivo
SGBD, 3, 4, 9, 38, 82, 108, 112, 114, 115, 117,
138, 142-154, 177-182
SIG, 5, 6, 10, 14
Sistemas,
Anlise de, 102, 126, 130
de Apoio Deciso (SADs), 6, 7, 8, 10, 11,
14, 77, 102, 103, 126, 142, 145,
de Informao, 2, 3, 5, 7, 8,10, 11, 14, 76,
88, 90, 92, 101, 104
de Informao Executivos, 6, 7, 10
de Informaes Gerenciais (SIGs), 6, 7, 10
SQL, 31, 37, 178, 180
Staging Area, 19, 10, 72, 90, 118-121, 132, 137,
139, 154, 155
Star Schema, 37, 49-65, 88
Suporte Deciso, 5, 6-9, 10, 15, 16, 27, 38,
45, 77, 80, 84-86, 95, 104, 108, 113, 121-126,
138, 142, 145, 150
T
Tabela de Fatos, 50-65, 136, 138, 147, 148, 150
Tabela Particionada, 148, 149
Tcnicas de Data Mining, 160, 164
Tecnologia da Informao, 10, 26, 40, 96, 104
Transao, 2, 3, 28, 169
Transacional, 3, 5, 6, 8, 14, 19, 48, 56, 105, 115,
143, 148, 154
U
UML, 93, 129, 130, 133, 136, 139
V
Vises Particionadas, 149
Volume de dados, 72, 100, 101, 113, 126, 142,
146, 147, 148, 153, 154
X
XMI, 81, 92, 93
XML, 81, 92, 93
P
R
O
J
E
T
A
N
D
O

S
I
S
T
E
M
A
S

D
E

A
P
O
I
O

D
E
C
I
S
O
B
A
S
E
A
D
O
S

E
M

D
A
T
A

W
A
R
E
H
O
U
S
E
PROJETANDO SISTEMAS
DE APOIO DECISO
BASEADOS EM
DATA WAREHOUSE
M
e
t
h
a
n
i
a
s

C
o
l
a
o

J
n
i
o
r
Fruto da experincia de vrios profissionais especialistas nas reas de Banco de Dados, Business
Intelligence, Marketing, Data Warehouse (DW) e Data Mining, este livro traduz as potencialidades de um DW como
a base para sistemas de suporte deciso. Atravs de uma linguagem simples e com foco em aspectos essen-
ciais, o leitor adquire um conhecimento slido sobre Sistemas de Apoio Deciso (SADs) e passa a conhecer as
caractersticas fundamentais de todas as ferramentas envolvidas neste processo. So abordados conceitos sobre
ferramentas de Business Intelligence tais como as ferramentas OLAP, EIS, ERP, CRM, Database Marketing e Data
Mining.
Alm de preparar conceitualmente o leitor, apresentada uma metodologia de desenvolvimento e documentao
de um projeto de ambiente de suporte deciso. Muitos dos exemplos apresentados no se prendem aos con-
ceitos bsicos, mas agregam conhecimento e criatividade por parte do seu autor e colaboradores, inclusive esten-
dendo a UML para documentao de um DW. H um cuidado especial para no apresentar um Data Warehouse
como a resoluo de todos os problemas, mas sim apresentar solues que podem ser utilizadas por gerentes
de um projeto como este. Gerncia de metadados e projeto fsico de banco de dados tambm so abordados e
todos os captulos do livro so finalizados com um resumo, para fixao e simples reviso do que foi abordado.
O livro beneficia profissionais e estudantes de Informtica em matrias como Banco de Dados e Tpicos Espe-
ciais, e direcionado para estudantes e profissionais de Administrao, Marketing, Publicidade, Contabilidade e
Economia, envolvidos profissionalmente com a rea gerencial ou academicamente com disciplinas como Tecno-
logia da Informao, Sistemas de Informao, Contabilidade Gerencial, CRM, entre outras.
Os profissionais de Marketing tambm podero encontrar neste livro a base para a implantao de aplicaes de
Database Marketing.
Methanias Colao Jnior M.Sc. em Informtica pela Universidade Federal de Campina Grande (UFCG) na
rea de Sistemas de Informao e Banco de Dados. Especialista em Cincia da Computao e Tecnologia da
Informao, membro da equipe de Sistemas de Apoio Deciso do Banco do Estado de Sergipe e professor da
Universidade Tiradentes e da Faculdade Sergipana (UNIP). Atua como consultor de empresas na rea de DW,
prestando servios Secretaria Municipal de Finanas de Aracaju, Secretaria de Estado da Fazenda de Sergipe e
Companhia Alagoana de Refrigerantes (Coca-Cola/SE). Ministra treinamentos e presta consultoria em Engenharia
de Software, Banco de Dados, Oracle e ferramentas de BI.
Andr Vincius Nascimento graduado em Cincia da Computao pela Univer-
sidade Federal de Sergipe e M.Sc. em Informtica pela UFCG na rea de Sistemas de
Informao e Banco de Dados. membro da equipe de Sistemas de Apoio Deciso
do Banco do Estado de Sergipe e professor da Universidade Federal de Sergipe, alm
de ministrar aulas em curso de ps-graduao em Administrao de Banco de Dados.
Maria de Ftima Almeida graduada em Cincia da Computao pela Universi-
dade Federal de Sergipe e M.Sc. em Informtica pela UFCG na rea de Sistemas de
Informao e Banco de Dados. Membro da equipe de Sistemas de Apoio Deciso
do Banco do Estado de Sergipe e professora de curso de ps-graduao em Admi-
nistrao de Banco de Dados e da Universidade Tiradentes.
PROJETANDO SISTEMAS DE APOIO DECISO
BASEADOS EM DATA WAREHOUSE
w
w
w
.
a
x
c
e
l
.
c
o
m
.
b
r
297

SistemasApoioDecisao BaseadosDataWarehouse PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SistemasApoioDecisao BaseadosDataWarehouse PDF

Загружено:

Авторское право:

Доступные форматы

P

Вам также может понравиться