Bagaimana Desain Basis Data Membantu Mengatur Guru, Pelajaran, dan Siswa?

Investasi dalam pengetahuan memberikan hasil terbaik.

Benjamin Franklin

Di dunia modern, pendidikan ada di mana-mana. Sekarang lebih dari sebelumnya, itu memainkan peran penting dalam masyarakat kita. Faktanya, sangat penting bahwa banyak dari kita melanjutkan pendidikan kita dengan baik setelah menyelesaikan sekolah atau perguruan tinggi.

Kita semua telah mendengar tentang pembelajaran seumur hidup, pendidikan non-formal, dan lokakarya untuk segala usia. Metode ini berbeda dari pendidikan formal dalam banyak hal, tetapi mereka juga memiliki kesamaan. Ada kelas, pelajaran, guru, dan siswa. Dan seperti dalam pengaturan tradisional, kami ingin melacak jadwal kelas, data kehadiran, dan prestasi instruktur atau siswa. Bagaimana kita bisa merancang database untuk memenuhi kebutuhan ini? Itulah yang akan kami bahas dalam artikel ini.

Memperkenalkan Model Basis Data Pendidikan Kami

Model yang disajikan dalam artikel ini memungkinkan kita untuk menyimpan data tentang:

• kelas/kuliah
• instruktur/dosen
• siswa
• kehadiran kuliah
• prestasi mahasiswa/dosen

Kita juga dapat menggunakan model ini sebagai jadwal sekolah, untuk kegiatan kelompok lainnya (pelajaran renang, lokakarya menari) atau bahkan untuk kegiatan pribadi seperti les. Masih banyak ruang untuk perbaikan, seperti penyimpanan data lokasi kelas atau durasi workshop; kami akan membahas ini di artikel mendatang.

Mari kita mulai dengan elemen basis data Pendidikan dasar kita:tabel.

Tiga Besar:Tabel Siswa, Instruktur, dan Kelas

student , instructor , dan class tabel merupakan inti dari database kami.

student Tabel di atas digunakan untuk menyimpan data dasar tentang siswa, tetapi dapat diperluas sesuai dengan kebutuhan tertentu. Dengan pengecualian tiga atribut kontak, semua atribut dalam tabel wajib diisi:

• first_name – nama siswa
• last_name – nama belakang siswa
• birth_date – tanggal lahir siswa
• contact_phone – nomor telepon siswa
• contact_mobile – nomor ponsel siswa
• contact_mail – alamat email siswa
• category_id – adalah referensi ke category katalog. Dengan struktur ini, kami dibatasi hanya satu kategori per siswa. Itu berfungsi dalam banyak kasus, tetapi dalam beberapa situasi kita mungkin memerlukan ruang untuk membuat daftar beberapa kategori. Seperti yang Anda lihat, menambahkan relasi banyak ke banyak yang menghubungkan student tabel dengan category kamus memecahkan masalah ini. Namun, dalam skenario ini, kita perlu menulis kueri yang agak lebih kompleks untuk menangani data kita.

Karena kami telah menyebutkannya, mari kita lanjutkan dan diskusikan category tabel di sini.

Tabel ini merupakan kamus yang digunakan untuk mengelompokkan siswa berdasarkan kriteria tertentu. name atribut adalah satu-satunya data dalam tabel (selain id , kunci utama) dan itu wajib. Satu set nilai yang dapat disimpan di sini adalah status pekerjaan siswa:“mahasiswa”, “bekerja”, “menganggur” dan “pensiun”. Kami juga dapat menggunakan set lain berdasarkan beberapa kriteria yang sangat spesifik, seperti “suka yoga”, “suka mendaki”, “suka bersepeda”, dan “tidak suka apa pun”.

instructor tabel berisi daftar semua instruktur/dosen dalam organisasi. Atribut dalam tabel adalah:

• first_name – nama instruktur
• last_name – nama keluarga instruktur
• title – gelar instruktur (jika ada)
• birth_date – tanggal lahir instruktur
• contact_phone – nomor telepon instruktur
• contact_mobile – nomor ponsel instruktur
• contact_mail – alamat email instruktur

title dan ketiga contact atribut tidak wajib.

