▌概念数据模型

数据架构的最顶层视角是主题域（Subject Area），从最顶层视角对数据进行高度抽象形成概念分组。

主题域是数据建模的起点，数据建模就是在一个主题域内逐步对数据的概念和关系进行梳理和详细设计的过程。

根据模型设计阶段和详细程度的不同，可以将数据模型划分为概念数据模型（CDM：Conceptual Data Model）、逻辑数据模型（LDM：Logical Data Model）和物理数据模型（PDM：Physical Data Model）。

有些方法论中会根据角色和视角的不同，划分成更多的阶段或层级，总体来说，概念、逻辑和物理的三层架构是从理论和实践角度都比较普遍的划分方式。

对于技术人员来说，最直观可见的就是数据库的表结构（Schema），通过逆向工程（Reverse Engineering）的方式将数据库中的表结构抽取出来，通过可视化的方式生成的模型图可以理解为物理数据模型。

通常逻辑数据模型和物理数据模型从结构上看起来并没有太大的差别，主要差别是在业务逻辑和关系描述的详细程度上，所以，逻辑数据模型的形态比较容易理解。

但是，概念数据模型与逻辑数据模型的抽象程度差别较大，导致很多人不理解概念模型应该是什么样的？以及概念模型存在的意义是什么？应该如何设计？设计的边界和规范是什么？等一系列细致的问题。

因此，本文希望从概念建模的目的、工具和流程几个方面来回答这几个问题，希望能够帮助你更好地理解概念数据模型，也希望能够帮助你在设计概念数据模型的时候减少一些纠结，更好地使用概念数据模型这个工具梳理对业务的理解，拉通业务和技术。

▌概念模型又称为主题域模型或业务对象模型

概念模型是一个广泛使用的术语。

不过，由于它一般是以主题域为单位展开设计，描述的是这个主题域内部关键实体和实体之间的关系，所以，在一些书中有时候也有被叫做主题域模型（Subject Area Model）的时候。

概念模型是业务需求分析过程中常常使用的工具，其中定义的实体是业务层面的一些核心的概念，定义的关系中包含着业务核心对象之间的关联性，所以，对于业务分析师来说，可以称之为业务对象模型（Business Object Model）。

▌概念模型是提高需求分析效率的可视化工具

在信息系统建设过程中的需求分析阶段，需求提出方和需求分析方要投入大量的时间沟通业务的详细过程，才能努力达成对需求理解的一致。

这个阶段通常会定义业务需求中的关键实体和实体之间的关系，比起表格或文档的形式来说，通过可视化的模型图的方式能够显著地提高沟通的效率。

所以，概念模型中描述的内容是面向业务、面向需求的，是给需求提出方和需求分析方提供的可视化设计与沟通工具。

▌概念建模是数据建模一部分，是设计数据模型骨架的过程

数据架构的构建是自顶向下的，先做顶层规划，再逐步细化，最终在数据库中创建表、字段等数据库对象，顶层规划的范围决定了数据架构和系统建设的整体范围。

数据建模的过程是从分析业务需求开始，为了描述业务中的关键信息，优先提炼关键实体、属性和关系，建立整个模型的骨架。

逻辑模型设计是进行详细设计的阶段，在完整地设计完所有实体、属性和关系之后，进行范式化、实体整合等设计过程。

物理模型设计阶段中，需要结合特定数据库的特性设计索引、分区，根据需求查询和开发编码的需求，进行反范式化设计等过程，这个阶段需要考虑的技术性因素非常多。

所以，数据建模的工作需要很强的综合分析和判断能力，不仅要理解业务，还要结合技术因素设计物理模型，最终，在数据库中创建真实表结构。

要同时兼顾业务表达清晰、结构灵活可扩展、数据加工处理性能还是很难的，整个过程中需要大量的博弈和权衡。

对于综合能力较强且设计经验丰富的数据建模师来说，可能在设计的前期阶段就会对后续阶段做预判和准备，例如，设计实体的过程中就会考虑未来的查询场景、未来一定时间内可能会产生的数据量等，这都是很正常现象。

但是，对于经验不足的初学者，因为知识和经验积累不足，很难在短期内考虑全面，所以，为了保障设计过程的统一和规范，按照标准化的设计流程开展工作，按部就班地一步一步开展工作，还是非常有必要，并且有很多好处的。

▌概念模型中设计的是关键实体、关系和属性

概念模型中的实体这个概念，也经常会有不同的叫法，从数据建模的角度来说，都可以定义为实体，只是实体设计的目的和内容存在一定差别。

