3.4 明确仓库的对象：主题和元数据
大多数商务数据都是多维的，所以采集和表示三维以上的数据不能完全借用业务数据库设计中的方法，必须有一种新的方法来表达多维数据。现阶段流行的有2种方法，一是面向对象方法，即把商务数据抽象为对象，再使用Rational Rose等对象建模工具来表达这些对象；另一种方法就是使用信息包图，这是一种简便且高效的方法，在项目中使用的普及率很高。
信息包图实际上是自上而下数据建模方法的一个很好的工具。自上而下的建模技术从用户的观点开始设计。用户的观点是通过与用户交流得到的，可以进一步明确用户的信息需求。自上而下的方法几乎考虑了所有的信息源，以及这些信息源影响商务活动的方式，它使得设计者可以围绕着一个通常的主题或商务领域进行信息包的开发。
下面就详述如何通过信息打包技术建立信息包图，从而确定数据仓库中的主题和元数据。
3.4.1 信息打包技术
1.信息打包技术的基本使用
信息打包法是一种自顶向下的设计方法，它从管理者的角度出发把焦点集中在企业的一个或几个主题上，着重分析主题所涉及数据的多维特性。此法具体分4个阶段：
（1）采用自顶向下的方法对商务数据的多维特性进行分析，用信息打包图表示维度和类别之间的传递和映射关系，建立概念模型。其中类别是按一定的标准对一个维度的分类划分，如产品可按颜色、质地、产地和销地等不同标准分类。
（2）对企业的大量的指标实体数据进行筛选，提取出可利用的中心指标。其中指标也称为关键性能指标和关键商务测量的值，是在维度空间衡量商务信息的一种方法。比如产品收入金额、原材料消耗、补充新雇员或设备运行时间等都可以叫做指标。
（3）在信息打包图的基础上构造星形图，对其中的详细类别实体进行分析，进一步扩展为雪花图，建立逻辑模型。
（4）在星形图和雪花图的基础上，根据所定义数据标准，通过对实体、键标、非键标、数据容量、更新频率和实体特征进行定义，完成物理数据模型的设计。
信息包图可以帮助用户完成以下工作：
● 定义某一商务中涉及的共同主题范围，例如：时间、顾客、地理位置和产品。
● 设计可以跟踪的、确定一个商务事件怎样被运行和完成的关键商务指标。
● 决定数据怎样被传递给数据仓库的用户。
● 确定用户怎样按层次聚合数据和移动数据。
● 决定在给定的用户分析或查询中实际包含了多少数据。
● 定义怎样访问数据，它的进入点是什么。用户想访问哪里，以及怎样引导进入信息包。
● 估计数据仓库大小。
● 确定一个数据仓库里数据的更新频率。
● 制定信息怎样被打包才能更好地提供给用户。
图3-24是一个空白的信息包图。注意信息包图上面的横线，这里要写上信息包的说明。可以有选择地填上概括说明和详细说明或者说明信息包图描述的是什么信息。而阴影部分就是代表在一定的维度和类别下的度量指标，这部分体现的就是数据分析的主要任务，在制作信息包图时需要和用户一起完成。
在以后对AdventureWorksDW数据仓库的分析中，主要是对Adventure Works Cycles公司的销售情况进行分析，根据前面对需求的分析，结合信息打包法的4个阶段，可以通过如下的方法建立信息包图。
图3-24 一个空白的信息包
（1）获取各个商务部门对商务数据的多维特性分析结果，确定影响销售的维度，这里可以提炼出日期、区域、产品、客户年龄和客户状况等5个维度。
（2）对每个维度进行分析，确定它与类别之间的传递和映射关系，如在AdventureWorks业务数据库中，日期有年、季度和月甚至更小的级别，而区域一般就分为国家、地区、城市和具体的商店。
（3）确定用户需要的指标体系，这里以销售情况作为事实依据确定相关的销售指标，如实际销售、计划销售、预测销售、计划偏差和预测偏差等。
有了以上的分析，就可以画出销售分析的信息包图，如图3-25所示，其他分析需求的信息包图可以用类似的方法表示。
图3-25 销售分析的信息包图
（4）这一步可以在信息打包图的基础上构造星形图，如图3-26所示。然后根据实际情况，把详细类别实体连接到星形图中就可以得到企业数据仓库的雪花模型。如在这里的AdventureWorks业务数据库中，已经通过表“ProductCategory”、“ProductSubcategory”和“Product”对产品进行了层次分类，把它们挂到图3-26的星形图中可以形成图3-27所示的雪花架构图。
图3-26 信息包图的基础上构造的星形图
图3-27 在星形图基础上构建的雪花架构图
注意，按照设计惯例，指标实体、维度实体和详细类别实体分别用矩形、菱形和六角形表示。
通过以上技术，实际上建立起了数据仓库的概念模型和逻辑模型。如图3-25所示的信息包图是在最终用户和技术人员共同完成的，通过它数据的构成便由客观世界转换到了主观世界。而图3-26则属于逻辑模型，因为它在信息包图的基础上将信息转换成了关系模型。对比最终数据仓库的架构（在3.2.2节有叙述）可知，这时离构建完整的数据仓库数据库已经很近了。
2.信息动态打包
信息打包图中涉及的维度及其对应的类别是事先固定的。这种将维度和类别固定所带来的最直接的问题是，所设计的数据仓库不仅对一些特定的查询分析操作的适应能力差，而且当查询或分析的要求发生变化时根本无法适应。解决该问题的方法是允许维度和类别进行自由改变，这就是信息动态打包的方法。
信息动态打包包括2方面的内容：与该指标分析对应的维度的动态组合及与维度关联的类别的动态组合。参考南京大学李雪梅等人的《一种基于信息动态打包的数据仓库的设计方法》一文，可以得到信息动态打包方法的7步大法。
（1）采用自顶向下的方法，通过与企业的领导和管理人员交谈挖掘出尽可能多的主题，然后根据这些主题找出对应的指标实体，进一步对每个指标实体采用基本信息打包法分析出其中包含的最明显的维度实体。
图3-28和图3-29分别是对销售分析和顾客人口统计分析得到的两个星形图，其中前者包括时间、地区和产品3个维度实体，后者包括时间、地区和顾客3个维度实体。
图3-28 从销售分析的星形图
图3-29 从顾客统计分析的星形图
（2）综合考虑所有的主题，采用指标实体矩阵对定义的信息包和维度实体进行统一和标准化处理。利用图3-30所示的统一实体矩阵来消除实体定义中的歧异和不一致，从而保证数据仓库中实体定义的一致性。矩阵中交叉点的‘X’表示相关。
图3-30 统一实体矩阵
（3）对于单个指标实体（信息包）找出所有的与该指标实体相关的但属于其他信息包的维度实体，再根据其与该信息包的相关程度进行排序，得到该指标实体的一个所有相关维度指标的一个有序集。需要特别指出的是，由于维度定义的相对性，当某些详细类别实体中的单个类别与指标实体的查询或分析密切相关时也可以将它作为单独的维度实体。如顾客细节实体中包括年龄组、性别、收入组、职业、教育和婚姻状况等，而其中年龄组、性别、收入组和职业与销售分析密切相关，故可以将它们分别作为销售的不同的维度实体。这样我们就可以得到与销售分析相关的维度实体集Dim销售={时期,地区,产品,年龄组,性别,收入组,职业}。这里我们定义前3者的相关度为1，其他维度实体的相关度为0.5。
（4）对于每个维度实体，进行类别划分，找出所有可行类别。然后对这些类别的划分条件根据其粒度从大到小进行排序，得到该维度实体的类别指标的一个有序集。
（5）创建指标实体的动态维。可以把维度实体分为2类，一类是指对该指标实体的分析必不可少的维度实体，称之为必需维；另一类则可以根据需要自由选择，称为可选维。如DIM销售集合中，时期、地区和产品是必需维，其余的则是可选维。
（6）创建与维度实体对应的动态类别实体。不同于维度实体，类别实体均设为可选的，类别实体可以根据具体情况自行确定。
（7）建立数据仓库中各个指标的概念模型（信息打包图）和逻辑模型（星形图或雪花图）。
信息动态打包的数据仓库设计方法采用了维度和类别动态重组技术，提供可以修改的数据存储方式，从而使所设计的数据仓库具有真正自适应的数据结构，较好地满足企业未来查询和分析的需要。
3.4.2 理解数据仓库中的主题
通过信息包图实际上确定了数据仓库的主题和大部分元数据。这一节先讲数据包图和主题的关系。
1.主题的概念
主题（Subject）是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。例如在前面信息包图使用的例子中，“销售分析”就是一个分析领域，因此这个数据仓库应用的主题就是“销售分析”。
面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。例如，一个生产企业的数据仓库所组织的主题可能有产品订货分析和货物发运分析等。而按应用来组织则可能为财务子系统、销售子系统、供应子系统、人力资源子系统和生产调度子系统。
主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。如在生产企业中，同样是材料供应，在操作型数据库系统中，人们所关心的是怎样更方便和更快捷地进行材料供应的业务处理；而在进行分析处理时，人们就应该关心材料的不同采购渠道和材料供应是否及时，以及材料质量状况等。
数据仓库面向在数据模型中已经定义好的公司的主要主题领域。典型的主题领域包括顾客、产品、订单和财务或是其他某项事务或活动。
2.主题域的获取
主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时，一般是一次先建立一个主题或企业全部主题中的一部分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。
比如，对于Adventure Works Cycle这种类型的公司管理层需要分析的主题一般包括供应商主题、商品主题、客户主题和仓库主题。其中商品主题的内容包括记录超市商品的采购情况、商品的销售情况和商品的存储情况；客户主题包括的内容可能有客户购买商品的情况；仓库主题包括仓库中商品的存储情况和仓库的管理情况等，如图3-31所示。
图3-31 根据业务情况确定的分析主题
确定主题边界实际上需要进一步理解业务关系，因此在确定整个分析主题后，还需要对这些主题进行初步的细化才便于获取每一个主题应该具有的边界。对于图3-31的4个主题及其在企业中的业务关系可以确定边界如图3-32所示。
图3-32 主题域的划分
3.确定主题的内容
主题虽然在信息包图中只占据标题的位置，但是却是信息打包方法中最重要的部分，当主题定义好之后，数据仓库中的逻辑模型也就基本成形了。此时，需要在主题的逻辑关系模式中包含所有的属性及与系统相关的行为。数据仓库中的数据存储结构也需要在逻辑模型的设计阶段完成定义，需要向里面增加所需要的信息和能充分代表主题的属性组。以Adventure Works Cycle这类公司数据仓库为例，如表3-7所示可以分别在“商品”、“销售”和“客户”主题上增加能够进一步说明主题的属性组。
表3-7 主题的详细描述
4.主题的使用
由于数据仓库的设计是一个螺旋发展的过程，在刚开始，没有必要在数据仓库的数据库中体现所有的主题，选择最重要的主题作为数据仓库设计的试金石是很有必要的。因此使用主题首先是找到需要分析的主题域。
例如在AdventureWorksDW数据仓库的概念模型设计中，在对需求进行分析后，认识到“商品”主题既是一个销售型企业最基本的业务对象，又是进行决策分析的最主要领域，因而把“销售分析”主题域定义为要首先建立的主题。通过“商品”主题的建立，经营者就可以对整个企业的经营状况有较全面的了解。先实施“商品”主题可以尽快地满足企业管理人员建立数据仓库的最初要求，所以先选定“商品”主题进行实施。
通过将主题边界的划分应用到已经得到的关系模型上还能形成原始的概念模型。这一模型是把主题域的划分和事务处理数据库中的表结合起来的模型，例如在上面的例子中，商品主题可能涵盖的关系表有商品表、供应关系表、购买关系表和仓储关系表；仓库主题可能涵盖的关系表有仓库关系表、仓库表、仓库管理关系表和管理员表。把这些表的键和字段联系起来，就可以形成如图3-33所示的原始概念模型图。
图3-33 划分了主题域的原始概念模型
3.4.3 理解数据仓库中的元数据
信息包图同样也包含了数据仓库中的大部分元数据。元数据最普通的定义是“关于数据的数据”。正是有了元数据，才使得数据仓库的最终用户可以随心所欲地使用数据仓库，利用数据仓库进行各种管理决策模式的探讨。元数据是数据仓库的应用灵魂，可以说没有元数据就没有数据仓库。
1.元数据的类型
通常把元数据分为技术元数据（Technical Metadata）和业务元数据（Business Metadata）。
技术元数据是描述关于数据仓库技术细节的数据，这些元数据应用于开发、管理和维护数据仓库，它主要包含以下信息。
● 数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；
● 业务系统、数据仓库和数据集市的体系结构和模式；
● 汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚合、汇总和预定义的查询与报告；
● 由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则及安全（用户授权和存取控制）。
业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法及公式和报表的信息。
在信息打包过程中，需要用包图表示维度和类别还有它们之间的传递和映射关系，实际上这个操作就是在原业务系统的基础上创建了元数据。其中的维度、类别还有层次关系是属于典型的技术型元数据，而业务系统中与之对应的术语则属于业务元数据。比如前面的例子中提炼出的日期、区域、产品、客户年龄和客户状况等维度，实际销售、计划销售、预测销售、计划偏差和预测偏差等指标皆属于元数据。这些数据在以后的分析中起到了极为重要的作用。下面将对这些作用进行归纳。
2.元数据的作用
从元数据的类型和作用来看，元数据实际上是要解决何人在何时、何地为了什么原因及怎样使用数据仓库的问题。再具体化一点，元数据在数据仓库管理员的眼中是数据仓库中的包含了所有内容和过程的完整知识库和文档，而在最终用户（即数据分析人员）眼中，元数据则是数据仓库的信息地图。
数据分析员为了能有效地使用数据仓库环境，往往需要元数据的帮助。尤其是在数据分析员进行信息分析处理时，他们首先需要去查看元数据。元数据还涉及到数据从操作型环境到数据仓库环境中的映射。当数据从操作型环境进入数据仓库环境时，数据要经历一系列重大的转变，包含了数据的转化、过滤、汇总和结构改变等过程。数据仓库的元数据要能够及时跟踪这些转变，当数据分析员需要就数据的变化从数据仓库环境追溯到操作型环境中时，就要利用元数据来追踪这种转变。另外，由于数据仓库中的数据会存在很长一段时间，其间数据仓库往往可能会改变数据的结构。随着时间的流逝来跟踪数据结构的变化，是元数据另一个常见的使用功能。
元数据描述了数据的结构、内容、链和索引等项内容。在传统的数据库中，元数据是对数据库中各个对象的描述，数据库中的数据字典就是一种元数据。在关系数据库中，这种描述就是对数据库、表、列、观点和其他对象的定义；但在数据仓库中，元数据定义了数据仓库中的许多对象——表、列、查询、商业规则及数据仓库内部的数据转移。元数据是数据仓库的重要构件，是数据仓库的指示图。元数据在数据源抽取、数据仓库开发、商务分析、数据仓库服务和数据求精与重构工程等过程都有重要的作用，在图3-34中可以看到元数据在整个数据仓库开发和应用过程中的巨大影响。因此，设计一个描述能力强并且内容完善的元数据，对数据仓库进行有效地开发和管理具有决定性意义。
图3-34 元数据及其影响域
元数据拥有的巨大作用的发挥会在后面对数据仓库的分析中逐步体会到。这一节实际上通过信息打包技术建立起了数据仓库的概念模型，通过信息包图得到的星形结构或雪花形结构实际上为数据仓库建立起了逻辑模型。可以说，通过对主题和元数据的分析，应该能够对从现实世界到主观世界的过程（即概念模型的构建）有深刻的认识，而对逻辑模型还需要从事实和维度的角度进一步研究。