MH／T 5055-2021  智慧民航数据治理规范数据架构

3民航数据架构一般要

3民航数据架构一般要求

3.0.1民航数据架构建设应识别业务流程中所依赖的数据及数据流，注重不同业务间数据的复 用与共享，统一业务数字化时所需的数据语言及操作手段。应用系统的设计和开发应依据数据 架构。数据架构在民航业务数字化中的作用如图3.0.1所示。 【条文说明】数据架构是业务与应用系统建设的桥梁：数据架构基于业务架构（业务模式、流 程、规则等）识别出业务数据需求，通过统一数据语言及操作手段，作为应用系统的应用架构 （系统功能、组件、接口等）和技术架构（技术指标、技术选型等）设计和开发的依据。

ppp3.0.2民航数据架构建设重点应包括以下内容

图3.0.1民航数据架构在业务数字化中的作用

1数据资产目录编制：厘清本单位的数据信息资源，支撑数据标准、数据模型、元数据与 主数据管理； （条文说明】本规范中“单位”指民航行业各级行政主体、企业、直属单位和行业协会等组织。 2数据标准管理：规范业务对象在信息系统中的定义和应用，支撑数据使用和交换的一致 性和准确性；

3数据模型构建：对民航业务模式和业务规则的数据需求进行分析和重新组织，支撑应用 系统设计和开发； 4元数据管理：规范数据业务属性、技术属性、操作属性，支撑业务在信息系统中落地； 5主数据管理：保持系统间核心业务数据的一致性，支撑跨部门、跨系统的数据融合与 应用。

4元数据管理：规范数据业务属性、技术属性、操作属性，支撑业务在信息系统中落地； 5主数据管理：保持系统间核心业务数据的一致性，支撑跨部门、跨系统的数据融合与 应用。 3.0.3民航数据架构建设应符合下列基本原则： 1数据架构规划应符合本单位业务战略，基于业务对象进行设计和实施； 2在数字化转型过程中应不断对数据架构进行审视和优化，满足适当的、差异化的数据 需求； 3数据架构的设计应考虑行业实践和主流软硬件技术，兼顾发展现状和未来趋势； 4应用系统数据库的设计和开发应遵循数据架构，减少数据穴余，实现接口标准化； 5业务数据责任人应会同信息技术支撑组织进行所辖业务数据架构的建设和维护。 【条文说明】数据责任人是指基于数据的业务属性负责数据治理责任的个体，包括最高数据责任 人、领域数据责任人、业务数据责任人。信息技术支撑组织是指本单位为数据治理工作提供信 息技术支持的组织或部门

3.0.3民航数据架构建设应符合下列基本原贝

数据兴学属生友安全唐 进行数据项分类。 1.1.2数据资产目录的范围应根据本单位业务需要进行设定，包括但不限于民航资源类、安全类 运行类、服务类、经济类等具有业务价值的数据，以及接口类、日志类等信息系统的支撑数据

4.1.1民航数据资产目录应基于数据业务属性进行数据项分层，基于数据共享属性及安全属性 进行数据项分类

4.1.2数据资产目录的范围应根据本单位业务需要进行设定，包括但不限于民航资源类、安全类 运行类、服务类、经济类等具有业务价值的数据，以及接口类、日志类等信息系统的支撑数据

4.2数据资产目录分层分类

.1数据资产目录分层结构（以机场运行安全事件为例

1领域：领域层是描述本单位数据管理的最高层级分类，宜基于业务管理边界进行数据划 分，将该领域下的数据资产与对应的业务领域流程架构、业务领域责任人相匹配； 2业务域：业务域应是领域下一组密切相关的业务对象集合，各业务域的数据应互不重 叠，同一业务域数据宜由相同的业务数据责任人负责； 3业务对象：业务对象定义业务域重要的人、事、物，数据架构与业务架构、应用架构 技术架构的集成应围绕业务对象开展； 4逻辑数据实体：逻辑数据实体是具有一定逻辑关系的数据属性集合，应描述一个业务对 象的某方面特征； 5属性：属性是数据架构的最小颗粒，应描述业务对象某个特征的数据性质。 【条文说明】图4.2.1示意的数据资产目录结构分为5层，各单位结合本单位数据资源具体情 况，兼顾数据资产与管理层级的对应关系，情选取以上5层中全部或部分层级进行划分

