FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS INÁCIO INOCENTI JUNIOR JAQUELIANE MACEDO DA SILVA

Transcrição

1 FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS INÁCIO INOCENTI JUNIOR JAQUELIANE MACEDO DA SILVA ANÁLISE DE DESEMPENHO E CARGA DE STRESS EM SISTEMAS DE BANCO DE DADOS ORIENTADO A OBJETOS SÃO JOSÉ DOS CAMPOS 2010

2 i INÁCIO INOCENTI JUNIOR JAQUELIANE MACEDO DA SILVA ANÁLISE DE DESEMPENHO E CARGA DE STRESS EM SISTEMAS DE BANCO DE DADOS ORIENTADO A OBJETOS Trabalho de graduação apresentado à faculdade de tecnologia Jesse Vidal de São José dos Campos, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Banco de Dados. Orientador: Carlos Augusto Lombardi Garcia, Me SÃO JOSÉ DOS CAMPOS 2010

3 ii INÁCIO INOCENTI JUNIOR JAQUELIANE MACEDO DA SILVA ANÁLISE DE DESEMPENHO E CARGA DE STRESS EM SISTEMAS DE BANCO DE DADOS ORIENTADO A OBJETOS Trabalho de graduação apresentado à faculdade de tecnologia Jesse Vidal de São José dos Campos, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Banco de Dados. ADRIANA DA SILVA JACINTO, ME JULIANA FORIN PASQUINI MARTINEZ, ME CARLOS AUGUSTO LOMBARDI GARCIA, ME 20/12/2010

4 iii AGRADECIMENTOS Agradeço a minha família pelo apoio e compreensão, a professora Juliana pela atenção e disposição, a o professor e orientador Garcia pelo apoio, aos demais professores pelas contribuições sempre positivas, e a os meus amigos e colegas. Jaqueliane Macedo da Silva

5 iv RESUMO A grande valorização do controle da informação e do conhecimento, pelas empresas a partir do início desse século, fez com que o setor tecnológico principalmente os setores voltados à área de Tecnologia da Informação tivessem um crescimento técnico considerável, porém a demanda e o volume de informações do mundo globalizado tende a tornar esse crescimento insuficiente. Tendo isso em vista, este trabalho analisa uma tecnologia importante no controle, gerenciamento e armazenamento das informações, o sistema de gerenciamento de banco de dados o SGBD, trazendo uma tecnologia de banco de dados pouco utilizada, mas com potencial para suportar grandes volumes de informações e dados complexos, a tecnologia de banco de dados orientado a objetos, que será comparada com uma tecnologia já comprovada e presente no mercado, a tecnologia de banco de dados relacional. Palavras Chave: Banco de dados orientado a objeto, banco de dados relacional, análise de desempenho.

6 v ABSTRACT The great importance of information governance and knowledge by firms from the beginning of this century has made the technology sector especially the ones focused on the area of Information Technology had a significant technical growth, but the demand and volume of information the world globalization tends to make this poor growth. With this in mind, this paper will examine an important technology in the control, management and storage of information, the management system database, the database system, bringing a technology database rarely used, but with potential to support large volumes of information and complex data, technology-oriented database object, which will be compared with a technology already proven in the market and the technology of relational database. Keywords: Database object oriented, relational database, performance analysis.

7 vi ÍNDICE DE FIGURAS Figura Exemplo de classe usando herança 7 Figura Modelagem BDOO 9 Figura Representação de associação entre as classes 10 Figura Representação de agregação entre as classes 10 Figura Representação de composição entre as classes 10 Figura Arquitetura do Sistema Iris 13 Figura Arquitetura do Sistema GemStone 14 Figura Gráfico Comparativo com as versões Oracle mais utilizadas no mundo 24 Figura Exemplo de conexão JDBC no Caché 27 Figura Exemplo de Modelo de Classe 30 Figura Exemplo de Referência Simples 32 Figura Relacionamento One to Many 32 Figura Relacionamento Parent Children 32 Figura Composição 33 Figura Herança 33 Figura 3.8 Tabela de Multiplicidade 34 Figura Exemplo de Objeto 36 Figura Tabela de Namespaces 37 Figura Estudo de Caso Hospital e Maternidade Marieta Konder Bornhausen 39 Figura Digrama de caso de uso hospital e maternidade Marieta Konder Bornhausen 42 Figura Diagrama de Classe (Agendamento) 43 Figura Diagrama de Classe (Atendimento) 44 Figura Diagrama de Classe (Convênio) 44 Figura Diagrama de Classe (Funcionário) 45 Figura Diagrama de Classe (Medico) 46 Figura Diagrama de Classe (Paciente) 46 Figura Diagrama de Classe (Produto) 47 Figura Diagrama de Classe (Remédio) 47 Figura Modelo Conceitual Hospital e Maternidade Marieta Konder Bornhausen 48

8 vii Figura Lógico Hospital e Maternidade Marieta Konder Bornhausen 48 Figura Modelo de Dados OO 49 Figura Composição (Classe Endereço e Pessoa) 50 Figura Herança (Classe Pessoa, Paciente, Funcionário e Medico) 50 Figura Relacionamento Classe Paciente, Medico, Funcionário, Convenio e Agendamento 51 Figura Relacionamento Classe Agendamento e Atendimento 51 Figura Classe Remédio e Produto 52 Figura Definição da Classe Agendamento 53 Figura Definição da Classe Atendimento 54 Figura Definição da Classe Convênio 55 Figura Definição da Classe Endereço 56 Figura Definição da Classe Funcionário 57 Figura Definição da Classe Medico 58 Figura Definição da Classe Paciente 59 Figura Definição da Classe Pessoa 60 Figura Definição da Classe Produto 61 Figura Definição da Classe Remédio 62 Figura Adicionando Grupo de Usuários (Thread Group) 64 Figura 4.2- Thread Group 64 Figura Tabela de parâmetros de um Thread Group 65 Figura Adicionando uma Requisição JDBC 65 Figura Requisição JDBC 66 Figura Tabela de parâmetros de uma requisição JDBC 67 Figura Adicionando um Elemento de Configuração de Conexão JDBC 67 Figura Parâmetros de Conexão com Banco de Dados 68 Figura Tabela de parâmetros de uma conexão JDBC 68 Figura Adicionando um Relatório 69 Figura Tabela de medidas do obtidas em um relatório 70 Figura Medida da amostra de quatrocentos usuários na análise de persistência de dados 72 Figura Medida do valor máximo obtido na persistência 73 Figura Medida do valor mínimo obtido na persistência 73

9 viii Figura Medida do valor médio obtido na persistência 74 Figura Análise de Busca Cinco Usuários por Segundo 75 Figura Média dos tempos de resposta para cinco usuários por segundo 75 Figura Medida do valor mínimo obtido na busca com cinco usuários 76 Figura Medida do valor máximo obtido na busca com cinco usuários 76 Figura Valor de vazão das requisições atendidas por segundo com cinco usuários 77 Figura Quantidade de carga em KB transferidos por segundo com cinco usuários 77 Figura Análise de Busca Cinquenta Usuários por Segundo 78 Figura 4.23 Média dos tempos de resposta para cinquenta usuários por segundo 78 Figura Medida do valor mínimo obtido na busca com cinquenta usuários 79 Figura Medida do valor máximo obtido na busca com cinquenta usuários 79 Figura Número de vazão das requisições atendidas por segundo com cinquenta usuários 80 Figura 4.27 Quantidade de carga em KB transferidos por segundo com cinquenta usuários 80 Figura 4.28 Análise de Busca com Quinhentos Usuários por Segundo 81 Figura 4.29 Média dos tempos de resposta para quinhentos usuários por 82 Figura Medida do valor mínimo obtido na busca com quinhentos usuários 82 Figura Medida do valor máximo obtido na busca com quinhentos usuários 83 Figura Número de vazão das requisições atendidas por segundo, com quinhentos usuários 83 Figura Quantidade de carga em KB transferidos por segundo com quinhentos usuários 84

10 ix LISTAS DE ABREVIATURAS E SIGLAS BD: Banco de Dado BDOO: Banco de Dado Orientado a objeto OO: Orientado a Objeto SGBD: Sistema de Gerenciamento de Banco de Dado SGBDOO: Sistema de Gerenciamento de Banco de Dado Orientado a Objeto SGBDOR: Sistema de Gerenciamento de Banco de Dado Objeto-Relacional SGBDR: Sistema de Gerenciamento de Banco de Dado Relacional UML: Unified Modeling Language JDBC: Java Database Connectivity RAM: Memória de Acesso Aleatório (Random Access Memory) CPU: Unidade Central de Processamento (Central Processing Unit)

11 x SUMÁRIO 1. INTRODUÇÃO Motivação Objetivos Objetivo Geral Metodologia Organização do Trabalho 3 2. REVISÃO BIBLIOGRÁFICA Visão Gera Princípios da Orientação a Objeto Modelagem de Dados OO Incorporação da OO em Banco de Dados Primeiros Sistemas Gerenciadores de Banco de Dados Orientados a Objetos Gerenciadores de Banco de Dados Orientado a Objetos Objetos e Atributos Herança e Tipos de Objetos Consultas Identificadores Atributos Associações Bancos de Dados Relacionais Conceitos Básicos SGBDR Aspecto armazenamento SGBDR As principais vantagens SGBD Considerações Finais DEFINIÇÃO E CONCRETIZAÇÃO DA BASE DE ESTUDOS Sistemas Gerenciadores de Banco de Dados Escolhidos Para Estudo Oracle 10g Express Edition Oracle 10g Limitações do Oracle 10g Express Edition Características do Oracle 10g Express Edition 26

12 xi Desvantagem do Oracle 10g Express Edition Utilização do Oracle 10g Express Edition Banco de Dados Orientado a Objetos do Estudo Modelagem de Dados Modelo de Classes Tecnologia de Objetos x Tecnologia Relacional Panorama do Modelo OO NameSpaces Ferramentas, Paradigma e Padrão de Projeto Apache JMeter Estudo de Caso: Hospital e Maternidade Marieta Konder Bornhausen Requisitos do Sistema Diagrama de Caso de Uso Diagramas de Classe Modelo Conceitual Modelo Lógico Modelagem para Banco de Dados OO Criação do Banco de Dados OO Definição das Classes ANÁLISE DE DESEMPENHO E CARGA DE STRESS Elaborando Plano de Teste com JMeter Resultados e Analises CONSIDERAÇÕES FINAIS Contribuições e Conclusões Trabalhos Futuros 88 ANEXOS 89 REFERÊNCIAS BIBLIOGRÁFICAS 91

13 1 1 INTRODUÇÃO 1.1 Motivação Atualmente, na Engenharia de Software, permanece uma imensa busca por mais eficiência e facilidade na produção e desenvolvimento, principalmente quando é algo complexo e que está constantemente em mudança. É ótimo poupar tempo e trabalho quando é necessário fazer algumas adaptações em um sistema ou aplicativo que já está funcionando. A busca por essas facilidades é constante, principalmente dentro do universo computacional que além de bastante complexo exige que seja prático e eficiente. Dessa busca de eficiência nos sistemas foi desenvolvida a programação orientada a objeto. Orientação a objeto é um conjunto de técnicas para o desenvolvimento de software que basicamente utiliza a composição de objetos individuais, que ajuda a construir um sistema mais reutilizável e eficiente. Hoje, em dia, as aplicações de bancos de dados têm exigido cada vez mais, por estarem mais complexas e variadas. Devido a uma grande quantidade de dados e um pedido de tempo de resposta das consultas e das transações muito pequena, isso gera a necessidade de ferramentas mais eficazes para atender toda essa demanda. Nas aplicações atuais, é muito comum encontrar SGBD relacionais para o gerenciamento dos dados, que com certeza tem inúmeras vantagens, porém, com essa demanda intensa dos volumes de dados tem limitado, de certo modo, o desempenho relacional. Uns dos problemas encontrados no modelo relacional são mapear os objetos para o modelo da base de dados, e as tuplas de relação são identificadas pelo os seus valores que não são fixos, o que gera uma complicação quando ocorre um tipo de alteração; o que não ocorre no modelo orientado a objeto. Por haver esses inconvenientes, buscam-se conceitos alternativos de bancos de dados para solucionar esses tipos de problemas. Visto um gancho de paradigmas que contribuiria para

