EP02: หลักการพื้นฐานของระบบฐานข้อมูล และการออกแบบเบื้องต้นสำหรับข้อมูล IoT
May 29, 2568 June 5, 2025
📚 ภาคทฤษฎี
เป้าหมาย: สร้างความเข้าใจที่ลึกซึ้งเกี่ยวกับทางเลือกของประเภทฐานข้อมูลและสถาปัตยกรรมต่างๆ เพื่อให้นักศึกษาสามารถวิเคราะห์และตัดสินใจเบื้องต้นได้ว่าระบบแบบใดจะเหมาะสมกับข้อมูลที่หลากหลายในโรงงานอัจฉริยะ โดยเฉพาะข้อมูลจากอุปกรณ์ IoT
1. ประเภทของระบบฐานข้อมูล (Database Types) และความเหมาะสมกับข้อมูล IoT 📊
1.1 ระบบฐานข้อมูลเชิงสัมพันธ์ (Relational Databases – RDBMS): “ตู้เก็บเอกสารที่มีระเบียบแบบแผน”
แนวคิดหลัก: ลองจินตนาการถึงตู้เก็บเอกสารขนาดใหญ่ที่แต่ละลิ้นชัก (ตาราง – Tables) เก็บแฟ้มเอกสาร (แถว – Rows) ประเภทเดียวกัน และในแต่ละแฟ้มก็มีช่องใส่ข้อมูล (คอลัมน์ – Columns) ที่กำหนดไว้ชัดเจน เช่น แฟ้ม “ข้อมูลเครื่องจักร” จะมีช่องสำหรับ “รหัสเครื่องจักร”, “ชื่อเครื่องจักร”, “รุ่น” เสมอหัวใจสำคัญคือ “ความสัมพันธ์ (Relationships)”: แฟ้มในลิ้นชักต่างๆ สามารถอ้างอิงถึงกันได้ เช่น แฟ้ม “บันทึกการซ่อม” อาจมีช่อง “รหัสเครื่องจักรที่ซ่อม” เพื่อให้รู้ว่าเป็นการซ่อมเครื่องจักรเครื่องไหนในลิ้นชัก “ข้อมูลเครื่องจักร” การเชื่อมโยงนี้ทำผ่าน คีย์ (Keys)
Primary Key (กุญแจหลัก): เหมือนเลขประจำตัวประชาชนของแฟ้มแต่ละแฟ้มในลิ้นชัก ไม่ซ้ำกันเลย ทำให้หาแฟ้มนั้นเจอได้ทันทีForeign Key (กุญแจอ้างอิง): เหมือนการจดเลขประจำตัวประชาชนของแฟ้มจากลิ้นชักอื่นมาใส่ไว้ในแฟ้มปัจจุบัน เพื่อบอกว่าแฟ้มนี้เกี่ยวข้องกับแฟ้มนั้น
ภาษา SQL (Structured Query Language): เป็น “ภาษาคำสั่ง” ที่ใช้สั่งงานตู้เก็บเอกสารนี้ เช่น “ขอดูแฟ้มเครื่องจักรทุกเครื่องที่ติดตั้งหลังปี 2020” หรือ “เพิ่มแฟ้มเครื่องจักรใหม่เข้าไป”คุณสมบัติ ACID (Atomicity, Consistency, Isolation, Durability): เปรียบเสมือน “ระบบประกันคุณภาพ” ของตู้เก็บเอกสาร ทำให้มั่นใจว่าทุกการเปลี่ยนแปลงข้อมูลจะถูกต้อง ครบถ้วน ไม่ว่าจะเกิดเหตุการณ์ไม่คาดฝันอะไรขึ้นก็ตาม
เน้นย้ำ: ACID สำคัญมากสำหรับข้อมูลที่ต้องการความแม่นยำสูง เช่น ข้อมูลทางการเงิน หรือข้อมูลการตั้งค่าที่สำคัญของเครื่องจักรในโรงงาน
จุดเด่น:
ข้อมูลเป็นระเบียบ แม่นยำสูง: เหมาะกับข้อมูลที่ต้องตรวจสอบความถูกต้องอยู่เสมอโครงสร้างชัดเจน เข้าใจง่าย (เมื่อคุ้นเคย): เมื่อออกแบบดีแล้ว การค้นหาและเชื่อมโยงข้อมูลทำได้ดี
ข้อจำกัด:
ไม่ค่อยยืดหยุ่นกับข้อมูลที่เปลี่ยนรูปแบบบ่อยๆ: ถ้าจู่ๆ อยากเพิ่มช่องข้อมูลใหม่ๆ ในแฟ้มทุกแฟ้ม อาจต้องรื้อระบบตู้กันพอสมควรการรับมือกับข้อมูลจำนวนมหาศาลมากๆ และเติบโตเร็วมาก อาจต้องใช้ตู้ที่ใหญ่และแพงมาก (Vertical Scaling): หรือการทำสำเนาหลายตู้แล้วให้ทำงานร่วมกัน (Horizontal Scaling) อาจจะซับซ้อน
ความเหมาะสมกับข้อมูล IoT ในโรงงานอัจฉริยะ:
ข้อมูลอ้างอิง (Master Data): ข้อมูลจำเพาะของเครื่องจักรแต่ละเครื่อง, รายละเอียดของผลิตภัณฑ์แต่ละชนิด, ข้อมูลผู้ใช้งานระบบข้อมูลการกำหนดค่า (Configuration Data): พารามิเตอร์การทำงานของเครื่องจักร, สูตรการผลิตข้อมูล Transaction ที่สำคัญ: ประวัติการสั่งงานเครื่องจักร, ผลการตรวจสอบคุณภาพที่สำคัญมากๆ
1.2 ระบบฐานข้อมูลแบบ NoSQL (Not Only SQL): “ห้องสมุดที่มีชั้นหนังสือหลากหลายรูปแบบ”
แนวคิดหลัก: ไม่ได้มีแค่ “ตู้เก็บเอกสารแบบเดียว” แต่เหมือนห้องสมุดที่มีชั้นหนังสือหลายแบบ บางชั้นอาจเก็บม้วนกระดาษ (Document), บางชั้นเก็บกล่องเล็กๆ ที่มีป้ายชื่อ (Key-Value), บางชั้นเก็บแฟ้มขนาดใหญ่มาก (Column-Family), หรือบางชั้นมีแผนผังโยงใยความสัมพันธ์ของหนังสือ (Graph) ออกแบบมาเพื่อรองรับข้อมูลที่ “ไม่เป็นระเบียบ” เท่า RDBMS หรือข้อมูลที่ “เยอะและเร็ว” มากๆความยืดหยุ่นคือจุดขาย (Schema Flexibility): ไม่จำเป็นต้องกำหนดช่องข้อมูลตายตัวเสมอไป ทำให้เก็บข้อมูลที่หลากหลายได้ง่ายประเภทหลักของ NoSQL และความเหมาะสมกับข้อมูล IoT (พร้อมตัวอย่างเปรียบเทียบเพิ่มเติม):
Document Databases (เช่น MongoDB): “ชั้นเก็บม้วนรายงานการทดลอง”
แต่ละ “ม้วน” (เอกสาร JSON/BSON) คือข้อมูลของสิ่งหนึ่ง เช่น “รายงานผลจากเซ็นเซอร์ตัวที่ 1 วันนี้” ซึ่งอาจมีรายละเอียดไม่เท่ากับ “รายงานผลจากเซ็นเซอร์ตัวที่ 2” ก็ได้
เหมาะกับ IoT: ข้อมูล Log จากอุปกรณ์, ข้อมูล Profile ของเซ็นเซอร์แต่ละตัวที่อาจมีคุณสมบัติปลีกย่อยต่างกัน, ผลการอ่านค่าจากเซ็นเซอร์ที่ซับซ้อนและมีหลายมิติ
Key-Value Stores (เช่น Redis): “ตู้ล็อกเกอร์เก็บของพร้อมป้ายชื่อ”
มี “ป้ายชื่อ” (Key) ที่ไม่ซ้ำกัน และ “ของในล็อกเกอร์” (Value) ซึ่งเป็นอะไรก็ได้ เข้าถึงของได้เร็วมากถ้าจำป้ายชื่อได้
เหมาะกับ IoT: เก็บค่าสถานะล่าสุดของเซ็นเซอร์ (เช่น “อุณหภูมิห้อง_A_ล่าสุด”: “25.5 C”), เก็บข้อมูล Session ของผู้ใช้ที่กำลังดู Dashboard, ทำ Cache ข้อมูลที่ดึงบ่อยๆ
Column-Family (Wide-Column) Stores (เช่น Apache Cassandra): “ห้องเก็บเอกสารขนาดใหญ่ที่จัดเรียงตามหัวเรื่องหลัก”
เหมาะกับการเก็บข้อมูลจำนวนมหาศาลที่ “หัวเรื่องหลัก” (Row Key เช่น SensorID+Timestamp) เหมือนกัน แต่ “รายละเอียดปลีกย่อย” (Columns) อาจมีเยอะมากและไม่จำเป็นต้องมีครบทุกหัวเรื่อง
เหมาะกับ IoT: ข้อมูลอนุกรมเวลา (Time-Series Data) จากเซ็นเซอร์จำนวนมาก ที่ส่งค่าเข้ามาอย่างต่อเนื่อง เช่น ค่าอุณหภูมิ, แรงดัน, การสั่นสะเทือน จากเซ็นเซอร์หลายร้อยตัว ทุกๆ เสี้ยววินาที
Graph Databases (เช่น Neo4j): “แผนผังเครือข่ายความสัมพันธ์ของตัวละครในนิยาย”
เน้นที่ “ใคร” (Nodes) เกี่ยวข้องกับ “ใคร” (Nodes) อย่างไร (Relationships)
เหมาะกับ IoT: วิเคราะห์ว่าอุปกรณ์ใดเชื่อมต่อกับอุปกรณ์ใดบ้างในเครือข่ายโรงงาน, ติดตามว่าวัตถุดิบชิ้นนี้ผ่านเครื่องจักรใดมาบ้าง, หาจุดที่อาจเป็นคอขวดในสายการผลิตจากความสัมพันธ์ของกระบวนการ
จุดเด่น:
รับมือข้อมูลหลากหลายรูปแบบได้ดี ขยายระบบเพื่อรองรับข้อมูลจำนวนมากได้ง่าย (Horizontal Scaling) โดยการเพิ่มเครื่องเซิร์ฟเวอร์เข้าไปในกลุ่มเร็วสำหรับการอ่าน/เขียนข้อมูลบางประเภท
ข้อจำกัด:
ความเข้มงวดเรื่องความถูกต้องของข้อมูลอาจน้อยกว่า RDBMS (บางระบบอาจใช้ Eventual Consistency – ข้อมูลอาจจะยังไม่เหมือนกันทุกที่ในทันที แต่สุดท้ายจะเหมือนกัน)การ Query ข้อมูลที่ซับซ้อนมากๆ และต้องเชื่อมโยงหลายส่วน อาจทำได้ยากกว่า RDBMS (ถ้าไม่ได้ออกแบบมาเพื่อการนั้นโดยเฉพาะ)
2. สถาปัตยกรรมระบบฐานข้อมูล (Database Architectures) 🏗️
2.1 สถาปัตยกรรมแบบไคลเอนต์-เซิร์ฟเวอร์ (Client-Server Architecture): “ร้านอาหารที่มีลูกค้าและห้องครัว”
แนวคิด:
ไคลเอนต์ (Client): คือ “ลูกค้า” ที่มาสั่งอาหาร (ร้องขอข้อมูล/บริการ) เช่น แอปพลิเคชันบนมือถือที่ใช้ดูกราฟอุณหภูมิ, หน้าจอ HMI ที่เครื่องจักร, โปรแกรมบน PC ที่ใช้ป้อนข้อมูลการผลิตเซิร์ฟเวอร์ (Server): คือ “ห้องครัวและพ่อครัว” ที่รับออเดอร์ (คำสั่ง) ไปปรุงอาหาร (ประมวลผลข้อมูล) และนำมาเสิร์ฟ (ส่งผลลัพธ์) นั่นคือ Database Server ที่มี DBMS และฐานข้อมูลอยู่
การทำงาน: ลูกค้า (Client) บอกรายการอาหาร (Request) -> พนักงานเสิร์ฟ (Network) นำไปให้ห้องครัว (Server) -> ห้องครัวปรุง (Process) -> พนักงานเสิร์ฟนำอาหารมาให้ลูกค้า (Response)ระดับของ Client-Server (Tiers):
2-Tier: ลูกค้าคุยกับพ่อครัวโดยตรง (Client <-> Database Server) ง่าย แต่ถ้าลูกค้าเยอะ พ่อครัวอาจจะงง3-Tier/N-Tier: มี “ผู้จัดการร้าน/แคชเชียร์” (Application Server) คั่นกลาง ลูกค้าสั่งอาหารกับผู้จัดการร้าน ผู้จัดการร้านประสานงานกับห้องครัวอีกที ช่วยแบ่งเบาภาระและจัดการระบบได้ดีขึ้น (Client <-> App Server <-> Database Server)
ข้อดี:
จัดการง่ายที่ “ห้องครัว” (Server): สูตรอาหาร, วัตถุดิบ, ความสะอาด อยู่ที่ส่วนกลาง“ลูกค้า” (Client) ไม่ต้องทำงานหนัก: แค่สั่งกับรอรับอาหาร
ข้อเสีย:
ถ้า “ห้องครัว” ปิด (Server Down): ลูกค้าทุกคนอดกิน (Single Point of Failure)ถ้าลูกค้ามาพร้อมกันเยอะๆ “ห้องครัว” อาจทำไม่ทัน (Bottleneck): ต้องมีระบบจัดการคิวที่ดี หรือขยายห้องครัว
การประยุกต์ในโรงงานอัจฉริยะ: ระบบควบคุมการผลิตส่วนกลาง, ระบบแสดงผล Dashboard, โปรแกรมบำรุงรักษาที่เชื่อมต่อกับฐานข้อมูลเครื่องจักร
2.2 สถาปัตยกรรมแบบกระจาย (Distributed Database Architecture): “เครือข่ายร้านอาหารแฟรนไชส์”
แนวคิด: แทนที่จะมีร้านอาหารใหญ่ร้านเดียว เรามี “ร้านสาขา” หลายร้านกระจายอยู่ตามที่ต่างๆ แต่ละร้านอาจมีเมนูหลักเหมือนกัน (Homogeneous) หรือมีเมนูพิเศษของตัวเอง (Heterogeneous) และข้อมูล (เช่น สูตรอาหาร, ยอดขาย) อาจจะเก็บแยกกันที่แต่ละสาขา หรือมีการทำสำเนาส่งถึงกัน หรือแบ่งส่วนกันดูแลเหตุผลที่ต้องมี “ร้านสาขา”:
ลูกค้าที่อยู่ใกล้สาขาไหน ก็ไปสาขานั้นได้เลย (เข้าถึงข้อมูลเร็ว)
ถ้าสาขาหนึ่งปิดปรับปรุง สาขาอื่นยังเปิดบริการได้ (ระบบไม่ล่มทั้งหมด – High Availability)
รองรับลูกค้าจำนวนมากได้พร้อมกัน โดยกระจายไปตามสาขาต่างๆ
รูปแบบการกระจายข้อมูล:
การทำสำเนา (Replication): “ทุกสาขามีสูตรอาหารเดียวกันเป๊ะๆ”
ข้อดี: อ่านข้อมูลเร็ว (ลูกค้าไม่ต้องรอสูตรจากส่วนกลาง), ถ้าสาขาหลักมีปัญหา สาขาอื่นยังมีสูตรทำอาหารได้ข้อเสีย: ถ้ามีการเปลี่ยนสูตรใหม่ ต้องแจ้งทุกสาขาให้ตรงกัน (อาจเกิดความล่าช้า), เปลืองที่เก็บสูตร (ข้อมูลซ้ำซ้อน)
การแบ่งส่วน (Fragmentation): “สาขานี้ดูแลเมนูเส้น สาขานั้นดูแลเมนูข้าว”
Horizontal Fragmentation: แบ่งตามลูกค้า เช่น ลูกค้าโซนเหนือเข้าร้านสาขาเชียงใหม่ ลูกค้าโซนใต้เข้าร้านสาขาหาดใหญ่Vertical Fragmentation: แบ่งตามประเภทข้อมูล เช่น แผนกบัญชีเก็บข้อมูลราคา แผนกครัวเก็บข้อมูลสูตรข้อดี: แต่ละสาขาดูแลเฉพาะส่วนของตัวเอง, ลดข้อมูลที่ไม่จำเป็นในแต่ละที่ข้อเสีย: ถ้าลูกค้าต้องการสั่งทั้งข้าวและเส้น อาจต้องมีการประสานงานระหว่างสาขา (Query ซับซ้อน)
ข้อดี:
น่าเชื่อถือสูง ระบบไม่ล่มง่าย เข้าถึงข้อมูลได้รวดเร็วสำหรับผู้ใช้ในพื้นที่นั้นๆ ขยายระบบได้ง่าย (เพิ่มสาขาใหม่)
ข้อเสีย:
ออกแบบและจัดการซับซ้อนมาก การทำให้ข้อมูลทุกสาขา “ตรงกัน” และ “ทันสมัย” เป็นเรื่องท้าทาย ค่าใช้จ่ายสูง
การประยุกต์ในโรงงานอัจฉริยะ:
บริษัทที่มีโรงงานหลายแห่งทั่วโลก แต่ละแห่งมีฐานข้อมูลการผลิตของตนเอง และมีการส่งข้อมูลสรุปที่สำคัญไปยังฐานข้อมูลกลางของสำนักงานใหญ่
ระบบ IoT ขนาดใหญ่ที่ใช้ Edge Computing โดยมีฐานข้อมูลขนาดเล็กเก็บและประมวลผลข้อมูลเบื้องต้นที่ “ขอบ” ของเครือข่าย (ใกล้กับเซ็นเซอร์) ก่อนส่งข้อมูลที่จำเป็นไปยัง Cloud Database ส่วนกลาง
🛠️ ภาคปฏิบัติ
เป้าหมาย: ฝึกฝนกระบวนการคิดวิเคราะห์เพื่อแปลงความต้องการของระบบในโรงงานอัจฉริยะออกมาเป็น “สิ่งที่ต้องเก็บข้อมูล (Entities)” และ “รายละเอียดของสิ่งนั้นๆ (Attributes)” ซึ่งเป็นหัวใจสำคัญของการเริ่มต้นออกแบบฐานข้อมูล
ส่วนที่ 1: ทบทวนจากสัปดาห์ที่ 1 และปูทางสู่การวิเคราะห์ความต้องการข้อมูล
ทบทวน: ผู้สอนทบทวนภาพรวมของข้อมูลที่ได้จาก MCU (อุณหภูมิ, ความชื้น, สถานะสวิตช์ ฯลฯ) จากปฏิบัติการสัปดาห์ที่ 1เชื่อมโยง:
“จากสัปดาห์ที่แล้ว เราเห็นข้อมูลดิบจากเซ็นเซอร์ เช่น ‘27.5’, ’60’, ‘ON’ ข้อมูลเหล่านี้มีประโยชน์ในตัวเอง แต่ถ้าเราต้องการนำไปใช้ในวงกว้าง เช่น วิเคราะห์ว่าเครื่องจักรตัวไหนทำงานผิดปกติ หรือห้องไหนร้อนเกินไป เราต้องจัดเก็บข้อมูลเหล่านี้อย่างเป็นระบบเสียก่อน”
“ก่อนจะสร้าง ‘บ้าน’ (ฐานข้อมูล) เราต้องรู้ว่าเราอยากให้บ้านมีกี่ห้อง (Entities) และแต่ละห้องจะเก็บอะไรบ้าง (Attributes) นี่คือสิ่งที่เราจะทำกันในวันนี้: การวิเคราะห์ความต้องการข้อมูล”
ส่วนที่ 2: การวิเคราะห์ความต้องการข้อมูลจากกระบวนการผลิตและอุปกรณ์ MCU: “ล้วงลึกความต้องการของโรงงาน” 📝⚙️
หลักการและขั้นตอน (เน้นการตั้งคำถาม WHY, WHAT, WHO, WHERE, WHEN, HOW):
กำหนดขอบเขตของระบบ (System Scope): “เรากำลังจะสร้างระบบอะไรกันแน่?”
WHY: ทำไมต้องมีระบบนี้? แก้ปัญหาอะไร? เพิ่มประสิทธิภาพด้านไหน? (เช่น เพื่อลดของเสีย, เพื่อคาดการณ์การเสียของเครื่องจักร)WHAT: ระบบนี้จะทำอะไรได้บ้าง? (เช่น เก็บข้อมูลอุณหภูมิ, แสดงผลกราฟ, แจ้งเตือน)
ระบุผู้มีส่วนได้ส่วนเสีย (Stakeholders) และความต้องการของพวกเขา: “ใครอยากรู้ข้อมูลอะไรจากระบบนี้ และจะเอาไปทำอะไร?”
WHO: ผู้จัดการฝ่ายผลิต, วิศวกร, ช่างเทคนิค, ผู้ควบคุมคุณภาพ, หรือแม้กระทั่งลูกค้า (ถ้าเป็นข้อมูลที่เปิดเผยได้)WHAT information do they need?: พวกเขาต้องการดูรายงานแบบไหน? ข้อมูลอะไรบ้างที่จำเป็นต่อการตัดสินใจหรือการทำงานของพวกเขา? (เช่น ผู้จัดการอาจต้องการดู OEE, วิศวกรอาจต้องการดูกราฟการสั่นสะเทือนของมอเตอร์)HOW will they use it?: ดูผ่าน Dashboard? Export เป็น Excel? รับแจ้งเตือนผ่าน Line/Email?
ระบุแหล่งข้อมูล (Data Sources): “ข้อมูลที่เราต้องการมาจากไหนบ้าง?”
ข้อมูลจาก MCU และเซ็นเซอร์ (เน้นย้ำ):
WHAT sensors are used?: DHT22 (Temp/Humid), HC-SR04 (Distance), ACS712 (Current), Photoelectric Sensor (Object Detection), Vibration Sensor, etc.WHAT data do they provide?: ตัวเลขอุณหภูมิ, ค่าความชื้น, ระยะทาง, กระแสไฟฟ้า, สถานะ (ON/OFF), จำนวนครั้งที่ตรวจจับWHEN/HOW OFTEN is data collected?: ทุกวินาที? ทุก 5 นาที? เมื่อมีการเปลี่ยนแปลง?
ข้อมูลจากมนุษย์ป้อน (Manual Input):
WHAT data?: รหัสพนักงานที่ปฏิบัติงาน, สาเหตุการหยุดเครื่องจักร (Downtime Codes), หมายเหตุการตรวจสอบWHO inputs it?: พนักงานหน้าเครื่อง, ช่างซ่อม
ข้อมูลจากระบบอื่น (Other Systems):
WHAT data?: รายการคำสั่งผลิตจากระบบ ERP (Enterprise Resource Planning), มาตรฐานคุณภาพจากระบบ QMS (Quality Management System)
รวบรวมและระบุ “รายการข้อมูล” ที่สำคัญ (Gather and List Key Data “Items”):
จากการตอบคำถามข้างต้น ให้ลิสต์ “คำนาม” หรือ “วลี” ที่เป็นข้อมูลที่เราต้องสนใจออกมาให้หมดก่อน
ตัวอย่าง: “รหัสเครื่องจักร”, “อุณหภูมิปัจจุบันของมอเตอร์ตัวที่ 1”, “เวลาที่เครื่องจักร X หยุดทำงาน”, “ชื่อผู้ควบคุมกะปัจจุบัน”, “จำนวนสินค้าดีที่ผลิตได้ในชั่วโมงนี้”, “ค่าความสั่นสะเทือนแกน X ของปั๊มน้ำ Y”
วิเคราะห์คุณลักษณะเบื้องต้นของ “รายการข้อมูล” แต่ละรายการ:
ชนิดข้อมูลคร่าวๆ: เป็นตัวเลข? เป็นข้อความ? เป็นวันเวลา? หรือเป็นแค่ ใช่/ไม่ใช่?ความถี่ที่ข้อมูลนี้จะถูกบันทึกหรือเปลี่ยนแปลง ความสำคัญของข้อมูลนี้ (จำเป็นมาก/มีก็ดี/ไม่ค่อยจำเป็น)
กิจกรรมกลุ่มย่อย: “สวมบทบาทนักสืบข้อมูลในโรงงานจำลอง” (Smart Factory Case Study Analysis)
ผู้สอนเตรียม สถานการณ์จำลอง (Case Study) ที่มีรายละเอียดชัดเจนขึ้นเล็กน้อยเกี่ยวกับ “ปัญหา” หรือ “เป้าหมาย” ของโรงงานจำลองนั้นๆ (อาจเป็น Case Study เดียวกับสัปดาห์ที่ 1 แต่เพิ่มรายละเอียดความต้องการเชิงข้อมูล)
ตัวอย่าง Case Study (ปรับปรุง): ระบบเฝ้าระวังและแจ้งเตือนสภาพแวดล้อมในห้องควบคุมหลัก (Main Control Room Monitoring System)
ปัญหา/เป้าหมาย: ห้องควบคุมหลักมีอุปกรณ์อิเล็กทรอนิกส์ราคาแพงและมีความสำคัญสูง หากอุณหภูมิสูงหรือต่ำเกินไป หรือมีความชื้นมากไป อาจทำให้อุปกรณ์เสียหายหรือทำงานผิดพลาดได้ ต้องการระบบที่สามารถเฝ้าระวังและแจ้งเตือนผู้ดูแลได้ทันท่วงที และสามารถดูข้อมูลย้อนหลังเพื่อวิเคราะห์แนวโน้มได้MCU & Sensors ที่ใช้:
NodeMCU (ESP8266) จำนวน 2 ตัว ติดตั้งคนละมุมห้อง
แต่ละ NodeMCU ต่อกับเซ็นเซอร์ DHT22 (วัดอุณหภูมิและความชื้น) และเซ็นเซอร์ตรวจจับควัน (MQ-2)
ข้อมูลอุณหภูมิและความชื้นถูกส่งทุก 1 นาที, ข้อมูลควันถูกส่งเมื่อมีการตรวจพบควัน
ผู้เกี่ยวข้อง (Stakeholders) และความต้องการ:
ผู้ดูแลระบบ (System Administrator):
ต้องการดูค่าอุณหภูมิ, ความชื้น, และสถานะควัน (ปกติ/มีควัน) ล่าสุดจากเซ็นเซอร์ทุกตัวแบบ Real-time บน Dashboard
ต้องการรับ SMS หรือ Email แจ้งเตือนทันทีเมื่อ:
อุณหภูมิสูงกว่า 30°C หรือต่ำกว่า 18°C
ความชื้นสูงกว่า 70%
ตรวจพบควัน
ต้องการดูกราฟแสดงประวัติอุณหภูมิและความชื้นย้อนหลังได้ 7 วัน เพื่อดูแนวโน้ม
หัวหน้าฝ่าย IT (IT Manager):
ต้องการดูรายงานสรุปจำนวนครั้งที่เกิดการแจ้งเตือนในแต่ละสัปดาห์/เดือน แยกตามประเภทการแจ้งเตือน
ต้องการทราบว่าเซ็นเซอร์ตัวไหนแจ้งเตือนบ่อยที่สุด
การดำเนินกิจกรรม:
แบ่งนักศึกษาเป็นกลุ่ม
ให้แต่ละกลุ่ม “สวมบทบาท” เป็นทีมวิเคราะห์ระบบที่ได้รับมอบหมายให้ทำ Case Study นี้
ใช้คำถาม WHY, WHAT, WHO, WHERE, WHEN, HOW เพื่อเจาะลึกความต้องการข้อมูล:
WHY: ทำไมต้องเก็บอุณหภูมิ? ทำไมต้องเก็บทุก 1 นาที? ทำไมผู้ดูแลต้องรู้?WHAT: ข้อมูลอะไรบ้างที่จำเป็น (อุณหภูมิ, ความชื้น, สถานะควัน, เวลาที่บันทึก, รหัสเซ็นเซอร์, ตำแหน่งเซ็นเซอร์, ประเภทการแจ้งเตือน, เวลาที่แจ้งเตือน, ข้อความแจ้งเตือน ฯลฯ)?WHO: ใครเป็นคนสร้างข้อมูลนี้ (เซ็นเซอร์)? ใครเป็นคนใช้ข้อมูลนี้ (ผู้ดูแล, หัวหน้า)?WHERE: ข้อมูลนี้มาจากเซ็นเซอร์ตัวไหน ตำแหน่งใด?WHEN: ข้อมูลนี้ถูกบันทึกเมื่อไหร่? การแจ้งเตือนเกิดขึ้นเมื่อไหร่?HOW: ข้อมูลนี้มีรูปแบบอย่างไร (ตัวเลขทศนิยม, ข้อความ, วันที่เวลา)?
ให้แต่ละกลุ่ม ลิสต์ “รายการข้อมูล” ที่สำคัญทั้งหมด ที่ต้องจัดเก็บออกมาให้ละเอียดที่สุดเท่าที่จะทำได้ พร้อมระบุแหล่งที่มา (เช่น จาก DHT22, จาก MQ-2, ระบบสร้างเอง) และความถี่คร่าวๆ
ส่วนที่ 3: แนวคิดการออกแบบฐานข้อมูลเบื้องต้น: จาก “รายการข้อมูล” สู่ “กลุ่มก้อนของข้อมูล (Entity & Attribute Identification)” ✏️🧱
การจัดระเบียบ “รายการข้อมูล”:
ผู้สอนอธิบายว่า “รายการข้อมูล” ที่ได้จากส่วนที่ 2 นั้นยังกระจัดกระจายอยู่ เราต้องนำมาจัดกลุ่มให้เป็นหมวดหมู่ที่สมเหตุสมผล ซึ่งก็คือการระบุ Entities และ Attributes
Entity (เอนทิตี): “กลุ่มก้อนหลักของข้อมูลที่เราสนใจ”
วิธีการมองหา Entity:
มองหา “คำนาม” หลักๆ ใน Case Study หรือในรายการข้อมูล (เช่น Sensor, Reading, Alert, Room, User)
ลองคิดว่า “อะไรคือสิ่งที่เราต้องการเก็บข้อมูลหลายๆ อย่างเกี่ยวกับมัน?”
จาก Case Study “ระบบเฝ้าระวังห้องควบคุม”:
อาจจะมี Entities เช่น: SENSOR_DEVICE (อุปกรณ์เซ็นเซอร์แต่ละตัว), ENVIRONMENTAL_READING (ข้อมูลการอ่านค่าสภาพแวดล้อมแต่ละครั้ง), ALERT_EVENT (เหตุการณ์การแจ้งเตือนแต่ละครั้ง), CONTROL_ROOM (ข้อมูลห้องควบคุม ถ้ามีหลายห้อง)
Attribute (แอตทริบิวต์): “รายละเอียดหรือคุณสมบัติของแต่ละกลุ่มก้อน”
วิธีการกำหนด Attribute:
นำ “รายการข้อมูล” ที่ลิสต์ไว้ มาพิจารณาว่าแต่ละรายการควรจะไปอยู่ใน Entity ไหน
“ข้อมูลนี้ใช้อธิบาย Entity ใด?”
ตัวอย่าง Attributes สำหรับ SENSOR_DEVICE (จาก Case Study):
DeviceID (รหัสเฉพาะของอุปกรณ์เซ็นเซอร์)DeviceType (เช่น “DHT22”, “MQ-2”)LocationInRoom (เช่น “มุมซ้ายหน้า”, “ติดเพดานกลางห้อง”)RoomID_FK (รหัสห้องที่ติดตั้ง – ถ้ามีหลายห้อง)InstallationDate (วันที่ติดตั้ง)Status (เช่น “Active”, “Inactive”, “Maintenance”)
ตัวอย่าง Attributes สำหรับ ENVIRONMENTAL_READING (จาก Case Study):
ReadingID (รหัสการอ่านค่าแต่ละครั้ง)DeviceID_FK (รหัสอุปกรณ์เซ็นเซอร์ที่ส่งค่านี้มา)Timestamp (วันเวลาที่บันทึกค่า)TemperatureValue (ค่าอุณหภูมิ – อาจเป็น Null ถ้าเซ็นเซอร์ไม่ใช่ตัววัดอุณหภูมิ)HumidityValue (ค่าความชื้น – อาจเป็น Null)SmokeDetected (สถานะการตรวจพบควัน – True/False)
ตัวอย่าง Attributes สำหรับ ALERT_EVENT (จาก Case Study):
AlertID (รหัสการแจ้งเตือน)ReadingID_FK (รหัสการอ่านค่าที่ทำให้เกิดการแจ้งเตือนนี้ – ถ้าเกี่ยวข้อง)DeviceID_FK (รหัสอุปกรณ์ที่เกี่ยวข้องกับการแจ้งเตือน)AlertType (เช่น “High Temperature”, “Low Temperature”, “High Humidity”, “Smoke Detected”)AlertTimestamp (วันเวลาที่เกิดการแจ้งเตือน)AlertMessage (ข้อความที่ส่งแจ้งเตือน)AcknowledgedStatus (สถานะการรับทราบการแจ้งเตือน – True/False)AcknowledgedBy_UserID_FK (รหัสผู้ใช้ที่รับทราบ – ถ้ามีระบบ User)
กิจกรรมกลุ่มย่อย: “สร้างพิมพ์เขียวข้อมูลเบื้องต้น”
ให้แต่ละกลุ่มนำ “รายการข้อมูล” ที่ได้จาก Case Study ของตนเองในส่วนที่ 2 มาทำงานต่อ
ระดมสมองเพื่อกำหนด Entities หลักๆ ที่เกี่ยวข้อง (ตั้งเป้า 3-5 Entities ก่อน)สำหรับแต่ละ Entity ที่ระบุได้ ให้ ลิสต์ Attributes ที่เกี่ยวข้อง ให้ครบถ้วนที่สุด โดยอ้างอิงจากรายการข้อมูลเดิม และอาจเพิ่มเติม Attributes ที่จำเป็นอื่นๆ (เช่น ID ต่างๆ, วันที่สร้างข้อมูล)
ลองพิจารณาว่า Attribute ไหนในแต่ละ Entity ที่น่าจะเป็น “ตัวแทน” หรือ “รหัสอ้างอิง” (Primary Key เบื้องต้น) ของ Entity นั้นได้ (ต้องไม่ซ้ำ)(เสริม ถ้ามีเวลา) ลองวาดภาพง่ายๆ แสดงว่า Entity ไหนน่าจะ “คุย” หรือ “เกี่ยวข้อง” กับ Entity ไหนบ้าง (เป็นการปูทางไปสู่เรื่อง Relationship ในสัปดาห์หน้า)
ให้นักศึกษาบันทึกผลงาน โดยอาจเขียนในรูปแบบ: Entity: [ชื่อ Entity] Attributes: - [ชื่อ Attribute 1] (ลักษณะข้อมูล: เช่น ตัวเลข, ข้อความ) - [ชื่อ Attribute 2] (PK) (ลักษณะข้อมูล: ...) - ... Entity: [ชื่อ Entity อื่น] Attributes: - ...
