XX学院数据治理服务+IDS平台建设与对接项目需求说明.docx

《XX学院数据治理服务+IDS平台建设与对接项目需求说明.docx》由会员分享，可在线阅读，更多相关《XX学院数据治理服务+IDS平台建设与对接项目需求说明.docx（39页珍藏版）》请在三一办公上搜索。

1、XX学院数据治理服务+IDS平台建设与对接项目需求说明1.建设目标1.1数据治理建设目标本次项目将围绕“数据治理驱动校务增效”的思路探索学校下一步的信息化建设,构建学校数据治理体系，设计配套数据管理组织结构、制定数据治理流程、对日常校务工作相关数据进行梳理、采集、清洗、标准化规范存储及应用、对相关数据资产进行可视化的全生命周期管理，并提供包括数据质量检测、跟踪处理、数据质量分析报告在内的数据质量全程管理服务，最终对外提供丰富的数据服务,支撑学校未来各类数据消费场景应用，如面向师生的最多跑一次流程服务与数据填表服务、面向业务部门的各类业务主题分析、面向学校决策部门的数据分析驾驶舱等。具体目标细化

2、为：(1)完成学校的信息标准建设，为校务工作数据资产化提供基准。(2)对学校校务工作相关数据资源情况进行全面盘点，然后根据学校实际情况，制定多样化数据采集的实施方案并落地执行。首先把学校具备采集条件的相关数据尽量的采集进资产库，并在这个过程中完成校务工作相关数据资产内容的对标、采集、转换(初步清洗)或特定编码工作。(3)在已建成数据资产的基础上，针对具体的应用数据、消费数据的场景，分析数据的内部质量的不足，形成由场景驱动的数据质量要求，进一步进行具体数据质量的检测和问题处理。(4)实现在办理业务填写相关表格时“一次录入、共享互通、重复使用、自动填充”的目标，最终实现师生一年只填“一张表”。(5

3、)为实现上述目标，所需要配套的管理机制和组织结构建设。1.2.身份认证平台建设目标完成对学校各类业务系统的进行身份对接，实现单点登录、用户管理、认证授权、认证审计等一系列问题。同时面向师生提供完善的自助服务，让用户可以便捷管理个人身份信息。对于本次新建的身份互联平台要求体现高校电子身份管理的特色，对于师生日常帐号的管理要充分考虑高校的特点与实际。对于本次新建的身份互联平台要求具体较高的安全性，在日常使用过程中，要求在帐号发放、帐号生命周期管理、敏感系统访问等使用场景下充分考虑相应的安全设计，以及对于系统出现恶意登录，非法登录、异常会话的情况，也应该具备相应的安全管理能力，确保系统使用安全。对于

4、本次新建的身份互联平台要求能够与时俱进，结合物联设备深化应用，比如通过利用相关设备的人脸识别、指纹识别功能，实现更安全、更便利的认证登录服务。2、总体要求2.1. 数据治理服务要求为了保障数据治理的有机、有序的开展，需要优化构建多层级的数据治理保障体系，包含数据管理组织、数据管理角色及职能、相应的管理制度及细则文档。投标人需要有充分的行业业务经验及能力，其为实现本项目所涉及的数据治理目标而配套提供的工具软件应具有完整自主知识产权，包括适应高校信息化行业业务特性的数据模型，例如适用于高校的主数据对象、代码标准、数据集市模型、业务数据模型等，具有完整的数据标准建设、数据集成交换、数据质量管理、数据

5、开放使用的实施方法论。以便从技术功能、业务经验、实施措施几方面保障学校数据治理服务的实施成效。2.1.1, 供多样的数据采集方案结合高校行业经验，赋能学校数据中心1）扩展可视化的数据集成工具，提供数据补采工具，丰富基础数据；2）基于多年的高校信息化建设经验打造行业集成库，提高集成效率并提升集成效果；3）提供在线可视化管理数据实施能力，促进数据资产建设成果提升。2.1.2, 可视化的高校数据资产管控中心，提升高校数据治理能力1）提供可视化数据资产管理中心，通过呈现全校整体宏观数据以及精细到单表的建设情况，让校方对学校数据资产建设做到“心中有数&2）提供对主数据流向的精细化管理功能，通过数据血缘关

6、系跟踪相关数据的“来龙去脉”，数据实施人员可以快速发现问题、解决问题；3）通过数据仓库提供的历史数据切片管理，支持数据实施人员查询主数据变化历史，了解主数据的“今生前世”，还可方便的追溯、排查数据问题。2.1.3, 强化全校各部门数据建设联动机制，形成数据资产建设合力1）引入权威数据责任单位管理，主数据的每个对象都对应唯一的权威责任单位，将数据责任落实到各责任单位；2）结合“数据资产建设、集成运行、资产开放、质量检测”等多方面数据，面向学校及各部门提供数据报告展现该部门的数据资产情况，促进各部门参与数据中心建设；3）各部门可管理所属部门的开放数据，根据数据申请方的实际情况选择是否共享相关数据，

