数据仓库建模方法论

一、ER实体模型

概念

定义：在信息系统中，将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述；实体：Entity，关系：Relationship，这种对数据的抽象建模通常被称为ER实体关系模型

实体：通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车，此实体非数据库的实体表

属性：对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重量、产地等

关系：现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位，就会有“库存”的属性产生；用户购买商品，依附实体用户、商品，就会有“购买数量”、“金额”的属性产品。

实体之间建立关系时，存在对照关系：
1:1 ，即1对1的关系，比如实体人、身份证，一个人有且仅有一个身份证号
1:n，即1对多的关系，比如实体学生、班级，对于某1个学生，仅属于1个班级，而在1个班级中，可以有多个学生
n:m，即多对多的关系，比如实体学生、课程，每个学生可以选修多门课程，同样每个课程也可以被多门学生选修

案例

场景：课程管理系统
该系统主要用来管理某校教师、学生、课程，其中包括课程选修、考试、教师授课、学生班级管理功能，现需要完成数据库逻辑模型设计

• ER
  
• IDEF1X
  

应用场景

ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式
Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模
BI架构提出分层架构，数仓底层ods、dwd也多采用ER关系模型就行设计

二、维度建模

概念

维度建模将数据仓库中的表划分为事实表、维度表两种类型。维度建模最被人广泛知晓的一种方式就是星型模式。

维度 : 度量的环境，用来反映业务的一类属性。

顾名思义，看待事物的角度。比如从颜色、尺寸的角度来比较手机的外观，从cpu、内存等较比比较手机性能。

维度表一般为单一主键，在ER模型中，实体为客观存在的事物，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。

比如商品，单一主键：商品ID，属性包括产地、颜色、材质、尺寸、单价等，但并非属性一定是文本，比如单价、尺寸，均为数值型描述性的，日常主要的维度抽象包括：时间维度表、地理区域维度表等。

比如:

事实表 : 维度模型的基本表，每个数据仓库都包含一个或者多个事实数据表。

阿里巴巴电商系对于维度建模有一些非常好的扩展补充，例如维度表可以分为快照维表、缓慢变化维表等，事实表可以分为事务事实表、周期快照事实表和累计快照事实表。

在ER模型中抽象出了有实体、关系、属性三种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。如:一次购买事件，涉及主体包括客户、商品、商家，产生的可度量值=包括商品数量、金额、件数等。

设计步骤

• 选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个时间的状态，比如当前的账户余额等；还可以是一系列相关业务时间组成的业务流程，具体需要看我们分析的某些事件发生情况，还是当前状态，或是事件流转效率。
• 选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。
• 识别维度。选择好粒度之后，就需要基于此粒度设计维度，包括维度属性，用于分析时进行分组和筛选。
• 选择事实。确定分析需要衡量的指标

案例

某电商平台，经常需要对订单进行分析，以某宝的购物订单为例，以维度建模的方式设计该模型

涉及到事实表为订单表、订单明细表，维度包括商品维度、用户维度、商家维度、区域维度、时间维度

商品维度：商品ID、商品名称、商品种类、单价、产地等
用户维度：用户ID、姓名、性别、年龄、常住地、职业、学历等
时间维度：日期ID、日期、周几、上/中/下旬、是否周末、是否假期等
优惠券：券ID、券类别、优惠金额

订单中包含的度量：商品件数、总金额、总减免
描述性属性：下单时间、结算时间、订单状态等
订单明细包含度量：商品ID、件数、单价、减免金额
描述性熟悉：入购物车时间、状态

建模

星型模型和雪花模型

维度建模通常又分为星型模型、雪花模型

所以由上可以看出，星型模型和雪花模型主要区别就是对维度表的拆分，对于雪花模型，维度表的涉及更加规范，一般符合3NF；而星型模型，一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率

上面的案例，对于商品再拆分出厂家、品类；用户的常住地再拆分出区域维度，改造为雪花模型

雪花和星型对比

冗余：雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；星型模型的维度表设计不符合3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间

性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高

ETL：雪花模型符合业务ER模型设计原则，在ETL过程中相对简单，但是由于附属模型的限制，ETL任务并行化较低；星型模型在设计维度表时反范式设计，所以在ETL过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理

三、dataValue模型

概念

Data Vault是在ER模型的基础上衍生而来，Data Vault模型是一种中心辐射式模型，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理；并非针对分析场景所设计。

Data Vault模型更容易设计，ETL过程中更易配置化实现。Hub想像成人体的骨架，那么Link就是连接骨架的韧带组织，
而satelite就是骨架上的血肉。Data Vault是对ER模型更近一步的规范化，由于对数据的拆解和更偏向于基础数据组织，在处理分析类场景时相对复杂，适合数仓低层构建，目前实际应用场景较少

基本结构

中心表-HUB

唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合

只包含业务主键信息以及数据装载的描述，不包含非键值以外的业务数据属性本身；比如中心表商品，在DataVault如下，商品属性以及描述信息，都属于卫星表的范畴

链接表-Link

表示中心表之间的关系，通过链接表串联整个企业的业务关联关系

链接表用来描述中心表间的关联关系，亦不包含业务键值以及数据装载描述以外的任何非键值数据，比如学生选课链接表，其设计如下，与选课相关的课时数等描述信息，都属于卫星表的范畴。

卫星表- Satellite

历史的描述性数据，数据仓库中数据的真正载体

数仓中数据的主要载体，包括对链接表、中心表的数据描述、数值度量等信息，中心表商品、订单明细的卫星表
分别如下：

案例

对上面已经讨论到的学生选课ER模型，进行DataVault模型重构，ER原模型如下：

重构原则:
I. 梳理所有主要实体
II. 将有入边的实体定义为中心表
III. 将没有入边切仅有一个出边的表定义为中心表
IV. 源库中没有入边且有两条或以上出边的表定义为连接表
V. 将外键关系定义为链接表

改造完后的大概模型

四、Anchor

概念

Anchor是对Data Vault模型做了更近一步的规范会处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了k-v结构的模型，模型范式达到了6NF由于过度规范化，使用中牵涉到太多的join操作，目前木有实际案例，仅作了解

基本结构

Anchors

类似Data Valut的Hub，代表业务实体且只有主键

Attributes

类似Data Valut的Satellite，但更加规范化，将其全部K-V结构化，一个表只有一个属性描述

Ties

类似Data Valut的Link，就是Anchors之间的关系

Knots

代表那些可能会在多个Anchors中公用的属性的提炼，比如说性别，状态等这种枚举类型且被公用的属性

在以上四个基本对象的基础上，又可以细分为历史和非历史的，其中非历史的会以事件戳加多条记录的方式来记录数据的变迁历史。

五、总结

以上为四种基本的建模方法，当前主流建模方法为：ER模型、维度模型

ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。
问题：

• 需要全面梳理企业所有的业务和数据流
• 实施周期长
• 对建模人员要求高

维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。
问题：

• 不需要完整的梳理企业业务流程和数据
• 实施周期根据主题边界而定，容易快速实现demo