Você está na página 1de 47

Roberto Baselio Lopes RA0502013 – 8º Semestre

ESTUDO COMPARATIVO DE IMPLEMENTAÇÃO DE MODELOS DE BANCO DE DADOS

Jaguariúna

2008

2

Roberto Baselio Lopes RA0502013 – 8º Semestre

ESTUDO COMPARATIVO DE IMPLEMENTAÇÃO DE MODELOS DE BANCO DE DADOS

à

disciplina "Trabalho de Conclusão de

Curso", do curso de Ciência da Computação da Faculdade de JAGUARIÚNA, sob orientação do Professor Luciano Calderoni, como exigência parcial para conclusão do curso de graduação.

Monografia

apresentada

Jaguariúna

2008

3

LOPES, Roberto Baselio. Estudo comparativo de implementação de modelos de banco de dados. Monografia defendida e aprovada na FAJ em 09 de dezembro de 2008 pela banca examinadora constituída pelos professores:

Prof. Luciano Calderoni Professor Orientador - FAJ

Prof. Fernando Augusto Zancheta Professor FAJ

4

Dedico este trabalho a minha companheira, que nos momentos mais difíceis esteve a meu lado, a minha mãe, pelos esforços realizados em me auxiliar, a meu professor orientador, pela maneira como me conduziu na elaboração deste, e acima de tudo a Deus, por ter me atendido e guiado pelo caminho correto.

5

AGRADECIMENTOS

Começo por agradecer a minha atual namorada e futura companheira, pelos sacrifícios realizados em prol de conclusão desta atividade.

A minha mãe Gécia Baselio, pelas restrições impostas a si mesma, a fim de me

auxiliar nesta missão. Aos colegas Rafael Rodrigues Bueno, Renato Freire Ricardo, Rafael Barbosa

Camargo e Kleber Quilez, aos quais, com nossos acalorados debates e compartilhamento de conhecimento, também impactaram no resultado deste trabalho.

E por último, mas certamente o mais importante, a meu professor orientador Luciano

Calderoni, por também acreditar em meu potencial, aceitando a tarefa de me orientar na realização deste, canalizando e direcionando louvavelmente as minhas idéias e ações neste projeto.

6

Eu acredito que não existem heróis.

A gente pode ter pessoas realmente espetaculares, por exemplo, figuras

espiritualizadas, religiosas, que são grandes modelos para a humanidade, mas na verdade,

todo mundo é igual.

Eu

não acredito que eu tenha uma verdade a mais. E principalmente a juventude.

Se

a juventude cair nesse erro de acreditar que sim, elas inevitavelmente vão acabar

descobrindo que o ídolo delas tem pés de barro.

(Renato Russo)

7

LOPES, Roberto Baselio. Estudo comparativo de implementação de modelos de banco de dados, 2008. Monografia (Bacharelado em Ciência da Computação) – Curso de Ciência da Computação da faculdade de Jaguariúna, Jaguariúna.

RESUMO

Com o advento da informática e sua utilização nas mais diversas finalidades, a persistência de dados tornou-se um dos mais importantes pilares dos sistemas de informações. Dentro deste contexto, garantir a integridade, a confiabilidade e a não replicação de dados passou a ser o fundamento principal na implementação de sistemas gerenciadores de bancos de dados. Diante desta realidade surgem vários modelos/métodos de implantação de persistência de dados, sendo os mais empregados atualmente os bancos de dados relacionais (SGDB), e mais especificamente ainda, os que se utilizam da linguagem SQL. Com o grande avanço das linguagens de programação, surgiu a necessidade de integrá-las aos bancos de dados, então surgiram camadas de persistências que realizavam a comunicação com os bancos de dados através de drivers, tornando-os genéricos e possíveis de serem aplicados a qualquer linguagem programação. Os exemplos mais básicos são o JDBC ou o ODBC. Paralelamente, também surgiram os frameworks facilitando a implementação das camadas de persistência. Em outra vertente, temos a evolução das linguagens de programação orientada a objetos trazendo consigo os bancos de dados orientados a objetos. Estes reduziram a necessidade do uso de drivers para conexões e eliminou a manipulação de dados para torná-los compatíveis com modelo relacional. O objetivo deste trabalho foi pesquisar as diferenças nas metodologias de persistência de dados (SGDB nativo, framework, SGDBOO), nas operações de CRUD e alguns dos principais recursos dos bancos de dados, as triggers, chaves primárias e estrangeiras.

PALAVRAS CHAVES: Banco de dados, Framework, implementação, tecnologia.

8

ABSTRACT

With the advent of computers and their use in many different purposes, the persistence of data has become one of the most important pillars of information systems. Inside of this context, ensuring the integrity, reliability and no data replication has become the essential foundation of system managers in the implementation of databases. Before this situation arise various models / methods of implantation of data of persistence, as currently employed, the relational databases (SGDB), and even more specifically, the ones which use SQL. With the big breakthrough programming languages, came the need to integrate them to the databases, then emerged categories of persistency held that the communication with the databases through drivers, made generic possible to be applied to any programming language. The most basic example the JDBC or ODBC, in addition, it also ederged the frameworks facilitating the implementation of layers of persistence. Other side, we have the evolution of programming language guided to objects bringing, the databases oriented to object. These reduced the need for drivers for connections and dropped the manipulation of data to make them compatible necessary in the relational model. The research aimed to find differences in methods of data persistence (SGDB native, framework, SGDBOO), in CRUD operations and some of the main resources of databases, the triggers, primary keys and foreign keys.

KEY WORDS: Database, Framework, implementation, technology.

9

Sumario

LISTA DE SIGLAS

11

LISTA DE CODIGOS FONTE

12

LISTA DE ILUSTRAÇÕES

13

LISTA DE TABELAS

14

1. INTRODUÇÃO

15

1.1. Objetivos

15

1.2. Metodologia

16

1.3. Cronograma

16

1.4. Capítulos

17

2. MODELOS DE IMPLANTAÇÃO

18

2.1. Modelo Relacional

18

2.1.1.

Etapas da implementação banco relacional

20

2.2. Framework

20

2.2.1.

Etapas da implementação banco via framework

21

2.3. Modelo Orientado a objeto

21

2.3.1.

Etapas da implementação banco orientado a

23

3. SOBRE OS BANCOS DE DADOS E FRAMEWORKS

24

3.1. PostgreSQL

24

3.2. Hibernate

24

3.3. DB4o

25

4. CONCEITOS

27

4.1. UML

27

4.2. XML

27

4.3. DER

28

4.4. JDBC

28

4.5. Operações de CRUD

29

5. ESTUDO DE CASO

30

5.1. Relacionamentos e Operações de CRUD

31

5.1.1. PostgreSQL (modelo relacional)

31

5.1.2. Hibernate (framework)

33

5.1.3. DB4o (orientado à objeto)

37

5.2. Índices e chaves

40

5.2.1. PostgreSQL

41

5.2.2. Hibernate

41

 

5.2.3. BD4o

41

10

5.4.

Desempenho

42

5.4.1. Ambiente

42

5.4.2. Metodologia

42

5.4.3. Resultados

43

6. RESULTADOS OBTIDOS

44

6.1.

Comparativo de características

45

7. BIBLIOGRAFIA

46

11

LISTA DE SIGLAS

ANSI-

American National Standards Institute;

CRUD-

Acrônimo da expressão em língua Inglesa Create, Retrieve, Update e Destroy, usada para definir quatro operações básicas usadas em bancos de dados relacionais;

DAO-

Data Acess Object;

DBA-

DataBase Administrator;

DB4o-

DataBase for Object;

DBOO-

Banco de dados orientado a objeto;

HQL-

Hibernate Query Language;

JAVA/SE-

Java Standard Edition;

JDBC-

Java Database Connectivity;

DER-

Diagrama Entidade-Relacionamento;

ODBC-

Open Data Base Connectivity;

ODMG-

Object Database Management Group;

OO-

Orientação à Objeto;

RDBMS-

Relational database management system

SIG-

Sistema de Informação Geográfica;

SGDB-

Sistema Gerenciador de Banco de Dados;

SGDBOO-

Sistema Gerenciador de Banco de Dados Orientado a Objeto;

SGDBR-

Sistema Gerenciador de Banco de Dados Relacional;

SQL-

Structured Query Language;

UML-

Unified Modeling Language;

XML-

eXtensible Markup Language;

12

LISTA DE CODIGOS FONTE

Código Fonte 1: Operação de CRUD via SQL

29

Código Fonte 2: Classes a serem persistidas

30

Código Fonte 3: Comando SQL para criação das tabelas

31

Código Fonte 4: Classe para conexão com SGDBR via JDBC

32

Código Fonte 5: Classe para persistência de dados via JDBC

33

Código Fonte 6: Arquivo XML para configuração da conexão via Hibernate

34

Código Fonte 7: Classe que realiza a conexão com banco via Hibernate

35

Código Fonte 8: Arquivo XML de mapeamento da classe proprietário

35

Código Fonte 9: Arquivo XML de mapeamento da classe veículo

36

Código Fonte 10: Operações de CRUD via Hibernate

37

Código Fonte 11: Classe de conexão com bando de dados OO

38

Código Fonte 12: Classe cliente relacionada coma classe veiculo

39

Código Fonte 13: Operações de CRUD via

40

Código Fonte 14: exemplo de declaração de chave primaria

41

13

LISTA DE ILUSTRAÇÕES

Ilustração 1: Exemplo de relacionamento

19

Ilustração 2: Exemplo de DER

19

Ilustração 3: Exemplo DER 1:1

19

Ilustração 4: Exemplo DER 1:N

19

Ilustração 5: Exemplo DER N:N

20

Ilustração 6: Manipulação de dados via framework

21

Ilustração 7: Comparação de manipulação de dados ente SGBDR e SGBDOO

22

Ilustração 8: Diagrama de classe para implementação de base de dado OO

23

Ilustração 9: DER das classes a serem persistidas

31

14

LISTA DE TABELAS

Tabela 1: Cronograma de atividades

16

Tabela 2: Comparativo entre implementações

43

Tabela 3: Comparativo entre modelos de implementação

45

15

1.

INTRODUÇÃO

O termo banco de dados foi criado inicialmente pela comunidade de computação, para

indicar coleções organizadas de informações armazenadas em computadores, porém o termo é atualmente usado para indicar tanto bancos de dados em computadores quanto coleções de dados em geral. Aceitando uma abordagem mais técnica, um banco de dados é uma coleção de registros salvos em um computador em um modo sistemático, de forma que um programa de computador possa consultá-lo para responder questões. Um banco de dados é usualmente mantido e acessado por meio de um software

conhecido como Sistema Gerenciador de Banco de Dados (SGBD). Normalmente um SGBD adota um modelo de dados, de forma pura, reduzida ou estendida. Muitas vezes o termo banco de dados é usado como sinônimo de SGDB. O termo banco de dados deve ser aplicado apenas aos dados, enquanto o termo SGDB deve ser aplicado ao software com a capacidade de manipular bancos de dados de forma geral. Porém, é comum misturar os dois conceitos.

O primeiro SGBD surgiu no final de 1960 tendo como motivação os primitivos sistemas

de arquivos disponíveis na época, estes sistemas não controlavam acessos concorrentes nem replicação de dados dentro do SGDB. Com o tempo, os SGBDs passaram a utilizar diferentes formas de representação para descrever a estrutura das informações contidas em seus bancos de dados. Atualmente, os seguintes modelos de dados são normalmente utilizados pelos SGBDs: hierárquico, em redes, relacional (amplamente usado) e o orientado a objetos.

Com a evolução dos ERPs modernos, os bancos de dados se tornaram o fator principal nas tomadas de decisões, fazendo da figura do DBA (database administrator), uma peça chave no controle das informações e na integridade do banco de dados. Mas com o surgimento, ou melhor, com a evolução dos vários paradigmas de persistência, sendo hoje em dia o relacional e o orientado a objetos os mais evidentes, surge à grande questão, qual paradigma é o mais recomendado.

1.1.

Objetivos

