数据仓库多维建模笔记

《数据仓库工具箱—维度建模的完全指南》笔记

一、数据仓库体系结构和建模过程、技巧

        关键点：数据仓库体系结构、维度建模的四个步骤、数据仓库总线结构、一致性维度。

1、对于数据仓库DW来说，业务需求是第一位的。

2、数据仓库的目标：

      1）、随心所欲的访问数据。直观、明显、简单、易用、切割、合并、下钻、上卷；

      2）、一致的展现数据（相对于原来从多个系统中出来的报表不一致）；

      3）、适应性、扩展性、可维护性；

      4）、为领导决策提供支持；

3、数据仓库的组成。

      源数据-->数据准备区-->数据仓库（维度建模）-->数据聚集区（OLAP）-->展现。

      其中原系统到数据准备区属于ETL过程。数据仓库和数据聚集区称为数据展示。展现称为数据存取工具。

4、数据仓库应特别注意的几点特点：

      1）、数据应该以维度的形式进行展示、存储和访问；

      2）、数据仓库中必须包含详细的原子数据；

      3）、必须采用共同的维度和事实表来建模；

5、数据仓库采用使用维度建模的好处：易理解、查询的高性能、修改的灵活性和可扩充性。

6、维度建模的扩展性。表现在三个方面：

      1）、在现有的事实表中增加维度；

      2）、在事实表中增加事实；

      3）、在维度表中增加属性；（第一章）

7、维度模型设计的四个步骤：

      1）、选取业务（主题）；

      2）、定于业务处理的粒度；

      3）、选择维度；

      4）、选择事实。

8、应优先为模型选择有原子性的信息，因为原子性的数据提供了最大限度的灵活性，可以接受任何可能形式的约束。（第二章）

9、数据仓库总线结构。实际上是一种增量建模方式，通过一致性维度来集成数据中心。

      数据总线矩阵：业务处理、公共维度。

      一级数据中心：衍生于单个基本源系统的数据中心，建议从一级数据中心开始建模，因为导致失败的主要风险是ETL。

      合并数据中心：合并多个位于不同源系统的一级数据中心。（第三章）

10、维度建模复查。

        考虑的问题：粒度，日期维度，退化维度，维度属性采用名称而不是编码，代理关键字，维度的多少。

11、维度建模常犯的错误：

        1）、舍弃一致性维度和一致性事实表；

        2）、事实表的粒度不采用原子型；

        3）、基于报表来设计维度表；

        4）、不使用代理关键字；

        5）、忽视维度的变化的需求；

        6）、将体系与体系层次分解成多个维度；

        7）、在维度表中为节省空间而限制使用详细的描述属性；

        8）、在事实表中放置用于约束与分组操作的文本属性。（第十五章）

12、数据仓库成功的五个前提：

        1）、拥有精明、强干的业务用户。用户应该对数据仓库具有独特的见解，坚信数据仓库项目具有实现的价值；

        2）、机构必须存在建立数据仓库坚实而有说服力的业务动机；

        3）、数据仓库的可用性；

        4）、业务用户与IT人员之间的沟通；

        5）、业务分析人员的分析文化，是基于图形、数据还是直觉、传闻和一时冲动。（第十六章）

二、维度表建模技巧

关键点：退化维度、代理关键字、一致性维度、渐变维度、角色模仿、杂项维度、微型维度、

                深度可变的层次建模方法、审计维度、多值维度解决办法、异构产品解决办法。

1、维度表倾向于将行数做得相当少，而将列数做的特别大。数据仓库的能力直接与维度表的属性的质量和深度成正比。

2、维度的属性采用文字而不是编码。

3、维度表通常是不规范的，几乎总是用空间换取简明性和可访问性。（第一章）

4、日期维度，应包含星期、周末指示符、月末指示符、节假日指示符、重大事件、财政时间等。

5、如果需要处理一天中不同时间，则增加一个时间维度。

6、一个维度包含多个体系（层次），每个层次包含若干级别。

7、退化维度。一方面可以通过退化维度对数据进行分组，另一方面可以使用退化维度关联到源数据上，有利于ETL更新及排错。

