数据库模型设计

⑴ 数据库设计概念模型图，逻辑模型图分别是什么

1.1.概念来模型(E-R图描述)
概念模型是对真实自世界中问题域内的事物的描述，不是对软件设计的描述。
表示概念模型最常用的是"实体-关系"图。
E-R图主要是由实体、属性和关系三个要素构成的。在E-R图中，使用了下面几种基本的图形符号。
实体，矩形
E/R图三要素 属性，椭圆形
关系，菱形
关系：一对一关系，一对多关系，多对多关系。
E/R图中的子类(实体)：
1.2.逻辑模型
逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。
1.3.物理模型
物理模型是对真实数据库的描述。数据库中的一些对象如下：表，视图，字段，数据类型、长度、主键、外键、索引、是否可为空，默认值。
概念模型到物理模型的转换即是把概念模型中的对象转换成物理模型的对象。

⑵ 数据库物理模型

数据库物理模型设计的目标是根据选定的Oracle数据库系统特点和航空物探数据管理与服务的业务处理需求，确定航空物探数据库最优的物理环境、存取方法和存储结构。即通过数据库物理设计，以便达到物理数据库结构的优化，使得在数据库上运行的各种事务响应时间少、存储空间利用率高、事务吞吐率大。

一、数据库布局

航空物探信息系统的维护数据（部门、岗位、人员、人员权限、数据入库检查规则及数据字典等）相对比较稳定。入库前数据需经过各种检查校对，确认数据正确后才能归档，存入航空物探资料数据库，所以存入资料库前的数据可能经常需要修改和删除，相对变化较大；而存入资料数据库中的数据一般不允许修改和删除，以免误操作破坏资料库数据造成损失。

图2-12 航空物探数据库逻辑模型

图2-13 航空物探数据库布局与数据采集流程图

据此，我们采用图2-13所示的数据库数据采集流程，并将航空物探数据库分为资料采集数据库、资料数据库、系统维护数据库分别进行存储和管理，实现数据的统一管理和统一使用，便于数据入库和易于维护等。

航空物探资料数据库是航空物探所有数据最终存储的场所。资料采集数据库是数据归档存入资料数据库前的临时“集散地”，在此接收各项检查，在确认数据无误后归档到资料数据库，然后删除资料采集数据库中已归档的数据。此外，资料采集数据库中还保存数据入库、维护、检查日志及归档记录。

系统维护数据库，存储系统维护信息（如系统功能、数据库表清单等）、安全信息（如信息系统用户的角色、权限、授权的系统功能等），数据字典、入库数据检查规则等。将其与航空物探数据分开，有利于系统维护和管理。

二、数据库空间设置

数据库空间设置包括磁盘空间设置、应用系统表空间设置、撤销表空间、临时表空间、日志空间和索引空间设置。

（一）磁盘空间设置

磁盘空间设置的目标：磁盘性能不能阻碍实现数据库性能，数据库磁盘必须专用于数据库文件，否则非数据库将会影响到数据库性能，且磁盘空间必须满足恢复和性能的要求。

航空物探数据库服务器为IBM P620小型机，8块硬盘，每块硬盘36GB空间，每块物理磁盘建立一个文件系统。为了提高磁盘的反应时间和寻道时间，提高I/O的存取效率，除了一块硬盘用于UNIX操作系统外，其余7块磁盘分别存放资料采集数据库、系统维护数据库-日志文件，资料数据库及资料数据库的大字段数据、索引、回滚段和数据日志文件。

（二）应用系统表空间设置

信息系统数据采集过程对数据的事务操作比较频繁，经常进行数据插入（新数据入库）、修改（入库数据有误）和删除操作（数据重新导入或归档入库），因此航空物探资料采集数据库所在的表空间会很活跃。为了不影响其他I/O的竞争，同时也可以提高数据入库的操作效率（50多年的历史数据需要集中入库），分配一个磁盘空间（36GB）为采集库的表空间。由于采集数据归档入资料库后被删除，同时进行数据入库的项目也不是很多，虽仍保留所有的采集日志数据，一个磁盘空间也足够使用。

航空物探资料数据库的二维表和Oracle大字段（BLOB）分别存放在不同的物理磁盘（每个磁盘36GB）上，对同时存在有表格数据和大字段数据的数据库表（如航迹线数据）时，可以提高磁盘I/O效率。随着数据入库的项目越来越多，需要增加相应的物理磁盘或磁盘阵列。

系统维护数据库相对稳定，占用磁盘空间约500 M左右。由于系统磁盘有限，把日志文件存放该磁盘中。

（三）撤销表和临时表空间的设置

在Oracle数据库中，撤销的目的是确保事务的回退和恢复。撤销参数有UNDO_MANAGEMENT、UNDO_TABLESPACE和UNDO_RETENTION。

UNDO_MANAGEMENT参数用于数据库中管理撤销数据的方式，航空物探数据库设置为自动模式（auto）。

UNDO_TABLESPACE参数用于指定数据库中保存撤销数据的撤销表空间名称，航空物探数据库撤销表空间名称为UNDO_ARGS_TBSPACE，空间大小设置为20GB，以确保在保留时间内进行恢复。

UNDO_RETENTION参数用于指定已经提交事务的撤销数据在能够覆盖之前应该保留多长时间，本数据库系统设置为60 min。

临时表空间是用以存储大量的排序，与撤销表空间存放在一个物理磁盘上，本数据库系统临时表空间设置为500 M。

（四）日志空间设置

日志的主要功能是记录对数据库已做过的全部操作。在系统出现故障时，如果不能将修改数据永久地写入数据文件，则可利用日志得到该修改，所以不会丢失已有操作结果。

日志文件主要是保护数据库以防止故障。为了防止日志文件本身的故障，航空物探数据库系统分别在一个独立磁盘和系统维护库磁盘中存放日志文件。若系统出现故障，在下次打开数据库时Oracle数据库系统自动用日志文件中的信息来恢复数据库文件。

根据航空物探数据库信息系统同时登录的用户数及使用的功能，将日志文件大小设置为10GB。

（五）索引表空间设置

为了提高航空物探信息系统的查询和统计速度，把所有索引空间与应用表空间完全分开，从而提高I/O存取效率。航空物探索引表空间大小设置为10GB。

聚集是表的一种存储方法，一般每个基本表是单独组织的，但对逻辑上经常在一起查询的表，在物理上也邻近存放，这样可减少数据的搜索时间，提高性能。

当几个关系（表）以聚集方式组织时，是通过公共属性的值为表聚集的依据。航空物探数据库系统是以项目标识（PROJ_ID）建立聚集的，所有涉及项目标识的数据库表直接引用项目标识聚集。航空物探聚集表空间与索引表空间相同。

