DB33 T 2052-2017 供排水数据库系统建设技术规范.pdf

《DB33 T 2052-2017 供排水数据库系统建设技术规范.pdf》由会员分享，可在线阅读，更多相关《DB33 T 2052-2017 供排水数据库系统建设技术规范.pdf（24页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 91.140.60 P 41 DB33 浙江省地方标准 DB33/T 2052 2017 供 排水数据库系统建设技术规范 Technical specification for drainage database system 2017 - 09 - 11 发布 2017 - 10 - 11 实施 浙江省质量技术监督局 发布 DB33/T 2052 2017 I 目 次 前 言 .II 1 范围 .1 2 规范性引用文件 .1 3 术语和定义 .1 4 供排水数据库基本要求 .3 5 供排水数据库建设 .3 5.1 供排水数据库设计 .3 5.2 供排水数据库命名规则 .5 5.3 供

2、排水数据库编写规则 .6 5.4 供排水数据库环境配置原则 .7 5.5 供排水数据库账户管理 .7 5.6 供排水数据库建设规范 .8 6 供排水数据库接口功能 .8 6.1 数据访问接口开放 .8 6.2 元数据的生成和汇交 .8 6.3 数据的交换 .8 6.4 导航目录管理 .9 6.5 开放服务状态监控 接口 .9 6.6 用户管理 .9 6.7 接口规范 .9 7 供排水数据库系统质量评定 .9 7.1 数据 质量 .9 7.2 运维 服务 质量 .9 8 供排水数据库系统运行维护 .10 8.1 运维人员 .10 8.2 基础 运行环境 .10 8.3 日志管理 .10 8.4

3、安全防护和故障处理 .10 附录 A 供排水生产数据元字段命名规则 .12 附录 B 供排水营业收费数据元字段命名规则 .17 DB33/T 2052 2017 II 前 言 本标准依据 GB/T 1.1-2009的规则起草。 本标准由浙江省住房和城乡建设厅提出并归口。 本标准主要起草单位：浙江省城市水业协会、杭州市水务控股集团有限公司、太平洋水处理工程有限公司、杭州杭开新能源科技股份有限公司。 本标准主要起草人：代荣、陈柳、叶圣炯、王蕾、朱弘、贾伯林、范青如、秦爱冬、张于。 DB33/T 2052 2017 1 供排水数据库系统建设技术规范 1 范围 本 标准 规定了 供排水数据库基本要求、

4、供排水数据库建 设、供排水数据库接口功能、供排水数据库系统质量评定、供排水数据库系统系统运行维护等。 本 标准 适用于供排水数据库的建设、运维和服务。 2 规范性引用文件 下列文件对于本文件的引用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 GB/T 9361 计算机场地安全要求 GB/T 22239 信息安全技术 信息系统安全等级保护基本要求 GB/T 22240 信息安全技术 信息系统安全等级保护定级指南 GB 50174 电子信息系统机房设计规范 TR-REC-001 参考型数据库建设规范 TR-R

5、EC-019 数据加工增值管理方法 TR-REC-031 建库技术指导规范 TR-REC-032 元数据访问服务接口规范 TR-REC-033 数据跨域互操作技术规范 TR-REC-034 跨域用户认证接口规范 TR-REC-062 技术文档参考规范 TR-REC-063 数据质量管理规范 TR-REC-064 数据质量评测方法与指标体系 DB33/T XXXX 智慧供排水信息系统安全技术规范 3 术语和定义 下列术语和定义适用于本文件。 3.1 供排水数据库 面向供排水企业信息系统， 按照 数据结构 来组织、 存储 和管理数据的建立在计算机存储设备上的仓库； 同时构建必要的 数据应用的环境，

6、实现供排水自动化管理。 3.2 供排水子库 DB33/T 2052 2017 2 供排水原始数据经过清洗、转换、映射等加工整理整合后形成的规范化数据库，是供排水数据库进行数据保存、组织和管理的最基本单元。 3.3 第三范式（ 3NF) 每个非 关键字 列都 独立 于其他非关键字列，并依赖于关键字，第三范式指数据库中不能存在 传递函数依赖 关系。 3.4 数据集 由 相关数据组成的可标识集合，可以是逻辑上或物理上的数据库，也可以是一个文件（如文本文件、图像、视频等）或文件集合。 3.5 编码体系 元数据修饰的一种方式，用来规定元素取值范围或取值意义的受控词表或规范名称。供排水数据库编码体系包含了

7、对关系数据库相同元素值的表达规范，相同类型文件型数据集存储格式，组织方式等的规定。 3.6 索引库 按照供排水子库数据索引的需求，通过抽取和转换相关供排水子库中的有关数据形成的数据库。索引库中除包含用于供排水子库检索和概要显示的字段外，还必须包含一个指针字段，用于存储相关数据的访问地址。 3.7 元数据 描述 数据 的数据，主要是描述数据 属性 的 信息 ，用来支持如指示存储位置、 历史 数据、 资源 查找、文件记录等功能。 3.8 数据交换 指 为了满足不同信息系统之间数据资源的共享需要，依据一定的原则，采取相应的技术，实现不同信息系统之间数据资源共享的过程。 3.9 编码 信息从一种形式或

8、格式转换为另一种形式的过程也称为计算机编程语言的代码简称编码。用预先规定的方法将文字、数字或其它对象编成数码，或将信息、数据转换成规定的电脉冲信号。 DB33/T 2052 2017 3 3.10 E-R图 也称实体 -联系图，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。 3.11 web service 一个平台独立的，低耦合的，自包含的、基于可编程的 web的应用程序。 3.12 数据源 数据源是提供某种所需要数据的器件或原始媒体。 4 供排水数据库基本要求 4.1 供排水企业 应根据系统建设规模和业务需求选择安全、稳定和高效的数据库系统。 4.2 应根据供排水数据资

9、源的内容特征及数据资源之间的关系，确定合理的内容框架和数据模型，构建若干供排水子库，并将数据资源进行分类保存和管理。 4.3 应根据供排水子库的内容特征，提出合理的数据分类目录，并将各供排水子库归入相应的类目。 4.4 供排水数据库的所有数据对象设计与定义、数据分类、数据存储、数据表示应遵循完整性、一致性、准确性、实用性、规范化原则。 4.5 供排水数据库应达到第三范式（ 3NF)要求。 5 供排水数据库建设 5.1 供排水数据库设计 5.1.1 供排水数据库设计原则 5.1.1.1 数据的一致性与标准性 数据库的设计应结合已建立系统的数据，并能与其他系统之间进行数据交换；数据库的设计除遵循数

10、据库设计的软件行业标准外，还应遵循国家、地方标准及行业的习惯性事实标准，以方便数据交流及功能的实行。 5.1.1.2 数据的实用性与完整性 数据库设计应按照系统规模和实际需求，遵循“先进性与实用性并重”的原则，保证数据的实用性；数据库设计中数据的完整性应通过约束条件来 控制，约束条件可检验进入数据库中的数据值，约束条件可防止重复或冗余的数据进入数据库，约束条件可保证新建或修改后的数据能够遵循所定义的业务知识。 5.1.1.3 数据的独立性和可扩性 DB33/T 2052 2017 4 数据库的数据应独立于应用程序，数据库的设计及其结构的变化不影响应用程序；数据库设计应具有扩展性能，系统增加新的

11、应用或新的需求时，不得引起整个数据库结构的变动。 5.1.1.4 数据的安全性 数据库设计应具备一个合理和有效的备份和恢复策略以及具备合理的对数据库访问的授权设计，避免数据的非法访问，保证数据库的 安全性。 5.1.1.5 数据分级管理机制 根据系统访问角色，应将用户分成领导决策分析用户、系统管理用户、运行浏览用户和运行调度用户等几个角色，分别赋予角色访问数据的权限和使用系统功能的权限，严格控制角色登录，实现数据的分级管理。 5.1.1.6 数据的兼容性 数据库设计应结合数据采集、数据入库、数据应用，以便于在空间数据的基础上进行设施及相关属性的设计，空间数据格式设计应与模型所需数据结合，利于模

12、型数据直接使用空间及设施的相关数据。 5.1.2 供排水数据库设计流程 5.1.2.1 需 求分析 应对供排水系统数据及需求有明确和充分的了解；得到数据字典描述的数据需求和数据流图描述的处理需求；调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 5.1.2.2 概念设计 概念设计可采用 E-R模型进行，用 E-R图建立一个独立的具体的数据库管理系统的概念模型。针对各个业务系统进行局部数据视图设计，然后进行局部数据视图集成，进行整体数据视图的设计。在整体设计中找到最大的共享数据集，同时对这些共享数据进行语义上的描述 (数据产生的业务系统、数据使用的业务系统等 )。 5.

13、1.2.3 逻辑设计 应将概念结构转换为具体的数据库管理系统所支持的数据模型，并对其进行优化。将 E-R图转换为关系模型。 5.1.2.4 物理设计 根据数据库管理系统的处理要求，为逻辑设计阶段形成的逻辑模型选取一个合适的物理结构，进行存储安排、设计索引、行程数据库内的模式。 5.1.3 供排水数据库结构设计规则 5.1.3.1 对程序流程有关的状态信息使用域应进行限制和定义，不允许用户修改定义。 5.1.3.2 用户可修改的状态列表信息用数据表来定义，一经创建后，用户只可修改名称，不能修改代码，修改后的名称 与原名称应代表相同的意义。 5.1.3.3 用户采用列表录入的文字信息，在一个统一的

14、“系统信息”表中定义，用户可任意创建和修改。用此种方法录入的信息，录入的信息与选择列表不存在约束关系，列表只是作为文字录入的一种辅助手段。 DB33/T 2052 2017 5 5.1.3.4 辅助编码表应至少有两列，即代码和名称，在名称非常稳定的情况下才可不使用代码。 5.1.3.5 记录业务数据的表中应设有“录入员”和“录入日期”列，由系统自动记录。 5.1.3.6 记录业务数据的表中，根据需要设置“过程”和“状态”列，“过程”列用一位数字或字符记录 ；状态列用一位数字或字符记录。所有表的过程状态的改变日期和操作人由一单独表来记录，表中记录状态改变的表标识记录标识操作人和操作日期。 5.1

15、.3.7 基本编码表中应设置“编码”“缩语”“名称”，“编码”作为主键与其它表的外键形成对应关系，完成基于主键 外键的完整性约束。 5.1.3.8 记录录入单据的表中设置“自动单据号”，由一字符开始以区分单据类型，后跟一数字序列表示序号。“自动单据号”由系统自动生成，作为主表的主键，不允许用户修改，并作为连接主表和明细表的外键。 5.1.3.9 明细表中应 设置序号列，用于同一单据中排列各行的序号。 5.1.3.10 用于记录业务数据的数据表与用于报表的数据表应分别存于不同的数据库中，分别命名为“业务数据库”和“决策数据库”。“业务数据库”独立于“决策数据库”进行设计，“决策数据库”中的数据来

16、源于“业务数据库”。 5.1.3.11 对于主表、明细表结构，设计对应的视图将两表连接用于查询。 5.1.3.12 禁止直接用编码或名称列表作为固定的过滤条件对数据进行查询。应将包含此过滤条件的查询做成特定的视图；或在编码表中加入一属性字段用于分类。 5.1.3.13 对于业务数据表应设定一个“存档标记列”，对于新增行或修改行设置该标志，以便将业务数据库中的数据向决策数据库复制时用以选择需更新的数据。当采用数据库复制技术时，也应设定此标志，以备用。此标志的设置可以由应用程序或触发器来执行。 5.1.3.14 决策数据库中应复制基本编码表和辅助编码表，以保持决策数据库数据的完整性。 5.1.3.