1按照数据项共享属性分类，应包括无条件共享、有条件共享、不予共享3种类型，可提 共给本单位所有部门共享使用的数据，属于无条件共享类；可提供给部分部门共享使用或仅能 够部分提供给所有部门共享使用的数据，属于有条件共享类；不宜提供给其他部门共享使用的 数据，属于不予共享类； 2按照数据项安全属性分类，应采用规范、明确的方法区分数据的重要性和敏感程度差 异，确定数据安全级别，对数据资源属性按数据安全级别要求进行编制，并根据数据安全级别 确定数据在其生命周期的各个环节应采取的数据安全防护策略和管控措施

4.3.1数据资产编码应符合下列原则

1统一性原则：单位内部应使用一套数据资产编码，支持不同业务部门及信息系统之间的 数据交换； 2唯一性原则：每个数据资产应使用唯一的数据资产编码进行标识，同一个编码只对应同 个数据资产； 3可读性原则：编码应具备可读性，协助使用者判断数据对应的数据资产类型； 4扩展性原则：编码长度应能适当扩展，同时不影响编码体系

4.3.2数据资产编码应与数据资产目录的分层结构对应，宜采用五级编码，分别为：领域、业 务域、业务对象、逻辑数据实体、属性。每级编码可采用不定长度的数字或英文字母，不同级 别编码之间通过下划线区分。编码结构如图4.3.2所示

图4.3.2数据资产目录编码结构示例

4.4数据资产目录编制流程

4.4.1目录编制前期准备阶段宜包括下列工价

4.4.4目录维护更新阶段，信息技术支撑组织应负责数据资产目录管理平台的建

5.1.1数据标准应包括下列基本内容： 1数据技术属性：包括数据项的名称、数据编码规则、数据类型、数据格式、数据更新频 率等，用于指导数据在应用系统中的实施； 2数据业务属性：包括数据项的业务定义、业务规则、数据来源、数据使用部门、数据质 量规则等，用于统一业务侧语言和理解； 3数据管理属性：包括数据的存储位置、管理部门、管理岗位、数据标准的生效日期和失 效日期等，用于明确数据标准管理的责任主体和管理指标。 5.1.2数据标准一般分为基础数据标准和指标数据标准，基础数据标准的对象是业务流程中直 接产生的、未经加工和处理的基础业务数据，指标数据标准的对象是具备统计意义的指标数据。 各单位可根据自身业务领域进行细分，如图5.1.2所示（以航空公司为例）

数据标准应包括下列基本

图5.1.2基础数据标准与指标数据标准（以航空公司为例）

5.2数据标准管理流程

标准评估改进。数据标准管理流程如图5.2.1所

5.2.2标准规划与申请阶段宜开展下列工作

图5.2.1数据标准管理流程

1调研规划：数据管理组织宜从本单位业务运行、国家和民航相关数据标准、信息系统数 据现状3个方面开展数据标准调研工作，并结合调研结果制定年度或者中长期的数据标准体系 管理的相关计划，调研内容宜包括数据业务含义、数据标准分类、数据项属性规则以及数据描 述等； 2指定职责：数据管理组织应明确数据标准管理工作的相关部门及其职责； 3提出标准申请：各业务数据责任人提出数据标准新增、修改、删除的申请，相关领域数 据责任人和数据管理组织审核

5.2.3标准制定阶段宜开展下列工作：

1分析现状：业务数据管理组织依据业务调研和信息系统调研结果，分析归纳数据标准现 状和问题，厘清实际生产中数据的定义方式和对业务流程、业务协同的影响； 2形成标准初稿：业务数据管理组织梳理相关业务数据标准范围，确定业务属性、技术属 性、管理属性，形成初稿

5.2.4标准审核发布阶段宜开展下列工作

