【数据库管理】|2 究竟哪种数仓模型设计更适合

设计模型，简单了解便是如何去设计方案表，促使表与表中间的关联构成一张有规律性的大网站。

 
在上一节《所以，什么是数据仓库》中谈及数仓模型的科学方法论，在其中点出了俩位重要人物Kimball的维度建模和Inmon的3NF模型。在逐渐基本建设数据库管理前，实体模型的挑选是最重要的一关之一，它是全部数仓中数据组织的基本上框架。在这节，大家梳理了业内常见的四种建模详尽探讨。
 

维度建模

Kimball明确提出的维度建模，是一种快速迭代和交货的实体模型基本建设方式 。在现阶段诸多建模中深受青睐，由于不管从数据信息了解、实体模型搭建或是是BI剖析等层面都相对性于别的模型方法好。又由于当代数仓绝大多数是根据Hadoop搭建，容许以室内空间换時间，维度建模就逐渐变成了优选 —— 我能在后面章节目录详解这一建模。
 

特性

维度建模是根据高宽比沉余维度表，为此提高开发人员对数据信息的逻辑思维能力、提升 数据信息一致性。又由于关系少，能够降低中下游ETL造成的I/O工作压力，但缺陷是消耗储存。
 

定义

层面：对待事情的视角，如店面、客户等
粒度分布：数据信息粒度分布，指融合多少个层面去看看数据信息，如店面产品粒度分布（粗粒度）、店面粒度分布（细粒度）
客观事实：产生的某一件不能更改的事，如购买商品、订单信息退换货等
衡量：用于给客观事实产生的水平给出一个数据，如额度，长短，容积等

假定有那么个要求：领导干部爱看全部店面在昨日一天内交易量的额度
层面：店面，日期

客观事实：交易量
衡量：额度

模型图

理想化情况下，维度建模展现的是一个规范的星形实体模型，好几个层面紧紧围绕着客观事实表为管理中心。
一般来说，维度建模的设计过程以下：

• 挑选业务流程全过程，如上图所述的产品交易、产品退换货全过程
• 申明粒度分布
• 设计方案层面
• 设计方案客观事实

当新要求来的时候，大家都必须重走之上全过程，来建立和丰富多彩实体模型，假如业务流程全过程不会有，则新创建一套层面和客观事实与之相匹配；假如层面或是客观事实早已存有，请升级或是丰富多彩表格中的字段名就可以，因此维度建模方法是一个持续迭代更新，逐步完善的建模。

具体设计方案中很有可能会从某一维度表中再拆分一个子维度表，如产品维度表，能够再分拆类目维度表，用外键约束依赖于产品维度表，这类展现方法称之为小雪花实体模型。

DataVault模型

Data Vault（下边称：DV）模型也是数据库管理模型的一种方式 ，在《Hadoop构建数据仓库实践》一书里有详解。这类模型方法相对性于维度建模而言，数据信息信息冗余少，能全自动融入将来不可预见的业务流程关联（表和表的关联）转变。假如你的企业较为重视历史记录的维护保养，或是是对于财务审计型（对材料做出直接证据收集及剖析）的业务流程，在数据信息进到实体模型的情况下又不愿太多对数据信息逻辑性开展恰当是否的分辨得话，DV实体模型适合你。假如听搞不懂上边说啥很一切正常，我们可以先掌握这类实体模型能处理什么问题！

参照： What is the data vault and why do we need it

在其中关键摘抄

1. 这类实体模型能最大限度的融入业务管理系统关联和关联间的转变。

如：订单信息-顾客 过去是 N:1 关联，可是现阶段早已拥有拼团游戏玩法，就变成了 1:N，假如业务流程转变后，大家 只必须在Link表中提升纪录或是列就可以，不需韬光养晦

2. DV不强烈推荐做脏数据处理方法，它只是体现上下游系统软件数据信息的真实有效，换句话说数据信息恰当是否都应当纪录到数仓里边并使他体现出去

特性

构造有点儿相近3NF，申明管理中心表和链接表来搭建实体线与实体线中间的关联，把实体线的叙述信息内容所有放进通讯卫星表格中储存。这类建模适用：要储存完完整整的历史记录变更纪录的状况。因此大部分每一种表种类都是有自身的代理商键。

代理商键：简言之便是根据数据整理方式 ，给表每一条纪录转化成一个唯一的ID，用于表明其每一次的转变。

假定大家有一张产品表：
 
ID          ITEM_ID          ITEM_NAME

0000001     20391        Iphone 11-新品发售！速购！

0000002     20391        Iphone 11-全网通！来买！

