逻辑数据模型（LDM：Logical Data Model）是涵盖了业务需求中所有实体、关系和属性的最详细的数据模型。

逻辑模型设计是从0到1设计一个数据模型的过程中耗时最久的环节。

不仅要详细地设计每一个实体、关系和属性，经历范式化、历史数据管理方式设计等环节，还要保证模型的易读性、规范性、未来可扩展性等等。

在逻辑数据模型这个主题里，有很多概念和思想还是需要有一定参考和判断基准的，接下来就从以下几个方面来稍微深入地聊一下逻辑数据模型。

▌概念、逻辑和物理模型有哪些区别

从设计流程的这个点来说，逻辑数据模型是概念数据模型的延续，将概念模型作为主体框架进行“精雕细刻”的过程。

从视野高度的这个点来说，概念模型设计需要宏观视角，逻辑模型设计需要微观视角。而物理模型与逻辑模型的结构基本没有太大的差别，只是把业务视角切换成了技术视角。

概念模型、逻辑模型和物理模型是从使用目的、设计重点、设计状态和设计流程几个角度划分的概念。

从使用目的的角度来说

概念模型是用于需求分析的工具，设计的重点是表达业务需求中的数据对象和关系，从而促进不同视角和角色对需求理解的一致；

逻辑模型是对业务最详细、最完整的表达，除了分析和沟通以外，要承接从业务到技术落地的重要职责；

物理模型是技术角度的数据字典，是数据库表结构和存储方案设计的产物，用于指导技术人员管理和开发。

从设计重点的角度来说

概念模型是框架设计，描述主要的实体、关系和属性；

逻辑模型是细节设计，要全面地描述所有数据，要保证数据完整性；

物理模型是技术设计，需要一定技术能力，考虑的是数据的存储方式、性能、开发和维护的便捷性等因素。

从设计状态的角度来说

概念模型是数据模型设计整个过程中“搭完台子”的状态；

逻辑模型是在搭好的台子上把舞台所有装饰都布置好的状态；

物理模型则是在舞台上把演出的时候需要的灯光、音响和装置都调试好，达到最佳效果的状态。

从设计流程的角度来说

虽然理论上将设计过程划分为“概念、逻辑和物理”三个阶段，但是需要注意的是：往往前一个设计阶段可能需要有意识或无意识地考虑后一个阶段的要点。

而且，也不是说逻辑模型设计的过程中只允许对逻辑模型进行修改，物理模型设计的过程中只允许对物理模型进行修改。

物理模型设计的时候可能会牵扯到逻辑模型的调整，逻辑模型设计的过程中要和概念模型中的实体对齐，所以也可能会需要调整概念模型。

它们三者并不孤立，既不是前一个阶段彻底完成后才能开始下一个阶段，也不是下一个阶段过程中不允许调整前一个阶段的模型。

▌逻辑模型设计的边界还是比较清晰的

就像设计概念模型的时候，会产生“到底该设计到什么程度才好”这类问题一样。

在设计逻辑模型的时候也会有很多疑问，比如，“逻辑模型是不是要继承概念模型中的所有实体？”“逻辑模型到底要不要在设计的过程中直接进行反范式化？”

先说一下我的观点：概念模型的边界没有明确的定义，会存在一定理解上和习惯上的差异，逻辑模型设计的边界还是比较清晰的。

例如：概念模型中都是重要的实体、关系和属性这一点很明确，只不过哪些是重要的？可能会有一些理解的不同。而最终设计完成的逻辑模型一定要包含业务需求中所有实体、关系和属性。

看，是不是很清晰？只要不是所有的，逻辑模型设计都不算完！

所以，最终设计完成的逻辑模型，可以说是一个完整的数据结构。

逻辑模型设计的过程中要不要进行反范式化？有些业务需求中并没有描述，而开发和实现的过程中，必须要的实体、属性和关系要不要包含在逻辑模型里？

先说第一个问题的结论，逻辑模型设计过程中，建议不考虑反范式化设计，但是，最终模型设计完成的时候，逻辑模型中应该包含反范式设计的结果。

