1、 ICS 35.240.20 L 70 DB36 江西省 地方标准 DB36/T 983 2017 公共信用信息平台建设 技术 规范 Technical Standard for construction of Public Credit Information Platform 2017 - 12 - 29 发布 2018 - 03 - 01 实施 江西省质量技术监督管理局 发布 DB36/T 983 2017 I 目 次 前言 . I 引 言 . III 1 范围 . 1 2 规范性引用文件 . 1 3 术语和定义 . 1 4 建设原则和目标 . 2 5 建设内容 . 3 6 建设模式 .
2、 3 7 信用数据处理模式 . 3 8 信用信息目录编制和数据归集基本要求 . 4 9 内部平台技术框架 . 4 10 功能要求 . 5 11 性能要求 . 7 12 安全性要求 . 7 13 应用系统接口 . 8 14 公共信用信息 . 8 15 信用数据处理模式 . 10 附录 A （资料性附录） 应用系统接口 . 16 DB36/T 983 2017 II 前 言 本标准按照 GB/T 1.1-2009 标准化工作导则 第一部分：标准的结构和编写 的 规定编写 。 本标准由江西省发展和改革委员会提出并归口。 本标准主要起草单位：江西省信息中心。 本标准主要起草人 :金俊平、杜军龙、肖俊才
3、、胡坚勇、薛婧，万昕、游旻晗、宋金庄、徐立雄、 陶明、郑自、占晓华。 DB36/T 983 2017 III 引 言 随着 社会信用体系建设 的不断 推进 ， 统筹 建设全省公共信用信息平台的任务迫在眉睫，鉴于全国目 前尚 未无 统一的公共信用信息平台建设 标准 ，为了规范和统一公共信用信息平台建设工作 ，依据社会 信用体系建设规划纲要（ 2014-2020年 ） 国发 2014 21号 、 江西省社会信用体系建设规划（ 2014-2020 年 ） 赣府发 2014 47号 文件精神和 GB 1.1-2009标准化工作导则 第一部分：标准的结构和编写规 则， 特制定本标准。 DB36/T 98
4、3 2017 1 公共信用信息平台建设 技术 规范 1 范围 本标准规定了 公共信用信息平台建设的术语和定义、建设原则和目标、建设内容、建设模式、信用 数据处理模式、信用信息目录编制和数据归集基 本要求、技术框架、功能要求、性能要求、安全性要求 和应用系统接口的要求。 本标准适用于江西省公共信用信息平台的建设活动。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 GB/T 22117 信用基本术语 3 术语和定义 GB/T 22117规定的 及下列 术语和定义适
5、用于本文件。 3.1 信用 credit 建 立在信任基础上，不用立即付款或担保就可获得资金、物资或服务的能力。这种能力以在约定期 限内偿还的承诺为条件。 注：广义的信用指诚信原则在社会上的广泛应用。 GB/T 22117，定义 2.1.1 3.2 信用信息 credit information 反映或描述信用主体信用状况的相关数据和资料等，主要包括政府（包括事业单位）信用信息、企 业信用信息、社会组织和个人信用信息。 GB/T 22117，定义 4.9 3.3 公共信用信息 Public credit information 公共信用信息是指各行政、司法机关以及依法、依规行使管理公共事务职能
6、的组织在履行职责过程 中形成的反映信用主体信用状况的数据和资料。 3.4 信用信息分类 credit information classification DB36/T 983 2017 2 把具有某种共同属性或特征的信息归并在一起 ，把具有不同属性或特征的信息区别开来的过程。 3.5 公共信用信息平台 public credit information platform 公共信用信息平台是支撑社会信用体系建设的信息化系统，通过 归集、存储 社会 法人和自然人的信 用信息，实现数据跨部门、跨行业、跨地区的交换和共享，提升政府服务和监管能力，通过推广信用信 息在各部门和重点领域的应用，全面推动社
7、会信用体系建设。 3.6 信用网站 Credit website 信用网站是政府在互联网上褒扬诚信、惩戒失信的窗口，主要面向社会，为各类信用主体提供信用 信息服务。信用网站要紧紧围绕信用信息的征集、整合、应用和监管，按照相关标准规范，征集和整合 有关行业和部门记录的社会成员信用信息。 3.7 信用信息基础数据库 credit information base database 信用信息基础数据库是公共信用信息平台的重要基础设施，信用信息基础数据库分为法人信用信息 基础数据库和自然人信用信息基础数据库，该数据库是归集、整理、保存法人和自然人的公共信用信息。 3.8 信用数据处理 credit d
8、ata processing 对公共信用信息数据进行归集、处理、存储、使用。 4 建设原则 和目标 4.1 建设原则 4.1.1 适用性 公共信用信息平台建设应适合工作实际和业务需求，具有实用价值。 4.1.2 开放性 公共信用信息平台建设应保持适度开放，具有兼容性和可扩展性。 4.1.3 安全性 公共信用信息平台建设应 把安全放到首位，既 要 考虑信用信息资源的共享，也要考虑信用信息 资源 的保护和隔离，利用各种安全手段增强信用平台的安全，同时对敏感信用信息进行特殊处理和保护。 4.2 建设目标 按照统一标准规范，充分利用云计算、大数据等先进技术，依托全省电子政务外网和电子政务云平 台，建设
9、省市两级公共信用信息平台及信用网站，通过各级政府部门数据交换、数据自主报送、第三方 系统对接等多种渠道进行信用信息的征集、处理和共享，为实施公共管理以及联合奖惩提供信用信息支 持，向社会提供信用信息服务。 DB36/T 983 2017 3 5 建设内容 5.1 内部平台 内部平台部署在政务外网内部应用区 ，供各部门使用，为各部门交换共享、查询应用信用信息、开 展联合奖惩提供支撑，并实现省市内部平台互联互通、信用信息交换。 5.2 信用网站 信用网站部署在互联网应用区，为公众提供信用政策法规宣传、信用建设动态、信用信息查询、异 议投诉受理等服务，为政府机关、 事业单位 、社会组织 、企业 和个
10、人推动、参与、了解信用体系建设提 供互动服务。 5.3 信用信息基础数据库 信用信息基础数据库建设即依托统一 社会信用代码，建立 社会法人 和自然人 两类 信用主体的信用信 息基础数据库。 5.4 平台建设相关其他内容 平台建设相关其 他内容包括以下几个方面： a) 完善各设区市电子政务云平台； b) 完善全省电子政务共享数据统一交换平台，依托该 该 平台进行省市数据交换、市级平台与市级 部门业务系统数据交换； c) 编制信用信息目录，规范信用信息归集 ； d) 建设安全防护 ， 敏感信息处理 、 身份认证管理 、 信用 权限管理 等技术手段 。 6 建设模式 全省公共信用信息平台按照省市两级
11、部署，省市县三级服务的模式建设 ： a) 省级平台由省级建设和管理； b) 市级平台由各设区市 建设和管理，覆盖设区市各部门及所辖县市区，并面向市县两级提供信 用 服务； c) 市级平台建设应参照省级平台的技术参数、数据标准、通用模块、交换接口等标准，按照江西 省公共信用信息平台建设 规范研究 、 开发各项应用功能，并实现与省级平台的数据对接； d) 县级原则上不建实体公共信用信息平台，各县（含省直管县）使用市级平台。 7 信用数据处理模式 a) 信用数据处理采用省级统一处理、省市储存的方式； b) “省级统一处理”即全省所有数据由省级统一处理（清洗比对）并整合形成全省统一的信用信 息基础数据
12、库，并按属地原则将各市信用信息通过全省电子政务共享数据统一交换平台返还给 各设区市，各设区市根据自身需要，对基础 信用信息进行进一步加工处理； c) “省市储存”指省市两级分别存储信用信息，省级存储全省所有信用信息，市级分别存储各市 信用信息。 DB36/T 983 2017 4 8 信用信息目录编制和数据归集基本要求 8.1 信用信息目录编制基本要求 按照省级信用信息目录编制要求，编制市级、县级信用信息目录，市级、县级信用信息目录在省级 信用信息目录编制要求的基础上，可根据自身情况，进行特色扩展。 8.2 信用信息数据归集基本要求 省市县按照职责和实际情况分别进行信用信息归集工作，省级负责归
13、集省直部门（单位）信用信息， 市级负责归集市直部门（单位）信用信息，县级负责归集县直部门及县级 以下单位信用信息。 9 内部平台 技术框架 9.1 内部平台 技术构架 内部 平台 技术架构采用 SOA面向服务的体系架构， 这种 体系架构是一个组件模型，它将应用程序的 不同功能单元通过这些服务之间定义好的接口和契约联系起来 ， 使 不同的业务服务可以相互交换数据， 参与业务流程，通过灵活的互相协作方式来完成具体的业务操作。这些业务服务独立于编程语言，独立 于实现方法，独立于运行环境 ， 具体 技术架构如图 1所示： 图 1 内部 平台技术构架 9.2 内部平台 技术实现 9.2.1 基于 J2E
14、E 平台 的三层分布式应用体系架构 采用 J2EE的 B/S/S三层结构体系结构，以零客户端维护、可扩展性强、跨平台作为最突出的特色。 9.2.2 基于统一应用平台进行应用系统的构建 DB36/T 983 2017 5 通过统一应用平台实现相应的公共服务功能，如统计报表定制工具、异常处理、日志管理、系统配 置管理等系统维护管理工具，以及用户 /组织机构管理、权限管理、认证管理、 CA接口等应用 服务。 9.2.3 基于 统一身份认证 的 安全 访问 通过 平台 门户对前台客户端进行整合，并实现用户的“单点登录（ SSO）”功能。用户通过认证以 后，实现对业务系统的访问；根据用户权限的不同实现内
15、容管理、个性 化管理、访问控制的功能、渠道 管理、客户端管理、并发访问控制等功能。 9.2.4 XML 数据交换标准 采用 XML格式作为数据流和数据模型标准，基于 XML标准描述业务数据和 XML的数据内容与数据显示 形式完全分离特性，具有较强的灵活性和平台无关性，并适用于异构数据库之间的信用数据交换。通过 XML有效保证平台对各种异构系统的信用数据接口需要。 10 功能要求 10.1 内部平台功能要求 10.1.1 信用数据分类管理功能 信用数据要进行分类管理，按照主体类别、数据类型、使用范围等不同方面进行管理。 1）信用主体目前包括政府部门（事业单位）、企业、社会组织和个人四大类，对每类
16、信用主体标 识、信用数据公开访问、是否要进行脱敏加密处理等进行分类； 2）按照信用数据类型分为基础数据和信用数据，其中基础数据为主体登记部门提供的主体登记数 据，即工商部门提供的企业注册登记信 息、公安部门提供的人口基础信息、机构编制部门提供的事业单 位登记信息及民政部门提供的社会组织登记信息 ； 信用数据则是标明主体信用状况的数据资料。基础数 据是平台整合数据的根本，而且个人基础数据是敏感类数据，更需严格管理； 3）按照数据使用范围分为三类：社会公开、政务共享和授权使用。社会公开即对所有人开放；政 务共享对所有政府部门公开；授权使用则需要信用信息源产生部门进行授权才能使用 。 10.1.2
17、信用数据处理功能 信用数据处理是平台的基础功能，在 信用信息 归集 的基础上通过对数据清洗、比对、组合、抽取等 过程整合 、 优化信用数据， 为应用提供支撑，主要包括： 1）信用数据清洗比对，对归集的数据进行处理，并与平台已有的数据进行比对，将格式不对、明 显错误、重复数据进行标识 ； 2）信用数据关联，将清洗比对后的信用数据入库，与信用主体关联、分类、设定使用权限等； 3）信用数据抽取，根据业务需要，将信用信息按地域、行业、领域或应用模式等自动抽取数据组 合成各类主题库； 4）错误信用数据处理，按照“谁提供，谁负责”的原则，将错误数据返回给各部门处理； 5)对各类信用数据形成统一的标识。 1
18、0.1.3 信用数据交换共享功能 信用数据交换共享是信 用信息归集交换的基础功能，依托全省电子政务共享数据统一交换平台实现 纵向和横向数据交换，包括： 1）向省级平台报送信用数据； DB36/T 983 2017 6 2）从省级平台获取本市信用数据； 3）实现市级部门之间的信用数据归集和交换； 4）实现县级信用数据的归集和交换。 10.1.4 信息查询功能 信用信息查询是应用的基础， 应提供多种查询方式： 1）提供单个指标集信用数据查询； 2）按信用主体查询所有相关信用信息； 3）提供信用数据接口（ Web Service）方式供各部门查询； 4）信用数据综合查询。 10.1.5 联合奖惩功能
19、 通过平台记录和展示各部门企业信用行为对企业进行联合奖惩，包括： 1）通过平台查询企业信用信息，再进行联合奖惩； 2）通过与部门业务系统对接，通过 Web Service的方式提供查询，并通过接口方式获取部门对企业 的奖惩信息； 3）展示联合奖惩信息； 4）对奖惩信用信息进行统计分析。 10.1.6 信用服务功能 信用服务至少包括以 下功能： 1）异议申诉管理。主要用于信用主体异议申诉的申请、受理、处理和信息反馈 ，是信用主体和政 府部门沟通的窗口 。 信用主体 对 公示的 信用 信息存在异议时 ，支持社会公众通过信用网站的异议申诉窗 口提交异议申诉，按照“谁提供，谁处理”的原则将受理的异议申
20、诉信息转交 给数据提供 单位进行判断 处理，做好信用数据把关工作，确保信用数据的准确和完整，异议申诉办理结束后将反馈结果转发给信 用网站提供社会公众查询； 2）批量审查服务。主要是为有企业主体审查需求的部门提供审查失信信息 查询与生成报告； 3）统计分析服务。根据各级不同需求实现统计分析报表与图表。如区域法人信用状况统计、行业 法人信用状况统计、区域法人信用预警、行业法人信用预警等。 10.1.7 权限设置功能 公共信用信息平台由很多的功能模块组成，即使对合法用户，也不能操作所有的模块，而是根据用 户的工作部门、工作性质授予相应的功能，对同样的信用数据可以设置不同的操作权限 ， 满足不同的管
21、理模式和管理规范的权限管理的要求。 10.2 信 用 网站功能要求 10.2.1 宣传功能 实现信用动态发布功能，发布全国、全省、设区市（含所辖县市区）社会信用体系建设动态新闻； 发布全国、全省、设区市（含所辖县市区）信用相关政策和法律法规；发布全国、全省、设区市（含所 辖县区）信用建设标准规范、信用研究学术文章、具有设区市（含所辖县市区）特色的企业和公众诚实 守信案例或守信承诺图文等。 10.2.2 公示功能 DB36/T 983 2017 7 实现守信信息、失信信息公示功能，通过信用公示栏目依法公示设区市（含所辖县区）企业及个人 各类守信行 为、守信获奖和荣誉、诚实守信“红名单”或失信行为
22、、不良信用记录和失信“黑名单”； 实现信用双公示及信用代码公示功能，按照国家要求对行政许可和行政处罚结果信息在 7天内对公众进 行公示，并及时对新赋信用代码和旧码转换结果进行公示。 10.2.3 查询功能 实现信用信息查询功能，根据 数据提供单位 的授权， 按照政府机关 、事业单位、社会组织、 企业、 重点人群等不同主体，为公众提供各类主体信用信息查询服务，查询结果可按照查询主体的基础信息（包 括登记注册备案、资质认证许可等信息）、守信信息、失信信息、其 他信息分类展示，方便公众查看。 10.2.4 互动功能 实现信用问答功能，公众可针对信用知识、信用资讯、信用投诉等内容进行提问；实现常用下载
23、和 意见反馈功能，对信用相关政策文件、研究文章等提供下载，及实现公众对信用网站意见和建议反馈的 收集功能。 11 性能要求 11.1 网络性能 要求数据传输网络畅通、快捷、安全、可扩展，满足 省市 县三级网络互联互通。 11.2 设备性能 要求支持通用性好的计算机系统、安全可靠的操作系统以及大型数据库系统，保证系统良好的性能。 11.3 查询性能 要求信用信息查询时限在 5 秒内返回查询结果，同时保障 web服务器 性能 正常 。 11.4 统计 分析性能 应满足用户的要求，稳定、可靠、实用，人机界面友好，输入、输出方便，图表生成灵活美观。 11.5 数据质量 性能 信用数据应完整、准确和及时
24、。 12 安全性要求 12.1 网络安全 网络安全主要考虑局域网安全、广域网安全、政务云平台安全、应用系统部署安全、信用数据安全、 操作系统安全、防病毒、防攻击等，主要通过访问控制、防病毒系统、防火墙系统、防止非法入侵、安 全防护系统、安全审计系统、安全监测应急响应与处理等，并对网络通信进行有效的监控，对已知的潜 在威胁进行有效的防范，保障网络的正常工作。 12.2 应用系统安全 DB36/T 983 2017 8 应用系统安全是信用信息系统中最关键的部分，所有的业务办理、事项处理都需要通过应用系统来 实现。应用系统安全对整个系统正常运行起着极其关键的作用。 12.2.1 身份认证 应用身份认
25、证应具有以下功能： 1）提供专用的登录控制模块对登录用户进行身份标识和鉴别； 2）对同一用户采用两种或两种以上 组合的鉴别技术实现用户身份鉴别； 3）提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不 重复用户身份标识 、 身 份鉴别信息不易被冒用 。 12.2.2 多级权限控制 安全评估公共信用信息平台 的功能模块组成，即使对合法用户，也不能操作所有的模块，而是根据 用户的工作部门、工作性质授予相应的功能模块；对同样的数据 可以设置不同的操作权限：查询权限、 录入权限、审核权限、审批权限 等 。 12.2.3 应用系统访 问 要对数据资源访问规定不同的访问等级，不同用户只可访问经
26、过授权的信用数据资源。加强对数据 资源访问的安全审计。 12.2.4 安全评估 定期根据应用系统的使用情况，进行有计划的应用系统安全评估，评估包括应用系统自身安全评估、 业务流程安全评估、应用交换安全评估、应用使用安全评估等。 其中， 内部平台要符合国家等保三级要 求，信用网站要符合国家等保二级要求。 12.2.5 信用数据安全 1）主要包括信用数据分权限、分职能进行管理，对敏感数据进行加密处理等； 2）内部平 台与信用网站的数据，应分开存储和处理，内部平台的数据必须存储在政务网的内部应 用区； 3）在敏感信用数据传输过程中采用加密手段，利用国家批准使用的密码算法对数据加密，保证数 据安全，一
27、般信用信息采用政务邮箱进行传输。 12.3 制度安全 制定必要的安全管理制度和措施，如平台运行维护制度、信用数据定期备份制度、 信息安全等级保 护制度、 各种紧急情况的应急措施等。 13 应用系统接口 应用系统接口详见附录 A。 14 公共信用信息 14.1 公共信用信息分类 DB36/T 983 2017 9 14.1.1 基础信息 基础信息是指信用主体（涵盖 社会 法人、自然人）的身份登记信息，主要是工商、质检、民政、 税 务、编办及公安部门提供的 社会 法人和自然人的身份登记信息，其主要内容包括： 1）登记 /注册 /备案信息； 2）资质信息； 3）行政许可。 14.1.2 守信信息 守
28、信信息是指 行业主管部门依照法定条件和程序对 信用主体 做出的行政表彰和荣誉类信息，其主要 内容包括但不限于以下内容： 1）企业或个人受到行业主管部门或 政府部门的 表彰信息； 2）红榜信息。 14.1.3 失信信息 失信信息是指是行业主管部门根据行政职能与法定权限对 信用主体 做出的处罚信息，其主要内容包 括但不限于以下内容： 1） 行政处罚信息； 2）行政强制信息； 3）未履行法定义务、违约信息； 4）黑榜信息。 14.1.4 其他信息 其他信息主要是指除以上三种以外的信用信息。 14.2 公共信用信息数据项 14.2.1 基础信息数据项 e) 登记 /注册 /备案信息：法定名称、代码类型
29、（统一社会信用代码或工商注册号、组织机构代码、 税务登记证）、企业（单位）类型、法定代表人、注册资本、成立日期、注册地址、有效起始 日期、有效终止日期、经营范围、登记机关、高管人员信息等内容； f) 资质信息：法定名称、代码类型、资质等级名称、资质证书号、有效起始日期、有效到期日期、 证书状态、资质证书核发日 期、资质证书核发机关等内容； g) 行政许可 信息 ：行政许可决定书文号、项目名称、审批类别、许可内容、行政相对人名称、行 政相对人身份证号、行政相对人统一社会信用代码 (组织机构代码、税务登记证、工商注册号 )、 法定代表人姓名、许可决定日期、许可截止期、许可机关、当前状态、地方编码、
30、数据更新时 间戳、备注。 14.2.2 守信信息数据项 1) 表彰类：法定名称、代码类型、荣誉内容、荣誉授予日期、授予机构等内容； 2) 红榜类：法定名称、代码类型、红榜内容、红榜发布日期、发布机构等内容。 14.2.3 失信信息数据项 DB36/T 983 2017 10 1） 行政处罚类 : 行政处罚决定书 文号、处罚名称、处罚类别 1、处罚类别 2、处罚事由、处罚依据、 行政相对人名称、行政相对人身份证号码、行政相对人统一社会信用代码 (组织机构代码、税务登记证、 工商注册号 )、法定代表人名称、处罚结果、处罚决定日期、处罚机关、当前状态、地方编码、数据更 新时间戳、备注； 2） 行政强
31、制类 : 法定名称、代码类型、行政强制信息内容、决定日期、决定机关等内容； 3） 未履行法定义务、违约类 : 法定名称、代码类型、欠薪 /欠费 /欠税 /欠贷信息内容、披露机关 等内容； 4） 黑榜类：法定名称、代码类型、黑榜内容、发布日期、发布机构等 内容。 关键数据项说明 1) 法定名称：指法人、其他组织和个体工商户等在登记、注册、备案机关记载的名称，不包括名 称的简称或缩减写法； 2） 代码类型：指行政管理机关在管理相关行政业务事项中，依法赋予法人、其他组织和个体工商 户等与其名称唯一对应的代码，包括组织机构代码、工商营业执照注册号、税务登记证号或统一社会信 用代码等；自然人对应的是公民
32、身份证号码。 15 信用数据处理模式 15.1 归集 15.1.1 基本要求 a) 信用信息归集机构应事先公开信息归集的对象、方式、内容和流程； b) 信用信息归集机构应记录归集对象、归集时间、归集方式、归集人员等 信息； c) 信用信息归集机构应建立完善的归集管理制度，制定人员要求管理、归集操作程序规范； d) 信用信息归集机构不应以法律限制的不正当手段归集信用信息； e) 信用信息归集机构应有义务保证信息的真实性。 15.1.2 范围与来源 信用信息的来源包括但不限于以下几个方面： a) 信用信息主体； b) 第三方中介 机构 ； c) 与信用信息主体利益相关的机构； d) 相关的政府部门
33、； e) 媒体、媒介； f) 其他拥有信用信息主体信息的机构和个人。 15.2 处理 15.2.1 信用信息处理流程图 信用信息处理是为了保 证数据的统一性、完整性、准确性，信用信息处理流程 见下图 2。 DB36/T 983 2017 11 图 2 数据处理流程图 15.2.2 信用信息目录判定 实现信用信息目录与信用信息的“以一对一”对应 规则 。具体方法：将 数据提供单位提供 的信息， 与平台已存在的信用信息目录进行比对，对于信用信息目录不存在的信息，应先创建该信息对应的信用 信息目录。对于信用信息目录已存在的，直接进入信息转换流程操作。 15.2.3 信用信息目录规则设定 信用信息目录
34、设置时，必须针对数据处理设定相关规则规范，设定的规则包括信用信息目录指标项 数据转换规则、信用信息目录指标项数据清洗规则、信用信 息目录指标项基础数据规则、信用信息目录 指标项基准数据规则、信用信息目录指标项数据校核规则、信用信息目录指标项数据关联规则。 15.2.4 信用数据转换 DB36/T 983 2017 12 通过信用信息目录指标项审核的数据，首先根据信用信息目录指标项数据转换规则对数据进行转 换，包括格式转换、数据拆分、数据合并等处理工作。数据转换的规则包括： 1）将全角数据转换为半角数据； 2）将日期时间格式转换为目录指标项规定的日期时间格式； 3) 将繁体字符转换为简体字符；
35、4) 将 2进制 、 8进制 或 16进制转换为 10进制； 5) 根据数据字典代码将代码数据转换为正常数据。 15.2.5 信用数据清洗 数据清洗的主要任务是根据信用信息目录 清洗规则将 对 数据进行准确性、完整性、一致性、唯一性、 实时性、有效性的检验，过滤不符合规则要求的数据 ， 数据清洗规则主要包括： 1）重复信用数据检验。数据库中属性值相同的记录被认定是重复数据，通过判断记录 的属性值是 否相等来检测记录是否相等，相等的数据合并为一条数据（合并 /清除），非重复数据进入下一步数据 处理 环节； 2）缺失信用数据检验。对于信用信息目录要求必填项目进行检验，对检查中数据项缺失的数据， 直
36、接反馈给 数据提供 单位，经 确认后重新提交； 3）不一致数据检验。以代码提供的信用数据，需要根据数据字典表进行比对，发现数据的不一致 或者数据字典不存在的数据，直接反馈给 数据提供 单位，经确认后重新提交。 15.2.6 信用数据叠加 数据叠加分为基础数据叠加和非基础数据叠加两类 ， 具体规范如下： 1）基础信用数据叠加。 是 指在办理业务或信息归集时，首次获取某个信用主体的基础信息，数据 直接添加到基础数据库 。 2）非基础数据叠加。 是指 信用基础数据发生变更后，非基础数据中涉及的基础数据字段应随之变 更， 便于 数据的关联。 15.2.7 信用数据校核 数据校核是根据信用信息目录指标项
37、数据校核规则，以法定授权部 门提供的数据为基准，将不同部 门提供的同一指标的数据进行校对核验，以求形成合格、准确的信用数据 ， 数据校核分为基础数据校核 和非基础数据校核两种。 1）基础数据校核即身份核 实，以法定授权部门提供的身份信息为基准数据，校对来自其他部门的 身份数据，重点指标是统一社会信用代码、工商注册登记号、 税务登记证 号 、 组织机构代码、公民身份 证号码等； 2）非基础数据校核是以法定授权部门的数据对多部门非基础数据比对，核实信息准确性，以自然 人信息为例，具体包括出生校核、死亡校核、婚姻状况校核等。 数据校核业务流程如下图所示： DB36/T 983 2017 13 数据接
38、收 数据校核 改数据是否能够 准确取值 ？ 共建单位核实 结果反馈 Y N 信用数据库 图 3 数据校核流程 15.2.8 信用数据关联 数据关联是指将不同部门提供的同一信用主体 的信用数据进行关联，根据信 用信息目录指标项数据 关联规则实现对 信用主体的信用状况进行综合性的描述。 信用数据关联遵循以公民身份证为基础的公民 统一社会 信用 代码，以统一社会信用代码为基础的 社会 法人信用代码，辅助工商注册号、企业名称、法 DB36/T 983 2017 14 定代表人、注册地址、籍贯姓名等其他属性为标识信息，进行数据关联比对处理，并赋予其统一内部代 码标识，生成完整、准确、动态的信用档案信息。
39、 15.2.9 二义数据处理 信用数据转换、信用数据清洗、信用数据校核、信用数据关联等数据处理过程中，会产生各种按照 规则不能处理的、不符合条件的数据 ，对于这些数据，基于“谁提供、谁负责”的原则，应采取“不丢 弃、不修改、不入库”的原则，将每个环节碰到的疑问数据返回给 数据提供 单位，并可追溯。数据提供 方接收到疑问数据集后，可进行修正，并作为更新数据再次上报。 15.3 存储 信用 数据经过标准化数据处理流程，最终形成信用 信息基础 数据库，为信用数据应用提供全面、准 确、及时的信息支撑。 15.4 使用 15.4.1 更新范围 信用数据的更新范围涵盖信用信息目录所包涵的所有联席成员单位目
40、录项数据以及社会信用主体 所报送的 信用信息。 15.4.2 更新周期 按照信用信息目录所规定，信用信息的更新周期分为年报、季报、月报、周报、日报、实时。各成 员单位按照信用信息目录所规定数据报送周期向公共信用平台报送相关信用数据。 15.4.3 更新方式 对于信用数据更新方式，主要有全量更新和增量更新两种。对于首次报送信用平台的数据，要求采 用全量更新的方式，一次性报送所有历史数据。对于日常更新的数据，主要采用增量更新方式，按照数 据时间戳分批次报送新数据到信用平台。 15.4.3.1 全量更新 全量更新是指整个数据集的整体更新，一般采用直接覆盖目标数据集的方式。全量更新数据处理是 采 用抽
41、取方法直接处理，通过 ETL工具，直接抽取数据覆盖到目标数据集。 15.4.3.2 增量更新 增量更新是指在进行更新操作时，只更新需要改变的地方，不需要更新或者已经更新过的信用数据 不要重复报送。增量更新数据处理是抽取自上次抽取以来数据库中要抽取的表中新增、修改、删除的数 据。 一般增量数据抽取方法有以下两种： 1）触发器：在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除三个触发器，每当 源表中的数据发生变化，就被相应的触发器将变化的数据写入一个 临时表 ，抽取线程从临时表中抽取数 据。触发器方式的优点是数据抽取的性能较高，缺点是要求在业务数据库中建立触发器，对业务系统有 一定的性能
42、影响； 2）时间戳 ： 它是一种基于递增数据比较的增量数据捕获方式，在源表上增加一个时间戳字段，更 新修改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间戳字段 的值来决定抽取哪些数据。 DB36/T 983 2017 15 15.4.4 异议数据处理 信用主体 对公共信用信息 平台披露的信用信息存在异议时，可通过信用网站或 内部 平台提出异议申 请，根据异议审核情况采取冻结措施，暂时冻结数据并向 数据提供单位 转发异议协查请求。 数据提供 单 位对异议数据进行处理，处理完成后结果反馈到公共信用信息平台，公共信用信息平台根据处理结果解 冻信用信息，并将处理结果反馈
43、给异议申请人 。异议数据处理流程详见下图 4： 图 4 异议数据处理 DB36/T 983 2017 16 附 录 A （资料性附录） 应用系统接口 A.1 接口构架 接口架构采用 XML Web Service，使用 Web Service进行数据通信。 A.1.1 信用数据重用 重用代码功能，重用代码后的信用数据，使用 Web Service，通过直接调用远端的 Web Service实现。 A.2 服务接口说明 A.2.1 Web Service地址 信用数据共享的 WebService的地址为： http:/:/ /dataservice/services/soap/externald
44、ataservice?wsdl A.2.2 调用举例 以下以 java都要用天气预报为例，了解调用 WebService的步骤 try / 使用 RPC方式调用 WebService RPCServiceClient serviceClient = new RPCServiceClient(); Options options = serviceClient.getOptions(); / 指定调用 WebService的 URL EndpointReference targetEPR = new EndpointReference( / 不设或者设错了 Action，抛出 org.apache.axis2.AxisFault: 服务器未能识别 HTTP 头 options.setTo(targetEPR); QName qname; /* / SOAPAction 的值 options.setAction(http:/WebX / 这个参数告诉 调用接口的完整 url / 第一个参数为接口的 namespace
