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.

5 – Techniques avancées

5.1 – Relations multiples

Il est tout à fait possible que deux entités soient reliées à la fois par plus d'une relation.

Une telle possibilité n'a rien d'absurde, et correspond à beaucoup de situations de la vie réelle.

Imaginons, par exemple, que nous ayons à modéliser les relations entre une population et un parc immobilier. Nous aurons deux entités : l'une qui identifiera les différents individus (et dont les propriétés seront leurs noms, prénoms, n° de sécurité sociale, etc.). L'autre entité recensera les différents logements (n° d'appartement, étage, adresse, etc.). Or, il est clair que la relation d'un individu avec un logement peut être de plusieurs natures différentes, qui sont très largement indépendantes les unes des autres :

  • il peut en être propriétaire
  • il peut en être locataire
  • il peut en être bailleur
  • il peut l'occuper à titre de résidence principale
  • etc.

Face à ce problème, la solution est simple : les deux entités Individus et Logements doivent être reliées simultanément par plusieurs relations différentes. On parle alors d'associations plurielles. Cette technique illustre, en quelque sorte à l'envers, la question de la transitivité : il peut y avoir plusieurs relations qui mènent d'une entité à l'autre, à condition que ces relations possèdent des significations différentes.

5.2 La réflexivité

5.2.1 Principe général

Encore un mot de matheux pour désigner une chose pas si compliquée qu'elle en a l'air, à savoir qu'une relation peut concerner des éléments d'une même entité.

Supposons une base d'individus, par exemple les animaux d'un zoo. En vue de suivre les pedigrees de chaque bébête, nous devons enregistrer qui est l'enfant de qui. Pour cela, il nous faudra relier l'entité Animaux à elle-même, par la relation « est le parent de… ». Cela peut paraître un peu bizarre, mais en réalité, cela ne pose aucun problème.

On pourra donc modéliser tout cela dans notre MCD de la manière suivante :

5.2.2 Du MCD au MLD

Au niveau du MLD, il n'y a rien de particulier à signaler – les règles exposées plus haut s'appliquent. Si la relation réflexive est de type « un à plusieurs », avec une cardinalité minimale de 1, cette relation prendra la forme d'une propriété supplémentaire dans la table, destinée à contenir l'ID de l'élément concerné. Par exemple, la relation « est le père de », qui entre dans ce cas de figure (un père peut avoir plusieurs enfants, mais un enfant ne peut avoir qu'un seul père) se manifestera par un champ code_père, dans lequel on entrera, le cas échéant, l'ID du père :

Si, en revanche, la relation réflexive est de type « plusieurs à plusieurs », elle donnera lieu à une nouvelle table. Celle-ci comportera deux champs, chacun des deux contenant l'ID d'un des deux animaux susceptibles de cohabiter. Et, toujours aussi logiquement, cette table de jointure sera reliée au champ ID_animal de la table Animaux par un double lien.

NB 1 : On peut très bien imaginer une situation où une relation serait à la fois réflexive et plurielle ! En plus de savoir qui est le parent de qui, on pourrait ainsi noter qui peut être mis dans la même cage que qui (certains individus ne peuvent pas se blairer, et se battent dès qu'ils en ont l'occasion). Dans ce cas, pas de problème, l'entité Animaux sera greffée de deux relations réflexives différentes (« est le parent de » et « peut cohabiter avec »).

NB 2 : Il serait en revanche tout à fait mal venu de créer deux relations, l'une « est le parent de » et l'autre « est l'enfant de ». Ce serait en quelque sorte un pléonasme, ces deux relations n'en faisant en réalité qu'une seule.

5.3 Relations avec attributs

5.3.1 – Principe général

Prenons le cas tout bête d'une entreprise qui gère les commandes de ses clients.

Dans une première entité figurent les commandes, avec leur date, leur référence, etc. Pour savoir de quoi est composée chaque commande, on se tourne naturellement du côté d'une entité qui regroupe l'ensemble des produits vendus par notre entreprise. Au premier abord, il semble que nous soyons face à une situation déjà rencontrée maintes fois :

Sauf qu'il y a un petit souci : je n'ai fait figurer nulle part la quantité dans laquelle chaque produit entre dans chaque commande. Par exemple, la commande n°456 peut porter sur 45 rideaux de douche à fleurs roses et 12 gants de toilette en crin, la commande n°508 sur 23 gants de toilette en crin et 3 savons de Marseille, etc. Or ces nombres (45, 12 et 23) doivent obligatoirement être stockés quelque part, faute de quoi mon système de gestion de factures ressemblera à une passoire.

Première possibilité : je les intègre à la table des commandes. Hum... Comment faire ? En créant un seul attribut ? Mais cela veut dire que pour une commande donnée, on ne pourra renseigner qu'un seul nombre. Or, dans une commande, on peut commander plusieurs produits çà la fois (chacun dans une quantité différente). Donc, ça ne va pas.

Deuxième possibilité : j'intègre les quantités à la table des produits. Mais là, c'est le même problème : Si je crée un nouvel attribut (et un seul), cela veut dire qu'à chaque produit correspond une quantité et une seule. Sauf qu'évidemment, Il se peut très bien que le nombre de Kiki en peluche commandés par Bidule soit de 7 546 tandis que Machin, lui, en a acheté 12. Donc, problème.

