Visualizar - Polis Educacional

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
Monografia
apresentada
à
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.
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 objeto. ......................... 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 5.3. Procedures e Triggers .................................................................................... 42 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 DB4o. ...................................................... 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-dedados-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 “opensource”, 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
Testes
OK
OK
Correção de Divergências
OK
OK
OK
OK
Coleta de resultados preliminares
Compilação do relatório inicial
OK
OK
OK
OK
Análise dos Resultados
OK
OK
Entrega do trabalho
Tabela 1: Cronograma de atividades
OK
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.
Ilustração 1: Exemplo de relacionamento
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.
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.
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.
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,
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.
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
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/bancode-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 JDBCODBC, 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'...) VALUES
('valor1','valor2','valor3'...);
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){
super();
this.id = id;
this.nome = nome;
}
public Veiculo(String placa,
String modelo){
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:
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;
•
“Hibernate.connection.driver_class”: Corresponde ao nome do driver
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;
3. E por fim as tag <mapping resource> que indicam os arquivos XML onde estão
mapeados os objetos a serem persistidos.
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 p = new HibernateUtility();
public crud throws Exception{
factory = p.getSession();
}
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
Tempo médio
Metodologia
SGBD / Framework
Relacional
PostgreSQL
0,38
Framework
Hibernate
0,59
Orientado à objeto
DB4o
0,34
(s)
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
9
SQL;
9
Mapeamento;
9
Comandos próprios;
Relacionamentos
9
Conceito de chaves estrangeiras;
9
Chaves mapeadas;
9
Mesmo das linguagens OO;
9
As
9
Maior integração com a linguagem
9
Não elimina o uso de SQL;
iniciais
dependem de mapeamento de
Simplicidade de
Implementação
configurações
objetos;
9
Depende do driver de conexão
utilizada;
9
utilizado;
Não elimina a programação direta
no banco de dados;
9
no banco;
9
Triggers
9
9
São implementadas diretamente
Utiliza
a
capacidade
Não
há
trigger,
estas
9
desempenho do servidor de DB
Índices
Material de
Consulta
9
Possui
índices,
com
Facilmente encontrado;
na
própria
Seu
desempenho
depende
da
estrutura utilizada pela aplicação
a 9
possibilidade do índice único
9
implementada
aplicação;
são
implementadas do SGBD;
e
É
Não
há
índices,
estes
são 9
implementadas do SGBD;
9
Tão
disponível
quanto
Há
índices,
mas
índices únicos;
sua
aceitação de mercado;
Tabela 3: Comparativo entre modelos de implementação
9
Material escasso
não
existes
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,
Bruno.
UML
-
Que
raios
é
isso?.
Disponível
via
URL
em:
http://www.plugmasters.com.br/sys/materias/476/1/UML---Que-raios-%E9-isso%3F. Acesso
em: 03 de mai. de 2008.
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
http://java.sun.com/javase/6/docs/. Acesso em: 01 de mai. De 2008.
via
URL
em: