【第三部分实施篇】第七章数据仓库及数据模型管理

1.1. 概述与关键概念

1.1.1. 数据模型的定义
根据国家标准《GB/T 36073-2018 数据管理能力成熟度评估模型》中的定义，数据模型是使用结构化的语言将收集到的组织业务经营、管理和决策中使用的数据需求进行综合分析，按照模型设计规范将需求进行的重新组织。它是对现实世界数据特征的抽象、表示和处理，用于描述一组数据的概念和定义。

1.1.2. 数据仓库及数据模型管理的目标
数据仓库的根本特点之一是存放数据，并且这些数据是通过整合不同来源的数据形成的。而数据模型是数据仓库的架构基础，勾勒出数据仓库的宏观框架。数据仓库依赖于数据模型来规划数据的组织和存储方式。
(1) 建立组织级的数据“骨架”
通过收集和分析组织数据需求、内外部监管需求、与外部组织互联互通的需求，制定模型规范，开发数据模型，明确了数据仓库要涵盖的业务范围和主数据数据，清晰描述组织中数据、关系以及存储的方式等内容，形成组织级的数据“骨架”。并对数据模型和数据仓库建设进行全流程的管理，保证数据模型符合组织的业务发展。
(2) 保证数据仓库建设的规范化
组织通常拥有多个业务系统和数据源，数据模型管理致力于构建统一的数据存储形式和方式，对不同来源的数据进行整合和标准化，通过数据模型对数据的结构、属性、相互关系以及数据约束条件进行统一规划和设计，保证数据仓库中数据统一和完整，保证数据仓库建设的规范化和标准化。
(3) 为数据应用提供更好支撑
合理的数据模型标识了数据实体、属性以及它们之间的关系，使业务人员和技术人员能够轻松理解数据的含义、来源和使用方法，进而提高数据查询、分析和处理的效率。从技术角度来讲，合理的数据模型设计可以有效减少数据仓库中数据存储的冗余，增强数据的复用性。

