往期推荐
目录
2.1 范式建模法（Third Normal Form，3NF）
2.2 维度建模法（Dimensional Modeling）
数仓建模即数据仓库建模，对数据仓库中的数据进行适当的联合，类似数据库分库建表，明晰数据关系，以便进行数据处理操作。（可以适当冗余，不遵循范式）
1. 数仓建模在哪层建
以维度建模为例，建模是在数据源层的下一层进行建设，在上节的分层架构中，就是在DW层进行数仓建模，所以DW层是数仓建设的核心层！
2. 数仓建模要怎么建（三种建模法）
常见的有范式建模法、维度建模法、实体建模法等，每种方法从本质上将是从不同的角度看待业务中的问题。
2.1 范式建模法（Third Normal Form，3NF）
- 范式建模法其实是我们在构建数据模型常用的一个方法，该方法主要由 Inmon 所提倡，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模 方法，大部分采用的是三范式建模法。
- 范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库 中这种规则就是范式，这一过程也被称为规范化。目前关系数据库有六种范式：第一范式 （1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式 （4NF）和第五范式（5NF）
- 在数据仓库的模型设计中，一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :
- 每个属性值唯一，不具有多义性 ;
- 每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
- 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去；
据 Inmon 的观点，数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化。
2.2 维度建模法（Dimensional Modeling）
- 维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。
- 维度建模专门应用于分析型数据库、数据仓库、数据集市建模，以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
典型的代表是我们比较熟知的星形模型（Star-schema），以及在一些特殊场景下适用的雪花模型（Snow-schema）。
维度建模中比较重要的概念就是 事实表（Fact table）和维度表（Dimension table）。
- 事实表：
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看， 事实表行对应一个度量事件，反之亦然。
事实表特征：事实表=维度+度量- 维度表：维度就是所分析的数据的一个量，维度表就是以合适的角度来创建的表，维度表的主键可以作为与之关联的任何事实表的外键
总的说来，在数据仓库中不需要严格遵守规范化设计原则，有时还会故意设计数据冗余。因为数据仓库的主导功能就是面向分析，以查询为主，不涉及数据更新操作。事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。
2.2.1 维度建模模式（数据分析模型）
2.2.1.1 星型模式
星型模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表组成，且具有以下特点：
- 维表只和事实表关联，维表之间没有关联；
- 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
- 以事实表为核心，维表围绕核心呈星形分布；
2.2.1.2 星座模式
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维表。很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
2.2.1.3 雪花模式
雪花模式(Snowflake Schema)是对星型模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用。
2.2.2 维度建模过程
数仓工具箱中的维度建模四步走：
2.2.2.1 选择业务过程
- 维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。
- 比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户购买情况等，我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。
2.2.2.2 声明粒度
相关名词不清楚的可以查看该博客
- 先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。
- 为什么要提相同粒度呢？在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。
2.2.2.1 确认维度
维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者， 此时该属性往往是维度属性，数仓工具箱中告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一。
2.2.2.1 确认事实
- 事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。
- 维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属 性。
- 记住最实用的事实就是数值类型和可加类型事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。
2.3 实体建模法（Entity Modeling）
- 实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。
- 那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。
将任何一个业务过程划分成 3 个部分，实体，事件，说明，如下图所示：
上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事 实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。
2594
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
