由于周二要开会讨论，周一必须交掉初步的设计，来不及把书看完，首先把余下部分笔记粘贴上，再谈谈自己的看法。
7. 在Star Schema中，可以有Junk dimension table. 里面可以存一些flag,type这种distinct value较少的属性。
8. 如果两个fact 同时发生且属于同一粒度(不存在不同dimension 过滤属性），即存在于一个fact表中，否则存储于不同的fact表，不同的fact table 可以share 同一个dimension table
9. 不要试图去join 两张fact tables, 一者是慢，因为fact table 往往很多行，二者是结果有错.如果需要对比或者总结两张fact table, 必须使用drill across: 1. 第一步对两个fact table分别做query。2. 然后把两个结果做join.
10. 做 drill across, 有三种做法:
1) 在数据库中对不同的fact table做query，将几个结果发送给外部工具来合并作分析
2)在数据库中对不同的fact table做query，将几个结果作为临时表存在数据库中，之后在数据库中做merge。之后把最终结果发送给外部分析工具。
3) 利用复杂的SQL一次性搞定query和merge，但其实实际工作与2）基本一样。
11. 如果两个dimension attributes可以出现在两个不同的行为中（每个fact table代表一个行为），那么这两个dimension attributes 应该放在两张dimension table中.
12. 如果两个dimension attributes 无需任何行为也相关，例如product 和 brand. 没有任何交易发生，此二者也相关. 所以这两个dimension attributes 应该被放入一个dimension table.
13. 可以在date的dimension table中加一些属性，例如day of week(For example: Monday), Month number(1-12） and so forth
14. 需要Promotion Coverage Factless Fact Table来记录所有促销的产品，不然的话，就无法追踪促销但没有卖出的产品信息
15. 需不需要查询同一个transaction的tax和discount信息，如果不需要，transaction表中就不需要存储tax和discount的各种外键，即不需transaction作为fact table.
上述的笔记只是书中各种设计的rules。现实的数据比书本中的例子要复杂很多，往往是类似xml的层次型数据，下一篇会进一步介绍实际的处理和设计方法。