และแล้วก็ก็มาถึงเรื่องชวนปวดหัวของใครหลายคน นั้นก็คือ 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 ครับผม
