datawarehouse_artigo bom_parei modelo de dados.pdf

5/28/2018 datawarehouse_artigo bom_parei modelo de dados.pdf

1/44

DATA WAREHOUSE

INTRODUO

Informaes importantes em uma organizao, armazenadas em grandes bancos

de dados, geralmente heterogneas e distribudas, so pouco aproveitadas para

dar suporte deciso. Tentando minimizar problemas de distribuio e

heterogeneidade, no centro deste ambiente est o conceito de Data Warehouse.

A tecnologia de Data Warehouse surgiu principalmente devido s dificuldades que

muitas organizaes comearam a passar pela quantidade de dados que suas

aplicaes estavam gerando e dificuldade de reunir estes dados de forma

integrada para uma anlise mais eficiente. A idia, ento, foi reunir em um nico

local, somente os dados considerados teis no processo decisrio.

Em um exemplo prtico, suponhamos uma empresa de transporte areo. Atravs

da tecnologia Data Warehouse pode-se obter a informao sobre qual ms do ano

h uma maior procura por vos para o Rio de Janeiro, ou ainda, para qual local os

jovens com menos de vinte e cinco anos esto viajando atravs dos meios areos.

Tendo em mos essas informaes em tempo hbil em outras palavras, antes

da concorrncia os executivos dessa organizao podem dispor mais vos para

o Rio de Janeiro no ms de maior procura e, a respeito dos jovens, talvez fosse

interessante disponibilizar algum tipo de lazer diferenciado durante a viagem.

De posse destas informaes, os executivos/usurios do Data Warehouse

dispem de mecanismos que permitem, a partir de seu velho e volumoso banco


2/44

de dados, extrair dados que sero de grande utilidade e que daro maior

lucratividade a mdio-longo prazo.

O nosso exemplo se aplica a empresas privadas, mas o Data Warehouse tambmpode ser aplicada em organizaes governamentais pblicas. Tendo em mos um

Data Warehouse, o Secretrio da Sade, por exemplo, pode obter a informao

de qual regio da cidade ocorreram mais casos de dengue nos ltimos cinco anos

e, em quais meses desses anos, houve uma maior incidncia desse vrus.

Os avanos da tecnologia de informao vieram garantir a possibilidade das

organizaes manipularem grandes volumes de dados e atingirem um alto ndice

de integrao. Dados de todos os departamentos de uma organizao podem

estar em uma nica base de dados, integrados, padronizados e resumidos para

serem analisados pelos tomadores de decises.


3/44

DESENVOLVIMENTO DO PROJETO DE DATA WAREHOUSE

EVOLUO DOS SISTEMAS DE APOIO DECISO

Segundo Inmon (1997), a evoluo dos sistemas de apoio a deciso pode ser

dividida em cinco fases entre 1960 e 1980. No incio da dcada de 1960 o mundo

da computao consistia na criao de aplicaes individuais que eram

executadas sobre arquivos mestres, caracterizadas por programas e relatrios.

Aproximadamente em 1965 o crescimento dos arquivos mestres e das fitas

magnticas explodiu, surgindo problemas como a complexidade de manuteno

dos programas; a complexidade do desenvolvimento de novos programas; a

quantidade de hardware para manter todos os arquivos mestres e a necessidade

de sincronizar dados a serem atualizados.

Por volta de 1970, surgiu a tecnologia DASD, substituindo as fitas magnticas pelo

armazenamento em disco. Com o DASD surgiu um novo tipo de software

conhecido como SGBD ou sistema de gerenciamento de banco de dados, que

tinha o objetivo de tornar o armazenamento e o acesso a dados no DASD mais

fceis para o programador.

Examinando a confuso criada pelos arquivos mestres e as enormes quantidades

de dados redundantes ligadas a eles, no de admirar que banco de dados seja

definido como: uma nica fonte de dados para todo o processamento. (Inmon,

1997).


4/44

Aproximadamente em 1975 surgiu o processamento de transaes online. Com o

processamento de transaes online de alta performance, o computador pde ser

usado para tarefas que antes no eram viveis como controlar sistemas de

reservas, sistemas de caixas bancrios, sistemas de controle de produo e

outros.

At o incio da dcada de 1980, novas tecnologias, como os PCs e as L4Gs,

comearam a aparecer. O usurio final passou a controlar diretamente os

sistemas e os dados, descobrindo que era possvel utiliza-los para outros objetivos

alm de atender ao processamento de transaes online de alta performance. Foi

nesse perodo tambm que se tornou vivel a construo dos SIGs. Hoje

conhecidos como SAD, os SIGs consistiam em processamento utilizado para

direcionar decises gerenciais.


5/44

A TEIA DE ARANHA

Aps o advento das transaes online de alta performance, comearam a surgir

os programas de extrao. Esses programas varrem arquivos de banco dedados usando alguns critrios, e, ao encontrar esses dados, transporta-os para

outro arquivo de banco de dados.

Com a difuso do programa de extrao, comeou a formar-se a chamada

arquitetura de desenvolvimento espontneo ou teia de aranha, conforme

mostrado na Figura 3. Primeiro havia extraes. Depois, extraes das extraes,

e, ento, extraes das extraes das extraes, e assim por diante.

Figura 1 - A Teia de Aranha


6/44

Devido arquitetura de desenvolvimento espontneo, surgiram problemas com a

credibilidade dos dados, a produtividade e a dificuldade de transformar dados

puros em informaes.

O AMBIENTE PROJETADO

A arquitetura de desenvolvimento espontneo no era suficiente para atender as

necessidades do futuro das empresas, fazendo-se necessrio uma mudana de

arquitetura, surgindo o ambiente projetado de Data Warehouse.

No cerne do ambiente projetado est a percepo de que h fundamentalmente

duas espcies de dados dados primitivos e dados derivados. A Tabela 1 mostra

algumas das principais diferenas entre dados primitivos e derivados.

Dados primitivos / Dados operacionais Dados derivados / dados SAD

Baseado em aplicaes Baseados em assunto ou negcio

Detalhados Resumidos ou refinados

Podem ser atualizados No so atualizados

So processados repetitivamente Processados de forma heurstica

Requisitos de processamento conhecidoscom antecedncia

Requisitos de processamento no soconhecidos com antecedncia.

A performance fundamental Performance no fundamental

Voltados para transao Voltados para anlise

Alta disponibilidade No necessria alta disponibilidade

Atendem as necessidades cotidianas Atendem as necessidades gerenciais

