水文地质应用分析系统建设方案Word下载.docx

水文地质应用分析系统建设方案Word下载.docx

《水文地质应用分析系统建设方案Word下载.docx》由会员分享，可在线阅读，更多相关《水文地质应用分析系统建设方案Word下载.docx（32页珍藏版）》请在冰豆网上搜索。

元数据库是对以上各数据进行描述的元数据的集合，是进行数据交换的基础。

每大类数据库又可分为若干个子数据库。

2.2数据库管理平台

数据库管理平台负责对数据资源进行管理维护、数据交换，包括数据库维护管理系统、信息资源目录与信息发布系统、水利综合查询系统和元数据管理系统。

1）数据库维护管理系统

数据库管理系统主要是对综合数据库的管理，主要功能有数据库模式定义、数据更新维护、数据库用户管理、代码维护、数据库性能优化管理等。

2）信息资源目录与发布系统

以水利数据中心为枢纽建立水利信息资源共享，通过元数据管理，组建数据资源目录管理。

信息资源目录系统提供分布式数据共享的基础，对于物理上分散的数据资源建立统一的数据清单，系统能够数据所有者提供发布的平台，为数据使用者提供查询服务。

在数据中心建设中，省水资源中心数据、省水文局水情中心数据、省水土保持监测站数据、省水利信息中心数据以数据资源目录的形式提供发布和检索平台。

虚拟的信息目录中心设在省水利信息中心，统一管理信息目录，提供注册和发布平台。

3）水利综合查询系统

水利综合查询系统是对中心数据资源的检索服务，提供基础性水利数据的信息浏览。

4）元数据管理

元数据管理系统集中管理的元数据的系统，实现对异构、异地数据资源的分布式管理与服务。

其基本功能包括元数据的提取、质量保证和再处理、系统的维护。

2.3应用支撑平台建设

应用支撑平台是构筑整个水利数据中心应用系统的统一支撑平台。

应用支撑平台介于中心数据库和各种应用系统之间，与业务应用系统的运行网络环境、软硬件环境无关。

通过管理软件、中间件、数据备份软件等构造数据中心的软件运行环境。

数据中心应用支撑平台包括操作系统、数据库系统、存储备份软件、地理信息系统软件和工作流等各种应用中间件。

平台的功能主要为各种应用系统提供数据库的访问、地理空间服务、系统之间的信息交换、事务处理、流程控制、认证等各种服务和统一的Web服务器平台。

3数据层设计

数据层由基础地理空间数据和水文地质专题数据两大部分组成。

基础地理空间数据根据国家测绘局相关规范中的要求，需要对基础地理信息数据进行内容提取、分层细化、模型对象化重构、统计分析、符号化表现等处理改造，形成用于水文地质信息服务平台的公共地理框架数据，主要包括基础框架要素、影像数据、三维数据、地名地址、地面高程模型和基础框架要素。

地理框架数据由地理框架数据库管理系统生产、加工和维护等。

建立水文地质数据中心，方便资源的整合和利用。

3.1数据库设计

3.1.1数据库设计原则

3.1.1.1原始单据与实体之间的关系

可以是一对一、一对多、多对多的关系。

在一般情况下，它们是一对一的关系：

即一张原始单据对应且只对应一个实体。

在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。

这里的实体可以理解为基本表。

明确这种对应关系后，对我们设计录入界面大有好处。

3.1.1.2主键与外键

一般而言，一个实体不能既无主键又无外键。

在E—R图中,处于叶子部位的实体,可以定义主键，也可以不定义主键。

主键与外键的设计，在全局数据库的设计中，占有重要地位。

当全局数据库的设计完成以后，有个美国数据库设计专家说：

“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心（数据模型）的高度抽象思想。

因为：

主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。

3.1.1.3基本表的性质

基本表与中间表、临时表不同，因为它具有如下四个特性：

（1）原子性。

基本表中的字段是不可再分解的。

（2）原始性。

基本表中的记录是原始数据（基础数据）的记录。

（3）演绎性。

由基本表与代码表中的数据，可以派生出所有的输出数据。

（4）稳定性。

基本表的结构是相对稳定的，表中的记录是要长期保存的。

理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。

3.1.1.4范式标准

基本表及其字段之间的关系,应尽量满足第三范式。

但是，满足第三范式的数据库设计，往往不是最好的设计。

为了提高数据库的运行效率，常常需要降低范式标准：

适当增加冗余，达到以空间换时间的目的。

三个范式：

　　通俗地理解三个范式，对于数据库设计大有好处。

在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式（通俗地理解是够用的理解，并不是最科学最准确的理解）：

第一范式：

1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；

第二范式：

2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；

第三范式：

3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。

没有冗余的数据库设计可以做到。

但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。

具体做法是：

在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。

降低范式就是增加字段，允许冗余。

3.1.1.5识别与正确处理多对多的关系

　　若两个实体之间存在多对多的关系，则应消除这种关系。

消除的办法是，在两者之间增加第三个实体。

这样，原来一个多对多的关系，现在变为两个一对多的关系。

要将原来两个实体的属性合理地分配到三个实体中去。

这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。

一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。

3.1.1.6主键PK的取值方法

　　PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串,由程序自动加1来实现。

也可以是有物理意义的字段名或字段名的组合。

不过前者比后者好。

当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。

3.1.1.7中间表、报表和临时表

　　中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键（数据仓库除外）。

临时表是程序员个人设计的，存放临时记录，为个人所用。

基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。

3.1.1.8完整性约束

　　域的完整性：

用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。

　　参照完整性：

用PK、FK、表级触发器来实现。

　　用户定义完整性：

它是一些业务规则，用存储过程和触发器来实现。

3.1.2数据库表设计原则

3.1.2.1先局部后整体

不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；

不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。

3.1.2.2领域模型驱动

采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。

对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。

并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。

3.1.2.3满足范式标准

根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：

一个表中的所有非关键字属性都依赖于整个关键字。

关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。

在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。

由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：

一个表应满足第二范式，且属性间不存在传递依赖。

同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1－N或N－N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。

在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。

这时，应根据反向工程的思路反馈给领域模型。

如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。

第四范式：

一个表如果满足BCNF，不应存在多值依赖。

在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。

并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。

当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。

这是一个折中的方案。

3.1.2.4建立索引

应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。

虽然建立索引会消耗部分系统资源，但比较起在检索时搜索整张表中的数据尤其是表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。

3.1.2.5平衡考虑存储过程

尽量少采用存储过程，目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。

但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过程。

3.1.2.6表关联约束设计

当处理表间的关联约束所付出的代价（常常是使用性上的代价）超过了保证不会出现修改、删除、更改