Livro Apostila BI

Apostila de Treinamento Business Intelligence
Capitulo 1 - O que Business Intelligence?
1.1. Introduo
1.2. Business Intelligence Conceitos e analises
1.3. Business Intelligence - Histrico
1.4. Business Intelligence Benefcios
1.5.Gesto do Conhecimento e Sistemas de Informao
1.5.1. Conceitos Bsicos de Gesto do Conhecimento
1.5.1.1. O que e dado?
1.5.1.2. O que a informao?
1.5.1.3. O que conhecimento?
1.5.2.Viso geral Dados, Informao e Conhecimento:
1.5.3. Gesto do Conhecimento
1.5.4. Administrao de Dados
1.5.5. Sistemas de Informao em Organizaes.
1.5.6. Componentes de Sistemas de Informao.
Capitulo 2 - Data Warehouse
2.1. Introduo
2.2. O que um Data Warehouse?
2.2.1. Orientado por assunto
2.2.2. Integrado
2.2.3. Histrico
2.2.4. No voltil
2.3. Um pouco mais sobre Data Warehouse
2.4. Construindo um Data Warehouse
2.4.1. Arquitetura de um Data Warehouse
2.4.1.1. Viso Conceitual
2.4.1.2. Viso Fsica (em Camadas)
2.4.2. Estrutura Fsica dos Dados do DW
2.4.2.1. Arquitetura de Duas Camadas
2.4.2.2. Arquitetura de Trs Camadas
2.4.3. OLTP versus OLAP
2.4.4. Projeto e Desenvolvimento de Sistemas de Data Warehouse
2.4.4.1. Funes dos Componentes da Equipe
2.4.4.2. Anlise entre Model. Dimensional e Model. Relacional
2.4.4.3. Problemas Encontrados no Desenvolvimento de Data Warehouses
2.4.5. Melhorando a performance do Data Warehouse
2.4.5.1. Intercalao de Tabelas
2.4.5.2. Introduo de Informaes Redundantes
2.4.5.3. Separao de Dados
2.4.6. Componentes dos Sistemas de DW
2.4.6.1. O Sistema Gerenciador de Banco de Dados
2.5. O Ciclo de vida do desenvolvimento de um Data Warehouse
2.6. Consideraes Iniciais para a criao de um Data Warehouse
2.7.Dados Operacionais
(11) 3531 6550 - www.strattus.com.br 1

Capitulo 3 - Modelagem Dimensional
3.01. Introduo
3.02. Modelagem de dados
3.03. Modelagem Dimensional
3.04. Processo da Modelagem Dimensional
3.05. Processo de Modelagem de um Data Warehouse
3.06. Tipos de Arquitetura
3.06.1. Arquitetura "Top-Down"
3.06.2. Arquitetura "Bottom-Up"
3.06.2.1 Enterprise Data Mart Architecture (EDMA)
3.06.2.2 Data Storage/Data Mart (DS/DM)
3.06.3. Arquitetura intermediria
3.07. Data Marts
3.08. Gerando o modelo dimensional atravs do StarSchema
3.08.1. Variaes do StarSchema
3.08.2. Vantagens do modelo StarSchema
3.08.3. Tabela de fatos
3.08.3.1. Fatos com produtos heterogneos
3.08.3.2. Classificao de atributos em uma tabela de Fatos
3.08.4. Tabela de Dimenso
3.08.4.1. Dimenses com Itens Heterogneos
3.08.4.2. Dimenses Descaracterizadas
3.08.4.3.Tratamento de dimenses e fatos com cardinalidade
3.08.4.4.Tcnicas de rastreamento de alteraes
3.08.4.5. Criando novas chaves
3.08.4.6. Criando de Mini - dimenses
3.08.5. Granularidade
3.08.6. Medidas de derivao
3.09. Data Mining
3.10. Metadados
3.11. OLAP
3.11.1. Gerao de Consultas (Queries)
Capitulo 4 Criando um Data Mart de Vendas
No disponvel
Capitulo 5 Especiais
No disponvel

Business Intelligence no algo que se compra de um fornecedor, mas um

objetivo alcanado por uma organizao.
Luiz Cmara, Presidente da InfoBuild Brasil
Captulo 1 O que Business Intelligence?
1.1. Introduo
Com o passar dos anos a necessidade de conhecimento, vem crescendo cada vez
mais neste mundo globalizado. Acredito que podemos chamar este sculo de A
ERA DA INFORMAO. Com isso, o volume de dados e seus devidos
repositrios vem se multiplicando, se tornando armazns de dados isolados que
dificultam a anlise e a compreenso verdadeira de todo o negcio.
Ou seja, ns os profissionais de tecnologia, envolvidos nas camadas de

gerenciamento e anlise de dados, temos como principal objetivo ajudar as
empresas a transformar os grandes volumes de registros em informaes
relevantes para a empresa, suportando os processos de deciso estratgica e
gerando vantagens competitivas no mercado.
Toda esta habilidade chamada de Business Intelligence (BI), que apoiada por
ferramentas de tecnologias adequadas, permite organizar dados dispersos em
uma empresa, de forma a torn-los inteligveis e depois estud-los com o objetivo
de gerar o Conhecimento e Inteligncia, a serem utilizados no desenvolvimento
estratgico de aes, que beneficiam todo o negcio.
Como exemplo deste emaranhado e complexo sistema de informao, podemos

citar os tradicionalmente sistemas legados das empresas ERP (Enterprise
Resource Planning), bem como as fontes externas de dados e outras fontes de
informao (Planilhas, Arquivos de lotes, etc).
Tudo isso faz com que as organizaes empenhem seus esforos na construo
de ferramentas, que atravs de uma anlise refinada do negcio, mais os
conceitos de Business Intelligence, integrados a crescente tecnologia de softwares
voltados a esta rea, possam monitorar e acompanhar a evoluo das tomadas de
decises, com preciso e rapidez.
O objetivo desta obra conscientizar todos os escales das empresas privadas,

bem como os rgos pblicos em geral, qual a importncia no tratamento da
informao e das reais necessidades de investimento nos projetos de Business
Intelligence.
Digo com propriedade que depois de meus vinte e sete anos como desenvolvedor
de ERPs legados, como documentador e principalmente como especialista em

reporting que; a busca de novas oportunidades no mercado, bem como a gesto

ideal para nossos negcios, no vira sem que tenhamos um bom e estruturado
projeto de BI, ou seja, centralizar as informaes, de forma racional e orientada s
necessidades do nosso negcio. Essa sem dvida alguma, a melhor forma de se
tomar decises estratgicas.
No decorrer desta obra, o amigo leitor vai conhecer um pouco mais sobre
Business Intelligence, vai acompanhar conceitualmente e na prtica a criao de
um Data Warehouse e ver como eles so fundamentais em qualquer projeto de BI.
Vai visualizar como a partir destas informaes armazenadas em formato simples
e organizadas, podem ser realizadas as anlises para a tomada de decises
estratgicas relacionadas ao seu negcio.
Tambm vai conhecer o conceito dos poderosos Data Marts e a fantstica

modelagem dimensional, bem como as tecnologias de OLAP, que sero
amplamente comparadas com a OLTP.
Aqui o amigo leitor ainda avaliar os conceitos do Balanced Scorecard e de gesto

do conhecimento, bem como poder testar na prtica a criao de um Data
Warehouse, atravs de um pequeno projeto de BI, analisado e demonstrado em
todas as suas etapas.
1.2. Business Intelligence Conceitos e anlises
O mercado mundial como um todo, no para de comentar e divulgar sobre a

coqueluche do momento, Business Intelligence; suas aplicaes e solues
tecnolgicas disponveis no mercado. Porm, eu lhe pergunto amigo leitor, ser
que realmente sabemos sobre o que estamos falando?
Acredito que precisamos, antes de qualquer coisa, ter a conscincia real sobre o
conceito de BI, para o qual existem os mais diversos tipos de anlises e conceitos
na atualidade.
Nosso primeiro passo ser o entendimento dos dois termos que compem o
referido conceito: Business (negcio) e Intelligence (inteligncia)
O primeiro, quer dizer a intermediao de uma atividade comercial com fins

lucrativos, quando se trata do mundo empresarial. O segundo se refere
faculdade de aprender ou compreender; capacidade de resolver situaes
complexas e problemticas, mediante a reestruturao da informao perceptiva
(Fsica).
Com a juno dos dois termos acima, correto supor que a inteligncia do
negcio est ligada intrinsecamente capacidade das pessoas em posies
estratgicas dentro de uma corporao e que esto diretamente ligadas ao
negcio. Pessoas estas, com poder de deciso para adaptar, implementar ou

alterar o rumo da empresa (estrutura, recursos humanos, financeiros, materiais,

etc.) ou externamente (mercado, concorrncia, econmico, etc.).
O conceito de BI tem como principal objetivo, auxiliar estes homens e mulheres a

aprimorar o processo de tomada de deciso, atravs do tratamento das bases de
dados existentes.
O BI engloba o uso de ferramentas sofisticadas, que fazem parte da rea de

pesquisa como, por exemplo, a Inteligncia Artificial (IA). Estas ferramentas
proporcionam alm de informaes mais detalhadas, uma base de conhecimento
extensa, modelada e racionalizada, que conseqentemente dissemina o
conhecimento obtido no tratamento da base de dados, que nada mais so do que
as prticas oriundas das decises tomadas por toda a empresa.
As empresas fazem parte do mundo dos negcios e esse visa eternamente ao

lucro, ao retorno dos capitais investidos no menor tempo possvel. Numa realidade
competitiva como esta, as informaes estratgicas assumem um papel
fundamental para o sucesso dessa empreitada.
bvio que no podemos deixar de citar a enorme quantidade de informaes

que so despejadas sobre ns diariamente. Desta forma precisamos de
mecanismos eficientes que nos ajudem a criar e monitorar critrios para
selecionarmos e organizarmos as informaes que realmente nos interessam.
Como no poderia deixar de ser, os sistemas de informaes prestam uma grande

ajuda nesse sentido. Esse sistema proporciona lucros quando permite que uma
maior quantidade de bens sejam produzidos, uma maior quantidade de clientes
sejam atendidos, a satisfao dos mesmos sejam conquistadas, e finalmente,
permite uma melhor alocao dos recursos disponveis.
Quando a empresa consegue obter essas informaes rapidamente e de forma

estruturada, ela sem dvida sair na frente de seus concorrentes, descobrindo os
problemas com seus produtos e servios, possibilitando corrigi-los com maior
velocidade e eficincia. A informao estratgica proporciona saber se os seus
clientes esto satisfeitos e poder definir novas estratgias para expanso de sua
empresa no mercado.
Mas, o ponto mais importante nessa mistura de tecnologias a empresa poder

direcionar todo seu capital intelectual para a sua devida funo, que pensar. Os
gerentes e diretores podero ter as informaes rapidamente e tambm tero
mais tempo para melhorarem todos seus processos e analisarem mais os seus
dados, que passaro a ser valiosas informaes. A a Tecnologia da Informao
(TI) estar exercendo seu grande papel, que o de fornecer informaes de
qualidade e deixar de ser uma armazenadora de dados.

O Business Intelligence pode ser entendido como um leque conceitual que

envolve a Inteligncia Competitiva (CI), a Gerncia de Conhecimento (KMS) e a
Internet Business Intelligence (IBI), pesquisa e anlise de mercado, relacionados
nova era da Informao, dedicada a captura de informaes e conhecimentos que
permitem as organizaes competirem com maior eficincia e exatido.
Isso bom para cada um de ns clientes e consumidores. E melhor ainda para os

profissionais que fazem parte dessas grandes empresas, pois alm de nos
capacitarmos ainda mais, conseguiremos ajudar a nossas instituies
coorporativas a crescerem e chegarem a excelncia de seus negcios.
Segundo Gartner Group:
A maior ameaa das empresas da atualidade o desconhecimento... O Business

Intelligence se empenha em eliminar as dvidas e a ignorncia das empresas
sobre suas informaes, aproveitando os enormes volumes de dados coletados
pelas empresas.
Por fim, o BI ou Inteligncia Empresarial tem como principal objetivo integrao

dos aplicativos e tecnologias para extrair e analisar os dados corporativos de
maneira simples, no formato correto e no tempo certo, para que a empresa possa
tomar decises melhores e mais rpidas, sempre buscando auxiliar o executivo
em seus negcios.
1.3. Business Intelligence - Histrico
Ao contrrio do que se possa imaginar, o conceito de Business Intelligence no

recente. Civilizaes antigas j utilizavam esse princpio h milhares de anos,
quando cruzavam informaes obtidas junto natureza em benefcio prprio.
Observar e analisar o comportamento das mars, os perodos de seca e de

chuvas, a posio dos astros, entre outras, eram formas de obter informaes que
eram utilizadas para tomar as decises que permitissem a melhoria de vida de
suas respectivas comunidades.
O mundo mudou desde ento, mas o conceito permanece o mesmo. A

necessidade de cruzar informaes para realizar uma gesto empresarial eficiente
hoje uma realidade to verdadeira quanto no passado foi descobrir se a alta da
mar iria propiciar uma pescaria mais abundante.
Pela viso da tecnologia, a era que podemos chamar de "pr-BI" est num
passado no muito distante, algo entre trinta ou quarenta anos atrs. Nesta poca,
quando os computadores deixaram de ocupar salas gigantescas, na medida em
que diminuram de tamanho e ao mesmo tempo, as empresas passaram a
perceber os dados como uma possvel e importante fonte geradora de
informaes decisrias.

No entanto, naquela poca ainda no existiam recursos eficientes que

possibilitassem uma anlise consistente desses dados para a tomada de deciso.
Era possvel reunir informaes de maneira integrada, fruto de sistemas
transacionais estabelecidos com predominncia em dados relacionais, mas que,
reunidos como blocos fechados de informao, permitiam uma viso da empresa,
mas no traziam ganhos decisrios ou negociais.
Estamos falando do final dos anos 60, perodo em que cartes perfurados,
transistores e linguagem COBOL eram a realidade da Informtica. Era a poca em
que se via o computador como um desconhecido, um vislumbre de modernidade,
mas que ainda parecia estar em uma realidade muito distante.
O panorama comeou a mudar na dcada de 70, com o surgimento das

tecnologias de armazenamento e acesso a dados, Direct Access Storage Device
(DASD), dispositivo de armazenamento de acesso direto, e o Sistema Gerenciador
de Banco de Dados (SGBD), duas siglas cujo principal significado era o de
estabelecer uma nica fonte de dados para todo o processamento.
A partir da o computador passou a ser visto como um coordenador central para

atividades corporativas e o banco de dados foi considerado um recurso bsico
para assegurar a vantagem competitiva no mercado.
No incio dos anos 90, a maioria das grandes empresas contava somente com
Centros de Informao (CI) que embora mantivessem estoque de dados,
ofereciam pouqussima disponibilidade de informao. Mesmo assim, os CI
supriam, de certa forma, as necessidades de executivos e detentores das tomadas
de deciso, fornecendo relatrios e informaes gerenciais.
O mercado passou a se comportar de modo mais complexo e a tecnologia da

informao progrediu rumo ao aprimoramento de ferramentas de software, as
quais ofereciam informaes precisas e no momento oportuno para definir aes
que tinham como foco a melhoria do desempenho no mundo dos negcios.
No inicio da dcada de 90, surgiu o Data Warehouse (DW) que uma grande
base de dados de informao, ou seja, um nico repositrio de dados.
Considerado pelos especialistas no assunto, como o elemento principal para a
execuo prtica de um projeto de BI.
No entanto, quando se trata de BI, as opinies nem sempre so unnimes. Na

avaliao de alguns consultores importante que a empresa que deseja
incorporar ferramentas de anlise disponha de um repositrio especfico para
reunir os dados j transformados em informaes
Esse repositrio no precisa ser necessariamente, um DW, mas algo menos

complexo como, por exemplo, um Data Mart (Um banco de dados ou parte dele,
desenhado de forma personalizada para departamentos), ou um banco de dados
relacional comum, mas separado do ambiente transacional (operacional) e

dedicado a armazenar as informaes usadas como base para a realizao de

diferentes analises e projees.
Como j foi mencionado acima, o conceito de Business Intelligence muito mais

antigo do que se imagina. Mas o desenvolvimento tecnolgico ocorrido a partir da
dcada de 70 e nos anos posteriores, que possibilitou a criao de ferramentas
que vieram a facilitar todo o processo de captao, extrao, armazenamento,
filtragem e disponibilidade personalizada dos dados.
Isso fez com que o setor corporativo passasse a se interessar cada vez mais pelas
solues de BI, principalmente por volta do final de 1996, quando o conceito
comeou a ser difundido como um processo de evoluo do Executive Information
Systems (EIS - Sistema de informaes executivas), um sistema criado no final da
dcada 70, a partir dos trabalhos desenvolvidos pelos pesquisadores do
Massachusets Institute of Tecnology/EUA (MIT).
O EIS na verdade, um software que objetiva fornecer informaes empresariais

a partir de uma base de dados. uma ferramenta de consulta s bases de dados
das funes empresariais para a apresentao de informaes de forma simples e
amigvel, atendendo s necessidades dos executivos da alta administrao
principalmente. Permite o acompanhamento dirio de resultados, tabulando dados
de todas as reas funcionais da empresa para depois exibi-los de forma grfica e
simplificada, sendo de fcil compreenso para os executivos que no possuem
profundos conhecimentos sobre tecnologia. Em termos simples o EIS permite a
esses profissionais o acesso amigvel a uma srie de informaes pela via
eletrnica, apresentadas de forma clara e visualmente atraente.
Com o passar dos anos o termo Business Intelligence ganhou maior abrangncia,
dentro de um processo natural de evoluo, como o prprio EIS, e mais as
solues Decision Support System (DSS - Sistema de Suporte Deciso),
Planilhas Eletrnicas, Geradores de Consultas e de Relatrios, Data Marts, Data
Mining, Ferramentas OLAP, entre tantas outras que tm como objetivo promover
agilidade comercial, dinamizar a capacidade de tomada de decises.
A histria do Business Intelligence tambm est profundamente atrelada ao ERP

sigla que representa os sistemas integrados de gesto empresarial cuja funo
facilitar os processos operacionais das empresas. Esses sistemas registram,
processam e documentam cada fato novo na empresa e distribuem as
informaes de maneira clara e segura, em tempo real.
Mas as empresas que implantaram estas solues logo se deram conta de que
apenas armazenar grande volume de dados, no lhes serviriam de nada, j que
essas informaes se encontravam repetidas, incompletas e espalhadas em
vrios repositrios dentro da corporao. Percebeu-se que era preciso dispor de
ferramentas que permitissem reunir esses dados em uma nica base de
informao e trabalh-los de forma, que possibilitassem realizar diferentes
anlises sob variados ngulos.

Tradicionalmente, o Business Intelligence pertenceu ao domnio do pessoal de TI

e dos especialistas em pesquisa de mercado, responsveis pela extrao de
dados, pela implantao de processos e pela divulgao dos resultados aos
executivos responsveis pela tomada de decises. Mas com o crescimento da
Internet tudo mudou. Hoje, a rede permite disponibilizar solues de BI para um
nmero cada vez maior de pessoas dentro e fora das grandes corporaes.
1.4. Business Intelligence Benefcios
O BI consegue trazer inmeros benefcios para as organizaes que o utilizem de

forma correta. Veja abaixo uma lista destes benefcios.
Antecipar mudanas no mercado;

Antecipar aes dos competidores;
Descobrir novos ou potenciais competidores;
Aprender com os sucessos e as falhas dos outros;
Conhecer melhor suas possveis aquisies ou parceiros;
Conhecer novas tecnologias, produtos ou processos que tenham impacto
no seu negcio;
Conhecer sobre poltica, legislao ou mudanas regulamentais que
possam afetar o seu negcio;
Entrar em novos negcios;
Rever suas prprias prticas de negcio;
Alinhar projetos de tecnologia com as metas estabelecidas pelas empresas
na busca do mximo retorno do investimento;
Propiciar alternativas de investimento em tecnologia dentro do contexto
estratgico, tecnolgico e financeiro da empresa;
Ampliar a compreenso das tendncias dos negcios, propiciando melhor
consistncia no momento de deciso de estratgias e aes;
Permitir uma anlise de impacto sobre rumos financeiros e organizacionais
para criar mudanas nas iniciativas gerenciais;
Facilitar a identificao de riscos e gerar segurana para migrao de
estratgias, criando maior efetividade nas implementaes dos projetos;
Abrir um caminho orientado para implantaes futuras de novas
tecnologias, estabelecendo prazos e focando o oramento dentro das
perspectivas e objetivos da empresa;
Gerar, facilitar o acesso e distribuir informao de modo mais abrangente
para obter envolvimento de todos os nveis da empresa.
Podemos citar exemplos mais especficos como o setor comercial, marketing,

