Carolina Fernanda da Silva R.A.

: 0402013

ANLISE E AVALIAO DO FRAMEWORK HIBERNATE EM UMA APLICAO CLIENTE/SERVIDOR.

Jaguarina 2007

Carolina Fernanda da Silva R.A.: 0402013

ANLISE E AVALIAO DO FRAMEWORK HIBERNATE EM UMA APLICAO CLIENTE/SERVIDOR.

Monografia apresentada disciplina Trabalho de Concluso de Cincia da Computao da Faculdade de Jaguarina, sob a orientao do Professor Ms. Ricardo Menezes Salgado, como exigncia parcial para obteno do grau de Bacharel em Cincia da Computao.

Jaguarina 2007

SILVA, Carolina Fernanda. Anlise e Avaliao do Framework Hibernate em uma Aplicao Cliente/Servidor. Monografia defendida e aprovada na FAJ em 11 de Dezembro de 2007 pela banca examinadora constituda pelos professores:

Prof. Ms. Ricardo Menezes Salgado FAJ - Orientador

Prof. Ms. Fernando Augusto Zancheta FAJ

Prof. Paula Saretta FAJ

SILVA, Carolina Fernanda. Anlise e Avaliao do Framework Hibernate em uma Aplicao Cliente/Servidor. 2007. Monografia (Bacharelado em Cincia da Computao) - Cincia da Computao, Jaguarina.

RESUMO

O modelo de programao orientado a objetos e o modelo relacional de banco de dados se destacam no mercado atual, porm necessria uma compatibilidade entre esses modelos, um processo de converso chamado mapeamento objeto-relacional. Realizar esse mapeamento de forma manual muito trabalhoso, por outro lado existem ferramentas que automatizam essa tarefa. O sistema Hibernate estreitamento entre a tecnologia relacional e orientada a promove um garantindo objetos

interdependncia de bancos de dados relacionais e proporcionando uma reduo de esforo do desenvolvedor em suas tarefas de persistncia de dados. Nesse trabalho so abordadas tcnicas de mapeamento, assim como as funcionalidades do framework Hibernate, apresentando suas vantagens e desvantagens no seu uso na camada de persistncia. O Hibernate cria uma camada independente, no sendo necessrio alterar a aplicao em casos de eventuais migraes ou mudana de banco de dados. A sua utilizao transparente, dispensando o desenvolvedor do aprendizado de sintaxe e comandos SQL, ocorrendo a reduo significativa de esforo, prazo, custo e manuteno, aumentando assim a produtividade.

Palavras-chave: Hibernate, Banco de dados Relacionais, Mapeamento objeto/relacional.

SUMRIO
LISTA DE FIGURAS...................................................................................................................... 6 1 2 3 4 INTRODUO .................................................................................................................... 10 1.1 MOTIVAO .................................................................................................................. 12 OBJETIVO .......................................................................................................................... 13 METODOLOGIA ................................................................................................................. 13 3.1 PLANO DE TESTES ......................................................................................................... 13 ARQUITETURA EM CAMADAS ......................................................................................... 16 4.1 EVOLUO DOS MODELOS DE PERSISTNCIA DE OBJETOS .................................................. 19 4.1.1 Requisitos de uma Camada de Persistncia ....................................................... 20 5 6 SQL..................................................................................................................................... 22 BANCO DE DADOS............................................................................................................ 26 6.1 SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS ......................................................... 26 6.2 BANCO DE DADOS RELACIONAIS ..................................................................................... 28 6.2.1 Tabela ................................................................................................................ 29 6.2.2 Atributo ............................................................................................................... 29 6.2.3 Chaves ............................................................................................................... 29 6.2.4 Vises................................................................................................................. 29 6.2.5 Seqncias......................................................................................................... 30 6.2.6 Unidades de Programa ....................................................................................... 30 6.2.7 ndices ................................................................................................................ 30 6.3 NORMALIZAO............................................................................................................. 30 6.4 MODELAGEM DE DADOS ................................................................................................. 31 6.5 TCNICAS DE MAPEAMENTO ............................................................................................ 33 6.5.1 Mapeando objetos para Tabelas ......................................................................... 36 6.5.2 Mapeando atributos ............................................................................................ 36 6.5.3 Mapeamento de Relacionamentos ...................................................................... 36 6.6 BANCO DE DADOS ORIENTADO A OBJETOS ........................................................................ 38 6.6.1 Linguagem orientada a objeto ............................................................................. 39 6.6.2 Linguagens de programao persistentes ........................................................... 40 6.6.3 Persistncia de objetos ....................................................................................... 40 6.7 BANCOS DE DADOS RELACIONAIS-OBJETO ........................................................................ 41 7 HIBERNATE ....................................................................................................................... 42 7.1 7.2 7.3 7.4 8 8.1 8.2 9 10 INCOMPATIBILIDADE DE PARADIGMA ................................................................................. 44 MAPEAMENTO OBJETO-RELACIONAL ................................................................................ 47 INTERFACES.................................................................................................................. 51 HQL ............................................................................................................................ 56 ANLISE DE BANCO DE DADOS......................................................................................... 83 ANLISE DE TEMPO ........................................................................................................ 86 REFERNCIAS BIBLIOGRFICAS................................................................................ 98

ESTUDO DE CASOS .......................................................................................................... 57

CONCLUSO ..................................................................................................................... 96

LISTA DE FIGURAS Figura 1: Arquitetura em camadas..................................................................................14 Figura 2: Arquitetura do Hibernate..................................................................................48 Figura 3: Ciclo de vida.....................................................................................................51 Figura 4: Modelagem do banco de dados.......................................................................54 Figura 5: Estrutura do Projeto..........................................................................................55 Figura 6: Classes Entidades Hibernate........................................................................59 Figura 7: Estrutura do projeto JDBC................................................................................60 Figura 8: Classes Entidades JDBC..............................................................................61 Figura 9: Arquivos para conexes em banco de dados distintos....................................65 Figura 10: Arquivo para conexes em banco de dados..................................................66 Figura 11: Classe DAO projeto Hibernate....................................................................68 Figura 12: Classe DAO projeto JDBC..........................................................................72 Figura 13: SinRegional....................................................................................................73 Figura 14: SistTransmissao.............................................................................................74 Figura 15: Barramentos...................................................................................................75 Figura 16: Cargas............................................................................................................76 Figura 17: Datas..............................................................................................................77 Figura 18: Climatica.........................................................................................................78 Figura 19: Grfico MySQL...............................................................................................79 Figura 20: Relatrio MySQL............................................................................................80 Figura 21: Grfico PostgreSQL.......................................................................................80 Figura 22: Relatrio PostgreSQL.....................................................................................81 Quadro 1: Classe SinRegional utilizando anotaes.......................................................56 Quadro 2: Classe SistTransmissao utilizando anotaes...............................................56

Quadro 3: Classe SistTransmissaoPK............................................................................56 Quadro 4: Classe SinRegional........................................................................................60 Quadro 5: Classe SistTransmissao.................................................................................60 Quadro 6: Arquivo de configurao utilizando o banco de dados PostgreSQL..............61 Quadro 7: Arquivo de configurao utilizando o banco de dados MySQL......................62 Quadro 8: Classe de conexo usando Hibernate ...........................................................64 Quadro 9: Classe de conexo usando JDBC..................................................................65 Quadro 10: Classe DAO utilizando Hibernate.................................................................66 Quadro 11: Classe DAO da tabela sinRegional utilizando SQL......................................68 Tabela 1: Comparativo entre tcnicas de mapeamento de classes................................32 Tabela 2: Comparativo entre sistemas de bancos de dados...........................................38 Tabela 3: Mecanismo de gerao de chaves primrias..................................................42 Tabela 4: Dialetos do Hibernate......................................................................................63 Tabela 5: Consultas MySQL, terceiro plano de testes....................................................82 Tabela 6: Consultas MySQL, quarto plano de testes......................................................83 Tabela 7: Consultas PostgreSQL, terceiro plano de teste...............................................85 Tabela 8: Consultas PostgreSQL, quarto plano de teste................................................86 Tabela 9: Testes de Incluso...........................................................................................88 Tabela 10: Testes de Excluso.......................................................................................90 Grfico 1: Mdia tempo de consultas MySQL, terceiro plano de teste............................84 Grfico 2: Mdia tempo de consultas MySQL, quarto plano de teste.............................84 Grfico 3: Mdia tempo de consultas PostgreSQL, terceiro plano de teste....................87 Grfico 4: Mdia tempo de consultas PostgreSQL, quarto plano de teste......................87 Grfico 5: Mdia tempo de incluso................................................................................89 Grfico 6: Mdia tempo de excluso...............................................................................91

LISTA DE ABREVIATURAS E SIGLAS SQL Structured Query Language JDBC Java Database Connectivity MOR Mapeamento objeto/relacional DBA Administrador de Banco de Dados SGDB Sistema Gerenciador de Banco de Dados XML Extensible Markup Language BDOO Banco de Dados Orientado a Objetos SEQUEL Strutured English Query Language ANSI American National Standards Institute ISSO International Standards Organization DDL Data Definition Language DML Data Manipulation Language DQL Data Query Language DCL Data Control Language 1FN Primeira Forma Normal 2FN Segunda Forma Normal 3FN Terceira Forma Normal 4FN Quarta Forma Normal 5FN Quinta Forma Normal E-R entidade-relacionamento UML Unified Modeling Language API Application Programming Interface HQL Hibernate Query Language J2EE Java 2 Enterprise Edition

JDK Java Development Kit JPA Java Persistence API DAO Data Access Object EJB Enterprise JavaBean JNDI Java Naming and Directory Interface JTA Java Transaction API (JTA)

1 INTRODUO

Na ltima dcada, o modelo de programao, projeto e modelagem orientado a objetos tornou-se o mais avanado modelo de desenvolvimento de software, oferecendo aumento da produtividade, segurana e facilidade de manuteno. A orientao a objetos um padro de sistemas que abstrai a realidade apontando diversas entidades com atributos e operaes comuns a ser automatizado por objetos que abrangem dados e mtodos. Um objeto um conceito, uma abstrao, algo com limites ntidos e significados no contexto do problema em causa (PINHEIRO apud RUMBAUGH,1994). Em paralelo, os bancos de dados relacionais so utilizados para o gerenciamento de grandes volumes de dados e oferece pesquisas rpidas, integridade referencial, compartilhamento de informaes de forma segura e o gerenciamento de acessos. Atualmente, dominam o mercado, pois apresentam uma viso nica, no redundante e resumida dos dados de uma aplicao. A medida que os desenvolvedores dominam os sistemas de gerenciamento de bancos de dados relacionais, compreendem Structured Query Language (SQL), trabalham com tabelas e chaves estrangeiras, os mesmos fazem uso da tcnica mais comum para persistncia de dados em Java, ou seja, trabalham diretamente com SQL e Java Database Connectivity (JDBC). . Contudo, o processo envolvendo o cdigo de persistncia manual trabalhoso,

principalmente quando se trata de diversos dialetos SQL, exigindo maior esforo de desenvolvimento. Sendo assim, se forem modificadas as exigncias, ser necessrio uma maior dedicao e esforo para manuteno. Como banco de dados relacionais caracteriza-se por possuir uma tecnologia mais difundida no gerenciamento de dados apresentando melhor desempenho e segurana, houve o crescimento da demanda por essa tecnologia, pois h a necessidade de ferramentas de suporte a decises, que esto mais presentes nas grandes organizaes. J o sistema de banco de dados orientado a objetos possui desvantagens no mbito de no atender transaes de sistemas legados, alm de aplicaes baseadas em SQL.

10

Dessa maneira, de acordo com Rumbaugh (1994) os sistemas de bancos de dados baseados em objetos prometem melhor desempenho e maior facilidade de uso em longo prazo, porm, eles ainda no esto maduros como os sistemas de bancos de dados relacionais convencionais causando problemas de integrao com as aplicaes convencionais existentes. Sendo assim, existe uma forte tendncia de utilizao de bancos de dados relacionais para armazenamento dos objetos de aplicaes orientadas a objetos. Contudo, existem diferenas significativas do paradigma orientado a objetos para o modelo relacional. Para que seja possvel obter os benefcios de ambos, necessria uma compatibilidade entre esses modelos. A aplicao passa a necessitar de um processo intermedirio de converso. O mapeamento objeto-relacional uma tcnica de desenvolvimento para reduzir as diferenas potenciais entre as tecnologias orientadas a objetos utilizando bancos de dados relacionais. Realizar este mapeamento de forma manual muito custoso e dedica muito tempo na construo e manuteno. Por outro lado, existem ferramentas que automatizam essa tarefa, promovendo um estreitamento entre as tecnologias. Utilizando-se como meio de armazenamento o banco de dados relacional dentro de uma arquitetura adotando a persistncia de objetos, a mesma ter de possuir uma interligao para traduzir o modelo orientado a objeto para um modelo relacional em razo das divergncias de representao desses modelos. J persistncia a habilidade de um objeto sobreviver ao ciclo de vida do processo no qual ele reside (DAIBERT apud KELLER, 2004). A persistncia do objeto pode ser considerada transparente, pois o desenvolvedor produz operaes de manipulao de dados de objetos em sua programao sem notar que h uma arquitetura promovendo funcionalidades no decorrer dessas manipulaes. Esse processo permite o cdigo limpo, livre de mapeamentos e funes que no pertencem ao seu escopo. O conjunto de funcionalidades da persistncia deve se restringir apenas a operaes de incluso, atualizao, consulta e excluso. O modelo relacional o mais utilizado na representao e compreenso dos dados que integram um sistema de informaes. No desenvolvimento de aplicaes em banco de dados a modelagem dos mesmos proporciona uma viso concisa e compacta em uma aplicao. O mapeamento o ato de se determinar como os objetos e seus relacionamentos so persistidos em um mecanismo de armazenamento de dados permanente seguindo um modelo relacional (PINHEIRO apud AMBLER, 2000). O mapeamento objeto/relacional (MOR) constri uma ponte entre o objeto e schemas relacionais, permitindo que a

11

aplicao persista objetos diretamente fazendo a converso de objetos em um formato relacional, ou seja, trabalha por reversibilidade transformando dados de uma representao para outra. De acordo com Bauer e King (2005, p. 39), MOR no uma bala prateada para toda a tarefa de persistncia; seu trabalho aliviar o desenvolvedor de 95 por cento de trabalho de persistncia de objeto. Segundo Ambler 2007, o mapeamento objeto/relacional permite que os desenvolvedores de sistemas se concentrem no que fazem de melhor, ou seja, desenvolver aplicaes sem ter a preocupao sobre como os objetos sero armazenados. Alm disso, o MOR deve permitir que os administradores de dados (DBAs) administrem bancos de dados desconsiderando a introduo de erros em aplicaes existentes.