7、提升部门数据管理的责任感和参与感。2.1.4, 打造数据质量管理规范体系建设，支撑数据治理工作逻辑闭环1）优化数据质量检测工具，并支持将单表的检测结果通过邮件的方式推送给源头业务人员，支持和学校门户平台等消息方式（并支持阿里云短信、微信企业号、WeLink公众号、站内信等多种方式）实现对接，推动数据质量提升；2）提供可视化的数据质量管理中心，以直观透明的方式呈现当前数据质量的情况，并展示数据质量提升的历史情况；3）提供直观的质量检测报告，所见即所得的反映问题所在及动态。既可以反映当前现状，也可以追溯历史，反映历史问题的处理情况；4）提供一个在线的数据质量反馈通道，普通师生在数据使用情况中发现数

8、据问题，可在线进行反馈，数据管理员可集中排查处理。2.1 5、促进学校数据资产产生数据价值，打通数据应用的最后一公里1）预置数据业务模型、数据集市模型，让建设的数据资产更具针对性，可以直接用于实际消费场景，如一网通办流程服务，数据决策分析；2）提供完善的APl接口管理，通过数据资产管理目录将对外开放，让数据使用方可以便捷的查询数据、订阅数据、申请数据、使用数据，从而让数据不断被使用，被消费。2.1.6.相同的数据使用于不同消费场景，通过不断的使用提升数据质量1）权威数据源数据和填报系统采集的数据共同形成学校的可共享数据，通过数据开放接口供给服务于年度考核、职称评审、科研上报等整个师生生命周期管

9、理；2）通过数据消费场景不断牵引数据的质量提升和数据校验，提高教职工对数据质量和填报的重视度。2.2 、身份认证平台要求2.2.1、 统一身份认证必须满足XX学院智裁校园建设的需要，对用户的信息进行集中管理；2.2.2、 统一身份认证所使用的记录仅需保存用户账号和加密后的密码，且后台结构化数据中的记录相一致；2.2.3、 用户信息加密传输，用户登录等敏感信息需要加密存储；2.2.4、 实现一人多号的身份切换机制，可以给一个人指定其中一个账号为默认账号；2.2.5、 必须提供QQ、微信、企业微信、钉钉、门户叩p、手机短信等各种身份认证接口标准，实现各类应用场景下的多种身份认证；2.2.6、 后台

10、管理功能具有批量操作功能,角色管理功能,应用展厅接入功能、应用和用户单独授权功能，方便的系统设置功能等；2.2.7、 PC端和移动端的界面需要完全能够根据学校的需要定制化；228、标准化多种常见协议，所有的对接均可通过配置管理。除现有系统的校内关键应用的标准化对接外，还需要标准化对接CARSLVPN,上网认证设备等，使用户不管在校内还是校外均能方便访问校园内关键应用资源，提高用户使用体验；除了对接协议标准化，对接文档也要标准化，包括存档文档和在线文档，对系统对接、接口开发和使用提供详尽的资料和丰富的样例。方便用户在不需要实施方介入的情况下快速对接；2.2.9、 有效的问题排查和使用监管的手段，

11、能够监管数据同步状态，监测接入方式，查询异常信息，审计各种异常，统计访问量等；2.2.10、 有完善的负载和备份机制，确保高并发场景下的正常使用和系统宕机后的迅速恢复；实现原有认证的迁移和停用，需要迁移原有统一身份认证的所有账号数据和所有应用对接数据，仅保留和保障一套身份认证运行。2.2.11、 支持用户多重身份属性的定义和存储，符合学校教工多重身份、多重职务的现状。支持分布式数据采集机制，符合学校数据源分散管理的特点。2212、身份数据的处理方式除了新生入学、新教师和新员工报到的身份创建，还包括学生离校、教师员工离职的身份状态变化的同步处理和权限模型的建立。为学校各类用户提供注册、变更、转化

12、、注销的全生命周期的身份数据管理方案。2.2.13、 系统具有良好的稳定性和易集成性。支持对不同开发平台、不同开发模式的应用系统的认证集成，提供多种成熟标准的认证接口，实现对网络层服务的集成，支持Unix、Linux、WindoWS等多种平台，实现完全跨平台部署。3、总体技术要求3.1 数据治理技术要求投标人为实现本项目所涉及的数据治理目标而配套提供的工具软件要求采用B/S结构，可运行于Unix、LinuxWindOWS等高安全性操作系统。开发技术应采用J2EE标准，组件技术及在数据交换上对多种类型的数据，包括各类关系型数据库、XML.大数据的支持，使系统功能最优化，同时将整体方案内部在技术上

