Sunteți pe pagina 1din 65

FACULDADE DE TECNOLOGIA SO PAULO

PROCESSAMENTO DE DADOS
MONOGRAFIA

MODELAGEM DIMENSIONAL

SO PAULO
2012

FACULDADE DE TECNOLOGIA SO PAULO


PROCESSAMENTO DE DADOS
MONOGRAFIA

MODELAGEM DIMENSIONAL
RAMON RAMOS DE CASTRO NOVAIS

Monografia apresentada Faculdade de Tecnologia So Paulo para obteno de grau Tecnlogo


em Processamento de Dados

Professor Orientador: Gabriel Shammas

SO PAULO
2012

DEDICATRIA

Aos meus pais


Rogrio e Wanderly
s minhas avs
Nair e Adelina
Aos meus amigos de Faculdade e Trabalho
(cujos nomes no sero citados para no correr o risco de esquecer algum)

AGRADECIMENTOS

Primeiramente minha namorada pelo apoio, ajuda e pacincia


durante o processo de elaborao deste trabalho.
Aos meus pais pelo apoio, tanto emocionalmente quanto
financeiramente para minha concluso da faculdade.
Ao meu professor orientador no s pela ajuda neste trabalho, ms
tambm pelos ensinamentos passados em sala de aula, que foram decisivos
na escolha do tema e at minha carreira profissional.
E, finalmente a todos que contriburam direta e indiretamente para
realizao deste trabalho.

SUMRIO
DEDICATRIA _________________________________________________________________________ 3
AGRADECIMENTOS ____________________________________________________________________ 4
SUMRIO ____________________________________________________________________________ 5
LISTA DE TABELAS _____________________________________________________________________ 7
LISTA DE GRFICOS ____________________________________________________________________ 8
LISTA DE FIGURAS _____________________________________________________________________ 9
RESUMO ____________________________________________________________________________ 10
ABSTRACT ___________________________________________________________________________ 11
INTRODUO ________________________________________________________________________ 12
1.

BUSINESS INTELLIGENCE __________________________________________________________ 13


1.1.
1.2.
1.3.

2.

HISTRIA ____________________________________________________________________ 13
CENRIO ATUAL _______________________________________________________________ 15
DATAWAREHOUSE ______________________________________________________________ 15

INTRODUO A BANCO DE DADOS __________________________________________________ 17


2.1.

HISTRIA DO BANCO DE DADOS_____________________________________________________ 18


2.1.1.
2.1.2.

Os primeiros do mercado _________________________________________________________ 19


Evoluo _______________________________________________________________________ 20

2.2.
BANCO DE DADOS RELACIONAIS_____________________________________________________ 21
2.2.1.
Elementos _____________________________________________________________ 21
3.

BANCO DE DADOS DIMENSIONAL ___________________________________________________ 22


3.1.
HISTRIA ____________________________________________________________________ 23
3.2.
INTRODUO E CONCEITO _________________________________________________________ 24
3.3.
MODELAGEM DIMENSIONAL _______________________________________________________ 25
3.4.
MODELOS DE IMPLEMENTAO _____________________________________________________ 28
3.4.1.
Modelo Estrela (Star Schema) ______________________________________________ 28
3.4.2.
Modelo Floco de Neve (Snow Flake) _________________________________________ 29

4.

ETL ____________________________________________________________________________ 31
4.1.
4.2.

5.

COMPONENTES DO ETL __________________________________________________________ 33


ETL NO CICLO DE VIDA DO DATA WAREHOUSE __________________________________________ 35

DISTRIBUIO DE DATA WAREHOUSE _______________________________________________ 36


5.1.
BANCO DE DADOS DISTRIBUDOS ____________________________________________________ 37
5.1.1.
Banco de Dados Distribudo x Data Warehouse Distribudo ______________________ 38
5.2.
ARQUITETURA DE DATA WAREHOUSE DISTRIBUDO DE INMON ________________________________ 39
5.3.
ARQUITETURA DE DATA WAREHOUSING DISTRIBUDO DE MOELLER_____________________________ 42
5.3.1.
Arquitetura de Data Warehousing Distribudo Homogneo ______________________ 43
5.3.2.
Arquitetura de Data Warehousing Distribudo Heterogneo _____________________ 45
5.3.3.
Arquitetura de Data Warehousing Distribudo com SGBD Distribudo nico _________ 46

6.

AVALIAO GARTNER 2011 ________________________________________________________ 48

6.1.
CRITRIOS ___________________________________________________________________ 48
6.1.1.
Habilidade para execuo _________________________________________________ 48
6.1.2.
Abrangencia de viso de mercado __________________________________________ 50
6.2.
FORNECEDORES: PONTOS FORTES E CUIDADOS ___________________________________________ 53
6.2.1.
Informatica ____________________________________________________________ 53
6.2.2.
IBM ___________________________________________________________________ 55
6.2.3.
Microsoft ______________________________________________________________ 58
6.2.4.
Oracle _________________________________________________________________ 60
CONCLUSO _________________________________________________________________________ 63
REFERCIAS BIBLIOGRAFICAS ___________________________________________________________ 64
WEBGRAFIA _________________________________________________________________________ 65

LISTA DE TABELAS

TABELA 1- COMPARATIVO ENTRE PROCESSAMENTO TRANSACIONAL E ANALTICO ________________ 25


TABELA 2 - COMPARATIVO ENTRE MODELO ESTRELA E FLOCO DE NEVE _________________________ 31
TABELA 3 - HABILIDADE PARA EXECUO - PESO DOS CRITRIOS _______________________________ 50
TABELA 4 - ABRANGNCIA DE VISO - PESO DOS CRITRIOS ___________________________________ 52

LISTA DE GRFICOS

GRFICO 1 - TABELA FATO NO CENTRO E DEMAIS TABELAS DIMENSO AO REDOR ________________ 27


GRFICO 2 - MODELO ESTRELA __________________________________________________________ 29
GRFICO 3 - MODELO FLOCO DE NEVE ____________________________________________________ 30
GRFICO 4 - ETL NO CICLO DE DADOS _____________________________________________________ 32
GRFICO 5 - ETL NO CICLO DE VIDA DO DATA WAREHOUSE ___________________________________ 36
GRFICO 6 - ARQUITETURA BSICA DO DATA WAREHOUSE DISTRIBUIDO DE INMON ______________ 40
GRFICO 7 - VARIAO DA ARQUITETURA BSICA DO DATA WAREHOUSE DISTRIBUDO DE INMON __ 42
GRFICO 8 - ARQUITURA DO DATA WAREHOUSE HOMOGNIO DE MOELLER _____________________ 44
GRFICO 9 - ARQUITETURA DO DATA WAREHOUSE DISTRIBUDO HETEROGNIO DE MOELLER_______ 45
GRFICO 10 - ARQUITETURA DO DATA WAREHOUSE DISTRIBUDO COM SGBD DISTRIBUDO NICO DE
MOELLER _______________________________________________________________________ 47

LISTA DE FIGURAS

FIGURA 1 ENTRADA DE DADOS EM DATA WAREHOUSE _____________________________________ 17


FIGURA 2 - COMPONENTES DO ETL _______________________________________________________ 34
FIGURA 3 - QUADRANTES MGICOS DE FERRAMENTAS DE INTEGRAO DE DADOS GARTNER 2010 _ 52
FIGURA 4 - LOGO INFORMATICA _________________________________________________________ 53
FIGURA 5 - LOGO IBM _________________________________________________________________ 55
FIGURA 6 - LOGO MICROSOFT ___________________________________________________________ 58
FIGURA 7 - LOGO ORACLE ______________________________________________________________ 60

10

RESUMO
Um data warehouse consiste em uma coleo de dados orientada por
assuntos integrados, variante no tempo e no voltil que d suporte
tomada de deciso pela alta gerncia da empresa.
tambm um conjunto de ferramentas e tcnicas de projeto, que
quando aplicadas s necessidades especficas dos usurios e aos bancos de
dados especficos permitir que planejem e construam um Depsito de
Dados.
O Data Warehouse no um produto e no pode ser comprado como
um software de banco de dados. O sistema de Data Warehouse similar ao
desenvolvimento de um ERP, ou seja, ele exige anlise do negcio, exige o
entendimento do que se quer retirar das informaes. Apesar de existirem
produtos que fornecem uma gama de ferramentas para efetuar o Cleansing
dos dados, a modelagem do banco e da apresentao dos dados, nada disso
pode ser feito sem um elevado grau de anlise e desenvolvimento.
O sistema de Data Warehouse no pode ser aprendido ou codificado
como uma linguagem. Devido ao grande nmero de componentes e de
etapas, um sistema de Data Warehouse suporta diversas linguagens e
programaes desde a extrao dos dados at a apresentao dos mesmos.

11

ABSTRACT
A Data Warehouse consists in a integrated colection of subject
oriented datas, that varies on time and is not volatile which gives suport to
the decision taked by the company's high management.
It is also a series of tools and project tecniques, that when applied to
the users' specifics needs and specifics data bases will allow to be planed
and built a Data Warehouse.
The Data Warehouse is not a product and can not be bought as a data
base software. The Data Warehouse system is similar to the development
of a ERP, in other words, it demands a business analysis, demands the
understainding of the business and demands what is needed to retrieve of
the informations. Although the existence of products that provide a huge
number of tools to perform the data Cleaning, the data base modeling and
the data presentation, none of this can be done without a high level of
analysis and development.
The Data Warehouse system can not be learned or codified as a
language. Due to its greats numbers os components and steps, a Data
Warehouse system suports many languages and programing since the data
extraction to the presentation of then.

