Implantação de Tecnologia de Data Warehouse em Bibliotecas com Uso de Tecnologia Adequada

Transcrição

1 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 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 A base de dados inicial continha cerca de transações (entre empréstimos, renovações e devoluções de itens) envolvendo usuários e 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

3 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

4 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 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

5 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

6 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 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 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 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 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 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

7 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 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

8 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 , 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

9 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 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 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 transações mensais (com alguma folga) teríamos transações anuais. Para um histórico de 5 anos de transações esse data mart demandaria portanto um espaço de 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 time_key full_date day_of_week dim_patron patron_key patron_id codigo dim_tipo_trans tipo_trans_key grupo acao_grupo fact_transações time_key item_key patron_key tipo_trans_key audit_key ocorrencia Figura 1. Esquema do data mart de circulação dim_item item_key item_id call_number dim_audit audit_key data_carga status_carga 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

10 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. Data Mart Circulação Estabelecimento de assuntos significativos dim_item item_key Ass_signif lookup_ass_signif ass_signif chave_gr_tematico descricao dim_gr_tematicos chave_gr_tematico descricao n_grupos Processamento manual e interativo dim_patron patron_key patron_id codigo dim_grupos cluster chave_gr_tematico a0 a1 Definição dos grupos temáticos fact_lista item_key patron_key cluster rank dim_gr_tematicos chave_gr_tematico descricao n_grupos Segmentação dos usuários para cada grupo temático dim_item item_key Stored procedure lista_recom() Stored procedure segmenta() Construção de uma lista de recomendação para cada usuário em cada grupo temático dim_patron patron_key rh metod_socio marketing Detalhe_patron patron_key a0 a1 dim_grupos cluster chave_gr_tematico a0 Figura 2. Desenvolvimento do modelo de cooperação indireta 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 , 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

11 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 Descrição Grupo temático 659 Publicidade e Propaganda. Relações Públicas. Marketing Marketing. Vendas. Distribuição. Marketing 34 Direito. Jurisprudência. Outros 651 Escritório. Outros 654 Telecomunicações e Telecontrole. Outros 62 Engenharia. Tecnologia em Geral. Outros 36 Assistência. Previdência. Seguridade Social. Outros Administração da Produção. Outros 2 Religião. Teologia. Outros 7 Arte. Esportes. Outros 8 Língua. Literatura. Outros 9 Geografia. Biografia. História. Outros 3 Ciências Sociais. Direito. Administração Outros Teoria Econômica. Conceitos de economia. Economia 339 Comércio Internacional. Economia Dinâmica Econômica. Economia 33 Economia. Economia 30 Metodologia. Metodologia/sociologia/pol./adm.publ. 35 Administração Pública. Governo. Assuntos Militares Metodologia/sociologia/pol./adm.publ. 31 Demografia. Sociologia. Metodologia/sociologia/pol./adm.publ. 32 Política. Metodologia/sociologia/pol./adm.publ. 657 Contabilidade. Contabilidade/materiais Comércio. Contabilidade/materiais Administração de Materiais. Contabilidade/materiais 61 Ciências Médicas. Adm. hospitalar 6 Ciências Aplicadas. Medicina. Tecnologia. Adm. hospitalar Administração. Adm. hospitalar 65 Organização e Administração. RH 1 Filosofia. Psicologia. RH Pessoal. Fator Humano. RH. RH 658 Administração de Empresas. Organização RH 331 Trabalho. Emprego. Economia do Trabalho. RH R Referência. Educação/antropologia 37 Educação. Ensino. Educação/antropologia 0 Generalidades. Ciência e Conhecimento. Educação/antropologia 39 Antropologia. Educação/antropologia 334 Cooperativismo Cooperativa/agricultura 68 Indústria. Cooperativa/agricultura 63 Agricultura. Cooperativa/agricultura 5 Matemática. Ciências Naturais. Finanças 336 Finanças Públicas. Finanças Finanças. Finanças 11

12 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 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 Descrição Cluster Chave única para os grupos Chave_gr_tematico Chave externa para o grupo temático correspondente a esse grupo. a0 Valor da semente correspondente a esse grupo nessa coordenada a1 " a9 " Ar " N_usuarios 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 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

13 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

14 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 Endreço eletrônico: 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: 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: link válido em 15/04/2000. GIURLANI, Silvia. O pragmatismo dos negócios. ComputerWorld, 16/08/1999. Endereço eletrônico: link válido em 15/04/2000. GALLAS, Susan. Kimball Vs. Inmon. DM Review. Setembro Endereço eletrônico: 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: link válido em 12/04/

15 HERMIZ, Keith B., Ph.D. Critical Success Factors for Data Mining Projects. DM Review, Fevereiro Endereço eletrônico: link válido em 15/04/2000. INMON, Willian H. Building the Data Warehouse. 2.ed. New York: John Wiley & Sons, p. INMON, Willian H. Data Mart Does Not Equal Data Warehouse. DM Review. 01/05/1998. Endereço eletrônico: 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, p. KIMBALL, Ralph; et al. The Data Warehouse Lifecycle Toolkit: expert methods for designing, developing, and deploying data warehouses. New York: John Wiley & Sons, p. KOHARI, Moiz. Unix, Windows NT and Linux. DM Review. Abril, Endereço eletrônico: link válido em 15/04/2000. LUMEK, Roberta, Information Technology and Libraries. Library Management, vol. 5 n. 3, MCB University Press. ORFALI, Robert; et al. Client/Server Survival Guide. 3ª ed. New York: John Wiley & Sons, p. PEPPERS, Don, ROGERS, Martha. Is your company ready for one-to-one marketing? Harvard Business Review, January-February 1999, p PRADO, Heloisa de A. Organização e Administração de Bibliotecas. 2.ed. São Paulo: T.A. Queiroz, RAMOS, Tagil O. Data Warehouse perde espaço para Data Mart nas empresas. ComputerWorld. 25/05/1998. Endereço eletrônico: 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: 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: link válido em 12/04/2000. THOMSEN, Erik. OLAP Solutions: building multidimensional information systems. New York: John Wiley & Sons, p. WESTPHAL, Christopher, BLAXTON Teresa. Data Mining Solutions: methods and tools for solving real-world problems. New York: John Wiley & Sons, p. 15