Quand on modélise une base de données avec la méthode MERISE, le passage du MCD au MLD concentre la plupart des erreurs structurelles. Un oubli de normalisation à ce stade, et ce sont des anomalies d’insertion, de suppression ou de mise à jour qui se propagent en production. Adopter les bons réflexes lors de la normalisation des données évite de devoir restructurer un schéma entier après coup.
Normalisation MCD/MLD : pourquoi le problème se joue avant la première table
La normalisation n’est pas une étape qu’on applique mécaniquement après avoir dessiné un schéma. Elle commence dès la collecte des données, au moment où l’on identifie les entités et leurs attributs dans le MCD.
A lire en complément : Évitez le logiciel propriétaire Microsoft PowerPoint : des solutions libres à adopter
Vous avez déjà vu un MCD où une entité « Client » contenait à la fois le nom, l’adresse, le code postal, la ville et le pays dans un seul bloc ? Ce réflexe de tout regrouper crée des dépendances transitives dès le modèle conceptuel. Le code postal détermine la ville, qui détermine le pays. Aucun de ces attributs ne dépend directement de l’identifiant du client.
Corriger ce type de défaut au niveau du MCD (en isolant une entité « Adresse » ou « Localité ») coûte quelques minutes. Le corriger après la génération du MLD, avec des clés étrangères déjà en place et des requêtes écrites, prend des heures.
A lire en complément : Comment se connecter à Arkevia ?
Dépendances fonctionnelles : le test à appliquer à chaque attribut
Avant de valider un MCD, chaque attribut mérite une question simple : de quel identifiant dépend-il directement, et de rien d’autre ?
C’est le principe de la dépendance fonctionnelle directe. Un attribut A dépend fonctionnellement d’un identifiant B si, pour chaque valeur de B, il existe une seule valeur possible de A. Si A dépend de B, mais aussi d’un autre attribut C qui dépend lui-même de B, on a une dépendance transitive. C’est précisément ce que la troisième forme normale (3NF) cherche à éliminer.
Prenons un exemple concret. Dans une entité « Commande », on trouve parfois : numéro de commande, date, référence produit, libellé produit, prix unitaire. Le libellé et le prix dépendent de la référence produit, pas du numéro de commande. Ces attributs n’ont rien à faire dans l’entité Commande. Ils appartiennent à une entité « Produit » reliée par une association.
Les trois formes normales à vérifier systématiquement
- Première forme normale (1NF) : chaque attribut contient une valeur atomique, pas de liste ni de groupe répétitif. Un champ « téléphones » contenant plusieurs numéros séparés par des virgules viole la 1NF.
- Deuxième forme normale (2NF) : tous les attributs non-clé dépendent de la totalité de la clé primaire, pas d’une partie seulement. Ce problème apparaît surtout avec les clés composées dans les associations.
- Troisième forme normale (3NF) : aucun attribut non-clé ne dépend d’un autre attribut non-clé. C’est le piège de la dépendance transitive décrit plus haut.
Appliquer ces trois vérifications de façon méthodique sur le MCD, avant toute transformation en MLD, supprime la majorité des anomalies de mise à jour.
Transformation MCD vers MLD : les pièges sur les associations
La conversion du MCD en MLD suit des règles de transformation connues, mais deux cas génèrent régulièrement des erreurs de normalisation.
Associations avec attributs et cardinalités mixtes
Une association porteuse d’attributs entre deux entités avec des cardinalités (1,n) des deux côtés se transforme en table intermédiaire. La clé primaire de cette table est composée des clés étrangères vers les deux entités parentes.
Le réflexe à adopter : vérifier que chaque attribut de l’association dépend bien de la clé composée complète. Si un attribut ne dépend que d’une des deux clés étrangères, il doit migrer vers la table de l’entité correspondante. Sinon, la 2NF est violée.
Associations de type (1,1) et fusion d’entités
Quand une association porte une cardinalité (1,1) d’un côté, l’entité concernée absorbe la clé étrangère de l’entité opposée lors du passage au MLD. Pas besoin de table intermédiaire.
Le piège : fusionner les attributs des deux entités dans une seule table sans vérifier les dépendances fonctionnelles. Si l’entité absorbée avait des attributs qui dépendent uniquement de sa propre clé, la fusion crée une dénormalisation silencieuse.
Normalisation et traçabilité des données : un enjeu réglementaire croissant
Le règlement européen sur l’intelligence artificielle (AI Act), adopté en 2024, introduit des obligations sur la qualité et la traçabilité des données utilisées par les systèmes d’IA. Pour les bases de données qui alimentent ces systèmes, cela se traduit par des contraintes directes sur la modélisation.
Trois exigences impactent la normalisation MCD/MLD :
- La documentation de la provenance des données et des transformations appliquées, ce qui suppose des entités et attributs dédiés dans le modèle.
- Le renforcement de la minimisation des données et la séparation fonctionnelle des usages, un principe qui rejoint la logique de décomposition de la 3NF.
- La transparence des logiques de traitement, y compris au niveau des schémas de données eux-mêmes.
Un MCD bien normalisé facilite naturellement cette traçabilité. Chaque entité a un périmètre clair, chaque attribut une provenance identifiable. Un MCD dénormalisé, avec des attributs mélangés entre entités, rend cette documentation difficile à maintenir.
Outils de vérification MCD/MLD : ce que JMerise permet (et ce qu’il ne fait pas)
JMerise est un outil gratuit de modélisation MERISE qui permet de dessiner un MCD et de générer automatiquement le MLD correspondant. La transformation applique les règles standard de passage (gestion des cardinalités, création des tables intermédiaires, migration des clés étrangères).
Ce que JMerise automatise bien : la structure relationnelle de base. Ce qu’il ne vérifie pas : les dépendances fonctionnelles entre attributs. L’outil ne signale pas qu’un attribut dépend transitivement d’un autre, ni qu’une clé composée est partiellement redondante.
Le réflexe pratique consiste à utiliser JMerise pour la transformation mécanique, puis à relire chaque table du MLD en appliquant manuellement le test des trois formes normales. La normalisation reste un travail d’analyse humaine, pas de génération automatique.
Un MCD proprement normalisé produit un MLD qui ne nécessite presque aucune retouche. Quand le passage au MLD génère des tables avec des dizaines d’attributs ou des clés composées de trois colonnes ou plus, c’est généralement le signe que le MCD d’origine contenait des dépendances non résolues. Revenir au modèle conceptuel pour corriger la source du problème reste toujours plus efficace que de patcher le modèle logique.
