城市生命线实时监测物联网应用示范工程数据库设计书

城市生命线实时监测物联网应用示工程数据库设计书1.1编写目的与围
目的：
本文档的目的是说明城市生命线实时监测物联网示工程市级平台的数据库设计，包括系统体系结构和系统功能，为系统软件编程和系统维护提供基础。

本文档是城市生命线实时监测物联网应用示工程市级平台系统详细设计的组成部分，此文档用途是：明确数据库的表名、字段名等数据信息，用来指导后期前台及数据库后台开发的规文档。

围：
本文档围是对城市生命线实时监测物联网示工程市级平台的数据库设计说明。

主要包括：设计规、数据字典、数据实体关系、表清单、表详细信息等。

1.2预期读者
本文档的预期读者为系统设计人员、软件开发人员、软件测试人员和项目评审人员。

1.3文档性及私密性
本文档为市市政市容管理委员会部文档，未经许可，不得外传。

1.4项目背景
城市生命线是指城市排水、供水、供气、供电、供热、交通、通讯等基础设施系统。

这些系统是维持现代城市生产、生活的基础，随着城市居民生活条件、文化与信息需求的不断提高以及城市经济的快速发展, 促使对城市生命线系统的需求与依赖性越来越高。

实时监测城市生命线的生命体征的健康状况，保障城市的安全平稳运行、保证城市居民的正常生产生活、支撑领导决策都起到非常关键的作用。

作为国家的政治中心、具有国际影响力的经济中心、传统与现代融合发
展的文化中心，在按照“国际化、现代化、精品化”发展理念，把建设成为和谐宜居的世界城市，做好“四个服务”，高端服务业发展，“人文、科技、绿色”和社会和谐的进程中，坚持高标准的要求，不断提高城市管理工作能力和水平尤为重要。

有效地实时监测城市生命线的生命体征，获得各项有效数据和指标，对于保障城市运行安全，对于指导城市规划、建设和发展有着重要的意义。

特别是在应对突发事件时，提供基础运行数据和高峰时运行数据可为领导决策提供基础参考。

由于信息采集的及时性、准确性、完整性不高，信息展示形式不形象、不直观、不易被理解，城市生命线日常运行信息沟通传递水平不高，导致城市生命线日常运行协调难度大，城市生命线安全运行和应急管理的指挥协调难度大，降低了领导决策的准确性、科学性。

而且，目前城市生命线行业运行分管部门多、协调头绪多、相互干扰大、隐患排查难的问题仍然存在。

因此，需要在市市政市容委前期开拓性建设城市运行管理新思路的基础上，进一步完善城市运行管理的机制，本期项目重在完善城市生命线日常运行指挥协调机制及配套信息共享机制，统一协调城市生命线日常运行和应急指挥中面临的问题。

应用物联网技术，以水、电、气、热为监测对象，在“市城市运行监测信息平台”的原有系统基础上，进一步丰富底层基础数据完善数据智能处理和展示界面，建设城市生命线实时监测物联网示工程，全面监管市城市生命线各生命体征，保证城市安全运行、提高应急突发事件的预警、处理能力和水平。

1.4.1物联网发展领导批示要求
2009年以来，“物联网”技术与应用在国外引起广泛关注，市委书记淇、市长郭金龙等市领导对此高度重视，专程对本市物联网技术应用情况进行调研，听取有关情况汇报，并作出重要批示，要发展物联网产业，带动中关村科技产业发展，并优先从城市安全运行、应急管理做起。

为落实市领导批示精神，市发改委会同市应急办、市经信委等部门，起
草《关于加快推进本市物联网产业发展和示应用有关事项的意见》（市发改文〔2010〕113号）并上报市政府。

常务副市长就此作出批示：物联网产业的发展问题由经信委系统研究，首先在城市应急和管理中应用，由应急办牵头。

5月4日，常务副市长再次批示：请应急办牵头商发改委、经信委就推进这项工作进行研究并提出意见。

