数据仓库作为决策支持系统（DSS）的基础，具有面向主题的、集成的、不可更新的、随时间不断变化的特性。这些特点说明了数据仓库从数据组织到数据处理，都与原来的数据库有很大的区别，这也就需要在数据仓库系统设计时寻求一个适合于数据仓库设计的方法。在一般的系统开发规划中，首先需要确定系统的功能，这些系统的功能一般是通过对用户的需求分析得到的。从数据仓库的应用角度来看，DSS分析员一般是企业中的中高层管理人员，他们对决策支持的需求不能预先做出规范的说明，只能给设计人员一个抽象地描述。
这就需要设计人员在与用户不断的交流沟通中，将系统的需求逐步明确，并加以完善。因此数据仓库的开发规划过程实际上是一个用户和设计人员对其不断了解、熟悉和完善的过程。 数据仓库的开发应用规划是开发数据仓库的首要任务。只有制定了正确的数据仓库规划，才能使组织主要力量有序地实现数据仓库的开发应用。在数据仓库规划中一般需要经历这样几个过程：选择实现策略、确定数据仓库的开发目标和实现范围、选择数据仓库体系结构、建立商业和项目规划预算。 当数据仓库规划完成后，需要编制相应的数据仓库规划说明书，说明数据仓库与企业战略的关系，以及与企业急需处理的、范围相对有限的开发机会，重点支持的职能部门和今后数据仓库开发工作的建议，实际使用方案和开发预算，作为数据仓库实际开发的依据。
1、选择数据仓库实现策略
数据仓库的开发策略主要有自顶向下、自底向上和这两种策略的联合使用。自顶向下策略在实际应用中比较困难，因为数据仓库的功能是一种决策支持功能。这种功能在企业战略的应用范围中常常是很难确定的，因为数据仓库的应用机会往往超出企业当前的实际业务范围，而且在开发前就确定目标，会在实现预定目标后就不再追求新的应用，是数据仓库丧失更有战略意义的应用。由于该策略在开发前就可以给出数据仓库的实现范围，能够清楚地向决策者和企业描述系统的收益情况和实现目标，因此是一种有效的数据仓库开发策略。该方法使用时需要开发人员具有丰富的自顶向下开发系统的经验，企业决策层和管理人员完全知道数据仓库的预定目标并且了解数据仓库能够在那些决策中发挥作用。
自底向上策略一般从某个数据仓库原型开始，选择一些特定的为企业管理人员所熟知的管理问题作为数据仓库开发的对象，在此基础上进行数据仓库的开发。因此，该策略常常用于一个数据集市、一个经理系统或一个部门的数据仓库开发。该策略的优点在于企业能够以较小的投入，获得较高的数据仓库应用收益。在开发过程中，人员投入较少，也容易获得成效。当然，如果某个项目的开发失败可能造成企业整个数据仓库系统开发的延迟。该策略一般用于企业洗碗对数据仓库的技术进行评价，以确定该技术的应用方式、地点和时间，或希望了解实现和运行数据仓库所需要的各种费用，或在数据仓库的应用目标并不是很明确时，数据仓库对决策过程影响不是很明确时使用。
在自顶向下的开发策略中可以采用结构化或面向对象的方法，按照数据仓库的规划、需求确定、系统分析、系统设计、系统集成、系统测试和系统试运行的阶段完成数据仓库的开发。而在自底向上的开发中，则可以采用螺旋式的原型开发方法，使用户可以根据新的需求对试运行的系统进行修改。螺旋式的原型开发方法要求在较短的时间内快速的生成可以不断增加功能的数据仓库系统，这种开发方法主要适合于这样一些场合：在企业的市场动向和需求无法预测，市场的时机是实现产品的重要组成部分，不断地改进对与企业的市场调节是必需的；持久的竞争优势来自连续不断地改进，系统地改进是基于用户在使用中的不断发现。 自顶向下和自底向上策略的联合使用具有两种策略的优点，既能快速的完成数据仓库的开发与应用，还可建立具有长远价值的数据仓库方案。但在实践中往往难以 *** 作，通常需要能够建立、应用和维护企业模型、数据模型和技术结构的、具有丰富经验的开发人员，能够熟练的从具体（如业务系统中的元数据）转移到抽象（只基于业务性质而不是基于实现系统技术的逻辑模型）；企业需要拥有由最终用户和信息系统人员组成的有经验的开发小组，能够清楚地指出数据仓库在企业战略决策支持中的应用。
2、确定数据仓库的开发目标和实现范围
为确定数据仓库的开发目标和实现范围，首先需要对企业管理者等数据仓库用户解释数据仓库在企业管理中的应用和发展趋势，说明企业组织和使用数据来支持跨功能系统的重要性，对企业经营战略的支持，以确定开发目标。在该阶段确认与使用数据仓库有关的业务要求，这些要求应该只支持最主要的业务职能部门，将使用精力集中在收益明显的业务上，使数据仓库的应用立即产生效果，不应该消耗太多的精力在各个业务上同时铺开数据仓库的应用。
在确定开发目标和范围以后，应该编制需求文档，作为今后开发数据仓库的依据。 数据仓库开发的首要目标是确定所需要信息的范围，确定用户提供决策帮助时，在主题和指标域需要哪些数据源。这就需要定义：用户需要什么数据？面向主题的数据仓库需要什么样的支持数据？为成功地向用户提交数据，开发人员需要哪些商业知识？哪些背景知识？这就需要定义整体需求，以文件的形式整理现存的记录系统和系统环境，对使用数据仓库中数据的候选应用系统进行标识、排序，构造一个传递模型，确定尺度、事实及时间标记算法，以便从系统中抽取信息且将他们放入数据仓库。通过信息范围确定可为开发人员提供一个良好的分析平台，和用户一起分析哪些信息是数据仓库需要的，进行商业活动需要什么数据。开发人员可以和用户进一步定义需要，例如数据分级层次、聚合的层次、加载的频率以及需要保持的时间表等。 数据仓库开发的另一个重要目标是确定利用哪些方法和工具访问和导航数据？虽然用户都需要存取并且检索数据仓库的内容，但是所存取的粒度有所不同，有的可能是详细的记录，有的可能是比较概括的记录或十分概括的记录。用户要求的数据概括程度不同，将导致数据仓库的聚集和概括工具的需求不同。
数据仓库还有具有一定功能来访问和检索图表、预定义的报表、多维数据、概括性数据和详细记录。用户从数据仓库中获得信息，应该有电子表格、统计分析器和支持多维分析的分析处理器等工具的支持，以解释和分析数据仓库中的内容，产生并且验证不同的市场假设、建议和决策方案。为将决策建议和各种决策方案向用户清楚地表达出来，需要利用报表、图表和图像等强有力的信息表达工具。 数据仓库开发的其他目标，是确定数据仓库内部数据的规模。在数据仓库中不仅包含当前数据，而且包含多年的历史数据。数据的概括程度决定了这些数据压缩和概括的最大限度。如果要让数据仓库提供对历史记录进行决策查询的功能，就必须支持对大量数据的管理。数据的规模不仅直接影响决策查询的时间，而且还将直接影响企业决策的质量。
在数据仓库的开发目标中，还有：根据用户对数据仓库的基本需求，确定数据仓库中数据的含义；确定数据仓库内容的质量，以确定使用、分析和建议的可信级别；哪种类型的数据仓库可以满足最终用户的需求，这些数据仓库应该具有怎样的功能；需要哪些元数据，如何使用数据源中的数据等。 数据仓库的开发目标多种多样，十分复杂，需要开发人员和用户在开发与使用的过程中不断交互完善。因此，在规划中需要确定数据仓库的开发范围。使开发人员能够根据需求和目标的重要性逐步进行，并且在开发中吸取经验教训，为数据仓库在企业中的全部实现提供技术准备。因此，在为数据仓库确定总体开发方向和目标以后，就必须确定一个有限的能够很快体现数据仓库效益的使用范围。在考虑数据仓库苦的应用范围时，主要从使用部门的数量和类型、数据源的数量、企业模型的子集、预算分配以及开发项目所需的时间等角度分析。
在分析这些因素时，可从用户的角度和技术的角度两方面进行。 从用户的角度应该分析哪些部门最先使用数据仓库？是哪些人员为了什么目的使用数据仓库？以及数据仓库首先要满足哪些决策查询？因为这些决策查询往往确定了关于数据维数、报表的种类，这些因素都将确定数据仓库定义时所需要的数量关系。查询的格式越具体，越容易提供数据仓库的维数、聚集和概括的规划说明。 从技术角度分析，应该确定数据仓库中元数据库的规模，数据仓库的元数据库是存储数据仓库中数据定义的模型。数据定义存储在仓库管理器的目录中，可以作为所有查询和报表工具构造和查询数据仓库的依据。元数据库的规模直接表示了数据仓库中必须管理的数据规模。通过对元数据库规模的管理，实际上就确定了数据仓库中所需要管理的数据规模。
3、数据仓库的结构选择
数据仓库的结构可以进行灵活的选择，可将组织所使用的各种平台进行恰当的分割，把数据源、数据仓库和最终用户使用的工作站分割开来进行恰当的设计。
（1）数据仓库的应用结构
基于业务处理系统的数据仓库 在这种结构中，将运作的数据用于无需修改数据的只读应用程序中。具有这种结构的数据仓库元数据库是一种虚库，而不是数据仓库自身的元数据。在数据仓库元数据库的直接指导下，对数据仓库的查询就是简单的从数据库中抽取数据。
单纯数据仓库
利用在数据仓库中的数据源净化、集成、概括和集成等 *** 作，将数据源从业务处理系统中传输进集中的数据仓库，各部门的数据仓库应用只在数据仓库中进行。这种结构经常发生在多部门、少用户使用数据仓库的情况下。这里的集中仅仅是逻辑上的，物理上可能是分散的。
单纯数据集市
数据集市是指在部门中使用的数据仓库，因为企业中的各个职能部门都有自己的特殊需要，而统一的数据仓库可能不能满足这些部门的特殊要求。这种体系结构经常发生在个别部门对数据仓库的应用感兴趣，而组织中其他部门却对数据仓库的应用十分冷漠之时，由热心的部门单独开发式所采用。
数据仓库和数据集市
企业各部门拥有满足自己需要的数据集市，其数据从企业数据仓库中获取，而数据仓库从企业各种数据源中收集和分配。这种体系结构是一种较为完善的数据仓库体系结构，往往发生在组织整体对数据仓库应用感兴趣之时所采用的体系结构。
（2）数据仓库的技术平台结构 单层结构
单层结构主要是在数据源和数据仓库之间共享平台，或者让数据源、数据仓库、数据集市与最终用户工作站使用同一个平台。共享一个平台可以降低数据抽取和数据转换的复杂性，但是共享平台在应用中可能遇到性能和管理方面的问题，这种体系结构一般在数据仓库规模较小，而组织的业务系统平台具有较大潜力之时所采用。
客户/服务器两层结构
一层为客户机，一层为服务器，最终用户访问工具在客户层上运行，而数据源、数据仓库和数据集市位于服务器上，该技术机构一般用于普通规模的数据仓库。
三层客户/服务器结构
基于工作站的客户层、基于服务器的中间层和基于主机的第三层。主机层负责管理数据源和可选的源数据转换；服务器运行数据仓库和数据集市软件，并且存储仓库的数据；客户工作站运行查询和报表运用程序，且还可以存储从数据集市或数据仓库卸载的局部数据。在数据仓库稍具规模，两层数据仓库结构已经不能满足客户的需求，要讲数据仓库的数据存储管理、数据仓库的应用处理和客户端应用分开之时，可以采用这种结构。
多层式结构
这是在三层机构基础上发展起来的数据仓库结构，在该结构中从最内数据层到最外层的客户层依次是：单独的数据仓库存储层、对数据仓库和数据集市进行管理的数据仓库服务层、进行数据仓库查询处理的查询服务层、完成数据仓库应用处理的应用服务层和面向最终用户的客户层。体系层次可能多达五层，这种体系结构一般用于超规模数据仓库系统。
4、数据仓库使用方案和项目规划预算
数据仓库的实际使用方案与开发预算，是数据仓库规划中最后需要确定的问题。因为数据仓库主要用于对企业管理人员的决策支持，确保其实用性是十分重要的，因此需要让最终用户参与数据仓库的功能设计。这种参与是通过用户的实际使用方案进行的，使用方案是一个非常重要的需求模型。实际使用方案必须有助于阐明最终用户对数据仓库的要求，这些要求有的只使用适当的数据源就可以得到基本满足，而有的却需要来自企业外部的数据源，这就需要通过使用方案将这些不同的要求联系起来。 实际使用方案还可以将最终用户的决策支持要求与数据仓库的技术要求联系起来。因为当用户确定最终要求后，为元数据库的范围确定一个界限。还可以确定所需要的历史信息的数量，当根据特定的用户进行数据仓库的规划时，就可确定最终用户所关心的维度（时间、方位、商业单位和生产企业），因为维度与所需要的概括 *** 作有明显的关系，必须选择对最终用户有实际意义的维度，如：“月”、“季度”、“年”等。最后，还可以确定数据集市/数据仓库的结构需要，使设计人员确定采用单纯数据仓库结构，还是单纯的数据集市结构或者是两者相结合的结构。
在实际使用开发方案确定后，还需要对开发方案的预算进行估计，确定项目的投资数额。投资方案的确定可以依据以往的软件开发成本，但是这种预算的评估比较粗糙。另一种方法是参照结构进行成本评估，也就是说，将数据仓库实际使用方案所确定的构件进行分解，根据各个构件的成本进行预算估算。数据仓库的构件包含在数据源、数据仓库、数据集市、最终用户存取、数据管理、元数据管理、传输基础等部分中，这些构件有的在企业原有信息系统中已经具备，有的可以选择商品化构件，有的则需要自我开发。根据这些构件的不同来源，可以确定比较准确的预算。 在完成数据仓库规划后，就需要编制数据仓库开发说明书，说明系统与企业战略目标的关系，以及系统与企业急需处理的范围相对有限的开发机会，所设想的业务机会的说明以及目标任务概况说明、重点支持的职能部门和今后工作的建议。数据仓库项目应有明确的业务价值计划开始，在计划中需要阐明期望取得的有形和无形的利益。无形利益包含利用数据仓库使决策完成得更快更好等利益。
业务价值计划最好由目标业务主管来完成，因为数据仓库是用户驱动的，应该让用户积极参与数据仓库的建设，在规划书中要确定数据仓库开发目标的实现范围、体系结构和使用方案及开发预算。
一、范围
本标准定义了山东半岛城市群地质－生态环境空间数据库的数据结构框架、数据实体及实体之间的相互关系，定义了成果图件空间数据的要素集、要素类、要素分类代码及属性数据项，可用于山东半岛城市群项目数据的采集、存储、管理、共享及数据库建设。
二、规范性引用文件
下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所示版本均为有效。所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。
GB / T 1. 1—2000 标准化工作导则 第 1 部分: 标准的结构和编写规则
GB / T 13923—92 国土基础信息数据分类代码
GB / T 2260—1999 中华人民共和国行政区划代码
GB / T 2659 世界各国和地区名称代码
GB / T 9649—88 地质矿产术语分类代码
DZ / T 0160—95 1∶ 200000 地质图地理底图编绘规范及图式
DZ / T 0197—1997 数字化地质图图层及属性文件格式
GB 958—99 区域地质图图例 ( 1∶ 50000)
DZ / T 0179—1997 地质图用色标准及用色原则
DDB 9702 GIS 图层描述数据内容标准
GB 17108—1997 海洋功能区划技术导则
中国地质调查局 地质图空间数据库建设工作指南 ( 2. 0 版)
中国地质调查局 1∶ 20 万区域水文地质图空间数据库图层及属性文件格式工作指南
三、术语和定义
本标准涉及的主要术语如下:
1. 地理信息数据库 ( geodatabase)
采用标准关系数据库技术来管理、表现地理信息的空间数据库。
2. 数据包 ( data package)
逻辑相关数据实体的集合，本标准中将山东半岛城市群项目数据整体视作一个数据包。
3. 数据实体 ( data entity)
描述专业领域同一类型数据的数据元素的集合，如地质构造数据实体，概念上等同于UML 的类。数据实体可通过一个或多个相关的数据元素及相关的数据实体定义。
4. 数据集 ( dataset)
逻辑相关数据组成的数据集合，如一幅地图可视作一个数据集，数据集是一个逻辑上的整体。
5. 数据子集 ( subdataset)
按一定规则划分的数据集中逻辑相关数据的集合，本标准中的一个数据子集对应一个地图要素类，数据子集类别对应地图上的图层划分。
6. 空间数据 ( spatial data)
用来表示空间实体的位置、形状、大小和分布特征诸方面信息的数据。空间数据不仅具有实体本身的空间位置及形态信息，而且还有实体属性和空间关系 ( 如拓扑关系)信息。
7. 空间参照系 ( spatial reference)
对地理信息数据的空间范围和投影的描述。
8. 地图 ( map)
地理信息的图形描述，包括地理信息数据和地图元素，如标题、图例和比例尺等。本标准中将一幅地图视作一个数据集进行管理，并通过一组要素集 ( 要素类、关系类、属性表的集合) 、空间参照系、地图样式定义地图的数据内容及显示方式。
9. 图层 ( layer)
地图上特定区域范围内按一定规则划分的相似要素类的集合，如水系、城镇。图层为要素类的专题组合及表现，一个图层定义了它包含地理信息数据的地理位置和显示方法。
10. 要素 ( feature)
现实世界中的对象在地图图层中的表示，如地图中表示道路的一条线。
……
四、缩略语和符号
1. 缩略语
ARD 图外整饰要素 ( Elements Around Map)
BMAP 地理底图 ( Basemap)
BOU 境界、边界 ( Bourn)
CD 代码 ( Code)
COL 综合柱状图 ( Colomnar Chart)
DT 日期 ( Date)
ELE 地形高程 ( Elevation)
……
2. UML 类图符号
山东半岛城市群地区地质－生态环境与可持续发展研究
3. ER 图符号
山东半岛城市群地区地质－生态环境与可持续发展研究
五、基于 UML 的 Geodatabase 的空间数据模型
构建地质数据的空间数据模型是建立地质信息数据库的一项关键工作，是数据库建设的基础。Geodatabase 数据模型作为 ArcGIS 软件平台的一种通用数据形式，目前已被国内外众多地质空间数据库的建设所采用。数据建模也已经成为地质数据库建立的一项主要内容。
目前针对地质、水文、矿产、海洋等多个领域的专业 Geodatabase 数据模型都已存在，国内目前应用于区域地质 － 生态环境调查的综合地质 － 生态环境空间数据模型还比较少见。因此，本项目在分析国内外目前比较通用的各专业数据模型的基础上，提出了专门面向山东半岛城市群地质 － 生态环境空间数据库建设的 Geodatabase 数据模型。
在 Geodatabase 数据模型中，允许定义要素之间类型的关联，Geodatabase 对空间数据管理以关系数据库为基础，利用商用关系数据库成熟的数据处理能力对空间数据和非空间数据进行统一管理。Geodatabase 使用面向对象的方法，使得要素可以具有自己的行为和属性，并且要素类具有继承性、多态性和封装性。这样，以更加适合自然的行为和人的思维方式去组织数据，更精确地模拟真实世界。
1. Geodatabase 数据模型的结构体系
Geodatabase 数据模型作为一种新型的面向对象的数据模型，融入了面向对象的核心技术，如类 ( Class) 、对象 ( Object) 、封装 ( Encapsulation) 、继承 ( Inheritance) 和多态( Polymorphism) 等思想和技术。Geodatabase 数据模型的目的就是为了让用户能更容易、更自然地表示 GIS 数据特征和更容易地建立特征之间的各种关系。Geodatabase 空间数据库数据模型如表 12 －1 所示。
表 12 －1 Geodatabase 内部结构
续表
2. Geodatabase 数据库模型的特点
Geodatabase 有两种，即个人与多用户 Geodatabase。
1) 个人 Geodatabase 支持内置于 ArcGIS 系统并提供对本地数据的访问，适用于面向项目的 GIS，在 Microsoft Access 数据库平台上实现，提供生成和更新 Access 数据库的服务，可处理小型或适中的 Access 数据库。但个人 Geodatabase 的存储容量有不能超过 2GB的限制。
2) 多用户的 Geodatabase 是通过 ArcSDE ( ARC 空间数据库引擎) 实现的。ArcSDE可以生成和访问从小型到大型的 Geodatabase 并提供关系型数据的开放界面。
与标准的关系数据库相比，Geodatabase 简化了地理数据建模的工作，因为它包含有用于建模地理信息的通用模型。
此外，Geodatabase 还同时支持两个视图，即对象视图和关系视图。这样就综合了对象视图和关系视图两者的优点。对象视图在 Geodatabase 中占据主导地位，其目的是提供一个接近于逻辑数据模型的数据模型，因而更接近于现实。关系视图则用于一些 Geodata-base 数据的常规处理，它表示的是一些简单地理对象的特征。
3. 基于 UML 的 Geodatabase 数据模型的设计
( 1) Geodatabase 数据库设计的方法
在 ArcGIS 中，建立地理数据库可以有多种方法。借助 ArcCatalog，可以通过 3 种方式建立新的地理数据库。
第一种方法是建立一个新的地理数据库。
第二种方法是移植已经存在的数据到地理数据库中去。
第三种方式是用 CASE 工具来建立地理数据库。
( 2) 面向对象和 UML ( 统一建模语言)
面向对象是软件程序设计中的一种新思想，它能使程序设计更加贴近现实，并且花费更小的精力。面向对象方法学包含了对象 ( object) 、类 ( classification) 、继承 ( inherit-ance) 、聚集和消息 ( messages) 的概念。
UML ( Unified Modeling Language，统一建模语言) 是一种基于面向对象方法的建模语言，具有创建系统的静态结构和动态行为等多种结构模型的能力，是一种通用的建模语言。在 Geodatabase 的设计中，主要用到描述系统静态结构的类图。类图的节点表示系统中的类及其属性和 *** 作。类图的边表示类之间的联系，包括继承、关联、依赖、聚合等。
类的表示由 3 个部分方框组成，上面部分给出了类的名称中间部分给出了该类的单个对象的属性下面部分给出了一些可以应用到这些对象的 *** 作。类的表示如图 12 －5。
图 12 －5 类的表示
关联是对类的实例之间联系的命名，与关联有关的内容有关联元数 ( Degree) 、关联角色 ( Role) 和重复度 ( Multiplicity) 。
UML 中有 3 种类型的类: 抽象类 ( abstract class) 、可创建化类 ( creatable class) 和可实例化类 ( instantiable class) 。
UML 类图的符号见本节第四部分内容。
( 3) 面向对象的地理数据模型的设计方法
利用 CASE 工具进行 Geodatabase 数据模型设计的步骤具体为:
1) 在 CASE 工具中进行 UML 建模。
2) 将设计好的 UML 模型载入资料库 ( repositry) 。
3) 利用 GIS 软件提供的 CASE 接口，根据资料库中的 UML 模型生成空间数据库结构。至此，Geodatabase 空间数据库结构初具雏形。在 GIS 软件环境中，现在可以将新生成的数据或已有的数据进行格式转换后载入到设计好的 Geodatabase 空间数据库中，由空间数据库统一管理。利用 CASE 工具来建立 Geodatabase 地理数据库的工作流程见图12 － 6。
图 12 －6 利用 CASE 工具来建立 Geodatabase 地理数据库的工作流程
六、地质 － 生态环境 Geodatabase 数据模型的建立
( 一) 数据模型设计的依据
根据山东半岛城市群地质 － 生态环境调查评价研究工作的需要和山东半岛城市群地质 － 生态环境 GIS 数据库系统的整体设计要求，结合各地质 － 生态环境要素的成果图件和文本报告资料，利用 UML 设计工具 Microsoft Visio 完成了山东半岛城市群地质 － 生态环境Geodatabase 数据模型的设计 ( 图 12 － 7) 。
图 12 －7 山东半岛城市群地质 － 生态环境 Geodatabase 数据模型的设计依据
( 二) 山东半岛城市群地质 － 生态环境数据库的 UML 类图
1. 数据集管理
山东半岛城市群项目数据包中的数据以数据集为单元统一组织管理，数据集管理方式就是将一份文字报告或一幅成果图件视作逻辑上的整体，用 “数据集编号”唯一标识，通过数据集实体统一管理。同一数据集的不同实体，例如成果图中的图层，通过实体中的“数据集编号”元素关联。
2. 空间数据管理
山东半岛城市群项目数据包由文字报告及成果图件两大类数据组成，并以成果图件为主，成果图件是一空间数据实体，统一存储在面向对象的地理信息数据库中，以图幅为单元进行管理。
3. 数据包总体结构
本标准中山东半岛城市群项目数据包总体结构用 UML 模型来体现，山东半岛城市群项目数据包由 “成果报告”、“元数据”及 “存档文件”3 个数据实体 ( UML 类) 组成，通过 “数据集”实体统一组织管理。“成果报告”由它的继承类 “文字报告”及 “成果图件”定义，为研究成果数据包的主体数据。“元数据”及 “存档文件”为数据集的辅助数据，“元数据”存放文字报告或成果图件的元数据“存档文件”存放文字报告或成果图件的相关存档文件，供数据集数据的整体下载与利用。
一个 “数据集”实体对应一个项目的 “文字报告”或一幅 “成果图件”每一个数据集必须有一个而且只能有一个 “元数据”文件“存档文件”是 “数据集”的可选聚合实体。
“成果图件”是一空间数据实体，由特定的面向对象地理信息数据库 ( Geodatabase)统一存储、管理。一幅 “成果图件”数据内容由一组空间要素集 ( 基础地理要素集、地质要素集、地球物理要素集、地球化学要素集、辅助要素集) 组成，空间要素集数据类型包括矢量 ( Feature Dataset，简称要素集) 、栅格 ( Raster Dataset) 和 TIN ( TIN Dataset)3 种。
4. 数据集编号的编码规则
数据集编号由数据库管理方统一编码，必须保证编号在数据库中唯一，编号中的英文字母全部大写。
山东半岛城市群项目数据集按 “项目或图幅—提交单位—提交年份—成果序号”编码。数据集编号的字符串长度不得超过 22 位，以保证 “数据集编号 + 要素类名”的字符串总长度不超过 30 位。
5. 成果图件要素类命名规则
要素类名字符串总长度不得超过 8 位。
矢量要素类按 “要素集类型 + 要素类名 + 要素类型”命名，全部用大写英文字母表示。“要素集类型”用一位代码表示，如 “L”表示基础地理要素集。栅格数据集数据以“要素集类型 + 要素类型”命名，要素类型用代码 RAS 表示，如 “DRSRAS”表示遥感栅格数据。TIN 数据集数据以 “要素集类型 + 要素类型”命名，要素类型用代码 TIN 表示，如 “LELETIN”表示地面高程 TIN。
6. 成果图件要素分类编码规则
要素分类编码用以标识不同的要素类要素，保证地图要素存储、交换、显示的一致性。
( 1) 分类编码原则
1) 科学性、系统性
2) 相对稳定性
3) 不受地图比例尺的限制
4) 完整性和可扩展性
5) 适用性。
( 2) 分类编码方法
成果图件要素类中不同要素的分类编码采用中华人民共和国国家标准 《国土基础信息数据分类与代码》的编码结构，结构如下:
山东半岛城市群地区地质－生态环境与可持续发展研究
大类码、小类码、一级代码和二级代码分别用数字顺序排列。识别位由用户自行定义，以便于扩充。在本项目中编码分两类: ①基础地理要素编码②地质专业要素编码( 地质、地球物理、地球化学等) 。
( 三) 山东半岛城市群项目数据实体及实体关系
山东半岛城市群项目数据实体类及其代码见表 12 －2，实体类名代码按实体类的英文名缩略语编码，本标准中山东半岛城市群项目数据实体及实体间关系用 UML 及实体关系图 ( ERD) 来体现。
表 12 －2 山东半岛城市群项目数据实体类及其代码
1. 数据集实体 ( MGRD_Dataset)
山东半岛城市群项目数据包中的 “数据集”实体用来统一组织管理 “文字报告”、“成果图件”、“元数据”及 “存档文件”数据实体，“数据集”实体中的数据项包含数据集的归属项目、提交日期、提交单位、主题类别及地理范围等可用于数据集检索的信息。一个 “数据集”实体对应一个项目的 “文字报告”或一幅 “成果图件”，“数据集”实体与 “元数据”实体间为一一对应关系，与 “存档文件”实体间为一对多的对应关系。“数据集”实体的数据内容及其存储表通过 “数据子集”实体分类定义，主键 ［数据集编号］可用于同一数据集中不同 “数据子集”的关联，也可用于数据集对应的 “元数据”及“存档文件”的关联。
2. 成果报告数据实体 ( MGRD SumTmaryReport)
研究成果报告数据实体包括项目的最终综合文字报告及相应的成果图件。
( 1) 文字报告数据实体 ( SR_WordReport)
文字报告数据实体包括 “文字报告”及图像格式的 “报告附图”数据实体，文字报告及附图均以二进制大对象存储。数据实体之间通过 ［数据集编号］ 关联。
( 2) 成果图件数据实体 ( SR_hemeMapSet)
“成果图件”数据实体是一空间数据实体，主要以矢量图形格式存储在地理信息数据库中，其中也包括栅格数据及 TIN 数据用于数据的空间分析。
1) 要素集: “成果图件” 数据实体以图幅为数据集单元进行管理图幅内容以分属不同空间要素集 ( 基础地理要素集、地质要素集、地球物理要素集、地球化学要素集、辅助要素集) 的要素类组合，同一个要素集内的要素类享有同一空间参照系，相互具有拓扑关系。
2) 要素类: 一个要素类的存储单元为关系数据库中的一个数据表，要素类图元类型有点、线、面、注记 4 种，一个要素类只能包含一种图元类型。本标准中基础地理要素集、地质要素集、地球物理要素集、地球化学要素类、辅助要素集的要素类用 UML 类图体现。
3) 图层: 图层为要素类的专题组合及表现，不同图层的组合即构成了可视化 “成果图件”。本项目通过对数据来源的分析，提出并建立了适合山东半岛城市群地区地质 － 生态环境调查与评价特点的空间数据库数据图层。考虑到空间数据的应用和相互转换，每一图层均应建立相应的内部属性表，属性表必须包含一些基本字段内容，根据具体任务的不同，需灵活扩充内部属性表字段内容。 “成果图件”数据实体的图层划分及其代码见表 12 －3。
4) 要素类属性: 要素类的要素特征由属性表定义，属性表每一行对应一个要素，每一列包含要素的一个特征信息。
表 12 －3 成果图件数据实体的图层划分及其代码
5) 要素类要素分类: 同一要素类中不同类型的要素用不同的代码标识，通过属性表中的 “编码” ( GEO_CODE) 数据项体现，以便地图中同一要素类要素的分类显示，并保证地图要素存储、交换、显示的一致性。在本项目中成果图件的基础地理要素分类代码采用中华人民共和国国家标准 《国土基础信息数据分类与代码》，并根据需要进行了扩充，地质专业要素分类代码全部由本标准定义，见表 12 －4 和表 12 －5。
表 12 －4 基础地理要素分类代码
表 12 －5 地质专业要素分类代码
图12 -8 山东半岛城市群项目数据包UML类图
图层编码中，第一位为图类代码，L 代表基础地理类图层D 代表基础地质类图层G 代表国土资源图层W 代表地壳稳定性图层S 代表水资源图层H 代表海岸带图层T 代表生态环境图层R 代表人类工程活动图层F 代表分析评价图层Y 代表预测与防治图层Z 代表辅助图层。第二位为比例尺代码，图件均采用 1∶ 50 万比例尺，代码为 B。第三位到第五位为图名的汉语拼音首字母缩写。第六位为图层数字编号。
( 四) 山东半岛城市群项目 UML 类图
1. 山东半岛城市群项目数据包 UML 类图
UML 类图见图 12 － 8。
2. 成果图件要素集 UML 类图
1) 基础地理要素集实体 UML 类图 ( FD_Geography) 。本项目将基础地理要素分为地理网格、居民地、境界、交通网、地貌地形、水系、海洋海岸带、行政区划、栅格数据等 9个抽象要素类，建立了 “各市基本情况”对象类，与表明各地区域的 “城市群”类相连接，将山东半岛城市群8 个地级市的地理位置数据与地区的基本资料数据有机地联系起来。
2) 地质要素集实体 UML 类图 ( FD_Geology) 。
3) 国土资源要素集实体 UML 类图 ( FD_LandResource) 。
4) 水资源要素集实体 UML 类图 ( FD_WaterResource) 。
5) 生态环境要素集实体 UML 类图 ( FD_Environment) 。
6) 辅助要素集实体 UML 类图 ( FD_Ancillary) 。
3. 山东半岛城市群项目数据实体关系图
1) 数据集实体 ER 图 ( MGRD_DataSet) 。
2) 研究成果报告数据实体 ER 图 ( MGRD_SummaryReport) ( 图 12 － 9) 。
图 12 －9 研究成果报告数据实体 ER 图 ( MGRD_SummaryReport)
七、山东半岛城市群项目数据包数据字典
( 一) 数据集实体 ( MGRD_DataSet)
山东半岛城市群地区地质－生态环境与可持续发展研究
( 二) 研究成果报告数据实体 ( MGRD_SummaryReport)
1. 文字报告数据实体 ( SR_WordReport)
山东半岛城市群地区地质－生态环境与可持续发展研究
2. 成果图件数据实体 ( SR_ThemeMapSet)
( 1) 基础地理要素集实体 ( FD_Geography)
山东半岛城市群地区地质－生态环境与可持续发展研究
( 2) 地质要素集实体 ( FD_Geology)
山东半岛城市群地区地质－生态环境与可持续发展研究
( 3) 水资源要素集实体 ( FD_HydroResource)
山东半岛城市群地区地质－生态环境与可持续发展研究
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）