具有唯一外键的表规范化

问题描述 投票:0回答:1

假设有一个表

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。

foreign-keys database-normalization
1个回答
0
投票

选择主键

  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
      表中的属性不是派生的或相互依赖的,而是仅依赖于主键。

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

© www.soinside.com 2019 - 2024. All rights reserved.