Correction - Dépendances fonctionnelles et formes normales

Dépendances fonctionnelles

Question 1 : La dépendance fonctionnelle correcte est EMPNO $ \rightarrow $ ENAME car à chaque n° d’employé (empno) correspond au plus un nom d’employé (ename). L’autre proposition est fausse.

Question 2 : Du fait de la question précédente on voit bien qu’une dépendance fonctionnelle n’est pas forcément symétrique.

Question 3 :

  1. JOB $ \rightarrow $ ENAME : NON
  2. ENAME $ \rightarrow $ JOB : NON
  3. DEPTNO $ \rightarrow $ MGR : NON
  4. DEPTNO $ \rightarrow $ DNAME : OUI, OUI
  5. EMPNO, DNAME $ \rightarrow $ JOB : NON
  6. EMPNO, DNAME $ \rightarrow $ MGR : OUI, NON
  7. EMPNO, DEPTNO $ \rightarrow $ JOB : OUI, OUI
  8. EMPNO, DEPTNO $ \rightarrow $ LOC : OUI, NON

Question 4 : On voit que empno détermine ename, mgt, hiredate, sal et comm tandis que deptno détermine dname et loc. Pour éviter les redondances il faut donc que la clef soit (empno, deptno).

Formes normales

Question 5 :

  1. LIVRAISON(n°fournisseur, listeVilles) : pas en 1NF, le stockage d’un attribut qui contient une liste impose une syntaxe SQL complexe pour sortir chaque ville et l’interroger.
  2. LIVRAISON (n°fournisseur, ville) : 1NF, la clé sur fournisseur implique qu’un fournisseur ne fournisse qu’une ville, ou alors, il faut mettre la clé sur fournisseur et ville.
  3. CLIENT (n°client, nom, prénoms) : pas en 1NF, même explication que 1.
  4. CLIENT (n°client, nom, prénom1, prénom2) : 1NF, les prénoms sont indiqués dans des champs différents.
  5. CLIENT (n°client, nom, prénom, adresse) : pas en 1NF, si on veut récupérer en SQL certains éléments de l’adresse comme la ville par exemple. Si l’on veut récupérer l’adresse comme un tout, la relation peut alors être considérée en 1NF.

Question 6 :

  1. PRET (n°isbn, n°adherent, date, nom_adherent, ville_adherent, titre_livre) : pas en 2NF car n°adhérent $ \rightarrow $ nom_adherent et n°isbn $ \rightarrow $ titre_livre.
  2. PRET (n°isbn, date, n°adherent, nom_adherent, ville_adherent, titre_livre) : pas en 2NF car n°isbn $ \rightarrow $ titre_livre.
  3. PRET (n°isbn, n°adherent, date) : 2NF, tous les attributs font partie de la clé !
  4. PRET (n°exemplaire, date, n°adherent) : 2NF

Question 7 :

  1. FOURNISSEUR (n°fournisseur, ville, pays) : pas en 3NF, si ville $ \rightarrow $ pays, sinon 3NF, cas de Brest qui peut être en France ou en Biélorussie.
  2. PERSONNEL (n°agent, nom, département_recherche, bâtiment) : 3NF, si l’on prend le cas de notre école où un département peut être réparti sur plusieurs bâtiments. 2NF, uniquement si département_recherche $ \rightarrow $ bâtiment.
  3. PERSONNEL (n°agent, nom, département_recherche, statut_agent) : 3NF
  4. VOL(n°vol, compagnie, heure, destination, modele_avion, nombre_passagers) : 3NF
  5. VOL(n°vol, compagnie, heure, destination, modele_avion, nombre_places) : pas en 3NF, uniquement en 2NF car modele_avion $ \rightarrow $ nombre_places.

Question 8 : Il s’agit de minimiser les redondances pour assurer l’intégrité des données lors des mises à jour.