Différence entre les relations un à un et un à plusieurs dans la base de données
Il s’agit probablement d’une question élémentaire (idiote), mais lorsqu’il existe une relation un-à-un dans une base de données, l’autre table a un ID de clé étrangère (dans cet exemple). Et dans une relation un-à-plusieurs, la table contient de nombreuses clés étrangères.
Mais la base de données ne sait pas s'il s'agit d'une relation un à un ou un à plusieurs, n'est-ce pas? Les relations que je crée dans un diagramme ER servent uniquement à indiquer où doivent figurer les clés étrangères lors de la création des tables.
Je ne comprends pas tout à fait l’idée des relations, même si j’ai lu de nombreux tutoriels à ce sujet.
Merci d'avance.
En un sens, toutes les relations dont nous parlons ne sont pas connues de la base de données, ce sont des constructions que nous avons inventées pour mieux comprendre comment concevoir les tables.
La grande différence en termes de structure de table entre un-à-un et un-à-plusieurs est qu’il est possible (mais pas nécessaire) d’avoir une relation bidirectionnelle, ce qui signifie que le tableau A peut avoir une clé étrangère dans la table B, et la table B peut avoir une clé étrangère dans l'enregistrement associé dans la table A. Cela n'est pas possible avec une relation un à plusieurs.
Les relations un-à-un associent un enregistrement dans une table à un enregistrement unique dans l'autre table. Les relations un-à-plusieurs associent un enregistrement d'une table à plusieurs enregistrements de l'autre table.
Pour activer la relation un à un, vous devez ajouter une contrainte unique à la clé étrangère. Il n'est pas possible d'avoir deux clés étrangères pour chaque table car il sera impossible de créer des enregistrements.
J'ai du mal à comprendre quelle est la question.
Votre analyse est en grande partie correcte, en ce sens que si vous avez 2 tables et que table2 a une clé étrangère pour la table 1, il peut s'agir d'un tête-à-un ou de plusieurs-un.
Votre phrase "Et dans une relation un à plusieurs, la table contient de nombreuses clés étrangères."
La table du côté "Plusieurs" contient toujours une colonne qui est une clé étrangère, sa juste que plusieurs lignes peuvent avoir la même valeur de clé étrangère (plusieurs lignes pointent vers un seul parent).
Notez également que vous pouvez placer la clé étrangère sur la table parent, à l'enfant, au lieu de l'inverse. De cette façon, vous pouvez empêcher les un-à-plusieurs si vous voulez le faire. Notez également que de cette manière, plusieurs parents peuvent partager un enfant, ce qui peut être ou ne pas être ce que vous voulez.
L'équivalent au niveau base de données 1: 1 vs. 1: m est d'avoir un index unique sur la colonne de clé étrangère. Notez que cela ne fonctionnera que pour 1: 1, PAS 1: 0..1, car null est pris en compte lors de l'évaluation de l'unicité. Il existe des solutions de contournement pour cette restriction, mais c'est tout au niveau de base.
De la même manière, par exemple, un produit n'a qu'un code de produit, il s'agit donc d'une relation un à un ( produit <-> ABC123 ), mais un client peut acheter plusieurs produits. C'est donc une relation un à plusieurs ( personne <- >>> produit ).
eh bien, vous avez raison, cette relation est importante pour vous, mais pas pour DB elle-même. Lorsque vous disposez de deux tables, l’une avec vos informations de base et l’autre avec vos informations détaillées, vous ne pouvez pas mapper vos données sur une autre personne.
Maintenant, ajoutez la troisième table "villes" et l’un de vos points d’information à la ville dans laquelle vous vivez - c’est un exemple de one-to-many (une ville peut être utilisée et devrait être utilisée par de nombreuses personnes).
one-to-many/one-to-one montre simplement comment vos tables interagissent. Et tout le temps, vous voulez "enregistrer" des lignes/colonnes dans une table sans les dupliquer, vous utiliserez une relation un-à-plusieurs avec une autre table. Ou plusieurs à plusieurs :)
Supposons que vous avez une table avec deux attributs A et B. Si A est une clé candidate et que B ne l'est pas, la relation entre A et B est de 1 à plusieurs. Si A et B sont des clés candidates, la relation est de 1 à 1.
Étant donné les tableaux A et B si
- A et B ont une relation stricte de 1 à 1
- Pour chaque instance B, il y aura toujours une instance A
La meilleure approche consiste à faire de la clé primaire de B également une clé étrangère référençant A. Elle est également appelée "héritage de table par type" et la relation "est un". Il existe d'autres moyens d'appliquer une clé étrangère unique, mais l'utilisation de la clé primaire rend la relation plus claire dans le schéma et dans les diagrammes ER.
Bien sûr, il y a toujours d'autres scénarios, et si votre conception ne répond pas aux deux critères ci-dessus, vous devrez utiliser une autre approche.