三、数据库参数设置

在数据库创建前需要对如下数据库参数进行设置，航空物探参数文件名为Initoraargs.ora，各种参数设置如下：

航空物探信息系统建设

四、内存设置

航空物探数据库服务器物理内存为4GB，除部分用于系统开销外，其余全部用于数据库。

Oracle使用共享系统全局区（System Global Area，SGA）内存来管理内存和文件结构，包含DB_block_Buffers、DB_cache_size、Shared_pool_size、Log_Buffer参数。航空物探数据库系统的全局区内存参数设置如下。

DB_block_Buffers参数为SGA中存储区高速缓存的缓冲区数目，每个缓冲区的大小等于参数DB_block_size的大小，DB_block_Buffers=19200（约300 MB）。

Shared_pool_size参数为分配给共享SQL区的字节数，是SGA大小的主要影响者，Shared_pool_size=1228800000（1.2GB）。

DB_cache_size参数是SGA大小和数据库性能的最重要的决定因素。该值较高，可以提高系统的命中率，减少I/O，DB_cache_size=1024000000（1GB）。

Log_Buffer参数为重做日志高速缓存大小，主要进行插入、删除和修改回退操作，Log_buffer=5120000（5MB）。

五、优化设置

由于航空物探信息系统的采集软件和应用软件是采用MS.NET C＃进行开发的，应用程序与数据库之间的连接有传统的ODBC和OLE DB两种方式。为了支持ODBC在OLE DB技术上建立了相应的OLE DB到ODBC的调用转换，而使用直接的OLE DB方式则不需转换，从而提高处理速度。

在建立数据库表时，参数Pctfree和Pctused设置不正确可能会导致数据出现行链接和行迁移现象，即同一行的数据被保存在不同的数据块中。在进行数据查询时，为了读出这些数据，磁头必须重新定位，这样势必会大大降低数据库的执行速度。因此，在创建表时应充分估计到将来可能出现的数据变化，正确地设置这两个参数，尽量减少数据库中出现的行链接和行迁移现象。

航空物探资料采集数据库表的插入、修改和删除的频率较高，Pctfree设置为20，Pctused设置为40；系统维护数据库表相对稳定，Pctfree设置为10，Pctused设置为15；资料数据库表除了增加数据外基本不进行修改和删除操作，Pctfree设置为10，Pctused设置为5。

六、扩展性设置

多CPU和并行查询PQO（Parallel Query Option）方式的利用：CPU的快速发展使得Oracle越来越重视对多CPU的并行技术的应用，一个数据库的访问工作可以用多个CPU相互配合来完成。对于多CPU系统尽量采用并行查询选项方式进行数据库操作。航空物探数据库服务器为2个CPU，在程序查询中采用了并行查询的方式。

在航空物探工作量统计、飞行小时统计、测量面积统计和岩石物性统计中，为了加快统计效率，在相应的查询语句中增加了并行查询语句。

随着航空物探高精度测量程度的不断提高，测量数据将越来越大。为了满足航空物探查询效率及发展，将航磁测量数据与校正后航磁测量数据按比例尺分1∶20 万以下、20万～50万、1∶50万以上分别存放3张不同的数据库表。

七、创建数据库

在完成数据库布局、空间设置、内存设置、数据库参数设置、扩展性设置和优化设置后，进行航空物探数据库物理模型设计，即航空物探数据库实体创建。由于航空物探空间数据库逻辑模型是采用ESRI提供的ArcGIS UML构建的Geodatabase模型，因此，使用ESRI公司提供的CaseTools将航空物探数据UML模型图转成空间数据库（Geodatabase）实体（图2-14）。

航空物探属性数据库表（二维表）是采用Power Designer数据库设计平台直接把数据库关系模型生成数据库脚本来创建的。

经过数据库的概念设计、逻辑设计和物理设计，最终生成航空物探数据库。

图2-14 航空物探数据库物理模型实现

八、空间数据的索引机制

对于海量的空间数据库而言，数据库的操作效率是关系到数据库成败的关键问题。为了提高数据的访问、检索和显示速度，数据在加载到数据库时，要素类数据建立了空间索引，栅格数据构建了金字塔结构，对象类数据采用与数据库直接联接的访问机制。

（一）空间索引

为了提高要素类数据的查询性能，在建立航空物探空间数据库时，创建了空间索引机制。常用的空间索引有格网索引、R树索引、四叉树索引等。Geodatabase采用格网索引方式。所谓格网索引是将空间区域划分成适合大小的正方形格网，记录每一个格网内所包含的空间实体（对象）以及每一个实体的封装边界范围，即包围空间实体的左下角和右上角坐标。当用户进行空间查询时，首先计算出用户查询对象所在格网，然后通过格网编号，就可以快速检索到所需的空间实体。

确定适合的格网级数、单元大小是建立空间格网索引的关键。格网太大，在一个格网内有多个空间实体，查询检索的准确度降低。格网太小，则索引数据量成倍增长和冗余，检索的速度和效率较低。数据库的每一数据层采用不同大小、不同级数的空间索引格网单元，但每层最多级数不能超过三级。格网单元的大小不是一个确定性的值，需要根据对象的大小确定。空间索引格网的大小与检索准确度之间的关系如图2-15所示。

选择格网单元的大小遵循下列基本原则：

1）对于简单要素的数据层，尽可能选择单级索引格网。减少RDBMS搜索格网单元索引的级数，缩短空间索引搜索的过程，例如航迹线要素类。

图2-15 索引格网大小与检索准确度的关系

2）如果数据层中的要素封装边界大小变化比较大，应选择2或3级索引格网。Geodatabase最多提供三级格网单元。每一要素封装边界在适合的级内，减少了每一封装边界有多个格网的可能性。在空间索引搜索过程中，RDBMS则必须搜索所有3个格网单元级，这将消耗大量的时间。

3）若用户经常对图层执行相同的查询，最佳格网的大小应是平均查寻空间范围的1.5倍。

4）格网的大小不能小于要素封装边界的平均大小，为了减少每个格网单元有多个要素封装边界的可能性，格网单元的大小应取平均格网单元的3倍。最佳格网单元的大小可能受图层平均查询的影响。

空间域是按照要素数据集定义的，空间索引格网是按照要素类设置的。它们都是在创建Geodatabase数据库时设置，并一经设置，中间不许改变；所以一定要在充分分析数据的情况下确定它们的值。航空物探数据主要是简单要素类，空间跨度为70°。根据上述原则，航空物探数据选择单级索引格网，格网大小为20°。

（二）金字塔结构

金字塔结构的核心是将栅格数据逐级进行抽稀，形成多级分辨率的重采样数据，并将其分割成块，按一定的文件格式（金字塔文件格式）存储成磁盘文件；在以后进行图像显示处理时，只需将要显示的部分所覆盖的块从磁盘文件直接读进内存缓冲区显示即可。从金字塔的所有层中寻找与所要求显示的比例相近或匹配的一层，并将该层的从某一点起的一定范围的图像所覆盖的所有块加载到内存缓冲区，提取所需部分并形成图像。

金字塔算法（图2-16）是通过获取显示时所需要的一定分辨率的数据来提高显示速度。使用金字塔数据格式后，在显示全图时仅需要显示一个较低分辨率的数据，这样既能加快显示速度，又不会影响显示效果。放大图像，尽管显示图像分辨率提高，由于显示区域减小，所以显示速度不会下降。如果没有为栅格数据建立金字塔数据，则每次显示都会读取整个数据，然后进行重采样得到显示所需要的分辨率，明显地降低了显示速度。

图2-16 金字塔压缩示意图

金字塔数据重采样方式有：最近邻法、双线性内插和立方卷积。其中最近邻法适用于离散数据，而双线性内插法和立方卷积法适合于连续数据。

在ArcGIS Engine中提供了IRasterPyramid和IRasterPyramid2接口来实现金字塔数据的建立，而建立的数据保存在*.rrd格式的文件中。

（三）空间域定义

空间域是指数据的有效空间范围，即Geodatabase数据库的最大等效坐标的值域范围，其定义主要是指比例系数和Min X、Min Y的计算。

因为使用整数比浮点数有更高的压缩率，并且对整数进行二进制搜索比较快，所以多用户Geodatabase以4字节正整数存储坐标，其最大值为32位正整数所能表示的范围是21.4亿（2147483647），整数的范围称为空间域。在创建Geodatabase数据库时需要定义合适的比例系数。大的整数值将消耗大量的计算机物理内存，所以选定的比例系数最好不要大于必须的比例系数。空间域随坐标系的单位变化而变化。

比例系数和空间域之间成反比例关系，比例系数越大（存储单位越小），表达的空间域也越小。为了使目标数据都存储在系统中，需要谨慎地设置比例系数。将目标数据的宽度和高度较适中的数值乘以比例系数，如果结果小于21.4亿，则比例系数是合适的。

航空物探数据模型是为我国的航空物探行业数据建库设计的，它支持的空间数据的坐标范围为我国领土覆盖的海陆空间，最低纬度为赤道。根据概念设计的分析，航空物探数据模型采用的是地理坐标系，坐标系单位是度，基准是Beijing_1954，要求存储的坐标数据精度达到0.01 m。在赤道处，赤道圆周长为40075694.6 m，则每度弧长=40075694.6×100/360 cm=11132137.389 cm，即1 cm对应8.983000883E-8°。所以，航空物探数据模型的比例系数取为8.98E-8，即存储单位为8.98E-8°，可满足1 cm精度要求。

将空间域移动到目标数据范围之前，首先找到空间域在存储单位的中心位置，目的是在必要时向各个方向扩展。4字节正整数可表示的坐标范围：2147483647×8.98E-8=192.84°。我国的领土范围是东经70°～140°，北纬0°～60°。所以，选取的比例系数是合适的。把空间域坐标系中心定为90°，然后，计算空间域的Min X、Min Y。

航空物探信息系统建设

航空物探信息系统建设

所以坐标的存储数据是：

航空物探信息系统建设

航空物探信息系统建设

⑶ 数据库模型图和ER图区别是什么

ER图是属于概念模型它与具体的DBMS无关。
从你的截图上来看，截图里的所说的数据库模型图版是不准确的权，正确的是ER模型转换为关系模型。
因为ER图是属于概念设计阶段，它的下一阶段就是转换成关系模型，也就说与具体的DBMS有关。

下面是数据库设计的常见四阶段：
第一阶段：用户需求分析；
第二阶段：概念设计(即E-R模型)； 与具体的DBMS无关
第三阶段：关系模型； 与具体的DBMS有关
第四阶段：物理模式。

⑷ 数据库设计时的概念数据模型一般用什么图表示

通过数据抽象，设计系统概念模型，一般为E-R模型

数据库设计一般分6个阶段：
1、需求分析：了解用户的数据需求、处理需求、安全性及完整性要求；
2、概念设计：通过数据抽象，设计系统概念模型，一般为E-R模型；
3、逻辑结构设计：设计系统的模式和外模式，对于关系模型主要是基本表和视图；
4、物理结构设计：设计数据的存储结构和存取方法，如索引的设计；
5、系统实施：组织数据入库、编制应用程序、试运行；
6、运行维护：系统投入运行，长期的维护工作。

⑸ er数据模型一般在数据库设计的什么阶段使用

er数据模型一般在数据库设计的概念结构设计阶段使用。ER模型常用于信息系专统设计中；比如它们属在概念结构设计阶段用来描述信息需求和/或要存储在数据库中的信息的类型。

但是数据建模技术可以用来描述特定论域（就是感兴趣的区域）的任何本体（就是对使用的术语和它们的联系的概述和分类）。在基于数据库的信息系统设计的情况下，在后面的阶段（通常叫做逻辑设计），概念模型要映射到逻辑模型如关系模型上；它依次要在物理设计期间映射到物理模型上。注意，有时这两个阶段被一起称为“物理设计”。

(5)数据库模型设计扩展阅读

E-R模型的构成成分是实体集、属性和联系集

其表示方法如下：

（1） 实体集用矩形框表示，矩形框内写上实体名。

（2） 实体的属性用椭圆框表示，框内写上属性名，并用无向边与其实体集相连。

（3） 实体间的联系用菱形框表示，联系以适当的含义命名，名字写在菱形框中，用无向连线将参加联系的实体矩形框分别与菱形框相连，并在连线上标明联系的类型，即1—1、1—N或M—N。

⑹ 请简要的叙述一下数据库的主要设计过程

一、数据库设计过程

数据库技术是信息资源管理最有效的手段。

数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。

数据库设计的各阶段：

A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。

B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。

C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。

D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

1. 需求分析阶段

需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。

需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。

需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。

常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。

分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis，简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。

数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。

2. 概念结构设计阶段

通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。

概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。

概念模型特点：

