30105-2013

EP03: การสร้างแบบจำลองข้อมูลสำหรับโรงงานอัจฉริยะ

📚 ภาคทฤษฎี

เป้าหมาย: สร้างความเข้าใจที่ลึกซึ้งเกี่ยวกับแนวคิด หลักการ และองค์ประกอบสำคัญของ Entity-Relationship Diagram (ERD) เพื่อให้สามารถนำไปประยุกต์ใช้ในการออกแบบฐานข้อมูลสำหรับโรงงานอัจฉริยะได้อย่างถูกต้อง

1. บทนำสู่การสร้างแบบจำลองข้อมูล (Introduction to Data Modeling)

  • 1.1 ความหมายและความสำคัญของการสร้างแบบจำลองข้อมูล:
    • การสร้างแบบจำลองข้อมูล (Data Modeling) คืออะไร?
      • มันไม่ใช่แค่การวาดรูป แต่เป็น กระบวนการวิเคราะห์และกำหนดโครงสร้างข้อมูล ที่องค์กรหรือระบบต้องการจัดเก็บและใช้งาน
      • เป็นการ สร้างพิมพ์เขียว (Blueprint) สำหรับฐานข้อมูล เปรียบเหมือนสถาปนิกออกแบบบ้านก่อนลงมือก่อสร้างจริง
      • ผลลัพธ์ที่ได้มักจะเป็น แบบจำลองข้อมูล (Data Model) ซึ่งมีหลายระดับ เช่น Conceptual (แนวคิด), Logical (เชิงตรรกะ), และ Physical (เชิงกายภาพ) โดย ERD ที่เราจะเรียนกันจัดอยู่ในระดับ Conceptual ถึง Logical
    • ทำไมการสร้างแบบจำลองข้อมูลจึงสำคัญ?
      • ความเข้าใจที่ตรงกัน (Shared Understanding): ช่วยให้ทุกคนที่เกี่ยวข้อง (นักวิเคราะห์ระบบ, ผู้ออกแบบฐานข้อมูล, โปรแกรมเมอร์, ผู้ใช้งาน) เห็นภาพเดียวกันว่าระบบจะจัดเก็บข้อมูลอะไรบ้าง มีความสัมพันธ์กันอย่างไร
      • ลดความซับซ้อน (Manage Complexity): ระบบงานจริงมักมีความซับซ้อน แบบจำลองข้อมูลช่วยให้เรามองเห็นโครงสร้างที่จำเป็นและตัดทอนส่วนที่ไม่เกี่ยวข้องออกไปได้
      • พื้นฐานสำหรับการออกแบบฐานข้อมูลที่ดี (Foundation for Good Database Design): แบบจำลองที่ดีจะนำไปสู่ฐานข้อมูลที่มีประสิทธิภาพ ลดความซ้ำซ้อนของข้อมูล (Data Redundancy) และรักษาความถูกต้องของข้อมูล (Data Integrity)
      • ช่วยในการสื่อสาร (Communication Tool): ERD เป็นภาษากลางที่ใช้อธิบายโครงสร้างข้อมูลให้ผู้อื่นเข้าใจได้ง่าย
      • เอกสารประกอบระบบ (Documentation): เป็นส่วนสำคัญของเอกสารระบบที่ใช้อ้างอิงในการพัฒนาและบำรุงรักษาระบบในอนาคต

2. องค์ประกอบหลักของ Entity-Relationship Diagram (ERD) 🖼️

  • 2.1 Entity (เอนทิตี):
    • ทบทวนนิยาม: สิ่งใดๆ ที่เราสนใจและต้องการจัดเก็บข้อมูลเกี่ยวกับมัน สามารถระบุตัวตนและแยกแยะออกจากสิ่งอื่นได้ (เช่น บุคคล, สถานที่, สิ่งของ, เหตุการณ์, แนวคิด)
    • การระบุ Entity: มักจะมาจาก “คำนาม” ที่สำคัญในคำอธิบายความต้องการของระบบ หรือจากการวิเคราะห์กระบวนการทำงาน
      • ตัวอย่างในโรงงานอัจฉริยะ: MACHINE (เครื่องจักร), SENSOR (เซ็นเซอร์), PRODUCT (ผลิตภัณฑ์), PRODUCTION_BATCH (รุ่นการผลิต), MAINTENANCE_LOG (บันทึกการบำรุงรักษา), OPERATOR (ผู้ควบคุมเครื่อง)
    • Entity Instance (หรือ Record): คือ สมาชิกแต่ละตัวของ Entity นั้นๆ เช่น ถ้า MACHINE เป็น Entity, เครื่องจักร A, เครื่องจักร B ก็คือ Instance ของ MACHINE
    • สัญลักษณ์: โดยทั่วไปคือรูปสี่เหลี่ยมผืนผ้า (Rectangle) ที่มีชื่อ Entity เขียนอยู่ภายใน (มักใช้ตัวพิมพ์ใหญ่)
  • 2.2 Attribute (แอตทริบิวต์):
    • ทบทวนนิยาม: คุณสมบัติหรือลักษณะที่อธิบายรายละเอียดของ Entity หนึ่งๆ
    • การระบุ Attribute: มาจากคุณสมบัติที่เราต้องการทราบเกี่ยวกับ Entity นั้นๆ
      • ตัวอย่าง Attributes ของ Entity MACHINE: MachineID, MachineName, ModelNumber, InstallationDate, Status
      • ตัวอย่าง Attributes ของ Entity SENSOR_READING: ReadingTimestamp, SensorID_FK, Value, UnitOfMeasure
    • ประเภทของ Attributes (อาจจะยังไม่ลงลึกมากในสัปดาห์นี้ แต่เกริ่นได้):
      • Simple Attribute: ไม่สามารถแบ่งย่อยได้อีก (เช่น MachineName)
      • Composite Attribute: สามารถแบ่งย่อยออกเป็นส่วนๆ ได้ (เช่น Address อาจประกอบด้วย Street, City, ZipCode)
      • Single-valued Attribute: มีได้เพียงค่าเดียวสำหรับแต่ละ Instance (เช่น MachineID)
      • Multi-valued Attribute: อาจมีได้หลายค่าสำหรับแต่ละ Instance (เช่น PhoneNumber ของพนักงานคนหนึ่ง) (ในการออกแบบจริงมักจะแยกเป็น Entity ใหม่)
      • Derived Attribute: ค่าของมันสามารถคำนวณหรือหาได้จาก Attribute อื่น (เช่น Age สามารถคำนวณได้จาก DateOfBirth)
    • สัญลักษณ์: โดยทั่วไปคือรูปวงรี (Oval) เชื่อมต่อกับ Entity หรือเขียนเป็นรายการภายใต้ชื่อ Entity ในสี่เหลี่ยม (นิยมกว่าในการวาด ERD ที่ซับซ้อน)
  • 2.3 คีย์ (Keys) ใน ERD:
    • ความสำคัญของ Keys: ใช้ในการระบุ Instance แต่ละตัวใน Entity ได้อย่างเฉพาะเจาะจง และใช้ในการสร้างความสัมพันธ์ระหว่าง Entities
    • Primary Key (PK – คีย์หลัก):
      • คือ Attribute (หรือกลุ่มของ Attributes) ที่มีคุณสมบัติ ไม่ซ้ำกัน (Unique) สำหรับทุก Instance ใน Entity นั้น และ ต้องมีค่าเสมอ (Not Null)
      • ใช้ในการ “ชี้ตัว” หรือ “อ้างอิง” ถึง Instance นั้นๆ ได้อย่างแม่นยำ
      • ตัวอย่าง: MachineID สำหรับ Entity MACHINE, SensorReadingID สำหรับ Entity SENSOR_READING
      • Candidate Key: Attribute หรือกลุ่มของ Attributes ที่มีคุณสมบัติเป็น Primary Key ได้ (อาจมีได้หลายตัวในหนึ่ง Entity) เราจะเลือกตัวใดตัวหนึ่งมาเป็น Primary Key
      • สัญลักษณ์: มักจะ ขีดเส้นใต้ ชื่อ Attribute ที่เป็น Primary Key
    • Foreign Key (FK – คีย์นอก):
      • คือ Attribute (หรือกลุ่มของ Attributes) ใน Entity หนึ่ง (เรียกว่า Child Entity หรือ Referencing Entity) ที่มีค่า ตรงกับค่าของ Primary Key ของอีก Entity หนึ่ง (เรียกว่า Parent Entity หรือ Referenced Entity)
      • ทำหน้าที่สร้าง “สะพาน” หรือ “ความเชื่อมโยง” ระหว่างสอง Entities
      • ตัวอย่าง: ถ้า SENSOR_READING ต้องการระบุว่าการอ่านค่านั้นมาจากเครื่องจักรใด จะมี Attribute MachineID_FK ใน SENSOR_READING ซึ่งค่าของมันจะต้องเป็นค่าใดค่าหนึ่งที่มีอยู่จริงใน MachineID (PK) ของ Entity MACHINE
      • สัญลักษณ์: บางครั้งอาจมีการกำกับว่า (FK) หรือวาดเส้นเชื่อมโยงพิเศษ แต่โดยทั่วไปจะแสดงผ่านความสัมพันธ์
  • 2.4 Relationship (ความสัมพันธ์):
    • ความหมาย: การเชื่อมโยงหรือความเกี่ยวข้องกันระหว่างสอง Entities (Binary Relationship) หรือมากกว่า (N-ary Relationship – พบไม่บ่อยในการออกแบบเบื้องต้น) หรือแม้กระทั่ง Entity เดียวกันมีความสัมพันธ์กับตัวเอง (Recursive/Unary Relationship)
    • การระบุ Relationship: มักจะเป็น “คำกริยา” ที่แสดงการกระทำหรือความเชื่อมโยงระหว่าง Entities
      • ตัวอย่าง: MACHINE is_assigned SENSOR (เครื่องจักร ถูกกำหนดให้มี เซ็นเซอร์), SENSOR generates SENSOR_READING (เซ็นเซอร์ สร้าง ข้อมูลการอ่านค่า), OPERATOR controls MACHINE (ผู้ควบคุมเครื่อง ควบคุม เครื่องจักร)
    • สัญลักษณ์: โดยทั่วไปคือรูปสี่เหลี่ยมขนมเปียกปูน (Diamond) ที่มีชื่อความสัมพันธ์ (คำกริยา) เขียนอยู่ภายใน และมีเส้นเชื่อมจาก Diamond ไปยัง Entities ที่เกี่ยวข้อง หรือใน Crow’s Foot Notation มักจะเป็นเพียงเส้นเชื่อมระหว่าง Entities และมีชื่อความสัมพันธ์กำกับอยู่บนเส้นนั้น
    • Degree of Relationship (ระดับขั้นของความสัมพันธ์):
      • Unary (Recursive): Entity หนึ่งมีความสัมพันธ์กับตัวเอง (เช่น EMPLOYEE supervises EMPLOYEE)
      • Binary: Entities สองตัวมีความสัมพันธ์กัน (พบบ่อยที่สุด)
      • Ternary: Entities สามตัวมีความสัมพันธ์กัน (ค่อนข้างซับซ้อน ควรพยายามแปลงเป็น Binary หลายๆ อันถ้าเป็นไปได้)
  • 2.5 Cardinality Ratio และ Modality (Optionality) ของความสัมพันธ์:
    • Cardinality Ratio (อัตราส่วนจำนวนสมาชิก): ระบุจำนวน สูงสุด ของ Instance ของ Entity หนึ่งที่สามารถมีความสัมพันธ์กับ Instance ของอีก Entity หนึ่งได้ (และในทางกลับกัน)
      • One-to-One (1:1): Instance หนึ่งของ A สัมพันธ์กับ Instance หนึ่งของ B เท่านั้น
        • ตัวอย่าง (สมมติ): MACHINE_CONTROLLER (MCU 1 ตัว) controls SPECIFIC_MACHINE_PART (ชิ้นส่วนเครื่องจักรเฉพาะ 1 ชิ้น) (ถ้า MCU 1 ตัวคุมแค่ส่วนเดียว และส่วนนั้นถูกคุมโดย MCU เดียว)
      • One-to-Many (1:N): Instance หนึ่งของ A สัมพันธ์กับ Instance หลายตัว ของ B ได้ แต่ Instance หนึ่งของ B สัมพันธ์กับ Instance หนึ่งของ A เท่านั้น
        • ตัวอย่าง (พบบ่อยมาก): MACHINE (1 เครื่อง) has SENSOR (หลายตัว) (แต่เซ็นเซอร์ 1 ตัว ติดตั้งอยู่บนเครื่องจักรเพียง 1 เครื่อง)
        • PRODUCTION_ORDER (1 คำสั่งผลิต) generates PRODUCT_ITEM (สินค้าหลายชิ้น)
      • Many-to-Many (M:N): Instance หนึ่งของ A สัมพันธ์กับ Instance หลายตัว ของ B ได้ และ Instance หนึ่งของ B ก็สัมพันธ์กับ Instance หลายตัว ของ A ได้เช่นกัน
        • ตัวอย่าง: OPERATOR (พนักงาน 1 คน) can_operate MACHINE (หลายเครื่อง) และ MACHINE (1 เครื่อง) can_be_operated_by OPERATOR (หลายคน – ในต่างกะ)
        • ข้อควรจำ: ในการออกแบบฐานข้อมูลเชิงสัมพันธ์จริง ความสัมพันธ์แบบ M:N จะไม่สามารถสร้างได้โดยตรง จะต้องถูก แปลง (Resolve) โดยการสร้าง Entity ใหม่ที่เรียกว่า Associative Entity (หรือ Intersection/Junction Table) ขึ้นมาคั่นกลาง โดย Entity ใหม่นี้จะมีความสัมพันธ์แบบ 1:N กับ Entity เดิมทั้งสอง
          • ตัวอย่าง: OPERATOR (1) — (0,N) OPERATION_ASSIGNMENT (0,N) — (1) MACHINE. โดย OPERATION_ASSIGNMENT จะมี PK ของตัวเอง และมี FK จาก OPERATOR และ MACHINE และอาจมี Attributes เพิ่มเติมเช่น AssignmentDate, Shift
    • Modality (หรือ Participation/Optionality – ความเป็นทางเลือกในการเข้าร่วมความสัมพันธ์): ระบุว่า Instance ของ Entity หนึ่ง จำเป็นต้อง (Mandatory) หรือ ไม่จำเป็นต้อง (Optional) เข้าร่วมในความสัมพันธ์นั้นหรือไม่
      • Mandatory Participation (บังคับเข้าร่วม): หมายความว่าทุก Instance ของ Entity นั้นจะต้องมีความสัมพันธ์กับอย่างน้อยหนึ่ง Instance ของอีก Entity หนึ่ง (แทนด้วยค่าต่ำสุดเป็น 1)
      • Optional Participation (เป็นทางเลือกในการเข้าร่วม): หมายความว่า Instance ของ Entity นั้นอาจจะไม่มีความสัมพันธ์กับ Instance ใดๆ ของอีก Entity หนึ่งเลยก็ได้ (แทนด้วยค่าต่ำสุดเป็น 0)
    • การแสดง Cardinality และ Modality ร่วมกัน (เช่น ใน Crow’s Foot Notation):
      • จะแสดงเป็นคู่ของ (Minimum, Maximum) สำหรับแต่ละด้านของความสัมพันธ์
      • (0,1) : Zero or One (Optional, Single)
      • (1,1) : One and Only One (Mandatory, Single)
      • (0,N) หรือ (0,*) : Zero or Many (Optional, Multiple) – ตัว N หรือ * หรือสัญลักษณ์ตีนกา <
      • (1,N) หรือ (1,*) : One or Many (Mandatory, Multiple) – ตัว N หรือ * หรือสัญลักษณ์ตีนกา <
      • ตัวอย่างการอ่าน Crow’s Foot: เส้นที่ออกจาก Entity MACHINE ไปยัง Relationship has_sensor มีสัญลักษณ์ |--O< หมายความว่า:
        • ด้าน MACHINE (|): เครื่องจักร 1 เครื่อง (One)
        • ด้าน SENSOR (O<): อาจจะไม่มีเซ็นเซอร์เลย (Zero) หรือมีเซ็นเซอร์หลายตัว (Many)
        • แปลว่า: เครื่องจักร 1 เครื่อง อาจจะไม่มีเซ็นเซอร์เลย หรือมีเซ็นเซอร์ได้หลายตัว

🛠️ ภาคปฏิบัติ

เป้าหมาย: ให้นักศึกษาฝึกฝนการนำความรู้เรื่ององค์ประกอบและสัญลักษณ์ของ ERD มาสร้างเป็นแผนภาพจริง โดยเริ่มจากการทำความเข้าใจสัญลักษณ์ การวาดตามตัวอย่าง และประยุกต์ใช้กับ Case Study ที่ทำต่อเนื่องมาจากสัปดาห์ที่ 2 เพื่อจำลองข้อมูลในโรงงานอัจฉริยะ

ส่วนที่ 1: ทบทวนความรู้จากทฤษฎี, ทำความคุ้นเคยกับสัญลักษณ์ ERD (Crow’s Foot) และเครื่องมือ

  • ทบทวนจากภาคทฤษฎี: ผู้สอนทบทวนองค์ประกอบหลักของ ERD (Entity, Attribute, PK, FK, Relationship, Cardinality, Modality) อย่างรวดเร็ว
  • เน้นสัญลักษณ์ Crow’s Foot Notation:
    • Entity: รูปสี่เหลี่ยมผืนผ้า
    • Attribute: เขียนเป็นรายการภายใน Entity (Primary Key ขีดเส้นใต้)
    • Relationship: เส้นตรงเชื่อมระหว่าง Entities, มีชื่อความสัมพันธ์กำกับบนเส้น (มักเป็นคำกริยา)
    • Cardinality & Modality Symbols (ที่ปลายเส้นแต่ละด้าน):
      • | (ขีดเดียวแนวตั้ง): หมายถึง “One”
      • O (วงกลม): หมายถึง “Zero”
      • < (สัญลักษณ์คล้ายตีนกา): หมายถึง “Many”
    • การอ่านสัญลักษณ์คู่:
      • O| : Zero or One (Optional Single)
      • || : One and Only One (Mandatory Single)
      • O< : Zero or Many (Optional Multiple)
      • |< : One or Many (Mandatory Multiple)
  • แนะนำเครื่องมือ (ถ้ามี):
    • ผู้สอนสาธิตการใช้งานโปรแกรมวาด ERD เบื้องต้น (เช่น draw.io หรือ app.diagrams.net ซึ่งเป็นตัวเดียวกันและฟรี) แสดงวิธีการสร้าง Entity, เพิ่ม Attribute, วาดเส้น Relationship, และใส่สัญลักษณ์ Cardinality
    • หากไม่มีโปรแกรม ให้เน้นการใช้กระดาษ ปากกา และไม้บรรทัด โดยให้วาดสัญลักษณ์ให้ชัดเจน

ส่วนที่ 2: กิจกรรมสาธิตและฝึกวาด ERD อย่างง่าย (Guided Practice)

  • ผู้สอนสาธิตการวาด ERD สำหรับสถานการณ์ตัวอย่างทีละขั้นตอน (ใช้ Crow’s Foot):
    1. สถานการณ์: “แผนก (DEPARTMENT)” และ “พนักงาน (EMPLOYEE)”
      • วิเคราะห์:
        • แผนก 1 แผนก มีพนักงานได้หลายคน (One-to-Many)
        • พนักงาน 1 คน สังกัดอยู่เพียง 1 แผนก (สมมติฐาน)
        • สมมติว่าแผนกต้องมีพนักงานอย่างน้อย 1 คน (Mandatory participation for Employee side of Department)
        • สมมติว่าพนักงานทุกคนต้องสังกัดแผนก (Mandatory participation for Department side of Employee)
      • Entities & Attributes:
        • DEPARTMENT: DeptID (PK), DeptName
        • EMPLOYEE: EmpID (PK), EmpName, Position, DeptID_FK (FK to DEPARTMENT)
      • การวาด:
        • วาด Entity DEPARTMENT และ EMPLOYEE
        • กำหนด Primary Keys (DeptID, EmpID)
        • วาดเส้น Relationship “employs” หรือ “belongs_to”
        • ใส่ Cardinality: DEPARTMENT (||) — employs — (|<) EMPLOYEE
          • อ่านจาก Department ไป Employee: แผนก 1 แผนก (Mandatory) จ้างพนักงาน 1 คนหรือมากกว่า (Mandatory Multiple)
          • อ่านจาก Employee ไป Department: พนักงาน 1 คน (Mandatory) สังกัดอยู่กับแผนก 1 แผนกเท่านั้น (Mandatory Single)
          • (Foreign Key DeptID_FK ใน EMPLOYEE จะเกิดขึ้นเมื่อแปลง ERD เป็นตาราง)
    2. สถานการณ์: “นักศึกษา (STUDENT)” และ “รายวิชา (COURSE)” (Many-to-Many)
      • วิเคราะห์:
        • นักศึกษา 1 คน สามารถลงทะเบียนได้หลายรายวิชา
        • รายวิชา 1 วิชา สามารถมีนักศึกษาลงทะเบียนได้หลายคน
      • Entities & Attributes (เบื้องต้น):
        • STUDENT: StudentID (PK), StudentName
        • COURSE: CourseID (PK), CourseName
      • การจัดการ Many-to-Many:
        • อธิบายว่าต้องสร้าง Associative Entity ขึ้นมา เช่น ENROLLMENT
        • ENROLLMENT: EnrollmentID (PK), StudentID_FK, CourseID_FK, EnrollDate, Grade
      • การวาด (หลัง Resolve M:N):
        • STUDENT (|<) — (0,N) ENROLLMENT (0,N) — (|<) COURSE
          • (Student 1 คน อาจจะยังไม่ลงทะเบียน หรือลงทะเบียนหลาย Enrollment record; Course 1 วิชา อาจจะยังไม่มีใครลง หรือมีคนลงหลาย Enrollment record)
          • (Enrollment record 1 รายการ ต้องมาจาก Student 1 คน และเป็นของ Course 1 วิชา)
  • ให้นักศึกษาฝึกวาดตามตัวอย่าง หรือโจทย์ง่ายๆ เพิ่มเติม:
    • “ผู้แต่ง (AUTHOR)” และ “หนังสือ (BOOK)” (ผู้แต่ง 1 คน เขียนหนังสือได้หลายเล่ม)
    • “สินค้า (PRODUCT)” และ “ผู้จัดจำหน่าย (SUPPLIER)” (สินค้า 1 ชนิด อาจมาจากผู้จัดจำหน่ายหลายราย และผู้จัดจำหน่าย 1 ราย อาจจัดจำหน่ายสินค้าหลายชนิด – M:N)
    • ผู้สอนเดินให้คำแนะนำในการเลือกใช้สัญลักษณ์ Cardinality และการ Resolve M:N

