五、数据仓库详细介绍（建模）理论篇

1 前言

大家好，本篇文章是数仓详细介绍系列的第四篇。

第一篇是简单介绍，后三篇属于数仓设计部分：

数仓概述，这一篇我给大家简单介绍了数据仓库的基本概念和大致构建过程，没有过多深入主要是给大家有个基本的了解。
数仓架构，这部分确定了数据仓库的结构和边界，我们从四个不同视角给大家带来了相对全面的宏观认识，当然还差一个部署架构。
数仓规范，则是对数据管理的全流程进行约束，以保证数据管理工作的有序、高效、高质量的开展。上篇是心法，我们简单阐述了规范的重大意义以及设计和落地方法论。下篇是招式，我们从四个不同方向给大家呈现了一幅完整规范范本，给大家参考。
数据模型，可以说是数据仓库的基石，承载着数据存储的重要职能。上篇我们主要介绍数据建模理论，我们先不对数仓建模做太多介绍，而是从更大的视角去阐述。下篇我们主要介绍真实数仓建设场景下的数据建模实践。

由于数仓建模的重要性，数据仓库的文章都会用绝大多数篇幅来讲解，当然主要还是维度建模，我一开始也认为自己会在这一章讲讲三范式，讲讲维度建模然后就完了，由于大家都已经讲的很好了，甚至我都打算直接转载了。

后来由于一些其它原因，我在七月份做了一次公开课《数据仓库的前世今生》，八月份又翻阅了一些 DAMA2.0 的内容。突然意识到数据建模并不等于数仓建模，事实上数仓建模仅仅是数据建模的其中一个分支，在范式建模和维度建模之外也还有几个别的建模方法，只是数仓建模很少用到罢了。

既然这篇是数据建模的理论篇，那么我们何不跳出数仓建模，从更大的视角展开来阐述呢？

2 什么是模型？

说到模型，还有另外一个比较容易搞混的概念：什么是模式?

从字面的意思理解，“模”一种标准，或者一种套路，“式”方式，方法，形式。两个字连接在一起就可以解释为，一种可以重复使用，具有参考性的方法、知识体系。

在互动百科中定义为：

模式是指从生产经验和生活经验中经过抽象和升华提炼出来的核心知识体系。模式（Pattern）其实就是解决某一类问题的方法论。把解决某类问题的方法总结归纳到理论高度，那就是模式。模式是一种指导，在一个良好的指导下，有助于你完成任务，有助于你作出一个优良的设计方案，达到事半功倍的效果。而且会得到解决问题的最佳办法。

实际中有些人会把模式误认为模型，大家可以参考以上定义去做识别。

好了，我们接下来回归正题，既然我们聊建模，那么什么是模型？

现实中我们经常听到各种各样的模型，比如数学模型、算法模型、数据模型、概念模型、内存模型、领域模型、编程模型、行业研究模型。。。哈哈，是不是很乱！反正我是有点晕了，不过能跟模型联系上的总能给人一种高大上的感觉。

模型（model）是对现实客观事物的一种表示和抽象，它可以是文字、图表、公式，也可以是计算机程序或其他实体模型。可以说，模型是把对象实体通过适当的过滤，用适当的表现规则描绘出的简洁的模仿品，通过这个模仿品，人们可以了解到所研究实体的本质，而且在形式上便于人们对实体进行分析和处理。

模型不只可以描述实物，还可以描述虚拟物件。描述实物就很好理解了，比如建筑模型、汽车模型、飞机模型。

上边的解释，是不是不太好理解，好吧，看我下边的解释：

按照wiki的定义，模型是指对于某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式

这里要划的重点是：抽象！模型是可以简化人们的认知成本，有助于人们拨开庞杂细节和迷雾，理解客观事物的。比如古代打仗商讨战术使用的军事沙盘，所有形势地理浓缩呈现到台面上，给大家一种直观全面的认识。

3 什么是数据模型?

百度百科的定义：

wiki MBA智库的定义：

通俗版的解释：

数据模型是现实世界或业务逻辑在数据层面的投影，是将数据元素以标准化的模式组织起来，用来模拟现实世界的信息框架和蓝图。

目的和作用：

方便人与人之间信息的传递和沟通。
方便人们通过数据模型去理解现实世界。
计算机通过算法模型、规则模型，可以预测客观虚拟事物的发展或轨迹。
现实世界的虚拟事物，抽象到信息世界逻辑模型，再转换成计算机世界的数据模型，而计算机能够存储和识别的是物理模型。