14 2 aperfeiçoar tal desempenho, principalmente em questões de escalabilidade de sistemas, desperta um interesse para unir conceitos de orientação a objetos em bancos de dados. 1.2 Objetivos A seguir serão apresentados os objetivos desse trabalho Objetivo Geral Este trabalho tem como intuito realizar um estudo prático de analise de desempenho e carga de stress do padrão de banco de dados orientado a objetos em relação ao padrão de banco de dados relacional por meio de exemplos, testes, estudo de casos, etc Resultados Esperados Os resultados esperados para este trabalho são: a) Mostrar como é possível fazer a transição de aplicativos que são implementados seguindo o padrão de banco de dados relacional para o padrão de banco de dados orientado a objetos; b) Comprovar através de coleta de resultados concretos a diferença de desempenho e capacidade de carga de cada SGBD; c) Fazer uma análise crítica de forma comparativa do desempenho do Banco de Dados Relacional em relação ao Banco de Dados Orientado a Objeto.

15 3 1.3 Metodologia Para atingir os objetivos desse trabalho, será realizado o estudo do tema proposto, buscando exemplos de sistemas que usam banco de dados orientado a objetos e relacional, além de artigos, dissertações e teses que façam a análises de tais bancos. E a partir dessa teoria analisar de forma pratica ambos os bancos, submetendo-os a testes para avaliar suas propriedades, como limitações e desempenho. 1.4 Organização do Trabalho Este Trabalho está organizado da seguinte forma: Capítulo 1 - Introdução: Este tópico mostra os problemas e necessidades existentes dentro do contexto de um SGBD, e quais desses problemas e necessidades são endereçadas ao SGBDOO; Capítulo 2 - Revisão Bibliográfica: Neste capítulo serão apresentados os conceitos que fundamentam um Sistema Gerenciador de Banco de Dados Orientado a Objetos e um Relacional; Capítulo 3 - Definição e Concretização da Base de Estudos: Este capítulo terá por objetivo mostrar como seguirá o estudo, visando a obtenção da solução proposta; Capítulo 4 - Análise de Desempenho e Carga de Stress: Neste Capítulo serão apresentados os resultados e os meios seguidos para obtê-los; Capítulo 5 - Considerações Finais: Este capítulo terá como objetivo apresentar de forma sólida as argumentações finais do trabalho.

16 4 2. REVISÃO BIBLIOGRÁFICA 2.1 Visão Geral Banco de Dados tem como objetivo a persistência de dados contendo as informações necessárias para o tipo de sistema e o relacionamento entre elas. Para que o sistema seja eficiente, ele tem que ser capaz de guardar todas as informações com precisão. É necessário reproduzir o maior número de informações possíveis para o funcionamento do sistema. E isso se torna umas das maiores dificuldades de um sistema, reproduzir as informações detalhadas e as relações entre elas. Seja o, de um sistema de um estabelecimento comercial que possui vários clientes. É necessário guarda as informações dos clientes, informações essas como nome, endereço, telefone, CPF, RG. Parece simples armazenar essas informações, cria-se um registro numa tabela no banco de dados para cada cliente e pronto problema resolvido. Porém, não é tão simples assim, é preciso analisar a seguinte situação, que cada cliente pode ter mais de um telefone e mais de um endereço; e assim notam-se quanto os dados podem ser complexos e cheios de detalhes. Uma solução para esta necessidade seria obter um padrão para armazenar e gerenciar as informações de forma que não falte nenhuma informação. Para isso, foram desenvolvidos sistemas de gerenciamento de banco de dados. Já existem, algum tempo no mercado alguns softwares para o gerenciamento de informações de dados, que surgiu por causa da complexidade dos dados e para facilitar a persistência dos dados na base, a manipulação e segurança dos dados, entre outras coisas. Para administrar essas informações, utilizam-se os SGBDs (Sistema de gerenciamento de banco de dados) com o objetivo de armazenar as informações e facilitar o acesso a elas. Alguns tipos de SGBDs são (SGBDR) Relacional, (SGBDOO) Orientado a objeto e o (SGBDOR) Objeto-Relacional. No SGBDR, seus dados são percebidos e relacionados como tabelas; ele tem sido o mais utilizado nas aplicações de armazenamento dos objetos, por vários motivos sendo que o principal deles, possuir a liderança do mercado devido a um

17 5 grande investimento na tecnologia relacional, e por já estar a muito tempo nas empresas. SGBD Orientado a Objetos utiliza os benefícios que a linguagem de programação de orientação a objeto possui, reutilizando esses benefícios na persistência dos objetos no banco de dados. No SGBDOO armazenam-se os dados junto com os métodos, e esses mesmos métodos acessam e manipulam esses dados. Utilizam-se também conceitos SGBDs que não são Orientados a objetos, por exemplo, ele possui gravações, recuperações, bloqueio de transações, integridade dos dados e distribuições dos dados. São algumas das características que compõem o SGBDOO, mas claramente o SGBDOO soma às funcionalidades do SGBD a linguagem de programação orientada a objeto. SGBDOR Objeto-Relacional utiliza propriedade dos dois tanto do SGDBR e do SGBDOO, é a tentativa de aproximar o relacional com orientado a objeto, devido à evolução dos sistemas surgiu essa necessidade de aproximação dos tipos de modelagem de Banco de dados para unir a eficácia entre os dois. De forma geral esse é o conceito que esse trabalho apresentará ao longo do seu desenvolvimento (COSTA, 2000). 2.2 Princípios da Orientação a Objeto Orientação a objeto é um paradigma para facilitar o desenvolvimento de um programa; o seu conceito é composto por classe, herança, polimorfismo, encapsulamento. Utilizando esse conceito facilita o desenvolvimento do sistema, deixando-o mais reutilizável e fácil de fazer alteração. O conceito de Orientação a Objeto foi desenvolvido na Linguagem de programação Simula. A Simula foi desenvolvido por Kristen Nygaard e Ole-Joham Dahl entre 1962 a 1964 no Norwegion Computing Center, com o objetivo de simulação de sistemas que foi denominada como Simula I, mas após a sua conclusão, iniciaram uma nova versão para acrescenta novos recursos mais utilizáveis para aplicações mais genéricas, assim lançou a Simula 67, em 1967, que desenvolveu a construção de classes e começou iniciar o conceito de OO. Mas esse conceito só começou a ser aceito nas linguagens de programação a partir de 1980, com a

18 6 linguagem Smalltalk que se baseou na Simule 67 e aplicou o conceito de OO. Na Smalltalk todas as informações são armazenadas em forma de objetos sendo as informações simples ou não. A execução da linguagem Smalltalk é feita através de interpretação. Hoje em dia as linguagens de orientação a objeto mais utilizadas são Java e C++. C++ não é uma linguagem interpretada, as operações são realizadas em tempo de compilação, ela é representada em forma de objetos que representam entidades do mundo real. Linguagem de programação Java foi desenvolvida pela SUN, é uma linguagem mais simples em relação a C++, seus programas são compilados através de uma máquina virtual que interpreta seus os códigos de operação. Essas são algumas das linguagens que são orientadas a objeto. Esse conceito de Orientação a Objeto basicamente se resumi em um Modelo de Objetos, mensagem e métodos; Classe, Atributos, Herança, Encapsulamento e Polimorfismo. Programação Orientada a Objeto foi desenvolvida para retratar o mundo real dentro do computador, para isso são utilizados objetos. A programação Orientada a Objeto faz a comunicação entre os objetos, essa comunicação é feita através de uma troca de mensagem entre os objetos. É necessário especificar a mensagem que cada objeto deve receber e o que ele deve fazer quando receber a mensagem; essa mensagem é um texto de forma que cada objeto consegue identificar e realizar as instruções determinadas; informações também podem ser passadas através de parâmetros, que são argumentos que uma mensagem pode receber para que os objetos possam se comunicar entre si. Objetos são informações e descrições do mundo real. Classe é a organização do objeto e contém a descrição do que é necessário para compor o objeto. Atributos contem o valor e as informações detalhadas que caracterizam o objeto (RICARTE, 1998).

19 7 Herança, uma classe herda as características de outra já existente como ilustra a figura 2.1, a nova classe pode herdar os atributos e os métodos da outra classe. Encapsulamento guarda e protege os dados para que eles possam ser reusados, tem algumas privações porem é eficaz na reutilização. O polimorfismo constrói um padrão que poder ser usado por outras classes. Figura Exemplo de classe usando herança. Fonte: MCLAUGHLIN, 2007 Resumidamente esse é o conceito de orientação a objeto, que tem como objetivo facilitar e aperfeiçoar a programação de um software. 2.3 Modelagem de Dados OO Modelo de dado é a forma que o sistema esta organizado, é a estrutura que compõem o sistema. Na modelagem OO é organizada utilizando os seguintes princípios; classe, heranças, métodos, mensagens, polimorfismo, encapsulamento, abstração e objetos. Classes: agrupa todos os objetos que são do mesmo tipo, ou seja, os que possuem as mesmas características. Heranças: cria-se um modelo para um tipo incremental, esse modelo pode ser reutilizado na criação de um novo tipo, um transmiti para o outro a sua estrutura de comportamento, evitando o trabalho de ter que fazer tudo de novo à mesma estrutura, a herança permiti que uma classe herde as características de outra. Na parte de Banco de Dados simplificaria a parte

20 8 de esquema. Existem dois tipos de herança, simples e múltiplas. Na herança simples um tipo tem apenas um supertipo do mesmo jeito uma subclasse herda somente de uma única classe. Na herança múltipla um tipo (filho) pode ter mais de um supertipo (pai). Métodos: fala o que um objeto deve fazer, atendendo as operações associadas a uma ou mais classes. Mensagens: é a forma de ativar os métodos e, também, a maneira como os métodos usam para se comunicarem entre si. Um método troca informações com outro, através de mensagens. Polimorfismo: usando polimorfismo a mesma operação pode atender requisições diferentes em classes diferentes, é também a forma de unir as funcionalidades das classes. Encapsulamento: é identificar as operações diferentes e criar um padrão para manipulá-las, para poder lidar com as complexidades das operações. Abstração: é analisar uma parte em comum de um conjunto de objetos, e formar um tipo a partir de outro, utilizando a análise. Objeto: são as necessidades do mundo real que precisam ser retratadas dentro do sistema, possuem um nome do tipo de operação e ficam armazenadas ocultamente. Um objeto possui atributos que são características internas do objeto. Identidade do objeto: eles são independentes do armazenamento físico; os identificadores persistem os objetos de forma que não dependem do estado interno dos objetos, é o próprio sistema que cria uma identidade para cada objeto. A identidade contribui para a integridade de cada objeto e evita problemas, como anomalias quando se é preciso fazer atualizações nos objetos. Objetos complexos: é a complexidades dos objetos, ou seja, os tipos de construtores que compõem os objetos, esses tipos são tuplas, registros, coleções, arrays, listas, conjuntos. No modo Orientado a objeto qualquer tipo de construtor pode ser aplicado a qualquer objeto, já no modelo relacional os construtores só podem ser aplicados nas tuplas e nos registros que

21 9 possuem valores atômicos. Para fazer a manutenção dos objetos tanto no modelo orientado a objeto quanto no modelo relacional é necessário definir operadores de manipulação, alguns desses operadores são atualizar e remover objetos. Tipos de objetos: é a descrição dos objetos, ele é composto pela a interface e a implementação, ele serve para modelar as estruturas dos objetos e ajuda manter a segurança. No desenvolvimento de um SGBD é utilizado todo esse conceito, que traz a abrangência de soluções mais eficazes e de níveis mais seguros nas consistências dos objetos e facilitam a manipulação e o relacionamento entre esses objetos, assim possibilitam a eficiência e a otimização de um sistema de gerenciamento de Banco de Dados. Veja alguns exemplos de modelagem de dados com OO nas figuras a seguir. A figura 2.2 representa a utilização desses conceitos citados ate o momento, e nas figuras 2.3, 2.4 e 2.5 representam especificamente alguns dos detalhes que compõem os conceitos da OO (RICARTE, 1998). Figura Modelagem BDOO Fonte: ALMEIDA, 2005

22 10 Figura Representação de associação entre as classes. Fonte: Conceitos da orientação a objetos, Disponível em: Figura Representação de agregação entre as classes. Fonte: Conceitos da orientação a objetos, Disponível em: Figura Representação de composição entre as classes. Fonte: Conceitos da orientação a objetos, Disponível em:

23 Incorporação da OO em Banco de Dados Banco de Dados distribuídos é um conjunto de base de dados ligados logicamente e espalhado por uma rede de computadores. No Banco de Dados distribuídos os arquivos podem estar fragmentado ou replicados, esses dados replicados geram uma cópia de todos os dados deixando as bases iguais. Na fragmentação, os dados são divididos no sistema, de maneira que, quando visualizados de forma local, as bases de dados parecem diferentes, mas visualizadas de forma global os dados são visto de forma única. Há dois tipos de Bancos de Dados distribuídos os homogêneos que são compostos pelos mesmos bancos de Dados e heterogêneos que são compostos por mais de um tipo de Bancos de Dados. Os SGBDs já atendem a um grande número das necessidades dos sistemas de Banco de dados distribuídos, como acesso concorrente de múltiplos usuários, controles de transações atômicas, recuperação de dados no caso de ocorrer alguma falha e condições que avalie as consistências dos dados durante os seus procedimentos. Mesmo assim, atendendo a todas essas necessidades, ainda ficam algumas questões a desejar, portando se desenvolveu a necessidade de unir as boas resoluções da programação orientada a objetos nos sistemas de bancos de dados. O interesse de unir orientação a objeto a banco de dados veio a partir da ideia de representar objetos do mundo real que são do mesmo gênero mas possuem alguma distinção, representaria esses objetos na base de dados através da abstração, esse conceito poderia ser a solução para o problema de diferença entre descrições de objetos causadas por diferenças linguísticas, ou seja, (o gap semântico) da modelagem e o mundo real. Referência gap de semântica (SOUZA, 2006). Por haver essa possibilidade de resolução desse tipo de problema, despertou-se o interesse de incorporar os conceitos da orientação a objeto nos sistemas de bancos de dados. Essa incorporação traz soluções para vários tipos de mecanismo no banco de dados, soluções essas, identificar os objetos, objetos compostos, referências, integridade, tipos, procedimentos e comportamentos associados entre os objetos, encapsulamento de objetos, ordenarem os

24 12 conjuntos de soluções, grandes blocos de dados, acesso remoto, alteração no esquema sem grandes danos nos dados já armazenados, interface de programação e diferentes versões de evoluções dos objetos. A possibilidade de todas essas soluções dentro desses mecanismos foi o que motivou os estudos de fazer essa integração, já que tem essa possibilidade grandiosa de ser obter a evolução e a otimização nos procedimentos já utilizados no SGDB. 2.5 Primeiros Sistemas Gerenciadores de Banco de Dados Orientados a Objetos Com crescimento modelo de orientação a objeto, alguns protótipos começaram a ser desenvolvidos para se tentar criar um sistema gerenciador de banco de dados (SGBD), que agregasse de alguma maneira os conceitos da orientação a objeto. O sistema Iris é um desses protótipos, que foi desenvolvido pela Hewlett-Packard, e tinha o intuito de analisar as funcionalidades que um sistema gerenciador de banco de dados orientado a objeto poderia oferecer. Para isso, o sistema Iris buscou incorporar novos mecanismos de modelagem e construção de tipo de dados, suporte a inferências no banco de dados, além de suporte a transações longas e múltiplas versões da base de dados. Assim, o sistema possibilitaria que varias aplicações de linguagens distintas interagissem com o sistema gerenciador de objetos, para isso as aplicações teriam suas construções mapeadas para construções interna do gerenciador (RICARTE, 1998).

25 13 Mesmo assim, o sistema Iris teve que recorrer a um sistema gerenciador de banco de dados relacional desenvolvido pela HP, para desenvolver seu módulo gerenciador de armazenamento. O sistema foi desenvolvido na linguagem C em estações de trabalho Unix (HP-9000). A seguir a figura 2.6 ilustra a arquitetura do sistema Iris Figura Arquitetura do Sistema Iris. Fonte: RICARTE, 1998 O sistema ainda apresentou três tipos de interfaces com as aplicações, uma usualmente conhecida que usava a linguagem OSQL em conjunto com alguma outra linguagem de programação, outra que apresentava o gerenciador como um objeto para a aplicação, tendo métodos atribuídos ao objeto para interação com o sistema, e por fim a última abordagem que visava explorar o modelo de persistência de objeto, onde os objetos eram manipulados pelo gerenciador de forma transparente para o programador. Além dessas funcionalidades, o sistema também possuía um editor gráfico desenvolvido em Lisp, para facilitar o desenvolvimento dos esquemas de objetos. O sistema IRIS posteriormente daria origem a um produto desenvolvido pela HP, o OpenDB (RICARTE, 1998).

26 14 Outro protótipo que pode ser citado como exemplo é o sistema GemStone, desenvolvido pela Servio Logic Corporation. O sistema GemStone a principio usava a linguagem Smalltalk, que acabou sendo modificada para que se fosse possível a manipulação de uma base de dados, com essa mudança surgiu a linguagem OPAL, que seguia o conceito da teoria dos conjuntos para desenvolver seu modelo de dados. A figura 2.7 ilustra de maneira simplificada a arquitetura do sistema GemStone. Figura Arquitetura do Sistema GemStone. Fonte: RICARTE, 1998 O módulo Gem compilava programas em OPAL, tendo recursos de verificação de autorização de usuários além de fornecer conjuntos de classes e métodos pré-estabelecidos para as aplicações, e quando o sistema era carregado no servidor o modulo Gem também era responsável pelo controle das conexões com as sessões cliente. Módulo Stone, para este modulo cabia a tarefa de gerenciador de dados, com funcionalidades típicas de um sistema gerenciador de banco de dados, como entrada e saída de disco, transações e controle de concorrência. O sistema GemStone usava a linguagem OPAL, mas posteriormente o sistema passou a suportar a linguagem C++, possibilitando o desenvolvimento de aplicações nessa linguagem (RICARTE, 1998).

27 Gerenciadores de Banco de Dados Orientado a Objetos Alguns aspectos que apenas um sistema de gerenciador de banco de dados orientado a objetos possui são de grande importância para o entendimento do mesmo, como tais sistemas trabalham os conceitos de herança e atributos, por exemplo, e esses aspectos serão apresentados nas sessões subseqüentes Objetos e Atributos Diferentemente do modelo relacional, um banco de dados orientado a objetos, não depende de seus atributos para definir um identificador e, por isso, um banco de dados orientado a objetos não possui limitações relacionadas ao processamento de chaves primárias e estrangeiras, presentes em bancos de dados relacionais. Atributos de objetos são características que estão presentes em qualquer sistema gerenciador de banco de dados, mesmo os puramente relacionais, em que os atributos podem assumir valores atômicos ou apenas literais, porém um banco de dados orientado a objeto pode trabalhar seus atributos de forma mais abrangente, podendo ter atributos simples, onde os valores dos atributos são puramente literais e também atributos complexos, que podem ser referências, coleções ou virtuais. O tipo referencial ou associativo é usado para estabelece relações entre os objetos, já as coleções são usadas para definir conjuntos de dados, como listas ou arranjos de valores enquanto os atributos complexos virtuais ou derivados são atributos onde seus valores não são gravados de maneira explicita no banco, e sim armazenados por meio de procedimentos, tais atributos geralmente são definidos como apenas leitura, e dificilmente tem seus valores atualizados (RICARTE, 1998).

28 Herança e Tipos de Objetos A definição dos tipos de objetos em um sistema de banco de dados orientado a objetos é feita através de uma linguagem de definição de objeto, que permite a definição de procedimentos associados a sua estrutura (como no caso dos atributos virtuais). Além disso, a linguagem de definição de objetos permite também a criação de novos tipos de objetos a partir de tipos já existentes, criando então subtipos de objetos, isso se faz aplicando o conceito de herança, que é o mesmo conceito de generalização usado em banco de dados relacionais. Os subtipos criados herdam os objetos dos tipos já existentes, mesmo assim os novos tipos criados podem se diferenciar de seu pai, isso é feito com a criação de novos atributos, ou ainda sobrescrevendo algum método herdado, e assim cria-se uma estrutura de tipos de dados relacionados. Outro conceito de definição de objeto aplicado em um sistema de banco de dados orientado a objeto é o conceito de herança múltipla, que é semelhante à herança, só que neste caso o subtipo criado pode herdar objetos de mais de um pai, o uso de herança múltipla também pode causar falta de semântica em alguns casos, além de possíveis conflitos de resolução de atributos ou métodos. Já à modificação de um tipo em um sistema de banco de dados orientado a objeto, acarreta na mudança da estrutura do esquema de dados, coisa que não ocorre em um sistema relacional, já que quando era feita uma modificação de um tipo nesse sistema de banco de dados, as alterações afetavam em sua grande parte as aplicações (RICARTE, 1998).

29 Consultas De grande importância para aplicações que interagem com um sistema banco de dados, as consultas são responsáveis pela obtenção das operações realizadas na base de dados, em um sistema que segue o modelo relacional é necessária uma linguagem especifica de manipulação de dados para efetuar as consultas, porém como há diferenças entre as linguagens desenvolvidas para programação (orientadas a objeto) e a linguagem de manipulação de dados relacionais, cria-se um problema conhecido com impedance mismatch, que é a falta de compatibilidade entre as linguagens. O que não é problema para os sistemas de base de objetos, que podem oferecer mecanismos de persistências de objetos incorporados na linguagem de programação, como por exemplo, a persistência feita por métodos de especificação, que são por tipo, por invocação explícita ou por referência. Na especificação de persistência por tipo, apenas alguns tipos pré-definidos de objetos podem ser persistentes para base de objeto, agora na especificação por invocação explícita, a aplicação solicita o armazenamento persistente do objeto em questão explicitamente, e enquanto a por referência um ou mais objetos são declarado persistentes (raízes), e os demais objetos que são referenciados por eles, automaticamente também se tornam persistentes, assim solucionando o problema de impedance mismatch em consultas. Outro fato importante em relação a consultas em sistemas de base de objetos é o tipo de resultado que pode ser gerado pelas consultas. Em sistemas relacionais os resultados das consultas são relações, já em sistemas com orientação a objetos a flexibilidade é maior, alguns sistemas podem limitar os resultados por tipos específicos de objetos (RICARTE, 1998) Identificadores A representação de objetos em um sistema de banco de dados orientado a objetos é feita por meio da criação de identificadores, que é de grande importância em relação ao desempenho do sistema, e pode ser feita de duas maneiras, com a representação física ou lógica do objeto.

30 18 A representação física possui o endereço real do objeto na memória, e sua identificação é feita pela posição da memória onde o objeto foi criado. A representação lógica exige o mapeamento entre uma representação interna e o endereço do objeto. Abordagens básicas de criação de identificadores são feitas utilizando endereços estruturados, que contém representações lógicas e físicas, com a utilização de surrogates, identificadores lógicos que são mapeados para endereços físicos através de um índice ou de uma tabela, e a utilização de surrogates tipados, onde a informação sobre o tipo do objeto é incluída no identificador lógico. Sem os identificadores de objetos a consistência de um banco de dados orientado a objetos estaria comprometida, já que os identificadores são usados tanto pelas aplicações e pelo próprio sistema de base de objeto para representar as associações de objetos. Um o identificador deve também garantir sua qualidade de único, para isso alguns sistemas tratam de garantir que os identificadores de objetos removidos não sejam reutilizados, já outros sistemas que atuam com múltiplas bases de dados em rede garantem a unicidade do identificador, incorporando o endereço da maquina servidora no identificador de objeto. Quanto ao desempenho de recuperação de objetos, os identificadores simplesmente físicos apresentam um melhor desempenho, porém esses tipos de identificadores são menos flexíveis quanto à alocação dos objetos na base, dificultando operações como realocação de objetos, que pode ser necessária para ampliar o espaço de armazenamento associado a um objeto ou realizar uma compactação ou reclustering da base de dados. Por esse aspecto, o endereçamento físico não é utilizado. Alguns sistemas também oferecem a possibilidade de localizar um objeto por atributos chaves, que é muito semelhante ao utilizado pelos sistemas tradicionais, onde os valores atribuídos como chaves são mapeados através de índices (RICARTE, 1998).

31 Atributos Inicialmente alguns protótipos de sistemas gerenciadores de base de objeto, propunham que a maneira mais simples de representação dos atributos de objetos era através de relações com campos de dimensões fixas que, no entanto limitava a flexibilidade dos atributos, já que não permitia trabalhar com campos de dimensões variáveis, como por exemplo, atributos do tipo de coleções com quantidade variável de elementos. Mas logo, com a utilização de listas de propriedades, a implementação de atributos se tornou mais versátil. Uma lista de propriedades é representada por três campos, um campo identificador de atributo, um campo com o tamanho do valor do atributo e um campo com o valor do atributo. Atributos podem ser representados de maneira diferenciada quando existe o conceito herança entre os objetos, se a relação de herança entre os objetos for simples, a lista de propriedades ainda pode ser usada, pois a lista de propriedade é capaz de fazer a junção dos atributos do objeto pai e o objeto sucessor, mas caso exista herança múltipla a lista de propriedade é incapaz de resolver conflitos entre tipos ancestrais e atributos com o mesmo nome, tendo assim a necessidade de mecanismos mais complexos para resolver tais problemas. Outro fator importante a se observar em um sistema de gerenciador de banco de dados orientado a objeto é o conceito de coleções, que é largamente utilizada para a descrição dos atributos de objetos e no retorno de consultas. A manipulação de coleções pode ser complexa, já que as coleções podem ser muito extensas e possuir objetos muito grandes, para isso o principal mecanismo usado são os objetos interadores, que é um objeto temporário que possui referências aos membros da coleção, com os objetos interadores métodos foram criados para produzir o próximo elemento da coleção (lista) ou buscar o enésimo elemento da coleção (arranjo) (RICARTE, 1998).

