sistema de monitoramento e identificação de problemas em bancos

SISTEMA DE MONITORAMENTO E IDENTIFICAÇÃO
DE PROBLEMAS EM BANCOS DE DADOS BASEADO EM
CASOS
Guilherme Cruz <[email protected]>
Fabiana Lorenzi <[email protected]> – Orientador
Universidade Luterana do Brasil (Ulbra) – Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas –
Câmpus Canoas
Av. Farroupilha, 8.001 – Bairro São José – CEP 92425-900 – Canoas – RS
30 de novembro de 2011
RESUMO
Este artigo apresenta o desenvolvimento de um Sistema de Recomendação Baseado em Casos (SRBC) que
tem como objetivo realizar o monitoramento de Sistemas Gerenciadores de Banco de Dados Relacional (SGBDR) a
fim de identificar possíveis problemas de desempenho. Através da coleta constante de informações específicas do
SGBDR, o sistema torna-se uma ferramenta de grande utilidade para o administrador de banco de dados (DBA). Os
resultados obtidos atenderam as expectativas no momento em que o usuário definiu o sistema como pró-ativo após a
sua utilização.
Palavras-chave: Sistemas de Recomendação Baseados em Casos; Sistemas Gerenciadores de Bancos de Dados;
Administrador de Banco de Dados.
ABSTRACT
Title: “Case-based Monitoring System and Identification of Database Problems”
This paper presents the development of a Case-Based Reasoning Recommender System (CBR-RS) which
aims to carry out the monitoring of Relational Database Management Systems (RDBMS) in order to identify
potential performance problems. By collecting specific information contained in the RDBMS, the system becomes a
very useful tool for the database administrator (DBA). The results met the expectations at the time the user has
defined the system as pro-active after use.
Key-words: Case-Based Reasoning Recommender System; Relational Database Management Systems; Database
Administrator.
1
INTRODUÇÃO
O armazenamento de informações assumiu uma importância vital na economia contemporânea. Para
a maioria das empresas, o crescimento financeiro está diretamente relacionado à capacidade e a habilidade
de administrar sistemas e bases de dados, uma vez que a tecnologia da informação tornou-se o alicerce de
toda a indústria. Nesse cenário, os bancos de dados emergem como um recurso de alta criticidade.
“Banco de dados é uma coleção ordenada de dados, a qual é normalmente armazenada em um ou
mais arquivos associados. Os dados são estruturados em tabelas, onde referências cruzadas entre tabelas são
possíveis. A existência de tais relações entre tabelas leva um banco de dados a ser denominado banco de
dados relacional.” (KOFLER, 2005, p. 3). A administração de um banco de dados relacional, por sua vez, é
realizada através de Sistemas Gerenciadores de Banco de Dados Relacional (SGBDR), softwares que
possibilitam a estruturação, manutenção e monitoramento da coleção de dados.
O responsável por administrar o SGBDR é denominado administrador de banco de dados (Database
Administrator, DBA). Dentre as funções administrativas de um DBA estão a criação e manutenção de
usuários, tabelas e suas respectivas relações, dispositivos de armazenamento e, principalmente, o
monitoramento e aperfeiçoamento do desempenho do banco de dados.
Para monitorar o desempenho de um SGBDR é necessária a realização de consultas à base de dados
utilizando a linguagem SQL (FORTA, 2004). Existem ferramentas próprias das empresas desenvolvedoras
dos SGBDR, que oferecem diversas opções de monitoramento, porém muitas consultas são realizadas
manualmente pelo DBA a fim de verificar informações específicas do desempenho do banco. Assim, o
trabalho de um administrador de banco de dados torna-se repetitivo no momento em que o monitoramento
1
deve ser constante, principalmente para bancos que suportam sistemas críticos, além de ser dependente do
comprometimento do DBA em realizar as consultas de forma pontual e analisar corretamente os resultados.
Com a motivação de auxiliar o DBA na identificação de possíveis problemas de desempenho, este
trabalho apresenta como solução um sistema que utiliza a abordagem de Raciocínio Baseado em Casos
(RBC) para monitorar o SGBDR através de consultas pré-definidas pelo usuário. Pela interface do sistema,
o DBA poderá definir as informações a serem coletadas que irão representar os casos, podendo criar regras
de monitoramento para áreas específicas do banco.
Este artigo está organizado da seguinte forma: a seção 2 apresenta referências teóricas, a seção 3
descreve o desenvolvimento dos processos do ciclo do RBC e a seção 4 apresenta a implementação do
sistema proposto. As seções 5 e 6 representam, respectivamente, a etapa de validação do sistema e a
conclusão deste artigo.
2
REFERENCIAL TEÓRICO
Esta seção descreve as fundamentações teóricas que constituem este trabalho, trazendo como
referências a abordagem de Raciocínio Baseado em Casos (RBC) e Sistemas Gerenciadores de Banco de
Dados Relacional (SGBDR).
2.1
Raciocínio Baseado em Casos
Segundo NILSSON (1998), a Inteligência Artificial pode ser definida como o estudo e a aplicação
de técnicas e métodos baseados no comportamento inteligente de seres humanos e outros animais para
resolver problemas através de sistemas computacionais. O Raciocínio Baseado em Casos (RBC) surge como
uma abordagem ao modelo de aprendizagem humana, que utiliza a experiência de situações já vivenciadas, e
ainda presentes em memória, para solucionar problemas complexos.
O RBC é fundamentalmente diferente, em muitos aspectos, de outras abordagens principais da IA.
Ao invés de depender exclusivamente do conhecimento geral de um domínio do problema, ou de descrições,
suposições e conclusões, o RBC utiliza o conhecimento específico de experiências passadas (situações
concretas). Um novo problema é resolvido encontrando casos passados semelhantes e reutilizando-os na
nova situação. Outra importante diferença é que o RBC possui um processo de incremento e aprendizagem,
uma vez que uma nova experiência é armazenada toda vez que um problema for solucionado, estando
imediatamente disponível para problemas futuros (AAMODT e PLAZA, 1994).
Na terminologia do RBC, um caso representa uma situação de problema. Uma experiência passada,
que foi capturada e absorvida de uma maneira que possa ser reutilizada na resolução de problemas futuros, é
denominada de caso passado, caso anterior, caso armazenado ou caso retido. Consequentemente, um novo
caso ou um caso não-resolvido é a descrição de um novo problema a ser solucionado. Sendo assim, o
raciocínio baseado em casos é um conjunto de processos cíclicos e integrados de resolução de problema,
aprendizagem dessa experiência e resolução de novos problemas.
Conforme apresentado por AAMODT e PLAZA (1994), o ciclo do RBC, representado na Figura 1,
é composto por quatro fases: Recuperação, Reutilização, Revisão e Retenção. Uma primeira descrição de
um problema define um novo caso. Este novo caso é utilizado para recuperar um caso da coleção de casos
anteriores. O caso recuperado é combinado com o novo caso, através da reutilização, em um caso resolvido,
ou seja, uma proposta de solução para o problema inicial. Através do processo de revisão, é testado o
sucesso da solução. Durante a retenção, a experiência útil é retida para futura reutilização, e a base é, então,
atualizada por um novo caso aprendido, ou por modificação de alguns casos já existentes.
2
Figura 1- Ciclo do RBC
Para que seja iniciado o ciclo RBC, porém, é necessário que se completem alguns pré-requisitos.
Dentre eles, exige especial atenção a representação dos casos, uma vez que o caso é a entrada e saída de
todos os processos do ciclo.
2.1.1
Aquisição de Conhecimento
Aquisição de conhecimento é o processo o qual coleta e modela conhecimento para um sistema
especialista, e pode ser realizado através de técnicas como entrevistas estruturadas ou narrativas, entrevistas
centralizadas ao problema, bem como através de discussão em grupo, observação e questionários
(SCHMALHOFER, STRUBE e WETTER, 1992). Esta etapa é considerada por muitos autores como o
ponto que define o sucesso ou o insucesso do ciclo do RBC, uma vez que todas as informações pertinentes
devem ser coletadas. Caso contrário, os casos, que desempenham no ciclo papel-chave, estarão
representados de maneira incompleta.
Para adquirir o conhecimento pertinente, porém, é necessário o envolvimento de um especialista da
área referenciada pelo ciclo. Utilizam-se, assim, as técnicas de aquisição de conhecimento. Através das
informações obtidas desses processos é, então, definida a representação dos casos.
2.1.2
Representação dos Casos
Em KOLODNER (1991), é descrito o papel que os casos podem desempenhar para ajudar as
pessoas a tomar decisões e o conteúdo que os casos devem ter para auxiliar nessa questão fundamental. A
autora não comenta sobre a forma que um caso deve tomar, mas foca nos tipos de coisas que devem ser
representadas em um caso para que ele possa ser produtivamente utilizado para o raciocínio. Os casos
devem conter a descrição de uma situação de problema, a solução que foi proposta e o resultado obtido, bem
como se esteve perto ou não do que era esperado.
2.1.3
Indexação e Recuperação dos Casos
Índices são estruturas de dados que podem ser armazenadas em outras estruturas para que possam
ser pesquisadas rapidamente (DEHNE, 1993). Indexação de casos envolve relacionar índices a casos para
facilitar o processo de recuperação.
Recuperação é a utilização de técnicas de busca para pesquisar a base de casos com o objetivo de
encontrar casos passados que apresentem semelhança ou níveis de similaridade com o novo caso. Neste
trabalho será utilizado o algoritmo de vizinho mais próximo. Conforme COPPING (2004), o algoritmo de
vizinho mais próximo é uma abordagem de busca que seleciona experiências com base na distância
geométrica entre instâncias de um mesmo espaço.
2.1.4
Reutilização e Revisão dos Casos
Reutilização é o processo do ciclo do RBC que tem por objetivo apresentar uma solução para um
novo problema através de soluções de casos passados. A apresentação de uma nova solução, porém, é
obrigatoriamente antecedida pelo processo de recuperação do caso, uma vez que ela é definida pela solução
presente no caso passado recuperado. Sendo assim, a experiência do caso passado é relacionada ao novo
3
problema (AAMOD e PLAZA, 1994).
O processo de reutilização pode ser realizado através da atribuição da solução recuperada no caso
passado, sem que haja modificações, à solução do novo caso. Essa técnica é comumente aplicada para
atividades de classificação, onde é provável que cada solução seja representada frequentemente na base de
casos e, sendo assim, o caso mais semelhante recuperado, se for considerado suficientemente similar, tem
grande probabilidade de conter a solução apropriada. A reutilização pode se tornar complicada, entretanto,
se houverem diferenças significativas entre o caso recuperado e o novo problema. Em situações como essa,
uma adaptação pode ser necessária (KOLODNER, 1993).
Uma vez finalizada a reutilização, o processo de revisão é então iniciado. Durante essa etapa, a
solução proposta ao novo problema é avaliada e pode sofrer modificações (AAMOD e PLAZA, 1994). Essa
fase é considerada por alguns autores como o período de aprendizagem com as falhas. Sendo assim, a
revisão permite o ajuste da solução recuperada à solução do novo problema. Técnicas de revisão podem ser
aplicadas e gerar regras, heranças ou conhecimento de domínio.
2.1.5
Retenção dos Casos
A retenção é apresentada como o passo final ao ciclo do RBC, e é nele que o resultado do último
processo de solução de caso é incluído na base de conhecimento do sistema. O caso revisado é armazenado
com as características do problema e a solução encontrada, assumindo implicitamente que o resultado
obteve sucesso (AAMOD e PLAZA, 1994).
Existem, entretanto, diversas questões relacionadas a melhores práticas de aprendizagem com um
novo caso e a como diferentes sistemas podem armazenar diferentes tipos de informações em seus casos.
Quando o critério para o sucesso ou não de um caso é complexo, os casos devem incluir informações
adicionais sobre a resolução do problema e sobre o cenário que caracterizou o problema.
2.2
Sistemas Gerenciadores de Banco de Dados Relacional
O modelo relacional de dados surgiu oficialmente com a publicação do artigo “Um Modelo
Relacional de Dados para Grandes Bancos de Dados Compartilhados” (CODD, 1970). Depois de publicado,
o estudo proposto foi aceito e definido como o modelo para bancos de dados relacionais. Com base no
artigo de Codd, é apresentado, no ano de 1976, pelo engenheiro de software Peter Chen, um novo modelo
relacional denominado Modelo Entidade-Relacionamento (ER), sendo o mais popular e utilizado até os dias
de hoje.
Segundo CHEN (1976), o modelo ER é definido por quatro termos chave, sendo eles: entidades,
relacionamentos, atributos e domínios. A estrutura básica do seu modelo relacional é a tabela (representando
uma entidade), onde as informações são estruturadas em linhas e colunas. Os relacionamentos, por sua vez,
são as referências existentes entre as entidades. As colunas têm o papel de enumerar os vários atributos da
entidade e as linhas são instâncias da entidade. Como resultado, a linha de uma tabela de empregados, por
exemplo, representa um único empregado.
No entanto, todas as entidades em um banco de dados relacional seguem algumas premissas básicas
(BRYLA, 2004). Primeiro, a ordem das colunas em uma tabela é irrelevante. Segundo, não podem existir
linhas idênticas em uma mesma tabela. E por terceiro, a linha de uma tabela pode conter um único valor para
cada um de seus atributos. Adicionalmente, cada tabela pode ou não conter uma coluna denominada chave
primária, que servirá como identificador único de cada linha da tabela. Para compor o relacionamento entre
tabelas, utilizam-se chaves estrangeiras.
2.2.1 Relacionamentos
Os relacionamentos entre entidades podem ocorrer entre duas ou mais tabelas, através de chaves
estrangeiras, sendo o binário o mais comum deles. A cardinalidade de uma relação indica quantas
instâncias de uma entidade podem ser relacionadas a uma instância de outra entidade. A cardinalidade no
modelo ER expressa o número de ocorrências de uma entidade em relação à outra. Os relacionamentos mais
comuns entre entidades são um-para-um, um-para-muitos e muitos-para-muitos. As propriedades de cada
relacionamento são as seguintes (OSBORNE e MORTON, 2010):
• Um-para-um: Neste tipo de relacionamento, uma instancia de uma entidade só pode estar
relacionada à outra única instancia da outra entidade. Por exemplo, uma pessoa pode possuir
4
apenas um único número de registro geral (RG), e cada RG pode pertencer a somente uma única
pessoa.
• Um-para-muitos: Neste caso, cada instancia de uma entidade, está relacionada com diversas
instâncias da outra entidade. Exemplificando, uma pessoa pode alugar diversos livros de uma
biblioteca, mas cada livro pode ser alugado por uma única pessoa por vez.
• Muitos-para-muitos: Nesta situação, cada instância da entidade A, por exemplo, está relacionada
a muitas instâncias da entidade B e, ao mesmo tempo, uma instância da entidade B está
relacionada a diversas instâncias da entidade A. Tomando como exemplo, um desenvolvedor de
uma empresa de software pode fazer parte de muitos projetos, e cada projeto pode utilizar
diversos desenvolvedores.
2.2.2 Estrutura
Atualmente, existem diversas empresas desenvolvedoras de sistemas gerenciadores de banco de
dados relacional. Dentre elas, podemos destacar a Oracle, com os produtos Oracle e MySQL, e a Microsoft
com o SQL Server. Em ambas, seus produtos possuem as mesmas estruturas básicas, como arquivos de
armazenamento, tabelas e agrupamentos de tabelas, usuários e esquemas. Um importante detalhe, entretanto,
caracteriza-se pelo fato de que as mais relevantes informações de desempenho do SGBDR, em tempo real e
históricas, são armazenadas em tabelas do próprio banco de dados, estando disponíveis para consulta pelo
administrador de banco de dados.
2.2.3 Linguagem
A linguagem de acesso e manipulação de dados de um SGBDR é a Structured Query Language
(SQL), traduzida como linguagem de acesso estruturada. O propósito da SQL é simplesmente prover uma
interface ao banco de dados. Toda instrução é considerada um comando. A linguagem SQL difere de outras
linguagens de programação como C e Java, que tendem a processar dados em conjuntos, e não em linhas
individuais. Outra característica é que ela não requer instruções de como navegar até os dados – isso
acontece de forma transparente para o usuário (OSBORNE e MORTON, 2010).
Existem diferenças em como as empresas desenvolvedoras dos SGBDR implementam as
funcionalidades da SQL, embora as técnicas aprendidas pelo usuário em um banco de dados vão se transferir
para outros. A base de toda linguagem SQL é composta pelos comandos select, insert, update e delete,
utilizados para consultar, inserir, atualizar e remover registros, respectivamente.
3
DESENVOLVIMENTO DO CICLO DO RBC
Esta seção descreve o desenvolvimento deste sistema em relação ao ciclo do raciocínio baseado em
casos, e organiza-se de forma a facilitar o entendimento, uma vez que todas as etapas são dependentes de
etapas anteriores, iniciando com a aquisição de conhecimento.
3.1
Aquisição de Conhecimento
A aquisição de conhecimento é o item base para o desenvolvimento de um sistema que utiliza o
raciocínio baseado em casos. Através dela, são coletadas as informações que irão definir a representação dos
casos e a forma como serão manipuladas. O levantamento dos dados ocorreu através de questionário e
entrevista com o especialista na área de SGBDR, um dos administradores de banco de dados de uma
empresa multinacional.
3.1.1
Questionários
Foram apresentados ao especialista dois questionários com diferentes abordagens. No primeiro,
utilizaram-se apenas perguntas relativas às atividades realizadas pelo DBA, com o objetivo de entender as
responsabilidades e funções de seu dia-a-dia. O segundo questionário, por sua vez, visou levantar os
detalhes sobre os dados coletados e técnicas utilizadas por ele para verificar o desempenho do banco de
dados e identificar possíveis problemas.
Em ambos os questionários, ficou evidente a importância de uma tarefa realizada pelo DBA: a
execução de consultas personalizadas com base no comportamento da aplicação que aquele determinado
banco de dados suporta. Cada aplicação da empresa é desenvolvida com objetivos específicos de negócio.
5
Algumas são utilizadas como sistemas gerenciadores de vendas, por exemplo, responsáveis por armazenar e
atualizar uma grande quantidade de dados. Em contrapartida, outros sistemas executam consultas complexas
que envolvem cruzamentos e operações de ordenação entre os dados sem a necessidade de inserir
informações na base de dados, consumindo, entretanto, boa parte dos recursos do SGBDR, como sistemas
geradores de relatórios.
Assim, os mais prováveis problemas de desempenho em um SGDBR estão relacionados à maneira
como o sistema suportado manipula a coleção de dados. Algumas aplicações realizam processos com
utilização de paralelismo, gerando excessos de carga e concorrência. Outras executam, ao mesmo tempo,
variados processos de inserção, atualização e deleção de dados, os chamados comandos DML (Data
Manipulation Language), que muitas vezes acabam por paralisar uns aos outros, no momento que
compartilham os mesmos recursos.
3.1.2
Entrevista
Através dos dados presentes nos questionários foi possível analisar e identificar os tópicos mais
importantes sobre o assunto, para que informações mais detalhadas pudessem ser coletadas através de uma
conversa com o especialista. Assim, foi organizada uma entrevista semi-estruturada com base nos seguintes
tópicos:
• Como as ferramentas de monitoramento próprias das empresas desenvolvedoras dos SDGBR
poderiam ser mais úteis?
• Pessoa ou equipe responsável e conhecimento necessário para construir as consultas
personalizadas.
• Tipos de dados retornados nas consultas.
• Frequência de execução das consultas.
• Número necessário de consultas para verificar e identificar problemas em nível de desempenho
do SGDBR.
• Armazenamento da solução encontrada para um problema de desempenho.
• Protótipo de representação de um caso.
3.2
Representação dos Casos
Para um sistema que objetiva realizar o monitoramento e a identificação de problemas em SGBDR,
uma representação de caso é um artefato capaz de descrever o nível de desempenho do banco de dados em
um determinado momento e os atributos que constituem tal definição. Com as respostas obtidas através da
entrevista ficou clara, porém, a necessidade de flexibilidade na representação dos casos. Para cada problema
específico a ser verificado, um diferente número de atributos podem ser necessários. Em resumo, os
atributos do caso, em sua grande maioria, são representados pelas consultas SQL e o usuário do sistema
deve, assim, ser capaz de criar inúmeras representações de casos.
Além da variação na quantidade de atributos, outra questão extremamente importante foi levantada
pelo especialista quando se referindo a atribuição de nível de desempenho aos casos. Todo o caso coletado
do SGBDR necessita ter um atributo que informe a caracterização ou não de um problema concreto ou a
caracterização de apenas um aviso. Segundo ele, o valor deste atributo deve ser preenchido ou revisado pelo
usuário, uma vez que o banco de dados fornece apenas as informações de desempenho, não sendo capaz de
relacioná-las a problemas passados. Dessa forma, tanto casos novos quanto casos passados possuem um
atributo denominado categoria, conforme a Tabela 1.
Valor
0
3
2
1
Tabela 1 – Valores para o atributo Categoria
Nome
Descrição
Neutro
Não há problemas.
Aviso
Um novo problema pode ocorrer.
Problema
Um novo problema está ocorrendo.
Problema Grave Um novo problema grave está ocorrendo.
Todas as representações que o usuário definir possuem alguns elementos em comum. Ao contrário
das consultas, tais elementos não possuem influência no processo de recuperação dos casos:
6
• Código: uma vez que muitas representações podem ser criadas, é necessário haver um número
identificador único para cada caso, criado automaticamente pelo sistema.
• Nome: nome da representação do caso, definido pelo usuário.
• Descrição: objetivo pelo qual a representação foi criada, definido pelo usuário.
• Freqüência: intervalo de coleta do caso, em minutos, definido pelo usuário.
• Solução: descrição da resolução ou da tentativa de resolução e do sucesso ou não da mesma,
preenchidas pelo usuário.
• Limiar: atributo utilizado no algoritmo do processo de recuperação, definido pelo usuário.
Dessa forma, cada representação de caso possui os seis atributos citados acima, o atributo categoria,
descrito na Tabela 1, e uma ou mais consultas SQL, totalizando oito atributos mínimos. Para cada atributo
há um tipo e tamanho específico de dado conforme a Tabela 2.
Tabela 2 – Atributos mínimos do Caso
Atributo
Tipo
Tamanho
Codigo
Numérico
10
Nome
Texto
100
Descricao
Texto
400
Frequencia
Numérico
10
Solucao
Texto
1024
Categoria
Numérico
1
Limiar
Numérico
6
SQL
Texto
1024
A representação de casos em SRBC envolve, neste sistema, a atribuição de pesos, níveis de
relevância, aos atributos de um caso de acordo com a sua importância na caracterização do problema
(AAMODT e PLAZA, 1994). Assim, apenas as consultas SQL são relevantes para a caracterização de um
problema em um sistema gerenciador de banco de dados relacional e, portanto, são os únicos elementos aos
quais pesos devem ser atribuídos. Todos os outros elementos devem possuir peso nulo ou igual a zero,
conforme apresentado no Quadro 1.
Quadro 1 – Peso dos Atributos do Caso
Atributo
Peso (x)
Código
x = 0 ou x = nulo
Nome
x = 0 ou x = nulo
Descricao
x = 0 ou x = nulo
Frequencia
x = 0 ou x = nulo
Solucao
x = 0 ou x = nulo
Categoria
x = 0 ou x = nulo
Limiar
x = 0 ou x = nulo
SQL
0<x<1
Com base no protótipo de representação de caso criado pelo especialista e nas definições de
atributos e pesos descritos na Tabela 2 e no Quadro 1, foi concluída a representação final dos casos do
sistema, atentando para o indefinido número de consultas SQL possíveis. A Figura 2 ilustra um exemplo de
caso que caracteriza um problema de desempenho conhecido como locks (travas) em um banco de dados
Oracle. O SGBDR da Oracle segue um sistema de integridade de dados que antecipa conflitos em potencial
e bloqueia algumas transações de interferirem em outras com o objetivo de evitar conflitos entre transações
concorrentes, são os chamados locks (ALAPATI, 2009).
7
Figura 2 – Exemplo de Caso
Conforme a Figura 2, os seis primeiros atributos não serão utilizados na recuperação dos casos,
porém todos os atributos restantes influem no processo de recuperação. O atributo limiar é utilizado para
limitar a similaridade entre os casos recuperados. Os cinco últimos atributos, também na cor verde, são as
consultas SQL definidas pelo usuário. Cada consulta SQL representa um comando a ser executado no
SGBDR, e os resultados desses comandos constituem os valores dos atributos correspondentes. Os tipos de
valores retornados, numérico ou texto, dependem dos comandos utilizados na consulta SQL.
3.3
Indexação dos Casos
A indexação dos casos neste sistema foi desenvolvida para facilitar e simplificar o processo de
recuperação. Cada caso armazenado na base de conhecimento é representado através de uma entidade do
banco de dados. Cada linha dessa tabela contém os identificadores e os valores dos atributos do caso. Assim,
através dos identificadores, é possível consultar a entidade de atributos e recuperar o peso atribuído a cada
um, para que possam ser utilizados na etapa de recuperação.
3.4
Recuperação dos Casos
O processo de recuperação dos casos terá como base a utilização do algoritmo do vizinho mais
próximo. Seguindo esse contexto, cada atributo da representação do caso tem um peso específico, conforme
seção 3.2, para que possa ser calculada a distância entre os casos, fator principal para a escolha do caso mais
próximo, ou mais semelhante, ao caso que se deseja obter uma solução.
Figura 3 – Algoritmo do vizinho mais próximo (COVER e HART, 1967)
A utilização do algoritmo do vizinho mais próximo no ciclo do RBC tem como objetivo encontrar,
dentre os casos armazenados na base, o caso mais semelhante ao novo problema, onde:
•
•
•
•
•
•
d: é resultado do cálculo da distância entre dois elementos;
q: representa o novo problema;
c: representa um caso armazenado na base;
f: representa a característica de q e c;
w: é o peso atribuído a característica f;
sim: é a função de similaridade;
Existem diversas técnicas de medida de similaridade e a mais frequentemente aplicada, e também
utilizada neste projeto, utiliza a distância Euclidiana entre dois elementos de um mesmo espaço temporal. O
Quadro 2 ilustra a comparação entre dois casos C1 e C2, armazenados na base, com o novo problema.
8
Quadro 2 – Comparação de C1, C2 e novo problema
Peso
C1
C2
Problema
Atributo
0.6
52
47
50
ConsultaLocks
0.1
7
3
5
ConsultaTabelas
0.1
5
8
9
ConsultaUsuarios
0.2
20
25
22
ConsultaSessoes
Através dos pesos definidos para cada atributo, e dos valores de atributos correspondentes para cada
caso, é então calculada, separadamente, a distância de cada um em relação ao novo problema, conforme a
Figura 4.
Figura 4 – Cálculo de distancia entre casos
Verifica-se que o valor da distância entre os casos da base e o novo problema é maior para o caso C1
e menor para o caso C2. Assim, considera-se o caso C2 como de maior semelhança ao novo problema.
Entretanto, o caso C2 só será utilizado como caso recuperado no ciclo do RBC se a distancia calculada
estiver abaixo do limiar estabelecido pelo usuário durante a criação da representação do caso.
3.5
Reutilização, Revisão e Retenção dos Casos
O processo de reutilização de casos neste sistema consiste na atribuição da categoria e da solução do
caso recuperado ao novo caso. Os valores de categoria, conforme a Tabela 1 (apresentada na seção 3.2)
estão relacionados à caracterização de problemas. Se o caso recuperado representar um cenário real de
problema e possuir o valor 3 (três) para a categoria, por exemplo, o novo caso será atribuído com o mesmo
valor. O mesmo acontece para a solução, sendo também replicada ao novo caso.
Uma vez reproduzidos os valores de categoria e de solução ao novo problema, cabe ao usuário
revisar se eles realmente se aplicam ao novo caso. Se alterações forem necessárias, ambos os valores podem
ser modificados através da interface do sistema. Caso não haja modificações, o usuário pode solicitar o
armazenamento do caso na base de conhecimento. Novos casos que receberem o valor de categoria 0 (zero),
após o processo de reutilização, serão automaticamente armazenados na base sem qualquer intervenção do
usuário.
9
4
IMPLEMENTAÇÃO DO SISTEMA
Os itens descritos nesta seção têm como objetivo o esclarecimento das etapas de implementação
deste sistema baseado em casos para o monitoramento e identificação de problemas em sistemas
gerenciadores de banco de dados relacional.
4.1
Tecnologias
A codificação do sistema foi realizada através da linguagem de programação C# com o auxílio do
framework .NET e do software Visual Studio, da Microsoft. O Visual Studio é um ambiente de
desenvolvimento integrado (IDE) especialmente dedicado ao framework .NET e as linguagens Visual Basic,
C, C++ e C#, também sendo amplamente utilizado para o desenvolvimento web, através da plataforma
ASP.NET (Microsoft, 2008).
Além de auxiliar na implementação do código-fonte, o Microsoft Visual Studio foi escolhido como
ferramenta de desenvolvimento por facilitar a criação de interfaces gráficas e por permitir a criação de
sistemas locais (desktop), aplicações para a web ou ainda para aparelhos móveis. Para este projeto optou-se
pela utilização de um sistema desktop, uma vez que o principal usuário do sistema, o administrador de banco
de dados, realiza a maioria de suas tarefas através de softwares na sua própria estação de trabalho.
Como base de dados, é utilizado o SQL Server 2008, o sistema gerenciador de banco de dados
relacional da Microsoft. O SQL Server é amplamente integrado com o Visual Studio e, por esse motivo,
torna prática a modelagem e o acesso aos dados. A versão escolhida é a EXPRESS, que não exige compra de
licenças e permite que qualquer indivíduo utilize o SQL Server livremente.
4.2
Funcionalidades
As funcionalidades do sistema foram planejadas de forma a atender as necessidades do
administrador de banco de dados na identificação de problemas. Para facilitar a utilização, o sistema foi
logicamente dividido em três segmentos:
•
•
•
•
•
4.2.1
Administração de alvos
Administração de atributos
Administração de casos
Coleta e monitoramento
Módulo especialista
Administração de alvos
A administração de alvos refere-se à criação e manutenção das fontes de conexão dos bancos de
dados a serem monitorados pelo sistema. Cada alvo armazena as informações de endereçamento de um
SGBDR. Os alvos podem estar localizados em qualquer servidor, desde que estejam acessíveis a partir da
máquina onde o sistema está sendo utilizado pelo usuário. Inicialmente, este sistema só permite que sejam
criados alvos para o SGBDR Oracle e Microsoft SQLServer. Para que seja possível conectar a um SGDBR
utilizam-se algumas informações básicas, independentemente do tipo ou marca de banco de dados a ser
acessado. O usuário do sistema é responsável por fornecer a string de conexão ao SGDBR. Uma vez que se
possui essa informação, a conexão pode então ser criada. A Figura 5 ilustra o comportamento do sistema em
relação aos alvos.
Figura 5 – Arquitetura de alvos
10
Cada representação de caso criada pode ter apenas um alvo relacionado, porém um alvo pode ser
utilizado por diversos casos. Assim, cada caso irá realizar a coleta de dados de apenas um SGDBR. Em
outras palavras, as consultas SQL do caso serão executadas a partir da conexão com o banco de dados alvo,
e o usuário do sistema é responsável por fornecer os dados de conexão corretos.
4.2.2
Administração de atributos
O segmento de administração de atributos permite ao usuário criar, editar e remover consultas SQL.
Conforme apresentado na seção 3.2 deste trabalho, as consultas SQL são os únicos atributos relevantes ao
caso. Outro importante detalhe é o fato de que o código SQL de uma consulta pode ser utilizado em diversas
representações de casos. Cada consulta SQL criada pelo usuário irá gerar um novo atributo no sistema, que
pode ser utilizado por mais de uma representação de caso.
Sendo assim, para que o usuário possa criar uma nova representação, é necessário que antes estejam
criadas todas as consultas SQL que irão compor os atributos daquele novo caso. A edição de código de
consultas SQL existentes pode ser realizada a qualquer momento, porém caso essa consulta também esteja
em utilização por outros casos a modificação será replicada entre eles, uma vez que o atributo é o mesmo no
sistema. Por outro lado, a exclusão de uma consulta não será permitida se aquele atributo fizer parte de
qualquer representação de caso ainda presente no sistema.
Os códigos utilizados nas consultas devem ser compatíveis com as especificações de linguagem do
SGBDR a ser monitorado. Em outras palavras, caso o usuário esteja criando uma representação de caso para
monitorar um SQLServer, por exemplo, o código utilizado deve seguir a semântica da linguagem SQL da
Microsoft. Dessa forma, o usuário do sistema é responsável por garantir a sintaxe e a semântica correta
daquela linguagem.
4.2.3
Administração de casos
Uma vez que as consultas SQL estejam criadas, conforme o item 4.2.2, o usuário poderá então
iniciar a definição da representação dos casos. Toda consulta adicionada a representação do caso, porém,
deve ter um peso atribuído, variando de zero a um. Através da interface de administração de casos é possível
criar novos casos ou remover casos existentes. Operações de edição em uma representação já criada, como
adição ou remoção de atributos, não são possíveis, uma vez que o raciocínio baseado em casos não permite
que a representação do caso seja modificada durante o ciclo. Entretanto, o usuário pode modificar o valor ou
o conteúdo de atributos existentes, como nome, frequência e limiar.
Conforme descrito anteriormente na seção 3.2 deste trabalho, muitas representações de casos podem
ser criadas. Cada representação fará parte de um único ciclo de RBC, assim o sistema terá que administrar o
funcionamento dos diversos ciclos. Em resumo, se o usuário criar duas diferentes representações de casos
para monitorar os bancos A e B, por exemplo, as quatro fases do ciclo do RBC serão executadas
separadamente para cada representação.
Para que o monitoramento de cada representação de caso ocorra, o usuário deve definir a frequência
de execução do processo de recuperação do caso. O usuário estabelece o intervalo de tempo para que o caso
seja coletado no alvo. Se uma frequência de quinze minutos for definida, por exemplo, isso significa que o
sistema irá criar uma conexão ao SGBDR alvo relacionado e irá executar as consultas SQL que compõem o
determinado caso toda vez que o intervalo de quinze minutos for atingido, conforme ilustrado na Figura 6.
Os retornos das consultas irão compor os valores dos atributos do caso.
!"
Figura 6 – Exemplo de coleta do caso
11
Além do atributo frequência, o usuário deve fornecer outras informações para a criação de uma nova
representação de caso. Cada representação terá um identificador único, criado automaticamente pelo
sistema, porém o usuário deve definir o nome, bem como a descrição da representação. A seguir, o usuário
deve informar a qual grupo aquela representação pertence, qual o limiar para aquela representação e qual o
alvo relacionado. Os grupos são utilizados para facilitar a organização, uma vez que os casos podem ser
agrupados em tipos de problemas específicos, ou de acordo com as áreas do SGBDR a serem monitoradas.
4.2.4
Coleta e Monitoramento
O monitoramento refere-se à interface pela qual o DBA terá acesso as tarefas de coleta de casos do
sistema. As tarefas de coleta são as atividades as quais executam os comandos SQL que compõe os casos de
acordo com o atributo freqüência definido pelo usuário quando da criação da representação do caso. Através
do monitoramento, o usuário poderá verificar as informações dos casos coletados.
Para cada representação de caso do sistema, serão executados os quatro processos do ciclo do RBC:
recuperação, reutilização, revisão e retenção. A tela de monitoramento permite que o usuário verifique se
existem casos que foram identificados em alguma categoria, após o processo de recuperação ser realizado
(seção 3.4). A interface fornece, ao mesmo tempo, informações sobre o caso semelhante recuperado e ainda
possibilita o acesso direto ao atributo solução do caso recuperado.
A principal função do sistema é a identificação de problemas ou possíveis problemas de
desempenho no SGDBR, assim, apenas casos que se enquadrem nessa questão serão exibidos na interface.
As atividades de administração da tela de monitoramento incluem a ordenação dos casos por categoria ou
grupo, o armazenamento de casos e, principalmente a atribuição de uma solução, descrita em formato texto,
e a modificação da categoria do caso, se o usuário achar necessário alterar a categoria que foi atribuída
automaticamente pelo sistema.
A Figura 7 ilustra o diagrama de atividades da linguagem UML (GOGOLLA e KOBRYN, 2001) do
processo de monitoramento. Um caso C1 recém coletado é submetido ao processo de recuperação. Ocorre a
recuperação de um caso semelhante S1 e o valor do atributo categoria é replicado ao novo caso C1, que por
sua vez, passa a ser exibido na tela de monitoramento, se o valor de categoria for diferente de zero.
Figura 7 – Diagrama de atividades: monitoramento
4.2.5
Módulo Especialista
O módulo especialista deste sistema consiste em algumas funcionalidades específicas que devem ser
utilizadas apenas pelo especialista, sendo controladas através de um processo de autenticação, com o
objetivo de filtrar o acesso. Embora ambos o usuário e o especialista deste sistema sejam DBAs, os sistemas
baseados em casos normalmente permitem que apenas o especialista realize modificações na base de
conhecimento, bem como na representação dos casos. O principal objetivo de controlar o acesso é evitar que
casos armazenados sejam alterados indevidamente, mantendo a base de conhecimento íntegra. Sendo assim,
este módulo utiliza uma interface que solicita usuário e senha para login.
12
4.3
Interfaces
As interfaces gráficas do sistema foram desenvolvidas com o intuito de seguir um mesmo padrão,
conforme os princípios da usabilidade. Com o auxilio do Microsoft Visual Studio, as telas foram criadas
como forms (formulários) do Windows. A maioria dos princípios de design e usabilidade está internamente
incluído em interfaces desse tipo (SATZINGER, JACKSON e BURD, 2009).
4.3.1
Menu
A interface de menu contém quatro dos segmentos lógicos do sistema: administração de alvos,
administração de atributos, administração de casos e monitoramento. Cada opção do menu exibe sub-itens
com as funcionalidades relacionadas, como inclusão, edição e exclusão de elementos. O menu está presente
apenas na tela inicial do sistema e é do tipo cascata, sendo os sub-itens carregados em pequenas áreas abaixo
do item de menu respectivo, quando esse for selecionado (Figura 8). Ao selecionar um subitem do menu,
uma nova janela (formulário) será carregada separadamente.
Figura 8 – Menu do sistema
4.3.2
Interface de Monitoramento
Esta é a interface principal do sistema, apresentada na Figura 9, e é através dela que o DBA irá
monitorar os SGBDR. Graficamente, ela está dividida em duas áreas, sendo uma delas o painel de casos e a
outra de contadores. No painel de casos será exibida a lista de casos que foram identificados como aviso,
problema ou problema grave, com os valores de categoria três, dois e um respectivamente. Casos com valor
de categoria zero não serão exibidos, visto que não caracterizam qualquer instabilidade.
Uma vez que esteja ciente dos casos presentes no painel, cabe ao usuário definir as modificações
necessárias antes que o caso possa ser retido na base. Assim, os valores de atributos podem sofrer alterações
conforme as respectivas instruções:
• Categoria: o primeiro valor de categoria é atribuído automaticamente pelo sistema após a
recuperação de um caso semelhante. A categoria pode ser modificada pelo usuário de acordo
com a Tabela 1 (seção 3.2). Se o caso estiver armazenado, a categoria poderá apenas ser
modificada através das interfaces de administração de casos da base de conhecimento.
• Solução: a solução para o problema caracterizado pode ser inserida e modificada a qualquer
momento pelo usuário.
Assim que o usuário definir que as alterações necessárias foram concluídas, ele pode, então,
armazenar o caso na base através do botão Armazenar. Consequentemente, os casos armazenados não serão
mais exibidos no painel, porém estarão imediatamente disponíveis na base de casos para que participem dos
próximos processos de recuperação. O DBA também possui a funcionalidade de visualizar os detalhes do
caso semelhante recuperado para cada caso exibido no painel. Dessa forma, ele pode ter acesso a solução
anterior do caso recuperado, e verificar se ela pode ser útil na resolução do novo problema.
Sobre a área de contadores, essa sessão tem por objetivo exibir dados sobre a contagem de casos da
base. Através do painel de estatísticas, o usuário poderá verificar o número total de casos retidos na base,
bem como a contagem de casos por categoria.
Em ambos os painéis da interface de monitoramento, os casos são diferenciados através de cores por
categoria. Os casos de categoria três, que simbolizam um aviso ao usuário, serão exibidos na cor amarela.
Os casos de categorias dois e um, que caracterizam a ocorrência de problemas e de problemas graves, são
representados nas cores laranja e vermelha, respectivamente. Ainda na interface de monitoramento, o
usuário pode interromper ou iniciar o processo de coleta dos casos, através de dois botões localizados na
subárea Processo de Coleta de Casos. Se o botão que interrompe o processo for pressionado, todas as
representações de caso são afetadas, uma vez que novos casos não serão coletados.
13
Figura 9 – Tela de monitoramento
4.3.3
Base de Conhecimento
O acesso aos casos armazenados na base de conhecimento é realizado através do item de menu
Casos, e do subitem Base de Conhecimento. Através das interfaces de manipulação de casos da base, o
usuário pode realizar operações como cadastro, edição e exclusão. Tais funcionalidades são controladas,
entretanto, pelo módulo especialista, que exige credencias para o acesso.
Na tela de Cadastro de Caso na Base de Conhecimento (Figura 10), o especialista pode inserir
novos casos para qualquer representação de casos, desde que a representação já tenha sido cadastrada
anteriormente. O usuário seleciona a representação desejada, informa valores para categoria e solução, e
pode então inserir os atributos que representam o retorno de cada consulta SQL, para que possam ser
utilizados nos próximos processos de recuperação de caso.
Figura 10 – Cadastro de caso na base de conhecimento
14
4.4
Diagrama ER
O diagrama ER da base de dados deste sistema, conforme apresentado na Figura 11, foi planejado de
acordo com regras de organização de dados em tabelas de um banco de dados relacional. O processo de
modelagem de dados em tabelas relacionais é conhecido como normalização e pode ser altamente complexo.
Usualmente, entretanto, utilizam-se apenas três níveis de normalização, divididos em: primeira, segunda e
terceira forma (WATSON e RAMKLASS, 2008). Os relacionamentos entre tabelas são compostos através
de chaves primárias e chaves estrangeiras, conforme descrito no item 2.2.1 (Seção 2.2).
Figura 11 – Diagrama ER
5
VALIDAÇÃO E RESULTADOS
A validação deste sistema ocorreu através da sua utilização, durante um período de cinco dias, pelo
especialista, que é um administrador de banco de dados Oracle de uma grande empresa. O objetivo principal
da validação foi verificar a correta aplicação do algoritmo do vizinho mais próximo e a confiabilidade dos
resultados apresentados pelo sistema.
O especialista criou cinco representações de caso, onde cada uma representou um tipo de problema
diferente a ser monitorado. Para cada representação de caso foram criadas consultas SQL específicas através
da interface de Cadastro de Atributos, conforme apresentado na Figura 12. Algumas das consultas foram
utilizadas em mais de um caso.
Figura 12 – Cadastro de Consulta SQL
15
Os pesos atribuídos para cada consulta SQL e a freqüência de coleta para cada representação foram
definidos pelo especialista de acordo com o que foi julgado mais importante para a caracterização de cada
problema. O limiar para todas as representações de caso foi inicialmente definido em 5.0, e posteriormente
alterado a fim de identificar o valor mais adequado para cada representação. A Figura 13 ilustra a criação de
uma das representações.
Figura 13 - Cadastro da Representação de Caso
Uma vez que as cinco representações de caso foram definidas, o especialista criou a base de
conhecimento. Através da tela de Cadastro de Caso na Base de Conhecimento, foram incluídos cinco novos
casos para cada representação, de categorias zero, um, ou dois. O especialista decidiu por não incluir
nenhum caso de categoria três (problema grave), pois achou mais interessante que o sistema realiza-se as
coletas e que a categoria de problemas considerados graves fosse modificada através do painel, quando
conveniente. Assim, a base de conhecimento do sistema foi inicialmente populada com 25 casos.
Durante o primeiro dia, o DBA verificou que o limiar definido em 5.0 estava alto demais para a
maioria dos casos, uma vez que de um total de 137 casos coletados, 84 apresentaram uma distância abaixo
do limiar, sendo que apenas 13 foram confirmados como identificações corretas, representando uma
confiabilidade do sistema de aproximadamente 15%. Sendo assim, ao longo dos cinco dias, o limiar das
representações foi sendo modificado para possibilitar uma melhor identificação e diferenciação dos casos. A
modificação do limiar de uma das cinco representações resultou, por exemplo, em uma confiabilidade de
87% ao final do período, conforme apresentado no Quadro 3.
Dia 1
Dia 2
Dia 3
Dia 4
Dia 5
Limiar
5,0
3,0
2,5
2,0
1,0
Total de coletas da representação
23
31
28
35
27
Coletas abaixo do limiar
17
18
13
10
8
Coletas corretamente identificadas
5
8
9
7
7
29%
44%
69%
70%
87%
Confiabilidade
Quadro 3 – Dados sobre as coletas de uma representação
Uma vez que o funcionamento do sistema é baseado em casos, os quatro passos do ciclo do RBC
devem ser seguidos. No momento em que um caso é exibido ao usuário através do painel de casos, as etapas
de recuperação e reutilização de caso já devem ter sido realizadas, portanto é esperado que a categoria do
novo caso possua o mesmo valor da categoria do caso semelhante recuperado. O mesmo deve acontecer
para o atributo solução. Sendo assim, o especialista realizou verificações constantes nas informações dos
16
casos apresentados no painel, e realizou algumas capturas de telas (Figura 14), para conferir se a categoria e
a solução foram atribuídas conforme esperado, se os valores retornados em cada coleta realmente estavam
próximos e se a distância calculada entre o novo caso e o caso semelhante estava abaixo do limiar.
Figura 14 – Caso recuperado e caso semelhante
Dessa forma, foi possível validar que as funcionalidades do sistema apresentaram comportamentos
dentro do esperado. Também foi verificado que o usuário não encontrou dificuldades de uso durante o
período de validação, o que confirma um bom grau de usabilidade das telas e interfaces de operações.
Por fim, o especialista sugeriu algumas modificações ao sistema, como evitar que casos iguais,
coletados durante um pequeno intervalo de tempo, sejam exibidos no painel. Esse cenário ocorreu durante
períodos em que um problema identificado no SGDBR demorou a ser solucionado, fazendo com que as
coletas realizadas durante esse intervalo possuíssem exatamente os mesmo valores de atributos. As
melhorias sugeridas serão consideradas para trabalhos futuros.
6
CONCLUSÃO
O raciocínio baseado em casos (RBC) foi, durante anos, uma das áreas com o crescimento mais
acelerado no campo de sistemas baseados em conhecimento. Através da recuperação e aplicação de
experiências passadas a novas situações de problemas, o RBC possui a capacidade de resolver questões
complexas. Considerado hoje um grande expoente dentre as metodologias de resolução de problemas, o
RBC utiliza a similaridade entre casos de um mesmo ambiente, sendo amplamente aplicado em sistemas de
informação nas mais diversas áreas e tecnologias.
Ao longo deste artigo foram descritas as etapas de implementação do RBC para a criação de um
sistema de monitoramento e identificação de problemas em sistemas gerenciadores de banco de dados
relacional (SGBDR). Os quatro processos do ciclo do RBC foram analisados e aplicados conforme as
necessidades apresentadas pelo especialista na área de administração de SGBDR, contribuindo para que o
objetivo inicial de auxiliar o administrador de banco de dados (DBA) em suas tarefas diárias pudesse ser
alcançado.
17
O resultado mais significativo obtido durante a validação deste sistema ocorreu quando o
especialista, e também DBA Oracle, classificou o aplicativo como uma ferramenta que incentiva a próatividade e, consequentemente, possibilita a diminuição no tempo de resolução de problemas. Segundo ele,
o diferencial apresentado em relação a sistemas já existentes no mercado está no armazenamento e na
utilização de experiências passadas, uma vez que uma base de conhecimento é criada e aperfeiçoada ao
longo do tempo. O especialista também destacou a importância no fato de o sistema realizar o
monitoramento automático e pontual do SGBDR com a utilização de consultas SQL definidas pelo próprio
usuário.
Assim, com a análise e o desenvolvimento do sistema apresentado neste artigo, bem como com os
resultados obtidos através do período de validação, acredita-se que as expectativas iniciais tenham sido
atendidas. Entende-se, entretanto, que melhorias possam ser realizadas para que esta ferramenta um dia
possa ser reconhecida e amplamente utilizada na área de SGBDR.
REFERÊNCIAS
AAMOD, A; PLAZA, E; Case-Based Reasoning: Foundational issues, Methodological Variations and
System Approaches. AI Communications, vol. 7, 1994
ALAPATI, Sam R. Expert Oracle Database 11g Administration. The Expert’s Voice in Oracle, 2009.
BRYLA, Bob. Oracle Database Foundations: Technology Fundamentals for IT Success. London, 2004.
CHEN, Peter Pin-Shan. The Entity-Relationship Model – Toward a Unified View of Data.
Massachusetts Institute of Technology, 1970.
CODD, Edgar Frank. A Relational Model of Data for Large Shared Data Banks. 1970
COPPIN, Ben. Artificial Intelligence Iluminated. Jones and Barlett Illuminated Series, Canada, 2004.
COVER, T; HART, P; Nearest Neighbor Pattern Classification. 1967
DHENE, Frank. Algorithms and Data Structures. Third Workshop, Montreal, Canada, 1993.
FORTA, Ben. SQL: Sams Teach Yourself. Third Edition Includes Coverage of MySQL and PostgreSQL;
2004
GOGOLLA, Martin; KOBRYN, Cris; UML 2001 – The Unified Modeling Language: Modeling
Languages, Concepts and Tools. 4th International Conference, Toronto, Canada, 2001.
KOFLER, Michael. The Definitive Guide to MySQL. New York, NY, 2005.
KOLODNER, Janet. Improving human decision making through case-based decision aiding. Artificial
Intelligence Magazine, 1991.
KOLODNER, Janet. Case-Based Reasoning. 1993.
MORTON, Karen; OSBORNE, Kerry; Pro Oracle SQL: Exploit the full power of SQL and supporting
features in Oracle Database. 2010
NILSSON, Nils J; Artificial Intelligence: a new synthesis. United States, 1998.
SATZINGER, John; JACKSON, Robert; BURD, Stephen; Systems Analysis & Design In a Changing
World. USA, 2009.
SCHMALHOFER, Franz; STRUBE, Gerhard; WETTER, Tomas. Contemporary knowledge engineering
and cognition. First Joint Workshop, 1991.
WATSON, John; RAMKLSS, Roopesh; OCA Oracle Database 11g: SQL Fundamentals I. USA, 2008.
18