Bases de données relationnelles

Une base de données relationnelle ne se contente pas de stocker des données : elle les organise en tables reliées par des clés et protégées par des contraintes. Cette organisation doit répondre à des usages différents, comme les transactions courtes de l’OLTP ou les requêtes analytiques de l’OLAP. Ce chapitre présente les clés, la normalisation et les transactions ACID, en distinguant le modèle logique du stockage physique.

Qu’est-ce qu’une base de données relationnelle ?

Une base de données relationnelle organise donc l’information sous forme de tables, chacune décrivant un type d’objet ou de fait du domaine. Une table est un ensemble de lignes et de colonnes. Chaque ligne représente un enregistrement ; une clé primaire ou une contrainte d’unicité permet de l’identifier sans ambiguïté. Chaque colonne décrit un attribut. Les tables se relient par des clés, ce qui permet de croiser les informations sans les recopier.

Table Clients

Id_client Prenom Nom Age
1 Aymen El Hankouri 36
2 Jean-Pierre Jeunet 72
3 Andreï Tarkovski 50
4 Giuseppe Tornatore 69
5 Nadine Labaki 51

Exemple : une table Clients. Chaque ligne est un enregistrement ; Id_client, en bleu, est la clé primaire qui identifie la ligne.

Une application de commerce peut utiliser MySQL, PostgreSQL ou Cloud SQL pour enregistrer les clients, les produits et les commandes. Lorsque l’entreprise veut analyser plusieurs années de ventes, elle peut utiliser BigQuery, qui est conçu pour interroger rapidement de grandes quantités de données.

Le modèle relationnel correspond à la structure logique des données : tables, clés et contraintes. Le stockage physique correspond à leur organisation réelle dans le moteur : stockage par lignes ou par colonnes, index, partitions et clustering. Cette distinction explique pourquoi deux systèmes peuvent exposer des tables SQL semblables tout en répondant à des workloads différents.

Quand l’utiliser ?

Une base relationnelle est adaptée lorsque les données sont structurées, liées entre elles et soumises à des règles d’intégrité. En 2026, on la retrouve notamment dans les usages suivants :

  • Transactions courantes — OLTP. L’application enregistre rapidement des opérations fiables. Exemples : paiement mobile, commande en ligne, réservation ou mise à jour d’un stock.
  • Applications métier. Les données sont organisées autour d’entités liées et réutilisées par plusieurs fonctions. Exemples : CRM avec clients et commandes, gestion des contrats, suivi des employés ou gestion d’un catalogue produit.
  • Analyse décisionnelle — OLAP. Les données opérationnelles sont préparées puis chargées dans un data warehouse comme BigQuery. Exemples : suivre le chiffre d’affaires, comparer les ventes par région ou construire un tableau de bord.
  • Séparation des usages. Une base PostgreSQL, MySQL ou Cloud SQL peut faire fonctionner l’application, tandis que BigQuery analyse son historique. Les deux systèmes travaillent sur les mêmes données métier, mais avec des requêtes et des objectifs différents.

De la transaction à la décision : OLTP et OLAP

Critère OLTP OLAP
Objectif Gérer les transactions courantes Analyser de grands volumes historiques
Opérations Insertions, mises à jour, suppressions Requêtes complexes, agrégations
Modèle Souvent normalisé Souvent dimensionnel ou dénormalisé
Priorité Latence et concurrence Débit de scan et agrégation
Requêtes Courtes et nombreuses Longues ; cadence variable
Intégrité Transactions et contraintes fortes Garanties selon le moteur
Stockage Souvent par lignes et index Souvent columnar et partitionné
Mise à jour Continue ou par micro-lots Batch ou streaming
Utilisateurs Opérations, applications de vente Analytics, machine learning
Exemples PostgreSQL, MySQL, Cloud SQL BigQuery, Snowflake, Redshift

Les caractéristiques indiquées sont des tendances, non des définitions absolues.

OLTP et OLAP désignent d’abord des workloads. OLTP privilégie de nombreuses transactions courtes, la faible latence, la concurrence et l’intégrité. OLAP privilégie les scans, les jointures et les agrégations sur de grands ensembles. Les moteurs OLTP utilisent souvent un stockage par lignes et des index ; les moteurs analytiques emploient souvent un stockage columnar, du partitionnement et du clustering. Ce sont des choix physiques fréquents, pas les définitions d’OLTP et d’OLAP.

