【问题标题】:What is the 2nd normal form?第二范式是什么?
【发布时间】:2025-12-24 12:20:08
【问题描述】:

我对这些的非正式表示是:

1NF:表格被划分,因此没有项目会出现多次。

2NF:?

3NF:值只能由主键确定。

我无法从我在网上或书中找到的摘录中理解它。如何区分 1NF 和 2NF?

【问题讨论】:

  • 看看这个帖子:*.com/questions/723998/…
  • 花了我一段时间,但我想我现在明白了; 2NF:它依赖于整个密钥,但在 3NF 中它是“只有密钥”。 :)

标签: database database-normalization


【解决方案1】:

如果每个非主属性在功能上完全依赖于每个键,则关系模式属于 2NF。

【讨论】:

    【解决方案2】:

    Wikipedia 说:

    一个表在 2NF 中当且仅当它在 1NF 中并且每个非素数 表的属性要么依赖于整个候选人 键,或另一个非主要属性。

    为了解释这个概念,让我们用一张表格来列出改编自Head First SQL的玩具:

    TOY_ID| STORE_ID| INVENTORY| STORE_ADDRESS
    

    主键由属性 TOY_ID 和 STORE_ID 组成。如果我们分析非主属性 INVENTORY,我们会看到它同时依赖于 TOY_ID 和 STORE_ID。太酷了。

    但另一方面,非主属性 STORE_ADDRESS 仅取决于 STORE_ID 属性(即它与主键属性 TOY_ID 无关)。这明显违反了 2NF,所以要向 2NF 投诉,我们的架构必须是这样的:

    库存表:TOY_ID| STORE_ID| INVENTORY

    还有一个 Store 表:STORE_ID| STORE_ADDRESS

    【讨论】:

    • 本例中的 3NF 是什么?
    • 3NF 模式没有传递依赖(一个非键列依赖于另一个非键列)。我使用的示例只有一个非关键属性,所以它已经在 3NF
    【解决方案3】:

    某些列是键(主键或辅助键)的一部分。我们将这些称为主要属性。

    对于第二范式,我们将考虑非主属性,看看是否应该将它们移动到另一个表中。我们可能会发现某些属性不需要完整的键,我们就能够识别它们对于至少一个候选键的值。也就是说,有一个候选键,即使该候选键的一列中的值被删除,我们仍然可以在给定候选键的情况下确定该属性的值。

    【讨论】: