SistemasApoioDecisao BaseadosDataWarehouse 19735

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/327582653
PROJETANDO SISTEMAS DE APOIO À DECISÃO BASEADOS EM DATA

WAREHOUSE; Implementing Decision Support Systems and Data Warehouses
Book · September 2018
CITATIONS READS
10 540
1 author:
Methanias Colaço Júnior

FEDERAL UNIVERSITY OF SERGIPE (UFS)
73 PUBLICATIONS 94 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Security Analytics View project
Strategic Business-Driven and Experimental Big Data Science, Big Code, Data Mining and BI View project
All content following this page was uploaded by Methanias Colaço Júnior on 11 September 2018.
The user has requested enhancement of the downloaded file.

www.axcel.com.br
BASEADOS EM DATA WAREHOUSE

PROJETANDO SISTEMAS DE APOIO À DECISÃO
PROJETANDO SISTEMAS DE APOIO À DECISÃO Methanias Colaço Júnior
Fruto da experiência de vários 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 à decisão. Através de uma linguagem simples e com foco em aspectos essen-
ciais, o leitor adquire um conhecimento sólido sobre Sistemas de Apoio à Decisão (SADs) e passa a conhecer as
características fundamentais de todas as ferramentas envolvidas neste processo. São abordados conceitos sobre PROJETANDO SISTEMAS
ferramentas de Business Intelligence tais como as ferramentas OLAP, EIS, ERP, CRM, Database Marketing e Data
Mining.
Além de preparar conceitualmente o leitor, é apresentada uma metodologia de desenvolvimento e documentação
DE APOIO À DECISÃO
de um projeto de ambiente de suporte à decisão. Muitos dos exemplos apresentados não se prendem aos con-
ceitos básicos, mas agregam conhecimento e criatividade por parte do seu autor e colaboradores, inclusive esten- BASEADOS EM
dendo a UML para documentação de um DW. Há um cuidado especial para não apresentar um Data Warehouse
como a resolução de todos os problemas, mas sim apresentar soluções que podem ser utilizadas por gerentes
de um projeto como este. Gerência de metadados e projeto físico de banco de dados também são abordados e
DATA WAREHOUSE
todos os capítulos do livro são finalizados com um resumo, para fixação e simples revisão do que foi abordado.
O livro beneficia profissionais e estudantes de Informática em matérias como Banco de Dados e Tópicos Espe-
ciais, e é direcionado para estudantes e profissionais de Administração, Marketing, Publicidade, Contabilidade e
Economia, envolvidos profissionalmente com a área gerencial ou academicamente com disciplinas como Tecno-
logia da Informação, Sistemas de Informação, Contabilidade Gerencial, CRM, entre outras.
Os profissionais de Marketing também poderão encontrar neste livro a base para a implantação de aplicações de
Database Marketing.
Methanias Colaço Júnior é M.Sc. em Informática pela Universidade Federal de Campina Grande (UFCG) na

área de Sistemas de Informação e Banco de Dados. Especialista em Ciência da Computação e Tecnologia da
Informação, é membro da equipe de Sistemas de Apoio à Decisão 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 serviços à Secretaria Municipal de Finanças 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é Vinícius Nascimento é graduado em Ciência da Computação pela Univer-

sidade Federal de Sergipe e M.Sc. em Informática pela UFCG na área de Sistemas de
Informação e Banco de Dados. É membro da equipe de Sistemas de Apoio à Decisão
do Banco do Estado de Sergipe e professor da Universidade Federal de Sergipe, além
de ministrar aulas em curso de pós-graduação em Administração de Banco de Dados.
Maria de Fátima Almeida é graduada em Ciência da Computação pela Universi-

dade Federal de Sergipe e M.Sc. em Informática pela UFCG na área de Sistemas de
Informação e Banco de Dados. Membro da equipe de Sistemas de Apoio à Decisão
do Banco do Estado de Sergipe e professora de curso de pós-graduação em Admi-
nistração de Banco de Dados e da Universidade Tiradentes. 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 não pode ser vendido e/ou distribuído em CD-ROM, DVD-ROM ou por programas
de compartilhamento P2P. A forma correta de obter este arquivo é adquirindo-o através dos
sites da Editora Axcel (www.axcel.com.br) e de Júlio Battisti (www.juliobattisti.com.br).
Se você adquiriu este documento através dos meios legais descritos acima, não distribua ou
venda este produto. Você estará cometendo um crime contra o autor da obra.
Se você adquiriu este e-book por intermédio de terceiros, regularize sua situação entrando em
contato pelo e-mail editora@axcel.com.br, para que não seja alvo das penalizações previstas em
Lei. Usar cópia ilegal também é crime de violação dos direitos autorais.
REPRODUÇÃO PROIBIDA PELA LEI DO DIREITO AUTORAL.

II Projetando Sistemas de Apoio à Decisão Baseados em Data Warehouse
Copyright © 2004 by Methanias Colaço Júnior

Copyright © 2004 by Axcel Books do Brasil Editora Ltda.
Nenhuma parte desta publicação poderá ser reproduzida

sem autorização prévia e escrita de Axcel Books do Brasil Editora.
Editora de Produção: Gisella Narcisi

Editor Responsável: Ricardo Reinprecht
Projeto Gráfico: Axcel Books
Equipe Axcel: Alberto Baptista Garcia, Carlos Alberto Sá Ferreira,
Fagner Silva Henrique e Ingo Bertelli
Projetando Sistemas de Apoio a Decisão Baseados em Data Warehouse

ISBN: 85-7323-208-0
Os originais de livros enviados para avaliação pela Editora serão destruídos,

quando não aprovados. Não será feita sua devolução em nenhuma hipótese.
Os conceitos emitidos nesta obra são de inteira responsabilidade do Autor.
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
Para uso pessoal. Este material não pode ser utilizado em Salas de Aula e para ministrar treinamentos.
Sumário III
“A chave para ter sucesso nos negócios é ter

informações que ninguém mais tem. ”
Aristóteles Onassis
IV Projetando Sistemas de Apoio à Decisão Baseados em Data Warehouse
Agradecimentos
Em primeiro lugar agradeço a Deus, pelas constantes bênçãos derramadas. Na nossa

vida, devemos fazer tudo na dependência Dele.
Agradecimentos a todos da minha família e em especial: ao meu pai Methanias e à

minha mãe Valdice, responsáveis diretos pela minha formação; à minha irmã Mahely e
ao meu cunhado Marco pelo incentivo; e aos meus primos queridos Gardênia, Tici, Sá,
Edmilson Júnior, Alexsandro e Jonatas, pela admiração.
Agradeço, com o coração cheio de orgulho e felicidade, aos meus melhores ex-alunos de
Banco de Dados, e agora meus colegas e professores, André Vinícius Nascimento e Maria
de Fátima Almeida. Colaboradores diretos e indispensáveis deste livro, eles são um
exemplo de amor, profissionalismo e dedicação à árdua tarefa de dominar conhecimentos
da área de Informática.
À Gerente de Marketing Érika Celestino pela contribuição quanto à aplicação prática de

marketing nas organizações.
Ao Designer Jonatas Lemos Rodrigues pela arte final das ilustrações.
Aos meus queridos alunos e ex-alunos, maiores motivos da escrita deste livro.
Aos professores Asterio Tanaka, Eduardo Bernardes e Marcus Sampaio pela experiência
transmitida e pela confiança em mim depositada.
Aos irmãos em Cristo, que sempre oram pela minha vida.
A todos os amigos e profissionais que contribuíram para realização desta obra.
Sumário
Prefácio V
Sobre o Autor
Methanias Colaço Júnior é M.Sc. em Informática pela Universidade Federal de Campina

Grande (UFCG) na área de Sistemas de Informação e Banco de Dados. Especialista em
Ciência da Computação e Tecnologia da Informação, é membro da equipe de Sistemas
de Apoio à Decisão 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 serviços à Secretaria Municipal de Finanças 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é Vinícius Nascimento é graduado em Ciência da Computação pela Universidade

Federal de Sergipe e M.Sc. em Informática pela UFCG na área de Sistemas de Informação
e Banco de Dados. É membro da equipe de Sistemas de Apoio à Decisão do Banco do
Estado de Sergipe e professor da Universidade Federal de Sergipe, além de ministrar
aulas em curso de pós-graduação em Administração de Banco de Dados.
Maria de Fátima Almeida é graduada em Ciência da Computação pela Universidade

Federal de Sergipe e M.Sc. em Informática pela UFCG na área de Sistemas de Informação
e Banco de Dados. Membro da equipe de Sistemas de Apoio à Decisão do Banco do
Estado de Sergipe e professora de curso de pós-graduação em Administração de Banco
de Dados e da Universidade Tiradentes.
Colaboraram em três capítulos deste livro.
VI Projetando Sistemas de Apoio à Decisão Baseados em Data Warehouse
Apresentação
A globalização da economia, a mutação dos mercados e o acirramento da concorrência

tornaram a informação o bem mais valioso para as organizações, e estas passaram a
tratar seus dados não mais como meros resultados de transações, 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 análise de negócios, crescimento e capacidade de
prever novas oportunidades.
As informações contidas em um Data Warehouse possuem características específicas que

as distinguem das informações existentes em projetos de bancos de dados convencionais.
Grandes volumes de dados, dados históricos e bases não normalizadas são algumas das
peculiaridades que impedem a utilização das metodologias tradicionais de análise de
sistemas. Ao deparar-se com esse quadro, a indústria de software, aliada a pesquisadores
da área, passou a investir na concepção 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 concepção de um ambiente de Data Warehousing bem-sucedido.
Infelizmente, a realidade mostra que muitos projetos de Data Warehouse fracassaram

completamente ou causaram frustração nas expectativas de seus usuários (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 experiência acadêmica e prática, do caminho a ser seguido para o
sucesso de um projeto como esse.
Ao implantar um DW, os administradores esperam alcançar benefícios, tais como:

■ Recursos para acessar de modo rápido e flexível as informações do negócio.
■ Disponibilidade de mecanismos que incorporam a inteligência do negócio e permitem
efetuar o acompanhamento do desempenho e identificar as exceções no padrão de
comportamento esperado.
■ Facilidades para a definição de estratégias microssegmentadas, a partir do conhecimento
relacionado com o comportamento dos clientes.
■ Criação de conhecimento com base na análise de diversos cenários e identificação de
padrões de comportamento ou preferências/hábitos de consumo.
Apresentação
Sumário VII
■ Redução de riscos associados ao negócio, através das facilidades de análise de risco e

avaliação de alternativas.
■ Rapidez na percepção de probabilidade de ocorrência de inadimplência e de riscos
associados à composição do negócio, aliada à possibilidade de adoção de novas táticas
para a correção de desvios.
■ Implementação de um efetivo “marketing de relacionamento”, permitindo a definição
de estratégias com foco nos clientes e atendimento das suas expectativas, visando à
elevação da taxa de retenção dos mesmos.
Esse livro, fruto da experiência de vários 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 à Decisão. Através de uma linguagem simples
e com foco em aspectos essenciais, o leitor adquire um conhecimento sólido sobre Sistemas de
Apoio à Decisão e passa a conhecer as características fundamentais de todas as ferramentas
envolvidas neste processo. São abordados conceitos sobre ferramentas de apoio à decisão tais
como as ferramentas OLAP, EIS, ERP, CRM, Database Marketing e Data Mining.
Além de preparar conceitualmente o leitor, apresentamos uma metodologia de

desenvolvimento e documentação de um projeto de ambiente de suporte à decisão. Muitos
dos exemplos apresentados não se prendem aos conceitos básicos, mas agregam
conhecimento e criatividade por parte do seu autor e colaboradores, inclusive estendendo
a UML para documentação de um DW. Tivemos um cuidado especial para não apresentar
um Data Warehouse como a resolução de todos os problemas, mas sim apresentar soluções
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 fictícia e todos os capítulos do
livro são finalizados com um resumo para fixação e simples revisão do que foi abordado.
O primeiro capítulo do livro introduz o leitor no domínio dos Sistemas de Informação

relacionados com o Apoio à Decisão. Especificamos todas as soluções criadas para geração
de informações gerenciais, bem como suas nomenclaturas específicas que hoje perfazem
o jargão dos sistemas que servem à alta gerência.
No Capítulo 2, apresentamos o conceito de Data Warehouse (DW) e o encaixamos no do

contexto dos ambientes de suporte à decisão modernos. O leitor poderá caracterizar e
diferenciar um DW dos bancos de dados convencionais.
VIII Projetando Sistemas de Apoio à Decisão Baseados em Data Warehouse
O Capítulo 3 descreve as principais ferramentas de apoio à decisão (ou ferramentas de

Business Intelligence (BI)) utilizadas no mercado. Elucidamos as características
fundamentais de uma ferramenta OLAP e preparamos o leitor para avaliar ferramentas de
apoio à decisão, averiguando exigências da área de negócios para este tipo de ferramenta.
Além das ferramentas OLAP, pela importância mercadológica, conceituamos CRM e Da-
tabase Marketing, relacionando-os com um projeto de DW. Discutimos aspectos importantes
para a construção de um DW que apoiará uma política de relacionamento com clientes.
No Capítulo 4, enfatizamos o esquema de dados utilizado em Data Warehouses

relacionais. Procuramos dirimir as principais dúvidas de projeto surgidas na
construção de esquemas-estrela.
O Capítulo 5 discute e apresenta conclusões de todo o contexto que envolve uma

arquitetura para gerência e armazenamento de metadados. Analisamos os requisitos de
uma boa arquitetura, o processo de concepção de um repositório de metadados e sugerimos
o armazenamento de alguns atributos e entidades indispensáveis à sobrevivência de um
projeto de DW.
Os Capítulos 6 e 7 são a espinha dorsal do livro. No Capítulo 6, apresentamos uma

metodologia clara de desenvolvimento de um DW e, no Capítulo 7, uma extensão UML
para documentar todas as etapas do processo.
O Capítulo 8 provê o embasamento teórico necessário para a elaboração de um projeto

físico de dados para Data Warehouse; e serve de base para a escolha de um SGBD que
apresente características que dêem suporte à criação e evolução de um banco de dados
voltado para suporte à decisão.
Por fim, no Capítulo 9, são apresentados conceitos de Data Mining e sua importância
como auxílio para a tomada de decisão. O Processo de Descoberta de Conhecimento é
abordado em detalhes, seguido de uma discussão sobre as principais técnicas de Mineração
de Dados. O capítulo é finalizado com uma explicação detalhada de um algoritmo de
geração de regras de associação, uma das mais importantes técnicas de Data Mining, e
uma discussão sobre a importância de integrar as técnicas de mineração aos Sistemas
Gerenciadores de Bancos de Dados.
Apresentação
Sumário IX
Objetivos
Com este livro, o leitor alcançará os seguintes objetivos:

■ Familiarizar-se com todos os conceitos, regras e expressões do domínio de Sistemas
de Apoio à Decisão.
■ Entender o que é um Data Warehouse (DW) e sua relevância 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 gerência e armazenamento de metadados em um DW.
■ Conhecer as principais ferramentas de BI (Business Intelligence, ou Inteligência
Aplicada aos Negócios).
■ Valorizar a importância de uma política de marketing e entender como conduzir um
projeto de DW para beneficiar o marketing estratégico das organizações.
■ Dominar a configuração ideal de Sistemas Gerenciadores de Bancos de Dados
utilizados em projetos de DW.
■ Compreender os benefícios e funcionamento de um processo de mineração de dados
(Data Mining) em bancos de dados históricos.
Público-Alvo
Este livro interessa a qualquer pessoa envolvida na produção, implantação, manutenção,

gerência e utilização (inclusive diretores e executivos) de Sistemas de Informações
Gerenciais ou de Apoio à Decisão.
Além de beneficiar profissionais e estudantes de Informática em matérias como Banco

de Dados e Tópicos Especiais, o livro é direcionado para estudantes e profissionais de
Administração, Publicidade, Contabilidade e Economia, envolvidos profissionalmente
X Projetando Sistemas de Apoio à Decisão Baseados em Data Warehouse
com a área gerencial ou academicamente com disciplinas como Tecnologia da Informação,

Sistemas de Informação, Contabilidade Gerencial e etc.
Os profissionais de Marketing também poderão encontrar neste livro a base para a

implantação de aplicações de Database Marketing.
Como Usar Este Livro
Para alunos e profissionais de informática, sugerimos uma leitura linear deste livro. Uma
atenção especial deve ser dedicada aos Capítulos 4, 6, 7 e 8, que apresentam
responsabilidades específicas destes profissionais em projetos de DW.
Os demais acadêmicos e profissionais de outras áreas podem começar pela leitura dos
Capítulos 1, 2, 3 e 9, enfatizando aspectos relacionados aos negócios. No Capítulo 9, por
exemplo, é possível entender como funciona o processo de mineração de dados em dois
níveis. Um nível para aqueles que desejam saber o que é e quais os benefícios da mineração
para os negócios, e, para os interessados, um nível de conhecimento de como funcionam
os processos de mineração.
Os Capítulos 4, 5, 6 e 7 são importantíssimos para servirem de guia para administradores

e diretores de áreas de sistemas de informação. Estes capítulos fornecem ao gestor um
embasamento para o acompanhamento de projetos de DW, visando eliminar a frustração
de expectativas.
Sumário XI
Sumário
Capítulo 1: Introdução .................................................................................................... 1
Evolução dos Sistemas de Informação .......................................................................... 2
Sistemas de Informação Gerenciais ............................................................................... 5
Sistemas de Informação Executivos .............................................................................. 6
Sistemas de Apoio à Decisão ........................................................................................ 7
Resumo ...................................................................................................................... 10
Capítulo 2: Sistemas de Apoio à Decisão Baseados em Data Warehouse .................... 13

Conceito de Data Warehouse ..................................................................................... 16
Características de um Data Warehouse ....................................................................... 16
Orientado por Temas ............................................................................................ 16
Integrado .............................................................................................................. 16
Variante no Tempo ................................................................................................ 17
Não Volátil ............................................................................................................ 17
Data Marts ................................................................................................................. 18
Arquitetura Básica de um Data Warehouse ................................................................. 18
Data Warehouse X Enterprise Resource Planning (ERP) ............................................... 21
Resumo ...................................................................................................................... 22
Capítulo 3: Ferramentas de Apoio à Decisão ................................................................ 25

Ferramentas OLAP ...................................................................................................... 26
OLAP X OLTP ........................................................................................................ 28
Características ....................................................................................................... 29
Conjunto de Operações 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
Tendências ............................................................................................................ 37
CRM .......................................................................................................................... 38
Fidelização ............................................................................................................ 40
As Relações Virtuais Através da Internet ................................................................. 41
Database Marketing .............................................................................................. 42
XII Projetando Sistemas de Apoio à Decisão Baseados em Data Warehouse
Resumo ...................................................................................................................... 45
Capítulo 4: Modelagem de Dados Para Data Warehouses ........................................... 47

Por que Não Usar o Modelo Entidade e Relacionamento Tradicional? ......................... 48
Star Schema (Esquema Estrela) ................................................................................... 49
Tipos de Dimensão ............................................................................................... 52
Dimensão Tipo 1 ............................................................................................. 52
Dimensão Tipo 2 ............................................................................................. 52
Dimensão Tipo 3 ............................................................................................. 53
Dimensões descaracterizadas ........................................................................... 55
Chaves Artificiais .............................................................................................. 56
Dimensão Tempo .................................................................................................. 57
Hierarquias ............................................................................................................ 58
Agregados ............................................................................................................ 59
Tipos de indicadores para as tabelas de fatos ........................................................ 60
Um Estudo de Caso Para Definição dos Passos da Modelagem Dimensional ............... 60
Dúvidas comuns de projetistas de DW ....................................................................... 62
Resumo ...................................................................................................................... 64
Capítulo 5: Gerência de Metadados em um Data Warehouse ..................................... 67

Metadados em um processo de Data Warehousing .................................................... 68
Metadados Operacionais ............................................................................................ 71
Metadados de Negócio .............................................................................................. 73
Uma Arquitetura Básica de Metadados ....................................................................... 74
Tipos de Arquitetura de Metadados ............................................................................ 75
Requisitos de uma Arquitetura de Metadados ............................................................. 77
Integração ............................................................................................................ 77
Extensibilidade ...................................................................................................... 77
Robustez ............................................................................................................... 78
Abertura ............................................................................................................... 78
Automatização e Reutilização de Processos ........................................................... 78
Padronização do Processo de Integração ............................................................... 79
Flexibilidade .......................................................................................................... 80
Gerenciamento de Múltiplas Versões de Metadados .............................................. 80
Facilidades de Atualização ..................................................................................... 81
Arquitetura Multicamadas ..................................................................................... 81
Gerenciamento de segurança ................................................................................ 81
Funcionalidade de um Repositório de Metadados ...................................................... 82
Provisão de Informação ......................................................................................... 82
Metamodelo ......................................................................................................... 83
Acesso ao Repositório ............................................................................................ 83
Administração de Versão e Configuração .............................................................. 83
Sumário XIII
Análise de Impacto ............................................................................................... 84

Notificação ........................................................................................................... 84
Metadados Técnicos e Qualidade de Dados em Metadados ....................................... 84
Controle de Metadados em um Projeto Evolutivo de Construção de DW .................... 89
Padronização de Metadados ...................................................................................... 91
O Metamodelo CWM ........................................................................................... 92
Resumo ...................................................................................................................... 94
Conclusões ................................................................................................................. 96
Capítulo 6: Uma Metodologia para Implementação de um Data Warehouse ............. 99

Diferenças entre a Análise Tradicional
e a Análise de Sistemas de Apoio à Decisão .............................................................. 102
Entrevistas ................................................................................................................ 104
Características a serem Analisadas no Ambiente de Informações Existente ........... 105
Disponibilidade de Informações ..................................................................... 105
Acesso às informações disponíveis .................................................................. 105
Acuracidade ................................................................................................... 105
Modelos de Tabelas Geradas em Entrevistas com os Usuários e Analistas ............ 106
Técnicas .............................................................................................................. 109
Equipe ..................................................................................................................... 110
Ambiente de Hardware e Software ........................................................................... 113
Esquema de Carga ................................................................................................... 116
Sistema de Carga ................................................................................................ 119
Pontos de Verificação para Garantia de Qualidade .................................................... 121
Cronograma de Implementação ............................................................................... 123
Resumo .................................................................................................................... 125
Capítulo 7: Estendendo a UML Para Documentar um Data Warehouse .................... 129

Projeto Arquitetural .................................................................................................. 130
Documentação de Data Marts .................................................................................. 132
Visão Estática ...................................................................................................... 132
Visão Dinâmica ................................................................................................... 133
Transformação de atributos ............................................................................ 133
Transformação de atributos em mais de um atributo ..................................... 134
Tabela se transforma em outra sem alteração de atributos ............................. 134
Atributos novos nas tabelas ............................................................................ 135
Atributos que Deixam de ser Usados .............................................................. 135
Chaves Artificias ............................................................................................. 135
Estereótipos Para Dimensão, Tabela de Fatos e Tabelas Auxiliares ................... 136
Hierarquias, Agregados e Tipos de Indicadores .............................................. 137
Documentação da Configuração Física e de Relatórios OLAP .................................... 138
Resumo .................................................................................................................... 139
XIV Projetando Sistemas de Apoio à Decisão Baseados em Data Warehouse
Capítulo 8: Otimização da Configuração Física de

um Banco de Dados Para Data Warehouse ................................................................ 141
Bloco de Dados ........................................................................................................ 143
Tamanho de Bloco de Dados .............................................................................. 145
Tamanho da Área Livre ........................................................................................ 146
Separação Física de Tipos de Dados .......................................................................... 146
Particionamento ....................................................................................................... 148
Visões 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
Capítulo 9: Data Mining e a Descoberta de Informações

Para Alavancagem do Negócio ................................................................................... 157
Mineração de Dados: alguns conceitos ..................................................................... 158
O Processo de Descoberta do Conhecimento ........................................................... 161
Preparação dos Dados ................................................................................... 162
Data Mining e Customer Relationship Management (CRM) ..................................... 163
Como o Data Mining Ajuda o Database Marketing .................................................. 163
Principais Técnicas de Mineração de Dados .............................................................. 165
Classificação ........................................................................................................ 165
Regras de Associação .......................................................................................... 167
Geração de Regras de Associação: o algoritmo Apriori .............................................. 171
Geração dos Conjuntos .................................................................................. 172
Fase de Poda ....................................................................................................... 173
Contagem de Suporte ......................................................................................... 174
Geração de Regras .............................................................................................. 175
O Algoritmo Apriori Quantitativo: uma nova abordagem .................................... 176
Integração de Mineração de Dados e SGBD´s ........................................................... 177
Abordagens de Integração .................................................................................. 178
Categoria Convencional – Fracamente Acoplada ............................................ 178
Categoria – Fortemente Acoplada .................................................................. 180
Categoria Caixa Preta .................................................................................... 180
Resumo .................................................................................................................... 181
Bibliografia .................................................................................................................. 183
Glossário ...................................................................................................................... 191
Índice Remissivo .......................................................................................................... 193
Capítulo 1: Introdução 1
1
C A P Í T U L O
Introdução
2 Projetando Sistemas de Apoio à Decisão Baseados em Data Warehouse
Evolução dos Sistemas de Informação

O cenário de competição no mundo dos negócios tem assistido a profundas mudanças
nos últimos anos. As empresas estão sendo impulsionadas a rápidas e contínuas adaptações
para sobreviverem e crescerem no mercado. É necessário conquistar novos clientes, manter
os já existentes, ampliar o ramo de negócios com qualidade e inová-lo conforme as
tendências mercadológicas. Produtos devem ser concebidos com alta economicidade e
com seus empreendedores aplicando um excelente grau de efetividade.
Para levar as corporações a um lugar de destaque, os administradores precisam ter a capacidade

de analisar os dados disponíveis e tomar decisões rápidas e seguras. Diante desta necessidade
crescente, os sistemas de informação (SI) têm evoluído nas últimas décadas e buscado alternativas
para o fornecimento otimizado de informações para apoio à decisão. Os dados estão sendo
utilizados como verdadeiros recursos empresariais, porém não foi sempre assim. Para chegar ao
estado atual, os sistemas de informação passaram por longos anos de aperfeiçoamento, que
culminaram com a visão de executivos modernos e visionários da informática como uma forma
imbatível de alavancagem de negócios. Resumiremos adiante como se deu esta evolução.
Nos anos 60 os sistemas eram criados como verdadeiras ilhas de informação. As aplicações
mantinham seus dados independentes e isolados das outras. Os dados comuns entre
aplicações eram redundantes e, na maioria das vezes, inconsistentes. Um cadastro de
funcionários, por exemplo, repetia-se no sistema de recursos humanos e no sistema de
empréstimos de ferramentas em uma indústria. Assim, se fosse necessária a criação de
uma nova aplicação que utilizasse informações de funcionários, um arquivo era gerado
especificamente para esta finalidade. Se os dados nele contidos fossem necessários 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 específicos, relativos a problemas
específicos, gerados por dados também específicos. Não existiam métodos de gerenciamento
de dados como um recurso e nem para o recolhimento dos benefícios resultantes.
Foi em 1970 que aconteceu o advento do armazenamento em disco. Diferente do

armazenamento em fita magnética, os dados poderiam ser acessados diretamente e o tempo
de processamento era bem menor. Nesta época, surgiu o termo OLTP1 – Processamento de
1
On Line Transaction Processing.
Transações On Line – para definir o processamento efetuado pelos sistemas de informação

transacionais ou operacionais. Estes sistemas de informação são também identificados
pela expressão Eletronic Data Processing (EDP), e são necessários para o controle
operacional das organizações. Sistemas OLTP fornecem agilidade, segurança e eficiência
na inserção dos dados em bancos de dados, porém a maioria deles falha no fornecimento
de análises significativas e levam muito tempo na recuperação de dados gerenciais.
Os Problemas da Redundância...
Muitas empresas tiveram prejuízos sérios devido à presença de redundância de dados e conseqüente
inconsistência dos mesmos. Podemos citar o exemplo do funcionário de uma indústria demitido.
Na maioria das vezes, seu cadastro era excluído apenas do sistema de recursos humanos e, por
uma falta de integração de sistemas, erroneamente mantido no sistema de empréstimos de
ferramentas. Nada impedia que a insatisfação com a demissão levasse a pessoa a visitar a oficina,
retirar as ferramentas mais caras e nunca mais voltar com as mesmas. A redundância pode
transformar uma coisa simples em um verdadeiro caos para a organização.
Paralelamente ao advento do OLTP, surgiram os Sistemas de Gerenciamento de Bancos de

Dados (SGBD). Os SGBDs foram softwares criados para fornecer acesso às informações
e à atualização das mesmas, garantindo a segurança 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 redundâncias de
informações 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). Além disso,
os profissionais de informática da época, apesar de serem pessoas competentes,
desenvolviam sistemas sem nenhuma visão metodológica e com uma preocupação
extrema na estruturação e reestruturação do hardware das organizações. Até as mudanças
mais recentes, a engenharia de software era empírica e foram produzidos softwares
sob demanda, sem nenhuma preocupação com a geração futura de informações
integradas e estratégicas.
Figura 1.1: Arquitetura Simples de um SGBD.
Concluímos então que faltaram dois requisitos essenciais da engenharia de software

moderna: administração de dados e uma metodologia de desenvolvimento. Nosso livro
não pretende discutir problemas de metodologia, nem tampouco a crise do software, mas
fica claro que, sem administração de dados, os sistemas podem continuar sendo
desenvolvidos sem a consciência da importância da integração para a produção de
informações gerenciais. Exemplificando, uma simples tabela de feriados pode ser repetida
em diversos sistemas, causando problemas de atualização e inconsistência. Imaginemos
cálculos de juros semelhantes, sendo feitos com base em tabelas de feriados diferentes
ou desatualizadas.
Executivos sempre sofreram ao solicitarem relatórios gerenciais de sistemas distintos e

encontrarem resultados diferentes sobre assuntos comuns. Dos anos 80 até os dias atuais,
soluções foram criadas para resolver os problemas decorrentes da falta de administração
de dados e para produzir informações gerenciais com uma única versão da verdade.
Analisaremos estas soluções a seguir.
Figura 1.2: “Teia” causada pela falta de integração.
Sistemas de Informação Gerenciais

Depois da implantação de diversos sistemas de informação transacionais, as empresas
tendem naturalmente a desenvolver sistemas que forneçam informações integradas e
sumarizadas. Estas informações podem ser oriundas dos diversos sistemas transacionais
existentes, bem como podem ser extraídas de um único sistema transacional, limitadas
ao escopo do mesmo. Atualmente, engenheiros de software competentes sempre
incorporam funcionalidades gerenciais em seus sistemas.
Informações gerenciais têm a capacidade de prover insumo para análise, planejamento e

suporte à decisão, além de possibilitarem, ao nível tático da organização, a visualização
do desempenho de um departamento e até mesmo de toda a corporação. Sistemas que
possuem essas informações são geralmente chamados de Management Information
Systems (MIS) ou Sistemas de Informação Gerenciais (SIG).
Os SIGs começam a surgir quando os gerentes sentem a necessidade de informações

rápidas, em quantidade, com qualidade e, principalmente, integradas. É o conhecido
estágio de controle e integração de uma corporação. Nesta fase, os diretores e gerentes
costumam alavancar o desenvolvimento de sistemas com características gerenciais.
Um Sistema de Informação Gerencial verdadeiro deve fornecer informações para os

planejamentos operacional, tático e até mesmo estratégico da organização, comparando
o desempenho atual da organização com o que foi planejado. Os gerentes devem ser
capazes de analisar despesas e a compatibilidade das mesmas com o orçamento planejado.
É notório que SIGs, apesar de não serem considerados Sistemas de Apoio à Decisão,
auxiliam gerentes no processo de tomada de decisão e podem perfeitamente fazer parte
de um ambiente completo de suporte à decisão. Na seção Sistemas de Apoio à Decisão
diferenciaremos um Sistema de Informação Gerencial de um Sistema de Apoio à Decisão.
Sistemas de Informação Executivos

Unindo informações dos Sistemas Transacionais às informações dos SIGs é possível
construir sistemas de informação voltados para executivos. Sistemas deste tipo também
podem agregar informações coletadas de fontes externas à organização e prover os resultados
em formato interativo, diminuindo o esforço da alta gerência para análise dos mesmos.
Sistemas construídos para dinamizar o trabalho dos executivos são sugestivamente

chamados de Executive Information Systems (EISs), ou Sistemas de Informação
Executivos. Não existem maiores diferenças conceituais em relação a um Sistema de
Apoio à Decisão. O que diferencia é, em geral, a interface com o usuário, que deve
permitir que um executivo utilize um EIS com facilidade. Estes sistemas provêm aos
executivos informações comparativas através de mapas, gráficos e dados estatísticos
fáceis de entender. Além disso, agregam funcionalidades de correio eletrônico,
teleconferências, calendários, agendas, gerenciamento de projetos, tarefas e pessoas.
Na verdade, podemos considerar um Sistema de Informações Executivo como um Sistema

de Informações Gerenciais acrescido de características que dão ao executivo a vantagem
de poder analisar informações e organizar o seu trabalho em um único ambiente.
Somente organizações maduras e com boa administração de dados conseguem desenvolver

e/ou implantar um Sistema de Informação Executivo. É necessário que os sistemas de
informação existentes reflitam o fluxo de informações da organização. A metodologia
de desenvolvimento adotada deve prever participação do usuário em todas as fases e a
organização tem que vislumbrar sempre a informação como recurso e patrimônio. Em
outras palavras, os sistemas de informação passam a ser a base para o planejamento
estratégico, e todas as decisões passam a depender destes sistemas.
Os Sistemas de Informação Executivos são confundidos com outras ferramentas de apoio à

decisão, mas têm como principal diferença a facilidade. Ainda hoje, a maioria dos executivos
prefere ter uma tela EIS com “botões mágicos” para geração de relatórios, a usar uma
ferramenta que necessite de apoio investigativo e intuição. Estas telas EIS fornecem dados
detalhados sobre o passado, presente e tendências futuras das unidades de negócios em relação
ao mercado, além de auxiliarem o processo de planejamento e de controle da organização.
Um Sistema de Informação Executivo autêntico deve permitir a navegação de dados

sintéticos para dados mais detalhados, e pode fazer parte do conjunto de ferramentas e
sistemas que consultam uma base de dados histórica existente.
Sistemas de Apoio à Decisão

O conceito de Sistemas de Apoio à Decisão (SADs), ou Decision Support Systems (DSSs),
está na realidade relacionado com um ambiente complexo, projetado para fornecer
subsídios para que a alta gerência tome decisões.
Autores de livros de informática voltados para as áreas de administração, economia e

contabilidade costumam definir SADs de forma ambígua, sem clara diferença entre um
Sistema de Apoio à Decisão e um Sistema de Informação Gerencial, por exemplo. Nossa
obra também pretende contribuir para a formação de administradores modernos,
elucidando definições nebulosas da literatura existente.
A maioria dos conceitos enunciados sobre SADs os coloca como sistemas de informação
que apóiam qualquer processo de tomada de decisão nos níveis tático, estratégico e
operacional. Isto não é suficiente, pois qualquer SI pode ser útil ao nível gerencial e, nem
por isso, todo Sistema de Informação será um Sistema de Apoio à Decisão. Um Sistema de
Informações Gerenciais também pode apoiar qualquer processo de tomada de decisão tática.
Um EIS apóia decisões estratégicas e até um Sistema de Informação Transacional pode
apoiar decisões de nível operacional. A pergunta é: “Qual é a diferença ?”.
O famoso exemplo das fraldas e da cerveja...
Através de um ambiente de suporte à decisão bem projetado e utilizando Mineração 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 próximas, com batata fritas entre elas, aumentando consideravelmente
a venda dos três produtos. Muitas vezes, o cliente nem pretende levar a cerveja, mas o faz
quando vê a tentação do lado das fraldas.
Existem várias explicações para o caso, como por exemplo a presença do bebê significar falta de
tempo para ir a uma boate à noite para beber. O fato é que a decisão de reposicionamento do
estoque foi diretamente influenciada pela informação descoberta. Há vários outros exemplos
curiosos, como a venda de colírios em feriados e etc.
A diferença reside no fato de os Sistemas de Apoio à Decisão não só fornecerem informações

para tomada de decisões, mas também contribuírem e influenciarem o processo. Um SAD
deve fornecer e analisar alternativas, pesquisar históricos de decisões tomadas e auxiliar a
resolução 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 análise de risco em investimentos de capital.
Atualmente, algumas empresas já proporcionam que um gerente possa tomar uma decisão
baseada em um simples relatório estatístico ou tomar outra completamente diferente,
baseada na descoberta de uma informação escondida na base histórica (veja o quadro “O
famoso exemplo das fraldas e da cerveja...”). A descoberta de informações escondidas
através de Mineração de Dados (Data Mining) é abordada no Capítulo 9.
Entendendo a diferença, podemos conceituar um SAD como um ambiente projetado

