De l'Objectif Fonctionnel à la Modélisation Transactionnelle

Contexte et déclic : qu’est-ce qu’une bonne modélisation ?

Pendant très longtemps, j’ai cru comprendre la modélisation. Pendant mes études, j’étudiais la théorie : les architectures monolithiques vs distribuées, le rôle d’un SGBD, les propriétés ACID, etc. Cependant, la pratique restait un concept flou.

Le véritable déclic a eu lieu lors de mon alternance chez Maeba Consulting. Je travaillais sur la maintenance évolutive d’une application de gestion administrative et nous étions confrontés à des blocages permanents côté backend. On n’arrivait pas à progresser, et j’ai réalisé que le problème n’était pas le code, mais la modélisation de base qui ne permettait plus au business de grandir.

La modélisation est la traduction des besoins fonctionnels en schéma, et si ce schéma est rigide, le projet meurt.

Pour vous expliquer ma méthode, je vais prendre le cas d’une activité simple : la gestion d’une pharmacie.

Point de départ : l’analogie de la ligne unique

À la base, il faut comprendre que la création même des bases de données relationnelles avait pour but de résoudre les problèmes liés aux fichiers plats (comme les tableaux Excel par exemple).

Donc, mon analogie pour bien commencer une modélisation est la suivante : quand quelqu’un vient avec un besoin fonctionnel, partez du principe que toute l’information est linéaire, enregistrée sur une seule ligne. Cela vous donne une base de départ solide pour entamer le processus.

Dans la réalité, la majorité des business commencent vraiment sur des tableaux Excel. Si c’est le cas, ce fichier vous donne déjà une base concrète pour comprendre le fonctionnement initial du business.

Par la suite, je vais m’appuyer sur les étapes de normalisation pour structurer cette information de manière optimale. Pour celles et ceux qui ne sont pas familiers avec les concepts de normalisation, il s’agit d’un processus méthodique qui vise à organiser les données dans une base relationnelle pour réduire la redondance et améliorer l’intégrité des données. Elle se fait en plusieurs étapes, appelées formes normales (1NF, 2NF, 3NF, etc.), chacune ayant des règles spécifiques.

Voici notre table de départ (notre base linéaire) :

Table : Ventes_Brutes

Étape 1 : la Première Forme Normale (1NF) - l’atomicité et l’identifiant

La 1NF est souvent l’étape la plus longue car elle demande de casser toutes les structures complexes pour atteindre l’élément le plus fin possible.

1.1 Éclatement des données composées

On commence par séparer ce qui peut l’être. “Simon Bay” devient un prénom et un nom. L’adresse est découpée en rue, code postal, ville et pays.

1.2 Le problème des groupes répétitifs (anti-pattern)

Pour les fournisseurs, on pourrait être tenté de faire ceci :

La 1NF interdit formellement les groupes répétitifs du même type. On ne peut pas “numéroter” des colonnes pour contourner le problème. Il faut faire en sorte que chaque cellule ne contienne qu’une seule information. Dans notre cas, nous allons devoir dupliquer la ligne pour chaque fournisseur.

1.3 Mise en conformité 1NF et clé primaire

On duplique les lignes pour que chaque cellule soit parfaitement atomique (une seule valeur). Pour terminer la 1NF, on ajoute un identifiant unique (clé primaire) car rien ne permet d’identifier naturellement une ligne dans ce tableau.

Table : Ventes_1NF

(Suite de la table Ventes_1NF)

Étape 2 : la Deuxième Forme Normale (2NF) - séparation des entités

Pour passer en 2NF, il y a une condition stricte : la table doit d’abord être en 1NF. Ensuite, il y a une règle logique très simple : une table ne doit stocker des informations que sur un seul sujet précis. Il faut se poser la question : est-ce que cette colonne dépend fonctionnellement du sujet principal de la table ?

Par exemple, dans notre grande table de départ, l’adresse, le prénom et le nom du client dépendent du Client, mais elle ne dépend absolument pas de la Vente. De même, le prix du médicament dépend du Médicament.

Action : On sépare donc les grands sujets (les entités) dans leurs propres tables (Client, Médicament, Fournisseur) pour éliminer la redondance. C’est à cette étape que l’on commence à relier les tables entre elles en introduisant les Clés Étrangères (FK).

Table : Client

Table : Medicament

Table : Fournisseur

Gestion des relations :