student tabel dan instructor tabel berbagi struktur yang sama, tetapi ada kemungkinan lain untuk mengatur informasi ini. Pendekatan kedua adalah memiliki person tabel (yang menyimpan semua data karyawan dan siswa) dan memiliki hubungan banyak-ke-banyak yang memberi tahu kita semua peran yang diberikan kepada orang itu. Keuntungan terpenting dari pendekatan kedua adalah kami hanya akan menyimpan data sekali. Jika seseorang adalah instruktur di satu kelas dan siswa di kelas lain, mereka hanya akan muncul sekali di database, tetapi dengan kedua peran yang ditentukan.

Mengapa kami memilih pendekatan dua tabel untuk model database pendidikan kami? Umumnya, siswa dan instruktur berperilaku berbeda, baik di kehidupan nyata maupun di database kami. Karena itu, sebaiknya simpan data mereka secara terpisah. Kami dapat menemukan cara lain untuk menggabungkan informasi orang yang sama yang muncul di kedua tabel (misalnya, sepasang kueri sisipkan/perbarui berdasarkan id eksternal, seperti nomor jaminan sosial atau nomor PPN).

class tabel adalah katalog yang berisi detail tentang semua kelas. Kita dapat memiliki beberapa instance dari setiap tipe kelas. Atribut dalam tabel adalah sebagai berikut (semua wajib kecuali end_date ):

• class_type_id – adalah referensi ke class_type kamus.
• name – adalah nama pendek dari kelas.
• description – deskripsi ini lebih spesifik daripada yang ada di class_type meja.
• start_date – tanggal mulai kelas.
• end_date - tanggal akhir kelas. Ini tidak wajib karena kami mungkin tidak selalu mengetahui tanggal akhir yang tepat untuk setiap kelas sebelumnya.
• completed – adalah nilai Boolean yang menunjukkan apakah semua aktivitas kelas yang direncanakan telah selesai. Ini berguna ketika kita telah mencapai end_time yang direncanakan untuk kelas tetapi kegiatan kelas lainnya belum selesai.

class_type tabel adalah katalog sederhana, dimaksudkan untuk menyimpan informasi dasar tentang kuliah atau kelas yang ditawarkan kepada mahasiswa. Itu bisa berisi nilai-nilai seperti “Bahasa Inggris (grup)”, “Bahasa Polandia (grup)”, “Bahasa Kroasia (grup)”, “Bahasa Inggris (secara langsung)”, atau “Pelajaran dansa”. Ini hanya memiliki dua atribut wajib – name dan description , keduanya tidak memerlukan penjelasan lebih lanjut.

class_schedule tabel berisi waktu khusus untuk kuliah dan kelas. Semua atribut dalam tabel adalah wajib. class_id atribut adalah referensi ke class tabel, sedangkan start_time dan end_time adalah waktu mulai dan berakhirnya kuliah khusus tersebut.

Siapa Disini? Tabel Terkait Kehadiran

attend tabel menyimpan informasi tentang siswa mana yang menghadiri kelas mana dan hasil akhir. Atribut dalam tabel adalah:

• student_id – adalah referensi ke student meja
• class_id – adalah referensi ke class meja
• class_enrollment_date – adalah tanggal siswa mulai menghadiri kelas tersebut
• class_drop_date – tanggal siswa keluar dari kelas. Atribut ini akan memiliki nilai hanya jika siswa meninggalkan kelas sebelum tanggal akhir kelas. Dalam hal ini, drop_class_reason_id nilai atribut juga harus disetel.
• drop_class_reason_id – adalah referensi ke drop_class_reason meja
• attendance_outcome_id – adalah referensi ke attendance_outcome meja

Semua data kecuali class_drop_date dan drop_class_reason_id Dibutuhkan. Keduanya akan diisi jika dan hanya jika seorang siswa keluar dari kelas.

drop_attendance_reason tabel adalah kamus yang berisi berbagai alasan mengapa seorang siswa mungkin berhenti kursus. Hanya memiliki satu atribut, reason_text , dan itu wajib. Contoh kumpulan nilai mungkin termasuk:“sakit”, “kehilangan minat”, “tidak punya cukup waktu” dan “alasan lain”.

