Pourquoi pas de relations plusieurs-à-plusieurs?
J'apprends pour la première fois sur les bases de données et SQL. Dans le texte que je lis (Oracle 11g: SQL de Joan Casteel), il est écrit que "les relations plusieurs à plusieurs ne peuvent exister dans une base de données relationnelle". Je comprends que nous devons les éviter et je comprends comment créer une entité passerelle pour les éliminer, mais je tente de comprendre parfaitement la déclaration "ne peut pas exister".
Est-il réellement physiquement impossible d'avoir une relation plusieurs-à-plusieurs représentée?
Ou est-ce simplement très inefficace, car cela entraîne beaucoup de duplication de données?
Il me semble que ce soit le dernier cas et que l’entité passerelle minimise les données dupliquées. Mais peut-être que je manque quelque chose? Je n'ai pas trouvé de raison concrète (ni mieux encore d'exemple) qui explique pourquoi il faut éviter la relation plusieurs-à-plusieurs, que ce soit dans le texte ou ailleurs. J'ai cherché toute la journée et je n'ai trouvé que la même information répétée: "ne le faites pas, utilisez plutôt une entité passerelle". Mais j'aime demander pourquoi. :-)
Merci!
Pensez à une relation simple comme celle qui existe entre les auteurs et les livres. Un auteur peut écrire plusieurs livres. Un livre pourrait avoir de nombreux auteurs. Maintenant, sans une table de liaison pour résoudre la relation plusieurs à plusieurs, quelle serait l'alternative? Vous devez ajouter plusieurs colonnes Author_ID à la table Books, une pour chaque auteur. Mais combien en ajoutez-vous? 2? 3? dix? Quel que soit votre choix, vous vous retrouverez probablement avec un grand nombre de lignes éparses où beaucoup des valeurs de Author_ID sont NULL et il y a de bonnes chances que vous rencontriez un cas où vous n'avez besoin que "d'une seule" de plus. Vous modifiez donc constamment le schéma pour essayer de vous adapter ou vous imposez une restriction artificielle ("aucun livre ne peut avoir plus de 3 auteurs") pour forcer les choses à s'adapter.
Une véritable relation plusieurs-à-plusieurs impliquant deux tables est impossible à créer dans une base de données relationnelle. Je crois que c'est ce à quoi ils se réfèrent lorsqu'ils disent que cela ne peut pas exister. Afin de mettre en œuvre plusieurs méthodes, vous avez besoin d’une table intermédiaire composée de trois champs, un identifiant, un identifiant associé à la première table et un identifiant associé à la seconde.
La raison pour laquelle vous ne voulez pas de relations plusieurs à plusieurs, c'est comme si vous disiez qu'elles sont incroyablement inefficaces et que la gestion de tous les enregistrements liés à chaque côté de la relation peut être difficile, par exemple si vous supprimez un enregistrement d'un côté, ce qui se passe enregistrements dans la table relationnelle et la table de l'autre côté? Les suppressions en cascade sont une pente glissante, du moins à mon avis.
Normalement (jeu de mots), vous utiliseriez une table de liens pour établir plusieurs noms.
Comme décrit par Joe Stefanelli, supposons que vous ayez des auteurs et des livres
SELECT * from Author
SELECT * from Books
vous créeriez une table JOIN appelée AuthorBooks
Ensuite,
SELECT * from Author a JOIN AuthorBooks ab on a.AuthorId = ab.AuthorId JOIN Books b on ab.BookId = b.BookId
j'espère que cela pourra aider.
il dit que "les relations plusieurs à plusieurs ne peuvent pas exister dans une base de données relationnelle".
Je soupçonne que l'auteur est juste controversé. Techniquement, en langage SQL, il n’existe aucun moyen de déclarer explicitement une relation M-M. C'est un résultat émergent de la déclaration de multiples relations 1-M à la table. Cependant, il s'agit d'une approche courante pour obtenir le résultat d'une relation M-M et elle est absolument utilisée fréquemment dans les bases de données conçues sur des systèmes de gestion de base de données relationnelle.
Je n'ai pas trouvé de raison concrète (ou mieux encore d'exemple) qui explique pourquoi il faut éviter la relation plusieurs-à-plusieurs,
Ils devraient être utilisés là où ils sont appropriés, ce serait un moyen plus précis de le dire. Il y a des moments, tels que les exemples d'ouvrages et d'auteurs donnés par Joe Stafanelli, où toute autre solution serait inefficace et introduirait d'autres problèmes d'intégrité des données. Cependant, les relations M-M sont plus compliquées à utiliser. Ils ajoutent plus de travail de la part du concepteur d'interface graphique. Ils ne doivent donc être utilisés que s’il est judicieux de les utiliser. Si vous êtes hautement convaincu qu'une entité ne devrait jamais être associée à plus d'une entité d'une autre entité, limitez-le à tout prix à un 1-M. Par exemple, si vous suivez le statut d'un envoi, chaque envoi ne peut avoir qu'un seul statut à la fois. Il serait excessif de compliquer la conception et de ne pas avoir de sens logique de permettre à une expédition d’avoir plusieurs statuts.
Les relations plusieurs à plusieurs sont en fait très utiles et courantes. Par exemple, considérons un système de gestion de contacts qui vous permet de regrouper des personnes. Une personne peut être dans plusieurs groupes et chaque groupe peut avoir plusieurs membres.
La représentation de ces relations nécessite un tableau supplémentaire - c'est peut-être ce que dit réellement votre livre? Dans l'exemple que je viens de donner, vous auriez une table de personne (id, nom, adresse, etc.) et une table de groupe (id, nom de groupe, etc.). Ni ne contient d'informations sur qui est dans quel groupe; Pour ce faire, vous disposez d'une troisième table (appelez-la GroupePersonne) dans laquelle chaque enregistrement contient un ID de personne et un ID de groupe. Cet enregistrement représente la relation entre la personne et le groupe.
Besoin de trouver les membres d'un groupe? Votre requête pourrait ressembler à ceci (pour le groupe avec ID = 1):
SELECT Person.firstName, Person.lastName
FROM Person JOIN PersonGroup JOIN Group
ON (PersonGroup.GroupID = 1 AND PersonGroup.PersonID = Person.ID);
C'est correct. La relation plusieurs à plusieurs est divisée en plusieurs relations un à plusieurs. Donc, essentiellement, il n’existe AUCUN rapport entre plusieurs personnes!
Bien sûr, ils peuvent (et existent). Cela me semble être une déclaration de caisse à savon. Ils sont nécessaires à de nombreuses applications métier.
Fait correctement, ils ne sont pas inefficaces et ne possèdent pas non plus de données en double.
Jetez un coup d'oeil à FaceBook. Combien existe-t-il de nombreuses relations entre amis et amis d'amis? C’est un besoin commercial bien défini.
La déclaration selon laquelle "les relations plusieurs à plusieurs ne peuvent pas exister dans une base de données relationnelle". est manifestement faux.
Inventons une relation fictive (plusieurs relations entre plusieurs) entre les livres et la table des ventes. Supposons que vous achetiez des livres et que pour chaque livre acheté, vous devez générer un numéro de facture pour ce livre. Supposons également que le numéro de facture d'un livre peut représenter plusieurs ventes au même client (pas en réalité mais supposons). Nous avons de nombreuses relations entre les livres et les entités de vente ..__ Si tel est le cas, comment pouvons-nous obtenir des informations sur un seul livre étant donné que nous avons acheté 3 livres puisque tous les livres auraient en théorie le même numéro de facture? Cela pose le problème principal de l’utilisation d’une relation plusieurs à plusieurs, je suppose. Maintenant, si nous ajoutons une entité intermédiaire entre Livres et ventes de telle sorte que chaque livre vendu ne comporte qu'un seul numéro de facture, nous pouvons toujours identifier correctement chaque livre, quel que soit le nombre de livres achetés.
Bien sûr, la relation M-M existe bien dans les bases de données relationnelles et elles ont également la capacité de traiter à un certain niveau via des tables de pontage. Cependant, à mesure que le degré de relation M-M augmente, la complexité augmente, ce qui ralentit les cycles R-W et la latence. Il est recommandé d'éviter de telles relations M-M complexes dans une base de données relationnelle. Les bases de données Graph constituent la meilleure alternative et permettent de gérer les relations entre plusieurs objets. C'est pourquoi les sites de réseaux sociaux utilisent des bases de données Graph pour gérer les relations M-M entre utilisateur et amis, utilisateurs et événements, etc.