摘自：DB2 Magzine,
2003 年 7 月
对 Don Chamberlin、Don Haderle 和 Pat Selinger 三位 DB2 先驱的访谈，讨论的范围涉及 DB2 的过去、现在和未来，这次谈话的主题是 DB2 发展历程中的 各个“转折点”。
DB2 杂志： 对象/关系技术是一个转折点吗？即使它并未在市场上真正站稳脚跟？
Haderle： 是的。对象/关系技术必须利用数据库的可扩展性，也就是如何提供一个可以添加您或其它人开发的新功能的平台。虽然对象/关系技术并没有在市场上得到广泛应用，但它成为了我们实现多个小组协作、添加功能和保持整体向前发展的基本的数据库引擎基础结构。在1995 年和 1996 年，我们开始第一次在 DB2 和 DataJoiner 中运用 Garlic 研究项目提供的技术。
Selinger： 触发器、BLOB、用户自定义函数(UDF)，所有这些都伴随着对象/关系技术的浪潮一同出现。现在每个人都可以充分利用这类技术，因为我们已经将它们整合到数据库引擎中。我认为对象/关系技术与人工智能(AI)有几分类似：一旦 AI 开始发挥作用，人们也就不再称它为 AI 了。剩下的是那些发展越来越缓慢的功能了。 但我认为，正如我们看到在对象/关系数据库结构中引入了 EJB 和其它新技术一样，我们将发现有越来越多的风险性技术被开发出来。
谈到数据可用性，我们还必须提到数据共享和多系统功能 - 联邦和Parallel Sysplex。大约在1994 年，我们在大型机和开放系统平台上引入了这些功能。我认为这类技术也是一个转折点。
Chamberlin： 我认为我们现在正在经历信息集成的转折点。回顾过去，我发现两种截然不同但同时存在的技术潮流：一种专注于处理结构化、同构数据，另一种专注于处理非结构化的数据。如果您正在处理银行账户，所有记录就都是同构且结构化的。今天，我们可以用数字媒体来展示书籍，但书和银行帐户不一样，每本书的结构都是不相同的。
因此，历史上各种各样的软件都围绕这两类不同的数据技术潮流来发展。现在，Web 正在把它们融合在一起。我们需要通用的工具来同时处理这两类数据。这正是我们目前面临的挑战。
DB2 杂志： 早期我们讨论了使用能够处理 DSS 和操作、事务处理行为的语言 SQL 是一种激进但可行的想法。现在 SQL 是否面临类似的考验，即是否能够支持结构化和非结构化的数据系统？
Selinger： 是的，这就是为什么你看到 Don Chamberlin 在 XML 查询语言(Xquery) 委员会上强烈建议 IBM 来定义这一能够处理这两类数据的下一代查询语言的原因。展望未来，客户将希望引入更多的数据，而不仅仅是"循规蹈矩"的结构化信息。
Haderle： 我同意 Don 的说法。正如我们所说，我们正处于这一转折点的浪尖上。它"诞生"了虚拟数据库概念以及支持这一概念的联邦技术。现在面临的主要问题是存在一组分散的数据，客户希望引入这些数据并将它们全部链接在一起，我们该怎么做呢？答案是提供虚拟层。
Selinger： 在开发了所有 SQL 创新和关系功能之后，Don [Chamberlin] 花费了几年的时间来研究文件管理。我们认为这是他一次很大的转变，但我们当时并不知道这一切工作都是在前进的道路上兜圈子。
Haderle： 在二十世纪 90 年代初，我们对 Don 说："Don，这是个问题。"他说："是的，我知道这是个问题。"我们问他："SQL 是否是我们打算驾御的工具？它是否有足够的表现力？"Don 说："不是。我需要不断地完善它。"因此，他成为了 XML 的拥护者，并提出了这样一种理念：我们需要通过现有的基于 SQL 的应用程序和基于 XML 的应用程序来提供接入。Don 一直在研究 XML数据模式，它是创建虚拟数据库层和提供允许人们获得无数信息的信息实用程序的核心。
在 DB2 XML Extender 的帮助下，我们才真正开始了这一过程。XML Extender 实现了一个 Native XML 数据库，它可以将DB2 封装起来。在不受太多关系规则约束的情况下，我们开发出了越来越多的功能，它将提供 XML 模式、XML 查询和其它工具。但是我们还有可以用于支持 XML 的关系功能 - 我们可以整合 XML 和关系功能，同时为您提供这两种技术的特性。
之后我们的重点转移到联邦技术上来。Pat 主攻元数据，它将使我们能够查看不同数据源和数据结构发送的信息并无缝地对其进行联合。对元数据的理解可以帮助我们开始研究描述数据在不同数据源环境中的语义规则-以及如何能够无缝地对它们进行联合。这就是用户所需要的，不是吗？我们正在为这个问题而努力，我们把这种技术叫做"信息集成。"
Selinger： 您可以这样来考虑：SQL 和关系系统只需要您指定希望从数据中获得的信息，而无需关注数据在物理上是如何存储的，是否对某些数据进行了索引。SQL 和关系系统在物理数据存储上提供一个透明的层次。同样的，信息集成为您提供另外一个透明的层次-这次是在数据源的位置和语言上。信息集成能让您上升一个层面并使您能够与分布的异构数据源交互，就好像它们都在同一个位置，都使用 SQL 和 Xquery 语言一样。
Chamberlin： 您必须以一种截然不同的方式来处理元数据。在纯粹的关系数据库中，数据是同构的 - 每个银行账户看起来都是一样的。您可以归纳出描述银行账户结构的元数据并将它存放目录中，而无需为每位账户复制它。但是如果数据是异构的，例如一个数字图书馆，因为每个对象都必须进行自我描述，所以元数据必须与数据密切结合。由于每个对象都是不相同的，您不能归纳出数据的描述并把它放在一个公共位置。元数据与数据是混合在一起的，数据模式也是动态的，这样，存取一组完全不同的数据的系统使用的查询语言必须能够同时查询数据和元数据。
Haderle： 在使用 XML、Xquery 和联邦技术时，您必须提供非常强大的复制功能。如果您计划部署联邦系统，您不能保证总能够通过网络来获取到信息。为了使其能够正常运行，您必须将某些信息保留在本地。我们如何能够将实现数据的缓存？我们如何实现自动复制?我们如何设置不同的模式来保证事务更新、信息验证和异步连接的一致性？这都是我们正在研究的课题。我们正处于这一转折点上。
DB2 杂志： 在 V8 中，将 Content Manager 整合到 DB2 似乎是这一演变过程中的关键一步。
Selinger： Content Manager 为我们带来了一次重要的转变。这种强大的内容管理应用程序能够保存包括文件夹、版本在内的所有数据库不能理解的信息的语义和功能。这一切都将基于 DB2，关系数据库管理系统在 Content Manager 中可以起到类似于图书馆中卡片目录的作用。
在DB2 V8中我们所做的工作的是在存储过程和 UDF 中实现相应功能以将它们集成到数据库中，然后就可以通过数据库提供的特性来使用这些功能。例如，如果我们需要，我们可以并行运行它。这就是目前我们将功能添加到 DB2 中采用的方法。我们正在致力于将更多的语义融合到数据库引擎中。
Haderle： 这就是我们目前的途径。坦白地说，如果 DBMS 不能够实现版本管理和其它内容管理功能，开发商将基于 DB2 来编写自己的内容管理查询系统。开发商必须依赖 DB2 来构建自己的查询系统的原因是因为他的客户需要查询与时间相关的或者其它的一些特殊问题。通常的情形是，开发商构建的层面会变得越来越复杂，直到他将几乎整个查询系统都建立在我们的查询系统之上。接着，开发商开始担心并行机制和其它一些因素，如果脱离了我们的系统，他可能需要 200 位员工来开发本来 DB2 能够完成的功能。
因此，我们的工作是添加越来越多的语义和结构知识，从而使内容管理系统可以充分利用数据库并最大限度地减少单独构建一个完整查询系统的需求。如果我们不能把某些语义和功能添加到数据库引擎中，结果又将如何呢？借助于我们的可扩展性，如存储过程和 UDF，我们能够让内容管理系统将其它的功能加入到我们的结构中并同样能够享受查询编译、并行机制等特性带来的优势，而无须基于 DB2 来另外编写一个层面。
Chamberlin： 我认为有一些对象/关系的观念正在奏效，它们在数据库层为我们解析复杂对象的语义提供了良好的基础。
Selinger： 是的，通过提升数据库能够理解的抽象层次，可以减少上层应用程序的规模。这就是这场游戏的主题：减少员工工作，从而人们可以加速应用程序的交付和降低成本。您可以腾出更多的人手来开发下一个应用程序并使企业更具竞争力。
DB2 杂志： 是否 Starburst 优化器的引入使得这么强的可扩展性成为可能？与 Starburst 一同推出的新型查询重写和查询编译技术为 DB2 引擎增加了更多的智能。
Selinger： Starburst 是一个完整的系统- 一种全功能的数据库系统。我们采取的口号是"现在我们已经走到了这一步，我们知道我们正在做什么，让我们从头开始，设计一个可扩展的系统。"我们希望实现高度的可扩展性和优化，这将对未来的发展起着决定性作用。Starburst 融合了对象/关系理念，以及可扩展性和可扩充性，并开始具有以查询重写和新型编译为代表的自主功能。Starburst 使 DB2 在开放系统上实现了功能上的显著跳跃。
Haderle： Starburst 是 DB2 成为开放系统的巨大转折点。但当我们谈到 20 世纪 90 年代中期的转折点时，我们有点不负责任，因为我们没有提到数据挖掘。我们在二十世纪 80 年代后期引入了查询并行机制，它使复杂的查询能够以非常快的速度完成。至于数据挖掘
