rapporto uno a molti nel database - concetto di progetto

Question

Una relazione uno a molti tra due tabelle dovrebbe essere implementata con due o tre tabelle? Per esempio dovremmo avere:

author(id,otherAttributtes) 
books(id,authorid,otherAttributes) 

o

author(id,otherAttributtes) 
    books(id,otherAttributes) 
    authorConnectsBooks(authorid,booksid) 

mi piace di più il primo approccio, ma ho visto il secondo e in applicazioni più complesse un sacco di volte. C'è qualche svantaggio per il primo metodo, o è solo personale quale strada seguire?

Answer 1

Il primo esempio mostra una relazione uno a molti, mentre la seconda mostra una relazione molte a molte.

Esempio Diciamo che usiamo il primo esempio

Author 
AuthorID 

Book 
BookID 
AuthorID 

Come ti rappresentare che sia Jane e Jon ha scritto il libro "StackOverflow per divertimento"? In questa tabella delle relazioni non puoi, hai espresso che un autore può scrivere molti libri. Quindi, o Jane ha scritto o Jon ha scritto. Se solo uno di loro ha scritto i libri, potresti usare questo tipo di relazione. Tuttavia, se vuoi dimostrare che entrambi hanno scritto questo libro, hai bisogno di una relazione molte a molte.

Ora, usando questa stessa analogia di Jane e Jon, puoi rappresentare entrambi gli autori di questo libro usando il tuo secondo esempio: molti a molti rapporti.

---

Consente di utilizzare StackOverflow come esempio a partire da un uno a molti e che termina con una relazione molti a molti:

Authors 
Joel 
Jeff 

Books 
Stackoverflow Joel 

povero Jeff, che non è accreditato con StackOverflow dall'esempio precedente ... così abbiamo hanno bisogno di risolvere questo:

Author 
Joel 
Jeff 

Books 
Stackoverflow 

AuthorBooks 
Stackoverflow Jeff 
Stackoverflow Joel 

Ora tutti sono felici ...

Answer 2

Se la relazione è in realtà uno a molti, non c'è bisogno di una tabella di collegamento (authorConnectsBooks nell'esempio). Nel tuo esempio, tuttavia, non hai una relazione uno-a-molti poiché un autore può scrivere molti libri e un libro può essere scritto da molti autori. Nel tuo esempio, hai effettivamente una relazione molti-a-molti. Se hai effettivamente una relazione molti-a-molti, allora hai bisogno di una tabella di collegamento (authorConnectsBooks nell'esempio).

Answer 3

uno a molti è due tabelle.

il secondo è molti a molti.

Authors 
1 Larry Niven 
2 Jerry Pournelle 

Books 
1 Integral Trees 
2 King David's Spaceship 
3 The Mote in God's eye 

AuthorsBooks 
1 1 
2 2 
1 3 
2 3 

Answer 4

Una relazione uno-a-molti deve essere implementata con 2 tabelle.

Ma la relazione che si propone nel proprio esempio (tra Autori e Libri) non è uno a molti, è molti-a-molti.

"Un autore può scrivere molti libri e un libro può essere scritto da uno o più autori".

E una relazione molti-a-molti dovrebbe essere implementata con 3 tabelle.

Buona giornata.

Answer 5

Come tutti hanno affermato, il primo è un rapporto uno a molti in cui non è necessario il tavolo supplementare. Solo due tavoli dovrebbero funzionare. Ma nel secondo caso, dal momento che è di molti a molti realtionship, sarà necessario aggiungere una tabella aggiuntiva nota come Junction o la tabella di riferimento incrociato perché la maggior parte dei sistemi di gestione del database supportano solo le relazioni uno-a-molti, è necessario implementare tali relazioni manualmente tramite una terza tabella di giunzione. La chiave primaria della tabella di giunzione viene normalmente formata utilizzando le chiavi primarie delle tabelle che connette. Ecco una pagina wiki che spiega lo stesso esempio esatto che lei ha chiesto:

LINK