METODOLOGIA

PARA

IMPLEMENTAÇÃO DE PROJETOS

DE

DATA WAREHOUSE

Autor: Felipe Ferreira

E-mail: felipe.ferreira@w5solutions.com.br

felipe6ferreira@hotmail.com

Rio de Janeiro, 6 de dezembro de 2004

 ii

RESUMO

Motivado pelo interesse nas diversas tecnologias e ferramentas de apoio à

decisão, este trabalho foi desenvolvido com o objetivo de organizar uma metodologia
eficiente no desenvolvimento evolutivo de data warehouse, baseado nos conceitos e
técnicas existentes.

Implementar um data warehouse está longe de ser uma tarefa fácil, mesmo
considerando o desenvolvimento por assuntos (Data Marts). Faz-se necessária uma
atenção especial para o método de desenvolvimento. Este trabalho apresenta as fases do
projeto de implementação do data warehouse: levantamento, modelagem, extração,
modelagem multidimensional, análise de resultados, visões pré-definidas e segurança.
 iii

SUMÁRIO

Resumo ii
1. Introdução 1
2. Tecnologias 3
3. Infra-estrutura 5
4. Metodologia 9
4.1. Levantamento 9
4.2. Modelagem 11
4.3. Extração de dados 14
4.4. Modelagem Multidimensional 17
4.5. Análise de Resultados 19
4.6. Visões Pré-definidas 20
4.7. Segurança da Informação 21
6. Estudo de Caso 24
7. Conclusão 27
8. Lista de Abreviações e Siglas 28
9. Referências Bibliográficas 29
1. INTRODUÇÃO

Com o advento da computação, surgiram os primeiros programas para

transformação de dados em informação. Junto vieram alguns complicadores, como:
tempo de processamento, volume de dados, formas de acesso, meios físicos etc. As
tecnologias evoluíram, porém o conceito permanece. Transformar dados em informação
é a principal razão da existência da informática.

Os primeiros programas comerciais foram criados para auxiliar os processos

organizacionais, tais como folhas de pagamento, contabilização e controles de estoque.
Apesar da evolução das tecnologias estes aplicativos ainda são tão essenciais quanto os
sistemas especialistas.

Com o passar do tempo muitos aplicativos foram desenvolvidos para

automatizar os processos. Como conseqüência o volume de dados crescia ainda mais,
dificultando a obtenção de informações para análise e tomada de decisão.

Na década de 80 surgiram os primeiros sistemas comerciais para auxílio à

tomada de decisão. Tinham como objetivo resumir os dados essências e organizá-los. O
crescente volume e a complexidade para obter os dados, de diferentes fontes, tornaram
estes aplicativos ineficientes à medida que não disponibilizavam as informações
necessárias para tomada de decisão em tempo hábil. Observa-se que não importa ter
apenas os dados se a informação não está disponibilizada em momentos decisivos.

Surgiram na década seguinte os sistemas integrados (ERP) que agilizaram

processos, otimizando recursos. Como promessa destes mega-sistemas, todas as
informações necessárias seriam obtidas a partir deles. Porém, outros sistemas
especialistas ainda permaneciam por serem estratégicos e mais eficientes. Permanecia
também o problema da disponibilização da informação no momento certo. A
concorrência de transações da operação das empresas com busca de informações em
altos volumes de dados começaram a comprometer o ambiente. Ficando bem
caracterizado a que se destinavam os sistemas integrados: otimizar as transações das
empresas.

A evolução das tecnologias de busca de informação para tomada de decisão e a

necessidade de organizar os dados motivaram o estudo científico do problema. Segundo
INMON “Um data warehouse é um conjunto de dados baseado em assuntos, integrado,
 2

não volátil e variável em relação ao tempo, de apoio às decisões”. (1997, pág 33) Ele
demonstra em sua obra as principais técnicas para construção de um data warehouse.

A integração dos dados, associadas a técnicas e ferramentas, no data warehouse

proporcionam um ambiente de dados organizados por assuntos para obtenção de
informações para tomada de decisão. Imagina-se então que o DW seja um ambiente
onde todas as informações, para tomada de decisão, são obtidas.

Construir um DW está longe de ser uma tarefa fácil. As técnicas e as

ferramentas não são suficientes para garantir o êxito na construção. É necessária uma
metodologia capaz de levar à sua implementação. INMON acrescenta que “a tentativa
de aplicar ferramentas e técnicas de desenvolvimento inadequadas conduz apenas a
desperdício e confusão. Por exemplo, no mundo CASE predomina a análise baseada em
requisitos. Tentar aplicar as ferramentas e técnicas CASE ao mundo do Data warehouse
não é aconselhável e vice-versa”. (1997, pág 24) No ciclo de vida do DW predominam
os dados e a informação resultante da organização da base de dados.

Mesmo considerando seu desenvolvimento em partes (Data Marts) deve-se ter

a visão do todo para garantir a integração das informações. O armazém de dados (DW)
não pode ser apenas um repositório, onde os dados de diferentes aplicações estão na
mesma base de dados centralizada. Os dados devem estar organizados para refletir a
visão do negócio de forma integrada.

A metodologia descrita a seguir tem como objetivo uma orientação para

desenvolvimento evolutivo do data warehouse. Dividida em fases bem caracterizadas
pelo agrupamento das principais técnicas relacionadas. Ela descreve a finalidade de
cada fase, identificando os pontos críticos e descrevendo sucintamente as principais
técnicas.

As fases do projeto de implementação do data warehouse, por assunto, são:

levantamento de dados, modelagem de dados, extração de dados, modelagem
multidimensional, análise de resultados, visões pré-definidas e segurança da
informação. Além da descrição das fases do projeto também são abordadas neste
trabalho as tecnologias relacionadas ao data warehouse, a infra-estrutura necessária e
administração do data warehouse.

Numa definição singular, para este trabalho, o data warehouse é considerado

como: o repositório de dados para tomada de decisão.
 3

2. TECNOLOGIAS

Em parte o data warehouse é a evolução de algumas tecnologias. Outras que

surgiram em paralelo ao conceito de DW também evoluíram e possuem grandes
benefícios se estiverem integradas. Também existe um grupo de tecnologias mais
recente que foram influenciadas pela deficiência ou amadurecimento do conceito. A
seguir são definidas algumas das técnicas e ferramentas relacionadas com o data
warehouse.

Os Sistemas de Informações Gerenciais (SIGs) foram uma das primeiras

tentativas de criação de um ambiente único de informações para tomada de decisão.
Eles foram desenvolvidos para disponibilizar relatórios que atendessem ao corpo
gerencial das organizações. Porém, estes sistemas ainda não utilizavam técnicas de
organização de dados específicas que suportassem um ambiente com crescimento
escalar.

Como evolução dos SIGs os Executive Information Systems (EIS) foram

desenvolvidos para melhorar a interface com os executivos e solucionar alguns
problemas de performance. De acordo com INMON “por meio dos EIS o analista
executivo pode localizar problemas com precisão e detectar tendências que são de vital
importância para a gerência”.(1997, pág 237) Estes sistemas também eram suportados
pela tecnologia OLAP.

A tecnologia OLAP (On-Line Analytical Process) constitui um sistema de

armazenamento de dados agregados. Determinadas informações são obtidas a partir de
dados pré-calculados disponíveis para consulta direta, sem a necessidade da pesquisa
dos dados elementares e consolidação em tempo de execução, otimizando assim o
processo de consulta de dados. Estes sistemas também são conhecidos como
multidimensionais ou cubos, por permitirem a consulta de informações por múltiplas
visões.

O armazém de dados (DW), em si, é suportado por um Sistema Gerenciador de

Banco de Dados (SGBD), onde os dados extraídos dos sistemas transacionais são
armazenados. O DW também utiliza a tecnologia OLAP para permitir as consultas
analíticas On-Line.
 4

É importante contextualizar algumas tecnologias que são influenciadas ou