Alta taxa de acesso Baixa ou mdia taxa de acesso

Tabela 1 - dados operacionais versus dados derivados

Dados primitivos e dados derivados devem estar fisicamente separados. H uma

grande quantidade de diferenas entre dados primitivos e dados derivados.

espantoso que a comunidade de processamento de informaes tenha pensado


7/44

que dados primitivos e dados derivados pudessem se encaixar em um nico

banco de dados (Inmon, 1997).

H quatro nveis no ambiente projetado o operacional, a atmico ou DataWarehouse, o departamental e o individual, como representado na Figura 4. O

nvel operacional de dados contm apenas dados primitivos e atende

comunidade de processamento de transaes de alta performance. O Data

Warehouse contm dados primitivos que no so atualizados e dados derivados.

O nvel departamental de dados praticamente s contm dados derivados. E o

nvel individual de dados onde o maior parte das anlises heursticas feito.

Um importante aspecto do ambiente projetado a integrao dos dados que

ocorre ao longo da arquitetura. Se os dados chegarem ao Data Warehouse em um

estado no integrado, no podero ser utilizados como base para uma viso

Operacional Atmico / DataWarehouse

Departamental Individual

- Detalhado

- Cotidiano

- Valores atuais

- Alta taxa de

acesso

- Baseado em

aplicaes

- mais granular

- Temporal

- Integrado

- Baseado em

negcio

- Algum nvel

de resumo

- Paroquial

- Alguns derivados;

alguns primitivos

- Tpico de

departamentos:

- contabilidade

- marketing

- engenharia

- produo

- Temporrio

- ad hoc

- Heurstico

- No repetitivo

- Baseado em PCs ou

estaes de trabalho

Figura 2 - Nveis do Ambiente Projetado


8/44

corporativa dos dados. A existncia desta viso um dos fundamentos do

ambiente projetado(Kimball, 1998).

O QUE UM DATA WAREHOUSE

William H. Inmon foi um dos pioneiros no assunto Data Warehouse. Sua definio

a mais objetiva sobre o que um Data Warehouse: uma coleo de dados

orientados por assunto, integrado, varivel com o tempo e no-voltil, que tem por

objetivo dar suporte aos processos de tomada de deciso (Inmon, 1997).

Em outras palavras, um Data Warehouse um banco de dados contendo dados

extrados do ambiente de produo da empresa, que foram selecionados e

depurados, tendo sido otimizados para processamento de consulta e no para

processamento de transaes. Em geral, um Data Warehouse requer a

consolidao de outros recursos de dados alm dos armazenados em banco de

dados relacionais, incluindo informaes provenientes de planilhas eletrnicas,

documentos textuais, etc.

Para Campos (1999), importante considerar, no entanto, que um Data

Warehouse no contem apenas dados resumidos, podendo conter tambm dados

primitivos. desejvel prover ao usurio a capacidade de aprofundar-se num

determinado tpico, investigando nveis de agregao menores ou mesmo dados

primitivos, permitindo tambm a gerao de novas agregaes ou correlaes

com outras variveis. Alm do mais, extremamente difcil prever todos os


9/44

possveis dados resumidos que sero necessrios: limitar o contedo de um Data

Warehouse apenas a dados resumidos significa limitar os usurios apenas s

consultas e anlises que eles puderem antecipar frente a seus requisitos atuais,

no deixando qualquer flexibilidade para novas necessidades.

Para ficar mais clara a concepo de Data Warehouse examina a tabela 2 que

contm uma comparao entre as caractersticas dos bancos de dados

operacionais com um Data Warehouse.

Caractersticas Bancos de dadosOperacionais

Data Warehouse

Objetivo Operaes dirias do negcio Analisar o negcio

Uso Operacional Informativo

Tipo de processamento OLTP OLAP

Unidade de trabalho Incluso, alterao, excluso. Carga e consulta

Nmero de usurios Milhares Centenas

Tipo de usurio Operadores Comunidade gerencial

Interao do usurio Somente pr-definida Pr-definida e ad-hoc

Condies dos dados Dados operacionais Dados Analticos

Volume Megabytes gigabytes Gigabytes terabytes

Histrico 60 a 90 dias 5 a 10 anos

Granularidade Detalhados Detalhados e resumidos

Redundncia No ocorre Ocorre

Estrutura Esttica Varivel

Manuteno desejada Mnima Constante

Acesso a registros Dezenas Milhares

Atualizao Contnua (tempo real) Peridica (em batch)

Integridade Transao A cada atualizao

Nmero de ndices Poucos/simples Muitos/complexosInteno dos ndices Localizar um registro Aperfeioar consultas

Tabela 2 - Comparao entre banco de dados operacionais e Data Warehouse

O Data Warehouse o alicerce do processamento dos SADs. Em virtude de haver

uma nica fonte de dados integrados, e uma vez que os dados apresentam


10/44

condies facilitadas de acesso e interpretao, a tarefa do analista de SAD no

ambiente Data Warehouse fica incomensuravelmente mais fcil do que no

ambiente clssico.

CARACTERSTICAS DE UM DATA WAREHOUSE

Quatro caractersticas principais regem o conceito de Data Warehouse.

Orientado por temas: Refere-se ao fato do Data Warehouse armazenar

informaes sobre temas especficos importantes para o negcio da empresa.

Exemplos tpicos de temas so: produtos, atividades, contas, clientes, etc. Em

contrapartida, o ambiente operacional organizado por aplicaes funcionais. Por

exemplo, em uma organizao bancria, estas aplicaes incluem emprstimos,

investimentos e seguros (Campos, 1999).

Integrado:Refere-se consistncia de nomes, das unidades das variveis, etc,

no sentido de que os dados foram transformados at um estado uniforme. Por

exemplo, considere-se sexo como um elemento de dado. Uma aplicao pode

codificar sexo como M/F, outra como 1/0 e uma terceira como H/M. Conforme os

dados so inseirdos para o Data Warehouse, eles so convertidos para um estado

uniforme, ou seja, sexo codificado apenas de uma forma. Da mesma maneira,

se um elemento de dado medido em centmetros em uma aplicao, em

polegadas em outra, ele ser convertido para uma representao nica ao ser

colocado no Data Warehouse(Campos, 1999).


11/44

Variante no tempo:refere-se ao fato do dado em um Data Warehouse referir-se a

algum momento especfico, significando que ele no atualizvel, enquanto que o