para apoiar, contribuir e influenciar o processo de tomada de decisão (Figura 1.3). Este
ambiente é formado pelos seguintes componentes:
■ Banco de Dados (BD): Não podemos confundir o conceito de Banco de Dados com o
conceito de Sistema Gerenciador de Banco de Dados. Um Banco de Dados não está
necessariamente relacionado com armazenamento eletrônico. Bancos de dados podem
ser vistos como coleções de dados inter-relacionados. Em um ambiente de suporte à
decisão, podem ser formados por informações internas e externas à organização, por
conhecimentos e experiências de especialistas e por informações históricas acerca das
decisões tomadas. Um Data Warehouse, objetivo principal do nosso livro, pode fazer
parte, ou ser o banco de dados principal de um ambiente de suporte à decisão. A
princípio e simplificadamente, podemos conceituar um Data Warehouse como um
Banco de Dados projetado para armazenar informações integradas de toda organização,
mantendo um histórico das mesmas.
■ Sistema Gerenciador de Banco de Dados (SGBD): Como discutido anteriormente,
um SGBD é uma coleção de programas que permitem aos usuários 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 icação de diversos
arquivos que, de outra forma, seriam distintos, eliminando-se total ou
parcialmente a redundância entre os mesmos. Já o compartilhamento não significa
apenas que as aplicações existentes podem compartilhar dados do Banco de
Dados, mas também que novas aplicações podem ser desenvolvidas para operar
sobre os mesmos dados armazenados.
■ Aplicativos com características gerenciais (AGs): São aplicativos com funções
gerenciais de análise acrescidas. Aplicativos com estas funcionalidades podem fazer
parte do grande ambiente de suporte à decisão.
■ Ferramentas de apoio à decisão (FADs): Também chamadas de ferramentas de BI
(Business Intelligence, ou Inteligência Aplicada aos Negócios), são softwares
desenvolvidos para apresentar graficamente as informações, auxiliando a simulação
de situações, fornecendo capacidade de análise, ou descobrindo conhecimento. Além
disso, existem ferramentas no mercado que facilitam a implementação de funções
específicas, tais como o Gerenciamento de Risco de Crédito, Rentabilidade de Clientes,
Database Marketing, etc.
Neste livro, abordaremos excelentes e importantes exemplos de FADs. No Capítulo 3,

discutiremos sobre as ferramentas OLAP (abreviação de Analytic Processing On-Line,
ou processamento analítico on-line) de apoio à decisão, bem como sobre ferramentas de
Database Marketing e CRM (Customer Relationship Management, ou gerência da relação

com os clientes). No Capítulo 9, esmiuçaremos o conceito e características de um processo
de mineração de dados (Data Mining).
Figura 1.3: Ambiente de apoio à decisão.
Resumo
Paulatinamente ao longo das três últimas décadas, os sistemas de tecnologia da informação
têm se preocupado muito com problemas de negócios. Esta preocupação reside na
necessidade de competição das empresas no mercado globalizado. As organizações devem
ser capazes de analisar os dados disponíveis e tomar decisões rápidas e seguras.
Soluções para geração de informações gerenciais foram criadas, recebendo uma

nomeclatura específica que hoje perfaz o jargão dos sistemas de informação que servem
à alta gerência. Enumeremo-las:
■ Sistemas de Informações Gerenciais (SIG): Sistemas que geram informações com a
capacidade de prover insumo para análise, planejamento e suporte à decisão, além de
possibilitarem, ao nível tático da organização, a visualização do desempenho de um
departamento e até mesmo de toda a corporação.
■ Sistemas de Informação Executivos (EIS): Geram informações gerenciais como os
SIGs e dinamizam o trabalho dos executivos através da agregação de funcionalidades
como correio eletrônico, teleconferências, calendários, agendas, gerenciamento de

projetos, tarefas e pessoas.
■ Sistemas de Apoio à Decisão (SAD): Ambiente projetado para apoiar, contribuir e
influenciar o processo de tomada de decisão.
Os sistemas de informação envolvidos com o processo de tomada de decisão podem ser,

na realidade, pápeis assumidos por aplicações criadas exclusiva ou parcialmente para
esse propósito.
Capítulo 2: Sistemas de Apoio à Decisão Baseados em Data Warehouse 13
2
C A P Í T U L O
Sistemas de Apoio à
Decisão Baseados em
Data Warehouse
Os Sistemas de Apoio à Decisão tradicionais eram concebidos através do desenvolvimento

de Ferramentas de Apoio à Decisão (FAD) (ver Capítulo 1) para produção e distribuição
de informações úteis para gerentes, executivos e analistas do conhecimento. Para a
produção destas informações, as FADs acessavam os bancos de dados operacionais da
organização, gerando um forte acoplamento entre Sistemas de Informações Transacionais
e Sistemas de Apoio à Decisão (Figura 2.1).
Como a quantidade de dados gerados nas empresas cresce em progressão geométrica, o

acoplamento passou a ser um problema e, para que as aplicações continuassem com um
bom desempenho, era preciso separar os dados mais antigos da base de dados acessada
pelas aplicações transacionais, pois a concorrência entre as consultas gerenciais e as
funções desempenhadas pelos Sistemas de Informação 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 históricos passaram a ser armazenados separadamente e restaurados

quando preciso. Porém, a confiança e desempenho também eram comprometidos pelo
fato de os dados não estarem adequados para o suporte à decisão, ou seja, tanto estavam
desintegrados (Capítulo 1), como também não foram modelados para otimizar o
desempenho de consultas gerenciais (discutiremos modelagem de dados para apoio à
decisão no Capítulo 4 deste livro).
Aliadas às necessidades supracitadas, consultas a esses dados históricos 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 restauração e acesso a essas
informações. A maioria dos gerentes passava dias para obter uma informação gerencial
e ainda assim não confiava na acuracidade da mesma.
Objetivando integrar dados de múltiplas fontes, um processo de análise com informação

de qualidade sem impacto para o ambiente operacional e um atendimento a diferentes
tipos de usuários com agilidade e flexiblidade, surgiu o conceito de Data Warehouse
(Armazém de Dados) (Figura 2.2).
Figura 2.2: Integração com um Data Warehouse.
Conceito de Data Warehouse

Data Warehouse (DW) é um banco de dados histórico, separado lógica e fisicamente do
ambiente de produção da organização, concebido para armazenar dados extraídos deste
ambiente. Antes de serem armazenados no DW, os dados são selecionados, integrados e
organizados para que possam ser acessados da forma mais eficiente, auxiliando assim o
processo de tomada de decisão.
Segundo W. H. Inmon, especialista e pioneiro no assunto, um Data Warehouse é “um conjunto

de dados, não volátil, orientado a tópicos, integrado, que varia com o passar do tempo e que
serve de suporte para o processo de tomada de decisões da gerência”. (W. H. Inmon, 1996).
Analisaremos as características enunciadas por Inmon a seguir.
Características de um Data Warehouse
Orientado por Temas

O Data Warehouse armazena informações necessárias para o processo de suporte à
decisão. Essas informações são organizadas pelos temas importantes para o negócio da
empresa. Em uma rede de restaurantes, por exemplo, os temas são: produtos, clientes,
funcionários, etc.
Cada tema pode envolver várias tabelas. Considerando o tema cliente, podem existir
tabelas com as informações gerais (nome, endereço, 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. Além destas, podem existir tabelas cumulativas com os clientes que mais
consumiram no período de 1999 a 2003, e tabelas detalhadas que armazenarão o código
do cliente, a data da venda, os produtos consumidos e o valor da despesa. Portanto,
percebe-se que, para o mesmo tema, podem existir vários níveis de detalhamento.
Integrado
O Data Warehouse deve consolidar dados de diversas origens, o que geralmente envolve
diferentes codificações. Os dados devem ser perfeitamente integrados para que ao serem
armazenados assumam uma única convenção. Exemplificando: uma aplicação pode
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 são extraídos para o Data Warehouse devem assumir uma
única codificação.
Variante no Tempo
Os dados em produção são atualizados de acordo com as mudanças necessárias, e com
isso os dados “históricos” são perdidos. Em consultas, são capturados os dados válidos
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 informações anteriores.
Em um Data Warehouse os dados são carregados como fotos da base de dados operacional
do momento, ou seja, cada ocorrência e cada mudança são consideradas como um novo
registro. Os dados não são atualizados e podem ser comparados ao longo do tempo. Ao
consultar o cliente “X” do exemplo anterior em 2000, virão os dados da época de solteiro.
Não Volátil
Teoricamente, depois que os dados estão no Data Warehouse (DW) não poderão ser
atualizados ou alterados, apenas acessados. Os novos dados serão 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 são atualizados registro a registro a qualquer momento.
Escrevemos teoricamente, pelo fato de algumas situações específicas exigirem

atualização dos dados carregados para o DW. Podemos tomar como exemplo a carga
de dados contábeis. Como saldos contábeis normalmente sofrem atualizações, pois
podem existir lançamentos de valores errados, também é necessário corrigir esses
valores carregados para o DW.
A característica da não volatilidade pode ser aceita totalmente devido ao fato de o banco
de dados de um DW ser configurado fisicamente para otimização de inclusões e consultas
(analisaremos otimização física no Capítulo 8), ou seja, não deve ser um banco preparado
para atualizações. Desta forma, é melhor remover a carga errada e carregar os dados
novamente do que realizar updates (atualizações) na base do DW.
Data Marts
O Data Mart é geralmente descrito como um subconjunto dos dados contidos em um
Data Warehouse extraído para um ambiente separado. Data Marts são muito úteis nas
seguintes condições:
■ Os dados devem estar segregados para melhorar o desempenho do sistema do ponto
de vista do usuário.
■ Deve existir uma cópia dos dados onde só pessoas com autorização devem ter o
privilégio de acessá-las.
■ Em um ambiente corporativo, é importante fortalecer o conceito de propriedade
dentro do banco de dados. Diferentes setores serão responsáveis por diferentes Data
Marts. Segundo Kimball, especialista no assunto:
“Um Data Mart, também conhecido como Warehouse Departamental, é uma abordagem
descentralizada do conceito de Data Warehouse (Kimball et al., 1998)”.
Esses ambientes fisicamente distintos trazem benefícios, mas existe um preço a se pagar.
Com a presença de muitos Data Marts pode haver o risco de redundância. A construção
de Data Marts deve ter sempre a preocupação de compartilhamento de dados, tabelas e
relatórios em comum entre os departamentos. A dificuldade de evitar a redundância de
dados pode ir contra o paradigma de um Data Warehouse já que a separação física em
diferentes grupos diminui essa habilidade de organização. Fica clara a necessidade de
preservação da consistência das informações presentes nos Data Marts através da
eliminação de redundâncias, pois relatórios em comum não podem possuir valores
diferentes. Isto é uma característica da maioria dos Sistemas Transacionais das corporações
e deve ser eliminada com a presença de um DW.
Arquitetura Básica de um Data Warehouse

Descreveremos resumidamente o funcionamento de uma arquitetura padrão de Data
Warehouse (Figura 2.3).
Os dados vêm dos diversos Sistemas Transacionais e geralmente são tratados por uma
ferramenta ETL2 . Ferramentas ETL são responsáveis pela extração, transformação e
2
Extraction, Transformation and Load, ou extração, transformação e carga.
carregamento dos dados no DW. Num projeto de construção 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 também à
falta de conhecimento e documentação dos mesmos.
Figura 2.3: Arquitetura básica de DW.
O fluxo de dados começa nas aplicações fontes, e passa por uma área intermediária
de armazenamento chamada de Staging Área (Área de Estágio). Na Staging Área os
dados sofrem integração, limpeza e depois são exportados para o DW. A integração
consiste na consolidação dos dados de diversas origens, o que geralmente envolve
diferentes codificações. Os dados devem ser perfeitamente integrados para que ao
serem armazenados assumam uma única convenção (ver seção Integrado neste
capítulo). A limpeza é a rejeição de valores inválidos, chaves repetidas ou registros
com outros tipos de erro. Estas ações constituem a tarefa mais crítica na geração de
um Data Warehouse (descreveremos em detalhes a implementação de um processo
ETL no Capítulo 6).
Segundo Kimball, além da Staging Área, o ideal é que exista uma segunda área intermediária
antes da carga definitiva para o DW. Esta segunda área, chamada de ODS (Operational
Data Store), deve ser uma base de dados com utilização previsível, parcialmente estruturada
e analítica cujo histórico é de apenas 30 ou 60 dias e cujas informações estão organizadas

por área de negócio (Figura 2.4). É um retrato da base obtida da extração, transformação e
limpeza de dados dos sistemas fontes operacionais da empresa e no início de sua concepção
era visto como sendo um tipo de DW (Kimbal et al., 1998).
Na realidade, no ODS, os dados são mantidos como no ambiente operacional, ou seja, não
estão modelados ainda para consultas gerenciais, porém podem ser úteis para recuperção
de cargas de dados problemáticas. Com um ODS, não é necessário refazer toda a extração
para corrigir eventuais problemas na transferência dos dados para o DW. Muitos projetos
de DW possuem ODS e utilizam esta área para fazer validação de regras de negócio, ou
seja, na Staging Área a limpeza se resume em verificar chaves repetidas e problemas de
integridade referencial; verificações de regra de negócio são feitas no ODS.
Por economia de espaço de armazenamento em disco muitos DWs são implementados

sem ODS. Não há implicações graves nisto, pois cargas problemáticas podem ser refeitas.
A única implicação será um maior tempo para correção de cargas erradas.
Figura 2.4: Arquitetura de DW segundo Kimball.
Somente após a integração e limpeza os dados são exportados para o DW. Depois os
dados são transmitidos para Data Marts (Figura 2.5) ou, numa abordagem centralizada,
são consultados diretamente pelos usuários através de uma Ferramenta de Apoio à
Decisão, por exemplo.
Figura 2.5: DW e Data Marts.
Data Warehouse X Enterprise

Resource Planning (ERP)
Antes da implantação de DWs as empresas já buscavam a integração dos dados acessados
por seus sistemas e agilização dos seus processos. Foram criados softwares multi-
modulares para auxiliar gestores em todas as fases do negócio.
Sistemas capazes de facilitar o fluxo de informações entre todas as atividades de uma

empresa, como fabricação, logística, finanças e recursos humanos, são chamados de
ERP (Enterprise Resource Planning ou Sistemas de Gestão Empresarial). Um ERP é,
geralmente, composto por um banco de dados único, operando em uma plataforma comum
que interage com um conjunto de aplicações.
Um banco de dados ERP pode ser confundido com um DW, porém existem diferenças
básicas. Apesar de fornecerem uma estrutura integrada, sem redundância de
informações, Sistemas de Gestão Empresarial (ERP) utilizam o mesmo banco de dados
para armazenamento de dados operacionais e para armazenamento de dados históricos

utilizados como fonte de informações gerenciais. Nos deparamos, mais uma vez, com
o problema da concorrência. Consultas gerenciais são feitas no mesmo ambiente
operacional e provavelmente serão mais lentas do que consultas feitas em um DW
separado. Além disso, os dados também não estão modelados para um maior
desempenho destes tipos de consulta.
Na nossa opinião, um ERP é uma excelente solução para gestão das empresas, desde que
seja escalável, ou seja, que se integre facilmente com outros aplicativos e possa ser
estendido facilmente à medida que a corporação cresce e necessita da automatização de
outras funcionalidades.
Sistemas ERP fornecem excelentes relatórios gerenciais; todavia, não podemos descartar
a presença de um DW. Por possuir uma base de dados integrada, um ERP pode ser a fonte
ideal para um DW projetado para fornecer informações gerenciais com agilidade e sem
concorrência com o ambiente operacional.
Resumo
Mesmo com a tendência natural de crescimento da integração entre aplicações operacionais,
decisões de nível estratégico e tático exigem um conteúdo mais rico do que aquele encontrado
no ambiente operacional, o qual apresenta inúmeros obstáculos para o processamento
analítico. As empresas precisam de um ambiente exclusivo que armazene adequadamente
os dados extraídos das diversas bases, disponibilizando as informações a qualquer instante.
O banco de dados deste ambiente, que surgiu como solução para prover informações
gerenciais para a tomada de decisões, foi denominado de Data Warehouse.
Um DW é um banco de dados histórico, separado lógica e fisicamente do ambiente de

produção da organização, concebido para armazenar dados extraídos deste ambiente.
Antes de serem armazenados no DW, os dados são selecionados, integrados e organizados
para que possam ser acessados da forma mais eficiente, auxiliando assim o processo de
tomada de decisão.
A dificuldade de implementação de um DW completo imediatamente fez surgir o conceito

de Data Mart, ou Warehouse Departamental. Um Data Mart é um subconjunto lógico de
um DW, um DW setorial.
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 são responsáveis pela extração, integração, limpeza e posterior carga dos dados para o
DW. A integração consiste na consolidação dos dados de diversas origens, o que geralmente
envolve diferentes codificações. Os dados devem ser perfeitamente integrados para que
ao serem armazenados assumam uma única convenção. A limpeza é a rejeição de valores
inválidos, chaves repetidas ou registros com outros tipos de erro. Estas ações constituem
a tarefa mais crítica na geração de um Data Warehouse.
Sistemas ERP podem ser excelentes fontes de informações para um DW. Isto é possível
pelo fato de um banco de dados único interagir com todos os aplicativos deste tipo de
sistema. Desta forma, elimina-se a redundância de informações e redigitação de dados, o
que assegura a integridade das informações obtidas.
Capítulo 3: Ferramentas de Apoio à Decisão 25
3
C A P Í T U L O
Ferramentas de Apoio à Decisão
As Ferramentas de Apoio à Decisão estão relacionadas com o conceito de BI (Business

Intelligence, ou Inteligência Aplicada aos Negócios). Podemos dizer que BI é um conjunto
de tecnologias que permitem o cruzamento de informações e suportam a análise dos
indicadores de desempenho de um negócio. Portanto, as ferramentas de apoio à decisão
que fazem inferências em um banco de dados histórico, um DW por exemplo, são também
chamadas de ferramentas de BI.
Neste capítulo, analisaremos dois tipos de Ferramentas de Apoio à Decisão. 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 à decisão
em um capítulo especial, o Capítulo 9.
Ferramentas OLAP
Uma das tarefas mais solicitadas ao pessoal de TI (tecnologia da informação) nas
organizações é a produção de consultas que descrevam de forma clara e concisa
informações sobre os negócios da empresa. Essas consultas ou relatórios apresentam-se
desde simples listagens de funcionários ou produtos a complexos mapas de demonstração
de crescimento financeiro. Independente de seu objetivo final, a verdade é que, nem
sempre, é possível prever durante o projeto ou compra de sistemas quais informações
necessitarão ser extraídas. Essa incapacidade de previsão, algo perfeitamente aceitável
quando o assunto refere-se a negócios, faz surgir a necessidade de mecanismos auxiliares,
adjacentes aos sistemas utilizados, para a geração de novos relatórios.
A primeira solução da indústria de software para atender a essa demanda foi o desenvolvimento
de ferramentas de geração de relatórios. Porém, a partir do momento em que a informação
passou a ser o bem mais valioso para as organizações e com o surgimento de toda a infra-
estrutura dos Data Warehouses, surgiu a necessidade da criação de ferramentas com uma
capacidade de análise maior do que a dos geradores de relatórios tradicionais. Ou seja, embora
a infra-estrutura necessária para armazenar milhares de informações estivesse pronta, um
novo problema tornar-se-ia o mais novo pesadelo para o pessoal de TI. Como apresentar
essas informações? Como fornecer a capacidade de análise para essas informações?
As informações contidas em um Data Warehouse possuem características específicas

que as distinguem das informações existentes em projetos de bancos de dados
convencionais. Grandes volumes de dados, dados históricos e bases não normalizadas

são algumas das peculiaridades que impedem a utilização das ferramentas convencionais
para geração de relatórios. Ao deparar-se com esse quadro, a indústria de software, aliada
a pesquisadores da área, também passou a investir na concepção 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 analítico on-line)
que caracteriza o conjunto de técnicas utilizadas para tratar informações 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
publicação desse ensaio, a palavra OLAP transformou-se em uma buzzword no cenário
de bancos de dados, e todo profissional de sistemas esforçava-se para compreendê-la, e
como ela se encaixava no paradigma de aplicações de suporte à decisão.
No entanto, OLAP, conforme definida pelo Dr. Codd, não é uma nova tecnologia e
alguns produtos já existiam há tempos no mercado. Por força deste mesmo mercado,
as ferramentas que apresentavam características OLAP passaram a ser referenciadas
como ferramentas OLAP.
Atualmente, as linguagens de programação e as principais empresas de Sistemas Gerenciadores

de Banco de Dados oferecem APIs3 e componentes como soluções prontas para a criação de
aplicações de Business Inlelligence (termo utilizado atualmente para definir aplicações voltadas
à alavancagem dos negócios), passando a falsa impressão da simplicidade por trás de uma
ferramenta verdadeiramente OLAP. Essa tendência 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:
“Don´t Build, Buy It” . Ou seja, o investimento e o tempo despendido na construção de uma
solução caseira não traz resultados aparentes e, em sua maioria, resulta em projetos fracassados
ou produtos com carência interminável de manutenção.
O ideal é adquirir uma ferramenta OLAP com as características e particularidades que

analisaremos adiante. É importante conhecer o que uma verdadeira ferramenta OLAP
deve prover aos seus usuários.
3
Application Program Interface – Um conjunto de funções predefinidas, documentadas e disponibilizadas por um
software que servem de interface para outras aplicações interagirem com o mesmo. “Um Software A” pode
fornecer uma API e a mesma ser usada por um “Software B”, possibilitando uma interface (ligação) entre eles.
OLAP X OLTP
Os bancos de dados desenvolvidos para OLTP (On-Line Transaction Processing, ou
processamento de transações on-line) geralmente são considerados inapropriados para
Data Warehouses. Eles não podem ser repositórios de fatos e dados históricos, não atendem
satisfatoriamente a consultas e a recuperação rápida dos dados é praticamente impossível.
Os dados estão em constante mudança. Basicamente, os bancos OLTP oferecem grandes
quantidades de dados brutos que não são facilmente compreendidos.
Em contraste com os sistemas OLTP, as ferramentas OLAP oferecem um grande potencial de

recuperação e análise de informações rápida e fácil. O processamento OLAP provê acesso
aos dados corporativos de um Data Warehouse com total segurança e controle, e provê aos
usuários todas as flexibilidades existentes em programas dedicados à análise de dados.
A tecnologia OLAP dispõe de um conjunto de operações e ferramentas que torna o

usuário capaz de lidar com a complexidade das planilhas. É possível analisar tendências,
fazer comparações, destacar problemas e manipular as informações em qualquer ordem.
Vejamos as principais diferenças entre os processamentos OLAP e OLTP na tabela a seguir.
Tabela 3.1: Diferenças entre OLAP e OLTP
OLAP OLTP
Relevância para dados históricos Mantém usualmente a situação corrente.
Necessidade de ver o dado sob Voltado para velocidade e automação de

diferentes perspectivas: aplicações funções repetitivas.
dinâmicas
Atualizações quase inexistentes, apenas Atualizações em grande número.

novas inserções
Baseado em dados históricos, Baseado em transações

consolidados e freqüentemente
totalizados
Operações de agregação e cruzamentos Alto nível de detalhe
Características
A principal característica dos sistemas OLAP é permitir uma visão conceitual multidi-
mensional dos dados de uma empresa. Os dados são modelados numa estrutura conhecida
por cubo (Figura 3.1), onde cada dimensão representa os temas mais importantes da
empresa como produto, cliente, funcionário e tempo.
Figura 3.1: Cubo de 4 dimensões
Muitos usuários se perguntam por que uma simples planilha não pode ser considerada
uma ferramenta OLAP. Sabemos que o termo planilha vem de plano (duas dimensões
apenas), não permitindo, em linhas gerais, uma visão multidimensional dos dados. Além
da visão multidimensional dos dados da empresa, existem também 11 regras criadas
pelo Dr. Codd em 1993 que servem para avaliar uma ferramenta considerada OLAP. No
total temos 12 regras que são descritas a seguir:
■ Visão conceitual multidimensional: os dados são modelados em diversas dimensões
podendo haver cruzamento de todos os tipos de informações.
■ Transparência: OLAP deve atender a todas as solicitações do analista, não
importando de onde os dados virão. Todas as implicações devem ser transparentes
para os usuários finais.
■ Acessibilidade: as ferramentas OLAP devem permitir conexão com todas as bases de

dados legadas. A distribuição de informações deve ser mapeada para permitir o acesso
a qualquer base.
■ Desempenho de informações consistentes: as ferramentas OLAP devem possuir
conhecimento sobre todas as informações armazenadas para que possa disponibilizar,
sem complexidade para o usuário final, qualquer tipo de consulta.
■ Arquitetura cliente/servidor: OLAP deve ser construída em arquitetura cliente/ servidor
para que possa atender a qualquer usuário em qualquer ambiente operacional.
■ Dimensionalidade genérica: deve ser capaz de tratar informações em qualquer
quantidade de dimensões.
■ Manipulação de dados dinâmicos: devido ao grande volume de informações
armazenadas nas diversas dimensões de um modelo multidimensional, é comum a
espacidade dos dados, e então essas células nulas devem ser tratadas para evitar custos
com memória.
■ Suporte a Multiusuários: nas grandes organizações é comum vários analistas
trabalharem com a mesma massa de dados.
■ Operações ilimitadas em dimensões cruzadas: as ferramentas OLAP devem ser capazes
de navegar nas diversas dimensões existentes.
■ Manipulação intuitiva dos dados: o usuário deverá ser capaz de manipular os dados
livremente, sem necessitar de qualquer tipo de ajuda.
■ Flexibilidade nas consultas: o usuário deverá ter a flexibilidade para efetuar qualquer
tipo de consulta.
■ Níveis de dimensão e agregação ilimitados: devido às várias dimensões existentes,
deve haver vários níveis de agregação dos dados.
Conjunto de Operações OLAP

Geralmente, ao iniciar uma consulta, o usuário tem perguntas como: “Qual o vinho mais
vendido no período de 2001 a 2003?”. Para que essa pergunta seja traduzida de forma
inteligível ao computador, devem ser oferecidos aos usuários meios para realizar tal
tarefa. Os fabricantes OLAP adotaram diversas soluções.
Uma primeira tentativa foi a de oferecer uma tela com interface gráfica, onde botões,
listas e marcadores compõem o cenário da análise. Essa solução não se mostrou eficiente
para uma primeira consulta, pois o usuário fica restrito a uma interface predefinida.
Essa abordagem é eficiente para modificação de um cenário atual produzido a partir de
consultas iniciais e intuitivas. O usuário tem a liberdade de incrementar a consulta com
o uso desta interface.
Em uma segunda tentativa foi implementado um conjunto de instruções para compor

uma extensão SQL4 , onde o usuário monta o cenário conforme a digitação de comandos.
Essa abordagem é a mais flexível, embora não seja a mais popular, já que geralmente os
usuários OLAP não detêm os pormenores técnicos das linguagens de programação.
Após a montagem do cenário de uma consulta, freqüentemente o analista de negócios

deseja mudar o resultado da análise. De nada adiantaria a montagem se não houvesse
meios de manipulação. Atualmente as ferramentas OLAP fornecem suporte para funções
de derivação de dados complexos, que recebe o nome de Slice and Dice.
O suporte Slice and Dice é uma das principais características de uma ferramenta OLAP.
Ele serve para modificar a ordem das dimensões, alterar linhas por colunas de maneira a
facilitar a compreensão dos usuários. Essa característica é de extrema importância, pois
com ela podemos analisar as informações de diferentes prismas, permitindo ao usuário
investigar diferentes inter-relacionamentos. O Slice and Dice compreende quatro
operações: Ranging, Drilling, Rotation e Ranking.
Ranging
É a operação responsável por, a qualquer momento, alterar o resultado das consultas,
inserindo novas posições ou removendo as que estão em foco. Para que isto ocorra é
preciso que o usuário informe o que está modificando e o que será feito. Por exemplo, a
inserção de um novo produto em uma consulta. O resultado desse Ranging será
considerado para todas as demais operações, ou seja, pode-se encarar o resultado como
um novo cubo gerado a partir do cubo original.
4
SQL – Structured Query Language – Linguagem de manipulação e definição de dados de um Banco de
Dados Relacional.
Drilling
Após escolher o que deseja analisar, o analista ainda pode mudar o escopo do que está
analisando, porém essas informações podem encontrar-se agregadas em diversos níveis.
O Drilling permite navegação por entre estes níveis. Existem três operações 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 dimensão Produto

para uma organização de restaurantes, onde podem
ser efetuadas as operações de Drilling.
Drill Down
Esta operação navega verticalmente na hierarquia no sentido em que os dados são mais
atômicos. Considerando a Figura 2.4 é possível 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 usuário precisa montar o seguinte cenário:

■ Uma visão com os tipos de produtos
■ Uma outra visão com o total de vendas de todos os pratos
■ Posição: Mês: Maio, Ano: 1999
O primeiro resultado poderia ser do tipo:
Figura 3.3: Resultado (Para Mês = Maio e Ano = 1999).
Com esse resultado o analista não pode tomar nenhuma decisão. Para que os dados
sejam mais específicos será preciso utilizar o conceito de Drilling, para que seja alterado
o escopo da análise.
A fim de conseguir informações mais detalhadas sobre os pratos de Massas e Carnes, o

analista precisará navegar ao longo das hierarquias de cada dimensão, até chegar no nível
mais específico de cada prato. Executando o DrillDown em Massas obtém-se o seguinte:
Figura 3.4: Resultado do DrillDown em massas.
O resultado mostra que o motivo da elevação das vendas de Massas foi gerado pela
notável saída de Pizzas.
Drill Across
Esta operação permite navegar transversalmente no eixo da árvore hierárquica. O Drill
Across é uma operação de grande utilidade, pois permite inserir e retirar posições do
cenário corrente.
Continuando com o exemplo anterior, se quisermos comparar a vendagem de Pizzas

com os demais pratos de Carnes, precisaríamos navegar no mesmo nível de detalhe das
posições da dimensão. Neste caso, o resultado seria o seguinte:
Figura 3.5: Resultado do Drill Across.
Drill Up
A última operação do Drilling realiza a função inversa do Drill Down. Ela permite ao
usuário uma visão mais agregada das informações. Nesta técnica podemos navegar nos
diversos níveis até o mais sumarizado.
Aplicando Drill Up no exemplo acima poderíamos obter:
Figura 3.6: Resultado do Drill Up.
Rotation
Além de mudar as posições em foco, o analista também tem a flexibilidade de alterar a forma de
visualização das informações. O Rotation permite ao analista mudar a visão que está tendo dos
dados. Vale salientar que o Rotation não adiciona nem retira posições do cenário. A grande
vantagem do Rotation é que não há operações de disco no servidor para que os dados sejam
vistos de forma diferente. O que muda é apenas como os dados serão dispostos para o usuário.
O exemplo anterior está analisando os tipos de produtos e seus totais. Aplicando o Rotation
é possível obter uma análise com os tipos de produtos e seus respectivos preços.
Ranking
Com esta operação o analista pode filtrar as informações que ele deseja ver. É possível
fazer uma classificação dos dados obtidos e operar diretamente sobre os valores das
células. Vale frisar que as operações anteriores atuavam apenas sobre as posições ou
dimensões dos dados. Através do Ranking, o analista pode executar diversos tipos de
filtros, eliminando assim as informações desnecessárias.
Figura 3.7: Resultado sem aplicação 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 aplicação de Ranking.
Pelo exemplo acima, percebemos que não só 3 células 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 navegação de
um nível de detalhamento para outro “mais baixo” ou “mais alto” em tempo real.
Os bancos de dados multidimensionais surgiram para melhorar a relação custo/benefício

na implantação OLAP. Em resumo o MOLAP é uma classe de sistemas que permite a
execução de análises sofisticadas e exploração de dados usando como gerenciador um
banco de dados multidimensional.
Em um banco de dados MOLAP os dados são mantidos em arranjos que simulam um

cubo com n dimensões e indexados de maneira a prover um ótimo desempenho no acesso
a qualquer elemento. Combinando as dimensões, o usuário pode ter uma visão geral de
todos os dados da empresa num excelente desempenho.
Um array multidimensional tem um número fixo de dimensões e os valores são

armazenados nas células. Cada dimensão consiste de um número de elementos. Em outras
palavras, o cubo (Figura 3.9) é, de fato, apenas uma metáfora visual, uma representação
intuitiva do evento, pois todas as dimensões coexistem para todo ponto no cubo e são
independentes umas das outras.
Figura 3.9: Visão multidimensional do volume de

vendas de uma rede de concessionárias.
OLAP Relacional (ROLAP)

Como a maioria das empresas utiliza os Bancos de Dados Relacionais5, também surgiu,
paralelamente ao conceito de MOLAP, o conceito de ROLAP (Relacional OLAP) como
uma grande solução 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 análise multidimensional dos dados que estão 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 temporárias. De forma
inversa podem ser executados os comandos SQL para recuperação dos dados e posterior
processamento no servidor OLAP.
Os servidores ROLAP, além de possuírem as características dos sistemas OLAP, utilizam-

se de metadados (Capítulo 5), dados sobre dados, para descreverem o modelo dos dados
e auxiliarem a construção de consultas. Também são criados comandos SQL otimizados
para bancos de dados, ajudando o analista na utilização desta tecnologia.
Nas ferramentas ROLAP, o uso de uma camada semântica acima do esquema relacional permite
que os dados sejam apresentados ao usuário através do modelo multidimensional. Logo, interfaces
ou servidores ROLAP são definidos como sistemas OLAP que traduzem operações 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 tradução de consultas entre os dois modelos. Este esquema, denominado de esquema
estrela, permite a simulação de um Banco de Dados Multidimensional numa base relacional.
No Capítulo 4, estenderemos a explicação do esquema estrela.
Ferramentas ROLAP têm um menor desempenho em relação às ferramentas MOLAP,