1.4.2“感知”物联网应用技术框架明确要求
按照国家发展物联网和本市“感知”示建设的有关要求, 为推动“感知”示建设，深化本市物联网应用，带动物联网产业发展，提升政务和公共服务管理水平，制定了《关于在政务和公共服务领域开展物联网应用的指导意见》，政务和公共服务领域开展物联网应用框架以标准规体系、信息安全体系为保障，分为感知、网络、支撑、应用四层。

政务和公共服务领域物联网应用技术框架
感知层是利用射频识别读写器、传感器、卫星定位终端、图像采集设备等，对目标对象进行实时感知，及时获取各类感知信息；网络层是利用电子政务网络、政务物联数据专网、无线宽带专网、移动公网和互联网等网络，保障各类感知信息安全可靠传输；支撑层是依托物联网应用支撑平台，实现
各类重要管理对象、感知设备的统一编码和统筹管理，实现各类感知信息的及时共享和有效整合；应用层是根据政务和公共服务领域的业务需求，对及时掌握的各类感知信息进行综合加工和智能分析，为政府、企业和个人提供更加精细化、智能化的服务。

1.4.3城市安全运行和应急管理物联网应用的明确要求
按照市领导批示和要求，全市政务物联网应用建设以城市安全运行和应急管理为突破口开展，并带动全市政务物联网应用和产业发展。

城市安全运行和应急管理领域物联网总体框架
城市安全运行和应急管理物联网应用将按照“1+1+N”框架开展，第一个“1”是指市应急指挥平台，第二个“1”是指市物联网应用支撑平台，“N”是指各部门（区县）应急物联网应用。

市应急指挥平台通过市物联网应用支撑平台，汇聚接入各部门（区县）应急物联网应用的物联信息，对全市城市安全运行和应急进行全过程常态化管理，实现“管得住、上得来，看得见、能整合”。

（1）市应急指挥平台
通过对已有系统的技术升级改造，进一步提高信息感知能力、提升应急处
置水平，为市领导提供全市城市安全运行和应急管理物联网综合信息服务。

（2）市物联网应用支撑平台
主要包括编码赋码服务、物联基础信息服务，以及物联信息的目录、交换、接入、整合和共享展示服务等，基于云计算技术全市统筹建设，是全市统一的政务领域物联网应用基础设施。

一是通过政务外网，接入、汇集、整合全市城市安全运行和应急管理物联信息，为市应急指挥平台服务；二是利用物联共享信息库，为市属专项指挥部、区县应急办和相关单位提供共享服务。

（3）各部门（区县）应急物联网应用
市各部门根据行使职能需要，为实施精细化、实时化、系统化的监控与管理而建设的具体应急物联网应用系统，重点关注风险源、救援物资、救援设备、救援队伍等基本信息。

城市生命线实时监测物联网系统市级平台的建设，是基于“1+1+N”的系统架构进行的，如下图所示：
城市生命线实时监测物联网系统的定位
1
1
1.4.4建设目标
通过“城市生命线”实时监测物联网示工程建设，具体实现以下四大目标：
⏹提升政府对生命线运行整体态势的掌握水平。

通过对城市生命线的计
划、调度、存量等运行信息进行实时、准确地采集和整合分析，为相关
职能部门和市领导及时准确掌握城市生命线整体运行情况提供有效服务，进一步提升政府对生命线运行整体态势的掌握水平。

⏹提升相关职能部门对生命线设施的监管水平。

通过集成共享示企业的
生命线设施实时运行数据，提升相关职能部门对生命线设施的监管水平。

⏹提升城市生命线突发事件的应急反应能力和应急处置水平。

通过建设
应急指挥、辅助决策等功能，进一步提升城市生命线突发事件的应急反
应能力和应急处置水平。

⏹提升生命线相关企业的精细化、智能化的运行监控和安全管理水平。