13、的相互依赖性减至最低。具体要求如下：3.1.1、 必须采用B/S架构。支持Unix、Linux、Windows多种平台、支持IPv4IPv6网络环境，完全支持跨平台的部署，必须基于OraCIeUg或以上版本的大型数据库。3.1.2、 遵循J2EE的技术路线。采用Java编程语言和服务器端JaVa技术进行开发，采用面向对象的组件技术，利用这些组件顺利地建立分布式应用程序。3.1.3、 采用成熟的SC)A架构及设计理念，保证学校内部各业务系统集成和交互过程中异构技术架构和异构数据结构集成中的稳定性和可管理性。应用程序开发与运行结构要基于统一的技术开发平台的三层架构，即Web服务器、应用支撑服务器和

14、数据库服务器。3.1.4、 支持多种成熟的ETL中间件。能提供统一的可视化的开发工具，能图形化的设计和定义抽取、转换、加载流程，并保证数据集成交换的稳定性和安全性。3.1.5、 支持与主流关系型数据库进行对接，包括且不限于OraCle、MySQL、PostgreSQL、MicrosoftSQLServernIBMDB2UDB、IBMDB2400InformixSybaseASEnterpriseSybaseASAnywhere等。3.1.6、 支持与部分非主流关系型数据库进行对接，包括MiCrOSOftACCess、MicrosoftExcelDbaseVisualFoxpro03.1.7、

15、支持包括JMSTopicaJMSQueue、WebServicesTabled-TXt文件、XML文件、支持操作系统的网络协议，包括FTP。3.1.8、 数据集成支持基于HadOOP大数据技术框架的数据源，并能从中获取数据。3.1.9、 系统必须支持负载均衡，支持动态监测负载状况，自动对可用资源进行并发检测，调整和分配等功能。3.1.10、 除了IT通用的元数据管理、主数据管理、标准管理等功能外，应根据高校行业特性和专属特征，提供专门针对高校的元数据模型、业务领域模型、数据集市模型等，而非其他行业或IT通用方案。3.1.11、 投标人应具有独立开发完成、具有自主知识产品而非集成第三方开源软件的

16、工具软件、具备一定的成熟度。应支持基于现有平台的二次开发，包括但不限于依据学校使用情况进行的软件调整、优化、细化、深化。3.2 、身份平台技术要求321、标准化平台需基于J2EE标准的微服务技术架构。需采用基于LDAP标准的目录服务器存储身份数据，并提供身份认证。322、可集成性1）提供多种认证接口的异构支持，包括代理认证和LDAP目录服务接口。2）支持多种语言的接口方式，包括Nginx反向代理、Java、.Net、PHP,Python等。3）支持Unix、LinUX多种平台，完全支持跨平台的部署。4）全面支持IPv4IPv6网络环境。323、可扩展性1）要求身份、授权、认证功能相对独立，可以

17、灵活的与第三方产品对接。2）可实现用户名/口令认证模式,手机号绑定认证,支持动态口令认证接口。3）提供大并发访问下的高可用性，支持集群工作模式，具备多机热备和负载均衡的能力。324、高性能1）可为数百个应用提供统一身份认证服务的同时保证秒级的认证操作时间。2）对资源池连接数、滞后时间的调整（滞后时间是指在线用户多少时间不活动，此用户的资源连接就应该释放）。3）可为数百个应用提供统一身份认证服务的同时保证秒级的认证操作时间。4）系统需支持100OO用户并发进行登录操作时，平均响应时间不超过4.1秒。投标人需在投标文件中提供国家认可的第三方软件产品质量检验机构出具的检验检测报告复印件证明。3.2.

18、5、灵活性提供灵活的同步策略配置，支持通过工具将权威数据源中新建和变更的用户身份数据同步至校园身份互联平台。326、可管理性集中的身份数据管理，不仅提供用户帐号的维护，还能提供便捷的批量导入等功能。平台应提供历史事件的查询和认证会话的相关操作，建立完善的事后追溯机制。327、快速部署支持容器化的部署方式，从而能够在校内快速部署。3.2.8、双机热备系统实现双机热备部署，提高运行可靠性。4、安全性要求4.1、 认证授权：保证用户的合法性和用户使用应用信息资源的权力，避免内部敏感信息泄漏和服务所提供的信息资源被非法访问，造成严重的安全事件。4.2、 信息保密：充分利用密码技术，对于需要保密的信息，

