给定FD，如何将UNF表规范化至3NF？Oracle建模规范化求助

问题1：将包含staff、patient、date、time、surgery的UNF表规范化至3NF #

首先得明确：规范化的核心是靠函数依赖（FD）消除数据冗余和操作异常，所以第一步你得把所有明确的FD列出来——咱拿这类手术/预约场景里最常见的FD组合来演示，方便你套用，比如假设你的FD是：

• staff, date, time → surgery（同一医护人员在同一时间只能做一台手术）
• surgery → patient（每台手术对应固定的患者）
• patient, date, time → surgery（同一患者同一时间只能接受一台手术）

步骤1：从UNF到1NF #

UNF表的典型问题是有重复组（比如一行里挤了同一个staff同一天多台手术的信息），第一步就是拆分行，让每个属性都是原子值，每行有唯一标识。比如原UNF表可能是：

转成1NF后，就得拆成两行：

步骤2：从1NF到2NF #

2NF要求消除非主属性对候选键的部分依赖，先得确定候选键。根据上面的FD，候选键是(staff, date, time)和(patient, date, time)——因为这两个组合都能唯一确定surgery。现在看非主属性：surgery完全依赖候选键，patient依赖于surgery，没有部分依赖（非主属性不会只依赖候选键的某一部分），所以当前1NF表已经满足2NF。

步骤3：从2NF到3NF #

3NF要消除非主属性之间的传递依赖。这里patient依赖于surgery，而surgery又依赖于候选键，这就是传递依赖。所以咱得拆成两个表：

1. 手术安排表：主键(staff, date, time)，属性包含staff, date, time, surgery——负责记录医护人员的手术时间安排
2. 手术患者映射表：主键surgery，属性包含surgery, patient——负责记录每台手术对应的患者

这样拆分后，所有非主属性都直接依赖于各自表的主键，没有传递依赖，完全符合3NF要求。

问题2：用Oracle SQL Developer Data Modeler建模后，找不到符合所有FD的规范化方法 #

遇到这种工具“不给力”的情况，我从来不会死磕工具的自动功能，而是先手动推导，再反过来调整模型，具体做法如下：

1. 先把函数依赖捋明白，排除矛盾 #

工具出问题，大概率是你输入的FD有遗漏、冲突，或者工具没正确识别。先停下来做这几件事：

• 把所有FD列在纸上，用Armstrong公理验证（比如有没有A→B和B→A同时存在，但A、B不是同一属性组的矛盾情况）。
• 用闭包算法计算每个属性组的闭包，确认候选键的正确性——别光凭感觉猜，要实打实算出来。

2. 手动推导符合要求的3NF结构 #

别指望工具帮你拆表，自己按照规范化步骤来：

• 先拆出2NF：消除非主属性对候选键的部分依赖，把依赖候选键某一部分的属性单独建表。
• 再拆出3NF：消除非主属性之间的传递依赖，把传递依赖的属性单独建表，用决定它的属性当主键。
• 确保每个表的主键能唯一决定表里的所有属性，所有FD都能对应到某个表的约束上。

3. 在工具里手动建表，绑定约束 #

跳过工具的自动规范化，手动创建拆分后的表：

• 在Oracle SQL Developer Data Modeler里逐个创建表，设置好主键。
• 手动添加外键约束，关联拆分后的表（比如手术安排表的surgery字段关联手术患者映射表的surgery主键）。
• 到工具的“函数依赖”面板里，为每个表手动添加对应的FD，确保工具能识别所有约束。

4. 检查工具的设置，排除限制 #

有时候工具的默认设置会拖后腿：

• 看看有没有开启“严格规范化”的选项，如果没开，工具可能会忽略一些FD。
• 确认工具是否支持复合主键的FD识别，如果不支持，可能需要调整主键的设置（比如给复合键加个唯一约束）。

5. 用工具的一致性检查验证 #

建完手动模型后，用工具的“一致性检查”功能扫一遍，看看有没有违反FD的情况，比如某个表的属性无法被主键/外键约束决定，然后调整结构直到所有FD都满足。

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