(1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。

(2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。

概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

2.1 第零步——初始化工程

这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。

2.2 第一步——定义实体

实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有 “代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。

2.3 第二步——定义联系

IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系(强制的或可选的)还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。

2.4 第三步——定义码

通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图(KB图)。

2.5 第四步——定义属性

从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。

2.6 第五步——定义其他对象和规则

定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。

3. 逻辑结构设计阶段

将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。

将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。

数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：

表内的每一个值都只能被表达一次。

表内的每一行都应该被唯一的标识(有唯一键)。

表内不应该存储依赖于其他键的非键信息。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

4. 数据库物理设计阶段

为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

5. 数据库实施阶段

运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行 ，(Data Definition Language(DDL数据定义语言)用作开新数据表、设定字段、删除数据表、删除字段，管理所有有关数据库结构的东西)

●Create (新增有关数据库结构的东西，属DDL)

●Drop (删除有关数据库结构的东西，属DDL)

●Alter (更改结构，属DDL)

6. 数据库运行和维护阶段

在数据库系统运行过程中必须不断地对其进行评价、调整与修改。内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

7. 建模工具的使用

为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。

ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用 ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。

设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构;画数据流图，生成应用程序。

二、数据库设计技巧

1. 设计数据库之前(需求分析阶段)

1) 理解客户需求，包括用户未来需求变化。

2) 了解企业业务类型，可以在开发阶段节约大量的时间。

3) 重视输入(要记录的数据)、输出(报表、查询、视图)。

4) 创建数据字典和ER 图表

数据字典(Data Dictionary，简称DD)是各类数据描述的集合，是关于数据库中数据的描述，即元数据，不是数据本身。(至少应该包含每个字段的数据类型和在每个表内的主外键)。

数据项描述: 数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系

数据结构描述: 数据结构名，含义说明，组成:[数据项或数据结构]

数据流描述: 数据流名，说明，数据流来源，数据流去向， 组成:[数据结构]，平均流量，高峰期流量

数据存储描述: 数据存储名，说明，编号，流入的数据流，流出的数据流，组成:[数据结构]，数据量，存取方式

处理过程描述: 处理过程名，说明，输入:[数据流]，输出:[数据流]，处理:[简要说明]

ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。

5) 定义标准的对象命名规范

数据库各种对象的命名必须规范。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

2. 表和字段的设计(数据库逻辑设计)

表设计原则

1) 标准化和规范化

数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。

2) 数据驱动

采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。

举例，假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等)，不妨把相应的连接和路径信息存储在用户界面支持的表里。如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等)，那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

3) 考虑各种变化

在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。

4) 表名、报表名和查询名的命名规范

(采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。你可以统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象(比如 tbl_Employees)。用 sp_company 标识存储过程，用 udf_ (或者类似的标记)标识自定义编写的函数。

字段设计原则：

1) 每个表中都应该添加的3 个有用的字段。

dRecordCreationDate，在SQL Server 下默认为GETDATE()

sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER

nRecordVersion，记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因

时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。

2) 对地址和电话采用多个字段

描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

3) 表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名

对列[字段]名应该采用标准的前缀和后缀。如键是数字类型：用 _N 后缀;字符类型：_C 后缀;日期类型：_D 后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

假设有两个表：

Customer 和 Order。Customer 表的前缀是 cu_，所以该表内的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前缀是 or_，所以子段名是：

or_order_id、or_cust_name_id、or_quantity 和 or_description 等。

这样从数据库中选出全部数据的 SQL 语句可以写成如下所示：

Select * From Customer, Order Where cu_surname = "MYNAME" ;

and cu_name_id = or_cust_name_id and or_quantity = 1

在没有这些前缀的情况下则写成这个样子(用别名来区分)：

Select * From Customer, Order Where Customer.surname = "MYNAME" ;

and Customer.name_id = Order.cust_name_id and Order.quantity = 1

第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了。

5) 选择数字类型和文本类型的长度应尽量充足

假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

6) 增加删除标记字段

在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。

7) 提防大小写混用的对象名和特殊字符

采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA)，绝对不要在对象名的字符之间留空格。

8) 小心保留词

要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，用 DESC 作为说明字段名。后果可想而知!DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用，但得到的却是一大堆毫无用处的信息。

9) 保持字段名和类型的一致性

在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在表1中叫做“agreement_number”，就别在表2里把名字改成 “ref1”。假如数据类型在表1里是整数，那在表2里可就别变成字符型了。当然在表1(ABC)有处键ID，则为了可读性，在表2做关联时可以命名为 ABC_ID。

10) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

3. 选择键和索引(数据库逻辑设计)

参考：《SQL优化-索引》一文

4. 数据完整性设计(数据库逻辑设计)

1) 完整性实现机制：

实体完整性：主键

参照完整性：

父表中删除数据：级联删除;受限删除;置空值

父表中插入数据：受限插入;递归插入

父表中更新数据：级联更新;受限更新;置空值

DBMS对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发器实现机制用户定义完整性：

NOT NULL;CHECK;触发器

2) 用约束而非商务规则强制数据完整性

采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键) 的完整性所以不能强加于其他完整性规则之上。如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。

3) 强制指示完整性

在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

4) 使用查找控制数据完整性

控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。

5) 采用视图

为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

6) 分布式数据系统

对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年或者 10 年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一些标记，在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。

7) 关系

如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。

8) 给数据保有和恢复制定计划

考虑数据保存策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。

9) 用存储过程让系统做重活

提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

5. 其他设计技巧

1) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

2) 使用常用英语(或者其他任何语言)而不要使用编码

在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。

3) 保存常用信息

让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。

4) 包含版本机制

在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。

5) 编制文档

对所有的快捷方式、命名规范、限制和函数都要编制文档。

采用给表、列、触发器等加注释的 数据库工具。对开发、支持和跟踪修改非常有用。

对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。

6) 测试、测试、反复测试

建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。

7) 检查设计

在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

三、数据库命名规范

1. 实体(表)的命名

1) 表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则(比方说，如果表名是一个单词，别名就取单词的前4 个字母;如果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名;如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4 字母长的别名，其余依次类推)

对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意：将字段名称会统一成大写或者小写中的一种，故中间加上下划线。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

举例：

定义的缩写 Sales: Sal 销售;

Order: Ord 订单;

Detail: Dtl 明细;

则销售订单明细表命名为：Sal_Ord_Dtl;

2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。

举例：

定义的缩写 Material Ma 物品;

物品表名为：Material, 而不是 Ma.

但是字段物品编码则是：Ma_ID;而不是Material_ID

3) 所有的存储值列表的表前面加上前缀Z

目的是将这些值列表类排序在数据库最后。

4) 所有的冗余类的命名(主要是累计表)前面加上前缀X

冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表

5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。

关联表用于保存多对多关系。

如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。

举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object;

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

2. 属性(列)的命名

1) 采用有意义的列名

表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义;

A、如果是数据库自动生成的编码，统一命名为：ID

B、如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名，即“XXXX_ID”

