Muốn hiểu 6NF với một ví dụ

Question

Tôi vừa đọc các đối số của @ PerformanceDBA lại: 6NF và E-A-V. Tôi tò mò. Trước đây tôi đã hoài nghi về 6NF vì nó đã được trình bày là "đơn thuần" gắn bó một số cột dấu thời gian trên các bảng.

Tôi đã luôn làm việc với từ điển dữ liệu và không cần phải thuyết phục để sử dụng một từ điển hoặc để tạo mã SQL. Vì vậy, tôi mong đợi một câu trả lời sẽ yêu cầu một từ điển (hoặc danh mục) được sử dụng để tạo mã.

Vì vậy, tôi muốn biết cách 6NF sẽ xử lý một ví dụ đơn giản cực kỳ. Một bảng các mục, mô tả và giá cả. Giá thay đổi theo thời gian.

Vì vậy, dù sao, bảng Mục trông giống như thế nào khi được chuyển đổi thành 6NF? "Sự bùng nổ của các bảng là gì?" điều đó xảy ra ở đây?

Nếu ví dụ không hoạt động với một bảng đơn giản này, vui lòng thêm những gì cần thiết để có được điểm trên.

Answer 1

Tóm lại, 6NF có nghĩa là mọi mối quan hệ bao gồm khóa ứng cử viên cộng với không quá một thuộc tính khác (khóa hoặc không khóa). Để mất ví dụ của bạn, nếu một "mặt hàng" được xác định bởi một ProductCode và các thuộc tính khác là mô tả và giá sau đó một schema 6NF sẽ bao gồm hai quan hệ (* biểu thị quan trọng trong mỗi):

ItemDesc {ProductCode*, Description} 
ItemPrice {ProductCode*, Price} 

này có khả năng là một cách tiếp cận rất linh hoạt bởi vì nó giảm thiểu sự phụ thuộc. Đó cũng là bất lợi chính của nó tuy nhiên, đặc biệt là trong một cơ sở dữ liệu SQL. SQL làm cho nó khó khăn hoặc không thể thực thi nhiều ràng buộc nhiều bảng. Sử dụng lược đồ trên, trong hầu hết các trường hợp, sẽ không thể thực thi quy tắc kinh doanh mà mỗi sản phẩm phải luôn có mô tả và giá. Tương tự như vậy, bạn có thể không thực thi được một số khóa phức hợp nên áp dụng (vì các thuộc tính của chúng có thể được chia thành nhiều bảng).

Vì vậy, khi xem xét 6NF, bạn phải cân nhắc các quy tắc phụ thuộc và tính toàn vẹn nào quan trọng đối với bạn. Trong nhiều trường hợp, bạn có thể thấy nó thực tế và hữu ích hơn khi gắn vào 5NF và bình thường hóa không hơn thế.

Answer 2

Tôi thực sự đã bắt đầu đặt câu trả lời cùng nhau, nhưng tôi gặp phải các biến chứng, bởi vì bạn (khá dễ hiểu) muốn có một ví dụ đơn giản. Vấn đề là đa tạp.

Trước tiên, tôi không có ý tưởng tốt về mức độ chuyên môn thực tế của bạn về Cơ sở dữ liệu quan hệ và 5NF; Tôi không có một điểm bắt đầu để mất và sau đó thảo luận về các chi tiết cụ thể của 6NF,

Thứ hai, giống như bất kỳ NFs nào khác, nó bị biến đổi. Bạn chỉ có thể bước vào nó; bạn có thể thực hiện 6NF cho các bảng certan; bạn có thể đi hết con heo trên mỗi bàn, vv Chắc chắn có một vụ nổ bàn, nhưng sau đó bạn Bình thường hóa nó, và giết chết vụ nổ; đó là một triển khai nâng cao hoặc trưởng thành của 6NF. Không sử dụng cung cấp toàn bộ hoặc một phần mức 6NF, khi bạn đang yêu cầu ví dụ đơn giản nhất, dễ hiểu nhất.

