Bonsoir ptitdev,
C’est le MCD qui a pour objet de représenter graphiquement le besoin fonctionnel. Le MLD permet de traduire le MCD sous forme de tables, en tenant compte de la règle fondamentale suivante, voulue en 1970 par Ted Codd, inventeur du Modèle Relationnel de Données :
Chaque intersection d’une ligne et d’une colonne contient exactement une valeur du type applicable, et rien d’autre.
Si l’on n’a que les 3 tables CLIENT, COLLAB, COMPETENCE, leur représentation en extension pourrait ressembler à quelque chose comme ceci :
Table COMPETENCE
Id_competence Nom_competence
------------- --------------------
1 Analyse SI
2 PowerAMC
3 SQL Server
Table CLIENT
Id_client Nom_client Competences_Requises
--------- ------------ --------------------------
1 Ets Naudin 1
2 Madame Mado 1
3 Tomate & Cie 1, 2, 3, 4
Table COLLAB
ID_collab Nom_collab Competences_Detenues Clients
--------- ---------- -------------------- --------------
1 Raoul 2 1
2 Paul 2, 3, 7 1, 3
3 Jean 3, 1 2, 3
Examinons le contenu de la table CLIENT. L’attribut Competences_Requises est multivalué (d’où, en passant, l’utilisation du pluriel pour le nommer) : la règle fondamentale est violée. En outre, pour le client Tomate & Cie les collaborateurs devraient avoir les compétences 1, 2, 3, 4, or cette dernière n’existe pas, la table contient donc une erreur. Vous semblez penser qu’on s’en sortira « avec les clés étrangères qui vont bien », mais une valeur de clé étrangère doit avoir son homologue en tant que valeur de clé primaire (ou alternative) d’une table de la base de données : ces valeurs doivent être du même type, ce qui n’est pas le cas ici : l’attribut Competences_Requises est du type ARRAY (ou LIST ou apparenté), tandis que l’attribut Id_competence qui sert pour la clé primaire de la table COMPETENCE est du type INTEGER (ou équivalent) : comme dirait l’autre, y a du conflit de type dans cette affaire, ou comme disait Pascal (pas celui des Pensées, l’autre) : « M’sieur Fernand, vous la voyez, ce coup-là, l’embrouille ? »
Bref, sauf à passer à un SGBD NF² (Non Première Forme Normale) du genre O², il faudra vous résoudre à normaliser la table CLIENT, c'est-à-dire faire comme dit Codd dans son article fondateur, rendre vertical ce qui est horizontal :
Id_client Nom_client Competence_Requise
--------- ------------ ------------------
1 Ets Naudin 1
2 Madame Mado 1
3 Tomate & Cie 1
3 Tomate & Cie 2
3 Tomate & Cie 3
3 Tomate & Cie 4
Cette fois-ci, vous pourrez établir une contrainte référentielle et faire interdire la présence de la ligne <3, Tomate & Cie, 4>. Néanmoins, la clé primaire n’est plus le singleton {Id_client} mais la paire {Id_client, Competence_Requise}, or il existe la dépendance fonctionnelle {Id_client} → {Nom_client} faisant que la 2NF (deuxième forme normale) est violée, ce qui conduit à appliquer le théorème de Heath pour décomposer la table en deux tables ayant respectivement pour contenu :
Id_client Nom_client
--------- ------------
1 Ets Naudin
2 Madame Mado
3 Tomate & Cie
Id_client Competence_Requise
--------- ------------------
1 1
2 1
3 1
3 2
3 3
3 4
Curieusement, la structure de la 1re table ressemble comme deux gouttes d’eau à celle de la table CLIENT de mon message précédent et la structure de la 2e table ressemble étonnamment à celle de la table REQUISE_PAR : la boucle est bouclée...
Il est bien difficile, sinon illusoire de se limiter à 3 tables...
A titre d'exercice je vous laisse le soin de normaliser la table COLLAB.
Partager