Une relation est établie entre deux tables de base de données lorsqu'une table a une clé étrangère qui 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 une clé étrangère fonctionne pour établir une relation
Passons en revue les bases des clés primaires et étrangères. Une clé primaire identifie de manière unique chaque enregistrement de la table. Il s'agit d'un type de clé candidate qui est généralement la première colonne d'une table et peut être généré automatiquement par la base de données pour garantir son caractère unique.
Une clé étrangère est une autre clé candidate (et non la clé primaire) utilisée pour lier un enregistrement à des données d'une autre table.
Par exemple, considérons 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 | Nom du cours | Teacher_ID |
|---|---|---|
| Course_001 | La biologie | Enseignant_001 |
| Course_002 | Math | Enseignant_001 |
| Course_003 | Anglais | Enseignant_003 |
Vous pouvez voir que la clé étrangère dans Courses correspond à une clé primaire dans Teachers:
| Teacher_ID | Nom de l'enseignant |
|---|---|
| Enseignant_001 | Carmen |
| Enseignant_002 | Véronique |
| Enseignant_003 | Jorge |
On peut dire que la clé étrangère Teacher_ID a aidé à établir une relation entre les tables des cours et des professeurs.
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:
Un par un: 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 associé à plusieurs enregistrements d'une autre table.
Considérons 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 ne comporterait aucune clé étrangère pointant vers la table Orders.
Plusieurs à plusieursRemarque: 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 non seulement de tables Clients et de commandes, mais également d’une table Produits.
Là encore, la relation entre la table Customers et Orders est un à plusieurs, mais considérons la relation entre la table Orders et Products. Une commande peut contenir plusieurs produits, et un produit peut être lié à plusieurs commandes: plusieurs clients peuvent soumettre une commande contenant certains des mêmes produits. Ce type de relation nécessite au minimum trois tables.
Quelles sont les relations de base de données importantes?
L'établissement de relations cohérentes entre les tables de base de données permet d'assurer l'intégrité des données et contribue à la normalisation de la base de données. Par exemple, que se passe-t-il si nous ne lions aucune table via une clé étrangère et combinons simplement les données des tables Courses et Enseignants, comme suit:
| Teacher_ID | Nom de l'enseignant | Cours |
|---|---|---|
| Enseignant_001 | Carmen | Biologie, maths |
| Enseignant_002 | Véronique | Math |
| Enseignant_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 (1NF), qui stipule que chaque cellule de tableau doit contenir une seule donnée discrète.
Ou peut-être avons-nous décidé d'ajouter simplement un deuxième enregistrement pour Carmen, afin de faire respecter 1NF:
| Teacher_ID | Nom de l'enseignant | Cours |
|---|---|---|
| Enseignant_001 | Carmen | La biologie |
| Enseignant_001 | Carmen | Math |
| Enseignant_002 | Véronique | Math |
| Enseignant_003 | Jorge | Anglais |
C'est toujours une conception faible, introduisant des duplications inutiles et ce qu'on appelle anomalies d'insertion de données , ce qui signifie simplement que cela 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 éditées, mais que la personne qui effectue l'édition des données ne réalise pas qu'il existe plusieurs enregistrements? La table contiendrait alors des données différentes pour le même individu, sans aucun moyen clair de l'identifier ou de l'éviter.
Le fait de diviser ce tableau en deux tableaux, Enseignants et Cours (comme illustré ci-dessus), crée la relation appropriée entre les données et contribue donc à assurer la cohérence et l'exactitude des données.
