细化维度表属性

《The Data Warehouse Toolkit, 2rd》读书笔记

数据仓库受业务驱动的最终目标

数据仓库必须使组织机构的信息变得容易存取

数据仓库必须一致地展示组织机构的信息

数据仓库必须具有广泛的适应性和便于修改

数据仓库必须发挥安全堡垒作用以保护信息资产

数据仓库必须在推动有效决策方面承担最基本的角色

数据仓库被业务群体所接受才能认定是成功的

数据仓库体系的主要构件

操作型源系统，数据聚集，数据展示，数据存储工具

操作型源系统：外部的操作型数据库

数据聚集：数据存储和ETL（extract-transformation-load）

数据展示：数据组织、存储，便于其他应用直接查询

数据存储工具：存储、读取数据的工具

事实表和维度表术语

元数据：描述数据的数据，也就是数据属性。例如下图中，“出版者”、“出版日期”是元

数据项目，“中信出版社”、“2011”是元数据内容。

事实表：包含数字数据（事实），多个索引（维度表的主键）。例如下图中，“Product Key”、“Store Key”是索引，“Quantity Sold”、“Dollar Sales Amount”是数字数据。

维度表：包含主键（事实表的索引），详细信息。例如下图中，“Product Key”是主键，“Weight”、“Product Description”等是商品的详细信息。

粒度：数据单位中保存数据的细化或综合程度的级别。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。

连接事实表和维度表

理解了事实和维度表之后，现在就考虑将两个组块一起融合到维度模型中去的问题。如下图所示，有数字型度量值组成的事实表连接到一组填满描述属性的维度表上。这个星型特征结构通常被叫做星型连接方案。该术语可以追溯到最早的关系数据库时期。

关于其中用到的维度方案，应该注意的第一件事就是其简明性与对称性。很显然，业务用户会因为数据容易理解和浏览而从简明性方面受益。上图设计方案的魅力就在于它能够充分地被业务人员所认可。在针对几百个相关实例所做的自由评测活动中，用户们一致认为维度模型正是他们所要的东西。特别是，表格数量的减少和富有意义的业务描述符号的使用，更进一步减少了出现误解的可能性。

如果有一张已经存在的规范化ER图，将它转换为一组维度模型的第一步是，将ER图分成一些分散的业务处理过程，然后分别单独建模。第二步是选出ER图中那些含有数字型与可加性非关键字事实的多对多关系，并将它们标记为事实表。最后一步是，将剩下的所有表复合成具有直接连接到事实表的单连关键字的平面表，这些表成为维度表。

有关维度建模的讹传

神话1 维度模型与数据中心都只是应用于概要性数据方面的

神话2 维度模型与数据中心是针对部门而不是针对企业的解决方案

神话3 维度模型与数据中心是不可升级的

神话4 维度模型与数据中心仅当可预见的使用模式时才适合

神话5 维度模型与数据中心是不能集成的，从而只能形成直通的解决方案

数据仓库构建需要避免的常见疏误

疏误10 过多地将心思放在技术和数据上了，而不关注业务的要求和目标

疏误9 未能实现或者再现像数据仓库业务主管所具备的看起来有影响、易访问而又合乎情理的管理功能梦想而耿耿于怀

疏误8 扭住指定一个庞大的多年工程计划不放，而不是去追求一个更易处理的可能也是更急迫的可以进行迭代开发的方案

疏误7 将精力全部投入到构造规范化数据结构中去了，而在建造一个基于维度模型的可行的展示环节时，却已经用光了给定的投入

疏误6 把注意力放在后台的作业性能和容易开发上，而不是放在前台的查询性能与容易使用

疏误5 把展示环节中假定为可查询的数据做得过于复杂。喜欢一个显得更为复杂的展示的数据库设计人员必定要花费一年的时间向业务用户提供（使用）支持，所以应该去建立一个在突出简明性更为人们所欣赏的解决方案。

疏误4 在孤立应用的基础上建立维度模型，而没有考虑到采用共享的一致的维度将这些模型捆绑在一起的数据体系结构

疏误3 仅仅将总结性数据加入到展示环节的维度中

疏误2 把业务、业务需求与分析内容以及基本数据与支持技术等都看成是静态的

疏误1 忽视了数据仓库的成功直接系于用户的接受程度这样的认识。

设计维度模型的四步过程

1、选取要建模的业务处理过程

2、定义业务处理的粒度

3、选定用于每个事实表行的维度

4、确定用于形成每个事实表行的数字型事实

以零售为例：

第一步：选取业务处理

POS零售业务，什么促销条件下的什么日子里，在什么商店正在销售什么样的产品。

第二步：定义粒度

通过访问POS事务信息，粒度最好是原子性的，以便能够得出一个关于商场销售非常详细的概况。

例如，想弄清星期一相对于星期日在销售上的不同情况，是否值得为谷物一类的物品准备那么多不同大小的商标，想了解有多少购物者对优惠50%的洗发精促销活动特别感兴趣，想确定如果对一个竞争很激烈的饮用苏打产品进行了大力的促销宣传以后进行降价销售会造成什么样的影响。

第三步：选定维度

根据实例研究，可以确定的描述性维度有：日期、产品、商店与促销

第四步：确定事实

根据实例研究，可以确定的事实有：销售量、销售额、成本额、毛利润金额

细化维度表属性

日期维度表

日期维度表的每列由行所代表的特定日期进行定义。“星期”一列含有每天像“星期一”这样的名称内容，该列可用于创建比较“星期一”与“星期日”的业务的报表。日历表中“月”所在列的日编号从每个月的1开始取值，然后根据月份的情况取到28、29、30或者31，这一列对于每月的同一天进行比较的情况很有好处。按照类似的方式，可给出一年中每月的编号（1，……，12）。纪元表示法采用一种称为凯撒日编号（即从某纪元开始连续对日期进行计数）来有效地给出日编号。当然也可以在表中给出“星期”与“月份”的绝对编号列。所有这些整数都支持跨年度跨月份的简单数据运算。在生成报表时，常常要给出像“一月”这样的月份名称。此外，为报表给定一个“年月”（YYYY-MM）列标题也是很有用途的。同样，报表中很可能需要季度编号（Q1，……，Q4）或者诸如2001-Q4这样的年季度编号列。如果财政年度与日历表在周期上不一致，则可以为财政年度给出类似的列。

在“节假日”指示列中给出“节假日”或者“非节假日”这样的内容。要记住，维度表属性是做报表标记之用的，因此，简单地在“节假日”指示列中给出“Y”或者“N”是没有多大作用。关于这个问题，考虑以下要对某产品的节假日与非节假日的销售情况进行比较的报表应用就可以弄清楚。显然，列中给出“节假日”或者“非节假日”这样富有意义的值比一个“Y”或者“N”之类的编码，要有用得多。还要注意，不应该在报表生成器中执行将编码标记翻译成易理解的标记这种操作，而应该将翻译内容存放在数据库中，以便使各种用户不受其报表生成工具的限制而得到一致的翻译内容。