在知识传播途中,向涉及到的相关著作权人谨致谢意!
文章目录
【空间数据组织与管理】空间数据获取、空间数据处理、空间数据应用三大技术的基础和核心
1 空间数据管理
【空间数据管理定义(狭义)】基于传统的数据库技术、面向空间数据的特点,研究数据的存储方法、索引技术和查询手段
1.1 空间数据为什么要管理
【为什么空间数据需要管理?】空间数据有以下特征,这些特征需要统筹解决=>所以需要科学进行管理
【空间数据的特征】
- 【空间特征】空间对象的空间坐标隐含了空间分布特征,因而我们除了通用性数据库管理系统或者文件系统关键字的索引和辅助关键字索引外,一般都需要建立空间索引
- 【空间关系特征】拓扑关系、度量关系、方位关系。拓扑关系方便了空间数据查询和空间分析,但另一个方面也给空间数据的一致性和完整性维护增加了复杂度
- 【非结构化特征】
- 在当前关系数据库管理系统中,数据中每条记录都是结构化的(定长的),数据项不能再分,不允许嵌套记录。而空间数据不能满足这种定长的要求。空间数据的数据项是变长的,非结构化的
- 比如一条弧段的坐标,其长度是不可限定的,可能是两对坐标,也可能是成百上前对坐标;另一方面,它不满足关系数据模型的结构化要求,从而使得空间图形难以直接采用关系数据管理系统
- 【多尺度多态特征】不同观察比例尺具有不同的尺度和精度,同一地物在不同情况下也会有形态差异
- 【海量数据特征】GIS数据量庞大,远大于一般通用数据库,可称为海量数据。由此,需要在二维空间上划分块或图幅,在垂直方向上划分层来进行组织
- 【分类编码特征】一般情况下,每个空间对象都有一个分类编码,这类分类编码往往是按照国家标准、行业标准、区域标准应用的
- 每一种地物类型在某个GIS中的属性项个数是相同的,因而在许多情况下,一种地物类型对应一个属性数据表文件
- 如果几种地物类型的属性项相同,也可以多种地物类型共用一个属性数据表文件
- 【多源特征】空间数据的来源多种多样
【结构化】相对来讲,更加稳固的,更清楚,更具体的一种形式
结构化的数据库管理技术面临的挑战:内模型、外模型、不适应非结构化特征,并与之对应
【GML】XML可扩展标记语言,在GIS方面的应用即是GML,特点是:有语义信息,可以把数据的关联性表达出来
【为什么GIS没有用这种方式表达?GIS数据模型为什么不是这种形态?】
传统GIS手段局限了我们的认知,局限了我们的视野
1.2 数据管理的发展历程
可以从数据库发展这个线索上看
【发展背景】
- 早期的系统图像属性和属性数据是完全独立的,这通常需要同时启动图形文件系统和关系数据库系统,甚至两个系统来回切换,使用起来很不方便
- 后来,随着技术的发展,GIS可以在图形环境下直接操纵属性数据,图形与属性完全在一个界面下进行咨询和维护,而不需要启动一个完整的数据库管理系统
- 并随着ODBC(open data base consortium,开放数据库连接协议)推出,GIS软件开发商只要开发GIS与ODBC的接口,就可以将属性数据与任何一个支持ODBC协议的关系型数据库系统连接,并且GIS用户都是在同一个界面下处理图形和属性数据,这种方式成为混合方式
1.3 矢量数据管理
- 文件-关系型
- 全关系型
- 对象-关系型
- 纯对象型
1.3.1 文件-关系型
【代表】ESRI:coverage(一种数据库、优秀的一种数据结构)、shapefile
【工作方式】图像数据和属性数据独立组织和管理
- 索引、图像存在文件中:用文件系统管理几何图形数据
- 属性存在数据库中:用商用关系型数据库管理属性数据
- 两者通过ID传递:两者通过目标标识或内部连接码进行连接
【优点】比单单的文件型,更灵活了
【缺点】
- 数据的安全性、一致性、完整性、并发控制以及数据损坏后的恢复方面缺少基本的功能
通过ID关联,有一个中间人,消息传递很困难保持一致,理论上能够做到,但实际上要花费很大的代价,需要用两套标准。文件无法让更多人使用,并发性差 - 查询运算、模型操作运算速度慢
属性数据和图形数据通过ID联系起来 - 计算机系统中单个文件的最大数据量有限制(有不超过4G、十几G),超过便无法打开
- 数据发布和共享困难
- 缺乏表示空间对象及其关系的能力
1.3.2 全关系型
【二维表】符合范式的结构,特点:结构精良、有类型长度的限制、大小非常统一,是一种结构化数据管理
【国产数据库】人大:金仓数据库;华中科大:达蒙数据库
【原理】图形数据、属性数据都采用现有的关系型数据库存储,使用关系数据库标准连接机制来进行空间数据与属性数据的连接
-
基于关系模型的方式(用表来存):正常的几何方式(几何表中单独表示)
【例子】存线:两个表,线:点=1:N的关系
【缺点】简单普遍的空间查询与操作,需要遍历、连接表来运算,费力耗时 -
变长字段存(BLOB二进制块中存)
【优点】省去了大量关系连接的操作
【缺点】二进制块的读写效率比定长属性字段更慢=>需要通过索引来解决
【优点】
- 用二维关系表表达,存储和标准化提取数据
- 成熟的商业化的关系数据库软件进行支撑
- 能存海量数据,单个字段存储量高达2GB
- 具有较高的安全性,能提供分布式共享的能力
【缺点】不能直接存储和管理非结构化的空间数据
1.3.2.1 空间数据引擎SDE
【概念】空间数据引擎(Spatial database engine)
- 是一种GIS产品或模块
- 主要是指通过解决存储在关系数据库中的空间数据与应用程序之间的数据结构,从而将空间图形数据存放到大型关系数据库进行管理
【两种方式】
- 一种是ESRI与数据库开发商联合开发的空间引擎SDE,称为中间件方式的SDE
- 另一种是开发商自己对数据库本身做出的扩展,使其支持空间数据管理,如Oracle的Spatial模块
【特点】
- 存储量大:支持超大数据集
- 通过标准API提供查询检索数据
- 高性能高并发:提供灵活且高性能的空间数据提取与搜索,拥有多用户并发查询的快速响应
- 分布式:专门为多用户,分布式环境设计
- 开发方面:开放的体系结构,真正的CS架构,具有有利而灵活的应用开发环境、完整灵活的安全控制机构
- 跨平台跨网络:通过TCP/IP横跨任何同构或异构的网络,支持多种硬件平台
- 数模模型:逻辑上的无缝、连续的非瓦片式的空间目标数据模型
- 升维:提供从基于文件的系统到DBMS管理数据库系统的平滑的升迁
1.3.2.2 ArcSDE
【介绍】
- 浮着在关系型数据库之上的,没有对数据库进行改变
- 在外围的 做了一个翻译工作 中间件
- 一边存,一边建立空间索引
【注意】ArcSDE不是一种数据库,是一种模型,一种中间件,一种软件
【工作原理】
【优势】
- 为任何客户提供空间数据的服务(多并发操作)
- 通过TCP/IP横跨任何同构或异构的网络
- 提供从基于文件的系统到DBMS管理数据库系统的平滑的升迁
- 以一种连续的、无缝的数据管理大型地理要素
- 通过标准API提供查询检索数据
- 真正的CS架构(客户端/服务器的架构)
- 跨越Internet提供公开的空间数据访问
- 通过前期建立的空间索引可以快速的把数据从中提取和定位出来
【类似的软件】
- 超图的SDX软件:全关系型的空间数据库软件
- MapInfo公司:SpatialWare
1.3.3 对象关系型模式
【背景】
- 商业数据库厂商发现ArcSDE占据市场份额后。
- 直接采用通用的关系数据库管理系统的效率不高,而非结构化的空间数据又十分重要
【对象关系型模式】在标准的支撑下,在数据库底层修改数据库结构,使数据库支持点、线、面的存储
【代表】
- SQL Server2008全面支撑空间数据
软件帮助:详细介绍了支持的空间数据库、空间索引方法,CSDN可以拿到这方面的资料 - Oracle
Oracle白皮书(技术资料)
【优势】
- 产生了新的对几何的支持
【注意】空间几何绝不意味着只有点、线、面。点、线、面只是代表着几何中的一种特例。还有几何单型(国家标准里定义了48种:样条曲线、弧串弧段等)、几何复型、几何组合型、几何聚集性 - 提供了简单的空间操作
对各种几何操作进行了定义,提供了各种空间操作算子,这些算子都是嵌入到SQL语句中的 - 效率高很多
在全关系型数据库中坐标串存在BLOB字段类型中,而数据库厂商对此提出了一个解决方案:线串
【缺点】
- 几何类型太少。空间数据结构不能由用户任意定义,使用上受限制
- 函数相对来说比较简单,一般不带拓扑关系
- 依然没有解决对象的嵌套问题(冗余的问题、关系的问题)
- 利用关系数据库管理系统中的大对象字段可以分块存储影像和DEM数据,但是对于多尺度的DEM数据,影像数据的空间索引、无缝拼接与漫游、多数据源集成等技术漫游一个完整的解决方案
1.3.4 面向对象的数据库
【优势】
- 具有嵌套性
- 具有高度的封装性
- 等等
【缺点】商业数据库产商不愿意做出改变
他们知道关系型数据库存在着一些局限,但市场已经高度发达了,基本能够承载他的基本发展了,他不想去做这种风险性的改变–>产业绑架了技术的发展
【思考】新技术的产生,旧技术还有什么存在的价值
【参考文章 | 搜索关键词】
- 蔡晓兵 Esri中国(北京)有限公司副总裁:ArcSDE鸡肋说
- ArcSDE产品介绍
- The Gateway for GIS data in a DBMS-SDE
- ArcSDE中间件技术的生命力
- Understanding ArcSDE
1.4 栅格数据管理
【栅格数据管理】基于文件的影像数据库管理、文件结合数据库影像管理、基于关系数据库管理
1.4.1 文件管理方式
目前大部分GIS软件和遥感图像处理软件都是采用文件方式来管理遥感影像数据
【缺点】
- 遥感影像数据库并不是仅仅包含图像数据本身,而且还包含大量的图像元数据信息(如图像类型、摄影日期、摄影比例尺等)
- 本身还具有多数据源、多时相等特点
- 数据的安全性、并发操作和数据共享等都将使文件管理无法应付
1.4.2 文件数据库管理方式
【工作原理】
- 影像数据仍按照文件方式组织管理
- 在关系数据库中,每个文件都有唯一的标识号(ID)对应影像信息(如文件名称、存储路径、元数据等)
【优点】影像数据索引的存在,使影像数据的检索效率得到提高
【缺点】不是真正的数据库管理方式,影像数据并没有放入数据库中,数据库管理的只是其索引
1.5 关系数据库管理
【工作原理】
- 基于扩展关系数据库的影像数据库管理是将影像数据存储在二进制变长字段中
- 然后应用程序通过数据访问接口来一访问数据库中的影像数据
- 同时影像数据的元数据信息存放在关系数据库的表中,二者可以进行无缝管理
【特点】
- 集中安全共享:所有数据集中存储,数据安全,易于共享
- 管理多源、时态:较方便管理多数据源和多时态数据
- 共享互操作:支持事物处理和并发控制,有利于多用户的访问与共享
- 交互式查询:影像数据和元数据集成到一起,能方便进行交互式查询
- 对Caientl Server的分布式应用支持较好,网络性能和数据传输速度都有很大提高
- 影响数据访问只能通过数据驱动接口访问,有利于数据的一致性和完整性控制,数据不会被随意移动、修改和删除
- 支持异构的网络模式,即应用程序和后台数据库服务器可以在不同操作系统平台下运行
现有商业数据库都有良好的网络通信机制,本身能够实现异构网络的分布式计算,使应用程序的开发相对简单化
2 总结
2.1 矢量数据的管理方式
方式 | 介绍 | 优点 | 缺点 |
---|---|---|---|
文件/关系数据库混合管理模式 | 图形数据和属性数据通过ODBC协议联系 | 比传统的OID方式方便 | 但运行速度慢,自修复性差、缺乏处理空间对象及其关系的能力 |
全关系数据库管理模式 | 关系数据库采用标准连接机制来进行管理 | 其标准统计,便于数据互操作 | 这种存储方式采用二进制块存储、处理效率较低 |
对象-关系数据库管理模式 | 采用了管理空间数据库的专用管理模块 | 解决了空间数据变长的问题,比二进制快存储机制处理效率高得多 | 但是空间数据结构不能由用户自行定义,API预先设置,不利于用于依据自身需求的二次开发 |
2.2 栅格数据管理方式
方式 | 介绍 | 优点 | 缺点 |
---|---|---|---|
简单文件管理 | 文件管理方式采用简单文件管理 | 数据结构相对简单,适用于小型数据 | 但由于遥感影像数据通常不仅仅包含图像本身,还包含一系列的元数据,因此这种管理方式的数据安全性较低、并发控制处理能力较弱,数据共享能力较差 |
文件-数据库管理方式 | 影像数据依旧使用文件方式管理,在数据库中每个文件对应唯一标识码 | 这种管理方式使数据检索效率得到显著的提高 | 但并没有真正数据入库,数据库管理的只是索引 |
关系数据库管理方式 | 将影像数据存储于二进制变长字段中,将元数据存放在关系数据库表中,实现了无缝管理 | 数据集中存储,数据安全、易于共享,支持并发操作,交互式查询,支持异构网络模式,使数据管理方便 | 但建库较为复杂 |
暂无评论内容