Datawarehouse

Inicialmente analisemos algumas definições, elaboradas por acadêmicos

autores e profissionais especializados em Data Warehouse, que podem nos dar
uma primeira impressão sobre a tecnologia.
Segundo Inmon, Data Warehouse é uma coleção de dados orientados por
assuntos, integrados, variáveis com o tempo e não voláteis, para dar suporte ao
processo de tomada de decisão;
Data Warehouse é um processo em andamento que aglutina dados de
fontes heterogêneas, incluindo dados históricos e dados externos para atender à
necessidade de consultas estruturadas e ad-hoc, relatórios analíticos e de suporte
de decisão, conforme Harjinder;
Kimball define assim: é um conjunto de ferramentas e técnicas de projeto,
que quando aplicadas às necessidades específicas dos usuários e aos bancos de
dados específicos permitirá que planejem e construam um data warehouse.
Para entender o que é um DW, é importante fazer uma comparação com o
conceito tradicional de banco de dados. Conforme Batini, "Um banco de dados é
uma coleção de dados operacionais armazenados e utilizados pelo sistema de
aplicações de uma empresa específica". Os dados mantidos por uma empresa são
chamados de "operacionais" ou "primitivos". Batini refere-se aos dados do banco
de dados como "dados operacionais", distinguindo-se de dados de entrada, dados
de saída e outros tipos de dados.
Levando em consideração esta definição sobre dados operacionais, pode-
se dizer que um DW é, na verdade, uma coleção de dados derivados dos dados
operacionais para sistemas de suporte à decisão. Estes dados derivados são,
muitas vezes, referidos como dados "gerenciais", "informacionais" ou "analíticos".
Os bancos de dados transacionais, ou operacionais, armazenam as informações
das transações diárias da empresa, são utilizados por todos os funcionários para
registrar e executar operações pré-definidas, por isso seus dados podem sofrer
constantes mudanças. Por não ocorrer redundância nos dados e as informações
históricas não ficarem armazenadas por muito tempo, este tipo de BD não exige
grande capacidade de armazenamento.
Já um DW armazena dados analíticos, destinados às necessidades da
gerência no processo de tomada de decisões. Isto pode envolver consultas
complexas que necessitam acessar um grande número de registros, por isso é
importante a existência de muitos índices criados para acessar as informações da
maneira mais rápida possível. Um DW armazena informações históricas de muitos
anos e por isso deve ter uma grande capacidade de processamento e
armazenamento dos dados que se encontram de duas maneiras, detalhados e
resumidos.
Com base nestes conceitos podemos concluir que o DW é um conjunto de
técnicas e bancos de dados integrados, projetados para suportar as funções dos
Sistemas de Apoio à Decisão, onde cada unidade de dados está relacionada a um
determinado assunto, ou fato. Esses bancos de dados é que darão subsídio de
informações aos gerentes e diretores de empresas, para analisarem tendências
históricas dos seus clientes e com isso melhorarem os processos que aumentem a
satisfação e fidelidade dos mesmos.
No DW os dados podem ser retirados de múltiplos sistemas de computação
normalmente utilizados há vários anos e que continuam em operação, como
também podem ser de fontes externas da empresa. Data Warehouses são
construídos para que tais dados possam ser armazenados e acessados de forma
que não sejam limitados por tabelas e linhas estritamente relacionais. Os dados de
um DW podem ser compostos por um ou mais sistemas distintos e sempre
estarão separados de qualquer outro sistema transacional, ou seja, deve existir
um local físico onde os dados desses sistemas serão armazenados

Histórico do Data Warehouse

Para se entender o avanço que culminou na chegada do conceito de Data
Warehouse para a Tecnologia da Informação, é preciso lembrar como evoluíram 
os processos tecnológicos na área.
Em decorrência da revolução industrial e das grandes guerras mundiais, o
primeiro grande passo para os Data Warehouses foi dado. Surgiu então, em
1946, o ENIAC, um grande computador construído na Universidade da
Pensilvânia, movido a 18.000 válvulas e ocupando uma grande sala, ele
conseguia executar 200 operações por segundo.
Dez anos depois do ENIAC, foi também desenvolvido o transistor por um
grupo de pesquisadores americanos. O transistor era capaz de executar a mesma
tarefa das válvulas. A sua vantagem era o tamanho e a baixa potência dissipada.
Com o transistor, surgiram computadores muito menores e com capacidade
incrementada. Em 1964, máquinas como o IBM System 360 já despontavam,
como máquinas viáveis para uso empresarial.
No final dos anos 60, os computadores tornaram-se realmente
indispensáveis a qualquer grande organização. Rodavam somente um aplicativo
de cada vez, onde esses aplicativos eram executados sobre arquivos mestres. As
aplicações eram caracterizadas por relatórios e programas, geralmente em
COBOL. O uso de cartões perfurados era comum. Os arquivos mestres eram
armazenados em arquivos de fitas magnéticas, que eram adequadas para o
armazenamento de um grande volume de dados a baixo custo, mas apresentavam
o inconveniente de terem que ser acessadas sequencialmente.
Por volta de 1970, a época de uma nova tecnologia de armazenamento e
acesso a dados, havia chegado: a introdução do armazenamento em disco, ou
DASD (direct access storage device, ou dispositivo de armazenamento de acesso
direto), surgiu um novo tipo de software conhecido como SGBD ou sistema de
gerenciamento de banco de dados. Com o DASD e o SGBD surgiu a idéia de um
“banco de dados”,  também definido como uma única fonte de dados para todo o
processamento. 
O banco de dados promoveu uma visão de uma organização “baseada em
dados”, em que o computador poderia atuar como coordenador central para
atividades de toda a empresa. Nesta visão, o banco de dados tornou-se um
recurso corporativo básico.  Pela primeira vez as pessoas não estavam vendo os
computadores apenas como misteriosos dispositivos de previsão. Em vez disso, 
os computadores eram vistos como uma verdadeira vantagem competitiva. A
idéia dos sistemas de informação para os negócios começou a tomar forma.
Em outras palavras, os computadores tornaram-se importantes máquinas de
negócios, com os quais as empresas  alcançaram mais eficiência.
Nas décadas de 70 e 80, grandes aperfeiçoamentos  tecnológicos
resultaram em novos sistemas de informação que custavam bem menos e eram
bem mais poderosos. Com o surgimento dos bancos de dados relacionais a
informatização nas Empresas já acontecia a passos largos: as pessoas mais
influentes e poderosas tinham acesso aos microcomputadores e a sua facilidade
de uso aumentou muito.
 Com o processamento de transações online de alta performance, surgiram
os sistemas de reservas aéreas em nível mundial, sistemas bancários globais e
cartões de créditos internacionais.
A chegada de novas tecnologias, como os PC’s e as linguagens de 4 ª
geração,  permitiu-se que o usuário final assumisse  um papel mais ativo,
controlando diretamente os sistemas e os dados, fora do domínio do clássico
processamento de dados.
Com essa evolução, as empresas começaram a perceber que poderiam
analisar de forma otimizada seus dados, ou seja, descobriram que poderiam
incrementar seus recursos de Business Intelligence.  Essa descoberta muda o
enfoque que até então fora atribuído ao conjunto de informações (Sistemas).
Nasce um  novo conceito para a tecnologia da informação, no qual os sistemas
informatizados passaram a pertencer a dois grupos:
.  Sistemas que tratam o negócio: Dão suporte ao dia a dia do negócio da
empresa, garantem a operação da empresa, e são chamados de SISTEMAS
TRANSACIONAIS; e;
. Sistemas que analisam o negócio: Sistemas que ajudam a interpretar o que
ocorreu e a decidir sobre estratégias futuras para a empresa – compreendem os
SISTEMAS DE SUPORTE A DECISÃO.
Com a  chegada de novas ferramentas tecnológicas de análise de
informação, os gerentes começaram a exigir dos Sistemas Transacionais
respostas às suas solicitações. Como esses sistemas foram desenvolvidos para
garantir a operação da Empresa, não  estavam preparados para gerar e
armazenar as informações estratégicas necessárias a um Business
Em atendimento às solicitações dos gestores em relação à deficiência da
análise de informação nos sistemas legados, surgiu no mercado os chamados
Programas Extratores. Esses programas extraem informações dos Sistemas
Transacionais com o intuito de trabalhá-las em outros ambientes. Muitas vezes
essas extrações ocorriam em arquivos intermediários, onde as informações
sofriam novos tratamentos. Isso provocava uma falha na integridade das
informações acarretando, muitas vezes, uma falta de credibilidade dos dados, uma
queda da produtividade e a informação sendo publicada com valores diferentes.
Além disso, pelo fato de que os Sistemas Transacionais geravam um
grande volume de dados e pela diversidade dos sistemas implantados nas
empresas as pesquisas (relatórios) realizadas eram produzidas muito lentamente.
Nos tempos do Clipper e do Cobol fazer um relatório desse nível significava perder
muitas horas sobre o computador, pois se fazia necessário  que fossem extraídos
os dados de vários sistemas, muitas vezes esses não conversavam entre si.
Apesar dessas razões, é importante salientar que é possível a prática de
Business Intelligence com os sistemas operacionais da empresa, e com
outras fontes de dados, como planilhas eletrônicas e dados em papel, mas  esse
procedimento implica em grande possibilidade de equívocos, já que esses
dados são oriundos de várias fontes independentes, e não possuem entre si
relação de integridade.
Outro fator importante que prejudicava as decisões foi a falta de registro
dos fatos históricos nos Sistemas Transacionais, pois estes trabalhavam com uma
situação instantânea dos negócios.
Para resolver este problema, começou-se a estudar uma forma de se
armazenar a informação contida nos sistemas transacionais numa base de dados
central, para que houvesse integração total dos dados da empresa. Além disso,
era necessário manter o histórico das informações e fazer com que ela fosse
disposta dimensionalmente, ou seja, o analista de negócios poderia visualizar um
mesmo fato através de diversas dimensões diferentes. O nome dado a essa
modalidade de Sistema de Apoio à Decisão foi o Data Warehouse, ou em
português, Armazém de Dados.
Com o surgimento do DATA WAREHOUSE são necessários novos
métodos de estruturação de dados, tanto para armazenamento quanto  para a
recuperação de informações. Cabe ressaltar que as perspectivas e técnicas
necessárias para projetar o DATA WAREHOUSE são profundamente diferentes
dos SISTEMAS TRANSACIONAIS. Os usuários, o conteúdo dos dados, a
estrutura dos dados, o hardware e o software, a administração , o gerenciamento
dos sistemas,  o ritmo diário, as solicitações, as respostas e o volume de
informações são diferentes. 
Entender essa tecnologia com certeza ajudará os empresários a descobrir
novas tendências e caminhos para competir numa economia globalizada, onde a
concorrência é acirrada, trazendo melhores produtos ou serviços para o mercado
com maior  rapidez sem aumento dos custos.

Características do Data Warehouse

Segundo Inmon, um DW deve ser orientado por assuntos, integrado,

variável no tempo e não volátil. Essas são as principais características de um
DW descreveremos em maiores detalhes o que quer dizer cada uma delas logo
abaixo.

Orientação por Assunto

A orientação por assunto é uma característica marcante de um DW, pois
toda modelagem será voltada em torno dos principais assuntos da empresa.
Enquanto todos os sistemas transacionais estão voltados para processos e
aplicações específicas, os DWs objetivam assuntos. Mas  o que são assuntos?
Assuntos são o conjunto de informações relativas à determinada área  estratégica
de uma empresa.
 Numa revenda de carros, quais seriam as áreas e os assuntos ? Poderiam
ser as áreas de marketing, financeira e etc. Dentro dessas áreas poderiam surgir
vários assuntos. Por exemplo, vendas, serviços e etc. Os assuntos darão origem
as tabelas que chamaremos de fato, as quais descreveremos em maiores
detalhes mais abaixo.

Integração
Esta característica talvez seja a mais importante do DW. É através dela que
iremos padronizar uma representação única para os dados de todos os sistemas
que formarão a base de dados do DW. Por isso, grande parte do trabalho na
construção de um DW está na análise dos sistemas transacionais e dos dados
que eles contêm. Esses dados geralmente encontram-se armazenados em vários 
padrões de codificação, isso se deve aos inúmeros sistemas existentes nas
empresas, e que eles tenham sido codificados por diferentes analistas.  Isso quer
dizer que os mesmos dados podem estar em formatos diferentes. Vejamos agora
um exemplo clássico referentes aos gêneros masculino e feminino.
Num sistema OLTP, o analista convencionou que o sexo seria 1 para
masculino e 0 para feminino, já em outro sistema outro analista usou para guardar
a mesma informação a seguinte definição, M para masculino e F para feminino, e
por fim outro programador achou melhor colocar H para masculino e M para
feminino. Como podemos ver, são as mesmas informações, mas estão em
formatos diferentes, e isso num DW jamais poderá acontecer. Portanto é por isso
que deverá existir uma integração de dados, convencionando-se uma maneira
uniforme de guardarmos os mesmos, e isso gera bastante trabalho, se forem
poucos sistemas transacionais não causará grandes problemas, mas se tiverem
muitos então as coisas ficam um pouco complicadas e bem mais trabalhosas.

Figura 1

Variação no Tempo
Segundo W.H.Inmon, os Data Warehouses são variáveis em relação ao
tempo, isso nada mais é do que manter o histórico dos dados durante um período
de tempo muito superior ao dos sistemas transacionais, vejamos abaixo mais
algumas características.
Num DW é normal mantermos um horizonte de tempo bem superior ao dos
sistemas transacionais, enquanto no OLTP mantemos um histórico curto dos
dados, no DW guardamos esses dados num período maior. Isso é bastante lógico
porque num sistema transacional a finalidade é de fornecer as informações no
momento exato, já no Data Warehouse, o principal objetivo é analisar o
comportamento das mesmas durante um período de tempo maior.
Fundamentados nessa variação, os gerentes tomam as decisões em cima de fatos
e não de intuições.
 Seguindo a mesma linha de raciocínio é válido dizer que os dados nos