sendo um fator crítico em grandes DWs.
Tendências
Atualmente, a maioria das ferramentas OLAP consegue acessar mais de um tipo de banco de
dados, ou seja, as mesmas são capazes de fazer uma espécie de processamento híbrido (ROLAP
5
Bancos de Dados Relacionais são bancos de dados onde os usuários vêem os dados como um conjunto de tabelas.
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 tendência natural é que todas as ferramentas OLAP do mercado atinjam esse patamar.
Uma outra tendência, que deve ser meta dos modernos Sistemas Gerenciadores de Banco
de Dados, é a presença, 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 à decisão.
Quando um SGBD proporciona tecnologia multidimensional dentro do seu banco de

dados, facilita o processo de escolha de uma organização, entre um banco de dados
multidimensional OLAP e um Banco de Dados Relacional. A idéia principal é
proporcionar o desempenho e a flexibilidade de um Banco de Dados Multidimensional e
manter a gerenciabilidade, escalabilidade6 , confiança e acessibilidade já conquistadas
pelos Bancos de Dados Relacionais.
A união de dois modelos em um único banco proporciona redução do tempo de atualização,

pois permite o armazenamento em tabelas relacionais ou multidimensionais. Assim, os
dados não são replicados em duas bases de dados. Tipicamente usam-se dois passos no
processo de manutenção (atualização do Data Warehouse, geralmente relacional, e
atualização do banco de dados multidimensional). Com um banco híbrido, o tempo entre
os dados serem disponibilizados pelos sistemas fonte e estarem prontos para serem
analisados é menor. Ganha-se também em acuracidade, porque os dados não precisam
ser replicados entre tabelas relacionais e tabelas multidimensionais, isto é, não há
sincronização. Todos os usuários têm acesso a uma única versão dos dados quando os
mesmos são alterados e gravados no banco de dados.
CRM
Atualmente, a maioria das empresas ainda possui problemas de visão de marketing. Mesmo
aquelas totalmente informatizadas e com processos bem definidos possuem falhas nos
processos de adaptação, comunicação, avaliação e análise dos seus mercados.
6
Escalabilidade é a capacidade que um sistema apresenta de poder adaptar-se facilmente a uma carga
crescente de recursos e serviços.
Para continuar a existir e crescer no mercado, as organizações devem conhecer a si mesmas

e principalmente conhecer, criar e manter os seus clientes. Administrar é hoje um exercício
constante de quebra de tradições teóricas estabelecidas. Nos últimos anos, grandes
corporações vêm concentrando esforços, independente da área em que atuam, para
conhecer bem os hábitos dos seus clientes. Todos aqueles que compõem 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 comercialização
não deve estar focada nos produtos, mas nas necessidades de cada consumidor.
Assim, numa empresa todos devem ser “vendedores”. Todos devem ter consciência de
que a sobrevivência e o sucesso da empresa dependem de cada um e não apenas do
Departamento de Vendas ou do Marketing. Exemplificando, até as pessoas da
contabilidade devem ser vendedores e fazer a diferença. A telefonista passa a ser
importantíssima, pois, às vezes, é o primeiro contato do cliente com a empresa.
Essa importante visão de marketing foi empacotada na sigla CRM (Customer Relationship
Management ou gerenciamento das relações com o cliente). O principal objetivo do CRM
é conquistar a fidelidade dos clientes satisfazendo suas reais necessidades de consumo.
Estamos diante de uma verdadeira revolução 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 prestação de serviços. A venda é
sinônimo da administração eficaz das contingências de compra. Para alcançar esse
patamar, a informação deve ser o principal produto. Vende quem sabe o que o cliente
quer, como ele quer e quando ele quer.
As empresas deverão ouvir os seus clientes, pois esta é a melhor maneira de

compreender o mercado; todavia, nem sempre o cliente sabe o que ele quer. Através
de uma boa análise de mercado, as organizações deverão 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 serviço novo e diferente.
Muitas empresas e produtos que fizeram sucesso não foram pedidos de clientes. Nós não
pedimos o telefone celular e vivemos hoje na dependência dele. Não pedimos sistemas
de computador com interface gráfica e estamos todos “mal-acostumados” com janelinhas
e botões amigáveis nas telas de computador.
Como não poderia deixar de ser, a tecnologia da informação desempenha e desempenhará

um dos papéis mais importantes neste processo de conquista e fidelização dos clientes.
Para aplicar o conceito de CRM, como veremos a seguir, as empresas deverão ter bancos
de dados (idealmente Data Warehouses) organizados e estruturados para servirem de
base na manutenção dos clientes.
Fidelização
Utilizaremos o termo “fidelizar”, porém sabemos que não existem clientes verdadeiramente
fiéis. Na verdade, as empresas devem buscar a agregação de novos valores às suas marcas,
pois clientes permanecem consumindo um produto ou serviço enquanto existem vantagens
para eles. Podemos metaforizar e dizer que clientes são “gatos” e não “cachorros”, ou seja,
“eu continuo com você enquanto a situação estiver confortável para mim”.
Portanto, “fidelizar” um cliente significa conquistá-lo, valorizando a relação para manter

por mais tempo. A base do CRM está na segmentação. A partir daí faz-se uma
diferenciação no tratamento. O resultado é a “fidelidade”.
Os clientes não podem ser tratados da mesma forma. Os que trazem mais rentabilidade,
ou maior volume, são 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 individualização faz a diferença, pois também existem casos de clientes que
deixam de consumir um produto não pelo maltrato e sim pela indiferença.
O pacote CRM traz um conjunto de processos para identificar o cliente certo, oferecer-
lhe o que interessa, no momento em que ele precisa, através 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 pão e leite durante 25 anos em uma padaria. Se este casal gastou em média
um dólar por dia, isto representou, ao longo dos 25 anos, US$ 9.125,00 para o dono da
padaria. Além disso, quantos clientes não foram conquistados com as recomendações do
casal? Cliente “fiel” significa cliente vendedor.
Para vender, o cliente, mais uma vez, precisa ser surpreendido. Ninguém vai ao cinema
e diz que viu uma tela gigante. O cliente fala do que o surpreendeu. Neste momento, os
leitores são nossos clientes. O nosso objetivo é escrever um livro que agrade e surpreenda
o leitor positivamente através de uma leitura fácil e compreensiva de assuntos mistificados
por muitos. Se os leitores gostarem deste livro, esperamos isso, recomendarão o mesmo
a amigos, colegas de profissão e de universidade. Um cliente satisfeito comenta com
cerca de 4 pessoas e um insatisfeito comenta com cerca de 10.
As Relações Virtuais Através da Internet

Nos próximos anos, estaremos comprando todos os produtos e serviços de que precisamos
através 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 também na relação 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. Estatísticas mercadológicas mostram que mais de 60% dos clientes
internet desistem de suas compras pela demora e dificuldade dos sites.
As empresas devem fornecer boas informações sobre os produtos que estão sendo
vendidos, diminuindo a incerteza do cliente e conseqüentemente diminuindo também o
número de desistências. Também é importante planejar a entrega dos produtos que estão
sendo vendidos, o chamado SCM – SupplyChain Management, pois empresas podem ter
sua imagem denegrida pela incapacidade de entrega de produtos vendidos via internet
ou através de outro canal. Todo o processo de entrega e o próprio acesso às compras
devem oferecer segurança ao cliente.
A tendência é que as organizações façam parcerias para entrega e armazenamento dos

seus produtos. O custo dos produtos não cai, mas o custo da compra sim. Toda competência
será transferida para a venda, ou seja, informações de qualidade, em abundância e com o
mínimo custo para acesso.
Para descobrir os interesses dos clientes (traçar o perfil) e oferecer os produtos certos em
sites internet, novamente, as corporações deverão ter Data Warehouses (Capítulo 2)
armazenando o histórico das compras dos clientes, suas reclamações, sugestões e etc.
Isto traz um novo conceito, o Database Marketing.
Database Marketing
Podemos definir marketing como o exercício de estar atento às tendências 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 aplicação de
marketing com o auxílio de Data Warehouses. A integração é a palavra-chave neste
processo, para que se tire proveito das informações já existentes sobre clientes, utilizadas
para uma realimentação eficiente do banco de dados de relacionamento.
O Data Warehouse para ser usado por ferramentas de Database Marketing deve
transformar todo o histórico de relacionamento entre clientes e fornecedores, contido na
base de dados operacional, em transformações segmentadas sobre o público da empresa,
pois não podemos nos relacionar com quem nós não conhecemos.
Todos os conceitos de BI (Business Inteligence) vistos até agora devem ser utilizados. O
passo inicial é construir um DW, em que informações dimensionais (tempo, produto,
cliente e etc.) facilitem aspectos de segmentação, permitindo um foco mais objetivo
sobre campanhas de marketing. Os conceitos de Data Mining (Capítulo 9), ou Mineração
de Dados, também poderão ser aplicados para descoberta de informação sobre clientes.
Após a construção do DW, o passo seguinte é manter o foco no cliente como diretriz
para alcançar os objetivos do negócio. O conhecimento do cliente em todas as dimensões
é o componente fundamental do processo, sendo portanto necessário dispor de grande
variedade de dados e informações, dentre as quais podem ser citadas:
■ Dados cadastrais completos ou primários.
■ Informações sobre a composição familiar.
■ Histórico do relacionamento com a empresa.
■ Aspectos que caracterizam o cliente como uma entidade individualizada.
■ Hábitos e preferências de consumo, considerando produtos e serviços de um modo geral.
O processo de planejamento do negócio é efetuado de acordo com o mercado alvo em

que a organização deseja atuar. O perfil dos clientes permitirá que seja realizada a
segmentação dos clientes e seja feita a análise do risco associado à operação geral da
empresa. Este processo é cíclico e sua precisão apresenta uma estreita relação com a
disponibilidade de uma ampla gama de dados atuais e históricos, além de projeções
sobre a evolução dos tópicos considerados durante os processos de análise e de simulação.
Os mecanismos de acompanhamento e de controle permitirão a monitoração do alcance

das metas estabelecidas, a identificação da ocorrência de eventuais desvios e a execução
de ações corretivas e/ou proativas adequadas para cada área de atuação.
Figura 3.10: Visão do relacionamento existente entre o

foco no cliente e o processo do negócio pretendido.
O foco no cliente exige que as informações sejam geradas a partir da combinação dos
dados tratados por diversos aplicativos existentes no ambiente convencional. A eficiência
do processo de negócio está intimamente ligada à disponibilidade de recursos para a
análise de alternativas e avaliação do risco associado com cada uma delas.
Focar no cliente significa basicamente tratar clientes diferentes de forma diferente. Os

principais objetivos são:
■ Identificar os clientes que dão prejuízo à empresa. Como eles nunca vão desaparecer,
não adianta desprezá-los. A empresa deve descobrir quanto custa atendê-los para
diminuir ou eliminar este custo;
Figura 3.11: Processo de negócio.
■ Identificar e manter clientes mais lucrativos. Conhecendo as preferências individuais

de seus melhores clientes, as empresas podem personalizar sua oferta de serviços e
produtos para os mesmos;
■ Identificar e desenvolver relacionamentos com clientes de maior potencial. O cliente
pode ter necessidades que são satisfeitas pela concorrência.
As empresas deverão focar inicialmente nos clientes que já são fiéis para depois continuar
na busca incessante por novos clientes, pois é mais barato manter do que conquistar
novos clientes. Atingir este foco não é simples e pode significar mudanças na estrutura
de toda a organização, 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 publicação desse ensaio,
a palavra OLAP transformou-se em uma buzzword no cenário de bancos de dados, e
todo profissional de sistemas esforçava-se para compreender a OLAP e como ela se
encaixava no paradigma de aplicações de suporte à decisão.
Além de definir OLAP, o Dr. Codd também criou 12 regras para OLAP. No entanto,
OLAP, conforme definida pelo Dr. Codd, não é uma nova tecnologia e alguns produtos já
existiam há tempos no mercado. Basicamente, um sistema OLAP é qualquer sistema que
capture informações sumarizadas, e permita que essas sumarizações sejam apresentadas
com suporte para funções de derivação de dados complexos. Este suporte recebe o nome
de Slice and Dice.
O suporte Slice and Dice é uma das principais características de uma ferramenta OLAP.
Ele serve para modificar a ordem das dimensões e alterar linhas por colunas de maneira
a facilitar a compreensão dos usuários. Essa característica é de extrema importância,
pois com ela podemos analisar as informações de diferentes prismas, permitindo ao
usuário investigar diferentes inter-relacionamentos. O Slice and Dice compreende quatro
operações: Ranging, Drilling, Rotation e Ranking.
Além das ferramentas OLAP as empresas estão investindo em aplicações voltadas para o
conhecimento do mercado e dos seus clientes. Essa importante visão de marketing foi
empacotada na sigla CRM (Customer Relationship Management ou gerenciamento das
relações com o cliente). O principal objetivo do CRM é conquistar a fidelidade dos clientes
satisfazendo suas reais necessidades de consumo. Estamos diante de uma verdadeira
revolução 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.
Database Marketing (DBMKT) é o termo que está sendo usado por especialistas
para definir a aplicação de marketing com o auxílio de Data Warehouses. A integração
é a palavra-chave neste processo, para que se tire proveito das informações já
existentes sobre clientes, utilizadas para uma realimentação eficiente do banco de
dados de relacionamento.
O Data Warehouse, para ser usado por ferramentas de Database Marketing, deve
transformar todo o histórico de relacionamento entre clientes e fornecedores, contido na
base de dados operacional, em transformações segmentadas sobre o público da empresa,
pois não podemos nos relacionar com quem nós não conhecemos.
Capítulo 4: Modelagem de Dados Para Data Warehouses 47
4
C A P Í T U L O
Modelagem de Dados
Para Data Warehouses
Por que Não Usar o Modelo

Entidade e Relacionamento Tradicional?
Como vimos no Capítulo 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 publicação 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 redundância muito baixa. As regras de
normalização de Codd orientavam o projetista a criar uma estrutura lógica de tabelas
sem qualquer redundância.
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 responsável pela melhora fenomenal na velocidade de
processamento das aplicações transacionais a partir de 1980. O segredo dessa modelagem
é remover qualquer redundância dos dados, pois em havendo qualquer inserção, alteração
ou exclusão de dados será preciso uma atuação 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 gráfica (DER) e
textualmente as estruturas, operadores e regras que definem os dados. Os princípios
básicos são identificar os itens relevantes, geradores de informação para o processamento
do sistema (objetivos), identificar a manipulação dessas informações (entradas e saídas)
e identificar as regras que regem o surgimento das informações (restrições). Ao
desenharmos um DER (principal componente do Modelo Entidade e Relacionamento)
criamos uma abstração dos dados e representamo-la graficamente.
Essa modelagem é eficiente para as aplicações transacionais, onde os dados são acessados
individualmente, mas quando se trata das complexas consultas do mundo dos negócios,
esse modelo falha.
Nesse modelo, os dados são divididos em várias entidades distintas (retângulos) e cada
entidade é transformada em uma tabela (vide Figura 4.1). Essa característica gera alguns
problemas que fazem o diagrama ficar complexo e de difícil visualização e memorização,
tanto pelo usuário final quanto pelos projetistas.
Figura 4.1: Parte de um Diagrama Entidade e Relacionamento (DER)

de um Sistema de Vendas para Restaurantes.
Devido ao grande número de tabelas, fica impraticável realizar consultas complexas, já

que é preciso fazer um grande número de conexões entre as mesmas. Outro grande
problema é a simetria do modelo, pois as tabelas são muito parecidas, muitas vezes não
são povoadas e possivelmente poderá haver diferentes respostas para consultas com
objetivos idênticos, elaboradas sem o total conhecimento da semântica do modelo. Não
é possível distinguir quais as tabelas mais importantes ou dominantes no modelo (simetria).
Além desses problemas, esse modelo não foi projetado para armazenar dados históricos.
Constantemente há atualização na base de dados e informações históricas são perdidas.
Na projeção de bases de dados para Data Warehouses, deve-se quebrar o paradigma da

eliminação de redundâncias em um modelo de dados (normalização) e buscar armazenamento
histórico. Desnormalizando algumas tabelas, o projetista do DW busca ganhar desempenho
nas consultas. Contudo, não se deve introduzir redundância em qualquer lugar do modelo. A
redundância sempre traz um preço a ser pago, seja o custo de armazenamento em disco ou o
custo da manutenção de um esquema de atualização em paralelo.
Star Schema (Esquema Estrela)

Sendo rigorosamente fiéis aos conceitos de bancos de dados, não chamaremos o esquema
estrela de modelo, pois o mesmo é apenas uma forma de dispor as tabelas do modelo
relacional para a simulação de um banco de dados multidimensional.
O conceito Star Schema foi criado pelo Dr. Ralph Kimball e tem como característica
básica a presença de dados altamente redundantes para se obter um melhor desempenho.
Essa desnormalização ocorre devido a junções de tabelas para que não haja necessidade
de ocorrerem estas junções em tempo de execução.
O nome Star Schema foi adotado pela semelhança com uma estrela. Este esquema é
composto de um tabela dominante, chamada tabela de fatos, no centro, rodeada por
tabelas auxiliares, chamadas de tabelas de dimensão. A tabela de fatos conecta-se às
demais por múltiplas junções e as tabelas de dimensões se conectam com apenas uma
junção à tabela de fatos (vide Figura 4.2).
Dimensão Produto
Id_Produto
Descrição
Dimensão Tempo
Tipo
Id_Tempo Fatos Vendas Preço
Dia Id_Tempo
Mês Id_Produto
Ano Id_Funcionário
Dia_Semana Dimensão Funcionário
Unid_Vendida
Feriado Valor_Vendas Id_Funcionário
Semestre Nome
Trimestre Endereço
Telefone
RG
CPF
Figura 4.2: Exemplo de Esquema Estrela
Neste esquema a consulta ocorre inicialmente nas tabelas de dimensão e depois na tabela
de fatos, assegurando assim a precisão dos dados através de uma estrutura completa de
chaves onde não é preciso percorrer todas as tabelas. Isso garante um acesso mais eficiente
e o mais alto desempenho possível.
As tabelas dimensionais são desnormalizadas para aumentar o desempenho e armazenam

as informações a respeito das dimensões dos dados. Cada coluna deverá conter descrições
textuais significativas para os usuários e deverão ser apropriadas para relatórios.
Figura 4.3: Exemplo de tabela de dimensão.
A tabela de fatos armazena grande quantidade (tabelas de dimensão são menores) de

dados históricos (normalmente numéricos) em função do tempo, obtidos a partir da
intersecção de todas as dimensões da estrela. Cada dimensão tem uma chave primária7
que corresponde a um dos campos da chave da tabela de fatos. A dimensão tempo é
sempre integrante da chave primária e é na tabela de fatos onde armazenamos os
indicadores de desempenho (medidas) do negócio.
Figura 4.4: Exemplo de tabela de fatos.
Ao contrário do modelo entidade e relacionamento tradicional, o esquema estrela é

assimétrico, pois podemos perceber nitidamente a tabela de fatos como dominante. Além
disso, este esquema é flexível para suportar a inclusão de novos elementos de dados,
bem como mudanças que ocorram no projeto. Essa flexibilidade se dá na medida em que
todas as tabelas de fatos e dimensões podem ser alteradas simplesmente acrescentando
novas colunas às mesmas e nenhuma ferramenta de consulta ou relatório precisa ser
alterada de forma a acomodar essas mudanças.
7
Chave primária é 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 primária.
Tipos de Dimensão
As dimensões em um esquema estrela representam entidades que evoluem ao longo do
tempo. A descrição e a formulação de produtos evoluem, pessoas modificam seus nomes,
casam-se e divorciam-se, aumentam o número de filhos e trocam de endereço, etc. Assim,
deve-se decidir o que fazer quando estas mudanças ocorrem.
Se quisermos acrescentar estas modificações à tabela de fatos ou criarmos dependências

entre a dimensão tempo e as demais dimensões, estaremos retornando a uma estrutura
altamente relacionada e perderemos desempenho. Como a maioria das dimensões é
constante ao longo do tempo, podemos optar por três formas de tratamento destas
modificações como veremos a seguir.
Dimensão Tipo 1
Quando o histórico não é relevante, substituímos valores antigos dos registros da
dimensão e, portanto, perdemos a capacidade de rastrear o histórico passado.
Exemplificando, suponhamos que o funcionário Joaquim tenham casado; simplesmente
substituímos o valor contido no campo “Estado Civil” do registro de Joaquim por
“Casado”. Não é necessário fazer outras modificações no registro da dimensão, e
nenhuma chave do banco de dados será alterada.
Dimensão Tipo 2
Adicionamos um registro à dimensão contendo os novos valores do atributo no momento
da mudança, com o intuito de segmentar o histórico entre a descrição antiga e a nova
descrição. Chaves artificiais são de extrema importância neste caso (vide seção Chaves
Artificiais). Vejamos o exemplo do produto cocktail em uma cadeia de restaurantes.
Para o cocktail, imaginaremos que o registro da dimensão produto represente um

determinado código único. A partir de algum ponto no tempo, digamos 20 de março de
2000, a formulação do conteúdo do cocktail muda de com álcool para sem álcool,
refletindo uma alteração significativa nos ingredientes da bebida. No segmento dos
restaurantes essa situação ocorre com freqüência e rotineiramente é criado um novo
código único para descrever o produto alterado. Nesse contexto, notamos que o código
nada mais é que uma chave lógica, mantida pelo fabricante da bebida.
Quando observamos o banco de dados de vendas do restaurante, não notamos uma divisão
do histórico. O antigo cocktail continuará a ser vendido no restaurante após 20 de março
de 2000, até o final do estoque. Isso variará de restaurante para restaurante. Os novos
cocktails serão comercializados a partir de 20 de março de 2000 e gradualmente
substituirão os antigos. Haverá um período de transição em que os dois tipos de cocktail
serão vendidos nos restaurantes. Os caixas reconhecerão os dois códigos e não encontrarão
dificuldades em manipular a venda de cada uma das bebidas. Assim, o uso de registros
separados na dimensão divide a tabela de fatos automaticamente e o usuário não precisa
preocupar-se com as duas formulações do cocktail, a menos que esteja usando o campo
“Conteúdo de Álcool”.
Como o histórico é dividido não poderemos usar o novo valor de um atributo no histórico
antigo, ou vice-versa. Se criarmos a restrição em uma consulta “Conteúdo de Álcool =
Nenhum”, não veremos nenhum cocktail antes de 20 de março de 2000. De modo geral
é o que desejamos. Raramente queremos saber qual seria o histórico caso a alteração não
tivesse ocorrido. Observe na Figura 4.5 que é criado um novo “Id Produto” (chave artifi-
cial) e são atualizadas as datas de início e fim de validade do registro.
Figura 4.5: Dimensão Tipo 2.
Dimensão Tipo 3
Se quisermos usar um novo valor de atributo para consulta em um histórico antigo, criamos
novos campos “atuais” no registro original da dimensão para incluir os novos valores,
mantendo também seus valores originais. Desta forma, permitimos a descrição do histórico
anterior e o posterior à mudança tanto em relação aos valores originais do atributo quanto
aos valores atuais. Em análises de vendas, quando um mercado muda, inicialmente é
sempre viável rastrear tanto os valores antigos como os modificados do mercado ao
longo do tempo. Não criamos um novo registro, mas adicionamos um campo no atributo
modificado do mercado. No caso de uma mudança de estado civil, por exemplo,
adicionamos um novo campo denominado “Estado Civil Atual” e provavelmente

mudaremos o nome do campo “Estado Civil Antigo” para “Estado Civil Original”.
Adicionamos também um campo “Data de Início do Estado Civil”. Sempre que houver
uma modificação do “Estado Civil” substituímos o valor do campo “Estado Civil Atual”
e mudaremos a “Data de Início”. Nunca modificamos o “Estado Civil Original”. Dessa
forma, podemos rastrear todo o histórico 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 histórico com base na modificação será por meio do
campo “Data de Início”.
A dimensão de tipo 3 não pode ser utilizada para descrever com precisão modificações
como o exemplo da bebida cocktail. É impossível saber com precisão quantos restaurantes
esgotaram o estoque dos cocktails antigos. Isso ocorre comumente quando o fabricante
muda a formulação de um produto, mas não cria um novo código único. Nesse caso, os
relatórios de vendas obtidos por meio do campo não têm como distinguir as formulações.
Com o tipo 3 podemos manipular apenas o valor original e o atual do atributo modificado.
Os valores intermediários são perdidos. Caso haja necessidade de dividir o histórico com
precisão, deve-se optar pelo tipo 2 e toda a gama de modificações poderá ser rastreada. Não
é viável combinar os tipos 2 e 3, pois isso resultará em um aumento da complexidade das
aplicações. O tipo 3 também aumenta a complexidade e só deve ser utilizado em casos de
necessidade extrema, pois, em muitos casos, nomes de atributos anteriores são geralmente
esquecidos e abandonam-se as comparações com valores originais do mercado.
Pequenas Dimensões Para

Auxílio de Dimensões Grandes
Para aumentar o desempenho de pesquisas e restrições, podemos acrescentar ao modelo
dimensões pequenas que auxiliarão no registro de modificações de dimensões
relativamente grandes como a de clientes, por exemplo. O objetivo é não penalizar a
consulta na tabela de fatos utilizando uma grande e cara dimensão.
Transferimos para a pequena dimensão 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 nível salarial e escolaridade, colocamos na pequena dimensão
todas as combinações possíveis de níveis salariais e escolaridade; desta forma, quando
ocorrer uma modificação do perfil de um cliente, bastará mudarmos para uma chave de
Instrução (pequena dimensão) diferente, à medida que carregamos os registros da tabela

de fatos em períodos regulares. Não precisamos criar um novo registro na dimensão
cliente porque a pequena dimensão contém todos os perfis salariais de que necessitamos.
Incluindo a chave de “Instrução” na tabela cliente, seria necessário criar um novo registro
cliente para rastrear a correspondência entre as instruções modif icadas. Não
recomendamos isso, pois o ideal é substituir a chave “Instrução” nos novos fatos sempre
que houver uma modificação. Dessa forma, podemos pesquisar o perfil salarial atual
juntamente com os outros atributos do cliente a qualquer momento. O histórico passado
de perfis pode ser construído sempre que necessário, consultando-se a tabela de fatos e
selecionando o “Id do cliente” e sua chave “Instrução”, que de modo geral será diferente
da chave instrução atual.
Dimensão Instrução
Id_Instrução
Nível_Salarial
Fatos Vendas Escolaridade
Id_Tempo
Id_Instrução
Dimensão Cliente
Id_Cliente
Unid_Vendida Id_Cliente
Valor_Vendas Nome
Endereço
Telefone
RG
CPF
Figura 4.6: Estrela com pequena dimensão.
Dimensões Descaracterizadas
Chamamos de dimensões descaracterizadas chaves de dimensão sem uma tabela de
dimensão correspondente. Podemos ter números de controle, como por exemplo números
de notas fiscais e/ou pedidos representados como dimensões descaracterizadas. Migramos
o número 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).
Figura 4.7: Dimensão Descaracterizada Pedido.
Chaves Artificiais
Quando projetamos um DW não podemos cometer o erro de utilizar a mesma chave
significativa utilizada no sistema fonte para as dimensões. Quando utilizamos a mesma
chave, reduzimos a flexibilidade do esquema, diminuímos o desempenho e aumentamos
o trabalho de manutenção.
Ao utilizarmos chaves artificiais (Ids nos exemplos deste livro) geradas que não possuam
relação significativa com os dados que descrevem, ganhamos flexibilidade e um melhor
desempenho do Data Warehouse.
As diferenças entre chaves significativas e chaves não significativas existem em diversos

níveis. Através da normalização de dados em sistemas fontes transacionais, as chaves
significativas, também chamadas de lógicas, são freqüentemente representadas por mais
de uma coluna, dependendo do nível de sumarização que representam. Todavia, as chaves
artificiais são sempre uma única coluna por dimensão. A utilização de chaves artificiais
em vez de chaves lógicas traz diversas vantagens, tais como:
■ Se surgirem novos níveis de sumarização, a estrutura física das tabelas que
compartilham da chave artificial não se modifica, só muda o conteúdo das chaves e o
número de linhas.
■ Uma redução no tamanho da chave primária indexada, aumentando o desempenho
(vide Capítulo 8).
■ Facilidade no armazenamento de histórico em dimensões do tipo 2, pois quando
uma atualização é feita no registro de uma dimensão, uma nova chave é gerada com
os novos dados e a anterior permanece fazendo referência ao valor histórico. Por
exemplo, na mudança do Estado Civil de um cliente, são armazenados os dados da

época de solteiro e o registro atual de casado. Isso mantém um histórico total da
vida do cliente.
Devemos ignorar as chaves lógicas e gerar números inteiros seqüenciais, ou seja, as

colunas que formam a chave lógica permanecem e acrescentamos um seqüencial 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.
Dimensão Tempo
A princípio, um projetista de DW pode questionar se é realmente necessário criar uma
tabela de dimensão tempo. O questionamento baseia-se na pergunta: “Se eu coloco uma
data na minha tabela de fatos, não posso extrair qualquer informação relativa ao tempo
através do banco de dados?”.
Com a dimensão tempo procuramos armazenar descrições que não podemos extrair
utilizando funções nativas dos bancos de dados. Um banco de dados, por exemplo, não
pode informar-nos se em um determinado dia era feriado ou não (vide Figura 4.9).
Além disso, o armazenamento de descritivos na dimensão tempo aumenta o desempenho
das consultas, pois não há necessidade do uso de funções do banco de dados para gerar
estas descrições.
Figura 4.9: Exemplo de dimensão tempo.
A dimensão tempo também pode descrever períodos fiscais, temporadas e etc.
Hierarquias
Como ferramentas OLAP suportam que as hierarquias sejam representadas em uma única
tabela de dimensão, é viável adotar esta solução. Para o exemplo de produtos, podemos
ter registros em níveis mais altos de granularidade (grupo), ou seja, com alguns campos
nulos, e registros nos nível mais baixo (produto) com todos os campos preenchidos.
Vejamos o exemplo da Figura 4.10:
Figura 4.10: Exemplo de dimensão com hierarquia.
Alguns projetistas optam por criar tabelas de dimensão derivadas para representar cada nível
hierárquico como uma tabela física diferente no banco de dados. Isto pode ser interessante
quando membros da hierarquia possuem propriedades relevantes e quando análises realizam
consultas diretas por valores destes membros. A tabela de dimensão principal permanece
inalterada, mantendo a hierarquia completa, criando-se tabelas derivadas (tipo, por exemplo)
para facilitar agrupamentos por valores de membros específicos. Supondo que haja necessidade
de recuperar os totais de vendas de massas verdes, haverá inicialmente uma filtragem na
tabela de tipos (tabela normalizada – menor redundância) e depois a busca na tabela de fatos,
já que o “Id” da tabela derivada também é migrado para a mesma.
Não costumamos usar esta abordagem, pois ela aumenta o número de tabelas no esquema.
Agregados
Em um DW, chamamos de granularidade o nível de detalhe das tabelas. Quanto maior o
nível de detalhe, menor a granularidade.
A agregação é o processo de resumir dados granulares ou detalhados e de armazenar

fisicamente as agregações na tabela de fatos ao longo de uma hierarquia. Toda sumarização
é uma redundância por excelência, porém a agregação 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 nível de granularidade de produto e uma tabela de fatos
agregada que armazena dados em nível de grupo. Isto é viável se muitas consultas são
feitas por totais de Grupo. Neste caso, as somas dos valores das vendas por grupo já vão
estar prontas, agilizando assim estas consultas.
Figura 4.11: Estrela com agregado.
Em casos muito críticos, podemos optar por acrescentar o campo grupo na tabela com
menor granularidade com intuito de otimizar o desempenho da agregação por grupo.
Isto é comum em casos com dimensões descaracterizadas. Se tivermos notas ficais como
sendo integrantes de um pedido, podemos construir uma tabela de fatos de notas fiscais,
acrescentando o número 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 geração de muitas agregações pode resultar em uma explosão do tamanho do Data

Warehouse. Por este motivo, muitas ferramentas OLAP incorporam uma tecnologia de
agregação que resolve de modo eficiente as questões quanto à determinação de quando
recuperar um valor agregado armazenado ou quando recuperar o dado de detalhe e realizar
uma agregação 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 dimensões como o número de unidades
vendidas, por exemplo.
■ Semi-Aditivos: podem ser adicionados ao longo de algumas dimensões. Podemos citar
como exemplos níveis de estoque e medições de intensidade como temperatura. Não
faz sentindo somar temperaturas, porém faz sentido calcular uma média.
■ Não-aditivos: não podem ser somados de forma alguma. São exemplos: tipo de
vendedor ou tipo de cliente. Um fato como esse é usado na realização de contagens
para resumo de registros ou para análise um a um dos registros do fato. Se
acrescentarmos a uma tabela de fatos o indicador total de vendas até o momento, não
podemos somar estes valores ao longo dos dias.
Um Estudo de Caso Para Definição

dos Passos da Modelagem Dimensional
Suponhamos que temos uma rede de restaurantes composta de 50 filiais localizadas em
vários estados. Cada filial oferece mais de 1000 produtos diferentes entre bebidas e
pratos. A direção do restaurante pretende analisar as vendas, custos e lucros. Festivais
(promoções) são utilizados para atrair clientes e potencializar as vendas.
Para projetar estrelas com intuito de gerar informações gerenciais, o engenheiro de soft-
ware deve identificar qual subconjunto do modelo de negócio será usado. No Capítulo 7
apresentamos uma metodologia para especificação de requisitos de um DW.
Neste caso específico, optaremos por verificar o movimento diário de cada produto. O
objetivo é verificar os produtos vendidos, preços e filiais que efetuaram a venda ao
longo do tempo.
Depois de definida a parte do modelo de negócio a ser analisada, devemos decidir qual
granularidade será usada para a parte escolhida. No nosso caso poderíamos analisar os dados
em nível de nota fiscal e verificar o movimento diário e/ou mensal dos produtos por filial.
Figura 4.12: Estrela Vendas de uma rede de restaurantes.
O terceiro passo é definir as dimensões que participaram da estrela. Quando escolhemos

o nível de granularidade da tabela de fatos, dimensões podem surgir naturalmente. Ao
escolher uma dimensão é viável verificar se todas podem ser relacionadas ao nível de
granularidade escolhido sem gerar duplicações e se as dimensões correspondem ao que
foi quantificado na tabela de fatos.
Por fim, escolhemos os fatos mensuráveis que irão 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.
Dúvidas Comuns de Projetistas de DW

■ Qual a granularidade que devo adotar? Na dúvida, escolha sempre o nível de
detalhamento menor. Desta forma, a tabela de fatos pode ser facilmente estendida
pela adição de novos fatos, novos atributos de dimensão ou adição de nova dimensão
completa. Seu esquema não ficará limitado e não haverá arrependimento futuro.
■ Quantas dimensões meu esquema pode ter no máximo? Geralmente temos de 4 a 15
dimensões. Esquemas com mais de 20 dimensões aparentam ter dimensões que
poderiam ser combinadas a outras, eliminando-as.
■ Posso acrescentar novos indicadores na tabela de fatos? Sem problemas, desde que
os mesmos correspondam às dimensões do esquema.
■ Em que momento atualizar uma dimensão do tipo 2? Se ao carregar os fatos também
são carregadas as novas alterações da tabela de dimensões, não há problema algum,
ou seja, podemos tranqüilamente só atualizar as dimensões na hora da carga dos fatos
que normalmente é diária. O contrário é que não pode, pois serão geradas
inconsistências temporais.
■ Em dimensões do tipo 2. Como verificar se um registro de dimensão sofreu alteração
e necessita de um novo registro que atenda a nova versão, preservando o antigo para
efeitos históricos? Devemos ter uma chave lógica eleita que servirá de base para a
comparação das mudanças: matrícula do funcionário, por exemplo. Começamos a
carga pelas dimensões e depois carregamos os fatos. Se houver problema em qualquer
dimensão de uma estrela, a carga deve ser abortada.
■ Como armazenar fatos de um produto que não está em promoção? Criamos um registro
na dimensão “Promoção” com o valor descritivo “Sem promoção”;
■ Se só armazeno produtos que foram vendidos, como recuperar informações de produtos
que estavam em promoção e não foram vendidos? Podemos preencher a tabela de
fatos com zeros para este caso, porém vamos expandi-la enormemente. A recuperação
pode ser feita através da diferença da lista de produtos em promoção 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 dimensões e possuem uma
semântica diferente. Em um esquema para análise de vendas, pode existir uma tabela
de fatos para as vendas concretizadas e outra idêntica 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 dimensão no esquema estrela? Basta criar uma dimensão
derivada Grupo que terá um relacionamento de muitos para muitos com a dimensão
Produto. Como resultado, teremos uma tabela de fatos “Grupo X Produto”. Esta
tabela conterá os IDs do grupo e de produto. Podemos aplicar esta solução em
qualquer caso semelhante.
■ Como identificar dimensões? Dimensões 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 dimensões são identificadas nas perguntas
feitas pela área diretiva. Uma dimensão é um participante de um fato explicitamente
indicado na pergunta, não evolui com freqüência e não possui indicadores analíticos
associados. Na pergunta: “Qual o desempenho das filiais em cada estado?”,
identificamos a necessidade de análise por filial e por estado. As dimensões respondem
a perguntas do tipo “O que?” (sofre a ação – venda de um Produto), “Quem?” (agente
associado – venda por um funcionário), “Onde?” (local – venda na filial x) e “Quando?”
(tempo – vendas mensais ou diárias).
■ Como identificar fatos? Também identificamos fatos na perguntas: “Qual o desempenho
das filiais em cada estado?”. Geralmente numéricos, os fatos são evolutivos, mudando
seus valores com freqüência.
■ Como os DERs dos sistemas fontes podem direcionar o projeto de um esquema estrela?
Podemos acompanhar as seguintes dicas:
Relacionamentos de “um para muitos” podem indicar a presença de uma dimensão.

Relacionamentos de “muitos para muitos” possuem tabelas intermediárias, e estas
podem conter valores númericos que indicam fatos.
Entidades para representar documentos como Nota Fiscal e Pedido podem indicar
fatos e dimensões descaracterizadas.
Geralmente as entidades fortes indicam dimensões.
■ A minha ferramenta OLAP não possui suporte intuitivo para executar contagem de
registros na tabela de fatos, como posso contar os registros facilmente? Acrescentando
um campo numérico à 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 publicação 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 redundância muito baixa. As regras de normalização de Codd orientavam o
projetista a criar uma estrutura lógica de tabelas sem qualquer redundância. No entanto,
devido a questões de desempenho, abria-se espaço para a introdução de dados duplicados
para garantir um acesso mais rápido.
Contudo, o projetista de dados de DW não deve introduzir redundância em qualquer

lugar do modelo. A redundância sempre traz um preço a ser pago, seja o custo de
armazenamento em disco ou o custo da manutenção de um esquema de atualização
em paralelo.
Aceitando-se, então, a introdução de redundância ao modelo de dados, chegamos à técnica

