Définition d’une base de données relationnelle

Une base de données relationnelle est un système de gestion de données organisé selon le modèle relationnel, tel que défini par Edgar F. Codd dans les années 1970. Dans ce modèle, les données sont structurées sous forme de tables (appelées aussi relations), qui représentent des ensembles d’éléments homogènes. Chaque table se compose de lignes (enregistrements ou tuples) et de colonnes (attributs ou champs).

Concepts clés

L’idée fondamentale est d’établir des relations (d’où le terme « relationnel ») entre ces tables en utilisant des clés primaires et des clés étrangères, ce qui permet de maintenir l’intégrité et la cohérence des données pour garantir une structure normalisée.

Tables, lignes et colonnes

Dans une base de données relationnelle, une table est comparable à une feuille de calcul (spreadsheet) : chaque table correspond à un domaine d’informations précis. Par exemple, pour un système de gestion d’une bibliothèque, on pourra avoir une table Livres, une table Auteurs et une table Emprunteurs.

Colonnes : chaque colonne (ou attribut) définit un type d’information stockée pour un enregistrement. Par exemple, dans la table Livres, on pourra avoir les colonnes ID_Livre, Titre, Date_Publication et ISBN. Les colonnes spécifient le nom de l’attribut ainsi que son type (entier, texte, date, etc.).

Lignes : chaque ligne (ou enregistrement) correspond à une occurrence particulière d’un ensemble de colonnes. Dans la table Livres, une ligne pourra être :

ID_Livre	Titre	Date_Publication	ISBN
1	« Le Petit Prince »	1943-04-06	978-0156012195
2	« Les Misérables »	1862-01-01	978-2070409180

Clés primaires

La clé primaire (Primary Key) est un ou plusieurs attributs (colonnes) dont la combinaison garantit l’unicité de chaque ligne au sein d’une table. En d’autres termes, aucune deux lignes d’une même table ne peuvent partager la même valeur pour la clé primaire. Cette contrainte est essentielle pour identifier de manière univoque chaque enregistrement, faciliter les opérations de mise à jour et de suppression, et maintenir l’intégrité des relations entre tables.

Par exemple, dans la table Auteurs, la colonne ID_Auteur (typiquement de type entier auto-incrémenté) pourra servir de clé primaire :

ID_Auteur	Nom	Prénom	Date_Naissance
1	Hugo	Victor	1802-02-26
2	de Saint-Exupéry	Antoine	1900-06-29

Ici, ID_Auteur est unique pour chaque auteur. Si l’on souhaite ajouter un nouvel auteur, la base de données génère automatiquement un nouvel identifiant qui n’existe pas encore dans la table.

Clés étrangères

Une clé étrangère (Foreign Key) est un attribut (ou un ensemble d’attributs) d’une table qui fait référence à la clé primaire d’une autre table. Son rôle est de créer une liaison entre deux tables, garantissant que les valeurs présentes dans la colonne de la clé étrangère correspondent à une valeur existante dans la table référencée. Cette contrainte permet d’assurer la cohérence référentielle : on ne peut pas insérer dans une table fille une valeur de clé étrangère qui n’existe pas dans la table parent.

Reprenons l’exemple de la base de données d’une bibliothèque. Imaginons une table Emprunts qui enregistre quels livres ont été empruntés par quels emprunteurs :

ID_Emprunt	ID_Livre	ID_Emprunteur	Date_Emprunt	Date_Retour
1	2	10	2025-05-15	2025-06-15
2	1	7	2025-05-20	2025-06-20

ID_Livre est une clé étrangère référencée à la table Livres (colonne ID_Livre dans Livres).
ID_Emprunteur est une clé étrangère référencée à la table Emprunteurs (colonne ID_Emprunteur dans Emprunteurs).

