การออกแบบฐานข้อมูล
| English | ไทย |
|---|---|
| relational database/rɪˈleɪʃənl ˈdeɪtəbeɪs/ | ฐานข้อมูลเชิงสัมพันธ์ |
| tables/ˈteɪblz/ | ตาราง |
| entities/ˈentɪtiz/ | เอนทิตี |
| primary key/ˈpraɪməri kiː/ | คีย์หลัก |
| foreign key/ˈfɒrən kiː/ | คีย์อ้างอิง |
| normalisation/ˌnɔːməlaɪˈzeɪʃn/ | การปรับมาตรฐาน |
Courses ที่เปลี่ยนชื่อหนึ่งรายการมีสองชื่อตอนนี้
- โรงเรียนคัดลอกชื่อ Course เข้าไปในทุกแถวการลงทะเบียน การเปลี่ยนชื่อบางสำเนาทำให้มีสองชื่อที่ขัดแย้งกันสำหรับ Course เดียวกัน
- ฐานข้อมูลเชิงสัมพันธ์ เก็บแถวใน ตาราง首先在ระบุ เอนทิตี เช่น นักเรียนและCourses และความสัมพันธ์ระหว่าง них
แยกตัวตนออกจากฉลากที่เปลี่ยนแปลงได้
- คีย์หลัก ระบุแถวได้อย่างเป็นเอกลักษณ์และไม่เป็น null ID นักเรียนที่มั่นคงช่วยให้เปลี่ยนชื่อได้โดยไม่เปลี่ยนตัวตนของนักเรียน
- คีย์ธรรมชาติสามารถใช้ได้เมื่อความเป็นเอกลักษณ์และความมั่นคงถูกรับประกัน ชื่อไม่ใช่คีย์ที่ดีในที่นี้เพราะนักเรียน不同的人อาจมีชื่อนี้เช่นเดียวกัน อีเมลก็อาจเปลี่ยนได้เช่นกัน
นักเรียนสามารถแชร์ชื่อและเปลี่ยนอีเมลได้ คีย์ nàoเหมาะที่สุดสำหรับการออกแบบนี้?
เลือกเอกลักษณ์ที่มั่นคง แทนที่จะเป็นฉลากที่ซ้ำซ้อนหรือเปลี่ยนแปลงได้
แทนความสัมพันธ์หลายต่อหลาย
- นักเรียนคนหนึ่งสามารถเรียนหลายCourses; Course หนึ่งสามารถมีนักเรียนหลายคน ใช้ตาราง registrations ที่มีแถวเดียวสำหรับคู่ student–course แต่ละคู่
- คีย์ภายนอก เชื่อมโยงแต่ละ registration กับคีย์ student หรือ course ที่ถูกต้อง คีย์หลักแบบผสม
(student_id, course_id)ป้องกันไม่ให้คู่เดียวกันปรากฏซ้ำ
แบบจำลองใดแสดงถึงนักเรียนที่เรียนหลายวิชาและวิชาที่มีนักเรียนหลายคน?
แต่ละการลงทะเบียนบันทึกคู่ระหว่างนักเรียน–วิชาหนึ่งครั้ง
กุญแจประเภทใดที่เชื่อมโยงการลงทะเบียนเข้ากับกุญแจรายวิชามีอยู่เดิม?
กุญแจภายนอกแสดงถึงและจำกัดการอ้างอิงนี้เมื่อมีการเปิดใช้การบังคับใช้
ข้อจำกัดใดป้องกันคู่的学生–รายวิชา เดียวกันปรากฏขึ้นสองครั้ง?
กุญแจหลักแบบคอมโพสิตระบุคู่ดังกล่าว
เก็บข้อเท็จจริงของCourse ไว้กับCourse
- การปรับรูปแบบ จัดระเบียบตารางโดยใช้การพึ่งพาต่อกันเพื่อลดการซ้ำซ้อนที่ไม่สอดคล้องกัน ในการออกแบบนี้ Course ID กำหนดชื่อของมัน ดังนั้นเก็บชื่อไว้ในcourses
- ค่าคีย์ภายนอกที่ซ้ำกันเป็นเรื่องปกติ: registrations หลายรายการสามารถอ้างอิงถึงCourse เดียวกัน “ห้ามซ้ำค่าใดๆ” ไม่ใช่กฎการออกแบบฐานข้อมูลที่มีประโยชน์
การระบุรหัสรายวิชาซ้ำในแถวการลงทะเบียนหลายบรรทัดถือเป็นความผิดพลาดในการปรับมาตรฐานเสมอ
การอ้างอิงซ้ำนั้นคาดหวังไว้ การคัดลอกชื่อรายวิชาลงในแต่ละบรรทัดความสัมพันธ์จึงก่อให้เกิดปัญหาการอัปเดต在此处
เปิดใช้งานและทดสอบข้อจำกัด
- ใน SQLite ให้เปิดการบังคับใช้คีย์ภายนอกในแต่ละการเชื่อมต่อด้วย
PRAGMA foreign_keys = ONก่อนเริ่มงาน การประกาศความสัมพันธ์เพียงอย่างเดียวไม่เพียงพอ - ทดสอบการลงทะเบียนที่ถูกต้อง คู่ซ้ำ และการลงทะเบียนที่อ้างอิงถึงรายวิชาที่หายไป ข้อจำกัดควรปฏิเสธสองกรณีหลัง;但它们ไม่ตัดสินใจว่าผู้เรียกใช้รายใดมีสิทธิ์เข้าถึง
PRAGMA foreign_keys = ON;
CREATE TABLE students (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
CREATE TABLE courses (id INTEGER PRIMARY KEY, title TEXT NOT NULL);
CREATE TABLE enrolments (
student_id INTEGER REFERENCES students(id),
course_id INTEGER REFERENCES courses(id),
PRIMARY KEY (student_id, course_id),
CHECK (student_id IS NOT NULL AND course_id IS NOT NULL)
);
การประกาศกุญแจภายนอกของ SQLite หมายความว่าถูกบังคับใช้ในทุกการเชื่อมต่อโดยไม่จำเป็นต้องเปิดใช้งาน
เปิดใช้ PRAGMA foreign_keys = ON ในแต่ละการเชื่อมต่อและตรวจสอบพฤติกรรม
ตรวจสอบการออกแบบกับกรณีใหม่
- สำหรับรายการยืมหนังสือ ชื่อหนังสืออาจไม่ใช่สำเนาทางกายภาพที่เป็นเอกลักษณ์เดียว ให้ระบุผู้ยืม สำเนา และเหตุการณ์ยืมก่อนเลือกคีย์
- ตัดสินใจว่าเหตุการณ์ซ้ำสามารถอนุญาตได้หรือไม่ คู่ นักเรียน–รายวิชา สามารถระบุการลงทะเบียนหนึ่งครั้งในที่นี้ แต่คู่ ผู้ยืม–สำเนา ไม่สามารถแยกแยะการยืมซ้ำในวันที่ต่างกันได้
เลือกคีย์สำหรับตัวตนที่ต้องการ แยกข้อเท็จจริงของเอนทิటీออกจากแถวความสัมพันธ์ แล้วตรวจสอบความไม่ซ้ำและข้อจำกัดการอ้างอิงด้วยกรณีเฉพาะเจาะจง
เสนอ entidad และกุญแจสำหรับห้องสมุดซึ่งผู้ยืมสามารถยืมสำเนาเดียวกันได้มากกว่าหนึ่งครั้ง
ใช้รหัสผู้ยืม รหัสสำเนา และเอกลักษณ์เหตุการณ์ยืมแยกต่างหากพร้อมรายละเอียดเหตุการณ์ที่จำเป็น
ทำไมคู่ผู้ยืม–สำเนาเพียงอย่างเดียวจึงไม่เพียงพอเป็นกุญแจสำหรับการยืมซ้ำ?
กุญแจต้องแยกแยะเหตุการณ์จริงที่ต้องการบันทึก