Relacionamento muitos para muitos dá uma ajudinha?

Front-end
#1

Bom dia, estou fazendo uma modelagem de banco de dados para uma empresa de móveis planejados e estou precisando de um help.
tenho 3 tabelas envolvidas nessa duvida, “[color=red]cliente[/color]”, “[color=red]endereco[/color]”, “[color=red]orcamento[/color]”.

Regas de negócio:
Cada [color=red]cliente[/color] tem no minimo 1 e no máximo 2 [color=red]enderecos[/color] (onde reside atualmente e onde residirá).
Cada [color=red]endereco[/color] tem de 0 à N [color=red]clientes[/color].

Cada [color=red]orcamento[/color] tem no minimo 1 e no máximo 1 [color=red]endereco[/color](que é onde os móveis serao entregues).
Cada [color=red]endereco[/color] tem de 0 à N [color=red]orcamentos[/color]

OBS: O [color=red]endereco[/color] onde o [color=red]cliente[/color] residirá só será cadastrado se for o mesmo do [color=red]orcamento[/color].

Duvida:
Eu coloco o relacionamento entre [color=red]cliente[/color] e [color=red]endereco[/color] como muitos para muitos (criando uma tabela intermediaria) ou
coloco 2 chaves estrangeiras na tabela [color=red]cliente[/color] puxando 2 [color=red]enderecos[/color] ? Por que (a pergunta que nao quer calar) ?

Eu poderia clolocar também uma chave estrangeira entre [color=red]cliente[/color] e [color=red]orcamento[/color] mas nao vejo muita praticidade nisso.
Tendo os 2 enderecos na tabela [color=red]cliente[/color] quando eu for consultar o [color=red]endereco[/color] do [color=red]cliente[/color] na minha classe java
seria bem mais facil.

Nao sei como seria o certo de fazer esse relacionamento, quem puder me ajudar fico agradecido.

#2

Ola v0olverine,

Voce tem a flexibilidade de modelar o seu banco de dados da maneira mais simples ou complexa, depende de como o sistema sera usado. Existe um conjunto de regras que lhe ajudara a entender um pouco mais sobre modelagem de base de dados. Esse conceito e conhecido como Database Normalization.
Mas com relacao ao problema apresentado, eu faria da seguinte forma.

Nao crie uma tabela intermediaria para cliente e endereco. Coloque a chave estrangeira de cliente na tabela endereco
Coloque a logica garantido no maximo 2 enderecos na sua aplicacao.
Coloque a chave estrangeira para cliente na tabela orcamento.
Coloque tambem a chave estrangeira de endereco na tabela orcamento. ( O endereco de entrega )

Bem, essas sao apenas sugestoes.
Boa sorte

#3

Oi Carol

Pense comigo, o cliente tem 2 (ou seja N) enderecos.
cliente tem o endereco onde reside atualmente e onde residirá futuramente (em lojas de móveis normalmente o cliente mobilha um imovel que ele comprou e está indo morar)

Um endereco tem N clientes.
em um endereco residem o pai que já é cliente a mae e 2 filhos. Um dos filhos vai se casar e se mudar e também virou cliente porque deseja mobilhar a nova residencia.
O endereco onde reside atualmente o filho é o mesmo do pai que já está cadastrado, entao seria teoricamente só puxar o endereco já cadastrado do pai pela chave estrangeira
do novo cliente (o filho) nao ?

Se eu colocar a chave estrangeira de cliente na tabela endereco, o cliente vai ter N enderecos mas enderecos nao vai poder ter N clientes, a nao ser que voce esteja me dizendo para quando eu for cadastrar outro cliente que resida em um endereco já cadastrado eu recadastre o mesmo endereco (que é uma opcao interecante que eu nao tinha pensado antes).
É isso que vc está me dizendo ?

Obrigado pela resposta

#4

E ai blza? bom, não sei se tu ta trabalhando com SQL nativa ou se está usando algum framework de persistencia como o Hibernate.

Eu tenho um caso bem semelhante no meu projeto e vou te mostrar como eu fiz.

Eu tenho um documento de transporte chamado ctrc que possuem dois clientes ligados nele, remetente e destinatario, e cada cliente pode ter n ctrcs.

Então eu mapeei da seguinte forma:

ManyToOne
private Cliente remetente;
ManyToOne
private Cliente destinatario;

O que acontece ai, ele restringe que o CTRC deve ter apenas UM remetente e UM destinatário, mas ambos do tipo CLIENTE, e os CLIENTES poderão ter MUITOS CTRCs.