Ainsi, avant d’autoriser l’insertion d’un emprunt, le SGBD (Système de Gestion de Base de Données) s’assure que la valeur indiquée pour ID_Livre existe bien dans la table Livres et que la valeur pour ID_Emprunteur existe bien dans la table Emprunteurs.

Relations

Dans une base de données relationnelle, les tables ne sont pas isolées : elles communiquent entre elles via des relations, qui définissent les liens logiques entre les données. Le type de relation détermine comment les informations se connectent, et cela repose sur le concept de cardinalité. Trois formes principales sont utilisées : un à un, un à plusieurs, et plusieurs à plusieurs.

Dans les exemples suivant, on utilise PK pour représenter les clés primaires (Primary Key) et FK pour les clés étrangères (Foreign Key). Les relations sont illustrées avec des tableaux, et les concepts sont intégrés de manière fluide dans le texte, comme demandé.

Relation un à un (1:1)

Une relation un à un signifie qu’à chaque enregistrement d’une table correspond un seul enregistrement dans l’autre table. Cela s’implémente généralement en faisant d’une colonne une clé étrangère avec une contrainte d’unicité.

Exemple : chaque Utilisateur possède un Profil unique.

Table `Utilisateur`	Type	Description
`id`	INT (PK)	Identifiant unique
`nom`	TEXT	Nom de l’utilisateur

Table `Profil`	Type	Description
`id`	INT (PK)	Identifiant du profil
`utilisateur_id`	INT (FK, UNIQUE)	Référence à `Utilisateur.id`
`bio`	TEXT	Présentation courte

Dans cette relation, la colonne utilisateur_id est une clé étrangère (FK) qui pointe vers la clé primaire (PK) Utilisateur.id, et la contrainte UNIQUE garantit qu’un seul profil est lié à un seul utilisateur.

Relation un à plusieurs (1:N)

Dans une relation un à plusieurs, une entrée dans la table "parent" peut être reliée à plusieurs entrées dans la table "enfant", mais chaque entrée "enfant" ne peut pointer que vers une seule entrée "parent". Ici, la clé étrangère est placée dans la table "enfant".

Exemple : un Auteur peut écrire plusieurs Livre.

Table `Auteur`	Type	Description
`id`	INT (PK)	Identifiant de l’auteur
`nom`	TEXT	Nom de l’auteur

Table `Livre`	Type	Description
`id`	INT (PK)	Identifiant du livre
`titre`	TEXT	Titre du livre
`auteur_id`	INT (FK)	Référence à `Auteur.id` (clé étrangère)

La clé étrangère auteur_id relie chaque livre à un auteur unique, tandis qu’un même auteur peut apparaître plusieurs fois dans la table Livre.

Relation plusieurs à plusieurs (N:M)

Lorsqu’une entité peut être liée à plusieurs instances d’une autre entité, et inversement, on utilise une table de jonction (ou table associative) contenant deux clés étrangères qui forment ensemble une clé primaire composite.

Exemple : les Étudiants peuvent s’inscrire à plusieurs Cours, et chaque Cours peut avoir plusieurs Étudiants.

Table `Étudiant`	Type	Description
`id`	INT (PK)	Identifiant de l’étudiant
`nom`	TEXT	Nom de l’étudiant

Table `Cours`	Type	Description
`id`	INT (PK)	Identifiant du cours
`nom`	TEXT	Intitulé du cours

Table `Inscription`	Type	Description
`etudiant_id`	INT (FK)	Référence à `Étudiant.id`
`cours_id`	INT (FK)	Référence à `Cours.id`
PK	(etudiant_id, cours_id)	Clé primaire composite

Dans ce modèle, la table Inscription contient deux clés étrangères pointant respectivement vers Étudiant et Cours. Ensemble, ces deux colonnes forment la clé primaire composite, empêchant les doublons et représentant efficacement la relation N:M.

SQL (Structured Query Language)