0000003     20391        Iphone 11-赔本卖！店家不要钱！
 
这儿的代理商键便是ID，业务流程外键约束便是ITEM_ID。

定义

假如 Hub 是人的骨架，那麼 Link 便是联接框架的肌腱，Satellite 便是框架上的肉体。

 
维度建模有层面和客观事实的定义，同样的，DV实体模型也是有自身的一套“表种类”，在其中包括三种表

• Hub：管理中心表，每一个实体线独立建一个中心表，每一个管理中心表仅有代理商键、业务流程外键约束、装车時间、数据来源四个字段。管理中心表与管理中心表中间是公平关联，不会有亲子关系。

• Link：储存不一样的Hub（2个或是之上）中间的关联，储存实体线表的代理商键、无效标识、装车時间、数据来源等。

• Satelites：通讯卫星表，储存Hub或是是Link的详细说明。

模型图

3NF模型

数据库管理鼻祖 Bill INmon 明确提出的建模：从全公司的高宽比设计方案一个 3NF 实体模型，用实体线关联（ER）实体模型叙述公司业务流程，在方式理论上合乎 3NF。
数据库管理中的 3NF 和 OLTP 系统软件中的 3NF 的差别：数据库管理的 3NF 是立在公司视角朝向主题风格的抽象性，而不是对于某一实际工作流程的实体线目标关联的抽象性。
 
数据库管理的 3NF 特性：

• 必须全方位联接公司业务流程和数据信息；
• 执行周期时间十分长；
• 节约储存，数据信息高宽比精减；
• 对模型工作人员的规定较高；
• 选用 ER 实体模型基本建设数据库管理实体模型的立足点是融合数据信息，将系统结构中的数据信息以全部公司视角按主题风格开展相似度组成和合拼，并开展一致性解决，为数据统计分析管理决策服务项目，但并不可以立即用以剖析管理决策；

 
因为三范式模型在公司中不常见，应用面不广并且没有什么难度系数，因此这儿也不深入探讨了。但是能够顺带回望一下什么叫3NF。
我们在设计方案OLTP系统软件时要遵照3NF，它是关联型数据库查询基础理论的基本和具体指导方式 。
 

第一范式-1NF

注重列的原子性，规定列不可以再分割。
事例：考虑到那样一个表【手机联系人】（名字，性別，电話）

在具体情景中，一个手机联系人有家中电話和公司座机电话，那麼这类表总体设计就沒有做到 1NF。要合乎 1NF 大家只需把列（电話）分拆，
即：【手机联系人】（名字，性別，家中电話，公司座机电话）

第二范式-2NF

在遵照1NF前提条件下，规定表务必有外键约束，且非外键约束列要彻底依靠此外键约束，不可以一部分依靠。
事例：考虑到订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）
外键约束为（OrderID，ProductID），显著看得出，标色的好多个列是只取决于外键约束之一的ProductID，因此（UnitPrice，ProductName）归属于沉余字段名，不符2NF。
解决方案：【OrderDetail】表拆分成
【OrderDetail】（OrderID，ProductID，Discount，Quantity）和
【Product】（ProductID，UnitPrice，ProductName）
 
 

第三范式-3NF

在遵照2NF前提条件下，规定非外键约束列务必立即取决于外键约束，不可以存有传送依靠。
事例：考虑到一个订单信息表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）外键约束是（OrderID），CustomerName，CustomerAddr，CustomerCity 立即依靠的是 CustomerID（非外键约束列），而不是立即取决于外键约束，它是根据传送才取决于外键约束，因此不符 3NF。公司应当把这类外戚清除掉！
 
 

Anchor模型

太人少用了，这儿不进行说。
Anchor实体模型由Lars. Rönnbäck明确提出，是DataVault实体模型的进一步范式化解决，核心内容是只加上、不改动的可拓展实体模型，Anchor实体模型搭建的表非常的窄，类似K-V结构型实体模型。它关键包含Anchors（实体线且仅有外键约束），Atributes（特性），Ties（关联），Knots（公共枚举类型特性)）。Anchor是运用中较为少的建模，仅有传统式公司和少数几家互联网公司有运用，比如：蚂蜂窝等。
 
 

汇总

数据库管理的模型方法大致而言就之上几类，在日益发展趋势的技术实力、数据信息发生爆炸和储存成本费减少的发展趋势中，维度建模是数最多企业应用的。每一个企业都必须依照具体情况挑选适合的实体模型，但是，以不变应万变，量身定制，从人工成本、数据信息应用成本费、储存成本费、生产加工复杂性等视角衡量，一定能寻找合适自身的“大网站”。