dependentes do DW para preparação de um ambiente que suporte de forma eficaz tais
tecnologias.

Atualmente os EISs, associados com o data warehouse, podem ser

considerados como sistemas de BI (Business Intelligence). Outras tecnologias como
Data Mining também influenciam o BI, na descoberta de conhecimento.

Obter informação de uma grande base de informações (DW) pode se tornar

uma tarefa difícil, mesmo que organizada por assuntos. Explorar as informações, por
meio de ferramentas analíticas, pode não ser eficaz quando não se tem a certeza do que
se está procurando. A tecnologia de Data Mining, com seus algoritmos e técnicas pode
ser facilitada se existir uma fonte de dados organizada. CARVALHO relata que “em
uma empresa que deseja analisar o conteúdo da massa de dados criada por suas
atividades, um processo de unificação precisa ser efetuado de forma a possibilitar o
acesso de um indivíduo (analista) às múltiplas faces desta informação. Para que o data
mining seja realizado, é necessário o acesso a uma massa de dados limpa, consistente e
unificada em sua linguagem e lógica. Certamente que analistas vêm realizando data
mining há muitos anos, utilizando ferramentas simples e bancos de dados separados,
porém a construção de um data warehouse em muito facilita o processo de mineração de
dados e de decisão”. (2001, pág 193)

SWIFT define que “CRM é totalmente dependente de um local centralizado de

dados detalhados sobre clientes, seus comportamentos e suas preferências, incluindo
detalhes específicos sobre privacidade de dados: o data warehouse”. (2001, pág 65)

Analisar as informações contidas no data warehouse, com crescente volume de

dados, pode não ser eficiente com relatórios, books, gráficos etc. São muitas
informações a serem analisadas. Algumas corporações estão adotando o Balanced
Scorecard (BSC) como uma metodologia de gestão, onde são definidos indicadores de
performance. Para estes indicadores são definidas metas e ações dentro da organização.
Sistemas de BSC disponíveis no mercado têm maior eficiência se integrados ao data
warehouse, caso contrário terão que buscar os dados para os indicadores diretamente
nos sistemas transacionais.

Outro sistema relacionado ao BSC é o de Performance Management (PM),

também conhecido como Business (BPM), Corporate (CPM) ou Enterprise Performance
 5

Management (EPM), que definem as metas dos indicadores. Estes sistemas, muitas
vezes, utilizam o histórico dos indicadores como fonte para cálculo das metas.

Fica evidente assim que a construção do data warehouse deve levar em

consideração como as informações serão utilizadas e integradas a outros sistemas e
processos das instituições.

A metodologia de implementação de data warehouse, por assuntos, é descrita

neste trabalho pelas fases de:

Definição da infra-estrutura

Levantamento de dados

Modelagem de dados

Extração de dados

Modelagem multidimensional

Análise de resultados

Visões pré-definidas

Segurança da informação

Administração

3. INFRA-ESTRUTURA

A infra-estrutura deverá suportar o ambiente projetado, com alto crescimento

de dados, consultas complexas e não previstas (ad-hoc), diversidade de integração,
diferentes tipos de tecnologias etc. O produto final do DW serão os dados, organizados
e de fácil entendimento.

As ferramentas a serem utilizadas para a construção do data warehouse sejam,

talvez, uma das menores preocupações que o arquiteto tenha. Integrar os sistemas,
organizar os dados e disponibilizar as informações serão preocupações constantes.
Desta forma, não importa muito qual o fornecedor ou marca devemos escolher, porém
algumas características devem ser levadas em consideração.

Como dito anteriormente, a principal ferramenta de um data warehouse é o

Banco de dados (SGBD), onde os dados extraídos dos sistemas transacionais ficarão
 6

armazenados. Ele deverá suportar: grandes volumes de dados, alta performance para
carga de dados e consulta de informações, flexibilidade para alteração de estruturas,
fácil administração e operação, baixo custo por usuário, integração com diferentes
plataformas e sistemas, etc. Devem-se evitar utilizar características que dificultem a
migração para outra plataforma. Em longo prazo, por questões de custo, pode ser
necessária uma mudança de plataforma. Com tanta integração e a utilização do DW por
toda organização o custo de licença de uso, por usuário, deve ser considerado desde o
início como um fator crítico. Sendo os dados o mais importante, a estrutura de
organização dos dados deve ser muito bem conhecida, documentada e de fácil acesso.

Para suportar consultas complexas e não previstas (ad-hoc) é necessário que

tanto dados detalhados quanto totalizadores, fórmulas e conjuntos de dados possam ser
consultados com o menor tempo de resposta possível. A infra-estrutura do data
warehouse deve possuir uma ferramenta que suporte este tipo de consulta. As
ferramentas OLAP possuem tais características, simplificando assim o trabalho de
agregação e visualização das informações.

THOMSEN define que “os conceitos de OLAP incluem a noção ou idéia de

múltiplas dimensões hierárquicas e podem ser usados por qualquer um para que se
pense mais claramente a respeito do mundo, seja o mundo material da escala atômica à
escala galáctica, o mundo econômico dos micros agentes à macro economias, ou o
mundo social dos relacionamentos interpessoais aos internacionais. Em outras palavras,
mesmo sem qualquer tipo de linguagem formal, é útil apenas sermos capazes de pensar
em termos de um mundo multidimensional e com múltiplos níveis, independentes da
sua posição na vida”.

“Outras linguagens formais, incluindo Data Definition Language (DDL), Data

Manipulation Language (DML), Data Representation Language (DRL) e seus
analisadores associados (e compiladores opcionais), poderia ser usada para qualquer
modelagem descritiva, seja ela transacional ou de suporte à tomada de decisão. Em
outras palavras, a associação de OLAP com suporte à tomada de decisão é mais uma
função das características físicas de otimização dos produtos OLAP do que quaisquer
características inerentes das construções de linguagem do OLAP”.

“As camadas de produto do OLAP normalmente residem em cima dos bancos

de dados relacionais e geram SQL como saída da combinação. O armazenamento e o
acesso aos dados são tratados pelo banco de dados”.
 7

“Produtos OLAP completos, que precisam incluir um compilador e métodos de

armazenamento e acesso, são otimizados para acesso a dados e cálculos rápidos, sendo
usados para a modelagem descritiva de dados, derivada de sistemas de suporte à tomada
de decisão (DSS – Decision Support Systems). A fronteira entre linguagens e produtos
OLAP não é demarcada com clareza”.(2002, pág 5)

Resumidamente, as ferramentas OLAP fazem parte da infra-estrutura do Data

Warehouse para consolidação de dados (agregação), aplicação de regras de negócio,
cálculos (fórmulas) e disponibilizar a visão multidimensional.

Para obter os dados do ambiente operacional para o data warehouse, podem ser
utilizadas várias linguagens, formas de acesso, conectores de dados e meios físicos
diferentes (discos, fitas, rede etc). Segundo INMON, “à primeira vista, quando os dados
são movidos do ambiente herdado para o ambiente do data warehouse, parece que nada
além de simples extrações de dados de um local para o próximo está ocorrendo. Em
virtude dessa enganosa simplicidade, muitas empresas começaram a construir seus data
warehouses manualmente. O programador olha para a movimentação de dados do
antigo ambiente operacional para o novo data warehouse e declara: “Eu posso fazer
isso”! Munido de lápis e formulário de codificação, nos três primeiros minutos do
projeto e desenvolvimento do data warehouse, o programador ansiosamente mergulha
na criação do código”.

“Contudo, primeiras impressões podem ser muito enganadoras. O que em um

primeiro momento parece ser nada mais do que a movimentação de dados de um local
para outro transforma-se, rapidamente, em uma grande e complexa tarefa – muito maior
e mais complexa do que o programador negociou”.(1997, pág 115)

Como veremos adiante, em detalhes, no tópico de extração de dados, são

necessárias algumas técnicas para esta tarefa. É verdade que, por meio de programação,
a extração de dados possa ser feita. Sendo assim a extração de dados é uma das camadas
da arquitetura do data warehouse. O fato da extração de dados poder ser executada por
programação não significa que seja a mais eficiente. O alto volume de dados, a
diversidade de tecnologias envolvidas e a complexidade de transformações podem
dificultar a manutenção dos extratores e o tempo de desenvolvimento comprometido.

Para atender a esta camada algumas empresas fornecedoras de software

desenvolveram ferramentas de ETL (Extract Transform and Load), facilitando em muito
 8

a integração e operacionalização. Considerando que a fase de extração pode consumir

cerca de 70% do tempo de desenvolvimento do projeto. Abrir mão de uma ferramenta
de ETL pode ser um grande risco para o projeto e comprometê-lo. Investir numa
ferramenta, que garanta a integração e atenda aos requisitos da extração de dados, é no
mínimo aconselhável. Além disso, usualmente os fornecedores não cobram por
conectores ou pontos de integração e sim como um pacote, portanto investir mais nestas
ferramentas não irá aumentar os custos à medida que o data warehouse se expandir.

Para que a arquitetura do data warehouse esteja completa é necessário uma

última camada. A consulta, análise e visualização das informações compõem esta
camada. Apesar dos bancos de dados possuírem formas de acesso e as ferramentas
OLAP visões multidimensionais, é necessário que os usuários possam acessar as
informações de forma integrada ao seu ambiente de trabalho. Como requisito mínimo
para a arquitetura do data warehouse deve-se considerar uma ferramenta que acesse os
dados armazenados e de forma exploratória possam analisar os dados. Outra forma de
acesso, de forma orientada, são os portais de informação, que são constituídos por
visões pré-definidas, consultas e relatórios pré-formatados.

Nas quatro camadas descritas acima (armazenamento, extração, consolidação e

análise) devemos considerar o alto volume de dados, múltiplos acessos simultâneos e
alta disponibilidade. Esta preocupação garantirá a escalabilidade do ambiente do data
warehouse.

Outro fator muito importante está na flexibilidade que o ambiente deve possuir
para atender as constantes mudanças de visão do negócio. Uma empresa que opera com
apenas um produto pode passar a comercializar outros, assim como uma empresa pode
se tornar uma grande organização composta por diferentes unidades de negócio. Não é
necessário que estas mudanças estejam previstas no data warehouse, porém a
implementação delas não pode ser inviabilizada pela arquitetura utilizada.

INMON observou que “outra importante diferença entre os ambientes

operacionais e de data warehouse são os padrões de utilização de hardware que ocorrem
em cada ambiente”. (1997, pág 25) No processamento operacional há picos e platôs no
processamento, mas há uma constante de utilização elevada e estável. No DW há uma
utilização binária, ou seja, totalmente utilizado ou simplesmente não está. INMON
acrescenta que “esta diferença fundamental consiste em mais uma razão para o fato de
que tentar combinar os dois ambientes na mesma máquina e ao mesmo tempo não
 9

funciona. Você pode otimizar sua máquina para o processamento operacional ou pode
otimizar sua máquina para o processamento do data warehouse, mas não é possível ter
ambas as situações ao mesmo tempo e no mesmo equipamento”.(1997, pág 25)

Esta característica de utilização determina que o ambiente deve ser

completamente separado do operacional, sendo assim, todos os equipamentos devem ser
separados, sem nenhum tipo de compartilhamento. Isto nos leva a crer que a utilização
de rede também terá algum impacto e deve ser levada em consideração na arquitetura. O
armazenamento de dados em discos externos também não deve ser compartilhado.

Considerando que os dados são históricos e não voláteis no data warehouse,

podemos chegar à conclusão que as contingências podem ser reduzidas, ou seja, sem
redundância de disco por exemplo. Porém, a disponibilidade do DW para tomada de
decisão tende a aumentar e correr o risco de não ter a informação em tempo hábil não é
compatível com este ambiente.

4. METODOLOGIA

4.1. LEVANTAMENTO

Sendo o data warehouse um grande repositório de dados e possuindo como

origem os dados dos sistemas transacionais, podemos concluir que a principal análise
deve ser feita com base no dados e não nas funções e requisitos. INMON confronta o
ciclo de vida dos projetos de sistemas clássicos (SDLC) com o data warehouse, onde “o
sistema clássico é baseado em requisitos. Para desenvolver sistemas, primeiro é
necessário entender as necessidades. Depois disso, vêm às fases de projeto e
desenvolvimento. O ciclo do DW é o inverso. No DW começa pelos dados. Uma vez
que os dados estejam sob controle, eles são integrados e, em seguida, testados para que
se verifiquem quais distorções há neles, se houver alguma. Então, é feita a codificação
de programas para os dados. Os resultados dos programas são analisados e, finalmente,
os requisitos do sistema são compreendidos”.(1997, pág 24)

Analisar as bases de dados de grandes corporações pode não ser uma tarefa
eficiente, pois nem todas possuem documentação e nem mesmo seguem os padrões de
normalização de dados. Sendo assim, vasculhar as bases de dados dos sistemas
transacionais sem um direcionamento prévio exigirá um esforço grande dos arquitetos
do data warehouse.
 10

A principal abordagem para construção do DW é pela implementação de Data

Marts, que são assuntos específicos das áreas das empresas. Os Data Marts têm sua
origem na construção de cubos, pela utilização da tecnologia OLAP. Esta abordagem é
considerada por alguns autores como ineficiente por não considerar a integração com
outras bases de dados dentro do data warehouse. Outra característica dos Data Marts, a
ser considerada, é a implementação em partes para se chegar ao todo (Bottom-Up).

Mesmo considerando a construção do DW por partes, alguns Data Marts

podem ser muito complexos. Os Data Marts podem ter como origem mais de uma base
de dados e cada uma com dezenas ou centenas de tabelas. Como orientação para o
trabalho de levantamento de dados outras fontes devem ser analisadas.

Analisando as principais questões, referentes ao assunto, pode-se observar que

existirá a carência por algum tipo de informação específica ou que a informação atual
não é confiável, conflitante com dados de outra área da empresa ou fora do tempo para
tomada de decisão. Desta forma são identificados problemas analíticos que não são
solucionados pelos sistemas transacionais, como exemplo a análise de comportamento
dos clientes ao longo do tempo. Caso o sistema transacional tente solucionar este tipo de
questão ele pode se tornar ineficaz para as transações ou gerar a informação fora do
tempo.

O direcionamento para as principais questões pode ser dado pelos gestores e

executivos da organização, desta forma é possível traçar um alinhamento com a visão
estratégica da empresa. A equipe coordenadora do Data Warehouse deve ter acesso ao
plano estratégico da empresa, bem como ter o pleno entendimento da visão da empresa.

Numa análise mais ampla devem-se revisar os processos das áreas relacionadas
com o assunto, onde são observadas as regras de negócio. Estas regras podem dar
origem às transformações na fase de extração de dados. Em geral as transformações
podem ocorrer por questões técnicas, mudanças de formatos ou uma visão de negócio.
As transformações por visão de negócio acontecem em geral por adaptação dos
processos das empresas aos sistemas, normalmente em casos de implantação de ERPs.

Outra fonte que pode auxiliar nesta fase de levantamento de dados são
relatórios gerenciais, que muitas vezes são improvisados em planilhas eletrônicas a
partir da coleta de dados de várias fontes. É comum encontrar nestes relatórios os
principais indicadores monetários e físicos (quantitativos).
 11

A análise das bases de dados dos sistemas transacionais pode ser iniciada pela
pesquisa das tabelas com maior volume de dados. Estas tabelas normalmente são
referentes a eventos ou fatos que ocorrem com freqüência, indicados por campos de data
ou período. Comumente estas tabelas são definidas como ordens, itens, detalhamento
etc. Os atributos destas tabelas são compostos, em grande parte, por chaves estrangeiras
(foreign key) e indicadores. Os indicadores são dados quantitativos, monetários, taxas e
medidas. As tabelas relacionadas com a tabela de eventos (ou fatos) podem dar origem
às dimensões, que são as diferentes visões que se poderá ter do assunto.

