关于SDE的思考[转]

关于SDE的思考[转]

学无止境 2010-03-03 14:39:44 阅读11 评论0 字号：大中小

因为自己对ArcSDE的理解还是比较浅，有点模糊，但脑子里有一个将ArcSDE功能进行扩展的念头，不知道SDE是否支持二次开发，我们能否将空间数据管理的功能集成到其中？先将这篇文章收藏在这：

ArcSDE中间件技术的生命力

把ArcSDE的技术看成是一种对于空间数据管理而言可有可无的"鸡肋"，实际上是一种简单化的、"形而上学"的观点。持该观点的思维逻辑是：既然ArcSDE和OracleSpatial都是用于存储空间数据，那有了Oracle还要ArcSDE何用？显然，该逻辑的前提是将ArcSDE和OracelSpatial等同起来。错误的前提导致了无效的结论。而导致前提出错的根源，除了非技术的（或者说商业的）原因之外，主要还是对ArcSDE本身以及空间数据管理技术及其发展趋势缺乏深入了解。

首先，ArcSDE和Oracle Spatial的定位不同。Oracle Spatial强调或关心的是使Oracle DBMS所管理的数据库能够"空间化（spatiallyenabled）"，实际上是在原来的数据库模型上进行了空间数据模型的扩展。同样的工作，除ORACLE外，IBM的DB2和Informix也在做，分别有其Spatial Extender和SpatialDatablade技术。它们的定位应该说是基本一致的。与DBMS厂商不同，ESRI的ArcSDE的定位则是空间数据的管理及应用，而非简单的数据库空间化。也正是由于定位的不同，OracleSpatial实现的仅仅是"点、线、面"等简单空间要素的存储和检索，而ArcSDE则除此之外还能管理面向对象的注记、平面拓扑、线性拓扑、栅格（影像）数据、CAD数据等，同时提供基于版本管理的工作流和长事务处理机制。定位的不同，使得ArcSDE和OracleSpatial的数据模型、实现技术及客户端应用都存在相当的错位，对于用户而言，二者就不是"非此即彼"、"非0则1"的互斥之选了。

很能说明问题的事实是：ORACLE、IBM、INFORMIX（现在Informix已被IMB并购）等DBMS厂商都是ESRI的合作伙伴，在空间数据管理技术的开发上都与ESRI有较为深层次的合作，ESRI在其中贡献的是其对空间数据管理及应用的深厚底蕴。ESRI和DBMS厂商间是一种各施其长、互惠互利的合作关系.

其次，就空间数据物理模型而言，ArcSDE和Oracle Spatial支持的共五种：

A. 压缩二进制LONG RAW；（ArcSDE 支持）

B. 压缩二进制LOB；（ArcSDE支持）

C. 对象相关VARRAY；（ORACLE 支持）

D. OGC空间类型；（ArcSDE支持）

E. 规范化存储。（ORACLE支持）

其中，ArcSDE支持的三种格式要么与OGC（OpenGIS Consortium）颁布的规范（Simple FeatureSpecification for SQL）一致（d）,要么完全含盖了OGC的规范，并作了相当的扩展。而ORACLE所支持的两种格式都与OGC规范不全相容。这自然会影响到今后完全基于该平台的GIS系统的数据共享和互操作性。而数据共享和系统互操作性是GIS平台本身及其应用发展的关键趋势。

第三、上面提到的空间数据的五种物理实现方式的访问效率从高到低依次为：a、b、c、d、e。ArcSDE的方式效率是最高的。因为要解决面向多用户并发访问的海量空间数据管理和驱动，效率始终是ArcSDE重点考虑的问题。

第四、ORACLE的对象相关VARRAY方式是所谓的"白箱"，即数据对象所"包裹"的内容是可以直接访问和操纵的。而ArcSDE的方式则是所谓的"黑箱"，客户端不能直接在数据库表一级直接操作底层数据对象结构中的内容（因为是二进制吧？）。"白箱"的好处是其客户端可以直接通过SQL访问数据，这也是许多GIS厂商在空间数据管理上避重就轻而直接依赖于OracleSpatial的原因之一。但正因为如此，数据的一致性成了问题。DB2和Infomix似乎都看到了问题所在，所以也摒弃了"白箱"的模式。

从上面四点可以看出，ArcSDE并非因为有了Oracle Spatial就成了多余的东西。相反，对于那些不仅仅满足于将空间数据找个地方存起来的应用（具有更高要求的应用），考虑ArcSDE是更合理的选择。

ArcSDE相对于其所选用的DBMS而言，是扮演了一个"中间件"的角色。为什么需要中间件？就是因为没有一种数据库平台可以在不同操作系统、不同级别、不同领域的应用中"大包大揽"一统天下。而不同的DBMS在数据模型、物理实现等诸多方面都存在很大差异，要靡合这些差异，靠DBMS厂商自身是不可能解决问题的。DBMS厂商当然希望能一统天下，但事实证明，在充分竞争的商业环境里，在可见的将来这是不可能做到的。数据库领域如此、其它如电子商务领域也同样如此。那解决之道何在？答案是：中间件。通过中间件的作用，将不同的操作系统平台和数据库平台的差异之处屏蔽在中间件之后，将面向特定领域（如空间数据管理及应用）所需的技术高度专业化地实现出来（抽象），供不同的客户端高效地共享和互操作。

当然，DBMS不能一统天下，作为空间数据服务器的ArcSDE也不能。在当前除ESRI以外的GIS厂商尚未推出强有力的类似ArcSDE的"中间件"之际，诸多GIS厂商对空间数据管理"中间件"的攻击实出无奈。但是，信息化社会须以消除信息孤岛为必要条件，而要各信息之岛间能够互联互通互操作，要么把信息平台全都统一，要么以某种方式将不同的平台沟通起来，针对不同的领域，各自建立面向应用的虚拟空间及界面。前者不可能，后者则正在由各色各样的"中间件"担纲领衔。"中间件"在电子商务和其它互联网应用中正在大行其道（全球产值已逾700亿美元），在空间数据管理领域，ArcSDE只是先行了一步。

______________________

红色的部分说的很明白，中间件是将不同屏蔽，暴露出相同接口。那在这不同和相同之间，中间件做的什么呢？拿我们空间信息领域来说，是将不同数据库平台中存储的不同数据模型、不同数据结构的空间数据转化为可被GIS应用程序识别和处理的空间对象。那我们是否可将更多的功能从GIS软件中抽象出来，放入SDE中？即在空间领域普遍通用、可被自动完成且又十分常用的功能，如投影转换、尺度变换等功能，从GIS软件中剥离出来，融入到SDE中。从SDE中获取到的不再是原生态的数据，而是满足用户需求的，经过SDE自动处理的数据？当然，不可能所有的功能都拿到SDE中，只有那些可以自动完成不需人工干预的操作才可以，如一个简单的缓冲区计算。

转载自：http://blog.163.com/sky_zzb/blog/static/1213095172010232394486/

转载于:https://www.cnblogs.com/wuhenke/archive/2010/03/20/1690530.html