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

Question

有人告诉我下表不适合第二次数据库规范化。但我不知道为什么？我是数据库设计的新手，我读过一些3NF的教程。但对于2NF和3NF，我不能很好地理解它们。期待有人能为我解释一下。谢谢你，

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

Answer 1

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

Answer 2

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

表中没有非主属性在功能上依赖于

候选键的真子集
（维基百科）

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

让我们更多地了解第二种规范化形式。为了便于理解，稍微改变一下您的示例，假设有一个表CUSTOMER(customer_id, customer_name, address)。超级键是唯一确定管的属性的子集。在本例中，有 3 个超级键： (customer_id) ； （客户 ID，客户名称）； （客户 ID、客户名称、地址）。 （2 个人的客户名称可能相同）

在您的情况下，您已确定 (customer_id, customer_name) 为主键。违反了第二种形式的规则；因为它只需要 customer_id 来唯一确定数据库中的管。 为了理论准确性，这里的问题是由主键（不是候选键）的选择引起的，尽管可以应用相同的论点来显示冗余。您可能会在此处找到一些有用的示例。

第三范式指出：

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

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

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

为了纠正它，我们需要消除传递依赖。因此，我们将该表拆分为 2 个表：CUSTOMER(customer_id, customer_name, city) 和 CITY(city, postal_code)。这可以防止在同一城市和地区拥有太多管道的冗余。邮政编码。