dado de produo atualizado de acordo com mudanas de estado do objeto em

questo, refletindo, em geral, o estado do objeto no momento do acesso. Em um

Data Warehouse, a cada ocorrncia de uma mudana, uma nova entrada criada,

para marcar esta mudana. O tratamento de sries temporais apresenta

caractersticas especficas, que adicionam complexidade ao ambiente do Data

Warehouse. Processamentos mensais ou anuais so simples, mas dias e meses

oferecem dificuldades pelas variaes encontradas no nmero de dias em um msou em um ano, ou ainda no incio das semanas dentro de um ms. Alm disso,

deve-se considerar que no apenas os dados tm uma caracterstica temporal,

mas tambm os metadados, que incluem definies dos itens de dados, rotinas de

validao, algoritmos de derivao, etc. Sem a manuteno do histrico dos

metadados, as mudanas das regras de negcio que afetam os dados no Data

Warehouse so perdidas, invalidando dados histricos(Campos, 1999).

No Voltil:Significa que o Data Warehouse permite apenas a carga inicial dos

dados e consultas a estes dados. Aps serem integrados e transformados, os

dados so carregados em bloco para o Data Warehouse, para que estejam

disponveis aos usurios para acesso. No ambiente operacional, ao contrrio, os

dados so, em geral, atualizados registro a registro, em mltiplas transaes. Esta

volatilidade requer um trabalho considervel para assegurar integridade e

consistncia atravs de atividades de rollback, recuperao de falhas, commits e


12/44

bloqueios. Um Data Warehouse no requer este grau de controle tpico dos

sistemas orientados a transaes(Campos, 1999).

Granularidade: diz respeito ao nvel de detalhe ou de resumo contido nasunidades de dados existentes no Data Warehouse. Quanto maior o nvel de

detalhes, menor o nvel de granularidade. O nvel de granularidade afeta

diretamente o volume de dados armazenado no Data Warehouse e ao mesmo

tempo o tipo de consulta que pode ser respondida(Campos, 1999).


13/44

USURIOS TPICOS DE UM DATA WAREHOUSE

Inmon, Welch e Glassey (1999) identificaram trs usurios tpicos de um Data

Warehouse: os fazendeiros, os exploradores e os turistas. A Figura 5 ilustra os

tipos de usurios.

Como regra, os dados estruturados organizacional servem aos usurios

fazendeiros e turistas. O dados detalhados servem aos usurios exploradores

porque so orientados corporativamente, suportam acesso aleatrio e so

OLAP

Estruturado

Organizacional

Exploradores

FazendeirosTuristas

Os fazendeiros

da organizao

colhem

informaes a

partir de

caminhos

de acessos

conhecidos.

Os turistas da

organizao

navegam

atravs das

informaes

colhidas pelos

fazendeiros.

Os exploradores da

organizao procuram as

recompensas

desconhecidas e at ento

ignoradas que se ocultam

por trs dos dados

detalhados.

Figura 3 - Usurios do Data Warehouse


14/44

completos e histricos. O ambiente OLAP (explicado mais adiante) suporta os

usurios fazendeiros porque os dados so personalizados antes de serem

enviados ao ambiente OLAP. A fim de personalizar os dados, necessrio saber

como os dados sero usados.; os fazendeiros tomam essas decises com base

no como os turistas consomem seus produtos. Em outras palavras, fornecimento e

demanda aplicam-se arquitetura do Data Warehouse na determinao do que

deve ser populado no ambiente OLAP (Inmon, Welch e Glassey, 1999).

H diversas excees a essa regra de diferentes usurios. Devido quantidade

limitada de dados l encontrados, o grande nmero de ndices e a elegncia da

interface, possvel executar exploraes no ambiente OLAP. Contudo, a

explorao no nvel OLAP superficial, e encontra uma viso geral e no

detalhada. Na maioria das vezes, o ambiente OLAP existe e perfeito para os

usurios fazendeiros e turistas, mas no para a comunidade de exploradores.


15/44

ARQUITETURA DO DATA WAREHOUSE

Para ser til o Data Warehouse deve ser capaz de responder a consultas

avanadas de maneira rpida, 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 rpida. Mas construir um

Data Warehouse eficiente, que servir de suporte a decises 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 vrios sistemas podem conter redundncias e diferenas, ento

antes de pass-los para o Data Warehouse necessrio 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

usurios utilizaro em suas decises. Um Data Warehouse pode variar sua

arquitetura conforme o tipo de assunto abordado, pois as necessidades tambm

variam de empresa para empresa.

A Figura 6 mostra os principais componentes da arquitetura de um Data

Warehouse.


16/44

A arquitetura de um Data Warehouse inclui ferramentas para extrair dados de

mltiplas bases de dados operacionais e fontes externas; limpar, transformar e

integrar estes dados, carreg-los at o Data Warehouse e periodicamente fazer orefresh, isto , propagar as atualizaes ocorridas nas mltiplas base de dados

operacionais. Em adio ao Data Warehouse principal, pode haver vrios Data

Warehouses departamentais, que so denominados Data Marts.

Dados no Data Warehouse e Data Marts so armazenados e gerenciados por um

ou mais servidores de Data Warehouse, os quais apresentam visesmultidimensionais de dados para uma variedade de ferramentas front end.

Finalmente, h um repositrio para armazenar e gerenciar metadados.

Front End Tools

Servidores OLAP

Fontes

BD

ExtraoTransformaoCarga

Refresh

DW

Data Marts

?

Anlise

Consulta

Relatrio

Data Minin

Administrao e gerenciamento: Repositrio de

Back End

Figura 6 - Arquitetura do Data Warehouse


17/44

FERRAMENTAS BACK END

Sistemas de Data Warehouse usam uma variedade de ferramentas para extrao,

limpeza de dados, carga e refresh para povoar o banco de dados. Estas

ferramentas so chamadas Back End e as principais funes desempenhadas por

elas so:

Limpeza de dados: J que o Data Warehouse usado para tomada de deciso,

importante que os seus dados estejam corretos. Entretanto, uma vez que

grandes volumes de dados esto envolvidos, h uma alta probabilidade de erros e

anomalias nos dados. Tamanhos inconsistentes de campo, descries

inconsistentes, atribuio inconsistente de valores, entradas erradas e violao de

restries de integridade so alguns exemplos onde a limpeza de dados torna-se

necessria.

Carga: Depois de extrair, limpar e transformar, os dados devem ser carregados

