归一化表至5 NF

Question

我很难决定一个关系是否应该归一化为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

将此关系规范化为以下内容是否有意义：

• A，B，C
• A，B，D
• C，D

保持C，D的关系包含所有可能的组合

Answer 1

如果（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设计的查询性能，而无需放弃适当的逻辑关系设计。 但是，当然，您有时必须在性能或空间效率方面牺牲一致性。