• Un médicament peut avoir plusieurs fournisseurs (N), et un fournisseur peut proposer plusieurs médicaments (N). C’est une relation many-to-many. On crée donc une table de liaison pour le stock.
• Un client peut acheter plusieurs médicaments lors d’une même vente, et un médicament peut être acheté par plusieurs clients. On crée donc une table pour la Transaction.

Table : Liaison_Stock (Relation N:N)

La DateVente dépend du sujet “Vente” (l’acte, la transaction ou l’événement).

Voici comment le déduire en se posant la fameuse question est-ce que cette colonne dépend fonctionnellement du sujet ? :

• Est-ce qu’elle dépend du Client ? Non. Le client (ex : Simon Bay) existe indépendamment de cette date. Il pourrait très bien faire un achat aujourd’hui, puis un autre la semaine prochaine. La date ne le définit pas en tant que personne.
• Est-ce qu’elle dépend du Médicament ? Non. Le Paracétamol existe dans le catalogue de la pharmacie tous les jours, peu importe quand il est vendu.
• Est-ce qu’elle dépend du Fournisseur ? Non plus.
• La date est une caractéristique unique de l’action d’acheter. Elle définit quand la rencontre entre le client et le médicament a eu lieu.

C’est exactement pour cette raison que, dans notre schéma final, l’attribut date_heure (ou date_vente) est placé dans la table de transaction VENTE et dépend de la clé primaire id_vente.

Table : Vente (Lien entre l’acte, le client et le produit)

Étape 3 : la Troisième Forme Normale (3NF) - dépendances transitives

Objectif : être en 2NF et éliminer les dépendances transitives. Une dépendance transitive survient lorsqu’un attribut dépend d’un autre attribut qui n’est pas la clé primaire.

Le problème : dans notre table Client, la Ville et le Pays dépendent en réalité du Code Postal (CP), et non directement de l’identifiant du client. C’est une dépendance indirecte.

La solution : on crée une table de référence géographique. Cela évite les erreurs de saisie (comme écrire “Pariss” au lieu de “Paris”) et garantit que chaque colonne ne dépend que de sa propre clé primaire.

Le compromis (Storage vs Retrieval) : pour des bases de données plus grandes, la table LOCALITE pourrait être encore découpée (par exemple, séparer les Villes et les États/Pays). Cependant, il faut garder à l’esprit un principe fondamental d’architecture : plus on normalise, plus on gagne en efficacité de stockage (storing efficiency), mais plus il faudra exécuter de jointures (JOIN) pour reconnecter et lire la donnée, ce qui réduit l’efficacité de récupération (retrieving efficiency).

Structure finale (Le Schéma Logique)

En ajoutant quelques champs nécessaires à la réalité physique d’une application (comme la quantité pour une vente ou les contacts), voici à quoi ressemble notre modèle final, parfaitement normalisé :

Table : LOCALITE
(code_postal, ville, pays)