以城市生命线相关5大行业的风险（运行监测点以及安全关注点）统计
和风险预测为出发点，提升生命线相关企业的精细化、智能化的运行监
控和安全管理水平。

在5大行业推广应用物联网，促进生命线领域的物
联网产业发展。

1.5设计依据（参考资料）
⏹《市城市生命线实时监测物联网应用示工程初步设计及概算》
⏹《关于批准城市生命线实时监测物联网应用示工程项目建议书（代可行
性研究报告）的函》京发改[2011]1886号；
⏹《市城市安全运行和应急管理领域物联网应用建设总体方案》（京政办
[2011]14号）；
⏹《关于加快推进本市物联网产业发展和示应用有关事项的意见》市发改
文[2010]113号；
⏹《关于在政务和公共服务领域开展物联网应用的指导意见》；
⏹《管理对象和感知设备编码规》（试行）；
⏹《物联基础信息规》（试行）；
⏹《物联信息元数据规》（试行）；
⏹《物联信息接入规》（试行）。

⏹《国家信息化领导小组关于我国电子政务建设指导意见》（中办发
[2002]17号）；
⏹《国家电子政务工程建设项目管理暂行办法》（55号令）；
⏹《市党政机关网络与信息系统安全定级指南（试行）》；
⏹《市信息化工作领导小组关于加强信息安全保障工作的实施意见》京办
发[2004]3号；
⏹《市电子政务建设管理办法（试行）》经信息办发[2004]39号；
⏹《市电子政务总体技术框架》；
⏹《市政务与公共服务信息化工程建设管理办法》市政府第67号令。

⏹《计算机软件需求说明编制指南》（GB9385-1988）；
⏹《中华人民国计算机信息系统安全保护条例》；
⏹《计算机软件产品开发文件编制指南》（GB/T 8567-1988）；
⏹《计算机信息系统安全保护等级划分准则》（GB/T 17859-1999）；
⏹《信息技术安全技术信息技术安全性评估准则》（GB/T 18336-2001）。

⏹《城市生命线实时监测物联网示工程市级平台需求规格说明书》
⏹《城市生命线实时监测物联网示工程市级平台概要设计》
⏹《城市生命线实时监测物联网示工程市级平台详细设计》
2设计思路
2.1设计原则
（1）以推广示为出发点
应充分利用现有网络、硬件设施和系统软件等建设资源，此次示不仅要实现创新技术的无障碍演练，同时应为下一步全市推广打下基础。

（2）以系统应用建设为目的
紧紧围绕系统应用建设的目标，充分分析用户需求，设计出稳定高效的应用系统。

（3）可持续发展原则
在详细设计中按照可持续性发展的原则，采用正确的策略、适当的技术和有效的措施确保系统的可伸缩性。

（4）遵循标准，系统兼容性原则。

应充分考虑系统兼容性，遵循标准，包括与采集器通信、运行环境等，为大围推广奠定基础。

（5）可控制性原则。

在设计时考虑核心设计的可控制性，谨防被较轻易复制。

（6）统一性原则
本次示工程的目的是实现对全市接入平台的电梯按照统一性原则进行分级监测管理，以及与市物联网支撑平台的纵向连接，这样一个物理上分散的系统，必须坚持统一性原则。

这种统一性表现在：
⏹统一规
⏹统一标准
⏹统一接口
⏹统一的体系结构
⏹消息表示的一致性
⏹应用层信息交换协议的一致性
⏹整合后数据格式的一致性
2.2约束条件
本平台软件能够支撑的监测点数和接入的数据受硬件环境的限制，如服务器配置和数量，以及网络环境等。

2.3总体技术路线
系统将基于SOA的体系架构搭建，通过服务总线，将所开发的系统功能紧密结合起来，服务之间采取低耦合设计，从而为系统未来的升级和扩展提供极大的灵活性。

同时，基于SOA的架构设计，也为顺利整合现有系统提供了技术解决方案。

