Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Especialização em Desenvolvimento de Sistemas para Web

Transcrição

1 Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática 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 Maringá, 2011

2 JADER DOS SANTOS TELES CORDEIRO 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 Maringá, 2011

3 JADER DOS SANTOS TELES CORDEIRO 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

4 AGRADECIMENTOS 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. Aos companheiros da especialização, com quem aprendi muito.

5 RESUMO 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. Palavras-chave: Mapeamento Objeto-Relacional, persistência.

6 ABSTRATIC 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. Work-key: Objeto Relacional Mapping, persistence.

7 LISTA DE ILUSTRAÇÕES FIGURA 1 - ESTADO DO SISTEMA DURANTE A TRANSAÇÃO FIGURA 2 - EXEMPLO DE MAPEAMENTO FIGURA 3 - EXEMPLO DE MAPEAMENTO OBJETO-RELACIONAL FIGURA 4 - ARQUITETURA DO JPA JAVA API PERSISTENCE FIGURA 5 - ARQUITETURA SIMPLIFICADA DO HIBERNATE FIGURA 6 - ESTRUTURA DE UM BENCHMARK FIGURA 7 - DIAGRAMA GERADO DO WORKBANCH FIGURA 8 - BIBLIOTECAS HIBERNATE FIGURA 9 - BIBLIOTECAS TOPLINK FIGURA 10 - CICLO DE VIDA DOS OBJETOS FIGURA 11 - ANOTAÇÕES BÁSICAS PARA MAPEAMENTO FIGURA 12 - TABELA DEPARTAMENTO FIGURA 13 - TABELA DEPENDENTE FIGURA 14 - TABELA EMPREGADOPROJETO FIGURA 15 - COMPARAÇÃO ENTRE AS PESQUISAS DO GRUPO FIGURA 16 - COMPARAÇÃO ENTRE AS PESQUISAS DO GRUPO FIGURA 17 - COMPARAÇÃO ENTRE AS PESQUISAS DO GRUPO FIGURA 18 - COMPARAÇÃO ENTRE AS PESQUISAS DO GRUPO

8 LISTA DE TABELAS QUADRO 1 - APLICAÇÃO DO CHECK-POINT QUADRO 2 - TIPOS DE CONSULTAS PARA ANÁLISE DE DESEMPENHO QUADRO 3 - ARQUIVO PERSISTENCE.XML COM HIBERNATE QUADRO 4 - ARQUIVO PERSISTENCE.XML COM TOPLINK QUADRO 5 - ENTITY MANAGER QUADRO 6 - COMPARATIVO NA ASSOCIAÇÃO DE CONCEITO QUADRO 7 - MAPEAMENTO DA CLASSE DEPARTAMENTO QUADRO 8 - MAPEAMENTO DA CLASSE DEPENDENTE QUADRO 9 - MAPEAMENTO DA CLASSE EMPREGADOPROJETO QUADRO 10 - CONSULTA CLASSE DEPARTAMENTO COM GRUPO QUADRO 11 - CONSULTA CLASSE DEPARTAMENTO COM GRUPO QUADRO 12 - CONSULTA CLASSE DEPENDENTE COM GRUPO QUADRO 13 - CONSULTA CLASSE DEPENDENTE COM GRUPO QUADRO 14 - CARGA DE TRABALHO NOS TESTES QUADRO 15 - CONSULTA DO GRUPO QUADRO 16 - CONSULTA DO GRUPO QUADRO 17 - CONSULTA DO GRUPO QUADRO 18 - CONSULTA DO GRUPO QUADRO 19 - ORDEM DA EXECUÇÃO DOS TESTES... 46

9 LISTA DE SIGLAS API BD DDL DBMS DML HQL IDE JDBC JPA JPQL JSTL JVM LGPL ORM POJO RI SGDB SQL XML Application Program Interface Banco de Dados Data Definition Language Database Management System Data Manipulation Language Hibernate Query Language Integrated Development Environment Java Database Connectivity Java Persistence API Java Persistence Query Language Java Standard Tag Library Java Virtual Machine Lesser GNU Public License Object Relation Mapping Plain Old Java Objects Reference Implementation Sistema Gerenciador de Banco de Dados Structured Query Language Extensible Markup Language

10 SUMÁRIO 1 INTRODUÇÃO Definição do Problema Justificativa Motivação Limitação da pesquisa Objetivo geral Objetivos específicos REVISÃO BIBLIOGRÁFICA Persistência de dados Persistência de Objetos Banco de dados Modelo relacional Mapeamento Objeto-Relacional Framework Java Persistence API Hibernate Toplink essentials Benchmark avaliação de desempenho em banco de dados METODOLOGIA DE DESENVOLVIMENTO DA PESQUISA Procedimentos metodológicos Seleção do conjunto de consultas AMBIENTE PARA EXECUÇÃO DOS TESTES Base de dados utilizada Modelo de entidade e relacionamento Projeto Bibliotecas Arquivo de configuração persistence.xml Entiny manager Mapeamento das classes Pesquisa no banco de dados (JPQL) EXECUÇÃO DOS TESTES...44