第二个问题的结论也一样，在逻辑模型设计过程中，建议不考虑那些因为技术因素产生的对象（例如：复制、计算来的派生属性和开发时候需要的系统属性），但是，最终设计完成的逻辑模型中，应该包含这些对象。

原因很简单，逻辑模型阶段的核心逻辑一定是详细设计所有对象，并通过范式化最大程度地降低冗余、确保数据完整性。

只是，在物理模型设计阶段考虑各种技术实现方式的时候，需要在逻辑模型中也对这些设计点有所体现，所以需要来完善逻辑数据模型。

最终形成的是数据结构一致，但是角度不同逻辑模型和物理模型。

理论虽然很固化，但实际逻辑模型设计的过程中，对于经验丰富的建模师来说，一定会考虑一些技术实现的因素，可能在逻辑模型设计的过程中就顺手设计好了。

这是人家能力优秀啊，不能说人家不按游戏规则出牌呀！

当然，从理论层面明确划分不同设计阶段的边界肯定是对的，对初学者和不熟悉的人来说还是非常具有参考意义的。

▌逻辑模型设计的关键点

为什么这个小节的标题是逻辑模型设计的“关键点”而不是“流程”？

就像之前说的概念、逻辑和物理模型设计的过程一样，虽然有先后顺序，但并不是只允许单向执行，不允许回退调整的。

本文并不会详细介绍逻辑模型设计的具体方法，只是想给你分享一些我对逻辑模型的认识，希望可以在后续的学习中对你有所帮助。

逻辑模型设计的过程中，会涉及以下几个关键性的设计工作：实体设计、关系设计、属性设计、主标识符设计、范式化设计、历史数据管理设计、逻辑模型审查。

实体设计

设计实体的时候，最重要的就是明确定义实体的性质。与概念模型相比，需要通过设计工具更加详细地描述实体的性质和构成，并且要把业务需求中涉及的所有实体都清晰地设计出来。

关系设计

关系不仅仅是实体之间关系的描述，也是业务逻辑的表达。

既表达了实体中数据之间关系基数的类型（一对一、一对多），也表达了数据生成的顺序（父实体中的数据比子实体中的数据先存在）。

属性设计

逻辑模型设计阶段的属性设计，第一要务就是要把业务需求中描述的所有信息项都设计到模型中，每个实体都要包含完整的属性。

理论上来说，派生属性和系统属性是在物理模型设计阶段考虑的，所以，逻辑模型设计阶段需要把所有的派生属性和系统属性去掉。

（虽然真实的设计过程中确定未来一定会需要的一些属性也会顺带设计出来，标注清楚这些属性的来源和计算逻辑。）

主标识符设计

主标识符（Primary Identifier）的设计与实体设计其实是一体的，基本上实体设计的时候就已经确定了实体的主标识符。

但是，主标识符这个概念非常重要的，在实体和属性设计完成后，还是需要划分一个独立的过程，来确认主标识符设计的是否合适。

范式化设计

范式化（Normalization）是关系型数据库中最重要的概念之一，逻辑模型设计阶段必须经历范式化设计的工作。

原则上逻辑模型是一个进行了彻底范式化的模型，不包含任何冗余（Redundancy），避免在数据变更的时候产生异常（Anomaly）。

经历过范式化设计的模型，实体的性质会更加明确，模型的结构也会更加稳定。只不过，大多数建模过程中，只要做到符合第三范式的要求即可。

历史数据管理设计

逻辑模型设计阶段需要深入分析和思考的另外一部分工作就是：如何管理历史数据（Historical Data）。这里说的历史数据是指实体中数据发生变化时产生的数据，它与描述业务过程的数据不同。

如何设计历史数据存储的方式，会影响到实体主标识符的设计，从而影响到与它相关实体之间关系的设计，更会直接影响未来程序处理的逻辑。

逻辑模型审查

经历了以上几个关键的设计环节之后，最后一步就是对设计完的逻辑模型进行审查（Review）。审查的目的是保证业务需求中包含的数据已经全部、正确地体现在逻辑模型当中。这个环节虽然费时且繁琐，但是为了避免对后续的过程产生负面的影响，这个环节是不可缺少的重要工作。