1.1.3. 关键概念
1.1.3.1. 数据模型的类型
按照不同的应用层次和模型覆盖的内容粒度，数据模型一般分为主题模型、概念模型、逻辑模型和物理模型。
(1) 主题模型。主题模型是最高层级的、以主题概念及其之间的关系为基本构成单元的模型，主题是对数据表达事物本质概念的高度抽象。主题模型是围绕某个业务而聚集的数据（如客户、交易、零售主题等），用于定义数据模型的范围，为数据模型的设计提供总体框架。
(2) 概念模型。概念模型是一种面向用户、面向客观世界的模型，主要用于描述现实世界的概念化结构，是业务视角的高层次、粗粒度的模型，用于反映核心业务概念实体以及实体之间的关系。概念模型侧重业务逻辑而不包含设计的细节，不对实体的属性建模，与具体的数据存储无关。概念模型是在充分理解用户需求与业务领域后，通过分析、归纳而提炼出的抽象集合，常被用作数据治理的蓝图，用于梳理业务对象以及关联关系。
(3) 逻辑模型。逻辑模型是由概念模型转换而来的，以概念模型的设计为基础，将实体与关系映射到逻辑模型，进行细化设计。逻辑模型关注逻辑实现，不考虑物理属性。在此过程中需要增加所需要的新的实体、细化关联关系以及细化实体属性。
(4) 物理模型。物理模型是逻辑模型在具体数据存储介质上的实现，是一种面向计算机物理表示的模型，描述了数据在存储介质上的组织结构。其中包括对逻辑模型中各种实体表的具体化，需要对数据库中的表、视图、字段、数据类型、主键、外键、索引等进行明确和定义。物理模型描述如何使用特定的数据库系统实现业务，目的是实现数据存取。
1.1.3.2. 数据模型的主要元素
在数据模型领域，实体、属性和关系是建模过程中必不可少的元素。
(1) 实体。实体是客观存在的事物在人脑中的反映，或者说，客观存在的并可相互区别的客观事物或抽象事件称为实体。实体可以是人、事、物，也可以是事物与事物之间的关系。如客户、商品、商家，以及客户和商品之间的购买关系。
(2) 属性。属性是实体所具有的某一方面的特征，一个实体由若干属性来刻画。如客户的属性有名称、类型、联系方式等。
(3) 关系。关系是定义了两个实体之间关联的方式，可以是一对一、一对多或者是多对多。
1.1.3.3. 数据建模方式
关系建模和维度建模是数据仓库建设过程中常用的两种建模方式，适用于不同的场景。一般情况下，关系建模应用在数据仓库的治理层，目的是清晰地存储数据。维度建模应用在数据仓库的应用层，目的是方便地实现数据分析和数据应用。
一、关系建模
关系建模的全称是实体关系建模，即E-R模型（Entity-Relationship），它由P. P. Chen于1976年首先提出。E-R模型提供了一种不受任何数据库系统约束的面向用户的表达方法，在数据库设计中被广泛使用。关系建模需要遵循三范式原则，对实体之间的依赖关系进行整合，得出系统ER图。
在数据仓库建设过程中，治理层旨在将组织的数据按主题进行整合，并进行一致性处理，为数据分析决策提供支撑，且治理层数据存在大量的实体和复杂的关系，并且这些关系和数据会随着业务的发展而发生变化，关系建模能够更好地适应这种情况，可以灵活地处理各种复杂的数据关系，同时能够保证数据插入、更新和删除操作能够高效执行。因此，在治理层优先选择关系建模。
二、维度建模
维度模型由数据仓库领域的大师Ralph Kimball倡导。维度建模更多是面向业务过程进行建模，从分析决策的需求出发构建模型，为分析需求服务，重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。
在数据仓库建设过程中，维度建模在应用层起着至关重要的作用，能够更好支撑数据汇总、指标分析、指标下钻等各种数据应用场景，因此在数据仓库的应用层优先选择维度建模。
维度模型由两个基本要素组成：事实表和维度表。
(1) 事实表。事实表是维度模型的基本表，它存储的是业务事实数据，是数据分析的基础。如针对销售过程，销售事实表包括交易ID、客户ID、商品ID、交易时间、交易金额、商品数量等信息。
(2) 维度表。维度表是组成事实表不可或缺的一部分，对事实表中的数据进行分类，为事实表中的数据提供上下文信息，帮助我们从不同的角度分析业务事实。如销售事实表对应的客户、商品等属性，都分别对应了客户维度表、商品维度表等，为销售事实表提供了更多维度的分析视角。
维度建模一般呈现为星型模型、雪花模型或者星座模型。星型模型架构简单直观，易于理解和实现，能够快速满足基本的业务分析需求，在应用层是首选的数据模型。当维度具有层次结构且变化频繁，为更好的保证维度的一致性，雪花模型能够更好地应对这种情况。
(1) 星型模型
星型模型主要是用一张事实表对应多张维度表完成整个建模过程，即以事实表数据为中心，拓展事实表的维度信息或者维度表的属性信息来完成模型的构建。构建之后，星型模型中维度与事实表的关系如下图所示。如，针对订单事实表，结合商品、客户、供应商、区域等维度表就构成了星型模型。
星型模型结构简单直观，易于理解和维护，业务人员能够快速掌握数据模型结构，方便进行数据分析。缺点是在维度表中会出现冗余数据，比如商品维度表，每种商品的描述、规格等信息，会因为多次销售记录而重复存储，这增加了存储空间。

图 1 星型模型中的事实表与维度表

(2) 雪花模型
雪花模型中各数据模型整体呈现雪花的形状，因而得名。雪花模型是对星型模型中的维度表进行了层次化，将模型中较大的维度表逐步拆解成较小的维度表，这些被拆解的维度表不会直接关联到事实表，而会被关联到主维度表，形成层次。雪花模型中维度与事实表的关系如下图所示。
雪花模型通过对维度表进行规范化分层，适合处理具有明显层次结构且变化频繁的维度，能够减少数据冗余并提升维护灵活性。然而，这种结构也增加了模型的复杂性，导致理解与维护成本上升，且在查询时通常需要更多的表关联，因此查询效率一般低于星型模型。

图 2 雪花模型中维度与事实表的关系

(3) 星座模型
星座模型是由星型模型延伸而来的，星型模型基于一张事实表，而星座模型则是由多张事实表并且共享维度表构成的。星座模型是数据仓库建模中一种相对复杂的模型。典型的星座模型中维度与事实表的关系如图所示。如销售事实表和用户行为事实表同时关联商品维度表，就可以通过商品对销售情况、用户浏览偏好进行分析。

图 3 星座模型中维度与事实表的关系

