CN102368272B - 一种数据库系统实现栅格数据类型的方法及其系统 - Google Patents

Abstract

针对以GeoTiff等文件方式组织和存储的大规模栅格数据难以实现统一组织、高效一体化查询检索以及并发安全访问问题，提出了一种数据库系统实现栅格数据类型的方法及其系统，对栅格数据类型所采用的常规物理存储模式进行了扩展，能够同时支持基于数据库内部栅格格式的本地存储和基于外部栅格数据源格式的外部存储，并通过引入数据结构的统一映射机制并扩展常规数据库系统结构——包括扩展外部存储驱动器和栅格逻辑对象处理器，实现了数据库系统对内部存储和外部存储栅格数据的高效集成和基于SQL的统一操作。

Description

一种数据库系统实现栅格数据类型的方法及其系统

技术领域

本发明主要涉及信息处理技术，特别涉及一种在数据库管理系统内核中实现栅格数据类型的方法及其系统。

背景技术

近些年来，随着遥感与信息探测技术的飞速发展，地理空间数据正在呈几何级数增长，如何对多源、多尺度下的海量地理空间数据进行高效组织和访问已成为迫切需要解决的核心问题。

栅格数据是地理空间数据的重要组成部分，是以像元(或像素)矩阵结构保存的地理空间数据，它是一类数据的总称，涵盖遥感影像、数字高程模型、格网数据等多种具体形态，甚至普通照片也属于典型的栅格数据。由于遥感平台所采集的地理空间数据基本都属于栅格数据(即遥感数据产品)，因此栅格数据所占地理空间数据总量的比重最大且数据量与日俱增，对其如何进行高效组织和访问已构成挑战。

对地理空间数据的存储，总体上已从文件方式发展为数据库方式。文件方式存储栅格数据主要存在以下缺陷：

●文件的相对独立性导致数据的松散型组织；

●难以实现高效检索，尤其是多条件的联合检索；

●一体化查询与分析效率不高，包括跨文件一体化、矢栅一体化查询与分析等；

●并发更新与安全问题无法解决。

针对文件方式的不足，近年来空间数据库技术得到了快速发展。空间数据库系统对栅格数据的存储和操作主要借助扩展栅格数据类型实现。所谓栅格数据类型，是除Int、Varchar等常规字段类型之外，针对存储栅格数据而专门引入的一种新的字段类型。要实现该数据类型，需要对原有数据库系统内核进行扩展，设计针对该数据类型的数据存储和访问机制，并定义一系列针对该数据类型的SQL算子以实现对栅格数据(或称栅格对象)的操作，而用户层面，只要将表中的某个字段定义为栅格数据类型字段，就可以在该字段中存储栅格数据，并通过执行相应的SQL算子实现对栅格数据的增、删、改、查。例如，Oracle数据库发明了栅格数据类型SDO_GeoRaster，该类型底层采用基于数据库表的存储和访问机制，专利号为US 2005/0055376A1；国产空间数据库BeyonDB发明了栅格数据类型ST_Raster，该类型独创了基于数据库表(行内模式)和数据库内控文件系统(行外模式)两种并行结构的存储和访问机制，专利号为ZL 200910244117。

以上基于数据库的类型扩展机制来存储和操作栅格数据，可较好地解决所述文件方式所存在的缺陷(即在数据的统一组织、高效一体化查询与检索、以及并发安全访问方面存在的问题)，但前提是：需要将外部栅格数据物理导入到数据库，并以数据库内部栅格格式存储才能解决以上问题。需要指出的是，所述ZL200910244117所发明的行外模式虽然采用的是基于文件存储，但其属于数据库内部实现的一种栅格文件系统，其目的是提高数据库只读访问的效率，即外部栅格数据如要基于数据库行外模式存储则仍然需要执行导入过程。

那么，为何不放弃文件方式或将所有基于文件方式的栅格数据导入数据库来存储？实际上，栅格数据采用文件方式还是数据库方式存储一直存在争议，其原因在于，文件方式存储栅格数据仍有很强的现实意义：

●大量遥感数据产品主要是以GeoTiff等文件格式保存，数据量巨大(单卫星数据中心往往以百TB计)，如要全部导入数据库几乎不可能完成，且即使完全导入数据库存储，也致使同一份数据需要维护文件存储和数据库存储两个版本，数据一致性难以维护；