Adaptando isso para sua aplicação, seria algo como

ManyToOne
private Endereco enderecoAtual;
ManyToOne
private Endereco enderecoFuturo;

Ou seja, vc teria duas chaves estrangeiras de endereço dentro da tabela cliente.

Espero ter ajudado,

Abraço.

EDIT: Uso Hibernate/JPA

#5

Eu penso assim, um endereco pode ter mais de um cliente (uma familia, por exemplo, os pais e dois irmãos). Se mais de um cliente comprar móveis (o pai, para a sala de estar, a mãe para a cozinha, cada filho para seu quarto) você terá um cenário de 4 compras para o mesmo endereço, certo?
Então, este relacionamento é N : M.
Portanto, eu criaria a tabela cliente, a tabela endereco e uma associativa, com duas FKs, uma referenciando a PK de cliente e uma referenciando a PK de endereco. Isso permitiria cadastrar um cliente com varios endereços (casa, apartamento, escritório) ou vários clientes no mesmo endereço.
Orcamento 1 : 1 Endereco
Cada orcamento tera uma FK que referencia a PK de endereco

#6

[quote=igor_henrique]E ai blza? bom, não sei se tu ta trabalhando com SQL nativa ou se está usando algum framework de persistencia como o Hibernate.

Eu tenho um caso bem semelhante no meu projeto e vou te mostrar como eu fiz.

Eu tenho um documento de transporte chamado ctrc que possuem dois clientes ligados nele, remetente e destinatario, e cada cliente pode ter n ctrcs.

Então eu mapeei da seguinte forma:

ManyToOne
private Cliente remetente;
ManyToOne
private Cliente destinatario;

O que acontece ai, ele restringe que o CTRC deve ter apenas UM remetente e UM destinatário, mas ambos do tipo CLIENTE, e os CLIENTES poderão ter MUITOS CTRCs.

Adaptando isso para sua aplicação, seria algo como

ManyToOne
private Endereco enderecoAtual;
ManyToOne
private Endereco enderecoFuturo;

Ou seja, vc teria duas chaves estrangeiras de endereço dentro da tabela cliente.

Espero ter ajudado,

Abraço.

EDIT: Uso Hibernate/JPA
[/quote]

Igor, ele ainda está nos primeiros passos do desenvolvimento, criando os relacionamentos no banco de dados, a tecnologia que vai utilizar pode até estar definida, mas não interfere em nada, ao menos neste momento.
O que irá interferir, e muito, é se a construção dos modelos das tabeloas não for bem feito, aí, das duas uma, ou ele refaz ou não segue o modelo…

Por isso sou um ferrenho defensor da análise e design antes de começar a programar (embora essa fase seja bem chata)

#7

drsmachado isso que eu ia dizer, voce falou tudo.
também pego firme nessa parte, até porque se voce construir o melhor predio do mundo com as colunas de sustentacao mal feitas o primeiro vento forte e lá vai tudo pra baixo.

Gostei da sua sugestao é oque eu estava pensando também, se alguémtiver alguma sugestao melhor gostaria de saber.

#8

drsmachado, concordo com vc, na verdade meu exemplo foi só pra chegar ao entendimento da resolução (na minha opinião) final.

Que ele poderia fazer uma tabela com duas chaves estrangeiras, repondi dessa forma por causa da dúvida dele no post acima do meu, ai achei interessante demonstrar com um exemplo prático, independente de ele utilizar framework ou não, só demonstrei que da pra usar duas chaves estrangeiras em cima daquela lógica

#9

Ola v0olverine,

Desculpe, nao havia visto a relacao N para N entre cliente e endereco.
Realmente, voce esta correto, toda relacao N para N devera ter uma tabela intermediaria, ClienteEndereco, contendo a chave estrangeira de Cliente e de Endereco.

Sobre o seu comentario:

"a nao ser que voce esteja me dizendo para quando eu for cadastrar outro cliente que resida em um endereco já cadastrado eu recadastre o mesmo endereco (que é uma opcao interecante que eu nao tinha pensado antes). "

Nao havia entendido que era N para N, entao nao recomendo o recadastro do mesmo endereco. Acredito que essa opcao seja alias um design nao desejado para a sua aplicacao.

E com relacao a uniao com a entidade Orcamento, ainda acredito que Orcamento deveria ter uma chave estrangeira para cliente e para o endereco. (endereco de entrega)

#10

obrigado a ajuda de todos !

#11