19、采用密码技术进行加解密处理，防止信息的非授权泄漏，确保涉密信息在产生、存储、传递和处理过程中的保密。4.3、 数据完整性：建立数据完整性检验机制，保证收发双方数据的一致性，防止信息被非授权修改。4.4、 审计：记录应用日志，对事件进行分析，并能提供预警信息。4.5、 数据备份：利用数据库的备份功能将建设的平台和系统数据备份到指定的服务器或存储系统上。4.6、 要求投标人需从物理安全、网络安全、系统安全、应用软件安全、数据备份安全等几个方面提出配套的安全体系完善方案，以便防范安全风险。4.7、 提供数据开放过程的安全性管控机制。提供各种人员操作的系统日志，能够对数据操作进行管理和追查；提供数据接

20、口、数据操作任务或方案的调度管理，对调度执行日志进行管理和追查。4.8、 为使用信息系统的用户提供统一身份认证服务。保证身份的真实性，信息的保密性、完整性以及相关应用业务（如支付、审核等）的不可抵赖性。其宗旨是保证各应用系统提供的服务和享受服务的用户实现安全交互，并为用户提供网上的身份认证和信任服务。4.9、 用户和权限完全由内部自主管理。区别于其他公共身份认证中心，完全享有组织内部信息的保密性和独立性,管理方便,安全可靠,不受第三方控制。完全基于WEB界面，加密传输，无需专用客户端，随时随地可进行管理，方便安全。4.10、 密码加密：支持扩展SSHA、MD5、SHA等多种密码加密算法，加密算

21、法不可逆，加密后数据不可被复制猜测；并可以快速扩展用户属性信息。4.11、 安全的认证方式：要求基于非共享Cookie的CAS认证方式，集成应用不能读到CAS域名下的安全令牌。4.12、 支持国产软件能力：国产化支持是国家政策，同时国家对高校系统的安全等级有严格要求。要求本次所投产品不论是管理端还是用户端都应该支持国产操作系统与国产数据库。5、建设内容5.1.数据治理5.1. K数据治理范围1）本次项目数据治理范围包括以下数据源头治理：人事、教务、科研、学工、财务、一卡通、图书、0A、后勤和资产等不少于10个主要数据来源业务集成工作由投标人、原业务系统提供商和采购方共同完成。2）构建关键业务申

22、报、审核流程，以典型业务作为抓手，一数一源结合业务过程机制，构建数据采集、维护和管理机制，逐步形成高质量的业务数据。实现伴随式、动态数据采集，逐步形成规范的数据采集机制，不断提升数据质量。5.1.2. 数据治理体系建设服务1）投标人需从组织架构、政策制度、管理流程等方面对学校数据管控现状进行全面评估，提供数据管理和治理的规范文档模板，协助采购人形成正式的管理办法并发布。其中包括：2）建立适合学校的数据治理组织架构，包括决策层、管理层和执行层，明确不同层次机构的职责和任职要求，制定不同层次之间及层次内部的工作协同和汇报流程，在人员到位后即可按分工职责开展工作。输出数据治理组织模型，该模型必须包含

23、组织架构图、具体的角色定义，角色职责定义；围绕数据标准、元数据、主数据、数据质量、数据安全等治理职能，明确各个角色在流程中的活动角色。3）建立适合学校的数据管理办法，覆盖总则、管理职责与分工、信息资源目录管理、数据采集与存储、数据共享、数据使用、数据平台管理、数据安全管理、数据质量管理、监督问责等数据治理管理领域，可根据学校要求进行专项考核制度制定（如针对业务人员故意或无意录入不准确数据的考核等），切实将数据管控落实到各项相关工作中。该办法需要明确管理数据范围；数据管理、数据采集与数据质量等基本概念定义；数据管理、提供、使用单位的职责；信息资源目录的定义、维护管理制度；数据采集的流程与制度、采

24、集单位的责任；数据共享方式定义、共享原则、使用流程等；数据使用的原则、范围、责任；数据安全管理责任、工作开展方式；数据质量的发现、反馈、受理机制流程；数据管理、数据质量过程中重大问题的问责机制。4）建立数据管理配套工作流程、管理制度、工作规范（包含但不仅限于如下文档：数据标准&模型命名规范、数据接口命名规范、数据集成与共享规范、业务元数据变更规范、数据使用授权规范、数据集成与共享规范、数据质量管理规范）等。具体要求包括：需要明确数据标准设计原则、数据模型命名规范；明确ETL接口分类、接口命名的规范；APl接口分类及命名规范；明确数据集成流程定义、数据共享流程定义；业务元数据变更管理制度及变更流

