Chuẩn hóa: Có được coi là tuân thủ để phân chia các giá trị tĩnh, số như một năm vào bảng riêng của chúng không?

Tôi đang có một cuộc thảo luận thú vị với một nhà thiết kế cơ sở dữ liệu khác về chuẩn hóa. Trong ví dụ này, chúng tôi có bảng GameTitle và mỗi bản ghi phải chứa năm mà trò chơi được phát hành. Ông nói rằng 2NF yêu cầu mọi thứ phải được chuẩn hóa, do đó, để tuân thủ, trường năm nên được tách thành bảng ReleaseYears với khóa chính được tham chiếu bởi bảng GameTitle. Tôi nói nó nên duy trì như một trường trên bảng GameTitle.

Lập luận của tôi cho điều này là một năm chỉ là một giá trị số không nguyên thủy, tĩnh bởi chính bản chất của nó (tức là năm 2011 sẽ luôn là năm 2011). Do đó, nó đóng vai trò là định danh riêng của nó và không cần gì để tham chiếu vì nó là chính nó. Điều này cũng giới thiệu bảo trì bổ sung vì bây giờ bạn phải thêm một năm mới vào bảng chỉ để tham khảo nó. Nếu bạn chuẩn bị trước bảng với một phạm vi lớn trong nhiều năm thì bạn có thêm các bản ghi có khả năng sẽ không có tài liệu tham khảo nào cả. Điều này cũng làm tăng kích thước cơ sở dữ liệu vì bây giờ bạn có thêm bảng, chi phí ghi lại và khóa chính bổ sung cho chính năm đó. Nếu bạn giữ năm như một trường trên bảng GameTitle, bạn sẽ loại bỏ tất cả chi phí bảo trì và chi phí bổ sung này.

Suy nghĩ về điều này?

chỉnh sửa: Mete để đăng bài này trên StackOverflow. Ai đó có thể bỏ phiếu để xóa cái này hoặc đánh dấu nó cho sự chú ý?

Các nhà thiết kế cơ sở dữ liệu khác chỉ đơn giản là sai, nhưng lý luận của bạn cũng sai. Giả sử bạn bắt đầu với bảng này, có một khóa ứng viên duy nhất, "game_title".

Table: game_titles

game_title                      year_first_released
--
The first game                  1998
The second game                 1999
Best game: the third one        2001
The fourth game                 2003
Forty-two, the end of games     2011

Bạn đánh giá xem nó có trong 2NF hay không bằng cách tự hỏi mình những câu hỏi này.

Q: Trước hết, nó có trong 1NF không?

A: Vâng, đúng vậy.

Q: các thuộc tính nguyên tố (thuộc tính là một phần của khóa ứng cử viên) là gì?

A: "game_title" là thuộc tính nguyên tố duy nhất.

Q: các thuộc tính không chính là gì?

A: "year_first_release" là người duy nhất.

Q: "year_first_release" có chức năng phụ thuộc vào toàn bộ "game_title" hay chỉ là một phần của nó?

A: Khóa ứng viên duy nhất, "game_title", là một cột duy nhất; nó thậm chí không có bộ phận. Vì vậy, "year_first_release" phụ thuộc về mặt chức năng vào toàn bộ "game_title".

Võngà. Bạn đã tìm thấy 2NF.

Bạn có thể bỏ qua một số điều khoản chính thức bằng cách hỏi trước xem nó có trong 1NF không, sau đó trả lời câu hỏi này.

Q: Có bất kỳ khóa ứng cử viên tổng hợp?

A: Không.

Võngà. Bạn đã tìm thấy 2NF một lần nữa.

Theo định nghĩa, để một bảng vi phạm 2NF, nó phải có ít nhất một khóa ứng cử viên có nhiều hơn một cột.

Đây là lý do của bạn để từ chối ý kiến ​​của bạn bè của bạn.

• Một năm chỉ là một giá trị số không nguyên thủy.
• Một năm là tĩnh bởi chính bản chất của nó.
• Một năm phục vụ như định danh riêng của mình.
• Một bảng năm giới thiệu bảo trì bổ sung.
• Một bảng năm có thể có thêm các hàng không được tham chiếu.
• Một bảng năm làm tăng kích thước cơ sở dữ liệu.

Không có lý do nào trong số những lý do này có liên quan đến việc một bảng có trong 2NF hay không.

Khi thiết kế cơ sở dữ liệu, không sai khi xem xét các vấn đề bảo trì, kích thước cơ sở dữ liệu, các hàng không được ước tính, các ràng buộc phạm vi, v.v. Thật sai lầm khi gọi những điều đó là bình thường hóa.

Ồ, và bảng hai cột mà tôi đã cung cấp ở trên - đó là trong 5NF.

