如果您刚开始接触数据建模，不清楚如何创建或表达数据建模的业务价值；或者您在企业中属于类似业务架构师角色，感觉到应用系统生产的数据跟业务流程没有一个合适的沟通接口；或者您是数据分析架构师，但您总感觉没有一种合适的形式去与业务组织去明确沟通需求；或者…
从数据架构师的角度来看，这些问题都可以通过建设概念数据模型来解决，也就是在数据建模中的概念建模模式。我们来分享概念数据模型的最佳使用方法，以解决您的困惑，促进组织内相关项目的成功。
▌什么是概念数据模型 （CDM）？
概念数据模型是组织在其业务运营中使用或打算使用的数据的高级、抽象表示。它提供了组织或特定业务项目中数据需求的全局视图，而无需深入研究如何存储或操作数据的技术细节。概念数据模型的目标是通过捕获业务或组织的基本概念来创建对业务的共同理解。
那么，“共同理解”和“基本概念”是什么意思呢？对业务的共同理解可确保每个人对基本概念（包括包含或排除的概念）具有相同的定义。基本概念是指角色、人员、地点或流程，它们是商业模式不可或缺的一部分。请记住我们在建设概念数据模型要从大处着眼，从小处着手，并可实现快速扩展。
从数据建模的建模模式的层次分类来说，基本上可以分为概念、逻辑、物理这三种类型。当然如果您的建模是在数据仓库、数据湖、数据中台、湖仓一体、云存储等大型存储中心上，在最前端还有主题模型的级别。概念数据模型是三种主要数据模型类型中的第一种。
▌概念数据建模的价值
创建概念数据模型的过程将会生成两个主要建模成果——实际的概念模型（CDM）图和基本概念的定义。通过与业务组织的根据CDM图和概念不断确认及修改，最终达成在组织中或特定业务项目组织中对业务的共同理解。
概念数据模型的真正价值在于：
▎将业务驱动因素、战略目标和战略与业务问题、事实和限定词联系起来
▎在技术和业务之间建立共识，实现清晰的沟通并促进对基本要素的辩论
▎提高未来数据模型（To Be模型）的清晰度和精确度
▎创建可验证的上下文和问题范围的边界
▌如何创建概念数据模型
▎示意基本概念实体，并建立概念实体间的数据关系（画图）
图 1 - 仅包含实体和关系的事务性 CDM
图 1 中的简单图表演示了酒店预订系统的基本组成部分，包括人员（客户和客人）、物理建筑（酒店）、物业的细分（房间）以及房间和客人的交集（预订）。
图 1 中示意未定义实体之间关系的基数。它只定义关系的方向。其中有些关系是双向的，通常这意味着关系基数是多对多的。虽然关系基数很重要，但我们要理解影响概念模型的通常不是细节或复杂性。更重要的概念实体间事实上存在关系。
图 2 - 具有实体、关系和标识符的事务性 CDM
图 2 演示了一种略有不同的样式，它添加了实体的关键标识，例如房间和确认编号。不过在概念数据模型中，这些关键属性可以不用标注其数据的数据类型。在这里实体间的关系将会显示基数，但它会缺少关系的描述。我们可能发现，严格来说，上述图中将关系的描述标注上去会更好，但是关于概念数据模型的可视化要求相对于逻辑模型和物理模型不那么严格。因为概念数据模型还有一个关键的产物是基本定义和概念的输出，通过建模工具可以记录这些基本定义和概念，也可以用如“word文档”来记录并作为“基本定义和概念”的输出。
CDM 的目标是捕捉并确认业务的本质，并可以促进组织中不同角色、不同知识背景、不同工作背景进行沟通。因此，技术部门可能不会反对使用与正式数据图表密切相关的 CDM图。相比之下，非技术性业务导向的利益相关者可能还会想要如酒店的图像、客户的画像和关于人际关系的故事。
所以我们的主要结论是：
1. 首先观众很重要
2. 概念数据模型的图表表现没有单一的最佳格式，假如标准的CDM模型图不合适，也许我们可以使用业务草图。
3. 概念数据模型的图表应可以捕捉业务的要点。概念数据模型的概念实体不能太多，一般我们会将概念数据模型称为一页纸的模型，可以用一页纸清晰地表达业务的要点。
▎添加业务定义
前面我们将业务要点通过图形表达出来，我们还必须构成概念数据模型的业务定义。这些定义将描述概念实体和实体间的数据关系。下面是一个快速示例：
图 3 - 实体和关系的定义
▎通过协作验证共享理解
最后，这一点也可以称为模型的协作建模和评审阶段，需要利益相关人一起来讨论并验证一下模型中表达的共同理解。我们的业务利益相关者应该能够阅读定义，查看数据模型图（通常只有一页），建模师能明确回答他们的关键业务问题。概念数据模型表达的内容应该是有边界的或者有特定业务场景的。如果概念数据模型没有业务场景边界，那从另一角度来说它就不能代表业务利益相关者关注的业务要点。
协作对于使这一过程有价值及富有成效至关重要。我们需要知道的是，概念数据模型不能是建模师独有，不是建模师的个人资产，它应属于组织或者特定项目团队，准确来说应至少属于包括业务高层、业务架构、数据架构、建模师共同的资产。所以在整个概念数据模型的建模过程中，如果没有与业务利益相关者的协作，概念数据模型将很有可能没有业务价值。
在整个建模过程中涉及利益相关者的迭代过程，将确保对模型的任何更改都是小的中期调整。它还确保 CDM 准确反应业务目标，并确保模型的最终评审简单易完成。
▌用于数据和分析的概念数据模型示例
业务对象将决定如何执行概念数据建模过程。您是否正在为移动应用程序构建事务模型？业务线的分析模型怎么样？还是用作企业数据仓库的仓库模型？
请记住，概念数据模型独立于底层数据平台技术，但会根据数据的用途有不同的建模方式，也会影响建模过程。下面是几种类型的概念模型示例。
▎事务型
为事务系统开发 CDM 通常需要了解数据访问及时性、事务完整性、客户体验、可伸缩性和易用性的独特要求。这些类型的系统可能会是在线零售、预订系统、库存系统甚至一些金融服务系统。前面与酒店管理相关的示例，请参阅图 1 和图 2。
从示例中我们可以了解概念数据模型都关注客户、房间和预订等重要实体。模型中还标识了关键属性，如客户 ID 和确认编号。最后，它标识实体之间的业务交互。它不关注实际表、列名、数据类型或PK/FK 关系。所有这些都在业务定义中定义。请参阅图 3 中的示例。
▎分析型
图4 - 用于分析的CDM
分析用例的 CDM 通常侧重于使用定量和定性措施来衡量业务流程。我们在这里关注的实体是数据的聚合和类别。出于这个原因，分析CDM通常看起来像一个具有事实和维度的星形图。
我们可以回想一下，在分析开发中，当业务目标上定义了数据模型的活动（分析路线）和输出（如报表）。分析方案通常会开发出事实和限定条件矩阵，我们可以称为事实限定矩阵 （FQM）。FQM将定义了三个概念：
l 度量 - 我们的业务需要了解业务流程的聚合
l 限定 - 度量值的类别、分组和条件
l 交集 - 显示哪些限定适用于哪个度量值的连接
图5 - 事实限定矩阵
创建 FQM 并不困难，它将用于验证您的概念数据模型。要创建 FQM，只需建模师去询问您的利益相关者（示例）：
l 用什么措施来了解业务？
l 如何对度量进行限定、分组或分类？
l 度量需要多细化？例如，按天？按小时？按月计算销售额？
l 对于每个度量值，确定限定条件是否可以应用该度量值。
正如在我们的示例中看到的那样，非技术人员可以轻松理解我们的图表和 FQM。他们可以看到，该系统将按酒店、房间和客户衡量一段时间内的收入。FQM 也是验证和确认模型的宝贵工具。
▎企业级
由于利益干系人、业务线和大型组织的复杂性增加，企业级CDM 带来了额外的挑战。但是如果有可参考的行业模型及主题分类，它并不是一个很难的问题。这就是最开始提到的在概念数据模型这个级别上，还有更高级的级别存在——主题模型。
主题模型能够将模型细分为单独的逻辑组或域。数据建模是一个迭代过程，在使用主题模型时更是如此。为了有效地使用主题模型：
l 让业务领导者和利益相关者参与进来，以确定共同的主题模型。
l 确定应解决哪些主题模型以及解决的优先次序。
l 对于每个主题模型，重复标识实体、属性和关系的过程。
一旦特定主题模型的 CDM 完成，就可以开始逻辑和物理建模。不是一定得等到全部完成了企业级的主题模型及各下属的概念模型，才进行逻辑和物理建模。
如图 5 所示，该模型侧重于预设主题模型，并链接到其他主题模型，如营销和支付。以这种方式使用主题模型可确保您保持在一定范围内容讨论并确保所有利益相关者看到他们的关注点是如何得到解决的。
▌关于概念数据模型的关键要点
总结，以下是一些概念数据模型的关键要点：
l 概念数据模型提供组织数据需求的全局视图，而无需深入研究技术细节——保持您的建模范围。
l CDM抓住了业务问题的本质，并将与未来的逻辑和物理数据模型保持一致。
l 健康协作机制的主要目标是在技术和业务团队之间建立共识，实现清晰的沟通并促进对基本概念的辩论。
l 实体、关系和核心概念的定义是概念数据模型的一部分。该模型不仅仅一个模型图。
l 直观地表示 CDM，并使用他们认为最吸引人的沟通方法和风格将内容传达给利益相关者。
构建概念数据模型是交付成功数据计划的第一步，也可以说是最重要的一步。通常，我们急于实现物理模型，但有时需要放慢速度才能加快速度。与业务利益相关者建立信任和信心将确保您在未来提供更好、更快的数据模型。