1.1 Motivao
Atualmente, os sistemas gerenciadores de bancos de dados (SGBDs) possuem um lugar de destaque se comparados com as tecnologias de armazenamento promovendo confiabilidade e robustez, porm no possuem caractersticas para armazenar objetos. Desse modo, surge a necessidade do mapeamento dos dados onde os mesmos so persistidos de forma correta e ntegra. Esse mapeamento, quando usado no contexto de orientao a objetos, adiciona complexidade extra, necessitando de um processo intermedirio de converso. Segundo Bauer e King (2005), o projeto Hibernate um framework1 que aplica as metodologias de padres de projeto, promovendo um estreitamento entre a tecnologia relacional e orientada a objetos. Alm de possuir cdigo aberto e ter uma comunidade bastante ativa, promovendo interdependncia de bancos de dados relacionais e proporcionando uma reduo de esforo do desenvolvedor em suas tarefas de persistncia de dados.

1 Framework: Conjunto de vrios elementos de programao, com foco numa rea especfica, para resolver problemas computacionais dessa e outras reas correlatas.

12

2 OBJETIVO
Descrever os objetivos, vantagens e desvantagens do Hibernate, realizando a persistncia de objetos em diferentes SGBDs, apresentando os aspectos de sua arquitetura a fim de conhecer seu papel dentro de aplicaes desenvolvidas no paradigma orientado a objetos. A meta unir tecnologia de desenvolvimento de softwares baseados na orientao a objetos com a tecnologia de armazenamento de dados relacional proporcionando transparncia aos desenvolvedores na manipulao de informaes de objetos em um mecanismo de persistncia. Foram implementados dois softwares de leitura, insero e atualizao de dados de carga eltrica ativa em base horria (MW/h) medidos em vrios pontos de uma empresa distribuidora da regio nordeste do Brasil.

3 METODOLOGIA
Para realizar os testes de desempenho nos bancos de dados, foi utilizada a ferramenta Apache JMeter, permitindo a anlise e visualizao das estatsticas por meio de grficos. Segundo Fonseca, o JMeter permite simular uma carga pesada de usurios em uma rede, com o objeto dos testes de analisar o desempenho total sob tipos diferentes da carga. Tem como objetivo realizar testes de caixa cinza e preta, executando testes de stress, validando requisitos no funcionais do software.

3.1 Plano de testes

Primeiro plano de teste Simulao de dez usurios conectados ao banco MySQL; A operao SQL relacionada foi executada dentro de um loop em 100 vezes; Cada usurio realizou 5 requisies, citada abaixo:

SELECT * FROM Cargas;

13

A tabela foi populada com a seguinte quantidade de dados: Cargas Segundo plano de teste Simulao de dez usurios conectados ao banco PostgreSQL; A operao SQL relacionada foi executada dentro de um loop em 100 vezes; Cada usurio realizou 5 requisies, citada abaixo: 500 linhas

SELECT * FROM Cargas; A tabela foi populada com a seguinte quantidade de dados: Cargas 500 linhas

Terceiro plano de teste A simulao foi realizada em ambos os SGBDs; A consulta foi executada dentro de um loop de 100 vezes; Foram realizadas as seguintes consultas: Consulta uma tabela SELECT * FROM Sin_Regional; Consulta duas tabelas SELECT * FROM Sin_Regional; SELECT * FROM Sist_Transmissao; Consulta quatro tabelas SELECT * FROM Sin_Regional;

14

SELECT * FROM Sist_Transmissao; SELECT * FROM Barramentos; SELECT * FROM Cargas; As tabelas foram populadas com a seguinte quantidade de dados: Sin_Regional Sist_Transmissao Barramentos Cargas 15 linhas 15 linhas 15 linhas 500 linhas

Quarto plano de teste A simulao foi realizada em ambos os SGBDs; A consulta foi executada dentro de um loop de 100 vezes; Foram realizadas as seguintes consultas: Consulta uma tabela SELECT * FROM Sin_Regional; Consulta duas tabelas SELECT * FROM Sin_Regional; SELECT * FROM Sist_Transmissao; Consulta quatro tabelas SELECT * FROM Sin_Regional; SELECT * FROM Sist_Transmissao; SELECT * FROM Barramentos; SELECT * FROM Cargas; As tabelas foram populadas com a seguinte quantidade de dados:

15

Sin_Regional Sist_Transmissao Barramentos Cargas

150 linhas 150 linhas 150 linhas 1000 linhas

Quinto plano de testes A simulao foi realizada em ambos os SGBDs; A consulta foi executada dentro de um loop de 100 vezes; Foi realizada a seguinte incluso: INSERT INTO Cargas VALUES (, 1, 2, 3, 4, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555, 555); Sexto plano de testes A simulao foi realizada em ambos os SGBDs; A consulta foi executada dentro de um loop de 100 vezes; Foi realizada a seguinte excluso: DELETE FROM Cargas WHERE carg_hor1 = 555

4 ARQUITETURA EM CAMADAS
No decorrer dos anos at atualmente, se busca o aprimoramento de padres e tcnicas para o desenvolvimento de sistemas de maior qualidade e manuteno simplificada. Coeso e acoplamento so as tcnicas inicialmente criadas durante o perodo em que se utilizavam sistemas estruturados. Segundo Calado 2006, a coeso agrupa elementos de acordo com sua similaridade. O acoplamento caracteriza-se na independncia de componentes, onde se pode alterar determinado componente, sem que haja danos em outros. De acordo com Calado 2006, o uso de camadas se desenvolve:

16

A aplicao dessas mtricas no est restrita a objetos, trechos de cdigo ou atributos, elas tambm so aplicadas arquitetura de uma aplicao. O uso de Camadas (Layers) um Padro Arquitetural que ajuda na tarefa de separar responsabilidades, promovendo baixo acoplamento e alta coeso em um sistema (Calado, 2006, sem p.).

A camada ser responsvel por agrupar classes, pacotes e componentes com caractersticas em comum. As classes que possuem funo similar sero reunidas em determinada camada, promovendo a coeso e evitando o acoplamento, pois controlada a forma que as camadas se comunicam. De acordo com Calado (2006), o uso de camadas permite uma srie de vantagens, sendo elas: Reduzem complexidade: agrupam componentes e simplificam a comunicao entre eles; Reduzem dependncia/acoplamento: a regra de comunicao evita dependncias diretas entre componentes de camadas diferentes; Favorecem a coeso: componentes de responsabilidades relacionadas so agrupados; Promovem reusabilidade: camadas podem ser reutilizadas em outros sistemas ou podem ser substitudas; um Padro Arquitetural conhecido: facilita a comunicao e entendimento entre desenvolvedores.

Entretanto, encontram-se tambm as desvantagens: Limitadas pela tecnologia: algumas regras precisam ser quebradas por limitaes tecnolgicas; Apenas complicam um sistema muito simples: no qualquer sistema que exige o uso de camadas; Possibilidade de overdose: muitos arquitetos acabam criando camadas demais e tornando a aplicao extremamente complexa.

17

As camadas permitem diversos modos de arranjos, sendo que a quantidade varia de acordo com o tamanho da aplicao e da arquitetura estipulada. Entretanto, com um menor nmero de camadas, o desempenho da aplicao ser melhor, sendo necessrio o equilbrio entre o nmero de camadas utilizadas e sua arquitetura para obter maior manutenibilidade e menores impactos dentro do sistema. Segundo King (2005, p. 23), uma arquitetura de aplicativo tpica, provada, alto-nivelada usa trs camadas, uma para cada apresentao, lgica de negocio e persistncia, como mostra a figura 1.

Figura 1 Arquitetura em camadas (Bauer e King, 2005)

Camada de apresentao (Presentation Layer): a lgica de interface do usurio o ponto mais alto. O cdigo responsvel para a apresentao e controle de pgina e tela de navegao forma a camada de apresentao. Camada de negocio (Bussiness Layer): geralmente acordado que esta camada de negcio seja responsvel pela implementao de qualquer regra de negcio ou requerimentos do sistema que seriam entendidos por usurios como parte do problema de domnio.

18

Camada de persistncia (Persistence Layer): caracterizada por um grupo de classes e componentes responsveis pela memria de dados e sua recuperao, um ou mais armazenamento de dados. Esta camada necessariamente inclui um modelo das entidades de domnio de negocio.

Banco de dados (Database): o banco de dados existe fora do aplicativo Java. a atual representao persistente do estado de sistema. Se um banco de dados de
SQL for usado, o banco de dados incluir o esquema relacional e procedimentos possivelmente armazenados. Assistente/classes de utilidade (Utility and Helper Classes): todo o aplicativo tem um set de assistente de infra-estrutura ou classes de utilidade que usado em toda camada do aplicativo (por exemplo, classes Exception para tratamento de erros). Esses elementos de infra-estrutura no formam uma camada, desde que eles no obedeam s regras para dependncia entre camadas na arquitetura de camadas.

4.1 Evoluo dos modelos de persistncia de objetos

Buscando rapidez na implementao, os sistemas adotam a incluso de cdigo SQL dentro da lgica, dificultando a manuteno de cdigo e um acoplamento do sistema ao SGDB utilizado. Em caso de qualquer mudana na estrutura das tabelas, todo o cdigo poder ser afetado, sendo assim reescrito. Outra opo colocar o cdigo SQL em classes de acesso a dados, ou seja, separadas das classes da aplicao, como meio de restringir o impacto das mudanas no sistema como um todo trazendo maior controle ao escopo dos possveis erros. A camada de persistncia permite a abstrao de dados, promovendo a interdependncia entre o modelo de objetos e o banco de dados. Permite alteraes na estrutura ou banco de dados sem causar impactos na aplicao, alm de permitir o armazenamento em SGBDs orientados a objetos, objetos relacionais e arquivos Extensible Markup Language (XML). Segundo Jnior, uma camada de persistncia de objetos funciona como uma biblioteca permitindo a realizao do processo de persistncia, de forma transparente. possvel controlar de forma simples o gerenciamento de um modelo de objetos em vrios

19

tipos de repositrios. Fazendo uso dessa concepo, mtodos para incluir, alterar e remover objetos, permite ao desenvolvedor trabalhar como se estivesse em um sistema completamente orientado a objetos. Desse modo de acordo com Jnior 2003, a utilizao de camada de persistncia envolve:
As vantagens decorrentes do uso de uma camada de persistncia no desenvolvimento de aplicaes so evidentes: a sua utilizao isola os acessos realizados diretamente ao banco de dados na aplicao, bem como centraliza os processos de construo de consultas (queries) e operaes de manipulao de dados (insert, update e delete) em uma camada de objetos inacessvel ao programador. Este encapsulamento de responsabilidades garante maior confiabilidade s aplicaes e permite que, em alguns casos, o prprio SGBD ou a estrutura de suas tabelas possam ser modificados, sem trazer impacto aplicao nem forar a reviso e recompilao de cdigos (Jnior, 2003, sem p.).

4.1.1 Requisitos de uma Camada de Persistncia

Uma camada de persistncia real deve implementar as seguintes caractersticas, (JNIOR apud AMBLER 2003): Dar suporte a diversos tipos de mecanismos de persistncia: um mecanismo de persistncia pode ser definido como a estrutura que armazenar os dados - seja ela um SGBD relacional, um arquivo XML ou um banco de dados orientado a objetos (BDOO), por exemplo. Uma camada de persistncia deve suportar a substituio deste mecanismo livremente e permitir a gravao de estado de objetos em qualquer um destes meios. Encapsulamento completo da camada de dados: o usurio do sistema de persistncia de dados deve utilizar-se, no mximo, de mensagens de alto nvel como save ou delete para lidar com a persistncia dos objetos, deixando o tratamento destas mensagens para a camada de persistncia em si.

20

Aes com multi-objetos: suportar listas de objetos sendo instanciadas e retornadas da base de dados deve ser um item comum para qualquer implementao, tendo em vista a freqncia desta situao. Transaes: ao utilizar-se da camada de persistncia, o programador deve ser capaz de controlar o fluxo da transao - ou ter garantias sobre o mesmo, caso a prpria camada de persistncia preste este controle. Extensibilidade: a camada de persistncia deve permitir a adio de novas classes ao esquema e a modificao fcil do mecanismo de persistncia. Identificadores de objetos: a implementao de algoritmos de gerao de chaves de identificao garante que a aplicao trabalhar com objetos com identidade nica e sincronizada entre o banco de dados e a aplicao. Cursores e Proxies: as implementaes de servios de persistncia devem ter cincia de que, em muitos casos, os objetos armazenados so muito grandes - e recuper-los por completo a cada consulta no uma boa idia. Tcnicas como o lazy loading (carregamento tardio) utilizam-se dos proxies para garantir que atributos s sero carregados medida que forem importantes para o cliente e do conceito de cursores para manter registro da posio dos objetos no banco de dados (e em suas tabelas especficas). Registros: apesar da idia de trabalhar-se apenas com objetos, as camadas de persistncia devem, no geral, dispor de um mecanismo de recuperao de registros - conjuntos de colunas no encapsuladas na forma de objetos, como resultado de suas consultas. Isto permite integrar as camadas de persistncias a mecanismos de gerao de relatrios que no trabalham com objetos, por exemplo, alm de permitir a recuperao de atributos de diversos objetos relacionados com uma s consulta. Arquiteturas Mltiplas: o suporte a ambientes de programas stand-alone, cenrios onde o banco de dados encontra-se em um servidor central e mesmo arquiteturas mais complexas (em vrias camadas) deve ser inerente camada de persistncia,

21

j que a mesma deve visar a reusabilidade e fcil adaptao a arquiteturas distintas. Diversas verses de banco de dados e fabricantes: a camada de persistncia deve tratar de reconhecer diferenas de recursos, sintaxe e outras mincias existentes no acesso aos bancos de dados suportados, isolando isto do usurio do mecanismo e garantindo portabilidade entre plataformas. Mltiplas conexes: um gerenciamento de conexes (usualmente utilizando-se de pooling) uma tcnica que garante que vrios usurios utilizaro o sistema simultaneamente sem quedas de performance. Queries SQL: apesar do poder trazido pela abstrao em objetos, este mecanismo no funcional em cem por cento dos casos. Para os casos extremos, a camada de persistncia deve prover um mecanismo de queries que permita o acesso direto aos dados - ou ento algum tipo de linguagem de consulta simular SQL, de forma a permitir consultas com um grau de complexidade maior que o comum. Controle de Concorrncia: acesso concorrente a dados pode levar a

