航班运行控制是控制系统，是一个行业和领域的控制系统。管理系统中的控制过程在本质上与工程的、生物的系统是一样的，都是通过信息反馈来揭示成效与标准之间的差，并采取纠正措施，使系统稳定在预定的目标状态上的。而当前国内航司的FOC、HCC、AOC、GOC等，还是集中数据库与MIS相结合的状态。虽然很多航司考虑、并尝试神经网络理念的落地应用和参考海外航司的实绩，但是还有很多环节和体系需要重新考虑和建设。

01 前言

数字化时代，数据是企业核心资产，也是内部运营和生产的关键，但是其需要治理；而治理的其中一个结果就是充分体现航司业务能力的数据模型和数据架构。其在分析体系中，解决挖掘、洞察及智能决策；而在应用体系中，承载的不仅仅是当前系统应用的状态，更支撑着系统的交互和联动。所以需要在运控领域参考行业、国际、国家相关标准，形成适合航司自身的数据模型及存储逻辑，并且面向OLTP和OLAP两类场景，构建好运控领域的整体数据架构，让存储在其中的数据模型真正能够高效运转起来。

02 数据治理在于解决流转

正如过往分享的，航司运行控制需要按照人体的神经网络的模式运转一样，按照控制论中自适应系统的要求，未来运控势必更强调ODS的建设、及针对性的实现自适应运行控制的神经网络传导能力的建设，即仿效神经网络或感觉器官，实现智能化的自组织系统。其中元数据、实时运营数据、经验决策数据正是上述四种不同类型的数据库和数据存储模式在运行控制领域的落地经典模型。即从架构和技术视角，需要一整套端到端的、准实时的、有时序的、规则和数据库控制驱动的航班运行控制的数据供应链架构落地，而数据治理正发生在此架构之上、数据流转之中。

仿效埃森哲等数据供应链理念，需要将航班运行控制领域的数据端到端的建设，分为6个阶段，从而实现各个远端及分散的神经末梢与核心数据存储之间的数据流转和供应链实现。

02.1需理解该领域的行业特色

根据曾经海外航司成功案例，以及诸如IBM、HP等全球企业服务厂商的行业解决方案等，再结合近一些年国内航司在ODS、HCC、运控体系建设等方面的实绩，航班运行控制及保障领域，具备如下特点和行业特质：

实时性强的交易数据体系：即ODS也好、ODES也好，或者其他数据架构模式，其都是必须解决和支持实时及准实时的OLTP业务，数据端到端的供应链上必须实现实时的数据及信息信号的反馈、实时的端到端传输、实时的整体数据快照等等。

集中数据存储与企业消息系统结合：其与数据中台、数据湖、大数据平台、数据集市、数据仓库是不同的。虽然其需要集中存储航班运行、各保障单元、控制及恢复等的交易系统的数据，但是其关键需要数据的关联、合理建模等。数据不能按照数仓贴源层或ODS层的方式放置，需要以例如航班或Flight Leg主键的模式进行整合，并将时间、保障单元、关联报文等进行模块化的数据建模，并一般建模的结果往往是大于主数据建模的结果，因为其需要携带更全面的、依赖的、可链接的其他元素的数据或状态信息。这之后，还需要通过企业消息系统或最简单的分布式消息队列在各个业务系统、应用模块和相关操作工具上往复的进行交换和流转，这都需要数据建模、消息定义以及信息和数据的流转控制。总结而言，实时性、流通性和数据块特性是上述大数据平台及数仓等数据体系无法实现的。

持续的时序化数据快照：正因为航班运控领域ODS，其需要实时反应整体航班为主线的各个控制和保障环节的状态，绘制整体的快照，这就造成每个控制环节和保障单元的状态变化，以及各类报文事件，都会随着时间的推移，产生一系列的快照。并且根据自身数据建模的特点，主数据之上的数据块建模结果，这就造成整体存储的数据从短期上看，其将是一系列的时间戳序列化的数据切面。而正是这样的数据形态，才需要特殊的数据建模手段和处理利用方式来响应，最后形成完全时序化的、持续不间断的一系列整体和单一维度的航班运行的快照切片。

