具有唯一外键的表规范化

Question

假设有一个表

User

具有以下属性

User: user_id(Primary Key), name, password, phone, username, email, created_on

还有另一张桌子

Customer

 Customer: customer_id, dob, gender, user_id (Foreign key to User table)

据此，一位客户或

customer_id

将仅与一位

user_id

相关联。因此

customer_id

和

user_id

都可以唯一地确定

Customer

表中的每条记录。我应该将哪一个视为主键，省略另一个的原因是什么？
我该如何将该表标准化为 3NF。

Answer 1

选择主键

1. 唯一性：

   customer_id

   和

   user_id

   在各自的表中都是唯一的。由于

   user_id

   是

   User

   表中的外键，它将唯一标识一个用户，假设每个用户对应一个客户，它也可以唯一标识一个客户。

2. 含义：

   customer_id

   可能是代理键，这意味着它除了用作数据库中的标识符之外没有任何意义。

   user_id

   ，另一方面，不仅可以识别客户，还可以将该客户与用户配置文件联系起来。

3. 未来变化：如果业务规则发生变化，使得用户将来可以链接到多个客户（例如，如果用户可以拥有多个角色或帐户类型），

   user_id

   将不再唯一标识一个客户。在这种情况下，

   customer_id

   将是一个更安全的选择，因为它独立于其他实体。

=>

customer_id

应用作 Customer

 的主键

它可以避免业务规则演变时出现的潜在问题，并且它保持了明确的关注点分离，其中

User

表处理与身份验证相关的属性，而

 Customer

表处理客户特定的详细信息。

归一化为 3NF

为了确保

Customer

表标准化为第三范式 (3NF)，您应该检查：

1. 1NF（第一范式）：

   • 原子性：确保每一列都包含原子（不可分割）的数据值。例如，

     name

     不应包含多个名称。
   • 唯一性：每一行都需要是唯一可识别的。这是通过主键

     customer_id

     实现的。

2. 2NF（第二范式）：

   • 无部分依赖：所有非键属性（例如，

     dob

     、

     gender

     ）必须依赖于整个主键，而不仅仅是其一部分。由于

     customer_id

     是唯一主键，并且

     Customer

     中的所有其他属性都依赖于它，所以自然满足这个条件。

3. 3NF（第三范式）：

   • 无传递依赖：非关键属性不应依赖于其他非关键属性。

     Customer

     表中的所有属性（

     dob

     、

     gender

     、

     user_id

     ）应仅依赖于

     customer_id

     ，而不是相互依赖。
   • 为了遵守 3NF，请确保

     Customer

     表中的属性不是派生的或相互依赖的，而是仅依赖于主键。

通过确保这些条件，您的表结构将是健壮、高效和可扩展的，为扩展数据库模式提供清晰的途径，而不会引入冗余或异常。