ปัญหาคลาสสิกของโรงเรียนส่วนใหญ่ไม่ใช่การ “ไม่มีข้อมูล” แต่คือการมีข้อมูลที่ “ซ้ำซ้อนและกระจัดกระจาย” ค่ะ
ฝ่ายทะเบียนมีไฟล์ Excel รายชื่อนักเรียนชุดหนึ่ง ฝ่ายปกครองก็มีอีกชุดหนึ่ง ห้องพยาบาลก็มีอีกชุด พอเด็กคนหนึ่งเปลี่ยนนามสกุลที ต้องตามแก้ถึง 3-4 ที่ แถมบางทีแก้ไม่ครบข้อมูลก็ไม่ตรงกันอีก นี่คือสัญญาณเตือนว่า “การออกแบบฐานข้อมูล (Database Design)” ของเรากำลังมีปัญหาค่ะ
วันนี้เราจะมาดูวิธีการวางโครงสร้าง Database โรงเรียนให้เป็นระบบ แบบที่เรียกว่า Relational Database ที่จะช่วยให้ชีวิตครูและบุคลากรง่ายขึ้นเยอะ
Getty Images
สำรวจ
หลักการคิด: เปลี่ยนจาก “ไฟล์ใครไฟล์มัน” เป็น “ถังข้อมูลกลาง”
หัวใจของการออกแบบ Database คือ “ข้อมูลเรื่องเดิม ต้องเก็บไว้ที่เดียว (Single Source of Truth)” ค่ะ เราจะไม่เก็บชื่อนักเรียนไว้ในตารางเกรด แต่เราจะเก็บชื่อไว้ใน “ตารางนักเรียน” แล้วใช้แค่ “รหัสประจำตัว” ไปแปะไว้ในตารางเกรดแทน
เมื่อเข้าใจหลักการนี้แล้ว มาดู 4 ตารางหลัก (Tables) ที่ทุกโรงเรียนต้องมีกันค่ะ
1. ตารางข้อมูลหลัก (Master Data Tables)
นี่คือตารางที่เก็บข้อมูลที่ “นิ่ง” หรือเปลี่ยนแปลงไม่บ่อย เปรียบเสมือนเสาหลักของบ้าน
- Students (ตารางนักเรียน):
- Columns: StudentID (PK), FirstName, LastName, DateOfBirth, Address, ParentPhone
- หัวใจสำคัญ:
StudentID(รหัสประจำตัวนักเรียน) คือกุญแจหลักที่ห้ามซ้ำ
- Teachers (ตารางครู):
- Columns: TeacherID (PK), Name, Department, Email
- Subjects (ตารางวิชา):
- Columns: SubjectCode (PK), SubjectName, Credit (หน่วยกิต)
2. ตารางธุรกรรม (Transaction Tables)
นี่คือตารางที่บันทึก “เหตุการณ์” ที่เกิดขึ้นในแต่ละวัน ข้อมูลจะไหลเข้าตารางนี้ตลอดเวลา
- Enrollments (ตารางการลงทะเบียนเรียน):
- หน้าที่: เชื่อมโยงว่า “นักเรียนคนไหน” เรียน “วิชาอะไร” ใน “เทอมไหน”
- Columns: EnrollmentID, StudentID (FK), SubjectCode (FK), Semester, Year, Grade (เกรด)
- Note: ตรงนี้แหละค่ะที่เราจะใส่เกรด เราจะไม่ใส่เกรดในตารางนักเรียน เพราะนักเรียน 1 คนมีเกรดได้หลายวิชา
กฎเหล็ก 3 ข้อ เพื่อป้องกัน Database พัง
1. Primary Key (PK) ต้องมีทุกตาราง: ทุกบรรทัดต้องมีสิ่งที่ระบุตัวตนได้ชัดเจน เช่น รหัสนักเรียน (StudentID) ห้ามใช้ชื่อ-นามสกุลเป็นตัวระบุ เพราะคนชื่อซ้ำกันมีเยอะค่ะ
2. ใช้ Foreign Key (FK) เชื่อมโยงแทนการพิมพ์ซ้ำ: ในตารางลงทะเบียน (Enrollments) ห้ามพิมพ์ชื่อวิชา “คณิตศาสตร์” ลงไปตรงๆ แต่ให้ใส่รหัสวิชา “ว101” แทน ถ้าวันหนึ่งวิชานี้เปลี่ยนชื่อ เราแก้ที่ตาราง Subjects ที่เดียว ทุกอย่างจะเปลี่ยนตามทั้งหมด
3. Normalization (ลดความซ้ำซ้อน): ถ้าตารางไหนเริ่มมีข้อมูลซ้ำๆ ให้แตกตารางออกมา เช่น ถ้าในตารางนักเรียนมีช่อง “ชื่อผู้ปกครอง, เบอร์ผู้ปกครอง, อาชีพผู้ปกครอง” ซ้ำๆ กัน (พี่น้องเรียนโรงเรียนเดียวกัน) ควรแยก “ตารางผู้ปกครอง (Parents)” ออกมาต่างหาก แล้วเชื่อมด้วย ID ค่ะ
ตัวอย่างภาพรวมความสัมพันธ์ (ER Model)
ลองจินตนาการเส้นโยงความสัมพันธ์นะคะ:
- 1 นักเรียน —> ลงทะเบียนได้ —> หลายวิชา (One-to-Many)
- 1 วิชา —> มีนักเรียนเรียนได้ —> หลายคน (One-to-Many)
- 1 ครู —> สอนได้ —> หลายวิชา
การวางผังแบบนี้จะทำให้เวลาเราอยากรู้ว่า “เทอมนี้ ครูสมชายสอนนักเรียนกี่คน?” เราสามารถเขียนคำสั่ง (Query) ดึงข้อมูลเชื่อมโยงกันได้ทันที โดยไม่ต้องไปเปิดสมุดจดหลายๆ เล่มค่ะ
บทสรุป: ยอมลำบากตอนออกแบบ สบายตอนใช้งาน
การออกแบบ Database ที่ดีอาจใช้เวลาคิดวางแผนนานในช่วงแรก แต่ผลลัพธ์คือข้อมูลที่มีคุณภาพ (Data Integrity) ค่ะ
- รายงานแม่นยำ: ไม่มีปัญหายอดนักเรียนไม่ตรงกัน
- ขยายระบบง่าย: อนาคตอยากเพิ่มระบบห้องสมุด หรือระบบตัดเงินบัตรอาหาร ก็แค่สร้างตารางเพิ่มมาเชื่อมต่อกับ StudentID เดิมได้เลย
เริ่มจัดระเบียบข้อมูลวันนี้ เพื่อระบบโรงเรียนที่ยั่งยืนในวันหน้าค่ะ!