有些方法论中，为了区分概念模型和逻辑模型中实体的特征不同，将概念数据模型的实体称之为业务实体（Business Entity）或业务对象（Business Object）。

例如，在《华为数据之道》中，将概念模型中的实体定义为“业务对象（L3）”，将逻辑模型中的实体定义为“逻辑数据实体（L4）”，在业务对象建模的理论中，也将这个阶段的实体定义为业务对象。

实体叫什么名称其实并不是那么关键，最关键的是概念模型是为了明确地表达业务中的概念，促进相关方快速达成理解的一致。所以，在概念模型设计的过程中只定义关键实体、属性和关系。

如果在概念设计阶段，把实体、关系和属性设计得过于详细，反而会失去重点，起到相反的作用，理解和沟通起来会很困难。

在提炼关键实体的过程中会始终贯穿着 5W1H 和二八法则的思想。

使用 5W1H 分析法，优先提炼最关键的那百分之二十的业务对象，业务对象可以是行为的主体，也可以是业务的活动和过程。例如，在常见的交易型系统中，关键的主体是客户，对象是商品，关键的业务过程是订购。

关键实体和关键属性通常是一体的。

有些建模师认为在这个阶段为了让模型看起来简洁明了，不需要在模型中设计关键属性，包括关键实体的标识符。

这个观点也是有道理的，只是“要不要在概念模型中设计关键属性？”这个问题，并没有权威的出处给出一个标准的答案，其原因，可以理解为每个团队和企业的规范不同，所以，会存在不同的要求。

个人认为关键属性和实体的标识符从一定程度上能够帮助模型的读者更好地理解实体的本质（也就是实体中包含哪些数据）。例如，如果一个实体中包含客户名称、身份证号码、手机号码等关键属性，一般可以推断出这个实体是“客户”。

所以，如果能够通过少量的属性，明确表达实体的本质概念，促进大家对概念理解的一致性，在概念模型中设计标识符和关键属性也没有什么问题。

在概念模型中，实体之间的关系也是非常重要的。不过，关系也只建议设计重要的关系，实体和实体之间可能会存在很多关系，过多的关系线错综复杂，必定会增加模型图的复杂度。

而且，概念模型中允许存在多对多关系，从某种角度来说，也是为了避免在这个阶段就把关系设计得过于详细。

▌逻辑模型设计是概念模型设计的延续，对概念数据模型进行详细设计

在从零到一设计一个数据模型的过程中，必然会经历概念、逻辑、物理三个阶段，即使在流程上跨过概念模型设计过程，从逻辑模型开始，也必须要优先提炼关键实体、关系和属性，这个过程就相当于经历了概念模型设计工作。

正因如此，才会说概念模型设计是搭建模型骨架的过程，逻辑模型要延续概念模型设计的成果，进行更加具体和详细的设计。

概念模型中的关键实体和关系会延续到逻辑模型当中，也就是说大部分概念模型中的业务对象或实体都能够在逻辑模型中找到对应的逻辑实体，只不过他们之间的关系并不是一一对应的，可能存在一对多的关系。

从逻辑模型的角度来说，逻辑模型中的关键实体都要向概念模型中的业务对象对齐，维持他们之间的对齐（Alignment）关系。

“概念模型和逻辑模型的边界是什么？”这个问题也经常会困扰很多人。

从概念模型在业务需求分析过程中承担的作用来说，只要满足相关方业务沟通的目的就可以，没有必要增加概念模型的复杂度。

从逻辑模型设计的角度来说，概念模型设计的成果能够保证数据模型整体骨架稳定的程度就可以，细节的设计可以在逻辑模型设计过程中细化。

也就是说，对于关键实体来说，如果在逻辑模型设计过程中，没有找到与概念模型相对应的业务对象，需要在概念模型中补充设计，确保向概念模型对齐的原则。

而概念模型中，大部分业务对象都应该落到逻辑模型中，但是，也允许仅表达业务说明而设计的业务对象存在，这些业务对象，不一定必须要落到逻辑模型中。

▌概念模型设计过程中最难的就是实体设计

在概念模型设计阶段，“实体的命名是否准确？”“实体的性质和构成是否定义清楚？”“实体是否可以抽象或泛化为更高一层的概念？”，这些问题也是概念模型设计过程中让很多人困扰的事情。

不仅仅是概念模型，在逻辑模型设计的阶段也同样会面临这样的问题。

实体设计的方法，后续会另外详细介绍，本文中不再说明太多。

要想设计好实体除了一些方法以外，还存在一定建模经验上的要求，不存在一种完美的方式。

建议可以学习一些在不同行业中具有一定通用性的参考模型，会对数据建模的提升有很大的帮助。