收藏 分销(赏)

DB11∕T 1919-2021 政务数据汇聚共享规范(北京市).pdf

上传人:曲**** 文档编号:76557 上传时间:2022-05-30 格式:PDF 页数:17 大小:306.72KB
下载 相关 举报
DB11∕T 1919-2021 政务数据汇聚共享规范(北京市).pdf_第1页
第1页 / 共17页
DB11∕T 1919-2021 政务数据汇聚共享规范(北京市).pdf_第2页
第2页 / 共17页
DB11∕T 1919-2021 政务数据汇聚共享规范(北京市).pdf_第3页
第3页 / 共17页
DB11∕T 1919-2021 政务数据汇聚共享规范(北京市).pdf_第4页
第4页 / 共17页
DB11∕T 1919-2021 政务数据汇聚共享规范(北京市).pdf_第5页
第5页 / 共17页
点击查看更多>>
资源描述

1、ICS 35.240 CCS L 72 DB11 北京市地方标准 政务数据汇聚共享规范 Specification for government data aggregation and sharing 北京市市场监督管理局 发 布 DB11/T 19192021 2021- 12- 28 发布 2022- 04- 01 实施DB11/T 19192021 I 目 次 前言 . II 1 范围 . 1 2 规范性引用文件 . 1 3 术语和定义 . 1 4 总体架构 . 2 5 汇聚共享数据类别及要求 . 2 6 数据汇聚共享方式及要求 . 3 7 数据质量要求 . 4 8 数据安全保护要求

2、. 4 附录 A(规范性) 政务数据汇聚共享业务流程 . 5 附录 B(资料性) 数据接口服务调用步骤 . 7 附录 C(资料性) 数据接口服务调用示例 . 9 附录 D(规范性) 数据质量要求 . 12 参考文献 . 14 DB11/T 19192021 II 前 言 本文件按照GB/T 1.12020标准化工作导则 第1部分:标准化文件的结构和起草规则的规定起草。 本文件由北京市经济和信息化局提出并归口。 本文件由北京市经济和信息化局组织实施。 本文件起草单位:北京市经济和信息化局、北京市大数据中心、太极计算机股份有限公司、清华大学、北京大学、北京航空航天大学、北京交通大学、北京工业大学、

3、阿里云计算有限公司、腾讯云计算(北京)有限责任公司、中电长城网际系统应用有限公司、数据堂(北京)科技股份有限公司、华控清交信息科技(北京)有限公司、首都信息发展股份有限公司。 本文件主要起草人:贾晓丰、高文飞、刘旭、赵琰昉、刘志荣、苗婕、章敏、张晰、高嵩、江茜、张健枫、王睿宇、王宇航、赵章界、赵莹、肖益、李宝东、卢洪、穆显显、郭燕航、蔡姗姗、徐葳、张久珍、邓攀、李浥东、林绍福、皮文凯、李树翀、张子彪、张兴、齐红威、姚会文、李志荣、张建伟。 DB11/T 19192021 1 政务数据汇聚共享规范 1 范围 本文件规定了政务数据汇聚共享的总体架构、数据类别、共享方式,描述了对数据质量和数据安全保

4、护的要求。 本文件适用于政务部门 (包括行政机关和具有公共事务管理职能的事业单位) 的非涉密政务数据通过北京市大数据平台进行汇聚共享的实施和管理。 2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。 其中, 注日期的引用文件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。 DB11/T 19182021 政务数据分级与安全保护规范 DB11/T 3372021 政务数据资源目录体系规范 DB11/T 553.5 政务信息资源共享交换平台技术规范 第5部分:接口规范 3 术语和定义 下列术语和定义适用于本文件。

5、3.1 政务数据 government data 各级政务部门及其支撑单位在履行职责过程中依法采集、生成、存储、管理的各类数据资源。 来源:GB/T 38664.12020,3.1,有修改 3.2 数据汇聚共享 data aggregation and sharing 政务部门因履行职责需要,使用其他政务部门的政务数据(或接口服务),以及为其他政务部门提供政务数据(或接口服务)的行为。 来源:GB/T 38664.12020,3.2,有修改 3.3 目录区块链系统 directory blockchain systerm 利用区块链技术理念,对北京市职责目录、数据目录、库表目录进行统一管控的分