economia e finanas, como as primeiras e mais promissoras reas para a
aplicao dos projetos de BI.

Na rea comercial o BI oferece os seguintes benefcios:
Melhora no prognstico de vendas;

Visibilidade contbil abrangente;
Integrao entre oramento de anlise; melhor compreenso da
segmentao do mercado;
Flexibilidade e interao dos relatrios financeiros; Melhoria nas decises
de distribuio de produtos.
Benefcios para a rea de marketing:
Campanha de marketing dirigido;

Informaes personalizadas de cliente;
Comportamento e freqncia de compra ou preferncias so obtidos de
uma forma rpida e fcil com a utilizao das ferramentas de BI;
Fidelizao dos clientes; Mala direta e pblico alvo.
Benefcios para a rea de economia e finanas:
Aes personalizadas, avaliao de riscos e de oportunidades futuras;

Anlise de crdito e de riscos em empresas do setor financeiro;
Controle de fraude de empresas de seguro.
1.5. Gesto do Conhecimento e Sistemas de Informao
Antes de iniciarmos com o desenvolvimento e as aplicaes referentes ao projeto

de BI, vamos falar um pouco sobre a gesto do conhecimento e os sistemas de
informao, j que na minha humilde viso, nenhuma empresa conseguir criar
um bom DW, sem que seus processos e aes no estejam baseados nestes dois
conceitos.
O conceito de Gesto do Conhecimento surgiu no inicio da dcada de 90 em que

a Gesto do Conhecimento no era mais um tipo de moda de eficincia
operacional. Agora a GC fazia parte da estratgia empresarial.
1.5.1. Conceitos bsicos de Gesto do Conhecimento
Sem compreender o conceito de dado, informao e conhecimento, no

conseguiremos apresentar o processo de Gesto do Conhecimento.

1.5.1.1. O que dado?
Dado pode ter significados distintos, dependendo do contexto no qual a palavra

utilizada. Para uma organizao, dado o registro estruturado de transaes.
informao bruta, descrio exata de algo, ou de algum evento. Os dados em si

no so dotados de relevncia ou propsitos, mas so importantes porque so a
matria essencial para a criao da informao.
1.5.1.2. O que a informao?
Informao uma mensagem com dados que fazem diferena, podendo ser
audvel ou visvel. onde existe um emitente e um receptor. o resultado mais
importante da produo humana.
Definir informao no uma tarefa fcil. Se partirmos da clssica distino entre
dados, informao e conhecimento encontraremos certa impreciso.
Informao um termo que envolve todas as trs palavras, e ainda serve como
conexo entre os dados brutos e o conhecimento que no decorrer das anlises
pode ser obtido.
Esses termos s vezes so utilizados de forma inadequada, o que podemos

constatar quando verificamos que durante muito tempo as pessoas se referiam
aos dados como informao.
O significado da informao e seus propsitos exigem de imediato, a redefinio

no apenas das tarefas que so realizadas com a ajuda desta informao, mas
tambm dos processos que as utilizam como insumos.
Veja que as pessoas transformam dados em informao. Ao contrrio dos dados a

informao exige anlise. Este sem dvida o maior desafio imposto aos
especialistas da T.I.
1.5.1.3. O que conhecimento?
Conhecimento o estgio mais avanado da informao, mais valioso, mais difcil

de gerenciar e de se obter. valioso precisamente porque se trata de uma
informao que recebeu um significado, uma interpretao. Algum indivduo ou um
grupo refletiu sobre conhecimento, acrescentou a ele sua prpria sabedoria,
considerou suas implicaes mais amplas.
O conhecimento, muitas vezes tcito existe simbolicamente na mente humana

e difcil de explicitar. O homem tenta insistentemente incorporar conhecimento
s mquinas, mas os resultados ainda so tmidos e sua aplicao restrita.

O Conhecimento deriva da informao assim como esta, dos dados. O

conhecimento no puro nem simples; mas uma mistura de elementos, fluido
e formalmente estruturado; intuitivo e, portanto, difcil de ser colocado em
palavras ou de ser plenamente entendido em termos lgicos. Ele existe dentro das
pessoas e por isso complexo e imprevisvel.
O Conhecimento humano pode ser classificado em dois tipos: Conhecimento

explcito e Conhecimento tcito. NONAKA e TAKEUSHI [01].
Conhecimento explcito: o que pode ser articulado na linguagem formal,

inclusive em afirmaes gramaticais, expresses matemticas, especificaes,
manuais etc., facilmente transmitido, sistematizado e comunicado. Ele pode ser
transmitido formal e facilmente entre os indivduos. Esse foi o modo dominante de
conhecimento na tradio filosfica ocidental.
Conhecimento tcito: difcil de ser articulado na linguagem formal, um tipo de

conhecimento mais importante. o conhecimento pessoal incorporado
experincia individual e envolve fatores intangveis como, por exemplo, crenas
pessoais, perspectivas, sistema de valor, intuies, emoes e habilidades.
considerado como uma fonte importante de competitividade entre as
Organizaes.
S pode ser avaliado por meio da ao. Portanto, os conhecimentos explcito e

tcito so unidades estruturais bsicas que se complementam e a interao entre
eles a principal dinmica da criao do conhecimento na organizao de
negcio.
1.5.2. Viso geral Dados, informao e conhecimento:
Dados Informao Conhecimento

Simples observaes sobre o Dados dotados de Informao valiosa da mente
estado do mundo relevncia e propsito humana. Inclui reflexo, sntese e
contexto.
- Facilmente estruturado - Requer unidade de anlise - De difcil estruturao
- Facilmente obtido por - Exige consenso em relao - De difcil captura em mquinas
mquinas ao significado - Freqentemente tcito
- Freqentemente - Exige necessariamente a - De difcil transferncia
quantificado mediao humana
- Facilmente transfervel
A evoluo no processo dados informao - conhecimento exige cada vez mais

o envolvimento humano. Os computadores so timos para nos ajudar a lidar com
dados, mas quando evolumos para informao a adequao diminui, tornando-se
crtica com o conhecimento.

1.5.3. Gesto do conhecimento
A Gesto do Conhecimento o processo de identificao, criao e aplicao dos

conhecimentos que so estratgicos na vida de uma empresa. Permite a
organizao como um todo saber o que ela SABE. A gesto do conhecimento
leva as organizaes a mensurar com mais segurana a sua eficincia, tomar
decises acertadas com relao a melhor estratgia a ser adotada em relao a
seus clientes, concorrentes, canais de distribuio e ciclo de vida de produtos e
servios.
1.5.4. Administrao de dados
Saber administrar dados trabalhar o dado como base estratgica da

organizao, representando a empresa, independentemente dos processos das
diferentes unidades que utilizem o dado.
A administrao de dados (Gesto de dados) pode ser definida como uma funo
da organizao responsvel por desenvolver e administrar centralizadamente
estratgias, procedimentos, prtica e planos capazes de fornecer dados
corporativos necessrios, quando necessrios, revestidos de integridade,
privacidade, documentao e compartilhamento. SERRA [02]
A administrao de dados em uma organizao pode ter uma atuao ampla,

participando efetivamente do Planejamento Estratgico Empresarial junto
direo das empresas onde permitiria detectar, entre outros, as necessidades de
informao futuras, pois estaria planejando melhor suas bases de dados em
atendimento aos negcios da corporao e atuando fortemente na administrao
dos dados informatizados e os no informatizados espalhados pelos diversos
setores da organizao.
Portanto, ao administrador de dados, cabe: procurar identificar, descrever

(documentar) e modelar (estruturar) os dados - chave a serem armazenados e
gerenciados (manipulados), alm de cuidar das adaptaes impostas pelo
Sistema Gerenciador de Banco de Dados Relacional (SGBDR) e dos aspectos de
desempenho e segurana.
1.5.5. Sistemas de informao em organizaes
A tecnologia da informao esta redefinindo os fundamentos das regras de

negcios. Atendimento ao cliente, operaes, estratgias de produto e de
marketing e distribuio dependem muito, ou s vezes at totalmente, dos
Sistemas de Informao (SI). A tecnologia da informao e seus custos passaram
a fazer parte integralmente do dia-a-dia das empresas.

indiscutvel que toda organizao tm pelo menos dois problemas genricos:

como gerenciar as foras e grupos internos que geram seus produtos e servios, e
como lidar com clientes, legislaes, concorrentes e tendncias gerais scios
econmicas em seu ambiente. A principal razo pela qual so construdos os
sistemas de informao para resolver problemas organizacionais e para reagir a
uma mudana no ambiente LAUDON [03].
Alguns sistemas de informao tratam unicamente de problemas internos, alguns

de assuntos puramente externos e outros cumprem os dois papis. So
classificados costumeiramente pela especialidade funcional a que se destinam e
pelo tipo de problema. Nenhum sistema sozinho rege todas as atividades de uma
empresa.
Os sistemas em nvel estratgico ajudam os gerentes seniores a planejar as aes

de longo prazo.
Os sistemas tticos auxiliam os gerentes de nvel mdio a supervisionar e

coordenar as atividades dirias da empresa.
Os especialistas e funcionrios de escritrio utilizam sistemas de conhecimento

para projetar, racionalizar servios e lidar com documentos, enquanto os sistemas
operacionais tratam das atividades dirias de produo e servio.
Imagem 01
Um sistema pode ser definido como um conjunto de partes coordenadas que

concorrem para a realizao de um conjunto de objetivos, seguindo um plano.
Qualquer sistema pode ser encarado como um subsistema de um maior, sendo
isso denominado hierarquia de sistemas. POLLONI [04].

Segundo LAUDON [*]:
Um sistema de informao (S.I.) pode ser definido como um conjunto de

componentes inter-relacionados trabalhando juntos para coletar, recuperar,
processar, armazenar e distribuir informao com a finalidade de facilitar o
planejamento, o controle, a coordenao, a anlise e o processo decisrio em
empresas e outras organizaes.
Um sistema um grupo de componentes inter-relacionados que trabalham juntos

de encontro a uma meta comum recebendo os resultados e produzindo resultados
em um processo organizado de transformao.
Um sistema dessa ordem, s vezes chamado de sistema dinmico, possui trs

componentes ou funes bsicas em interao:
O contedo dos sistemas de informaes varia de empresa para empresa, face s

necessidades especficas de cada entidade. Em geral contm informao sobre
pessoas, lugares e coisas de interesse no ambiente ao redor da organizao e
dentro da prpria organizao. Sua principal tarefa transformar a informao em
uma forma utilizvel para a coordenao do fluxo de trabalho de uma empresa,
auxiliando a tomada de decises em todos os nveis e a previso e soluo de
assuntos complexos.
Trs atividades bsicas compem um sistema de informaes: entrada (ou input),

processamento e sada (ou output). A entrada envolve a captao ou coleta de
fontes de dados brutos de dentro da organizao ou de seu ambiente externo. So
exemplos de dados: total de unidades vendidas ou compradas, datas, descrio
de clientes e produtos.
A entrada envolve a captao e reunio de elementos que entram no sistema para

serem processados.
O processamento envolve processos de transformao que convertem Resultado

(entrada) em produto. Entre os exemplos se encontram um processo industrial, o
processo da respirao humana ou clculos matemticos.
A sada envolve a transferncia de elementos produzidos por um processo de

transformao at seu destino final. Produtos acabados, servios humanos e
informaes genricas devem ser transmitidos a seus usurios.
Deve-se ressaltar que um sistema de informao pode ser formal ou informal,

organizacional ou individual, baseado em computadores (SIBC) ou no. LAUDON [03].
Os SIBC so sistemas formais que se baseiam em definies de dados de

procedimentos, mutuamente aceitos e relativamente fixos, para a coleta,
armazenamento, processamento e distribuio de informao. Por exemplo, um

arquivo manual de nomes e endereos de clientes ou um catlogo alfabtico por

cartes em uma biblioteca um sistema de informao formal, pois estabelecido
por uma organizao e est de acordo com regras e procedimentos
organizacionais; isto quer dizer que cada entrada no sistema tem o mesmo
formato de informao e o mesmo tipo de contedo.
Os sistemas informais, ao contrrio, no tm essas caractersticas. No h acordo

sobre que informao existe como ser armazenada e o que ser armazenado ou
processado. Muitos no deixam de ser importantes, na realidade, so muito
poderosos e flexveis. Exemplos desses sistemas informais so as redes de boato
no escritrio, grupos de amigos, estudantes e ainda pessoas com interesses
comuns que trocam informaes livremente sobre um grande nmero de
assuntos, tpicos e personalidades mudando-os constantemente.
Os SIBC so montados com a finalidade de resolver problemas importantes na

organizao. De acordo com POLLONI [*], um SIBC eficaz, deve:
1. Produzir informaes realmente necessrias, confiveis, em tempo hbil e

com custo condizente, atendendo aos requisitos operacionais e gerenciais
de tomada de deciso;
2. Tem por bases diretrizes capazes de assegurar a realizao dos objetivos,

de maneira direta, simples e eficiente;
3. Integrar-se estrutura da organizao e auxiliar na coordenao das

diferentes unidades organizacionais (departamentos, divises, diretorias
etc.) por ele interligadas;
4. Ter um fluxo de procedimentos (internos e externos ao processamento)

racional, integrado, rpido e de menor custo possvel;
5. Contar com dispositivos de controle interno que garantam a confiabilidade

das informaes de sada e adequada proteo aos dados controlados pelo
Sistema;
6. Finalmente, ser simples, seguro e rpido em sua operao.
1.5.6. Componentes de Sistemas de Informao.
Os mais poderosos sistemas de informao da atualidade usam tecnologia da

Informao para executar parte das funes de processamento, isto no quer
dizer que apenas investindo em computadores teremos excelentes sistemas.
Um sistema bem sucedido tem dimenses organizacional e humana atreladas aos

componentes tcnicos.

Ele existe para atender as necessidades organizacionais, incluindo problemas

apresentados pelo ambiente externo criado por tendncias polticas,
demogrficas, econmicas e sociais LAUDON [9].
As organizaes devem moldar seus sistemas de informaes de acordo com

suas necessidades, hierarquias, estrutura funcional e sua cultura especfica.
Diferentes nveis e diferentes especialidades em uma organizao criam

interesses e pontos de vista diferentes, que freqentemente conflitam entre si.
Os sistemas de informao devem responder e resolver estes conflitos internos

alm de problemas criados pelo ambiente externo.
As pessoas so os usurios dos sistemas de informao sob o enfoque de

fornecimento de insumos e utilizao de seus produtos, tudo integrado ao seu
ambiente de trabalho. Suas atitudes a respeito de seus empregos, empregadores
ou da tecnologia de computao podem ter um efeito poderoso sobre sua
capacidade de usar sistema de informao de modo produtivo.
Os sistemas de processamento de transaes so exemplos importantes de

sistemas de apoio s operaes que registram e processam dados resultantes de
transaes das empresas. Eles processam transaes de dois modos bsicos.
No processamento em lotes, os dados das transaes so acumulados durante

certo tempo e periodicamente processados.
No processamento em tempo real (ou on-line), os dados so processados
imediatamente depois da ocorrncia de uma transao. Os sistemas de ponto -de
- venda, por exemplo, em muitas lojas de varejo utilizam terminais eletrnicos no
caixa para capturar e transmitir eletronicamente dados de vendas por conexes de
telecomunicaes para centros regionais de computao para processamento
imediato (tempo real) ou a cada noite (lote).
Os sistemas de controle de processo monitoram e controlam processos fsicos.
Uma refinaria de petrleo, por exemplo, utiliza sensores eletrnicos conectados a

computadores para monitorar continuamente os processos qumicos e fazer
ajustes imediatos (em tempo real) que controlam o processo de refino.
Os sistemas colaborativos aumentam as comunicaes e a produtividade de

equipe de projeto, por exemplo, podem usar correio eletrnico para enviar e
receber mensagens eletrnicas e videoconferncia para realizar reunies
eletrnicas e coordenar suas atividades.
A tecnologia o meio empregado para transformao e organizao dos dados

para utilizao das pessoas. No necessariamente um sistema de informao
computadorizado, podendo ser um sistema manual, tal como um arquivo de

fichrios, porm os computadores substituram a tecnologia manual de

processamento de grandes volumes de dados e de trabalhos complexos de
processamento. Os sistemas baseados em computadores tm como componentes
tcnicos:
O hardware de computador: o equipamento fsico usado para as tarefas

de entrada, processamento e sada em um sistema de informao.
composto pela unidade de processamento do computador e nos vrios
dispositivos de entrada (teclado, scanner, mouse, Etc.).
(Dispositivos de reconhecimento de caracteres pticos OCR, dispositivos

de controle de voz, sensores), sada (impressora, plotters, terminais de
vdeo e outros tipos de dispositivos) e armazenamento (Disco magntico e
disco tico), alm dos meios fsicos que interligam estes dispositivos.
O software do computador: Consiste em instrues pr-programadas que

coordenam o trabalho dos componentes do hardware para que executem
os processos exigidos pelos vrios sistemas de informao.
A tecnologia de armazenamento: serve para organizar e armazenar os

dados utilizados por uma empresa. A tecnologia de armazenamento inclui
os meios fsicos para armazenar os dados, assim como o software que rege
a organizao de dados nesses meios fsicos.
A tecnologia de comunicao: usada para conectar pontos diferentes do

hardware e para transferir dados de um ponto a outro via redes.
Quando os sistemas de informao se concentram em fornecer informao e

apoio para a tomada de deciso eficaz pelos gerentes, eles so chamados
sistemas de apoio gerencial. Fornecer informao e apoio para a tomada de
deciso por parte de todos os tipos de gerentes (dos altos executivos, aos
gerentes de nvel mdio e at os supervisores) uma tarefa complexa. Em termos
conceituais, vrios tipos principais de sistemas de informao apiam uma serie
de responsabilidade administrativa do usurio final:
1. Sistemas de informao gerencial;

2. Sistemas de apoio deciso;
3. Sistemas de informao executiva.
Os sistemas de informao gerencial fornecem informao na forma de relatrios

e exibies em vdeo para os gerentes. Os gerentes de vendas, por exemplo,
podem utilizar seus terminais de computador para obter visualizaes
instantneas sobre os resultados de vendas de seus produtos e acessar relatrios
semanais de analise de vendas que avaliam as vendas realizadas por cada
vendedor.

Os sistemas de apoio deciso fornecem suporte computacional direto aos

gerentes durante o processo de deciso. Os gerentes de propaganda podem
utilizar um pacote de planilhas eletrnicas para realizar analise de simulao
quando testam o impacto de oramentos alternativos de propaganda sobre as
vendas previstas para novos produtos. Os sistemas de informao executiva (EIS)
fornecem informaes critica em quadros de fcil visualizao para uma
multiplicidade de gerentes.
Biografia
[01] NONAKA e TAKEUCHI, 1997, IKUJIRO NONAKA, E HIROKATA TAKEUCHI, 1997, Criao de conhecimento na
Empresa, Editora Campus, Rio de Janeiro, Brasil.
[02] SERRA, 2002, LARCIO SERRA, 2002, A Essncia do Business Intelligence, Editora Berkeley, So Paulo,
Brasil.
[03] LAUDON, 2002, LAUDON, LAUDON, 2002, Gerenciamento de Sistemas de Informao,
[04] POLLONI, 2001, ENRICO PLLONI e TIBOR SIMCSIK, 2002, Tecnologia da Informao Automatizada, Editora
Futura, So Paulo, Brasil.

Captulo 2 Data Warehouse?
2.1. Introduo
Desde sua apario no incio da dcada de 90, e at os dias de hoje, o conceito e

a operao de um DW (Data Warehouse), saram do mbito terico, acadmico,
para a rea empresarial, notando-se uma clara tendncia no sentido de sua
aceitao por praticamente todas as empresas que operam em ambientes
competitivos.
Antes da popularizao dos DW e das ferramentas de ERP (Enterprise Resource

Planning), uma verdadeira integrao de dados era apenas um sonho, ou seja, era
uma utopia a ser quebrada. Sistemas trocavam dados de forma que atendesse s
necessidades de cada um deles, sendo por isso chamado "sistemas integrados",
sem que essa integrao sequer se aproximasse do que se vem hoje nos ERP,
cujos fornecedores tm dado a seus produtos caractersticas que os tornam
facilmente fornecedores de dados aos warehouses.
Cada aplicativo tinha uma viso da situao, um produto ou uma operao; uma
viso corporativa das informaes disponveis era praticamente irreal.
Dados histricos no existiam de forma organizada e os dados sintticos
disponveis mostravam quase sempre apenas uma pequena parte da realidade da
empresa.
A integrao dos dados permite a um executivo ter uma viso "corporativa" dos
dados; essa integrao, ou mais especificamente a migrao dos dados mantidos
pelos sistemas anteriores, no entanto, no um processo fcil, nem barato. Tudo
isso exige muito planejamento.
H algumas verses de Data Warehouse que merecem ser individualizadas por