attendance_outcome tabel berisi deskripsi tentang aktivitas siswa dalam mata kuliah tertentu. outcome_text adalah satu-satunya atribut dalam tabel dan itu diperlukan. Satu set nilai yang mungkin adalah:“sedang berlangsung”, “selesai dengan sukses”, “selesai sebagian” dan “belum menyelesaikan kelas”.

Siapa yang Bertanggung Jawab? Tabel Terkait Pengajaran

teach , drop_teach_reason dan teach_outcome tabel menggunakan logika yang sama seperti attend , drop_attendance_reason dan attendance_outcome tabel. Semua tabel ini menyimpan data tentang aktivitas terkait kursus instruktur.

teach tabel digunakan untuk menyimpan informasi tentang instruktur yang mengajar kelas mana. Atribut dalam tabel adalah:

• instructor_id – adalah referensi ke instructor meja.
• class_id – adalah referensi ke class meja.
• start_date – adalah tanggal saat instruktur mulai mengerjakan kelas tersebut.
• end_date – adalah tanggal ketika instruktur berhenti mengerjakan kelas itu. Itu tidak wajib karena kita tidak bisa tahu sebelumnya apakah instruktur akan mengajar sampai tanggal akhir kelas.
• drop_teach_reason_id – adalah referensi ke drop_teach_reason meja. Itu tidak wajib karena instruktur tidak boleh membatalkan kelas.
• teach_outcome_id – adalah referensi ke teach_outcome_reason meja.

drop_teach_reason tabel adalah kamus sederhana. Ini berisi serangkaian kemungkinan penjelasan mengapa instruktur selesai mengajar kelas sebelum tanggal berakhirnya. Hanya ada satu atribut wajib:reason_text . Ini bisa berupa “sakit”, “pindah ke proyek/pekerjaan lain”, “berhenti”, atau “alasan lain”.

teach_outcome tabel menggambarkan keberhasilan instruktur pada kursus tertentu. outcome_text adalah satu-satunya atribut tabel dan itu wajib. Nilai yang mungkin untuk tabel ini dapat berupa:“sedang berlangsung”, “selesai dengan sukses”, “selesai sebagian” dan “belum menyelesaikan kelas pengajaran”.

student_presence tabel digunakan untuk menyimpan data tentang kehadiran mahasiswa untuk perkuliahan tertentu. Kita dapat berasumsi bahwa untuk setiap kuliah instruktur akan mencatat kehadiran dan/atau ketidakhadiran untuk semua siswa. Atribut dalam tabel adalah:

• student_id – adalah referensi ke student meja
• class_schedule_id – adalah referensi ke class_schedule meja
• present – adalah Boolean yang menandai apakah mahasiswa hadir pada perkuliahan atau tidak

Kita bisa memantau kehadiran siswa di kelas tertentu dengan query seperti berikut (dengan asumsi bahwa @id_class berisi id kelas yang kita inginkan).

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 persentase, 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, absensi_outcome.outcome_text SEBAGAI kehadiran_hasilFROM kelas INNER JOIN hadir DI class.id =hadir.class_id INNER JOIN student ON hadir.student_id =student.id KIRI GABUNG class_schedule ON class_schedule.class_id =class.id KIRI JOIN student_presence. .id DAN student_presence.class_schedule_id =class_schedule.id KIRI GABUNG absensi_outcome ON absensi_outcome.id =hadir.attendance_outcome_idWHERE class.id =@id_classGROUP OLEH mahasiswa.id, mahasiswa.nama_depan, mahasiswa.nama_belakang, kehadiran_outcome) .out 
  
 

 Tabel “instructor_presence” menggunakan logika yang sama dengan tabel “student_presence”, tetapi di sini kita ingin fokus pada instruktur. Atribut dalam tabel adalah:
 
 
instructor_id – adalah referensi ke instructor meja
 
class_schedule_id – adalah referensi ke class_schedule meja
 
present – adalah nilai Boolean yang mewakili apakah instruktur hadir di kuliah atau tidak
 
 

 Kita dapat menggunakan kueri di bawah ini untuk memantau aktivitas instruktur di kelas:
 
