⌂  Menu général
Chapitre Bases de données

Conception, contraintes et rôle du SGBD

Comment garantir des données cohérentes ? Ce que fait vraiment un SGBD pour nous. Et les premiers pas en SQL avec CREATE TABLE.

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

Objectifs de la séance

  • Connaître les trois familles de contraintes d'intégrité : domaine, clé, référence.
  • Comprendre les services rendus par un SGBD : persistance, accès concurrents, efficacité, sécurité.
  • Adopter un regard critique sur l'usage des données personnelles.
  • Découvrir la syntaxe SQL de création de table (CREATE TABLE).
Rappel express

La billetterie, en 30 secondes

Reprends le schéma relationnel obtenu en séance 1 :

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)
Quelle est la clé primaire de BILLET ? Ses clés étrangères ?
Clé primaire : num_billet. Clés étrangères : #id_spectateur (référence SPECTATEUR) et #id_concert (référence CONCERT).
Cours

Les contraintes d'intégrité

Un schéma relationnel ne suffit pas à garantir des données cohérentes : il faut aussi poser des règles.

Contrainte de domaine

Chaque attribut doit respecter le type et l'ensemble de valeurs autorisées pour son domaine.

ex. un prix doit être un nombre positif
Contrainte de clé

La clé primaire d'une relation doit être unique et non vide sur chaque ligne.

ex. deux billets ne peuvent pas avoir le même num_billet
Contrainte de référence

La valeur d'une clé étrangère doit correspondre à une valeur existante de la clé primaire référencée (intégrité référentielle).

ex. un id_concert dans BILLET doit exister dans CONCERT
Exercice 1

Repérer les violations de contraintes

On tente d'insérer ces lignes dans BILLET, sachant que les spectateurs enregistrés ont pour identifiants 11 à 15, et les concerts 1 à 5.

num_billetid_spectateurid_concertprixdate_achat
1123452026-08-01
2123452026-08-01
3993452026-08-02
4127452026-08-02
5123-102026-08-03
2153382026-08-03
Pour chaque ligne posant problème, quelle contrainte est violée ?
Ligne 3 (id_spectateur=99) : contrainte de référence — ce spectateur n'existe pas.
Ligne 4 (id_concert=7) : contrainte de référence — ce concert n'existe pas.
Ligne 5 (prix=-10) : contrainte de domaine — un prix ne peut pas être négatif.
Ligne 6 (num_billet=2, en double) : contrainte de clé — num_billet doit être unique, or la valeur 2 existe déjà.
Cours

Le rôle du SGBD

Un SGBD (Système de Gestion de Base de Données) est le logiciel qui gère la base à notre place.

Persistance

Les données restent stockées durablement, même après l'arrêt du programme.

Accès concurrents

Plusieurs utilisateurs peuvent lire/modifier la base en même temps sans conflit.

Efficacité

Le SGBD optimise la recherche et la manipulation, même sur de gros volumes.

Sécurité

Il contrôle qui a le droit de lire ou modifier quelles données.

Activité

Usage responsable des données

La billetterie possède les emails de tous ses spectateurs.

a. Peut-elle revendre cette liste sans prévenir les spectateurs ?
Non : cela serait contraire au RGPD (Règlement Général sur la Protection des Données), qui impose que les données personnelles soient utilisées uniquement pour la finalité pour laquelle elles ont été collectées, avec le consentement de la personne concernée.
b. Quelles précautions un SGBD peut-il mettre en place ?
Restreindre les droits d'accès (seuls certains comptes autorisés peuvent lire la table SPECTATEUR), chiffrer les données sensibles, et conserver un historique des accès (traçabilité).
Cours

Créer une table en SQL : CREATE TABLE

CREATE TABLE nom_table (
    colonne1 TYPE CONTRAINTE,
    colonne2 TYPE CONTRAINTE,
    -- ...
    PRIMARY KEY (colonne1),
    FOREIGN KEY (colonneX) REFERENCES autre_table(colonne)
);

Types courants : INTEGER, TEXT, REAL, DATE. Contraintes courantes : NOT NULL (obligatoire), UNIQUE (pas de doublon).

Exercice guidé — Table ARTISTE

CREATE TABLE ARTISTE (
    id_artiste INTEGER,
    nom_artiste TEXT NOT NULL,
    genre TEXT,
    PRIMARY KEY (id_artiste)
);
À ton rythme

Exercices gradués — CREATE TABLE

Niveau 1

Écris le CREATE TABLE de SALLE(id_salle, nom_salle, ville).

Voir la correction
CREATE TABLE SALLE (
    id_salle INTEGER,
    nom_salle TEXT NOT NULL,
    ville TEXT,
    PRIMARY KEY (id_salle)
);
Niveau 2

Écris le CREATE TABLE de CONCERT(id_concert, nom_concert, date_concert, #id_artiste, #id_salle), avec ses deux clés étrangères.

Voir la correction
CREATE TABLE CONCERT (
    id_concert INTEGER,
    nom_concert TEXT NOT NULL,
    date_concert DATE,
    id_artiste INTEGER,
    id_salle INTEGER,
    PRIMARY KEY (id_concert),
    FOREIGN KEY (id_artiste) REFERENCES ARTISTE(id_artiste),
    FOREIGN KEY (id_salle) REFERENCES SALLE(id_salle)
);
Niveau 3 — défi

Écris le CREATE TABLE de BILLET(num_billet, #id_spectateur, #id_concert, prix, date_achat), avec NOT NULL sur prix, et si tu trouves comment faire, une contrainte interdisant un prix négatif (indice : CHECK).

Voir la correction
CREATE TABLE BILLET (
    num_billet INTEGER,
    id_spectateur INTEGER,
    id_concert INTEGER,
    prix REAL NOT NULL CHECK (prix >= 0),
    date_achat DATE,
    PRIMARY KEY (num_billet),
    FOREIGN KEY (id_spectateur) REFERENCES SPECTATEUR(id_spectateur),
    FOREIGN KEY (id_concert) REFERENCES CONCERT(id_concert)
);
CHECK est hors-programme strict mais illustre bien comment un SGBD peut faire respecter une contrainte de domaine plus fine que le simple type.
Bilan

Vocabulaire clé de la séance

Contrainte de domaine Contrainte de clé Intégrité référentielle Persistance Accès concurrents SGBD CREATE TABLE PRIMARY KEY FOREIGN KEY
Séance 3

La suite : peupler la base

Passage à la pratique sur DB Browser for SQLite : création effective des 5 tables, puis INSERT, UPDATE et DELETE sur la billetterie.