Curso de Engenharia de Computação

Transcrição

1 Curso de Engenharia de Computação COMPARAÇÃO ENTRE BANCO DE DADOS RELACIONAIS E BANCO DE DADOS ORIENTADO A OBJETOS: CARACTERÍSTICAS E IMPLEMENTAÇÃO DE UM PROTÓTIPO David Rodrigues Machado Itatiba São Paulo Brasil Dezembro de 2009

2 ii Curso de Engenharia de Computação COMPARAÇÃO ENTRE BANCO DE DADOS RELACIONAIS E BANCO DE DADOS ORIENTADO A OBJETOS: CARACTERÍSTICAS E IMPLEMENTAÇÃO DE UM PROTÓTIPO David Rodrigues Machado Monografia apresentada à disciplina de Trabalho de Conclusão de Curso II, do curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Ms. José Aparecido Carrilho, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Ms. José Aparecido Carrilho Itatiba São Paulo Brasil Dezembro de 2009

3 iii Comparação entre Banco de Dados Relacionais e Banco de Dados Orientado a Objetos: Características e Implementação de um Protótipo David Rodrigues Machado Monografia defendida e aprovada em 07 de dezembro de 2009 pela Banca Examinadora assim constituída: Prof. Ms. José Aparecido Carrilho (Orientador) USF Universidade São Francisco Itatiba SP. Prof Ms. Cláudio Maximiliano Zaina (Membro Interno) USF Universidade São Francisco Itatiba SP. Prof. Ms. Debora Meyhofer Ferreira (Membro Interno) USF Universidade São Francisco Itatiba SP. O registro de arguição e defesa consta de ATA DE ARGUIÇÃO FINAL DE MONOGRAFIA, devidamente assinada e arquivada na coordenação do curso.

4 iv Saber ler e escrever não é o fim da educação, sequer o início. Mahatma Gandhi In: ATTENBOROUGH, RICHARD. A Sabedoria de Gandhi

5 A meus queridos pais, Maria Niva e José Maria, que não terminaram o primeiro grau, mas sempre me deram apoio. v

6 vi Agradecimentos Agradecimento especial ao Prof. José Aparecido Carrilho, que com sua experiência e ensinamentos durante a orientação, me indicou a direção da luz para que o trabalho fosse concluído. Ao Prof. Cláudio Maximiliano Zaina, pela supervisão durante a disciplina de Trabalho de Conclusão de Curso II, além de ter sido o professor de diversas disciplinas durante o meu curso de Engenharia de Computação. Ao Prof. Alencar de Melo Junior, pelas suas orientações iniciais durante a supervisão do Trabalho de Conclusão de Curso I. Aos meus colegas de sala, Leandro, Paulo, Rafael, Márcio, Gustavo e João Paulo, não só pela amizade, mas pela colaboração que me deram em relação às disciplinas durante estes cinco anos de curso. Ao Presidente da República Luiz Inácio Lula da Silva pela criação do programa Prouni, pois sem isso, provavelmente nunca teria cursado um curso superior. Agradeço a todas as pessoas que de alguma forma, contribuíram para que eu chegasse até aqui. Mesmo quando não tive confiança em mim mesmo de que conseguiria durante as dificuldades do curso. Isto inclui todo o corpo docente que lecionou para mim, os quais alguns deles não estão mais presentes na Universidade São Francisco.

7 vii Sumário Lista de Siglas... ix Lista de Figuras... x Lista de Tabelas... xi Resumo... xii Abstract... xiii 1 INTRODUÇÃO Objetivos Objetivos Específicos Organização do Trabalho ASPECTOS TEÓRICOS Banco de Dados Relacional Estrutura das Tabelas e seus Relacionamentos Chaves Linguagens de Consultas SQL Banco de Dados Orientado a Objetos Novas Aplicações de Banco de Dados Estrutura do Modelo de Objetos Herança Identidade de Objeto (OID) e Ponteiros Linguagens de Programação Persistente Vantagens e Desvantagens dos Modelos Relacional e Orientado a Objetos Vantagens do Modelo Relacional Desvantagens do Modelo Relacional Vantagens do Modelo de Objetos Desvantagens do Modelo de Objetos PROJETO DO PROTÓTIPO Modelagem do Banco de Dados Modelagem Relacional para o Protótipo... 19

8 viii Modelagem das Classes de Objetos para o Protótipo Modelagem das Tabelas para o Modelo Relacional Softwares utilizados no Projeto MySQL db4objects (db4o) Exemplo MySQL X db4o Exemplo MySQL Exemplo db4o O Protótipo TESTES Testes de Inserção Testes de Atualização Testes de Consulta Testes de Remoção Testes com Procedures SQL Análise dos Resultados CONCLUSÃO Contribuições Extensões Referências Bibliográficas Bibliografia Consultada Apêndice A Protótipo para Testes nos Bancos de Dados Apêndice B Resultados dos Testes nos Bancos de Dados... 84

9 ix Lista de Siglas AVE BD CAD CASE CRUD db4o GPL IDE NQ ODMG OID OIS OLAP ORM QBE RDBMS SODA SQL Alta Velocidade Espanhola Banco de Dados Computer-Aided Design Computer-Aided Software Engineering Create, Read, Update, Delete db4objects General Public License Integrated Development Environment Native Query Object Database Management Group 1. Object Identifier Office Information System On-line Analytical Processing Object-Relational Mapping Query by Example Relational Database Management System Simple Object Data Access Structured Query Language

