DB2 的对象-关系精要（第 1 部分，共 2 部分）

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Kathy Zeidenstein, 数据管理 信息集成策略和标准, IBM 硅谷实验室

2002 年 6 月 01 日

描述 DB2 版本 7 中对用户定义的结构化类型和其它面向对象功能（如继承、方法、对象标识符、引用导航和方法动态分派（多态性））的支持。索引扩展允许在结构化和区别类型的数据上创建用户定义的索引规范，从而提高性能。JDBC 2.0 和 SQLJ Part 2 支持提供了编程环境和数据库服务器两者之间更紧密的集成。

简介

在这篇分为两部分的文章中，我将描述对象-关系技术，它是 DB2 最不为人知的秘密之一。对象-关系支持提供了向关系数据库扩展所必需的“管道”。DB2 家族的所有成员都支持巨对象类型、用户定义的函数和用户定义的区别类型。本文的焦点集中在基于用户定义的结构化类型的最新技术上，这项技术提供了对象的持久存储，它还包括面向对象的其它功能，如继承、使用方法的行为规范、对象标识符、引用导航和方法动态分派（多态性）。另外，索引扩展还允许在结构化和区别类型的数据上创建用户定义的索引规范，从而提高性能。JDBC 2.0 和 SQLJ Part 2 支持提供了编程环境和数据库服务器两者之间更紧密的集成。IBM 的很多技术（包括内容管理、空间数据和 XML 文档搜索）都依赖于对象-关系技术的支持，这个事实生动地说明了 DB2 向对象-关系功能作出的长期承诺。
在第 1 部分中，我将介绍 DB2 中的对象-关系功能，重点特别集中在用户定义的结构化类型和类型层次结构，以及使用表来存储这些类型（如类型化表）的实例上。我还会描述如何在旧的关系数据上使用“对象视图”。 第 2 部分将描述如何在列中存储结构化类型对象，如何在对象上调用方法，还要描述 SQLJ 和 JDBC 扩展，这些扩展会有助于将这些数据库对象集成到 Java 应用程序中。

回页首

DB2 的对象-关系精要

一小段历史……

1995 年，DB2 在所有其它主要数据库厂商之前提出了它第一个 对象-关系扩展。提供这些扩展的目的是为了满足很多应用程序日益迫切的需求，它们需要这些扩展来超越“普通的”关系数据库的处理能力。尽管大部分事务数据可以被映射为通常的数据类型（货币映射为十进制类型，名称映射为字符串类型，日期映射为日期字符串类型），但图形系统和文本管理系统的出现意味着数据值会非常庞大。视频和音频数据甚至会更大。使用现有的技术来处理此类数据非常困难。

为了满足这种应用需求，DB2 通用数据库（DB2 Universal Database™，UDB）在其版本 2 发行版中提出了可以在单个数据值中存储大量数据的新数据类型。这减轻了应用程序的负担，使其不必将字符串接合在一起来组成文档。反之，整个文档或图像都可以存储在一个新的 巨对象类型中：字符巨对象（character large object，CLOB）、二进制巨对象（binary large object，BLOB）和双字节字符巨对象（double-byte character large object，DBCLOB）。为了使在应用程序中处理 LOB 更容易，客户机应用程序中有用于操作 LOB 的内置函数和在客户端应用程序将 LOB 数据作为文件或定位器处理的技术。尽可能地延迟 LOB 实例化可以大大优化 LOB 操作。

除了加入新的类型之外，我们还可能使数据库更容易理解存储在其中的数据的意图。用户可以定义 区别类型，也就是基于现有类型，但在名称和语义上与系统中定义的其它所有类型截然不同的类型。这向用业务术语定义数据和在数据库中封装业务语义迈出了重要的一步。

因为区别类型是建立在预定义类型的基础之上，所以出于性能的原因，它们被紧密地集成在数据库管理程序中。它们和预定义类型共享用于实现内置函数、比较操作符、索引等相同的高效代码。DB2 优化程序可以进行有效的优化，因为它能够深入地理解底层数据类型表示。