Tôi tin rằng bạn hiểu rằng một số bảng có thể là "trong 5NF" trong khi một số khác có "trong 6NF".

Vì vậy, tôi đặt một thứ lại với nhau cho bạn. Nhưng ngay cả điều đó cũng cần giải thích.

Bây giờ SQL hầu như không hỗ trợ 5NF, nó không hỗ trợ 6NF ở tất cả (tôi nghĩ rằng dportas nói cùng một điều trong các từ khác nhau). Bây giờ tôi thực hiện 6NF ở mức độ sâu, vì lý do hiệu suất, xoay vòng đơn giản (của toàn bộ bảng; bất kỳ và tất cả các cột, không phải hàm PIVOT ngớ ngẩn trong MS), truy cập cột, v.v.Đối với điều đó bạn cần một danh mục đầy đủ, là một phần mở rộng cho danh mục SQL, để hỗ trợ 6NF mà SQL không hỗ trợ, và duy trì tính toàn vẹn và quy tắc kinh doanh của dữ liệu. Vì vậy, bạn thực sự không muốn thực hiện 6NF cho vui, bạn chỉ làm điều đó nếu bạn có nhu cầu, bởi vì bạn phải thực hiện một danh mục. (Đây là những gì đám đông EAV không làm, và đây là lý do tại sao hầu hết các hệ EAV có vấn đề toàn vẹn dữ liệu. Hầu hết trong số họ không sử dụng declarative tham chiếu & Data Integrity rằng SQL không có.)

Nhưng hầu hết mọi người người thực hiện 6NF không thực hiện cấp độ sâu hơn, với một danh mục đầy đủ. Họ có nhu cầu đơn giản hơn, và do đó thực hiện một mức độ nông hơn 6NF. Vì vậy, hãy lấy điều đó, để cung cấp một ví dụ đơn giản cho bạn. Hãy bắt đầu với một bảng Product thông thường được khai báo là trong 5NF (và đừng tranh luận về 5NF ​​là gì). Công ty bán nhiều loại Sản phẩm khác nhau, một nửa cột là bắt buộc và nửa còn lại là tùy chọn, nghĩa là tùy thuộc vào Loại Sản phẩm, một số cột nhất định có thể là Null. Trong khi họ có thể đã làm tốt công việc với cơ sở dữ liệu, Nulls giờ là một vấn đề lớn: các cột không phải là Null đối với một số ProductTypes nhất định là Null, vì khai báo là NULL, và mã ứng dụng của chúng chỉ tốt như của người tiếp theo .

Vì vậy, họ quyết định đi với 6NF để khắc phục vấn đề đó, bởi vì phụ đề của 6NF quy định rằng nó loại bỏ Vấn đề Null. Mẫu thứ sáu bình thường là dạng bình thường không thể hủy diệt, sẽ không có thêm NF sau này, bởi vì dữ liệu không thể được chuẩn hóa thêm. Các hàng đã được chuẩn hóa ở mức tối đa. Định nghĩa của 6NF là:

một bảng nằm trong 6NF khi hàng chứa khóa chính và tối đa một thuộc tính.

Lưu ý rằng theo định nghĩa đó, hàng triệu bảng trên khắp hành tinh đã có trong 6NF, mà không có ý định đó. Ví dụ. các bảng tra cứu hoặc tra cứu điển hình, chỉ với PK và mô tả.

Phải. Vâng, bạn bè của chúng tôi nhìn vào bảng sản phẩm của họ, trong đó có tám thuộc tính không chính, vì vậy nếu họ làm cho bảng sản phẩm 6NF, họ sẽ có tám bảng sản phẩm phụ. Sau đó, có một số vấn đề là một số cột là Ngoại khóa cho các bảng khác, và dẫn đến nhiều biến chứng hơn. Và họ lưu ý thực tế là SQL không hỗ trợ những gì họ đang làm, và họ phải xây dựng một danh mục nhỏ. Tám bảng là chính xác, nhưng không hợp lý. Mục đích của họ là để loại bỏ Nulls, không phải để viết một subytem nhỏ xung quanh mỗi bảng.