10 x Lista de Figuras Figura 1 Exemplo de um Modelo Relacional em um sistema bancário... 2 Figura 2 Exemplo de um Modelo Orientado a Objetos em um sistema bancário... 2 Figura 3 Exemplo de especialização em hierarquia em um modelo de Escola de Informática Figura 4 Casos de uso para o protótipo de um sistema de Escola de Informática Figura 5 Modelo Relacional para o protótipo de um sistema de Escola de Informática Figura 6 Modelo Orientado a Objetos para o protótipo de um sistema de Escola de Informática Figura 7 Modelagem das Tabelas do Modelo Relacional Figura 8 - Representação da arquitetura de um servidor Mysql Figura 9 - Armazenamento de objetos em um B.D Relacional e em um B.D db4o Figura 10 Diagrama das telas do protótipo para Escola de Informática Figura 11 Gráfico do teste de inserção nos bancos de dados para 4500 registros Figura 12 Gráfico do teste de atualização nos bancos de dados para 4500 registros Figura 13 Gráfico do teste de consulta nos bancos de dados para 4500 registros Figura 14 Gráfico do teste de remoção nos bancos de dados para 4500 registros Figura 15 Gráfico do teste de inserção entre procedures SQL e Banco de Dados Relacional usando Java Figura 16 Gráfico do teste de atualização entre procedures SQL e Banco de Dados Relacional usando Java Figura 17 Gráfico do teste de consulta entre procedures SQL e Banco de Dados Relacional usando Java Figura 18 Gráfico do teste de remoção entre procedures SQL e Banco de Dados Relacional usando Java

11 xi Lista de Tabelas Tabela 1 Tabela de dados referentes a Pessoas Tabela 2 Tabela de dados referentes a Funcionários... 6 Tabela 3 Resultado da projeção Tabela 4 Resultado da restrição Tabela 5 - Tabela resultante da junção entre a tabela Funcionários sobre Pessoas Tabela 6 Exemplo de especialização de classes com herança para uma Escola de Informática Tabela 7 - Detalhes do benchmark open source PolePosition gerado para comparar o db4o 24 Tabela 8 Resumo dos resultados nos testes efetuados para 4500 registros

12 xii MACHADO, David Rodrigues. Comparação entre Banco de Dados Relacionais e Banco de Dados Orientado a Objetos: Características e Implementação de um Protótipo p. Monografia (Bacharelado em Engenharia de Computação) Curso de Engenharia de Computação da Universidade São Francisco, Campus de Itatiba. Resumo A busca de um modelo ideal para Banco de Dados é constante. Entre esse modelos estão o Banco de Dados Relacional e o Banco de Dados Orientado a Objetos. O Modelo de Dados Relacional é o conceito abstrato que define maneiras de armazenar, manipular e recuperar dados estruturados, unicamente na forma de coleções de tabelas, sendo elas simples estruturas com linhas e colunas. As tabelas se relacionam através de chaves que determinam que cada registro seja único. A linguagem de consulta predominante neste modelo é o SQL. O Modelo de Dados Orientado a Objetos é baseado no paradigma de programação orientada a objetos e propõe trabalhar com os dados utilizando dos mesmos conceitos de objetos: classes, polimorfismo, herança e encapsulamento. O Identificador de Objetos (OID) permite identificar unicamente um objeto, através de referências que se assemelham aos ponteiros. Para que o armazenamento dos dados seja efetivado, é necessária uma linguagem de programação que proveja persistência dos dados. Este projeto avalia os Modelos de Banco de Dados Relacional e de Objetos, comparando-os através de um protótipo de uma aplicação e de testes realizados, modelados para uma Escola de Informática. Fez-se uso na implementação da linguagem de programação Java e os Bancos de Dados Mysql (Relacional) e db4objects (Orientado a Objetos). PALAVRAS-CHAVE: Banco de Dados Relacional, Banco de Dados Orientado a Objetos, MySQL, db4objects.

13 xiii Abstract The search for an ideal model for the database is constant. Between these models are the Relational Database and the Database Object Oriented. The Relational Data Model is the abstract concept that defines ways to store, manipulate and retrieve structured data, only in the form of collections of tables, and they are simple structures with rows and columns. The tables are related by keys that determine that each record is unique. The query language predominant in this model is the SQL. The Data Model Object Oriented is based on the paradigm of object-oriented programming, and proposes to work with data using the same concepts of objects: classes, polymorphism, inheritance and encapsulation. The Object Identifier (OID) permits identify an object through references that are similar to pointers. For the storage of data be effective, you need a programming language that provides data persistence. This project evaluates the models Relational and the of Objects, comparing them through a prototype implementation and testing, modeled for a School of Informatics. The implementation was done using the Java programming language and the MySQL Database (Relational) and db4objects (Object Oriented). KEYWORDS: Relational Database, Object Oriented Database, MySQL, db4objects.

14 1 1 INTRODUÇÃO A quantidade de informação a ser persistida cresce bruscamente, ano após ano, com a necessidade de se armazenar cada vez mais dados em todos os tipos de aplicações. Desta maneira, buscam-se sempre formas mais eficientes, rápidas, seguras, estáveis, viáveis e, porque não, fáceis para o armazenamento de dados. Atualmente não se armazenam apenas caracteres e simples valores numéricos, mas uma infinidade de dados como vídeos, imagens, áudios, objetos complexos, etc. Além da utilização do Banco de Dados Relacional, outra forma de armazenamento que está ganhando espaço no mercado, ainda que tímida, é o Banco de Dados Orientado a Objetos. Mas fica a pergunta: será que os Bancos de Dados Orientado a Objetos são tão revolucionários como foi o paradigma orientado a objetos para as linguagens de programação?. Pensando nisso, veio então a motivação para este Trabalho de Conclusão do Curso, que tem como base a comparação do amplamente usado Banco de Dados Relacional, com o Banco de Dados Orientado a Objetos, busca-se assim comparar as diferenças, vantagens e desvantagens entre esses dois modelos. Modelo Relacional: O modelo relacional usa um conjunto de tabelas para representar os dados e as relações entre eles. Cada coluna de uma tabela possui um nome único. Uma linha do objeto representa um relacionamento entre um conjunto de valores. Esse conjunto de relacionamentos dentro de uma tabela faz com que exista uma curta correspondência entre o conceito de tabela e o conceito matemático de relação (que deu origem ao nome deste modelo de dados). Este foi um dos primeiros modelos de dados a se estabelecer em aplicações comerciais (Silberschatz et al., 1999). A Figura 1 mostra um exemplo de um modelo de Banco de Dados Relacional.