综上所述，数据模型有如下几个用途：

以一种结构化、方便理解特定事实的组织方式呈现给人，比如BI模型、分析模型。
帮助更好的理解业务，比如业务模型、概念模型、领域模型、逻辑模型。
根据对样本数据或人的经验猜想，构建模型，去预测其它同类事物或场景，比如算法模型。
将现实世界的信息转化成数据模型，呈现给计算机，可以用于存储或计算，比如物理数据存储模型

根据数据模型用途的不同，建模方法也大相径庭。所以我们在做数据建模前，一定要先想清楚所建模型的具体用途和场景。

我们所说的数仓建模，实际上就是构建一种数据存储模型，用于结构化存储我们日常业务行为或信息化系统存储下来有价值的数据。

数仓建模的目的，是使用数据建模方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

性能，良好的数据模型能帮助我们快速查询所需要的数据，减少数据的 110 吞吐。
成本，良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。

效率，良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
质量，良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

高质量数据建模的重大意义：

更低的存储成本
更高的查询效率

清晰明了的数据结构方便理解和使用
简化的ETL处理逻辑

更好的数据质量保障（一致性、准确性、完整性、时效性）
更灵活的应对变化

更好的满足客户需求

4 通用的数据建模流程

调研阶段 --》》概念模型 --》》逻辑模型 --》》物理模型 --》》生产应用迭代

调研阶段，我们需要做好业务调研、需求调研、数据探查。

业务调研帮助我们了解业务，结合业务去理解需求我们一开始就应该带着需求去做模型设计。
最后我们还要结合业务和需求去做数据探查以确保原始数据的现状能够满足现有的和未来的业务需求。

应用场景主要分为数仓建模、BI建模、算法建模等等，应用场景不同建模的方法也会差异很大。
只有对业务、需求、数据、应用场景有足够的了解，才有可能设计出高质量的数据模型。

概念模型阶段，我们必须做好以下几方面工作：

注重全局理解和对整体架构的思考，确定系统的核心以及划清系统范围和边界。类似于领域模型，这一阶段我们对于建模的范围、工作量、重点等会有一个整体直观的认识，同时确保跟客户达成共识。
需要确定好领域内的基础和关键的业务实体，同时也要给出实体间关系的描述。
我们要统一各种业务术语和命名规范。
我们应该明确后续使用的数据存储类型（通常会是某类数据库，这个我们下文会介绍），因为不同的数据存储对应的逻辑模型设计可能会有很大差异。

上图来源自 DAMA2.0 。左边的是关系型概念数据模型，右边的是维度型概念数据模型。

逻辑模型阶段，需要根据概念模型确定好的边界做进一步的细化。

逻辑模型文档比较详细，所有实体属性均需添加，实体间关系要清晰描述，需要使用术语，遵循命名规范，采用 Case 工具创建项目文件，对各个实体以及关键属性必须要有清晰的描述。
逻辑模型不受底层实际存储数据库的约束，但我们需要定义好实体属性以及实体间的关系（这里主要是主外键关系、一对一或一对多或者多对多关系）、实体和属性的备注说明、属性的数据类型以及约束（空值、非空、主外键键约束）。
我们应该遵循先规范化再逆规范化的设计顺序，规范化的设计能够消除冗余方便理解，逆规范化的设计主要是为了方便使用，但我们切不可把偷懒和不专业当成逆规范化。

上图来源自 DAMA2.0 仅供大家参考理解。在逻辑模型设计上关系模型设计思路和维度模型差异还是很明显的。关系模型设计重在捕获业务流程的规则。维度模型设计重在捕获业务问题以确定业务流程的运行状况和性能，是维度型概念数据模型的完全属性透视图。

物理模型阶段，我们主要是针对不同的数据存储类型，根据逻辑模型，使用模型设计工具自动生成的。

常用模型设计工具是：PowerDesigner 。
对于主外键约束，在 OLTP 系统我们有可能会生成，但在 OLAP 环境下通常不会用。
建模工具可以根据物理模型直接生成模型设计交付文档、数据库建表语句等。
需要考虑查询性能要求和未来一段时间内的存储空间占用情况。
需要确定使用哪些约束、索引、以及表字段备注的准确完整性等，当然我们之前很多时候基于商业竞争考虑这里是不写备注的。

生产应用及迭代，物理模型部署以后，会逐步投入生产使用。随着业务的深入或者变动，模型也需要跟着优化完善。优质的模型可以更好的适应未来需求的变化，但是一劳永逸的模型几乎是不存在的。