Simple 6NF Example

Độc giả không quen với các tiêu chuẩn cho mô hình quan hệ cơ sở dữ liệu có thể tìm thấy IDEF1X Notation hữu ích để giải thích những biểu tượng trong ví dụ.

Vì vậy, thông thường, Bảng sản phẩm giữ lại tất cả các cột bắt buộc, đặc biệt là FK và mỗi cột Tùy chọn, mỗi cột Không thể bỏ qua, được đặt trong bảng phụ Sản phẩm riêng biệt. Đó là hình thức đơn giản nhất mà tôi đã thấy. Năm bảng thay vì tám. Trong Mô hình, bốn bảng phụ Sản phẩm là "trong 6NF"; bảng Sản phẩm chính là "trong 5NF". Bây giờ chúng tôi thực sự không cần tất cả các đoạn mã mà SELECTs từ Sản phẩm phải tìm ra những cột cần xây dựng, dựa trên ProductType, vv, vì vậy chúng tôi cung cấp một khung nhìn, về cơ bản cung cấp "view" 5NF của cụm bảng sản phẩm.Điều tiếp theo chúng ta cần là những nguyên tắc cơ bản của một phần mở rộng cho danh mục SQL, để chúng ta có thể đảm bảo rằng các quy tắc (toàn vẹn dữ liệu) cho các ProductTypes khác nhau được duy trì ở một nơi, trong cơ sở dữ liệu và không phụ thuộc trên mã ứng dụng. Danh mục đơn giản nhất mà bạn có thể nhận được. Điều đó được loại bỏ khỏi ProductType, vì vậy ProductType giờ đây là một phần của Siêu dữ liệu đó. Bạn có thể triển khai cấu trúc đơn giản đó mà không cần danh mục, nhưng tôi không khuyên bạn nên sử dụng nó.

Cập nhật

Điều quan trọng cần lưu ý rằng tôi thực hiện tất cả các quy tắc kinh doanh trong cơ sở dữ liệu. Nếu không, nó không phải là một cơ sở dữ liệu (khái niệm thực hiện các quy tắc "trong mã ứng dụng" là vui nhộn trong cực đoan, đặc biệt là ngày nay, khi chúng ta có người trồng hoa làm việc như "các nhà phát triển"). Vì vậy, tất cả các quy tắc, vv được thực hiện đầu tiên và quan trọng nhất như khai báo SQL, ràng buộc CHECK, chức năng, vv. Điều đó bảo toàn tất cả Tuyên bố tham chiếu Integrity, và Integative Data Integrity. Phần mở rộng của danh mục SQL bao gồm vùng SQL không có khai báo và sau đó chúng được triển khai dưới dạng SQL. Là một từ điển dữ liệu tốt, nó làm được nhiều hơn thế. Ví dụ. Tôi không viết lượt xem mỗi khi tôi thay đổi bảng hoặc thêm hoặc thay đổi cột hoặc đặc điểm của chúng, chúng được tạo trực tiếp từ danh mục + tiện ích mở rộng bằng trình tạo mã đơn giản.

Một lưu ý quan trọng khác. Bạn không thể thực hiện 6NF (hoặc EAV đúng, cho rằng vấn đề), mà không hoàn thành một bài tập chuẩn hóa đầy đủ và trung thành, đến 5NF. Vấn đề tôi thấy ở mọi trang web là, họ không có trạng thái 5NF chính hãng, họ có một sự hỗn loạn một phần hoặc không bình thường hóa, nhưng họ rất gắn bó với điều đó. Việc tạo ra 6NF hoặc EAV từ đó là một thảm họa. Tạo EAV hoặc 6NF từ đó mà không có tất cả các quy tắc nghiệp vụ được triển khai trong SQL khai báo là một thảm họa hạt nhân, cháy trong nhiều năm. Gieo nhân nào gặp quả nấy.