15 2 Figura 1 Exemplo de um Modelo Relacional em um sistema bancário. Modelo Orientado a Objetos: O modelo orientado a objetos trabalha com um conjunto de objetos. O objeto, por sua vez, possui valores armazenados em variáveis de instâncias, além de conter um conjunto de métodos que o manipulam. Os objetos que possuem os mesmos atributos e métodos são agrupados em classes que também podem ser definidas como um tipo. Essa definição faz com que seja similar ao tipo abstrato de uma linguagem de programação orientada a objetos. O modo que um objeto A acessa os dados de outro B é através do método de B (enviar mensagem). A interface de métodos de um objeto indica a sua parte externa visível. As variáveis de instâncias e o código dos métodos são a parte interna que não são visíveis externamente (Silberschatz et al., 1999). A Figura 2 mostra a representação do mesmo exemplo da Figura 1 em um Modelo Orientado a Objetos. Figura 2 Exemplo de um Modelo Orientado a Objetos em um sistema bancário.

16 3 São apresentados ao longo do trabalho o estudo, a comparação e a descrição das características do Banco de Dados Relacional e do Banco de Dados Orientado a Objetos, com o objetivo de avaliar os benefícios e pontos negativos de cada um. Para a avaliação destes modelos foi necessário desenvolver um protótipo de uma aplicação para realização de testes, visando avaliar as duas formas de armazenamento de dados e o desempenho de cada uma delas. 1.1 Objetivos O objetivo deste trabalho é avaliar as características de um Banco de Dados Relacional, comparando-as com um Banco de Dados Orientado a Objetos. Haverá apresentação das características, vantagens e desvantagens de cada um destes modelos e avaliação do desempenho para determinadas tarefas. Para fazer a avaliação foi necessário implementar um protótipo de uma aplicação para testar os Bancos de Dados. 1.2 Objetivos Específicos O foco deste trabalho é a análise das características do Banco de Dados Relacional e do Banco de Dados Orientado a Objetos e a comparação entre eles. Esta análise envolveu a implementação de um protótipo para uma Escola de Informática para testar os bancos, a fim de descrever suas vantagens e desvantagens. O intuito do projeto é avaliar se o modelo de Banco de Dados Orientado a Objetos é realmente vantajoso e em quais casos ele poderá obter melhor desempenho. A linguagem escolhida para o protótipo foi Java porque, além de ser uma linguagem orientada a objetos, é compatível com Banco de Dados Orientado a Objetos, permite trabalhar com dados persistentes e, ainda, é amplamente utilizada atualmente, além de ser gratuita e multiplataforma. O protótipo se conecta a um Banco de Dados Relacional, o MySQL, escolhido por ser gratuito e bastante usado. Essa aplicação também será integrada a um Banco de Dados Orientado a Objetos. São vários Bancos de Dados Orientado a Objetos existentes como, Jasmine, db4objects (db4o), O2, Object Store, etc. Foi escolhido o db4objects pois é de código aberto e flexível, usado com abrangência de 2% em alguns países e permite que sua

17 4 aplicação armazene e recupere dados com apenas uma linha de código, mesmo com complexas estruturas de objetos em sua aplicação (Guerra, 2007). 1.3 Organização do Trabalho Os conceitos teóricos são apresentados no capítulo 2, onde há uma descrição do Banco de Dados Relacional e do Orientado a Objetos, relatando também as vantagens e desvantagens observadas em cada modelo. No capítulo 3 são descritos a metodologia, modelagem e codificação empregadas para a implementação do protótipo para uma Escola de Informática, usando os Banco de Dados MySQL e db4objects (db4o). No capítulo 4, há uma descrição dos testes e dos resultados obtidos. No capitulo 5 são relatadas as conclusões obtidas neste projeto.

18 5 2 ASPECTOS TEÓRICOS Serão abordadas neste capítulo as características dos Modelos de Bancos de Dados Relacional e Orientado a Objetos, descrevendo as vantagens e desvantagens de cada modelo que são relevantes para realização do trabalho. 2.1 Banco de Dados Relacional Banco de Dados Relacional é o conceito abstrato que define maneiras de armazenar, manipular e recuperar dados estruturados unicamente na forma de uma coleção de tabelas, cada uma das quais possui um único nome, sendo elas simples estruturas com linhas e colunas. Ele foi um dos primeiros modelos de dados a se estabelecer em aplicações comerciais e, atualmente, é utilizado em numerosas aplicações no âmbito do processamento de dados tradicional, sendo o modelo mais amplamente usado (Silberschatz et al., 1999) Estrutura das Tabelas e seus Relacionamentos Considere a Tabela 1 sobre Pessoas que consiste em quatro colunas: Código, Nome, CPF, e Telefone. Essas colunas contêm os atributos das Pessoas. Para cada atributo existe uma coleção de valores permitidos, chamado de domínio do atributo. O atributo Nome, por exemplo, é o conjunto de todos os nomes de Pessoas. Suponha que Código, Nome, CPF e Telefone (v 1, v 2, v 3 e v 4 ) estejam no domínio D 1, D 2, D 3 e D 4 respectivamente, então a linha da tabela Pessoas que contém v 1, v 2, v 3 e v 4, será um subconjunto de (Silberschatz et al., 1999): D 1 x D 2 x D 3 x D 4 Matematicamente existe uma relação como um subconjunto de um produto cartesiano de um conjunto de domínios, semelhantes à definição de uma tabela. O que difere é que se designa nome aos atributos e matematicamente se usam nomes numéricos, utilizando o numero inteiro 1 para representar o atributo cujo o domínio aparece em primeiro lugar no conjunto de domínios e 2 para o atributo que tem o domínio que aparece em segundo e assim por diante. Como as tabelas usam o conceito matemático de relação, pode se usar os termos matemáticos relação e tupla (registros) no lugar de tabela e linhas (Silberschatz et al., 1999).