para o Data Warehouse. Um pr-processamento adicional pode ser requerido,

como por exemplo, checagem de restries de integridade, sumarizao,

agregao, dentre outros mais. Tipicamente, batch load usado para este

propsito, isto , o processo de carga feito em lotes. A carga do Data

Warehouse tem que lidar com volumes de dados muito maiores que os banco de

dados operacionais.


18/44

Refresh: Fazer o refresh de um Data Warehouse consiste em propagar as

atualizaes ocorridas nos banco de dados operacionais para o banco de dados

derivado do Data Warehouse.

FERRAMENTAS FRONT END

Segundo Moraes (1998), o componente front end de um sistema de Data

Warehouse o responsvel por fornecer uma soluo de acesso aos dados que

atenda as necessidades por informaes dos trabalhadores do conhecimento.

As ferramentas front end so utilizadas para anlise, ajudando a interpretar o que

ocorreu e a decidir sobre estratgias futuras. Neste tipo de aplicao, somente a

operao de consulta se faz necessria.

As ferramentas Front End executam:

o Seleo do conjunto de dados necessrios;

o Clculo e manipulao dos dados;

o Apresentao das informaes;

Os geradores de consultas e relatrios so considerados a primeira gerao de

ferramentas para o acesso a dados, as quais permitem a realizao de consultas

ad-hoc. Atualmente, as ferramentas de OLAP so as principais aplicaes de

suporte deciso utilizadas em sistemas de Data Warehouse, sendo

consideradas a segunda gerao de ferramentas para acesso a dados. Ao


19/44

contrrio dos geradores de consultas e relatrios, que apenas permitem uma

visualizao esttica dos dados que no podem mais ser manipulados, as

aplicaes de OLAP possibilita que a partir de uma resposta se faam outros

questionamentos, ou seja, o usurio consegue analisar o porqu dos resultados

obtidos.

Moraes (1998), compilou a lista abaixo de caractersticas que possuem eficientes

ferramentas de Front End.

o facilidades para acesso aos dados, manipulao e apresentao;

o capacidade de especificar consultas e relatrios com facilidade;

o suporte para a indstria de padres de interface, incluindo Microsoft

Windows GUI, ODBC, etc.

o suporte para o desenvolvimento de interfaces amigveis;

o habilidade para acessar a funcionalidade nativa de uma variedade

de BD e outras origens de dados;

o habilidade para suportar uma variedade de plataformas servidoras e

SGBDs.


20/44

DATA MARTS

Um Data Mart um sistema de suporte a deciso que incorpora um subconjunto

de dados da empresa focalizado em funes ou atividades especficas da

organizao. Os Data Marts tm propsitos especficos relacionados ao negcio,

como medida do impacto de promoes de marketing, medida ou previso de

vendas, medida do impacto da introduo de novos produtos, etc.

Data Marts podem incorporar dados substanciais, mas eles contm muito menos

dados que teria um Data Warehouse desenvolvido para a mesma organizao.

Uma vez que Data Marts so focalizados em propsitos especficos do negcio, o

planejamento do sistema e a anlise dos requerimentos so mais facilmente

gerenciveis, e o projeto, implementao, fase de testes e instalao so bem

mais baratos que para um Data Warehouses (Inmon, Welch e Glassey, 1999).Por

esse motivo, os Data Marts esto se tornando uma alternativa bastante popular

nos ltimos anos.

Os projetos de Data Marts devem ser inicialmente simples e teis para que

possam atingir seus objetivos de forma rpida e clara. No desejvel para uma

empresa investir uma quantia em dinheiro e tempo de seus funcionrios em um

projeto que pode levar meses para ser concludo e que durante o processo de

implantao possa terminar por gerar controvrsias e at mesmos problemas para

os setores(Kimball, 1998).


21/44

DATA MINING

Data Mining uma ferramenta de extrao de dados. O Data Mining engloba um

nmero de diferentes abordagens tcnicas, como clustering (agrupamento),sumarizao de dados, regras de classificao, deteco de anomalias, etc.

Data Mining uma categoria de ferramentas de anlise. Em vez de se fazerem

perguntas, entrega-se grandes quantidades de dados e pergunta-se se existe algo

de interessante (uma tendncia ou um agrupamento, por exemplo). O processo de

minerao de dados pode extrair conhecimento que est escondido ou

informaes de prognstico do Data Warehouse sem a necessidade de consultas

especficas ou requisies.

Esse processo de minerao usa tcnicas avanadas como redes neurais,

heursticas, descoberta por regra e deteco de desvio. Ao contrrio de relatrios

e consultas cujos relacionamentos j se conhece, o trabalho do Data Mining

descobrir o que no se sabe que existe no banco de dados.

Alguns exemplos de aplicaes de Data Mining:

o identificar padres de compra dos clientes;

o identificar correlaes escondidas entre diferentes indicadores

financeiros;

o identificar superfaturamento em grandes obras pblicas.


22/44

SISTEMAS GERENCIADORES DE BANCOS DE DADOS

SGBDs tm como funo fornecer acesso e manipulao eficientes aos dados

armazenados no banco, proteger estes dados contra acessos indevidos e mantersua consistncia e integridade(Moraes, 1998).

Os SGBDs em sistemas de Data Warehouse devem suportar processamento

analtico on-line (OLAP), ao contrrio do j tradicional processamento de

transaes on-line (OLTP). Os SGBDs voltados ao processamento de transaes

tm como principal caracterstica dar suporte para atualizaes concorrentes de

centenas de usurios. J os SGBDs voltados para sistemas de Data Warehouse

devem ser otimizados para o processamento de consultas complexas e ad-hoc.

Trs classes de SGDBs devem ser citadas:

a) SGBDs relacionais tradicionais:

A tecnologia relacional vem sendo amplamente reconhecida como a melhor

alternativa para a hospedagem de dados em sistemas de Data Warehouse.

Rapidamente, as melhorias dos SGBDs na rea de suporte deciso vm

atendendo as necessidades impostas pelo ambiente de Data Warehouse. Isto se

deve, principalmente, a dois principais pontos fracos dos SGBDs

multidimensionais: inflexibilidade (estrutura de arquivos proprietria) e limitado

volume de dados que podem gerenciar.

b) SGBDs multidimensionais (MOLAP):


23/44

Em um banco de dados multidimensional, em vez de armazenar registros em

tabelas, eles armazenam os dados em matrizes. So projetados com o objetivo de