Je n'ose même pas imaginer créer plusieurs attributs (quantité 1, quantité 2, quantité 3, etc.) : que ce soit dans une table ou dans un autre, ce serait un flagrant délit de propriété à valeurs multiples, dont on a vu précédemment qu'il s'agissait d'une faute irrémédiable.

Nous voilà donc bien avancés... En fait, toute la difficulté vient du fait que le nombre de produits de chaque sorte qui ont été commandés est une caractéristique liée à chaque commande. La solution s'impose d'elle-même : cette information doit donc figurer au cœur même de la relation qui unit les commandes aux produits. À chaque fois qu'une nouvelle commande porte sur un nouveau produit, on doit se demander : « en combien d'exemplaires ? ».

L'information (la propriété) « Quantité commandée » n'est donc pas un attribut d'une des deux entités Commandes et Produits, mais comme un attribut de la relation qui les unit.

Ce que nous représenterons de la manière suivante :

Remarque vraiment intelligente : une relation ne peut posséder légitimement un attribut que si elle est de type « plusieurs à plusieurs ».

Démonstration par l'absurde:

  • imaginons qu'il ne puisse y avoir qu'un seul produit par commande. Dans ce cas, la quantité commandée serait unique pour chaque commande, et pourrait donc être un attribut de l'entité Commande.
  • inversement, si chaque produit ne pouvait être commandé qu'une fois et une seule, on pourrait ajouter la quantité comme attribut de l'entité Produits

Pour conclure, ajoutons que rien n'oblige une relation à posséder un seul attribut. Il est tout à fait possible qu'existent des relations avec deux, trois, quatre, etc. attributs.

5.3.2 – Passage au MLD

Aucune difficulté : une relation avec attributs étant nécessairement une relation « plusieurs à plusieurs », elle donnera naissance, lors du passage au MLD, à une nouvelle table (de jointure). Tout simplement, les attributs de la relation deviendront des propriétés supplémentaires de la table de jointure (en plus des codes correspondant aux clés primaires des tables concernées).

5.4 – Relations de dimension supérieure à 2

Aïe aïe aïe, encore du vocable matheux. Mais non, c'est rien, ça pique à peine au début et après on ne sent plus rien.

5.4.1 – Principe général

Partons simplement du fait que jusqu'à présent, les relations que nous avons modélisées ne mettaient toujours aux prises que des entités deux à deux : les CD et les genres musicaux, les commandes et les produits, etc. Il peut cependant arriver que la relation doive s'établir directement entre plus de deux entités (d'où le titre).

Prenons un système d'information qui gère le travail quotidien dans une université (bon courage). Chaque jour, des groupes d'étudiants ont cours dans certaines salles avec certains professeurs. Mais on suppose que tout dans cette histoire est susceptible de varier : dans une journée donnée, le même groupe peut avoir cours avec plusieurs profs dans plusieurs salles différentes, les profs peuvent donner plusieurs cours ou aucun, etc.

La manière la plus directe de modéliser une telle situation sera d'écrire que :

On est donc face à une relation impliquant non plus deux, mais trois entités, ce qui finalement, ne pose pas de problèmes particuliers. Au passage, on remarque qu'une relation de dimension supérieure à 2 peut fort bien comporter des atributs, comme toute autre relation (Ici, Heure_début_cours et Heure_fin_cours).

5.4.2 – Du MCD au MLD

On vérifie facilement qu'une relation de dimension supérieure à deux est forcément de type « plusieurs à plusieurs » (faudrait-il dire : « plusieurs à plusieurs à plusieurs » ? – en voilà une question qu'elle est bonne). Une telle relation devient donc systématiquement une table de jointure, comportant autant de champs que d'entités à relier.

6. – Esquisse d'une méthode générale

Si l'on tente de résumer l'ensemble des questions à se poser pour réussir une modélisation, on obtient quelque chose qui pourrait ressembler à ceci :

  1. Identifier l'ensemble des entités. Décomposer celles-ci autant que nécessaire, en se demandant si, pour chacune d'elles, il existe des propriétés dont les valeurs seront redondantes. Si oui, 99 fois sur 100, ces propriétés doivent être « externalisées » vers une nouvelle entité.
  2. Traquer et éliminer les valeurs multiples et les synonymes
  3. Quelles sont les relations ? Pour chaque relation établie entre les entités A et B, se demander : « un élément de A entre-t-il plusieurs fois en relation avec le même élément de B ? » Si non, c'est une relation simple (dont on examine ensuite les cardinalités). Si oui, quelles sont les informations qui différencient ces différentes associations. Si ces informations ne sont pas particulièrement redondantes, elles sont des attributs de la relation. Si elles sont redondantes, elles doivent être issues d'une entité, et la relation est donc de dimension > 2. Dans le cas où cette étape fait surgir une nouvelle entité, reprendre l'étape précédente.
  4. Vérifier que toute relation multiple, directe ou indirecte, d'une entité à une autre, se justifie par le fait que chacune d'elles exprime des significations différentes.
  5. Traquer et éliminer les polysèmes

Allez, là, ça va carrément être l'extase :

 

exercice 3
exercice 4
exercice 5
exercice 6
exercice 7
exercice 8