12

INTRODUO

O mundo dos negcios a muito utiliza informaes como vantagem competitiva.


Com o crescimento do mercado com a globalizao, a computao se tornou
fundamental para processar grandes volumes de dados. medida que os anos
avanaram, empresas comearam a se tornar corporaes e os sistemas saram das reas
operacionais para influenciar nas decises de negcio. Nesse cenrio percebeu-se o
grande gargalo dos antigos meios de armazenamento: a questo de desempenho para
obter informao de grande volume de dados.
E no somente obter as informaes a tempo, outro problema era o formato.
Com as constantes aquisies de empresas menores, as fontes de dados de sistemas prexistentes no conseguiam se comunicar devido a diferentes padres de suas
arquiteturas.
A soluo dos dois problemas abordada nesse trabalho: ETL e Datawarehouse.
De um lado, veremos mais detalhadamente a necessidade de implantao de
datawarehouse em mdias/grandes corporaes e o surgimento das ferramentas de ETL
para possibilitar essa centralizao de dados.

13

1. BUSINESS INTELLIGENCE

Segundo artigo publicado por Orlando Augusto Nunes1, Business Intelligence


um conjunto de conceitos e metodologias que, fazendo uso de acontecimentos (fatos) e
sistemas baseados nos mesmos, apoia a tomada de decises em negcios. O grande
desafio de todo indivduo que gerencia qualquer processo a anlise dos fatos
relacionados a seu dever. Ela deve ser feita de modo que, com as ferramentas e dados
disponveis, o gerente possa detectar tendncias e tomar decises eficientes e no tempo
correto. Com essa necessidade surgiu ento o conceito de Business Intelligence.
O propsito do Business Intelligence permitir a tomada de decises proativas,
ao gerar informaes necessrias ao negcio e disponibiliz-los no momento certo.
medida que o cenrio econmico muda cada vez mais rpido, a necessidade de
informaes de negcios e as demandas pela rapidez e qualidade destas informaes
crescem na mesma velocidade. Por outro lado, a oferta de informaes de negcios
aumenta constantemente. O resultado uma overdose de dados onde difcil retirar
informaes relevantes para subsidiar tomadas de deciso. Tal fato torna mais difcil um
entendimento

aprofundado

do

cenrio

econmico.

Faz-se

necessria

uma

aproximao/abordagem sistemtica para analisar temas e tendncias estratgicas e


antever mudanas com clientes, atividades e competidores.

1.1. Histria

1 Tecnlogo em Planejamento de Transportes pelo (IFG)

14

H milhares de anos, Fencios, Persas, Egpcios e outros Orientais j faziam, a


seu modo, Business Intelligence, ou seja, cruzavam informaes provenientes da
natureza, tais como comportamento das mars, perodos de seca e de chuvas, posio
dos astros, para tomar decises que permitissem a melhoria de vida de suas
comunidades. A histria do Business Intelligence que conhecemos hoje, comea na
dcada de 70, quando alguns produtos de BI foram disponibilizados para os analistas de
negcio. O grande problema era que esses produtos exigiam intensa e exaustiva
programao, no disponibilizavam informao em tempo hbil nem de forma flexvel,
e alm de tudo tinham alto custo de implantao.
Em 1989, Howard Dresner2, um pesquisador da consultoria Gartner Group3,
popularizou o BI como um termo geral para descrever um grupo de conceitos e mtodos
para melhorar o processo de tomada de deciso em negcios atravs do uso de sistemas.
Tambm no final dos anos 80 e incio dos anos 90, surgiu o conceito de
estocagem de informao. A ideia era deixar os dados onde eles j estavam e acess-los
a partir de qualquer lugar com alguma ferramenta especfica. Com o aumento de
padres, automaes e tecnologias, uma vasta quantidade de dados se tornou disponvel.
As tecnologias de estocagem de dados determinaram repositrios para armazenar estes
dados. A melhora das ferramentas que extraiam, transformavam e carregavam dados
aumentaram a velocidade de coleta de informaes. Tecnologias permitiram a rpida
gerao de novos relatrios para a anlise de dados, tudo pela ao do prprio usurio,
sem interferncia ou dependncia de profissionais de tecnologia da informao (TI). O
BI agora se tornava a arte de filtrar uma grande quantidade de dados, extrair as
informaes pertinentes, e tornar a informao em conhecimento.
2 Vice presidente da Gartner Inc. na poca, deixou a empresa em 2005.
3 Consultoria fundada em 1979 por Gideon Gartner

15

1.2. Cenrio Atual

Por muitos anos BI tem sido utilizado por grandes corporaes apenas, j que
essas eram as nicas capazes de investir grandes quantias, tanto de tempo quanto de
dinheiro, para desenvolver os projetos de BI.
Atualmente uma nova gerao de produtos de BI tem surgido: alta performance,
operaes intuitivas e rpida implantao so caractersticas das novas solues que
atendem a empresas de todos os tamanhos.
Essas novas solues se mantm fieis ao objetivo inicial de apoiar a tomada de
deciso transformando dados em conhecimento. No entanto, em vez de estar atado a
questes de estrutura e conformidade que caracterizam os antigos produtos de BI, a
nova abordagem foca na implantao simples e resultados rpidos. A importncia dessa
economia de tempo no pode ser subestimada j que o custo de projetos longos no est
apenas no seu valor absoluto, mas no tempo que se gasta e na falta de resultados no
tempo que o mercado necessita.

1.3. Datawarehouse

Datawarehouse pode ser definido com as duas palavras que compe seu nome:
Data, do ingls, dados; Warehouse, do ingls, armazm, local para estocar seus bens.
Datawarehouse um local onde guardado toda informao estratgica para empresa
para auxiliar na tomada de deciso.

16

Para obter uma melhor analise de quais dados sero guardados no


datawarehouse, deve-se entender a diferena dos tipos de dados de um empresa:
Dados operacionais
Produzido por softwares corporativos, as empresas utilizam para servios
rotineiros como pedidos de clientes, cadastro de produtos ou gerenciamento de
transaes financeiras. Dados operacionais tambm podem vir de fontes externas
como por exemplo sistemas de cotao financeira.
Dados de integrao
Dados utilizados para integrar aplicaes que no foram projetados para
trabalhar juntas.
Dados para controle
Utilizado para elaborao de relatrios de apoio deciso. Os dados so
preparados para permitir aos usurios a melhor compreenso da situao da
empresa.

17

Figura 1 Entrada de dados em data warehouse

Repare que na imagem acima o datawarehouse apenas recebe as informaes de


diversos sistemas. Os datawarehouses no tm como funo gerar dados operacionais,
mas tratar esses dados junto com os dados de integrao para gerar dados de controle e
melhoria corporativa.

2. INTRODUO A BANCO DE DADOS

18

Bancos de dados (ou bases de dados) so conjuntos de dados logicamente


coerentes dispostos em estrutura regular que possibilita a reorganizao dos mesmos e
produo de informao. Representa abstratamente uma parte do mundo real que de
interesse de certa aplicao.
Por esta definio qualquer sistema que rena e mantenha organizada uma srie
de informaes relacionadas a um determinado assunto em uma determinada ordem
pode ser considerado um banco de dados, como por exemplo, uma lista telefnica, um
arquivo de clientes, uma lista de produtos, etc.

2.1. Histria do Banco de Dados

Nas dcadas de 1960 e 1970, as empresas descobriram que estava muito custoso
empregar um nmero grande de pessoas para fazer trabalhos como armazenar e indexar
(organizar) arquivos. Por este motivo, valia a pena os esforos e investimentos em
pesquisar um meio mais barato e ter uma soluo mecnica eficiente.
Em 1970 um pesquisador da IBM - Ted Codd 4- publicou o primeiro artigo
sobre bancos de dados relacionais. Este artigo tratava sobre o uso de clculo e lgebra
relacional para permitir que usurios no tcnicos armazenassem e recuperassem grande
quantidade de informaes. Codd visionava um sistema onde o usurio seria capaz de
acessar as informaes atravs de comandos em ingls, onde as informaes estariam
armazenadas em tabelas.

4 Edgard Frank Ted Codd (1923-2003) cientista computacional ingls. Realizou vrias contribuies cincia computacional, mas o modelo relacional
permaneceu como seu maior feito.

19

Devido natureza tcnica deste artigo e a relativa complicao matemtica, o


significado e proposio do artigo no foram prontamente realizados. Entretanto ele
levou a IBM a montar um grupo de pesquisa conhecido como System R5 (Sistema R).
O projeto do Sistema R era criar um sistema de banco de dados relacional o qual
eventualmente se tornaria um produto. Os primeiros prottipos foram utilizados por
muitas organizaes, tais como MIT Sloan School of Management6. Novas verses
foram testadas com empresas aviao para rastreamento do manufaturamento de
estoque.
Eventualmente o Sistema R evoluiu para SQL/DS7, o qual posteriormente
tornou-se o DB28. A linguagem criada pelo grupo do Sistema R foi a Structured Query
Language (SQL - Linguagem de Consulta Estruturada). Esta linguagem tornou-se um
padro na indstria para bancos de dados relacionais e hoje em dia um padro ISO 9
(International Organization for Standardization).