Cập nhật kết thúc. Cuối cùng, có, có ít nhất bốn cấp độ chuẩn hóa cao hơn (Bình thường hóa là Nguyên tắc, không chỉ là một Mẫu chuẩn), có thể được áp dụng cho cụm sản phẩm 6NF đơn giản đó, cung cấp nhiều điều khiển hơn, ít bảng hơn. , vv Chúng ta càng đi sâu, danh mục càng mở rộng. Và mức độ hiệu suất cao hơn. Khi bạn đã sẵn sàng, chỉ cần hỏi, tôi đã dựng lên các mô hình và đăng chi tiết trong các câu trả lời khác.

Answer 3

trước đây tôi đã từng hoài nghi về 6NF như nó đã được trình bày như là "chỉ đơn thuần là" gắn bó một số cột timestamp trên bảng.

Tôi không hoàn toàn chắc chắn rằng quan niệm sai lầm rõ ràng này đến từ đâu. Có lẽ thực tế là 6NF đã được giới thiệu cho cuốn sách "Dữ liệu thời gian và chế độ quan hệ" của Date, Darwen và Lorentzos? Nhưng dù sao, tôi hy vọng các câu trả lời khác ở đây đã làm rõ rằng 6NF không bị giới hạn trong cơ sở dữ liệu thời gian. Điểm tôi muốn làm là, mặc dù 6NF là "đáng kính" về mặt học thuật và luôn đạt được, nó có thể không nhất thiết dẫn đến thiết kế tối ưu trong mọi trường hợp (và không chỉ khi xem xét việc triển khai bằng SQL). Ngay cả những người khám phá và những người ủng hộ nói trên của 6NF dường như đồng ý, v.d.

Chris Date: "Đối với mục đích thực tế, hãy liên kết với 5NF (và 6NF)."

Hugh Darwen: "sự phân hủy 6NF xung quanh ngày [! Không phải là người] sẽ là quá mức cần thiết ... một thiết kế tối ưu cho các câu lạc bộ bóng đá là ... 5-and-một-bit-NF"

!

Hugh Darwen: "chúng ta đang ở 5NF nhưng không phải trong 6NF, và một lần nữa 5NF là đủ" (một số ví dụ tương tự)

Sau đó, một lần nữa, tôi cũng có thể tìm thấy bằng chứng ngược lại:.

Chris Date: "Darwen và Tôi có cả hai cảm thấy một thời gian mà tất cả các relvars cơ sở nên được trong 6NF ".

Trên một lưu ý thực tế, gần đây tôi đã mở rộng lược đồ SQL của một trong các sản phẩm của chúng tôi để thêm một tính năng phụ. Tôi đã sử dụng một 6NF để tránh các cột nullable và kết thúc với sáu bảng mới mà hầu hết (tất cả?) Của các đồng nghiệp của tôi đã sử dụng một bảng (hoặc có thể mở rộng một bảng hiện có) với các cột nullable. Mặc dù tôi đã chứng minh một số procs được lưu trữ 'helper' và một 'denormalized' VIEW với trình kích hoạt INSTEAD OF, mọi trình coder đã phải làm việc với tính năng này ở cấp SQL đã không còn cách nào để nguyền rủa tôi nữa :)

Answer 4

mọi người đã xuống: Anchor Modeling. Tài liệu học thuật tuyệt vời về chủ đề này, kết hợp với các ví dụ thực tế. Các tác phẩm của họ cuối cùng đã đẩy tôi vượt qua ranh giới để xem xét việc xây dựng một DW trong 6nf cho một dự án sắp tới. Các công việc POC tôi đã làm đã xác nhận (đối với tôi, ít nhất) rằng những lợi ích to lớn của 6nf không lớn hơn chi phí.