1

我有以下 db-schema 。

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

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

数据库目前在 3NF 中。但是我想知道哪些UNIT属于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  |
           +---------+
4

3 回答 3

1

From the information supplied, it appears that this is a true parallel hierarchy. On this basis, I believe that the proposed amended schema would still be normalised to 3NF.

于 2010-09-24T11:07:21.427 回答
0

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

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

由于表在 3NF 中，当所有功能依赖项都由键、整个键以及除了键确定（所以帮助我 Codd）时，您必须从这个角度看待您的模式。

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

于 2010-09-23T13:10:32.503 回答
0

我认为您的“乌鸦脚”图不支持您问题中概述的其他依赖项。您是如何提出 FILE 和 UNIT 之间的 1:Many 关系的？

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

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

此外，我假设上述每个属性都在功能上确定了一些其他属性不会出现在任何其他功能依赖项的左侧。这些将是：

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

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

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

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

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

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

  • 单位->文件

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

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

UNIT 实例 U1 与 FILE 实例 F1 和 F2 相关。在这种情况下，不能支持UNIT -> FILE功能依赖，或者原始的功能依赖集不完整并且模式不在 3NF 中。

此时你需要解决现实世界是否支持FILE -> UNIT 依赖。如果是这样，那么原始模型不在 3NF 中，并且需要对模式进行更多修改。如果不支持依赖项，那么您可以说的最好的方法是：

  • 文件，单位->没有

以及对应关系：

  • 文件单位：（文件，单位）

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

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

编辑

根据对此和其他答案的许多评论，看来：

  • 单位->文件

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

  • 块->单元

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

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

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

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

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

于 2010-09-23T15:04:13.223 回答