开发对象-关系数据库应用程序（第一部分）

英文原文

开发对象-关系数据库应用程序（第一部分）

Paul Brown
IBM Informix
2002 年 6 月

	内容
简介
数据库的设计目标
数据库分析和设计
数据流、工作负载和查询
结束语

简介

这篇文章是以前在 Informix Tech Notes 季刊上发表过。Tech Notes 文档收集了该季刊从 1991 年到 2001 年的文章。要获得 1998 年以来或更早文章的重印本，请与技术支持（Technical Support）（tsmail@us.ibm.com）联系。

编者注：本文是关于开发对象-关系数据库应用程序的两部分系列文章中的第一篇。它源自由 Informix Press 出版的书籍 Developing Object-Relational Database Applications。本文（第一部分）讲述了数据库分析和设计方法，第 2 部分着重讲述了应用程序实现。

当使用对象-关系数据库管理系统（ORDBMS）的开发人员采取更为“整体”的方法而不是使用典型的关系 DBMS 技术来进行数据库分析和设计时，会从 ORDBMS 这项技术中受益最多。

通常，关系 DBMS 被看作高效、可靠和相对静态的商业数据资源库。SQL-92 提供了用于存储关于有趣的现实情况的事实的灵活框架，并提供了用于操作记录这些事实的数据的机制。但由于 SQL 的简单性，使得开发人员很难用它来实现很多事情。例如，尝试用 SQL-92 回答下列简单问题：

“我的哪个雇员本周过生日？”

您会问，该问题真的这么难？对，如果我们实际使用的日历象 SQL-92 的 DATE 数据类型那样简单，该问题就很容易。但因为 2 月 29 日出生的人除了闰年以外，每年都在 2 月 28 日庆祝生日，所以这个问题就变得复杂了。结果是，您需要编写如下所示的 SQL-92 查询：

图 1. 用 SQL-92 编写的“今天是谁的生日？”查询的不完整解决方案

对象-关系 DBMS 技术的主要目标是使开发人员能够避免象这样的复杂性，然后创建更智能化的数据库。在本文的稍后部分，我们将研究同一问题的 ORDBMS 解决方案。但首先，我们将回顾一下适用于使用 ORDBMS 的开发人员的高级别开发方法描述。这个方法组合了关系和面向对象这两方面的分析和设计。在此期间，我们将就什么最有效以及什么根本无用给出实际建议。

数据库的设计目标

考虑 ORDBMS 的一种好方法是将它当作一种软件“底板（back-plane）”：一种框架，您可以在其中嵌入对应于应用程序感兴趣的东西的软件模块（对象类）。对象-关系 DBMS 和更传统的软件框架（如纯面向对象的 DBMS、应用程序服务器或 TP 监视器中间件）的不同之处在于嵌入式对象类是在抽象的或逻辑的数据模型中部署的。结果是，对象-关系数据库开发团队需要在两个级别上工作。一个开发人员团队用 C 或 Java 这样的语言实现数据库中的对象，同时另一个团队组合这些对象以满足应用程序问题域的高级别需求。

任何 MIS 开发项目的出发点都是系统打算支持的用户团体，并且最重要的目标是开发项目要满足用户需求。我们用术语问题域来表示用户需求的完整集。为了充分地服务于用户需求，信息系统应该努力做到：

• 完整。系统必须包含与问题域相关的所有信息。换句话说，数据库必须是可共享的。有时，这意味着数据库应该包含“参考”数据：用户无权控制但依赖于它们进行决策的事实（映射、文档和元数据等）。
• 正确。系统应该精确地表示问题域。类似于人类的所有工作，这个事实也会随时间而更改，因此系统应该有能力适应此类更改。
• 一致。信息系统中的模糊（例如，如果显示两条相反的信息）将在系统的用户中引起混乱和错误。信息系统的设计应该将此类问题的风险降到最低。完成这一点的一个重要方法是设计数据库模式，以便对于任何一个要存储的事实，在数据库中仅有一个位置用于存储它。
• 灵活。从 RDBMS 技术的成功中学到的最重要的经验就是：在运行时回答在设计时未曾料到的问题的能力有极大价值。人类天生就比计算机系统更灵活，并且用户会经常提出新的问题和需求。当然，数据库对这类行为的支持程度，是一个衡量其战略价值的尺度。
• 有效。时间就是金钱。必须按以下几个标准衡量系统的效率：操作性能（最终用户响应时间）、上市时间（开发的容易程度）和管理性开销。