C、如果键是数字类型，你可以用_NO 作为后缀;

D、如果是字符类型则可以采用_CODE 后缀

E、对列名应该采用标准的前缀和后缀。

举例：销售订单的编号字段命名：Sal_Ord_ID;如果还存在一个数据库生成的自动编号，则命名为：ID。

2) 所有的属性加上有关类型的后缀

注意，如果还需要其它的后缀，都放在类型后缀之前。

注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。

3) 采用前缀命名

给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。

3. 视图的命名

1) 视图以V作为前缀，其他命名规则和表的命名类似;

2) 命名应尽量体现各视图的功能。

4. 触发器的命名(尽量不使用)

触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加'_I'，Delete触发器加'_D'，Update触发器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。

5. 存储过程名

存储过程应以'UP_'开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为'UP_Ins_Agent_Account'。

6. 变量名

变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。

7. 命名中其他注意事项

1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29(不包括标识字符@)。

2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。

3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突

4) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。

⑺ 数据库逻辑模型

数据库关系模型(数据库逻辑模型)是将数据概念模型转换为所使用的数据库管理系统(DBMS)支持的数据库逻辑结构,即将E-R图表示成关系数据库模式。数据库逻辑设计的结果不是唯一的,需利用规范化理论对数据库结构进行优化。

在关系模型中,数据库的逻辑结构是一张二维表。在数据库中,满足下列条件的二维表称为关系模型:

1)每列中的分量是类型相同的数据;

2)列的顺序可以是任意的;

3)行的顺序可以是任意的;

4)表中的分量是不可再分割的最小数据项,即表中不允许有子表;

5)表中的任意两行不能完全相同。

由此可见,有序的航空物探测量剖面数据不满足数据库关系模型条件第3条“行的顺序可以是任意的”,因此,不能简单地直接利用关系数据库(如Oracle,SQL Server,Sybase等)来管理剖面数据,需将数据在数据库中的存储方式改为大字段存储,确保不因数据库数据的增加和删除等操作改变剖面数据有序特性。

一、大字段存储

(一)大字段存储技术

大字段LOB(Large Object)技术是Oracle专门用于存放处理大对象类型数据(如多媒体材料、影像资料、文档资料等)的数据管理技术。LOB包括内部的和外部的两种类型。内部LOB又分CLOB(字符型)、BLOB(二进制型)等3种数据类型,其数据存储在数据库中,并且支持事务操作;外部LOB只有BFILE类型,其数据存储在操作系统中,并且不支持事务操作。LOB存放数据的长度最大可以达到4G字节,并且空值列(没有存放数据)不占空间(图2-6)。

图2-6 大字段存储示意图

由于外部LOB存放在操作系统文件中,其安全性比内部LOB差一些。此外,大字段的存储支持事务操作(批量提交和回滚等),而外部LOB不支持事务操作。所以,航空物探测量剖面数据采用BLOB来存储。对于BLOB类型,如果数据量小于4000字节,数据库通常采用行内存储,而数据量大于4000字节采用行外存储。分析航空物探测量剖面数据,每个场值数据占4个字节(单精度),目前航磁数据采样率为10次/s,4000字节只能存储100s数据;一般情况下航空物探测量每条测线飞行时间至少在10min以上,每条测线数据量远远大于4000字节。所以,航空物探测量剖面数据采用行外存储方式,即大字段列指定“Disable Storage In Row”的存储参数。

由于大字段类型长度可变,最大可到4G。假设测线飞行时间为T,场值采样率为n次/s,测线场值数据量为4Tn,所以有4Tn≤4G。单条测线飞行时间T不会超过10h(36000s,航空物探测量1架次至少飞行1个往返2条测线),则场值的采样率n≤4G/4T=4×1024×1024×1024/4×36000次/s=29826次/s。采用大字段来存储测量数据,不仅能够减少数据表的记录数,提高查询效率,而且使得采样率的扩展不受限制。

(二)大字段存储技术应用

由于航空物探数据的数据量较大,现有的航磁测量数据按基准点方式(点存储)存储可达几亿个数据记录。若按磁场数据采样点存储方式(简称“场值存储方式”),则记录条数=(磁场数据采样率/坐标采样率)点存储方式的记录数,达几十亿条数据记录,且随着数据采样率的扩展、测点的加密,航空物探测量数据量随着时间的推移呈现快速增长之势。显然,如果采用常规的表结构来存储,势必造成数据的存储、管理、检索、浏览和提取都非常困难。另一方面,从航空物探专业应用需求来说,很少对单个测点的场值数据进行运算、分析等操作,一般至少是对一条测线或以上测线,多数时候是需要对整个测区的场值数据进行化极、上延、正反演拟合等。

因此,在航空物探数据库表结构设计时,改变过去将基准点或场值点数据记录作为数据库最小管理对象的理念,采用了大字段存储技术,将测线作为数据库最小管理对象,将测线上的测量数据,如坐标数据和磁场、重力场数据分别存储在相应大字段中。在航空物探数据库建设中,大量采用数据库的大字段存储技术(详见《航空物探信息系统数据库结构设计》)。

(三)大字段存储效率

以航磁测量数据为例分析大字段存储技术优势。如果以场值存储方式存储测线数据,则每条记录包含架次号、测线号、基准号、地理坐标、投影坐标、磁场数据等,由于坐标数据采样率2次/s,磁场数据采样率10次/s,每5个磁场数据中,只有第1个磁场数据有坐标数据,其他4个坐标数据是内插出来,因此在测线记录中会产生大量冗余的数据坐标数据。采用点存储方式存储的测线数据记录数等于线上基准点数,若采用大字段存储方式,一条测线数据只存储为1条数据记录(图2-7),一般一条测线的测点数近万个,甚至更多,可见采用大字段存储大大减少测线数据存储记录数,提高数据的存取效率。

以某测区的两条航迹线为例,分别采用3种方式测试数据库的数据存储效率。磁场数据的采样率10次/s,坐标数据采样率2次/s,两条测线上共有基准点8801个。以场值方式存储先内插坐标信息,使得每个场值数据都拥有自己的坐标,然后存入数据库,共有数据记录44005条,写入数据库时间为57.22s,读取时间为1.03s。第二种方式是以采样点的方式进行存储,共有8801条记录,写入数据库时间为9.47s,读取需要0.91s。第三种方式是以大字段的形式存储,只有2条记录,写入数据库1.03s,读取时间为0.44s(表2-2)。大字段数据存储记录数最少,存取效率最高。用整个测区数据测试效果更加明显。

表2-2 三种数据存储方法的存取效率比较

图2-7 大字段存储方式示意图

二、联合主键

