relational-database - 关系v分层数据模型

Question

当F.E. Codd提出relational model时，当时建立的数据库使用了hierarchical model。我的理解是，关系模型被认为是对分层方法的重大改进。

我的直觉是，出于某些原因，这是“合理的”。


关系模型似乎是“查询不可知的”，因为它不是反映您查询方式的数据形状，而是结构化的，因此可以相对轻松地提出任何问题。
关系模型还使可变性变得简​​单。您可以通过向表中添加行（向集合中添加元组）或删除它们来断言或撤消事实。相反，在分层设置中，您需要添加或从其他对象中删除，这会引入一些次要问题，例如，如果父对象不存在，则需要创建父对象，如果它为空，则需要删除父对象。
关系模型可以轻松地建模不容易适合父子方法的关系，例如三个实体之间的关系。
关系模型似乎更适合架构增长，因为可以使用新表添加新的事实。谨慎执行此操作无需破坏现有表（和事实）或依赖于它们的服务。


但是，尽管感觉关系数据模型具有优势，但我想对为什么它在当时肯定被认为是显着优越的原因有一些见解，并且大概仍然如此。

我真的很欣赏某种形式的论点，或者理想情况下，一篇或多篇论文或其他文档，或者经过其背后推理的规范参考文献所引起的争论。

为了清楚起见，我不是在问哪种方法的实际实现，也不是在存储或计算方面它们的相对资源使用情况，除非这对答案很重要。

谢谢。

Answer 1

说“当时建立的数据库使用了层次模型”并不是很正确。

首先（很挑剔），是/不使用某些物理结构的数据库管理系统。 “数据库”-即数据库设计可以使用各种抽象。不管最终的物理平台如何，实体关系建模作为一种设计工具一直很流行。

其次，当时“大铁”大型数据库通常使用分层模型，而indexed-sequential在过去称为“微型计算机”（例如DEC PDP-8 / -11； IBM System / 34）上更为普遍。 ，/ 36； ICL 1900 / ME29；霍尼韦尔DPS4 / DPS7）。

我们可以说，磁盘上的索引顺序组织源于使用逐批更新的打孔卡或磁带系统。这就是“顺序”的来源。

您说您不想询问实际的实现；但是答案全在于实际的实现。顺序读取磁盘比随机访问（后者需要读取头跳动）更有效。这就是为什么与磁盘相比，内存被称为“随机访问内存”。 （很久以前，RAM变得如此便宜，我们可以将整个数据库保留在内存中。）

类似地，组织了层次模型以提供对常用查询路径的快速访问。层次结构将紧密链接的节点放在同一物理磁盘补丁上。因此，从客户到该客户的订单到该订单的项目行之间导航很容易。

不利的一面是，很难在整个层次结构中进行导航-例如，查找项目P5432的所有订单行，而与哪个客户/订单无关。 （此外，如果您随后要检索正在订购P5432的客户，则需要在层次结构上“向后”工作。如果它们全部位于同一磁盘补丁中，则希望您不必看起来太远/也许它在其中将相同的磁盘存储桶加载到RAM。）

同样，索引顺序组织偏爱一个特定的索引-主键。如果要按客户名称而不是编号进行搜索，则需要具有各种丑陋组织的“二级索引”，才能将索引存储桶保留在数据附近。还有臭名昭著的“存储桶溢出”现象，当您修改名称中的一个青少年的拼写错误时，可能会阻止机器死机，从而将其转移到完全不同的字母位置。

（顺便说一下，NoSQL数据库是仅具有一个键的键值存储，似乎注定会陷入与二级索引有关的所有陷阱。它们需要第二个键值存储来提供具有各种索引的备用索引。让他们保持同步很有趣。回到未来！）

Codd在实施关系模型时遇到的最大问题是说服IBM高层认为该模型可以有效地支持通过多个“访问路径”进行查询。您会看到他的许多早期论文都在谈论从查询编写器/编程器中抽象“导航”。实际上，原始的System / R设计有很多折衷之处，因为

a）IBM工程师只是不理解Codd所说的数学抽象；

b）他们害怕狗屎会像狗一样无聊，他们会丢掉工作。

[啊！个人意见：但是该小组聚在一起很久了，网上有些地方让人回想起。]这些折衷一直持续到“直到SQL为止。坦率地说，这是一堆杂物，应该仅仅作为一个有趣的概念证明而被杀死。

Codd的模型是如何成功的（或者更确切地说是SQL模型，而不是Codd的）？


磁盘技术得到改善-尤其是寻找时间
有人弄清楚哈希索引和b树，并​​将表的所有索引保存在与实际数据分开的内存中；而不是像磁悬浮磁带序列存储一样尝试保存它。
拉里·埃里森（Larry Ellison）嗅到即将发生的事情，并偷走了IBM工程团队的成员在Oracle建立同样的东西。迈克尔·斯通布雷克（Michael Stonebreaker）也成立了Ingres。


比赛开始了！没有时间停下来让一切都变得正确。实施您所拥有的（即SQL的概念证明）并将其匆匆推向市场，无论是否准备就绪。 （听起来像一个熟悉的故事？）

您对关系模型的优越性的观点都是精心设计的。它们本质上是根据规范化技术得出的。我要说的是，在上世纪70年代/ 80年代后期，人们对它们还没有很好的理解。模式设计看起来很像分层或索引顺序数据模型，只是被转换为“平面”表。特别是，有一种趋势是设计“宽”表，以将我们所了解的有关“客户”的所有信息聚集在一个磁盘补丁上，而不是垂直分区。 （由于担心将分区连接在一起会对性能造成影响。）这意味着很多不适用或“未知”的字段-这是SQL空值的可憎之处。

因此，您的“改进”还只是部分实现。也许有一天，我们会看到为关系模型设计的DBMS。现在，我们不得不忍受SQL。