suas caractersticas especiais: uma delas o Operational Data Store (ODS), que
opera diretamente conectado aos dados operacionais, objetivando dar suporte a
decises de natureza operacional, com caractersticas que permitem a obteno
de tempos de resposta bastante rpidos.
2.2. O que um Data Warehouse?
Por Willian H. Inmon
"Data Warehouse um banco de dados orientado por assunto, integrado, no

voltil e histrico, criado para suportar o processo de tomada de deciso."
Outra boa definio para DW vem de Gupta (1997): "um ambiente estruturado,
extensvel, projetado para a anlise de dados no volteis, lgica e fisicamente

transformados, provenientes de diversas aplicaes, alinhados com a estrutura da

empresa, atualizados e mantidos por um longo perodo de tempo, referidos em
termos utilizados no negcio e sumarizados para anlise rpida".
De forma bastante simples, a imagem 1 mostra a arquitetura de um DW, com os

sistemas que o alimentam, seus usurios, o DW propriamente dito e os
metadados, cada um desses conceitos ser amplamente discutido mais frente:
Imagem 01
A definio de um Data Warehouse (por W. H. Inmon) necessita de um completo

detalhamento, porque existem detalhes muito importantes e sutilezas bsicas nas
caractersticas de um Warehouse.
Orientado por Assunto

Integrado
Histrico
No Voltil
2.2.1. Orientado por assunto
A primeira caracterstica de um DW que ele est orientado ao redor do principal

assunto da empresa. O caminho do registro, orientado ao assunto est em
contraste com a mais clssica das aplicaes orientadas por processos ao redor
dos quais os sistemas operacionais mais antigos esto organizados.

A imagem 02 mostra o contraste entre os dois tipos de orientaes.
Data
Operacional
Warehouse
Emprstimos Clientes
Carto Bancrio Vendas
Crdito Produtos
Orientados Orientados
a aplicao ao assunto
Imagem 02
No geral, o mundo da informao operacional est todo baseado ao redor de

aplicaes e funes transacionais. O mundo do Data Warehouse est organizado
ao redor do principal assunto assim como por exemplo, cliente, vendas, produtos e
atividades. O alinhamento ao redor das reas de assunto afeta o desenho e
implementao do dado criado no Data Warehouse, ou seja, a rea do assunto
mais influente a parte mais importante da estrutura chave.
O mundo das aplicaes est preocupado com o desenho dos processos e de

banco de dados. O mundo do Data Warehouse est focado exclusivamente na
modelagem de dados e desenho do banco de dados.
Nota: O desenho de processos (como na forma clssica) no parte de um ambiente de Data Warehouse.
As diferenas entre aplicaes orientadas por processos/funes e as orientadas

por assunto, mostra as diferenas no contedo dos dados e no nvel de detalhes
dos mesmos. No Data Warehouse so excludos os dados que no devem ser
usados no processo de DSS (Sistemas de Suporte a Deciso), enquanto no

ambiente operacional as aplicaes contm dados para satisfazer imediatamente

as requisies funcionais/processamento que podem ou no ser usadas para
anlise de DSS.
Outra importante maneira na qual os dados operacionais das aplicaes difere dos
dados para Data Warehouse est no relacionamento dos dados. Dados
operacionais mantm relacionamentos entre duas ou mais tabelas baseadas nas
regras de negcio que esto em efeito. Registros do DW usam uma base de
tempo e os relacionamentos criados no DW so muitos. Muitas regras de negcio
so representadas no DW entre duas ou mais tabelas.
2.2.2. Integrado
O mais importante aspecto do ambiente de DW que dados criados dentro de um

DW so integrados. SEMPRE. COM NENHUMA EXCEO. Essa sem duvida a
melhor essncia do ambiente de warehouse... A integrao mostra-se de
diferentes maneiras: na conveno consistente de nomes, na forma consistente
das variveis, na estrutura consistente de cdigos, nos atributos fsicos
consistente dos dados, e assim por diante.
Veja os exemplos refletidos pela imagem 03
Imagem 03

A habilidade coletiva de muitos analistas de aplicaes em criar produtos sem

consistncia lendria. A imagem 3 apresenta algumas das muitas diferenas
importantes na maneira como as aplicaes so desenhadas.
Codificao - desenvolvedores de aplicaes tm preferido, por exemplo,

codificar o campo SEXO das mais variadas formas. Um desenvolvedor
representa SEXO com um "M" e um "F". Outro desenvolvedor representa
SEXO com um "1" e um "0". Outro desenvolvedor representa SEXO com
um "x" e um "y". E ainda outro desenvolvedor SEXO com "masculino" e
"feminino". "M" e "F" so provavelmente bons para algumas
representaes. Entretanto quando SEXO carregado para o DW de um
projeto de BI, o mesmo deve ser convertido para um nico formato; o
formato do Data Warehouse.
Forma dos atributos - desenvolvedores de aplicaes tm preferido ao

longo dos anos utilizarem uma variedade de medidas. Um desenvolvedor
armazena dados em centmetros. Outro desenvolvedor armazena em
polegadas. Outro desenvolvedor de aplicao armazena dados em milhes
de ps cbicos por segundo. E outro desenvolvedor armazena informaes
em termos de jardas. Quando a informao chega no Data Warehouse
necessrio ser mensurada e transformada de algum modo.
2.2.3. Histrico
Todo registro no Data Warehouse exato em algum momento do tempo. A

caracterstica bsica do dado em warehouse ter muitas fontes de dados
diferentes no ambiente operacional.
No ambiente operacional o dado exato no momento do acesso, ou seja, no

ambiente operacional quando voc acessa uma unidade do dado, voc espera
que isto deva refletir os valores corretos no momento do acesso.
Por causa do dado em DW ser exato em algum momento do tempo, o dado criado
no warehouse um "histrico". A imagem 4 mostra os valores histricos do dado
no warehouse.
Os valores histricos dos dados no DW so mostrados em vrias maneiras. O

modo mais simples que o dado representa os dados sobre um horizonte de
tempo distante. O horizonte de tempo representado pelo ambiente operacional
muito curto.
O segundo modo que o "histrico" mostrado no DW na estrutura chave.

Sempre na estrutura chave do DW existe, explicitamente, ou implicitamente, um
elemento de tempo, assim como dia, semana, meses, etc. O elemento de tempo
est quase sempre no final da chave concatenada criada no DW.

A terceira maneira que o "histrico" aparece no DW, que uma vez o registro
estando correto, no pode ser atualizado.
Dado no DW e, para todos os propsitos prticos, uma srie longa de

snapshots. Naturalmente se os snapshots do dado tm sido feitos incorretamente,
eles no so alterados uma vez feitos. Em alguns casos isto pode ser sempre
ilegal, podendo os snapshots no DW, serem alterados. Dados operacionais iniciam
pontualmente no momento do acesso, podendo ser atualizados quando surgir
necessidade.
Imagem 04
2.2.4. No voltil
A quarta caracterstica definida para um DW que ele no voltil. Imagem 5

ilustra este aspecto no Data Warehouse.
A imagem 5, apresenta que atualizaes como, incluso, excluso, e alterao,

so feitas regularmente no ambiente operacional de um registro bsico. Mas a
manipulao de dados bsicos que ocorre no Data Warehouse mais simples.
Existem somente duas espcies de operaes que ocorrem no DW, carga inicial
do dado, e o acesso ao dado. Esta no uma atualizao do dado (no sentido
geral de atualizao) no DW como parte normal do processamento.
Para o nvel de desenho, existe a necessidade de ter cautela nas atualizaes

anormais, o que no um fato importante no DW, atualizaes neste dado no
so feitas. Existem meios para que no nvel fsico do desenho, permisses
possam ser criadas para otimizar o acesso ao dado, particularmente em
procedimentos com o uso de normalizao e desnormalizao fsica.
Outras conseqncias da simplicidade das operaes do DW esto na tecnologia

bsica usada para rodar no ambiente de DW. Como suporte para atualizao de

registro por registro em modo on-line requer uma tecnologia com fundamentos
muito complexos, em baixo da simplicidade de uso.
A tecnologia que suporte backup, recovery, transao com integridade do dado, a

deteco e correo de deadlock muito complexa. Isto no necessrio para
processamento de DW.
As caractersticas de um Data Warehouse, desenho orientado ao assunto,

integrao dos dados com o Data Warehouse, histrico, e simplicidade de
gerenciamento dos dados - todos conduzem para um ambiente que MUITO,
MUITO diferente do ambiente operacional bsico.
A fonte para aproximar todos os dados do Data Warehouse o ambiente

operacional. Muitas vezes as pessoas podem pensar que isto mais uma
redundncia do dado entre os dois ambientes. De fato, na primeira impresso isso
at ocorre, porm, este entendimento superficial a necessidade de demonstrar o
que est ocorrendo no Data Warehouse. De fato, este o MNIMO de
redundncia do dado entre o ambiente operacional e o ambiente de Data
Warehouse. Considere o seguinte:
Dado filtrado quando passa do ambiente operacional para o ambiente de

Data Warehouse. Muitos dados nunca saem do ambiente operacional.
Somente o dado que necessrio para o processamento do DSS
encontrado no ambiente warehouse;
O histrico do dado muito diferente de um ambiente para outro. Dado no

ambiente operacional muito recente. Dado no warehouse muito antigo.
S na perspectiva de histrico recente, muito pequeno o overlap entre o
ambiente operacional e o ambiente de Data Warehouse;
O DW contm dados sumarizados que nunca so encontrados no ambiente

operacional;
Dados sofrem uma fundamental transformao ao passar para o DW.

Muitos dados so alterados significativamente aps serem selecionados e
movidos para o Data Warehouse. Dito de outra forma, muitos dados so
fisicamente e radicalmente alterados quando movidos para o warehouse.
Estes dados no so os mesmos que residem no ambiente operacional do
ponto de vista de integrao.
Nota: Redundncia de dados entre os dois ambientes uma ocorrncia rara, resultando em menos que 1% de
redundncia entre os dois ambientes.

Imagem 5
2.3. Um pouco mais sobre Data Warehouse
No existe uma receita pronta para desenvolver um DW, porem, possvel

encontrar vrias ferramentas no mercado mundial que atendem e, ou abrangem
desde as etapas de extrao e anlise de dados, at a construo propriamente
dita, e o gerenciamento do DW.
Um ponto importante a ser ressaltado a observao do valor do investimento no

projeto como um todo, geralmente situado na casa dos milhes de dlares.
Por estar diretamente vinculado aos negcios da empresa, o projeto exige no

apenas o trabalho da equipe tcnica, mas tambm a interao constante da rea
executiva, pois qualquer desvio ou mau entendimento na execuo dos vrios
processos que envolvem um projeto de BI pode causar graves prejuzos ao levar a
empresa a consultar informaes no confiveis e, conseqentemente, a tomar
decises erradas.
2.4. Construindo um Data Warehouse
Antes de qualquer coisa, vamos analisar a arquitetura de um DW, suas

caractersticas e mincias. Desta forma poderemos entender melhor as etapas
operacionais que sero apresentas posteriormente nesta obra.

2.4.1. Arquitetura de um Data Warehouse
Podemos definir basicamente duas formas de apresentao da arquitetura de um

DW, uma conceitual e outra fsica do modelo relacional que representa todo o
sistema.
2.4.1.1. Viso Conceitual
Metadados produzidos em todas as etapas
Monitorao e Repositrio de
Administrao Metadados
Data Servidores
Warehouse OLAP
Fontes
Externas
ETL
Anlises
Data
Mining
BD
Operacionais Data Marts
Ferramentas
Imagem 6
O DW pode ser dividido em diversos Data Marts (DM), que departamentalizam os

dados separando-os por setores dentro da organizao.
Nota: Os data marts sero apresentados posteriormente.
Os dados contidos nos DW e nos DMs so gerenciados por um ou mais

servidores de warehouse, os quais apresentam vises multidimensionais dos
dados para uma variedade de ferramentas front end.
A viso multidimensional geralmente apresentada na forma de um ou mais

cubos de dados, que indicam que as informaes so visualizadas em linhas e

colunas como o formato tradicional das planilhas, porm existem mais dimenses,
sendo que o cubo teria apenas mais uma dimenso.
2.4.1.2. Viso Fsica (em Camadas)
Camada de Bancos de Dados Operacionais e Fontes Externas: contm as

bases de dados operacionais e podem ser compostas tambm de
informaes de fontes externas, estes dados recebem um tratamento
especial para poderem ser incorporados ao DW;
Imagem 07
Camada de Acesso aos Dados: Compe o elo de ligao entre as ferramentas de

acesso informao e os bancos de dados operacionais, comunicando-se com
diversos Sistemas de Gerenciamento de Banco de Dados (SGBDs) e sistemas de
arquivos, sendo que a este conjunto de caractersticas d-se o nome de acesso
universal de dados;
Camada de Transporte ou Middleware: tem a funo de gerenciar a

transmisso das informaes pelo ambiente de rede que serve de suporte
para o sistema como um todo, separando as aplicaes operacionais do
formato real dos dados, realiza ainda a coleta de mensagens e transaes
e se encarrega de entreg-las nos locais e nos tempos determinados;

Camada do Data Warehouse: constitui-se do armazenamento fsico dos

dados oriundos dos sistemas operacionais da empresa e externos,
permitindo um acesso mais rpido e seguro aos dados do DW, alm de
prover maior flexibilidade de tratamento e facilidade manipulao;
Camada de Acesso Informao: proporciona a interao com os usurios

finais atravs de ferramentas visuais tradicionais, tais como sistemas de
planilhas de clculo, browsers, entre outras;
Camada de Metadados (Dicionrio de Dados): os metadados descrevem os

dados e a organizao do sistema, podem ser ainda frmulas utilizadas
para clculo, descries das tabelas disponveis aos usurios, descries
dos campos das tabelas, permisses de acesso, informaes sobre os
administradores do sistema, entre outras;
Camada de Gerenciamento de Processos: faz o controle destas tarefas que

mantm o sistema atualizado e consistente, gerenciando as diversas
tarefas que so realizadas durante a construo e a manuteno dos
componentes de um sistema de DW;
Camada de Gerenciamento de Replicao: serve para selecionar, editar,

resumir, combinar e carregar no DW as informaes a partir das bases
operacionais e das fontes externas, envolvendo programao bastante
complexa, sendo que existem ferramentas poderosas que permitem que
estes processos sejam gerenciados de forma mais amigvel, alm do
controle da qualidade dos dados que sero carregados.
2.4.2. Estrutura Fsica dos Dados do DW
A respeito da disposio fsica dos dados, o DW pode ter uma estrutura

centralizada em um nico local ou ento ser implementado de forma distribuda.
Se optarmos pelo primeiro modelo, o centralizado; teremos um warehouse
consolidado e o Banco de Dados (BD) formar um DW integrado.
Definindo o projeto desta forma pode-se maximizar o poder de processamento e

acelerar os processos de busca por informaes analticas.
Definindo-se uma arquitetura federativa, pode-se distribuir a informao por

funo, separando os dados do setor financeiro em um servidor, os dados de
marketing em outro local, e dados de manufatura em um terceiro lugar.
Existe ainda uma terceira metodologia, na qual se considera uma arquitetura de

DW separada por camadas, armazenando os dados mais resumidos em um
servidor, dispondo os dados um pouco mais detalhados, em nvel de detalhe

intermedirio, em um segundo servidor, e por fim colocamos os dados mais

detalhados (atmicos) em um terceiro servidor. A imagem 8, exemplifica esta
metodologia.
Volume de Consultas /
Nmero de Usurios
Granularidade /
Tamanho da Base
Camada 1 Camada 2 Camada 3
Imagem 8
O primeiro servidor geralmente atende maior parte das consultas, sendo que
teremos um menor nmero de pedidos de acesso solicitados para a camada 2 e
camada 3.
O dimensionamento dos servidores o seguinte: na primeira camada podemos ter

uma configurao para suportar um grande nmero de usurios que faro
diversas consultas, as quais trabalharo com um volume relativamente pequeno
de dados. J os servidores das outras duas camadas devem ser configurados
para permitir processar grandes volumes de dados, porm no necessria uma
preocupao em configurar o sistema para suportar o acesso de um nmero maior
de usurios.
Isto explica-se pelo fato de que a maioria dos usurios ter suas perguntas
respondidas pelas consultas iniciais da camada 1. Se algum usurio no se
satisfizer com o nvel de detalhe das respostas da camada 1, pode buscar maiores
informaes na camada 2 e at mesmo na camada 3. Conclumos ento que
poucos usurios faro acessos regulares ltima camada, sendo que alguns
nunca o faro alm do nvel inicial.
2.4.2.1. Arquitetura de Duas Camadas
Existe uma arquitetura de implantao de sistemas de DW que consiste em utilizar

um computador de alta capacidade como servidor. Este mtodo disponibiliza
aplicaes aos usurios finais na forma de ferramentas front end, que servem para
realizar as consultas, em conjunto com os componentes do servidor com
ferramentas back end, que servem para municiar o DW com informaes.

Organizaes que podem crescer com a incorporao de outras empresas do

mesmo ramo ou ainda de outro ramo de negcio, gradualmente acumulam
diversos sistemas de computao legados, cada um com suas incompatibilidades
de definies dos dados. Esta redundncia e falta de consistncia dos dados
dificulta a administrao das bases de dados, resultando numa dificuldade
tambm para desenvolver-se novas aplicaes front end.
Esta arquitetura pode ser chamada de "sistema guarda-chuva", a qual possui um

formato em que o cabo do guarda-chuva representa o servidor principal e as
hastes representam os sistemas de consulta a este servidor.
Imagem 9
A arquitetura ilustrada na imagem 9 pode ser usada para construir um sistema de

DW em duas camadas, o qual possui os componentes dos clientes (front end) e os
componentes do servidor (back end).
Esta arquitetura bastante conveniente, uma vez que utiliza os sistemas j

existentes na empresa bem como os servidores de bancos de dados e requer um
pequeno investimento em hardware e software.
Um dos grandes problemas que existe neste tipo de arquitetura o fato de no ser
permitido o seu escalonamento, o que resulta, com o aumento do nmero de
usurios, num desempenho ruim pelo gargalo existente entre os clientes e o
servidor. Estas anomalias podem ocorrer pelo uso de estaes clientes muito
lentas e com muitos processos rodando simultaneamente.

2.4.2.2. Arquitetura de Trs Camadas
Para tentar solucionar os problemas de desempenho resultantes do gargalo da

arquitetura de duas camadas, existe uma arquitetura de informao em mltiplas
camadas, como mostrado na imagem 10. Esta arquitetura bastante flexvel e
suporta um grande nmero de servios integrados, onde a interface do usurio
(ferramentas front end), as funes de processamento do negcio e as funes de
gerenciamento do BD so separadas em processos, os quais podem ser
distribudos atravs da arquitetura de informao.
Este tipo de arquitetura em trs camadas bastante utilizado. Na primeira camada
ficam as aplicaes de interface com os usurios, que devem ser grficas e
baseadas em rede. Dados e regras de negcio podem ser compartilhados pela
organizao, assim como o BD para o DW, ficam armazenados em servidores de
alta velocidade na segunda camada, a camada central. Na terceira e ltima
camada esto localizadas as fontes de dados.
Analisando o ambiente do DW, os servidores de BD e os servidores de aplicaes
da camada central provem um acesso eficiente e rpido aos dados
compartilhados.
Com a separao dos servidores em transacional e analtico pode-se obter uma

boa performance nas consultas e no processamento, sendo que deve haver
disponibilidade de equipamentos e recursos satisfatrios de conexo entre os
diversos componentes do sistema.
Imagem 10

2.4.3. OLTP versus OLAP
Os termos OLTP (on-line transaction processing processamento on-line de

transaes) e OLAP (on-line analytical processing processamento analtico on-
line) descrevem o modo de processamento de cada uma das componentes da
diviso proposta para os sistemas de Bancos de Dados.
Bancos de dados operacionais atingem propores de centenas de megabytes e

at mesmo gigabytes.
Consistncia e capacidade de recuperao de dados so crticas, e a

maximizao do poder de processar transaes requerida para minimizar os
problemas que podem ser causados pela concorrncia de processos.
Analisando sistemas OLAP, sistemas que do apoio deciso, pode-se notar o

contraste com OLTP.
No caso do processamento analtico deve-se dar maior importncia aos dados

histricos, totalizados e consolidados em detrimento dos dados detalhados ou
individualizados.
Uma vez que os DW contm dados referentes a longos perodos de tempo, estes
podem atingir dimenses muito maiores do que os bancos de dados operacionais,
chegando a conter centenas de gigabytes e at mesmo terabytes de informaes.
A tabela 1 ilustra as diversidades apresentadas pelos dois tipos de sistemas, DW

