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

Question

我有以下数据库模式。

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

UNIT 将FILE上下文中不同GROUP的“相似”BLOCK分组。

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

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

或者

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

Answer 1

从提供的信息来看，这似乎是一个真正的并行层次结构。在此基础上，我相信所提议的修改模式仍将标准化为3NF。

Answer 2

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

显然，进行更改后，要知道哪些单元属于文件，只需连接 FILE 和 UNIT 表即可。

由于表处于 3NF 状态，因此所有功能依赖项均由键、整个键以及除了键之外的任何内容决定（所以请帮助我 Codd），因此您必须从这个角度来看待您的模式。

鉴于现有信息，这些表很可能全部采用 3NF（BCNF 和 AFAICT 也采用 4NF 和 5NF）。

Answer 3

我不认为你的“鱼尾纹”图支持
您的问题中概述的其他依赖项。你是怎么上来的
FILE 和 UNIT 之间的 1:Many 关系？

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

• GROUP -> 文件
• 块 -> 组
• 块 -> UNIT

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

• FILE ->其他文件属性
• GROUP ->其他组属性
• BLOCK ->其他块属性
• UNIT -> other-unit-attributes

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

• FileRelation: (FILE, other-file-attributes)
• GroupRelation: (GROUP, FILE，其他组属性）
• UnitRelation：（UNIT，其他单元属性）
• BlockRelation：（BLOCK，GROUP，UNIT，其他块属性）

这几乎与您所描述的相符。

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

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

• UNIT -> 文件

这看起来像您添加到“鱼尾纹”图表中的部分。添加这个引入了一个逻辑
矛盾。原始模式支持具有与以下内容相关的给定UNIT
多个 FILE 实例。如：

• FileRelation(F1, ...)
• FileRelation(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 -> 单位
依赖与否。如果是这样，那么原始模型不属于 3NF 并且更多
架构的重新设计已按顺序进行。如果不支持依赖项，那么您最好说的是：

• FILE、UNIT -> 什么都没有

以及对应的关系：

• FileUnit: (FILE, UNIT)

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

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

编辑

基于数字对此和其他答案的评论似乎是：

• UNIT -> FILE

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

• BLOCK -> UNIT

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

• FileRelation: (FILE, other-file-attributes)
• GroupRelation: (GROUP, FILE, other-group-属性）
• UnitRelation：（UNIT、FILE、其他单元属性）
• BlockRelation：（BLOCK、GROUP、 other-block-attributes)

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

由于未说明，原始模式不在 3NF 中
功能依赖：UNIT -> 文件。上述建议的关系集是
在3NF中。

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