Após a análise das bases de dados, dos relatórios e reuniões de levantamento

deve ser produzida uma especificação com a definição do assunto, os objetivos da
análise do assunto, as principais questões, a definição das regras de negócio, os
indicadores, as múltiplas visões do assunto, o mapeamento dos dados das bases de
origem e a periodicidade para extração dos dados.

O mapeamento dos dados deve ser bastante detalhado para facilitar o trabalho
na fase de extração de dados. Neste mapeamento de dados devem ser indicados as bases
de dados, arquivos, tabelas, campos, atributos, formatos etc.

Esta especificação será utilizada durante todo o projeto do Data Mart como
orientação para que os objetivos sejam atingidos.

4.2. MODELAGEM

Identificados os dados que deverão ser extraídos dos sistemas transacionais

pode-se iniciar a modelagem para armazenamento no data warehouse.

A modelagem para o DW tem grande influência das ferramentas OLAP que,

por questões de performance e visualização das informações, dependem de um modelo
estrela. Este modelo, de forma resumida apresenta os fatos ao centro e todas as
dimensões relacionadas aos fatos. Existem algumas variações desse modelo como o
modelo em cascata (snowflake), que para algumas tabelas de dimensões estarão
relacionadas com outras tabelas. Estas tabelas relacionadas às dimensões darão origem,
em grande parte, a níveis de consolidação da dimensão no modelo multidimensional,
como será discutido mais adiante.

O modelo lógico para um Data Mart é bastante simples, com algumas

restrições. O relacionamento dos fatos com as dimensões não poderão ter cardinalidade
 12

N para N, ou seja, um fato não pode estar relacionado com mais de um elemento de uma
tabela de dimensão. Os elementos das tabelas de dimensão estarão relacionados com
vários itens da tabela de fatos, caracterizando assim a necessidade de agregação.

A desnormalização de dados no data warehouse é aceita e em muitos casos

indicada para solucionar problemas de performance e espaço em disco, combinando
dados de várias tabelas do modelo de dados dos sistemas transacionais em uma tabela
de fatos ou dimensão. INMON “É interessante observar que, no data warehouse, essas
circunstâncias ocorrem regularmente em função de os dados serem baseados em
parâmetros de tempo. Os dados do data warehouse sempre apresentam relevância em
relação a um determinado momento, e unidades de tempo ocorrem com grande
regularidade. Em um data warehouse, a criação de um array por mês, por exemplo, é
algo muito natural. Outra importante técnica de projeto especialmente relevante para o
ambiente de data warehouse consiste na introdução intencional de dados
redundantes”.(1997, pág 100) Contudo, algumas ferramentas de mercado estão cada vez
mais adaptadas aos conceitos de data warehouse. Tirando grande proveito do ambiente
relacional, sem perder o conceito, para construir bases multidimensionais (OLAP) com
maior eficiência. Sendo assim, não devemos abrir mão da desnormalização para tudo,
mas sempre que necessário.

Um dos aspectos mais importante na modelagem é definir a granularidade dos

dados. As bases de dados transacionais possuem muitos dados de controle das
transações que talvez não sejam relevantes para tomada de decisão. INMON “A razão
pela qual a granularidade é a principal questão de projeto consiste no fato de que ela
afeta profundamente o volume de dados que residem no data warehouse e, ao mesmo
tempo, afeta o tipo de consulta que pode ser atendida. O volume de dados contidos no
data warehouse é balanceado de acordo com o nível de detalhe de uma consulta”.(1997,
pág 45)

Outro paradigma a ser rompido em relação aos sistemas transacionais é

referente à representação de acontecimentos passados. KIMBALL “Os sistemas OLTP e
data warehouse tratam o tempo de forma diferente. O melhor sistema OLTP é um status
instantâneo dos negócios de uma organização, atualizado constantemente à medida que
as transações são concretizadas. Os valores-chave do negócio devem mudar a cada
minuto ou segundo. O status muda continuamente e os relacionamentos entre as
entidades são alterados”. (1998, pág 100) No DW estes instantâneos serão armazenados
 13

e identificados com uma marca de tempo, onde poderemos observar as mudanças de

comportamento, seja de clientes ou produtos.

Algumas dimensões no data warehouse devem ser observadas com mais

atenção, pois possuem grande relevância para a integração dos dados. Quando
importamos os fatos dos sistemas transacionais para o DW observamos sempre que
possuem o atributo de tempo. Portanto, a dimensão de tempo terá grande importância
para o modelo de dados do data warehouse. Outra característica importante é podermos
definir atributos comuns para os fatos, através do tempo, como: feriados, acontecimento
importante (externos ou internos da organização), dia da semana etc.

Fatos diferentes podem dar origem à outra dimensão que deve ser observada
com atenção. A relação de fatos realizados com previstos ou calculados é o conceito de
versão, que é representado usualmente nos data warehouses como uma dimensão de
versão.

Mais recentemente, com a evolução dos conceitos de marketing, e mais

especificamente do marketing de relacionamento, o cliente tem ganhado maior atenção
dos analistas de data warehouse, com o intuito de atender as necessidades dos sistemas
de CRM (Customer Relationship Management). Modelar os dados dos clientes de forma
que seja possível observar as mudanças do mesmo, ao longo do tempo, é fundamental
para atender a esta finalidade.

Diferentemente da modelagem de dados dos sistemas transacionais, com os

modelos de entidade e relacionamento (MER), no data warehouse o modelo de dados
físico se apresenta muito semelhante ao lógico, seguindo o conceito estrela e suas
variações. Porém, a preocupação será no armazenamento, objetivando maior
performance e menor custo de espaço para o armazenamento de dados.

Devemos ter maior atenção para as tabelas de fatos, pois noventa por cento dos
dados de cada Data Mart serão armazenados nestas tabelas. As tabelas de fatos serão
compostas por dois grupos de atributos chaves estrangeiras e indicadores. O
dimensionamento correto dos tipos de dados das chaves das dimensões e dos
indicadores determinará o espaço necessário para o armazenamento.

A granularidade das tabelas de fatos poderá ser reavaliada após alguns anos de
dados armazenados. INMON comenta sobre níveis duais de granularidade, onde “na
maior parte do tempo, há uma grande demanda por eficiência no armazenamento de
 14

dados e no acesso a eles bem como pela possibilidade de analisar dados em maior
detalhe. (Em outras palavras, a organização quer fazer o gol e defender ao mesmo
tempo!) Quando uma organização possui grandes quantidades de dados no data
warehouse, faz sentido pensar em dois (ou mais) níveis de granularidade na parte
detalhada do data warehouse”. (1997, pág 49) Deve ser observado que, efetuando este
tipo de modelagem, alguma informação será perdida ao longo do tempo.

Outro aspecto a ser considerado no modelo físico é o particionamento dos

dados. O particionamento permitirá o gerenciamento flexível dos dados e a distribuição
de bases de dados por unidades de negócio de forma descentralizada.

Resumidamente o modelo de dados do data warehouse refletirá a organização

dos fatos e dimensões na base de dados.

4.3. EXTRAÇÃO DE DADOS

O data warehouse é dependente dos sistemas transacionais internos ou externos

das instituições. Os sistemas transacionais são a fonte de dados para o data warehouse,
como a matéria-prima para a fabricação de um produto. Interligar estes ambientes tão
heterogêneos, com: tecnologias diversificadas, diferentes bases de dados, formatos
diferentes, conexões e distâncias; torna a fase de extração de dados a mais trabalhosa,
consumindo cerca de 70% do tempo da equipe do data warehouse.

Quando a integração entre os sistemas transacionais e o DW não possui um

