Modèle relationnel de données

Il était une fois, quand les dinosaures étaient énormes… enfin, plutôt en 1970, un gars nommé Edgar Codd s’est dit que le chaos dans les données avait dépassé le stade du bazar créatif et ressemblait plus à un trou noir qui bouffe ton temps et tes ressources. Edgar a bien réfléchi et a trouvé un moyen de tout organiser, posant au passage les bases d’un monde où les données sont rangées dans des petites tables bien propres, comme des livres sur l’étagère d’une bibliothèque parfaite. Des lignes, des colonnes, de l’ordre — et fini les « ça passe » ou « bah, c’est clair comme ça ».

Le modèle relationnel repose sur la représentation des données sous forme de tables, où chaque table est composée de lignes et de colonnes. C’est super intuitif : les lignes sont des enregistrements, les colonnes sont des propriétés ou des attributs de l’enregistrement. Cette approche simplifie le traitement et la manipulation des données.

Imagine que tu passes une commande sur un site e-commerce. Pour que ta commande soit bien prise en compte et livrée, le système doit gérer plein de détails : qui tu es (l’acheteur), quel service de livraison tu as choisi, où livrer, et comment suivre le statut du colis.

Si toutes ces infos étaient stockées dans une seule table géante, ce serait le bazar : les données seraient dupliquées, ce serait galère à mettre à jour et encore pire pour retrouver rapidement ce qu’il te faut. L’approche relationnelle aide à mettre de l’ordre en séparant les infos dans différentes tables qui peuvent échanger des données entre elles.

Sur ce schéma, tu vois un exemple d’organisation des données pour le suivi des livraisons :

• Clients – ici on stocke les infos sur chaque client – avec un Numéro Client unique.
• Services de livraison – cette table contient la liste des services qui peuvent livrer, chacun avec un Numéro Service unique.
• Livraison de commande – c’est la table centrale, celle qui fait le lien. Chaque ligne ici, c’est une livraison précise. Elle a son propre Numéro Livraison, et fait référence au client, au service de livraison, peut pointer vers une commande précise, la date et le statut actuel.

Les flèches montrent comment les enregistrements de la table Livraison de commande sont liés aux enregistrements des tables Clients et Services de livraison.

Exemple fictif de la table Livraison de commande :

Les avantages de cette approche :

• Les infos sur les clients ou les services de livraison sont stockées une seule fois, ce qui évite les répétitions dans chaque enregistrement de livraison.
• Les liens via des numéros uniques (on appelle ça des clés) garantissent, par exemple, qu’il n’y aura pas de livraison sans client existant ou via un service inexistant.
• Tu peux facilement combiner les données de plusieurs tables pour faire des rapports complexes ou des sélections précises.
• Quand tu modifies une info, c’est fait à un seul endroit et c’est direct dispo pour toutes les opérations liées (genre le numéro de téléphone du service de livraison).

Structure d’une base de données relationnelle

Le cœur d’une base de données relationnelle, ce sont les tables. Chaque table a :

• Un nom (Table Name) pour qu’on puisse l’identifier — par exemple, customers.
• Un ensemble de colonnes (Columns/Attributes) qui définissent les propriétés de l’objet.
  • Quand on nomme des colonnes qui servent de numéros uniques (clés primaires), on utilise souvent le modèle nom_id. Le suffixe _id veut dire "identifiant". Exemple : Numéro Client devient customer_id.
  • Par exemple, pour la table customers : ça peut être customer_id, first_name, email, etc.
• Des données dans les lignes (Rows/Records) – une ligne dans la table customers contient toutes les infos sur un client précis (101, Alex Song, etc.).

Regardons un exemple de table — customers :

Clés des tables

Pour identifier chaque ligne de façon unique dans une table, on utilise une clé primaire (Primary Key, PK). C’est une colonne (ou plusieurs) dont les valeurs sont uniques pour chaque ligne et ne peuvent pas être vides. Imagine ça comme un numéro unique pour chaque enregistrement, par exemple customer_id dans notre table customers : il identifie clairement chaque client.

La clé primaire, c’est comme un passeport, ou plutôt son numéro : unique pour chaque objet. Et ça évite les soucis avec les lignes qui ont le même nom.

Pour créer des liens entre les tables, on utilise une clé étrangère (Foreign Key, FK). C’est une colonne dans une table qui fait référence à la clé primaire d’une autre table. Les clés étrangères, c’est les "ponts" entre les tables. Souvent, le nom de la colonne de clé étrangère est le même que celui de la clé primaire à laquelle elle fait référence. Par exemple, dans la table deliveries, la colonne customer_id sera une clé étrangère, stockant les valeurs de la colonne customer_id de la table customers, ce qui relie la livraison au client.

C’est le schéma qu’on connaît, mais maintenant il est plus réaliste.

• La table customers contient les infos sur les clients ; sa clé primaire est customer_id.
• La table delivery_services stocke les données sur les services de livraison ; sa clé primaire est service_id.
• La table orders (montrée pour compléter, car il y a une référence order_id depuis la table des livraisons) sert à stocker les infos sur les commandes, avec la clé primaire order_id.
• La table deliveries est centrale pour le suivi des opérations de livraison. Elle a :
  • Sa propre clé primaire : delivery_id.
  • Trois clés étrangères pour faire les liens :
    • customer_id (FK) : relie la livraison à un client précis de la table customers.
    • service_id (FK) : relie la livraison au service choisi de la table delivery_services.
    • order_id (FK) : relie la livraison à la commande correspondante de la table orders.
  • Le champ created_date indique la date et l’heure de création de l’enregistrement de livraison.

Cette utilisation des clés primaires et étrangères garantit l’intégrité des données. Le système ne te laissera pas créer un enregistrement de livraison si le customer_id ou le order_id n’existe pas dans les tables correspondantes, et ça permet de récupérer facilement les infos liées.

Avantages du modèle relationnel

Le modèle relationnel a plein d’atouts qui en font le leader par rapport aux autres approches :

1. Structure simple. Les tables avec colonnes et lignes, c’est clair et facile à piger.
2. Flexibilité pour bosser avec les données. Tu peux ajouter ou modifier des données facilement, sans casser l’intégrité.
3. Support des requêtes complexes. Avec SQL, tu peux récupérer des données de plein de tables, les combiner, filtrer, et faire à peu près tout ce que tu veux. Par exemple, trouver tous les étudiants inscrits à un cours précis — fastoche !
4. Intégrité des données grâce aux clés. L’utilisation des clés primaires et étrangères garantit que les données dans la base restent cohérentes. Impossible, par exemple, d’ajouter un étudiant à un cours qui n’existe pas.

Le modèle relationnel de données, c’est la base des bases de données modernes. C’est simple, puissant et parfait pour stocker des données structurées. Comme disait Edgar Codd : "Range ou crève !" (bon, il l’a dit autrement, mais l’idée est là…). Dans la prochaine leçon, on verra en quoi le modèle relationnel est différent des autres types de bases de données (genre NoSQL) et où il vaut mieux les utiliser.