Hoe helpt databaseontwerp docenten, lessen en studenten te organiseren?

Een investering in kennis levert het meeste op.

Benjamin Franklin

In de moderne wereld is onderwijs alomtegenwoordig. Nu meer dan ooit speelt het een belangrijke rol in onze samenleving. Het is zelfs zo belangrijk dat velen van ons onze opleiding lang voortzetten nadat ze hun school of universiteit hebben afgerond.

We hebben allemaal gehoord van levenslang leren, niet-formeel onderwijs en workshops voor alle leeftijden. Deze methoden verschillen in veel opzichten van het formele onderwijs, maar ze hebben ook dingen gemeen. Er zijn klassen, lessen, docenten en studenten. En net als in een traditionele omgeving, willen we het lesrooster, de aanwezigheidsgegevens en de prestaties van de instructeur of leerling bijhouden. Hoe kunnen we een database ontwerpen om aan deze behoeften te voldoen? Dat is wat we in dit artikel zullen behandelen.

Introductie van ons onderwijsdatabasemodel

Met het model dat in dit artikel wordt gepresenteerd, kunnen we gegevens opslaan over:

• lessen/lezingen
• instructeurs/docenten
• studenten
• aanwezigheid lezing
• prestaties van studenten / docenten

We zouden dit model ook kunnen gebruiken als schoolrooster, voor andere groepsactiviteiten (zwemlessen, dansworkshops) of zelfs voor één-op-één activiteiten zoals bijles. Er is nog veel ruimte voor verbeteringen, zoals het opslaan van leslocatiegegevens of workshopduur; we zullen deze behandelen in komende artikelen.

Laten we beginnen met onze basis Education database-elementen:de tabellen.

De grote drie:leerling-, instructeur- en klastafels

De student , instructor , en class tabellen vormen de kern van onze database.

De student tabel, hierboven weergegeven, wordt gebruikt om basisgegevens over studenten op te slaan, maar kan worden uitgebreid volgens specifieke behoeften. Met uitzondering van de drie contactattributen zijn alle attributen in de tabel vereist:

• first_name – de naam van de leerling
• last_name – de achternaam van de student
• birth_date – de geboortedatum van de student
• contact_phone – het telefoonnummer van de student
• contact_mobile – het mobiele telefoonnummer van de leerling
• contact_mail – het e-mailadres van de student
• category_id – is een verwijzing naar de category catalogus. Met deze structuur zijn we beperkt tot slechts één categorie per student. Dat werkt in de meeste gevallen, maar in sommige situaties hebben we misschien ruimte nodig om meerdere categorieën op te sommen. Zoals je kunt zien, voeg je een veel-op-veel-relatie toe die de student tabel met de category woordenboek lost dit probleem op. In dit scenario moeten we echter complexere query's schrijven om onze gegevens te verwerken.

Aangezien we het hebben genoemd, gaan we verder en bespreken we de category tafel hier.

Deze tabel is een woordenboek dat wordt gebruikt om studenten te groeperen op basis van bepaalde criteria. De name attribuut is de enige data in de tabel (naast id , de primaire sleutel) en het is verplicht. Een reeks waarden die hier kan worden opgeslagen, is de arbeidsstatus van de student:"student", "in dienst", "werkloos" en "gepensioneerd". We kunnen ook andere sets gebruiken op basis van een aantal zeer specifieke criteria, zoals 'houdt van yoga', 'houdt van wandelen', 'houdt van fietsen' en 'vind niets leuks'.

De instructor tabel bevat een lijst van alle instructeurs/docenten in de organisatie. De attributen in de tabel zijn:

• first_name – de naam van de instructeur
• last_name – de achternaam van de instructeur
• title – de titel van de instructeur (indien van toepassing)
• birth_date – de geboortedatum van de instructeur
• contact_phone – het telefoonnummer van de instructeur
• contact_mobile – het mobiele telefoonnummer van de instructeur
• contact_mail – het e-mailadres van de instructeur

