Povoamento de Sistemas de Dados para Suporte à Decisão Assistido
por Agentes
Anália Lourenço Joaquim Gonçalves Orlando Belo
Departamento de Informática Universidade do Minho
Portugal
Resumo
A selecção, extracção, transformação e integração de dados são tarefas bastante comuns em sistemas de informação empresariais. Tal pode-se justificar pela necessidade que os gestores das empresas têm em conciliar informação em sistemas de dados especializados, normalmente organizados por assuntos. Assim, não é de surpreender que este tipo de tarefas e mecanismos associados estejam em contínuo aperfeiçoamento e evolução por forma a assegurar de modo efectivo a satisfação dos requisitos de informação dos gestores (frequentemente variáveis), bem como o seu próprio desempenho em processos de tomada de decisão. Contudo, os dados recolhidos apresentam na maioria dos casos ruído que, embora não causando uma entropia significativa ao nível transaccional, dificulta a sua análise e consequentemente o seu tratamento. Por outro lado, a própria estrutura de armazenamento nem sempre é a mais adequada, visto que, a maior parte das vezes, existe uma preocupação exacerbada com os requisitos transaccionais, o que faz com que os dados sejam depois despejados em verdadeiros contentores de informação muito pouco interessantes e úteis. Assim, no sentido de contrariar situações como as referidas e de "ilibar" os sistemas transaccionais de quaisquer responsabilidades de tratamento e armazenamento de dados “mortos”, desenhámos e desenvolvemos uma ferramenta computacional para suporte à realização das operações de selecção, extracção transformação e integração de dados, prestando especial cuidado ao nível das estruturas de suporte a processos de limpeza, consistência e integridade de dados. Este artigo visa descrever sucintamente a ferramenta desenvolvida, assim como o suporte que disponibiliza para processos de alimentação de Sistemas de Data Warehousing, recorrendo para o efeito à construção de uma comunidade de agentes que simbioticamente interagem, a fim de promover esse tipo de actividade.
Palavras chave: Sistemas de Data Warehousing, Computação Baseada em Agentes, Sistemas de Bases de Dados, Computação Java.
1 Introdução
Seleccionar, extrair, transformar e integrar dados em repositórios de informação especializados são tarefas bastante comuns em ambientes de Sistemas de Suporte à Decisão (SSD) [Meyer e Cannon 1998] [Poe et al. 1998]. Contudo, a frequência com que estas tarefas são levadas a cabo, bem como o volume e a qualidade dos dados que elas envolvem, fazem com que o sucesso da sua realização apresente contornos bastante variáveis. De facto, ninguém tem dúvidas de que os processos operacionais em seu redor devem ser robustos e, simultaneamente, bastante flexíveis face a possíveis alterações na natureza dos dados ou mesmo perante novas exigências organizacionais. No que diz respeito à frequência com que estas tarefas são desempenhadas, é de notar que quanto maiores forem os períodos da sua realização mais fácil se torna o planeamento do seu processamento, assim como mais fácil é a avaliação de possíveis
“mutações” na informação e a correcção de eventuais erros que possam ter sido cometidos no passado da organização. Quando a frequência operatória é elevada, o risco inerente aumenta consideravelmente, visto que existe uma margem ínfima de correcção de erros, não sendo possível uma análise eficiente do processo em tempo real.
Assim, os processos relacionados com a selecção, extracção, transformação e integração de dados, normalmente designados por processos de alimentação de dados, devem ser muito bem planeados face às características específicas da informação que irão manipular e aos objectivos dos agentes de decisão empresariais, já que, embora se pretenda disponibilizar um conjunto de mecanismos o mais genéricos e abstractos possível de suporte a essas tarefas, torna-se indiscutível a necessidade (obrigatoriedade) de estes terem em conta a natureza dos dados em causa. Por exemplo, não se podem tratar dados relativos às vendas de um supermercado e às análises clínicas de um hospital do mesmo modo, visto que a relevância da cada elemento do conjunto de dados tem um peso próprio dentro do seu contexto de análise e de aplicação. Desta forma, em algumas situações existe a possibilidade de se desprezar informação, por esta ser escassa ou de má qualidade, pois tais elementos não são indispensáveis à caracterização do quadro pretendido, enquanto noutros casos o valor destes dados, em termos de análise, acarreta a necessidade de aproveitamento de tudo aquilo que se encontra disponível, independentemente da vulnerabilidade dos mesmos.
Embora toda esta problemática esteja presente quer nos sistemas transaccionais quer nos sistemas de processamento analítico, a verdade é que a crescente necessidade de separação destes dois universos, com a consequente ascensão dos Sistemas de Data Warehousing (SDW) [Kimball 1996] [Inmon 1996], como pilares dos processos de análise, valoriza essas tarefas, suscitando uma maior atenção sobre elas. Os SDW exigem que a informação seja consistente e coerente em termos das diversas fontes de dados de onde é extraída e face à estrutura de análise montada. É irrefutável que um sistema deste tipo não apresenta quaisquer mais valias se os dados que sustenta não oferecerem uma certa credibilidade, isto é, não tiverem sido limpos e tratados convenientemente de acordo com os requisitos operacionais dos sistemas e com os critérios de análise e tomada de decisão previamente definidos pelos gestores empresariais. Por outras palavras, o que torna um SDW proveitoso é a fiabilidade que o utilizador/analista/gestor pode ter relativamente à sua informação. Para isso é desejável e necessário que os processos de alimentação dos SDW consigam eliminar todas as impurezas que infectam a informação recolhida nos sistemas operacionais ou pelo menos a maior parte delas, para além de homogeneizar os vários elementos provenientes das diversas fontes de informação disponíveis. Neste sentido foi desenvolvida uma ferramenta computacional especialmente concebida para acolher e suportar, em termos genéricos, o processo de alimentação dos repositórios de dados de um SDW. Esta ferramenta visa solucionar os principais problemas levantados ao longo desse processo, ao mesmo tempo que pretende automatizá-lo e padronizá-lo. Com esta ferramenta pretende-se trabalhar os dados desde o momento em que o utilizador define os critérios de selecção da informação, sobre uma ou várias fontes de informação, até à altura em que a sua integração no correspondente SDW seja possível. Logicamente que, desde a estruturação dos pedidos dos utilizadores até à fusão das várias respostas a uma mesma questão, passando pela sustentação de uma rede de comunicação entre o sistema e as distintas fontes de dados, tudo foi pensado de modo a conferir a maior flexibilidade possível à ferramenta, ao mesmo tempo que foram asseguradas premissas tão básicas como a consistência, integridade e segurança dos dados, bem como a segurança e a robustez do acesso e da manipulação das diversas funcionalidades providenciadas pelo sistema. O trabalho aqui descrito faz parte integrante do processo de desenvolvimento e implementação de uma das camadas de suporte de um ambiente para SDW assistido por agentes [Belo 1999].
2 O Modelo Conceptual do Sistema
Em termos genéricos, o sistema concebido pode ser encarado como um caso particular de uma comunidade de agentes [Ferber 1999] [Wooldridge e Jennings 1995] [Jennings e Wooldridge 1995] que interagem, cooperando de modo a atingir um objectivo comum: a realização com sucesso de processos de alimentação de uma Data Warehouse (DW). Dentro desta comunidade subsistem agentes de diversos tipos, organizados segundo as suas próprias competências, que são responsáveis pela resolução de problemas e/ou tarefas específicas em cada processo de alimentação que suportem. Assim, podem-se destacar os seguintes tipos de agentes:
- O Coordenador, que é o agente responsável pela "sincronização" da comunidade, garantindo a activação atempada dos agentes que devem intervir num determinado processo de alimentação e a transmissão de tarefas e/ou informação entre estes.
- O Relógio, que obviamente estabelece a bússola temporal que orienta todo o sistema de agentes e mecanismos associados.
- O Agente de Pesquisa da Agenda, o qual, em períodos regulares de tempo, averigua se existem trabalhos marcados para determinada data e hora, advertindo o coordenador de tal facto e promovendo a activação do respectivo processo de alimentação.
- O Distribuidor de Trabalho, que organiza o processamento específico de determinado processo, desencadeando a realização de cada uma das tarefas que o compõem, direccionando-as para as fontes de informação correspondentes e reescalonando-o para próximas execuções, se assim estiver estipulado.
- O Agente Extractor, o qual realiza a extracção dos dados propriamente dita (comunica com a fonte de informação e extrai desta a informação requerida) e a respectiva normalização. No caso de ocorrer a necessidade de despoletar simultaneamente mais do que um processo de extracção, o agente extractor pode-se replicar, permitindo assim a execução paralela dos vários processos de extracção.
- O Gestor de Histórias é tipicamente um agente que faz a gestão das logfiles do sistema, sendo responsável pelo registo de todo e qualquer evento ocorrido no sistema, segundo as orientações do agente de coordenação.
- O Agente de Estatísticas, as quais permitem ter uma noção de como decorreu o processo relativo a uma dada tarefa, a um dado processo de alimentação, quer em termos de tempo dispendido, quer em termos da natureza dos dados manipulados. Existe ainda outro tipo de entidades que ajudam os agentes do sistema a desenvolver as suas actividades ou a servirem de suporte/matéria-prima a essas mesmas actividades. Dada a necessidade de contacto com as distintas fontes de informação, potencialmente localizadas em diferentes sítios distribuídos pela organização, foram criados servidores específicos de pedidos a instalar em cada uma das máquinas onde estão localizadas as diferentes fontes de informação. Estes servidores promovem o contacto entre o sistema - os agentes extractores - e as fontes de informação disponíveis, possibilitando deste modo quer a colocação de uma dada questão a determinada base de dados quer o retorno da respectiva resposta.
Em termos da actividade de agendamento, desenvolveram-se entidades que dão corpo a cada um dos tipos de trabalho que interessa tratar. Desde trabalhos imediatos ou de realização única a trabalhos de natureza periódica. Adicionalmente, decidiu-se manter cada agenda em formato relacional, garantindo desta forma a consistência, a coerência e a integridade dos dados e, simultaneamente, permitindo a existência de diversas agendas - sob as quais são escalonados distintos trabalhos -, de entre as quais apenas uma se encontrará activa em cada momento. Assim sendo, a ferramenta integra distintos elementos funcionais, vocacionados para as distintas etapas do processo de alimentação. De entre estes, destaca-se actualmente o agente de
distribuição de trabalho, o qual é responsável pelo agendamento e pela activação dos trabalhos, bem como pelo tratamento e integração dos correspondentes resultados (respostas às questões colocadas) no SDW. Isto é, a actividade de agendamento “alimenta” o sistema com pedidos de informação dirigidos ao distribuidor de trabalho, o qual despoleta a sua resolução, recorrendo para o efeito aos agentes de extracção, e, quando as correspondentes respostas se encontrarem disponíveis, caber-lhe-á o respectivo tratamento com vista à construção, se possível, de uma única resposta. Junto das bases de dados dos sistemas operacionais encontrar-se-ão somente os agentes de extracção, activados pelos servidores de cada uma das máquinas aquando da chegada de novos pedidos de informação.
Gestor Logs Relógio
Distribuidor Coordenador Log Files <registo de um evento> <evento> <activação de processo> <tarefas> <tarefas> <iniciar> Agenda <nova tarefa> . . . Extractor(1) Extractor(2) Extractor(n) <lista de tarefas> Servidor do sistema Colector Resultados <inserir resultados> <respostas>
Servidor máquina X Servidor máquina Y
BD(X1) BD(X2) Sistemas Operacionais X Extractor(X) BD(Y1) BD(Y2) Sistemas Operacionais Y Extractor(Y) Estatísticas Estatísticas <inserir estatísticas> <estatísticas> Plataforma Computacional (i)
Plataforma Computacional (j) Plataforma Computacional (k)
Figura 1: Funcionamento genérico do sistema.
Por fim, resta sublinhar que o agente relógio constitui a pedra de toque do sistema, visto que todas e cada uma das actividades a realizar manifestam um cariz temporal acentuado. De facto, estas são despoletadas mediante uma "senha temporal", tornando-se imprescindível a adequada sincronização das distintas operações, especialmente as que implicam a interacção de vários agentes. A Figura 1 ilustra o funcionamento genérico do sistema, desde o momento em que lhe é colocada uma nova questão até que esta é dada como realizada.
3 O Modelo Físico do Sistema
O sistema foi desenvolvido através da linguagem Java. Esta escolha teve por base a necessidade de garantir independência face à(s) arquitectura(s) com que é preciso lidar e à pretensão de tirar partido do rico e completo ambiente de desenvolvimento disponibilizado por essa linguagem, recorrendo e adaptando diversos conceitos estruturais e funcionais nela existentes, tal como será evidenciado posteriormente. Concretamente, é de salientar a modelação do sistema como uma comunidade de agentes que se interajudam, trocando informação de natureza diversa, e constituindo cada um dos elementos um especialista dedicado a uma fase (ou parte de uma fase) específica de um processo de alimentação. Esta modelação viu-se em muito facilitada devido à flexibilidade que o Java manifesta face à caracterização e à implementação das distintas entidades, bem como às robustas "vias de comunicação" que o Java disponibiliza.
Nas secções seguintes são apresentados e analisados os diferentes módulos do sistema desenvolvidos em Java, identificando sempre que possível os elementos que compõem as suas hierarquias, as respectivas competências e as interacções que mantêm com os outros módulos do sistema. Adicionalmente, sempre que tal se justificar, faz-se referência a fundamentos teóricos, nomeadamente a protocolos de comunicação, e/ou detalham-se certos aspectos considerados mais relevantes ou mais delicados em termos da aplicação.
3.1 A Agenda do Sistema
Este módulo congrega os elementos que caracterizam um esquema de agendamento, quer em termos estruturais quer funcionais. Por outras palavras, neste módulo foram construídas as classes que permitem implementar um esquema de calendarização de modo a possibilitar o agendamento automático de processos de alimentação de dados de um DW. Adicionalmente, este esquema possibilita a integração de pedidos de diversos tipos, adaptando-se assim às necessidades manifestadas pelo utilizador em cada momento. Os tipos de pedido que o sistema admite actualmente são: a) ad-hoc (Imediate), b) a despoletar numa data específica (Once), ou c) recorrente (Recurring Job). Assim, e tendo-se como objecto de agendamento processos de extracção, foi criada uma hierarquia de classes que traduz a graduação lógica entre estes. Tal como se pode observar na Figura 2, existe um objecto genérico, o Job, que contém as características básicas de um processo desta natureza. Deste objecto deriva uma série de outras classes que materializam tipos mais específicos, apresentando algumas destas sub-hierarquias próprias. Paralelamente, foi ainda construída uma classe que permite caracterizar as várias tarefas que integram os processos de alimentação.
Figura 2: O módulo agenda.
Job
Once Recurring Job Imediate
Job Types Task
Weekly Montly Dayly
3.2 Os Agentes
Os principais elementos funcionais do sistema são agentes de software, organizados numa comunidade, capazes de interagir com o objectivo de atingir em conjunto os propósitos e/ou suprir as necessidades do sistema e dos seus utilizadores. Assim, foram desenvolvidos diversos conjuntos de programas que ao serem integrados no ambiente da ferramenta disponibilizam todos os tipos de agentes implementados até ao momento, organizando-os de acordo com as suas características estruturais e funcionais (Figura 3).
A classe abstracta SoftAgent define o interface e o comportamento comuns a todos os agentes do sistema. Nesse sentido foram implementados dois interfaces: o Runnable, que dá vida às threads, as quais conferem autonomia aos agentes, e o SoftAgentListener, ao qual se recorre com vista a assegurar a comunicação entre os agentes. Quaisquer outras considerações mais alargadas acerca das vantagens oferecidas pelas threads encontram-se fora do âmbito deste artigo, apenas interessa referir que, recorrendo a esta "base", se torna possível a execução paralela das diversas actividades, o que não só agiliza o sistema como também rentabiliza o seu próprio desempenho.
Figura 3: Hierarquia do módulo Agents.
Por outro lado, no que diz respeito à comunicação, crê-se relevante, a este nível, a análise de alguns dos seus aspectos principais. Assim sendo, é de referir que, cada agente mantém um array de listeners, o qual contém as referências de todos os outros agentes que implementam o interface SoftAgentListener e que estão interessados em ser informados acerca da ocorrência de determinado(s) evento(s). Qualquer agente (SoftAgent) pode ser fonte de um evento, ao mesmo tempo que pode ser registado como listener de eventos de outros agentes. Tal implica a existência de métodos que permitam quer a adição e a remoção de referências ao nível das listas de notificação multicast, quer a realização da(s) actividade(s) de notificação propriamente dita(s). Assim, sempre que ocorra um determinado evento no qual existam agentes interessados, procede-se à sua divulgação, cabendo a estes a sua captação da rede e consequente tratamento. 3.3 A Coordenação do Sistema
O Coordenador (CoordinatorAgent), tal como o próprio nome indica, é o responsável pela coordenação de todas as actividades ocorridas ao nível do sistema, quer estas envolvam entidades externas quer estas estejam ligadas apenas como seus elementos integrantes. Assim sendo, este agente encontra-se sempre em condições de caracterizar os acontecimentos
SoftAgentListener SoftAgent StatisticsAgent ExtractionAgent DWExtractorAgent LogAgent AgendaLookupAgent ClockAgent CoordinatorAgent
ocorridos ou em decurso, constituindo desta forma a fonte de informação por excelência dos agentes responsáveis pela criação, gestão e manutenção das logfiles.
É também da responsabilidade deste agente a manutenção das ligações com a base de dados operacional, onde reside a informação relativa à agenda e às logfiles, assim como com a base de dados de resultados, isto é, com a zona de concentração de dados onde são armazenados os dados extraídos dos sistemas fonte. Depois de ser activado pelo programa principal, o agente de coordenação permanece activo durante todo o tempo de vida da aplicação. Logo que esta é iniciada, e por forma a garantir a sincronização temporal do sistema, é activado o Relógio, que é imediatamente adicionado à lista de notificação do Coordenador, o qual também passará a integrar a sua lista de notificação.
3.4 O Tempo do Sistema
O agente Relógio (ClockAgent) assume um papel bastante importante, pois todas as actividades são desenvolvidas de acordo com uma marcação temporal previamente estabelecida pelos administradores do sistema. Assim, este agente tem a responsabilidade de alertar o coordenador da data e hora actuais a cada momento, por forma a que este possa desencadear um processo de verificação da agenda com vista à recolha e posterior satisfação de todos os trabalhos, cuja etiqueta temporal coincida com a desse momento. Concretamente, logo que o coordenador receber a notificação do agente Relógio, este activará um agente de pesquisa da agenda que procederá à eventual recolha de trabalhos a desencadear. Por cada um dos trabalhos agendados para o instante em questão é activado um agente de extracção, cabendo a cada um deles um processo em particular. Por último, resta salientar a possibilidade de parar o agente Relógio a qualquer momento, isto é, colocar o agente num estado inactivo, com vista à execução de actividades de administração ou de manutenção do sistema.
3.5 As Funcionalidades de Acesso aos Dados
Com vista a assegurar o armazenamento consistente, coerente e íntegro de toda a informação recolhida ou gerada pelo sistema e a sua fácil manipulação, optou-se pela manutenção de uma base de dados - a base de dados operacional do sistema - capaz de armazenar todos os dados respeitantes aos diversos processos de extracção. A comunicação entre os diversos sistemas de dados integrados ou utilizados pelo sistema é feita através da JDBC API [White et al. 1999] disponibilizada pelo JDK. Esta API possibilita o acesso a qualquer tipo de bases de dados, permitindo acessos de diversos tipos, que vão desde o acesso via ODBC até aos drivers que utilizam sockets [Hamilton et al. 1997] [Hughes et al. 1996]. Optou-se também por encapsular em duas novas classes os dois tipos de acesso presentes na aplicação, de modo a simplificar a programação a este nível. Por um lado, existe o acesso genérico, em que se agrupam alguns dos métodos mais utilizados no acesso a bases de dados, por outro lado, o acesso à base de dados operacional, o qual torna mais transparentes os acessos específicos a este repositório, cuja estrutura se conhece antecipadamente. Pretendeu-se desta forma distanciar tanto quanto possível o utilizador dos pormenores da sintaxe da linguagem utilizada na definição de questões sobre as bases de dados, através da criação de métodos que traduzam adequadamente uma dada "intenção" num comando desta natureza. Por exemplo, é possível questionar a agenda do sistema acerca dos processos agendados para uma dada data e uma dada hora sem necessidade de executar qualquer interrogação explícita.
3.6 Invocação Remota de Métodos
A componente do sistema relacionada com a invocação remota de métodos tem como objectivo principal a reunião de todos os mecanismos necessários à criação e sustentação de servidores que garantam a comunicação entre todos os componentes do sistema, para além do necessário contacto com as fontes de alimentação disponíveis. Concretamente, pretendeu-se implementar um conjunto de servidores que permitissem o acesso a sistemas de bases de dados, assegurando a recepção de pedidos distintos de extracção de informação e sua resolução, mediante a
activação de agentes extractores, bem como o tratamento da devolução das correspondentes respostas ao agente de distribuição. Este agente encontra-se localizado numa máquina específica, a qual também é contactável através de um servidor próprio responsável pelo direccionamento de pedidos de extracção, bem como das suas respostas (incluindo as respectivas estatísticas) para o servidor ou para o agente mais adequado, consoante a situação. Deve-se referir que, em termos de comunicação, estes servidores têm por base o Remote Method Invocation. O seu objectivo principal é facultar aos objectos uma plataforma de comunicação que lhes permite estabelecer contacto recorrendo à "tradicional" invocação de métodos e libertando-os de quaisquer preocupações relacionadas com a localização dos seus receptores. Isto significa que um cliente poderá aceder sempre a um servidor deste tipo, quer este esteja situado localmente ou a estabelecer um acesso a partir de uma plataforma remota, não necessitando de conhecimentos de comunicação complexos. Assim, este tipo de implementação impõe a existência de um servidor permanentemente activo, que disponibilize métodos acessíveis remotamente, os quais são utilizados pelos diversos clientes com vista à realização de uma qualquer actividade nessa máquina [Hughes et al. 1996].
4 Conclusões e Trabalho Futuro
Neste artigo descreveram-se os modelos lógico e físico de um sistema multiagente especialmente desenhado e desenvolvido para suportar e orientar processos de alimentação (selecção, extracção, transformação e integração de dados) em ambientes de SDW. Procurou-se dar relevância aos conceitos mais preponderantes quer em termos conceptuais quer em termos de aplicação, visto que se pretendeu apresentar todo o processo de esquematização realizado, apresentando as suas significativas vantagens em termos do desenvolvimento e do desempenho do processo, mas também se considerou importante focar os obstáculos mais significativos ao seu nível. Adicionalmente foram apresentados alguns dos aspectos mais importantes relacionados com a implementação do sistema, em particular com a sua comunidade de agentes, nomeadamente aqueles que directamente estão envolvidos com o conjunto de actividades relativas aos processos de alimentação ou com a criação e administração de servidores que de forma eficiente e segura dêem resposta aos requisitos de comunicação entre as distintas máquinas intervenientes nesses processos. O desenho modular que o sistema apresenta providencia uma forma simples e eficiente para suportar e manusear processos de alimentação naturalmente distribuídos e concorrentes.
A integração de técnicas de computação baseadas em agentes na implementação da ferramenta aqui apresentada permitiu o desenvolvimento de melhores e mais efectivos processos de alimentação, garantindo de imediato, dado ser uma característica inata de qualquer agente, autonomia e independência ao nível individual dos processos de extracção. Ao colocar-se uma comunidade de agentes a realizar algumas das tarefas mais convencionais de um SDW - tarefas de administração, recolha e preparação de dados, etc. - foi possível criar algumas novas bases operacionais para tornar o sistema menos dependente de eventuais processos que exigissem intervenções humanas e capaz de reagir em tempo real a eventuais falhas do sistema, dado que os agentes poderão ter incluída nas suas bases de conhecimento informação que lhes suporte as suas actividades em situações como essas.
Em termos de trabalho futuro, pensa-se que este sistema pode ainda ser aperfeiçoado, sobretudo em termos dos seus interfaces gráficos e da flexibilidade, robustez e desempenho dos seus agentes. Adicionalmente, será necessário melhorar os modelos de coordenação e cooperação actuais, no sentido de os tornar mais versáteis e flexíveis, capazes de sustentar novos processos de extracção de informação, em particular relacionados com DW exteriores à organização na qual o sistema está instalado. Porém, a grande aposta futura será feita na concepção de novos sistemas que interajam com o actual, com vista a alargar os horizontes do trabalho desenvolvido
em termos da análise e congregação de sistemas de metadados e da extracção de conhecimento a partir do SDW construído.
5 Agradecimentos
Os autores querem deixar expressos os seus agradecimentos ao Eng. António Nestor
Ribeiro, pelas suas sugestões e discussões técnicas, e ao Rui Amílcar, pelas suas
contribuições para o desenvolvimento inicial do interface gráfico do sistema.
6 Referências
Belo, O., Gathering the Right Information at the Right Time, In Proceedings of the ICEIS'99 - International Conference on Enterprise Information Systems, Setúbal, Portugal, 1999. Ferber, J., Multi-Agent Systems - An Introduction to Distributed Artificial Intelligence,
Addison-Wesley, 1999.
Hamilton, G., Cattell, R., Fisher, M., JDBC Database Access with Java: A Tutorial and Annotated Reference. Addison Wesley, 1997.
Hughes, M., Hughes, C., Shoffner, M, Winslow, M., "Java Network Programming", Manning Publications, 1996.
Inmon, W., Building the Data Warehouse, John Wiley & Sons, 1996.
Jennings, N., Wooldridge, M., Applying Agent Technology, Applied Artificial Intelligence: An International Journal, 9(4):351-361, 1995.
Kimball, R., Data Warehouse Toolkit : Practical Techniques for Building Dimensional Data Warehouses, John Wiley & Sons, 1996.
Meyer, D., Cannon, C., Building a Better Data Warehouse, Prentice Hall Ptr., 1998.
Poe, V., Klauer, K., Brobst, S., Building a Data Warehouse for Decision Support, Prentice Hall, Inc., II edition, 1998.
White, S., Maydene, F., Cattel, R., Hamilton, G., Hapner, M., JDBC API Tutorial and Reference, Second Edition, Addison Wesley, 1999.
Wooldridge, M., Jennings, N., Intelligent agents: theory and practice, Knowledge Engineering Review 10, 1995.
