具有复合键的有序树的表设计

Question

在考虑数据库规范化规则时首选哪种表设计：

考虑以下用于描述有序树的节点表的设计。键是复合键。

• ck：复合键
• parent：父节点
• next：下一个节点，其中next.parent = parent.
  （这定义了一个前向链表）
• sk：代理键

设计1：

node(ck_x, ck_y, parent_ck_x, parent_ck_y, next_ck_x, next_ck_y)

设计2：

node(sk, ck_x, ck_y, parent_ck_x, parent_ck_y, next_ck_x, next_ck_y)

设计 3：

node(sk, ck_x, ck_y, parent_sk, next_sk)

第一个设计有 6 列。第二种设计增加了一个替代键，有 7 个列。第三种设计有 5 个列，它使用代理项来保存一列。

是否有任何规范化规则（或其他数据库设计规则）偏好一种设计而不是其他设计？

更新

替代设计：子类型节点表、isParent 标志、嵌套集。这些设计具有更大的读/写复杂性。

设计 4：

• 此设计将表拆分为 3 个表。父表和下一个表包含来自节点表的键的互斥子集。它为每个节点使用2+4=6 列。

  node(ck_x, ck_y)

  parent(ck_x, ck_y, parent_ck_x, parent_ck_y)

  next(ck_x, ck_y, next_ck_x, next_ck_y)

设计 5：

• 此设计使用 isParent 标志来指示下一项是父项。它使用4+1=5 列，1 列只是一点点。这比设计 3) 中使用的 5 列空间小

  node(ck_x, ck_y, next_ck_x, next_ck_y, isParent)

设计 6：

• 此设计使用嵌套集来创建有序树。复合键不再用于定义父级或子级的顺序。它使用2+2=4 列。但是下限列和上限列都应该使用sizeof(ck_x)+sizeof(ck_y)，这等于设计1中使用的6列的空间。

  node(ck_x, ck_y, lowerBound, upperBound)

更新

设计 7：

• 这使用索引来表示节点的位置。

  node(ck_x, ck_y, parent_ck_x, parent_ck_y, index)

备注

• 使用前一个节点 i.s.o.与插入和更新相比，下一个节点减少了对单个插入的创建和添加。

• 规范化与列或表的数量无关。

Answer 1

TL;DR 根据您提供给我们的内容进行猜测：根据可能的功能依赖关系（确定候选键）以及您似乎如何表示树，所有这些设计都在 5NF 中。这里的设计不需要因为标准化而改变。

---

规范化用其他表替换一个表而不引入新列。对 BCNF 的规范化需要了解所有的函数依赖关系；除此之外的规范化需要了解连接依赖关系。这需要通过在表格中了解行对情况的说明以及可能出现的情况。 （如果我们知道某些列是唯一的，那么我们就知道它们在功能上决定了所有列。）

首先选择可以描述可能出现的任何情况并表达对这些情况的查询的设计。规范化可能会改进设计（在减少更新异常或某些冗余方面），但设计的适当性或质量的其他方面与规范化无关。必须谨慎选择树结构关系设计，以适应预期用途和 DBMS 特性。

PS 1 规范化不引入代理项。功能依赖很重要；你没有给他们。候选键很重要；你没有给他们。 （主键仅在它们是候选键时才重要。）阅读规范化的基本概念和步骤。

PS 2 规范化未解决对共享同一父级的链表兄弟的约束。仅仅因为有重复的值，就不需要冗余；冗余是关于 rows 在表中或不在表中重复的语句。 Re "redundancy". 事实上，描述树的显而易见的基本关系方式只是一张表“父 P 有子 C”或“父 P 有第 N 个子 C”。您正在以关系方式表示一棵树。不要以关系方式表示树的（非关系）表示。

PS 3 您对列的数量和大小/空间（包括代理键的使用）的关注几乎肯定是错误的。只需根据您的查询和更新进行最直接的设计即可。 （同样，你没有描述。）