Tradurre gli attributi delle relazioni dal diagramma ER in SQL

Question

Attualmente sto provando a familiarizzare con SQL per la prima volta, quindi sto lavorando con alcuni problemi. Ecco una specifica del database di esempio:

Studenti (nome, genere, corso) fanno progetti (titolo). Ogni progetto ha due supervisori (nome, genere, dipartimento). Tutti gli studenti fanno un progetto ma non tutti i progetti vengono presi. Più di uno studente può fare lo stesso progetto . Gli studenti incontrano regolarmente uno dei loro supervisori e questi incontri vengono registrati (data, ora, studente, supervisore, note).

Finora ho ottenuto un diagramma ER redatto che mi sembra corretto:

posso ottenere le nozioni di base (ad esempio, la creazione di un tavolo per studenti, ecc), ma sto avendo difficoltà a capire come rappresentare le relazioni, in particolare la relazione delle riunioni, e come rappresentarla e i suoi attributi in SQL. Dovrei invece creare un'entità 'incontri'?

Answer 1

Sì, è necessario creare un'entità Meeting per rappresentare la relazione molti a molti tra Student e Supervisor. In esso puoi fare riferimento a quelle tabelle utilizzando chiavi esterne corrispondenti alle rispettive tabelle. In SQL può sembrare qualcosa di simile:

Create table Meeting { 
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, 
student_id INT NOT NULL, 
supervisor_id INT NOT NULL, 
//rest of the fields... 
FOREIGN KEY (student_id) REFERENCES Student(id) 
FOREIGN KEY (supervisor_id) REFERENCES Supervisor(id) 
} 

Si potrebbe anche fare la stessa cosa per il Supervise tra il Project e Supervisor. Potresti anche usare qualcosa chiamato una chiave composita sul tuo tavolo Meeting, immagino che dipenda da preferenze personali, di solito lo faccio in questo modo quando rappresento molte a molte relazioni. Non sto dicendo che questa è la sintassi che userai, dipende dal tuo database, questo è stato solo un esempio per indicarti la giusta direzione. Spero che sia d'aiuto.

Anche per il diagramma (sto solo supponendo che questo sia per un corso), potresti voler esaminare un software come visio o paradigma visivo per creare il tuo diagramma ER. Mentre la maggior parte delle persone sarà in grado di capire il tuo diagramma corrente, non è corretto modellare.

Per divertimento ho fatto uno schema basato sulle vostre tavole:

si vorrebbe un'entità tra Supervisor e Project se sono un molti a molti. Questo è chiamato associative entity. Ho etichettato il mio SupervisorProject solo così sono un po 'più chiari.

Modifica trascurato il fatto che studenti e progetto è stato un molti a uno, fissa che, mi spiace.

Answer 2

In risposta a Cohagen this stackoverflow post si suggerisce che molte o molte relazioni come Supervise possono essere rappresentate mantenendo la tabella delle relazioni anche se non ha attributi. Al contrario, la tabella Do si trova tra una relazione molti a uno e non ha attributi, quindi possiamo eliminarla e aggiungere semplicemente un riferimento a una chiave esterna alla tabella del progetto negli studenti.