1意见征询：数据管理组织收集相关业务部门、信息技术部门的意见； 2论证审议：业务数据管理组织根据意见征询结果对数据标准修订完善后提交数据标准工 作组审议：

3批复发布：数据标准通过数据标准工作组论证审议后，由数据管理组织审批发布 5.2.5标准落地执行阶段宜开展下列工作： 1宣讲培训：数据管理组织按照业务条线和技术条线，组织业务数据管理组织对相关人员 进行数据标准的培训和宣讲； 2推动执行：业务数据管理组织分析数据标准要求与现状的实际差异，确定标准执行方案 和计划，推动数据标准在相关业务系统中落地。

5.2.6标准评估改进阶段宜开展下列工作：

1跟踪、评估成效：业务数据管理组织评 地的实施成效 流程执行情况，收集标准修订需求，将存在的问题上报数据管理组织： 2标准维护、更新：标准变更包括需求收集、需求评审、变更评审、发布等，业务数据管 理组织应对标准修订进行版本管理，使数据标准“有迹可循”； 3标准废止：数据管理组织应依规废止无应用对象的数据标准。

1数据结构应描述数据的类型、内容、性质，以及数据之间的联系； 2数据操作应定义在相应数据结构上的操作类型和操作方式； 3数据约束应描述数据库中数据结构之间的语法、词义联系，以及彼此之间的约束关系。 6.1.2数据模型建设任务应包含以下内容： 1全面梳理本单位的应用系统数据现状，分析相关方的数据需求，包括但不限于：系统应 用需求、内部组织战略和合规需求、行业监管需求、跨机构互联互通需求； 2建立一套本单位共同遵守的数据模型设计开发规范，指导本单位数据模型的开发和 管理； 3建立和维护单位级数据模型和应用系统级数据模型，使用单位级数据模型指导应用系统 级数据模型的设计，并设置相应的角色进行管理； 4使用单位级数据模型指导和规划本单位的信息系统建设； 5建立单位级数据模型和应用系统级数据模型的映射关系，并根据系统的建设定期更新数 据模型。

6.2.1数据模型设计宜采用概念数据模型、逻辑数据模型、物理数据模型三层模式进行设计 三层数据模型对比如表6.2.1所示

表6.2.1三层数据模型对比表

6.2.2概念数据模型应描述业务对象及业务对象之间的关系。概念数据模型如图6.2.2所示 （以旅客订票为例）。 【条文说明】概念数据模型是面向客观世界的模型，主要描述现实世界的概念化结构，与具体的 数据库管理系统不直接相关

图6.2.2概念数据模型（以旅客订票为例）

6.2.3逻辑数据模型应以概念数据模型为基础，描述业务规则下的逻辑数据实体关系，指导数 居在数据库中的落地，包括网状数据模型、层次数据模型等。逻辑数据模型如图6.2.3所示 （以旅客订票为例）

图6.2.3逻辑数据模型（以旅客订票为例）

6.2.4物理数据模型应按照规则将逻辑数据模型中定义的逻辑数据实体、属性、属性约束、关 系等内容，如实转换为数据库软件能识别的物理数据实体关系。 （条文说明】物理数据模型是一种面向计算机物理表示的模型，描述数据在存储介质上的组织结 构。物理数据模型与具体的数据库管理系统、操作系统和硬件有关，同时考虑系统性能的相关 要求。

6.3.1概念数据模型设计应重点定义数据的业务需求。逻辑数据模型设计应重点定义实体与实 体之间的关系。物理数据模型设计应考虑技术实现因素，进行数据库体系结构设计。 【条文说明】逻辑数据模型设计在数据模型框架中起着承上启下的作用，是连接业务对象与计算 机物理表示的桥梁

1业务对象与逻辑数据实体的关系应一对一或一对多，不应多对一。 【条文说明】逻辑数据实体不能脱离业务对象独立存在，因此逻辑数据实体描述一个特定的业务 对象。 2描述业务对象不同业务特征的密切相关的属性集合，可设计为一个逻辑数据实体。