1.1.3.4. 数据仓库、数据湖和湖仓一体
随着组织信息化系统的增多、数据的爆炸式增长，不同系统之间、不同数据库之间很难做到数据共享，数据分析、数据集成也变得越来越困难。为了解决组织内部数据集成与分析的问题，就诞生了数据仓库的概念。
针对数据仓库，行业上有两种不同的定义。Bill Inmon把数据仓库定义为“面向主题的、整合的、随时间变化的、相对稳定地支持管理决策的数据集合”，他用规范化的关系模型来存储和管理数据。而Ralph Kimball则把数据仓库定义为“为查询和分析定制的交易数据的副本”，这种方法通常称作多维模型。其实两者并不冲突，Bill Inmon主要讲的是数据仓库的治理层，而Ralph Kimball主要讲的是数据仓库的应用层。
数据仓库是一个理想的系统，可用于数据的分析和处理。本指南认为数据仓库有三个核心特征：
(1) 数据仓库存储的数据是经过集成、整合、清洗、加工的其他系统的数据；
(2) 数据仓库是面向主题来组织数据的存放形式；
(3) 数据仓库是为了更好地数据分析和访问。
随着技术和数据的发展，为了挖掘数据价值，组织希望完整保存生产经营过程中的所有相关数据，数据湖（Data Lake）应运而生。它是一个存储各类原始格式（结构化、半结构化、非结构化）数据的集中式存储库，数据在加载时无需预先定义结构或模型，具有存储容量大、数据类型多样、成本相对较低的特点。与数据仓库不同，数据湖侧重于原始数据的长期保存和探索性分析，为数据科学、机器学习等场景提供原材料，但其数据未经治理，直接用于分析的门槛较高。
湖仓一体（Lakehouse）是一种融合数据湖与数据仓库优势的新型架构。它通过在数据湖的底层存储之上，构建数据仓库的管理能力（如ACID事务、数据版本管理、数据治理和优化查询），实现了数据在湖与仓之间的无缝流动与统一管理。原始数据可低成本存入湖中，经过治理和加工后形成的高价值数据可直接用于数仓分析，同时数仓中的历史数据也可回流至湖中长期保存。这种架构旨在兼顾数据湖的灵活性与数据仓库的严谨性，降低数据架构的复杂度和数据迁移的成本。
一般情况，数据仓库能够满足90%的数据管理和应用场景，在数据量未到达一定级别时，选择数据仓库就可以满足数据管理需求。反而数据湖或湖仓一体因具有较高的技术门槛，大大增加了整体架构的复杂度和维护成本。

1.1.4. 与其他模块的关系
在数据治理体系中，数据模型决定数据存储结构和方式，还与数据标准、数据质量、数据应用等模块有着紧密的关系。
1.1.4.1. 与数据仓库的关系
数据仓库是存储数据的物理介质，归集组织内的数据并按主题分层次存放，以便于更好地支撑数据分析。而数据模型是构建数据仓库的基础前提，利用图形描述数据在数据仓库中组织和存放方式的“地图”，它指导数据仓库的架构设计、数据组织方式以及数据之间的关联关系。
1.1.4.2. 与数据标准的关系
数据标准为数据模型的设计提供了规范和准则，数据标准定义了数据的命名规则、数据类型、数据格式、取值范围等，数据模型需要遵循这些标准进行设计和开发，以确保数据的一致性和规范性。
1.1.4.3. 与数据质量的关系
数据模型与数据质量相互影响。一方面，良好的数据模型设计是保障数据质量的基础。合理的数据结构、准确的数据定义以及适当的数据约束（主键、外键、数据类型约束等）能够减少数据错误、保证数据的一致性和完整性，从而提高数据质量。另一方面，数据质量的反馈也有助于优化数据模型。通过对数据质量问题的分析，可能会发现数据模型存在的缺陷或不合理之处，进而对数据模型进行调整和改进。
1.1.4.4. 与数据应用的关系
数据模型与数据应用是双向驱动的关系，数据模型为数据应用奠定基础，而数据应用则驱动数据建模的发展和优化。数据模型清晰地定义了数据结构以及数据之间的关系，为上层数据应用提供清晰数据框架，能够更好地理解和操作数据。同时，物理模型中索引、分区等策略的设置，能够提高数据访问的性能。而数据应用中的性能不足、业务需求无法满足等现象又反向促进数据模型的优化和改善。

1.2. 实施指南

1.2.1. 落地思路
数据仓库及数据模型管理是一项系统性工程，采用 “规划－设计－维护” 的流程，形成顶层设计、落地实施、持续运营的闭环管理，构建一个数据架构清晰、模型规范统一、能够持续支撑业务分析的数据平台。

