[原创]-数据仓库维度建模
概述
在数据建模过程中，最简单的描述就是按照事实表、维度表来构建数据仓库、数据集市。在维度建模方法体系中，维度是描述事实的角度，如日期、客户、供应商等，事实是要度量的指标，如客户数、销售额等。
维度建模还会分为星型模型、雪花模型等，各有优缺点，但很少直接回答一个问题，也就是数据仓库为什么要采用维度建模？ 维度模型是数据仓库领域大师Ralph Kimball 所倡导，他的《[数据仓库工具箱]》，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
星型模型与OLAP多维数据库
为什么要进行数据建模
- 进行全面的业务梳理，改进业务流程。
在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。
- 建立全方位的数据视角，消灭信息孤岛和数据差异。
通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。
- 解决业务的变动和数据仓库的灵活性。
通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。
- 帮助数据仓库系统本身的建设。
通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。
事实表
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，例如电商行业中的订单表，每完成一个订单，就会在表中增加一条记录，实际上就是业务上的流水表，表内不存放实际的内容，是一堆维度表主键的集合，通过这些维度主键可以对应到维度表中的一条记录。
维度表
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，这里的主键和外键可以是实际表中创建的，也可以是物理意义上的虚拟主键和外键。
维度表通常是比较宽、扁平型的非规范表，包含大量的低粒度属性。
以上面两种表简单举一个列子:
建模原则
- 高内聚和低辑合
将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型：将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。
- 核心模型与扩展模型分离
建立核心模型与扩展模型体系，核心模型包括的宇段支持常用的核心业务，扩展模 型包括的字段支持个性化或少量应用的需要 ，不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。
- 公共处理逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
- 成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
- 数据可回滚
不改变处理逻辑，不修改代码的情况下重跑任务结果不变
- 一致性
字段命名及定义必须一致
- 命名清晰、可理解
表命名需清晰、一致，表名需易于使用方理解
维度模型设计
在数仓中存在几种数据存储方式的算法：
1.历史快照： 每天都是增量数据，保存每日增量，例如流水表
2.拉链： 对于流水记录存储，一般存储5年的记录，例如在银行业中，每天的流水记录太大，数仓存储压力太过大，用历史拉链的方式节省存储空间拉链表是一种数据库设计模式，类似与面向对象的23中设计模式，用于存储历史数据和分析时间维度。可以查看某一个时间点活着时间段的历史快照信息；
3.全量覆盖： 配置信息可以用这种方式
宽事实表设计的优缺点：
- 业务直观，在做业务的时候，这种表特别方便，直接能对到业务中。
- 使用方便，写sql的时候很方便。
- 数据冗余巨大，真的很大，在几亿的用户规模下，他的订单行为会很恐怖、粒度僵硬，什么都写死了，这张表的可复用性太低。
维度模型设计的优缺点：
- 数据冗余小（因为很多具体的信息都存在相应的维度表中了，比如客户信息就只有一份）
- 结构清晰（表结构一目了然）
- 便于做OLAP分析（数据分析用起来会很方便）
- 增加使用成本，比如查询时要关联多张表
- 数据不一致，比如用户发起购买行为的时候的数据，和我们维度表里面存放的数据不一致
