Especialização em Desenvolvimento de Sistemas para Web
JADER DOS SANTOS TELES CORDEIRO
ESTUDO COMPARATIVO ENTRE OS FRAMEWORKS DE
MAPEAMENTO OBJETO-RELACIONAL HIBERNATE E TOPLINK
ESTUDO COMPARATIVO ENTRE OS FRAMEWORKS DE
MAPEAMENTO OBJETO-RELACIONAL HIBERNATE E TOPLINK
Monografia apresentada ao Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web da Universidade Estadual de Maringá, como requisito para obtenção do título de “Especialista” – Área de Concentração: Informática.
Orientador: Prof. Msc. Gécen Dacome de Marchi
ESTUDO COMPARATIVO ENTRE OS FRAMEWORKS DE
MAPEAMENTO OBJETO-RELACIONAL HIBERNATE E TOPLINK
Monografia apresentada ao Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web da Universidade Estadual de Maringá, como requisito para obtenção do título de “Especialista” – Área de Concentração: Informática, pela comissão formada pelos professores.
__________________________________________ Prof. Msc. Gécen Dacome de Marchi – Orientador
__________________________________________ Prof. Msc. Flávio Rogério Uber
__________________________________________ Prof. Msc. Munif Gebara Junior
Agradeço em primeiro lugar a Deus, pela vida, sabedoria, pelo amor, por estar em todos momentos.
A toda minha família, por me ensinarem à verdade, dignidade, o caminho do bem e pelo apoio.
A minha esposa que esteve ao meu lado em todos momentos.
Aos professores do curso, que dividiram um pouco dos seus conhecimentos.
Ao Profesor Msc. Gécen Dacome de Marchi, pela orientação neste trabalho.
Nas aplicações de software é comum o armazenamento de dados persistentes. Para a tecnologia Java temos uma grande diversidade nos padrões e soluções que realizam esta função. Uma interface de conexão para esta plataforma com banco de dados é o JDBC (Java Database Conectivity). Acessar banco de dados relacionais numa perspectiva orientada a objetos é comum nas aplicações atuais. Os desenvolvedores frequentemente deparam-se com os dois paradigmas, o modelo relacional e o modelo orientado a objetos. Este trabalho é um estudo comparativo entre as ferramentas de Mapeamento Objeto-Relacional, os frameworks Hibernate e TopLink. Eles permitem persistir, manipular diretamente objetos Java e a conectividade passa a ser função do framework de persistência. Detalharemos um estudo de caso com a metodologia utilizada para realização nesta pesquisa, comparando os resultados obtidos nas duas especificações. Também com objetivo de padronizar o projeto, utilizamos a JPA (Java Persistence API) para definir a forma de mapear os objetos. A motivação da pesquisa foi a preocupação na maneira como as aplicações são desenvolvidas, é sempre difícil escolher soluções em tecnologia, assim utilizaremos técnicas sistemáticas e metodologias sólidas, também permitir uma reprodução dos processos de testes em outras aplicações, para considerar características diferenciadas de cada projeto.
In the applications software is common to store persistent data. For Java we have a great diversity of standards and solutions that perform this function. A connection interface for this database platform is the JDBC (Java Database conectivity). Relational database access in object-oriented perspective is common in current applications. Developers often faced with the two paradigms, the relational model and object-oriented model. This work is a comparative study between the tools of Object-Relational Mapping, TopLink and Hibernate frameworks. They allow to persist, to directly manipulate Java objects and connectivity becomes a function of the persistence framework. A case study will detail the methodology used to conduct this research, comparing the results obtained in the two specifications. Also in order to standardize the design, use the JPA (Java Persistence API) to define how to map the objects. The motivation of the research was the concern in the way applications are developed, it is always difficult to choose technology solutions, so we use systematic techniques and robust methodologies also allow a reproduction of the testing processes in other applications, to consider different characteristics of each project .
FIGURA 1 - ESTADO DO SISTEMA DURANTE A TRANSAÇÃO... 16
FIGURA 2 - EXEMPLO DE MAPEAMENTO... 19
FIGURA 3 - EXEMPLO DE MAPEAMENTO OBJETO-RELACIONAL... 20
FIGURA 4 - ARQUITETURA DO JPA – JAVA API PERSISTENCE... 21
FIGURA 5 - ARQUITETURA SIMPLIFICADA DO HIBERNATE... 22
FIGURA 6 - ESTRUTURA DE UM BENCHMARK... 25
FIGURA 7 - DIAGRAMA GERADO DO WORKBANCH... 29
FIGURA 8 - BIBLIOTECAS HIBERNATE... 30
FIGURA 9 - BIBLIOTECAS TOPLINK... 31
FIGURA 10 - CICLO DE VIDA DOS OBJETOS... 34
FIGURA 11 - ANOTAÇÕES BÁSICAS PARA MAPEAMENTO... 36
FIGURA 12 - TABELA DEPARTAMENTO... 36
FIGURA 13 - TABELA DEPENDENTE... 38
FIGURA 14 - TABELA EMPREGADOPROJETO... 40
FIGURA 15 - COMPARAÇÃO ENTRE AS PESQUISAS DO GRUPO 1... 47
FIGURA 16 - COMPARAÇÃO ENTRE AS PESQUISAS DO GRUPO 2... 48
FIGURA 17 - COMPARAÇÃO ENTRE AS PESQUISAS DO GRUPO 3... 48
QUADRO 1 - APLICAÇÃO DO CHECK-POINT... 26
QUADRO 2 - TIPOS DE CONSULTAS PARA ANÁLISE DE DESEMPENHO... 27
QUADRO 3 - ARQUIVO PERSISTENCE.XML COM HIBERNATE... 32
QUADRO 4 - ARQUIVO PERSISTENCE.XML COM TOPLINK... 33
QUADRO 5 - ENTITY MANAGER... 35
QUADRO 6 - COMPARATIVO NA ASSOCIAÇÃO DE CONCEITO... 36
QUADRO 7 - MAPEAMENTO DA CLASSE DEPARTAMENTO... 37
QUADRO 8 - MAPEAMENTO DA CLASSE DEPENDENTE... 39
QUADRO 9 - MAPEAMENTO DA CLASSE EMPREGADOPROJETO... 41
QUADRO 10 - CONSULTA CLASSE DEPARTAMENTO COM GRUPO 1... 42
QUADRO 11 - CONSULTA CLASSE DEPARTAMENTO COM GRUPO 2... 42
QUADRO 12 - CONSULTA CLASSE DEPENDENTE COM GRUPO 3... 43
QUADRO 13 - CONSULTA CLASSE DEPENDENTE COM GRUPO 4... 43
QUADRO 14 - CARGA DE TRABALHO NOS TESTES... 44
QUADRO 15 - CONSULTA DO GRUPO 1... 44
QUADRO 16 - CONSULTA DO GRUPO 2... 45
QUADRO 17 - CONSULTA DO GRUPO 3... 45
QUADRO 18 - CONSULTA DO GRUPO 4... 45
API Application Program Interface BD Banco de Dados
DDL Data Definition Language DBMS Database Management System DML Data Manipulation Language HQL Hibernate Query Language
IDE Integrated Development Environment JDBC Java Database Connectivity
JPA Java Persistence API
JPQL Java Persistence Query Language JSTL Java Standard Tag Library
JVM Java Virtual Machine
LGPL Lesser GNU Public License ORM Object Relation Mapping POJO Plain Old Java Objects RI Reference Implementation
SGDB Sistema Gerenciador de Banco de Dados SQL Structured Query Language
1 INTRODUÇÃO...11 1.1 Definição do Problema...11 1.2 Justificativa...12 1.3 Motivação...12 1.4 Limitação da pesquisa...12 1.5 Objetivo geral...13 1.6 Objetivos específicos...13 4 REVISÃO BIBLIOGRÁFICA...14 4.1 Persistência de dados...14 4.2 Persistência de Objetos...14 4.3 Banco de dados...14 4.4 Modelo relacional...17 4.5 Mapeamento Objeto-Relacional...18 4.6 Framework...19
4.7 Java Persistence API...……….20
4.8 Hibernate...22
4.9 Toplink essentials...23
4.10 Benchmark – avaliação de desempenho em banco de dados...23
5 METODOLOGIA DE DESENVOLVIMENTO DA PESQUISA...25
5.1 Procedimentos metodológicos...26
5.2 Seleção do conjunto de consultas...27
6 AMBIENTE PARA EXECUÇÃO DOS TESTES...28
6.1 Base de dados utilizada...28
6.2 Modelo de entidade e relacionamento...29
6.3 Projeto...30
6.4 Bibliotecas...30
6.5 Arquivo de configuração persistence.xml...32
6.6 Entiny manager...33
6.7 Mapeamento das classes...35
6.8 Pesquisa no banco de dados (JPQL)...41
REFERÊNCIAS BIBLIOGRÁFICAS...53
1 INTRODUÇÃO
Atualmente, existe a necessidade dos gestores das corporações tomarem decisões fundamentais para bons negócios nas empresas, tornando o conhecimento da informação importante mas não único, que não seja simplesmente armazenado, é fundamental que posteriormente os dados possam ser consultados de forma correta em tempo adequado. Torna-se importantíssimo a escolha do banco de dados, pelos fatores de tratamento, segurança e principalmente velocidade na busca das informações, itens determinantes no sucesso da organização.
Este trabalho propõe aplicação de alguns conceitos e técnicas para persistência em objetos Java, através da utilização do Mapeamento Objeto-Relacional. Pretendemos elaborar um comparativo por uma outra visão, além das dificuldades no desenvolvimento e facilidades para manutenção, uma verificação na execução do programa com comparação direta entre o Framework Hibernate e TopLink. Espera-se com os resultados contribuir para escolha, com opções de técnicas para uma rápida resposta nos acessos a base de dados e métodos para organização.
Além dos interesses comerciais, existe uma grande demanda por parte de outras áreas de pesquisas por soluções para problemas de armazenamento e gerência de dados ou objetos. Operações específicas nas estruturas de programação são necessárias para uma eficiente gerência dos dados. A solução para os novos desafios de banco de dados aponta para a tecnologia de orientação a objetos.
1.1 Definição do Problema
Os aplicativos são desenvolvidos com orientação a objeto e integração a banco de dados, precisamos de uma forma de comunicação eficiente. Uma grande parcela dos códigos dos programas é destinada à manipulação de dados SQL via JDBC. Os desenvolvedores são forçados a uma adequação ao modelo de dados, dificultando a manutenção.
As empresas utilizam o modelo relacional e não tem interesse em mudanças para banco orientado a objeto. É necessário um framework para persistência com
desempenho e ganho em produtividade, mas que permita eliminação de grande parte da codificação.
1.2 Justificativa
Os resultados analisados servirão de base para direcionar a escolha de uma metodologia, que possibilite rapidez em modo de execução, comparando possíveis perdas em desempenho e organizada do ponto de vista de manutenção.
1.3 Motivação
Temos diversas opções de SGBD disponíveis com recursos variados, seguidores incondicionais que este ou aquele é melhor, repete-se o mesmo problema com a linguagem de programação. Ainda ficou uma lacuna, qual framework de mapeamento objeto relacional utilizar, para fazer a ligação da linguagem em nossa base de dados. Sendo assim, nosso objetivo é contribuir de forma concreta seguindo conceitos já testados de benchmark, para uma análise comparativa entre o framework de persistência Hibernate e o TopLink. Também colaborar para permitir a reprodução das comparações para situações específicas ou diferenciadas, com pequenas alterações possamos aplicar em sistemas diversos. 1.4 Limitação da pesquisa
Temos atualmente disponíveis muitos frameworks para o Mapeamento Objeto-Relacional, fizemos a opção por dois com vasta documentação e conceito na comunidade Java. Esta pesquisa não tem a finalidade de indicar o melhor framework a ser utilizado e sim o que obteve melhor desempenho no teste proposto. Também temos a dificuldade de padronização quando utilizamos tecnologias muito diferentes, mas é importante em trabalhos futuros optamos por outros, desde que o acesso aos seus recursos sejam pelos mesmos componentes.
1.5 Objetivo geral
Elaborar análise e projeto através de técnicas de orientação a objeto, implementação com auxilio de Frameworks e ferramentas específicas, capaz de executar e gerenciar empregados no projeto. Foi feito o desenvolvimento individual, com bibliotecas próprias em cada projeto para não termos interferências nos processos.
A JPA define uma maneira de mapear objetos POJO (Plain Old Java Objects) para um banco de dados. Quanto a especificação JPA, o Hibernate (Jboss) e Toplink (Oracle) destacam-se como mais populares para o mapeamento objeto relacional (ORM).
O armazenamento de dados de forma persistente, traz uma grande preocupação no desenvolvimento, com várias técnicas existentes há uma tendência para utilizarmos a que permita uma melhor organização dos códigos, visando facilidade no entendimento e manutenção. Utilizaremos os frameworks Hibernate e Toplink para verificar além das vantagens estruturais de organização, uma real eficácia em seu uso, comparando-os em situações críticas de forma padronizada com um método de Benchmark, para obter o tempo entre a requisição de consulta e o tempo de resposta.
1.6 Objetivos específicos
a) Estudar ferramentas de apoio para Mapeamento Objeto Relacional.
b) Implementar o Sistema utilizando a linguagem de programação Java, com o auxilio da IDE Eclipse com JavaPersistence API (JPA).
c) Fazer um comparativo de desempenho entre as duas tecnologias de Mapeamento Objeto-Relacional Hibernate e TopLink.
4 REVISÃO BIBLIOGRÁFICA
Neste capítulo é realizada a fundamentação bibliográfica dos temas envolvidos no trabalho.
4.1 Persistência de Dados
É a forma de assegurar que as informações utilizadas sejam duráveis, por meio de armazenamento que possibilitará sua restauração posterior, necessidade fundamental nos sistemas de computação (DATE, 2000, p.9).
Na regra de negócio onde os objetos representam diversas entidades a serem manipuladas, a persistência significa a possibilidade dos objetos existirem em meio externo a aplicação, não permaneça volátil (LUCKOW, D.H; MELO, A. A. de, 2010, p.107).
4.2 Persistência de Objetos
A capacidade do objeto estar de forma acessível nas execuções das rotinas das aplicações, considera-se persistência de objetos. Onde serão armazenados até o término da aplicação os objetos transientes, sua existência é limitada à vida do objeto instanciado, quando termina o programa é liberado da memória temporária. Para torná-los objetos persistentes é necessário armazenar em um repositório estável, que possibilite através de técnicas a reconstrução do objeto, mesmo que removido da memória (LUCKON, D.H; MELO,A.A. de, 2010, p.120).
Em sistemas relacionais as instâncias do banco de dados são automaticamente persistentes, já as instâncias criadas no âmbito do programa de aplicação, só se tornam persistentes se o programador transfere para o banco de dados. No modelo relacional a divisão entre o programa de aplicação e o acesso ao banco de é bem dividido e claro, no modelo orientado a objetos estes ambientes se misturam (CAELUM, p.29)
4.3 Banco de dados
É uma coleção de informações relacionadas que podem ser armazenadas e recuperadas quando necessário.
“Em essência, um sistema de banco de dados é apenas um sistema computadorizado de armazenamento de registros. O banco de dados pode, ele próprio, ser visto como o equivalente eletrônico de um armário de arquivamento.” (DATE, 2000, p. 2).
O gerenciamento da base de dados é feito pelo conjunto de software que permite criar ou manter o banco de dados nos diversos modelos, com definições dos seus usuários, restrições. A camada de acesso faz a conexão entre aplicação e base de dados, permite atualização dos dados a todo instante, temos consultas, inserção, remoção, facilitadas pelo software gestor. O SGBD (Sistema de Gerenciamento de Banco de Dados) ou DBMS (Database Management System), dinamizam operações dando ao ambiente eficiência para o armazenamento e recuperação do conteúdo composto por dados. Também possui acesso, restrições a estrutura de cada arquivo, formato de armazenamento para que as inconsistências e divergências sejam corrigidas e estabelecido um padrão de organização (ELMASRI, R.; NAVATHE, S. B., 2005, p.3).
Date (2000, p. 37) detalha algumas funções do SGBD deverão ter suporte aos seguintes itens:
- Definição de dados: deve ser capaz de aceitar definição de dados, incluir componentes DDL (Data Definition Language) uma linguagem de definição de dados para diversas linguagens.
- Manipulação de dados: gerenciar as solicitações do usuário para buscar, atualizar ou excluir com componente ou compilador DML (Data Manipulation Language) linguagem de manipulação de dados.
- Otimização e execução: As requisições serão processadas pelo componente otimizador sob controle em tempo de execução (run time).
- Segurança e integridade de dados: Um monitoramento das solicitações do usuário, para qualquer tentativa de violação as restrições de segurança definidas. - Recuperação e concorrência de dados: Software ou componente gerenciador de transações.
- Dicionário de dados: informações adicionais sobre os dados, esquemas, mapeamentos externos, conceituais, descrição das restrições de segurança e integridade.
Para Elmasri e Navathe (2005, p. 402) o sistema de banco de dados objetiva a manutenção e consulta dos dados no repositório. Deve ser capaz de gerenciar acessos simultâneos, através das transações e possuir requisitos descritos pela propriedade da ACID :
Atomicidade: Quando uma ou parte da transação falhe, por software ou hardware a transação deverá ser cancelada.
Consistência: Manter o banco de dados em estado consistente, com respeito a integridade referencial.
Isolamento: As transações devem operar isoladamente sem interferências de outras.
Durabilidade: Garantir backup dos dados e checagem das transações com logs.
Figura 1 – Estado do sistema durante a transação Fonte: Bauer, C.; King, G. (2005, p. 156)
Com estes requisitos é assegurado não somente sua persistência, mas que estarão válidos e coerentes. A Figura 1 detalha as operações das transações compreendidas entre início e término consideramos de commit e a qualquer momento deve ser possível um rollback o cancelamento.
As informações podem ser facilmente consultadas, para extrair conjuntos de dados com critérios estabelecidos. Mecanismos próprios predefinidos para lidar com
acesso concorrente, uma transação termina sucesso com commit ou desfaz o processo com roolback.
4.4 Modelo relacional
Representada por uma sólida base teórica em conceitos lógicos e matemáticos da álgebra relacional, similar a uma tabela com valores relacionados, introduzido por Codd em 1970 e utilizado atualmente nos SGBD (ELMASRI, R.; NAVATHE, S. B., 2005 p. 89).
No modelo relacional as informações estão em uma representação matemática, vista como conjunto de tabelas (relações), constituída por campos (atributos) que identificam dados armazenados, cada linha da tabela considerada como registro é identificado como única, com atributo chave de acesso aos registros da tabela. Temos a possibilidade de uma tabela ser atributo chave em outra, que será uma chave estrangeira com ligação lógica entre elas, com restrições reduzimos redundância e preservamos a consistência das informações (DATE, 2000, p.54).
São compostos por relações entre tabelas, com um nome e várias colunas, correspondente a um fragmento de dado diferente com várias linhas. Na criação do banco de dados, modelamos itens do mundo real e relacionamentos. De uma forma geral cada classe de objeto modelado necessita de tabela própria. Para cada coluna tem um tipo de dado associado com nome único. As linhas são também chamadas de registros ou tuplas. Os valores consistem no conjunto de valores individuais que correspondam às colunas. Temos a chave o identificador artificial específico para garantia de ser único. Os esquemas devem demonstrar as tabelas em conjunto com suas colunas, tipos de dados, chaves primárias e estrangeiras. É o conjunto dos detalhes de projeto, pode ser exibido em diagramas de entidade e relacionamento (ELMASRI, R.; NAVATHE, S. B., 2005 p. 90).
De acordo com MACHADO, F.N.R e ABREU, M.P. de. (1996, p. 54) nos relacionamentos existem quatro tipos básicos de relacionamento em banco de dados, são classificados de acordo com o número de itens em cada lado do relacionamento..
- Um-para-um – 1:1 - Uma entidade A está associada no máximo a uma entidade B, e vice-versa.
de entidades em B. Uma entidade B, entretanto pode estar no máximo associada a uma entidade em A
- Muitos-para-um – N:1 - Uma entidade em A está associada no máximo a uma entidade em B. Uma entidade em B, entretanto, pode estar associada a qualquer número de entidade em A
- Muitos-para-muitos – M:N - Uma entidade em A está associada a qualquer número de entidades em B, e uma entidade em B está associada a qualquer entidade em A.
No armazenamento dos dados de forma reduntante, ocupamos espaço extra que gera o problema de termos anomalias de atualização e inconsistência. Sua integridade é violada, já não sabemos o que está correto. Um aspecto importante é a estrutura das tabelas, deve ser construído em modelo consistente e passar por um processo de normalização, utilizamos 6 formas normais para reduzir a redundância (ELMASRI, R.; NAVATHE, S. B., 2005 p. 11).
4.5 Mapeamento Objeto-Relacional
Para LUCKOW e MELO (2010, p. 121) a maneira mais comum de armazenar dados são em bancos relacionais, torna-se necessário na linguagem orientada a objeto uma interação mais funcional. Com a necessidade de converter objetos em tabelas e tabelas em objetos, muitas vezes a linguagem não é compatível. Com o ORM (Object Relational Mapping) ocorre uma persistência automatizada dos objetos para as tabelas em banco de dados relacional, através do uso de meta dados que descrevem o mapeamento entre os objetos e o banco de dados.
O termo Mapeamento Objeto-Relacional é definido como a técnica de mapear o registro do banco de dados em objetos, persistir as informações contidas nos objetos em forma de linhas e colunas. Responsável por mapear classes e atributos do modelo orientado a objeto para tabelas e colunas do banco de dados. Entretanto, existem diversos conceitos na orientação a objeto para os quais o modelo relacional não oferece suporte. Umas das diferenças entre objetos e banco de dados relacionais é a forma de representação dos relacionamentos. Os objetos trabalham com ponteiros ou referências para outros objetos, que são criados em tempo de execução, enquanto no banco de dados estão relacionados por sua estrutura vinculada por chaves primárias e estrangeiras (DALL’OGLIO, P., 2009, p. 223)
Figura 2 – Exemplo de mapeamento
A Figura 2 demonstra que o Mapeamento Objeto-Relacional faz uma relação entre a classe e tabela com suas linhas e colunas.
No paradigma orientado a objetos, além dos atributos temos comportamentos que são métodos, entre outras estruturas complexas, heranças, agregações e composições. Assim surgiu a necessidade de ferramenta para compatibilidade entre os dois modelos, com técnicas que visam a persistência com o mapeamento objeto-relacional.
4.6 Framework
São implementações prontas que chamamos de bibliotecas, auxiliam no desenvolvimento de software. Os Frameworks de persistência de objetos farão o trabalho difícil, repetitivo de relacionamento e acesso ao banco de dados, enquanto nos preocupamos mais com a regra de negócio (SILVA, A. G. da, 2005, p. 20).
Existem bibliotecas de software reusáveis para aplicações comerciais, para sistemas de tempo real e para problemas científicos e de engenharia. Porém, há poucas técnicas sistemáticas para se fazer adições em uma biblioteca, interfaces padrões para software reusável são difíceis de ser impostas, questões de qualidade e manutenibilidade permanecem sem solução e, por fim, o desenvolvedor muitas vezes nem mesmo tem conhecimento de que os blocos de construção existem. (PRESMMAN, 2000, p. 101).
Além de ser funcional, tem que ser eficiente no armazenamento dos dados inseridos por usuários e sistemas externos. Quase todos os aplicativos requerem dados persistentes, um dos conceitos fundamentais em desenvolvimento de sistemas. O banco de dados relacional ainda é uma tecnologia muito utilizada em qualquer plataforma de desenvolvimento.
Com a linguagem de programação Java, houve uma ascendência do paradigma orientado a objetos para o desenvolvimento de software. Este modelo quando voltado para as funções de persistência conduz os desenvolvedores a incompatibilidade no paradigma (SILVA, A. G. da, 2005, p. 41).
Figura 3 – Exemplo de Mapeamento Objeto-Relacional Fonte: Adaptado de Roman (2002, p. 121)
Apresentamos na Figura 3 a tabela representada por uma classe, as colunas serão os atributos da classe e uma linha da tabela como instância da classe.
O mapeamento objeto/relacional na persistência de objetos, automatiza de forma transparente dentro de um aplicativo Java para as tabelas de um banco de dados relacional (LUCKOW, D.H; MELO, A. A., 2010, p. 120).
4.7 Java Persistence API
Tem sua base nas melhores tecnologias de persistência, um conjunto de definições que criam um modelo de acesso aos frameworks de Mapeamento Objeto- Relacional, com linguagem de consulta, modo declarativo para descrever e soluções
completas para o mapeamento com persistência de objetos. A JPA (Java Persistence API) definida na JSR-220 (Enterprise JavaBeans, Version 3.0), padroniza o mapeamento objeto relacional na plataforma Java. Baseada no conceito POJO (Plain Old Java Object), os objetos persistentes são denominados entidades (entities). As entidades são definidas por classes Java comuns sem relação com o frameworks ou bibliotecas, podem ser abstratas ou herdar de outras classes sem restrição (GONÇALVES E., 2007, p. 527).
O pacote javax.persistence contém as classes e interfaces da JPA, assim podemos fazer o mapeamento utilizando anotações para cada uma das entidades criadas, é necessário rotular com @Entity para reconhecer uma classe Java comum. A tabela é representada pela anotação @Table e a chave primária com @Id, cada coluna utiliza @Column. As anotações em Java (Java Annotation), são tipos especiais definidos para simplificar a anotações dos elementos da classe. O compilador faz a leitura das informações e as deixa disponível nos arquivos de classe. Assim o Java Virtual Machine (JVM), vai determinar o modo de interação dos elementos e seus comportamentos (GONÇALVES, E., 2008, p. 276).
Com esses recursos o desenvolvedor obtém uma maior produtividade, quando houver mudanças será necessário realizar mínimas modificações no ORM, apenas bibliotecas e arquivos de configuração sofrem alterações significativas com a nova implementação.
Figura 4 – Arquitetura do JPA – Java Api Persistence Fonte: Lopes, L.H.C (2008, p. 21)
Na Figura 4 temos arquitetura da JPA, que permite a escolha do provedor (implementação) e uma única API como padrão de persistência. Também obtemos alguns benefícios nos uso da JPA como modelo, ele considera tudo como POJOs, os mapeamentos podem ser feitos por annotations, auxilia no gerenciamento de transações, podemos escrever códigos que aceite qualquer base de dados relacional, linguagem de consulta própria. Trabalha com independência de tecnologia Hibernate ou TopLink, propõe um isolamento quanto ao SGBD utilizado (GONÇALVES, E., 2008, p. 277) .
4.8 Hibernate
Um Framework de persistência para aplicações Java de código aberto distribuído com a licença Lesser GNU Public License (LGPL), possui versão .NET o NHibernate. Criado por desenvolvedores Java no mundo e liderado por Gavin King. Com benefício de ser uma solução madura, compatível com diversos bancos relacionais e servidores de aplicação, com curva de aprendizado rápido e principalmente variedade na documentação, livros, artigos, tutoriais, entre outros.
Sua principal função é reduzir a complexidade nos programas Java, baseado no modelo orientado a objeto, que trabalhem com banco de dados relacionais. Permite facilidade para o mapeamento dos atributos com uso de XML ou Anotações nas classes conforme Figura 5. Com o HQL (Hibernate Query Language) uma linguagem de consulta orientada a objetos, faz a recuperação das consultas por meio de uma camada de cache eficiente (SILVA, A.G. da, 2005, p. 42).
Figura 5 – Arquitetura simplificada do Hibernate Fonte: Silva, A.G da. (2005, p. 43)
O gerenciador de conexões provê o gerenciamento de forma eficiente das conexões com o banco de dados, deve ser eficiente devido à enorme quantidade de recursos consumidos para abrir e fechar. Para permitir ao usuário a possibilidade de executar uma ou mais sentenças por um conjunto de operações no banco de dados, temos o gerenciador de transações.
4.9 Toplink Essentials
O TopLink foi desenvolvido por The Object People, em Smaltalk, nos anos 90. Em 2002, a Oracle Corporation adquiriu dando continuidade em seu desenvolvimento. TopLink Essentials é uma RI (Reference Implementation) de EJB 3.0, Java Persistence API fornece um poderoso e flexível framework para os objetos Java. Também é um framework de persistência, para mapear dados originalmente armazenados no modelo relacional em modelo de objetos, com facilidade para elaborar queries dinâmicas e sofisticadas (GONÇALVES, E., 2008, p. 277).
4.10 Benchmark – avaliação de desempenho em banco de dados
Com grande diversidade de sistemas baseados no modelo relacional, a seleção nas ferramentas para desenvolvimento adequada as características da aplicação é inevitável. Passa ser fundamental a comparação entre desempenhos que melhor satisfaça os requisitos desejados. Em conseqüência, a criação de testes que permitam uma análise em condições padronizadas.
As avaliações em sistemas informatizados são realizadas com a utilização de benchmarks conforme Vieira, Durães e Madeira (2005, p. 72), os quais proporcionam padrões na avaliação de desempenho em sistemas e devem possuir as seguintes características para serem considerados válidos.
Representatividade: os benchmarks devem representar sistemas reais.
Portabilidade: os benchmarks devem ser portáveis para diferentes plataformas, proporcionando assim, comparativos de desempenhos entre diversos distribuidores de sistemas.
Repetibilidade: quando um benchmark é aplicado no mesmo ambiente, mais de uma vez, ele deve produzir resultados semelhantes.
Escalabilidade: essa característica prevê que os benchmarks realizem avaliações em ambientes com diferentes capacidades.
Não Intrusividade: na necessidade de avaliar outro ambiente deve-se realizar o mínimo ou nenhuma alteração nesse novo ambiente.
Simplicidade: os benchmarks devem ser de fácil implementação e utilização pelos usuários que farão as avaliações.
“Os procedimentos e regras que devem ser seguidos durante a execução da benchmark devem ser claramente definidos durante a sua especificação.” (VIEIRA, DURÃES e MADEIRA, 2005, p. 3)
Temos uma diversidade de sistemas que manipulam e armazenam as informações com recursos variados. A necessidade de comparar desempenhos e características, conduz a uma forma natural para o gestor tomar decisões que satisfaçam os requisitos da aplicação, na criação de testes para comparar os sistemas em condições semelhantes, com atenção na tecnologia e padrões nos cenários utilizados.
5. METOLOGIA DE DESENVOLVIMENTO DA PESQUISA
Uma métrica é necessária para medir ou mensurar alguma técnica aplicada, muito utilizada em processos de qualidade para produção de software, com análise de classes do programa, quantidade de linhas de código, relação de tempo com custo no seu desenvolvimento.
Aplicaremos o método quantitativo apresentando um estudo de caso do projeto, estrutura padrão, acesso a banco de dados, com a implementação de programa para administrar as consultas em cada método utilizado, avaliando tempo de acesso de início e término das rotinas e seus possíveis pontos críticos.
Figura 6 – Estrutura de um benchmark Fonte: Novais, J.L.P. (2006, p. 46)
Na estrutura do benchmark utilizaremos check-point apresentado na figura 6, como metodologia de avaliação para obter tempo gasto entre requisição de consulta e seu tempo de resposta, faremos para fins de padronização 10.000 persistências em 6 tabelas e a realização da pesquisa em 21 consultas com variações de uma, cem e mil com indexação e não indexado ou associações múltiplas. Para impedir uma interferência externa, a rede local não foi utilizada para testagem dos procedimentos.
A forma de apresentação das tabulações será uma comparação direta com os resultados em forma de colunas.
5.1 Procedimentos metodológicos:
Os testes de desempenho com a metodologia proposta por DEMURJIAN, (1985, p. 17), na qual a maneira de obtenção do tempo gasto entre a requisição de uma consulta e o retorno da sua resposta é enfatizada. Nesta metodologia é utilizado o conceito de check-point, onde são criados pontos de recuperação do tempo nas requisições de consultas ao SGBD. Esta recuperação pode ser realizada através de alguma linguagem de programação, gravando-se os tempos de relógio do sistema em dois momentos: na requisição e na obtenção da resposta. Calculamos a diferença entre o tempo do momento de obtenção da resposta e o tempo do momento da requisição.
RES = T2 – T1
T1: Tempo obtido no momento da requisição. T2: Tempo obtido no momento da resposta. RES: Tempo de resposta.
1 package cadastro;
2 import model.Departamento; 3 import dao.DepartamentoDao;
4 public class CadastroDepartamento { 5 public static void main(String[] args) {
6 CadastroDepartamento cadastro = new CadastroDepartamento();
7 DepartamentoDao departamentoDao = new DepartamentoDao();
8 Long inicial = System.currentTimeMillis();
9 cadastro.cadastraDepartamentos();
10 Long result = (System.currentTimeMillis() - inicial);
11 System.out.println("Tempo gasto no Departamento ...: " + result); // ---
12 }// end main
Na linha 8 recebemos o tempo do relógio do sistema antes da consulta, em seguida a solicitação ao método na linha 9 e obtemos o tempo de realização da consulta na linha 10, pela subtração entre o tempo final e o tempo inicial apresentado na linha 11. O trecho do código da Quadro 1 está escrito em Java e as anotações do número da linha foram acrescentadas para melhor entendimento.
5.2 Seleção do conjunto de consultas
De acordo com Boral e Dewitt (1984, p. 5), 21 consultas são o suficiente para analisar o desempenho de um sistema de bancos de dados. As consultas em bancos de dados consomem basicamente dois recursos de sistema:
a) Ciclos de CPU: são consumidos tanto pelo sistema que executa a consulta (a aplicação) e outras funções executadas pelo próprio SGBD. Ciclos de CPU também são consumidos pelo Sistema Operacional na iniciação das operações de disco.
b) Operações de Disco: são consumidos durante a recuperação dos dados requeridos para responder uma consulta, armazenar dados de uma consulta no disco ou atividades de swapping.
Boral e Dewitt (1984, p. 5), definem que quatro tipos de consultas são necessárias para a realização da análise de desempenho em sistemas de bancos de dados.
Grupos Utilização de CPU Utilização de Disco
Tipo 1 Baixo Baixo
Tipo 2 Baixo Alto
Tipo 3 Alto Baixo
Tipo 4 Alto Alto
6 AMBIENTE PARA EXECUÇÃO DOS TESTES
De acordo com Vieira, Durães e Madeira (2005, p.72), uma das características necessárias para que um benchmark de bancos de dados seja considerado válido é a representatividade, que consiste em representar sistemas reais. Os testes serão realizados utilizando-se parte da infra-estrutura de uma aplicação. Neste caso não serão considerados as telas e funcionalidades avançadas da aplicação, apenas sua estrutura básica.
Os SGBDs utilizados nos testes não sofrerão nenhuma alteração em suas configurações, com o objetivo de manter a homogeneidade do ambiente. Assim, todos os SGBDs serão instalados com sua configuração padrão e todas as consultas serão padronizadas, sem o uso de instruções específicas de um SGBD em particular.
Utilizamos tecnologia Java para programação em conjunto com vários recursos: a ide Eclipse Java EE para Desenvolvimento Web, framework Hibernate distribuição hibernate-distribuition-3.6.0.Final-dist e Toplink Essentials distribuição glassfish-persistence-installer-v2.1-b60.jar, Java JDK 6u20, banco MySql 5.1.36, Workbench 5.11 OSS instalado no sistema operacional Windows XP SP2.
Para equipamento um microcomputador com processador Intel Core 2 Duo com cache L2 de 2Mb, H.D 120 GB SATA de 7200 rpm, 2 GB Memória Ram.
6.1 – Base de dados utilizada
Uma das decisões iniciais foi à escolha do banco de dados a ser aplicado no projeto. Utilizamos alguns critérios ao definirmos esta opção, a de documentação que forneçam exemplos, fóruns, artigos e livros, para facilitar nosso trabalho. Amplo reconhecimento na comunidade de software e ser de distribuição livre. Uma das opções foi o MySql 5.1.36 instalado no pacote WampServer 2.0 para plataforma Windows, que se integra facilmente com o Workbench nos fornecendo uma melhor produtividade em todas alterações necessárias.
6.2 Modelo de entidade e relacionamento
O framework traz a facilidade de encapsular o conceito de tabelas, para que os responsáveis pelo desenvolvimento trabalhem as classes com melhor organização do modelo.
Figura 7 – Diagrama gerado no workbanch
Com o diagrama exibido na Figura 7, temos detalhado a organização das tabelas e seus atributos, que possuem relacionamento no projeto.
6.3 Projeto
Seguimos criando um novo projeto com Eclipse, é necessário adicionar as bibliotecas conforme seção 6.4, estão descrita características baseadas na API JPA, não sendo específicas da implementação Hibernate ou TopLink. Para permitir a utilização de outras soluções com mesmo modelo.
6.4 – Bibliotecas
Antes de iniciarmos o desenvolvimento da aplicação, precisamos configurar o ambiente para utilização da JPA, em conjunto com o framework escolhido.
Figura 8 – Bibliotecas Hibernate
Apresentamos na figura 8, as bibliotecas aplicadas no projeto com Hibernate pacote hibernate-distribuition-3.6.0.Final-dist, Arquivos do JavaServer Faces v2.0 disponível no site oficial do Mojara pacote mojarra-2.0.3-FCS-binary.zip, o conjunto
de tags de apoio para o desenvolvimento web JSTL (Java Standard Tag Library) jstl-1.2.jar.zip, alguns arquivos Apache Commons o commons-beanutils-1.8.3-bin.zip para componentes JavaBeans, commons-collections-3.2.1-commons-beanutils-1.8.3-bin.zip extensão Java 2 SDK Collections Framework, commons-digester-2.1-bin.zip processamento de arquivos XML, commons-logging-1.1.1-bin.zip para geração de mensagens log, slf4j-1.6.1 biblioteca complementar do Hibernate, para BD MySql utilizamos o driver mysql-connector-java-5.1.14-bin.jar.
Figura 9 – Bibliotecas TopLink
Para mantermos uma padronização do modelo aplicado, procuramos alterar apenas as bibliotecas necessárias commons-lang-2.2.jar, essentials.jar e toplink-essentials-agent.jar para adequado funcionamento.
6.5 Arquivo de configuração persistence.xml
Contém as configurações para acesso, dialeto, provedor de persistência entre outros. No Quadro 3 temos o Hibernate e no Quadro 4 o TopLink, pois a JPA sozinha não faz a persistência. O persistence.xml conectará ao banco de dados no lugar de sua aplicação, portanto ele precisará saber como obter as conexões. A distribuição do Hibernate contém a JPA 2.0, para mantermos uma padronização no projeto limitamos o acesso aos recursos da JPA 1.0, já que o TopLink disponibiliza a implementação nesta versão.
<persistencexmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unitname="empresa"transaction-type="RESOURCE_LOCAL"> <provider>org.hibernate.ejb.HibernatePersistence</provider>
<class>model.Sexo</class> <class>model.Projeto</class> <class>model.Empregado</class> <class>model.Dependente</class> <class>model.DepartamentoLocal</class> <class>model.Departamento</class> <class>model.EmpregadoProjeto</class> <class>model.Parentesco</class>
<properties>
<propertyname="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"></property>
<propertyname="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/empresa"></property>
<propertyname="javax.persistence.jdbc.user"value="root"></property> <propertyname="javax.persistence.jdbc.password"value=""></property>
</properties> </persistence-unit> </persistence>
Quadro 3: Arquivo persistence.xml com Hibernate
<persistencexmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unitname="empresa"transaction-type="RESOURCE_LOCAL"> <provider>oracle.toplink.essentials.PersistenceProvider</provider>
<class>model.Sexo</class> <class>model.Projeto</class> <class>model.Empregado</class> <class>model.Dependente</class> <class>model.DepartamentoLocal</class> <class>model.Departamento</class> <class>model.Parentesco</class> <class>model.EmpregadoProjeto</class>
<properties>
<!-- <property name="toplink.logging.level" value="FINE"/> --> <propertyname="toplink.jdbc.driver"value="com.mysql.jdbc.Driver"/> <propertyname="toplink.jdbc.url"
value="jdbc:mysql://localhost:3306/empresa"/>
<propertyname="toplink.jdbc.user"value="root"/> <propertyname="toplink.jdbc.password"value=""/> </properties>
</persistence-unit> </persistence>
Quadro 4: Arquivo persistence.xml com TopLink
Em toplink.jdbc.user definimos o nome do usuário para acesso ao banco de dados, em toplink.jdbc.password a senha, na toplink.jdbc.url definimos a url, jdbc, na propriedade toplink.jdbc.driver o driver necessário e toplink.logging.level qual tipo de log devem gerar, mas em nosso projeto está desativado.
6.6 Entiny manager
Para a entidade estar persistente é necessário uma associação a um contexto, que fornece a conexão entre as instâncias e o banco de dados. O objeto EntityManager controla o acesso ao banco de dados, pode persistir um POJO no banco, fazer a recuperação, remover, agregado a consultas específicas.
As entidades são objetos simples java, o entity manager faz a gerência das instâncias da entidades, para que as modificações se reflitam no banco com sincronia em uma aplicação com JPA.
Figura 10 – Ciclo de vida dos objetos Fonte: Bauer, C.; King, G. (2005, p. 116)
O estado do ciclo determina as ações possíveis, conforme a Figura 10 que exemplifica o controle do ciclo. O estado Transiente são instanciados com o operador new, não são persistentes e não gerenciados pelo EntityManager.
No estado Persistente existe um vínculo com o banco de dados, que está sincronizado com a instância obtida através do EntityManager, associado a um contexto persistente.
Para o estado Desligado (Detached), são as instâncias persistentes não gerenciadas pelo fechamento da transação que pertenciam, seu estado pode não estar mais sincronizado com o banco.
1 package conexao;
2 import javax.persistence.EntityManager;
3 import javax.persistence.EntityManagerFactory; 4 import javax.persistence.Persistence;
5 public class HibernateJpaUtil {
6 private EntityManagerFactory emf;
7 public EntityManager getEntityManager(){
//responsavel pela persistencia
8 return emf.createEntityManager();
9 }
10 public HibernateJpaUtil() {
//chamo ele de reprodutor da instância
11 emf = Persistence.createEntityManagerFactory("empresa");
/* o nome passado vem do arquivo persistence.xml que contém as configs
* para conexão com o BD. */
12 }
13 }
Quadro 5: Entity Manager
É demostrado na Quadro 5 uma fábrica de conexão, onde criamos um reprodutor da instância na linha de comando nº 11, que recebe do arquivo persistence.xml as configurações conforme o quadro 3 ou 4, responsável pela persistência o Entity Manager consta na linha 7 que recebe o retorno da instância criada.
6.7 Mapeamento das classes
Devemos mapear os arquivos com Annotations, para definir as propriedades e relacionamentos das classes, não temos a pretensão de abordar todas técnicas existentes, recursos disponíveis e as tecnologias aplicadas aos frameworks com a JPA, mas exemplificar com detalhamento os passos seguidos no desenvolvimento do projeto, para referência de uma possível reprodução futura.
Figura 11 – Anotações básicas para mapeamento
Na figura 11 alguns exemplos mais utilizados de relacionamentos com Annotations, também chamados de associações entre as entidades.
Conceito relacional Conceito orientado a objetos com Java
Tabela Classe
Coluna Atributo
Registro Instância de um objeto
Tipo de dado char, varchar, etc Java.lang.String Integer (números inteiros em geral) Int, Integer Number (números decimais em geral) Double, float
Quadro 6 : Comparativo na associação de conceito Fonte: Luckow, D.H; Melo, A.A. (2010, p. 552)
No Quadro 6, apresentamos um comparativo entre o conceito relacional e o conceito orientado a objetos.
Figura 12 – Tabela departamento
Utilizaremos em nossa base de dados a tabela departamento, detalhada na figura 12 com relacionamento @OneToMany com a classe Empregado para criação de nossa entidade, que seria o mapeamento dos atributos de uma classe.
package model;
import java.io.Serializable;
import java.util.Date;
import javax.persistence.*; @Entity
@Table (name="departamento")
publicclass Departamento implements Serializable {
privatestaticfinallongserialVersionUID = 1682862344999118414L; @Id
@Column(name="idDepartamento")
private Integer idDepartamento; @Column(name="descr")
private String descr;
@Column(name="inicioDeptoData")
private Date inicioDeptoData;
public Integer getIdDepartamento() {
returnidDepartamento; }
publicvoid setIdDepartamento(Integer idDepartamento) {
this.idDepartamento = idDepartamento;
}
public String getDescr() {
returndescr; }
publicvoid setDescr(String descr) {
this.descr = descr;
}
public Date getInicioDeptoData() {
returninicioDeptoData; }
publicvoid setInicioDeptoData(Date inicioDeptoData) {
this.inicioDeptoData = inicioDeptoData;
}
publicstaticlong getSerialversionuid() {
returnserialVersionUID; }
Quadro 7: Mapeamento da Classe Departamento
A classe Departamento representada no Quadro 7 possui mapeamentos de atributos com anotações, @Entity declara que a classe é uma entidade com referência a uma tabela no banco de dados, um elemento principal que determina uma classe ser POJO (Plain Old Java Object), passando a persistíveis nos padrões da JPA, @Table com atributo name para definir o nome da tabela, mas geralmente tem o mesmo nome da classe, @Id correspondente a uma chave primária como identificador único, @Column com atributo name para os nomes dos campos, acompanhados dos métodos get e set.
Figura 13 – Tabela dependente
A Figura 13 representa a tabela dependente, com campos diferenciados temos idDependente e idEmpregadoFk definido como chave primária composta também por uma chave estrangeira, idSexoFk e idParentescoFk são chaves estrangeiras com relacionamento N:1 com a tabela Empregado, Sexo e Parentesco conforme apresentado na Figura 7 com diagrama gerado no workbanch.
package model; import javax.persistence.*; import java.io.Serializable; import java.sql.Date; import model.Empregado; import model.Sexo; @Entity
@Table(name="dependente")
publicclass Dependente implements Serializable{
privatestaticfinallongserialVersionUID = 6123230227914565573L; @Id
@Column(name="idDependente")
private Integer idDependente; @ManyToOne
@JoinColumn(name="idEmpregadoFk")
private Empregado empregado; @Column(name="nome")
private String nome;
@Column(name="nascimento")
private Date nascimento; @ManyToOne
@JoinColumn(name="idSexoFk")
@ManyToOne
@JoinColumn(name="idParentescoFk")
private Parentesco parentesco;
public Integer getIdDependente() {
returnidDependente; }
publicvoid setIdDependente(Integer idDependente) {
this.idDependente = idDependente;
}
public Empregado getEmpregado() {
returnempregado; }
publicvoid setEmpregado(Empregado empregado) {
this.empregado = empregado;
}
public String getNome() {
returnnome; }
publicvoid setNome(String nome) {
this.nome = nome; }
public Date getNascimento() {
returnnascimento; }
publicvoid setNascimento(Date nascimento) {
this.nascimento = nascimento;
}
public Parentesco getParentesco() {
returnparentesco; }
publicvoid setParentesco(Parentesco parentesco) {
this.parentesco = parentesco;
}
public Sexo getSexo() {
returnsexo; }
publicvoid setSexo(Sexo sexo) {
this.sexo = sexo; }
publicstaticlong getSerialversionuid() {
returnserialVersionUID; }
}
Quadro 8: Mapeamento da Classe Dependente
O Quadro 8 nos apresenta a utilização do @ManyToOne com o @JoinColumn e seu atributo name, que define a coluna proprietária do relacionamento que guardará o valor da associação, é responsável por indicar explicitamente o nome da coluna que guarda a chave estrangeira. Ocorrendo com idEmpregadoFk, idSexoFk e idParentescoFk, na linha seguinte temos uma variável
tipo private da Classe relacionada Empregado, Sexo, Parentesco que receberá as informações vinculadas.
Figura 14 – Tabela empregadoProjeto
Na tabela empregadoProjeto exibida na Figura 14, os campos idEmpregadoFk e idProjetoFk definidos como chave primária composta por chave estrangeira, seu relacionamento N:N com a tabela empregado e projeto de acordo com a Figura 7 com diagrama gerado no workbanch.
package model; import java.io.Serializable; import javax.persistence.*; import model.Empregado; import model.Projeto; @Entity @Table(name="empregadoProjeto")
public class EmpregadoProjeto implements Serializable {
private static final long serialVersionUID = -6286112162452026428L; @Id
@Column(name="id") private Integer id; @ManyToOne
@JoinColumn(name="idEmpregadoFk") private Empregado empregado; @ManyToOne
@JoinColumn(name="idProjetoFk") private Projeto projeto;
public Integer getId() { return id; }
public void setId(Integer id) { this.id = id;
public Empregado getEmpregado() { return empregado;
}
public void setEmpregado(Empregado empregado) { this.empregado = empregado;
}
public Projeto getProjeto() { return projeto; }
public void setProjeto(Projeto projeto) { this.projeto = projeto;
}
public static long getSerialversionuid() { return serialVersionUID; }
}
Quadro 9: Mapeamento da Classe EmpregadoProjeto
Estamos neste mapeamento do Quadro 9 demostrando o @ManyToMany, mas pela exigência da aplicação de modelo único no desenvolvimento, optamos por facilitar este relacionamento com o uso do @ManyToOne para executar o trabalho do muitos para muitos, já que teremos nesta tabela muitos empregados e muitos projetos, na tentativa de simplificar a associação.
6.8 Pesquisas no banco de dados (JPQL)
Para realizar consultas orientada a objetos utilizamos uma linguagem de consulta específica JPQL (Java Persistence Query Language), que oferece recursos que realizam consultas complexas equivalente aos baseados no modelo relacional. Em qualquer classe Java podemos definir as consultas JPQL, utilizamos o método createQuery() com uma string para consultas dinâmicas. Mesmo com uma flexibilidade importante, esta pode prejudicar o desempenho, pois será processado sempre pelo provedor ao executar o método.
“Esta é uma linguagem de consultas independente de banco de dados e opera no modelo de entidades lógicas, ao contrário do modelo de dados físico.”
// --- GRUPO 1---
public Departamento buscarDepartamentoQuery (Integer codigo) { EntityManager em = getEntityManager() ;
Departamento departamento = new Departamento();
try {
Query consulta = em.createQuery("select d from Departamento d where d.idDepartamento = :codigo").setParameter("codigo", codigo);
// Retorna um resultado
Departamento con = (Departamento)consulta.getSingleResult(); return (Departamento)consulta.getSingleResult(); }finally { em.close(); } }
Quadro 10: Consulta classe Departamento com grupo 1
No quadro 10 selecionamos por createQuery uma tupla entre dez mil, pesquisa por campo indexado.
/// --- GRUPO 2 ---
public List<Departamento> departamentoGrupo2() { EntityManager em = getEntityManager();
try {
//- Grupo 2 - Selecionar 100 tuplas de 10.000 não indexado (limite de 100)
Query consulta = em.createQuery("from Departamento d where d.descr like 'Descr depto%' and d.idDepartamento > 5000");
consulta.setFirstResult(0); // parametro limite Inicial consulta.setMaxResults(100); // parametro limite Final
List<Departamento>departamentos = consulta.getResultList();
for(Departamento d : departamentos){
System.out.println("Cada descrição Departamento: " + d.getDescr()); } return consulta.getResultList(); }finally { em.close(); } }
Quadro 11: Consulta classe Departamento com grupo 2
No quadro 11 selecionamos por createQuery cem tuplas entre dez mil, pesquisa por campo não indexado.
// --- GRUPO 3 ---
public List<Dependente> dependenteGrupo3() { EntityManager em = getEntityManager();
try {
//- Grupo 3 - Selecionar 1.000 tuplas de 10.000 utilizando índice com relação a outra tabela com 10.000
Query consulta = em.createQuery("select d from Dependente d left join fetch d.sexo left join fetch d.sexo where d.sexo.idSexo = 2");
consulta.setFirstResult(0); consulta.setMaxResults(1000);
List<Dependente>dependentes = consulta.getResultList(); for(Dependente d : dependentes){
System.out.println("Descr. Dependente: " + d.getNome() ); } return consulta.getResultList(); }finally { em.close(); } }
Quadro 12: Consulta classe Dependente com grupo 3
Apresentamos no quadro 12 a seleção de um mil tuplas entre dez mil, por com campo indexado e relação com outra tabela com dez mil registros.
// --- GRUPO 4 ---
public List<Dependente> dependenteGrupo4() { EntityManager em = getEntityManager();
try {
//- Grupo 4 - Selecionar 100 registros com função agregada 10.000 tuplas Query consulta = em.createQuery("select count(d) from Dependente d where d.empregado.idEmpregado = 1 and idDependente <= 100");
return consulta.getResultList(); }finally { em.close(); } }
Quadro 13: Consulta classe Dependente com grupo 4
Utilizamos uma função agregada no Quadro 13, em uma tabela com dez mil tuplas, relacionada com cem registros.
7 EXECUÇÃO DOS TESTES
Para um ambiente sugerido na metodologia, foram persistidas as tabelas com um conjunto significativo de dados, visando um ambiente próximo de uma situação real, com a persistência em 6 tabelas com 10.000 registros com tamanhos variados, totalizando 60.000 registros para preenchimento de acordo com a metodologia aplicada, na tabela sexo com 2 registros e tabela parentesco com 9 registros cadastrados.
A realização dos testes foi baseada nas consultas propostas por Boral e Dewitt (1984), onde é possível avaliar o comportamento do acesso ao SGBD de acordo com o uso de CPU e memória. Estes registros serão aplicados para todas as consultas, visando manter a uniformidade dos testes.
Persistir Carga de trabalho
A Persistir 10000 Departamentos
B Persistir 10000 Localização
C Persistir 10000 Empregados
D Persistir 10000 Dependentes
E Persistir 10000 Projetos
F Persistir 10000 Empregados do projeto
G Persistir 00002 Sexo
H Persistir 00009 Parentesco
Quadro 14: Carga de trabalho nos testes
No quadro 14 as tabelas foram preenchidas com a quantidade de registros para sua carga de trabalho.
Grupo 1 (Selecionar 1 tupla de 10.000 indexado)
A Selecionar um departamento de 10000
B Selecionar uma localização de 10000
C Selecionar um empregado de 10000
D Selecionar um dependente de 10000
E Selecionar um projeto de 10000
F Selecionar um empregado do projeto de 10000
No quadro 15 selecionamos por createQuery uma tupla entre dez mil, pesquisa por campo indexado.
Grupo 2 (Selecionar 100 tuplas de 10.000 usando não indexado)
A Selecionar cem departamentos de 10000
B Selecionar cem localizações de 10000
C Selecionar cem empregados de 10000
D Selecionar cem dependentes de 10000
E Selecionar cem projetos de 10000
F Selecionar cem empregados dos projetos de 10000
Quadro 16: Consulta do Grupo 2
No quadro 16 selecionamos por createQuery cem tuplas entre dez mil, pesquisa por campo não indexado.
Grupo 3 Selecionar 1.000 tuplas de 10.000 utilizando índice com relação a outra tabela com 10.000
A Selecionar um mil localizações de 10000 (que seja do depto 1)
B Selecionar um mil empregados de 10000 (que seja do depto 2)
C Selecionar um mil dependentes de 10000 (com sexo feminino 2)
D Selecionar um mil projetos de 10000 (que seja da localização 3)
E Selecionar um mil empregados dos projetos de 10000 (que
esteja no projeto 3) Quadro 17: Consulta do Grupo 3
Apresentamos no quadro 17 seleção de um mil tuplas entre dez mil, por com campo indexado e relação com outra tabela com dez mil registros.
Grupo 4 Função agregada em uma tabela com 10.000 tuplas
(relacionada com 100 partições)
A Selecionar cem empregados com função agregada e relação
com 10000 departamentos
B Selecionar cem empregados do projeto com função agregada e
relação com 10000 projetos
C Selecionar cem dependentes com função agregada e relação
com 10000 empregados
D Selecionar cem projetos com função agregada e relação com
10000 departamento local Quadro 18: Consulta do Grupo 4
Utilizamos uma função agregada no Quadro 18, em uma tabela com dez mil tuplas, relacionada com cem registros.
Ordem de Execução Itens do Grupo Grupo 1 A, B, C, D, E, F Grupo 2 A, B, C, D, E, F Grupo 3 A, B, C, D, E Grupo 4 A, B, C, D
Quadro 19: Ordem da execução dos testes
No Quadro 19 está detalhado a ordem de execução dos testes, exemplifica por grupo quais o itens utilizados.
Nas atividades realizadas foi construído uma aplicação, com modelo comum de B.D para utilização do Framework para realizar ORM. Definimos as métricas aplicadas no Benchmark e preenchimento das tabelas de acordo com o planejamento. Fizemos a preparação do aplicativo para o ambiente de testes, executamos as rotinas definidas em sua ordem e por fim avaliação dos testes nas métricas e seus resultados.
Foram realizadas 21 consultas em 6 tabelas com configuração padrão, para cada Framework. Antes da aplicação dos testes em cada grupo o Windows foi reiniciado e na seqüência iniciado o Wamp para carregar o MySql, depois o Eclipse em diretório padrão, por último o Apache Tomcat.
Para não ocorrer aproveitamento de cache dos componentes envolvidos, antes de cada item testado os servidores foram parados e novamente reiniciados.
8 APRESENTAÇÃO DOS RESULTADOS
Foram executados vários testes, os resultados registrados serão apresentados em gráficos para facilitar a compreensão e usa visualização.
Além da técnica ao programar, uma linguagem adequada e a forma de armazenamento na construção de um projeto, temos que incluir o método de persistência e recuperação das informações, um fator importante influenciando diretamente no desempenho de acesso ao SGBD.
Figura 15: Comparação entre as pesquisas do Grupo 1
No Grupo 1 são representadas consultas de baixo uso de processador e disco, resulta na busca indexada de um registro entre as dez mil da tabela. Conforme a figura 15, observamos que item A referente departamento e B localização com o Hibernate, apresentou um desempenho de até 63,04% superior aos demais. GRUPO 1 0 500 1000 1500 2000 2500 3000 M il is s e g u n d o s Hibernate 687 656 2406 2438 2360 2157 TopLink 1859 1469 2578 2594 2578 2422 A B C D E F
Figura 16: Comparação entre as pesquisas do Grupo 2
Representadas no Grupo 2 consultas com baixa utilização de processador, mas com alto acesso a disco, onde resulta na busca não indexada de cem linhas entre dez mil da tabela, apresentado na figura 16. Novamente o item A referente departamento e B localização com o Hibernate, superou em até 59,35% em relação aos outros.
Figura 17: Comparação entre as pesquisas do Grupo 3
GRUPO 2 0 500 1000 1500 2000 2500 3000 M il is s e gu nd os Hibernate 718 671 2453 2438 2453 2406 TopLink 1766 1485 2594 2657 2625 2594 A B C D E F GRUPO 3 0 1000 2000 3000 4000 M il is s e g u n d o s Hibernate 1078 2656 2750 2594 2562 TopLink 2328 2953 3141 3015 3422 A B C D E
Na consulta do Grupo 3 na figura 17, possuem alta utilização de processador e baixo acesso a disco, recuperamos os objetos através de junções entre duas classes relacionadas, com busca indexada de um mil linhas com relação a outra tabela de dez mil. Todos itens com junções as operações ficaram mais lentas, mas demonstrou eficiência nas consultas realizadas por junções entre as tabelas.
Figura 18: Comparação entre as pesquisas do Grupo 4
Para o Grupo 4, consiste na alta utilização de processador e alto acesso a disco, aplicado função agregada para selecionar cem linhas com relação a outra tabela de dez mil, através de junções entre classes apresentados na figura 18. Os resultados foram similares não sendo tão eficiente sua otimização nas consultas realizados pelo Hibernate.
GRUPO 4 0 1000 2000 3000 4000 M il is s e g u n d o s Hibernate 2954 2156 2297 2391 TopLink 3250 2672 2500 2422 A B C D