●文件格式的数据移动、拷贝灵活，不需要类似数据库的导入和导出操作；

●文件数据的独立访问和处理性能相对较高，较适合数据生产系统使用。

那么，能否设计一种内置于数据库的新型栅格数据类型及其系统，能够屏蔽后端的栅格数据物理存储格式，既能以数据库内部栅格格式存取栅格数据，又能直接存取外部栅格数据源格式(包括常用的如GeoTiff等文件格式或其他数据库格式)，从而保留外部栅格数据源相对独立性的同时，又能实现基于数据库系统的统一组织、高效一体化查询检索以及并发安全访问，是本发明的初衷。

发明内容

本发明要解决的技术问题是：针对以GeoTiff等文件方式组织和存储的大规模栅格数据难以实现统一组织、高效一体化查询检索以及并发安全访问问题，提出了一种同时支持本地数据库存储和外部数据源格式存储的数据库新型栅格数据类型，并通过在数据库底层引入数据结构的统一映射机制并扩展常规数据库系统结构--包括扩展外部存储驱动器和栅格逻辑对象处理器，实现了数据库系统对内部存储和外部存储的栅格数据的高效集成和基于SQL的统一操作。

本发明解决其技术问题所采用的技术方案：

根据本发明的第一方面，提供一种数据库系统实现栅格数据类型的方法，包含如下步骤：

(1)按照数据库的数据类型扩展定义规范，在数据库管理系统的数据类型体系中增加定义栅格数据类型；

(2)对栅格数据类型所采用的常规物理存储模式进行扩展，能够同时支持本地存储和外部存储，其中，本地存储即完全以数据库内部栅格格式来存储栅格数据，而外部存储则以非本地数据库定义的外部栅格数据源格式来存储栅格数据；

(3)在数据访问时，将本地存储和外部存储的不同格式的栅格数据动态映射为同构的栅格逻辑对象；

(4)以栅格逻辑对象为统一视图，实现针对栅格数据类型的各类SQL操作。

所述步骤(2)中的栅格数据类型包含有存储标志，该存储标志用于标识当前记录的当前栅格数据类型字段值所保存的栅格数据所采用的物理存储模式，即本地存储或外部存储。

所述步骤(2)中的外部栅格数据源格式包含文件型栅格数据源格式和数据库型栅格数据源格式。

所述步骤(2)中的外部存储包含两个部分，在栅格数据类型字段中保存的对外部栅格数据源的描述信息，以及基于所述描述信息关联的以外部栅格数据源格式保存的栅格数据。其中，所述的在栅格数据类型字段中保存的对外部栅格数据源的描述信息至少包含对外部栅格数据源的链接信息。

所述步骤(3)中实现不同格式栅格数据动态映射为同构的栅格逻辑对象的方法具体为：首先，数据库内部栅格格式均以栅格逻辑对象为中介实现序列化和解序列化；其次，针对每一种外部栅格数据源格式建立数据动态转换驱动，实现外部栅格数据源格式和栅格逻辑对象的实时转换。

所述的数据动态转换驱动具备数据延迟转换技术，即栅格逻辑对象实施分步构造过程，该过程针对不同SQL操作实时转换并填充栅格逻辑对象所需访问的局部属性项，以避免仅局部数据访问而一次性填充栅格逻辑对象的全部属性项。

根据本发明的第二方面，提供一种实现栅格数据类型的数据库系统，包含基础数据库系统，并具有支持栅格数据外部存储的扩展系统，该扩展系统保存有以外部栅格数据源格式存储但在所述基础数据库系统的栅格数据类型字段中保存有对该外部栅格数据源描述信息的所有栅格数据，并包括：

外部存储驱动器：用于底层存取不同格式的外部栅格数据源，并动态转换为同构的栅格逻辑对象；

栅格逻辑对象处理器：用于输入栅格逻辑对象，执行基于栅格逻辑对象的各类计算操作，并返回计算结果给基础数据库系统。

所述基础数据库系统包括：

访问接口：用于连接到数据库并发出各类SQL请求；

SQL解析/优化/执行器：用于解析SQL请求、生成查询计划并分解调用基于数据类型的各种操作；

数据类型管理器：用于维护数据库数据类型体系，并接收SQL解析/优化/执行器对数据类型操作的调用，执行包含栅格数据类型在内的面向数据类型的各种操作，并将操作结果返回给SQL解析/优化/执行器；

