Normalisez, normalisez encore, normalisez toujours…

une par une et critiquons les…

Règle n°1 : Une entité est en première forme normale si toutes ses propriétés sont élémentaires et s’il existe au moins une clef caractérisant chaque occurrence de l’entité.

Outre l’obligation de clef, l’atomicité d’un attribut doit être étudiée, non pas sous l’angle du pur modèle des données, mais sous l’angle des traitements qui devront être opérés sur cette donnée. Étudions par exemple, la collecte des informations sur des personnes. Un attribut NOM peut comporter le titre, le nom et le prénom d’une personne si aucun traitement particulier n’est envisageable sur ce conglomérat de données (données purement informationnelles). En revanche si l’on doit chercher une personne par son nom de famille ou établir des statistiques sur le sexe des personnes, alors il faudra séparer ces éléments.

Et si le traitement consiste à envoyer une offre promotionnelle au moment de la fête (Saint Claude, Saint Pierre…) alors il faudra probablement scinder les prénoms composés afin d’éviter une requête trop complexe ou l’envoi en double du bon de réduction ! Enfin, si le volume des données est très important il peut être intéressant d’externaliser les informations les plus redondantes comme le titre (M., Mme., Mlle…. ) ou le prénom. Cela économisera de nombreuses occurrences des Claude, Jean, Marc ou Luc… Bref, rien qu’à ce niveau, une seule table, mais déjà quatre modèles de données ! Voir Figure 1. Autre exemple : faut-il décomposer ou non un numéro national d’identité32 ?

Encore une fois, tout dépend du traitement. Dans une table d’employés, il y a peu d’intérêt de le faire. Mais dans une application de gestion de données médicales, cela peut revêtir une importance particulière, car ce numéro comporte le sexe, le lieu de naissance et indirectement donne une idée de l’âge, toute donnée qui peut avoir un intérêt magistral dans bien des cas où l’on fouillera les données à le recherche de corrélations entre l’âge, le sexe et la survenue de telle ou telle maladie ! À titre d’exercice, posez-vous la question de la modélisation d’une adresse IP33…

Règle n° 2 : Une entité est en deuxième forme normale si et seulement si elle est en première forme, et que tout attribut n’appartenant pas à une clef ne dépend pas que d’une partie de cette clef. Tout ce charabia pour nous dire que certaines informations anodines d’une table peuvent s’avérer être en partie redondante avec les informations contenues dans la clef. Dans la pratique, cette règle a deux implications : soit l’un de vos attributs peut dépendre de la clef, mais plus vicieux, si votre clef est décomposable, alors décomposez-la et constatez que parfois certaines informations n’ont pas besoin de figurer en sus de la clef.

Prenons un exemple. Notre numéro national d’identité constitué de 13 caractères est en fait une clef composée de 6 éléments (en sus de la clef permettant de contrôler la saisie). Dès lors comment modéliser correctement un patient pour lequel on aura prévu d’utiliser comme clef primaire de la table ce fameux numéro INSEE ? Le premier caractère donnant le sexe inutile de le redonder. Les caractères 6 à 10 donnant le département et la commune, inutile de saisir en sus le lieu de naissance, utilisons une table de références des communes par codification INSEE…

Voici résumé dans différentes étapes, un tel affinage du modèle (voir figures 2, 3 et 4)… Dans ce dernier modèle (figure 4) parfait du point de vue normalisation, plus aucune redondance n’est visible. Il a fallu créer un lien identifiant entre les entités insee_commune et insee_departement et reporter les informations de l’employé dans l’association ! Pas évident de parvenir à un tel modèle sans un certain savoir faire et une bonne pratique de la modélisation de données. En pratique, ce modèle conceptuel aboutira à la base de données suivante (figure 5).

Reste qu’un tel modèle possède une clef peu efficace. On trouvera donc plus juste de rajouter dans toutes les entités des clefs informatiques auto incrémentées et de transformer les clefs sémantiques en contraintes d’unicité. On bénéficiera alors du meilleur des deux mondes : concision de la clef donc performance des jointures et non redondance absolue donc moindre volume des données.

Règle n° 3 : Une entité est en troisième forme normale si elle est en deuxième forme normale et que tout attribut n’appartenant pas à une clef ne dépend pas d’un attribut non clef. Ceci pour dire qu’il faut se méfier de certaines données : elles peuvent induire une redondance, et tout particulièrement en ce qui concerne les clefs étrangères. Par exemple dans une table où le n° INSEE de personne figure en tant qu’attribut non clef, le simple fait de rajouter le sexe ou le lieu de naissance suffit à violer cette règle. Mais il y a un cas où cette règle paraît être violée et où elle ne l’est pas. C’est celui des modèles dont les données doivent être "photographiées" à un instant précis de la chronologie applicative… Autrement dit le problème de la représentation du temps dans un modèle de données.

