- 男人的内心都是很纯洁的，风骚起来恐怕受不了。
作为数仓的工作者,长时间的与数据打交道，一股作气写sql。
在Kimball和Inmon是两种主流的数据仓库方法论，分别由 Ralph Kimball 和 Bill Inmon 提出，在实际数据仓库建设中，业界往往会相互借鉴使用两种开发模式。
整理如下：
image.png
Inmon 模型
- 看过数据建模的书的小友都知道，Inmon他提出的建模方法是从全企业的高度设计一个3NF模型，但是数仓的3NF和OLTP中的3NF的区别在于，它是站在企业的角度面向主题的抽象，而不针对具体业务过程。
他推崇自上而下的建模方式，即从数据源到数据仓库再到数据集市的（先有数据仓库再有数据市场）一种瀑布流开发方法。
Inmon模型以数据源头为导向。需要探索性地去获取尽量符合预期的数据，尝试将数据按照预期划分为不同的表需求。明确数据的清洗规则后将各个任务通过ETL由Stage层转化到DW层，这里DW层通常涉及到较多的UDF开发，将数据抽象为实体-关系模型。在完成DW的数据治理之后，可以将数据输出到数据集市中做基本的数据组合。将数据集市中的数据输出到BI系统中去辅助具体业务。
在OLTP系统数据(可以笼统为业务后端用的数据)的主要用的建模方式就是三范式，从而在事务处理中解决数据的冗余和一致性问题，遵照一定的规范要求，目的在于降低数据的冗余性
关系模型之范式理论：
第一范式（1NF）：每一列原子性。
例如：<编号，姓名，商品> 那么商品里面不能包含数量和某个商品，需拆分，一个属性不可多个值。
第二范式（2NF）：满足第一范式并且非主键的数值都依赖于数据表的主键,不能存在部分依赖
例如：<学号，姓名，身份证，课程号，课程名，分数>在这个表主键是<学号，课程号>分数完全依赖（课程号，课程名）分数不完全依赖姓名，那么拆表<学号，姓名，身份证><课程号，课程名，分数>
第三范式（3N）：满足第二范式，消除数据冗余，不能存在传替函数依赖。
例如：A->B,B->C那么A不等于指向C。（学号, 姓名, 年龄, 性别，系别，系别，系办地址，系办电话）作为一张表，那么存在（学号）→ (姓名, 年龄，性别，系别，系办地址、系办电话)但是还存在下面的决定关系(学号) → (所在学院)→(学院地点, 学院电话)
拆分：
(学号, 姓名, 年龄, 性别，系别)
(系别, 系办地址、系办电话)
image.png
Kimball 模型
- Kimball老师 模型推崇自底向上的设计模式，即从数据集市到数据仓库再到数据源(先有数据集市再有数据仓库)的一种敏捷开发方法。Kimball都是以最终任务为导向。在得到数据后需要先做数据的探索，尝试将数据按照目标先拆分出不同的表需求。在明确数据依赖后将各个任务再通过ETL由Stage层转化到DM层。这里DM层数据则由若干个事实表和维度表组成。接着，在完成DM层的事实表维度表拆分后，数据集市一方面可以直接向BI环节输出数据了，另一方面可以先DW层输出数据，方便后续的多维分析。
维度建模是专门用于分析型数据库、数据仓库、数据集市建模的方法。：
- 维度建模里面，包含了基本的两个概念。
-
维度表(dimension)
表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。 -
事实表(fact table)
表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。
在维度建模的基础上又分为三种模型：
星型模型：
image.png
- a. 维表只和事实表关联，维表之间没有关联；
- b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
- c. 以事实表为核心，维表围绕核心呈星形分布；
雪花模型：
image.png
- 雪花模式是对星形模式的扩展，每个维表可继续向外连接多个子维表
星座模型：
- image.png
- 雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。
