环境监测数据系统中常见数据库结构分析

＊刘菁 孔茹

（1.山东省生态环境监测中心 山东 250000 2.山东省烟台生态环境监测中心 山东 264000）

随着大数据时代的到来，数据的重要性不言而喻，环境监测数据更是支持环境保护工作的重要基础，如何保证环境监测数据的完整性、一致性、历史延续性，是决定环境监测数据库的主要因素。在不同历史阶段中，所使用的数据系统，它们在操作平台、用户界面、数据处理方式、表征形式以及对硬件资源的利用上各有不同，下面就针对几个具有代表性的环境监测数据库结构进行分析，并提出改进建议，以解决因数据库结构的不完善而带来的各种问题。

1.环境监测数据系统常见的3种基本数据库结构特点

(1)dBASEIII或Foxbase建立的数据库

环境监测数据库，是90年代普遍使用的一种库结构，这种数据库结构采用dBASEIII或Foxbase系统建设[1]，符合巴斯范式要求，基本信息分解为多个数据表。以河流基本信息为例，基本信息由河流名称数据表，断面名称数据表，所属城市数据表，监测项目代码4个数据表构成，监测数据表又分为必测数据表和选测数据表，必测数据表键值只有断面代码和日期，选测数据表增加了监测项目代码。这种数据库结构在使用时，要关联这6个数据表，才能得到一条完整的监测数据。该历史数据库导出到第三方数据统计软件后，很难直接查阅。即便是专业人员做导入，也要反复测试、核对，特别需要注意各数据库之间的关联顺序，否则很容易造成数据疏漏。数据库中的监测数据采用数值型存储，未检出的监测项目要在检出限前加“-”号进行标识，在统计均值等问题时，需要特别注意“-”号带来的问题。

这种结构的优点是：一是减少了冗余，保存空间少，符合当时计算机的存储空间的要求；二是涵盖所有的监测项目，即便是之后的新增的监测项目，也只需要在监测项目信息库中新增，不用修改数据库就可以使用，适合环境保护工作发展的进程。随着计算机系统的发展，这种结构已被新的数据库系统所替代，但在整理、导入历史数据等工作时，还会用到，在使用中要认真查看资料，做好与历史数据的衔接和匹配工作。

(2)ACCESS+SQL Server组合建立的数据库

SQL Server是一个可扩展的、高性能的、为分布式客户机/服务器计算所设计的数据库管理系统，系统管理先进，支持Windows图形化管理工具，支持本地和远程的系统管理和配置。但对计算机配置要求较高。Microsoft Office Access是由微软发布的关系数据库管理系统。是Microsoft Office的系统程序之一，具有强大的数据处理、统计分析能力，运行速度快，对计算机配置要求不高。这种组合结构是在省级站布署使用SQL Server数据库，在市、县级站使用Access数据库[2]。利用这种组合结构很好的解决了当时计算机配置参差不齐带来的诸多问题。这套系统首次完成了系统内数据在线传输，减少出错率，大大提高了数据及时性，工作效率得到了有效提升。

对数据库结构分析可以得知，河流、湖库监测数据存储在一个数据表，饮用水、地表水、地下水存储在一个数据表，通过识别码进行区分，因此同一个字段因为存储的数据类别不同，存储的监测数据也不相同。如果直接从数据库导出数据，要结合数据识别码分析结构和字段，才能得知字段所代表的数据名称。该系统能直接导入、导出EXCEL等文件，极大的方便了使用人员，也给历史数据的整理带来了便利。但系统也存在一个问题，是由于Access系统的主键为自动生成的随机数，当多个城市在各自的计算机上增减点位代码时，会生成相同的随机数，再上传到上一级数据库时，就会造成数据的混乱，为避免这个问题，对点位的修改权限只能上收统一建立，再下发，这在应用上有很大的局限性。

该系统点位信息合并为一个数据表，且监测数据表里含有多个基本信息，即便自行导出，也可立即使用，极大地方便了用户。数据采用字符型存储，解决了未检出填报问题，由于是字符型，对数据存储时要有必须的数值检查，以免存储其它字符。监测数据表为一个，没有选测数据表，这样随着监测要求的变化，若有新增监测项目就要修改数据库结构，很容易造成应用系统产生其它问题，也正因为监测项目的固定，也会造成历史数据导入时，部分监测项目无处可存的情况发生。

(3)SQL Server建立的数据库

