Les bases de données relationnelles et l'interrogation des données
Fiche de préparation d'épreuve, calée sur le référentiel du BTS CG : son plan, ses exemples et son vocabulaire suivent l'épreuve. La même notion est traitée pour tous les publics dans Outils transversaux : TM 30, Les bases de données relationnelles et SQL.
- Code
- CG P7.03
- Public
- Candidats au BTS CG, processus P7
- Cours
- 18 pages, PDF
- Diaporama
- 25 diapositives, thèmes sombre et clair, PowerPoint modifiable et PDF
- Synthèse
- 2 pages, PDF
- Podcast
- Fichier audio
- Vidéo
- Fichier vidéo MP4
- Infographie
- L'essentiel de la fiche sur une image
- Avec l'achat
- Téléchargement dans votre espace client
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.
Voir ce que traite le coursCours
18 pages rédigées, en PDF.
Diaporama
25 diapositives en PowerPoint modifiable, thème sombre pour projeter et thème clair pour imprimer.
Synthèse
2 pages pour réviser l'essentiel.
Podcast
La notion expliquée à l'oral, à écouter hors de l'écran.
Vidéo
Une présentation animée de la notion, en MP4.
Infographie
L'essentiel de la fiche sur une image.
Ce que traite le cours
8 sections, 18 pages
- 1Pourquoi structurer : ce que le tableur ne sait pas faire
- 2Le modèle conceptuel de données : entités, associations, cardinalités
- 3Du modèle conceptuel au modèle relationnel : les règles de passage
- 4Les contraintes d'intégrité : la fiabilité comptable inscrite dans la structure
- 5Interroger en SQL : anatomie d'une requête et ordre d'évaluation
- 6Jointures, agrégation et regroupement : produire une information comptable
- 7Écrire dans la base : requêtes de mise à jour, droits et traçabilité
- 8Exploiter les extractions : contrôler, rapprocher, alimenter le tableau de bord
Notions, outils et auteurs
Chaque repère mène aux autres fiches qui le traitent.
Notions
Modèles et outils
Présentation de la notion
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.
La suite de cet article se lit librement sur le Mag : lire le guide complet de la notion.
Objectifs de la fiche
- Identifier les quatre défauts du tableur employé comme base de données (redondance, anomalies)
- Construire un modèle conceptuel de données : entités, attributs, identifiant, associations, cardinalités
- Appliquer les règles de passage du modèle conceptuel au schéma relationnel (clé primaire, clé étrangère, table de jonction)
- Poser des contraintes d'intégrité d'entité, référentielle et de domaine
- Écrire une requête SQL avec jointures, filtres, regroupement et agrégation en respectant l'ordre d'évaluation
- Distinguer WHERE et HAVING et utiliser LEFT JOIN + IS NULL pour détecter des absences
Questions fréquentes
Pourquoi ne pas simplement tout gérer dans un grand tableur ?
Parce qu'un tableur tolère la redondance, accepte des valeurs incohérentes et laisse les mises à jour se faire à moitié : le même client peut se retrouver avec deux adresses différentes sans que rien ne l'empêche. Une base relationnelle bien conçue interdit ce genre d'anomalie dès la saisie.
Comment savoir de quel côté poser une clé étrangère ?
La clé étrangère se pose toujours du côté de la cardinalité 1,1, c'est-à-dire du côté de l'entité qui n'en a qu'une seule des deux : une facture n'a qu'un client, donc c'est la table FACTURE qui reçoit la clé du client, jamais l'inverse.
Pourquoi ma requête avec une condition sur une somme dans le WHERE renvoie-t-elle une erreur ?
Parce que le WHERE est évalué avant le regroupement (GROUP BY) et le calcul des agrégats : au moment où le WHERE s'exécute, aucune somme n'a encore été calculée. Une condition portant sur un total, un nombre ou une moyenne doit toujours aller dans le HAVING.
Comment retrouver les factures qui n'ont reçu aucun règlement ?
En utilisant une jointure externe gauche (LEFT JOIN) entre les factures et les règlements, puis en filtrant sur IS NULL côté règlement : une jointure interne classique écarterait justement les factures les plus urgentes, celles qui n'ont aucune correspondance.