区别类型的行为是由用户定义的函数定义的。用户定义的函数就是应用程序逻辑（或者 DB2 内置的标量函数），它操作数据值并返回结果。这样，通过结合用户定义的函数和区别类型，简单对象或巨对象数据类型对特定的应用程序域就变得有意义了。数据库引擎可以强制业务规则，因为它知道除非先进行必需的转换（通过用户定义的函数），否则是不能允许比较美元和日元的。DB2 还支持函数名的 重载，并根据一种有效的“最适合的”算法选择合适的函数。

DB2 中引入的另一个功能就是从函数（而不是标量值）返回表（记录集）的能力。这种功能很强大，因为它可以使任何数据源看起来都象 DB2 表一样，然后这些数据源就可以用于普通的 SQL 查询、连接操作和分组等。

DB2 还包括了音频、图像、视频以及文本的类型和函数。这些预包装的类型和行为被称为 DB2 Extender™。当然，这些类型只是 DB2 中可以定义的一小部分，不过这些类型是基于内容的环境中使用的典型类型。DB2 的扩展性的确是驱动 IBM 的 Content Manager 产品的因素之一。

回页首

最近加入的内容：结构、行为和继承

加入的巨对象类型让应用程序可以用我们熟悉的方式处理大的、复杂的类型；也就是通过使用关系数据库存储和检索数据值。此外，能够命名这些类型和定义这些类型的行为还使应用程序不再需要支持语义检查和业务逻辑。

然而，巨对象类型中存储的所有数据本质上都是平面的 — 一个字符串或位串 — 它可以很好地避免与存储在其中的商业对象之间产生联系。这可以把将巨对象读取到应用程序工作区中的任务交给应用程序，把该对象“解析”到需要修改的地方，然后把对象存回数据库。

对于某些类型的数据来说，将对象作为属性经过命名的集合更有意义。这种特殊的用户定义的类型被称为 结构化类型，它在 1998 年被引入 DB2 UDB 版本 5.2 中。它最初的功能不仅提供了创建结构化类型的能力，还允许使用类型层次结构定义和表层次结构的同等存储机制。该发行版还引入了“引用”的使用，用来定义对象之间的关系和在对象之间进行导航。

结构化类型提供了一种创建模式的方法，这种方法对于那些习惯于 OO 编程语言的人来说更加自然 — 这些编程语言包括继承属性和“is-a”关系（值可替代性）的建立。结构化类型对于在应用程序中植入 Java 对象更加适合。

您可以为定义结构化类型的行为使用用户定义的函数。然而，DB2 版本 7 实现了为定义对象行为定义 方法的能力。方法和用户定义的函数非常相似，因为它们也可以用外部语言（如 Java 或 C）或 SQL 来编写。然而，方法经常与特定的结构化类型相关联，并使用不同的句法进行调用。方法适合于实现真正可以看成是特定类型“所有”或归结于该特定类型的行为的情况。无论使用何种环境，类型的行为是伴随着类型的。相反，函数在参数上则支持更对称的视图。

回页首

在“传统”数据上使用对象-关系功能

DB2 的任何对象-关系功能都能够用于传统的 SQL。一个应用程序可能只需要 LOB 支持，而另一个应用程序则可能希望充分利用结构化类型、方法和继承。另外，通过使用本文中描述的对象视图支持，我们甚至可以在关系数据上使用面向对象的建模。

回页首

结构化类型化表（“类型化表”）

在这一部分，我们将集中在使用类型化表的基础上。通过创建对象模型，我们可以更容易地考虑将模型映射为 DB2 中可用的构造。

请考虑下面的情况：

