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 回答