32 Associações Em um sistema de gerenciamento de banco de dados orientado a objetos a criação de relacionamentos não precisa seguir exatamente o modelo conceitual definido para a futura aplicação, logo se pode tomar diversos modos de criação dependendo do tipo de relação estabelecida. Por exemplo, um relacionamento um-para-muitos, pode ser representado por imediação física, por indexação, por ligação ou através de objetos intermediários criados pelo sistema gerenciados de base de objeto. Um tipo de relação implícita em um sistema gerenciador de base de objeto é a relação que se faz pela ordenação, apesar de tal conceito de ordenação, mesmo sendo muito usado em aplicações, não estar presente na maioria dos sistemas gerenciadores de base de objetos, onde apenas coleções do tipo conjunto são suportadas. A integridade referencial é outro fator importante nas associações em sistemas gerenciadores de base de objeto, que é mantida, mas usualmente com o uso de pares de atributos inversos. Então se o objeto α tem relação com um objeto β, e esse é referenciado pelo objeto α, o sistema gerenciador de base de objetos cria internamente a referência entre os objetos (α β). O sistema gerenciador ainda pode criar um contador de referencias para o objeto, só permitindo sua remoção quando o valor desse contador for nulo (RICARTE, 1998). 2.7 Bancos de Dados Relacionais Os Bancos de dados relacionais surgiram por volta da década de 70. Porém, só alguns anos mais tarde as empresas passaram a utilizá-los. Antes do surgimento do SGBDR eram utilizados modelos de dados hierárquicos. Os Bancos de Dados Relacionais foram desenvolvidos para facilitar o acesso aos dados, possibilitando utilizar uma grande multiplicidade no tratamento das informações (TAKAI, 2005).

33 Conceitos Básicos SGBDR A arquitetura de um banco de dado relacional utiliza-se aspectos de tabelas, linhas, colunas, chaves primárias, chaves estrangeiras, registros, índices, regras de integridades. Em um banco de dados podem existir inúmeras tabelas, sendo que o limite pode ser imposto pelos recursos de software ou de hardware utilizado. Os dados são representados como tabelas, que são formadas por linhas e colunas. As Colunas possuem apenas valores atômicos. As linhas contêm um mesmo conjunto de colunas. São por meio das chaves que as tabelas se relacionam, existem dois tipos de chaves a primária e a estrangeira. Chaves Primárias são colunas que possuem valores para identificar exclusivamente cada linha que contem uma relação. Chaves Estrangeiras referencia valores de outra coluna. Registros Cada linha formada por uma lista ordenada de colunas, representa um registro. Os registros podem assumir valores nulos quando necessário. Índices são tabelas secundárias criadas pelo SGBDR para armazenar informação de ordenação dos registros na tabela principal. No entanto o índice pode afetar também no desempenho, caso exista muitos índices ou índices com muitas redundâncias, causa lentidão durante as transações de inclusão, alteração e remoção de registros. Há duas formas de integridade a integridade de identidade e a integridade referencial. A integridade identidade: jamais o valor da chave primária poderá ser nulo. A integridade referencial: Uma tabela poderá possui uma chave estrangeira que é chave primaria em outra tabela com o mesmo valor ou esse valor poderá se nulo apenas para indicar uma relação entre as tabelas. Esse conceito de dados organizados em tabelas para a estruturação dos dados contribui para o sucesso de sistemas relacionais de dados (TAKAI, 2005).

34 Aspecto armazenamento SGBDR Materialização: restaurar um objeto a partir do banco de dados; Atualização: enviar modificações sobre um objeto para o banco de dados; Remoção: remover um objeto do armazenamento que já estava persistente na base. Esses são aspectos relacionados a funcionalidades que implementam o transporte de objetos da memória principal alocada para o SGBD (TAKAI, 2005) As principais vantagens SGBD Consultas rápidas: pelo fato dos dados estarem integrados, as resposta das consultas podem ser mais rápidas. Acessos Múltiplos a base de dados: os dados podem ser visualizados em diversos tipos de consultas diferentes, podendo obter varias informações em apena uma consulta. Flexibilidade: Uma alteração pode não implicar em uma total modificação no sistema. Integridade da informação: A obrigatoriedade de não permitir a redundância entre os dados facilitam as modificações dos dados (TAKAI, 2005).

35 23 3. DEFINIÇÃO E CONCRETIZAÇÃO DA BASE DE ESTUDOS 3.1 Sistemas Gerenciadores de Banco de Dados Escolhidos Para Estudo Para realizar o estudo de analise de desempenho e carga de stress em banco de dados orientado a objetos, foram escolhidos os dois SGBD s mais conceituados no mercado, o sistema que é o objeto de nosso estudo o InterSystems Caché um banco de dados robusto orientado a objeto, e o Oracle 10g Express Edition um dos bancos de dados relacionais mais usados atualmente, que servirá como base de comparação na analise de desempenho e carga de stress Oracle 10g Express Edition Oracle é uma SGBD (sistema de gerenciador de banco de dados) uma ferramenta para gestão de bases de dados. Para seu funcionamento ele utiliza a tecnologia cliente e servidor, sendo necessário instalar a ferramenta servidor, para acessar a base de dados de uma máquina. Para fazer o acesso à base de dados da maquina utiliza a ferramentas de desenvolvimento como Oracle designer e Oracle Developer que são ferramentas básicas da programação Oracle. O acesso a base de dados é através do SQL Plus, que estar nos programas Oracle que é utilizado para realizar consultas através da linguagem SQL. A ferramenta Developer é utilizada para criar, compilar e executar documentos. A vantagem dessa ferramenta é a disposição de compor um formulário em diversos visuais, como em Visual Base ou em Visual C, porém, a desvantagem é que para compartilhar o formulário é necessário criar uma cópia para uma pasta compartilhada para que todos que estão trabalhando na aplicação possam visualizar, e então sempre que tiver uma alteração será preciso copiar a pasta novamente para poder disponibilizá-la atualizada, isso causa bastante

36 24 complicação e dificuldade fora que existe um grande risco de perder pastas atualizadas. Já a ferramenta designer, conecta a base de dados atendendo a aplicação que tem todos os formulários e não causa problemas de versões diferentes e nem perca em outros trabalhos, porém, a desvantagem é que falta visual para compor o formulário. Esse é basicamente o funcionamento do Oracle database (SERSON, 2006) Oracle 10g Oracle Database possui algumas versões, a primeira que é o Oracle 7 e depois outras como Oracle 8, Oracle 8i, Oracle 9i, Oracle 10g e Oracle 11g; essas são as versões Oracle Database existente no mercado, entre tanto esse trabalho citara somente a versão Oracle 10g que será utilizada ao longo do desenvolvimento desse trabalho, já que atualmente é a versão mais atuante no mercado como pode ser visto na figura 3.0. Figura Gráfico Comparativo com as versões Oracle mais utilizadas no mundo. Fonte: SIQUEIRA, 2009 O Banco de dados Oracle XE (versão gratuita) disponibiliza o desenvolvimento de aplicativos em varias plataformas e dar suporte em diversos ambiente de desenvolvimento. E possui um ótimo desempenho mesmo sendo uma versão gratuita não deixa a desejar em nenhum momento em segurança, desempenho e compatibilidade com outros produtos da Oracle facilitando a evolução do aplicativo. O que significa sem sombra de duvida que Oracle 10g é

37 25 uma versão muito funcional que suporta o desenvolvimento e implementação de aplicativos, porém possui algumas limitações (SERSON, 2006) Limitações do Oracle 10g Express Edition Essas limitações são a fins de deixar a versão mais simples de manipular sendo mais fácil de estalar e de administrar. As limitações são memórias de apenas 1GB de RAM, apenas um banco de dados que poderá se executado em determinado computador, um limite de 4 GB no disco e o processador com baixa escalabilidade (SERSON, 2006) Características do Oracle 10g Express Edition O Oracle 10g Express Edition contem os recursos de Backup para a recuperação, restauração e replicação de dados; segurança de conexão e de contas; compatibilidade com ferramentas de terceiros, como ferramentas gráficas, monitoramento e desenvolvimento de consultas; possui ferramenta Oracle SQL Developer e os conceitos de bancos de dados distribuídos, entre outros (SERSON, 2006) Desvantagem do Oracle 10g Express Edition As desvantagens do Oracle 10g Express Edition são baixa memória, baixa quantidade de gerenciamento e processamento. Em relação a outras versões pagas. Há também algumas desvantagens em relação às ferramentas de gerenciamento e replicação do disco (SERSON, 2006).

38 Utilização do Oracle 10g Express Edition Oracle 10g Express Edition pode ser usado para a produção, teste ou desenvolvimento de um aplicativo, atendendo muito bem de acordo com a necessidade da empresa. Apesar das suas limitações, ele é capaz de atender essas necessidades, devido a inúmeras funcionalidades como integração, escalabilidade, redução de custo, portabilidade, ótima administração e ótima distribuição (SERSON, 2006) Banco de Dados Orientado a Objetos do Estudo O banco de dados orientado a objetos do estudo (Caché) é considerado banco de dados pósrelacional que integra um banco de dados robusto orientado a objetos, sistema de desenvolvimento de alto desempenho em SQL, além de e um rico acesso multidimensional. Banco de dados pós-relacional: É a nomenclatura criada pela InterSystems, para se referir à forma multidimensional de como os dados podem ser modelados e acessados pelo desenvolvedor. Então, isso significa que embora os dados sejam armazenados internamente na forma de matriz multidimensional, o banco de dados orientado a objetos permite a modelagem de dados da forma que o desenvolvedor achar mais adequada, ou seja, ele pode modelar as informações como se fosse um objeto, como uma tabela, ou como uma matriz multidimensional. Os dados são descritos apenas uma vez, em um único dicionário de dados integrado, e são imediatamente disponíveis para todos os métodos de acesso. Sendo assim, mesmo o desenvolvedor optando em modelar os dados no formato de objetos, por exemplo, ele pode acessar essas informações na forma de tabelas, e vice-versa (INTERSYSTEMS, 2010).

39 27 A arquitetura do banco de dados orientado a objetos do estudo permite também, o desenvolvimento de aplicações web de maneira simples e com extraordinária velocidade no processamento de transações, escalabilidade máxima, e consultas em tempo-real. O banco de dados trabalha com os conceitos de orientação a objetos aplicados e conhecidos em todas as linguagens de programação que seguem esse paradigma, conceitos tais como herança, polimorfismo, encapsulamento e associação entre classes. Além de trabalhar com a abordagem relacional, que facilita sua aceitação no mercado. O Caché possui também uma estrutura de armazenamento conhecida como Globais que é capaz de armazenar todos os tipos de dados, incluindo streams binárias e imagens gráficas. Essa definição de nome como Global indica que todos os usuários podem acessar estes tipos de dados, e esses tipos de dados não são muito comuns em bancos de dados relacionais. Além disso, o banco de dados orientado a objetos do estudo possui o um recurso que outros bancos de dados OO estudados não possuíam, que o recurso de conexão JDBC (Java Database Connectivity) com ilustra a figura 3.1 (INTERSYSTEMS, 2010). Figua Exemplo de conexão JDBC no Caché. Fonte: INTERSYSTEMS, 2010

40 Modelagem de Dados Já que o banco de dados é estruturado no paradigma de orientação a objetos, ele pode oferecer o recurso de modelagem de dados por objetos também, que é uma grande vantagem quando se quer desenvolver aplicações complexas de maneira mais rápida, e depois também modificálas com mais facilidade, além de que os objetos suportam uma estrutura de dados mais ampla, e assim podendo descrever os dados de forma mais natural, condizendo com o que é visto no mundo real. O modelo de objeto do banco de dados orientado a objetos do estudo é baseado no padrão ODMG (Object Database Management Group) e suporta diversas características importantes, como a herança múltipla, por exemplo. Naturalmente, muitas ferramentas (tais como geradores de relatórios) usam SQL, e não tecnologia de objetos, para acesso aos dados. Para isso, o banco de dados orientado a objetos possui uma característica particular: sempre que for definida uma classe de objetos do banco de dados, o banco de dados orientado a objetos do estudo fornece automaticamente total acesso SQL a estes dados, sem trabalho adicional. Desta forma, as ferramentas baseadas em SQL trabalham perfeitamente com dados do banco de dados orientado a objetos. Quando se utiliza uma definição DDL de um banco de dados relacional, banco de dados orientado a objetos gera automaticamente uma descrição de objeto dos dados, habilitando assim seu imediato acesso como objetos, bem como por SQL. A arquitetura de dados unificada do banco de dados orientado a objetos mantém estes caminhos de acesso sincronizados (INTERSYSTEMS, 2010).