• 利用类型层次结构和继承会对您有好处吗？有了 DB2 的结构化类型，您就可以定义类型层次结构了。就象使用面向对象编程语言中的类层次结构一样，使用 DB2 结构化类型建模的对象也继承了它们的超类型（在层次结构中类型之上的类型）的属性。在上面的模型中，我们为所表示的“人”对象的各种类型使用了继承。
• 在版本 7 中，您可以选择将结构化类型对象存储为类型化表行，也可以选择将其存储为常规表或类型化表的单个列。您会如何选择？通常，当那些对象是对象模型中“主要的”实体（如人和部门）时，您会将对象存储为表中的行。
• 还有一些对象也是存储在类型化表中的很好选择，它们是必须被其它对象所引用和共享的对象（由雇员、航运等使用的商业地址），或者独立于另一个对象而存在的对象（删除一个部门并不意味着经理会离开）。如果关系是牵制性和依赖性之一，那么对象就可以存储为一列（注意：这一点在第 2 部分中有更详细的描述）。
• 当对象作为行存储在表中时，表的每一列都包含对象的一个属性，而且您可以象访问 DB2 表的任何列一样访问对象的属性。
• 您应该如何将属性映射为 DB2 数据类型呢？您不仅将需要考虑一个属性将使用多大空间，还需要考虑您试图从任何属性或属性的组合中取回的信息类型。

对于名字和工资这样的情况，一般从属性到数据的映射通常都很简单，它们可以被轻易地映射为字符和数字数据类型。对于很大的对象来说（如图像或很长的文本描述），您可能就需要选择 DB2 的一种特别为存储很大的对象而设计的数据类型了。这些数据类型是 CLOB（字符巨对象）、BLOB（二进制巨对象）或 DBCLOB（双字节字符巨对象）。

您甚至可以使用结构化类型来定义属性。这被称为嵌套。在属性有结构（如地址）或您的列可以容纳不同的子类型（如几何元素，即形状、线条、点、多边形、圆、矩形等等）时，您可能希望这样做。我们将在第 2 部分中更详细地讨论嵌套。

回页首

创建“类”：DB2 中的类型层次结构

当您创建用户定义的结构化类型时，使用句法和创建表所用的句法十分相似；您指定类型名、它的属性名以及属性的数据类型。如果您在结构化类型下创建子类型，那么这些子类型就会自动继承层次结构中在它们之上的类型（ 超类型）的属性。

回页首

存储对象：创建表层次结构

类型层次结构和引用的加入为查询带来了好几个增强功能，包括轻松地在对象间遍历引用的能力和对子集隐式考虑的支持。

执行官是雇员，也是人……

表层次结构有值可替代性的属性；也就是说，它会建立一个“is-a”关系。对表的查询其实是对表和它所有子表中对象集合的查询。SELECT、DELETE 和 UPDATE 语句都应用在选定的表和其任何子表上。然而，只有为选定的表所定义的属性才会被返回。当您从 Person_table 选择所有列时，Person_table 和它的任何子表中的对象都会被检索，但只有属于 person 的属性（列，包括从它的超类型中继承的）才会被返回。

SELECT P.* FROM Person_table P;

如果查询代之以 SELECT * FROM Employee_table ，所有的 Employee 属性中只有属于 employee 和 executive 的才会被返回。这种模式当然比强制将“人”的所有不同类型转到同一个表中并为不同的类型值应用搜索谓词要简单得多。

表层次结构的 OUTER 联合：选择所有属性

如果您希望看到来自所选择的表和其子表的所有属性，请使用表层次结构上的 OUTER 联合：例如，SELECT * FROM OUTER(Employee_table)将返回带有雇员所有属性的结果，并包括执行官（executive）才有的奖金（bonus）。对于不适用于返回行的属性，将返回空值。

SELECT * FROM OUTER(Employee_table)

使用 ONLY “关闭”子表检索

在 FROM 子句中使用 ONLY 来将检索的对象限制为指定表中的对象，而不是任何子表中的对象。

SELECT * FROM ONLY (Person_table);

回页首

使用路径表达式简化关系查询

反引用操作符（->）在 路径表达式中使用。路径表达式提供了一个比使用连接来从相关对象选择属性的传统方法简单得多的句法。路径表达式并不表达正确的连接条件，而是允许您遍历对象之间的基于引用的关系。例如，雇员和部门有一个可引用的关系。部门中有经理（他们碰巧也是雇员），而雇员有对应的部门。要查找雇员名和工资以及对应的部门 ID 和经理，而且这些部门的预算都在 200000 美元以上，您就可以发出下面的查询：

SELECT E.name, E.salary, E.dept->ID, E.dept->manager->name AS MANAGER
FROM Employee_table E
WHERE E.dept->budget >200000

