Enseigné dans le M2 PISE de l'Université Paris 7 par Christophe DARMANGEAT.

Toutes les erreurs, insuffisances et plaisanteries affligeantes contenues dans ce site
relèvent de la seule responsabilité de la bassesse de leur auteur (NB : attention, jeu de mots).

Si ce cours vous a instruit, ou amusé, ou mieux, les deux à la fois, n'hésitez surtout pas à me remercier en m'invitant au restaurant ou sur une barrière de corail. Ou mieux, les deux à la fois.

Situations embarrassantes

Un des problèmes les plus fréquemment rencontrés par le modélisateur débutant est de savoir comment définir les relations entre plusieurs entités qui « marchent ensemble » - mais comment ? Si l'on prend le cas où l'on a trois entités, il y a trois grandes façons de les relier :

  • Deux relations simples (figure A)
  • Trois relations, reliant les trois entités deux à deux (figure B)
  • Une seule relation de dimension trois (figure C)

Arrivés à ce point, j'ai pour vous deux mauvaises nouvelles et une bonne.

Première mauvaise nouvelle : les trois solutions ne sont jamais équivalentes. Autrement dit, opter pour une des trois solutions au pif vous conduira dans le décor deux fois sur trois en moyenne (si en plus vous êtes malchanceux, ça peut être plus souvent).

Deuxième mauvaise nouvelle : il n'y a pas de truc miracle qui permette de choisir la bonne option sans avoir à réfléchir au problème à résoudre. Autrement dit, tout réflexe du genre « J'ai fait comme ça la dernière fois, ça a marché » ou « Ca m'a l'air sympa ce joli dessin-là » a peu de chances de vous conduire au bon résultat.

Maintenant, la bonne nouvelle : la modélisation étant une activité rationnelle, elle ne relève pas des processus cognitifs de la magie noire. Donc, si on réfléchit avec un chouia de méthode, on trouve la bonne solution.

1. Quelques remarques générales

  • Dans la figure A : comme on le constate, il n'existe pas de lien direct entre les éléments de l'entité 1 et ceux de l'entité 3. Ce lien est établi de manière indirecte (par transitivité, diraient les matheux) mais il faut raisonner à partir des cardinalités pour vérifier si les informations peuvent bel et bien être retrouvées de la manière dont l'exigent les besoins du problème.
  • Dans la figure B : le fait majeur est que chaque entité est doublement reliée aux deux autres. La table 1 est reliée directement à la table 3, et elle lui est aussi reliée via l'entité 2. A partir de là, de deux choses l'une.
    • Soit ces relations expriment toutes une même réalité : par exemple, si l'on prend des clients, des commandes et des produits, on dira que les clients passent des commandes, que les commandes portent sur des produits, et que les clients commandent des produits. Il y a là un problème d'architecture, car la même réalité est codée deux fois. On s'expose alors à ce que l'une des deux voies de relation disent autre chose que l'autre... ce qui est catastrophique. Et si elles disent toutes les deux la même chose, c'est bien qu'il y en a une qui ne sert à rien...
    • Soit ces relations ne parlent pas toutes de la même chose. Par exemple, la relation entre Clients et produits ne porte pas sur des affaires de commandes, mais dit que tel client a droit à une remise sur tel produit. Dans ce cas, pas de souci : la relation peut fort bien paraître doublée, en réalité, elle ne l'est pas : il s'aggit bien de deux chemins de relations différents.
  • Dans la figure C : les trois entités sont associées « simultanément ». Une manière plus juste de s'exprimer sera de dire que tout élément de chaque entité peut librement être associé à tout élément des deux autres entités. Ce modèle exprime la plus grande souplesse, puisque toutes les combinaisons sont possibles. Il s'applique aux situation dans lesquelles il n'y a pas de régularité (certains éléments étant associés à certains autres, et seulement à ceux-là).

2. Brève étude de cas

Les raisonnements généraux valent ce qu'ils valent, mais pour mieux se retrouver dans tout cela, il n'est pas inutile de partir d'un exemple. Imaginons que nous modélisions un centre de formation. Nous aurons donc à gérer (entre autres) des profs, des groupes d'élèves et des salles d'enseignement. On s'en doute, il existera une entité profs, une entité groupes et une entité salles. Mais la difficulté est de déterminer quelle sera la nature des relations que ces entités devront entretenir entre elles.

 

Hypothèse n°1 : chaque prof a en charge un certain nombre de groupes (toujours les mêmes sur une période donnée), et chaque groupe a toujours cours dans la même salle

