Professional Documents
Culture Documents
R.A. 0305057
DATA WAREHOUSE
Jaguariúna
2006
Luis Fernando Panegassi
R.A. 0305057
DATA WAREHOUSE
Jaguariúna
2006
Panegassi, Luis Fernando. Data Warehouse. Monografia defendida e aprovada na FAJ em 11
de dezembro de 2006 pela banca examinadora constituída pelos professores:
______________________________________________________________________
Prof. Odair Jacinto da Silva
FAJ – Orientador
______________________________________________________________________
Prof. Silvio Petroli Neto
FAJ – Prof. Convidado
______________________________________________________________________
Livio
FAJ - Convidado
DEDICATÓRIA
"O valor das coisas não está no tempo em que elas duram, mas na intensidade com que
acontecem. Por isso existem momentos inesquecíveis, coisas inexplicáveis e pessoas
incomparáveis".
(Fernando Pessoa)
Lista de Siglas
RESUMO
INTRODUÇÃO........................................................................................................................12
CAP. 1 - EVOLUÇÃO DOS SISTEMAS DE APOIO À DECISÃO ......................................13
1.1 – Histórico ....................................................................................................................13
1.2 – O Ambiente projetado ...............................................................................................14
CAP. 2 – O QUE É DATA WAREHOUSE.............................................................................16
2.1 – Histórico ......................................................................................................................16
2.1.1 – Origem ..................................................................................................................16
2.2 – Definições....................................................................................................................17
2.3 - Características de um Data Warehouse........................................................................17
2.3.1 - Orientado para áreas de interesse ..........................................................................19
2.4 – Integrado......................................................................................................................19
2.5 - Variante no tempo ........................................................................................................19
2.6 - Não volátil ....................................................................................................................20
2.7 – Granularidade ..............................................................................................................20
2.7.1 – Níveis duais de granularidade ..............................................................................21
2.8 – Metadados....................................................................................................................22
CAP. 3 – ARQUITETURA DO DATA WAREHOUSE.........................................................23
3.1 – Arquitetura genérica do Data Warehouse....................................................................23
3.2 – Outras arquiteturas.......................................................................................................25
3.2.1 – Arquitetura de duas camadas................................................................................25
3.2.2 – Arquitetura de três camadas .................................................................................26
CAP. 4 – MODELO DE DADOS DO DATA WAREHOUSE ...............................................28
4.1 - A Questão das Dimensões............................................................................................28
4.2 - Esquemas do tipo Estrela e Floco de Neve ..................................................................29
4.2.1 – Vantagens do modelo estrela................................................................................31
4.2.2 - Bancos de Dados Multidimensionais ....................................................................32
4.3 – Conversão do modelo E-R para o modelo do Data Warehouse ..................................32
4.3.1 - Remoção dos dados puramente operacionais........................................................33
4.3.2 - Adição de um elemento de tempo na estrutura da chave ......................................33
4.3.3 - Introdução de dados derivados..............................................................................34
4.3.4 - Transformação de Relacionamentos entre dados em artefatos dos dados ............34
4.3.5 - Acomodação dos diferentes níveis de granularidade ............................................36
4.3.6 - União dos dados comuns de diferentes tabelas .....................................................36
4.3.7 - Criação de arrays de dados....................................................................................37
4.4 Data Marts ......................................................................................................................38
CAP. 5 – DESENVOLVIMENTO DO DATA WAREHOUSE..............................................39
5.1 - Estratégia Evolucionária ..............................................................................................40
5.2 - Aspectos de Modelagem ..............................................................................................40
5.3 – Técnicas de gerenciamento da quantidade de dados operacionais pesquisados..........41
5.4 – Técnicas para incrementar a performance ...................................................................43
5.5 - Etapas do Desenvolvimento de um Data Warehouse ..................................................46
5.6 – Relacional versus multidimensional............................................................................47
5.6.1 - Um ou mais bancos ...............................................................................................48
CAP. 6 – CARREGANDO O DATA WAREHOUSE ............................................................50
6.1 – Extração .......................................................................................................................50
6.2 – Transformação e filtros................................................................................................51
6.3 - Derivação e Sumarização .............................................................................................52
CAP. 7 – EXTRAINDO INFORMAÇÕES DO DATA WAREHOUSE ................................53
7.1 - Ferramentas OLAP.......................................................................................................53
7.1.1 - MOLAP x ROLAP................................................................................................55
7.2 - Ferramentas Data Mining.............................................................................................57
CONCLUSÃO..........................................................................................................................59
BIBLIOGRAFIA ......................................................................................................................61
INTRODUÇÃO
Hoje em dia uma organização precisa utilizar toda informação disponível para criar e
manter vantagem competitiva. Sai na frente à organização que consegue tomar decisões
corretas e rápidas.
Com esta importante tarefa nas mãos, profissionais tomadores de decisão tais como
executivos, gerentes e analistas, exigem dos sistemas de suporte à decisão DSS (Decision
Support Systems) mais recursos para análise, front-ends que suportem consultas ad hoc,
interfaces gráficas apropriadas, etc.
A idéia de Data Warehouse é integrar os dados internos e externos de uma
organização em uma estrutura única permitindo uma melhor utilização dos dados pelos
analistas, gerentes e executivos.
Uma vez obtida a integração, sistemas como OLAP (On-Line Analytical Processing) e
Data Mining fornecem mecanismos sofisticados para análise dos dados.
Estudar e conhecer a tecnologia de Data Warehouse pode ajudar os empresários a
descobrir novas formas de competir em uma economia globalizada, trazendo melhores
produtos ou serviços para o mercado, mais rápido do que os concorrentes, sem aumentar o
custo do produto ou do serviço. Não existem ainda metodologias formais para implementação
de um Data Warehouse, ela deve ser adaptada às características e às expectativas de cada
empresa, mas o principal objetivo em todas elas é o de descobrir maneiras diferentes de atuar
no mercado e quais as mudanças internas que devem ocorrer para atender as novas realidades.
Este trabalho tem como objetivo fazer um estudo dos principais conceitos necessários
para o desenvolvimento de um ambiente de Data Warehouse. No capítulo I é apresentada a
evolução dos sistemas de apoio à decisão e o motivo do surgimento da necessidade do Data
Warehouse. No capítulo II iniciam-se os conceitos sobre o Data Warehouse, mostrando suas
características básicas. O capítulo III mostra as arquiteturas disponíveis para construção de
Data Warehouses, e no capítulo IV os modelos de dados. O capítulo V mostra alguns detalhes
do desenvolvimento propriamente dito do Data Warehouse. O capítulo VI mostra as técnicas
para extrair as informações dos sistemas existentes e transforma-las adequadamente para o
Data Warehouse. E finalmente no capítulo VII são apresentadas as técnicas para extração e
analise dos dados de um Data Warehouse que são: OLAP e Data Mining.
CAP. 1 - EVOLUÇÃO DOS SISTEMAS DE APOIO À DECISÃO
1.1 – Histórico
A evolução dos sistemas de apoio à decisão pode ser dividida em cinco fases entre
1960 e 1980. No início da década de 1960 o mundo da computação consistia na criação de
aplicações individuais que eram executadas sobre arquivos mestres, caracterizadas por
programas e relatórios.
Aproximadamente em 1965 o crescimento dos arquivos mestres e das fitas magnéticas
explodiu, surgindo problemas como: a complexidade de manutenção dos programas; a
complexidade do desenvolvimento de novos programas; a quantidade de hardware para
manter todos os arquivos mestres e a necessidade de sincronizarem dados a serem atualizados.
Por volta de 1970, surgiu a tecnologia DASD (Direct Access Storage Device),
substituindo as fitas magnéticas pelo armazenamento em disco. Com o DASD surgiu um novo
tipo de software conhecido como SGBD (Sistema de Gerenciamento de Banco de Dados), que
tinha o objetivo de tornar o armazenamento e o acesso a dados no DASD mais fáceis para o
programador. E com o SGBD surgiu a idéia de um “banco de dados” que foi definido como:
uma única fonte de dados para todo o processamento.
Aproximadamente em 1975 surgiu o processamento de transações on-line. Com o
processamento de transações on-line de alta performance, o computador pôde ser usado para
tarefas que antes não eram viáveis como controlar sistemas de reservas, sistemas de caixas
bancários, sistemas de controle de produção e outros.
Até o início da década de 1980, novas tecnologias, como os PCs (Personal
Communications Services) e as L4Gs (Linguagens de Quarta Geração), começaram a
aparecer. O usuário final passou a controlar diretamente os sistemas e os dados, descobrindo
que era possível utilizar os dados para outros objetivos além de atender ao processamento de
transações on-line de alta performance. Foi nesse período também que se tornou viável a
construção dos MIS (Management Information Systems), hoje conhecidos como SAD
(Sistemas de Apoio à Decisão) eles consistiam em processamento utilizado para direcionar
decisões gerenciais [INM97].
1.2 – O Ambiente projetado
2.1 – Histórico
2.1.1 – Origem
Segundo Haisten (1999), a origem do Data Warehouse vem dos estudos do MIT
(Massachusetts Institute of Technology) nos anos 70 que focavam o desenvolvimento de uma
arquitetura técnica mais eficiente para sistemas de informações. Pela primeira vez foi feita
uma distinção entre sistemas operacionais e aplicações analíticas e surgiu o princípio de
separar esse dois tipos de processamentos em projetos e armazéns de dados diferentes.
Para Ballard & Herreman (1998) e Teresko (1999), o conceito de Data Warehouse
surgiu no inicio dos anos 80 quando os sistemas gerenciais de banco de dados (SGBD)
emergiram como produtos comerciais com facilidades para a computação de apoio a decisão
(SAD). Teresko (1999) comenta que Bill Inmon, observou que estes repositórios de
informações poderiam ser organizados em um bem corporativo que ele chamou de Data
Warehouse e por causa disso Inmon é considerado o “pai do Data Warehouse”. No inicio, o
Data Warehouse consistia de instantâneos, ou subconjuntos dos dados operacionais que eram
carregados em banco de dados de apoio a decisão em períodos regulares que costumavam ser
semanais ou mensais (Ballard & Herreman, 1998).
2.2 – Definições
2.4 – Integrado
Refere-se à consistência de nomes, das unidades das variáveis, etc., no sentido de que
os dados foram transformados até um estado uniforme. Por exemplo, considere-se sexo como
um elemento de dado. Uma aplicação pode codificar sexo como M/F, outra como 1/0 e uma
terceira como H/M.
Conforme os dados são trazidos para o Data Warehouse, eles são convertidos para um
estado uniforme, ou seja, sexo é codificado apenas de uma forma. Da mesma maneira, se um
elemento de dado é medido em centímetros em uma aplicação, em polegadas em outra, ele
será convertido para uma representação única ao ser colocado no Data Warehouse.
Significa que o Data Warehouse permite apenas a carga inicial dos dados e consultas a
estes dados. Após serem integrados e transformados, os dados são carregados em bloco para o
Data Warehouse, para que estejam disponíveis aos usuários para acesso. No ambiente
operacional, ao contrário, os dados são, em geral, atualizados registro a registro, em múltiplas
transações. Esta volatilidade requer um trabalho considerável para assegurar integridade e
consistência através de atividades de rollback, recuperação de falhas, commits e bloqueios.
Um Data Warehouse não requer este grau de controle típico dos sistemas orientados a
transações.
2.7 – Granularidade
Diário Mensal
2.8 – Metadados
Para ser útil o Data Warehouse deve ser capaz de responder a consultas avançadas de
maneira rápida, sem deixar de mostrar detalhes relevantes à resposta. Para isso ele deve
possuir uma arquitetura que lhe permita coletar, manipular e apresentar os dados de forma
eficiente e rápida. Mas construir um Data Warehouse eficiente, que servirá de suporte a
decisões para a empresa, exige mais do que simplesmente descarregar ou copiar os dados dos
sistemas atuais para um banco de dados maior. Deve-se considerar que os dados provenientes
de vários sistemas podem conter redundâncias e diferenças, então antes de passá-los para o
Data Warehouse é necessário aplicar filtros sobre eles.
O estudo de uma arquitetura permite compreender como o Data Warehouse faz para
armazenar, integrar, comunicar, processar e apresentar os dados que os usuários utilizarão em
suas decisões. Um Data Warehouse pode variar sua arquitetura conforme o tipo de assunto
abordado, pois as necessidades também variam de empresa para empresa. É possível definir
uma arquitetura genérica onde praticamente todas as camadas necessárias são apresentadas,
conforme a arquitetura genérica vista a seguir, ou arquiteturas que utilizam somente algumas
das camadas definidas, como as arquiteturas em duas e três camadas.
A arquitetura ilustrada na Figura 4 pode ser usada para construir um Data Warehouse
em duas camadas que consiste de componentes dos clientes (front end) e componentes do
servidor (back end). Esta arquitetura é atrativa porque ela utiliza os sistemas existentes bem
como os servidores de bancos de dados existentes e requer um investimento mínimo em
hardware e software. Entretanto, a arquitetura em duas camadas não é escalonável e não
suporta um grande número de usuários simultaneamente. Isto estimula o desenvolvimento de
estações clientes muito pesadas, pois muito processamento é alocado para processar nestas
estações [DAL99].
É importante reconhecer que não existe uma arquitetura "correta" para Data
Warehouse. Para algumas organizações pode ser atrativo utilizar a arquitetura em duas
camadas, por que ela minimiza o custo e a complexidade de construção do Data Warehouse.
Para outras que requerem grande performance e escalabilidade, a arquitetura em três camadas
pode ser mais apropriada. No planejamento do Data Warehouse, as organizações devem
examinar as alternativas disponíveis de arquiteturas e selecionar aquela que satisfaça os seu
requisitos estratégicos e organizacionais [DAL99].
CAP. 4 – MODELO DE DADOS DO DATA WAREHOUSE
Obter respostas a questões típicas de análise dos negócios de uma empresa geralmente
requer a visualização dos dados segundo diferentes perspectivas. Como exemplo, imagine-se
uma agência de automóveis que esteja querendo melhorar o desempenho de seu negócio, Para
isso, necessita examinar os dados sobre as vendas disponíveis na empresa. Uma avaliação
deste tipo requer uma visão histórica do volume de vendas sob múltiplas perspectivas, como
por exemplo: volume de vendas por modelo, volume de vendas por cor, volume de vendas por
fabricante, volume de vendas por período de tempo. Uma análise do volume de vendas
utilizando uma ou mais destas perspectivas, permitiria responder questões do tipo: Qual a
tendência em termos de volume de vendas para o mês de dezembro para modelos Volvo
Sedan preto?
A capacidade de responder a este tipo de questão em tempo hábil é o que permite aos gerentes
e altos executivos das empresas formular estratégias efetivas, identificar tendências e
melhorar sua habilidade de tomar decisões de negócio. O ambiente tradicional de bancos de
dados relacional certamente pode atender a este tipo de consulta. No entanto, usuários finais
que necessitam de consultas deste tipo via acesso interativo aos bancos de dados, mostram-se
seguidamente frustrados por tempos de resposta ruins e pela falta de flexibilidade oferecida
por ferramentas de consulta baseadas no SQL (Structured Query Language). Daí a
necessidade de utilizar abordagens específicas para atender a estas consultas.
Para compreender melhor os conceitos envolvidos, examinemos em maior detalhe o
exemplo acima.
Chamaremos de dimensões as diferentes perspectivas envolvidas, no caso, modelo,
loja, fabricante, mês. Estas “dimensões” usualmente correspondem a campos não numéricos
em um banco de dados.
Consideremos também um conjunto de “medidas”, tal como vendas ou despesas com
promoção.
Estas medidas correspondem geralmente a campos numéricos em um banco de dados.
A seguir, avaliam-se agregações destas medidas segundo às diversas dimensões e as
armazenamos para acesso futuro. Por exemplo, calcula-se a média de todas as vendas por
todos os meses por loja. A forma como estas agregações são armazenadas pode ser vista em
termos de dimensões e coordenadas, dando origem ao termo multidimensional.
Intuitivamente, cada eixo no espaço multidimensional é um campo/coluna de uma
tabela relacional e cada ponto um valor correspondente à interseção das colunas. Assim, o
valor para o campo vendas, correspondente a mês igual a maio e loja igual a Iguatemi é um
ponto com coordenada [maio, Iguatemi]. Neste caso, mês e loja são duas dimensões e vendas
é uma medida.
Teoricamente, quaisquer dados podem ser considerados multidimensionais.
Entretanto, o termo normalmente se refere a dados representando objetos ou eventos que
podem ser descritos, e, portanto, classificados por dois ou mais de seus atributos.
Estruturas relacionais podem ser usadas para a representação e o armazenamento de
dados multidimensionais. Neste caso, as abordagens encontradas incluem desde a adoção de
formas específicas de modelagem (os chamados esquemas estrela e floco de neve) até
mecanismos sofisticados de indexação.
Para tal, W. H. Inmon fornece então alguns passos que podem ser seguidos, não se
esquecendo de que o fundamental é que as decisões de transformação devem ser tomadas
levando-se em consideração os requisitos específicos da empresa. Os passos básicos são:
4.3.1 - Remoção dos dados puramente operacionais
A primeira ação consiste em remover os dados que são usados apenas no ambiente
operacional, como vemos no exemplo da Figura 10. Neste, atributos tais como mensagem,
descrição e status são retirados, pois é muito pouco provável que estes sejam utilizados no
processo de tomada de decisão.
Neste momento, pode ser que se pense em manter todos os atributos, pois talvez algum
destes seja necessário para alguma decisão específica. Entretanto, deve-se levar em conta o
custo para gerenciar grandes volumes de dados [DAL99].
Da mesma forma que o Data Warehouse, o Data Mart ainda não possui uma definição
universalmente aceita e também esta em fase de aperfeiçoamento. Os Data Marts são
subconjuntos de dados, dentro de um Data Warehouse, projetados para dar suporte a negócios
de unidade organizacionais especificas (NIMER, 1998).
Segundo o autor, os Data Marts são muito interessantes para resolver certos
problemas, mas não são necessariamente substitutos de um projeto de Data Warehouse. Um
Data Mart não deve ser um pequeno Data Warehouse, com a finalidade de ser rápido ou
possuir dados ainda não suportados para o Data Warehouse (KIMBALL, 1997).
Os projetos de Data Marts se justificam em poucos casos, basicamente naqueles onde
a alta gerência ainda não esta convencida quanto a viabilidade e vantagens que a tecnologia
do Data Warehouse pode prover as organizações. Neste caso, os Data Marts são viáveis, por
apresentarem resultados mais rápidos, demoram entre 4 a 12 meses para serem
implementados e, em conseqüência, começam a dar resultados mais rápidos. Os Data
Warehouses têm prazos que variam entre 1 a 5 anos para implementação completa.
CAP. 5 – DESENVOLVIMENTO DO DATA WAREHOUSE
A primeira técnica consiste em pesquisar dados que apresentem marcas de tempo. Para
isso é necessário que as aplicações registrem o momento da última alteração ou atualização
em um registro para que ao ser executada a varredura para o Data Warehouse só sejam
examinados os registros que tenham a data de atualização igual ou maior do que a data da
última pesquisa.
A segunda técnica utiliza um arquivo de registros de alterações efetuadas. Este
arquivo, também chamado arquivo “delta”. É criado por uma aplicação e contém apenas as
alterações efetuadas por esta nos dados operacionais. Quando é possível contar com um
arquivo delta o processo de varredura se torna muito eficiente uma vez que os dados que não
sofreram alterações não serão acessados. O problema é que poucas aplicações geram arquivos
delta.
A terceira técnica consiste em varrer um arquivo de auditoria ou de log. Basicamente o
arquivo de log possui os mesmos dados de um arquivo delta, todavia, há algumas diferenças
significativas. Uma delas é que por ser o arquivo utilizado para a recuperação dos dados do
banco de dados operacional em uma eventual falha não é interessante que se utilize este
arquivo com outros propósitos. Outra diferença é que os arquivos de log normalmente
possuem uma estrutura interna voltada aos objetivos de um sistema e não estão
completamente preparados para a recuperação de dados por um Data Warehouse.
A quarta técnica empregada no gerenciamento da quantidade de dados pesquisados
durante a extração para o Data Warehouse consiste em modificar o código da aplicação
operacional. Essa pode ser a pior escolha, sobretudo quando o código da aplicação é antigo ou
complexo.
A última opção consiste em moldar um arquivo de imagem "anterior" e "posterior".
Segundo esta opção, uma cópia do banco de dados é tirada no momento da extração e quando
for realizada outra extração, outra cópia será tirada. As duas cópias serão comparadas
serialmente entre si para que seja detectada a atividade transcorrida neste período e então
resgatadas às diferenças entre as duas copias.
Esse método é pesado, complexo e demanda uma quantidade excessiva de recursos.
O grande desafio de um sistema de apoio a decisão é que ele possua uma interface
amigável e tempo de resposta satisfatório. Existem algumas técnicas que podem ser aplicadas
no desenvolvimento de um Data Warehouse para incrementar sua performance. Essas
tecnologias podem ser divididas em duas áreas: aquelas que propõem soluções baseadas em
hardware e outras baseadas em software.
Algumas destas técnicas baseadas em software são amplamente utilizadas no ambiente
operacional e outras são específicas do ambiente de Data Warehouse, algumas técnicas são
citadas a seguir, conforme [DAL99] e [PER99].
Uma proposta ao nível de hardware seria dividir o trabalho entre vários processadores.
Porém, o sistema gerenciador de banco de dados deve ser capaz de dividir seu processamento
entre esses processadores. Com o processamento paralelo, a percepção de melhora no
desempenho é imediata, mas a tendência, ao longo do tempo, é voltarmos ao mesmo ponto,
devido ao crescimento constante do Data Warehouse, atrelado às grandes mudanças que
ocorrem freqüentemente no mundo dos negócios.
A distribuição do Data Warehouse, por vezes, é similar à abordagem do
processamento paralelo: dividir a base de dados em subconjuntos de dados e coloca-los em
unidades de processamento separadas. A análise a respeito desse conceito vem novamente ao
encontro de mesma atribuída ao processamento paralelo: dividir o trabalho. Portanto,
podemos chegar à mesma conclusão, em termos de desvantagem, apresentada no
processamento paralelo, ou seja, à medida que o número de dados aumentar, teremos sempre
de buscar maneiras de subdividir o conjunto de dados.
Data marts são outra forma de distribuir os dados contidos no Data Warehouse. Os
data marts, geralmente, contêm dados específicos de uma determinada área ou departamento.
Dessa forma, podemos dizer que os data marts são “mini” Data Warehouses, armazenados
provavelmente em plataformas diferentes. O processo de particionamento melhora o
desempenho no resgate de informações, fazendo uso da segmentação dos dados em áreas
lógicas diferentes.
Recursos sofisticados de indexação são a maneira mais eficiente de redução de I/O de
disco, necessária para resgatar um subconjunto de dados. Com técnicas avançadas de
indexação, a seleção de registros por qualquer critério é executada usando-se poucas leituras
do disco. Dessa forma, obtemos, em segundos, seleções complexas em enormes bases de
dados. Existem várias formas de indexação. Há índices nativos da estrutura de banco de dados
relacionais: primários, B-tree (árvore B) e hash/hashing. Há também índices especializados,
independentes da estrutura dos bancos de dados relacionais: invertidos, bitmap, combinados,
R-tree (árvores R) e alguns outros específicos para determinadas aplicações.
Uma técnica relativa a estrutura do Data Warehouse que pode ser utilizada é a
intercalação de tabelas onde o projetista deve procurar intercalar as tabelas afins em um
mesmo local físico, diminuindo assim a quantidade de E/S (entradas/saídas), tanto em termos
de acesso aos dados, como em termos de acessos aos índices para a localização dos dados. A
melhor estratégia de intercalação de tabelas deve ser defina com base nos tipos de dados e
possíveis consultas que podem ser realizadas.
Outra técnica importante aplicada especialmente no ambiente de Data Warehouse
consiste na introdução intencional de dados redundantes. A Figura 19 mostra um exemplo no
qual a introdução deliberada de dados redundantes proporciona um excelente retorno. Na
parte superior da Figura 19 o campo – descrição – está normalizado e não apresenta
redundância. Dessa maneira todos os processos que precisam ver a descrição precisam acessar
a tabela básica. Na parte inferior da Figura 19 o campo – descrição – foi intencionalmente
colocado nas diversas tabelas em que ele precisa ser usado. O problema da replicação de
dados é somente o aumento do volume do Data Warehouse, já que praticamente não existe a
preocupação com atualizações neste ambiente.
Figura 19 – Introdução intencional de dados redundantes.
A terceira técnica que pode ser utilizada para aumentar a velocidade de acesso aos
dados é chamada de "separação de dados" que consiste em transformar uma tabela
normalizada e que apresente probabilidades de acesso muito diferentes em duas tabelas
separadas.
Para a construção de um Data Warehouse pode ser usada também uma técnica
chamada de “índice criativo”. Um índice criativo é gerado quando os dados passam do
ambiente operacional para o ambiente de Data Warehouse. O índice criativo gera um perfil de
dados de interesse do usuário final, como informações sobre os produtos mais vendidos,
clientes inativos e outras informações que possam antecipar os interesses da gerencia, como
esta antecipação nem sempre é possível é necessário avaliar com cautela sobre quais os dados
em que será aplicada esta técnica.
Por último deve-se esclarecer que a tentativa de reproduzir a integridade referencial no
Data Warehouse constitui uma abordagem incorreta pois os dados em um Data Warehouse
não são atualizados e representam informações ao longo do tempo, com isso os
relacionamentos não permanecem iguais impossibilitando a criação de relacionamentos.
5.5 - Etapas do Desenvolvimento de um Data Warehouse
6.1 – Extração
Uma vez que os dados são extraídos e colocados na área de trabalho temporária, estes
devem passar por uma série de tratamentos. O primeiro destes tratamentos refere-se a limpeza
ou filtragem dos dados onde o objetivo é garantir a integridade dos dados através de
programas ou rotinas especiais que tentam identificar anomalias e resolvê-las, deixando os
dados em um estado consistente antes de serem instalados no Data Warehouse. A correção de
erros de digitação, a descoberta de violações de integridade, a substituição de caracteres
desconhecidos, a padronização de abreviações, podem ser exemplos de limpeza de dados.
O segundo passo é colocar os dados em uma forma homogênea aplicando uma
metodologia de comparação de representações, que inclua os critérios a serem utilizados na
identificação de semelhanças e conflitos de modelagem. Conflitos de modelagem podem ser
divididos em: semânticos e estruturais. Conflitos semânticos são todos aqueles envolvendo o
nome ou palavra associado às estruturas de modelagem, por exemplo, mesmo nome para
diferentes entidades ou diferentes nomes para a mesma entidade. Conflitos estruturais
englobam os conflitos relativos às estruturas de modelagem escolhidas, tanto no nível de
estrutura propriamente dito como no nível de domínios. Os principais tipos de conflitos
estruturais são os conflitos de domínio de atributo que se caracterizam pelo uso de diferentes
tipos de dados para os mesmos campos. Conflitos típicos de domínio de atributo são:
• Diferenças de unidades: quando as unidades utilizadas diferem, embora forneçam a
mesma informação (como distância em metros ou quilômetros);
• Diferenças de precisão: quando a precisão escolhida varia de um ambiente para outro
(como quando o custo do produto é armazenado com duas posições ou com seis
posições decimais);
• Diferenças em códigos ou expressões: quando o código utilizado difere um do outro
(como no caso de sexo representado por M ou F e por 1 e 2);
• Diferenças de granularidade: quando os critérios associados a uma informação,
embora utilizando uma mesma unidade, são distintos (como quando horas trabalhadas)
correspondem às horas trabalhadas na semana ou às horas trabalhadas no mês;
• Diferenças de abstração: quando a forma de estruturar uma mesma informação segue
critérios diferentes (como com endereço armazenado em um atributo único, ou
subdividido em rua e complemento).
Depois de identificados os conflitos de modelagem, deve-se criar as regras de
mapeamento de representações equivalentes e de conversão para os padrões estabelecidos
pelo Data Warehouse [DAL99].
Diferentes alternativas também existem para prover suporte a dados. Uma abordagem
é derivar os dados durante o processo de carga e armazená-los no ambiente relacional
corporativo. Uma alternativa é fazer a derivação quando o servidor de replicação distribui os
dados para os Data Warehouses. Ou então, derivar os dados "on-the-fly" quando o usuário
submeter uma consulta ou lançar uma simulação.
CAP. 7 – EXTRAINDO INFORMAÇÕES DO DATA WAREHOUSE
Nos primórdios do Data Warehouse, Data Mining era visto como um subconjunto das
atividades associadas com o Data Warehouse. Mas atualmente os caminhos do Data
Warehouse e do Data Mining estão divergindo. Enquanto o warehouse pode ser uma boa
fonte de dados para minerar, o Data Mining foi reconhecido como uma tarefa genuína, e não
mais como uma colônia do warehouse [PAR99].
Apesar de o termo Data Mining ter se tornado bastante popular nos últimos anos,
existe ainda certa confusão quanto à sua definição. Data Mining (ou mineração de dados) é o
processo de extrair informação válida, previamente desconhecida e de máxima abrangência a
partir de grandes bases de dados, usando-as para efetuar decisões cruciais. Data Mining vai
muito além da simples consulta a uma banco de dados, no sentido de que permite aos usuários
explorar e inferir informação útil a partir dos dados, descobrindo relacionamentos escondidos
no banco de dados. Pode ser considerada uma forma de descobrimento de conhecimento em
bancos de dados KDD (Knowledge Discovery in Databases), área de pesquisa de bastante
evidência no momento, envolvendo Inteligência Artificial e Banco de Dados.
Um ambiente de apoio à tomada de decisões, integrando técnicas de Data Mining
sobre um ambiente de Data Warehousing, possibilita um grande número de aplicações, que já
vêm sendo implementadas em diversos segmentos de negócios, como manufatura, automação
de pedido de remessas, varejo, gerenciamento de inventários, financeiro, análise de risco,
transporte, gerenciamento de frotas, telecomunicação, análise de chamadas, saúde, analise de
resultados, markenting, estabelecimento do perfil dos consumidores, seguros, detecção de
fraude, dentre outros [PIN99].
Data Mining pode ser utilizado com os seguintes objetivos:
• Explanatório: explicar algum evento ou medida observada, tal como porque a
venda de sorvetes caiu no Rio de Janeiro;
• Confirmatório: confirmar uma hipótese. Uma companhia de seguros , por
exemplo, pode querer examinar os registros de seus clientes para determinar se
famílias de duas rendas tem mais probabilidade de adquirir um plano de saúde
do que famílias de uma renda;
• Exploratório: analisar os dados buscando relacionamentos novos e não
previstos. Uma companhia de cartão de crédito pode analisar seus registros
históricos para determinar que fatores estejam associados a pessoas que
representam risco para créditos.
Quando determinados padrões de comportamento, como associação de produtos
durante um processo de compras, por exemplo, começam a se repetir com freqüência, as
ferramentas Data Mining indicam a presença de oportunidades e "insights" em relação àquele
público consumidor. O diferencial do Data Mining está no fato de que as descobertas de
padrões de consumo se dão por uma lógica de algoritmos com base em uma rede neural de
raciocínios. São ferramentas de descobertas matemáticas feitas sobre os registros corporativos
já processados contra descobertas empíricas [POL99].
CONCLUSÃO
[BIS99] BISPO, Carlos Alberto F. & CAZARINI, Edson Walmir. Análises sofisticadas com o
On-Line Analytical Processing. Developer’s Magazine, São Paulo, n.32, p.28-31, abril de
1999.
[INM97] INMON, William H.. Como construir o Data Warehouse. 2ª ed. New York:
Editora Campus, 1997.
[PIN99] PINHEIRO, Carlos André Reis. Data Mining: obtendo vantagens com seu Data
Warehouse.
[HAISTEN99], M. Real time data warehouse: the next stage in data warehouse evolution, part
1. DM Review, June 1999.