主外键是关系型数据库建立表间关系的核心。在航空物探空间数据库建设过程中,要素类与要素类之间、要素类与对象类之间,以及对象类与对象类之间的关系的描述有3种形式,即拓扑关系——描述要素类与要素类之间结点、邻接和联通关系;叠加关系——描述要素类与要素类之间的相交、包含与分类关系;隶属关系——描述对象类与对象类之间的派生关系。前两种关系是采用空间数据模型建立的关系,而隶属关系是通过主键建立的对象类与对象类之间的关系。在建立一对一、一对多的表间关系时,需要在整个数据库表中确定具有唯一性的一个字段作为主键(主关键字)。

按照传统的航空物探数据的档案管理模式,每个项目分配一个自然数作为档案号,项目的所有资料均与此档案号相联系。勘查项目和科研项目的档案号是独立编号的,且均从001开始。加之人工管理的原因,存在1个项目2个档案号和2个项目1个档案号的情况,因此现行的档案号与项目之间的对应关系不具备唯一性,不能作为项目的唯一标识,即不能作为数据库表的主键。项目编号也不能作为数据库表的主键,项目编号也只是近十年的事,以前的项目没有项目编号。

综合考虑上述因素和项目具有分级、分类的特点,提出了构造项目唯一标识码(简称“项目标识”)的方法,并以此码作为数据库表的主键。

项目标识(主键):AGS+项目类别(2位)+项目起始年份(4位)+档案号(6位)

标识含义:AGS——航空物探的缩位代码;

项目类别——2位代码,01代表勘查项目、02代表科研项目;

起始年份—4位代码,项目开始年号;

档案号—6位代码,为了与传统的项目管理方式相衔接,后面3~4位是

项目档案管理模式下的档案号,不足部分补零。

以上15位编码是一级项目的项目标识,二级及其以下级别的项目标识是在上一级项目标识基础上扩展2位数字代码,中间用“.”号隔开,数字为该级项目的序号。项目标识定义为30位编码,适用于六级以内的项目。例如:AGS022004000576.08.04.02,表示该项目为2004年开展的档案号为576的航空物探科研项目(一级项目)的第8课题(二级项目)第4子课题(三级项目)的第2专题。由此可见,该项目标识不仅仅是一个建立表间关系的关键字,同时还表达了不同级别项目间的隶属关系。在系统软件开发时,利用此关系生成了项目的分级树形目录,用户对项目的层次关系一目了然,便于项目查询。

数据库的主键一经确定,相应地需要确定联合主键的组成及其表达方式。所谓联合主键就是数据资料的唯一标识,在一个数据库表中选择2个或者2个以上的字段作为主键。由于航空物探数据绝大部分与项目标识有关,加之数据的种类较多,分类复杂,单凭主键确定数据库表中记录的唯一性,势必需要构建极其复杂的主键,这种方法既不利于主键的数据操作,又会造成大量的数据冗余,合理地使用联合主键技术可以很好地解决资料唯一问题。以项目提交资料为例,提交的资料分为文字类资料、图件类资料和媒体类资料,我们对资料进行分类和编号,例如100代表文字资料(110——World文档,120——PDF文档),200代表图件资料(210——基础地理资料、220——基础地质资料,230——航迹线图,240——剖面图,250——等值线图等),300代表媒体资料(310——PPT文档,320——照片等),第1位(百位)表示该资料的类型,第2~3位表示该类资料的序号。

在数据库管理和项目资料查询时,采用项目标识与资料分类编号作为联合主键(图2-8),可以高效地实现复杂数据的查询。在整个数据库系统中多处(项目查询、数据提取等模块)使用联合主键技术。

图2-8 联合主键实例

三、信息标准化

为了实现数据共享,在航空物探数据库建模过程中,参考和引用了近百个国家信息化标准,编制了4个中心信息化标准和1个图件信息化工作指南。

(一)引用的国家信息化标准

1)地质矿产术语分类代码:地球物理勘查,地球化学勘查,大地构造学,工程地质学,结晶学及矿物学,矿床学,水文地质学,岩石学,地质学等。

2)国家基础信息数据分类与代码,国土基础信息数据分类与代码,地球物理勘查技术符号,地面重力测量规范,地面磁勘查技术规程,地面高精度磁测技术规程,大比例尺重力勘查规范,地理信息技术基本术语,地理点位置的纬度、经度和高程的标准表示法,地名分类与类别代码编制规则。

3)地球空间数据交换格式;数学数字地理底图数据交换格式;数字化地质图图层及属性文件格式。

(二)本系统建立的信息化标准

编写了“航空物探空间数据要素类和对象类划分标准”,“航空物探项目管理和资料管理分类代码标准”,“航空物探勘查分类代码标准”,“航空物探信息系统元数据标准”,“航空物探图件信息化工作指南”,以便与其他应用系统进行信息交换,实现数据库资料共享。

航空物探空间数据要素类和对象类划分标准:根据物探方法、数据处理过程以及推断解释方法和过程,把与GIS有关的数据划分为不同类型的要素类-对象类数据,按专业、比例尺、数据内容对要素类和对象类进行统一命名,使空间数据库中的每个要素类和对象类的命名具有唯一性,防止重名出现。规定要素类-对象类数据库表结构及数据项数值类型。

航空物探项目管理和资料管理分类代码标准:规定了航空物探项目管理和资料管理的相关内容,包括航空物探勘查项目和科研项目的项目立项、设计、实施、成果、评审、资料汇交等项目管理的全过程中的内容,以及项目成果资料和收集资料的归档、发送、销毁、借阅等资料管理与服务过程中的内容和数据项代码。

航空物探勘查分类代码标准:在“地质矿产术语分类代码地球物理勘查”(国家标准GB/T9649.28—1998)增加了航磁、航重专业方面所涉及的数据采集、物性参数、方法手段、仪器设备、资料数据解释及成图图件等内容和数据项代码。

航空物探信息系统元数据标准:规定了航空物探空间数据管理与服务的元数据(数据的标识、内容、质量、状况及其他有关特征)的内容。

四、航迹线数据模型

(一)航迹线模型的结构

航空物探测量是依据测量比例尺在测区内布置测网(测线和切割线)。当飞机沿着设计的测线飞行测量时,航空物探数据收录系统按照一定的采样率采集采样点的地理位置、高度和各种地球物理场信息。采用属性数据分置的方法,将测线地理位置信息从航空物探测量数据中分离出来,形成航迹线要素类表,在此表中只存储与航迹线要素类有关的数据,如项目标识、测区编号、测线号、测线类型(用于区分测线、切割线、不同高度线、重复线等)、坐标、高度值等;将航迹线的对象类数据(磁场、重力场基础数据)分别以大字段形式存储在各自的二维表中,它们共享航迹线,解决了多源有序不同采样率的航空物探测量数据的数据存储问题,在满足要素类空间查询的同时,统一数据的存储方式(图2-9)。航迹线要素类隶属于测区要素类,它们之间为空间拓扑(包含)关系。测区从属于勘查项目,每个勘查项目至少有一个测区,它们之间为1对多关系。有关项目信息存放在项目概况信息对象类表中,各种表之间通过项目标识进行联接。

