Une base de données relationnelle transforme des informations liées en structures lisibles et interrogeables. Proposé par Edgar F. Codd en 1970, ce modèle s’appuie sur des principes mathématiques qui guident encore la conception de nombreux systèmes.
Pour comprendre son fonctionnement, imaginons une librairie qui gère ses livres, ses clients et ses commandes. Quelques notions centrales — tables, attributs, tuples et clés — permettent de construire une organisation cohérente, dont les principes essentiels apparaissent ici.
A retenir :
- Organisation des données en relations structurées et compréhensibles
- Identification fiable des lignes par des clés adaptées
- Réduction des incohérences grâce aux contraintes d’intégrité référentielle
- Interrogation souple des informations avec l’algèbre relationnelle
Modèle relationnel : tables, attributs et tuples
Ces principes prennent forme dans des tables, où chaque ligne décrit un élément et chaque colonne une caractéristique définie. Cette séparation aide la librairie à distinguer les données d’un client de celles d’une commande.
Relations et domaines : organiser les données
Dans ce modèle, une relation correspond à un ensemble structuré de tuples, couramment représenté par une table. Ses attributs nomment les colonnes, tandis que leurs domaines précisent les valeurs admises, comme une date ou un numéro de commande.
La table Clients peut ainsi contenir un identifiant, un nom et une adresse électronique. Une ligne forme un tuple ; l’ordre des lignes n’a pas de signification et chaque tuple doit être identifiable sans ambiguïté.
Selon E. F. Codd, les opérations relationnelles produisent elles-mêmes des relations, ce qui permet de combiner les résultats. Cette propriété distingue le modèle logique de la manière dont un logiciel stocke physiquement les informations.
Les concepts jouent des rôles complémentaires :
- La relation définit un ensemble cohérent d’enregistrements
- L’attribut décrit une propriété commune aux enregistrements
- Le domaine limite les valeurs possibles d’un attribut
- Le tuple rassemble les valeurs d’une ligne particulière
Un schéma bien défini évite, par exemple, de mélanger une date d’achat et un nom dans la même colonne. Le tableau suivant illustre ces notions à partir d’une structure simplifiée.
| Élément | Exemple en librairie | Rôle |
|---|---|---|
| Relation | Clients | Regrouper les fiches clients |
| Attribut | Adresse électronique | Décrire une caractéristique |
| Domaine | Valeurs de type texte | Encadrer les valeurs acceptées |
| Tuple | Une fiche client complète | Représenter un enregistrement |
Clés primaires et étrangères : relier les tables
Une fois les tables définies, leurs liens déterminent comment les informations restent cohérentes. Dans la librairie, les commandes doivent renvoyer à des clients réellement enregistrés, plutôt qu’à des fiches ambiguës.
Clés et intégrité référentielle
La clé primaire identifie chaque tuple de façon unique, par exemple avec un numéro client. Une clé étrangère reprend cette référence dans une autre table, comme l’identifiant du client enregistré avec chaque commande.
Selon Chris J. Date, la théorie relationnelle distingue les structures logiques des choix de mise en œuvre. En pratique, une contrainte d’intégrité référentielle peut empêcher la création d’une commande associée à un client inexistant.
Les liens entre tables s’adaptent aux besoins : un client peut passer plusieurs commandes, tandis qu’une commande renvoie à un client. Une relation plusieurs-à-plusieurs, comme livres et auteurs, se représente généralement par une table d’association.
Pour éviter les références fragiles, la conception s’appuie sur quelques règles :
- Choisir une clé primaire stable pour chaque table
- Déclarer les clés étrangères vers des identifiants existants
- Créer une table d’association pour les liens plusieurs-à-plusieurs
- Définir le traitement des valeurs absentes selon leur sens
Ces choix préviennent les doublons et les références orphelines, mais la qualité dépend aussi de la répartition des informations. C’est là que la normalisation devient utile.
| Relation entre entités | Exemple | Représentation usuelle |
|---|---|---|
| Un à un | Personne et dossier unique | Référence unique entre les deux tables |
| Un à plusieurs | Client et commandes | Clé étrangère dans Commandes |
| Plusieurs à plusieurs | Livres et auteurs | Table d’association dédiée |
| Référence obligatoire | Commande et client existant | Clé étrangère contrôlée |
Algèbre relationnelle, SQL et normalisation
Lorsque les liens sont fiables, il devient possible de rechercher et de transformer les données sans parcourir manuellement chaque table. L’algèbre relationnelle fournit le cadre logique de ces opérations, que SQL rend accessibles dans les systèmes courants.
Opérations relationnelles et requêtes SQL
Selon Codd, des opérations comme la sélection, la projection, l’union, la différence et le produit cartésien construisent de nouvelles relations. Une sélection filtre les commandes par date, tandis qu’une projection ne conserve que les colonnes nécessaires.
SQL exprime ces demandes sans obliger l’utilisateur à décrire chaque étape physique du traitement. Pour la librairie, une requête peut réunir les commandes et les clients afin d’afficher le nom associé à chaque achat.
La normalisation organise les tables afin de limiter les répétitions et les anomalies lors des modifications. Au lieu de recopier l’adresse d’un client dans chaque commande, la base conserve cette information dans Clients et la relie par une clé étrangère.
Quelques opérations éclairent le passage de la théorie à l’usage :
- La sélection conserve les tuples répondant à un critère
- La projection limite le résultat aux attributs nécessaires
- La jointure rapproche des lignes grâce à un attribut commun
- La normalisation réduit les répétitions évitables entre tables
Une normalisation excessive n’est pas un objectif en soi : les choix doivent répondre aux usages et aux contraintes du système. Les fondamentaux restent la clarté du schéma, la fiabilité des clés et la cohérence des règles appliquées.
Les sources théoriques éclairent ces principes sans remplacer les décisions propres à chaque projet. Les références fondatrices de Codd et les travaux de Chris J. Date permettent d’approfondir le modèle et ses usages.
Source : E. F. Codd, « A Relational Model of Data for Large Shared Data Banks », Communications of the ACM, 1970 ; Chris J. Date, Database in Depth: Relational Theory for Practitioners, O’Reilly, 2005.
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
