商业银行数据模型建设模式和设计工艺探究

构建企业级数据模型可以帮助银行厘清数据分布关系，优化数据架构，确保数据的一致性、完整性和易用性，进而提升数据应用效率，激发数据的业务价值。

随着监管部门对数据安全、数据质量要求的不断提高，银行机构亟需深化对数据的精细化管理，确保数据的准确性、安全性以及合规性。银行通过建立统一的数据标准，规范数据采集、处理、存储和使用等流程，提高数据的质量和价值，避免数据泄露、不合规使用等问题，为数字化转型提供可靠的数据基础。

数据模型建设是推动高质量数据治理体系的核心环节。银行业作为早期开展数字化转型的行业，在取得了诸多显著的成果同时，也暴露出了一些问题。在银行的数据管理模式从粗放式扩张向集约式管理转变的过程中，出现了数据架构、数据质量等方面的问题。例如，数据质量无法满足运营安全要求，数据架构难以支撑业务创新需求等。构建企业级数据模型可以帮助银行厘清数据分布关系，优化数据架构，确保数据的一致性、完整性和易用性，进而提升数据应用效率，激发数据的业务价值。

一、数据模型具有四大价值

在数据生产和管理过程中，数据模型发挥着关键作用，高质量的数据模型具有以下价值：

构建业务与技术沟通的桥梁。良好的数据模型有利于统一银行内部人员对业务定义与术语的认知，提升银行内跨业务、跨团队的沟通效率。
保障业务与数据架构的一致性。数据模型的研发需要依托于业务架构，良好的数据模型有利于从组织层面上，保障业务架构与数据架构的一致性，指导银行内系统建设与业务创新。
优化数据成本。按照数据模型要求进行数据的研发应用，可以有效减少数据存储的冗余，增强数据的复用性，避免了孤岛式、烟囱式建设。优化数据的存储、建设和应用成本。
提升业务决策能力。数据模型的建立有助于明确数据流向，保障数据的真实性，为行内业务决策者和数据使用者提供可靠的数据分析与应用，助力发挥数据价值。

二、数据模型建设模式

通过对我国大型商业银行内模型领域专家开展广泛调研与讨论，我们发现，当前普遍存在两类数据模型建模方式，一是从企业架构视角进行建模，二是从数据应用场景视角进行建模。下面，我们将分别介绍这两种模式的建设流程及特点，并对二者进行对比，便于读者进行选择。

1. 基于企业架构视角建模

基于企业级架构视角的模型是以企业战略为核心，依托业务模型建立企业级数据标准，贯穿战略层面与系统应用层面。基于企业级架构视角的模型建设有助于打破组织内IT系统的孤岛式建设，核心任务是对银行内战略的分解、传导，帮助企业将零散的能力“聚沙成塔”，确保战略意图和绩效指标逐层落实到每一个流程步骤、程序模块、操作规范中。

企业级架构中的业务模型从产品、流程及数据三个角度，对企业的业务运营进行精细化、结构化的描述。

产品模型，主要包括产品分类结构、产品组件、产品条件和产品参数，以及可售产品实例化；通过对企业产品分类来优化和完善产品目录，确定与产品相关的业务规则、约束、价格等关键要素，并采用产品条件及参数的形式表达；在操作流程中由产品确定的相关业务规则形成企业级的产品模型。
流程模型，是业务模型的主线，描述了客户端到端的业务操作流程；通过提取业务的变量（比如客户C、产品P、渠道C和合作方P），形成汇总的企业级流程，保证渠道、产品线之间业务流程的一致性以提供卓越的客户体验；流程模型能够包容客户、产品、渠道及合作方的差异，支持线上线下全渠道整合，体现端到端的完整业务处理流程，为客户提供跨渠道的、一致的体验和一站式的产品服务。
数据模型，是将流程模型以及产品模型中产生的所有数据需求进行逻辑化和抽象化表示，反映企业的战略目标在实施过程中所用到的所有数据实体及实体之间的关系。集合每个操作流程需要进行读写处理的信息对象，流程规则需要读取或记录的信息项及其关联关系，构成了数据模型的基本输入。

产品模型、流程模型和数据模型从不同的维度还原了业务本质。产品模型体现业务创新，流程模型体现运营模式，数据模型体现业务模式。通过三者模型的对接，一方面交叉验证提升业务模型质量，另一方面为后续IT设计提供输入。