2.1.1. Os primeiros do mercado

Mesmo a IBM sendo a companhia que inventou o conceito original e o padro


SQL, eles no produziram o primeiro sistema comercial de banco de dados. O feito foi

5 Sistema de banco de dados constitudo como um projeto da IBM San Jose Research (agora IBM Almaden Research Center) em 1970. Precursor do SQL, foi o
primeiro sistema a demonstrar que um modelo relacional poderia oferecer um bom desempenho em processamento de transaes.
6 rea de business do Instituto Tecnolgico de Massachusetts, em Cambridge.
7 Structured Query Language/Data System. Uma implementao imperfeita do modelo relacional de Ted Codd, foi o primeiro uso comercial de um DBMS
(Database Management System) da IBM em seus mainframes utilizando a linguagem SQL. Introduzido no mercado no inicio de 1980.
8 Criando em 1983 pela IBM. Existem diferentes verses do DB2 que rodam em desde um simples PDA, at em potentes mainframes e funcionam em servidores
baseados em sistemas Unix, Windows, ou Linux.
9 Organizao Internacional de Normalizao/Padronizao. Fundada em 1947, em Genebra, Sua, a ISSO aprova normas internacionais em todos os campos
tcnicos.

20

realizado pela Honeywell Information Systems Inc10., cujo sistema foi lanado em
junho de 1976. O sistema era baseado em muitos princpios do sistema que a IBM
concebeu, mas foi modelado e implementado fora da IBM.
O primeiro sistema de banco de dados construdo baseado nos padres SQL
comearam a aparecer no incio dos anos 80 com a empresa Oracle atravs do Oracle 2
e depois com a IBM atravs do SQL/DS, servindo como sistema e repositrio de
informaes de outras empresas.

2.1.2. Evoluo

O software de banco de dados relacionais foi sendo refinado durante a dcada de


80. Isso deve-se ao feedback (retorno) que os usurios destes sistemas faziam, devido ao
desenvolvimento de sistemas para novas indstrias e ao aumento do uso de
computadores pessoais e sistemas distribudos.
Desde sua chegada, os bancos de dados tm tido aumento nos dados de
armazenamento, desde os 8 MB (Megabytes) at centenas de Terabytes de dados em
listas de e-mail, informaes sobre consumidores, sobre produtos, vdeos, informaes
geogrficas, etc. Com este aumento de volume de dados, os sistemas de bancos de
dados em operao tambm sofreram aumento em seu tamanho.
O padro SQL passou da IBM para a ANSI 11 e para a ISO, os quais formaram
um grupo de trabalho para continuar o desenvolvimento.
10 Grande conglomerado de empresas americanas seriada em Morristown, Nova Jersey. Produz uma variedade de produtos comerciais e de consumo, servios de
engenharia e sistemas aeroespaciais para uma ampla variedade de clientes, desde consumidores privados a grandes corporaes e governos.

21

2.2. Banco de Dados Relacionais

A modelagem relacional baseia-se no princpio de que as informaes em uma


determinada base de dados podem ser consideradas como relaes matemticas e que
esto representadas de forma uniforme, atravs do uso de tabelas bidimensionais. Desta
forma, os dados so dirigidos para estruturas mais simples de armazenamento os dados,
que so as tabelas, na qual a viso do usurio privilegiada.
Este modelo, por suas caractersticas e por sua completitude, mostrou ser uma
excelente opo, superando os modelos mais usados quela poca: o de redes 12e o
hierrquico13. A maior vantagem do modelo relacional sobre seus antecessores a
representao simples dos dados e a facilidade com que consultas complexas podem ser
expressas.
Esse modelo surgiu para atender sistemas transacionais que possuem operaes
atmicas (que devem ocorrer por completo ou ento sero desfeitas) pr-definidas,
geralmente com um grande nmero de usurios simultneos realizando operaes
repetidamente.

2.2.1. Elementos

11 American National Standards Institute, com sede em Washington, DC. Organizao privada sem fins lucrativos que supervisiona o desenvolvimento de padres
de consenso voluntrio para produtos, servios, processos, sistemas e pessoal nos Estados Unidos.
12 Neste modelo as entidades se representam como ns e suas relaes so as linhas que os unem. Nesta estrutura qualquer componente pode se relacionar com
qualquer outro como em uma teia de aranha.
13 Utiliza rvores para a representao lgica dos dados. Estas rvores so compostas de elementos chamados ns. O nvel mais alto da rvore denomina-se raiz.
Cada n representa um registro com seus correspondentes campos.

22

Tabela (ou Relaes, ou Entidades): Armazena todos os dados do BDR (Banco


de Dados Relacional), e composta de linhas e colunas. Essas tabelas associamse entre si atravs de regras de relacionamento, estas regras consistem em
associar um atributo de uma tabela com um conjunto de registros de outra
tabela.
Registros (ou Tuplas): Cada linha de uma tabela representa um registro (ou
tupla); um registro uma instncia de uma tabela, ou entidade. Esses registros
no precisam necessariamente conter informaes em todas as colunas, podendo
admitir valores nulos quando necessrio.
Atributo: colunas de uma tabela
Chave: conjunto de um ou mais atributos que determinam a unicidade de cada
registro

3. BANCO DE DADOS DIMENSIONAL

Diferente dos modelos anteriores (hierrquico, de rede e relacional) onde as


informaes eram divididas em muitas tabelas para melhor representao do mundo
fsico, o foco no modelo dimensional agrupamento de informao. Onde nos seus
predecessores redundncia de dados era visto como um defeito, aqui se torna uma
vantagem competitiva. No a representao computacional do mundo fsico que se
busca nessa abordagem, mas a coletnea de informao para alimentar sistemas
necessariamente geis. Aqui o cliente no est interessado em ver o modelo lgico, mas
nos nmeros finais de sua consulta, as vezes grficos ou tabelas, que tenham potencial
para influenciar nas suas decises de negcio.

23

3.1. Histria

1970, a preparao:
Dcada tecnolgica com predominncia de mainframes. Apesar do desempenho
em executar funes rotineiras, os dados criados desse processamento so isolados em
bancos de dados primitivos e conjunto de arquivos apenas acessveis aos departamentos
de processamento de dados responsveis pelo mainframe.
Era quase impossvel, por exemplo, comparar o desempenho de lojas de varejo
da regio oriental de um grupo de empresas com as lojas da regio ocidental, ou com
seus concorrentes ou mesmo contra seu prprio desempenho em um perodo anterior.
Como tentativa de obter essas informaes, grandes demandas de relatrios eram
frequentes aos departamentos de processamento de dados, gerando filas constantes de
pendncias.
A fim de suprir essas necessidades em tempo mais hbil, algumas empresas
adotaram uma abordagem interessante: eram identificados dados importantes e
constantemente requisitados (como informaes de clientes, vendas e despesas) e
periodicamente era feito a copia dos dados para fonte externa onde esses dados
poderiam ser acessados para formar relatrios comuns (como relatrios de lucro,
despesas, ganho por cliente).
O problema dessa abordagem era sua aplicabilidade. Em vista que a fonte inicial
dos dados eram mainframes de certas empresas, comparativos entre empresas com
mainframes configurados de forma diferente j no era possvel.

24

Empresas de hardware/software comearam a surgir com solues para esse


problema. Entre 1976 e 1979, a partir da pesquisa do instituto tecnolgico da Califrnia
(Caltech14) e o grupo de tecnologias avanadas do Citybank surgiria a empresa
Teradata. Seus fundadores desenvolveram um sistema de gerenciamento de banco de
dados para processamento paralelo utilizando vrios microprocessadores focado em
sistemas de suporte a deciso. Teradata 15foi constituda em 13 de julho de 1979 e
comeou em uma garagem em Brentwood, Califrnia. O nome do Teradata foi
escolhido para simbolizar a habilidade de gerenciar terabytes (trilhes de bytes) de
dados.

3.2. Introduo e conceito

De acordo com Ralph Kimball, Dimensional Modeling is a design technique


for databases intended to support end-user queries in a data warehouse., modelagem
dimensional uma tcnica de design de banco de dados projetada para suportar
consultas de end-users em um Data Warehouse. Para sistemas de processamento
analtico, o grande volume de dados necessrios para consultas de planejamento ttico e
estratgico devem ser processados de forma rpida. Para melhorar o desempenho, h
redundncia planejada dos dados (diferente do modelo relacional), compensando os
gastos com armazenamento e atualizao das informaes. Com isso temos uma
estrutura simples, com tabelas de dados histricos em series temporais, descritos atravs

14 Califrnia Institute of Technology. Universidade privada localizada em Pasadena, Califrnia. Sendo uma das primeiras universidades do mundo em pesquisa, a
Caltech mantm uma forte nfase e tradio nas Cincias naturais e Engenharia. De acordo com a classificao anual da Times Higher Education de 2011, a
Caltech a melhor universidade do mundo.
15 Teradata Corporation fundada em 1979. Considerada pela pesquisa do Instituto Gartner uma das empresas lideres em datawarehouse e ferramentas business
analytics.