sistemas transacionais estão sendo atualizados constantemente, cuja exatidão é
válida somente para o momento de acesso. Os dados existentes num DW são
como fotografias que refletem os mesmos num determinado momento do tempo.
Essas fotografias são chamadas de snapshots.
A dimensão tempo, sempre estará presente em qualquer fato de um DW,
isso ocorre porque, como falamos anteriormente, sempre os dados refletirão num
determinado momento de tempo, e obrigatoriamente deverá conter uma chave de
tempo para expressar a data em que os dados foram extraídos. Portanto podemos
dizer que os dados armazenados corretamente no DW não serão mais atualizados
tendo-se assim uma imagem fiel da época em que foram gerados.
Assim como os dados, é importante frisar que os metadados, também
possuem elementos temporais, porque mantêm um histórico das mudanças nas
regras de negócio da empresa. Os metadados são responsáveis pelas
informações referentes ao caminho do dado dentro do DW.  Daremos uma
definição melhor sobre metadados mais adiante.

Não Volatilidade
No DW existem somente duas operações, a carga inicial e as consultas dos
front-ends aos dados. Isso pode ser afirmado porque a maneira como os dados
são carregados e tratados é completamente diferente dos sistemas transacionais.
Enquanto nesses sistemas temos vários controles e updates de registros, no DW
temos somente inserts e selects de dados. Por exemplo, num sistema de
contabilidade podemos fazer alterações nos registros. Já no DW, o que acontece
é somente ler os dados na origem e gravá-los no destino, ou seja, no banco
modelado multidimensional.
Deve-se considerar que os dados sempre passam por filtros antes de
serem inseridos no DW. Com isso muitos deles jamais saem do ambiente
transacional, e outros são tão resumidos que não se encontram fora do DW. "Em
outras palavras, a maior parte dos dados é física e radicalmente alterada quando
passam a fazer parte do DW. Do ponto de vista de integração, não são mais os
mesmos dados do ambiente operacional. À luz destes fatores, a redundância de
dados entre os dois ambientes raramente ocorre, resultando em menos de 1
por cento de duplicações", essa definição é dada por Inmon.

Localização
Os dados podem estar fisicamente armazenados de três formas:
Num único local centralizando o banco de dados em um DW integrado,
procurando maximizar o poder de processamento e agilizando a busca dos dados.
Esse tipo de armazenagem é bastante utilizada, porém há o inconveniente do
investimento em hardware para comportar a base de dados muito volumosa, e o
poderio de processamento elevado para atender satisfatoriamente as consultas
simultâneas de muitos usuários.
Os distribuídos são Data Marts, armazenados por áreas de interesse. Por
exemplo, os dados  da gerência financeira num servidor, dados de marketing
noutro e dados da contabilidade num terceiro lugar. Essa pode ser uma saída
interessante para quem precisa de bastante performance, pois isso não
sobrecarrega um único servidor, e as consultas serão sempre atendidas em tempo
satisfatório.
Armazenados por níveis de detalhes, em que as unidades de dados são
mantidas no DW. Pode-se armazenar dados altamente resumidos num servidor,
dados resumidos noutro nível de detalhe intermediário no segundo servidor e os
dados mais detalhados (atômicos), num terceiro servidor. Os servidores da
primeira camada podem ser otimizados para suportar um grande número de
acessos e um baixo volume de dados, enquanto alguns servidores nas outras
camadas podem ser adequados para processar grandes volumes de dados,   mas
baixo número de acesso.
Para mudar de nível é necessário que ocorra um dos seguintes eventos: os
dados são sintetizados, arquivados ou eliminados.
O processo de sintetização interage no nível mais alto de detalhamento
(dados detalhados atuais) para os níveis seguintes (levemente e altamente
resumidos). Quando termina determinado período de tempo (semana, mês,
trimestre, ano), os dados são indexados por estes períodos e armazenados nos
seus respectivos níveis de detalhamento. Para facilitar o acesso aos dados, estes
devem estar sintetizados e indexados de várias maneiras.  Portanto, ao mesmo
tempo que ocorre o agrupamento por datas, também pode ocorrer a sintetização
por grupos e subgrupos.
Cada nível possui um horizonte de tempo definido para a permanência dos
dados. Então o fato de os dados serem transportados para níveis mais elevados
não implica na exclusão do nível anterior. Um processo denominado processo de
envelhecimento ocorre quando este limite é ultrapassado, e portanto os dados
podem ser transferidos para meios de armazenamentos alternativos ou passar de
dados detalhados atuais para dados detalhados antigos.

Credibilidade dos Dados

A credibilidade dos dados é o muito importante para o sucesso de qualquer
projeto. Discrepâncias simples de todo tipo podem causar sérios problemas
quando se quer extrair dados para suportar decisões estratégicas para o negócio
das empresas. Dados não dignos de confiança podem resultar em relatório inúteis,
que não têm importância alguma, assim como uma lista de pacientes do sexo
masculino e grávidos, por exemplo. "Se você tem dados de má qualidade e os
disponibiliza em um DW, o seu resultado final será um suporte à decisão de baixo
nível com altos riscos para o seu negócio", afirma Robert Craig,  analista do
Hurwitz Group.
Coisas aparentemente simples, como um CEP errado, podem não ter
nenhum impacto em uma transação de compra e venda, mas podem influir nas
informações referentes a cobertura geográfica, por exemplo. "Não é apenas a
escolha da ferramenta certa que influi na qualidade dos dados", afirma Richard
Rist, vice-presidente Data Warehousing Institute. Segundo ele, conjuntos de
coleções de dados, processos de entrada, metadados e informações sobre a
origem dos dados, são importantíssimos. Outras questões como a manutenção e
atualização dos dados e as diferenças entre dados para bancos transacionais e
para uso em Data Warehousing também são cruciais para o sucesso dos projetos.
Além das camadas do DW propriamente dito, tem-se a camada dos dados
operacionais, de onde os dados mais detalhados são coletados. Antes de fazer
parte do DW estes dados passam por diversos processos de transformação para
fins de integração, consistência e acurácia.
A Tabela 2 descreve um conjunto de características, normalmente utilizadas
para verificar a qualidade dos dados, e indica algumas das maneiras de medir o
nível de qualidade dos mesmos do DW. Nem todas as características da tabela
precisam necessariamente ser averiguadas, deve-se escolher as que representam
maior fator de risco para o ambiente proposto e trabalhar em cima destas
características.

Tabela 2

Granularidade

Granularidade nada mais é do que o nível de detalhe ou de resumo dos

dados existentes num DW. Quanto maior for o nível de detalhes, menor será o
nível de granularidade. O nível de granularidade afeta diretamente o volume de
dados armazenados no DW, e ao mesmo tempo o tipo de consulta que pode ser
respondida.

Quando se tem um nível de granularidade muito alto o espaço em disco e o

número de índices necessários, tornam-se bem menores, porém há uma
correspondente diminuição da possibilidade de utilização dos dados para atender
a consultas detalhadas.

A Figura 3 exemplifica o conceito acima, utilizando os dados históricos das vendas

de um produto. O nível de granularidade muito baixo pode ser caracterizado pelo
armazenamento de cada uma das vendas ocorridas para este produto, e um nível
muito alto de granularidade seria o armazenamento dos somatórios das vendas
ocorridas por mês.

Figura 3
Com o nível de granularidade muito baixo, é possível responder a praticamente
qualquer consulta, mas uma grande quantidade de recursos computacionais é
necessária para responder perguntas muito específicas. No entanto, no ambiente
de DW, dificilmente um evento isolado é examinado, é mais provável que ocorra a
utilização da visão de conjunto dos dados.

Os dados levemente resumidos compreendem um nível intermediário na estrutura

do DW, são derivados do detalhe de baixo nível encontrado nos dados detalhados
atuais. Este nível do DW é quase sempre armazenado em disco. Na passagem
para este nível os dados sofrem modificações. Por exemplo, se as informações
nos dados detalhados atuais são armazenadas por dia, nos dados levemente
resumidos estas informações podem estar armazenadas por semanas. Neste nível
o horizonte de tempo de armazenamento normalmente fica em cinco anos e após
este tempo os dados sofrem um processo de envelhecimento e podem passar
para um meio de armazenamento alternativo.

Os dados altamente resumidos são compactos e devem ser de fácil acesso, pois
fornecem informações estatísticas valiosas para os Sistemas de Informações
Executivas (EIS), enquanto que nos níveis anteriores ficam as informações
destinadas aos Sistemas de Apoio a Decisão (SAD), que trabalham com dados
mais analíticos procurando analisar as informações de forma mais ampla.

O balanceamento do nível de granularidade é um dos aspectos mais críticos no

planejamento de um DW, pois na maior parte do tempo há uma grande demanda
por eficiência no armazenamento e no acesso aos dados, bem como pela
possibilidade de analisar dados em maior nível de detalhes. Quando uma
organização possui grandes quantidades de dados no DW, faz sentido pensar em
dois ou mais níveis de granularidade, na parte detalhada dos dados. Na realidade,
a necessidade de existência de mais de um nível de granularidade é tão grande,
que a opção do projeto que consiste em duplos níveis de granularidade deveria
ser o padrão para quase todas as empresas.

O chamado nível duplo de granularidade, ilustrado na Tabela 3, se enquadra nos

requisitos da maioria das empresas. Na primeira camada de dados ficam os dados
que fluem do armazenamento operacional e são resumidos na forma de campos
apropriados para a utilização de analistas e gerentes. Na segunda camada, ou
nível de dados históricos, ficam todos os detalhes vindos do ambiente
operacional. Como há uma verdadeira montanha de dados neste nível, faz sentido
armazenar os dados em um meio alternativo como fitas magnéticas.

Com a criação de dois níveis de granularidade no nível detalhado do DW, é

possível atender a todos os tipos de consultas, pois a maior parte do
processamento analítico dirige-se aos dados levemente resumidos que são
compactos e de fácil acesso.  E para ocasiões em que um maior nível de detalhe
deve ser investigado existe o nível de dados históricos. O acesso aos dados do
nível histórico de granularidade é caro, incômodo e complexo, mas caso haja
necessidade de alcançar esse nível de detalhe, lá estará ele.
DIVIDIR PARA CONQUISTAR OU CONQUISTAR PARA DIVIDIR?

Tivemos a oportunidade de participar de um encontro, realizado em Junho

de 2003 e patrocinado pela PHD Brasil, com o Sr. Bill Inmon, um dos precursores
da tecnologia de Data Warehouse (DW). O que pudemos notar com bastante
clareza nas conversas de bastidores foi que as diferentes abordagens de
construção de um Data Warehouse defendidas pelo próprio Inmon, frente à
abordagem proposta por Ralph Kimball, têm causado dúvidas na comunidade de
TI e na comunidade de negócios sobre a melhor forma de se construir um DW.
Basicamente, os dois autores divergem sobre o melhor "approach". Kimball
sugere que o DW deve ser "divido para depois ser conquistado", construindo-se
Data Marts para posteriormente chegar-se ao Data Warehouse. Inmon sugere que
o DW deva ser projetado de forma una, modelando-se toda a empresa e
chegando-se a um único modelo corporativo, partindo-se posteriormente para os
Data Marts.
Entretanto, para chegarmos a uma conclusão, primeiramente devemos
analisar com mais detalhes o que cada um dos dois autores diz sobre a
abordagem de construção.

- Ralph Kimball

Em seu artigo "Divide and Conquer" (www.rkimball.com), Kimball começa

discorrendo sobre a necessidade de se ter conceitos corporativos que atendam às
necessidades da empresa como um todo. Entretanto, para que isto seja possível,
é necessário o comprometimento da mais alta cúpula da corporação no sentido de
conduzir com mãos de ferro o esforço de integração de conceitos, bem como é
necessário que um dos executivos usuários de informações gerenciais, como um
diretor ou vice-presidente, esteja disponível para ser o patrocinador e condutor do
levantamento de conceitos corporativos.

A criação e manutenção dos conceitos corporativos não são tarefas da área de TI,
e sim da alta cúpula da corporação e dos usuários de informações.

No que tange aos Data Marts, Kimball diz que eles não devem ser
departamentais, ou seja, os Data Marts devem ser orientados aos dados, ou
fontes de dados. Exemplificando, se um banco possui uma fonte de dados de
contas correntes e poupança, então um Data Mart de Contas deve ser criado. Este
não será um Data Mart proprietário da área financeira e nem da área de
Marketing, será sim um Data Mart que terá como público todos os usuários de
todos os departamentos que lidam com aquele assunto. Isso seria possível uma
vez que os conceitos corporativos abordados acima já estariam disponíveis e
implantados, dando à toda empresa uma visão única sobre sue negócio.

Transcendendo os conceitos corporativos, que até então tem um cunho de

negócios, para uma visão tecnológica, Kimball propõe a criação de tabelas Fato e
Dimensão em conformidade, ou seja, tabelas que serão utilizadas por diferentes
usuários e Data Marts.

As equipes dos diferentes Data Marts deverão se reunir em um conselho para

delinear as dimensões em conformidade. Dimensões em conformidade típicas são
as de Tempo, Produto, Cliente e Empregado.

Entretanto, o esforço para criação dessas tabelas é muito árduo. De tempos em

tempos o conselho responsável pela criação e manutenção das tabelas gasta
muito tempo tentando alinhar conceitos de diferentes e, na maioria das vezes, não
chega a um consenso. É por isso que a alta administração da empresa, na pessoa
do patrocinador do projeto, deve estar comprometida e envolvida nos esforços de
integração de dados e conceitos.

Da mesma forma, as medidas, ou fatos, que podem ter conceitos alinhados em

