1. 第六章 RDBMS 的扩展 关系模型中概括与聚合的扩展 支持共享与递归的分子对象概念 关系查询语言 QUEL 的扩展及其支持 关系模型中的抽象数据类型 XSQL 语言的扩展 嵌套的关系模型 NF2

2. ※ 6.1 关系模型中概括与聚集的扩展 例 1 ：关于人的特化模型示例 Persons sex maritalStatus nationality Females Austrians Canadians … Singles Males Married

3. 关系扩展模型 —— 一般化的 m 维特化示例 R S k1 S km …… R 11 R 1p 1 R m1 R mp m ……

4. 扩展的关系模型的一般语法 var R : generic s k1 =(R 11,…,R 1p 1 ); … s km =(R m1,…,R mp m ); of aggregate keylist s 1 : key R 1 ; … s n : key R n ; end

5. 对该语法的说明 对 generic 关系 R ，具有 n 个属性，其中： －若是一般的类型，仅用类型符标识它 －若是一个聚集引用，即若引用一个 generic 关 系类型，则需要加前缀 “key” 进行区分 对 R 可以特化，其 m 维的特化属性用 s k1 …s km 表 示 每一个特化属性 s ki 将 R 的实例化对象划分成 p i 个 不相交的集合，每一个集合为 R 的一个特化集

6. 因此，若 R 有 m 维特化属性，则将 R 的实例 集进行 m 种划分，每一种划分都可以获得 R 的 P i 个特化集（ R i1,…,R ip i ) M 个特化属性 s k1,…,s km 属于 R 的属性集 s 1,…,s n 的子集。

7. 正确定义一个 generic 的关系 R 需要如下规则： 1.R 的 n 个属性中，每个属性的类型定义 R i （ 1≤i≤n ）是以下两种类型： (1) 是一个类型标识符（前缀 key 必须不出现）， 它表示了 R i 是一个原子值。 (2) 是一个 generic 的标识符，则前缀 key 必须在 定义中出现, 它表示对其他对象的引用。 2.Keylist—— 主关键属性表是 {s 1,…,s n } 的子 集

8. 3. 每一个特化类型 R ij （ 1≤i≤m ， 1≤j≤P i ）都 是一个 generic 标识符，其关键字域与 R 的 相同，且其属性在定义时就要 copy 父类型 除特化属性外的所有属性。 4. 特化属性 S ki （ 1≤i≤m ）都与 R 的某个属性 S j （ 1≤j≤n ）相同。 5. 如果 S ki 与 S j 相同，则 S j 的类型 —R j 的值域 是（ R i1,…,R ip i ）。

9. 一个应用实例 — 基于扩展关系模型的 CSG 表示 参看 P 31 页 CSG 的形式化表示： ::= ::= | | ::= cube | cylinder | cone | … ::= rotate | scale | translate | … ::= union | intersection |difference |…

10. 由此看出，一个 object 有三种类型： 1. Prim_obj （原始对象） 2. Mot_obj （运动对象） 3. Comp_obj （组合对象） 如下图：

11. 扩展 CSG 实例化关系模型 Mech_obj ID MAN ARG_OBJ LEFT_ARG RIGHT_ARG TYPE Mot_obj Prim_obj Comp_obj T MAT PRICE OP_CODE PTYPE cylinder … cuboid LENGTH WIDTH HEIGHT

12. CSG 的关系模型表示 (1) var mech_obj: generic (2) TYPE = (prim_obj, mot_obj, comp_obj); (3) of (4) aggregate [ID] (5) ID : identifier; (6) MAN: manufacturer; (7) TYPE: structural_comp (8) end

13. Mech_obj 的三个特化子类型说明 var prim_obj ： generic prim_obj 是 mech_obj 的 PTYPE =(cylinder,…,cuboid); 特化，而本身通过特化控制 of 属性 PTYPE 进一步被特化 aggregate[ID] 为原始对象集合 ID:identifier; 这两个属性是父类属性， MAN:manufacturer; 除控制特化的 TYPE 属性 MAT:material; 外的全部属性的复制，以 PRICE:money; 此实现继承的概念 PTYPE:geom_form; end