这些是任何信息系统的目标，无论用什么技术构建它。项目因对每个目标的侧重程度不同而不同。主要由其它软件系统访问的嵌入式应用程序主要注重于效率和一致性，但不必特别灵活。另一方面，支持管理决策制定者的系统应该首先是正确和灵活的。当在备选设计中进行选择时，对新系统的用户团体的目的和目标的清晰理解是非常有帮助的。

数据库分析和设计

ANSI 的三层数据库模型（Three-Tier Database Model）已经推出二十年了，但它至今还象过去一样广泛使用（尽管供应商不断重新包装其概念）。三层模型描述三个“抽象级别”，相应的是：

1. 最终用户的概念性框架和关于他们推论问题域的方法。这称为概念性或外部级别。
2. 存储信息和提供工具（由此其它程序可以检索和操纵该信息）的软件服务。这对应于 DBMS 软件提供的抽象级别。我们称之为逻辑或内部级别。
3. 用来构造数据存储的物理结构以及用来执行数据检索和操纵的低级别算法。隐藏这个物理级别的细节是关系或对象-关系 DBMS 的主要增值。

所有 DBMS 分析和设计方法都描述了在不同抽象级别上表示问题域的技术，以及用于在各层之间转换不同模型的算法。下面的图 2 提供了三种模型如何安排和如何交互的理想化图示。

图 2. ANSI 数据库模型的三层

我们在本文中描述的方法是很常见的，因为它在上图中从左到右依次进行。首先，它着重于捕获系统用户如何考虑他们所访问信息的完整描述。此类概念性视图由一列用户使用的对象和用这些对象描述的事实组成。注：在许多网站中“用户”是理想化的。也就是说，网站的总体架构设计师将他们“介绍”给您，决定他们应该看到什么、在哪里看到以及他们的行为。

概念性模型推动逻辑数据库的设计，逻辑数据库作为对象-关系数据库模式实现。在对象-关系 DBMS 中，模式概念除了包括表、视图和常见业务过程之外，还扩展到包括数据类型及其行为。最后，ORDBMS 足够灵活，因此开发人员和管理员可以对逻辑模式进行微调以优化系统性能。这涉及物理层上的工作 — 创建索引、对数据分区和重新实现嵌入式逻辑以实现适当的性能。

概念性数据建模

关于问题域，不同的用户有不同的观点；开发团队的首要任务是分析和记载所有的问题。前面已经说过，对于开始这个过程，对概念性模型更改有可靠和确定的认知很重要。以前，修改用户界面很困难。用大型、分阶段的发行版来进行客户机端软件的升级。但是，因为 HTML 和脚本编制语言使修改网站上的最终用户经历变得如此容易，也因为“网络时代”是这样一个加速发展的参照系，所以现今的用户界面（UI）开发人员对其后端数据库施加了极大的压力，要求数据库象用户界面一样快速发展。

但是，有一件事没有变，那就是图是记载概念性模型的最佳方法。图形用户界面使绘制复杂图形的工作变得简单。并且过多语义数据模型的存在使不同图的意义规范化，因而使得开发人员团队能够清晰地交流关于用户的想法。这些语义模型的一部分包括：

• 扩展实体-关系建模（Extended Entity-Relationship Modeling (EER)）。EER 用类似于继承的概念和抽象数据类型（对象的域或类）扩展了传统的实体-关系建模（Entity-Relationship Modeling）。EER 分析的优秀手册包括 Toby Theorey 编写的 Database Modeling and Design（Morgan Kaufmann）和 Fleming 及 von Halle 编写的 Handbook of Relational Database Design（Addison Wesley）。
• 最近已开发了更高级的关系建模技术。其中最著名的是关系-角色建模（Object-Role Modeling）或 ORM。Terry Halpin 编写的 Conceptual Schema and Relational Database Design（Prentice Hall）极好地介绍了这种技术，并且，还大体上出色地介绍了概念性分析。
• 面向对象的分析和设计已经产生了几种极有用的图表绘制语言。其中最著名的是统一建模语言（ Universal Modeling Language）或 UML。尽管主要打算供使用与面向对象的编程语言的开发人员使用，但 UML 可以迅速地改写以同对象-关系 DBMS 一起工作。许多书籍和工具描述和使用了 UML。