suporte tecnológico ideal, é possível subdividir esta fase em: extração e importação dos
dados. As transformações serão tratadas no momento da importação.

É possível extrair os dados dos sistemas transacionais no formato adequado

para simples importação no data warehouse. Porém, esta pode não ser a estratégia mais
adequada, pois as transformações possivelmente ficariam nos ambientes transacionais,
tornando-os mais complexos. Outro fator é a manutenibilidade das regras de negócio
que, desta forma, de nada agregará aos sistemas transacionais implementar as regras de
transformação. Esta situação ainda poderá trazer problemas de performance para o
ambiente transacional, com processos concorrentes entre extratores e transações ou
processos operacionais.

Deve-se manter a integração entre estes ambientes a mais automática possível,

evitando a manipulação de dados pelos usuários e reduzindo risco a falhas. As
 15

ferramentas de ETL (Extract Transform and Load) são de suma importância para a
integração dos ambientes transacionais e o data warehouse.

Com base na especificação definida no levantamento de dados serão

produzidas novas especificações de desenvolvimento: definição dos extratores e
especificação das importações dos dados. Tendo estas especificações bem definidas é
possível executá-las em paralelo.

As especificações dos extratores conterão a definição da seleção dos dados,

critérios de seleção, formato de saída, objetos que devem ser criados, parâmetros da
interface, script de teste e controles de erro.

A seleção dos dados e os critérios de seleção definirão quais os objetos,

campos e tabelas, dos sistemas transacionais serão manipulados e qual a relação entre
eles. Os critérios de seleção também poderão conter restrições fixas da seleção dos
dados, que sejam exclusivamente referentes à complexidade de busca dos dados do
sistema transacional específico, não sendo assim nenhuma transformação de dados.

O formato de saída basicamente define a ordem dos campos, largura de colunas

e conversões elementares, tais como formato de data.

Os parâmetros da interface são os critérios de seleção enviados pelo processo

principal de carga de dados que coordena as interfaces.

Os controles de erro são fundamentais para a integração com o ambiente do

data warehouse, onde poderão ser monitoradas as falhas no processo para comunicação
aos administradores dos sistemas.

O script de teste é a descrição de como a extração pode ser executada e qual o

resultado esperado. Este teste permite a validação do processo independentemente da
integração com o data warehouse.

Como produto das especificações de extração são produzidos alguns objetos,

tais como: programas, arquivos, conectores etc. A especificação deverá conter também
o local de armazenamento dos objetos.

Observa-se que as interfaces dos extratores devem ser flexíveis, permitindo

assim a re-execução dos processos para correção de erros. Deve-se ter como objetivo
primário na definição dos extratores que qualquer processo possa ser executado a
qualquer tempo. Mesmo considerando que a definição da periodicidade de extração
 16

definida na especificação de levantamento de dados e alinhada com a necessidade da

área de negócio, os extratores devem possuir a capacidade de serem executados a
qualquer tempo para correção de problemas adversos.

Com a periodicidade definida, deve-se buscar o menor volume de dados

possível dos sistemas transacionais. INMON “Outro importante problema diz respeito
ao acesso eficiente aos dados dos sistemas existentes. Como pode o programa que varre
os sistemas existentes saber se um arquivo já foi 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 data warehouse é
antieconômica e pouco realista. Há três tipos de carga que podem ser feitos do ambiente
operacional para o data warehouse: o carregamento de dados históricos, o carregamento
de dados de valor corrente no ambiente operacional e o carregamento de alterações do
data warehouse a partir de alterações (atualizações) que tenham ocorrido no ambiente
operacional desde a última atualização do data warehouse”.(1997, pág 76)

Para solucionar o problema do corte dos dados podem ser empregadas algumas
técnicas: marcar de tempo, arquivo de log ou auditoria, arquivo delta, imagem anterior /
posterior e alteração da aplicação do sistema transacional.

A performance de carga de dados estará relacionada diretamente com o volume

de dados extraído do sistema transacional. Podem-se empregar técnicas de segmentação,
principalmente dos fatos, para carregá-los em paralelo.

As especificações de importação de dados devem tratar de como os dados

devem ser carregados no data warehouse. Este processo também contempla a
coordenação dos sub-processos para carga de cada uma das interfaces das tabelas de
dimensões e fatos. Esta especificação deve conter as definições do: mapeamento técnico
dos dados da origem para as tabelas do data warehouse, as transformações de tipos de
dados, as transformações de substituição de chaves, transformações das regras de
negócio e verificação dos possíveis erros no processo de extração.

As interfaces com alto grau de acoplamento, ou seja, com tecnologias similares

ao data warehouse, podem ser tratadas em apenas uma especificação.

Uma particularidade da extração dos dados é a conversão inicial dos dados dos
sistemas transacionais para o data warehouse. Após o desenvolvimento dos extratores é
possível iniciar a carga de dados para o data warehouse. Porém, vale avançar para as
 17

próximas fases do projeto até a análise de resultados, onde algumas validações podem
ser executadas e possivelmente trará modificações para os extratores de dados. Por fim,
após as modificações, os dados devem ser convertidos por períodos. Tentar trazer todos
os dados de uma só vez não é recomendado, podendo causar grande impacto nos
sistemas transacionais, que já estão em ambiente produtivo.

É comum verificarmos que, após a carga dos dados dos sistemas transacionais
para o data warehouse, muitas informações não possuem o valor esperado. Após as
primeiras cargas de dados, é necessário fazer uma análise criteriosa das informações.
Muitos dados podem não estar qualificados, ou seja, os dados contidos nos sistemas
transacionais não estão consistentes. Este problema de qualificação e análise dos dados
é abordado com mais detalhes na fase de análise de resultados, onde o analista de
suporte a decisão tem grande participação no processo.

4.4. MODELAGEM MULTIDIMENSIONAL

Após a carga de dados poderíamos considerar que o data warehouse está

concluído. Porém, como todo sistema pressupõe a entrada, processamento e saída,
devemos considerar a análise dos dados como saída primária do data warehouse.

O modelo de dados lógico e físico, descrito anteriormente, do data warehouse é

constituído por uma visão multidimensional, em estrela. Porém, eles representam,
respectivamente, uma visão de entendimento do negócio e como os dados estarão
armazenados no DW. A modelagem multidimensional formará uma camada
intermediária entre a base de dados e as ferramentas de consulta de dados, que serão
definidas mais à frente.

Especificamente nesta fase será tratada a questão da utilização das ferramentas

OLAP. Os principais conceitos da tecnologia OLAP são: visão multidimensional,
agregação de dados, análise exploratória e cálculos. THOMSEN define que “os
requisitos funcionais para OLAP possuem um formato central e periférico. Os requisitos
centrais, raiz, necessários ou mínimos no lado lógico incluem suporte para múltiplas
dimensões, hierarquias, fórmulas dimensionais e separação de estrutura de dados e
representação. Fisicamente, o principal requisito é velocidade suficiente para oferecer
suporte à análise ocasional. Qualquer linguagem ou produto que não aceite pelo menos
esses requisitos não pode, com seriedade, ser classificado como oferecendo suporte a
OLAP”.(2002, pág 20)
 18

A característica de ser multidimensional, das ferramentas OLAP, permite que

os assuntos (Data Marts) sejam analisados por diferentes visões (prismas, ângulos etc).
Esta característica está intimamente ligada a análise exploratória que permite ao analista
de suporte a decisão investigar os dados, adquirindo conhecimento, validando
suposições, análise de tendências e confrontando diferentes aspectos do assunto, entre
outras análises possíveis.

Se considerássemos uma base de dados ideal que, para qualquer consulta

