Differenza tra relazione uno-a-molti e molti-a-uno


117

Qual è la vera differenza tra relazione uno-a-molti e molti-a-uno? È solo invertito, tipo?

Non riesco a trovare nessun tutorial "buono e facile da capire" su questo argomento diverso da questo: SQL per principianti: Parte 3 - Relazioni con il database


1
Questa è una spiegazione perfetta: en.wikipedia.org/wiki/Many-to-many_(data_model)
RobertPitt

@RobertPitt in che modo l'articolo molti-a-molti è pertinente alla domanda? Probabilmente intendevi piuttosto en.wikipedia.org/wiki/One-to-many_(data_model)
TMG

Risposte:


111

Sì, è viceversa. Dipende da quale lato della relazione è presente l'entità.

Ad esempio, se un reparto può assumere per più dipendenti, il rapporto da reparto a dipendente è uno a molti (1 reparto impiega molti dipendenti), mentre il rapporto da dipendente a reparto è molti a uno (molti dipendenti lavorano in un reparto).

Maggiori informazioni sui tipi di relazione:

Relazioni database - Documentazione IBM DB2


2
Ho paura che non faccia scene! ( NON SICURO MA ) penso che l'ordine rappresenti la dipendenza! Non è vero ?? Ad esempio, un utente al ruolo può essere 1 a molti ma non molti a uno perché non è possibile ottenere riferimenti dell'utente che utilizza il ruolo! Ha senso?
Amanuel Nega


29

Da questa pagina sulla terminologia del database

La maggior parte delle relazioni tra le tabelle sono uno-a-molti.

Esempio:

  • Un'area può essere l'habitat di molti lettori.
  • Un lettore può avere molti abbonamenti.
  • Un giornale può avere molti abbonamenti.

Una relazione molti a uno è la stessa di uno-a-molti, ma da un punto di vista diverso.

  • Molti lettori vivono in un'area.
  • Molti abbonamenti possono essere di uno stesso lettore.
  • Molti abbonamenti sono per lo stesso giornale.

20

Qual è la vera differenza tra relazione uno-a-molti e molti-a-uno?

Esistono differenze concettuali tra questi termini che dovrebbero aiutarti a visualizzare i dati e anche possibili differenze nello schema generato che dovrebbero essere pienamente comprese. Per lo più, però, la differenza è di prospettiva.

In una relazione uno-a-molti , la tabella locale ha una riga che può essere associata a molte righe in un'altra tabella. Nell'esempio di SQL per principianti , uno Customerpuò essere associato a molti Orders.

Nella relazione molti-a-uno opposta , la tabella locale può avere molte righe associate a una riga in un'altra tabella. Nel nostro esempio, molti messaggi Orderpossono essere associati a uno Customer. Questa differenza concettuale è importante per la rappresentazione mentale.

Inoltre, lo schema che supporta la relazione può essere rappresentato in modo diverso nelle tabelle Customere Order. Ad esempio, se il cliente ha colonne ide name:

id,name
1,Bill Smith
2,Jim Kenshaw