数据I/O管理器：用于缓存并底层存取包含栅格数据类型在内的所有数据类型字段值；

事务管理器：用于管理数据库锁和日志；

栅格数据库：逻辑上包含本地存储和外部存储的各类栅格数据。

以上所述的一种实现栅格数据类型的数据库系统，其各组件的具体交互职责为：

数据类型管理器接收SQL解析/优化/执行器对栅格数据类型字段的操作调用，首先在事务管理器控制并发的前提下，通过数据I/O管理器读取栅格数据库中对应栅格数据类型字段的值，然后根据该栅格数据类型字段中保存的存储标志执行相应的栅格数据访问和计算操作，最后将操作结果返回给SQL解析/优化/执行器。

所述的根据栅格数据类型字段中保存的存储标志执行的栅格数据访问操作具体为，根据存储标志判断如果是本地存储，则由数据类型管理器解序列化所述栅格数据类型字段中保存的数据库内部栅格格式为栅格逻辑对象；如果是外部存储，则由数据类型管理器根据栅格数据类型字段中保存的对外部栅格数据源的描述信息调用外部存储驱动器，由外部存储驱动器读取外部栅格数据源格式并动态转换为栅格逻辑对象。所述的外部存储驱动器可内置至少一种对不同外部栅格数据源格式的读驱动或写驱动，其中的读驱动负责将外部栅格数据源格式动态转换为栅格逻辑对象，而写驱动负责将栅格逻辑对象动态转换为外部栅格数据源格式。

所述的根据栅格数据类型字段中保存的存储标志执行的栅格数据计算操作具体由栅格逻辑对象处理器完成，即栅格逻辑对象处理器接受统一格式的栅格逻辑对象及计算所需参数，完成指定的栅格计算，并将计算结果返回给数据类型管理器。

本发明与现有技术相比所具有的优点是：首先，对栅格数据库的常规内模式进行了扩展，引入外部栅格数据源格式(如GeoTiff、GeoRaster等)作为栅格数据类型的底层物理存储结构，从而实现了数据库内部和外部栅格数据的统一组织。其次，在数据访问和操作过程中，通过在数据库底层引入栅格数据物理异构到逻辑同构的映射机制，使数据库系统能够对库内外不同格式栅格数据实现一体化的查询与分析操作，同时，借助数据库天然的索引环境并配合本发明所述的栅格逻辑对象的延迟转换技术，能够达到较高的检索效率。最后，由于用户统一通过数据库接口访问栅格数据类型中保存的栅格数据，因此数据库的并发访问控制和安全访问策略对于物理存储结构透明，也即对于外部存储的文件型栅格数据，数据访问时能够同样遵循数据库的并发访问控制和安全访问策略，从而解决了直接存取文件型栅格数据所存在的并发与安全隐患。

附图说明

图1为本发明中的数据库系统结构示意图；

图2为本发明中的数据存储模式示意图。

具体实施方式

下面结合附图和实施例进一步说明本发明的技术方案。

前已述及，所谓栅格数据类型，是除Int、Varchar等常规数据库所提供的字段类型之外，针对存储栅格数据(一种不同于简单数据的复杂数据)而专门引入的一种字段类型。数据库管理系统如要增加支持一种新的复杂数据类型，必须对数据库系统内核进行扩展，设计针对该数据类型的数据存储和访问机制，并定义一系列针对该数据类型的SQL算子以实现对栅格数据(或称栅格对象)的操作。参考图1，假设采用扩展数据库系统100底层内核的方式实现本发明所述的栅格数据类型及其系统，则具体的方案实施包含类型定义、存储模式扩展以及系统结构与处理逻辑扩展三个方面，以下拟结合具体实例进行说明。

1、定义栅格数据类型ST_Raster

定义栅格数据类型是在数据库管理系统的类型体系中增加对栅格数据类型及其操作函数接口的描述，不涉及类型的具体存储结构和操作函数的具体实现。不同的数据库管理系统给出的数据类型扩展定义规范不同，如Oracle数据库管理系统采用Create Type语句配合对象描述实现新数据类型的定义，但从数据库类型扩展原理上，均符合抽象数据类型(ADT)的定义方法，以下给出实施例：

