范式建模和维度建模对比
范式建模
该方法的主要由Inmon所提倡，主要利用关系型数据库进行数据仓库的建设，且模型的建设方法和业务系统的数据模型比较类似
经典范式理论中，一个符合第三范式的关系必须具有以下三个条件：
- 1NF：每个属性值唯一，不具有多义性；
- 2NF：每个非主属性必须完全依赖于整个主键，而非主键的一部分；
- 3NF：每个非主属性不能依赖于其他关系中的属性。
优点：
- 节约存储
- 结构清晰
- 易于理解
- 适合关系型数据库
缺点：
- 构建比较繁琐
- 查询复杂
- 不适合构建在大数据分布式环境下
虽然有这些缺点，但是范式建模的理论，仍然是需要我们去熟练掌握。原因有如几点：
- 数据仓库的上游有相当一部分数据源是业务数据库，而这些业务数据库，其理论一般基于范式理论；
- 数据源的规范定义需要我们了解范式理论；
- 数据仓库下游系统比如报表系统设计时，可能会用到范式理论。
维度建模
范式由于存在上述的问题，Kimball根据自己的经验，提出的维度建模的理论，即数据都可以抽象成事实和维度，维度为观察事物的角度，事实为对应某粒度下的度量值，一般，维度建模的步骤如下：
- 1.选择业务过程
业务过程是-系列操作活动，转换为事实表中的事实，例如每个月每个账单快照 - 2.声明粒度
粒度是指事实表中的一行代表什么。同一事实表不要混用粒度，最好从最小粒度开始设计维度，因其能承受用户无法预知的查询需求。 - 3.确认维度
维度是根据粒度将表分开成多个维度表，即从不同维度（角度）去看。
维度是数据仓库的灵魂，是BI的入口和驱动 - 4.确认事实
事实是指一种在某个粒度下的度量，例如在销售维度中，销量和总额是良好的事实，而商店经理的工资则不允许出现在该维度中。
优点：
- 方便使用
- 适合大数据下的数据处理
- 适合进行OL AP操作
缺点：
- 维度补全造成的数据存储的浪费
- 维度变化造成的数据更新量大
- 与范式理论差异很大，是典型的反三范式
维度建模举例
假设我们要构建的是一张订单表，那业务过程即为这个具体是哪种业务场景下的订单数据;
粒度即为该表中的每一 条数据具体是细化到如何的程度，是一条数据代表一个订单还是多个订单;
维度即为该订单有哪些的附属信息，比方说订单类型、支付方式、城市信心、日期信息等等;
事实是指具体的订单量的数值。
那么，我们可以假设，这个订单表的基础信息包括：
| 编号 | 字段 |
|---|---|
| 01 | 订单ID |
| 02 | 发货人ID |
| 03 | 收件人ID |
| 04 | 发货时间 |
| 05 | 发货地点 |
| 06 | 快递单号 |
| 07 | 物品件数 |
| 08 | 订单总金额 |
| 09 | 订单状态 |
| 10 | 下单时间 |
| 11 | 支付订单号 |
| 12 | 支付时间 |
| 13 | 支付状态 |
| 14 | 收货时间 |
| 15 | 收货状态 |
业务过程：用户购买商品的订单记录表
申明粒度：每一条记录代表一个有效订单
确认维度：商户维度、用户维度、支付维度、收货维度
确认事实：订单总金额
通过对不同的维度进行统计组合，我们就会得到一个多维数据集，来从多角度观察我们的业务过程的好坏情况。