数字化转型与架构 - 架构设计篇｜建模之数据模型

　　数据模型与之前介绍的系统建模有一定差异。系统建模更多从不同的视角对系统进行全面的描述，数据模型固定在数据视角，所以数据模型是一个从设计到实现的递进层次关系。

建模关系示意图

一、建模层级

　　数据模型包含三个层面，概念模型、逻辑模型和物理模型。使用三层模型可以更好的分离业务与数据管理系统的实现，其中逻辑模型层是一个适配层。

　　概念模型是数据模型中最抽象的一层，此层只关注描述数据自身的属性和数据与数据之间的关系。此层忽略技术实现上的细节，通过模型描述最真实的现实世界。

　　逻辑模型是概念模型和物理模型的适配层，实现概念模型的同时又隔离物理模型的细节。此层考虑了数据的组织方式和存储结构，在逻辑模型层还决定了数据库管理系统的特性要求，例如：数据类型、数据索引等。逻辑模型仍然不涉及到物理实现，采用同一逻辑模型的数据库管理系统在规模和性能上仍有较大差别。此层是数据库管理系统的分类标准之一，逻辑模型决定了适用业务场景是进行数据库选型的重要参考。

　　物理模型是数据系统在计算机系统中具体的实现。物理模型关心数据按何种组织方式存储到系统中。从操作系统角度，所有的数据都是存储在不同路径下的文件。文件中数据的内容和数据所在的位置都是由物理模型决定。物理模型采取的存储组织结构决定了系统的存储容量、检索性能等多个性能指标。

三层模型示意图

　　由于现在多使用成熟的开源数据库系统作为开发组件，所以在系统设计层面主要考虑数据库管理系统的逻辑模型和性能指标即可。在系统开发过程中，应深入了解所选数据库管理系统的 API 及特性，充分发挥系统的最大优势。

二、概念建模方法

　　一个系统架构描述的是各个组件的功能及组件之间的交换关系。组件功能的操作对象是一个个实体，每个实体因为操作产生的变化生成数据。数据模型要描述的就是这些实体和实体与实体的关系，最通用的建模方法也被命名为实体关系图，简称为 E-R 图。这里的实体并不是一个具体的事物，而是代表一类事物。

　　E-R 图的基础元素非常简单：实体、实体属性、实体与实体的关系。实体代表一种客观事物或者一个抽象概念。实体属性是对实体的一个细化描述，可以代表属性的一种功能、特征或者特性。实体与实体的关系天然存在，但是如何正确的匹配却需要找准对应关系。有时实体的特征属性可以作为关联的标识，有时需要增加数据系统属性才能正确的连接两个实体。在增加标识的过程中，概念模型层面只需要确认实体各自唯一标识的含义，通常是生成一个 ID 属性。到逻辑模型才需要考虑 ID 属性用什么形式进行记录。

　　下面以会员系统中的会员等级进行案例分析，本示例中包含四个实体。

会员：会员是用户在某个组织进行注册并加入特定的会员计划。成为会员需要支付一定费用或达到条件。会员通常能够享受到特定的权益和优惠。

成长值：会员行为产生的一种分数。成长值到达一定数量可以提升会员等级或者获得权益。

会员等级：会员等级标识会员到达了会员体系中的一定级别。会员等级通常对应不同的会员特权、折扣和服务。

会员权益：会员权益是会员体系中所包含的待遇、特殊优惠或服务员，会员权益用于彰显会员的特殊性和稀缺性。

四实体关系示意图

　　从会员视角，三个实体都是围绕会员产生的一些增减变化。这些变化可以衍生出两类的数据，实体变化的记录和当前状态下的实体数据情况。下面我们只分享实体的当前状态，简化实体关系的复杂度。

　　每个会员都有属于自己的成长值，既会员与成长值是一对一的对应关系。

1 对 1 示意图

　　会员等级是一个虚拟的概念，每个会员都可以达成各个等级，但在同一时间会员只可能拥有一个等级。所以会员和会员等级是 N 对 1 的关系。

N 对 1 示意图

　　会员权益通常是一种服务，满足条件的会员都可以享受。会员也可以拥有多个不同种类的权益。所以会员和会员权益之间是 N 对 N 的关系。

N 对 N 示意图

　　会员等级发生变化时，会员的权益也会随之变化，所以等级和权益之间还隐藏着一组 N 对 N 的关系。这组关系表达的是一种业务规则，是会员权益变更的依据。这种业务规则可以看作是一组传递的映射关系，但是在设计过程中要秉承单一职责的原则，不要让一组关系包含不同的功能含义。

　　在 ER 图的绘制过程中，我们还要遵循一些基本原则。其中最重要的三点如下：

命名规范：实体、属性和关系的名称应该准确、一致，避免在不同语境下产生歧义。

主键标识：每个实体有一个主键，并且主键符合主键的设计规范及范式的要求。

范式约束：实体和实体之间的关系应该满足 BCNF 范式的要求。

三、概念模型与逻辑模型的转换

　　采用关系模型的数据库很长时间占据主流市场，所以 ER 图的设计常常贯穿了概念模型和逻辑模型设计，并且可以使用一个简单的模式完成 ER 图的转换，既每个实体和关系都创建一张表。

　　当主键类数据库（KV 模型和文档模型的数据库）占有一席之地之后，ER 模型已经无法直接映射为逻辑模型，需要进行适当的转换。KV 模型的 K 既是实体的主键，同时又包含含义前缀。此时 K 起到“表”名称的作用，对数据进行区分和“隔离”。

　　1 对 1 的关系，经常会弱化一个实体成为另一个实体的属性。

　　1 对 N 的关系和 N 对 1 的关系有所不同，需要明确查询的“方向”。从 N 到 1 查询，可以与 1 对 1 的关系一样。如果是 1 对 N 的关系，必须单独存储 N 条关系记录。在不支持数据结构的 KV 模型，还需要另外存储关系的数量。

　　N 对 N 与 1 对 N 的关系同理，双向查询需要存储两倍的关系数据。

1 到 1KV 模型示意图

1 到 NKV 模型示意图

四、不太一样的大数据模型

　　大数据中的大不仅仅是数据记录条数多，还代表描述事物的数据维度多。单一的海量数据我们也很难发现事物间的新联系。所以，大数据模型会在业务模型上增加维度进行分析。为了提升性能，还会打破范式建立数据冗余的“宽表”。大数据在系统搭建时更注重数据架构的分层和加工，在数据模型上只是对业务系统的模型进行整合和改造。

　　数据模型的建立与业务建模一样都是系统设计中的重要环节。数据建模有助于系统开发过程中数据定义的统一、数据内容的完整和一致。建设好数据模型，有助于开发人员的理解也有助于数据治理工作的开展和实施。