Basic Database System Part 6 - ออกแบบ Database ด้วย ER Model ตอนที่ 1

สำหรับ 2 ตอนที่แล้วเราได้เรียนรู้การทำ Normalization ให้ถึงระดับ 5NF ไปแล้ว แต่ผมเชื่อว่าคงมีหลายคนสงสัยว่า เราจะได้ตารางเริ่มต้นแล้วเอามาทำ Normalization ยังไง อยู่ดีๆมันขึ้นมาเองเลยเหรอ จริงๆมันมีวิธีให้ได้มาซึ่งตารางนั้น

1. เอามาจาก Report ใช่ครับ คุณฟังไม่ผิดครับ ปกติงานส่วนใหญ่จะรู้ว่าต้องเก็บข้อมูลอะไรส่วนหนึ่งจะรู้จาก Report ครับ เพราะสุดท้ายแล้วเราจะเอา Report ออกมาดูว่ามีอะไรในระบบ มีอะไรทำสำเร็จเท่าไหร่ ไม่สำเร็จเท่าไหร่ ซึ่ง Report ส่วนใหญ่เป็นตาราง

2. ใช้วิธีการออกแบบที่มีคนคิดขึ้นมาแล้ว โดยแต่ละวิธีเมื่อออกแบบเสร็จเราจะได้เป็น Conceptual model ตามแต่ละวิธี โดย Conceptual model คือ model ที่ทำให้เราเข้าใจว่าสิ่งที่เราสนใจนั้นเกี่ยวข้องกันอย่างไร มีโครงสร้างอย่างไร ซึ่งตัว Conceptual model นี้ไม่ขึ้นตรงกับ DBMS เจ้าไหน และ Database model อะไร เมื่อคุณได้ตัว Conceptual model ออกมาคุณสามารถแปลงมันไปเป็น Database model ใดก็ได้ โดย Conceptual model ที่เป็นที่นิยมมากๆมี 2 ชนิดคือ ER Model กับ ORM โดยที่ผมจะเขียนนั้นคือ ER Model เพราะคนส่วนใหญ่ใช้ (คนส่วนใหญ่ใช้ไม่จำเป็นต้องดีที่สุดนะครับ ลองไปดูการออกแบบด้วย ORM ดูเพิ่มเติมครับ บางทีอาจจะสนุกกว่าการใช้ ER )

Entity Relationship Model ( ER Model )

Entity Relationship Model คือ Model ที่พูดถึง Entity ซึ่งหมายถึงสิ่งที่เราสนใจในระบบ อาจจะหมายถึงหนังสือ คน การโอน การยืม ตามแต่สิ่งที่ระบบนั้นสนใจ กับ Relationship ซึ่งหมายถึงความสัมพันธ์ ( เตือนไว้ตรงนี้เลยว่าไม่เกี่ยวกับ Relation ในเนื้อหา Relational database ) รวมแล้ว Entity Relationship model คือ Model ที่แสดงความสัมพันธ์ระหว่าง Entity ในระบบ

สัญลักษณ์ของ Entity Relationship Model

ถ้าสมมุติเราทำระบบเก็บข้อมูลพนักงานในบริษัท Entity ที่เราน่าจะต้องสนใจคือ “พนักงาน” ซึ่งพนักงานก็น่าจะมีข้อมูลเกี่ยวกับ รหัสพนักงาน , ชื่อ-นามสกุล , วันที่เริ่มทำงาน , เพศ ซึ่งด้วยข้อมูลทั้งหมดนี้เราสามารถเขียนมันให้อยู่ในสัญลักษณ์ดังภาพด้านล่าง

โดยเราจะไล่ทีละสัญลักษณ์

Entity

นี่คือสัญลักษณ์แทน Entity โดย Entity เราจะตั้งชื่อว่าอะไรก็ใส่เข้าไป โดยในตัวอย่างแรก Entity พนักงาน เราก็ใส่พนักงานเข้าไปแทน Entity