【条文说明】描述同一业务对象不同业务特征的属性，如果密切相关则可设计为一个逻辑数据实 体，以减少余。 3逻辑数据实体设计宜遵循第三范式。设计同一个业务对象的逻辑数据实体时，每个逻辑 数据实体的属性不宜重复定义，不宜包含其他逻辑数据实体中的非关键字类型的属性。 4提供数据服务或跨业务领域使用的基础数据时，应单独设计逻辑数据实体。当业务对象 的若干属性能够组合起来形成有价值的数据服务时，可设计成一个逻辑数据实体。 5两个业务对象间的关系可设计成关系型逻辑数据实体。 【条文说明】关系型逻辑数据实体在数据资产目录中，按业务发生的时间先后顺序，归属于后出 现的业务对象

6.4.1信息系统建设和运行维护过程中，应审核新建数据模型，对数据模型进行标准化管理和 统一管控

6.4.2数据模型管理包括但不限于以下内容：

6.4.2数据模型管理包括但不限于以下内容

1数据模型设计：应设计标准化的数据模型，支持对新建系统的正向建模能力和对原有系 统的逆向工程能力，数据模型设计应与企业架构保持一致，提高单位内部数据的一致性： 2模型差异稽核：应对数据模型与应用数据库进行稽核对比，保障数据模型设计与实现的 致性，可针对数据库表结构、关系等的差别形成差异报告，辅助数据模型管理人员监控数据 模型质量间题，提升数据模型设计和实施质量； 3数据模型变更管控：宜对数据模型设计、提交、评审、发布、实施到消亡的全过程进行 变更管理； 4建设数据模型管理工具：宜建设单位内部统一的数据模型管理工具，支撑多系统、多业 务并行协作的数据模型管理

7.1.1民航元数据分类宜包括业务元数据、技术元数据和操作元数据，具体内容如下： 1业务元数据：描述数据系统中业务领域相关概念、关系和规则的数据，包括业务术语 信息分类、指标、统计口径等； 2技术元数据：描述数据系统中技术领域相关概念、关系和规则的数据，包括物理模型的 表与字段、ETL规则、集成关系等； 3操作元数据：描述数据处理日志及运营情况的数据，包括系统执行日志、访问记录等。 条文说明）业务元数据举例：如针对机场基础信息数据，其标识信息、数据质量与精度信息 空间参照信息、发布与更新信息、负责单位与联系信息等均构成描述该机场基本数据（机场代 码、坐标等）的业务元数据。技术元数据举例：如针对机场旅客静态图像数据，其基本数字对 象（对象标识符、文件大小、字节序列、压缩类别等）、基本图像信息、图像捕捉元数据、图像 评估元数据（空间度量、图像色彩编码等）等构成描述该数据的技术元数据。 7.1.2元数据管理应制定元数据标准、管理规范、管理平台与管控机制，并通过全流程（产 主、采集、注册和运维）的元数据管理，实现元数据应用。元数据管理体系架构如图7.1.2 所示。

图7.1.2元数据管理框架

7.2.1民航元数据管理流程宜包产生元数据、采集元数据、注册元数据和运维元数据：

1产生元数据：应制定元数据管理相关流程与规范的落地方案，在信息系统开发过程中实 现业务元数据与技术元数据的连接； 2采集元数据：应通过统一的元模型从各类信息系统中采集元数据； 3注册元数据：应制定元数据注册方法，完成数据资源池的元数据注册工作： 4运维元数据：宜通过建立元数据中心，管理元数据产生、采集、注册的全过程，实现元 数据运维

7.2.2产生元数据应符合下列要求！

1明确业务元数据、技术元数据和操作元数据之间的关系，定义元数据模型，元数据模型 示意如图7.2.2所示

图7.2.2元数摄模型