Le SQL (Structured Query Language) est le langage standardisé utilisé pour interagir avec les bases de données relationnelles. Il permet non seulement de définir et de modifier la structure même des tables (par le biais du DDL, Data Definition Language), mais aussi d’insérer, de mettre à jour, de supprimer et de consulter les données (par le biais du DML, Data Manipulation Language). Enfin, SQL inclut des fonctionnalités de contrôle d’accès et de gestion des transactions (DCL, Data Control Language et TCL, Transaction Control Language).

Consultation des données

Pour consulter des données dans une base de données, on utilise la commande SELECT, qui permet d'interroger la base selon des critères précis. Par exemple, pour récupérer tous les noms et prénoms des auteurs on peut écrire :

SELECT Nom, Prenom
FROM Auteurs

Il est également possible d'effectuer des jointures entre plusieurs tables pour obtenir des résultats combinés. Par exemple, la requête suivante renvoie le titre des livres écrits par Victor Hugo :

SELECT L.Titre, A.Nom, A.Prenom
FROM Livres L
JOIN Auteurs A ON L.ID_Auteur = A.ID_Auteur
WHERE A.Nom = 'Hugo';

Insertion, mise à jour et suppression de données (DML)

Insertion : la commande INSERT INTO permet d’ajouter de nouvelles lignes dans une table.

INSERT INTO Auteurs (Nom, Prenom, Date_Naissance, Nationalite)
VALUES ('Hugo', 'Victor', '1802-02-26', 'Française');

Mise à jour : la commande UPDATE modifie les valeurs d’une ou plusieurs colonnes pour les lignes correspondant à une condition donnée.

UPDATE Auteurs
SET Nationalite = 'Française'
WHERE ID_Auteur = 1;

Suppression : la commande DELETE supprime des lignes répondant à un critère spécifié.

DELETE FROM Auteurs
WHERE Date_Naissance < '1900-01-01';

Tri, agrégation et regroupement

On peut utiliser des fonctions d’agrégation comme SUM, COUNT, AVG, MAX ou MIN pour calculer des statistiques, ainsi que des clauses supplémentaires comme GROUP BY, HAVING ou LIMIT.

Nombre total de livres :

SELECT COUNT(*) AS NombreLivres
FROM Livres;

Total des ventes d’un livre :

SELECT SUM(Ventes) AS VentesTotales
FROM Livres
WHERE Titre = 'Le Petit Prince';

Prix moyen, maximum et minimum des livres :

SELECT 
  AVG(Prix) AS PrixMoyen,
  MAX(Prix) AS PrixMax,
  MIN(Prix) AS PrixMin
FROM Livres;

Nombre de livres par auteur :

SELECT Auteur_ID, COUNT(*) AS NombreLivres
FROM Livres
GROUP BY Auteur_ID;

Auteurs ayant écrit plus de 5 livres :

SELECT Auteur_ID, COUNT(*) AS NombreLivres
FROM Livres
GROUP BY Auteur_ID
HAVING COUNT(*) > 5;

Top 10 des livres les plus vendus :

SELECT Titre, Ventes
FROM Livres
ORDER BY Ventes DESC
LIMIT 10;

Création et modification de tables (DDL)

Pour définir la structure d’une table, on utilise la commande CREATE TABLE. Par exemple :

CREATE TABLE Auteurs (
  ID_Auteur INT PRIMARY KEY AUTO_INCREMENT,
  Nom VARCHAR(100) NOT NULL,
  Prenom VARCHAR(100) NOT NULL,
  Date_Naissance DATE
);

INT définit le type entier, VARCHAR(100) définit une chaîne de caractères de longueur maximale 100, DATE est un type date.
PRIMARY KEY associe la colonne ID_Auteur à la clé primaire.
AUTO_INCREMENT (ou SERIAL dans certains SGBD) indique que l’identifiant est généré automatiquement.
NOT NULL signifie que la colonne ne peut pas contenir de valeur NULL.

