数据仓库实践杂谈（十三）——逻辑数据模型（数仓模型）

[目录]

• 第一章：概述
• 第二章：整体数据分层
• 第三章：整体实现框架
• 第四章：元数据
• 第五章：ETL
• 第六章：数据校验
• 第七章：数据标准化
• 第八章：去重
• 第九章：增量/全量
• 第十章：拉链处理
• 第十一章：分布式处理增量
• 第十二章：列式存储
• 第十三章：逻辑数据模型（数仓模型）
• 第十四章：数据模型参考
• 第十五章：维模型
• 第十六章：渐变维
• 第十七章：数据回滚
• 第十八章：关于报表
• 第十九章：数据挖掘

数据仓库实践杂谈（十三）——逻辑数据模型（数仓模型）

曾经有几年逻辑数据模型很火热，大家都研究这个。道理上来说，逻辑数据模型并不仅仅是用在数据仓库。在OLTP系统中建立良好的数据模型更加重要。但只不过这东西从实践上被推广开来，很大程度是原NCR/Teradata适用于金融行业的数据模型在某大型国有银行项目实施后传播开来。确实是好东西，感觉一下子给我打开了天眼，原来系统设计还能这样做。

回到最基础的地方，先回顾一下什么叫数据模型。根据大学课本的定义，数据模型分三个层次：

• 概念模型（Conceptual Data Model），是一种面向用户、面向客观世界的模型，主要用来描述世界的概念化结构，基本上跟计算机、数据库无关。
• 逻辑模型（Logical Data Model），是一种面向数据库系统的模型，是具体的DBMS所支持的数据模型。此模型既要面向用户，又要面向系统。
• 物理模型（Physical Data Model），是一种面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。

这里重点研究的是逻辑模型。可以看出，逻辑模型很关键，但也很难。又要业务看得懂，又要系统能理解。这里我们不讨论层次模型和网状模型，只针对关系模型讨论。毕竟，尤其在逻辑模型中，我们最关注的是识别业务实体和建立实体之间的关系（概念模型中主要识别实体）。就是所谓的E-R建模。可以说软件工程发展这么多年，到如今，UML庞大而复杂（难写、难看懂），貌似基本销声匿迹了。但E-R建模，确实历久弥新，简单、有效。最大好优势就是，基本上，谁都看得懂。而且如果非要给一个数据模型定义一个“好”的标准，其实就一个，满足三范式。

听起来并不难，但为啥很难从零开始做好，而要利用现成的模型去修改呢？主要就是业务的复杂性导致了。任何一个行业，要把所有的业务实体以及实体之间的关系都分析清楚，是一个庞大的工作，而且需要对业务和技术都很精通的专家。早年（2004年）的Teradata FS-LDM 7.0版本，有将近1200个实体、5000个属性，200多个逻辑视图来阐述金融的数据模型。而之后一直在持续升级，不断地增加实体和关系。

为了更好的阐述数据模型，Teradata的数据模型分成三层：

• 第一级：主题域，一般在10个左右；
• 第二级：概念层，50多个关键实体；
• 第三级：细节和逻辑视图，将近1200个实体、5000个属性和超过200个逻辑视图。

下图就是一个典型的主题域模型。一般耳熟能详的Party域（参与方，而非客户），以及协议、资产、产品、财务、营销、渠道、地理位置、事件和内部组织架构等。基本上，要设计一个业务系统所涉及的数据（表），都可以套到这些主题里面去。

学习现成的逻辑数据模型对我们绝大多数人而言，不但是学习模型的设计思路、方法和技巧，而且还是在学习业务的整体规划。尤其是要设计新的业务领域的时候，参考现成的数据模型，基本可以知道应该有哪些实体（业务要素）和关联关系，快速的设计出自己需要的数据结构。

可以说，对于所有的业务系统而言，数据模型是最重要的。数据记录对了，业务才算正常完成。在这基础上，才是易用性、便捷性和效率、并发性能等要素。

回到数据仓库本身，业务系统的数据模型和数据仓库的数据模型什么关系呢？首先我们认为这两个模型所反映的业务内涵是一致的。做一个极端的假设，一个公司只有一个系统，这个系统的数据模型设计的很合理、非常棒（前提是满足三范式）。那么我们可以直接把这个模型作为数仓模型的基础，当然，记得增加时间戳以保留历史痕迹。然而现实世界一般都没这么简单了，往往复杂的业务体系会由很多个IT系统共同支撑，比如一般银行，基本都有上百个系统。同时系统之间的数据往往存在交叉，比如，客户信息会在多个系统都有。单纯的把业务系统的数据堆放在一起，会引起数据冲突，统计口径不一致，严重的导致业务管理混乱等诸多问题。

当然，也有人认为用维度建模方式直接建立多维模型作为数据仓库的模型。但我个人是支持Inmon 的范式建模法，虽然难，但毕竟能很好的描述业务的所有历史。这个观点应该也得到越来越多人的认可。

那么问题回到如何建立一个合适的数据仓库模型呢？很多教材采用传统的瀑布模型思路：

这个方法很正确，但基本上没啥用。牛顿都说了，要站在巨人的肩膀上。庞杂的业务使得试图自己从头建立一个完善的数据模型所需要的投入几乎是不可想象的。如果没有自己的模型积累，就从Teradata或者IBM或者能找到的一个成熟的模型作为参考。一头考虑原始数据的情况，另一头考虑业务需求，根据两端的情况对参考模型做适当的裁剪、增补。

最关键的一点是，不要指望模型一蹴而就。要拥抱变化，支持变化。所以范式化很重要。

随着数据仓库建立和运营，源系统的数据质量会越来越好，业务需求也会越来越多，数仓模型自然就需要演化，或者说进化。

最后，提一下所谓的三范式：

• 每个属性值唯一，不具有多义性 ;
• 每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
• 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

简单的理解则是一个表所有的字段都直接跟主键关联，两个表的关联通过外键，不能把属于其他实体的内容放进去。比如客户表和订单表，每个表都应该只保存自己的内容，订单表中用客户号做外键和客户表关联。至于什么字段属于一个实体，这就看实体识别的本事了。

未完待续。

上一篇：数据仓库实践杂谈（十二）——列式存储

上一篇：数据仓库实践杂谈（十四）——数据模型参考