我很难决定是否应该将关系规范化为 5 NF。
可以说我有一个由以下组成的所有关键关系:
A B C D
- A 和 B 是另一个表的外键,其中 A 和 B 作为主键
- C 可以是 X1、X2、X3
- D 可以是 Y1、Y2、Y3
在该关系中,C 和 D 是彼此的组合。
示例数据:
- 1、2、X1、Y2
- 3、4、X2、Y2
- 5、6、X1、Y3
- 7、8、X2、Y1
将这种关系规范化为以下是否有意义:
- 甲、乙、丙
- 甲、乙、丁
- 丙、丁
其中保持 C、D 的关系包含所有可能的组合
我很难决定是否应该将关系规范化为 5 NF。
可以说我有一个由以下组成的所有关键关系:
A B C D
在该关系中,C 和 D 是彼此的组合。
示例数据:
将这种关系规范化为以下是否有意义:
其中保持 C、D 的关系包含所有可能的组合
如果 (A,B) 是关系中的一个键(假设这由星号表示),那么它已经在 4NF 中,因为 C 和 D 在功能上都依赖于 (A,B)。分解成 5NF 然后简单地是
(A,B,C)
(A,B,D)
您不需要进一步的关系(C,D)。快速检查 SQL 确认您的示例数据:
create table t1(A,B,C);
create table t2(A,B,D);
insert into t1 values (1,2,'X1'), (3,4,'X2'), (5,6,'X1'), (7,8,'X2');
insert into t2 values (1,2,'Y2'), (3,4,'Y2'), (5,6,'Y3'), (7,8,'Y1');
select * from t1 natural join t2;
A B C D
---------- ---------- ---------- ----------
1 2 X1 Y2
3 4 X2 Y2
5 6 X1 Y3
7 8 X2 Y1
至于分解到您的关系是否有意义:通常,我总是会选择确保最大数据一致性的关系设计。在您的情况下,从 4NF 到 5NF 并不能保护您免受任何进一步的插入/更新/删除异常。您只需对数据进行水平分区,从关注点分离的角度来看,这可能是有意义的,但从数据一致性的角度来看,这不是必需的。
编辑:添加了对密钥为 (A,B,C,D) 的情况的讨论
如果 (A,B,C,D) 是您关系中的关键,并且数据中的项目连接依赖项就是您在问题中提出的那些( R = (A,B,C) * (A,B ,D) * (C,D),不仅适用于您的示例数据,而且作为数据完整性规则),那么 5NF 模式将强制您的数据一致性,而您的原始模式不会(您可以有插入/更新/删除异常)。因此,从逻辑的角度来看,您应该使用 5NF 模式,否则您必须在应用程序级别强制执行数据完整性。
像往常一样(对于 3NF 也是如此),可能会有特定的性能要求迫使您对架构进行非规范化(例如,在查询数据时保存连接),但除非被迫这样做,否则我总是会尽力而为可能的概念模式。对于许多 DBMS,甚至可以通过使用适当的索引和/或增量物化视图在物理级别上提高 5NF 设计的查询性能,而无需放弃适当的逻辑关系设计。但当然,在某些时候,您可能不得不以一致性换取性能或空间效率。