Sự khác biệt giữa 3NF và BCNF về mặt đơn giản (phải có thể giải thích cho một đứa trẻ 8 tuổi)

Tôi đã đọc báo giá: dữ liệu phụ thuộc vào khóa [1NF], toàn bộ khóa [2NF] và không có gì ngoài khóa [3NF] .

Tuy nhiên, tôi gặp khó khăn khi hiểu 3.5NF hoặc BCNF như cách gọi của nó. Đây là những gì tôi hiểu:

• BCNF chặt chẽ hơn 3NF
• bên trái của bất kỳ FD nào trong bảng phải là một siêu khóa (hoặc ít nhất là một khóa ứng cử viên)

Vậy tại sao sau đó, một số bảng 3NF không có trong BCNF? Ý tôi là, trích dẫn 3NF nói rõ ràng "không có gì ngoài khóa" có nghĩa là tất cả các thuộc tính chỉ phụ thuộc vào khóa chính. Cuối cùng, khóa chính là khóa ứng viên cho đến khi được chọn là khóa chính của chúng tôi.

Nếu có bất cứ điều gì không ổn liên quan đến sự hiểu biết của tôi cho đến nay, xin vui lòng sửa lỗi cho tôi và cảm ơn vì bất kỳ sự giúp đỡ nào bạn có thể cung cấp.

Pizza của bạn có thể có chính xác ba loại topping:

• một loại phô mai
• một loại thịt
• một loại rau

Vì vậy, chúng tôi đặt hàng hai loại pizza và chọn các loại toppings sau:

Pizza    Topping     Topping Type
-------- ----------  -------------
1        mozzarella  cheese
1        pepperoni   meat
1        olives      vegetable
2        mozzarella  meat
2        sausage     cheese
2        peppers     vegetable

Đợi một chút, mozzarella không thể vừa là phô mai vừa là thịt! Và xúc xích không phải là một pho mát!

Chúng ta cần ngăn chặn những sai lầm này, để làm cho mozzarella luôn là phô mai. Chúng ta nên sử dụng một bảng riêng cho việc này, vì vậy chúng tôi viết ra thực tế đó ở một nơi duy nhất.

Pizza    Topping
-------- ----------
1        mozzarella
1        pepperoni
1        olives
2        mozzarella 
2        sausage
2        peppers

Topping     Topping Type
----------  -------------
mozzarella  cheese
pepperoni   meat
olives      vegetable
sausage     meat
peppers     vegetable

Đó là lời giải thích mà một đứa trẻ 8 tuổi có thể hiểu. Đây là phiên bản kỹ thuật hơn.

BCNF hoạt động khác với 3NF chỉ khi có nhiều khóa ứng viên chồng chéo.

Lý do là sự phụ thuộc chức năng X -> Ytất nhiên là đúng nếu Ylà một tập hợp con của X. Vì vậy, trong bất kỳ bảng nào chỉ có một khóa ứng cử viên và nằm trong 3NF, nó đã có trong BCNF vì không có cột (khóa hoặc không khóa) phụ thuộc chức năng vào bất cứ thứ gì ngoài khóa đó.

Bởi vì mỗi chiếc bánh pizza phải có chính xác một trong số các loại topping, chúng tôi biết rằng (Pizza, Topping Type) là một khóa ứng cử viên. Chúng ta cũng biết một cách trực giác rằng một loại topping nhất định không thể thuộc về các loại khác nhau cùng một lúc. Vì vậy (Pizza, Topping) phải là duy nhất và do đó cũng là một khóa ứng cử viên. Vì vậy, chúng tôi có hai khóa ứng cử viên chồng chéo.

Tôi đã cho thấy một sự bất thường khi chúng tôi đánh dấu mozarella là loại topping sai. Chúng tôi biết điều này là sai, nhưng quy tắc làm cho nó sai là một phụ thuộc Topping -> Topping Typekhông phải là phụ thuộc hợp lệ cho BCNF cho bảng này. Đó là một sự phụ thuộc vào một cái gì đó khác hơn là toàn bộ khóa ứng cử viên.

Vì vậy, để giải quyết vấn đề này, chúng tôi đưa Topping Type ra khỏi bảng Pizzas và biến nó thành thuộc tính không khóa trong bảng Toppings.