permitir uma eficiente e conveniente armazenagem e recuperao de dados que

esto intimamente relacionados. Estes dados so armazenados, visualizados e

analisados segundo diferentes dimenses.

O grande problema dos SGBDs multidimensinais a sua capacidade de

armazenamento ainda limitada para as necessidades de um Data Warehouse.

Desta forma, estes produtos so mais utilizados no mercado como gerenciadores

de Data Marts.

c) SGBDs relacionais especializados para sistemas de Data Warehouse:

So otimizados para atender ambientes de somente leitura (read only), onde o

processamento eficiente de consultas importantssimo. A idia nestes produtos

abandonar os requisitos necessrios ao processamento de transaes (OLTP) e

se concentrar nos requisitos necessrios ao OLAP. Desta forma, estes SGBDs

fornecem novas tcnicas de otimizao de consultas sobre estruturas do tipo star

scheme, utilizam novos mtodos de indexao e interpretam a sintaxe SQL para

dar suporte a consultas que so importantes no ambiente de Data Warehouse.


24/44

MODELO DE DADOS

Obter respostas a questes tpicas de anlise dos negcios de uma empresa

geralmente requer a visualizao dos dados segundo diferentes perspectivas.

Suponhamos uma grande rede de hotis que deseja melhorar o desempenho de

seu negcio. Para isso, necessita examinar os dados sobre as reservas e seus

clientes. Uma avaliao deste tipo requer uma viso histrica do volume de

reservas informaes sobre seus clientes sob mltiplas perspectivas, como por

exemplo: qual a idade mdia de seus clientes, qual o perodo mdio que os

mesmos se hospedam no hotel. Uma anlise da idade mdia de seus clientes

utilizando uma ou mais destas perspectivas, permitiria responder questes do tipo:

Qual a idade mdia dos hspedes na temporada de final de ano?

Tendo em mos a resposta para essa questo, a gerncia do hotel poderia investir

no marketing para um cliente-alvo mais preciso. A capacidade de responder a este

tipo de questo em tempo hbil o que permite aos gerentes e altos executivos

das empresas formular estratgias efetivas, identificar tendncias e melhorar sua

habilidade de tomar decises de negcio. O ambiente tradicional de bancos de

dados relacional certamente pode atender a este tipo de consulta. No entanto,

usurios finais que necessitam de consultas deste tipo, via acesso interativo aos

bancos de dados, mostram-se frustrados por tempos de resposta ruins e pela falta

de flexibilidade oferecida por ferramentas de consulta baseadas no SQL (Kimball,

1998).


25/44

Da a necessidade de utilizar abordagens especficas para atender a estas

consultas.

A mais importante diferena entre sistemas OLTP e Data Warehouse est nomodelo de dados. O tradicional modelo Entidade-Relacionamento divide os dados

em vrias entidades distintas, cada uma transformada em uma tabela do Banco de

Dados OLTP. H algumas observaes a fazer sobre o diagrama entidade-

relacionamento.

Em primeiro lugar, ele muito simtrico. Todas as tabelas parecem iguais; esses

diagramas so difceis de visualizar e memorizar tanto pelo usurio final quanto

pelos projetistas (Kimball, 1998). Segundo, quando duas tabelas do diagrama so

necessrias para uma consulta, h um nmero imenso de conexes possveis

entre as duas tabelas. Em consultas que abrangem muitas tabelas e registros, os

diagramas Entidade-Relacionamento tornam-se muito complexos tanto para o

usurio entender quanto para o software navegar. Dito isto, pode-se concluir que

modelos Entidade-Relacionamento so um desastre para ambientes read only

(somente consulta) e no so propcios para serem utilizados como base para o

Data Warehouse.

A representao dos dados em um Data Warehouse estruturada como um cubo

de dados. Essa estrutura chamada modelo dimensional, tambm conhecida

como star scheme. Ao contrrio do modelo Entidade-Relacionamento, o modelo

dimensional muito assimtrico. H uma tabela dominante no centro do diagrama

com mltiplas junes a conectando nas outras tabelas. Cada uma das tabelas


26/44

secundrias possui apenas uma juno com a tabela central. A tabela central

chamada de tabela de fatos e as outras tabelas de tabelas de dimenso, como

mostra a Figura 7:

A tabela de fatos armazena medies numricas do negcio. Cada uma das

medies obtida na interseo de todas as dimenses. Os fatos melhores e

mais teis so numricos, valorados (diferentes a cada medida) e aditivos (podem

ser adicionados ao longo das dimenses). O motivo para utilizar fatos valorados e

aditivos que em praticamente todas as consultas feitas tabela de fatos, so

solicitados centenas ou milhares de registros para construir o conjunto de

resposta. Esse grande nmero de registros ser compactado em algumasdezenas de linhas para produzir o conjunto de resposta do usurio. A nica forma

vivel de compact-los no conjunto de resposta ser adicion-los. Portanto, se as

medies forem nmeros e se forem aditivas, pode-se construir facilmente o

conjunto de resposta.,

DIM TEMPO

id_tempodia_do_ms

dia_da_semana

ms

ano

FATO COMPRAS

id_tempoid_produto

id_fornecedor

quantidade

valor

DIM PRODUTO

id_produto

descrio

categoriavolume

DIM FORNECEDOR

id_fornecedor

nomeendereo

descrio

Figura 5 - Star Scheme


27/44

As tabelas dimensionais armazenam as descries textuais das dimenses. Esses

atributos textuais so usados como restries e cabealhos de linha no conjunto

de resposta.

Ao se projetar um banco de dados, pode-se ficar na dvida se um campo de

dados ser modelado como um fato ou um atributo. Segundo Kimball (1998), se o

dado for numrico e variar continuamente a cada amostragem, ele ser

considerado um fato. Do contrrio, se for uma descrio praticamente constante

de um item, ser considerada um atributo de dimenso.

O Star Schemetem uma srie de vantagens que so descritas abaixo:

o O Star Scheme tem uma arquitetura padro e previsvel. As ferramentas de

consulta e interfaces do usurio podem se valer disso para fazer suas

interfaces mais amigveis e fazer um processamento mais eficiente;

o Todas as dimenses do modelo so equivalentes, ou seja, podem ser

vistas como pontos de entrada simtricos para a tabela de fatos. As

interfaces do usurio so simtricas, as estratgias de consulta so

simtricas, e o SQL gerado, baseado no modelo, simtrico;

