In che modo la progettazione di database aiuta a organizzare insegnanti, lezioni e studenti?

Un investimento in conoscenza paga il miglior interesse.

Benjamin Franklin

Nel mondo moderno, l'istruzione è onnipresente. Ora più che mai, svolge un ruolo importante nella nostra società. È così importante, infatti, che molti di noi continuino la propria istruzione anche dopo aver terminato la scuola o l'università.

Tutti abbiamo sentito parlare di apprendimento permanente, educazione non formale e laboratori per tutte le età. Questi metodi differiscono in molti modi dall'istruzione formale, ma hanno anche cose in comune. Ci sono classi, lezioni, insegnanti e studenti. E proprio come in un ambiente tradizionale, vorremo tenere traccia del programma delle lezioni, dei dati sulle presenze e dei risultati dell'insegnante o degli studenti. Come possiamo progettare un database per soddisfare queste esigenze? Questo è ciò di cui parleremo in questo articolo.

Presentazione del nostro modello di database sull'istruzione

Il modello presentato in questo articolo ci consente di memorizzare dati su:

• lezioni/lezioni
• docenti/docenti
• studenti
• frequenza alle lezioni
• Risultati di studenti / docenti

Potremmo anche utilizzare questo modello come orario scolastico, per altre attività di gruppo (lezioni di nuoto, laboratori di danza) o anche per attività individuali come il tutoraggio. C'è ancora molto spazio per miglioramenti, come la memorizzazione dei dati sulla posizione della classe o la durata del workshop; li tratteremo nei prossimi articoli.

Iniziamo con i nostri elementi base del database Education:le tabelle.

I tre grandi:studenti, insegnanti e tabelle di classe

Lo student , instructor e class le tabelle costituiscono il cuore del nostro database.

Lo student la tabella, mostrata sopra, viene utilizzata per memorizzare i dati di base sugli studenti, ma può essere ampliata in base alle esigenze specifiche. Ad eccezione dei tre attributi di contatto, tutti gli attributi nella tabella sono obbligatori:

• first_name – il nome dello studente
• last_name – il cognome dello studente
• birth_date – la data di nascita dello studente
• contact_phone – il numero di telefono dello studente
• contact_mobile – il numero di cellulare dello studente
• contact_mail – l'indirizzo email dello studente
• category_id – è un riferimento alla category Catalogare. Con questa struttura, siamo limitati a una sola categoria per studente. Funziona nella maggior parte dei casi, ma in alcune situazioni potrebbe essere necessario spazio per elencare più categorie. Come puoi vedere, aggiungendo una relazione molti-a-molti che collega lo student tabella con la category dizionario risolve questo problema. In questo scenario, tuttavia, dovremo scrivere query piuttosto complesse per gestire i nostri dati.

Visto che ne abbiamo parlato, andiamo avanti e discutiamo della category tabella qui.

Questa tabella è un dizionario utilizzato per raggruppare gli studenti in base a determinati criteri. Il first_name l'attributo è l'unico dato nella tabella (oltre a id , la chiave primaria) ed è obbligatorio. Un insieme di valori che possono essere memorizzati qui è lo stato occupazionale dello studente:"studente", "occupato", "disoccupato" e "pensionato". Potremmo anche utilizzare altri set in base ad alcuni criteri molto specifici, come "ama lo yoga", "ama l'escursionismo", "ama andare in bicicletta" e "non gli piace niente".

Il instructor la tabella contiene l'elenco di tutti gli istruttori/docenti nell'organizzazione. Gli attributi nella tabella sono:

• first_name – il nome dell'istruttore
• last_name – il cognome dell'istruttore
• title – il titolo dell'istruttore (se presente)
• birth_date – la data di nascita dell'istruttore
• contact_phone – il numero di telefono dell'istruttore
• contact_mobile – il numero di cellulare dell'insegnante
• contact_mail – l'indirizzo email dell'insegnante

Il title e tutti e tre i contact gli attributi non sono obbligatori.