5 数据存储技术发展的三个阶段

在上文我们提到，在概念模型设计阶段我们就应该确定好使用何种存储类型的数据库。

经过五十多年的发展，数据存储主要经历三个大的阶段。

第一阶段：数据库技术诞生以及三大模型之争

时间迈入了 1960 年代，野心勃勃的美国人提出了登月计划，这在当时可以件大事情。可是要飞到月球去，得有个交通工具，美国人起了个希腊神话中太阳神来命名了这个飞船。要制作这个飞船，可以动用了美国庞大的社会资源，可是这个超复杂的东东有着数不清的零件，如何管理它们成了大难题？于是计算机业内的百年老店— IBM 出场了，研发了一款叫做 ICS 的软件，专门用来管理这些零件信息。后来以此为基础诞生了大名鼎鼎的 IMS（Information Management System）数据库。这可是现代数据库的祖先。直到今天，这一老当益壮的数据库还在某些银行重要的核心岗位发挥着余热。

IMS 数据库是基于层次结构构建的，很容易实现从上往下找，但对于左右横向查询就不太好用。另一个老牌公司 GE 看到了，开发出了新的基于网状的数据库 IDS。这个貌似蜘蛛网结构的数据库很快取得的不错的市场成绩。作为行业的老大，IBM 自然不会坐以待毙，在一个超级英雄 EF.Codd（下图中，曾获得图灵奖）的带领下，提出了关系模型。一时间，层次、网状、关系三大关系模型杀的浑天黑地。直到一个重要的语言-SQL的出现，改变了整个战局。这是一个如此简单易懂的语言，可以很容易描述数据访问需求，战局的天平倾斜关系模型。后来，聪明人扎堆的加州大学伯克利分校开发了 INGRES（就是现在的 PostgreSQL ）数据库，证明关系模型是靠谱的，才为这场战争画上了句号。

注：以上两段文字摘抄自 CSDN 文章：

https://blog.csdn.net/hzbooks/article/details/108480871

第二阶段：SQL 语言促使关系型数据库一家独大。

由于 SQL 超低学习成本，以及关系型数据库对 SQL 的天然支持，使得关系型数据库迅速普及并几乎完全占领市场，像我们耳熟能详的数据库，基本上都是关系型数据库。

第三阶段：新型数据库的百花齐放。

后来随着互联网用户规模、数据量越来越大，并且要求 7X24 小时在线，传统的关系型数据库由于性能随着数据量的变大而极速下降、升级扩展困难、扩容成本与数据规模呈指数级增长，这都促使开发者们不得不去探索新的数据存储。

NoSQL (Not Only SQL)，泛指非关系型的数据库，我们通常会根据不同的使用场景去选择不同的 NoSQL 数据库，但由于不支持 SQL 就极大的增加了数据从业者的使用难度，好在后来有人想到在此之上封装一层 SQL 解析程序，这才加速了 NoSQL 数据存储的快速普及，比如 Hive、SparkSQL 等等。而其它没有提供 SQL 查询或者 SQL 支持不到位的几乎很难扩大影响力和普及率，有些甚至也已经慢慢被淘汰了。

虽然开放对 SQL 的支持使得 NoSQL 数据存储得到普及，但其依然存在一些问题使其无法取代传统关系型数据库，近些年伴随着分布式协议的成熟，人们找到了一种新的方式来解决这些痛点。

NoSQL (Not Only SQL)，泛指非关系型的数据库，我们通常会根据不同的使用场景去选择不同的 NoSQL 数据库，但由于对 SQL 的支持能力弱，使用群体往往被限制在技术圈层内，通常能够提供相对完备 SQL 支持能力，或者再次之上再包一层SQL转化解析的才更容易被普及到更广大的数据从业者中去，比如Hive、SparkSQL等等。

NewSQL ，是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。

NewSQL 系统的提出，正是为了满足整合 NoSQL 和 RDBMS 特性的需求。其中，NoSQL 提供了可扩展性和高可用性，传统 RDBMS 提供了关系模型、ACID 事务支持和 SQL。用户已不再考虑一招能解决所有问题（one-size-fits-all）的方案，逐渐转向针对 OLTP 等不同工作负载给出特定数据库。大多数 NewSQL 数据库做了全新的设计，或是主要聚焦于 OLTP，或是采用了 OLTP/OLAP 的混合架构的全新设计。