25、程；明确数据共享类型以及数据使用申请、授权流程等。5.1.3. 数据治理规划服务5.1.3.1, 数据资源及需求调研投标人需对治理范围内业务系统或部门进行实地调研，以数据视角摸清各系统（或部门）核心编码规则、数据字典、业务数据的建设使用情况，执行层面存在问题，也充分了解各系统（或部门）当前及未来对数据的需求,输出部门数据调研报告。报告内容具体要求如下：（1）系统建设使用情况；需要明确系统名称、责任部门、系统建设方、建设年代、数据库情况、系统访问情况等信息；（2）数据核心数据编码情况；了解核心编码的分类及编码规则，例如本科生分类及学号编制规则，教职工分类及编号规则；便于制定或优化学校核心公共标准

26、。（3）部门提供数据：需全面了解本部门数据的生产情况，包括线上线下，需描述业务名称、数据名称，数据项名称、数据规模、数据更新频度等；便于明确数据治理范围。（4）部门数据需求；全面了解本部门数据的当前及未来需求情况，包括提出部门、需要数据名称、数据项描述、用途场景、提供部门；便于明确数据治理范围。（5）数据字典：根据部门提供数据、部门数据需求内容，全面采集业务系统数据字典，需要输出数据字典名称，字典代码、字典名称等内容，供后续统一代码标准，制定代码标准的清洗转换规则使用。（6）问题描述：详细记录业务部门反馈的数据问题，包括业务部门，提出人、问题描述，问题类型。5.1.3.2, 数据治理规划5.1

27、3.2.1、数据责任规划汇总各业务系统及部门调研情况，以一种清晰及标准化的设计理念对数据资产进行顶层设计和规划，从全局的视角对数据进行管理和划分，以“一数一源”、“谁产生、谁负责”为指导原则，设计定义代码标准和数据标准清单，围绕清单，明确部门责任，根据部门使用需求，形成供需UC矩阵，作为学校顶层数据架构，经过校方确认之后，输出代码标准治理责任清单及数据UC矩阵、数据治理责任清单及数据UC矩阵。报告内容具体要求如下：(I)代码标准治理责任清单及数据UC矩阵：包含代码分类、代码标准名称、代码标准对象名称、责任单位、各单位是否使用等；清单需要覆盖治理范围内所有涉及到的代码标准；从数量上代码标准清单不

28、少于300个；数据标准治理责任清单及数据UC矩阵：包含数据一级分类、二级分类、数据名称、数据对象名称、责任单位、各单位是否使用等。清单需要覆盖治理范围内所有涉及到的数据标准；从数量上数据标准清单不少于500个。51.3.2.2、代码标准规划结合调研情况，投标人需要从顶层规划与设计层面，对影响全局、制定难度较大、执行推广难的标准，以下称为核心公共标准，优先配合校方完成制定，包含但不仅限于如下：校区代码、组织机构分类与代码、人员分类与编码规则。同时明确核心公共标准的管理、维护等职责及业务流程。经过校方确认之后，输出并发布核心校标及编码规范。具体要求如下：(1)校区代码：校区代码需包含代码、名称，顺

29、序、是否使用等信息(2)组织机构分类与代码：需要覆盖党群组织、行政部分、直属单位、学院、党委、科研机构等；明确归口管理的单位，编码规则、维护流程；组织机构描述需包含单位编号、单位分类、单位名称、所挂靠单位、中文简称、英文名称、层次、级别、党委隶属、排序、状态、成立时间、成立文号、撤销时间、撤销文号等属性。(3)教职工分类及编码：需要覆盖人事归口管理、部门归口管理的人员等；明确人员分类及各类人员的归口管理单位、编号规则、管理流程；(4)学生分类及编码：需要覆盖学工、教务、海外学院等；明确学生分类及各类人员的归口管理单位、编号规则、管理流程；对于其它代码标准，投标人需要以代码责任单位为单元，遵从参

30、照国标、行标、同时结合校标，梳理代码标准,制定初始代码标准，需要和责任方讨论落实，经过责任单位确认之后，输出业务管理信息标准-代码标准，投标人需要依据该标准配合校方进行业务源头的标准化推进。该标准具体要求如下：（1）需要覆盖责任单位负责的所有代码标准；（2）需要明确标准的编制及设计原则；（3）代码标准描述必须明确分类、名称、表名称、参照标准体系；（4）代码标准内容需要包含代码、名称、层次、父节点、顺序、是否使用等属性。5.1.323、数据标准规划投标人需要以数据责任单位为单元，以数据视角、标准化设计理念，从全局的视角对数据进行管理和划分，遵从参照国标、行标、同时结合学校实际业务情况，定义数据标

31、准、数据模型、数据采集策略、数据共享策略、基础数据质量标准，需要和责任方讨论落实，经过责任单位确认之后，输出并发布业务管理信息标准-数据标准,配合校方进行业务源头的标准化推进。该标准具体要求如下：（1）需要覆盖责任单位负责的所有数据标准；（2）需要明确数据标准数据元素广义描述，例如数据项编号、数据项名、中文名长度、主键、类型、值域等；（3）需要明确数据共享类型、采集策略的定义；（4）数据标准描述中需要有数据分类、数据名称、数据模型名称、描述、提供部门；数据项描述需要包含数据项编号、数据项ID、数据项名、字段中文名、类型、长度、主键、是否为空、值空间、解释/举例、引用编号；（5）数据采集策略需要

32、明确数据是线上还是线下数据，采集方式、采集频度等（6）数据共享策略需要明确共享类型，便于数据使用时进行规范化管控；需要明确数据项的责任单位。5.L324、开放能力规划投标人需要以数据消费、服务化视角，围绕各部门提出的数据需求，分2层规划设计学校数据开放能力，一层基于现有的数据标准构建业务模型，进行开放能力（APD的规划设计，二层投标人需要兼顾服务应用建设，进行业务模型及开放能力的规划，和信息化部门讨论落实，经过信息化部门确认之后，输出并发布开放能力规划，配合校方进行数据开放能力建设。该规划具体要求如下：（I）提供不少于30个业务模型；业务模型描述参照数据标准规划中具体要求；（2）提供不少于50

33、个API的规划；（3）APl描述需要包含APl名称，业务模型名称、APl描述、入参、出参、需求场景。5.14、数据治理实施服务数据治理实施主要从标准管理、数据集成、数据质量、数据共享开放四个方面开展工作，依据数据标准规划，对学校现有数据进行整合关联，按照标准数据模型进行抽取并标准化转换和清洗，按照业务领域进入全量数据仓库，形成全校基础数据资产；依据数据质量标准规划，进行数据质量评估；依据开放能力规划,构建学校数据开放能力。5.1.4.1标准管理投标人需以责任单位为单元，依据代码标准规划阶段取得的成果，进一步落实并完成以下工作：（1）完成代码标准校核、入库管理；（2）可集中对代码标准进行拆合、启

34、停等操作，能够记录代码变更过程；（3）需覆盖责任单位清单类所有代码标准；可通过系统查询；（4）完成代码标准和责任单位数据字典的代码映射关系的管理功能，实现代码映射的自动感知匹配功能。在代码标准映射过程中，可提供有代码和无代码两种场景下的映射管理；（5）需能够提供针对信息编码的管理，可自动记录代码标准的变更记录，自动生成标准版本号，管理员可查看、删除己发布的任一历史版本标准详细信息,并支持导出标准以及将任意历史版本标记为现行标准等操作；（6）需支持选择任意两个信息编码标准进行版本差异对比，并支持导出将版本变化详情。5.1.4.2,数据标准管理投标人需以责任单位为单元，依据数据标准规划阶段取得的成

35、果，进一步落实并完成数据标准管理工作：（1）完成数据标准校核、入库管理；（2）需能够提供针对数据对象标准管理，可自动记录数据模型标准的变更记录，自动生成标准版本号，管理员可查看、删除已发布的任一历史版本标准详细信息，并支持导出标准以及将任意历史版本标记为现行标准等操作；（3）需支持选择任意两个数据对象标准进行版本差异对比，并支持导出将版本变化详情；（4）需覆盖责任单位清单类所有数据标准；可通过系统查询数据标准。（5）提供在线管理规范和实施方案的文档管理功能，支持拖拽的方式将个人电脑的文档上传至系统，需支持包括xls、xlsx、docdocx、pdf、pptpptx这几种格式的文件上传。并添加到

36、不同的分类中。支持通过关键词查询相关文档01.1 .4.3责任管理投标人需以责任单位为单元，依据数据责任规划阶段取得的成果，进一步落实并完成以下工作：（1）完成代码标准、数据责任入库管理；（2）需要支持以责任单位为单元，增加或取消代码标准、数据责任；（3）覆盖责任单位所有责任清单；可通过系统查询责任清单。5.144 、数据集成投标人需以责任单位为单元，依据数据责任规划阶段取得的成果，进一步落实并完成数据资产采集入库工作：（1）针对有源头支撑的数据，提供同步接口制作服务，包括ETL接口或APl接口；（2）针对学校数据集成工作，需提供丰富的数据集成开发包。包括拓扑管理、集成设计、集成查看、集成调度

37、等工具；（3）能够提供丰富的集成接口支持，包括支持主流关系型数据库、支持非主流关系型数据库、支持ODBC数据源类型接入、支持主题或者队列、支持WebService、支持TabIed-Txt文件、支持XML文件以及操作系统的网络协议的集成接口；（4）为了提升数据集成的工作量，需要能够向学校提供基于各种场景通用的知识模块，数据集成需求开发包数量不得低于100项；（5）除了能够提供学校常规主数据管理的功能外，还必须向学校提供基于主数据生命周期的追溯功能，使学校数据管理人员清楚指导每个数据对象随着时间变化，增、册IJ、改的数据量；（6）必须提供基于数据流向的可视化展示功能，能够实时监控数据源头及目标的

38、数据量，接口运行状态等，能够很方便的在拓扑图和详细列表之间进行切换；（7）为方便数据管理员实时监控与目标表相关的源头系统与主数据表之间的运行状态，必须提供数据字段血缘监控功能，实现可以通过目标表下钻至源头、主数据、目标三方的监控可视化环境，可在可视化环境下通过触发表间连接，下钻至接口运行状态监控环境；（8）需支持查询数据对象的接口运行记录，从建表到当前时间的数据全生命周期变化过程；（9）能够面向学校数据集成业务，提供符合高校行业特征的高校行业集成库，通过可视化集成工具，梳理各业务系统核心的数据模型与字段，形成预制同步接口；（10）为方便学校信息中心对数据管理的效率，投标方需提供在线SQL查询器

39、，可方便的进行在线SQL查询操作；（Il）要求提供内置的在线ETL工具，支持集成交换ETL接口管理，能够查看集成交换任务列表,可查询已创建的所有任务详细信息；支持批量变更、导入、导出集成任务；支持新增集成交换任务，能够通过勾选的方式从源数据库的代码表或业务表中配置待集成的字段;支持对待集成的字段进行过滤、左右合并操作;支持已建集成交换任务进行编辑、运行、复制任务、删除任务、查看日志；可以自动加载已配置的代码映射关系，运行接口时自动根据映射关系转换代码数据；（12）需支持ETL调度任务管理，支持自定义配置调度任务的同步规则，支持在调度任务中配置多个集成任务，可通过拖拉拽的方式调整任务执行的顺序；

40、（13）需提供内置ETL集成监控工具，提供可视化的页面展示内置ETL工具的集成数据，包括上行任务数、下行任务数、昨日上行任务数据量、昨日下行任务数据量、总调度数、近24小时调度运行时刻图。通过柱状图或图表的方式展示耗时最大任务TOPl0、昨日上行任务TOPl0、昨日下行任务TOPl0、昨日报错调度/任务情况、未添加调度的任务状况；（14）需提供内置ETL的运行日志监控，支持通过关键字搜索具体调度名称、任务名称、运行时间段进行搜索，监控列表能够显示调度/任务名称、开始运行时间、运行时长、当前状态（包括成功、失败、运行中、手动停止四种状态）、包括新增/修改/删除/失败迭代数据量，可查看每条记录的详

41、细日志信息。其中对于调度计划，需支持查看调度流程及流程中所有接口的运行状况；（15）需提供主数据变化情况查询功能，支持按照时间维度查询数据对象生命周期变化情况，能够查询每个时间变化节点，该数据对象的新增数据、更新数据、删除数据的条目数。能够提供列表展示数据对象变更记录，支持编辑多个条件组进行高级搜索；（16）需提供数据变化历史对比功能，支持查询某个数据对象在两个时间点的数据变化情况；（17）需提供数据异动监测管理的功能，支持配置异动监测字段。支持查询监测字段的异动情况，若某个字段存在异动情况，可点击移动数量下钻查看异动详情，异动详情包括接口名称、服务事件编号、处理日期、变更前的值，变更后的值；

42、（18）需覆盖责任清单范围内所有数据，可通过系统查询到具体数据；（19）以业务域为单元，输出业务域数据治理集成报告并获得校方确认，该报告具体包含该业务域下所有数据上行接口、数据下行接口；接口描述需包含接口描述、目标表、调度任务、调度频率、集成策略、具体字段映射、清洗转换规则等。5.1.4.5数据资产展现通过对数据资产可视化展现功能建设，使学校可以清晰看到现有校级资产状况，涉及数据模型建模完成情况、数据同步集成概况、数据同步质量等。（1）需提供校级、业务领域、责任单位三个维度的数据建设成果总览，能够满足以可视化树形结构的方式集中方便的呈现学校数据资产概况，其中需要覆盖校级数据资产中包括的主数据对

43、象模型、自定义对象模型、业务对象模型、数据集市模型、代码标准模型五大类。投标方可以提供以打分的方式，对学校一定时间范围内数据资产进行评估；支持查看不同模型分类的状态占比、不同模型分类下的业务模型的完整度占比以及不同业务模型的表数量和数据量。投标方需在投标文件中提供真实运行的系统截图加以证明。（2）需支持查看校级、部门数据报告及环比增长情况，能够满足为学校数据管理员提供在可视化环境下查看数据资产详情，对各模型逐级下探的功能，能够在一个页面上集中展现不同模型下未建表、无数据表和有数据表的个数。支持展示数据画像，在页面左侧提供数据分类展示栏，并支持关键字搜索查看具体的主数据表，选中查询的主数据表可在

44、页面右侧展示该表的相关统计卡片，包括数据对象字段数、资产目录开放字段数、开放业务模型数量、ETL接口数、APl接口数、检测项数，点击卡片可显示相关数据详情。支持查看该主数据的接口统计信息，包括上行接口、下行接口、APl查询接口、APl写入接口，对于上行/下行接口统计信息，能够进一步查看接口的映射关系和运行记录；对于APl查询/写入接口统计信息，能够查询调用日志。（3）需支持饼状图或柱状图的形式展示学校各个版本数据标准使用情况，包括展示各版本访问量分布、各版本搜索量分布及搜索次数、标准搜索热门关键词TOP3、规范文档查看TOP3、规范文档下载ToP3、各版本对象标准与字段数建设情况。需支持以折线

45、图的方式展示各版本对象标准变化率。投标方需在投标文件中提供真实运行的系统截图加以证明。（4）能够支持实现多级权威数据责任单位管理的功能，提供易用配置的方式，将责任单位与主数据对象模型之间建立关联，最终可以在数据血缘关系、部门数据报告、质量报告查询中，可自动根据责任单位进行主数据对象模型的筛选。（5）需要能够为学校提供数据集成接口运行状态的文本及图形方式展现，实现支持查看每个接口调用成功/失败数量上的反馈，以及支持查看不同业务系统接口数量、运行次数和成功运行次数的统计；需能够提供基于数据平台运行的数据流量桑基图。投标方需在投标文件中提供真实运行的系统截图加以证明。（6）需支持查看学校各个时间段的

46、历史数据质量的评分，以及查看学校当前学校数据资产涉及责任单位数、业务系统数、检测数据对象数、检测业务字段数、定义业务检测项数、涉及数据样本数。提供图形化的方式展示个业务领域数据建设及质量情况，支持按照雷达图的方式对业务领域进行数据质量评分。投标方需在投标文件中提供真实运行的系统截图加以证明。（7）需支持提供可视化的方式展示学校数据资产开放情况。包括模型及API开放情况、资产目录开放情况。投标方需在投标文件中提供真实运行的系统截图加以证明。模型及APl开放可视化展示要求如下:需展示业务模型数量、查询APl数量、查询APl调用数、写入APl数量、写入APl调用数、写入数据量等。支持将最新更新数据、

47、热门查询APE热门写入APl的内容进行排列展示。需提供折线图、饼状图等方式展示APl接口使用的趋势分布、以及对外开放模型的种类分布。数据目录开放可视化展示要求如下：需展示开放资产目录数量、开放资产字段数量、公用APl接口数量、私人APl接口数量。支持将最新更新开放数据、热门API、热门下载的数据分门别类的展示。需提供折线图、饼状图等方式展示各个时间段资产使用情况，资产申请情况，资产使用环状图。（8）需支持以三维数据地图直观的展示数据资产中心整体数据架构，从全域数据资产采集、结构化及非机构化数据采集存储能力、数据加工计算、数据质量评估、数据开放共享等全链路体现资产中心治理能力；支持展示ETL接口

48、数、APl接口数、表数、数据量等指标。投标方需在投标文件中提供真实运行的系统截图加以证明。5.1.4.6、数据补采（1）投标人需根据学校数据业务源头建设情况，对存在线下管理或临时需要采集的数据，提供数据补采服务，具体要求如下：提供数据补采工具，满足学校日常excel文件补采工作和临时数据填报任务。其中文件补采功能需包括添加模板、数据补采、补采日志查询等功能。1）数据补采任务配置：需支持添加上传excel模板，并配置该模板所属单位，模板上传后可配置字段映射同步规则，配置字段映射关系；提供自动映射功能，能够根据字段名称进行自动映射；映射后可以点击某一行的映射关系，来选择至少一个主键字段，否则不允许保存。2）数据补采：需支持用户下载模板，模板只包含已经映射的字段；点击补采后先校验表头是否符合模板，如果符合模板格式，直接开始导入数据，完成后提示成功和失败的数据量，并可以下载失败数据列表，提供失败原因。3）补