图 4 数据仓库与数据模型管理落地思路图

(1) 数据仓库规划
基于技术体系的建设基础，组织需要为数据仓库建设确立清晰的顶层架构与实施规范，为“数据怎么存”建立指导策略。主要工作包括根据组织的数据规模、实时性要求和技术栈，选择合适的数据仓库架构；规划数据的分层结构，明确各层的职责与数据流向；并制定统一的命名规范、开发标准和运维制度，为后续所有设计、开发和管理工作提供遵循依据，避免建设过程中的无序和返工。
(2) 数据模型设计
数据模型设计是将业务需求转化为可落地的数据存储结构的关键过程。依据实际情况，可选择组织级整体规划或需求导向的敏捷建模两种路径。核心活动是按照“主题模型→概念模型→逻辑模型→物理模型”的层次，逐步将业务概念细化为具体的数据库表、字段、索引与约束。设计过程中必须严格遵循前期制定的规范与数据标准，确保模型的规范性、一致性与可理解性，最终通过严格的评审后才能发布生效，指导开发。
(3) 数据模型维护
数据模型并非一成不变，需要及时根据应用情况、业务目标进行调整和更新，并监控数据模型与实际应用是否一致，确保数据模型能够随着业务发展而持续演进，并始终保持其准确性与有效性。核心工作包括通过工具定期监控物理数据库结构与设计模型的一致性，杜绝“两张皮”现象；对模型变更实施管控，确保变更可控、影响可知、历史可追溯，从而保障数据仓库的长期稳定运行与持续价值输出。

1.2.2. 实施策略
-顶层设计与敏捷交付相结合，选择适配的建设路径
数据模型设计不应拘泥于单一模式。针对新建平台、系统重构或需要建立长期统一视图的战略项目，可以考虑增加顶层设计阶段的投入，采用组织级整体规划路径，自顶向下系统性地设计主题域与概念模型，夯实数据架构根基，从根本上规避数据孤岛。对于需求明确、急需见效或资源有限的情况，则更推荐采用需求导向的敏捷建模路径，以具体业务场景为驱动，快速交付数据模型，迅速验证价值。实践中，两种路径可并行或分阶段采用，例如先通过敏捷路径在核心业务域取得速赢、建立信心，再逐步完善和归并到企业级整体蓝图中。
-将数据模型管理纳入数据治理整体工作，实现联动与协同
数据模型是数据治理成果的核心载体与具体体现，其管理工作不应孤立进行。应当将数据模型的全生命周期管理（设计、评审、发布、变更、下线）主动嵌入组织的数据治理体系之中，与数据标准、数据质量、数据安全及主数据管理等模块建立强关联。在模型设计阶段即引用已发布的数据标准，确保属性定义、编码规则统一；在评审阶段需加入数据质量规则的核查点，从源头规避设计缺陷导致的质量问题；在运维阶段，模型的变更必须触发相关联的数据资产目录、血缘关系的同步更新等。从而确保数据模型不仅是技术设计的成果，更是承载了组织数据治理规则、支撑数据价值可持续释放的关键基础设施。

1.2.3. 常见挑战与解决方法
-数据标准如何在数据模型中落地？
在数据模型建设的过程中经常会出现无标准可依或者是有标准不依的现象，针对这种情况，数据治理团队可以分步骤制定数据标准，数据模型中属性的中文名称的命名、英文名称的命名、数据类型、数据值域、关联代码等都要遵守组织中相关的数据标准规范，如数据元标准。同时，在数据模型评审过程中，建立标准的检查机制，让数据标准能严格执行，以便在事前发现问题并及时解决问题。如果已经制定了数据标准却执行不到位，那么数据标准如同虚设。解决了这些问题，意味着夯实了数据模型的标准基础，让数据模型的建设和落地没有后顾之忧，同时为数据质量的提升也提供了保障。
-数据模型如何保持长期有效？
数据仓库是数据模型的实例化体现，数据模型的无序变更会造成数据仓库的失控，如果缺乏管理，很容易造成数据模型和实际数据仓库不一致性的“两张皮”现象。比如，开发人员为快速满足需求直接修改数据库结构，在变更数据模型时没有从数据设计、业务合理性、数据质量规则、数据库性能等方面进行综合评审。为了保持数据模型的长期有效性，规范数据仓库建设，应当在数据模型的管理过程中，建立审核机制并保留变更记录便于追溯，禁止直接操作数据库修改物理表。同时应建立一致性监测机制，时刻保持数据模型与数据存储的一致性。