SELECT a.id, CONCAT(a.first_name, ' ', a.last_name) AS instruktur_name, a.number_total, CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS persentase, a.teach_outcomeFROM(SELECT instruktur.id, instruktur.nama_depan, instruktur.nama_belakang, SUM(CASE WHEN instruktur_presence.present =True THEN 1 ELSE 0 END) AS number_present, COUNT(DISTINCT class_schedule.id) AS number_total, teaching_outcome.outcome_text AS teaching_outcomeFROM class INNER JOIN teaching ON class.id =teaching.class_id INNER JOIN instruktur ON teaching.instructor_id =instruktur.id KIRI GABUNG class_schedule ON class_schedule.class_id =class.id KIRI instructor_presence instructor_presence instructor_presence instructor_presence .id DAN instruktur_presence.class_schedule_id =class_schedule.id KIRI GABUNG teaching_outcome ON teaching_outcome.id =teaching.teach_outcome_idWHERE class.id =@id_classGROUP BY instruktur.id, instruktur.nama_pertama, instruktur.nama_belakang, pengajaran_outcome).outcome. 
Sekarang, mari kita selesaikan dengan membahas tabel Contact Person.
 
Siapa yang Dapat Kami Hubungi? Tabel Kontak Person
 

 Dalam kebanyakan kasus, kami tidak perlu menyimpan informasi kontak darurat (yaitu dalam keadaan darurat, hubungi orang ini). Namun, ini berubah ketika kita mengajar anak-anak. Secara hukum atau adat, kita perlu memiliki Kontak Person untuk setiap anak yang kita ajar. Dalam tabel model kami – contact_person , contact_person_type dan contact_person_student – kami mendemonstrasikan bagaimana hal ini dapat dilakukan.
 
  
 

 contact_person tabel adalah daftar orang-orang yang berhubungan dengan siswa. Tentu saja, kita tidak perlu membuat daftar semua kerabat; kebanyakan kita akan memiliki satu atau dua kontak per siswa. Ini adalah cara yang baik untuk menemukan "siapa yang akan Anda hubungi" ketika siswa membutuhkan atau ingin pergi lebih awal. Atribut dalam tabel adalah:
 
 
first_name – adalah nama kontak person
 
last_name – adalah nama keluarga orang tersebut
 
contact_phone – adalah nomor telepon orang tersebut
 
contact_mobile – adalah nomor ponsel orang tersebut
 
contact_mail – adalah alamat email orang tersebut
 
 

 Detail kontak tidak wajib, meskipun sangat berguna.
 
  
 

 contact_person_type table adalah kamus dengan satu atribut yang diperlukan:type_name . Contoh nilai yang disimpan dalam tabel ini adalah:“ibu”, “ayah”, “kakak”, “kakak” atau “paman”.
 
  
 

 contact_person_student table adalah relasi many-to-many yang menghubungkan Contact Person dan tipenya dengan siswa. Atribut dalam tabel adalah (semuanya wajib):
 
 
contact_person_id – adalah referensi ke contact_person meja
 
student_id – adalah referensi ke student meja
 
contact_person_type_id – adalah referensi ke contact_person_type meja
 
 

 Mungkin perlu disebutkan bahwa relasi banyak-ke-banyak ini menghubungkan tiga tabel bersama-sama. Pasangan atribut contact_person_id dan student_id digunakan sebagai kunci alternatif (UNIQUE). Dengan begitu, kami akan menonaktifkan entri duplikat yang menghubungkan setiap siswa dengan narahubung yang sama. Atribut contact_person_type_id bukan merupakan bagian dari kunci alternatif. Jika demikian, kita dapat memiliki banyak hubungan untuk orang yang dapat dihubungi yang sama dan siswa yang sama (menggunakan jenis hubungan yang berbeda), dan itu tidak masuk akal dalam situasi kehidupan nyata.
 

 Model yang disajikan dalam artikel ini harus dapat memenuhi kebutuhan yang paling umum. Namun, bagian dari model dapat dikecualikan dalam beberapa kasus, mis. kita mungkin tidak membutuhkan seluruh segmen contact person jika siswa kita adalah orang dewasa. Seperti yang saya katakan sebelumnya, kami akan menambahkan peningkatan ini pada waktunya. Jangan ragu untuk menambahkan saran dan berbagi pengalaman Anda di bagian diskusi.