14. var cuboid cuboid 不是 generic 类型 ， aggregate [ID] 它没有进一步特化（没有子类） ID:identifier; MAN:manufacturer; 这四个属性继承父类 MAT ： material; 而来 PRICE:money; LENGTH:real; 这三个属性是 cuboid WIDTH:real; 自身的进一步描述 HEIGHT:real; end

15. var mot_obj mot_obj 也不是 generic 类型 aggregate [ID] ID:identifier; MAN:manufacturer; ARG_OBJ: key mech_obj; 该属性表达了对一 个对象的引用 T : matrix; end

16. var comp_obj aggregate [ID] ID:identifier; MAN:manufacturer; LEFT_ARG_OBJ:key mech_obj; RIGHT_ARG_OBJ: key mech_obj; OP_CODE :( union,difference,intersection,…) end

17. 一个无孔支架 bracket 的 CSG 的关系实例 mech_obj ID MAN TYPE … “bracket #1” “plate #1” “plate #2” … “Steal,Inc.” … “comp_obj” “prim_obj” …

18. comp_obj ID MANLEFT_ARG_OBJRIGHT_ARG_OBJOP_CODE … “bracket #1” … “steal,Inc.” … “plate#1” … “plate #2” … “union” … prim_obj ID MAN MAT PRICE PTYPE … “plate #1” “plate #2” … “steal,Inc.” … “iron” … 20.00 10.00 … “cuboid” …

19. cuboid IDMANMATPRICELENGTHWIDTHHEIGHT … “plate #1” “plate #2” … “steal,Inc.” … “iron” … 20.00 10.00 … 10 … 5 2 … 0.5 …

20. 对该模型的总结与讨论 特点： 1. 扩展了对概括抽象和聚集抽象的支 持, 方法简单，易理解。 2. 通过复制方案实现继承。 问题： 1. 由于复制造成大量冗余，效率低下。 2. 没有面向对象行为，即不允许具体 的行为操作。 3. 基本对象的语义结构仍然不易表达。 4. 为保证一致性，在更新操作时需要进行持 续的信息复制，开销较大。