城市生命线实时监测物联网系统市级平台主要为业务处理应用，需要分布式部署，多用户访问，根据应用特点，采用B/S结构，用JAVA语言开发；至于外部接口部分需要根据实际对接需要提供相应服务，接口设计上需要支持webservices服务、前置机数据库、文件导入导出、地址访问等方式。

由于该平台面向大数量量处理，数据库方面首选oracle数据库。

2.4软件运行环境
服务器：浪潮 NF8560M2、NF5220
操作系统：WINDOWS SERVER 2008 R2
应用服务器：Tomcat7.0
数据库：oracle11g
网络环境：市市政市容委部网
3系统详细设计
3.1系统架构图
行业子系统
城市生命线实时监测物联网示工程市级平台系统架构图
市级平台从行业子系统中采集城市生命线五大行业的监测对象的实时运行信息、综合类指标信息、计划信息、监测对象基本信息、重大活动保障基本信息、预案信息、应急资源等信息，当城市生命线发生报警、故障后，系统主动将报警、故障信息及其他相关辅助信息发送到市级平台。

一旦监测对象或者综合类指标发生报警和故障，市级平台就会自动启动告警流程，一线工作人员和维护人员市级平台相关界面和手机将在第一时间收到报警和故障信息，以便及时现场处理。

按照业务管理要求，报警、故障信息及突发事件信息将由相关部门进行分级响应处理。

3.2功能框架图
城市生命线实时监测物联网示工程市级平台功能框架图
●建立信息服务域，发挥数据优势，为城市生命线管理决策提供有价值的信息服务；
●建立监测管理决策服务域，发挥实时监测、数据分析、数据预测优势，支撑城市生命线的决策、日常管理和重大活动保障。

3.2.1信息服务域
信息服务域由市级平台数据层和获取层构成，它通过商业智能技术手段深化企业数据的精加工能力，在市级平台中构造集中提供数据和信息服务的实体。

面向数据实体通过对数据和数据处理进行组织封装，形成数据服务。

信息服务
域不仅为监测管理决策服务域提供数据支撑，同时还为市级平台外的其它系统提供数据和信息服务。

3.2.1.1获取层
获取层涵盖市级平台从各子系统中抽取相关基础数据，进行清洗、转换、整理到数据仓库的全过程。

各数据源系统主要包括：行业子系统、城市监测运行平台、气电热联调联动平台等。

3.2.1.2数据层
数据层实现市级数据仓库中基础数据、汇总数据以及深加工后的数据、信息的集中管理，并可根据业务需求建立面向其他委办局的数据集市，如给市应急办的数据集市。

数据层包括基础数据、汇总数据、信息子层三个部分。

3.2.2监测管理决策服务域
监测管理决策服务域由市级平台访问层和应用层组成，对外（包括用户或外部系统）提供市级平台监测管理决策应用服务。

监测管理决策服务域通过基础功能构件的健全和完善，建立面向不同使用人员的不同应用解决方案，并通过信息访问渠道和信息推送机制来促进市级平台的易用性。

3.2.2.1应用层
应用层包括功能子层、应用子层和信息适配子层。

功能子层包括指标管理、监测对象管理、保障资源管理、预测模型管理、模板管理、GIS标注管理等。

应用子层面向城市生命线的管理和业务组织模式，其中的应用通过调用和编排功能子层提供的功能集中解决一类业务问题。

如实时监测、动态预测、综合分析、科学预警、辅助决策等。

信息适配子层根据不同使用角色需要，将应用子层中的各种应用进行整合，形成整体解决方案通过访问层提供给相应的角色。

例如：领导桌面、大屏指挥、业务系统等。

将应用层细分为功能子层、应用子层和信息适配子层，既解决了“应用适配”的问题，在功能架构上又进行了适度的解耦，并提升了基础功能的复用能力。

