1

我很难决定是否应该将关系规范化为 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 的关系包含所有可能的组合

4

1 回答 1

0

如果 (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 设计的查询性能,而无需放弃适当的逻辑关系设计。但当然,在某些时候,您可能不得不以一致性换取性能或空间效率。

于 2013-11-06T22:52:21.757 回答