图 1 流程模型、数据模型、产品模型三者关系参照图

基于企业架构视角建模流程主要分为五步：

第一步，识别需求。通过研讨会、访谈、业务手册等方式，识别业务重点关注的内容。
第二步，构造业务对象。提取相关名词形成候选核心实体，并基于核心实体形成业务对象。
第三步，界定数据范围。提炼业务数据，界定系统的数据范围。
第四步，划分主题域。对业务数据进行分类，抽象业务对象，最终梳理出业务实体，及实体间的业务关联规则。
第五步，完善业务对象清单。结合流程模型验证已识别业务对象的正确性和完整性，识别完善与细化业务对象清单。

2. 基于应用场景视角建模

基于应用场景视角建模是从业务驱动的角度，从具体业务场景出发，覆盖各方业务需求。核心任务是对具体业务场景的业务逻辑进行抽象，将业务与技术融为合力，为企业的战略规划、市场预测、产品研发等方面提供有力支持。

基于应用场景视角建模流程主要分为四步：

第一步，识别需求。明确需要建模的业务场景及模型应用诉求，例如风险评估、客户分析等场景。
第二步，系统调研。对现有源系统进行信息调研，获取相关数据源、数据分布等信息。
第三步，数据梳理。基于业务需求梳理数据项，包括数据指标、业务实体等，并逐步迭代定义实体关系，标识实体属性。
第四步，建立映射。在实施过程中与底层库表建立完善的映射关系，持续优化建立描述各业务场景的数据模型。

图 2 数据应用场景视角数据模型参照图

3. 两种数据模型建设模式对比

基于企业架构视角的数据模型建设方式，通常适合于跨部门或系统的业务需求较多的组织。这种方式主要是由组织层面发起，通过对数据的宏观把握和分析，梳理和整合不同部门和系统之间的业务逻辑和数据关系，通常实施开发周期较长，适合于组织重构数据模型或创新业务模式的时期。

基于应用场景视角的数据模型建设方式，则通常适合于精细化分析的业务需求较多的组织。这种方式主要是从某个特定的业务场景出发，通过对数据的深入挖掘和分析，梳理和分析具体场景中的数据关系和业务逻辑，实施开发周期与业务场景及需求有关，适合于组织对已有数据模型进行改造或升级的时期。

值得注意的是，数据模型构建的核心是为业务服务，在应用中企业需根据组织实际情况和需求，综合考虑企业数据现状、存储方式、处理效率与复杂度等情况，灵活选择或融合使用两种数据模型建设方式，以实现更好的数据分析和业务决策。

图 3 两种建模模式对比分析

三、数据模型设计原则与研发工艺

企业级数据模型通常包含概念模型、逻辑模型和物理模型。建设数据模型是一套专业且规范的构建工序，包括对数据结构进行整理、分析、信息归类、裁剪与映射等一系列操作流程。本节将介绍企业级数据模型的建设原则与建设工艺，从各类数据模型的建模关键活动、设计指导原则及实施工艺（或工具）等角度进行说明。

1. 数据模型设计的六项原则

建设数据模型是一套专业且规范的构建工序，包括对数据结构进行整理、分析、信息归类、裁剪与映射等一系列操作流程。在企业级模型研发的过程中应遵守以下原则：

完整性原则： 在充分参考各类业界企业级数据模型的基础上，结合银行的实际情况，确保模型包含了正确的、全面的业务概念，涵盖现有业务范畴及数据范围如存款、贷款、投融资、营销等。其中涉及的重要实体、重要关系、重要分析维度等属性应保持完整。此外，还需要满足各模型间的参照完整性，支持相关的业务活动。
继承性原则： 指数据模型要遵循已有的概念，即所建立的模型应该在已存在主题的基础上进行细化。确保数据模型的全局一致，并保障数据可溯源，逐步形成企业统一数据模型。
可扩展性原则： 主题分类应具有高度的通用性，支持业务规则的多变性，保持数据模型的动态调整能力，以适应复杂的业务情况，并为后续拓展新的业务提供一定程度的技术支持。
连贯性原则： 模型中的数据与数据之间应有连贯性，由于单独的数据所体现的价值往往比相关联的数据少，数据间的连贯性可充分发挥数据的分析价值。
前瞻性原则： 企业应从业务的未来发展趋势看待模型，除了支持现有的业务与数据需求外，设计出来的模型应能够适应企业未来的业务发展，以支撑行业先进概念与企业未来需求。
可操作性原则：模型的应用可与日常操作和实例快速结合使用，易于让业务人员理解和使用，有助于科技和业务部门人员的沟通，便于指导项目研发。

