Analisando a performance das Estratégias que realizam o Mapeamento Objeto Relacional no JPA

Transcrição

1 a r t i g o Analisando a performance das Estratégias que realizam o Mapeamento Objeto Relacional no JPA Analisando a performance das estratégias do mapeamento objeto relacional na prática Douglas Rocha Mendes concluiu o curso de Bacharelado em Informática pela Universidade Positivo em Concluiu o mestrado em Telemática na Universidade Federal Tecnológica do Paraná em No mesmo ano, publicou o artigo Bandwidth Fairness of a Single Rate Three Color Marker Algorithm Implementation no congresso internacional 8th IEEE International Conference on Communication Systems (ICCS 2002). Em julho de 2007, publicou o livro Redes de Computadores Teoria e Prática pela Editora Novatec. Em fevereiro de 2009 publicou o livro Programação Java com Ênfase em Orientação a Objetos. Trabalha com programação Java desde Atualmente está trabalhando na COPEL como analista de sistemas, desenvolvendo sistemas Java na plataforma J2EE, como também ministra aulas nas faculdades SPEI e Expoente. É professor da pós-graduação em Engenharia de Software da UFPR e de cursos de extensão da Universidade Positivo. Pode ser contatado pelo (douglas.mendes@copel.com). O artigo proposto descreve sobre a performance das três estratégias para mapear uma hierarquia de classes do modelo orientado a objetos para o modelo relacional. Será dado ênfase aos pontos positivos e negativos de cada uma das estratégias de mapeamento como também será apresentada uma análise de performance de cada uma das estratégias de mapeamento. Iremos dar ênfase nas operações de inserção, seleção e remoção de dados. Os testes de performance foram executados com o auxílio do framework JUnit e ainda foram utilizados os bancos de dados HSQLDB v. 1.69, FireBird v. 2.0 e MySQL v Estes testes podem ser baixados do site da revista e ser novamente executados em qualquer outro banco de dados. A ideia é apresentar inicialmente um estudo realizado, porém novos testes poderão ser executados a fim de ajudar no dia-a-dia de administradores de banco de dados como também de desenvolvedores e analistas da plataforma Java. 55

2 Q uando desenvolvemos sistemas orientados a objetos e usamos o JDBC para a persistência dos dados, utilizamos consultas no formato da linguagem SQL, que são executadas diretamente no banco de dados. Apesar de a linguagem SQL já ter sido exaustivamente explorada, esta possui algumas particularidades que muitas vezes impactam na produtividade do desenvolvimento de um software, principalmente quando a equipe de desenvolvimento está iniciando nesta tecnologia. Durante um projeto orientado a objetos é muito comum usarmos a linguagem SQL e realizarmos o mapeamento objeto relacional manualmente, ou seja, o analista e o programador juntos definem os modelos de classes e dados e ainda juntos formalizam como o acesso a estes dados deve ocorrer. Desta forma, não existe garantia que o acesso definido irá usufruir dos melhores métodos, causando muitas vezes a perda de performance e qualidade no acesso aos dados. Com o advento dos frameworks, algumas novidades foram disponibilizadas em relação ao mapeamento objeto relacional, sendo a principal delas que o mapeamento objeto relacional ocorre de forma automática. Os frameworks oferecem uma maior facilidade ao programador no momento de gravar, recuperar, remover ou atualizar dados no banco de dados. Desta forma, o programador consegue gravar ou acessar um objeto Java sem a necessidade de montar complexos comandos SQL, ou seja, todo mapeamento objeto relacional ocorre de forma automática. Um simples comando emitido pelo framework permite que todo o conteúdo de um conjunto de tabelas seja associado a um objeto Java, sendo que toda a complexidade gerada para este acesso fique abstraída pelo framework. É importante observar que as consultas continuam sendo executadas pela API JDBC através da linguagem SQL, porém o framework abstrai toda esta complexidade do programador. Esta abstração é que agrega produtividade no desenvolvimento de um software. Neste artigo iremos abordar sobre uma importante característica oferecida pelos frameworks de mapeamento objeto-relacional, mais especificamente, iremos apresentar detalhadamente todos os elementos envolvidos e necessários para o mapeamento de uma hierarquia de classes dispostas em uma herança para uma ou mais tabelas. No exemplo apresentado, iremos considerar todas as estratégias possíveis de herança presentes no framework JPA. O JPA (Java Persistence API) representa uma especificação padrão para o gerenciamento de persistência e mapeamento objeto relacional (ORM). Ainda neste artigo iremos apresentar a performance de cada uma das estratégias de herança, levando em consideração as operações de inserção, seleção e remoção de dados. Estes testes irão ocorrer nos bancos de dados HSQLDB, FireBird e MySQL. A ideia será permitir ao leitor escolher qual a melhor estratégia, levando em consideração a sua performance e o banco de dados utilizado. Todos os testes executados neste artigo podem ser estendidos a outros bancos de dados, bastando apenas que o leitor configure alguns arquivos XML. Será disponibilizado neste artigo como proceder os testes em outros banco de dados. Assim, para introduzir este importante assunto, iremos comentar sobre alguns conceitos presentes neste contexto, tais como: conceito de herança, conceito de polimorfismo, consultas polimórficas, as estratégias de herança SINGLE_TABLE, TABLE_PER_CLASS e JOINED. Desta forma, iremos buscar oferecer ao leitor informações para que este possa tomar a melhor decisão em relação a qual das estratégias de herança usar no seu projeto. Herança O conceito de herança está fundamentado na definição de uma classe com base em outra. A classe usada como referencial pode ser chamada de superclasse, classe mãe, classe-base ou generalização. A nova classe criada a partir de outra passa a ser uma subclasse, classe-filha, classe derivada ou especialização. Podemos redefinir métodos e criar novos atributos na subclasse. A implementação de herança em Java é realizada inserindo-se a palavra extends seguida do nome da superclasse após a definição da subclasse. Neste artigo, iremos utilizar como exemplo três hierarquias de classes, sendo uma para cada estratégia de mapeamento, ou seja, teremos uma hierarquia de classes para as estratégias SINGLE_TABLE, TABLE_PER_CLASS e JOINED. A figura 1 apresenta o diagrama de classes utilizado para o artigo. Para mais detalhes sobre o conceito de herança como também outros conceitos de orientação a objetos, buscar no livro Programação Java com Ênfase em Orientação a Objetos. Neste livro, são apresentadas todas as particularidades do conceito de herança como também inúmeros exemplos práticos. A seguir, iremos descrever sobre o conceito de polimorfismo e consultas polimórficas. Estes dois conceitos são extensivamente utilizados na manipulação de objetos como também estão presente nas consultas ao banco de dados. Polimorfismo O termo polimorfismo é originário do grego e significa muitas formas : poli significa muitas e morphos significa formas. Este representa um dos mais importantes conceitos da orientação a objetos e pode ser utilizado junto com outros conceitos conhecidos, tais como: herança, classes abstratas e interfaces. O seu uso ocorre de forma frequente em programas Java, como também na recuperação de dados através das consultas polimórficas no JPA. Consulta polimórfica Uma consulta polimórfica permite a extração de dados de tabelas que foram definidas em uma hierarquia de herança, ou seja, ao selecionar um objeto da tabela PessoaFisicaJoined, por exemplo, todas as outras tabelas da hierarquia conectadas a esta (PessoaJoined e AutorJoined) serão envolvidas na consulta, 56

3 afim de retornar o objeto requisitado. Quando informamos um identificador para recuperar um objeto este poderá ser de qualquer um dos tipos da hierarquia, logo o JPA irá realizar uma busca em todas as tabelas da hierarquia, seja uma superclasse ou subclasse. Vejamos um exemplo com a consulta: select pessoa from PessoaFisicaJoined pessoa where pessoa.cpf=:cpf. Esta consulta, após ser convertida para o formato do JPA, irá formalizar que existe um inner join com a tabela PessoaJoined e um left outer join com a tabela AutorJoined. Isto ocorre devido a estas duas tabelas estarem associadas à tabela PessoaFisicaJoined através da hierarquia de herança. As tabelas PessoaJuridicaJoined e EditoraJoined não serão envolvidas na cláusula SQL por pertencerem a uma segunda parte da hierarquia. A figura 1 esclarece a hierarquia de classes e a figura 5 apresenta o modelo de entidade e relacionamento. Ou seja, independentemente do objeto a ser recuperado, uma conexão (join) entre as tabelas sempre vai ocorrer. Esta conexão será um inner join caso a classe seja uma superclasse da tabela requisitada ou um left outer join caso a classe seja uma subclasse da tabela requisitada. A seguir, apresentamos a cláusula SQL original gerada pelo JPA: através de herança também serão envolvidas. Porém esta consulta SQL varia entre as estratégias disponíveis. A seguir, iremos apresentar detalhadamente cada uma das estratégias, como também a performance de cada uma delas. Single_Table Nesta estratégia, todas as entidades em uma hierarquia de classes são mapeadas para uma única tabela. A figura 2 apresenta o modelo de entidade e relacionamento utilizado pela estratégia SINGLE_TABLE. SELECT pessoafisi0_.id as id38_, pessoafisi0_1_.datacadastro as datacada2_38_, pessoafisi0_1_.matricula as matricula38_, pessoafisi0_1_.databloqueio as databloq4_38_, pessoafisi0_1_.contaacesso as contaace5_38_, pessoafisi0_1_.senha as senha38_, pessoafisi0_1_.id_endereco as id8_38_, pessoafisi0_1_.nome as nome38_, pessoafisi0_.rg as rg39_, pessoafisi0_.cpf as cpf39_, pessoafisi0_.especialidade as especial4_39_, pessoafisi0_.dtnasc as dtnasc39_, pessoafisi0_2_.qdadelivrospublicados as qdadeliv2_40_, pessoafisi0_2_.descultimolivro as desculti3_40_, pessoafisi0_2_.qdadepaginasultlivro as qdadepag4_40_, case FROM when pessoafisi0_2_.id is not null then 2 when pessoafisi0_.id is not null then 1 end as clazz_ PessoaFisicaJoined pessoafisi0_ inner join PessoaJoined pessoafisi0_1_ on pessoafisi0_.id=pessoafisi0_1_.id left outer join AutorJoined pessoafisi0_2_ pessoafisi0_.id=pessoafisi0_2_.id WHERE pessoafisi0_.cpf=? O objetivo desta consulta SQL foi mostrar o uso do join entre as tabelas da hierarquia. Ou seja, apesar de a consulta formalizar que os dados devem ser obtidos da tabela PessoaFisicaJoined, as outras tabelas conectadas on Para formalizar o uso desta estratégia, anotamos a classe com a Inheritance e informamos que o tipo da herança é SINGLE_TABLE. Vejamos um (strategy = InheritanceType.SINGLE_TABLE). A e o atributo InheritanceType.SINGLE_TABLE são utilizados para definir a estratégia do relacionamento de herança. Nesta estratégia, devemos também informar uma coluna discriminadora que será utilizada para diferenciar os objetos que são mapeados para as linhas nessa tabela. Na superclasse, devemos anotar a classe com a DiscriminatorColumn. Esta annotation define o nome e o tipo da coluna que será criada na tabela. Vejamos um (name = "DISCRIMINATOR", discriminatortype = DiscriminatorType.STRING). Neste exemplo, formalizamos que o tipo da coluna discriminadora será string e o nome dela será DISCRIMINATOR (poderia ter qualquer outro nome). Para completar a formalização do uso desta estratégia, devemos informar qual o conteúdo da coluna discriminadora. Para isso, usamos a Esta annotation define o conteúdo a ser inserido na coluna DISCRIMINATOR criada, ou seja, dentro dos parênteses informamos o conteúdo desta coluna. Vejamos um isica"). É importante observar que todas as classes que compõem a hierarquia deverão também ser anotadas com a e um valor diferente deve ser informado entre as aspas duplas. Toda esta formalidade nas classes serve para que as linhas gravadas na tabela sejam posteriormente identificadas, ou seja, se a linha gravada for do tipo da classe PessoaFisica, a coluna DISCRIMINATOR terá este conteúdo. Vejamos na figura 3 um exemplo dos dados gravados na tabela PessoaST. Na coluna DISCRIMINATOR, temos o nome de cada objeto gravado. 57