e Bancos de Dados Operacionais:
Tabela 1: Diferenas entre os tipos de sistemas.
Caractersticas DBs Operacionais DW
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
Caractersticas BDs operacionais DW
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/complexos
Inteno dos ndices Localizar um registro Aperfeioar consultas
2.4.4. Projeto e Desenvolvimento de Sistemas de Data Warehouse
A maioria dos autores sobre o assunto costuma dizer que o projeto de sistemas de
DW muito cansativo e penoso. Analisando pelo ngulo das gerncias
administrativas, muitas vezes pode-se imaginar que, uma vez que a base de
dados transacional j est em funcionamento, torna-se automtica a implantao
de sistemas de anlise e suporte deciso.
Muitas vezes necessria uma completa reavaliao dos sistemas transacionais

para que s ento seja possvel modelar um projeto de DW.
De certa forma os projetos de sistemas de apoio tomada de deciso no fogem

ao modo tradicional de se implementar e implantar sistemas de informao. Deve
ser feita uma anlise do sistema como um todo utilizando-se inclusive da
realizao de diversas reunies com os gerentes, funcionrios e outros
colaboradores envolvidos no tema.
Os projetos de DMs 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 mesmo problemas para os setores.
Aps a concluso de um projeto inicial bem implantado, com certeza surgiro

outros projetos a partir de novas idias dos prprios usurios, e tambm dos
projetistas, em funo da experincia adquirida durante o projeto do sistema
inicial.

2.4.4.1. Funes dos Componentes da Equipe
O projeto e a posterior manuteno e utilizao de sistemas de DW requerem o

empenho de profissionais capacitados e com conhecimentos avanados em
diversas reas. Alm disto, podero ser definidas vrias funes para os usurios.
De acordo com o tamanho do projeto e o tipo de tecnologia utilizada, podem ser
necessrias vrias pessoas para realizar as diferentes funes. Nota-se tambm
que algumas das funes da tabela 2 so necessrias apenas durante a fase de
projeto do DW. Algumas funes podem variar conforme o estgio em que se
encontra o projeto, assim como podem ser agrupadas para que uma s pessoa
realize vrias delas ao mesmo tempo.
Tabela 2: Funes dos componentes da equipe de um DW.
Funes Responsabilidades
Gerente do Data Warehouse Define as estratgias pertinentes ao Data Warehouse;
Planeja e gerencia o DW;
Comunica os objetivos do DW para a equipe de
desenvolvimento.
Arquiteto de Dados (Modelador) Desenvolve o modelo de dados

Analisa as exigncias de dados
Desenha as estruturas dos dados
Define as vises gerenciais para os dados
Administrador de Metadados Define os padres de metadados

(Modelador) Gerencia o repositrio dos metadados
Administrador do BD (DBA) Cria as estruturas fsicas no BD

Monitora o carregamento dos dados e a performance das
consultas
Usurio de nvel gerencial Descreve os dados necessrios

Especifica as regras de negcio
Testa os resultados das transformaes dos dados
Analista de processos e aplicaes Desenvolve as aplicaes de suporte deciso

(Funcional)
Especialista em Aplicaes Indica onde esto os dados nos sistemas transacionais

Operacionais (DBA/Analista Sistemas)
Analista e programador de Indica as fontes de dados para o DW

converses (ETL/DBA) Desenvolve os programas para selecionar e carregar os
dados
Especialista em suporte tcnico Desenvolve as atividades tcnicas como instalar e

(infra-estrutura) configurar mquinas
Instrutor Treina os usurios para acessar o DW

2.4.4.2. Analise entre Model. Dimensional e Model. Relacional
Um modelo entidade-relacionamento nem sempre indicado para a construo de

bancos de dados de apoio deciso, os chamados DSS (Decision Suport
Systems).
Este tipo de modelagem bastante apropriado para ser aplicado no

desenvolvimento de sistemas transacionais em ambientes relacionais.
Na atualidade, a forma mais utilizada pelos projetistas para armazenar grandes

quantidades de dados feita em bancos de dados relacionais, uma vez que sua
estrutura de dados bastante propcia para solucionar problemas de espao em
disco e tambm de desempenho. A questo fundamental que as novas
tecnologias de consulta e anlise de dados requer recursos que a modelagem
relacional no pode oferecer.
sugerido por vrios autores do tema BI, a utilizao de tcnicas diferenciadas

denominadas Modelagem Dimensional (MD), as quais estruturam os dados de
forma diferente daquela definida pelos sistemas relacionais, possibilitando que
todas as consultas sejam melhoradas.
No existem segredos para que se converta um modelo ER em um modelo

dimensional. O gerenciador de banco de dados utilizado no MD bastante
diferente do tradicional que gerencia modelos ER, sendo que no primeiro so
facilitadas a navegao e as consultas. O nmero de tabelas reduzido pelo fato
de existirem dimenses ligadas a uma tabela de fatos central, logo o gerenciador
pode trabalhar com um nmero menor de chaves.
A teoria de bancos de dados relacionais sugere aos desenvolvedores que

procurem eliminar as redundncias dos dados atravs da modelagem ER e
normalizaes. As tabelas definidas so relacionadas atravs de chaves e utiliza-
se estas tabelas normalizadas para reduzir o nmero de atualizaes necessrias
nesta base.
O grande problema dos modelos ER que o nmero de tabelas inconsistentes

grande. Qualquer pessoa que tenha projetado um sistema de informao que
controle um processo dentro de uma empresa de porte mdio deve possuir pelo
menos um grande mapa desenhado com as entidades relacionadas entre si.
Podem existem nele centenas de tabelas interligadas por centenas de

relacionamentos. Este modelo pode ser visto pelos olhos do projetista e das
pessoas ligadas tecnologia de banco de dados como um modelo consistente e
bem arranjado, o qual supre as necessidades de consistncia e desempenho das
transaes que so realizadas em grandes quantidades a todo o momento.
Porm, sob a tica do usurio final, este modelo arquitetado dificlimo, para no
dizer impossvel, de ser entendido.

J um modelo dimensional nos parece diferente. Um modelo estrela organiza de

forma mais simplificada o processo como um todo, reduzindo a amplitude dos
fatos desejados e trazendo as questes importantes para o foco.
Por exemplo, na Imagem 11 apresentado um modelo dimensional de um

processo empresarial tpico: um caixa registrador de vendas em uma cadeia de
varejo.
Normalmente se chama este tipo de diagrama de Diagrama Estrela. Observe que

na tabela central, a tabela de fatos, esto colocadas chaves para as dimenses e
alguns atributos que representam medidas numricas do negcio.
Esta tabela tradicionalmente a maior em nmero de registros.
Imagem 11
Sistemas de DW podem ter vrias tabelas de fatos, cada uma representando um

processo diferente dentro da empresa, constituindo os DMs, que podem ser
ligados uns aos outros dependendo da necessidade e tambm da possibilidade de
que isto acontea.
As tabelas de fatos so ligadas atravs de relacionamento a diversas tabelas de

dimenses utilizando chaves. Estas tabelas so muito menores em tamanho e
nmero de registros do que a tabela de fatos a que so ligadas. Cada tabela de
dimenso tem uma nica chave e os campos destas tabelas so tipicamente
textuais e utilizados como fontes para compor os cabealhos de relatrios.
Um esquema estrela como o da imagem 11 se baseia em dois tipos de consultas

(queries): browse e join multitabelas.
A query browse definida para ser aplicada em uma tabela apenas, sem que seja
necessrio utilizar comandos join. Um exemplo deste tipo de consulta ocorre
quando um usurio abre um menu pull-down de toda a lista de itens de uma tabela
que representa uma dimenso do modelo estrela a fim de consultar seus atributos.

Normalmente os dados resultantes desta consulta sero apresentados de forma

automtica, uma vez que, teoricamente, tudo o que se quer j est na tela.
As consultas com joins multitabelas so precedidas por uma srie de browses que
fazem uso da estrutura do modelo estrela atravs de diversas unies entre a
tabela de fatos e as dimenses. Dificilmente este tipo de consulta ser atendido
rapidamente, uma vez que so localizadas centenas ou at milhares de registros
de tabelas subjacentes para darem uma resposta resumida para o usurio.
A modelagem dimensional um processo top-down. Primeiro so identificados os

processos empresariais que sero a base para a criao das tabelas de fatos,
tabelas estas que sero povoadas como os dados numricos destes fatos. A
modelagem ER habitual possui grande parte de seu conjunto formado pelas
tabelas de dimenso e por tcnicas de normalizao. Se as tabelas de dimenso
forem normalizadas em estruturas de "floco de neve", onde estas dimenses so
compostas de mais de uma tabela, podem surgir dois problemas. Primeiro, o
modelo de dados fica bastante complexo para ser apresentado aos usurios.
Segundo, a unio entre as diversas partes do floco de neve ir comprometer o
desempenho do sistema como um todo.
O desempenho durante a fase de atualizao das tabelas raramente importante

em sistemas de apoio deciso, uma vez que esta operao feita, como j foi
dito neste trabalho, durante a noite ou em momentos em que no se esteja
utilizando os sistemas da empresa a pleno vapor. Mesmo assim, alguns projetistas
utilizam o argumento de melhorar este desempenho para justificarem a
necessidade de normalizar as dimenses.
Um projeto de banco de dados dimensional tem uma estrutura fixa onde no h

nenhum caminho alternativo. Isto simplifica grandemente a otimizao e a
avaliao de questes nestes esquemas. Deve ser construda uma longa lista
ordenada de chaves compostas para a tabela de fatos. A seguir, repassar a tabela
de fatos compondo um ndice por vez.
Analise de perto como seu gerenciador de banco de dados tenta processar uma
consulta em um esquema estrela. Se o plano de avaliao de consulta tem a
tabela de fatos em parte semelhante ao modo abaixo a lista com as tabelas de
dimenso mencionadas depois disto, seu DBMS no sabe como fazer joins do tipo
estrela. Quando a tabela de fatos s parte da lista abaixo, o DBMS est
gravando um subconjunto da tabela de fatos no disco. O DBMS est testando
ento individualmente os registros resultantes contra as tabelas de dimenso
restantes e o resultado uma query que roda muito lentamente.
Uma diferena final um pouco controversa entre o modelo ER e a MD o grau de

julgamento deixado nas mos do projetista. A essncia de um bom modelo
dimensional a escolha do conjunto da maioria das dimenses naturais da
perspectiva de um usurio final. Sempre h duas ou mais alternativas que

representam os dados da mesma maneira, mas empacotam as dimenses

diferentemente. Em ltima instncia, o julgamento do projetista deve prevalecer.
til ter uma anlise de ER antes de embarcar em um projeto dimensional porque

a equipe de DW entender melhor os dados desta forma. Porm, a equipe tem
que fixar aparte o diagrama ER durante o processo de projeto do DW porque a
modelagem dimensional tem que proceder de uma perspectiva de usurio, em
lugar de uma perspectiva de dados. Se no existir uma anlise de ER, no
recomendvel despender um bom tempo para fazer isto com a finalidade de
construir um banco de dados de DW.
Os ltimos trs quartos do tempo de uma anlise de ER so para a reduo da
redundncia - especialmente fora das tabelas de dimenso que no beneficiam o
projeto dimensional.
2.4.4.3. Problemas encontrados no Desenvolvimento de Data Warehouses
Existem diversos problemas que podem ocorrer durante o desenvolvimento de um

sistema de DW. Dentre estes problemas, os mais comuns so:
a) No envolver a alta direo da empresa no projeto: Conforme j foi dito em

sees anteriores, o projeto de um DW s ter sucesso se os futuros usurios se
envolverem diretamente desde o incio nas atividades, pois isto facilitar a
destinao das verbas necessrias nos momentos oportunos alm de direcionar
os trabalhos para que os reais objetivos do DW para o negcio da empresa sejam
alcanados no momento da implantao;
a) Gerar falsas expectativas com promessas que no podero ser cumpridas:

citar frases do tipo "O DW mostrar aos gerentes as melhores decises" pode
causar tanto desconfiana no projeto quanto desprezo;
b) O DW no mostrar as melhores decises, mas sim respostas s consultas

efetuadas. Cabe aos usurios elaborar consultas inteligentes e analisar as
respostas obtidas;
c) Carregar no DW informaes somente porque elas esto disponveis nos

sistemas transacionais: Nem todos os dados disponveis nos sistemas
operacionais da empresa so necessariamente teis para o DW. Cabe ao
arquiteto dos dados analisar junto com os usurios quais os dados que
realmente contm informaes necessrias e desprezar aqueles que no
fazem parte dos objetivos do DW;
d) Imaginar que o projeto do banco de dados do DW o mesmo que o projeto de

um sistema transacional: num processo transacional devem ser dimensionados
os recursos para que se atinja uma alta velocidade de acesso e grandes
facilidades na atualizao de registros. Nos sistemas de apoio deciso a
realidade totalmente outra. O objetivo destes sistemas fornecer acessos

agregados, ou seja, somas, mdias, tendncias, etc. Outra diferena entre os

dois tipos de sistemas pode ser detectado no tipo de usurios. Nos sistemas
transacionais um programador desenvolve uma consulta que poder ser
utilizada milhares de vezes. No DW o usurio final desenvolve suas prprias
consultas que podem ser utilizadas somente uma vez;
e) Na seleo do pessoal, escolher um gerente para o DW com orientao

essencialmente tcnica: os sistemas de apoio deciso so na verdade uma
prestao de servios e no um servio de armazenamento de dados. Por
isso, fundamental que o gerente do DW seja uma pessoa voltada aos
interesses dos usurios e principalmente que, saiba dos termos utilizados
diariamente pelos altos gerentes e outros tomadores de decises.
f) Dedicar-se ao tratamento de dados do tipo registros numricos e string: Muitos
poderiam imaginar que as informaes que sero utilizadas em um DW seriam
oriundas especificamente dos registros das bases de dados transacionais, e
que estas informaes seriam apenas nmeros ou palavras. Quem pensa
desta forma pode estar enganado, pois textos, imagens, sons e vdeos podem
ser bastante teis no momento da anlise de determinadas situaes da
empresa e do negcio;
g) Projetar um sistema com base em um hardware que no poder comportar o

crescimento da demanda do DW: A capacidade dos servidores est em
constante crescimento, porm pode ser dimensionando um ou mais
equipamentos para trabalharem por um ou dois anos, mas as caractersticas
destes sistemas indicam que a quantidade de informaes armazenadas pode
atingir at mesmo alguns Terabytes. importante que o servidor do banco de
dados do DW seja fornecido por uma empresa confivel e que garanta a
possibilidade de serem realizadas expanses a valores e prazos compatveis
com os de mercado;
h) Imaginar que aps a implantao do DW os problemas estaro terminados:

Muito esforo deve ser despendido para que um sistema de DW saia da
prancheta. Porm, aps a sua implantao os usurios comearo a criar mais
e mais consultas, e estas consultas necessitaro de novos dados que
resultaro em novas consultas. Desta forma, o projeto de um sistema de apoio
deciso precisa ser revisado e atualizado constantemente, no apenas com
novos dados, mas tambm com novas tecnologias.
2.4.5. Melhorando a performance do Data Warehouse
O desempenho dos sistemas de DW deve ser sempre considerado como um dos

fatores crticos para o sucesso do projeto, uma vez que sero manipuladas
grandes quantidades de informao por um nmero razovel de usurios.
Podem ser aplicadas algumas tcnicas durante o projeto e o desenvolvimento de

um DW na tentativa de melhorar seu desempenho para o usurio final.

Algumas destas tcnicas j so utilizadas nos projetos de sistemas transacionais e

outras so mais especficas para utilizar nos sistemas de apoio deciso.
2.4.5.1. Intercalao de Tabelas
Nesta tcnica o projetista do DW intercala as tabelas relacionadas entre si em um

mesmo local fsico. Este procedimento diminui a carga de operaes de entrada e
sada (E/S), tanto em funo do acesso aos dados, como em funo do acesso
aos ndices para a localizao destes dados. Tentando prever, mesmo que
superficialmente, quais consultas sero feitas pelos usurios, pode-se agrupar ou
desagrupar as diversas tabelas do sistema.
2.4.5.2. Introduo de Informaes Redundantes
Aplicada essencialmente em ambientes de apoio deciso, esta tcnica consiste

na introduo deliberada de dados redundantes, os quais proporcionam um
excelente incremento de desempenho.
Na parte superior da imagem 12 est o campo denominado descrio, o qual est

normalizado e sem redundncia. Sendo assim, os processos que necessitarem da
descrio, devero acessar a tabela bsica para obter tal informao. Na parte
inferior da imagem o campo denominado descrio foi colocado propositadamente
nas outras tabelas, mesmo que seja uma informao totalmente redundante, pois
isto ir permitir ao sistema que encontre estas informaes sem que seja
necessrio acessar a tabela original de produtos.
Como se pode notar, o problema da replicao dos dados reside no fato de que as
informaes iro ocupar mais espao para o armazenamento, uma vez que so
gravadas diversas vezes as descries dos produtos, alm de tornar a
manuteno do sistema mais trabalhosa, uma vez que no basta atualizar apenas
a tabela de produtos no item descrio para propagar esta informao pelo
sistema, como se costuma fazer nos bancos de dados relacionais.
De qualquer maneira, como os sistemas de DW tm a caracterstica de sofrerem

poucas atualizaes e em contrapartida fazerem uso de muitos acessos s bases
devido s consultas ad hoc dos usurios finais, esta estratgia interessante pelo
fato de que o acrscimo de desempenho bastante considervel.

Produtos Produo Estoque Gerencia

Cdigo Cdigo Cdigo Cdigo
Descrio ... ... ...
Unidade
Atualizao Acesso Acesso Acesso
Produtos Produo Estoque Gerencia

Cdigo Cdigo Cdigo Cdigo
Descrio Descrio Descrio Descrio
Unidade ... ... ...
...
Atualizao Acesso Acesso Acesso
Imagem 12
2.4.5.3. Separao de Dados
Quando existirem informaes em uma tabela da base transacional na qual o

nmero provvel de acessos pode ser diferente dependendo do item desejado, h
a opo de separar aquela tabela em duas ou mais partes. Esta tcnica serve
para aumentar a velocidade de acesso aos dados e denominada "separao de
dados".
Por exemplo, a data da incluso de um produto no sistema pode ser importante

para determinados usurios que desejem analisar os dados sob uma perspectiva
especfica, porm na maioria das vezes para as consultas dos usurios esta
informao no ser solicitada.
A tabela, portanto, pode ser dividida em duas: uma contendo as informaes com
um nmero mais alto de possibilidades de acesso, e outra com as informaes
que possuem uma probabilidade mais baixa.

Imagem 13
Construindo uma arquitetura deste tipo d-se preferncia queles usurios que
consultam informaes mais corriqueiras, os quais obtero respostas mais
rapidamente do que aqueles que realizam perguntas sofisticadas e que so
realizadas esporadicamente. A deciso de privilegiar este ou aquele tipo de
consulta bastante importante para que futuras solicitaes ao sistema no
gerem consultas to complexas que o sistema de apoio deciso tenha que
realizar um grande processamento de dados para poder dar uma resposta ao
usurio.
2.4.6. Componentes dos Sistemas de DW
No final do ano de 1991 a IBM definiu um sistema chamado Information

Warehouse Framework (IW), como sendo um "conjunto de sistemas de gerncia
de banco de dados, interfaces, ferramentas e facilidades que gerenciam e
distribuem informaes confiveis, oportunas, corretas e compreensveis sobre o
negcio para pessoas autorizadas a tomar decises".
Este sistema consiste de trs componentes mais importantes, que so: o
enterprise data, o data dellivery e o decision support.
O primeiro, enterprise data, compe a parte central do warehouse, com SGBDs

que cuidam para que a integridade dos dados seja mantida, dando suporte
segurana destes dados, permitindo a sua recuperao, se necessrio, alm de
manter a total disponibilidade destes dados a todos que necessitem realizar
consultas. O desempenho do sistema tambm conseqncia da atuao deste
mdulo.

O segundo, data delivery, utilizado para recuperar os dados que se encontram

nas fontes internas da empresa, independentemente do local ou servidor onde se
encontrem. Esto disponveis ainda neste componente servios de transferncia,
transformao e enriquecimento de dados, sendo ainda controladas as cpias dos
dados tambm pelo data delivery.
No terceiro e ltimo componente, o decision support, permitido que os

tomadores de deciso manipulem adequadamente as informaes e transformem
os dados brutos em conhecimento til para a empresa. Para tal, devem ser
aplicadas tcnicas contidas em ferramentas que permitam selecionar, manipular e
apresentar os dados nos mais diversos formatos (planilhas, grficos, etc).
Este sistema definido pela IBM serviu como referencial para que a arquitetura de
sistemas de DW fosse mais bem entendida pelos estudiosos do assunto.
claro que estas ferramentas, na atualidade, podem ser consideradas