um âmbito corporativo, como as vendas em empresas de varejo, também devem
ser construídas em conformidade. Para isso os diferentes tipos de sumarização e
agregação devem ser detectados para atender às diversas necessidades. As
Fatos que não podem ser dispostas em conformidade devem ser nomeadas de
maneira diferente, deixando claro que os conceitos embutidos nela não são
corporativos, evitando confusão futura.

Ao final da construção dos Data Marts orientados a assuntos, teríamos uma série
de pontos de conexão entre eles, que seriam as tabelas Fato e Dimensão em
conformidade. Desta forma, informações entre os diferentes Data Marts poderiam
ser geradas de maneira íntegra e segura. A este conceito Kimball dá o nome de
Data Warehouse Bus Architecture.

Segundo o autor, o Data Warehouse Bus Architecture seria como um livro de

receitas para a construção de Data Warehouses nas grandes empresas. O
problema (DW) seria divido em partes e resolvido incrementalmente, de maneira
íntegra e escalável.

- Bill Inmon

Em diversos "White Papers" de seu site (www.billinmon.com), especificamente em

"Data Marts and the Data Warehouse : Information Architeture for the Millenium",
Inmon discorre sobre a sua CIF (Corporate Information Factory) como infra-
estrutura ideal para ambientar os dados da empresa, desde de seus sistemas
transacionais até a disponibilização de informações gerenciais ao usuário final.

O ponto de partida da CIF são os sistemas transacionais, ou legados, onde as

transações do dia-a-dia da corporação são registradas em seu máximo detalhe.
Os sistemas legados servem de fonte de dados para o grande Data Warehouse e
para o ODS (Operational Data Store).
A construção de um ODS é facultativa, entretanto, ajuda em muito a diminuir os
esforços de construção de um DW. Todo o esforço de integração entre os
sistemas transacionais da empresa seriam depositados no ODS e a carga do
Warehouse seria simplificada de maneira incomensurável.

No Data Warehouse estaria modelado de maneira atômico e levemente

denormalizado todo o negócio da empresa. Segundo Inmon, o DW deve ser
modelado desta forma por que servirá de fonte de dados para diversos tipos de
aplicações como Data Marts e Data Mining. A manipulação da informação fica
muito facilitada com os dados estruturados desta maneira.

Emanando do Data Warehouse, seriam criados os Data Marts. Uma vez que os
dados da empresa já estão integrados no Data Warehouse, os Data Marts que
atenderiam os diversos departamentos da empresa gerariam dados íntegros e
corporativos.

E por que não construir os Data Marts antes do DW ? Segundo Inmon, a

construção de Data Marts atende à requisitos proprietários, departamentais. Para
cada Data Mart, portanto, seriam delineadas regras específicas de negócios e
procedimentos específicos de Extração, Transformação e Carga (ETL) dos dados
oriundos dos sistemas transacionais. A visão corporativa da empresa seria
deixada a segundo plano e as necessidades imediatas dos departamentos
prevaleceria. Comercialmente esta abordagem tem o nome de "Bottom-Up".

Este procedimento, segundo o autor, geraria uma série de problemas para a

empresa. Dentre eles, podemos citar o trabalho redundado de ETL que os
diversos Data Marts terão de implementar, a redundância de dados em diversos
sistemas, o consumo exagerado de recursos de produção e, o mais grave dos
problemas, a geração de um caos informacional, onde os dados presentes nos
diferentes Data Marts não poderiam ser integrados para geração de informações
corporativas.

As figuras abaixo ilustram a diferença entre as duas abordagens descritas :

"Bottom-Up", partindo-se dos Data Marts para se chegar ao DW e "Top-Down",
partindo-se do DW para se chegar aos Data Marts.

Abordagem "Bottom-Up"

Abordagem "Top-down", defendida por Inmon.

Por defender uma abordagem "Top-Down", Inom destaca a necessidade de um

efetivo envolvimento do Usuário de Negócios e da alta cúpula organizacional na
construção do DW. Este envolvimento é muito importante na concepção de
conceitos corporativos, uma vez que no DW deverão estar presentes dados
integrados dos diversos legados, e no levantamento dos reais requisitos
informacionais.
O Data Warehouse deve corresponder aos anseios dos usuários e não deve ser
fruto da vaidade da área de Tecnologia. Segundo o autor, apesar deste ponto
parecer óbvio, é muito comum encontrar grandes "Elefantes Brancos" que não
atendem às reais necessidades de negócios da empresa mas que elevam o brio
dos técnicos.

- E agora, que abordagem adotar ?

Descrevemos acima as abordagens defendidas pelos dois maiores experts em

Data Warehouse no mundo. A diferença entre as duas é sensível e, por isso,
somos levados a momentos de reflexão e até confusão em relação ao melhor
"approach" em nossos projetos.

Primeiramente é importante detectarmos o que há de comum entre as duas teses.

O ponto em comum mais importante é o seguinte : Uma empresa sem auto-
conhecimento, sem uma visão corporativa de seu negócio, nunca terá um Data
Warehouse.

Ralph Kimbal é claro quando diz que os Data Marts devem ser orientados a
assuntos e não departamentais. Portanto, todos os usuários da corporação que
estão ligados a um determinado assunto, não importando sua lotação, devem ser
envolvidos na construção do Data Mart. Isto implica em um trabalho de integração
de conceitos entre diversos departamentos, até que chegarmos a uma visão
corporativa e única da empresa.

Bill Inmon tece uma analogia muito interessante em relação às soluções

departamentais e não integradas. Segundo ele, o usuário se comporta como um
viajante perdido em uma grande floresta. Se encontramos o usuário perdido e lhe
oferecermos um doce, o agrado será muito bem acolhido (O doce será
devorado !). Continuaremos a oferecer doces até que, em um determinado
momento, o usuário clamará por algo mais substancial, algo que não poderemos
oferecer.

Entretanto, sabemos que empresas com processos e dados íntegros não são
encontradas facilmente e que, na maioria de nossos clientes, não há um mínimo
de integridade.

Por esse motivo, o correto seria convencer a alta administração das empresas
sobre a importância de se ter uma visão corporativa de seus processos e dados.
Se pensarmos com calma, não deveríamos nos esforçar para convencê-los disso,
afinal a maior interessada e beneficiada seria a própria empresa e o Data
Warehouse seria apenas um dos frutos da integração.

Entretanto devemos reconhecer nosso insucesso, ou até incompetência, em achar

a pessoa certa na empresa para patrocinar um projeto desta magnitude e para
mostrar a importância de integrarmos conceitos e dados.
Partindo-se de uma empresa com conceitos integrados e disposta, ou imposta por
sua direção, a integrar dados, é indiferente adotar a abordagem "Bottom-Up" ou a
"Top-Down".

Não podemos ser tão puristas como Inmon e Kimball, mesmo por que ao
escolhermos uma das duas abordagens, estaremos indo contra o que diz o autor
que foi preterido. Um aspecto tranqüilizante é que certamente as duas abordagens
geraram muitos casos de sucesso. Das duas formas chegaremos ao mesmo lugar,
o Data Warehouse. É importante salientarmos que é uma opinião pessoal nossa e
que o intuito deste artigo é que cada profissional chegue a sua própria conclusão.

Mas e se nossos esforços de se convencer a alta administração da empresa

falharem ? Soluções isoladas tem seu valor ? Não adianta ficarmos esperando o
Nirvana. Em muitos casos, nossa única alternativa será o desenvolvimento de
Data Marts isolados, ou independentes. Esse tipo de solução agirá como o doce
retratado por Inmon na analogia descrita acima. O usuário departamental poderá
encontrar os resultados esperados, entretanto, a alta administração da empresa
estará arranjando um grande problema para o futuro, quando diversos Data Marts
independentes estiverem espalhados pela empresa.

A velha história do mesmo relatório, pedido à diversos departamentos, e trazendo

resultados diferentes voltará a acontecer. Caberá a nós, meros consultores e
técnicos, apenas avisar que o caos de informações será instalado, uma vez que
não temos poder e nem orçamento para fazer as coisas como deveriam ser feitas.

Business Intelligence

O grande desafio de todo indivíduo que gerencia qualquer processo é a análise

dos fatos relacionados a seu dever. Ela deve ser feita de modo que, com as
ferramentas e dados disponíveis, o gerente possa detectar tendências e tomar
decisões eficientes e no tempo correto. Com essa necessidade surgiu então o
conceito de Business Intelligence.

Há milhares de anos atrás, Fenícios, Persas, Egípcios e outros Orientais já faziam,

a seu modo, Business Intelligence, ou seja, cruzavam informações provenientes
da natureza, tais como comportamento das marés, períodos de seca e de chuvas,
posição dos astros, para tomar decisões que permitissem a melhoria de vida de
suas comunidades.

A história do Business Intelligence que conhecemos hoje, começa na década de

70, quando alguns produtos de BI forma disponibilizados para os analistas de
negócio. O grande problema era que esses produtos exigiam intensa e exaustiva
programação, não disponibilizavam informação em tempo hábil nem de forma
flexível, e além de tudo tinham alto custo de implantação.
Com o surgimento dos bancos de dados relacionais, dos PC’s e das interfaces
gráficas como o Windows, aliados ao aumento da complexidade dos negócios,
começaram a surgir os primeiros produtos realmente direcionados aos analistas
de negócios, qu possibilitavam rapidez e uma maior flexibilidade de análise.

Os sistemas de BI têm como características:

- Extrair e integrar dados de múltiplas fontes

- Fazer uso da experiência
- Analisar dados contextualizados
- Trabalhar com hipóteses
- Procurar relações de causa e efeito
- Transformar os registros obtidos em informação útil para o conhecimento
empresarial

São ferramentas de Business Intelligence:

- Data Warehouses
- Planilhas Eletrônicas
- Geradores de Consultas e Relatórios
- EIS
- Data Marts
- Data Mining
- Ferramentas OLAP

Business Intelligence - Produzindo Resultados

Não é necessário envidar esforços para convencer alguém da importância do

Business Intelligence (BI) para as organizações que almejam alta competitividade
no mercado. O que é importante colocar em discussão é a forma como muitas
destas organizações vem encarando e implementando seus sistemas de Business
Intelligence. É preciso cuidar do equilíbrio entre os investimentos empregados
(normalmente altos) e os resultados obtidos. Além disso, a estratégia de
implementação deve estar alinhada com os objetivos organizacionais.

Pode-se entender uma visão geral de uma arquitetura BI, através da figura abaixo:
Conceituando (de forma extremamente sintética) seus componentes, temos:

- Operacional: Plataforma de dados relativos ao dia-a-dia da organização,

vitais para sua operação no mercado. Segundo Inmon, "é chamado assim
porque está relacionado com as operações de negócios diárias da
corporação".

- Staging Area (SA): Também chamada por Inmon como "camada de

integração e transformação", a SA é uma área de tratamento, padronização
e transformação das informações operacionais para carga na arquitetura BI;

- Operational Data Store (ODS): Também de acordo com Inmon, ODS é uma
base de dados integrada, volátil, de valores correntes, e que contém
somente dados detalhados. Também pode ser entendido como uma visão
integrada do mundo operacional. Normalmente sua construção adota bases
de dados relacionais;

- Data Warehouse (DW): Para Kimball, o DW é a fonte de dados para

consultas na organização, ou nada menos que a união de todos os Data
Marts já constituídos. Pode ser visto também como uma grande base de
dados que apresenta diversos níveis sintéticos dos dados operacionais,
cujo objetivo maior é o de fornecer informação estratégica integrada,
segundo uma visão holística da organização. Normalmente, é construída
sob a forma de fatos (mensuráveis) e as dimensões sob as quais podem
ser analisados (ex: as vendas da companhia na região nordeste foram de
R$-1.000.000,00 no mês de maio/2003; onde o fato é valor das vendas e as
dimensões são a região e o mês);

- Data Mart (DM): Kimball, um expoente defensor de construções de DM,

afirma que os data marts são subconjuntos de um DW completo. Podemos
assim entender DM como pequenos DW, de visão departamental ou de
área interesse ou área assunto bem definida, com o propósito de fornecer
visão estratégica dos dados setorizados;
- Near Line Store (NLS): Inmon conceitua NLS como sendo uma
armazenagem complementar ao DW, a fim de manter dados raramente
acessados;

- Exploration Warehouse (EW): Inmon se refere ao EW como sendo um

ambiente ideal para análises pesadas e inexploradas ainda por serem
efetuadas, isolado do warehouse corporativo;

- Metadados: David Marco define, de forma simplista, como sendo dados

sobre dados. Detalhando mais o conceito, Marco afirma que os metadados
podem ser encarados como cartões de catálogo (similares aos de
bibliotecas) em um DW, mantendo relevante informação para se efetuar
análises sobre o ambiente do DW. Resumidamente, pode-se definir
metadados como sendo os dados que definem os elementos de dados da
arquitetura BI. Na verdade, metadados deveriam ser adotados para
qualquer sistema de bases de dados a serem desenvolvidos, mas,
infelizmente, estão muito ligados à construção de sistemas BI;

- ETL: Sigla derivada de Extract, Transformation and Load, é o processo de

captura das fontes de dados a serem utilizadas em um ambiente BI, sua
transformação, padronização e posterior carga no DW (ou DM ou ODS).
Pode-se claramente perceber um ambiente de ETL na visão geral do
ambiente BI apresentada acima;

- OLAP: Advindo da expressãoOn-Line Analytic Processing, Kimball define

como a atividade de consulta e apresentação de dados textuais e
numéricos em um DW;

- Drill: Operação de detalhamento (drill-down) ou agregação (drill-up, também

conhecido como roll-up) em um processo OLAP.