Segundo Gláucio Guerra (http://glaucioguerra.wordpress.com/2007/09/05/banco-de- dados-orientado-a-objetos-dbo4/, mai. 2008).

No mercado existem diversos tipos de banco de dados orientados a objetos como o NeoDatis, ObjectDB, MyOODB e o db4o que foram escritos em Java. Dentre eles, escolhi o db4o para trabalhar em um projeto de um sistema com mais ou menos 50 usuários, sendo no máximo 5 com uso simultâneo. Era um projeto relativamente pequeno, curto prazo de entrega e sem muita complexidade de modelagem. O que dificultava um pouco era o prazo que era muito curto mesmo.

16

O db4o foi perfeito neste caso, evitei toda aquela configuração de mapeamento objeto-relacional com o Hibernate, não precisei falar com o DBA para criar um schema no Oracle me livrando de toda a burocracia que é inevitável na maioria das vezes.

Com o intuito de analisar esta afirmação, este trabalho tem o objetivo de disponibilizar um benchmark aos interessados quanto à qual modelo de persistência de dados resulta numa maior produtividade. Comparando os modelos de implementação Sistema Gerenciador de Banco de Dados Relacional (SGDBR), Sistema Gerenciador de Bando de Dados Orientado à objeto (SGDBOO) e utilizando um framework para um SGDBR. Outros objetivos secundários são:

Disponibilizar informações sobre o funcionamento das tecnologias;

Disponibilizar comparativos entre modelos de implementação.

1.2. Metodologia

Através de pesquisa, serão avaliadas as características dos modelos de implementação, bem como suas particularidades, focando os produtos PostgreSQL para banco de dados relacional, Hibernate para framework e DB4o para banco de dados orientado a objeto. A escolha destes produtos deve-se principalmente a suas características “open- source”, não resultando em custos extras no caso de implantação física.

1.3. Cronograma

Atividade

Mar

Abr

Mai

Jun.

Jul.

Ago.

Set

Out.

Nov.

Levantamento Bibliográfico

OK

OK

OK

OK

OK

OK

OK

OK

OK

Preparação do ambiente de desenvolvimento

OK

               

Implantação do programa base

OK

               

Implantação das tecnologias de persistência

OK

OK

             

Coleta de resultados preliminares

 

OK

OK

           

Compilação do relatório inicial

   

OK

           

Testes

     

OK

OK

       

Correção de Divergências

     

OK

OK

OK

     

Análise dos Resultados

         

OK

OK

   

Entrega do trabalho

             

OK

OK

Tabela 1: Cronograma de atividades

17

1.4.

Capítulos

CAPÍTULO 1 – Neste capítulo consta uma pequena introdução sobre o tema, os objetivos que se pretende atingir com este trabalho, a metodologia adotada na pesquisa e o cronograma de atividades. CAPÍTULO 2 – Neste capítulo são abordados os conceitos dos modelos de persistência de dados, bem como as etapas recomendadas para tal implementação. CAPÍTULO 3 – Neste capítulo temos uma breve descrição dos bancos de dados e framework selecionados para a pesquisa deste trabalho. CAPÍTULO 4 – Neste capítulo consta uma breve explanação sobre as tecnologias e conceitos necessários para a implementação dos bancos de dados selecionados. CAPÍTULO 5 – Neste capítulo consta um estudo de caso onde é minimamente implementado um banco de dados nos três modelos de persistência propostos, a fim de se obter um panorama geral de cada modelo. CAPÍTULO 6 – Neste ponto estão descritas as conclusões, com base na análise do estudo de caso. CAPÍTULO 7 – Aqui são descritos os livros e sites pesquisados.

18

2. MODELOS DE IMPLANTAÇÃO

Existem vários modelos de implementação de banco de dados, abaixo teremos os conceitos dos modelos focos de estudos desta monografia: o modelo relacional, o orientado à objeto e uma introdução ao conceito do framework como ferramenta auxiliar de persistência de dados.

2.1. Modelo Relacional

O modelo relacional é uma teoria matemática desenvolvida por Edgar Frank Codd

(1970), que descreve como as bases de dados devem funcionar. Embora esta teoria seja a base para o software de bases de dados relacionais, poucos sistemas de gestão de bases de dados seguem o modelo de forma restrita, a maioria apresenta funcionalidades que violam a teoria, variando assim em poder e complexidade. A discussão se esses bancos de dados merecem ser chamados de relacional ficou esgotada com tempo e foi padronizada pela arquitetura ANSI / SPARC em três níveis de componentes:

uma coleção de estruturas de dados, formalmente chamadas de relações, ou informalmente tabelas;

uma coleção dos operadores, a álgebra e o cálculo relacionais, que constituem

a base da linguagem SQL;

uma coleção de restrições da integridade, definindo o conjunto consistente de estados de base de dados e de alterações de estados. As restrições de

integridade podem ser de quatro tipos: o domínio (ou tipo de dados), o atributo,

o relvar (variável de relacionamento) e restrições de base de dados.

O modelo relacional atende as necessidades de aumentar a independência de dados

nos sistemas gerenciadores de banco de dados; provendo um conjunto de funções apoiadas na álgebra relacional para persistência e recuperação de dados, se mostrando mais flexível e adequado ao solucionar os vários problemas que surgem na concepção e implementação da base de dados. Um dos pontos fortes do modelo relacional de banco de dados proposto por Edgar é a possibilidade de definição de um conjunto de restrições de integridade. Estas definem os estados e mudanças de estado, determinando os valores que podem e os que não podem ser armazenados. Outro ponto forte são os relacionamentos propriamente ditos, tendo como estrutura básica uma tabela para cada entidade. Os relacionamentos são construídos pelos atributos em comum nas entidades, logo algumas restrições precisaram ser impostas para evitar aspectos indesejáveis, como: Replicação de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são: integridade referencial, chaves

19

e integridade de junções de relações. As figuras a seguir, mostram como ocorre o relacionamento entre tabelas.

seguir, mostram como ocorre o relacionamento entre tabelas. Ilustração 1: Exemplo de relacionamento Ilustração 2:

Ilustração 1: Exemplo de relacionamento

entre tabelas. Ilustração 1: Exemplo de relacionamento Ilustração 2: Exemplo de DER No exemplo acima se

Ilustração 2: Exemplo de DER

No exemplo acima se pode identificar que o Cliente Pedro ocupa o quarto simples, e o Cliente Paulo ocupa o quarto de casal. Outras características dos relacionamentos é seu tipo, que tem a função de indicar como ocorre este relacionamento:

O relacionamento pode ser dos tipos:

1:1 (um para um) – Exemplo: casamento, onde um marido pode possuir apenas uma esposa e uma esposa apenas um marido.

possuir apenas uma esposa e uma esposa apenas um marido. Ilustração 3: Exemplo DER 1:1 •

Ilustração 3: Exemplo DER 1:1

1:N (um para ene) – Exemplo: Veiculo automotor, onde um veículo pode possuir apenas um proprietário, mas um proprietário pode possuir vários veículos.

possuir apenas um proprietário, mas um proprietário pode possuir vários veículos. Ilustração 4: Exemplo DER 1:N

Ilustração 4: Exemplo DER 1:N

20

N:N (ene para ene) – Exemplo quarto de hotel, onde um quarto pode ser alugado por varias pessoas e uma pessoa pode alugar vários quartos.

por varias pessoas e uma pessoa pode alugar vários quartos. Ilustração 5: Exemplo DER N:N 2.1.1.

Ilustração 5: Exemplo DER N:N

2.1.1. Etapas da implementação banco relacional.

O processo de criação de uma base dados consiste em:

Elaborar um modelo de entidade relacionamento DER;

Criação das tabelas no banco de dados;

Definição dos relacionamentos;

Criação dos objetos que serão persistidos;

Criação de classe/função de conexão com o banco de dados;

Criação da classe/função que vai persistir o objeto

2.2.

Framework

“Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação” Mohamed Fayad e Douglas C. Schimidt (Object-oriented application frameworks , 1997)

Em computação, um framework pode ser definido como uma estrutura de suporte definida em que outro projeto de software pode ser organizado e desenvolvido. Um framework pode incluir programas de suporte, bibliotecas de código, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes de um projeto de software. Frameworks são projetados com a intenção de facilitar o desenvolvimento dos projetos software, reduzindo teoricamente o tempo de implantação, sendo que se diferencia de uma simples biblioteca, uma vez que se concentra apenas em oferecer implementação de funcionalidades.

21

A sua utilização para persistência de dados consiste numa camada intermediária que

oculta as operações realizadas diretamente no banco, já que no SGDBR o objeto deve ser “desmontado” na inserção, e “reconstruído” na recuperação,

na inserção, e “reconstruído” na recuperação, Inserção recuperação Ilustração 6: Manipulação de
Inserção recuperação
Inserção
recuperação

Ilustração 6: Manipulação de dados via framework

A utilização de um framework de persistência de dados tende a facilitar esta atividade

de “desmontar” e reconstruir. A motivação para o uso de frameworks de persistência é ter um mecanismo simples para persistência de objetos com bancos de dados SQL,

mapeamento automático, ou semi-automático, construção de consultas através da montagem de protótipos, foco em OO.

2.2.1. Etapas da implementação banco via framework

O processo de criação de uma base de dados consiste basicamente em:

Elaborar um modelo de entidade relacionamento DER;

Criação das tabelas no banco de dados onde serão persistidos os dados

Criação dos objetos que serão persistidos;

Criação do mapeamento (geralmente em XML) relacionando as propriedades do objeto aos campos na tabela

Criação do arquivo de propriedades para que o Hibernate se conecte ao banco de dados;

Criação da classe que vai persistir o objeto

2.3. Modelo Orientado a objeto

Segundo José Carlos Macoratti (http://www.macoratti.net/net_oocb.htm, abr. 2008), a orientação a objetos, também é conhecida como um paradigma de análise, projeto e programação de sistemas baseado na composição e interação entre diversas unidades de software chamadas de objetos.

22

Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de projeto. Juntamente com o avanço da linguagem de programação orientadas a objeto, surgiram os bancos de dados propostos nos mesmo paradigmas. Os bancos de dados orientados a objeto (DBOO) começaram a se tornar comercialmente viáveis em meados de 1980. Seu surgimento se deve aos limites de

armazenamento e representação semântica impostas no modelo relacional. Alguns exemplos são os sistemas de informações geográficas, que são mais facilmente construídos usando tipos complexos de dados.

A estrutura padrão para os DBOO foi feita pelo Object Database Management Group

(ODMG). Esse grupo é constituído por representantes dos principais fabricantes de DBOO e seus membros têm o compromisso de incorporar o padrão em seus produtos. O termo Modelo Orientado a Objetos é usado para documentar o padrão que contém a descrição geral das facilidades de um conjunto de linguagens de programação orientadas a objetos e

a biblioteca de classes que pode formar a base para o SGDBOO. Quando os DBOO foram

introduzidos, algumas das falhas perceptíveis do modelo relacional pareceram ter sido solucionadas com esta tecnologia e acreditava-se que tais bancos de dados ganhariam grande parcela do mercado. Hoje, porém, acredita-se que os DBOO serão usados em aplicações especializadas, enquanto os sistemas relacionais continuarão a sustentar os

negócios tradicionais, onde as estruturas de dados baseadas em relações são suficientes.

A principal característica de um BDOO e a forma como ele persiste os dados. Como

mencionado anteriormente, o modelo relacional precisa “desmontar” o objeto, o DBOO salva

o objeto diretamente no banco.

o objeto, o DBOO salva o objeto diretamente no banco. Ilustração 7: Comparação de manipulação de

Ilustração 7: Comparação de manipulação de dados ente SGBDR e SGBDOO

Na fase de projeto de um DBOO podem ser utilizados os diagramas de classes em UML em substituição ao DER no banco de dados relacional. Na figura abaixo temos um digrama de um DBOO.

23

23 Ilustração 8: Diagrama de classe para implementação de base de dado OO 2.3.1. Etapas da

Ilustração 8: Diagrama de classe para implementação de base de dado OO

2.3.1. Etapas da implementação banco orientado a objeto.

Para a criação de banco de dados orientado a objetos são necessários os seguintes passos:

Elaboração da UML ou DER das classes persistidas;

Criação do objeto que será persistido;

Definição dos relacionamentos;

Criação da classe que vai persistir o objeto;

24

3. SOBRE OS BANCOS DE DADOS E FRAMEWORKS

Muitos bancos de dados comercialmente viáveis estão disponíveis para uso. Neste capitulo abordaremos os softwares e frameworks que são foram utilizados nesta monografia.

3.1. PostgreSQL

O PostgreSQL é uma derivação do projeto POSTGRES da universidade de Berkeley,

cuja última versão foi a 4.2. O POSTGRES foi originalmente financiado pelo DARPA (Agência de Projetos de Pesquisa Avançada para Defesa), ARO (Departamento de Pesquisa Militar), NSF (Fundação Científica Nacional) e ESL Inc. A implementação do

projeto POSTGRES iniciou em 1986, e em 1987 tornou-se operacional. A primeira versão lançada para o público externo foi em 1989. Em 1991 era lançada a versão 3, com melhorias no executor de consultas e algumas partes do código foram refeitas. As versões subseqüentes, até o Postgres95, foram focadas em confiabilidade e portabilidade. O POSTGRES foi utilizado para diversos sistemas de pesquisa e de produção, uma aplicação de análise financeira, um banco com rotas de asteróides, e diversos sistemas de informações geográficas. O código do POSTGRES foi aproveitado em um produto comercializado pela Illustra Information Technologies (posteriormente incorporada à Informix, que agora pertence à IBM).

A versão 95 (Postgres95) teve mudanças radicais em relação ao projeto original. O

seu código foi totalmente revisado, o tamanho do código fonte foi reduzido em 25%, e a linguagem SQL foi implementada. O desempenho foi melhorado e vários recursos foram adicionados. Em 1996 o nome Postgres95 tornou-se inadequado, o projeto foi rebatizado "PostgreSQL", para enfatizar a relação do POSTGRES original com a linguagem SQL. A numeração da versão voltou a seguir o padrão anterior ao Postgres95 (considerada a 5.0), e a primeira versão do PostgreSQL foi a 6.0. Enquanto a ênfase do Postgres95 tinha sido a correção de falhas e otimização do código, o desenvolvimento das primeiras versões do PostgreSQL foi orientada à melhoria de recursos e implementação de novos recursos, sempre seguindo os padrões de SQL anteriormente estabelecidos

3.2. Hibernate

Hibernate foi criado por desenvolvedores Java, espalhados ao redor do mundo, e liderado por Gavin King. Posteriormente, JBoss Inc (empresa comprada pela Red Hat) contratou os principais desenvolvedores do programa para fazer o seu suporte. Por: José Claudio Vahl Júnior e Marcílio da Silva Oliveira em Uma introdução dirigida (2005) dizem que

“O Hibernate é uma solução livre para armazenar objetos

Java

em

bases

de

dados relacionais (Object/Relational Mapping -

25

ORM). Além de mapear as classes Java para as tabelas do banco de dados, o Hibernate também possui uma linguagem (HQL) que facilita a recuperação dos dados evitando esforços com manipulação direta de SQL e JDBC”

O objetivo do Hibernate é diminuir a complexidade entre os programas Java, baseado

no modelo orientado a objeto, que precisam trabalhar com um SGBDR. O Hibernate abstrai geração das chamadas SQL e libera o desenvolvedor do trabalho manual da conversão dos dados resultantes, mantendo o programa portável para quaisquer bancos de dados SQL, em contrapartida (segundo estudos), causa um pequeno aumento no tempo de execução. Hibernate pode ser utilizado em aplicações Java standalone ou em aplicações Java EE, utilizando servlet ou sessões EJB beans. Uma característica do Hibernate é o uso da HQL (Hibernate Query Language) que é um dialeto SQL para o Hibernate. Ela é uma poderosa linguagem de consulta que se parece muito com a SQL, mas a HQL é totalmente orientada a objeto, incluindo os paradigmas de herança, polimorfismo e encapsulamento.

3.3.

DB4o

No mercado existem diversos tipos de banco de dados orientados a objetos como o NeoDatis, ObjectDB, MyOODB e o db4o que foram escritos em Java.

O db4o é um banco de dados inteiramente orientado a objetos, podendo ser utilizado

em aplicações do tipo embarcada, cliente-servidor e desktop. Este SGDB permite armazenar classes Java diretamente no banco, sem precisar utilizar consultas SQL ou qualquer tipo de framework que faça o mapeamento objeto-relacional. Empresas como a Bosch, Hertz, BMW, Intel, Seagate entre outras, já utilizam o db4o. São inúmeras as vantagens em relação ao banco de dados relacional: a ferramenta é nativa em Java (ou .Net), oferece rapidez de inserção e consulta, utiliza pouco recurso computacional, tem fácil aprendizado, não possui nenhuma linha de código SQL para CRUD (Create, Read, Update e Delete). Em seu artigo, Gláucio Guerra (http://glaucioguerra.wordpress.com/2007/09/05/banco- de-dados-orientado-a-objetos-dbo4/, mai. 2008), comenta.

Posso dizer que minha experiência foi muito boa com este BDOO com os seguintes parâmetros:

Pouca concorrência

Baixa complexidade no DER

Sincronização com PDA

26

A principal característica do DB4o, disponibilizada pelo site PolePosition que é um projeto open-source para Benchmark de banco de dados (http://www.polepos.org/, mai 2008). Este banco roda até 44 vezes mais rápido que os BDs que já conhecemos.

27

4.

CONCEITOS

Ao longo desta monografia são abordados alguns termos e nomenclaturas, portanto, abaixo temos descritos os principais conceitos necessários para a persistência de dados.

4.1. UML

A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária

de terceira geração. A UML não é uma metodologia de desenvolvimento, mas ela auxilia a visualizar o desenho e a comunicação entre objetos. Os esforços para a criação da UML tiveram início em outubro de 1994, quando

Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Método Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.

É importante distinguir entre um modelo UML e um diagrama UML, o último é uma

representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente. Hoje em dia o uso da UML faz parte das “boas práticas de engenharia", pretendendo ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos. Kris Richards e Cindy Castillo, no artigo “Why Model With UML?” (http://www.netbeans.org/kb/55/uml-why-model.html, jun. 2007), dizem.

O propósito da Linguagem de Modelagem Unificada (Unified Modeling Language - UML) é prover uma notação de modelagem independente de linguagem de programação e de plataforma. Ferramentas UML são tão versáteis quanto os fundamentos de UML.

4.2. XML

O XML (eXtensible Markup Language) foi estimulado pela insatisfação com os formatos existentes (padronizados ou não), o World Wide Web Consortium (W3C) começou a trabalhar em meados da década de 1990 em uma linguagem de marcação que combinasse a flexibilidade da SGML com a simplicidade da HTML. O principio do projeto era criar uma linguagem que pudesse ser lida por software, e integrar-se com as demais linguagens. Sua filosofia seria incorporada por vários princípios importantes:

Separação do conteúdo da formatação;

Simplicidade e Legibilidade, tanto para humanos quanto para computadores;

Possibilidade de criação de tags sem limitação;

28

Criação de arquivos para validação de estrutura (Chamados DTDs);

Interligação de bancos de dados distintos;

Concentração na estrutura da informação, e não na sua aparência;

O XML é considerado um bom formato para a criação de documentos com dados organizados de forma hierárquica, como se vê freqüentemente em documentos de texto formatados, (properties). Essa característica permite, por exemplo, que um banco de dados possa através de uma aplicação escrever em um arquivo XML, e outro banco distinto possa ler então estes mesmos dados.

4.3. DER

Diagrama entidade relacionamento é um modelo diagramático que descreve o modelo de dados de um sistema com alto nível de abstração. Ele é a principal representação do Modelo de Entidades e Relacionamentos. Sua maior aplicação é para visualizar o relacionamento entre tabelas de um banco de dados, no qual as relações são construídas através da associação de um ou mais atributos destas tabelas.

4.4. JDBC

Java Database Connectivity ou JDBC é um conjunto de classes e interfaces (API) escritas em Java que faz o envio de instruções SQL para qualquer banco de dados relacional; API de baixo nível e base para APIs de alto nível; Amplia o que você pode fazer com Java; Possibilita o uso de bancos de dados já instalados; Para cada banco de dados há um driver JDBC que pode cair em quatro categorias:

Ponte JDBC-ODBC: É o tipo mais simples, mas restrito à plataforma Windows. Utiliza ODBC para conectar-se com o banco de dados, convertendo métodos JDBC em chamadas às funções do ODBC. Esta ponte é normalmente usada quando não há um driver puro - Java (tipo 4) para determinado banco de dados, pois seu uso é desencorajado devido à dependência de plataforma.

Driver API-Nativo: O driver API-Nativo traduz as chamadas JDBC para as chamadas da API cliente do banco de dados usado. Como a Ponte JDBC- ODBC, pode precisar de software extra instalado na máquina cliente.

Driver de Protocolo de Rede: Traduz a chamada JDBC para um protocolo de rede independente do banco de dados utilizado, que é traduzido para o protocolo do banco de dados por um servidor. Por utilizar um protocolo independente, pode conectar as aplicações clientes Java a vários bancos de dados diferentes. É o modelo mais flexível.

29

Driver nativo: Converte as chamadas JDBC diretamente no protocolo do banco de dados. Implementado em Java, normalmente é independente de plataforma e escrito pelos próprios desenvolvedores. É o tipo mais recomendado para ser usado.

4.5. Operações de CRUD

CRUD é o acrônimo da expressão em língua Inglesa Create, Retrieve, Update e Delete, usada para definir quatro operações básicas usadas em bancos de dados relacionais (RDBMS) ou em interface para usuários para criação, consulta, atualização e destruição de dados. As operações CRUD também são relevantes em interfaces para usuários de vários níveis. Por exemplo, em um programa de Catálogo de Endereços, uma entrada de um contato individual pode ser considerada a unidade básica de persistência. Em SQL os comandos podem ser resumidos em:

CREATE TABLE 'tabela' (

);

‘campo1’,

‘campo2’,

‘campo3’,

INSERT INTO 'tabela' ('campo1','campo2','campo3'

('valor1','valor2','valor3'

);

)

VALUES

DELETE FROM 'tabela' WHERE 'condição';

UPDATE 'tabela' SET 'campo1'= 'valor' WHERE 'condição';

Código Fonte 1: Operação de CRUD via SQL

30

5. ESTUDO DE CASO

Partindo de um problema básico, como “Cadastro de Veículos” e considerando apenas dois objetos, o proprietário e o veículo, teremos as duas classes Java abaixo:

public class Proprietario { private int id = 0; private String nome = null;

public class Veiculo { private String placa = null; private String modelo = null;

public Proprietario(int id, String nome){

public Veiculo(String placa, String modelo){

 

super(); this.id = id; this.nome = nome;

 

super(); this.placa = placa; this.modelo = modelo;

}

}

public int getId(){ return id;

public String getPlaca() { return placa;

}

}

public void setId(int id){ this.id = id;

public void setPlaca(String placa){ this.placa = placa;

}

}

public String getNome(){ return nome;

public String getModelo() { return modelo;

}

}

public void setNome(String nome){ this.nome = nome;

public void setModelo(String modelo){ this.modelo = modelo;

}

}

}

}

Código Fonte 2: Classes a serem persistidas

Para o exemplo serão consideradas também as seguintes premissas

Cada carro possui um proprietário

Cada proprietário possui um ou mais carros.

Teremos então os processos abaixo divididos para cada um dos bancos, levando em conta as etapas de implementação proposta no capítulo referente aos modelos de implantação e utilizando as tecnologias selecionadas.

31

5.1. Relacionamentos e Operações de CRUD

5.1.1. PostgreSQL (modelo relacional)

De acordo com o problema exposto acima temos um relacionamento de 1:N que pode ser representado pelo seguinte DER:

de 1:N que pode ser representado pelo seguinte DER: Ilustração 9: DER das classes a serem

Ilustração 9: DER das classes a serem persistidas

Com base neste modelo, temos o seguinte código SQL para criação das tabelas no banco:

CREATE TABLE Proprietario ( ID INTEGER NOT NULL

, Nome CHAR(30)

);

CREATE TABLE Veiculo ( Placa CHAR(7) NOT NULL

, Modelo CHAR(20)

, ID INTEGER NOT NULL

);

ALTER TABLE Proprietario ADD CONSTRAINT PK_PROPRIETARIO PRIMARY KEY (ID);

ALTER TABLE Veiculo ADD CONSTRAINT PK_VEICULO PRIMARY KEY (Placa);

ALTER TABLE Veiculo ADD CONSTRAINT FK_Veiculo_1 FOREIGN KEY (ID) REFERENCES Proprietario (ID);

Código Fonte 3: Comando SQL para criação das tabelas

Nesta etapa de criação já é possível identificar um dos primeiros pilares dos bancos de dados, que é o relacionamento. Como já explicado anteriormente, ele serve para mostrar alguma característica de relação com outra entidade. Para implementar isso o modelo relacional faz uso do conceito de chave estrangeira, que consiste basicamente em relacionar uma entidade conhecida e um atributo de outra entidade.

32

Definido o objeto a ser persistido e criadas as tabelas, os próximos passos ocorrem na linguagem de programação selecionada, que consiste na conexão entre a linguagem e o banco de dados. Para se conectar ao PostgreSQL existem várias formas, pois se trata de um banco de dados independente de sistema operacional possuindo versões Linux e Windows®. As mais comuns são:

ODBC – Conexão disponível no Windows®. JDBC – Conexão disponível para programas em Java. Uma vez que nesta apresentação estamos focados no desenvolvimento em Java, utilizaremos esta última como exemplo de conexão com o banco. Abaixo podemos verificar o código fonte de uma classe Java que retorna um statement para manipulação de dados em SQL.

public class Conec(){;

private static Statement stmt = null; private static ADOconection conexao = null;

public Statement getADOconection() { if ( stmt == null){ try { Class. forName ("org.postgresql.Driver"); Connection con = DriverManager. getConnection (

"jdbc:postgresql://localhost/TCCpostgre:5432",

"postgres", "shaman"); stmt = con.createStatement( ResultSet. TYPE_SCROLL_INSENSITIVE , ResultSet. CONCUR_READ_ONLY );

}

catch (Exception exc) { System. out .println(exc.toString());

}

}

return stmt;

}

}

Código Fonte 4: Classe para conexão com SGDBR via JDBC

Neste código, podemos identificar 3 elementos básicos:

Primeiro: o nome do driver “Class. forName ” que indica qual driver será utilizado, no caso de um driver JDBC cada fabricante de banco de dados é responsável por implementar uma série de classes determinadas para o padrão JDBC, por isso este nome pode variar muito de banco para banco;

33

Segundo: são as três Strings de conexão “DriverManager. getConnection ” sendo elas o endereço do serviço (IP) e nome da base de dados, o nome do usuário e por fim a senha de conexão;

Terceiro: é o elemento statement, ele é o objeto responsável por manipular os comandos em SQL. Uma vez estabelecida uma conexão com o banco (como visto anteriormente), é possível executar os comandos SQL no banco de dados. Abaixo temos um exemplo de como poderíamos executar esta operação diretamente no banco através apenas da conexão JDBC.

public Proprietario operacaoSelect(){ try{ Statement stmt = new Conec().getADOconection(); ResultSet rs = stmt.executeQuery("select * from proprietario where id = 1");

rs.next(); return new Proprietario(rs.getInt("id"), rs.getString("nome"));

}

catch (Exception e) {

return null;

}

}

public boolean operacaoInsert(Proprietario prop){ try{ Statement stmt = new ccc().getADOconection(); stmt.execute("insert into proprietario (id, nome) values(" + prop.getId +", " + prop.getNome +");");

return true;

}

catch (Exception e) {

return false;

}

}

Código Fonte 5: Classe para persistência de dados via JDBC

As operações de CRUD podem ser divididas em dois tipos: as simplesmente executadas “stmt.execute”, que não retornam informações do banco, e as querys “stmt.executeQuery”, estas retornam uma lista de dados compatíveis com busca realizada no banco. Neste código, também nota-se a necessidade de desmontar o objeto para deixá-lo compatível com os dados manipuláveis pelo banco de dados e também nota-se os trabalhos para remontá-lo para que possa ser utilizado pela aplicação.

5.1.2. Hibernate (framework)

Apesar de todas as facilidades propostas pelo uso do Hibernate, as configurações básicas no banco devem ser executadas invariavelmente, ou seja, a criação das tabelas propostas no item anterior devem ser implementadas no banco de dados diretamente.

34

Entretanto, a partir deste ponto iniciam-se diferenças, a começar pela conexão com o banco de dados. Utilizando-se de um arquivo XML, com as informações de conexão e link para os arquivos de mapeamento das tabelas, o Hibernate é capaz de se conectar com o banco.

<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN"

"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>

<session-factory> <property name="Hibernate.dialect"> org.hibernate.dialect.PostgreDialect </property> <property name="Hibernate.connection.driver_class"> org.postgresql.Driver </property> <property name="Hibernate.connection.url">

jdbc:postgresql://localhost/TCCpostgre:5432

</property> <property name="Hibernate.connection.username"> postgre </property> <property name="Hibernate.connection.password"> shaman </property>

<mapping resource="proprietario.hbm.xml"/> <mapping resource="veiculo.hbm.xml"/>

</session-factory>

Código Fonte 6: Arquivo XML para configuração da conexão via Hibernate

No código fonte acima podemos verificar alguns itens importantes.

1. A tag “<session-factory>” é responsável por informar ao Hibernate os

parâmetros de configuração;

2. Nas tags “<property name>” são informados parâmetro individuais de conexão

e informação:

“Hibernate.dialect”: informa qual o padrão de linguagem SQL o banco de dados utiliza;

driver

“Hibernate.connection.driver_class”:

Corresponde

ao

nome

do

JDBC;

“Hibernate.connection.url”: Endereço de conexão do banco;

“Hibernate.connection.username”: Nome de usuário do banco ;

“Hibernate.connection.password”: Senha do usuário;

35

Com o parâmetro de conexão mapeado faz-se necessária a criação de uma classe que instancia conexão com o banco.

import org.hibernate.Session; import org.hibernate.SessionFactory; import org.hibernate.cfg.Configuration;

public class HibernateUtility { private static SessionFactory factory ; static { try {

factory = new Configuration().configure().buildSessionFactory();

}

catch (Exception e) {

e.printStackTrace(); factory = null;

}

}

public static Session getSession() {

return factory .openSession();

}

}

Código Fonte 7: Classe que realiza a conexão com banco via Hibernate

O objeto “factory” lê o arquivo XML e através do método “openSession” retorna uma sessão do Hibernate. Entretanto, ao fazer uso do Hibernate, é preciso algumas configurações extras. Inicialmente é preciso mapear a tabela do banco em relação ao objeto a ser persistido através de um arquivo XML:

<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate Mapping DTD 3.0//EN"

"hibernate-mapping-3.0.dtd">

<hibernate-mapping> <class name="Proprietario" table="proprietario"> <id name="id" column="id" type="integer"> < generator class="assigned"/>

</id> <property name="nome" column="nome" type="string"/>

</class>

</hibernate-mapping>

Código Fonte 8: Arquivo XML de mapeamento da classe proprietário

36

<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate Mapping DTD 3.0//EN"

"hibernate-mapping-3.0.dtd">

<hibernate-mapping> <class name="Veiculo" table="veiculo"> <id name="placa" column="placa" type="string"> < generator class="assigned"/>

</id> <property name="modelo" column="modelo" type="string"/> <one-to-many name="proprietario" column="id" class="Proprietario"/>

</class>

</hibernate-mapping>

Código Fonte 9: Arquivo XML de mapeamento da classe veículo

Na tag <class> o parâmetro “name” recebe o nome da classe a ser mapeada e o parâmetro “table” o nome da tabela correspondente no banco de dados. Na tag <id> o parâmetro “name” indica o nome do atributo chave correspondente ao objeto, o parâmetro “column” indica o nome da coluna na tabela e o parâmetro “type” o tipo do dado. O mesmo vale para a tag <property>. Outra característica neste caso é o relacionamento que também deve estar configurado no banco. Ele é informado ao Hibernate pela tag <one-to-many> que consiste em:

“name”: nome da tabela;

“column” nome da coluna referência

“class” classe correspondente ao objeto com o qual o item vai se relacionar. Outras variantes desta tag são <one-to-one> e <many to many>

Uma vez mapeado o objeto, as operações podem ser realizadas pelos comandos:

37

public class crud(){

private SessionFactory factory;

HibernateUtility

public crud throws Exception{ factory = p.getSession ();

p
p

= new HibernateUtility();

}

public void UsInserir(Proprietario prop) throws Exception { Session session = factory.openSession(); session.save(prop); session.flush(); session.close();

}

public void UsAlterar(Proprietario prop) throws Exception { Session session = factory.openSession(); session.update(prop); session.flush(); session.close();

}

public void UsExcluir(Proprietario prop) throws Exception { Session session = factory.openSession(); Session.delete(us); session.flush(); session.close();

}

public Usuario UsRecuperar(Proprietario prop) throws Exception { Session session = factory.openSession(); Usuario us = session.load(prop, prop.getId); session.flush(); session.close(); return prop;

}

}

Código Fonte 10: Operações de CRUD via Hibernate

Apesar da complexidade em mapear os dados e a conexão em arquivos XML, a classe final, responsável por manipular os dados no banco se torna muito simples e compacta.

5.1.3. DB4o (orientado à objeto)

Assim como no modelo relacional, no modelo orientado à objeto é necessário haver uma classe de conexão com o banco de dados, que se mostra muito similar.

38

import com.db4o.Db4o; import com.db4o.ObjectContainer;

public class Main { public static void main(String[] args) { Integer porta = 8000; String usuario= "user"; String senha = "123"; ObjectContainer db = Db4o.openServer("//localhost/banco.yap", porta);

db.grantAccess(usuario,senha); try {

// algum código db4o } finally { db.close();

}

}

Código Fonte 11: Classe de conexão com bando de dados OO

No comando “Db4o.openServer()” deve se informar o endereço do banco e a porta onde o serviço está executado, enquanto no comando “db.grantAccess()” é informado o usuário e a senha do banco. Entretanto aqui é possível verificar a primeira diferença. É necessário alterar a classe proprietário para definir o relacionamento, pois como não existem tabelas neste modelo de banco de dados, os relacionamentos ocorrem diretamente nos objetos. Portanto é preciso que a classe proprietário contenha um atributo chamado veículo, e como o relacionamento é do tipo 1:N, o atributo veículo deve ser um array, logo nossa classe ficará assim:

39

public class Proprietario { private int id = 0; private String nome = null; private ArrayList<Veiculo> veic = null;

public Proprietario(int id, String nome) { this.id = id; this.nome = nome;

}

public int getId() { return id;

}

public void setId(int id) { this.id = id;

}

public String getNome() { return nome;

}

public void setNome(String nome) { this.nome = nome;

}

public Veiculo getVeic(int index) { return veic.get(index);

}

public void setVeic(Veiculo vei) { veic.add(vei);

}

}

Código Fonte 12: Classe cliente relacionada coma classe veiculo

No DB4o, as operações de CRUD tornam-se ainda mais simples, bastando apenas informar o objeto a sofrer a operação. Como este banco de dados possui um mecanismo de serialização de objetos, ele garante a unicidade dos objetos, para no caso de uma exclusão ou alteração ser executada no objeto correto, mesmo que em termos de conteúdo existam objetos similares.

40

public class Perssist { private ObjectContainer db = Db4o.openFile("c:/guerra.yap");

public salvar(Cliente cli) { db.set(cli);

}

public update(Cliente cli) { ObjectSet<Cliente> lista = db.get(obter( new Cliente (777,"Maria")));

Cliente cliente = lista.next(); cliente.setNome("Maria José"); db.set(cliente);

}

public delete(Cliente cli) { ObjectSet<Cliente> lista = db.get(obter (new Cliente (777,"Maria")));

Cliente cliente = lista.next(); cliente.setNome("Maria José"); db.delete(cliente);

}

public Cliente obter(Cliente cli) { Query query = db.query(); query.constrain(Cliente.class); query.descend("codigo").constrain( cli.getId_cliente()).smaller(); ObjectSet<Cliente> lista = query.execute(); while (lista.hasNext()){ return lista.next();

}

}

}

Código Fonte 13: Operações de CRUD via DB4o.

5.2. Índices e chaves

Índice é um roteiro ordenado, alfabético ou sistemático, dos itens de uma coleção. Pode ser também o conteúdo de um documento, acompanhado de referenciais que permitem a identificação e localização do próprio conteúdo. O índice é um mecanismo auxiliar, usado no armazenamento, busca e recuperação da informação. Pense assim: quando você quer achar um tópico de um livro, você o folheia todo até achar ou procura no índice? (se ficou com a primeira opção é porque o livro é pequeno e bem conhecido - isso nem sempre acontece com seu banco de dados). Logo, em um banco de dados o índice é igual qualquer outro índice, o banco "organiza" o conteúdo de determinadas colunas (ou todas) para facilitar a busca. Resumindo, o Índice é um arquivo auxiliar associado a uma Tabela. Sua função é acelerar o tempo de acesso às linhas de uma Tabela, cria ponteiros para os dados armazenados em colunas especificas. O Banco de dados usa o índice de maneira semelhante ao índice remissivo de um livro, verifica um determinado assunto no Índice e depois localiza a sua posição em uma determinada página.

41

Nesse contexto, quando se fala em chaves (primaria ou estrangeira), nada mais é que um índice único, não nulo (no caso de chave primaria) ou um índice de outra tabela (chave estrangeira)

5.2.1. PostgreSQL

Como mencionado acima, num banco de dados relacional o índice auxilia na recuperação de dados, melhorando significativamente no desempenho do banco. Ou seja, é implementado tal como sua definição, aplicando-se também para chaves primarias e estrangeiras.

CREATE TABLE nome_tabela ( campo1 <tipo> NOT NULL, campo2 <tipo> NOT NULL, campoX <tipo>, PRIMARY KEY (campo1, campo2)

);

Código Fonte 14: exemplo de declaração de chave primaria

5.2.2. Hibernate

No hibernate, o conceito de índice e chaves deve ser implementado diretamente no banco de dados, uma vez que o hibernate apenas faz o mapeamento objeto relacional.

5.2.3. BD4o

Segundo Rogério Weinert (2008)

Antes de mais nada, a visão relacional em um ambiente orientado a objetos não é aplicável, pois no caso de um SGBDOO cada objeto é único.

Num SGDBOO é implementado do conceito de UUID´s (Universal Unique ID) que são na realidade um objeto associado a cada objeto que existe no banco e sendo muito mais "fortes" que as ID´s, pois indicam ao SGDOO a real unicidade de um objeto. Como dito anteriormente uma chave primaria é um índice único e não nulo, e não deve ser confundido com uma “sequence” implantada junto a essa chave. Por exemplo, no DB4o esta “sequence” deve ser implantada no código fonte da aplicação, mas deve-se ter em mente que o DB4O "conhece" cada objeto dentro do banco, independente da chave customizada que eles contenham. Podem até existir dois objetos com a mesma chave, o DB4O consegue diferenciar os dois. Para se criar um índice no DB40, tendo por base o código fonte 2 desta apresentação teremos:

42

Db4o.Configure().ObjectClass(typeof(Proprietario)).ObjectField("Nome").Indexed(true);

O inconveniente fica pelo fato da aplicação também ter que garantir a unicidade do

objeto sempre que preciso.

5.3. Procedures e Triggers

Procedure é uma coleção de comandos em SQL para gerenciamento de Banco de dados. Encapsula tarefas repetitivas, aceita parâmetros de entrada e retorna um valor de status (para indicar aceitação ou falha na execução). O procedimento armazenado pode reduzir o tráfego na rede, melhorar a desempenho, criar mecanismos de segurança, etc. Já uma trigger é um recurso de programação que sempre é acionado a ocorrência de um evento, é muito utilizada para ajudar a manter a consistência dos dados ou para propagar alterações em um determinado dado de uma tabela para outras. Um bom exemplo é uma trigger criada para controle de quem alterou a tabela. Nesse caso, quando a alteração for efetuada, a trigger é disparada e grava em uma tabela de histórico de alteração, o usuário e data/hora da alteração. Atualmente os SGDBOO não têm implantada essa característica, ficando por conta do programador integrar as funções necessárias ao seu projeto.

5.4. Desempenho

O teste abaixo visa de forma simples demonstrar os resultados de desempenho dos

modelos de persistência de dados.

5.4.1. Ambiente

Para o teste de desempenho foi utilizado o seguinte ambiente:

Notebook Itautec®;

Processador Intel® Celeron M 1,6Ghz;

1,43GB memória RAM;

Windows XP® Home SP3;

SGDB’s conforme proposto no capitulo 1 subseção 2;

5.4.2. Metodologia

Passo 1: - Foram implementados os objetos conforme descritos nos códigos fontes ao longo desta monografia; Passo 2: - Elaborada função que realizava automaticamente operações de inserção, deleção, update e consulta repetidamente por 1000 vezes cada uma, tendo seus tempos totalizados em seguida;

43

Passo 3: - Repetição da operação por 3 vezes, e obtenção do tempo médio de cada uma das três metodologias de implementação;

5.4.3. Resultados

Metodologia

SGBD / Framework

Tempo médio

(s)

Relacional

PostgreSQL

0,38

Framework

Hibernate

0,59

Orientado à objeto

DB4o

0,34

Tabela 2: Comparativo entre implementações

Inicialmente deve-se observar que os métodos foram desenvolvidos pelo autor desta apresentação com base em analise estatísticas, entretanto deve-se levar em conta o fato de que em ambientes diferentes os resultados podem e devem variar. Analisando a tabela 2 pode-se constatar certo equilíbrio entre o SGBDR e o SGBDOO, entretanto o uso do framework demonstrou uma queda no desempenho, uma vez que se trata da implementação de uma camada extra, o que resulta em varias conversões, mapeamentos e consultas realizados antes da operação propriamente dita.

44

6. RESULTADOS OBTIDOS

O framework se mostra útil para aproximar o modelo relacional do modelo orientado a objeto, sem muitos ganhos no quesito desenvolvimento, mas mostrando força imensa quando de migra de um serviço de banco de dados relacional para outro. Neste caso, basta uma pequena configuração no arquivo descrito no código fonte 6 e nada mais, uma vez que o framework é o responsável por gerenciar a persistência, sua aplicação não apresenta necessidade de manutenções no caso de uma migração na base de dados. Outro ponto é a simplicidade com que o modelo orientado à objeto trabalha com os objetos, sem a necessidade de configurar um banco de dados ou mesmo os vários arquivos de mapeamento do framework. Tratando os objetos de uma maneira transparente ao programador, respeitando todas as características do objeto, reduzindo assim muito o tempo de desenvolvimento. Logo as tecnologias estudadas, com base na metodologia usada, não presentearam nenhuma característica que a tornasse uma melhor escolha em detrimento à outra, mas sempre é recomendada uma análise profunda do projeto. Num exemplo mais simples um controle de clientes pode ser feito tanto no modelo relacional quanto no modelo orientado a objeto, mas:

Quando se busca facilidade em controlar integridade é preferível o modelo relacional;

Quando a preocupação for posteriores migrações na base de dados, o framework é uma ótima alternativa;

Caso o desejo seja simplicidade de desenvolvimento é melhor o modelo orientado a objeto. Para finalizar, pode-se observar que todas as metodologias de implementação são muito boas. Além disso, possuem recursos e vantagens que se complementam, o que significa que, para a maioria das aplicações, todas podem ser usadas. Na verdade, o correto não é tentar descobrir qual é a melhor, mas em que situação uma ou outra deve ser utilizada. Portanto deve-se entender bem quais recursos sua aplicação precisa, tentado estimar o volume de dados, o hardware disponível, e as funcionalidades necessárias. Todavia, há situações em que todas as metodologias serão boas escolhas. Nesses casos, é recomendável fazer testes e avaliar qual oferece mais vantagens à aplicação. Um banco de dados pode ser a diferença entre ter e não ter um negócio seja ele de qualquer porte. Por isso, a escolha deve ser bem feita e aspectos como desempenho, recursos, documentação e suporte devem ser considerados. A seguir temos uma tabela comparativa com as principais características apresentadas por cada modelo de implementação.

45

6.1. Comparativo de características

   

Modelo de Implementação

 

Característica

Relacional

 

Framework

 

Orientado a Objeto

 

CRUD

SQL;

Mapeamento;

 

Comandos próprios;

 

Relacionamentos

Conceito de chaves estrangeiras;

 

Chaves mapeadas;

 

Mesmo das linguagens OO;

   

As

configurações

iniciais

 

Não elimina o uso de SQL;

 

dependem

de

mapeamento

de

Simplicidade de

 

objetos;

 

Maior integração com a linguagem utilizada;

Implementação

Depende

do

driver

de

conexão

 

utilizado;

 

Não elimina a programação direta no banco de dados;

 
 

São

implementadas

diretamente

 

É

implementada

na

própria

Triggers

no banco;

 

Não

trigger,

estas

são

aplicação;

 

Utiliza

a

capacidade

e

implementadas do SGBD;

Seu

desempenho

depende

da

desempenho do servidor de DB

 

estrutura utilizada pela aplicação

Índices

Possui

índices, com

a

Não

índices,

estes

são

índices,

mas

não

existes

possibilidade do índice único

implementadas do SGBD;

índices únicos;

 

Material de

Facilmente encontrado;

 

Tão

disponível

quanto

sua

Material escasso

 

Consulta

 

aceitação de mercado;

 

Tabela 3: Comparativo entre modelos de implementação

46

7.

BIBLIOGRAFIA

NASSU, Eugenio A.; SETZER, Valdemar W. Banco de dados Orientados a Objetos. São Paulo: Edgard Blucher, 1999. 136p

DATE, C. J. Uma Introdução a Sistemas de Banco de Dados. São Paulo: Edgard Blucher, 1999. 896p.

BAUER, Christian; KING, Gavin. Hibernate em Ação. São Paulo: Ciência Moderna, 2005. 560p

FAYAD, Mohamed; SCHIMIDT, Douglas C. Object-oriented application frameworks , New York, ACM, 1997 38p.

MONTEIRO, Eduarod. Db4o: Banco OO. Disponível via URL em:

http://imasters.uol.com.br/artigo/5056/bancodedados/db4o_banco_oo. Acesso em:

13 de abr. de 2008.

GUERRA, Gláucio. DB4Objects na terra de gigantes do BD relacional com Java. Disponível via URL em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=4121. Acesso em: 27 de abr. de 2008.

DB4Objects – parte II – mãos a obra. Disponível via URL em:

http://www.devmedia.com.br/articles/viewcomp.asp?comp=4137&hl=*db4o*. Acesso em: 27 de abr. de 2008.

DB4Objects – parte III: Armazenando objetos relacionados. Disponível via URL em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=4323&hl=*db4o*. Acesso em: 27 de abr. de 2008.

DB4Objects na prática – parte IV: Aplicação embedded server. Disponível via URL em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=4495&hl=*db4o*. Acesso em: 27 de abr. de 2008.

MAIA, Italo M. C. DB4Objects na DB4O – Um BD com estilo!. Disponível via URL em:

http://www.db4o.com/portugues/guj-db4o.pdf. Acesso em: 27 de abr. de 2008.

47

LINHARES, Mauricio. Introdução ao Hibernate 3. Disponível via URL em:

www.guj.com.br/content/articles/hibernate/intruducao_hibernate3_guj.pdf. Acesso em 27 abr. de 2008.

MARINHEIRO, Wellington. Tutorial Hibenate. Disponível via URL em:

http://www.livramento.yu.com.br/Hibernate.html. Acesso em: 01 de mai. de 2008.

CARVALHO, Marcio Santos. Persistindo Objetos com Java, Hibernate e PostgreSQL.

Disponível via URL em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=4149.

Acesso em: 01 de mai. de 2008.

ROQUE,

http://www.plugmasters.com.br/sys/materias/476/1/UML---Que-raios-%E9-isso%3F. Acesso

em: 03 de mai. de 2008.

em:

Bruno.

UML

-

Que

raios

é

isso?.

Disponível

via

URL

SUN MICROSYSTENS. JDBC Introduction. Disponível via URL em:

http://java.sun.com/docs/books/tutorial/jdbc/overview/index.html. Acesso em: 03 de mai. de

2008.

BORBA, Sueli de Fátima Poppi. Metodologia Para Implantação De Modelos

Multidimensionais Em Banco De Dados Orientado A Objetos. 2006. 228f. Tese

(Doutorado em Engenharia de Produção) - Universidade Federal de Santa Catarina,

Florianópolis.

OLIVEIRA, Lucas Gonçalves. Construção de um sistema de Blackboard para gestão de

documentos usando XML. 2004. 81f. Tese (Conclusão de Curso em Sistemas de

informação) – Pontifícia Universidade Católica de Minas Gerais, Arcos.

The PostgreSQL Global Development Group. Manual de Referência do PostgreSQL 7.3.2.

Tradução. Traduzido por Halley Pacheco de Oliveira. 1996. 334p

DEITEL, H.M; DEITEL P.J. Java: Como programar. 4 ª Ed. Porto Alegre: Bookman, 2003.

893p.

JANDL, Peter J. Introdução ao Java. São Paulo: Berkeley, 2002. 492p.

SUN Microsystems. Java API Documentation. Disponível via URL em:

http://java.sun.com/javase/6/docs/. Acesso em: 01 de mai. De 2008.