rudimentares e por isso foram aperfeioadas e adaptadas cada vez mais s novas
tecnologias oferecidas pelas empresas fabricantes de Bancos de Dados.
A implementao de um sistema de DW faz uso constante de ferramentas que

realizam tarefas definidas. Temos a seguir uma lista dos componentes destes
sistemas:
Fontes de dados do DW;

Um conjunto de estruturas de dados analticos (o DW);
Um sistema de gerncia de banco de dados (SGBD) configurado
especialmente para atender aos requisitos analticos dos sistemas de DWs;
Um componente back end: faz a extrao, limpeza, transformao,
integrao e carga dos dados das diferentes origens (fontes);
Um componente front end: Disponibiliza aos usurios finais o acesso aos
dados do DW;
Um repositrio para armazenar e gerenciar os metadados.
A imagem 14 demonstra o relacionamento entre estes componentes.

Imagem 14
2.4.6.1. O Sistema Gerenciador de Banco de Dados
O sistema de gerncia de BD tem como uma das principais funes prover acesso
e manipulao eficientes aos dados armazenados atravs de uma linguagem de
alto nvel. Deve ainda o SGBD possuir um sistema de proteo contra acessos
no autorizados alm de manter a consistncia e a integridade destes dados.
No caso dos sistemas de DW os SGBDs devem possuir ferramentas que dem

suporte a OLAP, que, conforme j mencionamos, difere de OLTP em uma srie de
requisitos.
Os SGBDs direcionados ao processamento de transaes so normalmente

dimensionados para atender a um grande nmero usurios que realizam
operaes atmicas (transaes).
No caso de um DW, o gerenciador deve ser configurado para que os poucos

usurios que fazem uso destes dados possam realizar um grande nmero de
consultas ad hoc (definidas no momento da execuo) ou pr-definidas, todas
bastante complexas e poderosas.
Para que isto seja possvel, existem ferramentas que envolvem tecnologias
complexas a fim de permitir que o usurio obtenha dados resumidos utilizando
tcnicas de aperfeioamento e combinao de mtodos de indexao, os dados
so armazenados em sistemas multidimensionais e consultados por extenses do
SQL padro.

Pode-se implementar sistemas de DW em SGBDs relacionais embora j existam

gerenciadores especializados em atender s necessidades dos sistemas de apoio
deciso, os chamados SGBDMs, ou sistemas de gerncia de BD
multidimensionais, chamados tambm de servidores MOLAP, que armazenam os
dados em matrizes ou arrays ao invs de tratar os dados em registros de tabelas
relacionadas entre si.
Pelo fato de utilizarem esta tecnologia, suas dimenses ainda no atingem o

tamanho necessrio para grandes DWs por limitaes tcnicas tanto de software
quanto de hardware o que acaba reduzindo o uso destes sistemas apenas em
sistemas de DM.
2.5. O Ciclo de vida do desenvolvimento de um Data Warehouse
No disponvel
2.6. Consideraes Iniciais para a criao de um Data Warehouse
Nosso ponta p inicial consiste basicamente na extrao dos dados das fontes de
dados internas, incluindo a transformao e a limpeza (racionalizao) dos dados.
Deve-se observar a exigncia de padronizao dos dados, geralmente distribudos
de formas distintas pelos departamentos das empresas.
Um dos itens mais importantes o repositrio dos metadados, responsvel pela

documentao de cada registro realizado na base de dados. Os metadados vo
proporcionar a segurana sobre a qualidade das informaes obtidas (Como
veremos mais adiante nesta obra)
Para que o projeto do DW obtenha sucesso necessrio escolher corretamente a

estratgia a ser adotada, esta estratgia deve ser adequada s caractersticas e
necessidades especficas do ambiente onde o DW ser implementado.
Existem vrias abordagens que podem ser utilizadas para o desenvolvimento de

um DW, mas importante fazer uma escolha fundamentada em pelo menos
quatro dimenses: escopo do DW, grau de redundncia de dados e tipo de
usurio final, etc.
O escopo de um DW pode ser to amplo quanto aquele que inclui todo o conjunto
de informaes de uma organizao ou to restrito quanto um DW pessoal
definido para um nico gerente. Quanto maior o escopo, maior o valor do DW e
por conseqncia mais cara e trabalhosa ser sua criao e manuteno.
Por isso, muitas empresas tendem a iniciar com a construo de Data Marts e s
aps obter um retorno de seus usurios, iniciam a expanso do escopo,
integrando os Data Marts em um nico DW.

Nota: Veremos os Data Marts mais adiante no capitulo de modelagem dimensional.
Quanto redundncia de dados, h essencialmente trs nveis de redundncia:
DW virtual: Consiste em simplesmente prover os usurios finais com

facilidades adequadas para extrao das informaes diretamente dos
bancos de produo, no havendo assim redundncia, mas podendo
sobrecarregar o ambiente operacional;
DW centralizado: Constitui-se em um nico banco de dados fsico contendo

todos os dados para uma rea funcional especfica, um departamento ou
uma empresa, sendo usado onde existe uma necessidade comum de
informaes. O DW central normalmente contm dados oriundos de
diversos bancos relacional-operacionais, devendo ser carregado e mantido
em intervalos regulares;
DW distribudo: P seus componentes distribudos em diferentes bancos de

dados fsicos, normalmente possuindo um grau de redundncia alto e por
conseqncia, procedimentos mais complexos de carga e manuteno.
Outro fator importante na escolha da abordagem de desenvolvimento o padro

de uso do DW. Relatrios e consultas pr-estruturadas podem satisfazer o usurio
final, e geram pouca demanda sobre o SGBD e sobre o 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, como as estruturas
altamente normalizadas, ao invs de uma estrutura mais complexa que necessite
de reconstruo a cada mudana, por exemplo, estrutura multidimensional.
O DW deve ser construdo de forma interativa, isto , no possvel definir

antecipadamente todos os requisitos necessrios sua construo at que ele
esteja parcialmente povoado e sendo utilizado pelos analistas de SAD. Portanto
ele no pode ser projetado da mesma forma como so construdos os sistemas
baseados em requisitos. Por outro lado um erro grave pensar que no
necessrio prever alguns requisitos iniciais. necessrio encontrar um meio termo
entre estes dois conceitos. Por ser projetado e carregado passo a passo, dito
que ele segue uma abordagem evolucionria.

W. Inmon indica algumas das muitas razes que mostram a importncia do

desenvolvimento seguir a abordagem evolucionria:
Histrico de sucesso das aplicaes sugere estatisticamente tal mtodo;
Usurio final no ter condies de expressar suas necessidades com

clareza at que a primeira interao seja feita;
A gerncia no se comprometer por completo at que verdadeiros

resultados tangveis e claros sejam apresentados;
H necessidade de, rapidamente, obter resultados visveis.
Muitas empresas iniciam o processo a partir de uma rea especfica, que

normalmente uma rea carente de informao e cujo trabalho seja relevante
para os negcios da empresa, criando 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 DW e deixar que os usurios analisem
minuciosamente as amostras dos dados. Somente aps a concordncia do grupo
quanto aos requisitos e funcionamento, que o DW ser de fato carregado com
dados dos sistemas operacionais na empresa e dados externos.
O modelo de processos deve ser bem analisado antes do incio do projeto pois ele
formado tipicamente por diagramas de contexto de nvel zero, diagramas de
fluxo de dados, diagramas de estrutura e outras estruturas baseadas em
requisitos. Em muitos ambientes o modelo de processos pode ser fundamental
para o desenvolvimento de sistemas, no entanto, na construo de um DW o
modelo de processos pode ser um empecilho, pois ele pressupe a existncia de
um conjunto de necessidades conhecidas antes que os detalhes do projeto sejam
definidos.
2.7. Dados Operacionais
Seria a glorias das glorias se a criao do DW consistisse em apenas extrair

dados operacionais e inseri-los no Data Warehouse. Nada poderia estar mais
longe da verdade. Um DW construdo a partir de informaes provenientes de
vrias aplicaes operacionais com dados no integrados entre si.
Quando estas aplicaes j existentes foram criadas no foi considerada a

possibilidade de uma integrao futura. Cada aplicao possui seu conjunto nico
e particular de requisitos e, durante o processo de desenvolvimento, as outras
aplicaes no eram levadas em conta.

No difcil encontrar em sistemas de uma mesma empresa dados rotulados da

mesma maneira em locais diferentes, mas que contenham as mesmas
informaes ou alguns dados que apresentem as mesmas nomenclaturas e as
mesmas informaes, contudo, com unidades de medidas diferentes. A questo
da configurao dos extratores (ETLs) ou mesmo da programao de extratores
"personalizados" para os sistemas da empresas que no so integrados pode se
tornar uma tarefa muito complexa. A imagem 15 demonstra a falta de integrao
comum ao ambiente dos sistemas existentes.
Imagem 15
Veja mais um exemplo de integrao: Um campo que tenha o objetivo de

armazenar a informao distncia. Ele pode ser definido de vrias maneiras.
Alm de poder ter qualquer titulo como rtulo ele tambm pode utilizar unidades
de medidas distintas como metros, quilmetros ou centmetros. No existe uma
preocupao especfica com o modo como o caminho ser medido do DW,
contanto que ele seja medido de forma coerente. A imagem16 apresenta o
processo de integrao dos dados que tem o mesmo significado, mas que
possuem representaes diferentes.
Imagem 16

Este exemplo apenas d uma idia da questo da integrao e por si s no

complexo. Mas quando ele se multiplica pelos milhares de arquivos e sistemas
existentes, a questo da integrao se torna extremamente complexa e
dispendiosa.
Outro importante problema da passagem de dados do ambiente operacional para

o ambiente do DW diz respeito ao acesso eficiente aos dados dos sistemas
existentes, no simples definir um mtodo que indique para os programas que
esto varrendo as bases de dados operacionais se um arquivo j foi ou no
varrido anteriormente.
H uma enorme quantidade de dados no ambiente de sistemas existentes e a

tentativa de efetuar varreduras completas toda vez que feita uma varredura para
o DW extremamente onerosa e sem duvida alguma muito mais demorada.
Para carregar e transformar os dados provindos de sistemas operacionais,

necessrio um esforo de processamento muito grande (regras de ETL), por isso
estes processos so realizados normalmente a noite, deixando os dados
disponveis para o dia seguinte. Quando os dados so transferidos para o DW a
sua caracterstica de no volatilidade faz com que os dados que so manipulados
no ambiente operacional assumam a situao de definitivos no podendo mais
sofrer alteraes.
Outra informao importante que muitos dados do ambiente operacional no

passam para o DW, pois o processo de carga efetua uma filtragem nos mesmos,
impedindo que dados redundantes ou sem valor para analise faam parte do
sistema.
No geral h trs tipos de cargas que podem ser feitas do ambiente operacional
para o dimensional (DW):
Dados histricos: O carregamento dos dados histricos do sistema

operacional para posterior descarregamento no DW no uma boa
maneira de acessar os dados dos sistemas existentes, pois alm de
sobrecarregar os sistemas on-line (transaes) tambm pode acessar
informaes que j foram carregadas para o ambiente de DW;
Dados de valor corrente: O carregamento de dados de valor corrente no

ambiente operacional feito atravs da criao de um ou mais arquivos
seqenciais com os valores atuais do sistema operacional. Este arquivo
posteriormente ser processado e descarregado no DW o que no
ocasionar danos ao ambiente on-line;

Alteraes: O carregamento de alteraes do DW a partir de atualizaes

que tenham ocorrido no ambiente operacional desde a ltima atualizao
do DW consiste no maior desafio ao arquiteto de dados. No fcil realizar
o rastreamento eficiente e o tratamento das alteraes que esto sendo
efetuadas sobre o ambiente operacional sem sobrecarreg-lo.

Captulo 3 Modelagem Dimensional
3.01. Introduo
A viso multidimensional de dados no algo to novo assim, pois a necessidade

de se obter de maneira rpida e simples, todo um histrico de informao de
nossos ambientes operacionais, faz com que as empresas busquem cada vez
mais, alternativas para organizar e acessar seus dados.
3.02. Modelagem de dados
A modelagem de dados um modo eficiente de entender os dados. O seu

propsito prover um registro apurado de aspectos do mundo real para um
contexto especifico. Atravs da modelagem, o desenvolvedor do banco de dados
pode eliminar redundncias, que representam algumas das fontes de informaes
inconsistentes e que podem levar a construo de sistemas de tomadas de
deciso ineficientes.
Um modelo de dados uma coleo de conceitos que podem ser utilizados para
descrever um conjunto de dados e as operaes para a sua manipulao. (BATINE,
CERI, NAVATHE, 1992).
A no utilizao de um modelo implica em um crescimento desorganizado das

aplicaes e seus repositrios de dados. Desta forma as aplicaes demandam
altos custos, para a sua manuteno e crescimento. O modelo permite ao usurio
um melhor entendimento do negcio, com a vantagem de facilitar a visualizao
das ocorrncias e qualquer ao dentro do ambiente dimensional. Podemos
ressaltar tambm as excepcionais vantagens de se prever os impactos de
qualquer mudana sobre o ambiente operacional.
O modelo representa a definio, caracterizao e relacionamento dos dados em

um determinado ambiente. Um dos diagramas mais empregados na modelagem
de dados o Diagrama de Entidade e Relacionamento (DER).
Tradicionalmente, a modelagem de dados empregada em trs nveis no

ambiente operacional. Esta modelagem se inicia por um diagrama de alto nvel
relacionado rea do assunto, denominado modelo conceitual, seguido por uma
camada intermediria, denominada modelo lgico, at a camada do modelo fsico,
que representa o modo como os dados sero armazenados.
Atualmente, existe uma tendncia nas metodologias de desenvolvimento de DW

em aplicar este tipo de modelagem.

Nessas metodologias, o modelo conceitual do DW seria representado pelo modelo

corporativo e os modelos lgico e fsico pelo esquema estrela (modelo
dimensional).
A seguir so apresentadas caractersticas dos modelos conceitual, lgico e fsico

empregados nos ambientes operacionais:
1. Modelo Conceitual: O modelo conceitual aquele que apresenta os

objetos, suas caractersticas e relacionamento como uma representao fiel
ao ambiente observado. Este modelo no se preocupa com os aspectos
relacionados implementao, como por exemplo, estruturas fsicas e
formas de acesso de um SGBD especfico (COUGO, 1997) Atravs deste
modelo possvel criar uma descrio da realidade fcil de entender e de
interpretar (BATINE, CERI, NAVATHE, 1992). O modelo conceitual, em particular, tem
sido representado atravs do Diagrama de Entidade/Relacionamento
(DER).
2. Modelo Lgico: O modelo lgico aquele onde os objetos, suas

caractersticas e relacionamentos apresentam uma representao de
acordo com as regras de implementao e limitaes impostas por alguma
tecnologia (COUGO, 1997). Ele descreve as estruturas que comporo o banco
de dados, sem considerar nenhuma caracterstica especfica de um SGBD
(MACHADO, ABREU, 1996). O modelo lgico , normalmente representado por uma
estrutura relacional, hierrquica ou em rede, sendo a modelagem relacional,
a mais empregada atualmente.
A diferena entre o modelo conceitual e o lgico, entretanto, no to fcil de ser

observada. Com o emprego das ferramentas CASE, o que se observa atualmente
o desenvolvimento de uma modelagem conceitual, muito prxima modelagem
relacional. O que no incorreto, desde que o modelo conceitual se concentre em
representar os conceitos e caractersticas de um dado ambiente (COUGO, 1997).
Em um modelo lgico, normalmente se observa informaes sobre chaves de

acesso, controle de chaves duplicadas, itens de repetio, normalizao e
integridade.
3. Modelo Fsico: O modelo fsico aquele em que a representao dos

objetos feita sob o foco do nvel fsico de implementao das ocorrncias,
ou instncias, das entidades e seus relacionamentos. O conhecimento do
modo fsico de implementao das estruturas de dados ponto bsico para
o domnio deste modelo (COUGO, 1997).
Este modelo descreve, a partir do modelo lgico, as caractersticas fsicas

associadas ao armazenamento/acesso a dados, como, por exemplo, ndices,
mtodos de acesso e distribuio fsica.

3.03. Modelagem Dimensional
A modelagem dimensional representa o modo como s informaes existentes em

uma empresa sero modeladas e tratadas. O objetivo principal desta modelagem
a elaborao de um projeto de banco de dados consistente (DW), que permita
atingir, de modo preciso, vises multidimensionais para o usurio final. O modelo
final deve ser, portanto, facilmente entendido e interpretado pelos
desenvolvedores e usurios finais.
Qual seria ento uma boa definio para modelagem dimensional? ... uma
tcnica de projeto lgico que procura apresentar dados de uma forma comum, que
intuitiva para as pessoas que a acessam e que permita o acesso a informao
com alto desempenho.
A modelagem dimensional e muito diferente da modelagem transacional

(Entidade-Relacionamento E/R), que procura eliminar redundncias de forma a
economizar espao. Essa eliminao de redundncias tem como efeito a criao
de diversas entidades dentro da modelagem, o que torna mais difcil a
compreenso do modelo por usurios que no tenham nvel avanado. A
modelagem E-R faz com que as recuperaes SQL possuam joins mais
complexos, com a unio de diversas tabelas, o que torna o resultado mais
demorado.
Em um DW, a modelagem deve ser analisada e implementada para atender todas

as necessidades do negcio. No existe um modelo certo ou errado. O que existe
o entendimento do negcio no seu nvel mximo de detalhamento, que deve ser
traduzido em uma base de dados dimensional, que por sua vez, formatada e
agrupada, na forma de objetos do banco de dados, possam ser armazenadas e
disponibilizadas ao usurio final de forma rpida e simples.
Veja abaixo os componentes do modelo dimensional:
Fatos: so observaes decorrentes do andar do negcio. No so

conhecidas de antemo, ou seja, no se sabe o seu valor at que se tenha
acontecido. Compe-se basicamente de campos numricos. Ex: quantidade de
produtos vendidos.
Atributos do negcio: so as descries das caractersticas do negcio.

So conhecidos previamente e so caracterizados por campos textuais. Ex: nome
do produto.
Tabelas do modelo dimensional:
1. Tabelas Fato: so as tabelas que guardam os dados do negcio. Todas as

informaes decorrentes do andamento do negcio que no so
conhecidas previamente. Os fatos podem ser aditivos, ou seja, podem ser
acumulados, alm de terem valores contnuos.

2. Tabelas Dimenso: so as tabelas que guardam os atributos do negcio.

Elas podem ser usadas para restringir as pesquisas feitas nos tabelas Fato
e servem como ttulos em colunas.
Existem vrias formas de representao para os dados em ambientes de banco

de dados convencionais. Podemos generalizar sem perder informaes da
seguinte maneira:
Datas e Horas: uma das principais caractersticas de um DW atravs das

suas operaes poder analisar historicamente os dados. Como as possibilidades
de anlise so atribudas a restries das dimenses e possibilidade de agrupar
os dados, ento as datas e horas so sempre bom indcio de atributos de
dimenso, no de fatos.
Textuais: os dados textuais so descries de fcil compreenso humana,

logo natural que sejam utilizados para descrio de elementos do negcio.
Como as possibilidades de anlise so atribudas a restries das dimenses e
possibilidade de agrupar os dados, ento as descries textuais so sempre bom
indcio de atributos de dimenso, no de fatos.
Fatos Aditivos: so numricos e podem ser somados em relao s

dimenses existentes, pois sua semntica permite tais operaes. Sempre que em
uma modelagem um dado numrico for apresentado ento este ser um bom
indcio de um atributo em fatos. Em geral, fatos aditivos representam medidas de
atividade do negcio. Ex. Valor Venda, Quantidade de produtos vendidos.
Fatos Semi-Aditivos: tambm so numricos, mas no podem ser

somados em relao a todas as dimenses existentes, pois sua semntica no
permite. Em geral, fatos semi-aditivos representam leituras medidas de
intensidade do negcio. So snapshots destas leituras que entram no DW. O valor
atual j leva em considerao valores passados. Ex. Nvel de Estoque,
Fechamento dirio/mensal de conta.
Fatos No-Aditivos: algumas observaes no so numricas que

tambm no so datas/horas podem eventualmente ser fatos dos eventos.
Campos textuais de livre formato so ruins quer seja para dimenses ou fatos. Em
geral, campos como obs so exemplos desta situao, pois o domnio irrestrito.
Ex. Em um DW para registrar acidentes de transito temos: carro 1, carro 2, moto 1,
moto 2., hora/data, descrio do acidente, descrio do tempo (chuva,...) e
descrio da pista.

Aditivos Semi-Aditivos No-Aditivos

