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
2
3
Dedico este trabalho a todos os mestres da FIAP que compartilharam
seus
conhecimentos e a minha família que sempre me apoiou.
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
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
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.
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.
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
9
suprir informações para suporte a decisões gerenciais, sobre o projeto
do site na
Internet e o comportamento de seus usuários.
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
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
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
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
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.
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
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:
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:
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.
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
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
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.
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
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.
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.
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
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
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;
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
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
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].
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.
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
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
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
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)
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)
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)
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)
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
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)
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
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-
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
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
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.
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.
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
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.
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
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.
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
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.
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.
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;
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
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
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
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
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.
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.
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.
|