- Para que esta visão geral BI seja construída, muito se discute sobre a linha
metodológica a ser adotada na construção: Bill Inmon ? Ralph Kimball ?
Uma linha mista ? Outros autores ? Enfim, que tipo de arquitetura de
"fábrica de informação" assumir ? Outra discussão que se faz é sobre o
modelo de dados físico a ser adotado: Star-schema ? Snow-flake ? M-E/R ?
Outro qualquer ? Misto ?

- A tecnologia também produz as mais variadas discussões e defesas

partidárias, apaixonadas e envaidecidas sobre os mais variados temas:

- Qual o sistema gerenciador de banco de dados mais apropriado ?

ORACLE, DB2, SYBASE IQ, TERADATA ? Se for nova tecnologia no
ambiente, como introduzi-la, como criar cultura, qual a curva de
aprendizado?
 - Quanto à ferramenta OLAP, qual a que permite maior flexibilidade,
facilidade de uso, recursos gráficos, operações OLAP (como drill), interação
com o gerenciador de banco de dados ?

- E a ferramenta ETL ? É melhor desenvolver todo o ETL com recursos

próprios ("hands-on") ? E a manutenção do desenvolvimento ? Com
ferramenta ETL, qual o ganho de produtividade ? Qual o resultado sobre
investimentos (ROI) ?

- Qual a máquina, sistema operacional e plataforma (Mainframe ou UNIX ou

NT ou outro) ?

- E Metadados ? Como implementar ? Como manter ? Adquirir no mercado

(e existem poucas alternativas) ou construir internamente à organização
("in-house") ? Como integrar à Administração de Dados corrente na
empresa ?

Toda esta discussão tecnológica e sobre a forma de se construir o ambiente BI,

além de outros fatores não citados neste artigo, é verdadeiramente importante na
concepção desta plataforma em qualquer organização. Mas não deve ser
encarado como o objetivo final de qualquer construção BI. Entretanto, muitas
vezes, o foco dos altos investimentos não são colocados de forma prioritária como
realmente deveria ser, proporcionando, por exemplo, o seguinte questionamento:
Como obter rapidamente resultados que conduzam a Organização à liderança do
mercado através de um maior conhecimento sobre seus CLIENTES, suas
TRANSAÇÕES (ou outras formas de RELACIONAMENTO) e o consumo dos
PRODUTOS / SERVIÇOS oferecidos pela ORGANIZAÇÃO (dentre muitas outras
análises que podem ser efetuadas dependendo da solução BI implementada) ?

Grande parte das iniciativas de implementação de BI são frustradas por inúmeros

fatores, dentre os quais, discussões apaixonadas intermináveis (algumas delas já
citadas neste artigo) que somente atrasam o início, a condução e o término do
projeto, retardando a entrega de resultados, esperados pelo investidor, que
justifiquem as elevadas somas de recursos empregados no projeto. Sendo assim,
a fim de atingir a expectativa geral do alto "staff" da organização (de forma
tempestiva), devemos elevar a prioridade da entrega de resultados previstos (e
esperados com elevada ansiedade) com tais investimentos.

Muitas vezes, a adoção de uma linha ortodoxa seguindo Inmon levará a

organização a um tempo de análise, projeto e construção extremamente elevado,
em função de que Inmon prevê que toda a arquitetura de BI seja construída, a fim
de que a visão de toda a informação da empresa esteja integrada em uma visão
holística, com armazenamento histórico das transações operacionais, seja em
ODS ou Data Warehouse.

Caso uma outra linha, também ortodoxa, como a de Kimball, seja adotada, a
organização buscará desenvolver soluções de informação estratégica para cada
área assunto de interesse da organização, atendendo a cada visão de negócio
com sistemas de informações estratégicos, resumidos em Data Marts, priorizando
esta ou aquela visão de negócios na construção. Qual visão de negócios deve ser
privilegiada ? Como descobrir qual visão pode viabilizar os resultados mais
interessantes para a organização ?

Apesar de que esta última visão tende a produzir resultados mais rápidos devido
ao foco em um determinado assunto de negócio, muitas vezes a alta
administração da organização fica privada de informação estratégica para a
condução abrangente e estratégica de seus negócios.

Desta forma, o que se propõe neste artigo é a entrega parcial de resultados, como
em Data Marts propostos por Kimball, mas priorizando a entrega de resultados
que apresentem a informação da camada mais estratégica da organização.

Segundo esta proposta, busca-se produzir resultados que, em primeiro lugar,

forneçam uma visão geral resumida da situação numérica da empresa como um
todo. Não se pode dizer que é um DM, pois o DM é departamental ou de área
assunto específico. Neste caso, o que se tem é uma visão ampla em termos de
negócios (abrangendo a maior parte dos mesmos, os mais representativos), mas
restrita em termos de profundidade, detalhes. O objetivo fundamental é o de
produzir uma visão estratégica dos negócios da organização, que viabilize tomada
de decisão de maior impacto na organização, que defina os rumos da mesma.

Este tipo de abordagem produzirá alguns impactos importantes para a

continuidade da construção da arquitetura BI nas organizações:

- Apresentação dos primeiros resultados da arquitetura exatamente para a

alta executiva da empresa, onde o retorno sobre o investimento será
fortemente percebido;

- Indução à busca de detalhes da visão estratégica apresentada pela alta

executiva da empresa;

- O apelo de se obter retorno sobre investimentos (ROI) de maneira mais

apropriada é indiscutível quando se discute a aplicação de recursos de TI
em uma organização;

- O desenvolvimento direcionado a resultados provocará a criação de um

ciclo virtuoso de resultados que geram novos desenvolvimentos que geram
novos resultados e assim por diante;

- O acompanhamento dos resultados obtidos com os investimentos

empregados será mais visível e viabilizará a construção da arquitetura
completa de informações estratégicas, qualquer que seja a linha de
construção a ser adotada.

- Diante da proposta apresentada, deve-se ter os seguintes cuidados:

- Deve haver elevado envolvimento executivo, incluindo a identificação da

necessidade de se construir tal plataforma de informação.

- A administração do ambiente apoiada por metadados é fundamental para

viabilizar a integração das construções parciais;

- O dimensionamento do escopo do projeto deve ser adequado à realidade

da organização;

- O emprego de tecnologia deve ser efetivo, de acordo com as necessidades

do projeto e da organização;

- Composição da equipe de projetos com indivíduos de elevado

conhecimento técnico em BI e, principalmente, negocial;

- Deve haver contenção do excesso de expectativas dos usuários;

- Como todos os projetos de IT, ainda é necessário cuidados em relação à

resistência humana;
 - A obtenção dos dados deve se dar de forma produtiva, precisa e no tempo
adequado;

- Não se deve utilizar variáveis, cuja qualidade dos dados relativos a elas não
seja confiável. Aliás, em muitas construções BI, o primeiro produto obtido é
que se deve melhorar o nível da qualidade de dados de forma geral ou
específica.

Conclusão: As organizações estão em constante busca por melhores resultados

de suas operações no mercado. Um dos principais insumos para a tomada de
decisões que as possam conduzir neste rumo de sucesso é a informação, vital
para a condução de seus negócios e a tomada de decisão estratégica. Neste
sentido, percebe-se que, mesmo para se atingir o primeiro objetivo, é necessário
que o processo de obtenção da informação estratégica também esteja alinhado
com a busca de melhores resultados. Os resultados positivos na obtenção da
informação viabilizarão outras construções, que viabilizarão novos resultados, em
um fortuíto ciclo virtuoso. Certamente estará se solidificando uma organização
suportada pela inteligência competitiva.

OLAP

Uma coisa é possuir a informação. Outra é a forma como a consultamos.

Partindo dos primórdios da informatização, quando um sistemas que gerava

relatórios era a principal fonte de dados residentes na empresa, toda vez que uma
análise necessitasse ser feita, eram necessários produzir novos relatórios. Estes
relatórios tinham que ser produzidos pela área de informática e, normalmente,
precisavam de muito tempo para ficarem prontos. E, também, apresentavam os
seguintes problemas:

- Os relatórios eram estáticos;

- O acúmulo de diferentes tipos de relatórios num sistema gerava um
problema de manutenção.

Então surgiu o conceito de OLAP (On-Line Analytic Processing). O OLAP

proporciona as condições de análise de dados on-line necessárias para responder
às possíveis torrentes de perguntas dos analistas, gerentes e executivos.

OLAP é implementado em um modo de cliente/servidor e oferece respostas

rápidas as consultas, criando um microcubo na máquina cliente ou no servidor.As
ferramentas OLAP são as aplicações que nossos usuários finais têm acesso para
extraírem os dados de suas bases e construir os relatórios capazes de responder
as suas questões gerenciais. Elas surgiram juntamente com os sistemas de apoio
a decisão para fazerem a consulta e análise dos dados contidos nos Data
Warehouses e Data Marts.

A funcionalidade de uma ferramenta OLAP é caracterizada pela análise multi-

dimensional dinâmica dos dados, apoiando o usuário final nas suas atividades,
tais como: Slice and Dice e Drill.

Características da análise OLAP

Drill Across

O Drill Across ocorre quando o usuário pula um nível intermediário dentro de uma
mesma dimensão. Por exemplo: a dimensão tempo é composta por ano,
semestre, trimestre, mês e dia. O usuário estará executando um Drill Across
quando ele passar de ano direto para semestre ou mês.

Drill Down

O Drill Down ocorre quando o usuário aumenta o nível de detalhe da informação,

diminuindo o grau de granularidade.

Drill Up

O Drill Up é o contrário do Drill Down, ele ocorre quando o usuário aumenta o grau
de granularidade, diminuindo o nível de detalhamento da informação.

Drill Throught

O Drill Throught ocorre quando o usuário passa de uma informação contida em

uma dimensão para uma outra. Por exemplo: Estou na dimensão de tempo e no
próximo passo começo a analisar a informação por região.

Slice And Dice

O Slice and Dice é uma das principais características de uma ferramenta OLAP.
Como a ferramenta OLAP recupera o microcubo, surgiu a necessidade de criar um
módulo que convencionou-se de Slice and Dice para ficar responsável por
trabalhar esta informação. Ele serve para modificar a posição de uma informação,
alterar linhas por colunas de maneira a facilitar a compreensão dos usuários e
girar o cubo sempre que tiver necessidade.

Alertas

Os Alertas são utilizados para indicar situações de destaque em elementos dos

relatórios, baseados em condições envolvendo objetos e variáveis. Servem para
indicar valores mediante condições mas não para isolar dados pelas mesmas.
Ranking

A opção de ranking permite agrupar resultados por ordem de maiores / menores,

baseado em objetos numéricos (Measures).Esta opção impacta somente uma
tabela direcionada (relatório) não afetando a pesquisa (Query).

Filtros

Os dados selecionados por uma Query podem ser submetidos a condições para a
leitura na fonte de dados. Os dados já recuperados pelo Usuário podem ser
novamente “filtrados” para facilitar análises diretamente no documento.

Sorts

Os sorts servem para ordenar uma informação. Esta ordenação pode ser
customizada, crescente ou decrescente.

Breaks

Os Breaks servem para separar o relatório em grupos de informações (blocos).

Por exemplo: O usuário tem a necessidade de visualizar a informação por cidades,
então ele deve solicitar um Break. Após esta ação ter sido executada,
automaticamente o relatório será agrupado por cidades, somando os valor
mensuráveis por cidades.

Bancos MOLAP

O que aconteceria se um banco de dados contivesse dados sumarizados

resultantes de cálculos matemáticos, estatísticos de tempo e financeiros; além de 
não possuir relacionamentos?

Bancos de Dados Multidimensionais

Breves Definições:

Banco de dados multidimensional: multidimensional data base (MDB);

Fato: Tabela de valores. Nesta tabela temos os valores que serão analisados no
nosso Data Warehouse/Data Mart;

Ferramenta MOLAP: Ferramenta OLAP que utiliza um MDB;

Ferramenta ROLAP: OLAP que utiliza um Banco de Dados Relacional.

MDB é um banco que dá suporte e otimiza manipulações matemáticas (como
quantidade total vendida em determinado espaço de tempo), financeiras (como
cálculos com valores, conversões financeiras), estatísticas e de tempo (como
quantos dias há entre 2 datas, por exemplo). Um MDB oferece um ambiente muito
recomendado para usuários que necessitem habilidade de analisar “fatias” dos
dados em um único local.

Para podermos enxergar de forma um pouco mais didática, veremos abaixo um

Data Mart com 3 dimensões em um MDB:

Neste caso acima, temos então uma implementação MOLAP para sua empresa
acessar. Cada aresta representada deste cubo, é uma forma diferente de analisar
os dados, a partir de agora em forma de informação já resumida.

Para acessar a informação, o cliente OLAP informa ao servidor, como por

exemplo, as coordenadas:

(Ano=1999; Linha de produto = Luxo; Região = Centro-Oeste)

e o Banco Multidimensional encontra a receita de vendas referentes a essa

informação e a envia ao client que a requisitou.

A escalabilidade dos bancos multidimensionais é outra característica destes. Estes

bancos são projetados para suporte a um número muito grande de usuários
simultâneos sem que haja degradação na sua performance.

Breve Definição:

Agregações ou valores agregados: valores que envolvem uma pré-computação do

banco de dados multidimensional. Uma agregação pode ser um total de vendas de
uma determinada região. Estes valores são encontrados no MDB, não somente
desta região, mas também totais de vendas de todas regiões, totais mensais,
anuais, todos anos.

Hierarquia: relação de superioridade entre níveis mais altos em comparação aos

mais baixos. À medida que descemos os níveis hierárquicos, veremos grãos cada
vez mais detalhados, enquanto ao ascendemos nesses níveis temos um
detalhamento menor.

Em um MDB, podemos encontrar todos os cálculos que envolvem os valores do

MDB (como no exemplo abaixo). Como conseqüência, as queries quase não
requerem processamento algum do servidor. O processamento no servidor
demora na maioria das queries menos de 5 (cinco) segundos, e em quase todas
queries até 10 (dez) segundos.

