Nếu một bảng có khóa thay thế có một cột được biết là có các giá trị không null duy nhất (ví dụ SSN), thì nó có vi phạm 3NF không?

Theo tôi hiểu, về cơ bản , hình thức bình thường thứ ba (3NF) có nghĩa là phải có chính xác một khóa.

Nếu một bảng có idcột tăng tự động cũng có một cột được biết là duy nhất và không phải là null, ví dụ số an sinh xã hội, thì cột khác này có thể được sử dụng làm khóa.

Bỏ qua các vấn đề thực tế / kinh doanh (ví dụ rủi ro về sinh thái / quyền riêng tư khi chuyển qua SSN làm khóa / FK), từ khía cạnh thiết kế lược đồ nghiêm ngặt, liệu một bảng như vậy có nằm trong 3NF không vì có 2 khóa hiệu quả?

Câu trả lời có khác nhau về việc liệu có một khóa duy nhất trên cột kia không? Nếu vậy, tại sao?

Một mối quan hệ R ở dạng bình thường thứ ba nếu mọi thuộc tính không chính của R không phụ thuộc quá mức vào từng khóa ứng cử viên của R

EFCodd, 1971, Chuẩn hóa thêm mô hình quan hệ cơ sở dữ liệu

Nó được ngầm định trong định nghĩa về một mối quan hệ mà một mối quan hệ phải có ít nhất một khóa. Gì về 3NF hoặc bất kỳ mẫu bình thường khác đòi hỏi một mối quan hệ nên có chỉ một chìa khóa.

Thật không may, các cuốn sách về thiết kế và chuẩn hóa cơ sở dữ liệu có các ví dụ phong phú về các mối quan hệ chỉ với một khóa duy nhất và thay vào đó là ít ví dụ có nhiều hơn một khóa. Điều này gây cho tôi sự kỳ quặc khi có nhiều khóa dường như là thông lệ rất phổ biến hiện nay. Sự thiếu sót của các ví dụ thực tế trong văn học phi học thuật dường như là một nguyên nhân gây nhầm lẫn về vai trò của các khóa trong thiết kế cơ sở dữ liệu. Một nguyên nhân khác của sự nhầm lẫn là việc ghi nhớ phổ biến "không có gì ngoài chìa khóa". Cụm từ đó thường được gán cho Bill Kent nhưng nó không phải là định nghĩa chính xác về 3NF.

Vì câu hỏi dựa trên việc giải thích quy tắc, trước tiên chúng ta nên xem thông tin được liên kết đó là (nhấn mạnh của tôi):

2. tất cả các thuộc tính trong một bảng chỉ được xác định bởi các khóa ứng cử viên của bảng đó chứ không phải bởi bất kỳ thuộc tính không chính nào.

Tôi nghĩ rằng sự nhầm lẫn là kết quả của việc giải thích sai thuật ngữ "khóa ứng viên". Có thể có nhiều khóa ứng cử viên trong một bảng. Đây là lý do tại sao chúng tôi có các thuật ngữ sửa đổi để xác định rõ hơn trong nhóm này: Chính và Thay thế. Nếu các bảng có thể có một và chỉ một khóa, thì thuật ngữ Khóa "Chính" sẽ gây hiểu nhầm và thay vào đó nên được gọi là một cái gì đó khác (có thể là "Phụ huynh" hoặc "Nguồn gốc" hoặc "Nhận dạng", v.v.). Nhưng "Chính" ngụ ý rằng có thể có các phím "phụ" và các phím đó được gọi là các phím "Thay thế".

Các khóa thay thế được chỉ định trong các mô hình vật lý thông qua Chỉ số duy nhất hoặc Chỉ mục duy nhất. Cũng cần phải lưu ý rằng cả hai loại Candidate Keys (Tiểu học và thay thế), có thể được tham chiếu bởi Keys nước ngoài (mặc dù một thường sẽ không / không nên làm một điều như vậy mà không có một rất lý do chính đáng!).

Câu trả lời có khác nhau về việc liệu có một khóa duy nhất trên cột kia không? Nếu vậy, tại sao?

