1、基于RDBMS的数据仓库实现：数据仓库的设计也可以理解为面向OLAP的数据库设计。数据仓库的设计模式分为星型结构、雪花结构(1个维度表向外连接子维表)、星座结构（1个维度被多个事实表使用）。在星型模型中主要数据存储在事实表中，没有冗余，并符合3NF
2、除了对应到维度的外码和度量属性，事实表中还常常考虑另外两个属性：事务标识码(transaction identifier)和事务时间(transaction time)。
事务标识码通常被命名为TID，其意义就是各种订单号，事务编号...... 为什么将这个属性放到事实表而不是维表中呢？一个主要原因是它的数量级太大了，这样每次查询都会耗费很多资源来Join。这种将某些逻辑意义上的维度放到事实表里的做法被称为退化维度(degenerate dimension)。
将事务时间维度放到事实表中的考虑也是出于相同考虑。然而这么设计又一次"逆规范化"了：事务标识码非主码却决定事务标识时间，显然违背了3NF。但现在我们是为数据仓库建模，所以这样做是OK的。另外在分布式的数据仓库中，这个字段十分重要。因为事实表的数量级非常大，Hive或者Spark SQL这类分布式数据仓库工具都会对这些数据进行分区。任何成熟的分布式计算平台中都应禁止开发人员建立非分区事实表，并默认分区字段为(当天)日期。
3、细节事实表(detailed fact tables)中每条记录表示单一事实，而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看，细节事实表通常有设置TID属性，而聚集事实表则无。
两种事实表各有优缺点，细节事实表查询灵活但是响应速度相对慢，而聚集事实表虽然提高了查询速度，但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中，聚集事实表使用和细节事实表细节事实表的维度。
4、比较经典的数据仓库设计解释：https://blog.csdn.net/lzlchangqi/article/details/52841429
5、数据仓库建模是一个综合性技术，需要使用到ER建模、关系建模、维度建模等技术而且当企业业务复杂的时候，这部分工作更是需要专门团队与业务方共同合作来完成。因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。
6、维度表：分三类，固定维度，渐变维度（SCD:Slowly Changing Dimension），和快变维度。
渐变维度解决数据缓慢变化的问题，学习资料：https://ask.hellobi.com/blog/biwork/974
https://blog.csdn.net/xiaoxu0123/article/details/5417894
维度层次：维度的层次分为完全层次和不完全层次两种。日期维度就是完全层次，日-月-年 。所谓不完全层次就是有层些层次会断层，这个时候维度上卷时就是空的，所以这个时候的解决方案就是断层维度自动填充下级维度的值，也就是说下级维度上卷时卷到的是它自己。 比如 日-月-推广期-年 这个层次维度，一个推广期可有有多个月份，也有可能某个月份没有推广期，这个时候，没有推广期的月份的 推广期这个层次的值就填成月份的值。
| 商品 | 时间 | 销量 |
| A | 2017 | 5000 |
| A | 春季推广期 | 3000 |
| A | 3月 | 1000 |
| A | 4月 | 2000 |
| A | 8月 | 2000 |
| A | 8月 | 2000 |
7、数据仓库深入学习笔记：https://blog.csdn.net/wzy0623/article/list/17