de projeto em esquema estrela (Star Schema).
A técnica Star Schema foi concebida pelo Dr. Ralph Kimball como uma forma alternativa
de projeto de dados para aplicações de DW. O nome estrela (Star) é devido à forma de
projeto, onde uma grande tabela de fatos reside no centro do modelo, rodeada por vários
pontos, ou tabelas de referência.
O princípio básico por trás do Star Schema é a introdução de dados altamente redundantes
por questões de desempenho. O Dr. Kimball descreve as desnormalizações como pré-
junções de tabelas, de forma que as aplicações não precisem fazer a junção das tabelas
em tempo de execução. No centro do Star Schema, a tabela de fatos é normalmente
composta de chaves e dados puros. Uma tabela de fatos é, geralmente, muito extensa e
contém milhões de linhas.
Capítulo 5: Gerência de Metadados em um Data Warehouse 67
5
C A P Í T U L O
Gerência de Metadados
em um Data Warehouse
Metadados em um Processo
de Data Warehousing8
Os metadados são definidos como dados sobre dados, porém 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, além do banco, gera-se uma documentação muito maior. Além de descrever
sobre o levantamento de dados e o banco, temos ainda o levantamento dos relatórios a
serem gerados, de onde vêm os dados para alimentar o DW, processos de extração, tratamento
e rotinas de carga dos dados. Ainda podem ser gerados metadados sobre as regras de negócio
da empresa e todas as mudanças que elas podem ter sofrido, e também a freqüência de
acesso aos dados. Os metadados englobam o DW e mantêm as informações sobre localização
dos dados (Figura 5.1). São exemplos de metadados para um DW:
■ A estrutura dos dados segundo a visão do programador.

■ A estrutura dos dados segundo a visão dos analistas de negócio.
■ A fonte de dados que alimenta o DW.
■ A transformação sofrida pelos dados no momento de sua migração para o DW.
■ O modelo de dados.
■ O relacionamento entre o modelo de dados e o DW.
■ O histórico das extrações de dados.
Acrescentamos ainda os dados referentes aos relatórios que são gerados pelas ferramentas
OLAP, assim como os que são gerados nas camadas semânticas.
Os metadados podem surgir de vários locais durante o decorrer do projeto. Eles provêm
de repositórios de ferramentas de modelagem, os quais geralmente já estão estruturados,
facilitando a integração da origem dos metadados e um repositório dos mesmos. Essa
fonte de metadados é riquíssima. Outros dados que devem ser considerados metadados
são os materiais que surgirão das entrevistas com os usuários. Destas entrevistas podem
obter-se informações preciosas que não estão documentadas em nenhum outro lugar
além de regras para validação dos dados depois de carregados no Data Warehouse.
8
Chamamos de Data Warehousing (Dwing) a solução completa desde a coleta dos dados até a sua
transformação em informação.
Figura 5.1: Abragência dos Metadados em um processo de DWing.
As pesquisas na área de metadados para DW estão aumentando em função da necessidade

extrema das organizações de conhecer melhor os dados que elas mantêm, e também
conhecer com mais detalhes os dados de outras organizações, através de intranets e
extranets. Sem uma documentação eficiente dos dados, é dificultada aos usuários a
localização de dados necessários para suas aplicações. Também, os dados ficam sujeitos
à superposição de esforços de coleta e manutenção, e vulneráveis a problemas de
inconsistências. O não uso ou uso impróprio da informação será altíssimo.
Dentro do contexto de DW podemos dividir os metadados em duas categorias básicas:

metadados técnicos e metadados de negócio.
Metadados técnicos provêem conf iabilidade na acuracidade do DW para os

desenvolvedores. Descrevem os dados necessários pelas várias ferramentas utilizadas
para armazenar, manipular ou movimentar dados. São altamente estruturados e geralmente
tratados via uma ferramenta de repositório. Adicionalmente, os metadados técnicos
suportam a manutenção do DW permitindo sobretudo fácil escalabilidade ao mesmo.

Temos como exemplos de metadados técnicos:
■ Controles de Auditoria.
■ Nomes das tabelas do DW (em caso de DW relacional).
Metadados de negócio perfazem a junção entre o mundo codificado de um DW e o mundo

do usuário de negócios. Este tipo de metadado permite facilitar a utilização do DW pelos
usuários, auxiliando-os em suas consultas ad hoc. São tanto não-estruturados quanto
estruturados, tornando-se difíceis de serem tratados e integrados por uma ferramenta
estruturada tipo repositório. Podemos citar como exemplos de metadados de negócio:
■ Mapeamento dos campos das tabelas de um DW relacional para atributos conceituais.
■ Regras para operações de DW drill-down, drill-up e drill-across, conhecidas como
operações OLAP.
■ Informações sobre sumários e transformações de dados.
■ Nomenclaturas para os dados que possam ser facilmente entendidas pelos analistas de
negócios ou executivos.
Existem diversos problemas a serem enfrentados com o uso e gerência de metadados em

ambientes de DW. Em primeiro lugar, é necessário delimitar o escopo de atuação, pois a
decisão de quais metadados devem ser coletados e mantidos é complexa. Os principais
problemas pertinentes à gerência de metadados estão relacionados com:
■ Redundância: diversas ferramentas de um ambiente de DW ainda armazenam seus
próprios metadados em formato proprietário.
■ Séries históricas: o conceito de um dado pode evoluir, ou o ramo estratégico do negócio
pode mudar completamente.
■ Falta de estruturação de alguns metadados: aquisição e transferência de metadados
de negócios não-estruturados que contextualizam eventos externos e internos à empresa,
os quais provocam discrepâncias nas informações estratégicas. Residem em agendas
particulares, e-mails, mídias alternativas, imagens e etc.
■ Soluções particulares: em se tratando de metadados de negócios, não existe uma
solução única.
■ Suporte a usuários de diferentes perfis: diferentes comunidades irão propor, projetar e

ser responsáveis por diferentes tipos de metadados.
■ Criação de novos conjuntos de metadados (evolução do DW).
■ Interoperabilidade de diferentes sistemas.
Metadados Operacionais
Os metadados operacionais fazem parte do conjunto de metadados técnicos de um
processo de Data Warehousing. Estes metadados exercem uma influência no ambiente
de entrada de um Data Warehouse, determinam a aceitabilidade dos dados que são
transmitidos para o Data Warehouse e controlam o processo pelo qual a transmissão é
feita. É fundamental para a natureza de um ambiente de Data Warehouse que o escopo
do sistema esteja em constante fluxo. Mudanças em relação a negócios, novas telas,
ferramentas de análise oferecendo novas maneiras de análise de dados, e a consistência
e completeza oferecidas por um Data Warehouse podem significar benefícios que irão
contribuir para uma constante evolução.
Os metadados operacionais, para suportarem essa constante evolução do Data Ware-

house, devem possuir um conjunto de classes mínimas tais como:
■ Aplicação: Define qualquer sistema que atue como fonte de dados.
■ Fluxo dos dados: Define a relação de fluxo do começo ao fim, para um segmento de
trabalho independente, dentro do carregamento de um Data Warehouse.
■ Ordem de Transferência: Uma subdivisão do Fluxo de Dados, permitindo ao
desenvolvedor entender como a transferência vai funcionar, a ordem em que as tarefas
serão executadas, e sob quais circunstâncias ela poderá dar certo.
■ Transformação: É uma atividade que, no nível de Ordem de Transferência, muda a
estrutura ou conteúdo de alguma parte do dado que está sendo transferido.
■ Classes Fonte: Definem os objetos que existem dentro da aplicação de origem e que
são acessados para procurar os dados que serão transferidos para o Data Warehouse.
■ Aributos Fonte: Atributos individuais que são usados como dados de origem nas
Classes Fonte.
■ Classe Destino: Provê uma definição para cada classe dentro do ambiente de DW.
■ Atributo Destino: Provê uma definição em nível de atributo para cada item do dado.
■ Armazenamento Físico: Fonte atual, intermediária e os objetos de destino usados na
transferência.
■ Regras: Definem as regras que estão alocadas em cada item do dado (geralmente em
nível de atributo) enquanto passa pelo ambiente de Data Warehouse, possivelmente
fazendo a validação, medição, dependências complexas com outros atributos,
dependências com data e hora, e outros efeitos externos.
■ Dependências: Dependências existentes na Ordem de Transferência – adicionando
sofisticação para o conceito de fluxo de trabalho, permitindo ao desenvolvedor definir
a ordem de cada passo. Na verdade uma implementação mais moderna dessa
característica seria possível com uma ferramenta de gerenciamento de projetos. Vale
também considerar que a ferramenta ETL irá permitir a gravação e o controle desses
modelos de trabalho.
Os elementos citados acima são basicamente estáticos. Eles não são afetados pelo banco
de dados ou por outras influências externas. Muitas companhias oferecem ferramentas
que possam aumentar a capacidade de gerenciar metadados operacionais. Em alguns
casos, as ferramentas combinam gerenciamento de metadado técnico 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 são vendidas como eficientes mecanismos para desenvolvimento e controle de
seqüências ETL, mas são na verdade avanços significativos na área de gerenciamento de
metadados automativos. Em alguns casos, modelos de metadados básicos têm sido
estendidos para inclusão de características dinâmicas que provêm informações como
volume de dados, volatilidade, tempo de carga e marcadores para transferência de dados.
Estáticos ou dinâmicos, os metadados que controlam a extração, transformação e

carregamento dos dados devem idealmente ser capturados por uma interface gráfica,
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, é impossível controlar
a carga, não importando o nível de modernidade que o front-end de uma ferramenta ETL
possa oferecer.
Metadados de Negócio
Os metadados de negócio englobam informações requeridas pelos usuários finais para
balanço e sobre como usar o conteúdo de um Data Warehouse para suprir suas
necessidades. Essencialmente, metadados de negócio asseguram que cada usuário tenha
um ambiente de Data Warehouse consistente bem entendido, e que possam usar isto para
formular um método apropriado para encontrar suas necessidades de negócios. Em
conseqüência disso, os metadados de negócio devem responder perguntas como: O
rendimento inclui ou exclui taxas de venda?; Quando alguém de outro departamento fala
sobre tipos de produtos, a que ele ou ela está se referindo? Qual a fórmula 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. É função dos metadados de negócio controlar e gerar respostas para estas
perguntas, e assegurar que os usuários do DW e Data Marts estejam trabalhando de
acordo com as regras da empresa.
Para o controle de metadados de negócio também é necessário possuir um conjunto

mínimo de classes, tais como:
■ Apelidos: Nomes secundários para classes e atributos – assegurando que exista um
entendimento comum das regras de negócio.
■ Domínios
■ Volumes
■ Cardinalidade
■ Volatilidade
■ Perspectivas do negócio
■ Medidas
■ Atributos sem medidas
■ Escopos de análise
■ Itens do negócio: Definição de item de negócio para um determinado setor. Faz-se
necessário um controle dos responsáveis pela inclusão de valores de atributo. Em
diversos casos a interpretação dos dados é feita de maneira diferente em cada grupo
da organização, pois cada departamento tem suas próprias regras e conceitos.
■ Data de início, data de fim e status: Atributos temporais necessários para o controle
de versionamento dos metadados. São respectivamente: Data de início de validade do
metadado, data de fim de validade do metadado e situação do metadado (válido ou
inválido atualmente). Desta forma é possível manter um histórico da evolução da
semântica dos dados, um requisito indispensável aos analistas de negócio.
Uma Arquitetura Básica de Metadados

Para a definição de uma arquitetura básica de metadados devemos sempre ressaltar a
inevitável presença de diversas fontes de metadados em um ambiente de Data Ware-
house. Em virtude disto, é necessária a presença de uma ferramenta de integração de
metadados para unir as várias fontes de metadados (Figura 5.2).
Figura 5.2: Uma arquitetura básica de metadados.
Para o uso da ferramenta de integração, precisa-se saber quais os metadados genéricos e

se a mesma suportará todos os outros metadados existentes no processo. A identificação
das fontes e de seus requisitos de integração é fundamental para a visualização de possíveis
necessidades de mudanças no modelo da base de metadados suportado pela ferramenta

de integração de dados.
Deve haver compatibilidade entre o repositório e as ferramentas ETL e de modelagem.

Já o processo de integração com um dicionário de dados pode ser feito através da escrita
de um programa complexo para moldar o dicionário de dados a um formato que possa
ser integrado à ferramenta do repositório ou, idealmente, o modelo de metadados suportado
pela ferramenta de integração de metadados deve possuir os campos necessários para
suportar esses metadados.
Finalmente, pode ser usada uma ferramenta OLAP para acessar a informação no
repositório ou até mesmo ser desenvolvida uma interface Web para acesso através de
uma intranet, por exemplo.
Tipos de Arquitetura de Metadados

Podemos definir 4 tipos de arquitetura de metadados. São eles:
■ Metadados Centralizados: O conceito de arquitetura de metadados centralizada é um
modelo uniforme e consistente onde o esquema de definição e organização de vários
metadados seja armazenado em um repositório global de metadados.
■ Metadados Descentralizados: O objetivo de uma arquitetura descentralizada é um
modelo uniforme e consistente onde o esquema de definição e organização de vários
metadados seja armazenado em um repositório global de metadados e em elementos
de metadados que apareçam em repositórios locais. Todo metadado que é compartilhado
e reutilizado entre os vários repositórios primeiro deve passar pelo repositório central.
Porém, o compartilhamento e o acesso ao metadado local são independentes do
repositório central. O repositório central é o conjunto dos metadados armazenados em
repositórios locais. Essa arquitetura é muito desejável para aquelas empresas que têm
linhas de negócio diferentes e não-relacionadas, pois há o compartilhamento dos
metadados entre múltiplos repositórios e também cada repositório local é autônomo
para com seu conteúdo e requisitos administrativos.
■ Metadados Bidirecionais: Uma arquitetura de metadado bidirecional permite que o
metadado seja modificado no repositório para depois ser transportado para seu lugar
de origem. Por exemplo, se um usuário acessa o repositório e muda o nome de um
atributo para um dos Data Marts, a mudança é repetida na ferramenta de modelo de

dados para atualizar o modelo físico para aquele Data Mart específico. Apesar de
complexa, esta arquitetura é bem desejada, pois permite que as ferramentas
compartilhem os metadados e também permite que as empresas detectem modificações
nos metadados, o que é extremamente atrativo para organizações que querem
implementar um repositório de metadados em um nível mais elevado.
Existem 3 (três) desafios para implementação de metadados bidirecionais:

■ O repositório de metadados deve sempre ter a última versão da fonte de metadados
que irá ser alimentada.
■ As mudanças precisam ser capturadas e resolvidas, pois um usuário pode estar
mudando o metadado no repositório enquanto outro usuário muda o mesmo metadado
em sua fonte.
Mais interfaces precisam ser modeladas para o envio dos metadados do repositório às
suas fontes.
■ Metadados Rotativos: O metadado rotativo permite que o repositório envie seu
metadado de volta ao sistema de informação operacional da empresa. Essa arquitetura
é parecida com a bidirecional, mas nesse caso o repositório envia seu metadado para o
sistema fonte operacional e não para dentro de outras aplicações. Metadados rotativos
estão ganhando popularidade entre as organizações que querem implementar um
repositório de grande escala, pois permitem fazer mudanças globais no repositório e
ter essas mudanças detectadas dentro do sistema fonte operacional da empresa.
Metadados rotativos possuem as mesmas complexidades dos bidirecionais. O

repositório terá que possuir a última versão dos metadados, no caso de esse metadado
ser enviado do repositório para o sistema fonte operacional. Se o repositório não
possuir a última versão, não há garantia de que o usuário atualize a última versão.
Além disso, um usuário pode fazer mudanças nos metadados no repositório ao mesmo
tempo em que outro está mudando no sistema fonte operacional. Esses conflitos
devem ser detectados e interfaces construídas para unir os metadados a sistemas
fontes operacionais. Apesar de poucas empresas estarem usando uma arquitetura
rotativa, é um grande progresso em repositórios de metadados.
Requisitos de uma
Arquitetura de Metadados
Integração
O maior desafio em construir um DW é integrar todos os seus dispositivos de dados e
transformar esses dados em informações valiosas. O mesmo acontece para um repositório
de metadados. Por exemplo, uma organização deseja mostrar a seus usuários a definição
de um campo que aparece em um relatório, e digamos que esse campo veio de uma
planilha eletrônica. O processo de integração dos metadados deve criar um link entre os
metadados do relatório e o campo da planilha. A integração dos dados é a tarefa mais
complexa na implementação de um repositório de metadados.
Extensibilidade
Se a integração é a característica mais difícil a ser atingida, a escalabilidade é a mais
importante. Um repositório de metadados que não foi feito para crescer constantemente
breve ficará obsoleto. Três fatores estão levando os repositórios a esse crescimento:
■ Crescimento contínuo de sistemas de suporte à decisão: É normal que o tamanho de um DW
e o número de usuários que acessam esse DW dobrem em um só ano. Se esses sistemas de
suporte à decisão crescem, o repositório tem que crescer para atender esse crescimento.
■ Reconhecimento do valor de um uso mais amplo dos metadados: Durante os últimos
cinco anos as empresas começaram a notar a importância de ter um repositório de
metadados. Essas empresas não estão utilizando o repositório só para suporte à decisão,
mas também para outros fins.
■ Maior confiança 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 disponibilização
dos mesmos na rede da organização.Nos últimos anos, as organizações começaram a
entender que o repositório de metadados é a principal estrutura para implementar o
gerenciamento do conhecimento.
A ferramenta que gerencia o repositório também deve ser transportável entre sistemas
operacionais, pois a mudança de um sistema operacional na organização não pode devastar
um projeto de repositório de metadados.
Robustez
Como qualquer sistema, um repositório de metadados deve ter funcionalidade e desempenho
suficiente para atender as necessidades da sua empresa. Deve atender os usuários técnicos
como também os usuários de negócios, e ter mais algumas características como:
■ Capacidade de importação e exportação de metadados.
■ Configuração segura e facilidades de permissão de acesso aos dados.
■ Arquivamento e backup simplificados.
■ Habilidade de gerar relatórios técnicos e de negócios.
Abertura
A tecnologia usada para a integração de metadados e acessos deve ser aberta e flexível.
Por exemplo, os bancos de dados usados para guardar metadados são geralmente
relacionais, mas a arquitetura de metadados tem que ser suficientemente flexível a ponto
de permitir que a organização mude de um banco de dados relacional para outro tipo de
arquitetura. A abertura também diz respeito ao acesso ao repositório, ou seja, as
organizações geralmente desejam fornecer seus relatórios aos seus usuários via Web direto
de qualquer browser. Um bom gerente de metadados deve permitir isso.
Automatização e Reutilização de Processos

O processo de carregar e manter o repositório de metadados deve ser o mais automatizado
possível. Implementações que contêm muitos processos manuais em sua arquitetura
diminuem o desempenho do repositório, ou muitas vezes o tornam inativo. Com uma
análise cuidadosa e alguns esforços, 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 situações, é mais fácil desenvolver
um front-end para os usuários e deixá-los criar e manter seus próprios metadados. Mesmo
que esses usuários não se sintam à vontade em criar seus metadados, pelo menos até o
repositório estar funcionando, um bom front-end e uma boa assistência da equipe de
desenvolvedores poderiam encorajá-los nesta tarefa.
Padronização do Processo de Integração

O processo de integrar dispositivos de metadados é baseado no mesmo conceito de ETL
(Extração, transformação, carregamento) em um DW. O processo ETL divide-se em:
■ Camada de Extração (Aquisição de Dados): A principal atividade da camada de
extração é adquirir dados de várias fontes sem causar impacto algum nessas fontes.
Duas transformações ocorrem ao dado nesta camada. O repositório deve decidir se a
seleção de gravação deve ser usada nessa camada ou na camada de transformação.
Geralmente é bom evitar critério de gravação nesse ponto, ao menos que os dados no
metadado sejam bastante volumosos e essa quantidade que será carregada no repositório
seja um subconjunto menor. Logo após, o desenvolvedor pode adicionar campos
específicos para serem usados no repositório.
■ Camada de Transformação: A camada de transformação é a “espinha dorsal” do
repositório. A mais importante atividade do repositório de metadados acontece nessa
etapa: integração e limpeza da fonte de metadados. Após esta tarefa, os metadados
ficam prontos para serem carregados no repositório. A transformação e limpeza devem
acontecer na mesma plataforma física do repositório de metadados. Desse modo,
enquanto as requisições ao repositório crescem, toda fonte de metadados pode ser
integrada na mesma área física, portanto minimizando mudanças na camada de extração
e reduzindo os pedidos à fonte de metadados.
As funções de transformação e limpeza podem ocorrer no mesmo programa ou
processo, ou em vários processos, mas os arquivos gerados provenientes dos processos
de transformação devem sempre se igualar aos das classes de metadados, de onde ele
foi carregado. Qualquer erro que possa ocorrer quando o repositório estiver sendo
carregado acontece nessa camada. Isso é importante para criar procedimentos de
recuperação no caso de a leitura ter que parar.
■ Camada de Leitura: A camada de leitura captura os arquivos que são gerados na camada
de transformação e os leva ao repositório. Procedimentos de recuperação também são
importantes nessa camada caso haja algum problema no processo de leitura. Geralmente
usa-se o mecanismo de leitura de volume padrão e bancos de dados relacionais. Se no
futuro houver a necessidade de ligar tabelas relacionais, os processos nas camadas de
extração e transformação não serão afetados, mas os processos nesta camada terão
que ser modificados. Como poucos processos acorrem nesta camada, as modificações
são relativamente fáceis.
Existem 2 (duas) grandes vantagens em separar a camada de extração da camada de

transformação:
■ Sincronismo: A camada de extração mantém o metadado no repositório 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 dinâmico, e ocorre porque
a leitura dos metadados é feita em diferentes instâncias. Assim, a informação no
repositório de metadados não estará em sincronização. Criando um arquivo de extração
no processo de integração, todas as classes podem ser construídas a partir desse arquivo,
que eliminaria qualquer problema de sincronismo.
■ Backup: A criação de um arquivo de extração provê uma cópia da fonte de metadados.
Entretanto, se alguma coisa fizer parar o processo de integração de metadados, pode
ser feita uma recuperação das mudanças sem causar nenhum dano.
Flexibilidade
Modelos de metadados geralmente usam um esquema orientado a objetos para representação
conceitual da organização dos repositórios. O modelo de metadados provê uma estrutura para
estabelecer um protocolo para acesso aos metadados, administração e intercâmbio de informações
entre os softwares que acessam o repositório. O modelo de metadados deve ser capaz de capturar
o que for de interesse das aplicações que fazem uso do repositório. Por exemplo, em um DW ou
ambiente de suporte à decisão temos como metadados chave: objetos relacionais e não-
relacionais, conceitos multidimensionais, lógicas de transformação, regras de negócio e
programas de trabalho. Todos esses metadados devem ser manipulados pelo repositório. A
metodologia de modelagem de metadados deve ser capaz de acomodar vários tipos de
relacionamentos, como um-pra-um, um-pra-muitos, muitos-pra-muitos, agregação e herança.
Gerenciamento de Múltiplas
Versões de Metadados
No momento em que o metadado provê um contexto para interpretação do significado
da informação, o repositório tem a função de gerenciar a estrutura dos dados de um DW
por um longo espaço de tempo. Por esta razão, é preciso saber o período de tempo em
que o metadado é armazenado no repositório. 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 usuário facilmente consulte versões antigas do metadado.
Facilidades de Atualização
Inevitavelmente, podem ocorrer mudanças nas aplicações que acessam o repositório a
partir do momento que ele for carregado. A equipe que implementou o repositório tem
que decidir em que momento atualizar o repositório para cada fonte de metadados. Como
regra geral, a maioria dos repositórios é atualizada mensalmente. Na maioria das fontes
de metadados, não é necessária uma atualização do repositório para cada mudança que
ocorra. Por exemplo, se for adicionado um índice em uma tabela de um sistema fonte,
não é necessária a atualização, mas se algo de mais abrangente acontecer como a
eliminação de uma entidade de um sistema fonte, o repositório tem que ser atualizado
para incorporar os novos modelos de dados, definições de negócios, e assim por diante.
Claro que alguns tipos de metadados, como por exemplo as estatísticas de leitura de um
DW e acesso dos usuários, são constantemente atualizados.
Arquitetura Multicamadas
A maioria dos repositórios de metadados é baseada em arquitetura de duas camadas, cliente-
servidor, da mesma forma que um servidor de banco de dados funciona, sendo acessado
por várias aplicações. Mas uma arquitetura multicamadas provê uma arquitetura mais aberta
e extensível para gravação, leitura e modificação dos metadados. Essa arquitetura inclui
um servidor de repositório que encapsula um sistema de gerenciamento físico de banco de
dados (seja relacional ou orientado a objetos) e fornece vários componentes para manipular
inúmeras interfaces (XMI, XML, COM+, etc.). Também deve haver provisão de mecanismos
para acesso e gerenciamento de metadados em redes locais e de longa distância para
acomodar ambientes de distribuição. Com o crescimento da internet e comércio eletrônico,
uma arquitetura multicamadas é um importante requisito para um repositório de metadados.
Gerenciamento de Segurança
É importante salientar que o metadado é um recurso inestimável em uma organização.
O acesso ao metadado deve ser cuidadosamente controlado para projetar recursos
intelectuais e assegurar a validação e integridade do metadado para todos os usuários

ao mesmo tempo.
O esquema de gerenciamento de segurança para o repositório de metadados é parecido

com a maioria dos SGBDs, mas deve ser projetado para necessidades específicas dos
criadores de metadados, usuários e administradores. Além disso, o acesso deve ser restrito
ao metadado de acordo com o tipo, ou as operações que os usuários ou administradores
dos metadados pretendem fazer. Um esquema de gerenciamento de segurança robusto é
um requisito essencial para o repositório de metadados.
Funcionalidade de um
Repositório de Metadados
Para alcançar seus objetivos, o repositório de metadados deve prover certa funcionalidade
como: provisão de informação baseada em um metamodelo, acesso automático,
administração de versão e configuração, análise de impacto e notificação.
Provisão de Informação
O repositório tem que oferecer mecanismos para exame, filtro e navegação de modo a
satisfazer as necessidades de informação dos usuários. O esquema do repositório deve
prover consultas sob certas condições como, por exemplo, fazer consultas selecionando
apenas o processo de atualização, ou todos os metadados lógicos que se relacionam com
o objeto de negócio “sócio”.
A estrutura do repositório também deve permitir seleção de metadados de acordo com

sua origem, propósito e tempo de produção. Isto exige que os metadados possuam chaves
que contêm os valores apropriados (por exemplo, em terminologia relacional atributos
para propósito, origem e etc. devem existir).
Um repositório não só deve prover informações explícitas sobre relacionamentos entre

metadados como também implícitas. Em conseqüência disso, uma exigência de
funcionalidade essencial é a navegação dentro da coleção de metadados. Começando
com um certo elemento, o usuário pode navegar por outros elementos ao longo de
relações existentes. Esta navegação é dirigida pelo esquema especificado em um nível
conceitual do repositório.
Com relação à filtragem o ideal é que além do exame de atributos fixos seja possível
também a procura de palavras-chave dentro de descrições textuais. Desta forma, toda
informação relacionada com um tópico pode ser provida.
Com relação à navegação é extremamente necessária uma interface amigável para o

usuário interagir com o repositório. Cada usuário deve ter seu ponto de partida de
navegação baseado nos seus direitos de visibilidade (visões do usuário).
Metamodelo
Para prover a funcionalidade necessária, um metamodelo apropriado deve ser escolhido.
Um metamodelo é o esquema conceitual do repositório de metadados. Especifica
elementos de metadados e relacionamentos entre eles.
O metamodelo requer elementos para representar metadados em níveis diferentes de

abstração e deve ser extensível para que usuários possam definir aplicações com elementos
de metadados específicos.
Acesso ao Repositório
Para ser utilizável, o repositório tem que ser atualizado. Só podem ser garantidos o uso
próspero e longevidade do repositório se interfaces para interoperabilidade com outros
repositórios estiverem disponíveis. Para isso é necessário que um padrão de intercâmbio
seja adotado e uma API seja fornecida para acesso por outras ferramentas.
Administração de Versão e Configuração

Mudanças importantes de metadados como atualização de esquemas de fontes
operacionais requerem criação de versões diferentes e conseqüente armazenamento
no repositório. Porém, problemas podem surgir com vínculos incompatíveis, ou
descrições no nível conceitual que não são mais válidas. Desta forma o repositório
deve prover mecanismos de notificação para descobrir tais erros de estrutura e
validade dos metadados.
Análise de Impacto
Esta característica deve permitir que administradores possam avaliar o impacto de
mudanças no DW antes que eles sejam feitos. Simulações são feitas para descobrir quais
partes do sistema são afetadas quando a aplicação requer mudanças. Por exemplo,
mudanças de esquemas fontes podem ter conseqüências para regras de transformação.
Notificação
O repositório deve prover mecanismos de notificação para usuários e/ou ferramentas
interessadas em mudanças significantes.
Metadados Técnicos e
Qualidade de Dados em Metadados
Poucos DWs exploram as vantagens de incorporar metadados técnicos especializados
em seu modelo de dados de suporte à decisão e processos ETL. Isso sempre leva a uma
redução na flexibilidade do DW, causando perda de tempo, dinheiro com manutenção,
aquisição de dados e auditoria de informação. Pode também levar os usuários a
interpretarem de maneira errada as informações do DW. Nesse tipo de situação, é
necessário rever o repositório de metadados e procurar aprimorar a identificação e
qualidade dos dados. É importante entender como o uso do metadado controla a qualidade
da informação guardada em um DW.
Sabemos que muitas empresas usam um repositório para acessar informações técnicas e
de negócio. Por esse aspecto, o repositório serve como um catálogo de informações para
um ambiente de suporte a decisão, sendo como um guia para a informação armazenada
no DW. Apesar dessa importante característica, o repositório ainda pode ser expandido
para uma participação ativa no processamento dos dados.
O repositório de metadados mantém informações do modelo de suporte à decisão, sistemas

fontes operacionais, processos ETL, e estatísticas de leitura que abrangem o DW. A
integração desses componentes no repositório está em um nível razoavelmente alto. Por
exemplo, a informação do repositório pode ser usada para determinar que um sistema
operacional de gerenciamento seja a fonte que alimenta uma tabela específica em DW
relacional. Revendo as estatísticas de leitura do repositório, pode-se determinar como e
com que freqüência o DW é atualizado. Essa informação permite aos usuários terem
uma boa visão do ambiente de suporte a decisão, mas esse nível de informação é
insuficiente quando um usuário técnico ou de negócio precisa ter uma visão mais detalhada
dos dados de um DW.
Para alcançar uma visão mais detalhada da informação contida no DW, o arquiteto do
repositório, o modelador dos dados e os desenvolvedores usam o metadado técnico que
foi estendido para forjar um relacionamento mais próximo entre o repositório e o banco
de dados de suporte a decisão. Isso é realizado incorporando o metadado técnico no DW.
Essa técnica é usada para estender o projeto e a arquitetura de um DW, para aumentar o
processo de otimização para aquisição dos dados, atividades de manutenção e medidas
para qualidade dos dados.
Para fazer do metadado técnico uma ponte entre o repositório e o modelo de dados de um
DW, o projetista deve incluir operadores no modelo de dados físico. O metadado técnico,
ao contrário da informação guardada no repositório, é referenciado de maneira livre no
DW. Essas marcações de metadados técnicos provêem um bom detalhamento da
informação contida no DW. Essa associação direta do metadado para cada informação
no DW, é o que distingue o metadado estendido.
Para escolher os operadores, o sistema fonte operacional une os dados ao metadado

técnico estendido durante o processo ETL. O metadado técnico se une aos dados no DW
provendo um significado semântico mais claro para o dado. Por exemplo, a tabela de
lojas deriva sua informação de duas fontes operacionais. A informação é retirada tanto
de uma aplicação de vendas quanto de uma aplicação de recursos humanos, dependendo
da disponibilidade. Sem o metadado técnico estendido na tabela, a informação só pode
ser usada do jeito que está, sem o sistema fonte operacional que a provê. O metadado
técnico marcado permite determinar quais dados foram derivados das duas fontes.
O projetista do repositório, o modelador dos dados e desenvolvedores precisam

calmamente considerar o plano usado pelos metadados técnicos no modelo de suporte à
decisão. Usuários de negócio e técnicos do DW devem identificar e concordar com um
claro e consistente método de marcação dos dados originários do sistema fonte
operacional. Qualquer metadado técnico amarrado aos dados deve ser aplicável por
completo, não só a maioria dos atributos da classe.
Prefere-se manter metadados técnicos amarrados a mínimos modelos de dados

dimensionais, como aqueles que são só uma ou duas classes, onde uma simples fonte
alimenta o DW, ou quando vários sistemas fontes operacionais precisam ser integrados
para carregar uma classe de suporte à decisão. Esquemas complicados fazem da saída
dos metadados do sistema, fonte operacional mais desafiadora.
A equipe do DW é responsável por avaliar o projeto e o impacto de manutenção causado

pelo uso de metadados amarrados ao repositório, 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 aderência rígida no modelo de suporte à
decisão para que funcione completamente e apropriadamente. Isso pode impedir o uso
de alguns ou todas as marcações de metadados técnicos em certas dimensões como a
dimensão tempo de um DW. Certos tipos de metadados estendidos podem precisar de
que processos adicionais de ETL ocorram, o que poderia causar lentidão na carga.
Uma variedade de marcações do metadado técnico pode ser incorporada ao projeto do

modelo de dados de suporte a decisão para melhorar o detalhamento de informações de
um DW. Dependendo dos requisitos da aplicação, do número de sistemas fontes
operacionais alimentando o DW, ou da complexidade do modelo de suporte à decisão, a
inclusão de marcações de metadados técnicos pode ou não fazer sentido. Por exemplo,
adicionar uma coluna a uma tabela de dimensão em um DW relacional para identificar o
sistema fonte operacional, onde só uma pequena fonte de informação existe para preencher
a tabela, pode parecer pouco produtivo ou prover pouco valor. Mas tem que se considerar
os possíveis efeitos de não incorporar essa marcação de metadado. Primeiro, o fato de o
DW ter uma só fonte hoje não assegura que amanhã ele vá continuar assim. Segundo, se
o DW realmente evoluir e o número de sistemas fontes aumentar, é difícil 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 número de fontes, estamos provendo
consistência para modelos de suporte à decisão e gerando disciplina na implementação
da metodologia de desenvolvimento adotada.
A incorporação de metadados técnicos em um modelo de DW relacional, por exemplo,

acontece durante a transformação do modelo de dados de negócio. Durante essa
modelagem, as colunas físicas são adicionadas às tabelas apropriadas como foi
determinado pelos requisitos de negócios e avaliação técnica previamente completa. O
metadado técnico é incorporado no modelo físico baseado no tipo de tabela que está
sendo endereçado.
Dependendo dos requisitos de negócio de um projeto, os seguintes atributos dos metadados

técnicos serão muito úteis:
■ Data de Leitura: Uma das diferenças fundamentais entre um modelo de dados de um
sistema fonte operacional normal e o modelo de DW é a adição da data em todos os
dados. Um dos atributos mais usados dos metadados técnicos é o atributo “Data de
Leitura”. Este atributo mostra quando (data ou hora) uma informação foi carregada
pelo DW. Essa data instantânea é usada para manter a integridade temporal do dado
em um DW no momento em que as informações são inseridas e atualizadas. Esse
atributo pode ser referenciado pelo administrador do DW para identificar possíveis
dados que precisem ser arquivados ou deletados. Usuários 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 relevância para o cenário de negócios.
A data efetiva dos dados extraídos do sistema fonte operacional pode ser mais
importante. É necessário observar estes detalhes quando for feita a determinação de
que marcações de metadados técnicos adicionar ao modelo de dados.
■ Data de Atualização: Outro atributo comum dos metadados técnicos é a “Data de
atualização”. Esse atributo indica quando um registro foi atualizado pela última vez
durante seu ciclo. Esse atributo também é usado para manter a integridade temporal
das informações em um DW.
■ Identificador de Ciclo de Leitura: Esse atributo é um identificador seqüencial nomeado
durante cada ciclo de leitura em um DW, não importa a freqüência. Como um
identificador seqüencial, 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 repositório de metadados que descreva outras estatísticas operacionais sobre
o ciclo de leitura. Usando somente o repositório de metadados, pode-se determinar
quando e quantos ciclos ocorrerão no DW. Usando o identificador, pode-se determinar
até quando e quais registros foram lidos.
■ Indicador de Versão: O atributo “Indicador de Versão” identifica a última versão de
um registro numa tabela de um DW relacional, por exemplo. Além de ser importante
para manter histórico, esse atributo também é muito útil para esquemas que não sejam
tipo estrela, onde o modelo de dados é como um DW atômico 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 usuários consultem dados históricos e atuais do DW.
■ Identificador do Sistema Fonte Operacional: Uma das mais úteis técnicas em termos
de campos de metadados tanto para administradores, quanto para usuários 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
construção. Os usuários de negócio poderão questionar a qualidade ou a validade dos
dados em um DW para devolver a informação ao sistema de informação operacional
de origem, que forneceu a informação. 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 análise alternativa para pesquisas no DW. Esse atributo pode
ser usado efetivamente em uma variedade de atividades de análise para identificar
quais dados deveriam estar em relatórios. Por exemplo, o “Identificador de Chaves”
pode ser usado para identificar e filtrar as contas contábeis que estão inativas em
um certo banco.
■ Indicador de Nível de Secreto: Uma das técnicas mais controversas é o atributo
“Indicador de Nível Secreto”. Esse atributo é usado para indicar que regras de negócio
ou suposições foram aplicadas em um dado em particular durante o processo ETL.
Esse atributo possibilita ao usuário medir o nível de credibilidade de um dado baseado
em um processo de transformação que foi executado. O “Indicador de Nível Secreto”
é freqüentemente usado para identificar problemas de qualidade de dados do sistema
fonte operacional e facilitar a correção desses problemas. O “Indicador de Nível
Secreto” também é usado para identificar dados que tiveram que ser estimados, previstos
ou tendenciados. Desta forma, um DW pode ter, por exemplo, níveis de estabilidade:
um determinado nível representa dados considerados mais voláteis, fáceis de limpar
ou relativamente moderados para definir; outro nível pode representar dados que fo-
ram considerados mais problemáticos para definir; um terceiro nível pode consistir de
dados que não vieram de nenhum dos sistemas fontes operacionais mas sim de alguma
planilha, e um quarto nível para marcar os dados de fontes externas como novos serviços
ou fontes comerciais.
Vale salientar que incorporar marcação de metadados técnicos faz possível uma variedade
de otimizações na aquisição dos dados, atividades de manutenção e informações de
auditoria dos usuários finais no DW. Como exemplo podemos citar a possibilidade de
eliminação de uma carga corrompida ou suspeita de um DW com maior facilidade, pois
antes de os atributos de metadados técnicos serem incorporados dentro do modelo de
dados, os desenvolvedores tinham opções limitadas de isolamento e remoção de
informações corrompidas. A marcação de metadados técnicos permite aos
desenvolvedores serem seletivos em seus métodos de remoção de dados do banco.
Em resumo, a incorporação de atributos de metadados técnicos em um DW permite a