ADT ST_Raster{

类型属性：

{TYPE_NAME＝st_raster；TYPE_ID＝1121；TYPE_ATTR＝OBJ|NOKEY|NOSORT...}

类型操作：

其中，①类型属性：描述数据类型的基本特性，如TYPE_NAME为数据类型的名称，TYPE_ID为数据类型的唯一标识，TYPE_ATTR为数据类型的特性标志位的组合，其中的OBJ表示该栅格数据类型为对象型数据类型，NOKEY说明栅格数据类型的字段不能作为数据表的主键，NOSORT说明栅格数据类型不支持排序等。②类型操作：定义与该栅格数据类型相关的所有操作函数的接口，包括操作函数的名称、参数类型以及返回值的类型等，如以操作函数Int＝ST_BandNum(ST_Raster r)为例，该操作函数用于获取栅格数据类型中存储的栅格数据的波段总数，其中，ST_BandNum为该操作函数的名称，ST_Raster r说明该操作函数需要传入ST_Raster类型字段值作为参数，而Int标识该操作函数返回的波段总数为整型。

2、扩展ST_Raster类型的物理存储模式

定义完ST_Raster数据类型后，第二步需要在数据库管理系统的内模式确定ST_Raster数据类型所对应的物理存储结构。物理存储结构涉及到存储模式和具体存储格式，其中本发明主要对常规的数据库存储模式进行扩展，但不对具体存储格式进行限定，例如，当采用外部存储模式时，至于采用GeoTiff格式还是其他格式保存栅格数据，非本发明重点。

以图2中的表rst_tab为例，该表中的字段rast采用上述ST_Raster数据类型。ST_Raster数据类型设计包含两种物理存储模式，即本发明所提出的本地存储和外部存储。其中，本地存储即完全以数据库内部栅格格式来存储栅格数据，而外部存储则以非本地数据库定义的外部栅格数据源格式来存储栅格数据。外部存储的栅格数据可以包含如GeoTiff、Erdas Imagine、JPEG等不同格式的文件型栅格数据，以及类似Oracle GeoRaster、ArcSDE Raster等数据库型栅格数据。以下举例说明实现两种物理存储模式的具体实施方式：

以rid＝1的记录为例：字段rast中的“StgMode＝IN”用于标识该记录中存储的栅格数据采用的是本地存储，也即该栅格数据以数据库内部栅格格式保存于DBMS data file中(数据库内部数据文件)中，至于具体存储格式可参考专利US 2005/0055376A1等，此处不作限定。

以rid＝2的记录为例：该字段rast中保存的栅格数据采用的是外部存储模式，且为文件型栅格数据，其具体包含两个部分，①在栅格数据类型字段中保存的对外部栅格数据源的描述信息：“StgMode＝OUT”用于标识该记录中存储的栅格数据采用的是外部存储，“Frmt＝TIF”标识外部栅格数据源格式为Tiff格式，“URL＝D：\Imgs\600_600_3.GIF”记录外部栅格数据源所在路径的链接信息。②基于所述描述信息关联的以外部栅格数据源格式保存的栅格数据，该具体实施例中即为：以Tiff格式保存的600_600_3.GIF文件。

rid＝3的记录与rid＝2的记录类似，采用的也是外部存储模式，且同样为文件型栅格数据，但链接的是Erdas Imagine格式的外部栅格文件。

rid＝4的记录采用的也是外部存储模式，但为数据库型栅格数据，其中的“Frmt＝ORA”标识外部栅格数据源为Oracle数据库提供的GeoRaster格式；“URLscott，tiger，db，table，column，rid＝21”记录外部栅格数据源所在数据库的链接信息，包括用户名、密码、数据库名、表名、栅格数据类型字段名以及行的定位条件。

综上，采用以上所述的ST_Raster数据类型存储栅格数据，单从存储角度具有以下特点：

(1)存储结构较为灵活，即使在同一张rst_tab表中，也可以混合基于本地存储和外部存储的不同的栅格数据，且外部存储既可以是文件型栅格数据，也可以是其它数据库系统中保存的数据库型栅格数据。

(2)当主要采用基于文件型的外部存储时，由于栅格数据主要占据本地数据库之外的存储空间，因此表结构本身数据量较小，但却可以实现对外部大规模栅格数据的统一组织。

(3)用户通过统一的访问接口存取栅格数据类型字段值，因此用户对于ST_Raster的存储结构可做到透明，这样充分体现了抽象数据类型的作用，并实现了数据库系统对不同格式栅格数据基于ST_Raster类型的统一组织。

3、扩展数据库系统结构和处理逻辑

以扩展后的ST_Raster物理存储模式为基础，进一步对常规数据库系统结构及处理逻辑进行扩展，目的是为了实现对内部存储和外部存储栅格数据的一体化操作。如图2所示，对包含访问接口、SQL解析/优化/执行器、数据类型管理器、事务管理器、数据I/O管理器和栅格数据库的基础数据库系统50进行扩展，加入了栅格逻辑对象处理器、外部存储驱动器并引入外部数据源，构成外部存储的扩展系统60。下面结合实施例说明各组件职责和处理逻辑。

假设要从上述rst_tab中搜索出所有未进行过地理空间参考(Georeferencing)的栅格数据，并返回这些记录的rid字段值。其中Georeferencing为遥感或地理信息系统领域的公知常识，用于描述栅格数据的象元坐标和实地坐标的换算关系，即如果包含Georeferencing信息，则可以由象元坐标(指图面上的坐标)计算实地坐标(比如现实世界的经纬度坐标)，或通过实地坐标计算象元坐标，从而使一幅遥感影像(一种最典型的栅格数据)具有了空间定位能力。要实现以上搜索，数据库只要执行以下SQL语句：

SELECT rid FROM rst_tab WHERE ST_Georeferenced(rast)＝FALSE

其中的WHERE语句对符合条件的记录进行筛选，即对rst_tab表中的每一行栅格数据执行ST_Georeferenced操作函数，如果返回值为FALSE即当前行符合搜索条件。ST_Georeferenced操作函数的完整接口为Bool＝ST_Georeferenced(ST_Raster r)，需传入栅格数据类型字段值，并判断该字段中存储的栅格数据是否包含了Georeferencing信息，如果不具备就返回FALSE，如果具备则返回TRUE。

以上SQL语句通过访问接口组件发送给SQL解析/编译/执行器，SQL解析/编译/执行器解析该SQL请求、生成对应的查询计划并分解执行其中的ST_Georeferenced操作，而该操作的具体执行由数据类型管理器负责，即数据类型管理器首先在事务管理器控制并发的前提下，通过数据I/O管理器读取rst_tab中的当前记录行，其中包含rast字段值，然后根据该rast字段值中保存的存储标志StgMode执行相应的栅格数据访问和计算操作。

假设当前操作的是rid＝1的记录行，通过判断rast字段值中的“StgMode＝IN”知道该栅格数据采用了本地存储，则数据类型管理器根据预知的数据库内部栅格格式对rast字段值进行解序列化，生成统一的栅格逻辑对象。其中，栅格逻辑对象为中间数据结构，与具体存储格式无关，可采用类或结构方式实现，此处以结构方式给出示例：

假设当前操作的是rid＝2的记录行，通过判断rast字段值中的“StgMode＝OUT”知道该栅格数据采用了外部存储，则由数据类型管理器进一步根据rast字段中保存的对外部栅格数据源的描述信息——对应到本实施例中即为“Frmt＝TIF”和“URL＝D：\Imgs\600_600_3.GIF”调用外部存储驱动器读取栅格数据。此处，假设外部存储驱动器内置了对以上Tiff和IMG两种文件型栅格数据源以及Oracle GeoRaster数据库型栅格数据源的读写驱动，其中的读驱动负责将Tiff、IMG和GeoRaster格式的栅格数据动态转换为栅格逻辑对象RastOBJ，而写驱动负责将栅格逻辑对象RastOBJ动态转换为Tiff、IMG和GeoRaster格式。由于当前的ST_Georeferenced操作是一种读取操作，且外部存储格式为Tiff格式，故外部存储驱动器将实例化Tiff格式的读驱动，通过间接调用Tiff格式的读写库(如公知的libtiff库等)，读取D：\Imgs\600_600_3.GIF文件的所需数据项，并填充到RastOBJ中(如果是数据库型栅格数据源，则连接到外部数据库，并通过数据库接口访问栅格对象的所需数据项)。此处，由于ST_Georeferenced操作只涉及对空间参考信息的读取，故可进一步使用延迟转换技术，即对RastOBJ实施分步构造过程，例如，在对象实例化时只填充以上RastHeight、RastWidth等基本属性项，对于空间参考、颜色表等非基本属性项在对象实例化时暂不进行填充，直到逻辑对象处理器执行空间参考计算操作时，再通过驱动按需实时读取外部栅格数据源的空间参考信息，从而实现较高的数据存取效率。

通过以上访问过程获得同构的栅格逻辑对象RastOBJ后，具体判断当前RastOBJ是否已被空间参考将由栅格逻辑对象处理器完成。栅格逻辑对象处理器以RastOBJ为操作对象，并实现了针对RastOBJ实例的各类计算操作。例如，对应上述的ST_Georeferenced操作函数，在逻辑对象处理器中需要实现对应的针对RastOBJ实例的空间参考计算操作，假设入口函数为Bool RastOBJ_ISGeoref(RastOBJ*rastobj)，该函数实现逻辑如下：

(1)判断所传入的栅格逻辑对象rastobj是否已经读取了空间参考信息(比如通过判断其georefs成员指针是否为空实现)，如果由于延迟转换机制尚未读取，则通过当前的栅格数据驱动实例实时读取外部栅格数据源的空间参考信息并填充到georefs成员；

(2)判断georefs成员是否已包含准确的空间参考信息，如果参数值已被准确填充，则说明已被空间参考，则返回TURE，如果未准确填充，则返回FALSE，从而实质上完成了ST_Georeferenced操作函数所需实现的功能。

以上，在执行带有ST_Georeferenced的SQL操作过程中，系统借助栅格数据物理存储格式异构到逻辑同构的映射机制，使数据库系统能够对rst_tab表中不同存储模式的栅格数据实现一体化访问和计算，其中，栅格逻辑对象的延迟转换技术，能够避免为访问局部数据(如本实施例中只需访问空间参考信息)而实例化整体对象，从而保证了较高的查询检索效率。同时，由于用户统一通过类似以上SQL操作访问栅格数据类型中保存的栅格数据，因此数据库的并发访问控制和安全访问策略对于物理存储结构透明。比如，当一个会话执行对rid＝2记录(对应外部存储的文件型栅格数据)中的rast字段进行Update更新时，另一个对该记录的Update更新会等待，一旦前一更新完成，后一更新立即执行，因此，对于并发更新外部存储的文件型栅格数据，不会存在并发冲突问题，从而解决了直接存取文件型栅格数据所存在的并发与安全隐患。

本发明未详细阐述部分属于本领域公知常识，且本技术领域中的普通技术人员应当认识到，以上的实施例仅是用来说明本发明，而并非用于对本发明的限定，只要在本发明的实质思想范围内，对以上实施例的变化、变型都将落在本发明的权利要求书范围内。

Claims (11)

1.一种数据库系统实现栅格数据类型的方法，其特征在于，包含如下步骤：

（1）按照数据库的数据类型扩展定义规范，在数据库管理系统的数据类型体系中增加定义栅格数据类型；

（2）对栅格数据类型所采用的常规物理存储模式进行扩展，能够同时支持本地存储和外部存储，其中，本地存储即完全以数据库内部栅格格式来存储栅格数据，并将栅格数据保存于数据库内部数据文件中，而外部存储则以非本地数据库定义的外部栅格数据源格式来存储栅格数据；

（3）在数据访问时，将本地存储和外部存储的不同格式的栅格数据动态映射为同构的栅格逻辑对象；

（4）以栅格逻辑对象为统一视图，实现针对栅格数据类型的各类SQL操作；

所述步骤（3）中实现不同格式栅格数据动态映射为同构的栅格逻辑对象的方法具体为：首先，数据库内部栅格格式均以栅格逻辑对象为中介实现序列化和解序列化；其次，针对每一种外部栅格数据源格式建立数据动态转换驱动，实现外部栅格数据源格式和栅格逻辑对象的实时转换；

所述的数据动态转换驱动具备数据延迟转换技术，即栅格逻辑对象实施分步构造过程，该过程针对不同SQL操作实时转换并填充栅格逻辑对象所需访问的局部属性项，以避免仅局部数据访问而一次性填充栅格逻辑对象的全部属性项。

2.如权利要求1所述的一种数据库系统实现栅格数据类型的方法，其特征在于，所述步骤（2）中的栅格数据类型包含有存储标志，该存储标志用于标识当前记录的当前栅格数据类型字段值所保存的栅格数据所采用的物理存储模式。

3.如权利要求1所述的一种数据库系统实现栅格数据类型的方法，其特征在于，所述步骤（2）中的外部栅格数据源格式包含文件型栅格数据源格式和数据库型栅格数据源格式。

4.如权利要求1所述的一种数据库系统实现栅格数据类型的方法，其特征在于，所述步骤（2）中的外部存储包含两个部分，在栅格数据类型字段中保存的对外部栅格数据源的描述信息，以及基于所述描述信息关联的以外部栅格数据源格式保存的栅格数据。

5.如权利要求4所述的一种数据库系统实现栅格数据类型的方法，其特征在于，所述的在栅格数据类型字段中保存的对外部栅格数据源的描述信息至少包含对外部栅格数据源的链接信息。

6.一种实现栅格数据类型的数据库系统，其特征在于，包含基础数据库系统，并具有支持栅格数据外部存储的扩展系统，该扩展系统保存有以外部栅格数据源格式存储但在所述基础数据库系统的栅格数据类型字段中保存有对该外部栅格数据源描述信息的所有栅格数据，并包括：

外部存储驱动器：用于底层存取不同格式的外部栅格数据源，并动态转换为同构的栅格逻辑对象，具体为：针对每一种外部栅格数据源格式建立数据动态转换驱动，实现外部栅格数据源格式和栅格逻辑对象的实时转换；

栅格逻辑对象处理器：用于输入栅格逻辑对象，执行基于栅格逻辑对象的各类计算操作，并返回计算结果给基础数据库系统；

所述基础数据库系统包括：

访问接口：用于连接到数据库并发出各类SQL请求；

SQL解析/优化/执行器：用于解析SQL请求、生成查询计划并分解调用基于数据类型的各种操作；

数据类型管理器：用于维护数据库数据类型体系，接收SQL解析/优化/执行器对数据类型操作的调用，执行包含栅格数据类型在内的面向数据类型的各种操作，并将操作结果返回给SQL解析/优化/执行器；

数据I/O管理器：用于缓存并底层存取包含栅格数据类型在内的所有数据类型字段值；

事务管理器：用于管理数据库锁和日志；

栅格数据库模块：逻辑上包含本地存储和外部存储的各类栅格数据，其中，本地存储即完全以数据库内部栅格格式来存储栅格数据，并将栅格数据保存于数据库内部数据文件中，而外部存储则以非本地数据库定义的外部栅格数据源格式来存储栅格数据。

7.如权利要求6所述的一种实现栅格数据类型的数据库系统，其特征在于，所述的对外部栅格数据源的描述信息至少包含对外部栅格数据源的链接信息。

8.如权利要求6所述的一种实现栅格数据类型的数据库系统，其特征在于，数据类型管理器接收SQL解析/优化/执行器对栅格数据类型字段的操作调用，首先在事务管理器控制并发的前提下，通过数据I/O管理器读取栅格数据库中对应栅格数据类型字段的值，然后根据该栅格数据类型字段中保存的存储标志执行相应的栅格数据访问和计算操作，最后将操作结果返回给SQL解析/优化/执行器。

9.如权利要求8所述的一种实现栅格数据类型的数据库系统，其特征在于，所述的根据栅格数据类型字段中保存的存储标志执行的栅格数据访问操作具体为，根据存储标志判断如果是本地存储，则由数据类型管理器解序列化所述栅格数据类型字段中保存的数据库内部栅格格式为栅格逻辑对象；如果是外部存储，则由数据类型管理器根据栅格数据类型字段中保存的对外部栅格数据源的描述信息调用外部存储驱动器，由外部存储驱动器读取外部栅格数据源格式并动态转换为栅格逻辑对象。

10.如权利要求9所述的一种实现栅格数据类型的数据库系统，其特征在于，所述的外部存储驱动器内置至少一种对不同外部栅格数据源格式的读驱动或写驱动，其中的读驱动负责将外部栅格数据源格式动态转换为栅格逻辑对象，而写驱动负责将栅格逻辑对象动态转换为外部栅格数据源格式。

11.如权利要求8所述的一种实现栅格数据类型的数据库系统，其特征在于，所述的根据栅格数据类型字段中保存的存储标志执行的栅格数据计算操作具体由栅格逻辑对象处理器完成，即栅格逻辑对象处理器接受统一格式的栅格逻辑对象及计算所需参数，完成指定的栅格计算，并将计算结果返回给数据类型管理器。

Images