Data Warehouse

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, aonde 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, aonde 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 Intelligence eficiente.
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 fonte 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 diferente
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, e é muito
válida.

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 3.1 precisam necessariamente ser averigüadas, 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.
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
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.
Vejamos 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 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:
Business Objects – site na Internet – www.businessobjects.com
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
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
Por Daniel Fujiwara
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.
Metadados
Os Metadados são um dos tópicos mais interessantes e , de certa forma, confusos do ambiente do Data
Warehouse. Interessantes por serem os dados de controle de um projeto de DW. Confusos por não
terem uma definição muito clara para a maioria das pessoas. Metadados são dados que fazem
referência a outros dados. Por exemplo, um catalogo telefônico pode ser considerado um catalogo de
metadados por fazer referência a dados pessoais, no caso telefones e nomes. Outro exemplo prático é o
da biblioteca de livros. Quando visitamos uma à procura de algum livro ou de algum autor, fazemos uso
de um catalogo bibliográfico, que contém dados de todos os títulos disponíveis, como autor, editora e
número de páginas.
Todas as fases de um projeto de Data Warehouse, desde a modelagem até a visualização da
informação, geram metadados. Neles estarão contidos informações como atributos das tabelas,
agregadas utilizadas, cálculos necessários, descrições, periodicidade das cargas, histórico de mudançs
etc... .
Existem no mercado ferramentas que já são capazes de armazenar e gerenciar (Sybase Warehouse
Control Center e Prism Warehouse Directory) alguns tipos de metadados, apesar disso ainda não foi
estabelecido um padrão de armazenagem e gerenciamento pelo mercado.
Segundo Inmon, os metadados mantêm informações sobre "o que está e onde," no DW. Tipicamente os
aspectos que sobre os quais os metadados mantêm informações são:
 A estrutura dos dados, segundo a visão do programador;
 A estrutura dos dados, segundo a visão dos analistas de SAD;
 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 relacionamento entre o modelo de dados e o DW;
 O histórico das extrações de dados.
