BCNF分解（数据库设计）答案

【问题标题】：BCNF Decomposition (Database Design)BCNF分解（数据库设计）
【发布时间】：2011-08-01 04:59:43
【问题描述】：

我正在尝试将几个表分解为 BCNF。我相信第一个被正确分解，但我不确定其他人是否可以分解。任何帮助表示赞赏

**make(id, name, est, founder, city, state)**

id->name;
name->est, city, state, founder;
city->state

New Relations: [Key(id),name], [Key(name),est,city,state,founder], [Key(city),state]

**model(id, makeId, name, year, category)**

id->makeId, name;
name->year, category (not superkey, but can't really decompose)

**features(id, modelId, abs, tpms, sidebags, drl)**

id->modelID, abs, tpms, sidebags, drl 

**user(id, name, pass, first, last, phone, isAdmin)**

id->name, pass, isAdmin; name->first, last, phone

**selling(id, price, modelId, mileage, userId)**

id->price, modelId, mileage, userID

【问题讨论】：

标签： database-design normalization decomposition

【解决方案1】：

BCNF 很简单：只需确保单个关系中属性集之间的所有依赖关系都是对关系超键的依赖。你的第一个很接近，但第二个关系需要省略“状态”。通常，人们会停留在 3NF，因为并非所有与 FD 的关系都具有保持依赖关系的 BCNF 分解。您需要帮助分解其他关系吗？如果您需要，我会提供帮助。

编辑：对其他关系的帮助。

销售和功能都很好。 Models 和 Users 需要在 Name 上进行拆分才能进入 BCNF；您表示这不是您可以为模型做的事情。为什么？名称暗示箭头右侧的东西，对吧？

【讨论】：

是的，如果您能帮我分解其他的，将不胜感激。我仍在学习如何应用该算法，所以看看在这些情况下如何做会很有帮助。
lhs 必须是超级键，对吧？如果我将其分解为： [Key(id),makeId, name] [Key(name), year, category] 是否正确？感谢您的帮助。
把名字放在第一位，是的。任何给定关系中的依赖都必须在该关系的超键上；该超级键不必是原始的超级键。您在上面的评论中建议的分解是正确的、保留依赖关系的、无损的 BCNF 分解。
酷，谢谢！我假设 users 表分解如下： R1: [Key(id), name, pass, isAdmin] R2: [Key(name), first, last, phone] 这些新关系会像新模型一样满足 BNCF关系？可以在 BCNF 中考虑销售/功能吗？