o O modelo dimensional totalmente flexvel para suportar a incluso de

novos elementos de dados, bem como mudanas que ocorram no projeto.

Essa flexibilidade se expressa de vrias formas, dentre as quais temos:


28/44

Todas as tabelas de fato e dimenses podem ser alteradas

simplesmente acrescentando novas colunas a tabelas;

Nenhuma ferramenta de consulta ou relatrio precisa ser alterada deforma a acomodar as mudanas;

Todas as aplicaes que existiam antes das mudanas continuam

rodando sem problemas;

o Existe um conjunto de abordagens padres para tratamento de situaes

comuns no mundo dos negcios. Cada uma destas tem um conjunto bem

definido de alternativas que podem ento ser especificamente programadas

em geradores de relatrios, ferramentas de consulta e outras interfaces do

usurio. Dentre estas situaes temos:

Mudanas lentas das dimenses: ocorre quando uma determinada

dimenso evolui de forma lenta e assncrona;

Produtos heterogneos: quando um negcio, tal como um banco,

precisa controlar diferentes linhas de negcio juntas, dentro de um

conjunto comum de atributos e fatos, mas ao mesmo tempo esta

precisa descrever e medir as linhas individuais de negcio usando

medidas incompatveis;

o Outra vantagem o fato de um nmero cada vez maior de utilitrios

administrativos e processo de software serem capazes de gerenciar e usar


29/44

agregados, que so de suma importncia para a boa performance de

respostas em um Data Warehouse.

DESENVOLVIMENTO DE UM DATA WAREHOUSE

O sucesso do desenvolvimento de um Data Warehouse depende

fundamentalmente de uma escolha correta da estratgia a ser adotada, de forma

que seja adequada s caractersticas e necessidades especficas do ambiente

onde ser implementado. Existe uma variedade de abordagens para o

desenvolvimento de Data Warehouses, devendo-se fazer uma escolha

fundamentada em pelo menos trs dimenses: escopo (departamental,

empresarial, etc), grau de redundncia de dados, tipo de usurio alvo.

O escopo de um Data Warehouse pode ser to amplo quanto aquele que inclui

todo o conjunto de informaes de uma empresa ou to restrito quanto um Data

Warehouse pessoal de um nico gerente. Quanto maior o escopo, mais valor o

Data Warehouse tem para a empresa e mais cara e trabalhosa sua criao e

manuteno. Por isso, muitas empresas tendem a comear com um ambiente

departamental e s aps obter um retorno de seus usurios expandir seu escopo.

Quanto redundncia de dados, h essencialmente trs nveis de redundncia: o

Data Warehouse virtual, o Data Warehouse centralizado e o data warehouse

distribudo.

O Data Warehouse virtual consiste em simplesmente prover os usurios finais

com facilidades adequadas para extrao das informaes diretamente dos


30/44

bancos de produo, no havendo assim redundncia, mas podendo

sobrecarregar o ambiente operacional.

O Data Warehouse central constitui-se em um nico banco de dados fsicocontendo todos os dados para uma rea funcional especfica, um departamento ou

uma empresa, sendo usados onde existe uma necessidade comum de

informaes. Um Data Warehouse central normalmente contm dados oriundos de

diversos bancos operacionais, devendo ser carregado e mantido em intervalos

regulares.

O Data Warehouse distribudo, como o nome indica, possui seus componentes

distribudos por diferentes bancos de dados fsicos, normalmente possuindo uma

grau de redundncia alto e por conseqncia, procedimentos mais complexos de

carga e manuteno.

Os padres de uso de um Data Warehouse tambm constituem um fator

importante na escolha de alternativas para o ambiente. Relatrios e consultas pr-

estruturadas podem satisfazer o usurio final, e geram pouca demanda sobre o

SGBD e sobre o ambiente servidor. Anlises complexas, por sua vez, tpicas de

ambientes de suporte deciso, exigem mais de todo o ambiente.

Ambientes dinmicos, com necessidades em constante mudana, so mais bem

atendidos por uma arquitetura simples e de fcil alterao, ao invs de uma

estrutura mais complexa que necessite de reconstruo a cada mudana. A

freqncia da necessidade de atualizao tambm determinante: grandes


31/44

volumes de dados que so atualizados em intervalos regulares favorecem uma

arquitetura centralizada.

ESTRATGIA EVOLUCIONRIA

Data Warehouses, em geral, so projetados e carregados passo a passo,

seguindo, portanto uma abordagem evolucionria. Os custos de uma

implementao "por inteiro", em termos de recursos consumidos e impactos no

ambiente operacional da empresa justificam esta estratgia.

Muitas empresas iniciam o processo a partir de uma rea especfica da empresa,

que normalmente uma rea carente de informao e cujo trabalho seja relevante

para os negcios da empresa, criando os chamados Data Marts, para depois ir

crescendo aos poucos, seguindo uma estratgia "botton-up" ou assunto-por-

assunto.

Outra alternativa selecionar um grupo de usurios, prover ferramentas

adequadas, construir um prottipo do Data Warehouse, deixando que os usurios

experimentem com pequenas amostras de dados. Somente aps a concordncia

do grupo quanto aos requisitos e funcionamento, o Data Warehouse ser de fato

alimentado com dados dos sistemas operacionais na empresa e dados externos.

Data Marts tambm pode ser criados como subconjunto de um Data Warehouse

maior, em busca de autonomia, melhor desempenho e simplicidade de

compreenso.


32/44

ASPECTOS DE MODELAGEM

A especificao de requisitos do ambiente de suporte deciso associado a um

Data Warehouse fundamentalmente diferente da especificao de requisitos dossistemas que sustentam os processos usuais do ambiente operacional de uma

empresa.

Os requisitos dos sistemas do ambiente operacional so claramente identificveis

a partir das funes a serem executadas pelo sistema. Requisitos de sistemas de

suporte deciso so, por sua vez, indeterminados.

O objetivo por trs de um Data Warehouse prover dados com qualidade; os

requisitos dependem das necessidades de informao individuais de seus

usurios. Ao mesmo tempo, os requisitos dos sistemas do ambiente operacional

so relativamente estveis ao longo do tempo, enquanto que os dos sistemas de

suporte deciso so instveis. No entanto, embora as necessidades por

informaes especficas mudem com freqncia, os dados associados no

mudam. Imaginando-se que os processos de negcio de uma empresa

permaneam relativamente constantes, existe apenas um nmero finito de objetos

