Différence entre une relation un-à-plusieurs et plusieurs-à-un


117

Quelle est la vraie différence entre une relation un-à-plusieurs et plusieurs-à-un? C'est seulement inversé, en quelque sorte?

Je ne trouve aucun tutoriel `` bon et facile à comprendre '' sur ce sujet autre que celui-ci: SQL pour les débutants: Partie 3 - Relations avec les bases de données



@RobertPitt En quoi l'article plusieurs-à-plusieurs est-il pertinent par rapport à la question? Vous vouliez
TMG

Réponses:


111

Oui, c'est l'inverse. Cela dépend de quel côté de la relation l'entité est présente.

Par exemple, si un service peut employer pour plusieurs employés, alors, service à employé est une relation un à plusieurs (un service emploie plusieurs employés), tandis que la relation employé à service est plusieurs à un (de nombreux employés travaillent dans un même service).

Plus d'informations sur les types de relations:

Relations de base de données - Documentation IBM DB2


2
J'ai peur que cela ne fasse pas de scènes! ( PAS SÛR MAIS ) Je pense que l'ordre représente la dépendance! N'est-ce pas ?? Par exemple, un utilisateur à rôle peut être de 1 à plusieurs mais pas plusieurs à un car on ne peut pas obtenir les références de l'utilisateur qui utilise le rôle! Cela a-t-il du sens?
Amanuel Nega

Peut-être les relations de base de données maintenant?
fragorl

29

À partir de cette page sur la terminologie des bases de données

La plupart des relations entre les tables sont un-à-plusieurs.

Exemple:

  • Une zone peut être l'habitat de nombreux lecteurs.
  • Un lecteur peut avoir plusieurs abonnements.
  • Un journal peut avoir plusieurs abonnements.

Une relation plusieurs à un est la même que un à plusieurs, mais d'un point de vue différent.

  • De nombreux lecteurs vivent dans une région.
  • De nombreux abonnements peuvent concerner un seul et même lecteur.
  • De nombreux abonnements concernent un seul et même journal.

20

Quelle est la vraie différence entre une relation un-à-plusieurs et plusieurs-à-un?

Il existe des différences conceptuelles entre ces termes qui devraient vous aider à visualiser les données et également des différences possibles dans le schéma généré qui doivent être entièrement comprises. Cependant, la différence réside principalement dans la perspective.

Dans une relation un-à-plusieurs , la table locale a une ligne qui peut être associée à plusieurs lignes dans une autre table. Dans l'exemple de SQL pour les débutants , on Customerpeut être associé à plusieurs Orders.

Dans la relation plusieurs à un opposée , la table locale peut avoir plusieurs lignes associées à une ligne dans une autre table. Dans notre exemple, plusieurs Orders peuvent être associés à un Customer. Cette différence conceptuelle est importante pour la représentation mentale.

De plus, le schéma qui prend en charge la relation peut être représenté différemment dans les tables Customeret Order. Par exemple, si le client a des colonnes idet name:

id,name
1,Bill Smith
2,Jim Kenshaw

Puis pour que a Ordersoit associé à a Customer, de nombreuses implémentations SQL ajoutent à la Ordertable une colonne qui stocke le idde l'associé Customer(dans ce schéma customer_id:

id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2