25

de tabelas de dimenses, de modo que o modelo reflita o processo de analise de


negcios da empresa.
As atualizaes nesse modelo so feitas periodicamente em batch, no havendo
necessidade de controlar as alteraes realizadas entre uma atualizao e outra.
Um dos objetivos desse modelo permitir ao usurio realizar consultas na base
de dados sem depender da equipe de tecnologia.
As diferenas entre os modelos relacionais e dimensionais pode ser visto na
tabela a seguir:
Processamento Transacional

Processamento Analtico

Dados Normalizados

Dados Consistentes

Atualizao em tempo real

Desempenho compatvel com o


volume de dados

Controle de Concorrncias

Cala representao do modelo

Dados Concorrentes

Ferramentas

especiais

usurios finais
Respostas imediatas
Tabela 1- Comparativo entre processamento transacional e analtico

3.3. Modelagem dimensional

Elementos que compem um Modelo Dimensional:


Tabela Fato

para

26

De acordo com Kimball, a tabela de fatos a principal tabela de um modelo


dimensional, onde as medies numricas de interesse da empresa esto armazenadas.
A palavra "fato" representa uma medida dos processos modelados, como quantidades,
valores e indicadores. A tabela de fatos registra os fatos que sero analisados.
composta por uma chave primria (formada por uma combinao nica de valores de
chaves de dimenso) e pelas mtricas de interesse para o negcio.
A tabela de fatos deve ser sempre preenchida com as medidas referentes ao fato.
No se deve preencher uma linha da tabela fato com zeros para representar que nada
aconteceu (por exemplo, que no houve vendas de um produto em determinada data),
pois isso faria com que a tabela de fatos crescesse demais. Alm disso, a tabela de fatos
deve representar uma unidade do processo do negcio, no devendo-se misturar
assuntos diferentes numa mesma tabela de fatos.
Tabela Dimenso
A tabela de dimenso composta de atributos e contm a descrio do negcio.
Seus atributos so fontes das restries de consultas, agrupamento dos resultados e
cabealhos para relatrios. Ela possui aspectos pelos quais se pretende observar as
mtricas relativas ao processo modelado. A tabela de dimenso costuma ser bem menor
do que a tabela fato, geralmente com muito menos do que um milho de registro.
Um exemplo da diferena entre a tabela fato e a dimenso est na figura a
seguir:

27

Grfico 1 - Tabela fato no centro e demais tabelas dimenso ao redor

Se o fato/mtrica a ser medido/a for a receita de uma rede de supermercados, as


dimenses para a avaliao da mtrica seriam, por exemplo, a quantidade de lojas, a
localizao, os produtos vendidos e o tempo.
Tabela Agregada
A tabela agregada criada com dados da tabela fato, alterando sua
granularidade, ou seja, ela sumariza os dados, gerando uma tabela menor. A tabela
agregada utilizada para otimizar o tempo de acesso de uma consulta ao banco de
dados. importante avaliar bem o ambiente para definir quais agregaes devem ser
criadas; a utilizao das mesmas requer um esforo adicional de manuteno, alm de
aumentar o gasto com armazenamento, por isso deve-se sempre tentar criar tabelas
agregadas que atendam a mltiplas consultas. Alm disso, as tabelas agregadas podem
ser temporrias; desta forma, deve-se levar em conta a possvel extino dessa tabela e
os futuros efeitos causados devido a sua excluso.
Mtricas
So as informaes armazenadas nas tabelas fato que permite medir o
desempenho dos processos do negcio. As mtricas so geralmente volumtricas,

28

numricas, podem ou no ser agregadas e na maioria das vezes so do tipo aditivas, ou


seja, permitem operaes como adio, subtrao e mdias. Existem tambm outros
dois tipos de mtricas, as mtricas no aditivas e as semi-aditivas. As mtricas no
aditivas no podem ser manipuladas livremente, como valores percentuais ou relativos.
J as mtricas semi-aditivas so valores que no podem ser somados em todas as
dimenses.

3.4. Modelos de Implementao

3.4.1. Modelo Estrela (Star Schema)

O nome estrela se d devido disposio em que se encontram as tabelas,


sendo a tabela fato centralizada relacionando-se com diversas outras tabelas de
dimenso. Veja um exemplo da estrutura do Star Schema na figura a seguir:

29

Grfico 2 - Modelo Estrela

Nesse modelo os dados so desnormalisados para evitar joins entre tabelas,


diminuindo o tempo de consultas, no entanto devido a repetio de dados, utiliza mais
espao em disco. A vantagem desse modelo a eficincia na extrao de dados, o que
um grande diferencial em se tratando de um datawarehouse.

3.4.2. Modelo Floco de Neve (Snow Flake)

Outro tipo de estrutura bastante comum, o modelo de dados Snow Flake (Floco
de Neve), que consiste em uma extenso do modelo Estrela onde cada uma das "pontas
da estrela" passa a ser o centro de outras estrelas. Isto porque cada tabela de dimenso
seria normalizada, "quebrando-se" a tabela original ao longo de hierarquias existentes

30

em seus atributos. Recomenda-se utilizar o esquema floco de neve apenas quando a


linha de dimenso ficar muito longa e comear a ser relevante do ponto de vista de
armazenamento. Veja um exemplo da estrutura do Snow Flakes na figura a seguir:

Grfico 3 - Modelo Floco de neve

Devido a essa estrutura, o acesso aos dados mais lenta, mas facilita na
construo de cubos de algumas ferramentas BI(Business Intelligence) e BA (Business
Analytics).
A deciso de optar pelo esquema estrela ou pelo floco de neve deve ser tomada
levando-se em considerao o volume de dados, o SGBD, as ferramentas utilizadas, etc.
Abaixo temos uma tabela comparativa entre esses dois modelos.

Tabela dimenso

Modelo Estrela

Modelo Floco de Neve

No normalizada

Normalizada

31

Tamanho fisico

Grande volume j que os

Volume reduzido, j que os

dados se repetem nas tabelas dados das tabelas dimenses so


dimenses no normalizadas normalizados

para

evitar

repeties
Velocidade
consultas

das

Rpida

Menos rpida do que o modelo


estrela devido a normalizao

Tabela 2 - Comparativo entre modelo estrela e floco de neve

4. ETL

ETL, vem do ingls Extract Transform Load, ou seja, Extrao Transformao


Carga. O ETL visa trabalhar com toda a parte de extrao de dados de fontes externas,
transformao para atender s necessidades de negcios e carga dos dados dentro do
Data Warehouse.
Os projetos de data warehouse consolidam dados de diferentes fontes. A maioria
dessas fontes tendem a ser bancos de dados relacionais ou flat files16, mas podem
existir outros tipos de fontes tambm. Um sistema ETL precisa ser capaz de se
comunicar com bases de dados e ler diversos formatos de arquivos utilizados por toda a
organizao.

16 Coleo de dados armazenados e acessados de forma sequencial que contem registros sem relao estruturada

32

Grfico 4 - ETL no ciclo de dados

Na imagem acima temos as entradas de dados em azul. A abordagem aqui a


possibilidade de diferentes tipos de entrada. Como as ferramentas de ETL unificam os
dados, no h mais a necessidade de ficar preso a alguma marca ou tipo de
armazenamento de dados. Podemos por exemplo ter os dados de um ERP, de uma
ferramenta CRM, flat files ou bancos de dados de sistemas operacionais como RDBMS
(Relational Data Base Management System, sistema gerenciador de banco de dados
relacional) e mainframes, todos usando bases diferentes e podendo estar normalizados
diferentemente tambm. Isto d s empresas liberdade na escolha de suas ferramentas,
visto que o importante agora so as vantagens operacionais e no as restries
funcionais.
Ao passar pelo processo de ETL (quadrado verde), os dados so armazenados no
datawarehouse de forma que seja possvel recuperar:

33

Raw data os dados. Ex.: data de nascimento


Metadata os dados sobre os dados. Ex.: tipo do dado (se texto ou datetime)
Summary data o agrupamento dos dados, resumo. Ex.: mdia das idades
A partir desse ponto, o datawarehouse j est preparado para alimentar os
sistemas de apoio a deciso como ferramentas OLAP, relatrios e Data Marts.

4.1. Componentes do ETL

Nesta imagem ns podemos visualizar um exemplo de modelo de Arquitetura de


uma soluo de BI. O objetivo aqui no discutir sobre toda a arquitetura, mas
visualizar os principais componentes que fazem parte de um sistema ETL.

34

Figura 2 - Componentes do ETL

Extrao: a coleta de dados dos sistemas de origem (tambm chamados Data


Sources ou sistemas operacionais), extraindo-os e transferindo-os para o
ambiente de DW, onde o sistema de ETL pode operar independente dos sistemas
operacionais.
Limpeza, Ajustes e Consolidao (ou tambm chamada transformao): nesta
etapa que realizamos os devidos ajustes, podendo assim melhorar a qualidade
dos dados e consolidar dados de duas ou mais fontes.
O estgio de transformao aplica uma srie de regras ou funes aos dados
extrados para ajustar os dados a serem carregados. Algumas fontes de dados
necessitaro de muito pouca manipulao de dados. Em outros casos, pode ser
necessrios trabalhar algumas transformaes, como por exemplo, juno de dados

35