e eventos com as quais uma organizao est envolvida.

Por esta razo, o modelo de dados uma base slida para identificar requisitos

para um Data Warehouse.


33/44

ETAPAS DO DESENVOLVIMENTO DE UM DATA WAREHOUSE

Na verdade, difcil apontar no momento, uma metodologia consolidada e

amplamente aceita para o desenvolvimento de Data Warehouses. O que se v naliteratura e nas histrias de sucesso de implementaes em empresas, so

propostas no sentido de construir um modelo dimensional a partir do modelo de

dados corporativo ou departamental, de forma incremental.

De qualquer forma, a metodologia a ser adotada ainda bastante dependente da

abordagem escolhida, em termos de ambiente, distribuio, etc.

Desenvolver um Data Warehouse uma questo de casar as necessidades dos

seus usurios com a realidade dos dados disponveis. Abaixo podemos analisar

os chamados pontos de deciso, que constituem definies a serem feitas e

correspondem a etapas do projeto:

1. Os processos, e por conseqncia, a identidade das tabelas de fatos;

2. A granularidade de cada tabela de fatos;

3. As dimenses de cada tabela de fatos;

4. Aos fatos, incluindo fatos pr-calculados;

5. Os atributos das dimenses;

6. Como acompanhar mudanas graduais em dimenses;


34/44

7. As agregaes, dimenses heterogneas, minidimenses e outras decises

de projeto fsico;

8. Durao histrica do banco de dados;

9. A urgncia com que se d a extrao e carga para o Data Warehouse.

Esta metodologia segue a linha top-down, pois comea identificando os grandes

processos da empresa.

EXTRAINDO INFORMAES DE UM DATA WAREHOUSE

Existem vrias maneiras de recuperar informaes de um data Warehouse. As

formas de extrao mais comuns no mercado hoje so:

o Ferramentas de consulta e emisso de relatrios;

o EIS (Executive Information Systems);

o Ferramentas OLAP;

o Ferramentas Data mining.

A nova tendncia dessas solues a integrao com o ambiente Web,

permitindo maior agilidade em consultas estticas e dinmicas.


35/44

A seguir veremos de forma bsica e separadamente os conceitos das tecnologias

OLAP e Data Mining. A diferena bsica entre ferramentas OLAP e Data Mining

est na maneira como a explorao dos dados abordada.

Com ferramentas OLAP a explorao feita na base da verificao, isto , o

analista conhece a questo, elabora uma hiptese e utiliza a ferramenta para

confirm-la.

Com Data Mining, a questo total ou parcialmente desconhecida e a ferramenta

utilizada para a busca de conhecimento.

FERRAMENTAS OLAP

OLAP On-Line Analytical Processing representa um conjunto de tecnologias

projetadas para suportar anlise e consultas ad hoc. Sistemas OLAP ajudam

analistas e executivos a sintetizarem informaes sobre a empresa, atravs de

comparaes, vises personalizadas, anlise histrica e projeo de dados em

vrios cenrios de "e se...".

Os sistemas OLAP so implementados para ambientes multi-usurio, arquitetura

cliente-servidor e oferecem respostas rpidas e consistentes s consultas

iterativas executadas pelos analistas, independente do tamanho e complexidade

do banco de dados.


36/44

A caracterstica principal dos sistemas OLAP permitir uma viso conceitual multi-

dimensional dos dados de uma empresa. A viso multi-dimensional muito mais

til para os analistas do que a tradicional viso tabular utilizada nos sistemas de

processamento de transao. Ela mais natural, fcil e intuitiva, permitindo a

viso em diferentes perspectivas dos negcios da empresa e desta maneira

tornando o analista um explorador da informao (Bispo e Cazarini, 1999).

A modelagem dimensional a tcnica utilizada para se ter uma viso multi-

dimensional dos dados. Nesta tcnica os dados so modelados em uma estrutura

dimensional conhecida por cubo. As dimenses do cubo representam os

componentes dos negcios da empresa tais como "cliente", "produto",

"fornecedor" e "tempo". A clula resultante da interseo das dimenses

chamada de medida e geralmente representa dados numricos tais como

"unidades vendidas", "lucro" e "total de venda". Alm dos componentes dimenso

e medida outro importante aspecto do modelo multi-dimensional a consolidaodos dados uma vez que para a tarefa de anlise so mais teis e significativas as

agregaes (ou sumarizao) dos valores indicativas dos negcios.

Alm da viso multi-dimensional dos dados da empresa, a tecnologia OLAP tem

uma srie de outras caractersticas importantes relacionadas abaixo:

o Anlise de tendncias. A tecnologia OLAP mais do que uma forma de

visualizar a histria dos dados. Deve, tambm, ajudar os usurios a

tomar decises sobre o futuro, permitindo a construo de cenrios ("e


37/44

se...") a partir de suposies e frmulas aplicadas, pelos analistas, aos

dados histricos disponveis;

o Busca automtica (reach-through) de dados mais detalhados que noesto disponveis no servidor OLAP. Detalhes no so normalmente

importantes na tarefa de anlise, mas quando necessrios, o servidor

OLAP deve ser capaz de busc-los;

o Dimensionalidade genrica;

o Operao trans-dimensional. Possibilidade de fazer clculos e

manipulao de dados atravs diferentes dimenses;

o Possibilidade de ver os dados de diferentes pontos de vista (slice and

dice), mediante a rotao (pivoting) do cubo e a navegao (drill-up/drill-

down) entre os nveis de agregao;

o Conjunto de funes de anlise e clculos no triviais com os dados.

Segundo Inmon, Welch e Glassey (1999), existe tambm um conjunto de regras

que servem para avaliar as ferramentas OLAP):

o

Viso conceitual multidimensional;

o Transparncia;

o Acessibilidade;


38/44

o Performance de Relatrio consistente;

o Arquitetura cliente-servidor;

o Dimensionalidade genrica;

o Operao dimensional cruzada irrestrita;

o Manipulao de dados intuitiva;

o Flexibilidade quanto a relatrios;

o Dimenso e nveis de agregamentos ilimitados;

o Pesquisa de detalhes (drill down);

o Atualizao incremental do banco de dados;

o Arrays mltiplos;

o Seleo de subconjuntos;

o Suporte a dados locais.

Uma arquitetura OLAP possui trs componentes principais: um modelo de

negcios para anlises interativas, implementado numa linguagem grfica que