19 6 Na Tabela 1 existem três tuplas. Suponha que a tupla variável t se refere à primeira tupla da relação. Usamos a notação t[nome] = David Rodma t[cpf] = Uma alternativa seria escrever t[1] para os valores da tupla no primeiro atributo, t[2] para o segundo e assim por diante. Matematicamente t r para representar que a tupla t esta na relação r. Existe a possibilidade de um atributo possuir o mesmo domínio. Por exemplo, a relação Pessoas possui quatro atributos, Código, Nome, CPF e Telefone. A relação Funcionários possui o mesmo domínio, o conjunto formado pelos nomes de Pessoas. O valor nulo, que indica valor desconhecido ou inexistente, pertence a qualquer domínio possível. O Telefone na relação Pessoas pode possuir um valor nulo caso a pessoa não tenha telefone (Silberschatz et al., 1999). As manipulações das tabelas são feitas através de operadores, como, por exemplo, busca de dados. São os operadores de restrição, projeção ou junção que vão derivar as tabelas de outras tabelas. A operação de restrição, também conhecida como seleção, extrai linhas específicas de uma tabela. A operação de projeção extrai colunas específicas de uma tabela. Já a operação de junção une duas tabelas com base em valores comuns em uma coluna em comum (Date, 2000). Tabela 1 Tabela de dados referentes a Pessoas. PESSOAS Código Nome CPF Telefone David Rodma (11) Rubens Ewald Filho (11) Martin Scorsese (11) Tabela 2 Tabela de dados referentes a Funcionários FUNCIONÁRIOS Código Data_Admissão Quant_Horas_Trabalhada /02/ /04/ Restrição: Funcionários (Tabela 2) nos quais Quantidades de Horas Trabalhadas > 220 : Tabela 4 Resultado da restrição. Código Data_Admissão Quant_Horas_Trabalhada /04/ Projeção: Pessoas sobre o Código e CPF: Tabela 3 Resultado da projeção. Código CPF

20 7 No exemplo de junção (Tabela 5), a tabela Pessoas (Tabela 1) e Funcionários (Tabela 2) têm uma coluna Código em comum, de maneira que podem ser juntadas com base no código em comum entre essas colunas. Assim, produz as linhas cujos códigos entre elas sejam iguais. A saída obtida pela operação pode servir como entrada para outra tabela. Junção: Pessoas e Funcionários sobre Pessoas: Tabela 5 - Tabela resultante da junção entre a tabela Funcionários sobre Pessoas. Código Nome CPF Telefone Data_Admissão Quant_Horas_Trabalhada David Rodma (11) /02/ Rubens Ewald Filho (11) /04/ Em um modelo relacional as tabelas não são estruturas físicas e sim lógicas. Em relação ao nível físico, o sistema tem vários modos para armazenar os dados: arquivos seqüenciais, indexação, hashing, cadeia de ponteiros, compactação entre outras. Repare que não há nenhum ponteiro no nível lógico conectando uma tabela a outra, como no exemplo mostrado entre a linha que contem o Código da tabela Pessoas e a linha Código da tabela Funcionários, onde a conexão não é feita por ponteiro e sim pelo aparecimento do valor Código entre as duas tabelas. Podem existir ponteiros no nível físico, mas são ocultados do usuário (Date, 2000). Agregando as tabelas, restrições, projeções e junções, o modelo relacional é constituído dos componentes seguintes (Date, 2000): Tipos escalares (incluindo o tipo booleano); Gerador de tipo de relação: É uma interpretação pretendida para esse tipo de relação gerada; Variáveis de relações: Para as relações geradas que atribuem valores de relações as variáveis de relações. Exemplo: insert, update e delete; Operações relacionais: Para derivar valores de relações de outros valores de relações. No exemplo da Tabela 1 a relação Pessoas, de Código (tipo inteiro) 0010 chama-se Rubens Ewald Filho (tipo texto), possuindo o CPF de nº e Telefone (11) Esta proposição foi adquirida trocando Código (cabeçalho) pelo valor 0010 (corpo),

21 8 Nome por Rubens Ewald Filho e CPF por Chaves As tabelas se relacionam através de chaves. Uma chave é um conjunto de um ou mais atributos que determinam que cada registro seja único na tabela. A unicidade dos registros é determinada por sua chave, que é muito importante para a criação dos índices. Existem dois tipos de chaves. A chave primária nos permite distinguir as várias entidades de um conjunto identificando cada registro e garantindo a unicidade. Ela não pode se repetir. Um exemplo de chave primária seria o campo Código presente na Tabela 1 e Tabela 2. A chave estrangeira é formada através de um relacionamento com a chave primária de outra tabela. Define um relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso a chave primária seja composta na origem, a chave estrangeira também o será (Silberschatz et al., 1999). Para se determinar a chave primária para um esquema de relações deve se observar aspectos como conjuntos de entidades fracas, conjunto de relacionamento, tabelas combinadas e atributos multivalorados (Silberschatz et al., 1999) Linguagens de Consultas As informações dos Bancos de Dados são obtidas através de uma linguagem de consulta, que, normalmente, são de nível mais alto que as linguagens mais comuns. As linguagens de consultas são divididas em procedural e não-procedural. Na primeira, o usuário deve informar ao sistema a realização de uma sequência de operações para obter o resultado que se deseja. Já na segunda, o usuário descreve a informação que se deseja, sem fornecer um procedimento específico para obtê-la. Entre as linguagens puras, a álgebra relacional é procedural e o cálculo relacional de tupla ou domínio são não-procedurais (Silberschatz et al., 1999). Os sistemas de banco de dados comerciais incorporam tanto a linguagem procedural como a não-procedural. Entre as linguagens comerciais, a que mais se destaca é o SQL, o qual é usado pela maioria dos Bancos de Dados Relacionais.