usuários de negócios e administradores resolverem problemas administrativos e de qualidade
de dados. Os principais objetivos são: Medidas de qualidade de dados; Amostragem de
resultados do ciclo de leitura do processo ETL; Administração e manutenção.
Controle de Metadados em um
Projeto Evolutivo de Construção de DW
Para um DW abranger toda a corporação inicialmente, a mesma deve ser totalmente
informatizada e integrada, além do fato de o projeto ser extremamente complexo e com
alta probabilidade de insucesso.
Para diminuir os riscos de fracasso de construção de um DW e como a integração

total é rara de ser encontrada ainda hoje, deve-se aproveitar a estrutura operacional
disponível e desenvolver um Data Mart de cada vez. Esta técnica 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 composição de todos os Data Marts e o EDW (ou
Data Warehouse Corporativo).
O desenvolvimento de um FDW, devido à sua complexidade, é o mais dependente do

controle de metadados para dar certo. Os metadados serão usados para assegurar que
toda informação deverá ser enviada para todos os Data Marts, sendo eles independentes
ou não do EDW.
Em linhas gerais, os metadados englobam as maiores funções de cada ciclo de vida dos
dados dentro de um Federated Data Warehouse. Os metadados provêem uma linguagem
comum para definir o comportamento dos dados. A sintaxe formal dos metadados permite
definição robusta de regras de negócio e significados associados com os dados que estão
sendo transferidos do sistema de informação operacional de origem para o EDW e
eventualmente para dependentes ou independentes Data Marts. Isso se aproxima da visão
tradicional dos metadados, descrevendo como vendas e clientes se relacionam,
assegurando a consistência do grupo de clientes, definições universais, valores usados
para moeda, entre outros.
Os metadados também controlam o fluxo dos dados. Os metadados técnicos vão conter
não só definições dos dados, como também descrições formais da ocorrência dos fluxos,
regras de transformação de dados, dependências entre as transformações, e fatores de
tempo que afetam a transferência dos dados.
Finalmente, os metadados vão comunicar a natureza dos dados dentro do Data Warehouse
para os usuários e desenvolvedores com a necessidade de entender a base dos negócios.
Essa habilidade de acessar a definição e o controle dos dados é vital para que a proliferação
dos metadados ao longo das comunidades técnicas e não-técnicas seja efetiva e entendida.
O EDW pode suprir papéis diferentes nesse tipo de arquitetura. Ele provê um seguro e
completo mecanismo pelo qual a qualidade dos dados pode ser posta em controle de
consistência dentro dos Data Marts, mas evidentemente apresenta um nível significante
de redundância de dados. Cada item incluso no EDW estará no mínimo em uma das
estruturas dos Data Marts.
Todas as regras de negócio impostas pelo EDW ou pelos metadados técnicos dentro da
Staging Area serão herdadas pelos Data Marts, em um caso ideal. Os metadados técnicos
definem e controlam as regras de negócio que são aplicadas nos dados quando os
mesmos entram em um ambiente de Data Warehouse. Uma vez dentro do ambiente, a
interpretação que é posta sobre o dado pelos usuários é controlada pelos metadados de
negócio, que também asseguram que o comportamento do dado em diferentes Data

Marts seja consistente.
Na prática, isto implica que os metadados devem ser gerenciados de acordo com os
seguintes aspectos:
■ As regras contidas dentro dos metadados técnicos devem ser controladas para assegurar
que elas estejam corretas. Regras sem necessidade devem ser omitidas e as regras
ditas universais não devem ser parciais.
■ As regras dentro dos metadados de negócio devem estar presentes em um formulário
de fácil entendimento pelo usuário final daquele dado – o principal propósito desses
metadados é assegurar que o usuário possa acessar e manipular o dado eficientemente
e corretamente. Isso não vai acontecer a menos que os metadados de negócio sejam
robustos e presentes nos termos de negócio.
■ O mecanismo de controle deve assegurar que os níveis dos metadados de negócio e
técnicos estejam consistentes. Se isso não acontecer, os metadados vão piorar a
qualidade dos dados ao invés de melhorar.
Padronização de Metadados
A globalização das corporações em um ambiente de negócios altamente competitivo
exige um fluxo de informações rápido e eficiente. Para isso, é necessária a integração
de informações e seu conseqüente gerenciamento como forma de diminuir o custo e o
tempo despendido na implementação de novas soluções. Contudo, esse gerenciamento
integrado encontra obstáculos na proliferação de ferramentas de gerenciamento e
manipulação de dados que, em sua maioria, processam metadados de maneira
proprietária. A solução para esse problema apresenta-se na forma de padrões para
definição e troca de metadados, o que permite a reutilização de dados entre diferentes
aplicações. Podemos citar dois principais padrões que possuem esse objetivo: MDIS
(Metadata Interchange Specification) e OIM (Open Information Model) ambos
pertencentes à Metadata Coalition, um consórcio não-lucrativo de vendedores e usuários
finais que tem como objetivo prover uma especificação não proprietária dos metadados
corporativos. O MDIS provê conceitos para suportar a troca de metadados relacionados
com diferentes tipos de repositórios de dados: relacionais, multidimensionais, em rede,
hierárquicos e baseados em arquivos. Contudo, sua especificação restringe-se aos
relacionamentos existentes em um esquema de dados. Em contrapartida, o OIM

apresenta modelos de informações que englobam todas as fases do desenvolvimento
de sistemas de informação. Um desses modelos é o modelo de banco de dados, que
fornece conceitos relativos a provedores de dados relacionais.
Mesmo assim a padronização de metadados ainda não está estabilizada, pois padrões
para aplicações específicas requerem um alto grau de detalhe e regulamentação mais
precisa que padrões de propósito geral.
Seguindo na busca por padronização diversas empresas como a Oracle e Unisys deixaram a
Metadata Coalition e estão propondo o CWM (Common Warehouse Metadata). O mecanismo
é baseado no Intercâmbio XML9 de Metadados (XMI) especificamente. XMI usa os padrões
da XML. Em outras palavras, todo atributo de um metamodelo é representado na Definição
de Tipo de Documento (DTD) por um elemento de XML cujo nome é o atributo. Cada
associação entre duas metaclasses é representada por dois elementos de XML que representam
os papéis na associação. As multiplicidades da associação estão em multiplicidades de XML
que são válidas para especificar os modelos de elementos de XML.
Ainda não se sabe qual nível de detalhe e cobertura pode ser esperado pelo mesmo, ou seja,
até agora não está claro se o mesmo será um padrão estrutural que define um metamodelo
para Data Warehouse ou apenas um padrão de troca. O CWM não é a solução para a integração
funcional dos repositórios de dados, mas pode vir a facilitar esta tarefa por fornecer metadados
padronizados. Comparando o CWM com o OIM temos como principal diferença a amarração
do pacote OLAP do OIM ao modelo relacional. As diferenças são interessantes de serem
vistas, porém já é sabido que a Metadata Coalition forneceu suas especificações para o CWM
e parece ter desistido de continuar com a tarefa árdua de construir um “padrão”.
O Metamodelo CWM
O principal objetivo do CWM é facilitar a troca de metadados em um ambiente de DW
distribuído. O CWM pode ser classificado como um padrão para representação e troca
de metadados. Nele é especificado um metamodelo que pode ser visto como um esquema
conceitual para representação de metadados.
9
XML – eXtensible Markup Language – linguagem de marcação (Markup Language) extensível e flexível, cujos
dados são delimitados por tags. A XML foi projetada para descrever o conteúdo dos dados.
O padrão CWM é uma proposta do OMG (Object Management Group) que se baseia em
outros três padrões do mesmo grupo.
O Object Management Group (OMG) é uma organização internacional, fundada em

1989, que hoje é formada por mais de 800 membros, dentre eles fabricantes de software
e usuários. O objetivo maior do OMG é promover a interoperação de sistemas heterogêneos
distribuídos utilizando tecnologia orientada a objetos. Seu principal produto consiste em
especificações voltadas para a indústria de software e independentes de fabricante.
Dentre as várias especificações (e padrões) desenvolvidas/adotadas pelo OMG estão o

MOF (Meta Object Facility), a UML (Unified Modeling Language) e o XMI (XML
Metadata Interchange) que, juntos, formam o núcleo da arquitetura de metamodelagem
do OMG, na qual o CWM está inserido, sendo um metamodelo de domínio específico.
O CWM é constituído de vários submetamodelos, que representam metadados comuns

às principais áreas da tecnologia de Data Warehousing. Essas áreas funcionais foram
classificadas em:
■ Resources: suporta a definição de vários tipos de dados fontes e alvos, é composta por
metamodelos que representam fontes relacionais, orientadas a objetos, registros,
multidimensionais e XML.
■ Analysis: define as transformações e processamentos analíticos que ocorrem nas fontes
de dados. Abrange os metamodelos que representam transformações de dados, OLAP,
mineração de dados, visualização de informações e nomenclatura de negócios.
■ Management: utilizado quando na definição de metadados para registrar informações
de scheduling e detalhes operacionais tais como o resultado de transformações. Consiste
dos metamodelos Warehouse process e Warehouse operation.
■ Foundation: provê os tipos de metadados para representação de conceitos e estruturas
que são compartilhados por outros pacotes do CWM.
■ Object Model: neste pacote estão definidos os construtores básicos para a criação e
descrição de todas as classes do metamodelo em todos os outros pacotes. O Object
Model é um subconjunto da UML que inclui apenas as características necessárias para
criar e descrever o CWM.
Se o CWM for aceito verdadeiramente como padrão, habilitará produtos de apoio à decisão
a compartilhar dados e informação. Isto, em troca, proveria aos Data Warehouses uma
estrutura aberta, comum a todas as ferramentas envolvidas no processo. Havendo um

metamodelo padronizado para todas as ferramentas a comunicação entre elas torna-se
basicamente viável.
Resumo
As pesquisas na área de metadados para DW estão aumentando em função da necessidade
extrema das organizações de conhecer melhor os dados que elas mantêm, e também
conhecer com mais detalhes os dados de outras organizações, através de intranets e
extranets. Sem uma documentação eficiente dos dados, é dificultada aos usuários a
localização de dados necessários para suas aplicações. Também, os dados ficam sujeitos
à superposição de esforços de coleta e manutenção, e vulneráveis a problemas de
inconsistências. O não uso ou uso impróprio da informação será altíssimo.
Dentro do contexto de DW podemos dividir os metadados em duas categorias básicas:

metadados técnicos e metadados de negócio.
Metadados técnicos provêem conf iabilidade na acuracidade do DW para os

desenvolvedores.
Metadados de negócio perfazem a junção entre o mundo codificado de um DW e o

mundo do usuário de negócios.
Para a definição de uma arquitetura básica de metadados devemos sempre ressaltar a

inevitável presença de diversas fontes de metadados em um ambiente de Data Warehouse.
Em virtude disto, é necessária a presença de uma ferramenta de integração de metadados
para unir as várias fontes de metadados.
Podemos citar 4 tipos de arquitetura de metadados. São elas: Metadados centralizados;

Metadados descentralizados; Metadados bidirecionais; Metadados rotativos.
Para a construção de uma arquitetura de metadados o repositório dos mesmos deve atender
a requisitos básicos tais como: Integração; Extensibilidade; Robustez; Abertura;
Automatização e reutilização de processos; Padronização do processo de integração;
Flexibilidade; Gerenciamento de múltiplas versões de metadados; Facilidades de
atualização; Ser multicamadas; Gerenciamento de segurança.
Em se tratando de funcionalidades, é desejável que um repositório de metadados proveja

certas funcionalidades como: provisão de informação baseada em um metamodelo, acesso
automático, administração de versão e configuração, análise de impacto e notificação.
Além de explorar um repositório de metadados, um projeto de DW pode explorar as

vantagens de incorporar metadados técnicos especializados em seu modelo de dados de
suporte à decisão e processos ETL.
Para alcançar uma visão mais detalhada da informação contida no DW, o arquiteto do
repositório, o modelador dos dados e os desenvolvedores usam o metadado técnico que
foi estendido para forjar um relacionamento mais próximo entre o repositório e o banco
de dados de suporte a decisão. Isso é realizado incorporando o metadado técnico no DW.
Essa técnica é usada para estender o design e a arquitetura de um DW, para aumentar o
processo de otimização para aquisição dos dados, atividades de manutenção e medidas
para qualidade dos dados.
Para fazer do metadado técnico uma ponte entre o repositório e o modelo de dados de um
DW, o projetista deve incluir operadores no modelo de dados físico. O metadado técnico,
ao contrário da informação guardada no repositório, é referenciado de maneira livre no
DW. Essas marcações de metadados técnicos provêem um bom detalhamento da
informação contida no DW. Essa associação direta do metadado para cada informação
no DW é o que distingue o metadado estendido.
Para escolher os operadores, o sistema fonte operacional une os dados ao metadado técnico
estendido durante o processo ETL. O metadado técnico se une aos dados no DW provendo
um significado semântico mais claro para o dado. Por exemplo, a tabela de um cliente
deriva sua informação de duas fontes operacionais. A informação é retirada tanto de uma
aplicação de automação de venda quanto de uma aplicação de planejamento de recursos,
dependendo da disponibilidade. Sem o metadado técnico estendido na tabela, a informação
só pode ser usada do jeito que está, sem o sistema fonte operacional que a provê. O metadado
técnico marcado permite determinar quais dados foram derivados das duas fontes.
Dependendo dos requisitos de negócio de um projeto, os seguintes atributos dos metadados

técnicos serão muito úteis: Data de leitura; Data de atualização; Identificador de ciclo de
leitura; Indicador de versão; Identificador do sistema fonte operacional; Identificador de
chaves; Indicador de nível secreto.
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 serão usados para assegurar que
toda informação deverá ser enviada para todos os Data Marts, sendo eles independentes
ou não do EDW.
Finalmente, os repositórios de metadados caminham para uma padronização da

representação e troca de metadados. O principal objetivo é facilitar a troca de metadados
em um ambiente de DW distribuído. Atualmente, o metamodelo com maior aceitação é
o CWM. Nele é especificado um metamodelo que pode ser visto como um esquema
conceitual para representação de metadados.
Conclusões
Os benefícios que um Repositório de Metadados pode oferecer a um ambiente de
Tecnologia da Informação, tais como histórico de informações e o grande aumento de
qualidade nas pesquisas, são notórios. Todavia, a utilização do mesmo em empresas
ainda está longe de ser uma tarefa fácil e de baixo custo. A tecnologia envolvida necessita
de mão-de-obra qualificada e escassa, e atualmente só grandes empresas têm capital e
estrutura para usufruir de tamanha qualidade na administração de informações. Devido a
estes fatores, empresas de várias categorias estão tentando desenvolver seu próprio
repositório utilizando-se de seus próprios conhecimentos e experiências. Isso certamente
resultará no desenvolvimento de Repositórios que possam ser acessíveis financeiramente
a pequenas e médias empresas.
Em se tratando de arquitetura, idealmente, uma empresa deveria ter um único repositório

para administrar seus metadados, porém a centralização não condiz com a realidade
por diversas razões, como evolução de diversos departamentos que implica
desenvolvimento assíncrono de repositório. Em outras palavras e fazendo uma anologia
com a construção de um DW, um repositório de metadados é construído idealmente
numa metodologia bottom-up. Ou seja, o repositório evolui gradativamente até abranger
os metadados de toda a corporação de uma forma centralizada, assim como os Data

Marts formam o DW corporativo.
Analisando a questão da extensão dos metadados técnicos, podemos concluir que

atributos de metadados técnicos não devem sempre ser incorporados nas classes de um
DW. O projetista do repositório, 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 repositório e as
ferramentas de front-end.
Capítulo 6: Uma Metodologia Para Implementação de um Data Warehouse 99
6
C A P Í T U L O
Uma Metodologia Para

Implementação de um
Data Warehouse
“Por onde começamos?”. Esta é uma das principais perguntas feitas pelos engenheiros
de software quando planejam implementar um DW. São várias as opções: DW
Corporativo, DWs departamentais, DWs funcionais (marketing, f inanceiro,
administrativo), DWs para projetos especiais, etc.
Como um projeto de DW conceitualmente pressupõe uma arquitetura centralizada, sua

implementação não é uma tarefa fácil. A implementação de um DW completo requer uma
metodologia rigorosa e uma completa compreensão dos negócios da empresa. Esta abordagem
pode ser longa e dispendiosa e por isto sua implementação exige um planejamento bem
detalhado (em outras palavras: tempo longo). Neste contexto e com a necessidade de agilização
de implantação dos projetos de DW, o Data Mart passou a ser uma opção de arquitetura
interessante, pois os mesmos podem ser desenvolvidos para cada área da corporação num
processo paulatino e gradativo. Em um projeto de DW, a cada desenvolvimento de um novo
Data Mart a equipe adquire experiência e elimina os erros de implementações anteriores.
A tecnologia usada tanto no DW como no Data Mart é a mesma, as variações que ocorrem
são mínimas, sendo em volume de dados e na complexidade de carga. A principal diferença
é a de que os Data Marts são 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 criação 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 organização cria um DW e depois parte para a segmentação,
ou seja, divide o DW em áreas menores gerando assim pequenos bancos orientados
por assuntos departamentalizados.
■ Bottom-up: Na perspectiva Bottom-up temos uma situação inversa. A organização,
por desconhecer a tecnologia, prefere primeiro criar um banco de dados para somente
uma área. Com isso os custos são bem inferiores aos de um projeto de DW completo.
A partir da visualização 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 implementação, complexidade na
modelagem e acarreta dificuldades políticas e financeiras ao decorrer do projeto.

Já no desenvolvimento Bottom-up na ausência de um DW central e coordenado, a
flexibilidade certamente não será alcançada; além do mais, os pré-requisitos para
desenvolver Data Marts independentes levariam estes ao uso de sistemas de
informação operacionais individuais, contradizendo com a necessidade de uma
visão mais ampla.
Como alternativa para as desvantagens apresentadas acima surgiu o conceito de Feder-

ated Data Warehouse (FDW), que busca combinar as técnicas de desenvolvimento bot-
tom-up e top-down, enquanto diminuem os riscos de fracasso de um projeto de DW. As
idéias principais são apagar o mito de que um DW útil deve abranger toda a empresa e
conceber um projeto evolutivo dando enfoque inicial aos aspectos mais críticos.
Para um DW abranger toda a corporação inicialmente, a mesma deve ser totalmente

informatizada e integrada, além do fato de o projeto ser extremamente complexo e
com alta probabilidade de insucesso. Como a integração total é rara de ser encontrada
ainda hoje, deve-se aproveitar a estrutura operacional disponível e desenvolver um
Data Mart de cada vez.
Os resultados são atingidos em ciclos médios 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 coerência entre os vários Data Marts. Para garantir
essa coerência, o projeto deve prever uma estrutura de metadados compartilhada,
como vimos no Capítulo 5 (seção Controle de Metadados em um Projeto Evolutivo
de Contrução de DW).
Como prioridade, uma aconselhável escolha é o desenvolvimento de um Data Mart

baseado nos sistemas de informação contábeis da organização. Sob uma perspectiva
gerencial, os dados contábeis são excelentes fontes de informações que subsidiem os
gestores das organizações no processo decisório, facilitando o planejamento, controle e
avaliação de desempenho. Dados contábeis são considerados formais, científicos e
universais, sendo portanto capazes de atender à necessidade empresarial de tomada de
decisão. Além disso, sabemos que todos os eventos e indicadores de desempenho do
negócio relevantes são registrados nos sistemas contábeis.
Independente do tipo de Data Mart escolhido, em cada novo ciclo, deve-se seguir uma
metodologia de desenvolvimento bem definida como veremos nas próximas seções.
Diferenças entre a Análise Tradicional

e a Análise de Sistemas de Apoio à Decisão
Existem várias diferenças entre a análise tradicional de sistemas e a análise de sistemas
de apoio à decisão (SAD). Na análise tradicional de sistemas, o objetivo é documentar
todos os processos lógicos, descrevendo transformações de dados, repositórios de dados,
e entradas e saídas externas do sistema existente para o sistema proposto.
Por outro lado, a análise de SADs está focada na determinação de requisitos de dados e
fontes de dados de um sistema, e em documentar como extrair e disponibilizar esses
dados para os usuários finais.
A primeira diferença importante entre a análise para sistemas OLTP e SADs está nas
descrições das interfaces com os usuários. Na análise tradicional, um cuidado especial é
tomado com o método através do qual o usuário final irá interagir com o sistema. Na
análise de SADs, os desenvolvedores esperam que a maioria, se não todas, as consultas
feitas sejam adhoc10 . Sendo assim, os desenvolvedores de sistemas de apoio à decisão
estão mais interessados em especificar os dados para a base de informações do que
especificar os métodos de acessos aos dados.
Outra distinção básica entre sistemas tradicionais e sistemas de apoio à decisão é o objetivo
da fase de análise. Análises de sistemas de apoio à decisão são orientadas a dados,
diferentemente de sistemas tradicionais que colocam a lógica de processo como foco
principal. Na análise de SADs, as bases de dados fonte já existem e estão claramente
definidas. Sendo assim, os objetivos da análise de sistemas de apoio à decisão são:
compreender quais dados são de interesse dos usuários finais, como extrair esses dados
das bases operacionais e como disponibilizar essas informações para os usuários finais.
Basicamente, a análise 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.
■ Análise de Processo: define os processos de carga e extração.

■ Análise de Fontes de Dados: descreve os itens de dados que são de interesse do usuário
final. Essa fase descreve também como os dados serão editados, limpados, agregados
e sumarizados.
■ Análise de Carga de Dados: concentra-se em descrever como os dados serão carregados
dentro da base de dados do Data Warehouse.
■ Análise de Consultas de Dados: importa em como os usuários finais irão usar os dados.
Os dois últimos processos são de importância significativa para uma implementação

de SAD correta.
A análise de carga de dados envolve a compreensão de como os dados serão extraídos do

sistema fonte, como esses dados serão limpos e validados e como esses dados serão
carregados, agregados e sumarizados na base de dados alvo. Nesse aspecto, a integridade
referencial pode ser utilizada para garantir que valores de dados válidos 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 exclusão, ela não
acarreta nenhum problema de desempenho para a base de dados do DW, especialmente
porque a carga, normalmente, deve ser feita em horários fora de pico.
A análise 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 usuários finais planejam
usar. Diferentemente dos sistemas OLTP, que podem ter centenas de tipos de consultas,
praticamente todas as consultas dentro de sistemas de apoio à decisião recaem em uma
das quatro categorias a seguir:
■ Análise estatística: cálculos de somatórios, médias, etc.
■ Análise multivariável: comparações entre classes de objetos para analisar padrões.
■ Simulação e modelagem: utilização do SAD para validação de hipóteses.
■ Previsão: utilizar o sistema de apoio à decisão para previsão de valores futuros.
Essa categorização irá ajudar a modelar os relacionamentos e entidades envolvidos no SAD.
Entrevistas
O conhecimento do negócio e a compreensão das necessidades de informação das diversas
áreas da organização são fundamentais para a concepção de um ambiente de suporte à
decisão que permita subsidiar as atividades de controle do negócio, definição de estratégias
e elaboração de planejamento.
O ambiente de informação convencional fornece os dados que serão utilizados para gerar
as informações disponibilizadas pelo ambiente de suporte à decisão.
O levantamento da infra-estrutura de sistemas relacionada com as operações dos clientes

deve ser feito junto a representantes da área de tecnologia durante reuniões de trabalho e
deve considerar aspectos relacionados com a infra-estrutura tecnológica existente.
O principal objetivo da realização de entrevistas iniciais com representantes das diversas

áreas da organização é entender as características do ambiente de informação utilizado
pelas mesmas. As reuniões para entrevistas devem sempre contar com uma equipe fixa,
formada por pessoas que tenham um conhecimento da organização como um todo.
Idealmente são escolhidas duas pessoas, uma representante da área executiva ou diretoria
e outra da área de tecnologia da informação (TI). O importante é que estas pessoas tenham
uma visão geral do negócio da corporação.
Os dados coletados devem ser consolidados para traçar o perfil das necessidades que
irão nortear o planejamento do modelo para a implementação do ambiente de suporte à
decisão. Dados relativos aos sistemas de informação devem ser levantados junto às equipes
de desenvolvimento e produção (TI). O foco deste levantamento deve ser a identificação
do conteúdo e volume das bases de dados existentes.
Finalmente, a última atividade da etapa de identificação do ambiente de negócios é a

discussão e validação do sumário das informações levantadas e premissas para o modelo
com o corpo executivo da organização.
Características a Serem Analisadas

no Ambiente de Informações Existente
Disponibilidade de Informações
Deve-se analisar o volume de informações disponíveis para os usuários finais e quais os sistemas
que as geram. Esta análise deve averiguar a existência de informações que permitam a
segmentação de clientes e destacar a importância do cadastro de todos os clientes da organização.
Outro ponto de verificação importante é a possibilidade de existência de informações

divergentes quando analisadas de diferentes fontes.
Acesso às Informações Disponíveis

Verificar se o acesso é realizado através de consultas on-line e/ou relatórios e se existe
dificuldade para a obtenção de informações cruzadas (por exemplo, entre produtos x
filiais x clientes). Este fato leva um grande número de empresas a redigitarem em planilhas
(microinformática) alguns dados obtidos em relatórios para a obtenção da informação
desejada (ou no formato desejado).
Esta prática aumenta o prazo da disponibilização de informações estratégicas para os

níveis diretivos, gerando ainda sobrecarga para muitas áreas, que em algumas situações
precisam se desviar de suas atribuições para garantir a liberação de relatórios.
Acuracidade
Extrair o sentimento dos usuários em geral (grupo de entrevistados) com relação à
acuracidade das informações obtidas. Um fator que contribui para isto é a necessidade
de redigitação de dados para obtenção de algumas informações. Outro é a situação típica
de sistemas transacionais onde o momento em que a informação é obtida pode influenciar
em seu valor (os dados estão corretos, mas foram obtidos em momentos diferentes, levando
a resultados igualmente diferentes).
Modelos de Tabelas Geradas em

Entrevistas com os Usuários e Analistas
Durante o processo de entrevistas devem ser geradas tabelas que irão identificar as
necessidades de informação relativas à corporação como um todo, informações relativas
a áreas específicas e também necessidades comuns. A tabela da Figura 6.1 é um exemplo
de como elencar as necessidades de informação (necessidades de uma cadeia de
restaurantes) e cruzá-las com as áreas da organização.
Figura 6.1: Necessidades de Informação X Áreas.
Outra tabela importante a ser gerada é a que identifica os sistemas fontes que possuem as
informações necessárias dos usuários. A tabela da Figura 6.2 é um exemplo.
Usuários internos utilizam um conjunto de aplicativos corporativos ou desenvolvidos

para a área visando apoiar a execução das atividades que estão sob sua responsabilidade.
Figura 6.2: Relacionamento entre informações

necessárias e fontes de dados para sua geração.
Aplicativos corporativos são responsáveis pelo tratamento das transações relacionadas

aos produtos oferecidos pela organização. De um modo geral, eles atendem às necessidades
de informação operacional, através de consultas e de relatórios previamente definidos.
Aplicativos departamentais são desenvolvidos para atender as necessidades das áreas

que, normalmente, estão relacionadas com controles locais ou com o tratamento de dados
gerados por vários sistemas corporativos.
Para efeito de levantamento, devem ser considerados os aplicativos responsáveis por informações
necessárias à implementação do Data Warehouse. A tabela da Figura 6.3 exemplifica como
relacionar os aplicativos avaliados. Esta avaliação deve ser composta por macrofluxo do sistema,
documentação da base de dados, características de processamento e etc.
Figura 6.3: Relação de aplicativos analisados.
As entrevistas também devem identificar os volumes de dados dos sistemas fontes para
fins de projeção do espaço em disco que deverá existir no servidor de Data Warehouse.
Os volumes devem ser obtidos a partir de dados do ambiente de produção e representar
um dia ou mês aleatórios, podendo haver desvios (a maior ou a menor) em relação ao
valor médio. No entanto, para fins de avaliação de volume total de armazenamento em
disco necessário, estes desvios não afetarão a ordem de grandeza da capacidade necessária.
Outro fato a considerar é que os volumes de dados devem ser multiplicados por 3 (fator
recomendado pela maioria dos fornecedores de SGBD) para obtenção da capacidade de
disco necessária para a implementação da estrutura de dados que irá suportar o Ambiente
de Suporte à Decisão. 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 horários
da disponibilização dos arquivos (ou tabelas) necessários para a carga do Data Warehouse.
No cabeçalho destas tabelas podemos ter:
■ Horário: Término do processamento.
■ Momento: Indica quando os dados estão disponíveis (antes ou depois da execução de
determinado programa).
■ Interceptar: Indica o programa que libera ou utiliza o arquivo.
Os horários de término de processamento dos sistemas corporativos irão influenciar

diretamente a janela de tempo para carga de informações no Data Warehouse, assim
como o período de atualização (D-1 ou D-2), ou seja, o DW poderá ter informações
históricas atualizadas até o dia anterior ou, na pior das hipóteses, até dois dias anteriores.
Técnicas
Todas as técnicas básicas podem ser utilizadas. As entrevistas devem ser conduzidas
colocando os usuários (principalmente os gestores) como se estivessem em um ambiente
perfeito e pudessem obter todas as informações que desejam. O objetivo é extrair toda e
qualquer necessidade importante de informação gerencial. O entrevistador deve tentar
absorver destas pessoas a visão que têm em relação às tarefas que executam, o que elas
acham que devem fazer e como o fazem. Deve-se tomar cuidado com respostas agradáveis,
pois muitas vezes os entrevistados dão essas respostas com o intuito de auxiliar o
entrevistador e acabam mascarando alguma informação relevante.
Entrevistas eficazes dependem de uma cuidadosa preparação. Devemos começar definindo

a finalidade, identificando perguntas, fatores e informações que faltam.
Como é necessário entrevistar várias 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
responsáveis pelas áreas em questão. Gerentes podem deter informações preciosas e/
ou indicar quem poderá tê-las.
Ao começar as entrevistas pelos gerentes, praticamos uma técnica política, pois as pessoas
hesitam menos em conceder o seu tempo se o “chefe” estiver a par da entrevista e a tiver
aprovado. Quando entrevistamos alguém, devemos saber sua posição no organograma e
conhecer as funções básicas de seu departamento ou de seu grupo. Entrevistadores
despreparados fazem os entrevistados (no nosso caso, pessoas cheias de tarefas) perderem
tempo e conseqüentemente ficam desacreditados.
Outro fator importante é o roteiro (orientação) da entrevista, deve ser planejado antes.
Devemos ter sempre em mente perguntas para dar seqüência ao assunto se houver
desvio do objetivo-chave.
A entrevista deve ser aberta com uma atmosfera descontraída para que o estabelecimento
da comunicação seja favorável. Podemos iniciar com uma conversa sobre algo lúdico,
clima e etc. Contudo, não se pode perder muito tempo com isso e deve haver um cuidado
para essa técnica não atrapalhar a entrevista.
Em seguida, o entrevistador deve iniciar o processo com uma pergunta ou pedido genérico
do tipo: “Por favor, explique-me este modelo de negócio”. Depois de explicações do
usuário, é sempre bom resumir o que foi absorvido para verificar se a compreensão do
assunto está sendo correta, pois se houver discrepância o entrevistado irá discordar.
Em todo o decorrer da entrevista devemos ser políticos, ou seja, evitar críticas ao ambiente
de informações atual e manter a concentração nas respostas, valorizando-as por mais
insignificantes que algumas possam parecer.
Finalmente, é importante ter bom senso e não promover reuniões muito longas, pois no final das
mesmas a produtividade é baixa e usuários de Data Warehouses geralmente são ocupadíssimos.
Equipe
Considerando as análises necessárias para implementação de um Data Warehouse, a
equipe do projeto relaciona-se com usuários finais e equipes de desenvolvimento dos
sistemas legados (Figura 6.5).
Se não é possível obter as informações sobre os dados, também não será possível construir
corretamente as referências de metadados.
Por outro lado, a equipe também terá uma grande dependência da agilidade e
disponibilidade das equipes dos sistemas legados, para obter os arquivos (ou tabelas)
extraídos de acordo com os cronogramas de implementação.
É ainda necessário estabelecer acordos com os responsáveis pelo planejamento da

produção, para que os arquivos (ou tabelas) sejam extraídos e transmitidos para o servidor
de Data Warehouse em um tempo adequado para manter as informações atualizadas.
Assim, fica evidente que, mesmo possuindo os conhecimentos necessários e facilidades

de negociação, o resultado final e diário 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 decisão ou de grande relacionamento com os
ambientes de desenvolvimento e produção.
Outro ponto a considerar é a necessidade de relacionamento com os usuários. Além do

perfil necessário, a equipe (especialmente aquela voltada ao planejamento do ambiente)
deve ter acesso aos responsáveis pelas áreas usuárias, para garantir um perfeito
entendimento das necessidades e, novamente, estabelecer acordo de prazos de liberação
ou de acesso às informações.
Equipes de Desenvolvimento Coordenadores Ambiente

dos Sistemas Legados de Produção
Acordos para extração de dados Acordos de Janela de Tempo
Entendimentos da formação dos Acordos para processos de
dados transferência de dados
Equipe DW
Usuários Finais
Entendimento de necessidades de informação
Definição de indicadores de desempenho
Definição de necessidades de acesso
Figura 6.5: Relacionamentos da equipe de DW
A quantidade de componentes da equipe irá variar muito, dependendo da utilização ou não de

ferramentas que facilitem os processos. Por exemplo, a geração e manutenção de metadados
pode ser uma tarefa muito complicada caso não haja uma ferramenta com esta finalidade.
Outra tarefa que pode ser minimizada é a programação para consultas e relatórios. Se
forem utilizadas ferramentas adequadas, a equipe do projeto deverá preocupar-se apenas
com o suporte à ferramenta disponibilizada aos usuários, que passariam a ter a
responsabilidade sobre criar seus acessos aos dados (respeitando-se aí os limites
estabelecidos pela política de segurança de acesso). Nossa experiência mostra que este
suporte é sempre maior do que o esperado pela equipe DW. A maioria dos usuários ainda
não é capaz de construir consultas intuitivamente e criar seu próprios relatórios gerenciais
de acordo com a demanda. Os usuários preferem ter uma estrutura EIS (vide Capítulo 1),
ou seja, relatórios gerenciais prontos acionados via um simples botão gráfico.
Sendo assim, ao definir a equipe, deve-se levar em conta a possibilidade da alocação

de um ou mais profissionais para construir os relatórios gerenciais solicitados pelos
usuários e posterior disponibilização 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 não conseguem gerar consultas complexas
automaticamente, o profissional também deve conhecer a linguagem de consulta do
SGBD escolhido e o modelo de dados, capacitando-o para produzir consultas
complexas específicas.
A aversão dos antigos gerentes aos computadores...
Vários projetos já passaram por altos níveis de frustração pelo pouco uso ou desuso total do DW
após a sua implementação. É incrível, mas ainda existem diretores e gestores de empresas que
se negam a usar uma ferramenta OLAP disponibilizada e preferem continuar fazendo seus
cálculos no papel ou em planilhas eletrônicas. Além disso, ainda não é comum uma cultura de
criação dos relatórios gerenciais pelos próprios diretores. Para conseguir sucesso na utilização
do DW, deve existir uma política de marketing do produto, convencendo os usuários da
acuracidade e valiosidade das informações geradas. Os mais pessimistas dizem que isso só será
totalmente possível quando a atual geração de diretores aposentar-se e renovar-se com
administradores modernos e estrategistas.
O Gerenciador de Banco de Dados escolhido também excerce influência, na medida em