inconsistncias. Para prever e evitar problemas decorrentes do acesso simultneo, a camada de persistncia deve prover algum tipo de mecanismo de controle de acesso. Este controle geralmente feito utilizando-se dois nveis - com o travamento pessimstico (pessimistic locking), as linhas no banco de dados relativas ao objeto acessado por um usurio so travadas e tornam-se inacessveis a outros usurios at o mesmo liberar o objeto. No mecanismo otimstico (optimistic locking), toda a edio feita em memria, permitindo que outros usurios venham a modificar o objeto.

5 SQL

Desde o princpio do uso do computador de conhecimento geral que o mesmo tem como funo receber dados, process-los e gerar a sada dos mesmos. Posteriormente surge

22

a necessidade de armazenar esses dados produzidos por computadores, sendo que esse armazenamento e recuperao de informaes tm papel primordial na informtica. A criao da linguagem de banco de dados relacionais, a SQL, foi criada em 1970 com E. F. Codd. Segundo Oliveira (2002 p. 17), Codd estabeleceu princpios sobre gerncia de banco de dados, denominando-os com o termo relacional. Essa foi a base utilizada na criao de uma linguagem-padro para manipular informaes em banco de dados relacionais. Primeiramente denominada Strutured English Query Language (SEQUEL), a SQL fora desenvolvida atravs da IBM, que fez uso dos princpios de Codd. No ano de 1979 surgiu a verso inicial comercial da linguagem SQL. A SQL atualmente encontra-se no patamar de padro para manipulao de dados em banco de dados. A linguagem SQL vem sendo padronizada por duas entidades, a American National Standards Institute (ANSI) e tambm a International Standards Organization (ISSO). Aps vrias modificaes, em 1989 surge a verso que utilizada pelos bancos de dados atuais. Em 1999, surge a SQL-99 que define um padro de banco de dados objeto relacional. A mesma no necessariamente utilizada como padro pelos fabricantes. Grande parte dos bancos de dados usados atualmente atingem somente at o ponto bsico. Ainda que despontem inovaes, a maioria dos bancos de dados ainda se utilizam da verso anterior. Entretanto, h a existncia de comandos de nvel mdio e completo. De acordo com Oliveira, o padro SQL-92 contempla as seguintes modalidades:
Divide-se o padro SQL-92 em quatro nveis: Entry (bsico), (em evoluo), Intermediate (intermedirio) e Full

Transational

(completo). A maior parte dos bancos de dados utilizados atualmente atende ao nvel bsico. Mesmo existindo uma verso mais nova do padro, a maior parte dos bancos de dados ainda utiliza, de forma bsica, o padro anterior. Alguns comandos, contudo, atingem os nveis intermedirios e completo (Oliveira, 2002, p.18).

No modelo relacional a tabela consiste no nico tipo de estrutura de dados existente, sendo possvel a criao de outras tabelas com a juno ou combinao de

23

vrias delas, assim como pesquisar, atualizar ou excluir linhas de tabelas utilizando apenas comandos SQL. Sendo que o SQL no considerado uma linguagem procedural, logo possvel especificar o que deve ser feito e no como deve ser feito. Assim, o comando atinge um conjunto de linhas e no cada uma das linhas somente. Dessa maneira, com o comportamento procedural no necessrio compreender o funcionamento e armazenamento fsico dos dados dentro do banco de dados. Cabe ressaltar que no possvel transferir os comandos SQL de um banco de dados para outro, entretanto, com as devidas adaptaes, a maioria dos comandos poder ser aproveitada, de acordo com o banco de dados utilizado.

O SQL pode ser utilizado de duas maneiras, interativamente ou de forma embutida: Na maneira interativa executam-se comandos diretamente no banco de dados, sendo que a maioria deles possuem ferramentas que permitem a execuo interativa. O usurio digita o comando desejado e imediatamente mostram-se os resultados aps a execuo. Podemos citar o QMF for Windows, ferramenta do banco de dados DB2. Na segunda forma o comando SQL embutido, em linguagens que suportam o SQL, como Cobol, Pascal, Basic, C e outras. Essas linguagens podem ser denominadas de rotinas SQL, que enviam ou recebem parmetros atravs de variveis. Por sua vez, o banco de dados recebe esses parmetros em comandos, executando-os e retornando a informao desejada. De acordo com Oliveira (2002), tanto no modo interativo ou embutido a linguagem dividida em quatro grupos de comandos: Data Definition Language (DDL) : permite a criao de comandos responsveis pela criao de objetos do banco de dados, como tabelas, vises, ndices. Dentre eles:

24

CREATE TABLE ALTER TABLE DROP TABLE CREATE VIEW CREATE INDEX Data Manipulation Language (DML): permite a execuo de comandos para a manipulao dos dados como consultas e alteraes dos dados armazenados no banco de dados. INSERT DELETE UPDATE Data Query Language (DQL): permite extrair dados do banco de dados. SELECT Data Control Language (DCL): so comandos que provem a segurana interna do banco de dados, atribuindo privilgios para usurios acessarem determinados objetos do banco de dados. GRANT REVOKE CREATE USER ALTER USER Com o advento do SQL-99, a linguagem SQL passou a incorporar comandos procedurais (BEGIN, IF, FUNCION, PROCEDURES), ou seja, extenses da linguagem. Essas extenses so especificas de cada banco de dados, podemos citar PL/SQL, que por sua vez uma linguagem procedural do Oracle e o Transact-SQL, do banco de dados SQL Server.

25

6 BANCO DE DADOS
Segundo Oliveira (2002, p. 22), um banco de dados um conjunto coerente e lgico de dados relacionados que possuem significncia intrnseca. Esses dados representam aspectos do mundo real e devem ser mantidos para atender aos requisitos da empresa. Temos outra definio com Date (2000, p. 9), um banco de dados uma coleo de dados persistentes utilizada pelos sistemas de aplicao de uma determinada organizao. De acordo com Oliveira (2002), h cinco tipos de banco de dados: Hierrquico: um gerenciador desse tipo representa dados como uma estrutura de arvore, composto de uma hierarquia de registro de dados. Rede: representa os dados como registros vinculados uns aos outros, formando conjuntos comuns de dados. Relacional: representa os dados como uma simples coleo de linhas e colunas em tabelas bidimensionais. Objeto-relacional: combina o modelo orientado a objetos (unio de propriedades e mtodos) com o modelo relacional (linhas e colunas de tabelas). Objeto: representa os dados e processos em um nico objeto.

6.1 Sistema de Gerenciamento de Banco de dados

Um gerenciador de banco de dados uma coleo de programas que permite criar estruturas, manter dados e gerenciar as transaes efetuadas em tabelas, alm de permitir a extrao das informaes de maneira rpida e segura.

26

Segundo Silberschatz (1999, p. 01), um sistema gerenciador de banco de dados (SGBD) constitudo por um conjunto de dados associados a um conjunto de programas que fornece o acesso a esses dados. O principal objetivo de um SGBD proporcionar um ambiente conveniente e igualmente eficiente para a recuperao e armazenamento das informaes do banco de dados. Os sistemas de banco de dados so projetados para gerir grandes volumes de informaes. O gerenciamento de informaes implica a definio das estruturas de armazenamento e a definio dos mecanismos para a manipulao dessas informaes armazenadas contra eventuais problemas com o sistema, alm de impedir tentativas de acesso no autorizadas. Se os dados so compartilhados por diversos usurios, o sistema deve evitar a ocorrncia de resultados anmalos. Algumas das principais caractersticas de um gerenciador de banco de dados, de acordo com Oliveira (2002): Controle de redundncia: informaes devem possuir um mnimo de redundncia visando estabelecer estabilidade do modelo. Compartilhamento de dados: as informaes devem estar disponveis para qualquer numero de usurios de forma concomitante e segura. Controle de acesso: necessidade de saber quem pode realizar qual funo dentro do banco de dados. Esquematizao: os relacionamentos devem estar armazenados no banco de dados para garantir a facilidade de entendimento e aplicao do modelo. A integridade das informaes deve ser garantida pelo banco de dados. Backup ou cpias de segurana: deve haver rotinas especficas para realizar a cpia de segurana dos dados armazenados.

27

6.2 Banco de Dados Relacionais

Segundo Silberschatz (1999, p. 61), um banco de dados relacional consiste em uma coleo de tabelas, cada uma das quais com um nico nome. Uma linha em uma tabela representa um relacionamento entre um conjunto de valores. Sendo uma tabela um conjunto de relacionamentos, h um estreitamento entre a abordagem tabela e o conceito matemtico de relao, originando assim a nomenclatura desse modelo de dados. O objetivo de um banco de dados relacional armazenar um grupo de objetos em um dicionrio de dados, de forma a tornar rpida e segura a manipulao das informaes contidas nos mesmos. Como objetos, podemos entender tabelas, vises, ndices e at mesmo procedimentos e funes que estejam armazenadas no banco de dados. O modelo relacional contempla trs aspectos: Estruturas As estruturas so objetos bem definidos (tabelas, vises, ndices e assim por diante) que armazenam ou acessam os dados de um banco de dados. Essas estruturas e as informaes podem ser manipuladas por operaes. Operaes As operaes so aes definidas claramente que permitem aos usurios manipular os dados e as estruturas de um banco de dados. Elas devem obedecer a um conjunto predefinido de regras de integridade. Regras de integridade As regras de integridade so as leis que governam as operaes permitidas nos dados e nas estruturas de um banco de dados. Dessa maneira as mesmas protegem os dados e as estruturas de um banco de dados, garantindo integridade e segurana a estrutura.

28

6.2.1 Tabela
Uma tabela pode ser entendida como um conjunto de linhas e colunas. As colunas de uma tabela qualificam cada elemento (no caso, a linha com informaes relacionadas ao objeto).

6.2.2 Atributo
Os atributos so as informaes bsicas que qualificam uma entidade e descrevem seus elementos ou caractersticas. Quando transpostos ao modelo fsico (ao banco de dados), os atributos so denominados de campos ou colunas.

6.2.3 Chaves
As chaves so um conjunto de um ou mais atributos que identificam linhas e estabelecem relaes entra linhas e tabelas de um banco de dados relacional. Chave primria: representada por uma ou mais colunas que so usadas para distinguir das demais linhas de uma tabela. Chave estrangeira: representada por uma ou mais colunas, que por sua vez, so chaves primrias de uma tabela, permitindo a implementao de relacionamentos em um banco de dados relacional.

6.2.4 Vises
Uma viso a representao de uma ou mais tabelas, que tambm pode ser definida como uma consulta armazenada. As vises admitem as operaes bsicas como consultas, inseres, atualizaes e excluso, mas com as devidas restries, ou seja, qualquer das operaes executadas em uma viso, afetar as tabelas bases desta viso.

29

6.2.5 Seqncias
Uma seqncia gera automaticamente valores numricos para as linhas de uma ou mais tabelas, tornando de maneira simplificada a programao do aplicativo.

6.2.6 Unidades de Programa

Funes, triggers, procedures, e blocos annimos se referem unidade de programa. Os procedimentos e funes combinam a facilidade e flexibilidade do SQL funcionalidade de procedimento de uma linguagem de programao estruturada.

6.2.7 ndices
Os ndices podem fazer referncia a uma ou mais colunas e so criados independentemente dos dados. Fazem parte da lgica, portanto, podem ser excludos e criados a qualquer momento. O seu objetivo aumentar o desempenho da recuperao dos dados.

6.3 Normalizao
Segundo Heuser (2004, p. 149), uma forma normal uma regra que deve ser obedecida por uma tabela para que esta seja considerada "bem projetada. Seguem abaixo as definies de formas normais: Primeira forma normal (1FN) - diz-se que uma tabela est na primeira forma normal, quando a mesma no contm tabelas aninhadas, ou seja, nenhum de seus atributos possuem repeties. Segunda forma normal (2FN) - uma tabela encontra-se na segunda forma normal, quando, alm de estar na 1FN, todos os atributos no chave da tabela unicamente da chave, ou seja, no contm dependncias parciais. Entende-se por dependncia parcial (funcional), quando uma coluna depende apenas de parte de uma chave primria composta. dependem

30

Terceira forma normal (3FN) - uma tabela encontra-se na terceira forma normal, quando, alm de estar na 2FN, todos os seus atributos no chave no dependem de nenhum outro atributo no chave, ou seja, no contm dependncias transitivas. Entende-se por dependncias transitivas, quando uma coluna, alm de depender da chave primria da tabela, depende de outra coluna ou conjunto de colunas da tabela. Quarta forma normal (4FN) - uma tabela encontra-se na quarta forma normal, quando, alm de estar na 3FN, no h repetio de dois ou mais atributos no chave, ou seja, no contem dependncias multivaloradas. Entende-se por dependncias multivaloradas, quando uma coluna ou conjunto de colunas depende multivaloradamente de uma coluna (determinante) da mesma tabela quando um valor do atributo determinante identifica repetidas vezes um conjunto de valores da coluna dependente. Quinta forma normal (5FN) - muito raro ocorrer, sendo que utilizada quando uma tabela na quarta forma normal pode ser dividida em duas ou mais tabelas, para evitar redundncias existentes.

6.4 Modelagem de Dados

Segundo Oliveira (2002, p. 25), a abordagem relacional a utilizao de conceitos de entidade e relacionamento para criar as estruturas que iro compor o banco de dados, partindo sempre da necessidade do usurio ou grupo de usurios do sistema. Dessa maneira a modelagem de dados tem como propsito representar as informaes do negcio, desenvolvendo um modelo contendo entidades e relacionamentos. De acordo com Pinheiro (2005, p. 36), no desenvolvimento de aplicaes em banco de dados, o modelo relacional o mais utilizado para a representao e entendimento dos dados que compem a essncia de um sistema de informaes. O modelo conceitual e lgico descrito por Heuser (2004, p. 6,7) da seguinte maneira:

31

