และแล้วก็ก็มาถึงเรื่องชวนปวดหัวของใครหลายคน นั้นก็คือ
E-R Model (Entity Relationship Model) แต่จะไม่พูดถึงก็ไม่ได้ เพราะมันคือเครื่องมือที่ช่วยให้จินตนาการ หรือ ออกแบบระบบฐานข้อมูลได้ง่ายที่สุดแล้วล่ะครับ
อย่างที่พูดผมไปตั้งแต่ตอนที่ 1 ถ้าหากลากยาวอธิบายจนครบถ้วน
ท่านคงหลับคาคอมพิวเตอร์แน่ ๆ ผมจะสรุปแต่ที่ท่านควรรู้
เป็นตัวอย่างให้ดูก็แล้วกันนะครับ
เมื่อกล่าวถึง Entity Relationship Model แปลตรงตัวก็คือ
โมเดลความสัมพันธ์ระหว่าง Entity แล้วเจ้า Entity คืออะไร บางคนบอกชื่อแปลก ๆ ไม่เคยได้ยิน เอางี้ครับ จำง่าย ๆ ตามผม
Entity ก็คือตารางหรือก็คือฐานข้อมูล ที่พูดถึงไปในตอนที่แล้ว ขอยกตัวอย่างจากรูปของตอนที่แล้วมา ให้ดูนะครับ
จากรูป ที่เป็นสีเขียวทั้งหมดของตารางนั่นแหละครับคือ
Entity ซึ่ง Entity ประกอบสองส่วนคือด้วย
Attribute(จำง่าย ๆ คือคอลัมน์ของตาราง) และ
ข้อมูล (ข้อมูล 1 แถวก็คือ 1 record)
สรุปง่าย ๆ แค่นี้ก่อน เจาะลึกเดี๋ยวจะงง ต่อไปถ้าผมพูดถึง Entity
ให้ท่านนึกถึงภาพตารางด้านบนนี้ไว้นะครับ ที่กล่าวมาทั้งหมดนั่นคือ 1
Entity
ต่อไป ความสัมพันธ์ระหว่าง Entity หมายถึง Entity 2 Entity ขั้นไปที่มีความสัมพันธ์กัน แบ่งชนิดความสัมพันธ์ออกเป็น 3 ชนิด คือ
1. One-to-Many
เป็นความสัมพันธ์ปรกติของระบบฐานข้อมูลครับครับ กล่าวคือ 1 record ของ
Entity(ตาราง)หนึ่ง จะสัมพันธ์ กับ หลาย record ของอีก Entity(ตาราง)หนึ่ง
เช่น
Entityพนักงาน กับ
Entityแผนก นึกภาพตามง่าย ๆ ครับ 1 แผนก สามารถมีพนักงานสังกัดได้หลายคน พนักงาน 1 คนสามารถสังกัดแผนกได้ 1 แผนก ดังตัวอย่างด้านล่าง
2. One-to-One คือ Entity หนึ่งจะมีความสัมพันธ์
กับอีก Entity หนึ่ง แบบ record ต่อ record(Entity ฃหลัก 1 record
สามารถสัมพันธ์กับ Entityย่อย เพียง 1 record เท่านั้น)
ลองนึกภาพตามผมนะครับ เรามีระบบอยู่ 2 ระบบในบริษัท ซึ่งสร้างฟอร์ม log-in
ขึ้นมา 2 หน้า แต่ใช้ฐานข้อมูลพนักงานร่วมกัน เช่น
ระบบจัดซื้อ(ของแผนกจัดซื้อ) และ ระบบซ่อมจักร(แผนกช่างจักร)
วิธีที่ง่ายที่สุด คือเราสร้าง Entity สำหรับ log-in ขึ้นมา 2 ตาราง
สำหรับ 2 ระบบ ซึ่ง พนักงาน 1 คน จะสามารถ มีได้ 1 account ต่อ 1
ระบบดังรูปตัวอย่าง (ตอนนี้รู้แค่ว่า Access สามารถสร้างฟอร์มให้ Login
เข้าระบบได้ แค่นั้นก่อนนะครับ ส่วนวิธีการผมจะทำเป็น workshop
ให้ดูในภายหลังคร้ับ)
ถึงแม้จะเป็นวิธีการที่ง่าย แต่ไม่นิยมเท่าใหร่ ส่วนใหญ่หากมี 2 Entity ที่มีความสัมพันธ์เป็นแบบ one-to-one เราจะนิยมรวมทั้ง 2 Entity เป็น 1 Entity แบบนี้
จากรูปด้านบน หมายถึงเราตัองแน่ใจว่า 1
คนสามารถเข้าระบบได้เพียงระบบเดียวเท่านั้น เช่น นาย 111
เข้าได้แต่ระบบจัดซื้อ หรือ นาย 444 เข้าได้แต่ระบบซ่อมจักร
แต่ในกรณีพิเศษที่เราไม่มั่นใจว่าพนักงาน 1 คนจะสามารถเข้าได้หลายระบบหรือเปล่า เราสามารถออกแบบความสัมพันธ์ ของ Entity เป็น one-to-many ได้ดังรูป (ใช้ฟิลด์ ระบบ เป็นตัวระบุว่าเป็น account ของระบบไหน)
ซึ่งเราจะออกแบบระบบให้เป็นแบบไหนก็ได้ครับ ไม่ผิดทั้ง 3 แบบ ใช้งานได้เหมือนกัน แต่เราต้องดูความเหมาะสมเอาครับ
3. Many-to-Many หมายถึง Entityที่หนึ่ง
มีความสัมพันธ์กับ Entityที่สอง หลาย record ในขณะที่
Entityที่สองก็มีความสัมพันธ์กับ Entityที่หนึ่ง แบบหลาย record
เช่นกัน โดยส่วนตัวแล้วเจอบ่อย ๆ ครับความพันธ์แบบนี้ เช่น
- Entityสินค้า กับ Entityใบสั่งซื้อ
(สินค้าชนิดหนึ่งสามารถถูกซื้อด้วยใบสั่งซื้อหลายใบ
และใบสั่งซื้อใบหนึ่งสามารถสั่งซื้อสินค้าได้หลายชนิด)
- Entityยา กับ Entityใบเบิกยา (ยาชนิดหนึ่งเบิกด้วยใบได้หลายใบ และใบเบิกยาใบหนึ่งสามารถเบิกยาได้หลายชนิด)
- Entityหนังสือ กับ
Entityสมาชิก(หนังสือหนึ่งเล่มสามารถมีสมาชิกยืมได้หลายคน(ยืมแล้วคืน)
และสมาชิกหนึ่งคนสามารถยืมหนังสือได้หลายเล่ม)
ซึ่งความสัมพันธ์ระหว่างแบบ
Many-to-Many เรานึกภาพได้เขียนได้
แต่เอาไปสร้างฐานข้อมูลไม่ได้ครับ จำเป็นต้องแปลงให้เป็นให้อยู่ในรูป One-to-Many ก่อน ถึงตรงนี้หลายคนอาจจะงงว่าจะแปลงได้อย่างไร ขอให้ศึกษาภาพตัวอย่างด้านล่างนี้นะครับ
จากรูปตัวอย่างด้านบน Entityสินค้ัา มีความสัมพันธ์กับ Entityใบสั่งซื้อ แบบ
Many-to-Many แต่เราสามารถแปลง ความสำพันธ์แบบ
One-to-Many ได้โดยสร้างตาราง รายละเอียดใบสั่งซื้อ เพื่อเชื่อมทั้ง 2 ตาราง ดัีงรูป
ซึ่งความสัมพันธ์ของ Entity แบบ
Many-to-Many นั้น มักจบด้วยการ
สร้าง Entity มาคั่นเพื่อแปลงความสัมพันธ์ ให้กลายเป็นแบบ One-to-Many เสมอ
จบแล้วครับสำหรับตอนที่ 3 ทำรูปกันซะเหนื่อยทีเดียว โปรดติดตามตอนต่อไป ตอนที่ 4 ในชื่อตอนว่า E-R Diagram ครับผม