图2-9 航迹线数据模型结构

(二)航迹线的UML模型

统一建模语言UML(Unified Modeling Language)是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。UML是面向对象技术领域内占主导地位的标准建模语言,成为可视化建模语言的工业标准。在UML基础上,ESRI定义了空间数据库建模的ArcGIS包、类库和扩展原则。

图2-10 与航迹线有关的数据库表逻辑模型结构图

在确定航迹线数据模型后,以它为基础,使用UML完成与航迹的有关的项目概况信息、测区信息、原始数据等数据库表逻辑模型设计(图2-10)。

由UML模型生成Geodatabase模式时,模型中的每个类都对应生成一个要素类或对象类。类的属性映射为要素类或对象类的字段。基类属性中包含的字段,在继承类中不需重复创建。例如,每个类都包括项目标识等字段,可以创建一个包含公共属性的基类,其他类从该类继承公共的属性,而无需重复建基类中包含的属性。因为基类没有对应的要素类或对象类,所以将基类设置为抽象类型。要素类之间的关系采用依赖关系表示。

五、数据库逻辑模型

关系数据库的逻辑结构由一组关系模式组成,因而从概念结构到关系数据库逻辑结构的转换就是将概念设计中所得到的概念结构(ER图)转换成等价的UML关系模式(图2-11)。在UML模型图中,要素数据集用Geodatabase工作空间下的静态包表示。要素集包不能互相嵌套,为了容易组织,在生成物理模型后,在要素数据集包中自定义嵌套。要素数据集与空间参考有关,但是空间参考不能在UML中表达。要素类和二维表都是以类的形式创建的,区别是要素类继承Feature Class的属性,而二维表继承Object属性。为了表达每种元素的额外属性,比如设置字符型属性字段的字符串长度,设置要素类的几何类型(点、线或面)需要使用Geodatabase预定义的元素标记值。

图2-11 逻辑设计关系转换

基于航空物探数据的内在逻辑关系进行分析,使用统一建模语言(UML)构建数据实体对象间的关系类,定义了航空物探数据库的逻辑模型(图2-12)。

⑻ 系统数据库和模型库设计

（一）系统数据库类型

数据库是整个农用地分等信息系统的基础，是系统开发设计要考虑的重中之重。在数据形式上，系统数据库包括两大块：一是空间数据库，二是属性数据库。目前的空间数据技术已从以MapInfo为代表的混合型数据库（空间数据库＋关系型数据库）发展到以ArcInfo的Coverage为代表的拓展型数据库。鉴于农用地分等属性数据量庞大，为减少数据冗余，提高数据检索的速度，本研究采用空间数据和属性数据分开管理的模式，依据关键字段进行绑定，进行科学索引，从而实现空间数据和属性动态链接和高效整合。

1.空间数据库

江苏省农用地分等信息系统空间数据库内容包括以下方面：

（1）土地利用现状图层：全省13个省辖市以1996年土地利用现状图为基础，经变更调绘形成以2000年为基准年的土地利用现状图，以现行的土地分类标准按八大类分类进行信息提取并分层存储，系统分别存储为耕地、林地、水域、未利用地、建设用地等图层。

（2）全省土壤类型图层：以土属为分类单位，比例尺为1:20万。

（3)1996年和2000年全省行政区划图层：在行政区划中精确到乡镇级别，分别提取存储了市名图层、县（区）名图层、乡（镇）名图层、全省行政界线图层、市级行政界线图层、县（区）级行政界线图层、乡（镇）级行政界线图层。

（4）评价单元图层：通过GIS空间叠加功能，利用土地利用现状图、行政区划图和土壤类型图叠加产生的评价单元图层，建立分等评价单元数据库。

2.属性数据库

江苏省农用地分等信息系统属性数据库内容包括以下方面：

（1）土壤属性数据：以全国第二次土壤普查为基础，结合全省土壤监测样点数据，建立土壤质量状况数据库，最小单位为土种，包括pH值、有机质含量、表层土壤质地、耕层厚度、障碍层深度、水土侵蚀程度、盐渍化程度数据。

（2）农田水利环境数据：建立了1996～2000年间各乡镇农田水利环境基础数据库，包括灌溉保证率、排水条件数据。

（3）土地利用现状数据：建立了全省13个省辖市的以1996年土地利用现状图为基础，经变更调绘形成的以2000年为基准年的土地利用现状数据库，区分耕地中的详细用地类型差异，标示水田、旱地、荒草地等纳入本次评价范围的用地内容。

（4）全省地形地貌数据库。

（5）农业区划数据：输入了江苏省农业区划数据，把江苏全省划分为6大区划，以乡镇为最小级别，建立全省乡镇的区划归属数据库。

（6）农业耕作制度数据：建立了全省各市、县、乡镇的农业耕作制度数据库，包括指定作物水稻和小麦的播种空间分布状况数据库。

（7）光温生产潜力数据：建立了全省各市、县指定作物水稻和小麦的光温生产潜力和气候生产潜力数据库。

（8）农业投入－产出数据：全省13个省辖市以乡镇为单位，建立了1996～2000年农业生产投入－产出数据库。

（9）作物产量数据：全省13个省辖市以乡镇为单位，建立了1996～2000年的指定作物水稻和小麦的产量数据库。

（10）土地利用详查分类面积数据：全省13个省辖市以乡镇为单位，建立了2000年土地利用详查分类面积数据库。

从数据格式上分，数据库又可分为：①图件数据库：指空间数据以及绑定在空间数据上的相关属性数据，本次江苏省农用地分等建立了以分等单元为记录的属性数据库，并通过关键字段与空间数据关联；②分类统计数据库：包括全省13个省辖市以乡镇为单位的1996～2000年指定作物产量统计数据和全省13个省辖市以乡镇为单位的2000年土地利用详查分类面积统计数据。

（二）系统数据库管理模式