17、15 实体应同时采取多种分类方法， 一个实体有多于一种的分类方法，或实体中的每个实例所属的类的数量是不定的，这时实体表和分类表之间的关联应是多对多的，即一个实体属于一个分类而 同时也属于其它的分类；对于具有可多选分类标志的表，与分类名称列表之间存在多对多的关系，应按多对多的关系来处理。 5.1.3.16 一个业务表（或主表 +明细表）依赖另外一个业务表的数据，或在流程上一个业务表根据另一个业务表生成，则该业务表中应有一字段记录另一业务表对应记录的标识； 一个业务流程应作为一个事务，并保证这一事务的完整性；事务应有一个标识，在这个事务进行过程中所产生的一切数据都应打上事务标识作为标记，可以“回滚

18、”整个事务，或“回滚”（从后向前）到事务进行的某一点上再继续进行直到完成事务。 5.1.3.17 业务数据表往往关联许多的基本信息表，这些基本信息表中有时含有一些分类字段，而业务数据表的分类统计需引用这些字段；分类字段的内容会改变，而这种不能改变影响业务数据的统计结果，则在这些业务数据表中应包含这些分类字段，用以记录业务发生时该字段的内容。 5.1.3.18 类别和状态的多选分为必选（ 1.n）和可选（ 0.n），必选在设计时应有说明，在程序实现中有控制和检查；两个可选的类别或状态表可以合并为一个表，再与引用此表的主表形成多对多的关系。 5.2 供排水数据库命名规则 5.2.1 前缀 命名规则

19、 5.2.1.1 表和视图命 名规则如 下： a) 系统信息表： TS_； b) 基本编码表： TB_； c) 决策数据表： TD+业务模块缩写 _； DB33/T 2052 2017 6 d) 业务数据表：业务模块缩写 _； e) 业务模块缩写 :不同的业务以不同的缩写（ 2 4个字符）开始 ； f) 视图：表命名的基础上加前缀改为 V_； e) 后缀：主表、明细表结构的表，主表为 _M；明细表为 _L； g) 单词首写字母应大写，多个单词间不得用任何连接符号 ； h) 表命名宜用英名描述，特殊情况可用拼音，不得使用汉字。 5.2.1.2 过程、函数、触发器命 名规则如 下： a) 过程：

20、SP_； b) 函数： FN_； c) 触发器： TR_表名 _，操作前触发器 (INSTEAD OF)： TR_表名 _OF。 5.2.1.3 自定义数据类型、默认、规则命 名规则如 下： a) 自定义数据类型： UD_； b) 默认 : DF_，对于非绑定的默认可取系统默认的名字 ； c) 规则： RU_，对于非绑定规则 (约束 )可取系统默认的名字。 5.2.1.4 主键、外键关系、索引命 名规则如 下： a) 主键 : 采用后缀，表名 _PK； b) 外键关系：采用后缀 ， _主表 _从表 _FK； c) 索引：采用后缀，列名 _IDX，符合索引列名间用 _隔开。 5.2.2 列命名规

21、则 5.2.2.1 列命名应采用可表达对象明确意义的形式命名，部分对安全具有特殊要求的可用编号命名。 5.2.2.2 列命名应以字母开头，包含具有特定含义的英文单词或汉语拼音，同一个对象不得英文和汉语拼音混用。 5.2.2.3 拼音的使用规则应为采用中文名称首字的全拼，后接其它字的中文拼音首字母，两个对象根据此方法命名出现重复则对两个对象都用中文拼音的完整拼音来表示，不得使用汉字。 5.2.2.4 书写时单词第一个字母应大写，复合含义的其他单词首字母应大写，其余小写。 单词之间以下划线“ _”间隔，长度不超过 30 个字符。 5.2.2.5 严禁使用关键字命名。 5.2.2.6 宜优先采用前缀