executada, o tempo de resposta fosse sempre imediato, uma das questões mais
importantes tratadas pelas ferramentas OLAP não seria necessária. A agregação das
informações, executada pelo processamento das ferramentas OLAP, disponibilizará
imediatamente as informações, independente da complexidade da consulta. Se as
agregações foram feitas por demanda deve ser de forma imperceptível para os analistas
de suporte à decisão. De forma simplista as ferramentas OLAP devem calcular (agregar)
todas as combinações e totais possíveis para que as informações sejam consultadas em
tempo hábil para tomada de decisão, independente da quantidade de dados armazenada
na base de dados do data warehouse.

Tecnicamente a fase de modelagem multidimensional é onde são

desenvolvidos os cubos, definindo as visões multidimensionais nas ferramentas OLAP.
Grande parte do trabalho, para esta fase, já foi executado na fase de modelagem, com a
definição das tabelas de fatos e dimensões. Contudo, é necessário configurar a
ferramenta OLAP para definir a origem dos dados para consolidação das informações.
Algumas das regras de negócio, identificadas no levantamento de dados, estarão
explicitadas por meio de fórmulas na estrutura dos cubos, como membros calculados.

Nesta interface entre a base de dados do data warehouse e a ferramenta OLAP

é importante que ela seja flexível, permitindo a adaptação de novas regras de negócio do
constante amadurecimento das organizações. Como importante recurso para comportar
estas adequações os SGBDs visões (view), ou seja, consultas predefinidas que são
armazenadas na estrutura do banco de dados, reduzindo assim o esforço para
manutenção dos cubos.

Portanto, o modelo multidimensional deverá refletir as possíveis visões e

responder a maioria das questões identificadas na fase de levantamento de dados.
Permitindo assim que os analistas de suporte a decisão executem consultas analistas On-
Line.
 19

4.5. ANÁLISE DE RESULTADOS

Esta fase pressupõe que as informações já estão disponíveis para análise. Não é
necessário que todos os dados já tenham sido carregados para o data warehouse, mas
uma parte significativa que permita a avaliação dos resultados. Neste ponto do projeto o
analista de suporte a decisão tem a responsabilidade de validar as informações contidas
no data warehouse. O analista deverá observar a conformidade das informações
disponibilizadas com a especificação produzida na fase de levantamento de dados.

Este trabalho deverá ser o mais rigoroso possível, pois a partir das informações
contidas no data warehouse e disponibilizadas elas serão usadas para a tomada de
decisão. Uma informação errada pode causar mais prejuízos que a falta delas.

Neste ponto o analista de suporte a decisão, com o apoio do arquiteto do data

warehouse, poderão identificar falhas no processo de extração. Também será possível
qualificar as informações obtidas a partir das bases de dados dos sistemas transacionais,
identificando campos que não foram preenchidos corretamente ao longo dos anos de
produtividade desses sistemas. A visão macro das informações, disponibilizada pelas
ferramentas OLAP, permitirá aos analistas descobrir fatos não identificáveis no
ambiente transacional. Eventualmente estas análises servirão para definição de novas
regras de negócios e requisitos para os sistemas transacionais, tais como a
obrigatoriedade do preenchimento de determinados dados ou novas regras de
integridade.

O trabalho da análise de resultados inicia um novo ciclo no desenvolvimento

do Data Mart, obrigando ao arquiteto do data warehouse reavaliar os dados dos sistemas
de origem, ajustar a especificação e passar pelas fases de modelagem, extração e
modelagem multidimensional para que as informações sejam novamente analisados.

Garantir a confiabilidade das informações do data warehouse é uma tarefa

constante, mesmo após a implementação do Data Mart. Fatos externos, adequações a
legislação e mudanças organizacionais podem afetar de forma direta ou indiretamente o
data warehouse. A confiabilidade das informações do data warehouse deve ser mantida
realizado validações periódicas e ajustando os dados da base de dados constantemente.
Caso as validações não ocorram com freqüência é comum acontecer dos usuários
deixarem de consultar as informações, tomarem decisões baseadas em dados errados ou
 20

fazer com que os executivos percam a confiança nas informações de tal modo que se
determine a descontinuidade do projeto todo.

O comprometimento dos executivos e analistas de suporte a decisão é

fundamental para o sucesso do projeto, garantindo confiança nas informações e
continuidade.

4.6. VISÕES PRÉ-DEFINIDAS

Grande parte das informações já foi disponibilizada para os usuários de suporte

a decisão, através da utilização das ferramentas OLAP. Porém nem todas as consultas
devem ser feitas de forma exploratória, obrigando aos usuários a pesquisa desde o
início.

Esta fase do projeto tratará da disponibilização de visões direcionadas e

freqüentemente extraídas do DW, através de relatórios. Existem alguns grupos de
relatórios que serão disponibilizados: relatórios gerenciais, consultas complexas,
indicadores, consultas direcionadas etc.

Em muitos casos estes relatórios são disponibilizados por meio de portais de

informação. Onde os gestores, que não dispõe de muito tempo para explorar as
informações e em grande parte dependentes do trabalho dos analistas de suporte a
decisão, poderão consultar as informações periodicamente e norteando sua equipe, de
acordo com o alinhamento estratégico da organização.

Os relatórios gerenciais, agora obtendo os dados pelo data warehouse, com a

garantia de que a informação estará disponível para tomada de decisão em tempo hábil,
integrada a outras visões da empresa e a versão única da verdade. A unicidade da
informação garantirá que nenhum relatório conflitante seja apresentado aos gestores.

Num ambiente integrado algumas análises podem ser feitas de forma orientada,
onde os analistas de suporte a decisão e os gestores podem “navegar” entre relatórios
obtendo o detalhe necessário para suas conclusões e observação de comportamento de
vendas, clientes, produtos etc.

Mesmo num ambiente proporcionado pelas ferramentas OLAP algumas

consultas serão muito complexas para que os analistas de suporte a decisão possam
desenvolver seus relatórios sem o auxílio do arquiteto do data warehouse. Estes
relatórios necessitam de profissionais tecnicamente preparados para utilização de
 21

funções específicas das linguagens de consulta de dados das ferramentas OLAP ou da

utilização de ferramentas de Data Mining.

Algumas das principais questões, documentadas na especificação do

levantamento de dados, poderão ser respondidas com a criação de visões pré-definidas,
já que as informações estão disponíveis.

Os indicadores da empresa poderão estar disponibilizados como visões

predefinidas e possivelmente alinhados com conceitos de gestão organizacionais, como
Balanced Scorecard (BSC).

A camada de visões pré-definidas poderá obter as informações diretamente da

base de dados do data warehouse ou pela configuração de consultas aos cubos.

4.7. SEGURANÇA DA INFORMAÇÃO

Grande parte das informações disponibilizadas no data warehouse refletem as

visões táticas e estratégicas das organizações, portanto nem todos poderão ter acesso a
estas informações. Esta fase deve tratar de quem pode, quem deve, como pode e por
onde as informações devem ser consultadas.

A política de segurança para o ambiente do data warehouse deve ser muito

flexível, permitindo que pessoas com perfis macro ou mais específicos possam acessar
as informações de sua responsabilidade ou interesse empresarial.

Cada um ao seu nível de decisão ou de análise deve acessar a informação,

porém existirão alguns grupos específicos da organização que deverão ter acesso quase
irrestrito ao data warehouse, são as áreas de: planejamento estratégico, controladoria e
inteligência de marketing.

Deve-se ter muito cuidado ao disponibilizar canais externos, tais como

Extranets, para consultas ao data warehouse. Estes canais, se existirem, devem ser
monitorados constantemente e com altos requisitos de segurança.

Outra questão crucial para este ambiente, em relação à segurança, é garantir

que as informações contidas no data warehouse caiam em mãos erradas, os
concorrentes. É necessário uma política de segurança rígida para a equipe de
administração e operação do data warehouse.
 22

Por outro lado, de que adiantaria todo o esforço para construir o data
warehouse se as informações ficarem confinadas no repositório de dados. Alguns
analistas podem desenvolver uma visão analítica, crítica e consciente, com o acesso as
informações do data warehouse.

5. ADMINISTRAÇÃO