22 Structure Query Language (SQL) Originalmente desenvolvida pela IBM, a princípio foi chamado de Sequel, essa linguagem foi implantada como parte de um projeto (Sistema R) no inicio da década de 70. A linguagem foi sendo aprimorada e teve seu nome alterado para SQL (Structure Query Language). O SQL tem representado o padrão para as linguagens dos Bancos de Dados Relacionais, devido em parte, à necessidade de uma linguagem de consulta mais fácil para o usuário. O SQL combina construtores em álgebra e cálculo relacional, e não é apenas uma linguagem de consulta como também possui recursos para definição de estruturas de dados para modificação de dados e especificações de restrições de segurança (Silberschatz et al., 1999). A estrutura básica do SQL é: Select A 1, A 2,..., A n From R 1, R 2,..., R m Where P Select: relaciona os atributos desejados no resultado de uma consulta. From: associa as relações que serão pesquisadas durante a evolução de uma expressão. Where: um predicado que envolve atributos da relação que aparece na cláusula From. Cada A i representa um atributo e cada R i, uma relação. P é um predicado. Os valores em SQL podem ser tratados de várias maneiras. Para isso inclui várias operações (rename, union, intersect, except), ordenação (order by), duplicidade, funções (avg, min, max, sum, count), subconjuntos aninhados (in, not in), verificação de relações vazias (exist, not exist), comparações de conjuntos (> some, <=some, =some, < > some, > all, < all etc), remoção (delete), inserção (insert), atualizações (update), tipos de domínios (char, integer etc) e definições de relação (create table, primary key etc) (Silberschatz et al., 1999). 2.2 Banco de Dados Orientado a Objetos Muitas aplicações são limitadas por restrições impostas ao Modelo Relacional (ou sistema de SQL de modo geral). O modelo Orientado a Objetos, baseado no paradigma de programação Orientada a Objetos, que surgiu primeiramente para a linguagem Simula 67, e mais tarde introduzida para Smalltalk, C++, Java, entre outras, vem como uma alternativa para reverter às limitações impostas ao Modelo Relacional (Silberschatz et al., 1999).

23 10 Como os Banco de Dados Orientados a Objetos são influenciados pelas Linguagens de Programação Orientada a Objetos, utiliza os conceitos de Objetos, Classes, Polimorfismo, Herança, Encapsulamento, descritos a seguir: Objeto: modelam entidades físicas ou abstratas do mundo real. Os objetos podem ser divido em persistentes - que são armazenados após a execução de uma aplicação, podendo ser recuperados e compartilhados e transientes - que persistem somente durante a execução do programa, não sendo muito útil para um Banco de Dados; Classes: Estrutura para conter em determinado modelo, os dados que devem ser representados e as operações que devem ser efetuadas com eles (Santos, 2003); Métodos: Operações contidas em uma classe (Santos, 2003); Polimorfismo: Permite manipulação de instâncias de classes que herdam de uma mesma classe ancestral de forma unificada (Santos, 2003); Herança: Reutilização de classes que permite usar uma classe pai como base, herdando todos os campos e métodos não privados da classe base (Santos, 2003); Encapsulamento: Capacidade de ocultar dados dentro de modelos, permitindo que somente operações especializadas ou dedicadas manipulem os dados ocultos (Santos, 2003) Novas Aplicações de Banco de Dados Os Bancos de Dados convencionais encontram certas dificuldades em relação a novas aplicações que surgiram no mercado. Entre essas novas aplicações estão os Banco de Dados Multimídia (imagens, vídeo-on-demand, dados geográfico e espaciais, áudio etc), Sistema de Informação de Escritório (OIS), Banco de Dados Hipertexto (como, por exemplo, World Wide Web, que é uma hipermídia), Projetos Auxiliados por Computador (CAD), Engenharia de Software Auxiliado por Computador (CASE), etc (Silberschatz et al., 1999). Com o aumento da capacidade e do menor custo do hardware (disco, processamento, memória, banda larga), e, a melhoria do gerenciamento de Banco de Dados, as novas aplicações que não foram previstas no passado encontram dificuldades para serem modeladas no Banco de Dados Relacional (Silberschatz et al., 1999). Além disso, as novas aplicações estão se tornando mais complexas de se expressar. Por exemplo, um sistema da Secretária de Segurança Pública, precisa tratar, constantemente, imagens, impressões digitais e assinaturas. O Modelo Orientado a Objetos pode tornar-se uma alternativa aos problemas encontrados no Modelo Relacional.

24 Estrutura do Modelo de Objetos Um objeto se assemelha a uma entidade no Modelo Relacional. O paradigma de objeto trabalha com o encapsulamento de dados que representam um objeto em uma única unidade, com um conjunto de variáveis que contém dados de objetos, semelhantes aos atributos no Modelo Relacional. A comunicação entre o sistema é realizada através de mensagens (chamadas de métodos), que são as solicitações que ocorrem entre os objetos ou execução de um método solicitado. Os métodos são uma parte do código que executam a mensagem e retornam um valor. Esta abordagem de métodos pode ser motivada, como por exemplo, em uma empresa que tem funcionários com cargos diferentes, em que a maneira de se calcular o salário é diversificada, pois você pode ter funcionários recebendo por hora, salário fixo, bônus de vendas, etc. Essa forma de executar métodos diferentes é chamada de polimorfismo. O método polimórfico seria encapsulado no código para calcular o salário dos funcionários que obteria em resposta a mensagem calcular_salario. O encapsulamento faz com que se acessem somente os métodos necessários para sua execução, já que as respostas são feitas através de mensagens que modificam os métodos e variáveis, sem alterar o resto do sistema (Silberschatz et al., 1999). Outra característica do Modelo de Objetos é a presença de classes de objetos, que são objetos similares presentes em um Banco de Dados. Isto inclui as variáveis de mesmo nome, tipo e métodos, que respondem a mesma mensagem. Os objetos que formam a classe são chamados de instância de sua classe. O conceito de classes em um Modelo Orientado a Objetos assemelha-se a um conjunto de entidades num Modelo Relacional (Silberschatz et al., 1999) Herança Um Banco de Dados de Objetos geralmente é composto de várias classes, muitas vezes similares. Essas classes podem ser herdadas pelas subclasses ( classes filhas ), das superclasses ( classes pais ), podendo então, as subclasses reaproveitarem parte do código, como os atributos e métodos. Um exemplo de herança seria ter uma classe Pessoas e a outra classe Funcionários para representar uma Escola de Informática. Ambas possuem variáveis similares para Nome, Endereço, CPF, etc, em que, hierarquicamente, a classe Funcionários poderia herdar de Pessoas. Desta maneira, como a classe Funcionários herda as variáveis da classe Pessoas,