Key attribute

นี่คือสัญลักษณ์แทน Key attribute โดย Key attribute คือค่าที่ใช้อ้างอิงถึง Entity ได้เพียง Entity เดียว (มองง่ายๆว่าคือ Primary) ในตัวอย่างแรกของเราคือรหัสพนักงาน ซึ่งรหัสพนักงานสามารถใช้เป็นตัวอ้างอิงถึง Entity ได้เพียง Entity เดียว โดย Key attribute อาจมีหลายตัวได้

Attribute

นี่คือสัญลักษณ์แทน Attribute ซึ่งคือค่าต่างๆที่ Entity นั้นจากตัวอย่างของเราคือ ชื่อ-นามสกุล (ไม่เป็น Key attirbute เพราะอาจจะมีคนชื่อนามสกุลซ้ำกันก็ได้ เช่น บุญชู บ้านโข้ง อาจจะมีหลายคน) เพศ วันที่เริ่มทำงาน

ความสัมพันธ์ระหว่าง Entity

ระบบที่เรากำลังออกแบบคือระบบเก็บข้อมูลพนักงานในบริษัท Entity ของเราไม่ได้มีเพียงแค่ Entity พนักงานอย่างเดียว มันน่าจะมี Entity อื่นด้วย ตัวอย่างเช่น Entity แผนกดังภาพ

แล้วความสัมพันธ์ระหว่าง Entity พนักงานกับ Entity แผนกเกี่ยวข้องกันยังไง อันนี้แล้วแต่ระบบที่คุณสนใจว่ามันเกี่ยวข้องกันยังไงตาม อย่างระบบของผมที่สมมติขึ้น Entity พนักงานกับ Entity แผนก เกี่ยวข้องกันคือ พนักงานอยู่ภายใต้แผนก ซึ่งจากความสัมพันธ์นี้จะเขียน Model ได้ดังภาพ

โดยเราสามารถอ่านความสัมพันธ์ระหว่าง Entity พนักงาน กับ Entity แผนกได้แบบนี้

• 1 Entity พนักงาน อยู่ภายใต้ Entity แผนก ได้เพียง 1 Entity แผนก (ภาษามนุษย์คือ พนักงาน 1 คน อยู่ภายใต้ แผนก ได้แผนกเดียว)

• 1 Enttiy แผนก มี Entity พนักงาน อยู่ภายใต้ได้ “หลาย” Entity พนักงาน ( ภาษามนุษย์คือ แผนก 1 แผนก มีพนักงาน อยู่ภายใต้ ได้หลายคน)

Relationship

Relationship ใช้สัญลักษณ์ สี่เหลี่ยมขนมเปียกปูนในการบอกความสัมพันธ์ว่าคือความสัมพันธ์มีตัวอักษร 1 , M , N เป็นจำนวนความสัมพันธ์

คราวนี้คุณอาจจะสงสัยว่าตัวอักษร 1 , M อะไรพวกนี้มันเขียนยังไง จะรู้ได้ไงว่ามันเป็น 1 หรือ M เอาอะไรตัดสินใจ เดี๋ยวเราค่อยๆมาทำความเข้าใจกันครับ

ลากเส้นความสัมพันธ์

ถ้าเราอยากรู้ว่า Entity มีความเกี่ยวข้องกันยังไงให้ลองยกตัวอย่างขึ้นมา เช่น พนักงาน E001 , E002 , E003 , E004 เนี่ยมันอยู่ภายใต้ แผนก DEV , QA ยังไง ถ้าคิดไม่ออกลองดูภาพด้านล่างครับ

