Dépendances entre les tables d'une base de données

4.1 Présentation

En convertissant les tables de la base de données en tables régulières, vous pouvez maintenant analyser les relations entre elles. Le nombre d'éléments interagissant entre deux tables liées s'appelle la cardinalité. La cardinalité vous aide à contrôler l'efficacité avec laquelle vous avez partitionné vos données dans des tables.

Théoriquement, toutes les entités peuvent entretenir des relations entre elles, mais en pratique, il existe trois types de relations entre entités :

• Un par un
• Un à plusieurs
• plusieurs à plusieurs

4.2 Communication individuelle

S'il n'y a qu'une seule instance de l'entité A pour chaque instance de l'entité B, on dit qu'elles ont une relation un à un (souvent désignée par "1:1"). Sur les diagrammes ER, une telle relation est indiquée par une ligne avec une petite barre à chaque extrémité :

Une relation 1:1 indique généralement que, à moins que vous n'ayez une bonne raison de les séparer, il est préférable de combiner les données des deux tables en une seule.

Cependant, dans certaines circonstances, il est raisonnable d'utiliser des tables avec des relations 1:1. Si vos tables ont des champs avec des données facultatives, telles que des descriptions, et dans de nombreux cas, elles sont vides, il est logique de déplacer toutes les descriptions vers une table séparée, ce qui vous permettra de vous débarrasser des lacunes fréquentes et d'augmenter l'efficacité de votre base de données. .

Ensuite, afin de mapper correctement les données, vous devrez inclure au moins une colonne identique dans chaque table (il est préférable de choisir une clé primaire pour cela).

4.3 Relation un-à-plusieurs

Ce type de relation se produit lorsqu'un enregistrement dans une table est associé à plusieurs entités dans une autre. Par exemple, le même client peut passer plusieurs commandes ou un visiteur de la bibliothèque peut emprunter plusieurs livres en une seule visite. Les relations un-à-plusieurs (ou 1:M en abrégé) sont exprimées dans un diagramme utilisant la notation des pattes d'oie, comme illustré dans l'exemple ci-dessous :

Pour appliquer une relation 1:M lors de la planification d'une base de données, ajoutez simplement la clé primaire de la table "un" en tant qu'attribut à la table "plusieurs". Si la clé primaire se trouve dans une autre table, elle est appelée "clé étrangère". La table "un" est considérée comme la table parent, tandis que la table "plusieurs" est considérée comme la table enfant.

4.4 Relation plusieurs-à-plusieurs

Lorsque plusieurs entités d'une table peuvent être connectées à plusieurs entités d'une autre, elles sont considérées comme ayant une relation plusieurs à plusieurs (ou M:M). Par exemple, une telle relation existe entre les élèves et les classes, puisque chaque élève peut assister à plusieurs classes différentes, et, par conséquent, de nombreux élèves peuvent venir à chaque classe.

Sur le diagramme ER, ce type de relation s'affiche comme suit :

Malheureusement, il est impossible d'implémenter directement une telle relation dans la base de données. Par conséquent, il devra être divisé en deux relations un-à-plusieurs.

Pour ce faire, vous devrez créer une nouvelle entité entre les deux tables. Si une relation M:M est établie entre les ventes et les produits, la nouvelle entité pourra être appelée "produits vendus" car elle représentera le contenu de chaque vente.

Avec "marchandises vendues" et la table "ventes" et la table "marchandises" seront liées par le type 1:M. Dans différents modèles, ces entités intermédiaires sont appelées différemment - "tables de connexion", "entités associatives" ou "tables de nœuds".

Chaque entrée de table de liens relie deux entités différentes de tables adjacentes (et peut également contenir des informations supplémentaires). Par exemple, un tableau de liens entre les étudiants et les classes pourrait ressembler à ceci :

4.5 Obligatoire ou non ?

Une autre approche de l'analyse des liens consiste à déterminer laquelle des entités connectées est une condition préalable à la présence d'une autre entité. Le côté de liaison en option est marqué d'un cercle sur le coffre.

Par exemple, pour qu'un État ait son propre représentant à l'ONU, il doit exister sur la carte du monde, mais l'affirmation contraire sera fausse :

Deux entités peuvent être interdépendantes (c'est-à-dire que l'une ne peut exister sans l'autre).

Liens récursifs

Parfois, une table peut se référer à elle-même. Par exemple, une table d'employés pourrait avoir un attribut "manager" qui nous renverrait à un autre employé dans la même table. C'est la relation récursive.

Connexions supplémentaires

Les liens sont considérés comme redondants s'ils sont exprimés plus d'une fois. En règle générale, l'un d'entre eux peut être supprimé sans perdre d'informations importantes. Par exemple, si l'entité "élèves" est connectée à l'entité "professeurs" non seulement directement, mais aussi indirectement par le biais de "classes", il est logique de supprimer la relation entre les entités "élèves" et "professeurs". Cette décision est justifiée par le fait qu'il est possible d'affecter des élèves à des enseignants uniquement par le biais de classes.

4.6 Intégrité référentielle des données

Lors de la modification des clés primaires et étrangères, il convient d'observer un aspect tel que l'intégrité référentielle des données . Son idée principale est de garder deux tables dans une base de données qui stockent les mêmes données cohérentes.

L'intégrité des données représente des relations correctement construites entre les tables avec des liens corrects entre elles. Dans quels cas l'intégrité des données peut être violée :

• Anomalie de suppression . Se produit lorsqu'une ligne est supprimée de la table principale. Dans ce cas, la clé étrangère de la table dépendante continue de faire référence à la ligne supprimée de la table maître.
• Anomalie d'insertion . Se produit lorsqu'une ligne est insérée dans une table dépendante. Dans ce cas, la clé étrangère de la table dépendante ne correspond à la clé primaire d'aucune des lignes de la table maître.
• Anomalie de mise à jour . Avec une telle anomalie, plusieurs lignes d'une table peuvent contenir des données appartenant au même objet. Si vous modifiez les données d'une ligne, elles peuvent entrer en conflit avec les données d'une autre ligne.

Anomalie de suppression

Pour résoudre l'anomalie de suppression, la clé étrangère doit être définie sur l'une des deux contraintes suivantes :

Si une ligne d'une table dépendante nécessite nécessairement une ligne de la table maître, la clé étrangère est définie pour une suppression en cascade. Autrement dit, lorsqu'une ligne est supprimée de la table maître, la ou les lignes associées sont supprimées de la table dépendante.

Si une ligne d'une table dépendante n'autorise aucune relation avec une ligne de la table principale (c'est-à-dire qu'une telle relation est facultative), la clé étrangère est définie sur NULL lorsque la ligne associée est supprimée de la table principale. La colonne de clé étrangère doit être nullable.

Anomalie d'insertion

Pour résoudre l'anomalie d'insertion lors de l'ajout à une table de données dépendante, la colonne qui représente la clé étrangère doit être nullable. Et ainsi, si l'objet ajouté n'a aucun lien avec la table principale, alors la colonne de clé étrangère aura une valeur NULL.

Mettre à jour les anomalies

Pour résoudre le problème d'anomalie de mise à jour, la normalisation est appliquée, ce qui a été discuté précédemment.