有许多计算机辅助软件工程（Computer Assisted Software Engineering (CASE)）程序有助于开发人员使概念性建模自动化。遗憾的是，目前，这些工具中的大多数不能反映 ORDBMS 的全部能力。例如，它们不捕获关于组合到数据库表中的数据类型调色板的信息，或者是实现这些对象的行为的函数的信息。假以时日，这些工具将会改进。

扩展实体关系建模

为了清晰和简单起见，我们在示例中使用 EER 图表绘制模型。EER 并不妄想涵盖每种可能的建模情况，但它简单、直观并在大多数情况下工作得很好。

EER 在 ORDBMS 方法中的用法和在传统方法中用法的不同之处在于，我们对每个实体内容的分析稍有不同。用 EER 完成了对用户概念性模型的高级别概述后，我们使用面向对象技术来将实体分解成对象类的最小集合。有时我们将整个实体作为一个对象类对待。但更典型的情况是，组成实体的元素（每种元素的类型以及该类型在实体中担任的角色）可以被有效地建模成数据库中不可再分的含义单元（使用面向对象的分析技术）。

例如，考虑各个大学教授都喜爱的经典的“雇员／部门／产品／客户”数据库模式。自然地，我们的示例作了一点更新，并包含了一些使事情变得复杂的典型的实际细节，因此在传统 RDBMS 中难以处理。下面的图 3 表示了描述本示例高级概念性模型的扩展 ER（Extended ER）图。

图 3.“Boxes-R-Us Inc”的扩展 ER 模型

对我们的应用程序的简要描述看上去应该象这样：

“Boxes-R-Us Inc.（一个公司）制造和销售一系列各种颜色和尺寸的纸板盒产品（Product）给客户（Customer）。其制造分布到一系列分部（Branch）。公司的每个雇员（Employee）都在某个分部工作，但以后可能更换分部。雇员分类成不同的子类型：合同工（Contractor）和两种专职（Full_Time）雇员（生产 (Production) 工人和销售 (Sales) 人员）。之所以这样做，是因为雇员是按不同规程获得酬劳的，而规程是根据雇员类型制定的。销售人员按销售给客户的产品数量获得酬劳。”

当使用 ORDBMS 时，所有具有 EER 建模特征的建模概念都是有效的。和使用传统 EER 模型的示例一样，在您的图中记载下列内容是个很好的主意：

• 估计实体间“有一个（has_a）”关系的比率。在我们的示例中，使用“乌鸦脚”技术来表示每个分部制造多种产品，但产品不会由多个分部制造。其它概念，类似于必需关系（其中弱实体实例的存在依赖于相关的强实体的存在）和业务规则也很有用。
• 描述任何键。由于两个原因，键概念很重要。首先，键驱动规范化处理，这种处理使数据库设计师能够确保其模式中的每个事实仅被表示一次。其次，键经常表示一些关于数据的重要规则，这些规则应该强制执行以确保正在存储的数据是正确的。
• 小心地建模关系。上图中包含的一对关系比实体间简单的“有一个”关系复杂得多。雇员层次结构中反映了这样的第一个关系。在 ORDBMS 中表示此类继承层次结构比在 RDBMS 中直接得多。第二类关系是合格的。例如，一段时间，多个雇员在多个分部中工作。

让我们更详细地讨论这两种实体的内部结构。注：尽管我们在这里使用了相当标准的实体图，但您或许条件更好，将 UML 样式类图（Class Diagram）用于这个更详细的描述。您用 EER 分别对 RDBMS 和 ORDBMS 进行建模方法的一个重要区别是，ORDBMS 模型支持强类型（strong typing）。也就是说，所有属于相似类型（在关系理论中，我们称为域）都应该象这样标识。将所有这些域编目成 EER 模型的一部分要求您特别注意实际上构成每个实体元素的数据的类型。例如：

图 4. 来自 EER 模型的两个实体的详细结构

关于这些实体，有几件事情要指出。

首先，请注意有多少种不同数据的类型，以及强类型如何在概念性模型中捕获更多的语义信息。使用 RDBMS 技术时，将每个属性分解成一组原子组件并对每个组件分配一个 SQL-92 类型是很常见的。例如，我们可以使用 INTEGER 而不是 Employee_Num 和 Customer_Num。这带来了令人遗憾的结果，必须用属性的名称来区分信息的类型。使用 ORDBMS 时，很容易对应于每种数据对象类型创建单独的类型，并将属性的名称保留为属性在实体中的角色。