使用路径表达式可以查询甚至更复杂的关系。例如，假定您希望查找经理的经理为 Lou Gerstner 的所有雇员的名称。您可以这样做，并避免必须编写五路连接的情况：

SELECT E.name
FROM Employee_table E
WHERE E.dept->manager->dept->manager->name='Lou Gerstner';

如果非类型化表包括 REF（ 数据类型）作为一列，您甚至可以在类型化和常规（非类型化）表之间使用路径表达式。

引用所表示的关系与可引用完整性表示的关系有所不同（尽管在引用上也使用可引用完整性是绝对可能的）。DB2 在内部将路径表达式作为左外连接对待，这意味着路径表达式将利用 DB2 复杂的连接优化。DB2 还会进行检查，以确保执行查询的 ID 享有读取所有引用的表的访问权。

回页首

丰富的查询能力

类型层次结构和引用的加入为查询带来了好几个增强功能，包括轻松地在对象间遍历引用的能力和对子集隐式考虑的支持。

执行官是雇员，也是人……

表层次结构有值可替代性的属性；也就是说，它会建立一个“is-a”关系。对表的查询其实是对表和它所有子表中对象集合的查询。SELECT、DELETE 和 UPDATE 语句都应用在选定的表和其任何子表上。然而，只有为选定的表所定义的属性才会被返回。当您从 Person_table 选择所有列时，Person_table 和它的任何子表中的对象都会被检索，但只有属于 person 的属性（列，包括从它的超类型中继承的）才会被返回。

SELECT P.* FROM Person_table P ;

如果查询代之以SELECT * FROM Employee_table，所有的 Employee 属性中只有属于 employee 和 executive 的才会被返回。这种模式当然比强制将“人”的所有不同类型转到同一个表中并为不同的类型值应用搜索谓词要简单得多。

表层次结构的 OUTER 联合：选择所有属性

如果您希望看到来自所选择的表和其子表的所有属性，请使用表层次结构上的 OUTER 联合：例如，SELECT * FROM OUTER(Employee_table)将返回带有雇员所有属性的结果，并包括执行官（executive）才有的奖金（bonus）。对于不适用于返回行的属性，将返回空值。

SELECT * FROM OUTER(Employee_table)

使用 ONLY “关闭”子表检索

在 FROM 子句中使用 ONLY 来将检索的对象限制为指定表中的对象，而不是任何子表中的对象。

• SELECT * FROM ONLY (Person_table);

使用路径表达式简化关系查询

反引用操作符（->）在 路径表达式中使用。路径表达式提供了一个比使用连接来从相关对象选择属性的传统方法简单得多的句法。路径表达式并不表达正确的连接条件，而是允许您遍历对象之间的基于引用的关系。例如，雇员和部门有一个可引用的关系。部门中有经理（他们碰巧也是雇员），而雇员有对应的部门。要查找雇员名和工资以及对应的部门 ID 和经理，而且这些部门的预算都在 200000 美元以上，您就可以发出下面的查询：

SELECT E.name, E.salary, E.dept->ID, E.dept->manager->name AS MANAGER
FROM Employee_table E
WHERE E.dept->budget >200000

使用路径表达式可以查询甚至更复杂的关系。例如，假定您希望查找经理的经理为 Lou Gerstner 的所有雇员的名称。您可以这样做，并避免必须编写五路连接的情况：

SELECT E.name
FROM Employee_table E
WHERE E.dept->manager->dept->manager->name='Lou Gerstner';

如果非类型化表包括 REF（ 数据类型）作为一列，您甚至可以在类型化和常规（非类型化）表之间使用路径表达式。

引用所表示的关系与可引用完整性表示的关系有所不同（尽管在引用上也使用可引用完整性是绝对可能的）。DB2 在内部将路径表达式作为左外连接对待，这意味着路径表达式将利用 DB2 复杂的连接优化。DB2 还会进行检查，以确保执行查询的 ID 享有读取所有引用的表的访问权。

回页首

对象视图

在关系系统中，视图扮演了很重要的角色，它使数据与应用程序保持独立，并控制对敏感数据的访问。这些用途非常关键，所以在保持对象-关系本性的同时在对象-关系体系结构上具有相同能力是很重要的。换句话说，方法调用、可替代性、路径表达式都应该能够使用。另外，还需要将“旧”数据转换成对象-关系表／视图层次结构。