1.3. 实施流程

1.3.1. 实施概述
数据仓库及数据模型管理是贯穿“规划－设计－维护”全生命周期的系统性工作，需结合业务目标、技术规范与数据治理要求，各步骤工作内容环环相扣，确保数据仓库的规范性建设和满足数据应用的便捷性。

1.3.2. 数据仓库规划
1.3.2.1. 实施概述
表 1 步骤1 数据仓库规划实施概述

1.3.2.2. 活动
1.3.2.2.1. 数据仓库架构选择
数据仓库的选择需要综合考虑业务需求、技术能力、成本等多方面的因素，在此基础上选择适合组织当下并适当考虑长期发展的数据仓库。
推荐的数据仓库架构包括传统数仓架构、大数据架构以及流批一体架构。
(1) 传统数据仓库
在传统的数据仓库中，主要是将结构或半结构化数据通过离线ETL定期加载，之后再通过计算分析供业务使用。数据仓库的建设一般基于Oracle、MySQL、达梦、海量等数据库，但在当下，仍需考虑信创要求，优先选择国产数据库。传统数据仓库能够满足90%以上的数据仓库建设场景。

图 5 传统数据仓库架构示意图

(2) 大数据架构
传统数据仓库的缺点是时效性和数据存储类型的限制。随着数据规模的不断扩大，传统数据仓库架构难以承载海量数据。因此，随着大数据技术的普及，我们通常采用大数据技术来承载存储与计算任务，例如Hadoop+Hive/Spark、Doris等。大数据架构与传统数据仓库架构的明显区别在于数据存储方式的不同，由HDFS、对象存储、MPP数据库等方式替代传统的关系型数据库，结合Spark、MapReduce等计算框架和Hive、SparkSQL、Impala等查询框架共同构成。

图 6 大数据架构示意图

(3) 流批一体架构
随着业务的发展，对数据实时性提出了更高的要求，将对实时性要求高的部分拆分出来，增加了一条实时计算链路，从源头开始做流式改造，将数据发送到消息队列中，实时计算引擎消费队列数据，完成实时数据的增量计算。与此同时，批量处理部分依然存在，实时与批量并行运行，最终由统一的数据服务层合并结果提供给前端。

图 7 流批一体架构示意图

1.3.2.2.2. 数据仓库层次规划
数据仓库分层在数据仓库建设中扮演着关键角色，不同层次的数据承担不同的职责，每个层次专注特定的功能，使数据仓库的结构更加清晰，让数据归集、清洗、分析等数据处理流程功能单一，提高可维护性。通过分层对贴源层数据进行清洗、转换和校验之后形成高质量的治理层数据，为应用层提供基础数据，保证数据质量。同时，数据仓库分层能够更好的满足不同的应用场景，贴源层保留原始数据，适合深度挖掘，而应用层提供聚合和整理的数据，适合快速生成报表和进行宏观分析。
结合多年行业经验，本指南将数据仓库分为来源层（SRC，Source Data）、贴源层（ODS，Operational Data Store）、（DW，Data Warehouse）、应用层（ADS，Application Data Service）和共享层（DS，Data Share）。

表 2 数据仓库分层示例

