Chapitre Bases de données

Du tableur au modèle relationnel

Pourquoi un tableau unique ne suffit pas pour gérer des données, et comment le modèle relationnel résout le problème — de la conception (MCD) au schéma de tables (MLD).

Durée · 2h Séance · 1 / 7 Support · à garder pour réviser

Au programme

Objectifs de la séance

Comprendre pourquoi un simple tableur pose problème pour gérer des données volumineuses.
Découvrir le vocabulaire du modèle conceptuel de données (MCD) : entité, attribut, association, cardinalité.
Découvrir le vocabulaire du modèle relationnel : relation, attribut, domaine, clé primaire, clé étrangère.
Savoir passer d'un MCD à un schéma relationnel (MLD).

Activité 1

Une billetterie mal organisée

Une petite salle de concert enregistre toutes ses ventes de billets dans un unique tableau. Regarde-le attentivement avant de répondre aux questions.

N° billet	Concert	Date	Salle	Ville	Artiste	Genre	Prix	Spectateur	Email
1	Nuit Électro	12/09/2026	Zénith	Lyon	DJ Solstice	Électro	45€	Léa Martin	lea.martin@mail.fr
2	Nuit Électro	12/09/2026	Zénith	Lyon	DJ Solstice	Électro	45€	Noah Petit	noah.petit@mail.fr
3	Rock en Seine	20/09/2026	Stade des Lumières	Lyon	Les Foudres	Rock	38€	Léa Martin	lea.martin@mail.fr
4	Nuit Électro	12/09/2026	Zénith	Lyon	DJ Solstice	Électro	45€	Inès Dubois	ines.dubois@mail.fr
5	Jazz sous les étoiles	25/09/2026	Le Trianon	Paris	Miles & Co	Jazz	30€	Noah Petit	noah.petit@mail.fr
6	Rock en Seine	20/09/2026	Stade des Lumières	Lyon	Les Foudres	Rock	38€	Inès Dubois	ines.dubois@mail.fr

1. Quelles informations sont répétées plusieurs fois ? Pourquoi est-ce un problème ?

Le nom du concert, la date, la salle, la ville, l'artiste, le genre et le prix sont répétés à chaque billet vendu pour le même concert. De même, le nom et l'email d'un spectateur qui achète plusieurs billets. C'est un problème car cela gaspille de l'espace, et surtout crée un risque d'incohérence si une même information est saisie différemment sur deux lignes.

2. La salle « Zénith » déménage et change d'adresse. Que doit-on faire ? Quel risque cela fait-il courir ?

Il faut modifier la ville/salle sur toutes les lignes concernées (ici 4 lignes). Le risque est d'en oublier une, ce qui créerait une incohérence entre les données : c'est l'anomalie de mise à jour.

3. On veut enregistrer un nouveau concert sans billet vendu. Est-ce possible ?

Non : sans billet vendu, il n'existe aucune ligne pour enregistrer les informations du concert. C'est l'anomalie d'insertion.

4. Si on supprime la ligne du billet n°5, que perd-on d'autre que ce billet ?

On perd toutes les informations sur le concert « Jazz sous les étoiles » (date, salle, artiste...), puisque c'était le seul billet vendu pour ce concert. C'est l'anomalie de suppression.

À retenir : ces trois problèmes viennent de la redondance des données : une même information est répétée sur plusieurs lignes au lieu d'être stockée une seule fois.

Vocabulaire

Trois anomalies liées à la redondance

Mise à jour

Une information répétée doit être modifiée partout où elle apparaît. Un oubli crée une incohérence.

Insertion

Impossible d'enregistrer une nouvelle donnée tant qu'elle n'est reliée à rien d'autre dans le tableau.

Suppression

Supprimer une ligne peut faire disparaître une information qu'on voulait pourtant conserver.

Cours

Le modèle conceptuel de données (MCD)

Avant de stocker les données, on modélise le réel avec un vocabulaire précis.

Entité

Objet ou concept du monde réel que l'on souhaite décrire.

ex. CONCERT, ARTISTE

Attribut

Caractéristique ou propriété d'une entité.

ex. nom_concert, date

Identifiant

