Qual é o "lado proprietário" em um mapeamento ORM?

O que exatamente significa o lado dono ? O que é uma explicação com alguns exemplos de mapeamento ( um para muitos, um para um, muitos para um )?

O texto a seguir é um trecho da descrição de @OneToOne na documentação do Java EE 6. Você pode ver o conceito que possui o lado nele.

Define uma associação de valor único para outra entidade que possui multiplicidade um para um. Normalmente, não é necessário especificar a entidade de destino associada explicitamente, pois ela geralmente pode ser inferida a partir do tipo de objeto que está sendo referenciado. Se o relacionamento for bidirecional, o lado não proprietário deverá usar o elemento mappedBy da anotação OneToOne para especificar o campo ou a propriedade do relacionamento do lado proprietário.

Por que é necessária a noção de um lado dono:

A idéia de um lado proprietário de uma relação bidirecional deriva do fato de que nos bancos de dados relacionais não existem relações bidirecionais, como no caso de objetos. Nos bancos de dados, temos apenas relações unidirecionais - chaves estrangeiras.

Qual é o motivo do nome 'dono'?

O lado proprietário da relação rastreada pelo Hibernate é o lado da relação que possui a chave estrangeira no banco de dados.

Qual é o problema que a noção de possuir lado resolve?

Veja um exemplo de duas entidades mapeadas sem declarar um lado proprietário:

@Entity
@Table(name="PERSONS")
public class Person {
    @OneToMany
    private List<IdDocument>  idDocuments;
}

@Entity
@Table(name="ID_DOCUMENTS")
public class IdDocument {
    @ManyToOne
    private Person person;
}

Do ponto de vista do OO, esse mapeamento define não uma relação bidirecional, mas duas relações unidirecionais separadas.

O mapeamento criaria não apenas tabelas PERSONSe ID_DOCUMENTS, mas também criaria uma terceira tabela de associação PERSONS_ID_DOCUMENTS:

CREATE TABLE PERSONS_ID_DOCUMENTS
(
  persons_id bigint NOT NULL,
  id_documents_id bigint NOT NULL,
  CONSTRAINT fk_persons FOREIGN KEY (persons_id) REFERENCES persons (id),
  CONSTRAINT fk_docs FOREIGN KEY (id_documents_id) REFERENCES id_documents (id),
  CONSTRAINT pk UNIQUE (id_documents_id)
)

Observe a chave primária pkem ID_DOCUMENTSsomente. Nesse caso, o Hibernate controla os dois lados da relação independentemente: Se você adicionar um documento à relação Person.idDocuments, ele inserirá um registro na tabela de associação PERSON_ID_DOCUMENTS.

Por outro lado, se chamarmos idDocument.setPerson(person), alteramos a chave estrangeira person_id na tabela ID_DOCUMENTS. O Hibernate está criando duas relações unidirecionais (chave estrangeira) no banco de dados, para implementar uma relação bidirecional de objetos.

Como a noção de possuir lado resolve o problema:

Muitas vezes o que nós queremos é apenas uma chave estrangeira na tabela de ID_DOCUMENTSdireção PERSONSea mesa associação extra.

Para resolver isso, precisamos configurar o Hibernate para parar de rastrear as modificações na relação Person.idDocuments. O Hibernate deve rastrear apenas o outro lado da relação IdDocument.persone, para isso, adicionamos mappedBy :

@OneToMany(mappedBy="person")
private List<IdDocument>  idDocuments;

O que significa mappedBy?

Isso significa algo como: "as modificações deste lado da relação já estão mapeadas pelo outro lado da relação IdDocument.person, portanto, não é necessário rastreá-lo aqui separadamente em uma tabela extra".

Existem GOTCHAs, consequências?

Usando mappedBy , Se nós só chamar person.getDocuments().add(document), a chave estrangeira em ID_DOCUMENTSvão NÃO estar ligado ao novo documento, porque esta não é a / lateral proprietária rastreado da relação!

Para vincular o documento à nova pessoa, você precisa ligar explicitamente document.setPerson(person), porque esse é o lado proprietário da relação.

Ao usar mappedBy , é de responsabilidade do desenvolvedor saber qual é o lado proprietário e atualizar o lado correto da relação para acionar a persistência da nova relação no banco de dados.

Você pode imaginar que o lado proprietário é a entidade que tem a referência ao outro. No seu trecho, você tem um relacionamento individual. Como é uma relação simétrica , você terá que, se o objeto A estiver em relação ao objeto B, também o vice-versa for verdadeiro.

Isso significa que salvar no objeto A uma referência ao objeto B e salvar no objeto B uma referência ao objeto A será redundante: é por isso que você escolhe qual objeto "possui" o outro que tem a referência a ele.

Quando você tem um relacionamento um para muitos, os objetos relacionados à parte "muitos" serão o lado proprietário; caso contrário, você precisará armazenar muitas referências de um único objeto para uma multidão. Para evitar isso, todos os objetos da segunda classe terão um ponteiro para o único ao qual se referem (portanto, eles são o lado proprietário).

Para um relacionamento muitos-para-muitos, uma vez que você precisará de uma tabela de mapeamento separada de qualquer maneira, não haverá nenhum lado proprietário.

Em conclusão, o lado proprietário é a entidade que faz referência ao outro.