什么标准化形式是餐厅菜单？

Question

这可能是偏离主题但我很好奇。

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

我说这是BCNF，因为但是一位朋友提到它不是因为传递依赖价格而在3NF中 - ＆gt;项目名称 - ＆gt;项目编号。你们觉得怎么样？

Answer 1

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

您尚未确切指定相关架构。假设关系：

Menu {ItemID, Name, Price}

有两个键：{ItemID}和{Name}，然后Menu在BCNF中与功能依赖关系集相关：

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

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

功能依赖性总是以“决定因素”形式写成 - ＆gt;相关。我不知道普莱斯怎么可能成为一个决定因素（菜单上每个项目的独特价格似乎极不可能）所以你提到的依赖性：价格 - ＆gt;项目名称 - ＆gt;项目编号对我来说没有多大意义。如果由于某种原因价格确实恰好是非关键决定因素，那么上述菜单关系当然会违反BCNF（和3NF）。

Answer 2

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

如果菜单是多语言的，菜单仍然满足第一范式（如果我们将虚拟列“语言”视为真列;否则，菜单甚至不是1NF），但不能满足第二范式：没有非键属性依赖于键的正确子集： 这里的架构是：列（语言，ID，名称，价格）;键（（语言，id），（名称[，语言]））但价格仅取决于用餐ID，而不取决于订购的语言。

理论上，DB-适当的分解是引入一对表 表（语言，id，名称）键（（language，id），（name [，language]）） table（id，price）键（id） 。当然，这对于一家真正的餐馆来说会很不方便（想象得到两个菜单 - 一个英文菜单和一个翻译表），唯一的好处就是强制语言价格的独立性而非暗示。

名称与价格无关：价格不确定名称;这是相反的方式。