Pour modifier une table existante, on utilise la commande ALTER TABLE. Par exemple, pour ajouter une colonne :

ALTER TABLE Auteurs
ADD COLUMN Nationalite VARCHAR(50);

Transactions et contrôle d’accès

Le SQL inclut également des commandes pour gérer les transactions :

BEGIN TRANSACTION (ou START TRANSACTION) pour démarrer une transaction.
COMMIT pour valider définitivement les modifications effectuées depuis le début de la transaction.
ROLLBACK pour annuler toutes les modifications effectuées depuis le début de la transaction, en cas d’erreur ou d’incohérence détectée.

Par exemple :

BEGIN TRANSACTION;
-- Transfert d'argent entre deux comptes
UPDATE Comptes SET Solde = Solde - 100 WHERE ID = 123;  -- Débit
UPDATE Comptes SET Solde = Solde + 100 WHERE ID = 456;  -- Crédit
-- Si aucune erreur :
COMMIT;
-- Si une erreur se produit (ex : solde insuffisant) :
-- ROLLBACK;

Les commandes de contrôle d’accès (DCL) comme GRANT et REVOKE permettent de définir qui peut lire, écrire ou administrer les différentes parties de la base de données.

Par exemple :

-- Création d'un rôle "lecture_seule"  
CREATE ROLE lecture_seule;  
GRANT SELECT ON ALL TABLES IN SCHEMA public TO lecture_seule;  
-- Attribution à un utilisateur  
GRANT lecture_seule TO utilisateur4;

Propriétés ACID

Les bases de données relationnelles respectent le principe des propriétés ACID, un acronyme qui décrit quatre garanties fondamentales pour la gestion des transactions :

$$\text{ACID} = { \text{Atomicité}, \text{Cohérence}, \text{Isolation}, \text{Durabilité} }$$

Atomicité

Une transaction doit être atomique, c’est-à-dire qu’elle s’exécute en totalité ou pas du tout. Si une partie de la transaction échoue, l’ensemble des opérations réalisées depuis le début de cette transaction doit être annulé (rollback). Par exemple, lors d’un virement bancaire :

Étapes	Actions
Étape 1	Débit du compte A.
Étape 2	Crédit du compte B.

Si l’étape 2 échoue (panne du serveur, violation d’intégrité, etc.), l’étape 1 doit être annulée pour éviter que de l’argent disparaisse ou n’apparaisse sur un compte sans correspondance.

Cohérence

La transaction doit garantir que la base de données reste dans un état cohérent à l’issue de son exécution. Cela signifie que toutes les contraintes (contraintes d’intégrité, contraintes de clé étrangère, règles métier définies par le SGBD ou par des procédures stockées) doivent être respectées avant et après la transaction. Par exemple, si la somme des montants débités et crédités dans une transaction bancaire doit rester égale, alors l’exécution d’une transaction ne doit pas aboutir à un déséquilibre.

Isolation

L’isolation fait référence au fait que l’exécution concurrente de plusieurs transactions ne doit pas entraîner d’effets indésirables (incohérences, lectures de données intermédiaires, etc.). On définit plusieurs niveaux d’isolation (selon la norme SQL) :

READ UNCOMMITTED : les transactions peuvent voir les données non validées par d’autres transactions (phénomène de « lecture sale »).
READ COMMITTED : une transaction ne peut lire que les données validées par d’autres transactions (empêche la lecture sale, mais autorise la « lecture non répétable »).
REPEATABLE READ : garantit que si une transaction lit à plusieurs reprises une même ligne, elle obtient toujours la même valeur durant toute la transaction (empêche la lecture non répétable, mais pas le phénomène de « phantom read »).
SERIALIZABLE : le niveau le plus strict, qui garantit l’équivalent d’une serialisation des transactions, c’est-à-dire que l’effet produit par plusieurs transactions concurrentes est identique à celui qu’on obtiendrait si on les exécutait l’une après l’autre dans un ordre quelconque (empêche le « phantom read »).

Durabilité

La durabilité garantit que, une fois qu’une transaction est validée (commit), ses modifications sont pérennes : elles survivent à toute défaillance du système (panne d’électricité, crash du serveur, etc.). Les SGBD assurent cette propriété en enregistrant les changements dans des journaux (logs) avant de les appliquer définitivement aux fichiers de données. Ainsi, en cas de redémarrage, le SGBD peut rejouer les transactions validées à partir de ces journaux pour restaurer l’état de la base de données.

Exemple d’utilisation simple

Imaginons une base de données de gestion d’étudiants et de cours. Voici les trois tables principales :

Table `Etudiants`

CREATE TABLE Etudiants (
    ID_Etudiant INT PRIMARY KEY AUTO_INCREMENT,
    Nom VARCHAR(50),
    Prenom VARCHAR(50),
    Date_Naissance DATE
);

Colonne	Type	Contraintes
ID_Etudiant	INT	PRIMARY KEY, AUTO_INCREMENT
Nom	VARCHAR(50)
Prenom	VARCHAR(50)
Date_Naissance	DATE

Table `Cours`

CREATE TABLE Cours (
    ID_Cours INT PRIMARY KEY AUTO_INCREMENT,
    Intitule VARCHAR(100),
    Credits INT
);

Colonne	Type	Contraintes
ID_Cours	INT	PRIMARY KEY, AUTO_INCREMENT
Intitule	VARCHAR(100)
Credits	INT

Table `Inscriptions` (relation n-n entre Étudiants et Cours)

La table Inscriptions est nécessaire pour modéliser une relation de type plusieurs-à-plusieurs (n-n) entre les étudiants et les cours. En effet, un étudiant peut suivre plusieurs cours au cours de sa formation, et un cours peut être suivi par plusieurs étudiants. Cette multiplicité réciproque ne peut pas être représentée directement par une clé étrangère dans une seule des deux tables. La solution consiste à créer une table intermédiaire — ici Inscriptions — qui fait le lien entre les deux entités. Chaque enregistrement de cette table associe un étudiant à un cours donné, à une date précise d’inscription.

CREATE TABLE Inscriptions (
    ID_Inscription INT PRIMARY KEY AUTO_INCREMENT,
    ID_Etudiant INT,
    ID_Cours INT,
    Date_Inscription DATE,
    FOREIGN KEY (ID_Etudiant) REFERENCES Etudiants(ID_Etudiant),
    FOREIGN KEY (ID_Cours) REFERENCES Cours(ID_Cours)
);

Colonne	Type	Contraintes
ID_Inscription	INT	PRIMARY KEY, AUTO_INCREMENT
ID_Etudiant	INT	FOREIGN KEY → `Etudiants(ID_Etudiant)`
ID_Cours	INT	FOREIGN KEY → `Cours(ID_Cours)`
Date_Inscription	DATE

Objectif : ajouter un étudiant et l’inscrire à un cours

Nous allons :

Créer un étudiant,
L'inscrire à un cours existant,
Le tout dans une transaction pour assurer l'atomicité.

BEGIN TRANSACTION;

INSERT INTO Etudiants (Nom, Prenom, Date_Naissance)
VALUES ('Dupont', 'Marie', '2003-11-15');

-- Supposons que l'étudiant obtient l'ID 5
INSERT INTO Inscriptions (ID_Etudiant, ID_Cours, Date_Inscription)
VALUES (5, 2, '2025-06-01');

COMMIT;

Remarque : Si le cours avec ID_Cours = 2 n'existe pas (ou est supprimé), la seconde insertion échouera. Grâce à la transaction, tout sera annulé via un ROLLBACK implicite : Marie Dupont ne sera pas ajoutée à la base, assurant ainsi la cohérence des données.

Les bases de données relationnelles

All work licensed under CC BY-NC-SA 4.0