Tôi gặp vấn đề với dạng bình thường thứ hai (2NF) và tôi đã không thể giải quyết nó bằng cách sử dụng Google. Nó làm tôi phát điên vì tôi là giáo viên và tôi không muốn dạy những thứ sai cho học sinh của mình.

Hãy có một bảng với 5 trường.

Gradings = {StudentName, SubjectCode, SubjectName, #Exam, Lớp}

Phụ thuộc theo cách này:

StudentName, SubjectCode, #Exam -> Lớp

Mã chủ đề -> Tiêu đề

Tên chủ đề -> Tiêu đề mã

Do đó, khóa ứng viên 1 là {StudentName, SubjectCode, #Exam} và khóa ứng viên 2 là {StudentName, SubjectName, #Exam} .

Các thuộc tính nguyên tố là {StudentName, SubjectCode, SubjectName, #Exam} và các thuộc tính không chính là Lớp

Theo định nghĩa của dạng thông thường thứ hai, một thuộc tính không phải là số nguyên tố có thể phụ thuộc vào một phần của khóa ứng viên. Thuộc tính không nguyên tố duy nhất (Lớp) không phụ thuộc vào một phần của khóa ứng viên nên bảng này có vẻ như trong 2NF.

Vấn đề là tôi nghĩ có gì đó không ổn (và tôi có thể sai). Tôi nghĩ các đối tượng nên có bảng riêng của họ.

Điểm số = {Tên sinh viên, Mã môn học, #Exam, Lớp}

Đối tượng = {Mã chủ đề, Tên chủ đề}

Nhưng 2NF không tạo ra điều này. 3NF là về sự phụ thuộc giữa các thuộc tính không phải là số nguyên tố nên nó cũng không tạo ra điều này. Nhưng dường như đây là kết quả đúng đắn, bởi vì nó không có sự dư thừa.

Tôi đoán nếu thuộc tính không phải là số nguyên tố được định nghĩa là "thuộc tính không phải là khóa ứng cử viên", 2NF sẽ tạo ra kết quả mong muốn. Nhưng tôi đã kiểm tra điều này nhiều lần và thuộc tính không phải là số nguyên tố được định nghĩa là "thuộc tính không BẮT ĐẦU cho khóa ứng viên".

Tôi đang làm gì sai?

Mối quan hệ của bạn là trong 3NF, (và không chỉ trong 2NF), vì như bạn nói, thuộc tính không nguyên tố duy nhất là Lớp , chỉ xuất hiện ở phía bên phải của FD của bạn.

Mối quan hệ không nằm trong BCNF, vì phía bên trái của hai FD nhỏ không phải là một siêu khóa.

Tuy nhiên, bạn có thể phân tách một cách dễ dàng mối quan hệ với ( SubjectCode , SubjectName ) và ( StudentName, SubjectCode, #Exam, Lớp ) hoặc ( StudentName, SubjectName, #Exam, Lớp )

Sự phân tách này cung cấp cho bạn hai quan hệ BCNF và duy trì tất cả các phụ thuộc chức năng. Điều này không phải lúc nào cũng có thể (bạn luôn có thể phân tách mối quan hệ với 3NF, nhưng không nhất thiết phải là BCNF).

2NF

Nếu bạn muốn có một ví dụ về 2NF (chứ không phải 3NF), mối quan hệ của bạn cần phải chứa các phụ thuộc bắc cầu.

Ví dụ: giả sử bạn có cột Điểm. Điểm trực quan-> Điểm vì tất cả các bài kiểm tra có cùng số điểm sẽ có cùng điểm (điều này sẽ không công bằng nếu không), nhưng lưu ý rằng chúng ta không thể nói Điểm-> Điểm vì một số điểm có thể có cùng điểm (11% và 12% chẳng hạn như "Thất bại".

Bây giờ mối quan hệ của bạn là:

Điểm số ( StudentName, SubjectCode, SubjectName, #Exam, Điểm, Lớp )

và bạn có một hình thức dự phòng mới vì mỗi lần bạn nhập một kết quả có cùng số điểm với một bản ghi Điểm khác, bạn cũng phải lặp lại Điểm tương ứng. Do đó, để có được 3NF, bạn có thể phân hủy thành

ScoreGrades ( Điểm, Điểm )

với Điểm số là chìa khóa và

Điểm số ( StudentName, SubjectCode, SubjectName, #Exam, Score )

Bạn đúng trong mọi điều bạn nói. Mã chủ đề, Tên chủ đề cần phải đi trong bảng riêng của họ để thực thi các phụ thuộc mong muốn. Đây là một ví dụ tốt về lý do tại sao 2NF và 3NF không đủ để tạo ra các thiết kế cơ sở dữ liệu tốt - thay vào đó bạn cần Boyce Codd Form Form (BCNF).

2NF và 3NF được thay thế bởi BCNF, thực tế mà nói làm cho những NF nhỏ hơn trở nên lỗi thời *. BCNF là quan trọng hơn và đơn giản hơn để giải thích và áp dụng. Là một giáo viên, tôi khuyên bạn nên dành nhiều thời gian hơn cho BCNF và ít hơn cho 2NF và 3NF. Nếu một bảng thỏa mãn các yêu cầu của BCNF thì nó cũng thỏa mãn 2NF và 3NF.

* 3NF không phải là Mẫu thường bảo tồn phụ thuộc cao nhất. Mẫu chính khóa thông thường (EKNF) là. Nói một cách chính xác, đó là EKNF, không phải BCNF, khiến 3NF trở nên lỗi thời, nhưng EKNF bị lãng quên một cách bất công và hầu hết các sách giáo khoa và khóa học thậm chí không đề cập đến nó. Số tiền tương tự là thiết kế cho BCNF và sau đó kiểm tra xem tất cả các phụ thuộc mong muốn và bất kỳ quy tắc toàn vẹn nào khác có thể được thực thi đúng - nếu không, sau đó sửa đổi thiết kế. Không ai trong số các NF là một giải pháp hoàn chỉnh cho tính toàn vẹn dữ liệu nhưng BCNF thường đến gần nhất và là cách dễ nhất để giải thích và sử dụng.

Tôi sẽ không nói đã bao lâu kể từ khi tôi mới học tất cả những điều này. Nhưng tôi nhớ rằng tôi đã có một giáo sư, sau khi dạy cho chúng tôi ý nghĩa đúng đắn của "phụ thuộc chức năng" và "thuộc tính không chính" và tất cả các từ thông dụng khác, đã cho chúng tôi một loạt các câu hỏi đơn giản để hỏi xem có bình thường không hình thức đã đạt được. Hãy xem liệu tôi có thể nhớ được điều đó không ...

Chúng tôi đã xác định (các) khóa ứng viên nên chúng tôi đặt câu hỏi này cho các thuộc tính không phải là số nguyên tố còn lại. Trong trường hợp này, chỉ có một: lớp.

Thông tin tối thiểu tuyệt đối mà chúng ta cần để xác định điểm duy nhất là gì? Chúng ta cần biết học sinh, môn học và bài kiểm tra. Tốt, đây là một trong những chìa khóa ứng cử viên.

EDIT: VVV

Nhưng câu trả lời cũng có thể là tên sinh viên, tên môn học và bài kiểm tra. Điều này sẽ phù hợp với khóa ứng cử viên thứ hai.

Giả sử rằng SubjectCode và SubjectName đều là các khóa ứng cử viên cho thực thể Chủ thể, không có lý do gì để có cả hai trường này ở đây. Một tham chiếu duy nhất cho một hàng trong bảng Đối tượng là khá đủ. Vì vậy, chúng tôi có thể loại bỏ hoàn toàn trường Chủ đề mà không phải hy sinh bất kỳ tính toàn vẹn nào của mô hình.

Tuy nhiên, trong câu trả lời ban đầu của tôi, với mong muốn thể hiện một mức độ bình thường hóa khác, tôi đã bỏ qua rằng TitleName đã được sử dụng trong khóa ứng viên và coi đó chỉ là một thuộc tính không phải là số nguyên tố khác. Tôi đoán nó quá rõ ràng với tôi rằng đây là một lĩnh vực vô dụng, tôi nghĩ nó sẽ rõ ràng với mọi người và vì dù sao chúng ta đã thoát khỏi lĩnh vực này, vấn đề là gì?

Nhưng thay vì loại bỏ phần đó của câu trả lời, tôi sẽ giữ nó để so sánh.

EDIT KẾT THÚC: ^ ^ ^

Thông tin tối thiểu tuyệt đối mà chúng ta cần để xác định duy nhất tên chủ đề là gì?

SubjectName chỉ phụ thuộc vào SubjectCode - một tập hợp con của khóa ứng viên. Vì vậy, bộ dữ liệu này không có trong 2nf. SubjectCode phải là khóa chính của bảng Chủ đề để đó là vị trí thích hợp để đặt SubjectName. Xóa nó khỏi bộ dữ liệu này và bây giờ là 2nf.

Nếu chúng ta đặt câu hỏi về một thuộc tính và câu trả lời không phải là tất cả hoặc một phần của khóa ứng viên, thì bộ dữ liệu không nằm trong 3nf. Nhưng bộ dữ liệu này cũng tầm thường trong 3nf và hơn thế nữa, vì chúng tôi đã hết các lĩnh vực để đặt câu hỏi. ;)

Lưu ý: khi chúng tôi nói "bình thường hóa", chúng tôi đang đề cập đến một quy trình được áp dụng cho một thực thể logic. Vì tuple được cung cấp dường như là định nghĩa của một thực thể gọi là "lớp", nên chúng ta có thể bình thường hóa nó. Tuy nhiên, tại một thời điểm tôi đã nói "bộ dữ liệu này không có trong 2nf", mà đúng hơn là " thực thể này không ở trong 2nf". Tôi xin lỗi nếu điều này đã gây ra nhầm lẫn.

Thuộc tính không nguyên tố duy nhất (Lớp) không phụ thuộc vào một phần của khóa ứng viên nên bảng này có vẻ như trong 2NF.

Đó là trong 2NF.

Vấn đề là tôi nghĩ có gì đó không ổn (và tôi có thể sai). Tôi nghĩ các đối tượng nên có bảng riêng của họ.

Không có lý do để mong đợi rằng các đối tượng nên có bảng riêng để phân tách bảng gốc thành 2NF . Bạn đang nhầm lẫn một số khái niệm mơ hồ về "nên" với những gì mà bất kỳ hình thức bình thường cụ thể nào thực sự mang lại cho bạn.

3NF là về sự phụ thuộc giữa các thuộc tính không phải là số nguyên tố nên nó cũng không tạo ra điều này.

"3NF là về sự phụ thuộc giữa các thuộc tính không chính" không phải là định nghĩa đúng của 3NF vì vậy "vì vậy nó cũng không tạo ra điều này" không phải là một kết luận đúng đắn. Mặc dù áp dụng một định nghĩa thực tế cho thấy bảng nằm trong 3NF, không cần bảng sinh viên. Nhưng một lần nữa, không có lý do để mong đợi rằng sẽ có.

Nhưng dường như đây là kết quả đúng đắn, bởi vì nó không có sự dư thừa.

Một lần nữa, "sự dư thừa" là vô cùng mơ hồ, do đó, "vì" và kỳ vọng của sinh viên là không có cơ sở. Các hình thức bình thường khác nhau là miễn phí và chịu các loại dị thường cụ thể và "dư thừa" liên quan. Nhưng "sự dư thừa" khác không được giải quyết bằng cách chuẩn hóa có thể vẫn còn.

Bảng này không có trong BCNF, vì nó có các FD không nằm ngoài CK. Phân tách nó theo BCNF dẫn đến việc có bảng sinh viên. BCNF là hình thức bình thường cao nhất để xử lý các JD (tham gia phụ thuộc) đi kèm với các FD. Tuy nhiên, các JD khác có thể có vấn đề (nghĩa là không "ngụ ý bởi các CK") và nên được loại bỏ bằng cách chuẩn hóa thành 5NF.

PS Bảng gốc cũng thỏa mãn FD {StudentName, SubjectName, #Exam} -> Lớp.

Phụ thuộc theo cách này:

cái này có nghĩa là gì chứ? Nó không rõ ràng.

Ý bạn là, "Đây là tất cả các FD không tầm thường nắm giữ"? Không, bởi vì họ ngụ ý thứ tư. "Đây là một số FD giữ"? Không, điều đó có nghĩa là các FD trong trạng thái đóng tạm thời, nhưng điều đó không nói rằng các FD khác không giữ, nhưng bạn đã có thể xác định các CK. "Các FD giữ chính xác là những cái trong đóng cửa quá độ của những cái này"? Nếu bạn có ý đó, bạn sẽ chỉ biết nó nếu bạn đã hiển thị nó, tức là bạn sẽ phải tìm thấy sự đóng cửa đó (thông thường, thông qua một vỏ bọc tối thiểu / chính tắc) và sau đó cho thấy rằng không có FD khác; Bạn đã? Bất kể, những gì bạn viết chỉ không có nghĩa là. Vì vậy, tôi hy vọng rằng bạn không suy luận hợp lý về tình hình FD & CK.

Bạn đúng, đối tượng yêu cầu bảng riêng của nó. Nếu bạn chọn một trong các khóa ứng cử viên của mình, subject_codehoặc subject_nametrở thành khóa ứng viên không chính. Sau đó, bạn loại bỏ trường chủ đề không chính khỏi bảng phân loại.

Bạn có một phụ thuộc chức năng về chủ đề mà bạn có hai định danh duy nhất. Điều này được thể hiện bằng sự phụ thuộc quá độ giữa subject_codevà subject_name. Điều này cho thấy yêu cầu tạo bảng chứa hai trường đó và xóa một trong các trường này khỏi tất cả các bảng khác. Bảng này cũng có thể có các cột phụ thuộc bổ sung, mặc dù tôi không thấy cột nào trong ví dụ này. Ở dạng bình thường thứ 3 bạn đã chọn.

điểm phụ thuộc vào ba trường khác (khóa ứng viên) trong bảng phân loại mới. Như đã lưu ý ở trên, bạn cần chọn một trong các trường ứng cử viên cho bảng chủ đề. Thông thường đây sẽ là một giá trị mã nếu có sẵn vì chúng có xu hướng ổn định hơn. Mô hình kết quả là trong 3nf vì tất cả các trường không khóa phụ thuộc hoàn toàn vào các trường trong khóa chính.

Phân tích sâu hơn về vấn đề (yêu cầu) có khả năng mang lại một bảng phiên đối với những dấu hiệu nào được áp dụng. Mô hình hiện tại không có khả năng bao gồm một sinh viên lặp lại một khóa học. Điều này sẽ được đề cập trong một bài học sau.

Học sinh cũng có khả năng trở thành một bảng riêng vì có thể có nhiều học sinh có cùng tên. Điều này có thể sẽ được giải quyết bằng cách thêm khóa chính tổng hợp (số học sinh?).

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

Tôi đang chuẩn bị xóa cái này vì nó được coi là không chính xác

Tên chủ đề cũng là một thuộc tính không phải là số nguyên tố và nó phụ thuộc vào một phần của Mã chủ đề chính (quy tắc ngắt - không được có bất kỳ sự phụ thuộc một phần nào của bất kỳ cột nào vào khóa chính).

Điều này bị cấm trong Mẫu thông thường thứ 2 và do đó nên được đặt trong bảng riêng của nó như bạn đã nghi ngờ.

Tôi nghĩ rằng nơi bạn đến chưa được xác định là trong việc xác định hai bộ khóa ứng cử viên, khi bạn tạo bảng, bạn phải chọn một bộ khóa ứng viên để tạo khóa chính. Các cột còn lại trở thành thuộc tính không phải là số nguyên tố, nghĩa là, nếu bạn chọn khóa ứng viên thứ hai, Mã chủ đề trở thành thuộc tính không chính phụ thuộc vào một phần của khóa chính (Tên chủ đề) và nên được đặt trong bảng riêng của nó.

Điều quan trọng là dạy các hình thức bình thường thứ 1, 2 và 3 theo thứ tự khi chúng xây dựng trên nhau. BCNF về cơ bản cũng là một phần mở rộng cho dạng thứ 3 thông thường, vì vậy việc nắm bắt mạnh mẽ ở các cấp thấp hơn là điều cần thiết.

Thêm nữa; một nhà phát triển có kinh nghiệm sẽ không xem xét các mức độ chuẩn hóa độc lập vì nhiều quy tắc trở nên trực quan.

Họ cũng sẽ biết khi nào nên phá vỡ các quy tắc chuẩn hóa để giải quyết các vấn đề thiết kế và tối ưu hóa nhất định. Bình thường hóa nên được coi là một hướng dẫn để thiết kế tốt không phải là một quy tắc nghiêm ngặt, tôi tin rằng đó cũng sẽ là một điểm giảng dạy tốt.