provenientes de diversas fontes, seleo de apenas determinadas colunas e traduo de


valores codificados (se o sistema de origem armazena 1 para sexo masculino e 2 para
feminino, mas o data warehouse armazena M para masculino e F para feminino, por
exemplo).
Entrega ou Carga dos dados: Consiste em fisicamente estruturar e carregar os
dados para dentro da camada de apresentao seguindo o modelo dimensional.
Dependendo das necessidades da organizao, este processo varia amplamente.
Alguns

data

warehouses

podem

substituir as

informaes

existentes

semanalmente, com dados cumulativos e atualizados, ao passo que outro DW


(ou at mesmo outras partes do mesmo DW) podem adicionar dados a cada
hora. A latncia e o alcance de reposio ou acrscimo constituem opes de
projeto estratgicas que dependem do tempo disponvel e das necessidades de
negcios.
A parte de Gerenciamento composta por servios para auxiliar no
gerenciamento do DataWarehouse. Aqui ns temos tasks especficas para
gerenciamento de jobs, planos de backup, verificao de itens de segurana e
compliance.

4.2. ETL no Ciclo de Vida do Data Warehouse

36

Grfico 5 - ETL no ciclo de vida do data warehouse

O Ciclo de vida do Data Warehouse composto por uma srie de etapas. Iniciase pelo planejamento do Programa ou Projeto, passamos pelo levantamento e definio
dos requisitos de negcios e a nos dividimos em trs caminhos:
Arquitetura e Design Tcnico
Modelagem Dimensiona
Planejamento e desenvolvimento da aplicao de BI, o front-end17 propriamente
dito.

5. DISTRIBUIO DE DATA WAREHOUSE

A maioria das organizaes constri e mantm um nico data warehouse


centralizado, isto feito por vrias razes:
Os dados em um data warehouse integrado pela organizao, e uma viso
integrada dos dados usada somente na sede da organizao;
17 parte do sistema de software que interage diretamente com o usurio

37

A organizao opera em um modelo centralizado de negcio;


O volume dos dados em um data warehouse tal que um nico repositrio de
dados centralizado faz sentido;
Complexidade de desenvolvimento de um ambiente distribudo;
Maior Segurana; e
Fcil Gerenciamento.

Em resumo, a poltica, a economia e a tecnologia favorecem muito o uso de um


nico data warehouse centralizado. Entretanto, dados extremamente centralizados
podem resultar em perda de disponibilidade e queda de desempenho das consultas. Da
surge a necessidade de um ambiente de distribuio de data warehouse, tendo como
vantagens sobre os ambientes centralizados: o aumento da disponibilidade dos dados, o
aumento da disponibilidade de acesso aos dados e o aumento de desempenho no
processamento de consultas OLAP.

5.1. Banco de Dados Distribudos

Os banco de dados distribudos trazem vantagens da computao distribuda


para o domnio do gerenciamento de banco de dados. Um sistema de computao
distribuda consiste em vrios elementos de processamento, no necessariamente
homogneos, que so interconectados por uma rede de computadores e cooperam na
execuo de certas tarefas. Os banco de dados distribudos podem ser definidos como
uma coleo de mltiplos bancos de dados logicamente inter-relacionados, distribudos

38

por uma rede de computadores. Abaixo so destacadas algumas vantagens na utilizao


de banco de dados distribudos:
Transparncia de fragmentao, replicao e alocao;
Melhoria na confiabilidade e disponibilidade;
Melhoria de desempenho; e
Expanso mais fcil;
De acordo com Elmasri e Navathe, a distribuio leva a uma maior
complexidade no projeto e na implementao do sistema. Para obter as vantagens
potenciais listadas anteriormente, o ambiente de banco de dados distribudos deve ser
capaz de prover algumas funes, alm daquelas j presentes em ambientes
centralizados, como por exemplo:
Rastreamento dos dados;
Processamento de consultas distribudas;
Gerenciamento de transaes distribudas;
Gerenciamento de dados replicados;
Recuperao de banco de dados distribudo;
Segurana; e
Gerenciamento do diretrio (catlogo) distribudo.

5.1.1. Banco de Dados Distribudo x Data Warehouse Distribudo

O data warehouse nada mais do que um banco de dados especial integrado,


orientado por assunto, varivel com o tempo e no voltil, usado para dar suporte ao

39

processo gerencial de tomada de deciso. Por isso, as contribuies obtidas pelos


trabalhos de pesquisa em sistemas de banco de dados distribudos podem ser utilizadas
como base para o desenvolvimento de ambientes de data warehousing distribudos.
Porm, esses trabalhos devem ser estendidos de forma a enfocar aspectos importantes
dos ambientes de data warehousing distribudo, tais como a multidimensionalidade dos
dados do data warehouse, a organizao dos dados dessa base de dados em diferentes
nveis de agregao e as caractersticas das consultas OLAP comumente realizadas
pelos usurios de sistemas de suporte deciso.

5.2. Arquitetura de Data Warehouse Distribudo de Inmon

A arquitetura de data warehouse distribudo definida por Inmon 18 baseada


nos conceitos de data warehouse local e de data warehouse global. O Grfico 6
ilustra esta arquitetura, onde o data warehouse global situa-se localizado no site
correspondente ao escritrio central ou sede da empresa, enquanto os data warehouses
locais esto localizados em regies geogrficas diferentes ou comunidades tcnicas
distintas.

18 William H. Inmon (1945) cientista computacional conhecido como pai do datawarehouse, criou a definio mais aceitvel de datawarehouse: coleo de
dados orientados, no volteis, integrados, e variados pelo tempo para o auxiliar no suporte de decises

40

Grfico 6 - Arquitetura bsica do data warehouse distribuido de INMON

Os dados armazenados no data warehouse local so de interesse somente para o


nvel local, ou seja, cada data warehouse local tem como escopo dos seus dados
detalhados que refletem a integrao das informaes provenientes dos sistemas
operacionais do site local ao qual ele serve. Apesar de ser inteiramente possvel a
existncia de algum grau de compartilhamento entre os sistemas do ambiente
operacional

encontrados

em

cada

um

dos

sites,

qualquer

interseo

ou

compartilhamento dos dados de um data warehouse local para outro apenas uma
coincidncia. Os dados armazenados no data warehouse global so de interesse para a
empresa como um todo. Estes dados so integrados a partir das intersees naturais dos
dados existentes nos sites que compem o ambiente distribudo. O relacionamento entre
o data warehouse global e os data warehouses locais pode ser observado da seguinte
forma. Os dados levemente agregados residem no nvel global, enquanto que os dados
detalhados residem nos nveis locais. Como pode ser observado, os dados localizados
no data warehouse global e nos data warehouses locais so mutuamente exclusivos:

41

qualquer dado no data warehouse global no encontrado nos data warehouses locais, e
vice-versa. Em contrapartida, o projeto estrutural dos dados corporativos armazenados
no data warehouse global pode sobrepor pores dos modelos de dados dos data
warehouses locais. Inmon prope uma variao desta arquitetura, onde consiste no prarmazenamento dos dados a serem enviados ao data warehouse global por cada um dos
sites locais. Assim, cada site que participa do ambiente armazena os dados globais
correspondentes s informaes locais em uma base de dados especial, chamada de rea
de armazenamento do data warehouse global, antes de envi-los ao data warehouse
global propriamente dito. Neste caso, a restrio de exclusividade mtua dos dados
observada tanto entre os dados localizados nos data warehouses locais e nas reas de
armazenamento do data warehouse global quanto entre os dados localizados nos data
warehouses locais e no data warehouse global. Contudo, pode haver alguma
redundncia entre os dados armazenados no data warehouse global e nas reas de
armazenamento do data warehouse global em cada um dos sites, caso a poltica adotada
pela empresa seja a no remoo dos dados destas reas aps o envio destes ao data
warehouse global. O Grfico 7 representa as reas de armazenamento do data warehouse
global em cada um dos sites.

42

Grfico 7 - Variao da arquitetura bsica do data warehouse distribudo de INMON

Inmon sugere que o desenvolvimento desta arquitetura deve ser feito


primeiramente criando os data warehouses locais para cada entidade geogrfica, para
que depois, o data warehouse global seja criado, refletindo a integrao dos negcios
atravs das diferentes localizaes.

5.3. Arquitetura de Data Warehousing Distribudo de Moeller

As arquiteturas de data warehousing distribudo definidas por Moeller

so

baseadas na juno de dois conceitos: integrao atravs do elemento banco de dados e


distribuio atravs do elemento rede. Assim, um data warehouse distribudo definido
por Moeller como uma coleo de dados compartilhados logicamente integrada, a qual

43

