Dépendances fonctionnelles : définition et exemples

Une dépendance fonctionnelle (DF), notée A → B, existe quand la connaissance d'une valeur de A permet de connaître une seule valeur de B : connaissant le numéro d'un adhérent, on connaît son nom. Les DF relient entre elles les données du dictionnaire. Elles servent à deux choses : trouver les entités et leurs identifiants avant de dessiner le MCD, puis vérifier que les tables sont bien normalisées. Ce chapitre les définit, montre comment les trouver et comment passer d'un graphe de DF à un MCD.

Définition et notation

On dit que B dépend fonctionnellement de A, et on écrit A → B, si à une valeur de A correspond toujours une seule valeur de B. On lit « A détermine B » ou « B dépend de A ». A est la source (ou partie gauche) de la DF, B sa cible (ou partie droite).

À Rivelire :

• num_adherent → nom_adherent : un numéro de carte correspond à un seul nom. L'inverse est faux : deux adhérents peuvent s'appeler Martin, donc nom_adherent ne détermine pas num_adherent.
• code_barre → code_site : un exemplaire est rattaché à un seul site (RG6). L'inverse est faux : un site possède de nombreux exemplaires.
• email → num_adherent : l'adresse électronique est unique (RG7), elle détermine donc l'adhérent. Ici la DF marche dans les deux sens.

Une DF peut avoir plusieurs données à gauche. Le rôle d'un contributeur dépend du couple contributeur-document (RG4) : Jean Dupuis peut être auteur d'un album et traducteur d'un autre. Ni le contributeur seul ni le document seul ne suffisent :

(num_contributeur, num_document) → role

DF élémentaire

Une DF A → B est élémentaire si aucune partie de A ne suffit à déterminer B. La question ne se pose que si A contient plusieurs données.

• (num_contributeur, num_document) → role est élémentaire : il faut les deux.
• (num_contributeur, num_document) → titre n'est pas élémentaire : num_document seul détermine déjà le titre.

Cette notion paraît théorique, elle est pourtant au cœur de la deuxième forme normale : une table dont un attribut dépend d'une partie seulement de la clé contient de la redondance.

DF directe et DF transitive

Une DF A → C est transitive s'il existe une donnée B, différente de A et de C, telle que A → B et B → C. Sinon, elle est directe.

num_document → code_genre       (directe : RG3)
code_genre   → libelle_genre    (directe)
num_document → libelle_genre    (transitive : elle passe par code_genre)

Il est vrai que connaître le document permet de connaître le libellé de son genre. Mais cette information est portée par le genre, pas par le document. Si on la rangeait avec le document, on la recopierait sur les 800 romans policiers du catalogue. La troisième forme normale interdit justement les DF transitives entre la clé et les autres attributs.

Trouver les dépendances fonctionnelles

La méthode tient en une question, posée pour chaque paire de données qui semblent liées : « Connaissant une valeur de A, est-ce que je connais une seule valeur de B ? » La réponse vient des règles de gestion. Quand elles ne disent rien, demande à l'utilisateur, ou écris ton hypothèse.

Commence par les données qui ressemblent à des identifiants (numéros, codes) : ce sont les sources probables. Puis rattache chaque autre donnée à la source dont elle dépend directement. Voici le résultat pour Rivelire, sans les données de la RG13 :

code_site        → nom_site, adresse_site, ville_site
code_genre       → libelle_genre
num_document     → titre, annee_parution, resume, code_genre
num_contributeur → nom_contributeur, prenom_contributeur
code_barre       → date_acquisition, etat, num_document, code_site
num_adherent     → nom_adherent, prenom_adherent, date_naissance, email, date_inscription
num_emprunt      → date_emprunt, date_retour_prevue, date_retour, num_adherent, code_barre
(num_contributeur, num_document) → role
(num_adherent, num_document)     → date_reservation

Cette liste ne contient que des DF élémentaires et directes : c'est ce qu'on appelle une couverture minimale. Les DF qu'on peut en déduire (comme code_barre → titre, qui passe par num_document) n'y figurent pas.

Deux données ne dépendent de rien, et c'est normal :

• les données calculées (âge, nombre d'emprunts en cours) ont été retirées du dictionnaire au chapitre précédent ;
• les paramètres (durée de prêt, nombre maximal d'emprunts) ne dépendent d'aucune source : ils sont les mêmes pour tous.

Si une donnée élémentaire ne dépend d'aucune source, c'est le signe qu'il manque un identifiant. Avant RG9, on aurait pu croire que (num_adherent, code_barre) → date_emprunt. Mais un adhérent peut emprunter deux fois le même exemplaire : le couple ne détermine pas une seule date. Il faut donc un identifiant propre à chaque emprunt, num_emprunt. Cette situation, très fréquente, s'appelle l'historisation (chapitre 7).

Le graphe des dépendances fonctionnelles

On représente souvent la couverture minimale par un graphe : chaque source est une boîte, une flèche va de la source vers les données qu'elle détermine. Le graphe montre d'un coup d'œil les chaînes de DF.

Lis-le en suivant les flèches : un emprunt détermine son exemplaire, qui détermine son document, qui détermine son genre. Chaque flèche qui va d'une source vers une autre source deviendra une association du MCD.

Des dépendances fonctionnelles au MCD

Le graphe des DF contient presque tout le MCD. Quatre règles permettent de passer de l'un à l'autre.

Appliqué à Rivelire, le graphe donne sept entités (SITE, GENRE, DOCUMENT, CONTRIBUTEUR, EXEMPLAIRE, ADHERENT, EMPRUNT), cinq associations issues des flèches entre sources (le document et son genre, l'exemplaire et son document, l'exemplaire et son site, l'emprunt et son adhérent, l'emprunt et son exemplaire) et deux associations porteuses (contribuer avec role, réserver avec date_reservation). Il manque une seule chose, que le graphe ne montre pas bien : le lien entre un adhérent mineur et son responsable, qui relie l'entité ADHERENT à elle-même. Le chapitre 4 dessine ce MCD.

Exercices

num_client   → nom_client, tel_client
code_agence  → ville_agence
num_velo     → modele, date_mise_service, code_agence
code_tarif   → prix_jour
num_location → date_debut, date_fin, num_client, num_velo, code_tarif