Implantação de Tecnologia de Data Warehouse em
Bibliotecas com Uso de Tecnologia Adequada
Autoria: Erico Resende Santos e Francisco José Espósito Aranha Filho
1 RESUMO
Projetos de implementação de data warehouses e data marts costumam ser longos e
dispendiosos. Nesta pesquisa foi desenvolvido um modelo de implementação de data marts
para a circulação do acervo de bibliotecas com uso de tecnologia adequada, ou seja, com foco
na solução por oposição a foco na tecnologia em si.
Um projeto piloto foi conduzido na biblioteca Karl A. Boedecker em que testou-se,
com sucesso, essa metodologia. O resultado obtido serviu de base para um estudo de
cooperação indireta, com uso de técnicas de data mining, como forma de gerar
recomendações de leitura para os usuários da biblioteca.
O data mart desenvolvido permitiu ainda outros estudos do perfil dos usuários e
diversas análises que pressupõe o acesso aos dados de circulação do acervo.
Estes resultados revelaram a possibilidade de se desenvolver sistemas desse tipo para
bibliotecas genéricas, com resultados bastante sofisticados, sem a necessidade de grandes
investimentos iniciais e em prazo reduzido.
2 INTRODUÇÃO
Com a crescente tendência de publicações em meio eletrônico e com o crescimento da
Internet como forma de distribuição de informações, o conceito tradicional de bibliotecas
como um local físico para armazenagem de informações deve evoluir para um conceito de
portal.
Vista como um portal, a biblioteca deve oferecer, além do acervo físico, um conjunto
amplo de produtos e serviços como: fornecimento de informações em meio eletrônico
(localmente e a distância), fornecimento de índices, catálogos, ferramentas de localização,
ajuda ativa na busca por informação etc. (Beaumont, 1998).
Seguindo a tendência de tornar-se um portal de informações, é importante que a
biblioteca mantenha um foco nos usuários, procurando entender suas necessidades e manter
com eles um relacionamento. Uma forma de fazer isso é fornecer uma ajuda ativa aos
usuários na localização de obras relevantes para sua pesquisa. Para isso é necessário adquirir
um conhecimento dos seus hábitos e interesses, o que passa por um estudo do seu
comportamento (Aranha, manuscrito).
Exemplos de técnicas para estudar esse comportamento são cooperação indireta e
link analysis (Aranha, manuscrito). Essas técnicas estão incluídas no conjunto de técnicas de
data mining (item 2.2) e são utilizadas em função da grande quantidade de dados analisados e
da característica pouco estruturada do problema.
A aplicação dessas técnicas demanda um conjunto acessível, consistente e íntegro de
dados. A preparação dos dados é uma parte essencial no processo de data mining (Westphal
& Blaxton, 1998). E uma solução frequentemente usada para a disponibilização desses dados
são data warehouses (Berry & Linoff, 1997).
A proposta dessa pesquisa é a definição de um data mart (extensível para um data
warehouse) como forma de dar suporte à aplicação de técnicas de data mining que
pressuponham o acesso aos dados de circulação do acervo de bibliotecas (ver itens 2.3 e 2.4
para uma explicação dos termos data mart e data warehouse).
1
2.1 PROJETO NA BIBLIOTECA KARL A. BOEDECKER
Um projeto piloto de um sistema de recomendações para os usuários foi implementado
na biblioteca karl A. Boedecker. Para isso foi implantado um data mart de circulação do
acervo da biblioteca.
O estudo do perfil dos usuários (Aranha, manuscrito) foi baseado na exploração do
histórico de transações de circulação do acervo na biblioteca realizadas no período de 1º de
março a 19 de julho de 1999. A base de dados inicial continha cerca de 22.500 transações
(entre empréstimos, renovações e devoluções de itens) envolvendo 1.688 usuários e 4.362
itens do acervo da biblioteca.
2.2 DATA MINING
Data mining é o processo de exploração e análise, por meios automáticos ou semiautomáticos, de um conjunto grande de dados com o objetivo de descobrir padrões e regras
significativos (Berry e Linoff, 1997). Esse processo pode ter duas abordagens: teste de
hipóteses e síntese de conhecimento. Teste de hipótese refere-se ao uso dos dados para
verificar ou negar uma hipótese ou noção prévia. Síntese de conhecimento é a descoberta de
uma informação sem nenhuma condição inicial. Pode ser direta (caso em que se deseja
explicar um atributo específico em função de outros dados) e indireta (caso em que se procura
relações sem foco em um atributo específico).
As técnicas de data mining podem ser divididas em: classificação, estimativa,
previsão, agrupamento por afinidade, agrupamento e descrição (Berry e Linoff, 1997). O
estudo referido envolverá, principalmente, a técnica de agrupamento por afinidade ou análise
de relacionamento.
Os fatores críticos de sucesso para projetos de data mining são (Hermiz, 1999):
1. Definição de um problema real articulado;
2. Garantia de dados de qualidade e em quantidade para o estudo;
3. Reconhecimento do caráter não estruturado do projeto;
4. Planejamento de aprendizado com o processo.
A preocupação desta pesquisa é a abordagem do segundo ponto, ou seja, o
desenvolvimento de mecanismos para a manutenção e disponibilização dos dados para a
realização do estudo. Isso demanda a construção de uma base acessível, consistente e íntegra
de dados, o que levou à proposição do data mart.
2.3 DATA WAREHOUSE
O data warehouse é uma coleção de dados não volátil, crescente no tempo, integrada e
orientada ao negócio para dar suporte a decisões gerenciais (Inmon, 1996). É a fonte de dados
para consulta da organização (Kimball, 1998).
Ele tem as seguintes características (Berson e Smith, 1997):
• É um banco de dados projetado para análise, que usa dados de várias aplicações.
• É projetado para um pequeno número de usuários com interações longas.
• É usado basicamente para leitura.
• É atualizado periodicamente (principalmente com adição de dados).
• Contém dados atualizados e históricos para fornecer informações do fluxo do negócio no
tempo.
• É formado por poucas e grandes tabelas.
• Destina-se à realização de consultas que resultam em um conjunto grande de dados e
geralmente envolvem leituras de tabelas inteiras e vários relacionamentos.
O data warehouse deve ter os seguintes objetivos (Kimball, 1998):
• Tornar a informação mais acessível.
2
•
•
•
•
Tornar a informação mais consistente, ou seja, informação de qualidade em toda a
organização. Os termos usados em uma parte da empresa devem ter o mesmo significado
em toda a empresa.
Ser uma fonte de informação adaptável e maleável. Deve ser projetado para mudança
constante sem que todo o sistema tenha que ser alterado.
Ser uma fonte segura para proteger a informação na empresa.
Deve ser a base para a tomada de decisão.
2.4 DATA MART
O data mart tem definição controversa junto aos autores (especialmente Kimball e
Inmon) e fabricantes de ferramentas.
Segundo Inmon o data mart é uma coleção de dados relacionados a alguma área da
empresa (algum processo específico), organizados para dar suporte à decisão e baseados nas
necessidades de um determinado departamento. Ele afirma que o data mart e o data
warehouse têm estruturas essencialmente diferentes e um conjunto de data marts dificilmente
pode ser integrado e, mesmo que for, não resultará em um data warehouse (Inmon, 1998).
Segundo Inmon o data mart é derivado do data warehouse.
Kimball define o data mart como um subconjunto lógico do data warehouse. De
acordo com sua abordagem, o data warehouse não passa da união de todos os data marts que
o constituem (Kimball, 1998).
Essa diferença de abordagem se reflete em opiniões controversas de cada autor em
relação ao processo de implantação do data warehouse. Ambos concordam que a implantação
da solução completa é muito complexa para ser feita de uma vez e ambos concordam que a
sustentação do projeto depende da entrega rápida de uma solução parcial que agrade os
usuários e justifique o investimento (Gallas, 1999). Mas a solução proposta por cada um é
diferente.
Kimball propõe a implantação de um data mart por vez, desde que seja feita uma
prévia modelagem da organização e que os data marts fiquem conformados de acordo com
essa modelagem (ver item 2.5). Inmon propõe a implantação iterativa do data warehouse, ou
seja, o sistema começa pequeno e evolui progressivamente em espaços curtos de tempo. Essa
evolução é sempre feita com base na modelagem inicial dos dados da organização (Inmon,
1998).
Nesse trabalho a motivação inicial é a construção de um data mart apenas e isso é
válido tanto sob a ótica de Kimball quanto de Inmon. No entanto a eventual ampliação da
solução para a construção de um data warehouse não é possível segundo Inmon e é
perfeitamente válida na abordagem de Kimball.
A conclusão preliminar a que se chega é que essa diferença de abordagem é mais
relativa à terminologia utilizada do que propriamente conceitual. Isso porque Inmon se refere
ao data mart como uma coleção de dados derivada do data warehouse, enquanto para
Kimball o data mart é a própria unidade lógica do data warehouse, ou seja, eles estão falando
de coisas diferentes.
No desenvolvimento do projeto piloto na biblioteca Karl A. Boedecker foi adotada a
abordagem de Kimball. Pudemos testar a implementação de um pequeno data mart paralelo
ao principal para dar suporte ao resultado do sistema de recomendações proposto. No entanto
a validação de uma estratégia de implementação como proposta por Kimbal em uma grande
organização não é objeto dessa pesquisa.
3
2.5 MODELAGEM DIMENSIONAL
Para o desenvolvimento de data warehouses o modelo mais viável é o modelo
dimensional em oposição ao modelo de entidade relacionamento (Kimball, 1998).
O modelo dimensional é composto por uma tabela com uma chave múltipla chamada
tabela fato (fact table) e por várias tabelas menores chamadas dimensões (dimension table).
Cada dimensão tem uma chave única que corresponde exatamente a um dos componentes da
chave múltipla da tabela fato. Para a visualização do modelo usaremos o resultado do item
3.2.5 correspondente ao modelo desenvolvido para o projeto piloto da biblioteca.
A implementação da solução completa do data warehouse em uma única etapa seria
uma tarefa muito difícil. A abordagem proposta por Kimball é a implementação de um data
mart de cada vez, ou seja, a abordagem de cada processo de negócio separadamente. Isso
corresponde a definir uma fact table de cada vez.
A dificuldade que surge então é como unir todos os data marts de forma que o todo
fique coerente e possa integrar toda a organização. Se os data marts forem incompatíveis
entre si eles nunca poderão compor um data warehouse. Kimball propõe que a modelagem de
cada data mart obedeça a uma arquitetura padrão que ele chama de via do data warehouse.
Para a construção da via é necessário ter dimensões “conformadas” e uma definição
padronizada para os fatos. Uma dimensão conformada é uma dimensão que significa a mesma
coisa em qualquer star schema em que esteja, ou seja, em qualquer data mart. As dimensões
conformadas são essenciais para manter a integração de todos os data marts no data
warehouse. Da mesma forma os fatos devem estar conformados. Isso significa dizer que se
um determinado fato é referenciado com medidas diferentes em dois processos (por exemplo
um produto cuja quantidade é medida em unidades em algum processo e em lotes em outro),
as duas medidas devem ser expressas nos dois data marts correspondentes e cada uma deve
ter um nome diferente.
Um aspecto importante no desenho das dimensões é a consideração a respeito da
mudança contínua. Existem três estratégias básicas para lidar com essas mudanças:
1. Alterar o registro original perdendo informações históricas.
2. Criar um novo registro usando outro valor para a chave.
3. Criar um campo “velho” na dimensão para guardar o atributo anterior.
O uso dessas estratégias varia em cada caso e a escolha entre elas deve ser baseada no
tamanho da dimensão, na velocidade de mudança e na necessidade de se manter informações
históricas.
O projeto de cada data mart deve levar em conta 4 passos básicos de acordo com
Kimball (1998). São eles:
1. Escolha do data mart: Corresponde a escolher o processo do negócio ou a(s) fonte(s)
operacional(is) dos dados. É conveniente começar o projeto com a escolha de um data
mart de uma única fonte e montar as dimensões conformadas desde o início de maneira
que os data marts seguintes possam se “plugar” na via.
2. Escolha da granularidade das tabelas fato: Corresponde a dizer o que é exatamente
cada registro da tabela fato. Geralmente essas tabelas devem ser o mais granulares
possível, principalmente para projetos de data mining onde o detalhe é essencial. As
medições menos granulares devem ser derivações das tabelas fato construídas de modo a
permitir melhora de performance em algumas consultas (tabelas agregadas).
3. Escolha das dimensões: Com a definição da granularidade a escolha das dimensões já
estará iniciada. Como o registro da tabela fato corresponde à medição de algum processo,
esse processo já estará naturalmente relacionado a algumas dimensões. No entanto o
projetista do data mart pode adicionar algumas dimensões de forma a tornar a informação
mais completa. Toda dimensão que puder ser relacionada ao fato específico de forma
única deve ser adicionada ao modelo.
4
4. Escolha das medidas: A escolha da granularidade também já identifica uma série de
medidas pertinentes. Essas medidas devem ser totalmente apropriadas à granularidade
escolhida para a tabela fato.
2.6 BUSINESS INTELLIGENCE
Business Intelligence (BI) é um termo introduzido pelo GartnerGroup no fim da
década de 1980 que se refere ao acesso e exploração de dados estruturados relativos a um
domínio específico, análise dos dados, desenvolvimento de conhecimento a partir dessa
análise e aplicação desse conhecimento para tomada de decisão (Harris e Dresner, 1999).
As ferramentas de BI incluem:
• Construção de consultas ad hoc,
• Geração de relatórios,
• DSS (Decision Support Systems),
• EIS (Executive Information System),
• Análise estatística (data mining),
• OLAP (OnLine Analytical Processing), entre outras.
Business Intelligence (BI) é uma forma de tornar útil o data warehouse. “A aplicação
de BI não pressupõe um data warehouse mas o data warehouse é inútil sem BI“ (Strange,
1999). Em relação à administração da biblioteca, ou ao estudo de data mining, o processo de
BI envolve a extração das informações necessárias a partir do data warehouse, ou data mart,
análise dessas informações (por meio de OLAP e relatórios, por exemplo) e tomada de
decisões com base nas mesmas, ou seja, envolve uma forma de usar os dados para facilitar a
administração.
3 O PROJETO NA BIBLIOTECA KARL A. BOEDECKER
A Biblioteca Karl A. Boedecker foi fundada em 1954 para dar suporte bibliográfico à
EAESP – FGV. Conta com acervo de 67 mil exemplares de 47 mil títulos de livros e 3,2 mil
exemplares de 1,8 mil títulos de teses e dissertações (Biblioteca Karl A. Boedecker. Relatório
Anual 1998, documento interno).
A biblioteca conta também com mais de 6 mil usuários cadastrados no sistema dos
quais pouco mais de 2 mil estão ativos. A biblioteca atende aos professores, alunos e
funcionários da escola, além de instituições externas.
Os alunos podem ser dos seguintes cursos:
• CGAE (Graduação em Administração de Empresas),
• CGAP (Graduação em Administração Pública),
• CEAG (Especialização em Administração para Graduados),
• CEAHS (Especialização em Administração Hospitalar),
• Doutorado,
• Mestrado
• MBA,
• PECE (Programa de Educação continuada)
• Alunos de intercâmbio
Além dos alunos correntemente matriculados a biblioteca atende também aos exalunos da escola.
Em face disso os usuários são classificados de acordo com seu tipo que podem ser
todos os citados acima.
Em relação aos itens, estes podem ser classificados como livros, teses e dissertações,
obras de referência, revistas etc.
5
A biblioteca Karl A. Boedecker é uma biblioteca especializada, ou seja, ela se
preocupa em atender prioritariamente algumas áreas específicas do conhecimento as quais:
ciências aplicadas e sociais voltadas para administração de empresas e economia. Isso não
implica ausência total de outras áreas mas a ênfase é dada para estas.
3.1.1 Situação Tecnológica
A biblioteca vem passando por processos de modernização, por exemplo com a
instalação, em 1995, do sistema VTLS. O sistema suporta todo o processo transacional da
biblioteca como controle de circulação, catalogação, busca por palavras e booleana, controle
de literatura básica, controle de periódicos, controle de estoque, relatórios estatísticos etc.
O sistema fornece arquivos com estatísticas de transações passadas, no entanto estes
arquivos servem apenas como controle e são ineficientes para uso analítico (daí a necessidade
observada de um data warehouse no ambiente de administração).
Todo o processo de empréstimo já se encontra automatizado, inclusive com o
reconhecimento do usuário e dos itens por códigos de barras. Os usuários receberam um
cartão com seu código de barras pessoal impresso que facilita essa identificação. Cada código
de usuário está associado a uma senha. Os livros também têm código de barras impresso.
De todo o acervo da biblioteca apenas cerca de 26.000 itens estão cadastrados
eletronicamente no VTLS. Esses itens são os que circularam depois da implantação do
sistema e/ou que foram adquiridos no período após a implantação do sistema. Em função
disso apenas esses itens serão cadastrados no data mart.
3.2 MODELAGEM DIMENSIONAL
3.2.1 Escolha do Data Mart
O modelo de dados desenvolvido partiu das necessidades do estudo do perfil de
usuários (Aranha, manuscrito). Para isso foi necessário desenvolver um único data mart
relativo às transações (ou circulação do acervo). A principal fonte para os dados é o sistema
transacional da biblioteca (VTLS) que gera arquivos flat com todas as transações relativas à
circulação do acervo.
3.2.2 Escolha da Granularidade da Tabela Fato
Nesse data mart cada fato, ou seja, cada registro na tabela fato corresponde a uma
transação que pode ser dos tipos: empréstimo, renovação e devolução. Esse fato não tem
nenhuma medida associada. Trata-se apenas da ocorrência de uma transação relacionando as
dimensões especificadas no registro.
3.2.3 Escolha e Definição das Dimensões
Usuários – dim_patron
A dimensão de usuário tem duas fontes principais de dados. Uma é a escola e a outra a
biblioteca. A escola forneceu dados referentes aos alunos como a média do curso e média no
vestibular. A biblioteca forneceu dados gerais sobre os usuários como endereço e dados
referentes à sua situação como usuário da biblioteca.
Os principais requisitos em relação aos usuários é que eles pudessem ser
identificáveis, tanto em relação ao seu papel na biblioteca como na escola. Além de poderem
ser identificados em função de diversos atributos como endereço, idade, sexo etc.
Para cada dimensão foi gerada uma chave para controle interno sem nenhum
significado fora do data mart. Essa chave é chamada surrogate key e funciona como uma
6
forma de tornar o data mart independente do sistema legado da biblioteca (Kimball, 1998).
Além dessa, a dimensão traz outras chaves e códigos para identificação do usuário na
biblioteca e na escola.
Foram adicionados também campos para descrição de características dos usuários
como idade, sexo e tipo do usuário, além de outros dados como endereço completo (separado
em vários campos), telefone, e-mail e data de cadastro do usuário na biblioteca. A separação
de dados como endereço em vários campos é aconselhável para as dimensões pois dessa
forma os dados são mais facilmente acessados.
Foram adicionados alguns campos relativos ao comportamento dos alunos na escola
como desempenho acadêmico, média no vestibular, entre outros. Esses atributos oferecem um
problema adicional na modelagem pois não são válidos para todos os tipos de usuários. A
questão é se nos casos em que o atributo é inválido (como desempenho acadêmico do
professor ou funcionário) o valor deve ser mantido nulo ou não. A princípio mantivemos
nulos os valores inválidos.
Finalmente a dimensão conta com atributos resultados de processamento externo, ou
seja, eles constituem uma agregação de valor à dimensão. O significado desses campos será
explicado no item 3.3.
Com relação à mudança contínua dessa dimensão, a opção na modelagem é que os
dados relativos a usuários antigos nunca sejam descartados. Para isso sempre poderemos criar
novas chaves artificiais mesmo que as chaves de produção sejam reutilizadas pela escola ou
pela biblioteca. No caso de alteração dos dados de algum usuário, esses dados serão
simplesmente alterados diretamente na dimensão.
Itens – dim_item
A dimensão de itens tem duas fontes principais. A primeira são os arquivos de
estatística gerados pelo VTLS e outra, a principal, são outros arquivos gerados pelo VTLS
que contêm diversos dados sobre todos os livros adquiridos em um determinado período.
Seria uma “tabela mestre” do VTLS sobre os itens. Essa dimensão também contém campos
derivados de modelagem e do uso de técnicas de data mining.
Foi criada também uma chave artificial além das chaves de produção usadas na
biblioteca para identificar o item. Uma das identificações é o call_number. É uma
identificação única para um determinado item que agrega o código CDU (ver item abaixo) e o
título e nome do autor de forma codificada. Para a atribuição desse código podem ser usadas
as tabelas de Cutter, Cutter-Sanborn e PHA entre outras. No caso da PHA, por exemplo, o
código é formado pela primeira letra do nome do autor, seguida por um código para o
sobrenome (de acordo com a tabela) e a primeira letra do título da obra (Prado, 1992).
Foram adicionados também: campos de referência ao assunto do livro (ver próximo
item); características básicas dos itens com título, autor, número de páginas data de aquisição
etc. e algumas variáveis realimentadas no data_mart por processamento externo (ver item
3.3).
Hierarquia de Assuntos
O principal requisito em relação a essa dimensão é que ela descreva os itens não só
pelos atributos diretos como título, autor, número de páginas etc., mas também com base em
uma estrutura hierarquizada de assunto (ou área do conhecimento) de forma que torne fácil o
relacionamento entre os itens e dos itens com outras dimensões. Para isso foi desenvolvido
um modelo que tirou proveito do sistema de classificação usado pela biblioteca.
Existem vários sistemas de classificação, entre os quais o de Melvil Dewey e o CDU.
Para bibliotecas gerais o sistema de Melvil Dewey é apropriado. Para bibliotecas mais
7
especializadas é interessante o uso do sistema CDU – Código Decimal Universal (Prado,
1992). A biblioteca Karl A. Boedecker utiliza o sistema CDU.
Esses sistemas procuram sistematizar todas as áreas do conhecimento. Trata-se de um
conjunto de códigos estruturados hierarquicamente e partindo de grandes áreas do
conhecimento para o mais particular. As áreas mais gerais em que o conhecimento é dividido,
segundo o CDU, são:
• 0 – Generalidades: o conhecimento, a cultura, a ciência, o saber, a escrita etc.
• 1 – Filosofia. Psicologia.
• 2 – Religião. Teologia.
• 3 – Ciências sociais.
• 4 – Vaga no momento.
• 5 – Ciências matemáticas, físicas e naturais. Ecologia.
• 6 – Ciências aplicadas. Tecnologia.
• 7 – Artes. Divertimento. Lazer. Esportes.
• 8 – Línguas. Lingüística. Filologia. Literatura.
• 9 – Geografia. Biografia. História e ciências auxiliares.
O CDU contém ainda diversos símbolos para classificar as obras segundo lugar,
tempo, língua etc. Ou seja, o CDU se presta a uma classificação mais minuciosa que o sistema
de Dewey.
A grande dificuldade na modelagem dessa dimensão é a definição da hierarquia dos
assuntos conforme o código CDU. Para isso foram definidos um campo para o código CDU,
cinco campos para definir a hierarquia dos assuntos, desde o nível 1 até o 5 e um campo
especial para definir o “assunto significativo” (ver item 3.3). Um item que tem código CDU
igual a “336.781.5”, terá assunto_nivel1 igual a “3”, assunto_nivel2 igual a “33” e assim por
diante.
Com relação à mudança contínua essa dimensão se comporta como a dimensão de
usuários. Só serão retirados itens quando estes forem descartados ou perdidos, de acordo com
a política da biblioteca.
Tempo – dim_time
A dimensão de tempo fornece uma extensa descrição para cada dia do ano e pode ser
rapidamente construída para vários anos. Essa dimensão tem por objetivo fornecer uma série
de informações a respeito da data em que ocorreu uma determinada transação. A manutenção
dessa dimensão envolve apenas acrescentar mais anos quando necessário.
Tipos de transação – dim_tipo_trans
Como a tabela fato representa tanto retiradas como renovações e devoluções, foi
necessária a introdução de uma dimensão de tipo de transação. Essa dimensão foi organizada
de acordo com a hierarquia de comandos do VTLS. O principal requisito em relação a essa
dimensão é que a consulta a um determinado tipo de transação seja imediato, o que pode ser
feito através de uma simples restrição em uma consulta.
Com relação á mudança contínua, essa dimensão será alterada manualmente sempre
que necessário.
Auditoria – dim_audit
A última dimensão acrescentada a esse data mart é a dimensão “audit”, que permite
realizar a auditoria no processamento do data_warehouse.
É gerada uma chave artificial para cada novo registro, correspondente a um
processamento no data mart, além de campos para identificar a data e hora de início do
8
processo em questão, o número de registros processados e o número de registros que
apresentaram problemas.
A tabela fato correspondente ao processamento auditado é identificada por um campo
tipo_carga. Cada tipo de carga é realizado em uma tabela fato diferente.
Com relação à mudança contínua, essa dimensão sempre terá registros adicionados.
Isso ocorre sempre que se der um novo processamento.
3.2.4 Escolha das medidas
Esse data mart não apresenta medidas para a granularidade escolhida para a tabela
fato. Trata-se de uma factless fact table ou tabela fato sem medidas (Kimball, 1998). Foi
acrescentado um campo com valor default de 1 para significar uma ocorrência e facilitar a
soma em consultas.
3.2.5 Resultado final
O Star Schema resultante pode ser visto na Figura 1.
A tabela fato tem cada registro com 5 campos de 4 bytes cada e 1 campo de 1 byte,
totalizando 21 bytes. De acordo com os dados colhidos em nossa amostra, se assumirmos uma
média de 6.000 transações mensais (com alguma folga) teríamos 72.000 transações anuais.
Para um histórico de 5 anos de transações esse data mart demandaria portanto um espaço de
72.000 x 5 x 21 bytes < 8 MB. Normalmente o tamanho das dimensões é desprezado por ser
bem menor que da tabela fato (Kimball, 1996).
Em face da dimensão reduzida, esse data mart pode perfeitamente ser gerenciado em
uma plataforma pequena com resultados satisfatórios.
dim_time
dim_time
time_key
time_key
full_date
full_date
day_of_week
day_of_week
...
...
dim_item
dim_item
item_key
item_key
item_id
item_id
call_number
call_number
...
...
fact_transações
fact_transações
time_key
time_key
dim_patron
dim_patron
item_key
item_key
patron_key
patron_key
patron_id
patron_id
codigo
codigo
...
...
patron_key
patron_key
tipo_trans_key
tipo_trans_key
audit_key
audit_key
ocorrencia
ocorrencia
dim_tipo_trans
dim_tipo_trans
tipo_trans_key
tipo_trans_key
grupo
grupo
acao_grupo
acao_grupo
...
...
dim_audit
dim_audit
audit_key
audit_key
data_carga
data_carga
status_carga
status_carga
...
...
Figura 1. Esquema do data mart de circulação
3.3 AGREGAÇÃO DE VALOR – DATA MINING
Com base nos dados coletados, de acordo com o modelo apresentado, foi conduzido o
estudo apresentado como motivação inicial dessa pesquisa.
O estudo desenvolvido pelo professor Francisco Aranha (manuscrito), realizado com o
uso de técnicas de data mining, propõe um modelo de cooperação indireta como forma de
gerar listas de recomendação de itens para cada pesquisador registrado no sistema. Estas listas
estão baseadas no comportamento de outros pesquisadores semelhantes a ele.
9
O modelo do data mart foi constantemente trabalhado de forma a possibilitar a
execução e comportar os resultados desse estudo, tanto com relação ao modelo conceitual
como à automatização do processo de carga e manutenção do sistema.
O desenvolvimento do modelo de cooperação indireta (e o conseqüente retrabalho no
data mart) segue a linha esquematizada na Figura 2.
dim_item
dim_item
item_key
item_key
...
...
Ass_signif
Ass_signif
...
...
Data Mart
Circulação
Estabelecimento de
assuntos significativos
Processamento
manual e
interativo
Definição dos
grupos temáticos
lookup_ass_signif
lookup_ass_signif
ass_signif
ass_signif
chave_gr_tematico
chave_gr_tematico
descricao
descricao
Stored procedure
segmenta()
Segmentação dos usuários
para cada grupo temático
dim_patron
dim_patron
patron_key
patron_key
patron_id
patron_id
codigo
codigo
...
...
fact_lista
fact_lista
dim_gr_tematicos
dim_gr_tematicos
chave_gr_tematico
chave_gr_tematico
descricao
descricao
n_grupos
n_grupos
...
...
dim_patron
dim_patron
Detalhe_patron
Detalhe_patron
patron_key
patron_key
...
...
rh
rh
metod_socio
metod_socio
marketing
marketing
...
...
patron_key
patron_key
a0
a0
a1
a1
...
...
item_key
item_key
dim_item
dim_item
dim_grupos
dim_grupos
patron_key
patron_key
item_key
item_key
...
...
cluster
cluster
chave_gr_tematico
chave_gr_tematico
a0
a0
...
...
cluster
cluster
dim_grupos
dim_grupos
rank
rank
cluster
cluster
chave_gr_tematico
chave_gr_tematico
a0
a0
a1
a1
...
...
dim_gr_tematicos
dim_gr_tematicos
chave_gr_tematico
chave_gr_tematico
descricao
descricao
n_grupos
n_grupos
...
...
Stored procedure
lista_recom()
Construção de uma lista de
recomendação para cada usuário
em cada grupo temático
Figura 2. Desenvolvimento do modelo de cooperação indireta.
3.3.1 Assuntos significativos
O assunto significativo (AS) é um artifício utilizado para reduzir a cardinalidade dos
assuntos através do tratamento da taxonomia da forma mais conveniente para o problema.
Este procedimento é denominado consolidação (Aranha, manuscrito).
Com isso os itens são agrupados em segmentos significativos em algum nível da
hierarquia de assunto, de acordo com o número de transações associadas. Assim se o assunto
336.78, por exemplo, tiver um número grande de transações, ele será o assunto significativo
para esse item. Senão a hierarquia será diminuída para “336.7”, “336” etc. até que um desses
assuntos seja significativo.
Em relação ao modelo, a definição dos AS foi contemplada através da adição do
atributo ass_signif na dimensão de itens. O estabelecimento dos AS foi realizado
manualmente e esses assuntos não serão modificados em uma base regular, ou seja, a
manutenção será feita esporadicamente.
A automatização desse processo pode ser feita adotando-se um valor mínimo para o
número de transações de um determinado assunto comparado com o total (ou um número
máximo de assuntos significativos) e adicionando-se uma rotina simples no processo de carga
das transações. No entanto foi decidido durante o desenho do sistema que a definição dos AS
seria manual.
10
Ficou definida uma tabela chamada lookup_ass_signif com todos os AS, sua descrição
e uma chave para a dimensão de grupos temáticos. A Tabela 1 mostra cada assunto já
relacionado com um grupo temático de acordo com a fase seguinte do projeto: a definição dos
grupos temáticos (GT).
Tabela 1. Assuntos significativos definidos pela análise.
Ass_signif
659
658.8
34
651
654
62
36
658.5
2
7
8
9
3
330.1
339
330.3
33
30
35
31
32
657
658.6
658.7
61
6
658.0
65
1
658.3
658
331
R
37
0
39
334
68
63
5
336
658.1
Descrição
Publicidade e Propaganda. Relações Públicas.
Marketing. Vendas. Distribuição.
Direito. Jurisprudência.
Escritório.
Telecomunicações e Telecontrole.
Engenharia. Tecnologia em Geral.
Assistência. Previdência. Seguridade Social.
Administração da Produção.
Religião. Teologia.
Arte. Esportes.
Língua. Literatura.
Geografia. Biografia. História.
Ciências Sociais. Direito. Administração
Teoria Econômica. Conceitos de economia.
Comércio Internacional.
Dinâmica Econômica.
Economia.
Metodologia.
Administração Pública. Governo. Assuntos Militares
Demografia. Sociologia.
Política.
Contabilidade.
Comércio.
Administração de Materiais.
Ciências Médicas.
Ciências Aplicadas. Medicina. Tecnologia.
Administração.
Organização e Administração.
Filosofia. Psicologia.
Pessoal. Fator Humano. RH.
Administração de Empresas. Organização
Trabalho. Emprego. Economia do Trabalho.
Referência.
Educação. Ensino.
Generalidades. Ciência e Conhecimento.
Antropologia.
Cooperativismo
Indústria.
Agricultura.
Matemática. Ciências Naturais.
Finanças Públicas.
Finanças.
Grupo temático
Marketing
Marketing
Outros
Outros
Outros
Outros
Outros
Outros
Outros
Outros
Outros
Outros
Outros
Economia
Economia
Economia
Economia
Metodologia/sociologia/pol./adm.publ.
Metodologia/sociologia/pol./adm.publ.
Metodologia/sociologia/pol./adm.publ.
Metodologia/sociologia/pol./adm.publ.
Contabilidade/materiais
Contabilidade/materiais
Contabilidade/materiais
Adm. hospitalar
Adm. hospitalar
Adm. hospitalar
RH
RH
RH
RH
RH
Educação/antropologia
Educação/antropologia
Educação/antropologia
Educação/antropologia
Cooperativa/agricultura
Cooperativa/agricultura
Cooperativa/agricultura
Finanças
Finanças
Finanças
11
3.3.2 Grupos temáticos
Esse passo também é realizado manualmente pois a definição não será alterada em
uma base regular, ou seja, os 10 GT encontrados permanecerão inalterados até que se decida
que devem mudar.
A definição leva em conta um agrupamento dos AS de acordo com uma técnica de
análise de cesta (Aranha, manuscrito). Cada grupo (ou cesta) de AS é um grupo temático. A
análise definiu 10 GT (conforme a Tabela 1) que formaram a dimensão chamada
dim_gr_tematicos.
3.3.3 Segmentação dos usuários
A segmentação dos usuários é feita de forma a se encontrarem grupos de usuários
semelhantes no seu comportamento quanto à retirada de itens com os mesmos assuntos
significativos. O procedimento utilizou um algoritmo de análise de agrupamento (Aranha,
manuscrito).
Como forma de automatizar o processo esse algoritmo foi desenvolvido em uma
stored procedure do SGBD (Sistema Gerenciador de Banco de Dados – Informix™).
O algoritmo é repetido para todos os grupos temáticos. Primeiramente é construída
uma tabela chamada main com todos os usuários do grupo temático corrente e seu perfil de
assuntos. Essa tabela é criada e destruída para cada grupo temático com base na tabela
detalhe_patron. A tabela detalhe_patron constitui um snowflake, ou tabela marginal do data
mart (Kimball, 1998) e serve para caracterizar os usuários com base nos assuntos
significativos já consultados pelos mesmos. Ela é atualizada a cada carga no data mart.
São definidas então “sementes” com valores aleatórios para todos os AS a partir da
tabela main. Cada semente passa a ser um grupo na dimensão dim_grupos (Tabela 2).
Tabela 2. Dim_grupos
Colunas
Cluster
Chave_gr_tematico
a0
a1
...
a9
Ar
N_usuarios
Descrição
Chave única para os grupos
Chave externa para o grupo temático correspondente a esse grupo.
Valor da semente correspondente a esse grupo nessa coordenada
"
...
"
"
Nº de usuários nesse grupo
Aos usuários são então atribuídos grupos de acordo com sua distância em relação às
sementes em um processo iterativo até que o resultado seja estável entre duas iterações, ou
seja, até que os grupos de cada usuário não se alterem.
Com relação ao modelo de dados, a implementação desse agrupamento foi feita pela
inclusão de 10 atributos na dimensão de usuários. Cada um desses campos é uma chave
externa para a dimensão de grupos.
Com isso se torna possível consultar o data mart com base em uma restrição pelo
grupo, ou seja, é possível acessar as transações de certo indivíduo e de outros usuários do
mesmo grupo (ou semelhantes a ele). Essa é a base para a construção das listas de
recomendação, o último passo do processo.
3.3.4 Listas de recomendação
A construção das listas de recomendação envolve na verdade a definição de outra
tabela fato que chamamos fact_lista. Essa tabela fato tem três chaves externas para as
12
dimensões de usuários, itens e grupos; e uma medida chamada rank que corresponde à
relevância da ligação respectiva.
A automatização dessa etapa do processo também foi feita com o uso de uma stored
procedure chamada lista_recom().
Essa stored procedure simplesmente cria uma tabela temporária com todas as
transações que envolvam os grupos do qual participa o usuário em questão e insere na tabela
fact_lista os itens distintos com um contador para os itens mais relevantes – a medida rank.
Para o preenchimento são descartados os itens que o usuário já retirou, de forma que só sejam
recomendados os itens novos para ele.
4 ADEQUAÇÃO TECNOLÓGICA
A adequação tecnológica diz respeito à adoção de uma solução mínima suficiente para
o problema em questão. A conclusão dessa pesquisa é de que o melhor método para garantir
essa adequação é a implementação do sistema por etapas, ou seja, de uma forma progressiva.
Com relação ao modelo dimensional isso significa implementar um data mart de cada
vez, na visão de Kimball, ou implementar o sistema iterativamente, na visão de Inmon. De
qualquer forma essa implementação por etapas garante a possibilidade de conseguir resultados
preliminares satisfatórios com um menor investimento inicial. O processo proposto por
Kimball de implementação de um data mart de cada vez foi testada com sucesso no projeto
piloto.
Com relação à estrutura tecnológica, a implementação por etapas significa a adoção de
uma solução distribuída para o data warehouse. A solução distribuída corresponde à
implantação do sistema em vários servidores em uma rede, de forma que o sistema comece
pequeno e cresça de acordo com a necessidade. Isso torna o custo inicial com hardware e
software bem menor que em uma solução centralizada (Inmom, 1996).
Ainda com relação ao hardware necessário, existe também a possibilidade lançada
pela HP® de adquirir uma máquina com capacity on demand. A máquina é adquirida com um
número reduzido de recursos (de processamento e memória) que podem ser aumentados a
medida em que forem necessários.
Com relação ao back room, ou processo de data stage, a adequação tecnológica pode
significar a adoção de uma solução temporária (desenvolvimento de código, por exemplo) nas
primeiras fases do projeto. Um tipo de solução provisória também foi testada com sucesso no
projeto piloto.
E finalmente, com relação ao front room, pode ser adequado realizar processos
simples de data mining e visualização sem o uso de uma ferramenta definitiva na fase inicial
do projeto. Isso somente será viável se os usuários forem familiarizados com algum tipo de
ferramenta de consulta (como o Access™, cujo uso como ferramenta de front room foi
testado no projeto).
Com relação aos recursos humanos necessários, o mais comum nesses projetos é a
contração de consultoria especializada (outsource). No caso de bibliotecas de escolas, fica a
sugestão do incentivo aos alunos para que desenvolvam pesquisas para implementar os
sistemas.
5 CONCLUSÃO
Nessa pesquisa foram propostos um modelo e uma metodologia de implantação de um
data mart (extensível para um data warehouse) para a circulação do acervo de bibliotecas
genéricas.
13
O projeto piloto, desenvolvido na biblioteca Karl A. Boedecker, conseguiu testar com
sucesso a metodologia proposta, além de ter dado suporte a um estudo de cooperação indireta
com uso de técnicas de data mining.
Também pudemos testar algumas técnicas de implantação desse tipo de tecnologia,
entre elas a implantação de dois data marts relacionados e a realimentação de informações no
data mart a partir de processamento externo.
A pesquisa desenvolveu também abordagens para a adoção de uma solução
“tecnologicamente adequada”, de forma a viabilizar projetos com baixo orçamento. Essas
abordagens têm como enfoque tornar a implantação do sistema progressiva, reduzindo o custo
inicial do projeto e permitindo que ele cresça à medida do necessário.
Essa adequação tecnológica foi também amplamente testada no projeto piloto.
As principais sugestões para a continuação da pesquisa são a integração completa do
sistema desenvolvido com a Internet, além do uso do sistema para outros estudos baseadas em
técnicas de data mining, como análise de redes.
6 REFERÊNCIAS BIBLIOGRÁFICAS
ARANHA, Francisco. E-Service em Bibliotecas: Geração de Valor para Pesquisadores por
Meio de Cooperação Indireta. Texto manuscrito ainda não publicado.
BEAUMONT, Jane. Trends in Library Automation. 1998. Endreço eletrônico:
http://fox.nstn.ca/~jbeaumon/ola98/index.htm, link válido em 15/11/1999
BERRY, Michael. J. A, LINOFF, Gordon. Data Mining Techniques for Marketing Sales and
Customer Support, New York: John Wiley & Sons, 1997
BERSON, Alex, SMITH, Stephen J. Data Warehousing, Data Mining & OLAP, New York:
McGraw-Hill, 1997
CABENA, Peter; et al. Discovering Data Mining. From Concept to Implementation. New
York: Prentice Hall, 1997
DONNARD, Heloisa e BOREGAS, Edmilson. A experiência da biblioteca no processo de
informatização. Documento apresentado no 1º Encontro Nacional de Usuários do VTLS,
realizado na UERJ, Universidade Estadual do Rio de janeiro, RJ, 16 de setembro de 1998
CRESNER, H. Rumors of Data Mining's Demise Are Greatly Exaggerated. Gartner
Research
and
Advisory
Services,
11/11/1998.
Endereço
eletrônico:
http://intranet.gv.br/gartner, link válido em 12/04/2000.
FARIAS, Andréa. A hora e a vez dos data marts. ComputerWorld, 06/04/1998. Endereço
eletrônico: http://www.uol.com.br/computerworld/abre.htm, link válido em 15/04/2000.
GIURLANI, Silvia. O pragmatismo dos negócios. ComputerWorld, 16/08/1999. Endereço
eletrônico: http://www.uol.com.br/computerworld/abre.htm, link válido em 15/04/2000.
GALLAS, Susan. Kimball Vs. Inmon. DM Review. Setembro 1999. Endereço eletrônico:
http://www.dmreview.com, link válido em 15/04/2000.
HARRIS, K. e DRESNER, H. Business Intelligence Meets Knowledge Management.
Gartner Research and Advisory Services, 01/03/1999. Endereço eletrônico:
http://intranet.gv.br/gartner, link válido em 12/04/2000.
14
HERMIZ, Keith B., Ph.D. Critical Success Factors for Data Mining Projects. DM Review,
Fevereiro 1999. Endereço eletrônico: http://www.dmreview.com, link válido em
15/04/2000.
INMON, Willian H. Building the Data Warehouse. 2.ed. New York: John Wiley & Sons,
1996. 401p.
INMON, Willian H. Data Mart Does Not Equal Data Warehouse. DM Review. 01/05/1998.
Endereço eletrônico: http://www.dmreview.com, link válido em 15/04/2000.
KIMBALL, Ralph. The Data Warehouse Toolkit: practical techniques for building
dimensional data warehouses. New York: John Wiley & Sons, 1996. 388p.
KIMBALL, Ralph; et al. The Data Warehouse Lifecycle Toolkit: expert methods for
designing, developing, and deploying data warehouses. New York: John Wiley & Sons,
1998. 771p.
KOHARI, Moiz. Unix, Windows NT and Linux. DM Review. Abril, 2000. Endereço
eletrônico: http://www.dmreview.com, link válido em 15/04/2000.
LUMEK, Roberta, Information Technology and Libraries. Library Management, vol. 5 – n. 3,
1984. MCB University Press.
ORFALI, Robert; et al. Client/Server Survival Guide. 3ª ed. New York: John Wiley & Sons,
1999. 762p.
PEPPERS, Don, ROGERS, Martha. Is your company ready for one-to-one marketing?
Harvard Business Review, January-February 1999, p. 151-163.
PRADO, Heloisa de A. Organização e Administração de Bibliotecas. 2.ed. São Paulo: T.A.
Queiroz, 1992.
RAMOS, Tagil O. Data Warehouse perde espaço para Data Mart nas empresas.
ComputerWorld.
25/05/1998.
Endereço
eletrônico:
http://www.uol.com.br/computerworld/abre.htm, link válido em 15/04/2000.
STRANGE, K. Data Warehouse Enthusiasm Conceals Vendor Turmoil. Gartner Research
and Advisory Services. 03/02/1999. Endereço eletrônico: http://intranet.gv.br/gartner, link
válido em 12/04/2000.
STRANGE, K. Key Issues: Data Warehouse Operations and Manageability. Gartner
Research
and
Advisory
Services.
04/01/1999.
Endereço
eletrônico:
http://intranet.gv.br/gartner, link válido em 12/04/2000.
THOMSEN, Erik. OLAP Solutions: building multidimensional information systems. New
York: John Wiley & Sons, 1997. 576p.
WESTPHAL, Christopher, BLAXTON Teresa. Data Mining Solutions: methods and tools for
solving real-world problems. New York: John Wiley & Sons, 1998. 617p.
15