地理数据库存储基于关系原则

数据库管理系统 (DBMS) 可以被看作是开放的系统,因为通用关系数据模型的简单性和灵活性使数据库管理系统支持的应用程序范围非常广泛。

地理数据库存储模型以 DBMS 原则为基础并采用了一系列简单而必要的关系数据库概念。DBMS(以及文件地理数据库的文件系统)为使用表存储信息和使用表中的信息提供了一种简单而正式的数据模型。

以下是几个重要的概念:

对于存储在关系数据库中的 ArcSDE 地理数据库,还具有许多其他 DBMS 功能:

例如,要素类以 DBMS 表的形式存储。每一行表示一个要素。每一行中的各列分别表示要素的各种特征或属性,并且其中一列用于存储要素几何(例如,点、线或面坐标)。在以下示例中,Shape 字段用于存储要素类表中每个宗地行的面形状。

表中的要素和属性存储

DBMS 中的各种列类型用于在表中存储 Shape 字段。这些类型通常是某些 DBMS 所支持的二进制大对象 (BLOB) 类型或扩展的空间类型。例如,用于存储要素的空间列类型中至少有一种可用于 ArcSDE 所支持的所有 DBMS - Oracle、IBM DB2、Informix、PostgreSQL 和 SQL Server。这样就可以使用 SQL 来访问要素,并且符合针对空间类型的国际标准化组织 (ISO) 和开放地理空间联盟 (OGC) 标准。

SQL 作用于表中的行、列和类型。列类型(数字、字符、日期、BLOB、空间类型等)是 SQL 代数中的对象。DBMS 管理着这些简单的数据类型和表,而其他应用程序逻辑可以实现更为复杂的对象行为和完整性约束。

然而,只是向 DBMS 添加对空间属性的空间类型以及 SQL 支持并不足以支持 GIS。

在关系 DBMS 中实现更高级的对象和行为

如果开发人员想要实现具有行为和逻辑的更高级的对象,可以通过编写应用程序代码来完成。例如,某组织可以实现一个如下所示的 Employees 表:

Last Name

First Name

Hire Date

Salary

Brown

Ben

10-10-2001

$10,000.50

Jones

Betty

06-14-1998

$22,000.00

Smith

Jason

08-23-1999

$44,000.75

Employees 表

Employees 表是一个由行和列组成的简单关系数据表。每列中的数据符合某一特定的数据类型,如字符、日期和数字。DBMS 是在这一级别处理信息。

但是,只是将该信息添加到 DBMS 表并不会使 DBMS 变为工资单或雇员管理系统。同样,添加用于存储具有两个小数位的数字的 Dollars 列也不会使 DBMS 变为会计核算系统。此时需要更高级的应用程序逻辑。

举例来说,可以实现以下逻辑来支持人事活动:聘用、实施加薪、雇员辞职、晋升和管理福利。为雇员及其姓名、薪水以及聘用日期构建的业务对象不会作为关系对象来实现。要实现这些业务对象的行为以及完整性约束,需要使用更复杂且更有针对性的应用程序逻辑。

GIS 中广泛应用了相似的业务对象。例如,拓扑、网络、线性参考系、栅格目录、注记、terrain、地图图层等都是 GIS 用以基于 DBMS 中所存储的简单空间表现形式来实现 GIS 行为的高级对象。

与其他 DBMS 应用程序一样,对于 GIS 应用程序来说,只是包含具有空间列类型的表是不够的。要构建地理信息系统,需要同时使用上述两组对象,即简单 DBMS 关系列类型对象以及地理数据库应用程序对象(如拓扑)。

应用程序逻辑属于哪里?

无数的数据库管理系统 (DBMS) 实现已有力证实,对表中的行和列类型起作用的单独应用程序层适用于高级应用程序。例如,所有广泛采用的客户信息系统 (CIS)、企业资源规划 (ERP) 系统和会计程序包都在应用程序层实现高级应用程序逻辑,这实现了更强的开放性和扩展性、更高的性能、更丰富的工具集和增强的灵活性。

用户通过绝大多数操作的应用程序逻辑与这些系统交互并在这些系统中执行事务,并且仅使用结构化查询语言 (SQL) 进行重点(和适当的)活动。

分离数据层之上的应用程序逻辑还允许将相同的逻辑应用于 DBMS、文件、可扩展标记语言 (XML) 和其他数据存储备选方法。这使得此架构更加开放。例如,ArcGIS 中的地理数据库应用程序逻辑还用于读取和处理所有地理数据源(如计算机辅助绘图 (CAD) 数据、shapefile、MapInfo 数据、Intergraph GeoMedia 文件和地理标记语言 (GML) 文件)。

保留此更高级别逻辑的其他方法包括作为 DBMS 中的存储过程和数据库触发器或作为 DBMS 中的扩展类型保留。

9/15/2013