数据库设计：分层数据

Question

我在进行规范化的关系数据库设计时很难描述一个很小的层次结构，该层次结构与典型的层次结构示例有很大的偏差，因此我不确定如何继续进行第一次处理此类问题。

我的问题如下：

保证层次结构中的每个分支深度为2、4或6级。 如果深度为2层，则层次结构如下所示：

Category / Group / Component

如果深度为4级，则如下所示：

Category / Group / Component / Group / Component

如果深度为6级，则如下所示：

Category / Group / Component / Group / Component / Group / Component

类别，组和组件各自具有自己的属性集。 使问题更加复杂的是，组件和实体A，组件和实体B以及组件和实体C之间存在关系。

我最初的想法是努力将组件保持在一个表中，但是，我一直无法提出一种可以满足此目标的标准化解决方案。

相反，我想出了一个规范化的解决方案，其中在三个可能的组件级别的每个级别都有一个单独的组件表。 但是，我对此并不满意，因为它将捕获组件和实体A，B和C之间的链接的表的数量增加了两倍（总共9个链接表，如果所有组件都在一个表中，则为3个）。

这是我想到的设计的样子：

TABLE: Group_1_Components

ATTRIBUTES: Row_ID, Category, Component

RELATES-TO: Group_1_Components_A_Links, Group_1_Components_B_Links, Group_1_Components_C_Links, Group_2_Components

---

TABLE: Group_2_Components

ATTRIBUTES: Row_ID, Group, Component, Group_1_Component_Row_ID

RELATES-TO: Group_2_Components_A_Links, Group_2_Components_B_Links, Group_2_Components_C_Links, Group_1_Components, Group_3_Components

---

TABLE: Group_3_Components

ATTRIBUTES: Row_ID, Group, Component, Group_2_Component_Row_ID

RELATES-TO: Group_3_Components_A_Links, Group_3_Components_B_Links, Group_3_Components_C_Links, Group_2_Components

9个链接表中的每个表都包含两个行ID，以解决与表A，B或C的多对多关系。

这是一个合理的设计，还是我忽略了一个更简单，更典型的解决方案？ 我研究了一些特定的设计技术，这些技术专门用于捕获关系数据库中的层次结构，尤其是邻接表，但是我不确定它们是否适合此处，也不确定它们是否是标准化的解决方案。

应该注意的是，很少会修改层次结构。 它会经常被读取，其中读取将检索所选组的所有组件或特定级别的组件。 到实体A，B和C的链接表将定期写入。

任何和所有建议都欢迎。 在此先感谢您的帮助。 布赖恩

Answer 1

我建议您对数据进行非规范化，以便您的层次结构基于组件/组实体，以便与“常规”层次结构匹配。 在这种情况下，您可以具有下表：

a）组件

b）组

c）Component_Groups-在component_id和group_id上具有唯一键，以确保每个组件和组只有一个组合

在这种情况下，您的层次结构将是：类别-> Component_Group-> Component_Group-> Component_Group

Answer 2

此类问题的另一种选择是使用自引用表。 一张桌子

具有ID，PARENT_ID和TYPE的单个表，因此您可以区分CATEGORY，GROUP和COMPONENT。

所有类别都没有PARENT_ID，然后您可以搜索其父ID等于您要深入研究的类别ID的所有子对象。