41 Modelo de Classes Para entender melhor os conceitos de um modelo de classe, fica mais fácil exemplificar tal modelo, e para isso nada melhor do que um exemplo que retrate uma necessidade do mundo real, assim o diagrama da figura 3.2 apresenta um modelo simples de um sistema escolar, representando suas classes com atributos, serviços e relacionamentos. As classes Aluno, Professor e Curso representam os cadastros básicos. A classe Pessoa apresenta os atributos em comum de Alunos e Professores, incluindo seu Endereço. A classe Titulação representa o grau de escolaridade de um professor (Graduação, Especialização, Mestrado, Doutorado). E ainda, a classe Avaliação que registra as notas de Alunos em Cursos, e finalmente, os Alunos e Professores estão associados a Cursos. Figura Exemplo de Modelo de Classe Fonte: Fonte: ALMEIDA, 2005 Classes: Ao se implementar classes dentro do banco de dados orientado a objetos é importante entender como o sistema gerencia essas classes, primeiramente o banco tem que definir o agrupamento lógico das classes que é feito através das NameSpaces, que pode ser

42 30 conceituado como se fossem o ambiente de trabalho para o desenvolvedor, ou como já dito, como estruturas lógicas, onde são criados os projetos. Esses projetos podem conter como exemplo as páginas Web, as rotinas e os pacotes onde são armazenadas as classes. Quando se cria uma classe, esta deve ser associada obrigatoriamente a um pacote (novo ou já existente), que são responsáveis por armazenar as classes. Então, sempre que uma classe é referenciada, tem-se que mencionar o seu pacote. O banco de dados orientado a objetos do estudo oferece aos desenvolvedores vários tipos de ferramentas, com a finalidade de tornar mais fácil o desenvolvimento de sistemas, entre elas o Studio. Nele são criadas as classes com seus métodos, relacionamentos, índices, buscas, rotinas e páginas Web. Usando o Studio o desenvolvedor encontrará muito mais facilidade ao que se refere a criar classes, porém essa facilidade se torna inútil, caso o mesmo não conheça os Tipos de Classes que o banco de dados orientado a objetos trabalha que são: Classe Persistente: é capaz de armazenar seus objetos no banco; Classe Serial: é armazenada apenas quando embutida em outro objeto persistente. Uma classe serial faz parte de outra do tipo persistente, como a classe Endereço em relação à classe Pessoa. Desta forma, um Endereço somente é persistido quando uma Pessoa é persistida; Classe de Tipos de Dados: serve para definir novos tipos além daqueles já existentes como Integer e Number. Classe Abstrata: serve para definir propriedades e métodos comuns em várias outras classes; Classe Registrada: não pode armazenar objetos na base de dados; Classe Derivada: para servir de superclasse quando se trabalha com herança.

43 31 O banco de dados orientado a objetos do estudo ao final de um projeto pode armazenar todas as classes de um pacote, em formato XML, sendo possível a exportação e a importação do pacote com todas as classes ou parte delas. Associação entre Classes: A associação entre classes é representada pela ligação existente entre objetos, possibilitando a comunicação entre eles. No banco de dados orientado a objetos do estudo esta ligação pode ser feita de diversas maneiras: a) Referência Simples: esse tipo de referência ocorre quando um objeto de uma determinada classe aponta para um objeto de outra. Neste tipo de referência, por não haver a necessidade de se verificar a existência do objeto a todo o momento, nota-se um melhor desempenho em relação às demais associações, porém nesse tipo de referência não existe integridade referencial, mas também há outro fator relevante, que é a diminuição do acoplamento, já que não possui a propriedade inversa da classe referenciada. Na figura 3.3, o objeto da classe professor simplesmente aponta para a sua titulação. Figura Exemplo de Referência Simples Fonte: ALMEIDA, 2005 b) Relacionamento: São dois os tipos de relacionamento adotados no banco de dados orientado a objetos do estudo, que são One to Many e Parent Children. No relacionamento One to Many (um para vários), nesse tipo de relacionamento a integridade referencial é mantida, onde vários objetos de uma classe apontam para um objeto de outra classe, e é claro, não se pode apagar um objeto de uma classe que tenha um objeto de outra apontando para ele. A Figura 3.4 exemplifica este tipo de relacionamento (ALMEIDA, 2005).

44 32 Figura Relacionamento One to Many Fonte: ALMEIDA, c) No relacionamento Parent Children (pai para filho), um objeto pai pode possuir vários filhos e, quando o pai é excluído, todos os filhos também o são (esse tipo de relacionamento segue o conceito de agregação em UML.), garantindo assim a integridade referencial entre os objetos. Na Figura 3.5, este relacionamento pode ser observado entre as classes de Aluno e Avaliação. Este Figura Relacionamento Parent Children Fonte: ALMEIDA, 2005 d) Composição: Segue como o próprio nome diz o conceito de composição em UML, que é feita através da ligação entre uma classe persistente e uma classe serial. Na figura 3.6 pode ser observada a presença da composição entre as classes Pessoa e Endereço. A classe Endereço é persistida juntamente com a classe Pessoa. Figura Composição Fonte: ALMEIDA, 2005

45 33 Para o banco de dados orientado a objetos do estudo, os relacionamentos do tipo 1:1 (um pra um) e N:N (vários pra vários) são interpretados como relacionamento do tipo 1:N (um pra vários) já o relacionamento 1:1 (um pra um) pode ser substituído por um relacionamento One to Many, usando um método de validação que garanta a existência de um único objeto nesta associação. Relacionamentos N:N, podem ser mapeados através de dois relacionamentos One to Many. e) Herança no Caché: No Caché, a herança pode ser implementada de forma que uma classe herde atributos e métodos de alguma superclasse existente no modelo. Este conceito está exemplificado na figura 3.7, onde a classe Aluno herda os atributos Nome e Telefone da classe Pessoa. Figura Herança. Fonte: ALMEIDA, 2005 Alguns métodos bem conhecidos da orientação a objetos também são aplicados no banco de dados orientado a objeto escolhido, como: a) Encapsulamento: O encapsulamento impede a visualização interna do objeto por métodos de outros objetos, assim protegendo seus dados. No banco de dados orientado a objetos os métodos de acesso get e set estão implícitos dentro das propriedades criadas nas classes Caché, então não há a necessidade do desenvolvedor criar estes métodos, mas o uso destes métodos de acesso é perfeitamente aceitável, sendo possível ao desenvolvedor sobrescrevê-los para realizar algum tipo de processamento

46 34 b) Polimorfismo: Com o polimorfismo, pode-se utilizar o identificador de serviço para métodos que são executados de forma diferente em classes diferentes. Quem decide qual método executar é o objeto que recebe a chamada (ALMEIDA, 2005). c) Multiplicidade: é o que define em uma modelagem orientada a objetos o número de instâncias de uma classe relacionada com uma instância de outra classe. Então, para todas as associações entre classes, exceto a herança, haverá uma multiplicidade em cada uma das direções das classes. Multiplicidade pode ser considerada um subconjunto, possivelmente infinito de inteiros não negativos. A figura 3.8 mostra alguns exemplos de multiplicidade (FIGUEIREDO, 2005). Figura 3.8 Tabela de Multiplicidade. Multiplicidade Significado 0..1 zero ou um zero ou um 1 Somente 1 Somente * ou 0...n Maior ou igual a zero * ou n Maior ou igual a zero 1...* ou 1...n Maior ou igual a Intervalo de 1 a , Intervalo de 1 até 5 ou 10 até 18 Fonte: FIGUEIREDO, Tecnologia de Objetos x Tecnologia Relacional Na tecnologia de objetos, a complexidade dos dados está contida dentro do objeto, e os dados são acessados por uma interface consistente. Em contraste com a tecnologia relacional, que por não gerir a complexidade do mundo real de dados, os dados estão dispersos entre várias tabelas e os usuários ou os programadores acabam sendo responsáveis por lidar com essa constante complexidade.

47 35 Como os objetos se pode modelar dados complexos de forma simples, a programação orientada a objetos é a melhor escolha para programação de aplicações complexas. Da mesma forma, para o acesso a objetos do banco de dados que também é a melhor opção, sendo aplicada nas funções de inserir e atualizar o banco de dados (ou seja, para processamento de transações). O banco de dados orientado a objetos complementa o acesso a objetos com uma linguagem de objeto estendida de consulta SQL. No entanto, o SQL é mais adequado para efeito de consultas e relatórios em vez de processamento de transações (para o qual é complexo e muitas vezes ineficiente) (INTERSYSTEMS, 2010) Panorama do Modelo OO Conceitualmente, um objeto é um pacote que inclui os valores do objeto de dados (propriedades) e uma cópia de todo o seu código (métodos). Para reduzir o armazenamento é comum que os objetos da mesma classe compartilhem a mesma cópia do código (por exemplo, não seria realista que para cada nota fiscal um objeto tenha sua própria cópia privada de código). Além disso, o método chamado normalmente resulta em uma função eficiente solicita, ao invés de suportar a sobrecarga de passar mensagens. No entanto, estas técnicas de implementação são ocultas ao programador, que sempre precisa pensar em termos de objetos de transmissão de mensagens. Qual é a diferença entre um objeto e uma classe? Uma classe é a estrutura e definição de código fornecido pelo programador. Ele inclui uma descrição da natureza dos dados (seu tipo) e como ele é armazenado, bem como todo o código, mas não contém quaisquer dados. Um objeto é uma instância particular de uma classe. Por exemplo, fatura é um objeto da classe Invoice. Um exemplo simples de um objeto está representado na figura 3.9.

48 36 Figura Exemplo de Objeto Fonte: INTERSYSTEMS, 2010 Tecnologia de Objetos também promove uma visão natural dos dados por não se limitar a simples propriedades. Os objetos podem conter outros objetos, ou referências a outros objetos, o que torna mais fácil a construção de modelos úteis e dados significativos (INTERSYSTEMS, 2010) NameSpaces Ao desenvolver algum sistema no banco de dados orientado a objetos, se deve antes associar este desenvolvimento a um determinado Namespace. Quando o Caché é instalado, ele cria alguns Namespaces, conforme demonstra a figura 3.10.

49 37 No banco de dados orientado a objetos os Namespaces são como ambientes de trabalho e são neles que estão contidas as classes (tabelas), rotinas e dados que são compiladas pelo sistema. (ALMEIDA, 2005). Figura Tabela de Namespaces NameSpace Descrição USER SAMPLES %SYS NameSpace utilizado para se criar aplicações de teste e exemplos. NameSpace que possui uma série de classes utilizadas nos exemplo que acompanham o Caché. NameSpace utilizado pelo Caché para diversas tarefas internas do sistema. Fonte: ALMEIDA, Ferramentas, Paradigma e Padrão de Projeto Para o desenvolvimento do estudo foi de fundamental importância a definição das ferramentas e o paradigma de programação que mais se adequasse ao estudo, além de um padrão de projeto de software que garantisse um desenvolvimento ágil e seguisse os padrões qualidade de software. E assim foi definida a linguagem de programação usada para a criação do aplicativo do estudo de caso, a ferramenta de modelagem UML (Unified Modeling Language), e a ferramenta de modelagem de dados relacionais, além é claro do software que executará os testes de carga no banco de dados.

50 Apache JMeter O Apache JMeter é uma aplicação desenvolvida na linguagem de programação Java e foi criada para executar teste de carga de aplicações, como as aplicações do tipo Cliente/Servidor, por exemplo. Essa ferramenta foi originalmente projetada para realizar testes em aplicações web, mas, logo foi expandida para fazer outros tipos de testes, tais como o teste que será realizado nesse estudo, que é o teste em servidores de banco de dados via JDBC, além desse tipo de teste o JMeter executa também teste de carga em servidores de FTP, JNDI, LDAP e Web Services. Com o Apache JMeter, é possível assegurar se um sistema gerenciador de banco de dados está habilitado para suportar uma determinada quantidade de usuários simultâneos e estudar o seu comportamento no que se refere à escalabilidade. Neste contexto, entende-se por escalabilidade a capacidade de resposta do sistema em relação à demanda de recursos exigidos dele. Aumentar a escalabilidade de um sistema de banco de dados é o mesmo que expandir sua capacidade de processamento e armazenamento de registros, seja melhorando a capacidade do hardware ou otimizando o uso dos recursos do sistema. O Apache JMeter é uma ferramenta de código aberto distribuído sobre a licença ASF(Apache Software Foundation) e seu download pode ser feito diretamente no site da Apache (CARATTI, 2006).