1.3.2.2.3. 数据仓库规范制定
数据仓库建设规范是数据管理制度体系的组成部分，主要包括数据仓库的分层架构、数据模型设计规范、数据仓库为运维制度等内容。应明确数据仓库各个层次的数据存储结构，为数据模型管理提供统一的、规范的、标准化的工作流程和设计规范，能够使数据仓库更好地组织和管理数据，锚定业务价值，统一建模标准，避免后续开发偏离方向或产生数据混乱。
结合多年实践经验，本指南认为数据模型的建设应遵循以下原则：
(1) 针对贴源层，一般情况下不需要进行建模操作，仅需要根据来源数据逆向出物理模型即可，无需创建概念模型和逻辑模型；
(2) 针对贴源层的物理模型，在与来源数据结构保持一致的基础上，增加来源部门、数据处理时间等字段，便于后续的数据来源统计和分析；
(3) 治理层需要对数据进行整合和标准化处理，数据模型应遵循组织制定的标准规范，包括数据元标准、字典标准等。在组织没有制定标准时应尽量参考国家标准、行业标准和地方标准。
(4) 适度地规范化，规范化有助于减少数据冗余，保证数据的一致性和完整性。过度规范化可能会导致查询性能下降，因为复杂的查询可能需要进行大量的表连接操作。因此，在某些情况下需要进行反规范化处理。比如在应用层的宽表。
除此之外，应立足全局制定数据模型设计过程中应遵循的技术规范：
(1) 数据库名称。数据库名称必须全局唯一，建议采用“数据仓库分层_数据库名称”的格式，命名全部小写，不应包含特殊字符；
(2) 物理表名称。ODS层物理表名称建议采用“ods_来源库名称（10个英文字符以内）_表名称”的格式，尽量保留源系统表名的关键部分，以便追溯，若源表名过长，可适当缩写，但要保持含义清晰。DW层建议采用“dw_表名称”。ADS层物理表采用“ads_业务场景名称（10个英文字符以内）_表名称”的格式。
(3) 字段规范：1）字段命名以小写全称，尽量使用业务术语，避免使用模糊的缩写；2）根据实际情况设置数据类型和长度，避免出现全部是字符型、长度全部是100的现象；3）日期类型统一使用“YYYY-MM-DD”格式、金额类型使用“DECIMAL(18,2)”；4）禁止使用数据库的保留字作为命名，如from、where等；
(4) 约束规范：增加必要的数据约束，包括主键、非空等，保证数据完整；
(5) 引用数据标准规范：模型设计应以组织已制定的数据标准作为依据，包括名称、类型、长度、值域等内容。

1.3.3. 数据模型设计
1.3.3.1. 实施概述
数据模型设计的本质是将组织业务对象、业务过程转换为数据模型以及数据模型之间的关系，是将数据从业务视角转换成技术视角的过程，即通过主题域模型、概念模型、逻辑模型、物理模型以及评审发布五个环节，逐步细化和实现从业务到数据存储物理结构的转换。
在实际落地中，可以根据项目目标、资源分配等选择合适的数据模型设计路径。以下是两种经典路径：
路径一：企业级整体规划与建模：适用于战略级数据平台建设，采用自顶向下的方式，以组织全局视角完成主题模型→概念模型→逻辑模型→物理模型的完整设计。此路径从组织整体业务出发，系统性地构建全局一致的数据骨架，为复杂分析与长期数据资产管理奠定坚实基础。其挑战在于设计周期较长，对业务抽象能力、资源投入及跨部门协同的要求较高。
路径二：以需求为导向的敏捷建模：适用于需求明确、快速迭代或试点项目，采用需求驱动的方式，依次完成需求分析→逻辑分析→数据探查→模型设计的敏捷设计，其中模型设计部分可以裁剪主题模型→概念模型→逻辑模型→物理模型的设计路径。这种方法以具体业务价值为导向，能够快速交付可用的数据模型，有助于在短期内建立信任并验证数据治理的价值。但其聚焦于局部需求的特点，可能导致模型之间缺乏整体协调，未来随着需求增多可能面临模型冗余或整合的挑战。
两种路径其实并非互斥，可以根据实际情况结合使用。下文将围绕完整的模型设计步骤展开，各实施团队可以根据所选路径，侧重或复用相应环节。

表 3 步骤2 数据模型设计实施概述

1.3.3.2. 活动
1.3.3.2.1. 主题模型设计
数据主题模型是最高层级的，以各个主题概念及其之间的关系为基本构成单位的数据主题集合。
主题划分要遵循全局性、可理解性、适中的原则，要既能涵盖当前所有的业务需求，又能让新业务在进入时可以被已有的主题域或扩展的新主题域包含。常见的主题划分方法有按来源系统、按业务部门，本指南推荐基于“摸家底”阶段梳理出的业务域，将业务视角的领域转化为数据视角的主题，形成统一的组织数据视图，如常见的人力资源管理、财务管理、市场营销、库存管理等业务域。
主题模型的设计主要包括明确主题边界和确定主题关系两个步骤。
(1) 明确主题边界。对已梳理的业务域进一步分析，形成对应的数据主题，并清晰界定每个主题的范围。保障每个主题相对独立完整，为后续建模提供方向。
(2) 确定主题关系。分析各主题之间的关联，理清数据脉络。
1.3.3.2.2. 概念模型设计
概念模型用来定义重要的业务概念层面的实体及其关系，如客户、供应商、产品、合同、渠道、生产等。
其设计主要包含两个核心活动：确定核心业务实体，并建立实体间的业务关系，从而形成反映业务本质、独立于技术实现的高层数据视图。
(1) 确定实体
从业务调研结果中抽象组织最高层级的概念，如客户、供应商、商品等，将之定义为实体。这些实体是业务活动的核心对象。
(2) 建立实体关系
梳理实体之间在业务流程中的相互关系。常见的关系类型有一对一（1:1）、一对多（1:N）、多对多（N:N）。为每种关系赋予清晰的业务含义，确保技术人员和业务人员理解一致。
以下图为例，根据“货从哪来，钱如何结算”视角，识别出最核心的3个业务对象实体：商品、客户和供应商。由商品分别与客户、供应商之间的联系，再识别出销售订单和采购订单2个实体。各实体关系如下。