que os SGBDs especializados possuem recursos que facilitam a implementação das
tabelas, interface com as ferramentas de acesso e etc.
Quanto à organização, a equipe poderia estar assim orientada:

■ Grupo de profissionais com profundos conhecimentos das necessidades dos usuários
e das ferramentas de visualização.
■ Grupo de profissionais encarregado dos modelos de dados do Data Warehouse e Data
Marts, com amplos conhecimentos das estruturas de dados da organização, assim
como do Sistema Gerenciador de Banco de Dados e demais softwares para criação e
manutenção dos repositórios de informação.
Evidentemente haverá conhecimentos que deverão ser compartilhados entre os dois

grupos, visando o melhor aproveitamento do ambiente.
Ambiente de Hardware e Software

Por questões de desempenho, o servidor de DW deverá estar separado fisicamente
dos demais e, com base nos volumes identificados, possuir algumas características
importantes tais como: escalabilidade de memória, arquitetura SMP11 (Symmetric
Multi-Processor), recursos para acesso de grandes volumes de informação
simultaneamente, etc.
Deve-se observar que a implementação de um ambiente de suporte à decisão 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 através
de recursos de gerenciamento de rede. Este gerenciamento deverá prever o momento de
congestionamento (o que provocaria aumentos indesejáveis nos tempos de resposta),
permitindo que seja expandida a capacidade dos canais de alta velocidade antes da
ocorrência de congestionamento.
Outro ponto a ressaltar é que o tempo de resposta das consultas realizadas sobre um
Data Warehouse será também decorrência do volume de informações acessadas.
Dependendo da pesquisa, o tempo de resposta poderá ser de alguns minutos,
independentemente da velocidade do canal de atendimento.
Para a implementação de um DW será necessária a utilização de um conjunto

mínimo de softwares, composto por um Sistema Gerenciador de Banco de Dados,
software para geração do modelo multidimensional (pode estar acoplado à
ferramenta de acesso ou não) e ferramenta de acesso para os usuários f inais
(geralmente OLAP) (Figura 6.6).
Após a existência de um mínimo de informações históricas, poderão ser

consideradas também ferramentas para Data Mining e Database Marketing. Estas
ferramentas deverão também ser analisadas, considerando-se a rapidez de
implementação destas funções.
11
SMP é uma arquitetura de processamento paralelo onde um grupo de processadores trabalha
conjuntamente, sendo possível qualquer um deles executar uma parte do programa.
Figura 6.6: Arquitetura básica de hardware e software
Devido ao volume de informações armazenadas (e investimentos necessários em

disco), aliado ao fato de que as consultas efetuadas não caracterizam uma aplicação
de missão crítica, não é necessário o contingenciamento a partir de duplicidade dos
componentes do ambiente.
No entanto, é necessário investir em ferramentas (hardware e software) para a realização

de backups12 das estruturas de dados. A finalidade destes backups será minimizar o
tempo de restauração do ambiente, em caso de falha em qualquer um dos componentes.
Os principais SGBDs especializados em Data Warehouse possuem rotinas específicas

para este fim, permitindo backups incrementais (somente alteração), backups de estruturas,
backups de imagem de discos, etc.
Da mesma forma, os servidores especializados também disponibilizam estações de salva

(robótica) visando facilitar esta atividade. Um robô pode trocar uma fita automaticamente
quando a mesma esgota sua capacidade de armazenamento, não havendo assim a
necessidade de intervenção humana para continuidade do backup.
12
Backups são cópias de segurança de um sistema.
Durante a implementação da primeira fase de um DW, normalmente seu servidor

está totalmente dedicado às atividades de desenvolvimento e testes. No entanto, a
partir da liberação da primeira fase para os usuários finais, e por toda a vida do Data
Warehouse, os desenvolvedores necessitarão de um ambiente exclusivo para
desenvolvimento e testes, já que esta atividade é incompatível com o acesso aos
dados executado pelos usuários finais.
Dependendo do servidor contratado, poderá ser feita uma expansão que será
configurada como ambiente independente do ambiente “de produção”, isto é, aquele
ambiente sendo utilizado para consultas.
Por outro lado, outros equipamentos não possuirão esta característica, exigindo a
disponibilização de um servidor exclusivamente para esta finalidade. Deve-se observar,
aqui, que este servidor e o SGBD utilizado devem ser totalmente compatíveis com os
utilizados no ambiente principal, evitando-se assim retrabalho e dificuldades na
implementação das novas fases.
Por fim, a infra-estrutura de hardware e software disponibilizada para o DW deve possuir

as seguintes características:
■ Integração com o ambiente transacional existente.
■ Organização das informações por assuntos relevantes para o negócio.
■ Informações não voláteis usadas como base para análises e projeções.
■ Interface gráfica amigável.
■ Disponibilidade de ferramentas de consulta de fácil utilização e flexibilidade para
apresentação de resultados.
■ Dicionário de dados (metadados) para facilitar a referência às informações disponíveis
(Ex.: significado da informação e regras para tratamento).
■ Séries históricas de informações consolidadas, com diversos níveis de agregação,
atualizadas com a periodicidade adequada para cada tipo de informação (Ex.: evolução
diária do valor de compra de um produto).
■ Tratamento de informações em diversas dimensões (Ex.: volume de vendas realizadas
por região, por tipo de produto, por gerente, por mês).
■ Tratamento de grandes volumes de informações em cada consulta.
■ Combinação de consultas predefinidas e consultas não previstas antecipadamente.

■ Consultas iterativas e seqüenciais, com salvas intermediárias de resultados para
simplificar a lógica de tratamento da informação (Ex.: seleção de contratos com valor
superior a R$10.000, classificação por loja e subtotal por gerente de conta).
■ Interoperabilidade das diversas ferramentas responsáveis por funções específicas (Ex.:
consulta, análise de risco, simulações, etc.).
Esquema de Carga
Como ferramentas ETL ainda são relativamente caras, pequenas, médias e até mesmo
grandes empresas tendem a construir um sistema de carga próprio para o DW. Sendo assim,
descreveremos aqui os componentes básicos que um sistema como esse deve possuir.
Praticamente todos os dados armazenados em um Data Warehouse se originam de sistemas

externos. A colocação destes dados e a preparação completa de modo a poder utilizá-los
é uma das principais etapas em um Data Warehouse.
Muitas etapas são necessárias para transformar dados não processados de origem externa
em informações prontas para serem acessadas pelo usuário final e para serem utilizadas
no processo de tomada de decisões 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, conexões de canal de mainframe e fitas magnéticas.
■ O dados precisam ser convertidos para o formato interno do banco de dados escolhido
para o DW a partir de uma variedade de representações externas, incluindo registros
de comprimento variável e fixo, formatos de caracteres e binários e etc.
■ Os dados precisam ser filtrados de modo a rejeitarem valores inválidos, chaves repetidas
ou registros com outros tipos de erro.
■ Os registros precisam ser reorganizados a partir de representações dos Flat Files13 de
modo a ficarem compatíveis com o esquema do DW. Quando o sistema fonte utiliza
um banco de dados diferente ou imcompatível, ou até mesmo utiliza outra estrutura de
13
Flat File é um arquivo plano geralmente do tipo texto, formatado para conversão de outro banco de dados. O Flat
File possui registros de tamanho único, onde cada registro de detalhe gera uma inclusão no banco de dados.
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 exigências de
configurações para particionamento de dados, balanceamento de discos e etc.
■ Os registros precisam ser verificados em relação ao banco de dados existente de modo
a assegurar consistências, mantendo uma integridade referencial completa.
■ Os registros precisam estar corretamente indexados.
A Figura 6.7 representa as etapas básicas de um fluxo de carga:
Figura 6.7: Esquema básico de carga de um Data Warehouse.
Uma atualização de Data Warehouse não estará completa até que todas as etapas tenham
sido finalizadas de maneira bem-sucedida. A transmissão dos Flat Files dos computadores
em que estão instalados os sistemas legados para o servidor de DW pode ser feita de
várias formas como via FTP (File Transfer Protocol ou protocolo de transferência de
arquivo), por exemplo. Vale salientar que Flat Files são dispensáveis em organizações
que possuem uma estrutura unificada de banco de dados e são 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 referência, o sistema de origem
e o tipo deste arquivo que geralmente é texto.
■ Detail: São 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 totalização de registros com o
intuito de verificar se não houve nenhum problema na transmissão 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 Capítulo 2) encontram-se tabelas que são a cópia dos Flat Files e
as tabelas de violação de dados, para cada uma destas tabelas. Estas tabelas de violação
são, por sua vez, a cópia das originais mais um atributo de diagnóstico. São exemplos de
tipos de diagnóstico:
■ Violação de chave estrangeira14: um contrato para um cliente que não existe.
■ Violação de chave primária: dois produtos com o mesmo código.
No repositório ou ODS (vide Capítulo 2) encontram-se tabelas de dimensão (com seus

históricos completos) e de fatos com um histórico menor. Também podem existir tabelas
normalizadas para validação como cargos, cidade, estado. O repositório serve para filtrar
os dados livrando-os de inconsistências tipo funcionário cujo salário é igual zero.
O conteúdo do repositório não é igual ao do Data Warehouse. Por exemplo, os fatos

armazenados podem ser de apenas os últimos três meses. Muitas empresas não adotam o
14
Chave estrangeira é um campo qualquer da tabela que permite representar a associação lógica entre
linhas de duas tabelas. Exemplificando, uma tabela de contratos individuais deve possuir um campo
“código do cliente”, que representa o cliente que fez o contrato. Este tipo de campo é chamado de chave
estrangeira, pois é uma chave primária exportada da tabela de clientes.
ODS e fazem todas as verificações de violações de chaves e de regras de negócio na

própria Staging Area sem armazenar histórico (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á estão no formato compatível 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 responsável, no mínimo,
pela execução, 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 programação.
A operação de um Sistema de Carga consiste basicamente na Montagem de uma Agenda

de Carga, Liberação da Agenda e Monitoração da Carga.
Periodicamente (diariamente, mensalmente, etc.) os arquivos (Flat Files) contendo as

informações dos sistemas legados são 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 deverão 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 após a chegada
de todos os Flat Files o processo de carga deve ser iniciado. Também deve ser possível
excluir um sistema (conjunto de Flat Files) da agenda, evitando assim o carregamento
do mesmo em dias específicos. O processo como um todo consiste em carregar os Flat
Files para tabelas temporárias 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 são geralmente escritas na linguagem do banco de dados
escolhido e/ou empregando utilitários de conversão de banco de dados.
■ Tabela de tarefas: contém os arquivos de cada sistema que serão carregados diariamente
e a data de movimento. Também deve haver um campo para controlar as diversas
situações 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 dependência de arquivos: deve conter as dependências entre arquivos para a
seqüência correta da carga. Alguns arquivos não podem ser carregados antes de outros.
■ Tabela de controle de fim de carga: contém os nomes de todos os arquivos já carregados.
Para carregar os dados nas diversas camadas, o sistema deverá exibir a relação de sistemas
com suas respectivas datas de processamento. O operador poderá fazer alguma alteração
nas datas antes de o processo começar, montando assim a tabela de carga. A partir das
tabelas de carga e de sistemas é montada a tabela de tarefas (to do list), ou seja, a lista de
sistemas que serão carregados no dia.
Excetuando a carga na Staging Area, onde se acrescenta o esvaziamento das tabelas

temporárias no início do processo e ignoram-se as dependências entre arquivos, o sistema
deve fazer basicamente o seguinte: buscar tarefas em espera, disparar as rotinas de cargas
respectivas de acordo com a dependência entre arquivos e verificar se houve violações.
Geralmente, as violações são checadas pelas rotinas de carga construídas no banco de dados.
Estas rotinas geram uma exceção para o sistema de carga que fica responsável em alertar o
operador. Aconselhamos métodos como o envio de e-mails para os analistas responsáveis.
Pontos de Verificação
Para Garantia de Qualidade
Determinadas características do ambiente de informação antes da implementação do DW
poderão dificultar a implementação de alguns conceitos, frustrando expectativas. Dessa forma,
recomendamos que seja analisada a melhor alternativa para suprimir estas dificuldades.
De modo geral, as principais situações a serem consideradas são:

■ Verificar se informações significativas para os processos de segmentação de clientes
estão no cadastro e se todos os clientes possuem cadastro. Esta prática é comum em
muitas organizações; somente fazer o cadastro quando o cliente solicita um produto que
necessita de maiores garantias. Porém, o grupo sem cadastro ficará excluído de qualquer
análise setorial que envolva as informações do cadastro. Num ambiente pleno de suporte
à decisão toda informação que permita categorizar o cliente é fundamental, seja para
planejamento de campanhas, seja para análise da pulverização do risco por segmento.
■ Verificar se informações típicas para segmentação de clientes fazem parte das bases
de dados de clientes da empresa. Existem informações (tais como renda familiar,
número de filhos, idade dos filhos, etc.) que podem não ser trabalhadas pela organização
em suas análises de segmento.
■ Averiguar as informações que se encontram em microcomputadores (digitadas
diretamente pelo departamento gestor da informação). Este tipo de dado é de difícil
extração para alimentação do DW. Devem ser consideradas alternativas para envio
destas informações para sistemas corporativos.
■ Se possível, diminuir as janelas de tempo para extrações 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 manutenção do DW com informações
em D-1 (do dia anterior). É pertinente uma análise para verificação da possibilidade
de diminuição da janela de tempo.
Um ambiente ideal de suporte à decisão deveria possuir, no mínimo, as seguintes

características:
■ Integração com o ambiente de dados convencional: o ambiente de suporte à decisão
será um complemento do ambiente de aplicativos convencional. As informações
disponibilizadas pelo novo ambiente serão geradas a partir dos dados tratados pelos
sistemas aplicativos e que refletem as transações realizadas pela organização;
■ Flexibilidade para consulta de informações e para apresentação de resultados: o
acesso às informações deverá ser interativo e flexível, permitindo que, através de
comandos simples, o usuário submeta suas consultas e selecione a forma de
apresentação (relatório colunar, gráficos de diversos tipos ou uma combinação de
ambos) que melhor satisfaça suas necessidades.
■ Detalhamento seletivo de informações: deverá existir a possibilidade de detalhar as
informações, partindo de um elevado grau de consolidação 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 específico e chegando ao volume de uma cidade selecionada).
Normalmente, este procedimento estará associado à ocorrência de distorções nos
resultados esperados.
■ Gerenciamento por exceção: deverão estar disponíveis mecanismos que permitam a
geração de avisos de alerta em caso da ocorrência de desvios nos valores estabelecidos
para itens que foram selecionados para acompanhamento (Ex. taxa média de juros
praticada por uma loja, diferente daquela recomendada).
■ Indicadores de desempenho e índices de gestão: deverão existir indicadores que
permitam avaliar o desempenho de entidades (Ex.: volume de vendas por loja) ou de
grupos (Ex.: taxa de inadimplência por Regional), com base em critérios previamente
definidos. Adicionalmente, deverão estar disponíveis índices que permitam fazer a
gestão do negócio (Ex.: custo médio da captação de recursos).
■ Acesso a informações externas: o acesso a informações externas permitirá a

identificação de tendências do mercado e a avaliação da situação da empresa perante
seus concorrentes. A identificação dos concorrentes potenciais será feita com base no
perfil dos clientes e dos produtos oferecidos.
■ Modelos de simulação: deverão estar disponíveis ferramentas que permitam
desenvolver modelos destinados a simular a implementação das diversas alternativas
existentes e fazer a análise comparativa dos resultados gerados por cada uma delas
(Ex.: avaliar o impacto de duas taxas de juros diferentes para a concessão de crédito;
composição da base de clientes para atingir um dado crescimento percentual).
■ Segurança de acesso ao ambiente: a natureza do ambiente de suporte à decisão e das
informações tratadas exigirá a disponibilidade de mecanismos que assegurem o controle
de acesso de acordo com os critérios de segurança estabelecidos.
Cronograma de Implementação
A implementação de DW deverá ser gradual e constituída por etapas consecutivas. Em
cada fase deverão ser disponibilizadas as informações e os recursos destinados a apoiar
as atividades de uma área alvo.
O processo de implementação deverá contemplar a adequação do ambiente de informação

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 necessários para gerar certos tipos de informações
previstas pelo ambiente de suporte à decisão.
O cronograma de implementação 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 informação e gerando novos Data Marts.
Inicialmente, são necessárias 12 atividades, com duração total variável e diretamente

proporcional à disponibilidade de recursos humanos. Esta duração deve prever ainda a
total disponibilidade dos recursos necessários de hardware e software.
O cronograma abaixo ilustra e dá orientação para atividades que podem ser feitas
concomitantemente.
Figura 6.9: Cronograma de implementação.
Nos demais incrementos, haverá uma repetição de atividades, sendo que algumas serão
bastante simplificadas. Dependendo de decisões da equipe de projeto, atividades poderão
ser divididas em subatividades. Assim, a duração de cada atividade será definida de
acordo com o escopo adotado e recursos alocados.
Incrementos posteriores podem ser conduzidos resumidamente assim:

■ Treinamento em informática: somente será necessário se incluídas novas ferramentas
(Data Mining, por exemplo).
■ Modelo lógico/físico: necessário pela inclusão de novas estruturas de dados no novo
incremento.
■ Detalhar fontes e tratamento dos novos dados.
■ Novas rotinas de extração.
■ 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 extraídos e
estruturas implementadas.
■ Carga de dados: iniciar as cargas diárias de dados. As primeiras em situações de teste,
validando as rotinas desenvolvidas. Recomendamos trabalhar inicialmente em ambiente
de teste (desenvolvimento).
■ Ferramentas para usuários: em princípio, instalar a ferramenta para novos usuários,
se houverem. Exceto se houver nova ferramenta (por exemplo, Data Mining).
■ Treinamento de usuários: em caso de novos usuários ou nova ferramenta, treinamento
completo. Caso sejam mantidos os mesmos usuários, deverá haver apenas treinamento
esclarecendo sobre as novas informações implementadas;
■ Laboratório: com base nos novos dados carregados, acompanhar os usuários nas
primeiras consultas ao Data Warehouse.
Resumo
Ao planejarem construir um SAD as organizações devem buscar um projeto evolutivo,
pois para um DW abranger toda corporação inicialmente, a mesma deve ser totalmente
informatizada e integrada, além do fato de o projeto ser extremamente complexo e

com alta probabilidade de insucesso. Como a integração total é rara de ser encontrada
ainda hoje, deve-se aproveitar a estrutura operacional disponível e desenvolver um
Data Mart de cada vez.
Os resultados são atingidos em ciclos médios 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 análise de sistemas

tradicional, pois análises de sistemas de apoio à decisão são orientadas a dados,
diferentemente de sistemas tradicionais que colocam a lógica de processo como
foco principal. Na análise de SADs, as bases de dados fonte já existem e estão
claramente definidas. Sendo assim, os objetivos da análise de sistemas de apoio à
decisão são: compreender quais dados são de interesse dos usuários finais, como
extrair esses dados das bases operacionais e como disponibilizar essas informações
para os usuários finais.
Enrevistas com usuários finais durante o decorrer do projeto são de grande importância
para o entendimento das características do ambiente de informação existente. Podem ser
usadas todas as técnicas tradicionais de entrevistas, coletando assim dados consolidados
para traçar o perfil das necessidades que irão nortear o planejamento do modelo para a
implementação do ambiente de suporte à decisão.
A equipe de projeto para construção do DW tem seu tamanho influenciado pela utilização
ou não de ferramentas que facilitem todos os processos envolvidos. Independente do
tamanho, a equipe se divide em dois grupos básicos: grupo de profissionais com profundos
conhecimentos das necessidades dos usuários e das ferramentas de visualização e grupo
de profissionais encarregado dos modelos de dados do Data Warehouse e Data Marts,
com amplos conhecimentos das estruturas de dados.
Por questões de desempenho, o servidor de DW deverá estar separado fisicamente dos

demais e com base nos volumes identificados possuir algumas características importantes,
tais como: escalabilidade de memória e recursos para acesso de grandes volumes de
informação simultaneamente. Em se tratando de software, um DW necessita de um Sistema
Gerenciador de Banco de Dados, de um software para geração do modelo multidimen-
sional (pode estar acoplado à ferramenta de acesso ou não) e de uma ferramenta de

acesso para os usuários finais (geralmente OLAP).
Ferramentas ETL também são softwares importantíssimos em um processo de Data

Warehousing e pode ser viável construí-las especificamente para cada caso. Um sistema
ETL deve ser responsável, no mínimo, pela execução, 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 programação.
Para garantir a qualidade do DW e evitar frustrações, alguns cuidados básicos podem

diminuir os riscos de fracasso do projeto, tais como: verificar se informações típicas
para segmentação de clientes fazem parte das bases de dados de clientes da empresa;
disponibilizar mecanismos que permitam a geração de avisos de alerta em caso da
ocorrência de desvios nos valores estabelecidos para itens que foram selecionados
para acompanhamento, etc.
O cronograma de implementação 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 informação e gerando novos Data Marts.
Capítulo 7: Estendendo a UML Para Documentar um Data Warehouse 129
7
C A P Í T U L O
Estendendo a UML
Para Documentar um
Data Warehouse
Documentar um Data Warehouse significa buscar a adequação de artefatos+ da análise

de sistemas moderna para especificar os dados de interesse dos usuários finais, como
extrair esses dados das bases operacionais e como disponibilizar essas informações para
estes usuários. Por questões de compatibilidade com as atuais metodologias de
desenvolvimento de software e para reaproveitar os modelos utilizados pelas ferramentas
CASE15 , devemos buscar a utilização da linguagem UML (Unified Modeling Language
ou linguagem de modelagem unificada) como mecanismo de representação para
especificar e documentar as diversas fases do desenvolvimento de um DW. De nada
adianta termos uma metodologia que apresenta novas simbologias e notações que não
possuem suporte das ferramentas CASE significativas do mercado.
A linguagem de modelagem UML é o resultado final da síntese de métodos de análise e

projeto orientados a objetos que surgiram no final dos anos 80 e início dos anos 90.
Tendo sua primeira versão lançada em 1997, a UML representa, principalmente, a
unificação dos métodos propostos por Booch, Rumbaugh e Jacobson. A UML, ao contrário
de seus ancestrais diretos, não especifica um processo a ser seguido, mas limita-se a
constituir-se de uma linguagem de modelagem para visualização, especificação,
construção, documentação e gerenciamento de sistemas de software.
Vista como padrão hoje, a UML compreende uma série de artefatos que são utilizados
para análise de requisitos e projeto de um sistema de software. O leitor interessado
em uma documentação mais completa e específ 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. São identificadas e definidas camadas (subsistemas),
módulos (partes de subsistemas) e interdependências.
+
Nesse contexto, o termo artefato refere-se a um resultado tangível de um processo de desenvolvimento. A
UML oferece uma série de artefatos de documentação 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 construção de
um software seja ela lógica ou física, documentação ou teste.
Uma estrutura em camadas é algo desejável 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 módulos (pacotes). Os
módulos agrupam unidades funcionais (classes) que têm correlações.
No projeto arquitetural, definem-se modelos gráficos com a disposição das camadas em

sistemas computacionais. Para as camadas que estão em sistemas computacionais distintos
deve-se elucidar como é feita a comunicação entre elas (ODBC16 , etc.).
O critério de “particionamento” dos subsistemas em módulos é de acordo com o nível de

acoplamento das funcionalidades. Portanto, dentro dos módulos as classes têm um maior
nível de acoplamento. Já o acoplamento entre as classes dos módulos externos é mais
fraco, isolando assim a complexidade. O objetivo é criar uma arquitetura em que o projeto
a ser desenvolvido esteja preparado para sofrer manutenções evolutivas de forma que
uma alteração não cause problemas não esperados.
Figura 7.1: Projeto arquitetural de um DW.
16
ODBC (Open DataBase Connectivity) é uma especificação Microsoft para permitir que aplicações Windows
acessem a múltiplos dados através de um método simples, sem considerar os diversos formatos dos
arquivos de dados.
Em um DW, exemplificando uma estrutura básica sem ODS, temos uma arquitetura
distribuída, sendo composta de um repositório de dados central (o próprio Data
Warehouse), que é acessado por máquinas clientes em diversos setores da organização,
conforme mostrado no projeto arquitetural representado pela Figura 7.1.
Documentando a arquitetura do DW é possível identificar facilmente as decisões tomadas

em alto nível, tais como: modularização, estrutura de comunicação e controle, estratégia
de persistência e paradigmas de bancos de dados usados. É importante descrever e elucidar
o funcionamento de cada módulo.
Documentação de Data Marts

Para cada novo Data Mart implementado, deve-se gerar um documento contendo todas
as informações que especificam a total funcionalidade do mesmo. Podemos citar como
indispensáveis em uma documentação os seguintes itens:
■ Objetivo do Data Mart;
■ Descrição do funcionamento básico.
Visão Estática
Em se tratando de visão estática dos dados, é importante acrescentar à documentação o
modelo conceitual de dados da Staging Area e o modelo conceitual da camada de dados
(DW) propriamente dita. Além disso, se houver, é importante descrever a definição dos
Flat Files, obedecendo a uma padronização 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 referência 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 geração (vide exemplo na
tabela da Figura 7.2)
Figura 7.2: Bases de dados fontes

e Flat Files associados.
Visão Dinâmica
Para documentação de procedimentos ou métodos criados para efetuar carga e
transformação de dados no DW é viável descrever:
■ Objetivo
■ Parâmetros
■ Origem de dados
■ Tabelas afetadas
■ Pseudocódigo básico do funcionamento.
Em relação à representação gráfica da transformação de atributos, é possível criar, através

da UML, uma semântica específica para DW como veremos a seguir:
Transformação 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: Representação de transformação simples de atributos.
transformando-se em id_dependência, através de uma consulta à dimensão

tb_dim_dependência. O atributo resultante fará parte da tabela tb_fatos_vendas.
Transformação de Atributos
em Mais de um Atributo
Existem situações 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: Representação da transformação em mais de um atributo.
Tabela se Transforma em Outra

sem Alteração de Atributos
Transformações desse tipo (vide Figura 7.5) indicam que todos os atributos da primeira
tabela também existem na segunda.
Figura 7.5: Representação da transformação de tabelas.
Atributos Novos nas Tabelas

Atributos novos podem ser representados com um sinal “+” para indicar a adição de um
algo novo na transformação. Na Figura 7.6 os atributos “id_produto” e “dt_inicio” foram
acrescentados à tabela “tb_dim_produto”.
Figura 7.6: Representação do surgimento

de novos atributos.
Atributos que Deixam de ser Usados

Atributos que passarão a não existir em uma tabela alvo podem ser representados com um sinal
“-” para indicar a exclusão na transformação. Na Figura 7.7 o atributo “hora” não é exportado.
Figura 7.7: Representação de atributos que deixam de ser usados.
Chaves Artificias
Podemos ressaltar chaves artificiais com um indicador de seqüência, seguido do rótulo
que contém o nome do atributo correspondente à chave. Na Figura 7.8 o atributo
“id_produto” de tb_fatos_vendas é uma chave artificial (vide Capítulo 4).
Figura 7.8: Representação de chaves artificiais.
Estereótipos Para Dimensão,

Tabela de Fatos e Tabelas Auxiliares
A UML oferece um grau de liberdade para que seja possível ajustá-la a
necessidades específicas. Um estereótipo está relacionado com a introdução de novos
elementos para permitir que o usuário estenda a capacidade de modelagem da linguagem.
Figura 7.9: Representação de tabelas

auxiliares e dimensões.
O uso de estereótipos, no nosso caso, facilita a visualização e entendimento das tabelas

nas suas respectivas camadas. Tabelas de dimensão podem ser representadas pelo estereótipo
<<Dimensão>> seguido de um número que representa o tipo da dimensão (1, 2 ou 3) (vide
Capítulo 4). Tabelas auxiliares (Staging Area) e tabelas de fatos serão 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 símbolos “(A)”, “(N)” e “(S)”
para caracterizar indicadores aditivos, não-aditivos e semi-aditivos respectivamente.
Figura 7.10: Representação de hierarquias, agregados e indicadores.
Como agregados não deixam de ser tabelas de fatos, podemos acrescentar ao estereótipo
<<Fato>> o estereótipo <<Agregado>>. Os campos utilizados para agregação podem
ser representados pela ligação das dimensões com a tabela de fatos agregada. Estas ligações
representaram os campos de agregação utilizados. Também é possível especificar a função
de agregação (vide na Figura 7.10 a função Soma()).
As hierarquias podem ser documentadas com notas indicando os campos envolvidos e

seus respectivos níveis na mesma.
Documentação da Configuração
Física e de Relatórios OLAP
O gerenciamento de grandes volumes de dados causa muitos problemas
administrativos e de desempenho, o que pode ser minimizado a partir de técnicas
como particionamento de tabelas e de índices (vide Capítulo 8). A documentação do
projeto deve especificar todas as técnicas utilizadas, com o intuito de orientar futuras
manutenções aditivas e até corretivas.
Outro ponto de destaque na documentação de um DW é a especificação dos relatórios

OLAP construídos. Na engenharia de software tradicional, se não houver uma rigorosa
política 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 construção de um ambiente de suporte à decisão o
gerente de projeto deve tomar cuidado para não começarem a surgir “donos de relatórios”.
Alguns relatórios podem possuir características especiais e um alto nível de complexidade,
dificultando ou impossibilitando a manutenção dos mesmos. Assim, deve existir uma
exigência da documentação.
Quando um relatório for construído, deve-se elucidar o uso de comandos específicos da

linguagem de consulta (comandos que não foram gerados automaticamente pela
ferramenta OLAP) e artifícios, tais como funções e procedimentos armazenados,
construídos no SGBD, exclusivamente para dar suporte a relatórios complexos. Para
documentar estas funções e programas, pode ser utilizada a mesma estrutura apresentada
na seção Visão Dinâmica, também utilizada para documentar procedimentos ou métodos
criados para efetuar carga e transformação de dados no DW.
Resumo
Por questões de compatibilidade com as atuais metodologias de desenvolvimento de
software e para reaproveitar os modelos utilizados pelas ferramentas CASE, devemos
buscar a utilização da linguagem UML (Unified Modeling Language ou linguagem de
modelagem unificada) como mecanismo de representação para especificar e documentar
as diversas fases do desenvolvimento de um DW.
É relevante documentar a arquitetura do DW para possibilitar a fácil identificação das

decisões tomadas em alto nível, tais como: modularização, estrutura de comunicação e
controle, estratégia de persistência e paradigmas de banco de dados usados. É importante
descrever e elucidar o funcionamento de cada módulo.
Para cada novo Data Mart implementado, deve-se gerar um documento contendo todas
as informações que especificam a total funcionalidade do mesmo. Com relação à visão
estática dos dados, os tradicionais artefatos UML para representação de modelos
conceituais podem ser usados para documentação do modelo de dados da Staging Area e
do modelo da camada de dados (DW) propriamente dita.
Para documentação da visão dinâmica descrevemos procedimentos ou métodos

criados para efetuar carga e transformação de dados e, em relação à representação
gráfica da transformação de atributos, é possível criar, através da UML, uma semântica
específica para DW.
A documentação do projeto também deve especificar todas as técnicas utilizadas para

otimização física do DW e relatórios construídos nas ferramentas OLAP. Devemos facilitar
manutenções corretivas e aditivas no banco de dados, bem como evitar o nascimento de
“donos” de relatórios impossíveis de serem mantidos.
Capítulo 8: Otimização da Configuração Física de um Banco de Dados... 141
8
C A P Í T U L O
Otimização da Configuração
Física de um Banco de Dados
Para Data Warehouse
Conforme foi visto no Capítulo 2, um Sistema de Suporte à Decisão baseado em Data

Warehouse é caracterizado pela consolidação de dados provenientes de diferentes fontes,
armazenados por longos períodos de tempo com o objetivo de fornecer informações em
níveis estratégico e gerencial. Grande volume de dados e exigência de desempenho em
processos de carga e processamento de consultas são, também, pontos que distinguem
um SAD de um Sistema de Processamento On-Line. Em função dessas diferenças, o
projeto físico de um Data Warehouse difere de um projeto físico para bases de dados
operacionais, e sua perfeita criação e otimização representam novos desafios para Analistas
e Administradores de Banco de Dados (DBAs) que, a partir de agora, precisam lidar com
esse novo tipo de aplicação.
Embora a maioria das técnicas de projeto físico utilizadas para Sistemas OLTP sirva
para o ambiente de Data Warehouse, elas não são suficientes para solucionar os problemas
inerentes ao volume de dados trabalhado em um Data Warehouse e atender às pressões
por consultas mais rápidas. A combinação desses fatores tem contribuído, cada vez mais,
para o desenvolvimento de novas características nos SGBDs a fim de suportar as
exigências impostas por aplicações baseadas em DW. Em conseqüência, faz-se necessária
a reciclagem técnica dos DBAs que passarão a ser responsáveis por grandes repositórios
de dados para que os mesmos tenham conhecimento das principais técnicas e soluções
disponíveis atualmente para essa nova classe de aplicação. Somente através dessa
consciência, poderá ser possível desenvolver projetos físicos que traduzam segurança,
disponibilidade e alto desempenho.
Decisões de projeto físico, a exemplo da escolha de índices e estratégias de

particionamento, possuem profundo impacto nos processos de um ambiente de Data
Warehouse. Por esse motivo, dedicamos um capítulo a esse tema, procurando abordar o
assunto da maneira mais prática, apresentando os principais conceitos e enumerando um
check list de decisões a serem tomadas em todas as fases do desenvolvimento de um
projeto de Data Warehouse.
Este capítulo, portanto, possui dois principais propósitos: Prover embasamento teórico
necessário para a elaboração de um projeto físico de dados para Data Warehouse; e
servir de base para a escolha de um SGBD que apresente características que dêem suporte
à criação e evolução de um banco de dados voltado para suporte à decisão. Não representa
nosso objetivo substituir a experiência de um DBA, mas apontar questões cruciais que
devem ser conscientemente discutidas levando-se em conta os principais objetivos e

exigências de um projeto de SAD.
Bloco de Dados
A grande maioria dos Sistemas Gerenciadores de Banco de Dados armazena seus dados
em uma unidade lógica chamada bloco de dados ou página. Uma tabela, por exemplo, é
formada por vários blocos que são responsáveis por armazenar seus registros. Um bloco
representa a menor unidade de Entrada e Saída (E/S) para um SGBD e, geralmente,
consiste de um ou mais blocos contíguos do Sistema Operacional. De maneira geral, um
bloco de dados em um SGBD é dividido em três partes distintas (Figura 8.1): Cabeçalho,
Área de Dados e Área Livre.
Figura 8.1: Representação genérica de um

bloco de dados em SGBDs
O cabeçalho armazena informações, tais como:

■ Identificador do bloco.
■ Controle transacional.
■ Diretório contendo o deslocamento de cada registro no bloco.
■ Indicador de tempo referente ao último acesso.
■ Apontadores para outros blocos.
A Área de Dados representa o espaço 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 informações relacionadas a uma linha de tabela ou índice.
Um componente de registro, por sua vez, é subdividido em: Cabeçalho de Registro e
Informações do Registro (Figura 8.2).
Figura 8.2: Detalhamento de

um componente de registro.
A parte Cabeçalho do Registro armazena informações como:

■ Identificador do registro.
■ Número de colunas do registro.
■ Apontador para outros registros.
A parte Informações do Registro contém as colunas do registro e seus respectivos

tamanhos, sendo essa parte a responsável por armazenar os dados propriamente ditos.
A Área Livre representa a porção do bloco reservada para a manutenção de registros já

existentes. Quando a Área de Dados é totalmente preenchida, não é possível inserir novos
registros em um bloco. A partir desse momento, a Área Livre funciona como uma reserva
de espaço destinada às alterações efetuadas nos registros do bloco. Como exemplo de
alteração, podemos imaginar um registro com uma coluna do tipo CHARACTER
VARYING17 que no momento de inserção encontrava-se com valor nulo e, em um dado

momento, recebeu uma cadeia de caracteres de tamanho 50. Caso não existisse essa
reserva de espaço 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 ocorrência degrada o desempenho, pois aumenta o número de operações de
E/S uma vez que para ler o registro será necessário acessar dois blocos de dados.
Uma vez esclarecido o conceito de bloco de dados, vamos verificar qual a influência
desse componente no projeto físico de um Data Warehouse.
Tamanho de Bloco de Dados