Không, bởi vì đó là vấn đề của mô hình vật lý và logic. Bạn có thể có một bảng có một IDENTITYtrường nhưng chưa xác định Khóa chính. Bảng và dữ liệu của nó có thể dễ dàng ở 3NF, ngay cả khi mô hình vật lý không thực thi điều đó. Sự khác biệt này tương tự như việc có hay không Khóa ngoại được xác định. Bạn chắc chắn có thể THAM GIA các bảng và không có hồ sơ mồ côi, cho dù có bất kỳ PK / FK nào được xác định hay không. Và dữ liệu có thể chính xác 100% mà không cần các cấu trúc đó. Nhưng việc xác định PK và FK là sự khác biệt giữa Tính toàn vẹn tham chiếu (logic) và Tính toàn vẹn tham chiếu khai báo (vật lý). Có các ràng buộc trong mô hình vật lý đơn giản là giúp thực thi các quy tắc của mô hình logic.

Liên quan đến SSN (" Số an sinh xã hội " cho những người không quen thuộc với từ viết tắt đó) và nó là Khóa thay thế và có Chỉ số / ràng buộc duy nhất về nó:

Tôi muốn giới thiệu với xem xét một SSN là một chính thay thế và đặt một hạn chế duy nhất hoặc Index vào nó, ngay cả khi người ta thường làm như vậy (SSN thường được coi là một "thiên nhiên" Key - một trong những tồn tại trong thế giới thực) . Có hai lý do chính:

1. Độ chính xác: Hầu hết thời gian, các giá trị này được đưa vào hệ thống bằng cách ai đó điền vào biểu mẫu, cho dù trên giấy hoặc trực tuyến. Mọi người thường mắc lỗi trong khi nhập dữ liệu mọi lúc, đặc biệt nếu nguồn là dạng giấy được nhập bởi ai đó đang đọc chữ viết tay cẩu thả của người khác (chẳng hạn như của tôi, hầu như không đọc được).

   Ngay cả khi dữ liệu đến từ một hệ thống khác, bạn có thể chắc chắn rằng hệ thống nguồn đã xác thực thông tin không? Bạn có thể chắc chắn rằng không có lỗi trong xuất dữ liệu của họ? Điều gì nếu có một lỗi trong nhập dữ liệu của bạn?

2. Tính duy nhất: Ngay cả khi Cơ quan An sinh Xã hội chính chưa bao giờ cấp ID trùng lặp, điều đó không có nghĩa là sự trùng lặp đã không xảy ra. Ngoài vấn đề trộm cắp danh tính, tôi nhớ đã nghe từ một người nào đó làm DBA cho Bộ Doanh thu tiểu bang (tôi tin) và người phải giải quyết các lợi ích An sinh Xã hội, cách họ gặp "vấn đề" đối phó với những gì thực hành cũ hơn là chỉ định lại SSN của người đã chết cho người phối ngẫu còn sống (thường là góa phụ) để người phối ngẫu còn sống dễ dàng tiếp tục thu các khoản thanh toán lợi ích. Tôi chắc chắn rằng hoạt động này đã chấm dứt cách đây một thời gian, nhưng dữ liệu "trùng lặp" vẫn còn trong hệ thống.

Theo tôi hiểu, về cơ bản, hình thức bình thường thứ ba (3NF) có nghĩa là phải có chính xác một khóa.

Số 2NF, 3NF và Boyce Codd Form Form (BCNF) xử lý các phụ thuộc chức năng . Bảng trong 2NF có nghĩa là không có phụ thuộc khóa một phần trong đó cột không khóa phụ thuộc vào một số tập hợp con chính xác của khóa nhiều cột. Các bảng như bảng trong ví dụ của chúng tôi đã có trong 2NF vì mỗi khóa ứng cử viên là một cột duy nhất. Một bảng trong 3NF có nghĩa là mọi cột không khóa cũng không phụ thuộc chức năng vào một số cột không khóa khác và do đó tạo ra một phụ thuộc bắc cầu. Không có vấn đề gì nếu có một hoặc một trăm khóa ứng cử viên. Trên thực tế, đó là BCNF, không phải 3NF, đây là hình thức bình thường "cuối cùng" liên quan đến các phụ thuộc chức năng. Điều này là do một bảng có thể ở 3NF nhưng không có trong BCNF vì có thể có nhiều khóa ứng viên trùng nhau. Do đó, khi chúng tôi sử dụng thuật ngữ 3NF có nghĩa là "hoàn toàn bình thường hóa" đối với các phụ thuộc chức năng, điều chúng tôi thực sự muốn nói là BCNF.

