Compartilhe







Publicidade

background image
FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA
CENTRO DE PÓS-GRADUAÇÃO
CURSO DE GESTÃO DE TECNOLOGIA DA INFORMAÇÃO
Um Data Mart de seqüência de cliques da WEB
Luiz Eduardo Mainenti Pagnez
Monografia de Conclusão de Curso apresentada como
exigência parcial para obtenção do título de pós-graduação
Lato Sensu em Gestão de Tecnologia da Informação
Orientador: Prof. MS. Gutenberg A. Silveira
São Paulo
2002
background image
2
background image
3
Dedico este trabalho a todos os mestres da FIAP que compartilharam seus
conhecimentos e a minha família que sempre me apoiou.
background image
4
SUMÁRIO
SUMÁRIO ...................................................................................................................4
SUMÁRIO DE FIGURAS ............................................................................................5
RESUMO ....................................................................................................................6
ABSTRACT.................................................................................................................7
1- INTRODUÇÃO........................................................................................................8
2- JUSTIFICATIVA....................................................................................................10
3- DEFININDO O QUE É UM DATA WAREHOUSE E UM DATA MART .................13
4- DEFINIDO AS INFORMAÇÕES: A SEQÜÊNCIA DE CLIQUES DA WEB ...........24
5- MAPEANDO OS SISTEMAS PROVEDORES......................................................31
6- PROPOSTA DE ARQUITETURA .........................................................................33
7- MODELANDO OS DADOS...................................................................................35
8- FERRAMENTAS DE BANCOS DE DADOS .........................................................44
9- PROCESSOS PARA IMPLEMENTAÇÃO ............................................................53
10- CONCLUSÃO .....................................................................................................59
REFERÊNCIAS BIBLIOGRÁFICAS..........................................................................60
background image
5
SUMÁRIO DE FIGURAS
FIGURA 1 ­ EXEMPLO DE GRÁFICO MRTG DIÁRIO DE UTILIZAÇÃO DO
TRÁFEGO DA REDE.................................................................................................13

FIGURA 2 ­ EXEMPLO DE GRÁFICO MRTG SEMANAL DE UTILIZAÇÃO DO
TRÁFEGO DA REDE.................................................................................................13

FIGURA 3- PROPOSTA DE UTILIZAÇÃO DO DATA WEBHOUSE EM CONJUNTO
COM O SERVIDOR WEB..........................................................................................30

