它仍然是标准化的数据库模式吗？数据库

Question

我有以下 db-schema 。

FILE、GROUP和BLOCK代表XML文件的对象结构。 FILE 是根。 GROUP 对 FILE 有 FK。 BLOCK 有一个 FK 到 GROUP，另一个 FK 到 UNIT。

UNIT 在 FILE 的上下文中对来自不同 GROUPs 的“相似”BLOCKs 进行分组。

数据库目前在 3NF 中。但我想知道哪些 UNITs 属于 FILE.id=1。为此，我必须进行一个连接所有 4 个表的查询。为了优化这个模式，我可以创建新的关系 UNIT n--FK-->1 FILE。然而，我的查询仅在优化的 db-schema 上连接了两个表。 问题来了：这个 DB（带有这个新 FK）还在 3 NF 中吗？理论怎么说？

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

或

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+

Answer 1

在您进行更改之前，尚不清楚 UNIT 表如何适应架构。

显然，在您进行更改后，您只需加入 FILE 和 UNIT 表即可知道哪些单元属于文件。

由于表处于 3NF 中，当所有功能依赖关系都由键、整个键以及只有键确定时（所以请帮帮我 Codd），因此您必须从这个角度看待您的架构。

鉴于可用信息，很可能这些表格都属于 3NF（以及 BCNF，以及 4NF 和 5NF 中的 AFAICT）。

Answer 2

我认为您的“乌鸦脚”图不支持 您的问题中概述的其他依赖项。你是怎么上来的 与1：FILE和UNIT之间有很多关系吗？

这些是您描述的功能依赖项...

• 组 -> 文件
• 块 -> 组
• 块 -> 单位

另外，我假设上述每个属性在功能上决定了一些 附加属性未出现 在任何其他功能依赖项的左侧。这些将是：

• 文件 -> 其他文件属性
• GROUP -> 其他组属性
• 块 -> 其他块属性
• 单位 -> 其他单位属性

从上述函数依赖构造一组 3NF 关系给出：

• 文件关系：（文件，其他文件属性）
• GroupRelation：（GROUP、FILE、其他组属性）
• UnitRelation：（UNIT，其他单位属性）
• BlockRelation：（BLOCK、GROUP、UNIT、其他块属性）

这和你描述的差不多。

确定与给定 FILE 相关的 UNIT 实例 需要在 FILE 上将 FileRelation 连接到 GroupRelation，然后将 GroupRelation 连接到 GROUP 上的 BlockRelation，然后 UNIT 上的 BlockRelation 到 UnitRelation。

您希望通过在模型中的某处插入新关系来避免这种多表连接 给出从 UNIT 到 FILE 的直接映射。这种关系意味着泛函 依赖：

• 单位 -> 文件

这看起来像您添加到“乌鸦脚”图中的位。添加这个引入了一个逻辑 矛盾。原始模式支持将给定的 UNIT 与 多个 FILE 实例。如：

• 文件关系（F1，...）
• 文件关系(F2, ...)
• GroupRelation(G1, F1, ...)
• GroupRelation(G2, F2, ...)
• BlockRelation(B1, G1, U1, ...)
• BlockRelation(B2, G2, U1, ...)
• UnitRelation(U1, ...)

UNIT 实例 U1 与 FILE 实例 F1 和 F2 相关。鉴于这种情况，无法支持 UNIT -> FILE 功能依赖 或者原始的功能依赖集不完整，架构不完整 在 3NF 中。

此时需要判断现实世界是否支持FILE -> UNIT 依赖与否。如果是这样，那么原始模型不在 3NF 中，而且更多 模式的返工是有序的。如果不支持依赖项，那么最好的说法是：

• 文件，单位 -> 什么都没有

及对应关系：

• FileUnit：（FILE，UNIT）

是一种反规范化，因为它的内容可能是通过现有的表功能依赖导出的。

============================================== ======================================

编辑

根据对这个和其他答案做出的许多 cmets，看来：

• 单位 -> 文件

是真正的函数依赖，函数依赖：

• 块 -> 单位

虽然不正确，但一定是多余的。我相信正确的 3NF 集 现在这个模型的关系是：

• 文件关系：（文件，其他文件属性）
• GroupRelation：（GROUP、FILE、其他组属性）
• UnitRelation: (UNIT, FILE, other-unit-attributes)
• BlockRelation：（BLOCK、GROUP、其他块属性）

注意 UNIT 外键已从 BlockRelation 中删除。 这是因为 UNIT -> FILE FD 使它变得多余。这 (BLOCK, UNIT) 关系现在通过在 FILE 上将 UnitRelation 连接到 FileRelation 来形成 然后 FileRelation 到 FILE 上的 GroupRelation，然后 GroupRelation 到 GROUP 上的 BlockRelation。

由于未说明，原始架构不在 3NF 中 功能依赖：UNIT -> FILE。上面提出的一组关系是 在 3NF 中。

注意：在规范化模式时，需要说明每个功能依赖关系 在前面。缺少一个可以改变整个画面！

Answer 3

从提供的信息看来，这是一个真正的并行层次结构。在此基础上，我相信提议的修正模式仍然会被规范化为 3NF。