Numricos Numricos Textual e Lgico
Somas Mdia Contagem
Bons Fatos Fatos Razoveis Fatos Ruins
Fcil Navegao Navegao Mdia Navegao Mdia
3.04. Processo da Modelagem Dimensional
O processo de modelagem de dados dimensional se inicia com a anlise dos

modelos de dados existentes no ambiente operacional (Transacional), sendo ideal
a utilizao do modelo de dados corporativo da empresa. Algumas empresas,
porm, no possuem esses modelos para os sistemas antigos, ou mesmo
apresentam o prprio modelo corporativo dividido em modelos menores, em
virtude de seu porte.
Para estes casos necessrio analisar os DER dos sistemas relacionados rea
a ser incorporada ao DW. A anlise destes modelos permitir uma melhor base
para o conhecimento do negcio e para um gil desenvolvimento do DW. Atravs
da anlise do(s) DER elaborado um "pr-modelo de dados" responsvel pela
integrao entre o ambiente operativo (viso processo) e o DW (viso negcio).
O(s) modelo(s) multidimensionais, que constituiro o DM, derivado a partir deste
"pr-modelo".
Com a concluso do DM, efetua-se a integrao do(s) novo(s) modelo(s) ao

modelo do DW.
Para melhor tratar a questo de integrao entre o ambiente operativo e o DW, as

diretrizes do processo de modelagem foram divididas em quatro (4) fases. As
seguintes fases compem a modelagem:
FASE A - Estudo dos Modelos Existentes: Esta fase responsvel por delimitar o
escopo do modelo corporativo ou dos DER relacionados aos sistemas existentes.
Este escopo representa a rea de interesse para a anlise. Para se iniciar esta
fase, as seguintes condies devem ser atendidas:
rea de interesse definida pelo usurio final;

Necessidades de anlise. Quando no houver uma definio formal,
necessrio o levantamento dos tipos mais comuns de anlises solicitadas
pelo usurio final;
Modelo corporativo ou DER de sistemas existentes.
FASE B - Elaborao do pr-modelo: Esta fase a responsvel por analisar e

integrar os DER dos sistemas operativos que compem a rea de interesse. Essa

integrao responsvel pela criao de um pr-modelo. O pr-modelo se

caracteriza por ser um DER no normalizado, com caractersticas peculiares. Para
a realizao desta fase necessrio que o projetista apresente um conhecimento
razovel do negcio, que lhe permita tomar decises com o auxlio dos usurios
finais.
FASE C - Modelagem do DM: Esta fase a responsvel por estabelecer um

conjunto de vises dimensionais. Aps a validao das vises dimensionais, pelos
usurios finais, os modelos dimensionais sero derivados, a partir do "pr-
modelo", empregando o esquema estrela. O modelo dimensional do DM
representado pela composio dos modelos dimensionais desenvolvidos para
atender s vises dimensionais. Para a realizao desta fase, o projetista deve
avaliar criteriosamente as necessidades levantadas pelo usurio final e possuir o
pr-modelo.
FASE D - Integrao do DM ao DW: Esta fase corresponde atualizao do DW,

de acordo com a construo de um novo DM. Representa o desenvolvimento
incremental do DW. Como dois modelos estaro disponveis, o pr-modelo e o
modelo dimensional do DM, a atualizao do DW pode ser realizada adotando a
viso de Inmon ou a viso de Kimball. Esta fase apresenta tambm consideraes
sobre as mudanas estruturais usuais durante o desenvolvimento de um ADW.
A modelagem dimensional independe do SGBD onde ser implementada. O
modelo final pode ser inserido em um SGBD relacional ou em um SGBD
multidimensional. O esquema estrela , normalmente, empregado para
representar esta modelagem.
Nota: Mais adiante veremos os tipos de esquemas existentes para amodelagem dimensional
A modelagem dimensional torna as operaes realizadas pelas ferramentas do

DW, muito mais simples, como por exemplo:
Rollup: Permite que o usurio reduza o nvel do escopo da anlise. Ele

sobe o nvel de detalhamento, ou seja, incrementa o nvel de agregao;
Drill-Down/Drill-Up: Caminho inverso do Rollup, permitindo que o usurio

navegue entre os nveis de detalhamento ao analisar. Com o Drill Down
voc pode subir ou descer dentro do detalhamento do dado, como por
exemplo, analisar uma informao tanto por dia como semestralmente ou
ainda por ano, partindo da mesma base de dados.
Slice-Dice: Seleo e projeo. Os dados no DW devem ser projetados de

modo a permitir consultas que combinem e separem as informaes,
atravs de qualquer medio possvel do negcio.
Pivot (pivoteamento): Permite que o usurio reorganize a disposio das

dimenses para uma nova viso dos dados.

Viso AD HOC: Segundo Inmon So consultas com acesso casual nico e

tratamento dos dados segundo parmetros nunca antes utilizados,
geralmente executados de forma interativa e heurstica.
Observe diversas dimenses separadamente no exemplo da imagem abaixo.
Imagem 01
3.05 Processo de modelagem de um Dara Warehouse
O projeto de um DW envolve a seleo de componentes que constituiro o

ambiente, a seleo de uma abordagem para a construo dos componentes
selecionados e a definio do tipo de modelagem de dados a ser empregada nos
repositrios. Uma breve descrio do que trata cada uma destas etapas descrita
a seguir:
Seleo dos componentes: realizada atravs de um estudo das reas de

interesse que iro compor o DW. De acordo com o nmero de reas, o
volume de informaes e os sistemas operativos existentes possvel
realizar uma estimativa de necessidade de repositrios;
Seleo da abordagem para a construo dos componentes: a abordagem
"bottom-up" a mais recomendada, pois permite balancear a relao custo
x benefcio, apresentando resultados rpidos e conquistando investimentos
a nvel pessoal e financeiro; e
Definio da modelagem a ser empregada: conforme j mencionado, existe
um consenso quanto ao emprego da modelagem multidimensional para os
DM.
Entretanto, para o DW, a modelagem varia de acordo com sua aplicabilidade,

podendo ser aplicada a viso Inmoniana ou a viso Kimballiana. A observao de
experincias de desenvolvimento de DW demonstra que o conhecimento do
negcio alcanado, atravs da anlise dos modelos de dados existentes no

ambiente operativo. Esses modelos permitem agilizar o desenvolvimento e

garantir a simplicidade para novas interaes.
O DW acessa dados operativos, que so transformados e integrados para

gerarem dados informativos e analticos. A integrao entre os modelos do
ambiente operativo e o ADW garante que esse processo funcione da melhor forma
possvel. O processo de modelagem deve, portanto, transformar modelos de
dados orientados a processo, os modelos funcionais, para modelos de dados
orientados a negcio, os modelos dimensionais.
Atravs da modelagem de dados realiza-se a transformao de uma viso de

processo em uma viso de negcio. Essa transformao est representada na
Imagem 3.8.
Conforme apresentado na imagem 02, o DW o centralizador de dados,

apresentando diferentes propostas de modelagem: a modelagem dimensional
(viso Kimball) e a modelagem no totalmente normalizada, porm sem ser
dimensional (viso Inmon-Graziano). A deciso sobre qual melhor modelo aplicar
ao DW uma deciso de projeto, variando caso a caso, de acordo com as
necessidades da empresa.
Os dados no DW representam uma composio de seus repositrios, sendo a

fase da modelagem responsvel por garantir a integrao e consolidao dos
mesmos. Essa garantia obtida atravs do emprego de metadados que permitem
o gerenciamento e controle dos dados, desde o ambiente operativo at a sua
viso pelo usurio final.

Imagem 02
O processo de modelagem deste ambiente realizado com base nos requisitos e

nas necessidades estabelecidos pelos usurios finais. O ponto de partida a
anlise dos modelos de dados do ambiente operativo. A partir desta anlise so
obtidos os dados que sero trabalhados, consolidados e sumarizados.
Esses dados comporo o modelo do DW, na abordagem "top-down" ou o modelo

do DM, na abordagem "bottom-up".
A abordagem "top-down" cria os DM a partir do modelo de dados do DW. A

abordagem "bottom-up", desenvolve os DM independentemente, realizando a
integrao do seu modelo de dados ao modelo do DW.
Para auxiliar o processo de modelagem, os desenvolvedores devem se manter

atentos com relao aos seguintes itens:
Estabelecer o escopo do DW. Este escopo se refere definio dos

componentes que integraro o ambiente, seleo da abordagem de

desenvolvimento a ser empregada e ao tipo de modelo a ser utilizado em

cada um dos repositrios do ambiente.
Garantir que a modelagem de dados do DW represente a viso negcio.

Deve ser possvel extrair do DW ou dos DM, as vises multidimensionais
solicitadas pelo usurio final;
Integrar as fontes de dados dos sistemas operativos e fontes externas.

importante observar que a otimizao da integrao, implica diretamente
em acelerar a disponibilidade dos dados para as consultas dos usurios
finais (resultados);
arantir a disponibilidade das informaes finais para aplicativos,

G
ferramentas OLAP e Data mining. Para isso a modelagem dos dados
devem se preocupar com questes quanto a facilidades de uso e a
transformao dos dados;
arantir que a modelagem do ambiente seja capaz, de rapidamente,

G
ajustar-se a mudanas nos negcios.
A seguir sero apresentadas as abordagens da modelagem de dados para DW e

DM existentes na literatura atual. A modelagem do DW apresentada segundo a
abordagem de Kimball, ou seja, empregando um modelo dimensional.
3.06. Tipos de arquitetura
De uma forma geral, a arquitetura do DW ainda est em evoluo. Esta evoluo

pode ser considerada como uma resposta crescente complexidade deste
ambiente e s dificuldades de integrao entre todos os componentes.
Os desenvolvedores deste ambiente devem se preocupar em como integrar o DW

s diversas fontes heterogneas e externas, aos DM, ODS, aplicaes servidoras,
"WEB" e "data mining", entre outros tipos de ferramentas disponveis
(FIRESTONE, 1998-b).
As arquiteturas "top-down", "bottom-up" e intermediria so propostas para o

desenvolvimento deste ambiente. Variaes destas arquiteturas esto sendo
avaliadas,sendo que uma arquitetura no inviabiliza a outra. Entretanto, a
variedade de opes requer uma anlise mais apurada do problema, para se
avaliar qual a arquitetura mais adequada empresa. A escolha da arquitetura
fator importante na seleo da tecnologia apropriada para o desenvolvimento e a
implantao deste ambiente.
Atualmente, considera-se que os problemas do DW esto mais relacionados com

a arquitetura do que com a tecnologia disponvel (MELLO, 1997).

3.06.1. Arquitetura "Top-Down"
A arquitetura "Top-Down" a arquitetura conhecida como arquitetura padro.
Nesta arquitetura o processo se inicia com a extrao, a transformao e com a

integrao das informaes dos sistemas operativos e dados externos para um
ODS. A seguir, os dados e metadados so transferidos para o DW.
Imagem 03
Nesta concepo, o DW armazena uma camada de dados atmicos e detalhes

histricos. A partir do DW so extrados os dados e metadados para os DM.
Nos DM, as Imagem 03 Arquitetura Padro, empregando ODS informaes

esto em um maior nvel de sumarizao e, normalmente, no apresentam o nvel
histrico encontrado no DW (INMON, 1998). A imagem 03 apresenta a arquitetura
padro empregando o ODS. A seguir so apresentadas as vantagens e
desvantagens desta arquitetura segundo Hackney (HACKNEY, 1998):
Vantagens:
Herana de arquitetura - Todos os DM originados a partir de um DW,

utilizam a arquitetura e os dados deste DW, permitindo uma fcil
manuteno;
Viso de empreendimento - O DW concentra todos os negcios da

empresa, sendo possvel a partir dele extrair nveis menores de
informaes;
Repositrio de metadados centralizado e simples - O DW prov um

repositrio de metadados central para o sistema. Esta centralizao permite

manutenes mais simples do que aquelas realizadas em mltiplos

repositrios;
Controle e centralizao de regras - A arquitetura "top-down" garante a
existncia de um nico conjunto de aplicaes para extrao, limpeza e
integrao dos dados, alm de processos centralizados de manuteno e
monitorao.
Desvantagens:
Implementao muito longa - Os DW so, normalmente, desenvolvidos de

modo iterativo, por reas de assuntos, como por exemplo, vendas, finanas
e recursos humanos. Mesmo assim, so necessrios, em mdia, 15 ou
mais meses para que a primeira rea de assunto entre em produo,
dificultando a garantia de apoio poltico e oramentrio;
lta taxa de risco - No existem garantias para o investimento neste tipo de

A
ambiente;
Heranas de cruzamentos funcionais. necessria uma equipe de

desenvolvedores e usurios finais, altamente capacitados para avaliar as
informaes e consultas que garantam empresa habilidade para
sobreviver e prosperar na arena de mudanas de competies polticas,
geogrficas e organizacionais;
Expectativas Relacionadas ao Ambiente - A demora para concluso do

projeto e a falta de retorno pode induzir expectativas nos usurios.
3.06.2. Arquitetura "Bottom-Up"
Em virtude da arquitetura "top-down" ser politicamente difcil de ser definida e

muito cara, requerendo um tempo grande para implementao, investimento e
sem apresentar retorno rpido, a arquitetura "bottom-up" vem se tornando muito
popular. A imagem 04 apresenta a arquitetura "bottom-up".
O propsito desta arquitetura a construo de um DW incremental a partir do

desenvolvimento de DM independentes.
O processo comea com a extrao, a transformao e a integrao dos dados

para um ou mais DM, sendo estes DM modelados, normalmente, atravs de um
modelo dimensional.
Um dos grandes problemas desta arquitetura a falta de um gerenciador que

garanta padres nicos de metadados, mesmo com a independncia dos DM.

A dificuldade em se garantir essa padronizao responsvel pela falha na

elaborao incremental do DW. A seguir so apresentadas as vantagens e
desvantagens desta arquitetura segundo Hackney (HACKNEY, 1998):
Arquitetura "Bottom-Up"
Imagem 04
Vantagens:
Implementao rpida - A construo dos DM altamente direcionada,

permitindo um rpido desenvolvimento. Normalmente, um DM pode ser
colocado em produo em um perodo de seis a nove meses;
Retorno Rpido - A arquitetura baseada em DM com incremento demonstra

rapidamente seu valor, permitindo uma base para investimentos adicionais,
com um nvel mais elevado de confiana;
Manuteno do Enfoque da Equipe - Um dos maiores desafios do

desenvolvimento de um ADW a manuteno do mesmo enfoque por toda
a equipe. A elaborao de DM incrementais, permite que os principais
negcios sejam enfocados inicialmente, sem que haja gastos no
desenvolvimento de reas que no so essenciais ao problema;
erana Incremental - A estratgia de DM incrementais obriga a entrega de

H
recursos de informao, passo a passo. Isto permite a equipe crescer e
aprender, reduzindo os risco. A avaliao de ferramentas, tecnologias,
consultores e vendedores s devem ser realizados uma vez, a no ser que
existam restries que impeam o reaproveitamento.

Desvantagens:
Perigo de LegaMarts - Um dos maiores perigos no DW a criao de DM

independentes. O advento de ferramentas de "drag-and-drop" facilitou o
desenvolvimento de solues individuais, de acordo com as necessidades
da empresa. Estas solues podem no considerar a arquitetura de forma
global. Desta forma, os DM independentes transformam-se em DM legados,
ou LegaMarts. Os LegaMarts dificultam, quando no inviabilizam futuras
integraes. Eles so partes do problema e no da soluo;
Desafio de Possuir a Viso de Empreendimento - Durante a construo dos

DM incrementais necessrio que se mantenha um rgido controle do
negcio como um todo. Este controle requer um maior trabalho ao extrair e
combinar as fontes individuais do que utilizar um DW;
Administrar e Coordenar Mltiplas Equipes e Iniciativas - Normalmente,

esse tipo de arquitetura emprega o desenvolvimento de DM em paralelo.
Isto pode conduzir a uma rgida administrao tentando coordenar os
esforos e recursos das mltiplas equipes, especialmente nas reas de
regras e semntica empresariais;
Maldio de Sucesso - A arquitetura com DM incrementais carrega a "

A
maldio de sucesso". Nestes casos, os usurios finais do DM encontram-
se felizes querendo mais informao para seus DM. Ao mesmo tempo,
outros usurios de outros DM aguardam o incremento de seus DM. Isto
conduz a equipe de DM a vencer desafios polticos, de recurso e de
administrao.
Muitas das novas abordagens propostas baseiam-se na arquitetura "bottom-up".

Elas procuram melhorar o processo de desenvolvimento e garantir a consistncia
dos metadados e facilidade de integrao do ambiente.
A arquitetura de DM para empresa ("Enterprise Data Mart Architecture" - EDMA) e

a arquitetura de armazenamento de dados/ DM ("Data Storage/Data Mart" -
DS/DM ) so bons exemplos dessas novas abordagens (FIRESTONE, 1998-b).
A seguir essas arquiteturas so apresentadas em maiores detalhes.
3.06.2.1. Enterprise Data Mart Architecture (EDMA)
a) EDMA: A EDMA uma evoluo da arquitetura "bottom-up", que emprega a

abordagem incremental para o DW pelo desenvolvimento de DM, utilizando um
"framework" compartilhado.

Imagem 05
Este "framework" inclui reas de assunto da empresa, dimenses comuns,

mtricas, regras de negcio e fontes de dados. Seu principal objetivo garantir
uma padronizao dos metadados utilizados na construo do ambiente,
permitindo o desenvolvimento incremental do DW, com margens mnimas de
duplicidade e inconsistncia de informaes. A EDMA uma arquitetura que
introduz o DDS substituindo o conceito do ODS original. A imagem 05 apresenta
esta arquitetura.
3.06.2.2. Data Storage/Data Mart (DS/DM)
A arquitetura DS/DM muito similar arquitetura EDMA, entretanto ela substitui o

DW por uma viso que representa uma conjuno lgica de DM. A arquitetura
DS/DM representada pela imagem 06.
Para autores como Inmon (INMON, 1998), a idia de um DW como um conjunto

integrado de DM muito difcil de ser implantada, dadas as caractersticas
especficas de cada DM.
- Arquitetura "Data Storage/Data Mart" DS/DM

Imagem 06
3.06.3. Arquitetura intermediria
Esta arquitetura tem o propsito de integrar a arquitetura "top-down" com a

"bottom-up". Nesta abordagem efetua-se a modelagem de dados do DW, sendo o
passo seguinte implementao de partes desse modelo. Estas partes so
escolhidas por rea de interesse e constituem os DM. Cada DM gerado a partir do
modelo de dados do DW integrado no modelo fsico do DW. A principal
vantagem desta abordagem a garantia da consistncia dos dados. Esta garantia
obtida em virtude do modelo de dados para os DM ser nico, possibilitando
realizar o mapeamento e o controle dos dados.
3.07. Data Marts
Os Data Marts (DM) podem ser considerados Data Warehouses

departamentalizados. Como por exemplo, menor volume de dados e padro de
uso bastante previsvel. Eles necessitam de tecnologia mais simples e barata, face
a esse menor volume de dados. Seu desenvolvimento e mais rpido e os
resultados mais palpveis a curto prazo.
Observem a imagem 07. Veja como os data marts se apresentam na viso

estrutural, onde aplicaes hipotticas os alimentam
Os data marts tem muito apelo, porque eles podem ser construdos de forma
simples, rpida e barata. Atualmente j se fala em "canned data marts", ou "data
marts enlatados", que seriam ferramentas extremamente simples e baratas,
destinadas a atender a necessidades bastante estruturadas (Radding, 1999).
Durante algum tempo, esses data marts independentes foram muito populares.
Mas, logo sua arquitetura se mostrou falha: quando uma corporao construa

vrios desses data marts, o volume de redundncia de dados (quase sempre

dados analticos) crescia muito, como crescia o nmero de programas que faziam
o interface entre essas estruturas e os sistemas legados; tambm cresciam os
recursos de hardware envolvidos.
J do ponto de vista da organizao, o problema maior talvez seja o de se ter

reas tomando decises a partir de nmeros diferentes, gerados em funo da
redundncia - quer por erros, quer por diferentes graus de atualizao ou critrios
de tratamento de dados (o exemplo clssico, embora possa no ser o melhor para
esse tema, o arredondamento versus truncamento de valores).
Imagem 07
Constatada essa realidade, percebeu-se que os data marts independentes no

eram a soluo, evoluindo-se ento para o conceito de data marts dependentes.
Em uma arquitetura desse tipo, h um warehouse central que alimenta os marts
dependentes; chamada tambm arquitetura "hub-and-spoke" (cubo-e-raio), onde
os marts so os raios e o warehouse, o cubo.
Como vantagem dessa estrutura, apresenta-se a integrao de dados no cubo e

autonomia de processos e nenhuma redundncia de dados nos raios. Os padres
gerais de design de banco de dados ditaram os caminhos de evoluo e
sofisticao do ambiente de warehousing; em seus primeiros tempos, a
normalizao de dados clssica era a base para a estruturao; quando a
arquitetura cubo/raio evoluiu, o padro passou a ser a normalizao e "star join"
para o cubo e 'snowflake" para os raios.
Uma vez que o warehouse j esteja construdo, a prxima etapa ser sua
explorao, no sentido de buscar, utilizar, as informaes nele contidas. Esse
trabalho, que chamado "data mining", permite descobrir padres importantes,
relaes de causa e efeito que vinham passando despercebidas, tendncias em
longo prazo, etc., de forma a permitir a melhoria dos processos.

preciso ter em mente que as diferenas entre data mart e data warehouse so
apenas com relao ao tamanho e ao escopo do problema a ser resolvido.
Portanto, as definies dos problemas e os requisitos de dados so
essencialmente os mesmos para ambos. Enquanto um data mart trata de
problema departamental ou local, um data warehouse envolve o esforo de toda a
companhia para que o suporte decises atue em todos os nveis da
organizao. Sabendo-se as diferenas entre escopo e tamanho, o
desenvolvimento de um data warehouse requer tempo, dados e investimentos
gerenciais muito maiores que um data mart.
A crescente popularidade desses mal definidos (entendidos), data marts sobre a

popularidade dos grandes sistemas de data warehouses corporativos baseada
em muitos bons motivos:
Os data marts tm diminudo drasticamente o custo de implementao e

manuteno de sistemas de apoio deciso e tm os posto ao alcance de
um nmero muito maior de corporaes.
Eles podem ser prototipados muito mais rpido, com alguns pilotos sendo
construdos entre 30 e 120 dias e sistemas completos sendo construdos
entre 3 e seis meses.
Os data marts tm o escopo mais limitado e so mais identificados com

grupos de necessidades dos usurios, o que se traduz em esforo/time
concentrado.
Os departamentos autnomos e as pequenas unidades de negcio

freqentemente preferem construir o seu prprio sistema de apoio deciso via

data marts (clulas de BI). Muitos departamentos de informtica esto vendo a

efetividade desta aproximao entre os dois mundos e esto construindo o data
warehouse por assunto ou um data mart por vez, gradualmente ganhando
experincia e garantindo o suporte dos fatores chave de gerenciamento e vendo,
ento, benefcios concretos muitas vezes ao ano. Comeando com planos
modestos e os desenvolvendo na medida em que se adquire mais conhecimento
sobre as fontes de dados e as necessidades dos usurios faz com que as
organizaes justifiquem os data marts na medida em que progridem.
Veja abaixo o esquema de um DW pela viso de Kimball
Data Marts
DW = Operational Data Store + Data Marts Integrados
Integrados
Marketing
Integrao
&
Vendas
Sistemas Transformao
Operativos
ODS Finanas
Produo
Histrico (no temporrio)

R.H.
Alto nvel de detalhe
...
3.08. Gerando o modelo dimensional atravs do StarSchema
O modelo dimensional representado pelos esquemas Star (Estrela), Snowflake

(Floco de neve) ou por suas variaes. A composio tpica do modelo Estrela possui
uma tabela central denominada Fatos (fact table) e um conjunto de entidades
denominadas Dimenso (dimension tables), na formato de uma estrela.
Partindo do modelo de negcios existente na organizao, projetado atravs do

modelo ER (Entidade-Relacionamento), analisam-se as dimenses que podem vir a
fazer parte do processo, e como podem ser agregados os valores detectados.
Inicialmente, as dimenses so consideradas de maneira geral, para posterior
detalhamento de atributos e suas hierarquias.
Para a gerao do modelo dimensional, a proposta baseia-se no padro de ambiente

de DW, que gerado a partir do ambiente operacional, com o modelo do negcio.

Deve existir a correlao entre os esquemas conceituais do banco de dados

operacional, observando os atributos das entidades e relacionamentos que identificam
fatos em um esquema ER. Essa anlise pode indicar dimenses implcitas no negcio
a ser modelado. Para gerar o modelo dimensional, portanto, faz-se necessrio
desmontar hierarquias, que so os relacionamentos normalizados do modelo ER,
anexando as informaes relevantes s tabelas Fatos ou Dimenso correspondentes.
Essa fase da metodologia caracteriza-se pela definio dos aspectos inicias do

modelo de negcio, que correspondem definio da granularidade, dimenses e
fatos.Tambm so estabelecidas as medidas de derivao.
O esquema estrela uma estrutura simples, com poucas tabelas e ligaes

("joins") bem definidas, que permite:
Facilidade de leitura e entendimento, no s pelos analistas, como por

usurios finais no familiarizados com estruturas de banco de dados ;
Um projeto de um banco de dados com uma viso mais prxima do
usurio final;
Criao de um banco de dados que propicie consultas rpidas, realizadas
de modo eficiente e intuitivo pelo usurio final;
Entendimento e "navegao" dos metadados pelos desenvolvedores e
usurios finais;
Utilizao de uma srie de ferramentas "front-end", desenvolvidas
especialmente para atender a este tipo de modelo.
Este esquema, entretanto, apresenta dificuldades com as dimenses, quando as

mesmas so muito grandes ou aparecem em grande nmero. Os sistemas que
apresentam estas caractersticas no devem forar a utilizao deste esquema
(POE, KLAUER, BROBST, 1998).
Alm disso, este esquema no apresenta uma forma clara de tratar hierarquias
implcitas.
O nome "Estrela" est associado disposio fsica do modelo, que consiste de

uma tabela central, a tabela de fatos, que se relaciona com "n" tabelas de
dimenses. A imagem 08 apresenta este esquema.
O esquema estrela pode representar tanto o modelo lgico, como o modelo fsico
do banco de dados (KIMBALL, 1997).
A representao mais simples de um modelo dimensional contm um esquema

estrela com uma tabela de fatos relacionada com tabelas de dimenses. Na
verdade, um modelo dimensional pode ser representado por uma ou mais tabelas
de fatos, relacionadas com tabelas de dimenses. Entretanto, a viso de um
esquema por vez torna o modelo mais claro.

Imagem 08
3.08.1. Variaes do StarSchema
Abaixo segue uma pequena explicao sobre as variaes do Esquema Estrela:
A. Esquema Estrela com mltiplas tabelas fato: acontece quando

existem fatos no relacionados tornando possvel existir mais de uma
tabela fato ou quando a freqncia de carga dos dados operacionais
distinta. Ex. tabela fato de vendas e tabela fato de vendas previstas.
B. Tabelas Associativas: algumas chaves podem ser desdobradas na

tabela fato quando existem relacionamentos muitos - para - muitos.

C. Esquema Estrela com tabelas Externas: nesse esquema uma ou mais

tabelas dimenso podem conter uma chave estrangeira que referencia a
chave primria de outra tabela dimenso, podendo tambm ser
chamada de tabela dimenso secundria.
D. Esquema floco de neve: o esquema floco de neve uma variao do

esquema estrela no quais todas as tabelas dimenso so normalizadas
na terceira forma normal (3FN). Reduzem a redundncia, mas
aumentam a complexidade do esquema e conseqentemente a
compreenso por parte dos usurios. Elas dificultam as implementaes
de ferramentas de visualizao dos dados. Impossibilitam o uso de
esquemas de indexao mais eficientes como o bitmap indexing.
E. Tabela Multi - Estrela: so assim chamadas quando a chave da tabela

fato complementada por mais campos que no so dimenses.
F. Constelaes: quando existem mltiplas tabelas fato que compartilham

as mesmas dimenses, dizemos que o esquema de constelaes de
fatos. Isto acontece quando as medidas nas tabelas fatos possuem
diferenas em relao aos eventos geradores: Ex: vendas realizadas x
vendas previstas ou venda unitria x desconto por venda conjunta.
3.08.2. Vantagens do modelo StarSchema
Veja algumas das principais vantagens de se utilizar o modelo Straschema para a

modelagem dimensional de seus DWs:
O modelo Estrela 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;
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 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:
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 de
forma a acomodar as mudanas;

Todas as aplicaes que existiam antes das mudanas continuam

rodando sem problemas;
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;
Outra vantagem o fato de um nmero cada vez maior de utilitrios

administrativos e processo de software serem capazes de gerenciar e usar
agregados, que so de suma importncia para a boa performance de
respostas em um data warehouse.
3.08.3. Tabela de fatos
A tabela de fatos representa as informaes que sero avaliadas, sendo,

normalmente, constituda de valores numricos que representam os objetos da
anlise, como por exemplo, total de vendas, total de movimentao, mdia,
mximos ou mnimo de valores. Algumas vezes possvel encontrar tabelas de
fatos sem valores numricos, nesses casos, normalmente, a tabela de fatos
empregada para mapear eventos. (KIMBALL, 1997)
A tabela de fatos normalmente grande, apresentando muitos registros. Esta

tabela contm as informaes bsicas do nvel de transao do negcio, de
interesse particular a uma aplicao. Uma caracterstica importante da tabela de
fatos a esparsidade, dessa forma, quando no existem valores para um
cruzamento de dimenses, no so armazenados zeros. A tabela de fatos
armazena as medies numricas totalmente focadas para o negcio.
Os desenvolvedores no geral devem dar preferncia aos atributos que

representem valores de adio, ou seja, atributos que permitam o incremento de
dados.
Segundo Kimball (KIMBALL et al, 1998), os fatos podem ser classificados em transaes
individuais, "snaphots", linhas de itens.

As transaes individuais, normalmente, apresentam uma estrutura muito simples,

com um campo acumulado que contm o valor da transao.
Os fatos "snapshots" representam medidas de atividades extradas em tempo

determinado, como, por exemplo, fim do dia ou fim do ms.
Os fatos do tipo "linhas de itens" so aqueles que representam exatamente uma

linha de item, como, por exemplo, itens de pedido, itens de entrega e itens de
vendas, etc.
3.08.3.1. Fatos com produtos heterogneos
A rea financeira representa um dos melhores exemplos para produtos

heterogneos, porque, normalmente, trabalha com uma variedade de produtos e
servios. Para estes modelos dimensionais, recomenda-se a criao de uma
dimenso geral e de dimenses especficas para os produtos/servios. Da mesma
forma, ser necessria uma tabela de fatos gerais e tabelas de fatos especficas
para cada produto.
Estas tabelas de fatos especficas podem apresentar sua chave compondo a

chave da tabela de fatos geral. Desse modo, possvel agilizar o processo de
consultas.
Os fatos especficos ou "sub - fatos" representam medies numricas de uma

dimenso especfica, podendo ser inseridas na tabela de fatos principal (ou
global). (KIMBALL et al, 1998).
A imagem 09 apresenta uma tabela fato, com anlises bancrias, e com uma
tabela de sub-fato.
Imagem 09

3.08.3.2. Classificao de atributos em uma tabela de fatos
Os atributos mais comuns em uma tabela de fatos so valores numricos. Estes

valores podem ser de trs tipos:
Valores Aditivos: so valores da tabela de fatos sobre os quais podem ser

aplicadas as operaes de soma, subtrao e mdia. Os valores, como por
exemplo, "total de vendas" e "total de itens vendidos", por Produto X Regio
X Loja representam valores aditivos.
Valores No Aditivos: so valores da tabela de fatos que no podem ser

manipulados livremente, como valores percentuais ou relativos. Para esses
tipos de valores, os clculos devem ser realizados sobre os dados
absolutos nos quais se baseiam. Todos os valores que medem um nvel de
intensidade so valores estticos no aditivos. Esses valores so vlidos
para o momento em que a informao foi obtida, e sua soma atravs do
tempo no tem significado, entretanto, podem ser teis para futuras
manipulaes. Segundo Kimball (KIMBALL, 1997), estes valores, normalmente
mostram totais segundo fatores multiplicativos diferentes. Para estes casos,
recomendvel que se mantenham os valores unitrios, geradores dos
valores no aditivos, na tabela de fatos. As consultas a serem realizadas
sobre a tabela de fatos podem realizar os clculos ou se for o caso, vises
podem ser criadas com os valores calculados. Um exemplo de valores no
aditivos pode ser representado por informaes de totais a preo de custo e
a preo de venda, de itens perdidos e danificados, armazenados na tabela
de fatos "ESTOCAGEM".
Valores Semi Aditivos: so valores que envolvem contagem dupla.
Portanto, so restritos a uma dimenso. Quando a anlise efetuada sobre
a dimenso aditiva, as operaes normais podem ser aplicadas sobre o
valor. Segundo Kimball (KIMBALL, 1996), todas as medies que registram
um nvel esttico, como nveis de estoque e saldos de contas financeiras, e
medies de intensidade, como de temperatura ambiente, so informaes
no aditivas ao longo do tempo. Entretanto, podem ser agregadas, de
forma til, ao longo do tempo Segundo Kimball (KIMBALL, 1996), todas as
medies que registram um nvel esttico, como nveis de estoque e saldos
de contas financeiras, e medies de intensidade, como de temperatura
ambiente, so informaes no aditivas ao longo do tempo. Entretanto,
podem ser agregadas, de forma til, ao longo do tempo atravs do clculo
da mdia do nmero de perodos de tempo. Portanto, podem ser
considerados valores semi-aditivos.
Trs solues so recomendadas para o tratamento deste tipo de valor:
Qualquer tentativa de processamento sobre valores semi-aditivos deve ser

avisada ao usurio;

Recorrer ao dado bsico, isto , ao dado ainda no agregado, de onde foi

extrada a tabela de fatos correspondente;
Gerar na tabela de fatos, registros que armazenem o total real, embutindo
uma agregao em relao ao atributo semi-aditivo.
Um exemplo de valor semi-aditivo o valor em estoque por ms de um produto.

As manipulaes e consultas sobre estes fatos devem restringir ou agregar o
perodo, pois a soma dos totais em estoque em mais de um perodo, contabilizaria
mais de uma vez itens em estoque.
3.08.4. Tabela de Dimenso
A tabela de dimenso armazena as informaes necessrias para anlises ao

longo de dimenses, sendo normalmente, menores que a tabela de fato. Esta
tabela apresenta chave simples e seus campos, normalmente descritivos, so
empregados como fonte das restries e linhas de cabealhos para relatrios.
A qualidade do banco de dados proporcional a dos atributos de dimenses,

portanto deve ser dedicado tempo e ateno a sua descrio, ao seu
preenchimento e a sua garantia de qualidade. (KIMBALL, 1996).
3.08.4.1. Dimenses com Itens Heterogneos
A dimenso que descreve itens heterogneos, segundo Kimball (KIMBALL, 1996)

(KIMBALL et al, 1998), aquela cujos atributos representam mais de um produto ou
servio.
Este tipo de dimenso comum na rea financeira. Para estas dimenses

recomenda-se, aps a definio do modelo principal, contendo a tabela de fatos
central e a tabela dimensional central, a criao de tabelas de fatos e tabelas
dimensionais especficas para cada tipo de item. A definio da dimenso global,
abrangendo os vrios tipos de itens, possibilita a elaborao de consultas gerais.
Enquanto a definio das dimenses especficas permite consultas especficas
com um maior nvel de detalhe.
Segundo Thomsen (1997, p.66), "Uma hierarquia um atributo de uma dimenso". As

hierarquias so a base para a agregao de dados e para a navegao entre os
diferentes nveis de detalhe em um estrutura multidimensional (THOMSEN,1997) (MEYER,
CANNON, 1998).
As hierarquias descrevem a estrutura organizacional e lgica dos relacionamentos

entre os dados (MEYER, CANNON, 1998). A Imagem 10 apresenta os nveis de
agregaes que podem ser aplicados a dimenso Produto.

Muitas dimenses apresentam uma estrutura hierrquica ou de mltiplos nveis. A

imagem 10 apresenta as hierarquias de mltiplos nveis para a dimenso Tempo.
Algumas estruturas hierrquicas so facilmente identificadas, como por exemplo,

uma estrutura de tempo representada por horas, dias, semanas, meses, trimestres
e anos; e uma estrutura geogrfica representada por cidades, municpios, estados,
regies e pases. Dois tipos de hierarquia podem ser considerados para uma
dimenso: explicita e implcita.
Hierarquias explcitas: segundo Kimball (KIMBALL, 1997), a identificao

deste tipo de hierarquia realizada atravs de uma anlise do DER. As
hierarquias so caracterizadas por uma seqncia de entidades
interligadas, cujos relacionamentos, entre cada par de entidades na
seqncia, sejam N:1. A imagem 10 representa a hierarquia explcita para a
dimenso Produto. Essa hierarquia constituda pelas dimenses Tipo e
Categoria.
Hierarquias Implcitas: tambm conhecidas como mltiplas hierarquias,

representam as hierarquias embutidas nos atributos das dimenses. Um
exemplo para mltiplas dimenses, pode ser observado na imagem 10,
apresenta a classificao de produtos de um supermercado. Essa
classificao feita nas categorias alimentos e material de limpeza. Os
alimentos podem ser sub-categorizados, quanto durao, em perecveis
ou no perecveis, ou, quanto frmula, em diettico ou no diettico. Do
mesmo modo, os materiais de limpeza podem ser classificados, quanto
sua frmula, em txica ou no txica, ou, quanto sua consistncia, em
lquida, pastosa ou em p.
Imagem 10

Uma questo importante a ser abordada diz respeito influncia da hierarquia das
dimenses sobre a tabela de fato. A tabela de fatos deve refletir a menor
granularidade das dimenses.
Imagem 11
Ao se estabelecer as hierarquias nas dimenses, a menor granularidade deve ser
mantida na tabela de fatos, de modo a garantir que no sejam armazenados
registros que representem totais referentes a um nvel mais alto na hierarquia de
uma dimenso.
Dessa forma, se a dimenso Produto, na imagem 10, apresenta a hierarquia:

CATEGORIA/ TIPO/ PRODUTO, os registros na tabela de fatos devem indicar
totais no nvel de produto. Os registros que totalizem por CATEGORIA ou TIPO
no devem ser armazenados.
3.08.4.2. Dimenses Descaracterizadas
As dimenses descaracterizadas, tambm conhecidas como dimenses

degeneradas, so representadas na tabela de fatos como chaves de dimenso,
sem que exista a tabela de dimenso.
Um exemplo de dimenso descaracterizada representada pelo nmero de
controle de documentos, nmero de pedidos e nmero de faturas. Este tipo de
atributo, normalmente, empregado em tabelas de fatos onde o gro da tabela
representa o documento propriamente dito ou uma linha de item do documento.
3.08.4.3.Tratamento de dimenses e fatos com cardinalidade
Segundo Kimball (KIMBALL et al, 1998), apesar de, normalmente, a cardinalidade entre
as dimenses e a tabela de fatos ser 1:N, podem acontecer casos em que esta
cardinalidade seja M:N. Para este tipo de cardinalidade, Kimball (KIMBALL et al, 1998)
recomenda a adio de uma nova dimenso que representar uma ponte entre a
dimenso original e a tabela de fatos.

A identificao deste tipo de cardinalidade empregando um desenvolvimento

baseado apenas em tcnicas dimensionais no uma tarefa trivial. Neste tipo de
desenvolvimento, as dimenses e a prpria tabela de fatos so definidas de
acordo com a especificao do usurio final.
Para identificar a existncia da cardinalidade M:N necessrio uma anlise mais

minuciosa, cruzando o modelo gerado com as regras do negcio.
Quando esta cardinalidade identificada, deve ser realizada a insero de uma

dimenso ponte. Esta dimenso ponte representa efetivamente a cardinalidade
M:N, com a tabela de fatos. Esta dimenso, alm de sua chave normal, ter uma
chave que permite identificar o conjunto de informaes. Esta chave, nica para
um conjunto, ser inserida na tabela de fatos. Dessa forma, ser possvel realizar
as consultas pela dimenso origem, garantindo que no haver repeties na
tabela de fatos.
Abaixo o amigo leitor vai poder observar uma lista de definies que devem ser
seguidas para analisar o tipo de cardinalidade que dever ser utilizada entre suas
tabelas fatos e as dimenses:
Estabelecer a granularidade do modelo, identificando a necessidade do

nvel sumarizado;
Gerar a tabela de fatos, a partir do escopo do problema de transaes

referente ao departamento selecionado;
Identificar s dimenses no associativas, que esto ligadas aos fatos, com

respectivos atributos;
Identificar a dimenso associativa, e respectivos atributos dimensionais;
Gerar a dimenso tempo, a partir do perodo da transao da operao,

com sua respectiva granularidade, observando a necessidade de anlise do
negcio;
Determinar os atributos das entidades que sero utilizados nas vrias

dimenses geradas, considerando o negcio em anlise;
Definir as medidas e regras de derivao, relacionadas aos valores e

nmeros de transaes;
Verificar as hierarquias de classificao, definindo se essas sero

agregadas s dimenses associativas;

Verificada a existncia de valores nulos, que no atendam aos requisitos de

