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设计改进查询性能，而不会放弃适当的逻辑关系设计。但是，当然，您可能必须在某些时候交换性能或空间效率的一致性。

将表规范化为5 NF

1 个答案: