数据仓库点滴

1：数据仓库必须由业务用户的需求来驱动，并因此从一个简单的维度视角来建立于展示数据仓库这样的概念；
2：对数据仓库，业务才是第一位的；
3：操作性系统：存入数据；数据仓库：取出数据；
4：数据仓库在需求、客户、体系结构和运行机制与操作性系统有很大不同；
5：客户的烦恼：不能访问数据；切割数据；快速访问；不同系统间不同编码；
6：数据仓库：易阅读的、并且精心组织，可信而安全；
7：EAI：企业应用一体化，所有系统按一定的视角来统一设计；
8：数据仓库的4个环节：操作源系统、数据聚集、数据展示和数据的存取；
9：ETL：数据析取转换和加载；转换如拼写错误、丢失补充、标准化格式、多数据源组合、重复数据消除、仓库
关键字的分配；
10：维度模型是为数据仓库用户提交数据最可行的技术手段；
11：维度建模和3NF范式建模的不同；
12：数据仓库维度建模要求：必须包含原子数据、一致性维度和事实；符合数据仓库总线结构；
13：总线结构是构造分布式数据仓库系统的秘诀；
14：元数据；
15：ODS：操作数据的存储，一般没有必要；
16：可加性、半加性和非加性事实；
17：事实表倾向于更多的行和更少的列，维表则相反；
18：事实表分类：周期、事务和累积快照；
19：数据仓库：以数据库为基础，在需求、客户、体系结构和运作方式等方面都与数据库应用有很大的不同；
20：数据仓库的两种增值操作：OLAP和DM；
21：设计维度模型的四步处理过程：业务、数据粒度、维度和事实；
22：日期维度；
23：退化维度；
24：雪花处理，一般不建议，除非支架如日期支架等；
25：代理关键字：
26：事实表中用ROWID的意义不大；
27：维表，少行多列，少于100万，50--100个属性不少见，并且使用单一的关键字；
28：数据仓库的能力直接与维度属性的质量和深度成正比；
29：维度属性应该是真正的文字而不是代码；
30：维度建模的好处：简明性、对称性和性能上的好处；
31：维度模型和数据中心的要求：符合数据仓库总线结构；
32：建模中避免的疏忽：大的规划，而应该小量迭代开发；注意技术而忽视用户，注意力要放在前台的查询、
性能和容易使用上；
33：数据仓库的成功直接系于用户的接受程度；
34：如果用户不将数据仓库作为提高决策制定水平的基础环节，则无意义；
35：维度建模不仅适合于总结性的数据，而且也适合于细节性的数据；
36：计算量应该存储，不要太计较空间；而百分比和比率应该存储分子和分母；
37：开发人员要估计最大事实表的行数；
38：日期维度考虑：年、季度、月、日、半年、旬、周、财政年。。。节假日、月周末、交易日等；以及重大
事件；
39：日期关键字应该是整型，不要使用自然关键字；
40：因果维度和偶然维度；
41：退化维度：所形成的维度为空，一般是事实表的自然关键字；
42：必须避免在事实表中出现空关键字；
43：数据仓库团队应该有意识地打破一些传统的建模规则，因为这是将注意力集中到通过容易使用与良好的性能
来发挥业务价值而不是放到事务处理的效率上的需要；
44：维度的snowflaking导致过多的维度；为了节省磁盘空间而投入精力去规范化维度表，只不过是浪费时间；
45：允许雪花，如支架处理；
46：过多的维度，会导致事实表消耗过大的磁盘空间；
47：1-15个维，不多于25个维；
48：体系层次相关的属性，应该成为同一维度的组成部分；
49：代理关键字：仅用于维度表和事实表的连接；不要含有其它意义；
50：使用代理关键字的好处：对操作性变化的缓冲；性能上的优势；支持处理维度属性的修改；
51：维度表：不要使用合并关键字或复合关键字；
52：应该避免在维度与事实表之间给出多个并行的连接，称为“双筒”连接，这样对性能会产生不利的影响；
53：用原子性数据加载能够获得最大的灵活性；
54：相似成组，市场篮子分析；
55：用详尽而强壮的描述属性填充维度表是至关重要的。
56：经纪类券商值链：客户开户--资金存取--买卖股票--清算交收；
57：三种库存类型：事务快照、周期库存快照、库存累积快照；
58：周期性库存快照会生成密集的快照表；一般随时间的增加，快照的频率要降低，如60天；
59：半加性事实(semiadditive facts)：只在有些维度上可加，一般是时间，如余额数据；
60：半加性事实一般计算余额数据，如银行即按照日平均结余额来计算月帐户总额的；
61：周转次数=销售总量/日平均持有；证券交易周转次数=交易量/日平均总资产余额；
62：库存累积快照：从入库到出库这段时间内操作的跟踪；
63：数据仓库总线矩阵：突出一致性维度的要求，即非常重要的维度；
64：多事务事实和单事务事实，一般多源系统使用多事务事实；
65：缓慢变化维度：即维度属性随时间在发生变化；称为渐变维度（Slowly changing dimensions）:SCDs
66：维度变化的跟踪可以将每件事情都放在事实表中或者使每个维度都与时间相关，从而处理这些变化的做法是不能让人接受的；
67：渐变维度的处理类型1：改写属性，快速而简单，缺点是丢失历史；
68：渐变维度的处理类型2：添加新的维度行；可以加生效或截止日期，但仅用在ETL环节；
69：类型2的管理办法：每次计算行CRC校验保存校验值，下次计算则比较，有改变则加入新的维度行；
70：类型2的优缺点：准确跟踪历史；缺点是加速维度表的膨胀，对于超过百万行的维度表是不合适的；也不能将新旧历史联系起来；
71：渐变维度的处理类型3：添加维度列，可以有效跟踪新旧历史；
72：快速变化维度的处理：将迅速变化的属性分裂成一个或多个单独的维度，然后在事实表中放置两个外关键字，一个用于主维度表，另一个用于快速变化维度表；
73：采购管理针对买方；定单管理针对卖方；
74：事实的规范化，即以事务类型来区分事实，是不推荐使用的；事实处于同一行中运算更容易；如证券成交量和手续费放在同一行中是比较合适的；
75：维度的角色模仿：如不同的日期连接相同的维度表，SQL会解释认为要求相同的时间，而实际中是不可能的；这样就要求角色模仿（role-playing）；
76：维度可以是单一的表，但每个角色都应该单独标记在视图中；
77：产品维度的特点：大量冗长的描述列；在许多非体系属性之外，存在一个或多哥属性体系结构；我们不提倡为
产品维度创建经过规范化处理的雪花状子表；
78：退化维度：一般是为操作型事务标识符而保留的；
79：杂项维度：junk dimension，将低基数的标志与指示符分组；
80：杂项维度的建立一般可以预先建立，如果理论值很大是，则可以考虑每遇到一个值就添加；
81：多种流通货币使用多事实量；
82：粒度不同的标题与分列项事实；父事实的分配处理，以适应子事务的粒度；
83：理想的情况下，分配处理由财务或业务团队主持分配工作事务。
84：累积快照的区别：随着处理行为的发生，一般都要重新存取事实表（插入和更新），而周期快照和事务快照只进行插入操作；
85：累积快照最适合于具有明确起止时间的短期处理应用，如加工流水线；而诸如银行帐户这样的长期应用则应该使用周期快照；
86：多计量单位，保存转换因子于事实表中；
87：周期性快照通常比事务事实表具有更多的事实；
88：数据仓库设计人员通常在常规静态数据仓库前面建立一个实时分区以满足用户需求；
89：CRM达到的目标：收入增加、效率提高；提高营销效果与周转率，增加营业收入；低成本的营销生产率；增高的客户利率富余，更好的客户满意度，增长的客户保持量；CRM的另一个目标是将不能获利的客户变成可以获利的客户；
90：CRM的有效性首先依赖于在每次与客户协作中进行的数据收集行为，然后取决于数据的广泛性在分析中所发挥的支配作用；
91：数据仓库对CRM数据的来源：事务型数据、协作行为数据、人口与行为数据、自备概况数据；
92：操作性CRM与分析性CRM；
93：一致性客户维度是建立有效CRM的关键元素；
94：姓名和地址属性因该尽可能分成一些基本的部分；姓名地址的解析；客户属性：地理属性；常见的客户属性，如日期开户、出生等；日期使用角色模仿；客户分段或分值属性：性别、种族、年龄、收入、业务市场分段等；
95：聚集事实属性：将聚集事实作为维度的属性提供；
96：低基数属性集的维度支架，一种可以接受的雪花设计；
97：大型变化客户维度：百万以上；
98：快速变化超大维度（rapidly changing monster dimension）:解决办法：将分析频率高或者变化频率大的属性拆分成微型维度（minidimension）；将比较恒定或查询频率不高的属性遗留在原来的巨型客户表中；
99：在创建微型维度时，诸如收入与购买总额这样的不断变化的属性，应该被转换成波段分布的范围，即要强迫微型维度中的属性只能在数目相当少的离散值中取值；波段范围确定后，以后再修改是不切实际的；
100：建立微型维度后，每次建立事实表行时，都要包括客户相关的两个关键字，普通客户维度关键字与微型维度关键字；