数据安全及个性化数据消费：数据是持续的时序快照，且按照特定建模实现的数据模型和存储，但是真正消费和利用的时候，则需要考虑使用方的业务情况、使用诉求等，更需要考虑数据块传递的带宽等问题。一般都需要对于数据的来源、更新审计及日志等，按照利用方或请求方的角色、座席、用途等定义系列的规则加以控制。并且这些都需要体现在数据模型之上，而这些往往不会在大数据平台或数据湖及中台上完全体现。

以数据利用为目标进行设计：正如上述提及的个性化订阅和基于座席的数据安全和消费控制，运控领域的ODS或实时的数据镜像，其是面向此领域特殊的应用场景及使用诉求而建设的。好比数据中台，其在电商领域虽然承载数据量较大、且相对数据种类也纷杂、支持的场景也多，但是其不能实现多部门、多角色、多环节、多流程的统一协作问题。故大家从来没有在电商领域或市场营销场景下控制论的概念。既然航班运行控制及保障领域的行业特殊性，就需要从数据治理需要的工作中，面向该领域设计和落地针对性的方案，并且与具体特殊的数据利用和信息消费整合在一起考虑实现手段，例如数据服务不能简单是微服务、API，以及应用主数据的服务接口Schema定义，还需要在其中考虑到数据库规则驱动的数据服务接口的生成、字段及信息的关联、权限及审计的应用等，这些都是数据治理在该领域需要考虑的，并且数据治理不是简单的定义数据模型，其还包含标准和安全，以及架构和使用管控等。

数据模型及结构是关键：从个性化的数据利用、以利用和场景为目标的数据模型设计、时序化持续的数据镜像等等，都对于该领域的数据建模提出了很高的要求，其不仅仅是为了数据分析和决策而生，更关键是为了多部门、多角色、多环节、多流程统一协作而产生的，其不能落地到某一个业务系统或业务中心来实现、也不能通过简单的分布式消息队列来实现、也不能完全通过数据湖之上的大数据平台或数据中台来实现，其必须是隶属于业务及交易领域的一个特殊存在，且要求严格和行业针对性的数据建模，诸如时序化要求下各类时间戳、记录更新时间等要求，数据更新来源和审计日志等要求，这些都是要落地到数据建模的工作中，并且也数据库中的物理表方式存在，且也支持分析和决策，但是与数据中台或数仓之上的分析和决策是完全不同视角的。

没有行业标准、只有经验积累：正因为其该领域的特殊性，故其不能完全照搬和依赖于行业标准和方法论，其需要有自身的特色和个性落地方案。就以数据模型而言，不管是概念、逻辑还是物理数据模型，其都没有整个行业或国际上公开的、可直接参考的数据模型、数据字典等。都是各个航司经历多年积累下来的。海外航司在该领域的数据模型和建模工作成绩斐然，其关键是善于引入外部企业服务的专业能力、注重企业架构及数据在该领域的特殊性，结合外部专业资源慢慢积累下来的。例如我服务的EDS，其在运控领域的数据模型是过往近20年民航经验的积累，由近百人的国外行业老专家们在不同的航空公司实施交付中积累下来，并以一整套FltOps（Flight Operations）产品线的方式固化成型的。

02.2 数据或业务中台不是解决办法

首先作为全民航第一个实施过数据中台的人员，结合使用阿里云数据中台产品及在南航实施的2年经验，我理解该领域的诉求，我认为数据中台不能解决该领域的问题。其次核心问题是数据中台的理念、方式、实现逻辑、架构方式等等是无法满足航班运行控制及保障领域长期对于ODS的利用诉求的。且确实在某些理念思路和新技术应用上有价值，但是这不代表整体方案和模式适合该领域，我也不认为其可以颠覆整个业态的模式，首先其需要解决和完美回答，数据中台是怎样实现控制论的；但是其确实可以通过自身的优势和技术的融合，为该领域整体的OIS（包含ODS/Operational Data Store、MDR/Meta Data Repository、IDS/Informational Data Store）提供部分的置换，例如将IDS完全用数据中台替代，这是合理和必须的，也是极具价值的。

怎样解决实时性？运行领域当前没有完全单一的系统能够将航班动态、报文信息、保障单元状态、控制环节信号等统一汇总和输出的地方。数据湖之上的数据中台也许能够实现整体的数据汇总和数据建模，但是其对于秒级的数据更新及多元的同步，其本质是不能实现和不现实的。

