微型机与应用
MICROCOMPUTER & ITS APPLICATIONS
2000 Vol.19 No.2 P.45-47




地图应用中层次－关系型DBMS的实视图及其增量维护
王元珍　陈懿
摘 要： 讨论了基于层次－关系模型的视图机制，并以OEM模型为基础，提出了一个增量维护的算法。
关键词： GIS 实视图 对象交换模型 层次－关系模型 增量维护
　　地理信息系统（GIS）的核心是地理数据库，它要保存描述地图上实体的属性数据和描述地物空间特性的空间数据。空间数据量很大而且具有定位、定性的特性，选择适当的数据模型是提高系统性能的关键。我们采用层次－关系的混合模型（如图1所示），将地图的基本信息用上层关系来描述，对于地图中的各类地物，用下层关系来刻画，既结合了层次模型的空间描述能力，又能利用成熟的关系数据库技术提高地理信息系统的性能。
　　视图（view）是通过查询语句定义的从1个或多个数据源中导出的表，在分布式地图应用中，地图数据的数据量大，还要面向常规信息的查询，拓朴查询、空间分析以及屏幕显示，所以我们应用实视图机制，在客户端保留一部分原始数据的副本，以减少网络传输量，减轻服务器负荷，提高地图应用的整体性能。传统的关系模型数据库上的查询的返回值集本身实际上是结构完整的“小”数据库。而层次－关系模型是个混合模型，它同时包含描述层次的指针结构数据和描述传统关系的表结构数据。我们可以扩充定义实视图的SQL语句，保证实视图与原始数据的结构一致性。这种实视图定义语句局限于特定的数据模型。本文我们将采用对象交换模型（OEM）为中间模型，讨论层次－关系数据库上的实视图机制和它的增量维护算法。
1 DM2中的对象交换模型
　　对象交换模型OEM是面向对象的模型，已广泛用作异构数据库集成的中间模型。在DM2中我们用OEM作为定义来实现实体视图的概念模型，以简化混合模型上的复杂操作。每一个对象（object）由1个四元组＜OID，label，type，value＞表示。OID是全局唯一的标识，label是对对象的描述，type可以是诸如integer和string的原子类型，也可以是集合类型（set）。集合类型的值是一些其它对象的OID的集合。OEM模型可以用只有1个根节点的有向图表示。从根节点出发可以遍历到图中任一节点。
　　DM2中对于关系模型，我们可以用根root表示关系名，根的每个孩子就是关系中的每个元组，记为tuple．，层次关系则用图2中的父子关系描述，层次－关系模型就转换为OEM模型。
　　例1：用OEM模型描述图2中的层次－关系数据库（为了表示方便我们略去了四元组中的类型和值2个域）。

图1　层次-关系混合模型

图2　层次-关系数据库

图3　OEM模型描述的图2的层次一关系数据库
　　ROOT是1个集合类型的对象，它有2个儿子，分别代表地图的2个子图。N1，L1是原子类型。定义label（o）表示对象的标注，value（o）表示o的值，例如label（M11）＝tuple，value（M11）＝｛N1，L1｝。为方便视图机制的描述，作以下定义。
　　定义1：一条路径（path）是零个或多个标注（label）和点号交替排列的序列：p＝l1．l2…ln。例如river．R2就是一条路径。
　　定义2：N．p表示所有能从对象N经路径p达到的对象的集合。如果N2∈N1．p，则N1是N2的祖先（ancestor），N2是N1的1个后代（descendent），p中的第一个标注是N1的儿子，最后一个标注则与N2的标注相同。如果有N2∈N1．p1，N3∈N2．p2，则N3∈N1．p1．p2。在图3中，节点M12是节点ROOT的后代，可以从ROOT节点经路径river．tuple到达，即M12 ROOT．river．tuple。
　　定义3：集合类型的对象可进行集合操作，union（S1，S2）表示1个值为｛（valueS1）∪value（S2）｝的对象，其中S1，S2都是集合类型的对象。定义int（S1，S2）表示值为｛value（S1）∩value（S2）｝的对象。
2 视图与实视图
　　基于面向对象的方法，我们用以下形式的查询语句来定义视图：
　　SELECT OBJ．Sel＿path＿exp X
　　FROM DB
　　WHERE cond（X．cond＿path＿exp）
　　系统将查询所有由路径OBJ．Sel＿path＿exp能得到的对象，当它满足条件cond（X．cond＿path＿exp）时，将它存入结果对象＜ANS，answer，set，value（ANS）＞。这个结果对象就是视图的面向对象的描述。
　　在DM2中把结果对象与原来的层次OBJ．Sel＿path＿exp结合起来就能构造出1个层次－关系结构的结果数据库。该查询实现的视图定义为：
　　define view MapView as： 
　　　SELECT ROOT．river．* X 
　　　FROM MAP 
　　　WHERE X．length＞250 
　　这个视图用1个对象＜V，view，set，value（V）＞表示。
　　实体化的视图就是物理上实现的视图，它通过物理上存储视图固定定义的数据，减少查询时间。这对于数据仓库这样大型的数据基地的复杂查询，具有很大的性能优势。
　　我们重新定义视图中对象的OID，用类似路径的方式保持视图结构与原数据库结构的一致性，使得实体视图仍然是1个层次－关系数据库。当1个新对象X被创建并加入视图V时，把X的OID改为V．X。 
　　例2：定义实体视图如下。 
　　define mview MMAPVIEW as： 
　　　　SELECT ROOT．river．tuple X 
　　　　FROM MAP 
　　　　WHERE X．length＞250
　　得到的视图表示
如图4所示。