图 8 概念模型示例

1.3.3.2.3. 逻辑模型设计
与概念模型相比，逻辑模型增加了对数据元素和结构的定义，确定每个实体的属性，包括名称、数据类型、长度、取值范围、是否为主键等。但逻辑模型是独立于数据库系统设计的，到这一步还无法直接用于数据库的开发。
(1) 细化实体与属性
对概念模型中的实体属性进行更详细的定义，明确每个属性的数据类型，如整数型、字符型、日期型等。同时，确定属性的长度、精度以及是否可为空等约束条件。如果组织中已经定义了数据标准，逻辑模型中应遵循和采用数据标准中的定义。
以概念模型示例中的“客户”实体为例，对其属性的定义如下。

表 4 逻辑模型设计-细化实体与属性示例

(2) 属性拆分
逻辑模型中的属性具有原子性，它应该包含一个且只有一个数据（事实），不能被再次拆分。
以上述“客户”实体的属性为例，“联系方式”属性其实是一个复合属性，应该再拆分为2个原子属性，分别是手机号码和邮箱。

图 9 逻辑模型设计-属性拆分示例

(3) 添加衍生属性
根据业务需求，识别并添加一些通过其他属性计算或推导得出的衍生属性。
以上述“客户”实体为例，通过出生日期计算出“客户年龄”属性、基于累计消费金额划分“客户等级”属性、根据“注册日期”计算出“入会年限”属性，形成新的“客户”实体属性。

表 5 逻辑模型设计-添加衍生属性示例

(4) 确定数据完整性约束
数据的完整性约束包括确保每个实体的主键具有唯一性和非空性、保证外键引用的有效性和业务规则约束。为每个实体确定主键，主键是能够唯一标识实体中每一条记录的属性或属性组合。
以上述“客户”实体为例，其属性的约束如下。

表 6 逻辑模型设计-确定数据完整性约束示例

(5) 添加关联实体
在完成对单个实体内部属性与约束的设计后，接下来需要设计实体之间的业务关系。当实体间存在“多对多”的复杂关系时，需要创建关联实体来准确描述这种关系，并记录相关的业务事实。关联实体从关系中涉及的实体获取标识属性，并将它们放入一个新的实体中。该实体只描述实体之间的关系，并允许添加属性来描述这种关系。
以3.3.2.2概念模型设计示例中的销售场景为例，“销售订单”和“商品”实体原本是多对多关系，销售订单只能记录包含了哪些商品，却无法记录同一订单中不同商品的具体购买数量、成交单价或折扣信息，这导致关键交易细节丢失。
因此，新增关联实体“销售订单明细”，作为“销售订单”和“商品”实体间的关联纽带。并为“销售订单明细”其识别出数量、单价等属性，使得一个订单可完整记录一次交易行为的所有信息。同理，在采购部分也增加“采购订单明细”实体。
在维度建模中，关联实体“销售订单明细”通常被称为事实表，它能够准确、清晰地反映客户与商品之间的购买行为事实。
经过以上步骤，最终形成的逻辑模型示例如下。

图 10 逻辑模型设计示例

