Modéliser la donnée

Un modèle est une décision, pas un détail technique

Les trois premiers chapitres ont posé le cadre : qui gouverne, avec quels référentiels, sous quelles obligations légales. Ce chapitre descend dans la structure elle-même : comment traduire un besoin métier en base de données. Un point mérite d’être posé d’emblée : un modèle de données n’est pas un choix technique secondaire laissé à la discrétion de qui écrit le code. C’est une décision qui engage la façon dont l’organisation pourra, ou non, répondre à ses futures questions métier, et qui coûte d’autant plus cher à corriger qu’elle a été prise tôt, sans recul.

Le modèle conceptuel : décrire le métier, pas la base

La démarche française de référence pour cette première étape, Merise, propose de construire d’abord un modèle conceptuel de données (MCD), sans se préoccuper encore de la technologie qui l’hébergera. Le monde UML propose un exercice équivalent avec le diagramme de classes. Trois notions suffisent à en poser les bases.

Une entité représente un objet ou un concept du métier dont on veut conserver des occurrences distinctes : un client, une commande, un produit. Une association relie deux entités pour représenter un fait métier : un client passe une commande. Une cardinalité précise, pour chaque sens de cette association, combien d’occurrences peuvent être liées : un client peut passer zéro, une ou plusieurs commandes (cardinalité 0,n), une commande appartient à un seul client (cardinalité 1,1). C’est elle qui décidera, plus tard, où se pose une clé étrangère, ou si une table intermédiaire devient nécessaire.

L’erreur la plus fréquente à ce stade n’est pas technique, elle est méthodologique : dessiner des tables avant d’avoir listé les entités et validé les cardinalités avec les personnes qui connaissent le métier. Un designer qui trace un plan avant de connaître les usages du bâtiment prend le même risque : un résultat élégant, mais inadapté.

Le modèle logique : passer au relationnel

Le modèle conceptuel validé, l’étape suivante le traduit en un modèle logique de données (MLD), qui anticipe cette fois un moteur relationnel : chaque entité devient une table, chaque association 1,n devient généralement une clé étrangère, chaque association n,n nécessite une table de jointure propre. C’est à ce stade qu’intervient la normalisation, un ensemble de règles qui organisent les colonnes d’une table pour limiter la redondance et les incohérences qu’elle produit.

La première forme normale (1FN) impose des valeurs atomiques : pas de liste de numéros de téléphone dans une seule colonne, mais une ligne par numéro dans une table associée. La deuxième forme normale (2FN) élimine les dépendances qui ne portent que sur un fragment d’une clé composée : un champ qui ne dépend que d’une partie de la clé primaire doit rejoindre une autre table. La troisième forme normale (3FN) élimine les dépendances transitives : si le code postal détermine la ville, la ville ne devrait pas être stockée directement à côté de l’adresse, elle devrait provenir d’une table de référence des codes postaux.

Normaliser jusqu’à la 3FN n’est cependant pas une fin en soi. Une dénormalisation raisonnée, réintroduire volontairement une redondance pour éviter une jointure coûteuse sur un chemin de lecture critique, reste une décision d’architecture légitime, à condition d’être documentée et mesurée, pas subie faute d’avoir compris la normalisation en premier lieu.

Le modèle physique : le SQL comme langage de vérité

Le modèle physique de données (MPD) traduit le modèle logique dans le vocabulaire exact du système de gestion de base de données choisi : types de colonnes, index, contraintes. Le type d’une colonne n’est jamais un détail : stocker une date dans une colonne texte interdit tout tri chronologique fiable et toute validation automatique du format. L’index accélère la recherche sur une colonne fréquemment interrogée, au prix d’un espace disque supplémentaire et d’un ralentissement des écritures : un choix d’équilibre, pas un réflexe à appliquer partout. Les contraintes, clé primaire, clé étrangère, unicité, valeur non nulle, portent la règle de gestion directement dans la base, ce qui la rend impossible à contourner, y compris par un script mal écrit.

C’est là que le SQL de création (DDL, Data Definition Language) devient ce qu’on peut appeler le langage de vérité du projet : au-delà des schémas et des présentations, c’est le script de création des tables qui décrit, sans ambiguïté possible, ce que la base accepte réellement.

Ce qu’un modèle bricolé coûte réellement

Un modèle mal pensé ne se voit pas tout de suite : les premières semaines, tout fonctionne. Le coût apparaît plus tard, sous forme de requêtes de plus en plus lentes à mesure que le volume grandit, de correctifs applicatifs qui compensent une contrainte que la base aurait dû porter elle-même, et de migrations de plus en plus risquées à mesure que les dépendances non documentées s’accumulent. Un modèle propre ne coûte pas plus cher à concevoir : il coûte simplement plus de rigueur en amont, et beaucoup moins cher à faire évoluer ensuite.

Ce chapitre s’est concentré sur le relationnel, parce qu’il reste le paradigme par défaut pour la majorité des systèmes de gestion. Il ne l’est pas pour tous les usages : le chapitre suivant explore les familles NoSQL et la modélisation orientée décision, deux territoires où les règles de ce chapitre ne s’appliquent plus de la même façon.