3.2.2.2访问层
访问层是各类使用人员访问市级平台的窗口和平台。

在访问层中整合了市级平台的访问资源，完善信息推送机制，并建立统一的市级平台门户。

市级平台门户实现应用嵌入、多渠道接入以及基础门户功能。

特别的要，将委领导的Web应用页面嵌入到门户中，使其在日常工作中能便捷访问市级平台所提供的服务。

3.2.3数据管理域
数据管理域包括市级平台数据质量管理体系和运维管理机制。

市级平台通过数据管理域有效地发挥数据管理的优势，进一步完善数据质量监控应用和数据运维管理机制，逐步实现城市生命线全程数据的监管。

元数据管理模块负责管理市级平台中的元数据，实现元数据自动获取和元数据存储，并构建相关的元数据管理功能和元数据应用。

数据质量管理子系统包括数据质量监控与数据质量管理流程，它们实现市级平台从数据源接口到应用展现的全流程数据质量监控与保障。

基于元数据的开发管理应用模块利用元数据来辅助进行应用开发，加强对开发过程的全流程管控，并在规化的开发过程中收集相应的元数据信息，提高元数据质量。

系统安全管理负责管理市级平台的安全。

它包括审计日志记录、接口管理和安全管理应用。

系统优化管理负责管理市级平台的优化，主要分为三个方面：系统优化、数据优化和应用优化。

备份与恢复为市级平台提供风险预防机制和灾难恢复措施，确保数据安全、
提高系统可用性、降低业务损失。

3.3 技术架构图
城市生命线实时监测物联网示工程市级平台技术框架图
市级平台采用面向服务的SOA 设计理念，充分考虑平台的扩展性、标准性和安全性，以事件驱动（EDA ）和元数据驱动（MDA ）来响应系统产生的事件和应对用户需求、展现形式的变动。

4 数据库设计
4.1 设计规 4.1.1 普通表命名规
整个系统的业务表按模块进行划分，一共分为4种类型。

表、字段命名：采用英文，中间采用”_”间隔。

4.1.2主键字段定义规
所有表必须有主键，原则上在无业务意义的序列号字段上建立主键。

主键的命名规则如下：
PK_表名
在一个表中加入无业务意义的序列号字段，在该字段上建立主键时，该字段的命名不按照数据字典的规命名，命名规则如下：
表名_ID(下划线)
该类字段的数据类型统一定为VARCHAR2(36)，即36位字符。

4.1.3索引定义规
为了提高查询速度，可以建立索引。

索引的作用相当于图书的目录，可以根据目录中的页码快读找到所需的容，当表中有大量记录时，若要对表进行查询，在表中建立索引，然后在索引中找到符合查询条件的索引值，最后通过保存在索引中的ROWID快速找到表中的相应记录。

对于业务生产数据，如果数据量很大（>1M）的表索引不可以超过4个，对于数据量很小（<1K）禁止使用索引。

对于业务统计数据，根据情况定义索引，没有明确限制。

4.1.4存储过程定义规
存储过程是在大型数据库系统中，一组为了完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。

存储过程是数据库中的一个重要对象，任何一个设计
良好的额数据库应用程序都应该用到存储过程。

对于普通业务处理过程禁止使用存储过程，只在需要运算大数据量，批量处理过程使用存储过程，存储过程的使用必须得到技术经理的认可。

4.1.5触发器使用规
触发器（trigger）是数据库提供给程序员和数据分析员来保证数据完整性的一种方法，它是与表事件相关的特殊的存储过程，它的执行不是由程序调用，也不是手工启动，而是由事件来触发，比如当对一个表进行操作（insert，delete，update）时就会激活它执行。

触发器经常用于加强数据的完整性约束和业务规则等。

本系统仅报警、预警部分可以使用触发器。

4.2数据库存储结构
Oracle数据库可划分为称作表空间的逻辑存储单元，每个tablespace可以包含很多oracle block。