Sự khác biệt tinh tế là 3NF phân biệt giữa các thuộc tính khóa và không khóa (còn được gọi là thuộc tính không chính ) trong khi BCNF thì không.

Điều này được giải thích tốt nhất bằng cách sử dụng định nghĩa của Zaniolo 3NF của , tương đương với Codd:

Một mối quan hệ, R, nằm trong 3NF iff cho mọi FD không cần thiết (X-> A) được R thỏa mãn ít nhất MỘT trong các điều kiện sau là đúng:

(a) X là một siêu khóa cho R, hoặc

(b) A là một thuộc tính quan trọng cho R

BCNF yêu cầu (a) nhưng không coi (b) là trường hợp đặc biệt của riêng mình. Nói cách khác, BCNF yêu cầu mọi yếu tố quyết định không cần thiết là một siêu khóa, ngay cả các thuộc tính phụ thuộc của nó cũng là một phần của khóa.

Một mối quan hệ, R, nằm trong BCNF iff cho mọi FD không cần thiết (X-> A) được thỏa mãn bởi R điều kiện sau là đúng:

(a) X là một siêu khóa cho R

BCNF do đó nghiêm ngặt hơn.

Sự khác biệt rất tinh vi đến nỗi những gì nhiều người mô tả không chính thức là 3NF thực sự là BCNF. Ví dụ: bạn đã nói ở đây rằng 3NF có nghĩa là "dữ liệu phụ thuộc vào khóa [s] ... và không có gì ngoài khóa [s]", nhưng đó thực sự là một mô tả không chính thức về BCNF chứ không phải 3NF. 3NF có thể được mô tả chính xác hơn là " dữ liệu không phải là khóa phụ thuộc vào các khóa ... và không có gì ngoài các khóa".

Bạn cũng đã nêu:

trích dẫn 3NF nói rõ ràng "không có gì ngoài khóa" có nghĩa là tất cả các thuộc tính chỉ phụ thuộc vào khóa chính.

Đó là một sự đơn giản hóa. 3NF và BCNF và tất cả các Biểu mẫu thông thường có liên quan đến tất cả các khóa ứng viên và / hoặc siêu khóa, không chỉ một khóa "chính".

Sự khác biệt giữa BCNF và 3NF

Sử dụng định nghĩa BCNF

Nếu và chỉ nếu với mỗi một trong các phụ thuộc của nó X → Y, thì ít nhất một trong các điều kiện sau giữ :

• X → Y là một phụ thuộc chức năng tầm thường (Y ⊆ X), hoặc
• X là một siêu khóa cho lược đồ R

và định nghĩa 3NF

Nếu và chỉ khi, đối với mỗi phụ thuộc chức năng của nó X → A, ít nhất một trong các điều kiện sau đây được giữ:

• X chứa A (nghĩa là X → A là phụ thuộc chức năng tầm thường), hoặc
• X là một siêu khóa, hoặc
• Mỗi phần tử của AX, sự khác biệt được đặt giữa A và X, là một thuộc tính nguyên tố (nghĩa là, mỗi thuộc tính trong AX được chứa trong một số khóa ứng cử viên)

Chúng tôi thấy sự khác biệt sau đây, trong điều kiện đơn giản:

• Trong BCNF : Mọi khóa một phần (thuộc tính nguyên tố) chỉ có thể phụ thuộc vào một siêu khóa,

trong khi

• Trong 3NF : Khóa một phần (thuộc tính nguyên tố) cũng có thể phụ thuộc vào một thuộc tính không phải là siêu khóa (tức là một thuộc tính khóa / nguyên tố một phần khác hoặc thậm chí là thuộc tính không phải là số nguyên tố).

Ở đâu

1. Một thuộc tính quan trọng là một thuộc tính được tìm thấy trong một chìa khóa ứng cử viên, và
2. Một khóa ứng viên là một superkey tối thiểu cho mối quan hệ đó, và
3. Một superkey là một tập hợp các thuộc tính của một biến mối quan hệ mà nó cho rằng trong tất cả các mối quan hệ giao cho biến đó, không có hai bộ dữ liệu khác nhau (hàng) có cùng giá trị cho các thuộc tính trong này set.Equivalently một superkey cũng có thể được định nghĩa là một tập hợp các thuộc tính của lược đồ quan hệ mà trên đó tất cả các thuộc tính của lược đồ phụ thuộc chức năng. (Một siêu khóa luôn chứa khóa ứng viên / khóa ứng viên luôn là tập con của siêu khóa. Bạn có thể thêm bất kỳ thuộc tính nào trong mối quan hệ để có được một trong các siêu khóa.)

Nghĩa là, không có tập hợp con một phần (bất kỳ tập hợp con không tầm thường nào ngoại trừ bộ đầy đủ) của khóa ứng viên có thể phụ thuộc chức năng vào bất cứ thứ gì ngoài siêu khóa.

Một bảng / quan hệ không có trong BCNF có thể bị dị thường, chẳng hạn như các bất thường cập nhật được đề cập trong ví dụ về pizza bởi một người dùng khác. Không may,

• BNCF không thể luôn luôn có được , trong khi
• 3NF luôn có thể thu được .

Ví dụ 3NF Versus BCNF

Một ví dụ về sự khác biệt hiện có thể được tìm thấy tại " bảng 3NF không đáp ứng BCNF (dạng thông thường BoyceTHER Codd) " trên Wikipedia, trong đó bảng sau gặp 3NF nhưng không phải BCNF vì "Sân tennis" (thuộc tính một phần khóa / chính) trên "Loại tỷ lệ" (thuộc tính khóa / nguyên tố một phần không phải là siêu khóa), đây là một phụ thuộc mà chúng ta có thể xác định bằng cách hỏi các khách hàng của cơ sở dữ liệu, câu lạc bộ tennis:

Đặt chỗ sân tennis ngày nay ( 3NF, không phải BCNF )

Court   Start Time  End Time    Rate Type
------- ----------  --------    ---------
1       09:30       10:30       SAVER
1       11:00       12:00       SAVER
1       14:00       15:30       STANDARD
2       10:00       11:30       PREMIUM-B
2       11:30       13:30       PREMIUM-B
2       15:00       16:30       PREMIUM-A

Các siêu khóa của bảng là:

S1 = {Court, Start Time}
S2 = {Court, End Time}
S3 = {Rate Type, Start Time}
S4 = {Rate Type, End Time}
S5 = {Court, Start Time, End Time}
S6 = {Rate Type, Start Time, End Time}
S7 = {Court, Rate Type, Start Time}
S8 = {Court, Rate Type, End Time}
ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey

Vấn đề 3NF : Thuộc tính khóa / thuộc tính một phần "Tòa án" phụ thuộc vào thứ gì đó không phải là siêu khóa. Thay vào đó, nó phụ thuộc vào thuộc tính khóa / thuộc tính một phần "Loại tỷ lệ". Điều này có nghĩa là người dùng phải thay đổi thủ công loại tỷ lệ nếu chúng tôi nâng cấp tòa án hoặc thay đổi thủ công tòa án nếu muốn áp dụng thay đổi tỷ lệ.

• Nhưng nếu người dùng nâng cấp tòa án nhưng không nhớ tăng tỷ lệ thì sao? Hoặc nếu loại tỷ lệ sai được áp dụng cho một tòa án?

(Về mặt kỹ thuật, chúng tôi không thể đảm bảo rằng phụ thuộc chức năng "Loại tỷ lệ" -> "Tòa án" sẽ không bị vi phạm.)

Giải pháp BCNF : Nếu chúng tôi muốn đặt bảng trên vào BCNF, chúng tôi có thể phân tách mối quan hệ / bảng đã cho thành hai quan hệ / bảng sau (giả sử chúng tôi biết rằng loại tỷ lệ chỉ phụ thuộc vào trạng thái thành viên và tòa án, mà chúng tôi có thể khám phá bằng cách hỏi các khách hàng của cơ sở dữ liệu của chúng tôi, chủ sở hữu của câu lạc bộ quần vợt):

Các loại tỷ lệ ( BCNF và 3NF yếu hơn, được ngụ ý bởi BCNF)

Rate Type   Court   Member Flag
---------   -----   -----------
SAVER       1       Yes
STANDARD    1       No
PREMIUM-A   2       Yes
PREMIUM-B   2       No

Đặt chỗ sân tennis ngày nay ( BCNF và 3NF yếu hơn, được ngụ ý bởi BCNF)

Member Flag     Court     Start Time   End Time
-----------     -----     ----------   --------
Yes             1         09:30        10:30
Yes             1         11:00        12:00
No              1         14:00        15:30
No              2         10:00        11:30
No              2         11:30        13:30
Yes             2         15:00        16:30

Giải quyết vấn đề : Bây giờ nếu chúng tôi nâng cấp tòa án, chúng tôi có thể đảm bảo loại tỷ lệ sẽ phản ánh sự thay đổi này và chúng tôi không thể tính giá sai cho một tòa án.

(Về mặt kỹ thuật, chúng tôi có thể đảm bảo rằng phụ thuộc chức năng "Loại tỷ lệ" -> "Tòa án" sẽ không bị vi phạm.)

Tất cả các câu trả lời tốt. Để đặt nó trong ngôn ngữ đơn giản [BCNF] Không một khóa nào có thể phụ thuộc vào một khóa.

tức là Không có tập hợp con một phần (tức là bất kỳ tập hợp con không tầm thường nào ngoại trừ tập hợp đầy đủ) của khóa ứng viên có thể phụ thuộc chức năng vào một số khóa ứng viên.

Câu trả lời của ' smartnut007 ', ' Bill Karwin ' và ' sqlvogel ' là tuyệt vời. Tuy nhiên, hãy để tôi đặt một quan điểm thú vị cho nó.

Vâng, chúng tôi có các khóa chính và không chính.

Khi chúng ta tập trung vào cách các số nguyên tố phụ thuộc vào các số nguyên tố, chúng ta thấy hai trường hợp:

Không phải số nguyên tố có thể phụ thuộc hoặc không .

• Khi phụ thuộc: chúng tôi thấy họ phải phụ thuộc vào khóa ứng viên đầy đủ. Đây là 2NF .

• Khi không phụ thuộc: có thể không phụ thuộc hoặc phụ thuộc bắc cầu

  • Thậm chí không phụ thuộc quá độ: Không chắc lý thuyết chuẩn hóa nào giải quyết vấn đề này.
  • Khi quá phụ thuộc quá mức: Nó được coi là không mong muốn. Đây là 3NF .

Điều gì về sự phụ thuộc giữa các số nguyên tố?

Bây giờ bạn thấy, chúng tôi không giải quyết mối quan hệ phụ thuộc giữa các số nguyên tố bởi NF thứ 2 hoặc thứ 3. Hơn nữa, sự phụ thuộc như vậy, nếu có, là không mong muốn và do đó chúng tôi có một quy tắc duy nhất để giải quyết điều đó. Đây là BCNF .

Tham khảo ví dụ từ bài đăng của Bill Karwin tại đây, bạn sẽ nhận thấy rằng cả ' Topping ' và ' Topping Type ' đều là các khóa chính và có sự phụ thuộc. Nếu họ không phải là số nguyên tố phụ thuộc, thì 3NF sẽ khởi động.

Ghi chú:

Định nghĩa của BCNF rất chung chung và không có sự khác biệt giữa các thuộc tính giữa nguyên tố và không nguyên tố. Tuy nhiên, cách suy nghĩ trên giúp hiểu được một số dị thường bị xâm phạm như thế nào ngay cả sau lần thứ 2 và thứ 3.

Chủ đề nâng cao: Ánh xạ BCNF chung thành 2NF & 3NF

Bây giờ chúng ta đã biết BCNF cung cấp một định nghĩa chung mà không cần tham khảo bất kỳ thông tin chính / không chính nào, hãy xem BCNF và 2/3 NF có liên quan như thế nào.

Đầu tiên, BCNF yêu cầu (trừ trường hợp tầm thường) rằng đối với từng phụ thuộc chức năng X -> Y (FD), X phải là siêu khóa. Nếu bạn chỉ xem xét bất kỳ FD nào, thì chúng tôi có ba trường hợp - (1) Cả X và Y không phải là số nguyên tố, (2) Cả hai số nguyên tố và (3) X nguyên tố và Y không phải là số nguyên tố, loại bỏ trường hợp (vô nghĩa) X không -prime và Y nguyên tố.

Đối với trường hợp (1), 3NF sẽ xử lý.

Đối với trường hợp (3), 2NF sẽ xử lý.