8、一般情况维度个数应该控制在15个以内，维度过多影响查询性能和磁盘空间。一些小维度可以进行组合，这取决于具体的业务。

9、代理关键字。

      使用代理关键字的优点：能实现渐变维度；获得性能上的优势，节省事实表空间；

                                                  可以记录没有操作源码的数据（ETL过程生成）；处理关键字段的修改、删除等。（第二章）

10、一致性维度。具有一致性的维度关键字，一致的属性名称，一致的属性定义，一致的属性值。

                                一致性维度对于设计可以进行集成的数据中心来说，具有绝对的决定性作用。（第三章）

11、渐变维度。渐变维度的处理办法：

                            类型1：改写属性值；类型2：添加维度行；类型3：添加维度列。第二种类型最常用。

12、快变维度的处理办法：将这些迅速变化的属性分裂成一个或者多个单独的维度。（第四章）

13、维度的角色模仿。在同一个维度表上通过视图的形式建立多个维度。在实际运用中，很多OLAP工具都支持在同一个维度表上建多个维度，而并不需要建立视图。

14、实体之间存在固定的，不随时间变化的，强烈相关的关系时，显然应该将它们当作单一维度进行建模。

15、杂项维度。将标志与指标符从设计中剥离出来，将其封装成一个或者多个杂项维度。（第五章）

16、将聚集事实放入维度表的优缺点。优点：查询时可以对聚集属性进行约束。缺点：ETL过程变麻烦了。

17、雪花模型的使用场合：粒度悬殊，节省空间（属性众多）。

18、宽度变化的属性集的处理办法：拆分成两个维度。Oracle数据库不存在这个问题。

19、采用类型2的方式处理维度慢性变化时，应该注意避免计数过度。

20、深度不变的体系结构（层次、级别）。一个层次建立单独的字段。如果某一个级别没有值，就应该用较低级别的属性覆盖该值。

21、深度可变的体系结构。使用桥接表来解决。父到子的每一条路径都包含一行记录，到其自身长度为0的路径包含一行。实际上是把循环递归的过程通过表数据的形式实现。大量olap工具以提供了对小于64000个成员的中小尺寸维度中这些体系进行导航操作得更加强劲的内置功能支持。（第六章）

22、依照实物描述内容在每行加入生效和截止日期标记，可以将类型2渐变维度设计方案修改为允许自然的对维度在时间上进行非常精细的切割。

23、审计维度。源系统的情况；抽取软件的版本；抽取记录数；开始时间；完成时间等。

24、维度的属性数量不确定时，使用关键词支架维度。相当于将横表设计成纵表。使用union和intersect命令解决SQL跨行约束问题。（第八章）

25、维度类型：因果维度、多日期或时间标记维度、退化维度、角色模仿维度、状态维度、审计维度、杂项维度。

26、多值维度。概念：一个账户拥有多个客户，一个客户也可能拥有多个账户。解决办法：桥接表。

27、异构产品方案。概念：每种产品类型都有大量的专用属性与度量事实不能为其他产品所用。解决方案：核心维度，定制维度，使用相同的代理关键字。采用支架结构。（第九章）

28、日期维度。国别历法的处理办法，做成日期维度的支架。

29、多个时区日期的处理办法，增加维度。（第十章）

30、多值维度解决方案：

         所谓多值维度是指一个事实表对应多个值的维度，比如，住院结算事实表拥有多个疾病。

         通过桥接表来实现。桥接表可以增加起止时间来满足住院渐变维度。可以增加加权因子来实现财务报表关于疾病的分类统计。

31、稀疏事实表的解决方案。事实维度表。实际上是纵表和横表的设计思想。

                                                    优点：灵活、结构简单、节省空间。缺点：生成查询、报表复杂、行间计算困难。

32、迟到维度行的处理办法：

        所谓迟到维度是指某项属性到当前时间才知道其以前的值。

        通过渐变维度（类型2）的方法处理，在维度表中增加记录并修改其他型的起止时间，在事实表中修改该维度的代理关键字。（第十三章）