Dans les lignes de données ci-dessus, si nous regardons la customer_idcolonne id, nous voyons que Bill Smith(customer-id # 1) a 2 commandes qui lui sont associées: une pour 12,34 $ et une pour 7,58 $. Jim Kenshaw(customer-id # 2) n'a qu'une seule commande pour 158,01 $.

Ce qu'il est important de réaliser, c'est qu'en général, la relation un-à-plusieurs n'ajoute en fait aucune colonne à la table qui est «un». Le Customern'a pas de colonnes supplémentaires décrivant la relation avec Order. En fait , la Customerforce aussi un à plusieurs avec ShippingAddresset SalesCalltables et encore ont pas des colonnes supplémentaires ajoutées à la Customertable.

Cependant, pour décrire une relation plusieurs-à-un, souvent une idcolonne est ajoutée à la table "plusieurs" qui est une clé étrangère à la table "un" - dans ce cas, une customer_idcolonne est ajoutée au Order. À la commande associée n ° 10 pour 12,34 $ à Bill Smith, nous attribuons la customer_idcolonne à Bill Smith's id 1.

Cependant, il est également possible qu'une autre table décrive la relation Customeret Order, de sorte qu'aucun champ supplémentaire ne doit être ajouté à la Ordertable. Au lieu d'ajouter un customer_idchamp à la Ordertable, il peut y avoir une Customer_Ordertable contenant des clés à la fois pour Customeret Order.

customer_id,order_id
1,10
1,11
2,12

Dans ce cas, le un-à-plusieurs et plusieurs-à-un sont tous conceptuels car il n'y a aucun changement de schéma entre eux. Le mécanisme dépend de votre schéma et de votre implémentation SQL.

J'espère que cela t'aides.


3
Le cas général est appelé une dépendance d'inclusion. Une contrainte de clé étrangère est le type de dépendance d'inclusion le plus courant, mais toutes les dépendances d'inclusion n'impliquent pas une clé étrangère. Le ou les attributs communs (la "référence") existent toujours dans les deux tableaux. Du côté «un», ces attributs sont appelés une clé candidate. Du côté «plusieurs», ils peuvent être une clé étrangère. Les termes «un à plusieurs» ou «plusieurs à un» pourraient être appliqués à toute dépendance d'inclusion qui implique au moins une clé candidate sans nécessairement impliquer de quel côté peut être facultatif.
nvogel

Intéressant @sqlvogel. En Java, le javax.persistence.OneToManydifférent du ManyToOne. Êtes-vous en train de dire qu'ils le sont ou simplement que cela dépend de la mise en œuvre? Ma réponse est-elle incorrecte?
Gray

2
La question concerne les bases de données relationnelles et SQL, pas Java. Peut-être avez-vous raison à propos de Java.
nvogel

Je l'utilisais comme exemple @sqlvogel. Êtes-vous en train de dire que «un-à-plusieurs» et «plusieurs-à-un» sont synonymes?
Gray

2
Je dis que ce sont deux façons de décrire exactement la même relation mais à partir de perspectives différentes. De la même manière que "A est un sous-ensemble de B" signifie la même chose que "B est un sur-ensemble de A".
nvogel

4

Il n'y a pas de différence. C'est juste une question de langue et de préférence quant à la manière dont vous définissez la relation.


1
Il y a certainement une différence, tant sur le plan conceptuel que sur le schéma généré. Voir ma réponse: stackoverflow.com/a/37954280/179850
Gris

4
@Gris. Non, il n'y en a pas. Votre réponse n'est pas seulement incorrecte, elle confond les débutants (ceux qui posent cette question).
PerformanceDBA

4

La réponse à votre première question est: les deux sont similaires,

La réponse à votre deuxième question est: un-à-plusieurs -> un HOMME (table MAN) peut avoir plus d'une femme (table WOMEN) plusieurs-à-un -> plus d'une femme a épousé un HOMME.

Maintenant, si vous voulez relier cette relation avec deux tables MAN et WOMEN, une ligne de table MAN peut avoir plusieurs relations avec des lignes de la table WOMEN. espérons que c'est clair.


3

Exemple

Deux tables avec une relation

SQL

En SQL, il n'y a qu'un seul type de relation, cela s'appelle une référence. (Votre interface peut faire des choses utiles ou déroutantes [comme dans certaines réponses], mais c'est une autre histoire.)

  • Une clé étrangère dans une table (la référe ing tableau)
    Références
    une clé primaire dans une autre table ( référe ed table)
  • En termes SQL, Bar fait référence à Foo
    Pas l'inverse

    CREATE TABLE Foo (
        Foo   CHAR(10)  NOT NULL, -- primary key
        Name  CHAR(30)  NOT NULL
        CONSTRAINT PK             -- constraint name
            PRIMARY KEY (Foo)     -- pk
        )  
    CREATE TABLE Bar (
        Bar   CHAR(10)  NOT NULL, -- primary key
        Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
        Name  CHAR(30)  NOT NULL
        CONSTRAINT PK                -- constraint name
            PRIMARY KEY (Bar),       -- pk
        CONSTRAINT Foo_HasMany_Bars  -- constraint name
            FOREIGN KEY   (Foo)      -- fk in (this) referencing table
            REFERENCES Foo(Foo)      -- pk in referenced table
        )
  • Puisqu'il Foo.Foos'agit d'une clé primaire, elle est unique, il n'y a qu'une seule ligne pour une valeur donnée deFoo

  • Puisqu'il Bar.Foos'agit d'une référence, d'une clé étrangère et qu'il n'y a pas d'index unique dessus, il peut y avoir plusieurs lignes pour une valeur donnée deFoo
  • Par conséquent, la relation Foo::Barest un-à-plusieurs
  • Maintenant, vous pouvez percevoir (regarder) la relation dans l'autre sens, Bar::Fooc'est plusieurs-à-un
    • Mais ne laissez pas cela vous embrouiller: pour chaque Barligne, il n'y a qu'une seule Fooligne référencée
  • En SQL, c'est tout ce que nous avons. C'est tout ce qui est nécessaire.

Quelle est la vraie différence entre une relation un à plusieurs et plusieurs à un?

Il n'y a qu'une seule relation, donc il n'y a pas de différence. La perception (d'une «extrémité» ou l'autre «extrémité») ou la lecture à l'envers, ne change pas la relation.

Cardinalité

La cardinalité est déclarée d'abord dans le modèle de données, ce qui signifie logique et physique (l'intention), puis dans l'implémentation (l'intention réalisée).

Cardinalité

Un à zéro à plusieurs
En SQL, c'est tout ce qui est requis.