Đối với trường hợp (2), chúng tôi thấy việc sử dụng BCNF

Đây là một câu hỏi cũ với các câu trả lời có giá trị, nhưng tôi vẫn hơi bối rối cho đến khi tôi tìm thấy một ví dụ thực tế cho thấy vấn đề với 3NF. Có thể không phù hợp với một đứa trẻ 8 tuổi nhưng hy vọng nó sẽ giúp.

Ngày mai tôi sẽ gặp các giáo viên của con gái lớn của tôi trong một trong những cuộc họp phụ huynh / giáo viên hàng quý. Đây là nhật ký của tôi trông như thế nào (tên và phòng đã được thay đổi):

Teacher   | Date             | Room
----------|------------------|-----
Mr Smith  | 2018-12-18 18:15 | A12 
Mr Jones  | 2018-12-18 18:30 | B10 
Ms Doe    | 2018-12-18 18:45 | C21 
Ms Rogers | 2018-12-18 19:00 | A08 

Chỉ có một giáo viên mỗi phòng và họ không bao giờ di chuyển. Nếu bạn có một cái nhìn, bạn sẽ thấy rằng: (1) cho mỗi thuộc tính Teacher, Date, Room, chúng tôi chỉ có một giá trị cho mỗi hàng. (2) siêu khóa là : (Teacher, Date, Room), (Teacher, Date)và (Date, Room)khóa ứng viên rõ ràng là (Teacher, Date)và (Date, Room).

_{(Teacher, Room) không phải là một siêu khóa vì tôi sẽ hoàn thành bảng vào quý tới và tôi có thể có một hàng như thế này (Mr Smith đã không di chuyển!):}

Teacher  | Date             | Room
---------|------------------| ----
Mr Smith | 2019-03-19 18:15 | A12

Chúng ta có thể kết luận điều gì? (1) là một công thức không chính thức nhưng chính xác của 1NF. Từ (2) chúng ta thấy rằng không có "thuộc tính không nguyên tố": 2NF và 3NF được cung cấp miễn phí.

Nhật ký của tôi là 3NF. Tốt Không. Không thực sự bởi vì không có người lập mô hình dữ liệu nào chấp nhận điều này trong lược đồ DB. Các Roomthuộc tính phụ thuộc vào Teacherthuộc tính (một lần nữa: giáo viên không di chuyển!) Nhưng schema không phản ánh thực tế này. Một người lập mô hình dữ liệu lành mạnh sẽ làm gì? Chia bảng làm hai:

Teacher   | Date
----------|-----------------
Mr Smith  | 2018-12-18 18:15
Mr Jones  | 2018-12-18 18:30
Ms Doe    | 2018-12-18 18:45
Ms Rogers | 2018-12-18 19:00

Và

Teacher   | Room
----------|-----
Mr Smith  | A12
Mr Jones  | B10
Ms Doe    | C21
Ms Rogers | A08

Nhưng 3NF không xử lý các phụ thuộc thuộc tính nguyên tố. Đây là vấn đề: tuân thủ 3NF là không đủ để đảm bảo thiết kế lược đồ bảng âm thanh trong một số trường hợp.

Với BCNF, bạn không quan tâm liệu thuộc tính đó có phải là thuộc tính nguyên tố hay không theo quy tắc 2NF và 3NF. Đối với mọi phụ thuộc không tầm thường (các tập con rõ ràng được xác định bởi các supersets của chúng), định thức là một siêu khóa hoàn chỉnh. Nói cách khác, không có gì được xác định bởi một thứ khác ngoài một siêu khóa hoàn chỉnh (không bao gồm các FD tầm thường). (Xem câu trả lời khác cho định nghĩa chính thức).

Ngay khi Roomphụ thuộc vào Teacher, Roomphải là một tập hợp con Teacher(không phải là trường hợp) hoặc Teacherphải là một siêu khóa (đó không phải là trường hợp trong nhật ký của tôi, nhưng đó là trường hợp khi bạn chia bảng).

Tóm lại: BNCF nghiêm ngặt hơn, nhưng theo tôi thì dễ nắm bắt hơn 3NF:

• trong hầu hết các trường hợp, BCNF giống hệt 3NF;
• trong các trường hợp khác, BCNF là những gì bạn nghĩ / hy vọng 3NF là.