近年来，地球物理场流动观测在地震分析预报中发挥了积极作用，对地球物理场流动观测数据共享的需求也日益增长。然而，地球物理场流动观测数据的管理一直相对滞后。虽然也进行过数据库系统建设，如“十五”期间的流动数据库系统建设^[1-2]，但一直没有建立比较完善和统一的数据库系统、数据管理系统和数据应用系统，没有建立从观测数据产出到应用的完整流程。而且，数据没有汇集到国家地震前兆台网中心进行共享服务。为此，中国地震局陆续出台了《地球物理场流动观测数据汇交与共享管理办法(试行)》和《地球物理场流动观测实施管理办法(试行)》，除进一步规范观测外，也加强地球物理场流动观测数据的共享服务工作。同时，从2013年开始，在地震行业专项“地球物理场流动观测信息融合关键技术研究”的支持下，国家地震前兆台网中心开始进行地球物理场流动观测数据管理平台的建设，包括硬件平台、流动观测数据库系统、数据管理与共享服务系统等。目前，该平台已初步建成并投入使用。本文主要介绍地球物理场流动观测数据库设计的有关方面。

1 数据库设计

数据库是数据管理和共享的核心公共平台。数据库系统建设主要包括设计数据库结构、搭建服务器平台、安装数据库管理系统、根据数据库结构规范编写建库脚本并创建数据库等工作。关于数据库设计的一些主要考虑因素在有关文献[3]中已有详细介绍，本文不再重复。下面主要介绍地球物理场流动观测数据库设计的技术细节。

1.1 设计的技术基础

地球物理场流动观测数据库主要涵盖流动地磁和流动形变。在设计前，针对目前地震系统的地球物理场流动观测数据管理情况，对主要施测单位和学科中心进行了调研。在综合有关资料的基础上，流动地磁数据库设计主要参考地震行业专项“流动地磁测量基本技术要求”成果(《流动地磁测量基本技术要求(试行)》(中震测函[2015]39号))。流动形变数据库设计以“十五”期间制定的流动形变数据库结构为主，并参考了中国地震局第二监测中心形变监测数据库结构。

1.2 数据库包含的主要内容

流动地磁涵盖总强度观测和三分量矢量观测。流动形变涵盖以下业务：1)流动GNSS观测；2)区域水准测量；3)跨断层场地水准测量；4)定点台站水准测量；5)跨断层基线测量。

包含的数据种类为：1)基础信息：有关观测网、测线、测点、台站、观测场地、观测仪器及检定、项目、观测任务、施测单位和人员等信息。2)观测信息：观测时的环境信息，如太阳位置、天气情况、通视情况等，以及原始观测数据等。3)成果数据：观测数据经处理后得到的测量成果，如流动地磁测量中的通化数据、长期变化改正后的数据、区域水准测量中经过改正后的往返测高差和高差中数等。

1.3 数据库方案(Schema)和表名

1) 数据库方案(Schema)设计。目前，前兆固定台站观测数据库是在Oracle系统上使用QZDATA方案，将所有表置于该方案下。为了与前兆固定台站观测数据库区分，同时又方便将流动观测数据与固定台站观测数据库部署到同一个Oracle实例上，流动观测数据库使用LDDATA方案，将流动地磁和流动形变的数据库表置于该方案下。

2) 表名设计。表名由观测手段、表类型、观测间隔(采样率)以及表的特征字符等组成，各部分之间用下划线连接。为了能将流动地磁、流动形变的数据放在同一个数据库中，将流动地磁、流动形变表在表名的观测手段部分进行区分，流动地磁表的表名开头2个字符为“LD”，流动形变表的表名开头2个字符为“LX”。表名的表类型部分参照固定台站观测数据库的设计，“DICT”表示基础信息表，“DYS”表示原始观测数据表，“DYU”表示观测成果表，“CP”表示仪器、标尺、天线检查等信息。

1.4 编码设计

代码设计是数据库设计的一个重要方面。在数据库中，对于一些重要的对象，如水准点，为了能够准确地标识各个对象，便于表之间进行信息的关联，也方便查询，往往赋予对象一个代码，就像我们每个人的身份证号码一样。本数据库中需要编码的对象有几十处，包括测网、测线、测段、测点、场地、台站、仪器、单位、人员等。代码设计需要考虑以下几个方面：

1) 唯一性。代码的唯一性包括本地唯一性和全局唯一性。本地唯一性是指本地数据库中该代码是唯一的。对于不需要进行交换的数据，保证代码的本地唯一性即可，这时往往可以使用数据库提供的一些机制来生成代码，如Oracle数据库的序列号(sequence)，它可以自动增长，省去了维护代码的麻烦。全局唯一性是指在一定范围内代码是唯一的，如整个地震系统。由于在系统内多个单位需要建立同样的数据库，单位的数据库之间需要进行数据的交换，因此代码必须是全局唯一的，这样在交换数据时不会产生冲突，在使用数据时也不会产生歧义。

2) 稳定性。数据库中使用的代码必须是比较稳定的，这样可以减轻对代码的维护工作量。代码一旦使用，如果要改变编码规则，将会造成巨大的麻烦，因此在设计时必须考虑周全。

3) 易编码。代码的编码规则不应太复杂，太复杂会使编码困难，且容易出错。