Modelo conceitual: o modelo conceitual consiste em uma descrio do banco de dados de forma independente de implementao em um SGBD. O modelo conceitual registra que dados podem aparecer no banco de dados, mas no registra como os mesmos esto armazenados a nvel de SGBD, onde faz se uso da tcnica de abordagem entidaderelacionamento, (E-R) que ser abordado posteriormente. Modelo lgico: o modelo lgico uma descrio de um banco de dados no nvel de abstrao visto pelo usurio do SGBD. Assim, o modelo lgico dependente do tipo particular de SGBD que est sendo utilizado. Modelo fsico: o modelo fsico usado por profissionais que procuram otimizar o desempenho no envolvendo mudanas no aspecto funcional. As linguagens e notaes no so padronizadas e variam de acordo com cada SGBD. A tcnica mais difundida de modelagem a abordagem entidade-relacionamento, onde representada pelo diagrama de entidade-relacionamento. Essa tcnica criada em 1976 por Peter Chen considerada um padro de modelagem e foi utilizado de modelo para outras tcnicas como a orientada a objetos Unified Modeling Language (UML). De acordo com Heuser (2004, p. 14), uma entidade pode ser definida como um conjunto de objetos da realidade modelada sobre os quais se deseja manter informaes no banco de dados. Segundo Pinheiro (2005, p. 36), as entidades no esto soltas, isoladas uma das outras, mas relacionadas de forma a mostrar a realidade em um contexto lgico. Relacionamento definido por Heuser (2004, p. 15) como um conjunto de associaes entre ocorrncias de entidades. similar ao relacionamento de orientao a objetos, onde obrigatoriedade e cardinalidade fazem parte de suas caractersticas. As vantagens na utilizao do Modelo de Entidade x Relacionamento de acordo com Oliveira (2002, p. 26):

Sintaxe robusta: o modelo documenta as necessidades de informao da empresa de maneira precisa e clara.

32

Comunicao com usurio: os usurios podem, com pouco esforo entender o modelo. Facilidade de criao: os analistaspodem criar e manter um modelo facilmente. Integrao com varias aplicaes: diversos projetos podem ser inter-relacionados utilizando-se o modelo de dados de cada um deles. Utilizao universal: o modelo no est vinculado a um banco de dados especifico, mas sim ao modelo da empresa, o que garante a sua interdependncia de implementao. De acordo com Pinheiro,
No ambiente de banco de dados implementamos as entidades como tabelas, suas instncias como registros e atributos como colunas. Os relacionamentos so mapeados em regras de integridade implementadas atravs de constraints de chaves estrangeira no banco de dados. A integridade referencial deve garantir que, quando um registro se relaciona, este deve ter uma referncia vlida para outro registro em outra tabela. Esta referncia inserida por cpias de colunas implementadas na tabela cujo nico objetivo referenciar a chave primria de outro registro em outra tabela (Pinheiro, 2005, p.37).

6.5 Tcnicas de mapeamento

Sabe-se que o modelo orientado a objetos e o modelo relacional apresentam diferenas de paradigma, porm so os mais utilizados em projetos de software. Observase uma semelhana entre o diagrama de entidade-relacionamento e o diagrama de classes da UML, onde uma classe com seus atributos mapeada por uma tabela do banco de dados e seus atributos, ou seja, as colunas. Contudo, o modelo relacional no fornece um suporte relacionado herana, que utilizado no modelo orientado a objetos.

33

Outra diferena a relao entre os objetos e entidades, onde no modelo relacional utilizado chaves estrangeiras para a as associaes entre as tabelas, nesse caso um campo referncia outra tabela, j os objetos fazem referncia a colees de outros objetos, mas atravs de apenas um atributo. Tendo conhecimento que os bancos de dados relacionais por sua natureza no suportam hierarquia, h trs tcnicas para mapear uma estrutura hierrquica de herana de classes para um banco de dados relacional: uma tabela por hierarquia completa de classes, uma tabela por classe concreta e uma tabela para cada classe concreta.

Tabela nica para toda a Hierarquia

Uma tabela nica para toda a hierarquia pode ser desenvolvida segundo Pinheiro, da seguinte maneira:
Nesta tcnica todos os atributos de todas as classes da estrutura hierrquica so mapeados para uma nica tabela. Cada linha um objeto de uma subclasse especfica, diferenciada na tabela atravs de uma coluna extra que indica a qual classe se refere. Esta coluna extra, denominada cdigo de tipo, pode implementar o polimorfismo se vislumbramos a possibilidade de acrescentar cdigos que representam combinaes de classes (Pinheiro, 2005, p.38).

Como vantagem tem-se um bom desempenho, pois todas as informaes esto em uma nica tabela, proporcionando assim simplicidade uma vez que para se adicionar classes necessrio acrescentar colunas para as novas informaes. As desvantagens so maior acoplamento entre as classes da hierarquia onde h necessidade de uma coluna identificar a classe de cada registro e em caso de mudana de uma classe em determinada tabela pode-se afetar outras classes e com a ausncia de normalizao dos dados ferindo as regras da teoria de modelagem. Devido as colunas com valores nulos, ou seja, no preenchidas em parte das linhas da tabela, havendo um desperdcio de espao no banco de dados. Alm disso, a tabela pode sofrer um grande aumento devido s hierarquias, sendo esta abordagem aconselhvel a pequenas hierarquias.

34

Uma tabela para cada classe concreta

Diferentemente das classes definidas como abstratas as classes concretas podem ter objetos instanciados. Essa abordagem define uma tabela para cada classe concreta no sendo necessrio um identificador de classe na tabela. Alm disso, a tabela implementa atributos herdados da superclasse assim como os atributos da prpria classe. Tem como vantagem melhor performance em relao ao acesso aos dados, pois todas as informaes de uma tabela se encontram em uma nica classe. Porm a redundncia dos atributos, pois o atributo replicado em todas as classes de cada subclasse, havendo maior manuteno da integridade da informao. Essa abordagem indicada para aplicaes que raramente sofrem mudanas.

Uma tabela para cada classe

definido um relacionamento de um-para-um entre todas as tabelas, onde classes so tabelas e atributos so colunas. Nessa modalidade, a estrutura de tabelas ficam semelhantes a hierarquia de classes no modelo UML, devido a normalizao dos dados. Tem como vantagem uma manuteno simples, j que para a incluso de novas classes criam-se tambm novas tabelas, sendo que o aumento do banco de dados proporcional ao nmero de objetos persistidos. Tendo em vista o aumento de tabelas no banco de dados, se torna mais complexo as rotinas de busca e gravao de objetos obtendo um menor desempenho.H tambm como ponto negativo a qualidade de junes (joins) entre tabelas. Essa abordagem apropriada em casos de mudanas continuas.

Uma tabela por hierarquia de classes Ad-hoc reporting Facilidade de implementao Facilidade de acesso Acoplamento Velocidade de acesso Suporte a polimorfismos Simples Simples Simples Muito alto Rpido Mdio

Uma tabela por classe concreta Mdio Mdio Simples Alto Rpido Baixo

Uma tabela por classe Mdio/Difcil Difcil Mdio/Simples Baixo Mdio/Rpido Alto

35

Tabela 1. Comparativo entre tcnicas de mapeamento de classes (Jnior, 2003).

6.5.1 Mapeando objetos para Tabelas

Existem diversas tcnicas de mapeamento de objetos, onde cada uma apresenta vantagens e desvantagens sobre as outras. Sendo assim, o desenvolvedor, a partir da escolha do mecanismo de persistncia, organiza a estrutura de tabelas em um banco de dados para suportar o esquema de objetos modelado.

6.5.2 Mapeando atributos

Os atributos de um objeto so mapeados em colunas da tabela, onde no necessariamente um atributo deve ter uma coluna que o referencia em uma tabela. Podemos ter um atributo que pode ser obtido atravs de consultas, ou um atributo mapeado para mais de uma coluna, e vice-versa como vrios atributos mapeados para somente uma coluna da tabela. Vale a pena ressaltar que o mapeamento deve considerar fatores, como a tipagem dos dados e comprimento mximo dos campos.

6.5.3 Mapeamento de Relacionamentos

O mapeamento de relacionamentos na associao entre objetos uma modalidade que tem por caracterstica a simplicidade. O relacionamento pode ser dividido em trs tipos: Um-para-um: onde se faz uso da chave estrangeira (foreign key), relacionando duas tabelas. Um-para-muitos: funciona da mesma forma do relacionamento anterior, muitos do relacionamento. Muitos-para-muitos: so modeladas por uma terceira tabela, que armazena as chaves, relacionando as duas tabelas. utilizando

chaves, porm a chave colocada na tabela que possui objetos mltiplos, ou seja, o lado

36

De acordo com Pinheiro,

Na metodologia orientada a objetos, alm da hierarquia, existem mais trs tipos de relacionamentos entre objetos: associao, agregao e composio. Relacionamentos na tecnologia de orientao a objetos so implementados atravs de referncias a objetos e correspondentes operaes de manipulao (Pinheiro, 2005, p.40).

So apresentadas abaixo as classificaes de relacionamento de objetos que influenciam o mapeamento objeto-relacional.

Cardinalidade do relacionamento entre objetos Relacionamento um-para-um: refere-se ao relacionamento onde a cardinalidade de cada um dos componentes no mximo um. Relacionamento mais. Relacionamento muitos-para-muitos: refere-se ao relacionamento onde a cardinalidade de cada um dos componentes um ou mais. um-para-muitos: refere-se ao relacionamento onde a

cardinalidade de um objeto no mximo um e do outro objeto pode ser um ou

Direcionamento do relacionamento de objetos Relacionamentos unilaterais: este relacionamento existe quando o objeto tem a referencia de outro objeto, mas o mesmo no contm a referencia do primeiro.

37

Relacionamentos bidirecionais: este relacionamento existe quando os objetos se referenciam.

No mundo relacional existe apenas o relacionamento unilateral, sendo assim uma tabela que contem uma ou mais colunas que faz referencia a chave primria de outra tabela. Deve-se escolher uma tabela para implementar a chave estrangeira em caso de cardinalidade um para um. J na cardinalidade um-para-muitos, a chave deve ser implementada na tabela de extremidade muitos. Sendo que na cardinalidade muitos-paramuitos, criada uma nova tabela chamada de associativa, que contm as associaes entre as tabelas, ou seja, as duas chaves estrangeiras correspondentes s chaves primarias das tabelas envolvidas.

6.6 Banco de dados orientado a objetos

Nos ltimos anos, as aplicaes de banco de dados no tem se encaixado nas solues propostas pelo modelo relacional e o modelo entidade relacionamento. Dessa maneira o modelo orientado a objetos nasceu para atender as exigncias de novas aplicaes. Segundo Silberschatz (1999, p. 269), o modelo de dados orientado a objeto uma adaptao a sistemas de banco de dados do paradigma de programao orientado a objeto. Est baseado no conceito de encapsular os dados em um objeto e o cdigo opera nesses dados. Podemos citar como caractersticas essenciais do banco de dados orientado a objetos: Objeto: corresponde a uma entidade do modelo E-R. Segundo Silberschatz (1999, p. 251), o objeto tem associado a ele: Um conjunto de variveis que contem os dados para o objeto; as variveis correspondem aos atributos no modelo E-R.

38

Um conjunto de mensagens ao qual o objeto responde; cada mensagem pode ter zero, um ou mais parmetros. Um conjunto de mtodos cada qual sendo um corpo de cdigo para implementar a mensagem: um mtodo retorna um valor como resposta mensagem.

Classes de objeto: existem muitas entidades similares em um banco de dados, ou seja, usam os mesmos mtodos e possuem variveis de mesmo nome e tipo. Exceto nos valores designados as variveis, normalmente agrupa-se objetos similares formando uma classe, compartilhando assim uma definio comum. Herana: no esquema de banco de dados orientado a objeto, normalmente temos muitas classes similares, entretanto temos classes que fazem uso de variveis especificas. Surge o conceito de herana que permite representar as similaridades entre as classes, colocando essas classes em uma hierarquia de especializao. A abordagem de uma hierarquia de classe correspondente ao conceito de especializao no modelo entidaderelacionamento.

6.6.1 Linguagem orientada a objeto

A linguagem orientada a objeto podem ser classificadas de duas formas: Na sua primeira forma so utilizados conceitos de orientao a objeto no projeto e codificados no banco de dados relacional. So usados modelos de entidaderelacionamento e posteriormente convertidos em conjuntos de relaes manualmente. Outra opo incorporar os conceitos de orientao a objeto na linguagem de banco de dados. Assim temos mais duas opes: Uma opo estender a linguagem de manipulao, o SQL, so os denominados sistemas relacionais objeto. A outra maneira estender a linguagem orientada a objetos, so denominadas linguagens de programao persistente.

39

6.6.2 Linguagens de programao persistentes

Ao contrrio das linguagens de programao tradicionais, as linguagens de programao persistentes manipulam diretamente os dados persistentes. Segundo Silberschatz (1999, p. 261), uma linguagem de programao persistente uma linguagem de programao estendida com estruturas para tratar dados persistentes. Linguagens de programao persistentes podem ser diferenciadas de linguagens com SQL embutida em duas formas: Na linguagem embutida, a linguagem host diferente da linguagem de manipulao, sendo o programador responsvel por qualquer tipo de converso entre as linguagens. J na linguagem de programao persistente, a linguagem de manipulao totalmente integrada com a linguagem host e ambas compartilham o mesmo sistema. Os objetos podem ser criados e armazenados no banco de dados sem qualquer tipo explicito ou mudanas de formato. Na linguagem embutida, o programador deve explicitar no cdigo para efetuar mudanas de dados do banco de dados para a memria e no caso de atualizao, armazenar esse dado para dentro do banco. J na linguagem de programao persistente, o programador no precisa explicitar no cdigo para efetuar manipulaes de dados persistentes tanto como buscar na memria como armazenar no banco. Vale a pena ressaltar com o uso das linguagens de programao torna-se fcil cometer erros que por sua vez danifiquem o banco de dados. Sendo de extrema importncia um suporte a linguagem declarativa, porem atualmente no bem aceita pelas linguagens de programao persistentes.

6.6.3 Persistncia de objetos

Persistncia por classe Abordagem simples, ao se declarar a classe persistente, todos seus objetos so persistentes. Caso contrrio, objetos de classes no persistentes so transientes. Com isso, pode ser considerada uma abordagem no flexvel.

40

Persistncia por criao Nessa abordagem introduzida uma extenso para a criao de objetos transientes. De acordo com a maneira que os objetos so criados os mesmos podem ser persistentes ou transientes. Persistncia por marcao Nessa abordagem todos os objetos so criados como transientes, e marcado explicitamente como persistente antes do trmino do programa. Assim, aps a criao do objeto decidido se o mesmo vai ser transiente ou persistente. Persistncia por referncia Nessa abordagem, so declarados objetos como persistentes (razes) e todos os objetos referenciados pela raiz, tambm so persistentes, formando estruturas de dados persistentes.

6.7 Bancos de dados relacionais-objeto

