Dúvidas sobre as anotações de relacionamento

Olá Jéssica.

FetchMode

• SELECT = Os relacionamentos serão retornados por meio de SELECTs isolados, ao invés de JOINs;
• JOIN = Exatamente ao contrário do exemplo anterior;
• SUBSELECT = Os relacionamentos serão retornados por meio de SUBSELECTs;

FetchType

• EAGER = (Ganancioso) Busca os relacionamentos sempre, acessando ou não o(s) objeto(s) desse relacionamento;
• LAZY = (Preguiçoso) Busca os relacionamentos se, e somente se, o acesso a esse(s) objeto(s) do relacionamento for(em) acessado(s). Lança um LazyInitializationException, caso se tente acessar o relacionamento após o EntityManager já ter sido fechado;

FetchMode vs FetchType

• Não especificar FetchMode explicitamente faz com que o que for definido em FetchType seja obedecido;
• Especificar explicitamente o FetchMode como JOIN faz com que definições explicitas de FetchType sejam ignoradas e assume FetchType como EAGER;
• Especificar explicitamente o FetchMode como SELECT ou SUBSELECT faz com que FetchType seja obedecido;

JoinTable

Como se trata de um relacionamento muito-para-muitos, há a necessidade de haver uma tabela extra, só para mapear o cruzamento de relacionamento entre as linhas das tabelas envolvidas.

• name: o nome dessa tabela extra;
• joinColumns: As chaves primárias das tabelas envolvidas no relacionamento serão usadas como chaves primárias e estrangeiras na tabela extra;
• JoinColumn: A chave estrangeira que se refere ao dono do relacionamento (A entidade onde a declaração está sendo feita);
• inverseJoinColumn: O mesmo que o exemplo anterior, só que sobre a outra entidade envolvida;

Um exemplo básico de tabela de relacionamento muito-para-muitos:

No exemplo acima, nota-se que:

• O funcionário 1 está alocado em ambas unidades 1 e 2;
• O funcionário 2 está alocado apenas na unidade 2;
• O funcionário 3 também está alocado na unidade 1;

Perceba que em um relacionamento muito-para-muitos, não há uma outra forma muito elegante de se resolver esse desafio sem essa tabela extra: Senão, ou a tabela unidade precisaria ter tantas colunas quantos funcionários na empresa (id_funcionario1, id_funcionario2, etc) - Inviável e inelegante - ou o mesmo com a tabela de funcionários, que deveria ter o mesmo número de colunas quanto ao número de unidade (id_unidade1, id_unidade2, etc)

Espero ter ajudado.

Muito obrigada Ítalo! Bastante esclarecedor, precisava desse detalhamento pra entender bem o conceito. Perfeito!