Bases de données relationnelles

Après avoir étudié le cycle de vie des données et les architectures de stockage, nous abordons leur organisation au sein d’une base. Le modèle relationnel fournit un cadre pour représenter les informations, exprimer leurs liens et définir des règles d’intégrité. Nous examinerons comment la conception des tables et la gestion des transactions contribuent à la cohérence des données. Ces principes serviront ensuite de point de départ à la modélisation des données pour l’analyse.

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

Une base de données relationnelle organise 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 17. 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, sauf contrainte NOT NULL
Identifie les lignes de sa table Oui Éventuellement
Nombre par table Au maximum 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 tables 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 ; l’identifiant du client et son nom, Alice, sont conservés sur chaque ligne. Une icône de clé et le badge PK identifient client_id comme clé primaire avant normalisation, puis possession_id après normalisation. 1NF : UNE CELLULE, UNE VALEUR AVANT : NON 1NF client client_id PK nom consoles 12 Alice NES, SNES, PS1 NORMALISER APRÈS : 1NF possession possession_id PK client_id nom console 101 12 Alice NES 102 12 Alice SNES 103 12 Alice PS1 Une ligne par possession, une seule console par cellule.
Figure 18. 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. Le nom du client est conservé sur chaque ligne ; cette répétition reste possible en 1NF.

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 tables séparent ligne_commande, commande et produit. Le badge PK composée regroupe cmd_id et pdt_id dans la table initiale et dans ligne_commande. Les clés primaires des tables commande et produit sont respectivement cmd_id et pdt_id. 2NF : DÉPENDRE DE TOUTE LA CLÉ AVANT : DÉPENDANCES PARTIELLES ligne_commande cmd_id pdt_id PK composée 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 TABLES ligne_commande cmd_id pdt_id PK composée qté 101 P001 1 commande cmd_id PK date_cmd 101 08/09/2026 produit pdt_id PK nom_pdt P001 Casque Chaque attribut dépend de toute la clé de sa table.
Figure 19. 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. Une icône de clé et le repère PK identifient les clés primaires : cmd_id dans les deux tables commande et client_id dans la table client. 3NF : PAS DE DÉPENDANCE TRANSITIVE AVANT : DÉPENDANCE TRANSITIVE commande cmd_id PK 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 TABLES commande cmd_id PK date_cmd client_id 101 08/09/2026 C001 102 09/09/2026 C001 RÉFÉRENCE client client_id PK nom_client C001 Alice Chaque attribut dépend directement de la clé de sa table.
Figure 20. 3NF : pas de dépendance transitive.
Avant décomposition, nom_client dépend de cmd_id par l’intermédiaire de client_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. Avec un niveau d’isolation et des contrôles adaptés, les deux paiements de 80 € ne peuvent pas être validés à partir du même solde de 100 €. Après un premier paiement, il reste 20 € : le second doit être refusé si le découvert est interdit. Cette garantie dépend du moteur, du niveau d’isolation choisi et de la façon dont l’application vérifie et met à jour le solde.

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.
  • ACID = quatre garanties d’une transaction : atomicité, tout réussit ou tout est annulé ; cohérence, les règles d’intégrité restent respectées ; isolation, les transactions simultanées ne se perturbent pas ; durabilité, une transaction validée reste enregistrée, même après une panne.