4 Listagem 3. Classe PessoaJuridicaST. Implementando a estratégia SINGLE_TABLE. Nesta estratégia, temos uma única tabela para acomodar todos os atributos de todas as classes envolvidas na hierarquia. Isto implica em ter colunas não sendo utilizadas, dependendo do objeto gravado. As listagens de programa 1, 2, 3, 4 e 5 apresentam os programas utilizados neste artigo para a estratégia SINGLE_TABLE. Iremos apresentar um fragmento do código sendo que o código completo poderá ser baixado do site da revista. Listagem 1. Classe PessoaST. Implementando a estratégia = = DISCRIMINATOR, discriminatortype = Pessoa ) public abstract class PessoaST extends Usuario implements Serializable { private int id; private String nome; private Endereco endereco; Listagem 2. Classe PessoaFisicaST. Implementando a estratégia PessoaFisica ) public class PessoaFisicaST extends PessoaST implements Serializable { private long rg; private long cpf; private String especialidade; private Date PessoaJuridica ) public class PessoaJuridicaST extends PessoaST implements Serializable { private long cnpj; private String nomefantasia; private String razaosocial; private Date dtfundacao; Listagem 4. Classe AutorST. Implementando a estratégia Autor ) public class AutorST extends PessoaFisicaST implements Serializable { private int qdadelivrospublicados; private String descultimolivro; private int qdadepaginasultlivro; Listagem 5. Classe EditoraST. Implementando a estratégia Editora ) public class EditoraST extends PessoaJuridicaST implements Serializable { private int qdadefuncionarios; private String areaespecializacao; private int qdadelivrosestoque; Esta estratégia traz facilidades como também dificuldades. A seguir, iremos apresentar os pontos positivos e negativos da estratégia SIN- GLE_TABLE. Pontos positivos Como pontos positivos, podemos citar: gia mais simples para implementar; selects para carregar os dados da tabela ou dados que tenham uma associação através de polimorfismo. Isto ocorre devido aos dados serem gravados na mesma tabela; Pontos negativos Como pontos negativos, podemos citar: todos os atributos das classes Usuario, PessoaST, PessoaFisicaST, Pessoa- JuridicaST, AutorST e EditoraST serão gravados em uma única tabela. Isto pode causar um problema de gestão na tabela ou ainda muita confusão; colunas ficam com valor null, causando desperdício de espaço em disco; profunda; devem ser criadas como nullable; totalmente sacrificada nesta estratégia. Manutenções em sistemas que usam esta estratégia tornam-se bem mais complexas. 58

5 Consulta gerada para select na estratégia SINGLE_TABLE Quando dizemos que o acesso aos dados na estratégia SINGLE_TABLE é simples é devido à cláusula SQL utilizada não necessitar de join, union ou subselects para este acesso. Quando selecionamos dados por padrão, usamos o comando select, sendo que no JPA não é diferente. Porém o comando select utilizado é remontado internamente e o resultado analisado difere um pouco do que estamos acostumados em utilizar. Vejamos o comando select gerado pelo JPA no seu formato original: select editorast0_.id as id43_, editorast0_.datacadastro as datacada3_43_, editorast0_.matricula as matricula43_, editorast0_.databloqueio as databloq5_43_, editorast0_.contaacesso as contaace6_43_, editorast0_.senha as senha43_, editorast0_.id_endereco as id23_43_, editorast0_.nome as nome43_, editorast0_.razaosocial as razaoso16_43_, editorast0_.cnpj as cnpj43_, editorast0_.nomefantasia as nomefan18_43_, editorast0_.dtfundacao as dtfundacao43_, editorast0_.qdadefuncionarios as qdadefu20_43_, editorast0_.areaespecializacao as areaesp21_43_, editorast0_.qdadelivrosestoque as qdadeli22_43_ Conforme podemos observar, a tabela que concentra todos os atributos é a tabela PessoaST. Neste exemplo, inserimos um objeto do tipo da classe EditoraST. Onde aparece o símbolo de?, indica que um parâmetro com valor dinâmico será utilizado. TABLE_PER_CLASS Com essa estratégia, todas as subclasses são mapeadas para uma tabela no banco de dados. Neste exemplo, teremos uma tabela para cada classe exceto para a classe PessoaTPC que representa a superclasse. Cada tabela irá possuir os seus atributos e uma cópia de todos os atributos da sua superclasse. Para verificar esta situação, basta acessar as tabelas e conferir as suas colunas. A figura 4 apresenta o modelo de entidade e relacionamento da estratégia TABLE_PER_CLASS. from PessoaST editorast0_ where editorast0_.discriminator='editora' and editorast0_.cnpj=? Conforme podemos observar, o comando select sempre irá considerar na cláusula where o nome do objeto e a chave para o acesso. Neste exemplo, formalizamos que recuperamos um objeto do tipo Editora. No caso da tabela Endereco, como esta não implementa nenhuma estratégia o acesso a suas colunas segue um filtro tradicional, ou seja, apenas usamos a chave primária para recuperar o registro. A tabela Endereco possui um com a tabela PessoaST. select endereco0_.idendereco as idendereco37_0_, endereco0_.rua as rua37_0_, endereco0_.cidade as cidade37_0_, endereco0_.estado as estado37_0_, endereco0_.complemento as compleme5_37_0_ from Endereco endereco0_ where endereco0_.idendereco=? Cláusula SQL gerada para insert na estratégia SINGLE_TABLE O comando insert nesta estratégia é formalizado pelo uso do nome do objeto na coluna DICRIMINATOR. Vejamos o comando gerado para inserir dados: insert into PessoaST (datacadastro, matricula, databloqueio, contaacesso, senha, id_endereco, nome, razaosocial, cnpj, nomefantasia, dtfundacao, qdadefuncionarios, areaespecializacao, qdadelivrosestoque, DISCRI- MINATOR, id) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?, 'Editora',?). Figura 4. Exemplo: modelo entidade relacionamento da estratégia. TABLE_Para formalizarmos o uso desta estratégia, devemos anotar a classe com a e no atributo strategy informar TABLE_PER_CLASS. Vejamos um itancetype.table_per_class). É importante observar que esta estratégia redefine os atributos da superclasse nas tabelas que representam as subclasses. Como diferença entre as estratégias SINGLE_TABLE e TABLE_PER_CLASS temos que na estratégia TABLE_PER_CLASS não precisamos definir uma coluna para representar o discriminator. Nesta estratégia, cada nova tabela terá uma chave (id) e os atributos da superclasse. As listagens de programa 6, 7, 8, 9 e 10 apresentam os programas utilizados neste artigo para a estratégia TABLE_PER_CLASS. Iremos apresentar um fragmento do código sendo que o código completo poderá ser baixado do site da revista. Listagem 6. Classe PessoaTPC. Implementando a estratégia = InheritanceType.TABLE_PER_CLASS) public abstract class PessoaTPC extends Usuario implements Serializable { private int id; private String nome; private Endereco endereco; 59

6 Listagem 7. Classe PessoaFisicaTPC. Implementando a estratégia TABLE_PER_CLASS. public class PessoaFisicaTPC extends PessoaTPC implements Serializable { private long rg; private long cpf; private String especialidade; private Date dtnasc; Listagem 9. Classe AutorTPC. Implementando a estratégia TABLE_ PER_CLASS. public class AutorTPC extends PessoaFisicaTPC implements Serializable { private int qdadelivrospublicados; private String descultimolivro; private int qdadepaginasultlivro; Listagem 8. Classe PessoaJuridicaTPC. Implementando a estratégia TABLE_PER_CLASS. public class PessoaJuridicaTPC extends PessoaTPC implements Serializable { private long cnpj; private String nomefantasia; private String razaosocial; private Date dtfundacao; Listagem 10. Classe EditoraTPC. Implementando a estratégia TABLE_ PER_CLASS. public class EditoraTPC extends PessoaJuridicaTPC implements Serializable { private int qdadefuncionarios; private String areaespecializacao; private int qdadelivrosestoque; Esta estratégia traz facilidades como também dificuldades. A seguir iremos apresentar os pontos positivos e negativos da estratégia TA- BLE_PER_CLASS. Pontos positivos Como pontos positivos, podemos citar: centes ao legado. Pois como as tabelas são independentes umas das outras, o relacionamento com o legado pode ser realizado. Pontos negativos Como pontos negativos, podemos citar: ou subclasse, é necessário utilizar subselects e/ou unions; colunas da superclasse serem redundantes nas tabelas que representam as subclasses; recuperação de um grande volume de dados pode ficar impraticável dependendo do banco de dados e também da posição da classe dentro da hierarquia. Neste artigo, iremos apresentar a performance desta estratégia em três diferentes bancos de dados. Consulta SQL gerada para select na estratégia TABLE_PER_CLASS Quando selecionamos dados na estratégia TABLE_PER_CLASS, realizamos a pesquisa diretamente na tabela a ser analisada. Conforme podemos notar neste exemplo fizemos um select na tabela AutorTPC, levando em consideração que todas as colunas da tabela AutorTPC, PessoaFisicaTPC, PessoaTPC e Usuário serão recuperadas. select autortpc0_.id as id44_, autortpc0_.datacadastro as datacada2_44_, autortpc0_.matricula as matricula44_, autortpc0_.databloqueio as databloq4_44_, autortpc0_.contaacesso as contaace5_44_, autortpc0_. senha as senha44_, autortpc0_.id_endereco as id8_44_, autortpc0_. nome as nome44_, autortpc0_.rg as rg45_, autortpc0_.cpf as cpf45_, autortpc0_.especialidade as especial3_45_, autortpc0_.dtnasc as dtnasc45_, autortpc0_.qdadelivrospublicados as qdadeliv1_46_, autortpc0_.descultimolivro as desculti2_46_, autortpc0_.qdadepaginasultlivro as qdadepag3_46_ from AutorTPC autortpc0_ where autortpc0_.cpf=? No caso da tabela AutorTPC, o select ficou simples, pois é a última classe da hierarquia, porém com a classe PessoFisicaTPC algumas novidades serão apresentadas. A tabela PessoFisicaTPC está situada no meio da hierarquia das classes. Por isso, o select ficará mais complexo. Vejamos um exemplo: Conforme podemos observar, esta cláusula SQL é bem mais complexa que as consultas utilizadas pela estratégia SINGLE_TABLE. Nesta consulta, temos o uso de subselect e union. Devido à inserção destes comandos, a performance desta estratégia tende a ficar pior dependendo da operação (inserção, seleção ou remoção) e do banco de dados utilizado. Para mais detalhes sobre a performance desta estratégia, analisar os quadros comparativos a seguir. select pessoafisi0_.id as id44_, pessoafisi0_.datacadastro as datacada2_44_, pessoafisi0_.matricula as matricula44_, pessoafisi0_.databloqueio as databloq4_44_, pessoafisi0_.contaacesso as contaace5_44_, pessoafisi0_.senha as senha44_, pessoafisi0_.id_endereco as id8_44_, pessoafisi0_.nome as nome44_, pessoafisi0_.rg as rg45_, pessoafisi0_.cpf 60

7 as cpf45_, pessoafisi0_.especialidade as especial3_45_, pessoafisi0_. dtnasc as dtnasc45_, pessoafisi0_.qdadelivrospublicados as qdade- Liv1_46_, pessoafisi0_.descultimolivro as desculti2_46_, pessoafisi0_. qdadepaginasultlivro as qdadepag3_46_, pessoafisi0_.clazz_ as clazz_ from ( select rg, id_endereco, senha, null as qdadelivrospublicados, matricula, id, null as descultimolivro, null as qdadepaginasultlivro, dtnasc, contaacesso, datacadastro, databloqueio, nome, cpf, especialidade, 1 as clazz_ select Cláusula SQL gerada para insert na estratégia TABLE_PER_CLASS Na estratégia TABLE_PER_CLASS, o comando insert é simples não sendo necessário inserir nenhum campo para a identificação do objeto. Cada objeto é identificado apenas pela chave primária. Vejamos um exemplo: Neste exemplo, inserimos um objeto do tipo da classe EditoraTPC. Onde aparece o símbolo de?, indica que um parâmetro com valor dinâmico será utilizado. JOINED from PessoaFisicaTPC union rg, id_endereco, senha, qdadelivrospublicados, matricula, id, descultimolivro, qdadepaginasultlivro, dtnasc, contaacesso, datacadastro, databloqueio, nome, cpf, especialidade, 2 as clazz_ where pessoafisi0_.cpf=? insert into EditoraTPC from AutorTPC ) pessoafisi0_ (datacadastro, matricula, databloqueio, contaacesso, senha, id_endereco, nome, razaosocial, cnpj, nomefantasia, dtfundacao, qdadefuncionarios, areaespecializacao, qdadelivrosestoque, id) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?). Na estratégia JOINED será criada uma tabela para cada classe presente no modelo de classes. Assim, não teremos a redefinição de atributos da superclasse em subclasses. A figura 5 apresenta o modelo de entidades e relacionamento da estratégia JOINED. Para formalizarmos o uso desta estratégia, devemos anotar a classe com a e no atributo strategy informar JOINED. Figura 5. Exemplo: modelo entidade relacionamento da estratégia. Vejamos um É importante observar que esta estratégia não redefine os atributos da superclasse nas tabelas que representam as subclasses. Outro ponto importante desta estratégia é a necessidade de definir explicitamente nas subclasses qual é o atributo da superclasse que representa a chave primária. Para isso, usamos a Vejamos um = "id"). No atributo referencedcolumnname, informamos o nome da coluna do banco de dados que representa a chave primária. No nosso exemplo, esta é a coluna id da classe PessoaJoined. As listagens de programa 11, 12, 13, 14 e 15 apresentam os programas utilizados neste artigo para a estratégia JOINED. Iremos apresentar um fragmento do código sendo que o código completo poderá ser baixado do site da revista. Listagem 11. Classe PessoaJoined. Implementando a estratégia = senha, column=@ Column(name= password )) public abstract class PessoaJoined extends Usuario implements Serializable { private int id; private String nome; private Endereco endereco; Listagem 12. Classe PessoaFisicaJoined. Implementando a estratégia (referencedcolumnname= id ) public class PessoaFisicaJoined extends PessoaJoined implements Serializable { private long rg; private long cpf; private String especialidade; private Date dtnasc; 61

8 Listagem 13. Classe PessoaJuridicaJoined. Implementando a estratégia (referencedcolumnname= id ) public class PessoaJuridicaJoined extends PessoaJoined implements Serializable { Listagem 14. Classe AutorJoined. Implementando a estratégia (referencedcolumnname= id ) public class AutorJoined extends PessoaFisicaJoined implements Serializable { private int qdadelivrospublicados; private String descultimolivro; private int qdadepaginasultlivro; private long cnpj; private String nomefantasia; private String razaosocial; private Date dtfundacao; Listagem 15. Classe EditoraJoined. Implementando a estratégia (referencedcolumnname= id ) public class EditoraJoined extends PessoaJuridicaJoined implements Serializable { private int qdadefuncionarios; private String areaespecializacao; private int qdadelivrosestoque; Esta estratégia traz facilidades como também dificuldades. A seguir, iremos apresentar os pontos positivos e negativos da estratégia JOINED. Pontos positivos Como pontos positivos, podemos citar: Pontos negativos Como pontos negativos, podemos citar: Consulta gerada para select na estratégia JOINED select pessoafisi0_.id as id38_, pessoafisi0_1_.datacadastro as datacada2_38_, pessoafisi0_1_.matricula as matricula38_, pessoafisi0_1_.databloqueio as databloq4_38_, pessoafisi0_1_.contaacesso as contaace5_38_, pessoafisi0_1_.senha as senha38_, pessoafisi0_1_. id_endereco as id8_38_, pessoafisi0_1_.nome as nome38_, pessoafisi0_.rg as rg39_, pessoafisi0_.cpf as cpf39_, pessoafisi0_.especialidade as especial4_39_, pessoafisi0_.dtnasc as dtnasc39_, pessoafisi0_2_.qdadelivrospublicados as qdadeliv2_40_, pessoafisi0_2_.descultimolivro as desculti3_40_, pessoafisi0_2_.qdadepaginasultlivro as qdadepag4_40_, case when pessoafisi0_2_.id is not null then 2 when pessoafisi0_.id is not null then 1 end as clazz_ from PessoaFisicaJoined pessoafisi0_ inner join PessoaJoined pessoafisi0_1_ on pessoafisi0_.id=pessoafisi0_1_.id left outer join AutorJoined pessoafisi0_2_ on pessoafisi0_.id=pessoafisi0_2_.id where pessoafisi0_.cpf=? Conforme podemos observar, na estratégia JOINED a JPA opta pelo uso de join e left join, enquanto na estratégia TABLE_PER_CLASS é utilizado union e subselects. A seguir, iremos abordar em mais detalhes a performance de cada uma das estratégias. Análise de performance Para a identificação dos tempos das estratégias SINGLE_TABLE, TABLE_PER_ CLASS e JOINED, usamos o framework JUnit e utilizamos as operações de inserção, seleção e deleção dos registros. Os testes ocorreram com 8 mil registros. O equipamento utilizado foi um Notebook Accer Core 2 Duo com 2G de memória RAM. Os testes foram realizados em três diferentes bancos de dados: HSQLDB 1.69, FireBird 2.0 e MySQL 5.1, porém estes testes podem também ser estendidos a outros banco de dados. Para a implementação dos testes foram desenvolvidas nove classes, sendo três para inserção em cada uma das estratégias, três para seleção em cada uma das estratégias e três para remoção dos dados. Todos os testes manipulam os mesmos dados, a fim de manter o mesmo critério para avaliação dos tempos. É importante observar que dentre os testes aqui apresentados a remoção ocorreu através da chave primária, porém a pesquisa ocorreu pelas colunas CPF e CNPJ, que não representam a chave primária das tabelas PessoaFisicaJoined e PessoaJuridicaJoined, respectivamente. Esta foi uma forma de realizar os testes, porém caso seja necessária a alteração para utilizar a chave torna-se bem simples e possível de ser feita. 62

9 Análise dos tempos de inserção de 8 mil registros: MySQL FireBird HSQLDB 8000 Registros JOINED TPC ST JOINED TPC ST JOINED TPC ST inserirpessoafisica 273, , , , , ,359 31,563 57,172 61,047 inserirpessoajuridica 290, , , , , ,266 28,562 46,859 74,453 inserirautor 317, , , , , ,391 37,172 64,922 55,297 inserireditora 309, , , , , ,703 40,328 59,094 64,859 Total 1.190, , , , , , , , ,656 Visão gráfica dos tempos de inserção de Como podemos observar na figura 6, o banco de dados HSQLDB é de longe o mais rápido em todas as estratégias para a operação de inserção. Em segundo lugar, fica o banco de dados FireBird e em terceiro o MySQL. Outros dados importantes a serem analisados tratam-se dos tempos da tabela 1 para a estratégia JOINED com as tabelas AutorJoined e Editora- Joined. Como estas tabelas ficam em uma maior profundidade na hierarquia, o tempo para incluir os dados ficou maior. Este evento se estendeu em quase todas as estratégias e em quase todos os bancos de dados. Tabela 1. Exemplo: Tabela com dados da operação de inserção Figura 6. Exemplo: visão gráfica da operação de inserção. MySQL FireBird HSQLDB 8000 Registros JOINED TPC ST JOINED TPC ST JOINED TPC ST obterpessoafisica 149, , , , , ,219 77, , ,609 obterpessoajuridica 167, , , , , ,672 94, , ,594 obterautor 208, , , , , , ,484 60, ,016 obtereditora 199, , , , , , ,484 68, ,937 Total 723, , , , , , , , ,156 mil registros: Como podemos observar na figura 7, o banco de dados HSQLDB não foi o mais rápido quando selecionamos dados na estratégia TABLE_PER_ CLASS. Nesta operação, tivemos que a operação de select no banco de dados MySQL para as tabelas posicionadas no meio da hierarquia ficou muito lenta. O tempo para executar cada operação foi de aproximadamente 3,2 segundos. Isto gerou um tempo final perto de 7,5 horas. Porém, caso sejam removidos os registros das tabelas AutorTPC e EditoraTPC, os tempos para a seleção como também para a remoção de registros, na estratégia TABLE_PER_CLASS, das tabelas PessoaFisicaTPC e PessoaJuridicaTPC ficam bem menores. Isto ocorre devido ao comando union gerado pela estratégia TABLE_ PER_CLASS nas consultas ficar sem função. Vejamos um exemplo: Tabela 2. Exemplo: tabela com dados da operação de seleção. a consulta gerada para a tabela PessoaFisicaTPC cria um subselect com a tabela PessoaFisicaTPC como também um union com a tabela AutorTPC. Como a tabela AutorTPC não possui registros, o union acaba ficando sem função. Assim, a performance melhora e muito. A consulta SQL para a tabela PessoaFisicaTPC apresentada no tópico Consulta SQL gerada para select na estratégia TABLE_PER_CLASS exemplifica a situação comentada. No caso da remoção de registros, a performance melhora devido ao mesmo caso. Para remover os registros, precisamos executar o método merge(). Este método gera um select no banco de dados, assim, teremos o mesmo problema da geração do union. Caso a tabela AutorTPC não tenha registros, este union também não retornará nenhum registro. 63

10 MySQL FireBird HSQLDB 8000 Registros JOINED TPC ST JOINED TPC ST JOINED TPC ST removerpessoafisica 246, , , , , ,016 31, ,672 33,000 removerpessoajuridica 286, , , , , ,766 32, ,312 34,954 removerautor 247, , , ,750 98, ,562 34,454 29,860 35,468 removereditora 255, , , , , ,359 35,734 31,468 35,641 Total 1.035, , , , , , , , ,063 Tabela 3. Exemplo: tabela com dados da operação de remoção. Figura 7. Exemplo: visão gráfica da operação de seleção. mil registros: Como podemos observar na figura 8 o banco de dados HSQLDB não foi o mais rápido quando removemos dados na estratégia TABLE_PER_CLASS, porém nos outros o tempo quase sempre ficou bem menor. Nesta operação, tivemos também que a operação de delete no banco de dados MySQL para as tabelas posicionadas no meio da hierarquia (PessoaFisicaTPC e PessoaJuridicaTPC) ficou muito lenta. O tempo para executar cada operação foi de aproximadamente 4 segundos. Isto gerou um tempo final perto de 8 horas. Porém, caso sejam removidos os registros das tabelas AutorTPC e EditoraTPC, os tempos para a remoção na estratégia TABLE_PER_CLASS no banco de dados MySQL, das tabelas PessoaFisicaTPC e PessoaJuridicaTPC, ficam bem menores. Isto ocorre devido ao banco de dados considerar que as tabelas que estão hierarquicamente abaixo das tabelas em questão não possuem mais nenhum registro. Como curiosidade, podemos enfatizar que os tempos de remoção de registros no banco de dados HSQLDB na estratégia TABLE_ PER_CLASS ficaram bem menores para as tabelas que estão na extremidade da hierarquia. Como executar os testes em outros bancos de dados Para executar em outros bancos de dados, precisamos configurar apenas dois arquivos XMLs. Primeiramente devemos criar o arquivo de conexão referente ao seu banco de dados. Ver no site do fornecedor ou na Internet Figura 8. Exemplo: visão gráfica da operação de remoção. como deve ser preparado. Neste artigo, usamos DataSource para o acesso aos bancos de dados. Estes arquivos devem ser gravados no diretório de deploy do servidor JBoss. Ex.: C:\...\server\jboss\server\default\deploy. Vejamos dois exemplos dos arquivos utilizados para os testes no MySQL e FireBird. O arquivo referente ao HSQLDB poderá ser baixado do site da revista. Vejamos na Listagem 16 o conteúdo do arquivo mysql-ds.xml Após a definição do arquivo para a conexão com o banco de dados, devemos configurar o arquivo persistence.xml que conecta os programas Java com o banco de dados. Este arquivo deve ficar no diretório META- INF e apontar para o arquivo de DataSource que pretende-se conectar. O nome do arquivo de DataSource deve ficar dentro do arquivo persistence.xml. A Listagem 18 apresenta um exemplo do arquivo persistence.xml apontando para o banco de dados MySQL. É importante observar que cada banco de dados possui um arquivo com as suas particularidades. Caso precise testar com outro banco de dados, altere o conteúdo deste arquivo. Herança de classes que não representam entidades Até o momento, as estratégias de herança abordadas consideraram que todas as classes envolvidas na hierarquia são classes anotadas com a annotation, ou seja, são classes que serão representadas no banco de dados como tabelas. Porém, podemos ter situações nas quais seja necessário herdar de uma classe do legado que não deverá ser considerada como uma tabela. Para isso, usamos a MappedSuperclass. 64

11 Listagem 16. Arquivo XML utilizado como DataSource para acesso ao banco de dados MySQL. <connection-factories> <local-tx-datasource> <jndi-name>mysql-ds</jndi-name> <connection-url> jdbc:mysql://localhost:3306/curso?createdatabaseifnotexist=true </connection-url> <driver-class>com.mysql.jdbc.driver</driver-class> <transaction-isolation>transaction_repeatable_read </transaction-isolation> <connection-property name= lc_ctype type= java.lang.string > UNICODE_FSS</connection-property> <connection-property name= maxstatements >10</connection-property> <user-name>root</user-name> <password>12345</password> <min-pool-size>0</min-pool-size> <max-pool-size>200</max-pool-size> <blocking-timeout-millis>5000</blocking-timeout-millis> <idle-timeout-minutes>15</idle-timeout-minutes> <track-statements>false</track-statements> <prepared-statement-cache-size>0</prepared-statement-cache-size> <metadata> <type-mapping>mysql</type-mapping> </metadata> </local-tx-datasource> </connection-factories> Listagem 17. Arquivo XML utilizado como DataSource para acesso ao banco de dados FireBird. <connection-factories> <local-tx-datasource> <jndi-name>mfirebird-ds</jndi-name> <connection-url>jdbc:firebirdsql:localhost/3050:/exemplo.fdb </connection-url> <driver-class>org.firebirdsql.jdbc.fbdriver </driver-class> <transaction-isolation>transaction_repeatable_read </transaction-isolation> <connection-property name= lc_ctype type= java.lang.string > UNICODE_FSS</connection-property> <connection-property name= maxstatements >10 </connection-property> <user-name>sysdba</user-name> <password>masterkey</password> <min-pool-size>0</min-pool-size> <max-pool-size>200</max-pool-size> <blocking-timeout-millis>5000</blocking-timeout-millis> <idle-timeout-minutes>15</idle-timeout-minutes> <check-valid-connection-sql>select CAST(1 as INTEGER) FROM rdb$database</check-valid-connection-sql> <track-statements>false</track-statements> <prepared-statement-cache-size>0</prepared-statement-cache-size> <metadata> <type-mapping>firebird</type-mapping> </metadata> </local-tx-datasource> </connection-factories> Listagem 18. Arquivo XML utilizado para a comunicação do JPA com o banco de dados MySQL. <?xml version= 1.0 encoding= windows-1252?> <persistence version= 1.0 xmlns= xmlns:xsi= xsi:schemalocation= > <persistence-unit name= titan > <provider>org.hibernate.ejb.hibernatepersistence</provider> <jta-data-source>java:/mysql-ds</jta-data-source> <properties> <property name= hibernate.hbm2ddl.auto value= create /> <property name= hibernate.show.sql value= false /> <property name= hibernate.dialect value= org.hibernate.dialect.mysqldialect /> </properties> </persistence-unit> </persistence> Listagem 19. Arquivo XML utilizado para a comunicação do JPA com o banco de dados FireBird. <?xml version= 1.0 encoding= windows-1252?> <persistence version= 1.0 xmlns= xmlns:xsi= xsi:schemalocation= > <persistence-unit name= titan > <provider>org.hibernate.ejb.hibernatepersistence</provider> <jta-data-source>java:/mfirebird-ds</jta-data-source> <properties> <property name= hibernate.hbm2ddl.auto value= update /> <property name= hibernate.show.sql value= false /> <property name= hibernate.dialect value= org.hibernate.dialect.firebirddialect /> </properties> </persistence-unit> </persistence> Uma vez que a classe não está anotada com a annotation, esta não terá uma tabela associada. Porém, pode ser necessário renomear um atributo para um novo nome na tabela criada. Para isto, usamos a Na classe PessoaJoined, sobrescrevemos um atributo da classe Usuario utilizando a Vejamos o (name = "senha", column Column (name="password")). Neste exemplo, estamos renomeando a coluna definida como senha para um novo nome chamado de password, ou seja, no banco de dados a coluna será criada como password. As listagens de programa 20 e 21 apresentam os programas utilizados neste artigo com este fim. 65

12 Listagem 20. Classe public class Usuario implements Serializable { private int matricula; private Date datacadastro; private Date databloqueio; private String contaacesso; private String senha;... Listagem 21. Classe PessoaJoined. Implementando a estratégia = column=@ Column(name="password")) public abstract class PessoaJoined extends Usuario implements Serializable { private int id; private String nome; private Endereco endereco;... Considerações finais Conforme podemos observar, cada estratégia possui uma particularidade, as quais destacamos: uma coluna adicional; gia SINGLE_TABLE possui melhor performance, vemos que isto ocorre em alguns casos, conforme podemos observar nos testes realizados. Esta estratégia joga no lixo o conceito de normalização e por isto deve-se sempre justificar a sua utilização; lenta que a estratégia JOINED em quase todos os testes realizados. Isto ocorre devido a esta estratégia utilizar uma string no filtro da cláusula SQL. No caso da estratégia JOINED, os filtros são feitos usando-se as chaves primárias; a recuperação de dados dentro de uma hierarquia de classe. Conforme podemos observar, esta estratégia tem grande dificuldade em funcionar no banco de dados MySQL; mostrou a melhor das estratégias; ração que está sendo executada. Como podemos observar na operação de inserção, a estratégia JOINED foi a mais lenta, porém não o suficiente para torná-la inviável. Quando utilizamos a estratégia JOINED na seleção, esta teve um resultado bastante positivo em relação às outras estratégias, ou seja, apesar de usar join o JPA esta bem ajustado a estas necessidades. Assim, esta estratégia deve ser sempre analisada com carinho, pois, além de ter boa performance, mantém o banco de dados normalizado; de dados avaliados. É extremamente recomendado que, caso o leitor utilize outro banco de dados, os testes sejam realizados para ter outra avaliação. Os testes podem com certeza auxiliar tanto o analista de sistemas como também administradores de banco de dados no momento da definição da melhor estratégia a ser adotada. Os testes aqui apresentados podem ser novamente executados em outros bancos de dados, porém recomendamos que seja utilizado o framework JUnit, por ter integrado o tempo que cada caso de teste executa. Isto ajuda a ter qualidade nos tempos levantados. Todos os testes foram executados mais de três vezes e em todos os casos os tempos ficaram próximos. Caso alguém tenha alguma dúvida ou Referências Novatec, v p. 66