1.3.3.2.4. 物理模型设计
根据逻辑模型设计物理模型，是将抽象的逻辑结构转化为具体数据仓库可实现的过程，需要充分考虑所选数据仓库的特性、性能优化以及实际存储需求等因素。根据不同的数据仓库架构，物理模型的设计可能会有所差异。
(1) 映射逻辑结构到物理结构
将逻辑模型中的实体直接映射为物理表。根据逻辑模型中实体的属性，为每个表定义相应的列，并确定每列的数据类型。例如，在逻辑模型中“客户”实体有“客户编码”（整数型）、“客户姓名”（字符型）等属性，在物理模型中“客户”表就对应有“khbm”（INT 类型）、“khmc”（VARCHAR 类型）等列。
(2) 主键和外键的实现
逻辑模型中的主键和外键约束在物理模型中通过数据库的特定机制来实现。在大多数关系型数据库中，使用 PRIMARY KEY 关键字定义主键，FOREIGN KEY 关键字定义外键。
(3) 索引设计
分析查询需求，为经常用于查询条件、排序或连接操作的列创建索引。索引可以加快数据的检索速度，但过多的索引会增加数据插入、更新和删除操作的开销。例如，如果经常根据“客户姓名”查询客户信息，可在“客户”表的“khmc”列上创建索引。
(4) 分区设计
对于数据量巨大的表，考虑进行分区。例如，按时间（如按月、按年）对销售记录表进行分区，将不同时间段的数据存储在不同的分区中。这样可以提高查询性能，特别是在查询特定时间段的数据时，只需扫描相关分区，减少数据扫描范围。
(5) 验证与优化
对物理模型进行验证，确保其能够满足业务需求和性能要求。可以通过模拟实际业务场景进行数据加载和查询测试，检查数据库的性能指标，如查询响应时间、吞吐量等。根据测试结果对物理模型进行优化，如调整索引策略、优化分区设置等，直到物理模型达到最优性能。
1.3.3.2.5. 评审与发布
数据模型设计的评审环节是在设计人员完成模型设计后，由数据治理团队内的技术专家和业务专家共同完成评审，至少包含如下内容：
(1) 基于设计与需求的一致性进行检查，模型是否满足需求所要求的功能和性能。组织的业务对象、业务流程是否都有对应的实体、属性和关系的体现，属性是否完整。
(2) 模型中数据标准的落地情况，是否已引用已制定的数据标准，重点考察重要属性的落标率，包括业务术语是否一致、业务含义是否清晰、数据类型与精度是否满足需求。
(3) 数据模型的名称、所属层次是否符合模型的规范。
(4) 实体之间的关联关系是否正确反映业务。
(5) 从技术方面，评审索引设计是否合适、分区设计是否合理等方面。

1.3.4. 数据模型维护

1.3.4.1. 实施概述
数据模型维护的工作是保障数据模型长期有效的重要手段，包括数据模型的一致性监测、数据模型的变更管理两个过程。

表 7 步骤3 数据模型维护的实施概述

1.3.4.2. 活动
1.3.4.2.1. 数据模型的一致性监控
发布上线的数据模型会进入运维阶段，这个环节的管控任务主要是确保数据模型与生产环节投产的数据库结构一致，从而避免数据治理人员随意修改数据结构，影响上下游系统对数据的使用。
通过数据模型管理工具的自动差异发现功能，可以快速定位本次版本的模型和上一版本基线模型的差异，主动将变更明细通知相关方，及时进行适应性调整，提升数据变更对上下游影响的协同效率。
1.3.4.2.2. 数据模型的变更管理
当业务需求发生变化或数据环境发生改变时，需要对数据模型进行相应的变更。数据模型变更控制的严格程度取决于组织对模型的管控策略，但至少我们应保持物理模型与实际数据库存储的一致性。例如，业务部门提出新的主题统计需求，我们可能就需要修改各个分层的数据模型，以满足数据归集、清洗、融合和统计的需求。
对数据模型的每次更改，都需要详细记录变更内容，包括：
(1) 变更原因，为什么需要变更。
(2) 变更对象以及变更内容，包括添加了哪些表，修改或删除了哪些列等。
(3) 由谁做出了变更。数据模型管理工具应提供数据模型版本控制和变更日志的管理功能。

（或访问：https://xcnoejbrkx3v.feishu.cn/drive/folder/HCXufFf6ilq0ejdF5Hmc3CJhnYf）

本书采用了开放式共创的编撰模式。我们坚信，内容的可靠性与实践性来自持续的交流与共创。因此，我们诚挚邀请您——每一位关注数据治理的同行者、实践者与思考者——加入本书的共创计划。

如果您在阅读过程中，提出关键修正、贡献具有借鉴价值的优质案例，或补充了不可或缺的核心内容，我们将诚挚邀请您成为本书的共同署名共创者，并参与后续的专题研讨与行业交流，共同推动数据治理领域的实践进步与生态发展。

愿这本书不仅是一本指南，更是一次连接行业、凝聚共识、共创未来的行动。

【第三部分 实施篇】第7章 数据仓库及数据模型管理

【第三部分实施篇】第7章数据仓库及数据模型管理