Receita de vendas do 3º trimestre de 1999

  SP RJ MG Total

Nacionais 352.950 220.530 251.830 825.310

Importados 126.290 90.850 93.870 311.010

Total 452.240 311.380 345.700 1.136.320

Agregações

Muitos valores agregados são predefinidos pelo Banco Multidimensional, assim

como no exemplo acima. Cálculos simples como totais de vendas e médias
aritméticas já são previstas pelo MDB ao processar as informações ao configurar a
mesma.

A explosão de dados é outra característica marcante do MDB. O número de

agregações em um MDB é uma função principalmente do número de dimensões e
dos níveis de hierarquias, os quais influem mais diretamente no volume de dados
que teremos no nosso servidor.

Assim como no exemplo acima o ano de 1999 tem os 4 trimestres, cada um

destes terá seus 3 meses de vendas, cada mês seus dias, até que cheguemos ao
grão, seja ele dia, hora, minutos ou ainda segundos.
Ao ascendermos em uma hierarquia dentro do MDB qualquer, teremos valores
cada vez mais agregados. No exemplo acima a receita de vendas do 1º trimestre
de 1999 é um valor que agrega todos os grãos referentes a esse trimestre,
enquanto a receita de vendas de 1999 é um valor que agrega as receitas de
vendas de todos trimestres desse ano.

Utilizando um número médio de agregações, e considerando a complexidade e

hierarquias destas, teremos em média uma explosão de dados com um fator de
240, ou seja, 15Mb de dados brutos se transformarão em um cubo que necessite
de, em média, 3,6GB para administra-lo.

DATA MART

A criação de um data warehouse requer tempo, dinheiro e considerável esforço

gerencial. Muitas companhias ingressam num projeto de data warehouse focando
necessidades especiais de pequenos grupos dentro da organização. Estes
pequenos armazenamentos de dados são chamados de Data Mart. Um data mart
é um pequeno data warehouse que fornece suporte à decisão de um pequeno
grupo de pessoas.

Algumas organizações são atraídas aos data marts não apenas por causa do
custo mais baixo e um tempo menor de implementação, mas também por causa
dos correntes avanços tecnológicos. São elas que fornecem um SAD customizado
para grupos pequenos de tal modo que um sistema centralizado pode não estar
apto a fornecer. Data marts podem servir como veículo de teste para companhias
que desejam explorar os benefícios do data warehouse.

Há um consenso entre os fornecedores de soluções de data warehouse. A idéia é

começar pequeno mas pensando grande. E é o que está acontecendo. Na maioria
dos casos, as empresas que optam pelo data warehouse iniciam o processo a
partir de uma área específica da empresa para depois ir crescendo aos poucos.
Mesmo nos casos de “Full Warehouse” ou data warehouse completos - como o da
Previdência Social da Holanda e Noruega - o processo costuma ser organizado a
partir dos data marts.

A variação de custo e duração de um projeto de data warehouse depende do

tamanho e da infra-estrutura da base de dados a ser trabalhada e também da
necessidade de “poder de fogo” (do quão estratégico e eficiente tem que ser o
sistema para o cliente). Acima de tudo, a empresa tem que saber identificar quais
são os tipos de informações mais valiosos.

O data warehouse pode ser uma decisão estratégica, mas não pode ser encarado
com imediatismo, ou seja, não é apenas algo que se realiza aos poucos, mas
também é um processo contínuo de atualização e consolidação dos dados
corporativos. Por isso, os investimentos em um sistema desse tipo não devem
nem podem ser feitos de uma única vez, mas de forma gradual ao longo do
tempo.

Data Warehouse X DataMart

É preciso ter em mente que as diferenças entre data mart e data warehouse são
apenas com relação ao tamanho e ao escopo do problema a ser resolvido.
Portanto, as definições dos problemas e os requisitos de dados são
essencialmente os mesmos para ambos. Enquanto um data mart trata de
problema departamental ou local, um data warehouse envolve o esforço de toda a
companhia para que o suporte à decisões atue em todos os níveis da
organização. Sabendo-se as diferenças entre escopo e tamanho, o
desenvolvimento de um data warehouse requer tempo, dados e investimentos
gerenciais muito maiores que um data mart.

Por muitos anos, todos os sistemas que extraíam dados de sistemas legados e os
armazenavam de maneira utilizável para suporte à decisão eram chamados data
warehouses. Ao longo dos últimos anos, uma distinção tem sido feita entre os
corporativos data warehouses e os departamentais data marts, mesmo que
geralmente o conceito ainda continue sendo chamado de data warehousing.

Debates na indústria em geral indicam que aproximadamente 70 a 80 por cento de

todos os data warehouses atualmente em produção são, de fato, data marts. Na
Conferência do Meta Group/DCI 1997 Data Warehouse World Conference, de
fevereiro de 1997 observou-se que “o foco dos departamentos de informática tem
se transferido da justificação do custo de implementação de data warehouses para
a entrega de aplicações de data marts.”

Os data marts atendem as necessidades de unidades específicas de negócio ao

invés das da corporação inteira. Eles otimizam a entrega de informação de suporte
à decisão e se focam na gerência sumarizada e/ou dados exemplificativos ao
invés do histórico de níveis atomizados. Eles podem ser apropriados e
gerenciados por pessoal fora do departamento de informática das corporações.

A crescente popularidade desses mal definidos data marts em cima da

popularidade dos grandes sistemas de data warehouses corporativos é baseada
em muitos bons motivos:

- Os data marts têm diminuído drasticamente o custo de implementação e

manutenção de sistemas de apoio à decisão e têm os posto ao alcance de
um número muito maior de corporações;
- Eles podem ser prototipados muito mais rápido, com alguns pilotos sendo
construídos entre 30 e 120 dias e sistemas completos sendo construídos
entre 3 e seis meses;
 - Os data marts têm o escopo mais limitado e são mais identificados com
grupos de necessidades dos usuários, o que se traduz em esforço/time
concentrado.

Os departamentos autônomos e as pequenas unidades de negócio

freqüentemente preferem construir o seu próprio sistema de apoio à decisão via
data marts. Muitos departamentos de informática estão vendo a efetividade deste
approach e estão agora construindo o data warehouse por assunto ou um data
mart por vez, gradualmente ganhando experiência e garantindo o suporte dos
fatores chave de gerenciamento e vendo, então, benefícios concretos muitas
vezes ao ano. Começando com planos modestos e os desenvolvendo na medida
que se adquire mais conhecimento sobre as fontes de dados e as necessidades
dos usuários faz com que as organizações justifiquem os data marts na medida
em que progridem.

Algumas vezes, projetos que começam como data warehouses se transformam

em data marts. Quando as organizações acumulam grandes volumes de dados
históricos para suporte à decisão que se mostram pouco ou nunca utilizados, elas
podem reduzir o armazenamento ou arquivamento de informação e contrair o seu
data warehouse em um data mart mais focado. Ou elas podem dividir o
warehouse em vários data marts, oferecendo tempos de resposta mais rápido,
acesso mais fácil e menos complexidade para os usuários finais.

CRM

Um Data Warehouse bem estruturado pode ser usado como uma poderosa
ferramenta de CRM (Gerenciamento de relacionamento com o Cliente) analítico.

Através do CRM a empresa pode conhecer o perfil de seu cliente, e a partir daí
fazer um trabalho dirigido de fidelidade. Por meio de pesquisas, descobriu-se que
é muito mais lucrativo manter um cliente do que tentar conquistar novos clientes.
Essa diferença de lucratividade fica mais explícita quando um cliente fidelizado é
comparado com cliente perdido pela empresas que terá de ser reconquistado.

O CRM é dividido em duas frentes, a operacional e a analítica. O CRM

operacional é feito através do contato direto da empresa com o cliente. Call
Centers, malas diretas, internet e outros tipos de canais são utilizados nesse
segmento de CRM. Já o CRM analítico é feito através dos dados contidos nas
bases gerenciais da empresa (Data Warehouse). Enquanto a função do
operacional é manter o contato com o cliente, o analítico preocupa-se em analisar
os dados colhidos por diversas fontes da empresa sobre o cliente.

Portanto o Data Warehouse deve contemplar as análises de campanhas de

marketing, perfil do cliente, análise de vendas, lealdade, desempenho dos canais
de contato, entre outras análises que fazem parte do CRM analítico.
DATA MINING

Atualmente, muitas revistas de informática e de negócios têm publicado artigos

sobre Data Mining. Contudo, há poucos anos atrás, muito pouca gente tinha
ouvido falar a respeito. Apesar dessa tecnologia ter uma longa evolução de sua
história, o termo como conhecemos hoje só foi introduzido recentemente, nos
anos 90.

DataMining (ou mineração de dados) é o processo de extrair informação válida,

previamente desconhecida e de máxima abrangência a partir de grandes bases de
dados, usando-as para efetuar decisões cruciais. O DMvai muito além da simples
consulta a um banco de dados, no sentido de que permite aos usuários explorar e
inferir informação útil a partir dos dados, descobrindo relacionamentos escondidos
no banco de dados. Pode ser considerada uma forma de descobrimento de
conhecimento em bancos de dados (KDD - Knowledge Discovery in Databases),
área de pesquisa de bastante evidência no momento, envolvendo Inteligência
Artificial e Banco de Dados.

Algumas vezes, projetos que começam como data warehouses se transformam

em data marts. Quando as organizações acumulam grandes volumes de dados
históricos para suporte à decisão que se mostram pouco ou nunca utilizados, elas
podem reduzir o armazenamento ou arquivamento de informação e contrair o seu
data warehouse em um data mart mais focado. Ou elas podem dividir o
warehouse em vários data marts, oferecendo tempos de resposta mais rápido,
acesso mais fácil e menos complexidade para os usuários finais.

Veja em que se baseia.

1.1) A estatística

O Data Mining descende fundamentalmente de 3 linhagens. A mais antiga delas é

a estatística clássica. Sem a estatística não seria possível termos o DM, visto que
a mesma é a base da maioria das tecnologias a partir das quais o DM é
construído.

A Estatística Clássica envolve conceitos como distribuição normal, variância,

análise de regressão, desvio simples, análise de conjuntos, análises de
discriminantes e intervalos de confiança, todos usados para estudar dados e os
relacionamentos entre eles.

Esses são as pedras fundamentais onde as mais avançadas análises estatísticas

se apóiam. E sem dúvida, no coração das atuais ferramentas e técnicas de DM, a
análise estatística clássica desempenha um papel fundamental.

1.2) Inteligência Artificial

A segunda linhagem do DM é a Inteligência Artificial, ou IA. Essa disciplina, que é

construída a partir dos fundamentos da heurística, em oposto à estatística, tenta
imitar a maneira como o homem pensa na resolução dos problemas estatísticos.

Em função desse “approach”, ela requer um impressionante poder de

processamento, que era impraticável até os anos 80, quando os computadores
começaram a oferecer um bom poder de processamento a preços mais
acessíveis.

A IA desenvolveu algumas aplicações para o alto escalão do governo/cientistas

americanos, sendo que os altos preços não permitiram que ela ficasse ao alcance
de todos. As notáveis exceções foram certamente alguns conceitos de IA
adotados por alguns produtos de ponta, como módulos de otimização de consultas
para SGBDs.

1.3) Machine Learning

E a terceira e última linhagem do DM é a chamada machine learning, que pode ser

melhor descrita como o casamento entre a estatística e a IA. Enquanto a IA não se
transformava em sucesso comercial, suas técnicas foram sendo largamente
cooptadas pela machine learning, que foi capaz de se valer das sempre
crescentes taxas de preço/performance oferecidas pelos computadores nos anos
80 e 90, conseguindo mais e mais aplicações devido às suas combinações entre
heurística e análise estatística.A machine learning tenta fazer com que os
programas de computador “aprendam” com os dados que eles estudam, tal que
esses programas tomem decisões diferentes baseadas nas características dos
dados estudados, usando a estatística para os conceitos fundamentais, e
adicionando mais heurística avançada da IA e algoritmos para alcançar os seus
objetivos.

De muitas formas, o DM é fundamentalmente a adaptação das técnicas da

Machine Learning para as aplicações de negócios. Desse modo, podemos
descreve-lo como a união dos históricos e dos recentes desenvolvimentos em
estatística, em IA e Machine Learning. Essas técnicas são usadas juntas para
estudar os dados e achar tendências e padrões nos mesmos. Hoje, o DM tem
experimentado uma crescente aceitação nas ciências e nos negócios que
precisam analisar grandes volumes de dados e achar tendências que eles não
poderiam achar de outra forma.

2 – Um resumo das principais técnicas de Data Mining

Existem inúmeras ramificações de Data Mining, sendo algumas delas:

REDES NEURAIS

INDUÇÃO DE REGRAS

ÁRVORES DE DECISÃO

ANÁLISES DE SÉRIES TEMPORAIS

VISUALIZAÇÃO

Visão geral das tecnologias de Data Mining (DM)

O DM é um campo que compreende atualmente muitas ramificações importantes.

Cada tipo de tecnologia tem suas próprias vantagens e desvantagens, do mesmo
modo que nenhuma ferramenta consegue atender todas as necessidades em
todas as aplicações.

Redes Neurais
Essa tecnologia é a que oferece o mais profundo poder de mineração, mas é
também a mais difícil de entender. As redes neurais tentam construir
representações internas de modelos ou padrões achados nos dados, mas essas
representações não são apresentadas para o usuário. Com elas, o processo de
descoberta de padrões é tratado pelos programas de DM dentro de um processo
“caixa-preta”.

As ferramentas deveriam, contudo, ser construídas para fazer as decisões ficarem

visíveis para os usuários. O problema com esse “approach” é que as decisões são
feitas na caixa-preta, o que as faz inexplicáveis.

Embora seja verdadeiro que as redes neurais apresentem o mais avançado poder
de mineração, muitos analistas de negócio não podem fazer uso delas porque os
resultados finais não podem ser explicados.