De title en alle drie contact attributen zijn niet verplicht.

De student table en instructor tabel delen een vergelijkbare structuur, maar er is een andere mogelijkheid om deze informatie te organiseren. Een tweede benadering zou zijn om een ​​person tabel (die alle werknemers- en studentgegevens opslaat) en heeft een veel-op-veel-relatie die ons alle rollen vertelt die aan die persoon zijn toegewezen. Het belangrijkste voordeel van de tweede benadering is dat we gegevens maar één keer opslaan. Als iemand een instructeur is in de ene klas en een student in een andere, wordt hij slechts één keer in de database weergegeven, maar met beide rollen gedefinieerd.

Waarom hebben we voor ons educatieve databasemodel gekozen voor de tweetabellenbenadering? Over het algemeen gedragen studenten en docenten zich anders, zowel in het echte leven als in onze database. Daarom kan het verstandig zijn om hun gegevens apart op te slaan. We kunnen andere manieren vinden om de informatie over dezelfde persoon die in beide tabellen wordt weergegeven, samen te voegen (bijvoorbeeld een paar invoeg-/bijwerkquery's op basis van een externe id, zoals een burgerservicenummer of btw-nummer).

De class table is een catalogus die details over alle klassen bevat. We kunnen meerdere instanties van elk klassetype hebben. De attributen in de tabel zijn als volgt (alle zijn verplicht behalve end_date ):

• class_type_id – is een verwijzing naar de class_type woordenboek.
• name – is een korte naam van de klas.
• description – deze beschrijving is specifieker dan die in de class_type tafel.
• start_date – de startdatum van de les.
• end_date – de einddatum van de les. Het is niet verplicht omdat we misschien niet altijd de exacte einddatum voor elke les van tevoren weten.
• completed – is een Booleaanse waarde die aangeeft of alle geplande klasactiviteiten zijn voltooid. Dit is handig als we de geplande end_time hebben bereikt voor een klas, maar andere klasactiviteiten moeten nog worden voltooid.

De class_type table is een eenvoudige catalogus, bedoeld om basisinformatie op te slaan over de colleges of lessen die aan studenten worden aangeboden. Het kan waarden bevatten zoals "Engelse taal (groep)", "Poolse taal (groep)", "Kroatische taal (groep)", "Engelse taal (in persoon)" of "Danslessen". Het heeft slechts twee verplichte attributen – name en description , die beide geen verdere uitleg behoeven.

De class_schedule tabel bevat specifieke tijden voor lezingen en lessen. Alle attributen in de tabel zijn verplicht. De class_id attribuut is een verwijzing naar de class tabel, terwijl start_time en end_time zijn de begin- en eindtijden van die specifieke lezing.

Wie is hier? Aanwezigheidsgerelateerde tabellen

De attend tabel bevat informatie over welke student welke les heeft bijgewoond en het eindresultaat. De attributen in de tabel zijn:

• student_id – is een verwijzing naar de student tafel
• class_id – is een verwijzing naar de class tafel
• class_enrollment_date – is de datum waarop de leerling die les begon te volgen
• class_drop_date – de datum waarop de leerling de klas verlaat. Dit kenmerk heeft alleen waarde als de leerling de les heeft laten vallen vóór de einddatum van de les. In dat geval wordt de drop_class_reason_id attribuutwaarde moet ook worden ingesteld.
• drop_class_reason_id – is een verwijzing naar de drop_class_reason tafel
• attendance_outcome_id – is een verwijzing naar de attendance_outcome tafel

Alle gegevens behalve class_drop_date en drop_class_reason_id Is benodigd. Deze twee worden alleen ingevuld als en alleen als een leerling de klas verlaat.

De drop_attendance_reason table is een woordenboek met de verschillende redenen waarom een ​​student een cursus zou kunnen laten vallen. Het heeft maar één attribuut, reason_text , en het is verplicht. Een voorbeeld van een reeks waarden kan zijn:"ziekte", "verloren interesse", "heeft niet genoeg tijd" en "andere redenen".

De attendance_outcome tabel bevat beschrijvingen over de activiteiten van studenten in een bepaalde cursus. De outcome_text is het enige attribuut in de tabel en het is vereist. Een reeks mogelijke waarden is:"in uitvoering", "met succes voltooid", "gedeeltelijk voltooid" en "klas niet voltooid".

Wie heeft de leiding? Lesgerelateerde tabellen

De teach , drop_teach_reason en teach_outcome tabellen gebruiken dezelfde logica als de attend , drop_attendance_reason en attendance_outcome tafels. Al deze tabellen bevatten gegevens over cursusgerelateerde activiteiten van instructeurs.

De teach tabel wordt gebruikt om informatie op te slaan over welke instructeur welke klas lesgeeft. De attributen in de tabel zijn:

• instructor_id – is een verwijzing naar de instructor tafel.
• class_id – is een verwijzing naar de class tafel.
• start_date – is de datum waarop de instructeur aan die les begon te werken.
• end_date - is de datum waarop de instructeur stopte met werken aan die klas. Het is niet verplicht omdat we niet van tevoren kunnen weten of de instructeur les zal geven tot de einddatum van de les.
• drop_teach_reason_id – is een verwijzing naar de drop_teach_reason tafel. Het is niet verplicht omdat de instructeur de les niet mag laten vallen.
• teach_outcome_id – is een verwijzing naar de teach_outcome_reason tafel.

De drop_teach_reason tabel is een eenvoudig woordenboek. Het bevat een reeks mogelijke verklaringen waarom de instructeur de les voor de einddatum heeft beëindigd. Er is slechts één verplicht attribuut:reason_text . Dit kan "ziekte", "verplaatst naar een ander project/andere baan", "stoppen" of "andere reden" zijn.

De teach_outcome tabel beschrijft het succes van de instructeur op een bepaalde cursus. De outcome_text is het enige kenmerk van de tabel en is vereist. Mogelijke waarden voor deze tabel kunnen zijn:"in uitvoering", "met succes voltooid", "gedeeltelijk voltooid" en "heeft de lesgroep niet voltooid".

De student_presence tabel wordt gebruikt om gegevens over de aanwezigheid van studenten voor een specifiek college op te slaan. We kunnen ervan uitgaan dat de docent voor elk college de aan- en/of afwezigheid van alle studenten noteert. De attributen in de tabel zijn:

• student_id – is een verwijzing naar de student tafel
• class_schedule_id – is een verwijzing naar de class_schedule tafel
• present – is een Booleaanse markering of de student bij het college aanwezig is of niet

We kunnen de aanwezigheid van leerlingen in een specifieke klas volgen met een zoekopdracht zoals de volgende (ervan uitgaande dat @id_class de klas-ID bevat die we willen).

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_outcomeFROM(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, presence_outcome.outcome_text AS presence_outcomeFROM class INNER WORD LID aanwezig OP class.id =attend.class_id INNER WORD LID student AAN attend.student_id =student.id LEFT DOE MEE class_schedule ON class_schedule.class_id =class.id LEFT JOIN student_presence ON student_presence =student.student .id AND student_presence.class_schedule_id =class_schedule.id LEFT JOIN presentielijst AAN Attend_outcome.id =attend.attendance_outcome_idWHERE class.id =@id_classGROUP BY student.id, student.first_name, student.last_name, presence_outcome.outcome>a  
 

 De tabel "instructor_presence" gebruikt dezelfde logica als de tabel "student_presence", maar hier willen we ons concentreren op de instructeurs. De attributen in de tabel zijn:
 
 
instructor_id – is een verwijzing naar de instructor tafel
 
class_schedule_id – is een verwijzing naar de class_schedule tafel
 
present – is een Booleaanse waarde die aangeeft of de instructeur aanwezig is bij de lezing of niet
 
 

 We kunnen de onderstaande vraag gebruiken om de activiteit van de instructeur in de klas te volgen:
 
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_outcomeFROM(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_outcomeFROM class INNER WORD LID VAN teach ON class.id =teach.class_id INNER WORD LID VAN instructeur AAN teach.instructor_id =instructor.id LEFT WORD LID VAN class_schedule ON class_schedule.class_id =class.id LEFT DOE IN instructor_presence.in instructor_presence.in instructor_presid .id AND instructor_presence.class_schedule_id =class_schedule.id LEFT DOE MEE teach_outcome ON teach_outcome.id =teach.teach_outcome_idWHERE class.id =@id_classGROUP BY instructor.id, instructor.first_name, instructor.last_name, teach_outcome.outcome_text) 
Laten we eindigen met het bespreken van de tabellen met contactpersonen.
 
Wie kunnen we bellen? Tabellen met contactpersonen
 

 In de meeste gevallen hoeven we geen contactgegevens voor noodgevallen op te slaan (d.w.z. neem in geval van nood contact op met deze persoon). Dit verandert echter wanneer we kinderen lesgeven. Volgens de wet of gewoonte moeten we een contactpersoon hebben voor elk kind dat we lesgeven. In onze modeltabellen – contact_person , contact_person_type en contact_person_student – we demonstreren hoe dit kan.
 
  
 

 De contact_person tabel is een lijst van mensen die verwant zijn aan studenten. Natuurlijk hoeven we niet alle familieleden op te sommen; meestal hebben we één of twee contacten per student. Dit is een goede manier om te vinden "wie je gaat bellen" wanneer de student eerder moet of wil vertrekken. De attributen in de tabel zijn:
 
 
first_name – is de naam van de contactpersoon
 
last_name – is de achternaam van de persoon
 
contact_phone – is het telefoonnummer van de persoon
 
contact_mobile – is het mobiele telefoonnummer van de persoon
 
contact_mail – is het e-mailadres van de persoon
 
 

 Contactgegevens zijn niet verplicht, hoewel ze erg handig zijn.
 
  
 

 De contact_person_type table is een woordenboek met een enkel, vereist attribuut:type_name . Voorbeelden van waarden die in deze tabel zijn opgeslagen zijn:"moeder", "vader", "broer", "zus" of "oom".
 
  
 

 De contact_person_student table is een veel-op-veel relatie die contactpersonen en hun type verbindt met studenten. De attributen in de tabel zijn (allemaal verplicht):
 
 
contact_person_id – is een verwijzing naar de contact_person tafel
 
student_id – is een verwijzing naar de student tafel
 
contact_person_type_id – is een verwijzing naar de contact_person_type tafel
 
 

 Het is misschien de moeite waard om te vermelden dat deze veel-op-veel-relatie drie tabellen met elkaar verbindt. Het attributenpaar contact_person_id en student_id wordt gebruikt als alternatieve (UNIEKE) sleutel. Op die manier schakelen we dubbele vermeldingen uit die individuele studenten verbinden met dezelfde contactpersoon. Het kenmerk contact_person_type_id maakt geen deel uit van de alternatieve sleutel. Als dat zo is, kunnen we meerdere relaties hebben voor dezelfde contactpersoon en dezelfde student (met verschillende soorten relaties), en dat heeft in het echte leven geen zin.
 

 Het model dat in dit artikel wordt gepresenteerd, moet de meest voorkomende behoeften kunnen dekken. Toch kunnen in sommige gevallen delen van het model worden uitgesloten, b.v. we zouden waarschijnlijk niet het hele contactpersonensegment nodig hebben als onze studenten volwassen zijn. Zoals ik al eerder zei, zullen we hier op termijn verbeteringen aan toevoegen. Voel je vrij om suggesties toe te voegen en je ervaringen te delen in de discussiesecties.