对象视图满足这些需求。

对象视图是可以有结构和行为的“虚拟的类型化表”，但它的结构和行为与底层基本表的又有所不同。对象视图定义使用结构化类型定义作为基础，这一点和类型化表完全一样。这些视图定义可以用来限制对表层次结构多个行的子集的访问，也可以通过只允许经由视图层次结构的访问从而隐藏表层次结构的某些列。

如果仅为视图中选择了多个行或表的子集，那么已经存在的结构化类型定义就可以作为视图定义的基础而使用。然而，如果属性／列的集合或通过视图提供的行为需要改变，那么我们就需要定义一个新的类型层次结构，作为视图层次结构的基础。例如，假定我们希望创建一组不包含月薪、周薪或地址信息的视图，其中不包括执行官和学生，而且只包括预算很大的部门。创建这样一个类型层次结构的类型定义只是比我们已经创建的 person 类型层次结构简单一点（属性少一点）。视图定义的主体会告诉您如何从基本表植入这些视图。

请注意 ONLY 关键字的使用，它将确保每个视图只从原始层次结构合适的子表植入。如果没有 ONLY，每个视图的层次结构中相应位置上或低于该位置的所有对象都会被植入该视图，这并不是我们在本示例中所希望的。

还要注意，由于 OID 列是一个引用类型，而引用类型是强制类型，所以不能直接从表的 OID 强制转换到视图的 OID；强制转换必须先转换到基本类型，然后再从基本类型（VARCHAR）转换到视图类型（vperson_t）。

		CREATE TYPE vperson_t AS
(name varchar(20))
NOT FINAL
MODE DB2SQL;
CREATE TYPE vemployee_t
UNDER vperson_t 
NOT FINAL
MODE DB2SQL; 
CREATE TYPE vdepartment_t AS 
(ID INTEGER,
manager REF(vemployee_t))
NOT FINAL
MODE DB2SQL;
altER TYPE vemployee_t
ADD ATtrIBUTE dept ref(vdepartment_t);

		CREATE VIEW vperson OF vperson_t
MODE DB2SQL
(REF IS oid USER GENERATED)
AS SELECT vperson_t(VARCHAR(oid)),
name FROM ONLY (Person_table);
CREATE VIEW vemp OF vemployee_t 
MODE DB2SQL 
under vperson
INHERIT SELECT PRIVILEGES
AS SELECT 
vemployee_t(VARCHAR(oid)), name, 
vdepartment_t(varchar(dept)) 
FROM ONLY (Employee_table)
CREATE VIEW vdept_bigbudget OF
vdepartment_t
MODE DB2SQL
(REF IS oid USER GENERATED,
Manager WITH OPTIONS SCOPE vemp)
AS SELECT vdepartment_t(varchar(oid)),
ID, vemployee_t(varchar(manager)) 
FROM Dept_table WHERE budget>100000; 
altER VIEW vemp altER ColUMN dept 
ADD SCOPE vdept_bigbudget; 

那么，因为原始类型化表中（employee_table 和 dept_table 之间）基于引用的关系被转到相应的对象视图，所以如下所示的查询也是可能的：

SELECT name, dept->ID
FROM vemp;

因为其中两个雇员属于预算低于 100000 的部门，所以这两个雇员的部门 ID 将返回空值。

DB2 有一种异乎寻常的能力，就是可以把视图处理为可更新的。这种能力对让视图真正有用于避免访问基本表是重要的。这种能力还可以扩展到对象视图，甚至从多个基本表创建的对象视图上。

回页首

使用对象视图“对象化”旧数据

对象视图提供了很多功能：它们可以更新，视图主体（视图的语义）和类型定义是分开的，而且通过这些视图看到的对象可以被操作，方法也可以通过对象标识和引用在对象上进行调用，这些都和基本表中对象可以提供的功能一样。因为对象视图提供了如此丰富的功能，所以它们也可以用来为商业数据创建“OO 外观和感觉”，这些商业数据总是以一种严格的关系模式驻留和操作。旧的应用程序可以继续使用基本表（或非类型视图），而新的应用程序可以根据对象视图运行。