怎样解决特殊要求？所以该领域的数据体系和模型等建设，都是要面向实时交易支持的，里面最典型的一个特点就是信息和数据的交换及流转。这其实就是主数据的概念，但是其需要平衡交换网络的通讯信道压力，也要平衡分布式通知事件与服务接口及集中数据存储的协作，所以需要在主数据模型基础之上强化面向应用场景的数据模型，形成一个数据块；另外对于基于座席偏好的数据利用、基于时间时序和安全审计的要求，都需要在数据模型等建设中针对性的考虑解决办法。另外从数据接入接出、分发及存储等一系列利用数据的场景问题上，需要结合当前可用的技术，设计和实施能够支持控制论的企业架构和数据治理的实现逻辑。

怎样解决利用个性化？数据即使统一存储，且通过第三范式进行建模之后，也还是需要将各个数据块的数据按照使用场景、座席职能、用户角色等，进行重新打包和提供数据利用的能力。这里面就需要将各类数据的关联关系、与角色和座席等的使用逻辑、订阅及发布消费的对应等，进行设计并落地到上述各个数据实体及模型中。这样才能解决数据的应用，而不是向数据中台上的数据管理及安全管理的逻辑，以租户的方式开放数据，之后再建应用，因为其违背和不可能支持数据的动态及灵活敏捷的按需打包和消费场景。

怎样解决动态接入接出？数据中台也好、数据湖之上配合大数据开发平台的湖仓一体架构也好，都需要专门的数据湖构建工具，或ETL等实现。但是对于数据消费其大部分以报表、数据应用及服务等方案体现。但核心的一点是数据中台上大量的是存储的事实表、维度表、数据指标体系等，这些其根本不是运控及保障业务流转中最关心和实际使用的。为了更好的实现数据、事件、信息、指令、沟通等的感知、采集及发现，然后流转到目的端，并实现整体结构化和体系化的时序镜像快照，这就需要有针对性的数据接入接出的架构和平台来实现。正如之前篇幅所提及的企业消息系统一样，其只是其中的一部分实现，还需要更有针对性的手段和数据处理工具，例如怎样灵活的处理各类报文和集成转化问题。

02.3 需与本领域的企业架构配合

数据治理不仅仅包含规划、组织、流程、工具、资产等这样的维度划分，还包含元数据、标准及质量、安全等等的维度，更关键作为一个数字化领域的概念，其最终落地在系统之上，这不仅包含大数据平台等数据中台、数据仓等的平台级软件应用之内，还包括各类签派放行、运行控制、机组排班等等业务系统之上。所以这就更需要综合考虑该领域的业务特质，以及控制论的理念，在权衡技术和架构投入的前提下，设计和实施针对性的架构体系，将数据从源头到消费端，实现端到端的闭环治理和高速高质的数据流转和业务协同。

例如，以航司地面保障数据平台的一个项目为例。其整体需求上虽然在表征上对于数据接口的支持、数据采集及加工、数据存储及服务、数据管控及治理等有硬性要求，但是其是一个完整的运营数据建设的体系，需要且未来必将跟数据洞察及分析，以及数据中台有直接关系。所以建设蓝图要从整体和长远的角度进行规划和设计，并从数据模型和数据架构体系的角度规划好各个层面的职能和重点。另外需要将数据流、数据发布、数据追踪及溯源等集中体现在设计中。如下是整体的逻辑应用架构，其包含数据接入、数据接出、数据服务、数据发布、数据跟踪、数据洞察、数据存储、数据引擎、数据管控等八大部件。为实现初期建设的目标，数据治理将启动关键作用，并在后续日常运营及运行角度作为数据管控的物理产出长期存在。

其中，将设计架构和安装部署4套数据库Schema：CRD / 通用及参考数据、AOD / 机场营运数据、BEL / 业务事件数据（即ODESBase）、ABI / 机场业务洞察数据。

CRD / 通用及参考数据 / Common & Reference Data Store：其中存储基础数据、通用数据、系统数据、配置数据。对于非某航司特有数据，数据Schema中不包含航司二字码，即不需要按航司不同进行识别。但是与航司业务有直接一对一关联的，则采用增加航司二字码的方式进行识别及存储，但是其均存储在统一数据对象实体表中。对于数据被多个航司拥有或操作的场景，定义额外的数据与航司使用关系映射表，以此保存一对多或乃至多对多的关联关系。对于关键数据，设计必要的审计信息字段及版本历史表，记录及跟踪数据的变化。