6、布式系统。 3.4 数据(或接口服务)提供方 data(interface service)provider 在政务数据汇聚共享过程中,提供数据(或接口服务)的政务部门。 3.5 DB11/T 19192021 2 数据(或接口服务)需求方 data(interface service)demander 在政务数据汇聚共享过程中,申请使用数据(或接口服务)的政务部门。 3.6 数据目录 data directory 数据资源和数据项的具体字段包含数据资源名称、数据资源摘要、数据起始日期、数据更新周期、数据格式、字段名称、数据类型及长度、是否主键、是否非空、数据量等。 4 总体架构 政务数据汇聚

7、共享工作依托北京市大数据平台开展, 通过目录区块链系统对政务数据进行汇聚共享,从提出申请、审批授权、获取共享到评价反馈,各环节操作实时记录上链、全程留痕可溯。总体框架见图1,详细业务流程按照附录A描述执行。 图1 政务汇聚共享总体架构 5 汇聚共享数据类别及要求 5.1 电子文件 5.1.1 以电子文件作为数据资源进行汇聚共享, 常用电子文件的存储格式有 wps、 xml、 txt、 doc、 docx、html、csv、xls、xlsx 等。 5.1.2 以电子文件类进行数据汇聚共享时,应遵循以下要求: a)电子文件名称应规范统一,与目录区块链中数据目录的数据资源名称保持一致; b)电子文件

8、的存储路径应规范统一,可根据更新的频度和检索效率建立子文件夹,不应随意更改路径; c)特殊类电子文件应提供必要的说明文档,确保所有文件内容可被正确理解; d)提供电子文件对账表,明确所汇聚电子文件包含的内容和数量等信息; DB11/T 19192021 3 e)建立异常反馈机制,通过异常数据反馈表及时解决数据问题。 5.2 数据库表 5.2.1 以数据库表作为数据资源进行汇聚共享,常用数据库存储格式有 oracle、sql server、db2、KingbaseES、access、dbf、dbase、sysbase 等。 5.2.2 以数据库表类进行数据汇聚共享时,应遵循以下要求: a)数据库

9、表名称应规范统一,一般为“机构简称首字母缩写+数据资源名称首字母缩写”,数据资源名称应与目录区块链中数据目录的数据资源名称保持一致; b)数据库表字段应与目录区块链中数据目录的数据项保持一致,且必须设有主键字段,并在数据表库中创建主键约束; c)数据库表结构应保持稳定,不应随意更改; d)提供必要的字段说明文档和对应的全部代码表,确保所有数据内容可被正确理解; e)提供数据对账表,包含数据条数等信息; f)建立异常反馈机制,通过异常数据反馈表及时解决数据问题。 5.3 数据接口服务 5.3.1 以数据接口服务作为数据资源进行汇聚共享,常用的接口方式有 WebService、Restful 等,

10、常用的数据接口服务格式有 XML、JSON 等。 5.3.2 以数据接口服务类进行数据汇聚共享时,应遵循以下要求: a)应提供详细的数据接口服务说明文档; b)一个数据接口服务一般应且只对应一类数据资源; c)服务应是无状态的,两次请求之间无须状态和会话的保持; d)服务地址和参数不应随意变更。 6 数据汇聚共享方式及要求 6.1 原始数据交换 6.1.1 电子文件交换方式 提供的电子文件格式应满足5.1.1的要求, 且每次应在固定的文件服务器数据路径下进行文件推送,文件资源在完全写入服务器磁盘之前,任何系统、人员不应再操作文件。 6.1.2 数据库表交换方式 按照数据汇聚共享的场景,支持下列

11、几种模式交换: a)标记位模式:适合大批量数据交换,应包含主键、标记位字段、推送至库表的时间字段,并且允许共享系统在完成交换之后更改标记位的值; b)时间戳模式:适合增量数据交换,应包含主键、时间戳字段,时间戳应精确到毫秒; c)触发器模式:适合增量模式交换,应包含主键、数据表上能建立增删改触发器; d)全量模式:全量模式适合数据库表量少,且每次更新都是全表更新的场景。 6.2 数据接口服务调用 6.2.1 数据接口服务封装 DB11/T 19192021 4 将各类数据转换为API接口,接口设计应符合DB11/T 553.5的要求,支持多源异构的数据库格式以及接口协议,包括主流关系型数据库、

