空间数据库的介绍（下）

最新推荐文章于 2023-03-31 22:08:02 发布

yangxuanlun

最新推荐文章于 2023-03-31 22:08:02 发布

阅读量1.6k

点赞数

文章标签：数据库扩展图形 integer 语言 string

2.3空间数据类型

空间数据类型系统或者空间代数可以描述成点线和面，包括他们之间的关系和行为组成(l例如形成区域交集)在第一部分，我们说对于一个空间数据库管理系统来说他们是数据模型中必须的一部分，因此对于模型和查询语言以及基本系统都需要提供他们。空间数据理性和操作已经够被描述。Scholl and Voisard (1989), Gargano et al. (1991) and Gfiting and Schneider之处已经对他们做了正式的定义。作为空间代数的例子，我们简单的考虑ROSE代数。

ROSE代数提供了点线和面三种数据类型，他们是基础。为了描述这些基础的东西，需要R-block和R-face这些中间体。为了给出一个R区域，R-block是一些R线段的连接。一个R-face实际上就是许多带洞的多边形，它可以被定义在细分区域中 Then, a value of

type points is a set of R-points, a value of type lines is a set of disjoint R-blocks,

and a value of type regions is a set of edge-disjoint R-faces (edge-disjoint means

that two faces may have a common vertex, but no common edge).

可扩展性有一个关于数据类型定义的总协定，在某些特定的领域，这些操作的定义是依赖于应用的。因此，在后期必须能够定义添加和修改数据类型，于是系统结构需要有的扩展性。

完整性这个问题主要是是否有一个正式的标准来说明哪些特定的操作集合在某些方面已经足够。在拓扑关系方面已经取得了一些成功。

一个或者更多的数据类型？是不是需要几种不同的数据类型（点线面）来区分？一些学者认为只需要他们中的一种或者他们的混合数据类型即可。这个问题类似于一个系统是否需要不同类型的整数和实数或者单一类型的数据。单一类型的优点是封闭下的操作很容易实现。另一方面，多种类型的话更容易描述和允许更多的操作应用。

设置操作一个空间代数不仅要支持在原SDT值上操作，还要支持对空间的对象集合进行操作，比如在一个分区上进行操作。例如对两个分区覆盖、融合或者寻找这个最接近查询对象的对象。这种操作要求有比原子操作更多的更复杂的接口。

2.4 空间关系

空间代数提供了这些操作，空间关系是他们中最重要的。例如，他们使得在已给的关系中访问所有对象成为可能。一个可以区分几个类

拓扑关系例如相邻内部不相交在缩放、旋转等变换下是不变的。

方向关系例如上下北边西南

制约关系例如距离小于一百

所有这些，拓扑关系是最重要的，而且已经有了一定的研究。有个基本问题是我们是不是能够列举出所有可能的关系。Egenhofer and Egenhofer and Herring提出了一个方法。他最初为基于他们的边界和内部设计了一个简单面，后来称作区域。两个对象有四个交集；每一个必须是空或者非空，可以得出24 = 16种组合。其中有八个是无效的，其中两个是对称的，于是得出六种不同的关系，分别是相离内部相接相等覆盖交叠

这种方法后来已经扩展成了各种方式。例如点和线的特征合在一起。考虑到外部（A-1），Egenhofer后来把原来的四交矩阵方式扩展成九交矩阵的方式。在二维空间，交集可以是空。零维（点），一维（线），二维（面）。这个结果，原则上有四的四次方256个组合。他们当中也有很多事无效的，所以最后在点、线、面中总共留下了52种关系。

这里有太多的名称使得用户无法记住，因此需要用什么东西来代替。我们已经介绍了五种基本的关系（相邻内部相交交叠相离），可以通过对扩展的方法对他们进行定义。例如：

相邻关系适用于面/面线/线线/面点/面和点/线但不适合于点/点。用A1 和 A2表示

定义为：

除了这五种关系以外，还有三种操作可以用来获取边界特征。Clementini等人已经证明这五种关系式互斥的，而且通过层面扩展方法描述的所有情况都可以使用这五种关系和三个边界操作来区分。

2.5 集成几何嵌入数据库系统数据模型

集合集合模型嵌入数据库系统数据模型实质上就是通过含有至少一种空间数据类型属性的对象来表示空间对象。因此，数据库系统数据模型必须在SDT系统的原数据类型的水平上（或者最好是一般对用户定义类型开放）进行扩展。目前，关系模型作为基础用的最多，而且这个方法也在其他任何一种模型中使用。在关系模型下，一个对象是通过元组来表示的，因此我们可以定义下面的关系：