Na maior parte do tempo a administração do data warehouse estará voltada

para o banco de dados, verificando a integridade, a performance e o volume de dados.
Também se deve ter atenção especial para os cubos, das ferramentas OLAP. Os critérios
de agregação dos dados devem ser re-analisadas de acordo com a utilização das
informações pelos usuários, assim como os índices do banco de dados.

É possível utilizar a infra-estrutura do próprio data warehouse para criação de

Data Marts para monitoramento do ambiente, tais como: análise de espaço em disco,
tempo de carga de dados, análise de acessos dos usuários.

Nas organizações em que a informação para tomada de decisão for muito

crítica para o negócio, deve-se ter grande atenção aos extratores de dados. Os processos
de extração de dados devem ser monitorados continuamente, com implementação de
controles de falhas. Caso ocorra algum erro nesses processos o administrador do data
warehouse deve ser comunicado imediatamente para analisar o problema.

Em alguns casos, novas regras negócio podem ter sido implementadas nos
sistemas transacionais, sem a comunicação para aos administradores do data warehouse.
Nestes casos o administrador deverá recorrer aos analistas de suporte à decisão para
reavaliação das transformações dos extratores de dados.

Todas as falhas ocorridas no ambiente do data warehouse devem ser

comunicadas aos responsáveis para que nenhum informação errada seja utilizada para
tomada de decisão. É válido manter uma política de comunicação para avaliação
constante da equipe de administração do data warehouse.

É fundamental que o ambiente do data warehouse seja altamente padronizado,

com políticas rígidas de verificação. Como o ambiente do DW tende a ser complexo,
com muitas regras de negócio, objetos, ferramentas e conectores com sistemas
heterogêneos, a padronização do ambiente permitirá que a manutenção seja mais
eficiente.
 23

Em alguns casos manter os padrões de desenvolvimento podem ser mais

interessante que obter a melhor performance possível. Utilizar linguagens de pouco
conhecimento da equipe, ou de profissionais do mercado, pode não ser uma estratégia
segura para a administração do data warehouse.

O data warehouse deve possuir ao menos dois ambientes similares, um de

produção e outro de desenvolvimento. Para implementações críticas é aconselhável um
ambiente de validação dos desenvolvimentos e de performance. Os ambientes de
validação e desenvolvimento devem ter características próximas ao de produção pois
tratarão do mesmo volume de dados. Outra vantagem de possuir os ambientes similares
é criar uma contingência para o ambiente de produção.

A “janela” de extração de dados dos sistemas transacionais deve ter atenção

especial dos administradores. Eles devem observar a concorrência com os ambientes
transacionais e garantindo que as informações sejam disponibilizadas no prazo previsto
e com a periodicidade correta.

Outro aspecto importante da administração do data warehouse é a continuidade

do projeto, verificando se as regras de negócio estão em constante validação pelos
usuários e a documentação do projeto atualizada. A questão da revisão das regras de
negócio é tão importante que outra característica dos data warehouses é possuir uma
base de metadados.

Alguns papéis devem estar bem definidos para a equipe de manutenção do data
warehouse. Alguns deles são: arquiteto de soluções, administrador de dados, analista de
suporte a decisão, analista de negócio, administrador de banco de dados,
desenvolvedores, patrocinadores do projeto. Talvez o arquiteto de soluções seja a peça
fundamental para a construção e manutenção do data warehouse. Ele deverá ter a visão
do todo, desde integrar os diferentes sistemas transacionais ao data warehouse a
disponibilização dos dados para os analistas. O administrador de dados (AD) deve ser
responsável pelos metadados, pela integração das bases de dados e organização dos
dados. O AD deverá ter profundo conhecimento da modelagem, tanto lógica, física e
multidimensional. O analista de suporte a decisão deverá garantir continuamente que as
informações estão corretas, comunicando as mudanças das regras de negócio e a visão
do negócio. Seu alinhamento com a equipe de administração do data warehouse deve
ser o mais fiel possível. O administrador de banco de dados (DBA) poderá ser o mesmo
do ambiente transacional, contanto que tenha disponibilidade para solucionar os
 24

problemas emergenciais e entenda perfeitamente as características dos dois ambientes.

Os desenvolvedores serão responsáveis pela codificação dos extratores de dados,
exigindo deles conhecimento de diferentes tecnologias para integração com sistemas
transacionais, e pela programação dos relatórios e visões pré-definidas. Os
patrocinadores do projeto deverão definir as prioridades, acompanhar o projeto e
garantir a continuidade.

6. ESTUDO DE CASO

A INFOGLOBO COMUNICAÇÕES LTDA é uma empresa com abrangência

nacional, atuando no mercado de Jornalismo. Seus principais produtos são o Jornal O
Globo, Jornal Extra, Jornal Diário de São Paulo e Globo On-line.

Para se manter como líder de mercado a INFOGLOBO investiu, nos últimos

dois anos, 70% dos seus recursos em Tecnologia de Informática. Nos últimos 10 anos,
desde 95, foram investidos 15% em Tecnologia. A principal mudança na linha de
investimento é o direcionamento para o seu ambiente transacional, na implementação do
sistema de ERP da SAP. Antes os investimentos estavam voltados para a área industrial.
Porém o montante investido anualmente manteve-se no mesmo patamar.

Contudo, o sistema não atende a todas as necessidades, principalmente

relacionadas a informações para tomada de decisão. Porém, o ERP é fundamental para a
estratégia da empresa em expansão para novos mercados. Mais recentemente focados na
Internet e outras regiões.

Seu histórico de implementação de sistemas informação é desde 94, com os

sistemas de informação gerenciais (SIGs). Em 96 a empresa adquiriu as licenças para o
ESSBASE 3.2, atualmente fornecido pela Hyperion. O ESSBASE é uma ferramenta
OLAP, que atendia as necessidades da empresa até 99. Juntamente com esta ferramenta
foi desenvolvido um sistema de EIS. Com a implantação do ERP os executivos
acreditavam que o sistema de EIS seria totalmente desativado. De fato ele foi, porém a
área de tecnologia já estudava os conceitos de data warehouse. Observamos que, após a
implantação do ERP, vários controles em planilhas eletrônicas. Como conseqüência
informações conflitantes e com critérios diferentes eram apresentadas em reuniões
estratégicas.
 25

Em 99, apoiado pelas áreas financeira e comercial, inicio-se o projeto de

construção do data warehouse da empresa. Foram estudados os principais conceitos e
buscaram-se as ferramentas que teriam melhor custo benefício para a empresa. Alinhado
aos objetivos estratégicos, procurou-se criar um ambiente integrado ao ERP e aos
sistemas legados, bem como outros sistemas especialistas. Os principais benefícios
trazidos pela implementação do data warehouse foram: maior segurança na informação,
disseminação da informação, compartilhamento da informação com outras áreas,
confiabilidade na informação e agilidade para tomada de decisão.

O projeto começou pela reavaliação das informações existente, definindo assim

quais as necessidades imediatas. Este trabalho permitiu o dimensionamento da infra -
estrutura e escolha da ferramenta. A INFOGLOBO comparou as principais ferramentas
do mercado. Foram avaliadas: o BW, Business Object (BO), SQL Server, Cognos, IQ
Multiplex e Essbase 6.0. Foram avaliadas as seguintes características: integração com o
ambiente tecnológico da empresa, modelo de dados pré-definido, ferramenta própria de
ETL, ferramenta de modelagem multidimensional, estrutura de armazenamento físico
da base de dados OLAP, complexidade de administração, custo de consultoria, custo de
software do servidor, custo de licenças de usuários e custo de manutenção anual.

Considerando a infra-estrutura tecnológica e os custos de consultoria, software,

licença de usuário e manutenção anual, a empresa optou pelo SQL Server. Os
conhecimentos da equipe na ferramenta eram mínimos e o mercado ainda não
acreditava na ferramenta. Sendo considerado por muitos com um banco de dados não
confiável para grandes bases de dados.