Estruturalmente, uma rede neural consiste em um número de elementos

interconectados (chamados neurônios) organizados em camadas que aprendem
pela modificação da conexão firmemente conectando as camadas. Geralmente
constroem superfícies equacionais complexas através de interações repetidas,
cada hora ajustando os parâmetros que definem a superfície. Depois de muitas
repetições, uma superfície pode ser internamente definida que se aproxima muito
dos pontos dentro do grupo de dados.

A função básica de cada neurônio é: (a) avaliar valores de entrada, (b) calcular o
total para valores de entrada combinados, (c) compara o total com um valor limiar,
(d) determinar o que será a saída. Enquanto a operação de cada neurônio é
razoavelmente simples, procedimentos complexos podem ser criados pela
conexão de um conjunto de neurônios. Tipicamente, as entradas dos neurônios
são ligadas a uma camada intermediária (ou várias camadas intermediárias) que é
então conectada com a camada de saída.

Para construir um modelo neural, nós primeiramente "adestramos" a rede em um

dataset de treinamento e então usamos a rede já treinada para fazer predições.
Nós podemos, às vezes, monitorar o dataset durante a fase de treinamento para
checar seu progresso.

Cada neurônio geralmente tem um conjunto de pesos que determina como o

neurônio avalia a combinação dos sinais de entrada. A entrada para um neurônio
pode ser positiva ou negativa. O aprendizado se faz pela modificação dos pesos
usados pelo neurônio em acordo com a classificação de erros que foi feita pela
rede como um todo. As entradas são geralmente pesadas e normalizadas para
produzir um procedimento suave.

Durante a fase de treinamento, a rede estabelece os pesos que determinam o

comportamento da camada intermediária. Um termo popular chamado
"backpropagation" (propagação realimentada) é usado quando os pesos são
ajustados baseados nas estimativas feitas pela rede - suposições incorretas
reduzem os limites para as conexões apropriadas.

Exemplos de ferramentas : SPSS Neural Connection, IBM Neural Network Utility,

NeuralWare NeuralWorks Predict

Indução de Regras

A Indução de Regras, ou Rule Induction, se refere à detecção de tendências

dentro de grupos de dados, ou de “regras” sobre o dado. As regras são, então,
apresentadas aos usuários como uma lista “não encomendada”.

Vários algoritmos e índices são colocados para executar esse processo, incluindo
o Gini, o C 4.5 e o CHAID. Na IR, a grande maioria do processo é feito pela
máquina, e uma pequena parte é feita pelo usuário.

Por exemplo, a tradução das regras para dentro de um modelo aproveitável é feito
pelo usuário, ou por uma interface de árvores de decisão. Do ponto de vista do
usuário, o maior problema com as regras é que o programa de DM não faz o
ranking das regras por sua importância. O analista de negócio é então forçado a
encarregar-se de criar um manual de análise para todas as regras relatadas a fim
de determinar aquelas que são mais importantes no modelo de DM, e para os
assuntos de negócio envolvidos. E isso pode ser um processo tedioso.

Exemplos de ferramentas: IDIS, da Information Discovery e Knowledge Seeker, da

Angoss Software;

Árvores de decisão

As árvores de decisão são uma evolução das técnicas que apareceram durante o
desenvolvimento das disciplinas de machine learning. Elas cresceram a partir da
aproximação de uma análise chamada Detecção de Interação Automática,
desenvolvida na Universidade de Michigan. Essa análise trabalha testando
automaticamente todos os valores do dado para identificar aqueles que são
fortemente associados com os itens de saída selecionados para exame. Os
valores que são encontrados com forte associação são os prognósticos chaves ou
fatores explicativos, usualmente chamados de regras sobre o dado. Outro antigo
algoritmo chamado CHAID foi desenvolvido estendendo as capacidades do DIA
sendo um pouco através da adição da fórmula estatística Chi squared.

Mas foi uma professor na Austrália que desenvolveu a tecnologia que permitiu o
aparecimento das árvores de decisão. Muitas pessoas na indústria de DM
consideram Ross Quinlan, da Universidade de Sydney, Austrália, como o “pai das
árvores de decisão”. A contribuição de Quinlan foi um novo algoritmo chamado
ID3, desenvolvido em 1983. O ID3 e e suas evoluções (ID4, ID6, C 4.5, See 5) são
muito bem adaptadas para usar em conjunto com as árvores de decisão, na
medida em que eles produzem regras ordenadas pela importância. Essas regras
são, então, usadas para produzir um modelo de árvore de decisão dos fatos que
afetam os ítens de saída. Novas fórmulas de árvores de decisão como a Gini, um
índice computacional inventado por Ron Bryman, são também muito bem
adaptadas para as árvores de decisão, e oferecem uma crescente velocidadede
processamento assim como mais amplas habilidades para processar números
concorrentemente com textos.

As árvores de decisão são meios de representar resultados de DM na forma de

árvore, e que lembram um gráfico organizacional horizontal. Dados um grupo de
dados com numerosas colunas e linhas, uma ferramenta de árvore de decisão
pede ao usuário para escolher uma das colunas como objeto de saída, e aí mostra
o único e mais importante fator correlacionado com aquele objeto de saída como o
primeiro ramo (nó) da árvore de decisão. Os outros fatores são subseqüentemente
classificados como nós do(o) nó(s) anterior(es). Isso significa que o usuário pode
rapidamente ver qual o fator que mais direciona o seu objeto de saída, e o usuário
pode entender porque o fator foi escolhido. Uma boa ferramenta de AD vai,
também, permitir que o usuário explore a árvore de acordo com a sua vontade, do
mesmo modo que ele poderá encontrar grupos alvos que lhe interessem mais, e aí
ampliar o dado exato associado ao seu grupo alvo. Os usuários podem, também,
selecionar os dados fundamentais em qualquer nó da árvore, movendo-o pra
dentro de uma planilha ou outra ferramenta para análise posterior.

As árvores de decisão são, quase sempre, usadas em conjunto com a tecnologia

de Indução de Regras, mas são únicas no sentido de apresentar os resultados da
Indução de Regras num formato com priorização. Então, a regra mais importante é
apresentada na árvore como o primeiro nó, e as regras menos relevantes são
mostradas nos nós subseqüentes. As vantagens principais das árvores de decisão
são que elas fazem decisões levando em consideração as regras que são mais
relevantes, além de serem compreensíveis para a maioria das pessoas. Ao
escolher e apresentar as regras em ordem de importância, as árvores de decisão
permite aos usuários ver, na hora, quais fatores mais influenciam os seus
trabalhos.
Exemplos de ferramentas : Alice d'Isoft, HyperParallel //Discovery, Business
Objects BusinessMiner, DataMind,Angoss Knowledge Seeker..

Análise Estatística de Séries Temporais

A estatística é a mais antiga tecnologia em DM, e é parte da fundação básica de

todas as outras tecnologias. Ela incorpora um envolvimento muito forte do usuário,
exigindo engenheiros experientes, para construir modelos que descrevem o
comportamento do dado através dos métodos clássicos de matemática. Interpretar
os resultados dos modelos requer “expertise” especializada. O uso de técnicas de
estatística também requer um trabalho muito forte de máquinas/engenheiros.

A análise de séries temporais é um exemplo disso, apesar de freqüentemente ser

confundida como um gênero mais simples de DM chamado forecasting”(previsão).

Enquanto que a análise de séries temporais é um ramo altamente especializado

da estatística, o “forecasting” é de fato uma disciplina muito menos rigorosa, que
pode ser satisfeita, embora com menos segurança, através da maioria das outras
técnicas de DM.

Exemplos de ferramentas : S+, SAS, SPSS

Visualização

As técnicas de Visualização são um pouco mais difíceis de definir, porque muitas

pessoas a definem como “complexas ferramentas de visualização”, enquanto
outras como simplesmente a capacidade de geração de gráficos.

Nos dois casos, a Visualização mapeia o dado sendo minerado de acordo com
dimensões especificadas. Nenhuma análise é executada pelo programa de DM
além de manipulação estatística básica. O usuário, então, interpreta o dado
enquanto olha para o monitor. O analista pode pesquisar a ferramenta depois para
obter diferentes visões ou outras dimensões.

Exemplos de ferramentas : IBM Parallel Visual Explorer, SAS System, Advanced

Visual Systems (AVS) Express - Visualization Edition

3 – Algumas razões porque o DM tem-se tornado parte das ferramentas de SAD

A crescente disponibilização de informações que tem surgido na medida em que
mais e mais organizações utilizam-se das ferramentas de Business intelligence,
está fazendo com que apareçam, também, novas necessidades de análise das
informações disponibilizadas.

Para atender essas novas necessidades, as ferramentas de SAD têm sido

incrementadas com sofisticadas funções, tais como a análise OLAP (On Line
Analitical Processing), formatações de relatórios cada vez mais flexíveis,
visualização 3D, filtros, classificações, alertas entre outros.

De todas essas funções, a OLAP é, sem discussão, a mais sofisticada, na medida

em que possibilita aos usuários estudar os dados de maneira multidimensional, de
modo que os mesmos podem “perfurar” os dados até os seus detalhes (função
comumente chamada de “drill down”), ou ainda ver porções sumarizadas desses
dados (função slice-and-dice), do ponto de vista que desejarem, enquanto
“perseguem” as respostas que procuram. Assim essa função permite que o
usuário veja os dados de várias e diferentes perspectivas, e a numerosos níveis
de detalhe ou agregação.

Comparativamente, o DM apresenta um método alternativo e automático de

descobrir padrões nos dados. Alternativo porque ele trabalha diretamente contra
todos os dados de um grupo, ao invés de se ater a seguir determinado caminho ao
longo de alguns dados e “perfurar” (ou executar um drill down) em busca de
detalhes. E é automático em sua execução devido ao fato que a ferramenta, por
ela mesma, estuda o dado e apresenta os seus “achados” aos usuários. Apesar
de o usuário ter que de tomar o cuidado de fornecer dados úteis à ferramenta,
uma vez isso feito ela pega o comando e “tritura” o grupo de dados ao seu modo.

Devido a essas duas características, o DM é extremamente adequado para

analisar grupos de dados que seriam difíceis de analisar usando apenas a função
OLAP, visto que esses grupos são grandes demais para serem “navegados”, ou
explorados manualmente, ou ainda porque contêm dados muito densos ou não-
intuitivos para serem compreendidos.

O DM não requer que o usuário “pilote”a ferramenta ao longo do processo de

análise dos dados, ou que administre o processo ao longo de seu andamento.
Fornecidos dados adequados no início do processo, o DM pode trazer sentido a
grupos de dados achando tendências ou padrões “escondidos” nos mesmos, e
apresentá-los ao usuário num formato compreensível.

Assim, a diferença básica entre OLAP e DM está na maneira como a exploração

dos dados é realizada. Na análise OLAP a exploração é feita através da
verificação, isto é, o analista conhece a questão, elabora uma hipótese e utiliza a
ferramenta pra refutá-la ou confirmá-la. Com o DM, a questão é total ou
parcialmente desconhecida e a ferramenta é utilizada para a busca de
conhecimento.
E essa capacidade claramente agrega valor à soluções de apoio à decisão. Em
muitos casos, os resultados apresentados pelo DM fazem surgir interessantes
questões sobre os dados originais ou que tenham alguma relação com os mesmos
no DW. Esse é um outro exemplo de como o DM agrega valor aos SAD.

Quando os resultados do DM propõem questões adicionais, os usuários podem

procurar por mais respostas em tempo real simplesmente rodando uma nova
consulta na base de dados, e minerando de novo. Ou, eles podem desejar usar os
resultados de uma mineração como guia para ajudá-los a pesquisar mais dados
usando a análise OLAP. Muitas vezes os usuários percebem que estão usando
um processo interativo de consultas, DM e OLAP, ao conseguir obter as
informações que mais lhes interessam, ao mesmo tempo em que podem formatar
os relatórios da maneira mais conveniente.

Dessa forma, o DM está se tornando um componente essencial para análise para

os sistemas de apoio à decisão, complementando as funções já existentes.

Algumas barreiras ao uso do DM

Nem sempre o DM pôde agregar valor aos SAD. De fato, houve no passado (e
ainda há, de certa forma) muitas barreiras para o DM se tornar uma função
essencial dos SAD. As mais importantes têm sido ultrapassadas, mas outras ainda
se mantêm.

Fundamentalmente, as mais importantes foram: alto custo das soluções;

necessidade de grandes volumes de dados armazenados em poderosos
servidores; e a pouca amigabilidade das ferramentas de DM para pessoas que
não fossem altamente especializadas.

Outras que se podem citar são: o desafio de preparar os dados para mineração;
as dificuldades em se obter uma análise custo/benefício bem fundamentada antes
do início do projeto e a preocupação quanto à viabilidade de muitos dos
fornecedores dessas ferramentas.

Altos Custos

O alto custo da maioria das ferramentas faz com que fique difícil a disseminação
das mesmas entre as corporações. Uma simples operação matemática mostra
que um projeto, com o custo de US$ 20.000 por usuário, pode atender não mais
que um seleto grupo de usuários.

Certos fornecedores dessas ferramentas têm introduzido produtos com custo mais
baixo, mas mesmo assim o preço continua limitando o uso em larga escala.
Evidentemente, os custos por usuário precisam ser reduzidos antes que os
benefícios desta tecnologia possam atingir a massa de usuários.
Necessidade de grandes volumes de dados

O maior obstáculo ao DM no passado foi a necessidade de armazenar e

administrar montanhas de dados e/ou servidores. Isso por si só já dificultava
bastante o crescimento do mercado de DM.

No entanto, a maioria dos fornecedores dessa tecnologia continua insistindo no

discurso de que o DM requer terabytes de dados e poderosos servidores, mas
soluções mais acessíveis já têm aparecido no mercado e criado condições para
ele deslanchar.