11 8 APRESENTAÇÃO DOS RESULTADOS CONSIDERAÇÕES FINAIS...50 REFERÊNCIAS BIBLIOGRÁFICAS...53

12 11 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

13 12 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.

14 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.

15 14 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.

16 15 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. - Desempenho: Realizar as tarefas de formas eficiente.

17 16 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

18 17 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. - Um-para-muitos 1:N - Uma entidade A está associada a qualquer número

19 18 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)

20 19 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 objetorelacional. 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).

21 20 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

22 21 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 para reconhecer uma classe Java comum. A tabela é representada pela e a chave primária cada coluna 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)

23 22 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)

24 23 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) 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.

25 24 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.

26 25 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 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.

27 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); // // end main Quadro 1: Aplicação do check-point

28 27 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 Quadro 2: Tipos de consultas para análise de desempenho

29 28 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 final-dist e Toplink Essentials distribuição glassfish-persistence-installer-v2.1-b60.jar, Java JDK 6u20, banco MySql , 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 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.

30 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.

31 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 final-dist, Arquivos do JavaServer Faces v2.0 disponível no site oficial do Mojara pacote mojarra fcs-binary.zip, o conjunto

32 31 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 bin.zip para componentes JavaBeans, commons-collections bin.zip extensão Java 2 SDK Collections Framework, commons-digester-2.1-bin.zip processamento de arquivos XML, commons-logging bin.zip para geração de mensagens log, slf4j biblioteca complementar do Hibernate, para BD MySql utilizamos o driver mysql-connector-java 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, toplink-essentials.jar e toplinkessentials-agent.jar para adequado funcionamento.

33 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. <persistence xmlns=" xmlns:xsi=" xsi:schemalocation=" version="1.0"> <persistence-unit name="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> <property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.driver"></property> <property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/empresa"></property> <property name="javax.persistence.jdbc.user" value="root"></property> <property name="javax.persistence.jdbc.password" value=""></property> </properties> </persistence-unit> </persistence> Quadro 3: Arquivo persistence.xml com Hibernate

34 33 <persistence xmlns=" xmlns:xsi=" xsi:schemalocation=" version="1.0"> <persistence-unit name="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"/> --> <property name="toplink.jdbc.driver" value="com.mysql.jdbc.driver"/> <property name="toplink.jdbc.url" value="jdbc:mysql://localhost:3306/empresa"/> <property name="toplink.jdbc.user" value="root"/> <property name="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.

35 34 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.

36 35 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"); as configs /* o nome passado vem do arquivo persistence.xml que contém * para conexão com o BD. */ 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.

37 36 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 Tabela Coluna Registro Tipo de dado char, varchar, etc Integer (números inteiros em geral) Number (números decimais em geral) Conceito orientado a objetos com Java Classe Atributo Instância de um objeto Java.lang.String Int, Integer 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 com a classe Empregado para criação de nossa entidade, que seria o mapeamento dos atributos de uma classe.

38 37 package model; import java.io.serializable; import java.util.date; (name="departamento") public class Departamento implements Serializable { private static final long serialversionuid private Integer private String private Date iniciodeptodata; public Integer getiddepartamento() { return iddepartamento; public void setiddepartamento(integer iddepartamento) { this.iddepartamento = iddepartamento; public String getdescr() { return descr; public void setdescr(string descr) { this.descr = descr; public Date getiniciodeptodata() { return iniciodeptodata; public void setiniciodeptodata(date iniciodeptodata) { this.iniciodeptodata = iniciodeptodata; public static long getserialversionuid() { return serialversionuid; Quadro 7: Mapeamento da Classe Departamento A classe Departamento representada no Quadro 7 possui mapeamentos de atributos com 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 com atributo name para definir o nome da tabela, mas geralmente tem o mesmo nome da correspondente a uma chave primária como identificador com atributo name para os nomes dos campos, acompanhados dos métodos get e set.

39 38 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; public class Dependente implements Serializable{ private static final long serialversionuid private private Empregado private String private private Sexo sexo;

40 39 private Parentesco parentesco; public Integer getiddependente() { return iddependente; public void setiddependente(integer iddependente) { this.iddependente = iddependente; public Empregado getempregado() { return empregado; public void setempregado(empregado empregado) { this.empregado = empregado; public String getnome() { return nome; public void setnome(string nome) { this.nome = nome; public Date getnascimento() { return nascimento; public void setnascimento(date nascimento) { this.nascimento = nascimento; public Parentesco getparentesco() { return parentesco; public void setparentesco(parentesco parentesco) { this.parentesco = parentesco; public Sexo getsexo() { return sexo; public void setsexo(sexo sexo) { this.sexo = sexo; public static long getserialversionuid() { return serialversionuid; Quadro 8: Mapeamento da Classe Dependente O Quadro 8 nos apresenta a utilização com 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

41 40 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; public class EmpregadoProjeto implements Serializable { private static final long serialversionuid private private private Projeto projeto; public Integer getid() { return id; public void setid(integer id) { this.id = id;

42 41 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 mas pela exigência da aplicação de modelo único no desenvolvimento, optamos por facilitar este relacionamento com o uso 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. (GONÇALVES, E. 2008, p. 283)