SQL2000联机丛书：创建数据仓库
本次摘录 来源于
SQL2000联机丛书中 创建和使用数据仓库概述
为的是对数据仓库有个概观的认识
=============
创建数据仓库
=============
设计数据仓库 ->创建数据准备区->创建数据仓库数据库->从可操作系统中析取数据->
清理和转换数据->将数据装入数据仓库数据库->准备显示信息->将数据分发到数据集市
设计数据仓库
------------
必须将数据仓库数据组织起来以符合数据仓库的目的，即快速访问信息以进行分析和创建报表。
使用维度建模
实体关系建模通常用于为单位的所有进程创建一个复杂的模型。
这种方法已被证实在创建高效的联机事务处理 (OLTP) 系统方面很有效。
相反，维度建模针对零散的业务进程创建个别的模型。
例如，销售信息可以创建为一个模型，库存可以创建为另一个模型，
而客户帐户也可以创建为另一个模型。
每个模型捕获事实数据表中的事实，以及那些事实在链接到事实数据表的维度表中的特性。
由这些排列产生的架构称为星型架构或雪花型架构，已被证实在数据仓库设计中很有效。
维度建模将信息组织到结构中，这些结构通常对应于分析者希望对数据仓库数据使用的查询方法。
例如，问题
"What were the sales of food items in the northwest region in the third quarter of 1999?"
（1999 年第三季度西北地区的食品销售额是多少？）
表示使用三个维度（产品、地理、时间）指定要汇总的信息。
数据仓库模型
销售信息的简单维度模型可能包括一个名为 Sales_Fact 的事实数据表，
每个产品项的每个销售在该表中有一条记录，
该表还包含售出的数量、单位成本和销售额。
有关销售记录的各种信息可能包括客户、销售发生的商店、售出的时间和日期以及售出的产品。
这些信息中的每一类都可组织为自己的维度表。
客户信息放在 Customer 维度表中，商店信息放在 Store 维度表中，
时间和日期信息放在 Time 维度表中，产品信息放在 Product 维度表中。
在星型架构中，每个维度表都有一个由一个部分组成的主键，
该主键链接到事实数据表中由多个部分组成的主键的一个部分。
在雪花型架构中，一个或多个维度表分解为多个表，
每个表都有联接到主维度表而不是事实数据表的相关性维度表。
在大多数设计中，星型架构比雪花型架构更可取，
因为前者包含的用于信息检索的联接更少，并且更容易管理。
事实数据表
每个数据仓库或数据集市都包括一个或多个事实数据表。
星型架构或雪花型架构的中心是一个事实数据表，用以捕获衡量单位业务运作的数据。
事实数据表可能包含业务销售事件，如现金登记事务或非赢利组织的捐款和支出。
事实数据表通常包含大量的行，有时当事实数据表包含大型机构一年或几年的历史数据时，可能有数亿条记录。
事实数据表的主要特点是包含数字数据（事实），
而这些数字数据可以汇总以提供有关单位运作历史的信息。
每个事实数据表还包括一个由多个部分组成的索引，
该索引包含作为外键的相关性维度表的主键，而维度表包含事实记录的特性。
事实数据表不应包含描述性信息，
也不应包含数字度量字段以及使事实与维度表中的对应项相关的索引字段之外的任何数据。
包括在事实数据表中的最有用的度量值是累计的数字。
累计的度量值使可以通过添加各种度量值（如具体时间段内一组商店的特定项目的销售情况）获得汇总信息。
非累计度量值（如库存中现货的数量）也可用于事实数据表，但必须使用不同的汇总技术。
事实数据表中的聚合
聚合是通过详细记录计算汇总数据的过程。
在创建事实数据表时，可将数据聚合为汇总记录以减小事实数据表的大小，这通常是很诱人的。
但是，如果将数据汇总到事实数据表中，则分析者不再能直接使用详细信息。
如果需要详细信息，则必须标识并定位已汇总的详细信息行，详细信息行可能在提供数据的源系统中。
应在可能最细的粒度级别上维护事实数据表数据。
应在考虑了这些结果之后，再将数据聚合到事实数据表中。
将聚合数据和详细数据混合在事实数据表中，可能导致在使用数据仓库时出现问题和并发因素。
例如，销售订单通常包含多个产品项，而且可能包含折扣、税款或运输成本，
这些都算在订单总计中而不是个别的产品项中，而销售数量和产品项标识则记录在产品项级上。
在这种情况下，汇总查询变得更复杂，
Analysis Services 这类工具通常需要创建特殊的筛选器以处理粒度混合。
有两种方法可以处理这种情况。
一种方法是根据销售额、销售数量或发货量给产品项分配订单级的值。
另一种方法是创建两个事实数据表，一个包含产品项级的数据，另一个包含订单级信息。
详细信息事实数据表中应包含订单标识键，以便这两个表可以建立关系。
于是，订单表可以作为维度表用于详细信息表，并将订单级的值视为维度层次结构中订单级的特性。
聚合表
聚合表是包含事实数据表的汇总信息的表。
当 SQL 作为查询机制使用时，这些表可用于提高查询性能。
OLAP 技术（如 Microsoft SQL Server 2000 Analysis Services 所提供的 OLAP 技术）
消除了对这种表的需要。
Analysis Services 创建包含预聚合汇总的 OLAP 多维数据集，
这样，不论需要什么级别的汇总来回答查询，都可以快速回答查询。
当 Analysis Services 用于提供显示服务时，不必在数据仓库中创建聚合表。
Analysis Services 在必要时创建聚合，并将其存储在数据仓库数据库中的表内或内部多维结构中。
维度表
维度表包含描述事实数据表中的事实记录的特性。
有些特性提供描述性信息；
有些特性则用于指定如何汇总事实数据表数据以便为分析者提供有用的信息。
维度表包含帮助汇总数据的特性的层次结构。
例如，包含产品信息的维度通常包含将产品分为食品、饮料、非消耗品等若干类的层次结构，
这些产品类中的每一类进一步多次细分，直到各产品的 SKU 达到最低级别。
维度建模产生维度表，
在维度表中，每个表都包含独立于其它维度的事实特性。
例如，客户维度表包含有关客户的数据，产品维度表包含有关产品的信息，而商店维度表包含有关商店的信息。
查询使用维度中的特性来指定对事实信息的查看。
例如，查询可能使用产品、商店和时间维度来询问
"What was the cost of nonconsumable goods sold in the northeast region in 1999?"
（1999 年东北地区销售的非消耗品的成本是多少？）。
后面的查询可能在一个或多个维度上深化以检查更详细的数据，
如 "What was the cost of kitchen products in New York City in the third quarter of 1999?"
（1999 年第三季度纽约的厨房用品的成本是多少？）。
在这些示例中，维度表用于指定如何汇总事实数据表中的度量值（成本）。
维度表中的列可用于将信息分为不同的层次结构级。
例如，FoodMart 2000 示例数据库中的商店维度表包括下面指定层次结构级别的列。
列 描述
store_country 指定商店所在的国家。这是层次结构的国家级。
store_state 指定商店所在的省。这是层次结构的省级。
store_city 指定商店所在的城市。这是层次结构的城市级。
store_id 指定个别的商店。
这是层次结构的最低级别。该字段包含商店维度表的主键，并用于联接该维度表与事实数据表。
store_name 指定商店的名称。该列中的值用于以可读的形式向用户标识商店。
各种维度表
前面的示例说明了包含被分成常规级别的均衡层次结构的维度表。
其它类型的维度表包含不太均衡的信息，如局部划分的结构或组织图表，
这类结构中的层次结构由父子关系而不是级别数组表示。
代理键
维度表的主键保持稳定很重要。
强烈建议为所有维度表的主键创建代理键并使用它们。
代理键是在数据仓库内部维护的键，而不是从源数据系统中获得的键。
使用代理键有几个原因：
不同源系统中的数据表可能对同一实体使用不同的键。
提供历史数据的传统系统可能使用了与当前的联机事务处理系统不同的编号系统。
代理键唯一标识维度表中的每个实体，与源键无关。
可以使用单独的字段包含源系统中使用的键。
公司各分部独立开发的系统可能使用不同的键，或使用与其它分部系统中的数据冲突的键。
当每个分部独立地创建汇总数据报表时，这种情况不会产生问题，
但在合并数据的数据仓库中不允许这种情况。
键可以更改或在源数据系统中重新使用。
与其它情况相比，这种情况通常不大可能发生，但已知有些系统可以重新使用属于过时数据的键。
然而，键仍可以在数据仓库的历史数据中使用，而且同一个键不能标识不同的实体。
组织结构的更改可能移动层次结构中的键。
这可能是常见情况。
例如，如果销售员从一个地区调到另一个地区，
公司可能愿意跟踪两个事件：
销售员在调动日期前所在的原地区的销售数据，
和销售员在调用日期后所在的新地区的销售数据。
若要表示这种数据结构，销售员的记录必须存在于销售队伍维度表中的这两个位置，
而这在销售员的公司职员标识号用作维度表的主键时是不可能的。
代理键使同一销售员得以参与维度层次结构中的不同位置。
在这种情况下，销售员将在维度表中用两个不同的代理键表示两次。
这些代理键用于
将销售员的记录联接到与销售员在层次结构中所占用的不同位置相对应的事实数据集。
表中应包含一个单独的用于职员标识号的列，
这样，不论职员的记录在维度表中出现多少次，都可以复查或汇总有关职员的信息。
显示这类更改的维度称为更改慢的维度。
导致这类更改的另一个示例是创建产品的新版本，
如食品类的减肥产品版。
该产品将获得新的 SKU 或统一产品代码 (UPC)，
但可以保留仍在制造和销售的原产品的大多数相同特性。
适当使用代理键可使产品的两个版本一起汇总或单独汇总。
数据仓库负责实现和管理代理键。
OLTP 系统几乎不受这些情况的影响，而这些键的目的是准确跟踪数据仓库中的历史数据。
代理键是在数据转换过程中在数据准备区内进行维护。
引用完整性
必须在所有维度表和事实数据表之间维护引用完整性。
每个事实记录都包含与维度表中的主键相关的外键。
每个事实记录都必须在与事实数据表一起使用的每个维度表中有相关记录。
当维度表联接到事实数据表以响应查询或用于填充 OLAP 多维数据集时，
维度表中丢失的记录可以导致忽略事实。
如果在一个或多个维度表中丢失了记录，则查询可能返回不一致的结果。
查询若将有缺陷的维度表联接到事实数据表，则将排除事实，
反之，若不联接有缺陷的维度表则将包括那些事实。
共享维度
数据仓库必须为相似的查询提供一致的信息。
保持一致性的一种方法是创建由数据仓库中的所有组件和数据集市共享和使用的维度表。
可以作为共享维度的对象包括客户、时间、产品和地理等维度，如本主题前面介绍的示例中的商店维度。
例如，若要求所有 OLAP 多维数据集和数据集市使用相同的共享时间维度，则将使按时间汇总的结果保持一致。
索引
与在任何关系数据库中一样，索引对数据仓库的性能具有重要作用。
每个维度表都必须在主键上建立索引。
在其它列（如标识层次结构级别的列）上，索引对某些专用查询的性能也很有用。
事实数据表必须在由维度表外键构成的组合主键上建立索引。
创建数据准备区
--------------
为支持数据析取、清理和转换操作以便准备数据装入数据仓库，
需要创建表和其它数据库对象。
可以为数据准备区创建单独的数据库，或者可以在数据仓库数据库中创建这些项目。
数据准备区应包括包含传入数据的表、帮助实现代理键的表以及容纳转换数据的表。
可能需要其它表协调来自不同数据源的数据；
这些表可能包含标识常用实体（如来自使用不同键的系统的客户记录）的交叉引用信息。
可能还需要各种临时表执行中间转换。
准备装入数据仓库的数据所在的表与数据仓库中的目标表应具有相同的架构。
如果不是这样，则准备装入数据仓库表中的数据需经过转换，该转换在装载数据时可以单步完成。
无论是否使用单独的数据库，创建数据准备区
都包含创建表、视图、索引、DTS 包以及关系数据库中常用的其它元素。
创建数据仓库数据库
------------------
可以在设计数据仓库架构之后创建数据仓库数据库。
需要创建事实数据表和维度表，并在所有表中的主要字段上建立索引。
与 OLTP 数据库或数据准备区相比，数据仓库数据库的架构通常是很简单的。
星型架构由单个事实数据表和一些维度表组成。
雪花型架构增加了次要维度表。
更复杂的数据仓库可能包含多个事实数据表和许多维度表，
其中有些维度表由所有事实数据表共享，有些维度表则专用于单个事实数据表。
从可操作系统中析取数据
----------------------
将要用于数据仓库的数据必须从包含数据源的可操作系统中析取出来。
数据最初在数据仓库创建过程中析取，并且在更新数据仓库的过程中不断地定期析取。
如果源数据驻留在单个关系数据库中，则数据析取是简单的操作，
但如果源数据驻留在多个异类可操作系统中，则数据析取是非常复杂的操作。
数据析取过程的目的是使所有的源数据都具有通用的、一致的格式，以便准备装入数据仓库。
清理和转换数据
--------------
在从源系统析取数据的过程中可以完成很多数据转换。
但是，在将数据装入数据仓库前，经常还有其它任务需要完成。
例如，必须在析取后协调来自异类数据源的不一致的数据，并完成其它格式化和清理任务。
还应该一直等到析取过程合并代理键后。
某些在析取过程中可通过技术手段完成的转换可能会影响联机源系统的性能或操作；
应将这些任务推迟到析取完成后执行。
从源系统析取后，数据应驻留在数据准备区，在这里可以在数据装入数据仓库前完成清理和转换。
数据准备区可以是数据仓库数据库中单独的数据库或单独的表。
在清理和转换阶段，可以执行过程以验证数据的一致性，将数据转换成常用格式以及合并代理键。
可能需要执行手工操作协调数据的不一致或解决二义性文本字段输入项。
每次需要手工操作时，都应试着确定一种方法来消除在以后的数据转换操作中的手工步骤。
在某些情况下，也许能够修改源数据系统以消除源上的起因。
在某些情况下，也许能够建立自动化进程将未解决的数据留待以后手工异常处理，
这样，大批的数据就可以装入数据仓库而不会因手工干预而耽搁。
将数据装入数据仓库数据库
------------------------
清理数据并将其转换成与数据仓库要求一致的结构后，数据即准备装入数据仓库。
在装载操作中可以进行一些最后的转换，但应在最后的装载操作前完成所有可能标识不一致的转换。
将数据装入数据仓库时，就是在填充将由显示应用程序使用的表，该应用程序使数据可由用户使用。
装载数据通常涉及从源可操作系统、数据准备区数据库或数据仓库数据库中的准备区表传输大量的数据。
这样的操作会显著增加所涉及的数据库的处理负荷，因此应该在系统相对不忙时完成。
数据装入数据仓库数据库后，验证维度和事实数据表之间的引用完整性，
确保所有的记录都与其它表中的适当记录相关。
准备显示信息
------------
因为通常通过客户端应用程序提供对数据仓库数据的访问，
所以经常必须在数据仓库中完成某些任务以便为最终用户准备显示信息。
将数据分发到数据集市
--------------------
数据仓库设计可能包括用于特定业务方面（如销售、仓库和财务部门）的数据集市。
每个上述数据集市都包含一个数据仓库数据的子集，
但应使用公用共享维度以避免分析和生成报表时出现不一致。
从数据仓库中初始装载数据集市时，复制所有适用的共享维度表和适合于数据集市的事实数据表。
如果将某个数据集市特有的特殊维度表只用于该数据集市所服务的部门或组，
则可以在本地创建这些维度表；
用于创建报表从而与来自其它数据集市的报表进行比较的维度应是共享维度，
共享维度在数据仓库中集中进行管理并从数据仓库表中装载。
可以使用很多或所有用于装载数据仓库数据库的工具来装载数据集市。
posted on 2006-11-28 17:43 freeliver54 阅读(933) 评论(2) 编辑 收藏 举报