AOD / 机场营运数据 / Airport Operations Data Store：航班日常营运、机场运行、职能部门及资源操作的数据存储，基本以事务型数据为主。对于关键数据，设计必要的审计信息字段及版本历史表，记录及跟踪数据的变化。其中包含航班动态、航行数据、实时运行及保障状况。对于服务保障节点数据，也根据保障环节及服务链条，进行数据整合，保存相应的实时状态变化信息。

BEL / 业务事件数据 / Business Event Logging：即CQRS的具体实现，或称为ODESBase数据库。对于随着航班动态及地服机场资源的动态变化、操作、管控等事件的发生，将相关事件进行记录。其中包含上下游数据事件的记录、可按照时序和事件类型进行保存、可支持后续的全文检索等相关操作。

ABI / 机场业务洞察数据 / Airport Business Informational Data Store：对于后续准实时的KPI考核、统计分析、运营洞察等，配置及架构单独的数据存储。此举还解决了数据使用目的不同对于实时运营数据库及历史分析数据库的技术要求。实时的机场及航班运营状况，将通过消息队列及准实时同步方式，导入到此数据库中。经过适当的聚合及数据预处理，提供针对性的业务数据洞察及职能分析，和统计功能。但是此部分，确实可以从航司的整体视角考虑，通过数据中台来实现。

正如上述的案例及架构组成，那如若要开展数据治理，首要是将各个数据存储及使用的关键节点梳理和定位好，这样整体的数据治理不应该只发生在大数据平台等新建的环节，而且也需要考虑“源端”系统的能力，譬如选用的Sabre的MM作为航班动态和控制的业务应用及系统，产生航班动态ASM及MVT报文和数据，但是此时其就不能跟着航司的数据治理要求进行改造，只能设计针对性的架构和实现方式。例如这个时候建立FOD或AOD模型的集中化的、包含时序的、整体的运行保障数据存储及平台，就能够解决问题，并且关于数据治理中的元数据标准、数据标准及质量等，都可以在其上实现，并且形成标准和高质量的数据进入到后续数据利用和大数据平台等使用场景。并且当后续将Sabre的MM替换到自研系统或其他厂商系统后，也可以通过ODS的数据适配和报文适配及标准化功能模块来衔接。

02.4 需持续积累行业数据模型

很多人想到数据治理，第一印象和最先想到最苦的是给出一套行业放之四海而皆准的数据模型和数据字典。诚然，数据治理的最终结果肯定是要求整体从“源端”到消费端，以及从业务到大数据平台、从流程的头到流程的尾，数据要完全按照字段级的标准产生、存储、流转、交换，以及消费。IATA在多年前就已经启动了AIDM（IATA’s Airline Industry Data Model）的计划，其已经包含行李，报价和订单，飞机负载控制以及订单结算的标准，还有几个正在筹备中。其包括一个信息模型，该模型涵盖几个不同的领域，包括航班，购物，订单管理，付款，飞机配置，行李等。AIDM 版本根据乘客标准会议标准发布周期每6个月更新一次。其目的是成为存储的单一访问点：

行业认可的词汇

数据定义及其关系

相关业务要求

生成可互操作、更快、更简单的消息传递标准。

航空业是一个真正相互关联的行业。然而，通过使用不一致的定义，数据的无缝流动变得具有挑战性。同一术语在不同的系统中具有不同的含义，而多个术语用于描述相同的概念。从而实现数据交换的定义和格式的一致性得到提高，提高了整个行业的互操作性；加快新的或更改的数据交换标准的上市时间；通过质量和可见性更快地部署行业标准。与此同时IATA开展了AIDX（Aviation Information Data Exchange）。其是全球XML消息传递标准，用于在航空公司、机场和任何使用运营数据的第三方之间交换航班数据。AIDX通常用于飞行的操作窗口，但有些实现已将AIDX消息传递扩展到此临时范围之外。AIDX工作组开发和维护AIDX消息传递标准，以支持整个航空业高效和有效的运营航班数据交换。采用该行业数据标准为所有相关利益相关者带来了实质性的好处。该集团由航空公司、机场、IT服务提供商、供应商和行业协会组成。成员可能参与运营领域，构建IT解决方案，或负责维护其组织内的数据标准。采用 AIDX行业标准可为航空公司、负责更新运营航班信息的运营合作伙伴以及使用运营航班数据的行业利益相关者带来巨大利益：