下图展示了数据库如何存储表数据
从逻辑上讲，表包含有列值组成的行。

行最终以行片段的形式存储在数据库中，之所以称为行片段是因为在某些情况下，不可能在一个位置存储一整行。

表空间是oracle数据库中最大的逻辑结构，oracle数据库就是由一个或多个表空间组成的。

一个表空间的大小等于其中所有数据文件的大小之和。

数据库的大小等于其中表空间的大小之和，表空间可以被联机和脱机，system表空间不能脱机。

system表空间中包含数据字典和系统底层表，与数据库相关的管理信息。

该信息均包含在sysschema中。

只有sys用户使用或者拥有所需权限的其他管理用户才可以访问这些信息。

a.管理表空间：
1.表空间的管理主要包括确定表空间的大小，安排表空间所需要的存储空
间
2.创建、修改、删除表空间
3.选择修改表空间的区、段管理方式
4.设置表空间的状态等
b.确定表空间的大小：
1. 每行大概有多少字节
2. 该表最初或至少要包含多少行
3. 每个时间段表中的行的增长情况
4. 在该表上进行的操作的类型
5. 那种操作类型比较多
4.2.1表空间划分
4.2.2表空间数据文件对应关系
4.2.3表空间与数据表对应关系
4.3数据库文件备份与恢复
备份与恢复为市级平台提供风险预防机制和灾难恢复措施，确保数据安全、提高系统可用性、降低业务损失。

对于城市生命线系统而言，数据库是核心数据组成部分之一，因此针对数据库制定一个良好的备份策略是至关重要的。

4.3.1数据备份方式
针对不同类型数据备份要求，本项目使用了2种级别的备份方式，第一种是基于文件级别的备份；第二种是基于数据库级别的备份。

1.文件级别的备份
考虑到IT环境中除了数据库服务器和应用服务器以外，基本上属于文件级别的服务器。

2.数据库级别的备份
为了确保这些数据库7 x 24小时的运行状态，对的IT环境中涉及到的Oracle数据库进行备份和恢复。

4.3.2数据备份策略
对于关键应用来说，制定一个良好的备份策略是至关重要的。

一个好的备份系统，除了需要配备有好的软硬件产品之外，更需要有良好的备份策略和管理规划来进行保证。

备份策略的选择，要统筹考虑需备份的总数据量，线路带宽、数据吞吐量、时间窗口以及对恢复时间的要求等因素。

目前的备份策略主要有全量备份、增量备份和差分备份。

全量备份所需时间最长，但恢复时间最短，操作最方便，当系统中数据量不大时，采用全量备份最可靠。

增量备份和差分备份所需的备份介质和备份时间都较全量备份少，但是数据恢复麻烦。

根据不同业务对数据备份的时间窗口和灾难恢复的要求，可以选择不同的备份方式，亦可以将这几种备份方式进行组合应用，以得到更好的备份效果。

业务系统数据库采用Oracle数据库，根据业务特点，应用软件系统数据备份策略如下：
Oracle在归档模式下运行，利用备份软件数据库模块调用RMAN进行在线的热备份，可以在备份时，对备份数据保存在不同的存储对象中，利用多个磁带驱动器同时读写提高其数据备份的效率。

根据业务系统应用特点，Oracle的备份以周为备份周期，星期一到星期六做数据库累积增量、归档日志、控制文件和CATALOG用户所有对象的备份，星期日做全备份，保留前面一周期和当前周期的备份，每个周期有两份容余。

而且由于该应用的Oracle系统版本较新，也可以利用一些最新的Oracle备份技术，将同样的一份备份数据同时保存在不同的存储介质中去，如磁带和硬盘，以保证备份数据的完整性和安全性。

对于Oracle系统的数据备份和恢复的性能，可以通过开辟多个Oracle数据备份通道和多重数据迁移的技术得到保障。

详细如下所示（可以根据实际情况进行调整）：。