2012-05-24 3 views
1

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?

+0

Je ne suis pas sûr à propos de 3NF mais il est normalisé, je ne peux pas trouver de meilleures relations – Mustafa

+0

Quelle forme de confirmation voulez-vous? Je veux dire, est-ce suffisant pour dire 'Oui, c'est'? :) – dezso

+0

Eh bien, j'ai essayé de mettre cela en 3NF. Si ce n'est pas, vous pouvez me dire pourquoi pas;) – Razer

Répondre

1

Cela semble être bonne et normalisée. Je ne vois pas de division supplémentaire des tables.

Questions connexes