为减少数据存储冗余，同时提高索引速度，江苏省农用地分等信息系统数据文件采用普遍的目录树形式进行管理，按省－市－县行政体系分别存储相关数据。全省建立13个省辖市分目录，分目录下按照各自所含的县（区）建立子目录。根据目前行政管理体系现状，基础资料大多来源于县级行政单位，因此采用县（区）为基本行政单位较为合理，在保证资料来源的同时，也利于资料的分类归档存储。其相对应的空间图件数据也按精度要求分割到县级行政单位，既能减少系统调用数据的吞吐量，同时也满足了系统的精度需求。空间数据、属性数据、文本数据按照各自所属的行政级别归类存储，同时设立数据文件管理器进行目录文件的索引管理，见图3-86。

图3-86 江苏省农用地分等信息系统数据文件管理模式图

（三）系统数据库结构

数据库的结构设计决定了数据之间的调用及接口关系，清晰的逻辑调用关系和统一的数据接口格式有利于数据的组织、管理、调用。

1.空间数据库

江苏省农用地分等信息系统空间数据库以矢量图件的形式存在，以分图层的方式管理，包括了全省行政界线、土壤类型、按八大类分别提取的土地利用现状、分等单元等图层。其中，分等单元图层作为农用地分等的基础，考虑到图层本身信息量大，可能影响到系统运行效率，因此所在图层的属性表中只保留了ID字段，通过ID字段与外部属性库绑定，实现分等单元与外部属性库一一对应关系。ID字段是本图层的特征代码，表征了单元的唯一性，能体现出单元的图上位置和行政归属。《农用地分等定级规程》（国土资源大调查专用）和《中华人民共和国行政区划代码》（GB/T 2260-1999）为本研究分等单元代码的编码依据；本研究有1996年和2000年两套行政区划工作底图，为此分等单元特征代码共设14位，依次为江苏省代码（2位）－市代码（2位）－2000年县或区代码（2位）－2000年乡镇代码（2位）－1996年县或区代码（2位）－1996年乡镇代码（2位）－分等单元号（2位）。其中，省、市、县（区）的行政代码按国家统一代码，乡镇级代码在县（区）范围内根据划分分等单元的需要依次编码；分等单元编号的原则是不破乡镇界，即单元号是在同一乡镇内部自行编码。示例：32011501210101，指1996年江苏（32）南京（01）市江宁县（21）由于2000年行政调整变更为南京（01）的江宁区（15）。按行政体系分级编码的优点是有利于空间查询和国土资源管理部门根据工作需求按行政级别分类汇总统计数据。

2.属性数据库

江苏省农用地分等信息系统采用关系型数据库来存储数据，优点是结构清晰明了，数据的更新维护方便，通过索引能优化数据库，建立快速的查询浏览（表3-26～表3-30）。

表3-26 行政代码数据结构表

表3-27 土壤属性数据结构表

表3-28 农田水利设施数据结构表

表3.29 指定农作物投入－产出数据结构表

表3-30 农业耕作制度及农业区划表

（四）系统模型库

系统以《农用地分等定级规程》（国土资源大调查专用）中的相关技术方法和计算模型为基础，在模型库中预先内置了分等计算模型。模型库是动态，它允许专家根据情况动态调整计算模型形式及其参数。系统主要模型的数学计算公式如下：

（1）农用地自然质量分值（C_lij）计算公式见式（3-11）。

（2）样点土地利用系数计算公式：

中国耕地质量等级调查与评定（江苏卷）

式中：

K_lj´——样点的第j种指定作物土地利用系数；

Y_j——样点的第j种指定作物实际单产；

Y_j,max——第j种指定作物最大标准粮单产。

（3）等值区土地利用系数计算公式：

中国耕地质量等级调查与评定（江苏卷）

式中：

K_lj——等值区内第j种指定作物土地利用系数；

K_lj´——参与计算的同一等值区内合格样点第j种指定作物土地利用系数；

n——排除异常数据后参与计算的样点的个数。

（4）样点土地经济系数计算公式：

中国耕地质量等级调查与评定（江苏卷）

式中：

K_cj′——样点的第j种指定作物土地经济系数；

Y_j——样点第j种指定作物实际单产；

C_j——样点第j种指定作物实际成本；

A_j——第j种指定作物最高“产量－成本”指数。

（5）等值区土地经济系数计算公式：

中国耕地质量等级调查与评定（江苏卷）

式中：

K_cj——等值区内土地经济系数；

K_cj´——参与计算的同一等值区内合格样点第j种指定作物土地经济系数；

n——排除异常数据后参与计算的样点的个数。

（6）农用地自然质量等指数（R_i）计算公式见式（3-12）和式（3-13）。

（7）农用地利用等指数（Y_i）计算公式见式（3-14）和式（3-15）。

（8）农用地经济等指数（G_i）计算公式见式（3-16）和式（3-17）。

⑼ 数据库设计分哪几个阶段

按照规范的设计方法，一个完整的数据库设计一般分为以下六个阶段。

1、需求分专析属：分析用户的需求，包括数据、功能和性能需求

2、概念结构设计：主要采用E-R模型进行设计，包括画E-R图

3、逻辑结构设计：通过将E-R图转换成表，实现从E-R模型到关系模型的转换

4、数据库物理设计：主要是为所设计的数据库选择合适的存储结构和存取路径

5、数据库的实施：包括编程、测试和试运行

6、数据库运行与维护：系统的运行与数据库的日常维护

(9)数据库模型设计扩展阅读：

设计原则

1、一对一设计原则

在软件开发过程中，需要遵循一对一关系设计原则进而开展数据维护工作，通过利用此原则能够尽量减少维护问题的出现，保证数据维护工作顺利开展同时降低维护工作难度。

2、独特命名原则

独特命名原则的应用是为了减少在数据库设计过程中出现重复命名和规范命名现象出现。

3、双向使用原则

双向使用原则包括：事务使用原则和索引功能原则，软件市场常见的索引模式有：多行检索聚簇索引和单行检索非聚簇索引。

⑽ 数据库主要有哪些模型这些模型的特点是什么

1. 两大类数据模型：数据模型分为2类（分属2个不同的层次，在开发和版使用数据库中使用不同权的模型）。
   

2. 概念模型，也称信息模型，它是按用户的观点来对数据和信息建模，用于数据库设计。
   

3. 逻辑模型和物理模型，逻辑模型主要包括：网状模型、层次模型、关系模型、面向对象模型等，按计算机系统的观点对数据建模，用于DBMS实现。
   

4. 物理模型，是对数据最底层的抽象，描述数据在系统内部的表示方式和存取方法，在磁盘或磁带上的存储方式和存取方法。
   

5. 概念模型：信息世界中的基本概念。
   

6. 用途：数据库设计人员和用户之间进行交流的语言。但要考E-R图！
   

7. 最常用的数据模型：非关系模型，有层次模型和网状模型；关系模型；面向对象模型、对象关系模型。