提高数据质量和准确性、支持破坏性事件用例

提高灵活性/降低与支持 AIDX 接口的应用程序集成的成本

通过标准 AIDX 界面提高管理/现代化运营应用程序组合的敏捷性

减少与业务合作伙伴交换电子数据所需的 IT 适配器的数量/简化

利用开源 XML 工具处理和分析运营数据

目前，该架构包含大约180个不同的数据元素，涵盖了操作飞行腿的多个方面，例如：航班识别、代码共享航班、工作线、运营时间、中断详细信息、状态和备注、机场资源要求、乘客、行李、燃料、货物统计、飞机详情等。AIDX不断开发，以确保它适合目的，并满足行业不断变化的需求。目前的开发活动包括纳入变更请求以满足不断变化的新业务需求（例如，支持A-CDM向机场管理“TAM”的演变），为电传打字消息[如 MVT/MVA（+根据 AHM700 的其他消息）]开发向 AIDX 标准的迁移路径，以确保AIDX可以完全取代电传打字消息。通过将所有 AIDX 数据元素和属性建模到模型中，使AIDX与AIDM保持一致。

但是这种公立组织、每6个月更新一次的情况，以及真正参与过NDC项目的人都清楚，其版本迭代的延续性还是存在一定问题的。故航司在这之前，和面向全局的航司内部数据架构和模型的建设中，应该怎么办呢？这就需要基于过往重大项目、成功经验、自身特质等，持续的引入外部模型参考和优化自身模型落地，形成一整套适合自己、但能跟国际接口、且具备持续延展的数据模型体系。行业数据建模不是简单的业务系统数据的镜像，需要的聚合为面向全局及协同应用的领域数据。

例如如下DL等航司的航班/航节的数据模型可见，其与AIDM的并无特别差异，但是其包含更多的航班运行和信息流转的支持能力。这正是多年经验和该领域不断优化数据模型的成果。航班FLIGHT_LEG为核心表和7个字段构成核心主键，由其串联FLEET、STATION、CREW、FLIGHT_PLAN、LOAD_PLAN、MEL等等。

再以如下提及的REF（Reference）数据库的逻辑模型为例，其包含用户、座席、角色、权限、订阅、多航司、行业码表等一系列配置基础：

用户：用户信息及用户与角色对应关系，将存储在HR系统之中，由ODS提供数据访问。系统中将存储额外的用户信息，譬如特例用户，用于标识此用户拥有超越座席权限和配置的能力。同时用户的订阅和用户的喜好信息也是针对用户一一定义的。另外用户将有自己的工单信息，即代办事宜。

座席：即岗位。设置与航班的关联关系，即航班访问控制。设置与用户的关联关系，及用户登录控制。同时座席的订阅和座席的喜好信息也是针对座席一一定义的。另外座席将有自己的工单信息，即代办事宜。

角色：系统中除存储角色信息外，还将存储角色与资源，角色与数据之前的权限关系。

权限：权限分为功能权限和数据权限。系统将以座席权限为主，如果用户有高权限或特例权限，则使用用户的数据权限和功能权限。

喜好：分为应用系统喜好，用户喜好和座席喜好。如用户没有高权限或特例权限，则默认使用坐席喜好作为用户喜好的预设值。

消息：设置消息模板和可使用数据项目元素。以及与事件的关联关系。

事件：事件类型，定义，历史，渠道等。

订阅：事件发布和被消费，将有统一的订阅机制和配置管理。每个事件将根据其中包含的数据和关联的业务实体对象，将分为机场，飞机等若干订阅群体。

工作流：保存工作定义，状态，及运行历史。同时设置与事件的关联关系

规则：各类运行限制规则，及阈值。

02.5 需有本领域特色的技术方案

数据治理除了组织、规范、规划及资产等的落地外，还包含架构和工具，更重要的是要结合工具软件和技术手段，落地到端到端的数据供应链上。从航班动态的签派员更新、地服撤轮挡动作的物联网数据信号、ACARS卫星信号、或气象METAR报文、再或者自动配载的计算结果生成等开始，到最后应用端相应要做出的动作，这中间的数据采集接入及集成、加工到存储、存储到分析和消费等，就需要特定的技术环节来实现，并且在其中将数据标准和规范、管理标准和安全策略等应用其中。