Attribut (ou groupe d'attributs) qui distingue sans ambiguïté chaque occurrence d'une entité.

ex. id_concert

Association

Lien entre deux entités ou plus.

ex. SE_PRODUIT entre ARTISTE et CONCERT

Cardinalité

Nombre minimal et maximal de fois qu'une occurrence d'une entité participe à une association.

ex. (1,n)

En pratique

Association et cardinalités

Un artiste produit 1 à n concerts ; un concert a exactement un artiste principal.

0,1

0 ou 1 fois

1,1

Exactement 1 fois

0,n

0 à n fois

1,n

1 à n fois

Exercice 2 — guidé

La médiathèque

Une médiathèque gère des adhérents qui empruntent des documents (livres, CD, DVD). Chaque adhérent a un numéro, un nom et une adresse. Chaque document a une référence, un titre et un type. Un emprunt est caractérisé par une date de début et une date de retour prévue. Un adhérent peut emprunter plusieurs documents ; un document peut être emprunté par plusieurs adhérents (à des dates différentes).

Identifie les entités, l'association et les cardinalités

Entités : ADHÉRENT (num_adhérent, nom, adresse) et DOCUMENT (référence, titre, type).
Association : EMPRUNTE (date_début, date_retour_prévue) entre ADHÉRENT et DOCUMENT.
Cardinalités : ADHÉRENT (0,n) — EMPRUNTE — (0,n) DOCUMENT.

Cours

Du modèle conceptuel au schéma relationnel

Relation (table)

Ensemble structuré de données organisées en lignes et colonnes.

Domaine

Ensemble des valeurs possibles pour un attribut.

Clé primaire

Attribut(s) identifiant un n-uplet (une ligne) de façon unique. Notée soulignée.

Clé étrangère

Attribut faisant référence à la clé primaire d'une autre relation. Notée #préfixée.

Méthode

Règles de passage MCD → MLD

Chaque entité devient une relation ; son identifiant devient la clé primaire.
Pour une association 1,n / 1,1 : la clé primaire du côté « 1 » migre en clé étrangère dans la relation du côté « n ».
Pour une association n,n : elle devient une relation à part entière, dont la clé primaire est la concaténation des clés primaires des deux entités, complétée par ses propres attributs.

Exercice 3 — corrigé

Le schéma relationnel de la billetterie

Ce schéma est le fil rouge du chapitre : il sera repris tel quel pour créer la base en SQL dès la séance 3.

CONCERT

id_concert, nom_concert, date_concert, #id_artiste, #id_salle

ARTISTE

id_artiste, nom_artiste, genre

SALLE

id_salle, nom_salle, ville

SPECTATEUR

id_spectateur, nom_spectateur, email

BILLET

          num_billet, #id_spectateur, #id_concert, prix, date_achat

souligné = clé primaire # = clé étrangère

id_artiste et id_salle migrent dans CONCERT (associations 1,n côté ARTISTE/SALLE, 1,1 côté CONCERT). L'association ACHETE étant n,n, elle devient la relation BILLET à part entière.

À ton rythme

Exercices gradués

Niveau 1 — échauffement

Sur le schéma relationnel : CLIENT(id_client, nom, email) et COMMANDE(id_commande, date, #id_client) :

a. Quelle est la clé primaire de COMMANDE ? b. Quelle est sa clé étrangère ? c. Un client peut-il exister sans commande ? Une commande peut-elle exister sans client ?

Voir la correction

a. id_commande. b. #id_client, qui pointe vers CLIENT. c. Un client peut exister sans commande. Une commande ne peut pas exister sans client valide, car #id_client référence obligatoirement CLIENT (contrainte d'intégrité référentielle).

Niveau 2 — application

Une association sportive gère des adhérents (nom, prénom, date de naissance) qui possèdent une ou plusieurs licences. Chaque licence a un numéro, une date de délivrance, une date d'expiration, et correspond à un seul sport. Un sport a un nom et une fédération de rattachement.

Construis le MCD puis le schéma relationnel correspondant.

Voir la correction

ADHÉRENT (1,n) — POSSÈDE — (1,1) LICENCE · LICENCE (1,1) — CONCERNE — (1,n) SPORT

ADHÉRENT(id_adhérent, nom, prénom, date_naissance)
SPORT(id_sport, nom_sport, fédération)
LICENCE(num_licence, date_délivrance, date_expiration, #id_adhérent, #id_sport)

Niveau 3 — défi

Un réseau social simplifié gère des utilisateurs (pseudo, email). Un utilisateur peut suivre d'autres utilisateurs (association réflexive). Un utilisateur publie des messages. Un utilisateur peut aimer des messages publiés par d'autres, avec une date de « like ».

Construis le MCD complet en identifiant bien l'association réflexive et ses cardinalités, puis le schéma relationnel.

Voir la correction

SUIT : réflexive sur UTILISATEUR, (0,n)—(0,n). PUBLIE : UTILISATEUR (1,1)—(0,n) MESSAGE. AIME : UTILISATEUR (0,n)—(0,n) MESSAGE, porteuse de date_like.

UTILISATEUR(id_utilisateur, pseudo, email)
MESSAGE(id_message, texte, date_publication, #id_utilisateur)
SUIT(#id_utilisateur_suiveur, #id_utilisateur_suivi)
AIME(#id_utilisateur, #id_message, date_like)

Point clé : dans SUIT, les deux clés étrangères pointent vers la même relation UTILISATEUR — c'est le principe d'une association réflexive.

Bilan

Vocabulaire clé de la séance

Entité Attribut Association Cardinalité Relation Domaine Clé primaire Clé étrangère Anomalie Redondance

Séance 2

La suite : conception et SGBD

Contraintes d'intégrité, anomalies formalisées, rôle du SGBD — et premiers pas en SQL avec la base de la billetterie.