Tạo một bảng riêng cho bất kỳ thuộc tính nào không liên quan đến chuẩn hóa. 2NF, 3NF, BCNF, 4NF, 5NF đều liên quan đến việc loại bỏ các phụ thuộc không chính. Nếu bạn loại bỏ bất kỳ thuộc tính đơn lẻ nào sang một bảng mới và thay thế nó bằng một thuộc tính khóa ngoại thì các phụ thuộc trong bảng sẽ giống như trước đây - vì vậy phiên bản sửa đổi của bảng không nhiều hơn hoặc ít hơn bình thường hóa là trước đây.

Theo quan điểm của tôi, một bảng năm riêng biệt sẽ chỉ có ý nghĩa nếu "năm phát hành" không phải là một năm dương lịch, mà là một năm tài chính có thể kéo dài nhiều năm theo lịch (ví dụ: từ tháng mười đến tháng mười).

Bảng đó sau đó sẽ giữ định nghĩa (ngày bắt đầu và ngày kết thúc thực sự) của năm tài chính

Từ http://en.wikipedia.org/wiki/Second_n normal_form :

bảng 1NF nằm trong 2NF khi và chỉ khi, với bất kỳ khóa ứng viên K và bất kỳ thuộc tính A nào không phải là thành phần của khóa ứng viên, A phụ thuộc vào toàn bộ K thay vì chỉ là một phần của nó.

Bạn đã không cho biết năm đó có phải là một phần của khóa ứng viên hay không, nhưng tôi không chắc nó có vấn đề gì không, bởi vì trong cả hai trường hợp, 2NF sẽ được thỏa mãn khi có liên quan đến năm đó.

Ở mức độ thực tế, việc tách năm vì tất cả các lý do bạn liệt kê là một ý tưởng tồi.

Tôi không thích đối số với bảng riêng biệt vì kích thước của nó hoặc nó sẽ có các hàng không được sử dụng. Ngay cả khi bạn đặt 1000 năm vào bảng này, kích thước sẽ không đáng kể.

Điều đó nói rằng, tôi không nghĩ rằng bảng là cần thiết ở tất cả. Điểm có một bảng riêng trong năm là gì? Dữ liệu này đã có trong bảng chính và bạn hoàn toàn không lưu gì bằng cách tạo bảng thứ hai.

Đối số có thể khác nhau đối với bảng lịch, trong đó mỗi hàng đại diện cho một ngày và có thể có các thuộc tính khác (ngày trong tuần, bù UTC, cho dù đó là ngày lễ, v.v.).

Nhưng năm nào thôi? Không, tôi không thấy bất kỳ lợi ích nào cả ... Và như những người khác đã chỉ ra, hãy hỏi họ tại sao họ nghĩ rằng điều đó bình thường hơn? Hay những gì họ đạt được? Nếu bạn đang cố gắng viết các truy vấn như

WHERE othertable.year = 2011

Thay vì

WHERE dt >= 20110101 AND dt < 20120101

Sau đó, tôi sẽ cố gắng thuyết phục bạn rằng cái sau tốt hơn cho hiệu suất (giả sử dt được lập chỉ mục) và lưu trữ. Nếu sự đơn giản mã hóa là tối quan trọng thì tôi sẽ nói một cột được tính toán bền vững sẽ tốt hơn một bảng khác.

Tôi hoàn toàn đồng ý với câu trả lời của Catcall ngoại trừ một điểm: "năm" có thể không phải luôn luôn là một giá trị nguyên thủy, nhưng tôi đoán đó là một khái niệm logic kinh doanh nhiều hơn là một thiết kế cơ sở dữ liệu.

Giữ nguyên thiết kế, giả sử rằng năm chỉ nên là những năm được phép phát hành. Theo cách đó, bạn không xử lý các giá trị số nguyên thủy, mà là một tập hợp con của chúng và vì tập hợp con đó không có triển khai nguyên thủy, bạn phải tự làm (một bảng riêng?) Và tham chiếu nó (với một FK). Theo cách đó, chúng ta vẫn nói về nhiều năm, nhưng chúng ta cần quản lý chúng theo một cách khác, bởi vì về mặt khái niệm chúng đã thay đổi ý nghĩa của chúng. Tuy nhiên, chúng vẫn là "năm phát hành", nhưng về mặt khái niệm khác nhau về ý nghĩa của chúng đối với ai đó trong kiến ​​thức tên miền.

Đối với trường hợp cụ thể này, một lần nữa tôi nói rằng câu trả lời của Catcall là đúng, nhưng chỉ muốn chỉ ra điều đó. (Xin lỗi, chưa có đủ đại diện để bình luận.)