图4　实体视图

图5　实体视图
　　虽然视图对象只有1层叶节点，该叶节点对象的OID已充分表现了原数据库的层次结构。
3 实视图的增量维护
　　实体视图增加了系统的维护代价，系统必须在实体视图生成之后跟踪数据源的变化情况，通过刷新实现视图数据或增量维护的方法保持实体视图与数据源的一致性。一般情况下，增量维护的代价小于刷新实体视图的代价。
　　考虑3种基本更新：
　　1．insert（N1，N2）：将N2的OID加入到value（N1），N1必须是集合类型，更新完成后N2成为N1的儿子。
　　2．delete（N1，N1）：将N2的OID从value（N1）中删除。前提是N2是N1的儿子。
　　3．modify（N，oldv，newv）：把原子类型的对象从oldv更新为newv。
　　假设例1数据库中执行更新inser（M1，M13），这时M13只是个空对象，对实体视图没有影响。再执行更新insert（M13，L13），其中L13表示对象＜L13，length，interger，350＞，这时实体视图就受到影响，如图5所示。因此我们这里的基本更新不包括第一次执行的插入更新。同理，当删除1个地物的某个属性时，如果该属性满足condX．cond＿path＿exp，那么该属性的某个祖先对象就要被删除。下面的算法1就是根据OEM树的特性，检测被更新对象在实视图对象中对应的祖先，然后对这个祖先进行更新。
算法：视图MV的增量维护


　　注意到从1个节点到另1个节点最多只有1条路径，我们用path（N1，N2）来表示从N1到N2的路径，如果N1不是N2的祖先，则path（N1，N2）＝φ 。我们为算法1作以下定义：（1）ancestor（N，p）表示N的祖先X，它满足path（X，N）＝p。如果不存在这样的对象，ancestor（N，p）＝φ 。（2）eval（N，p，cond）返回N．p中满足cond（N．p）的所有对象的集合。当没有对象满足该条件时返回 。（3）Vinsert（VN1，VN2）表示创建对象VN2并把它加入到value（VN1）中。如果VN2已经在value（VN1）中，该操作忽略。（4）Vdelete（VN1，VN2）表示将对象VN2从value（VN1）中删除。如果value（VN1）中不存在VN2，该操作忽略。 
　　例2中数据库执行insertM1，M13更新时视图不用更新，执行insertM13，L13更新时，视图增量维护过程将根据算法1执行以下步骤：
第1步：检测到发生视图更新操作insert（M13，L13）；第2步：因为path（ROOT，M13）＝river．tuple，sel＿path＝river．tuple，cond＿path＝length，有sel＿path．cond＿path＝path（ROOT，M13）．label（L13）．p，此时p＝ φ；
第3步：令S＝eval（L13，φ，cond）＝（L13），L13存在于S中，因为value（L13）＝350＞250。因此对L13的插入将使得L13的某个祖先要被插入视图；第4步：令Y＝ancestor（L13，length）＝M13，执行Vinsert（MMAPVIEW，MMAPVIEW．M13）。此时MMAPVIEW．M13成为视图MMAPVIEW的儿子。 
　　本文讨论了地图应用中层次－关系混合模型上的实视图定义与实现，并给出了基于OEM的实视图增量维护算法。数据库实视图应该保留数据源的层次－关系结构。对象交换模型OEM普遍用于异构数据集成的中间模型，同时能够作为混合模型的数据库上的中间模型使视图定义与实现更统一自然。它使得同一视图定义语句能从不同结构的数据源导出实视图，提高了地图应用系统的适应性，缺点是需要额外的模型转换工作。
王元珍（武昌华中理工大学数据库与多媒体技术研究所430074）
陈懿（武昌华中理工大学数据库与多媒体技术研究所430074）
收稿日期：1999－08－21