以如下端到端的航班运行控制及保障恢复的数据供应链流程图为例，分享一些针对上述数据建模、个性化应用等的实现方式：

数据接入集成层：由于该层次需要对接各类不同的系统、报文、外部数据源、以及后续的物联网平台等，所以需要支持较多的集成工具，并提供可视化的集成工具便于实现“设计即所得”的模式来敏捷集成，并且实现监控和调度等能力。但是关键其在技术实现和方案手段上要支持流式和准实时的数据计算。这方面在多年前如果没有TIBCO这样成熟的套装软件的前提下，只能通过定制化的开发来实现，这就造成国内的航司和厂商往往仅仅局限于ETL和消息队列。但是如今大数据和相关技术的成熟，已经有很多开源及成熟的实现方案和手段了。当然不管怎样的手段，都需要对于贴源层的数据建模进行针对性的定制，存储好历史和处理好并发及异常。

数据聚合和展现层：当“源端”的数据第一时间进入ODS和运控集中的数据体系后，就立刻需要进行加工处理，其最终目标是形成整合的运控数据模型进行存储，并提供对外的消费和服务。但是过程中是进行数据治理和标准化转化的最关键一环。该部分的详细内容，在后续文章中展开，尤其是中间数据建模的几个关键场景和实现逻辑。

在线数据服务访问层：集中之后的具备行业特质的数据模型和整合数据，对外被内外部利用和消费的途径只有两种，一种是服务接口的方式，即之前提及的NGDS模式。那这边当年是没有敏捷的开发工具和低代码平台来实现，当初EDS是与TIBCO花费近1年的时间研发的平台，可以在数小时内完成数据服务的生产环境上线，并控制和跟踪审计服务接口的访问。然后当前不管是否使用基于JSON的RESTful服务，还是传统的Web服务，其都需要敏捷的、通过SQL等模式实现服务接口的快速开发，并且能够与安全、审计等进行集成。另外对于复杂的接口实现，例如基于Linkable概念的数据接口集成，则需要一些定制化或非敏捷的方式来实现。

数据传播及接出层：ODS的核心存储的数据变更，来自于接入聚合层，也可能来自于服务接口等。这些都会造成ODS的数据按照时序的前提下，发生变化。而这些变化就需要传播到相关的系统或源端。例如签派座席在航班追踪平台调整ETA，或HCC签派座席调整腹舱状态等，这些都是在整体协同平台上发生的业务动作，且直接通过接口访问到ODS，而不是落地到某一个业务系统，则此时需要将这些信号、数据变更等识别并捕获到，实现CDC的模式，用于后续分发和发布。在这些捕获的变更数据之上，构建和充分利用企业消息系统，将订阅和发布的规则、个性化数据消费的需求等逐一实现。

集中数据跟踪层：ODS上述几个层的实现，均会对与数据的操作和环节的调度产生大量的日志，并且整体也需要为了ODS的稳定提供各类可视化的调度及运维能力的建设，这就需要通过分布式日志系统及上述几个层次的专有技术方案或技术工具平台来实现整体的数据变更及日志等方面的能力。例如对于接口的访问、特殊关键数据块的访问、数据接入异常等，都需要形成日志，并进行汇总之后的跟踪、异常告警及查询分析。

数据洞察层：这部分就是ODS之后IDS的实现，其可以选用数仓，也可以使用大数据技术和平台来实现，即其是数据中台应该发挥的地方，这里不再详诉。

数据运维层：ODS是一个数据系统，其需要按照使用的场景和数据体系的特质，配合集中日志，实现整体的运维，例如清除历史记录、打包归档历史数据、逻辑删除并迁移数据、批量夜维到IDS等，这就需要相关的数据库内的配置驱动各类后台作业和可视化调度工具，按照运控数据的特质和上述几个数据层次的要求进行运维。

03 后续

由于篇幅所限，本篇行业数据模型及数据体系之后，将针对航班运行调度领域的核心数据建模中的关键环节、模型案例、业务支撑等几个方面进行分享。从而明确航班运行控制领域需要有针对性的行业数据模型，并且需要有面向业务特质的建模工作。