Durante a criação de um novo banco de dados o DBA precisa determinar o tamanho do
bloco de dados a ser utilizado. Tal decisão é totalmente dependente das características
físicas das tabelas do banco a ser criado e do tipo de aplicação.
Aplicações OLTP lidam, normalmente, com conjuntos de resultado pequenos, ou seja,

poucas linhas são acessadas por vez. Logo, possuir blocos com tamanho pequeno
economiza espaço em memória durante o acesso a dados. É por essa razão que se
recomenda para ambientes operacionais tamanhos de bloco entre 2 e 8 Kbytes.
Data Warehouses, ao contrário, possuem tabelas com grande número de colunas

(dimensões) e suas consultas resultam, em sua maioria, em grandes quantidades de
dados. A primeira característica, tabelas com número elevado de colunas, sugere um
bloco de dados que seja suficientemente grande para acomodar um número razoável
de linhas, reduzindo, dessa forma, o número de operações de E/S. A segunda
característica, conjuntos de resultado com volume grande de dados, também favorece
operações de E/S em função 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
recomendação para o tamanho de bloco a depender do tipo de aplicação. Nela, pode-se
observar que quanto mais uma aplicação aproxima-se de um Sistema de Suporte à
Decisão maior deve ser o seu bloco de dados.
17
CHARACTER VARYING é um tipo de dado que representa uma cadeia de caracteres de tamanho variável.
Figura 8.3: Relação entre tamanho

de bloco e tipo de aplicação.
Tamanho da Área Livre

Em um ambiente OLTP, fica evidente a necessidade de certo espaço reservado para a Área
Livre do bloco de dados, uma vez que os dados são bastante voláteis. Porém, uma vez no
Data Warehouse, os dados não mais sofrem alterações e suas mudanças são capturadas
através de novos registros. Logo, com o objetivo de economizar espaço em disco e maximizar
o número de linhas por bloco, pode-se reservar muito pouco espaço ou nenhum para a Área
Livre nos blocos de dados de um banco voltado para Data Warehouse.
Separação Física de Tipos de Dados

Em geral, os SGBDs apresentam um conceito, que chamaremos genericamente de
Espaço de Tabela, que representa um agrupamento físico de objetos do banco de dados.
O Espaço de Tabela tem por objetivo agrupar objetos correlatos de maneira a facilitar
tarefas administrativas como manutenção e backup, evitar fragmentações, e melhorar
o desempenho do banco através da redução de contenção18 para recursos de E/S. A
seguir, apontaremos algumas diretrizes a serem seguidas para o planejamento do lay-
out físico do banco de dados. Embora essas diretrizes sejam comuns aos dois tipos de
aplicações: OLTP e DW, no ambiente de Data Warehouse, em função do volume de
dados, elas são fatores determinantes do desempenho de consultas e cruciais para as
atividades de administração.
Como diretrizes para Espaço de Tabelas, podemos apontar:

a) O banco de dados deve possuir Espaços de Tabelas diferentes para:
■ Objetos de dicionário de dados
17
Nesse contexto, contenção é uma espera resultante da concorrência por recursos de Entrada e Saída.
■ Tabelas
■ Índices
Caso não haja mudanças estruturais, os objetos do dicionário de dados são, relativamente,
estáticos, e devem sempre estar disponíveis para o perfeito funcionamento do SGBD.
Por esse motivo, deve-se evitar agrupar objetos pertencentes ao dicionário e objetos
pertinentes às aplicações em um único Espaço de Tabela.
Tabelas e índices são objetos com características físicas diferentes. Índices são objetos
voláteis que têm como principal objetivo prover um caminho de acesso rápido aos dados
contidos em tabelas. Em decorrência de operações de inserção, remoção e alteração, as
estruturas de dados que formam os índices tendem a ficar desordenadas, necessitando de
uma reorganização. Essa atividade de reorganizar as estruturas de dados faz com que
espaços de memória no Espaço de Tabela sejam desocupados e novos espaços sejam
utilizados. Isso acarreta no aparecimento de “buracos” no Espaço de Tabela que degradam
desempenho e minimizam a utilização do espaço livre em disco.
b) Os arquivos relacionados aos Espaços de Tabelas devem ser distribuídos entre
controladoras e dispositivos de discos de modo a evitar contenção de E/S.
O dicionário de dados, as tabelas e seus índices correspondentes são, muitas vezes,

inseridos e lidos simultaneamente. Logo, uma distribuição de Espaços de Tabelas desses
objetos entre diferentes discos contribuirá para redução da concorrência entre recursos
de E/S e, conseqüentemente, melhor desempenho.
Devemos abusar na utilização de espaços de tabela...
No ambiente OLTP existe uma forte tendência por parte dos Administradores de Banco de Dados
em utilizar Espaços de Tabela para agrupar tabelas pertencentes a um mesmo sistema. Embora
essa abordagem alcance bons resultados para o ambiente operacional, ela não pode ser propagada
para o ambiente de DW. Nesse, existe a necessidade real de utilizar Espaços de Tabelas para cada
tabela de Fatos, uma vez que essas estruturas possuem características físicas diferentes mesmo
estando vinculadas a um mesmo Data Mart. Um segundo motivo para criar uma relação de 1
para 1 entre tabela de Fatos e Espaço de Tabela é o volume de dados geralmente ocupado por
essas estruturas. Através desse isolamento, pode-se alcançar melhor desempenho e facilidade em
tarefas administrativas como backup e restauração.
Particionamento
Um Data Warehouse, por definição, representa um banco de dados histórico com grande
volume de dados. Tal característica traz consigo problemas relacionados ao gerenciamento
de estruturas com centenas de gigabytes e até terabytes de dados. Consideremos o seguinte
cenário: uma tabela de fatos com, aproximadamente, 300 Gbytes de dados relativos a
uma década de informações transacionais que são acessadas constantemente como
mecanismo de planejamento estratégico e gerencial.
Como otimizar consultas em estruturas de tal tamanho?

Como reconstruir índices para uma estrutura tão grande em um espaço de tempo aceitável?
Como minimizar o tempo de indisponibilidade devido à necessidade de restaurar backups?
Como gerenciar rotinas de corte para eliminar dados anteriores a determinado período?
Como balancear E/S se uma única estrutura ocupa centenas de Gigabytes?
Para solucionar essas questões, os SGBDs passaram a oferecer mecanismos para o suporte
a grandes estruturas de dados para sistemas de missão crítica e Data Warehouses. O
principal mecanismo oferecido, atualmente, é o Particionamento. Embora os SGBDs
apresentem diferentes implementações, todos compartilham da mesma idéia: 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 contém dados históricos divididos pelo ano em 11 partições.
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: Visões Particionadas e Tabelas e Índices Particionados.
Visões Particionadas
Também conhecido com pseudoparticionamento ou particionamento manual, esse
mecanismo, ainda presente como o único em muitos SGBDs, representou a primeira
solução para o problema de grandes estruturas de dados. Esse tipo de particionamento é
alcançado através de duas atividades. A primeira consiste em dividir uma tabela em
diversas tabelas com estruturas idênticas e, através de restrições, separar os dados
pertinentes a cada uma delas. A segunda atividade é a criação de uma visão de banco de
dados que faça a união dos dados de todas as estruturas idênticas. Uma vez definida a
visão, consultas direcionadas à mesma e que contenham restrições no atributo de divisão,
farão referência, apenas, às estruturas efetivamente necessárias.
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 usuário todo o controle de separação de dados.
Vantagens do Particionamento
O Particionamento de estruturas, sejam elas tabelas ou índices, apresenta as seguintes
vantagens:
■ Redução do tempo de execução de consultas: O Otimizador de consultas pode,
automaticamente, eliminar partições que não atendem ao critério de consulta.
■ Redução do tempo de indisponibilidade em função de tarefas de manutenção: Algumas
tarefas de manutenção como criação e reconstrução de índices, e eliminação de dados
referentes a determinado período são altamente favorecidas pelo Particionamento,
pois partições isoladas de uma tabela podem ser acessadas mesmo que outras partições
estejam indisponíveis.
■ Redução do tempo para execução de backups e restauração: Partições podem ser
armazenadas em áreas de armazenamento individuais (Espaços de Tabela), o que pode
facilitar operações de gerenciamento como backup e restauração.
■ Desempenho de operações de Entrada e Saída: Através do uso de partições é possível

balancear operações de Entrada e Saída através da distribuição de partições entre
dispositivos físicos. Pode-se, por exemplo, distribuir partições mais recentes em
dispositivos mais rápidos e mover partições com dados históricos pouco acessados
para dispositivos mais lentos.
Índices
Índices são estruturas opcionais associadas a tabelas que têm por objetivo aumentar o
desempenho da execução de consultas. Índices para tabelas funcionam de forma
semelhante ao índice desse livro para a busca de informações. Além de auxiliar na busca
de dados, índices são os principais responsáveis pela redução de operações de E/S.
Os dados em um DW são organizados para que possam ser acessados da forma mais
eficiente possível, auxiliando assim o processo de tomada de decisão. Essa organização,
traduzida pelo Star Schema (ver Capítulo 4), precisa ser auxiliada por estruturas como
índices para que seja alcançado um alto grau de desempenho na execução de consultas.
A seguir, serão apresentados os principais tipos de índices utilizados em bancos de dados
voltados para a atividade de suporte à decisão.
Índices de Árvore B
Índices de Árvore B são os índices mais comuns encontrados na maioria dos SGBDs.
Sua estrutura de dados, como o próprio nome traduz, é uma Árvore B, na qual os nós de
nível 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 criação de índices de Árvore B em
um Star Schema, podemos afirmar que:
■ Deve-se criar um índice para os atributos chave das dimensões.
■ 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 dimensões
que sejam utilizados como restrições em consultas e que apresentem alta seletividade.
Índices de Bitmap
Em função da necessidade de consultas cada vez mais eficientes sob bases de dados cada
vez maiores, a indústria de SGBDs desenvolveu um tipo de índice especialmente projetado
para atender a aplicações baseadas em Data Warehouse. Índices de Bitmap (ou mapa de
bits) provêem a mesma funcionalidade que índices convencionais, a exemplo dos índices
baseados em Árvore B, porém utilizam uma representação interna diferente que os torna
mais rápidos e mais eficientes na economia de espaço.
Para explicar e exemplificar o uso de índices de Bitmap, vamos considerar uma tabela de
clientes que contenha os seguintes atributos: Nome, Sexo, Endereço e Região, onde os
possíveis valores para Sexo são “M” e “F”, e os possíveis valores para Região são “Norte”,
“Nordeste” e “Sudeste”. Utilizando os dados da Tabela 8.1, vamos criar índices de Bitmap
para os atributos Sexo e Região.
Tabela 8.1: Tabela de Clientes.
Nome Endereço Sexo Região
Chris Robin Rua José… M Norte
James Stuart Av. João… 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 número total de linhas da tabela (Tabela 8.2).
Tabela 8.2: Representação do índice de Bitmap para o atributo Sexo.
Valor Vetor de Bits
M 10101
F 01010
Em cada vetor da Tabela 8.2, as ocorrências do valor 1 indicam em quais registros o

valor correspondente aparece. Como exemplo, vamos examinar o vetor 10101 relacionado
ao valor M. A primeira ocorrência do valor 1 (da esquerda para a direita) no vetor indica
que o primeiro registro da tabela contém “M” como valor do atributo Sexo. Em
contrapartida, a primeira ocorrência do valor 0 indica que o segundo registro da tabela
contém “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 número de linhas da tabela. Esse mapa de bits pode ser utilizado para
responder, com alto desempenho, consultas com restrições no atributo Sexo.
Vamos criar um outro índice de Bitmap para o atributo Região (Tabela 8.3).
Tabela 8.3: Representação do índice de Bitmap para o atributo Região.
Valor Vetor de Bits
Norte 10010
Nordeste 00101
Sudeste 01000
A partir de agora podemos utilizar a potencialidade dos índices de Bitmap para responder
questões do tipo: Quais os clientes do Sexo Masculino que vivem na região 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 região Nordeste:
00101. O segundo passo é executar a operação 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 números 3 e 5 são os que satisfazem
nossas restrições (Tabela 8.4).
Tabela 8.4: Resultado da consulta utilizando índices de Bitmap.
Nome Endereço Sexo Região
Chris Robin Rua José… M Norte
James Stuart Av. João… F Sudeste
Russel Lamark Rua JK… M Nordeste
Tim Tompson Rua Duque… F Norte
David Av. Sabin... M Nordeste
Uma vez entendido o funcionamento dos índices de Bitmap, podemos apontar suas
principais vantagens:
■ Operações envolvendo comparações, junções e agregações são reduzidas à aritmética
binária com uma melhoria dramática no tempo de processamento.
■ Redução substancial do espaço utilizado comparado a outras técnicas de indexação.
■ Ganho dramático de desempenho mesmo para equipamentos com número relativamente
pequeno de CPUs e pouca quantidade de memória.
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 finalização diária 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 seção, recomendaremos uma série 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 utilitários para leitura de Flat Files: Considere o emprego de utilitários
de carga oferecidos pelos SGBDs. Esses utilitários apresentam excelente desempenho
para a leitura de Flat Files, podendo carregar milhares de registros por segundo.
■ Desabilitar índices: Ao carregar os Flat Files os índices necessários para operações

posteriores de transformação 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, não existe a necessidade de um controle
transacional. Assim, podemos desabilitar mecanismos para recuperação de dados tais
como arquivos de log utilizados para desfazer alterações ocorridas, pois estes
mecanismos retardam o processo de inclusão de dados no DW à medida em que
registram todas as inserções ocorridas.
■ Habilitar diretiva APPEND para inserção de dados em blocos de dados vazios: Alguns
SGBDs possuem uma diretiva de inserção, comumente chamada de APPEND, que faz
com que novos registros sejam inseridos no último bloco físico onde se encontram os
dados da tabela, ou seja, os novos registros serão inseridos no bloco seguinte ao usado
pela última vez. Por exemplo, se uma tabela usa 20 blocos no banco de dados, então
uma inserção que use a diretiva APPEND deverá iniciar a gravação destes novos
registros no 21º bloco. Isto aumenta o desempenho da carga, pois os processos que
controlam a inserção não precisam procurar por espaços vazios nos blocos já utilizados.
Resumo
Embora a maioria das técnicas de projeto físico utilizadas para Sistemas OLTP sirva
para o ambiente de Data Warehouse, elas não são suficientes para solucionar os problemas
inerentes ao volume de dados trabalhado em um Data Warehouse e atender às pressões
por consultas mais rápidas. A combinação desses fatores tem contribuído, cada vez mais,
para o desenvolvimento de novas características nos SGBDs a fim de suportar as
exigências impostas por aplicações baseadas em DW.
Decisões de projeto físico, a exemplo da escolha de índices e estratégias de

particionamento, possuem profundo impacto nos processos de um ambiente de Data
Warehouse. Resumiremos estas decisões a seguir:
■ Blocos de dados: são recomendados tamanhos entre 16 e 64 Kbytes.
■ Tamanho de área livre: pode-se reservar muito pouco espaço ou nenhum para a Área
Livre nos blocos de dados de um banco voltado para Data Warehouse.
■ Espaços de tabelas: o banco de dados deve possuir Espaços de Tabelas diferentes para
objetos de dicionário de dados, tabelas e índices.
■ Particionamento: devemos particionar tabelas e índices para alcançarmos os seguintes
objetivos:
■ Redução do tempo de execução de consultas.
■ Redução do tempo de indisponibilidade em função de tarefas de manutenção.
■ Redução do tempo para execução de backups e restauração.
■ Melhorar desempenho de operações de Entrada e Saída.
■ Uso de índices: Os dados em um DW são organizados para que possam ser acessados
da forma mais eficiente possível, auxiliando assim o processo de tomada de decisão.
Essa organização, traduzida pelo Star Schema, precisa ser auxiliada por estruturas
como índices para que seja alcançado um alto grau de desempenho na execução de
consultas.
■ Carregamento de dados para o DW: uma série de medidas pode ser utilizada para
aumentar o desempenho da carga de dados para uma área de Staging no ambiente de
Data Warehouse. São elas:
■ Emprego de utilitários para leitura de Flat Files.
■ Desabilitar índices de tabelas auxiliares da Staging Area.
■ Desabilitar log.
■ Habilitar diretiva APPEND para inserção de dados em blocos de dados vazios.
Capítulo 9: Data Mining e a Descoberta de Informações Para Alavancagem do Negócio 157
9
C A P Í T U L O
Data Mining e a Descoberta

de Informações Para Alavancagem
do Negócio
Como vimos anteriormente, a recente explosão da informação e a disponibilidade de

meios de armazenamento a um baixo custo tem tornado possível coletar dados
maciçamente durante as últimas décadas.
Ao mesmo tempo, a forma de interação entre as empresas e seus clientes tem mudado de
forma drástica. Os vendedores de hoje encaram uma situação muito complexa, com uma
variedade enorme de produtos e, conseqüentemente, maior concorrência. A continuidade
dos negócios com o cliente não está mais garantida e lealdade é coisa do passado. Os
clientes estão aumentando o seu nível de exigência e querem coisas que vão ao encontro
de suas exatas necessidades.
Como resultado destas profundas mudanças, as empresas têm descoberto que precisam
entender melhor seus clientes, dando respostas às suas vontades e necessidades de forma
ágil, sem esperar que os sinais de insatisfação sejam óbvios para se tomar as ações. Para
ter sucesso, as organizações devem ser proativas e antecipar os desejos dos clientes.
Todo este cenário faz surgir a necessidade de novas estratégias de negócio e os tomadores
de decisão modernos precisam de ferramentas para enfrentar as profundas mudanças.
Uma das vantagens da coleta intensiva de dados é o uso destas informações para ganhar
vantagens competitivas. O objetivo passa a ser, através da análise de dados, guiar o processo
de tomada de decisão.
Técnicas de Mineração de Dados (em inglês, Data Mining) podem ajudar a resolver
temas delicados de interações com clientes. Entretanto, é importante frisar que Data
Mining é somente uma parte de todo o processo de exploração da informação, e precisa-
se trabalhar com outras tecnologias (por exemplo, Data Warehouse e automação de mar-
keting), bem como com as práticas de negócio já estabelecidas.
Mineração de Dados: Alguns Conceitos

Técnicas e ferramentas que ajudam a explorar os dados em busca de informações valiosas
começaram a surgir e visam descobrir tendências ou padrões (“patterns”) – conhecimento
– em dados. Um conhecimento descoberto pode ser utilizado como uma previsão a respeito
de dados futuros, que, dentro de uma margem de erro quantificada, continuariam seguindo
o mesmo padrão. É importante, no entanto, que os padrões descobertos sejam realmente

úteis, não podendo ser nem óbvios e nem desinteressantes.
Dentro deste contexto, surgiu um conjunto de tecnologias conhecido por Mineração de

Dados que consiste basicamente em, utilizando uma das várias técnicas disponíveis,
extrair de grandes bases de dados da organização informações úteis e relevantes para a
tomada de decisão.
Afinal, o que é Data Mining?
Definindo de forma simples, Data Mining automatiza a detecção de padrões relevantes em um

banco de dados. Por exemplo, um padrão poderia indicar que homens casados com crianças têm
duas vezes mais chances de dirigir um carro esporte específico do que homens casados sem
crianças. Para um gerente de marketing de uma indústria automobilística, esse padrão
surpreendente poderia ser bastante valioso.
Mineração de Dados consiste em utilizar técnicas de estatística e de inteligência 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
usuários. Depois disto, analistas de negócio devem avaliar os modelos e validar a
relevância das predições realizadas.
Diferentemente das tradicionais consultas a bancos de dados com SQL1 9, nas quais deve
ser explicitado tudo o que se deseja obter, um algoritmo de mineração de dados é capaz
de descobrir informações “escondidas” do usuário. Neste ponto, podemos voltar ao
clássico exemplo das fraldas e da cerveja (Capítulo 1): a venda associada destes dois
produtos só poderia ser descoberta, sem o auxílio de técnicas de mineração, através de
uma consulta explícita ao banco de dados, na qual deveria ser especificado que o inter-
esse era verificar em quantas transações do supermercado os produtos apareceram jun-
tos. É fácil perceber que isto não seria nada intuitivo, visto que é difícil imaginar que
possa haver alguma associação na venda dos dois itens. Um algoritmo de Mineração de
Dados deve ser capaz por si só de descobrir padrões como este.
19
Structured Query Language - Linguagem de consulta a bancos de dados.
É importante frisar que Mineração de Dados é apenas uma das etapas do chamado Processo
de Descoberta de Conhecimento em Bancos de Dados (KDD – Knowledge Discovery in
Databases), explicado na seção O Processo de Descoberta do Conhecimento.
O Diferencial das Técnicas de Data Mining
O resultado da utilização de Data Mining é diferente de outros processos de negócio baseados

em dados. Na maioria das técnicas de exploração dos dados, os resultados apresentados são
coisas já conhecidas. Por exemplo, um relatório mostrando a diminuição das vendas de certa
linha de produtos em uma região pode ser direto para o usuário porque ele intuitivamente sabe
que esse tipo de informação já existe no banco de dados.
Técnicas de Data Mining, por outro lado, extraem informação útil, valiosa e previamente
desconhecida.
Para entendermos ainda mais a importância das técnicas de mineração, imaginemos um

gerente de marketing de uma empresa de telefonia regional, responsável pelo
gerenciamento dos relacionamentos com os clientes de telefonia celular da empresa.
Uma de suas atuais preocupações é a perda de clientes (conhecida como “churn”). É
preciso encontrar uma maneira de manter o cliente, para não ter que precisar tentar trazê-
lo de volta no futuro, o que pode ser uma tarefa muito mais difícil.
A tradicional abordagem para resolver este problema é escolher alguns clientes e tentar
convencê-los a assinar um plano por mais algum tempo de serviço. Esta tentativa poderia
envolver algum tipo de brinde ou talvez um desconto no plano tarifário. O problema,
entretanto, é descobrir quais clientes deveriam ser incluídos nesta solução. Por exemplo,
um cliente que utiliza as funcionalidades topo de linha dos aparelhos e sempre contrata
serviços 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 técnicas de Mineração de Dados são empregadas
como auxílio a uma das tarefas mais árduas: traçar o perfil dos clientes que devem ser
encaixados em determinadas estratégias.
A seguir, trataremos inicialmente das fases do processo de KDD e ressaltamos como

técnicas de mineração podem ser úteis ao serem utilizadas em conjunto com CRM e
Database Marketing (ver Capítulo 3). Depois disto, serão apresentadas duas das mais
disseminadas técnicas de mineração de dados. O tópico seguinte explica em detalhes um
algoritmo de mineração bastante disseminado. Finalmente são tratadas questões de
integração de Data Mining e Sistemas Gerenciadores de Banco de Dados.
O Processo de Descoberta
do Conhecimento
O processo de descoberta de conhecimento envolve várias fases, mostradas na Figura 9.1.
O objetivo é extrair de grandes bases de dados, sem nenhuma formulação prévia de hipóteses,
informações desconhecidas, válidas e acionáveis, úteis para a tomada de decisão.
De forma breve, o processo envolve três etapas iniciais: seleção, pré-processamento e

transformação, as quais compõem o que é denominado de preparação dos dados. Em
seguida vem a fase de Mineração de Dados, coração do processo e foco principal deste
capítulo. Por fim, o conhecimento gerado deverá ser analisado, o que acontece na etapa
de análise e assimilação dos resultados.
Figura 9.1: Etapas de um processo de KDD.
Preparação dos Dados

Esta fase compreende três etapas menores, explicadas a seguir:
■ Seleção de Dados: nesta etapa deverão ser identificadas as bases de dados a serem
utilizadas para a descoberta de conhecimento, levando-se em consideração os objetivos
do processo. Por exemplo, caso o objetivo seja descobrir associação entre itens vendidos,
a base de dados que armazena as transações do supermercado será a escolhida.
■ Pré-processamento de Dados: como a informação pode vir de várias bases distintas,
alguns problemas de integração devem ser resolvidos, o que será feito nesta etapa.
Exemplificando, suponha que a informação 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á
necessário um tratamento especial nos dados. Outro bom exemplo é o caso em que se
deseja trabalhar com idades dos clientes, mas esta informação está em forma de data
de nascimento, o que obriga a realização de um pré-processamento sobre tais dados.
Desta forma, a etapa resume-se em resolver inconsistências, problemas de integração
e adaptação dos dados ao formato desejado.
■ Transformação de Dados: o objetivo desta etapa é transformar os dados pré-
processados, de modo a torná-los compatíveis com as entradas dos diversos algoritmos
de mineração existentes.
■ Mineração de Dados: Esta fase é o coração do processo e caracteriza-se pela escolha
e aplicação da técnica e do algoritmo de mineração. Entre as principais técnicas podem
ser destacadas: Regras de Associação, Classificação e Agrupamento (“Clustering”),
cada uma podendo envolver um ou mais algoritmos.
■ Análise e Assimilação dos Resultados: Nesta etapa o conhecimento gerado deve ser
analisado de maneira a verificar se é realmente útil à tomada de decisão. Se a resposta
não for satisfatória, então será necessário repetir todo ou parte do processo de KDD.
É importante frisar que o processo é interativo e semi-automático, isto porque é

indispensável a interação com o usuário, que participará desde a definição dos dados a
serem analisados, até a análise do conhecimento gerado, de maneira a verificar se este é
realmente útil e previamente desconhecido. Além 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 através de um algoritmo de mineração.
Data Mining e Customer

Relationship Management (CRM)
Customer Relationship Management (ver Capítulo 3) é um processo que gerencia as
interações entre a empresa e seus clientes. Os usuários primários das aplicações de CRM
são o pessoal de Banco de Dados e de Marketing, que procuram automatizar os processos
de interação com os clientes. É necessário para estas equipes a identificação de segmentos
contendo clientes com alto potencial de lucro. A partir daí, são construídas e executadas
campanhas que impactam favoravelmente o comportamento desses clientes.
Segmentar clientes e traçar seus perfis requer uma quantidade significativa de dados
sobre os mesmos e seus comportamentos de compra. Entretanto, o armazenamento
massivo de dados torna difícil filtrar a base em busca das informações valiosas. Desta
forma, as aplicações de Data Mining têm servido para automatizar os processos de procura
nas montanhas de dados de maneira a encontrar padrões que sejam bons preditores de
comportamentos de compra. Depois disso, providências são tomadas levando em
consideração os segmentos de mercado definidos.
Como o Data Mining

Ajuda o Database Marketing
O Database Marketing (ver Capítulo 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 depósitos e produzir
uma resposta rápida. O sistema deve automaticamente agendar uma mala direta ou promoção
de telemarketing assim que o saldo do cliente exceda uma quantia predeterminada. Baseado
no tamanho do depósito, a promoção engatilhada pode, então, prover um incentivo
apropriado que encoraje o cliente a investir seu dinheiro em outros produtos do banco.
As técnicas de mineração de dados ajudam os usuários de Marketing a focar campanhas

de maneira mais precisa e também a alinhar as necessidades, desejos e atitudes de clientes.
Se a informação necessária existe no banco de dados, o processo de Data Mining pode
modelar virtualmente qualquer atividade do cliente. A chave é encontrar padrões relevantes
para problemas correntes de negócio.
Algumas questões típicas de que as técnicas de Data Mining tratam podem incluir
respostas a difíceis questões, como:
■ Quais clientes são mais prováveis de adquirir um determinado produto?
■ Qual é a probabilidade de um cliente comprar um valor predeterminado de mercadoria
através de um catálogo 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 questões 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 Aplicações Potenciais
Técnicas de Data Mining podem ser utilizadas nas mais diversas áreas. Sem a intenção de
esgotar as possibilidades, mas com intuito de destacar algumas aplicações importantes,
mineração de dados pode ser utilizada em segmentos como:
Vendas e Marketing: ajuda a identificar padrões de comportamento de consumidores; associar

comportamentos a características demográficas; ajuda a definir campanhas de marketing direto e
fidelizar clientes.
Bancos: a técnica ajuda a identificar padrões de fraudes (cartões de crédito); identificar

características de correntistas; minimizar prejuízos através de crédito a clientes.
Médica: identificar comportamento de pacientes, terapias de sucessos para diferentes tratamentos,

fraudes em planos de saúde e planos diferenciados por perfil do paciente.
Principais Técnicas
de Mineração de Dados
Existem vários modelos de descoberta de padrão ou de conhecimento. A escolha de um
modelo – juntamente com um algoritmo que extrai conhecimento segundo o modelo –
depende de um problema particular. Cada um dos modelos apresenta o conhecimento

descoberto em uma forma geralmente de fácil entendimento e análise.
Dois modelos bem disseminados são Classificação e Regras de Associação, explicados

nas seções Classificação e Regras de Associação, respectivamente.
Classificação
O objetivo desta técnica é a organização 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: diagnóstico médico, visando

classificar os pacientes, baseando-se em características e sintomas, e facilitando o
tratamento; avaliação de risco de crédito, tentando descobrir a probabilidade de prejuízos
por classe de clientes.
As abordagens de classificação normalmente usam um conjunto de treinamento em que

todos os objetos estão já associados a determinadas classes. Um algoritmo de classificação
aprende regras de classificação do conjunto de treinamento. Um conjunto de testes analisa
se as classificações pelo algoritmo batem com as classes reais dos objetos, o que é
denominado classificação supervisionada. O modelo aprovado é então usado para
classificar novos objetos.
Um algoritmo de classificação pode apresentar o resultado sob a forma de árvore de

decisão, como parcialmente apresentado na Figura 9.2. Nela, as pessoas são classificadas
em confiáveis ou não confiáveis para a concessão de crédito, baseando-se no grau de
escolaridade e na faixa de renda anual.
A interpretação de um dos galhos é que uma pessoa que possui mestrado e ganha acima
de dez mil reais por ano paga seus empréstimos, sendo, portanto, classificada como uma
pessoa confiável. Já uma pessoa com o título de mestrado e com uma renda anual menor
que 10 mil reais não é confiável para se conceder um empréstimo. Tal conhecimento
extraído da massa de dados de uma empresa permite ao gerente, por exemplo, tomar a
decisão de fazer novos empréstimos com uma maior segurança.
Figura 9.2: Árvore de decisão.
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, é possível que não
existam empréstimos realizados a clientes com tal atributo. Além disso, todas as regras
geradas a partir de uma árvore terão que conter o atributo raiz em seu antecedente. No
exemplo, como o grau de escolaridade é o atributo raiz escolhido, não há como se ter
uma regra do tipo: Se Ra > 50 então confiável.
Existem alguns algoritmos de classificação que, ao invés de montarem uma árvore de

decisão, expressam o conhecimento extraído através de regras do tipo “Se condição então
classe” ou X, Y ⇒ Z, chamadas simplesmente de Regras de Classificação. Cada galho
de uma árvore de classificação representa uma regra. A seguir, são exemplificadas as
mesmas regras da Figura 9.2, sob a forma de regras de classificação:
... Se (Grau de Escolaridade = Mestrado), (Ra <= 10) ⇒ não confiável

Se (Grau de Escolaridade = Mestrado), (10 < Ra <= 50) ⇒ confiável
Se (Grau de Escolaridade = Mestrado), (Ra > 50) ⇒ confiável...
Concluindo, uma regra de classificação terá sempre no seu conseqüente uma resposta ao
fato de as condições satisfazerem ou não a uma determinada classe previamente definida.
Uma outra técnica de Mineração de Dados é o Agrupamento ou “Clustering”. Como a

classificação supervisionada, agrupamento é a organização de uma base de dados em
classes. Entretanto, diferentemente de classificação supervisionada, as classes não são

definidas previamente, cabendo ao algoritmo defini-las dinamicamente, o que podemos
denominar de classificação não supervisionada.
Regras de Associação
Entre os diversos modelos de conhecimento, aqueles que geram regras de associação são
bastante poderosos e flexíveis, além de provavelmente serem os mais usados em problemas
práticos. A técnica tem sido intensamente pesquisada e seu principal objetivo é realizar
associações entre os itens, com o intuito de estabelecer correlações entre eles.
Um bom exemplo é verificar quais produtos costumam ser colocados juntos em um

carrinho de supermercado, e daí surgiu o termo “Análise de Market Basket”. As
cadeias de varejo usam associação para planejar a disposição dos produtos nas
prateleiras das lojas ou em um catálogo, de modo que os itens geralmente adquiridos
na mesma compra sejam vistos próximos entre si ou agrupados em uma promoção.
Aqui podemos recordar mais uma vez o clássico exemplo da rede de supermercados
americana (Capítulo 1). A descoberta de que o aumento do consumo de fraldas
infantis nas tardes de sexta-feira também causava o aumento do consumo de cerveja
não é de modo algum trivial e é inviável de ser descoberta a partir de uma inspeção
manual ao banco de dados. O ramo de livraria também tem utilizado esta técnica
com freqüência para descobrir quais títulos são geralmente adquiridos juntos. A
partir daí, o cliente pode ser sugerido a comprar novos exemplares, promoções podem
ser modeladas, etc.
Formalmente uma regra de associação é definida como:

“Se X então Y” ou “X ➨ Y”, onde X e Y são conjuntos de termos e X ∩ Y = ∅.
Diz-se que X é o antecedente da regra, enquanto Y é o seu conseqüente. Uma regra pode
ter vários itens tanto no antecedente quanto no conseqüente. Um algoritmo baseado em
regras de associação consiste em descobrir regras desse tipo entre os dados preparados
para a mineração. A seguir, um exemplo prático de regra de associação:
{Pão} ➨ {Leite, Manteiga}
A regra pode ser lida da seguinte forma: “Se Pão, então Leite e Manteiga”. Isto indica
que clientes compraram os itens Pão, Leite e Manteiga juntos. Além disso, em muitas
compras onde aparecia o produto Pão, os itens Leite e Manteiga também foram vendidos.
Podemos perceber que uma regra de associação é então uma regra de classificação
generalizada. A generalização consiste no fato de que Y, o conseqüente na regra de
associação, é uma conjunção de termos com quaisquer atributos, enquanto que, nas regras
de classificação, este é só um termo envolvendo unicamente o atributo de classificação.
É importante salientar que um algoritmo de regras de associação pode gerar uma explosão
de regras, uma vez que muitas combinações de itens são possíveis. Para evitá-la, dois
parâmetros são passados para o algoritmo: suporte mínimo e confiança mínima. O suporte
visa calcular com que freqüência os itens que compõem a regra apareceram juntos na
base de transações. Já a confiança tem o objetivo de descobrir a correlação entre o
antecedente e o conseqüente: quanto mais forte a correlação, mais expressiva ou mais
confiável é a regra. As definições de suporte e confiança são mostradas formalmente nas
Figuras 9.3 e 9.4, respectivamente. Em seguida, estes parâmetros são mais bem detalhados.
Para uma base de dados T, o suporte de um conjunto de itens X é o percentual de transações

que verifica X, conforme Figura 9.3:
Figura 9.3: Definição do suporte de uma regra.
A definição formal de confiança é trazida na Figura 9.4, onde X denota o antecedente e

Y o conseqüente da regra:
Figura 9.4: Definição da confiança de uma regra
Para entender como estas medidas funcionam, veja a Tabela 9.1, que representa dados de
uma mercearia para mineração. A primeira coluna indica o código da transação e as demais,
os itens ou produtos de venda. Cada linha representa uma transação feita para um cliente e
é identificada a partir do identificador de transação. Se um cliente comprou um item, o
valor da coluna correspondendo ao item é 1, e caso contrário, 0. Por exemplo, a primeira
transação indica que um cliente comprou leite e manteiga, mas não comprou pão.
Tabela 9.1 – Transações de vendas de uma mercearia.
Transação Leite Manteiga Pão
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:
{pão, leite} ➨ {manteiga} /* Se pão e leite então manteiga */
Pode-se constatar que os itens Pão, Leite e Manteiga foram comprados juntos em 6 das
10 transações da Tabela 9.1. Podemos dizer então que a regra tem suporte (“coverage”)
de 0,60 (6/10) ou 60%. Por outro lado, o antecedente aparece em 8 transações; destas 8,
6 contêm o conseqüente. Desta forma a confiança da regra é de 0,75 (6/8) ou 75%.
Os valores de suporte e conf iança devem ser passados para o algoritmo de

mineração. Desta forma, o usuário poderá aumentar ou diminuir o número de regras
geradas. Sintetizando, o objetivo é procurar regras expressivas, aquelas que
satisfazem as duas condições:
■ é freqüente, ou seja, tem suporte acima de um mínimo considerado aceitável.

■ a correlação entre antecedente e conseqüente, medida pela confiança, é forte ou acima
de um mínimo considerado aceitável.
A representação completa da regra é então:

{pão, leite} ➨ {manteiga} [0,60 0,75]
Que é lida assim: 60% dos clientes compraram pão, leite e manteiga; 75% dos clientes
que compraram pão e leite também compraram manteiga.
Utilizando o exemplo da mercearia, algumas perguntas podem ser respondidas a partir

dessas regras como: Quais regras possuem pão como antecedente? Isso pode ajudar a
entender, por exemplo, que itens poderão ter suas vendas influenciadas caso o
estabelecimento deixe de vender pão. Outra pergunta pode ser: Quais regras possuem
manteiga como conseqüente? Essa informação é uma maneira de descobrir como aumentar
as vendas deste produto através de sua comercialização associada a outros produtos.
Para se ter uma idéia, técnicas de mineração de dados, ainda no contexto da mercearia,
podem levar a conclusões como qual a melhor organização das prateleiras, de maneira
que produtos que geralmente são comprados juntos sejam disponibilizados também jun-
tos para os clientes, estimulando um possível aumento nas vendas.
Voltamos a frisar que, diferentemente das tradicionais consultas a bancos de dados nas quais
o usuário expressa exatamente tudo o que quer consultar e como os resultados devem ser
apresentados (o que aqui chamamos de consulta fechada), um algoritmo de mineração de
dados é capaz de descobrir informações escondidas na massa de dados (consulta aberta).
Exemplificando, para descobrir quantas transações tiveram dois produtos quaisquer associados,
a consulta precisaria ser escrita explicitamente. Com a utilização de um algoritmo de mineração,
o máximo que precisa ser feito é especificar o tipo de técnica que deverá ser utilizada; neste
caso, regras de associação. O algoritmo seria então executado recebendo os valores de suporte
e confiança mínimos e todas as possíveis associações de itens (regras) são geradas
automaticamente, sem necessidade de especificação de nenhuma consulta prévia.
Aqui devemos lembrar que o objetivo dos algoritmos de mineração é descobrir

informações não previstas. É fácil perceber que a venda de pão geralmente está associada
à de leite, por exemplo. Entretanto, muito dificilmente um gerente de um supermercado
iria prever que a venda de fraldas pudesse ter alguma relação com a de cervejas. Assim,
é praticamente impossível descobrir associações realmente relevantes e previamente
desconhecidas entre os itens sem a utilização de um algoritmo de regras de associação.
Muitos algoritmos foram desenvolvidos com o objetivo de descobrir regras de associação

entre itens. Podem ser citados: LargeKItemSets, Apriori, AprioriTid. Desses, o mais
disseminado é o seminal Apriori, pois deu origem a vários outros. O algoritmo e seu
funcionamento são detalhados na seção abaixo.
Geração de Regras de
Associação: O Algoritmo Apriori
O algoritmo Apriori foi introduzido por Agrawal e Srikant. O problema de descobrir
regras de associação pode ser decomposto em dois subproblemas:
■ Encontrar todos os conjuntos ou combinações de itens (itemsets) que têm suporte acima
do suporte mínimo, os quais são chamados de Grandes Conjuntos (Large Itemsets).
■ Usar os grandes conjuntos para gerar as regras com confiança acima do valor mínimo
estabelecido.
A Tabela 9.2 contém algumas notações importantes utilizadas pelos diversos algoritmos
de regras de associação.
Tabela 9.2: Algumas notações usadas no Apriori.
Notação Descrição
k-itemset Um conjunto com k itens
Lk União de grandes conjuntos de tamanho k.

Cada grande conjunto tem dois atributos:
i) conjunto de itens
ii) suporte
Ck União de conjuntos candidatos

