設計 - 第六正常形式

我有以下表：設計 - 第六正常形式

Blogs { BlogName } 
BlogPosts { BlogName, PostTitle }

博客日誌被建模的實體，並在根據6NF（根據第三宣言），這是無效的，同時的關係。

在6NF，這將是：

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

如果我要爲了通過序列NBR（只是一個例子）的博客文章，這將是另一個表

BlogPostsSorting { BlogName, PostTitle , SortOrder }

我必須它正確嗎？

來源

2011-09-24 firebird

您提出的6NF模式假定沒有博客重複使用帖子標題。 –

首先，雖然Date和Darwen在6NF有很多話要說，但我不相信TTM。其次，請注意，雖然6NF始終可以實現，但並不總是可取的。參見Darwen的關係數據庫理論導論（免費下載），7.3評估6NF分解，pp180-2。 – onedaywhen

sqlvogel是正確的in this answer。

除了這個小細節：博客是否冗餘取決於您是否需要/強制實施約束，以使所有博客元組必須至少有一個對應的BlogPost元組。你沒有說明任何說明。

這同樣適用於您的第三個relvar帖子，但在這種情況下，它極不可能對PostTitle存在有效，而不會顯示爲至少一個BlogPost的標題。

您是否需要將SortingOrder relvar作爲額外的取決於是否可以有不需要排序順序的BlogPosts。如果不能，那麼你的SortingOrder relvar只是取代BlogPosts。如果可以的話，那麼你可以有兩個相對的人;或者您仍然可以只使用SortingOrder relvar，並通過使用虛擬值（例如，始終爲-1）進行排序而無需排序的方式破解您的方式。

來源

2011-09-25 17:35:03

BlogPostsSorting {BlogName，PostTitle，SortOrder}。如果這是一個關鍵{BlogName，PostTitle}加上一個非鍵屬性{SortOrder}，那麼它就是6NF。（哦，等等，你是指可能的第二個鍵{BlogName，SortOrder}）的效果？我不認爲這會影響任何事情。該relvar仍然不nonloss分解。） –

該評論是迴應的評論似乎已經消失。 –

你的表的關鍵是什麼？根據列名，我猜測BlogPosts的關鍵只能是{BlogName，PostTitle}。在這種情況下，BlogPosts已經在6NF中 - 它沒有非優先屬性，因此不能被非丟失分解。博客relvar和帖子relvar將是多餘的 - 你不需要它們。

博客文章中（根據第三宣言）

你能告訴我，你認爲三宣言說建模的實體，並在同一時間根據6NF這是無效的關係那是無效的。我確信它不會，但我想知道你是如何得出這樣的結論的。

來源

2011-09-24 19:58:45 sqlvogel

TTM沒有任何關於6NF的明確說法（爲什麼會這樣？）和Chris Date有意避免使用現在的「實體」這個術語。 – onedaywhen

雖然與標準化沒有關係，但如果我們取消博客反轉，會出現實際的設計問題：在確定第一個標題之前，我們無法註冊博客。我認爲這是@ Erwin Smout所做的一點，假設他們正在考慮*隱含的約束。 – onedaywhen

設計 - 第六正常形式

回答

相關問題