Clé primaire et clé étrangère

La clé primaire identifie de façon unique une ligne : ni doublon, ni valeur nulle. La clé étrangère référence une clé primaire ou une contrainte UNIQUE d’une autre table ; elle admet des doublons, et parfois des valeurs nulles selon ce que le modèle autorise.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#E8EEF8","primaryTextColor":"#003399","primaryBorderColor":"#003399","lineColor":"#003399","fontFamily":"Arial, Helvetica, sans-serif"}}}%%
erDiagram
    direction LR
    CLIENTS ||--o{ TRANSACTIONS : reference

    CLIENTS {
        INT64 id_client PK
        STRING nom
        STRING ville
    }

    TRANSACTIONS {
        INT64 id_transaction PK
        INT64 id_client FK
        INT64 id_site FK
        DATE date
    }

Figure 18. Clé primaire vs clé étrangère.
La table Transactions référence la table Clients : sa clé étrangère id_client pointe vers la clé primaire id_client de Clients.
Condition Clé primaire Clé étrangère
Une ou plusieurs colonnes Oui Oui
Doublons autorisés Non Oui
Valeurs NULL autorisées Non Oui
Identifie les lignes de sa table Oui Éventuellement
Nombre par table Une Zéro ou plus

Normaliser pour écrire sans risque

La normalisation vise à réduire la redondance et à éviter les anomalies dans les tables relationnelles. Elle repose sur l’idée que chaque information doit être stockée une seule fois et dépendre de la bonne clé.

Une mauvaise organisation peut provoquer :

  • des anomalies de mise à jour, lorsque la même information doit être corrigée dans plusieurs lignes ;
  • des anomalies d’insertion, lorsqu’une entité ne peut pas être enregistrée sans une autre information ;
  • des anomalies de suppression, lorsqu’une suppression efface involontairement une information encore utile.

Les formes normales s’appliquent progressivement. La 3NF est un repère courant, mais la structure finale dépend des dépendances entre les données et des usages de la base.

1NF : une cellule, une valeur

La première forme normale signifie qu’une cellule ne doit contenir qu’une seule valeur. Il ne faut donc pas écrire plusieurs consoles dans la même cellule, comme NES, SNES, PS1. On crée une ligne pour chaque console afin de faciliter les recherches et les comptages.

1NF : une cellule, une valeur Deux tableaux comparent les données avant et après normalisation. Avant, les consoles NES, SNES et PS1 partagent une cellule. Après, chaque console occupe une ligne identifiée par possession_id. 1NF : UNE CELLULE, UNE VALEUR AVANT : NON 1NF client_id nom consoles 12 Alice NES, SNES, PS1 NORMALISER APRÈS : 1NF possession_id client_id console 101 12 NES 102 12 SNES 103 12 PS1 UNE LIGNE PAR POSSESSION
Figure 19. 1NF : une cellule, une valeur.
Une liste dans une cellule (NES, SNES, PS1) est éclatée : une ligne par possession de console, identifiée par possession_id.

2NF : dépendre de toute la clé

La deuxième forme normale concerne les tables dont la clé contient plusieurs colonnes. Chaque information doit dépendre de l’ensemble de la clé. Dans une ligne de commande, la quantité dépend du produit et de la commande. En revanche, la date dépend seulement de la commande et le nom dépend seulement du produit. On place donc ces informations dans des tables séparées : commandes, produits et lignes de commande.

2NF : dépendre de toute la clé À gauche, date_cmd dépend seulement de cmd_id, nom_pdt seulement de pdt_id, tandis que qté dépend de la clé composée. À droite, trois tableaux séparent ligne_commande, commande et produit. 2NF : DÉPENDRE DE TOUTE LA CLÉ AVANT : DÉPENDANCES PARTIELLES cmd_id pdt_id date_cmd nom_pdt qté 101 P001 08/09/2026 Casque 1 date_cmd dépend seulement de cmd_id. nom_pdt dépend seulement de pdt_id. Seule qté dépend du couple (cmd_id, pdt_id). DÉCOMPOSER APRÈS : TROIS TABLEAUX ligne_commande cmd_id pdt_id qté 101 P001 1 commande cmd_id date_cmd 101 08/09/2026 produit pdt_id nom_pdt P001 Casque Chaque attribut dépend de toute la clé de sa table.
Figure 20. 2NF : dépendre de toute la clé.
date_cmd rejoint commande, nom_pdt rejoint produit ; qté reste dans ligne_commande car elle dépend du couple (cmd_id, pdt_id).

3NF : pas de dépendance transitive

La troisième forme normale demande que chaque information dépende directement de la clé de sa table. Dans une table de commandes, nom_client ne dépend pas directement de cmd_id : il dépend de client_id. On place donc les informations du client dans une table séparée. La table des commandes conserve seulement les informations liées à la commande.

3NF : pas de dépendance transitive Avant normalisation, deux commandes du même client répètent le nom Alice : cmd_id détermine client_id, qui détermine nom_client. Après décomposition, la table commande référence une table client où nom_client dépend directement de client_id. 3NF : PAS DE DÉPENDANCE TRANSITIVE AVANT : DÉPENDANCE TRANSITIVE commande cmd_id date_cmd client_id nom_client 101 08/09/2026 C001 Alice 102 09/09/2026 C001 Alice cmd_id DÉTERMINE client_id DÉTERMINE nom_client Un attribut non-clé en détermine d’autres. Alice est répétée dans chaque commande de C001. DÉCOMPOSER APRÈS : DEUX TABLEAUX commande cmd_id date_cmd client_id 101 08/09/2026 C001 102 09/09/2026 C001 RÉFÉRENCE client client_id nom_client C001 Alice Chaque attribut dépend directement de la clé de sa table.
Figure 21. 3NF : pas de dépendance transitive.
nom_client dépend de client_id, pas de cmd_id : on sépare les données du client de celles de la commande.

Normalisation et dénormalisation

La normalisation réduit les répétitions, mais elle peut obliger à utiliser plusieurs tables et donc davantage de jointures. La dénormalisation répète certaines données afin de simplifier les requêtes et d’accélérer les analyses.

On normalise généralement les données utilisées par une application transactionnelle et on peut les dénormaliser lorsqu’elles servent principalement aux tableaux de bord ou aux statistiques. Il n’existe pas de règle universelle : le choix dépend des besoins.

Garantir la cohérence : les propriétés ACID

ACID décrit les propriétés attendues d’une transaction, indépendamment du modèle relationnel ou non relationnel qui la met en œuvre (Haerder et Reuter, 1983). Dans une banque, ACID protège les opérations contre les pannes et les accès simultanés. Ces propriétés ne remplacent pas l’authentification, les droits d’accès ou les systèmes de détection de fraude, mais elles empêchent certaines incohérences qui pourraient être exploitées.

Prenons le cas d’un client qui possède 100 € et tente d’effectuer deux paiements de 80 € en même temps.

Atomicité. Un virement est réalisé entièrement ou pas du tout. Le compte du client est débité et le compte du bénéficiaire est crédité. Une panne entre les deux opérations annule toute la transaction.

Cohérence. Les règles de la banque restent respectées : le montant doit être positif, le compte doit exister et le solde ne doit pas devenir négatif si le découvert est interdit. Un paiement impossible est refusé.

Isolation. Les deux paiements de 80 € ne peuvent pas utiliser simultanément le même solde de 100 €. Une seule opération est validée, ou aucune si les règles de la banque l’interdisent.

Durabilité. Une fois le paiement confirmé, il reste enregistré même si le serveur tombe en panne. La banque peut donc retrouver l’opération et le client ne peut pas profiter d’un redémarrage pour annuler artificiellement le débit.

NoteÀ retenir
  • Modèle relationnel = tables, clés et contraintes.
  • Clé primaire = identifie une ligne. Clé étrangère = relie une table à une autre.
  • 1NF = une cellule contient une seule valeur.
  • 2NF = chaque information dépend de toute la clé composée.
  • 3NF = chaque information dépend directement de la clé de sa table.
  • Normaliser = réduire les répétitions et les anomalies d’écriture, au prix de davantage de tables et parfois de jointures.
  • Dénormaliser = répéter volontairement certaines informations pour simplifier ou accélérer la lecture, notamment pour l’analyse.
  • OLTP = transactions courtes et nombreuses. OLAP = scans, jointures et agrégations sur de grands volumes. Le stockage par lignes ou par colonnes est un choix fréquent, pas la définition de ces workloads.
  • ACID = atomicité, cohérence, isolation et durabilité. Ces garanties dépendent du moteur et de sa configuration ; elles ne sont pas réservées aux bases relationnelles.