我曾经设计过ER模型和维度模型，对两者的差别有过了解。 这里只涉及到维度模型，因为ER模型的设计比较复杂，时间周期太长。
维度建模只包含两种表：事实表和维度表
事实表产生于业务过程，存储了业务活动或事件提炼出来的性能度量。从最低的粒度级别来看，事实表的一个行对应一个度量事件。
事实表根据粒度的角色划分，可分为 事务事实表、周期快照事实表、累计快照事实表。
需要注意的是，同一张表里的粒度必须相同，以上三种表不能混用。
- 事务事实表
用于承载事务数据，通常粒度比较低。它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表。例如商品交易事实表、用户充值事实表。
- 周期快照事实表
按照一定的时间周期间隔来捕捉业务活动的执行情况。两个关键字：周期、快照，简单说就是粒度比较粗事务事实表的定期快照。一旦装入事实表就不会再更新，它是事务事实表的补充。用来记录有规律、固定时间间隔的业务累计数据，通常粒度比较高。例如账户的月平均余额事实表、年商品销售额。
- 累计快照事实表
累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。
累积快照事实表记录的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点，一个生命周期对应一行。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。
维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，它里面的数据就是一些日，周，月，季，年，日期等数据，维度表只能是事实表的一个分析角度。
- 完成维度的初步定义，并保证维度的一致性。
- 确定主维表（中心事实表）。此处的主维表通常是数据引入层（ODS）表，直接与业务系统同步。例如，s_auction是与前台商品中心系统同步的商品表，此表即是主维表。
- 确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、卖家、店铺等维度存在关联关系。
- 确定维度属性，主要包括两个阶段。第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。以商品维度为例，从主维表(s_auction)和类目 、卖家、店铺等相关维表中选择维度属性或生成新的维度属性。
维度表常涉及到两种概念：退化维度和缓慢变化维度
- 退化维度
退化维度不是维度，它表示一种针对维度展现的方法。在实际开发中，经常遇到在一些事实表频繁使用的维度，比如订单表中的用户信息、商品信息。为了使用方便，这些维度信息便可以直接放到事实表中，毕竟对于目前大数据来讲，存储成本还是很低的，这种设计就称为退化维度。
- 缓慢变化维
维度并不是保持不变，它会随着业务的发展而发生改动。这种随着时间发生变化的维度称为缓慢变化维。
具体解决方式，请看博客
具体细节查看博客
事实表和维度按照数据组织类型可以分为 星型模型、雪花模型、星座模型。
- 星型模型
星型模型是以事实表为中心，所有维度直接关联在事实表上，呈星型分布，类似放射状。
- 雪花模型
基于星型模型，维度表上又关联了其他维度表。这种模型维护成本高、性能较差，不建议使用。尤其对基于Hadoop体系搭建数据仓库，减少join就是减少shuffle，性能差很多。
- 星座模型
基于星型模型的扩展，多张事实表共享维度表。数仓建设的后期，大部分维度建模都是星座模型。