Quindi per Orderassociare a a Customer, molte implementazioni SQL aggiungono alla Ordertabella una colonna che memorizza idgli associati Customer(in questo schema customer_id:

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

Nelle righe di dati sopra, se guardiamo la customer_idcolonna id, vediamo che Bill Smith(customer-id # 1) ha 2 ordini associati a lui: uno per $ 12,34 e uno per $ 7,58. Jim Kenshaw(customer-id # 2) ha solo 1 ordine per $ 158,01.

Ciò che è importante rendersi conto è che in genere la relazione uno-a-molti in realtà non aggiunge alcuna colonna alla tabella che è "uno". Il Customernon ha colonne aggiuntive che descrivono la relazione con Order. In effetti, Customerpotrebbe anche avere una relazione uno-a-molti con ShippingAddresse le SalesCalltabelle e tuttavia non avere colonne aggiuntive aggiunte alla Customertabella.

Tuttavia, per descrivere una relazione molti-a-uno, spesso idviene aggiunta una colonna alla tabella "molti" che è una chiave esterna alla tabella "uno" - in questo caso customer_idviene aggiunta una colonna alla Order. All'ordine # 10 associato per $ 12,34 a Bill Smith, assegniamo la customer_idcolonna Bill Smithall'id 1 di.

Tuttavia, è anche possibile che ci sia un'altra tabella che descrive la relazione Customere Order, in modo che non sia necessario aggiungere altri campi alla Ordertabella. Invece di aggiungere un customer_idcampo alla Ordertavola, ci potrebbero essere Customer_Ordertabella che contiene tasti sia per il Customere Order.

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

In questo caso, l' uno-a-molti e molti-a-uno sono tutti concettuali poiché non ci sono cambiamenti di schema tra di loro. Quale meccanismo dipende dallo schema e dall'implementazione SQL.

Spero che questo ti aiuti.


3
Il caso generale è chiamato dipendenza da inclusione. Un vincolo di chiave esterna è il tipo più comune di dipendenza dall'inclusione, ma non tutte le dipendenze dall'inclusione coinvolgono una chiave esterna. L'attributo o gli attributi comuni (il "riferimento") esistono sempre in entrambe le tabelle. Da un lato questi attributi sono chiamati chiave candidata. Dal lato "molti" possono essere una chiave esterna. I termini "uno-a-molti" o "molti-a-uno" potrebbero essere applicati a qualsiasi dipendenza dall'inclusione che coinvolge almeno una chiave candidata senza necessariamente implicare quale lato possa essere facoltativo.
nvogel

Interessante @sqlvogel. In Java, javax.persistence.OneToManydiversamente da ManyToOne. Stai dicendo che sono sinonimi o semplicemente che dipende dall'implementazione? La mia risposta è sbagliata?
Grey

2
La domanda riguarda i database relazionali e SQL, non Java. Forse hai ragione su Java.
nvogel

Lo stavo usando come esempio @sqlvogel. Stai dicendo che "uno-a-molti" e "molti-a-uno" sono sinonimi?
Gray

2
Sto dicendo che questi sono due modi per descrivere esattamente la stessa relazione ma da prospettive diverse. Allo stesso modo "A è un sottoinsieme di B" significa lo stesso che "B è un soprainsieme di A".
nvogel

4

Non c'è differenza. È solo una questione di linguaggio e preferenza riguardo al modo in cui affermare la relazione.


1
Certamente c'è una differenza, sia concettualmente che nello schema generato. Vedi la mia risposta: stackoverflow.com/a/37954280/179850
Gray

4
@Grigio. No non c'è. La tua risposta non è solo errata, confonde i principianti (quelli che fanno questa domanda).
PerformanceDBA

4

La risposta alla tua prima domanda è: entrambi sono simili,

La risposta alla tua seconda domanda è: uno-a-molti -> un MAN (tavolo MAN) può avere più di una moglie (tavolo WOMEN) molti-a-uno -> più di una donna ha sposato un UOMO.

Ora, se vuoi mettere in relazione questa relazione con due tabelle MAN e WOMEN, una riga della tabella MAN può avere molte relazioni con le righe nella tabella WOMEN. spero sia chiaro.


3

Esempio

Due tabelle con una relazione

SQL

In SQL esiste un solo tipo di relazione, si chiama Riferimento. (Il tuo front-end può fare cose utili o confuse [come in alcune risposte], ma questa è una storia diversa).

  • Una chiave esterna in una tabella (la referenc ing tabella)
    Referenze
    una chiave primaria in un'altra tabella (la referenc ndr tabella)
  • In termini SQL, Bar fa riferimento a Foo
    Not viceversa

    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
        )
  • Poiché Foo.Fooè una chiave primaria, è univoca, c'è solo una riga per ogni dato valore diFoo

  • Poiché Bar.Fooè un riferimento, una chiave esterna e non vi è alcun indice univoco, possono esserci molte righe per un dato valore diFoo
  • Quindi la relazione Foo::Barè uno-a-molti
  • Ora puoi percepire (guardare) la relazione al contrario, Bar::Fooè molti a uno
    • Ma non lasciarti confondere: per ogni Barriga, c'è solo una Fooriga a cui fa riferimento
  • In SQL, questo è tutto ciò che abbiamo. Questo è tutto ciò che è necessario.

Qual è la vera differenza tra uno a molti e molti a uno?

C'è solo una relazione, quindi non c'è differenza. La percezione (da una "estremità" o dall'altra "estremità") o la lettura a ritroso, non cambia la relazione.

Cardinalità

La cardinalità viene dichiarata prima nel modello dati, che significa Logico e Fisico (l'intento), e poi nell'implementazione (l'intento realizzato).

Cardinalità

Uno a zero a molti
In SQL questo (quanto sopra) è tutto ciò che è richiesto.

Uno a uno-a-molti
È necessaria una transazione per applicare quella nella tabella di riferimento.

Uno a zero a uno
Hai bisogno di Bar:

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

Uno a uno
È necessaria una transazione per applicare quella nella tabella di riferimento.

Molti a molti
Non esiste una cosa del genere a livello fisico (ricorda, c'è solo un tipo di relazione in SQL).

Ai primi livelli logici durante l'esercizio di modellazione, è conveniente tracciare tale relazione. Prima che il modello si avvicini all'implementazione, è meglio che venga elevato all'utilizzo solo di cose che possono esistere. Tale relazione viene risolta implementando una tabella associativa.

Molti a molti risolti


1
@Martijn Peters. Posso modificarlo per rispettare il codice di condotta. Ma hai anche rimosso (a) spiegazioni e (b) fatti evidenti nella realtà. Cosa devo fare con quelli?
PerformanceDBA

3
Trova un modo diverso per esprimere queste cose senza ricorrere a invezioni, insulti e insulti all'intelletto o alla condotta professionale di nessuno. Concentrati sulla tecnologia, non sulle persone che potrebbero o non avere torto.
Martijn Pieters

2

Uno-a-molti e Molti-a-uno sono simili nella molteplicità ma non nell'aspetto (cioè direzionalità).

La mappatura delle associazioni tra le classi di entità e le relazioni tra le tabelle. Esistono due categorie di relazioni:

  1. Molteplicità (termine ER: cardinalità)
    • Relazioni uno a uno : esempio marito e moglie
    • Relazioni uno-a-molti : esempio madre e figli
    • Relazioni molti-a-molti : esempio studente e soggetto
  2. Direzionalità : non influisce sulla mappatura ma fa la differenza su come possiamo accedere ai dati.
    • Relazioni unidirezionali : un campo o una proprietà di relazione che fa riferimento all'altra entità.
    • Relazioni bidirezionali : ogni entità ha un campo o una proprietà di relazione che fa riferimento all'altra entità.

Non c'è "direzionalità" in un database relazionale. Ogni relazione ha due "estremità": il riferimento (tabella a cui si fa riferimento) e il riferimento (tabella che fa riferimento). SQL / DML consente di fare riferimento a qualsiasi tabella, nel modo desiderato ... un lato ... l'altro lato ... entrambi i lati ... nessun lato.
PerformanceDBA

0

Non c'è differenza pratica. Usa semplicemente la relazione che ha più senso dato il modo in cui vedi il tuo problema, come ha illustrato Devendra.


Certamente c'è una differenza, sia concettualmente che nello schema generato. Vedi la mia risposta: stackoverflow.com/a/37954280/179850
Gray

3
@Grigio. No non c'è. La tua risposta non è solo errata, confonde i principianti (quelli che fanno questa domanda).
PerformanceDBA

0
  • --- Uno a molti --- Un genitore può avere due o più figli.
  • --- Molti a uno --- Quei 3 bambini possono avere un solo genitore.

    Entrambi sono simili. Questo può essere utilizzato appartiene alla necessità. Se vuoi trovare bambini per un particolare genitore, allora puoi andare con One-To-Many. oppure, se vuoi trovare genitori per due gemelli, potresti andare con Many-To-One. Allo stesso modo....,


-6

uno-a-molti ha la classe genitore che contiene n numero di figli, quindi è una mappatura di raccolta.

molti-a-uno ha n numero di figli contiene un genitore, quindi è una mappatura di oggetti


questa risposta è buona e avere informazioni aggiuntive non capisco perché è stato votato verso il basso, in un contesto unidirezionale uno a molti e molti a uno non fornirà la stessa qualità del codice a seconda della UX: se hai bisogno di ottenere una serie di dati correlati quindi uno a moltièpiù saggio se non avessi bisogno di un'istruzione select in cui qualche condizione va bene perché l'insieme è lì nella mappa, tuttavia se l'utente non ha bisogno di ottenere l'insieme di dati ed è interessato a ciascuna riga come unica istanza desiderata così Molti a uno è la scelta più saggia
Mohammed Housseyn Taleb

Può essere una buona risposta, ma non sono la stessa cosa: molti-a-uno ha una classe genitore contenente n numero di figli, uno-a-molti ha molti genitori per un figlio. In SQL potrebbe non fare la differenza in quanto la relazione molti-a-uno può essere omnidirezionale ma in un framework come Django, questo è un grosso problema, poiché non esiste una relazione uno-a-molti e la chiave esterna che si occupa della relazione Molti-a-Uno funziona naturalmente solo in una direzione, questa non può essere usata al contrario allo stesso modo.
iFunction
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.