Question

有人告诉我，下表不适合第二次数据库规范化。但我不知道为什么？我是数据库设计的新手，我已经阅读了3NF的一些教程。但对于2NF和3NF，我无法理解它们。希望有人可以帮我解释一下。谢谢，

    +------------+-----------+-------------------+
    pk                pk             row
  +------------+-----------+-------------------+
      A                  B                  C
   +------------+-----------+-------------------+
        A                  D                  C
 +------------+-----------+-------------------+
          A                  E                  C
  +------------+-----------+-------------------+

Answer 1

关于您的示例：该表不适合第二个数据库规范化（使用您的示例数据，我假设C仅依赖于A）。第二种规范化形式要求：

No non-prime attribute in the table is functionally dependent on a
候选键的适当子集（Wikipedia）

所以C依赖于“A”，它是主键的子集。您的主键是 特殊超级键。（dportas指出它不能被称为候选键，因为它不是最小的。）

让我们更多地谈论第二种规范化形式。稍微改变你的例子以便于理解，假设有一个表CUSTOMER(customer_id, customer_name, address)。超级键是属性的子集，它唯一地确定管。在这种情况下，有3个超级密钥：（customer_id）; （customer_id，customer_name）; （customer_id，customer_name，地址）。（2人的客户名称可能相同）

在您的情况下，您已确定（customer_id，customer_name）为主键。它违反了第二种形式规则;因为它只需要customer_id来确定数据库中唯一的管。 为了理论上的准确性，这里的问题来自于主键的选择（它不是候选键），尽管可以应用相同的参数来显示冗余。您可以找到一些有用的示例here。

第三种正常形式表明：

每个非素数属性都是非传递性依赖于每一个表中的候选键

让我们举个例子。更改上一个表以适合第二个表单，现在我们有表CUSTOMER(customer_id,customer_name, city, postal_code)，其中customer_id是主键。

显然，“postal_code”取决于客户的“城市”。这是违反第三条规则的地方：postal_code取决于城市，城市取决于customer_id。这意味着postal_code传递依赖于customer_id，因此该表不适合第三范式。

要纠正它，我们需要消除传递依赖。因此，我们将表格拆分为2个表格：CUSTOMER(customer_id, customer_name, city)和CITY(city, postal_code)。这可以防止在同一城市和太阳能管道中存在太多管道的冗余。 POSTAL_CODE。

Answer 2

除非您在此声明要满足哪些依赖项，否则无法正确回答您的问题。您似乎有两个具有相同名称（pk）的属性，在这种情况下，此表甚至不满足1NF，因为它不符合关系。

Answer 3

你可以简单地按照我的笔记。每个步骤都有很多例子详细描述：Normalization。搜索＆＃34;规范化＆＃34;网站上的术语。

数据库----数据库规范化

3 个答案: