0

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

考虑描述有序树的节点表的以下设计。密钥是复合密钥。

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

设计一：

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

设计二：

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)

笔记

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

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

4

1 回答 1

1

TL;DR根据您给我们的内容进行猜测：根据您似乎如何表示树的可能的功能依赖关系（确定候选键），所有这些设计都在 5NF 中。出于标准化的原因，此处无需更改设计。

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

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

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

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

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

于 2016-01-02T08:55:06.847 回答