Modélisation de Données : Partir des Questions, Pas des Tables

Démarrer un nouveau projet de base de données est un moment charnière. La tentation est grande d’ouvrir son outil de modélisation et de dessiner immédiatement des tables : une table users, une table products, une table orders. C’est une approche intuitive, mais elle conduit souvent à un schéma rigide, désordonné, et peu adapté aux besoins réels. Il existe une méthode bien plus puissante : commencer par les questions. En vous concentrant d’abord sur ce que vous voulez savoir, vous construirez un modèle de données qui sert réellement votre application.

Le Piège de la « Modélisation par Tables »

Quand vous commencez par dessiner des tables, vous pensez naturellement en termes de « choses » (entités) et de « propriétés » (colonnes). Cela semble logique, mais cela vous pousse à des décisions prématurées :

• « Un utilisateur a un nom, un email, une date d’inscription. »

• « Une commande a une date, un statut, un montant total. »

Cette approche « nomme » les choses avant de comprendre leur « usage ». Vous risquez de créer des colonnes inutiles, d’oublier des relations critiques, ou de structurer vos données d’une manière qui rendra les requêtes futures complexes, lentes ou impossibles à formuler simplement.

La Méthode « Question-First » : L’Approche Centrée Utilisateur

Le principe est simple : avant de dessiner la première table, écrivez la liste exhaustive des questions que votre application devra pouvoir poser à la base de données. Ces questions doivent être concrètes, dans le langage du métier, et couvrir tous les cas d’usage.

Exemple pour une plateforme de cours en ligne :

1. « Qui sont les apprenants inscrits au cours « Python Débutant » ? »

2. « Quel est le nombre total de leçons visionnées par l’apprenant « Marie » ce mois-ci ? »

3. « Quels sont les 5 cours les plus populaires cette semaine ? »

4. « Quel instructeur a généré le plus de revenus au dernier trimestre ? »

5. « Quelle est la progression moyenne (pourcentage de leçons terminées) dans le cours « Data Analysis » ? »

Ces questions ne sont pas des requêtes SQL. Ce sont les besoins métier. Elles deviennent votre cahier des charges fonctionnel pour le modèle de données. Pour explorer ce sujet, cliquez ici.

Étape 1 : Dériver les Entités et Relations des Questions

Une fois vos questions listées, analysez-les. Les noms et les verbes vous donnent les entités et les relations.

• Les Noms (Sujets/Objets) deviennent des Entités :

  • « apprenants », « Marie » → Entité learners.

  • « cours », « Python Débutant » → Entité courses.

  • « leçons », « leçon » → Entité lessons.

  • « instructeur » → Entité instructors.

  • « revenus », « progression » → Ce sont des faits ou des mesures, souvent le résultat d’un calcul ou une colonne dans une table de fait.

• Les Verbes et Prépositions deviennent des Relations :

  • « inscrits au cours » → Relation learners <–>> courses (Many-to-Many). Cela nécessite une table de jointure enrollments.

  • « leçons visionnées par l’apprenant » → Relation learners <–>> lessons. Nouvelle table de fait : lesson_views ou progress.

  • « cours de l’instructeur » → Relation instructors <<–> courses (One-to-Many).

  • « revenus générés par l’instructeur » → Relation indirecte via les cours et les inscriptions/paiements.

Résultat : Vous avez maintenant une liste d’entités (learners, courses, lessons, instructors) et de tables de relation/faits (enrollments, lesson_views) qui sont directement justifiées par un besoin métier. Rien n’est là « au cas où ».

Étape 2 : Définir les Attributs (Colonnes) à Partir des Questions

Maintenant, pour chaque entité ou table de fait, déterminez les attributs nécessaires pour répondre aux questions. Ne devinez pas. Regardez les questions.

• Pour la question 1 (« Qui sont les apprenants inscrits… ? ») : La table learners a besoin au minimum d’un id et d’un name.

• Pour la question 2 (« nombre total de leçons visionnées… ce mois-ci ») : La table lesson_views a besoin d’un learner_id, d’un lesson_id, et crucialement, d’un viewed_at (timestamp) pour filtrer par mois.

• Pour la question 3 (« cours les plus populaires cette semaine ») : Il faut pouvoir lier une vue (lesson_views) à un cours (courses), donc la table lessons a besoin d’un course_id. La popularité est une agrégation des vues de leçons, pas une colonne stockée.

Cette étaze révèle les dates (enrolled_at, viewed_at, created_at), les clés étrangères et les types de données (un montant est un decimal, pas un integer). Vous ajoutez exactement ce qui est nécessaire.

Étape 3 : Valider le Modèle en « Traduisant » les Questions en SQL (Mentalement)

C’est l’épreuve du feu. Essayez de reformuler mentalement chaque question en une requête SQL sur votre modèle naissant. Si c’est simple et évident, vous êtes sur la bonne voie. Si vous devez faire des jointures à 5 tables tordues ou des calculs complexes sur des colonnes mal nommées, c’est un signe qu’il faut réviser.

Question 1 : SELECT l.name FROM learners l JOIN enrollments e ON l.id = e.learner_id JOIN courses c ON e.course_id = c.id WHERE c.title = 'Python Débutant'; → Simple.
Question 3 : SELECT c.title, COUNT(lv.id) as view_count FROM courses c JOIN lessons le ON c.id = le.course_id JOIN lesson_views lv ON le.id = lv.lesson_id WHERE lv.viewed_at >= NOW() - INTERVAL '7 days' GROUP BY c.id ORDER BY view_count DESC LIMIT 5; → Logique, mais révèle le besoin de l’indexation sur viewed_at.

Les Bénéfices Concrets de Cette Approche

1. Un Schéma Lisible et Justifié : Chaque table et chaque colonne a une raison d’être documentée (la question originale). Cela facilite grandement l’onboarding de nouveaux développeurs.

2. De Meilleures Performances : En comprenant dès le départ les chemins d’accès aux données (les questions), vous pouvez indexer stratégiquement dès la création (ex: (learner_id, viewed_at) sur lesson_views).

3. Moins de Refactoring : Vous anticipez les besoins de requêtes complexes, évitant de restructurer la base en production.

4. Une Communication Métier/Développeur Clarifiée : Travailler sur une liste de questions comprises par tous (product owner, développeur, analyste) aligne les équipes et réduit les malentendus.

La Checklist du Modélisateur « Question-First »

Avant de créer votre première table, ayez :

• Une liste exhaustive de 10 à 20 questions métier.

• Les entités claires extraites des noms.

• Les relations claires extraites des verbes.

• Les attributs nécessaires pour répondre aux questions.

• Une validation par tentative de « traduction SQL mentale ».

La Donnée au Service de l’Intention

Un bon modèle de données n’est pas une collection statique de tables. C’est un système de réponses. En partant des questions que votre business a besoin de poser, vous construisez un schéma qui est, par conception, utile, efficace et évolutif.

La prochaine fois que vous ouvrirez pgModeler ou MySQL Workbench, résistez à l’envie de dessiner. Prenez un bloc-notes, rassemblez votre équipe, et posez la seule question qui compte : « Qu’avons-nous besoin de savoir ? ». Les tables, elles, viendront toutes seules, et elles seront parfaitement adaptées à leur seul vrai travail : fournir des réponses.