强类型是一种很好的编程实践。在遵守强类型的模式中，使用系统编目来发现各类关于模式中不同的部分组合在一起的消息已成为可能。例如，假设您希望了解数据库所知道的关于雇员的所有事情。在我们的模式中，雇员使用雇员号（雇员实体的主键是一个名为 Id 的属性，指定为 Employee_Num）标识。因此，模式中的所有有这种类型列的“表”都可以说是和雇员有一些关系的，即使没有定义通常的外键约束。

强类型在决策支持数据库中尤其有效。出于数据仓库目的，开发人员可能创建几个包含从几个操作系统抽取并被装入单个数据库的表。通常，类似于 Employee_Num 的数据对象是用来在不同系统之间交叉校验记录的值。一旦所有这些数据装入了单个数据库，强类型就允许可能不清楚有什么数据存在的开发人员来回答重要的元数据问题，类似于“我们有什么关于雇员的信息？”

当在这个级别执行分析时，不要研究太多关于您使用的数据的类型的细节是个好主意。如果您正在使用 RDBMS，两个 Address 属性可能分解成 First_Line、Second_Line、City、State 和 Zip。最有效地使用 ORDBMS 意味着采用略有差异的方法。一旦您已经标识了问题域中使用一种特殊数据的类型的每个位置，就处在了解它们共同拥有什么的更佳位置。然后，您可以一次开发对象的结构和行为而在整个模式中重用它。

包含雇员履历和住址的属性对 RDBMS 开发人员而言是陌生的。但是，这些是许多对象-关系数据库管理的数据的类型。在这些情况下，开发人员可以采购扩展包 — 称为 IBM Informix®；DataBlade® 模块 — 来管理这种数据的类型。

图 5. Products 实体的内部结构

关于组成 Products 实体的元素，有两点需要说明。

ORDBMS 数据模型支持非第一范式属性。这里，我们可以看到其使用的一个示例，该示例存储特定盒子可用的色彩范围。在这一阶段，不用过分担心如何在物理上表示这种结构。虽然 ORDBMS 表可以在单个栏中存储一组数据值，但如我们所见，这可能是最佳方法，也可能不是。

我们公司生产的每个盒子都有特定物理规格；其中最重要的是盒子的尺寸（多长、多宽、多高）以及强度如何（能容纳多少东西而不破裂）。对于 Boxes-R-Us，他们的商业效率取决于客户下订购的难易程度。这意味着，如果他们的数据库允许他们直接询问诸如物理重量以及“12 INCHES x 10 INCHES x 8 INCHES”的对象能否放进“31 CENTIMETERS x 31 CENTIMETERS x 31 CENTIMETERS”的盒子中这类事情，则是理想的。ORDBMS 可扩展性可以将与此类似的对象直接嵌入查询语言，这是构建商业应用程序时的最大好处。

那么，为什么所有这些活动都是有用的呢？因为它有助于您创建应用程序中各种数据的最小目录。正如我们所见，部分开发过程涉及使用 ORDBMS 的用户定义类型和用户定义的函数特性实现这些不同数据的类型。

面向对象分析和设计

面向对象分析和设计的中心思想是对象的接口（处理对象的方式）应该与其实现的详细信息（数据结构及其中逻辑）分开。OO 分析在开发 ORDBMS 数据库中所扮演的角色是使用可扩展的类型系统的概念性框架。使用用户定义的类型机制实现新对象。

这些类型的行为是在用户定义的函数中实现的。

首要任务是创建在 EER 模型中标识的所有各种数据的列表。这包括实体和组成这些实体的属性的各种数据。下表包含在我们的示例中标识的各种数据的部分列表，未按特定顺序排列。

图 6. 来自 Boxes-R-Us EER 模式的域列表

这种方法的重要优点是即使在整个模式的许多地方都可能使用共享数据对象，您也只需要开发它们一次。这样，如果您在分析的早期阶段发现错误或疏忽，则修正该错误相对容易。如果这些对象的定义分散在整个模式中的多处，则改正问题确实会变成一项很大的任务。

用户经常使用不同的术语来表示同一件事（同义词）或使用同一术语表示不同的事（反义词）。使用面向对象技术有助于您弄清这些含糊的术语。面向对象的软件工程技术以“对象”作为表示封装状态和行为的原子单元这一概念为中心。虽然没人会赞同这些名称，但如果两个对象在其处理方式上足够相似，则它们很可能是相同的。类似地，定义完全不同但具有相同名称的两种数据很可能是不同对象。