จากภาพคุณจะเห็นว่าความสัมพันธ์ว่าพนักงานแต่ละคนอยู่ภายใต้แผนกอะไร หากคุณสังเกตดีๆ คุณจะเห็นว่า 1 พนักงานนั้นอยู่ได้ 1 แผนก ส่วนถ้ามองฝั่งแผนกจะเห็นว่า 1 แผนกนั้นมีพนักงานอยู่ได้หลายคน ( M ) ดังนั้นเวลาไปเขียนสัญลักษณ์ตัวเลขจะเป็นฝั่ง Entity พนักงานจะเป็นตัว M เพื่อบอกว่า 1 Entity แผนกมีหลาย Entity พนักงาน ส่วนฝั่งแผนกจะใส่เลข 1 เพื่อบอกว่า 1 Entity พนักงานอยู่ได้ 1 Entity แผนก

แล้วมีความสัมพันธ์แบบอะไรบ้าง

ตัวอย่างความสัมพันธ์อยู่ภายใต้เป็นความสัมพันธ์แบบ 1 to M แต่คุณก็น่าจะเกิดคำถามว่ามันมีความสัมพันธ์แบบอื่นไหม เช่น แบบ 1 to 1 หรือ M to M อะไรแบบนี้ ซึ่งผมก็ขอบอกเลยครับว่ามีครับ เรามาลองดูตัวอย่างกัน

1 to 1

จริงๆความสัมพันธ์ระหว่าง พนักงาน กับ แผนก ไม่ได้มีความสัมพันธ์แค่ “อยู่ภายใต้” จริงๆยังมีความสัมพันธ์อื่นอีก เช่น ความสัมพันธ์ เป็นหัวหน้าแผนก ซึ่งความสัมพันธ์แบบเป็นหัวหน้าแผนกนี้เป็นความสัมพันธ์แบบ 1 to 1 คือ พนักงาน 1 คนเป็นหัวหน้าแผนกได้เพียง 1 แผนก ส่วน แผนก 1 แผนก เป็นมีหัวหน้าได้ 1 คน โดยเราสามารถทดสอบด้วยการลากเส้นความสัมพันธ์ดังรูปด้านล่าง (ขอละการเขียน Attriubte นะครับ)

M to M

คราวนี้มาลองคิดดูว่าบริษัทเนี่ยน่าจะมีโปรเจคที่บริษัทรับมาทำซึ่งแน่นอนว่าพนักงานน่าจะต้องถูกจัดให้ทำโปรเจคนั้น โดยพนักงานหนึ่งคนอาจจะถูกให้ทำหลายโปรเจค ดังนั้นความสัมพันธ์มันน่าจะเป็นแบบ M to M ซึ่งเราสามารถทดสอบเขียนความสัมพันธ์ดังรูปด้านล่าง (ขอละการเขียน Attriubte นะครับ)

Relationship มี Attribute ได้ไหม

คุณอาจจะมีคำถามว่า Relationship มันมี Attribute ได้ไหม คำตอบคือมันมีได้ครับ ยกตัวอย่างเช่นความสัมพันธ์ ที่ พนักงานต้องรับผิดชอบโปรเจคนั้นอาจมีค่าที่เกี่ยวข้องกับความสัมพันธ์นั้น เช่น จำนวนชั่วโมงที่ต้องรับผิดชอบต่อสัปดาห์ ซึ่งเป็นเรื่องที่เกิดขึ้นได้กับทุกความสัมพันธ์ ดังนั้นเราสามารถเขียน Attribute ของความสัมพันธ์ได้ดังภาพ

ความสัมพันธ์เกิดจาก Entity มากกว่า 2 Entity ได้หรือไม่

ตัวอย่างมาทั้งหมดนั้นเป็นความสัมพันธ์ที่เกิดจาก Entity 2 ตัวมีความสัมพันธ์กัน แล้วถ้า Entity มากกว่า 2 ตัวสามารถมีความสัมพันธ์กันได้ไหม คำตอบคือได้ครับ ตัวอย่างความสัมพันธ์ การขายของ โดยมี Entity ที่เกี่ยวข้องคือ บริษัทที่ขาย ของที่ขาย โปรเจค โดยเขียนความสัมพันธ์ดังภาพ (ขอละการเขียน Attribute ของ Entity ครับ)

