Un tableur additionne ce qu'on lui donne ; une base de données relationnelle refuse ce qui n'a pas de sens. Cette fiche apprend à lire un modèle de données, poser une clé étrangère et écrire une requête SQL juste — pour cesser de subir les données de l'entreprise et commencer à les interroger.
Pourquoi structurer plutôt qu'accumuler dans un tableur
Un tableur employé comme base de données cumule quatre défauts : redondance de l'information, anomalies de mise à jour, impossibilité d'insérer ou de supprimer proprement, rapprochements fragiles fondés sur des recherches verticales en cascade. Le modèle relationnel y répond par un principe unique : chaque information n'est stockée qu'une seule fois, à un seul endroit, et les rapprochements se font par des clés.
Du modèle conceptuel au schéma relationnel
La méthode Merise fournit le vocabulaire : entités, attributs, identifiant, associations et cardinalités (0,1 · 1,1 · 0,n · 1,n), qui se traduisent ensuite par des règles mécaniques — toute entité devient une table, toute association 1,1 devient une clé étrangère, toute association n,n devient une table de jonction. Les contraintes d'intégrité (d'entité, référentielle, de domaine) rendent alors impossible ce qu'un contrôle humain ne ferait que constater a posteriori.
Interroger en SQL : l'ordre qui change tout
Une requête SELECT s'écrit dans un ordre — SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY — mais s'évalue dans un autre : c'est de cet écart que naît le piège le plus fréquent, vouloir filtrer une somme dans le WHERE plutôt que dans le HAVING. Maîtriser les jointures — notamment le couple LEFT JOIN et IS NULL pour détecter les absences — permet de produire la balance âgée, le chiffre d'affaires par client ou les écarts entre en-tête et lignes d'une facture : des contrôles qu'aucun état standard ne propose.