1）业务元数据设计原则：一个领域下可有多个业务域，一个业务域下可有多个业务对象， 个业务对象下可有多个逻辑数据实体，一个逻辑数据实体下可有多个属性，一个属性应对应 个数据标准，每个数据标准可被一个或多个属性引用，每个属性应归属于一个逻辑数据实体 每个逻辑实体应归属于一个业务对象，每个业务对象应归属于一个业务域，每个业务域应归属 于一个领域： 2）技术元数据设计原则：物理表设计应满足第三范式；物理表、视图和字段的设计应基于 用途进行分类；承载业务用途的物理表、虚拟表、视图应与逻辑实体一一对应，承载业务用选 的字段应与属性一一对应； 3）操作元数据设计原则：宜按日志目的进行分类设计。 【条文说明】业务元数据设计原则与数据资产目录分层结构对应。 7.2.3采集元数据是从各数据源（生产系统、信息技术平台等）获取元数据，对元数据进行转 换，并写入元数据中心的过程，采集元数据流程如图7.2.3所示，应符合下列要求： 1选择适配器：应针对不同的元数据来源，选择相对应的适配器及元模型； 2配置数据源：应在确定数据源所选择的适配器类型、适配器版本、元模型的基础上，配 置数据源的名称、连接参数和描述； 3配置采集任务：宜设置自动调度的工作单元，为元数据的采集提供自动化、周期性、定 时的触发机制，

图7.2.3采集元数据流摄

7.2.4注册元数据宜按元数据准备度评估、元数据连接和注册发布3个步骤进行（如图7.2.4 所示），宜符合下列要求： 1准备度评估包括但不限于以下要点：信息系统名称是否符合本单位标准，数据资产目录 是否经过评审并正式发布，数据责任人是否确定数据密级，物理表、虚拟表、视图名是否合规； 2元数据连接应符合：逻辑实体和物理表、虚拟表、视图一对一连接，业务属性与字段

对一连接； 3对于增量元数据注册：应在信息系统设计与开发过程中落实元数据相关规范，确保系统 上线时完成业务元数据与技术元数据连接，通过元数据采集器实现元数据自动注册； 4对于存量元数据注册：应结合实际情况，在符合元数据相关规范的前提下，进行业务元 数据与技术元数据的连接及注册

7.2.5运维元数据包括但不限于以下内容：

图7.2.4元数据注册方法

1宜通过对元数据进行分析，发现数据注册、设计、使用的现状及问题，确保元数据的完 整、准确： 2宜通过数据资产分析，了解各领域的数据注册情况，发现数据在各信息系统使用过程中 存在的问题： 3宜通过业务元数据与技术元数据的关联分析，反向校验架构设计与实施情况，检查数据 标准的执行情况

7.3.1元数据应用宜包括以下内容

1元数据查询：应支持按元数据名称、元数据类别的查询，展示内容宜包括元数据编码、 元数据名称、元数据类型、元数据详细内容、创建时间、修改时间等关键信息； 2数据血缘分析与影响分析：可通过血缘分析提取数据的血缘关系，记录数据的来源和处 理过程，以快速定位问题数据：可通过影响分析提取数据的下游流向，以快速分析元数据修改

对下游条统的影响 3元数据统计分析：宜支持统计各类元数据的数量，比对相似元数据和变更前后版本； 4数据冷热度分析：宜支持统计数据表使用情况，从访问频次和业务需求角度出发，进行 数据冷热度分析； 5数据资产地图：宜通过对各类元数据的梳理和加工，实现不同来源的元数据有效集成 形成数据资产地图，支持从业务、技术、操作、管理等不同视角管理和使用数据资产

1理解主数据的整合需求； 2识别主数据的来源； 3定义和维护数据整合架构； 4实施主数据解决方案； 5定义和维护数据匹配规则； 6根据业务规则和数据质量标准对收集到的主数据进行加工清理： 建立主数据创建、变更的流程审批机制； 8实现各个关联系统与主数据存储库的数据同步； 修改、监控更新关联系统主数据变化

3定义和维护数据整合架构； 4实施主数据解决方案； 5定义和维护数据匹配规则； 6根据业务规则和数据质量标准对收集到的主数据进行加工清理： 7建立主数据创建、变更的流程审批机制； 8实现各个关联系统与主数据存储库的数据同步； 9修改、监控、更新关联系统主数据变化。 【条文说明】主数据管理的核心是确保各业务系统间主数据的一致性。以机场基本信息为例，机 场三字代码/四字代码、机场设施基本信息数据、机场跑道等级等建议作为主数据。航空公司基 本信息为例，航空公司两字代码/三字代码、企业基本信息等建议作为主数据，