12、Hadoop以及WebService、FTP、HTTP、自定义协议等。 6.2.2 数据接口服务管理 6.2.2.1 数据接口服务提供方应对提供的数据接口服务进行管理,包括对服务的注册、申请、维护、审核、发布、监控等。 6.2.2.2 对于以API接口服务方式提供的服务可以在配置下发或获取方式时指定数据范围, 系统自动生成接口的授权,访问者只有根据该授权才能获取到数据。 6.2.2.3 数据接口服务调用步骤见附录B,数据接口服务调用示例见附录C。 6.3 数据隐私计算 6.3.1 利用多方安全计算、联邦学习、可信执行环境等方式,在数据可用不可见或数据可用不可得的前提下,实现不同来源数据在保持加

13、密状态下进行融合分析运算,并将运算结果进行共享。 6.3.2 在密文数据上执行数据操作,避免数据使用方直接接触明文数据,以提高计算过程中的数据安全,确保敏感数据不泄露。 7 数据质量要求 7.1 政务数据汇聚共享时应从数据的可用性、完整性、规范性、一致性和时效性五个方面保证数据的质量。 7.2 数据质量要求按照附录 D 要求执行。 8 数据安全保护要求 数据安全保护要求应符合DB11/T 19182021的要求,对汇聚共享数据进行分级分类管理,并根据数据级别采取相应的管理措施和技术手段,对数据汇聚共享过程进行有针对性的保护,个人信息、敏感数据和重要数据应加强安全管控措施。 DB11/T 191

14、92021 5 附 录 A (规范性) 政务数据汇聚共享业务流程 A.1 政务数据汇聚业务流程 A.1.1 数据提供方编制数据目录,依托市大数据平台目录链系统进行目录上链,并准备数据,向市大数据平台提出数据汇聚申请。 A.1.2 市大数据平台对汇聚的数据进行核验,核验通过后则进行数据接入操作,未通过则将核验结果反馈给数据提供方。 A.1.3 数据提供方依据数据核验结果对数据进行完善, 完善后再次向市大数据平台提出数据汇聚申请。 A.1.4 市大数据平台对接入的数据进行数据质量评估,并将结果反馈给数据提供方,数据提供方依据数据质量反馈意见进行修改完善。 A.1.5 政务数据汇聚业务流程按照图A.

15、1执行。 图 A.1 政务数据汇聚业务流程 DB11/T 19192021 6 A.2 政务数据共享业务流程 A.2.1 数据需求方通过市大数据平台提出数据共享申请,市大数据平台对申请的数据进行共享属性判断,对无条件共享数据可直接进行数据共享。 A.2.2 对于有条件共享的数据,则需先判断数据是否授权,如果未授权,则向数据提供方提出授权申请,数据提供方审核授权后方可进行共享。 A.2.3 若数据提供方未授权,数据需求方可向市大数据核心工作组提出申请,若市大数据核心工作组判定应提供数据共享则启动共享程序,否则维持原状。 A.2.4 市大数据平台针对可共享的数据,先判断是否已汇聚到市大数据平台,若

16、未汇聚,则启动数据汇聚流程,汇聚后进行数据共享,若已汇聚,则直接进行数据共享。 A.2.5 政务数据共享业务流程按照图A.2执行。 图 A.2 政务数据共享业务流程 DB11/T 19192021 7 附 录 B (资料性) 数据接口服务调用步骤 数据接口服务调用步骤,涉及数据接口服务需求方、服务提供方和大数据平台等角色。数据接口服务调用步骤详见图B.1。 图 B.1 数据接口服务调用步骤 B.1 服务需求方 B.1.1 通过授权码,从服务代理端获取令牌。 B.1.2 使用令牌,对服务请求者身份标识、服务标识和请求时间进行签名计算,得到签名。 B.1.3 将服务请求者身份标识、服务标识、请求时

17、间和签名放入请求消息中,发送请求到服务代理平台。 B.2 市大数据平台 获取请求消息的服务请求者身份标识、服务标识、请求时间(_rtime)和签名信息等信息,进行权限验证和调用频率、调用次数、流量的检验。 DB11/T 19192021 8 B.3 服务提供方 B.3.1 获取请求数据进行相关业务处理。 B.3.2 根据授权表内容获取输出参数信息过滤输出参数。 B.3.3 返回调用结果给市大数据平台,再由市大数据平台返回给服务需求方。 DB11/T 19192021 9 附 录 C (资料性) 数据接口服务调用示例 C.1 数据接口服务输入参数JSON描述 returnType: json,

18、page:1, pageSize:2, “whereList”: queryField:name,logical :equals,queryValue:测试 数据接口服务输入参数说明见表C.1。 表 C.1 数据接口服务输入参数说明表 提交方式 POST 接口协议 HTTP+JSON 内容类型 application/json 提交资源数据 名称 是否必须 类型 长度 描述 returnType 是 string 32 返回数据格式(json/xml) page 否 string 20 页码数(可以为空,但要有这个参数),为空时默认 1 pageSize 否 string 20 每页最大显示行

19、数(可以为空,但要有这个参数),为空时默认取接口默认值 whereList 是 Json 数组 查询条件,下边为 json 对象参数 名称 类型 长度 描述 queryField string 50 查询列 logical string 50 查询符(下表有详细介绍) queryValue string 100 查询值 提交 http header数据 名称 是否必须 类型 长度 描述 BJS_sid 是 string 36 服务标识 sid BJS_rid 是 string 36 服务 rid BJS_sign 是 string 36 签名信息 BJS_rtime 是 string 36 服

20、务调用时间 返回 Http 状态 200 DB11/T 19192021 10 C.2 数据接口服务返回参数JSON描述 columns: ZD1, ZD2, ZD3, ZD4, ZD5, ZD6 , columnsInfo : columnName :ZD1, columnComments :, columnType :DATE, columnLength: 7 , columnName: ZD1, columnComments: 字段1, columnType :VARCHAR2 , columnLength :50 , columnName :ZD2 , columnComments :

21、字段2 , columnType :VARCHAR2 , columnLength :18 , columnName : ZD3 , columnComments :字段3, columnType :VARCHAR2 , columnLength :10 , columnName :ZD4, columnComments :字段4, columnType :DATE , columnLength :7 , columnName :ZD5 , columnComments :字段5 , columnType :DATE , columnLength: 7, columnName: ZD6, co

22、lumnComments: 字段6, columnType :VARCHAR2 , columnLength :6 , dataList: ZD1: XXX, ZD2: 1111111, ZD3: XX, ZD4 :2020 - 01 - 01 ,ZD5 :1998 - 01 - 01 ,ZD6 :, ZD1: XXX, ZD2: 1111111, ZD3: XX, ZD4 :2020 - 01 - 01 ,ZD5 :1998 - 01 - 01 ,ZD6 : ,counts :1000 ,page :1,maxCount :2 数据接口服务返回参数说明见表C.2。 DB11/T 191920

23、21 11 表 C.2 数据接口服务返回参数说明表 提交方式 POST 接口协议 HTTP+JSON 内容类型 application/json 返回数据参数 (输出参数) 名称 类型 长度 描述 columnsInfo Json 数组 列信息,包括类型,长度,备注等信息。 (下边为 json 对象参数) 名称 类型 描述 columnName string 列名称 columnComments string 列备注 columnType string 类型 columnLength string 长度 columns string 1000 列显示字符串 page string 20 页码数

24、 maxCount string 20 每页最大显示行数 counts string 20 查询全部记录数 dataList Json 数组 json 对象中 key 为列名,value 为实际值 DB11/T 19192021 12 附 录 D (规范性) 数据质量要求 D.1 数据可用性 D.1.1 政务数据汇聚共享应确保数据可读、可理解、可用。 D.1.2 有信息系统支撑的数据应提供结构化文件,并在汇聚数据时同步提供数据字典和码表,确保数据的可读可理解。 D.1.3 所提供的数据要保持独立可用,避免多类业务数据混合提供。 D.1.4 通过接口方式对接的,数据提供方要遵循接口传输规范,具有

25、完整的日志记录,保证数据可用。 D.2 数据完整性 D.2.1 目录完整 数据汇聚共享前应依据DB11/T 3372021的相关要求,确认形成完整的数据目录,按照实际汇聚数据对北京市目录区块链系统中数据目录进行完善。 D.2.2 字段完整 应涵盖该数据的所有有效字段。 示例:“户籍人口登记信息”包含“姓名、出生日期、性别、身份证号码、籍贯、家庭住址、曾用名”字段,汇聚数据应包含全部字段。 D.2.3 释义完整 应确保字段取值所配套的字典表、码表的完整性。 示例:“SEX”字段对应的字典名称“性别”,数据内容为“0”、“1”,“0”对应的实际内容为“男”,“1”对应的实际内容为“女”,汇聚数据应

