6

tôi có các bảng sau:thiết kế - thứ sáu hình thức bình thường

Blogs { BlogName } 
BlogPosts { BlogName, PostTitle } 

Blog bài viết được mô hình hóa một thực thể và mối quan hệ cùng một lúc mà không hợp lệ theo 6nf (theo tuyên ngôn thứ ba).

Trong 6nf, nó sẽ là:

Blogs { BlogName } 
Posts { PostTitle } 
BlogPosts { BlogName, PostTitle} 

Nếu tôi muốn đặt mua bài đăng trên blog của một nbr chụp liên tục (chỉ là ví dụ), đó sẽ là một bảng

BlogPostsSorting { BlogName, PostTitle , SortOrder } 

Tôi có nó đúng không

+0

Lược đồ 6NF được đề xuất của bạn giả định rằng không có blog nào từng sử dụng lại tiêu đề bài đăng. –

+0

Đầu tiên, trong khi Ngày và Darwen có nhiều điều để nói về 6NF, tôi không tin TTM làm. Thứ hai, lưu ý rằng mặc dù 6NF luôn đạt được nhưng nó không phải lúc nào cũng mong muốn. Xem phần Giới thiệu về Lý thuyết Cơ sở dữ liệu Quan hệ của Darwen (tải xuống miễn phí), 7.3 Đánh giá phân tích 6NF, tr180-2. – onedaywhen

Trả lời

4

sqlvogel là chính xác in this answer.

Ngoại trừ chi tiết nhỏ này: liệu Blog có dư thừa hay không phụ thuộc vào việc bạn muốn/cần thực thi ràng buộc với hiệu lực mà tất cả các tuple của Blog phải có ít nhất một bộ BlogPost tương ứng. Bạn đã không nói bất cứ điều gì để làm cho rõ ràng.

Các lưu giữ tương tự cho bài đăng thứ ba của bạn, ngoại trừ trong trường hợp này, rất có khả năng nó không hợp lệ để PostTitle tồn tại mà không xuất hiện dưới tiêu đề của ít nhất một BlogPost.

Cho dù bạn cần chuyển đổi SortingOrder dưới dạng phụ thuộc vào việc có hay không có BlogPosts mà không cần thứ tự sắp xếp. Nếu không thể, thì Relig SortingOrder của bạn chỉ đơn giản là thay thế BlogPosts. Nếu có thể, sau đó bạn có thể có hai relvars; hoặc theo cách khác, bạn vẫn có thể chuyển hướng SortingOrder và hack theo cách của bạn thông qua trường hợp bài đăng mà không cần đặt hàng bằng cách sử dụng giá trị giả (ví dụ: luôn -1).

+0

BlogBài viếtSắp xếp {BlogName, PostTitle, SortOrder}. Nếu đó là chìa khóa {BlogName, PostTitle} cùng với một thuộc tính không phải là khóa {SortOrder}, thì đó là 6NF. (Oh chờ đã, bạn đang đề cập đến ảnh hưởng của một khóa thứ hai có thể {BlogName, SortOrder} ???Tôi không nghĩ rằng điều này ảnh hưởng đến bất cứ điều gì. Các relvar vẫn không phải là không phân tách được.) –

+0

Nhận xét rằng nhận xét này là một phản ứng dường như đã biến mất. –

6

Các phím của bảng của bạn là gì? Dựa trên các tên cột, tôi đoán rằng chìa khóa của BlogPosts chỉ có thể là {BlogName, PostTitle}. Trong trường hợp đó, BlogPosts đã có trong 6NF - nó không có thuộc tính nonprime và do đó không thể phân tách nonloss. Các relvar Blogs và Relvar bài viết sẽ là dư thừa - bạn không cần chúng.

Blog bài viết được mô hình hóa một thực thể và mối quan hệ cùng lúc đó là không hợp lệ theo 6nf (theo tuyên ngôn thứ ba)

Bạn có thể cho tôi biết nơi bạn nghĩ rằng Tuyên ngôn thứ ba nói đến điều đó không hợp lệ. Tôi chắc chắn nó không nhưng tôi muốn biết làm thế nào bạn đến một kết luận như vậy.

+0

TTM không có bất cứ điều gì rõ ràng để nói về 6NF (tại sao nó?) Và ngày Chris cố ý tránh sử dụng thuật ngữ 'thực thể' ngày nay. – onedaywhen

+1

Mặc dù không liên quan đến bình thường hóa, sẽ có một vấn đề thiết kế thực tế nếu chúng tôi loại bỏ các relvar Blogs: chúng tôi sẽ không thể đăng ký một blog cho đến khi tiêu đề đầu tiên đã được quyết định. Tôi nghĩ rằng đây là điểm @Erwin Smout làm, giả sử họ đang dùng về * ngụ ý * ràng buộc. – onedaywhen

Các vấn đề liên quan