51 Estudo de Caso: Hospital e Maternidade Marieta Konder Bornhausen Figura Estudo de Caso Hospital e Maternidade Marieta Konder Bornhausen Fonte: INTERSYSTEMS 2010 Visando complementar o estudo de desempenho, criou-se a necessidade de se abordar um Case que incorporasse possíveis requisitos de alto desempenho e colocasse os sistemas de gerenciadores de banco de dados estudados atuando com uma carga alta de stress, além de demonstrar como é o desenvolvimento de um software projetado para atuar em conjunto com um banco de dados orientado a objetos. Porém, o estudo de caso não apresentava em seu conteúdo a especificação exata dos seus requisitos, modelagem do sistema e modelagem de dados, que então foram desenvolvidas como parte do estudo nas sessões a seguir Requisitos do Sistema Requisitos Funcionais: a) Requisito1- Cadastrar os pacientes: o sistema deve cadastrar os dados pessoais do paciente constando o seu nome, CPF, RG, telefone, endereço, CEP, bairro, cidade, estado.

52 40 b) Requisito2- Cadastra Atendimento ao paciente: o sistema deve cadastra detalhadamente o atendimento do paciente constando informações do tipo de consulta, o tipo de medicamento receitado, tipo de exame e o tipo de tratamento do paciente quando necessário, hora da internação, data de entrada, data de saída, se tem acompanhante, nome do convenio. c) Requisito3- Cadastrar os Médicos: o sistema deve cadastrar os dados pessoais do médico, constando seu nome, CRM, CPF, RG, telefone, endereço, bairro, especialidades, quantidade de paciente que ele atende e qual convênio atende. d) Requisito4- Cadastrar os Funcionários: o sistema deve cadastrar os dados pessoais do funcionário constando o seu nome, CPF, RG, telefone, endereço, CEP, bairro, cidade, estado, cargo, departamento, carga horária, valor pago por horas trabalhadas, salário mensal. e) Requisito5- Agendar consulta, o sistema deve fornecer a possibilidade de registrar o agendamento de consulta solicitada pelo paciente, constando o horário, a data, o medico, o nome do paciente. f) Requisito6- Cadastrar convênio: o sistema deve cadastra as informações do convenio constando o nome do convênio, CNPJ, registro. g) Requisito7- Gerenciar o estoque de remédios: o sistema deve ser capaz de gerenciar a quantidades de remédios presente no estoque, a descrição do remédio, prazo de validade e também deve constar o nome do remédio e as doses que o medicamento possui. h) Requisito8- Gerenciar o estoque de produtos: o sistema deve ser capaz de gerenciar a quantidade de produto, a descrição, o prazo de validade e constar nome de cada produto. i) Requisito 9- Inserir: o sistema tem que ser capaz de gravar informações numéricas e textuais dos usuários (médicos, funcionários e pacientes).

53 41 j) Rquisito10- Armazenar: o sistema tem que ser capaz de armazenar permanentemente essas informações. k) Requisito11- Buscar: o sistema tem que ser capaz de buscar informações. l) Requisito12- Alterar: o sistema tem que ser capaz de alterar informações. m) Requisito13- Remover: o sistema tem que ser capaz de remover informações. n) Requisito14- Gerar Relatório: o sistema tem que ser capaz de gerar um relatório das informações consultadas. o) Requisito15- Confirmar e cancelar opções: o sistema deve dar as alternativas para o usuário confirmar ou cancelar uma escolha. p) Requisito16- O sistema deve ser capaz de conceder as seguintes opções para os usuários do sistema: validar, voltar, continuar e confirmar as informações quando for realizado um cadastramento no sistema. Requisitos Não-Funcionais: a) Usabilidade: O software deve apresentar uma interface amigável para o usuário. b) Desempenho: O sistema deve ter o melhor desempenho possível.

54 Diagrama de Caso de Uso Figura Digrama de caso de uso hospital e maternidade Marieta Konder Bornhausen Diagramas de Classe Com as funcionalidades do sistema definidas no levantamento de requisitos, e claramente expressas no diagrama de Caso de Uso como ilustrou a figura 3.12 anteriormente, já é possível iniciar a definição das classes que farão parte do sistema, representando sua estrutura e como se relacionam.

55 43 a) A figura 3.13 representa a classe Agendamento, que está estruturada como POJO (Plain Old Java Objects) com a representação de todos seus atributos além dos métodos get e set, e seguindo o padrão de projeto MVC. Temos a classe de controle ControleAge, a classe de visão VisãoAge, e também a classe que contém a lógica de negócio a classe DaoAge. Figura Diagrama de Classe (Agendamento) b) A figura 3.14 seguinte representa o Atendimento, que também segue o padrão MVC, com a classe DaoAte com a lógica de negócio, a classe ControleAte como controle e a classe VisãoAte como Visão, Além da Classe Atendimento definida como POJO.

56 44 Figura Diagrama de Classe (Atendimento) c) A figura 3.15 a seguir representa o convênio, que também segue o padrão MVC, com a classe DaoCon com a lógica de negócio, a classe ControleCon como controle e a classe VisãoCon como Visão, Além da Classe Convênio definida como POJO. Figura Diagrama de Classe (Convênio)

57 45 d) A figura 3.16 a seguir representa o Funcionario, que também segue o padrão MVC, com a classe DaoFun com a lógica de negócio, a classe ControleFun como controle e a classe VisãoFun como Visão, Além da Classe Funcionario definida como POJO. Neste esquema está presente também a classe Pessoa definida como super-classe, que pode ser herdada e também a Classe Endereço que compõe a classe Pessoa. Figura Diagrama de Classe (Funcionario) e) A figura 3.17 a seguir representa o Medico, que também segue o padrão MVC, com a classe DaoMed com a lógica de negócio, a classe ControleMed como controle e a classe VisãoMed como Visão, Além da Classe Medico definida como POJO. Neste esquema está presente também a classe Pessoa definida como super-classe, que pode ser herdada e também a Classe Endereço que compõe a classe Pessoa.

58 46 Figura Diagrama de Classe (Medico) f) A figura 3.18 a seguir representa o Paciente, que também segue o padrão MVC, com a classe DaoPac com a lógica de negócio, a classe ControlePac como controle e a classe VisãoPac como Visão, Além da Classe Paciente definida como POJO. Neste esquema está presente também a classe Pessoa definida como super-classe, que pode ser herdada e também a Classe Endereço que compõe a classe Pessoa. Figura Diagrama de Classe (Paciente)

59 47 g) A figura 3.19 abaixo representa Produto, que também segue o padrão MVC, com a classe DaoPro com a lógica de negócio, a classe ControlePro como controle e a classe VisãoPro como Visão, Além da Classe Produto definida como POJO. Figura Diagrama de Classe (Produto) h) O diagrama 3.20 a seguir representa Remedio, que também segue o padrão MVC, com a classe DaoRem com a lógica de negócio, a classe ControleRem como controle e a classe VisãoRem como Visão, Além da Classe Remedio definida como POJO. Figura Diagrama de Classe (Remedio)

60 Modelo Conceitual Figura Modelo Conceitual Hospital e Maternidade Marieta Konder Bornhausen Modelo Lógico Modelo Lógico Hospital e Maternidade Marieta Konder Bornhausen

61 Modelagem para Banco de Dados OO Nessa etapa, o estudo se volta à modelagem de dados que será aplicada ao banco de dados orientado a objetos (Intersystems Caché), tal modelagem segue o padrão de diagramas UML (Unified Modeling Language), de tal modo que não é necessária outra ferramenta específica para modelagem OO, já que qualquer ferramenta CASE de desenvolvimento de modelos UML é capaz de suprir todas as necessidades de um modelo de dados orientado a objetos. E assim, como ilustra a figura 3.23, foi concebido o modelo de dados do estudo de caso, Hospital e Maternidade Marieta Konder Bornhausen. Figura Modelo de Dados OO.

62 50 O modelo de dados do estudo de caso utilizou-se em cada etapa de sua criação de conceitos clássicos da orientação a objeto no relacionamento entre suas classes, como pode ser notado: a) Classe Endereço e Pessoa: Nessa relação foi aplicado o conceito de composição, já que um endereço compõe a classe pessoa, ou seja, um endereço somente existirá se uma pessoa existir, como ilustra a figura 3.24, tendo multiplicidade de um endereço para uma ou mais pessoas (1 1..*). Figura Composição (Classe Endereço e Pessoa) b) Classe Pessoa, Paciente, Funcionário e Médico: Aqui a relação observada entre as classes é a de herança, a classe Pessoa é a classe pai, que delega as suas classes filhas (Medico, Paciente e Funcionário) seus atributos como nome e CPF, além dos atributos da classe Endereço como ilustra a figura 3.25, assim, quando for necessária a inserção de dados em classes com herança, somente a classe filha será instanciada possuindo todos os atributos da classe pai e composições e agregações se existirem. Figura Herança (Classe Pessoa, Paciente, Funcionário e Medico)

63 51 c) Classe, Paciente, Médico, Funcionário, Convenio e Agendamento: A Classe Paciente, Médico, Funcionário e Convenio estão relacionadas com a mesma multiplicidade (1 0..*) com a Classe Agendamento, onde por exemplo, um medico está relacionado a nenhum ou a vários agendamentos como ilustra a figura 3.26 a seguir: Figura Relacionamento Classe Paciente, Medico, Funcionário, Convenio e Agendamento d) Classe Atendimento e Agendamento: A Classe Atendimento possui um relacionamento diferente as demais classes relacionadas com Agendamento, já que apesar da mesma multiplicidade (1 0..*), é a classe Atendimento que possui varias ocorrências de um atendimento, como ilustra a figura 3.27 a seguir: Figura Relacionamento Classe Agendamento e Atendimento

64 52 e) Classe Remédio e Produto: Essas Classes não têm relacionamento com as demais classes, já que cada uma possui uma função especifica e única, que é a persistência de dados referentes a estoque de remédios para a Classe Remédio e estoque de produtos hospitalares em geral para a Classe Produto, as Classes Produto e Remédio estão ilustras na figura Figura Classe Remédio e Produto Portanto, fica evidente que a transição do modelo de dados relacional para o modelo de dados orientado a objetos é possível, como também ficou clara a diferença de complexidade estrutural que ambos os modelos apresentaram. Enquanto o modelo relacional apresenta em sua estrutura, artifícios complexos para a abstração das entidades de forma a representar da maneira mais fiel o que condiz às necessidades do mundo real, enquanto que o modelo de dados orientado a objeto devido a sua natureza e concepção oriunda de abstrações mais realistas, que em fato se adéquam facilmente as necessidades do mundo real, como é o conceito de herança, por exemplo, acaba apresentando uma estrutura mais abrangente de recursos, possibilitando assim modelagens mais rápidas e também a criação de estruturas diagramais mais enxutas e fáceis de entender.

65 Criação do Banco de Dados OO Com o modelo de dados orientado a objetos definido, se inicia então a etapa de construção do banco com suas respectivas classes usando a ferramenta Studio para criação, e o Portal de Administração do Sistema para o gerenciamento das Classes Definição das Classes As figuras a seguir ilustram como o SGBD Caché, define as classes em seu sistema. Figura Definição da Classe Agendamento

66 Figura Definição da Classe Atendimento 54

67 Figura Definição da Classe Convênio 55

68 Figura Definição da Classe Endereço 56

69 Figura Definição da Classe Funcionário 57

70 Figura Definição da Classe Medico 58

71 Figura Definição da Classe Paciente 59

72 Figura Definição da Classe Pessoa 60

73 Figura Definição da Classe Produto 61

74 Figura Definição da Classe Remédio 62

75 63 4 ANÁLISE DE DESEMPENHO E CARGA DE STRESS Nessa fase do estudo iniciam-se os testes de carga de stress nos SGBD s com o auxílio do Apache JMeter, que será usado em sua versão mais recente, a versão 2.4, possibilitando assim a coleta efetiva dos dados, e também torna possível a aplicação de conceitos matemáticos e estatísticos para obtenção de resultados mais abrangentes e conclusivos, que serão detalhados em seguida. 4.1 Elaborando Plano de Teste com JMeter Um plano de teste consiste em um conjunto de passos que serão executados com objetivo de simular o uso do sistema e coletar métricas dessa execução. Mas antes de se começar um plano de teste deve-se previamente adicionar na pasta correta os JARs necessários para a realização da conexão JDBC (Java Database Connectivity) com ambos os bancos estudados. Portanto, foram adicionados na pasta (...\jakarta-jmeter-2.4\lib) do JMeter os seguintes JARs: a) CacheBD.jar : Fornece o drive de conexão com banco de dados Caché (com.intersys.jdbc.cachedriver) via conexão JDBC; b) ojdbc_14.jar: Este JAR fornece o drive da Oracle de conexão JDBC (oracle.jdbc.oracledriver). Com os drives de conexão devidamente alocados, segue-se a próxima etapa, a etapa de adição e definição de um Grupo de Usuários (Thread Group). Como ilustra a figura 4.1.

