文章目录

• 数据仓库建模理论
• • 1、关系模式范式
  • • 1.1、第一范式(1NF)
    • 1.2、第二范式(2NF)
    • 1.3、第三范式(3NF)
  • 2、数据仓库建模基本理论
  • • 2.1、ER实体模型
    • 2.2、维度模型
    • • 2.2.1、事实表
      • 2.2.2、维度
      • 2.2.3、维度建模
      • • 2.2.3.1、星型模型
        • 2.2.3.2、雪花模型
        • 2.2.3.3、星座模型
    • 2.3、DataVault模型
    • • 2.3.1 DataVault基本结构
      • • 2.3.1.1、中心表-Hub
        • 2.3.1.2、链接表-Link
        • 2.3.1.3、卫星表- Satellite
      • 2.3.2、DataVault基本结构梳理

数据仓库建模理论

1、关系模式范式

只列前三种

1.1、第一范式(1NF)

域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项

1.2、第二范式(2NF)

在1NF的基础上，实体的属性完全依赖于主关键字，不能存在仅依赖主关键字一部分的属性

1.3、第三范式(3NF)

在2NF的基础上，任何非主属性不依赖于其它非主属性

2、数据仓库建模基本理论

2.1、ER实体模型

在信息系统中，将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述；实体：Entity，关系：Relationship，这种对数据的抽象

建模通常被称为ER实体关系模型

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

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

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

1:1 ，即1对1的关系，比如实体人、身份证，一个人有且仅有一个身份证号

1:n，即1对多的关系，比如实体学生、班级，对于某1个学生，仅属于1个班级，而在1个班级中，可以有多个学生

n:m，即多对多的关系，比如实体学生、课程，每个学生可以选修多门课程，同样每个课程也可以被多门学生选修

2.2、维度模型

Ralph Kimball推崇数据集市的集合为数据仓库，同时也提出了对数据集市的维度建模，将数据仓库中的表划分为事实表、维度表两种类型。

2.2.1、事实表

在ER模型中抽象出了有实体、关系、属性三种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。

**电商场景：**一次购买事件，涉及主体包括客户、商品、商家，产生的可度量值包括商品数量、金额、件数等

2.2.2、维度

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

维度表一般为单一主键，在ER模型中，实体为客观存在的事物，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。比如商品，单一主键：商品ID，属性包括产地、颜色、材质、尺寸、单价等，但并非属性一定是文本，比如单价、尺寸，均为数值型描述性的，日常主要的维度抽象包括：时间维度表、地理区域维度表等。

案例

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

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

1、商品维度：商品ID、商品名称、商品种类、单价、产地等

2、用户维度：用户ID、姓名、性别、年龄、常住地、职业、学历等

3、时间维度：日期ID、日期、周几、上/中/下旬、是否周末、是否假期等

4、优惠券：券ID、券类别、优惠金额

5、订单中包含的度量：商品件数、总金额、总减免。描述性属性：下单时间、结算时间、订单状态等

7、订单明细包含度量：商品ID、件数、单价、减免金额。描述性熟悉：入购物车时间、状态。

2.2.3、维度建模

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

2.2.3.1、星型模型

2.2.3.2、雪花模型

2.2.3.3、星座模型

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

• 雪花、星型模型对比

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

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

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

2.3、DataVault模型

Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强

调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理；并非针对分析场景所设计。

Data Vault模型是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键，用于定位和唯一标识记录或数据。

2.3.1 DataVault基本结构

1、中心表-Hub

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

2、链接表-Link

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

3、卫星表- Satellite

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

2.3.1.1、中心表-Hub

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

商品属性以及描述信息，都属于卫星表的范畴

2.3.1.2、链接表-Link

链接表用来描述中心表间的关联关系，亦不包含业务键值以及数据装载描述以外的任何非键值数据，比如学生选课链接表，其设计：

与选课相关的课时数等描述信息，都属于卫星表的范畴。

2.3.1.3、卫星表- Satellite

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

案例：

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kwVNtz8S-1606228364480)(C:\Users\Jarvis Shaw\AppData\Roaming\Typora\typora-user-images\image-20201124222437560.png)]

2.3.2、DataVault基本结构梳理

I. 梳理所有主要实体

II. 将有入边的实体定义为中心表

III. 将没有入边切仅有一个出边的表定义为中心表

IV. 源苦衷没有入边且有两条或以上出边的表定义为连接表

V. 将外键关系定义为链接表