O modelo relacional aninhado uma extenso do modelo relacional em que os domnios podem ser definidos como atmicos ou como relaes. O conjunto de inteiros um domnio atmico, mas o conjunto de todos os conjuntos de inteiros um domnio no atmico. Relaes aninhadas so apenas um exemplo de extenses ao modelo relacional bsico. Outros tipos de dados no atmicos, como registros aninhados tambm tm se mostrado teis. O modelo relacional aninhado, violando a 1NF, para permitir tipos no atmicos. Sistemas relacionais-objeto combinam dados complexos baseados em um modelo relacional aninhado com conceitos orientado a objeto como classe de objeto e herana. O modelo de dados orientado a objeto tem provocado uma necessidade por caractersticas como herana e referncias a objetos. Sistemas com os tipos complexos e orientao a objetos permitem que os conceitos do modelo E-R, como identidade de entidades, atributos multivalorados, generalizaes e especializaes sejam representadas diretamente sem uma traduo complexa para o modelo relacional. O SQL e outras

41

linguagens de consulta tem sido estendidas para tratar tipos complexos e orientao a objetos. Tanto os bancos de dados orientados a objeto construdos com base em linguagens persistentes, como os bancos de dados relacionais-objeto construdos a partir do modelo relacional, de responsabilidade do projetista de banco de dados escolher o tipo apropriado as necessidades da aplicao, alm disso, so direcionados a diferentes mercados. O SQL fornece boa proteo de dados contra erros de programao e facilita as otimizaes de alto nvel, promete desempenho para aplicaes que executam na memria principal e que realizam grande nmero de acesso ao banco de dados. As linguagens de programao persistentes visam as aplicaes que exigem grande desempenho, entretanto susceptveis a erros de programao e sem poder de consulta. J os sistemas relacionais objeto visam tornar a modelagem de dados e a consulta mais fcil pelo uso de dados complexos, incluindo dados multimdia. Segundo Silberschatz (1999, p. 287), para efeitos de comparao:

Tipos de dados Sistemas relacionais Linguagem de programao simples baseada em BDOOs Sistemas relacionais-objeto Simples Complexo Complexo

Linguagens de consulta Poderosa Integrao com linguagem de programao Poderosa

Caracterstica Alta proteo Alto desempenho Alta proteo

Tabela 2: Comparativo entre sistemas de bancos de dados (Silberschatz, 1999).

7 HIBERNATE
Hibernate uma ferramenta de mapeamento objeto/relacional completa que prov todos os benefcios do MOR. Selecionando os vrios mdulos do software de Hibernate e combin-los dependendo do tipo de projeto tcnico e de exigncias do negcio. De acordo com Fernandes e Lima, 2007.
O Hibernate um framework de mapeamento objeto relacional para aplicaes Java, ou seja, uma ferramenta para mapear classes Java em tabelas do banco de dados e vice-versa. bastante poderoso e d suporte ao mapeamento de associaes entre objetos, herana,

42

polimorfismo, composio e colees. O Hibernate no apresenta apenas a funo de realizar o mapeamento objeto relacional. Tambm disponibiliza um poderoso mecanismo de consulta de dados, permitindo uma reduo considervel no tempo de desenvolvimento da aplicao (Fernandes e Lima, 2007, sem p).

Hibernate Core
O Hibernate Core, tambm conhecido como Hibernate 3.2.x, ou Hibernate, o servio base para a persistncia com seu Application Programming Interface (API) nativo e seu mapeamento de dados em arquivos XML. Possui linguagem Hibernate Query Language (HQL) que se caracteriza por ser similar ao SQL. O Hibernate Core serviu de base para outros mdulos, podendo ser utilizado de modo isolado, sendo independente de outros frameworks e ambientes de desenvolvimento como Java 2 Enterprise Edition (J2EE), aplicaes Swing, dentre outras. A aplicao far uso de um mapeamento escrito em arquivos XML O mdulo Core responsvel pela gerao do cdigo SQL, encapsulando as operaes JDBC, eliminando a necessidade de escritas de sentenas SQL e de manipulaes de ResultSets JDBC, com exceo de consultas complexas ou dependentes de recursos nativos do banco de dados.

Hibernate Annotations
Uma nova maneira de se construir um mapeamento tornou-se possvel com o Java Development Kit 5.0 (JDK), se utilizando de anotaes diretamente no cdigo de fonte de Java. Com o pacote Hibernate Annotations trabalhando acima do pacote Hibernate Core pode-se substituir ou adicionar as anotaes ao mapeamento XML. Empregando o Hibernate Core e o Hibernate Annotations para reduzir linhas de cdigo no mapeamento objeto/relacional, em comparao com os arquivos XML.

Hibernate EntityManager
responsvel pelo controle do ciclo de vida e a persistncia dos objetos. O Hibernate EntityManager, cujo outro mdulo opcional que caracteriza-se em um pequeno envoltrio em torno no Hibernate Core, fornecendo compatibilidade de JPA e

43

implementando as operaes para insero, atualizao, remoo e consulta de objetos anotados.

7.1 Incompatibilidade de paradigma

De acordo com Bauer e King (2005, p. 8), sistemas de gerenciamento de bancos de dados relacionais so a nica tecnologia de gerenciamento de dados provada e quase sempre so uma exigncia em qualquer projeto Java. Os paradigmas modelo de objeto e modelo relacional so alvos de discusso nos ltimos anos devido o problema de incompatibilidade de paradigma. Esse problema comumente gerador de preocupao e esforo adicional em qualquer projeto no ambiente coorporativo. Segundo Bauer e King (2005, p. 8), em um aplicativo orientado para objeto, a persistncia permite que o objeto sobreviva ao processo que o criou. O estado do objeto pode ser armazenado em um disco e um objeto com o mesmo estado pode ser recriado em algum ponto no futuro. Uma soluo ao problema de incompatibilidade que vem ganhando bastante aceitao nos ltimos anos e j citado anteriormente o mapeamento objeto relacional. O MOR realiza a persistncia automtica (transparente) de objetos de uma aplicao orientada a objetos para tabelas de um banco de dados relacional, por meio de metadados (descrevem o mapeamento entre o modelo de objetos e o modelo relacional). Dessa maneira ao invs de obter os dados dos objetos e combina-los a uma string de consulta SQL que ser enviada ao banco de dados relacional, o desenvolvedor apenas invoca os mtodos responsveis por salvar, excluir, alterar os objetos e o framework Hibernate transforma os objetos e seus atributos em tabelas e colunas.

Problema de granularidade
Segundo Bauer e King (2005, p. 12), a granularidade refere-se ao tamanho relativo dos objetos. Objetos persistentes podem ter diferentes tipos de granularidade para tabelas e colunas de granularidade inerentemente limitada.

44

No modelo de objetos possvel alcanar vrios nveis de granularidade, ao contrario do modelo relacional que possuem apenas dois nveis, tabelas e colunas. Tendo como soluo a persistncia de objetos de baixa granularidade em tabelas de grande granularidade ou vice-versa. Em outras palavras, uma tabela armazena diversos tipos de objetos ou um objeto armazenado em diversas tabelas. Porm Bauer e King (2005) propem como objetivo do Hibernate suportar modelos de objeto de granularidade fina, ou seja, mais classes que tabelas. Portanto esse modelo oferece maior coeso e reutilizao de cdigo implementando segurana de tipo e comportamento.

Problema de subtipos
Conforme Bauer e King (2005, p. 15), a incompatibilidade de subtipos uma na qual a estrutura de herana em seu modelo de Java deve ser persistida em um banco de dados SQL que no oferece uma estratgia de herana. As primeiras solues MOR no suportavam esse tipo de mapeamento. As diferentes maneiras de mapeamento de herana so apresentadas como soluo a esse problema e foram abordadas no capitulo anterior.

Problema de identidade
O problema de identidade acontece quando temos dois objetos e os mesmos forem idnticos. No caso o Java prope duas solues para o problema, identidade e igualdade de objeto, j o banco de dados relacional uma soluo, a chave primria. Bauer e King (2005, p. 116), descrevem os trs mtodos para identificao de objetos: Identidade de objeto: objetos so idnticos se ocuparem o mesmo local na memria na Java Virtual Machine (JVM). Podendo ser verificada utilizando o operador == . Igualdade de objeto: objetos so iguais se possuem o mesmo valor (igualdade de valor), como definido pelo mtodo equals (Object o).

45

Identidade do banco de dados: objetos armazenados em um banco de dados relacional so idnticos se representarem a mesma linha ou, equivalentemente, compartilharem a mesma tabela e valor de chave primria. proposta como soluo o uso de identificadores de banco de dados, ou seja, o prprio Hibernate trataria a identidade do banco de dados internamente, essa soluo fcil e rpida, porm preciso escolher uma boa chave primria. Pode ser considerada uma boa chave primria, aquela que a coluna ou colunas, possurem sempre valores preenchidos (nunca ser nula), cada linha possui um nico valor (nica) e o valor dessa linha nunca sofrer mudanas (constante). Na tabela abaixo so apresentados vrios mecanismos internos do Hibernate para a gerao de chaves primrias:

Mecanismo Identidy Sequence Increment Hilo uudi.hex

Descrio Mapeado para colunas identity no DB2, MySQL, MSSQL, Sybase, HSQLDM, Informix. Mapeado em sequncias no DB2, PostgreSQL, Oracle, SAP DB, Firebird (ou generator no Interbase). L o valor mximo da chave primria e incrementa um. Deve ser usado quando a aplicao a nica a acessar o banco e de forma no concorrente. Usa algoritmo high/low para gerao de chaves nicas Usa uma combinao do IP com um timestamp para gerar um identificador nico na rede.

Tabela 3: Mecanismo de gerao de chaves primrias (Jnior, 2003).

Problema de associao
A associao referente a relao de uma entidade. Na linguagem orientada a objetos a associao representada por meio de referencia, e no modelo relacional a chave estrangeira representa a associao. No caso do modelo de objeto a associao navegvel em ambas as direes, ou seja, possuem um relacionamento bidirecional. J o modelo relacional desconhece a

46

navegao, portanto possuem um relacionamento unilateral. So propostas como solues: Associaes um-para-um: uso de chave estrangeira. Associaes muitos-para-muitos: uso de uma tabela link, ou seja, uma terceira tabela. Associaes um-para-muitos: uso de chave, porm do lado muitos. Cabe ressaltar que esse conceito j foi abordado e detalhado anterior. no captulo

Problema de navegao de grfico de objeto

Segundo Bauer e King (2005, p. 20), a coisa mais importante para melhorar desempenho de acesso a dados minimizar o nmero de pedidos ao banco de dados. O modo mais bvio para fazer isso minimizar o nmero de consultas de SQL. O Hibernate oferece como soluo quatro estratgias de busca: busca imediata, busca preguiosa, busca vida e busca em lotes. Que por sua vez, sero abordados posteriormente. Estima-se que 30 por cento gasto de esforo e tempo para codificar o SQL/JDBC de um aplicativo Java. Apesar de todo esse esforo, o resultado no parece ser o melhor. Conforme Lemos 2007, os principais problemas que geram o custo da incompatibilidade: necessrio escrever muito cdigo para (tentar) contornar o problema; Cdigo se torna repetitivo e de difcil manuteno; A escrita de cdigo SQL pode tornar a aplicao dependente do banco de dados; Modelagem dos objetos fica prejudicada; Outras camadas ficam fortemente acopladas camada de persistncia; Produtividade pode ser fortemente afetada.

7.2 Mapeamento Objeto-relacional

De acordo com Bauer e King,

47

A evoluo dos sistemas de hoje em verdadeiro sistemas de banco de dados relacional com integrao orientada para objeto sem costura permanece pura especulao [...]. MOR atualmente a melhor soluo disponvel e um salvador de tempo para os desenvolvedores que enfrentam a incompatibilidade de objeto/relacional diariamente (Bauer e King, 2005, p.40).

A soluo MOR consiste em quatro partes de acordo com Bauer e King (2005, p. 32): Um API por executar operaes Create, Read, Update, Delete (CRUD) bsicas em objetos de classes persistentes; A linguagem ou API para especificar consultas que recorrem a classes e propriedades de classes; Uma facilidade para especificar mapeamento de metadados; Uma tcnica para a implementao de MOR para interagir com objetos transacionais a fim de executar verificao suja (dirty), ir buscar associaes lentas, e outras funes de otimizao.

Transparncia o que caracteriza a qualidade de implementao da camada de persistncia como silenciosa, pois o desenvolvedor realiza operaes relacionadas a manipulao dos dados, sem perceber que o framework Hibernate est por trs dessas manipulaes. Alm disso, proporciona um cdigo mais limpo, tratando apenas de funes pertinentes ao seu escopo. Os nveis de qualidade do MOR so divididos em quatro modalidades (BAUER E KING apud FUSSEL).

Puro relacional
Todo o aplicativo, inclusive a interface do usurio usado o conceito de modelo relacional. Podendo ser til para aplicaes simples, pois os processos de negcio ficam a cargo do banco de dados. Porm essa abordagem apresenta deficincias de portabilidade e manuteno.

48

Mapeamento de objeto leve

Neste caso as entidades so representadas como classes e mapeadas manualmente para tabelas do banco de dados relacional. Essa abordagem bastante difundida, porm bem sucedida em aplicaes com um pequeno nmero de entidades.

Mapeamento de objeto mdio

Os aplicativos fazem uso do modelo de objetos, o SQL realizado em tempo de construo utilizando ferramentas que geram cdigo, as consultas so efetivadas usando uma linguagem OO. Essa abordagem adotada por aplicaes de nvel mdio e oferecendo portabilidade, pois no se encontra atrelada ao banco de dados.

Mapeamento de objeto completo

Esse tipo se mapeamento atende os conceitos de herana, polimorfismo e composio, oferecendo um mapeamento transparente. Fazendo uso da implementao do mapeamento objeto/relacional, alm da reduo de esforo na construo de aplicaes, se faz necessrio uma documentao padro e compreensvel a outras tecnologias. Os desenvolvedores so impostos a documentar o modelo de objetos e o modelo relacional de forma acessvel. Conforme Bauer e King (2005), o mapeamento objeto/relacional e o Hibernate apresentam como principais vantagens:

Produtividade
O Hibernate elimina grande parte do trabalho relacionado a persistncia, permitindo que o desenvolvedor se concentre na implementao da lgica da aplicao.

49

Manuteno
Com menos cdigo, enfatizado a lgica de negcio promovendo um maior entendimento do sistema. Quando o sistema faz uso da persistncia manual h sempre uma tenso, pois se o modelo de objeto sofrer alguma mudana, o modelo relacional ser impactado ou vice-versa. De acordo com Bauer e King (2005, p. 37), MOR funciona como um pra-choque entre os dois modelos: permite o uso mais elegante de orientao de objeto no lado de Java e isola cada modelo de mudanas menores para o outro.