É aceita pelo mercado a afirmação de que 80% do valor de um determinado grupo

de dados pode ser encontrado em 20% dos dados que o compõem, então é claro
que os fornecedores vão fazer de tudo para achar esses 20% e minerá-los.

As ferramentas que procuram tornar pessoalmente manejáveis grupos de dados

dão aos usuários a possibilidade de minerar porções de dados em seu próprio
computador, o que pode, efetivamente, contornar essa barreira. Embora não
tenham a intenção de substituir aplicações que necessitam de grandes volumes
de dados, essas ferramentas podem prover um acesso alternativo que pode
também ser usado em conjunto com as ferramentas “pesadas”.

Complexidade das Ferramentas

Mas mesmo com essa nova geração de ferramentas que permitem a mineração
em moderados grupos de dados, uma terceira barreira ainda permanece: A
grande maioria das ferramentas ainda continua incompreensível para os usuários
comuns. De fato, muitas ferramentas ainda fazem o seu trabalho em uma “caixa-
preta”, não permitindo que se saiba como alcançaram os seus resultados.

Isso significa que o DM ainda tem que ser feito no contexto da área de sistemas, a
quem os usuários têm que submeter as suas solicitações, esperar por dias ou
semanas enquanto um expert processa os dados, para então receberem e
examinarem a saída sumarizada. Se os resultados não satisfizerem, todo
processo tem que ser recomeçado.

Felizmente, há técnicas de DM mais compreensíveis, como, por exemplo, as

árvores de decisão, que permitem que qualquer um, com conhecimentos básicos
de computadores, possa utilizar e compreender o processo.

Contudo, o poder dessas ferramentas não chega nem perto daquelas que utilizam
técnicas mais sofisticadas.

O desafio da preparação dos dados para a mineração

A preparação dos dados para se realizar a mineração envolve muitas e
trabalhosas tarefas num projeto de DM, sendo considerada como 80% do
trabalho.

Os dados devem ser relevantes para as necessidades dos usuários, “limpos”

(livres de erros lógicos ou de entrada de dados), consistentes, e livres de
excessivas nulidades.

Mesmo que haja um projeto de DW anterior, onde os dados são normalmente

limpos e centralizados em um único local, continua havendo a necessidade de
prepara-los para a mineração, assim como a escolha dos dados certos para
minerar continua sendo crítico.

As dificuldades de se realizar a análise custo/benefício do projeto de DM

Estimar a taxa de retorno do investimento de um projeto de DM é complicado

devido ao fato que, como o objetivo da tecnologia é descobrir tendências (em
dados) que não seriam visíveis de outra maneira, torna-se virtualmente impossível
estimar tal taxa a partir de algo que é desconhecido. Visto que normalmente um
projeto de DM é razoavelmente caro, pode ser um tanto arriscado se decidir por
um projeto desse tipo.

Viabilidade dos fornecedores de ferramentas de DM

Finalmente, a viabilidade de mercado da maioria das ferramentas é uma

preocupação das empresas que procuram uma ferramenta confiável, para hoje e
para o futuro. O mercado está abarrotado de fornecedores, desde pequenas
empresas que comercializam apenas este produto até grandes companhias em
que sua ferramenta de DM é apenas mais uma das que produz. Assim como
qualquer nova tecnologia, a escolha do fornecedor é tão importante quanto a
escolha da ferramenta.

4 – Implementação de projetos de DM: Algumas questões importantes

A determinação de um valor mínimo para a realização da mineração

A regra 80/20

Os analistas concordam que por dentro de qualquer grande grupo de dados, 80%
da informação podem ser encontrados dentro de 20% dos dados. Essa regra força
a redução do tamanho do grupo de dados a ser analisado. O particionamento dos
grupos de dados pode ser usado para conseguir esse intento, o que significa que
apenas os dados relevantes é que são usados para o DM, concentrando os dados
úteis dentro dos 20% selecionados para análise. Se mesmo os grupos de dados
particionados continuarem grandes, pode-se retirar amostras dos mesmos para se
ter uma idéia do que acontece no todo.
Viabilidade estatística mínima

Quando se tenta minimizar o tamanho dos grupos de dados, é importante ter em

mente que um número mínimo de registros é necessário para se ter viabilidade
estatística. Em geral, um mínimo de 200 registros pode ser analisado de maneira
a se obter resultados estatisticamente viáveis, pois é um bom tamanho dentro do
escopo de dados de negócio.

As necessidades específicas de negócio

No contexto dos negócios, o DM encontra aplicações adequadas para estudar

aspectos específicos do negócio, o que se pode chamar de Escopo de Análise.
Por exemplo, um gerente de uma agência bancária quase certamente está mais
preocupado com os seus clientes do que com os clientes estaduais ou nacionais
do seu banco. Então o escopo de análise deste gerente certamente é a sua
agência, ou possivelmente a sua região, de modo a poder comparar os dados da
sua agência com os das agências de sua região. Grandes quantidades de dados
neste caso não são necessários para se chegar a bons resultados.

Porque dados de negócio são mais fáceis de minerar

Os dados de negócio apresentam oportunidades únicas para minerar.

Comparados com outros tipos de dados como os científicos, atuariais ou
estatísticos, eles são mais homogêneos e intuitivos, além de proporcionar mais
facilidades de agregação, que podem muitas vezes reduzir o volume de dados
“crus” necessários para uma dada operação.

Além disso, os dados de negócio normalmente são mantidos por pessoas de

negócio, que conhecem o seu significado. Os outros dados são com mais
freqüência recolhidos por um processo remoto, e aí transferidos para outros
analistas para processamento posterior, reduzindo as possibilidades desses
últimos entenderem o significado de cada aspecto dos dados.
Os dados de negócios são previsíveis

A possibilidade de se fazer previsões é o fator chave para que os dados de

negócio sejam mais “mineráveis”. Eles são coletados dentro do sistema de um
negócio particular, descrevendo, por exemplo, os clientes daquele negócio. Dados
de negócio “limpos” tenderão a conter valores que se incluirão em certas escalas
cabíveis. Ë completamente diferente, por exemplo, um vendedor de carros vender
um a R$ 40.000,00 ou a R$40.000.000,00. Os preços dos carros tendem a se
enquadrar dentro de uma faixa razoável. Igualmente, não é razoável o mesmo
vendedor de carros vende-los a pessoas que residem em países distantes ou que
pagam com moedas estrangeiras. Os dados de negócio sobre vendas de carros
tendem a descrever vendas a consumidores locais, e pagando na moeda do país.
Devido a eles terem menos exceções, é mais fácil ao usuário do DM reconhecer
tendências ou padrões. Valores fora do comum em um grupo de dados fazem com
que seja mais difícil minerar. Usando os termos de DM, esses valores
excepcionais são chamados de “ruído”.

Os Dados de Negócio são intuitivos

A natureza intuitiva dos dados de negócio é um outro facilitador para o DM.

Enquanto o dado científico normalmente contém valores “impenetráveis” e muitas
minúcias, o dado de negócio está de um lado diametralmente oposto.

Dados de negócio descrevem negócios, e são nomeados e guardados pelas

pessoas de negócio. Termos como receita, despesa, taxa de resposta, nível do
estoque, e limites de crédito são intuitivos, e os dados armazenados para estes
termos fazem sentido num contexto de negócios. As pessoas de negócio saberão
intuitivamente que os valores para limite de crédito serão certamente quantias de
dinheiro, e que um valor para taxa de resposta será em percentual. O fato dos
dados de negócio serem intuitivamente compreensíveis às pessoas de negócio é
uma grande vantagem para realizar DM pois consegue levantar muitos novos
conhecimentos a partir de pequenos ou médios grupos de informações. Na
linguagem do DM, essa característica de dados intuitivos é chamada de
percepção nativa dos dados.

As agregações podem acelerar o DM

Os dados de negócio são freqüentemente armazenados em formatos agregados,

como por exemplo receitas por trimestre, vendas por região, ou respostas de
promoções por CEP. Esses formatos podem ser muito mais fáceis de minerar do
que dados crus. Por outro lado, dados que não são de negócio suportam muito
menos sumarizações desse modo. Essas agregações permitem uma mineração
proveitosa num grupo de dados muito menor do que seria possível com dados
científicos. Minerando agregações, os usuários de negócio podem descobrir
tendências em seus negócios em qualquer nível que eles desejem. Minerando em
receitas regionalmente agregadas por gastos com propaganda nos vários meios
de comunicação poderia descrever que tipo de propaganda é mais efetiva em
cada região. Neste caso, não haveria a necessidade de minerar as vendas em
todo o território nacional.

Os usuários dos dados são os donos dos dados

Uma outra vantagem importante dos dados de negócio é que eles são, quase
sempre, coletados, mantidos e apropriados pelas mesmas pessoas que os usam,
isto é, pelas pessoas de negócio. Em contraste, os dados científicos são
freqüentemente compostos de fontes de dados estratificadas, como, por exemplo,
amostras que são coletadas em pesquisas de campo por algumas pessoas, e que
são mandadas ao centro de operações para ser compiladas por um outro time de
analistas.

4 - Glossário de Termos de Data Mining

AID: um dos primeiros algoritmos de DM desenvolvido na Univ. de Michigan.

Significa Detector Automático de Interação e tratava apenas valores simbólicos.

Agrupamento: Similar a Bining, mas para simbólicos. A principal diferença é que o

usuário pode, manualmente, desagrupar valores. Numa árvore de decisão, o
agrupamento é feito baseado no fator discriminante.

Amostragem: Pegar uma amostra casual de dados com o objetivo de reduzir o

número de registros para minerar. É um procedimento estatisticamente
complicado, mas pode ser feito num SGBD através do uso de um gerador
randômico de números e colunas no banco de dados.

Algoritmo: fórmula matemática complexa que é o coração de qualquer ferramenta

de DM. Análise “basket market”: uma técnica, usada em grandes redes varejistas,
que estuda cada compra feita por clientes para descobrir quais vendas são
normalmente feitas ao mesmo tempo. Essa é a base da (possivelmente falsa)
anedota das fraldas e das cervejas.

Análise de regressão: Um método estatístico de fazer análises/prognósticos de

séries temporais e também alguns aspectos do DM.

Análise/Prognóstico de séries temporais: uma complicada tecnologia que é usada

para dar progn ósticos estatisticamente precisos. É normalmente confundido com
predição ou com prognóstico, mas é muito mais difícil, e matematicamente
baseado.

Análise “what-if”: um método de fazer predição ou um simples prognóstico

baseado em uma variável colocada pelo usuário. Árvores de decisão: uma
tecnologia de DM que determina fatores causais classificados por sua importância
e apresentados no formato de árvore, compostos de raiz, ramos e níveis. Elas são
similares a gráficos de organização, com informações estatísticas apresentadas
em cada nó.

Associação: quando se considera um elemento de dado altamente relacionado

com outro, ou quando causa outro, falamos que eles são associados. A
Associação se refere a achar esses elementos associados. Repare que
Associação não significa, necessariamente, que um elemento de dado causa
outro.

Caixa Preta: qualquer tecnologia que não explica os resultados que gera. Os
usuários não podem descobrir como a resposta foi determinada. Isso faz com que
determinadas técnicas de DM sejam inadequadas para determinadas aplicações
de negócio.

CART: Um algoritmo de regressão estatística chi, usado para análises estatísticas

clássicas. Ele é que dá sustentação para as técnicas de Classificação e de
árvores de decisão. Pode ser usado para construir árvores de decisão, caso em
que pode ser usado o índice de Gini também. Efetivamente, o CART pode
processar apenas valores numéricos.

CHAID: um algoritmo híbrido que enxerta uma fórmula estatística chi dentro do
AID (heurística), na tentativa de tratar tanto numéricos quanto simbólicos.
Enquanto o CHAID é confiável, ao mesmo tempo é muito lento e limitado quanto
ao seu poder.

C4.5: um algoritmo de DM que foi desenvolvido a partir do ID3, ID4 e ID6. Ele
trabalha bem tanto com valores numéricos como simbólicos. Data Mining (ou
Mineração de Dados): A detecção automática de tendências e associações
“escondidas” nos dados. O DM é parte de um grande processo chamado
“knowledge discovery”. Pode ser também descrito como a aplicação de técnicas
de machine learning em aplicações de negócio.

Descoberta: encontrar tendências e associações escondidos no dado. Estatística:

baseada em matemática avançada, a estatística é uma das estruturas básicas do
DM. Não deve ser confundida com heurística, que estuda fórmulas não
matemáticas.

Fator causal: qualquer elemento de dado que conduz, influencia ou causa outro
elemento. Por exemplo, se limite de crédito do consumidor pode dizer quão
rentável um consumidor pode ser, então ele é um fator causal. Veja fator
discriminante.

Fator discriminante: uma medida de quão importante um fator causal é, usado

pelas árvores de decisão para construir a árvore.
Fraldas e Cervejas: uma anedota popular que descreve o poder do DM. A anedota
(de veracidade duvidosa) conta que uma grande rede de supermercados usou o
DM para descobrir que clientes sempre compravam fraldas e cervejas ao mesmo
tempo. Isso encorajou o varejista a colocar os dois itens juntos na prateleira,
incrementando a venda de ambos.

Gini: um moderno algoritmo de índice para árvore de decisão que foi desenvolvido
por Ron Bryman. Ele lida tanto com números quanto com texto, e oferece boa
velocidade de processamento.

Heurística: Fórmulas que são baseadas nos princípios da Inteligência Artificial,

como a teoria da entropia, não se atendo aos princípios estatísticos. Foram os
primeiros algoritmos que processaram com sucesso valores textuais (também
chamados de simbólicos).

Indução de regras: um método de executar descobertas induzindo regras sobre o

dado. Esse método testa valores dados num grupo de dados para ver quais outros
dados são os seus fatores fortemente associados. Inteligência Artificial (IA): O
antepassado do DM. É baseado em heurística renegando a estatística. Algumas
técnicas de IA foram adotadas em SGBDs e em aplicações militares e científicas.
Na medida que amadureceu e se expandiu encampando a estatística, passou a
ser conhecida como machine learning.

ID3: O primeiro algoritmo que foi desenhado para construir árvores de decisão. Foi
inventado por Ross Quinlan, na Universidade de Sydnei, Austrália. O ID3 foi
seguido pelo ID4, ID6 e see5.

Janela ou nível de confiança: uma medida estatística de quão certo alguém pode
estar que determinado resultado é correto. A janela ou nível descreve o quão
próximo o valor está de ser o resultado exato.

Machine Learning: Na medida em que a IA progrediu, ela incorporou tecnologias

oriundas da estatística clássica. Esse “casamento” produziu avanços tecnológicos
proveitosos, e passou a ser conhecido como Machine Learning.

Modelagem: Construção de um modelo que descreve as tendências e

associações descobertas. Esse modelo permite que os usuários explorem as
tendências e associações para entende-las melhor.

Overfitting: a tendência de misturar ruído nos dados na previsão de tendências.

Por exemplo, certos erros tipográficos que são freqüentemente feitos durante a
entrada de dados podem ser modelados pela ferramenta de DM.

Particionamento: a escolha de dados que são mais interessantes para minerar.

Isso é tipicamente pelos menos oitenta por cento do trabalho de DM.
Predição: usar dados existentes para predizer como outros fatores se
comportarão, assumindo que determinados fatos são sabidos a respeito do novo
fator. Fazer uma checagem de crédito de novos clientes usando dados dos
clientes existentes é um exemplo de predição.

Prognóstico: Adaptação das técnicas de DM para predizer tendências futuras com

confiança estatística. É comumente confundido com predição, mas é normalmente
muito mais complexo.

Redes Neurais: Uma altamente poderosa mas complicada tecnologia de DM, que
tenta imitar as complexas funções de raciocínio do cérebro. O principal problema
com as redes neurais é que as ferramentas não explicam como elas determinaram
os seus resultados. Uma outra limitação é que apenas profissionais especializados
podem usa-las produtivamente. See5: A mais recente das séries Quinlan dos
algoritmos da árvore de decisão.

Segmentação: Uma descrição exata do grupo alvo encontrado pelo DM. É

extremamente útil para marketing e aplicações que requerem uma descrição
precisa de certos grupos de clientes.

Significância estatística: uma medida estatística de que um dado valor numérico é

correto.

Simbólicos: dados em formato de texto, com ASCII ou varchar.

Verificação: o uso de uma tecnologia ou ferramenta substituta para verificar os

resultados de uma outra tecnologia ou ferramenta de DM. Por exemplo, a análise
OLAP pode ser usada para verificar resultados de DM.

Visualização: Apresentação de resultados ou passos intermediários de DM em

formato visual, como gráficos, de maneira que os usuários podem ver os padrões.

5 - Referências Bibliográficas:

ANDREATTO, Ricardo - CONSTRUINDO UM DATA WAREHOUSE E

ANALISANDO SUAS INFORMAÇÕES COM DATA MINING E OLAP - Faculdade
de Ciências Administrativas Valinhos, SP

DAL’ALBA, Adriano. Site sobre Data Warehouse. UFRJ

Data Mining Techniques - site na Internet –

www.pcc.qub.ac.uk/tec/courses/datamining/stu_notes.htm

Tecnologias de Data Warehouse e OLAP – Instituto de Computação da Fundação

CTI
Stage (ETL)

Esta etapa é uma das fases mais críticas de um Data Warehouse, pois envolve a
fase de extração dos dados dos sistemas transacionais ou de outras fontes
(planilhas, arquivos textos), a fase de Filtragem que consiste basicamente em
garantir a integridade dos dados e, por fim, a fase de Carga dos Dados no Data
Warehouse.

Quando os dados são movidos de sistemas transacionais para o ambiente de

Data Warehouse, parece que nada além de simples extrações de dados de um
local para o outro está ocorrendo. Em virtude desta enganosa simplicidade, muitas
vezes as empresas acabam perdendo tempo e dinheiro por ter que refazer toda
esta parte de extração.

O processo de carga dos dados passa por três etapas: extração, filtragem e a
carga propriamente dita.

Extração

A extração de dados do ambiente operacional para o ambiente de data warehouse

demanda uma mudança na tecnologia. Pois muitas vezes os dados são
transferidos de um banco de dados hierárquico, tal como o ADABAS, para uma
nova tecnologia de SGBD para Data Warehouse, tal como o IQ da Sybase.

A seleção de dados do ambiente operacional pode ser muito complexa, pois

muitas vezes é necessário selecionar vários campos de um sistema operacional
para compor um único campo no data warehouse.

Os dados são reformatados. Por exemplo: um campo data do sistema operacional

do tipo DD/MM/AAAA pode ser passado para o outro sistema do tipo ano e mês
como AAAAMM .

Podem existir várias fontes de dados diferentes para compor uma informação. Ela
pode ser oriunda de uma planilha excel, enquanto uma outra que serviria para
compor um mesmo fato viria de um arquivo texto.

Quando há vários arquivos de entrada, a escolha das chaves deve ser feitas antes
que os arquivos sejam intercalados. Isso significa que, se diferentes estruturas de
chaves são usados nos diferentes arquivos de entrada, então deve-se optar por
apenas uma dessas estruturas.

Os arquivos devem ser gerados obedecendo a mesma ordem das colunas

estipuladas no ambiente de data warehouse.

Podem haver vários resultados. Dados podem ser produzidos em diferentes níveis
de resumo pelo mesmo programa de criação do data warehouse.
Valores padrões devem ser fornecidos. As vezes pode existir um campo no data
warehouse que não possui fonte de dados, então a solução é definir um valor
padrão para estes campos.

O data warehouse espelha as informações históricas necessárias, enquanto o

ambiente operacional focaliza as informações correntes.

Filtragem dos Dados

Após a definição de como deverão ficar os dados no data warehouse, há a

necessidade de filtragem dos dados para colocá-los no padrão definido. Por
exemplo: Em um sistema operacional eu tenho o campo de sexo sendo
preenchido como F ou M, e em um outro sistema eu tenho este mesmo dado
sendo preenchido com 0 ou 1. É justamente, nesta hora que entra a parte de
filtragem, que seria transformar todos estes dados para o padrão definido, que no
exemplo seria F ou M.

Carga dos Dados

A parte de Integridade dos dados. No momento da carga é necessário checar os

campos que são chaves estrangeiras com suas respectivas tabelas para certificar-
se de que os dados existentes na tabela da chave estrangeira estão de acordo
com a tabela da chave primária.

Se a tabela deve receber uma carga incremental ou a carga por cima dos dados.
A carga incremental normalmente é feita para tabelas fatos, e a carga por cima
dos dados é feita em tabelas dimensões, onde o analista terá que deletar os
dados existentes e incluí-los novamente.

Apesar de existirem ferramentas de Carga como o DTS (Data Transformation

Service), ainda tem-se a necessidade de criar rotinas de carga para atender
determinadas situações que poderão ocorrer.

METADADOS

Um importante aspecto do ambiente de Data Warehouse (DW) diz respeito aos

metadados. Metadados são dados que fazem referência a outros dados ou,
segundo Inmon, os metadados mantêm informações sobre "o que está e onde" no
ambiente de DW.

No Data Warehouse os metadados assumem um papel de grande importância.

Duas comunidades diferentes são atendidas por dados operacionais e dados do
Data Warehouse. Os dados operacionais são utilizados por profissionais de TI e
usuários especializados, versados em computadores e capazes de se localizar
nos sistemas em função de seu treinamento e experiência. Todavia, o Data
Warehouse atende à comunidade de usuários de negócio, com funções táticas e
gerenciais (Analistas de Suporte à Decisão - SAD). O analista de SAD é,
geralmente, acima de tudo, um profissional especializado em uma determinada
área de negócio. Na comunidade de analistas de SAD, não há, normalmente, um
alto grau de especialização em computadores. Os analistas de SAD precisam de
tanta ajuda quanto possível para usar eficientemente o ambiente de Data
Warehouse, e os metadados se prestam muito bem para este fim.

Todas as fases de um projeto de Data Warehouse, desde o levantamento de

requisitos até a visualização da informação, geram metadados. Tipicamente, os
aspectos sobre os quais os metadados mantém informações são:

-A estrutura de Dados segundo a visão tecnicista;

-A estrutura de Dados segundo a visão de negócios;
-A fonte de dados que alimenta o DW;
-A transformação sofrida pelos dados no momento de sua migração para o DW;
-O modelo de dados;
-O histórico das extrações de dados;
-Informações referentes a relatórios gerenciais;
-Informações referentes às camadas semânticas;
-Informações referentes aos processos de Carga.

Estas informações são úteis tanto para quem mantém e desenvolve o ambiente,
como para os que usufruem dele como fonte de dados gerenciais. Entretanto,
como existem várias ferramentas concorrentes para as várias fases de um projeto,
não existem sistemas que consigam colocar todos os metadados gerados em um
único repositório central. Essa deficiência, e lacuna no mercado de software, faz
com que o desenvolvimento, gerenciamento, manutenção e utilização do Data
Warehouse fiquem comprometidos.

Grandes corporações sofrem com a ausência de um ambiente de metadados.

Dentre os todos os problemas podemos citar

1 - Os metadados são inacessíveis ao usuário de negócio

Na maioria dos casos, os usuários de negócio não possuem meios de acessar os

metadados sobre o ambiente de informações que utilizam. Meta informações
contidas no modelo de dados e na ferramenta OLAP são pouco utilizadas e, de
certa maneira inacessíveis aos usuários finais.

2 - Os metadados estão armazenados em ambientes distintos

Os metadados são armazenados em repositórios de dados e em arquivos

propietários das diversas ferramentas que compõem o Warehouse. Informções
que poderiam ser integradas e relacionadas, ficam pulverizadas no ambiente
informacional da empresa.

3 - Usuários de Negócio são dependentes da área de Tecnologia

Por não conhecer em sua totalidade a camada semântica da ferramenta OLAP e a
origem e estruturação dos dados do DW, constantemente os usuários de negócios
interpelam os técnicos e analistas da área de desenvolvimento sobre o conteúdo,
a origem, a fórmula de cálculo de determinados objetos gerenciais.

4 - Inexistência de Interfaces de Entrada de Metadados de ETL

Em empresas que optaram por não adiquirir ferramentas de ETL, partindo para o
desenvolvimento de processos de carga propietários, não existe interface ou
aplicativo que permita o vínculo de metadados aos processos de carga.
Consequentemente, o ambiente de ETL não está documentado e, portanto, torna-
se uma "área cega" do ambiente de Warehouse.

5 - Dificuldade de manutenção de Relatórios e Camadas Semânticas

A alteração de tabelas e atributos no modelo de dados, reflete nos Universos e

relatórios. Quando isso ocorre, relatórios e camadas semânticas que funcionavam
corretamente passam a não funcionar, ou a trazer dados incorretos para a
máquina do usuário de Negócios. A necessária iteração entre as equipes de
Modelagem e da ferramenta OLAP não existe, e manutenções preventivas no
ambiente para prever erros deste tipo não ocorrem.

6 - Dificuldade de mapeamento de dados entre o Data Warehouse e os Sistemas

Operacionais

As alterações, filtragens, resumos, conversões e alterações estruturais, que

ocorrem sobre os dados dos sistemas operacionais quando são transferidos para
o DW não são disponibilizados aos usuários de negócio e técnicos. Quando um
gerente necessita rastrear dados do Data Warehouse em sua fonte operacional,
leva-se muito tempo para se obter a resposta.

7 - Sub-utilização do Ambiente de Informações Gerenciais

Analistas de suporte à decisão, técnicos, analistas de sistemas e usuários de

negócio, tem dificuldade para conhecer todo o dado armazenado no warehouse.
Este conhecimento é vital para que informações valiosas ao negócio da empresa
sejam extraídas do ambiente. Desta forma, um ambiente que poderia ser frutífero
para a organização em termos de geração de informações, fica sub-utilizado.

8 - Alterações das Estruturas e Definições de Dados não são acompanhadas

Ao contrário dos sistemas operacionais, que não têm como preocupação o

armazenamento histórico de dados e que têm como pressuposto que só há uma
definição correta para os dados, o Data Warehouse necessita armazenar séries
históricas que variam de 5 a 10 anos. Durante este período, a dinâmica do
negócio da empresa impõe uma série de modificações organizacionais que devem
ser refletidas em seus modelos dados. Estas modificações precisam ser
armazenadas, e gerenciadas de maneira correta.

9 - Impossibilidade de se mensurar a utilização do ambiente

Uma das características de um Data Warehouse é a exigência de vasto espaço

em disco e de janelas amplas de produção. Estes recursos são extremamente
caros e escassos na empresa e, por isso, necessitam ser utilizados com
inteligência. Em diversas empresas não se consegue determinar se todos os
atributos e tabelas do modelo estão sendo utilizados e, como conseqüência, os
recursos de produção acima citados são utilizados em partes do modelo que não
são utilizadas.

10 - Visão não integrada da empresa

Por incrível que possa parecer, grandes empresas não tem uma visão unificada
sobre seus objetos corporativos. Cada unidade analisa a estrutura organizacional,
o cliente e os produtos de forma diferenciada. Isso ocorre devido às periódicas
mudanças dessas estruturas em razão de forças políticas ou mercadológicas.
Dessa maneira, as relações entre sistemas e unidades organizacionais distintas
fica muito comprometida, acarretando muitas vezes na geração de informções
incorretas para tomada de decisões, uma vez que não existem conceitos
corpoativos sobre objetos utilizados por toda corporação.