星形架构和雪花架构
在理解了事实表和维度表之后，接下来的问题就是如何组合它 在维度建模中，存在两种组合维度表和事实表的基本架构：星形架构和雪花架构。
当所有维度表直接连接到事实表时，整个组合的形状类似于星星，所以被称为星形架构。
星形架构是一种非规范化的结构，其数据存储存在冗余，比如考虑商品的维度表，其品牌信息在商品的每一行中都存在，包括其品牌 ID 、名称、品牌拥有者等。
通常很多商品的品牌都是一样的，所以在商品维度表中品牌的信息被重复存储了很多次，也就是存在冗余。
当有一个或者多个维度表没有直接连接到事实表，而是通过其他维度表连接到事实表上时，整个组合的形状就像雪花一样，这种架构被称为雪花架构。
雪花架构是对星形架构维度表的规范化，比如上述的商品表例子，在雪花架构中，其每一行仅存储品牌 ID ，而品牌的所有其他信息（包括品牌名称、拥有者、注册地等所有描述信息）都存储在单独的品牌维度表内。通过品牌 ID 这个外键，商品表可以间接获取到所有品牌描述信息。
雪花架构去除了数据冗余，节省了部分存储，但是也给下游用户的使用带来了不便
如下游用户需要分析品牌的销售额，必须自己先用订单表关联商品表，然后用商品表再关联品牌表。正是由于这一点，在维度建模的实际中， 雪花架构很少得到使用。
有时候简单的方案是最美的、最有力的，也是最有效的
基于星形架构的维度建模就是这种情况 。星形架构牺牲了部分存储的冗余，但是带来了使用上的极度便捷，也使下游用户的使用和学习成本变得非常低。
即使是没有任何技术背景或者维度建模背景知识的业务人员，也很容易理解，更何况目前的存储成本极低，多出的这份存储开销相比后续每次的关联计算、用户使用和学习成本来说，是非常划算的。
星形架构中，每个维度都是均等的，所有维度表都是进入事实表的对等入口，用户可以从任一维度、任一维度属性或者任意多个维度组合、任意多个维度属性组合，方便地对数据进行过滤和聚合（汇总、均值、最大、最小等）操作，而且非常符合业务分析直觉。
业务是多变的，模型的设计必须能够经受住业务多变的需求。在实际设计中，可以通过添加新维度或者向维度表中加入维度属性来满足业务新视角的分析需求。
大多数情况下，数据仓库模型设计中都会采用星形架构，但是在某些特殊情况下 ，比如必须使用桥接表的情况下等，必须使用雪花架构。
维度建模一般过程
维度建模一般采用具有顺序的 个步骤来进行设计，即选择业务过程、定义粒度、确定维度和确定事实。
维度建模的这 个步骤贯穿了维度建模的整个过程和环节，下面逐一介绍。
1. 选取业务过程
业务过程即企业和组织的业务活动，它们一般都有相应的源头业务系统支持。
对于一个超市来说，其最基本的业务活动就是用户收银台付款；对于一个保险公司来说，最基本的业务活动是理赔和保单等 。当然在实际操作中，业务活动有可能并不是那么简单直接 ，此时昕取用户的意见通常是这一环节最为高效的方式。
但需要注意的是，这里谈到的业务过程并不是指业务部门或者职能。模型设计中，应将注意力集中放在业务过程而不是业务部门，如果建立的维度模型是同部门捆绑在一起的，就无法避免出现数据不一致的情况（如业务编码、含义等）。因此，确保数据一致性的最佳办法是从企业和公司全局与整体角度，对于某一个业务过程建立单一的、一致的维度模型。
2. 定义粒度
定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明，粒度传递了事实表度量值相联系的细节所达到的程度的信息。其实质就是如何描述事实表的单个行。
典型的粒度定义包括：
超市顾客小票的每一个子项；
医院收费单的明细子项；
个人银行账户的每一次存款或者取款行为；
个人银行账户每个月的余额快照；
对于维度设计来说，在事实表粒度上达成一致非常重要，如果没有明确的粒度定义，则不能进入后面的环节。
在定义粒度过程中，应该最大限度地选择业务过程中最为原子性的粒度，这样可以带来后续的最大灵活度，也可以满足业务用户的任何粒度的分析需求。
3. 确定维度
定义了粒度之后，相关业务过程的细节也就确定了，对应的维度就很容易确定。正如前文所述。
维度是对度量的上下文和环境的描述
通过维度，业务过程度量与事实就会变得丰富和丰满起来。对于订单来说，常见的维度会包含商品、日期、买家、卖家、门店等。
而每一个维度还可以包含大量的描述信息，比如商品维度表会包含商品名称、标签价、商品品牌、商品类目、商品上线时间等。
4. 确定事实
确定事实通过业务过程分析可能要分析什么来确定。定义粒度之后，事实和度量一般也很容易确定，比如超市的订单活动，相关的度量显然是销售数量和销售金额。
在实际维度事实设计中，可能还会碰到度量拆分的问题，比如超市开展单个小票满 100减 10 元的活动，如果小票金额超过 10 元，这 10 元的优惠额如何分配到每一个小票子项实际设计中，可以和业务方具体讨论并制订具体的拆分分配算法。
……
以上。
