sql - 餐厅菜单是什么规范化形式？

Question

这可能是题外话，但我很好奇。

假设您有一个普通的餐厅菜单，其中包含 itemID、餐点名称和价格。它是什么正常形式？

我说它是 BCNF，因为但一个朋友提出它不在 3NF 中，因为传递依赖价格 -> 项目名称 -> 项目编号。你们有什么感想？

Answer 1

餐厅菜单不是任何正常形式。与任何其他要求集一样，菜单可以表示为 BCNF 中的关系模式或其他一些不在 BCNF 中的模式。这是数据库设计者在创建模式时所做的选择；不是菜单信息本身隐含的东西。

您还没有完全指定有问题的架构。假设关系：

Menu {ItemID, Name, Price}

有两个键：{ItemID} 和 {Name} 然后菜单在 BCNF 中关于功能依赖集：

ItemID -> Name -> Price
Name -> ItemID -> Price

这些不是非键传递依赖项，因为 Name 和 ItemID 都是候选键。由于菜单在 BCNF 中，它也在 3NF 中。

函数依赖总是以 Determinant -> Dependant 的形式编写。我看不出价格如何可能成为决定因素（菜单上每个项目的唯一价格似乎极不可能）所以你提到的依赖：价格 - > 项目名称 - > 项目编号没有多大意义大部头书。如果由于某种原因价格确实是非关键决定因素，那么上述菜单关系当然会违反 BCNF（和 3NF）。

Answer 2

如果菜单只有一种语言，那么表有两个键（id 和 name），每个非键（价格）都依赖于每个键，满足 3NF。4NF 也满足，因为只有一个非键列。5NF 和 6NF 处理多表关系；因为只有一张桌子，他们也很满意。

如果菜单是多语言的，菜单仍然满足第一范式（如果我们将虚拟列“语言”视为真列；否则，菜单甚至不是1NF），但不满足第二范式：没有非key 属性依赖于 key 的适当子集：这里的模式是：columns(language,id,name,price); keys((language,id),(name[,language])) 但价格仅取决于餐点 ID，而不是订购的语言。

DB-理论上，正确的分解是引入一对表 table(language,id,name) keys((language,id),(name[,language])) table(id,price) keys(id) 。当然，这在真正的餐厅里会很不方便（想象一下有两个菜单——一个英文菜单和一个翻译表），唯一的好处是价格独立于语言是强制的，而不是暗示的。

名称不依赖价格：价格不决定名称；这是相反的方式。