数据库设计漫谈

数据库设计漫谈 青岛海洋地质研究所 戴勤奋 I Copyright © 2008 by Qinfen Dai. All right reserved. I 目 录 前 言 ................................................................................................................................................I １ 什么是数据库.......................................................................................................................... １ 1.1 数据模型发展历程............................................................................................................. ２ 1.1.1 网状与层状数据模型.................................................................................................. ２ 1.1.2 关系数据模型.............................................................................................................. ２ 1.1.3 面向对象数据模型...................................................................................................... ３ 1.1.4 后关系数据模型.......................................................................................................... ４ 2 数据模型设计............................................................................................................................ ６ 2.1 整体框架约束下的迭代渐进............................................................................................. ７ 2.2 数据总体结构设计............................................................................................................. ９ 2.2.1 工作流与数据流分析............................................................................................ １１ 2.2.2 面向对象分析与设计............................................................................................ １５ 2.3 概念数据模型设计 ....................................................................................................... ２１ 2.3.1 关于概念数据模型的概念...................................................................................... ２２ 2.3.1.1 关于概念与实体的含义................................................................................... ２２ 2.3.1.2 关于概念层与物理层....................................................................................... ２３ 2.3.1.3 关于范式........................................................................................................... ２３ 2.3.1.4 关于属性定义................................................................................................... ２５ 2.3.1.5 关于属性的域................................................................................................... ２５ 2.3.1.6 关于联系定义................................................................................................... ２７ 2.3.1.7 关于主键设计................................................................................................... ２８ 2.3.1.8 关于外键设计................................................................................................... ２８ 2.3.1.9 关于可取值列表............................................................................................... ２９ 2.3.2 实体关系图与数据字典.......................................................................................... ２９ 2.3.3 Geodatabase 数据库数据模型设计 ......................................................................... ３５ 2.3.3.1 Geodatabase 框架结构元素 .............................................................................. ３５ 2.3.3.2 划分要素集和要素类....................................................................................... ３６ 2.3.3.3 要素分类编码................................................................................................... ３９ 2.3.3.4 关于拓扑........................................................................................................... ４３ 2.3.3.5 关于地图注记................................................................................................... ４５ 2.3.4 测试与优化.............................................................................................................. ５０ 2.4 构建数据库模式 ........................................................................................................... ５１ 2.4.1 什么是数据库模式................................................................................................ ５１ 2.4.2 什么是数据完整性................................................................................................ ５３ 2.4.3 表空间部署.............................................................................................................. ５４ 2.4.4 数据库模式对象部署.............................................................................................. ５５ 2.4.3.1 表及其约束....................................................................................................... ５６ 2.4.3.2 索引....................................................................................................................... 59 2.4.3.2 同义词................................................................................................................... 59 II 2.4.3.3 视图 ...................................................................................................................... 59 2.4.3.4 存储过程或函数 ................................................................................................. 60 2.4.3.5 触发器................................................................................................................... 60 2.4.3.6 包 .......................................................................................................................... 61 2.4.5 数据库重构.................................................................................................................. 62 3 元数据 ....................................................................................................................................... 63 3.1 元数据标准定制................................................................................................................. 65 3.2 元数据内容......................................................................................................................... 66 3.3 元数据 XML 格式化.......................................................................................................... 67 3.3.1 XML 来源..................................................................................................................... 67 3.3.2 XML 有效性验证......................................................................................................... 68 3.3.3 XML 显示..................................................................................................................... 69 3.3.4 XML 格式元数据的实现............................................................................................. 69 3.4 元数据编辑器..................................................................................................................... 70 3.5 一个元数据样式显示的核心元数据................................................................................. 71 3.6 一个元数据样式显示的完整元数据................................................................................. 73 4 应用架构设计............................................................................................................................ 84 4.1 DINO 生存环境................................................................................................................... 85 4.2 DINO 设计目标................................................................................................................... 87 4.3 DINO 功能架构................................................................................................................... 88 4.3.1 数据存储（Archiving）.............................................................................................. 88 4.3.2 数据管理（Maintenance） ......................................................................................... 89 4.3.3 数据分发（Dissemination）....................................................................................... 90 4.4 DINO 技术架构................................................................................................................... 92 4.4.1 数据存储层（Data Storage Layer）........................................................................... 93 4.4.2 应用服务层（Application Service Layer）................................................................ 94 4.4.3 前端服务层（Front Office Layer）............................................................................ 95 5 结束语........................................................................................................................................ 97 I 前 言 我开始学着做数据库设计时把这项工作想得很简单，觉得数据库设计就是设计几个数 据表而已。随着工作的深入，发现并非如此，要建立一个性能良好、可扩展、经得起时间 考验的数据模型不容易，因为这是一个系统工程，做系统工程需要统筹，需要权衡，需要 在各种冲突中寻求折中方案。因此与其说数据库设计是科学，倒不如说是一门艺术，权衡 的艺术。 目前数据库在商业领域演绎得很成功，已经到了离不开数据库的地步，但在科研领域 并非如此，虽然近几年对数据库的重视程度有所提高，但实际上数据库也只是先进科技的 标志而已，数据重利用程度并不高，其中的原因是多方面的。但不管什么原因，数据库设 计在其中举足轻重，因此这里想就此谈谈我自己的体会，从比较基础的层面上来谈，希望 能对像我这样半路出家的数据库设计人员有用。 戴勤奋 qddqinfen@cgs.gov.cn 2008 年 10月 １ １ 什么是数据库 经常有人问我：“你们的数据库到底能干什么？”；每年申请课题时会有课题负责要求 我写一段描述数据库重要性及先进性的文字插入他们的课题申请报告中；每当课题结束时 会有上级要求我们把数据库放到光盘里上交资料档案室（一直觉得这种要求挺怪的）。这几 年，数据库在各种场合频频出现，科学数据共享、数字地球、数字海洋等等都离不开数据 库，但其实大家对数据库了解并不多。当然一般的数据库用户不需要去了解，但对科研决 策的制订者以及数据库建设人员来讲，给出数据库的准确定义将有助于工作的正确导向。 因此开门见山，先谈谈“什么是数据库”。 韦氏大词典上说：“Database is a large collection of data in a computer,organized so that it can be expanded,updated,and retrieved rapidlly for various uses.” （数 据库是大量数据的集合，它们存储在计算机中，有组织，可扩展，并能快速更新、存取， 服务于不同的用户。） 从上述定义可知，数据库是能有效存储大量数据并提供数据应用服务的技术。但是现 实世界丰富多彩、错综复杂，数据库这一应用技术通过什么途径来实现繁杂数据的有效存 储与服务呢？从科学探索到市井生活，解决复杂问题的常规方法基本上都是由大化小，由 难化易，由共性到特殊，于是就有了数据库技术的核心和基础“数据模型”，通过数据模 型抽取问题域的本质特征，将现实领域简化在我们的掌控之中。因此，数据库又可进一步 定义为：数据库是通过数据模型简化数据对象实现数据有效操作的应用技术。 “数据模型+数据”是规范化后的数据；“数据有效操作”是对数据的快速检索和更新， 实际上是为了支持一个或多个工作流程，也就是为了实现应用，因此数据库可划分为两大 部分：数据和应用，数据库设计也即划分为两大部分：数据模型设计和数据库应用架构设 计。数据模型设计是将现实领域限制在数据模型的框架和约束下，让数据成为规范化数据， 为实现数据有效操作奠定基础；而数据库应用开发就是搭建良好的平台，让数据能得到大 范围共享与重利用。数据与应用是相互依托的，后台存储的数据是应用的支撑，前台的应 数据库是通过数据模型简化数据对象实现数据有效操作的应用技术。 ２ 用是数据的表现，数据库技术的最高境界是让数据走出数据库活动在应用流程中。 1.1 数据模型发展历程 过去几个世纪，数学家和物理学家们通过模型来简化复杂的自然现象，从模型中抽取 现象的各种研究特征，并通过实验来验证，使数学和物理学取得了巨大的进展。数据库技 术也有着同样的发展历程。 1.1.1 网状与层状数据模型 1961 年美国通用电气公司 Charles Bachman 等人开发出世界上第一个网状模型的数据 库管理系统 IDS（Integrated Data Store，集成数据存储），为网状模型数据库的发展奠定 了基础。 网状数据库模型对于层次和非层次结构的对象都能比较自然的模拟，在关系数据库出 现之前网状数据库管理系统要比层次数据库管理系统用得普遍。在数据库发展史上，网状 数据库占有重要地位。 1969 年 IBM 公司 Mc Gee 等人研制出层次模型（树型结构）的数据库管理系统 IMS （Information Management System，信息管理系统），成为最典型的层次型数据库管理系 统。 网状数据库和层次数据库都很好地解决了数据的集中和共享问题，但在数据独立性和 抽象性上有很大欠缺。 1.1.2 关系数据模型 1970 年，IBM 公司 San Jose 研究所的 E.F.Codd 博士发表了题为“A Relational Model of Data for Large Shared Data Bank”（大型共享数据库数据关系模型）的著名论文， 开创了数据库的关系方法和关系规范化理论的研究，他本人因此荣获 1981 年国际计算机协 数据库技术的最高境界是让数据走出数据库活动在应用流程中。 ３ 会（ACM）图灵奖。 由于关系模型有严格的数学基础，抽象级别比较高，而且结构简单，便于理解和使用， 对数据库的发展起到了至关重要的作用。 七十年代中期，IBM San Jose 研究所在 IBM 370 系列上研制了 System R 关系型数据库 管理系统；加州大学伯克莱分校在 Vax 系列机上实现了 Ingres 关系型数据库管理系统，这 些实验性系统在关系数据库管理系统的实现和系统性能方面作了大量工作。 1976 年 HONEYWELL 公司推出了第一个商用关系数据库产品 Multics Relational Data Store。 1979 年 Oracle 公司推出了第一个商用 SQL 关系数据库管理系统，Oracle V2.0。 1983 年 IBM 推出了 DB2 for MVS V1 关系数据库产品。 大量商品化关系数据库系统的问世及推广，使得关系数据库的应用深入到人类生活的 各个领域。经过几十年的发展，关系数据库技术已经相当成熟，但是关系数据模型在处理 非结构化数据方面始终是心有余而力不足。随着网络技术的发展，Web 页面、电子邮件、音 频、视频等非结构化数据爆炸式增长，关系数据模型在速度和性能方面的局限性也越来越 明显。 1.1.3 面向对象数据模型 九十年代，受当时面向对象技术风潮的影响，人们把大量的精力投入到面向对象的数 据库系统（object oriented database）研究。 鉴于面向对象技术的特点，面向对象数据库能满足复杂数据结构和海量存储的需要， 并且在应用系统开发速度和维护等方面有着极大的优越性，同时也有利于异构平台间的分 布式数据库运行。但好的技术并不表示好的市场前景。 面向对象方法与一般人的思维规律相符合，因此面向对象数据库最大的性能优势是能 以使用数据的方式组织数据，但也由此带来了对象－关系不匹配障碍。面向对象模型是以 分类为基础的，类用来定义存储在数据库内对象的结构及行为；而关系模型的基础是关系， 也就是基于关系的表，它要求将数据组织成规范的二维表，这种组织方式往往要求对象在 经过分解后才能进入数据库，使用对象时再通过 SQL 语言进行组装。可见面向对象概念与 关系概念是两个完全不同的概念，采用纯粹的面向对象数据库意味着取代原有关系数据库。 但由此带来的数据转换工作量和巨额开支是关系数据库老用户们不愿意承受的，因此市场 ４ 发展情况并不理想。而且面向对象语言和关系型数据库使用语言的方法不同，使得面向对 象数据库对 SQL 的支持很少，即使带 SQL 接口也难以创建用于管理商业智能应用所产生的 这类查询机制，因此在通用性方面也失去了优势。 于是在 1997 年出现了对象关系数据库，也就是在关系模型之上加入对象到关系的映射。 对象关系模型允许关系表中的列含有复杂的对象，这些对象能够捆绑“处理过程”来处理 复杂数据，并且允许 SQL 调用与关系型等同的“对象方法”。因此既支持已经被广泛使用的 SQL，具有良好的通用性，又具有面向对象特性，支持复杂对象及其行为，达到了对象技术 和传统关系数据库技术的融合。但是，根本问题并没有解决，对象关系数据库仍受不匹配 障碍的困扰。 1.1.4 后关系数据模型 进入 21 世纪随着 Web 应用的发展，如何有效地存储和管理 Web 上的文档数据，使其既 能被高效地操作和维护，又能在 Internet 平台上方便地表示和交换，给数据库技术提出了 应用需求。于是出现了所谓的后关系型数据库，也就是 XML 加关系模型数据库。 1999 年 Oracle 8i 率先推出了支持 XML 的版本，它将每个 XML 文档完整地存储为一个 大对象，或者将 XML 转换为关系列和行分散到表中，实际上未能实现 XML 的原生态存储， 原生态 XML 是以层次格式组织数据的，早期研究已经证明数据的层次格式难以支持快速高 效的数据检索。2002 年 Oracle 9i 在其第 2 版 Oracle 9i R2 中引入了高性能的本地 XML 数 据管理技术 XML DB，为 XML 存储创建了新的数据类型 XMLTPYE。XMLTPYE 列提供了结构化和 非结构化两种存储方式，存储在非结构化 XMLTYPE 中的 XML 文档以大对象存储；存储在结 构化 XMLTYPE 中的 XML 文档可以通过优化方式进行解析和存储。Oracle 利用高度优化的文 件夹模型将关系结构影射到基于路径的结构，并在关系表中使用特定的索引来加速基于路 径的访问，据测试，Oracle 处理 XML 数据的速度非常快，可以通过事务以每秒 2500 条数据 的速度处理 XML。性能提高了，但是实际上仍未能实现 XML 的层次结构存储。2005 年 5 月 Oracle 10g 第 2 版 Oracle 10g R2 推出，声称第一个在商业上包含了对 XML Query（XQuery） 标准的支持（XQuery 语言于 2007 年 1 月正式成为万维网联盟 W3C—World Wide Web Consortium 推荐标准），完全将 XML 嵌入其体系结构中。 2007 年 7 月推出的 Oracle 11g 中 XML 成为热点，在 Oracle 11g 中还可以使用 CLOB 及二进制两种方式存储 XML 信息，灵 活性提高。此外，Oracle 11g还提供了二元性的 XML 支持，即用户既可以将 XML 嵌入到 PL/SQL ５ 中使用，也可以将 PL/SQL 整合到 XML 中使用。 微软公司在 2005 年底发布了代号为 Yukon 的 SQL Server 2005，该产品可以存储和处 理 XML 类型的数据，并支持 XQuery 的 XML 数据检索。 IBM 在 2006 年 7 月推出了基于 XML 技术的新一代数据库系统 DB2 9，代号为 Viper（毒 蛇），声称把数据库技术领入了 XML 时代。它利用 IBM 的 PureXML 技术，解决了关系模型和 层次模型的共存问题，用户可以混合使用 SQL 和 XQuery 进行数据搜索与处理，实现了关系 型数据和 XML 数据的无缝操作。 XML 数据库的出现和发展是否意味着数据库技术进入了一个新时代，即混合型数据库时 代？现在还难以定论。 ６ 2 数据模型设计 数据库数据模型经历了近 50 年的发展历程，目前主流数据库仍然是关系模型数据库, 面向对象也好,XML 也好,都只不过是点缀,需要时可以用,不用也无妨。不过本节所谈的不是 关系数据模型本身，而是关系数据模型基础上的专业领域数据模型。 专业领域数据模型具体怎么来设计，很难有明确答案，因为各专业领域具体情况各不 相同，数据库建设目标也各不相同，数据库设计又需要根据实际情况与需求权衡，作出最 佳折中方案。因此很难说这样好，那样就不好。数据模型的好坏标准是它能否有效，而不 是完不完美或正不正确。一个完美得可以预见未来任何变化的设计，或一个灵活得可以容 纳任何扩展的设计是不存在的。数据库设计不是追求完美，而是寻求平衡。 涉及关系数据库系统产品的书很多，大部分针对特定数据库产品的操作使用和应用开 发，如：“SQL Server 2005 数据库开发详解”、“Oracle 9i&10g 编程艺术：深入数据库体 系结构”、“数据挖掘原理与应用：SQL Server 2005 数据库”、“SQL Server 2005 数据库开 发实战”等等，但涉及数据库设计的书不多，就是有也是谈理论居多，谈实际设计过程的 少，看完了还是一头雾水，面对自己的专业领域不知从何入手，如果你是非专业领域人士 （大多数情况下是如此），对专业知识和工作流程不甚了解的话，更是举步维艰，只能根据 专业部门提供的报表格式照样画瓢。我刚开始做数据模型设计工作时就有这种感受，几年 工作下来，经历了不少挫折，也长了知识。现在，我经常有一种冲动，恨不得把我原来设 计的数据模型推倒重来，因为里面有太多的毛病，但是这几乎是不可能的，数据库建成后 只能改良不能改革。于是我就想把我的认识写下来，写给别人看，也写给自己看。 在进入正题前先谈谈数据模型设计前的前期预备工作。 首先，数据模型设计前必须明确设计目标，目标是衡量设计好坏的标准，也是设计必 须遵循的规则。经常有这样的感受，随着工作的深入会渐渐把真正的设计目标忽略了，结 果走了不少弯路，做了许多不该做的事。设计目标确定，就可以作为依据来划定工作范围， 工作范围确定了，工作的深度、广度与焦点也就确定了，你也就知道哪些该做，哪些不需 要做，哪些需要马上做，哪些可以在下阶段再做，这样工作就可以合理、有序地开展，不 至于陷入忙乱之中。 其次，在设计前应了解所设计数据库的特点，以便在设计时权衡利弊，把握设计的度， 在应用与约束之间寻找最佳折中方案。商业领域的数据库数据几乎每时每刻都可能变化， ７ 用户量大，涉及大量的事务处理，因此需要多多关注数据在频繁变动过程中的完整性及可 恢复性。在科研领域，数据库的数据变动则取决于科研项目的工作进程，每期工程结束会 有大批的数据进库，平时变动不大，但数据量大，涉及大量数据的安全存储与管理；在数 据应用方面，一般会要求通过网络的数据快速定位与提取，要求数据的多方管理，要求数 据的可理解性，要求数据的可挖掘性等，但用户访问量不会太大。从另一角度来说，科研 领域的数据库接近维度数据库（数据仓库），主要目的是历史数据的管理，以及海量数据中 的钻取与挖掘。 2.1 整体框架约束下的迭代渐进 谈到关系数据模型设计，首先想到的可能会是“概念数据模型设计”及实体关系图（ER 图），但我认为完整的数据库数据模型设计需要经过三个阶段： （1） 数据总体结构设计； （2） 概念数据模型设计； （3） 构建数据库模式。 数据总体结构设计独立先行，工作内容是将问题域数据对象抽象为不同的类，构建出 数据整体框架。而后在整体框架约束下，根据需要先后选取待设计的数据类，实施概念数 据模型设计与数据库模式设计。各数据类的概念数据模型与数据库模式的设计工作可按实 际需要渐进，当前不需要的可暂时放一放，待需要时再补充。这样做的好处在于一方面能 把设计工作大事化小；另一方面，如果总体结构设计合理，即使后期部分模块的数据模型 设计不理想，也不会造成全局性的倒塌。 这里，我将上述设计过程统称为整体框架约束下的迭代渐进设计过程。工作以迭代方 式进行，表示将设计工作分割成一系列小的整体，每一个小整体的工作包括分析、建模、 测试、优化、部署等各个环节，完成一个小整体的设计工作，即完成一个迭代，然后是下 一个迭代，再下一个迭代，各个迭代之间的关系是并联的关系，互相没有内容及先后依赖， 某一迭代中的问题与修改不会对其它迭代工作产生不良影响，这种过程有别于串行（瀑布 式）的工作方式，在串行工作方式中，你必须首先确定所有需要实现的需求，然后创建详 细设计，然后实现该设计并进行测试，最后部署到数据库系统中，串行工作过程中要求每 一阶段的设计内容都是完美的，否则将会影响后面的设计内容，但是设计中出现各种各样 的问题是不可避免的，设计完成后出现各种各样的的变动也是正常的，因此串行工作方式 ８ 在一定程度上忽略了现实中的基本事实，由此引起的现实冲突和人员之间摩擦也不可避免， 在这方面，我深有感触。 迭代渐进式设计方法与石油地质勘探过程有类似之处。石油勘探的目的当然是找石油， 目标很简单，就是找油，但地质工作者真正找的却不是油，而是有利于油气聚集的构造圈 闭。构造圈闭的勘测过程是一轮又一轮逐渐缩小包围圈向目标逼近的过程：先采用成本比 较低的方法扫面，了解目标区内的区域地质构造特征，圈出有油气前景的盆地及凹陷；然 后选择有前景的凹陷区布设成本较高的二维地震测网，进行加密勘测，把握次一级地质构 造特征；再在次一级油气前景构造中布设成本很高的三维地震测网进行详测，圈定可能的 储油构造；最后定井位打井，如果出油，则计算石油储量，进入石油开采阶段，如果没有 油气显示，则转移到下一个具油气前景的凹，开始新一轮调查。撇开传统的石油地质勘探 过程，假如有某位领导找来张三李四，吩咐他们先把凹陷区、凸起区、圈闭、井位、石油 储量统统写出来，然后交给勘探部门去打井，可能任何人都会认定那位领导不正常，但是 在数据库设计或计算机软件设计工作中这种现象经常发生，当然有时为了完成任务也不得 不这样做，但这样做的结果是可想而知的。与传统石油勘探工作方式相似，数据库设计也 应该在前期先做扫面性的整体分析工作，然后抓住重点逐步推进，在不断探索、总结及完 善过程中将设计模型从问题域中推出，然后让它再回到问题域中去，使其能在问题域中得 到优化及应用。 此外，设计过程中保持正确的设计态度，把握设计的度也非常重要。首先，设计过程 中应积极与相关专业人员沟通，学习专业领域的知识，把握专业数据的生产流程，发掘专 业人员心目中的重要专业要素。同时，应以发展的眼光去看待你遇到的问题，勇敢自信地 面对变化。在数据库设计领域，唯一不变的就是变化本身，变化是正常现象，如果害怕变 化，说明你的第六感觉正在告诉你，你的设计有问题，该改一改了。在设计尺度把握上， 应从简单实用出发，不要过度设计，但这个简单不是粗糙，简单意味着能让开发人员不需 要费时间学习就能理解你的设计意图；意味着你的设计留有余地，能长期有效维护，当日 后需求有变更时，你能有自信在现有模型上进行重构（不影响大局的修改，也就是低成本 修改）或扩展。其次不要追求完美，没有必要试图在一开始就建立一个囊括一切细节的模 型，实际上你也很难做到。只要把住大方向，以当前需求为基准，在开始阶段设计一个基 础模型，然后在实际应用中慢慢地改进，这就是递增的思想。 最初的设计思想决定着一个系统的命运，现在我经常提醒自己的一句话是“别把系统 做死了”，言下之意是系统的雏形有可能不太好，但可以改进，让丑小鸭有希望变天鹅，而 ９ 不是拔苗助长，一锤子买卖。我目击了太多这样那样的数据库系统，又宣传又获奖，然后 连用都没用就销声匿迹了，有时侯想起来心里有说不出的感觉。 2.2 数据总体结构设计 我们通过数据库前台看到的通常是以表形式组织的数据，因此数据模型设计常被认为 是数据表设计，总体结构设计部分就常被忽略。我曾参加过一些数据库项目的研究成果汇 报，上去做报告的会说我们的数据库在 XXX 国际主流平台上开发，共设计了XXX个表，然 后一个一个表展示，看着做了很多工作，实际上把最重要的工作忘了，即这些数据表是应 该有组织的，这个组织就是总体结构。总体结构是数据对象存储的整体框架，整体框架是 整个数据库的支撑，总体结构设计得好，数据库的支撑力就强，即使后期的设计工作差一 点也不至于影响全局。 做数据模型设计时必须明白，前台看到的与后台存储的不是一回事，就像商品在商场 柜台里的摆放方式与货物在仓库里的堆放方式不可能是一致的，在商场里怎么对销售有利 就怎么放，而在仓库里肯定得考虑容易管理、容易提取、并且尽量少占仓储空间。曾经遇 到过做数据库设计的为投影坐标数据的存储发愁，因为假如每个投影存一套数据的话，那 数据库里要存多少套数据？这是我目前最常见的把数据显示与数据存储混同的现象。投影 是数据显示时的选择，后台可以用经纬度存储，根本就没必要去关心投影问题。因此，做 数据库设计的人员必须把数据显示与数据存储这两个层的概念范畴区分开，这有利于设计 工作的简单化，GIS数据库的设计尤其如此。以ERSI 的Geodatabase为例，Geodatabase是 建立在关系型数据库管理信息系统之上的空间数据库，在Geodatabase框架结构下，地图通 过存储层与表现层的两组数据对象构建，空间数据以Geodatabase的要素类与要素集组织并 存储管理，最终通过图层及地图样式综合表现，如图2.1。存储层与表现层的两组逻辑结构 概念清楚了，Geodatabase的数据模型结构也就把握住了。 Geodatabase实现了公共模型框架下的矢量、栅格、TIN、网络、地址等地理空间数据的 统一存储与管理，利用Geodatabase数据库设计就变得简单得多，因为总体结构框架确定了， 把数据显示与数据存储这两个层的概念范畴区分开，有利于设计工作的简单化。 １０ 需要做的事情只是在框架内填空，而且后台的数据库模式都是通过前台的ArcCatalog由系统 自动创建，不需要考虑太多的后台技术问题。近来有趋势把数据库完全依托Geodatabase来 做，因为这样既简单快速，也容易见成效。Geodatabase就好比是架傻瓜相机，不需要太多 的专业知识就能完成任务，但一个专业的高级摄影师是不会用傻瓜相机的，因为很难按自 己的意愿拍摄希望达到的效果。因此，如果是一个大中型的企业级数据库，我个人认为把 数据全部建在Geodatabase之上不是长久之计，因为过于依赖第三方产品了；而且从目前来 看，ARCGIS产品本身的稳定性也不是太好，有能力的话应仍以传统的关系数据库管理方式 为主，将Geodatabase作为一个空间数据的管理模块比较合适。 图2.1 存储层与表现层的空间数据对象及对应关系 １１ 总体结构设计是面向专业领域（下面统称为问题域）的设计，首先需要全面分析并把 握专业领域工作过程中可能产生的数据流，在此基础上采用面向对象的分析方法，进行问 题域各种数据对象的抽象，构建出数据类图，然后理顺数据类之间的关系，创建出数据总 体结构。一个好的总体结构应能体现完整的框架体系、支持多层次应用开发、而且稳定能 包容变化。 由于总体结构只是一个静态框架，因此总体结构设计只涉及静态对象建模，建模工具 采用UML。UML（Unified Modeling Language，统一建模语言）是目前最常用的面向对象建 模语言，1997年由OMG组织（Object Management Group，对象管理组织）发布，为开发团 队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年 的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划，就 像建筑工人多年来使用的建筑设计图一样。UML是一种可视化的表达方式，促使你的设计思 想能更容易被人理解并接受，因此重要的是你的设计思想，而不是UML。常见UML图包括用 例图、类图、序列图、状态图、活动图、组件图和部署图，分别用于不同的建模用途。总 体结构设计主要涉及其中的类图，通过类图将面向对象分析过程划分的数据类及其关联可 视化。 根据面向对象分析与设计方法，总体结构设计工作可按下列流程开展： (1) 剖析问题域（工作流与数据流分析）； (2) 划分对象（面向对象分析）； (3) 定义类（面向对象设计）； (4) 定义类之间的关系（面向对象设计）； (5) 绘制UML类图，小组讨论或专家认定； (6) 发布总体结构，统一设计思想。 2.2.1 工作流与数据流分析 剖析问题域是期望通过问题域的工作流和数据流分析提取数据对象,从而构成数据类 的抽象。工作流和数据流分析可以通过UML活动图理顺工作过程以及工作过程中可能产生 的数据对象，如图2.2（采用 Microsoft Visio 绘制）。 １２ 数 据 处 理 数 据 输 出 质 量 控 制 问 题 交 流 资料汇聚 划定数据集 汇集原始资料 实测资料 数据产品 图件资料 文字资料 核查 [基本完整] [不完整] 沟通 提交原始资料 补充资料 划分数据子集1 分幅整理 资料汇聚阶段 数据子集n 数据子集2 数据子集1 原始资料 核查 [完整] [不完整] 沟通 ... 提交数据集分类资料 补充资料 分类加工 电子介质资料加工 纸介质文档录入 纸介质图件扫描 《成果图件数据库数据模型》 《元数据内容标准》 电子文档 扫描图像 空间要素集 关系数据表 自查与互查 [合格] [不合格] 核查 修改或返工 [原始资料问题] 沟通 [不合格] [合格] 编写元数据文档资料 元数据 核查 [原始资料问题] 沟通 修改 [合格] [不合格] 元数据编写 提交成果图 产品汇总打包 数据集 地图数据产品 数据集 元数据产品 划分数据子集n 划分数据子集2 审查 细化处理阶段 成品提交 [合格] [不合格] 修改 成品提交阶段 数据集成品 拓扑规则 地图模板 图2.2 成果图数据处理与质量控制UML活动图 １３ 图2.2中的UML活动图符号说明如下： 动作 动作：完成某作业的动作 对象 对象：由动作产生或使用的对象 起始：活动开始 终止：活动结束 同步条分叉：一个输入转换为多个并行输出 同步条汇合：多个输入转换为一个输出,输出直到所有输入到达才发生 决策：互斥产生的分支 合并：任何延续输入的合并 控制流：从一个活动状态转换到另一个活动状态 对象流：活动输出或对象输入流 图2.2表示成果图编制过程中的数据处理工作分为三个阶段、五个环节。即资料汇聚， 细化处理和成品提交阶段；其中细化处理阶段又包括分组整理、分类加工及元数据编写环 节，与数据供方的沟通交流和质量控制措施贯穿始终。在资料汇聚阶段，数据处理方必须 明确数据包数据内容，并与数据供方沟通协调，畅通数据渠道，促使双方形成一个有机的 整体，保障工作顺利进行。细化处理阶段，按照数据模型设计要求将数据包分解为各数据 集单元，然后将各数据集单元分解为数据子集单元，再按载体类型对不同载体的数据子集 资料进行分类加工；加工后的数据再以数据子集为单元物理整合，以数据集为单元逻辑组 合，质量检查合格后提交数据产品；最后，编写并提交数据集的元数据。成品提交阶段， 将各数据集的数据与元数据汇总打包成数据集产品，数据质量审查合格后形成数据集成品 或数据包成品提交入库。 工作流和数据流也可以采用结构化软件设计中的工作流与数据流图进行分析，如图2.3、 图2.４。工作流与数据流图是结构化软件设计中的分析工具，虽然现在多采用面向对象以及 UML来进行软件系统的分析设计，但工作流与数据流图因其简易直观仍然有着不可替代的作 用。 １４ 、柱状取样 钻探取样 运抵室内 粒 度 定 名 称 重 装 袋 贴标签 填送样单 剖 样 岩芯A 岩芯B 贴标签 上 架 取分析样 封 存 碎屑矿物 粘土矿物 全岩矿物 、有孔虫 介形虫 地球化学 碳十四测年 、孢粉 藻类 送 样 照 相 分层描述 确定取样位置 ESR测年 古地磁 导航定位 图2.3 柱状和钻孔岩芯采集与室内编录工作流 甲方 剖样 岩芯分层描述 岩芯照片 岩芯 编录 取分 析样 分析 单位岩芯B 岩芯B 送样单 分析样品 粒度分析结果 矿物分析结果 古生物鉴定结果 地球化学分析结果 测年结果 古地磁分析结果 …… 柱状岩芯 钻孔岩芯 外部交互方,表示数据的外部来源和去处，通常是系统之外的人员或组织 数据处理，把流入数据转变为流出数据 流经的数据 图 2.4 柱状和钻孔岩芯样品室内编录与分析数据流 １５ 图 2.3 与图 2.4 表示了柱状与钻孔岩芯在室内的编录与分析过程，首先沿按岩芯管中 轴线将柱状与钻孔岩芯剖分两半，其中的一半进行封装处理作永久保留，另一半用于室内 编录和分析样采集。编录前对岩芯进行照相，然后进行岩芯分层描述。在岩芯描述完成后， 确定各类分析样品的取样位置，采取分析样品。采取的分析样品经定名、称重、装袋、贴 标签、填写送样单，最后送各实验室测试分析。 2.2.2 面向对象分析与设计 把握数据流来笼去脉后，就可以根据数据流进行数据对象的抽象，从中提取数据类（实 际上是将专业领域中的数据分成不同的模块）。类是对象的定义，类的定义内容包括类的名 称、属性（对象特征）和方法（对象可实施的操作）。对数据库数据的基本操作只有SELECT、 UPDATE、INSERT、DELETE有限的几种，具体操作与具体数据实体相关，只能在后期定义。 因此在总体结构设计阶段只需要关注类、类的关系及类的属性，最后的结果是一组没有定 义操作的类图。此外，在总体结构设计阶段，没必要关心类的所有属性，但需要关注类之 间赖以关联的主、外键属性，为后期概念数据模型设计打下良好的基础。不过请注意，在 面向对象设计中，将外键定义为属性是违反设计原则的，常规是通过关系类来定义数据对 象之间的关联，Geodatabase就是如此。但实际上在关系数据库中，关系类最后也是通过关 系模型中的外键来实现的，因此总体结构设计中拟考虑类之间关联的主、外键属性。 面向对象分析与设计中可采用的原则不少， Craig Larma 在其《UML和模式应用》）一 书中有详细的论述，下面的原则我认为对数据总体结构设计来说很有用： (1) 模块化：将问题域数据分解成一组内部内聚、外部松散耦合的模块。内聚指对象 自身职责的相关性和集中度比较高，类似于把相关性和集中度比较高的职责分配 给单独的对象，不让一个对象承担过多不相关的工作。松散耦合指对象之间的依 赖程度比较低，需要时可以帮一下，不需要时相忘于江湖，互相没有太多的牵连， 以此来降低对象之间的依赖程度，减少变化带来的影响，提高系统的伸缩性。在 Geodatabase中的模块化就是将数据分成不同的要素集，要素集内的数据共享同一 空间参照系，要素集内的要素类之间可以具有拓扑关系，但要素集之间的耦合是 松散的。 (2) 信息专家：把某类信息的管理职责分配给拥有该类信息的对象。信息专家原则实 际上是要求一个对象所涉及的信息要单一，不要涉及不相关的信息内容。 １６ (3) 间接性：为了避免两个或多个对象之间的直接耦合，可引入中介对象，使其作为 联系的媒介，通过中介可使数据库内部各数据模块之间的关系达到最小化。这就 是所谓的不要和“陌生人”对象讲话，增加公共的“熟人”对象原则。GIS系统设 计中最常见的是将位置模块作为公共模块，数据模块之间的关联均通过位置模块 实现，使模块之间的关系最小化。 (4) 纯虚构：如果不想违背模块化原则，信息专家原则又不合适时，可以创建新的对 象，该对象不代表问题域的概念，是凭空虚构的。如Geodatabase中的要素集实际 上就是纯虚构对象。 (5) 防止变异：预测可能的变化点或进化点，在变化范围之外创建对象，使其内部变 化不会对其它对象产生不良影响。最常见的是动静隔离的方法，将多变的部分从 相对稳定的部分中隔离出来。 总体结构最终给出的应该是一个有机整体，整体内部自成体系，如：里外分层、内部 分块，外层有入口（数据入口或数据管理单元），有出口（数据对外的信息通道），内部有 不同的模块（类）和模块之间的通道（类之间的联系）。同时，总体结构必须具有足够的抽 象程度，能保持长期稳定，并包容变化。检验总体结构的基本标准是：总体结构来自问题 域数据流的抽象，但必须与问题域的具体应用无关。 图2.5是一个海岛调查信息系统数据库的总体结构UML类图示例；图2.6是该系统中图件 部分的空间数据库总体结构示例，其实也是ArcGIS Geodatabase的总体结构表述。 图2.5与图2.6中的符号说明如下： 整体 部分 类A 类B 聚合 A依赖B 类0..* 类1 类0..1 类1..* 1 0或多 0或1 1或多 多重性类关系 整体 部分 组合1..1 超类 子类 泛化 １７ +AREA_ID[测区号] Location(调查区) +SURVEY_DBK[调查序号] +AREA_ID[测区号] Survey(调查) +METADATA_DBK[元数据序号] +SURVEY_DBK[调查序号] Metadata(元数据) +HISTORY_ENEVT_DBK[事件序号] +SURVEY_DBK[调查序号] HistoryEvent(历史事件) 0..* Diagram: DEMO_CLASS_OVERVIEW Title: 数据模型总体结构UML类图 Modified: 20081104 Author: 戴勤奋 System: 海岛调查信息系统(DEMO 1.0) +CONTENT_DBK[成果序号] +SURVEY_DBK[调查序号] -METADATA_DBK[元数据序号] +ASSET_DBK[评价序号] +COLLECTION_DBK[成果包序号] -DATASET_DBK[数据集序号] Content(成果目录) 0..* +COLLECTION_DBK[成果包序号] +SURVEY_DBK[调查序号] Collection(成果包) 0..* +ASSET_DBK[评价序号] Asset(成果评价) 0..* Document(文档) Map(图件) RawData(原始数据) BaseGeography(基础地理) CoastLine(海岛岸线调查) ForeshoreEvolvement(海岛岸滩地形地貌与冲淤动态调查) CoastalWetland(海岛湿地调查) CoastalReclamation(海岛围填海使用状况调查) InterditalZoneBottomSediment(海岛潮间带底质调查) IslandClimate(海岛气候调查) IslandGeology(海岛地质调查) IslandVegetation(海岛植被调查) InterditalZoneSedimentalChemistry(海岛潮间带沉积化学调查) InterditalZoneBenthos(海岛潮间带底栖生物调查) IslandGeomorphologyAndQuaternaryGeology(海岛地貌与第四纪地质调查) IslandEnvironmentalQuality(海岛环境质量调查) IslandLandUse (海岛土地利用调查) UninhabitedIslandSurvey(无居民海岛调查) 1..* 0..* 0..* RSImage(遥感影像) 1..* +DATASET_DBK[数据集序号] +COLLECTION_DBK[成果包序号] Dataset(数据集) +DATASET_DBK[数据集序号] +COLLECTION_DBK[成果包序号] DatasetIndex(数据集索引) +DATASET_DBK[数据集序号] DatasetData(数据集数据) 1..* 1..11..1 图 2.5 数据库总体结构示例 １８ 1..* SpatialReference(空间参照系) AttributeTable(属性表) 0..* RelationshipClass(关系类) FeatureClass(要素类) 0..* 1..* {Count("FC_Point" +"FC_Line" "FC_Polygon"+ "FC_Annotation" )=1 } FC_Point(点要素类) 0..1 FC_Annotation(注记要素类) FC_Polygon(面要素类) FC_Line(线要素类) 1..* FeatureDataset(要素集) Geodatabase 地理数据库 StyleGallery(样式库) 0..1 0..1 0..1 1..1 RelationshipClass(关系类) 0..* Topology(拓扑规则) +OBJECT_ID[要素序号] +MAP_DBK[图件序号] +GEOCODE[分类代码] Map(图件) +THEME_TYPE[专题类型] MapTemplete(地图模板) Diagram: DEMO_CLASS_GEODATABASE Title: 空间数据库总体结构UML类图 Modified: 20081106 Author: 戴勤奋 System: 海岛调查信息系统(DEMO 1.0) +MAP_DBK[图件序号] +COLLECTION_DBK[成果包序号] +THEME_TYPE[专题类型] MapIndex(图件索引) 1..* 图 2.6 空间数据库总体结构示例 １９ 图中类与类的关系包括聚合/组合、泛化和依赖。 当类之间有整体与部分关系的时候，使用聚合或者组合。聚合是一种相对松散的整体 与部分关系，聚合类不需要对被聚合类负责。图 2.6 中，“要素集”由“要素类”及其“关 系类”聚合而成。 组合是一种强聚合关系，组合类控制着被组合类的生命期，被组合类会随着组合类的 创建而创建，随着组合类的消亡而消亡。图 2.6 中，“要素集”与“空间参照系”之间就是 组合关系，同一个要素集内的要素类享有同一空间参照系，离开空间参照系，空间数据就 失去了地理意义。 依赖是一种弱关联，表示一个类与另一个类的涉及关系，但不是固定关系。例如：自 行车与打气筒，汽车与汽油的关系。图 2.6 中“要素集”与“拓扑规则”之间定义为依赖 关系，表示需要时可以通过拓扑规则来检测地理要素的数据质量，两者之间没有必然联系。 泛化表示子类与父类之间的关系，父类能够派生出具有更多特殊行为的子类，此时父 类即为子类的超类或说子类的泛化，子类是父类的特化。图 2.5 的抽象类（斜体字表示）“数 据集”为一泛化类，“文档”、“图件”、“遥感影像”和“原始数据”都是“数据集”的特化。 经常见到泛化与继承混用，严格来说，两者属于不同的领域不拟混用。泛化和特化属于问 题域，继承属于软件领域。软件领域的继承是使超类的特性适应于子类的软件机制，主要 是为了代码重用。而在问题域是期望对泛化类的研究提取子类的共性，以便数据类的抽象。 图 2.5 的设计意图如下： （1） 数据库数据内外分层，层内分块。外层为数据信息层，包括调查信息模块的“调 查区”（Location）、“调查”（Survey）、“历史事件”（HistoryEvent）、“成果目 录”（Content）、“成果评价”（Asset）和“成果包”（Collection），以及元数据 模块的“元数据”（Metadata），它们负责数据的对外信息服务。内层为数据资 源层，负责具体数据资源（文档、图件、遥感影像及原始数据模块）的存储。 外层与内层之间只有逻辑上的联系，物理上可以是隔离的，这为数据的安全性 提供了保障。 （2） “调查”（Survey）、“成果包”（Collection）、“数据集”（Dataset）类是支撑数 据库的中枢。在一个调查区可能进行多项专业调查，每项专业调查结果会形成 一个成果包，每个成果包中可能包括有多个报告文档、多幅成果图件、以及一 系列实测或收集的原始数据。 ２０ （3） “成果包”（Collection）是由外层进入内层的隘口，每个成果包的拥有者可以 拥有自己数据的管理权。这为实施多方数据管理奠定了基础，如果对成果包对 象施加数据表行级安全策略，进入数据库后，数据供方将只能看到并管理自己 的数据。 （4） “调查”（Survey）是数据信息层的非空间入口，同时“调查区”（Location） 可以作为数据的空间入口。入口意味着它们是数据的出入管理员，数据入库必 须先向它们登记，数据检索也首先从它们开始，对数据的任何操作将在入口处 被跟踪。 （5） “元数据”（Metadata）作为对外信息窗口，调查可以有调查元数据，成果也可 以有成果元数据。 （6） “成果目录”（Content）和“历史事件”（HistoryEvent）由系统自动维护，追踪 数据资源的入库、修改及更新操作。“成果目录”（Content）中可以容纳“成果 评价”（Asset）信息，让用户在第一时间了解数据的质量级别。成果评价可以 由多方专家通过网络评定。 （7） 内层的数据资源由“文档”、“图件”、“遥感影像”及“原始数据”模块管理。 数据集作为数据资源的逻辑组织单元，数据集可以是一个文档、一幅图件、或 同期同类型的实测数据，没有严格的范围界定。数据集实际数据均通过索引表 调用。 图 2.6 其实是 ArcGIS Geodatabase 的总体结构 UML 类图，其包含信息描述如下： (1) 地图通过“图件索引”（MapIndex）提取，“图件”（Map）类负责地理要素的存储， “地图模板”（MapTemplete）负责地理要素的显示。 (2) 一幅图件是 1 到多个要素集数据的专题聚合，及选定样式下各要素类对应图层 的综合表现。 (3) 地图数据由 ESRI 面向对象地理数据库（Geodatabase）统一存储及管理。包括 库级的要素集、属性表与关系类，以及要素集级别的要素类和关系类。 (4) 要素集聚合对象包括不同几何类型的要素类以及与要素类相关的关系类。同一个 空间要素集内的要素类享有同一空间参照系。拓扑规则也在同一数据库的要素 集中进行管理。 (5) 矢量要素类图元类型包括有：点（Point）、线（Line）、面（Polygon）、注记 ２１ （Annotation）四种，一个要素类只能包含一种图元类型。 (6) 属性表存储在地理数据库中通过关系类与要素类关联，实现要素类属性的动态捆 绑。 总体结构设计有关大局， 它是整个数据模型的灵魂，需要思路合理和概念完整，能在 将来为数据库系统的易用性及伸缩性提供保障，因为技术会不断更新，需求也会不断变化， 但数据库是不应该推倒重来的。有效的总体结构模型应该捕获了能满足当前需求的问题域 概念，搭建起实用的概念连接框架，最终确保模型能回答任何合理的问题，譬如: 是否有 利于数据安全保护？是否有利于数据管理？是否有利于公众服务？是否能适应变化？是否 能对后续设计起到指导与约束作用？等等。 2.3 概念数据模型设计 概念数据模型设计的目标是创建问题域对象的概念描述，使用关系模型时，问题域的 概念称作实体，概念的描述就是定义实体以及实体间的联系。概念数据模型通过实体 （Entity）、属性（attribute）、域（domain）和联系来描述。 概念数据模型设计在总体结构框架约束下进行，首先在总体结构框架中选择数据类， 最好从你比较熟悉的、或你认为比较重要的、或具有代表性的数据类入手；然后依据规范 化原则将数据对象分解成可关联的数据实体；在此基础上根据实际需要定义各实体的属性， 同时依照专业领域的业务规则定义属性的域；最后进行模型的测试及优化。概念数据模型 设计工作可以由多人分模块进行，但是必须将总体结构设计思想落实到每一个人，始终维 护总体设计思想的一致性。 概念数据模型设计流程如下： (1) 从总体结构中选取数据模块，确定待设计的数据对象； (2) 分解数据对象，确定数据实体及实体间的关系，绘制总实体关系图（不带属性 ER 图）； 在 Geodatabase 数据库设计中区分对象的定义级别很关键，属性表在库级定义，拓扑在要 素集级定义，要素类、关系类可以在库级也可以在要素集级定义。 ２２ (3) 定义实体的属性及域，绘制带属性的实体关系图，并附数据字典对属性的定义以 及属性的域加以文字补充说明； (4) 模型测试、修改与优化。 概念数据模型设计涉及许多“概念”，我很长时间处于模模糊糊之中，譬如说概念数据 模型的概念两字其含义究竟是什么？实体又是什么？域又是什么？规范化原则到底该贯彻 到何种程度？等等。2.3.1 的一些认识，可能会对设计工作有所帮助。 2.3.1 关于概念数据模型的概念 2.3.1.1 关于概念与实体的含义 关系模型的数学理论基础是集合论，用集合论来表达数据的结构和关系，就必定要求 集合中的数据元素是确定的，互异的，无序的。因此在关系数据库中，数据要求被组织成 规范化的表，确保表中的数据是一组独立的、通过键相关的数据。这种规范化设计要求通 过实体的分解来实现，也就是将实体拆成一个个子实体，用多个子实体来等价替代实体， 最后达到一个实体只能用关系数据库中的一个表来描述。当然，上述分解过程必须在无损 分解原则上进行，即分解后的关系表又能重新组合起来而不丢失任何信息。数据库中的实 体组装通过 SQL 语言实现，从中你也可以理解为什么关系数据库老提 SQL 优化，其原因是 为了提取需要的数据，有时不得不用 SQL 连接一个又一个表，导致计算机时间、空间及运 行效率上的损失，概念数据模型设计的重要性由此可见一斑。有人将关系模型的这种数据 存取方式比作拆车进库，也就是在车进入车库前把轮子、椅子、方向盘等等卸下存入车库， 用车时再把它们组装到一起。照上述分析，规范化程度越高，拆分的子实体就越多，最后 实体往往被分解得支离破碎，与现实世界中的客观对象相去甚远，只有概念上的意义了。 这是我对概念两字的理解，不知道是不是概念数据模型中概念两字的真正由来，但表 明关系数据库概念数据模型设计的研究对象是数据实体（Entity）及其联系，只要在概念上 有明确定义的都可以称作实体，与实体在现实世界中的客观存在性没有关系，因此可简单 地将实体理解为存储数据的对象。 这种数据组织方式，使得关系模型数据结构简单清晰，并有效地消除了冗余，为数据 的一致性与完整性提供了保障。此外，由于实体分解遵循的原则都是建立在数学理论基本 之上，与实际应用没有直接对应关系，使得用户在使用数据时，可以反其道而行之，也就 ２３ 是不用关心数据的具体组织结构，只要拟定数学逻辑条件就可以对数据进行应用操作。由 此，使数据从应用中独立出来，应用需求改变不要求以数据结构变更为代价，数据结构就 能保持稳定状态。 2.3.1.2 关于概念层与物理层 概念层对应问题域，物理层对应数据库系统。数据库设计需要从概念层走到物理层， 在概念层创建概念数据模型，然后在物理层构建数据库模式。概念数据模型是概念层的， 概念层的研究对象是实体及其联系，工作重点是实体的规范化分解。数据库模式是物理层 的，物理层的研究对象是表及其约束与操作，除概念数据模型到具体数据库的映射外，物 理层的工作重点是保障数据在数据库中的完整性与安全性，将数据库控制为一个安全的整 体。 区分概念层与物理层十分重要，因为实体夹在问题域与关系数据库之间，如果遇上一 个经验丰富的设计人员，实体能很好地概括问题域的概念，形成相互牵制的概念结构，并 清晰地传达给关系数据库；反之，实体可能过早地变成了物理层的表，概念数据模型设计 成了表结构设计，由于缺乏概念上的抽象与组织，表有可能像一盘散沙分布在关系数据库 中，由此埋下了不稳定隐患。因此，区分概念层与物理层十分重要，在概念层设计时将工 作重心放在实体的分解与联系上，在物理层设计时将工作重心放在数据的完整性与安全性 上，将会使设计工作变得单纯点，不至于复杂化。 2.3.1.3 关于范式 概念数据模型设计过程是一个实体的分解过程，也叫规范化过程，规范化实质是概念 的单一化，根据关系结构原则将数据对象分解为概念单一的实体，以消除存储异常，减小 实体是概念单一的数据存储对象。 区分概念层与物理层，使设计工作简单化。 ２４ 数据冗余，保持数据库的完整性，也就是数据的逻辑一致性。规范化增强了数据库的可维 护性，但在数据检索时可能需要用复杂的多表联结才能实现，这有可能造成数据库执行速 度及网络传输上的负担，导致数据库性能的下降。鉴于目前数据库的网络应用环境及对数 据库执行速度的要求，设计时需要在规范化和系统性能之间进行必要的权衡，权衡各方面 的因素后选择最优设计方案。 实体分解原则称为范式（normal form），范式用来保障存储在数据库中数据的完整性， 注意是完整性不是正确性，范式只能保证数据的整体一致性，也就是表示数据可能是正确 的，或至少看上去是正确的。范式相关内容在教课书上都可以找到，其中第一范式要求实 体中的所有属性都是不可分割的基本单元，即实体中的所有属性不能有多个值或者不能有 重复的属性，否则就可能需要实体的进一步分解；第二范式要求非键列取决于全部的键， 以消去非键属性对键的部分函数依赖；第三范式要求除了键不依赖其它，以消去非键属性 对键的传递函数依赖。还有进一步的第四、第五等范式，用于处理特殊的关系，不常用。 总的来说范式可概括为流传的顺口溜：“The key, the whole key, and nothing but the key, so help me Codd.”（“键、全部键、没有别的除了键，Codd 帮帮我”，注：E.F.Codd 为关 系理论的开创者，他在 1970 年发表的著名论文“A Relational Model of Data for Large Shared Data Bank”开创了对数据库的关系方法和关系规范化理论的研究，他本人因此荣获 1981 年 国际计算机协会图灵奖。） 在实际设计工作中不设计带重复属性的实体，不设计没有主键的实体，尽量做到“一 事一地”使实体概念单一化。这些能做到，范式也基本遵循了。 需要切记的是，范式并不是创建有效数据模型的灵丹妙药，彻底规范化的模型可能因 其慢速笨拙而无法成为有效模型。因此设计时拟根据实际需要权衡利弊，采用恰当的范式 等级，保证数据库系统的灵活性。不过在不失灵活性的同时，拟尽量遵循规范化原则，使 模型更有可能成为有效模型。 采用恰当的范式等级，保证数据库系统的灵活性，在不失灵活性的同时，尽量遵循规范化 原则，使模型更有可能成为有效模型。 ２５ 2.3.1.4 关于属性定义 属性是描述数据实体特征的数据项，属性设计没有固定的规则，满足实际需要是首要 的设计策略，非键属性的设计拟尽量与实际数据内容保持一致，这样有利于今后的数据加 工与处理，也能提高设计结果的可理解性。“从结果出发，不要将设计做得比它的实际需要 复杂”（Rebecca M.Riordan 《Designing Effective Database Systems》）。 此外，除了用于外部联系的外键，实体内的所有属性应只涉及实体本身的内容，让实 体成为所涉及内容的信息专家，尽力排除与实体内容不在同一范畴的属性项。 2.3.1.5 关于属性的域 域（Domain）是属性可能包含的所有有效值的集合，域不容易直观表示，因此常常与 数据类型混淆，有时甚至忽略了域的存在，定义属性域变成定义属性的数据类型。其实数 据类型和域是两个不同的概念，数据类型是物理上的概念，通过数据库引擎定义和实现， 而域是逻辑上的概念。域的概念范围比数据类型窄，例如一个人的年龄，其数据类型是整 型，而域应该表示为 0～120 的整型数。由此，可能有人会认为域是数据类型和有效性规则 的组合，差不多，但严格来说也不是，因为有效性规则是数据完整性的一部分，而域是一 设计元素，域可以在数据库系统内一次定义多处引用，可避免重复设计，减少出错几率。 因此，域具有值的派生作用，它代表某个值的集合，属性可以从中派生它的可取值，定义 在同一域上的属性可以在逻辑上进行比较。 域的设计分三个步骤： （１） 确定域的数据类型； （２） 限制取值范围（有效规则、可取值列表、非空等）； 尽力排除与实体内容不在同一范畴的属性项，让实体成为所涉及内容的信息专家。 数据类型和域是两个不同的概念，数据类型是物理上的概念，通过数据库引擎定义和实现， 而域是逻辑上的概念，域可以在数据库系统内一次定义多处引用。 ２６ （３） 指定域的格式（假如有必要的话，如用 YYYYMMDD 表示日期，一旦指定，所有日 期都可以采用日期域的格式，不需要再重复定义）。 在 “限制取值范围”阶段，可以指定有效规则，如：必须是正整数，也可以列举域的 所有可取值，将该域作为一个实体包含在数据模型中，如 Oracle 的 REF 约束，这样做不仅 能简化数据的输入，也增强了系统的扩展性，因为可取值是可以添加的。必要的话，还需 要定义度量单位及数据精度。 域的定义还需要说明定义在域上的属性值是否可以为空值或者是零长度的字符串，这 部分定义内容不拟忽视。 Geodatabase 中引入了 Domain 设计元素，不过我觉得与真正意义上的域有一定差异， Geodatabase 中的 Domain 主要是用于限定属性的有效取值范围和可取值列表。Geodatabase 中的 Domain 在库级别上定义，在 ArcCatalog 中选择“数据库→右键→属性”，然后选择 Domain 页就可定义属性的有效取值范围（Range）或可取值列表（Coded Value），见图 2.7。 在 Geodatabase 中你能充分体会到域（Domain）是一设计元素，因为一旦在库中定义后可以 在任何要素类和属性表中使用。 图 2.7 ArcCatalog 中 Domain 页面 ２７ 2.3.1.6 关于联系定义 对问题域中的实体有一个大致的描述后，接下来的任务就是建立这些实体间的联系。 联系的定义包括：确定联系参与者的可选性、定义联系的基数（一个实体的实例能够被另 一个实体的实例所引用的最大数目称为一个联系的基数，联系的基数有三种类型：一对一， 一对多和多对多）、以及联系的属性与约束。联系本身也是实体，因此它可以有属性。 根据我自己在工作中的体会，联系可以分为两种，强关系与弱关系。强关系类似于面 向对象中的整体与部分关系——聚合或组合，连接后的实体在问题域中是一个整体(或称为 复合实体)，这种关系是“HAS A”或“ IS A”关系，例如我是青岛海地所的一名员工（IS A）， 反过来青岛海地所有我这样的一名员工（HAS A），我与海地所是一对多的关系，我要对海 地所负责，海地所也要对所内的任何员工负责，相互是有内在制约的。弱关系类似于面向 对象分析中的依赖关系，需要时可以用一下（USE）或被用一下（USED FOR），但互相之间 没有内在制约，例如我用出租车去某地办事（USE）, 出租车被用来到某地办事（USED FOR）， 出租车只是可能涉及的实体，没有出租车也无妨。 之所以将强关系和弱关系分开，是因为涉及在物理层的参照完整性定义或复合实体的 实现。对于强关系，你可以在 Oracle 中通过嵌套表（nested table，嵌套表作为数据表中 的列，嵌套表数据本身在外部的存储表中存储，存储表的大小没有限制，但你不能直接操 纵存储表）、可变数组（varry，有限有序集合作为数据表中的列，数据在数据表内部存储， 数组大小是预定的，存进去时数据是什么顺序，出来时还是什么顺序）等集合对象类型来 定义复合实体，也可以用外键来维护实体的参照完整性。 关系数据库中实体之间的联系是通过外键实现的，在外键定义时就会涉及实体之间的 参照完整性（参见 2.4.2 相关内容）。强关系下的实体需要强制实施参照完整性，参照完整 性要求子表中的一列或一组列中的值必须与父表中的一列或一组列中的值相匹配，只要依 赖于某主键或唯一键的外键存在，父表中包含该主键或唯一键的行就不能删除或改变；只 要父表中不存在某外键和唯一值键，子表中就不能插入该外键和唯一值键的数据行。而弱 关系可以不遵循参照完整性，Geodatabase 中的简单关系就是这类关系，例如：航道上可 以有一个或多个相关联的航标灯，航道上也可以没有航标灯，删除航标灯不能就删除航道。 而 Geodatabase 中的复合关系则要求强制实施参照完整性规则，例如电线杆与变压器，当 电线杆被删除变压器也就没有存在的意义了。 ２８ 2.3.1.7 关于主键设计 主键在物理层有两个用途，其一用于唯一地标识一行，其二作为被外键引用的对象， 实质上是用来保证实体自身的完整性以及实体之间的参照完整性。主键不仅使实体被唯一 确定，也是实体与实体的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着 决定性的影响，因此在概念模型设计阶段必须予以重视，因为一旦数据库投入运行，就很 难对这些键进行修改了。 主键该是有领域意义还是无领域意义？这是设计主键时经常会面临的选择。一般建议 选择无领域意义的单一字段人造码，人造码通常由系统自动生成，例如 Geodatabase 中系 统自动生成的 ObjectID。有领域意义的主键虽然定义方便，但访问可能不方便。一方面， 假如实体从属表比较多的话，越靠后的从属表将会包含越多列的主键，造成数据连接和筛 选效率的降低；另一方面，在商业领域，有领域意义的主键有可能给人为破坏数据库提供 机会。但系统自动生成的主键也有它的问题，例如无法防止领域冲突、给用户故意添加无 意义记录提供了条件，除非有其它手段予以保证。此外，系统自动生成的主键在记录创建 以后才能得到，无法预先获取，这样给复合型或嵌套型从属实体的外键值获取带来困难。 设置按一定编码原则的主键，是解决键值无法预先获取的手段，但如果涉及大量此类主键 值的逐行集中输入，这样的主键就会成为负担，我曾经录入过这样的数据表，数千条记录， 每条记录都要求按规定输入编号，这是件令人痛苦不堪的工作，这样的数据库是走不了多 远的，当然如果这些编号是在原始数据生产时就附带，或输入的数据量不大也不是不可以。 因此，具体怎么做还要看实际情况而定。 2.3.1.8 关于外键设计 关系数据库支持一对一，一对多和多对多的实体间联系，这些联系通过外键来维护， 联系分为强关系（复合关系）和弱关系（简单关系）。 一般建议选择无领域意义的单一字段人造码作为主键，具体怎么做还要视实际情况而定。 ２９ 用于实现实体的连接重现，以及实施物理层的参照完整性。外键设计应符合总体结构设计 要求，维护总体结构的设计思想。此外，外键设计时最好通过外键后缀名将强关系外键与 弱关系外键区分开。例如图 2.9，强关系外键用 CMP 后缀表示，弱关系外键用 ASS 后缀表示。 主外键的合理命名便于今后数据库的维护，见其名便知其意。 2.3.1.9 关于可取值列表 当属性的列数无法确定时，可以将该属性内容转移到域的可取值列表中，相当于把横 表纵化，将动态部分转移到域的可取值列表中，以保持实体基本表的稳定性。在 Oracle 中 可以通过 REF 约束添加对外部表或对象的引用（参见 2.4.3.1）。将域作为一个实体对象包含 在数据模型中是动静隔离的有效手段，因为域的可取值列表可以根据实际需要不断扩展。 可取值列表也称代码表，定义为一个构造型《CodeList》，用于表示一个可能值的长表， 代码表是可扩展的。如果代码表的元素个数及内容能完全确定，此时代码表就成为枚举 《Enumeration》，枚举是确切值的列表。 2.3.2 实体关系图与数据字典 概念数据模型文档一般包括两部分，实体关系图（ER图）及数据字典，数据字典以字 典形式给出数据实体与属性的文字定义，以避免多义理解。 实体关系图（ER 图）绘制一般分两步走，第一步只考虑实体以及它们之间的联系，第 二步考虑给定实体的属性，不同时考虑两者是为了让设计工作变得单纯一点。实体关系图 的表示方法很多，当然只要能清楚表达设计意图就好。 图 2.8 为只考虑实体及其联系的实体关系图示例，图 2.9 为包含属性的实体关系图。 外键设计应符合总体结构设计要求，维护总体结构的设计思想。 横表纵化是动静隔离的有效手段。 ３０ 海岛调查数据总实体关系图 DIAS_ER_OVERVIEW 测区号 调查信息(SUV) 调查 SURVEY 历史事件 SUV_HISTORY_EVENT 调查序号 成果目录 SUV_CONTENT 成果评价 SUV_ASSET 评价序号 调查区 LOCA 空间位置(LOC) 文档(DOC) Diagram: DEMO_ER_OVERVIEW Title: 数据模型总实体关系图 Modified: 20081104 Author: 戴勤奋 System: 海岛调查信息系统(DEMO 1.0) 文档索引 DOC_INDEX 图件索引 MAP_INDEX 数据集 DATASET 图件(MAP) 原始数据(DAT) 图件 MAP 图件序号 成果包序号 元数据 METADATA 元数据(MD) 元数据序号 影像索引 RSIMG_INDEX 影像 RSIMG 影像(RSI) 成果包 COLLECTION 成果包序号 调查序号 调查序号 文档 DOCUMENT 文档序号 影像序号 数据集序号 数 据 信 息 层 数 据 资 源 层 原始数据 RAWDATA 图2.8 实体关系图示例 ３１ ⊥ LOCA_UK1 ⊥ ＊ A AREA_ID [测区号] ＊ A AREA_NM [测区名] ＊ N W_LON_DEG [西端经度(度)] ＊ N E_LON_DEG [东端经度(度)] ＊ N S_LAT_DEG [南端纬度(度)] ＊ N N_LAT_DEG [北端纬度(度)] LOCA（调查区） SUV_HISTORY_EVENT_ASS1 SURVEY_REF2 ＃ REF_SURVEY_KIND_PK ＃ ＊ A SURVEY_KIND_CD [调查类别] ＊ A DESCRIPTION [说明] REF_SURVEY_KIND（调查类别） ＃ SURVEY_PK ﹄ SURVEY_ASS1 ﹄ SURVEY_REF1 ﹄ SURVEY_REF2 ﹄ SURVEY_REF3 ﹄ SURVEY_REF4 ＃ ＊ N SURVEY_DBK [调查序号] ＊ A SURVEY_NM [调查名称] ○ A PREJECT_ID [项目编号] ○ A PREJECT_NM [项目名称] ＊ A ﹄ AREA_ID [测区号] ○ A ﹄ MAP_SHEET_CD [图幅号] ＊ A ﹄ SURVEY_KIND_CD [调查类别] ＊ A ﹄ SURVEY_TYPE_CD [调查专题] ＊ A ﹄ CONFIDENTIALITY_CD [密级] ○ N SURVEY_DIMENSION [调查面积(KM2)] ○ A OWNER_NM [调查单位] ○ D SURVEY_DATE [调查起始日期] ○ D COMPLETION_DATE [调查完成日期] ○ D LAST_ADDITION_DATE [最近添加日期] ○ D MODIFICATION_DATE [修改日期] ＊ D CREATION_DATE [创建日期] SURVEY（调查） SURVEY_ASS1 Diagram: DEMO_ER_SUV Title: 调查信息模块实体关系图 Modified: 20081104 Author: 戴勤奋 System: 海岛调查信息系统(DEMO 1.0) SURVEY_REF3 ＃ REF_SURVEY_TYPE_PK ＃ ＊ A SURVEY_TYPE_CD [调查专题] ＊ A DESCRIPTION [说明] REF_SURVEY_TYPE（调查专题） ＃ REF_SUV_CONFIDENTIALITY_PK ＃ ＊ A CONFIDENTIALITY_CD [密级] ＊ A DESCRIPTION [说明] REF_SUV_CONFIDENTIALITY（密级） SURVEY_REF4 SURVEY_REF1 ＃ REF_SUV_MAP_SHEET_PK ＃ ＊ A MAP_SHEET_CD [图幅号] ＊ A DESCRIPTION [说明] REF_SUV_MAP_SHEET（图幅号） ＃ SUV_CONTENT_PK ﹄ SUV_CONTENT_CMP1 ﹄ SUV_CONTENT_ASS1 ﹄ SUV_CONTENT_ASS2 ﹄ SUV_CONTENT_REF1 ﹄ SUV_CONTENT_ASS3 ﹄ SUV_CONTENT_CMP2 ＃ ＊ N CONTENT_DBK [成果序号] ＊ N ﹄ SURVEY_DBK [调查序号] ○ N ﹄ METADATA_DBK [元数据序号] ○ N ﹄ ASSET_DBK [评价序号] ＊ A TITLE [成果名] ○ A ﹄ DATA_KIND_CD [数据类别] ○ A MIME_TYPE [媒体类型] ○ A ONLINE_REFERENCE [在线引用] ○ N ﹄ COLLECTION_DBK [成果包序号] ○ A ﹄ DATASET_DBK [数据集序号] SUV_CONTENT（成果目录） SUV_CONTENT_CMP1 SUV_CONTENT_ASS2 ＃ SUV_HISTORY_EVENT_PK ﹄ SUV_HISTORY_EVENT_ASS1 ＃ ＊ N HISTORY_EVENT_DBK [事件序号] ＊ N ﹄ SURVEY_DBK [调查序号] ＊ A EVENT_TYPE [事件类型] ＊ D EVENT_DATE [事件日期] ○ A REMARK [备注] ○ A VISIBLE_ON_MAP [图上可见] SUV_HISTORY_EVENT（历史事件） ＃ SUV_COLLECTION_PK ﹄ SUV_COLLECTION_CMP1 ＃ ＊ N COLLECTION_DBK [成果包序号] ＊ N ﹄ SURVEY_DBK [调查序号] ＊ A TITLE [成果包名] ○ A ENTERED_BY_NM [提交人] ○ D SUBMISSION_DATE [提交日期] ○ D ARCHIVING_DATE [归档日期] ＊ D CREATION_DATE [创建日期] SUV_COLLECTION（成果包） SUV_CONTENT_ASS3 SUV_COLLECTION_CMP1 SUV_CONTENT_REF1 ＃ SUV_ASSET_PK ＃ ＊ N ASSET_DBK [评价序号] ＊ A RANK_LABEL [等级标签] ○ A REMARK [评价] ○ A SENDER_NM [评价人] ○ D DELIVERY_DATE [送交日期] ○ D MODIFICATION_DATE [修改日期] ＊ D CREATION_DATE [创建日期] SUV_ASSET（成果评价） ＃ REF_SUV_DATA_KIND_PK ＃ ＊ A DATA_KIND_CD [数据类别] ＊ A DESCRIPTION [说明] REF_SUV_DATA_KIND（数据类别） 图2.9 包含属性的实体关系图示例 ３２ 图 2.8 展示了数据里外分层、层内分块的格局，实体联系的基数与可选性分别用鸟爪 形符号和空圈表示，符号可以按需要组合，体现 0 或 1、1、0 或多、1 或多及多的实体联系。 0 或 多 0 或 1 多 1 或 多 1 图 2.10 为图 2.9 作了示意说明。 AD_MF_REF1 ＃ REF_AD_MF_GROUP_PK ＃ ＊ A MF_GROUP_CD [化石类别] ＊ A DESCRIPTION [名称] REF_AD_MF_GROUP（化石类别） ＃ AD_MF_PK ⊥1 AD_MF_UK1 ﹄ AD_MF_ASS1 ﹄ AD_MF_REF1 # ＊ A SUBSAMPLE_ID [送样号] ⊥1 ＊ A ﹄ BORHOLE_ID [孔号] ⊥1 ＊ N SSAM_TOP_DEP [取样顶深(cm)] ＊ N SSAM_BOT_DEP [取样底深(cm)] ＊ A ﹄ MF_GROUP_CD [化石类别] ○ N TOTAL_NR [丰度(枚)] ○ N SPECIES [简单分异度(种)] ○ N HSPECIES [复合分异度] AD_MF（微古鉴定统计） 属性代码 & 中文名 数据类型 A—字符型 N—数字型 D—日期型 B—大对象 实体名 引用表 实体类型 约束 ＃—主键 ⊥—唯一 ＊ —非空 ○ —允许空 ﹄ —外键 键 图 2.10 实体与属性表示示意 ３３ 图 2.9 中，实体用矩形框表示，分上中下三部分。上部为实体类型和实体名，实体类 型有属性表、点、线、面四种，实体名用模块名加表名表示。 中部列出实体的属性，属性分左右两区，左区为 4 列约束，表示主键及唯一键、非空、 数据类型和外键。其中数据类型只是大类的区分，不涉及具体数据库系统的数据类型及数 据精度，概念数据模型设计的工作重点应放在实体概念上，而不是实体的物理实现。右区 为属性代码及其中文名，后缀为 CD 的表示带代码表的属性，属性中文名可以在数据视图中 利用。如果键为复合键，也就是由多属性组成的键，需要注意属性的上下排列顺序。 下部为定义的键，可以是主键(PK)、唯一键(UK)和外键(CMP 或 ASS 或 REF)，图 2.9 中 带 ASS 后缀的外键为无完整性约束的外键，带 CMP 后缀的为带完整性约束的外键，后缀为 REF 的表示具引用约束的外键。多列复合的唯一键及外键用带上标的数字予以区分。 实体与属性的详细说明在数据字典中给出。域的有效值范围和数据格式部分设计内容 不容易简单表示，因此均在数据字典中加以说明。 下表为图 2.10 中 AD_MF 的数据字典示例。 ３４ 约 束 序 号 中文名 属性名 说 明 主键 唯一 非空 外键 数 据 类 型 域 1 微古鉴定统计 AD_MF 微体古生物鉴定结果统计，单 位干样重量必须在元数据中加 以说明 1.1-1.8 1.1 送样号 SUBSAMPLE_ID 送样的原始编号 √ AD_MF_PK A Free text 1.2 孔号 BORHOLE_ID 外业给定的钻孔编号 √1 AD_MF_UK1 √ √ AD_MF_ASS1 A Free text 1.3 取样顶深 SSAM_TOP_DEP 取样顶深，从孔顶部起算 √1 AD_MF_UK1 √ N 正整数，如：68， 单位：厘米（cm） 1.4 取样底深 SSAM_BOT_DEP 取样底深，从孔顶部起算 √ N 正整数，如：70， 单位：厘米（cm） 1.5 化石类别 MF_GROUP_CD 鉴定的微体古生物类别 √ √ AD_MF_REF1 A MF_GROUP_CD 《CodeList》（B.1） 1.6 丰度 TOTAL_NR 计算列，单位重量干样内所鉴 定化石群的化石总个体数 N 正整数，如：20， 以枚计，介形虫以壳瓣计 1.7 简单分异度 SPECIES 计算列，样品中所鉴定化石群 的化石种数 N 正整数，如：3 1.8 复合分异度 HSPECIES 计算列，复合分异度计算公式 如下： H(S) = -ΣPilnPi H(S)：复合分异度 Pi：第 i 种个数占全群的比例 N 正实数，如：1.04 ３５ 对于 REF 型的属性域，应采用单独的数据字典列出可取值，见下表： 序 号 代 码 名 称 说 明 B.1 MF_GROUP_CD 化石类别 分析鉴定的微体古生物类别 1 FO 有孔虫 foraminifers 2 OS 介形虫 ostracods 3 RO 放射虫 radiolarians 4 NF 超微化石 nannofossils 5 DI 硅藻 diatoms 2.3.3 Geodatabase 数据库数据模型设计 ArcGIS Geodatabase数据库数据模型用面向对象术语来描述，此时问题域的概念定义 为要素集、要素类、属性表与关系类，其中要素集、要素类涉及空间数据对象，它们与关 系数据库中的实体是有区别的，但属性表对象仍是传统意义上的实体级对象，Geodatabase 中的属性表通过关系类实现要素类属性的动态捆绑。Geodatabase数据框架下的数据模型设 计流程如下： （1）确定要素集； （2）确定各要素集的要素类，以及要素类之间的关系； （3）要素类要素分类编码（最好能预先制定相关标准）； （4）定义要素类要素属性； （5）定义属性表以及属性表与要素类之间的关系； （6）拟定要素类自身或要素类间的拓扑规则。 2.3.3.1 Geodatabase 框架结构元素 Geodatabase框架结构涉及一系列空间数据的逻辑结构元素，这些元素的概念弄清楚 了，Geodatabase数据模型也就把握住了，从这方面看它有点Oracle的风格。 在Geodatabase框架结构下，地图通过存储层与表现层的两组数据对象构建（见图2.1）， 数据以Geodatabase的要素类与要素集组织并存储管理，最终通过图层及地图样式显示。存 储层的逻辑结构元素包括要素（Feature）、要素类（Feature Class）、要素集（Feature Dataset）、属性表（Table）和关系类（Relationship Class）。 （１） 要素：要素是问题域空间对象的抽象，要素定义了空间对象的空间位置、形态 ３６ 及相应的属性信息。 （２） 要素类：Geodatabase的要素存储在要素类中。要素类是具有共同特征和关系的 同类要素的集合，在同一个要素类中，空间要素的几何类型必须一致。要素类 的几何类型包括点（point）、线（line）、面（polygon）与注记（annotation）， 其中注记是用来标识其它要素的要素类。Geodatabase支持要素类之间的逻辑完 整性，体现为对几何网络（geometric network）、拓扑规则和关系类等的支持。 （３） 要素集：要素集是共享同一空间参照系的要素类的集合或专题组合（空间参照 系是对空间数据的地理范围和投影的描述）。不同几何类型的要素类以及与要素 类相关的关系类可以存储在同一个要素集中，由于享有同一空间参照系，要 素集内的要素类之间可以具有拓扑关系。反过来说，拓扑关系只能在要素集级 别上定义。 （４） 属性表：在Geodatabase中属性表在库级定义，属性数据通过关系类与要素类关 联，用于地理要素属性的动态捆绑。 （５） 关系类：关系类为地理数据库中两个对象之间的关联或链接。关系类可以存 在于空间对象之间、非空间对象之间、以及空间对象和非空间对象之间。 Geodatabase中的对象间关系通过主键或属性值来维护，支持一对一、一对多和 多对多的简单关系与复合关系。简单关系是不要求参照完整性的关系，一个对 象的生存状态不影响另一个对象的生存状态，对象A从数据库中被删除，与之关 联的对象B仍然存在。复合关系强制实施参照完整性，一个对象的生命周期控制 着与它关联的另一个对象生命周期。 2.3.3.2 划分要素集和要素类 要素集与要素类根据专题需要划分。识别需要表达的专题内容，将具有共同特征以及 相同几何类型的要素划分到同一要素类中，然后将具有拓扑关系以及需要在同一坐标系下 表达的要素类划分到同一个要素集下，更简单地说，在图上需要放在同一个数据框架 （DataFrame）下的要素类应划分到同一个要素集下。图2.11 是一个基础地理要素集下的 要素类划分示例： ３７ 0..1 HYDL (水系线) HYDA (水系面) TERL (地貌线) HYDP (水系点) TERA (地貌面) 0..1 定位基础 (C) CPTL (坐标网) 1..1 居民地 (R) LRDL (公路) RESA (居民区) 0 ..1 0. .1 LRRL (铁路) RESP (居民点) 境界与政区 (B) BOUL (境界线) 0 ..1 0 ..1 BOUA (境界面) PIPP 管线点 PIPL 管线 0 . . 1 0 ..1 0 . . 1 GeographicFeatureClass(分类基础地理要素) 交通 (L) 0 . . 1 管线 (P) 0..1 AALL (注记线) 0..1 TBYL (海底等深线) 0 . . 1 0..1 TBYP (海底水深点) 地形地貌 (T) 注记 (A) 0 . . 1 水系 (H) 0 . . 1 TERP (地貌点) 0 . . 1 图2.11 要素类划分示例 ３８ 下表是地理底图的要素分类表示例（表中“√”表示必选的基础地理要素类）： 要素 大类 要素类 要素 类名 几何 类型 主要内容 必选 要素 测量控制点 CPTP 点 测量控制点 定位基础 （C） 坐标网 CPTL 线 图廓线、坐标网、南北回归线等 √ 水系（面） HYDA 面 湖泊、水库、双线河流、河中岛、 湖中岛、沙洲、沼泽 √ 水系（线） HYDL 线 单线河流、沟渠等 √ 水系 （H） 水系（点） HYDP 点 泉、井等 居民地（面） RESA 面 街区、高层建筑区、空地 居民地（线） RESL 线 面状居民地范围线 居民地（点） RESP 点 首都、城镇 √ 居民设施（面） RFCA 面 工矿、农业、公共服务区 居民设施（线） RFCL 线 工矿、城墙、垣栅 居民地 （R） 居民设施（点） RFCP 点 工矿、农业、公共服务、名胜古 迹、宗教设施、科学观测站等 铁路 LRRL 线 标准轨铁路、窄轨铁路、地铁、 轻轨 公路 LRDL 线 国道、省道、县道、乡道、专用 公路、其它公路、街道、乡村道 路 交通附属设施（线） LFCL 线 车行桥、人行桥、隧道、码头、 渡口 交通 （L） 交通附属设施（点） LFCP 点 车站、公路标志、助航标志、机 场 管线（线） PIPL 线 输电线、通信线、油气水输送主 管道 管线 （P） 管线（点） PIPP 点 变电站 境界（面） BOUA 面 陆域、岛屿、各级行政区 √ 境界（线） BOUL 线 海岸线、各级境界线、珊瑚礁边 线、暗沙边线、浅滩边线 √ 境界与政区 （B） 境界（点） BOUP 点 界桩、碑、礁石 ３９ 要素 大类 要素类 要素 类名 几何 类型 主要内容 必选 要素 地貌与土质（面） TERA 面 沙漠等 √ 陆地地貌（线） TERL 线 雪线、陆冰界、海洋冰界等 √ 陆地地貌（点） TERP 点 山峰、山口、火山等 √ 海底地形（线） TBYL 线 等深线 √ 地形地貌 （T） 海底地形（点） TBYP 点 水深点 植被（面） VEGA 面 耕地、园地、林地、草地、城市 绿地等 植被（线） VEGL 线 防火带、行树等 植被 （V） 植被（点） VEGP 点 零星树木、独立树等 注记 （A） 注记（线） AALL 线 海洋、海峡、海湾、河口、半岛、 山脉、沙漠、盆地等无实体对应 的地理名称沿走向注记线 √ 2.3.3.3 要素分类编码 要素分类编码将要素类所可能涵盖的要素类型规范化，用于同一要素类中要素的进一 步分类识别与显示。 信息分类编码其实包括两部分工作，首先是分类，分类是根据数据的属性或特征，按 一定的原则和方法对其进行区分和归类，并建立起一定的分类体系和排列顺序的过程。其 次是编码，编码是在分类的基础上，将数据赋予具有一定规律、易于计算机和人识别与处 理的符号，并形成对应的代码表的过程。 信息分类编码是标准化的一个领域，分类编码方法很多，常见的分类代码包括有含义 和无含义两种。有含义代码又可分为缩写码、层次码、并置码和组合码，无含义代码包括 顺序码和无序码。 （１） 缩写码是按一定缩写规则而生成的码，如世界各国名称代码，中国为 CN，美 国为 US 等。 （２） 层次码在地理信息编码中用得较多，它是以编码对象中的层级分类为基础， 逐级展开，一般为 4 层，大类、中类、小类、子类。我国基础地理要素分类 ４０ 编码国家标准 GB/T 13923-2006，就是采用层级分类法，六位十进制数字 码用来表示按数字顺序排列的大类、中类、小类和子类码。具体代码结 构如下： × × ×× ×× 大类 中类 小类 子类 下表是部分海洋要素的编码示例，分类编码允许扩展，如带（E）后缀的要素： 要素名称 分类代码 几何特征 要素类 说 明 海洋要素 海岸线 250200 线 BOUL 平均大潮高潮时水 陆分界线 干出线 250300 线 HYDL 0 米等深线 干出滩 250400 范围线构面 HYDA 海岸线与干出线之 间的潮侵地带,高 潮时淹没,低潮时 露出 礁石 250600 线 BOUL 水下孤立突出的岩 石 明礁 250601 点 BOUP 平均大潮高潮面时 露出的孤立岩石 暗礁 250602 点 BOUP 深度基准面以下的 孤立岩石 干出礁 250603 点 BOUP 平均大潮高潮面以 下，深度基准面以 上的孤立岩石 适淹礁 250604 点 BOUP 深度基准面时被淹 没的岩石 浅滩、暗沙（E） 250672 线 BOUL 暗沙是由沙和珊瑚 碎屑堆积体，略高 于高潮线或与高潮 线持平 ４１ （３） 并置码是由多个代码段组成的复合码，代码段相互独立，之间没有依赖关系。 如地图名按“分类代号 + 图幅号 + 比例尺”编码，如用 BSEUROPE5M 表示欧 洲 1:500 万地理底图，其中地理底图代号为“BS”，“EUROPE”表示欧洲幅，“5M” 表示 1:500 万。 （４） 组合码也是由多个代码段组成的复合码，但是代码段之间具有依赖关系。身 份证号码采用的就是组合编码。 （５） 顺序码是采用阿拉伯数字或拉丁字母的顺序编码，如 001、002、003 ……， 或 AAA、AAB、AAC …… 。 （６） 无序码一般由机器自动生成，可以作为复合代码的组成部分。 实际采用哪种编码方式得看专业要素特征而定，编码一般原则是： （１） 应尽可能采用已有的分类编码标准，如我国基础地理要素分类编码国家标准 GB/T 13923-2006。不是绝对需要，不要设计新的代码。 （２） 如无特殊要求，有含义代码是首选，因为使用比较方便，也容易记忆。 （３） 代码值尽可能由最少的字符组成，以节省存储并减少数据传输负荷。 （４） 为了便于代码人工操作，对较长的代码可规定存储格式和表述格式，如存储 格式为 XXXXXXXX，表述格式可以是 XXXX-XX-XX，将存储和表述分开。 （５） 为代码集合扩展提供支持。 分类编码确定后可作为 Domain 用于要素分类代码属性域的定义（见图 2.7）， 同时， 可以通过 ArcMAP 下的 Tools→Styles→Style Manager 可为每一类地图要素定义其显示样 式，为地图模板定制奠定基础，如图 2.12。 保证要素分类代码属性列非空，是对空间要素属性设计的最基本要求。分类代码项空 缺意味着该地图要素就无法在图上分类显示，因为一般情况下，分类代码其实也用作显示 代码。 保证要素分类代码属性列非空，是对空间要素属性设计的最基本要求。 ４２ 图 2.12 ArcMap 中定义要素显示样式 ４３ 2.3.3.4 关于拓扑 GIS 中拓扑是用来描述要素间或要素类间几何关系的规则，使得地理数据库能更真实合 理地模拟现实中的地理要素，同时也是数据质量控制的手段，保证地理要素的几何完整性。 过去拓扑是作为一种空间数据结构融合到数据中的，随着面向对象 GIS 的发展， 拓扑从数据结构中独立出来，作为要素行为和规则来实现。ARCGIS 中的拓扑规则在同 一数据库的要素集中进行管理，要素集外部的要素类不能参与到同一个拓扑中。此外, 参与拓扑的要素必须属于简单要素类（点、线、面），而且每个要素类只能处在一个拓 扑中。 拓扑需要在数据库设计阶段考虑，根据数据建模需求，明确一系列要素类中要素 之间的空间关系，然后定义相应的拓扑原则。拓扑中定义的规则可以控制同一要素类 中要素间的关系、不同要素类间要素间的关系、以及要素子类之间的关系。ARCGIS 系 统允许定义的拓扑规则可以查看 ARCGIS 相关文档，例如面之间不许重叠（如：行政边 界不允许重叠）、线之间不能交叉（如：等高线之间不能交叉）、线状要素的端点必须 被另一要素类中的点状要素覆盖（如：管线与管线节点）等。 图 2.13 在 ArcCatalog 中定义了海洋等深线要素类（TBYL）的拓扑规则：（1）等 深线不允许相交，（2）等深线也不允许自相交。图 2.14 为 TBYL 的拓扑检查结果，有 红点的表示有拓扑异常。图 2.15 为放大后看到的等深线自相交异常。 拓扑需要在数据库设计阶段考虑。 ４４ 图 2.13 定义拓扑规则 图 2.14 拓扑检查结果 ４５ 图 2.15 等深线自相交 2.3.3.5 关于地图注记 地图上的文字或符号注记虽然不是地图中的主角，但是很重要，而且在成图过程中占 用较大比例的制图工作量。对于有空间要素对应的注记，可直接利用要素的属性；没有空 间要素对应的地理名称，如山脉、海洋、海湾、海峡、海沟、海槽、海岭、海山、海台、 海盆等等，可通过注记线解决，采集注记位置线，归入注记线类，注记内容赋入属性项， 因为一个一个字往图上放不仅工作量大而且注记的位置也不容易确定。下表为注记线的属 性表示例： ArcGIS9.2 在注记方面有较大的改进，通过标注类（Define classes of features and label each class defferently）、标注管理器（Label Manager）和标注扩展模块 Maplex 中文名 属性名 数据类型 是否可空 长 度 小数位数 国标分类码 GBCODE STRING NO 6 - 中文名 CNAME STRING NO 30 - 英文名 ENAME STRING YES 60 - 标注类码 ANNCODE STRING NO 4 - ４６ （如果 Maplex 已安装的话，可在 Tools → Extensions 中选上 Maplex，然后 labeling → use maplex 激活 Maplex）可实现比较复杂的地图注记。 ArcGIS 中的地图注记涉及 Label（标注）与 Annotation（注记），两者的区别在于 Label 是动态的而 Annotation 是静态的。Label 可以在一定比例尺下转换为 Annotation，但 “Convert Labels to Annotation”必须在 Geodatabase 数据库中进行，而且转换时的地 图显示比例尺必须为成图比例尺，Annotation 是固定比例尺下的地图静态标注。 如果地图要求输出打印，则需要根据地图比例尺在数据库设计阶段确定并试验标注类， 标注类设计时最好能有多个选项，因为同类型的注记在不同区域字体大小会有变化，如南 海与黄海，虽然都是海洋注记，但黄海海域明显比南海海域范围小，注记时字也应适当变 小。 下表是海洋要素的标注类设计示例： 注记 要素 注记 名称 字 体 字 号 （磅） 字 形 颜 色 标注类 图 示 大洋 华文 中宋 28 斜 蓝 SO11 太平洋 18 SS11、SS21 阿拉伯海 16 SS12、SS22 南海 海洋 宋体 14 斜 蓝 SS13、SS23 黄海 13 SB11、SB21 孟加拉湾 11 SB12、SB22 北部湾 海峡 海湾 宋体 9 斜 蓝 SB13、SB23 巴布延海峡 15 ST11、ST21 马里亚纳海沟 13 ST12、ST22 冲绳海槽 海沟 海槽 海盆 宋体 11 斜 蓝 ST13、ST23 中央海盆 15 SM11、SM21 中大西洋海岭 13 SM12、SM22 九州-帕劳海岭 海洋要素 259000 （S） 海岭 海脊 海山 黑体 10 SM13、SM23 黄岩海山 ４７ 上表中标注类码用一个标注要素类字符(如:海洋注记要素类代码为 S)、一个注记名称 的英文首字符(如:海洋的注记名称代码为 S)、1 位数字的文字排列方式（0 无排列方式、1 沿线横排、2 沿线竖排）、及 1 位数字的字号大小组成（0 不分字号、1 大号字、2 中号字、 3 小号字）。 中文注记时会涉及文字的横排与竖排，见图 2.16，ArcGIS 支持文字的沿线横排，见图 2.17 和 2.18，但不支持文字的沿线竖排，因为英文注记不可能出现一个个单词拆开竖向排 列的情况，这时需要通过 VBScript 来解决。图 2.19 ～ 图 2.21 展示了沿线竖排的实现过 程，不过只实现了沿直线竖排，沿曲线竖排不知道有没有简单的办法实现。 沿线横排 沿线竖排 图 2.16 文字沿线横排与竖排 图 2.17 文字沿线横排设置 ４８ 图 2.18 １：５００万比例尺下文字沿线横排标注 图 2.19 文字沿线竖排设置 图 2.20 选择标注类为 SS22 的要素 ４９ 图 2.21 实现沿线竖排标注的 VBScript 图 2.22 １：５００万比例尺下文字沿线竖排标注 ５０ 2.3.4 测试与优化 概念数据模型设计应该按需求进行，当前没有需求的数据实体可暂时留白。每一类概 念数据模型设计完成后需要用实际数据进行测试，然后根据测试结果进行修改。测试过程 中，如果有数据项无法进入数据模型，说明你的设计不够完整，考虑是否需要补充；如果 有数据项总是空着，说明该部分设计可能是多余的，考虑是否删除它；如果属性特别多， 说明关系分解不够，考虑是否横向分解；如果数据量特别大，也说明关系分解不够，考虑 是否纵向分解。此外，如果你总是需要向人解释某些设计内容的具体含义，说明你设计得 不够简单清晰；如果数据必须经过复杂处理才能符合模型设计要求，或者使用时总觉得不 顺手，说明你的设计不实用；如果测试人员提交的规范化数据总是偏离你的设计意图，说 明你的设计不明确或有多义性；如果改动一个地方牵涉多处变动，说明你的设计独立性不 够强。在模型测试与优化过程中切记，没有完全正确的模型，因为模型只是对问题域概念 的一种近似或简化，但是模型可以是有效的模型，有效模型的标准是：实用性强，可维护、 可扩展，并能支持数据的有效存储及快速操作。需要有心理准备的是，“经测试正确”只是 表明模型可以投入正常工作，并不证明模型就能持久稳定了，虽然稳定是数据库设计及开 发人员的愿望，但事实证明，随着应用的不断深入，需求的逐步变化，修改及优化将是不 可避免的。在概念数据模型到数据库模式的构建中应充分考虑修改及优化的可能性，使得 构建的数据库模式能承受变化。 ５１ 2.4 构建数据库模式 概念数据模型设计完毕，并不表明数据库设计任务就完成了。从概念数据模型到构建 物理层数据库模式还有一段路要走，需要做的工作包括： （１）将概念数据模型映射到物理层的数据库模式（Database Schema）中，实体映射 到表、属性映射到字段，实现概念层到物理层的转化，或说是数据模型的物理实现与部署； （２）除数据表常规约束外，部署索引、视图、存储过程与触发器等模式对象，保障 数据的完整性、安全性、可伸缩性，这部分工作在物理层数据库设计中不容忽视，因为它 关系着数据库的可用性与可靠性。 数据库模式与数据库系统类型、应用架构及安全控制策略等具体因素密切相关。首先， 数据库模式与数据库系统类型有关，因为不同数据库的数据库模式定义方式有差异；其次， 数据库模式与应用架构有关，因为涉及数据库模式对象与完整性规则约束的部署，你可以 把他们部署在数据库端，也可以部署在应用端；数据库模式还与系统的安全需求有关，因 为涉及数据表的访问与操作权限。不管在何种情况，都应该从有利于数据库性能优化的角 度来构建数据库模式，在构建数据库模式过程中注意积少成多的性能负面影响。此外，数 据库模式是面向开发的，因此应该为应用开发搭建起良好的数据库访问平台，尽量避免对 数据库结构的直接访问，不至于数据库模式的修改引起外部应用的大幅度调整。 Geodatabase 上的数据库模式构建就简单得多，只需要通过 ArcCatalog 构建逻辑结构， 在数据库端的物理部署则由系统自动完成，不需要外部干预。 数据库模式这一称谓是 Database Schema 直接翻译的结果，不是特别容易理解，因为 Schema 建在 Oracle 等企业级关系数据库的服务器端，除 DBA（数据库管理员）外一般人是 看不到的，由此造成关于 Database Schema 的盲区，因此这里从什么是数据库模式开始谈 起。 2.4.1 什么是数据库模式 简单地说，Oracle、DB2、SQL Server 等企业级关系数据库管理系统（DBMS）均由三个 独立的组件构成：应用程序（application）、数据库引擎（database engine）和关系数据 库，见图 2.23。其中，应用程序负责与用户的交互；数据库引擎负责数据的物理操作，也 就是将数据存储到磁盘上，或在需要时将数据从磁盘中取出来；而关系数据库是数据库模 ５２ 式（database schema）及数据（data）的物理实现。真正的物理实现是数据库引擎的职责， 我们不必要去关心底层的 B 树、Hash 等等物理存储模式，但数据库模式是需要数据库设计 人员来定义的。那么数据库模式到底是什么呢？ 图 2.23 数据库管理系统组构 数据库模式（database schema）是概念层数据模型在物理层描述的集合，注意是数据 模型在物理层的描述，而不是实现，实现是数据库引擎的工作。因此，数据库模式是问题 域与数据库引擎之间的中介，将问题域概念数据模型表述成数据库模式要求的方式，数据 库模式表述方式也是数据库引擎能理解的方式，这样数据库引擎才能按照你定义的方式去 存储数据。 DBMS 为了对数据库中数据实施有效组织管理引入了 Schema，Schema 类似操作系统中的 文件夹，只不过里面放的不是文件，而是数据库逻辑对象，包括表、视图（Access 中的查 询）、索引、触发器及存储过程等。进入 DBMS 的管理控制台可以看到 Schema，而且 Schema 可能不止一个(操作系统中的文件夹不会只有一个)。在 Oracle 数据库中，每一个 schema 对应一个用户，也就是 schema 和用户的关系是一一对应的，不同的用户可以在各自的 schema ５３ 下定义自己的逻辑对象，不用担心有对象重名的可能性，因此从另一角度来说，schema 也 是个命名空间。不同 shcema 之间的表可以互相引用，但必须有权限，如果没有操作权限， 每个用户只能操作自己 schema 下的表。数据库管理员可以将不同应用的表放在不同的 schema 中，这样就可以通过 schema 对数据库中不同应用的表分别进行管理。 2.4.2 什么是数据完整性 保障数据完整性是构建数据库模式的最基本任务，因为数据完整性是数据库可靠性及 可用性的基本保证。那么什么是数据完整性呢？ 数据库的数据完整性（data integrity）表示通过完整性将数据库控制为一个整体， 存储在该整体中的实际物理数据在逻辑上具有一致性。数据库数据完整性是数据库中数据 的似真性，不是数据的正确性，也就是看上去是正确的，但并不保证数据是完全正确的。 这有点像财务做帐，至少面上要做平，如果面上都不平，那肯定是有问题，但即使面上做 平了，也不能保证没有假帐的可能性。 数据库数据完整性包括：域完整性、实体完整性和参照完整性。还有转换完整性、事 务完整性等动态的完整性要求，这里只谈静态的完整性。 （１） 域完整性 域是属性或数据列可能包含的所有有效值的集合，域完整性保证数据表中的每一列不 包含不合理的值。域完整性通过限定数据属性或字段的数据类型、取值范围（包括有效值 范围、可取值列表、非空、缺省值等）、数据格式与长度等实现。Oracle 中的 REF 约束就是 一个域完整性约束。 （２）实体完整性 实体完整性保证一个表中的每一行必须是唯一的。主键就是最简单的实体约束，主键 迫使每个实体被唯一确定。一个表只能有一个主键，如想保证其它的列唯一，可以将一个 或一组非主键列指定为唯一值键。 （３）参照完整性 参照完整性定义了关系数据库中不同表之间的逻辑一致性规则。前面已经介绍过，关 系数据库通过分解关系来减少冗余，当提取数据时通过外键实现关系的连接重组，如果连 接无法实现，那么数据库系统至少是不可靠的，甚至是不可用的。参照完整性建立在外键 和主键之间或外键和唯一值键之间的关系上。参照完整性规则要求子表中的一列或一组列 ５４ 中的值必须要与父表中的一列或一组列中的值相匹配，从属的一列或一组列称之为外键， 被引用的列或一组列称之为父键，父键必须是一个主键或唯一键。只要依赖于某主键或唯 一键的外键存在，父表中包含该主键或唯一键的行就不能删除或改变；只要父表中不存在 某外键和唯一值键，子表中就不能插入该外键和唯一值键的数据行。因此参照完整性用来 保障外键不孤立，外键所在的表中不允许与主表不匹配的外键存在，由此保证了表之间的 数据的一致性，防止了数据丢失或无意义的数据在数据库中遗留。 Oracle 中，当用户删除 或更新父表中某行而子表中有一个或多个与之匹配的行时，系统会根据其在 foreign key 子 句中定义的 on update 或 on delete 子句来决定约束行为，可以有四种选择：（1）cascade 自动级联删除或级联更新在子表中匹配的行；（2）set null 将子表中的外键列设置为 null， 如果该列不为非空；（3）set default 将子表中的外键列设置为缺省值，如果该列已设置缺 省值；（4）no action 拒绝对父表进行删除或更新。从中可以看到参照完整性规则与级联 删除或级联更新不是一回事，实施参照完整并非就实现了自动的级联删除或级联更新，不 要混同。 （4）几何完整性 Geodatabase 中要素间的几何完整性通过拓扑规则进行约束，控制同一要素类要素间的 几何关系、不同要素类要素间的几何合关系、以及要素子类之间的几何关系。具体见 2.3.3.4 介绍。 2.4.3 表空间部署 Oracle 数据库由若干个表空间（tablespace）构成，划分表空间是数据库部署的第一步， 因为任何数据库对象在创建时都必须指定存储在哪个表空间中。表空间对应若干个磁盘文 件，它是数据库逻辑结构与物理文件之间的一个映射，也就是是物理存储和逻辑对象之间 的中介。 表空间可按照数据总体结构来划分，把各个模块的数据放到不同的表空间中，以便对 不同数据模块的数据进行单独维护与管理，因为 Oracle 支持表空间数据的单独维护，如备 设置了外键并不等于设置了参照完整性，外键只是实施参照完整性的桥梁。 实施了参照完整并非就实现了自动的级联删除或级联更新。 ５５ 份、恢复或整体移动；也支持表空间在线、离线或只读。 下面是一个表空间划分的示例： 表空间 名 称 存储数据 用 途 系统 SYSTEM 存储数据库管理信息，包括数 据字典、存储过程和触发器等 ORACLE 系统必备表空间，不能脱 机 索引 INDEX 存储数据索引 ORACLE 系统 用户 USERS 存储用户信息 ORACLE 系统 元数据 XDB 存储元数据 ORACLE 系统 调查信息 DIAS_SUV 数据信息层的调查信息数据 DEMO 数据库 SDE 系统 SDE_SYSTEM 存储 SDE 系统管理数据 Geodatabase SDE 空间数据索引 SDE_INDEX 存储空间数据索引 Geodatabase 地图数据 DIAS_MAP 存储所有地图空间数据及与 地图相关的属性数据 Geodatabase 遥感数据 DIAS_RSI 存储遥感数据 Geodatabase 文档数据 DIAS_DOC 存储文档数据 DEMO 数据库 原始数据 DIAS_DAT 存储原始数据（可按专业模块 划分出多个表空间） DEMO 数据库 在 ArcGIS 中，只要通过 ArcCatalog 在关系数据库中创建一个 Geodatabase，ArcGIS 就会通过 SDE 引擎自动在数据库服务器端创建三个表空间：SDE 系统表空间、空间数据索引 表空间和空间数据对象表空间。 2.4.4 数据库模式对象部署 数据模型从概念层转化到物理层，转化过程中术语发生了改变，实体转化为表，属性 转化为字段。 关系术语 概念层 物理层 关系（实体） 表 属性 字段或列 元组 记录或行 ５６ 除实体到表、属性到字段的直接映射外，构建数据库模式过程中的最基本任务是解决 数据的完整性问题。完整性问题通过定义表的约束来完成，如果无法作为表定义的一部分 在常规约束中实现完整性约束，可以使用触发器或存储过程来强制实行约束。因此除数据 表的基本定义外，约束、索引、视图、存储过程、包与触发器等数据库模式对象需要视实 际应用环境与需求设置。相关的应用逻辑也可以在外部应用层实现，但中央化的应用逻辑 可充分利用数据库自身的协调性，并避免重复性的维护工作。 这里需要提醒的是，在安装数据库系统前一定仔细研究数据库系统的所有初始化参数， 考虑它们对表对象的影响，因为待数据进库后某些参数有可能很难改动了。拿 Oracle 初始 化参数文件里的参数“NLS_LENGTH_SEMANTICS”为例，“NLS_LENGTH_SEMANTICS”的缺省值 为“BYTE”（字节语义），当时在安装 Oracle 时我们直接采用了缺省方式“BYTE”没多加考 虑，但后来在创建表时总觉得不方便，因为中文是双字节的，涉及中文字符串的数据类型 长度都得乘 2 才能满足要求。我一直都以为 Oracle 数据库就该如此，一直到后来在一本书 中看到“没有特殊理由，应总是将参数设置为 NLS_LENGTH_SEMANTICS = CHAR”，才知道原 来 NLS_LENGTH_SEMANTICS 还可以设置为字符语义，此时数据都已经进库，除非重新倒数据， 否则是没法改动了。另外如 NLS_DATE_FORMAT 参数，这是日期默认格式的设置，虽然在数 据入库或提取时可以设置格式，但数据作隐式转换时（无格式定义时）就会取决于默认格 式，因此这一类参数的设置也应该加以考虑。最重要的当然是关于语言字符集的参数设置， 因为设置不对，出来的可就是乱码了。 2.4.3.1 表及其约束 Schema 中表的定义直接从概念数据模型派生，实体映射为表，实体的属性映射为数 据表的字段，属性域则由数据类型、数据格式及有效性规则共同定义，表之间的联系通 过外键实施约束,如下表。 除非有特殊理由，否则总是将参数设置为 NLS_LENGTH_SEMANTICS = CHAR（缺省为 BYTE）， 使字符语义成为缺省。 ５７ 约 束 序 号 中文名 字段名 说 明 主键 唯一 非空 外键 数 据 类 型 域 1 微古鉴定统计 AD_MF 微体古生物鉴定结果统计 1.1-1.8 1.1 送样号 SUBSAMPLE_ID 送样的原始编号 √ AD_MF_PK VARCHAR2(20) Free text 1.2 孔号 BORHOLE_ID 外业给定的钻孔编号 √1 AD_MF_UK1 √ √ AD_MF_ASS1 VARCHAR2(15) Free text 1.3 取样顶深 SSAM_TOP_DEP 取样顶深，从孔顶部起算 √1 AD_MF_UK1 √ NUMBER(6) 正整数，如：68， 单位：厘米（cm） 1.4 取样底深 SSAM_BOT_DEP 取样底深，从孔顶部起算 √ NUMBER(6) 正整数，如：70， 单位：厘米（cm） 1.5 化石类别 MF_GROUP_CD 鉴定的微体古生物类别 √ √ AD_MF_REF1 VARCHAR2(2) MF_GROUP_CD 《CodeList》（B.1） 1.6 丰度 TOTAL_NR 计算列，单位重量干样内所鉴 定化石群的化石总个体数 NUMBER(5) 正整数，如：20， 以枚计，介形虫以壳瓣计 1.7 简单分异度 SPECIES 计算列，样品中所鉴定化石群 的化石种数 NUMBER(5) 正整数，如：3 1.8 复合分异度 HSPECIES 计算列，复合分异度计算公式 如下： H(S) = -ΣPilnPi H(S)：复合分异度 Pi：第 i 种个数占全群的比例 NUMBER(4,2) 正实数，如：1.04 58 约束是数据完整性规则的体现，设计数据库时，规划和创建约束所花的时间越多，以后 管理数据库所花的时间就越少。常规约束通过表定义的组成部分声明，Oracle 里可以创建 7 种类型的约束，包括： (1) NOT NULL（非空）； (2) UNIQUE（唯一，允许包含空值）； (3) PRIMARY KEY（主健，能唯一标识表中一行的一列或一组列，主键必须唯一且非空）； (4) FOREIGN KEY（外键，与父表中主键或唯一键匹配的一列或一组列，用来维护表之 间的关联，实现参照完整性）； (5) CHECK（校验，定义字段有效性规则，要求有效性校验结果不等于 FALSE）； (6) DEFAULT（缺省值，只适用于插入新记录，可以认为它是 NOT NULL值的一种替代行 为）； (7) REF（指向一个可取值列表或对象的引用，类似于传统的关系型约束）。 其中主健和唯一健是表级的约束，保证实体的每个实例都是唯一确定的，非空、校验、 缺省值与引用是字段级的约束，保证重要数据内部的完整及合理性，外键用于实现表之间 的连接与参照完整性。如果某些约束规则无法作为表定义的一部分在常规约束中实现，可 以使用触发器来强制实行这个约束。 完整性规则可以在数据库中定义，也可以在应用层中定义,或者实行双保险，两边都定 义，前提是必须确保不同位置上规则的一致性。不过，拟尽可能在数据库中实现完整性规则 约束，因为中央化的规则能确保冲突数据无法从后门混入数据库，另一方面规则约束集中化 能降低维护成本，在规则修改时不需要大动干戈，让多个应用程序避免重复性的维护工作。 外键允许为空值，如果希望外键列中不包含空值，必须显式给出非空约束。 不等于 FALSE 和等于 TRUE 是有区别的，因为数据库允许 NULL 值，空缺项的值均为 NULL， 与 NULL 值的任何运算结果还是 NULL，因此数据库中是三值逻辑：TRUE、FLASE、NULL 。 59 2.4.3.2 索引 索引是对数据表一列或多列的值进行排序的一种结构，用于加速基于索引字段的数据排 序以及优化查询的执行速度，避免全表扫描。索引是直接影响数据库性能的数据库模式对 象，因此十分重要。在定义主键和唯一键约束时数据库引擎会自动创建相关字段的索引，其 它索引就需要用户自己定义。索引创建必须慎重，过多的索引将降低数据表的更新效率，因 为数据表每更新一次，索引也需要更新，所以创建索引时需要考虑表的更新频率。 实践中可通过测试或试验选择适合数据库的索引方式，一般情况下建索引原则如下： (1) 在大表上建索引，如果该大表的数据检索量只占数据总量的一小部分，能明显提高 数据检索速度； (2) 在外键或用于表连接的列上建索引，避免数据连接或级联更新时的全表扫描，提高 表连接速度； (3) 在常用的数据排序字段上建索引，可提高数据排序速度； (4) 不拟在具大量空值或重复值的列上建索引； (5) 不拟在频繁更新的列上建索引。 索引能改进数据检索速度，却使数据表的更新效率降低。对于批量装载或更新，可以考 虑在装载或更新时删除索引，装载或更新完成后再重建索引。索引在数据库内占用磁盘空间， 在数据库空间规划时必须加以考虑。拟为索引创建一个单独的表空间，并保证该索引表空间 的数据文件与表数据文件分别存储在不同的磁盘上，避免驱动器争用，加速数据访问的整体 性能。 2.4.3.2 同义词 同义词是数据表的别名，是指向数据表的数据库指针。如果访问 schema 下的模式对象 需要在对象前添加 schema 名称，建议使用同义词，以避免在应用代码中使用schema 名称的 硬编码。 2.4.3.3 视图 视图是根据用户需要，从一个或多个数据表中派生的虚表，由基于一个或多个数据表 的 SQL 查询定义，视图是数据表面向用户的模式。视图作用包括： (1) 过滤基表数据，通过 select 和 where 定义视图，显示用户关心的行或列； 60 (2) 隐藏设计痕迹，通过视图更改列名、替换代码，使表的显示方式符合用户的习惯； (3) 封装对表的访问，消除应用代码与表之间的直接耦合，使表结构变化不影响外部的 应用代码； (4) 安全访问控制，对不同用户授予不同的使用权，通过使用 select 子句限制用户对 基表列的访问，通过使用 where 子句限制用户对基表行的访问。 需要注意的是，视图定义是有限制的，如：不能使用 UNION 操作符；不能用 ORDER BY 子句等。此外，视图数据更新也有限制，如：基于多表的视图不能使用 DELETE；如果视图 不包括基表中的所有非空列，不能使用 INSERT；所有更新记录都必须属于同一基表；不能 更新表达式或函数的计算结果组成的列；不能在使用了 DISTINCT 语句的视图中更新或插入 记录；不能在使用了 GROUP BY 语句的视图中更新或插入记录等。 2.4.3.4 存储过程或函数 存储过程或函数是一组能完成特定功能的 SQL 语句集模块，通过指定存储过程或函数 名执行。存储过程在第一次调用时执行编译，再运行时其执行速度很快。存储过程作用包 括： (1) 用于封装可复用的复杂过程性逻辑； (2) 提高执行效率，因为存储过程执行效率高于应用程序中的请求处理； (3) 数据库端的数据集中处理减少网络流量； (4) 封装对表的访问，消除应用代码与表之间的直接耦合； (5) 安全访问控制，通过限定存储过程的执行权限，实现数据访问的权限控制。 尽可能将单独的 SQL 语句封装到过程或函数中，通过过程或函数的参数传递信息，避免 单独 SQL 语句的重复性拷贝。需要注意的是存储过程或函数依赖特定的数据库类型，不 能保证不同数据库之间或新旧版本之间的移植。 2.4.3.5 触发器 就本质而言，触发器也是一种存储过程。触发器主要通过事件进行触发而被执行，象存 尽可能将单独的 SQL 语句封装到过程或函数中，通过过程或函数的参数传递信息，避免单 独 SQL 语句的重复性拷贝。 61 储过程一样，触发器在第一次调用时执行编译。当对某一表进行诸如 UPDATE、 INSERT、 DELETE 这些操作时，数据库系统就会自动执行触发器所定义的 SQL 语句，从而确保对数据 的处理必须符合由这些 SQL 语句所定义的操作。 触发器常见的用法包括： (1) 实现数据同步更新及更新有效性确认，如强制实施无法在常规约束中实现的约束， 维护复杂关系数据表之间的数据完整性，添加自动编号列，实现一个自动编号的主 键，添加计算列等； (2) 数据库自动维护，如在数据库启动或关闭、用户连接或断开、以及异常引发时实现 数据库的自动维护与管理； (3) 实现数据库操作的精细控制，可以利用触发器来严格控制数据库对象的可允许操 作，一旦把相关逻辑放到触发器中，任何人都很难绕过所建的规则。 一般情况下，数据表操作最好通过存储过程实现，不要过多采用触发器，过多的触发器 将影响数据库的性能。 2.4.3.6 包 包（package）是相关过程和函数的 Oracle PL/SQL 逻辑组合单元（也就是包是组合数 据结构和程序代码块的容器）。包由包头和包体两部分组成，包头定义公共常量、变量、类 型，以及过程和函数界面；包体定义过程和函数的实现。Oracle 包提供了有意义的独特功 能，包括封装应用逻辑、组合逻辑相关应用逻辑、避免硬编码与代码重复性拷贝、缓存 SESSION 静态数据提高应用性能（利用包数据的持久性特征，通过缓存静态数据提高应用的 响应速度）等。 包构建原则： (1) 尽可能将逻辑相关的过程和函数封装到包中，避免单独过程和函数的重复性拷贝； 创建包的最主要动机是封装 SQL 语句、只提供操作界面、不让SQL 语句散落在代码 各处，这样开发人员只需要调用预定义的、已经过测试并优化的代码就行了，同时 代码的更新与维护也可达到最小化和中央化。因此建议：隐藏所有单行查询到一个 函数界面之后，这样可以确保执行时的异常处理，并选择最佳实现方式；其次识别 可能的最频繁并直接访问的表，用代码包围它；最后对于复杂的事务逻辑创建包级 过程，将复杂逻辑嵌入到过程中来处理，不要放任应用开发人员去寻思。 (2) 尽可能将逻辑相关的元素组合到同一个包中，减少代码运行时的内存占用，也易于 62 代码管理，因为运行时代码是以包为单位载入内存的，只要包中有一个元素被调用， 整个包随之载入内存； (3) 建立单独的异常处理包，封装异常处理的具体细节； (4) 尽可能避免在包头中声明包级全局变量，避免变量无法控制带来的负面影响； (5) 尽可能在包头中声明常量，避免包体中的硬编码文字串。 2.4.5 数据库重构 数据库模式构建完成后，随着应用的不断深入会遇到各种各样想不到的问题，外部需求 也可能不断变化，因此不可避免会涉及数据库的重构(Refactoring)及转换（Transform）。 重构是对数据库 schema 进行简单改动，也就是保持 schema 的原定义前提下改进 schema 的 设计。转换是为 schema 添加新的特征，也就是原 schema 定义的变更。由于 schema 的变动 波及与 schema 耦合的外部系统的变动及大量数据的迁移，因此技术上会有一定的难度。因 此数据库设计人员必须有正确态度应对变化，“对数据库模式设计，不要试图在项目前期完 成它，而要在项目生命期逐步构建它。”（Scott W. Ambler, Pramod J. Sadalage 《数据库 重构：渐进式数据库设计》） 数据库模式不是一成不变的静态结构，在实际中可能需要重构甚至转换来进行完善或扩 展，因此应有心理及技术上的准备去迎合变化。你的设计应该有足够的能力承受不影响大局 的数据库重构，即使数据库已经部署到生产环境中，数据库模式也照样可以安全地演进。 现实中数据库设计人员与应用开发人员往往是两拨人，互相的隔阂与冲突不可避免，如 果在一开始就有思想准备，把持续改进视作是数据库设计与开发中的正常工作。同时，在数 据库设计中考虑搭建良好的数据库访问平台，封装对数据库的访问，让外部程序通过持久层 来访问数据库，例如通过数据访问对象、通过持久性框架、通过存储过程、通过 Web 服务器 等，封装得越好，改进就越容易。这样，使得应用软件能与底层数据结构无关，从而简化应 用软件的设计，为应用软件系统的健壮性、灵活性、可重用性、可升级性和可维护性创造条 件。 包在概念上很简单，但实际应用具有挑战性，建议总是围绕包创建你的应用。 63 3 元数据 元数据很不受重视，但它在数据库中其实很重要，数据库数据做得再好，没有相应的元 数据说明，也有可能无法重利用。我多次遇到过这样的情形，为了利用数据不得不发 Email 与数据供方交流，多数情况下数据供方也无法回答，因为数据库管理方不是数据的真正供方， 最后只得放弃。 元数据（metadata）一般定义是关于数据的数据（data about data），具体说元数据是 描述一个资源对象，并有助于该对象管理、定位、获取与利用的数据。元数据并非信息时代 的新生产物，图书馆的图书卡片，档案馆的资料目录，工业产品的广告印刷品都是元数据的 传统形式，计算机与网络的大众化及数字信息资源的主流化赋予了元数据新的意义与作用。 首先，元数据可充当资源对象的使用指南，增强数据的可理解性。任何数据模型都是对 现实领域的近似表达或简化，因此数据库中的数据实体所表达的数据内容往往存在片面性与 局限性，元数据是弥补这部分缺陷的使者。元数据为数据生产方提供了全面描述数据资源的 途径，为保障资源对象的重利用、避免资源对象的无法理解和使用、以及误解与误用奠定了 基础。 其次，元数据的作用还包括充当资源对象的对外使者，通过它数据资源能被快速发现及 定位。元数据与具体资源对象虽密切相关，但它是独立于资源对象的，也就是说，两者只是 逻辑上的联系，物理上是分离的，因此元数据能独立地、不受限制地面向公众开放，不必担 心具体资源对象的安全性问题，对有偿或面向有限人群服务的资源，元数据解决了资源又要 共享又不能无限制开放的矛盾。此外，元数据信息量大载体量小，非常有利于网上检索、传 输及浏览。通过元数据，潜在用户可在海量信息中快捷地定位所需要的资源对象，而且不必 接触具体资源对象即可对资源对象有基本的了解和认识，从而确定资源对象的取舍。因此， 元数据对于数据交换网络的建设具有十分重要的作用，数据交换网络是在数据生产者、管理 者和用户之间建立的分布式电子连接网络，网络中心通过设在中心的元数据库可以实时地连 接各个分结点的元数据库，帮助潜在的用户找到其特定应用所需要的数据，实现数据的大范 围共享。 国外在元数据标准化方面的研究工作开展得较早，对于地理信息元数据，90 年代中期 以来已有不少国家和国际性组织发布并实施了各自的元数据内容标准，如美国联邦地理数据 委员会的 FGDC 元数据标准，欧洲标准化委员会的 TC287 元数据标准和澳大利亚、新西兰土 64 地信息委员会的 ANZLIC 核心元数据标准等等。2003 年 5 月国际标准化组织/地理信息委员 会（ISO/TC 211）发布了国际标准 ISO 19115：2003 《地理信息 元数据》，该标准是以 FGDC、 TC287 和 ANZLIC 等已有标准为基础研制的地理信息元数据标准，标准从工作草案 （WD—1996），委员会草案（CD1—1998，CD2—1999，CD3—2000），国际标准草案（DIS—2002）， 最终国际标准草案（FDIS—2003），正式国际标准（ISO 19115：2003），经历了多年的历程。 从内容上看 ISO19115 与 FGDC 十分相似，但在元数据内容的组织结构上两者却有着根本的区 别，ISO19115 采用面向对象的结构化模型来建立地理信息元数据的层次结构框架，更有利 于元数据的扩展及元数据的 XML 格式化存储。 近年来，国际和国内的许多领域都纷纷制订各类 ISO19115 专用元数据标准，ISO 19115 同名修订版《地理信息 元数据》（ISO19115:2003,MOD）已经批准为国家标准 GB/T 19710-2005，我国科技部科学数据共享工程从 2005 年开始采用 ISO 19115 的构建思想 制订了《科学数据共享元数据内容》标准及《元数据标准化基本原则和方法》。现在与地理 信息相关的标准都选择了 ISO 19115作为基本标准，并纷纷以 ISO 19115为基础定制行业相 关的标准。 不过定标准容易，实施却不简单，不是一份红头文件或一道行政命令能解决的。从目前 网上发布的元数据看，应用状况并不理想，元数据没有起到它应有的作用。我个人分析原因 如下： （１）文化差异 ISO 19115 是国外标准，习惯差异加之语言隔阂，使得相关中文标准有看上去有点怪， 实施时会有障碍，第一次接触元数据的人看着中文标签往往不知道该填啥。 （２）不重视元数据表现 ISO 19115 元数据是层次结构的，有点像阿里巴巴的故事，大故事里套小故事，不容易 用一个简单的线性表格来很好地表现。如果用一个简单的表格来表现就很可能走样。ISO 19115 元数据最好的表示方式是 XML（可扩展标记语言），因为 XML 非常有利于表达层次结构 的数据内容，并易于网上传输浏览与共享，而且现在的大型数据库都支持XML 格式的数据存 储。其实，ISO 19115 已定义了相应的 XML Schema（XML 模式）供参考，但是大部分国内定 制标准光重视内容不重视元数据的表现，把这部分给扔掉了。现在国内网上能看到的元数据 大部分是简单表格，或以 WORD、PDF 等格式的文档，XML 格式的元数据不多。有的元数据表 格又过于简化，造成元数据千篇一律，一模一样，元数据成了摆设，无法真正起到数据的标 识作用。 65 （３）不理解元数据 元数据是个中间介质，它夹在数据生产者与数据库建设人员之间，不上不下，数据生产 者认为数据提交了他们的任务就完成了，干吗要写什么元数据，写元数据是搞数据库人员的 工作不是他们的事情，因此常常不愿意填。而数据库建设人员，由于不了解数据的实际生产 过程加上缺乏专业知识，即使写也很难把元数据写好。 3.1 元数据标准定制 ISO 19115:2003 定义了普遍适用的空间信息元数据内容框架及其扩展规则，为专业领 域元数据标准的建立提供了一个基础平台。各专业领域可以在 ISO 19115:2003 的基础上， 建立自己的专用元数据标准（Profile）。 利用 ISO 19115 定制专用元数据标准的基本原则包括： （１）以实际需求及本地环境为本 元数据标准的最终目的是为了向用户提供更好的信息服务，因此在元数据实体和元数据 项的取舍、命名、扩展、布局上应充分考虑用户的实际需求与习惯。首先中文元数据标准应 符合中国文化的特点及语言习惯，以“联系方式”元数据项为例，英文习惯是由个人、单位、 市、省到国家排列，而中文习惯则完全相反，在定制过程中拟改写。其次，元数据内容应尽 可能符合我国的国情，以数据质量描述为例，ISO 19115 中有关数据质量的元数据内容非常 详尽，而我国在质量评价方面笼统居多，因此拟扩展相应的数据项来解决国内外的差异，避 免有关数据质量的元数据项形同虚设。 （２）注重元数据标准的易操作性 ISO 19115:2003 中定义了数百条的元数据项，在实际应用中必定有所取舍，在取舍定 制过程中尽量以简单易操作为原则，这样能有利于将来各方专业或非专业人员的元数据著录 与理解，当然这种简单化是建立在一定的准确度之上的，也就是在简单化与准确度之间平衡， 在简单化的同时，保证元数据能突出资源对象的不同特点，避免造成元数据千篇一律的现象。 （３）保障核心元数据内容的落实 核心元数据是保证数据资源能被唯一识别的最基本的元数据内容，核心元数据内容拟覆 盖数据资源的主要内容、创建日期、创建单位、覆盖区域及数据创建过程等主要元数据信息， 编写的标准拟确保这些信息将来能切实落到实处，以保证元数据能真正发挥元数据应有的作 用。 66 由 ISO 19115:2003 定制专用元数据标准的过程包括： （１） 保留 ISO 19115:2003 中必选的及核心的元数据实体和元数据项；(注：除必选 及满足一定条件下必选的元数据项外，其它元数据项是可以按需要自由取舍的。 元数据项可选性分三类：必选（mandatory），是必须给出的元数据项；条件必 选（mandatory-if-applicable），是当元数据项符合给定特征时必须给出的元 数据项、以及可选（optional），可自由取舍的元数据项。节点可选性是相对其 父节点而言的，也就是当父节点不空缺时，子节点相对其父节点的可选性。) （２） 根据本领域的专业特点与需求选取 ISO 19115:2003 中可选的元数据实体和元数 据项； （３） 遵循 ISO 19115:2003 的扩展规则，扩展专业领域需要的元数据实体和元数据项； （４） 拟定元数据包 UML 类图，建立所选取的和扩展的元数据实体和元数据项之间的 关联环境与层次结构，同时限定各元数据实体和元数据项的可选性及允许出现 的最大次数。 （５） 内容本地化，将元数据实体与元数据项英文名称翻译成中文，并按中文习惯调 整它们的先后次序，同时确保元数据实体及元数据项英文标识符的唯一性，以 便在元数据格式化文件中作为唯一标识，最后建立元数据实体及元数据项的数 据字典； （６） 按照我国的标准编写规则（GB/T 1.1—2000，标准化工作导则，第 1 部分：标 准的结构和编写规则），编写标准化文档，形成专业领域的专用元数据标准。 3.2 元数据内容 元数据内容包括描述性，管理性及应用性三方面信息，使元数据在展示资源对象名称、 类型、建立日期、创建单位、覆盖区域等外观特征的同时，还能反映资源对象的历史与变更、 质量与评价，同时提供资源对象的内容、参照标准、使用方法及获取与联系途径等。图 3.1 的元数据内容由数据编目信息（MD_DataIdentification）、数据质量信息 （DQ_DataQuality）、空间参照系信息（MD_ReferenceSystem）、内容信息 （MD_ContentInformation）及发布信息（MD_Distribution）五个信息类聚合。 67 MD_Metadata +fileIdentifier[0..1] : CharacterString +language[0..1] : characterstring +characterSet[0..1] : MD_CharacterSetCode = GB2312 or UTF-8 +contact[1] : CI_ResponsibleParty +dateStamp[1] : Date +metadataStandardName[0..1] : CharacterString +metadataStandardVersion[0..1] : CharcterString RS_ReferenceSystem0..* +referenceSystemInfo DQ_DataQuality 0..* +dataQualityInfo MD_Distribution 0..1 +distributionInfo MD_ContentInformation 0..* +contentInfo MD_DataIdentification 1..* +dataIdentificationInfo 图 3.1 元数据信息 UML 类图 3.3 元数据 XML 格式化 标准的元数据内容并未保证标准的元数据格式，采用什么语言与语法结构来组织元数据 内容是决定元数据检索效率及互操作性的关键。目前国内采用得比较多的是一般的文本文 件、WORD 文档、PDF 文档，以及关系型数据库表，也就是把元数据内容分成多个有关联的数 据库表，这样的元数据表现形式缺乏灵活性，很难体现元数据内部的嵌套、引用及标签多次 重复，也不利于元数据的管理与共享。相比之下，采用 XML 格式来描述元数据内容具有其它 数据格式无法替代的优越性。XML 有利于元数据的跨系统与跨平台共享、便于元数据的网络 传输与交互、能充分体现元数据内部的结构与层次。此外，XML 具有数据内容与显示方式分 离的特点，通过 XML Schema可以定义 XML 的内容，通过 XML XSLT样式单可以定义不同的元 数据显示方式，将同一元数据以不同的面貌展现给不同的用户。XML 数据描述技术是今后的 重要发展方向，下面编录了部分 XML 基础内容（主要来自 JavaEye 技术网站），我想会有助 于对 XML 的了解。 3.3.1 XML 来源 由于 HTML（HyperText Markup Language，超文本标记语言）越来越庞大，完全背离了 HTML 最初设计的初衷，并使得实现一个完全的 HTML 浏览器也越来越复杂。为了给 HTML 减肥，利于 Web 的健康发展，W3C 设计了 XML。XML 的设计思想来自 SGML（Standard Generalized Markup Language，标准通用标记语言）。SGML 是 IBM 创造的一个用于出版业 68 的文档格式标准，后来被 ISO 采纳作为国际标准（ISO 8879）。SGML 把文档内容与文档格 式完全分离开，使得内容提供者与排版人员的工作可以相互独立。SGML 是一种非常严谨的 标记语言，但是 SGML 的问题是过于复杂，一个基于 SGML 的出版系统开发成本高昂，价格 不菲。SGML 过于重量级的特点使其完全不适合用于 Web 领域，而且 SGML 的设计完全是面向 文档的，不是面向数据的，而大量基于 Web 的应用是面向数据的应用。于是 W3C 参考 SGML 设计了新一代的标记语言 XML，XML（Extensible Markup Language，可扩展标记语言）是 一种元语言，利用它可以创建其它任意种类的标记语言。实际上 XML 规范只有几十页，只是 SGML 规范的 1/10 左右。XML 实现了 W3C 最初设定的所有目标：轻量级、易于理解、扩展性 好、平台中立、兼顾文档和数据。 3.3.2 XML 有效性验证 有效的 XML 就是通过某种格式定义来规定这个 XML 中只能有哪些标记、这些标记应该 按照什么顺序出现，每个元素有哪些属性，这些属性的格式，取值范围等信息。然后这一类 的 XML 只要经过验证符合这个格式定义就认为是有效的 XML。为什么 XML 需要经过验证，这 主要是电子商务的需要。举个例子，如果你需要通过 Web 方式与客户进行交易，你把电子 形式的发票发给客户，客户也会把他们的发票发给你，但是两种发票的格式不同，就好象你 在说汉语他在说英语，彼此无法正常交流。所以必须要有一个统一的格式标准才能够展开正 常的电子商务活动。XML 就是靠不同的格式定义来建造不同的标记语言的，每一种格式定义 （标记语言）叫做一种词汇表（vocabulary）。 XML 的格式定义有很多种方法，包括 DTD（Document Type Definition，文档类型定义）、 XML Schema（XML 模式）、RELAX NG 等等。DTD 是参考 SGML DTD 创造出的 XML 格式定义方 法。DTD 的格式定义采用与 XML 不同的语法，这使得很难直接用解析器来解析 DTD，也很难 动态验证 XML 的有效性。W3C 后来又创造出了 XML Schema。XML Schema 是一种新型的 XML 格式定义方法，它完全采用 XML 语法，便于解析器处理，而且对于数据格式的定义更加严 格和精确，所以 Schema 更加适合面向数据的应用。那么有了 XML Schema 是否我们就可以 完全抛弃 DTD 呢？答案是否定的，由于 DTD 来自于 SGML，它非常适合面向文档的应用。定 义相同的 XML 格式，DTD 定义要比 XML Schema 简练得多，Schema 定义则显得繁复冗长。所 以 DTD 更适合面向文档的应用，而 Schema 则同时适合面向文档和面向数据的应用。因为 Schema 的格式定义很烦琐，所以有人开发了其它的格式定义方法，其中比较有前途的是 69 RELAX NG。RELAX NG 是一种以 RELAX（由日本人开发）与 TREX（由 XML 界的权威 James Clark 开发）为基础的模式语言。它的基本思想与 Schema 相同，也采用 XML 格式，所以程序处理 起来也很方便，而且它的语法比 Schema 要简单得多。但是目前 RELAX NG 还不是 W3C 的标 准，所以大多数解析器都不支持。不过 Schema 可能会在以后参考 RELAX NG 而得到简化， 所以我们还是应该更多地使用 Schema。 3.3.3 XML 显示 XML 的设计目标就是把内容与显示方式分离开。那么显示格式用什么来定义呢？有两种 方式，CSS（Cascading Style Sheets，层叠样式表）和 XSLT（Extensible Stylesheet Language——Transformation，可扩展样式单语言转换部分）。XML 页面要在浏览器中显示 必须结合 CSS 或者 XSLT 样式单。 现在流行的显示格式是 XSLT，原因与 Schema 一样，XSLT 是 XML 格式的，便于程序处理。 XSLT 是参考 SGML 中的 DSSSL（Document Style Semantics and Specification Language， 文档样式语义和规范语言）而设计的，最初叫做 XSL，但是后来 W3C 发现工作量实在太大 就分成了两个规范：XSLT 和 XSL:FO。XSLT 很快就作为正式规范推出了，主要是面向转换 应用的。XSL:FO 主要面向精确的格式定义（例如 PDF），正式规范才推出不久。目前 XSLT 已经进入了实用阶段。 XSLT 其实不完全是为显示而设计的，XSLT 的主要作用是将 XML 由一种格式转换为另 一种格式，例如由 XML 的一种词汇表转换为另一种词汇表，或者由 XML 转换为 HTML 或者 XHTML，便于在浏览器中显示。现在 IE 和 Mozilla 都可以很好地支持 XSLT。 XSLT 转换可以在服务器端实现，也可以在浏览器端实现。 3.3.4 XML 格式元数据的实现 目前的大型数据库都是 XML 加关系模型数据库，因此 XML 数据的存取没有任何技术障碍。 Oracle 9i R2 中引入了高性能的本地 XML 数据管理技术 XML DB，提供 XML 文件的整体及分 节点存储，Oracle 10g 包含了对 XML Query（XQuery）标准的支持。在 ORACLE 9i 数据库中 实现 XML 元数据存储的具体实现过程如下： （1） 根据标准中拟定的元数据包 UML 类图编写 XML Schema，目前有多种软件支持 XML Schema 的设计，Altova 的 XMLSpy（http://www.xmlspy.com）就是一个 70 很好的 XML 可视化编辑软件； （2） 在数据库中注册 XML Schema，创建对象类型； （3） 创建存储元数据的数据库数据表，并将其中一列的数据类型定义为 XMLTPYE 对 象类型，用于存储 XML 元数据文件。XMLTPYE 列提供了结构化和非结构化两种 存储方式，非结构化 XMLTYPE 中的 XML 文档以大对象存储，对于结构化 XMLTYPE 中的 XML 文档 Oracle 会以优化方式自动进行解析和存储，结构化存储方式利 于分节点的查询。定义时系统会问你是否需要合法性检验，如果选择合法性检 验，每当 XML 元数据加载时，数据库会自动根据已注册的 XML Schema 检测其 合法性与有效性； （4） 创建符合 XML Schema定义的 XML 文件框架，用于具体资源对象的元数据著录， 最好能编制与标准配套的元数据编辑器，由软件自动生成 XML 元数据文件，以 方便元数据著录； （5） 设计一个或多个 XSLT 样式单，加载到服务器端，使 XML 元数据能以设定的样 式显示元数据内容，XSLT 样式单也同样可以用 Altova 的 XMLSpy 编写； (注： XSLT 样式转换也可以在浏览器端实现，从实际使用情况看，由于元数据文件 比较小，加之 Oracle 的 XML 数据处理快，感觉不到有任何性能影响。在服务 器端实施 XSLT 样式转换更灵活，因此最好选择在服务器端实施样式转换。) （6） 著录具体资源对象的 XML 元数据，然后加载到已创建的数据表中，XML 元数据 存储即告完成。 3.4 元数据编辑器 元数据是一种多层嵌套的多节点树状结构数据，一般电子表格难以组织此类数据，因此 元数据编辑器就显得十分必要。图 3.2 是与“海洋地质调查与研究元数据内容”标准配套的 “海洋地质元数据编辑器”界面，可用于海洋地质调查与研究元数据的内容编辑及 XML 元数 据文件生成。 71 图 3.2 一个元数据编辑器主界面 3.5 一个元数据样式显示的核心元数据 下表是采用核心元数据样式 Core.xsl 在浏览器端显示的核心元数据： 标题 1:100 万南通幅海洋区域地质调查 2005 年多道地震数据采集 编号 NTF08-FD7-2005-01 提交日期 20051220 提交单位 青岛海洋地质研究所区域地质室南通幅区调项目组 语种 中文 标识 字符集 GB2312 72 摘要 本数据集为 1:100 万南通幅海洋区域地质调查 2005 年多道地震剖面数据，由上海海洋石油局第一海洋地质 调查大队奋斗七号执行施工。共 6 条多道地震测线：4 条南北向 NT05-1～NT05-3、NT05-6，2 条东西向 NT05-4、NT05-5，测线工作量 1727.5 公里，同步作单频水深测量。数据集内容包括炮点定位数字记录及炮 点同步水深测量数据（定位炮点数 34766，炮点距 50 米）、多道地震剖面外业信息、多道地震叠加剖面及偏 移剖面扫描图像、和叠加速度分析结果数据（每 1km 拾取一个速度谱）。 主题类别 地质调查 物探 数据类别 多道地震 单波束测深 空间表示类型 矢量 表格 类别 比例尺 1: 1000000 项目名称 2005 年 1:100 万南通幅海洋区域地质调查——多道地震数据采集 项目编号 200211000001——FD7-2005 起始日期 20050914 完成日期 20051220 实施单位 青岛海洋地质研究所区域地质室 上海海洋石油局第一海洋地质调查大队 华北煤层气勘察开发总公司第四物探大队 负责人 张志珣、王强、景新义 项目 主要成员 杜万兴、罗鹰、陈红星、顾兆峰、侯方辉、闫立志、郭晓滨、许冬梅 地理名称 南黄海 西端经度 121.466 东端经度 124.484 南端纬度 32 区域 北端纬度 36.015 工作平台 奋斗七号调查船 设施 仪器设备 星站差分 StarFire-2050G/M GPS 双频 RTG 接收机 SYNTRAK-480 地震数据记录系统 SLEEVE 空气枪组合震源 LDA 电缆 PROMAX 现场处理系统 DESO20 回声测深仪 数据志 野外施工按照“1：100 万南通幅海洋区域地质调查项目”多道地震外业数据采集合同、“1：100 万南通幅海 洋区域地质调查项目”多道地震数据采集施工设计、上海石油海洋局第一海洋地质调查大队 ISO 质量管理体 系文件及 SMS 安全管理体系文件执行。施工工序： 1）仪器测试与试验：包括 SPERRY MK37 作业罗径校 正，SF 2050G/M GPS RTG 接收机静态定位精度测试，SYNTRAK-480 记录仪月检、日检测试，SERCEL-LDA 数字电缆平衡调试，震源和电缆沉放深度试验，偏移距测试，SC-IVA 测深仪检验等。 2）导航定位：采用 73 高精度星站差分 SF 2050G/M GPS 双频 RTG 接收机为主导航，V5.3.0 版本的 GEOFIX 软件为综合导航系统， 采集、计算和控制各外部设备同步运行，进行外业导航定位。DGPS 定位中心由 GEOFIX 综合导航软件统一 归算到震源中心，离 GPS 天线距离为 62.91 米，方位（船艏向为 0°，按顺时针方向记数）为 180.11°。等距 离控制放炮，同时 GEOFIX 将 GPS 位置数据等记录在磁盘上。原始记录的炮点距 50 米，炮点纬度采用 DD°MM′SS.SSS″格式，记作 DDMMSS.SSS；炮点经度采用 DDD°MM′SS.SSS″格式，记作 DDDMMSS.SSS。 3）多道地震作业：资料采集作业原则是先东后西，先深后浅；航速和航向保持稳定，航速要求 5kn 左右， 船只偏离测线超出规定范围时，要及时缓慢修正，修正率不得大于 2 度/公里；到达测线前 2km 处使电缆拉 直，到达测线终点后，船只继续保持航向工作，延续距离等于半个排列长度；航线偏离设计测线不得大于 200 米；组合气枪总容量不低于规定值 80%，声压不小于 90%，整条测线空废炮率小于 6%，不正常工作道 不超过总道数的 1/24。 4）多道地震数据采集：外业地震数据由 SYNTRAK-480 地震数据记录系统记录，采 集因素如下：记录系统： SYNTRAK-480；震源系统：SLEEVE 空气枪；炮间距：50 米；道间距：12.5 米； 记录道数：240 道；采样率：2 毫秒；记录长度：6 秒；平均最小偏移距：200.42 米； 记录格式：SEG-D， 8015；滤波档位：3HZ/6DB/OCT，218HZ/484DB/OCT；滤波延迟：32 毫秒；电缆沉放深度：9 米；震源沉 放深度：7 米；平均水速：1527 米/秒。 5）质量保证系统：采用 ProMAX 处理系统，系统在现场进行基本 的预处理流程处理，处理至初迭，包括噪音分析。预处理后的资料是资料质量保证的手段之一。 6）水深测 量：多道地震测量同步进行高精度回声测深测量，测深系统为数字系统，精度满足 IHO 标准。 参照系 大地坐标系 WGS84 网址 http://www.qimg.com.cn 资源名 测线位置图、数据表及地震剖面图 发布 数据格式 ArcGIS SHP 8.2 Mapinfo 6.0 Microsoft Excel 2000 Microsoft Access 2000 文件编号 MD-NTF08-FD7-2005-01 提交日期 20070205 发布单位 青岛海洋地质研究所信息资料室 采用标准 海洋地质调查与研究元数据内容标准 元数据 标准版本 1.0 3.6 一个元数据样式显示的完整元数据 同一个 XML 元数据文件采用不同的样式可以有不同的显示结果，下面是采用另一个元数 据样式 chinese.xsl 显示的完整元数据。 74 1:100 万南通幅海洋区域地质调查 2005 年多道地震数据采集 摘要：本数据集为 1:100 万南通幅海洋区域地质调查 2005 年多道地震剖面数据，由上海海洋石油局第一 海洋地质调查大队奋斗七号执行施工。共 6 条多道地震测线：4 条南北向 NT05-1～NT05-3、NT05-6， 2 条东西向 NT05-4、NT05-5，测线工作量 1727.5 公里，同步作单频水深测量。数据集内容包括炮点定 位数字记录及炮点同步水深测量数据（定位炮点数 34766，炮点距 50 米）、多道地震剖面外业信息、多 道地震叠加剖面及偏移剖面扫描图像、和叠加速度分析结果数据（每 1km 拾取一个速度谱）。 关键词: 南黄海，多道地震 • 编目信息 • 数据质量信息 • 空间参照系信息 • 内容信息 • 发布信息 • 元数据信息 编目信息 标识 标题: 1:100 万南通幅海洋区域地质调查 2005 年多道地震数据采集 系列 系列名: 1:100 万南通幅海洋区域地质调查 系列号: I51A 日期 日期: 20051220 日期类型: 提交 编号: NTF08-FD7-2005-01 出处 单位: 青岛海洋地质研究所区域地质室南通幅区调项目组 职责: 数据供方 载体类型: 电子地图 载体类型: 电子表格 载体类型: 电子图像 摘要: 本数据集为 1:100 万南通幅海洋区域地质调查 2005 年多道地震剖面数据，由上海海洋石油局第一 海洋地质调查大队奋斗七号执行施工。共 6 条多道地震测线：4 条南北向 NT05-1～NT05-3、NT05-6， 2 条东西向 NT05-4、NT05-5，测线工作量 1727.5 公里，同步作单频水深测量。数据集内容包括炮点定 位数字记录及炮点同步水深测量数据（定位炮点数 34766，炮点距 50 米）、多道地震剖面外业信息、多 道地震叠加剖面及偏移剖面扫描图像、和叠加速度分析结果数据（每 1km 拾取一个速度谱）。 目的: 采用长排列、大容量震源地震采集技术，获得能量强、信噪比高的深部地层地震反射资料 75 状态: 已完成 联系信息 单位: 青岛海洋地质研究所 职责: 数据管理 联系方式 联系地址 国家: 中国 省: 山东 市: 青岛 地址: 福州路 62 号 邮政编码: 266071 在线链接 网址: http://www.qimg.cgs.gov.cn 空间表示类型: 矢量 空间表示类型: 表格 空间分辨率 比例尺: 1:1000000 语种: 中文 字符集: GB2312 主题类别: 地质调查 主题类别: 物探 数据类别: 多道地震 数据类别: 单波束测深 时空范围 总体描述: 研究区位于我国南黄海海域，地理坐标为北纬 32°～36°，东经 120°～126°。按国 际分幅，图幅编号为 I51A，为一标准百万分之一图幅。该图幅的南北宽度约为 443.93 公里，南部边 界的东西长度约为 567.08 公里，北部边界的东西长度约为 541.07 公里，总面积约为 246200 平方 公里，其中海域面积约为 225000 平方公里，约占图幅总面积的 91.4%，陆地和岛屿面积约为 21200 平方公里，占图幅总面积的 8.6% 。陆区分布在图幅的左上角和左下角，分别为山东省青岛市及江苏 省南通和盐城两市的沿海市镇。岛屿有图幅北部的灵山岛、大公岛等六个中方岛屿及图幅东部的大黑 山岛、小黑山岛等三十余个韩方岛屿。 覆盖区域 位置描述 地理名称: 南黄海 地理范围 西端经度: 121.466 ° 东端经度: 124.484° 南端纬度: 32° 北端纬度: 36.015° 本机环境: Win2000 Server,Oracle 9i,ESRI ArcSDE 8.2 示意图 76 关键词 关键词: 南黄海 类别: 地点 关键词 关键词: 多道地震 类别: 主题 注意事项 使用注意: NT05-4 线，炮点 16110～17225 段为反向减计数施工，使用炮点定位数据时加以注意。 使用注意: 炮点定位数据表中的缺失水深值用“9999”表示。 访问限制: 需要授权 使用限制: 需要授权 其他限制: 访问或下载数据需要申请授权，未经授权的只能浏览元数据。 项目 名称: 2005 年 1:100 万南通幅海洋区域地质调查——多道地震数据采集 编号: 200211000001——FD7-2005 起始日期: 20050914 完成日期: 20051220 实施单位: 青岛海洋地质研究所区域地质室 实施单位: 上海海洋石油局第一海洋地质调查大队 实施单位: 华北煤层气勘察开发总公司第四物探大队 负责人: 张志珣、王强、景新义 主要成员: 杜万兴、罗鹰、陈红星、顾兆峰、侯方辉、闫立志、郭晓滨、许冬梅 说明: “1:100 万南通幅海洋区域地质调查”是中国地质调查局于 2000 年启动的地质大调查项目， 南通幅是黄东海海域百万区调的第一个图幅，由青岛海洋地质研究所区域地质室负责实施。2002 年 开始项目作为实施项目“我国海域 1:100 万海洋区域地质调查示范”下的一个工作内容继续实施，项 目名称为“1:100 万南通幅海洋区域地质调查示范”（工作项目编号 200211000001）。上海海洋石 油局第一海洋地质调查大队(乙方)受青岛海洋地质研究所区域地质室(甲方)委托，负责完成 1:100 万 南通幅海洋区域地质调查项目 2005 年度工作设计中的多道地震数据采集任务，华北煤层气勘察开发 77 总公司第四物探大队计算研究所承担本次多道地震资料处理任务。共布设多道地震测线 5 条，南北向 3 条 NT05-1～NT05-3，东西向 2 条 NT05-4、NT05-5，设计测线长度为 1736.2km。 航次 名称: 奋斗七号 2005 年第一航次 起始日期: 20050914 完成日期: 20051012 实施单位: 上海海洋石油局第一海洋地质调查大队 负责人: 王强 主要成员: 杜万兴、罗鹰、陈红星 说明: 本航次自 2005 年 9 月 14 日上午 10：00 奋斗七号离开国家海洋局东海分局码头开始，至 10 月 12 日返回国家海洋局东海分局码头结束，共计 29 天。共完成了南通幅多道地震外业采集项目中多 道地震 1727.5 公里，水深测量 1727.5 公里。 作业平台 名称: 奋斗七号 类型: 调查船 简介: 船长：50.29 米；型宽：11.20 米；型 深：3.66 米；满载排水量：950 吨；主 机 型 号：CAT-D398 ×2，功率 1124.60 千瓦（562.30×2 千瓦）；辅机：WTA-14-G1 345×2；发电机：IFC-5 352-4TA45 200KW×2， 60HZ。 仪器设备 名称: 星站差分 StarFire-2050G/M GPS 双频 RTG 接收机 生产厂家: 美国 NAVCOM 公司 技术指标: StarFire 定位精度(RMS)：水平〈15cm，高程〈30cm，速度精度 0.01m/s。 工作参数: 使用 V5.3 版本的 GEOFIX 软件为综合导航系统,，进行外业导航定位。DGPS 定位中心由 GEOFIX 综合导航软件统一归算到震源中心，离 GPS 天线距离为 62.91 米，方位（船艏向为 0°， 按顺时针方向记数）为 180.11°。等距离（投影到测线）控制放炮；同时 GEOFIX 将 GPS 位置数 据等记录在磁盘上。 安装位置: GPS 天线位于奋斗七号船的最高点，距船尾 27 米。 仪器设备 名称: SYNTRAK-480 地震数据记录系统 生产厂家: 美国 SYNTRON 公司 技术指标: 包括：MSTP 多电缆遥控处理单元；MSRS 多电缆记录单元；SYNTRAK 采集数字包， 16bit、24db；SYNTRAK 数据传输包，16bit；IBM3590 磁带机，记录密度 10G；OYO624 绘图 仪； SYNTRAK-480 系统将从电缆上传输进来的数据包括地震数据、水鸟罗盘数据、电缆深度数据 等记录在地震磁带上；GCS90 实时打印气枪数据并同时记录在磁盘上。 工作参数: 多道地震数据采集参数：道间距 12.5m ；炮间距 50m；电缆工作段总长度 3000m ； 道数 240 ；覆盖次数 30 ；采样率 2ms ；记录长度 6sec ；最小偏移距 200m ；电缆沉放深度 9 m；记录格式 SEG-D，8015； 滤波档位 3Hz/6db/oct， 218Hz/484db/oct ；滤波延迟 32ms 。 仪器设备 名称: SLEEVE 空气枪组合震源 工作参数: 震源类型：单震源枪串；数量：2； 气枪个数：18； 震源频谱宽度： 6-94 Hz； 震源 波泡比：23.3（测试深度 6m 时）；震源峰峰值：86.5（测试深度 6m 时）；震源总容量：2940 cu in； 气枪压力 2000 P.S.I ；震源沉放深度：7 米；等距离控制放炮，炮间隔 50 米。 仪器布置图: 78 仪器设备 名称: LDA 电缆 生产厂家: 美国 SERCEL 公司 技术指标: 地震数据接收系统，由甲板电缆（1 段）、前导缆（1 段，200m）、艏部弹性段（2 段）、 工作段（40 段）、艉部弹性段（1 段）、尾标组成。电缆上装配 13 只电缆罗盘/定深器，由 Digicourse SYS-3 型电缆深度控制系统进行控制。 工作参数: 电缆工作段每段长 75m，共 40 段，电缆总长 3000m。道间距 12.5m ；道数 240 ； 覆盖次数 30 。 安装位置: 电缆沉放深度 9 米；最小偏移距 200m。 仪器布置图: 仪器设备 名称: PROMAX 现场处理系统 生产厂家: 美国 Landmark 公司 技术指标: ULTRA-80：450Hz UltraSPARC-II CPU X 2，主机硬盘容量：108G。 工作参数: 该系统在现场进行基本的预处理流程处理，处理至初迭，包括噪音分析。预处理后的资料 是资料质量保证的手段之一。 仪器设备 名称: DESO20 回声测深仪 生产厂家: 德国 ATLAS 公司 技术指标: 探测深度：0-2000 米；探头频率：25 kHz；精度：0.4%水深。 工作参数: 水深值记录在定位数据盘上（数字）和模拟记录纸上。 安装位置: DGPS 天线后方 5m 处，固定在船左舷。 相关数据集 数据集标识 标题: 1:100 万南通幅海洋区域地质调查 2003 年单道地震数据采集 系列 79 系列名: 1:100 万南通幅海洋区域地质调查 系列号: I51A 日期 日期: 20030807 日期类型: 提交 编号: NTF07-FD4-2003-01 出处 单位: 青岛海洋地质研究所区域地质室南通幅区调项目组 职责: 数据供方 关联类型: 参照关系 相关数据集 数据集标识 标题: 1:100 万南通幅海洋区域地质调查 2005 年单道地震数据采集 系列 系列名: 1:100 万南通幅海洋区域地质调查 系列号: I51A 日期 日期: 20050727 日期类型: 提交 编号: NTF07-FD7-2005-01 出处 单位: 青岛海洋地质研究所区域地质室南通幅区调项目组 职责: 数据供方 关联类型: 参照关系 Back to Top 数据质量信息 质评对象 数据级别: 数据集 数据志 综述: 野外施工按照“1：100 万南通幅海洋区域地质调查项目”多道地震外业数据采集合同、“1： 100 万南通幅海洋区域地质调查项目”多道地震数据采集施工设计、上海石油海洋局第一海洋地质调 查大队 ISO 质量管理体系文件及 SMS 安全管理体系文件执行。施工工序： 1）仪器测试与试验：包 括SPERRY MK37作业罗径校正，SF 2050G/M GPS RTG 接收机静态定位精度测试，SYNTRAK-480 记录仪月检、日检测试，SERCEL-LDA 数字电缆平衡调试，震源和电缆沉放深度试验，偏移距测试， SC-IVA 测深仪检验等。 2）导航定位：采用高精度星站差分 SF 2050G/M GPS 双频 RTG 接收机 为主导航，V5.3.0 版本的 GEOFIX 软件为综合导航系统，采集、计算和控制各外部设备同步运行， 进行外业导航定位。DGPS 定位中心由 GEOFIX 综合导航软件统一归算到震源中心，离 GPS 天线距 离为 62.91 米，方位（船艏向为 0°，按顺时针方向记数）为 180.11°。等距离控制放炮，同时 GEOFIX 将 GPS 位置数据等记录在磁盘上。原始记录的炮点距 50 米，炮点纬度采用 DD°MM′SS.SSS″格 式，记作 DDMMSS.SSS；炮点经度采用 DDD°MM′SS.SSS″格式，记作 DDDMMSS.SSS。 3） 多道地震作业：资料采集作业原则是先东后西，先深后浅；航速和航向保持稳定，航速要求 5kn 左右， 船只偏离测线超出规定范围时，要及时缓慢修正，修正率不得大于 2 度/公里；到达测线前 2km 处使 电缆拉直，到达测线终点后，船只继续保持航向工作，延续距离等于半个排列长度；航线偏离设计测 80 线不得大于 200 米；组合气枪总容量不低于规定值 80%，声压不小于 90%，整条测线空废炮率小于 6%，不正常工作道不超过总道数的 1/24。 4）多道地震数据采集：外业地震数据由 SYNTRAK-480 地震数据记录系统记录，采集因素如下：记录系统： SYNTRAK-480；震源系统：SLEEVE 空气枪； 炮间距：50 米；道间距：12.5 米；记录道数：240 道；采样率：2 毫秒；记录长度：6 秒；平均最 小偏移距：200.42 米； 记录格式：SEG-D ， 8015 ；滤波档位：3HZ/6DB/OCT ， 218HZ/484DB/OCT；滤波延迟：32 毫秒；电缆沉放深度：9 米；震源沉放深度：7 米；平均水速： 1527 米/秒。 5）质量保证系统：采用 ProMAX 处理系统，系统在现场进行基本的预处理流程处理， 处理至初迭，包括噪音分析。预处理后的资料是资料质量保证的手段之一。 6）水深测量：多道地震 测量同步进行高精度回声测深测量，测深系统为数字系统，精度满足 IHO 标准。 数据处理 目的: 二维多道地震资料处理 内容: 在《1:100 万南通幅海洋区域地质调查示范处理技术设计》的要求基础上，进行了系统的 处理流程、参数试验。依照 SY/5332-92《二维地震勘探资料常规处理技术规程》、SY/5482-92 《地震勘探资料处理质量检验细则》等行业标准要求，制定了 1:100 万南通幅海洋区域地质调查 示范处理多道地震测量工作处理项目的批处理流程：数据解编→几何定义→道编辑→带通滤波→ 倾角滤波→振幅补偿→串联预测反褶积→F-K 域多次波压制→速度分析→炮集 DMO→速度分析 →动校正→水平叠加→剩余振幅补偿→叠后去噪→带通滤波→叠加成果输出；剩余振幅补偿→偏 移→偏移后去噪→带通滤波→偏移成果输出。数据处理的关键在于四个环节：1）数据净化：目的 是提高原始数据的信噪比，充分利用多系统便利的交互功能逐炮、逐道进行检查，剔除坏炮、干 扰道；根据对原始资料详细的频谱分析，选取合理的手段、处理参数来压制高、低频干扰，突出 有效反射，将商船、涌浪噪音、浅滩流网等因素对资料的影响降至最低。 2）子波处理：在兼顾 信燥比的原则下，合理选择算子长度、预测步长、相关道数、白噪系数等反褶积参数，在不同构 造单元边缘设立空变控制点，以求得到满意的反褶积处理效果。 3）多波次消除：针对本区海洋 地震资料多波次发育的特点，充分研究多波次的周期性及其有效波在速度、t-p 域和 f-k 域的差 异，采用多道识别、单道处理的方法进行预测、压制，避免多波次压制过程中混波、假频等副作 用。 4）偏移归位：加强偏移方法的试验、对比，精心进行偏移速度的选择，力求得到最佳偏移 效果。详细处理过程可参见，“1:100 万南通幅海洋区域地质调查示范 2005 年度调查研究报 告”。 日期: 20051020 处理者 单位: 华北煤层气勘察开发总公司第四物探大队物探研究院计算研究所 人员: 闫立志、冯永强、郭晓滨、许冬梅、魏文成 职责: 数据处理 数据质量 质量综述 质评依据: 中国地质调查局地质大调查项目外业调查原始资料验收规定 质评依据: 1：100 万南通幅区域海洋地质调查项目多道地震外业数据采集施工设计书 质评依据: 多道地震数据采集委托合同 质评依据: 多道地震数据处理委托合同 质评方法: 2005 年 10 月 14 日，中国地质调查局组成验收组在上海对多道地震测量野外资料采 集工作进行验收。2005 年 12 月 20 日，对多道地震资料处理工作进行验收。 质量评述: 资料采集：1）项目组根据任务需求，通过现场试验所选择的施工参数合理；投入使用 的仪器设备性能指标、日常检验合格。 2）该航次各项测量施工资料齐全，班报记录清楚。 3） 采集的资料均符合技术设计要求。 4）质量管理体系健全，保证措施落实。经验收组评定，本次 81 野外工作质量评分为 94.4 分，评定等级为优秀级。验收组同意通过验收。资料处理：完成二维 多道地震常规处理 1727.5km，提交处理报告、偏移剖面、叠加剖面、速度谱等，得分 92.4， 为优秀级。 完整性 评述: 由于渔船、渔网干扰，外业共完成南通幅多道地震 1727.5 公里，同步水深测量 1727.5 公里，比原设计 1736.2 公里少了 8.7 公里。室内完成二维多道地震常规处理 1727.5km，提交 了叠加剖面及偏移剖面，速度谱每 1km 拾取一个。 位置精度 评述: 由于使用星站差分 GPS，施工过程中差分信号状态良好，施工导航质量很好。因原设计测 线穿越浅滩区，作业难度大，安全系数低等诸多因素，在控制构造的前提下，与甲方协商，部分 测线作如下调整：1）NT05-2 测线向东平移 12′，将原测线端点修改为 32°00′N、122° 22′E，36°00′N、122°22′E；2）NT05-1 和 NT05-5 两条测线的浅水段无法施工，其 剩余工作量改在 NT05-6 上实施，该测线的端点坐标为：33°45′N、123°20′E，36°00′ N、123°20′E。 专题精度 评述: 1）多道地震测量时，信号发射、记录数据正常，仅部分测线受过往商船影响，噪音偏大一 点。少量测线电缆羽角超过 15°，但均小于 18°。 2）多道地震处理采用 2ms 采样，处理长 度 6 秒，速度谱每 1km 拾取一个。处理过程采用了最新的处理技术，合理的流程及参数进行叠 前叠后的去噪、能量补偿、压制多次波、子波处理及偏移速度场重构与偏移处理，最终成果达到 了预定的技术指标。 3）在选定的地震测线进行了有针对性的、不同的处理模块和参数的效果对 比试验，注意提高浅、中、深层反射波组的信噪比和分辨率，同时保持地层地震反射特征。各种 反褶积模块使用正确，参数合理，使剖面分辨率得到明显提高，在最终的成果数据上，新生界地 震反射波的主频达到 40Hz、中生界地层地震反射波的主频不低于 30Hz，前中生界层地震反射波 的主频不低 20Hz。 4）采用有效的处理技术压制多次波，尤其是海底多次波，叠前、叠后合理 使用各种去噪处理手段，压制水鸟道附近干扰波及低、高频随机、线性干扰，使剖面中的各种干 扰波得到很好的压制，突出了有效反射。 5）处理中尽力改善深部基底波的质量，获取的主要反 射波组特征清晰，使新生界、中生界和古生界地层在地震剖面上得到较为清晰的反映。剖面地层 地震反射特征突出，正确地反映了地层的接触关系和赋存状态，满足地震相解释和层位标定、追 踪的要求。地震剖面反映的盆地结构清晰，凹陷和隆起的边界清楚；断层的断点清楚。 6）地震 剖面反映的地质构造及断层等地质现象清楚可靠，偏移方法正确、偏移速度合理。在偏移地震剖 面上，水平层、倾斜层以及绕射波迴转波都能很好地聚焦成像，基底特征明显，剖面的信噪比较 高；断点清晰，断面波归位正确，并尽量消除了偏移剖面的画弧现象。 Back to Top 空间参照系信息 大地坐标系: WGS84 Back to Top 内容信息 内容说明 文件标识 标题: 1:100 万南通幅海洋区域地质调查 2005 年多道地震数据集内容说明 版本: 1.0 82 日期 日期: 20070205 日期类型: 提交 文件名: FC-NTF08-FD7-2005-01.HTML Back to Top 发布信息 数据格式 格式: ArcGIS SHP 版本: 8.2 数据格式 格式: Mapinfo 版本: 6.0 数据格式 格式: Microsoft Excel 版本: 2000 数据格式 格式: Microsoft Access 版本: 2000 传输介质 在线资源 网址: http://www.qimg.com.cn 资源名: 测线位置图、数据表及地震剖面图 资源说明: 可申请，经数据供方同意后在线浏览电子地图、电子表格及地震剖面扫描图像 获取方式: 在线访问 在线资源 网址: http://www.qimg.com.cn 资源名: Excel 与 Access 格式的数据表、SHP 与 Mapinfo 格式的测线位置图。 资源说明: 可申请，经数据供方同意后下载打包文件。打包文件中不包括地震剖面扫描图像 （530MB），需要扫描图像的可在线浏览时下载，或与数据库管理员联系。 获取方式: 在线下载 离线介质 介质类型: 8 毫米盒式磁带 卷数: 25 介质说明: 多道地震原始磁带共 25 盘，记录格式 SEG-D，8015，存青岛海洋地质研究所资料 档案室，档号：地 72-47。 离线介质 介质类型: 8 毫米盒式磁带 卷数: 15 介质说明: 多道地震资料处理常规处理、偏移处理成果数据与地震原始数据转录成果带，共 15 盘，记录格式 SEG-Y，存青岛海洋地质研究所资料档案室，档号：地 72-34。 Back to Top 元数据信息 83 文件编号: MD-NTF08-FD7-2005-01 语种: 中文 字符集: GB2312 联系信息 单位: 青岛海洋地质研究所信息资料室 职责: 数据发布 提交日期: 20070205 标准名称: 海洋地质调查与研究元数据内容标准 标准版本: 试用 Back to Top 国土资源部地质调查局青岛海洋地质研究所 84 4 应用架构设计 应用架构设计包括两部分：功能架构设计和技术架构设计，功能架构是面向用户的架构， 是系统需要实现的功能；技术架构是面向开发的架构，简单地说是系统的编码架构，涉及应 用系统的层次结构以及采用的技术手段。 常见的三层模型技术架构是将应用组件组织成用户服务层、业务服务层、以及数据服务 层。Rebecca M.Riordan 针对数据库应用的特殊需求，在其《Designing Effective Database Systems》一书中提出了四层模型，如图 4.1。其中用户界面层对应用户服务层，负责与用户 的交互，包括通过窗体对象与用户交互、响应窗体对象的状态变化、以及初始化需求等。数 据界面层负责数据的有效性检验、格式化、以及数据缓存。事务界面层负责业务逻辑的构造， 也就是负责查询的构造与初始化，但不负责执行。具体执行由外部访问界面层负责，这一层 的代码组件处理与数据库引擎的交互，它们执行查询并将结果或错误信息返回给组件。 图 4.1 四层架构模型 （Rebecca M.Riordan 《Designing Effective Database Systems》） 85 至于技术手段，我个人认为应充分利用数据库自身的功能，如果某些功能可以在数据库 端高效实现，干吗不充分利用数据库自身的功能就地解决，而舍近求远移动到应用端呢？从 目前来看，现在做数据库开发的很少关心后台数据库是什么，大部分功能都是在应用端实现 的，这样开发速度很快，但不利于后期的扩展。 在功能架构方面，一般的科研领域数据库可能会面对三类用户： （１） 数据管理用户，这里的数据管理用户不是指 DBA（数据库系统管理员），而 是管理自己数据的用户，他们有权上载、修改、更新自己的数据，也应该有 权把自己数据的访问权限分配给别人，这就是所谓的多方数据管理。实现多 方数据管理，需要数据库系统管理方提供相关专业数据的数据管理平台，或 通用的数据交换格式，如美国国家地球物理数据中心（NGDC）的 MGD-2000 数据交换格式（http://www.ngdc.noaa.gov/mgg/dat/geodas/docs/mgd2000.htm）。 从我这几年数据库工作经历看，如果想把数据库做好做大，多方数据管理是 一条出路，这样能让数据生产方对自己的数据负责，假如数据中有质量问题， 他们也比较容易找到原因并予以修正，因为他们是数据的主人；而数据库系 统管理方只需要提供一个数据共享的平台，能把精力主要放在数据服务上， 提供更好的服务，而不是成天做数据的二次处理（现在的数据基本上都是在 由数据生产单位提交给数据中心，数据中心的工作人员负责数据规范化处理 及入库）。 （２） 专业用户，本系统的专业人员用客户端专业软件如 ArcGIS，Execl 等直接访 问数据库数据。 （３） 外部 WEB 用户通过浏览器访问数据。 做功能架构设计时应充分考虑这三方用户的应用需求，让数据库数据真正有进有出，能 顺畅流动起来。但从目前情况看，要实现这一步仍需要时间。下面介绍一个数据库的应用架 构实例，这个数据库是荷兰国家地质信息系统 DINO（Data and Information of the Netherlands Subsurface）。DINO 门户的网址为 http://dinolks01.nitg.tno.nl/dinoLks/DINOLoket.jsp。所涉及 的信息均来自 2003 年底的资料，注意可能被修订或更新的可能性。 4.1 DINO 生存环境 荷兰的数据库建设工作开展得较早,七十年代荷兰地调局下属的海洋地质与海岸带部就 86 开发了基于 UNIX 的 IMKMG 系统，提供海洋区调数据的管理与应用。八十年代就基本实现了 海洋区调的全过程信息化，其中一个典型的例子是地质取芯档案管理系统（Archive management system）。通过该系统可以追踪地质样品的采集、包装、标注、运输、保存、分 析全过程，以及所有过程中产生的数据记录。这些项目级及部门级的数据库为后来的 DINO 数据库建设打下了良好的基础。 荷兰国家地质信息系统 DINO 于 1997 年提到建设日程上，由荷兰地质调查局暨荷兰应用 地学研究所（TNO-NITG）负责项目实施，软件平台选择 Oracle 和 ArcInfo。1998 年 DINO 进入正式开发阶段，数据模型设计及应用开发同步进行，1999 年底第一阶段工作结束，完 成了钻孔、岩性及岩土工程参数数据模块的设计与数据管理系统的开发。2000 年进入第二 工作阶段，继续 DINO 系统的扩展。到 2003 年底，DINO 数据库系统已初具规模，建立了定 位数据模块、参数数据模块、地下水数据模块、地质资料数据模块、钻孔数据模块及岩性数 据模块，应用服务实现了每个模块的数据维护管理，以及 Web 在线服务。 DINO 的目标为： （１） 建立国家级数据中心，为政府部门、水董会、咨询公司、大学及个人提供地 质信息服务，使地质信息数据得到最有效的利用； （２） 应用“一站式服务”（one-stop-shop）模式，使基础地质信息的公众服务变得 更加简单、透明； （３） 数据集中管理，简化地质公司之间的数据分发过程。 据荷方介绍，DINO 的建立使公众、数据供方、政府及国家都从中获益。荷兰地调局 2001 年鉴显示，荷兰地调局 2001 年的总收入 3200 万欧元，其中地质信息收入在 12 个调查方向 中占 39%，达到了 1248 万欧元。 DINO 能在短期内走上轨道有其得天独厚的有利条件： (1) 国家制订了相关法律条文保障数据的公有化。荷兰法律规定数据生产方最多有 5 年的数据专有权，之后一律归国家所有。这为数据的集中管理与共享创造了有利条 件。 (2) 有一套完善的规范标准保证工作流程的数字化。数字化落实到数据采集、分析和成 果提交的全过程，数据生产过程也是数据库建设过程，工作结束数据库也同时完成， 不需要数据二次处理，数据一致性也很好。 87 (3) 从国家、单位到专业人员都对数据库很重视。国家及部门把数据当作资源来管理， 专业人员把数据提交数据库作为自己工作的一部分。他们的工作导向是原始数据要 求完整提交数据库，文字报告及图件只要能满足当前需要就行，讲求实用易懂，图 4.2 反映了他们对这方面的认识。 图 4.2 荷兰人画的 More is less & Less is more 4.2 DINO 设计目标 DINO 架构设计目标分为以下五个方面： （1） 用户第一，支持不同用户层的数据服务是首要设计目标。因此，DINO 系统 必须能支持不同数据服务系统的开发，同时要求不同的数据服务系统保持统 一的界面风格及操作方式，让数据管理与数据服务简单化。 （2） 安全第二，支持不同用户层的数据访问控制。授权数据访问可控制到行、列 级，专业人员允许通过 Excel、Access 或 ArcView 等第三方软件访问数据。 （3） 尽量减少对第三方产品的依赖性。因为 DINO 开发需要多年时间，DINO 的 使用时间可能更长，在此期间什么情况都可能发生，技术会不断更新，第三 方公司有可能倒闭，而 DINO 不可能推倒重来。 （4） 能适应未来的变化。同样，在 DINO 的开发与使用过程中，技术会不断更新， 业务需求会不断变化，数据类型会不断增加，而 DINO 不可能推倒重来，因 此设计的构架必须能容纳变化。 （5） 支持多方数据管理与访问，不受地点限制。DINO 服务对象包括 TNO、提交 88 数据的第三方公司与公众。DINO 必须提供数据管理平台，使 TNO 及第三方 公司可以通过 DINO 来管理自己的数据，并允许第三方公司通过 DINO 经营 自己的数据商店。DINO 还必须提供便捷与低廉的公共数据服务，让公众能 以最低的费用获取有用的数据信息。 4.3 DINO 功能架构 功能架构是面向应用，或说是面向用户的系统结构。图 4.3 展示了 DINO 的功能架构。 从用户角度看，DINO 数据库有多个入口和两个出口，进行数据的存储、管理和分发。 图 4.3 DINO 功能架构 4.3.1 数据存储（Archiving） DINO 是一个单一的数据库，数据库由多个模块，或说是数据子库组成。各模块数据按 不同的专业类型分类，并由不同的管理程序管理。 除位置模块（Locations）外，其它各专业模块之间没有关联，数据关联仅通过位置模块 实现，见图 4.4。因此位置模块是数据模块之间的协调员。这样做的目的是使模块之间的关 89 系最小化，以便数据模块的管理与扩展。 所有数据的定位信息必须在位置模块中登记，除了地理位置外，位置模块中还储存了一 系列元数据信息，模块连接信息及数据入库与修改信息。因此，位置模块也是数据的统一管 理单元。 图 4.4 位置模块作为数据管理与协调单元 4.3.2 数据管理（Maintenance） 一个数据库多个摸块，每个数据模块配备专用的数据管理程序，构成了 DINO 数据库的 多个管理入口。 TNO 项目组或第三方公司可以通过这些管理程序来管理自己的数据。DINO 提供一系 列安全访问机制及控制到行、列的数据保护机制，实现不受地点限制的多方数据管理。 数据输入、输出及质量控制均由数据管理程序完成，所有管理程序的用户界面风格保持 一致，使数据管理简单化。 数据质量由 TNO 组织专家组评定（有欧洲标准），专家组评定后给数据打分，评价结 果挂入位置模块，用户查看数据时就可了解数据的质量信息，从而决定数据的取舍。质量评 定信息将直接影响经营数据商店的部门与第三方公司的收益。 90 4.3.3 数据分发（Dissemination） DINO 数据库有两个应用出口，一个是 TNO 项目组或第三方公司的专业应用出口，另 一个是 Web 应用出口。DINO 的数据库应用很简单，就是数据的输入、输出与管理，至于数 据怎么用他们认是专业人员自己的事。 从专业应用出口，专业人员可以通过 Excel、Access 或 ArcView 等第三方软件，或通过 专业领域的特定软件访问数据，进行地学数据分析。DINO 提供应用平台，供不同应用环境 的数据访问。不同应用环境的数据处理结果又可以通过数据管理程序上载进入 DINO 数据 库。这样就构成了一个数据的出入循环，见图 4.5。 Web 应用出口由 DINO 门户掌控，服务模式他们称之为“一站式”，指通过一个 Web 页 面实现所有数据的访问，因此这里的“一站式”是指一站式数据商店，进入商店可以买到你 需要的所有东西。不过一站式服务只提供数据的查询与提取服务，DINO Web 页面提供基于 坐标或地理范围的查询服务，用户可以通过 Web 页面查询并确认需要的数据，DINO 管理机 构核实后通过 Email 方式将客户申请的数据发送给客户，见图 4.6、图 4.7、图 4.8。 图 4.5 DINO 专业应用 91 图 4.6 数据查询信息输入页面 图 4.7 地理空间查询页面 92 图 4.8 查询结果页面 4.4 DINO 技术架构 技术架构是面向开发人员的系统结构，DINO 采用三层技术架构，见图 4.9。从内向外 为：数据存储层，应用服务层及前端服务层。 93 图 4.9 DINO 技术架构 4.4.1 数据存储层（Data Storage Layer） DINO 采用 Oracle 存储数据，数据包括 DINO 数据，地图数据和元数据。空间数据存储 采用 ERSI 的 SDE 及 Oracle Spatial Package，具体采用何种方式视具体情况而定。 DINO 数据的总体结构在介绍功能架构时已经谈过，是一个数据库包含多个专业模块， 位置模块既是管理员也是协调员。因此，从数据模型角度来看，DINO 数据库只有一个出入 口，就是位置模块通道。 DINO 概念数据模型采用 Oracle Case Repository 构建，数据模型标准为 POSC Epicentre 及 Adventus 等。Adventus 是荷兰自己的一个关于地下水的数据模型标准。POSC Epicentre 是石油行业的国际标准数据模型，由国际石油技术软件开放公司 POSC 94 （http://www.posc.org）推出，目前的版本为 POSC Epicentre2.2，从网上就可以下载。 POSC（Petrotechnical Open Software Corporation）是一家非盈利公司，BP 石油公司、雪佛龙 公司、ELF 公司、美孚公司、德士古公司，阿莫克公司和挪威的 STATOIL 公司是主办公司， 我国于 1995 年加入该组织。POSC Epicentre 涵盖的专业面宽，可以适用于各专业和各种复 杂的数据类型及大数据量的存储，它定义了大约 1500 个勘探开发技术领域中的技术和商业 对象语义，将不同学科、不同领域的数据集成在一起，且独立于任何应用程序，抽象程度非 常高。 Epicentre 数据模型是采用面向对象设计的数据模型，模型包括对象、属性及活动三类， 很复杂，能看懂就不容易，我不知道 DINO 是参考该标准还是采用该标准建的数据模型。 4.4.2 应用服务层（Application Service Layer） 应用服务层也叫中间层，是用户接口或Web 客户端与数据库之间的逻辑层。应用服务层 集中了系统的业务逻辑处理，是应用软件系统中的核心部分。软件系统的健壮性、灵活性、 可重用性、可升级性和可维护性，在很大程度上取决于应用服务层的设计。因此构建一个良 好架构的应用服务层十分重要。 DINO 的应用服务层开发全部采用 Java，开发工具为 IBM 的 Eclipse 和 Oracle Jdevelop， Eclipse 可以从网上免费下载。Web 与应用服务器采用 SilverStream, Apache/Tomcat 和 Oracle Application Server。由此构建了 DINO 应用服务平台（DINO-Framework），见图 4.10 和图 4.11。 DINO 应用服务平台基于 J2EE 技术，是数据的共同访问平台，也是应用程序的共同开发 环境，访问安全控制也在其中实现。DINO 应用服务平台提供风格一致的交互界面（Forms）， 支持直接（C/S）与间接（通过应用服务器）的数据访问与操作。DINO 应用服务平台也提供 扩展接口，支持应用服务的定制、扩展与开发。DINO 应用服务平台隐藏了计算机通信协议 （当时采用 HTTP 与 HTTPS 穿越防火墙通信）、应用服务器类型以及具体的数据库操作过程， 简化了平台上的应用程序开发过程，使前端数据管理与访问变得简单而透明。 95 4.4.3 前端服务层（Front Office Layer） DINO 前端服务包括数据管理和数据商店两大部分，见图 4.10。 图 4.10 DINO 应用环境 前端服务基于 Internet 和 Intranet。网络安全控制由以下方式实现： （１） TNO 内部用户直接采用数据库注册方式管理及访问数据； （２） 提交数据的第三方公司及保密数据用户通过 VPN（虚拟专用网络）及 HTTPS 管理及访问数据； （３） 外部用户通过 HTTP 访问数据，采用应用服务器进行访问控制。 数据表操作权限由角色控制，数据访问控制到数据表行、列级，行级访问控制通过 Oracle Label-security 实现（注：Oracle 在这方面已有较大更新）。插入、删除及更新等 数据表操作只通过存储过程实现，不采用触发器也不对表直接操作。 数据管理通过 Java 应用胖客户端程序实现，胖客户端管理程序由 Java Web Start 部署。 Java Web Start 是基于 Java 的应用程序，允许从标准的 Web 服务器启动、部署和更新 Java 96 客户机应用程序。这样，客户机应用程序就可以远程启动，不受平台与地点限制。同时也免 除了客户机应用程序的下载、安装和配置过程，并且确保客户使用的应用程序版本总是最新 的。 DINO 应用平台（DINO-Framework）提供扩展机制，数据管理方还可以在平台上定制或 扩展自己的数据管理与应用服务。数据商店通过Web 应用服务实现，地图服务及元数据服务 采用 ESRI ARCIMS 实现。 图 4.11 DINO 应用平台 97 5 结束语 这是我五年来的工作体会与总结，虽然这五年里越干越没信心，却从中收获了充实、 平和与快乐，从看似乱麻的数据世界里搜寻有意义的线索是我喜欢的工作。希望有一天我所 看到的数据库世界和“豆”中映射的世界一样璀灿。美国地质调查局（USGS）国家测绘部（NMD） 数据中心（网址 http://www.usgs.gov/），以及美国海洋与大气管理局（NOAA）国家环境卫 星数据与信息服务部（NESDIS）数据中心（网址 http://www.nesdis.noaa.gov/）都是我们 学习的榜样和努力的方向。 Bean（豆） Honling Kuo 2007 年圣诞节摄于芝加哥千年公园