SISTEMA DE MONITORAMENTO E IDENTIFICAÇÃO DE PROBLEMAS EM BANCOS DE DADOS BASEADO EM CASOS

Transcrição

1 SISTEMA DE MONITORAMENTO E IDENTIFICAÇÃO DE PROBLEMAS EM BANCOS DE DADOS BASEADO EM CASOS Guilherme Cruz <guilhermelvcruz@gmail.com> Fabiana Lorenzi <lorenzi@ulbra.br> Orientador Universidade Luterana do Brasil (Ulbra) Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas Câmpus Canoas Av. Farroupilha, Bairro São José CEP Canoas RS RESUMO 30 de novembro de 2011 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

2 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

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

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

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

6 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 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. Tabela 1 Valores para o atributo Categoria Valor Nome Descrição 0 Neutro Não há problemas. 3 Aviso Um novo problema pode ocorrer. 2 Problema Um novo problema está ocorrendo. 1 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

7 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

8 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

9 Quadro 2 Comparação de C1, C2 e novo problema Atributo Peso C1 C2 Problema ConsultaLocks ConsultaTabelas ConsultaUsuarios 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

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

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

12 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 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 Módulo Especialista Figura 7 Diagrama de atividades: monitoramento 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

13 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) 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 Interface de Monitoramento Figura 8 Menu do sistema 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

14 4.3.3 Base de Conhecimento Figura 9 Tela de monitoramento 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

15 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 (Seção 2.2). 5 VALIDAÇÃO E RESULTADOS Figura 11 Diagrama ER 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

16 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 Coletas abaixo do limiar Coletas corretamente identificadas Confiabilidade 29% 44% 69% 70% 87% 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

17 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

18 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, BRYLA, Bob. Oracle Database Foundations: Technology Fundamentals for IT Success. London, CHEN, Peter Pin-Shan. The Entity-Relationship Model Toward a Unified View of Data. Massachusetts Institute of Technology, CODD, Edgar Frank. A Relational Model of Data for Large Shared Data Banks COPPIN, Ben. Artificial Intelligence Iluminated. Jones and Barlett Illuminated Series, Canada, COVER, T; HART, P; Nearest Neighbor Pattern Classification DHENE, Frank. Algorithms and Data Structures. Third Workshop, Montreal, Canada, 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. 4 th International Conference, Toronto, Canada, KOFLER, Michael. The Definitive Guide to MySQL. New York, NY, KOLODNER, Janet. Improving human decision making through case-based decision aiding. Artificial Intelligence Magazine, KOLODNER, Janet. Case-Based Reasoning MORTON, Karen; OSBORNE, Kerry; Pro Oracle SQL: Exploit the full power of SQL and supporting features in Oracle Database NILSSON, Nils J; Artificial Intelligence: a new synthesis. United States, SATZINGER, John; JACKSON, Robert; BURD, Stephen; Systems Analysis & Design In a Changing World. USA, SCHMALHOFER, Franz; STRUBE, Gerhard; WETTER, Tomas. Contemporary knowledge engineering and cognition. First Joint Workshop, WATSON, John; RAMKLSS, Roopesh; OCA Oracle Database 11g: SQL Fundamentals I. USA,