ส่วนที่ 3: กิจกรรมกลุ่ม: ออกแบบ ERD สำหรับ Case Study จากหน่วยที่ 2 🏭✍️

  • การดำเนินกิจกรรม:
    1. ให้นักศึกษาแต่ละกลุ่ม ทบทวน Entities และ Attributes ที่ได้ระบุไว้สำหรับ Case Study ที่กลุ่มตนเองวิเคราะห์ในหน่วยที่ 2 (เช่น ระบบติดตามพลังงานเครื่องจักร, ระบบตรวจสอบคุณภาพสินค้า)
    2. เป้าหมายของกลุ่ม:
      • ยืนยัน/ปรับปรุง Entities และ Attributes ให้สมบูรณ์ที่สุดเท่าที่จะทำได้ในขั้นนี้
      • กำหนด Primary Key ให้กับทุก Entity อย่างชัดเจน
      • ระบุความสัมพันธ์ (Relationships) ทั้งหมดที่จำเป็นระหว่าง Entities ที่มี พร้อมตั้งชื่อความสัมพันธ์ที่สื่อความหมาย (เช่น MACHINE is_monitored_by SENSOR; SENSOR_READING is_generated_by SENSOR)
      • กำหนด Cardinality และ Modality (ใช้ Crow’s Foot) สำหรับ “ปลาย” ทั้งสองด้านของแต่ละความสัมพันธ์อย่างละเอียด โดยพิจารณาจากตรรกะของ Case Study
        • ตัวอย่างคำถามที่ต้องตอบเพื่อกำหนด Cardinality:
          • เครื่องจักร 1 เครื่อง จำเป็นต้องมีเซ็นเซอร์หรือไม่? (Optional/Mandatory for Sensor side)
          • เครื่องจักร 1 เครื่อง สามารถมีเซ็นเซอร์ได้กี่ตัว? (One/Many for Sensor side)
          • เซ็นเซอร์ 1 ตัว จำเป็นต้องติดตั้งอยู่บนเครื่องจักรหรือไม่? (Optional/Mandatory for Machine side)
          • เซ็นเซอร์ 1 ตัว สามารถติดตั้งอยู่บนเครื่องจักรกี่เครื่อง? (One/Many for Machine side)
        • หากพบความสัมพันธ์แบบ Many-to-Many ให้ พยายาม Resolve โดยการสร้าง Associative Entity พร้อมกำหนด PK และ FK ที่เหมาะสม
      • วาด ERD ฉบับสมบูรณ์ สำหรับ Case Study ของกลุ่ม โดยใช้สัญลักษณ์ Crow’s Foot Notation อย่างถูกต้อง (ผ่านโปรแกรม หรือวาดด้วยมือให้ชัดเจน)
        • ควรมีการระบุชื่อ Entity, Attributes (พร้อม PK) และเส้น Relationship ที่มีชื่อและสัญลักษณ์ Cardinality ครบถ้วน

Related Posts