Il faut bien évidemment relier les profs aux groupes (chaque groupe a-t-il un seul prof ou peut-il en avoir plusieurs, on ne le sait pas a priori, mais cela ne change rien pour la suite de notre raisonnement). De même, on doit relier les groupes aux salles. On a donc a priori une figure de type A, avec comme entité centrale les groupes.

On peut néanmoins se demander s'il ne faudrait pas ajouter à cela une relation directe entre les profs et les salles, comme dans la figure B, pour dire « tel prof a cours dans telle salle ». On comprend vite que cela ne servirait qu'à compliquer les choses, sans apporter la moindre information supplémentaire. En effet, avec une architecture de type A, on sait déjà que tel prof a en charge telle groupe, et on sait aussi où chaque groupe a cours. On peut donc facilement retrouver dans quelles classes enseigne chaque prof. Si j'adopte la figure B, la relation supplémentaire qu'elle introduit signifie qu'on va dorénavant noter ce renseignement indépendamment du cours concerné. Soit cette information supplémentaire est cohérente avec celle que me donnait la chaîne qui reliait les profs aux classes et les classes aux cours, et elle n'apporte donc aucune information supplémentaire. Soit elle n'est pas cohérente avec ce qu'on peut reconstituer au travers de la chaîne profs - classes - salles, et l'administrateur de la base de données va avoir quelques nuits blanches. Bref, dans les deux cas, ce ne sont que des ennuis et aucun avantage.

Reste la possibilité d'une seule relation tridimensionnelle (figure C). Il faudrait alors informer le système de chaque combinaison prof-classe-salle. A priori, tout va bien... sauf que nous ouvririons ainsi la possibilité de saisir que le groupe X a cours tantôt en salle 120, tantôt en salle 124, etc. Or, il était bien stipulé que chaque classe avait toujours cours dans la même salle. Exit donc cette solution.

 

Hypothèse n°2 : au coup par coup, un prof prend en charge un groupe et fait cours dans une salle. Les salles ne sont pas toujours attribuées aux mêmes profs ni aux mêmes groupes. Et les groupes ne sont pas toujours pris en charge par les mêmes profs.

On reconnaît là la situation où chaque événement rassemble à la fois un prof, un groupe classe et une salle, sans aucune contrainte ni obligation de régularité. Autrement dit, il faut que mon modèle autorise à associer à tout moment tout élément des entités profs, groupes et salles : il s'agit évidemment d'une relation du type de la figure C.

Par acquit de conscience, regardons ce qui se passerait si j'optais pour la figure A. Dans ce cas, je pourrais établir les relations entre profs et groupes et entre groupes et salles. Mais, du fait que chaque prof serait potentiellement associé à plusieurs groupes, chaque groupe à plusieurs profs et à plusieurs salles, et chaque salle à plusieurs groupes, je n'aurais aucun moyen de reconstituer, à un moment donné, quel prof a cours dans quelle salle. Rajouter une relation directe entre les profs et les salles, avec une figure de type B, ne m'avancerait pas à grand chose : je saurais quels profs ont cours dans quelles salles, mais pas avec quelle classe (de même, je continuerais à savoir quels groupes ont cours dans quelle salle, mais pas avec quel prof, et quels profs ont cours avec quel groupe mais pas dans quelle salle).

 

Hypothèse n°3 : les profs ont en charge certains groupes, qui ont toujours cours dans les mêmes salles. Mais sur certains créneaux horaires, les salles servent aussi de lieux de permanence pour les profs.

Comme vous vous en doutez, voilà un cas qui doit être modélisé par la figure B. En effet, dans cette hypothèse, il existe entre les profs et les salles deux relations de nature tout à fait différente. D'une part, les profs peuvent accéder à une salle dans le cadre de leur permanence : c'est la relation directe entre les deux entités. D'autre part les profs sont affectés à des groupes qui sont eux-mêmes affectés à des salles d'enseignement : c'est la relation indirecte (des profs aux groupes, et des groupes aux salles).

Opter pour la figure A serait s'interdire de pouvoir enregistrer les permanences. Opter pour la figure C serait de surcroît ouvrir la porte au fait que chaque classe ne serait pas toujours dans la même salle.

 

Conclusion : Répétons-le, des trois figures présentées ci-dessus, aucune n'est « juste » ou « fausse » en elle-même. Toutes sont des modélisations pertinentes de certaines situatiosn réelles... et inadaptées à d'autres situations. Je ne peux donc que répéter : il n'y a pas de « truc » qui dispense de réfléchir à chaque problème pour trouver la solution idoine...