Nếu một bảng có cột id tự động tăng cũng có một cột được biết là duy nhất và không null, ví dụ số an sinh xã hội, thì cột khác này có thể được sử dụng làm khóa.

Không chỉ có thể, nó phải là nếu chúng ta muốn đảm bảo dữ liệu được lưu trữ trong cơ sở dữ liệu vẫn phù hợp với các quy tắc chúng ta đã xác định trong thế giới thực!

Bỏ qua các vấn đề thực tế / kinh doanh (ví dụ rủi ro về sinh thái / quyền riêng tư khi chuyển qua SSN làm khóa / FK), từ khía cạnh thiết kế lược đồ nghiêm ngặt, liệu một bảng như vậy có nằm trong 3NF không vì có 2 khóa hiệu quả?

Như đã giải thích ở trên, bảng có trong 3NF hay không (hay quan trọng hơn là BCNF) là trực giao với số lượng khóa ứng viên mà nó chứa.

Câu trả lời có khác nhau về việc liệu có một khóa duy nhất trên cột kia không? Nếu vậy, tại sao?

Không, đơn giản là vì việc xác định bảng có hay không trong 3NF không liên quan gì đến việc có bao nhiêu khóa ứng cử viên. Thay vào đó, mọi thứ phải làm với việc đảm bảo tất cả các cột không khóa phụ thuộc hoàn toàn vào chức năng của các khóa ứng cử viên đó.

Nhưng điều này không mang đến một điểm thú vị. Lưu ý rằng một khóa duy nhất khi được định nghĩa là một ràng buộc trong DBMS không giống như một mã định danh duy nhất được xác định là quy tắc kinh doanh trong mô hình kinh doanh khái niệm. Có lẽ trong thế giới của chúng ta, chúng ta luôn biết SSN của người đó và do đó, nó đóng vai trò là khóa ứng cử viên cho một người và có lẽ chúng ta cũng giới thiệu khóa thay thế trong lược đồ logic mà chúng ta gọi là Id người . Mô hình kinh doanh của chúng tôi bao gồm quy tắc nêu rõ SSN là định danh duy nhất cho một người trong thế giới của chúng tôi. Điều này ngụ ý một sự phụ thuộc chức năngcủa tất cả các thuộc tính mô tả về thuộc tính nhận dạng này. Quy tắc này không thay đổi chỉ vì chúng tôi quên hoặc chọn không thông báo cho DBMS. Đây chính xác là lý do tại sao điều quan trọng là khai báo ràng buộc - để DBMS có thể đảm bảo dữ liệu được lưu trữ phù hợp với các quy tắc của mô hình kinh doanh! Nếu chúng ta không tạo ra ràng buộc duy nhất đó đối với SSN, thì bây giờ chúng ta có thể vô tình tạo nhiều hơn một hàng cho cùng một người có cùng SSN; mỗi hàng có Id người khác nhau!

Một mồi tuyệt vời về các chủ đề này là Chuỗi cơ sở dữ liệu thực tế của Fabian Pascal và Lý thuyết quan hệ và thiết kế cơ sở dữ liệu của Chris Date , từ đó câu trả lời này được rút ra. Mặc dù mỗi bài viết của Fabian là phải đọc, bài số 1 (trong đó xác định rõ sự khác biệt giữa các mức độ khái niệm, logic và vật lý) và bài số 4 (trong đó xác định rõ các loại khóa khác nhau) giải quyết cụ thể câu hỏi này. Tương tự như vậy, toàn bộ cuốn sách của Chris là phải đọc trong khi Phần II là phần dành cho bình thường hóa đối với sự phụ thuộc chức năng.