relation states (sname: STRING; area: REGION; spop: INTEGER)

relation cities (cname: STRING; center: POINT; ext: REGION;

cpop : INTEGER)

relation rivers (rname: STRING; route: LINE)

Lipeck and Neumann把SDT系统融入到一个扩展的ER模型中。Scholl and Voisard把他们综合到了一个复杂的对象模型中。处理分区和网络更困难。分区可以被看成具有区域属性的对象集，但是那样会丢失一些信息,在这个里面面的分离和链接关系是是非常重要的。建模和分区也是非常重要的。已经指出，在一个空间区域数据类型中，建立一个区域属性的关系必须提供所有不相邻面的值。不过那还不完全正确，因为在关系上描述一个完整性约束并没有正确的使用数据类型这个概念

虽然对数据库中的图已经做了很多工作，但是在研究中并没有投入很多精力在嵌入网络的空间数据建模。一般假设图可以由已给的数据模型来表示。有个缺点是图结构对用户来书是不可见得，而且在系统执行过程总支持的不是很好。在Giiting，提出了GraphDB模型，它强调把一个图模型融入到一个标准的面向对象模型中。GraphDB提供了具有继承性质的对象类，像其他的OO模型一样，但是它和其他三种对象模型（简单类链接类路径类）又是有区别的，它的元素对应的是结点边缘和图的存储路径。例如我们对一个高速公路网建模，高速公路的入口和出口就是它的结点。具有线属性的高速公路部分就是它的边缘。而它的存储路径可以是下面这样的：

class vertex = pos: POINT;

vertex class junction = name: STRING;

vertex class exit = nr: INTEGER;

linkclass section = route: LINE, no_lanes: INTEGER, top_speed:

INTEGER from vertex to vertex;

path class highway = name: STRING as section+;

想进一步了解，请看G6ting。

3 查询

从一方面来看，查询就是把一个空间代数的操作链接到一个数据库系统的查询语言上。但是从其他方面来说，事实上空间数据需要一个图形显示结果，还图像输入查询或者至少在查询中使用SDTS值。在下面三部分我们讲一下数据库对象集上面的操作，图形输入输出，扩展查询语言的技术和要求。

3.1 基本操作

我们从一个角度来考虑对有空间属性的数据对象集的操作。这些操作包括空间选择空间链接空间函数应用和其他一些集操作

空间选择

严格的说没有一个像空间选择这样的东西。选择是一个能够返回含有谓词的对象集的操作。既然这样，谓词就被用来描述基于空间谓词的选择。例如：

寻找所有在Bavaria地方的城市

cities selectcenter inside Bavaria

寻找所有河流的交叉口

rivers selectroute intersects Window

空间链接它类似于空间选择，一个空间链接就是用空间谓词来比较两个对象的空间属性值的连接，；例如：找出所有河流长度不超过50千米的城市

cities rivers joindist(center, route) < 50

空间函数应用查询中的空间代数式如何算出SDT值的？在一个面向集合查询中，为每一个集合中的对象算出了一个新的SDT值。各种对象的代数操作都可以嵌入一个函数应用，例如，取代操作或者扩展操作等。扩展操作用一个表达式来评价每一个对象和其属性名；并把这个结果作为这个对象的新的属性，例如

查找出每一条通过Bavaria的河流的名字，以及这条河流在Bavaria的长度。

rivers selectroute intersects Bavaria

extend intersect ion (route, Bavaria) {part}

extendlength(part) {plength} projectrname, part, plength

其他的一些操作：

交叠融合 Voronoi.

3.2 图形输入和输出

传统的处理文字的数据库系统很容易从键盘输入数据并且获得查询结果。对于一个空间数据库系统来说，它的输入输出用图形来表示都是必不可少的。另外，在空间数据库系统中，查询的目标一般也是空间图像。这意味着检索信息一般不是一个单一的结果，而是几种查询的结合。例如一个GIS应用程序，用户一般想看到的是几个查询结果交叠在一起的一张地图。

一些学者（Frank (1982), Egenhofer and Frank (1988), and Egenhofer (1994).）认为空间查询有以下要求

1. 空间数据类型

2. 查询结果的图形显示

3. 几种查询结果的图形综合。