22、来命名区分，在复杂的对象模块条件下，可采用后缀命名来补充。 5.2.3 供排水生产数据元字段命名规则 供排水生产数据元字段命名规则应符合 本规范附录 A的规定。 5.2.4 供排水营业收费数据元字段命名规则 供排水营业收费数据元字段命名规则 应符合本规范附录 B的规定。 5.3 供排水数 据库编写规则 5.3.1 编码规则 5.3.1.1 应保持地理空间对象的逻辑一致性和唯一性，使不同类型用户能够对共享的数据进行综合查询。 5.3.1.2 应体现数据指标的整体系统性。在保持各专业数据库本身数据分类编码体系逻辑一致性的同时，通过分类编码体现综合集成后整体数据的分类系统，满足建立和更新综合数据库的

23、需要。 DB33/T 2052 2017 7 5.3.1.3 应保持数据库中数据项编码相对稳定。数据库中的数据结构是根据数据项之间的 ER模型（实体 -关系模型）通过软件实现的，数据库建设应将频繁变动的内容放到元数据中去解决；数据 库综合集成过程中，统一重新编码的范围仅限于数据项，现有数据库的 ER结构应保持固定，进行统一编码后便于进行数据库集成。 5.3.1.4 应保持简化与统一相结合，并具有可扩充性。空间数据的编码应考虑供排水行业已经建立的编码标准，并结合行业的实际情况。数据的编码应制定出合理、有效、有用的编码方案。 5.3.2 语法规则 5.3.2.1 存储过程的 In、 out参数应按

24、类别分开书写，不应交叉。 5.3.2.2 存储过程中变量的声明应集中在 is和 begin关键字之间申明。 5.3.2.3 应使用相关 表字段类型来定义相关的变量，并删除无用的变量与参数。 5.3.2.4 存储过程中存在多分支时，若有事务控制，应确保各分支均有事务结束处理，且发生异常时，必须在异常处理机制中进行异常捕获。 5.4 供排水数据库环境配置原则 5.4.1 生产、开发环境应分离。 5.4.2 生产、开发职责应分离。 5.4.3 一个生产应用应对应一个开发环境。 5.4.4 一个业务方向应配置一套生产库集群，不同业务方向数据交互应通过中间平台实现，不得直接使用数据库链接访问。 5.4.

25、5 测试环境应根据实际需要进行 部署。 5.5 供排水数据库账户管理 5.5.1 基本原则 5.5.1.1 数据库账户及其权限应依据最小授权原则设置，不同用途的账户应分设，并应对授权的再次传播进行控制。 5.5.1.2 每个连接到数据库中进行操作的个人或应用系统都必须有独立的数据库账户，达到数据库操作的可追溯性。 5.5.1.3 不同的数据库管理员应依据职责对不同的表数据进行权限划分，不得互相操作。 5.5.1.4 数据库账户应具有唯一性，禁止不同的数据库使用相同的账户与口令，禁止生产库和测试库使用同一组账户与口令。 5.5.1.5 上线应用系统不得使用数据库默认账户，应把默认账户设定为口令到期和被锁定。封锁主机操作系统对数据库账户的直接访问权限。 5.5.1.6 在日常巡检中应及时删除多余、过期的账户和清理权限过大的账户。 5.5.1.7 应对数据库账户授权分配情况进行书面记录。 5.5.1.8 应开启数据库审计功能，记录账户操作情况，包括记录应用系统用户、数据库账户操作时间和事项等。 5.5.2 密码控制 5.5.2.1 数据库账户密码应为无意义的字符组，长度至少为十位，并包含大写字符、小写字符、数字和特殊符号。