例如，Mail_Address 和 Delivery_Address 域可能会成为同义词。下图表示使用 UML 标准表示对象接口的每个对象的接口。UML 类图表示对象的静态结构，包括那个结构的元素是否可以由使用该类型的开发人员直接处理。从这些图中可以清晰地看出：这两种数据关系紧密，但不同之处在于 Delivery_Address 实例中可以包含提供发送详细指示的文档。

图 7. 两个类似对象的 UML 类图

将这一分析转变成实现计划时，开发人员有两种选择。首先，他们可以将这两个对象作为完全无关的类型开发。另一种，使用类型继承在 Delivery_Address 中重用 Mail_Address 类型的实现。通过使用类型继承来解决这个问题，开发人员将减少必须编写的代码总量。用来格式化 Mail_Address 中地址标签的代码可重用于 Delivery_Address。当然，如有必要，它们总是可以重载该行为。

数据的某些类型是模式（pattern）的示例。模式是许多类型使用的重复结构。模式很有用，因为它们允许您根据几个特征充实完整的设计。

枚举对象是一种很简单的模式示例。在我们的数据库中，情况可能是生产盒子的色彩的种类可能很有限，只有黑色、白色和棕色。为尽可能保持数据一致，开发人员可以使用枚举类型的实现来强制这些规则。在内部，Color 对象的实例可能被简单地存储为 2 字节整数。但是在向客户机程序返回值或将值插入表的代码中，开发人员可以编写一种逻辑以确保无效实例不可能发生。

描述这种情况的另一种方法是说新对象必须实现特定行为以用于特定的方法。例如，当客户或销售人员浏览产品目录时，他们可能按特定条件进行搜索。他们可能只想要能容纳三镑重的对象的盒子。换言之，他们想要容量超过三镑的盒子。为了有效浏览，他们想让查询按容量升序返回匹配的盒子。

这种查询可能类似于：

“显示容量大于三镑的所有盒子？”

图 8. 工作负载查询的示例

通过了解这类查询的重要性，您可以推断那些用户想把这个对象的实例与另一个进行比较、对它们进行排序、给它们加索引等。要支持这种功能，需要一个新类型以实现称为顺序运算符函数（LessThan、LessThanOrEqual、Equal、GreaterThanOrEqual、GreaterThan 和 NotEqual）和 B 树支持函数（Compare()）。

在下图中，我们显示 Mass 数据的类型的 UML 图。请注意我们在这个图中如何使用每个对象行为的完整定义。这有助于我们区别对象行为并标识多个类型的公共“保留”行为。

图 9. 带有顺序支持的 UML 类图示例

使用其它索引的其它类型需要提供不同的支持功能。例如，考虑用于存储特定雇员与分部关联的持续时间的 Period 数据的类型。Period 是带有起止日期和时间的对象。诸如重叠时段这样的有效支持概念需要类型包括 R 树访问方法可以使用的行为。

让我们更详细地分析雇员层次结构。回忆一下，将 Employees 分成子类别的主要理由是由于不同类型的雇员在 Boxes-R-Us 中执行的工作不同，所以他们的报酬也不同（其报酬的计算方法不同）。下图说明 Production 工人和 Sales 人员之间的差别。

图 10. 实体类型的 UML 类图

请注意这些定义中的重叠程度。除了与如何支付不同类型雇员相关的属性不同外，这两个实体完全相同。还请注意这两个实体是如何共享公共行为的。当我们分析其它类型雇员时，我们发现类似的模式。但是，用来计算报酬的算法根据雇员类别而变化。

在这个阶段，显然对行为进行规范化是一项重要任务。到目前为止引入的所有这些类都具有某些类型的行为。在某些情况下，如何表示该行为并不明显。例如，Mass 类可能需要迎合公制和英制单位，在这种情况下，它还需要解决两种单位之间的转换。有时，您将看到行为甚至也可能发生变化。用来计算销售代表年薪的精确算法可能每年都会变化，因为管理层试图引导销售人员完成不同的目标。

在这个方法的表示中，我们描述了一种自顶向下的方法。在将问题分解成其最小部分之前，首先标识和分析较大的结构。另一种同等有用的方法是从问题的最小组件分析开始，然后找出它们是如何组合的。这种称为自底向上分析方法的优点是较高级别结构（象表和它们之间关系）更改更迅速，并且修改更简单。通过首先集中于组合数据库中对象类型的综合调色板，您常会发现回答关于较高级别结构的问题更简单。确定适用于您项目的方法取决于您的喜好和经验。