三、事实表建模技术

1、事实表中的事实分为三种类型：可加性事实，半可加性事实，非可加性事实。

2、事实表的三种粒度：事务，周期快照，累计快照。

3、事实表倾向于具有更多的行和更少的列。

4、事实表的主键应采用复合主键，引入唯一的rowid关键字作为主键字并无什么优点可言。（第一章）

5、明显属于不同粒度的事实必须放在单独的事实表中。

6、将可计算得值作为事实的原因：消除用户出错的可能性，一致的引用它。例如，利润=销售额-成本额，将利润作为一个事实而不是通过展现工具进行计算得到。

7、非可加性的数据项尽量不要放到事实表中。例如，毛利润率是非可加性数据，不应该保存在事实表中，应保存分子和分母，再通过前端展现工具进行计算得到。

8、非事实型事实表。解答什么促销产品没有卖出去的问题。建立一张非事实型事实表，促销产品（周期快照）中每个商场的每隔促销产品每天创建一行。再关联销售事实表来解决什么产品没有卖出去这个问题。

9、事实表的粒度很关键，决定了维度模型的扩展性。过早汇总或者聚集处理必然限制对维度的增补。

10、半可加性事实。对特定的维度具有可加性，对其他维度不具有可加性。

11、周期快照事实表是最常见的库存设计方案。

12、一致性事实。一致的事实定义，一致的测量单位。（第三章）

13、使用单个事实表（通过增加事务类型维度）还是多个事实表的选择：

         1）、业务需求（目标是降低复杂度，用最有效的形式将数据展示给用户）；

         2）、业务处理的关联性；

         3）、源系统；

         4）、维度是否完全一致。（第四章）

14、事实表的规范化。纵表和横表的设计方式。优缺点。事实设置显得比较稀疏并且不在事实之间运算的情形是有用的。

15、不同粒度事实的处理办法。例如，订货系统中的订货分列项事实表（基于产品）与装运费（基于订单）。

         两种处理方式：（1）、分配到细节层次（装运费à产品）。（2）、建立两个事实表。优先采用第一种方式。

16、累计快照。采用对整个订单处理流程的分析感性趣，他们想了解产品的移动速度，累计快照很好的体现这种业务情景。

                             适用：具有明确起止时间的短期处理应用。

17、多个计量单位的处理办法。将转移因子写入事实表。

18、三种事实粒度的比较：（第五章）

	时间段	粒度	加载	更新	日期维度	事实
事务	时间点	每个事务一行	插入	不	事务日期	事务活动
周期快照	规律间隔	每段一行	插入	不	时间段终止日期	间隔事务
累计快照	不确定跨度，一般短期	每个生命期一行	插入更新	行为发生时更新	关键环节多日期	生命周期性能

19、至今为止事实：应该计算出来，而不是保存在事实表中。数字型事实必须与粒度保持一致。

20、事实的变化通过增加一行冲减记录，而不是通过修改原事实数据。

21、事实的自由分段。通过分段定义表连接到事实表上，来灵活划分和定义分段。分段事实字段需建索引。（第七章）

22、时间点结余建模。在事实表中增加最后标记字段和事务结束结余来实现。使用事务表来代替日快照事实表。（第九章）

23、多个事实表粒度。（第十一章）

24、非事实型事实表。没有度量值，记录发生的事件。分为两类：

         1）、记录事件与大量维度实体同时出现的内容进行记录；

         2）、范围表。可用来实现没有发生的事件。Olap在分析没有发生的事件方面做出了卓有成效的工作。（第十二章）

25、稀疏事实建模。将稀疏事实做成事实维度。纵表和横表。

26、迟到的事实行的处理办法。根据时间在各维度表中找到对应的代理关键字，然后插入事实表中。（第十三章）

27、异构产品事实表建模。建立一个核心事实表和一簇定制事实表。使用相同的代理关键字。

28、合并事实表。将两个事实表通过公共的维度合并在一起。可以通过展现工具进行合并。（第十五章）

四、行业建模经验

。。。。。