数据规范化至3NF的正确性验证及相关优化问题咨询

已完成的规范化操作过程 #

• 初始1NF表：包含字段 userId、userName、keyNumber、keyCode、accessGroup、doors，数据详情见对应表格。
• 2NF转换：选取(userID, doors)作为复合候选键，依据函数依赖（FD）规则拆分为3张表，主键分别为：
  • 表1：主键userID
  • 表2：主键doors
  • 表3：复合主键(userid, doors)
• 3NF转换：对2NF中的第一张表应用传递依赖规则，拆分为4张表（后两张与2NF一致，仅展示前两张）：
  • 表A：主键userID
  • 表B：主键keyNumber

技术疑问 #

1. 上述数据库规范化操作是否符合规范？若不符合，请指出错误之处。
2. 若操作符合规范，鉴于存在函数依赖keycode -> accessGroup，是否需要将3NF中的最后一张表拆分为两张表以满足3NF要求？

解答 #

问题1：操作规范验证 #

仅从当前描述来看，存在几个需要明确或修正的问题：

1. 2NF候选键与表结构合理性：2NF核心是消除非主属性对候选键的部分依赖，首先要确认(userID, doors)是否真的是主键（而非仅候选键）。若存在其他候选键（比如keyNumber可唯一标识用户关联数据），候选键选择会直接影响拆分逻辑。同时拆分出的3张表必须明确字段归属：
   • 主键为userID的表：只能保留完全依赖于userID的字段（如userName），若包含keyNumber/keyCode这类不直接依赖userID的字段，就违反2NF。
   • 主键为doors的表：仅能保留与门本身强相关的字段，混入其他非依赖字段不符合规范。
   • 复合主键(userID, doors)的表：应为用户-门关联表，仅保留这两个主键字段或完全依赖于该复合键的字段。
2. 3NF拆分逻辑模糊：描述中“对2NF中的第一张表应用传递依赖规则”未明确原表的字段构成和具体传递依赖关系。比如若原表存在userID → keyNumber → keyCode这类传递依赖，拆分合理；但如果传递依赖不成立，拆分就没有依据。

问题2：关于keycode -> accessGroup的3NF处理 #

3NF要求消除非主属性对主键/候选键的传递依赖，所有非主属性必须直接依赖于候选键。如果3NF中的目标表满足以下情况：

• 表的主键为keyNumber（或其他非keyCode的键），同时包含keyCode和accessGroup
• keyCode不是该表的主键/候选键，且accessGroup仅依赖于keyCode而非直接依赖于主键

这种情况下必须拆分该表：

• 表1：主键keyNumber，包含keyNumber、keyCode（需满足keyNumber → keyCode的函数依赖）
• 表2：主键keyCode，包含keyCode、accessGroup

以此消除传递依赖，符合3NF要求。如果keyCode本身就是该表的主键，那么keycode -> accessGroup属于直接依赖，无需拆分。

内容的提问来源于stack exchange，提问作者filtertips