Dove collocare gli attributi di una relazione in una relazione non molti-a-molti?

Question

Dove collocare gli attributi di una relazione in una relazione non molti-a-molti?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Dì che ho la seguente relazione uno-a-molti:

Se non desidero memorizzare alcuna informazione sulla relazione, posso semplicemente inserire la chiave primaria di School come chiave esterna nella tabella Student .

Ma diciamo che voglio memorizzare la data in cui uno studente si è iscritto in una scuola. In questo caso, posso ancora inserire la chiave primaria di School come chiave esterna nella tabella Student accanto all'attributo date_of_registration ? o dovrei creare una nuova tabella che contenga school_id e student_id come chiavi esterne insieme all'attributo date_of_registration ?

Se posso utilizzare entrambi gli approcci, quali sono i vantaggi e gli svantaggi di ciascun approccio?

database database-design relational-database

posta Tom 07.02.2018 - 09:35

fonte

3 risposte

Leggi altre domande sui tag database database-design relational-database

Pattern per la modulazione di un oggetto basato su una variabile Livello di convalida della soluzione WebApi in cluster

score 1 · Answer 1

Secondo il tuo modello di dati, ogni studente ha esattamente una scuola. Ha senso da questo punto di vista mettere i metadati della relazione sullo studente, dato che ogni studente ha esattamente uno di questi. Puoi normalizzarlo ulteriormente per avere una tabella delle relazioni in mezzo, ma è difficile immaginare un caso d'uso che lo renda necessario.

In effetti, se risulta necessario avere più dati generali sullo studente, logicamente, avresti invece un modello 'personale' e lo 'studente' sarebbe il rapporto di 1 m tra persona e scuola.

score 0 · Answer 2

Immagino che la creazione di una nuova tabella / extra creerebbe dati extra per l'archiviazione e l'elaborazione extra quando si tratta di query / aggiornamenti. Se uno studente può registrarsi solo una volta per una scuola, se cambia scuola la tabella viene aggiornata, ma dipende interamente dallo studente, quando si iscrive alla scuola.

score 0 · Answer 3

Il tipo di entità Studente è l'intersezione tra Scuola e Persona, una relazione molti-a-molti. Come attualmente documentato, hai scelto di omettere la cronologia delle registrazioni e di tenere solo la registrazione corrente. In quanto tale - lo studente è 1 a 1 ed è OK piegare la persona allo studente come hai fatto tu. Se il tuo dominio problematico richiede una storia separata Persona (nome, dob ecc.) Da Student (registration_date).