permita diversas vises e nveis de detalhes dos dados; um motor OLAP para

processar consultas multidimensionais contra o dado-alvo; e um mecanismo para

armazenar os dados a serem analisados.


39/44

MOLAP x ROLAP

Multidimensional OLAP (MOLAP) uma classe de sistemas que permite a

execuo de anlises sofisticadas usando como gerenciador de dados um bancode dados multidimensional. Em um banco de dados MOLAP os dados so

mantidos em arranjos e indexados de maneira a prover uma tima performance no

acesso a qualquer elemento. O indexamento, a antecipao da maneira como os

dados sero acessados e o alto grau de agregao dos dados faz com que

sistemas MOLAP tenham uma excelente performance. Alm de serem rpidos,

outra grande vantagem destes sistemas o rico e complexo conjunto de funes

de anlise que oferecem.

A maneira de se implementar os arranjos de dados pode variar entre fornecedores

de solues MOLAP. Existem as arquiteturas hiper-cubos e multi-cubos. Na

arquitetura hiper-cubo existe um nico cubo onde cada medida referenciada por

todas as outras dimenses. Por exemplo, um cubo onde a medida "compras"

referenciada pelas dimenses "produto", "ano", "mes", "estado" e "cidade".

Na arquitetura multi-cubos uma medida referenciada por dimenses

selecionadas. Em um cubo, a medida "vendas" referenciada pelas dimenses

"semestre", "estado" e "produto" e em outro cubo, a medida "custo" referenciada

pelas dimenses "ms" e "departamento". Esta arquitetura escalvel e utiliza

menos espao em disco. A performance melhor em cada cubo individualmente,

no entanto, consultas que requerem acesso a mais de um cubo podem exigir

processamentos complexos para garantir a consistncia do tempo de resposta.


40/44

Sistemas ROLAP fornecem anlise multidimensional de dados armazenados em

uma base de dados relacional. Existem duas maneiras de se fazer este trabalho:

o Fazer todo o processamento dos dados no servidor da base de dados. Oservidor OLAP gera os comandos SQL em mltiplos passos e as tabelas

temporrias necessrias para o processamento das consultas;

o Ou executar comandos SQL para recuperar os dados, mas fazer todo o

processamento (incluindo joins e agregaes) no servidor OLAP.

A principal vantagem de se adotar uma soluo ROLAP reside na utilizao de

uma tecnologia estabelecida, de arquitetura aberta e padronizada como a

relacional, beneficiando-se da diversidade de plataformas, escalabilidade e

paralelismo de hardware.

FERRAMENTAS DATA MINING

Segundo Pinheiros (1999), nos primrdios do Data Warehouse, o 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 esto

divergindo. Enquanto o Data Warehouse pode ser uma boa fonte de dados para

minerar, o Data Mining foi reconhecido como uma tarefa genuna, e no mais

como uma colnia do Data Warehouse.

Apesar do termo Data Mining ter se tornado bastante popular nos ltimos anos,

existe ainda uma certa confuso quanto sua definio. Data Mining (ou


41/44

minerao de dados) o processo de extrair informao vlida, previamente

desconhecida e de mxima abrangncia a partir de grandes bases de dados,

usando-as para efetuar decises cruciais. Data Mining vai muito alm da simples

consulta a uma banco de dados, no sentido de que permite aos usurios explorar

e inferir informao 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 evidncia no momento,

envolvendo Inteligncia Artificial e Banco de Dados (Campos, 1999).

Um ambiente de apoio tomada de decises, integrando tcnicas de Data Mining

sobre um ambiente de Data Warehousing, possibilita um grande nmero de

aplicaes, que j vm sendo implementadas em diversos segmentos de

negcios, como manufatura, automao de pedido de remessas, varejo,

gerenciamento de inventrios, financeiro, anlise de risco, transporte,gerenciamento de frotas, telecomunicao, anlise de chamadas, sade, analise

de resultados, markenting, estabelecimento do perfil dos consumidores, seguros,

deteco de fraude, dentre outros(Pinheiros, 1999).

O Data Mining pode ser utilizado com os seguintes objetivos:

o Explanatrio: explicar algum evento ou medida observada, tal como porque

a venda de sorvetes caiu no Rio de Janeiro;


42/44

o Confirmatrio: confirmar uma hiptese. Uma companhia de seguros, por

exemplo, pode querer examinar os registros de seus clientes para

determinar se famlias de duas rendas tem mais probabilidade de adquirir

um plano de sade do que famlias de uma renda;

o Exploratrio: analisar os dados buscando relacionamentos novos e no

previstos. Uma companhia de carto de crdito pode analisar seus registros

histricos para determinar que fatores esto associados a pessoas que

representam risco para crditos.

O diferencial do Data Mining est no fato de que as descobertas de padres de

consumo se do por uma lgica de algoritmos com base em uma rede neural de

raciocnios. So ferramentas de descobertas matemticas feitas sobre os registros

corporativos j processados contra descobertas empricas.

CARACTERSTICAS DE UM DATA WAREHOUSE BEM-SUCEDIDO

O que pode ser feito para criar um ambiente de anlise de dados moderno no qual

os usurios possam embarcar numa viagem aleatria e direta? Segundo Inmon,

Welch e Glassey (1999) h quatro objetivos-chave que devem ser alcanados

para um Data Warehouse ser considerado bem-sucedido.

o Fornecer modos melhores e mais rpidos para que os usurios

descubram as respostas a questes complexas e imprevisveis.


43/44

o Colocar os usurios em contado direto com os dados de que precisam

para tomar decises melhores.

o Permitir que os usurios tornem-se responsveis pela especificao,criao e gerao repetida dos relatrios e anlises que necessitem.

o Contar com uma manuteno apropriada e responsvel dos recursos de

dados corporativos.

O sistema que satisfaz esses objetivos um sistema de suporte a decises

moderno. Os projetos de Data Warehouse obtm sucesso quando os usurios so

mais independentes. Data Warehouses bem-sucedidos colocam os usurios no

centro do projeto. Quando todos reconhecem isso, uma nova atitude e abordagem

so os ingredientes mais bem-sucedidos nessa mistura. As organizaes que

entendem esses fatores fundamentais que esto conduzindo a alteraes no

paradigma tero sucesso em estabelecer Data Warehouses bem-sucedidos

(Inmon, Welch e Glassey, 1999).


44/44

Documents

datawarehouse_artigo bom_parei modelo de dados.pdf