第十五章对象关系数据库系统 本章介绍对象关系数据库系统 (Object Relational DataBase System,ORDBS) ORDBS 是面向对象数据模型 (Object Oriented Data Model, 以下简称 OO 模型 ) 和关系数据模型相结合的产物 数据库技术在商业领域的巨大成功刺激了其他领域对数据库技术需求的迅速增长 这些新的领域既为数据库应用开辟了新天地, 又提出了新的数据管理需求, 给数据库技术提出了挑战 新应用的挑战主要来自多种数据类型的应用领域, 例如, 计算机辅助排版系统中的大文本, 天气预报中的图像, 工程设计中复杂的图形数据, 股票市场交易历史中的时间序列数据, 空间和地理数据, 等等 由于传统数据库系统的设计目标源于商业事务处理, 它们难以适应和满足新的数据库应用需求 例如,RDBMS 只支持简单有限的数据类型, 不支持用户自定义的数据类型 ; 不支持用户自定义的运算和函数 ; 不能清晰地表示复杂对象 ; 没有全系统唯一的标识符等 这些是关系模型所不支持的 为此人们研究了非一范式的关系模型 语义数据模型 面向对象数据模型等 其中以面向对象数据模型最有影响 从 20 世纪 80 年代起, 国内外学术界 工业界努力探索数据库技术与对象技术的结合, 沿着三条路线展开了 OO 数据模型和面向对象数据库系统的研究 : 一条是以面向对象的程序设计语言为基础, 研究持久的程序设计语言, 支持 OO 模型 ; 一条是建立新的面向对象数据库系统 OODBS, 支持 OO 数据模型 ; 一条是以关系数据库和 SQL 为基础, 把面向对象技术融入数据库系统的 ORDBS 回顾上述 3 个方向所做的研究及开发工作, 可以看到它们的发展是不平衡的 其中 ORDBS 方向的成果最为卓著 它在传统关系数据库的基础上吸收了 OO 模型的主要思想, 同时又保持了关系数据库系统的优点, 成功开发了诸如 Postgres,Illustra 等原型系统 近年来, 各大 RDBMS 厂商也已推出了其产品的对象 - 关系版本, 从而满足了许多新的数据库应用需求 面向对象数据模型是继关系数据模型之后最重要的数据模型 本章 15.1 节首先简单介绍 OO 模型的基本概念, 然后下面各节讲解 ORDBS 15.1 面向对象数据模型 面向对象数据库系统支持 OO 模型
也就是说, 一个面向对象数据库系统是一个持久的 可共享的对象库的存储和管理者 ; 而一个对象库是由一个 OO 模型所定义的对象的集合体 15.1.1 OO 模型的核心概念一个 OO 模型是用面向对象观点来描述现实世界实体 ( 对象 ) 的逻辑组织 对象间限制 联系等的模型 一系列面向对象核心概念构成了 OO 模型的基础 概括起来,OO 模型的核心概念有如下几个 1. 对象 (Object) 对象是由一组数据结构和在这组数据结构上的操作的程序代码封装起来的基本单位 对象通常与实际领域的实体对应 一个对象包括以下几个部分 l 属性 (Attribute) 集合 : 所有属性合起来构成了对象数据的数据结构 ( 有的书上称为变量集合 ) 属性描述对象的状态 组成和特性 对象的某一属性可以是单值的或值的集合, 也可以是一个对象, 即对象可以嵌套 这种嵌套可以继续, 从而组成各种复杂对象 l 方法 (Method) 集合 : 方法描述了对象的行为特性 方法的定义包括两部分, 一是方法的接口, 二是方法的实现 方法的接口用以说明方法的名称 参数和结果返回值的类型, 也称之为调用说明 方法的实现是一段程序编码, 用以实现方法的功能, 即对象操作的算法 2. 对象标识 OID(Object IDentifier) 面向对象数据库中的每个对象都有一个唯一的不变的标识称为对象标识 (OID) 对象标识具有永久持久性, 即一个对象一经产生系统就会赋于一个在全系统中唯一的对象标识符, 直到它被删除 OID 是由系统统一分配的, 唯一的, 用户不能对 OID 进行修改 因此,OID 与关系数据库中码 (Key) 的概念和某些关系系统中支持的记录标识 (RID) 元组标识(TID) 是有本质区别的 OID 是独立于值的 系统全局唯一的 3. 封装 (Encapsulation) 每一个对象是其状态与行为的封装, 其中状态是该对象一系列属性值的集合, 而行为是在对象状态上操作的集合, 操作也称为方法 OO 模型的一个关键概念就是封装 每一个对象是其状态与行为的封装 封装是对象的外部界面与内部实现之间实行清晰隔离的一种抽象, 外部与对象的通信只能通过消息, 这是 OO 模型的主要特征之一 但是, 对象封装之后查询属性值必须通过调用方法, 不能像关系数据库系统那样 ( 用 SQL) 进行即席的 ( 随机的 ) 按内容的查询, 这就不够方便灵活, 失去了关系数据库的重要优点, 因此在 OODB 中必须在对象封装方面作必要的修改或妥协
4. 类 (Class) 共享同样属性和方法集的所有对象构成了一个对象类 ( 简称类 ), 一个对象是某一类的一个实例 (instance) 例如, 学生是一个类, 李勇 刘晨 王敏 张立等是学生类中的对象 在数据库系统中, 一再要大家注意区分 型 和 值 的概念 在 OODB 中, 类是 型, 对象是某一类的一个 值 类属性的定义域可以是任何类, 即可以是基本类, 如整数 字符串 布尔型, 也可以是包含属性和方法的一般类 特别地, 一个类的某一属性的定义也可是这个类自身 可以看到, 类的概念类似关系模式, 类的属性类似关系模式中的属性, 对象类似元组的概念, 类的一个实例对象类似关系中的一个元组 可以把类本身也看作一个对象, 称为类对象 (Class Object) 面向对象数据库模式是类的集合 15.1.2 类层次 ( 结构 ) 在一个面向对象数据库模式中, 会出现多个相似但又有所不同的类 例如, 教职员工和学生两个类都有身份证号, 姓名 年龄 性别 住址等属性, 也有一些相同的方法 当然, 教职员工对象中有一些特殊的属性和方法, 如工龄 工资 办公室电话号码 家庭成员数 教职员工和学生的公共属性和方法部分可以统一定义, 各自的特殊属性和方法部分可以分别定义 为此, 面向对象的数据模型提供了一种类层次结构 例如, 可以定义一个类 人 人的属性和方法是教职员工和学生的公共属性和公共方法 教职员工类和学生类定义为人的子类 教职员工类只包含教职员工的特殊属性和特殊方法 学生类也只包含学生的特殊属性和特殊方法, 如图 15.1 所示 图 15.1 学校数据库的类层次结构图为了叙述简单, 没有给出这些类的方法 在这个类层次中教职员工和学生是人的子类, 教员 行政人员和工人是教职员工的子类 教员 行政人员 工人中实际只有它本身的特殊属性和方法, 同时它们又继承教职员工类和人的所有属性和方法 因此, 逻辑上它们具有人 教职员工和本身的所有属性和方法 同样, 本科生和研究生是学生的子类 超类 / 子类之间的关系体现了 ISA 的语义, 例如, 图 15.1 中教员 ISA 教职员工, 教职员工 ISA 人 因此, 超类是子类的抽象 (Generalization) 或概括, 子类是超类的特殊化
(Specialization) 或具体化 类层次可以动态扩展, 一个新的子类能从一个或多个已有类导出 根据一个类能否继承多个超类的特性将继承分成了单继承和多重继承 (multiple inheritance) 15.1.3 继承在 OO 模型中常用的有两种继承, 单继承与多重继承 若一个子类只能继承一个超类的特性 ( 包括属性和方法 ), 这种继承称为单继承 ; 若一个子类能继承多个超类的特性, 这种继承称为多重继承 例如, 在学校中实际上还有 在职研究生, 他们既是教员又是学生, 在职研究生继承了教职员工和学生两个超类的所有属性和方法, 如图 15.2 所示 图 15.2 具有多继承的类层次结构图 单继承的层次结构图是一棵树 ( 如图 15.1), 多继承的层次结构图是一个带根的有向无回路图 ( 如图 15.2) 继承性有两个优点, 第一, 它是建模的有力工具, 提供了对现实世界简明而精确的描述 第二, 它提供了信息重用机制 由于子类可以继承超类的特性, 这就可以避免许多重复定义 当然子类除了继承超类的特性外还要定义自己特殊的属性和方法 在定义这些特殊属性和方法时可能与继承下来的超类的属性和方法发生冲突, 例如在教职员工类中已经定义了一个操作 打印, 在教员子类又要定义一个操作 打印, 这就产生了同名冲突 这类冲突可能发生在子类与超类之间, 也可能发生在子类的多个直接超类之间 这类冲突通常由系统解决, 在不同的系统中使用不同的冲突解决方法, 便产生了不同的继承性语义 例如, 对于子类与超类之间的同名冲突, 一般是以子类定义的为准, 即子类的定义取代或替换由超类继承而来的定义 对于子类的多个直接与超类之间的同名冲突, 有的系统是在子类中规定超类的优先次序, 首先继承优先级最高的超类的定义 ; 有的系统则指定继承其中某一个超类的定义 子类对父类即有继承又有发展, 继承的部分就是重用的成分 由封装和继承还导出面向对象的其他优良特性, 如多态性 动态联编等
15.1.4 对象的嵌套前面已经讲到, 在一个面向对象数据库模式中, 对象的某一属性可以是单值的或值的集合 进一步地, 一个对象的属性也可以是一个对象, 这样对象之间产生一个嵌套层次结构 对象嵌套概念是面向对象数据库系统中又一个重要概念 设 Obj 1 和 Obj 2 是两个对象 如果 Obj 2 是 Obj 1 的某个属性的值, 称 Obj 2 属于 Obj 1, 或 Obj 1 包含 Obj 2 一般的, 如果对象 Obj 1 包含对象 Obj 2, 则称 Obj 1 为复杂对象或复合对象 Obj 2 是 Obj 1 的组成成分, 也可称是 Obj 1 子对象 Obj 2 还可以包含对象 Obj 3, 这样 Obj 2 也是复杂对象, 从而形成一个嵌套层次结构 [ 例 1] 每辆汽车包括 : 汽车型号 汽车名称 发动机 车体 车轮 内部设备等属性 其中汽车型号和汽车名称的数据类型是字符串, 发动机不是一个标准数据类型, 而是一个对象, 包括 : 发动机型号 马力等属性 ; 车体也是一个对象, 包括 : 钢板厚度 钢板型号 车体形状等属性 ; 内部设备也是一个对象, 包括 : 车座 音响设备 安全设备等属性 ; 音响设备也可以是一个对象, 包括 :VCD 喇叭等属性, 如图 15.3 所示 图 15.3 汽车的嵌套层次图 对象嵌套层次结构和类层次结构形成了对象横向和纵向的复杂结构 这是说, 不仅各种类之间具有层次结构, 而且某一个类内部也具有嵌套层次结构, 它不再像一个关系模式那样是平面结构的了, 一个类的属性可以是一个基本类, 也可以是一个一般类 作为本节小结, 表 15.1 给出了关系数据模型与 OO 模型主要特性的比较
表 15.1 关系数据模型与 OO 模型的比较 内容 关系数据模型 面向对象数据模型 基本数据结构 二维表 类 数据标识符 码 OID 静态性质 属性 属性 动态行为 关系操作 方法 抽象数据类型 无 有 封装性 无 有 数据间关系 主外码联系, 数据依赖 继承 组合 模式演化能力 弱 强 15.2 对象 - 关系数据库 ORDBS 是关系数据库系统与面向对象数据模型的结合 它保持了关系数据库系统的非过程化数据存取方式和数据独立性, 继承了关系数据库系统已有的技术, 支持原有的数据管理, 又能支持 OO 模型和对象管理 SQL3 是 1999 年发布的 SQL 标准, 也称为 SQL99 其显著的特点之一是提供了面向对象的扩展, 增加了 SQL/Object Language Binding SQL3 的扩展使我们可以同时处理关系模型中的表和对象模型中的类与对象 SQL3 对 ORDBMS 标准的制定滞后于实际系统的实现 所以各个 ORDBMS 产品在支持对象模型方面虽然思想一致, 但是所采用的术语 语言语法 扩展的功能都不尽相同 下面的讲解以 SQL3 为主要参考, 适当加上某些产品的功能和特点 读者在使用具体产品时要以各个产品的手册为准 15.2.1 对象关系数据库系统中扩展的关系数据类型 SQL3 对关系数据库的数据类型进行了扩展, 克服原来关系数据库数据类型单一的缺点 扩展的类型包括 :LOB BOOLEAN 集合类型 ARRAY 用户定义的 DISTINCT 类型等 SQL3 最重要的扩展是面向对象的数据类型, 包括行类型 ROW TYPE 和抽象数据类型 (Abstract Data Type) 本小节介绍对关系数据类型的扩展, 后面章节介绍对面向对象的数据类型的扩展及其定义语言
1. 大对象 LOB(Large OBject ) 类型 LOB 可存储多达十亿字节的串 LOB 又分为二进制大对象 BLOB(Binary Large OBject) 和字符串大对象 CLOB(Character Large OBject) 两种 BLOB 用于存储音频 图像数据 CLOB 用于存储长字符串数据 LOB 类型数据是直接存储在数据库中, 由 DBMS 维护, 不是存在外部文件中 LOB 类型可以像其他类型的数据一样被查询 提取 插入和修改 但是使用时要注意, 必须为 LOB 提供足够大的缓冲区, 而且还有很多限制 应用程序在操作 LOB 类型数据时用 LOB 定位器 (LOB locator) 来提取 LOB 数据 应用程序通常并不传输整个 LOB 类型的值, 而是通过 LOB 定位器访问大对象值 2. BOOLEAN 类型 BOOLEAN 是布尔类型, 它支持 3 个真值 :true false 和 unknown 除了传统的 NOT AND 和 OR 布尔操作符外 SQL3 还增加了两个新的操作符 :EVERY( 而不是 ALL ) 和 ANY 这两种操作的参数都是 BOOLEAN 类型, 该 BOOLEAN 值通常是由一个表达式得到的 例如,WHERE EVERY(QTY>200) 或 WHERE ANY(QTY>200) 如果 QTY 列为空值, 两个操作符都返回 unknown; 如果 QTY 列为非空, 那么当该列的每一个值都使 (QTY>200) 为 true 时,EVERY 返回 true, 否则为 false; 当该列的每一个值都使 (QTY>200) 为 false 时,ANY 返回 false, 否则为 true ( 即只要该列中的某一个值使 (QTY>200) 为 true 时,ANY 就返回 true) 3. 集合类型 (Collection Type)ARRAY 相同类型元素的有序集合称为数组 ARRAY, 这是 SQL3 新增的集合类型, 它允许在数据库的一列中存储数组 [ 例 2] CREATE TABLE SALES ( ITEM_NO CHAR(20), /* 商品号 */ QTY INTEGER ARRAY[12], /* 整数数组, 存放 12 个月的销售额 */ PRIMARY KEY(ITEM_NO) ); SQL3 的数组只能是一维的, 而且数组中的元素不能再是数组
下面是向 SALES 表插入一个元组 : INSERT INTO SALES(ITEM_NO,QTY)VALUES ('T-shirt2000',ARRAY[200,150,200,100,50,70,80,200,10,20,100,200]); 下面是查询语句, 查找三月份销售额大于 100 的商品号 : SELECT ITEM_NO FROM SALES /* 从 SALES 表中选出满足下面条件的商品号 */ WHERE QTY[3]>100; /* QTY 数组第三个值大于 100*/ 4. DISTINCT 类型 SQL3 新加了一种 DISTINCT 类型 在应用中, 不同的字段经常定义成同一种数据类型 例如, 职工的智商字段 (IQ) 和鞋号字段 (SHOE_SIZE) 都定义成 INTEGER 类型 表达式 :WHERE SHOE_SIZE > IQ 语法是对的, 因为它们是同一种数据类型, 可以相互比较 但是, 这显然不符合实际应用的语义 这时可将 SHOE_SIZE 和 IQ 字段定义成 DISTINCT 类型 语法如下 : CREATE TYPE <type name> /* 用户定义数据类型的名称 */ AS <built in scalar type name> FINAL /* 只限于 SQL 内置的那些数据类型 */ [ <cast option>] /*cast 选项 */ [ <method specification commalist>]; /* 定义类型上的操作或方法 */ 本例中两字段类型可分别定义如下 : CREATE TYPE SHOE_SIZE_TYPE AS INTEGER FINAL; /* 用户定义 SHOE_SIZE_TYPE 数据类型, 它是整型的 */ CREATE TYPE IQ_TYPE AS INTEGER FINAL; /* 用户定义 IQ _TYPE 数据类型, 它是整型的 */ 这样就定义了 SHOE_SIZE_TYPE 和 IQ _TYPE 两种数据类型, 它们成为两种不同的数据类型 此时 SHOE_SIZE 只能与同类型数据值相比, 而不能与其他任何数据类型相比, 包括 INTEGER 类型 IQ 也一样 因此, 表达式 : WHERE SHOE_SIZE > IQ 就是非法的了 然而, 如果在定义类型时设置了选项 <cast option>, 下面用法也是合法的 : WHERE SHOE_SIZE > CAST (IQ AS SHOE_SIZE_TYPE) 15.2.2 对象关系数据库系统中扩展的对象类型及其定义为了支持 OO 数据模型,SQL3 扩展了面向对象的类型系统 在 ORDBMS 中, 类型 (TYPE) 具有类 (CLASS) 的特征, 可以看成类
1. 行对象与行类型一个行类型 (ROW TYPE) 可以使用如下语句定义 : CREATE ROW TYPE <row_type_name> (<component declarations>); 行类型中属性类型可以是基本类型 扩展的关系类型 行类型也称为元组类型, 因为它们的实例是表中的元组 [ 例 3] CREATE ROW TYPE Person_type /* 创建了一个行类型 Person_type*/ ( pno NUMBER, /* 以下是行类型属性说明 */ name VARCHAR2(100), address VARCHAR2(100) ); 然后, 可以创建基于行类型的表, 把类型实例化 定义语句如下 : CREATE TABLE <table_name> OF <row_type_name>; [ 例 4] CREATE TABLE person_extent OF Person_type (pno PRIMARY KEY ); /* 说明其中 pno 属性是主码 */ 创建了一个表 person_extent, 它由行类型 Person_type 来定义 表的属性定义直接对应行类型的属性定义 表中每行是一个对象, 有 OID 标识 2. 列对象与对象类型在实际 ORDBMS 中 ( 如 ORACLE) 提供了列对象的概念, 可以创建一个对象类型, 表的属性可以是该对象类型 语句如下 : CREATE TYPE <type_name> AS OBJECT (<component declarations>); [ 例 5] CREATE TYPE address_objtyp AS OBJECT (street VARCHAR2(50), city VARCHAR2(50) ); CREATE TYPE name_objtyp AS OBJECT (first_name VARCHAR2(30), last_name VARCHAR2(30) ) ;
然后创建一个表, 定义其中的属性是对象类型 例如 : [ 例 6] CREATE TABLE people_reltab ( /* 这是传统的建表语句 */ Id NUMBER(10), name_obj name_objtyp, /* 该列为对象类型 name_objtyp*/ address_obj address_objtyp); /* 该列为对象类型 address_objtyp*/ 语法上看这和传统的建表语句类似 SQL3 扩展的是 : 允许表中的属性列是对象类型 以上讨论的行类型和列对象提供了对象功能, 还可以通过他们的各种组合来实现复杂对象类型的构造, 但是它们并不提供 15.1.1 中所讨论的封装 而封装又是对象模型的一个本质特征, 它由 SQL3 中的抽象数据类型来提供 3. 抽象数据类型 (Abastract Data Type,ADT) SQL3 允许用户创建指定的带有自身行为说明和内部结构的用户定义类型称为抽象数据类型 定义 ADT 的一般形式为 CREATE TYPE <type_name> ( 所有属性名及其类型说明, [ 定义该类型的等于 = 和小于 < 函数,] 定义该类型其他函数 ( 方法 )); ADT 有许多重要特点 : (1) ADT 的属性定义和行类型的属性定义类同 (2) 在创建 ADT 的语句中, 通过用户定义的函数比较对象的值 如果不定义该类型的比较函数, 则采用默认的等于和小于函数来比较对象的大小 (3) ADT 的行为通过方法 (methods) 函数(functions) 实现 在 SQL3 中函数和方法有很多不同 方法是和某个用户定义的类型紧密联系在一起的, 而函数不是 函数和方法都可以用 SQL 语言或传统的程序设计语言 ( 包括 JAVA) 来书写 (4) SQL3 要求抽象数据类型是封装的, 而行类型则不要求封装 这是由数据库的特点决定的 数据库中数据是共享的, 对共享数据的操作主要是查询 增 删 改, 这是共同的隐含的操作 不需要为共享数据另外定义一组操作, 因此, 没有必要自定义函数和封装 对于大文本文档, 图像数据, 图形数据, 时间序列数据, 空间和地理数据等新的非结构化数据则需要定义各自特定的数据类型和操作, 抽象数据类型较好地满足了这些新应用的需求 由于特殊的数据类型一般和领域应用紧密相关, 其中的函数常常是原来应用程序的一部分, 因此一般由 ORDBMS 厂商和独立的软件开发商或有经验的用户部门合作, 为特定应用
开发类型库 ( 或简称类库 ) 对于这些类库,Informix 称为数据刀片 Datablades,Oracle 称为 Cartridge,IBM DB2 称为 Extender,Sybase 称为 Plug-in 等 这些类库必须经过产品质量确认后才能作为产品的一部分发行 (5) ADT 有 3 个通用的系统内置函数, 构造函数 (Constructor Function) 观察函数 (Observer Function) 和删改函数 (Mutation Function) 构造函数生成对象值, 格式为 <ADT 名 >() 例如, 一个名为 Image_type 的 ADT, 构造函数就是 Image_type(), 它返回该类型的一个新对象 ( 值 ) 观察函数用来读取属性值 这是个隐含的函数, 如果 park 是 Image_type 的一个对象, park(area) 就返回 park 的属性 area 的值 删改函数 Mutator, 用来修改和删除属性值 与 UPDATE DELETE 类似 (6) ADT 可以参与类型继承 在类型继承过程中, 子类型包括父类型的属性和方法, 并可以增加自己的新的属性和方法 在 SQL3 中由根类型开始, 与其相关的子类型 子类型的子类型构成一个类型层次 (Type Hierarchies) ADT 的其他特点限于篇幅就不详细说明了 15.2.3 参照类型 (Reference Type) SQL3 提供了一种特殊的类型 : 参照类型, 也称为引用类型, 简称 REF 类型 因为类型之间可能具有相互参照的联系, 因此引入了一个 REF 类型的概念 : REF < 类型名 > REF 类型总是和某个特定的类型相联系 它的值是 OID OID 是系统生成的, 不能修改 下面通过例子来说明 REF 类型的有关概念 [ 例 7] CREATE ROW TYPE employee_type( name VARCHAR(35), age INTEGER ); CREATE ROW TYPE Comp_ type( compname VARCHAR(20), location VARCHAR(20) ); 然后, 可以创建基于行类型的表, 如下所示 : CREATE TABLE Employee OF employee_type; CREATE TABLE Company OF Comp_ type; 实际应用中 Employee 的元组与 Company 中的元组存在相互参照关系 即某个职工在某个公司工作 可以使用 REF 类型描述这种参照关系
CREATE ROW TYPE Employment _type ( employee REF (employee_type), company REF (Comp_ type) ); CREATE TABLE Employment OF Employment _type; 这样, 表 Employment 中某一个元组的 employee 属性值是某个职工的 OID,company 属性值是该职工所在公司的 OID 从而描述了职工和公司相互的参照关系 OID 可以被显式声明和访问 例如,[ 例 7]employee_type 的定义可以改为 : [ 例 8] CREATE ROW TYPE employee_type( name VARCHAR(35), age INTEGER, emp_id REF(employee_type) ); /* 声明 emp_id 是 REF 类型 */ 然后可以使用 VALUES FOR <ref_attrribute> ARE SYSTEM GENERATED 由系统生成 OID 值, 如 [ 例 9] [ 例 9] CREATE TABLE Employee OF employee_type VALUES FOR emp_id ARE SYSTEM GENERATED; SQL3 提供了一种机制, 它可以建立一个参照属性, 指向基于该类型的一个指定的表, 语句如下 : < 参照属性名 > [REF(< 类型名 >)] SCOPE IS < 关系名 > 例如, 对于 [ 例 5] 中的地址对象可以先使用地址类型创建地址表, 如 [ 例 10] 然后修改 [ 例 6], 在表定义中使用 REF 类型 [ 例 11] [ 例 10] CREATE TABLE address_objtab OF address_objtyp ; [ 例 11] CREATE TABLE people_reltab2 ( id NUMBER(4) PRIMARY KEY, name_obj name_objtyp, addresss_ref REF(address_objtyp) SCOPE IS address_objtab ); people_reltab2 表中的参照列 address_ref 存储的是所参照对象 address_objtyp 的 OID,
SCOPE IS 用来限定所参照的对象在一个确定的表 address_objtab 的范围内 这样做的好处是, 可以在参照列上建立索引, 从而提高查询效率 [ 例 12] CREATE INDEX address_ref_idx ON people_reltab2(address_ref) ; [ 例 13] SELECT id FROM people_reltab2 p WHERE p.address_ref.city=' 北京 ' and p.address_ref.street=' 牛街 '; 15.2.4 继承性 ORDBMS 应该支持继承性, 一般是单继承性 例如定义行类型 Person_type 的子类 emp_type,emp_type 就继承了它父类的属性, 同时又可以定义 emp_type 子类自己的属性 这是人员类型没有而雇员才有的属性 雇员的 ID(EMP_ID) 和工资 (SALARY) [ 例 14] CREATE TYPE emp_type /* 用户定义了一个 emp_type 类型 */ UNDER person_type AS( /* emp_type 是人员类型 person_type 的子类 */ emp_id INTEGER, /* 定义 emp_type 类型的结构 */ salary REAL ) /* 定义 emp_type 类型的结构 */ NOT FINAL; [ 例 11] 还声明了该类型允许再有子类型,NOT FINAL 表示不是类层次结构中最后的 叶结点,FINAL 则表示该类型是类层次结构的叶结点 15.2.5 子表和超表 SQL3 支持子表和超表的概念 超表 子表 子表的子表也构成一个表层次结构 表层次和类型层次的概念十分相似 如果一个基表是用类型来定义的, 那么它可以有子表或 / 和超表 [ 例 15] 对于下面的类型层次 ( 图 15.4), 先定义这些类型 TYPE, 然后创建基于这些类型的表 CREATE TYPE person /* 创建 person 类型, 这是根类型 */ (id INTEGER,name VARCHAR(20),birthyear INTEGER,address VARCHAR(40))
NOT FINAL; /* 这是根类型,NOT FINAL 表示可以有子类型 */ CREATE TYPE employee /* 创建 person 的子类型 employee*/ UNDER person /* 类型 employee 继承 person 的属性 */ (salary INTEGER) /* employee 定义自己的属性 */ NOT FINAL; CREATE TYPE executive /* 创建 employee 的子类型 executive*/ UNDER employee /* employee 的子类型 */ (bonus INTEGER) FINAL; /* 类型 executive 下面没有子类型了 */ CREATE TYPE student /* 创建 person 的子类型 student */ UNDER person (major VARCHAR(10),wage DECIMAL) FINAL; /* 类型 student 下面没有子类型了 */ 图 15.4 类型层次示例 以上 4 个类型构成了一个类型层次 [ 例 16] Department 类型和 employee 具有相互参照的联系, 可以使用 REF 来表示这种联系 CREATE TYPE department /* 创建 department 类型 */ (ID INTEGER, manager REF(employee), /* 属性 manager 参照 employee 的 OID*/ Budget INTEGER); ALTER TYPE employee /* 修改类型 employee*/ ADD ATTRIBUTE dept REF(department); /* 属性 dept 参照 department 的 OID*/
基于这些类型可以定义以下的基本表和表层次 : CREATE TABLE person_table OF person /* 创建基于 person 类型的表 */ (name WITH OPTIONS NOT NULL); CREATE TABLE employee_table OF employee /* 创建基于 employee 的表 */ UNDER person_table; /* employee_table 表是 person_table 的子表 */ CREATE TABLE exec_table of executive UNDER employee_table /* exec_table 是 employee_table 的子表 */ CREATE TABLE student_table OF student UNDER person_table; /* student_table 是 person_table 的子表 */ CREATE TABLE dept_table OF department (manager SCOPE IS employee_table); ALTER TABLE employee_table ALTER COLUMN dept ADD SCOPE IS dept_table; 这些表就构成了一个表层次 子表可以继承父表的属性 约束条件 触发器等, 子表可以定义自己的新属性 可以使用 SQL 的 SELECT,INSERT,DELETE,UPDATE 语句对这些表进行操作 对某个表的查询其实是对该表和它所有子表中对象集合的查询 [ 例 17] SELECT name,address FROM person_table WHERE birthyear <=1970; 这个查询是要找出 person_table 表上 1970 年后出生的人 查询结果包括了 employee_table exec_table student_table 表上的所有人 可以使用 ONLY 关闭 对子表的检索 办法是在 FROM 子句中使用 ONLY 将检索的对象限制为指定表中的对象, 而不是该表和它的子表中的对象 [ 例 18] SELECT name,address FROM ONLY person_table WHERE birthyear <=1970; 这个查询是只找出了 person_table 表上 1970 年后出生的人 不包括 employee_table exec_table student_table 表上的人
对于 INSERT DELETE UPDATE 等其他操作, 也有同样的规则 INSERT: 向子表插入一行时一般情况下会在该子表的超表上也插入一行 例如正常的向 student_table 表中插入一个新学生, 则在 person_table 表上也插入一个新行 DELETE: 从表删除一行时一般情况下会在该表的超表和子表上也删除相应的一行 15.3 小结 本章首先介绍了 OO 模型的基本概念, 然后讲解了 ORDB 所扩展的 OO 特征和功能 ORDB 在关系模型的基础上扩充了数据类型, 支持对象概念和对象类型, 支持用户定义的抽象数据类型 ADT, 支持由基本数据类型 对象类型和用户自定义 ADT 类型构成的复杂对象, 支持继承的概念, 支持子表和超表的概念等 本章主要讲解 SQL3 所支持的对象特征和对象扩展 由于 ORDMS 的实现早于 SQL3 标准的制定, 使得各个 ORDBMS 在支持对象模型所扩展的功能都要超过 SQL3, 而且所采用的术语 语言语法又不尽相同 有关 ORDB 的数据操纵语句, 是对 SQL 语句的扩展, 容易掌握 因篇幅有限这里就不专门讲解了 读者使用时可以参考具体的 ORDBMS 的语法说明和有关手册 习 题 1. 定义并解释 OO 模型中以下核心概念 : 对象与对象标识 封装 类 类层次 2. OO 模型中对象标识与关系模型中的 码 有什么区别? 3. 什么是单继承? 什么是多重继承? 继承性有什么优点? 4. 课程大作业 : 对象- 关系数据库应用开发 (1) 实验目的 : 通过实践, 掌握 ORDB 的概念, 掌握一个实际的 ORDBMS 软件的对象类型及其定义, 掌握对象操作 (2) 基本要求 : 学习和熟悉某个 ORDBMS 软件, 在此系统平台上, 利用合适的开发工具开发一个 ORDB 销售订单系统 销售订单系统的数据描述 : 顾客 Customer 库存 Stock 订单 Purchase Order 产品项 Item 一个顾客可以发出多个订单, 一个订单包含多个产品项, 每项产品对应有库存记录 设计这些对象合理的属性 其中顾客的地址是 Address(Street,City,Zip) 顾客的电话是 PhoneList(Phone1,Phone2,Phone3) a) 用对象关系模型定义这些类型, 顾客的地址用列对象来定义, 顾客的电话用数组类型定义 b) 创建相应的对象表, 定义具有的参照联系 c) 用 PL/SQL 或 C++ 或 JAVA 编程实现若干应用, 可以包括以下几个方面
插入 : 对建立的 ORDB 中的各个表, 首先输入若干数据 设计与开发 : 为销售订单系统设计若干功能, 例如顾客定货, 顾客管理, 订单管理, 库存管理等 实现若干子系统的功能 查询 : 根据输入的订单号查出顾客和产品信息 ; 根据输入的产品项查询它的库存量 ; 查出北京的顾客信息 ; 等等 本章参考文献 1 Nelson M,Mattos.SQL3- 新的 SQL 标准, 新一代对象关系数据库.IBM 数据库通用技术,1999 2 Gulutzan P,Pelzer T. SQL-99 Complete. Really.Miller Freeman,Inc. USA,1999 ( 该书全面描述 SQL3 标准, 通过许多例子来说明 SQL3 的功能 对于 SQL3 来说, 内容比较完整 该书的翻译本为 : SQL-3 参考大全, 齐舒创作室翻译, 机械工业出版社,2000) 3 http://otn.oracle.com/products/oracle9i/content.html 4 Oracle9i Application Developer s Guide Object-Relational Features Release 2 (9.2) Part Number A96594-01 5 http://www-3.ibm.com/software/data/db2/udb/features.html 6 http://msdn.microsoft.com/library3 7 Kim W,Lochovsky F(Editors).Object-Oriented Concepts,Databases and Applications. Addison-Wesley, 1989 ( 本书讲解了面向对象数据库系统的基本概念 技术方法和应用 ) 8 Stonbraker M,Rowe L.The Design of POSTGERS.Proceedings of the ACM SIGMOD,1986 ( 本文介绍了 POSTGRES 系统, 是众多介绍 POSTGRES 系统的论文之一 ) 9 Kim W.Architectural Issues in Object-Oriented Databases.Journal of Object-Oriented Programming,March 1990 ( 本文介绍了 Orion 系统的各个方面, 是众多介绍 Orion 系统的论文之一 ) 10 Lecluse C,Richard P,Velez F.O2:An Object-Oriented Data Model.Proceedings of the ACM SIGMOD, 1988 ( 本文介绍了 O2 系统, 介绍 O2 系统的论文很多, 这只是其中之一 ) 11 Maier D,Stein J,et al.development of an Object-Oriented DBMS.Proceedings of the Inter. Conference on Object-Oriented Programming Systems,Languages and Applications,1986 ( 本文介绍了 Gemstone 系统, 介绍 Gemstone 系统的论文很多, 这只是其中之一 ) 12 Fishman D,Beech D et al.iris:an Object-Oriented Database Management System.in Readings in Oriented-Oriented Database Systems,1990 ( 本文介绍了 Iris 系统, 介绍 Iris 系统的论文很多, 这只是其中之一 )
13 Carey M L,DeWitt D et al.the EXODUS Extensible DBMS Project:An Overview,in Readings in Oriented-Oriented Database Systems.Morgan Kaufmann Publishers,1990 ( 本文介绍了 EXODUS 系统, 介绍 EXODUS 系统的论文很多, 这只是其中之一 ) 14 Hudson S E,King R.Cactis:A Self-Adaptive,Concurrent Implementation of an Object-Oriented Database Management System.ACM TODS,Volume 14,Number 3,1989 ( 本文介绍了 Cactis 系统 ) 15 王珊等.An Object-Oriented Model for GIS, 第三届泛太平洋计算机国际会议 PPCC-3 论文集,1989 16 王珊. 面向对象的数据库系统. 计算机世界专题综述,1990 17 王珊, 唐元昌, 任永杰等.OBMS/IDKE 的数据模型和无缝的编程语言. 计算机科学,No.2,1992 ( 本期的一组论文, 全面介绍了中国人民大学数据与知识工程研究所研制的对象管理系统 OBMS/IDKE 的对象数据模型 无缝的编程语言 对象存储管理和动态模式管理 ) 18 Stonbraker M M,Moore D.Object-Relational DBMSs:The Next Great Ware,Morgan Kaufmann Publisher, Inc. 1996 ( 本书作者是美国著名的数据库专家 本书已由杨冬青 唐世渭 裴芳等译校, 对象- 关系数据库管理系统 下一个浪潮, 北京大学出版社出版,1997) 19 Malcolm Atkinson et al.the Object-Oriented Database System Manifesto.Proc. First International Conference on Deductive and Object-Oriented Databases.New York,N.Y.:Elsevier Science,1990 ( 这篇文章试图为面向对象数据库系统 ( 以及面向对象数据模型 ) 作出定义 它描述了作为一个合格的面向对象数据库系统所应具备的主要特征和性质 ) 20 中国人民大学数据与知识工程研究所编译 :X3/SPARC/DBSSG/OODBTG 最终报告. 计算机工程与应用, No.6,1992 ( 本期是 OODBTG 最终报告 的专辑 1989 年 1 月, 在美国 ANSI 所属 ASC/X3/SPARC 的数据库系统研究组 (DBSSG) 下, 成立了面向对象数据库任务组 (OODBTG), 专门就对象数据管理 ( 简称 ODM) 为面向对象数据库管理系统 (OODBMS) 的标准化问题进行研究 该组织不是制定标准的技术委员会, 而是研究如何实现新标准的工作组 OODBTG 的目标是对下面的问题进行调查 研究和取得共识 : (1) 提出能被大家接受的对象数据库的可行定义 (2) 确定对象数据库技术与相关领域中面向对象技术之间的联系 这些相关领域包括程序设计语言 用户界面 方法学 信息建模方法等 (3) 为将来在对象信息管理领域内的标准化工作建立一个框架 该任务组于 1991 年 8 月发表了 OODBTG 最终报告 该报告在大量调查研究的基础上, 阐述了许多新的技术概念, 提出了对象数据管理 (ODM) 参考模型和实现对象信息管理标准化的建议 上述工作对以后面向对象数据库系统的研究和系统开发产生了深远影响 )