26、包含所有字段的完整解释。 D.2.4 周期完整 应覆盖该数据自采集日期起的全量历史数据,同时数据字段中应包含数据入库时间。 示例:“户籍人口登记信息”采集起始时间为2006年,则应汇聚自2006年至今的全量历史数据。 D.3 数据规范性 D.3.1 格式规范 D.3.1.1 有信息系统支撑的应提供结构化数据,数据项名称为英文的应提供数据项对应的中文说明。 D.3.1.2 通过接口方式对接的,数据提供方要遵循接口传输规范。 D.3.2 内容规范 D.3.2.1 数据的核心(非空)字段不能为空值。 示例:“户籍人口登记信息”中的“姓名”字段不能为空。 D.3.2.2 不应包含因业务或技术原因产生的

27、冗余数据。 DB11/T 19192021 13 示例:同类数据中不应包含2条完全相同的记录。 D.3.2.3 不应包含错误数据。错误数据包括但不限于以下情况: a)无效测试数据。系统建设或测试过程中残留的、无实际业务意义的测试数据。 示例:数据中包含多条“test”、“111111”等无效记录。 b)非法格式数据。字符类型、长度等不满足格式规范约束的数据。 示例:“年龄”为“%”;“身份证号码”位数为19位。 c)非法值数据。数据中包括多余的空格、乱码、全角、繁体等错误数据。 示例:“姓名”为“张三”;“电话号码”为全角数字例如“”。 d)范围溢出数据。超出字段取值范围的数据。 示例:“年龄

28、”为“300”。 e)逻辑错误数据。明显不符合合理业务逻辑的数据。 示例:“身份证号码”7到10位(表示出生年份)为“1790”。 D.4 数据一致性 D.4.1 数据目录一致性 数据汇聚共享以各部门目录区块链中数据目录为基准,应确保数据资源名称、数据项名称、数据格式等与“上链”数据目录完全一致。以非结构化文件方式提供的(如PDF、JPG、Word等),需在目录区块链“数据项”中填写为“附件”。大数据平台获取到数据后会与“上链”数据目录进行核验对比,核验通过才算完成汇聚。 D.4.2 数据内容一致性 D.4.2.1 不应存在数据名称相同、数据项(字段)不同的情况。 示例:两类数据名称均为“北京

29、市平均薪资水平”,其中一类数据的字段为“教育行业平均薪资、公安行业平均薪资等”,另一类数据的字段为“年份、薪资水平、详情”。 D.4.2.2 不应存在数据项(字段)相同、数据名称不同的情况。 示例:三类数据的字段均为“姓名、身份证号码、性别、年龄、居住地”,但数据名称分别为“个人基本信息”、“个人信息”、“个人基本数据”。 D.4.2.3 不应存在数据名称和数据项(字段)相同、数据内容不同。 示例:来自两个信息系统的“2007年平均薪资”数据,分别为“2000”和“2500”。 D.5 数据时效性 D.5.1 更新周期 市大数据平台汇聚的数据应与各政务部门生产系统数据的更新周期保持同步更新。

30、D.5.2 更新方式 D.5.2.1 增量方式:一般情况下以增量方式对汇聚数据进行更新。 D.5.2.2 全量方式:数据量较大的数据不宜以全量方式更新,例如数据量在100万条以上的。如有特殊原因需要全量更新的,根据具体情况另行商议。 DB11/T 19192021 14 参 考 文 献 1 GB/T 7027- 2002 信息分类和编码的基本原则与方法 2 GB/T 21062.1- 2007 政务信息资源交换体系 第1部分:总体框架 3 GB/T 21062.2- 2007 政务信息资源交换体系 第2部分:技术要求 4 GB/T 21062.3- 2007 政务信息资源交换体系 第3部分:数据接口规范 5 GB/T 21062.4- 2007 政务信息资源交换体系 第4部分:技术管理要求 6 GB/T 38664.1- 2020 信息技术 大数据 政务数据开放共享 第1部分:总则 7 GB/T 38664.2- 2020 信息技术 大数据 政务数据开放共享 第2部分:基本要求 _

展开阅读全文
相似文档                                   自信AI助手自信AI助手
猜你喜欢                                   自信AI导航自信AI导航
搜索标签

当前位置:首页 > 通信科技 > 数据库/数据算法

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        获赠5币

©2010-2024 宁波自信网络信息技术有限公司  版权所有

客服电话:4008-655-100  投诉/维权电话:4009-655-100

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :gzh.png    weibo.png    LOFTER.png 

客服