当F.E. Codd提出relational model时，已建立的时间数据库使用了hierarchical model。我的理解是，关系模型被认为是对分层方法的重大改进。
我的直觉是这个＆＃34;有意义＆＃34;原因有几个。
然而，虽然感觉关系数据模型具有优势，但我希望能够深入了解为什么它在当时被认为是显着优势的，并且可能仍然存在。
我真的很欣赏某些提炼形式的论点，或理想情况下，一篇或多篇论文或其他文件，或经过这背后推理的规范参考。
为清楚起见，我不会询问这两种方法的实际实现，或者它们在存储或计算方面的相对资源使用情况，除非这对答案非常重要。
感谢。
答案 0 :(得分：8)
说'＃34;建立的时间数据库使用分层模型＆＃34;
是不对的。首先（对于挑选），它的数据库管理系统不使用某些物理结构。 ＆＃34;数据库＆＃34; - 即数据库设计可能会使用各种抽象。无论最终的物理平台如何，实体 - 关系建模作为一种设计工具仍然很受欢迎。
其次，当时的等级模型通常适用于“大铁”。大型数据库indexed-sequential在以前被称为“小型计算机”的过程中更为常见。 （如DEC PDP-8 / -11; IBM System / 34，/ 36; ICL 1900 / ME29; Honeywell DPS4 / DPS7）。
我们可能会说磁盘上的索引顺序组织是使用批量逐个副本的打孔卡或磁带系统生成的。这就是＆＃34;顺序＆＃34;来自。
你说你不想问实际的实施;但答案完全是实际实施。顺序读取磁盘比随机访问（需要读取头跳转）更有效。这就是为什么与磁盘相比，内存被称为＆＃34;随机存取存储器＆＃34;。 （在RAM变得如此便宜之前，我们可以将整个数据库保存在内存中。）
类似地，组织层次模型以提供对常用查询路径的快速访问。层次结构将紧密链接的节点放在同一物理磁盘上。因此，很容易从客户导航到该客户的订单到该订单的项目行。
缺点是很难在[＆＃39;层次结构 - 例如，查找项目P5432的所有订单行，而不管哪个客户/订单。 （此外，如果您想要检索订购P5432的客户，则需要向后推进层次结构。如果它们都在同一块磁盘上，那么希望您不要＃39 ; t需要看得太远/可能它在加载到RAM的同一个磁盘桶中。）
类似地，索引顺序组织支持一个特定索引 - 主键。如果您想按客户名称而不是数字进行搜索，则需要使用“二级索引”。与各种丑陋的组织，以保持索引桶在数据附近的某处。而臭名昭着的桶溢出＆＃39;这可以阻止一台机器死机，因为你在一个名字中修改了一个十分小小的weensy拼写错误，所以将它转移到一个完全不同的字母位置。
（顺便说一句，NoSQL数据库，只有一个密钥的键值存储，似乎注定要落入所有与二级索引相关的陷阱。他们需要第二个键值存储来提供替代索引，各种乐趣让他们保持同步。回到未来！）
Codd在实施关系模型时遇到的最大问题是说服IBM高层，该模型可以通过多条访问路径有效地支持查询。你会看到很多早期的论文都在谈论抽象导航的问题。远离查询编写者/程序员。事实上，最初的System / R设计有很多妥协，因为
a）IBM工程师只是不了解Codd所谈论的数学抽象; b）他们害怕傻了，它会像狗一样表现，他们会失去工作。[报告！个人意见：但是这个小组很久以后就聚集在一起，并且在网络上有一些回忆。]这些妥协在SQL中持续存在至今;坦率地说，这应该是一堆有趣的证据。
Codd的模特是如何成功的（或者更确切地说是SQL模型，不是 Codd＆＃39;）
磁盘技术得到改善 - 特别是寻求时间
有人想出了散列索引和b-tree，并将表中的所有索引保存在单独的内存中，与实际数据保持一致;而不是试图把它像磁铁连锁店一样。
拉里·埃里森嗅出了正在发生的事情，并偷走了IBM工程团队的成员，在甲骨文建立同样的东西。 Michael Stonebreaker也组建了Ingres。
比赛开始了！没有时间停下来让一切正常。实施您所拥有的（即SQL概念证明）并将其推向市场，准备好与否。 （听起来像一个熟悉的故事？）
关于关系模型优越性的观点都很好。它们基本上遵循标准化技术。不过，我会说，在过去的70年代和80年代，他们并没有得到很好的理解。模式设计看起来很像分层或索引顺序数据模型，只是转换为＆＃39; flat＆＃39;表。特别是，有一种设计“广泛”的倾向。表格将一块磁盘上的所有内容汇集在一起，而不是垂直分区。 （因为担心将分区连接在一起会导致性能下降。）这意味着许多不适用或者不知道＆＃39;字段 - 这是SQL的可憎之处。
所以你的改进＆＃34;目前尚未部分实现。也许有一天，我们会看到一个DBMS设计为关系模型。现在我们必须忍受SQL。
答案 1 :(得分：3)
AntC为super answer提供了许多历史背景。我想从评论中的链接中收集答案，以确保他们不会错过。
绝对精彩的读物是Codd's 1981 Turing Award Lecture的写作。感谢你对suggesting it的回复。
在论文中，Codd提出了针对当代数据库的案例：
这些系统给应用程序编程人员带来了许多与他们的数据检索和操作任务无关的概念，迫使他们在不必要的低级别结构细节上思考和编码（＆＃34;所有者成员集＆＃34; of CODASYL DBTG是一个杰出的例子。
没有为一次处理多个记录提供任何命令 - 换句话说，DBMS不支持集合处理，因此，程序员被迫根据通常不必要的迭代循环进行思考和编码（这里我们在传统的数学意义上使用＆＃34; set＆＃34;而不是CODASYL DBTG的链接结构意义};
最终用户与数据库直接交互的需求，特别是未预料到的交互，未得到充分认识。假设查询功能是稍后可以添加到DBMS的东西。
考虑到所描述的问题，在Codd提出他的替代要求之后不久 - 他希望它实现的目标。
导致关系模型的研究工作最重要的动机是在数据库管理的逻辑和物理方面（包括数据库设计，数据检索和数据操作）之间提供清晰明确的界限。我们称之为数据独立目标。
第二个目标是使模型在结构上变得简单，以便各种用户和程序员可以对数据有共同的理解，因此可以相互通信关于数据库。我们称之为传播目标。
第三个目标是引入高级语言概念而不是特定语法I，以使用户能够一次在大块信息上表达操作。这需要为面向集合的处理提供基础，即，能够在单个语句中一次表示多组记录的处理。我们称之为集处理目标。
还有其他目标，例如为数据库组织和管理提供合理的理论基础，但这些目标与我们目前的生产力主题不太相关。
最后他介绍了关系模型并展示了它如何满足预期目标并解决了对当代系统的反对意见。
在我看来，这篇论文仍然非常相关。
它强烈地说明了为什么Codd提出了Relational方法，它实际上抛弃了当前系统的挑战，以满足他的期望和希望。我认为它们不足，尤其是我们倾向于在异构/多语言客户端服务器系统中部署的方式。我们可以声称他们克服了Codd的反对意见吗？
对于只熟悉该领域的人来说，这篇论文是一本平易近人且容易阅读的文章。
本文最后一个非常特别的摘录是对正统（强调我的）的警告：
关系代数，包括这些和其他运算符，旨在作为权力的尺度。它并非旨在成为所有关系系统应遵守的标准语言。关系模型的集合处理目标旨在通过至少具有关系代数功效的数据子语言来满足，而不使用迭代或递归语句。
因此，Codd并未声称关系模型是最佳或唯一的方法。他说它有实现目标的必要属性，但不一定是数据库设计的最后一个词。
在关系数据库上查看Codd's Original Paper也是值得的。感谢philipxy for this。它也是一本可读的论文，有充分的理由和背景。它确实有更正式的内容，但如果您对关系数据库有一定的了解，那么您无法获得任何帮助。