FIGURA 4 ­ EXEMPLO DE ARQUIVO DE LOG.......................................................33
background image
6
RESUMO
Neste trabalho é elaborada uma proposta para a implantação de um Data
Mart, que é um Data Warehouse orientado para um único assunto, ou departamento
da empresa. Este Data Mart tem como objetivo avaliar o comportamento dos
usuários de um site da internet, através dos arquivos de logs da seqüência de
cliques dos visitantes. O comportamento dos usuários será relacionado com as
transações comercias ocorridas no site e registradas no servidor de aplicativos do
sistema.
Para a construção dos conceitos de Data Warehouse e Data Mart da
seqüência de cliques, encontramos subsídios em Kimball e Inmon, que citam os
comportamentos que influenciariam no resultado comercial do site, tais como:
eventos de compra bem-sucedido, incompletos ou cancelados; localização, ou não,
das informações procuradas; e o grau de satisfação do usuário com o serviço, entre
outras possibilidades.
Serão discutidas questões de custo benefício, na construção deste Data Mart
e um modelo de dados adaptado da proposta de Kimball será sugerido. É proposta
também a infra-estrutura necessária para o projeto e, finalmente, é elaborado um
cronograma para implantação.
background image
7
ABSTRACT
In this work is presented a proposal for a Data Mart implantation, that is a Data
Warehouse focused in a specific subject or belong to an enterprise department. This
Data Mart have the objective to evaluate the behavior of web-site users, through click
stream data in the web server's logs files. The behavior of this users will be linked
with the commercial transactions made in the web site by the visitors and stored in
the system's application server.
To describe the Data Warehouse and Click Stream Data Mart concepts, we
find support in Kimball and Inmon, who mention how the user's behaviors can
contribute in the commercial result of the web-site, such as: complete, incomplete or
canceled buying events; successful localization of searched information's; and the
users satisfaction degree, for example.
Questions about cost justification will be discussed in this Data Mart
implementation. A data model will be suggested based in Kimball's work. Also will be
suggested the infra-structure needed to build this project, and finally, a timetable for
implementation is proposed.
background image
8
1- INTRODUÇÃO
Os sistemas de informações constituem-se em uma ferramenta estratégica
para as empresas que pretendam manter-se ou assumir uma posição de destaque
no nicho de mercado em que atuam. Para outras empresas é uma questão de
sobrevivência conhecer e utilizar as tecnologias mais modernas.
Este trabalho descreverá uma proposta para a implantação de um Data Mart
que visa acompanhar o comportamento dos usuários de um site
1
da Internet.
Definimos como escopo deste projeto então, o que chamamos daqui em diante de
Data Mart de seqüência de cliques. A organização a que se destina este sistema
seria uma empresa hipotética de Recursos Humanos chamada "JOB's"
2
. Por ter
experiência de trabalho como Webmaster de um site como este, nota-se o grande
valor de conhecer melhor o comportamento de seus clientes e visitantes, e
conseqüentemente poder oferecer melhores serviços e produtos para o mercado.
A empresa em questão implantou uma estrutura de e-commerce
3
em seu site
da Internet, oferecendo serviços de recrutamento e recolocação on-line para os
consumidores de todo o Brasil através de um serviço de assinaturas aonde os
clientes podem ter acesso a anúncios de vagas de emprego e divulgar seus
currículos. Devido ao grande sucesso deste projeto e ao crescente aumento no
número de visitas, é muito importante conhecer melhor estes visitantes e oferecer
cada vez mais serviços diferenciados que agreguem valor e fidelizem os clientes.
Neste trabalho será feita uma revisão teórica sobre os conceitos que
envolvem a implantação de um Data Warehouse e um Data Mart, estruturado para
1
Site ­ conjunto de páginas sob um mesmo domínio na Internet
2
Esta é uma empresa fictícia utilizada neste trabalho apenas para fins acadêmicos
3
E-commerce ­ comércio eletrônico: venda de produtos ou serviços por meios eletrônicos
background image
9
suprir informações para suporte a decisões gerenciais, sobre o projeto do site na
Internet e o comportamento de seus usuários.
background image
10
2- JUSTIFICATIVA
Usualmente construído em um sistema de gerenciamento de banco de dados
relacional (RDBMS)
4
, o Data Warehouse, que será definido na seção seguinte,
destina-se a liberar sistemas de processamento analítico da missão crítica das
consultas que consomem recursos de processamento. Esses Data Warehouse's
contêm dados que foram extraídos, limpos e transformados a partir de sistemas de
transações de processos. Consistem de uma coleção on-line de informações
corporativas que serão utilizadas para fins de suporte a decisão. Ele posiciona as
empresas para atender algumas grandes exigências:
Preparar seus sistemas e os usuários para uma evolução
constante;
Melhorar a contribuição de cada funcionário da
produtividade e na receita; entre os lucros desempenhando os
principais processos do negócio de forma melhor que os competidores
e eliminando o maior número possível de práticas consumidoras de
recursos;
Aplicar ciência à informação.
Possivelmente, a explosão de informações seja a ocorrência que afeta o Data
Warehouse de forma mais significativa. Segundo a bibliografia estudada, as
organizações perceberam que, dada a relação fundamental entre conhecimento e
poder, o uso dessas informações é imprescindível para sua vantagem competitiva.
O uso de um Data Warehouse para processamento de informações está
associado a consideráveis benefícios de custo, economia de tempo e aumento de
produtividade. Os dados podem ser acessados e analisados facilmente sem perda
4
RDBMS ­ Relational Data Base Management System
background image
11
de tempo com manipulação e processamento. Decisões podem ser tomadas mais
rapidamente e com a certeza de que os dados são atuais e precisos. Informações
integradas podem ser mantidas em categorias que representam operações
lucrativas. As tendências ao longo do tempo, podem ser analisadas e previstas com
a disponibilidade de dados históricos. Ele garante também que todos estejam
usando os mesmos dados no mesmo nível de extração, o que elimina resultados
analíticos conflitantes e argumentos a respeito da fonte da qualidade dos dados
utilizados. Em resumo, ele permite que as informações sejam processadas de forma
confiável e eficiente.
A empresa foco deste trabalho enfrenta a difícil tarefa de remodelar sua
arquitetura de informação de forma a alavancar o seu processamento analítico
(OLAP
5
), sem corromper, seus sistemas de processamento de transações on-line
(OLTP
6
). Como primeiro passo para alavancar o processamento analítico, será
começar implantando um Data Mart da Seqüência de Cliques ao invés de um caro e
complexo Data warehouse. Inmon [6] sugere até uma série de testes para avaliar e
justificar o custo de se implantar um complexo Data Warehouse ou quando é melhor
se começar com Data Marts departamentais, correndo o risco de se criar vários
sistemas incompatíveis pela organização.
Conforme pode se observar pelos gráficos de acesso nas figuras 1 e 2, este
site hipotético apresenta um grande volume de dados sendo distribuídos, neste
caso, tal volume corresponde a uma visitação média entre 30.000 e 50.000 visitantes
únicos por dia. Um sistema para interagir on-line com estes usuários pode facilmente
se tornar inviável à medida que o número de visitantes do site crescer. Portanto
5
OLAP ­ Online Analitycal Processing
6
OLTP ­ OnLine Transaction Processing
background image
12
seria de grande benefício para a empresa que o processamento analítico seja feito
em lote durante a madrugada, aonde o tráfego diminui, e o resultado das sessões
dos usuários armazenados neste Data Mart, criando também como sugere Kimball
[8], um sistema de cachê de respostas automáticas para interagir com os visitantes
on-line.
Figura 1 ­ Exemplo de gráfico MRTG7 diário de utilização do tráfego da rede
no site.
Figura 2 ­ Exemplo de gráfico MRTG8 semanal de utilização do tráfego da
rede no site.
7
MRTG ­ Multi Routing Traffic Graphics
8
MRTG ­ Multi Routing Traffic Graphics
background image
13
3- DEFININDO O QUE É UM DATA WAREHOUSE E UM DATA MART
Para compreender o que é e quais são as funcionalidades de um sistema de
Data Warehouse e de Data Mart, iremos retornar às definições dadas por Singh e
Inmon em vários trabalhos [4, 5, 6, 7, 10].
Começando com Singh [10], temos que Data Warehouse é o processo de
integração dos dados corporativos de uma empresa em um único repositórios a
partir do qual os usuários finais podem facilmente executar consultas, tirar relatórios
e fazer análises. O mundo do Data Warehouse é um ambiente de suporte a decisão
que alavanca dados armazenados em diferentes fontes e os organiza e entrega aos
tomadores de decisões da empresa, independente de plataforma que utilizam ou de
seu nível de qualificação técnica. Resumindo Data Warehouse é uma tecnologia de
gestão e análise de dados.
O primeiro critério sobre o qual estes autores concordam para uma definição
é que os Data Warehouse's armazenam dados no formato read-only (somente para
leitura). De fato, esta é a primeira regra do Data Warehouse. A teoria por trás disso é
que os bancos de dados normais armazenam dados das operações de negócios e
que muitas das aplicações de suporte a decisão associadas ao Data Warehouse
exigem muito dos bancos de dados que os executam. Além disso, para termos o
Data Warehouse precisamos que o sistema colete informações de várias fontes
diferentes e as utilize em um local em que essas diferenças se tornem compatíveis,
pois queremos também permitir que vários aplicativos usem as mesmas
informações.
O Data Warehouse é uma ferramenta competitiva que permite a qualquer
usuário final acessar dados da empresa inteira com qualidade. Ao arquivar dados
em um ponto de armazenamento central, o Data Warehouse oferece uma
background image
14
representação integrada das múltiplas fontes de informações da empresa. Ele
garante a consistência das normas de gerenciamento e das convenções aplicadas
aos dados. Portanto, o Data Warehouse reflete as necessidades da corporação, não
simplesmente as individuais. Singh cita a seguinte definição de Inmon[10]:
"Data Warehouse é um conjunto de dados orientado por
assunto, integrado, variável com o tempo e não volátil, que
fornece suporte ao processo de tomada de decisão do
negócio".
Orientados por assuntos significa que ele enfoca as principais entidades do
negócio. Integrado significa que os dados estão armazenados em um formato
consistente, deverá haver apenas um esquema de codificação. Variável com o
tempo significa que os dados estão associados a um ponto no tempo, e não volátil
significa que os dados não mudam depois de incluídos no Data Warehouse.
Data Mart é um sub-conjunto do Data Warehouse da empresa inteira.
Tipicamente, desempenha o papel de um Data Warehouse departamental, regional
ou funcional. Como parte do processo interativo do Data Warehouse, a empresa
pode construir uma série de data marts ao longo do tempo e eventualmente ligá-los
através de um Data Warehouse lógico da empresa inteira. Os dados podem estar
descritos em esquemas chamados de "estrelas" ou estruturas parecidas com "flocos
de neves" (snowflake structure), que seriam estrelas nas pontas de cada estrela [5].
Data Warehouse lógico
Contém todos os metadados (descritos mais adiante), regras de negócio e o
processamento lógico necessário para selecionar, organizar, agrupar e pré
processar dados. Atualmente, contêm as informações requeridas para encontrar e
acessar os dados, onde quer que eles estejam.
background image
15
Os Data Warehouse's podem funcionar como um repositório central para
grandes quantidades de informações diversificadas e valiosas. Eles são uma grande
fonte de informações para sumários e tabelas usadas no suporte do processamento
analítico on-line (OLAP). A capacidade para usar as informações do processo de
tomada de decisão depende de se ter as ferramentas apropriadas para extrair dados
específicos, converter as informações do negócio e monitorar as mudanças. O
problema não está mais na falta de dados, mas sim como procurá-los na gigantesca
quantidade de dados e informações úteis.
A solução está no uso inteligente de softwares que possam automatizar a
tarefa de extrair informações de detalhes e apresentá-las em termos de negócio,
fornecendo não só informações resumidas, mas também ter capacidade para
apresentar níveis de detalhe, desenvolver previsões e exportar informações para
outras ferramentas de suporte a decisão. Ao usar ferramentas para coletar,
organizar e extrair as informações mais recentes e úteis, grandes quantidades de
dados podem ser convertidas de informação em discernimento.
Estrutura de um Data Warehouse
Ainda segundo Singn [10] estes são os componentes que descrevem o Data
Warehouse:
Dados atuais;
Dados antigos;
Dados sumarizados;
Metadados.
Dados atuais
Eles são o que exigem mais atenção, pois refletem os acontecimentos mais
recentes, sempre de grande interesse. São volumosos porque estão armazenados
background image
16
no menor nível de granularidade. São armazenados em disco, facilitando o acesso,
porém torna o gerenciamento complexo e mais caro.
Dados antigos
Estes são geralmente os acessadas com menor freqüência e armazenados
em um nível de detalhe consistente com o detalhe dos dados atuais. Embora não
seja imprescindível o armazenamento em um meio alternativo, devido ao grande
volume de dados conjugados, o meio de armazenamento recomendado por Singn
para dados antigos é usualmente o removível, tal como uma biblioteca de fitas.
Dados sumarizados
Podem ser divididos em dois tipos:
Ligeiramente sumarizados: são encontrados no nível atual
de detalhe, extraídos do nível mais baixo. Esse nível é quase sempre
armazenado em disco;
Altamente sumarizados: são compactos e de fácil acesso.
Às vezes estes dados são encontrados dentro do ambiente do Data
Warehouse e às vezes em um ambiente externo.
Metadado
Este é citado como o componente mais importante do Data Warehouse.
Contém "dados sobre os dados". Sob muitos aspectos, situa-se em uma dimensão
diferente dos outros dados, porque não são retirados diretamente do ambiente
operacional. Resumindo: são todas as coisas relacionadas ao conteúdo dos dados
que permitem as pessoas entenderem como metadado foi criado e como é mantido.
Seu papel é mais importante do que aquele que desempenhava no ambiente
operacional clássico. Ele é usado como:
background image
17
Um diretório que ajuda a localizar o conteúdo do Data
Warehouse ;
Um guia para o mapeamento dos dados à medida que
estes são transformados do ambiente operacional para o ambiente do
Data Warehouse ;
Um guia para algoritmos usados para a sumarização
entre os dados atuais e os dados sumarizados.
O metadado contém informações sobre:
Estrutura dos dados;
Algoritmos usados para sumarização;
Mapeamento do ambiente operacional para o ambiente do
Data Warehouse.
Antes que os dados do Data Warehouse possam ser acessadas com
eficiência, é necessário entender quais dados estão disponíveis no Data Warehouse
e onde estão localizados. O metadado fornece um catálogo dos dados do Data
Warehouse e os indicadores e ponteiros para estes dados. Além de ajudar a
localizar os dados, podem conter:
Histórico da extração e transformação de dados;
Estatística de uso de dados;
Tamanho de tabelas;
Identifica autores de colunas;
Algoritmos de sumarização e modelagem de dados.
Em uma arquitetura bem projetada, eles mantêm entidades como as
dimensões, atributos e medições, para tabelas e colunas dentro do Data Warehouse
.Especificamente, incluem:
background image
18
Hierarquia de atributos;
Atributos para dimensões;
Mapeamento físico de atributos e medições;
Medições de desempenho.
Em uma implementação típica, a aplicação do Data Warehouse está acoplada
via o metadado, permitindo que as mudanças feitas no Data Warehouse sejam
refletidas imediatamente na aplicação do usuário final de acesso aos dados. Por
exemplo, se uma corporação se reestrutura e elimina um nível gerencial, logo que os
dados correspondentes à nova hierarquia organizacional são adicionados ao Data
Warehouse a aplicação deve reconfigurar-se usando metadado para refletir a nova
hierarquia.
Funções do Data Warehouse
O fluxo de dados da origem ao usuário inclui recursos de gerenciamento e
implementação. O Data Warehouse deve acessar os dados operacionais e externos,
transformar estes dados limpando, reconciliando, aprimorando, sumarizando e
agregando. Deve distribuir as informações, organizar, combinar de múltiplas fontes e
popular sob demanda. Deve armazenar cachês especializados e de múltiplas
plataformas. Localizar, por catálogos de informações, visualização de negócios e
modelos. Por último, apresentar análise dos dados, através de consultas e relatórios,
análise multidimensional e data mining9.
Data Warehouse operacional
Há dois tipos básicos de dados em qualquer empresa, o primeiro chama-se
de dado operacional, que são aqueles que suportam diretamente as funções do
9
Data mining ­ garimpagem de dados - processo de pesquisar grandes volumes de relacionamentos de
dados. Uma técnica que usa ferramentas de sofware para procurar determinados padrões e tendências.
background image
19
negócio e para os quais é desenvolvida a maior parte dos aplicativos desde que a
programação orientada ao negócio tornou-se uma prática. O segundo tipo de dado
chama-se de dado informativo e são esses dados que suportam o processo de
tomada de decisões.
A força impulsionadora por trás da evolução do Data Warehouse é a
necessidade de obter acesso informativo, em oposição ao acesso operacional, aos
dados corporativos. Acesso operacional significa acesso atual de instâncias
específicas de dados, enquanto o acesso informativo implica em acesso a grandes
volumes de dados para análises elaboradas, planejamento e tomada de decisão.
Diferenciar dados operacionais de informativos requer um critério de projeto
fundamentalmente diferente para o banco de dados operacional e o banco de dados
do Data Warehouse. Em resumo, os dados são armazenados em sua forma
elementar, onde não há redundância e qualquer dado necessário que não seja
elementar será derivado de uma coleção de dados elementares. Os dados podem
ser extraídos e armazenados no banco de dados. De modo geral, o banco de dados
operacional é utilizado para o processo de atualização, não para o processo de
extração.
O Data Warehouse não é construído para suportar o processo funcional da
empresa, mas para facilitar o uso da informação. Sua fonte de dados é o banco de
dados operacional utilizado para o processo de extração. De fato, ele só pode ser
atualizado pelo banco de dados operacional, pois é um recurso de somente leitura.
O primeiro passo na sua construção é simplesmente criar um banco de dados
especializado, que é o utilizado de acordo com a necessidade de informações do
tipo "e se". A única tecnologia adicional necessária para esse passo é a de extração
de dados do banco de dados aplicativos para o Data Warehouse que incluam os
background image
20
mecanismos apropriados para criar agregados. Embora certamente seja possível
desenvolver essa interface, já existem várias soluções disponíveis no mercado.
Sistema aplicativos versus sistema de informação
A necessidade de informações de alta qualidade que possam ser facilmente
acessadas e analisadas é o motivo que leva maior parte das empresas a
desenvolver um Data Warehouse. Essa necessidade deve ser a diferença
fundamental entre o processamento de dados operacionais e informativos. As
diferenças entre estes dois sistemas podem ser melhor visualizadas na tabela 1
abaixo:
Sistemas aplicativos
Sistemas de informação
Suporta decisões cotidianas
Suporta decisões estratégicas de
longo prazo
Com base em transações
Com base em análises
Dados mudam constantemente
Dados mudam raramente
Processamento repetitivo
Processamento heurístico
Mantém dados atuais
Mantém dados históricos
Armazenar dados de detalhe
Armazenar dados de detalhes e
sumarizados
Orientado aplicações
Orientado a assunto
Padrão de uso previsível
Padrão de uso imprevisível
Serve a comunidade
administrativa e transacional
Serve à alta administração
Tabela 1: Sistemas aplicativos versus Sistemas de informação
background image
21
Além disto, os dados informativos solucionam problemas resultantes do uso
de um ambiente operacional para análise de suporte a decisão tais como:
Falta de integração: os sistemas aplicativos geralmente estão dispersos por
toda a organização e tem sido desenvolvidos ou adquiridos de forma independente
ao longo do tempo, sem que se considerassem as integrações entre eles. Os vários
sistemas freqüentemente baseiam-se em diferentes tipos de bancos de dados e são
utilizados em mainframes ou em ambientes do tipo cliente-servidor heterogêneos, o
que os tornam incompatíveis e de difícil integração para o suporte a decisão.
Uma outra característica do ambiente operacional é a ausência de histórico,
não fornecendo uma perspectiva histórica para a tomada de decisões. Devido às
limitações de espaço e para manter um bom nível de desempenho, a maior parte
dos sistemas transnacionais não guarda os registros por muito tempo.
Falta de credibilidade: os dados mudam constantemente, dificultando o
acesso preciso e oportuno o a realização de uma análise que possa ser rastreada ou
repetida.
Desempenho: para processar centenas ou milhares de transações por
segundo, os sistemas aplicativos armazenam dados em formato destinados a
otimizar o desempenho da transação, não a suportar a análise do negócio. Conduzir
a análise e processar transações no mesmo sistema degrada substancialmente o
desempenho deste e prejudica a execução das transações rotineiras do negócio
críticas para a organização.
Além disto, as organizações geralmente mantêm sistemas aplicativos
separados para cada função específica do negócio, como a gestão de estoques,
compras e transações de venda. Isso dificulta a análise cruzada das informações
contidas nestes bancos de dados separados.
background image
22
O Data Warehouse soluciona esses problemas proporcionando uma
arquitetura para modelar, mapear, filtrar, integrar, condensar e transformar dados
operacionais em um banco de dados separado com informações úteis que podem
ser acessadas analisadas e utilizadas. Isso permite aos usuários acesso direto aos
dados corporativos, economizando tempo da equipe de sistemas e melhorando a
produtividade. Ele também pode ser usado para manter informações de histórico
necessárias para fins legais ou éticos, ou para atender a regulamentações
governamentais. Nestes casos, a capacidade de produzir informações integradas,
históricas, não voláteis é essencial para as operações do negócio.
Alternativas de implementação
A tarefa de implementar um Data Warehouse pode ser um esforço muito
grande, consumindo um tempo significativo, dependendo da alternativa de
implementação escolhida, isso pode influir muito no tempo necessário para se notar
o retorno do investimento.
Qualquer técnica de implementação tem prós e contras e tudo se resume em
uma decisão da administração baseada nas capacidades dos produtos e recursos
disponíveis. As alternativas para implementação do sistema são:
Data mart independente: esta abordagem permite que um
departamento ou grupo de trabalho implemente um sistema com um
mínimo ou nenhum impacto da divisão de MIS10. Talvez sejam
necessárias algumas qualificações técnicas, mas esses recursos
podem ser gerenciados no próprio departamento ou grupo de trabalho;
Data mart dependente: esta abordagem é semelhante ao
independente, exceto que será necessário o gerenciamento das fontes
10
MIS ­ Managment Information Systems
background image
23
de dados pelo MIS. Essas fontes de dados podem incluir dados
operacionais e dados externos e o grupo de trabalho decide quais
dados desejam e a freqüência do acesso e pode inclusive fornecer as
competências e ferramentas necessárias para extrair os dados;
Data Warehouse global: os requisitos e prioridades de
implementação serão baseados nas necessidades da empresa como
um todo. Um sistema como esse pode ser centralizado fisicamente ou
centralizado logicamente e distribuído fisicamente ao longo de
múltiplas plataformas. O projeto pode incluir o suporte de qualquer
número de Data Marts, que não serão os mesmos daqueles das
categorias independentes e dependentes. São criados especificamente
para serem parte do Data Warehouse global e populados a partir dele.
background image
24
4- DEFINIDO AS INFORMAÇÕES: A SEQÜÊNCIA DE CLIQUES DA
WEB
A proposta apresentada por Kimball [8] e Inmon [4], não se limita a apresentar
o resultado do Data Warehouse com uma interface típica de Internet, e sim levar a
Internet para o Data Warehouse, o que significa trazer comportamentos para o Data
Warehouse, que além da alimentação vinda de sistemas de processamento de
transações, terá também parte dessa alimentação vindo de transações capturadas
por meio de interfaces da Web. É necessário deixar claro que o objetivo não é
capturar transações para o sistema e sim capturar, analisar e entender o
comportamento de usuários que clicam em um site da Internet. Teremos uma nova
fonte de dados para nosso sistema, chamada de registro (log) de seqüência de
cliques, que é um registro detalhado de cada gesto efetuado por cada visitante às
página de um servidor de Internet [1, 3, 11].
As fontes de dados de processamento de transações on-line (OLTP) omitem
muitas informações interessantes, por exemplo, em um ambiente varejista registra
somente a última etapa em um relacionamento que vem sendo construído por algum
tempo. O sistema registrará que a venda aconteceu, mas não se tem nenhuma idéia
do que conduziu até esta venda. O sistema OLTP não pode capturar outras
interações com o cliente, como consultas, visitas, ou fatores que levaram o cliente
até mesmo a se aproximar do revendedor.
A seqüência de cliques, por outro lado, é uma série cronológica de ações
microscópicas que podem ser agrupadas em sessões. A trajetória das ações que
conduziram até uma compra ou algum outro comportamento em que estamos
interessados pode ser analisada e entendida. Pode-se ter mais confiança em como
os clientes chegaram, qual era seu propósito e qual a qualidade de sua experiência.
background image
25
Pode-se saber o que eles viram na tela, quanto tempo levaram para localizar as
escolhas que fizeram, sinais diretos de satisfação e sinais diretos de
descontentamento, ficando em uma posição muito melhor para responder e
efetivamente ao cliente individual [4, 8].
Os autores descrevem que não basta colocar cada área e evento de páginas
com cada gesto do usuário em um banco de dados. Uma seqüência de cliques bruta
não é uma descrição útil de comportamento, o que pode ser levado a conclusões
precipitadas. Principalmente Kimball [8] reforça que uma descrição mais útil de
comportamento é o propósito. O propósito comportamental tem muitas
interpretações possíveis. O propósito de longo prazo de um conjunto de eventos de
página pode ser "comprar um produto", mas a proposta de curto prazo pode ser
"obter a descrição de um produto".
Kimball e Merz [8] apresentam vários propósitos possíveis para o
comportamento do usuário final, entre elas estão:
Recolhimento de informações gerais;
Recolhimento de características de produtos;
Revisão da lista de perguntas feitas com freqüência
(FAQ11);
Pergunta ao suporte;
Pedido de produtos;
Pedidos de serviços;
Rastreamento do status do pedido;
Pesquisa;
Leitura de notícias e artigos;
11
FAQ ­ Frequently Asked Question
background image
26
Divertimento;
Correio eletrônico.
Os autores citam ainda descrições mais ricas de comportamento que são
ainda mais significativas se for possível identificá-las com segurança. Estas
descrições incluem:
Evento bem-sucedido de compra;
Evento de compra incompleto ou cancelado;
Localização das informações procuradas;
Não localização das informações procuradas;
Evento assassino de sessão (o usuário deixa o site);
Exibição incompleta de informações, mas o usuário
permaneceu no site;
Exibição incompleta de informações, e o usuário saiu do
site;
Caminho errado tomado;
O usuário está zangado;
O usuário está feliz;
O usuário é tranqüilizado.
Embora a marcação de sessões dos usuários da Internet com descrições de
comportamento seja certamente interessante por si própria e por seus efeitos, o
valor real da identificação do comportamento está em aprimorar a qualidade de
interação que o usuário tem com a empresa. Aprimorar esta interação se traduz
diretamente em lealdade do cliente, rendas e lucros aumentados. Os autores citam
o livro "Customers.com" de Patrícia Seybold (Random House, 1998), para identificar
background image
27
oito fatores de sucesso para qualquer negócio, mas especialmente para negócios
alavancados pela Internet. Estes fatores seriam:
Ter como alvo o cliente certo;
Possuir a experiência total do cliente;
Simplificar processos de negócio que tem impacto sobre o
cliente;
Fornecer uma visão de 360 ° do relacionamento com o
cliente;
Deixar que os clientes se sirvam;
Ajudar os clientes a fazer seus trabalhos;
Entregar um serviço personalizado;
Promover comunidades.
Para prover esta funcionalidade, Kimball e Merz [8] propõem a utilização de
um sistema em conjunto com o servidor de Web público e o servidor de transações
comerciais. Este sistema será um "cachê de resposta automática". Ele é construído
para antecipar o maior número possível de solicitações repetidas e previsíveis de
informações, sendo um, ou um conjunto de servidores de aplicativos que alimentam
o servidor da Web público. Os dados no cachê de resposta automática são criados
em uma série de trabalhos em lotes sendo executados no servidor de aplicativos
principal do sistema. Uma vez armazenados no cachê de resposta automática, os
objetos de dados podem ser buscados sob demanda pelos aplicativos do servidor da
Web público. Ele será mais do que um armazenamento operacional de dados
deverá fornecer também as seguintes funções:
Saudações personalizadas para visitantes de Web;
background image
28
Proposições de vendas cruzadas (cross-selling) e de
ampliação das vendas a um cliente (up-selling12) para visitantes de
Web, baseadas em aplicativos de exploração de dados procurando por
outros membros do seu grupo de comportamento;
Conteúdo de promoção dinamicamente escolhido para
visitantes de web;
Respostas tipo FAQ para problemas e solicitações de
suporte;
Relatórios para clientes e parceiros de negócios no canal
de entrega que precisam de uma quantidade moderada de integração
através do tempo;
Relatórios para gerência que precisa de integração
significativa através do tempo;
Cubos de OLAP pré-computados, para análise
exploratória;
Estudos de exploração de dados de curto e longo prazo,
mostrando a evolução de grupos de clientes por demografia e por
comportamento, e os efeitos de decisões sobre conteúdo promocional
e conteúdo de Said da Web em negócios feitos pela Internet;
Agregações convencionais que aprimoram o desempenho
de consulta.
12
up-selling ­ vender um produto de valor mais alto para um cliente existente
background image
29
Figura 3- Proposta de utilização do Data Webhouse em conjunto com o
servidor Web.
Kimball [8] adverte que construir um cachê de resposta automática não é uma
tarefa fácil, pois insere outro servidor no que já é uma arquitetura complexa, porém,
ele irá diminuir em muito a pressão sobre os sistemas de gerenciamento de banco
de dados e sobre os sistemas de aplicativos quando é necessário se encarar os
requisitos de oportunidade, volume de dados e tempo de resposta que são típicos da
Internet.
O autor reforça ainda, que o cachê de resposta automática não deve ser
confundido com o servidor de Web público ou o servidor de transação comercial. O
trabalho do servidor da Web público é gerenciar um grande número de conexões
simultâneas baseadas em navegadores, e não ser um banco de dados de alto
desempenho. O trabalho do servidor de transação comercial é capturar e manter um
imenso número de transações comerciais, como se fosse a caixa registradora da
empresa, e não será interessante que algo torne esta caixa registradora lenta.
INTERNET
Visitante
Servidor de Aplicativo
Servidor WEB
DataWebhou
Extração
Transformação
Cachê de
resposta
automática
Logs de
Seqüência de
background image
30
Na figura 3, pode se observar como se daria a integração deste novo sistema
com os servidores de Web e de Aplicativos já existentes. Como visto na seção
anterior nas definições de Data Warehouse e de Data mart, este sistema se
enquadra mais na definição de um Data mart por ser específico de um assunto, a
seqüência de clique da web, e não um Data Warehouse completo da empresa.
Kimball chama este sistema de Data Mart de seqüência de cliques da web como
simplesmente: Data Webhouse [8].
background image
31
5- MAPEANDO OS SISTEMAS PROVEDORES
Os sistemas provedores de informação para alimentar o Data Mart de
seqüência de cliques serão basicamente de dois tipo. O primeiro será o servidor de
aplicativos. Um banco de dados relacional que contém todo o processamento
transacional do site. Daí virão as informações de planos de serviços e produtos
efetivamente realizados e confirmados.
O segundo tipo de fonte de informações serão os arquivos de log de
seqüência de cliques do servidor web. Estes arquivos seguem a padronização criada
pelo W3C
13
chamada Extended Log File Format
14
para registrar todos os eventos
gerados pelos usuários que requisitam informações pelo site da web. O sistema
proposto irá ler estes arquivos de registros para extrair as informações das sessões
dos usuários e sumariza-las nas tabelas de dimensões que serão propostas adiante
neste trabalho. Este processamento irá requerer um grande processamento
computacional que será realizado em lote (batch) durante a madrugada, pois a cada
dia são produzidos uma média de 250Mbytes de dados das sessões dos usuários.
Na figura 4 abaixo, podemos observar um exemplo do tipo de informação guardada
nestes arquivos:
13
W3C ­ World Wide Web Consortium
14
Extended Log File Format ­ Formato Extendido de Arquivo de Registro ­ formato derivado do
Common Log Format.
background image
32
Figura 4 ­ Exemplo de arquivo de log
192.168.0.1 - - [22/Aug/2001:22:10:37 -0300] "GET / HTTP/1.0" 200 2899
192.168.0.1 - - [22/Aug/2001:22:10:37 -0300] "GET /imgs/logo-cnc.gif HTTP/1.0"
200 4349
192.168.0.1 - - [22/Aug/2001:22:10:37 -0300] "GET /imgs/apache_pb.gif HTTP/1.0"
200 1806
192.168.0.1 - - [22/Aug/2001:22:10:37 -0300] "GET /imgs/mod_ssl_sb.gif
HTTP/1.0" 200 2007
192.168.0.1 - - [22/Aug/2001:22:10:38 -0300] "GET /imgs/openssl.gif HTTP/1.0"
200 2063
192.168.0.1 - - [22/Aug/2001:22:10:53 -0300] "GET /manual/index.html HTTP/1.0"
192.168.0.1 - - [22/Aug/2001:22:10:53 -0300] "GET /manual/images/pixel.gif
HTTP/1.0" 200 61
192.168.0.1 - - [22/Aug/2001:22:11:07 -0300] "GET /php.ini HTTP/1.0" 404 262
192.168.0.1 - - [22/Aug/2001:22:11:12 -0300] "GET /php.info HTTP/1.0" 404 263
192.168.0.1 - - [22/Aug/2001:22:11:19 -0300] "GET /info.php HTTP/1.0" 404 263
192.168.0.1 - - [22/Aug/2001:22:33:28 -0300] "GET / HTTP/1.0" 304 -
200.34.71.177 - - [23/Aug/2001:10:05:01 -0300] "GET
/default.ida?%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3
%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
HTTP/1.0" 404 266
192.168.0.1 - - [23/Aug/2001:10:06:28 -0300] "GET /teste.php HTTP/1.0" 200 729
200.168.40.107 - - [23/Aug/2001:10:10:42 -0300] "GET
/default.ida?%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3
%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
HTTP/1.0" 404 266
200.226.215.71 - - [23/Aug/2001:10:11:44 -0300] "GET /default.ida?%u9
200.49.211.130 - - [23/Aug/2001:10:19:01 -0300] "GET /default.ida?%u9HTTP/1.0"
404 266
192.168.0.1 - - [23/Aug/2001:10:54:14 -0300] "GET /teste.php HTTP/1.0" 200 708
background image
33
6- PROPOSTA DE ARQUITETURA
Para construir um Data Mart de seqüência de cliques, precisaremos rever
alguns conceitos da arquitetura de Data Warehouse's e Data Mart's começando pelo
Modelo Dimensional.
Modelo dimensional
Para Kimball [8] e Singh [10], os Modelos dimensionais são construídos em
torno do conceito de fatos medidos. A maioria dos sistemas de produção são
especializados em capturar algum tipo de fato medido. O fato pode ser a venda de
produtos, o preço de uma ação ou a quantidade de cobertura de um seguro. Todos
estes fatores são numéricos e alguns deles são verdadeiros em um instante
específico do tempo, outros representam uma medida acumulada sobre o período de
tempo.
Os fatos medidos dos sistemas de produção são colocados em tabelas
chamadas tabelas de fatos. Um registro de tabela de fatos contém uma ou mais
medidas numéricas tomadas de um sistema de produção em algum instante. O
objetivo na modelagem dimensional é cercar os fatos metidos com o maior número
possível de dados contextuais. Cada um dos itens na lista de contexto são
chamados de dimensões. As dimensões são, cada uma delas, descrições textuais
ricas de algo que existe no momento em que o registro da tabela é definido. Devido
a variedade de descrições possíveis, não é interessante colocar todas as descrições
de dimensão em cada registro que representam o fato medido, coloca-se todas as
descrições textuais em tabela separadas de dimensão e somente coloca-se uma
chave estrangeira no registro real do fato. Cada chave estrangeira se conecta com
sua chave primária correspondente em uma tabela de dimensão. Esse modelo
background image
34
característico é chamado de junção em estrelas, porque a tabela de fatos está no
centro de todas as tabelas de dimensão, que estão organizadas em torno dela.
O grão é a definição formal do que é um único registro de tabela de fatos, e
declará-lo corretamente é muito importante para os projetos dimensionais. Deve se
iniciar pela declaração do grão e depois decidir quais fatos e dimensões se ajustam
a esse grão. Após declarar o grão, procuram-se dimensões que assumam um valor
único no contexto da medida. Inmon [4], sugere inclusive a utilização de um
gerenciador de granularidade já que este pode ser um fator crítico no Data mart de
seqüência de cliques. O gerenciador de granularidade será usado para editar, re-
organizar, agregar e sumarizar este dados.
Encadeando estrelas.
Muitos modelos dimensionais semelhantes (esquemas de estrelas) podem ser
construídos durante o tempo na empresa, representando fontes diversas de dados e
interesses de grupos diferentes. Cada um destes modelos dimensionais são
chamados de data mart. Grupos individuais construindo um Data Mart podem decidir
freqüentemente sobre seus objetivos de projetos, seu financiamento e a escolha de
tecnologia. Geralmente implementam sua solução muito mais rapidamente do que o
esforço centralizado para construir um Data Warehouse completo.
Para que um grande data webhouse distribuído por diversas empresas e
negócios funcione, é necessário algum tipo de uniformidade previsível, um conjunto
de padrões que permitam que as partes diferentes se reconheçam e se
comuniquem. Novas partes devem ser capazes de se unirem ao data Webhouse
existente e dele participar de maneira eficiente
background image
35
7- MODELANDO OS DADOS
Kimball [8] sugere a criação do maior número possível de dimensões que
possam ter relevância em um ambiente de seqüência de cliques. A seguir
apresentamos algumas destas sugestões do autor, modificadas para atender as
necessidades do website em estudo.
Dimensão da data do calendário
Ela terá um registro para cada dia no calendário. O autor sugere separar o dia
do calendário de um lado, que o horário do dia de outro, fazendo dimensões
separadas para ambas. Sua justificativa para uma dimensão explícita de data do
calendário, em vez de somente contar com um tipo de data SQL ou OLAP, é porque
muitos atributos não estão incluídos nestas linguagens padrão, como estações do
ano, feriados, dias úteis locais, períodos fiscais e outros eventos especiais que são
determinados pelo calendário que são específicos para cada negócio. A dimensão
recomendada para a data do calendário deve conter:
Chave de data
Chave primária auto-numérica
Tipo de data
(por exemplo: regular,
desconhecida, etc)
Data completa SQL
Dia da semana
(Segunda, terça, etc)
Número do dia na semana
(1..7)
Número do dia no mês
(1..31)
Número do dia no ano
(1..365)
Dia útil
(dia útil, feriado, fim de semana,
etc)
Feriado
(nenhum, ou dia do feriado)
background image
36
Número da semana no ano
(1..53)
Mês
(Janeiro, Fevereiro, Março, etc)
Número do mês no ano
(1..12)
Ano
(2001, 2002, etc)
Estação do ano
(estação do ano ou férias)
Evento
Indicador em especial de algum
evento, como por exemplo uma
campanha publicitária
O autor inclui vários campos passíveis de navegação da dimensão da data do
calendário que não são tão necessários, poderia-se a princípio, colocar cálculos
extras no aplicativo final do usuário para calcular informações como o nome do dia
na semana, número do dia no ano, ser feriado ou não, etc. Porém, o autor ressalta
que esta lógica extra nas ferramentas do usuário final poderia prejudicar o projeto
inteiro pela lentidão com que faria os aplicativos serem executados e pela
dificuldade com que os mesmos seriam mantidos.
Dimensão do horário do dia
Esta é uma dimensão simples que permite reverenciar períodos identificados
de tempo durante o dia, como horas individuais, podendo ter nomes para outras
faixas de tempo, como turno da noite ou horário do almoço, por exemplo. O autor
recomenda a construção da dimensão de tempo com uma granularidade de um
segundo, gerando 86.400 linhas de dimensão, no seguinte formato:
Chave de data hora
Chave primária auto- numérica
Tipo de data hora
(regular, desconhecido, etc)
Segundos desde à meia-noite
(0..86399)
Minutos desde a meia-noite
(0..1439)
background image
37
Registro de data do SQL
(00:00:00..23:59:59)
Hora (0..23)
Minuto (0..59)
Segundo (0..59)
Período de tempo
(ex.: turno da noite, horário de
almoço, etc.)
Dimensão do cliente
Um dos maiores desafios de um site da Internet é saber exatamente quem
está clicando em suas páginas. O autor sugere aqui, quatro grupos principais de
campos para dimensão do cliente, porém iremos considerar apenas os campos
relevantes ao site em um único grande grupo:
Chave de cliente
Chave primária de valores auto-
numéricos
Tipo de cliente
(desconhecido, cliente cadastrado,
cookie temporário, cookie permanente,
etc)
ID do cookie
Contador para cookies
persistentes
Id Cliente
Para pessoas com cadastro
completo no site
Nome
Nome quando de clientes
identificados
Tipo de nome
(real, completo, apelido, etc)
Saudação
(Sr, Sra, Srta)
background image
38
Sexo (Masculino,
Feminino,
desconhecido)
Origem do IP
Descrição da origem do endereço
de IP através de pesquisa reversa de
DNS
Tipo de Cliente
(Profissional, Estagiário, Empresa,
Aluno)
Nome da Empresa
Nulo se não for um cliente
Empresa
Telefone
Cidade
Estado
Endereço Eletrônico
Segmento de Interesse
(Eletro-eletrônicos, Financeiro,
Comércio, etc)
Área de Interesse
(Comercial, Administrativo,
Informática, etc.)
Nível Hierárquico
(Diretor, Gerente, Especialista,
etc)
Faixa Etária
Recenticidade
(data da última compra, assinatura
de plano)
Freqüência
(número de compras, renovação
de planos)
Intensidade
(valor total gasto pelo cliente)
background image
39
Grupo
Um campo rotulando o grupo
demográfico do cliente
Perfil de compra
Um campo rotulando o perfil de
compra do cliente
Perfil de devolução
Um campo rotulando a propensão
do cliente de devolver um
produto/serviço
Perfil de suporte
Um campo rotulando a utilização
do suporte pelo cliente
Dimensão da página
A dimensão de página deve descrever cada evento de página exibida na
Internet, tendo a preocupação de ser flexível o suficiente para tratar páginas HTML
estáticas ou scripts dinâmicos, sendo sugerida a seguinte configuração:
Chave de página
Chave primária auto-numérica
Tipo de página
(HTML, ASP)
Função
Ex.: descrição do serviço,
publicação de currículo, publicação de
vaga, etc
Tipo de imagens gráficas
(GIF, JPEG, etc)
Animação
(Java, ActiveX, Flash, etc)
Nome de Arquivo da página
Caminho no servidor
Dimensão da sessão
background image
40
Uma sessão mapeia todo o caminho percorrido por um usuário dentro do site
da internet. Através da análise da sessão, observamos se o objetivo do site foi
entendido e se a meta da venda foi alcançada ou não. Através da análise das
sessões de um usuário, feita em tempo de extração do data mart e identificado
através de cookies persistentes quando o usuário volta ao site, determina se este é
um cliente, nas palavras do autor, de "Alto Valor Confiável", ou "Novo Cliente", ou
"Prestes a Cancelar", ou "Cliente padrão". Todas estas características podem ser
derivadas de Data Marts da seqüência de cliques, podendo-se agrupar tipos de
usuários e extrair consultas do tipo:
Quantos clientes consultaram as informações dos
serviços antes de se cadastrar?
Quantos clientes viram as informações dos pedidos e
nunca fizeram uma assinatura?
Quantos clientes começaram o processo de cadastro e
não o terminaram? Podemos determinar uma página "matadora de
sessão"?
A dimensão da sessão conteria então:
Chave de sessão
Chave primária auto-numérica
Tipo de sessão
(Ex.: classificada, não classificada,
corrompida, etc..)
Contexto Local
(Solicitando informações de
pedidos, Consultando vagas, etc,...)
Objetivo da sessão
(Objetivo da navegação: apenas
olhando aleatoriamente, interessado no
serviço, lendo artigos, etc)
background image
41
Status do Sucesso
Se o objetivo foi alcançado ou não
Resultado da Sessão
(Fez uma assinatura, Cancelou
uma assinatura, Pesquisou no site, etc)
Status do Cliente
(rótulos como: "Alto valor
Confiável", "Padrão", etc)
Dimensão de referência
Os registros de log da internet possuem um campo denominado referer que
carregam a informação da origem do link que levou o cliente até o site. Se a origem
do link foi um sistema de pesquisa, as palavras chaves da consulta também podem
ser identificadas. Para armazenar estas informações, é sugerido a seguinte
dimensão:
Chave de referência
Chave primária auto-numérica
Tipo de referência
(Intranet, Parceiro, sistema de
busca, etc)
URL de referência
Endereço da página contendo o
link
Domínio de referência
Especificação
O querystring com os argumentos
da busca se existirem
Dimensão dos produtos e serviços
Esta dimensão tem o objetivo de descrever os produtos ou serviços que são o
assunto de uma página ou alvo de um evento. No caso do site em análise, teremos
background image
42
ambos: produtos e serviços, pois além do serviço de assinatura, com algumas
opções de planos, o site comercializa também livros e cursos.
Chave do produto
Chave primária auto-numérica
Tipo de produto
(Regular, promoção, não
aplicável)
Código do produto
Código do produto de acordo com
os registros dos bancos de dados de
produção
Categoria do produto
(Assinatura, Produto ou Curso)
Descrição
Período do curso ou assinatura
Data Início e Data Fim
Dimensão causal / promocional
O autor sugere aqui relacionar nesta dimensão as condições de mercado no
momento em que a medida é feita na tabela de fatos. Esta dimensão tenta fornecer
dicas ou "fatores causais" que possam explicar as razões pelas quais o cliente está
interessado na empresa ou em um produto ou serviço em particular. No caso deste
site, o ideal é adaptar esta dimensão para descrever os eventos relacionados com
campanhas publicitárias feitas junto a parceiros de negócios na Internet, e
campanhas em jornais de domingo, em especial nos cadernos de emprego. Esta
dimensão promocional ficaria então:
Chave Causal
Chave primária auto-numérica
Tratamento de Preço
(Oferecimento de desconto, preço
normal, etc)
Tipo de anúncio de jornal
(Grande, pequeno, fim-de-
background image
43
semana, diário)
Tipo de anúncio na internet
(Banners, permutas, sistemas de
busca, etc)
Outro evento causal
(desconto do concorrente,
instabilidade econômica, aumento
desemprego, etc)
Período de ocorrência
Data Início a Data Fim
background image
44
8- FERRAMENTAS DE BANCOS DE DADOS
Depois de definir quais informações queremos armazenar em nosso Data
Mart e como serão estas tabelas, precisamos consultar as ferramentas de banco de
dados disponíveis no mercado que possam nos ajudar. Consultando Singh [10] nota-
se que existe uma grande variedade de ferramentas disponíveis para análise de
dados corporativos. Essas ferramentas, algumas vezes, são referidas como
Sistemas de Suporte à decisão (DSS
15
) ou Sistemas de Informações Executivas
(EIS
16
). As ferramentas são subdivididas em várias categorias, cada qual voltada
para um conjunto diferente de problemas.
Análise de processo
Ferramentas de análise de processo auxiliam na identificação de problemas
com processos tais como manufatura, remessa ou atendimento de pedido. As
ferramentas de análise de processo apontam áreas de baixo desempenho e ajudam
a determinar as causas dos problemas.
Análise de agregados
Ferramentas de análise de agregados examinam agregações hierárquicas ou
multidimensionais dos dados. Essa análise é útil para sumarizar informações em
diferentes níveis de detalhe para gerar relatórios de previsão orçamentária, vendas e
estoque. Itens de interesse podem normalmente ser apresentados em maior detalhe.
Essas ferramentas de modo geral não são adequadas para análise de processo.
Algumas ferramentas que melhoram a análise de agregados são:
15
DSS ­ Decision Support System
16
EIS ­ Executive Information System
background image
45
Acumate ES da Kenan Systems Corp.
Advance da Lighten, Inc.
Commander da Comshare.
Dimension da Kelly Information Systems. Inc.
Empower and Enterprise Knowledge Server da
Metapraxis.
GENTIUM da Planning Sciences.
Holos da Holistic Systems.
Ferramentas de geração de relatórios e análise de dados
Hyperion da Hyperyon Software.
Media da Speedware Corpotion Inc.
PaBLO da Andyne.
Powerplay e Impromptu da Cognos Inc.
StarTrive da SelectStar Inc.
Consulta
Ferramentas para fins de consulta e geração de relatórios têm como objetivo
oferecer aos usuários uma interface amigável para banco de dados. Interfaces
gráficas simplificam a tarefa de formular consultas e apresentam os resultados no
formato gráfico. Essas ferramentas são úteis para análise ad hoc mas não oferecem
o desempenho necessário para solucionar problemas de análise extensa de
processo de agregados. Essas ferramentas são:
Bussines WEB, uma ferramenta para tornar informações
corporativas acessíveis via browsers Web da Managerment Science
Associates, Inc.
background image
46
CorVu da CorVu Pty. Ltd.
Forrest&Trees. InfoReports e InfoQuery da Platinum
Technology, Inc.
InfoAssistant da Asymetrix Corp.
IQ/ Objects e IQ/ Vision da IQ Software Corp.
Level5 Quest da Level Five Research.
Voyant da Brossco Systems.
Finalidades gerais
Ferramentas para finalidades gerais tais como planilhas e pacotes estatísticos
podem ser configuradas para solucionar uma ampla gama de problemas. As
ferramentas para finalidades gerais geralmente são versáteis, mas tendem a ser de
difícil configuração e lentas na análise de grandes volumes de dados corporativos.
Alguns exemplos de ferramentas para finalidades gerais são:
CrossGraphs, ferramentas de tabulação gráfica cruzada
da Belmont Research Inc.
Demos, um pacote para análise estatística de risco e
decisão da Lumina Decision Systems, Inc.
Excel, planilhas eletrônicas da Microsoft Corp.
Lótus 1-2-3, planilha eletrônica da Lótus Corp.
MATLAB, pacote de análise numérica e visualização da
The Math Works, Inc.
PV-Wave, pacote de análise de dados e visualização da
Visual Numerics, Inc.
background image
47
S-Plus, pacote de análise estatística e visualização da
Statistical Sciences.
SAS, pacote de análise estatística e visualização do SAS
Institute Inc.
SPSS da SPSS Inc.
Bancos de dados multidimensionais
Bancos de dados multidimensionais agregam dados em hipercubos. Por
exemplo, isso lhes confere um bom desempenho em consultas que solicitam dados
de sumário, total de vendas divididas por país. Infelizmente, ainda não existem
padrões que definem o acesso aos bancos de dados multidimensionais. Alguns dos
produtos mais comuns são:
Acumate ES da Kenan Systems Corp.
Cross Target da Dimensional Insight.
Essbase da Arbor Software Corp.
Express da Oracle.
GENTIUM da Planinig Sciences Crop.
HELM da Codework.
Holos da Holisitc Systems.
Lightship da Pilor Software.
Media da Speedware Corporation Inc.
MetaCube da Informix.
Bancos de dados relacionais
background image
48
Bancos de dados relacionais armazenam dados em tabelas. Eles são
especialmente adequados para o processamento de dados de transações. O SQL
proporciona um meio padronizado para acessar dados de bancos de dados
relacionais. Os principais bancos de dados relacionais são [7, 10]:
Ingress
Sybase
Microsoft SQL Server ­ ambiente NT [2]
Oracle ­ ambiente Unix,
DB2/UDB ­ ambiente OS390 e AIX,
Informix ­ ambiente Unix (high end),
Teradata ­ ambiente paralelo em alta escala.
Data Warehouses
Os data warehouse comerciais são usados para consolidar dados de
múltiplas fontes em uma organização. Os dados são então disponibilizados para o
processo de tomada de decisão corporativo. Alguns dos principais fornecedores de
tecnologia destes bancos de dados são:
Apertus Technologies. Inc., fornecedor do
Enterprise/Integrator.
Hewlett-Packard, fornecedor do Open Warehouse.
IBM, fornecedor do Virtual Warehouse.
MicroStrategy.
Platinum Technology, Inc. , fornecedor do InfoHGub.
Praxis International, fornecedor do OmniWarehouse.
Red Brick.
background image
49
Sequent Computer Systems. Inc.
Software AG.
Tandem Computers.
Inmon [7] destaca também os seguintes fornecedores de soluções completas:
SAP;
SAS com uma suíte integrada de produtos;
PeopleSoft;
Computer Associates.
Ferramentas De Análise De Dados
Ferramentas de análise de dados são usadas para executar funções
estatísticas e numéricas, previsões e modelagem multidimensional. Algumas vezes
referidas como ferramentas de processamento Analítico On-Line (OLAP), essas
ferramentas permitem que os usuários analisem dados ao longo de várias
dimensões, incluindo categorias como mercado, tempo e produto.
Essas ferramentas são usadas para analisar e prever tendências e medir a
eficiência das operações da empresa ao longo do tempo. Essas avaliações
fornecem suporte para tomada de decisão estratégica do negócio e insight sobre
como melhorar a eficiência e reduzir os custos das operações.
Ferramentas OLAP permitem que os usuários analisem e fatiem dados ao
longo de múltiplas dimensões como categorias de mercado, tempo e produto. Essas
ferramentas existem há muito tempo, mas assim como ferramentas para consulta e
geração de relatórios, os produtos OLAP agora estão aproveitando as vantagens da
interface gráfica de plataformas cliente/servidor. O Data Warehouse para OLAP não
background image
50
só oferece dados limpos e integrados, mas também dados históricos essenciais para
previsão e análise de tendências.
Há dois tipos de ferramentas OLAP para Análise de Dados Multidimensionais
(MDA); aquelas que acessam dados armazenados em sistemas de bancos de dados
multidimensionais (MDBMSs) e aquelas que os dados são armazenados em DBMS's
relacionais. A discussão está em qual tipo de DBMS é mais adequado para
armazenar e manter dados multidimensionais.
Os MDBMSs fornecem recursos de servidor tanto para análise quanto para
gerenciamento de dados. Eles proporcionam um bom desempenho de análises e
drill-drown através de múltiplos níveis de dados sumarizados, mas são menos
adequados para lidar com grandes volumes de dados detalhados. Segundo Singh
[10], a atual tendência do uso de MDBMSs é prover um recurso pass-through para
os RDMSs acessarem dados detalhados em uma configuração de Data
Warehousing de múltiplas camadas.
Quando as ferramentas MDA são usadas para acessar dados armazenados
em RDBMSs, o RDBMS fornece o recurso para gerenciamento de dados, enquanto
que a ferramentas front-end do cliente fornece o mecanismo para análise. As
vantagens dessa abordagem é que ambos, dados sumarizados e detalhados,
podem ser armazenados no RDBMS, e podem ser compartilhados por outras
ferramentas de inteligência do negócio.
As ferramentas de análise de dados trabalham tipicamente com dados
sumarizados e detalhados. Embora você possa construir sumários durante o
processo analítico, é muito mais eficiente criá-los com antecedência sempre que
possível. Essa abordagem reduz o overhead de processamento e facilita o trabalho
do usuário.
background image
51
MS-SQL Server 2000
Uma ferramenta que pode ser uma solução mais viável em termos de custo e
benefício para a empresa é o SQL Server 2000 da Microsoft [2]. Por ser uma
ferramenta muito difundida no mercado, traria um menor custo em sua implantação e
adaptação para este tipo de Data Mart. Encontramos vários aspectos deste pacote
que foram feitos para aplicações de Data Warehouse, entre eles:
Serviços Online Analytical Processing (OLAP). Efetua
análise rápida e sofisticada em bancos de dados relacionais grandes e
complexos com armazenamento multidimensional e suporte a
navegação;
Serviços Data Mining. Alavanca os serviços de data-
mining integrados para descobrir tendências, descobrir padrões e
predizer resultados prováveis usando informação de bancos de dados
relacionais, e em cubos OLAP multidimensionais;
Ações Closed Loop. Vai além da análise tradicional. Inicia
a Web ou aplicações de negócio automaticamente com o SQL Server,
ou outros processos, tais como o envio de e-mail.
Habilitado para a Web. Data warehousing com SQL
Server 2000 foi melhorado com a habilidade de acesso a cubos pela
Internet, assim como o link seguro de cubos pela Internet. Isto dá aos
parceiros e trabalhadores remotos capacidades completas de análise.
Além disso, com o Microsoft Commerce Server 2000, o SQL Server
2000 proporciona análise de transação Internet e click-stream na Web
background image
52
escaláveis. O que seria muito interessante para nosso projeto de Data
Webhouse.
O fabricante ainda ressalta aspectos de alta escalabilidade e alta performance
tais como:
Suporte a banco de dados com tamanho de terabyte.
Gerencia os maiores e mais flexíveis Data Warehouses;
Escalabilidade. Proporciona acesso às maiores fontes de
dados centrais através da empresa para servidores departamentais,
laptops e dispositivos móveis;
Processador de consulta avançado. Otimiza e executa
consultas (queries) completas típicas, tais como uniões de estrela. O
paralelismo intraquery oferece performance mais rápida quebrando
uma única consulta complexa em partes componentes, e então
distribuindo a carga de trabalho em múltiplos processadores. Modos de
exibição indexados aumentam performance e flexibilidade contendo
agregações.
background image
53
9- PROCESSOS PARA IMPLEMENTAÇÃO
Na bibliografia encontramos que para construir um Data Warehouse devemos
nos preocupar com o complexo trabalho de integração de sistemas para estabelecer
arquiteturas e para unir os vários componentes. Para simplificar este processo
existem várias soluções integradas como vimos na seção anterior. Kimball [8, 9]
sugere como uma alternativa, combinar os melhores produtos do mercado: um
banco de dados de um fornecedor, ferramentas de consulta de outro, middleware
17
de um terceiro. Por outro lado, em um pacote completo, os componentes individuais
já foram integrados para eliminar problemas de desempenho e conectividade. Muitos
aspectos de infra-estrutura são tratados por trás dos bastidores, o que significa
melhor desempenho e menos problemas de incompatibilidade de ferramentas.
A arquitetura técnica deve ser vantajosa em relação ao custo-benefício, deve
ser adaptável e de fácil implementação. Uma tecnologia confiável deve ser utilizada
que suporte infra-estrutura técnica atual da organização e também seja flexível para
o crescimento futuro.
Aspectos de escopo e tempo
Kimball [8] alerta que projetos modestos que parecem simples
freqüentemente não são. É preciso administrar as expectativas do usuário e
estabelecer compromissos aceitáveis antes que a maior parte do orçamento e tempo
sejam despedidos. Até mesmo um projeto inicial bastante simples deve ser
cuidadosamente planejado se for usado como base para a o sistema de escopo e
capacidade e expansível.
17
Middleware ­ hardware e software usados para conectar clientes e servidores, para mover e estruturar
dados e/ou pré-sumarizar dados usados por consultas e relatórios.
background image
54
Um sistema mais simples pode agilizar a implementação e proporcionar uma
experiência de aprendizado com risco reduzido. Certamente é possível construir um
sistema simples que contém volumes razoáveis de dados de uma única fonte,
acessadas em poucas e previsíveis categorias de agregados. Normalmente é
possível implementar esse tipo de sistema usando programas utilitários para popular
estes dados e um pacote de software para recuperação e análise. Portanto, a partir
deste primeiro Data Mart de seqüência de cliques, esperamos que a organização
perceba a necessidade de desenvolver novos Data marts departamentais até chegar
a um projeto completo de Data Warehouse.
Considerações sobre volume de dados
Este é um aspecto importante em relação a custos e benefícios do sistema. A
flexibilidade de uso e a adaptabilidade a mudanças são questões críticas.
Carregamento e consulta em paralelo e dispositivos de armazenamento mais
rápidos e baratos são mais tangíveis do que o modelo de dados e ferramentas de
consulta com flexibilidade a custo acessível e facilidade de uso.
É útil colocar alguns parâmetros na questão do volume. Grande seria um
termo relativo, ele é afetado pelo volume bruto, volatilidade, requisitos de acesso, a
complexidade dos relacionamentos entre os dados, requisitos de disponibilidade e
muitos outros fatores. Conforme o hardware e o software evoluem, os níveis de
tolerância aumentam constantemente. A seguir o autor indica algumas diretrizes de
volume:
Menos de 5 Gbytes é considerado pequeno. Um sistema
destes pode rodar em servidores PC de alto desempenho;
background image
55
De 5 a 100Gbytes de dados é considerado moderado.
Talvez seja preciso uma estação de trabalho de grande porte ou
mainframe;
De 100 a 300 Gbytes é considerado grande. Múltiplos
servidores, com processadores paralelos, ou mainframes de maior
porte serão necessários;
Acima de 300 Gbytes é considerado volumoso. Será
necessário um processamento paralelo massivo para esta categoria.
Extração de dados
Os dados virão principalmente dos sistemas de produção e dos arquivos de
log da seqüência de cliques do servidor de Internet. Já existe atualmente um
software feito na própria empresa que analisa os arquivos de logs para extrair
algumas informações como: número de visitantes diários (unique users) e o total de
páginas acessadas (page views). Este programa será incorporado ao sistema e
melhorado para extrair as informações de comportamento discutidas anteriormente.
Sistemas complementares serão desenvolvidos pela equipe interna da empresa e
irão recolher também as informações sobre as transações (produtos e serviços)
realizados no dia e relacionados com as sessões dos usuários. Todo este
processamento será realizado em batch durante a madrugada quando o acesso ao
site é pequeno, porém Kimball [9] sugere a possibilidade do uso da linguagem XML
na captura das transações para o Data Mart, devido ao interesse na criação dos
chamados Realtime Data Warehouse's (Data Warehouse com atualização em tempo
real - em paralelo - ao invés de processos em lote).
Repositório
background image
56
O repositório armazena o metadado. Esse é o mapa dos dados que serão
mantidos no Data Mart. Será usado pelos aplicativos de extração e por qualquer
middleware ou ferramenta de usuário que irá proporcionar acesso ao Data Mart. Ele
mudará de acordo com a mudança dos dados.
Banco de dados
Diferentes tipos de bancos de dados são usados como parte da estratégica
do Data Mart. Apenas alguns produtos têm capacidade de rodarem em hardware
paralelo massivo, mais esses produtos talvez sejam necessários para grandes
volumes de dados. Bancos de dados OLAP são desenvolvidos para manipular
tabelas multidimensionais e talvez sejam necessários para algumas aplicações em
vez de bancos de dados relacionais.
Levando em conta o volume de dados e que os outros sistemas do site se
encontram em plataforma Intel, propomos a utilização do produto da Microsoft, o
MS-SQL Server [2] para este Data Mart.
Ferramentas de consulta
Existe uma grande variedade de ferramentas de consultas, conforme a seção
anterior, que permitem ao usuário gerar consultas facilmente para armazenar
comandos usados com freqüência. De modo geral, as ferramentas de consulta
devem ser capazes de acessar informações de repositório e limitar os usuários a um
sub conjunto do Data Mart para evitar o esgotamento dos recursos disponíveis. A
proposta é que as consultas básicas sejam produzidas internamente, utilizando a
interface Web, para poderem ser acessadas pela Intranet da empresa, que já
contém alguma informações gerenciais.
Hardware
background image
57
A literatura sugere que em alguns casos, um equipamento paralelo massivo e
ferramentas de bancos de dados especiais podem ser adequados. Em outros,
servidores UNIX de médio porte podem ser tudo o que é necessário. Algumas vezes,
um único servidor será suficiente. Os dados também poderão ser distribuídos por
vários servidores de diferentes tamanhos e locais diferentes na rede. Dado o escopo
deste projeto, sugerimos a utilização de um servidor bi-processado da família Intel,
com dispositivos especiais de armazenamento (storage) prevendo um aumento na
base de dados no futuro e uma capacidade de memória (RAM) elevada, para
garantir a performance nas consultas aos dados do Data Mart.
Implementação
Definido o escopo do projeto, seus requisitos de software e hardware e com o
modelo de dados proposto na seção "Modelando os Dados" pode-se definir um
cronograma de implementação do projeto de 6 (seis) meses para este Data Mart de
seqüência de cliques, conforme tabela abaixo:
Tarefa
Duração
1
Definição e mapeamento dos processos
1 mês
2
Definição e mapeamento dos dados e metadados
1 mês
3
Aquisição e configuração do servidor de banco de
dados
15 dias
4
Análise e Implementação do modelo de dados
2 meses
5
Análise e Implementação dos sistemas de
extração
2 meses
6
Análise e Implementação dos sistemas de consulta
2 meses
Tabela 3: Cronograma de implantação
background image
58
1o mês
2o mês
3o
mês
4o
mês
5o
mês
6o
mês
Definição
e mapeamento
dos processos
Definição
e mapeamento
dos dados e
metadados
Análise e
Implementação do
modelo de dados
Análise e
Implementação dos
sistemas de consulta
Aquisição
e configuração
do servidor de
banco de dados
Análise
e
Implementação dos
sistemas de extração
Tabela 4: Cronograma de implantação
background image
59
10- CONCLUSÃO
Neste trabalho foi feita uma revisão teórica dos conceitos básicos envolvendo
Data Warehouse's, em especial um subconjunto desta arquitetura chamada de Data
Mart. Avaliou-se a implantação de um Data Mart para avaliar o comportamento dos
usuários de um site da internet, através dos arquivos de logs da seqüência de
cliques, relacionando este comportamento com as transações comercias ocorridas
no site e registradas no servidor de aplicativos do sistema.
Foi feita uma discussão sobre os possíveis comportamentos que refletiriam no
resultado comercial do site, tais como: evento de compra bem-sucedido, incompleto
ou cancelado; localização ou não, das informações procuradas; se o usuário está
satisfeito ou não com o serviço, entre outras.
Conclui-se que seria mais adequado, para um melhor custo benefício, a
construção deste Data Mart ao invés de um completo e complexo Data Warehouse
para a empresa inteira. Foi apresentada uma sugestão de estrutura de dados e de
infra-estrutura necessária para o projeto e, por fim, uma proposta de cronograma
para implantação de 6 meses e envolveria a utilização de ferramentas baseadas na
plataforma Intel de banco de dados com sistemas desenvolvidos pela equipe técnica
interna da empresa.
background image
60
REFERÊNCIAS BIBLIOGRÁFICAS
[1]CYCLADES BRASIL. Guia Internet de Conectividade. São Paulo: Cyclades
Brasil, 1999.
[2]Data Warehousing com SQL Server 2000:
http://www.microsoft.com/brasil/sql/techinfo/dataware.stm
[3]Extended Log File Format ­ 2001: World Wide Web Consortium - W3C -
http://www.w3.org/TR/WD-logfile.html
[4]Inmon, W.H. - An Architecture for Managing Click Stream Data ­ 2001:
BillInmon.com - http://www.billinmon.com/library/whiteprs/click%20stream.pdf
[5]Inmon, W.H. - Introduction To Data Marts ­ 2001: BillInmon.com -
http://www.billinmon.com/library/articles/introdm.asp
[6]Inmon, W. H. - The Data Warehouse Environment: Quantifying Cost
Justification And Return On Investment - Microsoft Corporation and
BILLINMON.COM, 2000. - http://www.microsoft.com/brasil/sql/techinfo/data-env.stm
[7]Inmon, W.H. - The Data Warehouse Marketplace ­ 2001: BillInmon.com -
http://www.billinmon.com/library/articles/artmktpl.asp
[8]Kimball, Ralph ­ Data Webhouse: construindo o Data Warehouse para a
Web / Ralph Kimball, Richard Merz; tradução Edson Furmankiewicz, Joana
Figueiredo. ­ Rio de janeiro: Campus, 2000.
[9]Kimball, Ralph - XML Will Make It Easier - abril, 2001: Intelligent Enterprise
Magazine - Data Webhouse ­ http://www.intelligententerprise.com/
[10]Singh, Harry ­ Data Warehouse; tradução: Mônica Rosemberg; revisão
técnica: José Davi Furlam ­ São Paulo ­ Makron Books, 2001.
background image
61
[11]ZWICKY, Elizabeth D. - Construindo Firewalls para a Internet / Elizabeth
D. Zwicky, Simon Cooper, D. Brent Chapman; tradução de Vandenberg de Souza -
Rio de Janeiro: Campus, 2000.
{* Google Analytcs *}