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

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

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

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.

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.

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

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.

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

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'è differenza pratica. Usa semplicemente la relazione che ha più senso dato il modo in cui vedi il tuo problema, come ha illustrato Devendra.

• --- 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....,

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