学院数据治理平台建设需求

学院数据治理平台建设需求一、项目背景自建校以来，学校根据国家政策要求和学校发展需要，积极推进信息化建设，建成了覆盖全校的校园网络基础设施以及一批基于业务单元的应用系统（如教务系统、OA、财务系统、人事系统、科研系统等），并搭建了基础平台，包括统一身份认证平台、共享数据中心、数据清洗与整合平台和信息门户平台，解决了面向用户的门户使用，进行了数据的集中整合。在一定程度上，达到了预期的目标。根据学校信息化现状的分析与研究，目前学校在信息化建设方面虽已取得一定成效，但仍有许多问题亟待解决：1、已有数据标准，但标准不满足目前现状。学校数据标准及信息标准滞后，不符合目前学校行情及国家行业标准。目前校级信息标准已不能指导目前数据中心的信息化建设，参考标准难取用，代码标准、接口标准、下行开放标准缺失，信息标准电子文档难维护、难使用，缺失关键数据管理细则、数据标准管理报告等问题突出。2、数据质量问题突出，缺乏数据治理能力前期共享数据中心建设主要解决了学校各部门数据孤岛问题，实现了基础数据集中管理、达到数据共享交换的目的。但是数据质量问题、数据同步、缺失问题还是很普遍，一方面以往关注点主要是在基础的主数据交换，另一方面数据质量的管理难度大，缺乏工具和标准，处于比较粗放的状态，对数据治理的重视程度也不够高，制度上也缺乏保障。加之在大数据背景下，各种应用系统产生的数据越来越多，越来越快，同时师生服务、管理、决策、以及教学科研的各种活动对数据质量和可信度要求也越来越高。3、重复填报、统计过程繁琐从学校实际情况来看，每年各类业务填报没有数据支持，还在采用较为原始的纸质手段进行，使得数据项重复填报、业务系统数据无法提供支撑，已经沦为常态，同时，数据质量还面临巨大的考验，填报的准确性有待考量。二、建设目标本次项目总体目标是从学校当前的建设现状出发，实现学校信息化建设的现代化和智能化。通过开展以需求为导向、以互联共享为核心、以信息安全为保障的信息化建设，推进以数据共享为目标，整合学校多源头的数据资源，治理学校数据资产，帮助学校建立起一套合规的、可持续提升的数据规范体系，保证对于核心数据资产的沉淀和积累，真正达到数据的准确性和权威性保障。主要包括以下几个方面：建设符合学校实际情况的校级数据字典和信息编码标准，包括各类信息子集标准、代码标准、数据交换标准、接口标准、数据模型标准等；编制学校各项数据管理规章制度；建立各信息系统与数据中心的数据交换机制，保证系统之间相关数据及时同步，打破信息孤岛；建设学校全量数据管理平台，对学校教务、人事、科研、财务、OA、一卡通等主要信息系统生产的数据进行全量采集、清洗整合、主题分类、分层管理，以师生数据全生命周期为主线，实现全校资源数据的有效存储与管理；建设全校数据质量监控体系，保证进入数据中心数据的规范性、完整性、一致性、准确性，定期发布数据质量报告；建设数据填报平台，满足缺失数据、临时数据、报告报表数据的填报采集需要；具备信息标准、全量数据、数据交换使用可视化大屏分析展示平台。建设数据开放平台，让全校师生共享数据治理成果，并参与到学校的数据治理过程中，提高学校数据质量，建设学校自己的数字化的智慧的校园。三、需求内容序号建设内容数量单位备注1全量数据中心1套/2全量数据质量管理平台1套包含12个业务系统的数据质量检测3全量数据开放平台1套4一表通平台1套包含50个表单设计5系统集成10个包含10个新增业务系统的系统集成6数据大屏2个大屏最终内容以校方确认为准四、技术、功能指标序号技术、功能指标1全量数据中心1.1基础性框架软件1.1.1为学校搭建大数据平台和各种组件，包括但不限于以下内容:提供各种能够快速稳定运行的数据计算框架，如Spark；使用ApacheImpala做为对HDFS、HBase的高性能SQL查询引擎；使用Hive数据仓库工具帮助用户分析数据；提供CM安装HBase分布式列式NoSQL数据库；包含原生的Hadoop搜索引擎以及ClouderaNavigatorOptimizer去对Hadoop上的计算任务进行一个可视化的协调优化，提高运行效率；提供的各种软件能让用户在一个可视化的UI界面中方便地管理、配置和监控Hadoop以及其它所有相关组件，并有一定的容错容灾处理；提供基于角色的访问控制安全管理。1.2全量数据标准管理系统:信息标准的实施是数据治理的首要措施，是数据运用的基石，在数据中心架构设计的过程中，数据标准将一直影响和指导学校的业务发展，并提供权威参照依据，标准也会随着需求的变化而不断的更新。1.2.1技术性需求1.2.1.1平台需内置包括2012年部标【教育管理信息标准-高等学校管理信息(JY/T1006-2012)】、2013年国标【国家标准GB/T29808—2013】、2018年国标【国家标准GB/T35298—2017】以及行业经验标准等；内置的参考标准应支持任意取用、下载；支持自定义标准。1.2.1.2基于国家标准和教育部标准，在现有学校信息标准的基础上，建立完善学校数据标准体系，包括数据集标准与数据代码标准，并支持可视化管理。1.2.1.3平台需和全量元数据及关系管理系统可实现联动，支持四层标准草案的管理，包括原始层、主题层、统计层、应用层标准的在线配置、模板导入和批量取用。1.2.2功能性要求1.2.2.1数据管理员首页:系统应提供数据管理员首页统计展示，应支持对参照标准统计、全量数据中心采标率统计、标准草案统计。1.2.2.2参照数据标准管理1.2.2.2.1参照数据标准首页:应支持数据集、代码集的查看、下载，支持新增/编辑数据集，发布/停用数据集，下载和配置数据集。1.2.2.2.2参照数据标准配置页:系统应支持自定义数据集，内置数据集、内置代码集功能，应提供标准内容的导入/导出；新增目录/表/数据项，且必须支持批量新增；支持删除目录/表/数据项，且必须支持批量删除；提供批量取用已发布参照标准的功能。1.2.2.3标准草案管理:需管理学校自定义的标准草案，在成为执行标准前支持在此页面进行标准代码集、数据集的单独管理、维护。需支持学校自定义标准草案时新增、修改、删除、配置等基本操作。1.2.2.3.1草案首页:应提供标准草案的拟定功能，包括数据集、代码集的新增/编辑/删除和发布。1.2.2.3.1.1新增标准草案:需支持新增草案，提供输入草案名和草案描述的功能。1.2.2.3.1.2信息标准发布:需支持学校自行编辑的信息标准，信息标准内容只有通过发布才会成为本校执行标准，提供给其他普通用户查看。1.2.2.3.1.3信息标准删除:需支持删除学校自行创建的信息标准1.2.2.3.2草案配置页面:草案配置页面应支持取用参照标准、自定义标准草案、批量导入标准内容。1.2.2.3.2.1需支持数据集的分层管理，支持每层标准内容的导入导出；应提供批量取用数据集标准（已发布参照标准、执行标准、元数据）；应支持批量新增目录/表/数据项，编辑目录/表/数据项，批量删除目录/表/数据项；需提供移动数据项功能。1.2.2.3.2.2需支持代码集管理，应提供标准内容的导入/导出；应提供批量取用代码集标准（已发布参照标准、执行标准、元数据）；应支持批量新增目录/表/数据项，编辑目录/表/数据项，批量删除目录/表/数据项；需提供移动代码项功能。1.2.2.4执行标准管理:需对经标准草案发布的标准（数据集和代码集）进行管理，能查看数据集、代码集，支持对各个历史发布版本进行统一管理。并能设置和取消各发布版本的执行状态。同时支持一键同步标准数据表至全量数据中心元数据。1.2.2.4.1执行标准首页:应支持数据集标准管理，应支持下载执行标准数据集文档、基础信息展示、结构图谱展示、更多版本管理、执行标准同步至元数据。应支持灵活选择管理标准分层（原始层、主题层、统计层、应用层）一键同步至元数据。应支持代码集标准管理，提供下载执行标准代码集文档、基础信息展示、更多版本。1.2.2.4.2执行标准配置:需支持数据集分层管理，包括预览建表语句、批量导出建表语句、批量导出标准内容；应支持代码集的批量导出标准内容。1.2.2.5数据中心采标率:需支持查看数据中心采标率，需支持查看不同业务系统中表的历史变化情况。1.2.2.6标准对比分析管理:通过不同标准之间、标准与元数据之间的对比，应支持通过图形化、数据表形式体现目标标准与对比标准的详细差异。1.2.2.7标准管理办法:协助学校根据实际情况制定出适合本校的数据管理办法，并支持管理办法的新增/编辑/删除/下载和在线预览。1.3全量元数据及关系管理系统:全量元数据及关系管理系统用于管理全量数据中心的所有元数据的产生和迭代过程，记录元数据与数据中心结构的变化，客观反应数据业务属性、技术属性和管理属性，基于元数据的管理功能，有效解决元数据和数据标准之间的业务连续性问题，建设为实现教育业务系统间的数据资源共享与信息交换以及实现业务综合报表、决策知识挖掘、决策分析提供的基础支撑。1.3.1技术性需求1.3.1.1基础性技术要求1.3.1.1.1系统需采用开放、标准的数据库设计。平台需基于SOA思想，以XML为信息交换语言，需支持跨平台部署，对数据库中的表与数据项都提供中文备注。1.3.1.1.2数据来源需支持完全自定义模板配置，需支持可编程化查询语句有效兼容了所有业务数据查询方式，需支持对外提供开放的数据访问服务接口，并实现对服务接口的管理，需支持对服务接口名称和描述的编辑，以及对接口的授权管理。1.3.1.1.3系统需遵循“谁产生、谁维护”的原则，所有的数据都有唯一的产生者和维护者。在管理上，需通过制定相应的应用规范要求数据生产者/维护者及时更新自己负责的数据，从而保证全量数据中心的数据按照学校信息标准更新。1.3.1.1.4系统需提供覆盖了全面的日志记录，需实现用户对系统标准的变更，元模型的变更，以及数据服务调用都是有详细的日志信息可以追溯。1.3.1.2其他要求1.3.1.2.1整体架构要求:整体架构需采用分层设计的方法，各层具有独立的功能含义和实施要求。需包含：原始数据层、主题明细层、汇总统计层以及应用数据层。详细如下：1.3.1.2.1.1原始数据层（原始层）:原始层数据结构与源业务系统最为贴近，设计功能要求与业务系统松耦合、源业务系统数据接入完整、数据的增量识别、短期的历史数据、高效的数据接入、中心库的数据来源、完整的源业务系统数据明细。1.3.1.2.1.2主题明细层（明细层）:设计功能要求：数据按主题存储、快速的数据查询结构、统一的业务编码、中长期历史数据、与行业标准结构贴近、完整的业务相关数据明细。1.3.1.2.1.3汇总统计层（统计层）:设计功能要求：数据可以是汇总数据、可以是快照数据、不包含明细数据、可满足初级的统计要求；是数据分析常用的数据源。本层数据主要由应用层展现要求而反推出的汇总中间数据，一般不是最终结果数据，而是大粒度的半结果性数据，主要作用在于提高后期查询互动的性能。1.3.1.2.1.4应用数据层（应用层）:设计功能要求：数据根据实际数据需求生成，满足表格、图形等数据展示和应用；是数据计算的最终结果，无其他数据处理过程依赖此数据库。此层数据形式大都是简单视图方式，提供给各应用系统（如门户、综合校情分析、手机门户等）直接使用。其创建需求就是来自于各应用系统的数据接口需求。1.3.1.2.2数据流向要求:数据流向要求数据能够从各个系统的接口出发，通过ETL工具将数据抽取到原始层，然后再根据主题数据标准的映射规则将原始层数据通过已有数据清洗与整合工具进行清洗、转换并装载到主题层，再根据分析需求，将主题层的数据做相应的计算并装载到统计层。最后，将门户需要展示的数据视图、报表中心需要的数据视图、个人中心的数据视图以及数据中心对外的接口表或者视图写到应用层进行统一管理，实现对数据全生命周期的管理。1.3.2功能性需求1.3.2.1数据管理员首页:系统应提供数据管理员首页统计展示，应支持数据中心总存储空间统计、数据中心表总数统计、数据中心数据项总数统计、数据中心数据总条数统计、参与数据交换系统（平台）总数统计、流入数据总条数统计和流出数据总条数统计；并可查看今日数据中心数据流向一览。1.3.2.2元数据管理1.3.2.2.1数据集元数据:基于数据中心四层架构模型，通过数据集元数据进行每一层元数据的管理，需提供个性化的配置方式支持在线配置数据集。支持界面增删改等基本操作，也包括手动/自动全量同步元数据至全量数据中心、反向同步至元数据，并可立即检测源表对比情况。系统需支持每一层的统计信息展示，原始层元数据需展示机构/平台的统计，集成的业务系统统计，表/视图个数/数据项统计系统应支持批量导出数据集、批量导出SQL、批量导入数据集；支持对目录/表/数据项的新增、编辑、删除；需具有更新待同步表至全量数据中心的功能，更新变化表至元数据、移动数据项排序。系统应支持自动识别原始层的表是否存在转换（有原始层映射关系则代表有转换），若不存在转换则支持“在线生成转换”。是否配置转换的更新频率应与自动提取映射关系强相关。系统在线生成转换的转换需符合命名规范：上行_业务系统名称_表中文名称。1.3.2.2.2提供元数据中数据集源表采集以及在线自动生成转换作业的功能演示。1.3.2.2.3数据集元数据结构图谱:系统需支持图形化展示各层数据集元数据机构，展开/收缩子集分支。1.3.2.2.4代码集元数据:需管理全量数据中心代码表表结构，提供个性化的配置方式在线配置数据集。支持界面增删改等基本操作，包括手动/自动反向同步至元数据。系统需支持每一层的统计信息展示，包括代码集、代码表的统计。系统应支持批量导入代码集、批量导出代码集、支持对目录/表/代码项的新增、编辑、删除；更新变化表至元数据。1.3.2.2.5代码映射关系管理:需支持代码映射关系管理，分别记录原代码目录、原代码表表名、原代码表数量、映射表表名、代码映射关系数、预警映射关系数，应支持编辑、删除操作。需支持新增代码表映射关系、立即检测代码关系、导出文件等功能。1.3.2.2.6数据集监测日志管理:应支持数据集变更日志统计，分别记录数据集和代码集数据项变更的情况，展示全量数据中心元数据正向/反向同步元数据表的更新记录，包括数据集元数据和代码集元数据。方便追踪数据中心元数据的变化情况。1.3.2.2.7代码集监测日志管理:应支持代码集变更日志统计，分别记录数据集和代码集数据项变更的情况，展示全量数据中心元数据正向/反向同步元数据表的更新记录，包括数据集元数据和代码集元数据。方便追踪数据中心元数据的变化情况。1.3.2.2.8UC矩阵预览:系统需支持UC矩阵预览（包括数据表和字段级的预览），原始层的表结合映射关系通过系统自动识别表的使用者，快速生成UC矩阵。1.3.2.2.9映射关系管理:需实现数据之间的字段级的映射关系管理。1.3.2.2.9.1原始层映射关系:系统需支持实时读取数据清洗与整合平台作业数据表解析，需提供新增映射关系，查看/编辑映射关系详情，查看映射关系，删除映射关系。1.3.2.2.9.2主题层/统计层映射关系:系统需支持实时读取数据清洗与整合平台作业数据表解析，需提供新增映射关系，查看/编辑映射关系详情，在线配置映射关系详情，预览映射关系，删除映射关系。1.3.2.2.9.3应用层映射关系:系统需支持实时读取数据清洗与整合平台作业解析视图，需提供新增映射关系，查看/编辑映射关系详情，在线配置映射关系详情，预览映射关系，删除映射关系。1.3.2.2.9.4提供全量数据中心元数据管理功能演示，应至少包含数据集元数据、数据集元数据结构图谱、代码集元数据、数据集监测日志管理、代码集监测日志管理。其中数据集元数据包含主题数据层、统计数据层、应用数据层，并且每一层中的数据子类详细信息需至少包含中文名称、数据项名、长度、值空间、主键、解释举例等内容；同时数据集进行整体支持导入、导出和SQL语句导出功能，并且可以针对某一数据自行进行新增和批量操作。1.3.2.2.10元数据关系分析:系统需利用元数据可视化展现映射关系的定义，描述元数据之间复杂的映射关系；应支持通过多对多的映射形成元数据之间的完整拓扑，形成全量数据中心四层架构数据表之间复杂的关系图谱。元数据关系分析分为UC矩阵分析，全链分析，血缘分析，影响分析等多种分析页面，需根据我校不同业务场景支持查看不同的分析页面。1.3.2.2.10.1UC矩阵分析:应支持UC矩阵分析关系图谱，按照数据维护分布图和数据使用图分别反应各业务系统维护、使用表的整体情况。关系粒度要细化到表中字段级别。1.3.2.2.10.2全链分析:应支持全链路展示并分析全量数据中心四层架构间各表的关联关系。关系粒度要细化到表中字段级别。1.3.2.2.10.3血缘分析（该功能需提供清晰截图证明并加盖单位公章）:应支持对某数据表向上分析查找该表的祖父表至原生业务系统，快速定位数据问题。需提供图形说明、血缘图谱展示、关联映射关系。关系粒度要细化到表中字段级别。1.3.2.2.10.4影响分析:对某数据表向下分析查找该表的使用对象至业务系统，需提前预测修改某字段属性给下游系统或部门带来的影响。需提供图形说明、影响分析图谱展示、影响表统计、关联映射关系。关系粒度要细化到表中字段级别。1.3.2.2.10.5数据地图（该功能需提供清晰截图证明并加盖单位公章）:需以三维立体地图的方式反映各个部门之间数据的流向，包括数据流入、流出的动态模型展示。1.3.2.2.10.6提供元数据关系分析管理演示，要求演示U/C矩阵分析、全链分析、血缘分析、影响分析、数据地图。要求演示进入全链分析可以以图形的方式展示四层架构的数据关系，要求演示向上追溯系统，找数据如何产生，向下可以找到数据的影响分析，找到数据的使用方向。1.3.2.3历史拉链管理:历史数据拉链管理对主数据非常重要，后续分析也会经常要使用到历史数据，问题出现也会去查询数据的历史拉链。因此，系统需在原始层提供历史数据拉链的管理功能，对原始层元数据进行数据拉链的设置，然后进行数据历史拉链的查看，并提供数据变更对比分析功能，分析某张表在不同时间的历史数据以及数据更新情况。1.3.2.3.1配置历史拉链:需支持批量设置历史拉链和批量取消历史拉链，支持单个表是否设置历史拉链。1.3.2.3.2查看历史拉链:应支持历史拉链的查看、历史拉链分析（按日期）。1.3.2.4数据服务管理1.3.2.4.1数据查询分析工具:需通过数据垂直搜索的方式提供可视化、自定义SQL等个性化方式查询全量数据中心数据表中的数据。通过自定义SQL查询支持保存查询模板、导出数据。通过可视化查询支持保存查询模板。1.3.2.4.2应用系统管理:应支持对接入的业务系统实现统一管理的功能，支持查看应用系统的名称、所属机构、系统类型、全量数据中心参与角色、服务授权数、授权IP地址、授权序列号；支持对业务系统编辑/服务授权，编辑内容包括输入授权IP地址及刷新授权序列号；支持查看已授权列表并可对已授权服务进行删除和批量删除操作，支持查看未授权列表并可进行授权和批量授权的操作。1.3.2.4.3数据服务管理:管理全量数据中心上行、下行数据的服务，需提供服务新增、编辑等基础功能；界面上同时支持统计服务的调用信息，包括服务的调用情况以及调用日志。新增数据服务，并对服务进行命名、设定调用频率并对其进行描述；支持对服务进行授权，经过授权的应用系统才有权限调用该服务；应提供对服务的停用、发布、删除、测试。1.4全量主数据管理系统:系统以主数据管理和共享为核心，提供全生命周期管控的主数据治理功能，协助我校实现主数据的标准化管理、统一数据表和全局共享，打通各信息系统之间的数据集成和业务协同，发挥主数据业务价值，促进学校降本增效。1.4.1技术性需求1.4.1.1要求采用B/S架构实现主数据可视化管理，并实现前台页面与服务器后台的实时通信，提高系统性能。1.4.1.2系统整体框架需采用可扩展性框架进行搭建，便于后期扩展。1.4.1.3要求系统灵活性高、可扩展，能够适应不断发展的需求。1.4.2功能性要求1.4.2.1机构分类管理:应支持机构的新增/编辑/删除功能。1.4.2.2组织机构管理:应支持组织机构的新增/编辑/删除/搜索功能，并支持组织机构的批量导入/导出。可新增机构号、机构名称、机构简称、机构简拼、所属校区码，选择机构分类，对组织机构进行描述。1.4.2.3专业信息管理:系统应提供对专业的新增/编辑/删除/搜索功能，并支持专业的批量导入/导出。可新增专业号、专业名称、所属机构，并选择相应学制。1.4.2.4班级信息管理:应提供班级信息管理功能，支持班级信息的新增/编辑/删除/搜索功能，并支持班级信息的批量导入/导出。可新增班号、班级名称，并选择所属专业。1.4.2.5系统厂商管理:应提供厂商管理功能，支持系统厂商的新增/编辑/删除功能。可新增厂商名称，对系统厂商进行描述。1.4.2.6业务系统管理:应支持业务系统的新增/编辑/删除/搜索功能；应支持业务系统的批量导入/导出。可新增业务系统名称、系统简拼、访问地址，选择所属机构/厂商名称/系统类型,支持图形显示状态（显示或隐藏）以及参与全量数据中心角色的设定（包括数据使用者、数据提供者和未参与）。1.4.2.7学生基本信息管理:应支持学生基本信息的新增/编辑/删除/搜索功能，并支持学生基本信息的批量导入/导出。可新增学号、姓名、联系电话、邮箱，选择性别、年级、所属班级和是否在校，并可上传头像。1.4.2.8教职工基本信息管理:应支持教职工基本信息管理功能，支持对教职工基本信息的新增/编辑/删除/搜索功能，并支持教职工基本信息的批量导入/导出。可新增教工号、姓名、联系电话、邮箱、职务，选择性别、学历、所属机构信息、政治面貌和是否在职，并可上传头像。1.4.2.9信息主题管理:应支持业务系统的新增/编辑/删除功能；应支持通过主体名称或简拼快速检索；应支持业务系统的批量导入/导出。可新增主题名称、主题简拼，对主题进行描述。2全量数据质量管理平台:为实现学校数据质量提升，需建设数据质量管理平台来自动检测数据的质量。数据质量管理平台的目标是监控数据状态，并对数据在任何程度上满足期望提供一定程度上的保证，用来检测可能指出一个数据质量问题的数据变化或在数据生成中的其他变化。2.1技术性需求2.1.1基础性技术需求2.1.1.1要求登录时间最长不超过8秒，检索时间不超过10秒，页面跳转不超过8秒，并发数60以上。2.1.1.2要求平台可以全天候24*7天运行，不会因为程序错误导致影响失败或者系统崩溃。2.1.1.3需支持同时兼容符合HTML5标准的主流浏览器，例如IE9及以上，chrome浏览器等。2.1.1.4需基于教育数据质量联机评估框架，数据质量检测元规则从五个方面，即完备性、及时性、有效性、一致性和完整性评价数据质量。2.1.1.5为支持在不同业务系统中重用规则，数据质量监控系统中每一个规则都需由规则描述语言RDL来表达。RDL由系统生产，并由规则执行引擎解析执行，不需要用户对其进行编辑。2.1.1.6数据质量监控系统，需提供在快速评估中进行列剖析，在数据质量监控模块中，通过创建相应的质量监控规则实现连接分析和键值分析。（需提供截图证明）2.1.1.7数据质量监控系统需利用相似重复数据检测算法，快速比对数据，自动发现相似重复数据。2.1.1.8数据质量监控系统需要基于内存数据库操作，从而提升数据质量检测效率。2.1.1.9系统需具备灵活的业务检测规则的设计功能，无需使用SQL代码即可实现。2.1.1.10需提供“脏数据库”管理，为数据质量治理留下记录。并且对满足数据质量阈值的“脏数据”，根据报告形成周期，向数据质量负责人定期通报数据状况以及改进建议。2.1.2其他需求2.1.2.1需要数据质量监控工作能够支持分布式多线程运算，提高运算能力。2.1.2.2需支持集群部署，保证系统高可用。2.1.2.3系统必须支持自动负载均衡，提高系统运行稳定性以及方便灵活的任务调度管理功能。2.1.2.4系统需通过先进的技术解决方案，最大化利用现有硬件资源，以适应高校环境中大数据量的实际情况。2.2功能性需求:数据质量监控平台需包含：数据源管理、快速评估工具、数据质量监控、业务规则管理、数据质量报告、消息中心、正则表达式配置、引擎管理以及日志管理功能。2.2.1数据源管理2.2.1.1系统需具备数据源管理功能，主要用于管理数据库数据源连接信息以及监测数据源的可用性，为数据评估、数据质量检测提供基础。应支持各种国内外主流数据库等。2.2.1.2系统需具备设置元数据同步频率的功能，并支持对同步时间的设定，按照每天/每周/每月进行设定。2.2.1.3为适应高校业务场景，系统需具备业务分类管理功能，业务分类是指按照一定主题聚集的数据表或者视图，比如教务业务系统为一种业务分类，由选课信息、成绩信息等数据表、视图构成，用于将数据源下的实体表进行分类管理。2.2.1.4业务分类功能需包含新增业务分类、修改业务分类、删除业务分类功能。并可设置业务分类的名称，从用户列表中选择数据负责人，可通过鼠标点击的方式选择业务分类中需要的数据表，支持待选数据表和已选数据表的查询功能。2.2.1.5系统需具备对数据源的定时检测功能，支持按照每天/每周/每月进行设置。2.2.1.6需支持配置数据质量大表&近十年数据分布功能，选择一个业务分类，需具备对表进行质量大表（是/否）、近十年数据分布（是/否）的设置功能。配置成功的表需在数据质量报告中相应模块进行展示。2.2.2快速评估工具:为便于快速掌握数据质量概况，需具备快速评估功能，可对关键数据进行快速评估，得到评估结果，以图形化界面展示数据量，数据极值，数据分布，数据填充率等指标。2.2.2.1选择评估对象2.2.2.1.1需支持选择业务分类中一个表下的一个字段，并把该字段加入到评估队列里。因学校数据表及字段众多，需要支持按业务分类及数据表搜索功能。2.2.2.1.2为了能得到更有业务价值的快速评估结果，需要能够设置被检测数据字段类型转换的功能，可选择将文本型字段转换为数值型或日期型进行快速检测。2.2.2.2评估进程管理:要求管理员可以查看队列中等待评估的字段列表，并可取消队列中的等待中的字段，便于管理员查看评估进度。2.2.2.3查看评估结果:要求管理员可以查看评估的结果(图表)，便于管理员了解数据项的数据概况。评估结果内容需要包括数据源名称、业务分类名称、数据表名称、字段名称、字段类型、空数据占比图形、数据总数、空数据总数、对字符型字段需要显示字段最大长度和最小长度、对日期类型字段要显示按年度数据量分布，最早年度，最晚年度、对数值型字段需要显示最大值和最小值。2.2.3数据质量监控2.2.3.1应支持数据质量检测运行结果的大屏展示，展示运行的统计分析内容，包括监控表、监控字段、业务规则的总数等，还应具有重复率、变化幅度、更新率、波动幅度、多列有效性等检测结果数据的占比展示。2.2.3.2需提供立即检测和检测回放功能。2.2.3.3需支持从该界面钻取到业务分类界面查看该业务的质量检测运行结果。2.2.4业务规则管理2.2.4.1数据质量监控规则设置2.2.4.1.1需要系统支持动态数据质量监控规则配置功能，采用图形化鼠标点击及参数设置等操作方式，让用户在无需编写SQL语句的前提下，方便快捷的根据业务需要，设置数据质量监控规则。2.2.4.1.2系统需支持数据质量规则的启停监测设置，便于管理数据质量监测状态。支持通过规则模板设置数据质量监控规则、禁用或启用数据质量监控规则，便于管理数据质量的监测策略。2.2.4.1.3数据质量监控规则设置内容应包括规则名称、检测维度、被检测字段的逐级选择功能（通过数据源、业务分类、数据表、字段的逐级选择）、阈值、对评分影响的权重等。2.2.4.1.4为保证数据质量检测的全面性，数据质量检测应包含多种检测维度，至少应包含数据填充率、数据唯一性、跨表数据有父无子的父记录检测、跨表数据有子无父的子记录检查、数据表中信息在一段时间内变化及时性检查、数据表中字段值在一段时间内值范围变化幅度检查，以上检测内容在数据质量监控规则设置中必须做到仅通过鼠标点击即可完成，无需代码编写工作。2.2.4.1.5在数据治理过程中，存在缺失及遗漏、错误数据的情况，为避免此类情况对数据质量的影响，要求提供通过关联关系在进行数据质量监测运算时对数据缺失自动补全的机制，以解决部分字段大面积数据遗漏错误的问题。2.2.4.2检测规则运行管理:需具备管理质量规则检测任务的功能。要求可以设置检测周期（每月/每周/每天/自定义时间间隔），具体检测的时间。2.2.4.3数据质量检测2.2.4.3.1根据已配置的数据质量监控规则对数据质量进行检测，应支持数据质量评分功能，将数据质量结果进行量化，以分值的形式展示，便于管理人员理解，需要提供科学合理的评分计算规则。2.2.4.3.2在检测完成后应提供脏数据管理功能，需通过图形化的方式可视化的展示不同数据表以及字段的脏数据量的多少，可查看到具体脏数据记录内容，并应提供脏数据导出功能供数据治理工作人员进行数据问题的分析与处理。2.2.5数据质量报告2.2.5.1查看报告2.2.5.1.1为使数据质量工作得到校方非技术部门领导和工作人员的支持与理解，对数据质量检测的结果要形成数据质量报告，以更偏向业务化的语言来讲解数据质量分析的结果，需支持下载报告。2.2.5.1.2为提高工作效率与准确性、规范性，需要提供数据质量报告自动生成功能，通过确定报告生成的内容与形式，以图形化结合文字描述的方式展示监控数据的状况，报告内容应包括对数据质量的总结，对通过测量发现的任何数据质量问题的回应，以及改进建议。2.2.5.1.3要求数据质量报告应分为全校整体报告和各部门主题独立报告两大部分。2.2.5.1.4全校整体报告汇总学校整体数据质量情况，需对全校数据质量进行评估，并形成量化分值以及各部门数据质量情况的概览。2.2.5.1.5各主题独立报告需要根据各个主题实际业务情况制定各主题专属的数据质量报告生成规则，包括评估情况、量化打分以及对特定测量类型指标检测出不满足数据质量阈值的“脏数据”，根据报告形成周期向数据质量负责人定期通报数据状况以及改进建议。2.2.5.2检测记录2.2.5.2.1需支持对检测状态、业务分类的搜索查看，检测状态需支持检测中/已完成/异常三种状态。2.2.5.2.2需提供查看业务分类检测记录详情的功能以及规则结果的查看，支持规则结果导出，导出内容应包含业务分类，业务规则、得分、脏数据条数统计，同时能够直接定位脏数据，找到问题数据的出处。2.2.5.2.3需提供检测异常的业务规则列表，用于确定异常范围。2.2.5.3数据质量专题报告:系统除了提供常规质量报告以外，还需支持质量报告的深化补充，至少应包含模式聚类专题报告、分布波动专题报告、列关系专题报告。需提供质量检测规则与生成数据质量专题报告之间的业务联动关系。2.2.6消息中心2.2.6.1消息中心应包括未读消息、已读消息、归档消息，并对消息的类型、内容、发送时间等进行查看，支持详情查看和定位到发生异常的记录。2.2.6.2消息主要来源应包括数据源连接失效、数据质量检测异常、数据评估异常等。2.2.6.3需支持消息订阅配置，根据个人喜好设置接收的消息内容和接收方式。2.2.7正则表达式配置:系统需支持配置相关有效性的正则表达式，在配置规则过程中使用，如对邮箱地址、身份证号等的校验，应内置部分正则表达式。2.2.8引擎管理：需支持引擎使用情况查看，包括CPU核数、物理内存、JVM内存、心跳等，可以对引擎进行启用/禁用。2.2.9日志管理：操作日志管理，要求可以实时展示账号、时间、IP、操作详情，以追踪用户情况方便查找异常情况。3全量数据开放平台：由业务系统分散带来的数据传播性和共享性受到很大限制，同时还存在数据不完整、数据不一致、数据不安全等问题，由于未能提供一个标准的渠道和传统认知问题，大部分人员未能参与其中，导致学校在数据治理的道路上异常艰辛，辛苦治理后的数据还不一定能够支持前端需求。因此需建设面向校级全员参与、基于权限控制下的数据开放服务平台，让全校师生共享数据治理的成果，从而建设生态型智慧校园。3.1技术性需求3.1.1基础性需求3.1.1.1平台需支持针对涉密数据脱敏处理。3.1.1.2平台需支持在单用户下，平台的信息检索及展示业务点，平均响应时间在3秒内；同时支持连接数5000-10000，系统运行稳定；3.1.1.3平台需兼容符合HTML5标准的主流浏览器，例如IE9及以上，chrome浏览器等。3.1.1.4平台需提供可视化的配置技术，用户无需通过编码即可实现接口的设计，帮助非专业人士实现接口操作。3.1.1.5平台的安全认证体系应基于URL拦截与ACL控制列表访问技术，对系统完成灵活而高细粒度的权限控制。3.1.1.6平台应基于API数据签名的身份验证方法，在服务端不需要存储用户的登录记录。3.1.1.7平台应基于内存数据库缓存操作，减少数据库的I/O操作，减少运行过程中因等待数据而消耗的时间，加快数据处理的速度，提高系统的整体效率。3.1.1.8要求数据开放平台采用垂直搜索引擎技术方案、强扩展式网格栅格SaaS访问控制技术方案来提高数据开放平台的可用性及安全性，保障学校的数据资产价值。3.2功能性需求3.2.1首页:应提供平台基本信息、开放数据资源的汇总情况、数据资源的分类及资源最新情况等情况展示。3.2.2全局搜索:应支持用户可根据数据资源名称或描述中的关键字、词语进行搜索，可搜索到与关键字、词语相对应的数据资源。3.2.3开放数据资源情况汇总:应支持将数据集开放统计、数据接口开放统计、数据资源统计、平台资源库开放统计、学校参与数据开放部门统计、参与师生统计情况汇总展示，并能体现开放数据资源中覆盖主题比例、院系机构比例、二级部分比例。3.2.4开放数据资源标签分类展示:应支持可根据信息主题和校内部门两种方式向用户分类展示，便于用户能够快速找到所需数据。3.2.5最新数据资源:应支持按发布时间排序展示最近的4个数据资源，包含：最新数据集、数据接口和数据资产，点击标签分别展示各自的最新4条资源的基本信息（基本信息应包含：开放部门，数据资源标题，发布时间），其中数据资产控制权限，仅当有资产权限是才展示。3.2.6最热数据资源:应支持按访问次数最多排序展示最多访问次数的4个数据资源，包含：最热数据集、数据接口，点击标签分别展示各自的最热4条资源的基本信息（基本信息应包含：开放部门，数据资源标题，访问次数）。3.2.7数据资产目录:应支持根据资产属性、人力资源域、学生管理域、教学资源管理域、科研管理域、财务管理域、资产管理域、热门标签、创建时间等条件快速筛选定位数据资产。3.2.8数据资源开放3.2.8.1应支持信息目录分类和数据来源分类；3.2.8.2应可在数据资源开放中查看数据集和数据接口；3.2.8.2.1其中数据集中的信息应包括：3.2.8.2.1.1开放数据集: 数据集应包括DOC/EXCEL/PDF/PPT/图片/视频/音频等文件形式，平台支持用户上传数据集，由平台数据管理员统一审核后对数据集进行统一的发布和维护，主要为校内部门及个人提供数据开放服务。3.2.8.2.1.2数据集详细信息:数据集基本信息应包含：数据集名称、所属主题、数据来源、数据集文件类型、更新频率、发布时间、最后更新、更新频率、维护部门（可以是数据管理员所在的信息中心，也可以是数据源部门）、开放截止时间、描述。应支持有权限的用户可以查询、下载本数据集。3.2.8.2.1.3数据集标签:可通过标签过滤数据资源，应包含信息主题分类、来源部分分类、数据集文件类型、我的访问权限、时间排序、关键字搜索等功能。3.2.8.2.2其中数据接口中的信息应包括：3.2.8.2.2.1开放数据接口:数据接口为专业数据资源，平台应支持校数据中心为校内各部门数据负责人、系统厂商提供数据开放服务，数据接口应包括API接口、数据库表/视图、DCI下行数据，用户通过相关接口信息获取接口数据。3.2.8.2.2.2数据接口详细信息:应支持有权限的用户方可点击查看数据接口详细信息，需要包含API接口、数据库表/视图接口、数据交换下行接口数据。3.2.8.2.2.2.1下载接口说明文件: 应支持可预览/下载接口使用说明文件。3.2.8.2.2.2.2展示基本信息: 应提供基本信息展示，应包含：数据接口名称、所属主题、来源、开放对象、接口类型、发布时间、最后更新、更新频率、维护部门、描述、截止开放日期。3.2.8.2.2.2.3展示元数据: 应提供元数据展示，应包含：数据项名、数据项中文名、类型、长度、约束、值空间、解释/举例。3.2.8.2.2.2.4接口测试: 应支持用户填写自己的密钥，可以测试接口，接口按照元数据的内容展示该接口的前10条数据，并显示本接口此时共有多少条数据，让用户感受本接口的数据量。3.2.8.2.2.2.5接口参数: 应包含：接口地址，请示示例，token，返回参数，返回示例等。3.2.8.2.2.3数据接口标签:应支持可通过标签过滤数据接口，应包含：信息主题分类 、来源部门分类、我的访问权限、时间排序、关键字搜索、接口类型。3.2.9个人中心:个人中心中应包括我的资源、我的互动、上传资源、消息中心3.2.9.1我的资源:应可以查看我的API接口、我的文件、我的DCI接口、我的视图/表接口、数据应用等。3.2.9.1.1我的API接口应包括：数据开放接口、资产接口。数据开放接口、资产接口均应可查看接口名称、数据获取方式、开放状态、开放截止日期、启/禁用状态、资源获取路径、操作（接口测试、文件获取）、下载通用接口文档、应支持根据开放状态、数据获取方式和接口名称查询数据开放接口。3.2.9.1.2我的文件应包括：数据集、接口文件获取、数据资产。3.2.9.1.2.1数据集中应可以查看数据集名称、文件类型、文件生成时间、应支持文件下载操作。3.2.9.1.2.2接口文件获取应可查看文件名称、接口名称、文件生成时间、应支持文件下载操作。3.2.9.1.2.3数据资产应可查看资产名称、资产类型、文件生成时间、应支持文件下载操作。应支持根据资产名称、资产类型查询数据资产。3.2.9.1.3我的DCI接口应可查看DCI接口名称、数据来源、配置表名称、开放状态、开放截止日期信息。应可根据DCI接口名称、开放状态、数据来源查询DCI接口。3.2.9.1.4我的视图/表接口应可查看视图/表接口名称、数据来源、配置表名称、开放状态、开放截止日期信息。应可根据视图/表接口名称、开放状态、数据来源查询视图/表接口。3.2.9.1.5其中数据应用中的信息应包括：3.2.9.1.5.1数据应用主要开放账号的各类应用数据，应支持每个账号可以查询开放应用和本账号相关的数据，并进行纠错和填报工作。同时应支持部门数据、二级学院数据以同样方式提供开放服务，从而方便每次用户发起的数据应用需求。为了防止师生和部门到处找自己的数据，通过开放平台，支持点击预览本账号的官方维护数据功能，支持下载并复制使用这些数据功能，如果发现数据有误还支持通过平台反馈，从源头上提高数据质量。3.2.9.1.5.2数据应用详细信息:应支持有权限的用户方可点击查看数据应用详细信息。3.2.9.1.5.2.1展示基本信息:应提供基本信息展示，应包含：数据应用名称、所属主题、来源、开放对象、发布时间、最后更新、维护部门、描述、截止日期。3.2.9.1.5.2.2展示元数据:应提供元数据展示，应包含：数据项名、数据项中文名、类型、长度、约束、值空间、解释/举例。3.2.9.1.5.2.3数据预览功能: 应根据元数据展示该用户在此数据应用中的数据，不需要填写参数，每个用户仅能查看自己的数据。应支持可下载预览后的数据。3.2.9.1.5.3数据应用标签:应支持可通过标签过滤数据资源，应包含：信息主题分类、校内部门分类、时间排序、关键字搜索。3.2.9.2我的互动:我的互动界面应包括查看我的申请、我的收藏、我的上传等功能3.2.9.2.1我的申请：应支持查看相关数据集、数据接口、数据资产等申请审批情况。3.2.9.2.2我的收藏：应支持查看相关数据集、数据接口、数据资产等收藏情况。3.2.9.2.3我的上传：应支持查看相关数据集、数据接口、数据资产等上传审批情况。3.2.9.3上传资源:前台上传资源界面应支持根据提供资源名称、资源描述、信息目录分类、数据资源选择等信息提交上传资源。3.2.9.4消息中心:消息中心中应支持查看权限审批情况、登陆异常通知等。3.2.10资源库管理3.2.10.1资源库配置管理:应提供数据源添加、编辑功能，并且支持数据源状态监控。3.2.10.2资源库分类管理:应提供数据库分类管理功能，并且支持对数据库类型进行新增，分类名称、描述进行编辑及删除。3.2.10.3资源库元数据管理3.2.10.3.1元数据管理3.2.10.3.1.1应支持可以新增表；3.2.10.3.1.2应支持各表目录上可以删除、编辑表；3.2.10.3.1.3应支持每次编辑修改表格后提示要不要同步到资源库，如果不同步，下一次资源库自动同步把在系统上的修改冲掉，以资源库的实际情况为准；3.2.10.3.1.4应支持未同步表至资源库前可删除表，同步之后无法删除；3.2.10.3.1.5应支持通过不同类型表的命名前缀来区分元数据类别：数据接口、数据应用；3.2.10.3.1.6应支持待发布元数据下的表指已保存但是未同步至资源库的；3.2.10.3.1.7应支持数据项来源由数据管理员准备数据时填写，作为数据纠错重要使用字段；3.2.10.3.1.8应支持通过表名来分目录，表名如果没有注释，可以目录处右键注释；3.2.10.3.1.9应支持可以批量导入元数据、导出表格；3.2.10.3.1.10应支持批量编辑暂时可编辑数据项来源、信息主题。3.2.10.3.2脱敏后表页面:应支持可查看脱敏后表格以及字段，包括脱敏规则；并提供导出功能。3.2.10.3.3未识别表页面:应支持表名不符合规范的表显示在其它未识别表中，可以去修改数据表名系统自动同步到相应的目录中。3.2.10.3.4应支持资源库更新库结构后自动同步到元数据，同步资源库元数据到元数据管理界面，随时以资源库的元数据为准。3.2.11数据库管理3.2.11.1数据库配置管理3.2.11.1.1应支持配置数据库连接信息以及监控数据库可用状态以及连接情况。3.2.11.1.2新增数据源:配置连接信息，应包括数据源名称、数据库类型、数据库名、端口号、主机名、用户名、密码、状态。3.2.11.1.3账号配置:应支持服务提供账号配置，勾选提供服务的账号，可多选，提供全选功能；已选择的用户数据库不可线下直接删除，未选择的用户可直接删除；取消某账号时需判断是否有账号被授权过，若存在被授权则不可取消，不存在则可取消。3.2.11.1.4编辑数据源:可编辑项应包含：数据源名称，密码，状态；修改了以上字段后可点击测试连接测试是否可用，连接可用提示连接成功，连接不可用提示连接失败；连接失败或修改信息后不可连接时，提示连接异常，此次修改不进行保存。3.2.11.1.5删除连接:应支持删除连接前需要先禁用数据库连接状态，保证所有用户多无法访问时才能删除，删除时给出提示。3.2.11.1.6SQL查询:应支持可查询对应数据库提供服务的用户下的所有表数据，仅提供查询，不可修改；提供运行按钮，显示对应查询结果。3.2.11.1.7页面展示信息:应包含：数据源名称、主机名、数据库类型、连接可用性、状态、操作（查看、编辑、账号配置、禁用、删除、SQL查询）。3.2.11.2数据库用户管理3.2.11.2.1应提供用户管理以及权限配置界面。3.2.11.2.2新增用户:应支持新增用户填写包含该用户对应数据源名称、用户、密码、使用部门（下拉单选）、账号状态（默认显示启用）等信息。3.2.11.2.3查看用户:应支持只可查看用户信息，不可修改。3.2.11.2.4编辑:应支持编辑时只可修改密码，使用部门。3.2.11.2.5授权:应支持对每个用户授权表以及表的操作权限；先选表，每个用户下都有表和视图，表可多选，用户可多选，可搜索表/视图英文名称；勾选表后自动添加至配置权限列表，添加成功的表默认勾选读权限，管理员可勾选写权限。3.2.11.2.6禁用:应支持用户状态为启用时可禁用，反之亦然。3.2.11.2.7展示项:展示项应包含：数据源名称、主机名、用户名、授权对象数量、使用部门、账号状态、操作。3.2.11.2.8筛选条件应包含：数据源名称，用户名，账号状态。3.2.12开放建议3.2.12.1开放建议:应支持填写建议标题，建议类型，建议内容即可完成开放建议的新增；应支持提交后可在个人中心我的建议处查看自己提交的建议列表，数据管理员的回复可以在消息中心查看；应支持数据管理员定期整理开放建议给学校相关领导汇报。3.2.12.2开放建议回复处理:应支持通过处理状态、建议类型和搜索过滤，可审批/批量审批，点击审批可不填写回复意见，也可以自己模板上编辑进行自定义回复。3.2.13数据脱敏管理3.2.13.1数据脱敏处理:应支持系统对敏感数据即涉及到真实姓名、身份证号、手机号和家庭住址等信息的数据，在不违反系统规则的情况，对真实数据进行改造并提供测试使用，以防止个人信息和商业机密的泄漏。应提供不同脱敏方式加密数据，保证数据开放安全性，系统可根据需求自定义脱敏规则。3.2.13.2脱敏规则管理:管理系统内置规则（替换，掩码，随机数），应支持系统管理员自定义规则。管理员可新增、编辑、删除、禁用自定义规则，系统内置规则不可操作，只允许查看。应支持新增规则时需要填写：脱敏方式、描述、上传jar包、状态（默认启用）；自定义脱敏规则若需要删除，需要先禁用，禁用时需保证未使用，若有字段正在使用该种脱敏方式脱敏，则给出提示。列表展示应包含：序号、脱敏规则名称、描述、状态、是否自定义、操作（编辑、禁用、删除）。筛选条件应包含：状态、是否自定义、脱敏规则名称。3.2.14数据资源配置管理3.2.14.1数据集列表3.2.14.1.1数据资源状态:状态应包含：已发布指正在开放状态下的数据资源、已停用指曾经发布然后停用后的数据资源、已停用的数据资源还可以再编辑后再发布，草稿指的是待编辑数据资源。删除后则从数据开放平台中删除数据资源信息。3.2.14.1.2数据资源列表:应支持可根据数据资源名称进行搜索，对于已发布的数据资源可以查看数据资源名称，数据资源来源、开放对象、最后更新时间，数据集操作可以先停用后再进行编辑或者删除，编辑后可以发布；也可以多选全选进行批量停用、批量发布、批量删除等操作。3.2.14.1.3数据集相关统计:应提供下载次数、访问次数、被申请次数、被收藏次数等统计。筛选条件：包含数据集状态，发布时间，数据资源名称。应支持列表展示系统默认按照发布时间降序排列。应支持对已停用的数据资源不显示在用户的收藏列表中。3.2.14.2数据应用列表:数据资源状态应包含：已发布指正在开放状态下的数据资源、已停用指曾经发布然后停用后的数据资源、已停用的数据资源还可以再编辑后再发布，草稿指的是待编辑数据资源。删除后则从数据开放平台中删除数据资源信息。应支持可根据数据资源名称进行搜索，对于已发布的数据资源可以查看数据资源名称，数据资源来源、开放对象、最后更新时间，数据集操作可以先停用后再进行编辑或者删除，编辑后可以发布；也可以多选全选进行批量停用、批量发布、批量删除等操作；应支持同时显示数据应用相关统计包含：预览次数、纠错次数、访问次数、被下载次数、被收藏次数。3.2.14.3数据接口列表:数据资源状态应包含：已发布指正在开放状态下的数据资源、已停用指曾经发布然后停用后的数据资源、已停用的数据资源还可以再编辑后再发布，草稿指的是待编辑数据资源。删除后则从数据开放平台中删除数据资源信息。应支持可根据数据资源名称进行搜索，对于已发布的数据资源可以查看数据资源名称，数据资源来源、开放对象、最后更新时间，数据集操作可以先停用后再进行编辑或者删除，编辑后可以发布；也可以多选全选进行批量停用、批量发布、批量删除等操作。同时显示数据接口相关统计应包含：调用次数、访问次数、被申请次数、被收藏次数。应支持列表展示系统默认按照发布时间降序排列。应支持已停用的数据资源不显示在用户的收藏列表中。3.2.14.4动态资产开放管理:应支持动态资产开放管理，应支持查看资产名称、子接口数量、资产状态、资产创建时间、审核层数、操作，应支持自定义列功能。3.2.14.5静态资产开放管理:应支持静态资产开放管理应支持查看资产名称、申请人数、下载次数、资产状态、资产创建时间，应支持自定义列功能。3.2.15数据资源申请处理3.2.15.1数据集申请列表:应支持可通过申请时间、审核状态、开放状态、数据集名称、申请人信息实现过滤。应支持数据集访问申请处理方式有两种，选择同意后该用户ID将自动加入到可访问用户列表，选择不同意则无变化；可批量同意或者不同意；如同意给申请人提供脱敏数据集或者其它数据集代替，可做自定义回复。3.2.15.2数据接口申请列表；应支持通过申请时间、审核状态、开放状态、数据获取方式、数据接口名称、申请人信息实现过滤。应实现数据集访问申请处理方式有两种，选择同意后该用户ID将自动加入到可访问用户列表，选择不同意则无变化；如同意给申请人提供脱敏接口，可做自定义回复。3.2.15.3应支持查看数据资产申请列表。应支持通过动态数据资产/静态数据资产、申请时间、审核状态、数据获取方式、数据接口名称、申请人信息实现过滤。应实现数据资产访问申请处理方式有两种，选择同意后该用户ID将自动加入到可访问用户列表，选择不同意则无变化；可批量审核通过/不通过；如同意给申请人提供脱敏数据资产，可做自定义回复。3.2.16平台用户上传资源管理3.2.16.1应支持通过审核状态、资源类型、资源主题和上传时间、搜索关键字等方式过滤页面；页面主要显示用户上传数据资源详细情况列表，数据管理员可以审核，审核是否同意开放，选择同意开放：文件将放入文件系统进行管理；选择不同意开放：文件将被系统自动删除，可自动填写审批意见回复；若未填写审批意见，则默认发送系统模板。3.2.16.2应实现可全选或者部分选择进行批量处理同意开放，批量不同意开放，批量回复。3.2.16.3可导出页面显示的表格数据；3.2.16.4应支持详情展示字段应包含：资源名称、资源类型、资源主题、资源格式、上传人姓名、上传时间、审核状态、审核结果、资源描述、上传人角色、上传人部门、处理时间。3.2.17平台配置管理3.2.17.1资产页面授权管理:主要用于数据资产页面授权，应支持新增用户，取消授权，查看信息等操作。3.2.17.2信息目录管理:应支持新增信息目录、编辑信息目录、删除信息目录等操作。3.2.17.3政策资源管理:主要用于管理员管理游客界面的数据开放政策，应包括开放政策的查询，新增，删除。查询时显示内容应包含：序号，政策名称，上传时间，操作。新增需要输入信息应包含：政策名称，上传文件；名称必填，文件不能为空。删除：应支持可通过选择复选框删除政策，可多选。下载：应支持点击后可下载对应文件。3.2.17.4术语解释管理:主要用于全量数据开放服务系统中常见的名词术语解释管理，支持查看、编辑、删除操作。3.2.17.5常见问题管理:主要用于全量数据开放服务系统中常见的问题及回答管理，支持查看、编辑、删除操作。3.2.18消息中心:应支持所有平台的消息，通过消息中心发送，列表展示；可以通过消息类型等进行过滤，搜索过滤等，根据时间排序。3.2.19系统管理: 系统管理应包含组织结构管理、个人用户管理、系统用户管理等功能。3.2.19.1组织机构管理:应支持院系机构树状结构图（主要分两部分：职能部门展示到二级部门、教学单位展示到班级），单位基本信息展示列表，管理员可以修改、删除单位信息，可导出显示的表数据，可通过单位名称关键字搜索。3.2.19.2个人用户管理:应支持统一管理数据开放平台用户，具有添加用户、修改用户、删除用户等功能。3.2.19.3系统用户管理:应提供系统用户列表，主要管理平台系统管理员和平台数据管理员账号。应支持系统管理员可以查看、编辑用户信息，重置密码，删除用户。4一表通平台:一表通平台可以实现状态数据的全方位采集，采取一人一码、定时填报的方式，全方位采集状态数据。为学校建立一套贯穿于各院系师生状态数据采集及状态数据的统计业务智能化服务模式，建立面向长期发展的技术队伍和保障体系，保证资源和服务的可靠性、安全性、科学性，满足学校的长期持续发展对信息采集的需求。并且借助“一表通”可以提升全量数据中心填充率，通过一表通实现全量数据中心状态数据纠错业务，推进数据治理落地。一表通系统需支持填报功能，协同数据填报、灵活的统计公式，对单元格数据进行校验；主要定位于收集尚未纳入任何业务系统的、临时性的数据需求，可以是面向教职工的，也可以是面向学生的。4.1技术性需求4.1.1基础性需求4.1.1.1平台必须采用三层结构设计，包含数据层、业务逻辑层、表示层，具有“高内聚低耦合”的特点。4.1.1.2平台应采用异步通信框架，并兼容多终端不同尺寸显示器和主流浏览器。4.1.1.3采用微服务架构，具有稳定性、持续性，保证质量。4.1.1.4平台应包含用户管理，权限控制（页面和操作权限），数据源管理、日志记录等，为学校提供完善的服务。4.1.2其他需求4.1.2.1平台需具备细粒度的用户及权限配置功能，面向多种角色、应包含校园教职工、学生、校友、家长、合作企业、社会公众人士，有参与学校数据填报业务需要的所有人员，均可完成相关数据的填报审核。4.1.2.2平台需支持自定义表单、自定义业务审核流程。4.1.2.3平台需支持数据填报，数据展示，数据纠错，自定义数据来源，自定义填报数据去向。4.1.2.4平台应采用在线Excel的交互模式，在表单定义及用户填报端灵活进行配置。4.1.2.5平台支持微服务架构，实现业务模块的松耦合，能够更加适应各种业务场合。4.1.2.6平台需具备附件上传功能，应包括Excel、word、pdf、zip、jpg等文件格式。4.2功能性需求4.2.1基础功能4.2.1.1平台需具备多种登录认证方式，应包含账号密码登录、单点登录；支持滑动验证，密码账号的异常提示，设置5天内记住密码，支持首次登录绑定信息。4.2.1.2平台需支持多种密码找回方式，支持验证码人机校验，支持通过手机短信验证码和邮箱验证码找回。4.2.1.3系统首页需支持对代办事项的提醒，可标记已读、未读；在同个界面可查看已办活动以及发起的活动。4.2.1.4数据填报需具备填报分类功能，可分为任务填报、日常填报，用户可根据自己需求，选择需要填报的活动。用户能在首页界面看到已填和未填的活动，并选择进行填报、查看历史填报、填报结果查看等操作。4.2.1.5账户设置:系统支持用户对手机、邮箱进行绑定，支持登录日志查看，保证账号信息的安全。支持修改密码功能，应包含通过手机、邮箱进行密码的验证。4.2.2数据填报4.2.2.1首页:应提供分类展示填报表单页面，用户可快捷定位填报表单；要求展示活动填报清单及填报状态、审核状态等；应支持用户把自己常用的填报、报表自定义添加到首页，方便用户使用的功能。应支持我的消息功能，支持展示消息中心、填报任务、催填功能发出的消息，便于用户整体查看所有的消息信息。应支持展示用户待审核工作任务、待填报工作任务的功能；应支持我的已办模块功能，支持展示用户以及审核的工作任务明细及详细情况；要求我的发起模块的功能，支持展示自己发起的填报单据明细（日常填报与任务填报）；要求填报时可进行流程查看、暂存功能；要求填报表单数据可从数据中心自动加载，历史填报过的数据可直接加载，来源于业务系统的数据一般为不可编辑状态；应支持我的待办任务查看，我的已办任务查看，我的发起任务查看，同时支持标记已读和标记未读；支持常用功能模块添加应用，可添加任务填报、日常填报、个人数据中心、部门数据中心、学校数据中心。应提供相应的机制来对采集填报的数据回流到学校数据中心。4.2.2.2任务填报:应支持任务填报功能，任务查询功能，要求支持集中展示未填报/完成/审核中/撤回状态的任务。应支持填报表单以Excel表的形式进行展示，填报过程支持查看流程、下载全部表单、下载当前表单、表单暂存。应支持填报过程中的控件选择，包括撤销/重做，格式刷、小数位数的增加减少、文本/数字/百分比/日期/时间/货币等自定义格式的设置；同时支持设置字体/单元格颜色、图片插入功能；还需支持表单中的公式，包括求和/平均值/计数/最大值等函数的设置。应提供导入功能，支持Excel文件的上传，模板下载。应支持数据查重，设置查重匹配列。应支持查看审核中任务填报表单情况，以时间轴的方式查看审批中发起人、审核人、审核的具体时间、耗时，以及审核的状态。应支持流程查看，以流程图的方式查看审核状态，还在审核中的状态支持以闪烁的形态进行展示和提示。同时应支持对流程查看图的放大/缩小/居中显示，支持鼠标缩放。4.2.2.3日常填报:提供日常填报功能，应支持日常填报总数量的统计，已填报次数的统计，审批中的填报数量统计，填写分布统计、填写情况统计。应支持日常填报功能并对日常填报的内容进行搜索；应以树菜单的方式对日常填报进行分类展示；应支持对日常填报情况查看，审核情况的展示，支持对审核情况进行筛选查看，审核状态应支持清除/暂存/撤回/退回/通过/未通过/撤销。支持表单下载，下载全部、下载当前，查看流程，暂存流程。4.2.2.4填报记录:应支持对填报记录的查询，包括已提交过的任务填报和日常填报及其审核状态，支持可撤回还未审核的表单，可编辑撤回、退回的表单。支持查看填报详情。应支持对撤回的表单进行重新编辑操作。应支持对任务填报/日常填报的查询，可按照发起时间范围进行查询。选择查看填报结果，支持对填报内容进行打印/下载全部/下载当前。4.2.3数据中心4.2.3.1个人数据中心:应支持以树菜单的方式按照业务进行分类，应支持对树菜单内容的自定义分类，可分为教务、人事、科研等。人事相关数据查询例如包括个人基本信息、职称信息、家庭成员、学习经历、工作经历、荣誉获奖、专任教师等，根据学校数据中心的数据以及一表通采集的数据进行配置和展示。要求支持在个人数据中心查看个人有关信息，对有异议的数据进行纠错，或对数据进行补录、删除维护、并上传证明材料。应支持纠错，应支持按展示数据表样提交纠错信息，按照字段确权分类（字段分类中的自定义审批流程）流转纠错数据审核流程；支持纠错数据审核提供辅审信息，并能自定义授权可见与不可见的上下文信息（字段）；应支持纠错、补录、删除后在审核完成前有相应颜色标识；应支持数据展示纠错面板可拉伸、收缩。应支持纠错记录查询，查询纠错信息、明细补录信息、明细删除信息；明细补录和明细删除必须支持对确权部门信息的记录，能够通过审核状态进行筛选查询。应支持查看数据维护记录，应支持用户在本模块查询自己已提交的全部纠错、补录、删除及审核状态；应支持进度，记录，结果；应支持数据与新纠错流程对接。纠错完成后，支持返回表单，并支持打印表单、下载全部和下载当前表单。4.2.3.2部门数据中心:应支持以树菜单的方式按照业务进行分类，应支持对树菜单内容的自定义分类，可分为教务、人事、科研等。人事相关数据查询例如部门人力统计、部门基本信息-人员清单等，根据学校数据中心的数据以及一表通采集的数据进行配置和展示。应支持纠错，应支持按展示数据表样提交纠错信息，按照字段确权分类（字段分类中的自定义审批流程）流转纠错数据审核流程；支持纠错数据审核提供辅审信息，并能自定义授权可见与不可见的上下文信息（字段）；应支持纠错、补录、删除后在审核完成前有相应颜色标识；应支持数据展示纠错面板可拉伸、收缩。要求支持在部门数据中心查看部门有关信息展示，对有异议的数据进行纠错，或对数据进行补录、删除维护、并上传证明材料。应支持纠错记录查询，查询纠错信息、明细补录信息、明细删除信息；明细补录和明细删除必须支持对确权部门信息的记录，能够通过审核状态进行筛选查询。应支持查看数据维护记录，应支持用户在本模块查询自己已提交的全部纠错、补录、删除及审核状态；应支持进度，记录，结果；应支持数据与新纠错流程对接。纠错完成后，支持返回表单，并支持打印表单、下载全部和下载当前表单。4.2.3.3学校数据中心:应支持以树菜单的方式按照业务进行分类，应支持对树菜单内容的自定义分类，如：绩效考核后，可放置各学院各部门的水平分报表；学校各学院总揽情况的报表等，根据学校数据中心的数据以及一表通采集的数据进行配置和展示。应支持纠错，应支持按展示数据表样提交纠错信息，按照字段确权分类（字段分类中的自定义审批流程）流转纠错数据审核流程；支持纠错数据审核提供辅审信息，并能自定义授权可见与不可见的上下文信息（字段）；应支持纠错、补录、删除后在审核完成前有相应颜色标识；应支持数据展示纠错面板可拉伸、收缩。要求支持在学校数据中心查看学校概况信息，对有异议的数据进行纠错，或对数据进行补录、删除维护、并上传证明材料。应支持纠错记录查询，查询纠错信息、明细补录信息、明细删除信息；明细补录和明细删除必须支持对确权部门信息的记录，能够通过审核状态进行筛选查询。应支持查看数据维护记录，应支持用户在本模块查询自己已提交的全部纠错、补录、删除及审核状态；应支持进度，记录，结果；应支持数据与新纠错流程对接。纠错完成后，支持返回表单，并支持打印表单、下载全部和下载当前表单。4.2.3.4由于一表通平台包含了很多关键性数据，数据安全影响比较大，要求有完善的身份鉴别方式来保障平台数据的安全性，解决以往单一应用服务器下的安全策略无法满足企业级数据平台的安全访问要求。4.2.4审核4.2.4.1填报审核:系统应支持对任务填报和日常填报进行审核，保证任务和日常填报的数据符合要求；审核人员可查看与自己相关的活动填报和模板填报的审批列表，并支持审批功能；要求审批表单页面进行上一个、下一个、同意、不同意、填写说明、打印、下载预览附件操作；要求对部分审批人员可设置批量审批的功能；要求可通过提交时间筛选，并支持按照表单名称进行搜索的功能；应支持对已审核的表单进行查看的功能，并支持审批撤回的功能。4.2.4.2填报审核记录:应支持对填报审核记录的查看，包括任务的处理时间、到达时间、岗位、所属机构筛选、审核寄过等查看，并支持查看和撤回操作，同时应支持批量撤回操作。要求支持转发撤回，查看转发人/转发对象。4.2.4.3纠错审核:纠错待审核：应支持审核纠错数据，查看已审核纠错、进度；应支持数据行补录、删除时打包审核，如果数据行字段在不同分类，则数据都可以看到，先审核有效；纠错审核记录：应支持用户在本模块查询由本人已审核过的纠错、补录、删除。填报审核：应支持任务填报、日常填报的审核列表，操作：批量审核、审核，查询，按时间筛选、搜索应支持审核转发功能、列表中能查看转发人。4.2.5消息中心4.2.5.1应提供消息发布功能。具有权限的用户可以在自己权限范围内发布消息，发布消息时支持管理系统填报表单与展示报表；消息支持系统内消息，系统外消息（邮件、短信），普通用户收到消息可以直接在消息中打开关联的表单与报表。在前台首页展示我的消息，应支持消息提示，具有消息数量提示以及弹窗提示，可通过快捷链接快速填报或查看展示；应提供消息列表展示，便于用户查看接受的所有消息。消息列表管理：应支持对所有发布的消息进行统一的管理，并记录发布的状态；应支持查看消息和预览消息；应支持撤回消息；应支持对消息标题及内容进行编辑，同时支持对消息的内容进行调整，调整控件至少包括消息内容的加粗、背景颜色的设置、字体设置、上标/下标设置。要求提供消息对象的设置，应支持选择填报/报表和自定义两种方式。4.2.6表单管理:表单管理是一表通活动构建中系统与用户进行交互的最重要的元素，因此，表单设计中首先要实现表单的灵活配置，通过表单的配置可以全面地定义支撑填报活动的数据和输出样式。应提供表单的在线配置与管理功能。需支持表单设计器自定义表单的样式、内容、填报控件、数据绑定；表单设计器应是一个类似Excel的web设计器，操作便捷。4.2.6.1需具备表管理功能：支持表单复制新增功能，节省大量的同类表单设计时间。需具备可视化表单设计功能，支持表单与表格两种模式。支持自定义设计表单、表格样式；需支持电子表格样式导入功能；支持表单预览；单元格格式设置：应支持常规、日期、文本、数值、时间设置。数据绑定：应支持拖拽绑定字段。数据列过滤：应支持自定义过滤条件编辑，支持条件逻辑组合（and、or、括号），条件操作符支持大于、大于等于、小于、小于等于、包含、不包含、等于、不等于。数据