4. 内容的显示例如一个点可以描述一个城市的位置，也能够显示一些背景，例如，这个城市所在国家的边界线。

5. 一个检查显示内容的工具当一个图形是有几个查询结果组成的话，应该能够查询是那些查询获得的这个结果

6. 扩展对话框应该可以通过指针来选择图片里的一个对象，例如拖动图片里的一个矩形框

7. 用不同的图形来表示在一个图片里用不同的图像（颜色、强度、符号）来表示不同的对象。

8. 应该对所表示的图形有一定的解释

9. 标签位置用一个图形的标签来作为一个对象的属性，那是可能的。但是对于一个地图来说找出一个好的标签是很难的。

10 比例尺的选择比例尺的大小不仅决定于图形的大小，还决定于用哪种符号来表示，或者一个对象是不是完全显示。

11 亚查询（Subarea for queries）

这些要求，一般来说，能够通过在查询语言或者用户界面设计中的文本命令来实现。一个图形用户界面可能包含至少三种子窗口：（1）显示表示对象集的文本窗口，它还有每个对象的数字属性。（2）一个包含查询结果或者几个表示对象类的空间属性图形交叠的窗口（3）一个用来输入查询和显示系统结果的文本窗口。

Egenhofer建议把一个查询看成三部分：

1 像在传统的查询中一样，描述这个对象集

2 划分成子查询结果，通过显示的查询号码用不同的格式来显示

3 描述每个子集如何表现他的空间属性

3.3 整合几何到一个查询语言中

整合几何到一个查询语言中有三个方面：

一、在查询语言中明确的SDT值是一个常量，而且图形输入这种常量

二、这四种基本操作表达空间代数

三、描述当前结果

，

5 系统结构

5.1 要求

在系统构架方面的问题是，整合第四部分所描述的支持空间数据类型的工具的整合。原则上来说，对一个标准类型需要做以下扩展

1 描述空间代数数据类型

2 基本操作程序

3 空间索引结构

4 空间索引的访问操作

5 过滤和精华技术？？？？？？

6 空间链接算法

7 所有操作的成本函数

8 空间选择和空间链接的统计估计

9 地图查询中的专业查询处理方法的优化扩展

10 包括数据定义和查询语言在内的操作和空间数据类型

11 用户几面扩展（图形处理和SDT(空间数据类型)值的输入）

以我们看来，能够容纳这些扩展的唯一简单的方法就是基于使用一个可扩展数据库管理系统的综合构架。然而，在可用扩展数据库技术之前GIS系统已经形成，我们首先应该复习一下GIS构架的方法。

5.2 GIS构架—使用一个封闭的数据库管理系统

第一代GIS是直接创建在文件系统上的，而且不支持数据库管理系统的功能，比如高水平的数据定义，灵活的查询和事物管理。这里不在进一步讨论他们。

当数据库管理系统技术特别是关系系统出现了以后，开始尝试着把他们作为一个基础来使用。这两种主要方法是分层结构和二元结构。

分层结构。在已有的数据库关系系统上实施空间功能，形成一个商业上可用的关系系统，像图13那样。

有两种方法可以表示SDT值。第一种在早期已经使用，它是用一个元组来表示一个点或者线段的坐标，然后把SDT值分成几份。这样做的缺点是，SDT操作时在顶层，SDT值首先要被重置，这需要很大的代价。第二种是用数据库管理系统中的长字段来表示SDT值。这比把SDT值分成小片要好一些，但是那样还是有问题，因为数据库管理系统只能处理uninterpreted byte strings这种形式的几何构型。只有在顶层才能评价精确几何上的谓词和操作。在特殊关系中可以通过维持一些Z元素（4.2.1部分）来提供有限的空间索引形式。那个可以通过一个B-tree轮流索引。

二元结构在一个顶层上集成两个独立系统

6结束语

这篇论文中我们尽可能的把当前空间数据库系统的主要技术联系在一起。为了容易管理，我们仅仅处理的是狭义上的空间数据库管理系统。不涉及图像数据库系统。Joseph and Cardenas (1988), Changet al. (1991), and Gupta et al. (1991)等人是致力于图像数据库系统上的。幸运的是在这个特定领域上的一些论文是有关图像数据库的，这样就缩小了他们之间的差距。Baumann认为基本的数据库支持光栅数据的管理。Chu et al.说明了图像数据在医学应用上的模型和查询要求以及技术等。Papadias and Sellis的重点是在图像中空间关系抽象的管理。