前面《报表自动化: 打开数据仓库的大门》提到了数仓分为了多个层次，其中 DW 层有多种建模方式，本文主要讲 维度建模 的方法，当然相关理论文章很多很多了，这篇文章主要是为了串一下流程，并不会详细的展开每一步的细节。
度量值
再开始聊维度之前，先让我们理解一下“度量”这个关键词，到底什么是度量？具体定义可以自行百度，咱们直接上例子。前两篇文章是以超市作为例子，现在继续围绕着超市来：
小明买了 10 个苹果，共计 3 斤，5.7 元 / 斤；3 斤橘子，4.00 元 / 斤；2 桶 1.5 L 的 XX 牌矿泉水，3.00 元 / 桶；一袋米 30 元
上面这么一个客户买了很多东西，一句话里一共涉及到五类信息：用户、数量、单价、单位、品牌。当然还隐含了多种信息：总价、商品类目……
多种类型的数据中，数量、单价、总价都可以当做度量值。
度量就是数字么？大部分度量都是数值
为什么要了解度量值这个概念？度量值它具有直接价值，度量值之间的关系可以构成间接价值，同时它们还有很大的继续加工挖掘分析的潜力（潜在价值），我们可以通过总价进行再次加总得到当日销售总额，也可以通过某个物品的单价月度曲线与销售量月度曲线进行分析得到人们可以接受的价位。
维度表
创建了维度并不能进行降维打击
小明买东西的例子，涉及到了很多类型的数据，其中单位、商品类目就可以作为维度。
用单位来举例：我们的表创建三个字段，第一个是数字类型的 Primary Key，第二个是单位的汉字，第三个是英文。
这样我们无论在哪里需要用单位，都可以只存这个数字就可以了，这样无论是存储空间还是搜索速度都比较友好，最主要的是我们可以很好地进行分类。
比如通过单位，我们可以将升类型的单位筛选出来，得到总的液体类物品销售量
比如通过商品类目进行分类，可以快速的得到所有的蔬菜销售情况
事实表
对于一个超市来说：销售事实、商品明细事实、用户信息事实、进货情况也是事实、库存情况也是事实……
事实表中的度量值：作为度量业务过程的事实（事实表属性），一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型。
事实表有三种类型 :事务事实表、周期快照事实表、累积快照事实表
事实表中一条记录所表达的业务细节程度被称为粒度
事实表的设计过程：选择业务过程、声明粒度、确定维度、确定事实
事实是维度建模的核心，DW 层会有一个或者多个事实表，上面有各种定义，本文还是以实用性为主，那么说说实在的：
事实表作为数据库的一个表，到底要存什么字段：
- Primary Key：最好是这个事实对应的业务 id，比如销售事实可以用销售账单的 id。实在没有？总要有个主键吧，可以是自增的 id
- 度量值（或者上面定义的 属性 这个词）：一个事实肯定有很多度量，销售就有销售的数量、金额等等
- 维度表 Primary Key：还用上面的例子，各种单位我们可能在数据库里写一堆“个”、“升”一类的无论占用空间，还是做分析都很不方便，那么这些单位肯定做会成为一个单位维度表，这时候事实表里只需要存对应的主键就可以了
- 其他事实表 Primary Key：继续看例子，小明这个客户，我们都知道他叫小明了估计也是办了会员卡的，会员卡肯定有 id 吧，不要犹豫存上他，总不能存“小明”这个 name 然后找到一堆重名的人吧；除此以外各种销售物品也许也有创建出事实，那么存个 id 并不会占用太多空间，当我们需要找到更详细的信息“出产地、出产公司”等等时可以快速的找到；再比如收银员这个企业员工表的 id 来方便找到对应的结账人员。
- 明细信息：如果这是一次超市的外卖，那么可能用户会有备注，虽然不是数字不属于度量，但如果有分析的需要可以加上
注意：我们存的只是 id，并不需要外键等手段让他们强链接
上面提到了把其他事实表的 Primary Key 存进来。这个并不是一定的！！
因为这样做会导致两个维度模型有了关联，如果没有这么明确的诉求，我们可以将其他事实表中需要的信息提取成一个专供当前事实的维度表。
比如公司员工信息表超级复杂，而且涉及到人员也很多很多并不都是收银人员，这些其他的人员是不会直接接触到来超市买东西的客户的，这个时候就可以单独的将收银人员提取出来作为我们这个销售事实的收银员维度。
其他模型的事实也许只是当前模型的维度
维度模型
经过上面的操作，事实表已经连上了维度表，这就已经完成了维度建模。那么连接以后会有什么样子呢？星型模型、雪花模型、星座模型
- 星型模型：事实表连接了多个维度表，没有连接其他的事实表
- 雪花模型：维度表也分了层次，也就是维度表里存了其他维度表的 id。比如销售事实与商品类目构成了这样的关系：物品-叶菜-蔬菜。这样我们销售表只存更小粒度的维度，然后维度中存更大粒度的维度或者其他的维度，这样构成了类似于雪花的样子
- 星座模型：维度表在做个模型中共用，或者事实表存了其他模型事实的 id，这样就将多个模型连到了一起
设计要追求完美么
我们需要一次性设计出“尽善尽美”的模型么？
上一篇文章也提到了数仓的多个层次，OBS -> DW -> DM，分别进行收集、整理、分析。这三层的设计根据业务情况可以进行如下安排
- 研究型、探索性、期待挖掘出更多价值、没有固定的报表期待、未来还需要各种扩展：OBS 直接接入各种数据源，DW 从数据角度出发去研究数据之间、业务之间的关系进行构建，DM 根据现在已知的要做的报表进行设计
- 时间紧迫、报表明确：在 deadline 迫使下，且已经有了明确的要做的事情，那么对于 DW 的模型可以根据报表的诉求进行设计，事实表只需要添加报表需要的字段，优先满足明确需求，快速交付。后续再根据变动进行字段的扩充、架构的演进。
本文对通过一个简单的例子说了一下维度模型，但是对于时间该如何处理呢？我们如何快速的算出来一天的总销售量？再比如小明购买物品后又退货了，那么我们该如何记录这个订单的状态变化呢？请见下文详解日期维度、缓慢变化维
最后，何谓完美？没有银弹
| 版权声明: 本站文章采用 CC 4.0 BY-SA 协议 进行许可，转载请附上原文出处链接和本声明。
| 本文链接: Cologic Blog - 报表自动化: 没有压力的维度建模 - https://www.coologic.cn/2020/03/1762/