exatido e clareza estabelecidos para o modelo;
Comparar e revisar os relacionamentos gerados no modelo dimensional

com o modelo operacional original;
Verificada a necessidade da utilizao dos atributos para se preservar a

anlise do negcio.
3.08.4.4. Tcnicas de rastreamento de alteraes
Os modelos de dados do ambiente operativo fazem pouca, ou mesmo, nenhuma

distino entre os dados estveis e aqueles freqentemente alterados. Como o
DW sensvel s mudanas, uma organizao tima aquela que separa os
dados de acordo com sua freqncia de atualizao. As modificaes dinmicas
exigem um grande controle de sincronismo, o que difcil, em virtude do grande
volume de informaes armazenadas neste ambiente.
Os atributos descritivos, normalmente, apresentam informaes que evoluem

lentamente ao longo do tempo. Por exemplo, o atributo ESTADO_CIVIL na
dimenso CLIENTE. Ao longo dos anos, as pessoas se casam, Morrem e se
divorciam. O emprego de mini-dimenses representa uma forma de tratar as
alteraes em dimenses.
Entretanto, outras solues so apresentadas para esse problema. Para garantir a

manuteno do histrico dos dados atravs do tempo, acompanhando a sua
evoluo so apresentadas trs solues (KIMBALL, 1996) (McGUFF,1998):
1. No manter o histrico, e simplesmente sobrescrever: a nica vantagem

desta soluo a facilidade de implementao. A mudana ocorrer na
dimenso responsvel pela informao, onde um registro ser alterado
recebendo um novo valor. Quando as mudanas ocorrem para acertos no
cadastro esta soluo vlida. Porm, para os demais casos, esta no a
soluo ideal, porque no atinge o propsito de manter o acompanhamento
histrico dos dados.
2. Adicionar um novo registro, com uma nova chave, e a nova descrio: esta
soluo exige uma chave genrica. Kimball sugere a adoo de um formato
de chave que adicione os dgitos de verso ao final. As chaves genricas
devem estar descritas nos metadados e serem tratadas pelas aplicaes do
usurio final. Esta soluo no impe maiores complexidades s
aplicaes. Nos aplicativos de navegao pelo DW, as consultas
pressupem uma viso dos dados atravs do tempo. As consultas so

feitas de forma a obter totais por perodo, particionando naturalmente a

tabela de fatos de forma cronolgica.
3. Criar um campo a mais para o atributo em questo na tabela dimenso,

para manter o valor corrente: Esta soluo permite visualizar ou restringir a
dimenso de acordo com o valor original ou com o valor corrente do atributo
que sofreu a alterao. mais complexa que a soluo anterior com
relao s aplicaes, sendo pouco aplicada na prtica. Apesar de nenhum
registro novo ser criado, torna-se necessria a manuteno de dois campos
para um atributo, um com o valor corrente e o outro com o valor original.
necessria a criao de um campo com a data em que o valor corrente
entrou em vigor. Como no existe mudana de chave, a nica forma de
identificar a mudana atravs da referncia data da alterao.
Utilizando, como exemplo, o atributo estado_civil na dimenso ALUNO, a
descrio dos registros passaria a ter dois novos campos -
est_civil_original, est_civil_data_efetiva - e o campo est_civil passaria a
chamar-se est_civil_corrente.
Esta soluo prpria para uma fase de adaptao, quando se precisa visualizar
os dados com base no valor antigo ou novo do atributo, como se no existissem
mudanas. A complexidade de se implementar este tipo de soluo reside no
tratamento destas consideraes, que devem se referir ao campo de data efetiva.
Alm disso, manter apenas o valor original e o valor corrente de um atributo no

atinge, por completo, o objetivo de acompanhar o histrico dos dados, pois os
valores intermedirios so perdidos.
3.08.4.5. Criando novas chaves
comum, a criao de novas chaves identificadoras para as dimenses em um

DW. Esta nova identificao, normalmente, decorrente das seguintes
necessidades (INMON, 1997):
Re-mapeamento de chave para evitar a dependncia da chave original.

Essa necessidade ocorre quando existe a possibilidade de alterao de
chave e necessrio evitar a sua reutilizao. A reutilizao de chaves
comum no ambiente operativo devido a sua pequena periodicidade de
armazenamento. O DW, ao contrrio armazena os registros por um longo
perodo, exigindo uma nova chave para evitar duplicidades e
inconsistncias para as consultas;
Re-mapeamento de chaves, reduzindo chaves longas para obter um melhor
desempenho nas consultas;

Estabelecimento de chaves genricas, permitindo mudanas na descrio

dos itens sem provocar alteraes nas chaves. A soluo normalmente
adotada no nvel fsico acrescentar dois ou mais dgitos ao final da chave
original.
Estes novos dgitos indicam a verso do item. As chaves genricas permitem o

rastreamento de modificaes pela generalizao da chave primria.
Apesar da modelagem fsica no pertencer ao escopo deste trabalho

interessante observar que a nvel fsico, comum a criao de chaves onde a
estrutura representa uma montagem baseada em processos de "hashing", para
facilitar o acesso.
3.08.4.6. Criando de Mini - dimenses
Segundo Kimball (1996, p.99), "A melhor abordagem para analisar modificaes em
tabelas dimensionais extremamente grandes subdividi-las em mini-dimenses
compostas por pequenos conjuntos de atributos estruturados para conter um
nmero limitado de valores.".
As mini-dimenses representam uma das melhores formas de tratar

periodicidades de atualizao diferentes em dimenses muito grandes
(KIMBALL,1996).
Alm disso, permitem a manuteno de um bom desempenho porque,

normalmente, se relacionam com a tabela de fatos, permitindo consultas diretas. O
relacionamento da mini-dimenso com a dimenso origem permite outros meios
de navegao.
A imagem 12 apresenta um exemplo de mini-dimenso DEMOGRFICA para a

dimenso CLIENTE.
Imagem 12

3.08.5. Granularidade
Granularidade o nvel de representao mais especfico utilizado para

armazenar os dados. Cada Grnulo representa, em suma, uma entidade dentro da
modelagem E-R. Em muitas situaes, existem hierarquias de conceitos, onde a
modelagem o nvel mais inferior. Um banco de maior granularidade um banco
de dados extremamente normalizado.
O nvel de granularidade de um DW deve ser estudado de forma a deix-lo de

entendimento e uso mais simples, para qualquer usurio. Quanto mais baixo o
nvel escolhido para a granularidade no DW, maior ser a quantidade de dados
armazenados (prximo ao transacional). A escolha da granularidade do DW no
precisa ser a mesma da utilizada no operacional, por isso sempre ser igual ou
superior (agregado).
Observando a questo da granularidade, pode-se considerar, tambm a

aditividade, em que medidas podem ser resumidas. A aditividade torna-se
importante quando ocorre a possibilidade de sumarizao em tabelas de fatos.
Geralmente desejvel que as medidas possam ser completamente aditivas, pois

quando no so, deve-se considerar dividi-las em seus elementos mais baixos
(atmicos).
Como regra geral, os dados podem ser mantidos com o maior nvel de
detalhamento e posteriormente, sumarizados, gerando um nvel mais baixo de
granularidade, oferecendo flexibilidade s consultas do usurio.
3.08.6. Medidas de derivao
Nesse momento, as informaes j definidas so consideradas e inicia-se o

processo de refinamento e detalhamento do modelo. Podem ser detectados
atributos novos e atributos desnecessrios podem ser eliminados. Consultas em
tempo de execuo geralmente no so satisfatrias e necessria a
materializao de dados agregados. Portanto, prope-se criar mecanismos para
sumarizar informaes, evitando a necessidade de execuo do processo de
sumarizao em toda consulta, atravs de regras estabelecidas na metodologia
proposta:
Para a sumarizao dos dados devem ser utilizadas as funes (em SQL)
SUM, AVG, COUNT ou equivalentes;
Quando no existir a necessidade de anlise atmica no dado, esse deve

ser sumarizado, caso contrrio, deve-se manter o mais baixo nvel de
granularidade ou manter na tabela Fatos os dados sumarizados e uma
hierarquia (ou similar) com os dados atmicos.

A imagem 13 mostra algumas das medidas derivadas: SaldoMedioMensal,

NumeroTransacoes, JurosPagos e TotalCredito, e suas regras de derivao,
geradas a partir das tabelas de dimenso e implementadas na tabela Fatos. As
medidas derivadas referenciadas no exemplo so sumarizadas atravs da
utilizao dos operadores SUM, AVG e COUNT na agregao dos valores de
medidas de dimenses.
Imagem 13
3.09. Data Mining
Qualquer sistema de Data Warehouse (DW) s vai funcionar e poder ser utilizado
plenamente, com a utilizao de boas ferramentas de explorao. Com o
surgimento do DW, a tecnologia de Data Mining (minerao de dados) tambm
ganhou a ateno do mercado.
Como o DW, possui bases de dados bem organizadas e consolidadas, as

ferramentas de Data Mining ganharam grande importncia e utilidade. Essa
tcnica, orientada a minerao de dados, oferece uma poderosa alternativa para
as empresas descobrirem novas oportunidades de negcio e acima de tudo,
alcanar novas estratgias para o futuro.
O propsito da anlise de dados descobrir previamente caractersticas dos

dados, sejam relacionamentos, dependncias ou tendncias desconhecidas. Tais
descobertas tornam-se parte da estrutura informacional em que decises so
formadas. Uma tpica ferramenta de anlise de dados ajuda os usurios finais na
definio do problema, na seleo de dados e a iniciar uma apropriada anlise
para gerao da informao, que ajudar a resolver problemas descobertos por
eles. Em outras palavras, o usurio final reage a um estmulo externo, a
descoberta do problema por ele mesmo.
Se o usurio falhar na deteco do problema, nenhuma ao tomada.
A premissa do Data Mining uma argumentao ativa, isto , em vez do usurio

definir o problema, selecionar os dados e as ferramentas para analisar tais dados,

as ferramentas do Data Mining pesquisam automaticamente os mesmos a procura

de anomalias e possveis relacionamentos, identificando assim problemas que no
tinham sido identificados pelo usurio.
Em outras palavras, as ferramentas de Data Mining analisam os dados,

descobrem problemas ou oportunidades escondidas nos relacionamentos dos
dados, e ento diagnosticam o comportamento dos negcios, requerendo a
mnima interveno do usurio, assim ele se dedicar somente a irem busca do
conhecimento e produzir mais vantagens competitivas.
Como podemos ver as ferramentas de Data Mining, baseadas em algoritmos que

forma a com lgica de predicados, somente facilitam e auxiliam o trabalho dos
analistas de negcio das empresas, ajudando as mesmas a conseguirem serem
mais competitivas e maximizarem seus lucros.
Nota: O capitulo Especiais vai apresentar um tpico inteiro sobre Data Mining, trazendo ainda mais informaes
para voc amigo leitor.
3.10. Metadados
Desde que surgiram os bancos de dados sempre se falou sobre a importncia da

documentao dos sistemas e dos prprios bancos. Com o surgimento do
conceito de Data Warehouse, isso no diminuiu a importncia, pelo contrrio,
aumentou e muito.
As Corporaes esto exigindo cada vez mais funcionalidades dos sistemas de TI

(Tecnologia da Informao), e repositrios de metadados no so nenhuma
exceo a esta regra. Mas o que so metadados?
Acima vimos que sempre houve preocupao com a documentao dos sistemas
e bancos de dados das corporaes, sabemos que no Data Warehouse
documentar tudo vital para a sobrevivncia do projeto, pois o DW pode ser um
projeto gigantesco e se no houver uma documentao eficiente ningum
conseguir entender nada.
Os metadados so definidos como dados dos dados. S que a complexidade

desses dados no Data Warehouse aumenta muito. Num sistema OLTP gera-se
documentos somente sobre o levantamento dos dados, banco de dados e o
sistema que alimenta o mesmo. No Data Warehouse alm do banco, gera-se uma
documentao muito maior.
Alm de falar sobre o levantamento de dados e o banco, temos ainda o

levantamento dos relatrios a serem gerados, de onde vem os dados para
alimentar o DW, processos de extrao, tratamento e rotinas de carga dos dados.
Ainda podem gerar metadados as regras de negcio da empresa e todas as
mudanas que elas podem ter sofrido, e tambm a freqncia de acesso aos
dados.

Segundo Inmon os metadados englobam o DW e mantm as informaes sobre o

que est onde. Ele ainda define quais informaes os metadados mantm:
A estrutura dos dados segundo a viso do programador;

A estrutura dos dados segundo a viso dos analistas de SAD;
A fonte de dados que alimenta o DW;
A transformao sofrida pelos dados no momento de sua migrao para o
DW;
O modelo de dados;
O relacionamento entre o modelo de dados e o DW;
O histrico das extraes de dados;
Acrescentamos ainda os dados referentes aos relatrios que so gerados pelas

ferramentas OLAP assim como os que so gerados nas camadas semnticas.
Os metadados podem surgir de vrios locais durante o decorrer do projeto.
Eles provm de repositrios de ferramentas case, os quais geralmente j esto

estruturados, facilitando a integrao da origem dos metadados e o repositrio dos
mesmos. Essa fonte de metadados riqussima.
Outros dados que devem ser guardados no repositrio de metadados, o material

que surgir das entrevistas com os usurios. Destas entrevistas podem obter-se
informaes preciosas que no esto documentadas em nenhum outro lugar alm
de regras para validao dos dados depois de carregados no Data Warehouse.
Como pudemos ver, o volume de metadados gerados muito grande. Existem

hoje algumas ferramentas que fazem nica e exclusivamente o gerenciamento dos
metadados.
Elas tm algumas caractersticas peculiares. Falando de uma maneira simplista,

essas ferramentas conseguem mapear o dado em todas as etapas de
desenvolvimento do projeto, desde a conceitual at a de visualizao dos dados
em ferramentas OLAP/EIS.
Agora vamos discutir os desafios arquitetnicos mais complexos que surgem ao

implementarmos um repositrio de metadados que requer funcionalidade mais
avanada.
Enquanto a maioria dos repositrios no tenta implementar estas caractersticas,

eles representam o tipo de funcionalidade que exigida atravs das corporaes.
As fontes metadados, (ferramentas de modelagem de dados, ferramentas de

extrao, transformao e carga, etc.) devem ser integradas no repositrio por
vrias necessidades. Uma arquitetura de metadados bidirecional permite que os

dados modificados na fonte possam ser alterados tambm no repositrio

automaticamente.
Esta arquitetura altamente desejvel por duas razes chaves. Primeiro: permite
a essas ferramentas compartilhar metadados. Isto desejvel no mercado de
ferramentas de apoio de deciso.
A maioria das corporaes que construram um sistema de apoio a deciso no
pensou na integrao das ferramentas.
Estas no so integradas, por isso, no se comunicam facilmente. At mesmo

essas ferramentas que podem ser integradas tradicionalmente requerem bastante
programao manual para compartilhar dados. Segundo: metadados bidirecional
atraente para corporaes que querem implementar um repositrio de metadados
em toda empresa.
Como vimos os metadados so importantssimos para o sucesso de um DW. Ao
comearmos qualquer projeto devemos sempre nos preocupar com os mesmos,
pois so eles que serviro de bssola para nos guiar pelo emaranhado de tabelas,
relatrios e dados quando estivermos perdidos.
3.11. OLAP
As ferramentas OLAP (On-Line Analytical Processing) so as aplicaes que

nossos usurios finais tm acesso para extrarem os dados de suas bases com os
quais gera relatrios capazes de responder as suas questes gerenciais.
Elas surgiram juntamente com os sistemas de apoio a deciso para fazerem a

extrao e anlise dos dados contidos nos Data Warehouses e Data Marts.
Nota: O capitulo especiais vai apresentar um tpico inteiro sobre a arquitetura OLAP.
3.11.1. Gerao de Consultas (Queries)
A gerao de consultas no OLAP se d de uma maneira simples, amigvel e

transparente para o usurio final, o qual precisa ter um conhecimento mnimo de
informtica para obter as informaes que deseja.
Cada uma destas tecnologias e tcnicas tem seu lugar no mercado de DSS
(Decision Support System) e apia diferentes tipos de anlises. importante
lembrar que as exigncias do usurio devem ditar que tipo de Data Mart voc est
construindo. Como sempre, a tecnologia e tcnicas devem estar bem
fundamentadas para atenderem da melhor maneira possvel essas exigncias.
Os Data Warehouses/Data Marts, servem como fonte de dados para estas

aplicaes, assegurando a consistncia, integrao e preciso dos dados. Os
sistemas transacionais no conseguem responder essas questes por isso,

necessria a criao de um ambiente de apoio de deciso robusto, sustentvel e

confivel.

Livro Apostila BI

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Livro Apostila BI

Diunggah oleh

Hak Cipta:

Format Tersedia

Apostila de Treinamento Business Intelligence

Capitulo 1 - O que Business Intelligence?

Capitulo 2 - Data Warehouse

(11) 3531 6550 - www.strattus.com.br 1

Capitulo 3 - Modelagem Dimensional

Capitulo 4 Criando um Data Mart de Vendas

(11) 3531 6550 - www.strattus.com.br 2

Business Intelligence no algo que se compra de um fornecedor, mas um

Luiz Cmara, Presidente da InfoBuild Brasil

Captulo 1 O que Business Intelligence?

Ou seja, ns os profissionais de tecnologia, envolvidos nas camadas de

Como exemplo deste emaranhado e complexo sistema de informao, podemos

O objetivo desta obra conscientizar todos os escales das empresas privadas,

(11) 3531 6550 - www.strattus.com.br 3

reporting que; a busca de novas oportunidades no mercado, bem como a gesto

Tambm vai conhecer o conceito dos poderosos Data Marts e a fantstica

Aqui o amigo leitor ainda avaliar os conceitos do Balanced Scorecard e de gesto

1.2. Business Intelligence Conceitos e anlises

O mercado mundial como um todo, no para de comentar e divulgar sobre a

O primeiro, quer dizer a intermediao de uma atividade comercial com fins

(11) 3531 6550 - www.strattus.com.br 4

alterar o rumo da empresa (estrutura, recursos humanos, financeiros, materiais,

O conceito de BI tem como principal objetivo, auxiliar estes homens e mulheres a

O BI engloba o uso de ferramentas sofisticadas, que fazem parte da rea de

As empresas fazem parte do mundo dos negcios e esse visa eternamente ao

bvio que no podemos deixar de citar a enorme quantidade de informaes

Como no poderia deixar de ser, os sistemas de informaes prestam uma grande

Quando a empresa consegue obter essas informaes rapidamente e de forma

Mas, o ponto mais importante nessa mistura de tecnologias a empresa poder

(11) 3531 6550 - www.strattus.com.br 5

O Business Intelligence pode ser entendido como um leque conceitual que

Isso bom para cada um de ns clientes e consumidores. E melhor ainda para os

A maior ameaa das empresas da atualidade o desconhecimento... O Business

Por fim, o BI ou Inteligncia Empresarial tem como principal objetivo integrao

1.3. Business Intelligence - Histrico

Ao contrrio do que se possa imaginar, o conceito de Business Intelligence no

Observar e analisar o comportamento das mars, os perodos de seca e de

O mundo mudou desde ento, mas o conceito permanece o mesmo. A

(11) 3531 6550 - www.strattus.com.br 6

No entanto, naquela poca ainda no existiam recursos eficientes que

O panorama comeou a mudar na dcada de 70, com o surgimento das

A partir da o computador passou a ser visto como um coordenador central para

O mercado passou a se comportar de modo mais complexo e a tecnologia da

No entanto, quando se trata de BI, as opinies nem sempre so unnimes. Na

Esse repositrio no precisa ser necessariamente, um DW, mas algo menos

(11) 3531 6550 - www.strattus.com.br 7

dedicado a armazenar as informaes usadas como base para a realizao de

Como j foi mencionado acima, o conceito de Business Intelligence muito mais

O EIS na verdade, um software que objetiva fornecer informaes empresariais

A histria do Business Intelligence tambm est profundamente atrelada ao ERP

(11) 3531 6550 - www.strattus.com.br 8

Tradicionalmente, o Business Intelligence pertenceu ao domnio do pessoal de TI

1.4. Business Intelligence Benefcios

O BI consegue trazer inmeros benefcios para as organizaes que o utilizem de

Antecipar mudanas no mercado;

Podemos citar exemplos mais especficos como o setor comercial, marketing,

(11) 3531 6550 - www.strattus.com.br 9

Na rea comercial o BI oferece os seguintes benefcios:

Melhora no prognstico de vendas;

Benefcios para a rea de marketing:

Campanha de marketing dirigido;

Benefcios para a rea de economia e finanas:

Aes personalizadas, avaliao de riscos e de oportunidades futuras;

1.5. Gesto do Conhecimento e Sistemas de Informao