2. 概念数据模型

概念模型也称为领域模型，是对数据的高级、抽象描述，概念模型的目标是捕获业务需求和数据的本质结构，通过模型帮助业务分析师和数据库设计师理解业务中的实体、实体间关系和数据分布关系，通常以实体-关系图形式呈现。

图 4 概念数据模型示意图

设计工艺

概念模型设计分为以下五步：

第一步：明确建模范围；第二步：制定分类模板；第三步：识别分类模板；第四步：细化分类层级；第五步：定义各级分类。

图 5 概念分类模型工艺

概念模型的主题划分是依据业务主体参与的业务活动特性来划分，建模人员需根据设计指导规则，梳理企业业务架构及业务实体，对业务概念或信息系统数据进行逻辑化，形成对数据模型分类框架的概念化结构。并按照“主体－行为－关系” （IBR）方法，建立数据域间的关联关系。通常对应银行业参考模型中的A（B）模型设计活动。

3. 逻辑数据模型

逻辑模型是对概念模型的进一步细化，描述业务实体、属性以及实体间的关系，可转化为数据库表结构的设计，通常使用实体- 关系模型来描述数据的结构和关系。

图 6 逻辑模型框架示意图（参与人主题）

设计工艺

逻辑模型设计分为以下八步：

第一步：识别候选实体；第二步：研发高阶实体关系草图；第三步：分配属性至候选实体；第四步：应用业务信息规范化原则；第五步：完善实体关系图（E-R 图）；第六步：定义域和示例；第七步：检查业务与流程的完整性；第八步：描述属性与业务规则。

图 7 逻辑模型实施工艺参考示意图

逻辑模型是依据概念分类主题划分做进一步细化，建模人员需根据设计规范识别各概念主题下的候选实体，形成实体关系草图，对实体属性及实体间关系进行规范性描述。其中从“ 分配属性至候选实体” 到“ 定义域和实例” 的四个环节需要反复迭代以持续完善模型内容。通常对应银行业参考模型中的C/C＇模型设计活动。

在由企业级逻辑模型（C模型）到应用级数据模型（C＇模型）设计过程中， C＇模型数据对象继承自C模型的业务对象，唯一的核心数据实体和属性应与业务对象保持一致。建立组织级数据模型与系统级数据模型的映射关系，形成模型的同步更新机制。

4. 物理数据模型

物理模型是数据库的实施模型，用于详细定义数据的物理结构，形成对真实数据库的完全描述。物理模型定义了数据库在特定硬件和数据管理系统中的存储和性能细节。

图 8 物理模型框架示意图（参与人主题）

设计工艺

物理模型是对逻辑模型的进一步细化，需要对数据库中的表、视图、字段、数据类型、主键、外键、索引等进行明确和定义。通常对应银行业参考模型中的D模型设计活动。

物理模型的设计还需要遵守如下原则：

一致性原则：主题分类及主要实体一致，继承逻辑模型灵活性，易于扩展等优点。
差异性原则：从逻辑模型到物理模型的落地设计过程中，对于集中式数据库存储，通常实体和属性是一一映射关系，主要考虑按不同的数据库类型进行属性类型和索引等设计的差异。
性能保障原则：从应用性能和分布式存储的设计考虑，物理模型落地时需从分库、分表及应用性能等方面进行设计规范，提高数据的处理性能。

物理模型（D模型）需要一对一继承 C’模型逻辑数据对象、实体和属性，并根据实际使用的数据库，设计相应的物理特性。此外还需保障物理模型（D模型）和企业级数据模型（C模型）、应用级数据模型（C’模型）间具有同步更新机制，确保数据模型间的一致性。

企业除了模型设计工作外，还面临着一系列的数据模型管理工作。总体来说，数据模型的管理包含组织（人）、流程与工具三个方面。

本文摘编自CCSA TC601 大数据技术标准推进委员会发布的《商业银行数据模型白皮书》，全文下载：