【条文说明】主数据管理的核心是确保各业务系统间主数据的一致性。以机场基本信息为 场三字代码/四字代码、机场设施基本信息数据、机场跑道等级等建议作为主数据。航空 本信息为例，航空公司两字代码/三字代码、企业基本信息等建议作为主数据

8.1.2主数据管理的目标是，

1消除数据亢余：通过主数据管理打通各业务链条，统一数据语言，统一数据标准，实现 数据共享，最大化消除数据几余； 2提升数据处理效率：通过主数据管理实现数据动态更新，减少人工处理的时间和工 作量； 3提高单位战略协同力：通过主数据的一次录人、多次引用，避免一个主数据在多个部门 和合同的重复录入，实现信息集成与共享

8.1.3主数据管理应符合下列原则

1唯一性：主数据应代表单位中的某个业务对象的唯一实例，应避免重复创建实例； 2标准统一：应制定统一的主数据标准和模型，并在流程的各个层级中实施主数据标准和 模型； 3单一数据源：应为每个主数据的创建、更新和读取操作确定一个应用系统作为数据源

以确保主数据跨系统、跨流程的唯一性和一致性： 4协同性：应确保主数据在正确的流程中创建、更新和使用，并在正确的应用系统中落 地，以确保全单位范围内的主数据质量

3.2.1主数据管理流程宜包括识别主数据、制定主数据标准、构建主数据管理系统和运维主 数据。

8.2.2主数据识别应考虑下列因素

1高业务价值性：主数据应是描述关键业务的数据； 2数据共享性：主数据应是不同业务部门之间、不同业务系统之间需多次共享的数据： 3基础性：主数据应是基础数据，不应是衍生数据，具有不可拆分性； 4长期有效性：主数据宜为在业务系统中存活周期较长的数据； 5识别唯一性：主数据应是能够唯一识别业务属性的数据，可明确区分业务对象、业务范 围和业务的具体细节； 6稳定性：主数据宜为变更频率较低的数据。 【条文说明】如果数据只在一个系统使用，并且未来也不会共享给其他系统，一般不作为主 数据

2.3主数据标准宜包括数据标准、质量标准和

1主数据数据标准宜包括数据来源、数据属性与编码、数据格式、数据模型、数据接口 范等内容； 2主数据质量标准宜包括主数据质量指标，主数据质量核查规范，主数据质量控制规范等 容； 3主数据安全标准宜包括网络安全、接口安全、应用安全和数据安全标准等内容。 8.2.4主数据管理宜依托必要的信息系统，主数据管理系统可采用以下3种模式： 1集中管理模式：由主数据管理平台集中管理，通过整合多个业务系统中的主数据，集中 进行主数据的清洗和标准化，并把主数据分发给需要的应用系统； 2源头管理模式：主数据由源头业务系统管理； 3协同管理模式：由源头业务系统和主数据管理平台按照协同规则对主数据进行管理

8.2.5运维主数据应制定主数据运维流程及紧急问题预案，建立主数据创建、变更的审批机

制，维护主数据整合架构和数据匹配规则，实现对主数据操作的维护，包括主数据申请与校验 审批、变更、冻结/解冻、发布、归档等。实现各个关联系统与主数据管理系统（源头业务系统

或主数据管理平台）的数据同步

8.3.1主数据采集应符合下列要求

1对于已经形成国家标准或行业标准的主数据，应采用相应标准进行采集，确保数据与发 布标准一致； 2对于未形成国家标准或行业标准的主数据，应依据本单位主数据标准进行采集，并保持 主数据管理系统与数据源头业务系统的同步

8.3.2主数据人库方式包括手工录人和系统接入，应符合下列要求：

