กรุณา อ่านบทความนี้ ประกอบครับ
สมมติว่าเรามีโอกาสได้ไปเยือนสถานที่ธรรมชาติแห่งหนึ่งซึ่งยิ่งใหญ่สวยงามมาก ๆ แล้วบังเอิญลืมเอากล้องถ่ายรูปติดไปด้วย พอเรากลับมาเราก็อยากจะแบ่งปันความประทับใจกับเพื่อนของเราด้วยการเล่าให้เพื่อนฟังโดยบรรยายไปต่าง ๆ นา ๆ แต่พูดเท่าไหร่เพื่อนก็ไม่รู้สึกซาบซึ้งอะไรกับเราด้วยสักที เพราะไม่ว่าจะอธิบายด้วยคำพูดยืดยาวขนาดไหนเพื่อนเราก็ไม่สามารถมองเห็นภาพความสวยงามตรงกับภาพที่เราเห็นมาด้วยตาตนเองได้ เพราะว่าภาพที่เราเห็นนั้นมันประกอบขึ้นด้วยรายละเอียดปลีกย่อยมากมายเกินกว่าที่คำพูดจะอธิบายได้
ปัญหาดังกล่าวสามารถเกิดขึ้นในการออกแบบระบบสารสนเทศเช่นกัน ถ้านักพัฒนาระบบต้องการจะถ่ายทอดภาพของระบบสารสนเทศที่กำลังจะพัฒนาว่าประกอบด้วยข้อมูลอะไรบ้างซึ่งตรงกับความต้องการที่ยูสเซอร์ที่ได้แจ้งไว้กับนักพัฒนาระบบหรือไม่ การอธิบายด้วยคำพูดของนักพัฒนาระบบไม่สามารถทำให้ยูสเซอร์เข้าใจตรงกับสิ่งที่นักพัฒนาระบบต้องการถ่ายทอดได้ นั่นจึงเป็นที่มาของ E-R Diagrams ซึ่งใช้แสดงข้อมูลในระบบสารสนเทศในรูปของรูปภาพ ซึ่งทำให้ยูสเซอร์และนักพัฒนาระบบมีความเข้าใจตรงกันในข้อมูลที่จะประกอบขึ้นเป็นระบบที่กำลังพัฒนา
ในการเขียน E-R Diagram จะต้องทำความเข้าใจเกี่ยวกับส่วนประกอบต่าง ๆ ของ E-R ดังต่อไปนี้
– Entity
entity แทนที่ สิ่ง ซึ่งอาจจะเป็นทั้งคน วัตถุ สิ่งของ หรือสิ่งซึ่งเป็นนามธรรมจับต้องไม่ได้ ใช้แทนที่สิ่งในโลกความเป็นจริงแต่ละ entity แทนที่ด้วยชื่อของ entity ในรูปสี่เหลี่ยมผืนผ้า
– Attribute
attributes ใช้แสดงถึงคุณสมบัติของ entity เช่น ชื่อ นามสกุล เลขประจำตัว ที่อยู่ ฯลฯ แทนที่ด้วยชื่อของ attribute ในรูปวงรี
จากภาพข้างบนแสดงถึง entity ที่ชื่อ Customer ซึ่งจะแสดงชื่อ entity อยู่ในรูปสี่เหลี่ยมผืนผ้า
ส่วน attribute จะแสดงชื่อ attribute อยู่ในรูปวงรี ซึ่งเชื่อมโยงกับ entity ด้วยเส้นตรงที่ลากเชื่อมระหว่าง entity และ attribute
Key attribute
คือ attribute ที่ถูกกำหนดให้เป็น key ของ entity โดยแทนที่ด้วย attribute ที่ถูกขีดเส้นใต้ จากในภาพ account Id ถูกขีดเส้นใต้เพื่อแสดงว่า attribute นี้ถูกใช้เป็น key ของ entity Customer
Multi-valued attribute
คือ attribute ที่มีค่าบรรจุอยู่มากกว่าหนึ่งค่า โดยแทนที่ด้วยวงกลมรูปไข่ซ้อนกันสองวง จากในภาพ attribute ที่ชื่อ otherUsers เป็น multi-valued attribute หมายถึง Customer สามารถมีผู้ใช้คนอื่น ๆ ที่ใช้บัญชีของ Customer ได้ (ผู้ใช้คนอื่นอาจจะเป็นญาติกับ Customer เช่น ลูก, ภรรยา, น้อง)
Derived attribute
คือ attribute ที่ค่าของมันได้มาจากการคำนวณของ attribute อื่น โดยแทนที่ด้วยวงกลมรูปไข่ที่เป็นเส้นประ จากในภาพ attribute ที่ชื่อ numberRentals หรือจำนวนที่เช่าซึ่งได้มาจากการรวมจำนวนสินค้าที่เช่าทั้งหมดเข้าด้วยกัน
Composite attribute
คือ attribute ที่สามารถแยกออกเป็น attribute ย่อย ๆ ได้หลาย attribute แทนที่โดยชื่อ attribute ใน วงกลมรูปไข่ที่มีเส้นตรงลากไปเชื่อมโยงกับ attribute หลัก จากในภาพ attribute ที่ชื่อ address สามารถแยกออกเป็น attribute ย่อยที่ชื่อ street, city, state, zipcode ได้อีก
Relationship Types
ใช้แสดงความสัมพันธ์ระหว่าง entity โดยแทนที่ด้วยรูปสี่เหลี่ยมข้าวหลามตัด ดังในภาพข้างล่าง Store Owns (เป็นเจ้าของ) Video (ในกรณีที่อ่านจากซ้ายไปขวา) หรือ Video IsOwnedBy (ถูกเป็นเจ้าของโดย) Store (ในกรณีที่อ่านจากขวาไปซ้าย) พึงสังเกตุว่าชื่อของ relationship types จะต้องเป็นคำกริยาเสมอ และความสัมพันธ์สามารถมี attribute ของตัวเองได้ เช่นในภาพ ความสัมพันธ์ Owns มี attribute คือ purchase Date และ cost
Cardinality Constraints
ใช้แสดงถึงข้อกำหนดของความสัมพันธ์ระหว่าง entity แบ่งออกเป็นสองแบบคือ
Cardinality ratio
ใช้แสดงถึงอัตราส่วนของความสัมพันธ์ แทนที่ด้วยตัวเลข 1, M และ N
1 : 1 แทนความสัมพันธ์แบบหนึ่งต่อหนึ่ง
1 : N แทนความสัมพันธ์แบบหนึ่งต่อหลาย
M : N แทนความสัมพันธ์แบบหลายต่อหลาย
Participation
ใช้แสดงการมีส่วนร่วมในความสัมพันธ์ของสมาชิกใน entity แทนที่ด้วยเส้นตรงหรือเส้นคู่
total (เส้นคู่) ทุก ๆ สมาชิกที่อยู่ใน entity จะต้องอยู่ในความสัมพันธ์ทั้งหมด
partial (เส้นเดี่ยว) บางส่วนของสมาชิกที่อยู่ใน entity เท่านั้นที่อยู่ในความสัมพันธ์
จากภาพข้างล่าง Store มีความสัมพันธ์ Owns กับ Video โดยหนึ่ง Store สามารถเป็นเจ้าของ Video ได้จำนวนหลาย ๆ Video แต่ว่าแต่ละ Video สามารถถูกเป็นเจ้าของได้โดย Store เพียงหนึ่ง Store เท่านั้น และแต่ละ Store อาจจะมี Video อยู่ในร้านหรือไม่มีก็ได้ (เส้นเดี่ยว) ในขณะที่ Video ทุก ๆ ม้วนจะต้องถูกเป็นเจ้าของโดยร้านค้าหนึ่งร้านเสมอ (เส้นคู่)
ตอนนี้เราได้เข้าใจสัญลักษณ์และองค์ประกอบต่าง ๆ ที่ใช้ในการเขียน E-R Diagram แล้ว ในตอนต่อไปเราจะได้ทำความเข้าใจหลักการที่ใช้ในการออกแบบข้อมูลด้วย E-R Diagram
เขียนโดย ชาคริต กุลไกรศรี
เราได้ทราบแล้วว่า E-R Diagram ประกอบขึ้นจากความสัมพันธ์ระหว่าง entity ตั้งแต่สอง entity ขึ้นไป ในการเขียน E-R Diagram เราจะต้องกำหนดให้ได้ก่อนว่าสิ่งที่เราสนใจ (problem domain) ซึ่งจะถูกนำมาเขียน E-R diagram นั้น สิ่งไหนจะใช้แทน entity สิ่งไหนจะใช้แทน attribute และสิ่งไหนจะใช้แทน relationship type ซึ่งการกำหนดดังกล่าวมักเป็นปัญหาใหญ่สำหรับนักศึกษาที่ต้องเขียน E-R diagram จากโจทย์ที่ได้รับ เพราะไม่แน่ใจว่าอะไรควรจะเป็น entity หรืออะไรควรจะเป็น attribute หรือเป็น relationship type กันแน่? ซึ่งมักทำให้เขียน E-R diagram ออกมาผิดจากโจทย์ที่ตั้งไว้หรือ E-R diagram ดังกล่าวไม่สามารถสื่อความหมายที่นักพัฒนาระบบต้องการสื่อสารกับยูสเซอร์ได้
ในตัวอย่างต่อไปนี้จะแสดงหลักการที่ถูกต้องในการเขียน E-R diagram เราลองมาดูโจทย์และรูป E-D Diagram ซึ่งจะใช้เป็นแบบฝึกหัดในการเขียน E-R diagram เบื้องต้นให้ถูกต้องดังต่อไปนี้
ร้านให้เช่าวีดีโอต้องการเก็บข้อมูลวีดีโอที่ให้เช่าแก่ลูกค้า โดยทางร้านต้องการเก็บข้อมูลด้วยว่าวีดีโอนี้อยู่ในร้านหรือถูกเช่าไปแล้วและมีค่าเช่าต่อม้วนเท่าไหร่ และต้องการทราบประวัติการเช่าวีดีโอของลูกค้า?
ในการแปลโจทย์ดังกล่าวให้อยู่ในรูปของ ER-diagram ดังรูปข้างบนให้ทำตามหลักการในแต่ละขั้นตอนดังต่อไปนี้
1. หาคำนามในประโยคว่าคำไหนใช้แทน entity และอะไรใช้แทน attribute
จากโจทย์ข้างบนคำนามที่พบคือ ร้านให้เช่าวีดีโอ วีดีโอ ลูกค้า ค่าเช่า
เราทำการพิจารณาทีละคำ
– ร้านให้เช่าวีดีโอ จากในโจทย์บอกว่า ร้านให้เช่าวีดีโอต้องการเก็บข้อมูลฯ แสดงว่าร้านให้เช่าวีดีโอเป็นผู้ที่ต้องการใช้ข้อมูลแต่ไม่ใช่ส่วนหนึ่งของข้อมูล ดังนั้น ร้านให้เช่าวีดีโอ จึงไม่ใช่ entity
-วีดีโอ จากในโจทย์บอกว่า วีดีโอที่ให้เช่าแก่ลูกค้า แสดงถึงความสัมพันธ์ระหว่าง วีดีโอกับลูกค้าคือการให้เช่า ดังนั้น วีดีโอ จึงเป็น entity (video)
-ลูกค้า เช่นเดียวกับข้างบน ลูกค้าสัมพันธ์กับวีดีโอ คือเช่าวีดีโอ ดังนั้น ลูกค้า จึงเป็น entity (customer)
-ค่าเช่า จากในโจทย์บอกว่า วีดีโอนี้อยู่ในร้านหรือถูกเช่าไปแล้วและมีค่าเช่าต่อม้วนเท่าไหร่? จะเห็นว่าประโยคดังกล่าวเป็นความต้องการทราบข้อมูลเพิ่มเติมที่เกิดจากการเช่า ดังนั้น ค่าเช่า จึงเป็น attribute (cost)
และจากประโยค วีดีโอนี้อยู่ในร้านหรือถูกเช่าไปแล้ว บอกถึงความต้องการข้อมูลเพิ่มเติมเพื่อที่จะใช้บอกว่าวีดีโอนี้อยู่ในร้านหรือถูกเช่าไปแล้ว ดังน้ันเราจึงเพิ่ม attribute เข้าไปเพื่อให้สามารถบอกสถานะดังกล่าวได้คือ วันกำหนดคืน, วันที่เช่า (dateDue, dateRented)
cost, dateDue, dateRented เป็น attribute ของการเช่า(rental)
2. พิจารณาคำที่ใช้บอกความสัมพันธ์ว่าควรจะกำหนดให้เป็น relationship หรือ entity
จากโจทย์ข้างต้นคำที่ใช้บอกความสัมพันธ์คือ เช่า ซึ่งเมื่อมองเผิน ๆ แล้ว ควรจจะกำหนดให้เป็น relationship type แต่ในที่นี้ เราไม่สามารถกำหนด เช่า เป็น relationship type ได้ เพราะว่าจากโจทย์ และต้องการทราบประวัติการเช่าวีดีโอของลูกค้า? ถ้าเรากำหนดให้ เช่า เป็นความสัมพันธ์ระหว่างลูกค้ากับวีดีโอ จะได้ (ลูกค้า—-เช่า—-วีดีโอ) ซึ่งวีดีโอจะมีสถานะอยู่สองสถานะคือถูกเช่าหรือยังไม่ถูกเช่า แต่เราไม่สามารถทราบได้ว่าลูกค้าเคยเช่าวีดีโอเรื่องอะไรบ้าง เพราะ relationship type ไม่สามารถเก็บข้อมูลได้เช่นเดียวกับ entity ดังนั้นเราจึงต้องกำหนดให้ เช่า เป็น entity ที่เรียกว่า การเช่า (Rental)
3. พิจารณาหาความสัมพันธ์ระหว่าง entity ที่เราหาได้
ถึงตอนนี้เราได้ entity ที่ต้องการแล้วคือ Customer(ลูกค้า) Video(วีดีโอ) และ การเช่า(Rental) เราต้องกำหนดความสัมพันธ์ให้ entity ทั้งสาม
ลูกค้าต้องการเช่าวีดีโอโดยผ่านการเช่า ดังนั้นลูกค้าจึงมีการเช่า (Customer—-Has—-Rental)
การเช่าแต่ละครั้งจะต้องมีวีดีโออยู่ในการเช่านั้น ดังนั้นการเช่าจึงมีวีดีโอ (Rental—-Has—-Video)
4. พิจารณาอัตราส่วนความสัมพันธ์ (Cardinality Constraints) ระหว่าง entity
ต่อไปเราพิจารณาอัตราส่วนความสัมพันธ์ระหว่าง entity
โดยทั่วไปแล้วลูกค้าสามารถมีการเช่าวีดีโอได้มากกว่าหนึ่งครั้ง แต่การเช่าแต่ละครั้งนั้นจะมาจากลูกค้าเพียงคนเดียวดังนั้นจึงเป็นความสัมพันธ์ 1 : M
เนื่องจากเราต้องการเก็บข้อมูลว่าวีดีโอแต่ละเรื่องนั้น เช่าเมื่อไหร่และถึงกำหนดคือเมื่อไหร่และสมมติว่าการเช่าวีดีโอหนึ่งเรื่องมีเพียงครั้งละหนึ่งม้วน แต่วีดีโอแต่ละม้วนสามารถอยู่ในการเช่าที่ต่างวาระกันได้หลาย ๆ ครั้ง ดังนั้นการเช่าจึงสัมพันธ์กับวีดีโอแบบ M : 1
5. พิจารณาการมีส่วนร่วมในความสัมพันธ์ (Participation)
ต่อไปเราพิจารณาการมีส่วนร่วมในความสัมพันธ์ของ entity
ลูกค้าบางคนอาจจะไม่เคยมีการเช่าวีดีโอเลยก็เป็นได้(เข้ามาเดินดูเฉย ๆ แต่ไม่เช่าก็ถือว่าเป็นลูกค้าเหมือนกัน) ดังนั้นความสัมพันธ์กับการเช่าจึงเป็นเพียงบางส่วน (partial) แทนที่ด้วยเส้นเดี่ยว
การเช่าแต่ละครั้งจะต้องเกิดจากลูกค้าที่เช่าเท่านั้น ไม่มีการเช่าครั้งไหนที่เกิดขึ้นได้โดยไม่มีลูกค้า ดังนั้นความสัมพันธ์ของการเช่ากับลูกค้าจึงเป็นแบบทั้งหมด (total) แทบที่ด้วยเส้นคู่
การเช่าแต่ละครั้งจะต้องมีวีดีโออยู่ในการเช่านั้น ไม่มีการเช่าครั้งไหนที่เกิดขึ้นได้โดยไม่มีวีดีโอ ดังนั้นความสัมพันธ์ของการเช่ากับวีดีโอจึงเป็นแบบทั้งหมด (total) แทบที่ด้วยเส้นคู่
วีดีโอแต่ละม้วนอาจจะถูกเช่าหรือไม่ถูกเช่าก็ได้ ดังนั้นความสัมพันธ์ของวีดีโอกับการเช่าจึงเป็นแบบเพียงบางส่วน (partial) แทนที่ด้วยเส้นเดี่ยว
6. พิจารณาว่า entity ใดเป็น weak entity
weak entity คือ entity ที่ไม่สามารถระบุการมีอยู่ของตนเองได้โดยอาศัย attribute ของตนเอง ในกรณีนี้ การเช่า (Rental) จะไม่สามารถคงอยู่ได้ ถ้าไม่มี entity Video คงอยู่ด้วย ดังนั้น Rental จึงเป็น weak entity (entity ที่เกิดจากความสัมพันธ์จะเป็น weak entity เสมอ) แทนที่ด้วยรูปสี่เหลี่ยมผืนผ้าซ้อนกันสองรูปและความสัมพันธ์ระหว่าง weak entity กับ entity หลัก ก็ต้องเป็นรูปสี่เหลี่ยมข้าวหลามตัดซ้อนกันสองรูป
ทั้งหมดคือหลักการในการเขียน E-R diagram ให้ถูกต้องตามโจทย์ความต้องการ
ในตอนต่อไปจะกล่าวถึงการเขียน E-R diagram แบบขยายหรือ Enhanced E-R (EER)
เขียนโดย ชาคริต กุลไกรศรี
พจนานุกรมข้อมูล (Data Dictionary)
What is a data dictionary?
- พจนานุกรมข้อมูล (Data Dictionary) เพื่ออธิบายความหมาย
ของข้อมูลต่างๆ ที่จัดเก็บภายในระบบฐานข้อมูล ซึ่งประกอบด้วย โครงร่าง
ของฐานข้อมูลในระดับต่างๆ รายละเอียดเกี่ยวกับการเรียกใช้ข้อมูลของผู้ใช้
และการรักษาความปลอดภัยของข้อมูล เป็นต้น
ตัวอย่าง ERD
Refer: Link1