目前当下流行的、普遍采用的数据库就是SQL Server。监测基本信息也逐步完善，存在适合多种平台的应用系统；监测数据表的基本信息越来越细化、越来越丰富，导入、导出方便，表征形式多样化，用户权限管理、安全性都得到了提高。该系统主要实现完善基本数据库的建立和数据的高效安全传输，各种应用系统由各用户在其基础上再进行二次开发应用。该系统存在的问题依旧是监测项目的不完整，虽然监测项目已相对完善，但若有新增的监测项目免不了修改数据库结构。特别是地表饮用水监测项目较多，除填写全分析数据以外，每月要填写未监测项目较多，造成不便。

2.常用的三种数据库存在的问题分析和解决方法

简单分析了以上三种结构，再来看一下以上结构是否存在普遍性的问题，又该如何解决这些问题，如何更合理的建立环境监测数据库结构呢?

以上数据库结构中往往因为设置主键等原因，基本信息表都没含日期信息，并且很多开发人员，也认为没有建立日期信息的必要。但这种结构类型的数据库基本信息如有变化，不再使用的点位的信息依旧保存，对更改的信息就要替换原有的信息，这样不仅不能完整的保留历史信息，而且也会造成统计结果的不一致。

下面举几个实例进行分析：

（1）在功能区噪声监测数据管理中，某点位的功能区类型原为工业区，随着城市的发展，企业外迁或转型等因素，现功能区类型更改为商业区，出现这种情况，要如何解决。以往通常的解决方案有两个，一是把功能区类型直接修改成现状的商业区，这样统计当前数据是可以的，但统计历史数据时的评价结果就与原统计结果以及实际情况不符，要进行历史数据的统计评价工作，就要借助之前保存的统计结果，随着时间的推移和人员的变化，很容易造成遗忘，造成数据统计错误。二是对该点位重新设一个编号，这样同一个点位实际处理中就成为两个不同点位来统计，这样就解决了当前以及历史数据的统计问题。但想要查看该点位历史以来的变化情况，就比较麻烦，需要人工再合并两个点位的数据后再进行计算；这个问题在利用点位信息的生成的GIS图时，也会出现同一个点位两种不同的类型，需要每次都进行人工处理，造成使用不便。

类似这种情况在基本信息表中填加上年度信息，就可以很好的解决。每一年的该点位的信息保持一致，如遇到信息变化，只修改当前年度的信息即可。每一年对基本信息做一次维护，追加上一年的信息，修改年度和改变的信息。

（2）工作中还会遇到一种情况，就是不以年度为单位而改变基本信息，比较典型例子就是重点排污企业监督性监测的执行标准，执行标准的起止时间并没有按照年度来变化，有的企业同一个年度会执行两种不同的标准，如果只增加年度字段也不能解决此类问题，所以基本信息的存储还是要有完整的日期数据，在基本信息表里要包含年、月、日这些具体日期数据。

目前监测数据库的数据存储，除重点排污企业监督性监测数据库之外，大都是按监测项目的排列存储[3]。比如上面提到的地表饮用水全分析的项目，多达109项，这样饮用地表水数据库结构就有109个监测项目字段，再加上基本信息，不用说，也能想象的到这个表有多长。这么长的表不论是在软件中使用，或者是导出到其它应用软件中，查看、计算、统计都是非常的不方便。即便是109项，也不能保证以后监测项目的完整性。

（3）在土壤例行监测要求中，需要监测土壤的特征污染物，每个地块的特征污染物可能都不相同。类似于这种情况，固定监测项目模式的数据库结构，就不能很好的满足工作需求。可能要反复修改数据库、更新升级系统才能解决。为解决诸如此类问题，可以参照文中第一种监测数据管理系统，建立一个监测项目库和选测项目库，或者将某些数据数据表直接采用监测项目+监测数据的形式存储，这样，不仅可以满足今后工作发展的要求，而且极大的方便了综合数据分析人员的查看、统计等工作需要，并且还可以很方便的利用第三方统计软件，例如EXCEL的数据透视表功能，更大地提高了工作效率。

3.结论

分析以上几种环境监测数据系统得知，环境监测数据库的建立，不仅考虑到当前工作的需要，更要考虑到历史数据导入的完整性和当今环境监测工作的发展需求。数据库系统建设中充分做好调研，了解数据的历史沿革，信息做到尽可能的完善，数据库结构尽可能的减少修改，这样才可以不仅保证数据的准确性，而且更能保证监测数据的连续性、完整性和可比性。只有监测数据信息化建设上了新台阶，才能更好地为环境科学分析、管理提供准确依据，为政府各级主管部门进行决策提供信息保障。