(potencialmente grandes) de tamanho k.
Cada conjunto candidato tem dois atributos:
i) conjunto de itens
ii) suporte
O algoritmo aparece na Figura 9.5. Nas próximas três subseções, explicamos em detalhes
seu funcionamento.
Figura 9.5: O algoritmo Apriori
Geração dos Conjuntos

Nesta fase, todas as possíveis combinações de itens serão geradas: são os chamados
Conjuntos Candidatos. Em seguida, aqueles que não atingirem o suporte mínimo são
descartados ou, utilizando a terminologia do algoritmo, podados. A geração dos candidatos
será mostrada nesta seção 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 são 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
mínimo são considerados grandes. Usando aqui um suporte de 0,7, todos os candidatos
seriam considerados grandes. Esta fase está representada na Figura 9.5 através 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 {Pão} inidvidualmente são grandes conjuntos,
então a combinação dos dois forma um conjunto candidato de tamanho 2. Da mesma
forma, os candidatos de tamanho 3 são gerados a partir das combinações de grandes
conjuntos de tamanho 2. Assim, sendo {Leite, Pão} e {Leite, Manteiga} grandes conjuntos,
então {Leite, Manteiga, Pão} formam um conjunto candidato.
Sintetizando, após a geração 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
combinações possíveis 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 são mostrados nas Figuras 9.6(b) e 9.6(c), respectivamente. Percebemos
que todos os candidatos de tamanho 2 obedecem ao suporte mínimo sendo, portanto,
considerados grandes, o que não acontece com o único candidato de tamanho 3.
Figura 9.6: Conjuntos candidatos de um, dois e três elementos.
Essa estratégia de fazer várias passagens pelos dados está representada no algoritmo a
partir do laço 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 laço é
feita a geração 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 passarão
a compor os grandes conjuntos deste mesmo tamanho denominados de Lk.
Cabe ressaltar que a ordem dos itens não faz diferença para o algoritmo. Por exemplo, o conjunto
{Leite, Pão} é idêntico ao {Pão, 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, Pão}.
Fase de Poda
Esta fase irá mostrar quando um conjunto deve ser descartado. Aqui devemos lembrar
que pode existir uma combinação muito grande de itens. Imagine em um supermercado
quantas combinações de 2 ou mais itens podem ser geradas. Desta forma, quanto mais
cedo um candidato que não atinge o suporte mínimo for descartado, melhor para o
desempenho do algoritmo. Assim, grande parte do esforço de otimização dos algoritmos
para geração de regras de associação está concentrado nesta etapa. De uma maneira
geral, a otimização consiste em descartar o quanto antes todos os conjuntos candidatos
que não obedecem ao suporte mínimo. Após esta etapa, a geração das regras torna-se
uma tarefa extremamente simples.
A fase de poda é executada em dois momentos distintos a cada interação do algoritmo. A

primeira poda é feita após a contagem do suporte dos candidatos de tamanho 1, onde são
naturalmente descartados aqueles que não atingem o suporte mínimo.
Alguns candidatos poderão 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} obedeça ao suporte mínimo, os itens {Leite} e {Manteiga}
individualmente também devem satisfazê-lo. Assim, se um candidato tem algum subconjunto
que não é grande terá sua poda antecipada. O passo de poda então remove todos os itemsets
c ∈ Ck que contém algum (k-1)-subconjunto de c que não está em Lk-1. Desta forma, a
segunda parte da poda é executada sempre imediatamente após a geração dos candidatos e
antes da contagem do suporte. Esta poda é executada a partir da geração 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 L2 = {Leite, Manteiga}, {Leite, Pão}, os grandes conjuntos de

tamanho 2. Desta forma, será gerado o candidato C3 = {Leite, Manteiga, Pão}. O passo
de poda irá descartá-lo logo após sua geração, visto que um dos seus subconjuntos, qual
seja, {Manteiga, Pão}, não é 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 transações, verificando a existência ou
não do candidato. Caso exista, seu suporte é incrementado (linhas 4 a 7 do algoritmo
na Figura 9.5).
Geração de Regras
A última parte do algoritmo Apriori é a geração das regras (linha 11, Figura 9.5), partindo
dos grandes conjuntos com seus respectivos suportes já encontrados, não exigindo,
portanto, passagem pelos dados. Aqui, a confiança mínima aceitável passa a ser
considerada. O processo de geração é visto como:
Para todo Large Itemset l, encontre todos os subconjuntos não vazios de l. Para cada
subconjunto a, gerar a regra no formato a ➨ (l - a), se a divisão do suporte(l) pelo
suporte(a) for pelo menos igual à confiança mínima estabelecida (MinConf).
Por exemplo, para o grande conjunto {Leite, Manteiga, Pão}, considerando os

subconjuntos {Leite, Manteiga} e {Pão} com respectivos suportes de 0,7 e 0,9, e
considerando ainda que o suporte de {Leite, Manteiga, Pão} é de 0,6, a confiança da
regra seria de 0,6/0,7 = 0,85. Estabelecendo uma confiança mínima aceitável de 0,8,
somente as regras sombreadas na Tabela 9.3 são geradas.
Tabela 9.3: As regras geradas pelo Apriori
Regra Fator de Confiança
{Leite} ➨ {Manteiga} 0,77

{Manteiga} ➨ {Leite} 0,88
{Leite} ➨ {Pão} 0,77
{Pão} ➨ {Leite} 0,88
{Manteiga} ➨ {Pão} 0,88
{Pão} ➨ {Manteiga} 0,77
{Leite, Manteiga} ➨ {Pão} 0,85
{Pão} ➨ {Leite, Manteiga} 0,66
{Leite, Pão} ➨ {Manteiga} 0,75
{Manteiga} ➨ {Leite, Pão} 0,75
{Manteiga, Pão} ➨ {Leite} 0,85
{Leite} ➨ {Manteiga, Pão} 0,66
A técnica de geração de regras de associação é bem flexível e poderosa, na medida em

que muitas associações entre os itens podem ser descobertas. Uma das grandes vantagens
do algoritmo Apriori é que, através das medidas de suporte e confiança, a quantidade de
regras e a especificidade das mesmas podem aumentar ou diminuir. Dessa forma, podem
ser geradas muitas regras ou o número pode ser filtrado para gerar apenas as mais
relevantes no contexto das transações analisadas.
Entretanto, o número de conjuntos candidatos pode ser enorme, podendo até impedir
a execução do algoritmo e a explosão de regras. Na prática, o custo do algoritmo
depende criticamente da base de dados utilizada e do suporte mínimo especificado.
A confiança tem menos influência, pois, para calculá-la, não é mais necessária a
varredura das transações.
Os esforços de otimização de algoritmos de regras de associação estão praticamente

concentrados na preocupação 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 transação gerada por um cliente que comprou 2 litros de leite e 10 pães é
idêntica à de outro que comprou apenas 1 litro de leite e 3 pães, por exemplo. Algumas
alternativas foram então propostas nas quais a quantificação dos dados é levada em
consideração. Como o próprio 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 também compram de 5 a 10 pães.
As medidas de suporte e confiança continuam sendo importantes no Apriori Quantitativo.

O problema, de uma maneira geral, ainda é encontrar todas as regras que satisfazem ao
suporte e confiança mínimos exigidos.
Como se pode perceber, os passos básicos são semelhantes aos do Apriori tradicional,
mas a informação extra das quantidades adiciona uma nova dimensão nas regras geradas.
O algoritmo é mudado basicamente no passo de poda, onde as informações quantitativas
são levadas em conta, para que o corte seja mais eficiente.
Integração de Mineração
de Dados e SGBDs
As pesquisas iniciais em Data Mining concentraram-se em definir novas operações de
mineração e desenvolver algoritmos para as mesmas, os quais lêem dados a partir de
arquivos isolados não normalizados (“Flat Files”), especialmente preparados com esta
finalidade. A maioria das aplicações foi desenvolvida em sistemas de arquivos com
estruturas de dados e estratégias de gerenciamento de memória especializadas.
Por outro lado, muito investimento em pesquisa e desenvolvimento tem sido feito para o
contínuo aprimoramento dos SGBDs. Entre suas numerosas características importantes,
destacamos: robustez, escalabilidade, controle de acessos concorrentes e otimização de
consultas. Além disso, cada vez mais as empresas armazenam seus dados sob a gerência
de robustos SGBDs. A tecnologia de SGDB então oferece várias funcionalidades que a
tornam valiosa ao implementar aplicações de mineração de dados. Por exemplo, é possível
trabalhar com conjuntos de dados consideravelmente maiores que a memória principal,
uma vez que o SGBD por si só é o responsável por grande parte do manuseio das
informações. Com a maturidade alcançada pelos SGBDs para armazenar, manter e
recuperar informações de grandes bancos de dados de forma eficiente, essas técnicas de
“otimização” poderiam ser incorporadas aos algoritmos de mineração de dados.
Apesar disto, grande parte das aplicações atuais de mineração ainda tem uma fraca conexão
com SGBDs: em grande parte das aplicações, eles são utilizados apenas como repositórios, a
partir dos quais os dados são extraídos e preparados para mineração. Fica claro que SGBDs e
algoritmos de mineração de dados deveriam se complementar, os primeiros tratando da gerência
dos dados a minerar, enquanto os últimos cuidariam da mineração propriamente dita.
Atualmente, esforços estão também se concentrando em integrar mineração de dados e
SGBDs, visando somar as vantagens desses dois mundos, aliando o potencial das técnicas
de mineração às conhecidas vantagens dos SGBDs. O algoritmo de regras de associação
utilizado tem sido o clássico Apriori, já apresentado e discutido.
Muitos fabricantes de SGBD já trazem soluções para utilização de técnicas de mineração
de dados completamente integradas a seus produtos. Outros fornecedores propõem
ferramentas que possam ser integradas a bancos existentes no mercado. Além disso,
aplicações para mineração podem ser implementadas e integradas a SGBDs de várias
maneiras, como mostram as próximas seções deste livro.
Abordagens de Integração
Várias propostas para integração de mineração de dados e SGBDs têm sido estudadas.
Na grande maioria dos trabalhos, a classificação das abordagens divide-se basicamente
em: convencional, fortemente acoplada e caixa preta.
Categoria Convencional – Fracamente Acoplada

Na categoria convencional, também chamada de fracamente acoplada, não existe nenhum
tipo de integração entre o SGBD e a aplicação. A maioria das atividades de mineração de
dados reside fora do controle do SGBD. Este serve, na melhor das hipóteses, como
repositório para armazenamento dos dados.
A implementação pode ocorrer de duas formas: alternativa “loose coupling” e alternativa

“cache mining”.
Na primeira, os dados sob um SGBD são lidos tupla a tupla, através de um cursor SQL20 .
Esta alternativa caracteriza-se pelo desenvolvimento de aplicações que usam a linguagem
SQL e uma linguagem de programação de propósito geral – linguagem hospedeira. A
base de dados nunca é copiada para um sistema de arquivo no disco local. Todo o acesso
é feito através de uma rede, resultando em alguns casos em problemas de desempenho.
O maior atrativo da abordagem é a flexibilidade de programação, visto que o algoritmo

de mineração é implementado completamente no lado aplicação. Além disso, qualquer
aplicação de mineração de dados pode facilmente passar a utilizar dados sob a gerência
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 mineração, já que eles estão em diferentes espaços
de endereçamento. Nenhuma das facilidades para grandes bancos de dados oferecidas
por um SGBD (paralelismo, otimização de consultas, escalabilidade, controle de acesso
concorrente, etc.) é aproveitada, apesar de serem de extrema importância para aplicações
de mineração, 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.
Figura 9.7: Mineração de dados com acoplamento fraco.
A segunda alternativa da categoria convencional é uma variação da primeira, na qual os

dados provenientes de um SGBD são armazenados temporariamente em um arquivo fora
do banco (“Flat File”), especialmente preparado para mineração. Essa estratégia é
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 são descartados
quando a execução é completada.
Comparada com a alternativa anterior, pode significar uma melhora no desempenho,

porém continua sem tirar proveito das facilidades do SGBD, além de requerer espaço
extra de armazenamento. Esta variação da abordagem fracamente acoplada tem como
vantagem aumentar a eficiência de acesso aos dados depois de armazenados no arquivo
auxiliar, porém requer espaço em disco adicional para armazenamento e consumo de
tempo na preparação e busca completa dos dados.
A Figura 9.8 ilustra a alternativa Cache-Mining:
Figura 9.8: Acoplamento fraco: alternativa cache-mining.
Categoria – Fortemente Acoplada

Na categoria fortemente acoplada, parte do algoritmo de mineração pode ser codificado e
processado no núcleo de um SGBD – lado servidor –, através de stored procedures e funções
definidas pelo usuário. Desta forma, as operações de acesso a dados, que consomem mais
tempo são mapeadas para SQL e executadas no lado servidor. A aplicação de mineração de
dados comporta-se então como uma aplicação cliente, ficando com a tarefa de visualizar o
conhecimento minerado no lado servidor. Fica então evidenciado que, desta forma, a aplicação
de mineração como um todo pode se beneficiar de vantagens próprias de um SGBD, como
otimização de consultas e todas as demais vantagens anteriormente mencionadas.
Para uma aplicação fortemente acoplada, o objetivo não é 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 invés de trazer os registros do banco de dados
para o programa de aplicação, insere-se, seletivamente, partes do programa aplicação
que realizam a computação sobre registros recuperados no SGBD, evitando assim a
degradação de performance ocorrida na categoria fracamente acoplada.
Figura 9.9: Arquitetura Fortemente Acoplada
Na Figura 9.9 o algoritmo é mapeado em código SQL e a forma como a consulta é

processada será determinada pelo otimizador de consultas, que escolhe o plano ótimo
dentre os vários planos de execução que possam ser usados para processar a consulta.
Categoria Caixa-Preta
Finalmente, na categoria caixa-preta, aos olhos do usuário o algoritmo de mineração é
completamente encapsulado dentro do SGBD. A aplicação envia uma simples requisição
solicitando a extração de algum conhecimento e recebe o resultado final como resposta.

Note que se trata também de uma integração 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 são explorados.
A desvantagem potencial é que a integração é escrava do particular algoritmo de mineração

implementado e sabe-se que nenhum algoritmo de mineração é 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 características do SGBD, o desenvolvedor de
aplicações 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 começarem a evoluir, este problema
tenderá a ser minimizado.
Resumo
O crescimento da concorrência e a conseqüente mudança do perfil do cliente, que
passa a ser mais exigente, faz surgir a necessidade de novas estratégias de negócio e os
tomadores de decisão modernos precisam de subsídios para encarar as mudanças. Ao
mesmo tempo, existe uma enorme quantidade de informação potencialmente importante
guardada nos bancos de dados, mas que ainda não foi descoberta, ou seja, está escondida
e é raramente tornada explícita.
Técnicas de Mineração de Dados surgem então como auxílio no processo de tomada de

decisão. Algoritmos de mineração de dados extraem, de grandes bases de dados e sem
prévia formulação de hipóteses, tendências, padrões e correlações entre os dados –
conhecimento –, os quais devem ser úteis à tomada de decisão. Sendo assim, a utilização
do processo de mineração de dados é de extrema importância, visto que, através dela,
muitos dados armazenados em poderosos SGBDs podem ser transformados em informações
relevantes que podem ser utilizadas de várias formas no processo de tomada de decisão.
Mineração 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, traçar
estratégias de marketing, entre outros aspectos.
Várias técnicas de mineração de dados podem ser encontradas, dentre as quais se destacam:
Regras de Associação e Classificação. Especificamente falando da geração de regras de
associação, a capacidade de descobrir correlação entre produtos vendidos é
extraordinariamente importante ao processo de tomada de decisão nas empresas de
comércio varejista. Esta técnica é geralmente utilizada para descobrir vendas associadas
de produtos nos mais diversos ramos. Já a classificação procura formar classes a partir
dos dados minerados. Por exemplo, a partir desta técnica é possível saber que clientes
terão mais chances de não pagar um determinado empréstimo no banco.
Uma grande vertente das pesquisas em mineração de dados se preocupa com a

integração entre algoritmos de mineração de dados e SGBDs, somando as vantagens
de cada uma das tecnologias. Até pouco tempo, as bases de dados utilizadas pelos
algoritmos de mineração de dados tinham sido sob a forma de arquivos completamente
desintegrados de SGBDs e preparados especialmente para mineração. Recentemente
já podem ser encontradas ferramentas completamente integradas a SGBDs,
disponibilizadas pelos próprios fabricantes.
Bibliografia 183
B I B L I O G R A F I A
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 Int’l 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 Int’l 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).
Bibliografia 185
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.

Utilização de Técnicas de Data Mining para o Reconhecimento de Caracteres Manuscritos,
In: XIV Simpósio Brasileiro de Banco de Dados, 235-249, Florianópolis, 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, no. 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.
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 (DMDW’2000), 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. Tradução da segunda edição.

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.
Bibliografia 187
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 Séries Temporais como Tipo de Dado Não Convencional, M. L. M. Campos & A.
K. Tanaka, Anais do XIV SBBD, Florianópolis-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, João 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, no 5, February 1998.
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 (IDEAS’99), 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.
STÖHR, T., MÜLLER, 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.
Bibliografia 189
SRIVASTAVA, J., CHEN P. Warehouse Creation: A Potential Roadblock to Data

Warehousing. IEEE Transactions on Knowledge and Data Engineering, vol. 11, no 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, no 3, 2000.
Bibliografia 191
G L O S S Á R I O
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: Orientação 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
Índice Remissivo 193
Í N D I C E R E M I S S I V O
A Classificação, 162, 165

Administração de Dados, 4, 7 Regra de, 166, 167, 168, 182
Administrador de Banco de Dados, 142, 147 Clustering, 162, 166
Administradores, 2, 7, 39, 84, 88, 89, 100, 112, 147 Confiança, 168, 175
AG, 9 CRM, 9, 38, 45, 163
Agregado, 29, 30, 32, 34, 59, 60, 80, 103, 115, Cronograma, 110, 123, 127
137, 138, 153
CWM, 92, 95
Análise de Sistemas, 102, 126, 130
Apriori, 171, 172, 175, 176, 177 D
Arquivo de log, 154, 155 Dados,
Árvore de decisão, 165, 166 Administração de, 4, 7
Banco de, 3, 8, 14, 16, 21, 26, 36, 42, 46, 48,
B 52, 57, 68, 72, 78, 81, 85, 92, 112, 116, 132,
Backup, 78, 80, 114, 125, 146, 155 142, 159, 179
Banco de Dados, 3, 8, 14, 16, 21, 26, 36, 42, Bloco de, 143, 154
46, 48, 52, 57, 68, 72, 78, 81, 85, 92, 112, 116, Dicionário de, 75, 115, 146, 147, 155
132, 142, 159, 179
Mineração de, 8, 10, 42, 93, 158, 164, 166-
Administrador de, 142, 147 170, 177-182
Volume de, 72, 100, 101, 113, 126, 142, 146,
BD, 8 147, 148, 153, 154
BI, 9, 26, 42 Data Mart, 18, 21, 22, 73, 76, 89, 90, 91, 96, 97,
100, 101,102, 112, 123, 126, 127, 132,139, 147
Bloco de Dados, 143, 154
Data Mining, 8, 10, 26, 42, 113, 125, 157, 158,
Business Intelligence (BI), 9, 26
159, 160,161, 163, 164, 165, 167, 169, 171, 173,
175, 177, 179
C Data Warehouse, 9, 15, 16, 17, 18, 19, 21, 22,
Carga, 17, 19, 23, 68, 72, 86, 89, 100, 103, 108, 23, 26, 27, 28, 38, 40, 42, 46, 49, 56, 60, 68, 71,
116, 125, 127, 133, 138, 153 72, 73, 74, 89
Carga de Dados, 103, 125, 153, 155 Data Warehousing, 68, 71, 93, 127
Chave, Database Marketing, 9, 42, 46, 113, 161, 163
Estrangeira, 118 DBA, 142, 145
Primária, 51, 56, 118 Decisão,
Chaves Artificiais, 52, 53, 56, 57, 135, 136 Árvore de, 165, 166
Classes, 71, 73, 80, 86, 131, 165, 166 Ferramentas de apoio à, 7, 9, 25
Suporte à, 5, 6-9, 10, 15, 16, 27, 38, 45, 77, Fato, 28, 50, 118, 136, 137, 147, 150
80, 84-86, 95, 104, 108, 113, 121-126, 138, Fatos,
142, 145, 150
Tabela de, 50-65, 136, 138, 147, 148, 150
DER, 48, 49
Federated Data Warehouse (FDW), 89, 90, 96
Descoberta de Conhecimento, 160, 161, 162
Ferramentas de apoio à decisão, 7, 9, 25
Desempenho, 14, 15, 18, 22, 37, 38, 49, 50, 52,
54, 56, 57, 59, 64, 103, 113, 138, 142, 145 - Fidelização, 40
155, 174, 178-181 Flat Files, 116, 120, 132, 153, 177
Indicadores de, 26, 51, 101, 122 FTP, 118
Dimensão, 29, 30, 31-36, 42, 45, 50-64, 86, 115,
118, 134-138, 145, 150, 176 G–H
Descaracterizada, 55, 56, 59, 64 Gerência de metadados, 67
Tempo, 29, 42, 51, 52, 57, 58, 63, 86 Hierarquia, 32, 58, 137
Documentação, 19, 68, 69, 94, 107, 130, 132,
133, 138, 139 I
Incremental, 123, 127
E Indicadores de Desempenho, 26, 51, 101, 122
EDW, 89, 90, 96 Índices, 81, 122, 138, 144, 147, 150
EIS, 6, 7, 8, 10, 111 Índices de Árvore B, 150
Enterprise Data Warehouse (EDW), 89, 96 Índices de Bitmap, 151
Enterprise Resource Planning (ERP), 21 Índices Particionados, 149
Entrevista, 68, 104 - 110, 126 Informação,
Equipe, 78, 81, 86, 100, 101, 104, 110-112, 125,
Tecnologia da, 10, 26, 40, 96, 104
126, 163
Integração, 3, 15, 19, 21, 42, 46, 68, 74, 77, 84,
ERP, 21, 22, 23
89, 91, 94, 101, 115, 122, 126, 162, 177
Espaço de Tabela, 146, 147
Integraçao Data Mining e SGBD, 177
Esquema de dados, 37, 62-64, 83-88, 92, 116
Interativo, 6, 122, 162
Esquemas-estrela, 37, 49-65, 88
Internet, 41, 81
Estimativa de espaço, 20, 107, 108, 109, 113,
146, 152, 153, 179
K–M
Executivos, 2, 4, 6, 7, 10, 14, 70 KDD, 160
Marketing, 8, 9, 38, 42, 45, 46, 100, 112, 113,
F 158-161, 163
FAD, 9, 14
MDIS, 91
Metamodelo, 82, 92-96 Otimização, 17, 85, 95, 139,141-143, 145, 174,
Metodologia de Desenvolvimento, 4, 7, 86, 96, 176-180
102, 130, 139 Otimizador de Consulta, 149,180
Mineração de Dados, 8, 10, 42, 93, 158, 164,
166-170, 177-182 P
MIS, 5 Particionamento, 117, 131, 138, 142, 148, 149,
154, 155
Modelagem Dimensional, 60
Processo de Descoberta de Conhecimento, 160, 161
Modelo,
Projeto,
Conceitual, 48, 92, 132
Arquitetural, 130-132
Entidade e Relacionamento, 48, 51
conceitual, 48, 80, 82, 83, 92, 96, 132
Físico, 76, 87, 125
físico, 142, 145, 154,
Lógico, 125
físico de dados, 142
Relacional, 49, 92
MOF, 93
Q
MOLAP, 35-38 Qualidade, 2, 6, 15, 40, 41, 84, 85-90, 95, 96,
Multidimensional, 29, 35-38, 49, 80, 91, 93,113 121, 127
N R
Negócio, 2,7,9,16,20,26, 31, 42-44, 48, 60, 68- Redundância, 3, 9, 18, 21, 23, 48, 49, 58, 59,
75,80-82,84-91, 104, 110, 119, 122, 158 64, 70, 90
Normalização, 27, 48, 49, 50, 54, 56, 58, 62, Regra,
64, 65, 70, 118, 177
de associação, 159, 162, 165, 167-182
O de classificação, 162, 165, 166, 167, 168, 182

Objetos, 71, 80-82, 93, 103, 130, 146-149, 155, 165 Relatórios, 4, 7, 18, 22, 26, 27, 50, 54, 68, 78,
ODS, 19, 118-120, 132 88, 105, 107, 111, 112, 138, 139
OIM, 91 Repositório de metadados, 76-87, 95, 96
OLAP, 9,19, 26-32, 35-38, 48, 58, 60, 64, 68, Restauração, 15, 114, 147, 149, 155
70, 75, 86, 92, 112, 127, 138 ROLAP, 37
Multidimensional (MOLAP), 35
Relacional (ROLAP), 37 S
SAD, 7, 8, 11, 102, 103, 125, 126, 142, 143
OLTP, 2, 28, 68, 102, 142, 145-147
Segurança, 3, 28, 41, 81, 82, 94, 111, 114, 123,
Orientação a Objetos, 80, 93, 130
142, 165
SGBD, 3, 4, 9, 38, 82, 108, 112, 114, 115, 117, V

138, 142-154, 177-182 Visões Particionadas, 149
SIG, 5, 6, 10, 14 Volume de dados, 72, 100, 101, 113, 126, 142,
Sistemas, 146, 147, 148, 153, 154
Análise de, 102, 126, 130
de Apoio à Decisão (SADs), 6, 7, 8, 10, 11, X
14, 77, 102, 103, 126, 142, 145, XMI, 81, 92, 93
de Informação, 2, 3, 5, 7, 8,10, 11, 14, 76, XML, 81, 92, 93

88, 90, 92, 101, 104
de Informação Executivos, 6, 7, 10
de Informações 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 à Decisão, 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
Técnicas de Data Mining, 160, 164
Tecnologia da Informação, 10, 26, 40, 96, 104
Transação, 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
www.axcel.com.br

PROJETANDO SISTEMAS DE APOIO À DECISÃO
PROJETANDO SISTEMAS DE APOIO À DECISÃO Methanias Colaço Júnior
Fruto da experiência de vários 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 à decisão. Através de uma linguagem simples e com foco em aspectos essen-
ciais, o leitor adquire um conhecimento sólido sobre Sistemas de Apoio à Decisão (SADs) e passa a conhecer as
características fundamentais de todas as ferramentas envolvidas neste processo. São abordados conceitos sobre PROJETANDO SISTEMAS
ferramentas de Business Intelligence tais como as ferramentas OLAP, EIS, ERP, CRM, Database Marketing e Data
Mining.
Além de preparar conceitualmente o leitor, é apresentada uma metodologia de desenvolvimento e documentação
DE APOIO À DECISÃO
de um projeto de ambiente de suporte à decisão. Muitos dos exemplos apresentados não se prendem aos con-
ceitos básicos, mas agregam conhecimento e criatividade por parte do seu autor e colaboradores, inclusive esten- BASEADOS EM
dendo a UML para documentação de um DW. Há um cuidado especial para não apresentar um Data Warehouse
como a resolução de todos os problemas, mas sim apresentar soluções que podem ser utilizadas por gerentes
de um projeto como este. Gerência de metadados e projeto físico de banco de dados também são abordados e
DATA WAREHOUSE
todos os capítulos do livro são finalizados com um resumo, para fixação e simples revisão do que foi abordado.
O livro beneficia profissionais e estudantes de Informática em matérias como Banco de Dados e Tópicos Espe-
ciais, e é direcionado para estudantes e profissionais de Administração, Marketing, Publicidade, Contabilidade e
Economia, envolvidos profissionalmente com a área gerencial ou academicamente com disciplinas como Tecno-
logia da Informação, Sistemas de Informação, Contabilidade Gerencial, CRM, entre outras.
Os profissionais de Marketing também poderão encontrar neste livro a base para a implantação de aplicações de
Database Marketing.
Methanias Colaço Júnior é M.Sc. em Informática pela Universidade Federal de Campina Grande (UFCG) na

área de Sistemas de Informação e Banco de Dados. Especialista em Ciência da Computação e Tecnologia da
Informação, é membro da equipe de Sistemas de Apoio à Decisão 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 serviços à Secretaria Municipal de Finanças 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é Vinícius Nascimento é graduado em Ciência da Computação pela Univer-

sidade Federal de Sergipe e M.Sc. em Informática pela UFCG na área de Sistemas de
Informação e Banco de Dados. É membro da equipe de Sistemas de Apoio à Decisão
do Banco do Estado de Sergipe e professor da Universidade Federal de Sergipe, além
de ministrar aulas em curso de pós-graduação em Administração de Banco de Dados.
Maria de Fátima Almeida é graduada em Ciência da Computação pela Universi-

dade Federal de Sergipe e M.Sc. em Informática pela UFCG na área de Sistemas de
Informação e Banco de Dados. Membro da equipe de Sistemas de Apoio à Decisão
do Banco do Estado de Sergipe e professora de curso de pós-graduação em Admi-
nistração de Banco de Dados e da Universidade Tiradentes. 297
View publication stats

SistemasApoioDecisao BaseadosDataWarehouse 19735

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SistemasApoioDecisao BaseadosDataWarehouse 19735

Enviado por

Direitos autorais:

Formatos disponíveis

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

PROJETANDO SISTEMAS DE APOIO À DECISÃO BASEADOS EM DATA

Book · September 2018

Methanias Colaço Júnior

Security Analytics View project

The user has requested enhancement of the downloaded file.

BASEADOS EM DATA WAREHOUSE

Methanias Colaço Júnior

André Vinícius Nascimento é graduado em Ciência da Computação pela Univer-

Maria de Fátima Almeida é graduada em Ciência da Computação pela Universi-

REPRODUÇÃO PROIBIDA PELA LEI DO DIREITO AUTORAL.

Copyright © 2004 by Methanias Colaço Júnior

Nenhuma parte desta publicação poderá ser reproduzida

Editora de Produção: Gisella Narcisi

Projetando Sistemas de Apoio a Decisão Baseados em Data Warehouse

Os originais de livros enviados para avaliação pela Editora serão destruídos,

Os conceitos emitidos nesta obra são de inteira responsabilidade do Autor.

Axcel Books do Brasil Editora

“A chave para ter sucesso nos negócios é ter

Em primeiro lugar agradeço a Deus, pelas constantes bênçãos derramadas. Na nossa

Agradecimentos a todos da minha família e em especial: ao meu pai Methanias e à

À Gerente de Marketing Érika Celestino pela contribuição quanto à aplicação prática de

Ao Designer Jonatas Lemos Rodrigues pela arte final das ilustrações.

Aos irmãos em Cristo, que sempre oram pela minha vida.

A todos os amigos e profissionais que contribuíram para realização desta obra.

Methanias Colaço Júnior é M.Sc. em Informática pela Universidade Federal de Campina

André Vinícius Nascimento é graduado em Ciência da Computação pela Universidade

Maria de Fátima Almeida é graduada em Ciência da Computação pela Universidade

Colaboraram em três capítulos deste livro.

A globalização da economia, a mutação dos mercados e o acirramento da concorrência

As informações contidas em um Data Warehouse possuem características específicas que

Infelizmente, a realidade mostra que muitos projetos de Data Warehouse fracassaram

Ao implantar um DW, os administradores esperam alcançar benefícios, tais como:

■ Redução de riscos associados ao negócio, através das facilidades de análise de risco e

Além de preparar conceitualmente o leitor, apresentamos uma metodologia de

O primeiro capítulo do livro introduz o leitor no domínio dos Sistemas de Informação

No Capítulo 2, apresentamos o conceito de Data Warehouse (DW) e o encaixamos no do

O Capítulo 3 descreve as principais ferramentas de apoio à decisão (ou ferramentas de

No Capítulo 4, enfatizamos o esquema de dados utilizado em Data Warehouses

O Capítulo 5 discute e apresenta conclusões de todo o contexto que envolve uma

Os Capítulos 6 e 7 são a espinha dorsal do livro. No Capítulo 6, apresentamos uma

O Capítulo 8 provê o embasamento teórico necessário para a elaboração de um projeto

Com este livro, o leitor alcançará os seguintes objetivos:

Este livro interessa a qualquer pessoa envolvida na produção, implantação, manutenção,

Além de beneficiar profissionais e estudantes de Informática em matérias como Banco

com a área gerencial ou academicamente com disciplinas como Tecnologia da Informação,

Os profissionais de Marketing também poderão encontrar neste livro a base para a

Como Usar Este Livro

Os Capítulos 4, 5, 6 e 7 são importantíssimos para servirem de guia para administradores

Capítulo 2: Sistemas de Apoio à Decisão Baseados em Data Warehouse .................... 13

Capítulo 3: Ferramentas de Apoio à Decisão ................................................................ 25

Capítulo 4: Modelagem de Dados Para Data Warehouses ........................................... 47

Capítulo 5: Gerência de Metadados em um Data Warehouse ..................................... 67

Análise de Impacto ............................................................................................... 84

Capítulo 6: Uma Metodologia para Implementação de um Data Warehouse ............. 99

Capítulo 7: Estendendo a UML Para Documentar um Data Warehouse .................... 129

Capítulo 8: Otimização da Configuração Física de

Capítulo 9: Data Mining e a Descoberta de Informações

Glossário ...................................................................................................................... 191

Índice Remissivo .......................................................................................................... 193

Evolução dos Sistemas de Informação

Para levar as corporações a um lugar de destaque, os administradores precisam ter a capacidade

Foi em 1970 que aconteceu o advento do armazenamento em disco. Diferente do