kinball＜数据仓库工具箱＞阅读笔记

1.  一个数值量到底是事实还是维度属性，对设计者来说是一个两难的问题，很难做出决策。连续值数字基本上可以认为属于事实，来自于一个不太大的列表的离散数字基本可认为是维度属性。
2. 由于与事实表比较，维度表通常要小的多，因此规范化或雪花模式实际上对数据库的总容量没有多大影响。一般对维度表存储空间的权衡往往需要关注简单性和可访问性。
3. 避免独立数据集市方法，虽然独立的数据集市往往也采用维度建模方法，但是忽视了一致性原则。
4. 项目可能包含多个业务过程，可以分多次迭代实现多个业务过程覆盖，而不是试图一次完成全部业务过程的覆盖。
5. 对非可加事实，尽可能存储相关的可加度量，最终通过计算求得非可加事实。比如比率，事实表中不存储比率，而是存储参与比率计算的相关可加的事实。
6. 维度表需要增加代理键，而不是使用来自业务系统的主键。日期维度除外，因为日期维度高度可预测且稳定。
7. 避免维度表存在空值属性，比如null或""，一方面不同的系统处理空值存在兼容问题，另一方面null值容易导致代码逻辑错误，比如，where column1 <> 'a'，结果中不包含null值的行，这一行为容易在代码中被忽略。再者，在报表中，空值会导致使用人员疑惑，看不懂。
8. 维度可包含对其他维度的引用，比如，用户账户维度可以引用表示开户银行的维度。这类被引用的辅助维度成为支架维度。但是要避免滥用支架维度，通常情况，两个维度间的关联应该由事实表来实现。
9. 避免两个事实表的连接操作。
10. 当潜在事实的数量达到极限（几百个），但是对于每一行，大部分事实无值，这种情况下可以考虑增