Desempenho
Tarefas manuais nem sempre tem melhor desempenho do que as tarefas automatizadas, considerando limitaes de tempo e custo. Alm disso, com o potencial aumento da produtividade o desenvolvedor poder gastar mais tempo em possveis gargalos.

Interdependncia de fabricante
De acordo com Bauer e King (2005, p. 38), interdependncia de banco de dados ajuda nos cenrios de desenvolvimento onde desenvolvedores usam um banco de dados local de peso leve, mas desdobram para produo em um banco de dados diferente. Assegura-se quando a base de dados no possui uma modelagem e normalizaes adequadas, sente-se uma dificuldade de reduzir as diferenas entre os dois mundos, o orientado a objetos e o relacional. Isso acontece principalmente em bancos legados onde no existia uma modelagem e a base de dados era utilizada em sistemas com uso de linguagens estruturadas. Com a idia do Hibernate de encapsular todo o cdigo SQL, alguns desenvolvedores so se sentem confortveis com o no controle de suas implementaes relacionadas a persistncia. Apesar do Hibernate oferecer o HQL como um recurso poderoso, em alguns casos preciso recorrer ao SQL nativo devido ao desempenho ou queries complexas.

50

Pode ser considerado como um ponto negativo a incluso de diversos jars a aplicao, porm uma vez efetivada sua configurao no necessrio reconfigur-lo. Abaixo esto listadas os principais jars utilizados: ehcache-1.1.jar jta.jar xml-apis.jar commons-logging-1.0.4.jar c3p0-0.8.5.2.jar asm-attrs.jar log4j-1.2.9.jar dom4j-1.6.jar antlr-2.7.5H3.jar cglib-2.1.jar asm.jar jdbc2_0-stdext.jar xerces-2.6.2.jar commons-collections-2.1.1.jar ejb3-persistence.jar hibernate-annotations.jar lucene-1.4.3.jar hibernate3.jar

7.3 Interfaces
Interfaces de programao so conceitos interessantes no Hibernate. Conforme Bauer e King (2005, p. 50), o principal objetivo do projeto da API manter as interfaces entre componentes de software em espao mais estreito possvel. Sendo que APIs MOR no so to pequenas, as interfaces do Hibernate podem ser vista na figura 2:

51

Figura 2: Arquitetura do Hibernate (Bauer e King, 2005) Interfaces do Hibernate podem ser classificadas: Interfaces chamadas por aplicativos para executar CRUD bsico e operaes de consulta. Essas interfaces so o ponto principal de dependncia do negcio do aplicativo/lgica de controle do Hibernate. So inclusas Sesso (Session), Transao (Transaction) e Consulta (Query). Session uma interface primria, fcil de criar, remover, atualizar e recuperar objetos persistentes. Possibilita a comunicao entre a aplicao e a persistncia atravs de conexo JDBC. SessionFactory a fabrica de sesses, criado na inicializao do aplicativo, mantm o mapeamento objeto relacional na memria e armazena declaraes SQL. Normalmente existe um nico SessionFactory para o aplicativo, no entanto se esse aplicativo acessar mais de um banco de dados dever ser criado outro SessionFactory.

52

Transation uma interface opcional, se no utilizado o gerenciamento de transaes fica dentro do cdigo. Query permite controlar e executar consultas tanto HQL quanto SQL nativo. Interfaces chamadas por cdigo de infra-estrutura do aplicativo para configurar o

Hibernate, o mais importante a classe de Configurao. A interface de configurao utilizada para especificar o local e propriedades do Hibernate, para ser criado o SessionFactory. Uma vez criado o SessionFactory o arquivo de configurao pode ser descartado. Vale a pena ressaltar que o local do arquivo de mapeamento relativo a raiz do classpath do aplicativo. Interfaces Callback permitem ao aplicativo reagir a eventos que aconteam dentro do Hibernate, como Interceptor, Lifecycle e Validatable. Estas interfaces permitem extenso da funcionalidade de mapeamento poderoso do Hibernate, como userType, CompositeUserType e IdentifierGenerator. Estas interfaces suportam definio de usurio permitem somar seus prprios tipos e so implementadas por meio do cdigo de infra-estrutura do aplicativo (se necessrio).

De acordo com Bauer e King,

Um fundamento e elemento muito poderoso da arquitetura a noo do Hibernate de um Tipo (type). Um Hibernate tipo objeto mapeia um tipo Java para um tipo de coluna de banco de dados (de fato, o tipo pode atravessar colunas mltiplas). Todas as propriedades persistentes de classes persistentes, inclusive associaes, tm um tipo de Hibernate correspondente. Este projeto torna o Hibernate extremamente flexvel e extensvel (Bauer e King, 2005, p.54).

Como o Hibernate faz uso de APIs do Java. O JDBC apresenta um nvel elementar de abstrao de funcionalidade relacionado a banco de dados, dessa maneira qualquer banco que possui driver JDBC suportado pelo Hibernate. Em relao aos aplicativos de servidores J2EE so integrados por meio do Java Naming and Directory Interface (JNDI) e Java Transaction API (JTA).

53

Interfaces de extenso
De acordo com Bauer e King (2005, p. 55), o Hibernate oferece interfaces de extenso quando as estratgias embutidas j no forem suficientes. Gerao de chave primria (interface IdentifierGenerator); Suporte dialeto de SQL (classe abstrata de Dialect); Estratgias de armazenamento (interfaces Cach e CacheProvider); Gerenciamento de conexo JDBC (interface ConnectionProvider); Gerenciamento de transao (interfaces TransactionFactory, Transaction e TransactionManagerLookup); Estratgias de MOR (interface hierrquica ClassPersister); Estratgias de acesso de propriedade (interface PropertyAccessor); Criao de representao (interface ProxyFactory). As aplicaes precisam ter conhecimento dos estados dos objetos no seu ciclo de vida da persistncia, pois sempre que propaga o estado de um objeto que est em memria para o banco de dados ou vice versa, a aplicao se comunica com a camada de persistncia, fazendo uso do gerenciador de persistncia e as interfaces de consulta do Hibernate. Conforme Fernandes e Lima 2007, em aplicaes orientadas a objetos, a persistncia permite que um objeto continue a existir mesmo aps a destruio do processo que o criou. Na verdade, o que continua a existir seu estado, j que pode ser armazenado em disco e ento, no futuro, ser recriado em um novo objeto. No ciclo de vida de persistncia, o objeto pode transacionar de um objeto transiente para um objeto persistente para um objeto detached, como pode ser visto na figura 3:

54

Figura 3: Ciclo de vida (Bauer e King, 2005).

Objeto transiente: quando os objetos so instanciados, ou seja, fazem uso do operador new, so transientes e no esto associados a nenhuma linha do banco de dados. O Hibernate no considera instancias transientes como transacionais, isso significa que no existe rollback para objetos transientes. Objeto persistente: qualquer objeto que possui uma identidade de banco de dados, ou seja, possui um valor de chave primria. Ao contrrio do objeto transiente, instancias persistentes so transacionais e esto sempre associadas a uma sesso. Objetos detached: quando o objeto tinha uma instancia associada ao contexto persistente e deixou de ser associada, por fechamento ou finalizao de sesso. Sendo objetos intermedirios no so transientes nem persistentes.

55

7.4 HQL
Segundo Bauer e King,
HQL no uma linguagem de manipulao de dados como SQL. S usado para obteno de objetos, no para atualizar, inserir ou deletar dados. A sincronizao de estado do objeto o trabalho do gerenciador de persistncia, no do desenvolvedor (Bauer e King, 2005, p.185).

Sendo compatvel com as seguintes habilidades: A habilidade para aplicar restries a propriedades de objetos associados, relacionados por referencia, ou contidos nas colees; A habilidade para obter somente propriedades de uma entidade ou entidades, sem o custo indireto de carregar a prpria entidade em um escopo transacional; A habilidade para ordenar os resultados da consulta; A habilidade para paginar os resultados; Agregao com group by, having e funes agregadas como sum, min, max; Associaes externas ao obter mltiplos objetos por linha; A habilidade para chamar funes SQL definidas pelo usurio; Subconsultas.

H quatro mtodos de busca para qualquer associao conforme Bauer e King (2005, p. 188): Busca imediata: o objeto associado buscado imediatamente usando uma leitura no banco de dados seqencial (ou pesquisa de cach). Busca preguiosa: o objeto associado ou coleo buscado preguiosamente, quando acessado pela primeira vez. Isso resulta em uma nova requisio ao banco de dados (exceto se o objeto associado estiver armazenado em cach).

56

Busca vida: o objeto ou coleo buscado junto com o objeto proprietrio, usando uma juno externa SQL, e nenhuma requisio adicional de banco de dados exigida. Busca em Lotes: esta tcnica pode ser usada para melhorar o desempenho da busca preguiosa obtendo um lote de objetos ou colees quando uma associao preguiosa acessada (busca em lotes tambm pode ser usada para melhorar o desempenho da busca imediata). De acordo com Bauer e King,
Consideramos HQL o mtodo mais poderoso. As consultas HQL so fceis de entender e elas utilizam classe persistente e nomes de propriedade no lugar de nomes de tabela e de colunas. HQL polimrfica: voc pode obter todos os objetos com uma determinada interface consultando essa interface. Com HQL, voc tem todo o poder de restries arbitrarias e projeo de resultados, com operadores lgicos e chamadas de funo exatamente como em SQL, mas sempre em nvel de objeto usando nomes de classe e de propriedade. Voc pode usar parmetros para ligar os argumentos de consulta de uma maneira segura de tipo. Consultas com estilo de relatrios tambm so suportadas, e uma rea importante onde geralmente faltam recursos para outras solues MOR (Bauer e King, 2005, p.381).

Com os poderosos recursos HQL, no s podemos recuperar dados do banco de dados como popular esses dados, ou seja, realizamos qualquer tipo de consulta de forma flexvel, mas em raras ocasies o Hibernate pode no oferecer uma soluo para uma consulta complexa. Dessa maneira precisamos recorrer ao uso do SQL, realizando consultas SQL nativas.

8 ESTUDO DE CASOS
Na figura abaixo est representada a modelagem do banco de dados, no estudo de caso proposto.

57

Figura 4: Modelagem do banco de dados A figura 4 apresenta a modelagem do banco de dados, sendo representada todas s estruturas de tabelas do projeto. Foi utilizado a ferramenta DBDesigner para efetuar a representao grfica. A figura 5 mostra a estrutura do projeto no NetBeans 5.0, usando o framework Hibernate.

Figura 5: Estrutura do projeto

58

Abaixo esto representadas as classes persistentes que implementam as entidades de domnio de negcio. Como citado anteriormente o mapeamento objeto/relacional pode ser realizado por meio de anotaes. Sendo que qualquer smbolo que comece com @ (arroba) uma anotao que aparece no cdigo fonte, mas so ignoradas pelo compilador. A anotao foi anexada a linguagem Java aps a verso 5.0 do JDK simplificando a maneira de escrever classes persistentes que eram realizadas por meio de arquivos XML.

package entity; import import import import import java.io.Serializable; javax.persistence.Column; javax.persistence.Entity; javax.persistence.Id; javax.persistence.Table;

@Entity @Table(name = "sin_regional") public class SinRegional implements Serializable { @Id @Column(name = "SIN_Regional_ID", nullable = false) private Integer sinRegionalID; @Column(name = "Sin_Nome") private String sinNome; @Column(name = "Sin_Carac") private String sinCarac;

public SinRegional() { } //mtodos getters e setters @Override public int hashCode() { int hash = 0; hash += (this.sinRegionalID != null ? this.sinRegionalID.hashCode() : 0); return hash; } @Override public boolean equals(Object object) {

59

if (!(object instanceof SinRegional)) { return false; } SinRegional other = (SinRegional)object; if (this.sinRegionalID != other.sinRegionalID && (this.sinRegionalID == null || !this.sinRegionalID.equals(other.sinRegionalID))) return false; return true; } }

Quadro 1 Classe SinRegional utilizando anotaes.

No quadro 1 representada uma classe de mapeamento utilizando anotaes, onde o @Entity indica que a classe uma entidade e a mesma mapeada atravs da anotao @Table, ou seja, o nome da tabela correspondente. Cada coluna da tabela refere-se a um atributo da classe, mapeadas por @Column e a sua chave primria recebe a anotao @Id. Tambm so representados os mtodos hashCode e equals, que garantem a igualdade do objeto mapeadas por @Override que sobrepe o mtodo da classe base ou superclasse.

package entity; import import import import import java.io.Serializable; javax.persistence.Column; javax.persistence.EmbeddedId; javax.persistence.Entity; javax.persistence.Table;

@Entity @Table(name = "sist_transmissao") public class SistTransmissao implements Serializable { @EmbeddedId protected SistTransmissaoPK sistTransmissaoPK; @Column(name = "Sistr_Nome") private String sistrNome; @Column(name = "Sistr_Num_Barras") private Integer sistrNumBarras; @Column(name = "Sistr_Caract") private String sistrCaract; @Column(name = "Sistr_Inf_Extras") private String sistrInfExtras;

60

public SistTransmissao() { } public SistTransmissao(SistTransmissaoPK sistTransmissaoPK) { this.sistTransmissaoPK = sistTransmissaoPK; }

public SistTransmissao(int sinRegionalID, int sistrID) { this.sistTransmissaoPK = new SistTransmissaoPK(sinRegionalID, sistrID); } //mtodos getters e setters

@Override public int hashCode() { int hash = 0; hash += (this.sistTransmissaoPK != null ? this.sistTransmissaoPK.hashCode() : 0); return hash; }

@Override public boolean equals(Object object) { if (!(object instanceof SistTransmissao)) { return false; } SistTransmissao other = (SistTransmissao)object; if (this.sistTransmissaoPK != other.sistTransmissaoPK && (this.sistTransmissaoPK == null || !this.sistTransmissaoPK.equals(other.sistTransmissaoPK))) return false; return true; } }

Quadro 2 Classe SistTransmissao utilizando anotaes. No quadro 2 observamos uma nova anotao o @EmbeddedId, que por sua vez, define a chave composta. Abaixo representada a classe que compe a chave composta.

package entity; import java.io.Serializable; import javax.persistence.Column; import javax.persistence.Embeddable;

@Embeddable

61