Un à un-à-plusieurs
Vous avez besoin d'une transaction pour appliquer celle du tableau de référencement.

Un à zéro à un dont
vous avez besoin dans Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

Un à un
Vous avez besoin d'une transaction pour appliquer celle du tableau de référencement.

Beaucoup à plusieurs
Il n'y a rien de tel au niveau physique (rappelons qu'il n'y a qu'un seul type de relation en SQL).

Aux premiers niveaux logiques pendant l'exercice de modélisation, il est pratique de dessiner une telle relation. Avant que le modèle ne se rapproche de la mise en œuvre, il vaut mieux l'élever à n'utiliser que des éléments qui peuvent exister. Une telle relation est résolue en implémentant une table associative.

Plusieurs à plusieurs résolus


1
@Martijn Peters. Je peux le modifier pour me conformer au code de conduite. Mais vous avez également supprimé (a) l'explication et (b) les faits prouvés dans la réalité. Que dois-je faire à ce sujet?
PerformanceDBA

3
Trouvez une autre façon d'exprimer ces choses sans avoir recours aux élucubrations, aux insultes et aux dénigrements sur l'intellect ou la conduite professionnelle de quiconque. Concentrez-vous sur la technologie, pas sur les personnes qui peuvent ou non avoir tort.
Martijn Pieters

2

Un-à-plusieurs et plusieurs-à-un sont similaires en multiplicité mais pas en aspect (c'est-à-dire en directionnalité).

Le mappage des associations entre les classes d'entités et les relations entre les tables. Il existe deux catégories de relations:

  1. Multiplicité (terme ER: cardinalité)
    • Relations individuelles: exemple mari et femme
    • Relations un à plusieurs : exemple mère et enfants
    • Relations plusieurs à plusieurs : exemple d'élève et de sujet
  2. Directivité : n'affecte pas la cartographie mais fait la différence sur la façon dont nous pouvons accéder aux données.
    • Relations unidirectionnelles : champ de relation ou propriété faisant référence à l'autre entité.
    • Relations bidirectionnelles : chaque entité a un champ de relation ou une propriété qui fait référence à l'autre entité.

Il n'y a pas de «directionnalité» dans une base de données relationnelle. Chaque relation a deux "extrémités": la Référence (table référencée) et le référencement (table faisant le référencement). SQL / DML permet de référencer n'importe quelle table, comme vous le souhaitez… d'un côté… de l'autre… des deux côtés… pas de côtés.
PerformanceDBA

0

Il n'y a pas de différence pratique. Utilisez simplement la relation qui a le plus de sens étant donné la façon dont vous voyez votre problème comme l'a illustré Devendra.


Il y a certainement une différence, tant sur le plan conceptuel que sur le schéma généré. Voir ma réponse: stackoverflow.com/a/37954280/179850
Gris

3
@Gris. Non, il n'y en a pas. Votre réponse n'est pas seulement incorrecte, elle confond les débutants (ceux qui posent cette question).
PerformanceDBA

0
  • --- Un à plusieurs --- Un Les parents peuvent avoir deux enfants ou plus.
  • --- Plusieurs à un --- Ces 3 enfants peuvent avoir un seul parent.

    Les deux sont similaires. Cela peut être utilisé appartient au besoin. Si vous voulez trouver des enfants pour un parent en particulier, vous pouvez choisir One-To-Many. ou bien, vous voulez trouver des parents pour des jumeaux, vous pouvez choisir Many-To-One. Également....,


-6

one-to-many a la classe parent contient n nombre d'enfants donc c'est un mappage de collection.

plusieurs-à-un a n nombre d'enfants contient un parent donc c'est un mappage d'objet


cette réponse est bonne et avoir des informations supplémentaires ne comprend pas pourquoi elle a été votée à la baisse, dans un contexte unidirectionnel, un à plusieurs et plusieurs à un ne fourniront pas la même qualité de code en fonction de l'UX: Si vous avez besoin d'obtenir un ensemble de données liées donc un à plusieurs est plus sage si vous n'avez pas besoin d'une instruction de sélection où une condition est bonne car l'ensemble est là dans la carte, cependant si l'utilisateur n'a pas besoin d'obtenir l'ensemble de données et est intéressé par chaque ligne comme unique instance souhaitée, plusieurs à un est un choix plus sage
Mohammed Housseyn Taleb

C'est peut-être une bonne réponse, mais ce ne sont pas les mêmes: plusieurs-à-un a une classe parent contenant n nombre d'enfants, un-à-plusieurs a plusieurs parents à un enfant. En SQL, cela peut ne pas faire de différence car la relation plusieurs-à-un peut être omnidirectionnelle, mais dans un cadre tel que Django, c'est un problème majeur, car il n'y a pas de relation un-à-plusieurs et la clé étrangère qui traite de la relation plusieurs-à-un ne fonctionne naturellement que dans un sens, cela ne peut pas être utilisé dans l'autre sens de la même manière.
iFunction du
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.