什么是对象关系数据库,为什么在空间数据库中需要这种模型?

Wil*_*son 7 database-design spatial relational-theory

GIS SE 中,我们中的许多人使用ESRI 地理数据库。ESRI 将地理数据库描述为object-relational.

什么是对象关系数据库,为什么需要在空间数据库中使用这种模型?

似乎他们采用了一些简单的关系数据库模型,并将其变得复杂。我想知道好处是什么。

我不是 DBA 或开发人员,所以外行的条款将不胜感激。

MDC*_*CCL 6

关系模型和面向对象范式

最先进的关系模型EF Codd 博士于 1970 年提出,是涉及数据库管理领域的应用科学。它的两个坚实支柱是一阶逻辑和集合论。

面向对象的范例,通过如设计艾伦凯博士,是建立应用程序的有用的方法。事实证明,它在构建图形用户界面方面非常有效,可促进最终用户和信息系统之间的交互。

如上所述,上面提到的两个框架中的每一个都有一个非常特定的目的。当用于生成适当类型的组件时,两者都对软件开发项目有很大帮助。

数据库管理、应用程序和术语“对象关系”

关系模型的概念和发展之前,(A)的设计,创建和管理应用程序的沉重与混合(B)的设计,创建和数据管理(在一个特设的方式这一切)。没有可用的科学来以一般和合理的方式处理数据。EF Codd 博士实际上是IBM 的一名程序员,并直接面对上述情况造成的困难。凭借他的才华、实践经验和数学背景,他能够设想和开发一个优雅而强大的基础来管理数据,除其他重要因素外,还允许以独立于应用程序的方式处理所述资源。

我不确定,但是,如果可能存在“'对象-关系'数据库管理系统”,它将是一个可以在其上实现“'对象-关系'数据库”的人工制品。“'对象-关系'数据库”将是一种通过将面向对象的结构与关系工具结合在一起而创建的设备。

很难判断是否可以存在上述性质的数据库管理系统,因为通过引入面向对象的构造,许多关系功能处于危险之中(有关信息,请参阅“Codd 的十二条规则”),因此也很难被认为是关系即使部分如此。

事实上,(i) 将面向对象的工具附加到关系数据库管理系统和 (ii) 在它之上实现的关系数据库中使用它们是完全没有必要的。

然而,有一些“当前”观点主张通过面向对象的模式,将设计、创建和管理的混合体用于 (a) 应用程序和 (b) 数据库。就数据库部分而言,这可以解释为向前科学(即前关系)时代回归的邀请(因为,自然地,没有与数据管理相关的面向对象模型) .

就其本身而言,关系模型提供了通用和强大的机制来设计(逻辑结构)、约束(值)和操作(抽象)数据。它们的好处之一是它们非常简单(但绝不简单)。为了充分利用上述机制,数据库管理员/操作员必须使用关系(通常在给定的 SQL 平台中声明为),并且如您所知,关系或不是关系的一部分。面向对象范式(既不提供数据完整性约束也不提供一般数据操作操作,也不应该这样做)。

关系语言的强大之处在于它的表达能力,而不是它的计算方面。粗略地说,当遵循关系方法时,我们声明了感兴趣事物的结构(它们的方式,它们的结构),而使用面向对象语言(例如,Smalltalk)时,应该主要处理重要事物的行为(他们如何做他们所做的事情,他们执行的过程),这对于应用程序编程来说是最重要的。

关系数据库的众多优势之一是,由于它必须独立于应用程序编程阶段所使用的语言或范式进行设计,因此它可以与多种语言和/或应用程序编程范式和/或多种应用程序一起工作同时进行程序。

也就是说,关系数据库必须由遵循关系原则的设计者构建,因此将 (1) 特定数据库构建到 (2) 特定关系数据库管理系统上并不会自动授予该特定数据库关系标签

ArcGIS地理数据库

为了帮助理解您在问题中包含的arcgis.com链接,我认为当使用术语地理数据库时,它实际上是一个完整地理信息系统上下文名称,其中可能包括

  • 建立在一个或多个数据库管理系统之上的一个或多个适当的数据库,以及
  • 一个或多个与所述数据库一起工作的应用程序。

在这方面,让我们看一下地理数据库的适当数据库的体系结构,其中指出:

地理数据库存储模型基于一系列简单但必不可少的关系数据库概念,并利用了底层数据库管理系统 (DBMS) 的优势。简单的表和定义明确的属性类型用于存储每个地理数据集的模式、规则、基础和空间属性数据。这种方法提供了一个用于存储和处理数据的正式模型。通过这种方法,结构化查询语言 (SQL)(一系列关系函数和运算符)可用于创建、修改和查询表及其数据元素。

所以这在某种程度上表明数据的处理独立于访问它的应用程序,当然这将是非常有价值的。

然后,此页面包含以下标题(以断言的形式)和段落:

地理数据库是对象关系

地理数据库通过在数据存储层(在各种数据库管理系统 [DBMS]、文件或可扩展标记语言 [XML] 内进行管理)之上的应用层中实施高级逻辑和行为,采用多层应用架构。地理数据库应用程序逻辑包括对一系列通用地理信息系统 (GIS) 数据对象和行为的支持,例如要素类、栅格数据集、拓扑、网络等。

这似乎表明对象行为(应用程序对象的行为方式)在应该处理的地方处理,即在应用程序级别(或“层”,如此处所述)。

此外,回到地理数据库 架构页面,引入了一个相同的标题和一个与上面提到的非常相似的段落,如下所示:

地理数据库是对象关系

地理数据库是使用与其他高级 DBMS 应用程序相同的多层应用程序架构实现的;它的实施没有任何异国情调或不寻常之处。地理数据库的多层体系结构有时称为对象关系模型。地理数据库对象作为具有标识的 DBMS 表中的行持续存在,并且通过地理数据库应用程序逻辑提供行为。应用程序逻辑与存储的分离允许支持多种不同的 DBMS 和数据格式。

一个以特殊方式引起我注意的摘录是“地理数据库对象作为具有标识的 DBMS 表中的行持久存在”,这是一种误导,因为关系数据库的表(即关系)保留表示的行(即元组)带有特定业务域谓词(可用于定义实体类型)提供的特定含义的断言,因此它不“持久化”对象。此外,由于对象的一个基本特征是它的行为(基本上,它的方法),了解它如何在关系数据库中“持久化”会非常有趣。

另一方面,重要的片段“应用程序逻辑与存储的分离允许支持多种不同的 DBMS 和数据格式”似乎强调了将数据与应用程序分开处理的巨大相关性。

结论

我的结论是,ArcGIS地理数据库既不是 (a) 对象关系数据库,也不是 (b) 对象关系数据库管理系统。如前所述,它很可能是一个完整的地理信息系统,它由 (i) 一个或多个实际数据库(其中一些可能或多或少是相关的)和 (ii) 一个或多个应用程序(其中一些可能或多或少是面向对象的)访问所述数据库。

也许这就是它在上下文中被称为“对象关系”的原因。