76 64 Na etapa de criação de um Grupo de Usuários é onde se torna possível informar a quantidade de usuários que você deseja simular e o comportamento desse usuário quanto suas requisições ao SGBD. Figura Adicionando Grupo de Usuários (Thread Group) Fonte: CARATTI, 2006 Em seqüência deve se definir os parâmetros desse grupo de usuários, tais como numero de usuários virtuais (threads) e o tempo de inicialização, como demonstra a figura 4.2. Figura 4.2- Thread Group Fonte: CARATTI, 2006

77 65 Para a definição correta de um Thread Group, se faz necessário o entendimento melhor de cada parâmetro. Portanto segue na figura 4.3, uma descrição mais detalhada de cada parâmetro de configuração do mesmo. Figura Tabela de parâmetros de um Thread Group. Parâmetro Descrição Nome Ação a ser Tomada após Erro no Testador Número de Usuários Virtuais Tempo de Inicialização (seg) Contador de Interação Agendador Nome do Thread Group Indica qual procedimento será executado em caso de erro durante uma requisição de teste, que são: - Continuar O erro será ignorado e novas requisições serão disparadas. - Interromper Usuário Virtual Interrompe somente a Thread que disparou a requisição, as demais Threads continuarão. - Interromper Teste Todo o teste será finalizado. Cada Thread é considerada como um usuário que executará as requisições SQL, então o número de usuários será a quantidade de testes executados. Define quantos segundos o JMeter tem para por todas as Threads em execução. Diz ao JMeter o número de vezes que o Thread Group irá executar, caso a opção infinito seja marcada o Thread Group será executado infinitamente. Permite agendar um horário de inicio e fim de uma execução de teste. Fonte: CARATTI, 2006 Logo após a criação de um Grupo de Usuários, será necessária a definição do tipo de teste que esse Thread Group executará, o JMeter possui vários tipos de testadores que podem ser adicionados ao Thread Group, como por exemplo uma requisição HTTP ou Java, mas nesse caso será usada uma Requisição JDBC, como mostra figura 4.4, que fará a conexão com Oracle e o Caché.

78 66 Figura Adicionando uma Requisição JDBC Fonte: CARATTI, 2006 Para que o teste com JMeter funcione adequadamente deve-se também respeitar a hierarquia dos objetos criados, como mostra a figura 4.5, que mostra esse tipo hierarquia, com um Thread Group (pai) e uma Requisição JDBC (filha). Tendo isso em vista, basta então iniciar a configuração dos elementos de uma Requisição JDBC, como ilustra também a figura 4.5. Figura Requisição JDBC Fonte: CARATTI, 2006

79 67 No elemento de requisição JDBC, é onde será determinada a consulta SQL de teste com o banco de dados, podendo ser do tipo Select Statement (uma SQL de seleção) ou ainda um Update Statement (uma SQL de atualização), entre outras opções. A figura 4.6 define melhor os parâmetros de uma requisição JDBC. Figura Tabela de parâmetros de uma requisição JDBC Parâmetro Descrição Nome Nome da Variável Tipo da Consulta Consulta Nome da requisição Define o nome de uma variável que será associada a um pool de conexões. Informa o tipo de consulta a ser realizada (Update, Select, etc.) Onde é escrito todo o comando da consulta SQL. Fonte: CARATTI, 2006 Em seguida, um Elemento de Configuração deve ser adicionado à requisição JDBC como mostra a figura 4.7, o elemento necessário para nosso estudo é a Configuração de Conexão JDBC. Figura Adicionando um Elemento de Configuração de Conexão JDBC Fonte: CARATTI, 2006.

80 68 No elemento de configuração de conexão JDBC que serão definidos alguns parâmetros essenciais para que a cada requisição SQL seja executada no banco de dados testado, como a URL de conexão com o banco e o DRIVER de conexão especifico daquele SGBD. A figura 4.8 ilustra tais parâmetros. Figura Parâmetros de Conexão com Banco de Dados Fonte: CARATTI, 2006 Abaixo a Figura # descreve melhor cada parâmetro de configuração de conexão JDBC Figura Tabela de parâmetros de uma conexão JDBC Parâmetro Descrição Nome Nome da Variável Limite de Conexões Timeout do Grupo de Conexões Validação da Conexão pelo Grupo de Conexões Nome dado a conexão, é possível criar varias conexões em um único teste Nome da variável relacionada ao pool de conexão, é possível usar vários pools de conexão, cada um ligado por uma variável. Numero Maximo de conexões admitidas em um pool Tempo Maximo que uma conexão deverá ser estabelecida, caso ultrapasse esse limite uma exceção será lançada. Uma consulta usada par validar uma conexão

81 69 Intervalo de Limpeza de Conexões Ociosas Tempo determinado para o encerramento de um usuário ocioso. URL do Banco String de conexão com o banco de dados Classe do Drive JDBC Nome completo da classe do driver JDBC está implementado. Nome de Usuário Nome de usuário criado para conexão com o banco Senha Senha definida para conexão com o banco Fonte: CARATTI, 2006 Com todas as definições anteriores estabelecidas, já é possível disparar contra o banco de dados as requisições configuradas, porém de nada adiantaria essa execução sem antes ter algum componente que possa coletar os resultados, para isso o JMeter oferece vários tipos de relatório e gráficos (Ouvintes) para analise de teste. Para adicionar qualquer tipo de relatório ou gráfico no JMeter é bastante simples como ilustra a figura 4.10 abaixo. Figura Adicionando um Relatório Fonte: CARATTI, 2006

82 70 No relatório que são obtidas as medidas necessárias para validar o estudo como o descrito abaixo na figura 4.11 (CARATTI, 2006). Figura Tabela de medidas do obtidas em um relatório Medida Descrição Média Mínimo Maximo Vazão Carga Valor médio de todas as Amostras em ms. Menor tempo de resposta em ms Maior tempo de resposta em ms Número de requisições atendidas por segundo Quantidade em KB transferidos por segundo Fonte: CARATTI, Resultados e Análise Com o ambiente de configuração e testes previamente elaborado, basta agora definir o ambiente de estudo, escolhendo os parâmetros mais adequados para estudo de caso (Hospital e Maternidade Marieta Konder Bornhausen). Para isso foi definido que apenas uma tabela de toda a modelagem do estudo de caso seria escolhida para os testes (tabela referente a estoque de remédios), tabela essa idêntica tanto no banco de dados relacional quanto no orientado a objetos, assim foi feito para que não se houvesse nenhuma discrepância entre o tamanho de dados, número de colunas e o tipo de atributos nas tabelas. Então, com a tabela de análise já definida passa-se agora a etapa de acepção numérica do ambiente de estudo, definindo o número de usuários por segundo que acessaram ambos os bancos de dados, e a quantidade de registros que a tabela de estoque de remédios possuirá.

83 71 Portanto, foi definido: O computador onde serão feitos os testes: CPU: Intel(R) Pentium(R) 4 ( 3.00 GHz ); Memória RAM: 512 MB; Sistema Operacional: Microsoft Windows XP Professional Service Pack 3. a) A tabela de estoque de remédios será persistida com 1000 (mil) registros, o desempenho da persistência também será analisado para ambos os bancos; b) As transações serão feitas por número de usuários por segundo; c) Serão realizados três testes de busca à tabela de estoque de remédios, onde o número de usuários máximo será de 500 usuários por segundo; d) As escalas definidas para os três testes de buscas serão de 5, 50 e 500 usuários por segundo; e) Os dados coletados serão medidas de média, mínimo, máximo, vazão e carga, além da coleta dos tempos de resposta de cada usuário, que será dado em milissegundos. Então, foram obtidos os seguintes resultados: Persistência de mil remédios (mil threads) na tabela de estoque de remédios em ambos os bancos de dados (um thread por segundo): Em transações com muitos usuários como é o caso da persistência da tabela de remédios onde temos mil usuários, a redução de conflitos entre processos concorrentes é crítica para se conseguir alto desempenho, já que um dos maiores conflitos ocorre entre transações que desejam acessar os mesmos dados simultaneamente. As transações do banco de dados orientado a objetos não trava páginas de dados inteiras enquanto faz atualizações. Em vez disto, como as transações requerem acessos freqüentes ou mudanças de pequenas quantidades de dados, o travamento do banco de dados orientado a objetos é feito a nível lógico.

84 Tempo de Resposta (ms) 72 Travamento de páginas em bancos de dados é utilizado para controlar vários acessos na mesma informação ao mesmo tempo. Os registros ficam bloqueados para não serem alterados ou visualizados por outros processos. Isso ocorre por causa da gravação, porque se um dado estiver sendo alterado, é conveniente esperar a finalização dessa gravação, para quando as informações forem recuperadas estejam totalmente atualizadas. Esse tipo de travamento em bancos relacionais deixa as transações mais lentas, devido a essa espera, em quanto ocorre às atualizações. O que não é o caso do orientado a objeto; Pelo fato dele fazer atualizações em níveis lógicos, não ocorre espera, e por isso as transações são realizadas de formas mais rápidas. Com o banco de dados orientado a objetos, as transações individuais ocorrem mais rapidamente, e mais transações podem rodar concorrentemente, havendo assim menos oscilações no tempo de resposta se comparadas ao banco de dados relacional, como pode ser observado na figura Perseistência 1 Thread/Segundo Amostra (400 Usuários) Relacional Orientado a Objetos Número de Threads (Usuários) Figura Medida da amostra de quatrocentos usuários na análise de persistência de dados

85 Tempo de Resposta (ms) Tempo de Resposta (ms) 73 O melhor desempenho obtido devido ao recurso de não travamento de páginas de dados do banco de dados orientado a objetos fica mais evidente nas medidas do valor máximo e mínimo de tempo resposta com ilustra a figura 4.13 e 4.14, em que ambas as medidas o banco de dados orientado a objetos obteve tempos de respostas mais baixos em relação ao relacional que não possui esse mecanismo por padrão Máximo Relacional 10 0 Relacional Orientado a Objetos Orientado a Objetos Figura Medida do valor máximo obtido na persistência Mínimo 2,5 2 1, ,5 1 Relacional Orientado a Objetos 0 Relacional Orientado a Objetos Figura Medida do valor mínimo obtido na persistência E também, como pode ser notado na figura 4.15, o banco de dados orientado a objetos teve em média melhores resultados, levando em consideração todos os tempos de resposta dos mil usuários.

86 Tempo de Resposta (ms) Relacional Média 3 Orientado a Objetos Relacional Orientado a Objetos Figura Medida do valor médio obtido na persistência Busca com cinco threads por segundo a tabela de remédios, com mil registros, aproximadamente 56KB em ambos os bancos de dados. Na análise de busca de dados, o banco de dados orientado a objetos além de usar o mecanismo que possibilita menor concorrência entre os usuários (não travamento de paginas de dados), apresenta uma forma de armazenamento de dados que apenas um banco de dados orientado a objetos pode ter que é o armazenamento multidimensional que é uma estrutura de dados que pode armazenar valores em mais de uma dimensão. Por construção do banco de dados orientado a objeto os arrays de multidimensionais não tem tipo, não requerem nenhuma declaração, definição e alocação de armazenamento. E arrays multidimensionais comuns de duas dimensões precisam de dois índices para acessar cada uma das posições dos dados. Logo nota-se que o banco de dados orientado a objeto aperfeiçoou a utilização de arrays multidimensionais e obteve um mecanismo mais eficiente para a sua utilização. Que aumenta consideravelmente o desempenho na recuperação de dados gravados em disco se comparado com o banco de dados relacional, como pode ser observado na figura 4.16 abaixo.

87 Tempo de Resposta (ms) Tempo de Resposta (ms) 75 Busca 5 Threads/Segundo Relacional Orientado a Objetos Número de Threads (Usuários) Figura Análise de Busca Cinco Usuários por Segundo Esse desempenho mais rápido do banco de dados orientado a objeto. É possível somente por que ele grava em suas namespaces esses arquivos chamados globais (arrays multidimensionais), que gravam os objetos com técnicas de armazenamento distribuídas em varias dimensões em vez de tabelas bidimensionais e, com isso, o acesso aos dados e as atualizações são realizadas com menos I/O de disco, que acaba aumentado o desempenho do banco de dado orientado a objetos. Tendo isso em vista, a média dos tempos de resposta para cinco usuários por segundo dos bancos de dados, somente vêem a comprovar essa diferença de desempenho, como mostra a figura Média Relacional Orientado a Objetos 0 Relacional Orientado a Objetos Figura Média dos tempos de resposta para cinco usuários por segundo