fisicamente distribuda atravs dos ns de uma rede de computadores. Uma vez que o
data warehouse distribudo consiste na integrao lgica de diversos bancos de dados
locais, ele no existe fisicamente nas arquiteturas de Moeller. Mais especificamente, o
data warehouse distribudo apenas um conceito virtual. Em particular, os termos local
e global so utilizados para realizar a distino, respectivamente, entre os aspectos
relacionados a um nico site e os aspectos relacionados ao ambiente de data
warehousing como um todo. Por exemplo, um data warehouse local refere-se a um
banco de dados pr-existente que reside em um site especfico da rede, ou seja, refere-se
a um data mart.
H trs diferentes tipos de arquitetura de data warehousing distribudo
apresentadas por Moeller [MOE01]: arquitetura de data warehousing distribudo
homogneo, heterogneo e com um SGBD distribudo nico.. importante salientar
que Moeller associa os seus trs tipos de arquitetura de data warehousing distribudo
abordagem de desenvolvimento, na qual uma corporao j gerencia vrios data marts
independentes e deseja possibilitar, como uma atividade subseqente, o acesso global
dos usurios de SSD a estes data marts atravs de um data warehouse global virtual. Ou
seja, os dados so mantidos nas fontes de dados e as consultas so decompostas em
tempo real e submetidas s diversas fontes, onde o resultado integrado e mostrado
para o usurio que efetuou a consulta. Isto obtido atravs do desenvolvimento de um
esquema global da empresa como um todo, que representa a integrao dos esquemas
locais dos data marts existentes, alm da interconexo destes data marts atravs da rede.

5.3.1. Arquitetura de Data Warehousing Distribudo Homogneo

44

O Grfico 8 mostra a arquitetura de data warehousing distribudo homogneo


proposta por Moeller, com os seus dois principais componentes: o data warehouse
distribudo e a ferramenta de banco de dados distribudos.

Grfico 8 - Arquitura do data warehouse homognio de MOELLER

Cada site nesta arquitetura possui o seu prprio banco de dados autnomo e pode
representar um data mart independente. A arquitetura homognea caracterizada por
apresentar em todos os sites o mesmo SGBD. So nestes SGBD que se armazenam os
data marts a serem distribudos. A ferramenta de gerenciamento do banco de dados
distribudo, por sua vez, responsvel por integrar os diversos bancos de dados locais,
oferecendo uma viso lgica do data warehouse corporativo, alm de gerenciar as
consultas dos usurios de SSD aos bancos de dados fora de suas redes locais. Essa
ferramenta baseada em dois elementos centrais relacionados manipulao dos dados
distribudos: esquema de fragmentao e esquema de alocao. O esquema de
fragmentao descreve como os relacionamentos globais so divididos entre os bancos
de dados locais. J o esquema de alocao especifica a localizao de cada um dos

45

fragmentos, possibilitando a execuo de consultas atravs dos diversos bancos de


dados locais. Este ltimo esquema tambm d suporte possibilidade de replicao dos
dados na arquitetura.

5.3.2. Arquitetura de Data Warehousing Distribudo Heterogneo

A arquitetura de data warehousing distribudo heterogneo proposta por Moeller


baseada nos mesmos componentes principais que a arquitetura de data warehousing
distribudo homogneo: o data warehouse distribudo e uma ferramenta de
gerenciamento do banco de dados distribudo. No entanto, na arquitetura de data
warehousing distribudo heterogneo, estes componentes possuem caractersticas e
funcionalidades particulares relacionadas heterogeneidade dos dados, aumentando,
com isso, a complexidade destes componentes. O Grfico 9 ilustra esta arquitetura.

Grfico 9 - Arquitetura do data warehouse distribudo heterognio de MOELLER

46

Cada site nesta arquitetura possui o seu prprio banco de dados autnomo e pode
representar um data mart independente. A arquitetura heterognea possibilita que
diferentes SGBD sejam utilizados nos sites da arquitetura, para armazenar os bancos de
dados a serem distribudos. de responsabilidade da ferramenta de gerenciamento do
banco de dados distribudo tratar e oferecer os servios adicionais voltados ao
tratamento da heterogeneidade. Alm desses servios adicionais, as demais
funcionalidades da ferramenta de gerenciamento do banco de dados distribudo na
arquitetura de data warehousing distribudo heterogneo so as mesmas funcionalidades
oferecidas por essa ferramenta na arquitetura homognea:
Conectar os diversos bancos de dados independentes atravs de uma rede de
computadores, oferecendo uma viso lgica integrada dos dados corporativos;
Atender s consultas dos usurios de SSD que requisitam dados atravs dos sites
da arquitetura; e
Proporcionar os esquemas de fragmentao e de alocao.
essencial a presena de um modelo de dados global integrado para o bom
funcionamento da ferramenta de gerenciamento do banco de dados distribudo.

5.3.3. Arquitetura

de

Data

Warehousing

Distribudo

com

SGBD

Distribudo nico

O Grfico 10 mostra a arquitetura de data warehousing distribudo proposta por


Moeller [MOE01]. Diferentemente do que foi visto nas arquiteturas de data
warehousing distribudo homogneo e heterogneo, na arquitetura com SGBD

47

distribudo nico no existem banco de dados locais autnomos, ou seja, esta


arquitetura no oferece suporte a data marts independentes.

Grfico 10 - Arquitetura do data warehouse distribudo com SGBD distribudo nico de MOELLER

Nesta arquitetura, os dados do data warehouse corporativo podem estar


armazenados em diferentes sites, podendo ser distribudos (fragmentados e/ou
replicados) nestes sites medida que o volume do data warehouse aumenta ou medida
que o nmero de usurios cresce. O acesso a estes dados feito atravs do SGBD
distribudo, que desempenha papel similar ao exercido pela ferramenta de
gerenciamento do banco de dados distribudo nas arquiteturas de data warehousing
distribudo homogneo e heterogneo, fazendo-se desnecessria a presena desta
ferramenta nesta arquitetura.
Enquanto nas arquiteturas homognea e heterognea cada banco de dados local
possui o seu prprio modelo de dados individual, na arquitetura com SGBD distribudo
nico no existem modelos de dados locais. Tal restrio est relacionada ao fato de que

48

as pores do data warehouse corporativo armazenadas nos diversos sites dessa ltima
arquitetura no podem ser consideradas bancos de dados locais autnomos. Apesar
disto, indispensvel a definio de um modelo de dados corporativo na arquitetura
com SGBD distribudo nico.

6. AVALIAO GARTNER 2011

Fundada em 1979 por Gideon Gartner, a lder de pesquisa na rea de


tecnologia da informao. Realiza avaliaes de diversos segmentos de TI anualmente
classificando os fornecedores em seus quadrantes quanto habilidade de executar e
abrangncia de viso de mercado.

6.1. Critrios

6.1.1. Habilidade para execuo

Produto/Servio: quo bem o fornecedor atende gama de funcionalidades de


integrao de dados exigida pelo mercado, a forma (arquitetura) como essas
funcionalidades so entregues e a usabilidade geral das ferramentas. A
capacidade funcional do produto fundamental para o sucesso das ferramentas
de integrao de dados e, portanto, recebe um peso maior.
Viabilidade geral. A magnitude dos recursos financeiros do fornecedor e a
continuidade de seu atendimento com o cliente e de sua tecnologia. Nesta

49

iterao do Quadrante Mgico coloca-se uma ponderao alta neste critrio para
refletir as permanentes preocupaes dos compradores sobre os riscos
associados com os fornecedores, como resultado das atuais condies
econmicas.
Execuo de Vendas / Preos. A eficcia do modelo de preos do fornecedor e
de seus canais de vendas diretos e indiretos. Devido aos exames minuciosos
sobre as questes de custos e natureza altamente competitiva deste mercado,
aumenta-se o peso deste.
Receptividade do mercado e histrico. O grau em que o vendedor tem
demonstrado a capacidade de responder com sucesso a demanda do mercado por
ferramentas de integrao de dados durante um perodo prolongado.
Execuo de Marketing. A eficcia global dos esforos de marketing do
fornecedor, o que influencia o grau de "mind share19", quota de mercado e
fidelidade dos clientes alcanada pelo vendedor.
Experincia do Cliente. O nvel de satisfao manifestado pelos clientes em
relao ao suporte de produtos, servios profissionais e relacionamento geral
com o fornecedor, bem como as percepes dos clientes de valor de ferramentas
de integrao de dados relativos aos custos e expectativas. Nesta iterao do
Quadrante Mgico mantm-se o peso elevado deste critrio para refletir a forte e
contnua preocupao que os compradores esto colocando sobre estas
consideraes, como resultado das condies econmicas e presses
oramentais.
Critrios de avaliao

19

Peso

Termo de marketing. Indica o nvel de que certa marca est gravada no subconsciente da pessoa.

50

Produto/Servio

Alto

Viabilidade geral

Alto

Execuo de Vendas / Preos

Alto

Receptividade do mercado e histrico

Mdio

Execuo de Marketing

Mdio

Experincia do Cliente

Alto

Tabela 3 - Habilidade para execuo - Peso dos critrios

6.1.2. Abrangncia de viso de mercado

Entendimento do mercado. O grau em que o fornecedor lidera o mercado em


novas direes (tecnologia, produtos, servios ou outros), e sua capacidade de se
adaptar s mudanas de mercado significativas. Dada a natureza dinmica deste
mercado, este item recebe uma ponderao elevada.
Estratgia de Marketing. O grau em que a abordagem de marketing do vendedor
alinha-se com e / ou explora as tendncias emergentes e da direo geral do
mercado.
Estratgia de Vendas. O alinhamento do modelo de vendas do fornecedor com a
maneira que as abordagens de compra dos clientes preferenciais ir evoluir ao
longo do tempo.
Estratgia de Oferta (Produto). O grau em que mapa do fornecedor estrada
produto reflete as tendncias de demanda no mercado, preenche lacunas atuais
ou fraquezas, e inclui acontecimentos que criam diferenciao competitiva e
aumento do valor para os clientes. Alm disso, dada a necessidade de
ferramentas de integrao de dados para suportar diversos ambientes de um

