Tabela pode conter 3 ou mais Chaves Estrangeiras?

[Carlos Antoliv 6]

Tabela pode conter 3 ou mais Chaves Estrangeiras, de acordo com a normatização?

Funciona assim, estou desenvolvendo um pequeno sistema em PHP, onde tenho

a tabela vendedora.

Sendo que cada vendedor recebe da empresa um tablet, um chip para o tablet,

telefone, um chip para o telefone e um modem;

 

Criei uma tabela para cada um que realizando o cadastro das informações como a marca, modelo, imei, serial.

tb_chip
tb_tablet
tb_cel
tb_modem

 

Ou seja, um para (1:1)

Preciso dizer que o chip tal é do tel tal e o outro chip tal é do modem tal

 

O que pensei em fazer...

criar uma tabela associativa:

tb_chip com tb_cel > pego o id da tabela associativa e insiro no cadastro do cliente;

mesma coisa para tb_chip e tb_modem;

Mesma coisa para tablet;

 

 

Resumidamente, funcionaria assim:

tb_vendedores

 

- tb_chip
- tb_cel > gera > id

- tb_chip

- tb_modem > gera id

 

tb_tablet > gera id

 

dentro da tb_associativa jogo esses 3(três) IDs

pego o ID da tb_associativa e insiro na tb_vendedores

 

 

Estes métodos estariam corretos? Um tempo atrás estudei 1FN, 2FN e 3FN, mas

dentro desse parâmetros que estou passando, fiquei um pouco pensativo.

 

pensei também em colocar o id das tabelas direto no cadastro do vendedor, ou seja

tb_chip

tb_cel

tb_modem

tb_tablet

tb_chip < mesma tabela, mas número diferente

 

Totalizando 5(cinco chaves estrangeiras);

 

 

Alguém poderia me auxiliar?

[Motta 645]

Pensou em

vendedor---------<kit_vendedor>-----kit

vendedor 
id_vendedor

kit_vend
---------
id_vendedor
id_kit
id_vigencia

kit
----
id_kit
chip
cel
modem
tablet

O vendedor pode mudar de kit , ter mais de um (se for o caso) e se tem um histórico

PS : Uma tabela pode ter sim N FKs

[Carlos Antoliv 6]

Agradeço pela resposta e atenção, Motta.

 

Não entendi muito a tua visão.

Porque veja bem: para cada dispositivo tenho atributos.. do tipo: marca, modelo, serial e imei.

Os dispositivo são: tablet, modem, cel, chip.

 

preciso associar cada um deles ao chip e depois que estiveram associados e relacionar a tb_vendedor, pois o vendedor só pode trabalhar depois de receber os dispositivos e dos chips associados aos dispositivos.

 

 

Pensei 1 milhão de maneiras, mas não sei qual seria a que mais se enquadra na normatização.

 

1 FORMA:

 

tb_chip + tb_modem > gravo o id em uma outra tabela, que pode ser tb_associar, exemplo;

tb_chip + tb_cel > gera id para tb_associar

tb_tablet > gravar id na tb_associar

 

ou seja, possuo 3 FK;

 

Minha dúvida é: será que jogando esses 3 FKs para uma outra tabelas, chamando-a de associativa e pegando o ID dessa tabela e jogando na tb_vendedores... isso seria correto? Causaria alguma inconsistência no banco?

 

2 FORMA:

 

criar um tb_dispositivos e cadatrar todos eles: tablet, modem, cel

criar também tb_chip

 

associar:

tb_dispositivo + tb_chip

gerar o id em uma outra tabela, tipo tip_dispositivo, pegar o id e associar a tb_vendedor

 

 

 

Não sei se consegui me expressar.

 

 

mas essas seriam as ideias.

 

 

O que acha?

[Motta 645]

Criei uma entidade artificial o "kit" que agrupa o

chip
cel
modem
tablet

 

Vínculo o kit ao kit_vendedor

Fica uma só fk , permite um histórico do que ficou com o vendedor.

Talvez mais trabalhoso para cadastrar.

[Carlos Antoliv 6]

Acho que entendi. Trocando o nome Kit para dispositivo, ficaria:

 

tb_dispositivo

- tipo_dispositivo;

- marca_dispositivo;

- modelo_dispositivo;

- serial_dispositivo;

- imei_dispositivo;

tb_chip

- num_contato_chip;

- radio_id_chip;

- num_controle_chip;

- operador_chip

tipo_dispositivo;

- id_tipo_dispositivo;

- fk_dispositivo_e_chip;

DENTRO DE TB_VENDEDOR

- id_vendedor;

- fk_tipo_dispositivo;

Será que poderia ser assim?

É mais ou menos isso que você

está sugerindo, Motta?

[Motta 645]

Não, mas parece ser outra solução.

 

Dispositivo abrangeria chip.kit etc , não ?

 

Só não colocaria em vededor pois limita a um , se perde histórico e se a regra mudar (mais de um por vendedor)

o modelo não atenderia mais

[Carlos Antoliv 6]

"Só não colocaria em vededor pois limita a um " não entendi.

Porque a ideia é atribuir todos esses dispositivos a um vendedor.

Tendeu..?

[Motta 645]

Colocando como atributo (campo) se limita um disposito á um vendedor. colocando em tabela se permite N dispositos para um vendedor.

[Carlos Antoliv 6]

Entendi.

O que você aconselharia, Motta?

[Motta 645]

Não sei , é sempre uma decisão difícil entre simplificar mas limitar ou abrir e "complicar".

Qual a chance da regra mudar ?

Precisa de um histórico?

[Carlos Antoliv 6]

Motta, eu pensei assim: no cadastro do vendedor, inserir o listMenu de cada um dos dispositivos(chip, modem, tablet, celular), ou seja, total de 4 listmenu.

Bom, tenho duas opções; posso criar uma tabela que contenha todos os dispositivos, ou tabela para cada dispositivo e inserir o FK de cada uma na tabela vendedor.

Mas não sei se seria o correto.

[Motta 645]

Dispositivos distintos , atributos distintos, eu tenderia a tabelas distintas.

 

O problema seria surgir um novo dispositivo , o sistema teria de ser alterado.

[Carlos Antoliv 6]

Ah tah...agora entendi.. bom, na verdade, os dispositivos não mudam. Vão continuar assim por muito tempo. Cada um recebe tablet, chip, modem e aparelho celular. Nada além disso. Sempre será dessa maneira. Claro, num futuro bem distante, alguma coisa pode mudar. Mas é um futuro bem distante.
Um amigo meu disse que não se faz isso com tabelas distintas; o outro já disse que se faz com tabelas distintas. Bom...rsrs.. não entendi mais nada.

 

Minha ideia era criar uma tabela para cada dispositivo, ou seja, 4 tabelas distintas. Dessa quatro tabelas, uma faz ligação com duas tabelas, que é tabela CHIP.

Ou seja, se faz ligação com outra tabela, isso quer dizer que essa ligação sendo feita, esse ID gerado, eu teria que jogar para uma outra tabela, tipo, uma tabela que receba os IDs.. daí, então, fazer ligação com a tabela vendedor. Só que me disseram que não se faz assim devido aos padrões. Mas os mesmos que me disseram que não se faz assim, também naõ disseram como proceder.

Essa era minha dúvida.

[Motta 645]

Em modelagem não existe A solução, existem possíveis soluções com pontos fortes e fracos.

 

Os padrões diferem , em UML de fato esta solução deveria passar por 4 classes, em um DER nem tanto.

 

Meu modelo ainda seria o do post #2.

[Carlos Antoliv 6]

Resolvi da seguinte maneira, criei uma tabela para receber os "IDs".