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.

4 – La normalisation du modèle

Ce vocable barbare recouvre l'idée que pour être valide, un modèle doit obéir à un certain nombre de normes. Celles-ci ne sont pas toutes du même ordre : certaines sont de simples règles de bonne conduite (ou d'hygiène), destinées à évacuer certaines ambiguités pouvant s'avérer gênantes à l'usage. D'autres sont impératives et leur violation constitue à coup sûr une faute grave. Le mieux est de les respecter toutes, en comprenant pourquoi il ne s'agit pas de préceptes tombés du ciel dans le seul but de nous pourrir l'existence, mais au contraire, de pratiques rationnelles visant à nous la simplifier.

4.1 – Les redondances

C'est la règle principale, sur laquelle on ne saurait que trop insister : une modélisation correcte doit avoir éliminé toutes les redondances possibles de données en constituant des nouvelles entités chaque fois que nécessaire, comme nous l'avons fait dès le départ en regroupant les genres musicaux dans une entité séparée.

On doit donc explorer systématiquement toutes les propriétés de toutes les entités, en se demandant à chaque fois si les valeurs que prendront ces propriétés ne risquent pas de se répéter plus souvent qu'à leur tour.

4.2 – Les valeurs multiples

Créer une propriété aux valeurs multiples constitue sans doute une des plus grosses fautes possibles dans une base de données.

Les valeurs multiples ne doivent pas être confondues avec les redondances. Par valeurs multiples, on entend le fait qu'une même propriété, pour chaque enregistrement, soit censée posséder plusieurs valeurs à la fois. Prenons l'exemple d'un journal qui souhaite mémoriser ses articles et leurs auteurs. On imagine donc une entité Articles, avec le titre, le corps de l'article, sa date, etc. ... Ayant bien assimilé la partie précédente, on prend soin de constituer une entité Auteurs et d'établir une relation entre Articles et Auteurs.

Fort bien. Sauf qu'à ce moment-là, le rédacteur en chef nous fait remarquer qu'un article peut fort bien avoir été écrit par plusieurs auteurs. « Qu'à cela ne tienne ! », répondons-nous bravement. Et de là, il y a trois solutions... dont deux qui mènent droit à la catastrophe.

  1. la première, que j'ose à peine concevoir, consiste à oublier tout ce que nous avons vu jusque-là et à atribuer une propriété Auteurs (au pluriel !) à notre entité Articles. C'est évidemment un grand n'importe quoi. D'une part, cette propriété viendrait tout à la fois télescoper l'entité Auteurs et la relation que nous avions établie avec elle. D'autre part, on se demande bien ce que pourrait recouvrir une propriété figurant au pluriel, et possédant donc plusieurs valeurs à la fois pour chaque enregistrement de la table...
  2. la deuxième est la plus fréquente, et c'est celle-là que j'ai appelée « la faute des valeurs multiples ». Elle consiste à créer autant de propriétés que de co-auteurs possibles, en les appelant en général Auteur1, Auteur2, Auteur3, etc., et en considérant que chacune de ces propriétés est en relation avec l'entité Auteurs. Cette architecture va produire un galimatias à peine moins horrible que le précédent : outre qu'on nage en pleine confusion entre MCD et MLD, il est évidemment hors de question d'avoir une entité ressemblant à un emmental, avec des Null à tous les coins de rue (car tous les articles n'auront pas le maximum d'auteurs que nous avons prévu).
    3. Ces deux fautes incarnent les deux formes possibles des propriétés à valeurs multiples. Elles sont tout aussi catastrophiques l'une que l'autre.
  3. en fait, la troisième solution est non seulement la seule correcte, mais c'est aussi, en réalité, la plus simple : la relation entre Articles et Auteurs est de type plusieurs à plusieurs, et se traduira dans le MLD par la création d'une table de jonction.

4.3 – Les synonymes

Les redondances d'informations au sein d'une même propriété ne sont pas les seules à devoir être traquées. Dans un modèle un peu compliqué, on peut vite être amené, volontairement ou non, à faire figurer plusieurs fois (dans plusieurs entités différentes) la même information – mettons, le nom du titulaire d'une police d'assurance. Lorsqu'une telle situation se produit, c'est toujours – hormis dans des contextes très particuliers – une erreur.

On se fixera donc comme principe qu'une information doit toujours figurer de manière unique dans un modèle. En effet, outre la perte de place occasionnée par une telle répétition, c'est surtout le risque d'une divergence entre les différentes copies de l'information qui est à craindre ; par exemple, une même personne qui se retrouverait au bout d'un moment répertoriée sous des noms à l'orthographe diverse selon qu'on est en train de parler de son assurance-vie, de son logement ou de ses versements de mensualités….