Área de Stage
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.
Metodologia de Levantamento
Apesar de serem displicentemente ignoradas em muitos Data Warehouses, as metodologias de
levantamento de dados gerenciais são indispensáveis ao sucesso de um Sistema de Apoio à Decisão
que pretende atender às necessidades do usuário de negócio.
Quando se fala em DW, muitos profissionais da área de TI pensam logo em construir rotinas de extração
de dados dos sistemas legados para posterior carga num modelo dimensional, em detrimento de um
entendimento das necessidades dos entendedores de negócio.
Para tal entendimento, foram criadas metodologias de levantamento de dados Gerenciais, como a JAD
(www.ibm.com) e o DMD (www.owg.com.br) , que são baseadas em reuniões de trabalho, onde os
participantes, orientados por um profissional com prática nesta etapa, extraem conhecimentos sobre o
“negócio”.
Basicamente, as metodologias funcionam através de “Brain Storms” conduzidos por um Facilitador. As
missões dos Departamentos envolvidos (conhecida também como Fator crítico de sucesso), questões
gerenciais e as informações que as respondem são levantadas, originado assim os objetos de negócio.
Além dessas questões e respostas, também são levantadas a ciclicidade e o tempo de permanência dos
dados na base do Data Warehouse.
Necessariamente, ao aplicar a metodologia, a única preocupação é com termos e questões gerenciais.
Alguns profissionais aplicam esta etapa já pensando na base de dados, com suas dimensões e fatos,
causando assim confusão na cabeça dos entendedores do negócio e uma maior possibilidade de falhas
na modelagem posterior.
Em alguns casos, quando aplicada a todos departamentos de uma empresa, a metodologia provoca
fenômenos interessantes como a descoberta de processos e análises redundantes, fazendo com que a
própria corporação seja otimizada.
Portanto, fica clara a necessidade de se implementar uma metodologia de levantamento de dados
gerenciais, antes de se iniciar a implantação física de um Data Warehouse. Além de gerar como produto
um SAD bem estruturado e modelado, esse procedimento também pode ser muito benéfico para a saúde
organizacional da empresa.
FAQ
Estamos colocando em nossa seção de FAQ’s, questões comumente elaboradas por profissionais e
estudantes da área de TI. Envie também suas perguntas, para que possamos enriquecer nosso Site.
Qual a abrangência de um projeto de Data Warehouse? A empresa como um todo? Somente
alguns Departamentos?
Dependendo da demanda do cliente podemos abranger a empresa inteira, ou seja, um Data Warehouse
completo. No caso de apenas alguns departamentos serem contemplados, adotamos a estratégia de
desenvolver Data Mart’s para cada um, mas sempre com a preocupação de compartilhar dados, tabelas,
relatórios em comum entre os departamentos, evitando assim redundância.
Qual a plataforma de hardware? Qual a quantidade de memória principal? E Disco rígido?
Existem vários processadores?
Tudo isso depende do tamanho do projeto. Trabalhamos num projeto de Data Warehouse ,de uma
grande Instituição Financeira brasileira, que utiliza uma máquina Sun com 19 processadores e espaço
alocado em disco para 10 Tera Bytes de Dados. Em outros projetos menores encontramos servidores
Intel-Pentium com 10 Giga de Espaço.
Qual o SGBD utilizado? Alguma razão especial na escolha ?
O melhor SGBD para Data Warehouse do mercado é o Sybase IQ . Ele possui características que
otimizam consultas em até 100 % , dependendo da referência. Outro dado importante é que ele pode
comprimir em até 70 % dados brutos, ou seja, se você enviar um flat-file (arquivo texto oriundo das bases
dos sistemas de origem) de 1 Gb, ele pode comprimir esses dados para até 300 Mb.
Qual o software de extração de informações(data mining)?
A princípio temos que distinguir extração de visualização. Data Mining é uma das técnicas de
visualização e análise de informações. Através dele podemos detectar comportamentos e tendências
que ficam “escondidos” e que só podem ser descobertos através dos algoritmos de Mining. Embora a
técnica de Mining seja a mais famosa no que diz respeito à visualização de dados, ela não é a mais
utilizada. É muito mais comum encontrar softwares OLAP, que possibilitam análise multidimensional e
Drill.Chamamos de extração de dados o ato de coletar dados nos sistemas transacionais (legados) para
posterior adição no Data Warehouse. Para esta tarefa utilizamos outros softwares como o Power Stage
(Sybase) e o DTS (Microsoft).
Qual a ordem do investimento?
Isso depende do tamanho do projeto. Em grandes projetos presenciamos investimento da ordem de até
2 milhões de Reais, isso inclui software, máquina e consultoria. Também encontramos projetos de
pequenos Data Marts, que utilizam principalmente solução Microsoft, onde são gastos no máximo 10 mil
Reais.
Quais os benefícios que a empresa que coloca um Data Warehouse espera obter c/ o projeto?
Lucro: Em cima de uma única decisão, baseada num Data Warehouse bem estruturado, a empresa
pode ter o montante investido retornado. Credibilidade de Dados: Os dados de um Data Warehouse são
devidamente modelados e homologados, dando assim segurança ao analista de negócio.Velocidade:
Com um DW o analista pode ter a informação certa na hora certa.
Quais são as principais dificuldades p/ a condução e evolução do projeto?
Um Data Warehouse é composto por várias variáveis. Podemos citar algumas como Metodologia,
Modelagem, ETL (Extração, Filtragem e Carga), Visualização de Dados, Consultoria, Hardware e
Ferramentas. Cada variável citada acima é extremamente importante, e qualquer falha em cada uma
delas pode levar o projeto à pique.Somos chamados em muitas empresas para consertar erros de
modelagem e para apresentar ferramentas que realmente solucionam o problema dos analistas de
negócios. Portanto, a maior dificuldade é manter a excelência dos serviços em todas as etapas do
projeto, pois todas são vitais.
Quando e quanto tempo leva para ser elaborado?
Um grande Data Warehouse leva de 6 a 12 meses. É importante salientar que os primeiros resultados
devem ser apresentados em 2 ou, no máximo, 3 meses, para que o usuário final possa sentir que o
investimento, geralmente alto, valeu à pena. Outro ponto importante é que, por ser uma ferramenta de
Business Intelligence, um DW deve responder às alternâncias do mundo externo e da própria
corporação, gerando assim o conceito de Data Warehousing, ou seja o Data Warehouse deverá sempre
estar em manutenção e otimização.