51

domnio de dados, plataforma e perspectiva mix fornecedor, avaliamos os


fornecedores sobre o grau de abertura de sua tecnologia e estratgia de produto.
Com o crescimento da diversidade de dados e ambientes envolvidas em
iniciativas de integrao de dados, este critrio recebeu uma ponderao elevada.
Modelo de Negcios. A abordagem global do fornecedor leva para executar sua
estratgia para o mercado de ferramentas de integrao de dados.
Vertical / estratgia da indstria. O nvel de nfase sobre os locais de
fornecedores de solues verticais e profundidade do fornecedor de
especializao vertical.
Inovao. O grau em que o fornecedor tem demonstrado uma disposio para
fazer novos investimentos para apoiar a sua estratgia e melhorar as capacidades
de seus produtos, o nvel de investimento em P & D voltada para
desenvolvimento das ferramentas, e na medida em que o fornecedor demonstra
energia criativa. Dado o ritmo de expanso das necessidades de integrao de
dados ea natureza altamente competitiva do mercado, esse critrio recebe uma
ponderao elevada.
Estratgia Geographic. A abordagem a presena global que o fornecedor est
buscando (por exemplo, presena local direta, revendedores e distribuidores), e
estratgia do vendedor e abordagem para expandir seu alcance em mercados
alm sua regio / pas.
Critrios de avaliao

Peso

Market Understanding

high

Marketing Strategy

standard

Sales Strategy

standard

52

Offering (Product) Strategy

high

Business Model

standard

Vertical/Industry Strategy

low

Innovation

high

Geographic Strategy

standard
Tabela 4 - Abrangncia de viso - Peso dos critrios

Figura 3 - Quadrantes mgicos de ferramentas de integrao de dados Gartner 2010

53

6.2. Fornecedores: Pontos fortes e cuidados

6.2.1. Informatica

Figura 4 - Logo Informatica

Redwood City, California, U.S.


www.informatica.com
Produtos: Plataforma Informatica (components includos: PowerCenter,
PowerExchange, Data Services, Cloud Data Integration)
Base de clientes: mais de 4.200
Pontos fortes:
Como um dos fornecedores mais amplamente reconhecidos no mercado,
Informatica continua a aumentar a sua presena e mantendo sua posio,
aparecendo em avaliaes de ferramenta de integrao de dados mais
frequentemente que suas competidoras. A nova verso Informatica 9 est bem
alinhada com as demandas do mercado atual e as tendncias em evoluo. A
oferta se expande no fornecimento de associao de dados, e rene tanto
integrao quanto a qualidade de dados em uma arquitetura runtime nica que se
alinha com as tendncias de consolidao da tecnologia.
A grande maioria de clientes estabeleceram Informatica como seu padro de
empresa para ferramentas de integrao de dados, e muitos aplicam suas

54

ferramentas em grande nmero de projetos que envolvem o uso de um numero


de desenvolvedores maiores do que a media. Enquanto quase todos esses
clientes aplicam a tecnologia em armazenamento de dados e BI, uma grande
porcentagem tem casos de uso adicionais. Especificamente, os dados de
migrao/transformao e de interfaces entre as aplicaes operacionais foram
referenciadas por clientes como outras opes de uso da ferramenta. A base de
clientes da Informatica continua a expressar um alto grau de satisfao com a
relao valor/tempo, o desempenho do suporte do produto, disponibilidade e em
geral, no relacionamento com o fornecedor.
Informatica continua como lder no mercado por explorar modelos alternativos
de entrega de funes de integrao de dados. Embora ainda seja uma pequena
parte de seus componentes focados nessas funes alternativas de entrega de
dados em relao ao seu modelo padro baseada em batch, o lanamento do
Cloud 9 oferece trs tipos de entrega baseadas em servio. Cloud Services so
focados na integrao saleforce.com. A plataforma Cloud est disponvel para
prestadores de servios independentes e integradores de sistema para
desenvolvimento em servios baseados nas nuvens, e Cloud Edition, uma
plataforma da Informatica para implementao em uma nuvem publica definido
como Amazon. A mais utilizada das 3 ofertas no padro parece ser a Cloud
Service.
Cuidados:
Enquanto sua base de clientes reflete seu mix diversificado de casos de uso, a
arquitetura de implantao permanece fortemente orientada a batch (entrega

55

orientada a lotes de dados). A adoo das abordagens nas nuvens e associao de


dados baixa em comparao ao modelo batch.
O fornecedor enfrenta forte concorrncia com a apario de grandes corporaes
no cenrio (IBM, Microsoft, Oracle e SAP), que oferecem a ferramenta de
integrao de dados como adicionais a produtos prprios. Informatica precisa
crescer seu mind-share e com executivos no pertencentes rea de TI.
Informatica possui preo alto em relao a muitos competidores. Este precisa
continuar a propagar o valor da sua ampla gama de funcionalidades e suas
aplicabilidades ou o preo se tornar um inibidor competitivo. Ao oferecer os
modelos de entrega baseado nas nuvens e ofertas por demanda ou por prazo,
Informatica espera superar esses desafio.

6.2.2. IBM

Figura 5 - Logo IBM

Armonk, New York, U.S.


www.ibm.com
Produtos: IBM InfoSphere Information Server (components includos: InfoSphere
DataStage, InfoSphere QualityStage, InfoSphere Change Data Capture, InfoSphere

56

Federation Server, InfoSphere Foundation Tools), InfoSphere Data Event Publisher,


InfoSphere Replication Server
Base de clientes: mais de 9.000
Pontos fortes
Os clientes da IBM frequentemente possuem demandas sofisticadas de
integrao de dados que exigem ferramentas para atender a problemas de
integrao de dados complexos. IBM continua a demonstrar forte viso do
mercado para atender as funcionalidades exigidas, alem de oferecer com sucesso
seus componentes de integrao a seus clientes existentes. Organizaes que
adotam as ferramentas InfoSphere tendem a considera-lo como o padro de
integrao de dados, refletindo isso, os clientes IBM o utilizam em vrios multiprojetos e maior nmero de desenvolvedores por cliente que a mdia dos seus
competidores. O aumento da base de clientes ocasiona problemas de migrao,
converso e operao na interface de dados.
IBM continua a aumentar o nvel de integrao e coerncia entre seus
componentes do InfoSphere Information Server. Lanamentos significativos no
final de 2008 e durante 2009 incluem a tecnologia CDC (obtido na aquisio de
DataMirror em 2006) com DataStage, as Foundation Tools (para gerenciamento
de metadados em vrios tipos, perfis e modelos), e a integrao do DataStage
com InfoSphere MSM Server. A meta para os prximos anos melhorar a
sinergia entre outras tecnologias IBM.
Distribuio de dados, problemas de sincronizao, BI, data warehouse e
gerenciamento de dados mestres se beneficiam das funcionalidades do CDC. A
comunicao com message brokers, portais Web/Apps e as mais comuns

57

implantaes de banco de dados relacionais so suportados. Enquanto funes


similares so oferecidas por alguns concorrentes, a oferta mais competitiva est
limitada a necessidades em bulk/batch.

Cuidados:
Em 2010 houve menor incidncia de relatos de problemas em alinhar os
diversos componentes, mas ainda h relatos sobre um grande numero de
moving parts que dificulta a implementao da soluo. Como resultado, os
clientes relataram a experincia de instalao da soluo como desafiadora.
Apesar destes desafios, a maioria dos clientes indicam que pretendem adquirir
novos produtos ou licenas do portflio InfoSphere nos prximo 12 meses.
A mesma situao existente em 2009. Durante 2010, a IBM se focou menos em
novas funcionalidades e mais em melhorar a qualidade de seus produtos.
Enquanto a IBM fornece vrios pontos de integrao entre as tecnologias
InfoSphere e o WebSphere de processo e aplicao de integrao de
capacidades, a maioria dos clientes os utiliza separadamente.
O preo continua sendo a maior das preocupaes para os clientes IBM. O uso
da velocidade da CPU como principal parmetro de preo (adiciona
complexidade para os clientes auditarem e modificarem suas implementaes) e
o relativamente alto custo de uma implementao tpica (em comparao com
seus concorrentes) criam algumas perspectivas em fornecedores alternativos ou
limitar investimentos para um pequeno numero de componentes.

58

6.2.3. Microsoft

Figura 6 - Logo Microsoft

Redmond, Washington, U.S.


www.microsoft.com
Produtos: SQL Server Integration Services, BizTalk Server
Base de clientes: mais de 10.000
O principal produto da Microsoft no mercado de ferramenta de dados o SQL
Server Integration Services (SSIS), focada na entrega de dados baseado em
batch. Clientes citam o baixo custo total de aquisio, rapidez de uso e
capacidade de se integrar com o restante dos recursos do Microsoft SQL Server
como principais razes para a escolha de SSIS.
Clientes reconhecem SSIS como uma ferramenta estvel e madura, capaz de
suportar em escala empresarial uma implementao um ambiente Microsoftcentric. O grande uso de SSIS dentro da base de clientes SQL Server tem a
aumentado a comunidade de suporte, treinamentos e documentaes de terceiros
sobre as prticas de implementao e abordagens de resoluo de problemas.

