Как дизайнът на база данни помага да се организират учители, уроци и ученици?

Инвестицията в знания носи най-добрия интерес.

Бенджамин Франклин

В съвременния свят образованието е вездесъщо. Сега повече от всякога той играе важна роля в нашето общество. Всъщност е толкова важно много от нас да продължат образованието си добре след завършване на училище или колеж.

Всички сме чували за учене през целия живот, неформално образование и семинари за всички възрасти. Тези методи се различават от формалното образование в много отношения, но имат и общи неща. Има класове, уроци, учители и ученици. И точно както в традиционна обстановка, ние ще искаме да следим графика на класа, данните за посещаемостта и постиженията на инструктора или учениците. Как можем да проектираме база данни, за да отговорим на тези нужди? Това ще разгледаме в тази статия.

Представяме нашия модел на база данни за образование

Моделът, представен в тази статия, ни позволява да съхраняваме данни за:

• класове/лекции
• инструктори/лектори
• ученици
• посещение на лекции
• постижения на студенти/преподаватели

Можем да използваме този модел и като училищен график, за други групови дейности (уроци по плуване, танцови работилници) или дори за индивидуални дейности като уроци. Все още има много място за подобрения, като например съхраняване на данни за местоположението на класа или продължителността на семинара; ще ги разгледаме в следващите статии.

Нека започнем с нашите основни елементи на базата данни за образование:таблиците.

Големите три:Студентски, инструкторски и класни маси

student , instructor , и class таблиците съставляват ядрото на нашата база данни.

student таблицата, показана по-горе, се използва за съхраняване на основни данни за учениците, но може да бъде разширена според специфичните нужди. С изключение на трите атрибута за контакт, всички атрибути в таблицата са задължителни:

• first_name – името на ученика
• last_name – фамилия на ученика
• birth_date – рождена дата на ученика
• contact_phone – телефонен номер на ученика
• contact_mobile – номер на мобилния телефон на ученика
• contact_mail – имейл адрес на ученика
• category_id – е препратка към category каталог. С тази структура ние сме ограничени само до една категория на ученик. Това работи в повечето случаи, но в някои ситуации може да ни трябва място за изброяване на няколко категории. Както можете да видите, добавянето на релация много към много, която свързва student таблица с category речникът решава този проблем. В този сценарий обаче ще трябва да напишем доста по-сложни заявки, за да обработваме нашите данни.

Тъй като го споменахме, нека да продължим и да обсъдим category таблица тук.

Тази таблица е речник, използван за групиране на ученици въз основа на определени критерии. name атрибутът е единствените данни в таблицата (освен id , първичен ключ) и е задължителен. Един набор от стойности, които могат да бъдат съхранени тук, е статусът на заетостта на студента:„студент“, „зает“, „безработен“ и „пенсиониран“. Бихме могли да използваме и други набори въз основа на някои строго специфични критерии, като „обича йога“, „обича туризъм“, „обича карането на колело“ и „не харесва нищо“.

instructor таблицата съдържа списък на всички инструктори/лектори в организацията. Атрибутите в таблицата са:

• first_name – името на инструктора
• last_name – фамилията на инструктора
• title – званието на инструктора (ако има такова)
• birth_date – рождена дата на инструктора
• contact_phone – телефонен номер на инструктора
• contact_mobile – номер на мобилния телефон на инструктора
• contact_mail – имейл адрес на инструктора

title и трите contact атрибутите не са задължителни.

student маса и instructor таблицата има подобна структура, но има друга възможност за организиране на тази информация. Вторият подход би бил да имате person таблица (която съхранява всички данни за служители и студенти) и има връзка много към много, която ни казва всички роли, присвоени на това лице. Най-важното предимство на втория подход е, че ще съхраняваме данни само веднъж. Ако някой е инструктор в един клас и ученик в друг, той ще се появи само веднъж в базата данни, но с дефинирани и двете роли.

Защо избрахме подхода с две таблици за нашия модел на образователна база данни? Като цяло студентите и преподавателите се държат различно, както в реалния живот, така и в нашата база данни. Поради това би било разумно да съхранявате техните данни отделно. Можем да намерим други начини за обединяване на всякаква информация за едно и също лице, която се появява и в двете таблици (напр. двойка заявки за вмъкване/актуализация въз основа на външен идентификатор, като номер на социално осигуряване или номер по ДДС).

class таблицата е каталог, който съдържа подробности за всички класове. Можем да имаме множество екземпляри от всеки тип клас. Атрибутите в таблицата са както следва (всички са задължителни с изключение на end_date ):

• class_type_id – е препратка към class_type речник.
• name – е кратко име на класа.
• description – това описание е по-конкретно от това в class_type маса.
• start_date – началната дата на учебния час.
• end_date – крайна дата на класа. Това не е задължително, защото може да не знаем предварително точната крайна дата за всеки клас.
• completed – е булева стойност, която обозначава дали всички планирани дейности в класа са завършени. Това е удобно, когато достигнем планирания end_time за клас, но други дейности в клас все още не са завършени.

class_type таблицата е прост каталог, предназначен да съхранява основна информация за лекциите или часовете, предлагани на студентите. Може да съдържа стойности като „Английски език (група)“, „Полски език (група)“, „Хърватски език (група)“, „Английски език (лично)“ или „Уроци по танци“. Той има само два задължителни атрибута – name и description , като и двете нямат нужда от допълнително обяснение.

class_schedule таблицата съдържа определени часове за лекции и часове. Всички атрибути в таблицата са задължителни. class_id атрибутът е препратка към class таблица, докато start_time и end_time са началните и крайните часове на тази конкретна лекция.

Кой е тук? Таблици, свързани с посещаемостта

attend таблицата съхранява информация за това кой ученик кой клас е посещавал и крайния резултат. Атрибутите в таблицата са:

• student_id – е препратка към student таблица
• class_id – е препратка към class таблица
• class_enrollment_date – е датата, на която ученикът е започнал да посещава този час
• class_drop_date – датата, на която ученикът е напуснал класа. Този атрибут ще има стойност само ако ученикът е напуснал клас преди крайната дата на класа. В този случай drop_class_reason_id стойността на атрибута също трябва да бъде зададена.
• drop_class_reason_id – е препратка към drop_class_reason таблица
• attendance_outcome_id – е препратка към attendance_outcome таблица

Всички данни с изключение на class_drop_date и drop_class_reason_id изисква се. Тези две ще бъдат попълнени, ако и само ако ученик напусне класа.

drop_attendance_reason table е речник, съдържащ различните причини, поради които студентът може да откаже курс. Той има само един атрибут, reason_text , и е задължително. Примерен набор от стойности може да включва:„болест“, „загубен интерес“, „няма достатъчно време“ и „други причини“.

attendance_outcome таблицата съдържа описания на студентската дейност в даден курс. outcome_text е единственият атрибут в таблицата и е задължителен. Набор от възможни стойности е:„в ход“, „завършен успешно“, „завършен частично“ и „не е завършил клас“.

Кой отговаря? Таблици, свързани с преподаването

teach , drop_teach_reason и teach_outcome таблиците използват същата логика като attend , drop_attendance_reason и attendance_outcome маси. Всички тези таблици съхраняват данни за дейностите на инструкторите, свързани с курсовете.

teach таблицата се използва за съхраняване на информация за това кой инструктор кой клас преподава. Атрибутите в таблицата са:

• instructor_id – е препратка към instructor маса.
• class_id – е препратка към class маса.
• start_date – е датата, на която инструкторът е започнал работа в този клас.
• end_date – е датата, на която инструкторът е спрял да работи в този клас. Не е задължително, защото не можем да знаем предварително дали инструкторът ще преподава до крайната дата на класа.
• drop_teach_reason_id – е препратка към drop_teach_reason маса. Това не е задължително, защото инструкторът може да не напусне класа.
• teach_outcome_id – е препратка към teach_outcome_reason маса.

drop_teach_reason таблицата е прост речник. Той съдържа набор от възможни обяснения защо инструкторът е завършил обучението преди крайната дата. Има само един задължителен атрибут:reason_text . Това може да бъде „болест“, „преместен на друг проект/работа“, „напускане“ или „друга причина“.

teach_outcome таблицата описва успеха на инструктора по конкретен курс. outcome_text е единственият атрибут на таблицата и е задължителен. Възможните стойности за тази таблица могат да бъдат:„в ход“, „завършено успешно“, „завършено частично“ и „не е завършил учебен час“.

student_presence таблицата се използва за съхраняване на данни за присъствието на студенти за конкретна лекция. Можем да приемем, че за всяка лекция инструкторът ще отбелязва присъствието и/или отсъствието за всички студенти. Атрибутите в таблицата са:

• student_id – е препратка към student таблица
• class_schedule_id – е препратка към class_schedule таблица
• present – е булева маркировка дали студентът присъства на лекцията или не