Entity สามารถมีความสัมพันธ์กับตัวเองได้หรือไม่

คำตอบคือได้ครับ ยกตัวอย่าง พนักงานสามารถถูกกำหนดหน้าที่ให้ดูแลพนักงานคนอื่น เหมือนเป็นพี่เลี้ยง ซึ่งพนักงานหนึ่งคนสามารถดูแลพนักงานได้หลายคนและพนักงานสามารถถูกดูแลจากพนักงานหลายคนได้ ซึ่งเราสามารถเขียนความสัมพันธ์ได้ดังภาพ (ขอละการเขียน Attribute ของ Entity ครับ)

มาลองเขียน ER Model จากโจทย์กัน

มีการจัดประชุมวิชาการทางศาสนาขึ้นโดยในงานจะมีผู้ขึ้นมาพูดเกี่ยวกับศาสนาต่างๆ โดยการประชุมจะพูดเกี่ยวกับศาสนานั้นว่าศาสนานั้นชื่อศาสนาอะไร มีศาสดาเป็นใคร พระคัมภีร์หรือหนังสือเกี่ยวกับศาสนาคืออะไร โดยในงานประชุมวิชาการนี้จะมี Speaker มาพูดเกี่ยวกับศาสนาต่างๆ ซึ่ง Speaker แต่ล่ะท่านนั้นเป็นผู้เชี่ยวชาญเคยอ่านหนังสือของศาสนาต่างๆมาแล้ว โดยทางงานวิชาการได้ให้ข้อมูลเกี่ยวกับศาสนาและ Speaker ที่จะมาพูดมาดังภาพ

หน้าที่ของเราคือทำ ER Model จากข้อมูลทั้งหมดที่มี

วิเคราะห์โจทย์

จากข้อมูลที่ได้เราพอเห็นคร่าวๆว่าน่าจะมี 2 Entity แน่นอนคือ RELIGION กับ SPEAKER แน่นอน และทั้งสองน่าจะมีความสัมพันธ์ด้วยความสัมพันธ์ SPEAK คือ SPEAKER SPEAK RELIGION ซึ่งจะได้ ER Model เบื้องต้นออกมาดังภาพ

ซึ่งข้อมูลที่เหลือที่ยังไม่อยู่ใน ER Model คือข้อมูลเกี่ยวกับ Text ซึ่งถ้าเราสังเกตดีๆจะเห็นว่า TEXT น้ันมีความสัมพันธ์กับ RELIGION และ SPEAKER ดังนั้นเราน่าจะให้ตัว TEXT เป็น Entity ด้วย ซึ่งจะได้ ER Model ออกมาดังภาพ

สรุป

สำหรับตอนนี้เราได้เรียนรู้เกี่ยวกับการเขียน Entity Relationship Model ว่ามีเขียนยังไง มีสัญลักษณ์อะไรบ้าง ไปจนถึงทดลองเขียน Entity Relationship Model จากโจทย์งานประชุมวิชาการศาสนา ซึ่งทั้งหมดที่เราเรียนรู้ไปเป็นเพียงบางส่วนของ Entity Relationship Model ซึ่งผมคิดว่าใช้บ่อยในการทำงาน จริงๆยังมีอีกหลายสัญลักษณ์ที่ผมไม่ได้พูดถึงตัวอย่างเช่น Weak Entity เป็นต้น ซึ่งถ้าใครสนใจสามารถไปหาอ่านเพิ่มได้ สำหรับตอนหน้าเราจะมาเปลี่ยน Entity Relationship Model นี้ให้กลายเป็น Relational Database Model เพื่อเอาไปใช้งานกัน

Ref

ตัวอย่างโจทย์เอามาจากหนังสือ Relational database systems : language, conceptual modeling and design for engineers