ฉันมีปัญหากับฟอร์มปกติที่สอง (2NF) และฉันไม่สามารถแก้ไขได้โดยใช้ Google มันทำให้ฉันเป็นบ้าเพราะฉันเป็นครูและฉันไม่ต้องการสอนสิ่งผิด ๆ ให้กับนักเรียนของฉัน

มามีตารางที่มี 5 ฟิลด์กัน

Gradings = {StudentName, SubjectCode, SubjectName, #Exam, Grade}

การพึ่งพาเป็นเช่นนี้:

StudentName, SubjectCode, #Exam -> Grade

SubjectCode -> SubjectName

SubjectName -> SubjectCode

ดังนั้นที่สำคัญผู้สมัคร 1 {StudentName, SubjectCode, #Exam}และที่สำคัญผู้สมัคร 2 {StudentName, subjectName, #Exam}

แอตทริบิวต์ที่สำคัญคือ{StudentName, SubjectCode, SubjectName, #Exam}และแอตทริบิวต์ที่ไม่ใช่นายกรัฐมนตรีคือGrade

ตามคำจำกัดความของรูปแบบปกติที่สองแอตทริบิวต์ที่ไม่ใช่นายกไม่สามารถขึ้นอยู่กับส่วนของคีย์ตัวเลือก แอ็ตทริบิวต์ที่ไม่ใช่ไพรม์เท่านั้น (เกรด) ไม่ได้ขึ้นอยู่กับส่วนของคีย์ตัวเลือกดังนั้นตารางนี้จะปรากฏเป็น 2NF

ปัญหาคือฉันคิดว่ามีบางอย่างผิดปกติ (และฉันอาจผิด) ฉันคิดว่าผู้เข้าร่วมการศึกษาควรมีตารางของตนเอง

Gradings = {StudentName, รหัสวิชา, #Exam, เกรด}

Subjects = {รหัสหัวเรื่อง, SubjectName}

แต่ 2NF ไม่ได้ผลิตสิ่งนี้ 3NF นั้นเกี่ยวกับการพึ่งพาระหว่างคุณลักษณะที่ไม่ใช่แบบเฉพาะดังนั้นมันจึงไม่สร้างสิ่งนี้ แต่สำหรับฉันแล้วดูเหมือนว่านี่เป็นผลลัพธ์ที่ถูกต้องเพราะไม่มีความซ้ำซ้อน

ฉันเดาว่าแอตทริบิวต์ที่ไม่เฉพาะเจาะจงถูกกำหนดเป็น "แอตทริบิวต์ที่ไม่ใช่คีย์ตัวเลือก" 2NF จะให้ผลลัพธ์ที่ต้องการ แต่ฉันได้ตรวจสอบสิ่งนี้ซ้ำแล้วซ้ำอีกและแอตทริบิวต์ที่ไม่สำคัญถูกกำหนดเป็น "แอตทริบิวต์ที่ไม่ได้อยู่ในคีย์ตัวเลือก"

ผมทำอะไรผิดหรือเปล่า?

ความสัมพันธ์ของคุณอยู่ใน 3NF (และไม่เพียง แต่ใน 2NF) เนื่องจากคุณบอกว่าคุณลักษณะที่ไม่สำคัญเพียงอย่างเดียวคือเกรดซึ่งจะปรากฏที่ด้านขวามือของ FD ของคุณเท่านั้น

ความสัมพันธ์ไม่ได้อยู่ใน BCNF เพราะด้านซ้ายของ FD ขนาดเล็กทั้งสองไม่ใช่ซุปเปอร์คีย์

อย่างไรก็ตามคุณสามารถแยกความสัมพันธ์กับ ( SubjectCode , SubjectName ) และ ( StudentName, SubjectCode, #Exam, Grade ) หรือ ( StudentName, SubjectName, #Exam, Grade )

การสลายตัวนี้ให้ความสัมพันธ์ BCNF สองแบบแก่คุณและรักษาการพึ่งพาการทำงานทั้งหมด สิ่งนี้เป็นไปไม่ได้เสมอ (คุณสามารถสลายความสัมพันธ์กับ 3NF แต่ไม่จำเป็นต้องเป็น BCNF เสมอไป)

2NF

หากคุณต้องการตัวอย่างของ 2NF (และไม่ใช่ 3NF) ความสัมพันธ์ของคุณต้องมีการอ้างอิงสกรรมกริยา

ตัวอย่างเช่นสมมติว่าคุณมีคอลัมน์คะแนน คะแนนโดยสังเขป -> คะแนนเนื่องจากการสอบทั้งหมดที่มีคะแนนเท่ากันควรได้คะแนนเท่ากัน (จะค่อนข้างไม่ยุติธรรม) แต่โปรดทราบว่าเราไม่สามารถพูดคะแนน -> คะแนนได้เนื่องจากคะแนนหลายคะแนนสามารถมีคะแนนเท่ากัน (11% และ 12% น่าจะเป็น "ล้มเหลว" เป็นต้น)

ตอนนี้ความสัมพันธ์ของคุณคือ:

การไล่สี ( StudentName, SubjectCode, SubjectName, #Exam, คะแนน, เกรด )

และคุณมีรูปแบบใหม่ของความซ้ำซ้อนตั้งแต่ทุกครั้งที่คุณป้อนผลลัพธ์ด้วยคะแนนเดียวกันกับเร็กคอร์ดการไล่เฉดสีอื่นคุณต้องซ้ำเกรดที่เกี่ยวข้องอีกครั้ง เพื่อให้ได้ 3NF คุณสามารถสลายตัวได้

ScoreGrades ( คะแนน, คะแนน )

ด้วยคะแนนเป็นกุญแจสำคัญและ

คะแนน ( StudentName, SubjectCode, SubjectName, #Exam, คะแนน )

คุณพูดถูกทุกสิ่ง รหัสวิชา SubjectName ต้องไปในตารางของตัวเองเพื่อบังคับใช้การอ้างอิงที่ต้องการ นี่เป็นตัวอย่างที่ดีว่าทำไม 2NF และ 3NF ไม่เพียงพอที่จะสร้างการออกแบบฐานข้อมูลที่ดี - คุณต้อง Boyce Codd Normal Form (BCNF) แทน

2NF และ 3NF ถูกแทนที่โดย BCNF ซึ่งการพูดจริงทำให้ NFs ที่น้อยกว่าล้าสมัย * BCNF เป็นสิ่งที่สำคัญกว่าและง่ายกว่าในการอธิบายและนำไปใช้ ในฐานะครูฉันแนะนำให้คุณใช้เวลามากขึ้นกับ BCNF และน้อยกว่าใน 2NF และ 3NF หากตารางมีคุณสมบัติตรงตามข้อกำหนดของ BCNF ตารางนั้นก็สอดคล้องกับ 2NF และ 3NF เช่นกัน

* 3NF ไม่ใช่รูปแบบปกติที่ได้รับการสงวนไว้สูงสุด Elementary Key Normal Form (EKNF) คือ การพูดอย่างเคร่งครัดคือ EKNF ไม่ใช่ BCNF ที่ทำให้ 3NF ล้าสมัย แต่ EKNF ถูกละเลยอย่างไม่เป็นธรรมและตำราและหลักสูตรส่วนใหญ่ไม่ได้พูดถึงมัน สิ่งที่มีจำนวนเท่ากันก็คือการออกแบบให้ BCNF จากนั้นตรวจสอบว่าการอ้างอิงที่ต้องการทั้งหมดและกฎความสมบูรณ์อื่น ๆ สามารถบังคับใช้ได้อย่างเหมาะสม - ถ้าไม่ให้ปรับเปลี่ยนการออกแบบ ไม่มี NFs ใดเป็นโซลูชั่นที่สมบูรณ์สำหรับความสมบูรณ์ของข้อมูล แต่โดยทั่วไปแล้ว BCNF จะใกล้เคียงที่สุดและเป็นวิธีที่ง่ายที่สุดในการอธิบายและใช้งาน

ฉันจะไม่พูดว่ามันนานแค่ไหนแล้วตั้งแต่ฉันได้เรียนรู้สิ่งนี้ทั้งหมด แต่ฉันจำได้ว่าฉันมีศาสตราจารย์คนหนึ่งที่สอนความหมายที่ถูกต้องของ "การพึ่งพาการใช้งาน" และ "คุณลักษณะที่ไม่ใช่นายก" และ "buzzwords อื่น ๆ " ให้พวกเรามีคำถามง่ายๆเพื่อถามว่าเป็นเรื่องปกติหรือไม่ ถึงแบบฟอร์มแล้ว ลองดูว่าฉันสามารถจำได้ว่าไกลหลัง ...

เราได้ระบุรหัสผู้สมัครแล้วดังนั้นเราจึงถามคำถามนี้ถึงคุณลักษณะที่ไม่ใช่นายก ในกรณีนี้จะมีเพียงเกรดเดียวเท่านั้น

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

แก้ไข: VVV

แต่คำตอบก็อาจเป็นชื่อนักเรียนชื่อเรื่องและการสอบ นี่จะตรงกับคีย์ตัวที่สอง

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

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

แต่แทนที่จะเอาคำตอบส่วนนั้นออกฉันจะเก็บไว้เพื่อเปรียบเทียบ

สิ้นสุดการแก้ไข: ^ ^ ^

ข้อมูลขั้นต่ำที่แน่นอนคืออะไรเราจำเป็นต้องระบุชื่อเรื่องเฉพาะ?

หัวเรื่องขึ้นอยู่กับ SubjectCode เท่านั้น - เซตย่อยของคีย์ตัวเลือก tuple นี้ไม่ได้อยู่ใน 2nf SubjectCode ควรเป็นคีย์หลักของตาราง Subjects เพื่อให้เป็นตำแหน่งที่เหมาะสมในการวาง SubjectName ลบออกจาก tuple นี้และตอนนี้ก็เป็น 2nf

หากเราถามคำถามเกี่ยวกับคุณลักษณะและคำตอบนั้นไม่ได้ทั้งหมดหรือบางส่วนของรหัสผู้สมัครดังนั้น tuple นั้นไม่ได้อยู่ใน 3nf แต่ tuple นี้ยังเป็นเรื่องเล็กน้อยใน 3nf และที่อื่น ๆ เนื่องจากเราใช้พื้นที่จนหมดในการถามคำถาม ;)

หมายเหตุ:เมื่อเราพูดว่า "normalize" เรากำลังอ้างถึงกระบวนการที่ใช้กับเอนทิตีแบบลอจิคัล เนื่องจาก tuple ที่ให้มาดูเหมือนจะเป็นคำจำกัดความของเอนทิตีที่เรียกว่า "grade" ดังนั้นเราจึงสามารถทำให้เป็นมาตรฐานได้ อย่างไรก็ตามถึงจุดหนึ่งฉันกล่าวว่า "tuple นี้ไม่ได้อยู่ใน 2nf" ซึ่งควรได้รับอย่างถูกต้องมากขึ้น " เอนทิตีนี้ไม่ได้อยู่ใน 2nf" ฉันขอโทษถ้าสิ่งนี้ทำให้เกิดความสับสน

แอ็ตทริบิวต์ที่ไม่ใช่ไพรม์เท่านั้น (เกรด) ไม่ได้ขึ้นอยู่กับส่วนของคีย์ตัวเลือกดังนั้นตารางนี้จะปรากฏเป็น 2NF

มันอยู่ใน 2NF

ปัญหาคือฉันคิดว่ามีบางอย่างผิดปกติ (และฉันอาจผิด) ฉันคิดว่าผู้เข้าร่วมการศึกษาควรมีตารางของตนเอง

ไม่มีเหตุผลที่จะคาดหวังว่าควรจะมีวิชาที่โต๊ะของตัวเองของพวกเขาไม่เป็นสำหรับการสลายตัวของตารางเดิมที่จะ 2NF คุณกำลังสับสนกับความคิดที่คลุมเครือของ "ควร" กับสิ่งที่รูปแบบปกติใด ๆ ให้กับคุณจริง ๆ

3NF นั้นเกี่ยวกับการพึ่งพาระหว่างคุณลักษณะที่ไม่ใช่แบบเฉพาะดังนั้นมันจึงไม่สร้างสิ่งนี้

"3NF นั้นเกี่ยวกับการพึ่งพาระหว่างคุณลักษณะที่ไม่ใช่นายก" ไม่ใช่คำจำกัดความที่เหมาะสมของ 3NF ดังนั้น "ดังนั้นมันจึงไม่สร้างสิ่งนี้เช่นกัน" ไม่ใช่ข้อสรุปที่ชัดเจน แม้ว่าการใช้คำจำกัดความที่แท้จริงจะแสดงให้เห็นว่าตารางอยู่ใน 3NF โดยไม่จำเป็นต้องใช้ตารางนักเรียน แต่อีกครั้งไม่มีเหตุผลที่จะคาดหวังว่าจะมี

แต่สำหรับฉันแล้วดูเหมือนว่านี่เป็นผลลัพธ์ที่ถูกต้องเพราะไม่มีความซ้ำซ้อน

อีกครั้ง "ความซ้ำซ้อน" นั้นไม่คลุมเครือดังนั้น "เพราะ" และความคาดหวังของตารางนักเรียนของคุณจะไม่ได้รับความเสียหาย รูปแบบปกติที่แตกต่างกันนั้นฟรีและขึ้นอยู่กับความผิดปกติบางประเภทและ "ความซ้ำซ้อน" ที่เกี่ยวข้อง แต่ "ความซ้ำซ้อน" อื่น ๆ ที่ไม่ได้รับการแก้ไขด้วยการทำให้เป็นมาตรฐานนั้นสามารถคงอยู่ได้

ตารางนี้ไม่ได้อยู่ใน BCNF เนื่องจากมี FD ที่ไม่ได้มาจาก CKs การแยกย่อยมันต่อ BCNF นำไปสู่การมีตารางนักเรียน BCNF เป็นรูปแบบปกติสูงสุดสำหรับการจัดการกับ JD (เข้าร่วมการอ้างอิง) ที่มาพร้อมกับ FDs อย่างไรก็ตาม JD อื่น ๆ อาจเป็นปัญหาได้ (เช่นไม่ใช่ "โดยนัยถึง CKs") และควรลบออกโดยการทำให้เป็นมาตรฐานไปที่ 5NF

PS ตารางต้นฉบับยังสอดคล้องกับ FD {StudentName, SubjectName, #Exam} -> Grade

การพึ่งพาเป็นเช่นนี้:

สิ่งนี้ควรหมายถึงอะไร มันไม่ชัดเจน

คุณหมายถึง "สิ่งเหล่านี้คือ FD ที่ไม่ใช่เรื่องไร้สาระที่ถือ"? ไม่เพราะมันหมายถึงสี่ "นี่คือ FD บางส่วนที่ถือ"? ไม่นั่นหมายความว่า FDs ในการถือปิดสกรรมกริยา แต่ไม่ได้บอกว่าคนอื่นไม่ถือ แต่คุณก็สามารถกำหนด CK ได้ "FDs ที่ถือเป็นสิ่งที่ปิดการถ่ายทอดเหล่านี้" หากคุณหมายถึงอย่างนั้นคุณก็จะรู้ได้ก็ต่อเมื่อคุณแสดงให้เห็นแล้วนั่นคือคุณจะต้องพบว่าการปิด (โดยทั่วไปคือผ่านฝาครอบขั้นต่ำ / มาตรฐาน) แล้วแสดงให้เห็นว่าไม่มี FD อื่น ๆ ใช่มั้ย ไม่ว่าสิ่งที่คุณเขียนไม่ได้หมายความว่า ดังนั้นฉันจึงคาดหวังว่าคุณไม่ได้ให้เหตุผลที่ดีเกี่ยวกับสถานการณ์ FD & CK

คุณถูกต้องวิชาต้องการตารางของตัวเอง หากคุณเลือกหนึ่งในกุญแจของตัวเลือกของคุณอย่างใดอย่างหนึ่งsubject_codeหรือsubject_nameกลายเป็นคีย์ที่ไม่ใช่หลัก จากนั้นคุณลบฟิลด์วิชาที่ไม่ใช่หลักออกจากตารางการไล่ระดับสี

คุณมีการพึ่งพาการทำงานในเรื่องที่คุณมีตัวระบุที่ไม่ซ้ำกันสองตัว นี่คือการแสดงโดยพึ่งพาสกรรมกริยาระหว่างและsubject_code subject_nameนี่เป็นการระบุความต้องการในการสร้างตารางที่มีทั้งสองฟิลด์และลบหนึ่งในฟิลด์เหล่านี้ออกจากตารางอื่นทั้งหมด ตารางนี้อาจมีคอลัมน์ที่ต้องพึ่งพาเพิ่มเติมได้เป็นอย่างดีถึงแม้ว่าฉันจะไม่เห็นในตัวอย่างนี้ ในแบบฟอร์มปกติที่ 3 ที่คุณเลือก

คะแนนขึ้นอยู่กับอีกสามฟิลด์ (คีย์ผู้สมัคร) ในตารางการไล่ระดับสีใหม่ ตามที่ระบุไว้ข้างต้นคุณจะต้องเลือกหนึ่งในฟิลด์ผู้สมัครสำหรับตารางวิชา โดยปกติจะเป็นค่ารหัสหากมีให้เนื่องจากมีแนวโน้มที่จะมีเสถียรภาพมากขึ้น รูปแบบผลลัพธ์เป็น 3nf เนื่องจากฟิลด์ที่ไม่ใช่คีย์ทั้งหมดขึ้นอยู่กับฟิลด์ในคีย์หลัก

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

นักเรียนก็อาจกลายเป็นตารางแยกต่างหากเนื่องจากเป็นไปได้ที่จะมีนักเรียนหลายคนที่มีชื่อเดียวกัน สิ่งนี้อาจแก้ไขได้ด้วยการเพิ่มคีย์หลักสังเคราะห์ (หมายเลขนักเรียน?)

subjects --->  sessions ---+--> grades
students  -----------------+

ฉันกำลังเตรียมที่จะลบสิ่งนี้เนื่องจากถือว่าไม่ถูกต้อง

ชื่อหัวเรื่องเป็นแอตทริบิวต์ที่ไม่สำคัญและขึ้นอยู่กับส่วนหนึ่งของรหัสหัวเรื่องหลัก (กฎการแบ่ง - จะต้องไม่มีการพึ่งพาบางส่วนของคอลัมน์ใด ๆ ในคีย์หลัก)

สิ่งนี้เป็นสิ่งต้องห้ามในแบบฟอร์มปกติที่ 2 และควรจะอยู่ในตารางของตัวเองตามที่คุณสงสัย

ฉันคิดว่าสถานที่ที่คุณติดค้างอยู่ในการระบุคีย์ตัวเลือกสองชุดเมื่อคุณสร้างตารางคุณต้องเลือกชุดตัวเลือกหนึ่งชุดเพื่อสร้างคีย์หลัก คอลัมน์ที่เหลือจะกลายเป็นแอตทริบิวต์ที่ไม่เฉพาะเจาะจงเช่นหากคุณเลือกรหัสผู้สมัครที่สองของคุณรหัสหัวเรื่องกลายเป็นแอตทริบิวต์ที่ไม่ได้ขึ้นอยู่กับส่วนของคีย์หลัก (ชื่อเรื่อง) และควรวางไว้ในตารางของตัวเอง

มันเป็นสิ่งสำคัญที่จะสอนรูปแบบที่ 1, 2 และ 3 ตามลำดับในขณะที่พวกเขาสร้างกัน BCNF ยังเป็นส่วนสำคัญในการขยายรูปแบบปกติที่ 3 ดังนั้นความเข้าใจที่แข็งแกร่งในระดับที่ต่ำกว่าเป็นสิ่งจำเป็น

เพิ่มเติม; นักพัฒนาซอฟต์แวร์ที่มีประสบการณ์จะไม่พิจารณาระดับของการทำให้เป็นมาตรฐานโดยอิสระเนื่องจากกฎหลายข้อนั้นใช้งานง่าย

พวกเขายังจะรู้ว่าเมื่อใดที่จะทำลายกฎการทำให้เป็นมาตรฐาน การทำให้เป็นมาตรฐานควรได้รับการปฏิบัติเพื่อเป็นแนวทางในการออกแบบที่ดีไม่ใช่กฎที่เข้มงวดฉันเชื่อว่านั่นจะเป็นจุดสอนที่ดี