88 Tempo de Resposta (ms) Tempo de Resposta (ms) 76 O banco de dados relacional apresentou uma diferença de desempenho inferior ao banco de dados orientado a objetos de aproximadamente 27% no tempo de resposta das requisições para cinco usuários por segundo. Mínimo Relacional Orientado a Objetos 0 Relacional Orientado a Objetos Figura Medida do valor mínimo obtido na busca com cinco usuários Quanto à medida referente às requisições que tiveram menor tempo de resposta entre todas as amostras, ou seja, o valor mínimo obtidos por ambos os bancos, o banco de dados orientado a objetos na análise com cinco usuários por segundo obteve um valor melhor como visto na figura Já no que se refere às requisições que tiveram o maior tempo de resposta entre todas as amostras, o valor máximo, o banco de dados orientado a objeto também obteve um valor melhor, como mostra a figura 4.19: 5000 Máximo Relacional Orientado a Objetos 0 Relacional Orientado a Objetos Figura Medida do valor máximo obtido na busca com cinco usuários

89 KB Usuários 77 Uma medida importante também analisada ao que se refere a desempenho é o numero de usuários atendidos por segundo pelos bancos de dados, a vazão, essa medida comprova com exatidão como o mecanismo que trata a concorrência no banco de dados orientado a objetos leva vantagem sobre o banco de dados relacional, sendo capaz de atender aproximadamente 0,2 usuários por segundo a mais que o banco de dados relacional, como demonstra a figura Vazão 1,4000 1,2000 1,0000 0,8000 0,6000 0,4000 0,2000 0,0000 1,0124 1,2309 Relacional Orientado a Objetos Relacional Orientado a Objetos Figura Valor de vazão das requisições atendidas por segundo com cinco usuários Outra medida importante é a análise de carga que o banco de dados pode suportar, ou seja, essa analise mede a quantidade de dados em KB por segundo que um banco de dados consegue transferir durante o teste, e como pode ser observado na figura 4.21, o banco de dados relacional foi capaz de transferir aproximadamente 18% a mais de dados que o banco de dados relacional. Carga 80, , , , , , , ,0000 0, , ,3605 Relacional Orientado a Objetos Relacional Orientado a Objetos Figura Quantidade de carga em KB transferidos por segundo com cinco usuários

90 Tempo de Resposta (ms) Tempo de Resposta (ms) 78 Busca com cinquenta threads por segundo a tabela de remédios em ambos os bancos de dados. Busca 50 Threads/Segundo Relacional Orientado a Objetos Número de Threads (Usuários) Figura Análise de Busca Cinquenta Usuários por Segundo A figura 4.22 representa o gráfico de 50 usuários, que também obteve o melhor desempenho porque seu tempo de resposta foi menor, devido ao seu mecanismo de busca que já foi citado anteriormente. Média Relacional Orientado a Objetos Relacional Orientado a Objetos Figura Média dos tempos de resposta para cinquenta usuários por segundo

91 Tempo de Resposta (ms) Tempo de Resposta (ms) 79 Figura 4.23 mostra a média do tempo que os bancos levaram para responder as buscas, fica claro, analisando o gráfico, é que o banco de dados orientado a objeto obteve uma média menor que o relacional, o que comprova que o banco de dados orientado a objeto levou menos tempo para concluir cada busca, devido ao seu mecanismo de busca. Nesse caso de busca com 50 usuários por segundo o orientado a objeto apresentou uma diferença de melhor desempenho de aproximadamente 18% em comparação ao banco de dados relacional Mínimo Relacional 6832 Orientado a Objetos Relacional Orientado a Objetos Figura Medida do valor mínimo obtido na busca com cinquenta usuários Figura 4.24 mostra o tempo mínimo que os bancos levaram para responder as buscas. O que comprova que o orientado a objeto consegue realizar mais buscas no tempo mais curto que o relacional Relacional Máximo Orientado a Objetos Relacional Orientado a Objetos Figura Medida do valor máximo obtido na busca com cinquenta usuários

92 KB Usuários 80 Figura 4.25 mostra o maior tempo que os bancos levam para responder as buscas. O que comprova que o relacional leva mais tempo para responder do que orientado a objeto. 1,2500 Vazão 1,2000 1,2265 1,1500 1,1000 1,0500 1,0000 1,0452 Relacional Orientado a Objetos 0,9500 Relacional Orientado a Objetos Figura Número de vazão das requisições atendidas por segundo com cinquenta usuários Figura 4.26 mostra o numero de requisições que os bancos conseguem atender por segundo, é possível observar que o orientado a objeto consegue atender mais requisições por segundo do que o relacional. O orientado a objeto possui 17% a mais de vazão para o atendimento das requisições. Carga 68, , , , , , , , , ,2411 Relacional Orientado a Objetos 52,0000 Relacional Orientado a Objetos Figura 4.27 Quantidade de carga em KB transferidos por segundo com cinquenta usuários

93 Tempo de Resposta (ms) 81 Figura 4.27 mostra a quantidade em KB de transferência que os bancos conseguem realizar por segundo; o orientado a objeto consegue realizar 17% mais transferência por segundo do que o relacional. Em uma busca com 50 usuários por segundo. Busca com quinhentos threads por segundo a tabela de remédios em ambos os bancos de dados. Busca 500 Threads/Segundo Relacional Orientado a Objetos Número de Usuários Figura 4.28 Análise de Busca com Quinhentos Usuários por Segundo A figura 4.28 representa o gráfico de 500 usuários. Sendo a ultima análise proposta realizada dos testes de desempenho de buscas nos respectivos bancos escolhidos para estudo. Com 500 usuários por segundo o Banco de dados orientado a objeto também obteve o melhor desempenho tendo o tempo de resposta mais rápido do que o Relacional.

94 Tempo de Resposta (ms) Tempo de Resposta (ms) 82 Média Relacional Orientado a Objetos Relacional Orientado a Objetos Figura 4.29 Média dos tempos de resposta para quinhentos usuários por segundo Figura 4.29 mostra a média do tempo que os bancos levaram para responder as buscas com quinhentos usuários por segundo. O orientado a objeto possui uma média de 9% de desempenho melhor que o relacional Mínimo Relacional Orientado a Objetos 7000 Relacional Orientado a Objetos Figura Medida do valor mínimo obtido na busca com quinhentos usuários Figura 4.30 mostra o tempo mínimo que os bancos levaram para responder as buscas. O orientado a objeto usa menos tempo para responde uma requisição do que o relacional em uma busca com 500 usuários por segundo.

95 Usuários Tempo de Resposta (ms) Relacional Máximo Orientado a Objetos Relacional Orientado a Objetos Figura Medida do valor máximo obtido na busca com quinhentos usuários Figura 4.31 mostra o maior tempo que os bancos levam para responder as buscas. O relacional usa mais tempo para responde uma requisição do que orientado a objeto em uma busca com 500 usuários por segundo. Vazão 1,2000 1,1500 1,1855 1,1000 1,0500 1,0000 1,0461 Relacional Orientado a Objetos 0,9500 Relacional Orientado a Objetos Figura Número de vazão das requisições atendidas por segundo, com quinhentos usuários Figura 4.32 mostra o número de requisições que os bancos conseguem atender por segundo, por meio do gráfico nota-se que o orientado a objeto consegue atender 12% mais requisições por segundo do que o relacional. Devido a essa vazão mais alta que o orientado a objeto possuiu.

96 KB 84 66,0000 Carga 64, , , , , , ,2903 Relacional Orientado a Objetos 54, ,0000. Relacional Orientado a Objetos Figura Quantidade de carga em KB transferidos por segundo com quinhentos usuários Figura 4.33 mostra a quantidade em KB de transferência que os bancos conseguem realizar por segundo; o orientado a objeto consegue realizar 14% mais transferência por segundo do que o relacional. O gráfico retrata que o orientado a objeto possui uma taxa de transferências maior do que o relacional, em uma busca com 500 usuários por segundo. Bem, esses foram os resultados obtidos com as buscas propostas para os testes. Obtiveram-se alguns resultados das comparações entre os bancos estudados, que podem até parecerem poucos, porém, a cargo de desempenho eles são bastante relevantes, principalmente em casos de sistemas muito robustos e complexos.

97 85 5 CONSIDERAÇÕES FINAIS Este capítulo tem como objetivo apresentar de forma sólida as argumentações finais do trabalho, relatando as conclusões alcançadas durante todo o estudo, além das contribuições que este trabalho pode trazer para o mundo acadêmico e para o setor de tecnologia da informação. O capitulo também tem como objetivo descrever os possíveis caminhos que este estudo poderá tomar após essa etapa, ou seja, quais serão os trabalhos desenvolvidos futuramente baseados neste estudo. Então, o capítulo será estruturado da seguinte maneira: Contribuições e Conclusões: Esta sessão descreverá a as conclusões e contribuições do trabalho; Trabalhos Futuros: Nesta sessão serão definidos os possíveis trabalhos futuros que este trabalho dará base.

98 Contribuições e Conclusões As contribuições deste Trabalho são: a) A definição das classes para o banco de dados orientado a objeto; b) A modelagem de dados do padrão de banco de dados relacional e modelagem de dados do padrão banco de dados orientado a objetos; c) A modelagem de um sistema com banco de dados; d) Análises de carga para busca com até quinhentos usuários por segundo em ambos os bancos, com medidas de vazão e carga; e) Análises de desempenho com vários usuários em uma inserção e busca de dados em ambos os bancos, com medidas de media, mínimo e máximo; f) Um estudo de caso baseado no padrão orientado a objetos; g) Uma análise conceitual do padrão de banco de dados orientado a objeto; h) Uma análise técnica do mecanismo de concorrência e armazenamento do padrão de banco de dados orientado a objetos em relação ao padrão relacional; i) Uma coleta de todas as amostras de busca e inserção;

99 87 A partir dessas contribuições pode-se concluir que: a) As definições de classes constatam que existe igualdade dos conceitos tanto para o banco de dados e quanto para a linguagem orientada a objetos; b) Com modelagem de dados idêntica para ambos os padrões, foi possível concluir que, existe maior facilidade de abstração do padrão orientado a objetos devido aos recursos que tal oferece como a herança, além de apresentar uma modelagem mais reduzida; c) Com um projeto de sistema em linguagem de programação orientada a objeto constatou-se que pode ser mais complexo a implementação do sistema em um banco de dados relacional; d) O banco de dados orientado a objetos nesse contexto de testes obteve desempenho melhor em todos os testes de inserção e busca dos dados, comprovando-se de forma pratica o melhor desempenho desse banco. e) Enquanto a análise de carga em buscas, o padrão orientado a objetos conseguiu atender de maneira mais eficiente a demanda em todos os testes efetuados. f) Com um estudo de caso que apresenta uma história de sucesso de um sistema desenvolvido com banco de dados orientado a objetos, conclui-se que é possível implementar sistemas a nível empresarial da mesma forma que o padrão relacional; g) O padrão de banco de dados orientado a objetos apresenta conceitos que visam facilitar o desenvolvimento de sistemas com banco de dados, em conjunto com linguagens de programação que seguem o mesmo paradigma, evitando problemas como o impedance mismatch entre o banco e a linguagem orientada a objeto; h) O padrão de banco de dados orientado a objetos dentro desses testes que foram propostos possui mecanismos em sua arquitetura e configuração padrão que levam vantagens técnicas em termo de desempenho.

100 88 i) Coletando todas as amostras de todos os testes tanto os de buscas como o de inserção e apresentando graficamente os resultados de ambos os bancos, que ao decorrer da maior parte das transações o padrão orientado a objetos obteve melhores tempos de resposta em relação ao padrão relacional. 5.2 Trabalhos Futuros Para trabalhos futuros serão propostos novos testes de otimização com o banco de dados orientado a objetos e relacional, tais como: a) Testes de mecanismos específicos que cada um dos bancos utiliza para tratar, buscas complexas envolvendo várias tabelas em uma única consulta; b) Os tipos indexação que cada um possui; c) Serão analisados como os respectivos bancos tratam buscas complexas que evolvem muito processamento de hardware, que precisam unir várias tabelas para poder responder a informação requerida. Esse serão os trabalhos futuros, analisar um grau de busca mais exato e obter comprovações de quais mecanismos utilizados pelos os bancos são mais eficazes e mais rápidos para atender os tipos de requisições submetidos a eles.

101 ANEXOS 89

102 90