Lo student tavolo e instructor table condividono una struttura simile, ma c'è un'altra possibilità per organizzare queste informazioni. Un secondo approccio sarebbe quello di avere una person tabella (che memorizza tutti i dati di dipendenti e studenti) e ha una relazione molti-a-molti che ci dice tutti i ruoli assegnati a quella persona. Il vantaggio più importante del secondo approccio è che memorizzeremo i dati solo una volta. Se qualcuno è un istruttore in una classe e uno studente in un'altra, apparirà solo una volta nel database, ma con entrambi i ruoli definiti.

Perché abbiamo selezionato l'approccio a due tabelle per il nostro modello di database educativo? In generale, studenti e docenti si comportano in modo diverso, sia nella vita reale che nel nostro database. Per questo motivo, potrebbe essere saggio archiviare i propri dati separatamente. Possiamo trovare altri modi per unire le informazioni sulla stessa persona che appaiono in entrambe le tabelle (ad es. coppia di query di inserimento/aggiornamento basate su un ID esterno, come un numero di previdenza sociale o una partita IVA).

La class table è un catalogo che contiene dettagli su tutte le classi. Possiamo avere più istanze di ogni tipo di classe. Gli attributi nella tabella sono i seguenti (tutti obbligatori tranne end_date ):

• class_type_id – è un riferimento al class_type dizionario.
• first_name – è un nome breve della classe.
• description – questa descrizione è più specifica di quella nel class_type tabella.
• start_date – la data di inizio del corso.
• end_date – la data di fine della lezione. Non è obbligatorio perché potremmo non conoscere sempre in anticipo la data di fine esatta di ogni lezione.
• completed – è un valore booleano che indica se tutte le attività di classe pianificate sono terminate. Questo è utile quando abbiamo raggiunto il end_time pianificato per una classe ma altre attività della classe devono ancora essere completate.

Il class_type table è un semplice catalogo, destinato a memorizzare le informazioni di base sulle lezioni o lezioni offerte agli studenti. Potrebbe contenere valori come "Lingua inglese (gruppo)", "Lingua polacca (gruppo)", "Lingua croata (gruppo)", "Lingua inglese (di persona)" o "Lezioni di ballo". Ha solo due attributi obbligatori:name e description , entrambi non necessitano di ulteriori spiegazioni.

Il class_schedule la tabella contiene orari specifici per lezioni e lezioni. Tutti gli attributi nella tabella sono obbligatori. Il class_id l'attributo è un riferimento alla class tabella, mentre start_time e end_time sono gli orari di inizio e fine di quella specifica lezione.

Chi c'è qui? Tavoli relativi alle presenze

Il attend la tabella memorizza le informazioni su quale studente ha frequentato quale classe e il risultato finale. Gli attributi nella tabella sono:

• student_id – è un riferimento allo student tabella
• class_id – è un riferimento alla class tabella
• class_enrollment_date – è la data in cui lo studente ha iniziato a frequentare quel corso
• class_drop_date – la data in cui lo studente ha lasciato la classe. Questo attributo avrà valore solo se lo studente ha abbandonato la lezione prima della data di fine della lezione. In tal caso, il drop_class_reason_id anche il valore dell'attributo deve essere impostato.
• drop_class_reason_id – è un riferimento al drop_class_reason tabella
• attendance_outcome_id – è un riferimento al attendance_outcome tabella

Tutti i dati tranne class_drop_date e drop_class_reason_id è obbligatorio. Questi due verranno riempiti se e solo se uno studente abbandona la classe.

Il drop_attendance_reason table è un dizionario che contiene i vari motivi per cui uno studente potrebbe abbandonare un corso. Ha un solo attributo, reason_text , ed è obbligatorio. Un esempio di insieme di valori potrebbe includere:"malattia", "interesse perso", "non ha abbastanza tempo" e "altri motivi".

Il attendance_outcome la tabella contiene le descrizioni dell'attività degli studenti in un determinato corso. Il outcome_text è l'unico attributo nella tabella ed è obbligatorio. Un insieme di valori possibili è:"in corso", "completato con successo", "completato parzialmente" e "classe non completata".