59

O tamanho e presena global da Microsoft fornece uma enorme base de clientes


para estudo de melhores prticas, habilidades dominantes e um modelo de
distribuio que suporta tanto as vendas diretas quanto a de parceiros. Alm
disso, clientes relatam um suporte ps-vendas de qualidade, incluindo
documentao e mecanismos de apoio on-line.
Cuidados
Enquanto SSIS pode ser integrado com o BizTalk e a Microsoft pode abordar
um estilo de replicao de entrega de dados pelas funcionalidades do SQL
Server, essa estratgia no est claramente articulada viso do mercado.
A verso do SQL Server 2008 R2 do SSIS ampliou substancialmente a
capacidade do fornecedor de suportar vrios tipos de requisitos de conectividade
de dados. No entanto, a ausncia de um slido CDC (Chance Data Capture) e
inabilidade de operar fontes de dados no baseados em SQL Server indicam que
o usurio final dessas organizaes deve buscar essas funcionalidades em
terceiros. Microsoft busca preencher essas lacunas com parceiros.
Clientes continuam a citar o gerenciamento de metadados (como descoberta de
metadados, origem e relatrio de dependncias) como uma fraqueza substancial.
Implementaes envolvendo a interoperabilidade entre SSIS e outros produtos
(como BizTalk e SQL Server 2008 Master Data Service) so descritos por suas
exigncias de excessivo esforo em codificao para personalizao. Microsoft
planeja atender a essas necessidades de integrao em uma futura verso do SQL
Server 11. Outras lacunas ou deficincias funcionais citados por clientes incluem
limitaes na qualidade/governana de dados.

60

6.2.4. Oracle

Figura 7 - Logo Oracle

Redwood Shores, California, U.S.


www.oracle.com
Produtos: Data Integrator, Data Service Integrator, Warehouse Builder, GoldenGate
Base de clientes: mais de 3.500
Pontos Fortes:
O Oracle Data Integrator (ODI) e os produtos GoldenGate tem como foco
central a integrao de dados Oracle. A Oracle afirmou que no ir mais dar
continuidade ao Oracle Warehouse Builder (OWB).

Oracle Data Services

Integrator (ODSI) adiciona novas funcionalidades de associao com os


produtos Oracle. Alem disso, a aquisio da Oracle GoldenGate Software
alcanou

seu

potencial

adicionando

classes

empresariais

replicao/sincronizao sua sute.


Em 2010, clientes relataram a facilidade de uso e a boa curva de aprendizado
para o ODI. Os clientes que o utilizam tambm reportaram a facilidade de
integrar da soluo com as infraestruturas existentes, aproveitando tanto a

61

extrao, a carga e a transformao (ETL) de dados quanto os slidos mdulos


de conhecimento e a boa conectividade.
A adoo de ambos ODI e GoldenGate continua a crescer dentro do SGBD
Oracle e a aplicaes baseadas em clientes, mais frequentemente em
implementaes de ETL tradicional em suporte a BI e data warehouse no
entanto, os clientes Oracle demonstraram recentemente interesse em outros
estilos de implementao. A opo por produtos Oracle foi baseada na absoro
dos clientes existentes dos produtos GoldenGate anteriores. Clientes citam como
escolha dessa ferramenta as funcionalidades para ETL, a boa integrao com o
SGBD Oracle, a integrao com os componentes e as aplicaes Oracle Fusion
Middleware e a presena geral no mercado e viabilidade.
Cuidados:
Clientes reportam que para alcanar todas as funcionalidades desejveis
preciso adquirir vrios produtos e com isso os custos sobem. Os preos da
Oracle so transparentes nos resultados, mas permanece complexo. Oracle
indica que os clientes podem obter um menor preo e licenciamento com o
Oracle Data Integrator Enterprise Edition (ODIEE), que inclui tanto o OWB
quando o ODI. Custos adicionais so associados ao ODSI e ao GoldenGate e
outros componentes adicionais. Finalmente, importante notar que o ODI 11g
foi um esforo conjunto das equipes do OWB e ODI um lanamento
significativo indicando que a integrao de dados Oracle est se movendo em
direo a uma abordagem unificada de desenvolvimento do produto.
Uma surpreendente pesquisa encontra relatos de que o suporte da Oracle no
parece familiarizado com o ODI e que seus profissionais parecem no ter

62

conhecimento sobre os produtos da prpria Oracle. Surpreendentemente, porque


pesquisas da Gartner com cliente relatam a fcil aprendizagem das ferramentas.
A combinao com a inquietao dos colaboradores, dos suportes e consultores
do produto indica que falta nfase no treinamento das ferramentas,
especificamente do ODI. A Oracle est aumentando seu suporte atualmente em
resposta s rpidas adoes do produto no mercado e parece que essa
despreparao um sintoma desse crescimento rpido.
ODSI relatado como tendo uma alta incidncia de erros de software (e uma
falta geral de funcionalidades de depurao), com algumas referencias a
componentes mais fracos no conjunto da ferramenta. Isto vai contra os dados da
Oracle de apoio ao cliente. possvel que algumas inconsistncias estejam
ocorrendo entre as mtricas de sucesso de suportes e as expectativas dos
clientes, o que a Oracle pretende dar uma resposta ao longo do tempo. Clientes
ODI reportam um fraco gerenciamento de verso e controles para
desenvolvimento (incluindo limitaes em gesto de acesso que so
supostamente abordados na verso ODI 11g). Em relao ao grande numero de
ferramentas, h uma falta de apoio ao desenvolvimento em equipe. No entanto
as vendas das ferramentas de integrao de dados Oracle esto crescendo, o que
indica uma aceitao do cliente em prticas go-to-market da Oracle.

63

CONCLUSO

Com o crescimento das empresas no mercado atual, a exigncia de informao


rpida e da maneira mais simples possvel est cada vez maior. Isso porque empresas
que demoram mais para tomadas de decises acabam ficando para trs e perdendo
competitividade.
Os DW so atualmente a fonte de informao mais importante para as empresas,
porm no importa se essa fonte seja de fcil acesso ou se o acesso rpido se as
informaes no estiverem l.
Outro problema que aparece, que as informaes nunca esto em um nico
lugar, precisando assim integr-las e convergi-las para um nico ponto.
Com isso as solues de ETL representam uma grande parte do setor de BI das
empresas, pois ele responsvel por carregar e padronizar os dados de diversas fontes, e
quanto mais rpido for esse processo, mais rpida a disponibilizao da informao
para as reas de gerncia para tomadas de decises e mais rpida ser a resposta da
empresa s variaes do mercado.
Neste trabalho foram abordados os assuntos sobre o histrico de solues de BI
envolvendo DW e os tipos de Banco de Dados (Relacional e Dimensional) que fazem
parte das ferramentas que so desenvolvidas para o apoio a tomada de deciso.
Foi apresentado tambm as formas de distribuio dos DWs para que os mesmos
possam atender as demandas de dados que crescem exponencialmente nos dias de hoje.
Observamos que um DW unificado pode no suprir as necessidades das empresas com
relao ao tempo de resposta, tornando assim as solues distribudas cada vez mais
presentes.
Por fim foi apresentada a anlise da Gartner mostrando o ponto forte e
consideraes sobre as principais empresas para solues de BI do mercado na
atualidade. Mostrando tambm que mesmo hoje, com as evolues tecnolgicas ainda
existe muito espao para crescer.

64

REFERCIAS BIBLIOGRAFICAS

ALMEIDA, Maria Sueli e outros, Getting Started with DataWarehouse and


Business Intelligence. 1 edio. San Jose, CA, EUA: International Business Machines
Corporation, 1999.
SIMON, Alan R., Data Warehousing for Dummies. 1 edio. Foster City, CA,
EUA: IDG Books Worldwide, 1999.
HAHN, Seungrahn e outros, Capacity Planning for Business Intelligence
Applications. 1 edio. San Jose, CA, EUA: International Business Machines
Corporation, 2000.
KIMBALL, Ralph & ROSS Margy, The Data Warehouse Toolkit. 2 edio.
New York, NY, EUA: John Wiley and Sons, 2002.
HAMMERGREN, Thomas C. & SIMON, Alan R.: Data Warehousing for
Dummies 2nd Edition. New Jersey: Wiley Publishing, Inc. 2009.
PORTUGAL TELECON, Manual de Introduo Data Warehouse e Informtica
Power Center 7.
TRABALHOS ACADMICOS CONSULTADOS:
Business Inteligence
(Trabalho de Concluso de Curso Faculdade de Tecnologia So Paulo; Autor:
Sandro Hira Pires).
Estrutura de BI
(Trabalho de Graduao Universidade Federal de Pernambuco; Autor: lvaro
Alencar Barbosa Palitot).

65

WEBGRAFIA
http://www.virtualtechtour.com/assets/GARTNER_DI_MQ_2010_magic_quadr
ant_for_data_inte_207435.pdf (Acessado em Agosto de 2012).
http://www.kimballgroup.com/ (Acessado em Julho de 2012).
http://pt.scribd.com/doc/86014285/9/Modelo-Relacional (Acessado em Julho de
2012).

S-ar putea să vă placă și