什么样的数据库才能称之为 NewSQL，应该有以下几点必备的特性：

SQL
ACID Transaction, 支持跨行事务
Auto-scale 可扩展性
Auto-failover

最后来一张图，有点搞笑，不过说真的，对于一个数据管理系统而言，得 SQL 者得天下，因为不支持 SQL 的话很难去普及推广。SQL 是最伟大的语言，数据从业者的最爱，不接受反驳，哈哈。。。

6 数据建模方法有哪些？

上边表格，是 DAMA 2.0 给出的建模方法和数据库交叉应用模式。

数据建模阶段，我们需要根据不同应用场景选择合适的建模方法和数据存储。同时也需要根据数据存储类型的不同去调整建模方法，比如关系数据库里实现的范式模型就是星型模式，在多维数据库环境中实现的维度模型通常称为联机分析处理数据库。

关系建模

关系模型是 1970 年 IBM 研究院， EF.Codd 提出来的，随后在 1971 年又提出了范式理论。

关系模型也被称作范式建模，因为其原理的核心是“规范化”理念，规范化是在保证数据存储完整性的同时，最小化冗余数据的结构化过程。

范式是符合某一种级别的关系模式的集合，目前关系型数据库有六种范式：第一范式（1NF），第二范式(2NF)，第三范式（3NF），Boyce-Codd范式（BCNF），第四范式（4NF），第五范式（5NF）。

规范化本质上是对数据存储结构进行拆分，范式等级越高拆的越细，同时规范化程度越高冗余度越低，但会给具体的查询带来负担，所以实际中我们通常到第三范式即可。

除了规范化，我们在进行关系建模时也会用到 ER 模型，即实体关系模型（Entity-relationship model），美籍华裔计算机科学家陈品山提出，是概念数据模型的高层描述所使用的数据模型或模式图。

ER 模型将现实世界抽象成不同的实体，每个实体附带不同的属性，实体与实体间的联系称为关系，关系又分为（1:1、1:n、m:3）三种。

ER 模型和规范化理论共同构成了关系建模理论，OLTP 系统基本上都是使用的关系建模。

样例一：ER 模型

下边是网上摘抄的学生-课程-教师实体关系图，给大家参考一下。

假设每个学生选修若干门课程，且每个学生每选一门课只有一个成绩，每个教师只担任一门课的教学,一门课由若干教师任教。“学生”有属性：学号、姓名、地址、年龄、性别。“教师”有属性：职工号、教师姓名、职称，“课程”有属性：课程号、课程名。

样例二：规范化

上文所说的规范化主要实现方案就是拆分，下边是临时写的一个集团公司合作伙伴的实体-关系-属性样例，写的很简单大家看懂问题就行。

由于供应商和客户既有共同的属性又有特有属性，集团客户又分为内部客户和外部客户。为了降低冗余所以我们需要设计出父子两类实体，将共有属性抽象出来做为父实体。

另外，公司与供应商间还会有采购合同，采购合同就应该从供应商实体中分离出来。

维度建模

联机分析处理的概念最早由关系数据库之父 E．F．Codd 于 1993 年提出。Codd 提出了多维数据库和多维分析的概念，把业务系统面向业务逻辑、面向事务增删改查而设计的存储结构，转换成面向分析、侧重查询的多维分析型存储结构。将所有对象都抽象为维度、度量、属性三类：

维度，可以理解为不同分析视角。
属性，用来定义和描述维度。

度量，是在一个或多个维度限定下的取值。

存储格式分为两种：

关系 OLAP（ROLAP）：基于关系数据库的 OLAP 实现，细节数据以及为聚合后的的粗粒度数据，通常会存储到关系型数据库中。
多维 OLAP（MOLAP）：有时候会构件 Cube，优点是使用方便，缺点是需要占用大量的存储空间。

上边两段是我在数据仓库系列开篇里边摘录两段内容。

我发现一个有意思的事情，关系建模和维度建模理论应该是同一个人（关系数据库之父 E．F．Codd）提出的，维度建模方法比关系建模方法晚出来了 20 年，这 20 年刚好是信息化从开端到普及的阶段，OLTP 系统存储下来的数据开始有了分析应用的需求和场景，而 OLTP 数据库在进行海量数据的分析处理上又有很多不足，比如大量的资源消耗和性能问题。

而维度模型和多维分析数据库就是在这样的背景下，由关系模型的奠基人提出来的，它将客观世界抽象成维度-属性-度量这三个概念，从而构成了维度模型。