25 12 seria necessário somente a implementação das variáveis específicas a classe Funcionários, como salário, data de admissão, entre outras. Esta hierarquia se assemelha a especialização (ISA) no modelo relacional (Silberschatz et al., 1999). As especializações são chamadas de subclasses, portando, Funcionários são uma subclasse de Pessoas e inversamente Pessoas é uma superclasse de Funcionários como mostra a Figura 3. PESSOAS ALUNOS FUNCIONÁRIOS PESSOAL ADMINISTRATIVO PROFESSORES Figura 3 Exemplo de especialização em hierarquia em um modelo de Escola de Informática. Na Tabela 6 é apresentado o exemplo de implementação de classes com herança, no qual o protótipo do projeto se baseia: Tabela 6 Exemplo de especialização de classes com herança para uma Escola de Informática. Class Pessoas{ int cod; String nome; String rg; String cpf; String sexo; date data_nasc; String tipo; String endereco; String bairro; String cidade; String uf; String cep; String telefone; String celular; String ; ; Class Alunos isa Pessoas { int matricula; String responsavel; String situacao float saldo; date data_ultimo_pagamento; date data_matricula; float nota; int frequencia; ; Class Funcionarios isa Pessoas{ int cod_func; String CTPS; float quant_horas_trabalhada; float salário_hora; date data_admissao; float salário_total; ; Class Pessoal_Administrativo isa Funcionarios{ String cargo; ; Class Professores isa Funcionarios { String area; String curso_habilitados; ;

26 Identidade de Objeto (OID) e Ponteiros No modelo Orientado a Objetos, o objeto mantém a identidade mesmo que sua propriedade se altere (variáveis, métodos, etc). Esse conceito não se aplica ao Modelo Relacional, porque as tuplas só são diferenciadas pelos valores que contém. A forma de identidade que o Modelo de Objeto usa é embutida, ou seja, é atribuído um identificador automático, ao contrário do Relacional em que se precisa atribuir uma chave primária em uma tabela como identificador único (Silberschatz et al., 1999). A identidade de objeto (OID) permite identificar unicamente um objeto, podendo ser números longos, caracteres, entre outros, onde a habilidade de armazenar é mais importante do que um nome de fácil compreensão pelo usuário. O objeto armazena uma referência do objeto que o representa. O problema é que os identificadores são específicos do sistema e devem ser traduzidos se houver necessidade de mudar para outro sistema, pois este já possui identificadores únicos externo ao sistema (Silberschatz et al., 1999). Os OIDs podem privar o programador de se preocupar com a implementação das chaves, mas em muitos casos, não elimina totalmente o uso de chaves pelo usuário. As chaves podem ser necessárias para facilitar referências ao mundo exterior e também servir como bases de pesquisas dentro do Banco de Dados (Date, 2000). Ao se criar um objeto, ele recebe um identificador. Linguagens Orientadas a Objetos não foram originalmente adaptadas para trabalharem com objetos persistentes, portanto o identificador somente será utilizado durante a execução do programa. Após o término, o objeto é excluído e o identificador fica sem sentido (Silberschatz et al., 1999). A idéia de identidade de objeto está relacionada com ponteiros. Um exemplo de se obter identidade é através de ponteiros para localização física. Um OID em C++ é um ponteiro de memória. Os identificadores em Banco de Dados em C++ são implementados através de ponteiros persistentes que, ao contrário de ponteiros de memória, permanecem válidos mesmo após o encerramento do programa. Porém a localização física de um objeto pode se alterar com o tempo. Para isso, existem várias formas de permanência de identidade: intraprocedimento, intraprograma, interprograma e persistente, sendo esta última necessária para o sistema de armazenamento de objetos, pois a persistência não é unicamente durante a execução do programa, mas, sim, entre as mudanças de estruturas dos dados (Silberschatz et al., 1999).

27 Linguagens de Programação Persistente O que difere uma linguagem de programação de um Banco de Dados é a manipulação de dados persistentes que continuam a existir mesmo que o programa se encerre, como por exemplo, as tabelas do Banco de Dados Relacionais. Isso é diferente das linguagens de programação que só manipulam arquivos. A linguagem relacional SQL é mais efetiva para manipular dados, mas outras linguagens de programação são exigidas para a implementação de uma aplicação como interface de usuário e rede. A forma mais comum para realizar a interface entre o Banco de Dados e a linguagem de programação é a introdução da linguagem SQL no meio do código. Esta solução possui o inconveniente de converter tuplas e objetos para fora do Paradigma Orientado a Objetos, podendo ocorrer erros de difícil identificação. Além disso, a conversão ocupa parte substancial do código. Uma possível solução seria a integração com uma máquina conectada na rede compartilhando o mesmo sistema (Silberschatz et al., 1999). A linguagem de programação persistente é uma linguagem de programação estendida com estrutura para tratar dados persistentes. A vantagem é não precisar alterar o formato dos objetos para armazenamento de dados além de que as mudanças que ocorrem são de forma transparente. Outra vantagem é que não se necessita de código explicíto que mova os dados do banco para a memória para então manipulá-los (Silberschatz et al., 1999). As mais importantes linguagens orientadas a objetos com versões persistentes são C++, Smaltalk e Java. Essas linguagens permitem manipular os dados diretamente sem ter que passar por uma linguagem do Modelo Relacional, como o SQL. A desvantagem de manipular os dados pela linguagem de programação é que elas são mais poderosas, tornando mais fácil cometer erros no Banco de Dados. A complexidade da codificação também se torna maior. O Grupo de Gerenciamento de Banco de Dados Objetos, conhecido ODMG (Object Database Management Group) se empenhou em tentar padronizar as extensões de linguagens C++, Smaltalk e Java para trabalhar com persistência, definindo bibliotecas e estendendo-as o menos possível (Silberschatz et al., 1999). As linguagens de programação orientada a objetos já possuem o conceito de objetos e estrutura para criá-los, mas esses objetos são transientes, ou seja, desaparecem quando o programa se encerra. Para tornár-lo persistente, existem várias formas a serem implementadas. Entre elas estão Persistência por Classe é a mais simples, onde se declara que uma classe é persistente; Persistência por Marcação - Os objetos são marcados como transientes e a decisão de persistência é declarada depois, mas antes do programa se encerrar;

28 15 Persistência por Referência Um ou mais objetos são declarados como persistentes (raiz). A partir disto, todos os objetos referenciados a partir dos objetos raízes são considerados persistentes, assim como as referências feitas a partir destes mesmos objetos. Um ponto negativo para essa solução é que a seqüência de cadeias de referência pode ter um alto custo para aplicação (Silberschatz et al., 1999). 2.3 Vantagens e Desvantagens dos Modelos Relacional e Orientado a Objetos Nesta seção são apresentadas as principais vantagens e desvantagens dos Modelos Relacional e Orientado a Objetos Vantagens do Modelo Relacional As principais vantagens do Modelo Relacional são: Bastante usado e com um grande legado (Date, 2000); Grande número de ferramentas e características que implementam o SQL, como padrões de conectividade, ferramentas de relatório, ferramentas de OLAP e de backup, padrões de recuperação e ferramentas gráficas; Quando o sistema de Modelo Relacional é instalado, já vem pronto para uso (Date, 2000); Todas as entidades, ainda que elas sejam relacionamentos, são representados do mesmo modo uniforme especificamente por meio de linhas em relações; O Banco de Dados pode ser manipulado e alterado independentemente da aplicação (Date, 2000); Utilização de diversas aplicações em um mesmo Banco de Dados (Paterson et al., 2006) Desvantagens do Modelo Relacional As principais desvantagens do Modelo Relacional são: Necessidade de seleção de chaves entre tabelas; Necessidade de mapeamento para conversão entre a linguagem de programação orientada

29 16 a objetos e o formato relacional para transformar objetos em estruturas de tabelas, o que o torna mais lento em tempo de compilação e execução e ainda exige parte substancial de código (Silberschatz et al., 1999); Codificação de conversão entre Objetos e Tuplas opera fora do paradigma de programação orientada a objetos e há um risco maior de erros não detectados (Silberschatz et al., 1999); Utilização de códigos sem significado semântico para poder identificar tuplas de seleção; Dificuldade de modelar novas aplicações e objetos complexos, como por exemplo, dados multimídia (Silberschatz et al., 1999) Vantagens do Modelo de Objetos As principais vantagens do Modelo de Objetos são: Utilização dos princípios das linguagens de programação orientada a objetos (Silberschatz et al., 1999); Não é necessária a seleção de chaves para as várias classes de objetos e utilizar códigos sem significado semântico para poder identificar tuplas de seleção; Maior consistência em manipulações de dados; Armazenamento direto de tipos de dados complexos (Silberschatz et al., 1999); Habilidade de alterar a definição de um objeto sem modificar o resto do sistema (Silberschatz et al., 1999); Utilização de identificador de objeto (OID) único e imutável, criado pelo sistema automaticamente e que são implementados em baixo nível (Silberschatz et al., 1999); Permite manipular o Banco de Dados diretamente com a linguagem de programação sem intermediação de outra linguagem, o que possibilita ter objetos muito complexos sem necessidade de transformar os dados (Silberschatz et al., 1999).

30 Desvantagens do Modelo de Objetos As principais desvantagens do Modelo de Objetos são: Pouco usado (Date, 2000); Ferramentas gráficas para desenvolvimento possuem poucos recursos. Ausência das ferramentas e características disponíveis em SQL; Quando o sistema é instalado não fica disponível para uso imediato, ele é adaptado para construções de classes e métodos (Date, 2000); Instabilidade no direcionamento de aplicações, já que tudo se resume a objetos; Linguagens para consultas não padronizadas (Date, 2000); Modificações de um esquema de banco de dados orientados a objeto é mais complicado que o modelo relacional, pois possui tipos complexos e herança; Gasta-se mais tempo para implementação do código para manusear objetos persistentes e apresenta dificuldades de especificar restrições (Date, 2000); Mais chance de cometer erros no Banco de Dados, já que as linguagens de programação são mais poderosas (Silberschatz et al., 1999); Identificadores são específicos do sistema e devem ser traduzidos se houver necessidade de mudar para outro sistema (Silberschatz et al., 1999).

31 18 3 PROJETO DO PROTÓTIPO Para dar inicío ao projeto do protótipo, foi definido um problema para ser modelado. O problema escolhido para ele foi de uma Escola de Informática. Os casos de uso do protótipo estão definidos na Figura 4 que resume as interacções entre o usuário e o protótipo. Figura 4 Casos de uso para o protótipo de um sistema de Escola de Informática. Conforme os casos de uso descrito na Figura 4, as ações disponíveis para um Funcionário de Escola de Informática são de Cadastrar Pessoas (Alunos ou Funcionários), Cadastrar Turmas, Cadastrar Cursos, Matricular Alunos e Calcular Salário do Funcionário. Os cadastros feitos no protótipo podem ser alterados, consultados e removidos. 3.1 Modelagem do Banco de Dados O projeto do protótipo foi modelado com os dois modelos de Banco de Dados, o Relacional e o de Objetos. A Figura 5 exibe a modelagem para o Banco de Dados Relacional e a Figura 6 mostra a Modelagem Orientada a Objetos com suas respectivas classes. A Figura 7 apresenta a modelagem das Tabelas.

32 Modelagem Relacional para o Protótipo Figura 5 Modelo Relacional para o protótipo de um sistema de Escola de Informática.

33 Modelagem das Classes de Objetos para o Protótipo Figura 6 Modelo Orientado a Objetos para o protótipo de um sistema de Escola de Informática.

34 Modelagem das Tabelas para o Modelo Relacional Figura 7 Modelagem das Tabelas do Modelo Relacional 3.2 Softwares utilizados no Projeto Os seguintes softwares foram utilizados para o desenvolvimento deste projeto: IDE NetBeans IDE Java de Código Livre (NetBeans, 2009); MySQL Banco de Dados Relacional; db4objects (db4o) Banco de Dados para Objetos (Informações, 2009); Windows Vista Home 32 bits - Sistema Operacional.

35 MySQL O MySQL é um gerenciador de Banco de Dados Relacional que utiliza a linguagem SQL. Desenvolvido para proporcionar economia na Web (Maior, 2009) e a sua crescente popularização se devem, principalmente, por ser gratuito e com código aberto (licença GPL). Está disponível para vários sistemas operacionais (Windows, Linux, MacOS, FreeBSD, OpenBS, etc). Ele foi produzido pela empresa alemã MySQL AB, disponível desde 1996, mas tem uma história de desenvolvimento que remonta a 1979 (Welling-Thomson, 2005). Mais tarde o MySQL foi comprado pela Sun Microsystems que hoje está preste a pertencer a Oracle (Oreskovic-Finkle, 2009). Ele utiliza SQL e permite armazenar, consultar, classificar e recuperar dados de forma eficiente e garante o acesso a multiusuários, assegurando que somente usuários autorizados acessem os dados (Welling-Thomson, 2005). Usado em mais de 10 milhões de máquinas com 50 mil downloads diários (Sun, 2008), alguns de seus usuários são o Facebook, Google, Nokia, Paggo, NASA, globo.com, NBC etc. (MySQL Customers, 2009). Segundo a Sun, seus benefícios são ferramentas para fácil desenvolvimento e implantação de infra-estruturas da Web complexas, dimensionável para suportar cerca de um milhão de usuários ao mesmo tempo e implantação em várias camadas que reduz custos e torna a implantação mais segura e simples (Maior, 2009). A Figura 8 mostra a representação da arquitetura MySQL. Figura 8 - Representação da arquitetura de um servidor Mysql (Palkovic, 2008).

36 db4objects (db4o) O db4objects (db4o) é um Banco de Dados Orientado a Objetos open source, projetado para aplicações do tipo embarcada, cliente-servidor e desktop. Foi usado para a implementação do protótipo no projeto. Possui modo nativo para Java e.net. Usa uma única biblioteca de desenvolvimento que se integra facilmente às aplicações e executa de forma altamente confiável e escalável tarefas de persistência com somente algumas linhas de código, não importando o quanto são complexas as estruturas. Não necessita utilizar-se de consultas SQL para CRUD (Create, Read, Update e Delete), eliminando a troca de orientado a objetos por performance (db4o, 2009). Empresas como a Boing, Bosch, Hertz, BMW, Intel, Seagate entre outras (Customers and Partners, 2009), já utilizam o db4o. Apresenta vantagens em relação ao Banco de Dados Relacional: oferece rapidez de inserção, utiliza pouco recurso computacional, tem fácil aprendizado, acesso direto ao Banco de Dados sem utilizar ORM (Mapeamento Objeto- Relacional) e ambiente de administração zero, já que as rotinas de melhoria podem ser feitas por um programador (Guerra, 2007). Na Espanha, a Indra Sistemas, uma empresa de desenvolvimento de softwares, foi contratada para criar o centro de controle do sistema espanhol de trens bala AVE. Neste projeto, o db4o foi utilizado como a base de dados de tempo real para controlar o tráfego. A capacidade de processamento do sistema da Indra fica em torno de 200 mil objetos por segundo (Rosenberg, 2009). A Figura 9 mostra que o objeto é desmontado para o armazenamento em estruturas de tabelas no Banco de Dados Relacional. Já no db4o, o objeto é diretamente armazenado como objeto. Figura 9 - Armazenamento de objetos em um B.D. Relacional e em um B.D. db4o (Paterson et al., 2006). De acordo com a empresa que produz o db4o, este banco roda até 44 vezes mais rápido que os Bancos de Dados conhecidos como Hibernate com Mysql (db4o, 2009). O benchmark de licença GPL, PolePosition, tem um método de teste chamado Barcelona que faz escrita, leitura, consultas e remoção de objetos com uma estrutura de herança de 5 níveis (PolePosition, 2009). Segundo o teste, o db4o se saiu melhor em relação a vários Bancos de

37 24 Dados conforme detalhes da Tabela 7. Tabela 7 - Detalhes do benchmark open source PolePosition gerado para comparar o db4o (Benchmarks, 2009). mais rápido mais lento Os recursos de consultas são fundamentais para qualquer Banco de Dados e o db4o oferece vários métodos de recuperação de dados (Paterson et al., 2006): QBE (Query by Example): No método QBE, você cria um modelo de objeto, que é uma instância da classe que você deseja pesquisar. Se atribuir valores para um ou mais atributos no seu modelo, então db4o procura por objetos no Banco de Dados com os atributos correspondentes. É um método simples e de fácil aprendizagem, mas só é ideal para consultas que não precisam de operadores lógicos. SODA (Simple Object Data Access): Constrói um grafo de consulta navegando referências em classes e as restrições que impõe. Utiliza strings para identificar os campos. Rápido, mas o conceito pode ser difícil de acostumar. NQ (Native Query): É uma consulta nativa expressa inteiramente na linguagem de programação e com checagem de tipos durante a compilação. Oferece consultas com várias vantagens importantes. 3.3 Exemplo MySQL X db4o Seguem dois códigos simples de exemplo para inserção, atualização, consulta e remoção, escrito linguagem Java. O primeiro utiliza o Banco de Dados Relacional MySQL e o segundo o Banco de Dados Orientado a Objetos db4o.