Montando relacionamentos no App Engine: Um para muitos

Olá a todos,

                Nesse post falaremos mais um pouco sobre o mecanismo de armazenamento de dados do App Engine. Demonstraremos como montar relacionamentos do tipo “um para muitos” nessa estrutura de armazenamento. Primeiro precisamos lembrar que o mecanismo do App Engine não é uma base de dados relacional, portanto precisamos pensar de uma maneira diferente quanto projetamos nossa estrutura de dados.

                Numa base de dados relacional temos cada entidade representada por uma tabela e os relacionamentos são dados por chaves primárias e estrangeiras. Num relacionamento do tipo “um para muitos”, onde temos um “pai” para muitos “filhos” temos na tabela “filho” um ou mais campos que compõem a chave estrangeira. Essa chave então aponta para os campos que compõem a chave primária no registro na tabela “pai”. Portanto o relacionamento é montado através de relacionamento entre os campos dos registros. Um ponto importante é que cada entidade permanece separada em uma tabela.

                Já na base de dados do App Engine temos uma estrutura orientada a objetos. Nesse tipo de base de dados as entidades são representadas por classes, que são as mesmas utilizadas no código do aplicativo. Portanto os relacionamentos entre os objetos são montados de outra maneira. Num relacionamento do tipo “um para muitos” o objeto “pai” contém os objetos “filhos” que podem estar organizados em arrays ou listas dinâmicas.

                Vamos então passar para o exemplo para deixar essas idéias mais claras. O primeiro passo é criar o projeto no eclipse. Nesse post utilizaremos um projeto do App Engine sem o uso do GWT. Esse projeto seguirá a sugestão do Rodrigo Monteiro feita em um comentário do post anterior. Porém alterei o tipo de relacionamento de “um para um” para “um para muitos”.

                Criado o projeto temos que definir nossa estrutura de dados, que será composta por um conjunto de classes. A classe “pai” representará livros, enquanto a classe “filho” serão os capítulos desse livro (na sugestão do Rodrigo a classe pai era Departamento e a classe filho Funcionario). Para montar o relacionamento entre o livro e seus capítulos (um livro para N capítulos) deveremos criar uma lista da classe capítulos na classe livro. Porém para permitir a identificação do relacionamento entre as classes pelo mecanismo de armazenamento deveremos criar uma propriedade do tipo livro na classe capitulo. O relacionamento é estabelecido ao utilizarmos o parâmetro mappedBy do atributo Element na propriedade da classe “pai” que representa seus filhos, ou seja, na lista de capitulos. Esse parâmetro recebe uma string que é o nome da propriedade que armazena o objeto “pai” no “filho”. A implementação dessa estrutura pode ser vista na figurar abaixo:

Codigo das classes que serao persistidas no App Engine

                Podemos então passar para a criação e armazenamento dos objetos. Para demonstrar vamos criar um objeto do tipo livro e adicionarmos nele alguns objetos do tipo capitulo. Após adicionarmos os objetos “filhos” no objeto “pai” devemos utilizar a classe PersistenceManager para persistir a classe “pai”. Nesse tipo de relacionamento não é necessário persistir as classes filhos, pois elas já serão persistidas junto com a classe “pai”. O código para realizar essa tarefa é semelhante ao abaixo:

Codigo para gravar os objetos no storage

                Podemos realizar as pesquisas a partir da classe “pai” ou pela classe “filho”, porém não podemos utilizar atributos da classe “filho” quando nossa consulta parte da classe “pai”. Abaixo temos um exemplo de como realizar a pesquisa nessa estrutura de dados:

Codigo para realizar a pesquisa

                Temos então um exemplo de relacionamento “um para muitos” no App Engine. Um ponto importante é primeiro projetarmos as classes para somente depois começarmos a utilizá-las. Como sempre deixei o código utilizado para construir o post no meu Sky drive, com o nome testeJDO.zip.

Abraços a todos e até o próximo post.