public class SistTransmissaoPK implements Serializable { @Column(name = "Sistr_ID", nullable = false) private int sistrID; @Column(name = "SIN_Regional_ID", nullable = false) private int sinRegionalID;

public SistTransmissaoPK() { }

public SistTransmissaoPK(int sinRegionalID, int sistrID) { this.sinRegionalID = sinRegionalID; this.sistrID = sistrID; } //mtodos getters e setters @Override public int hashCode() { int hash = 0; hash += (int)sinRegionalID; hash += (int)sistrID; return hash; } @Override public boolean equals(Object object) { if (!(object instanceof SistTransmissaoPK)) { return false; } SistTransmissaoPK other = (SistTransmissaoPK)object; if (this.sinRegionalID != other.sinRegionalID) return false; if (this.sistrID != other.sistrID) return false; return true; }

Quadro 3 Classe SistTransmissaoPK No quadro 3 a classe identificada com a anotao @Embeddable, indicando que se trata de uma classe de chave composta. Lembrando que todas as classes persistentes implementam a interface Serializable, permitindo que o objeto possa ser armazenado em disco ou percorrer pela rede. A figura abaixo mostra todas as classes persistentes dentro do pacote entity.

62

Figura 6: Classes entidades - Hibernate Fazendo uso da mesma modelagem, porm, sem a utilizao do Hibernate, ou seja, a mesma aplicao com a implementao de JDBC/SQL. Abaixo est representada a estrutura do projeto.

Figura 7: Estrutura do projetoJDBC

package entity; public class SinRegional { private Integer sinRegionalID;

63

private String sinNome; private String sinCarac; public SinRegional() { } //Mtodos getters e setters }

Quadro 4: Classe SinRegional

package entity; public class SistTransmissao { private private private private private private int sistrID; int sinRegionalID; String sistrNome; Integer sistrNumBarras; String sistrCaract; String sistrInfExtras;

public SistTransmissao() { } //Mtodos getters e setters }

Quadro 5: Classe SistTransmissao Observa-se no quadro 4 e 5 classes de entidade no projeto JDBC. Diferentemente do projeto Hibernate, no fazem uso de nenhuma anotao, bem como no sendo necessrio a identificao de chaves estrangeiras. Na figura abaixo mostra todas as classes dentro do pacote entity.

64

Figura 8: Classes entidades - JDBC Para dar inicio ao Hibernate preciso configurar seu principal arquivo, hibernate.cfg.xml. Atravs dele configurado o acesso ao banco de dados e a localizao das entidades mapeadas.
<?xml version="1.0" encoding="utf-8"?> <!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.connection.driver_class">org.postgreSQL.Driver</property> <property name="hibernate.connection.password">senha</property> <property name="hibernate.connection.url">jdbc:postgreSQL://localhost:porta/nomedob anco</property> <property name="hibernate.connection.username">usuario</property> <property name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</propert y> <mapping class="entity.SinRegional" /> <mapping class="entity.SistTransmissao" /> <mapping class="entity.Barramentos" /> <mapping class="entity.Cargas" /> <mapping class="entity.Climatica" /> <mapping class="entity.Datas" /> </session-factory> </hibernate-configuration>

Quadro 6 Arquivo de configurao utilizando o banco de dados PostgreSQL.

65

No quadro 6 so apresentadas os principais parmetros de configurao do arquivo hibernate.cfg.xml. As descries desses parmetros so: hibernate.connection.driver_class: Classe do Driver JDBC utilizado para realizar a conexo. hibernate.connection.password: Senha do usurio utilizada para a conexo com o banco de dados. hibernate.connection.url: String de conexo contendo o mecanismo de acesso JDBC, o SGBD, nesse caso o Postgres, seguido do servidor, porta e nome do banco. hibernate.connection.username: Nome do usuario do banco de dados. hibernate.dialect: Dialeto contendo caractersticas particulares do banco de dados. mapping class: representa as classes de domnio mapeadas com anotaes.

<?xml version="1.0" encoding="utf-8"?> <!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.connection.driver_class">org.gjt.mm.mySQL.Driver</propert y> <property name="hibernate.connection.password">senha</property> <property name="hibernate.connection.url">jdbc:mySQL://localhost:porta/nomedobanco< /property> <property name="hibernate.connection.username">usuario</property> <property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property> <mapping class="entity.SinRegional" /> <mapping class="entity.SistTransmissao" /> <mapping class="entity.Barramentos" /> <mapping class="entity.Cargas" /> <mapping class="entity.Climatica" /> <mapping class="entity.Datas" /> </session-factory> </hibernate-configuration>

Quadro 7 Arquivo de configurao utilizando o banco de dados MySQL.

66

Observa-se no quadro 7, quando realizada a mudana de banco de dados, so modificadas a classe do Driver, a url de conexo, usurio, senha e o dialeto do banco de dados. Na tabela 4 contm alguns dialetos utilizados pelo Hibernate.

SGBD PostgreSQL MySQL MySQL com InnoDB MySQL com MyISAM Oracle 9i/10g Microsoft SQL Server SAP DB HypersonicSQL Ingres Progress Interbase Pointbase FrontBase Firebird Informix

DIALETO org.hibernate.dialect.PostgreSQLDialect org.hibernate.dialect.MySQLDialect org.hibernate.dialect.MySQLInnoDBDialect org.hibernate.dialect.MySQLMyISAMDialect org.hibernate.dialect.Oracle9Dialect org.hibernate.dialect.SQLServerDialect org.hibernate.dialect.SAPDBDialect org.hibernate.dialect.HSQLDialect org.hibernate.dialect.IngresDialect org.hibernate.dialect.ProgressDialect org.hibernate.dialect.InterbaseDialect org.hibernate.dialect.PointbaseDialect org.hibernate.dialect.FrontbaseDialect org.hibernate.dialect.FirebirdDialect org.hibernate.dialect.InformixDialect
Tabela 4: Dialetos do Hibernate.

package util; import import import import org.hibernate.Session; org.hibernate.SessionFactory; org.hibernate.cfg.AnnotationConfiguration; org.hibernate.cfg.Configuration;

public class ConnectDBMySQL {

67

private static final SessionFactory sessionFactory; private static final ThreadLocal<Session> threadLocal = new ThreadLocal<Session>(); static { try { Configuration configuration = new AnnotationConfiguration(); configuration.configure("hibernate.cfg.xml"); sessionFactory = configuration.buildSessionFactory(); } catch (Throwable t) { throw new ExceptionInInitializerError(t); } } public static Session getInstance() { Session session = (Session) threadLocal.get(); session = sessionFactory.openSession(); threadLocal.set(session); return session; } }

Quadro 8 Classe de conexo usando Hibernate No quadro 8, apresentada a classe de conexo que se utiliza do arquivo mostrado anteriormente hibernate.cfg.xml, buildSessionFactory. responsvel por obter e retornar objetos. Nota-se tambm que criada uma instncia do tipo Session que associada a um objeto threadLocal capaz de abrir um processo concorrente a cada sesso aberta. Para obter conexes com mais de uma banco de dados preciso mais dois arquivos o primeiro ser o arquivo de configurao representado anteriormente nos quadros 6 e 7, e fazendo uso dessas configuraes outro arquivo de conexo representado no quadro 8. Como j citado anteriormente ser criado dois SessionFactory. para configurar e fazer uso do mtodo Retornando um sessionFactory que por sua vez ser

68

Figura 9: Arquivos para conexes em banco de dados distintos Como pode ser visto na figura 9, cria-se mais de um arquivo de configurao, tanto para banco de dados distintos como para diferentes SGBDs. Dessa maneira, so criadas diferentes classes de conexo de acordo com os SGBDs utilizados.

package util; import java.SQL.*; import java.SQL.Connection; import java.SQL.DriverManager; public class ConnectBDPostgreSQL { String url = "jdbc:postgreSQL://localhost:porta/nomedobanco"; String username = "usuario"; String password = "senha"; private Connection connection; public Connection getConexao() throws Exception { try { Class.forName( "org.postgreSQL.Driver" ); connection = DriverManager.getConnection( url, username, password ); } catch ( ClassNotFoundException cnfex ) { System.err.println("Failed to load JDBC/ODBC driver." ); cnfex.printStackTrace(); System.exit( 1 ); } catch ( SQLException SQLex ) { System.err.println( "Unable to connect" ); SQLex.printStackTrace( );

69

} return connection; } }

Quadro 9 Classe de conexo usando JDBC. O quadro 9 mostra uma classe comum de conexo ao banco de dados sem o uso do Hibernate. Onde criado um objeto tipo Connection que utilizando a string url, nome do usurio e senha, obtem uma conexo. No exemplo acima utilizado a string url do banco de dados PostgreSQL.

Figura 10: Arquivo para conexes em banco de dados A figura 10 apresenta a classe de conexo ao banco de dados. Lembrando que para ser efetuada a conexo com outros SGBDs, deve ser criado outra classe com as devidas especificaes.

package dao; import import import import import import entity.*; java.util.List; org.hibernate.HibernateException; org.hibernate.Session; org.hibernate.Transaction; util.ConnectBDPostgreSQL;

public class ClasseDao { private Session session;

70

public void salvar(Object object) { session = ConnectDB.getInstance(); Transaction tx = null; try { tx = session.beginTransaction(); session.save(object); tx.commit(); } catch (HibernateException e) { e.printStackTrace(); } finally { session.close(); } } public void editar(Object object) { session = ConnectDB.getInstance(); Transaction tx = null; try { tx = session.beginTransaction(); session.update(object); tx.commit(); } catch (HibernateException e) { e.printStackTrace(); } finally { session.close(); } } public void deletar(Object object) { session = ConnectDB.getInstance(); Transaction tx = null; try { tx = session.beginTransaction(); session.delete(object); tx.commit(); } catch (HibernateException e) { e.printStackTrace(); } finally { session.close(); } } public List consultarTabela(String entityName) { session = ConnectDB.getInstance(); List list = session.createQuery("from " + entityName).list(); return list; } public SinRegional consultarSinRegional(int codigo) { session = ConnectDB.getInstance(); SinRegional sinRegional = (SinRegional)session.createQuery("from SinRegional where SIN_Regional_ID = " + codigo).uniqueResult();

71

return sinRegional; }

Quadro 10 Classe DAO utilizando Hibernate. No quadro 10 utilizada a classe do padro Data Access Object (DAO), sendo responsvel por gerenciar e encapsular o acesso aos dados. Observa-se que criado um objeto session, garantindo uma nica sesso aberta. Os mtodos salvar, editar e deletar, recebem como parmetro um tipo object que pode ser qualquer tabela mapeada no arquivo hibernate.cfg.xml, ou seja, um mtodo salvar pode ser utilizado por todas as classes mapeadas para inserir novos dados em suas respectivas tabelas. O mesmo acontece para os mtodos editar e deletar. O mtodo consultar tabela recebe um tipo String com o nome da entidade que se deseja consultar e retorna um List com todos os dados da tabela. Em seguida o mtodo consultarSinRegional() retorna uma linha segundo o cdigo passado por parmetro. Nota-se que essas consultas utilizam o HQL (Hibernate Query Language), a linguagem de consultas do Hibernate, onde possvel escrever sentenas orientadas a objetos, usando herana, polimorfismo e associaes recuperando e modificando dados.

Figura 11: Classe DAO projeto Hibernate A figura 11 mostra apenas uma classe para realizar a persistncia de toda a aplicao.
package dao; import import import import public entity.*; java.SQL.*; util.ConnectBDPostgreSQL; java.util.*; class SinRegionalDao {

72

ConnectDB con = new ConnectDB(); public Vector consultarSinRegional() throws Exception{ Connection c = con.getConexao(); PreparedStatement ps = null; ResultSet rs = null; Vector lista = new Vector(); try { ps = c.prepareStatement("SELECT * FROM sin_regional"); rs = ps.executeQuery(); while (rs.next()) { SinRegional sinReg = new SinRegional(); sinReg.setSinRegionalID(rs.getInt(1)); sinReg.setSinNome(rs.getString(2)); sinReg.setSinCarac(rs.getString(3)); lista.add(sinReg); } } finally { if (rs != null) { rs.close(); rs = null; } if (ps != null) { ps.close(); ps = null; } if (c != null) { c.close(); c = null; } } return lista; } public SinRegional consultarSinRegionalPorCod(String codigo) throws Exception{ Connection c = con.getConexao(); PreparedStatement ps = null; ResultSet rs = null; SinRegional sinReg = new SinRegional(); try { ps = c.prepareStatement("SELECT * FROM sin_regional WHERE SIN_Regional_ID = '" + codigo + "'"); rs = ps.executeQuery(); while (rs.next()) { sinReg.setSinRegionalID(rs.getInt(1)); sinReg.setSinNome(rs.getString(2)); sinReg.setSinCarac(rs.getString(3)); } } finally { if (rs != null) { rs.close(); rs = null; } if (ps != null) {

73

ps.close(); ps = null; } if (c != null) { c.close(); c = null; } } return sinReg; } public void salvarSinRegional(SinRegional SinRegional) throws Exception{ Connection c = con.getConexao(); PreparedStatement ps = null; Vector lista = new Vector(); int cod = 0; try { ps = c.prepareStatement("INSERT INTO sin_regional VALUES (?, ?, ?)"); ps.setString(1,String.valueOf(cod)); ps.setString(2,SinRegional.getSinNome()); ps.setString(3,SinRegional.getSinCarac()); ps.executeUpdate(); } finally { if (ps != null) { ps.close(); ps = null; } if (c != null) { c.close(); c = null; } } } public void deletarSinRegional(String codigo) throws Exception { Connection c = con.getConexao(); PreparedStatement ps = null; try { ps = c.prepareStatement("DELETE FROM sin_regional WHERE SIN_Regional_ID = '" + codigo + "'"); ps.executeUpdate(); } finally { if (ps != null) { ps.close(); ps = null; } if (c != null) { c.close(); c = null; } } }

74

public void editarSinRegional(SinRegional SinRegional) throws Exception { Connection c = con.getConexao(); PreparedStatement ps = null; String cod = Integer.toString(SinRegional.getSinRegionalID()); try { ps = c.prepareStatement("UPDATE sin_regional SET Sin_Nome = ?, Sin_Carac = ? WHERE SIN_Regional_ID = '" + cod + "'"); ps.setString(1,SinRegional.getSinNome()); ps.setString(2,SinRegional.getSinCarac()); ps.executeUpdate(); }finally { if (ps != null) { ps.close(); ps = null; } if (c != null) { c.close(); c = null; } } } }

Quadro 11 Classe DAO da tabela sinRegional utilizando SQL. No quadro 11 a classe com operaes de insert, update, delete e dois tipos de consulta consultarSinRegional() retorna um tipo Vector com todas as colunas e linhas da tabela, j a consultarSinRegionalPorCod() retorna uma linha, segundo o cdigo que passado por parmetro. Nota-se um aumento significativo no nmero de linhas de cdigo comparado ao quadro 6. Vale ressaltar que no quadro 6 os mtodos so utilizados por todas as tabelas do banco de dados, j o quadro 7 apresenta os mesmos mtodos fazendo uso da linguagem SQL, para apenas uma tabela do banco de dados (SinRegional). Sendo assim necessrias um mtodo de insero, atualizao, excluso e consultas desses dados armazenados para cada tabela do banco de dados. Como pode ser visto na figura 12:

75

Figura 12: Classe DAO projeto JDBC Em ambas as aplicaes os pacotes gui.viso e gui.viso.tabelas, apresentam o mesmo contedo, ou seja a interface grfica das aplicaes. Seguem abaixo as representaes de cada tabela.

76

Figura 13: SinRegional A figura 13 representa a tabela SinRegional, podendo ser efetuada as operaes de incluso, alterao e excluso das informaes. Tendo o resultado dessas operaes a representao simultnea na tabela.

77

Figura 14: SistTransmissao A figura 14 representa a tabela SistTransmissao, que contm a tabela SinRegional como chave estrangeira, podendo ser efetuada as operaes de incluso, alterao e excluso das informaes. Tendo o resultado dessas operaes a representao simultnea na tabela.

78

Figura 15: Barramentos A figura 15 representa a tabela Barramentos, que contm as tabelas SinRegional e SistTransmissao como chave estrangeira, podendo ser efetuada as operaes de incluso, alterao e excluso das informaes. Tendo o resultado dessas operaes a representao simultnea na tabela.

79

Figura 16: Cargas A figura 16 representa a tabela Cargas, que contm as tabelas SinRegional, SistTransmissao, Barramentos e Datas como chave estrangeira, podendo ser efetuada as operaes de incluso, alterao e excluso das informaes. Tendo o resultado dessas operaes a representao simultnea na tabela.

80

Figura 17: Datas A figura 17 representa a tabela Datas, podendo ser efetuada as operaes de incluso, alterao e excluso das informaes. Tendo o resultado dessas operaes a representao simultnea na tabela.

81

Figura 18: Climatica A figura 18 representa a tabela Climatica, que contm a tabela Datas como chave estrangeira, podendo ser efetuada as operaes de incluso, alterao e excluso das informaes. Tendo o resultado dessas operaes a representao simultnea na tabela.

Vale a pena ressaltar que todas as tabelas foram implementadas as aes de incluso, alterao, excluso e consulta. Ficando para uma futura implementao a insero de arquivo texto gerando uma nova tabela, e com isso, sendo representada na rvore.

82

8.1 Anlise de banco de dados

Figura 19: Grfico MySQL Na figura 19 apresentado o grfico do MySQL, em preto os dados que foram solititados durante a consulta, em verde a vazo, ou tempo de resposta do SGBD, em vermelho o desvio padro, em azul a mediana e em roxo a mdia. Observa-se que a mdia se mantm, pois o desvio e a mediana permanecem em paralelo. A vazo crescente conforme as solicitaes efetuadas.

83

Figura 20: Relatrio MySQL Na figura 20 apresentado o relatrio onde foram feitas 500 transaes em 150,9 segundos.

Figura 21: Grfico PostgreSQL

84

Na figura 21 apresentado o grfico do PostgreSQL, em preto os dados, em verde a vazo, em vermelho o desvio padro, em azul a mediana e em roxo a mdia. Observa-se que a mdia no inicio alta, se mantm, pois o desvio e a mediana permanecem em paralelo. A vazo crescente conforme as solicitaes efetuadas. Portando o PostgreSQL, obteve maior rapidez nas consultas testadas.

Figura 22: Relatrio PostgreSQL

O teste foi realizado pelo software JMeter 2.3, sobre os bancos de dados MySQL 5.0 e PostgreSQL 8.2. Ambos os testes com 500 transaes, o banco de dados MySQL apresenta maior vazo por segundo em relao ao banco de dados PostgreSQL, ao realizar uma consulta simples, com os seguintes parmetros: 100 usurios efetuando uma consulta simultaneamente, com um loop de 5 vezes.

85

8.2 Anlise de tempo

A seguir so apresentados os resultados dos testes efetuados nos bancos de dados MySQL e PostgreSQL.

MySQL

Tabela 5: Consultas MySQL, terceiro plano de testes

86

Tabela 6: Consultas MySQL, quarto plano de testes Na tabela 5 e 6 so apresentadas trs baterias de testes seguindo o terceiro e quarto plano de teste, respectivamente, medindo o tempo da consulta usando o Hibernate e JDBC. Foram efetivadas trs tipos de consultas a primeira em uma tabela simples, a segunda em duas tabelas simultneas e a terceira em quatro tabelas. Observa-se que o JDBC obtm um melhor desempenho em relao ao Hibernate.

87

Mdia tempo de Consulta

900 800 700 Milisegundos 600 500 400 300 200 100 0 1 Hibernate JDBC

Grfico 1: Mdia tempo de consultas MySQL, terceiro plano de teste. O grfico acima mostra a diferena em milisegundos do tempo mdio de consulta das aplicaes que utilizam o Hibernate e o JDBC. O grfico referente ao terceiro plano de teste.

Mdia tempo de Consulta

1200 1000 Milisegundos 800 600 400 200 0 1 Hibernate JDBC

Grfico 2: Mdia tempo de consultas MySQL, quarto plano de teste. O grfico acima mostra a diferena em milisegundos do tempo mdio de consulta das aplicaes que utilizam o Hibernate e o JDBC. O grfico referente ao quarto plano de teste.

88

PostgreSQL

Tabela 7: Consultas PostgreSQL, terceiro plano de teste

89

Tabela 8: Consultas PostgreSQL, quarto plano de teste Na tabela 7 e 8 so apresentadas trs baterias de testes, seguindo o terceiro plano e o quarto plano de teste, respectivamente, medindo o tempo da consulta usando o Hibernate e JDBC. Foram efetivadas trs tipos de consultas a primeira em uma tabela simples, a segunda em duas tabelas simultneas e a terceira em quatro tabelas. Apesar do Hibernate conseguir ser mais rpido depois da primeira consulta, a melhor mdia de desempenho obtida pelo JDBC.

90

Mdia tempo de Consulta

700 600 Milisegundos 500 400 300 200 100 0 1 Hibernate JDBC

Grfico 3: Mdia tempo de consultas PostgreSQL, terceiro plano de teste. O grfico 3 mostra a diferena em milisegundos do tempo mdio de consulta das aplicaes que utilizam o Hibernate e o JDBC. O grfico referente ao terceiro plano de teste.

Mdia tempo de Consulta

1200 1000 Milisegundos 800 600 400 200 0 1 Hibernate JDBC

Grfico 4: Mdia tempo de consultas PostgreSQL, quarto plano de teste. O grfico 4 mostra a diferena em milisegundos do tempo mdio de consulta das aplicaes que utilizam o Hibernate e o JDBC. O grfico referente ao quarto plano de teste.

91

Tabela 9: Testes de Incluso Na tabela 9 apresentada trs baterias de testes medindo o tempo da incluso usando o Hibernate e JDBC. Observa-se que o JDBC obtm um melhor desempenho em relao ao Hibernate.

92

Incluso
80 70 Milisegundos 60 50 40 30 20 10 0 1 Hibernate JDBC

Grfico 5: Mdia tempo de incluso. O grfico 5 mostra a diferena em milisegundos do tempo mdio de incluso das aplicaes que utilizam o Hibernate e o JDBC. O grfico referente ao quinto plano de teste.

93

Tabela 10: Testes de Excluso. Na tabela 10 apresentada trs baterias de testes medindo o tempo da excluso usando o Hibernate e JDBC. Observa-se que o JDBC obtm um melhor desempenho em relao ao Hibernate.

94

Excluso
20,5 20 19,5 Milisegundos 19 18,5 18 17,5 17 16,5 16 1 Hibernate JDBC

Grfico 6: Mdia tempo de excluso. O grfico acima mostra a diferena em milisegundos do tempo mdio de excluso das aplicaes que utilizam o Hibernate e o JDBC. . O grfico referente ao sexto plano de teste.

Cabe ressaltar que os testes acima foram realizados medindo o tempo antes e depois da operao de banco (consulta, incluso e excluso), dentro do cdigo das aplicaes.

95

9 CONCLUSO

Neste trabalho foram apresentadas as diferenas potenciais de incompatibilidade de paradigma, entre o modelo relacional e o modelo de objetos. A soluo para obter melhor aproveitamento das tecnologias orientada a objetos e relacional criar uma ponte entre os dois mundos. Verifica-se que o mapeamento objeto/relacional soluciona de maneira bastante eficiente os problemas de incompatibilidade, apresentando diversas tcnicas de mapeamento e de busca visando um melhor desempenho. Foram implementadas duas aplicaes, uma usando o SQL/JDBC e outra utilizando o framework Hibernate. Ambas as aplicaes fazem uso de uma modelagem simples de banco de dados e implementam funcionalidades bsicas como incluso, alterao, excluso e consulta de dados. Observa-se que a aplicao que utiliza o Hibernate atingiu uma reduo de cdigo significativa relacionado a camada de persistncia, alm de conseguir a interdependncia de dados, tornando a aplicao portvel para diferentes SGBDs. Com a estratgia adotada pode-se afirmar que com o uso do Hibernate, h um ganho de produtividade, onde o desenvolvedor concentra seus esforos na lgica da aplicao. Porm h uma perda de desempenho, segundo os testes realizados, j que aplicao que utiliza o Hibernate possui uma camada a mais, que se sobrepe, acima do JDBC. Cabe ressaltar que no foi utilizado nenhuma otimizao do Hibernate, como ativar cach secundrio ou utilizar opes de busca como lazy loading (busca preguiosa). Conforme os autores Bauer e King, o Hibernate no prov a soluo para todos os problemas e no pode ser considerada a nica soluo para a tarefa de persistncia. Apesar de reduzir em 95 por cento o trabalho relacionado a camada de persistncia, os 5 por cento restantes exige bastante esforo, pois se trata de consultas complexas e especficas. Nesses casos aconselha-se o uso do SQL/JDBC para promover mais desempenho maior nas consultas mais complicadas. Outro fator relevante relacionado a implementao ou migrao de sistemas para obter maior aproveitamento do Hibernate, o grupo de desenvolvedores e arquitetos devem possuir certa experincia ou um aprendizado bem profundo da tecnologia.

96

Podemos concluir que apesar do Hibernate oferecer um ganho de produtividade na camada de persistncia, nota-se uma perda de desempenho em relao a aplicao que faz uso do SQL/JDBC, pois a mesma mantm uma comunicao direta com o banco de dados. Considerando o tempo de desenvolvimento, o Hibernate mais vantajoso em relao ao SQL/JDBC, porm cabe analisar se a performance um fator critico, pois alguns milisegundos podem no fazer diferena para o usurio final. preciso quantificar se essa demora aceitvel.

97

10 REFERNCIAS BIBLIOGRFICAS

ABREU M.; MACHADO F.; Projeto de Banco de Dados: Uma viso prtica 1 Ed. rica, 1996. ALVIM P.; OLIVEIRA H. Hibernate mapeamento OOxSGBDR. SQL Magazine, Ed 2, p. 40-45, 2004. AMBLER S.; The Design of a Robust Persistence Layer For Relational Databases. Disponvel em: http://www.ambysoft.com/downloads/persistenceLayer.pdf Acesso em: 30/01/2007. BAUER C.; KING G.; Java Persistence with Hibernate 1 Ed. Manning, 2007. BAUER C.; KING G.; Hibernate em ao 1 Ed. Cincia Moderna, 2005. BOAGLIO F. Hibernate, SQL Magazine, Ed. 17, p.38-46, 2005.
Arquitetura de Camadas em Java CALADO P.; http://www.mundojava.com.br/NovoSite/15materiacapa.shtml 05/02/2007.

EE.

Disponvel

em:

Acesso

em:

FERNANDES R.; LIMA G.; Hibernate Annotations. Disponvel em: http://www.jeebrasil.com.br/tags/hibernate. Acesso em 10/10/2007. FONSECA, G; Anlise Comparativa de Sistemas de Gerenciamento de Banco de Dados. 2006. 52f. Monografia Faculdade de Jaguarina, Jaguarina. GALHARDO R.; LIMA G.; Introduo ao Hibernate. Disponvel em: http://www.jeebrasil.com.br/mostrar/4 Acesso em: 05/11/2006. GONALVES K.; Teste de Software em aplicaes de banco de dados relacional. 2003. 61f. Tese (Mestrado). Universidade Estadual de Campinas, Campinas. HEUSER C.; Projeto de Banco de Dados. 5 Ed. Sagra Luzzatto, 2004. 98

Hibernate; Hibernate.org. Disponvel em: http://www.hibernate.org/ Acesso em: 12/09/2006.

IMARTERS; Os conceitos primordiais em banco de dados. Disponvel em:

http://www.devmedia.com.br/articles/viewcomp.asp?comp=3173&hl=banco%20de%20dados.

Acesso em 25/08/2007.

JNIOR H. F. de A.; Mapeando Objetos para Bancos de Dados Relacionais: tcnicas e implementaes. Disponvel em: http://www.mundooo.com.br/php/mooartigos.php?pa=showpage&pid=19. Acesso em: 23/10/2007. LINHARES M.; Introduo ao Hibernate. Disponvel em: http://www.guj.com.br/content/articles/hibernate/intruducao_hibernate3_guj.pdf Acesso em: 23/09/2006. LOZANO F. Hibernate na Web. Java Magazine, Ed. 33, p. 30-45, 2006. LOZANO F. Persistncia com Hibernate. Java Magazine, Ed. 28, p. 18-28, 2006. NASCIMENTO G. Fast Hibernate 3. Mundo Java, Ed. 17, p. 20-25, 2006. Oliveira, C.; SQL:curso prtico 1 Ed. Novatec, 2002. PEAK P.; Heudecker N.; Hibernate Quickly 1 Ed. Manning, 2006 PINHEIRO J.; Um framework para persistncia de objetos em banco de dados relacionais. 2005. 207f. Tese (Mestrado) Universidade Federal Fluminense, Niteri. RUMBAUGH, James. et al. Modelagem e Projetos Baseados em Objetos. Trad. Dalton Conde de Alencar. Rio de Janeiro: Editora Campus, 1994. SILBERSCHATZ A.; KORTH H.; SUDARSHAN S.; Sistema de Banco de Dados 3 Ed. Makron Books, 1999.

99