Бихме могли да наблюдаваме присъствието на учениците в конкретен клас със заявка като тази, която следва (ако приемем, че @id_class съдържа идентификатора на класа, който искаме).

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)), '%') КАТО процент, 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_prisent, COUNT(DISTINCT class_schedule.id) AS number_total, visitance_outcome.outcome_text КАТО visitance_outcomeFROM class INNER JOIN присъствам ON class.id =visit.class_id INNER JOIN student ON visit.student_id =student.id LEFT JOIN class_schedule ON class_schedule.class_id =class.id =class.id LEFT JOIN student_presence student_predent student_ .id AND student_presence.class_schedule_id =class_schedule.id LEFT ПРИСЪЕДИНЕТЕ visitance_outcome ON visitance_outcome.id =visit.attendance_outcome_idWHERE class.id =@id_classGROUP BY student.id, student.first_name, student.last_name, student.last_prename.com посещаемост_eoutcome> 
  
 

 Таблицата „instructor_presence“ използва същата логика като таблицата „student_presence“, но тук искаме да се съсредоточим върху инструкторите. Атрибутите в таблицата са:
 
 
instructor_id – е препратка към instructor таблица
 
class_schedule_id – е препратка към class_schedule таблица
 
present – е булева стойност, представляваща дали инструкторът присъства на лекцията или не
 
 

 Можем да използваме заявката по-долу, за да наблюдаваме дейността на инструктора в клас:
 
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)), '%') КАТО процент, 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) AS number_total, teach_outcome.outcome_text КАТО teach_outcomeFROM клас 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_id =prestructor_id на class. .id И instructor_presence.class_schedule_id =class_schedule.id LEFT JOIN teach_outcome ON teach_outcome.id =teach.teach_outcome_idWHERE class.id =@id_classGROUP BY instructor.id, instructor.first_name, instructor, instructor.com_text. 
Сега нека завършим, като обсъдим таблиците на лицата за контакт.
 
На кого можем да се обадим? Таблици на лицата за контакт
 

 В повечето случаи не е необходимо да съхраняваме информация за контакт при спешни случаи (т.е. в случай на спешност, свържете се с това лице). Това обаче се променя, когато учим деца. По закон или обичай трябва да имаме лице за контакт за всяко дете, на което обучаваме. В нашите модели таблици – contact_person , contact_person_type и contact_person_student – демонстрираме как може да се направи това.
 
  
 

 contact_person таблицата е списък с хора, които са свързани с ученици. Разбира се, не е необходимо да изброяваме всички роднини; най-често ще имаме един или два контакта на ученик. Това е добър начин да намерите „на кого ще се обадите“, когато ученикът има нужда или иска да напусне по-рано. Атрибутите в таблицата са:
 
 
first_name – е името на лицето за контакт
 
last_name – е фамилията на лицето
 
contact_phone – е телефонният номер на лицето
 
contact_mobile – е номерът на мобилния телефон на лицето
 
contact_mail – е имейл адресът на лицето
 
 

 Данните за контакт не са задължителни, но са много полезни.
 
  
 

 contact_person_type table е речник с един-единствен задължителен атрибут:type_name . Примери за стойности, съхранени в тази таблица, са:„майка“, „баща“, „брат“, „сестра“ или „чичо“.
 
  
 

 contact_person_student таблицата е релация много към много, която свързва лицата за контакт и техния тип с учениците. Атрибутите в таблицата са (всички са задължителни):
 
 
contact_person_id – е препратка към contact_person таблица
 
student_id – е препратка към student таблица
 
contact_person_type_id – е препратка към contact_person_type таблица
 
 

 Може би си струва да се спомене, че тази релация много към много свързва три таблици заедно. Атрибутната двойка contact_person_id и student_id се използва като алтернативен (УНИКАЛЕН) ключ. По този начин ще деактивираме дублиращи се записи, които свързват отделни студенти със същото лице за контакт. Атрибутът contact_person_type_id не е част от алтернативния ключ. Ако е така, бихме могли да имаме множество отношения за едно и също лице за контакт и един и същ ученик (използвайки различни типове взаимоотношения) и това няма смисъл в ситуации от реалния живот.
 

 Моделът, представен в тази статия, трябва да може да покрие най-често срещаните нужди. Все пак части от модела могат да бъдат изключени в някои случаи, напр. вероятно няма да имаме нужда от целия сегмент за контактни лица, ако нашите ученици са възрастни. Както казах по-рано, с времето ще добавяме подобрения към това. Чувствайте се свободни да добавяте предложения и да споделяте опита си в секциите за дискусии.