Une base de données relationnelle organise les informations en tables afin de les retrouver, de les relier et de les modifier sans confondre les enregistrements. Pour lire un schéma ou concevoir une petite application, quelques mots suffisent à comprendre comment ces éléments s’emboîtent.
Imaginez une librairie qui suit ses clients, ses commandes et ses livres : chaque donnée doit avoir une place claire. Les notions de champ, d’attribut, de clé primaire, de clé étrangère et de cardinalité éclairent cette organisation et les règles qui la protègent.
A retenir :
- Tables distinctes pour des entités clairement identifiées
- Clés primaires stables pour retrouver chaque enregistrement
- Clés étrangères pour relier les données sans doublons inutiles
- Contraintes adaptées pour préserver la cohérence au quotidien
Tables et attributs : lire le vocabulaire du modèle relationnel
Une fois les informations réparties par sujet, il devient plus facile de comprendre ce que chaque table décrit. Le modèle relationnel, proposé par Edgar F. Codd en 1970, représente ces informations sous forme de lignes et de colonnes.
Table, enregistrement, champ et attribut
Dans la librairie, une table « Clients » regroupe les données relatives aux personnes, tandis qu’une table « Livres » décrit les ouvrages disponibles. Chaque ligne est un enregistrement, et chaque colonne correspond à un champ décrivant une propriété.
Le mot attribut désigne cette propriété dans la conception du modèle : « nom », « courriel » ou « date de commande ». Un schéma précise les tables, leurs attributs, leurs types de données et les règles applicables.
Schéma relationnel et organisation des données
Le schéma sert de plan avant la création des tables dans un système de gestion de base de données. Il aide l’équipe à repérer les informations redondantes, par exemple un nom de client répété dans chaque commande.
Pour démarrer, la librairie peut distinguer clients, commandes et livres plutôt que de tout inscrire dans une seule table. Cette séparation rend les relations visibles et prépare le choix des identifiants.
Repères pour lire une table :
- Une table dédiée à un sujet identifiable
- Des colonnes décrivant les propriétés de ce sujet
- Des lignes correspondant aux éléments enregistrés
- Des types cohérents avec chaque donnée attendue
| Terme | Rôle | Exemple en librairie |
|---|---|---|
| Table | Regroupe des données d’un même sujet | Clients |
| Enregistrement | Décrit un élément particulier | Une cliente |
| Champ | Contient une valeur par enregistrement | Adresse courriel |
| Attribut | Décrit une propriété dans le modèle | Date d’inscription |
Clé primaire et clé étrangère : relier les tables
Après avoir défini les tables, il faut pouvoir distinguer chaque ligne et établir des liens fiables entre elles. Les clés remplissent ces deux fonctions, tandis que la cardinalité décrit la quantité de liens possibles.
Clé primaire : identifier chaque enregistrement
Une clé primaire identifie sans ambiguïté chaque enregistrement d’une table. Dans « Clients », un identifiant numérique peut distinguer deux personnes portant le même nom, contrairement au nom lui-même, qui peut changer ou se répéter.
Une clé primaire ne peut être absente ni dupliquée. Elle peut reposer sur un seul champ ou sur plusieurs attributs réunis, selon la structure des données et les règles du projet.
Clé étrangère, relation et cardinalité
Dans « Commandes », le champ « client_id » peut référencer l’identifiant d’un client : c’est une clé étrangère. Elle permet de relier les tables et d’éviter de recopier les coordonnées du client dans chaque commande.
La cardinalité précise combien d’éléments peuvent être associés : un client peut passer plusieurs commandes, alors qu’une commande appartient généralement à un client. Une relation plusieurs-à-plusieurs, comme commandes et livres, nécessite souvent une table intermédiaire.
« Dans notre exemple de librairie, chaque commande renvoie au client par son identifiant, plutôt que par son nom. »
Scénario pédagogique fictif
Relations courantes entre tables :
- Un-à-un : un élément associé à un seul autre élément
- Un-à-plusieurs : un client associé à plusieurs commandes
- Plusieurs-à-plusieurs : commandes et livres reliés par une table intermédiaire
Une fois les liens posés, le système doit aussi empêcher les références invalides et les valeurs incohérentes. C’est le rôle des contraintes d’intégrité.
Contraintes et bonnes pratiques pour préserver la cohérence
Quand les relations sont établies, les contraintes protègent la base contre les erreurs de saisie et les liens cassés. Leur choix doit refléter les règles réelles de l’activité, plutôt que d’ajouter des restrictions sans raison.
Contraintes d’intégrité : limiter les données invalides
Une contrainte NOT NULL exige une valeur, tandis que UNIQUE empêche les doublons dans un champ, comme une adresse courriel lorsqu’elle doit être distincte. Une règle CHECK peut, par exemple, imposer un prix supérieur à zéro.
La clé étrangère vérifie qu’une commande pointe vers un client existant. Selon la règle retenue, la suppression du client peut être refusée ou entraîner une action définie explicitement ; le choix de suppression en cascade mérite une attention particulière.
| Contrainte | Effet principal | Exemple d’usage |
|---|---|---|
| NOT NULL | Refuse une valeur manquante | Identifiant obligatoire |
| UNIQUE | Évite les valeurs répétées | Courriel distinct |
| CHECK | Applique une condition | Prix positif |
| FOREIGN KEY | Contrôle une référence entre tables | Commande liée à un client existant |
Normalisation et choix des clés au quotidien
La normalisation consiste notamment à séparer les informations qui décrivent des sujets différents. Dans l’exemple, les coordonnées restent dans « Clients » et les détails des ouvrages dans « Livres », ce qui limite les modifications répétées.
Avant de créer une table, vérifiez que chaque champ représente une seule information et que chaque relation traduit une règle métier compréhensible. Une structure claire facilite ensuite les jointures, les contrôles et l’évolution de l’application.
« Une clé stable nous évite de perdre le lien avec un client lorsque son adresse change. »
Scénario pédagogique fictif
Contrôles utiles lors de la conception :
- Identifiants uniques et jamais laissés vides
- Références cohérentes entre tables liées
- Contraintes conformes aux règles métier établies
- Informations répétées déplacées vers une table adaptée
Pour une petite librairie comme pour une application plus vaste, ces repères rendent les données plus faciles à maintenir. Les clés donnent une identité aux lignes, et les relations expliquent comment elles se répondent.
« Je commence par nommer les tables et les identifiants, puis je vérifie les liens avec des exemples réels. »
Scénario pédagogique fictif
« Une contrainte bien choisie bloque une erreur avant qu’elle ne se propage dans plusieurs tables. »
Scénario pédagogique fictif
Un mot qui se comprend dossier après dossier
Qu'il s'agisse de philosophie bouddhiste, de méditation, de culture tibétaine, d'industrie durable, de linguistique ou de bien-être, chaque rubrique raconte une facette différente de la même question : comment un même mot peut porter, à la fois, une pensée millénaire et un usage bien actuel. Rien n'est figé : chaque contexte nouveau peut encore faire évoluer ce sens.
Pour aller plus loin
- Comparer plusieurs sources avant de juger la portée d'une traduction ou d'une définition
- Replacer chaque terme dans son contexte culturel réel, pas seulement sa traduction littérale
- S'intéresser aux usages vivants de la langue autant qu'aux définitions figées
- Observer comment un même mot évolue d'un domaine à l'autre au fil du temps