O SQL Server atendia a todos os requisitos técnicos, por possuir as

características: repositório de dados (SGBD), integração com outros sistemas (ETL),
visão multidimensional, consolidação de dados, front-end integrado e escalabilidade.

Após a definição e configuração da infra-estrutura necessária, partiu-se para

um projeto piloto de implantação dos Data Marts da área financeira, que já era muito
bem atendida pelo EIS com ESSBASE. Com a implantação do Data Mart da área
financeira obtivemos ótimos resultados de performance, modificando completamente a
dinâmica dos processos da área. Os Data Marts existentes na plataforma do ESSBASE
foram migrados para o novo ambiente, considerando os conceitos de data warehouse.
 26

Com o sucesso da área financeira e confiança na arquitetura do data

warehouse, buscou-se novas áreas de interesse estratégico para a empresa. Neste ponto
ficou evidente a necessidade de uma metodologia que permitisse a expansão do data
warehouse de forma consistente e eficiente. Aliado às técnicas dos “papas” do data
warehouse, como INMON e KINBALL, foi definida a metodologia que traria a
eficiência para atender a outras áreas.

Seguindo a metodologia, com as fases descritas neste trabalho a empresa pode

expandir o data warehouse para as áreas de publicidade, venda avulsa do Diário de São
Paulo, jurídico e suprimentos. Recentemente foi feito um estudo para avaliação da infra-
estrutura adotada, com auxílio de consultoria da Microsoft, para garantir a
escalabilidade da arquitetura adotada.

Para identificar novas oportunidades de implementação de novos Data Marts

foi definida uma métrica que indique a prioridade para o desenvolvimento do projeto.
Nesta métrica são levados em consideração os seguintes parâmetros: importância da
área para o negócio, complexidade, disponibilidade da informação, conhecimento da
equipe e dos analistas de suporte a decisão.

Atualmente estão em andamento os projetos dos Data Marts de assinante,

venda avulsa dos produtos do Rio de Janeiro, distribuição e recursos humanos. Estes
projetos foram indicados para os executivos da empresa, considerando a métrica de
identificação de oportunidades.

Com a implantação dos primeiros Data Marts foi passível avaliar o impacto no
negócio, verificando a dinâmica das áreas atendidas. Na área de planejamento e controle
foi observado que o processo orçamentário ficou mais ágil e mais detalhado. Permitindo
que a área execute simulações a cada hora, quando só era possível fazer uma
consolidação por dia e totalmente dependente da área de tecnologia para executar o
processo. Na área de contabilidade societária permitiu-se que o prazo de fechamento
fosse reduzido de 6 para 2 dias. Com isto, os executivos puderam melhor avaliar os
prazos de pagamento dos fornecedores, melhorando o controle do fluxo de caixa da
empresa.

Antes da implantação do Data Mart da área de publicidade, ocorriam

problemas de concorrência no SAP, entre a captação de anúncios e jobs que eram
executados, durante o dia para, para análise histórica das vendas. Com a implantação
 27

deste Data Mart, a área passou a poder executar análises dos melhores clientes, de
diferentes formas: por produto, canal, ramo de atividade dos clientes, unidade de
negócio etc. No ERP só era possível executar uma única consulta de ranking de
anunciante por dia, que demorava 6 horas de processamento. Atualmente a execução
deste processo no DW dura 2 minutos. A captação de anúncios não aumentou por
conseqüência disto, porém foi possível reduzir os investimentos de hardware para o
ambiente do ERP. Atualmente a área de publicidade é dependente do DW para tomada
de decisão, sendo necessário um monitoramento de falhas e correção imediata caso
ocorra algum problema.

Também foi possível melhorar a análise de risco, com a visão macro dos
problemas relacionados com ações judiciais contra a empresa. Neste trabalho foi
necessário que antes da implementação do Data Mart fosse desenvolvido um sistema,
mesmo que simples, para o controle do processos, que antes eram feitos em planilhas
eletrônicas. Atualmente a área pensa em reavaliar o sistema transacional para melhorar
o controle das provisões.

Mesmo considerando a confiança nas ferramentas adotada a empresa estuda a

possibilidade de mudança da ferramenta para o BW, por considerá-la mais integrada as
ferramentas de ERP e CRM. Contudo, as informações, principal produto do data
warehouse, estão sendo organizadas para uma possível integração com outras
tecnologias.

7. CONCLUSÃO

Fundamentalmente as técnicas foram essenciais para a definição da

metodologia. A experiência da aplicação da metodologia também foi essencial para que
ela realmente se mostrasse eficiente na implementação e na expansão de projetos de
data warehouse.

Fica evidente também que os dados e, conseqüentemente, as informações

devem ser armazenados e organizados de forma independente das ferramentas
utilizadas. Sendo assim a metodologia se enquadra a este requisito básico do conceito de
data warehouse.

Uma das questões polêmicas do conceito de data warehouse é por se tratar de

um projeto utópico, pois criar uma fonte de dados única para tomada de decisão pode
 28

não se aplicar às condições da realidade. As instituições estão em constante mudança,

com novas implementações de sistemas transacionais, mudanças de plataforma,
métodos de trabalho diferentes e mudanças de estrutura organizacional. Porém os
benefícios da implementação do data warehouse são, comprovadamente pelo mercado,
inegáveis. Diz-se que um projeto de data warehouse não tem fim, pois ele está em
constante evolução para acompanhar as mudanças.

Contudo a metodologia ainda requer um aperfeiçoamento, com definições mais

rígidas das documentações e especificações.

8. LISTA DE ABREVIAÇÕES E SIGLAS

BI – Business Intelligence

BSC – Balanced Scorecard

BMP – Business Performance Management

CASE – Computer Aided Sotware Engineering

CLDS – Ciclo de vida baseado em dados

CPM – Corporate Performance Management

CRM – Customer Relationshio Management

DBA – Data Base Administrator

DDL – Data Definition Language

DML – Data Manipulation Language

DRL – Data Representation Language

DSS – Decision Support Systems

EIS – Executive Information System

EPM – Enterprise Performance Management

ERP – Enterprise Resource Planning

ETL – Extract Transform and Load

MER – Modelo Entidade-Relacionamento

OLAP – On-Line Analytical Processing

 29

OLTP – On-Line Transaction Processing

SDLC – Ciclo de vida do desenvolvimento de sistemas clássicos

SGBD – Sistema Gerenciador de Bando de Dados

SQL – Structured Query Language

9. REFERÊNCIAS BIBLIOGRÁFICAS

Carvalho, Luís Alfredo Vidal de – Datamining: a mineração de dados no marketing,

medicina, economia, engenharia, e administração.
Editora Érica – 2001

Inmon, William H. – Como Construir o Data Warehouse

Editora Campos – 1997

Jacobson, Reed – Microsoft SQL Server 2000 Analysis Services Step by Step
Microsoft Press - 2000

Kimball, Ralph – Data Warehouse Toolkit

Makron Books – 1998

Machado, Felipe Nery Rodrigues – Tecnologia e Projeto de Data Warehouse

Editora Érica - 2004

Madruga, Roberto – Guia de Implementação de Marketing de Relacionamento e CRM

Editora Atlas – 2004

Nolan, Sean e Huguelet, Tom – SQL Server 7.0 Data Warehousing Training
Microsoft Press – 1999

Pyle, Dorian – Data preparation for data mining

Academic Press – 1999

Seidman, Claude – Data Minnig with MS SQL Server 2000

Microsoft Press – 2001

Swift, Ronald – CRM, customer relationshio management: O Revolucionário Marketing

de Relacionamento com o Cliente
Editora Campus – 2001

Thomsen Erik – OLAP: Construindo sistemas de informações multidimensionais

Editora Campus – 2002

Ville, Barry de – Data Mining: integrated business for e-commerce and knowledge
management
Digital Press – 2001