设计-第六范式

发布于 2024-12-06 11:00:27 字数 398 浏览 0 评论 0原文

我有下表:

Blogs { BlogName }
BlogPosts { BlogName, PostTitle }

博客文章同时对实体和关系进行建模,根据 6nf(根据第三个宣言),这是无效的。

在 6nf 中,它将是:

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

如果我想按序列 nbr 对博客文章进行排序(只是一个示例),那将是另一个表

BlogPostsSorting { BlogName, PostTitle , SortOrder }

我是否正确?

I have the following tables:

Blogs { BlogName }
BlogPosts { BlogName, PostTitle }

Blog posts is modeling an entity and a relationship at the same time which is invalid according to 6nf (according to the third manifesto).

In 6nf, it would be:

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

If I wanted to order blog posts by a sequence nbr (just an example), that would be another table

BlogPostsSorting { BlogName, PostTitle , SortOrder }

Do I have it correct?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

坐在坟头思考人生 2024-12-13 11:00:27

你的表的键是什么?根据列名,我猜测 BlogPosts 的键只能是 {BlogName,PostTitle}。在这种情况下,BlogPosts 已经处于 6NF 状态 - 它没有非素数属性,因此不能进行无损分解。博客 relvar 和帖子 relvar 是多余的 - 您不需要它们。

博客文章同时对实体和关系进行建模
根据 6nf(根据第三个宣言),这是无效的

你能告诉我你认为第三宣言在哪里说这是无效的吗?我确信不是,但我想知道你是如何得出这样的结论的。

What are the keys of your tables? Based on the column names I guess that the key of BlogPosts can only be {BlogName,PostTitle}. In that case BlogPosts is already in 6NF - it has no nonprime attributes and therefore cannot be nonloss decomposed. The Blogs relvar and Posts relvar would be redundant - you don't need them.

Blog posts is modeling an entity and a relationship at the same time
which is invalid according to 6nf (according to the third manifesto)

Can you tell me where you think the Third Manifesto says that's invalid. I'm sure it doesn't but I'd like to know how you arrived at such a conclusion.

梨涡少年 2024-12-13 11:00:27

sqlvogel 在此答案中是正确的。

除了这个小细节之外:Blogs 是否冗余取决于您是否想要/需要强制执行一项约束,即所有 Blogs 元组必须至少有一个相应的 BlogPost 元组。你没有说任何话来澄清这一点。

这同样适用于您的第三个相关帖子,只不过在这种情况下,如果不作为至少一篇 BlogPost 的标题出现,则 PostTitle 的存在极不可能是有效的。

是否需要 SortingOrder 相关变量作为额外变量取决于是否存在不需要排序顺序的 BlogPost。如果不能,那么您的 SortingOrder 相关变量将简单地替换 BlogPosts。如果可以的话,那么你可以拥有两个relvars;或者,您仍然可以只拥有 SortingOrder 相关变量,并通过使用虚拟值(例如,始终为 -1)来破解帖子的情况,而无需排序。

sqlvogel is correct in this answer.

Except for this little detail: whether Blogs is redundant or not depends on whether you want/need to enforce a constraint to the effect that all Blogs tuples must have at least one corresponding BlogPost tuple. You didn't state anything to make that clear.

The same holds for your third relvar Posts, except that in this case it is highly unlikely that it could be valid for a PostTitle to exist, without it appearing as the title of at least one BlogPost.

Whether you need the SortingOrder relvar as an extra one depends on whether or not there can be BlogPosts for which no sorting order is needed. If there cannot, then your SortingOrder relvar simply replaces BlogPosts. If there can, then you can have the two relvars; or alternatively you can still just have the SortingOrder relvar, and hack your way through the case of posts without ordering by using a dummy value (e.g., always -1).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文