4) 易维护。比如，曾有人建议在水准点表的水准点所在地字段使用国家制定的行政区划代码，但该代码不是由地震系统制定，全国的行政区划也会经常变动，且变动之后并不会通告我们，如果不及时更新，容易造成数据库中的信息错误。

5) 容量。在设计代码时，必须考虑该代码的容量，确保代码在一定的时间内足够使用，不会出现代码用尽的问题。比如，IP地址长度一开始是4个字节(IPv4)，但随着互联网的迅猛发展，4个字节的IP地址很快用完，因此又出现了6个字节的IP地址(IPv6)，导致整个互联网需要逐步进行升级。

在本数据库设计时，考虑到以上方面，代码主要以单位、年份和顺序码等组成，例如，水准点编码规则为：水准点编码由14位组成，前2个字符为“LP”，第3~5位为埋石单位代码, 不足部分后面补0，中间4位为埋石年份，后5位为该单位该年内的顺序编码, 从0编至99 999，不足部分前面补0。

1.5 重要技术内容说明

1) 数据库内容的考虑。在考虑数据库中应包含哪些数据内容时，主要从各级节点数据管理和共享需求出发，主要保存成果数据及有关的观测信息、基础信息。由于现在流动观测大多数采用了电子记簿，从测量仪器上直接生成电子格式的观测手簿文件，可下载保存。因此，为了保存原始观测数据，在本平台数据库设计时，考虑了将电子观测手簿文件保存到数据库，如GNSS观测原始记录的标准格式文件、区域水准的观测原始文件、点之记电子文档等。这些原始观测信息将以BLOB(大对象二进制文件)的形式存放到数据库中。在保存之前，也可以以普遍认可的格式进行压缩，以节约存储空间。由于保存了观测原始资料，在相应的表结构中，没有必要将点之记中的每一项都作为字段，如点之记中，有“砂子来源”这样一项，说明建点所用砂子的来源，但这个信息被查询的可能性极低，因此在表结构中没有把它作为一个字段。否则，该表将会重复包含很多查询和应用需求极低的信息。

2) 观测任务的划分要求。固定台站观测是在某个测点上连续进行的，以获取被观测对象的连续时间数据序列，因此在进行前兆固定台站观测数据库设计时，是按台站、测点、测项分量、时间作为数据表的主键^[4]。流动观测主要是在一定空间范围内不定期进行重复测量。测量的期次是标识数据的一个主要属性，因此，在设计流动观测数据库时，凡是跟测量期次有关的数据信息表，其主键之一是“任务序列号”。“任务”是某单位某手段(流动GNSS、流动地磁、区域水准等)的某期次测量任务，对任务的划分应使数据易于区分，每个测网的每期测量作为一个测量任务。同一个测网、测点的两次测量，应分属于两个不同的测量任务。

3) 点位的历史变迁信息。观测点会由于遭到人为破坏等原因而被废弃，同时以新建观测点来替代，这种情况在流动观测中是经常出现的。因此，为了保存点位的历史变迁信息，以及某个点是否还在使用等信息，在数据库中作了相应设置。如水准点表中，有“替代前水准点编码”字段，点被废弃的日期和原因等，以及水准点别名表。

4) 点位综合利用。在进行本数据库设计时，考虑了重力、GNSS、水准观测数据的综合检索和应用。在GNSS点表中，设计了GNSS观测点四周建设的水准点数量、便于联测的水准点概述(点名、等级、距离等)、该GNSS点是否为重力联测点、便于联测的重力点概述(点名、等级、距离等)等信息。在水准点表中，设计了GPS联测点标记、基线观测点标记、重力联测点标记等信息。这些设计为重力、GNSS、水准观测数据的综合检索和应用提供了可能性。

2 数据库结构

流动地磁数据库见表 1，流动地磁观测的总体E-R关系见图 1。

流动形变数据库见表 2。以区域水准测量为例，给出其总体E-R关系图, 见图 2。流动形变观测的其他观测手段的总体E-R关系图与之相似，且更为简单。

3 结语

虽然中国地震局已经下发了两个文件加强和规范地球物理场流动观测数据的管理和共享，但要形成从观测单位到数据用户的完整的数据流程尚需时日。首先，应加强对地球物理场流动观测数据管理与共享服务的重视，将有关数据管理与共享服务的要求落到实处。其次，需完善各级节点的数据管理与服务平台，统一技术标准，尤其要统一数据库的格式, 加强数据流程链上各种管理和应用软件的研发。第三，由于各级节点的数据管理平台建设一直比较滞后，大量的历史数据没有入库。在很早前建设的独立的数据库中，这些历史数据的整理和入库将是一项繁重的任务，而且迫在眉睫，需要各方面给予大力支持，尽快进行抢救性整理入库。最后，由于地球物理场流动观测数据涉及敏感数据，敏感数据的管理和共享在技术层面上要求更高，影响了数据管理与共享服务工作的推进，需要逐步完善技术措施和相关的管理制度。

目前，国家地震前兆台网中心和中国地震局第一监测中心(流动形变学科中心)已在Linux平台上使用Oracle数据库系统建设了基于本设计的地球物理场流动观测数据库并投入使用，今后还将根据使用情况和用户需求不断进行完善。这将为加强地球物理场流动观测数据的有效管理、促进数据共享和应用打下坚实的基础。