À ce stade, deux techniques s’affrontent : le modèle synchronique et le modèle diachronique… Lequel va gagner ? Étudions encore une fois un exemple parlant, celui de la gestion des commandes de produits marchands. Le modèle que tout un chacun fait est le suivant (voire figure 6). Mais ce modèle possède un inconvénient majeur : si l’on doit changer le libellé ou le prix d’un produit, alors la réédition des commandes portant sur les produits changés génère des documents différents des originaux. D’où l’idée de dupliquer prix et libellé dans l’association "porte sur" afin de prendre un cliché, un instantané, une copie des valeurs des données des produits concernant chaque commande.

Voici donc notre modèle plus orthodoxe (figure 7). Il est appelé modèle synchronique dans le sens où l’information est piqué à l’instant de la commande. Mais ce modèle introduit une redondance néfaste au volume des données puisqu’il est probable (et souhaitable) que de nombreuses commandes portent sur les mêmes produits… De plus, il perd certaines informations ! En effet, imaginez que vous avez dans votre offre produit une savonnette fort cher et qui sent très mauvais. Il est probable qu’aucun client ne l’achète jamais. Le directeur commercial s’en rend compte et modifie le prix à la baisse. La savonnette dès lors commence à se vendre malgré sa puanteur… Comment savoir que vous avez eu un produit que vous n’avez pas vendu?

Cette information a disparu du fait du défaut de ce modèle ! Pour contrer ces problèmes, l’idée est alors de gérer une version des produits dans le temps. À chaque changement opéré sur la ligne, on conserve l’ancienne version avec une date d’obsolescence. Ceci suppose de rajouter à la clef de l’entité produit un attribut de type DATE. Cette technique dite diachronique, conduit au modèle suivant (voir figure 8). Mais véhiculer une date dans une clef n’est pas très performant. Alors, pour conserver toute sa beauté à un tel modèle, on peut utiliser une clef non sémantique, par exemple un auto incrément. Dès lors, on bénéficie du meilleur des deux mondes, mais attention à garder l’unicité du couple d’attribut référence + date version. Ce dernier modèle se schématise comme suit (voir figure 9).

Arrêtons là notre introspection des formes normales et de l’optimisation des modèles. Il y aurait encore beaucoup à dire… Intéressons nous rapidement à quelques techniques particulières. Peu d’informaticiens pensent à utiliser les techniques d’héritage des données. Pourtant cela résout bien des problèmes et permet d’économiser souvent une masse significative de données. De même pour la modélisation par méta modèles, c’est-àdire la possibilité de garder un modèle évolutif de stockage de l’information sans pour autant restructurer en permanence le schéma de la base. Enfin, sachez qu’il existe des modèles très particuliers pour résoudre très élégamment des problèmes complexes de données. Par exemple pour la modélisation des arborescences et autres hiérarchies, il existe un outil très efficace : le mode intervallaire. Mais pour ceux qui ne sont pas convaincus par l’intérêt d’un modèle parfaitement normalisé, je donnerais un seul exemple. Celui concernant la modélisation d’une personne et de ses coordonnées. Non seulement un modèle non normalisé entraîne de la redondance et donc un volume accru de données, mais il rend les requêtes les plus triviales très difficiles à écrire et donc catastrophiques en terme de performances.

Voyons cela de près. Dans le modèle pas normalisé constitué d’une seule table (voir figure 10), comment retrouver efficacement une personne qui habite rue Pasteur ou dont le numéro de téléphone est 04 11 47 28 52 ou encore qui possède l’email toto@microsoft. com ? Dans un exercice que je donne dans le cadre d’un cours d’optimisation, je pose les conditions suivantes et demande de comparer le volume des deux modèles (figures 10 et 11) : Supposons qu’il existe 500 000 clients, dont la moitié a une adresse renseignée avec une moyenne de 2 lignes par adresses (incluant code postal et ville), et qu’en moyenne on trouve 1,5 n° de téléphone par client et que 50% ont un email, 10% deux emails… Quel est le modèle le plus performant? Je terminerai par un constat.

Dans son offre logicielle Microsoft ne présente pas d’outil performant de modélisation de données. C’est dommage. Mais recourir à un outil de modélisation comme Power AMC ou Win Design est indispensable. Certes, le coût en est élevé, mais l’outil est plus pérenne que les environnements de développement et ne concerne que quelques personnes dans l’entreprise. Mais surtout je démontre à tous mes clients les gains spectaculaires que l’on obtient avec un tel outil. Et il est rare qu’il ne soit pas amorti en quelques mois!