Table : CLIENT
(id_client, nom, prenom, email, tel, num_rue, nom_rue, #code_postal)

Table : MEDICAMENT
(id_medic, nom, prix_base)

Table : FOURNISSEUR
(id_fournisseur, nom_societe)

Table : STOCK_FOURNISSEUR
(#id_medic, #id_fournisseur)

Table : VENTE
(id_vente, #id_client, #id_medic, quantite, date_heure)

De la Modélisation à la Conception Physique

Une fois ce schéma logique validé en 3NF, on quitte le papier pour passer à l’implémentation physique dans le moteur SQL. Créer les tables physiques demande de maîtriser les types et les contraintes pour garantir la qualité de la donnée en fonction du type de base de données utilisée (MySQL, PostgreSQL, SQL Server, etc.).

1. Précision financière vs performance

Pour le champ Prix dans la table Medicament, j’exclus systématiquement les types FLOAT ou REAL. Ce sont des types à virgule flottante approximatifs qui entraînent des erreurs d’arrondi redoutables lors des calculs de bilans financiers.

• Type utilisé : DECIMAL(10,2) ou NUMERIC. Cela garantit une précision mathématique exacte à deux chiffres après la virgule.

2. Optimisation du stockage des chaînes de caractères

Pour les noms et adresses, j’utilise VARCHAR(n) (ex: VARCHAR(255)) plutôt que le type générique TEXT.

• Pourquoi ? Contrairement à une idée reçue, VARCHAR n’alloue que l’espace réellement utilisé. Surtout, cela permet au moteur SQL de mieux optimiser la mémoire en limitant la taille maximale, ce qui est crucial pour la création d’index performants.

3. Les clés et l’intégrité référentielle

Pour garantir que le chaos du “Gros Tableau Excel” ne revienne jamais hanter le système, je configure des contraintes d’intégrité strictes au moment de la création des tables (CREATE TABLE) :

• ON DELETE RESTRICT : Sécurité absolue. Cela empêche un utilisateur de supprimer un médicament du catalogue s’il existe encore des historiques de ventes liées à ce produit dans la base.
• CHECK constraints : Je force la logique métier directement en base de données. Par exemple, j’ajoute CHECK (prix > 0) pour m’assurer qu’une erreur de saisie ne puisse jamais enregistrer un prix négatif.

Pour aller plus loin : modélisation vs Database Design

Il est important de prendre un peu de recul : ce que nous venons de voir ici se concentre uniquement sur la modélisation d’une base de données (le passage du besoin fonctionnel à la structure logique et physique initiale).

Cependant, le Database Design (la conception globale d’une base de données) va bien au-delà de la simple création de tables. Il englobe un ensemble de pratiques et de défis d’ingénierie, notamment lorsqu’il s’agit de :

• Déployer l’architecture en production de manière sécurisée.
• Administrer la base au quotidien (gestion des politiques de sauvegarde/restauration, monitoring des performances et contrôle granulaire des accès utilisateurs).
• Optimiser les performances (stratégies d’indexation avancées, partitionnement des données).
• Gérer l’intégrité et la cohérence des données à grande échelle sous forte charge (gestion des transactions concurrentes).
• Anticiper la duplication et la haute disponibilité (réplication, sharding, clustering).

Au final, il n’y a pas d’architecture universelle. Tous ces choix techniques d’administration et d’optimisation dépendent toujours de deux facteurs majeurs : le type d’application (fort en lecture ou fort en écriture ?) et l’échelle de la base (la volumétrie des données et le nombre d’utilisateurs simultanés).

Bilan et perspectives : le pont entre Software et Data Engineering

C’est en appliquant rigoureusement ces principes au quotidien que j’ai réussi à devenir un bien meilleur développeur logiciel. Bien que la modélisation ne soit qu’une infime partie de ce qu’un ingénieur fait au quotidien, c’est une étape fondamentale. Sans une base solide, l’application s’effondre.

Mettre cette méthodologie sur papier m’a permis de démocratiser le concept et, avec mon évolution vers l’ingénierie des données, cela prend tout son sens. Comprendre intimement ces mécanismes me permet de mieux appréhender les sources de données relationnelles (OLTP).

En ingénierie des données, on a souvent tendance à se focaliser uniquement sur la modélisation décisionnelle (Data Warehouse, schémas en étoile, analytique). On en oublie presque la modélisation transactionnelle. Pourtant, c’est primordial. Le transactionnel est le point d’origine de l’information. En maîtrisant la façon dont les tables relationnelles sont conçues, typées et contraintes, j’ai beaucoup plus de contrôle et d’influence sur la qualité de la donnée en amont, avant même qu’elle n’entre dans mes pipelines de données.

Important : la normalisation d’une base de données ne se limite pas à la 3NF. Il existe des formes normales plus avancées (BCNF, 4NF, 5NF) qui traitent de cas très spécifiques. De plus, la modélisation fait appel à d’autres concepts architecturaux comme l’héritage, qui intervient généralement à la fin de la normalisation pour éviter davantage de doublons et garantir l’unicité (un concept que j’ai pu approfondir dans mon projet sur la Modélisation Transactionnelle Hospitalière).

Cependant, pour la majorité des applications transactionnelles, atteindre la 3NF est largement suffisant pour garantir une bonne structure de données. Enfin, je tiens à souligner que la modélisation est un processus itératif : il est tout à fait normal de revenir en arrière et d’ajuster le schéma au fur et à mesure que les besoins métier évoluent ou que de nouvelles contraintes apparaissent.

Ressources

• Cours : Base de données relationnelles
• Les types de formes normales : 1NF, 2NF, 3NF, etc.
• Concepts clés : Comprendre les propriétés ACID

Récapitulatif de ce que j’ai appris

• Modélisation progressive : De la ligne unique à la 3NF, une approche méthodique pour structurer les données.
• Conception physique : Importance de choisir les types de données et les contraintes pour garantir la qualité et la performance.
• Pont entre Software et Data : La modélisation transactionnelle est la base de toute architecture de données solide, essentielle pour un Data Engineer qui souhaite maîtriser la qualité de la donnée dès sa création.