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 ครบถ้วน