J'ai relation suivante. Une entreprise a plusieurs employés. Chaque employé est défini par son numéro d'employé ENr
et il vit sur une adresse EAddress
avec un ZipCode ZZipCode
. La ville avec le ZipCode est une table propre car sinon il y a redondance dans la table Employee. Par conséquent, ZZipCode
est une clé étrangère dans Employee.Relation de base de données dans 3NF?
Un groupe est défini par GGroupId
, donc c'est la clé primaire. Chaque groupe a un chef de groupe qui peut être n'importe quel employé. Par conséquent ENr
est une clé étrangère. Chaque employé ne peut travailler sur aucun, un ou plusieurs groupes. Pour cette raison, la table GroupMember
existe où le tuple ENr
et GGroupID
définissent la clé primaire et les deux sont des clés étrangères (je ne peux pas faire les deux, gras et italique). Enfin, un produit est défini par l'ID produit PId
et est associé à un groupe GGroupID
.
Eh bien voici les relations pour cette description écrite.
Employe (enr, ENAME, Egender, EAddress, ZZipCode, ESocNr, ESalery)
groupe (GGroupId, Gname, GCostNr, enr)
groupmember (enr, GGroupID) Les membres du #both sont les clés étrangères aussi!
Produit (PId, PName, PPrice, GGRoupId)
Zip (ZZipCode, ZCityName, SStateID)
État (SStateID, SStateName)
Pour plus de précisions: gras sont membres clés primaires et italiques membres sont des clés étrangères. J'ai essayé de mettre cette relation dans 3NF
. Quelqu'un peut-il confirmer que c'est juste?
Je ne suis pas sûr à propos de 3NF mais il est normalisé, je ne peux pas trouver de meilleures relations – Mustafa
Quelle forme de confirmation voulez-vous? Je veux dire, est-ce suffisant pour dire 'Oui, c'est'? :) – dezso
Eh bien, j'ai essayé de mettre cela en 3NF. Si ce n'est pas, vous pouvez me dire pourquoi pas;) – Razer