È davvero difficile darti una risposta che risolva sufficientemente la tua domanda. La realtà è che il punto di utilizzo di un database relazionale è quello di modellare le relazioni del mondo reale tra entità.
Un database scolastico può essere piuttosto complesso. Deve tener conto molto di più di pochi corsi, studenti, ecc. E la normalizzazione dei dati (rimozione della ridondanza) è complessa!
Ad esempio, ecco come potrebbero essere alcune di queste relazioni:
# (middle initial is last for optimization)
-person
- id
+- int
+- primary key, unique, not null
- type
+- [foreign key] => position_id
- gender
+- enum (Male/Female)
+- not null
- dob
+- can be a date, a string, etc
+- not null
- address
+- [foreign key] => address_id
- first_name
+- varchar
+- not null
- last_name
+- varchar
+- not null
- middle_initial
+- char
+- can be null
# the position table tells you the type of person
# everytime a new position is created, it's added here
# this can be simple w/ 2 records:
# 1. student
# 2. faculty
# but it can also have administrative staff, etc and grow
# rather large
-position
- position_id
+- primary key, not null, unique
- psition
+- varchar
# holds all addresses.. these can be shared by faculty and students...
-addresses
- address_id
+- can be a hashsum, an int, etc... but it can also be
a composite key, made up of every other field in this table
- street_number
+- int
- street_name
+- varchar
- municipality
+- [foreign key] => municipality_id
- county
+- [foreign key] => county_id
- country
+- [foreign key] => country_id
-municipality
...contains attributes of all municipalites that
the school serves. new ones can be added, old ones
can be removed...
-county
...same as municipality
# list of departments
-department
-department_id
...etc, more attributes of a department
# list of available courses
-course
- course_id
- department
+- [foreign key] => department_id
# current semester and all previous semesters
-semester
...this is where the semesters are stored
# grade
-grade
- grade_id
- foreign key for course_id
- foreign key for semester_id
- foreign key for student person record
- foreign key for teacher person record
Ora, questo non è perfetto in nessun modo. È piuttosto incompleto! Fornire uno schema di database completamente normalizzato e a tenuta stagna va oltre lo scopo di questo post (a meno che tu non sia disposto ad assumere un appaltatore, wink).
Il punto che stavo cercando di fare con lo schema schema che ho fornito è che vuoi memorizzare le entità in tabelle univoche e collegare queste tabelle per mostrare le relazioni.
La tabella person è un buon esempio perché quella tabella può avere diverse relazioni. Ad esempio, più persone possono vivere allo stesso indirizzo e quindi abbiamo aggiunto una tabella address . Dobbiamo descrivere type / function / role di quella persona - sono uno studente? facoltà? impiegato amministrativo? volontario? Consiglio scolastico? contatto di emergenza? Un nonno che è autorizzato a raccogliere un bambino? ecc. ecc.
Inoltre, si potrebbe sostenere che gender è condivisa su più record e dovrebbe essere invece una chiave esterna - sarebbe una decisione sbagliata. Poiché esiste un numero così basso di risposte possibili, è più efficiente utilizzare un tipo di enum di database incorporato. Il motore del database ottimizzerà enum s per te.
Se non si separano le entità, le prestazioni del database ne risentiranno. Immagina di avere le stesse contee e comuni duplicati migliaia di volte nella tabella degli indirizzi! I comuni e le contee sono finiti - di solito una scuola può limitarli a una certa area geografica, ad esempio entro 100 miglia dalla scuola.
In questo modo, in futuro è facile aggiungere nuove contee, se una nuova persona ha un indirizzo che risiede in un comune o in una contea che non ha un record corrispondente.
Potresti anche voler creare una tabella nazionale se hai anche il motivo più banale per credere che gli studenti che risiedono permanentemente in un altro paese saranno nel database. Pensa allo studente straniero o uno studente che studia all'estero.
Come puoi vedere, queste relazioni sono complesse e devi pensare di conseguenza al tuo database.
Ad esempio, ci sono un numero piuttosto elevato di entità che saranno rappresentate nel database. Ne elencherò alcuni sotto e ti consentirò di prenderlo da qui:
- Dipartimenti
- semestri
- Corsi
- Course_materials
- Gradi
- Tieni presente che gli studenti possono prendere due volte la stessa classe se falliscono
Ci sono altre cose da tenere a mente, che possono essere nel databse:
- Tenere traccia dei venditori utilizzati dalla scuola
- Ricezione di lezioni, fatturazione, ecc.
- Tenere traccia di chi ha borse di studio
- Tenere traccia di quali sono gli studenti su quali squadre sportive
- Tenere traccia dei GPA e mettere in difficoltà gli studenti in prova accademica
- Monitoraggio di infrazioni, detenzioni, sospensioni
- Tenere traccia degli studenti trasferiti, ecc.