21. ※ 6.2 分子对象 — 对 generic 类型的进一步扩 展 分子对象 (Molecular Object ）的概念 — 分子对象由分子集合组成 — 分子集合将一系列实例 ( 可以是不同类型 ) 和它们的关系，聚集对象为较高层次的 实体

22. 分子对象的结构分类： — 不相交 / 非递归； — 相交 / 非递归； — 不相交 / 递归； — 相交 / 递归； 相交：指一个分子对象的组成部分 是否能被其他同类型分子对象共享。 递归 / 非递归：分子对象的结构是否 是递归定义的。

23. 四种类型分子的进一步说明 不相交 / 非递归 —— 是最简单的结构 — 分子集合内的所有分子之间均是两个不 相交的、结构不重叠的，因之也不是递 归定义的。 例如：原始对象集合。

24. 相交 / 非递归的分子对象 — 分子间存在共享对象成份，即两个分子 可能在一些抵赖的分子对象上重叠。 例如：具有同一平台的两个几何体

25. 不相交 / 递归 — 具有递归定义的不共享的分子结构， 例：几何对象的 CSG 表示是一个递归分子 对象的典型例子，它构成一颗二叉树。 参照图 3.2 （支架表示）

26. 递归 / 相交 — 如果允许 CSG 中的几何部件被共享，则 它是一个有向无环图 DAG

27. CSG 1 CSG 2

28. 6.3 将 QUEL 表达式作为类型的关系 模型的扩展 QUEL:— 由伯克利分校研制的 Ingres 查询语言 — 类似于元组关系演算 QUEL 的组成：由三个子句组合而成 —range of 子句：类似于 from 子句，作用为声 明元组变量的取值范围，书写格式为 range of t is r(t 为关系 r 的一个元组变量 ) —retrieve 子句：类似于 select 子句，作用为确 定查询目标，其变量必须已经在 range 子句中声明， retrive t.A 查询 t 的 A 属性值 —where P 子句：条件子句， P 为选择谓词 * 请参考 “ 数据库系统概念 ” 第五章

29. 一般化引用基制的模型构造 纯关系结构示例： E-R ： 关系表 boundary GEO_IDFACE_ID “cube#1” … “cube#1” … “cube#1” … “f1” … “f6” … “f1” … mech-part boundary faces N M IDSURFACE… “f1” “f2” … “f6” … ……………………………… ……………………………… mechanical_part IDNAME… “cube#1” … “cube#2” … “cube#3” … ……………………………… ………………………………

30. QUEL 查询语句序列 range of m is mechanical_part range of f is faces range of b is boundary retrive m.all,f.all where m.ID = “cube#1” and m.ID = b.GEO_ID and f.ID = b.FACE_ID range of m is mechanical_part retrive m.all, m.FACE_JOIN where m.ID = “cube#1” range of f is faces retrive f.GEO_JOIN where f.ID= “f1”

31. 关系模型的扩展 关系属性类型中扩展一个新类型 —QUEL 类 型 QUEL 类型为一个 QUEL 查询表达式，它可 以在被引用是触发执行 使用 QUEL 类型代替外键联接关系，例如上 图 boundary ，从而将原来显示的联接隐含 在父关系的某个属性中，只有在动态联接 时才被激活

32. 上述关系示例的扩展 mechanical_part IDNAMEFACE_JOIN “cube#1” … “cube#2” … …… … …… “range of f is faces retrive f.all where f.ID in {“f1”, …}” … “range of …” faces IDSURFACE…GEO_JOIN “f1” “f2” … “f6” 10.0 15.0 … …………………… “range of m is mechanical_part retrieve m.all where m.ID in {“cube#1”, “cube#2”}” …

33. 相应的 QUEL 查询语句 利用 mech-part 的 FACE-JOIN 和 faces 中的 GEO-JOIN 属性代码为： range of m is mech-part retrieve m.all,m.FACE-JOIN where m.ID = “cube#1” range of f is faces retrieve f.GEO-JOIN where f.ID=“f1”

34. 进一步的扩展 range of m is mech-part retrive m.FACE-JOIN.SURFACE where m.ID = “cube#1” 利用 QUEL 类型和操作符 ”.” 的重载，可以在 构造一个复杂的引用链时，通过简化显式 联接的方法简化查询和关系表的构建

35. 安全性的缺陷 由于采用隐式的联接方法 ( 通过 QUEL 函数 ) ，使得 查询结果只有在运行时进行动态联接时才能确定， 因而容易产生类型安全性错误 例如： mechanical_part IDNAMEFACE_JOIN “cube#3” … “cube#2” … …… … …… “range of f is other_faces retrive f.all where f.ID in {“f20”, …,”f25”}” “range of …” other_faces IDSURFACE…GEO_JOIN “f20” “f21” … “f25” “smooth” … “rough” …………………… “range of m is mechanical_part retrieve m.all where m.ID in {“cube#3”}” …

36. 安全性的缺陷 ( 续 ) 程序 range of m is mechanical_part retrive sum(m.FACE-JOIN.SURFACE) where m.ID = “cube#1” range of m is mechanical_part retrive sum(m.FACE_JOIN.SURFACE) where m.ID = “cube#3”

37. 6.4 关系模型中的抽象数据类型 概念：该模型发展得最好的是 INGRES ，他 们在开始研制时已留有与 C 的接口 —— ADT-INGRES ， 并进一步发展为 POSTGRES 。

38. 抽象数据类型的建模过程 在关系建模时，可以将某些属性显式地说明为一 个抽象数据类型 ADT 例： cuboids ( id: integer, material: char(10), description: char(20), V1: ADT: vertex_type, V2: ADT: vertex_type, … V8: ADT: vertex_type)

39. 抽象数据类型的建模过程 ( 续 ) 用户在系统提供的环境上，定义一个 ADT 的接口说明 例 ： define ADT (typename = “vertex_type”, bytesin = 9, bytesout = 9, inputfunc = “to_internal_vertex”, outputfunc = “to_external_vertex”, filename = “/usr/ingres/…/vertex”) XYZ “X%Y%Z” to_internal_vertex to_external_vertex

40. 抽象数据类型的建模过程 ( 续 ) 用户需要用 C(informix 也允许用 java) 语言实 现 ADT 的结构读写程序，并存放在按接口 说明的路径所示位置 在数据库运行时，需有用户需要检索 ADT 的值，则系统自动进行动态联接，激活并 运行相应的函数

41. 例：执行一个查询 range of c is cuboids retrieve (c.material, c.description,c.V1) where c.id = 5 结果为： materialdescritptionV1 XYZ coppermassive1.03.52.0

42. 用同样的方法，可以定义并实现在 ADT 域上的各 种用户自定义操作 informix 中使用 UDR 工具实现 例： define adtop (opname = “R y ”, funcname = “rotate_abount_y”, filename = “/usr/ingres/../rotate_y”, result = ADT: vertex_type, arg1 = ADT: vertex_type, arg2 = ADT: angle_type, prec like “+”)

43. 6.5 XSQL 支持的层次扩展模型 XSQL 是 Kifer 在 1992 中提出的一个 SQL 的面 向对象的扩展模型 SQL-3 标准已包括了 SQL 面向对象的扩展 XSQL 支持的层次扩展主要针对复合对象模 型，其扩展的主要是聚合抽象的实现方法

44. 基于纯关系模型的 XSQL 的基本构成 代用 Surrogates ：由系统产生并维护的关 系元组对象实例的逻辑标识符 特点 1. 唯一性 2. 系统内部产生，用户不能干涉 3. 不可修改，在一个对象的生命周期中保持不 变 4. 代用产生的标识符应当保证在 “ 世界范围 ” 内的 唯一性，以保证基于广域网的分布式 DB 中每 个元组的唯一性 生成方法： processor IDdate & time

45. component –of 属性 ——XSQL 利用该属性建立元 组间的引用关联。 关联的语义为 part-of 特点： component-of 属性支持元组间的 1:1 和 1:N 的 联接 E-R 表示： 关系表的定义 create table E1(E1-ID:identifier, E1_DATA:…) create table E2(E2-ID:identifier, E2_FATHER:component of (E1), E2_DATA:…) component of 的值是与 E2 的一个元组 e2 具有 R1 联系的 E1 的元组 e1 的 ID 值 N E1 R1 E2 componet of 1

46. 多层次的引用结构 E1 E2E3 E4 R1 R2 R3 (0,*) 1 (1,1) (0,*) (1,1) NN N 1 create table E1(E1-ID:identifier, E1_DATA:…) create table E2(E2-ID:identifier, E2_FATHER:component of (E1), E2_DATA:…)

47. E2 E2-IDE2-FATHERE2-DATA $589000101 $589000103 … $589000100 … ……………… E3 E3-IDE3-FATHERE3-DATA $589000102 $589000104 … $589000100 … ……………… E4 E4-IDE4-FATHERE4-DATA $589000105 … $589000101 … ……………… E1 E1-IDE1-DATA $589000100 $589000200 … ……………… 代用标识符的组成含有元组对象间的依赖关系，即对属于同一 个复合对象的元组，其 ID 值具有相同的前缀 系统对每一个复合对象建立一个 map 的映射，含有指向该元组 的存储位置指针 TIDs

48. 元组间 N:M 联系的扩展方法 原理：由于 XSQL 是在纯关系上进行的扩展， 因此，不可能表示集合属性，解决 N:M 关联 的方法只能采用第三方关系 —— 专门定义 一个引用关系表 R ，将两个有联系的元组对 应起来 reference 属性，它建立了一个引用关联

49. 一般的 N:M 联系的关系表定义 E-R 表示： 关系表定义： create table E1(E1-ID:identifier, E1_DATA:…) create table E1(E2-ID:identifier, E2_DATA:…) create table R(R-ID:identifier, RtoE1: reference(E1), RtoE2: reference(E2)) E1 R1 E2 N M

50. XSQL 模型的评价 创新点： 元组的逻辑标识符概念的引入 在关系模型的基础上建立了关系间的层次结构 解决了数据类型的 QUEL 的安全隐患 局限性： component-of 属性可以较好支持 1:N 联系，但是 在共享低层对象时，由于关系不能表示集合，会 造成大量的冗余，即一个引用就需产生一个对象 元组，由此造成查询的复杂低效，和一致性更新 维护困难

51. 局限性 ( 续 ) 对引用属性的支持力度很弱。由于 reference 属性相当于纯关系系统中的联接 关系，因此直接按照引用属性链完成检索 是不可能的，只能采用多个表的 JOIN 方法 进行显式地重构。 由于复合对象的管理由系统完成，即 map 对 用户不可见，因而进行复合对象物理存储 的集束 (clustering) 优化是困难的 ( 即在一个 页面上汇集不同元组组成的复合对象 ) 。