Ce deuxième principe peut être d'autant plus difficile à appliquer (mais d'autant plus nécessaire) que l'entreprise ou l'organisation elle-même répertorie les mêmes informations sous des noms différents (par exemple, le « code produit » dans un service, et la « référence » dans un autre). L'informaticien peut donc être trompé par ces noms différents et ne pas comprendre qu'ils désignent en fait la même information.

Ce type de biais est appelé, dans le jargon de Merise, un synonyme. Et les synonymes doivent donc être éliminés méthodiquement et sans pitié.

Synonymes indirects : j'appelle ainsi une situation où plusieurs informations différentes figurent dans la base alors que certaines peuvent être déduites des autres. Imaginons par exemple que nous trouvions dans notre base une liste de marchandises avec leurs prix hors taxes, les taux de TVA, le montant de la TVA et les prix toutes taxes. Il est clair que les deux dernières informations se déduisent des deux premières par calcul. Donc, la mauvaise architecture choisie conduit, au mieux, à stocker des informations pour rien (si les calculs sont justes) ; soit à des discordances d'information s'ils sont faux.

4.4 – La polysémie

La polysémie pourrait être un nom de maladie. Dans un sens, d'ailleurs, c'en est effectivement une. Elle est l'exact inverse du synonyme, mais elle est tout aussi nuisible à la bonne santé du système d'information.

Si le synonyme consiste à désigner la même information par des noms différents, la polysémie consiste à désigner des informations différentes sous le même nom. Par exemple, une propriété « référence » qui représenterait ici le code d'un produit, là celui d'un fournisseur, et ailleurs celui d'un client.

Même si dans l'absolu, la polysémie n'entraîne pas obligatoirement des problèmes fatals (tant que les polysèmes figurent dans des entités différentes), elle représente tout de même un choix bien dangereux. C'est une source potentielle de confusions. Or, en informatique, on a déjà bien assez de travail avec les problèmes inévitables ; les problèmes évitables, autant... les éviter.

Pour lutter contre la polysémie, il existe un truc aussi simple qu'imparable : utiliser systématiquement des noms de propriétés composés, qui se termineront par le nom de la table à laquelle elles appartiennent. En quelque sorte, le nom de la propriété est un prénom, celui de la table un nom de famille ! Ainsi, par exemple, on peut avoir comme propriétés code_disque, titre_disque, artiste_disque, etc. Dans le cas que j'évoquais à l'instant, on ne risquerait plus de confondre référence_produit, référence_fournisseur et référence_client.

À pratiquer systématiquement donc, dès que la base commence à prendre un peu d'ampleur et que le risque de polysémie commence à montrer le bout de son nez.

4.5 – La recherche de la transitivité

La transitivité est cette propriété mathématique qui dit qui si A est dans une certaine relation avec B, et B avec C, alors A est en relation avec C. Appliqué à la question de la modélisation, cela veut dire qu'il faut veiller à ne pas doubler inutilement les chemins entre les tables.

Reprenons, une fois encore, le cas de notre discothèque. La situation de départ peut être modélisée par trois entités : des artistes, des CDs et des genres. Les artistes sont en relation avec les CDs ; les CDs sont en relation avec les genres. La question est : est-il bénéfique, neutre ou nocif de mettre de surcroît les artistes en relation avec les genres ?

De deux choses l'une. Soit nous ne voulons signifier rien de plus que : « tel artiste a créé des oeuvres qui relèvent de tel et tel genre, on peut donc dire que lui-même se rattache à tel et tel genre ». Mais alors, on voit très bien que cette idée se déduit de la double relation Artistes - CDs et CDs - Genres. Rajouter une relation directe entre Artistes et Genres ne ferait, dans ce cas, qu'au mieux aujouter une information inutile, au pire introduire des discordances. Soit (et même si, en l'occurrence, on peut penser que c'est un peu stupide), on se dit qu'on veut établir par avance une série de genres pour chaque artiste afin de vérifier que ses oeuvres sont bel et bien conformes à son style. Alors – mais seulement alors &ndash il y a un sens à doubler la relation Artistes - CDs et CDs - Genres par une relation directe Artistes - Genres.

On peut formuler le principe général en disant qur dans un MCD, une relation ne doit jamais être redondante par rapport à une autre (ou une série) d'autres. En clair, il ne peut y avoir qu'un seul chemin entre une entité A et une entité B, sauf si les différents chemins correspondent à des significations différentes. La normalisation doit donc veiller à éliminer ces éventuelles relations parasites.

On trouvera une illustration très claire de ce principe dès le prochain chapitre.