下面的步骤可以用来根据上面所示的模式创建旧数据上的对象视图：

1. 创建层次结构化类型来匹配表。

   CREATE TYPE Supplier_t AS (name VARCHAR(20)) REF USING INTEGER MODE DB2SQL; CREATE TYPE Parts_t AS (name VARCHAR(20), Price DECIMAL (5,2), Supplier REF(Supplier_t), Qty INTEGER) MODE DB2SQL REF USING VARCHAR (10);

   创建提供者类型来映射为 Supplier 关系表。请注意，我们在对象视图中将使用 SuppID 列作为对象标识符； 因此，它不能被作为类型定义的一部分来指定。 因为 SuppID 列被定义为 INTEGER，所以请使用 REF USING 子句将对象标识符的底层类型指定为 INTEGER。 类似地，对于部分类型，对象标识符列被映射为 Parts 表的主键的数据类型（数据类型 VARCHAR(10) 的 Partno 列）。

2. 现在我们可以创建类型化表了。

   CREATE VIEW v_suppliers of Supplier_t MODE DB2SQL (REF IS Supp_ID USER GENERATED) AS SELECT supplier_t(Supp_ID), name FROM Suppliers; CREATE VIEW v_parts OF parts_t MODE DB2SQL (REF IS Partno USER GENERATED, Supplier WITH OPTIONS SCOPE scope v_suppliers) AS SELECT parts_t(Partno), name, Price, Supplier_t(supplier), qty FROM Parts;

   基本表的 SuppID 列是视图的对象标识符列，但必须强制转换为视图定义中的 REF 类型。 这里是部分视图的创建过程。我们还可以向 SELECT 添加另外的谓词，从而进一步限制视图中将植入哪些行。

现在，路径表达式就可以使用了：

SELECT Partno, Supplier->name AS Supplier_name FROM v_parts
WHERE Price > .05;

方法也可以被调用了，DB2DD 的下一个修订版的第 2 部分将展示这一点。

更多信息

DB2 通用数据库 V7， Application Development Guide。请特别参阅标题为“Object-Relational Programming”的那一章。

DB2 通用数据库 V7， SQL Reference。

Michael J. Carey、Serge Rielau 和 Bennet Vance 所著的“Object View Hierarchies in DB2 UDB”。 EDBT2000 ：478-492，1999

Michael J. Carey、Donald D. Chamberlin、Srinivasa Narayanan、Bennet Vance、Doug Doole、Serge Rielau、Richard Swagerman 和 Nelson Mendonca Mattos 所著的“O-O, What's Happening to DB2?” SIGMOD Conference1999：511-512

Michael J. Carey、Donald D. Chamberlin、Srinivasa Narayanan、Bennet Vance、Doug Doole、Serge Rielau、Richard Swagerman 和 Nelson Mendonca Mattos 所著的“O-O, What Have They Done to DB2?” VLDB1999：542-553

Chen、Weidong 等人所著的“High Level Indexing of User-Defined Types” Proceedings of the 25th VLDB Conference，爱丁堡，苏格兰，1999

N. M. Mattos、J. Kleewein、M. Tork Roth 和 K. Zeidenstein 所著的“From Object-Relational to Federated Databases”， Datenbanksysteme in Buro，Technik und Wissenschaft。1999 年 3 月 1 日：185-209。

关于作者

		Kathy Zeidenstein 自 1987 年起就在 IBM 的硅谷实验室工作。她开始时在 DB2 for OS/390 ® 组织中工作，在那里她第一次接触到了对象-关系。开始在 SQL 标准小组工作之后，她接触到了 DB2 中更高级的对象-关系功能，因为这项工作的很多语言设计都是提交到 SQL 标准协会的。如果没有实现此项技术的开发小组的帮助，本文可能就不会被撰写出来了。就在最近，Kathy 已经在商业智能小组工作，现在的工作和 IBM 新的信息集成策略有关。 您可以通过 krzeide@us.ibm.com与 Kathy Zeidenstein 联系。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首