[RESOLVIDO] Relacionamento 1:N

Então, mesmo sendo 1 : N, é possível criar uma tabela associativa para referenciar este relacionamento, caso a tabela fraca também se relacione com outras tabelas.
Como assim? Pessoas tem endereços, fornecedores também possuem endereços. Pessoas são diferentes de fornecedores, logo, não há herança.
Assim sendo, temos Pessoa 1 : N Endereço e Fornecedor 1 : N Endereço.
A idéia geral seria criar uma tabela endereço com uma chave estrangeira referenciando a chave primária de Pessoa e outra referenciando a chave primária de Fornecedor. Este modelo não me agrada, afinal, teríamos colunas vagas (ou pessoa_id ou fornecedor_id).
Desta forma, eu criaria as tabelas pessoa_endereco e fornecedor_endereco, onde colocaria as colunas pessoa_id e endereco_id e fornecedor_id e endereco_id.
Isso me garantiria que posso até adicionar novas tabelas que tenham o mesmo relacionamento com endereço que não teria qualquer problema.

Muito obrigado pelo esclarecimento. Neste caso, teria uma classe associativa entre Pessoa e Endereço, outra classe associativa entre Fornecedor e Endereço? É isso?

drsmachado:

Então, mesmo sendo 1 : N, é possível criar uma tabela associativa para referenciar este relacionamento, caso a tabela fraca também se relacione com outras tabelas.
Como assim? Pessoas tem endereços, fornecedores também possuem endereços. Pessoas são diferentes de fornecedores, logo, não há herança.
Assim sendo, temos Pessoa 1 : N Endereço e Fornecedor 1 : N Endereço.
A idéia geral seria criar uma tabela endereço com uma chave estrangeira referenciando a chave primária de Pessoa e outra referenciando a chave primária de Fornecedor. Este modelo não me agrada, afinal, teríamos colunas vagas (ou pessoa_id ou fornecedor_id).
Desta forma, eu criaria as tabelas pessoa_endereco e fornecedor_endereco, onde colocaria as colunas pessoa_id e endereco_id e fornecedor_id e endereco_id.
Isso me garantiria que posso até adicionar novas tabelas que tenham o mesmo relacionamento com endereço que não teria qualquer problema.

wbdsjunior:

drsmachado:

Então, mesmo sendo 1 : N, é possível criar uma tabela associativa para referenciar este relacionamento, caso a tabela fraca também se relacione com outras tabelas.
Como assim? Pessoas tem endereços, fornecedores também possuem endereços. Pessoas são diferentes de fornecedores, logo, não há herança.
Assim sendo, temos Pessoa 1 : N Endereço e Fornecedor 1 : N Endereço.
A idéia geral seria criar uma tabela endereço com uma chave estrangeira referenciando a chave primária de Pessoa e outra referenciando a chave primária de Fornecedor. Este modelo não me agrada, afinal, teríamos colunas vagas (ou pessoa_id ou fornecedor_id).
Desta forma, eu criaria as tabelas pessoa_endereco e fornecedor_endereco, onde colocaria as colunas pessoa_id e endereco_id e fornecedor_id e endereco_id.
Isso me garantiria que posso até adicionar novas tabelas que tenham o mesmo relacionamento com endereço que não teria qualquer problema.

Neste caso, já que o Endereço está em contextos diferentes - Pessoa e Fornecedor, Recursos Humanos e Suprimentos, ou sei lá o que - por que não criar duas tabelas para endereço - pessoa_endereco e fornecedor_endereco - que referenciam a tabela pessoa e fornecedor, respectivamente? No código, em Java, você pode manter as classes em pacotes diferentes - xx.xxx.recursohumanos.Endereco e xx.xxx.suprimentos.Endereco - e assim separar os contextos. Particularmente, prefiro essa abordagem.

drsmachado:

wbdsjunior:

drsmachado:

Então, mesmo sendo 1 : N, é possível criar uma tabela associativa para referenciar este relacionamento, caso a tabela fraca também se relacione com outras tabelas.
Como assim? Pessoas tem endereços, fornecedores também possuem endereços. Pessoas são diferentes de fornecedores, logo, não há herança.
Assim sendo, temos Pessoa 1 : N Endereço e Fornecedor 1 : N Endereço.
A idéia geral seria criar uma tabela endereço com uma chave estrangeira referenciando a chave primária de Pessoa e outra referenciando a chave primária de Fornecedor. Este modelo não me agrada, afinal, teríamos colunas vagas (ou pessoa_id ou fornecedor_id).
Desta forma, eu criaria as tabelas pessoa_endereco e fornecedor_endereco, onde colocaria as colunas pessoa_id e endereco_id e fornecedor_id e endereco_id.
Isso me garantiria que posso até adicionar novas tabelas que tenham o mesmo relacionamento com endereço que não teria qualquer problema.

Neste caso, já que o Endereço está em contextos diferentes - Pessoa e Fornecedor, Recursos Humanos e Suprimentos, ou sei lá o que - por que não criar duas tabelas para endereço - pessoa_endereco e fornecedor_endereco - que referenciam a tabela pessoa e fornecedor, respectivamente? No código, em Java, você pode manter as classes em pacotes diferentes - xx.xxx.recursohumanos.Endereco e xx.xxx.suprimentos.Endereco - e assim separar os contextos. Particularmente, prefiro essa abordagem.

Você usa ou já usou hibernate?
Quando você mapeia um relacionamento 1 : N no hibernate e não especifica a join column, ele cria uma tabela intermediária, como a que eu sugeri.

Estou iniciando os Estudos de hibernate esta semana. Minha intenção é usá-lo. Estudei esses assuntos a muito tempo na faculdade e por isso estou apanhando!
Então, no diagrama de classes, eu crio uma classe associativa entre pessoa e endereço? E faço as mesmas coisas no Java (crio uma classe endereço, uma classe pessoa, e uma classe endereço_pessoa)? É isso ou não?

glaubersilverio:

Estou iniciando os Estudos de hibernate esta semana. Minha intenção é usá-lo. Estudei esses assuntos a muito tempo na faculdade e por isso estou apanhando! Então, no diagrama de classes, eu crio uma classe associativa entre pessoa e endereço? E faço as mesmas coisas no Java (crio uma classe endereço, uma classe pessoa, e uma classe endereço_pessoa)? É isso ou não?

@Entity
@Table(name="pessoa_endereco")
public class Endereco {
    private Pessoa pessoa;
   // atributos
   // getters and setters
}

@Entity
public class Pessoa {
    @OneToMany(mappedBy="pessoa")
    private Set<Endereco> enderecos;
   // outros atributos
   // getters and setters
}

Mas e como faco com as demais classes que se relacionam com endereco? Desta forma eu terei que ter um atributo fornecedor por exemplo na classe endereco, e quando for pessoa ele ficara null

Como o amigo drsmachado sugeriu eu completei (ou tentei), você terá duas classes Endereco - uma para Pessoa e outra para Fornecedor. Você pode nomear as classes como nas tabelas do banco de dados PessoaEndereco e FornecedorEndereco, com comentei, criar as classes com o mesmo nome, mas em pacotes diferentes.

Agora consegui entender direitinho. Muito obrigado drsmachado e wbdsjunior. A ajuda de vocês foi de grande valia!