Chi comanda? Tabelle relative alla didattica

Il teach , drop_teach_reason e teach_outcome le tabelle utilizzano la stessa logica di attend , drop_attendance_reason e attendance_outcome tavoli. Tutte queste tabelle memorizzano i dati sulle attività relative al corso degli istruttori.

Il teach La tabella viene utilizzata per memorizzare informazioni su quale istruttore sta insegnando a quale classe. Gli attributi nella tabella sono:

• instructor_id – è un riferimento al instructor tabella.
• class_id – è un riferimento alla class tabella.
• start_date – è la data in cui l'insegnante ha iniziato a lavorare su quella classe.
• end_date – è la data in cui l'istruttore ha smesso di lavorare su quella classe. Non è obbligatorio perché non possiamo sapere in anticipo se l'insegnante insegnerà fino alla data di fine della lezione.
• drop_teach_reason_id – è un riferimento al drop_teach_reason tavolo. Non è obbligatorio perché l'insegnante non può abbandonare il corso.
• teach_outcome_id – è un riferimento al teach_outcome_reason tabella.

Il drop_teach_reason table è un semplice dizionario. Contiene una serie di possibili spiegazioni del motivo per cui l'istruttore ha terminato l'insegnamento prima della data di fine. C'è un solo attributo obbligatorio:reason_text . Potrebbe trattarsi di "malattia", "trasferito a un altro progetto/lavoro", "abbandono" o "altro motivo".

Il teach_outcome la tabella descrive il successo dell'istruttore in un particolare corso. Il outcome_text è l'unico attributo della tabella ed è obbligatorio. Possibili valori per questa tabella potrebbero essere:"in corso", "completato con successo", "completato parzialmente" e "non ha completato la lezione di insegnamento".

La student_presence La tabella viene utilizzata per memorizzare i dati sulla presenza degli studenti per una lezione specifica. Si può presumere che per ogni lezione il docente annoti la presenza e/o l'assenza per tutti gli studenti. Gli attributi nella tabella sono:

• student_id – è un riferimento allo student tabella
• class_schedule_id – è un riferimento al class_schedule tabella
• present – è un contrassegno booleano indipendentemente dal fatto che lo studente sia presente o meno a lezione

Potremmo monitorare la presenza degli studenti in una classe specifica con una query come quella che segue (supponendo che @id_class contenga l'ID classe che vogliamo).

SELECT
	a.id, 
	CONCAT(a.first_name, ' ', a.last_name) AS student_name,
	a.number_total, 
	CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS percentage,
	a.attendance_outcome
FROM
(
SELECT 
	student.id, 
	student.first_name, 
	student.last_name, 
	SUM(CASE WHEN student_presence.present = True THEN 1 ELSE 0 END) AS number_present,
	COUNT(DISTINCT class_schedule.id) AS number_total,
	attendance_outcome.outcome_text AS attendance_outcome
FROM class
	INNER JOIN attend ON class.id = attend.class_id
	INNER JOIN student ON attend.student_id = student.id
	LEFT JOIN class_schedule ON class_schedule.class_id = class.id
	LEFT JOIN student_presence ON student_presence.student_id = student.id AND student_presence.class_schedule_id = class_schedule.id
	LEFT JOIN attendance_outcome ON attendance_outcome.id = attend.attendance_outcome_id
WHERE class.id = @id_class
GROUP BY 
	student.id, 
	student.first_name, 
	student.last_name, 
	attendance_outcome.outcome_text
) a  

La tabella “instructor_presence” utilizza la stessa logica della tabella “student_presence”, ma qui vogliamo concentrarci sugli istruttori. Gli attributi nella tabella sono:

• instructor_id – è un riferimento al instructor tabella
• class_schedule_id – è un riferimento al class_schedule tabella
• present – è un valore booleano che rappresenta se l'insegnante è presente a lezione o meno

Potremmo utilizzare la query seguente per monitorare l'attività dell'insegnante in classe:

SELECT
	a.id, 
	CONCAT(a.first_name, ' ', a.last_name) AS instructor_name,
	a.number_total,
	CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS percentage,
	a.teach_outcome
FROM
(
SELECT 
	instructor.id, 
	instructor.first_name, 
	instructor.last_name, 
	SUM(CASE WHEN instructor_presence.present = True THEN 1 ELSE 0 END) AS number_present,
	COUNT(DISTINCT class_schedule.id) AS number_total,
	teach_outcome.outcome_text AS teach_outcome
FROM class
	INNER JOIN teach ON class.id = teach.class_id
	INNER JOIN instructor ON teach.instructor_id = instructor.id
	LEFT JOIN class_schedule ON class_schedule.class_id = class.id
	LEFT JOIN instructor_presence ON instructor_presence.instructor_id = instructor.id AND instructor_presence.class_schedule_id = class_schedule.id
	LEFT JOIN teach_outcome ON teach_outcome.id = teach.teach_outcome_id
WHERE class.id = @id_class
GROUP BY 
	instructor.id, 
	instructor.first_name, 
	instructor.last_name, 
	teach_outcome.outcome_text
) a 

Ora, concludiamo discutendo le tabelle dei referenti.

Chi possiamo chiamare? Tabelle dei referenti

Nella maggior parte dei casi, non è necessario memorizzare le informazioni di contatto di emergenza (ad esempio, in caso di emergenza, contattare questa persona). Tuttavia, questo cambia quando insegniamo ai bambini. Per legge o per consuetudine, dobbiamo avere un referente per ogni bambino a cui insegniamo. Nelle nostre tabelle modello – contact_person , contact_person_type e contact_person_student – dimostriamo come è possibile farlo.

Il contact_person la tabella è un elenco di persone che sono legate agli studenti. Naturalmente, non è necessario elencare tutti i parenti; per lo più avremo uno o due contatti per studente. Questo è un buon modo per trovare "chi chiamerai" quando lo studente ha bisogno o vuole partire presto. Gli attributi nella tabella sono:

• first_name – è il nome della persona di contatto
• last_name – è il cognome della persona
• contact_phone – è il numero di telefono della persona
• contact_mobile – è il numero di cellulare della persona
• contact_mail – è l'indirizzo email della persona

I recapiti non sono obbligatori, sebbene siano molto utili.

Il contact_person_type table è un dizionario con un unico attributo obbligatorio:type_name . Esempi di valori memorizzati in questa tabella sono:"madre", "padre", "fratello", "sorella" o "zio".

Il contact_person_student table è una relazione molti-a-molti che collega le persone di contatto e il loro tipo con gli studenti. Gli attributi nella tabella sono (tutti obbligatori):

• contact_person_id – è un riferimento al contact_person tabella
• student_id – è un riferimento allo student tabella
• contact_person_type_id – è un riferimento al contact_person_type tabella

Vale la pena ricordare che questa relazione molti-a-molti collega tre tabelle insieme. La coppia di attributi contact_person_id e student_id viene utilizzato come chiave alternativa (UNICA). In questo modo, disabiliteremo le voci duplicate che collegano i singoli studenti con la stessa persona di contatto. L'attributo contact_person_type_id non fa parte della chiave alternativa. Se è così, potremmo avere più relazioni per la stessa persona di contatto e lo stesso studente (usando diversi tipi di relazione), e questo non ha senso nelle situazioni della vita reale.

Il modello presentato in questo articolo dovrebbe essere in grado di coprire le esigenze più comuni. Tuttavia, parti del modello potrebbero essere escluse in alcuni casi, ad es. probabilmente non avremmo bisogno dell'intero segmento delle persone di contatto se i nostri studenti fossero adulti. Come ho detto prima, aggiungeremo miglioramenti a questo in tempo. Sentiti libero di aggiungere suggerimenti e condividere la tua esperienza nelle sezioni di discussione.