问题标签 [third-normal-form]

我有

R(ABCDE) 其中 AB 为主键 F= { f1: AB->CDE; f2: BD->E }

我很困惑，因为我的教科书说它达到了第 3 范式，但是当我通过在线工具检查时，它说由于 f2 违规，关系达到了第 2 范式。

哪个是对的？

我有一个我正在尝试建立的数据库，我希望它至少在 3NF 中。但是，有些字段并非在所有情况下都是必需的，并且该字段的必要性，而不是值本身，取决于另一个。

从本质上讲，我想跟踪由于某种原因而暂停的工作。我现在的主表包括以下字段：

我还有其他用于员工列表和存储位置的表格。现在我的问题是，如果作业在存储位置“LAB”中，那么它将有一个我想要跟踪的关联 Lab Ticket 编号。我将有另一个包含状态、ECD 等的 Lab Tickets 表。如果存储位置是“MR”，那么作业应该有一个通知编号，并且一个单独的表将包含有关通知的信息。

尽管作业在任何给定时间只能有 1 个存储位置，但它可以移动。例如，如果一个作业进入“LAB”并未能通过测试，它将被移动到“MR”并创建一个通知。

让我的 tblJobs 具有以下字段是否违反了 3NF 或其他形式的错误：

即使不是所有字段都填充或用于每项工作？顺便说一句，我正在使用 MS Access，尽管我认为这并不重要。

编辑：我看到有关 Null 值的相关帖子，但我的问题不是关于编程（我可以轻松地在不适用的字段中输入非空值 [例如“N/A”]），以及更多关于抽象数据库设计级别：简而言之，拥有可能不适用于大多数记录的字段是一种糟糕的形式吗？我通常讨厌在任何表中看到一堆 N/A 字段，但我开始认为一些经过深思熟虑的查询将允许我仅查看特定子集的相关信息。前任。对于“LAB”中的所有项目，显示实验室编号状态。

我已经分解了一种关系，它跟踪员工的关系以及他们在酒店工作的时间。原来的关系如下

改写为

我找到了功能依赖项

由此我创建了以下 3 个表

在我的第三张表中，我有一个主键，可以确定酒店的数量和位置。但是酒店号码也可以确定酒店的位置。我应该将酒店位置移动到一张新桌子上，只有酒店号码吗？那会占用更多空间，但是否有必要达到 3RD 范式？

我对这个3NF（第三范式）的东西有点困惑。我有一个需要做的项目，它需要在3NF中。我创建了一些描述计算机不同部分的表格。

例如，我有一个名为的表CPU和一个名为COMPUTERSYSTEM. CPU得到NAME了、PRICE和SOCKETTYPE列CLOCKSPEED。该COMPUTERSYSTEM表是不同组件的组合，这些组件位于CPU表或其他一些组件表中，例如GPU.

所以我的问题是，这是3NF吗？是表CPU 3NF吗？我理解3NF，因为每一行都需要依赖于primary key，而 myprimary key是所有表中的名称，价格和时钟速度等不依赖于名称吗？

假设我有一个具有以下属性的表

• 订单编号
• 商品编号
• 项目数量
• 项目单价
• 项目付款

其中“项目付款 = 项目单价 x 项目数量”。让我们简化情况，假设每个订单的任意数量只有一个 item id，并且不同的订单可能有相同的 item id。

1. 什么是主键，“订单 ID”、“订单 ID”和“商品 ID”，或者其他什么？

2. 如何将其归一化为 3NF？

   这是我正在考虑的解决方案：

   • 包含订单 ID（主键）、商品 ID、商品数量和商品付款的表格

   • 带有项目 id（前一个表的主键和外键）和项目单价的表。

3. 继续我在第 2 部分中给出的暂定解决方案。在第一个表中，对于每个项目 ID，项目付款与项目数量成正比。如果第一张表的主键是order id，则商品支付依赖于非主键属性的商品数量，违反了3NF无传递性要求。

   我应该将第一个表拆分为：

   • 带有订单 ID（主键）和商品 ID 的表
   • 带有项目 ID（前表的主键和外键）、项目数量和项目付款的表

   或进入：

   • 带有订单 ID（主键）和商品 ID 的表
   • 包含项目单价（原始第二个表的主键和外键）、项目数量和项目付款的表？

谢谢。

我正在准备考试，在我的课文中我发现了一个我不明白的例子。

在关系上，R(A,B,C,D,E,F)我得到了以下函数依赖：

现在我认为所有的 FD 都在 3NF 中（没有一个在 BCNF 中），但是文字说 FD1 和 FD2 在 2NF 中，而 FD3 和 FD4 在 1NF 中。我在哪里犯错误（或者是文本错误）。

我发现替代键是 ABD 和 ACD

正如 Thomas Connolly 和 Carolyn Begg 在第 180 页所写的 Database Solutions Second Edition 中所说：

第三范式 (3NF)
已经在 1NF 和 2NF 中的表，其中所有非主键列中的值只能从主键列而不是其他列中计算出来。

我见过很多人们使用标识列的场景，尽管他们的表中已经有一个主键列。记录也可以从标识列中计算出来，那么如果我们在表中使用自动递增标识列和主键，是否违反了 3NF？

更新：如果不是这样，哪个列应该被引用为另一个表中的外键。主键列还是标识列？

以下问题来自：https ://cs.senecac.on.ca/~dbs201/pages/Normalization_Practice.htm （练习3）

未规范化的表如下所示：

为了符合第一范式，必须处理所有重复组。在这种情况下，多个产品可能会出现在一个订单上，因此必须为其提供自己的实体并与原始表相关联：

这些表也是第二范式，因为在所有表中，每个非键属性都依赖于其表中的主键。

最后，要将其带入第三范式，必须为客户提供自己的实体并与原始订单实体相关联：

我是否将原始表格正确规范化为第三范式？如果没有，请提供反馈，解释我做错了什么。

关系 R(A,B,C,D,E) 具有函数依赖关系 A -> B,C,D,E 和 BCD -> E

A 是一把钥匙。但是，这种关系不在 3NF 中，因为 BCD -> E 是违规的，其中 E 不是素数属性，BCD 不是超键。所以如果我们分解关系，我们得到

R1(A,B,C,D) 和 R2(B,C,D,E) ? 还是我在这个分解中不正确

这是从Wikipedia获取的关于范式的文章的屏幕截图。

有人说，为了符合3NF该Genre Name列，必须将其放入它自己的字典表中。

我的问题是，那里也有Author Nationality断裂吗？3NF