数据流、工作负载和查询

本阶段要重点考虑的整体应用程序的另一个方面是工作负载：信息系统支持的一组公共查询和业务过程。工作负载的描述在多个方面有用。

首先，开发人员可以将实现业务操作的逻辑嵌入 ORDBMS，然后从客户机程序直接调用它们。当然，这不是什么新东西。关系 DBMS 支持这种数据库过程已经有一段时间了。但是许多开发人员在使用该技术时很谨慎，因为它虽然提供了改进的性能，但需要开发人员用专用过程语言开发代码。有了 ORDBMS，可以用使用标准 API 的开放语言（例如，Java 和 JDBC）实现这些数据库过程。

其次，早期 ORDBMS 技术采用者的经验之一是：通过将传统上与外部程序关联的逻辑引入 ORDBMS，他们可以改进其整体系统的性能和灵活性。例如，建议 Boxes-R-Us 在每个雇员生日时向他们发送一张贺卡或一封短信并不太难。正如我们先前所见，用 SQL-92 支持诸如“给出一个生日，然后确定今天是生日吗？”这种非常简单的操作是不可能的，因为匹配生日必须考虑在闰年的 2 月 29 日出生的人。在非闰年，这些人在 2 月 28 日过生日。理想情况下，您希望能够运行下列查询，让它处理复杂的问题。

图 11. 生日查询

在外部程序中，用诸如 C++ 或 Java 这类语言创建“Birthday”类显然是可行的。使用它将需要您编写查询检索在当前月份出生的每个人的姓名和生日（大约为全部数据的 1/12）。然后，在客户机端，Birthday 类中的编程逻辑将确定匹配。这种对象类可能与此类似：

图 12. 生日的 UML 类图

ORDBMS 数据模型的一条重要原则是：并非必须使用这样的类型来定义表的结构或列。可以使用这个对象的行为实现对其它常规数据的复杂查询操作，如图 11 所示。同样，大多数面向对象的方法承认有时您需要的不一定真的是一个对象，而只是函数或过程。让不熟悉面向对象的读者感到欣慰的是：完全可能象从前一样以完整的功能性或模块化方式来思考 ORDBMS 数据库的设计。

第三，工作负载目录为您提供了编写性能和可伸缩性测试环境的基础。新软件系统中最常见的技术故障原因之一就是开发人员没有在任何诸如生产环境之类的环境下测试他们实现的代码。

结束语

在本文中，我们已经研究了对象-关系数据库应用程序的初始开发方法。我们已经认识到为了最大限度地从 ORDBMS 中获益，开发人员需要收集的有关应用程序的问题域的信息通常比在关系 DBMS 开发中要收集的此类信息更多。因为 ORDBMS 允许他们嵌入到软件模块以表示在其问题域中对象的状态和行为，所以开发人员必须注意其应用程序的某些方面，传统上说，这些方面包括外部程序的任务、中间件或客户机接口。

通过结合使用扩展实体-关系建模和通用建模语言的方法以形象地表示类定义，我们可能获取一个应用程序并将其缩减为：

1. 对问题域感兴趣的对象的最小但完整的列表。
2. 将这些对象构造成我们想记录的事实的正确和一致的表示的方法。

在本系列最后一篇文章中，我们将描述一个过程，其中，可以使用 ORDBMS 数据模型的各种特性来表示我们在这里描述的语义模型。作为这一详细设计过程的一部分，我们回顾了不同机制之间的性能和灵活性权衡。

关于作者

Paul Brown 是 IBM 的 Chief Informix Technology Office 的“首席管子工”。Paul 与 Informix 首席技术官 Michael Stonebraker 博士合著了 Object-Relational DBMSs: Tracking the Next Great Wave。他是 Informix 的体系结构评审委员会的成员，他在 Informix 用户组会议以及伙伴论坛上定期发表演说，他还发表了有关数据库主题的许多论文。可以通过 pbrown1@us.ibm.com 与他联系。

IBM 和 DB2 是 IBM 公司在美国和／或其它国家或地区的商标或注册商标。

Java 和所有基于 Java 的商标和徽标是 Sun Microsystems，Inc. 在美国和／或其它国家或地区的商标或注册商标。

其它公司、产品和服务名称可能是其它公司的商标或服务标记。

IBM 版权和商标信息