Une relation est établie entre deux tables de base de données lorsqu'une table utilise une clé étrangère qui fait référence à la clé primaire d'une autre table. C'est le concept de base derrière le terme base de données relationnelle.
Comment fonctionne une clé étrangère pour établir une relation
Une clé primaire identifie de manière unique chaque enregistrement de la table. Il s'agit d'un type de clé candidate qui correspond généralement à la première colonne d'une table et qui peut être générée automatiquement par la base de données pour garantir son caractère unique. Une clé étrangère est une autre clé candidate (pas la clé primaire) utilisée pour lier un enregistrement à des données dans une autre table.
Par exemple, considérez ces deux tableaux qui identifient quel enseignant enseigne quel cours. Ici, la clé primaire de la table Courses est Course_ID. Sa clé étrangère est Teacher_ID:
| Course_ID | Course_Name | Teacher_ID |
|---|---|---|
| Cours_001 | Biologie | Teacher_001 |
| Cours_002 | Mathématiques | Teacher_002 |
| Cours_003 | Anglais | Teacher_003 |
Vous pouvez voir que la clé étrangère dans Courses correspond à une clé primaire dans Teachers:
| Teacher_ID | Nom_du_professeur |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Véronique |
| Teacher_003 | Jorge |
On peut dire que la clé étrangère Teacher_ID a aidé à établir une relation entre les tables Courses et Teachers.
Types de relations de base de données
À l'aide de clés étrangères ou d'autres clés candidates, vous pouvez implémenter trois types de relations entre les tables:
Individuel
Ce type de relation n'autorise qu'un seul enregistrement de chaque côté de la relation. La clé primaire concerne un seul enregistrement (ou aucun) dans une autre table. Par exemple, dans un mariage, chaque conjoint n'a qu'un seul autre conjoint. Ce type de relation peut être implémenté dans une seule table et n'utilise donc pas de clé étrangère.
Un à plusieurs
Une relation un-à-plusieurs permet à un seul enregistrement d'une table d'être lié à plusieurs enregistrements d'une autre table. Considérez une entreprise avec une base de données contenant des tables Clients et Commandes.
Un seul client peut acheter plusieurs commandes, mais une seule commande ne peut pas être liée à plusieurs clients. Par conséquent, la table Orders contiendrait une clé étrangère correspondant à la clé primaire de la table Customers, tandis que la table Customers n'aurait pas de clé étrangère pointant vers la table Orders.
Plusieurs à plusieurs
Il s'agit d'une relation complexe dans laquelle de nombreux enregistrements d'une table peuvent être liés à de nombreux enregistrements d'une autre table. Par exemple, notre entreprise a probablement besoin des tables Clients et Commandes, et probablement aussi d'une table Produits.
Encore une fois, la relation entre les tables Clients et Commandes est un-à-plusieurs, mais tenez compte de la relation entre les tables Commandes et Produits. Une commande peut contenir plusieurs produits et un produit peut être lié à plusieurs commandes puisque plusieurs clients peuvent soumettre une commande contenant certains des mêmes produits. Ce type de relation nécessite au minimum trois tables.
Pourquoi les relations de base de données sont-elles importantes ?
L'établissement de relations cohérentes entre les tables de la base de données permet de garantir l'intégrité des données, contribuant ainsi à la normalisation de la base de données. Par exemple, que se passe-t-il si nous ne relions aucune table via une clé étrangère et combinons à la place les données des tables Courses et Teachers, comme ceci:
| Teacher_ID | Nom_du_professeur | Cours |
|---|---|---|
| Teacher_001 | Carmen | Biologie, Mathématiques |
| Teacher_002 | Véronique | Mathématiques |
| Teacher_003 | Jorge | Anglais |
Cette conception est inflexible et viole le premier principe de normalisation de la base de données, la première forme normale, qui stipule que chaque cellule du tableau doit contenir une seule donnée discrète.
Ou peut-être avons-nous décidé d'ajouter un deuxième enregistrement pour Carmen, afin d'appliquer 1NF:
| Teacher_ID | Nom_du_professeur | Cours |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_001 | Carmen | Mathématiques |
| Teacher_002 | Véronique | Mathématiques |
| Teacher_003 | Jorge | Anglais |
Il s'agit toujours d'une conception faible, introduisant une duplication inutile et ce qu'on appelle des anomalies d'insertion de données, ce qui signifie qu'elle pourrait contribuer à des données incohérentes. Par exemple, si un enseignant a plusieurs enregistrements, que se passe-t-il si certaines données doivent être modifiées, mais que la personne effectuant la modification des données ne se rend pas compte que plusieurs enregistrements existent ? Le tableau contiendrait alors différentes données pour le même individu, sans aucun moyen clair de l'identifier ou de l'éviter.
Diviser ce tableau en deux tableaux, Enseignants et Cours, crée la relation appropriée entre les données et permet donc d'assurer la cohérence et l'exactitude des données.
