论文：https://pan.baidu.com/s/1mJPcyuPrNuzTkEkv6MDvCg
[zv2]本文总结了35年的数据模型建议，分为9个不同的时代。我们讨论了每个时代的提议，并表明只有很少的基本数据建模思想，而且大多数已经存在了很长时间。后来的提案不可避免地与先前的某些提案有很强的相似之处。因此，研究前人的建议是值得一试的。
[zv3]此外，我们还介绍了每一个时代对这些建议进行探索的经验教训。大多数目前的研究人员在之前的许多时代都不在场，而且对以前所学的知识了解有限(如果有的话)。有句古话说，不了解历史的人注定要重复历史。凭“古老的历史”,未来我们希望允许研究人员为了避免历史重演。
[zv4]不幸的是，当前XML时代的主要提议与70年代早期的CODASYL提议惊人地相似，后者由于其复杂性而失败。因此，当前的时代正在重演历史，“what goes around comes around”。希望下一个时代会更聪明。
[zv5]数据模型在20世纪60年代末就出现了，在其间的35年里，提案以惊人的规律继续着。当前的许多提议都来自于研究人员太年轻，无法从先前的讨论中吸取教训。本文的目的是总结35年的“进步”，并指出应该从这个漫长的过程中学到什么。
[zv6]9个年代: 等级制度(IMS): 60年代末和70年代的网络(CODASYL): 70年代的关系:70年代和80年代初的实体关系:70年代的扩展关系:80年代末和80年代的语义:70年代末和80年代初的面向对象:80年代末和90年代初的对象关系:80年代末和90年代初
半结构化(XML): 90年代末期至今
[zv7]我们还将尝试使用统一的术语集合，再次尝试限制可能发生的混乱。
[zv8]在本文的大部分内容中，我们将使用来自[CODD70]的供应商和部件的标准示例，图1以关系形式编写了这个示例。在这里，我们有供应商信息，零件信息和供应关系，以表明供应商可以提供零件的条款。
[zv9]IMS在1968年前后发布,最初有一个层次数据模型。它理解了一个记录类型的概念,它是一个以其相关的数据类型集合命名字段的集合。记录类型的每个实例都被迫服从记录类型定义中所示的数据描述。此外,指定字段的一些子集必须单独指定一个记录实例,即它们被要求成为密钥。最后,记录类型必须在树中排列,这样每个记录类型(除了根)都有一个唯一的父记录类型。IMS数据基是一个记录类型实例的集合,这样每个实例,除了根实例,都有一个正确的记录类型的单亲。
[zv10]树结构数据的这种需求对我们的示例数据提出了挑战，1信息重复2生存取决于parent
[zv11]IMS之所以选择分层数据库，是因为它便于使用简单的数据操作语言DL/1。IMS数据库中的每个记录都有一个层次顺序键(HSK)。基本上，HSK是通过连接祖先记录的键，然后添加当前记录的键来派生的。HSK定义了IMS数据库中所有记录的自然顺序，基本上是深度优先、从左到右。DL/1密切使用HSK顺序来表示命令的语义。例如，“get next”命令以HSK顺序返回下一个记录。HSK指令的另一种用法是“在父类中获取下一个”命令，
[zv12]尽管人们可能会认为第二种解决方案明显低于第一个解决方案;事实上,如果数据基础上只有一个供应商(第16个),那么第二个解决方案将比第一个解决方案更好。DL / 1程序员必须做出这样的优化权衡。
[zv13]IMS支持四种不同的层次数据存储格式。基本的记录可以是:顺序存储用记录的键在一个树中索引,使用记录的关键从根中发现依赖的记录物理顺序的各种指针。
[zv14]一些存储组织对DL/1命令施加限制。例如，纯顺序组织将不支持记录插入。因此，它仅适用于批处理环境，其中更改列表按HSK顺序排序，然后进行一次数据库遍历，将更改插入到正确的位置，并编写新的数据库。这通常被称为“老主人-新主人”处理。此外,存储组织,散列根记录关键不能支持“下一个”,因为它没有简单的方法来返回散列的记录
[zv15]无论在物理级别执行什么调优，数据库应用程序继续运行的能力都被称为物理数据独立性。物理数据独立性非常重要，因为DBMS应用程序通常不会一次编写完。随着新程序被添加到应用程序中，调优需求可能会发生变化，通过更改存储组织可以获得更好的DBMS性能。IMS选择限制物理数据独立性的数量。此外，应用程序的逻辑需求可能会随着时间而改变。由于新的业务需求或新的政府需求，可能会添加新的记录类型。还可以将某些数据元素从一个记录类型移动到另一个记录类型。IMS支持一定程度的逻辑数据独立性，
[zv16]基本上，图3的结构实际上是存储的，可以注意到这个结构中没有冗余，也没有不良的存在依赖性。
[zv17]一般来说，IMS允许将两个不同的树结构物理数据库“嫁接”到一个逻辑数据库中。使用逻辑数据库有很多限制(例如在使用delete命令时)，而且相当复杂，但它是在IMS中表示非树结构数据的一种方法。
[zv18]这些逻辑数据库的复杂性目前被认为是决定10年后IBM如何决定支持关系数据库的关键。
我们将总结到目前为止的经验教训，然后转向CODASYL建议。
第1条:物理和逻辑数据独立性是非常可取的
第2条:树结构数据模型是非常严格的
3:对树结构数据进行复杂的逻辑重组是一个挑战
4:一次记录的用户界面迫使程序员进行手工查询优化，这通常是ha进入翻译页面
[zv19]1969年，CODASYL(数据系统语言委员会)委员会发布了他们的第一份报告[CODA69]，随后在1971年[CODA71]和1973年[CODA73]发布了语言规范。CODASYL是一个专门的委员会，支持网络数据模型和记录数据操作语言。
[zv20]译文：这个模型将记录类型的集合(每个都有键)组织到网络中，而不是树中。因此，一个给定的记录实例可以有多个父实例，而不是像IMS中那样只有一个。因此，我们的供应商部件供应示例可以用图5中的CODASYL网络表示。
[zv21]CODASYL网络是一组命名记录类型和命名集类型的集合，它们构成一个连通图。此外，必须至少有一个入口点(记录类型不是任何集合中的子记录类型)。CODASYL数据库是记录实例和遵循此网络描述的设置实例的集合。
[zv22]这个解决方案需要三个二进制集来表示一个三向关系，这有点不自然。虽然CODASYL数据模型比IMS灵活得多，但是仍然有局限性。CODASYL数据操纵语言是一种每次记录的语言，通过这种语言，您可以在一个入口点进入数据库，然后通过以下设置导航到所需的数据。要找到供应商16在CODASYL提供的红色配件，可以使用以下代码:
[zv23]CODASYL建议将每个入口点的记录散列在记录中的键上。提出了几种集合的实现方法，它们需要父记录和子记录之间的指针的各种组合。
[zv24]CODASYL建议基本上没有提供物理数据独立性。例如，如果将供应商记录的键(以及散列存储)从sno更改为其他内容，则上述程序将失败。此外，不提供逻辑数据独立性，因为模式不能在不影响应用程序的情况下更改。
[zv25]转向网络模型的优势在于，实现图形结构数据(如我们的示例)不需要组装件。然而，CODASYL模型要比IMS数据模型复杂得多。在IMS中，程序员在层次空间中导航，而CODASYL程序员在多维超空间中导航。在IMS中，程序员必须只关心他当前在数据库中的位置和单个祖先的位置(如果他正在做“在父进程中获取下一步”)。相反，CODASYL程序员必须跟踪:
[zv26]因此，CODASYL建议增加了复杂性，以方便地表示非层次数据。CODASYL提供的逻辑和物理数据独立性比IMS更差。CODASYL还有一些更微妙的问题。例如，在IMS中，每个数据库可以独立地从外部数据源加载。
然而，在CODASYL中，所有数据通常都在一个大网络中。这个大得多的对象必须一次装载所有的东西，导致非常长的装载时间。此外，如果CODASYL数据库损坏，则需要从转储中重新加载所有数据。因此，与将数据划分为独立的数据库集合相比，崩溃恢复往往更为复杂。
此外，CODASYL负载程序往往很复杂，因为需要将大量记录组装成一组，这通常需要许多磁盘查找。因此，仔细考虑负载算法以优化性能通常是很重要的。因此，没有通用的CODASYL负载实用程序，每个安装都必须编写自己的程序。这种复杂性在IMS中不那么重要。
[zv27]因此，在CODASYL学到的教训是:
第五条:网络比层次结构更灵活，但更复杂
第六条:加载和恢复网络比层次结构更复杂
[zv28]关系时代
[zv29]在这种背景下，Ted Codd在1970年提出了他的关系模型[CODD70]。多年后，在与他的交谈中，他指出，他的研究的驱动力是IMS程序员在发生逻辑或物理更改时，花费大量时间对IMS应用程序进行维护。因此，他专注于提供更好的数据独立性。
[zv30]他的建议有三方面:
1.将数据存储在一个简单的数据结构(表)中
2.通过高级的一次一次的DML访问它不需要物理存储建议
3.使用简单的数据结构，可以更好地改变逻辑数据独立性。使用高级语言，可以提供高度的物理数据独立性。因此，不需要像IMS和CODASYL中那样指定存储建议。进入翻译页面
[zv31]此外，关系模型还有一个额外的优点:它足够灵活，可以表示几乎任何东西。因此，困扰IMS的存在依赖性可以通过图1中前面所示的关系模式轻松处理。另外，CODASYL中比较难的三方婚姻仪式在关系模型中很容易表示为:
[zv32]a）没有什么比CODASYL更复杂的了
b) CODASYL不提供可接受的数据独立性
c)一次性记录编程太难优化
d) CODASYL和IMS不够灵活，无法轻松地表示常见情况(如婚礼)
[zv33]早期的关系系统拥有自己的VAX市场。这给了他们时间来提高他们产品的性能，VAX市场的成功与关系系统的成功密不可分。
[zv34]所有的动作都发生在高端操作系统MVS上。在这里，IBM继续销售IMS, Cullinaine成功地销售了IDMS，而关系系统则不见踪影。
[zv35]IBM发出的关于关系系统非常严肃的信号是一个分水岭。首先，它结束了一次又一次的“大辩论”。由于当时IBM拥有巨大的市场力量，他们实际上宣布关系系统赢了，CODASYL和层级系统输了。不久之后，库里纳因和IDMS进入了市场。其次，他们有效地宣布SQL是事实上的标准关系语言。其他(更好的)查询语言，如QUEL，立即就死了。要对SQL的语义进行严厉批评，请参阅[DATE84]
[zv36]由于语义问题，在逻辑数据库的IMS概念上实现SQL太难了。因此，IMS中逻辑数据库的复杂性多年后再次困扰IBM。因此，IBM被迫转向双数据库策略，并宣布这场大辩论的赢家。
[zv37]综上所述，CODASL与关系的争论最终由三个事件解决:a) VAX的成功b) CODASYL引擎的不可移植性c) IMS逻辑数据库的复杂性
[zv38]从这个时代吸取的教训是:
教训7:无论数据模型如何，设置-时间语言都是好的，因为它们提供了更好的物理数据独立性。
教训8:简单数据模型比复杂数据模型更容易实现逻辑数据独立性。
9:技术争论通常是由市场上的大象来解决的，而且往往是由于与技术无关的原因。
10:查询优化器可以打败所有数据库管理系统应用程序程序员，除了最好的每次记录。
[zv39]实体关系时代
[zv40]在20世纪70年代中期，Peter Chen提出实体关系(E-R)数据模型作为关系数据模型、CODASYL数据模型和层次数据模型的替代品[CHEN76]。基本上，他建议将数据库看作实体实例的集合。粗略地说，这些对象具有独立于数据库中的任何其他实体的存在性。在我们的示例中，供应商和部件就是这样的实体。
此外，实体具有属性，这些属性是表示实体的数据元素。在我们的示例中，Part的属性是pno、pname、psize和pcolor。
这些属性中的一个或多个将被指定为惟一的，即为键。最后，实体之间可能存在关系。关系可以是1比1、1比n、n比1或m比n，这取决于实体如何参与关系。
[zv41]E-R模型的一种常见表示是“方框和箭头”符号，如图8所示。E-R模型作为由DBMS实现的底层数据模型从未得到认可。可能原因是在早期没有为它提出查询语言。也许它只是被70年代对关系模型的兴趣所压倒了。也许它看起来太像CODASYL模型的“清理版”版本了。无论什么原因，E-R模型在20世纪70年代萎靡不振。
[zv42]有一个领域E-R模型非常成功，即数据库(模式)设计。关系倡导者的标准智慧是通过构建最初的表集合来执行数据库设计。然后，将归一化理论应用到初始设计中。在20世纪70年代的十年里，提出了一系列的范式，包括第二范式(2NF) [CODD71b]，第三范式[CODD71b]， Boyce-Codd范式(BCNF) [CODD72b]，第四范式(4NF) [FAGI77a]，以及项目连接范式[FAGI77b]。将规范化理论应用于实际数据库设计问题时存在两个问题。
[zv43]相比之下，E-R模型作为数据库设计工具变得非常流行。陈的论文包含了构建初始E-R图的方法。此外，将E-R图转换为第三范式的表集合很简单[WONG79]。因此，DBA工具可以自动执行此转换。因此，DBA可以构建他的数据的E-R模型，通常使用方框和箭头绘图工具，然后可以确保他将自动获得良好的关系模式。基本上所有的数据库设计工具，如来自麦格纳解决方案的Silverrun
[zv44]第十一条:功能依赖对于凡人来说太难理解了。另一个合适的理由(保持简单的愚蠢)。
[zv45]R++时代
[zv46]从20世纪80年代初开始出现了一批(数量可观的)论文，可以用以下模板来描述:
1考虑一个应用程序，称之为X
2尝试在关系DBMS上实现X
3显示为什么查询很难，或者为什么观察到性能很差，向关系模型添加一个新的“特性”来纠正问题
[zv47]这个系列的论文形成了“R + +时代”,因为他们提出的所有添加到关系模型。在我们看来，可能最好的拍品是Gem [ZANI83]。Zaniolo建议在关系模型中添加以下构造，以及相应的查询语言扩展:
[zv48]这种“级联点”符号允许查询供应表，然后在其他表中有效地引用元组。这种级联点表示法类似于LSL等高级网络语言中的路径表达式。它允许在表之间遍历，而不必指定显式连接。
[zv49]在Gem中，可以引用查询语言中的继承层次结构。例如，要找到红色电器部件的名称，可以使用:此外，Gem对空值的处理非常优雅。
[zv50]这类扩展的问题是，尽管它们允许比传统关系模型中更简单的查询公式，但它们几乎没有提供性能改进。例如，关系模型中的主键-外键关系很容易将元组模拟为数据类型。此外，由于外键本质上是逻辑指针，因此该结构的性能与其他类型指针方案的性能类似。因此，Gem的实现速度不会明显快于关系模型的实现
[zv51]在20世纪80年代早期，关系型供应商特别关注提高系统的事务性能和可伸缩性，以便能够用于大规模业务数据处理应用程序。这是一个非常大的市场，有着巨大的收入潜力。相比之下，R++的想法影响不大。因此，R++的想法很少有技术转移到商业领域，这种研究重点对商业领域的长期影响也很小。
第12条教训:除非有很大的性能或功能优势，否则新构造不会有任何用处。
[zv52]语义数据模型时代。大约在同一时期，又出现了另一种想法，想法相似，但营销策略不同。他们建议关系数据模型是“语义贫困”,即。它不能轻易地表示感兴趣的一类数据。因此，需要一个“后关系”数据模型。后关系数据模型通常被称为语义数据模型。
SDM侧重于类的概念，类是遵循相同模式的记录的集合。与Gem一样，SDM利用了聚合和泛化的概念，并包含了集合的概念。通过允许类具有其他类中的记录属性，可以支持聚合。然而，SDM通过允许一个类中的属性成为某个类中的记录的一组实例来推广Gem中的聚合构造。
此外，类可以泛化其他类。与Gem不同，泛化被扩展为一个图形而不仅仅是一棵树。类也可以是其他类之间的联合、交叉或区别。它们也可以是另一个类的子类，由谓词指定以确定成员关系。
最后，类可以有类变量，例如，Ships类可以有一个类变量，它是类成员的数量。
[zv53]大多数语义数据模型都非常复杂，一般都是纸上谈兵。SDM定义后几年，Univac探索了Hammer和McLeod的想法的实现。然而，他们很快发现SQL是一种星系际标准，而且他们的不兼容系统在市场上并不是很成功。
[zv54]译文：在我们看来，SDMs面临着与R++支持者同样的两个问题。与R++提案一样，它们是许多易于在关系系统上模拟的机制。因此，在提出的构造中几乎没有杠杆作用。SDM阵营还面临R++提案的第二个问题，即已建立的供应商被事务处理性能分心。因此，语义数据模型的长期影响很小。
[zv55]从20世纪80年代中期开始，人们对面向对象的dbms (OODB)产生了兴趣。基本上，这个社区指出了关系数据库和c++等语言之间的“阻抗不匹配”。
[zv56]在实践中，关系数据库有自己的命名系统、数据类型系统和作为查询结果返回数据的约定。在关系数据库中使用的任何编程语言都有自己的版本。因此，将应用程序绑定到数据库需要从“编程语言语言”转换到“数据库语言”并返回。这就像“把苹果粘在煎饼上”，这就是所谓的阻抗不匹配的原因。
[zv57]第一个定义了一个游标，以覆盖SQL查询的答案。然后，打开游标，最后从游标中获取一条记录，并将其绑定到编程语言变量，这些变量不需要与相应的数据库对象具有相同的名称或类型。如果需要，数据类型转换由运行时接口执行。
程序员现在可以使用本地编程语言操作Struct。当查询的结果超过一个记录时,程序员必须重复上述示例中的游标。
[zv58]在Rigel中，就像在其他持久化语言中一样，变量(在本例中是pno)可以被声明。然而，它们只需要向Rigel声明一次，而不是向语言声明一次，向DBMS声明一次。
持久性编程语言显然比SQL嵌入干净得多。但是，它需要使用面向dbms的功能来扩展编程语言的编译器。由于没有编程语言世界语，因此每个编译器必须进行一次扩展。此外，每个扩展可能都是唯一的，因为c++与APL有很大的不同。
[zv59]不幸的是，编程语言专家一直拒绝关注一般的I/O，尤其是DBMS功能。因此，我们所知道的所有编程语言在这方面都没有内置的功能。这不仅使嵌入数据子语言变得乏味，而且结果通常难以编程，容易出错。最后，语言专业知识并不适用于重要的面向数据的特殊目的语言，例如报告作者和所谓的第四代语言。
因此，没有技术从20世纪70年代的持续编程语言研究转移到商业市场，丑陋的数据-子语言嵌入盛行。
[zv60]在20世纪80年代中期，由于c++的普及，人们对持久编程语言的兴趣再度高涨。这个研究方向被称为面向对象数据库(OODB)，主要关注于持久c++。对oodb的主要推动来自于一系列初创企业，包括本体、对象设计和Versant。所有构建的支持持久c++的商业系统。
这些系统的一般形式是支持c++作为数据模型。因此，任何c++结构都可以持久化。出于某种原因，用关系的概念扩展c++很流行，这个概念直接从十年前的实体-关系数据模型借用过来。因此，一些系统通过支持这个概念来扩展c++运行时。大多数OODB社区决定将工程数据库作为他们的目标市场
[zv61]为了应对工程市场，持久化c++的实现有以下要求:
1)不需要声明式查询语言。所需要的就是在c++中引用基于磁盘的大型工程对象的方法。
2)不需要花哨的事务管理。这个市场主要是一个用户一次处理大型工程对象。更确切地说，某种版本控制系统会很好。
3)运行时系统在操作对象时必须与传统的c++竞争。在这个市场中，使用持久c++的算法的性能必须与自定义加载程序和传统c++的性能相竞争
[zv62]很自然，OODB供应商关注于满足这些需求。因此，对事务和查询的支持很弱。相反，供应商关注于操作持久c++结构的良好性能。例如，考虑以下声明:
[zv63]不幸的是，这种工程应用程序的市场从来没有变得非常大，有太多的供应商竞争一个“利基”市场。目前，所有的OODB供应商都失败了，或者重新定位了他们的公司，以提供不同于和OODB的产品。例如，对象设计已经将自己重新命名为Excelon，并开始销售XML服务
[zv64]在我们看来，这次市场失败有很多原因。
1)无杠杆。OODB供应商为客户提供了避免编写加载程序和卸载程序的机会。这不是一个主要的服务，客户不愿意花大价钱购买这个功能。
2)没有标准。所有的OODB供应商产品都不兼容。
3)重新连接世界。在任何更改中，例如对持久数据进行操作的c++方法，那么所有使用该方法的程序都必须重新连接。这是一个明显的管理问题。
4)没有世界语编程语言。如果您的企业有一个不是用c++编写的、需要访问持久数据的应用程序，那么您就不能使用OODB产品之一。
[zv65]当然，OODB产品并不是设计用于业务数据处理应用程序的。它们不仅缺乏强大的事务和查询系统，而且运行在与应用程序相同的地址空间中。这意味着应用程序可以自由地操作所有基于磁盘的数据，而且不可能实现数据保护。在业务数据处理市场中，保护和授权是非常重要的。此外，oodb显然是对CODASYL时代的一种倒退，即程序员编写查询优化算法时的一种低级记录。作为一个结果,
[zv66]不幸的是，对于O2来说，有一种说法是“美国和世界其他地方一样”。这意味着新产品必须在北美生产，而世界其它地区则在关注美国的市场接受程度。O2是法国公司，由Francois Bancilhon从Inria剥离出来。对于O2来说，凭借先进的产品在欧洲获得市场的吸引力是很困难的，因为上面的格言。因此，O2意识到他们必须攻击美国市场，并在比赛后期转移到美国。到那时，一切都已经太迟了，OODB时代正在走下坡路。
[zv67]第13条:包不会卖给用户，除非他们“非常痛苦”
第14条:如果没有编程语言社区的支持，持久化语言将毫无用处。
[zv68]对象关系时代。对象关系(或)时代是由一个非常简单的问题驱动的。在INGRES的早期，该小组对地理信息系统(GIS)很感兴趣，并提出了支持它们的机制[GO75]。在1982年左右，以下简单的GIS问题困扰着INGRES研究小组。假设要在数据库中存储地理位置。例如，您可能希望将交叉口集合的位置存储为:
[zv69]不幸的是，这是一个二维搜索，而INGRES中的b -tree是一个一维访问方法。一维访问方法不能有效地进行二维搜索，因此在关系系统中无法快速运行该查询。
[zv70]同样，没有办法使用b树访问方法来执行这种查询效率。此外，需要花一点时间让自己相信这个查询是正确的，而且还有其他一些效率较低的表示。综上所述，简单的GIS查询在SQL中难以表达，它们在标准b树上执行，性能非常糟糕。
[zv71]下面的观察激发了OR建议。早期的关系系统支持整数、浮点数和字符串以及明显的操作符，主要是因为这些是IMS的数据类型，这是早期的竞争对手。IMS选择这些数据类型是因为这是业务数据处理市场需要的，也是他们的市场焦点。关系系统还选择了b -tree，因为这有助于业务数据处理中常见的搜索。后来的关系系统扩展了业务数据处理数据类型的集合，包括日期，
在其他市场，如GIS，这些不是正确的类型，b -tree不是正确的访问方法。因此，要处理任何给定的市场，都需要适合市场的数据类型和访问方法。由于可能还有许多其他市场需要解决，因此“硬连线”数据类型和索引策略的特定集合是不合适的。相当复杂的用户应该能够添加自己的;即根据特定需求定制DBMS。这种定制在业务数据处理中也很有用，因为需要一个或多个新的数据类型
因此，OR建议向SQL引擎添加用户定义的数据类型、用户定义的操作符、用户定义的函数和用户定义的访问方法。主要的或研究原型是Postgres [STON86]。
将OR方法应用到GIS中，只需要添加地理点和地理框作为数据类型。通过这些数据类型，上面的表可以表示为:
[zv72]要应对GIS市场，我们需要一个多维索引系统，比如四维树[SAME84]或r -树[GUTM84]。总之，一个高性能的GIS DBMS可以用适当的用户定义的数据类型、用户定义的操作符、用户定义的函数和用户定义的访问方法来构造。
[zv73]Postgres的主要贡献是找出支持这种可扩展性所需的引擎机制。实际上，以前的关系引擎对一组特定的数据类型、操作符和访问方法都有硬编码支持。所有这些硬编码的逻辑都必须被剔除，并被更加灵活的体系结构所取代。
1980年代中期，Sybase率先在DBMS中包含存储过程。其基本思想是在TPC-B上提供高性能，它由以下命令组成，模拟兑现支票:
[zv74]此事务需要DBMS和应用程序之间的5或6条往返消息。由于与正在进行的非常简单的处理相比，这些上下文切换比较昂贵，因此应用程序的性能受到上下文切换时间的限制。
减少这个时间的一个聪明方法是定义一个存储过程:
[zv75]这只需要在DBMS和应用程序之间往返一次，而不是5次或6次，并且极大地加快了TPC-B。为了在TPC-B等标准基准上快速运行，所有供应商都实现了存储过程。当然，这要求他们定义专用(小型)编程语言来处理错误消息并执行所需的控制流。这对于存储过程正确处理帐户中的“资金不足”等情况是必要的。
Postgres UDTs和UDFs将这个概念推广到允许用常规编程语言编写代码，并在处理常规SQL查询时调用代码。
Postgres为UDTs、udf和用户定义的访问方法实现了一种复杂的机制。此外，Postgres还实现了不太复杂的继承概念，以及指针(引用)、集合和数组的类型构造函数。后一组特性使Postgres在OO热潮的高峰期变得“面向对象”。
[zv76]后来的基准测试工作如Bucky [CARE97]证明了Postgres的主要胜利是UDTs和UDFs;在传统的关系系统上模拟OO构造是相当简单和高效的。这项工作再次证明了R++和SDM人群在几年前已经看到了什么;也就是说，对聚合和泛化的内置支持提供了很少的性能优势。换句话说，OR的主要贡献是为存储过程和用户定义的访问方法提供了更好的机制。
[zv77]OR模式在商业上取得了一些成功。Postgres被illustration商业化。在最初几年苦苦寻找市场之后，illustration公司抓住了“互联网浪潮”，成为“网络空间的数据库”。如果希望将文本和图像存储在数据库中，并将其与传统数据类型混合，那么illustration就是能够做到这一点的引擎。在互联网狂热的高峰期，illustration已经被Informix收购。从illustration的观点来看，有两个原因使我们联合使用Informix:
为了在OR中获得成功，必须拥有高性能的OLTP引擎。Postgres从未关注过OLTP的性能，而将其添加到Illustra中的成本将非常高。将Illustra的特性结合到现有的高性能引擎中更有意义。
为了成功，illustration必须说服第三方供应商将他们的应用程序套件转换成udf和udf。这是一项非常重要的任务，大多数外部供应商都不愿这么做，至少在Illustra能够证明这一点或展示一个巨大的市场机会之前是这样。因此，illustration遇到了一个“先有鸡还是先有蛋”的问题。为了获得市场份额，他们需要udf和udf;为了获得udf和udf，它们需要市场份额。
[zv78]在更广泛的商业市场上接受或接受技术的障碍之一是缺乏标准。每个供应商都有自己的定义和调用udf的方法，此外，大多数供应商都支持Java udf，但微软不支持。除非(而且直到)主要供应商能够就标准定义和调用约定达成一致，否则或技术将不会腾飞。
[zv79]教训14:OR的主要好处有两方面:将代码放入数据库(从而模糊了代码和数据的区别)和用户定义的访问方法。
教训15:新技术的广泛采用需要标准和/或大象的大力推动。
[zv80]在过去的五年里，关于“半结构化”数据的研究如雪崩般涌现。这类提议的一个早期例子是Lore [MCHU97]。最近，各种基于xml的提案都有相同的风格。目前，XMLSchema和XQuery是基于xml的数据的标准。有两个基本要点。
1)模式最后2)复杂的面向网络的数据模型
[zv81]1.模式最后：第一点是事先不需要模式。在“模式优先”系统中，会指定模式，随后可以加载符合该模式的数据记录实例。因此，数据库始终与已存在的模式保持一致，因为DBMS拒绝任何与模式不一致的记录。以前的所有数据模型都需要DBA预先指定模式。
在这类提案中，模式不需要预先指定。可以在最后指定，甚至完全不指定。在“模式最后”系统中，数据实例必须是自描述的，因为并不一定存在一个模式来赋予传入记录意义。如果没有自我描述的格式，记录只是“一桶比特”。要使记录自描述，必须用定义属性含义的元数据标记每个属性。下面是一些使用人工标记系统的此类记录示例:
[zv82]可以看出，这两张唱片都描述了一个人。此外，每个属性都有三个特征之一:
1)它只出现在两个记录中的一个中，而在另一个记录中没有具有相同含义的属性。
2)它只出现在两个记录中的一个中，但是在另一个记录中有一个属性具有相同的含义(例如passtimes和hobby)。
它出现在两个记录中，但是格式或含义不同(例如Works_for, salary)进入翻译页面
[zv83]这是语义异质性的一个示例，其中关于公共对象(在本例中是人)的信息不符合公共表示。语义异质性使查询处理成为一个巨大的挑战，因为没有基于此基础的索引决策和查询执行策略的结构。
“schema last”的拥护者通常会在应用程序中考虑到，用户可以很自然地以自由文本的形式输入他们的数据，可能是通过文字处理器(它可能用一些关于文档结构的简单元数据注释文本)。在这种情况下，在用户添加数据之前需要一个模式存在是一种强制。然后，“模式最后”的倡导者会在脑海中自动或半自动地为传入的数据添加标签，以构建上述半结构化记录。
相反，如果业务表单用于数据输入(这对于上面的Person数据可能是很自然的)，那么将使用“模式优先”方法，因为设计表单的人实际上也根据表单中允许的内容定义模式。因此，schema last主要适用于以自由文本作为数据输入机制的应用程序。
[zv84]严格结构化的数据包含必须符合模式的数据。通常，这基本上包括业务流程必须操作的所有数据。
[zv85]大型公司的人事记录是我们考虑的第二类数据库应用程序的典型。有相当数量的严格结构化的数据，唯一的免费文本输入是输入特定的注释字段。模式首先出现的是正确的方法，这种应用程序很容易解决
[zv86]第三类数据称为半结构化数据。我们能想到的最好的例子就是招聘广告和简历。在每一种情况下，数据都有一定的结构，但是数据实例可以根据所出现的字段和它们的表示方式有所不同。此外，不存在实例必须符合的模式。半结构化实例通常作为文本文档输入，然后进行解析以找到感兴趣的信息，然后将这些信息“分解”成存储引擎中的适当字段。在这种情况下，最后一个模式是一个好主意。
[zv87]第四类数据是纯文本，即没有特定结构的文档。在这个桶中，没有明显的结构可以利用。信息检索系统几十年来一直关注这类数据。很少有IR研究者对半结构化数据感兴趣;相反，他们感兴趣的是基于文档文本内容的文档检索。因此，在这个桶中没有要推断的模式，这对应于“根本没有模式”。
[zv88]因此，在我们的分类系统中，schema-last只处理第三类数据。支持者经常认为大学课程描述符合这一范畴。然而，我们所知道的每一所大学都有严格的课程描述格式，其中包括一个或多个文本字段。大多数学校都有一个标准的输入数据的表格，以及一个拒绝不符合这种格式的课程描述的系统(手动或自动)。因此，课程描述是第二类数据的例子，而不是第三类数据。我们认为，仔细检查第3类应用程序的声明实例将减少该类的实际实例。从第3类转向第2类，大概是为了在他们的数据库上加强一致性(从而更容易比较)。
[zv89]语义异质性在企业中已经存在了很长时间。他们在仓库项目上花费大量资金来设计标准模式，然后将操作数据转换为这个标准。此外，在大多数组织中，语义异质性是在数据集的基础上处理的;例如，具有不同模式的数据集必须同质化。典型的仓库项目超出了预算，因为模式的同质化非常困难。任何schema-last应用程序将不得不面对语义异构性纪录¬记录基础上,它将更加昂贵的解决。这是一个很好的理由。
总之，模式最后只适用于我们分类方案中的第三类应用程序。此外，在这门课上很难想出很多令人信服的例子。如果有的话，趋势是将类3应用程序移到类2中，大概是为了让语义异构问题更容易处理。最后，类3应用程序似乎有少量的数据。由于这些原因，我们将模式最后的数据库看作一个利基市场。
[zv90]现在我们来看看XML数据模型。过去，描述模式的机制是文档类型定义(dtd)，将来数据模型将在XMLSchema中指定。dtd和XMLSchema的目的是处理格式化文档的结构(因此dtd中有“文档”一词)。因此，它们看起来像一种文档标记语言，特别是SGML的一个子集]。因为文档的结构可能非常复杂，所以这些文档规范标准必然非常复杂。作为一个文档规范系统，我们对这些标准没有异议
[zv91]作为结构化数据的数据模型，我们认为这两个标准都有严重的缺陷。第一个近似值是，这些标准包含了以前任何数据模型建议中指定的所有内容。此外，它们还包含一些足够复杂的额外特性，以至于DBMS社区中没有人在数据模型中认真地提出过这些特性。
[zv92]例如，XMLSchema中提供的数据模型具有以下特征:
1) xml记录可以是层次化的，就像在IMS中一样
2)xml记录可以有“链接”(引用)其他记录,如CODASYL,宝石和长效磺胺
3) xml记录可以具有基于集合的属性，比如SDM
4) xml记录可以通过多种方式从其他记录继承，比如在SDM中进入翻译页面
[zv93]此外，XMLSchema还有几个特性，这些特性在DBMS社区中是众所周知的，但是由于复杂性，以前的数据模型中从未尝试过。一个例子是union类型，即记录中的属性可以是一组可能的类型之一。例如，在人事数据库中，字段“work - For”可以是企业中的部门编号，也可以是借调员工的外部公司的名称。在本例中，for可以是字符串或整数，具有不同的含义。
注意，union类型上的b树索引很复杂。实际上，联合中的每个基类型都必须有一个索引。此外，对于涉及联合类型的每个查询，必须有不同的查询计划。如果要连接两个分别包含N和M基类型的联合类型，那么至少要有Max (M, N)计划来协调。由于这些原因，在DBMS中从未认真考虑过union类型。
显然，XMLSchema是有史以来提出的最复杂的数据模型。很明显，这与“保持简单愚蠢”(KISS)量表上的关系模型的另一个极端是一样的。将如此复杂的数据用作结构化数据的模型是很难想象的。我们可以预见未来的三种情况。
场景1:XMLSchema将因为过度复杂而失败
场景2:XMLSchema的一个“面向数据的”子集将被提出，它要简单得多进入翻译页面
场景3:XMLSchema将变得流行。在十年内，激发Codd发明关系模型的IMS和CODASYL的所有问题将重新浮出水面。在那个时候，一些有进取心的研究者，叫他Y，将会“重拾”Codd的原始论文，并且会有一个“伟大辩论”的重播。大概会以和上次一样的方式结束。此外，Codd因其贡献于1981年获得了图灵奖[CODD82]。在这种情况下，Y大约会在2015年获得图灵奖。
[zv94]总结XML/XML- schema /Xquery是一个挑战，因为它有很多方面。很明显，XML将是一种流行的跨网络数据移动的“在线”格式。原因很简单:XML通过防火墙，而其他格式不通过。由于任何两个企业的机器之间总是有防火墙，因此跨企业数据移动将使用XML。由于一个典型的企业希望在企业内部以与企业外部相同的方式移动数据，因此完全有理由相信XML将成为星系际数据移动标准。
因此，所有类型的系统和应用软件都必须准备好发送和接收XML。将关系数据库生成的元组集转换为XML很简单。如果有一个OR引擎，这只是一个用户定义的函数。类似地，可以接受XML中的输入，并将其转换为元组，以使用第二个用户定义函数存储在数据库中。因此，技术促进了必要的格式转换。其他系统软件同样需要转换设备。
原生XML dbms可能会流行起来，但我们对此表示怀疑。XML dbms需要10年时间才能成为能够与目前的大象竞争的高性能引擎。此外，schema-last只能在有限的市场中具有吸引力，过于复杂的网络模型是KISS的对立面。XMLSchema迫切需要子集..xml模式的一个干净子集具有易于映射到当前关系dbms的特性。在这种情况下，实现新引擎的意义是什么?因此，我们期望原生XML dbms能够成为一个利基市场。
[zv95]现在考虑Xquery。一个(健全的)子集很容易映射到几个供应商的或SQL系统。因此，在大多数现有引擎之上实现Xquery的子集是相当简单的。因此，大象不太可能同时支持SQL和XMLSchema和XQuery的子集。后一个接口将被转换为SQL。
[zv96]此外，我们认为使用通用模式进行跨企业数据共享将会很慢，因为语义异构问题很难解决。虽然W3C在这个领域有一个项目，即所谓的语义web，但我们对其未来的影响并不乐观。毕竟，人工智能社区几十年来一直致力于知识表示系统的开发，但成效有限。语义网与过去的努力有着惊人的相似之处。由于web服务依赖于在完全不同的系统之间传递信息，所以不要把赌注压在这一交易的早期成功上
[zv97]几年前，OLE-DB受到微软的大力推动;现在是“X东西”。OLE-DB之所以受到微软的推动，在很大程度上是因为微软没有控制ODBC，并且认为oll - db具有竞争优势。现在，微软意识到了Java及其各种跨平台扩展(如J2EE)带来的巨大威胁。因此，它正在大力推进XML和Soap方面的工作，试图阻碍Java的成功。
问题与解答：
（一）历史上最有影响力的数据模型有哪些？其他为什么没形成气候？
1. 历史上最有影响力的数据模型有
a) 层次数据模型，它引入记录类型的概念，记录类型必须在树中排列,每个记录类型除了根都有一个唯一的父记录类型；
b) CODASYL网络模型，这个模型将记录类型的集合组织到网络中，而不是树中。相比层次数据模型，该模型中一个给定的记录实例可以有多个父实例。
c) 关系模型，它使用简单的数据结构，可以更好地改变逻辑数据独立性；使用高级语言，可以提供高度的物理数据独立性。
2.其他没有形成气候的原因是多方面的：
a) 性能上，没有太大进步。比如gem模型，尽管它们允许比传统关系模型中更简单的查询公式，但它们几乎没有提供性能改进。
b) 模型设计过于复杂，人们难以理解。比如大多数语义数据模型都非常复杂，一般都是纸上谈兵，与现有系统不兼容。因此，语义数据模型的长期影响很小。
c) 商业上没得到支持，比如OODB模型，这种工程应用程序的市场从来没有变得非常大，却有太多的竞争，从而导致了失败。
（二）数据模型的发展史给我们哪些教训？
教训是多样而丰富的：
1. 树结构数据模型是非常严格的,对树结构数据进行复杂的逻辑重组是一个挑战。
2. 网络比层次结构更灵活，但更复杂,加载和恢复网络比层次结构更复杂。
3. 无论数据模型如何，设置时间语言都是好的，因为它们提供了更好的物理数据独立性。
4. 简单数据模型比复杂数据模型更容易实现逻辑数据独立性。
5. 技术争论通常是由市场上的“大象”来解决的，而且往往是由于与技术无关的原因。
6. 模型功能不能过于复杂，要让绝大多数人都能理解。
（三）为什么作者不看好XMLschema？你有不同观点没？
作者不看好XMLschema是因为：XMLSchema具有几个复杂的特性，在以前的数据模型中从未尝试过，比如union类型。XMLSchema几乎是有史以来提出的最复杂的数据模型，将如此复杂的数据用作结构化数据的模型是很难想象的，很有可能会失败，如果能成功也算是奇迹。
我认为，还是要对XMLschema的未来持乐观的态度，因为技术的发展在一直推进，目前难以想象的困难，可能在某项技术突破后会使问题变得简单。
（四）你怎么理解本文标题？
我认为标题有下列几个含义：
1. 技术的发展是递进的，新技术的出现或多或少是以旧技术为前提和参考。
2. 新技术的出现受到当时条件的限制，是以现实条件为基础的，当理念太过先进，当前是难以实现的。然而，当现实条件达到时，这些“旧理念”会焕发新芽。
3. 已经过时的技术不一定就毫无价值了，当我们回顾整个技术发展历程，我们可以总结许多的经验教训，为新技术的发展提供参考。
# 打赏鼓励请扫支付宝微信二维码O(∩_∩)O金额不限噢噢！如果有修改建议或者疑问请留言！