1手工录人应按照确定的主数据规范进行数据建模、制定数据维护流程、建立数据校验规 则，录人数据内容及相关标准、规范，数据质量应由业务主管部门负责； 2系统接入应按照对接系统与主数据管理系统协商好的接口方案进行对接，并在主数据管 理系统上进行数据结构的建模，数据源系统应保障数据的实时性，数据质量应由业务主管部门 负责。

8.3.3主数据管理系统对原始主数据进行清洗，由主数据业务主管部门确认该主数据符

1主数据清洗应检查非空属性和编码格式； 2主数据清洗宜对数据导人过程或导入结果进行监控； 3主数据清洗应检验系统的重复性判断结果； 4主数据清洗应检查编码规则； 5对来自多个系统的源数据进行查重时，应按照以下原则确定主数据： 1）有确切第三方资质依据的数据，应将与第三方资质一致的数据作为主数据； 2）应符合少数服从多数原则，保持数据来源一致性

1主数据集成的合规数据源应为源头业务系统（源头管理模式）或主数据管理平台（集中 管理模式）。下游信息系统或应用不应从非数据源头业务系统或主数据管理平台集成主数据 2下游信息系统或应用应集成合规数据源且不修改属性。 3下游信息系统或应用中不应补录主数据。 4下游信息系统或应用不应向后传递数据。 【条文说明】主数据集成的不合规操作示例：A系统从B系统（非数据源）集成主数据，并且在 A系统落地了物理表；某系统直接调用中间系统（非数据源）的主数据，

医药标准8.3.5主数据变更应符合下列要求：

1主数据变更应由源头业务系统（源头管理模式）或主数据管理平台（集中管理模式）进 行主数据变更，确保下游信息系统或应用不变更数据： 2主数据变更应依据流程进行变更，当主数据使用方提出主数据新增、结构变更及废止的 申请时，应由业务主管部门对数据变更进行确认； 3发生主数据变更后，应确保各个关联系统与源头业务系统或主数据管理平台的数据 同步； 4主数据变更宜通过数据标识等技术手段实现对主数据变更的追踪

1为了便于在执行本规范条文时区别对待，对要求严格程度不同的用词，说明如下： 1）表示很严格，非这样做不可的用词： 正面词采用“必须”；反面词采用“严禁”。 2）表示严格，在正常情况下均应这样做的用词： 正面词采用“应”；反面词采用“不应”或“不得”。 3）表示允许稍有选择，在条件许可时首先这样做的用词： 正面词采用“宜”；反面词采用“不宜”。 4）表示有选择，在一定条件下可以这样做的，采用“可”。 2本规范中指定应按其他有关标准、规范执行时，写法为“应符合·.·的规定”或“应 安…·.··的规定执行”。非必须按所指定的标准、规范和其他规定执行时，写法为“可参照…··..”。

1为了便于在执行本规范条文时区别对待，对要求严格程度不同的用词，说明如下： 1）表示很严格，非这样做不可的用词： 正面词采用“必须”；反面词采用“严禁”。 2）表示严格，在正常情况下均应这样做的用词： 正面词采用“应”；反面词采用“不应”或“不得”。 3）表示允许稍有选择，在条件许可时首先这样做的用词： 正面词采用“宜”；反面词采用“不宜”。 4）表示有选择，在一定条件下可以这样做的，采用“可”。 2本规范中指定应按其他有关标准、规范执行时，写法为“应符合·的规定”或“应 ………·的规定执行”。非必须按所指定的标准、规范和其他规定执行时，写法为“可参照……….”。

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适 用于本文件。凡是不注日期的引用文件，其最新版本（包含所有修改单）适用于本文件， 【1］《信息技术服务治理第5部分：数据治理规范》（GB/T34960.5） [2]《数据管理能力成熟度评估模型》（GB/T36073） [3]《信息技术大数据数据分类指南》（GB/T38667） 「41《信息技术大数据术语》（GB/T35295） [5]】《信息技术大数据技术参考模型》（GB/T35589） 【6】《信息分类编码的基本原则和方法》（GB/T7027）

汽车标准机场建设工程行业标准出

成本价：19.00元