数据仓库

下载
技术词汇
access (访问或存取 )— 在存储单元上查找、读或写数据的操作。
access method (访问方法或存取方法 )— 用于将物理记录从大容量存储设备传入或传出
的技术。
access pattern (访问模式或存取模式 )— 访问数据结构的一般序列(例如，从元组到元组，
从记录到记录，从段到段等等)。
accuracy (精确度)— 一种对避免误差的定性估计，或对误差大小的定量度量，表示为一
个相对误差的函数。
ad hoc processing (特别处理) — 仅执行一次，偶尔访问，并且用从未用过的参数操纵数
据，通常以启发式的迭代的方式进行。
after image (后映像)— 当完成一个事务后，放入日志的数据快照。
agent of change (变化动因)— 大得不能抗拒的驱动力，通常是系统的老化、技术的变化、
需求的根本改变等等。
algorithm (算法) — 组织好用以在有限步骤内解决问题的一系列语句。
analytical processing (分析型处理 ) — 使用计算机为管理决策提供分析，通常包括趋势分
析、向下探查分析、统计分析及概要分析等等。
application (应用)— 支持一个组织或企业需求的一组相互联系的算法和数据。
application database (应用数据库 )— 组织好用以支持一种特定应用的数据集合。
archival database (存档数据库 )— 包含具有历史特性的数据的数据集合。一般来说，存
档数据是不被更新的。每个存档数据单元都和一个过去的时间点有关。
artifact (人工关系)— 在DSS环境中用于表示参照完整性的一种设计技术。
atomic (原子)— (1)存储在数据仓库中的数据；( 2)处理分析的最低层次。
atomic database (原子数据库 )— 由原始的原子数据组成的数据库；一个数据仓库；一个
DSS基础数据库。
atomic-level data (原子层数据 )— 具有最低粒度级的数据。原子层数据存放在数据仓库
中并随时间变化(即精确到过去某一时刻)。
attribute (属性)— 可以对实体或关系取值的特性。实体可以被赋予多个属性(例如，一
个关系中的元组由多个值组成)。一些系统也同样容许关系具有属性。
audit trail (审计跟踪)— 可用于跟踪活动的数据，这些活动通常是更新活动。
backup (备份)— 作为数据库备份活动的基础的一个文件。通常是以前某一时刻的数据
库的快照。
batch (批处理 ) — 多个程序(通常是长时间运行的、面向顺序的)互斥地访问数据的计算
机运作方式，当活动正在进行时不容许用户干预。
batch environment (批处理环境 )— 一种顺序控制的处理模式；在批处理中，收集并存储
输入，而后进行处理。一旦收集好，批处理输入将顺序地对一个或多个数据库进行处理。
216 数据仓库
下载
before image (前映像)— 更新前的记录快照，通常放在活动日志中。
bitmap (位映射 )— 用于显示一组块或记录存在与否的特殊索引形式。建立和维护位映
射是非常昂贵的，但它能提供快速比较和访问的手段。
blocking (组块)— 合并两个或多个物理记录，使它们的物理位置在一起。物理位置相连
的结果是可以通过执行单个机器指令来访问和获取它们。
cache (高速缓存 )— 通常在设备级上建立和维护的缓冲区。从高速缓存中检索数据要比
从磁盘柱面检索快得多。
cardinality(of a relation) (关系的基数) — 在一个关系中元组(即行)的数目。
CASE — 计算机辅助软件工程( computer-aided software engineering)。
checkpoint (检查点)— 数据库的一个标识的快照，或使事务对数据库冻结或停顿的一个
点。
checkpoint/restart (检查点 /重启动 )— 在程序起始点以外的地方重新运行程序的一种方
法，例如，当发生故障或中断时。在整个应用程序运行中，可能会使用 N个检验点。在每一个
检查点要存储足够的信息，以便程序能够恢复到检查点设定时的状态。
“C L D S” — 以幽默方式对分析型的 D S S系统的系统开发生命周期的命名。我们之所以
这样命名是因为它实际上是经典的系统开发生命周期 SDLC(System Development Life Cycle)
的逆序写法。
COBOL— 面向商业的通用语言( Common Business Oriented Language)，商业界的一种
计算机语言。一种非常通用的语言。
column (列)— 从同一域中选择值的一个纵向表。一行可以由一个或多个列组成。
commonality of data (数据通用性 )— 出现在不同应用或系统中的相同或相似的数据。数
据通用性的识别与管理是数据库概念设计和物理设计的基础之一。
compaction (压缩) — 一种用于减少数据表示的位数而不丢失数据内容的技术。采用压
缩技术，使重复的数据可非常简明地表示。
condensation (紧缩)— 减少管理数据量而不降低数据逻辑相容性的过程。紧缩与压缩有
本质上的区别。
contention (争用)— 当两个或多个程序试图同时访问同一个数据时出现的情况。
continuous time span data(连续时间跨度数据) — 一种数据的组织形式，使得在一个时间
跨度上，连续的数据定义由一个或多个记录表示。
CPU— 中央处理机( central processing unit)。
CPU-bound (CPU-界限)— 计算机不能产生更多输出的处理状态，因为处理器的 C P U部
分被100%地使用。当计算机达到 CPU－界限时，存储处理部件通常没有被 100%地使用。使用
现代的DBMS，计算机更可能出现 I/O-界限，而不是CPU-界限。
current value data (当前值数据 )— 与随时间变化的数据相反，在执行时准确度有效的数
据。
DASD — 参见“直接存取存储设备”。
data (数据)— 在存储介质上记录的事实、概念或指令，用于通信、检索，用自动方式处
理，并表示为人可以理解的信息。
D A，data administrator (数据管理员( D A)) — 负责数据管理软件的说明、获取和维护，
下载
技术词汇 217
以及负责文件或数据库的设计、验证和安全性的个人或组织。数据模型和数据字典通常是 D A
负责的。
database (数据库 ) — 按照一种模式存储相互关联的数据集合(通常是受控的、限制冗余
的)。一个数据库能够服务于一个或多个应用。
DBA，database administrator (数据库管理员( DBA))— 负责每天监控和管理数据库的组
织职能。DBA比DA职能与物理数据库设计的关系更密切。
database key (数据库键码 ) — 数据库中每个记录存在的一个唯一值。这个值经常是被索
引的，虽然它是可以作随机处理或散列的处理。
DBMS，database management system (数据库管理系统 )— 一个基于计算机的软件系统，
用于建立和管理数据。
data-driven development (数据－驱动开发 )— 以识别数据通用性为中心的开发方法，它
是通过一个数据模型和建立比直接应用更广泛范围的程序来实现的。数据－驱动开发不同于
传统的面向应用开发。
data element (数据元) — (1)实体的一个属性；( 2)一个唯一命名和很好定义的数据类别，
由数据项组成并包括在一个活动记录中。
D I S，data item set (数据项集合 ) — 一组数据项，每个数据项直接与数据项所属数据组
的键码有关。数据项设置可以在中间层模型中见到。
data model (数据模型)— (1)逻辑数据结构，包括由 DBMS为有效进行数据库处理提供的
操作和约束；( 2)用于表示数据的系统(例如， ERD或关系型模型)。
data structure ( 数据结构 ) — 数据元之间的逻辑关系，设计用来支持特定数据处理功能
(树、列表和表)。
data warehouse (数据仓库) — 用来支持DSS功能的、集成的、面向主题的数据库的集合，
每个数据单元与某个时刻有关。数据仓库包括原子数据和轻度汇总数据。
DSS，decision support system (决策支持系统) — 一个用于支持管理决策的系统。通常，
DSS涉及以启发式方式进行的许多数据单元的分析。一般， DSS处理不涉及数据更新。
decompaction (解压缩)— 压缩的反过程；一旦数据以压缩的形式存储，必须进行解压缩
才能使用。
denormalization (反规范化)— 将规范化数据放在物理地址中以优化系统性能的技术。
derived data (导出数据)— 依赖于企业的一个主要主题的两个或多个取值的数据。
derived data element (导出数据元)— 无须存储但需要时就能产生的数据元(年龄、当前
日期、出生日期)。
design review (设计评审 ) — 在编码之前对系统的所有方面进行公开评审的质量保证过
程。
direct access (直接存取) — 通过直接引用数据的卷地址来检索和存储数据的机制。这种
机制与存取数据直接相关，因为它通常需要联机使用数据。也称为随机存取或散列存取。
DASD，direct access storage device (直接存取存储设备 )— 一种数据存储设备，其上的
数据能够被直接存取，而不需要通过一个如磁带文件的顺序文件。磁盘是一种直接存取存储
设备。
download (下载) — 根据在一个数据库中发现的数据内容，向另一个数据库卸出数据的
218 数据仓库
下载
过程。
drill-down analysis (向下探查分析 )— 一种分析形式，其中对总数的检查导致对总数的
分量的探测。
dual database (双重数据库 ) — 从决策支持数据中分离高性能的、面向事务的数据的实
践。
dual database management systems (双重数据库管理系统 )— 用多个数据库管理系统来控
制数据库环境不同方面的实践。
dumb terminal (哑终端) — 在所有处理于远程计算机上进行的地方，用于与最终用户直
接交互的装置。哑终端只作为搜集数据和显示数据的装置。
EIS，Executive Information Systems(高级管理人员信息系统) — 为高级管理人员设计的
系统，主要用于向下探察分析和趋势分析。
encoding (编码)— 数据值物理表示的缩写或简写(例如，男 =“M”，女=“F”)。
entity (实体)— 在最高抽象层上数据模型设计人员所感兴趣的人物、地点或事物。
ERD，entity-relationship diagram (实体－关系图) — 一种高级数据模型，以图式表示在
集成范围内的所有实体以及实体之间的直接关系。
event (事件)— 一个重要活动发生的信号。事件是由信息系统解释的。
external data (外部数据)— (1)来源于企业操作型系统之外的数据；( 2)驻留在中央处理系
统之外的数据。
extract (抽取)— 从一个环境中选择数据并将它传送到另一个环境的过程。
flat file (平面文件)— 不包含数据聚集、嵌套的重复数据项或数据项组的记录集合。
foreign key (外键)— 一种属性，它不是一个关系系统中的主键，但它的值是另一个关系
的主键的值。
fourth-generation language (第四代语言) — 设计用来允许最终用户随意访问数据的语言
或技术。
functional decomposition (功能分解)— 将操作划分成构成过程基础的层次功能(活动)。
granularity (粒度) — 包含在数据单元中的细节级别。越细节的数据，粒度级越低。越综
合的数据，粒度级越高。
heuristic (启发式)— 下一步骤由当前步骤的分析结果所决定的分析模式。用于决策支持
处理。
image copy ( 映像复制 )— 为达到备份的目的，将数据库从物理上拷贝到另一介质的过
程。
index (索引) — 当一个记录的索引键项已知时，维护的记录存储结构部分，用来对记录
提供有效访问的。
information (信息)— 人们为了求解问题或作出决策而吸收和评价的数据。
integrity (完整性)— 确保数据库中包含的数据尽可能地准确和一致的数据库性质。
interactive (交互的 ) — 将联机事务处理和批处理的一些特征结合起来的一种处理模式。
在交互式处理中，最终用户与他或她单独控制的数据进行交互。另外，最终用户可以启动处
理数据的后台进程。
“is a type of ” (“定义类型” ) — 在概念数据库设计(例如，“cocker spaniel ”是一种
下载
技术词汇 219
“dog”类型)过程中对数据进行抽象的一种分析工具。
iterative analysis ( 迭代分析 ) — 下一步处理依赖于当前执行步骤所获得结果的处理模
式；启发式处理。
JAD，joint application design (联合应用设计) — 创建和细化应用系统需求的人(通常是
最终用户)组成的一个组织。
judgment sample (判断样本 )— 一个数据样本，其中数据由于基于一个或多个参数的样
本而被接受或拒绝。
key ( 键码)— 用于识别或定位记录实例(或其他类似的数据组)的数据项或数据项的组合。
key，primary (主键)— 在数据库中用于识别单个记录的唯一属性。
key，secondary (辅键)— 在数据库中用于识别一类记录的非唯一属性。
living sample (活样本)— 一个代表性的数据库，它通常代替大型数据库以用于启发式的、
统计的、分析的处理。从超大型数据库定期地、有选择地提取数据，这样产生的活样本数据
库代表超大型数据库在某一时刻的一个断面。
load (装载)— 将数据值插入原先为空的数据库。
log ( 日志)— 有关活动的日记。
logging (记日志)— 自动记录与数据访问、数据更新等有关的数据。
loss of identity (特征丢失 )— 当数据是从外部数据源装入，以及外部数据源的特征丢失
时，便发生特征丢失。常见的情况是用微处理器数据。
magnetic tape (磁带) — (1)与顺序处理紧密相关的存储介质；( 2)存储和检索图象的大容
量磁性带子。
master file (主文件)— 为给定的数据集(通常是由应用限定范围)保持记录系统的文件。
metadata (元数据 )— (1)关于数据的数据；( 2)对数据的结构、内容、键码、索引等等的
描述。
microprocessor (微处理机)— 满足单个用户需要的小型处理机。
migration (迁移)— 将经常使用的数据项移到比较容易访问的存储区域，以及将不常使
用的数据项移到比较难访问的区域的过程。
m i p s(million instructions per second，每秒百万指令) — 为小型计算机和大型计算机设
定的处理器速度的标准度量单位。
online storage (联机存储器 ) — 数据能以直接的方式访问的存储装置和存储介质。
operational data (操作型数据 ) — 用于支持公司日常业务处理的数据。
operations (操作部门)— 负责运行计算机的部门。
optical disk (光盘)—与磁性装置相对的一种使用激光的存储介质。光盘通常只写，单位
字节的费用比磁性存储设备要便宜，并且可靠性高。
overflow (溢出，溢出区)—(1)记录或数据段因为其地址已被占用而不能存储于其驻留地
址的情况。在这种情况下数据被放在另外地方，这种地方称为溢出区；( 2)D A S D的区域，当
溢出情况发生时，数据被送往该区域。
ownership (所有权)— 更新操作型数据的责任。
page (页面) — (1)在DASD之上的基本数据单元；( 2)主存储器中的基本存储单元。
parameter (参数)— 作为数据限定条件使用的基本数据值，通常用在数据搜索或模块控
220 数据仓库
下载
制中。
partition (分割)— 将数据分成不同物理单元的一种分割技术。分割可以在应用层或系统
层上进行。
populate (载入)— 在原先空的数据库中放置数据的具体值。
primary key (主键)— 一个属性，其中包含的值唯一地确定具有该键的记录。
primitive data (原始数据)— 数据的存在依赖于企业主要主题领域的唯一一次出现。
processor (处理机 )— 处于计算机程序执行的中心位置的硬件。一般来说，处理机分成
三种：大型机、小型机和微机。
processor cycles (处理机周期 ) — 驱动计算机(例如：启动 I/O，执行逻辑运算、移动数据、
算术运算)的硬件的内部周期。
production environment (生产环境)— 运行操作型的、高性能的处理过程的环境。
punched cards (穿孔卡)— 存储数据和输入的早期存储介质。现在穿孔卡已很少见了。
query language (查询语言 ) — 能够让最终用户与 D B M S直接交互的语言，用以检索并可
能修改DBMS下存储的数据。
record (记录)— 用数据与公共键码的关系组织的数据值的集合。
record-at-a-time processing(每次一个记录的处理方法) — 一次一个记录、一次一个元组
的数据存取方法。
recovery (恢复)— 将数据库复原到初始位置或状态，经常是在物理介质发生较大的破坏
之后进行的。
redundancy (冗余) — 存储数据不止一次出现的设计。当数据可以更新时，冗余会带来
严重的问题。当数据不被更新时，冗余经常是一种有价值的必要的设计技术。
referential integrity (参照完整性 )— 确保预定义关系有效性的一种 DBMS功能。
r e o rganization (重组织 ) — 在差的组织状态下卸载数据，然后在好的组织状态下再装入
这些数据的过程。在一些 D B M S 中，重组织用于重新构造数据的结构。重组织经常称为
“reorg”或“卸载 /再装入”过程。
repeating groups (重复组)— 在一个给定记录取值中，能出现好几次的数据集合。
rolling summary (轮转综合 ) — 一种档案数据存储形式，越新的数据具有细节越多的存
储，越旧的数据具有细节越少的存储。
scope of integration (集成范围)— 对建模系统边界的形式定义。
SDLC，system development life cycle (系统开发生命周期 )— 传统的操作型系统开发生
命周期，通常包括收集需求、分析、设计、编程、调试、集成和实施。
sequential file (顺序文件 )— 其记录根据一个或多个键码字段的值进行排序的文件。这
些记录能够以这个顺序从文件的第一个记录开始处理，直到文件的最后一个记录。
serial file (串行文件)— 一种顺序文件，其中按顺序的记录在物理上是相邻的。
“set-at-a-time processing” (“成组处理”)— 成组访问数据，组的每个成员满足一个选
择的标准。
snapshot (快照)— 数据库转储或在一些时候将数据存档在数据库以外。
solutions database (解决方案数据库 )— DSS环境的一个存储先前决策结果的部件。解决
方案数据库用于在进行当前决策时帮助确定行动的适当过程。
下载
技术词汇 221
storage hierarchy (存储器层次结构 ) — 连接起来形成存储子系统的存储单元，其中一些
单元较快但小而昂贵，其他一些单元较慢但大而便宜。
subject database (主题数据库 )— 围绕企业主要主题进行组织的数据库。传统的主题数据
库是针对顾客、事务、生产、零件和供应商的。
system log ( 系统日志 )— 与系统事件有关的审计追踪的记载(例如事务登录、数据库变
化等等)。
system of record (记录系统)— 操作型数据的定义性的和单一的数据源。假如数据元 abc
在某个数据库记录中的值为 2 5，但在记录系统中的值为 4 5，按数据源定义第一个值是不正确
的，并且必须改成一致的。记录系统对管理数据冗余是很有用的。
table (表)— 由一组具有标题的列和一组行(即元组)组成的关系。
time stamping (标时戳 ) — 将每条记录标上某个时刻的操作，通常是记录创建时间或者
是记录从一个环境传递到另一个环境中的时间。
time variant data (随时间变化数据 )— 其准确度与一些时刻有关的数据。随时间变化的
数据的三种形式是连续时间跨度数据、事件离散数据和周期性离散数据。请参看“当前值数
据”。
transition data (转换数据 )— 既具有原始特征又具有导出特征的数据；通常对商业的运
作非常敏感。典型的转换数据是银行的利率，保险公司的保险率，厂商 /销售商的零售率等
等。
trend analysis (趋势分析)— 在时间序列上寻找同类数据的过程。请参看“ EIS”。
true archival data (真实档案数据) — 原子数据库中最低级的数据，通常存储在大容量存
储介质上。
update (更新)— 对存储在数据库中的全部或所选择出的项目、组或属性的值进行修改、
增加、删除或替换。
user (用户)— 发送命令和消息给信息系统的人或过程。
下载
下载
参考文献
Boehm, B. Software Engineering Economics, Prentice-Hall, Englewood Cliffs, NJ, 1981.
Brooks, F. P., Jr. The Mythical Manmonth: Essays on Software Engineering , Addison-
Wesley, Reading, MA, 1974.
Chen, P. P. “The Entity Relationship Model — Toward a Unified View Of Data, ” i n
Transactions on Database Systems, Vol. 1, No. 1, March 1976.
— . The Entity Relationship Approach to Logical Database Design, QED Info Sciences,
Wellesley, MA, 1977.
Date, C. J. An Introduction to Database Systems, Addison-Wesley, Reading, MA, 1975.
Davis, A. M. “Automating the Requirements Phase: Benefits to Later Phases of Software
Life Cycle, ” in COMPSAC 80, Proceedings IEEE , Computer Society, Los Alamitos, CA,
October 1980.
Davis, G. B., and M. H. Olson. Developing a Long-Range Information Systems Plan in
Management Information Systems, McGraw Hill, New York, 1985.
DeMarcro, T. Structured Analysis and Systems Specification, Yourdon Press, New Yo r k ,
1978.
Digital Equipment Corporation manual, Information Systems Technical Strategy and
Architecture, DEC, Marlboro, MA, June 1989.
Gane, C., and T. Sarson. S t ru c t u red Systems Analysis: Tools and Techniques, Prentice-Hall,
Englewood Cliffs, NJ, 1979.
Inmon, W. H. Information Engineering for the Practitioner, Yourdon Press, New York, 1988.
— . Using DB2 for Decision Support Systems, QED, Wellesley, MA, 1989.
— . Using Oracle for Decision Support Systems, QED, Wellesley, MA, 1989.
— . T h i rd Wave Processing: Data Base Machines and Decision Support Systems, QED,
— . Understanding Data Pattern Processing,QED, Wellesley, MA, 1991 (with S. Osterfelt).
— . Using Rdb for Decision Support Systems, QED, Wellesley, MA, 1992.
— . Practical Information Engineering, QED, Wellesley, MA, 1992.
— . Building the Data Warehouse, John Wiley & Sons, Inc, New York, 1993.
— . Information Systems Architecture: Development in the 90’s, John Wiley & Sons, Inc.,
New York, 1993.
— . Rab/VMS: Developing the Data Warehouse, John Wiley & Sons, Inc., New York, 1993.
— . Using the Data Warehouse, John Wiley & Sons, Inc., New York, 1994.
— . Building the Operational Data Store, John Wiley & Sons, Inc., New York, 1995.
Jackson, M. A. Principles of Program Design, Academic Press, New York, 1975.
下载
参考文献 223
Karimi, J. “Computer Aided Process Organization in Software Design,” Dept. of MIS,
University of Arizona, 1983.
Kelly, Sean. Data Warehousing—The Key to Mass Customization, John Wiley & Sons, Inc.,
New York, 1994.
Kerr, M. J. The IRM Imperative, John Wiley & Sons, Inc., New York, 1990.
Konsynski, B. R., and R. J. Nunamaker. Decision Support in Enterprise Analysis, Plenum
Publishing, New York, 1984.
Loper, M., and W. H. Inmon. “A Unified Data Architecture for Systems Integration,”ISEC
Conference, Washington, DC(Feb).
Love, Bruce. Enterprise Information Technologies, New York.
Martin, J. Strategic Data Planning Methodologies, Prentice-Hall, Englewood Cliffs, NJ,
1982.
Martin, J., and C. Finklestein. Information Engineering , Savant Institute, Cornforth,
Lancashire, England, 1981.
Meyer, D., and M. Boone. The Information Edge, Dow Jones Irwin, Homewood, IL, 1988.
Orr, K. T. Structured Systems Development, Yourdon Press, New York, 1977.
P a r k e r, M., R. Benson, and E. T r a i n o r. Information Economics: Linking Business
Performance to Information Technology, Prentice-Hall, Englewood Cliffs, NJ, 1989.
Parsaye, K., and M. Chignell. Intelligent Database Tools & Applications , John Wiley &
Sons, Inc., New York, 1995.
Perkinson, R. Data Analysis: The Key to Database Design, QED, Wellesley, MA, 1984.
Rousopolous, N. “The Logical Access Path Schema of a Database Design ”, A C M
Transactions in Software Engineering, Vol. SE-8, No. 6, November 1982.
Smith, J. M., and D. C. P. Smith. “Database Abstraction Aggregation,”Communications of
the ACM, Vol. 20, No. 6, June 1977.
— . “Conceptual Database Design, ”INFOTECH, State of the Art Report on Database
Design, June 1978.
Teichrow, D., and E. A. Hershey. “PSL/PSA: A Computer Aided Technique for Structured
Documentation and Analysis of Information Processing Systems, ”in IEEE Transactions on
Software Engineering, Vol. SE-3, No. 1, 1977.
Tschritzis,D.C.,and F. H. Lochovsky.Data Models,Pre n t i c e - H a l l, Englewood Cliffs, NJ,
1981.
Yourdon, E. Techniques of Program Structure and Design, Prentice-Hall, Englewood Cliffs,
NJ, 1975.
Zachman, J. “A Framework for information Systems Architecture, ”IBM Systems Journal,
Vol. 26, No. 3, White Plains, New York, 1986.
感兴趣的论文
Ashbrook, J. “Information Preservation”(从管理层的角度来看数据仓库 ), CIO Magazine,

224 数据仓库
下载
July 1993.
Data Managemant Review. “C h a rgeBack In the Information Wa r e h o u s e”(数据仓库中的
chargeback既可以是福音也可能是祸根，本文强调了这种问题的两个方面 )，March 1993.
Database Programming Design. “Now Which is Data, Which is Information”(数据和信息
之间的区别 )，May 1993.
Devlin, B. A., and P. T. Murphy. “An Architecture for a Business and Information Systems”
(首次提及IBM环境中的信息仓库 ), IBM Systems Journal, Vol. 27, No. 1, 1988.
Discount Store News。 “Retail Technology Charges Up at KMart” （KMart为他们的ODS
环境中的数据仓库所采用的技术进行描述 ), Feb. 17, 1992.
G e i g e r, J. “Information Management for Competitive Advantage ”(有关数据仓库和
Zachman结构的最新技术的讨论 ), Strategic Systems Journal, ACR, June 1993.
Gilbreath, R. MD. “Health Care Data Repositories: Components and a Model” (有关信息
体系结构及其与医疗保健结合起来的一个很好的描述 ), Journal of the Healthcare Information
and Management Systems Society, Vol. 9, No. 1, Spring 1995.
— . “Informational Processing Architecture for Outcomes Management ”(有关数据仓库
应用于医疗保健和疗效分析的描述 ; 审稿中 — 214-682-0113).
G o l d b e rg, P., Lambert, R. and Powell, K. “Guidelines for Defining Requirements for
Decision Support Systems”（很好地讲述了有关如何在建立数据仓库以前定义最终用户需求） ,
Data Resource Management Journal, Spring 1991.
Hufford, D. “Data Administration Support for Bussiness Process Improvement”(数据仓库
和数据管理 ), AMS.
Inmon, W. H. IBM Systems Journal. “An Architecture for a Business and Information
System” (讲述有关IBM对数据仓库的理解 ), vol 17, no. 1, 1988.
— . “A Conceptual Model for Documenting Data Synchronization Requirements” (数据
同步和数据仓库 ), AMS.
— . “At the heart of the Matter”(原始数据和导出数据以及它们之间的区别 ), Data Base
Programming /Design, June 1990.
— . “Going Against the Grain” (讲述有关粒度问题及其与数据仓库的关系描述 ), Data
Base Programming/Design, July 1990.
— . “The Atomic Database ” (有关分割式数据库环境是数据库发展方向的预测 ),
Enterprise Systems Journal, Nov. 1990.
— . “The Cabinet Effect”(讲述为什么数据仓库为中心的体系结构不能退化为蜘蛛网式
环境), Data Base Programming/Design, May 1991.
— . “A Tale of Two Cycles”(操作型环境和数据仓库以及决策支持环境的开发生命周期
是截然不同的。本文讨论它们的区别 ), Data Base Programming/Design, Dec. 1991.
— . “Data Structures in the Information Warehouse”(有关数据仓库中公用数据结构的确
定), Enterprise Systems Journal, Jan. 1992.
— . “Winds of Change”(数据管理和数据仓库 — 有关数据管理是如何发展到今天这
种状况的描述), Data Base Programming/Design, Jan. 1992.
下载
参考文献 225
—. “Data Warehouse — A Perspective of Data Over Time”(描述有关数据仓库和数据的
管理在时间上的关系 ), 370/390 Data Base Management, Feb. 1992.
— . “ Building the D a t a B r i d g e ” ( 成功建立数据仓库的关键因素 ), Data Base
Programming/Design, April 1992.
—. “Metadata: A Checkered Past, A Bright Future”(有关元数据及其与数据仓库关系的
讨论), 370/390 Data Base Management, July 1992.
— . “The Need for Reporting ”(讲述在体系结构的不同部件中找到不同种类的报表 ) ,
Data Base Programming/Design, July 1992.
— . “ Neat L i t t l e P a c k a g e s ” (讲述在数据仓库如何看待数据关系 ), Data Base
Programming/Design, Aug. 1992.
— . “E I S a n d t h e D a t a W a r e h o u s e”（E I S和数据仓库之间的关系） , D a t a B a s e
Programming/Design, Nov. 1992.
— . “Untangling the We b”(探索将数据变为信息的原因 ), Data Base Programming
Design, May 1993.
— . “The Structure of the Data Wa r e h o u s e”(强调数据仓库中所具有的不同数据层次 ) ,
Data Management Review, Aug. 1993.
—. “Data Warehouse Lays Foundation for Bringing Data Investment Forward”(有关数
据仓库以及它与历史系统间关系的描述 ), Application Development Trends, Jan. 1994.
— . “The Data Warehouse — All Your Data at Your Fingertips ” (数据仓库的综述 ) ,
Communications Week, Aug. 29, 1994.
—. “The Data Warehouse: Managing the Infrastructure” (讲述有关数据仓库的低层结构
以及与之相关的预算 ), Data Management Review, Dec. 1994.
— . “EIS and Detail”(讲述有关支持EIS所需细节数据的多少以及数据仓库环境中综合
数据所起的作用 ), Data Management Review, Jan. 1995.
—. “Multidimensional Data Bases and Data Warehousing”(有关数据仓库中的当前细节
数据是如何与多维 DBMS相适应的描述), Data Management Review, Feb. 1995.
—. “The Operational Data Store”(有关ODS的描述), INFODB, Vol. 9, No. 1, Feb. 1995.
— . “Profiling the DSS Analyst ”(把D S S分析人员描述为农场主和探险家 ), Data
Management Review, March 1995.
—. “The Anatomy of a Data Warehouse Record”(有关数据仓库记录内部结构的描述 ),
Data Management Review, July 1995.
—. “Profile/Aggregate Records in the Data Warehouse”(有关概要/聚集记录在数据仓库
环境中是如何创建和使用的描述 ), Data Management Review, July 1995.
—. “Data warehouse and Contextual Data: Pioneering a New Dimension” (正如在数据
仓库中实际所看到的那样，需要时间上有关的数据 ), Data Base Newsletter, Vol. 23, No. 4,
July/August 1995.
—. “Transformation Complexity” (在建立数据仓库所需的转换过程中，为什么将转换
过程自动化比手工编程要优越 )，Data Management Review, Sept. 1995.
—. “The Ladder of Success” (建立和管理数据仓库不仅仅需要选择一个平台。这篇论
226 数据仓库
下载
文指出了成功建立一个数据仓库环境所必需的步骤 ), Data Management Review, Nov. 1995.
— . “Growth in the Data Warehouse”(讲述有关为什么数据仓库成长得如此之快以及增
加存储量的同时会降低存储器使用效率的现象 ), Data Management Review, Dec. 1995.
Inmon, W. H., and C. Kelly. “The 12 Rules of Data Warehouse”(有关定义数据仓库特性
的描述), Data Management Review, May 1994.
Inmon, W. H. , and P. Koslow. “Commandeering Mainframe Database for Data Warehouse
U s e” (讲述有关在大型机系统中所采用的最佳数据仓库 ), Application Development Tr e n d s ,
Aug. 1994.
Inmon, W. H., and M. Loper. “The Unified Data Architecture: A Systems Integration
S o l u t i o n” [原文 (修订后重新发表 )提出一种用于未来系统开发的数据体系结构 ], Auerbach,
1992.
Inmon, W. H. , and S. Osterfelt. “Data Patterns Say the Darndest Things”(有关DSS系统中
数据仓库的描述，以及怎样从一个仓库中导出信息处理 ), Computerworld, Feb. 3, 1992.
Kador, J. “One on One — Interview with Bill Inmon”(就数据仓库与Bill进行的讨论，包
括数据仓库是如何出现的一些背景 ), Midrange Systems, Oct. 27, 1995.
Kimball, R., and K. Strehlo. “Why Decision Support Fails and How to Fix It” (有关事实
表和星型连接的很好的描述，并用不少的篇幅讨论了 R a l p h的数据仓库和决策支持方法 ) ,
Datamation, June 1994.
Konrad, W. “Smoking Out the Elusive Smoker”(有关在广告限制的行销环境下进行数据
库行销的讨论), Business Week, March 16, 1992.
Lambert, B. “Breaking Old Habits to Define Data Warehouse Requirements”(有关最终用
户该如何设法决定 DSS需求的讨论 ), Data Management Review.
O’M a h o n e y, M. “Revolutionary Breakthough in Client/Server Data Wa r e h o u s e
D e v e l o p m e n t”(老式的历史系统开发方法学与现代的循环重复式开发方法学的比较 ), Data
Management Review, July 1995.
Sloan, R, and H. Green. “An Information Architecture for the Global Manufacturing
Enterprise”(有关在大规模制造环境中的信息体系结构的描述 ), Auerbach, 1993.
Thiessen, M. “Proving the Data Warehouse to Management and Customers: Where Are the
Saving?”(Mark Thiessen, Hughes Aircraft的学术报告 , 1994 Data Warehouse Conference, 分发
印刷品, 714-732-9059).
Wahl, D., and D. Hufford. “A Case Study: Implementing and Operating an Atomic Data
Base”(基于美国陆军DSS数据体系结构), Data Resource Management, Auerbach, Spring 1992.
Welch, J. D. “Providing Customized Decision Support Capabilities: Defining Architectures”
(决策支持系统和体系结构，基于 PacTel Cellular 的DSS体系结构), Data Resource Management,
Auerbach, 1990.
PRISM有关数据仓库解决方案的技术专题
从操作型环境中访问数据仓库数据大多数数据流是从操作型环境流向数据仓库环境的，
但是并非都是如此。此技术专题讨论了数据的回流问题。
下载
参考文献 227
数据仓库的容量规划此技术专题讨论了数据仓库环境下的磁盘存储空间和处理器资源
的容量规划和设计的问题。
捕获修改过的数据重复扫描操作型环境以刷新数据仓库所需要的资源是相当多的，此专
题简单地介绍了完成这些工作的一种替代方法。
客户机/服务器和数据仓库客户机/服务器处理可以用于支持数据仓库处理。此技术专题
讨论体系结构和设计问题。
从企业数据模型建立数据仓库数据模型从企业数据模型建立数据仓库模型所需要采取的
步骤。
数据仓库和成本分析对数据仓库进行事前成本分析是件困难的事情，此技术专题讨论了
这个问题。
数据仓库预算此技术专题讨论了不同的花费模式以及费用花费比重，其中包括一些如何
尽量减少花费的建议。
定义记录系统确定和定义记录系统的设计方面的一些考虑。
EIS和数据仓库以历史系统为基础的 EIS是很脆弱的，而以数据仓库为基础的 EIS却是非
常稳固，本技术专题对此有详细的阐述。
对最终用户解释元数据当一个用户碰到元数据时，最原始反应通常是“元数据实际究竟
是什么东西，我为什么还需要元数据？”此技术专题以非常普通直接的术语对元数据进行了
解释。
起步数据仓库是以循环重复方式建立起来的。此技术专题以详细的方式告诉你所需要采
取的第一个步骤。
9 0年代的信息体系结构：历史系统，操作型数据存储，数据仓库描述了操作型数据存
储的作用，并且描述了将操作型存储和数据仓库混合起来所产生的体系结构。
信息工程和数据仓库数据仓库体系结构与信息工程的设计和模型化实践是相当协调的，
此技术专题描述了它们之间的关系。
加载数据仓库乍看起来，将数据加载数据仓库是一件简单的事，实际上并非如此。该讨
论涉及到了将数据从操作型环境加载数据仓库中的许多不同的考虑因素。
管理多数据仓库开发工作当一个企业开始同时建立多数据仓库时，就会出现一系列新的
设计和开发问题。此技术专题提出并讨论了这些问题。
数据仓库中的元数据元数据是数据仓库的重要部分。此技术专题讨论了数据仓库中为什
么需要元数据的不同部份，以及元数据具有哪些不同的部份。
OLAP 和数据仓库轻度综合的数据总是数据仓库体系结构不可缺少的部分。现在，这种
结构被称为 OLAP，或数据集市。此技术专题讨论了 OLAP与数据仓库中细节数据的关系。
从单个数据库进行操作型和 D S S处理：对事实和假设进行分离有一个早期的概念，就
是单个数据库既应作为操作型处理的基础，又应服务于 D S S分析型处理。这个技术专题探讨
了这些问题，并且描述了为什么数据仓库是适宜作为 DSS信息处理的基础。
操作型数据存储数据仓库的操作型对应物是操作型数据存储（ ODS）。在此技术专题中，
对ODS有详细的定义和描述。
数据仓库的并行处理管理大量数据是数据体系结构设计人员所要面临的第一个而且是主
要的挑战。并行技术提供了管理更多数据的可能性。此技术专题是有关数据仓库环境中的并
228 数据仓库
下载
行处理技术问题的。
数据仓库环境中的性能在DSS数据仓库环境中，性能问题与 OLAP环境中一样重要。此
技术专题全部是有关 DSS数据仓库环境中的性能问题的。
重建工程和数据仓库许多企业没有意识到重建工程和数据仓库之间非常紧密并且非常有
用的关系。此技术专题指出这种关系，并讨论其他相关问题。
在数据仓库中表示数据关系：数据的人工关系在数据仓库中建立数据关系的设计问题。
数据仓库的安全数据仓库的安全性问题出现在不同的层面。此技术专题对这些问题进行
讨论。
数据仓库环境中服务层协议服务层协议是联机操作的一个里程碑，服务层协议适用于数
据仓库，但各种实现方式有着很大不同。
数据仓库中的数据快照描述不同类型快照以及各种不同快照的优缺点。
数据仓库/ O D S中的汇总数据库汇总数据具有它自己一套独特的考虑，如动态汇总数据
和静态汇总数据。每种类型的汇总数据都需要设计人员与最终用户相当不同的处理。此技术
专题为汇总数据建立了一种分类法，并将不同类型的汇总数据与数据仓库和 O D S(操作型数据
存储)联系起来。
说明操作型和 D S S的区别在每个工作环境都会冒出这样的问题—什么是操作型？什么
是DSS？此技术专题告诉你它们之间的区别。
依赖于时间的数据结构讨论不同类型的数据结构以及它们的优缺点。
采用通用数据模型一些企业用数据模型来作为它们的数据仓库设计的出发点，有些企业
不是这样做。通用数据模型可作为数据仓库设计和开发工作的开始。
什么是数据仓库此技术专题定义什么是数据仓库及其结构特征。这是一个基本的讨论，
适合于所有研究数据仓库的人。
下载
第1章决策支持系统的发展
信息系统领域是一个“不成熟”的领域。“不成熟”这个词通常具有消极的含义，因而公
开使用这个词不得不多加小心。但是从历史的观点来看的确如此。如果我们将信息处理的历
史与其他技术领域的历史进行比较的话，就没有争议了。我们知道古埃及的象形文字主要是
当时的帐房先生用来表示所欠法老谷子的多少。当漫步在罗马市区，我们就置身于两千多年
前土木工程师所设计的街道与建筑物之间。同样，许多其他的领域也可追溯到远古时代。
因为信息处理领域只是从 6 0年代初期才出现的，所以，历史地来看，信息处理领域是不
成熟的。
信息处理领域的年轻性表现之一就是其倾向于面面俱到。有这样一种说法，如果细节都
正确了，那么我们就可以坐享其成。这就好象是说，若我们知道如何铺水泥、如何钻孔、如
何安装螺母与螺栓，就不必操心桥梁的外型与用途了。如此态度会驱使一个成熟的土木工程
师发疯的。
数据仓库的历史是伴随某种发展过程开始的，在此发展过程中，业界中人士所考虑的是
投入更大的力量。更大规模的体系结构正在被勾勒出来 — 在这种体系结构中数据仓库处于
中心地位。最好从一种广阔的视角去观察这个体系结构，而不是从某种细节去认识。
1.1 演化
有趣的是，决策支持系统 ( D S S )处理是一个漫长而复杂的演化进程的结果，而且它仍在继
续演化。DSS处理的起源可以追溯到计算机发展的初期。
图1 - 1表明了从 2 0世纪6 0年代初期直到 1 9 8 0年的D S S处理的演化进程。在 6 0年代初期，创
建运行于主文件上的单个应用是计算领域的主要工作。这些应用的特点表现在报表和程序，
常用的是 C O B O L语言。穿孔卡是当时常用的介质。主文件存放在磁带文件上。磁带适合于廉
价地存放大容量数据，但缺点是需要顺序地访问。事实上，我们常说，在磁带文件的一次操
作中， 1 0 0 %的记录都要被访问到，但是只有 5 %或更少的记录是真正需要的。此外，访问整
条磁带的文件可能要花去 2 0 ~ 3 0分钟时间，这取决于文件上是什么数据及当前正在做什么处
理。
大约在 6 0年代中期，主文件和磁带的使用量迅速膨胀。很快，处处都是主文件。随着主
文件数量的增长，出现大量冗余数据。主文件的迅速增长和数据的巨大冗余引出了一些严重
问题：
■ 需要在更新数据时保持数据的一致性。
■ 程序维护的复杂性。
■ 开发新程序的复杂性。
■ 支持所有主文件需要的硬件数量。
简言之，属于介质本身固有缺陷的主文件的问题成为发展的障碍。如果仍然只用磁带作
为存储数据的唯一介质，那么难以想象现在的信息处理领域会是什么样子。
2发展数据仓库
下载
主文件，报表
1960
• 复杂性
• 维护
1965 • 开发
• 数据的一致性
• 硬件
很多主文件！！！
1970 DASD 数据库 — 所有处理的

DBMS 单一数据源
1975 联机高性能事务处理
1980
个人计算机
第四代程序设计语言技术
tx 处理 MIS/DSS
单一数据库服务于完成所有目的
图1-1 体系化环境的早期演化阶段
如果除了磁带文件以外没有别的东西可以存储大量数据，那么世界上将永远不会有大型、
快速的预定系统， AT M系统，以及其他系统。而事实上，在除磁带文件之外的种种介质上存
储和管理数据的能力，为采用不同的处理方式和更强有力的处理类型开辟了道路，从而把技
术人员和商务人员前所未有地聚集到一起。
1.2 直接存取存储设备的产生
到了1 9 7 0年，一种存储和访问数据的新技术出现了。这就是 2 0世纪7 0年代见到的磁盘存

下载
第1章决策支持系统的发展发展 3
储，或者称之为直接存取存储设备 ( D A S D )。磁盘存储从根本上不同于磁带存储，因为 D A S D
上的数据能够直接存取。 D A S D就不需要经过第 1条记录，第 2条记录……，第 n条记录，才能
得到第 n + 1条记录。一旦知道了第 n + 1条记录的地址，就可以轻而易举地直接访问它。进而，
找到第n + 1条记录需要的时间比起扫描磁带的时间少得多。事实上，在 D A S D上定位记录的时
间是以毫秒 (ms)来计量的。
随D A S D而来的是称之为数据库管理系统 ( D B M S )的一种新型系统软件。 D B M S的目的是
使程序员在 D A S D上方便地存储和访问数据。另外， D B M S关心的是在 D A S D上存储、索引数
据等任务。随着 D A S D和D B M S的出现，解决主文件系统问题的一种技术解决方案应运而生。
“数据库”的思想就是 D B M S的产物。纵观主文件系统所导致的混乱以及主文件系统累积的大
量冗余数据，就不会奇怪为什么把数据库定义为 — 所有处理工作的单一数据源。
但这一领域的发展并未在 1 9 7 0年停止。到 7 0年代中期，联机事务处理开始取代数据库。
通过终端和合适的软件，技术人员发现更快速地访问数据是可能的 — 这就开辟了一种全新
的视野。采用高性能联机事务处理，计算机可用来完成以前无法完成的工作。当今，计算机
可用于建立预定系统、银行柜员系统、工业控制系统，等等。如果仍然滞留在磁带文件系统
时代，那么今天我们认为理所当然的大多数系统就不可能存在了。
1.3 个人计算机/第四代编程语言技术
到了8 0年代，一些更新颖的技术开始涌现出来，比如个人计算机 ( P C )和第四代编程语言

( 4 G L )。最终用户开始扮演一种以前无法想象的角色 — 直接控制数据和系统，这超出了对
传统数据处理人员的界定。随着 P C与4 G L技术的发展，诞生了一种新思想，即除了高性能
联机事务处理之外，对数据可以做更多的处理。管理信息系统 ( M I S ) — (早期被如此称呼)
也可能实现了。 M I S如今称为 D S S，是用来产生管理决策的处理过程。以前，数据和技术不
能一并用来导出详细的操作型决策。一种新的思想体系开始出现，即一个单一的数据库既
能用作操作型的高性能事务处理，同时又用作 D S S分析处理。图 1 - 1表明了这种单一数据库
的范例。
1.4 进入抽取程序
大型联机高性能事务处理问世后不久，就开始出现一种称为“抽取”处理的程序(见图 1 -
2)，这种程序并不损害已有系统。
抽取程序是所有程序中最简单的程序。它搜索整个文件或数据库，使用某些标准选择合
乎限制的数据，并把数据传到其他文件或数据库中。
抽取程序很快就流行起来，并渗透到信息处理环境中。至少有两个理由可以用来解释它
为什么受到欢迎：
■ 因为用抽取程序能将数据从高性能联机事务处理方式中转移出来，所以在需要总体分
析数据时就与联机事务处理性能不发生冲突。
■ 当用抽取程序将数据从操作型事务处理范围内移出时，数据的控制方式就发生了转变。
最终用户一旦开始控制数据，他 (她)就最终“拥有”了这些数据。
由于这些原因(以及其他众多原因 )，抽取处理很快就无处不在。到了 90年代已有了很多抽
取程序，如图1-3所示。
4发展数据仓库
下载
1985
抽取程序
从一些参数开始,根据参数条件的满足搜索文
件,然后将数据拖到别处
抽取处理
为什么要进行抽取处理？
• 性能
• 控制
图1-2 抽取处理的特性
1.5 蜘蛛网
图1 - 3显示抽取处理的蜘蛛网开始形成。起初只是抽取，随后是抽取之上的抽取，接着是
在此基础上的再次抽取，如此等等。对于一个大公司，每天进行多达 45 000 次的抽取不是没
有听说过的。
贯穿于公司或组织的这种抽取处理模式很常见，以致得到一个专有名称。这种由失控的
抽取过程产生的结构被称为“自然演化体系结构” — 当一个组织以放任自流的态度处理整
个硬、软件体系结构时，就会发生这种情况。组织越庞大，越成熟，自然演化体系结构问题
就变得越严重。
从总体上看，抽取程序形成了蜘蛛网，这正是自然演化 (或“传统系统” )体系结构的另一
下载
第1章决策支持系统的发展发展5
传统系统环境
1990
自然演化的体系结构(或称为“蜘蛛网”)
图1-3 抽取处理广泛采用必然是件好事情
个名称。
1.6 自然演化体系结构的问题
与自然演化体系结构相关联的困难到底是什么呢？问题很多，主要有：
■ 数据可信性。
■ 生产率。
■ 数据转化为信息的不可行性。
1.6.1 数据缺乏可信性
以上问题之首是数据缺乏可信性，如图 1 - 4所示。两个部门向管理者呈送报表，一个部门
说业绩下降了15%，另一个部门说业绩上升了 10%。两个部门的结论不但不吻合，而且相去甚
远。另外，两个部门的工作也很难协调。除非十分细致地编制了文档，否则对任何应用目的
而言，协调是不可能的。
6 发展数据仓库
下载
当管理者收到这两张报表时，他们不知如何是好。管理者面临着根据政策和个人意志做
决定的状况。这是在自然演化体系结构中可信性危机的一个实例。
这种危机很广泛存在，而且是可以预想得到的，为什么？有五个理由可以解释危机的可
预测性(见图1-4)，它们是：
■ 数据无时基。
■ 数据算法上的差异。
■ 抽取的多层次。
■ 外部数据问题。
■ 无起始公共数据源。
部门Ａ +10%
部门B－15%
• 数据无时基
• 数据算法上的差异
• 抽取的多层次
• 外部数据问题
• 无起始公共数据源
图1-4 在自然演化体系结构中缺乏数据可信性
图1 - 5显示一个部门在星期日晚上提取分析所需的数据，而另一个进行分析的部门在星期
三下午就抽取了数据。有任何理由相信对某一天抽取的数据样本进行的分析与对另一天抽取
的数据样本进行的分析可能相同吗？当然不能！公司内的数据总是在变的。任何在不同时刻
抽取出来用于分析的数据集之间只是大致相同。
在自然演化体系结构中，数据可信性危机具有可预见性的第二个理由是算法上的差异。
下载
比如，一个部门选择所有的老帐号作分析。而另一个部门选择所有大帐号作分析。在有老帐
号的顾客和有大帐号的顾客之间存在必要的相关性吗？可能没有。那么分析结果大相径庭就
没有什么可大惊小怪的了。
可信性危机可预见性的第三个理由是前两个理由的扩展。每次新的抽取结束，因为时间
和算法上的差异，抽取结果就可能出现差异。对一个公司而言，从数据进入公司系统到决策
者准备好分析所采用的数据，经过八层或九层抽取不是罕见的。
缺乏可信性的第四个理由是由外部数据引起的问题。利用当今在 P C层次上的技术很容易
从外部数据源取得数据。在图 1 - 5所示的例子中，一个分析人员从《华尔街日报》取得数据放
入分析流中，而另一个分析人员从《商业周刊》中取得数据。分析人员在取得数据之时所做
的第一件事就是从大量外部数据中抽出所需要的部分。数据一旦进入 P C，就不再属于《华尔
街日报》了，而简单地变成了可能出自于任何数据源的普通数据。
并且，从《华尔街日报》取得数据的分析人员对从《商业周刊》中取得的数据是一无所
知的，反之亦然。这就不足为怪，外部数据导致自然演化体系结构中的数据缺乏可信性。
导致数据缺乏可信性的最后一个因素是通常没有一个公共的起始数据源。部门 A的分析工
多层抽取
华尔街
日报
部门Ａ +10%
• 星期日晚
• 老账号
多层抽取
部门B－15%
• 星期三下午
无公共起始数据源
• 大账号
• 缺乏一致性
商业周刊 • 没有同输入外部数
据的其他人协调
图1-5 自然演化体系结构中可信性危机可预见性的原因
下载
作源于文件 X Y Z，部门 B的分析工作源于数据库 A B C。不论文件 X Y Z与数据库 A B C之间关系
怎样，都不存在数据同步或数据共享。
有了这些理由，在每一个企业或机构中，如果允许软件、硬件和数据的体系结构自然地
演化为蜘蛛网，那么这种企业或机构中正酝酿着可信性危机就不足为奇了。
1.6.2 生产率问题
但是数据可信性还不是自然演化体系结构中的唯一的主要问题。在自然演化体系结构中，
当需要查询机构范围内的数据时，生产率 (或者说生产率低 )是不可预测的。
设想一个机构在商业上已运营了一段时间,并且已经建立起了大型数据集合,如图1-6顶部所示。
管理者期望用数年来积累的数据集合和众多文件生成一张企业报表，接受了该任务的设
计者为产生企业报表决定做三件事：
■ 定位报表需要的数据并分析数据。
■ 为报表编辑数据。
■ 为完成以上工作，召集程序员 /分析员。
生产率
根据全部数据生成企业报表
定位数据需要浏览大量文件
抽取程序很多，并且每个都是定制的，不得不克服很多技术上的障碍
图1-6 自然演化体系结构不利于生产率的提高
下载
要进行数据定位，必须分析很多文件和数据布局。而且，存在一些复杂因素：一个文件
有一个被称为 B A L A N C E的元素；而另一个文件有一个同名的元素。但是两个元素的意义相
去甚远。另一种情况是，一个数据库有一个被称为 C U R R B A L的文件，而在另一个数据集中
存在一个称为 I N V L E V E L的文件，此文件恰好与 C U R R B A L相同。这就不得不遍历每一个数
据，不只按名遍历，而且按数据的定义和计算要求遍历，这是一个十分乏味的过程。但是如
果要生成企业报表，这个过程就必不可少。除非对数据进行分析和“合理化”处理，否则报
表最终将产生更大的混乱，就像苹果和桔子混在一起一样。
一旦数据定位完成，下一个任务就是编辑数据。当然，为从众多的数据源中取得数据而
必须编制的程序相当简单。但是以下事实使这种工作复杂化：
■ 要写的程序很多。
■ 每个程序必须是定制的。
■ 程序涵盖了公司拥有的所有技术。
简言之，即使必须写报表生成程序，并且看起来并不难，但是由于上面的因素，为生成
企业报表检索数据仍是个十分乏味的工作。
在一个面临以上这些问题的公司里，分析人员估算过要完成这项工作需要很长时间，如
图1-7所示。
如果设计者只要求了两三个人月资源的工作量，那么生成这样一个报表可能不需要管理者过
生产率
数据定位 9～12个月
取得数据 15～24个月
程序员/分析员???
3～5年
第一个报表
第二个报表
第三个报表 3～5年
…………
第n个报表
除非在某些非常罕见的情况,第一张报表的制作不大可能为
第二张报表或第三张报表. . . 的制作有什么贡献
图1-7 在编写第一张报表时,对后继报表的需求还不清楚
下载
多的关注。但如果一个分析员需要很多资源，管理者就必须将这个请求与其他对资源的请求一并
考虑，并且必须为这些请求制定优先级。因此，分析员估算了漫长的时间以生成期望的报表。
如果时间代价是一次性的，那么为生成报表花费大量的资源也是可取的。换句话说，如
果生成第一份企业报表需要大量资源，生成所有后继报表可以建立在第一份报表基础之上，
那么不妨为生成第一份报表付出一些代价。但是事实并非如此。
除非事先知道未来的企业报表需求，并且除非这些需求影响到第一张企业报表的建造，
每个新的企业报表总要花费同前面差不多大的代价。换句话说，第一张企业报表非常不可能
为将来别的企业报表需求做出什么贡献。
因此在公司环境中，生产率是自然演化体系结构和传统系统所面临的一个主要问题。
1.6.3 从数据到信息
看来生产率和可信性还不是问题的全部，自然演化体系结构还存在着另一个主要缺陷 —
从数据到信息转化的不可行性。乍一看来，从数据转化成信息的思想是一个缺少实际意义的
虚无概念，但是事实完全不是这样。
考虑下面对信息的需求，这种需求在银行环境中很典型：“今年的帐号活动同过去五年中
各个年份有什么不同？”
图1-8显示了对信息的这种需求。
DSS分析员试图满足对信息的需求，而在此过程中发现的第一件事情，就是到现存的系统
从数据到信息
DDA
借贷 CD
存折
首先,遇到大量应用程序
DDA
CD
借贷存折
相同的元素只在此处存在的元素
不同的名字
不同的元素
相同的名字
其次，发现缺少应用程序之间的集成
图1-8 “这个金融机构今年的账号活动同过去五年中各个年份有什么不同？”
下载
中寻求必要的数据大概是最糟的举动。在传统环境中存在着 DSS分析员将要遇到的很多应用程
序。
试图发现一个帐号存在哪些相关数据是相当困难的。系统中有储蓄应用程序、借贷应用
程序、D D A (活期存款记帐 )应用程序和信用应用程序。从它们当中抽取公共信息几乎不可能。
设计这些应用程序时从未考虑数据集成，对 D S S分析员来说对它们进行解释并不比任何其他
人更容易。
但是，集成化并非分析人员在试图满足信息需求过程中遇到的唯一困难。第二个主要障
碍是在应用程序中没有存储足够的历史数据以满足 DSS分析员的需求。
图1 - 9显示借贷部门拥有长达两年的有用数据，存折处理程序有长达一年的数据， D D A应
用程序有 6 0天的数据， C D处理程序有1 8个月的数据。建造这些应用程序是用来满足当时收支
处理的需要 (自然是足够的！ )。设计时从未考虑过保存这些历史数据以满足 D S S分析的需求。
那么不用说，对 D S S分析来说，求助于现存系统不是明智的选择。但是除了这些又能求助于
什么呢？
在自然演化体系结构中建立起来的系统对信息需求的支持确实是不充分的，因为它们缺
乏集成性，以及在分析性处理需要的时间期限上和在蜘蛛网环境中应用程序的可用时间期限
上存在差异。
从数据到信息
一个例子：
“这个金融机构今年的账号活动同过去五年中各个年份有什么不同？”
DDA
当前值 -30天
借贷 CD
当前值 - 两年当前值—18个月
存折
当前值 - 一年
图1-9 现有的应用程序的确没有将数据转化成信息所需的历史数据
1.6.4 方法的变迁
自然演化体系结构的存在方式(今天大多数商场采取这种模式)确实不足以满足明天的需
要。体系结构需要转变，体系化的数据仓库环境应该在变化了的体系结构上建造。
体系结构设计环境的核心是意识到存在着两种基本数据：原始数据和导出数据。图 1 - 1 0
显示了原始数据与导出数据之间的一些主要区别。
原始数据是公司每天操作运行所用的细节性数据，导出数据是统计出来的或计算出来的
满足公司管理者需要的数据。原始数据可以更新，导出数据不可以更新。原始数据主要是当
前值数据，导出数据通常为历史数据。原始数据由以重复方式运行的过程操作，导出数据由
非重复地启发式地运行的程序操作。操作型数据是原始的， D S S数据是导出的。原始数据支
下载
持日常工作，导出数据则支持管理工作。
因此，在原始数据与导出数据之间存在着本质区别。奇怪的是，在信息处理界曾经考虑
过将原始数据和导出数据都放入一个单一数据库中。
方法的变迁
原始数据/操作型数据导出数据/DSS数据
• 面向应用 • 面向主题
• 详细的 • 综合的,或提炼的
• 在存取瞬间是准确的 • 代表过去的数据
• 为日常工作服务 • 为管理者服务
• 可更新 • 不更新
• 重复运行 • 启发式运行
• 处理需求事先可知 • 处理需求事先不知道
• 生命周期符合 SDLC • 完全不同的生命周期
• 对性能要求高 • 对性能要求宽松
• 一个时刻存取一个单元 • 一个时刻存取一个集合
• 事务处理驱动 • 分析处理驱动
• 更新控制主要涉及所有权 • 无更新控制问题
• 高可用性 • 松弛的可用性
• 整体管理 • 以子集管理
• 非冗余性 • 时常有冗余
• 静态结构；可变的内容 • 结构灵活
• 一次处理数据量小 • 一次处理数据量大
• 支持日常操作 • 支持管理需求
• 访问的高可能性 • 访问的低可能性或适度可能性
图1-10 在体系结构设计环境中数据整体思想的变化
1.7 体系结构设计环境
由于原始数据和导出数据的不同而导致的数据分离的自然扩展过程如图 1-11所示。
体系结构层次
操作型原子/数据仓库部门个体
• 细节的 • 大部分粒度 • 领域狭隘 • 暂时的

• 逐日 • 随时间变化的 • 一些导出数据； • 为特定目的的
• 当前值的 • 集成的 • 一些原始数据 • 启发式的
• 访问的高可能性 • 面向主题 • 典型的部门 • 非重复的
• 面向应用 • 一些汇总 • 财务 • 基于PC和工作站的
• 市场
• 工程
• 保险
• 制造
图1-11 尽管看起来不太明显,但在体系结构设计环境中存在的数据冗余很少
下载
1.7.1 体系结构设计环境的层次
在体系结构设计环境中有四个层次 — 操作层、原子或数据仓库层、部门层、个体层。数
据操作层只保存原始数据并且服务于高性能事务处理领域。数据仓库层存储不更新的原始数
据，此外一些导出数据也在此存放。数据的部门层几乎只存放导出数据。在数据个体层中完
成大多数启发式分析。
对这种体系结构的直接反应是在体系结构设计环境中存在大量冗余数据。事实上完全不是这
样，尽管数据冗余很少这一点乍看起来不明显。相反，在蜘蛛网中倒是存在着大量的数据冗余。
考察贯穿这种体系结构的数据的简单实例，如图 1 - 1 2所示。在操作层中存在一个顾客记
录J . J o n e s。在操作层的记录是包含当前值的数据记录。要了解顾客的当前的情况，就访问操
作层的记录。当然，如果关于 J . J o n e s的信息变化了，那么操作层的记录将随之变化成正确的
新数据。
简单例子：一个顾客
操作型原子/数据仓库部门/数据集市个体

按月的顾客
J.Jones
J.Jones
1986-1987 Jan-4101
123 Main Street
456 High St Feb-4209 顾客
信用度-AA
信用度-B Mar-4175 从1982年起
Apr-4215 帐号余额＞ 5 0 0 0且
J.Jones …………… 信用度不低于 B
1987-1989 ……………
456 High St
信用度-A
临时的！
J.Jones
1989-pres
123 Main St
信用度-AA
J.Jones现在的 J.Jones的信用我们吸引越来越多我们所分析的客户

信用度是多少 ? 历史如何 ? 或越来越少的客户 ? 趋势如何?
图1-12 可用不同数据层次进行查询的不同类型
在数据仓库环境中可以找到几条有关 J . J o n e s的记录，这些记录反映了 J . J o n e s的历史信息。

比如，要发现 J . J o n e s去年住在什么地方，就搜索数据仓库中的记录。在数据仓库环境中的数
据与在操作型环境中的数据之间无重叠。如果 J . J o n e s的地址发生了变化，那么在数据仓库中
本节标题是译者添加的。
下载
将产生一个记录，这个记录反映了从什么时间到什么时间 J . J o n e s住在哪里。注意数据仓库中
的记录无重叠，并且在数据仓库中存在与每个记录相关联的时间元素。
部门环境包括对一个公司中不同地区的部门有用的信息。部门环境包括市场部门数据库，
财务部门数据库，保险部门数据库，等等。所有部门的数据源都是数据仓库。部门层常被称
为“数据集市层”、OLAP层或“多维 DBMS”层。
部门层典型数据是月度顾客文件。在此文件中是一张所有顾客的分类列表。 J . J o n e s每月
都出现在这个汇总当中。可以进一步考虑将记帐信息作为冗余的一种形式。
最后的数据层是个体层。个体层数据常常是暂时的、小规模的。在个体层要做很多启发
式分析。通常，个体层数据被认为是由 P C机支持的数据。高级管理人员信息系统 ( E I S )处理主
要运行在个体层上。
1.7.2 集成
在图1 - 1 2中没有显示出来的体系结构设计环境的一个重要方面是发生于整个体系结构中
的数据集成。当数据从操作型环境传向数据仓库环境时，数据就被集成，如图 1-13所示。
简单例子：一个顾客
操作型原子/数据仓库
人寿保险
J Jones
女
1945年7月20日
…… 顾客
J Jones
汽车保险
女
J Jones 1945年7月20日出生
去年有两张罚单去年有两张罚单
一次大事故一次大事故
…… Main 大街123号
已婚
房产保险两个孩子
J Jones 高血压
Main 大街 123号 ……
已婚
……
健康保险
J Jones
两个孩子
高血压
……
图1-13 数据在从操作型环境转移到数据仓库环境的同时进行集成
下载
把数据从操作型环境载入到数据仓库环境时，如果不进行集成就没有意义。如果数据以
一种非集成状态到达数据仓库，它就不能被用来支持数据的企业视图。数据的企业视图是体
系结构设计环境的本质之一。
1.8 用户是谁
数据仓库的用户称为 DSS分析员。他首先是个商务人员，其次才是技术人员。 DSS分析员
的主要工作是定义和发现在企业决策中使用的信息。
了解DSS分析员的想法及他们对使用数据仓库的理解是很重要的。 DSS分析员有一种想法，
即“给我看一下我说我想要的东西，然后我告诉你我真正想要什么。”换句话说，DSS分析员在
发现模式下工作。直到看到报表或屏幕上的数据时，他们才开始探讨是否有必要进行DSS分析。
DSS分析员的态度之所以重要的理由如下：
■ 它是合理的。
■ 它是广泛的。
■ 它对数据仓库的开发方式和系统怎样使用被开发的数据仓库有深远的影响。
传统的系统开发生命周期 (SDLC)不适用于DSS分析领域。 SDLC假设在设计之初需求是已
知的(或至少是可以被发现的 )。但是，在 D S S分析员眼中，在 D S S开发生命周期的最后才发现
真正的需求。与数据仓库相关联的是一种完全不同的开发生命周期。
1.9 开发生命周期
操作型数据通常是非集成的，而数据仓库数据必须是集成的。在数据和处理的操作层和
数据和处理的数据仓库层之间，存在其他几个重要区别。操作层和数据仓库层之间内在的区
别关系到系统开发生命周期，如图 1-14所示。
需求
数据仓库
程序
程序
需求
传统的SDLC 数据仓库 SDLC

• 收集需求 • 实现数据仓库
• 分析 • 集成数据
• 设计 • 检验偏差
• 编程 • 针对数据编程
• 调试 • 设计DSS系统
• 集成 • 分析结果
• 实现 • 理解需求
图1-14 数据仓库环境下的系统开发生命周期与传统的SDLC几乎完全相反
下载
图1 - 1 4显示传统的系统开发生命周期支持操作型环境。数据仓库运行于一个与之完全不
同的生命周期下，有时称为 C L D S (与S D L C顺序相反 )。传统的 S D L C是需求驱动的。为建立系
统，你必须首先理解需求，然后进入到设计和开发阶段。 C L D S几乎刚好相反。 C L D S由数据
开始，一旦数据到手就集成数据。然后，如果数据有偏差，就检验看看数据存在什么偏差。
再针对数据写程序，分析程序执行结果。最后，系统需求才得到了理解。
C L D S是典型的数据驱动开发生命周期，而 S D L C是典型的需求驱动开发生命周期。试图
采用不适当的开发工具和技术只会导致浪费和混乱。比如， CASE领域是由需求驱动分析所支
配的。试图将CASE工具和技术用于数据仓库领域是不明智的，反之亦然。
1.10 硬件利用模式
操作型环境和数据仓库环境之间的还有另一个主要差别，即在各自环境中硬件利用模式
也不同，如图1-15所示。
操作型数据仓库
100%
0%
图1-15 不同环境下不同的硬件利用模式
图1 - 1 5左面显示操作型处理的典型的硬件利用模式。在操作型处理中有波峰和波谷，但
总归存在相当稳定的利用模式。
数据仓库环境中具有根本不同的硬件利用模式 (如图的右部所示 )，即利用的二元模式。要
么利用全部硬件，要么根本不用硬件。估算数据仓库环境中的硬件平均利用率是没有意义的。
这种根本区别也表明同时在同一台机器上把两种环境混在一起为什么不可行。要么针对
操作型处理优化机器，要么针对数据仓库处理优化机器。但是你不可能同时在同一台设备上
两者都作到。
1.11 建立重建工程的舞台
从生产环境转变到体系结构设计的数据仓库环境过程中有一个非常有用的副作用，尽管
它不是直接的。图 1-16显示了这种过程。
生产环境
操作型环境数据仓库环境
图1-16 从传统系统环境向体系结构设计的以数据仓库为中心的环境转变
下载
在图1-16中，在生产环境中发生一种转变。第一个作用是从生产环境中移走大量数据 —
大部分是档案数据。移走大量数据在许多方面具有好的效果，包括如下几条：
■ 生产环境更易于纠错。
■ 生产环境更易于重构。
■ 生产环境更易于监控。
■ 生产环境更易于索引。
简言之，仅仅是移走可观数目的数据就可使生产环境更具有可塑性。
另一个作用是从生产环境中移走信息性处理。信息性处理采取报表、屏幕显示、抽取等
形式。信息处理的特点是不停地变化。商业形势变化、机构变化、管理变化、财务状况变化，
等等。这些变化中的任何一个都对综合与信息性处理产生影响。当信息性处理处在生产传统
环境中时，维护起来无休无止。事实上，在生产环境中，大多数所谓的维护就是贯穿于正常
的信息变化周期中的信息性处理。通过把大多数信息性处理移到数据仓库中，生产环境中的
维护负担将大大减轻。图 1-17显示从生产环境中移走大量数据和信息性处理的效果。
大量的历史数
据,它们很少被
访问,几乎从不
改变
生产环境
随着无休止的维护而显示出
来的信息型、分析型需求
图1-17 从生产环境中移走不需要的数据和信息型需求— 建造数据仓库的效果
一旦生产环境经历转变到以数据仓库为中心的体系结构设计环境的变化，生产环境就正
好适合于重建工程。因为此时生产环境：
■ 更小。
■ 更简单。
■ 更集中。
总之，一个公司要想成功地重建生产系统和修整遗留系统，最重要的步骤是首先建立数
据仓库环境。
1.12 监控数据仓库环境
通常，数据仓库环境中两种受监控的操作成分是存储于数据仓库中的数据和数据的使用。
监控数据仓库环境中的数据是管理数据仓库环境的基本能力。通过监控数据仓库环境中的数
据能取得一些重要信息，包括：
■ 识别发生了什么增长，增长发生在什么地方，增长以什么速率发生。
下载
■ 识别正在使用什么数据。
■ 估算最终用户得到的响应时间。
■ 确定谁在实际使用数据仓库。
■ 说明正在使用数据仓库中的多少数据。
■ 精确指出数据仓库何时被使用。
■ 识别数据仓库的多少数据被使用。
■ 检查使用数据仓库的层次。
当数据体系结构设计者不知道这些问题的答案时，有效的管理运行中的数据仓库环境是
不可能的。
监控数据仓库真的有用吗？只要考虑一下知道“在数据仓库中什么数据正在被使用”有多么
重要就明白了。数据仓库的特性是不停地增长。历史数据不停地加入数据仓库，汇总数据也不停
地加入，新的抽取流在创建。同时数据仓库驻留的存储和处理技术并不昂贵。有时会问这样的问
题：“为什么所有这些数据要积累起来？真有人用这些数据吗？”显然，不论是否有数据仓库的
合法用户，在数据仓库正常运行期间，一旦数据放入数据仓库，数据仓库的开销就会增长。
只要数据体系结构设计者没有办法确定如何使用数据仓库中的数据，那么除了不断购买
新的计算机资源之外就别无选择了 — 购买更多的存储设备、更多的处理器，等等。但是通
过监控数据仓库中数据的使用，就有机会把不用的数据移到其他介质上。当数据体系结构设
计者发现当前一些数据没有使用，就把这种数据移到不昂贵的介质上，这是合适的做法。通
过监控数据仓库中数据的使用和活动情况，数据体系结构设计者能确定现在什么数据不在使
用，就能进行转移。监控数据仓库环境中的数据及活动会得到非常实在的和迅速的回报。
在数据监控处理期间，可以建立数据的各种概要文件包括：
■ 数据仓库中所有表的目录。
■ 这些表的内容。
■ 数据仓库中表的增长。
■ 用于访问表的可用的索引目录。
■ 汇总表和汇总源的目录。
监控数据仓库活动的需求通过下列问题来说明：
■ 什么数据正在被访问？
• 什么时候访问？
• 由谁访问？
• 访问频率怎样？
• 在什么细节层次？
■ 对请求的响应时间是什么？
■ 在一天的什么时间提出请求？
■ 请求多大的数据量？
■ 请求是被终止的还是正常结束的？
D S S环境中响应时间的概念与联机事务处理 ( O LT P )环境中响应时间的概念大不相同。在
OLTP环境中，响应时间总是十分重要的。在 O LT P中当响应时间太长时，业务情况很快就开
始变糟。在 D S S环境中不存在这种关系。在 D S S数据仓库环境中，响应时间总是宽松的。在
下载
DSS中响应时间不是决定性的，相应地，在 DSS数据仓库环境中响应时间以分钟和小时计，在
某些情况下以天计。
但是，在DSS数据仓库环境中响应时间很宽松并不意味着响应时间不重要。在 DSS数据仓
库环境中，最终用户重复地进行开发工作。这意味着下一个层次的开发依赖于当前分析中所
得到的结果。如果最终用户进行重复分析，并且周转时间只有 10分钟，那么他 (她)将比周转时
间多达 2 4小时的情况具有更高的生产率。因此，在 D S S环境中，响应时间与生产率之间存在
十分密切的关系。 DSS环境中响应时间只是非关键性的，并不意味着它无关紧要。
测量D S S环境中的响应时间是管理 D S S的第一步。仅此一点，监控 D S S活动就是必须进行
的非常重要的步骤。
在D S S环境中响应时间度量的问题之一是“要度量什么？”在 OLTP环境中，要度量什么
的答案是显而易见的。发出请求、接受服务，然后返回给最终用户。在 OLTP环境中响应时间
的度量是从请求被提交的时刻算起到结果被返回的时间。但是 D S S数据仓库环境不同于 OLTP
环境，因为没有明确的度量数据返回的时间。在 D S S数据仓库环境中，经常有作为查询结果
返回的大量数据。其中一些数据在某一时间返回，另一些数据在晚些时候返回。定义数据仓
库环境中数据返回时间不是件容易的事。一种解释是数据第一个返回的时间；另一种解释是
数据最后一个返回的时间。对度量响应时间还有很多其他可能的解释。 D S S数据仓库活动监
控程序必须能提供多种不同的解释。
在数据仓库环境中使用监控程序的一个根本问题是在哪儿进行监控。能进行监控工作的
一个地方是最终用户终端。这是做监控工作的一个方便位置，因为这里有很多空闲的机器周
期，并且在这里进行监控工作对系统性能只有很小的影响。但是，在最终用户终端监控系统
意味着每个被监控的终端需要自己的管理员。在一个单独的 DSS网络中，可能有多达 10 000台
终端，试图管理每个终端的监控工作几乎是不可能的。
另一个途径是在服务器层次对 D S S系统进行监控。在查询已形式化并且已经传给管理数
据仓库的服务器后，才开始进行监控。毫无疑问，在此处管理监控程序要容易得多。但是存
在系统范围内性能下降的很大可能性。因为监控程序使用服务器资源，监控程序影响整个
D S S数据仓库环境的工作性能。监控程序的位置是必须仔细考虑的重要问题，要在管理的方
便性和降低性能之间进行权衡。
监控程序最有效的用途之一是能够将今天的结果与每天平均的结果进行比较。发现异常
时，能够问一句“今天与每天平均的结果有什么不同？”这通常是有好处的。在大多数情况
下会发现性能变化不象想象中那么坏。但为了做这样的比较，需要一个“每天平均概况”。
“每天平均概况”包括了 D S S环境中描述一天情况的各种标准的重要度量指标。一旦对当天的
情况进行了度量，就可以与每天平均概况进行比较。
当然，每天平均值总是随时在变化的。定期地追踪这些变化，使得对长期系统趋势能够
进行度量将是有意义的。
1.13 小结
本章讨论了体系结构问题，数据仓库适合于采用这种体系结构。这种体系结构的演化贯
穿于信息处理不同阶段的整个历史。在这种体系结构中有四个数据及处理层次 — 操作层，
数据仓库层，部门层和个体层。
下载
第2章数据仓库环境
数据仓库是体系结构设计环境的核心，是决策支持系统 ( D S S )处理的基础。因为在数据仓
库中只有单一集成的数据资源，并且因为数据是可访问的，所以与传统数据环境相比，在数
据仓库环境中DSS分析员的工作将要容易得多。
本章将叙述数据仓库问题的一些重要特性。
数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用来支持管
理人员的决策。
数据仓库的面向主题性，如图 2-1所示。
面向主题
操作型环境数据仓库
汽车顾客
人寿保险单
健康保险费
意外伤亡索赔
应用主题
图2-1 数据面向主题的一个例子
传统的操作型系统是围绕公司的应用进行组织的。对一个保险公司来说，应用问题可能
是汽车保险、健康保险、人寿保险与意外伤亡保险。公司的主要主题范围可能是顾客、保险
单、保险费与索赔。
数据仓库的第二个显著特点是集成的。在数据仓库的所有特性之中，这是最重要的。图
2-2说明了当数据由面向应用的操作型环境向数据仓库传送时所进行的集成。
应用问题的设计人员历经多年制定出来的不同的设计决策有很多很多种不同的表示方法，
没有什么应用在编码、命名习惯、实际属性、属性度量等方面是一致的，各个应用问题设计
下载
第2章数据仓库环境 21
员自由地做出他或她自己的设计决策。
当数据进入数据仓库时，要采用某种方法来消除应用问题中的许多不一致性。例如，在
图2-2中，考虑关于“性别”的编码，在数据仓库中是编码为 m/f还是1/0并不重要，重要的是，
无论什么原始应用问题，无论数据仓库如何进行编码，在数据仓库中应该一致地进行编码。
如果应用数据编码为 X/Y，当其进入数据仓库时就要进行转换。对所有的应用设计问题都要考
虑同样的一致性处理，比如命名习惯、键码结构、属性度量以及数据特点等。
数据仓库的第三个重要特性是数据仓库是非易失的。图 2-3说明了数据的非易失性。
集成
编码
应用A m, f
m, f
应用B 1, 0
应用C x, y
应用D 男，女
属性度量
应用A 管道—cm
应用B 管道—inches 管道—cm
应用C 管道—mcf
应用D 管道—yds
多重信息源
应用A 描述
应用B 描述
描述
应用C 描述
应用D 描述
冲突的键码
应用A 键码char(10)
应用B 键码dec fixed(9, 2)
键码char(12)
应用C 键码pic‘9999999’
应用D 键码char(12)
图2-2 集成问题
非易失性
插入修改
访问
删除删除
载入
访问
插入修改
数据的逐个记录方式处理数据的批量载入/访问
图2-3 非易失性问题
22 数据仓库
下载
图2 - 3表示了操作型数据正规地是一次访问和处理一个记录。可以对操作型环境中的数据
进行更新。但数据仓库中的数据呈现出非常不同的特性。数据仓库的数据通常是一起载入与
访问的，但在数据仓库环境中并不进行一般意义上的数据更新。
数据仓库的最后一个显著特性是其随时间的变化性。如图 2 - 4所示。数据仓库中的数据随
时间变化的特性表现在以下几个方面：
■ 数据仓库中的数据时间期限要远远长于操作型系统中的数据时间期限。操作型系统的
时间期限一般是 60～90天，而数据仓库中数据的时间期限通常是 5～10年。
■ 操作型数据库含有“当前值”的数据，这些数据的准确性在访问时是有效的，同样当
前值的数据能被更新。而数据仓库中的数据仅仅是一系列某一时刻生成的复杂的快照。
■ 操作型数据的键码结构可能包含也可能不包含时间元素，如年、月、日等。而数据仓
库的键码结构总是包含某时间元素。
时间的变化
• 时间期限：当前到60～90天 • 时间期限：5～10年
• 记录更新 • 数据的复杂快照
• 键码结构可能包括/也可能不包括时间元素 • 键码结构包括时间元素
图2-4 随时间的变化问题
2.1 数据仓库的结构
数据仓库的结构如图 2-5所示。图2-5表明，在数据仓库中数据存在着不同的细节级：早期
生产线每月销售
高度综合级
1981～1992
轻度综合级
(数据集市) 子生产线
元
每周销售
1984～1992
数
据销售细节级
当前细节级
1990～1991
销售细节级
操作型转换
早期细节级 1984～1989
图2-5 数据仓库的结构
下载
细节级(通常是备用的、批量的存储 )、当前细节级、轻度综合数据级 (数据集市 )以及高度综合
数据级。数据是由操作型环境导入数据仓库的。相当数量的数据转换通常发生在由操作型级
别向数据仓库级别传输过程中。
一旦数据过期，就由当前细节级进入早期细节级。综合后的数据由当前细节级进入轻度
综合数据级，然后由轻度综合数据级进入高度综合数据级。
2.2 面向主题
顾客主题
基本顾客数据基本顾客数据顾客活动

1985～1987 1988～1990 1986～1989
customer ID customer ID customer ID

from date from data month
to date to date number of transactions
name name average tx amount
address address tx high
phone credit rating tx low
dob employer txs cancelled
sex dob …
… sex
…
顾客活动细节顾客活动细节
1987～1989 1990～1991
customer ID customer ID
activity date activity date
amount amount
location location
for item order no
invoice no line item no
clerk ID sales amount
order no invoice no
… deliver to
…
图2-6 数据仓库数据用主要主题领域(这里用顾客)来组织
24 数据仓库
下载
数据仓库是面向在数据模型中已定义好的公司的主要主题领域的。典型的主题领域包括：
■ 顾客。
■ 产品。
■ 事务或活动。
■ 保险单。
■ 索赔。
■ 帐目。
在数据仓库中，主要主题领域是以一组相关的表来具体实现的。例如，一个顾客主题的
实现可能像图2-6所示。
在图2 - 6中有五个相关的表，每个表设计用来实现作为顾客这个主要主题领域的一部分。
有一张从 1 9 8 5年～1 9 8 7年定义的顾客信息基本表，另有一张 1 9 8 8年～1 9 9 0年之间的顾客数据
定义基本表。有一张 1 9 8 6年～1 9 8 9年间的累积的顾客活动表。根据顾客每月的活动，针对每
个顾客记录编制一张月度总结记录表。
这里我们有从 1 9 8 7年～1 9 8 9年和从 1 9 9 0年～1 9 9 1年的顾客的详细活动文件。文件中数据
的定义因年份不同而不同。
一个顾客的所有表通过一个公共键码联系起来，图 2 - 7表明了用公共键码顾客标识号
… …
…
…
…
图2-7 属于相同主题域的数据集合由一个公共键码联系起来
下载
(customer ID)将在顾客主题领域中所找到的所有数据联系起来。顾客主题领域另一个有趣的
特征是其数据可以存储在不同的介质上，如图 2-8所示。
顾客
基本顾客数据
1988～1990
基本顾客数据顾客活动
1985～1987 1986～1989
顾客活动细节顾客活动细节
1987～1989 1990～1991
图2-8 数据仓库中主题领域可能包含不同介质上的数据
图2 - 8表明有的数据存储在直接存取存储设备 ( D A S D )上，有的数据存储在磁带上。数据
存储在不同介质上意味着在数据仓库中可能有多个数据库管理系统 ( D B M S )对数据进行管理，
或者某些数据根本没有被某个 D B M S管理。不能仅仅因为数据存储在磁带上，就认为它不是
数据仓库的一部分。
访问概率高且存储空间小的数据存放在快速且相对昂贵的存储介质上；访问概率低且存
储空间大的数据存放在廉价、慢速的存储介质上。
通常，D A S D和磁带是数据仓库中两种最常见的数据存储介质，但并非只能用这些介质，
另外两个不可忽视的介质是缩微胶片和光盘。缩微胶片适于存储详细的且无需在电子媒体
中再次复制的记录，合法的记录经常在缩微胶片上存放一个不确定的时期。光盘特别适合
于用作数据仓库的存储介质，因为它价廉、速度较快且能存储大量的数据。另外因为数据
仓库中的数据一旦载入几乎从来不用更新，这个特征使光盘存储成为数据仓库非常理想的
选择。
这些文件 (如图2 - 8所示)另一个有趣的特征是相同的数据既有综合级，又有细节级。每月
活动是综合的。同时，支持每月活动的细节存放在数据的磁带级上。这就是后面要讨论的
“粒度转换”的一种形式。
当数据围绕顾客这个主题组织时，每个键码都有一个时间元素。如图 2-9所示。
一些表是在“从日期到日期”的基础上进行组织的，称之为数据的连续组织。另一
些表是在“每月累积”的基础上进行组织的。还有一些是在“记录或活动的单独日期”
的基础上组织的。但是，所有记录都有某种形式的日期连接到键码，通常是键码的较低
部分。
26 数据仓库
下载
… …
…
…
…
图2-9 数据仓库中每个表都有时间元素作为键码结构的一部分(通常为较低的部分)
2.3 第1天到第n天的现象
建立数据仓库不是一蹴而就的。相反，数据仓库只能一次一步地进行设计和载入数据，
即它是进化性的，而非革命性的。突然建立一个数据仓库的费用、需要的资源和对环境的破
坏，都表明数据仓库的建立要采用有序地反复和一次一步的方式。
图2 - 1 0说明一个建立数据仓库的典型过程。第 1天，通晓本质上进行操作型处理的几个系
统。第2天，对数据仓库中第一个主题领域的最初几个表载入数据，此时就会产生一定的好奇
心，用户开始发现数据仓库和分析处理。
第3天，更多的数据载入数据仓库，并且随着数据量增大，将吸引更多的用户。一旦用户
发现有较容易载入的集成数据源，并有在时间维上观察数据的历史基础，这就不仅仅是好奇
心了。大约此时，认真的 DSS分析员渐渐地被吸引到数据仓库中。
第4天，随着更多的数据载入数据仓库，一批存储在操作型环境的数据被适当地放入数据
仓库中。现在，我们就“发现”数据仓库是可用来进行分析处理的信息源。各种各样的 D S S
应用出现了。的确，伴随着现在存入数据仓库的大规模数据，此时开始出现如此多的用户和
如此多的处理请求，以致于一些用户进入数据仓库的要求和分析工作被推迟。进入数据仓库
的竞争成为使用数据仓库的障碍。
第5天，部门数据库 (数据集市，或 O L A P )开始兴起，各部门发现通过把数据从数据仓库
输入它们自己的部门处理环境，会使它们的处理既便宜又容易。到达部门级的数据吸引着一
下载
第1天
现存系统
数据仓库
第2天
第一个主题领域
现存系统
第3天更多的主题
现存系统
第4天数据仓库开始完全载入，
访问它成为一个问题
现存系统
第5天
数据仓库增长，部门级处
理开始兴起
现存系统
更多的数据注入数据
第6天
仓库，较多注意力集
中在部门数据，因为
操作型
它较易得到
第n天
操作型
图2-10 第1天到第n天的现象
些DSS分析员。
第6天，部门系统出现繁忙，得到部门数据比获得数据仓库的数据更便宜、更快、更容易。
很快最终用户就放弃数据仓库的细节，去进行部门处理。
第n天，这种体系结构得到充分发展。生产系统的原始集合中只剩下操作型处理。数据仓
库具有丰富的数据，并有一些数据仓库的直接用户和许多部门数据库。因为在部门级上获得
28 数据仓库
下载
处理所需要的数据既容易又便宜，所以大部分 DSS分析处理都在部门级进行。
当然，从第 1天到第 n天的进化需要很长的时间，通常需要几年。并且在从第 1天到第 n天
的处理过程中， DSS环境在不断地提高和职能化。
(正常情况下，此时会发现蜘蛛网开始发展成为一个更大、更壮观的形式。但情况并非完
全如此，尽管解释起来相当复杂。要了解进一步深入的解释，请参考“ The cabinet eff c c t”，
Data Base Programming Design,May 1991。)
2.4 粒度
粒度问题是设计数据仓库的一个最重要方面。粒度是指数据仓库的数据单位中保存数据的
细化或综合程度的级别。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。
数据的粒度一直是一个设计问题。在早期建立的操作型系统中，粒度是用于访问授权的。
当详细的数据被更新时，几乎总是把它存放在最低粒度级上。但在数据仓库环境中，对粒度
不作假设。图2-11说明了粒度问题。
在数据仓库环境中粒度之所以是主要的设计问题，是因为它深深地影响存放在数据仓库
中的数据量的大小，同时影响数据仓库所能回答的查询类型。在数据仓库中的数据量大小与
查询的详细程度之间要作出权衡。
粒度 — 细节的级别
高细节级 — 低粒度级低细节级 — 高粒度级

例如：一个顾客一个月内的例如：一个顾客一个月内的
每个电话的细节电话的综合
a)
数据的分割
• 将数据分成小的单元
• 在应用层或 DBMS层进行
难以管理容易管理
b)
图2-11 数据仓库主要设计问题: 粒度、分割和适当设计

下载
2.4.1 粒度的一个例子
图2 - 1 2表示了粒度问题的一个例子。左边是一个低粒度级，每个活动 (在这里是一次电话 )
被详细记录下来，数据的格式如图所示。到月底每个顾客平均有 2 0 0条记录 (全月中每个电话
都记录一次 )，因而总共需要 40 000个字节。
该图的右边是一个高粒度级。数据代表一位顾客一个月的综合信息，每位顾客一个月只
有一个记录，这样的记录大约只需 200个字节，记录的格式如图所示。
显然，如果数据仓库的空间很有限的话 (数据量总是数据仓库中的首要问题 )，用高粒度级
表示数据将比用低粒度级表示数据的效率要高得多。
高粒度级不仅只需要少得多的字节存放数据，而且只需要较少的索引项。然而数据量大
小和原始空间问题不是仅有的应考虑的问题。为了访问大量数据，其处理能力的大小同样也
是应考虑的一个因素。
所以，在数据仓库中数据压缩非常有用。当数据被压缩后就会大大节省所用的 DASD存储
空间，节省所需的索引项，以及节省处理数据的处理器资源。
但是，当提高粒度级时，数据压缩就会出现另一个问题，图 2-13表示作出的选择。
在图2-13中,当提高数据粒度级时,数据所能回答查询的能力就会随之降低。换句话说,在一个
很低的粒度级上你实际可以回答任何问题,但在高粒度级上,数据所能处理的问题的数量是有限的。
粒度
高细节级低细节级
例如:一个顾客一个月的例如:一个顾客一个月的
每个电话的细节电话综合
每月40 000 个字节 200个字节

每月200个记录每月一个记录
图2-12 确定粒度级是数据仓库环境中最重要的设计问题
30 数据仓库
下载
粒度
例如：一个顾客一个月的例如：一个顾客一个月的
每个电话的细节电话综合
“Cass Squire上星期是否给他在波士顿的
女友打了电话？”
• 能回答，尽管需要一定 • 根本就不能回答。
数量的检索细节已经消失
但寻找单个记录是个非常不常见的事件
“上个月，人们从华盛顿打出的长途电话
平均有多少个？”
搜寻175 000 000个记录, 搜寻1 750 000个记录,

进行45 000 000 次I/O 进行 450 000次I/O
图2-13 粒度级对能回答什么问题和回答问题所需什么资源有深刻的影响
在图2-13中提出了下面的问题：
“Cass Squire上星期是否给他在波士顿的女友打了电话？”
在低粒度级上，这个问题是可以回答的，虽然这种回答将花费大量资源去查阅大量的记
录，但是Cass上周是否给他在波士顿的女友打了电话最终总是可以确定的。
然而，在高粒度级上就无法明确地回答这个问题。假如在数据仓库中存放的只是 Cass
Squire打的电话总数，那么就不能确定其中是否有一个电话是打往波士顿的。
但是，在进行 D S S处理时(这在数据仓库环境中是常见的 )，很少对单个事件进行检查。通
常是针对某种数据集合进行处理的，这意味着要查阅大量记录。
例如，假设提出下面的集合性查询问题：
“上个月人们从华盛顿打出的长途电话平均多少个？”
在一个DSS环境中这种查询类型是非常常见的。当然，它既可以在高粒度级上也可以在低
粒度级上得到回答。但在回答这个问题时，在不同的粒度级上所使用的资源具有相当大的差
下载
异。在低粒度级上回答这个问题需要查询每一个记录，所以需要大量的资源来回答这个问题。
但在高粒度级上，数据进行了很大的压缩，而且能够提供一个答案。如果在高粒度级上
包括了足够的细节，则使用高粒度级数据的效率将会高得多。
在管理数据的粒度问题中的权衡如图 2 - 1 4所示。在设计和构造数据仓库之初就必须仔细
考虑这种权衡。
灵活—能被处理的足够小的数
细节级—回答任何问题
据量
大数据量
小数据量
图2-14 粒度的权衡是首要的，所以大多数组织的最佳
解决办法是采用多重粒度级的形式
2.4.2 粒度的双重级别
很多时候，十分需要提高存储与访问数据的效率，以及非常详细地分析数据的能力。 (换
句话说，机构想有自己的蛋糕，并且吃了它！ )当一个企业或组织的数据仓库中拥有大量数据
时，在数据仓库的细节部分考虑双重 (或多重)粒度级是很有意义的。事实上，需要多个粒度级
而不是一个粒度级的需求，是因为粒度级设计采用双重级别应该是几乎每个机构默认的选择。
图2-15表明了在数据仓库的细节级上的两种粒度级。
图2 - 1 5所示(一家电话公司 )的我们称之为“双重”粒度级的设计，能满足大多数机构的需
要。在操作层是大量的细节，其中大部分细节是为了满足结帐系统的需求。多达 3 0多天的细
节存放在这种操作层中。
在这个例中的数据仓库包括两种类型的数据：轻度综合数据和“真实档案”细节数据。
数据仓库中的数据能回溯十年。从数据仓库中提取的数据是流向电话公司不同地区的“地
区”数据，然后各地区独立地分析各自的数据。在个体级上进行各自的启发式分析处理。
什么是轻度综合级，现在可能还不是很明显。图 2-16表明了一种轻度综合级。
当数据从操作型环境 (存储3 0天的数据 )载入时，它就被顾客综合成可能用于 D S S分析的数
据域。 J . J o n e s的记录显示她每月打电话的次数、每个电话的平均长度、长途电话的次数、接
线员帮助呼叫的次数，等等。
在轻度综合数据库中的数据量比细节数据库中的数据量少得多。当然，在轻度综合级数
32 数据仓库
下载
一个电话公司
粒度的双重级
• 30 天详细电话历史 10年电话历史逐个地区活动分析处理

• 其他顾客活动
轻度综合
在数据仓库层管理大量数据
真实档案
图2-15 大量数据使得大部分组织在数据仓库中需要两个粒度级
轻度综合数据
30天的细节轻度综合
J Jones 4月15日上午11:01～11:21 四月份

4月12日下午6:01～6:12 415-964-4738 J Jones
415-566-9982 接线员帮助 4月15日上午11:39～12:01 电话数量—45个
4月12日下午6:15～6:16 703-570-5770 未接通电话的平均长度—14分钟
415-334-8847 长途 4月15日下午12:10～12:46
长途电话数—18个
4月12日下午6:23～9:38 703-841-5770 号码错误
接线员帮助呼叫数—2个
408-223-7745 4月16日下午12:34～12:56
4月13日上午9:12～9:23 未接通电话数—1个
415-964-3130
408-223-7745 …… 存储1个记录所需的字节数—225
4月13日上午10:15～10:21
408-223-7745 接线员帮助
每月一个顾客存储200个记录平均需要的字节数—45 000
图2-16 采用数据的轻度综合，使大量的数据可简洁地表示
下载
据库中，对能访问的细节级存在一定的限制。
数据仓库中数据的第二层 — 最低粒度级 — 存放在数据的真实档案层上，如图 2 - 1 7所
示。
轻度综合
四月份
J Jones
电话次数—45个
电话的平均长度—14分钟
长途电话次数—18个
接线员帮助呼叫次数—2个
未接通电话次数—1个
J Jones 95%甚至更多的 DSS处理

4月12日下午6:01～6:12 在此进行
415-566-9982 接线员帮助
4月12日下午6:15～6:16
真实档案 5%或更少的DSS处理
415-334-8847 长途
4月12日下午6:23～6:38 在此进行
408-223-7745
4月13日上午9:12～9:23 • 耗费时间
408-223-7745 • 复杂
4月13日上午10:15～10:21 • 费用高
408-223-7745 接线员帮助
4月15日上午11:01～11:21
415-964-4738
4月15日上午11:39～12:01
703-570-5770 未接通
4月15日下午12:10～12:46
703-841-5770 号码错误
4月16日下午12:34～12:56
415-964-3130
……
图2-17 双重粒度级可有效地处理绝大多数的请求，并回答任何能够
回答的问题。这是最好的并且应作为默认的设计选择
在数据的真实档案层上，存储的所有的细节来自于操作型环境。在这一层上确实有大量
的数据。由于数据量太大，因此有必要将数据存放在如磁带这样的介质上。
通过在数据仓库的细节级上创建两种粒度级， DSS设计者可一举两得。大部分 DSS处理是
针对被压缩的、存取效率高的轻度综合级数据进行的。如果什么时候需要分析更低的细节级
( 5 %时间或更少的可能 )，可以到数据的真实档案层。在粒度真实档案层上，访问数据将是昂
贵的、麻烦的和复杂的事情，但如果必须进入这一细节级也只得如此。
随着时间的迁移，如果需要开发某种搜索数据的真实档案级的模式，设计者可能要在轻
度综合级上创建某些新数据域。
鉴于费用、效率、访问便利和能够回答任何可以回答的查询的能力，数据双重粒度级是
大多数机构建造数据仓库细节级的最好选择。只有当一个机构的数据仓库环境中只有相对较
34 数据仓库
下载
少的数据时，才应尝试采用数据粒度的单一级别。
2.5 分割问题
分割是数据仓库中数据的第二个主要的设计问题 (在粒度问题之后 )，如图 2 - 11 b所示。数

据分割是指把数据分散到各自的物理单元中去，它们能独立地处理。在数据仓库中，围绕分
割问题的焦点不是该不该分割而是如何去分割的问题。
人们常说，如果粒度和分割都做得很好的话，则数据仓库设计和实现的几乎所有其他问
题都容易解决。但是，假如粒度处理不当并且分割也没有认真地设计与实现，这将使其他方
面的设计难以真正实现。
当然，数据仓库还有其他设计问题，将在后面章节进行讨论。
2.6 样本数据库
样本数据库是数据仓库的一种有趣的、混杂的形式，它只是真实档案数据或轻度综合数
据的子集。术语“样本”源于它是更大数据库的子集 (即样本)这一事实，并需要进行定期刷新。
图2-18显示了一个样本数据库。
数据仓库
“所有的保险客户中，有多少是己婚且
具有大学学历的 35岁以上的男性？”
样本数据库 • 仓库中的一部分数据
• 用于查询的非常有效的形式
• 不能用于一般目的的分析 — 只能用于统计分析
图2-18 样本数据库— 另一种改变数据粒度的方法
在某些情况下 (如人口统计分析 )，样本数据库是非常有用的。但是对使用样本数据库有一

些苛刻的限制。除非设计者知道这些限制，否则就不应该创建这种数据库以作为数据仓库的
一部分。
样本数据库不是通用的数据库。假如你想知道“ J . J o n e s是不是顾客？”你就不要在样本
数据库中找这条信息。完全可能， J . J o n e s是一个顾客，但她不在样本数据库的记录中。样本
数据库适用于作统计分析和观察发展趋势。当数据必须以整体观察时，样本数据库能提供非
常理想的结果，但决不适用于处理单个的数据记录。
现在看一下样本数据库的数据通常是如何载入的？它是用一个程序搜寻一个大规模的数
据库，选取 1 / 1 0 0或1 / 1 0 0 0的记录，然后将这些记录送到样本数据库。于是最终样本数据库的
大小将是原先数据库的 1/100或1/1000。
样本记录的选取一般是随机的，必要时可采用一个“判断样本” (即记录必须达到一定标
下载
准才能被选中 )。判断样本所带来的问题是会使样本数据具有某种偏差，随机抽取数据带来的
问题是可能无法进行统计。无论如何，数据是选择作为样本的，所以在样本数据库中找不到
任何给定的记录这一事实是说明不了任何问题的。
样本数据库的最大好处是存取效率非常高。即使只是从一个大数据库中抽取了很小的一
部分，对它进行访问和分析也相对地有效得多。
换句话说，一个分析员可能花 2 4小时来浏阅与分析一个大数据库，而浏览与分析一个样
本数据库则可能只需 1 0分钟。在进行启发式分析中，周转时间对可以进行的分析而言是至关
重要的。在启发式分析中，分析员运行程序、分析结果、修改程序、再运行程序。如果执行
程序就花去 24小时，分析和修改程序的过程就会大大地削弱了 (更不用说修改所需的资源 )。
但如使用一个 1 0分钟内就足以浏览完的样本数据库，分析员就能很快地完成这种重复过
程。总之， DSS分析员的生产效率是由进行整个分析过程的速度来决定的。
有一种说法认为进行统计分析会导致错误的结论。现在来看一种情况：当分析员遇到一
个大文件，用 325 000 000条记录确定 5 6 . 7 %上路的汽车司机是男人，而使用样本数据库，分
析员用了 25 000个记录确定 55.9%上路的汽车司机是男人。前一种分析比后一种分析需要的资
源要大得多，而它们计算出的结论却差别非常非常小。毫无疑问，用大规模数据库进行分析
会比较精确，但这种精确的代价实在太高了，尤其在进行启发式处理时，通常要进行循环往
复的处理。
如果需要非常高的精确度，行之有效的方法是将要求形式化，并在样本数据库上进行反
复处理。这样做， D S S分析员就可较快地将要求形式化。当要求被理解后，再在大规模数据
库上仅运行最后一次。
采用样本数据是另一种在数据仓库中改变粒度级以便于进行 DSS处理的方法。
2.7 数据分割
在数据仓库环境中，问题不是要不要对当前细节数据进行分割，而是怎样对当前细节数
据进行分割。图 2-19说明了数据分割。
对当前细节数据进行分割的总体目的是把数据划分成小的物理单元。数据分割为什么如
此重要呢？因为小的物理单元能为操作者和设计者在管理数据时提供比对大的物理单元更大
的灵活性。
当数据存放在大的物理单元中时，尤其不能达到：
■ 容易重构。
■ 自由索引。
■ 顺序扫描(若需要)。
■ 容易重组。
■ 容易恢复。
■ 容易监控。
简单地说，数据仓库的本质之一就是灵活地访问数据。如果是大块的数据，就达不到这
一要求。因而，对所有当前细节的数据仓库数据都要进行分割。
分割数据的准确含义是什么呢？当结构相同的数据被分成多个数据物理单元时，数据便
被分割了。此外，任何给定的数据单元属于且仅属于一个分割。
36 数据仓库
下载
数据分割
小的数据单元能被：
• 重构
• 索引
• 顺序扫描(若需要)
• 重组
• 恢复
• 监控
1989
1988
数据的独立管理单元
可以有不同的定义
1990
1991
1987
处理集A
处理集B
图2-19 独立管理的数据分割可送到不同的处理集，而无须顾及其他的系统考虑
有多种数据分割的标准。例如，按：
■ 时间。
■ 商业线。
■ 地理位置。
■ 组织单位。
■ 所有上述标准。
数据分割的标准是严格地由开发人员来选择的。然而，在数据仓库环境中，按日期几乎
总是分割标准中的一个必然组成部分。
将人寿保险公司如何选择数据分割标准作为一个例子，来看看下列的数据物理单元：
■ 1988年健康索赔。
下载
■ 1987年人寿保险索赔。
■ 1988年意外伤亡索赔。
这个保险公司使用了日期即年和索赔类型作为标准来分割数据。
数据仓库开发人员面临的主要问题之一是在系统层上还是在应用层上对数据进行分割。
在系统层上进行分割在一定程度上是某些 D B M S和操作系统的一种功能。在应用层上进行分
割是由设计的应用程序代码完成的，这是只由开发者和程序员严格地控制的。当在应用层上
进行数据分割时， DBMS和系统就不知道一种分割与另一种分割之间的关系。
通常，在应用层上分割数据仓库的数据是很有意义的。这是有某些重要原因的，最重要
的是在应用层上每年的数据可以有不同的定义。 1 9 8 8年和1 9 8 9年的数据定义，可以相同也可
以不相同。仓库中数据的性质是长期数据积累的结果。
当数据在系统层上分割时， D B M S不可避免地希望只有一种数据定义。假定数据仓库中
保存的数据时间较长 (如达到十年 )，而且数据定义经常变化，让 DBMS或操作系统去管理一个
本该只有一种数据定义的系统将是毫无意义的。
在应用层上管理数据分割的另一重要特点是它能从一个处理集转移到另一个处理集而没
有损失。在数据仓库环境中，当工作负载和数据量成为真正的负担时，这种特点就是一种真
正的优点。
对数据分割最严峻的检验是提出这样的问题：“能否在分割中加入索引而不会明显地妨碍
其他操作？”如果一种索引能随意加上去的话，那么这种分块就足够理想了。如果索引还不
能很容易地加入，那么这个分块还得分得更精细一点。
2.8 数据仓库中的数据组织
迄今为止，我们还没有详细研究数据仓库中所建立的数据结构是怎样的。数据仓库中有
多种数据组织形式，我们将讨论几类比较常见的结构。
数据仓库中最简单最常用的数据组织形式也许是简单堆积结构，如图 2-20所示。
图2 - 2 0表示了从操作型环境中取出每天的事务处理，然后综合成数据仓库记录，这个综
合可根据顾客、帐目或者任何组织到数据仓库的主题领域来进行。这里的事务处理是以天来
进行综合。换句话说，对一个顾客的一个帐号的每天的所有活动进行合计，并在一天一天的
基础上输入数据仓库。
图2-21表示简单逐日堆积数据的一种变种，称之为轮转综合数据存储。
数据用与前面相同的处理方法从操作型环境输入到数据仓库环境中。只是在轮转综合文
件中的数据才被输入到不同的结构形式中。第一周的七天中的活动被逐一综合到七个每日相
应的位置，到第八天，将七个每日位置的数据加到一起，并放入第一周的数据位置中。然后，
第八天的每日总计加到第一个每日数据位置。
38 数据仓库
下载
简单堆积数据
每日事务处理
操作型数据每日综合
1月1日１月2日 1月3日 …
2月1日 2月2日 2月3日 …
3月1日 3月2日 3月3日 …

……
图2-20 数据仓库中最简单的数据组织形式是以逐个记录为基础的数据堆积 — 简单堆积数据
月底将每周位置的数据加到一起，并放入第一个每月相应的数据位置处，然后每周数据
位置清零。到了年底，将每月位置数据加到一起，放入第一个年度相应的数据位置处，然后
每月数据位置清零。
每日事务处理
操作型数据每日综合
第1天第2天第3天 … 第7天
第1周第2周第3周 … 第5周
第1月第2月第3月 … 第12月
第1年第2年第3年 … 第n年
图2-21 轮转综合文件是简单堆积文件的变种
轮转综合数据结构与数据的简单堆积结构相比，仅处理非常少的数据单元。它们之间的
优缺点比较如图 2-22所示。
下载
数据仓库数据的另外一种组织形式是简单直接文件，如图 2-23所示。
轮转综合数据
第1天第2天第3天 … 第7天

• 非常紧凑
第1周第2周第3周 … 第5周 • 一些细节丢失
• 提取越久的数据，越不详细
第1月第2月第3月 … 第12月
第1年第2年第3年 … 第n年
简单堆积数据
1月1日 1月2日 1月3日 … • 需要许多存储空间

• 无细节丢失
2月1日 2月2日 2月3日 …
• 许多处理与数据有关
3月1日 3月2日 3月3日 …
…………
图2-22 轮转综合数据与简单堆积数据的比较
1月份顾客
J Adams 123 Main Street

P Anderson 456 High Street
K Appleby 10 AStreet
L Azimoff 64 N Ranch Rd
…… ……
操作型数据
图2-23 简单直接文件—另外一种数据仓库的结构
图2 - 2 3表明，数据仅仅是从操作型环境拖入数据仓库环境中，并没有任何累积。另外，
简单直接文件不是在每天的基础上组织的，而是以较长时间为单位的，比如一个星期或一个
月。因此，简单直接文件是间隔一定时间的操作型数据的一个快照。
依据两个或更多的简单直接文件能生成一种连续文件。图 2 - 2 4是把1月份和 2月份的两个
数据快照合并，创建数据的一个连续文件。连续文件中的数据代表从第一个月到最后一个月
的连续数据。
当然，连续文件也可以通过把一个快照追加到一个以前生成的连续文件上来创建，如图
2-25所示。
数据仓库中有许多其他的数据组织形式，最常用的是：
■ 简单堆积。
■ 轮转综合。
■ 简单直接。
■ 连续。
40 数据仓库
下载
1月份顾客 2月份顾客
J Adams 123 Main Street J Adams 123 Main Street

P Anderson 456 High Street W Abraham 12 Hwy 9
K Appleby 10 AStreet P Anderson 1455 Tincup Ct
L Azimoff 64 N Ranch Rd K Appleby 10 A Street
…… …… L Azimoff 64 N Ranch Rd
…… ……
J Adams 1月份至今 123 Main Street

W Abraham 2月份至今 12 Hwy 9
P Anderson 1月份 456 High Street
P Anderson 2月份至今 1455 Tincup Ct
K Appleby 1月份至今 10 A Street
L Azimoff 1月份至今 64 N Ranch Rd
…… …… ……
图2-24 从直接文件创建一个连续文件
连续文件 3月份顾客
J Adams 1月份至今 123 Main Street J Adams 123 Main Street

W Abraham 2月份至今 12 Hwy 9 W Abraham 12 Hwy 9
P Anderson 1月份 456 High Street K Appleby 10 A Street
P Anderson 2月份至今 1455 Tincup Ct L Azimoff 64 N Ranch Rd
K Appleby 1月份至今 10 A Street …… ……
J Adams 1月份至今 123 Main Street

W Abraham 2月份至今 12 Hwy 9
P Anderson 1月份 456 High Street
P Anderson 2月份至今 1455 Tincup Ct
K Appleby 1月份至今 10 A Street
…… …… ……
图2-25 由简单直接文件创建连续文件，或把简单直接文件追加到连续文件
下载
在键码层，数据仓库的键码不可避免地是复合键码，这有两种强制性的理由：
■ 日期 — 年、年/月、年/月/日，等等，几乎总是键码的一部分。
■ 因为数据仓库中的数据是分割的，分割的不同分量表现为键码的一部分。
2.9 数据仓库— 标准手册
数据仓库与许多人 (管理人员、 D S S分析员、开发人员、计划人员等 )相关。而在大多数机

构中，数据仓库还是个新事物。于是就需要有一个官方组织对数据仓库进行解释和说明。
称数据仓库说明为“标准手册”可能有点死气沉沉。标准手册里是一些枯燥的含义，并
以无人问津和布满灰尘而闻名。但是以某种内部形式发行还是很有价值的尝试。
这种出版物应该包括下列内容：
■ 描述什么是数据仓库。
■ 描述对数据仓库输送信息的源系统。
■ 如何使用数据仓库。
■ 有了问题如何获得帮助。
■ 谁负责什么。
■ 仓库的迁入计划。
■ 仓库数据如何与操作型数据相关联。
■ 如何为DSS使用仓库数据。
■ 什么时候不往仓库中加数据。
■ 仓库里没有什么类型的数据。
■ 可利用的元数据的指示。
■ 记录系统是什么。
2.10 审计和数据仓库
伴随数据仓库出现的一个有趣的问题是：是否能够或是否应该对数据仓库进行审计？答
案是能对数据仓库进行审计；已有进行详细审计的几个例子。然而有更多的理由表明，即使
能对数据仓库进行审计，也不应该从中进行审计。不进行这种审计的主要原因如下：
■ 原先在数据仓库中没有的数据会突然出现。
■ 当需要审计能力时，数据进入数据仓库的定时会发生急剧变化。
■ 当需要审计能力时，数据仓库的备份和恢复限制会发生急剧变化。
■ 在仓库中审计数据，会使仓库中数据的粒度处在一个非常的级别上。
总之，在数据仓库环境中进行审计是可能的。然而，审计带来的复杂性使得审计在其他
地方进行更有意义得多。
2.11 成本合理性
数据仓库的一个有趣的问题是：数据仓库的成本合理性通常不是在先验的投资回报率
( R O I )基础上来进行判断的。要做这样的分析，必须在创建数据仓库之前就知道数据仓库带来
的收益。
通常情况下，在创建数据仓库时，实际收益是不知道的甚至是无法预测的，因为数据仓
42 数据仓库
下载
库的使用方式完全不同于其他信息系统所构造的数据和系统。数据仓库的使用是用一种与其
他信息处理不同的模式进行的，有点像“告诉我，你想要的是什么，然后我才能告诉你你真
正想要的是什么”这种模式。直到数据仓库的首次循环设计过程完成并可以利用以前， D S S
分析员不能真正说出数据仓库的可能性和潜力有多大。一旦 D S S分析员插手仓库，他或她就
能开始揭示 DSS处理的潜力。
因此，经典的ROI技术不能应用到数据仓库环境中。幸运的是，数据仓库是渐进式地建立
的。第一次循环设计过程能很快完成，并且只需相对较少的费用。一旦数据仓库的第一部分
已经建立并载入数据，分析员就能开始研究可能性。只有在这个时候，分析员才能着手证明
仓库开发费用的合理性。
根据经验，数据仓库第一次循环的设计规模要适中，小到足以建成仓库，大到仓库是有
意义的。所以，数据仓库最好一次构造一个小规模的循环设计，并且在仓库开发人员与 D S S
分析员之间适当而且快速地建立直接反馈回路。
此外，这些理由也说明，为什么说若最初设计的数据仓库 5 0 %是精确的，那么设计就是
成功的。根据仓库开发人员与 D S S分析员之间的反馈回路将不断地修改现有的仓库数据，并
向仓库中追加其他新数据。
数据仓库典型的首选方向集中于以下这些主题领域之一：
■ 金融。
■ 市场。
■ 销售。
有时，数据仓库的首选主题领域会专注于：
■ 工程/制造。
■ 保险行业。
2.12 清理仓库数据
数据并非只是注入数据仓库，它在数据仓库中也有自己的生命周期。到了一定时候，数
据将从仓库中清除。数据清理问题是数据仓库设计人员无法回避的基本设计问题之一。
从某种意义上讲，数据根本不是从数据仓库中清除，而仅仅是上升到更高的综合级。数
据清理或数据细节转化主要有以下几种方式：
■ 数据加入到失去原有细节的一个轮转综合文件中。
■ 数据从高性能的介质 (如DASD)转移到大容量介质上。
■ 数据从系统中实际清除。
■ 数据从体系结构的一个层次转到另一个层次，比如从操作型层次转到数据仓库层次。
因而，在数据仓库环境之中有种种数据清理或者转化的方式。数据的生命周期 (包括清除
或最终档案转移 )应该是数据仓库设计过程中活跃的部分。
2.13 报表和体系结构设计环境
如果说一旦数据仓库建立起来，所有的报表和信息处理都将在此实现，这只是一种诱惑。
情况确实不是这样。恰如其分地应归属于操作型系统领域的，是一个正统的处理类别。图 2 -
26表明不同的处理风格应位于什么位置。
下载
图2 - 2 6显示，操作型报表是为办事层用的，并且焦点基本在行式项目上。数据仓库或信
息型处理的焦点在管理，包含综合或其他情况下的计算信息。在数据仓库中一旦基本数据计
算已经完成，报表格式很少使用行式项目、细节信息。
操作型报表数据仓库报表
• 行式项目是基本的；一旦 • 一旦使用，行式项目很少甚至没
• 使用，综合很少或不重要 • 有用；综合或其他计算非常重要
• 对于办事层人员是重要的 • 对于管理层人员是重要的
图2-26 两种报表的区别
2.14 机遇性的操作型窗口
数据仓库是 D S S处理的基础，包含的都是档案信息，而且大部分是至少 2 4小时以前的。

但是档案数据在体系结构设计环境中别的地方能找到，特别是在操作型环境中也能找到。
在数据仓库中，发现 5～1 0年这样漫长的档案数据是很常见的。由于时间范围的缘故，数
据仓库中存在有大量的数据。
在操作型环境中发现的档案数据的时间范围称之为数据的“操作型窗口”，它一般不很长，
只能从一个星期到两年。但是操作型环境中档案数据的时间范围，并不是档案数据在操作型
环境和在数据仓库环境的唯一区别。不同于数据仓库，操作型环境的档案数据不是大宗的，
并具有高访问率。
为了理解在操作型环境中刷新的、非大宗的、高访问率的档案数据的作用，考虑一家银
行的工作方式。在一个银行环境中，顾客有理由想要找到有关这个月事务处理的信息，如这
个月的租金支票清了没有？什么时侯进行的支票支付存款？这个月的结余是多少？银行是否
取钱交了上星期电费？
可以要求把非常细节的和新近的事务处理 (仍然是档案的 )包含在银行的操作型环境中。但
是指望银行告诉顾客“ 5年前是否给杂货店开过一张支票？”或“ 1 0年前一张竞选捐款支票是
否兑换成现金了？”这是不是合理的呢？这些处理很难在银行的操作型系统领域进行，不仅
因为这些处理已时间很久了，而且它们包含的数据具有非常低的访问率。
时间操作型窗口从一种行业到另一种行业是变化的，甚至一个行业内部的数据和活动类型
也是变化的。例如，一个保险公司可能有一个 2到3年这样漫长的操作型窗口。至少与其他类型
44 数据仓库
下载
行业相比，保险公司内部的事务处理率是很低的，在顾客和保险公司之间直接交互相对就更少。
相反，银行活动的操作型窗口非常短，一般从 0到60天，银行有许多与顾客之间的直接交互。
一家公司的操作型窗口由该公司属于什么类型的行业来决定。如果是个大公司，它可能
拥有不止一个操作型窗口，这是由所处理业务的细目决定的。例如，在一家电话公司里，顾
客使用数据可能拥有 30到60天的操作型窗口，而卖主 /供应商活动可能拥有 2到3年的窗口。
下面是不同类型行业档案数据操作型窗口的一些建议：
■ 保险公司： 2～3年
■ 银行信托处理： 2～5年
■ 电话公司
• 顾客使用： 30～60天
• 供应商/卖主活动： 2～3年
■ 普通银行
• 顾客帐目活动： 30天
• 卖主活动： 1年
• 贷款： 2～5年
■ 零售业
• SKU 活动： 1～14天
• 卖主活动 1周～1个月
■ 航空公司
• 航班座位活动 30～90天
• 卖主/供应商活动 1～2年
■ 公用事业
• 顾客使用 60～90天
• 供应商活动 1～5年
操作型窗口的长度对 D S S分析员而言是很重要的，因为它决定了分析员在哪里进行不同
的分析和能做什么类型的分析。例如， D S S分析员能对在操作型窗口里找到的数据进行单项
分析，而不能做大的趋势分析。操作型窗口的数据适于高效单个访问，只有当数据传出操作
型窗口时，才适于进行大量数据的存储和访问。
另一方面， D S S分析员能对在操作型窗口外找到的数据进行全盘趋势分析。在操作型窗
口之外的数据能被整体地访问和处理，而访问任何一个单个数据单位都是不理想的。
2.15 小结
本章叙述了数据仓库的面向主题，每个数据记录的随时间变化，以及通过公共键码的连
接。
能做出的两个最重要的设计决策是数据粒度和数据分割。对大多数机构而言，双重粒度
是很有意义的。数据分割通常是在应用层上而不是在系统层上将数据分成小的物理单元。
下载
第3章设计数据仓库
建造数据仓库有两个主要方面 — 与操作型系统接口的设计和数据仓库本身的设计。在某
种程度上来说，“设计”并不能精确描述在启发式方式下建造数据仓库时发生了什么。首先，
载入一部分数据，供 D S S分析员使用和查看。然后，根据最终用户的反馈，在数据仓库中修
改、增添一些数据。
这种反馈循环贯穿于整个数据仓库的开发过程。那种以为在建造数据仓库时，用过去曾
用的设计方法就可以满足需求的想法是错误的。在数据仓库部分载入并且为 D S S分析员使用
之前，数据仓库的需求是不可能知道的。因此，在设计数据仓库时，不能采用设计传统“需
求-驱动”系统同样的方法。在另一方面，那种认为不预测需求是好思路的想法也是错误的。
在实际中，通常是介于两者之间的。
3.1 从操作型数据开始
起初，现存系统中存储的是操作型数据。这就难免会让人认为建造数据仓库是一个抽取
操作型数据，然后将其输入数据仓库的过程。其他就没有什么要做的了。
图3 - 1简单描绘了从现有的系统环境中抽取出数据加入数据仓库的过程。可以看到有多个
应用程序对数据仓库作出贡献。
数据仓库
现有应用
图3-1 把数据从操作型环境移入数据仓库不是简单的抽取
认为图3 - 1过于简单是有多种理由的。认为建造数据仓库仅仅是数据的抽取过程的观点之
所以是错误的，主要是因为操作型环境中的数据是非集成的。图 3 - 2表明现存系统中缺乏数据
集成是很常见的。
在以前构造现有应用时，没有考虑到将来可能还要集成。每个应用系统都有其独立的、
特殊的需求，而且在开发过程中不曾考虑到其他的应用。因此毫不奇怪，在不同的地方用不
同的名字存放相同的数据；或一些数据在不同的应用中用同一方式标明，但仍然是同样的数
46 数据仓库
下载
据；或同一应用中某些数据用同样名字却用不同的度量，等等。试图从多处存在数据的地方
抽取数据是个非常复杂的问题。
存款 DDA 贷款信用
相同的数据，不同的数据这里出现，不同的关键字

不同的名字相同的名字那里不出现相同的数据
图3-2 跨越不同应用的数据集成性很差
这种缺乏集成的弊病正是程序员的梦魇。正如图 3 - 3所示，从操作型环境中适当地提取数
据的编程过程中有很多细节需要说明。
编码转换
数据仓库
应用 A-m , f
m,f
应用 B-l , o
应用 C-x , y
应用 D-male , female
度量单位转换
应用 A-pipeline-cm
应用 B-pipeline-in 数据仓库
应用 C-pipeline-mcf cm
应用 D-pipeline-yds
字段转换
应用 A-balance 数据仓库
应用 B-bal bal
应用 C-currbal
应用 D-balcurr
图3-3 为了合理地把数据从现有系统环境移动到数据仓库环境中，必须集成
例如，对“性别”字段，如果没有一致的数据类型，就是一个典型的缺乏集成性的例子：
在一个应用中，性别编码为“ m / f”，在另一个应用中的编码为“ 0 / 1”。其实，在数据仓库中
只要字段的编码方式一致，“性别”字段到底怎么编码没有什么关系。因为当数据加入到数据
仓库时，字段值必须正确地译码并且采用合适的值重新写进记录。
另一个综合集成的例子是针对开发人员的。考虑到四个应用中有同样的字段 P I P E L I N E，
但是每个应用中的度量是不一样的。在应用 A中用的是英寸，在应用 B中用的是厘米，等等。
其实，在数据仓库中只要 PIPELINE字段的度量单位一致，究竟用什么无关紧要。
下载
第3章设计数据仓库 47
字段转换是数据集成的又一个问题。例如同一字段在四个应用中有不同的名字。为了保
证转换到数据仓库的数据正确，必须建立不同源字段到数据仓库字段的映射。
这些简单的例子几乎还未涉及到集成的最浅层问题，例子本身也并不复杂。但是当它们
在很多的系统和文件中存在时，集成问题就成了十分复杂而又繁重的工作了。
但是，现存系统的集成 (或缺乏集成)并不是从操作型的现存系统到数据仓库系统中的数据
转换工作的唯一难点。另一主要问题是存取现存系统数据的效率。扫描现存系统的程序如何
知道一个文件已经被扫描过？现存系统环境中有大量的数据，每次数据仓库扫描时都试图对
这些数据扫描一次，将是极大的浪费，同时也是不现实的。
从操作型环境到数据仓库有三种装载工作要做：
• 装载档案数据；
• 装载在操作型系统中目前已有的数据；
• 将自数据库上次刷新以来在操作型环境中不断发生的变化 (更新)从操作型环境中装载到
数据仓库中。
一般来说，装载档案数据的难度不是很大，因为经常不做这项工作。不少企业发现，在
很多环境下，使用旧的数据在成本上是不合算的。
从现有的操作型系统中装载数据，由于只需要装载一次，所以难度也不大。通常现存系
统环境可以下载到一个顺序文件中，而这个顺序文件可以在不破坏联机环境的前提下下载到
数据仓库。
对数据设计者而言，在实时的情况下装载数据 — 操作型环境正发生变化 — 是最为困难
的。要有效地捕捉到那些变化并对之进行处理并非是一件容易的事。于是，扫描已有的文件
成了数据仓库体系结构设计者主要面对的问题。
时间戳
现有应用增量文件
现有应用
日志或审
计文件
现有应用
前映像后映像
上一次更
新后数据现有代码现有应用
库的改变
图3-4 你知道要怎样扫描数据？是否你每天、每周扫描每个数据
48 数据仓库
下载
有五种通用技术用于限制数据的扫描量，正如图 3 - 4所示。第一种技术是扫描那些被打上
时戳的数据。当一个应用对记录的最近一次变化或更改打上时戳时，数据仓库扫描就能够很
有效地进行，因为日期不相符的数据就接触不到了。然而，目前的数据被打上时戳的很少。
数据仓库抽取中限制数据扫描量的第二种技术是扫描增量文件。增量文件由应用程序生
成，仅仅记录应用中所发生的改变。有了增量文件，扫描的过程就会变得高效，因为不在候
选扫描集中的数据永远不会涉及到。但是，许多应用程序并没有创建增量文件。
第三种技术是扫描审计文件或日志文件。审计文件或日志文件记录的内容，本质上同增
量文件一样。不过，这里还是有一些重要的区别。由于恢复过程需要日志文件，所以各种操
作都要保护日志文件。把日志文件用于其他目的，对计算机的操作也无大碍。利用日志文件
的另一个困难是它内部格式是针对系统的用途而构造的，而不是针对应用程序的。这就需要
一种技术手段作为日志文件内容的接口。日志文件的另一个缺点是其中所包含的内容超出了
数据仓库开发人员所需要的。审计文件有许多与日志文件相同的缺点。
当数据仓库抽取数据时，控制扫描数据量的第四种技术是修改应用程序代码。这并不常
用，因为很多应用程序的代码陈旧而且不易修改。
最后一个选择 (很多情况下，是一个可怕的选择，其目的是使人们相信一定有更好的办法 )
是将一个“前”映象文件和一个“后”映象文件进行比较。使用这种方法，一开始抽取就对数
据库进行快照(snapshot)。进行另一个抽取时，就进行另一个快照。这两个快照逐次比较，以确
定哪个活动发生了。这种方法很麻烦、复杂，还需要各种各样的资源。这只不过是最后的手段。
但是，集成和性能并不是仅有的两个使得简单的抽取过程无法用于构造数据仓库的主要
问题。第三个主要困难是时基变化，如图 3-5所示。
时基的转移
当前值
当前值日余额
当前值
当前值
日余额
当前值
当前值
当前值日余额
一个事务成功的完成产生一个新的余额一天结束时产生的余额
图3-5 当数据从操作型环境移动到数据仓库环境时，需要时基的转移
现存的操作型数据通常是当前值数据。当前值数据在被访问的时刻其精度是有效的，而
且是可更新的。但是数据仓库中的数据是不能更新的。这些数据必须附有时间元素。当数据
从操作型系统传送到数据仓库时，必需在数据中进行较大范围的改变。
下载
当数据从现存操作型环境传送到数据仓库时，要考虑的另一个问题是需要对数据的量进
行管理。数据要浓缩，否则数据仓库的数据量很快就会失控。在数据抽取一开始就要进行数
据浓缩。图 3-6表示数据仓库数据浓缩的一个简单形式。
管理大量的数据
当前值
当前值
日余额
如果大量的数据没有认真地管理和压周余额
缩，那么仅仅是数据仓库聚集的大量数
据就可以阻止数据仓库达到它的目的
月余额
图3-6 数据的压缩对于管理数据仓库至关重要
3.2 数据/过程模型和体系结构设计环境
尝试使用传统的设计方法前，设计者必须明白这些方法的适用范围与其局限性。图 3 - 7说
明了体系结构层次与数据建模和过程建模规程之间的关系。过程模型仅仅适用于操作型环境。
数据模型既可用于操作型环境，又可用于数据仓库环境。数据模型或过程模型用错了地方，
只会带来失败。
在本章后面会更详细地讨论数据模型。什么是过程模型？一个过程模型 (整个或部分地 )一
般包括以下内容：
• 功能分解。
• 第零层上下文图表。
• 数据流图。
• 结构图表。
• 状态转换图。
• HIPO 图。
• 伪代码。
在许多场合和环境下，过程模型是很有价值的。但在建造数据仓库时，过程模型是个障
碍。过程模型是基于需求的，它假设在细节设计开始之前是知道需求的。在处理过程时，是
可以这样假设的。但这样的假设在建造数据仓库时是不成立的。其实许多开发工具，如 CASE
工具具有相同的功能定位，为此，它们不适用于数据仓库环境。
50 数据仓库
下载
企业模型，操作型模型和数据仓库模型
数据类型
直接应用
间接应用
操作型数据仓库部门个人
数据仓库
直接应用
过程模型
图3-7 不同类型的模型怎样应用于体系结构设计环境
3.3 数据仓库和数据模型
数据模型既适用于现存系统环境也适用于数据仓库中环境，图 3-8做了更清楚的解释。
企业模型
数据模型
数据模型
数据仓库数据模型
数据模型
操作型数据模型
数据仓库
• 去掉纯操作型数据
操作型 • 给键码增加时间元素
• 合适之处增加导出数据
• 操作型数据模型等价于企业数据模型
• 创建人工关系
• 在数据库设计之前要加入性能因素
图3-8 不同层次模型间的关系
下载
图3 - 8所示的是一个企业数据模型，该模型建造时没有考虑现存的、操作型系统与数据仓
库之间的差别。企业数据模型只包含原始数据。要建造一个单独的现存数据模型，需要从企
业模型开始。然而，当企业数据模型传送到现存系统环境中时，性能因素也应加到该模型中。
总之，企业数据模型用于操作型系统时，几乎不用做什么改动。
但是，企业模型用到数据仓库中要做相当多的改动。首先要做的是除去纯粹用于操作型
环境的数据。然后，在企业数据模型的键码结构中增加时间元素。导出数据加到企业数据模
型中，在那里导出数据作为公用并只计算一次，而不重复计算。最后，操作型系统中的数据
关系在数据仓库中就转变为“人工关系”。
设计的最后一项设计工作是企业数据模型到数据仓库数据模型的“稳定性”分析。稳定
性分析是根据各个数据属性的变化特性将这些属性分组。图 3-9说明了稳定性分析。
零件表很少更改有时更改频繁更改
图3-9 一个制造业环境中稳定性分析的例子，显示出如何从一个大的、通用的表中
根据包含在表中的数据的稳定性需求而产生三个表
52 数据仓库
下载
在图3 - 9中，不常变化的数据聚集在一起，时而变化的数据聚集在一起，常变化的数据聚
集在一起。稳定性分析的最终结果 (这是物理数据库设计前数据建模的最后一步 )是具有相似特
性的数据聚集在一起。
于是，有一个数据模型的共同起源。可以作一个类比，企业数据模型是亚当，操作型数
据模型是凯恩，数据仓库的数据模型是亚伯。他们都源于同一个血统，但同时又互不相同。
3.3.1 数据模型
(已有一些其他的书籍论述数据建模。有很多的方法可供选择。随便找出几种都可以成功
地用来建造数据仓库。本书要讨论的方法是总结性质的，进一步的探讨请参阅《 I n f o r m a t i o n
Systems Architecture》, Wiley。)
有三个层次的数据建模：高层建模 ( E R D，实体关系层 )，中间层建模 ( D I S，数据项集 )，
底层建模(物理层)。
高层建模的特点是实体和关系，如图 3 - 1 0所示。实体的名字放在椭圆内。实体间的关系
用箭头描述。箭头的方向和数量表示关系的基数，只有直接的关系才标志。这样做以后，关
系的传递依赖就可以最小化。
一个椭圆表示一个实体或者主要主题
一个1∶n的关系
一个1∶1的关系
一个m∶n的关系
零件供应商
订单
装配
制造环境的一个简单的ERD
图3-10 表现实体和关系
在E R D层的实体位于最高抽象层。哪些实体属于模型的范围，哪些实体不属于，是由所
谓的“集成范围”来决定的，如图 3-11所示。
集成范围定义了数据模型的边界，而且集成范围需要在建模之前进行定义。这个范围由
系统的建模者、管理人员和最终用户共同决定。如果范围没有事先确定，建模过程就会一直
持续下去。书写集成范围的定义应该不超过 5页，而且应该使用业务人员懂得的语言。
企业ERD由很多反映了整个企业不同人员的不同观点的单个的 ERD合成的，如图3-12所示。
已经为企业内不同的群体建立好了各自独立的高层数据模型，这些模型共同组成这个企业 ERD。
下载
集成的范围
数据模型
图3-11 集成范围决定了企业的哪些部分反映在数据模型中
用户视图(1)
ERD(1)
用户视图(2)
ERD(2)
用户视图(3) 企业ERD
ERD(3)
用户视图(n)
ERD(n)
图3-12 企业ERD的构造来自于不同的用户视图ERD
54 数据仓库
下载
公共的ERD依照用户的观点而建，这些观点来自与不同部门适当的人员的交流。
3.3.2 中间层数据模型
高层数据模型建好后，下一步就是建中间层模型 ( D I S )。对高层模型中标识的每个主要的
主题域，或实体，都要建一个中间层模型，如图 3 - 1 3所示。高层数据模型标识了四个实体或
主要主题域，每个主题域再扩展成自己的中间层模型。
DIS DIS
ERD
DIS
DIS
ERD和DIS的关系
图3-13 ERD中的每一个实体将来都会被它的DIS所定义
初始数据组
数据“类型”
二次数据组
连接件数据
图3-14 中间层数据模型的四个组成部分
有趣的是，只有在很少的情况下，所有的中间层模型能一次全部建好。某个主要主题域
的中间层数据模型扩展后，这个中间层模型逐渐增大，而此时模型的其他部分仍然保持不变。
图3-14显示了中间层数据模型的构造。这里有四个基本的构造：
■ 初始数据组。
■ 二次数据组。
■ 连接件，表示主要主题域间的数据关系。
■ 数据“类型”。
初始数据组对每个主要主题域存在且只存在一次。它有在每个主要主题域只出现一次的
属性。同所有的数据组一样，初始数据组有属性和键码。
下载
二次数据组有对每个主要主题域可以存在多次的属性。从初始数据组有一直线段指向二
次数据分组。有多少可以出现多次的不同数据组，就含有多少二次数据组。
模型的第三个构造是连接件。它将数据从一个组到另一个组联系起来。一个 E R D层确定
的关系导致了DIS层的确认。用来指示连接件的惯例是一个有下划线的外键。
模型的第四个构造是数据的“类型”。数据的“类型”由指向右边数据组的线段指示。左
边的数据组是超类型，右边的数据组是子类型。
这四个数据模型构造用来标识数据模型中的数据属性和这些属性间的关系。当一个关系
在ERD层标识以后，在 DIS层就用一对连接件关系来表现，图 3-15就指出了其中一对。
在ERD，在顾客(CUSTOMER)和帐户(ACCOUNT)之间的关系已经表示出来。对于帐户的
D I S层，在帐户下有一个连接件。这说明一个帐户可能附有多个顾客。在顾客的 D I S层，顾客
下对应的关系没有表示出来。在顾客的 DIS层，应该有一个到帐户的连接件，说明一个顾客可
以有一个或多个帐户。
ERD
图3-15 ERD标明的关系在DIS中由连接件反映，注意只有一个连接件(从acctno到customer)
在图中显示。实际上，另一个连接件从customer到acctno将在customer的DIS中显示
作为一个 D I S详细情况的例子，如图 3 - 1 6所示。这是一个对于一个金融机构帐户的 D I S，

显示了DIS里所有不同的构造。
图3-16 一个扩展的表明银行可提供贷款类型的DIS
56 数据仓库
下载
特别注意一下这样一个情况，就是一个数据组有两个“类型”线引出来，如图 3 - 1 7所示。
银行活动存款
提款
ATM
这个DIS反映的活动类型：
• ATM存款
• ATM提款
• 出纳存款出纳
• 出纳提款
图3-17 显示不同子分类标准的一个DIS
存款表
银行活动存款
提款表
提款
ATM表
ATM
银行活动表
出纳
出纳表
图3-18 两个事务所表现的表的条目
下载
到右边的两条线说明有两个标准“类型”。一条线是活动类型 — 或者是存款或者是提款。另
一条线是活动 — 或者是ATM活动或者是出纳活动。两种类型的活动都包括下面的交易：
■ ATM存款。
■ ATM提款。
■ 出纳存款。
■ 出纳提款。
这个图表的另一个特点是公用数据在左边，所有的独有数据在右边。例如，日期( d a t e)和
时间(time)属性对于所有交易是公用的。但是，钱箱 (cashbox)的结算却是出纳独有的活动。
由数据模型产生的和数据模型物理数据表的关系如图 3 - 1 8所示。一般来讲，数据模型的
每个数据组都产生一个在数据库设计过程中定义的表。假设下面一种情况，两个交易产生一
些表条目，如图所示。下面的两个交易产生图中的物理表条目。
■ ATM处理提款，在1月2日，下午1:31。
■ 出纳处理存款，在 1月5日，下午3:15。
两个交易生成5个不同表的 6个条目。
与企业 E R D是由反映不同用户群体的不同 E R D所建成的一样，企业 D I S由多个 D I S建成，
如图 3 - 1 9所示。在进行对个别用户的访问或 J A D (联合应用程序设计 )会议时，就要生成一个
DIS和一个ERD。小范围的 DIS和其他所有 DIS一起形成一个反映企业观点的 DIS。
用户视图(1)
用户视图(2)
企业ERD
用户视图(3)
用户视图(n)
企业DIS
图3-19 企业DIS是由每个用户视图会话结果的DIS组成的
58 数据仓库
下载
3.3.3 物理数据模型
物理数据模型是由中间层数据模型创建的，它只是通过包含键码和模型的物理特性来扩展
中间层数据模型而得到的。这时，物理数据模型看上去像一系列表，这些表有时称做关系表。
人们很容易认为这些表是准备用来实现物理数据库设计的。然而，还有设计的最后一步
— 确定性能特性。
在数据仓库的情况下，确定操作性能特性的第一步意味着决定数据的粒度与分割，必须
这样做。(当然，键码结构要做改变，以便能加入与每个数据单元都相关的时间元。 )
做完粒度与分割后，许多其他的物理设计活动就要加进这项设计了。这些其他的物理设
计因素的概要如图 3-20所示。物理设计因素的中心在于物理 I/O(输入/输出)。I/O就是将数据从
存储器上调入计算机，或者将数据从计算机送到存储器，图 3-21就是简单的 I/O例子。
数据在计算机和存储器之间的调入调出是按块进行的。对性能来说 I / O事件如此重要是因
为存储器和计算机间的数据传输速度比计算机运算速度要慢大约两到三个数量级。计算机内部
运算速度以毫微秒计，而数据的传输速度是以毫秒计。因此，物理 I/O是主要影响性能的因素。
• 性能
数据模型
• 数据数组
• 归并表
• 选择冗余
• 进一步分离数据
• 导出数据
物理数据库设计
• 预格式化，预分配
• 人工关系
• 预连接表
图3-20 从数据仓库环境中获得好的性能
I/O
计算机
图3-21 取得最高的物理I/O效率
数据仓库设计者的工作是要物理地组织好数据，以便返回最大数量的记录，这些数据是
执行物理 I / O时产生的 (注：这不是盲目地将大量记录从 D A S D传到主存上。这是一个很复杂的
问题，即传输那些具有高访问概率的大量记录。 )
例如，假定程序员要取 5个记录。如果这些记录是在存贮器中不同的数据块上，那么就需
要五次 I / O操作。但是如果程序员能够预测到这些数据将成组的访问，将其并列地放在同一个
物理块中，那么这就只需要一次 I/O操作，这样使得程序的运行效率更高。
关于数据仓库中数据存放的问题还有一个缓和因素：数据仓库里的数据一般不更新。这样设
下载
计者就可以自由地采用物理设计技术，这些技术在数据需要经常更新的情况下很可能就不能接受。
3.4 数据模型和反复开发
在所有情况下数据仓库最好是反复建造的。下面就是为什么说反复建造是很重要的理由：
■ 业界成功的记录强烈地建议这样做。
■ 最终用户在第一遍完成以前不能明白地提出需求。
■ 只有实际结果切实而且明确时，管理部门才能作出充分的承诺。
■ 需要很快看到可视化结果。
这时，可能尚不清楚的是数据模型在反复开发中担当的角色，为了解释数据模型在反复
开发期间所起的作用，考虑典型的如图 3 - 2 2所示的反复开发过程。首先进行一遍开发，然后
另一遍，等等。数据仓库在每遍开发中都起着路标的作用，如图 3-23所示。
第b遍
第a遍
第c遍
第d遍
图3-22 数据仓库开发的不同阶段
第b遍
第a遍
第c遍
第d遍
图3-23 数据模型允许开发的不同重复阶段以一种紧密结合的方式进行
当第二遍开发继续接着进行时，开发人员相信，他或她将汇集第一遍开发的成果，因为
所有的开发都是数据模型驱动的。每遍后续开发都是建立在前一遍开发的基础上，结果就是
都在统一的数据模型上进行不同的开发。正是由于它们都是基于同一个数据模型，各遍开发
工作的成果将产生一个内聚的、高度和谐的整体，见图 3-24。
当不同遍的开发是在不同的数据模型之上进行时，就会产生很多重复的工作和很多不连
贯的开发，图3-25就说明了这个不协调的结果。
在数据仓库的增量式开发和反复式开发的过程中，在数据模型与达到长期集成和和谐工
作的能力之间，存在一个间接的但很重要的相互关系。
60 数据仓库
下载
图3-24 在开发工作结束时，所有遍的结果融合在一起
图3-25 如果没有数据模型，重复的开发不能构成一个内聚的模式有许多重叠和缺乏一致性
3.5 规范化/反规范化
数据模型处理过程的输出是一系列表，每个表包含键码和属性。常规的输出是很多表，
其中每个表只包含少量数据。
虽然输出大量小表本身没有什么不对，但从性能上看是一个问题。请考虑程序为使表之
间的动态互连而必须做的工作，如图 3-26所示。
程序
图3-26 当有许多表时，动态互连能力要求大量的I/O
下载
在图3 - 2 6中，一个程序开始执行。首先，一个表被访问，然后另一个表被访问。为了成
功运行，程序必须在很多表中跳转。每次程序从一个表跳到另一个，就要进行 I/O,既要存取数
据，又要存取索引以找到数据。如果只有一两个程序需要进行 I / O，那是不成问题的。但是如
果当所有的程序需要进行大量的 I / O时，性能就会受到影响。当物理设计生成的是很多小表，
而且每个小表都只有有限量的数据时，所发生的就正好是这种情况。
一个较为合理的方法是将这些表合并，使得只需进行最低限度的 I / O，如图 3 - 2 7所示，其
中很多小表都已经在物理上合并在一起。
程序
图3-27 当表在物理上被归并，就需要较少的I/O
这样做以后，同样的程序跟以前一样运行，只是现在只需要少得多的I/O去完成同样的工作。
于是，问题就转化，采取一种什么策略将表合并起来以获得最大的收益才是明智的？要
回答这个问题，就是数据库物理设计人员需要做的事了。
但是合并表只是能够节省 I / O的设计技术之一。另一个非常有用的技术是生成一个数据数
组。在图 3 - 2 8中，数据是规范化的，使得每产生一个数据序列值都存在一个不同的物理位置。
每次检索每一个值， n , n + 1 , n + 2 , . . . ,都需要进行一次物理 I / O才能得到数据。如果数据存放在一
个数组的单一行中，那么一次 I/O就足以检索到了，如图中下部所示。
当然，并不是在所有情况下创建一个数据数组都是有意义的。仅当数据序列产生的数量
是稳定的，数据是按序列存取的，且数据的创建与修改在统计上是以很规律的方式进行的时
候，创建一个数据数组才是有意义的。
有趣的是，在数据仓库中，由于数据具有基于时间特性，这些情况是经常发生的。数据
仓库中的数据经常与某个时刻相关，而且时间部分以很有规律的形式出现。在数据仓库中，
例如，每月创建一个数组，是很容易而且是很自然的事情。
另一个重要的，特别是和数据仓库相关的设计技术是引入冗余数据。图 3 - 2 9就给出了一
个引入冗余数据而带来好处的例子。在图的上部，字段(描述信息)是规格化的、无冗余的。这
样，所有需要查看一个部件描述的过程都必须访问基本部件表。尽管数据的更新是优化的，
但对这些数据的访问开销是很大的。
在图3-29的下部，数据元素(描述信息)有意地放在了可能要用到它的许多表中。这样做使访
问数据效率更高，而数据的更新是不优化的。然而，对于那些广泛使用的数据(如描述信息)，和
稳定的数据(也如描述信息)，几乎没有理由担心更新问题。尤其是在数据仓库中不用考虑更新。
62 数据仓库
下载
创建数据数组提高性能
程序
数据数组散布在各个不同的
物理块内
程序
数据物理地组织成数组
图3-28 在合适的情况下，创建数据数组可以节约可观的资源
选择使用冗余
更新访问访问访问访问访问
描述(desc)信息是非冗余的，经常使用，但是很少更新
更新访问访问访问访问访问
图3-29 描述是冗余的，散布在使用它的许多地方，当它被改变
的时候每一处都应改变，但是它很少改变
另一个有用的技术是：当访问概率有很大悬殊时，要对数据做进一步分离。图 3 - 3 0给出
下载
了这种情况。
在图3-30，考虑一个银行账户，账户住址(domicile)、开户数据(data opened)和余额(balance)是规范
化的。但是，余额与其他两项数据的访问概率差别很大。余额经常用到，而其他数据则很少用到。
为了使I/O效率高一些，并且使数据存放得更紧凑一些，可以将规范化的表分成两个独立的表，如图
3-30所示。
低访问概率
非常高的访问概率
图3-30 根据访问概率的很大差异进一步分离数据
有时，在物理数据库的设计中引入导出 (即计算出的 )数据可以减少 I / O，图3 - 3 1给出了这

样一个例子。一个程序为了计算出年薪和已付的税金，要定期访问工资清单。如果该程序在
每年年底运行一次，那么生成一个字段来存储计算出的数据就很有意义了。这些数据只要计
算一次，将来需要时只要访问那个字段就可以了。这个方法的另一个优点在于那个域的数据
只用计算一次而不必重复计算，减少了由不正确计值导致错误算法的可能。
引入导出数据
程序
图3-31 导出数据，计算一次就可以永久使用了
建造数据仓库的一个最具革新意义的技术是建立所谓的“创造的”索引或创造的简要记
录(由莫尔杜撰的术语 )，图3-32给出了一个创造的索引的例子。创造的索引是当数据由操作型
环境转移到数据仓库环境时建立起来的。由于每个数据单元必须能在任何情况下处理，所以
64 数据仓库
下载
在这时计算或建立索引只要很少的开销。
创适的索引 /概要文件
抽取
加载
轻度总结的数据
现有系统
创造的索引；
概要文件真实的存档
图3-32 创造的索引的例子：
• 卷中的前十名顾客是＿＿＿
• 这个抽取的平均的交易值是$nnn.nn
• 最大的交易值是$nnn.nn
• 查看交易活动而没有购买的顾客数nn
创造的索引为终端用户感兴趣的项目建立一个概要文件，例如“最大宗的购买”，最不活
跃的帐户，最近的发货，等等。如果对管理有意义的需求能够预测 (当然不是所有情况都如此 )，
那么在数据传送给数据仓库时建立“创造的索引”就有意义了。
数据仓库设计者要知道的最后一个设计技术就是数据仓库环境中参考完整性的管理。如
图3-33所示，在数据仓库环境中，参考完整性表现为“人工关系”。
数据仓库参考完整性
在操作型系统，数据库之间的关系由参考完整性处理
但是，在数据仓库环境
• 拥有比操作型环境更多的数据
• 一旦进入数据仓库，数据不再改变
• 需要表示不止一种商业规则
• 数据仓库中的数据清理并不是完全协调的
主题A 主题B
数据仓库环境中的人工关系：
• 可以单独管理
• 访问效率高
• 不需要更新
图3-33 数据仓库环境中的参考完整性
下载
在操作型环境中，参考完整性表现为数据表之间的动态连接，但在数据仓库环境中有如
下事实：数据量很大、数据是不更新的、数据按时间表示、关系不是静态的，因此应采取不
同的方法表示参考完整性。总之，数据的关系在数据仓库环境中需人为地加以表示。这意味
着有些数据要复制，有些要删除，同时其他数据仍然保留在数据仓库中。无论如何，试图在
数据仓库环境中重复参考完整性，显然是不正确的方法。
3.6 数据仓库中的快照
数据仓库是应各种各样的应用和用户而建，如顾客系统，市场系统，销售系统和质量控
制系统。不管数据仓库有什么非常不同的应用和类型，还是有一条共同的线索贯穿其中。在
其内部，每个数据仓库都围绕着一个称之为“快照”的一种数据结构。
图3-34说明了数据仓库快照的基本组成形式。
快照是因为一些事件的发生而产生
的。能够触发快照的事件有很多种。
一类事件是对离散活动的信息的记录，
例如填写支票，打电话，收到货物，时间
键码非键码初始数据二次数据
完成订单，购买保险单等。在发生离
图3-34 数据仓库中的数据记录是一个时刻的快照，
散活动时，将会带来一些商业活动，
包括不同类型的数据
并且需要记录下来。总之，离散活动
是随机发生的。
触发快照的另一类常见的事件是规定的时间点。在一个特定的时刻，快照就会触发。典
型的时间点包括日末，周末，月末。当然，这些时间点是事先可预测的，并不是随机的。
由事件触发的快照有四个基本部分：
• 键码(KEY)。
• 时间单元。
• 只和键码相关联的初始数据。
• 作为快照过程的一部分所捕获的二次数据，和初始数据或键码无直接的关系。
在数据仓库的这些基本部分中，只有二次数据是可选的。
键码可以是唯一的也可以不唯一。键码可以是单一的数据元素。但在数据仓库中，更多的
键码是由用来识别初始数据的很多数据元素组成的混合物。键码用来识别记录和初始数据。
时间单元根据时间元素生成，例如年、月、日、时和刻。时间单元通常是 (但并不总是)指
快照所描述事件已经发生的时刻。有时时间单元指的是捕获数据的时刻。 (在一些情况下，事
件发生时刻和捕获信息的时刻是不同的，而在另一些情况下是没有差别的。 )在由固定时间触
发事件的情况下，时间元素可以暗含而不是直接附于快照中。
初始数据是与记录的键码直接相关的非键码数据。例如，假设键码表示产品销售，时间
元素描述的是销售活动终结的时刻，初始数据描述的是销售什么产品以及销售的价格、条件、
地点和代理。
二次数据，如果存在的话，表示快照生成时捕获的外来信息。如与销售相关的二次数据是
一些关于产品出售的附带的信息 (例如成交时的股市价格 )。关于销售的另一个二次信息是销售
时银行对优惠顾客的流行利率。有很多种伴随信息可以加到数据仓库记录中去，如果将来这
66 数据仓库
下载
些信息会在 D S S处理过程中使用到。注意这些加到快照中的伴随信息可以是也可以不是外键
码。
一旦二次信息加到快照中 — 如果全部加入 — 初始信息和二次信息间的关系就可以推断
出来，如图 3 - 3 5所示。快照意味着在二次信息和初始信息之间存在关系。除此之外，没有什
么别的了。这种关系是快照的即时反映。不过，产生快照时，从快照记录中初始数据和二次
数据的并列，就能推出数据之间的关系。有时，这种导出关系叫做“人工关系”。快照记录是
数据仓库中最为一般和最容易发现的记录的例子。
非键码初始数据二次数据
图3-35 由于用驻留于同一快照中的二次数据可能构成如像初
始数据那样暗含的关系，人工关系被捕获
3.7 元数据
数据仓库环境中一个重要方面是元数据。元数据是关于数据的数据。只要有程序和数据，
元数据就是信息处理环境的一部分。但是在数据仓库中，元数据扮演一个新的重要角色。也
正因为有了元数据，可以最有效地利用数据仓库。元数据使得最终用户 / D S S分析员能够探索
各种可能性。
元数据在数据仓库的上层，并且记录数据仓库中对象的位置。典型地，元数据记录：
■ 程序员所知的数据结构。
■ DSS分析员所知的数据结构。
■ 数据仓库的源数据。
■ 数据加入数据仓库时的转换。
■ 数据模型。
■ 数据模型和数据仓库的关系。
■ 抽取数据的历史记录。
3.8 数据仓库中的管理参照表
大多数人想到数据仓库技术，就经常会想到不停地用来运行公司日常事务的一般大型数
据库，例如顾客档案，销售记录，等等。事实上，这些一般文件构成了数据仓库工作的框架。
然而，数据仓库中还有常被忽略的一类数据：参考数据。
参照表常常被认为是用来创建一个专门的问题。在很多情况下，参照表不是数据仓库的
一部分。例如，假设一个公司有 1 9 9 5年的一些参照表，并且从 1 9 9 5年开始建立数据仓库。随
着时间的推移，大量数据装载到数据仓库，同时，参照表用于操作上，并可能改变。在 1 9 9 9
年，需要将数据仓库与参照表进行比较。 1 9 9 5年的数据与参照表作过一个比较，但参照表没
有保持历史准确性， 1 9 9 5年数据仓库数据与参照表数据相比结果是准确的，而 1 9 9 9年数据相
比就得到很不准确的结果。正因为这个原因，数据仓库既需要一般数据也需要参考数据。
参考数据特别适用于数据仓库环境，因为使用参考数据可以明显地减少数据仓库的数据
下载
量。数据仓库环境中管理参考数据有很多的设计技术。这里要讨论两个，这两个技术恰恰是
处于这些技术的两个对立端的技术。 (在给出的设计选项中有很多选择和变型。 )
图3-36 一种管理数据仓库环境中的参照表的方法—每六个月产生一个参照表的快照
图3 - 3 6显示的是第一个设计选择，每 6个月做完整参照表的一个快照。示例中一个快照是
在1月1日生成，另一个是 7月1日，如此下去。这个方法好在非常简单。每 6个月生成一个小表
的快照没有什么难度。但是这个方法逻辑上是不完善的。例如，假设参照表的一些活动发生
在3月1 5日。如果加入一个新的条目 — d d w，然后5月1 0日该条目被删除。每 6个月做个快照
就没法捕获 3月1 5日到5月1 0日发生的活动。所以第一种管理参照表的方法是最简单的，但不
完备。
在数据仓库环境中，对参照表的第二个管理方法如图 3 - 3 7所示。该图表示，在某一时间
起点上，一个快照就是由一个参照表构成的。一年中参照表的活动都会被收集起来。为了确
定某一时刻参照表某个给定条目的状态，该活动将按参照表进行重组。在这种方法中，表的
逻辑完整性将可以在任何时刻被重新建立起来。然而，这种重建是一件复杂的事情，可能是
一个巨大的而且复杂的任务。这种方法在逻辑上是完整的，但实现起来却是复杂的。
这里给出的两种方法在想法上是相反的。第一种方法较简单。但是逻辑上并不完善。第
二种方法很复杂，但是却有逻辑上的完整性。在我们所讨论的这两种极端之间有很多可供选
择的设计方案。但是在设计和实施的过程中，有必要把参照表作为数据仓库中正式的一个部
分进行管理。
Jan 1 - 增加 TWQ - Taiwan

Dairy
Jan 16 - 删除 AAT
Feb 3 - 增加 AAG - German Power
Feb 27 - 改变 GYY - German Govt
……………………………………………
在一年的最初产生一个完整的参照表全年的改变被收集起来，并可
快照以在任意时刻重建参照表
图3-37 另一个管理参照表的方法
3.9 数据周期
数据仓库设计中的一个引人注目的问题是数据周期。所谓数据周期是指从操作型环境数
据发生改变起，到这个变化反映到数据仓库中所用的时间。考虑如图 3-38中所示的数据。
图中给出了关于 Judy Jones的当前信息，数据仓库包含有 J u d y的历史信息。现在假设发现
68 数据仓库
下载
Judy已经改变了她的地址。图 3-39表明这个变化一旦被发现，就马上被反映到操作型环境中。
图3-38 当公司发现J Jones搬家后会发生什么？

操作型
搬家到
图3-39 第一步是在操作型环境中改变J Jones的地址
一旦数据反映到操作型环境中，这个变化就必须被转入数据仓库中。图 3 - 4 0表示数据仓
库对最当前记录的终结日期进行了更正。并且插入了一条新的记录，这条记录反映了对有关
Judy Jones的记录所做的修改。
下载
问题是对数据仓库数据的这种调整，应该多长时间进行一次呢？原则上从操作型环境知
道数据的改变到这个变化反映到数据仓库中至少应该经历 24小时(见图3-41)。没有必要急于把
这个变化转入信息仓库中去，有几个需要把“时间间隔”放到数据中的原因：
首先，如果操作型环境与数据仓库相互之间结合得越紧密，那么所需的费用就越昂贵，
技术也越复杂。 24小时的时间间隔以现有技术来说将很容易被实现。
数据仓库
1993 改变终止日期
插入
图3-40 改变地址引起的在数据仓库中出现的活动
但是，更有说服力的一个原因是，时间间隔给环境附加了一个特殊的限制。间隔 2 4小时，
使得在数据仓库中不必做操作型处理；在操作型环境中不必做数据仓库处理。时间间隔的另
一个好处是在转入数据仓库之前，数据能达到稳定。
时间间隔
24小时延迟
改变改变
图3-41 在操作型环境知道改变到改变被反映在数据仓库之间的时间，至少需要24小时延迟
70 数据仓库
下载
3.10 转换和集成的复杂性
粗略一看，当数据从传统环境转入数据仓库时，除了简单地从一个地方抽取数据再放入
另一处，并没有做别的什么。由于表面上看起来很简单，很多组织开始手工建立他们的数据
仓库。程序员只看到了数据从旧的操作型环境到新的数据仓库环境中的简单流动就轻率地说：
“我可以做到！”于是，在数据仓库设计、开发伊始，程序员往往就着手编写代码。
然而，第一印象通常是非常靠不住的。开始时认为仅仅是数据在不同环境中的简单传送，
很快就会变成一个巨大的复杂的任务 — 比程序员所考虑的要大得多复杂得多。
准确地说，数据从操作型环境到数据仓库环境的传递要完成什么功能呢？下面就是所要
完成的某些功能。
■ 从原始操作型环境到数据仓库环境的数据抽取需要实现技术上的变化。一般包括，从
操作型系统获取数据的数据库管理系统 ( D B M S )技术，如 I M S，以及将数据写入更新的
数据仓库的 DBMS技术，如INFORMIX。在数据传递过程中需要实现技术的转移。
■ 从操作型环境中选择数据是非常复杂的。为了判定一个记录是否可进行抽取处理，往
往需要完成对多个文件中其他记录的多种协调查询，需要进行键码读取，连接逻辑等。
■ 操作型环境中的输入键码在输出到数据仓库之前往往需要重新建立。在操作型环境中
读出和写入数据仓库系统时，输入键码很少能够保持不变。在简单情况下，在输出键
码结构中加入时间成分。在复杂情况下，整个输入键码必须被重新散列或者重新构造。
■ 数据被重新格式化。举一个简单例子：有关日期的输入数据格式是 Y Y / M M / D D，当它
被写入输出文件时，需要转化为 DD/MM/YY的格式。(操作型数据进入数据仓库之前的
格式转换往往比这要复杂得多。 )
■ 数据将被清理。在某些情况下，为了保证输入数据的正确性，需要一个简单的算法。
在复杂情况下，需要调用人工智能的一些子程序把输入数据清理为可接受的输出形式。
■ 存在多个输入数据源。在某些情况下数据仓库中数据项的来源是一个文件，而在另外
一些情况下，则为另外一个文件。逻辑上必须分清楚，以便由适当的数据源提供正确
条件下的数据。
■ 当存在多个输入文件时，进行文件合并之前要首先进行键码解析。这意味着如果不同
的输入文件使用不同的键码结构。那么，完成文件合并的程序必须提供键码解析功能。
■ 当存在多个输入文件时，这些文件的顺序可能不相同甚至互不相容。在这种情况下这
些输入文件需要进行重新排序。当有许多记录需要进行重新排序时可能有些困难，但
可惜的是，通常都是这种情况。
■ 可能会产生多个输出结果。同一个数据仓库的创建程序会产生不同概括层次之上的结
果。
■ 需要提供缺省值。有时候，数据仓库的一个输出值没有对应的输入源。这时，必须提
供缺省值。
■ 对抽取选择输入的数据，其效率通常是一个问题。我们考虑一个情况，在刷新的时候，
我们没有办法将需要抽取的操作型数据和不需要抽取的操作型数据区别开来。这时，
必须读取整个文件。而读取整个文件的方法效率很低，因为在一个文件中，只有一小
部分的记录是用得上的。这将导致在线环境一直处于活动状态，进而挤掉了其他的处
下载
理活动。
■ 经常需要进行数据的汇总。多个操作型输入记录被连接成单个的“简要”数据仓库记
录。为了完成汇总，那些需要汇总的详细的输入记录必须被正确排序。当把不同类型
的记录汇总为一个数据仓库记录时，这些不同输入记录类型的到达次序必须进行协调，
以便产生一个单一记录。
■ 在数据元素从操作型环境到数据仓库的数据转移过程中，对数据元素的重命名应该进
行跟踪。当一个数据项移动时，往往被改变名字。这样就必须生成记录这些变化的文
档。
■ 必须被读的输入的记录有着不常见的或不标准的格式。下面列出了必须读的各种输入
类型：
• 固定长度的记录
• 不定长记录
• 出现不定
• 重复出现
■ 必须进行转换。但是必须指定转换逻辑，转换机制 (正如B E F O R E，A F T E R )会非常复
杂。有时转换逻辑变得非常曲折。
■ 这一点也许是最糟糕的：建立在旧的传统程序逻辑中的数据之间的关系必须被理解、
被解开，这样，这些文件才能被用来作为输入。而这些关系常常是深奥难懂的，没有
可供参考的文档资料。
■ 必须进行数据格式的转换。 EBCDIC到ASCII的转换(或反过来)必须进行。
■ 必须考虑到进行大容量输入的问题。当只有少量的数据作为输入时，可以有很多供选
择的方案。但是，当有大量的记录作为输入时，就必须引入一些特殊的设计方案 (如并
行装载和并行读出 )。
■ 数据仓库的设计必须符合企业数据模型。这样数据仓库的设计和建立就有一定的规则
和限制。数据仓库的输入是以很久以前的一个应用程序设计说明书为准的。然而自从
组织编写这个应用程序以来，它所依赖的业务条件可能已经经过了多次大的变化。已
经针对程序代码做过多次维护，但没有相关文档。另外，这个应用可能没有与其他应
用集成的需求。所有的这些脱节之处，在设计和建立数据仓库的时候必须予以考虑。
■ 数据仓库反映的是对信息的历史需求，而操作型环境是体现对信息目前的需求。
■ 数据仓库着眼于企业的信息化需求，而操作型环境则着眼于精确到秒的企业日常事务
需求。
■ 必须考虑到新创建的将要传入数据仓库的输出文件的传输。有些情况下这是很容易做
到的；在另一些情况下就不那么容易了，尤其是跨操作系统的情况。
还有更多需要考虑的；以上列出的仅仅是当一个程序员着手装载一个数据仓库时所面对
的复杂性的开始。
3.11 触发数据仓库记录
引起数据仓库的数据载入的基本的业务活动可以称为“事件→快照”事务。在一个事件
→快照事务中，某个事件触发了数据的一个快照 (一般是在操作型环境中 )，然后被转移到数据
72 数据仓库
下载
仓库环境中。图 3-42象征性地图示了一个“事件→快照”事务。
事件快照
延键非键码初始数
二次数据
时码据
图3-42 数据仓库中的每个快照都是由事件触发的
3.11.1 事件
引发快照的业务事件可能是一些重要活动的发生，比如：进行一次销售，货物入库，通
一次电话，或者发送一次货物。这类业务事件称作“活动－发生”事件。在数据仓库中另一
类可能触发快照的业务事件是日常的时间推移标志。如一天的结束，一个星期的结束，或一
个月的结束。这种业务事件称为“时间－发生”事件。
业务活动引起的事件是随机的。而时间推移所触发的事件则不是随机的。与时间有关的
快照的建立是有规律的并且是可以预知的。
3.11.2 快照的构成
产生的且要放入数据仓库中的快照一般包括几个构成部件。一个部件是标志事件发生的
时间单元。一般来讲 (并不是必然的 )，这个时间单元标记了快照产生的时间。另一个部件是用
来标识快照的键码。数据仓库快照的第三个部件是与键码相联系的初始的、非键码数据。另
外，有一个可选部件，是在形成快照时偶然捕获并被置入快照的二次数据。这些数据往往被
称作关系的“人工因素”。
在最简单的情况下，公司每一个重要的运作活动都将在数据仓库触发一次快照。在这
种情况下，公司内已经发生的一些业务活动与被置入数据仓库的快照数目之间是一一对应
的。当这种一一对应关系存在的时候，数据仓库就能跟踪与某一主题域有关的所有历史活
动。
3.11.3 一些例子
每当发生操作型业务活动就产生快照的例子可以在客户文件中找到。每次当客户搬迁、
更改电话号码或改变工作的时候，数据仓库就会相应改变，而且有关这个客户历史的一连串
记录就会写入数据仓库。一个记录跟踪客户从 1 9 8 9到1 9 9 1年的活动。另一个记录跟踪他从
1 9 9 1到1 9 9 3年的活动。还有一个记录跟踪这个客户从 1 9 9 3年到现在的活动。这个客户的每次
活动都以一个快照的形式载入数据仓库。
另一个说明每次业务活动都导致在数据仓库中产生一个快照的例子是在保险公司中保险
金的支付。假设保险金是每半年支付一次的，那么每隔 6个月就会在数据仓库中创建一个快照
记录，用来描述保险金的支付情况，包括所支付的时间、金额等。
当数据量不是太大，数据稳定 (不是经常变化 )，并且需要详细历史记录时，数据仓库可以
通过存储已发生的每次活动的详细情况来跟踪业务事件。
下载
3.12 简要记录
在很多情况下，数据仓库中的数据并不满足这些标准。有时数据量是巨大的。有时数据
的内容经常发生变化，而且有时商业上并不要求特别详细的历史记录。当上述一种或多种情
况出现时，可以建立另一种不同的数据仓库记录。这种记录可以被称为聚集记录或简要记录。
它是把各个不同操作型数据的详细信息聚集在一个记录中而形成的。一个简要记录的创建以
聚集的形式代替了许多条操作型记录。
简要记录可以象单个活动记录那样用来表示数据快照。二者之间的区别是：数据仓库中
的单个活动记录代表了一个单一的事件，而简要记录则代表的是多个事件。
如同单个活动记录一样，简要记录也是由某些已经发生的事件触发时，这些事件或者是
业务活动，或者是正常时间推移的标记。图 3 - 4 3说明了一个事件是怎样导致一个简要记录的
创建的。
操作型环境
顾客数据仓库
用户/月
呼叫1
呼叫2
呼叫3
呼叫4
呼叫n
聚集每月的呼叫以提供一个单一的合成记录
图3-43 从一系列详细记录创建一个简要记录
简要记录是由许多详细的记录聚集而创建的。如电话公司可能在月底整理用户在本月所
有的电话活动情况，把这些活动聚集在数据仓库中的一个客户记录中。这样，一个单一的记
录就被创建了，它所反映的是客户在一个月之内的所有活动情况。或者银行把一个顾客全月
的活动收集起来创建一条聚集的数据仓库记录，这条记录记载了客户这个月内的所有银行活
动。
操作型数据聚集形成一条数据仓库记录的过程可以采取多种形式，如：
■ 可以对操作数据的取值进行概括。
■ 可以对操作数据单元进行计数，以便获得单元的总数。
■ 可以对数据单元进行一些处理，以找出最高值、最低值、平均值等。
■ 可以捕获第一个和最后一个事件。
■ 落入几个参数限界之内的某些类型的数据可以被量度。
■ 在一段时间内有效的数据可以被捕获。
74 数据仓库
下载
■ 最老的数据和最新的数据可以被捕获。
有多少种算法和想象力，就有多少种方式可以表现操作型数据的聚集。
建立简要记录的另一个值得注意的好处是为用户的访问和分析提供了一种紧凑的方便的
数据组织形式。采用这种方式，终端用户会感到很方便。因为通过把许多记录聚集为一个记
录，用户仅仅一次就可以找到他所需要的数据。这种数据组织方式通过在数据仓库中的数据
聚集把用户从大量的劳动和繁重的处理中解放出来。
3.13 管理大量数据
有时候数据仓库中需要进行管理的大量数据是一个重要问题。建立简要记录是大量数据
管理的一种有效技术。在把操作型环境中的详细记录转入数据仓库中简要记录的过程中，数
据量的降低是显著的。一般通过建立简要记录可以使数据量降低 2～3个数量级。由于这种可
能性，创建简要记录是每一个数据体系结构设计人员手中很强有力的一种技术。事实上，与
其他设计或数据管理技术相比较，要想在数据仓库中有效地管理大量数据，那么建立简要记
录应该是数据仓库体系结构设计者应该考虑的首选技术和最强有力的技术。
然而，采用这种方式也有其不足之处。当采用简要记录方式的时候，必须清楚的是这样
将会失去数据仓库的一些能力或功能。首先，只要实现数据的聚集，信息的详细程度就会降
低。但有时，详细程度的降低不一定是坏事。这时的设计者必须能够保证详细程度的降低对
于利用该数据仓库进行决策支持的分析人员来讲是无关紧要的。数据仓库构造者保证所丢失
的细节并不特别重要的第一道防线 (最简单有效的)就是重复建立简要记录。这样设计人员就有
了很好地控制改变的灵活性。简要记录内容设计的第一遍为第二遍提供依据，依此类推。只
要数据仓库开发过程中每一遍走得很小，很快。就不至于在简要记录中忽略对终端用户来讲
是重要的某种要求。但是当简要记录的创立和开发的第一遍走得非常大，设计者可能会把他
们自己带入危险的境地。此时，由于数据仓库相当大，它的内容不能被仔细改动而导致重要
细节的忽略，使设计人员可能使自己陷于难堪的境地。
可以保证重要细节在简要记录的创建过程中不被丢失的第二种方法 (可以和第一种共同使
用)是在建立简要记录的同时建立历史细节的备用层，如图 3-44所示。
ESS
DSS
简要
数据标准DSS处理
操作型数据
详细
存档
数据在异常基础上
的报告
图3-44 另一种典型数据仓库体系结构—所有的细节数据在需要的时候都可以得到，
而对于DSS处理的最好性能是常规性能
下载
这种备用的细节并不会被经常用到。它被存储在较慢的便宜的顺序读取的介质上。在任
何情况下都不容易访问到，使用起来相当麻烦。但是一旦需要的话，细节确实是存在的。当
管理部门确实需要这些信息的时候，它们总可以被找到，尽管需要花费一些时间和金钱。
3.14 创建多个简要记录
一个细节可以用来创建多个简要记录。如电话公司的单个电话记录可以用来创建客户简
要记录，地区通信量简要记录，线路分析简要记录，等等。
简要记录可以被置入数据仓库或者置入数据仓库所支持的数据集市。当简要记录进入数
据仓库时是面向普通应用的，而进入数据集市时则是为了适应部门应用的。
操作型记录聚集成一条简要记录的过程通常是在操作型服务器上完成的。这是因为操作
型服务器足以管理大量的数据，而且这些数据任何情况下都驻留于服务器上。通常创建简要
记录的过程就是给数据排序和进行合并的过程。一旦建立快照的过程变得十分复杂冗长时，
就应该怀疑是否有必要建立快照。
简要记录中写入的元数据记录非常类似于单一活动快照中写入的元数据记录。不同的是，
聚集记录的过程成为一条重要的元数据。 (从技术上讲，聚集过程产生的记录是“元过程”信
息，而不是“元数据”信息。 )
3.15 从数据仓库环境到操作型环境
操作型环境与数据仓库环境的不同与任何两个环境可能的不同是一样的。从内容、技术、用
途、所服务的群体等许多方面来讲都是不同的。二者之间的接口被很好地说明。数据从操作型环境
到数据仓库环境要经过一次基本的转换。从操作型环境到数据仓库通常的数据流向如图
3-45所示。
数据仓库
传统应用
图3-45 在传统应用/数据仓库体系结构设计环境中的数据正常流动
有时会有这样的问题，从数据仓库环境到操作型环境可以传送数据吗？换言之，数据是
否可以反向传送？从技术角度讲，当然可以。这种数据传送在技术上是可行的，然而使数据
“回流”本身是不正常的。
3.16 正常处理
在正常情况下，数据不会从数据仓库流向操作型环境。由于各种原因，如业务活动的顺
序，对操作型处理的高性能的需求，数据寿命，操作型处理的较强的面向应用的特性，等等，
76 数据仓库
下载
使得从操作型环境到数据仓库的数据流动是很自然的，正常的。但是，在一些特别情况下，
的确需要数据的“回流”。
3.17 数据仓库数据的直接访问
图3 - 4 6说明了在那些最简单的动态的数据回流，即由操作型环境对数据仓库环境进行直
接的数据访问。在操作型环境中向属于数据仓库的数据提出了访问请求。这个请求被传送到
数据仓库中，然后找到所需要的数据，接着再传输到操作型环境中。很明显，从动态的角度
来看，传送过程的实现不会是简单的。
传统应用
查询
数据仓库
查询的结果
图3-46 一个从传统应用环境对数据仓库的直接查询
在直接访问数据仓库数据的过程中，有一些严格的、不能让步的限制。下面列出了一些
这类限制。
■ 从响应时间的角度来讲，这个请求必须能够忍受冗长的响应时间。它可能在经过 2 4个
小时后才被响应，这意味着请求数据仓库数据的操作处理并不具有在线特性。
■ 所请求的数据量必须是最小量的。数据的传输是以字节计的，而不是兆字节或千兆字节。
■ 管理数据仓库所用到的技术必须与管理操作型环境所用到的技术一致，如容量、协议等。
■ 从数据仓库取得的准备传输到操作型环境的数据必须不做或做最小的格式化。
这些条件限制了数据从数据仓库到操作型环境的数据传送。很容易明白在数据的直接访
问时为什么仅仅有少量的数据回流。
3.18 数据仓库数据的间接访问
由于严峻的不可妥协的传输条件，由操作型环境到数据仓库数据的直接访问很少发生。但
是，对数据仓库数据的间接访问则是另一回事。事实上，数据仓库的一个有效的应用就是操
作型环境对数据仓库的间接数据访问。一些间接访问数据仓库数据的例子可以充分说明这点。
3.18.1 航空公司的佣金计算系统
间接使用数据仓库数据的一个例子是在航空公司。为了能够理解这个例子，需要一些航
空公司预定和售票方面的知识。
考虑如图 3 - 4 7所示的航空公司定票事务。旅行社代表客户与航空公司机票预定服务人员
交涉。这个客户想购买一张飞机票而旅行社需要知道以下问题：
■ 还有座位吗？
下载
■ 座位票价是多少？
■ 旅行社能获得多少佣金？
4月15日有没有从巴
黎到纽约的座位？
旅行社代理
航空公司预定职员
图3-47 一个典型的商业交易
如果航空公司支付太多的佣金，他们将获得旅行社的这笔交易，但是会损失一部分钱。
如果佣金太少，这家航空公司可能会失去这笔交易，旅行社将会寻找另外一家支付佣金较多
的航空公司完成这笔交易。航空公司有必要在其最佳利益范围内非常仔细地计算所应支付的
佣金，因为这直接关系到它的底线。
旅行社代理和航空公司职员之间的交易必须在很短的时间内完成，比如 2～3分钟之内。
在这么短的时间内，航空公司职员必须输入完成一系列事务处理，如：
■ 是否有剩余座位？
■ 座位是否可优先使用？
■ 联系哪些航班？
■ 是否能联系上？
■ 票价多少？
■ 佣金多少？
如果航空公司职员(与旅行社代理交流时运行多个事务)的响应时间太长，那么航空公司将会
因此而失去交易。因此，出于航空公司的最高利益必须尽量缩短与旅行社对话过程中的响应时间。
佣金的计算成为交易中的重要组成部分。最佳佣金的计算将考虑两个因素 — 当前的预定
情况和历史情况。当前的预定情况提供了目前飞机票的预定情况。而历史情况则提供从前一
段时间的定票情况。二者之间可以计算出一个合适的佣金。图 3-48说明了参与计算的元素。
最佳的佣金是下面因素的函数
当前订票
旅行社代理
历史订票
图3-48 最佳的佣金通过比较当前订票和历史订票计算得来
78 数据仓库
下载
人们希望通过联机方式完成预定和航班历史情况的计算。但是所需处理的数据量很大，
如果采用联机方式，势必会影响到响应时间。相反，在有足够机器资源的地方，采用脱机方
式完成佣金计算和航班历史分析。图 3-49说明了采用动态的脱机佣金计算方法。
脱机计算和分析定期进行，且需要建立一个小的易于访问的航班状态表。当航空公司职
员与旅行社代理交互时，很容易查阅现有定票情况和航班状态表。结果，二者之间的对话很
迅速，且很好地利用了数据仓库的数据。
当前订票历史订票
旅行社代理
航班状态计算
航班日期
日期的平均订票
图3-49 航班状态文件通过读取历史数据周期地创建，它是航空公司代理快速获得
当前订票以及与历史平均订票情况比较的手段
3.18.2 零售个性化系统
在操作型环境中，间接使用数据仓库数据的另一个例子是零售个性化系统。在这样的系
统中，客户阅读到由零售商编制的目录或宣传广告后促使他有了购买的念头，或者至少想查
询一下目录，结果是给零售商打电话。图 3-50表明了零售商和客户之间的对话。
我在你们的目录中看到
感兴趣的东西你能介绍
一下吗？
目录
客户
电话推销员
图3-50 顾客看了邮件中的目录，希望得到更多信息
下载
这种对话可能持续 5～8分钟。这段时间内零售商的代表需要做一系列的事情 — 确定客
户，记下所需的定货信息等。响应时间必须简短，否则客户将失去兴趣。
当客户定货或咨询情况时，零售商代表查出一些与此有关的其他信息，如：
■ 客户上次购物的时间。
■ 上次购物的类型。
■ 客户所属的市场地段。
与客户对话的过程中，销售代表说出以下一些事情：
“我记得我们曾在二月份通过话”
“你购买的兰色运动衫怎么样？”
“你的那条裤子的问题解决了吗？”
一句话，销售代表有必要使交谈进行得很有人情味。这样，将会更加激起客户的购买欲
望。
另外，销售服务人员应该拥有市场地段信息，如：
■ 男/女
■ 专业/其他用品市场
■ 城市/乡村市场
■ 儿童用品市场
• 年龄
• 性别
■ 体育用品市场
• 鱼具
• 猎具
• 沙滩用具
因为对话可以进行得很个性化。而且有可用的客户所属的市场地段信息。因此，当客户
打入电话时，销售代表能够进行针对性的提问，如：
“你知道我们在泳装方面还有未公布的产品吗？”
“我们刚刚进一批意大利太阳镜，我想你可能有兴趣。”
“天气预报这是打野鸭的寒冬，我们有一种特制的长筒靴。”
客户已经完全投入了电话对话中，个性化的电话和关于客户对什么商品感兴趣的知识使
得销售商在不增加资本投入、不增加广告量的情况下增加收入。
这种个性化的电话对话正是通过对数据仓库的间接访问而完成的。图 3 - 5 1表明如何达到
这种个性化的动态过程。
后台(即数据仓库环境中 )有一个分析程序在不断读入和分析客户的记录。这个分析程序通
过一种复杂的方法扫描，分析客户的历史记录。它定时地提供给操作型环境一个包括下面内
容的文件：
■ 上次购物的日期。
■ 上次购物的类型。
■ 市场分析/市场地段信息。
当客户打入电话时，联机准备好的文件就等待由零售销售代表使用。
80 数据仓库
下载
目录
• 客户历史
• 销售历史
• 产品历史
• 销售商历史
客户
电话推销员
市场分析程序
客户历史文件
客户ID
• 上次购货日期
• 上次所购项目
• 产品市场分类
图3-51 客户历史被电话推销员立即利用
3.18.3 信用审核
间接利用数据仓库的另一个例子是银行金融领域的信用审核过程。它是用来确定一个客
户是否有资格获得贷款的一种审核过程。图 3 - 5 2说明了一个以交互模式进行的信用审核案
例。
您可以为我购买汽是的，如果你能向我
车贷款$15 000吗？介绍一下你自己。
客户出纳员
图3-52 联机贷款过程
在图3 - 5 2中，客户来到出纳员的窗口要求贷款。出纳员询问用户的一些基本信息，然后
下载
决定是否提供贷款。这种交互过程也发生在一个很短的时间内 — 大概5～10分钟。
客户出纳员 • 账户历史
• 偿还历史
• 工作历史
• 工资历史
• 资产管理历史
图3-53 同意贷款前先检查客户历史
为了确定是否应该提供贷款，需要进行一些处理，如图 3-53所示。
贷款请求首先经过一个简单审核处理。如果贷款金额较小，而且贷款人有一个稳定的经
济背景，那么就可以决定给他提供贷款，而不必再加以审核。然而，如果贷款金额较大，或
者贷款人没有稳定的经济来源，那么就需要继续审查。
后台审核程序依赖数据仓库。事实上，这种审核是综合的，需要对客户的各个方面进行
调查。例如：
■ 偿还历史。
■ 私有财产。
■ 财务管理。
■ 净值。
■ 全部收入。
■ 全部开销。
■ 其他的无形资产。
这种大范围的背景检测过程需要大量的历史数据。完成贷款审核中的这个处理过程需要
花几分钟的时间。
为了在最短的时间内满足尽可能多的客户要求，需要编写一个分析程序。图 3 - 5 4说
明了这个分析程序是如何与信用审核过程中其他部件协调工作的。分析程序定期启动，
它为操作型环境提供了一个可用文件。除了其他数据以外，这个文件应包括以下信息：
■ 客户识别信息。
■ 核准信贷限制。
■ 特殊的核准限制。
这样，当客户想申请获得贷款时，出纳员利用高性能的联机方式就可以给予 (或不给
予)客户贷款请求。仅当客户贷款金额超过预先核准的限额时，才需要经过贷款官员的进一
步审核。
82 数据仓库
下载
• 账户历史
• 偿还历史
客户出纳员
• 工作历史
• 工资历史
• 资产管理历史
预核准客户文件预核准/预分析程序
图3-54 预核准客房信用文件立即被银行出纳员访问
3.19 数据仓库数据的间接利用
对于间接利用数据仓库来讲，还有一种正在出现的模式，如图 3-55所示。
由一个程序对数据仓库进行定期的分析，以检验相关的特征和标准。这种分析过程将在
联机环境中产生一个小文件，其内容包括了有关企业业务方面的简明信息。这个文件被有效
快速地利用，以满足操作型环境中其他处理的需要。
联机环境
数据仓库
分析/预备程序
图3-55 数据仓库数据被联机操作型环境间接应用的方法
下面是间接使用数据仓库数据时应考虑的因素。
■ 分析程序：
• 拥有许多人工智能的特征。
• 可以运行在任何可用的数据仓库中。
• 在后台运行，这样处理时间就不是一个问题 (至少不是一个大问题 )。
下载
• 程序的运行与数据仓库发生变化的速度一致。
■ 周期性刷新
• 不是经常进行。
• 采用一种替代模式操作。
• 从支持数据仓库的技术传送数据到支持操作型环境的技术。
■ 联机预分析数据文件
• 每个数据单元仅仅包括少量的数据。
• 总体上可以包含大量的数据 (因为可以有很多的数据单元 )。
• 准确地包含了联机处理人员所需要的东西。
• 不被修改，但是定期全部刷新。
• 是联机高性能环境的一部分。
• 访问效率高。
• 可以访问单个数据单元，而不是以块的形式访问数据。
3.20 星型连接
数据模型作为一种数据仓库的设计基础，在实际应用中还存在许多缺点。考虑图 3 - 5 6所
示的简单数据模型。
供应商客户
产品
订单
发货
图3-56 一个简单的二维模型给人的印象是所有的实体都是等同的
图3 - 5 6中所示的数据模型中有四个相互关联的简单实体。如果数据库设计只需要考虑数
据模型的话，可以推断所有的实体都是平等关系。换言之，从数据模型的设计角度来看，所
有的实体之间的关系是对等的。仅仅从数据模型的角度来着手设计数据仓库会产生一种“平
面”效应。实际上，由于种种原因，数据仓库的实体绝不会是相互对等的。一些实体，要求
有它们自己的特别处理。为了明确为什么从数据模型的角度看一个组织中的数据和关系会发
生失真，根据在数据仓库中建立实体时将载入数据实体的数据量，我们来考虑数据仓库中数
据的一种三维透视。图 3 - 5 7表明了这种三维透视。代表供应商、客户、产品、发货的实体被
稀疏地载入，而代表订单的实体则大量地载入。将会有大量的数据载入代表订单实体的表中，
而在代表别的实体的表中载入的数据量则相对较少。由于大量的数据要载入订单实体，因此
需要一种不同的设计处理方式。
84 数据仓库
下载
发货
供应商
客户订单产品
图3-57 实体的三维透视表现出实体并不是平等的，有些实体包含的数据远远超过其他实体
用来管理数据仓库中载入某个实体的大量数据的设计结构被称为“星型连接”。图3 - 5 8给
出星型连接的一个简单例子。“订单”位于星型连接的中央。它是被大量载入数据的实体。在
其周围分别是“产品”、“客户”、“供应商”和“发货”实体。这些实体仅仅会产生不大的数
据量。星型连接中央的“订单”被称作是“事实表”，而其周围的其他实体 — “产品”、“客
户”、“供应商”和“发货”则被称为“维表”。事实表包含了“订单”独有的标识数据，也包
含了订单本身的独有数据。事实表还包含了指向其周围的表 — 维表的外键。如果非外键的
信息经常被事实表使用，那么星型连接内的非外键信息将会伴随外键的关系共同存在。例如，
如果“产品”的描述将被“订单”处理过程经常用到的话，那么这个描述将会与产品号一起
存储在事实表中。
订单
供应商发货
客户产品
图3-58 一个简单的星型连接，其中“订单”实体会由许多数据载入，其他实体与数据预连接
可以有任意多个外键与维表相关。当有必要检查外键数据与事实表中的数据时，就创建
一个外键关系。
创建和使用星型连接的一个有趣的方面是，在很多情况下，文本数据与数值数据是分离
开的。考虑图 3 - 5 9所示的图表。文本数据常出现在维表中，数值数据常出现在事实表中，这
种划分似乎在所有情况都会发生。
创建和使用星型连接的好处是可以为决策支持系统的处理优化数据。通过数据预连接和建立
有选择的数据冗余，设计者为访问和分析过程大大简化了数据，这正是数据仓库所需要的。应该
下载
注意，如果不是在决策支持系统数据仓库环境中使用星型连接，则会有很多的缺点。在决策支持
系统数据仓库环境以外，常有数据更新，而且数据关系的管理要在秒的一级上进行。在这种情况
下星型连接在创建和维护上就是很麻烦的数据结构。但是由于数据仓库是一个装载—访问环境，
它包括很多历史数据，且有大量的数据要管理，因此，星型连接的数据结构是十分理想的。
事实表
维表订单维表
供应商发货
客户产品
数字字符
图3-59 通常事实表格放置数字数据和外键，而维表则放置字符数据
事实表
维表订单
维表
供应商发货
客户产品
星形连接
图3-60 传统数据模型应用于维表即数据不多的实体，星形连接应用于事实表(即数据量大的实体)
86 数据仓库
下载
是不是星型连接结构的存在意味着数据模型不是设计数据仓库的基础了呢？完全不是！
数据模型对于大多数数据仓库环境的设计来讲，仍然是非常有用的一种结构。然而，星型连
接有它本身的恰当位置。图 3 - 6 0说明了数据仓库决策支持系统的设计中星型连接和数据模型
是怎样配合起来使用的。星型连接应用于设计数据仓库中很大的实体，而数据模型则应用于
数据仓库中较小的实体。
3.21 小结
数据仓库的设计始于数据模型。企业数据模型用于操作型环境的设计。企业数据模型的
一种变型用于数据仓库的设计。数据仓库以反复开发的形式建立。对于数据仓库的需求是不
可能预先知道的。数据仓库的构造是在与传统操作型系统完全不同的开发生命周期中进行的。
数据仓库开发者面临的基本问题是管理大量数据。为此，数据的粒度和分割是数据库设
计的两个最重要问题。然而，也存在许多其他物理设计问题，其中大多数都与数据访问的效
率有关。
下载
第4章数据仓库中的粒度
数据仓库开发者需要解决的最重要的单一设计问题是数据仓库中的粒度确定。当数据仓
库的粒度合理确定后，设计和实现的其他问题就会非常容易地解决，相反如果没有合理地确
定粒度的话，就会影响其他每个方面。
对选择合适级别的粒度的权衡 — 像我们在以前已讨论过的 — 将集中讨论在高粒度级别
上管理大量数据和存储数据，数据的细节的用法将不被考虑。
4.1 粗略估算
确定合适的粒度级的起点，是粗略估算数据仓库中将来的数据行数和所需 D A S D(直接存
取存储设备)数。毫无疑问，即使在最好的情况下我们也仅能做一下估计。但在建立数据仓库
之初，所需的只是一个数量级上的估计。
有一个计算数据仓库所占的空间的算法，如图估计数据仓库环境中的行数/空间大小
4 - 1所示。第一步是确定数据仓库中将要创建的所 1. 对每一个已知的表：
有表。然后，估计每张表中的行的大小。确切大计算一行所占字节数的
－最大估计值
小可能难以知道，估计一个下界和一个上界就可
－最小估计值
以了。对一年内：
接下来，估计一年内表中的最少行数和最多最大行数可能是多少？
行数。这是设计者所要解决的最大问题。比方说最小行数可能是多少？
一个顾客表，就应该估计在一定的商业环境和该对五年内：
最大行数可能是多少？
公司的商业计划影响下的当前的顾客数；如果当
最小行数可能是多少？
前没有业务，就估计为总的市场业务量乘以市场
对表的每个键码：
份额；如果市场份额不可知的话，就用竞争对手该键码的大小(按字节)是多少？
的业务量来估计。总之，要从一方或多方收集顾一年总的最大空间 =最大行大小×一年内最大行数
客的合理估算信息开始。一年总的最小空间 =最小行大小×一年内最小行数
累加索引空间
如果数据仓库是用来存放业务活动的话，就要
2. 对所有已知的表重复第 1步。
估计顾客数量，以及估计每个时间单位内业务活
动量。同样，可用相同的方法分析当前的业务量、图4-1 空间/行数计算
竞争对手的业务量、经济学家的预测报告，等等。
一旦估计完一年内数据仓库中数据单位的数量(用上下限推测的方法)，就用同样的方法对
五年内的数据进行估计。
粗略数据估计完后，就要计算一下索引数据所占的空间。对每张表(对表中的每个键码)确
定键码的长度和原始表中每条数据是否存在键码。
现在将各表中行数可能的最大值和最小值分别乘以数据的最大长度和最小长度。另外，
还要将索引项的数目与键码的长度的乘积累加到总的数据量中去。
88 数据仓库
下载
4.2 粒度划分过程的输入
可以将估计的行数和 DASD数作为粒度划分过程的输入，如图 4-2所示。

此时，数量级的精确性才是最重要的。
需要多少DASD？排序的
引导时间估计是多少？
空间估算，行估算
需要双重粒度吗？
图4-2 使用空间估计的结果
4.3 双重或单一的粒度？
一旦上面的估计完成后，下一步就要将数据仓库环境中总的行数和图 4 - 3中所示的表格进
行比较。根据数据仓库环境中将具有的总的行数的大小，设计和开发必须采取不同的方法。
以一年期为例，如果总的行数小于 10 000 行，那么任何的设计和实现实际上都是可以的。如
果一年期总行数是 100 000行或更少，那么设计时就需小心谨慎。如果在头一年内总行数超过
1 000 000行，那么就要请求采取双重粒度级。如果在数据仓库环境中总行数超过 10 000 000行
的话，必须强制采取双重粒度级，并且在设计和实现中应该小心谨慎。
对于五年期，行的总数大致依据数量级改变。对五年以后的推测是：
■ 在管理数据仓库中的大量数据时，将有更多的专门技术可用。
■ 硬件费用有所下降。
■ 可以使用功能更强大的软件工具。
■ 最终用户更加专业化。
所有的这些因素表明在一段长的时间内可以管理更大的数据量。
有趣的一点是，数据仓库存储时总的字节数与数据仓库的设计和粒度是几乎没有关系
的。换句话说，记录是 2 5个字节长或 2 5 0个字节长是没有关系的。图 4 - 3所示的表仍旧可用。
原因与数据的索引有关，不论被索引的记录的大小，都需要同样数量的索引项。只有在一
下载
第4章数据仓库中的粒度 89
些特殊情况下，被索引的记录的实际大小才影响决定数据仓库是否采用双重级粒度的策略。
一年期五年期
10 000 000 双重粒度级且认真设计 20 000 000 双重粒度级且认真设计
1 000 000 双重粒度级 10 000 000 双重粒度级
100 000 认真设计 1 000 000 认真设计
10 000 实际上任何设计都行 100 000 实际上任何设计都行
图4-3 粒度的阈值
4.4 确定粒度的级别
完成了一些简单分析之后(事实上，这时大多数公司发现他们需要双重粒度)，下一步就要
精确地确定粒度的级别。开始时是需要一些常识和直觉的。在很低的细节级上建立轻度汇总
的数据级是没有意义的，因为需要太多的资源来处理数据。而在太高的细节级上建立轻度汇
总的数据级，则意味着许多分析必须在真实档案级上进行。因此确定轻度汇总的粒度级的第
一件事是进行有根据的猜测。
但进行有根据的猜测也只是一个开端。还需要一定数量的反复分析来改进这个猜测，如
图4 - 4所示。对于轻度汇总的数据为了确定合适的粒度级别，唯一可行的方法是将数据拿到最
终用户的面前。只有当最终用户实际看到了数据之后，我们才能作出确定的回答。图 4 - 4说明
了我们所需做的反复的循环。
开发者
设计，载入
报表/分析
数据仓库
DSS分析员
经验规则：在第一次的设计周期中，如果 50%的工作是正确的，那么整个设计就是成功的
• 快速建立数据仓库的很小的子集并认真听取用户的反馈意见。
• 用原型法。
• 看看别人做了些什么。
• 找一个有经验的用户协同你工作。
• 看看机构现在已经有了些什么。
• 用模拟的输出进行 JAD(联合应用程序设计 )会议。
图4-4 最终用户的态度：“既然我看到了我能够做些什么,我就能告诉你什么是真正有用的。”
90 数据仓库
下载
4.5 一些反馈循环技巧
我们可以用以下的一些技巧来使反馈循环成为一个和谐的循环：
■ 用很小而很快的步伐建立数据仓库最初的几个部分，仔细聆听最终用户的意见。随时
准备做快速的调整。
■ 如果可以使用原型工具的话应用原型法，并使用从原型中收集的观察结果而使反馈循
环起作用。
■ 看看别人是怎样确定他们的粒度级别，学习一下他们的经验。
■ 与一个对整个过程了解的有经验的用户一起进行反馈的处理。不论什么时候都让你的
用户在暗中作为反馈循环的动力。
■ 看看本机构现在有什么系统正在运转。
■ 进行JAD会议并模拟其输出以得到想要的反馈。
有好多方法用来提高数据的粒度，如以下所列：
■ 当源数据置入数据仓库时，对它进行汇总。
■ 当源数据置入数据仓库时，对它求平均或进行计算。
■ 把最大/最小的设定值置入数据仓库。
■ 只把显然需要的数据置入数据仓库。
■ 用条件逻辑选取记录的一个子集置入数据仓库。
对于数据怎样轻度汇总是没有限制的(限制只存在于设计者的脑海里)。
有一点很重要，在典型的需求系统的开发中，在还不清楚大部分需求之前就忙于进行是
不明智的。但在数据仓库的建造中，如果已知了至少一半的需求后，还不开始同样也是不明
智的。换句话说，在建造数据仓库中，如果开发者想等着大多数需求明了后才开始工作，那
么这个仓库是永远建不起来的。尽快启动与 DSS分析员的反馈循环是非常重要的。
4.6 粒度的级别— 以银行环境为例

以如图4-5所示的一个银行或金融环境的简单数据结构为例。
在左边(在操作级上)是操作型数据。在这里我们可以看到银行业务的详细数据。六十天的
活动数据都存储在操作型的联机环境中。
操作型数据的右边是轻度汇总级的数据，总共是十年的活动记录。对于给定帐户，特定
月份的活动记录存储在数据仓库的轻度汇总部分。由于记录很多，所以这部分比原记录更加
简洁。在轻度汇总数据级有更少的 DASD数和更少的行。
当然，也有真实档案级的数据，其中存储着每一个细节的记录。真实档案级的数据存储
在适合于大量数据管理的媒体上。请注意并不是数据的所有字段都传送到真实档案级中去，
只有那些由于有合法的理由、信息性理由等所需要的域才被存储。那些即使在档案模式中以
后有用的数据在传送到真实档案级时也会从系统中清除出去。
真实档案级数据可以存储在如磁带机这样一种单一的媒体上。磁带机作为存储介质非常
便宜，但作为访问介质是非常昂贵的。然而，我们可以将有可能需要访问的一小部分的真实
档案级数据联机存储，这是完全可能的。例如，一个银行可以将最近 3 0天的业务记录联机存
储。最近 3 0天的数据是真实档案数据，而它们仍旧是联机的。 3 0天结束后，这些数据被送到
磁带机上，腾出的空间就可以存放下一个 30天的真实档案数据。
下载
在银行环境中的双重粒度
操作型
最近60天的业务活动长达十年的每月的帐户记录
帐户帐户
业务活动日期月份
数量业务次数
出纳号提款
地点储蓄
给谁月初结余
标识码月末结余
帐户结余帐户最高值
仪器号帐户最低值
……… 平均帐户结余
………
帐户
业务活动日期
数量
给谁
标识码
帐户结余
仪器号
………
图4-5 在银行环境中一个双重粒度的简单例子
现在考虑银行/金融系统体系结构设计环境中数据的另一个例子，如图 4-6所示。
图4 - 6显示了整个环境中客户的记录。操作型环境中显示了当前使用的准确的客户数据，
在轻度汇总级存放的也是同样的数据(通过数据的定义)，但只是一个月中某个时刻的快照。
还有一个连续的文件存放长时间范围的数据(过去 10年的数据)，它是从每月文件中产生的。
用这种方式，一个客户的历史记录能被追溯到很长一段时间。
再来看另一类企业 —制造业中体系结构设计环境的一个例子，如图 4-7所示。
在操作级上是完成若干给定部件的组装的生产线的记录。随着生产线的运转，每一天都
会积累许多记录。
轻度汇总级包括两个表，一个汇总某一部件一天中的生产情况，另一个汇总生产线上的生
产情况。部件生产累计表存放的是90天内的数据，而组装表只存放一天汇总的的生产情况数据。
真实档案级的数据包括每个生产活动的详细记录。而在银行系统中只有以后有用的数据
92 数据仓库
下载
在银行环境中的双重粒度
当前客户的数据上个月客户的记录文件
客户ID 客户ID
姓名姓名
地址地址
电话电话
雇主雇主
信用度信用度
月收入月收入
依靠依靠
有无住房？有无住房？
职业职业
…… ……
过去十年内客户的记录
客户ID
起始日期
结束日期
姓名
地址
信用度
月收入
有无住房？
职业
……
图4-6 银行环境中双重粒度的另一种形式
字段才被存储(事实上是以后有可能有用的字段)。
图4 - 8所示是制造业环境中另一个关于数据仓库粒度的例子。在操作型环境中有一个活动
订单文件，存储所有需要生产活动的订单。数据仓库中存放的是 1 0年内的订单历史。订单历
史表有一个主键码和多个辅键码。只有以后用于分析的数据才存储在数据仓库中。但订单数
量太少，没有必要置入真实档案级。当然，如果开始出现过多的订单，那么置入一个较低的
粒度级也可能是必要的。
下载
在制造业环境中的双重粒度
最近30天内每天的生产记录积累90天的生产记录
部件号
部件号
日期
日期完成总量
数量使用总量
被组装总废品率
组装成按时完成批量
生产订单滞后完成批量
废品率一年内的组装记录
按时否
组装ID
存放位置
部件号
责任工长日期
总量
批量
按时
滞后
真实档案级
部件号
日期
数量
被组装
组装成
生产订单
废品率
按时否
责任工长
图4-7 制造业环境中的某些不同粒度级别
请看另外的一个例子，如图 4 - 9所示，这是一个适合保险公司体系结构设计环境中数据的
粒度转换。保险费支付信息收集在一个活动文件中。然后过一段时间，这些信息传送到数据
仓库中。因为这里的数据相对较少，所以用双重粒度是没有必要的。然而，由于保险费交付
的定期性特点，交付数据是作为一个数组的一部分存放在数据仓库中的。
看一下如图 4-10所示的保险业环境中体系结构的另一个例子，注意它的保险索赔信息。
在当前的索赔系统中(环境的操作型部分)，存储了索赔的大量详细数据。当一个索赔已解
决(或已确定不予解决)，或者索赔隔了好长时间还未办理，这个索赔的信息就被传送到数据仓
库中去。在传送时，索赔信息用多种方式汇总 — 按每个代理在每个月，按每个月索赔的类
型，等等。在一个较低的详细级别上，索赔信息在真实档案级上无限期地保存着。在数据传
送到真实档案级的其他情况下，只有那些以后有可能用到的数据才保留下来(它们是在操作型
94 数据仓库
下载
环境中找到的大部分信息)。
制造业环境中粒度的级别
分别索引
最近2年内的活动订单十年内的订单历史
订单号
订单号
客户
订单日期
部件号
客户
数量部件号
订单日期
数量
交货日期
运费
运往
交货迟否？
加急
运费
联系人
运货单位
……
图4-8 订单太少，不需要双重粒度
保险业环境中的双重粒度
保险金支付记录(活动的)
保险号
支付日期保险金记录历史(10年内)
滞后日期
保险号
数量
年
调整保险金 — １
应付日期
支付日期
数量
迟交收费
保险金 — ２
应付日期
支付日期
数量
迟交收费
…………
图4-9 保险金支付记录的数量很少，故没有必要用双重粒度，并且由于允许保险金记帐，
就有机会来创建一个数据组
下载
保险业环境中的双重粒度
当前的索赔记录 10年内按月的代理/索赔
索赔单号代理
保险单号月份
索赔日期总索赔
数量总数量
提供的解决方案解决
索赔类型
无过失 10年内按月的代理/索赔
接受的解决方案
不接受的理由
仲裁？索赔类型
损坏估计月份
损失估计总索赔
未保险的损失总数量
共同保险？单次最大索赔
………… 解决
真实档案的，
不限时间
索赔单号
保险单号
索赔日期
数量
提供的解决方案
索赔类型
无过失
接受的解决方案
不接受的理由
仲载？
损坏估计
损失估计
未保险的损失
共同保险？
…………
图4-10 在数据仓库的轻度汇总部分存放了按非主键码汇总的索赔信息。
索赔信息必须作为数据仓库体系结构中的真实档案部分无限期地存放
以上就是在不同行业中粒度和体系结构设计环境的一些例子。
4.7 小结
选择合适的粒度级别是体系结构设计环境成功的关键。选择粒度级别的一般方法，是利
用常识，建立数据仓库的一小部分，并让用户去访问这些数据。然后仔细聆听用户的意见，
根据他们的反馈意见适当调整粒度的级别。
最坏的想法是想要事先设计好所有的粒度级别，再进行数据仓库的建造。即使在最好的
情况下，能使设计的 5 0 %是正确的就已经很不错的了。数据仓库环境的特点就是只有当决策
支持系统分析员实际看到了报告之后，才能想像哪些是真正需要的。
下载
第5章数据仓库和技术
在许多方面，数据仓库比数据库需要一系列更简单的技术。数据仓库中没有联机的数据
更新；只有非常少的一些锁定需要；而且对于远程处理接口的需要也只是最基本的；等等。
然而，数据仓库有许多技术上的需求。这一章就讲述一下这方面的要求。
5.1 管理大量数据
对于数据仓库，第一个也是最重要的技术需求就是能够管理大量的数据，如图 5-1所示。
第1个技术需求 —
管理大量数据的能力
能够管理多种介质
索引
能够轻松容易地索引和监视数据
报告
对于接口 — 用各种不同的
技术接受和传送数据
图5-1 对支持数据仓库的技术的一些基本需求
下载
第5章数据仓库和技术 97
有好多种管理大量数据的方法 — 通过寻址，通过索引，通过数据的外延，通过有效的溢
出管理，等等。管理大量的数据有两方面 — 能够管理大量数据的能力和能够管理好的能力。
任何声称支持数据仓库的技术一定都要满足能力与效率的要求。
数据仓库开发者建造数据仓库时，在理想的情况下是假定其能够满足处理大量数据的需
求的。在开发和实现数据仓库的时候，如果开发者不得不对技术进行扩展以适应数据仓库，
那么所用的基本技术就存在一定的问题。
当谈到数据仓库时，问题不仅是基本的技术及其效率，还有存储和处理的费用也是要考
虑的因素。
5.2 管理多介质
在处理大量数据时，为了满足高效率和合理的费用，应用在数据仓库中的基本技术应该
能够解决多种存储介质的问题。仅仅在 DASD上管理一个成熟的数据仓库是不够的。考虑到访
问速度和存储费用，对数据的存储要分层次。层次的区分如下：
主存 — 非常快 — 非常贵
扩展内存 — 非常快 —贵
高速缓存 — 非常快 —贵
DASD —快 — 适中
光盘 — 不慢 — 不贵
缩微胶片 —慢 — 便宜
由于数据仓库中的大量数量和被访问到的可能性这两方面因素存在，一个满载的数据仓
库应该放在多种存储层次上。处理数据仓库技术应该能管理多种存储介质上的数据。
5.3 索引/监视数据
数据仓库的灵魂就在于灵活性和对数据的不可预测的访问。这一点也就是要求能够对数
据进行快速和方便的访问。数据仓库中的数据如果不能方便和有效地检索，那么建立数据仓
库这项工作就不是成功的。当然，设计者可以利用许多方法来使数据尽可能地灵活，例如利
用双重粒度级和数据分割。但这些技术一定要支持方便的索引，一些索引技术常常是有用的，
如二级索引、稀疏索引、动态索引、临时索引等等。而且，建立和应用索引的费用不能太高。
相同地，数据仓库中的数据也应能随意地被监视。监视数据的费用也不能太高，过程不
能太复杂，监视程序在需要时应能随时运行。
有很多理由要监视数据仓库中的数据，包括：
■ 决定是否应数据重组。
■ 决定索引是否建立得不恰当。
■ 决定是否有太多数据溢出。
■ 决定数据的统计成份。
■ 决定剩余的可用空间。
如果数据仓库技术不支持对数据的方便和高效地监视的话，那么它就不适用。
5.4 多种技术的接口
数据仓库另一个非常重要的问题是要能够用各种不同的技术获得和传送数据。如果在向
98 数据仓库
下载
数据仓库传送数据和从数据仓库传递数据时有很大限制，那么这种支持数据仓库的技术实际
上是没有用的。
接口不仅要高效还要便于使用，并能够在批模式下运行。在联机模式下运行是有趣的，
但并不非常有用。
5.5 程序员/设计者对数据存放位置的控制
为了对数据进行高效地访问和更新，程序员 /设计者需要在物理的块 /页的一级上对数据的

存放进行特殊的控制，如图 5-2所示。
某项技术将数据放到它认为合适的地方是完全可以的，只要该项技术能在需要时被明确
地管制。如果某项技术非要将数据存放在某一物理地址而不允许程序员管制，那么它就犯了
严重的错误。
程序员/设计者时常对数据的物理位置进行整理来使之适合其用途。这样做可以使数据的
访问更加经济。
设计者
第5个技术需求 — 允
许设计者 /开发者在块
/页的级别上以一种最
佳的形式决定数据的
物理存放位置
第6个技术需求 — 能
够并行管理数据
元数据
第7个技术需求 — 有
很好的元数据管理
第8个技术需求 — 数
据仓库要有多种语言语言
接口
图5-2 数据仓库的另外一些技术需求
下载
5.6 数据的并行存储/管理
数据仓库中数据管理的最重要的特征之一是数据的并行存储 /管理。当数据被并行存储和
管理时，性能上会提高很多。通常，假定对数据的访问都是等概率的话，性能的提高与数据
所分布的物理设备的多少成反比。
整个数据的并行存储 /管理是非常复杂和重要的，在这里的论述是不够的，但应先在此提
及一下。
5.7 元数据管理
由于各种各样的原因，数据仓库中元数据比在传统操作型的数据库中更重要。元数据之
所以重要是由于与数据仓库相关的开发生命周期是完全不同的，数据仓库是在一种启发式的、
反复的开发生命周期上运作的。为了更加有效，数据仓库的用户应该能够对准确和实时的元
数据进行访问。没有一个好的元数据来源来运作的话， D S S分析员的工作就非常困难。典型
的元数据包括：
■ 数据仓库表的结构。
■ 数据仓库表的属性。
■ 数据仓库的源数据（记录系统)。
■ 从记录系统到数据仓库的映射。
■ 数据模型的规格说明。
■ 抽取日志。
■ 访问数据的公用例行程序。
5.8 语言接口
数据仓库需要有非常丰富的语言规定。没有一种健壮的语言，数据仓库中进入接口和访
问数据就非常困难。而且，访问数据仓库的语言一定要是高效的。
典型的数据仓库语言接口需要：
■ 能够一次访问一组数据。
■ 能够一次访问一条记录。
■ 特别要保证，为了满足某个访问要求能够支持一个或多个索引。
■ 有SQL接口。
■ 能够插入、删除、更新数据。
5.9 数据的高效装入
数据仓库的一个重要的技术能力就是要能够高效地装入数据，如图 5-3所示。
有好多种装入数据的方法：通过一个语言接口一次一条记录或者一起使用一个程序一次
全都装入。另外，在装入数据的同时，索引也要高效地装入。在有些时候，为了平衡工作负
载，数据索引的装入可以推迟。
如果数据仓库中数据的装入有不可克服的困难，那么这个数据仓库就没有用处了。
100 数据仓库
下载
能够高效地装载数
据仓库
有效地使用索引
能够以压缩的方式存
放数据
支持复合键码
图5-3 进一步的技术需求
5.10 高效索引的利用
数据仓库技术不仅必须能够方便地支持新索引的创建和装入，而且要能够高效地访问这
些索引。
有多种方法能够高效地访问索引：
■ 用位映像的方法。
■ 用多级索引。
■ 将部分或全部索引装入内存。
■ 当被索引的数据的次序允许压缩时对索引项进行压缩。
■ 创建选择索引或范围索引。
下载
除了索引的高效存储和浏览外，在主存储器层次对数据后续的存取也是很重要的。然而
不幸的是对主存数据访问的优化并不像对索引数据的访问一样有那么多选择。
5.11 数据压缩
数据仓库的成功之处就在于能够管理大量的数据。达到这一目的的中心是数据的压缩。
当数据能够被压缩时，它便能存储在很小的空间中。这尤其与数据仓库的环境有关，因为数
据在插入到数据仓库中后，是很少被更新的。数据仓库中数据的稳定性减少了空间管理问题，
这些问题是在更新紧密压缩的数据时发生的。
压缩的另一个好处是程序员可以完全脱离给定的输入 /输出操作。当然，对数据的访问就
会有相应的解压缩的问题。虽然解压缩需要一定的开销，但这个开销不是 I / O资源的开销，而
是C P U的开销。通常，在数据仓库环境中 I / O资源比C P U资源少得多，因此数据的解压缩并不
是一个主要的问题。
5.12 复合键码
数据仓库环境中一种简单而又重要的技术需求是能够支持复合键码。这种键码在数据仓
库环境中随处可见，主要是因为数据仓库中数据的随时间变化特性。
5.13 变长数据
数据仓库环境的另一个简单而又重要的技术需求是有效管理变长数据的能力，如图5-4所示。
第13个技术需求 — 能够有效地管理
变长数据
锁管理程序
第14个技术需求 — 能够按照需要开
启和关闭锁管理程序，能够在程序员
级显式控制锁管理程序
第15个技术需求 — 能够进行单独索
引处理
第16个技术需求 — 能够从一批介质
上将数据快速、完全地恢复
图5-4 数据仓库还需要的另外一些技术
102 数据仓库
下载
变长数据如果被经常更新和改变，就会产生性能上的严重问题。但当变长数据很稳定，
如在数据仓库中时，就没有固有的性能问题。
另一方面，由于数据仓库中数据的多样性，对数据的变长结构的支持是强制性的。
5.14 加锁管理
数据库技术的一个基本部分是加锁管理。加锁管理程序确保没有两个或两个以上的用户
在同一时间对同一数据进行更新。但数据仓库中是没有更新的。
应用加锁管理程序的后果之一是它消耗了相当的资源，即使数据不被更新也是一样。简
单地一直把加锁管理程序打开是会消耗很多资源的。为了使数据仓库环境更加合理，需要有
选择地将加锁管理程序打开或关闭。
5.15 单独索引处理
数据库管理系统的一个基本特征是能够进行单独索引处理。在许多情况下，只查看一个
索引(或一些索引 )就可以提供某些服务。当只通过查看一下索引就可以满足某些请求时，由于
用不着查看数据的最初数据源而会更加有效。但并不是所有的 D B M S都有辨别索引是否能满
足请求的智能。
5.16 快速恢复
数据仓库环境的一个简单而重要的技术特性，是能够从非直接存取存储设备快速地恢复
数据仓库表。当可以从二级存储设备上恢复时，就可能节约大量开支。如果没有能从二级存
储设备上快速恢复的能力，通常的做法是将 DASD的数目增加一倍，然后将增加出的数目作为
恢复/复原的存储区。
5.17 其他的技术特征
这里所讨论的特征只是最重要的一些。有好多其他的特征需要我们考虑，但由于数量太
多而不便详述。
值得注意的是传统技术中的很多其他特征只起很小的作用（如果它们还起作用的话)。这
样的一些特征包括：
■ 事务集成性。
■ 高速缓存。
■ 行/页级的锁定。
■ 参照完整性。
■ 数据视图。
5.18 DBMS类型和数据仓库
随着数据仓库的到来，以及人们认识到 D S S是现代信息系统基本结构的必不可缺少的一
部分，一类新的 D B M S产生了。这种新的数据库管理系统可以称为“数据仓库专用数据库管
理系统”。数据仓库专用数据库管理系统是特别为数据仓库和决策支持而优化设计的。
下载
数据仓库环境中的处理类型可以概括为装入和访问过程。数据从操作型数据环境中集成、
转换和装入到数据仓库中去。数据到了数据仓库后，在那里被访问和分析。在数据仓库中，
数据一旦被装入，通常是不被更新的。如果需要对数据仓库进行数据的更正和调整的话，也
是在对数据仓库数据没有分析操作的空闲时间进行。
传统数据库环境和数据仓库环境的另一个重要的区别在于，数据仓库中有更多的数据量，
比一般的操作型环境中要多得多。数据仓库中的数据量以 1 0 G B或1 0 0 G B计，而一个通用的
DBMS通常管理的数据要比它少得多。数据仓库要管理大量的数据，是因为它们：
■ 包括粒状的、原子的细节。
■ 包括历史信息。
■ 包括细节和汇总数据。
谈到基本的数据管理功能，数据仓库用与标准的操作型 D B M S非常不同的一组参数来进
行优化。
传统的通用数据库管理系统和数据仓库专用数据库管理系统的第一个也是最重要的区别
在于数据的更新。前者必须适合于记录级的更新，并将其作为操作的一个标准部分。由于记
录级的数据更新是一通用 DBMS的常规特征，所以它必须提供以下功能：
■ 锁定
■ 提交
■ 检测点
■ 日志处理
■ 死锁处理
■ 回退
不仅这些是 D B M S的常规特征，它们还要花费巨大的开销。有趣的是，当 DBMS 不被使
用时也要耗费这笔开销。换句话说，至少对某些 DBMS当仅执行只读操作时， DBMS也要提供
更新和锁定的开销。依赖于通用 D B M S，更新所需的开销能够被最小化，但不能完全没有。
而对于一个数据仓库专用的 DBMS来说，不会付出任何更新的开销。
通用DBMS和数据仓库专用 DBMS之间的第二个主要区别是基本的数据管理。对于通用的
D B M S来说，对数据在块级上的管理要包括一些附加的空间，这些空间用于以后更新和插入
数据时块的扩张。典型情况下，这些空间是些自由空间。对于通用 D B M S，自由空间可能要
占到50%。对于数据仓库专用的 DBMS，根本就不需要自由空间，因为数据一旦装入到数据仓
库后是不需要更新的，也就没有扩展物理块的需要。事实上，给定了数据仓库中要管理的数
据量后，留下以后不会用到的大量空间是没有意义的。
数据仓库和通用环境之间的另一个有关的区别反映在不同类型的 D B M S上，是索引的区
别。通用 D B M S环境限制在有限数量的索引，有这个限制是因为当有数据的更新和插入时，
索引本身需要数据管理。然而，在数据仓库环境中，没有数据的更新，却有必要对数据的访
问进行优化，也有多种索引的必要 (和机会)。事实上，数据仓库相对于操作型的、面向更新的
数据库来说，能够应用更健壮和更完善的索引结构。
除了索引、更新和物理块级上的基本数据管理以外，在数据管理能力和策略上，通用
DBMS和数据仓库专用 DBMS之间还存在其他一些基本区别。其中，这两种类型的 DBMS的最
基本的区别可能是在物理上以优化方式组织数据以适应不同类型访问的能力。通用 D B M S在
104 数据仓库
下载
物理上组织数据是为了优化事务的访问和处理。这种模式下的组织允许许多不同类型的数据
通过一个公共键码在物理上聚集起来，并能有效地通过 1次或2次I / O访问。信息访问的最优化
的数据通常有很不同的物理描述。在物理上组织它们而使对同一类型数据的多次不同访问能
够通过1次或2次I/O高效地进行。
数据能够在物理上进行优化以便于事务访问和 DSS访问。通用的 DBMS优化数据是为了事
务的访问，而数据仓库专用的 DBMS物理上优化数据是为了便于决策支持系统的访问和分析。
5.19 改变DBMS技术
对于信息仓库的一个有趣的考虑是，在数据仓库数量增长后， D B M S技术的变化。有几
个理由来说明为什么进行这样的改变：
■ 当今可用的 DBMS技术，当数据仓库首次载入数据时并不一定适合。
■ 数据仓库已经变得非常之大，以至于应该提出新的技术方法。
■ 数据仓库的利用已经提高许多，也改变了许多，使得现在的数据仓库的 D B M S技术已
经不适用了。
总之，我们有可能要一次又一次地重新审视基本的 DBMS技术。
是否应考虑找一种新的 DBMS技术？我们要考虑的是什么？以下的几点非常重要：
■ 新的DBMS技术是否满足可预知的需求？
■ 从旧的DBMS向新的DBMS的转换应该怎样去做？
■ 转换的程序应该怎样改变？
所有的这些考虑中，最后一个是最令人头痛的。即使在最好的环境中，试图去改变转换
程序也是一项很复杂的工作。
5.20 多维DBMS和数据仓库
一项在数据仓库中经常讨论的技术是多维数据库管理系统。多维数据库管理系统（有时
也叫“数据集市”)提供了一种信息系统结构使得对数据的访问非常灵活，可以用多种方法对
数据进行切片、分割，动态地考察汇总数据和细节数据的关系。多维 D B M S不仅提供了灵活
性，还可以对终端用户进行管理，这些非常适合 D S S环境。如图 5 - 5所示，多维 D B M S和数据
仓库之间有非常有趣和互补的关系。
金融市场会计
轻度综合的数据集市
多维DBMS(OLAP)
当前细节
图5-5 数据仓库的传统结构以及当前细节数据如何同部门数据(或多维DBMS，数据集市)配合
下载
数据仓库中的细节数据为多维 DBMS提供了非常健全和方便的数据源，多维 DBMS需要定
期地刷新。为此，数据要定期从数据仓库中导入到多维 D B M S中去。由于传统应用程序的数
据在进入数据仓库时被集成，多维 D B M S就用不着从操作型环境中抽取与集成数据，并因些
而受到推崇。另外，数据仓库在最低级别保存数据为那些利用多维 D B M S的用户进行低级别
的分析提供了基础。
可能有人会认为多维 D B M S应该作为数据仓库的数据库技术。除了一些非常特殊的情况
外，这种想法是不正确的。使得多维 D B M S技术最佳的那些性质并不是数据仓库的基本的重
要特性。数据仓库中最重要的特性也不是多维 DBMS技术的特性。
看一下数据仓库和多维 DBMS的区别：
■ 数据仓库有大量的数据；多维 DBMS中的数据至少要少一个数量级。
■ 数据仓库只适于少量的灵活访问；而多维 D B M S适合大量的非预知的数据的访问和分
析。
■ 数据仓库内存储了很长时间范围内的数据 — 从5年到10年；而多维DBMS 中存储着较
短时间范围内的数据。
■ 数据仓库允许分析人员以受限的形式访问数据，而多维 DBMS 允许自由的访问。
多维DBMS和数据仓库有着互补的关系，而不是数据仓库建立在多维 DBMS之上的关系。
数据仓库和多维 D B M S关系中有趣的一点是，数据仓库为非常细节的数据提供了基础，
而这在多维 D B M S中通常是不能看到的。数据仓库能容纳非常详细的数据，这些数据在导入
多维DBMS时被轻度综合了。而导入到多维 DBMS之后，数据会被进一步地汇总。在这种模式
下，多维DBMS可以包含除了非常细节以外的所有数据。使用多维 DBMS的分析者可以一种灵
活和高效的方式来对多维 D B M S中所有不同层次的数据进行钻取。如果需要的话，分析者还
可以向下钻取到数据仓库。通过这种方式将数据仓库和多维 DBMS相结合，DSS分析者可以得
到这两者的好处。 DSS分析者大部分时间里可以在多维 DBMS中享受其操作高效的优点，同时
如果需要的话，还可以向下钻取最低层次的细节数据。
数据仓库和多维 DBMS的另一个互补的方面是汇总的信息在多维 DBMS中计算和收集后被
存储在数据仓库中。通过以这种方式将数据进行融合，汇总数据在数据仓库中比在多维
DBMS中能够存储更长的时间。
数据仓库和多维 DBMS还有一个方面是互补的。多维 DBMS存放中等时间长度的数据，依
应用的不同从 1 2个月到 1 5个月。而数据仓库存放数据的时间跨度要大得多 — 从5年到1 0年。
考虑到这一点，数据仓库就成为多维 DBMS分析者进行研究的源泉。多维 DBMS分析者乐于知
道，如果需要的话，有大量的数据是可用的，但在不需要时却用不着在他们的环境中花费存
储所有这些数据的代价。
多维D B M S有不同的特色。一些多维 D B M S建立在关系模型上，而另一些多维 D B M S建立
在能优化“切片和分块”数据的基础上，在这里数据可以被认为存储在多维立方体内。后者
的技术基础可以称为“立方体基础”。
两种技术基础都支持多维 DBMS数据集市，但这两种技术基础之间存在着一些差异：
多维DBMS数据集市的关系型基础
■ 优点：
• 能支持大量数据。
106 数据仓库
下载
• 能支持数据的动态连接。
• 己被证实是有效的技术。
• 能够支持通用的数据更新处理。
• 如果对数据的使用模型不清楚的话，关系型结构与其他任何结构一样好。
■ 弱点：
• 性能上不是最佳的。
• 不能够单纯对访问处理进行优化。
多维DBMS数据集市的“立方体”基础
■ 优点：
• 对于DSS处理性能上是优化的。
• 能够对数据的非常快访问进行优化。
• 如果已知数据访问的模式，则数据的结构可以优化。
• 能够很轻松地进行“切片和分块”。
• 可以用多种方法检测。
■ 弱点：
• 几乎不能处理像标准的关系模型那么多的数据。
• 不支持通用的更新处理。
• 装入的时间很长。
• 如果对路径的访问不被数据设计所支持的话，这种结构就显得不灵活。
• 对数据的动态连接的支持是有问题的。
多维D B M S ( O L A P )是一种技术，而数据仓库是一种体系结构的基础。这两者之间存在着
互补的和共生的关系。最一般的情况下，数据仓库作为多维 DBMS的基础 — 从中选出细节数
据的一个子集传到多维 D B M S中，在那里，数据要么被汇总，要么被聚积。但在某些团体中
有一种观点认为多维 DBMS并不需要一个数据仓库作为它的数据的基础。
如果没有数据仓库作为多维 DBMS的基础，那么装入多维DBMS中的数据就是直接从老的、
传统的应用环境中得到。图 5 - 6展示了数据直接从传统环境装入多维 D B M S中去的情形。由于
它是直截了当的，并很容易实现，所以这种方法很吸引人。一个程序员能够立刻开始工作来
建造它。总之，这一设计的简单、快捷对于终端用户来说是一种诱惑，使他们认为构造多维
DBMS的这种方法是合适的。
然而不幸的是，图 5 - 6所示的结构中有一些并不显而易见的缺陷。由于各种各样的原因，
使得用数据仓库的当前详细级的数据装入多维 D B M S比直接从传统的操作型应用环境中装入
数据更有意义。
金融
多维DBMS数据集市
传统的应用
图5-6 从还没有当前细节数据的应用建立多维DBMS数据集市
图5 - 7展示了用数据仓库的当前详细级的数据装入多维 D B M S环境的方法。老的传统的
下载
操作型数据被集成、转换，再传入到数据仓库中。一旦到了数据仓库，被集成的数据就存
储在细节数据的当前级中。多维 D B M S 就是从数据仓库中这一级别的数据之中得到其数
据。
第一眼看上去，图 5-6和图5-7所示的两种结构似乎并没有本质上的区别。事实上，将数据
首先装入到数据仓库中似乎是浪费精力。但是，有一个非常好的理由说明为什么在创建多维
DBMS的第一步要先将数据集成到数据仓库中。
金融
多维DBMS
数据集市
当前细节
传统的应用
图5-7 数据从应用环境传入当前细节级然后再传入多维DBMS数据集市
考虑一下这样一个事实，在通常情况下，一个公司需要建立多个多维 D B M S。金融需要
它们自己的多维 D B M S，财务部门也需要它们自己的。市场部、销售部和其他一些部门都需
要他们自己的多维 D B M S。因为在这个公司里将会有众多的多维 D B M S，所以图 5 - 6所示的方
案就会变得非常复杂。这样图 5-6 就扩展为一个现实的方案 — 有众多的多维 D B M S都要直接
地和独立地从传统系统环境中获得数据，如图 5-8所示。
图5 - 8展示了众多的多维 D B M S直接从相同的传统应用中获得数据的情况，这种结构有什
么不对呢？
问题如下：
■ 抽取数据所需进行的开发量是巨大的。每一个不同部门的多维 D B M S都需要开发一套
适合它的抽取程序。抽取处理过程有大量的重叠。浪费的开发工作量很大。当多维
DBMS是从数据仓库中抽取数据时，它只要一套集成和转换的程序就够了。
■ 当多维 D B M S是从传统系统环境中直接提取数据时，是没有集成的基础的。每一个部
门的多维 D B M S对于怎样从不同的应用中集成数据都有它们自己的解释。不幸的是，
一个部门集成数据的方法通常和其他部门集成相同数据的方法是不同的。结果导致最
终没有单一集成的确定的数据源。在数据仓库建造时，本来有一个能够作为基础的单
一的、集成的、确定的数据源。
■ 为了维护所进行的开发工作量是巨大的。旧的传统应用的一种单一改变就会影响许多
抽取程序。在有抽取程序的地方都要做一些改动，而且这种改动会很多。当有了数据
仓库后，由于只需要写很少的程序来处理传统环境和数据仓库的接口，所以应用中的
改变产生的影响也是很少的。
108 数据仓库
下载
直接从应用到多维DBMS方法不能行之有效的一个主要原因
应用a 金融
市场
应用b
人力资源
应用c
管理报告
应用d
销售
生产
应用e
工程
应用f
会计
应用g
制造
应用h
保险
应用i 预算
图5-8 有许多的应用和许多的数据集市，每对之间都需要一个接口。
回避细节数据的当前级的后果是产生无法管理的“蜘蛛网”
■ 需要消耗的硬件资源的数量。对于每一个部门的每一个抽取处理，同样的传统的数据
都要顺序地重复地传送。而在数据仓库中，为了刷新数据仓库中的数据，传统数据只
需要传送一次。
■ 从传统环境中将数据直接导入多维 D B M S环境中的复杂度使得对元数据的高效管理和
控制受到损失。而在数据仓库可以对元数据进行直接的捕捉和管理。
■ 缺乏数据的一致性。当不同的部门存在意见上的分歧时，由于它们各自都有自己的多
维DBMS，这就很难解决。但用数据仓库后，冲突的解决是很自然和简单的。
下载
5.21 双重粒度级
数据仓库的一个有趣的方面是通常会创建双重环境。一个环境是能够进行联机的、交互
式处理的DASD环境，另一个环境通常是磁带处理或其他具有不同特征的大容量存储环境。在
许多情况下，支持 DASD环境的底层技术和支持大容量存储环境的底层技术是不同的。当在数
据仓库中有双重环境时，采用混合技术是正常和自然的。
但是，还有另一种方式把技术区分开，这种方式不是正常的或自然的。可以想象，数据
仓库环境 — D A S D部分 — 可以用多种技术将之分开，但除非这种区分是分布式数据仓库的
一部分，否则，是不提倡这种方法的。
5.22 数据仓库环境中的元数据
在数据仓库环境中的元数据所扮演的角色和在操作型环境中数据所扮演的角色是不同的。
在操作型环境中，元数据几乎被当成文档来处理并且降低到同样的重要性级别。然而，在数
据仓库环境中，元数据的重要性提高了。数据仓库环境中元数据的重要性如图 5 - 9所示。操作
型数据和数据仓库中的数据服务于两类不同的群体，操作型数据由 I T专业人员使用，许多年
来I T人员都是偶然地使用元数据。 I T专业人员不仅懂计算机，而且由于学历背景和所受的培
训，他们会在系统中找到他们自己的方法。然而，数据仓库数据是给 DSS分析者用的。DSS分
析人员通常首先是专业人员，他们通常没有很高的计算机水平。为了能够有效地使用数据仓
库环境，DSS分析人员需要尽量多的帮助，而元数据恰能很好地帮助他们。另外，在 DSS分析
者计划该怎样去做信息型 /分析型处理时，他们要首先去看元数据。由于所服务的人员的种类
不同，以及元数据在每天的工作中所起的作用不同，元数据在数据仓库环境中比在操作型环
境中重要得多。然而还有其他的一些原因使得数据仓库的元数据很重要。
元数据元数据
任选的强制的
IT DSS
专业人员分析人员
图5-9 IT专业人员偶尔使用元数据，DSS分析人员经常使用元数据并作为分析的第一步
110 数据仓库
下载
数据仓库的元数据所以重要的另一个原因，涉及到从操作型环境到数据仓库环境的映射，
图5-10展示了这一观点。
映射
元数据
图5-10 操作型环境和数据仓库环境之间的映射是需要元数据的另一个主要原因；
没有这种映射，对接口进行控制是非常困难的
元数据元数据
结构
内容
结构
内容
90 91 92 93 94 95 96 00
图5-11 数据仓库中包含很长一段时间的数据，因此必须管理多种数据结构/定义。
操作型环境假设在任一时刻只有唯一的一个正确的数据定义
当数据从操作型环境传入数据仓库环境时，数据要经历一个重大的转变。转化、过滤、
汇总、结构改变等等都会发生。有必要去跟踪一下这些转变，而数据仓库中的元数据正是能
做到这一点的理想所在。当一个管理者需要将数据从数据仓库追溯到操作型环境中时 (最终的
向下钻取 )，对这种转变保持一个细致的记录的重要性就显而易见了。在这种情况下，对数据
转变的记录恰恰是描绘了怎样从数据仓库钻取到操作型环境的源数据。
对于数据仓库环境中的元数据需要细致管理有另外一个重要原因，如图 5 - 11所示。数据
下载
仓库中数据会存在一段很长的时间 — 从5年到1 0年。而在 5年到1 0年这么长的时间段内，数
据仓库改变它的结构是很正常的。换句话说，一个数据结构能在 5到1 0年内保持不变是很不平
常的。那么，随着时间的流逝来跟踪数据结构的变化，则是数据仓库中元数据很自然的一项
任务。
将数据仓库环境中随时间变化的多种数据结构的概念与操作型环境中的元数据比较一下。
在操作型环境中，我们假定在任何时候，对数据结构有且仅有一个正确的定义。
5.23 上下文和内容
数据仓库引起人们兴趣的一个方面就是可以对数据在很长一段时间内进行存储和管理，
数据仓库要求对数据进行 5年到10年或更长时间的管理。
在过去，经典的操作型信息系统集中注意于公司的当前数据。在操作型世界中，强调的
重点是此刻帐目的余额是多少，或此刻的存货有多少，或此刻货物的运送情况如何。当然任
何一个组织都有必要知道当前的信息。但对过去一段时间的信息进行考察也有真正的价值。
当一个组织能够考察很长一段时间的信息时，发展趋势就很明显了。这是仅查看当前信息所
观察不到的。数据仓库定义中的一个重要特征就是能够对一段时间内的数据进行存储和访问。
考察作为数据仓库一部分的时间谱，使我们认识到了数据新的一个维 — 上下文维。为了
阐明上下文信息的重要性，下面给出了一个例子。
假定一个管理者想从数据仓库中要一份 1 9 9 5年的报表。报表生成后，管理者很满意。事
实上，由于管理者很满意，所以他便想要一份 1 9 9 0年的报表。由于数据仓库载有历史信息，
这样的一个要求并不难实现， 1 9 9 0年的报表生成了。现在管理者将这两份报表 — 1 9 9 0年的
一份和1995年的一份 — 拿在手中，并且宣布这些报表是一场灾难。
数据仓库工程师检查了报表，发现 1 9 9 5年的财政报告显示收入为 $ 5 0 , 0 0 0 , 0 0 0，而1 9 9 0年
的报告对同一种类显示为 $ 1 0 , 0 0 0。管理者宣称从来没有任何方法使任何种类的帐目在 5年内
增长这么多。
在就要放弃之前，数据仓库工程师向管理者指出报表中还有一些相关的因素没有显示出
来。数据仓库中 1 9 9 0年和1 9 9 5年的数据是从不同来源得到的； 1 9 9 0年的产品定义不同于 1 9 9 5
年的； 1 9 9 0年和1 9 9 5年有不同的市场领域； 1 9 9 0年和1 9 9 5年也有如对贬值的不同的计算。另
外，还有许多不同的外部因素需要考虑，如在通货膨胀、税款、经济预测方面的差别等等。
一旦报表的上下文向管理者解释了之后，内容就显得非常可接受和可解释了。
在这个简单而又常见的例子中，一段时间内数据的内容如果毫无附加信息地显示，那么
内容本身也就是非常难于理解、难以置信的。然而，当上下文加到一段时间内数据的内容上
去时，内容和上下文都变得非常令人明白。
为了理解和解释一段时期内的信息，需要一个全新的上下文维。当信息的内容仍十分重
要时，一段时期内信息的比较和理解使得上下文和内容同等重要。而在过去的几年中，上下
文是一直未被发现、未被开发的信息的一个维。
5.24 上下文信息的三种类型
我们需要管理三个级别的上下文信息：
■ 简单上下文信息。
112 数据仓库
下载
■ 复杂上下文信息。
■ 外部上下文信息。
简单上下文信息与数据本身的基本结构有关，包括如下一些内容：
■ 数据的结构。
■ 数据的编码。
■ 数据的命名约定。
■ 描述数据的度量，如：
• 数据的多少。
• 数据增长速度。
• 数据的哪一部分增长。
• 数据是怎样被使用的。
简单上下文信息在以往是用字典、目录、系统监视器等管理的。复杂上下文信息描述的
是和简单上下文信息相同的数据，但是从一个不同的侧面描述。复杂上下文信息强调了数据
的下面几点：
■ 产品定义。
■ 市场领域。
■ 定价。
■ 包装。
■ 组织结构。
■ 分发。
复杂上下文信息是一些非常有用，同时又非常难以捉摸的信息。它令人难以捉摸是因为
它是想当然的，并存在于背景环境中。它非常之基本，以致于没有人会想到要定义它是什么，
或怎样随时间变化。然而，在一段长的时期内，复杂上下文信息在理解和解释跨时间段信息
方面有着非常重要的作用。
外部上下文信息是那些公司以外的而在理解随时间变化的信息方面起重要作用的信息。
外部上下文信息的实例包括：
■ 经济预测：
• 通货膨胀。
• 金融。
• 税务。
• 经济增长。
■ 政治信息。
■ 竞争信息。
■ 技术进展。
■ 用户人数的统计变动。
外部上下文信息并没有直接指出关于一个公司的任何事情，但指出了公司运转和竞争中
所面对的任何事情。考虑到外部上下文信息的及时显示和它随时间的变化，外部上下文信息
是很令人感兴趣的。同复杂上下文信息一样，很少会有组织尝试去采集和量度这些信息。外
部上下文信息非常之多，也非常之显然，以致于人们总会想当然。它会很快被遗忘，而在需
下载
要时又很难重建。
5.25 捕获和管理上下文信息
复杂上下文信息和外部上下文信息之所以如此难捕获和确定的一个原因就是它们是非结
构化的。与简单上下文信息相比较，外部和复杂上下文信息非常杂乱无章。另外的一个因素
是上下文信息变化很快。这一刻我们感兴趣的和相关的信息，在下一时刻就可能会变得无关
和陈旧。正是外部和复杂上下文信息的这些不断变化和无组织的特点使得这种类型的信息很
难系统化。
下面看一看以前的情况。一个人可以认为信息系统行业在过去已经有了上下文信息。过
去是通过字典、仓库、目录和图书馆来试图捕获这些信息的，所有这些尝试都是针对简单上
下文信息管理的。尽管有这些好想法，但这里存在的一些明显的局限大大降低了其有效性。
以往管理简单上下文信息的方法存在以下的缺点：
■ 信息的管理是针对信息系统的开发者，而不是最终用户。这样，对于最终用户就会有
很少的可视性。因此，最终用户对并不明显的事情几乎没有热情，也不支持。
■ 对上下文信息管理的意图是被动的。开发者可以选择用或不用这些上下文信息管理工
具，很多人倾向于回避这些工具。
■ 对上下文信息管理的意图在很多情况下会从开发计划中删除掉。一个接一个的事例，
如应用是在 1 9 6 5年开发的，数据字典是 1 9 8 5年做的，而到了 1 9 8 5年就再没有更多的开
发经费了。甚至，那些非常有助于组织和定义简单上下文信息的人早已改行或到了其
他公司。
■ 对上下文信息的管理意图仅局限于简单上下文信息，没有尝试去捕获和管理外部和复
杂上下文信息。
5.26 刷新数据仓库
一旦数据仓库建好以后，注意力就从数据仓库的构造转向每天的操作上。人们发现操作
和维护数据仓库的费用很高。数据仓库中，数据量的增长速度比任何人预计的都要快，数据
仓库的最终用户 — DSS分析人员对数据仓库的大量的、不可预测的应用在管理数据仓库的服
务器端引起了竞争，而与数据仓库有关的最大最不可预知的开销是数据从传统数据环境到数
据仓库的定期刷新。起先是非常偶然的开销很快就变为一项巨大的开销。
大多数的组织在考虑刷新数据仓库时的第一步一般是直接读取老的传统的数据库。在某
些环境下进行某些处理时，刷新只能通过直接读取旧的传统文件。当数据必须从多个不同的
传统数据源收集，组成一个整体放入数据仓库中时，直接读取传统数据可能是进行数据仓库
刷新的唯一选择。或者当一个事务处理同时使多个传统文件更新时，直接读取传统数据也是
刷新唯一的方法。但是，作为一个通用的策略，商场发现重复地直接读取传统数据开销非常
大。直接读取传统数据库的开销体现在两个方面。第一个开销是当直接读取传统数据时，传
统的D B M S在读取过程中必须是联机的和活动的。对于传统数据库的长时间连续处理的机会
是很有限的。为了刷新数据仓库而分配很多的时间是不可取的。第二个方面就是相同的传统
数据并无必要地被传送了好几次。当只要 1 %或2 %的传统数据需要扫描时，刷新活动却得
100%地扫描整个文件。这种对资源的浪费在每一次刷新时都会发生。由于这些低效性的存在，
114 数据仓库
下载
直接地重复读取传统数据来进行刷新是应用非常有限的一种策略。
刷新数据仓库的一个更吸引人的方法是在传统环境中捕捉正在被修改的数据。当传统环
境中数据发生变化时，通过捕捉它，就不需要当刷新数据仓库时对传统环境中的表全部扫描。
另外，因为数据是在改变时被捕捉的，所以也就不需要传统 D B M S联机来进行长时间的顺序
扫描。相反，可以在脱机时处理捕捉到的数据。
在传统操作型环境中，当数据改变时有两种基本的技术来捕获这种数据。一种称为“数
据复制”。另一种称为“变化数据捕获”，指将发生了的变化从在联机更新时生成的日志或日
志磁带中提取出来。
数据复制要求将要捕获的数据在修改之前标识出来。那么，改变发生时数据就被捕获。
设置一个“触发器”来捕获数据的更新活动。数据复制的一个好处是可以有选择地控制捕获
处理。事实上只有需要捕获的数据被捕获到。数据复制的另外一个好处是数据的形式“简洁”，
定义完善。所被捕获的数据的内容和结构会很好地归档，易于程序员理解。数据复制的缺点
是由于要捕获数据，所以产生了许多额外的 I / O操作。同时由于数据仓库不稳定的、总在变化
的特性，系统也要不断地注意参数和触发器的定义，使得在数据更新时捕获之。 I / O需求的数
量通常不是很小的。另外， I / O操作是在系统高性能运行时进行的，这个时间系统是很难提供
I/O的。
第二种对数据仓库环境的高效的刷新方法是通过所谓 “变化数据捕获”（C D C)。C D C使
用了日志磁带来捕获和确定联机处理时的变化。 C D C需要读取日志或日志磁带。读取一个日
志磁带并不是一件小事，这其中有很多阻碍，诸如：
■ 日志磁带包含了许多无关数据。
■ 日志磁带格式难理解。
■ 日志磁带包括跨区记录。
■ 日志磁带通常包含的是数据的地址而并非它的值。
■ 日志磁带反映了 DBMS的特征，并随DBMS的不同而有很大的不同。
C D C的主要障碍就是读取和理解日志磁带。但是，一旦解决了这个问题后，我们就会发
现用日志来处理数据仓库刷新的一些吸引人的好处。第一个优点就是高效率。日志磁带处理
不像复制处理一样需要附加的 I / O操作。日志磁带不管它是否用于数据仓库的刷新，它都是要
写的。因此，日志磁带的 C D C处理不需要增加 I / O操作。C D C的第二个好处是，日志磁带会捕
获所有的数据更新操作。当对数据仓库或对传统系统环境做一些改变时，用不着再回头重新
定义参数。而且日志磁带是你所能得到的最稳定和基本的设备。
这里所描述的刷新技术的发展进程是模仿企业在他们对数据仓库的理解和操作过程中所
产生的想法。首先，是从传统数据库中直接读取数据来刷新数据仓库，然后他们尝试数据复
制。最后，操作的经济和效率使他们把 C D C当作数据仓库刷新的主要方法。在这个过程中，
他们发现一些文件是需要直接读取的。另外还有一些文件适合于用复制的方法。但对于通用
目的的数据仓库刷新来说， CDC是一种长期的最终的数据仓库刷新方法。
5.27 小结
为了满足数据仓库处理的需要，应该具有一些技术特征。这些技术特征包括健壮的语言
接口、支持复合键码和变长数据，以及如下的一些能力：
下载
■ 管理大量数据。
■ 管理各种各样介质上的数据。
■ 方便的索引和监视数据。
■ 大量接口技术。
■ 允许程序员将数据直接存放在物理存储设备上。
■ 数据的并行存储和访问。
■ 有数据仓库的元数据控制。
■ 高效地装入数据仓库。
■ 有效地使用索引。
■ 以压缩方式存储数据。
■ 有选择地关闭锁管理。
■ 单独索引处理。
■ 从大容量存储器迅速恢复。
下载
第6章分布式数据仓库
大部分企业建立和维护单一中央数据仓库环境。为什么单一中央数据仓库环境比较流
行？这有许多原因：
■ 数据仓库中的数据是全企业集成的数据，仅在总部使用集成视图。
■ 数据仓库中的大量数据使数据的单一的集中式存储具有意义。
■ 即使数据能被集成，但是若将它们分布于多个局部站点，则存取这些数据也是很麻烦
的。
总之，政策、经济和技术等诸多因素都更倾向于建立和维护单一中央数据仓库环境。但
是在某些特定场合，需要建立分布式数据仓库环境。
6.1 引言
为了便于理解分布式数据仓库何时有意义，我们先看一些处理的基本拓扑结构。图 6 - 1表
明了一种常见的处理拓扑结构：
站点A
站点C
总部
操作型处理
站点B
图6-1 许多企业处理的典型拓扑图
如图6 - 1所示，某企业设有一个总部，负责处理所有的业务。若在局部层上存在某些业务
处理，这些处理也是非常基本的。局部层上可能拥有一系列的哑终端，但是所作的处理工作
都是不太重要的。在这种拓扑结构中，不可能需要建立分布式数据仓库环境。
当局部层出现基本的捕获信息活动时，局部处理的复杂性将有所提高，如图 6-2所示。
在图6 - 2中，局部层有少量的捕获信息活动。一旦承揽了某业务，即将它传送到总部去处
理。在这种简单的拓扑结构中，也不需要建立分布式数据仓库环境。
现在，看一下如图 6 - 3所示的拓扑结构。同前两种处理拓扑结构相比 ,在图6 - 3中，局部层
有相对较多的处理过程。就拿操作型处理来说，局部站点是自主的。仅偶然或某些特定的处
理需要将数据和业务活动发送到总部处理。对于这类企业来说，采用某种形式的分布式数据
仓库就是必要的。
下载
第6章分布式数据仓库 117
站点A
捕获信息活动
站点C
捕获信息活动
总部
操作型处理
站点B
捕获信息活动
图6-2 某些场合，在站点层处理一些基本业务活动
站点A
局部操作型处理
站点C
总部
全局操作型处理
站点B
图6-3 在分布式数据仓库谱系的另一端— 在局部层要做许多操作型处理
正如即将讨论的，分布式数据仓库的种类很多。认为分布式数据仓库仅是一种两级模式
的思想是错误的。分布式数据仓库有许多层次(级别)。
局部自主性和处理过程较少的大多数企业一般拥有一个中央数据仓库，如图 6-4所示。
站点A
站点C
操作型处理
总部
站点B
数据仓库
图6-4 大部分企业具有一个中央控制与存储的中央数据仓库
118 数据仓库
下载
6.2 局部数据仓库
数据仓库的一种形式是局部数据仓库。局部数据仓库仅包含对局部层有意义的数据。图
6-5表明了一系列局部数据仓库的一个简单实例。
在图6 - 5中，位于不同地区的分部或不同的技术联营组织各拥有一个局部数据仓库。局部
欧洲
站点A
非洲
局部数据仓库站点C
美国
总部
局部数据仓库
亚洲站点B 操作型处理
局部数据仓库
局部数据仓库
全局数据仓库
所有DEC公司
站点A
所有Tandem公司
站点C
局部数据仓库美国
总部
所有IBM公司局部数据仓库
站点B 操作型处理
结合
局部数据仓库
IBM,DEC,Tandem
局部数据仓库
全局数据仓库
图6-5 需创建两级数据仓库的一些情形
下载
数据仓库除了存储的数据是局部的外，具有其他任何数据仓库的相同功能。换句话说，局部
数据仓库包含的是在局部站点上的历史的和集成的数据。局部仓库间的数据或数据结构不必
要协调一致。
6.3 全局数据仓库
当然，也可以是全局数据仓库，如图 6-6所示。全局数据仓库的范围涉及整个企业或组织。
它内部的每个局部数据仓库也都有各自服务的局部站点范围，全局数据仓库的范围是该企业。
同局部数据仓库一样全局数据仓库也包含历史数据。局部数据仓库的数据源如图 6 - 7所示，可
看出它们的数据来源于相应的操作型系统。
研究不同的局部数据仓库间的公用数据是一个很有意义的问题。图 6 - 8表明每个局部数据
仓库都有自己特定的数据和结构。
局部数据仓库间数据的重叠部分或公用部分是完全一致的，图 6 - 8所示的局部数据仓库之
间的无论什么数据或处理过程不用协调。
站点A
站点C
局部操
作型处理局部操
作型处理
局部数据仓库总部
局部数据仓库
局部操
作型处理
站点B
局部数据仓库
局部操
作型处理
全局数据仓库
局部数据仓库
图6-6 典型分布式数据仓库的可能形式
但是，假定某企业内一个站点和另一个站点间的数据存在自然重叠是合理的。如果存在
这样的交叉部分，那么最好将这些数据存放在全局数据仓库中。图 6 - 9表明全局数据仓库中数
据来自于现有的局部操作型系统的情形。
120 数据仓库
下载
站点A
站点C
局部操
作型处理
局部数据仓库
局部操
作型处理
站点B
局部数据仓库
局部操
作型处理
局部数据仓库
图6-7 从局部操作型环境到局部数据仓库的数据流
站点A
站点C
局部操
作型处理
局部数据仓库
局部操
作型处理
局部数据仓库
站点B
局部操
作型处理
局部数据仓库
图6-8 局部数据仓库间的数据及结构是非常不同的
下载
6.4 互斥数据
图6 - 9中隐含着未显示出来的假定，即假定局部数据仓库中的数据并不一定都出现在全局
数据仓库中，全局数据仓库中的数据也并不都来自于局部数据仓库。所以，全局数据仓库中
的数据不一定都从局部数据仓库中导入。
站点A
站点C
局部操
作型处理
总部
局部数据仓库
局部数据仓库
局部操
作型处理
局部数据仓库
站点B
局部操
作型处理
局部数据仓库全局数据仓库
图6-9 全局数据仓库中数据来自于无关的操作型系统
全局数据仓库中包含的是企业内部公共的和集成的数据。分布式数据仓库环境成功的关
键就是如何将局部操作型系统中的数据映射到全局数据仓库中的数据结构，如图 6-10所示。
图6 - 1 0表明全局数据仓库有一个公共的数据结构，包含企业内所有的公有数据。但是从
每个局部站点到全局数据仓库的数据映射不同。换句话说，全局数据仓库是集中定义和设计
的，而已存在的局部操作型系统的数据映射是由局部设计者和开发者选择的。
从局部操作型系统到全局数据仓库系统的数据映射，刚开始设计时很可能不完全准确，
但是随着时间的推移，用户反馈信息的积累，它们将会逐步完善。
数据仓库的一种变化形式是在局部层保存全局数据仓库的数据“登台”区域。图 6 - 11表
明这种情况，局部层在将数据传送到中心位置前先在每个局部区域登台这些数据。在许多场
合，这种方法可能在技术上是必需的。另外它可能会带来的一个重要问题是：当局部数据仓
库中保存的登台数据传送到全局数据仓库后应该腾空吗？如果局部层不删除这些信息，那么
将导致数据冗余。但是，在某些情况下，一定量的冗余数据也是需要的。对此问题必须作出
122 数据仓库
下载
映射到全局数据结构
站点A 站点C
局部操局部操
作型处理作型处理
站点B 总部
局部操局部操
全局数据仓库
图6-10 全局数据仓库有一个公共的数据结构，每个局部站点以不同的方式映射到公共结构
决定，且应提出处理策略与过程。
起初的全局数据仓库建造好后可能还存在着许多候选的主题域。许多企业以企业财务作
为主题域。财务之所以是一个好的起点，原因如下：
■ 它是相对稳定的。
■ 具有高的可视性。
■ 仅是企业业务的一部分(当然除了金融机构)。
■ 仅需处理少量数据。
下载
建造全局数据仓库时，必须处理一些特殊问题。就数据层来说，全局数据仓库并不符合
典型的数据仓库结构。其中一点是细节数据存在于局部层，而轻度综合的数据存在于中央全
局层。例如，假定一个公司的总部在纽约，在远离总部的德克萨斯、加利福尼亚和依利诺州
设有分部，这些分部单独管理销售和财务细节数据。总部将数据模型传送到各分部，各分部
将必要的企业数据转换为公司内部可集成的数据形式。数据在局部层进行转换后，传送到纽
约总部。原始的、未转换的细节数据仍然保存在局部层。仅将转换过的、轻度综合的数据传
送到总部。这是典型的数据仓库结构的一种变化形式。
站点A 站点C
局部操局部操
局部数据仓库
局部数据仓库
全局数据仓库全局数据仓库
(登台区域) (登台区域)
站点B 总部
局部操局部操
局部数据仓库
局部数据仓库
全局数据仓库
(登台区域)
全局数据仓库
图6-11 在局部层上有可能使全局数据登台，然后将其传送到总部层的全局数据仓库
6.5 冗余
从数据冗余的角度考虑，局部数据仓库和全局数据仓库间存在着冗余问题。图 6-12显示了
124 数据仓库
下载
一种策略，可避免局部层和全局层间的数据冗余(就此而言，全局数据是存放在局部登台区还是
存放在全局层并不重要)。当局部数据仓库和全局数据仓库间的数据出现冗余时，即表明没有正
确定义不同级别的数据仓库所辖的范围。当出现局部层和全局层之间的范围差别时，出现蜘蛛
网问题将是迟早的事。为此，采用局部数据和全局数据相互排斥的机制将是一种重要策略。
站点A 总部
局部操局部操
互相排斥
局部数据仓库局部数据仓库
互相排斥
全局数据仓库
全局数据仓库
(登台区域)
(登台区域)
图6-12 数据可以存放在局部数据仓库或全局数据仓库，但不能两者都存放
6.6 全局数据存取
与管理不同的数据仓库所需要的策略相一致，还有一个数据存取问题。初看起来，这个
问题好象微不足道，但实际却存在重要分歧。
图6 - 1 3表明了一些局部站点正在存取全局数据的情形。这些存取方式正确与否是与查询
有关的，它们可能是或不是数据仓库的正确使用方法。如果在存取过程中，全局数据被作为
信息使用并且仅被访问一次，那么在局部层上这种存取方式就可能是正确的。
总部
局部操
作型处理
站点A
局部数据仓库
站点B
站点C
全局数据仓库
图6-13 需要解决的一个重要问题是局部站点是否应访问全局数据仓库
下载
原则上，局部数据应局部使用，全局数据应全局使用。但这又会引发另一个问题：为什
么全局分析还要局部处理呢？通常没有好的理由来作出解释。
另一个问题是在体系化信息环境中信息请求的路径选择问题。当仅存在一个单一的中央
数据仓库时，此问题关系不大。但是当数据分布在一种复杂环境中时，例如图 6 - 1 4所示的分
布式数据仓库中，就需要一定数量的处理来确保能在正确的位置存取数据。
站点A
局部操
作型处理
局部数据仓库
全局数据仓库
查询：“公司上个月总的月薪支出是多少？”
(登台区域)
查询：“上月EDS在Tampa的设备维护费是多少？”
总部
站点B 局部操
作型处理
局部操
作型处理
局部数据仓库
局部数据仓库
全局数据仓库
(登台区域)
全局数据仓库
(登台区域)
图6-14 正确响应查询需要引向体系结构的不同位置
例如，通过查询局部站点来确定整个公司的薪水是多少，这是不正确的。还有，在全局
数据仓库中查询上月在某一特定站点上某一承包人的费用支付也是不正确的。
本章没有论述有关全局操作型数据这一相对独立的问题，仅举了一些每个局部站点具有
自己的特有数据和处理的实例。然而局部站点的操作型系统间存在某些共同性是完全可能的。
分布式数据仓库的整个问题是比较复杂的。在简单的单一中央数据仓库环境下，其作用
与功能是相当明了的。但是在分布式数据仓库环境下，范围、协调、元数据、响应性、数据
传输以及局部数据映射等问题确实使得环境复杂化了。
126 数据仓库
下载
6.7 分布式环境下其他考虑因素
分布式数据仓库的出现并不仅是由于公司向多个地区扩展而引起的，也有其他一些因素。例
如，一种因素是把数据仓库置于销售商的分布式技术基础上，Client/Server技术非常适合这种需求。
第一个问题是，数据仓库能采用分布式技术吗？答案是肯定的。第二个问题是，数据仓
库采用分布式技术的优缺点是什么？分布式数据仓库的第一个优点是引入代价低。换句话说，
对于一个数据仓库，当最初采用分布式技术时，软硬件代价要比最初采用传统的大型集中式
技术代价低。第二个优点是存放在数据仓库中的数据量理论上无限制。如果数据仓库中的数
据量开始超过分布式处理器的处理能力，那么可在网络中加入另一个处理器。所以可实现持
续增加数据。
图6 - 1 5中所示的进程描述了一种可能出现数据仓库中数据量无限增加的情况。这是具有
吸引力的，因为一般数据仓库将包含越来越多的数据(但并不是无限量)。
第一天
一个服务器存放数据仓库中的所有数据两个
服务器存放数据仓库的数据
两个服务器存放数据仓库的数据
第二天
存放数据的服务器的数目可根据数据仓库
第三天
的需求无限扩张(至少理论上如此)
图6-15 添加服务器来保存数据仓库中的数据的进程
但是随之又带来另一些问题，当数据仓库中的处理器(即服务器)扩展到一定数量时，网上
将出现过量的传输负载。图 6-16表明这种结果。
图6-16 增加服务器时网络中可能出现过量负载
下载
另外，当数据分散在多个服务器上时，会出现一个查询需要访问多个服务器上的大量数
据的问题。图6-17描述了一个查询希望调用来自多个服务器的大量数据。
数据仓库
查询
图6-17 一个查询访问多个数据仓库服务器上的大量数据
当然存在着一些技术和方法来处理分布在多个服务器上的数据仓库问题。确定无疑的是，
随着时间的推移，数据仓库变得非常庞大。在分布式数据仓库的早期，这里讨论的问题还不
明显，但是随着数据仓库越来越成熟，数据已变得很难管理了。
6.8 管理多个开发项目
许多企业采用数据仓库技术时，首先是为财务或市场管理部门建立数据仓库。一旦获得
成功，企业内其他部门就希望在此基础上建立相应的数据仓库。总之，数据仓库的体系结构
设计者就需要管理和协调企业内的多个数据仓库项目。
6.9 开发项目的性质
数据体系结构设计者管理多个数据仓库开发项目时，所面临的首要问题是开发项目本身
的性质。除非他们知道这些数据仓库开发项目的类型以及它们同整个体系结构的关系，否则
将很难管理和协调这些开发项目。由于不同方法所涉及的开发问题是非常不同的，所以不同
类型的数据仓库项目需要采用完全不同的管理方案。
多个数据仓库开发项目可以分为四种典型情况，这些情况大体如图 6-18所示。
首先，图 6 - 1 8中给出一种较少出现的情况，即一公司内的业务范围之间是完全分离的、
非集成的，对应的数据仓库是由不同的开发小组独立创建的。不同的业务范围独立向公司汇
报，但是与共享公司名称不同，在公司内没有业务集成和数据共享。这种公司的结构不是未
知的，但不是常见的。在这种没有任何业务集成的罕见情况下，一项数据仓库开发项目与另
一项数据仓库开发项目间发生冲突的危险几乎没有。相应地，数据仓库开发项目间很少或不
需要管理和协调。
第二种情况是当多个数据仓库项目同时出现时，各个开发小组负责创建同一个数据仓库
128 数据仓库
下载
的不同部分，而导致多个数据仓库开发项目同时出现。在这种情况下，同一级数据是由不同
开发小组创建的，但是它们分散在不同的地理位置。前一种情况很少出现，而这种情况却是
常见的。为了从总体上获得满意的集成效果，要求开发小组间进行密切协作。若开发项目不
协调，则大量数据的冗余存储和处理将可能导致较大的浪费。如果数据存在冗余，那么建立
的数据仓库的效率可能很低，因为 D S S环境中将存在典型的蜘蛛网问题。由于这种情况较常
见，所以值得充分关注。
数据仓库A 数据仓库B 数据仓库C 数据仓库D

业务范围A 业务范围B 业务范围C 业务范围D
完全非集成的业务范围各拥有自己的数据仓库
东北部数据仓库中西部数据仓库西部数据仓库东南部数据仓库
同一数据仓库具有一些分布式部分
轻度汇总的 OLAP
细节数据
同一数据仓库内不同级的数据
数据仓库的细节级的不同的非分布式部分
图6-18 多个小组建造数据仓库的四种可能方式
第三种情况是，当多个数据仓库项目开发同时出现时，不同小组负责建立数据仓库环境
中的不同级的数据(即汇总数据和细节数据)。这种情况也很常见。由于许多原因这种情况比前
下载
面提到的两种情况较易管理。
第四种情况是，多个小组试图以非分布式的方式建立数据仓库环境中数据当前细节级的
不同部分。这种情形很少出现，但是一旦发生，就必须特别注意。最后这种情况非常关键，
数据体系结构设计者必须知道问题是什么以及如何协调它们。
对于每种情况，下面我们将就所涉及的问题和各自的优缺点分别进行讨论。本节先讨论
一下完全无关的数据仓库。
完全无关的数据仓库的建立和运作如图 6 - 1 9所示。某公司有四个业务范围：高尔夫球场
管理、炼钢厂、小额银行业务和快餐联营。业务间没有任何集成，因此将来的数据仓库间也
不需要协调。从建模到基本技术的选择等所有机制(即平台、 DBMS、存取工具、开发工具等)，
每个不同的业务范围均可完全独立进行。

快餐联营炼钢厂小额银行业务高尔夫球场管理
图6-19 四个完全独立的业务部门在业务级没有或很少有数据集成
对于所有自主的业务范围，在某一层上可能也是必须集成的，例如财务平衡表。如果各
个业务范围对一个单财务实体负责，那么在财务平衡表层上就必须集成。可能需要建立一个
企业数据仓库来反映企业财务。图 6 - 2 0表明了一个针对上述不同业务部门的企业财务数据仓
库。
企业财务数据模型

图6-20 独立的业务部门间具有共同的企业财务数据
企业的财务数据仓库包含简单(抽象)的一些实体，例如花费、收入、资金支出、折旧等信
息，基本上都是在每个平衡表中出现的业务数据。(换句话说，在财务数据仓库中没有公用企
业描述信息，诸如客户、产品、销售等。)当然，图 6 - 2 0描述的企业财务数据仓库中的数据可
能来自局部数据仓库或在独立运作公司层中所出现的操作型系统。
局部层确实需要元数据。如果有企业财务数据仓库，那么企业财务层也需要元数据。但
是在这种情况下，不必要把任何元数据都捆绑在一起。
130 数据仓库
下载
6.10 分布式数据仓库
与无关的数据仓库模式不同，大部分企业内的部门间存在某种程度的集成。很少的企业
是像图6-20所示的那样自主的。更常见的多个数据仓库项目的开发形式如图 6-21所示。
非洲数据仓库美国数据仓库加拿大数据仓库远东数据仓库南美洲数据仓库
图6-21 逻辑上属于同一个数据仓库
在图6 - 2 1中，某公司在世界各地诸如美国、加拿大、南美、远东，非洲等地设有不同的
分支机构(站点)。每个分支机构具有自己特有的数据。机构间不存在数据重叠，特别是对于细
节事务数据。当第一个体系结构环境建立后，公司期望为它的每个分公司也创建一个数据仓
库。在不同的分支机构间存在某种程度的业务集成，同时也假定在不同的区域，业务运作具
有当地特色。这种企业组织模式在许多公司是很常见的。
许多企业建造数据仓库时，首先是在每个位于不同地域的部门内创建一个局部数据仓库。
图6-22表明了一个局部数据仓库的构造情况。
每个分部根据自己的需要创建富有本地特色的自主数据仓库。值得注意的是，至少就事
务数据而言，在不同的区域间不存在冗余的细节数据。换句话说，反映非洲事务的数据单元
不可能出现在欧洲的局部数据仓库中。
远东数据仓库
加拿大数据仓库
非洲数据仓库
美国数据仓库南美洲数据仓库
图6-22 在每个自主运作部门建立局部数据仓库
用这种方法创建分布式全局数据仓库有几个优缺点。优点之一是能很快完成。每个局部
小组控制局部数据仓库的资源和设计。它们也乐于拥有这样的自主权和控制权。这样开发的
数据仓库的优点能在整个企业内实时地表现出来。在 6个月内局部数据仓库就能建好、运行并
使局部层分公司受益。不利之处是如果部门间的数据结构(不是内容)存在共同性的话，这种方
法却不能识别或合理处理这样的共同性。
下载
6.10.1 在分布的地理位置间协调开发
另一种方法就是尽量协调不同的局部组织间的局部数据仓库的开发项目。这种方法理论
上听起来很合理，但真正贯彻起来不太有效。局部开发小组之间不可能完全同步，局部开发
小组期待中央开发小组协调局部开发小组的项目，处理出现的各种矛盾。建立了分离的数据
模型来支持每个分离地点的数据仓库的构建。
当数据仓库建造的价值在局部层表现出来后，公司就会决定建造一个企业数据仓库(图 6 -
2 3)。企业数据仓库反映不同地区、不同部门间的业务集成。它与局部数据仓库有关，但又不
同。建立企业数据仓库第一步是在企业数据仓库中为相关的业务部门建立企业数据模型。一
般来说，建立企业数据模型采用反复的方法。开始时，数据模型的规模较小、比较简单且限
制于一个业务子集。图 6 - 2 4显示了企业数据模型的建立。在企业数据模型建立后，将形成企
业数据仓库。
远东数据仓库
非洲数据仓库
美国数据仓库企业数据仓库
南美洲数据仓库
图6-23 某天决定建立企业数据仓库
远东数据仓库
非洲数据仓库
企业数据模型
美国数据仓库企业数据仓库
图6-24 建立企业数据模型
132 数据仓库
下载
6.10.2 企业数据分布式模型
企业数据模型反映企业层的业务集成，因此可能与局部数据模型中的某些部分重叠。这
是合理的也是正常的。而在其他情形下，企业数据模型与局部数据模型不同。不管什么情况，
都由局部组织来决定如何使企业的数据需求和局部的数据提供能力相适应。因为局部组织比
任何人都更了解自己的数据，它们做了最好的准备来表明应如何组织和重组织自己的数据以
满足数据仓库中企业数据设计的规范。
当局部层间数据的重叠部分的结构设计得较好时，数据内容上不会有较大范围的重叠。
图6-25显示出从局部层建立和装载企业数据仓库的情况。
企业数据仓库的数据源可能来自局部数据仓库，也可能来自局部操作型系统。记录系统
完全应在局部层确定。记录系统的定义大多需要几次循环往复。
远东数据仓库
非洲数据仓库
企业数据仓库
美国数据仓库
图6-25 从不同的自主运作部门装入的企业数据仓库
此外，一个重要的设计问题是从技术角度考虑如何将局部层的记录系统数据创建和传送
到企业数据仓库。在某些情况，正式“登台的”数据保留在局部层。而另一些情况，它们被
传送到企业环境，且在局部层不可存取。
通常，企业数据仓库中的数据在结构和概念上一般都是简单的。图 6 - 2 6表明企业数据仓
库中的数据对企业层的 DSS分析员来说是细节数据，同时对局部层的 DSS分析员来说却是汇总
数据。这种表面上的矛盾同这样一个事实是一致的，即表现为汇总数据还是细节数据是由观
察的角度决定的。
下载
南美洲数
据仓库
汇总数据
细节数据企业数据仓库
图6-26 在一个层次上是细节的而在另一个层次上是汇总的
分布式数据库的企业数据仓库与完全无关的各公司的企业财务数据仓库的对比，如图 6 -
27所示。
加拿大数据仓库远东数据仓库
非洲数据仓库
企业数据仓库
十分相似
美国数据仓库
企业财务数据模型

图6-27 分布式公司的数据仓库可以非常类似于一些无关公司的数据仓库
134 数据仓库
下载
分布式公司的数据仓库在许多方面非常类似于无关公司的数据仓库，诸如在设计和运作
方面。然而，它们之间存在一个主要区别。企业分布式数据仓库是对业务本身的扩展，反映
客户、销售商、产品等集成信息。因此企业分布式数据仓库表示了业务本身的体系结构。但
是，业务无关的公司的企业数据仓库是专门为财务服务的，希望将财务数据仓库应用到公司
各部分的其他关系上是不可能的。两个数据仓库的不同是它们表达数据的深度不同。
6.10.3 分布式数据仓库中的元数据
在整个分布式的企业数据仓库中元数据起着非常重要的作用，通过它可以协调不同地域
的数据仓库中的数据结构。毫无疑问，元数据为获得一致性和相容性提供了工具。
6.11 在多种层次上建造数据仓库
一个企业同时建造数据仓库的第三种模式是不同的开发小组负责建造数据仓库的不同层
次，如图 6-28所示。这种模式与分布式数据仓库开发模式区别很大。在图示的情况下， A组负
责建造高层综合的数据， B组建造中层综合的数据， C组建造当前层细节数据。
开发小组 B
开发小组A
OLAP
轻度汇总的
细节数据
开发小组C
图6-28 不同的开发小组负责建造数据仓库不同层的不同部分
这种数据仓库的多层模式是很常见的。幸运的是，这种方式很易管理，且风险最小。数
据体系结构设计者主要关心的问题是如何协调不同开发小组的工作，包括内容的规范说明和
结构的描述以及确定开发时间等。例如，如果 A组的进展明显在 B组和C组的前面时，那么将
出现一个问题，即当 A组在汇总级装载他们的数据时，要使用的细节数据可能还不存在。
不同的开发小组同时建造同一数据仓库的不同汇总级时，一个有趣的问题是，正是建造
当前细节级的开发小组在使用数据仓库的数据模型。图 6-29显示了这个关系。
开发小组A 开发小组B
OLAP
轻度汇总的
细节数据
数据模型
开发小组C
图6-29 正在开发最低细节级的开发组使用该数据模型
下载
数据仓库的数据模型直接反映了负责当前细节级分析和设计的开发者的开发工作。当然，
数据仓库模型是间接地反映了所有开发小组的需求。但是由于其他开发小组是对当前细节级
数据进行汇总的，所以它们对各自的需求又有进一步的描述。在大多数场合，较高汇总级的
开发者拥有自己的反映他们特定的需求的数据模型。
在数据仓库中管理建造不同汇总级的多个小组的问题之一，是数据仓库各层采用的技术
平台的问题。一般来说，不同的开发小组选用的开发平台不同。事实上，不同的开发小组选
取相同平台的情况确实也不常见。这有几个原因，而主要的是代价问题。数据的细节级，由
于处理的数据量大，所以要求一个企业级的平台。不同汇总级，特别是在较高的汇总级，需
处理的数据量相对较少，所以要求较高的汇总级同细节级采用同一平台(尽管这也是可以的)未
免太过分(代价太高)。
数据仓库中各种汇总级常常被置于不同于细节级数据平台的其他技术平台上的另一个原
因，是这些可选用的平台提供更多种多样的特殊软件，而这些软件中的许多是驻留细节数据
的单一平台上所没有的。不管数据的不同层次是采用单一平台还是多种平台，都必须认真存
储和管理元数据，以保证从一个细节级到下一层细节级的连续性。
由于数据仓库的不同开发小组在开发不同数据级时通常采用不同平台，这就出现了互连
性问题。图 6-30显示了级间的互连性需求。
轻度汇总 OLAP
细节数据
图6-30 数据仓库的不同级次之间的互连性是个重要问题
我们从几个方面来强调互连性问题。一是在调用( Call)级存取的兼容性。换句话说，在数据
仓库的任何两级之间构成细节数据和汇总数据时所采用的技术间在调用语法上是否兼容？如果不
存在一定程度的调用级语法的兼容性，那么接口的使用将会出现问题。互连性问题的另一个方面
是有效带宽。如果数据仓库的每一级都有很重的负载，那么两种环境间的接口将会成为瓶颈。
但是，从事数据仓库开发的小组是相互协作的，需要保证管理低级细节数据的开发小组能
为汇总数据和建立新层次数据的开发小组提供一个正确的数据基础。这种要求如图 6-31所示。
汇总
轻度汇总
细节数据
细节
图6-31 细节级数据是建立数据综合级的基础
136 数据仓库
下载
开发小组间的协作可以像满足各部门的数据需求的数据模型上的一个协议一样简单。如
果条件许可，也可制定非常精细的协议。
开发项目本身的协调是另一个问题。不同的开发小组之间需要遵循一定的时间顺序安排，
以使所有开发小组在需要数据之时都能获取所需的在较低级上收集到的数据。
6.12 多个小组建立当前细节级
当多个开发小组试图以非分布式的方式建立数据仓库中的当前细节级时，将出现某些特
殊情形。图 6-32显示了这种现象。
开发小组A
开发小组E
开发小组B 开发小组D
开发小组C
图6-32 不同的开发小组共同建立数据仓库中的当前细节级
只要开发当前细节级的开发小组开发的数据集是互斥的，就不会出现太多问题。在这种
情况下，只要这些开发小组使用相同的数据模型，且不同开发者的技术平台间存在兼容性，
那么就很少有风险。不幸的是，这种情况很少出现。更常见的是，多个开发小组设计和装载
的是一些或全部相同的数据，如图 6-33所示。
开发小组B
开发小组A
开发小组E
开发小组C
开发小组D
图6-33 不同开发小组开发的数据出现重迭
下载
当数据出现重迭时，将会引起一系列问题。第一个问题是代价，特别是存储和处理的代
价。必须考虑当前细节级数据中的所有冗余数据，尽可能减小任何数据冗余量。处理细节的
代价也是一个主要问题。
第二个比较糟糕的问题是将蜘蛛网问题引入了 D S S环境。由于存在大量冗余的细节数据，
所以自然会造成对数据的错误解释，且没有有效的解决方法。因此在数据仓库中的细节级创
建大量冗余的细节数据是非常不期望的状况，这就违背了它的目的。如果多个开发小组并行
地设计和装载当前细节级数据，那么一定要确保没有创建冗余数据。
为了确保在细节级不存在冗余数据，必须创建反映共同细节数据的数据模型。图6-34显示了
多个开发小组根据他们的兴趣组合共同创建一个公用的数据模型的情形。除了当前活跃的开发
小组，将来可能介入的其他开发小组也可能提供他们的需求。当然，如果开发小组知道将来的
需求，但是又不能清楚地描述它们，那么这些需求也不会作为公用细节数据模型中的考虑因素。
公共数据模型
开发小组C
的特有数据
开发小组A
的特有数据
开发小组A,B,C,D的公用数据
开发小组 D
开发小组B
的特有数据的特有数据
图6-34 对于所有开发小组，数据模型标识公用数据
公用细节数据模型反映了数据仓库中细节数据不同开发者的共同需求。
数据模型构成了数据仓库设计的基石。图 6 - 3 5表明在设计过程中数据模型将分割为多张
表，它们中的每个均成为数据仓库物理上的一部分。
公共数据模型
客户活动历史数据销售商历史数据
客户调查历史数据
销售历史数据替换部件历史数据
部件历史数据
装运历史数据
客户历史数据部件不合格历史数据
客户投诉历史数据货物到达历史数据货物装运破损历史数据
销售报价历史数据
图6-35 数据仓库在物理上分布在多个物理表和数据库中
138 数据仓库
下载
由于在实现时数据模型分割为多张物理表，所以数据仓库的开发过程采用反复的方法，
不需要立即建立所有表。事实上，在一个时期建立几张表有诸多原因，这样处理，可在需要
时使用最终用户的反馈信息来有条不紊地修改表。另外，由于公用数据模型分割为多张表，
所以在以后的某个时刻增加新表来弥补目前未知的需求不致成为问题。
6.12.1 不同层不同需求
一般来说，不同开发小组的需求不同(见图 6 - 3 6)，这些特殊的需求就导致了所谓的“局部
的”当前细节级。这些局部数据肯定是数据仓库的一部分。但是它与“公用”部分是截然不
同的。局部数据有自己的数据模型，通常比公用细节数据模型更小更简单。
公共数据模型
局部当前细节级数据
开发小组A特有的数据
开发小组B特有的数据
开发小组A,B,C,D共同的数据
开发小组C特有的数据
开发小组D特有的数据
图6-36 数据仓库中的当前细节级包含各开发小组的特有数据
所有的细节数据肯定不存在冗余。图 6-37清楚地说明了这点。
客户活动历史数据销售商历史数据
客户调查历史数据
销售历史数据替换部件历史数据
部件历史数据
装运历史数据
客户历史数据部件不合格历史数据
客户投诉历史数据货物到达历史数据货物装运破损历史数据
销售报价历史数据
图6-37 构成数据仓库细节级的多张表中非键码数据的非冗余性
下载
当然，数据非冗余性限制于非键码数据。在键码级数据肯定是冗余数据，因为外键码用
于将不同的数据类型相关联。图 6-38显示了使用外键码关联不同表的情况。
在图6 - 3 8的表中发现的外键码与受参照完整性所支配的典型的外键码关系不同。因为数
据仓库中收集和存取的是快照数据，出现的外键码关系是以人工关系组织的。
装运历史数据
销售历史数据
销售商历史数据
客户历史数据
部件历史数据
图6-38 数据仓库环境中的外键码
能否采用同样的技术来存放所有的细节表(公用的和局部的)？图 6 - 3 9显示了所有表以同
样技术存放的情况。以单一技术平台存放所有细节表有许多正当理由。一是单一平台比多个
平台代价低，二是维护和培训费用较低。细节数据采用多个平台唯一的原因是，使用多个平
台可能将不需要单一的大平台，而多个小平台的代价可能比一个大平台的代价要低。不管怎
么说，事实上许多机构为它们的所有细节数据仓库数据采用单一平台策略，并且运行效果很
好。
140 数据仓库
下载
开发小组B特有的数据开发小组D特有的数据
开发小组 A,B,C,D共同的数据
公用的技术平台
图6-39 数据仓库细节级不同类型的数据都在同一个技术平台上
6.12.2 其他类型的细节数据
另一种策略是对不同类型的细节级数据使用不同的平台。图 6 - 4 0显示了采用这种配置的
一个实例。一些局部数据使用一种平台，公用数据使用另一种平台，而其他的局部数据采用
一种其他的技术平台。这种选择具有一定的合理性，能很好地满足企业内不同的策略需求。
采用这种选择，不同的开发小组至少能对自己特有的需求具有一定程度的控制能力。不幸的
是，这种选择有几个主要的缺陷：必须购买和支持多个技术平台，最终用户必须接受多种技
术培训，技术间的界限很难跨越等。图 6-41表明这种困境。
开发小组B特有的数据开发小组D特有的数据
开发小组A,B,C,D共同的数据
平台B
平台C
平台A
图6-40 数据仓库的当前细节级数据的不同部分分散在不同的技术平台上
下载
开发小组B特有的数据开发小组 D特有的数据
开发小组A,B,C,D
共同的数据
数据传输
平台A 平台C
平台B
图6-41 数据传输和多表查询出现特殊技术问题
平台B
平台A
平台C
成批传输数据
分析完后的剩余数据
图6-42 不同平台间的接口问题
142 数据仓库
下载
如果数据仓库中细节的不同级采用多种技术，那么就必须经常跨越技术间的边界。 IBI 的
EDA/SQL最终用户技术能很好的适应这种需求。然而不幸的是，即使是像 EDA/SQL这样强有
力的软件工具，仍然存在体系结构上的问题。存在的一些问题如图 6-42所示。
问题之一是数据传输。如果 EDA/SQL接口用于少量的数据传输，那么效果还可以。但是，
如果E D A / S Q L用于大量的数据传输，那么 E D A / S Q L将会成为性能的瓶颈。不幸的是，在 D S S
环境中，对任一个请求都不可能预先知道它将访问多少数据。某些请求可能访问非常少的数
据，而另一些可能访问大量数据。当细节数据位于多种平台上时，资源的利用和管理的问题
将显现出来。
另一个相关的问题是“剩留”细节数据，即当细节数据从某地传送到另一个地方时将它
们驻留在当地的数据仓库。这种随意的细节数据搬迁将会导致细节级数据的冗余，在一定程
度上是不可接受的。
6.12.3 元数据
在任何情况下，无论采用多种技术还是单一技术管理细节数据，元数据扮演的角色都不
可忽略。图 6-43表明元数据需要位于数据仓库的细节数据的顶层。
元数据
客户活动历史数据
销售历史数据部件历史数据
装运历史数据
客户投诉历史数据
客户历史数据
销售报价历史数据销售商历史数据
图6-43 元数据位于数据仓库的顶层
6.13 公用细节数据采用多种平台
另一种可能性也是值得考虑的，即公用细节数据采用多种技术平台。图 6 - 4 4概括了这种
可能性。
开发小组间的公共数据
当前细节数据
平台A 平台B 平台C
图6-44 公用的细节数据采用多种开发平台
下载
但是这种可能性只是一种选择方案，决不是很好的选择。管理当前公用的细节数据是很
困难的。在细节级别出现大量数据将会面临许多特殊管理问题。所以采用多种技术平台只能
增加管理的复杂性。一般不推荐使用，除非有特殊的减轻策略。
6.14 小结
大部分企业建立和支持单一的中央数据仓库环境。但是在某些特定场合，建立分布式数
据仓库环境可能会取得更大效益。局部数据仓库拥有局部操作站点感兴趣的数据；分布式全
局数据仓库的数据及数据结构由全局层决定，而局部层到全局层的数据映射由局部处理。
总之，管理和协调分布式数据仓库环境比管理和协调单一场地的数据仓库环境要复杂得多。
下载
第7章高级管理人员信息系统和数据仓库
EIS— 高级管理人员信息系统 — 是计算的最有效形式之一。通过 EIS，高级管理分析员
可以精确指出问题并发现对于管理至关重要的趋势。在某种意义上说， E I S代表着对计算机最
复杂的使用之一。
E I S处理是出于帮助高级管理人员制定决策的目的而设计的。 E I S变成了高级管理人员观
察公司运营的窗口。 EIS处理总揽全局并且弄清与商业运作相关的方面。 EIS最典型的用途是：
■ 趋势分析和发现。
■ 关键比例指示器度量和跟踪。
■ 向下探察分析。
■ 问题监控。
■ 竞争分析。
7.1 一个简单例子
在高级管理人员看来 E I S分析是怎样的呢？作为一个例子，见图7 - 1，它显示了一家保险

公司提供的保险信息，按季度次序跟踪新的人寿、健康、意外事故保险的销售情况。这张简
单的图表是高级管理人员调查生意情况的一个良好的出发点。如图7 - 2中趋势分析所示，一旦
高级管理人员看到全面的信息，他(她)就能做更深入的调查。
如图7-2，高级管理人员已经把新人寿保险销售、新健康保险销售和新意外事故保险销售分
高级管理人员和EIS
500
400
300
全部保险单
200
100
第一季度第二季度第三季度第四季度第一季度第二季度

新人寿保险
新健康保险
新意外事故保险
图7-1 EIS处理的典型图表
下载
第7章高级管理人员信息系统和数据仓库 145
隔开。观察新意外事故保险销售，高级管理人员识别出一个趋势：每个季度的新意外保险销售
一直在下降。识别出这种趋势后，高级管理人员就能进一步研究为什么销售额会一直下降。
EIS中高级管理人员能看到什么
400
300
200
100
图7-2 趋势—新意外事故保险定单下滑
EIS分析提醒高级管理人员趋势是怎样的，然后就该他(她)去发现造成这种趋势的内在原因了。
高级管理人员对积极的和消极的趋势都感兴趣。如果生意正在变糟，那么为什么会变
糟？以什么样的速度变糟？要补救这种情况，能作些什么？或者，如果生意正在上扬，那么
为什么会上扬？为促进成功因素，能作些什么？这些成功因素能用到生意上的其他领域吗？
但是趋势分析并不是 E I S所能作的唯一的分析类型。另一种有用的分析类型是比较分析。
图7-3显示了一种 EIS分析中可能用到的比较分析。
比较
500
400
300
200
100
新人寿保险
新健康保险
图7-3 为什么在过去的三个季度里新健康保险的销售额会存在如此的差异
146 数据仓库
下载
观察图7 -3中第四季度数据、第一季度数据和第二季度数据，就会提出问题：为什么在过
去的三个季度里新健康保险的销售额会存在如此的差异？ E I S处理提醒管理者注意这些差异。
然后就该EIS分析员去确定其根本原因了。
对一个大型的多种经营的企业的管理者来说， E I S允许以很多方式观察企业行为。试图跟
踪大量行为比只试图跟踪少量行为要困难得多。从这个意义上说， E I S可以用来拓展管理者的
控制范围。
但是趋势分析和比较分析还不是管理者有效使用 E I S的仅有方法。另一种方法是“切片和
切块”。从这里，分析员取得基本信息，用一种方式分组并且分析它。然后用另一种方式分组
再分析它。切片和切块允许管理者对正在发生的行为进行不同侧面的观察。
7.2 向下探察分析
为了切片和切块，有必要“向下探察”数据。向下探察数据是指从一个汇总数据开始，
将该汇总数据逐次地分解成一组更细致的汇总数据。因为向下探察能够得到汇总数据下的细
节，所以管理者能够知道当前情况，特别是哪里的汇总数据值得关注。图7 - 4显示了一个向下
探察分析的简单实例。
西部地区
东南部地区
东北部地区
中部地区
图7-4 为使EIS显示的数据有意义,汇总数据需要支持向下探察处理
在图7- 4中，管理者已经看过了第二季度的汇总结果并想进一步探讨。管理者观察构成汇
总的各个地区的汇总数据。要分析的是西部地区、东南部地区、东北部地区、中部地区的数
据。在观察各个地区数据的过程中，管理者决定仔细查看一下东北部地区的数据。
东北部地区的数据是 New York，Massachusetts，Connecticut，Pennsylvania，New Jersey，
Vi rg i n i a，M a i n e，Rhode Island和Ve r m o n t的数据综合。在这些州中，管理者决定再仔细观察
New York州的数据。这就需要再查询该州有保险销路的各个城市的数据。
一般情况下，管理者选择一条从汇总数据到细节数据的路径，然后逐次进入到下一层进
行观察。在这种模式下，他 /她能够确定哪里存在问题。一旦发现异常，管理者就知道从何处
去查看能做出更好解释的数据。
有很多成熟的软件能用于 E I S，把分析结果呈现给管理者。 E I S的困难之处不在于图形表
示，而在于显示图形过程中所进行的查找和准备数据的过程，如图7 -5所示。
下载
只要数据存在， E I S就完全能够以图形的形式支持向下探察处理。但如果要分析的数据不
存在，向下探察处理就变得乏味而笨拙。这样的向下探察就不是高级管理人员需要的了。
EIS软件和
向下探察处理
图7-5 只要能取得需要的数据并且数据构造得合理，EIS软件就会支持向下探察处理
7.3 支持向下探察处理
生成用于向下探察分析的基本数据是成功地完成向下探察处理的主要障碍，如图7 - 6所
示。
购买及安装 EIS软件
既快又容易
图7-6 困难在于生成用于EIS处理的基本数据
事实上，有一些研究表明，每花费 1美元用于开发 E I S软件和硬件，就要为向下探察准备

数据花费9美元。
之所以要夸大这个问题，是因为高级管理人员关于感兴趣的事情总是不时地改变主意。
图7-7显示了使高级管理人员感兴趣的事情总是不时变化的特性。
某天，高级管理人员想了解公司的财务状况， E I S 分析员花费很大精力找出了支持这个
EIS需求的基本数据。第二天，意外地出现了一个生产问题，管理者又把注意力转向这个问题，
E I S分析员就赶紧尽力收集高级管理人员需要的数据。第三天， E I S分析员又不得不将注意力
转向发货中出现的问题。
148 数据仓库
下载
每当新问题或新机遇出现时，管理者的关注焦点就会改变。没有模式能预测管理者关注
的下一个焦点是什么。结果是 E I S分析员总是处在鞭梢的位置。 E I S分析员总是处于一种被动
响应的状态。并且，一旦为 EIS分析准备基本数据的工作分配下来， EIS分析员就会疲于奔命。
第一天管理者
管理者对财务状况感兴趣
第二天管理者
出现一个生产问题
财务
生产
第三天管理者
突然又出现了一财务
个发货问题
图7-7 • 管理者的注意力经常在转移
• 注意力转移是随机的
• 管理者总想得到当前需要的数据
• 最后，管理者希望数据是集成的
下载
7.4 作为EIS基础的数据仓库
数据仓库运行在 E I S环境中。数据仓库是根据 E I S分析员的需要而定制的。一旦建立了数

据仓库， E I S的工作比起没有数据仓库时要容易得多。图7 - 8显示了数据仓库怎样对 E I S的数据
需求提供支持。
有了数据仓库， EIS分析员：
■ 不必搜索限定的数据源。
■ 不必从现存系统中生成特定的抽取程序。
■ 不必担心非集成的数据。
■ 不必担心细节数据和汇总数据及两者之间的连接。
■ 不必担心寻找合适的数据时基。
■ 不必担心管理者是否改变下一步要观察的对象。
■ 有大量的汇总数据可用。
数据仓库
管理者
管理焦点的不可预见性
图7-8 数据仓库：
• 当需要时在适当位置
• 是集成的
• 有细节数据和汇总数据
• 包含管理需要的所有主题
• 有趋势分析需要的长的数据时基
简言之，数据仓库提供了 E I S分析员有效地支持 E I S处理所需要的数据基础。有了内容丰

富的、在适当地方的数据仓库，分析员就能以主动的姿态去满足管理者的需求 — 而不是无
休止地被动地响应。 E I S分析员的工作从数据工程师的工作转变成真正的分析工作，这多亏了
数据仓库。
7.5 到哪里取数据
E I S分析员为取得数据，可能会转向体系结构中多个不同的位置。如图7 - 9所示，E I S分析

150 数据仓库
下载
员可能到个体处理层、部门(数据集市)处理层、轻度汇总处理层或真实档案处理层去取数据。
EIS分析员可以从任何地方取得数据。
并且， E I S分析员为满足管理需要取得数据的过程，总是遵循一个通常的顺序或层次 (如
图7-9)。
操作型数据仓库部门个体
环境 (数据集市)
部门
轻度汇总
数据
真实档案
EIS
图7-9 EIS到哪里取数据
如图7-10所示，采用这种顺序有很充分的理由。在从个体处理层转向真实档案处理层的过
程中，分析员事实上进行了向下探察分析。体系结构设计环境中汇总程度最高的数据出现在个
体层。个体层的汇总支持层是部门层，支持部门层汇总的数据来自于轻度汇总层。最后，轻度
汇总层数据由真实档案层数据支持。刚才陈述的汇总顺序正是支持 EIS向下探察分析所必需的。
重复的汇总数据
部门
轻度汇总
数据
高度汇总数据
真实档案
细节数据
图7-10 向下探察处理是从个体处理层到真实档案数据
下载
几乎都按造惯例，数据仓库辟有一条路径用于向下探察分析。在数据仓库的不同层次，
在整个的汇总过程中，数据通过一个键码结构建立关联。键码结构本身或者键码结构衍生出
来的结构将各层数据联系起来，以便能够方便地进行向下探察分析。
EIS
元向下探察
据向下
探察历史
集成
向下
探察
图7-11 数据仓库如何支持 EIS：

① 数据仓库中有丰富的现成的汇总数据
② 数据仓库中数据的结构支持向下考察处理
③ DSS分析员可以通过元数据规划新的分析处理
④ 数据仓库中的历史数据支持 EIS中管理人员对趋势分析的需求
⑤ 数据在进入数据仓库前已经进行了集成化处理，这正是管理
者观察企业运营情况所需要的
数据仓库对 EIS支持的方式如图7 -11所示。

EIS的功能：
■ 用数据仓库支持汇总数据。
■ 用数据仓库结构支持向下探察处理。
■ 用数据仓库的元数据为 DSS分析员规划如何建造 EIS系统。
■ 用数据仓库的历史内容支持管理人员所需要的趋势分析。
■ 用数据仓库中的集成数据观察公司的运行概况。
152 数据仓库
下载
7.6 事件映射
在将数据仓库用于 E I S处理中的一个有用技术是事件映射。描述事件映射最简单的方式是
从简单趋势曲线开始。
图7- 1 2显示公司收入每月都在改变，从数据仓库取得的数据中已经估计出了趋势。收入
趋势本身是令人感兴趣的，但它只是对公司的运营情况给出一个肤浅的了解。要加强这种了
解，就要把事件映射到趋势曲线上。
公司的总收入
一月二月三月四月五月六月七月八月九月十月十一月
图7-12 简单的趋势曲线
如图7 - 1 3，把三个重要事件映射到公司的收入趋势曲线上，它们是“新潮彩电”生产线
的引入，对销售人员激励机制的采用，和竞争机制的引入。这就给出了另一个观察公司收益
和重要事件之间关系的视角。观察图7 - 1 3中的图表，可以得出这样的结论：新生产线和新激
励机制的引入使公司收入猛涨，而竞争机制在年末才开始发挥作用。
公司的总收入
引入“新潮彩电”生产线竞争促进了下一
在销售人员中
年收入的提高
引入激励机制
图7-13 趋势曲线上的事件映射
对某些类型的事件，事件映射是度量事件所产生的结果的唯一方法。一些事件和行为不
能直接度量，而不得不用一种相关方式度量。对于一些类型的事件，成本合理性和实际成本
收益用任何别的方法是不能度量的。
下载
但是，观察相关信息可能会得出错误的结论。而观察与不远将来的事件有关的多于一组
的趋势常常是有帮助的。举个观察多组趋势的例子，图7 - 1 4表明，公司收益与消费者置信指
标结合可以产生具有多个视角的图表。
消费者消费指标 — 由统计局每月公布
公司的总收入
引入“新潮彩电”生产线竞争促进了下一
年收入的提高
在销售人员中
引入激励机制
图7-14 将一个趋势分析置于现存的趋势分析之上，就可以得到另一个分析视角
观察图7-14，高级管理人员就能确定所映射的事件是否对销售产生了影响。
数据仓库可以既存储产生于内部的收入数据，又存储产生于外部的消费者置信数据。
7.7 细节数据和EIS
你需要多少细节数据才能运行你的 E I S / D S S环境呢 ?一种学院派的说法是你需要尽可能多

的细节数据。通过存储尽可能多的数据，你就能做任何当前需要的分析工作。既然 D S S的特
性是探究未知的东西，谁知道你需要什么样的细节数据呢 ?为安全起见，你最好把你当前能得
到的所有细节数据都保存起来。而且，你能得到的历史细节数据越多越好，因为你永远不会
知道为完成给定的 DSS分析，你需要在历史数据中回溯多远。
关于为DSS处理存储大量细节数据的讨论，其核心逻辑很难评论。从理论上说，为 DSS或
E I S处理准备尽可能多的数据肯定是正确的。但是在某些重要方面，关于 E I S中细节数据的讨
论如同Zeno悖论。在Zeno 悖论中，逻辑不可避免地证明，只要乌龟比兔子先出发，兔子就永
远追不上乌龟。实际情况和我们的观察告诉我们并非如此，这警告我们仅仅根据逻辑得出的
结论是不可靠的。
那么，在建造 D S S / E I S环境时，保存所有细节数据为什么错误呢 ?有几个原因。首先，存
储和处理的开销可能是个天价。仅仅存储和处理大量细节数据的开销就不允许建立一个所谓
有效的EIS/DSS环境。说它不切实际的第二个原因是大量数据是有效使用分析技术的一个障碍。
154 数据仓库
下载
有大量的数据需要处理，重要的趋势和模式可能就隐藏在漫无边际的细节数据记录的面罩之
下。第三个原因是前面所做的细节分析不可重用。只要存在大量的细节数据， D S S分析员就
会被鼓舞从头做新的分析。这是一种无益的浪费，甚至具有潜在的危害。因为如果新旧分析
的方式不完全相同，非常相似的分析还可能得到矛盾的结论。
做E I S分析不仅要存储细节数据，也要存储汇总数据。 D S S和E I S分析对汇总数据的使用
与对细节数据的使用一样多。汇总数据比细节数据的数据量小得多，并且管理起来容易得多。
从访问和表示的角度来看，汇总数据对管理来说是理想的。汇总数据是未来分析的基础，并
且，由于它的存在，不必进行重复分析。仅就这些原因，就应将汇总数据作为 DSS/EIS环境的
集成部件。
7.8 在EIS中只保存汇总数据
但是只保存汇总数据也存在一些现实问题。第一个问题就是汇总数据蕴涵着一个过程 —
汇总数据永远是计算过程的结果。计算可能简单也可能复杂。任何情况下都不存在孤立的汇
总数据，它总是和汇总过程联系在一起的。为有效利用从计算过程中得到的汇总数据， D S S
分析员必须取得汇总数据、理解用来产生汇总数据的过程。只有 D S S和E I S理解了汇总过程和
汇总数据之间的关系，并能有效地利用汇总数据，汇总数据才能构成 E I S和D S S分析的理想基
础。但是，如果 EIS/DSS分析员不理解这个过程是与汇总数据密切相关的，分析结果可能会是
误导性的。
汇总数据的第二个问题是汇总数据可能处于也可能不处于即将进行分析所需要的合适的
粒度级。为进行 EIS和DSS处理，需要在数据的细节程度和汇总程度之间进行权衡。
7.9 小结
在E I S分析员的需求和数据仓库之间存在着密切联系。数据仓库显然支持 E I S分析员的所
有需求。有了数据仓库， EIS分析员就不再处于被动地位，而是处于主动地位了。
数据仓库使 EIS分析员能处理：
■ 十分快捷信息的管理需要。
■ 转变其思路的需要。
■ 观察集成数据的管理需要。
■ 观察时间范围内数据的管理需要。
■ 进行向下探察的管理需要。
下载
第8章外部数据/非结构化数据与数据仓库
大部分组织是以现有系统为来源的数据（即企业的内部数据）上建立其第一个数据仓库。
在绝大部分情况下，从现有系统抽取的数据可称为内部结构化数据。数据来自于企业内部，
并且数据已经被变换成一种规则的格式。
但是，企业合法使用的其他大量数据却并非产生于企业本身的系统。这类数据称作外部
数据，通常这些数据是以非结构化的、不可预测的格式进入企业的。图8 - 1表示了进入数据仓
库的外部与非结构化数据。
外部数据非结构化数据
现有系统数据仓库
图8-1 外部数据与非结构化数据都归入数据仓库
数据仓库是存储外部与非结构化数据的理想场所。如果外部数据与非结构化数据没有存
放在一个集中确定的位置，势必会产生一些问题。图8 - 2表明当外部数据与非结构化数据以非
规范的形式进入企业时，就失去了数据来源的标识，并且不管怎样有次序地使用数据都不存
在数据间的协同。
典型地，当外部数据没有进入数据仓库时，这些数据就通过 P C进入企业。在 P C级上，本
质上进入的数据不存在任何错误。但是当数据在 P C级上进入时，几乎都是通过电子表格方式
手工地进入数据仓库，并且绝对没有试图捕获有关附加在数据上的任何数据源的信息。例如，
在图8-2中分析员得到了《华尔街日报》中一个报告。第二天，这个分析员采用《华尔街日报》
中的数据作为某个报告的一部分，然而当此报告进入企业主数据流时，有关原始数据源的信
息就丢失了。
获取外部数据的自由方式所导致的另一个困难是，在以后某个时刻很难回忆起这些数
据的意义。数据进入企业系统，使用一次后便消失了。即使几星期后，也很难重新访问
这些数据。这是很不幸的，因为许多来自外部源的数据在一定时间范围内都是非常有用
的。
来自外部数据源的数据类型是多种多样的。一些典型的主要数据来源如下：
156 数据仓库
下载
《商业周刊》
《华尔街日报》
《福布斯》《财富》
Kiplinger
《新闻周刊》
《洛山矶时报》《巴伦杂志》
图8-2 外部数据与非结构化数据所带来的问题：
• 当数据进入企业时，其来源被删掉了
• 一个分析员没有意识到另一个分析员已将类似的信息输入
■ 《华尔街日报》。
■ 《商业周刊》。
■ 《福布斯》。
■ 《财富》。
■ 工业通信。
■ 技术报告。
■ 《Dun and Bradstreet》。
■ 咨询员专门为企业研究的报告。
■ 《Equifax reports》。
■ 竞争分析报告。
■ 市场比较与分析报告。
■ 销售分析与比较报告。
■ 新产品通告。
另外，还有一些企业内部的报告也同样值得注意：
■ 审计季报。
■ 年度报告。
下载
第8章外部数据/非结构化数据与数据仓库 157
8.1 数据仓库中的外部数据/非结构化数据
在数据仓库中，存在一些与外部数据 /非结构化数据的使用和存储相关的问题。在图8 -3中

所给出的非结构化数据所存在的一个问题是可用频率。与内部出现的数据不同，外部数据没
有呈现的真正模式。当为了确保捕获正确的数据，而必须建立永久的监控方式时，呈现的频
率就成为一个问题。
外部数据非结构化数据
现有系统数据仓库
图8-3 与外部数据有关的问题：
• 访问的频率
• 数据的形式
• 不可预测性
外部数据的第二个问题是数据的形式。外部数据的形式是完全没有规则的。为了使之有
用并能放入数据仓库，就必须对外部数据进行一定的重新格式化，将其转化成为内部可接受
的与有用的形式。
导致外部数据难以获得的第三个因素是其不可预测性。外部数据可能在几乎任何时侯来
源于任何实际的数据源。外部数据本身可用性的不可预测性使得很难一致地与完全地获得所
需要的外部数据。
除了来自于期刊上的文章和咨询报告之外，外部数据的另一种来源是现在能够自动操作
的整个数据类，即非结构化数据，如图8 -4所示。
非结构化数据
图像
声音
数据仓库
图8-4 能够存储在数据仓库中的非结构化数据的一些形式
158 数据仓库
下载
非结构化数据的两种最常见的类型是图像和声音。图像数据是以图片形式存储的数据，
声音数据是数字存储的数据并能转换为一种声音格式。图像数据和声音数据的问题主要是技
术上的，获取并处理图像和声音数据的技术并不象传统技术那么成熟。另外，即使能够获取
图像和声音数据，存储它们也需要大量的 DASD设备，并且它们的查找、显示或回放都可能是
不方便的和缓慢的。
无论如何，非结构化信息的获取及其在数据仓库中的存储都还是有许多可能性的。
8.2 元数据和外部数据
在任何方案中，元数据都是数据仓库的一种重要组成部分。但是，当面对存储和管理外
部数据与非结构化数据时，元数据的作用呈现出完全不同的一面。图8 - 5表示了元数据的作
用。
非结构化数据外部数据
元数据:
• 文件标识符（ ID）
• 进入日期
• 描述
• 来源
• 分类
元数据 • 索引字
• 清理日期
• 物理地址引用
数据仓库 • 长度
• 相关引用
图8-5 对外部数据/非结构化数据，元数据起着新的作用
元数据是很重要的，因为在数据仓库环境中正是通过元数据来对外部数据进行注册、访
问与控制的。在数据仓库中对于外部数据来说，元数据的典型内容就是元数据重要性的最好
解释，例如：
■ 文件标识符（ID）。
■ 进入数据仓库的日期。
■ 文件描述。
■ 文件来源。
■ 文件来源的日期。
■ 文件的分类。
■ 索引字。
■ 清理日期。
■ 物理地址引用。
■ 文件长度。
■ 相关参考。
正是通过元数据，管理者来判断许多有关外部数据的信息。在许多情况下，管理者甚至不看
下载
源文件，只看元数据。在清除不相关的或过时的文件中，浏览元数据可为管理者减少大量的工作。
就外部数据而言，适当地建立和维护元数据对于数据仓库的操作是完全必要的。
与元数据有关的另一种数据类型是通知数据。图8 - 6所示的通知数据仅仅是一个为系统的
用户创建的文件，它表明与用户有关的数据分类。当数据进入数据仓库和元数据时，要进行
检查来发现谁与该数据有关。一旦发现获得了与某人有关的数据，就发出通知，以便让他或
她将来知道已经获得了有关的外部数据。
非结构化
外部数据
数据
通知文件
元数据
数据仓库
图8-6 外部数据和元数据的另一个优点是能够创建专门通知文件
8.3 存储外部数据/非结构化数据
如果方便且费用允许的话，外部数据 /非结构化数据实际上可以存储在数据仓库中。但在
非结构化
外部数据
数据
元数据
数据仓库
磁带
缩微胶片
文件柜
图8-7 在任何情况下，外部数据/非结构化数据总是与元数据一起进行登记的，
但实际数据依据其大小和存取概率来决定是否存储在数据仓库中
160 数据仓库
下载
许多情况下，将所有的外部数据存储在数据仓库中是不可能的或者是不经济的。于是，在数
据仓库的元数据中，对外部数据 /非结构化数据进行登录，创建一个条目以说明什么地方能找
到外部数据本身，外部数据存储在任何一个方便的地方，如图8 - 7所示。外部数据可能存储在
文件柜中，缩微胶片、磁带上，等等。当然，如果需要的话，外部数据可以存储在数据仓库
中。
8.4 外部数据/非结构化数据的不同组成部分
外部数据 /非结构化数据的重要设计问题之一是其经常包括许多不同的组成部分，其中一
些组成部分比另外一些更有用。作为一个例子，考虑一个产品的完整生产历史记录。生产过
程的某些方面是很重要的，如从开始到最后装配的时间。另一个重要的生产度量是所有非装
配的原材料的总成本。但还有许多其他不重要的信息同样也与生产信息相关，例如生产的实
际日期、装运说明书、生产时的温度。
为了管理这些数据，有经验的 D S S分析员或工程师需要决定什么是最重要的数据部分。
然后将最重要的数据存储在一个联机的、容易访问的位置。这是一个存储和访问效率的问题。
其余不重要的细节不能丢弃，而是将其放在大容量的存储位置。这样，大量的非结构化数据
就能够有效地存储和管理。
8.5 建模与外部数据/非结构化数据
数据模型和外部数据的作用是什么？图8 - 8反映了这个问题。数据模型通常的作用是根
据设计塑造环境。但外部数据与非结构化数据是根本不可塑的。看起来好象数据模型和外
部数据之间的关系很小。能做的事最多不过是在涉及的关键词和关键字解释范围内，记录
数据模型和外部数据之间的区别。任何将数据模型用于数据的重大改造的企图都将是一个
错误。
非结构化数据外部数据
数据模型
数据仓库
图8-8 外部数据/非结构化数据与数据模型通常只有极少的相似，
而且数据模型对外部数据和非结构化数据的改造无能为力
下载
8.6 间接报告
不仅原始数据能放入数据仓库，而且当数据循环重复时，间接报告可以按时间根据细节
数据来产生。例如图8 -9所示的月底道・琼斯平均指数报告。
道・琼斯平均工业指数
一月二月三月四月五月六月七月八月九月十月十一月十二月一月二月三月
月底道・琼斯平
均工业指数
图8-9 根据每日或每月的信息创建一个总结报告
在图8- 9中，道・琼斯平均指数信息每天输入数据仓库环境。每天的信息是有用的，但更
感兴趣的是由此产生的长期趋势信息。月底，有关道・琼斯平均指数的信息记入一个“间接”
报告中，于是间接报告就成为数据仓库中外部数据存储的一部分。
8.7 外部数据归档
每一条信息（外部的或其他的）都有个有用的生命周期。一旦超出了这个生命周期，保
存这些信息就不经济了。管理外部数据的一个基本部分就是决定数据的使用生命周期。即使
确定了使用生命周期，仍然还有一个数据是否丢弃或归档的问题。通常，外部数据可能从数
据仓库移出并放在较便宜的存储设备。元数据对外部数据的引用应该更新以反映新的存储位
置，并且新的存储位置仍然保留在元数据存储单元中。访问元数据存储单元的费用是很低的，
因此一旦放在那里，最好留在那里。
8.8 内部数据与外部数据的比较
可以对外部数据做的最有用的事情是过一段时间将其与内部数据进行比较。这种比较可
162 数据仓库
下载
以使管理工作“以树看森林”。对非常即时性的个体的活动和趋势与非常普遍的活动和趋势进
行比较，能使高级管理人员获得在其他地方不能得到的见解。图8 -10给出这样的比较。
工业界销售
（十亿为单位）
企业销售
（百万为单位）
1990 1991 1992 1993 1994 1995 1996
图8-10 外部数据与内部数据比较可以是很明晰的
当进行外部数据和内部数据的比较时，假设比较是在一个公共键码上进行的。任何其他
的假设都会使外部数据和内部数据的比较丢失其有用性。不幸的是，在外部数据和内部数据
之间实际得到一个公共的键码基础是不容易的。
为了理解这种难度，我们来看两个例子。一个例子中所卖的商品是大的、昂贵的物品，
如汽车或电视机。为了进行有意义的比较，由实际销路卖出的商品需要进行度量。零售商的
实际售出是比较的基础。不幸的是，数据的外部数据源使用的键码结构与内部系统使用的键
码结构并不相同。要将外部数据源转换成内部数据源的键码结构，反之亦然。这种转换不是
件小事情。
现在来考虑体积大、成本低的商品的销售度量，例如可乐。公司的内部销售曲线反映了
可乐的销售，但外部销售数据将可乐的销售与其他饮料（如啤酒）的销售混在一起。将这两
种类型销售数据进行比较将导致错误的结论。为了进行有意义的比较，需要有一个外部销售
数据的“清理过程”以便只包含可乐。事实上，只要可能，将包括各种各样生产与销售的瓶
装可乐。不仅要将啤酒从外部销售数据中剔除出去，也要将非竞争的可乐类型剔除出去。
8.9 小结
数据仓库不仅仅能够拥有内部的、结构化的数据。还有许多与企业运营有关的来自企业
以外数据源的信息。
外部数据是捕获的，而元数据是存储在数据仓库中的数据。元数据为高级管理人员检索
信息服务。另外，只要有新的项目进入数据仓库，经常会提供一种“通知”服务。
外部数据/非结构化数据实际并不一定存储在数据仓库中。
下载
第9章迁移到体系结构设计环境
在当今现实环境中，若想仓促地实现任何一种体系结构，注定都是要失败的。这其中存
在许多风险，企业可能要等很长的时间才有可能得到回报，以及由于试图想以后不再做任何
变化，不想采用任何渐进式的途径，而是采用革命式途径所带来的不现实性。
有一点确实很不错的是，迁移到体系结构设计的数据仓库环境中的过程，是一个逐步的，
每次只需完成有限的可提交的迁移工作。实现得最为成功的体系结构设计环境，是那些以每
次一遍的方式建立的数据仓库环境。这样，建立数据仓库只需要最少的人力资源，对现存应
用环境造成的破坏也必定是最小的。对这种重复式的开发而言，开发规模和速度都很重要，
结果也必须能够快速交付。
本章中，将讨论一种普通的迁移方案和开发方法。这种方法在附录中也有详尽的阐
述。该迁移方案已经得到许多企业的成功应用，这决不是幻想飞翔。这个方法本身来源
于许多企业的实践经验。当然，每个企业各自的方法会有不同的变化和置换。但这种迁
移方案和方法在许多企业都已取得了很大的成功，这点非常有益于树立各方面开发者的
信心。
9.1 一种迁移方案
这种迁移方案的起点是一个数据模型。数据模型描述企业的信息需求。它指出一个企业
所需要的，而并不一定是企业当前所具有的东西。在建立这个模型时，并不考虑任何技术问
题。
数据模型可以在内部建立起来，或者可以在一个普通的数据模型的基础上建立起来。数
据模型(至少！)需要给出如下的内容：
■ 企业的主要主题。
■ 各个主要主题之间的各种关系。
■ 更全面地描述主要主题的键码组和属性组，包括：
• 这些主要主题的属性。
• 这些主要主题的键码。
• 键码和属性的重复组。
• 各个主要主题领域之间的连接器。
• 图表化关系。
在理论上，建立体系结构设计环境也可以不要数据模型。然而，实际上从来没人这样做。
若想不用数据模型就去建立体系结构设计环境，就像是没有地图的航行一样，或许能成功，
但非常容易出现麻烦和错误。这也就像一个从未离开过得克萨斯的人，手上没有地图，也没
人指路，却想要降落在纽约的拉瓜尔地亚机场，然后要开车到曼哈顿中区去一样。或许真能
到那里，但直觉告诉我们，有一张地图肯定会好得多。
图9-1表明，建立或者获得一个数据模型是迁移过程的起点。
164 数据仓库
下载
现存系统环境
数据模型
现存系统环境
数据模型
定义记录系统
表述数据模型的最好数据：
• 最实时
• 最精确
• 最完备
• 与外部数据源最近
• 最具有结构兼容性
图9-1 迁移到体系结构设计环境
有了数据模型以后，下一步工作就是定义记录系统，记录系统是由企业已有的现存系统
来定义的。通常，这些系统是很混乱的。
记录系统只不过是找出现存系统所具有的“最好的”数据。此时，数据模型作为决定什
么是最好数据的判定基准。换句话说，数据体系结构设计人员从数据模型开始，找到手中最
符合数据模型需求的数据。有时找到的结果也不是很完美。在有些情况下，现存的系统环境
中找不到数据来例证数据模型中的数据。而另外一些情况下，现存的系统环境中，有许多数
据源在不同的情形下为记录系统提供数据。
现存数据系统的哪些数据源“最好”是由如下的标准来决定的：
■ 现存系统环境中的数据哪些是最完备的？
下载
第9章迁移到体系结构设计环境 165
■ 现存系统环境中的哪些数据是最实时的？
■ 现存系统环境中的哪些数据是最准确的？
■ 现存系统环境中的哪些数据是与输入现存系统环境的数据源最近的？
■ 现存系统环境中的哪些数据最接近数据模型的数据结构？是按键码判断，还是按各个
属性或多个数据属性的组合判断？
使用上面给出的数据模型和衡量标准，分析人员就可定义出记录系统。
定义好记录系统以后，下一个步骤就是设计数据仓库，如图 9-2所示。
如果数据模型建立工作进行得很好的话，设计数据仓库的工作也必将很简单。只需要修
现存系统环境
设计数据仓库
现存系统环境
设计数据仓库
抽取
集成
改变数据的时基
压缩数据
高效扫描数据
图9-2 迁移到体系结构设计环境
166 数据仓库
下载
改数据模型的少数几个方面，就可以将数据模型变为一个数据仓库的设计。要做的工作主要
有以下这些：
■ 如果原先没有时间元素的话，时间元素必须加入到键码结构中。
■ 必须清除所有的纯操作型数据。
■ 需要将参照完整性关系转换成“人工关系”。
■ 将经常需要用到的导出数据加入到设计中。
■ 为了适合于以下各项要求，需要对数据的结构进行调整：
• 增加数据阵列。
• 增加数据冗余。
• 在合适的情况下进一步分离数据。
• 在合适的时候合并数据表。
■ 需要做数据的稳定性分析。
一旦要设计数据仓库，就必须按主题领域进行组织，典型的主题领域有：
■ 客户
■ 产品
■ 销售
■ 账目
■ 活动
■ 装运
在主题领域内，有许多独立的数据表，每个均以一个公用键码连接。
数据仓库设计好以后，下一步就是设计和建立操作型环境中的记录系统和数据仓库之间
的接口，这些接口能保证数据仓库的载入工作能有序地进行。
乍看起来，这些接口似乎仅仅是一个数据抽取过程。当然，数据抽取过程确实是在此进
行的，但是，在接口中还包括了许多其他工作：
■ 来自操作型、面向应用型环境的数据的集成。
■ 数据时基的变更。
■ 数据压缩。
■ 对现存系统环境的有效扫描。
其中的多数问题已经在本书的其他部分讨论过了。
有意思的是，建立一个数据仓库所需要的大多数开发资源都花费在这点上了。建立数据
仓库所需的 8 0 %的精力都花在此处并非不正常。在安排数据仓库的开发工作时，许多开发者
过高地估计了其他工作所需要的时间，而过低估计了设计和建立操作型环境与数据仓库环境
之间的接口所需的时间。
一旦设计并建立好了接口程序，下一步工作就是开始载入第一个主题领域，如图 9 - 3所
示。
此时，有很多原因使得只需要载入一部分数据仓库所需要的数据。很可能需要对数据做
必要的改变。只载入一小部分的数据也就意味着可以简单快速地完成那些需要进行的改变。
大规模地载入大量的数据会丧失数据仓库的灵活性。一旦最终用户有机会观察数据，并向数
据体系结构设计人员反馈情况，载入大量数据就可以安全进行了。
下载
现存系统环境
开始载入第一个主题区
现存系统环境
警告：如果你等着“清理”好现存系继续载入并鼓励数
统而不作出反馈的话，你将“永远” 据集市部门使用
无法建立一个数据仓库。
图9-3 迁移到体系结构化环境
载入和反馈过程会持续一段很长的时间(没有一定的限期)。另外，数据仓库中的数据在此
过程中也在不断地改变。
这时，必须提出一点警告：“如果你等着清理好的现存系统，你将永远无法建立一个数据
仓库。”现存系统的操作型环境下的问题和活动必须独立于数据仓库的环境下的问题和活动。
在这点上，一件值得做的事情是观察数据仓库中数据的刷新频率。通常，数据仓库中数据
的刷新频率不应低于每24小时一次。在装载数据的时候，确保数据起码有 24小时的时延，数据
仓库的开发者就能将数据仓库变为操作型环境的可能性减小到最小程度。数据仓库服务于企业
的D S S的需要，而不是日常业务运作的需求。许多操作型处理依赖于数据存取瞬间的准确性
(数据的当前值)。只有通过确保(至少)有 24小时的时延，数据仓库开发者才有最大的成功机会。
9.2 反馈循环
数据仓库开发成功的关键是数据体系结构设计者和DSS分析者之间的反馈循环,如图9-4所示。
168 数据仓库
下载
数据仓库
现存系统环境
DSS分析人员
数据体系结构设计人员
图9-4 DSS分析人员与数据体系结构设计人员之间的关键的反馈循环
图9 - 4表明，数据仓库是从现存系统载入而来的。 D S S分析人员将数据仓库作为分析的基
础。在发现新机会的过程中， D S S分析者将那些需求反过来传送给数据体系结构设计人员，
以便使他们再去做出适当的调整。
有关这种反馈循环，有几点观察结果对数据仓库环境的成功建立是至关重要的问题：
■ D S S分析人员一定要严格遵循“给我我所想要的东西，然后我能告诉你我真正需要的
东西”的工作模式。
■ 反馈循环的周期越短，越有可能成功。
■ 需要调整的数据量越大，反馈循环所需要的周期就越长。
9.3 策略方面的考虑
图9-5表明，图中所描述的各个活动的路径强调了企业的 DSS需求。
设计和建立数据仓库环境的目的是用于为企业的 DSS需求提供支持，但除 DSS外，企业也
有其他方面的需求。图 9-6表明，企业也有操作型需求。
如图9-6所示，其中的操作型环境处于一种混乱状态。操作型环境中有许多未集成的数据，
其中包含的数据和系统都已很老了，有很多补丁，已经无法再对它们进行维护了。原来确定
的操作型应用的需求，已经改变得让人几乎无法识别了，等等。
前面所讨论的迁移方案仅仅适用于 D S S部分，但是，在创建数据仓库的同时，有没有可
能去矫正一些或许多的操作型环境中的“混乱”呢？答案是在某种程度上有可能做一些比像
美化操作型环境更少的一些重建工作。
下载
数据模型
现存系统
DSS
数据集市部门
级或个人系统
记录系统
数据仓库接口程序
数据仓库
图9-5 需遵循的首要路径是DSS路径
有一个方法，它是数据仓库环境的迁移中的一个独立途径，就是以数据模型为指导，告
诉管理者需对操作型环境需做的重大调整。但业界以往的记录表明，这种方法并不让人感到
乐观。它所需的工作量、资源的数量以及在进行大量的重写和重建操作型数据和系统时对终
端用户造成的破坏，都使得管理层很少愿意花费如此多的投入和资源去支持这种努力。
一个更好的方法是将重建操作型系统的工作和被称为“变化动因”的因素协调起来进行
数据模型
现存系统
DSS
数据集市部门
级或个人系统
数据仓库
记录系统操作型环境
变化动因：
• 系统老化
• 技术老化
• 组织上的剧变
• 大幅改变了的需求
图9-6 要取得成功的话，数据体系结构设计人员应该等待，直到各个变化动因变
得迫切以后，将与体系结构设计环境有关工作与合适的动因结合起来
170 数据仓库
下载
考虑，这些变化动因有：
■ 系统的老化。
■ 技术的剧烈更新。
■ 组织上的剧变。
■ 巨大的商业变化。
面对这些由变化动因所造成的影响，管理层毫无疑问需要做出相应的变化。唯一的问题
是要多快和花费多少钱。数据体系结构设计人员得将变化动因与体系结构的概念结合起来，
并以此给管理层提供充分的理由，以实现操作型处理环境的重建。
数据体系结构设计人员采取的重建操作型环境的步骤如图 9 - 7所示，这是建立数据仓库的
一项独立的活动。
首先，创建一个差异列表，这个差异列表给出了操作型环境和数据模型所描述的环境之
间的差别评估。差异列表是一个简单的列表，没有很详细的描述。
下一步是影响分析。此时，对差异列表中的每一项会造成的影响都做出一个评估。有些
项造成的冲击可能很严重，而其他的一些项对企业的运作所造成的影响几乎可以忽略。
再下一步，需要做出资源估计，以确定满足修复该差异列表项所需的资源数量。
现存系统
数据模型
1. 差异列表：
该数据模型与现存系统不同之处
记录系统 2. 影响分析：
每一个差异项目是如何表明差别的
3. 资源估计：
修复差异项目需要多少费用
4. 给管理层的报告：
• 要修复什么
• 估计需要的资源
• 工序
• 破坏分析
图9-7 创建操作型环境清理方案的第一步
最后，将所有以上的这些做成一个报告，提交给信息系统管理层。由管理层决定哪些工
作需要进行，开展步伐如何，等等。
下载
9.4 方法和迁移
本书的附录中讨论了一个构造数据仓库的方法。实际上，该方法的范围相当大，因为其
中不仅包含如何建立数据仓库，而且也说明如何使用数据仓库。另外，其中也包含了开发操
作型环境的典型工作方法，这些方法形成了所谓“数据驱动”的方法学。
讨论的方法在几个方面与迁移路径有所不同。迁移路径动态地描述总体工作步骤。而此
方法讨论特定的工作步骤，从这些工作得到的可提交的数据以及这些工作的次序。但并没有
叙述数据仓库创建的循环往复的动态过程。换句话说，迁移方案从三个角度描述一个概要的
方案，而些方法则从一个角度描述一个详细的方案。两者结合在一起形成了一个完整的创建
数据仓库所需的工作的描述。
9.5 一种数据驱动的开发方法
对开发方法需求是很普遍的。要求研究人员给出一个方法，给开发者指引一条合适的道
路，指出需要做些什么、按照什么次序做、整个工作需要多长时间。虽然方法学概念本身很
有吸引力的，但业界的记录并不让人满意。对方法(数据仓库或其他)的热情与对应用的失望交
织在一起。对方法学的历史记录表明，从方法学到应用实现是一条很不平坦的路。
为什么这些方法让人失望呢？其中有很多的原因：
■ 这些方法通常给出一个单调的、线性的工作流。实际上，几乎任何方法都需要循环重
复执行。换句话说，执行二三步以后、停止、再全部或部分重复前面的步骤，都是很
正常的。通常，这些方法本身没表明或没有考虑到它们本身需要重复进行一个或多个
步骤。对于数据仓库而言，这种不支持重复工作的缺点会使得这种方法成为一个大问
题。
■ 通常，这些方法给出了一些出现或仅出现一次的工作。确实，有些工作只需做一次(当
然得成功)就行了。然而，其他的一些工作在不同的情况下需要重复地做多遍(在这里指
的情况不同于求精的重复过程那种情况)。
■ 通常，这些方法规定好了一组需要做的工作。在许多情况下，其中有些根本就用不着
做，而有些需要做的工作却没有在方法中列出来，如此等等。
■ 这些方法经常说该如何做些工作，而不是说需要做什么。在描述如何做些什么的时候，
这些方法在碰到细节和特殊情况时，其有效性就成问题了。
■ 这些方法对要开发的系统的规模不加区分。有些系统很小，严格的方法在此时就没什
么意义；有些系统或许正好与某个方法相适应；而有些系统非常大，它们的规模和复
杂性会使方法根本就不起作用。
■ 这些方法经常将项目管理问题与需要做的设计和开发工作混在一起。通常情况下，项
目管理问题应该与开发方法相关问题分开。
■ 这些方法经常对操作型处理和 DSS处理不加区分。操作型处理和 DSS处理的系统开发生
命周期在许多方面是正好相反的。要取得成功，一个方法必须区分操作型和 D S S的处
理和开发。
■ 出现失败的情况下，这些方法一般都没有检查点和停止处。“如果前面一个步骤没有正
确执行的话，下一步该怎么办呢？”，方法中通常不把处理此类问题作为一部分。
172 数据仓库
下载
■ 这些方法常常是作为解决方案，而不是作为工具出售。当这些方法被当作解决方案来
出售时，不可避免地，一些其他的很好的判断和常识就可能会被这种方法所替代，而
这经常是错误的。
■ 这些方法总是提交出非常多的论文，却鲜有设计工作。设计和开发工作的地位被论文
不合理地取代了。
■ 这些方法可能很复杂，预计到了或许曾经发生过的或可能会发生的各种可能性。
尽管有这些缺点，对通用方法的需求仍然存在。附录中将会讨论一个适用于数据驱动环
境的通用方法，该方法充分考虑到了这些方法的缺陷和以往的记录。以概要方式给出的这种
数据驱动方法，很大程度上要归功于一些研究这种方法的先驱者。为此，想要得到对方法中
所讨论的复杂性和技术更充分的阐述的话，请参考书后所列出的参考文献。
数据驱动方法有一个突出的方面，就是它是建立在前面进行的工作的基础之上，也就是
建立在原先已开发的代码和处理的基础之上。基于原有工作之上的开发要获得成功，唯一的
途径就是要找出共同性。在开发者输入第一行代码或设计第一个数据库之前，他们应该知道
什么东西现在已经有了，它们对开发过程的影响如何。在使用已经存在的东西的时候，必须
保持清醒的头脑，而不要做重复工作。这就是基于数据驱动的开发的实质。
9.6 数据驱动的方法
为什么一种方法叫做数据驱动的方法呢？数据驱动的方法与任何其他方法有什么区别？
数据驱动的方法起码有如下两个显著的特点：
■ 数据驱动的方法不是按照一个应用接一个应用的方法去开发系统的。相反地，原先已
建立好的代码和数据被作为新代码和数据的基础，而不是新老并立。要建立在原先的
成果之上，就必须找出数据和处理的共同性。一旦找出共同性，已有的数据就可以作
为基础，若不存在任何数据，则需建立新的数据，而这些新建立的数据或许又可以作
为以后应用的基础。找出共同性的关键就是数据模型。
■ 必须强调的是，数据应集中存放，形成数据仓库，作为 DSS处理的基础，要认识到 DSS
处理与操作型环境相比，有一个大不相同的开发生命周期。
9.7 系统开发生命周期
操作型和 D S S系统的开发生命周期之间的深刻区别，从根本上体现了数据驱动开发方法
的特点。操作型系统的开发生命周期特点是，它开始于需求，结束于代码；而 D S S处理的开
发生命周期的特点，则是开始于数据，而结束于需求。
9.8 一个哲学上的考虑
在某些方面，有关方法的最好的一个例子是男女童子军的荣誉徽章体制。该荣誉徽章体
制用来衡量队员们什么时候应该晋升一个等级。该体制既应用于住在乡村也用于住在城市的
男孩和女孩，不管是喜欢体育的还是好学习的，也不管地域如何。简言之，荣誉徽章体制是
一种统一的、用于衡量成就的、经受了时间考验的方法。
荣誉徽章方法有什么秘密可言吗？如果有，那就是：荣誉徽章方法并不给你规定任何一
样工作该如何完成，相反，它只是仅仅说明该做些什么东西，以及给出一些衡量成就的不同
下载
参数。“该怎么做”这个问题则留给了男女童子军们自己。
在哲学上，本书附录所给出的方法采用了与荣誉徽章体制相同的观点。一般地说，其中
描述了需要达到的各个目标，以及各个工作的次序。该如何得到所需结果，则完全留给了开
发者。
9.9 操作型开发/DSS开发
数据驱动方法将分三个部分给出：方法 1、方法 2和方法 3。方法的第一部分即方法 1是用

于操作型系统和处理的，习惯于传统的结构化的操作型方法的人对这部分的方法或许很熟悉。
方法2是用于 D S S系统和处理的，也就是数据仓库的，这部分方法的本质在于将数据模型作为
媒介物，以它为中心找出数据的共同性。正是在附录的这部分描述了数据仓库的开发方法。
方法的第三部分即方法 3描述开发过程中的启发式部件中会出现什么，其中还说明数据仓库的
用法。
这三部分构成了数据驱动开发方法。
9.10 小结
本章探讨了一种迁移方案和一种方法(见附录)。该迁移方案讨论了将数据从现存系统环境
中转移到数据仓库环境的相关问题。另外，也讨论了操作型环境该如何组织的问题。
本章还讨论了一个通用的数据驱动的方法，该通用方法有三个阶段：操作型阶段、数据
仓库构造阶段和数据仓库重复使用阶段。
下载
第10章数据仓库的设计复查要目
在操作型环境中确保质量的最有效的方法之一是设计复查。通过设计复查可以检测到各
种错误，并在编码之前更正这些错误。在开发生命周期的早期费点功夫找到错误，能得到很
大的好处。
在操作型环境中，设计复查通常是在一个应用的物理设计完成以后进行的。操作型设计
复查所围绕的中心问题的类型有以下这些：
■ 事务处理性能。
■ 批窗口是否适当。
■ 系统可用性。
■ 容量。
■ 项目准备的充分性。
■ 用户需要的满足程度。
如果在操作型环境中我们正确地进行了设计复查，就可以节约可观的资源，并且大大增
加用户对系统的满意度。更重要的是，当设计复查正确地实施以后，一旦开始系统的编写，
系统的主要代码就用不着推倒重写了。
与在操作型环境中一样，设计复查在数据仓库环境中也是适用的，并有几个附带条
件。
一个附带条件是系统是在数据仓库环境中以循环重复的方式开发起来的，在这种开发方
式下，需求表现为开发过程的一个部分。典型的操作型环境是在严格定义的 S D L C (系统开发
生命周期 )下建立的，而数据仓库环境下的系统并不是按 S D L C建立的。操作型环境和数据仓
库环境下的开发过程的其他区别如下：
■ 操作型环境中的开发是按一次一个应用问题进行的，数据仓库环境下的系统是按一次
一个主题领域进行的。
■ 在操作型环境中，有一套稳定的需求，构成操作型环境下设计和开发的基础。而数据
仓库环境下，在 DSS开发的开端，人们对处理需求很少有一个稳定的认识。
■ 在操作型环境中，事务响应时间是主要的而且是极其重要的问题。而在数据仓库环境
中，事务响应时间基本上不算是个问题。
■ 在操作型环境中，来自不同系统的输入通常来自企业的外部数据源，最常见的是通过
与外部代理的交互获取数据。在数据仓库环境中，数据通常来自企业内部的各个系统，
而各个系统的数据是由很多种类的现有数据源集成而来的。
■ 在操作型环境中，数据几乎都是当前值 (也就是说，数据在用的那一刻是准确的 )。而在
数据仓库环境中，数据是随时间变化的 (也就是说，数据与某个时刻相关 )。
这样，在操作型环境和数据仓库环境之间就存在一些根本的区别，这些区别在进行设计
复查的过程中就可以体现出来。
下载
第10章数据仓库的设计复查要目 175
10.1 进行设计复查所涉及的问题
在数据仓库环境中，一旦一个主要的主题领域设计好以后，并准备加入到数据仓库环境
中时，就应开始做设计复查。但并不是每建一个新的数据库就需要做设计复查，相反，当整
个新的主题领域加入数据库中时，就有必要进行设计复查。
10.1.1 谁负责设计复查
设计复查时的参加者包括那些与所复查的 D S S主题领域有关的开发人员、操作人员或使
用人员。
通常情况下，包括如下人员：
■ 数据管理人员(DA)
■ 数据库管理员(DBA)
■ 程序员
■ DSS分析人员
■ 除DSS分析人员外的最终用户
■ 操作人员
■ 系统支持人员
■ 管理人员
在这组人员中，最重要的参与者是最终用户和 DSS分析人员。
在同一房间与同一时间，有所有这些不同人员聚在一起，这有一个显著的好处，那就是
有机会加强沟通，消除不同认识。在日常环境中，最终用户将问题告诉联络者，联络者转达
给设计者，设计者又通知程序员，在此过程中很有可能造成误传和误解。而当所有这些不同
类别的人员聚在一块时，就有了直接交流的机会，这对一个正在被复查的系统是非常有益的。
10.1.2 有哪些议事日程
对数据仓库环境进行复查的主题可以是任何可能会导致失败的设计、开发、项目管理或
者应用问题。简言之，任何有碍成功的障碍在设计复查过程中都会涉及到。通常，一个主题
越有争议，在复查期间就应更加重视它。
复查过程的基本问题将在本章后面部分中讨论。
10.1.3 结果
数据仓库设计复查能产生三种结果：
■ 对问题管理的评价和对进一步行动的建议。
■ 有关系统在设计中的位置以及复查时间的文档。
■ 一个“行动要目”表，阐明作为复查过程的结果的特定目标和行动。
10.1.4 复查管理
复查过程由两个人领导，一个督导人和一个记录员，督导人绝对不能是要复查的项目的
管理者或开发者。在有些情况下，若督导人是项目领导，从许多角度而言，复查的目标都有
176 数据仓库
下载
可能会失败。
要进行一个成功的复查，督导人不能参与项目，这点必须强制执行，这有以下的理由：
■ 作为一个局外人，督导人会用新的眼光，从外部角度观察系统。这种新鲜的眼光经常
能揭示出那些与系统的设计和开发很接近的人所不能发现的重要的见识。
■ 作为一个局外人，督导人能建设性地提出批评。与开发工作很密切的人员给出的批评
往往具有个人观点，并可能使设计复查局限于一个非常低的水平之上。
10.1.5 典型的数据仓库设计复查
1. 复查过程中遗漏了谁？是不是有应该参加的小组被遗漏了？以下这些小组成员出席了
吗？
■ DA。
■ DBA。
■ 编程人员。
■ DSS分析员。
■ 最终用户。
■ 操作人员。
■ 系统编程人员。
■ 审计人员。
■ 管理人员。
各小组的正式代表是谁？
解答：不管其他任何因素，合适的人员合适地参加了设计复查对于复查的成功是至关重
要的。最重要的参加者是 D S S分析员或最终用户，管理人员或许参加或许不参加，随他们自
己。
2. 最终用户需求都已完全预见到了吗？如果是，达到了什么程度？设计复查中最终用户
代表是否同意已做好的有关需求的表述？
解答：从理论上讲， D S S环境可以在无需与最终用户交互的情况建立起来，也就是无需
对最终用户的需求做出什么预测。然而，如果需要修改数据仓库环境中数据的粒度，或者在
数据仓库的顶层，需要建立EIS或人工智能处理过程，那么对需求做一些预见是很有益的尝试。
通常，甚至在预测了 D S S需求时，最终用户的参与程度是非常低的，最终结果也是非常粗略
的。进而，不应该花费大量的时间去预测用户的需求。
3. 数据仓库环境中的数据仓库的多少内容已经建立好了？
■ 哪些主题？
■ 有哪些细节？哪些综合？
■ 按字节算、按行算、按磁道 /柱面算有多少数据？
■ 有多少处理量？
■ 独立于被复查项目，有哪些增长模式？
解答：数据仓库环境的当前状态对被复查的开发项目有很大的影响。刚开始的开发工作
应在有限的范围内进行，并且应在边试边改的基础上开展。在这个阶段，不应有很关键的处
理或数据。另外，应该预计到一定量的快速反馈和重复开发。
下载
此后的数据仓库开发工作出错的机会就会少些。
4. 已经从数据模型中找出了多少主要主题？有多少是正在实现的？有多少是已全面实现
的？有多少是由正在被复查的项目来实现的？有多少是能在不远的将来得到实现的？
解答：通常，数据仓库环境一次只实现一个主题，开始少数几个主题应该被当作实验一
样。到了后来，早期开发工作中所学到的教训，就能在主题的实现中应用。
5. 数据仓库环境之外是否存在重要的 DSS处理(也就是数据仓库 )？如果存在的话，有没有
可能产生重复或冲突？对数据仓库环境外的 D S S数据和处理的迁移方案是什么？对于将不可
避免地要出现的迁移，最终用户能理解吗？在什么时间范围内做迁移工作？
解答：在正常情况下，在数据仓库环境中，只有部分数据仓库，而其他部分的数据在数
据仓库环境之外的话，这将是一个重大的错误。只有在一些最例外情况下，才允许存在一个
“分裂”方案(其中的情况之一是分布式数据仓库环境 )。
如果数据仓库环境确实有部分实际上处于数据仓库环境之外，就应该有种方案将 D S S体
系中的那部分搬回到数据仓库环境中。
6. 已经找出的主要主题是否都已经划分到更低的细节级？
■ 各个键码是否已标识？
■ 各个属性是否已经标识？
■ 键码和属性是否已组合起来？
■ 不同数据分组之间的关系是否已经标识？
■ 每一组的时间变化是否已经标识？
解答：需要有一个数据模型作为数据仓库的智能中心。这种数据模型在正常情况下有三
个层次：一个标识实体和关系的高层模型；一个标识键码、属性和关系的中层模型；以及一
个可以在此进行数据库设计的低层模型。然而，在开始建立 D S S环境时，并不是所有的数据
都需要模型化到最低层，但至少高层模型应该建好。
7. 问题6中所讨论的设计是否要周期性地复查？ (多长时间一次？非正式地还是正式地？ )
作为复查的结果，会出现什么变化？最终用户的反馈如何传递给开发者的？
解答：经常需要修改数据模型以反映企业的业务变化。通常情况下，这些变化具有逐渐
增长的特点，革命式的变化是不常见的。这种变化对已有数据仓库数据和计划中的数据仓库
数据所造成的影响应该做出评估。
8. 是否已确定操作型环境的记录系统？
■ 每一个属性的数据源确定没有？
■ 是否已经确定某一个或另外一个属性会成为数据源的条件？
■ 如果某一个属性没有数据源，是否确定了它的默认值？
■ 数据仓库环境中那些数据属性的属性值的公用度量确定没有？
■ 数据仓库环境中那些数据属性的共同的编码结构确定没有？
■ 数据仓库环境中的公共键码结构确定没有？记录系统的键码在哪些地方不符合 D S S的
键码结构的条件？确定转换途径没有？
解答：数据模型建立好以后，记录系统就定好了。记录系统通常存在于操作型环境中，
记录系统代表了支持数据模型的现存数据中最好的数据源。集成问题在定义记录系统时是一
个非常重要的因素。
178 数据仓库
下载
9. 从操作型记录系统中抽取数据到数据仓库环境的过程的频率确定没有？当前抽取过程
如何从上次的抽取过程中识别出操作型数据的变化？
■ 通过查看时戳数据？
■ 通过改变操作型应用代码？
■ 通过查看日志文件？或是某个审计文件？
■ 通过查看某个差异文件？
■ 通过比较“前”映像和“后”映像？
解答：抽取过程的频率之所为成为一个问题，是因为刷新中所需要的资源、刷新过程的
复杂性、以及数据及时刷新的需要等原因造成的。数据仓库的可用性常常与数据仓库是以什
么频率刷新的有关。
从技术角度而言，最复杂的问题之一是在抽取过程判定应该扫描哪些数据。在有些情况
下，需要从一个环境中传到下一个环境中的操作型数据是相当明确的。在另外一些情况下，
根本就无法知道应该对哪些数据进行检查，并将其作为载入数据仓库环境的候选数据。
10. DSS环境中通常包含多少数据量？如果数据量很大的话，那么
■ 是否应指定多重粒度级？
■ 是否应该对数据进行压缩？
■ 是否应进行定期数据清理？
解答：除了抽取过程所处理的大量数据外，设计者自己需要考虑数据仓库环境中实际的
数据量。对数据仓库环境中数据量的分析，直接地导致数据仓库环境中数据的粒度问题，并
可能会导致多重粒度级的出现。
11. 在执行抽取过程以创建数据仓库环境的时候，哪些数据将被滤出操作型环境？
解答：所有的操作型数据都传送到 D S S环境中是很少见的。几乎每一操作型环境都包含
有只与操作型环境相关的数据。这些数据不应该进入到数据仓库环境中去。
12. 采用什么软件来给数据仓库环境提供数据？
■ 这种软件已被彻底卸出了吗？
■ 存在或可能会存在什么瓶颈？
■ 接口是单向的还是双向的？
■ 需要什么技术支持？
■ 该软件能传送多大容量的数据？
■ 需要对软件做什么样的监控？
■ 对软件需要周期性地做什么变更？
■ 这种变更会伴有什么中断？
■ 安装这种软件需要多少时间？
■ 谁负责这种软件？
■ 这种软件何时能充分投入使用？
解答：数据仓库环境能够处理大量的不同类型的软件接口。然而，不应低估中断时间和
基础构造所需时间量。 D S S体系结构设计者不能想当然地认为，将数据仓库环境与其他环境
连接起来必定是直截了当的与容易的。
13. 在数据仓库环境外对 DSS部门的和个体的处理传送数据需要什么软件 /接口？
下载
■ 是否已经彻底地测试接口？
■ 可能存在什么瓶颈？
■ 接口是单向的还是双向的？
■ 需要什么技术支持？
■ 经过接口的预期数据流量是多大？
■ 接口需要什么样的监控？
■ 将对接口做哪些变更？
■ 对接口做变更后可能会产生什么中断？
■ 安装接口需要多长时间？
■ 谁负责这个接口？
■ 接口什么时候才能投入全面的应用？
14. 在数据仓库环境中将使用什么样的数据物理组织？数据能直接存取吗？能进行顺序存
取？能简单且廉价地创建索引吗？
解答：设计者应该复查数据仓库环境的物理配置以确保足够的可用空间，并保证一旦数
据到了这种环境中，就能以一种应答的方式去操纵它。
15. 数据仓库环境建好以后，往其中增加更多的存储空间容易不容易？在数据仓库环境中
重新组织数据难不难？
解答：所有数据仓库都不是静态的，没有数据仓库能在设计的初始阶段就能完全地进行
规格说明。在数据仓库环境的整个生命期，做一些设计上的修改是完全正常的。建立一个数
据仓库环境时，如果在中间过程要么不能做任何修改，要么很难进行一些修改，则这个设计
必定是一个失败的设计。
16. 数据仓库环境中的数据需要经常重新组织 (就是说增加、减少或扩大列，或修改键码
等)的可能性有多大？这些重新组织工作对数据仓库正在进行的处理有什么影响？
解答：给定数据仓库环境中所能找到的大量数据，重新组织这些数据并不是件容易的事。
另外，有了存档数据后，过了一定时间以后重新组织数据在逻辑上几乎是不可能的了。
17. 期望的数据仓库环境的性能水平如何？是否正式或非正式地拟定了 D S S服务级的协
议？
解答：除非正式拟定了一个 D S S服务级协议，否则不可能度量出性能指标是否已经达到
要求。这个DSS服务级协议应该涵盖 DSS性能水平及停机时间。典型的 DSS服务级协议会阐明
以下内容：
■ 每个数据单元在高峰时刻的平均性能。
■ 每个数据单元在非高峰时刻的平均性能。
■ 每个数据单元在高峰时刻的最坏性能。
■ 每个数据单元在非高峰时刻的最坏性能。
■ 系统可用性标准。
D S S环境的一个难题是性能度量，不像操作型环境，可以用绝对标准来度量它的性能，
DSS处理性能度量与下列内容有关：
■ 单个请求代表多少处理。
■ 当前正在并发进行的处理有多少。
180 数据仓库
下载
■ 在执行时刻有多少用户在系统中。
18. 期望的可用性水平有多高？是否已对数据仓库环境正式或非正式地拟定了可用性协
议。
解答：(见问题17的解答。)
19. 数据仓库环境中的数据是如何索引或存取的？
■ 任何表是否会有超过四个的索引？
■ 任何表是不是会被哈希存储？
■ 任何表是否仅有主键索引？
■ 为了维护索引需要些什么开销？
■ 为了最初装入索引需要什么开销？
■ 索引的使用频率如何？
■ 为了服务于更广泛的应用，索引是否能或是否应该被改变？
解答：数据仓库环境中的数据要求能被高效而灵活地存取。不幸的是，数据仓库处理所
具有的启发式特性使得对索引的需求具有不可预测性。造成的结果是，我们不能想当然地去
存取数据仓库环境中数据。通常，采用多层方法去管理对数据仓库的数据的存取是最理想的：
■ 哈希键或主键应该满足多数存取。
■ 二级索引应满足其他大多数存取模式。
■ 临时索引应该满足不常见的存取。
■ 对数据仓库数据的一个子集的抽取和顺序索引，应该满足不频繁或者生命期内只出现
一次的数据存取操作。
在任何情况下，数据仓库环境中的数据不应该按太大的分区存放，以免使它们无法自由
地进行索引。
20. 预期的数据仓库环境中处理量的大小如何？高峰期如何？日平均量的情况如何呢？峰
值处理率又是如何？
解答：不但需要预计数据仓库环境中的数据量，而且也应该预计到数据处理量。
21. 数据仓库环境中的数据应有怎么样的粒度级？
■ 高粒度级？
■ 低粒度级？
■ 多重粒度级？
■ 要不要做滚动式持续汇总？
■ 是否有真实档案级的数据？
■ 是否有真实样本级的数据？
解答：显然，在数据仓库环境中，最重要的设计问题是数据的粒度和采用多重粒度级的
可能性。简言之，如果数据仓库环境的粒度级已经正确地取好了，那么所有其他问题就变得
简单明了了；如果数据仓库环境中的粒度级没有正确地设计好，那么所有其他问题将会变得
复杂而沉重。
22. 数据仓库环境中有什么数据清除标准？数据是真的被清除，还是压缩好放到其他地
方？有什么法定需求？有什么核查要求？
解答：即使 D S S环境中的数据是存好档的，而且必然地具有很低的存取可能性，这些数
下载
据还是具有某种存取可能性 (否则它就不应被存储 )。当存取的可能性减低到 0 (或接近0 )时，数
据就应该被清除了。如果数据量是数据仓库环境中一个极严重的问题的话，将不再有用的数
据清除出去就成为数据仓库环境的比较重要的方面之一。
23. 为满足以下两项需要，各自需要的总数据处理能力是多少？
■ 为了最初实现？
■ 为了成熟时期的数据仓库环境？
解答：假设无法将所需要的能力需求规划到最后一位，对需要的能力至少估计一下也是
有益的，以免造成实际需要和可用能力之间的不匹配。
24. 在数据仓库环境中，能够识别出主题领域之间的哪些关系？这些关系的实现：
■ 能不能使外键码得到不断的刷新？
■ 能不能利用人工关系？
建立和维护数据仓库环境中的关系时需要哪些开销？
解答：数据仓库设计者要做的最重要的设计决策之一，就是该如何实现数据仓库环境中
的数据之间的关系。在数据仓库中，数据关系几乎不可能以与数据原来在操作型环境中的关
系相同的方式来实现。
25. 数据仓库环境内部的各个数据结构是否利用了以下各项技术：
■ 数据阵列？
■ 选择性的数据冗余？
■ 数据表的合并？
■ 导出数据的通用单元的创建？
解答：尽管在数据仓库环境中操作型性能并不算是个什么问题，但性能仍然毕竟还算是
一个问题。如果前面所列的这些设计技术能够减少 I O总量，设计者就应考虑采用这些技术。
这些技术是典型的物理反正规化技术。因为在数据仓库环境中并不修改数据，所以，对于哪
些事能做，哪些事不能做，并没有什么限制。
决定该采用哪些技术的因素包括如下几条：
■ 数据出现的可预测性。
■ 数据存取模式的可预测性。
■ 收集数据人工关系的必要性。
26. 数据仓库中的数据恢复需要多长时间？执行一次完整的数据仓库数据库恢复工作的操
作准备好没有？是部分性地恢复？这些操作会不会周期性地执行恢复工作，以使它们在需要
恢复时就已经准备好了？准备的程度是在下面的哪一级体现的：
■ 系统支持？
■ 应用编程？
■ DBA？
■ DA？
对于每类可能出现的问题，问题由谁负责是否已经明确？
解答：就像在操作型系统中一样，设计者必须为在恢复期间出现的中断做好准备工作。
恢复的频率、对系统进行备份所需的时间、以及在中断期间可能会产生的多米诺骨牌效应，
都需要认真加以考虑。
182 数据仓库
下载
使用说明书是否已经准备、测试和编写好？这些使用说明书是否得到经常的更新？
27. 在什么级别对重新组织 /重新构造进行准备：
■ 各种操作？
■ 系统支持？
■ 应用编程？
■ DBA？
■ DA？
是否编写了说明书和建立了过程，并做了测试？是及时更新的吗？它们能一直得到及时
更新吗？
28. 在什么级别对数据库表的装载进行准备：
■ 各种操作？
■ 系统支持？
■ 应用编程？
■ DBA？
■ DA？
是否编写了说明书和建立了过程，并做了测试？是及时更新的吗？它们能一直得到及时
更新吗？
解答：装载所需的时间和资源可能是相当大的，应该谨慎地做这个估计，这个估计需要
在开发生命周期的早期进行。
29. 在什么级别对数据库索引装载进行准备：
■ 各种操作？
■ 系统支持？
■ 应用编程？
■ DBA？
■ DA？
30. 如果对数据仓库环境中的某项数据的精确性产生过争议的话，该如何解决这种争议？
数据仓库环境中的每个数据单元的所有权 (或至少数据出处 )定好没有？如果有需要的话，能不
能建立数据的所有权？谁负责处理所有权问题？有关所有权问题，谁拥有最终的决定权？
解答：在数据仓库环境中，数据的所有权或管理权是数据仓库环境成功与否的基本因素。
有时数据库的内容不可避免地会出现问题。对这种可能性，设计者应该提前计划好。
31. 一旦数据放到数据仓库环境后，该如何修改数据？修改的频率如何？应该对修改进行
监控吗？如果存在一种定期出现修改的模式，在数据源层次上 (也就是操作环境下 )的修改该如
何进行？
解答：有时偶尔地或不定期地，需对数据仓库环境下的数据做一些修改。如果这些修改
具有一定的模式，那么 DSS分析人员就需要调查一下操作型系统中是否存在什么问题。
32. 公共汇总数据是否要与正常的原始 D S S数据分开存放？有多少公共汇总数据？是否应
该存储用于创建公共汇总数据所需要的算法？
下载
解答：即使数据仓库环境包含原始数据，在数据仓库环境中存在公共汇总数据也是很正
常的。设计者应该准备一些逻辑空间来存放这些数据。
33. 需对数据仓库环境中的数据库采用哪些安全措施？如何实施安全措施？
解答：数据访问成为一个问题，特别是在形势很明显地表明细节数据变成汇总数据或聚
集数据时。设计者应该预计到安全需求，并为之准备好数据仓库环境。
34. 有什么审查需求？怎样才能达到审查需求？
解答：通常，系统审计可以在数据仓库层做，但这几乎总是个错误。相反，在记录系统
层做细节记录的审查是最好的。
35. 是否采用数据压缩？是否考虑到压缩 /解压缩数据的开销？有什么开销？通过 DASD压
缩/解压缩数据能节省什么？
解答：一方面，对数据进行压缩或编码能节省大量的空间。而另一方面，数据压缩和编
码都需要 C P U时间，因为访问数据时需要解压缩或解码。设计者应该对这些问题做充分的研
究，并在设计中做一个审慎的折衷方案。
36. 需要对数据进行编码吗？考虑到编码 /解码的开销没有？实际上有哪些开销？
解答：(请参看问题 35的解答。)
37. 数据仓库环境中应该存储元数据吗 ?
解答：作为一条法则，元数据需要与任何档案数据一起存储。分析人员使用档案数据解
决问题的时候，如果他不知道他所分析的数据域的内容的含义时，绝对是很难办的。在将数
据存档时，把数据语义与其存放在一起，就可以缓解前面的问题。随着时间的过去，数据仓
库环境中的数据的内容和结构发生些变化是绝对正常的。设计者必须确保系统能始终跟踪随
着时间变化的数据定义。
38. 参照表是否应该存放在数据仓库环境中 ?
解答：(请参看问题 37的解答。)
39. 数据仓库环境中需要维护哪些目录 /字典？谁负责维护？如何保持更新？是为谁准备
的？
解答：不但随时跟踪数据定义是一个问题，而且跟踪数据仓库环境中的当前数据变化也
很重要。
40. 数据仓库环境中允许进行数据更新 (与装载和访问数据相反 )吗？(为什么？更新多少？
在什么情况下？是不是仅仅限于异常的情况下？ )
解答：在数据仓库环境下，在正常情况下如果任何更新操作都可以做的话，设计者就应
该探讨一下其中的原因了。唯一的一种会出现的更新，应该发生在出异常情况时，并且只能
对一小部分数据进行更新。除此以外的任何更新都会严重地危及数据仓库环境的功效。
在做更新的时候 (如果确实要做的话 )，它们应在一个专用窗口中执行，应该在系统中没有
其他处理，且在处理器有空闲时间的时候进行。
41. 从操作型环境中取数据到数据仓库环境时，有什么样的时间迟延？这个时间迟延会不
会少于 2 4个小时？如果会的话，为什么？在什么情况下会这样？数据从操作型环境传送到数
据仓库环境的过程是一个“推送”过程还是一个“拖拉”过程？
解答：从策略上讲，任何少于 2 4小时的时延都是有疑问的。通常，如果需要有少于 2 4小
时的时延，就表明开发者在将操作型需求构建到数据仓库中。流向数据仓库的数据流应该总
184 数据仓库
下载
是一个拖拉过程，也就是说数据只是在需要的时候被拖拉进数据仓库，而不是在系统可用的
时候推送到数据仓库环境中。
42. 应该做哪些有关数据仓库的活动日志？谁将会访问这些日志？
解答：大部分 D S S处理不需要日志。如果需要做大量的日志，通常情况下表明人们对当
前数据仓库环境中正在发生的处理的类型缺乏足够的理解。
43. 除了公共汇总数据以外，还有其他的数据从部门层或个体层流向数据仓库环境中吗？
如果有，就描述这些数据。
解答：只有在很少的情况下，公共汇总数据来自于其他数据源，而不是来自部门层或个
体层处理。如果有许多公共汇总数据是来自于其他数据源的话，则分析者就应该找一下原因
了。
44. 有什么样的外部数据 (即不是由一个企业内部的数据源和系统产生的数据 )进入数据仓
库环境？这些数据要不要加上特别标记？它们的数据源要与数据存储在一起吗？这些外部数
据进入系统的频率如何？有多少外部数据进入？是否需要非结构化的格式？如果发现外部数
据不准确会出现什么情况？
解答：除了公司的操作型系统外，即使是允许一些外部数据源合理地存在，但当有许多
数据从外部进入时，分析人员就应该找一下原因。在外部数据的内容和可用性规则方面，它
所能具有的灵活性都不可避免地要少得多，虽然外部数据也是一个不可忽视的重要的数据源。
45. 存在什么样的环境工具能帮助部门和个体用户查找数据仓库环境中的数据？
解答：数据仓库的一个主要的特点就是易于数据存取。而数据的可存取性问题第一步就
是这些数据的初始位置。
46. 有人尝试将操作型处理和 DSS处理同时混在一台机器上吗？ (为什么？有多少处理？有
多少数据？ )
解答：出于许多方面的考虑，同时将操作型处理和 D S S处理混合在同一台机器上是没有
什么意义的。只有在数据量和处理量都很小的时候，才有可能进行混合。但这些条件不是使
数据仓库环境达到最大成本效益的条件。 (请参阅《 Data Architecture — The Information
Paradigm》一书， Wiley, 1992年出版，该书对此问题有更深的探讨。 )
47. 有多少数据会从数据仓库层流回到操作层？按照什么频率？数据量多大？对响应时间
有什么限制？回流的数据是汇总性数据还是单个数据单元？
解答：通常，数据从操作型处理流向仓库层处理，再流向部门层处理，再流向个体层处
理。但也有一些值得注意的例外情况，只要没有太多的数据回流，并且只要回流是以有序的
方式执行的，通常情况下就不会出现问题。然而，如果回流时所涉及的数据量很大，那么就
出示红牌了。
48. 会出现多少针对数据仓库环境的重复性处理？导出数据的预先计算和存储能节省处理
时间吗？
解答：对于数据仓库环境而言，具有一定量的重复性处理绝对是正常的。如果只有重复
性处理要做，或相反根本没有重复性处理要做，设计者就都应找一下原因。
49. 主要主题该如何划分？ (按年？按地域？按功能单元？按生产线？ )对数据的分割的精
细程度如何？
解答：对于数据仓库环境所固有的数据量以及数据的不可预测的用途，必须强制性地把
下载
数据仓库的数据在物理上分割为小单元，以便能对它们进行独立的管理。我们要面对的设计
问题不是是否应该进行分割，相反，问题是分割该如何完成。一般地说，分割是在应用层而
不是在系统层进行的。
对分割策略进行复查的时候，应注意以下问题：
■ 当前数据量。
■ 未来数据量。
■ 数据的当前用途。
■ 数据的未来用途。
■ 仓库中其他数据的分割。
■ 其他数据的用途。
■ 数据结构的易变性。
50. 要创建稀疏索引吗？它们有用吗？
解答：在合适的地方创建的稀疏索引能够节省大量的处理。同时，稀疏索引创建和维护
需要相当数量的开销。数据仓库环境的设计者应考虑好它们的使用。
51. 要创建什么样的临时索引？它们要保留多长时间？它们会有多大？
解答：(参看问题50的解答，它也适合于临时索引。 )
52. 部门层和个体层会有什么文档？有关数据仓库环境和部门环境之间的接口、部门环境
和个体环境之间的接口、数据仓库环境和个体环境之间的接口有些什么文档？
解答：在部门和个体环境下，它们的处理的特点是形式自由，也就不太可能会有太多的
可用文档。然而，有关各个环境之间的关系的文档对数据的一致性是很重要的。
53. 用户要为部门层处理、个体层处理付费吗？谁承担数据仓库处理的费用？
解答：有一点是很重要的，就是用户必须有自己的预算，并且必须为所使用的资源付费。
可以预见，处理如果变成免费的，肯定产生大量的对资源的滥用。收费系统能够在资源的使
用方面给用户灌输一种责任感。
54. 如果数据仓库环境必须是分布式的，仓库的公用部分确定没有？它们是如何管理的？
解答：在分布式数据仓库环境中，一些数据必然地会受到严密的控制。这些数据需要由
设计者标识出来而由元数据控制存放位置。
10.2 小结
设计复查是一个重要的质量保证环节，它可以大大地提高用户的满意程度，并减少开发
和维护费用。在建立数据仓库之前，彻底地对数据仓库环境的许多方面进行复查，是一种很
有效的实际工作。
下载
技术词汇
access (访问或存取 )— 在存储单元上查找、读或写数据的操作。
access method (访问方法或存取方法 )— 用于将物理记录从大容量存储设备传入或传出
的技术。
access pattern (访问模式或存取模式 )— 访问数据结构的一般序列(例如，从元组到元组，
从记录到记录，从段到段等等)。
accuracy (精确度)— 一种对避免误差的定性估计，或对误差大小的定量度量，表示为一
个相对误差的函数。
ad hoc processing (特别处理) — 仅执行一次，偶尔访问，并且用从未用过的参数操纵数
据，通常以启发式的迭代的方式进行。
after image (后映像)— 当完成一个事务后，放入日志的数据快照。
agent of change (变化动因)— 大得不能抗拒的驱动力，通常是系统的老化、技术的变化、
需求的根本改变等等。
algorithm (算法) — 组织好用以在有限步骤内解决问题的一系列语句。
analytical processing (分析型处理 ) — 使用计算机为管理决策提供分析，通常包括趋势分
析、向下探查分析、统计分析及概要分析等等。
application (应用)— 支持一个组织或企业需求的一组相互联系的算法和数据。
application database (应用数据库 )— 组织好用以支持一种特定应用的数据集合。
archival database (存档数据库 )— 包含具有历史特性的数据的数据集合。一般来说，存
档数据是不被更新的。每个存档数据单元都和一个过去的时间点有关。
artifact (人工关系)— 在DSS环境中用于表示参照完整性的一种设计技术。
atomic (原子)— (1)存储在数据仓库中的数据；( 2)处理分析的最低层次。
atomic database (原子数据库 )— 由原始的原子数据组成的数据库；一个数据仓库；一个
DSS基础数据库。
atomic-level data (原子层数据 )— 具有最低粒度级的数据。原子层数据存放在数据仓库
中并随时间变化(即精确到过去某一时刻)。
attribute (属性)— 可以对实体或关系取值的特性。实体可以被赋予多个属性(例如，一
个关系中的元组由多个值组成)。一些系统也同样容许关系具有属性。
audit trail (审计跟踪)— 可用于跟踪活动的数据，这些活动通常是更新活动。
backup (备份)— 作为数据库备份活动的基础的一个文件。通常是以前某一时刻的数据
库的快照。
batch (批处理 ) — 多个程序(通常是长时间运行的、面向顺序的)互斥地访问数据的计算
机运作方式，当活动正在进行时不容许用户干预。
batch environment (批处理环境 )— 一种顺序控制的处理模式；在批处理中，收集并存储
输入，而后进行处理。一旦收集好，批处理输入将顺序地对一个或多个数据库进行处理。
216 数据仓库
下载
before image (前映像)— 更新前的记录快照，通常放在活动日志中。
bitmap (位映射 )— 用于显示一组块或记录存在与否的特殊索引形式。建立和维护位映
射是非常昂贵的，但它能提供快速比较和访问的手段。
blocking (组块)— 合并两个或多个物理记录，使它们的物理位置在一起。物理位置相连
的结果是可以通过执行单个机器指令来访问和获取它们。
cache (高速缓存 )— 通常在设备级上建立和维护的缓冲区。从高速缓存中检索数据要比
从磁盘柱面检索快得多。
cardinality(of a relation) (关系的基数) — 在一个关系中元组(即行)的数目。
CASE — 计算机辅助软件工程( computer-aided software engineering)。
checkpoint (检查点)— 数据库的一个标识的快照，或使事务对数据库冻结或停顿的一个
点。
checkpoint/restart (检查点 /重启动 )— 在程序起始点以外的地方重新运行程序的一种方
法，例如，当发生故障或中断时。在整个应用程序运行中，可能会使用 N个检验点。在每一个
检查点要存储足够的信息，以便程序能够恢复到检查点设定时的状态。
“C L D S” — 以幽默方式对分析型的 D S S系统的系统开发生命周期的命名。我们之所以
这样命名是因为它实际上是经典的系统开发生命周期 SDLC(System Development Life Cycle)
的逆序写法。
COBOL— 面向商业的通用语言( Common Business Oriented Language)，商业界的一种
计算机语言。一种非常通用的语言。
column (列)— 从同一域中选择值的一个纵向表。一行可以由一个或多个列组成。
commonality of data (数据通用性 )— 出现在不同应用或系统中的相同或相似的数据。数
据通用性的识别与管理是数据库概念设计和物理设计的基础之一。
compaction (压缩) — 一种用于减少数据表示的位数而不丢失数据内容的技术。采用压
缩技术，使重复的数据可非常简明地表示。
condensation (紧缩)— 减少管理数据量而不降低数据逻辑相容性的过程。紧缩与压缩有
本质上的区别。
contention (争用)— 当两个或多个程序试图同时访问同一个数据时出现的情况。
continuous time span data(连续时间跨度数据) — 一种数据的组织形式，使得在一个时间
跨度上，连续的数据定义由一个或多个记录表示。
CPU— 中央处理机( central processing unit)。
CPU-bound (CPU-界限)— 计算机不能产生更多输出的处理状态，因为处理器的 C P U部
分被100%地使用。当计算机达到 CPU－界限时，存储处理部件通常没有被 100%地使用。使用
现代的DBMS，计算机更可能出现 I/O-界限，而不是CPU-界限。
current value data (当前值数据 )— 与随时间变化的数据相反，在执行时准确度有效的数
据。
DASD — 参见“直接存取存储设备”。
data (数据)— 在存储介质上记录的事实、概念或指令，用于通信、检索，用自动方式处
理，并表示为人可以理解的信息。
D A，data administrator (数据管理员( D A)) — 负责数据管理软件的说明、获取和维护，
下载
技术词汇 217
以及负责文件或数据库的设计、验证和安全性的个人或组织。数据模型和数据字典通常是 D A
负责的。
database (数据库 ) — 按照一种模式存储相互关联的数据集合(通常是受控的、限制冗余
的)。一个数据库能够服务于一个或多个应用。
DBA，database administrator (数据库管理员( DBA))— 负责每天监控和管理数据库的组
织职能。DBA比DA职能与物理数据库设计的关系更密切。
database key (数据库键码 ) — 数据库中每个记录存在的一个唯一值。这个值经常是被索
引的，虽然它是可以作随机处理或散列的处理。
DBMS，database management system (数据库管理系统 )— 一个基于计算机的软件系统，
用于建立和管理数据。
data-driven development (数据－驱动开发 )— 以识别数据通用性为中心的开发方法，它
是通过一个数据模型和建立比直接应用更广泛范围的程序来实现的。数据－驱动开发不同于
传统的面向应用开发。
data element (数据元) — (1)实体的一个属性；( 2)一个唯一命名和很好定义的数据类别，
由数据项组成并包括在一个活动记录中。
D I S，data item set (数据项集合 ) — 一组数据项，每个数据项直接与数据项所属数据组
的键码有关。数据项设置可以在中间层模型中见到。
data model (数据模型)— (1)逻辑数据结构，包括由 DBMS为有效进行数据库处理提供的
操作和约束；( 2)用于表示数据的系统(例如， ERD或关系型模型)。
data structure ( 数据结构 ) — 数据元之间的逻辑关系，设计用来支持特定数据处理功能
(树、列表和表)。
data warehouse (数据仓库) — 用来支持DSS功能的、集成的、面向主题的数据库的集合，
每个数据单元与某个时刻有关。数据仓库包括原子数据和轻度汇总数据。
DSS，decision support system (决策支持系统) — 一个用于支持管理决策的系统。通常，
DSS涉及以启发式方式进行的许多数据单元的分析。一般， DSS处理不涉及数据更新。
decompaction (解压缩)— 压缩的反过程；一旦数据以压缩的形式存储，必须进行解压缩
才能使用。
denormalization (反规范化)— 将规范化数据放在物理地址中以优化系统性能的技术。
derived data (导出数据)— 依赖于企业的一个主要主题的两个或多个取值的数据。
derived data element (导出数据元)— 无须存储但需要时就能产生的数据元(年龄、当前
日期、出生日期)。
design review (设计评审 ) — 在编码之前对系统的所有方面进行公开评审的质量保证过
程。
direct access (直接存取) — 通过直接引用数据的卷地址来检索和存储数据的机制。这种
机制与存取数据直接相关，因为它通常需要联机使用数据。也称为随机存取或散列存取。
DASD，direct access storage device (直接存取存储设备 )— 一种数据存储设备，其上的
数据能够被直接存取，而不需要通过一个如磁带文件的顺序文件。磁盘是一种直接存取存储
设备。
download (下载) — 根据在一个数据库中发现的数据内容，向另一个数据库卸出数据的
218 数据仓库
下载
过程。
drill-down analysis (向下探查分析 )— 一种分析形式，其中对总数的检查导致对总数的
分量的探测。
dual database (双重数据库 ) — 从决策支持数据中分离高性能的、面向事务的数据的实
践。
dual database management systems (双重数据库管理系统 )— 用多个数据库管理系统来控
制数据库环境不同方面的实践。
dumb terminal (哑终端) — 在所有处理于远程计算机上进行的地方，用于与最终用户直
接交互的装置。哑终端只作为搜集数据和显示数据的装置。
EIS，Executive Information Systems(高级管理人员信息系统) — 为高级管理人员设计的
系统，主要用于向下探察分析和趋势分析。
encoding (编码)— 数据值物理表示的缩写或简写(例如，男 =“M”，女=“F”)。
entity (实体)— 在最高抽象层上数据模型设计人员所感兴趣的人物、地点或事物。
ERD，entity-relationship diagram (实体－关系图) — 一种高级数据模型，以图式表示在
集成范围内的所有实体以及实体之间的直接关系。
event (事件)— 一个重要活动发生的信号。事件是由信息系统解释的。
external data (外部数据)— (1)来源于企业操作型系统之外的数据；( 2)驻留在中央处理系
统之外的数据。
extract (抽取)— 从一个环境中选择数据并将它传送到另一个环境的过程。
flat file (平面文件)— 不包含数据聚集、嵌套的重复数据项或数据项组的记录集合。
foreign key (外键)— 一种属性，它不是一个关系系统中的主键，但它的值是另一个关系
的主键的值。
fourth-generation language (第四代语言) — 设计用来允许最终用户随意访问数据的语言
或技术。
functional decomposition (功能分解)— 将操作划分成构成过程基础的层次功能(活动)。
granularity (粒度) — 包含在数据单元中的细节级别。越细节的数据，粒度级越低。越综
合的数据，粒度级越高。
heuristic (启发式)— 下一步骤由当前步骤的分析结果所决定的分析模式。用于决策支持
处理。
image copy ( 映像复制 )— 为达到备份的目的，将数据库从物理上拷贝到另一介质的过
程。
index (索引) — 当一个记录的索引键项已知时，维护的记录存储结构部分，用来对记录
提供有效访问的。
information (信息)— 人们为了求解问题或作出决策而吸收和评价的数据。
integrity (完整性)— 确保数据库中包含的数据尽可能地准确和一致的数据库性质。
interactive (交互的 ) — 将联机事务处理和批处理的一些特征结合起来的一种处理模式。
在交互式处理中，最终用户与他或她单独控制的数据进行交互。另外，最终用户可以启动处
理数据的后台进程。
“is a type of ” (“定义类型” ) — 在概念数据库设计(例如，“cocker spaniel ”是一种
下载
技术词汇 219
“dog”类型)过程中对数据进行抽象的一种分析工具。
iterative analysis ( 迭代分析 ) — 下一步处理依赖于当前执行步骤所获得结果的处理模
式；启发式处理。
JAD，joint application design (联合应用设计) — 创建和细化应用系统需求的人(通常是
最终用户)组成的一个组织。
judgment sample (判断样本 )— 一个数据样本，其中数据由于基于一个或多个参数的样
本而被接受或拒绝。
key ( 键码)— 用于识别或定位记录实例(或其他类似的数据组)的数据项或数据项的组合。
key，primary (主键)— 在数据库中用于识别单个记录的唯一属性。
key，secondary (辅键)— 在数据库中用于识别一类记录的非唯一属性。
living sample (活样本)— 一个代表性的数据库，它通常代替大型数据库以用于启发式的、
统计的、分析的处理。从超大型数据库定期地、有选择地提取数据，这样产生的活样本数据
库代表超大型数据库在某一时刻的一个断面。
load (装载)— 将数据值插入原先为空的数据库。
log ( 日志)— 有关活动的日记。
logging (记日志)— 自动记录与数据访问、数据更新等有关的数据。
loss of identity (特征丢失 )— 当数据是从外部数据源装入，以及外部数据源的特征丢失
时，便发生特征丢失。常见的情况是用微处理器数据。
magnetic tape (磁带) — (1)与顺序处理紧密相关的存储介质；( 2)存储和检索图象的大容
量磁性带子。
master file (主文件)— 为给定的数据集(通常是由应用限定范围)保持记录系统的文件。
metadata (元数据 )— (1)关于数据的数据；( 2)对数据的结构、内容、键码、索引等等的
描述。
microprocessor (微处理机)— 满足单个用户需要的小型处理机。
migration (迁移)— 将经常使用的数据项移到比较容易访问的存储区域，以及将不常使
用的数据项移到比较难访问的区域的过程。
m i p s(million instructions per second，每秒百万指令) — 为小型计算机和大型计算机设
定的处理器速度的标准度量单位。
online storage (联机存储器 ) — 数据能以直接的方式访问的存储装置和存储介质。
operational data (操作型数据 ) — 用于支持公司日常业务处理的数据。
operations (操作部门)— 负责运行计算机的部门。
optical disk (光盘)—与磁性装置相对的一种使用激光的存储介质。光盘通常只写，单位
字节的费用比磁性存储设备要便宜，并且可靠性高。
overflow (溢出，溢出区)—(1)记录或数据段因为其地址已被占用而不能存储于其驻留地
址的情况。在这种情况下数据被放在另外地方，这种地方称为溢出区；( 2)D A S D的区域，当
溢出情况发生时，数据被送往该区域。
ownership (所有权)— 更新操作型数据的责任。
page (页面) — (1)在DASD之上的基本数据单元；( 2)主存储器中的基本存储单元。
parameter (参数)— 作为数据限定条件使用的基本数据值，通常用在数据搜索或模块控
220 数据仓库
下载
制中。
partition (分割)— 将数据分成不同物理单元的一种分割技术。分割可以在应用层或系统
层上进行。
populate (载入)— 在原先空的数据库中放置数据的具体值。
primary key (主键)— 一个属性，其中包含的值唯一地确定具有该键的记录。
primitive data (原始数据)— 数据的存在依赖于企业主要主题领域的唯一一次出现。
processor (处理机 )— 处于计算机程序执行的中心位置的硬件。一般来说，处理机分成
三种：大型机、小型机和微机。
processor cycles (处理机周期 ) — 驱动计算机(例如：启动 I/O，执行逻辑运算、移动数据、
算术运算)的硬件的内部周期。
production environment (生产环境)— 运行操作型的、高性能的处理过程的环境。
punched cards (穿孔卡)— 存储数据和输入的早期存储介质。现在穿孔卡已很少见了。
query language (查询语言 ) — 能够让最终用户与 D B M S直接交互的语言，用以检索并可
能修改DBMS下存储的数据。
record (记录)— 用数据与公共键码的关系组织的数据值的集合。
record-at-a-time processing(每次一个记录的处理方法) — 一次一个记录、一次一个元组
的数据存取方法。
recovery (恢复)— 将数据库复原到初始位置或状态，经常是在物理介质发生较大的破坏
之后进行的。
redundancy (冗余) — 存储数据不止一次出现的设计。当数据可以更新时，冗余会带来
严重的问题。当数据不被更新时，冗余经常是一种有价值的必要的设计技术。
referential integrity (参照完整性 )— 确保预定义关系有效性的一种 DBMS功能。
r e o rganization (重组织 ) — 在差的组织状态下卸载数据，然后在好的组织状态下再装入
这些数据的过程。在一些 D B M S 中，重组织用于重新构造数据的结构。重组织经常称为
“reorg”或“卸载 /再装入”过程。
repeating groups (重复组)— 在一个给定记录取值中，能出现好几次的数据集合。
rolling summary (轮转综合 ) — 一种档案数据存储形式，越新的数据具有细节越多的存
储，越旧的数据具有细节越少的存储。
scope of integration (集成范围)— 对建模系统边界的形式定义。
SDLC，system development life cycle (系统开发生命周期 )— 传统的操作型系统开发生
命周期，通常包括收集需求、分析、设计、编程、调试、集成和实施。
sequential file (顺序文件 )— 其记录根据一个或多个键码字段的值进行排序的文件。这
些记录能够以这个顺序从文件的第一个记录开始处理，直到文件的最后一个记录。
serial file (串行文件)— 一种顺序文件，其中按顺序的记录在物理上是相邻的。
“set-at-a-time processing” (“成组处理”)— 成组访问数据，组的每个成员满足一个选
择的标准。
snapshot (快照)— 数据库转储或在一些时候将数据存档在数据库以外。
solutions database (解决方案数据库 )— DSS环境的一个存储先前决策结果的部件。解决
方案数据库用于在进行当前决策时帮助确定行动的适当过程。
下载
技术词汇 221
storage hierarchy (存储器层次结构 ) — 连接起来形成存储子系统的存储单元，其中一些
单元较快但小而昂贵，其他一些单元较慢但大而便宜。
subject database (主题数据库 )— 围绕企业主要主题进行组织的数据库。传统的主题数据
库是针对顾客、事务、生产、零件和供应商的。
system log ( 系统日志 )— 与系统事件有关的审计追踪的记载(例如事务登录、数据库变
化等等)。
system of record (记录系统)— 操作型数据的定义性的和单一的数据源。假如数据元 abc
在某个数据库记录中的值为 2 5，但在记录系统中的值为 4 5，按数据源定义第一个值是不正确
的，并且必须改成一致的。记录系统对管理数据冗余是很有用的。
table (表)— 由一组具有标题的列和一组行(即元组)组成的关系。
time stamping (标时戳 ) — 将每条记录标上某个时刻的操作，通常是记录创建时间或者
是记录从一个环境传递到另一个环境中的时间。
time variant data (随时间变化数据 )— 其准确度与一些时刻有关的数据。随时间变化的
数据的三种形式是连续时间跨度数据、事件离散数据和周期性离散数据。请参看“当前值数
据”。
transition data (转换数据 )— 既具有原始特征又具有导出特征的数据；通常对商业的运
作非常敏感。典型的转换数据是银行的利率，保险公司的保险率，厂商 /销售商的零售率等
等。
trend analysis (趋势分析)— 在时间序列上寻找同类数据的过程。请参看“ EIS”。
true archival data (真实档案数据) — 原子数据库中最低级的数据，通常存储在大容量存
储介质上。
update (更新)— 对存储在数据库中的全部或所选择出的项目、组或属性的值进行修改、
增加、删除或替换。
user (用户)— 发送命令和消息给信息系统的人或过程。
下载
下载
参考文献
Boehm, B. Software Engineering Economics, Prentice-Hall, Englewood Cliffs, NJ, 1981.
Brooks, F. P., Jr. The Mythical Manmonth: Essays on Software Engineering , Addison-
Wesley, Reading, MA, 1974.
Chen, P. P. “The Entity Relationship Model — Toward a Unified View Of Data, ” i n
Transactions on Database Systems, Vol. 1, No. 1, March 1976.
— . The Entity Relationship Approach to Logical Database Design, QED Info Sciences,
Date, C. J. An Introduction to Database Systems, Addison-Wesley, Reading, MA, 1975.
Davis, A. M. “Automating the Requirements Phase: Benefits to Later Phases of Software
Life Cycle, ” in COMPSAC 80, Proceedings IEEE , Computer Society, Los Alamitos, CA,
October 1980.
Davis, G. B., and M. H. Olson. Developing a Long-Range Information Systems Plan in
Management Information Systems, McGraw Hill, New York, 1985.
DeMarcro, T. Structured Analysis and Systems Specification, Yourdon Press, New Yo r k ,
1978.
Digital Equipment Corporation manual, Information Systems Technical Strategy and
Architecture, DEC, Marlboro, MA, June 1989.
Gane, C., and T. Sarson. S t ru c t u red Systems Analysis: Tools and Techniques, Prentice-Hall,
Englewood Cliffs, NJ, 1979.
Inmon, W. H. Information Engineering for the Practitioner, Yourdon Press, New York, 1988.
— . Using DB2 for Decision Support Systems, QED, Wellesley, MA, 1989.
— . Using Oracle for Decision Support Systems, QED, Wellesley, MA, 1989.
— . T h i rd Wave Processing: Data Base Machines and Decision Support Systems, QED,
— . Understanding Data Pattern Processing,QED, Wellesley, MA, 1991 (with S. Osterfelt).
— . Using Rdb for Decision Support Systems, QED, Wellesley, MA, 1992.
— . Practical Information Engineering, QED, Wellesley, MA, 1992.
— . Building the Data Warehouse, John Wiley & Sons, Inc, New York, 1993.
— . Information Systems Architecture: Development in the 90’s, John Wiley & Sons, Inc.,
New York, 1993.
— . Rab/VMS: Developing the Data Warehouse, John Wiley & Sons, Inc., New York, 1993.
— . Using the Data Warehouse, John Wiley & Sons, Inc., New York, 1994.
— . Building the Operational Data Store, John Wiley & Sons, Inc., New York, 1995.
Jackson, M. A. Principles of Program Design, Academic Press, New York, 1975.
下载
参考文献 223
Karimi, J. “Computer Aided Process Organization in Software Design,” Dept. of MIS,
University of Arizona, 1983.
Kelly, Sean. Data Warehousing—The Key to Mass Customization, John Wiley & Sons, Inc.,
New York, 1994.
Kerr, M. J. The IRM Imperative, John Wiley & Sons, Inc., New York, 1990.
Konsynski, B. R., and R. J. Nunamaker. Decision Support in Enterprise Analysis, Plenum
Publishing, New York, 1984.
Loper, M., and W. H. Inmon. “A Unified Data Architecture for Systems Integration,”ISEC
Conference, Washington, DC(Feb).
Love, Bruce. Enterprise Information Technologies, New York.
Martin, J. Strategic Data Planning Methodologies, Prentice-Hall, Englewood Cliffs, NJ,
1982.
Martin, J., and C. Finklestein. Information Engineering , Savant Institute, Cornforth,
Lancashire, England, 1981.
Meyer, D., and M. Boone. The Information Edge, Dow Jones Irwin, Homewood, IL, 1988.
Orr, K. T. Structured Systems Development, Yourdon Press, New York, 1977.
P a r k e r, M., R. Benson, and E. T r a i n o r. Information Economics: Linking Business
Performance to Information Technology, Prentice-Hall, Englewood Cliffs, NJ, 1989.
Parsaye, K., and M. Chignell. Intelligent Database Tools & Applications , John Wiley &
Sons, Inc., New York, 1995.
Perkinson, R. Data Analysis: The Key to Database Design, QED, Wellesley, MA, 1984.
Rousopolous, N. “The Logical Access Path Schema of a Database Design ”, A C M
Transactions in Software Engineering, Vol. SE-8, No. 6, November 1982.
Smith, J. M., and D. C. P. Smith. “Database Abstraction Aggregation,”Communications of
the ACM, Vol. 20, No. 6, June 1977.
— . “Conceptual Database Design, ”INFOTECH, State of the Art Report on Database
Design, June 1978.
Teichrow, D., and E. A. Hershey. “PSL/PSA: A Computer Aided Technique for Structured
Documentation and Analysis of Information Processing Systems, ”in IEEE Transactions on
Software Engineering, Vol. SE-3, No. 1, 1977.
Tschritzis,D.C.,and F. H. Lochovsky.Data Models,Pre n t i c e - H a l l, Englewood Cliffs, NJ,
1981.
Yourdon, E. Techniques of Program Structure and Design, Prentice-Hall, Englewood Cliffs,
NJ, 1975.
Zachman, J. “A Framework for information Systems Architecture, ”IBM Systems Journal,
Vol. 26, No. 3, White Plains, New York, 1986.
感兴趣的论文
Ashbrook, J. “Information Preservation”(从管理层的角度来看数据仓库 ), CIO Magazine,

224 数据仓库
下载
July 1993.
Data Managemant Review. “C h a rgeBack In the Information Wa r e h o u s e”(数据仓库中的
chargeback既可以是福音也可能是祸根，本文强调了这种问题的两个方面 )，March 1993.
Database Programming Design. “Now Which is Data, Which is Information”(数据和信息
之间的区别 )，May 1993.
Devlin, B. A., and P. T. Murphy. “An Architecture for a Business and Information Systems”
(首次提及IBM环境中的信息仓库 ), IBM Systems Journal, Vol. 27, No. 1, 1988.
Discount Store News。 “Retail Technology Charges Up at KMart” （KMart为他们的ODS
环境中的数据仓库所采用的技术进行描述 ), Feb. 17, 1992.
G e i g e r, J. “Information Management for Competitive Advantage ”(有关数据仓库和
Zachman结构的最新技术的讨论 ), Strategic Systems Journal, ACR, June 1993.
Gilbreath, R. MD. “Health Care Data Repositories: Components and a Model” (有关信息
体系结构及其与医疗保健结合起来的一个很好的描述 ), Journal of the Healthcare Information
and Management Systems Society, Vol. 9, No. 1, Spring 1995.
— . “Informational Processing Architecture for Outcomes Management ”(有关数据仓库
应用于医疗保健和疗效分析的描述 ; 审稿中 — 214-682-0113).
G o l d b e rg, P., Lambert, R. and Powell, K. “Guidelines for Defining Requirements for
Decision Support Systems”（很好地讲述了有关如何在建立数据仓库以前定义最终用户需求） ,
Data Resource Management Journal, Spring 1991.
Hufford, D. “Data Administration Support for Bussiness Process Improvement”(数据仓库
和数据管理 ), AMS.
Inmon, W. H. IBM Systems Journal. “An Architecture for a Business and Information
System” (讲述有关IBM对数据仓库的理解 ), vol 17, no. 1, 1988.
— . “A Conceptual Model for Documenting Data Synchronization Requirements” (数据
同步和数据仓库 ), AMS.
— . “At the heart of the Matter”(原始数据和导出数据以及它们之间的区别 ), Data Base
Programming /Design, June 1990.
— . “Going Against the Grain” (讲述有关粒度问题及其与数据仓库的关系描述 ), Data
Base Programming/Design, July 1990.
— . “The Atomic Database ” (有关分割式数据库环境是数据库发展方向的预测 ),
Enterprise Systems Journal, Nov. 1990.
— . “The Cabinet Effect”(讲述为什么数据仓库为中心的体系结构不能退化为蜘蛛网式
环境), Data Base Programming/Design, May 1991.
— . “A Tale of Two Cycles”(操作型环境和数据仓库以及决策支持环境的开发生命周期
是截然不同的。本文讨论它们的区别 ), Data Base Programming/Design, Dec. 1991.
— . “Data Structures in the Information Warehouse”(有关数据仓库中公用数据结构的确
定), Enterprise Systems Journal, Jan. 1992.
— . “Winds of Change”(数据管理和数据仓库 — 有关数据管理是如何发展到今天这
种状况的描述), Data Base Programming/Design, Jan. 1992.
下载
参考文献 225
—. “Data Warehouse — A Perspective of Data Over Time”(描述有关数据仓库和数据的
管理在时间上的关系 ), 370/390 Data Base Management, Feb. 1992.
— . “ Building the D a t a B r i d g e ” ( 成功建立数据仓库的关键因素 ), Data Base
Programming/Design, April 1992.
—. “Metadata: A Checkered Past, A Bright Future”(有关元数据及其与数据仓库关系的
讨论), 370/390 Data Base Management, July 1992.
— . “The Need for Reporting ”(讲述在体系结构的不同部件中找到不同种类的报表 ) ,
Data Base Programming/Design, July 1992.
— . “ Neat L i t t l e P a c k a g e s ” (讲述在数据仓库如何看待数据关系 ), Data Base
Programming/Design, Aug. 1992.
— . “E I S a n d t h e D a t a W a r e h o u s e”（E I S和数据仓库之间的关系） , D a t a B a s e
Programming/Design, Nov. 1992.
— . “Untangling the We b”(探索将数据变为信息的原因 ), Data Base Programming
Design, May 1993.
— . “The Structure of the Data Wa r e h o u s e”(强调数据仓库中所具有的不同数据层次 ) ,
Data Management Review, Aug. 1993.
—. “Data Warehouse Lays Foundation for Bringing Data Investment Forward”(有关数
据仓库以及它与历史系统间关系的描述 ), Application Development Trends, Jan. 1994.
— . “The Data Warehouse — All Your Data at Your Fingertips ” (数据仓库的综述 ) ,
Communications Week, Aug. 29, 1994.
—. “The Data Warehouse: Managing the Infrastructure” (讲述有关数据仓库的低层结构
以及与之相关的预算 ), Data Management Review, Dec. 1994.
— . “EIS and Detail”(讲述有关支持EIS所需细节数据的多少以及数据仓库环境中综合
数据所起的作用 ), Data Management Review, Jan. 1995.
—. “Multidimensional Data Bases and Data Warehousing”(有关数据仓库中的当前细节
数据是如何与多维 DBMS相适应的描述), Data Management Review, Feb. 1995.
—. “The Operational Data Store”(有关ODS的描述), INFODB, Vol. 9, No. 1, Feb. 1995.
— . “Profiling the DSS Analyst ”(把D S S分析人员描述为农场主和探险家 ), Data
Management Review, March 1995.
—. “The Anatomy of a Data Warehouse Record”(有关数据仓库记录内部结构的描述 ),
Data Management Review, July 1995.
—. “Profile/Aggregate Records in the Data Warehouse”(有关概要/聚集记录在数据仓库
环境中是如何创建和使用的描述 ), Data Management Review, July 1995.
—. “Data warehouse and Contextual Data: Pioneering a New Dimension” (正如在数据
仓库中实际所看到的那样，需要时间上有关的数据 ), Data Base Newsletter, Vol. 23, No. 4,
July/August 1995.
—. “Transformation Complexity” (在建立数据仓库所需的转换过程中，为什么将转换
过程自动化比手工编程要优越 )，Data Management Review, Sept. 1995.
—. “The Ladder of Success” (建立和管理数据仓库不仅仅需要选择一个平台。这篇论
226 数据仓库
下载
文指出了成功建立一个数据仓库环境所必需的步骤 ), Data Management Review, Nov. 1995.
— . “Growth in the Data Warehouse”(讲述有关为什么数据仓库成长得如此之快以及增
加存储量的同时会降低存储器使用效率的现象 ), Data Management Review, Dec. 1995.
Inmon, W. H., and C. Kelly. “The 12 Rules of Data Warehouse”(有关定义数据仓库特性
的描述), Data Management Review, May 1994.
Inmon, W. H. , and P. Koslow. “Commandeering Mainframe Database for Data Warehouse
U s e” (讲述有关在大型机系统中所采用的最佳数据仓库 ), Application Development Tr e n d s ,
Aug. 1994.
Inmon, W. H., and M. Loper. “The Unified Data Architecture: A Systems Integration
S o l u t i o n” [原文 (修订后重新发表 )提出一种用于未来系统开发的数据体系结构 ], Auerbach,
1992.
Inmon, W. H. , and S. Osterfelt. “Data Patterns Say the Darndest Things”(有关DSS系统中
数据仓库的描述，以及怎样从一个仓库中导出信息处理 ), Computerworld, Feb. 3, 1992.
Kador, J. “One on One — Interview with Bill Inmon”(就数据仓库与Bill进行的讨论，包
括数据仓库是如何出现的一些背景 ), Midrange Systems, Oct. 27, 1995.
Kimball, R., and K. Strehlo. “Why Decision Support Fails and How to Fix It” (有关事实
表和星型连接的很好的描述，并用不少的篇幅讨论了 R a l p h的数据仓库和决策支持方法 ) ,
Datamation, June 1994.
Konrad, W. “Smoking Out the Elusive Smoker”(有关在广告限制的行销环境下进行数据
库行销的讨论), Business Week, March 16, 1992.
Lambert, B. “Breaking Old Habits to Define Data Warehouse Requirements”(有关最终用
户该如何设法决定 DSS需求的讨论 ), Data Management Review.
O’M a h o n e y, M. “Revolutionary Breakthough in Client/Server Data Wa r e h o u s e
D e v e l o p m e n t”(老式的历史系统开发方法学与现代的循环重复式开发方法学的比较 ), Data
Management Review, July 1995.
Sloan, R, and H. Green. “An Information Architecture for the Global Manufacturing
Enterprise”(有关在大规模制造环境中的信息体系结构的描述 ), Auerbach, 1993.
Thiessen, M. “Proving the Data Warehouse to Management and Customers: Where Are the
Saving?”(Mark Thiessen, Hughes Aircraft的学术报告 , 1994 Data Warehouse Conference, 分发
印刷品, 714-732-9059).
Wahl, D., and D. Hufford. “A Case Study: Implementing and Operating an Atomic Data
Base”(基于美国陆军DSS数据体系结构), Data Resource Management, Auerbach, Spring 1992.
Welch, J. D. “Providing Customized Decision Support Capabilities: Defining Architectures”
(决策支持系统和体系结构，基于 PacTel Cellular 的DSS体系结构), Data Resource Management,
Auerbach, 1990.
PRISM有关数据仓库解决方案的技术专题
从操作型环境中访问数据仓库数据大多数数据流是从操作型环境流向数据仓库环境的，
但是并非都是如此。此技术专题讨论了数据的回流问题。
下载
参考文献 227
数据仓库的容量规划此技术专题讨论了数据仓库环境下的磁盘存储空间和处理器资源
的容量规划和设计的问题。
捕获修改过的数据重复扫描操作型环境以刷新数据仓库所需要的资源是相当多的，此专
题简单地介绍了完成这些工作的一种替代方法。
客户机/服务器和数据仓库客户机/服务器处理可以用于支持数据仓库处理。此技术专题
讨论体系结构和设计问题。
从企业数据模型建立数据仓库数据模型从企业数据模型建立数据仓库模型所需要采取的
步骤。
数据仓库和成本分析对数据仓库进行事前成本分析是件困难的事情，此技术专题讨论了
这个问题。
数据仓库预算此技术专题讨论了不同的花费模式以及费用花费比重，其中包括一些如何
尽量减少花费的建议。
定义记录系统确定和定义记录系统的设计方面的一些考虑。
EIS和数据仓库以历史系统为基础的 EIS是很脆弱的，而以数据仓库为基础的 EIS却是非
常稳固，本技术专题对此有详细的阐述。
对最终用户解释元数据当一个用户碰到元数据时，最原始反应通常是“元数据实际究竟
是什么东西，我为什么还需要元数据？”此技术专题以非常普通直接的术语对元数据进行了
解释。
起步数据仓库是以循环重复方式建立起来的。此技术专题以详细的方式告诉你所需要采
取的第一个步骤。
9 0年代的信息体系结构：历史系统，操作型数据存储，数据仓库描述了操作型数据存
储的作用，并且描述了将操作型存储和数据仓库混合起来所产生的体系结构。
信息工程和数据仓库数据仓库体系结构与信息工程的设计和模型化实践是相当协调的，
此技术专题描述了它们之间的关系。
加载数据仓库乍看起来，将数据加载数据仓库是一件简单的事，实际上并非如此。该讨
论涉及到了将数据从操作型环境加载数据仓库中的许多不同的考虑因素。
管理多数据仓库开发工作当一个企业开始同时建立多数据仓库时，就会出现一系列新的
设计和开发问题。此技术专题提出并讨论了这些问题。
数据仓库中的元数据元数据是数据仓库的重要部分。此技术专题讨论了数据仓库中为什
么需要元数据的不同部份，以及元数据具有哪些不同的部份。
OLAP 和数据仓库轻度综合的数据总是数据仓库体系结构不可缺少的部分。现在，这种
结构被称为 OLAP，或数据集市。此技术专题讨论了 OLAP与数据仓库中细节数据的关系。
从单个数据库进行操作型和 D S S处理：对事实和假设进行分离有一个早期的概念，就
是单个数据库既应作为操作型处理的基础，又应服务于 D S S分析型处理。这个技术专题探讨
了这些问题，并且描述了为什么数据仓库是适宜作为 DSS信息处理的基础。
操作型数据存储数据仓库的操作型对应物是操作型数据存储（ ODS）。在此技术专题中，
对ODS有详细的定义和描述。
数据仓库的并行处理管理大量数据是数据体系结构设计人员所要面临的第一个而且是主
要的挑战。并行技术提供了管理更多数据的可能性。此技术专题是有关数据仓库环境中的并
228 数据仓库
下载
行处理技术问题的。
数据仓库环境中的性能在DSS数据仓库环境中，性能问题与 OLAP环境中一样重要。此
技术专题全部是有关 DSS数据仓库环境中的性能问题的。
重建工程和数据仓库许多企业没有意识到重建工程和数据仓库之间非常紧密并且非常有
用的关系。此技术专题指出这种关系，并讨论其他相关问题。
在数据仓库中表示数据关系：数据的人工关系在数据仓库中建立数据关系的设计问题。
数据仓库的安全数据仓库的安全性问题出现在不同的层面。此技术专题对这些问题进行
讨论。
数据仓库环境中服务层协议服务层协议是联机操作的一个里程碑，服务层协议适用于数
据仓库，但各种实现方式有着很大不同。
数据仓库中的数据快照描述不同类型快照以及各种不同快照的优缺点。
数据仓库/ O D S中的汇总数据库汇总数据具有它自己一套独特的考虑，如动态汇总数据
和静态汇总数据。每种类型的汇总数据都需要设计人员与最终用户相当不同的处理。此技术
专题为汇总数据建立了一种分类法，并将不同类型的汇总数据与数据仓库和 O D S(操作型数据
存储)联系起来。
说明操作型和 D S S的区别在每个工作环境都会冒出这样的问题—什么是操作型？什么
是DSS？此技术专题告诉你它们之间的区别。
依赖于时间的数据结构讨论不同类型的数据结构以及它们的优缺点。
采用通用数据模型一些企业用数据模型来作为它们的数据仓库设计的出发点，有些企业
不是这样做。通用数据模型可作为数据仓库设计和开发工作的开始。
什么是数据仓库此技术专题定义什么是数据仓库及其结构特征。这是一个基本的讨论，
适合于所有研究数据仓库的人。
下载
附录
A.1 开发操作型系统 — 方法之一
M1 — 初始工程活动
前序的活动：作出建立一个操作型系统的决定。
后继的活动：准备使用已有的代码 /数据。
估计时间：时间是不确定的，取决于工程的规模。
通常执行一次还是多次：一次。
特别的考虑：因为这一步骤含义模糊，有无限拖延的趋势。只要系统的 9 0 %(或者更少)在
这里定义，系统的开发就应继续进行到下一个阶段。
可以提交：不成熟的系统需求。
■ 会谈 —会谈的输出是描述系统做什么的“软核心”，通常反映了中层管理者的意见。
这种输出的格式是非常自由的。会谈覆盖的领域是不全面的，这成为一个规律。
■ 数据收集 — 此活动的输出可以有多个来源。通常，需求 — 一般是详细的 — 不在
其他地方收集的部分正是在这里收集的。这是随意的、包罗万象的需求收集活动，它
的结果为其他的需求收集活动填补了空白。
■ J A D会议输出 — 此活动的输出是集体讨论的大纲。需求在 J A D会议中形式化的一个
好处是自发性和思想的交流，以及不同的人在同一间屋子中关注共同的问题而产生的
判断力的聚集。一个或多个 J A D会议的输出是一组形式化的需求，其整体代表了最终
用户的需求。
■ 战略性商业计划的分析 —如果公司有一个战略性商业计划，那么思考这个计划与设计
系统的需求怎样联系起来将是有意义的。战略性商业计划的影响能够以多种方法表达
出来 —设定增长数字、鉴定新的商业线、描述组织结构的变化，等等。所有这些因素，
以及其他一些因素，构成要建造的系统的需求。
■ 现有系统深刻地影响了新的系统需求。如果已有了相关的系统，最起码也要把新的系
统需求和现有系统的接口明确定义。
转化、替代、并行处理以及诸如此类的问题，也是可能涉及的问题。这个活动的输出是
现有系统对将要建造系统的需求的影响的说明。
成功的因素：
如果做得恰当，系统的不确定性就会降低，开发工作的范围得到合理的设定，系统的各
个部件获得良好的组织。系统的政策性的和技术性的部分同样应该引起注意和定义。
M2 — 使用现有的代码 /数据
前序的活动：系统定义。
后继的活动：规模估计，阶段划分。
下载
附录 187
估计时间：非常快，即使最大的设计通常也不会超过一星期。
特别的考虑：这个步骤是确保代码和数据可重复使用的最好方法之一。这个步骤对于环
境的集成是至关重要的。
在设计好的环境中，每一个工程都有义务做到：
■ 尽可能多地使用现有的代码 /数据。
■ 为将来的工程可以使用现在进行工程的代码和数据做准备。这个步骤的输出是鉴定现
有的代码/数据是否可以重复使用，以及鉴定将来的处理需要采取的步骤。
如果现有的代码 /数据需要修改，则将这些修改标记为系统开发需求的一个正常的部分。
如果现有的代码 /数据需要删除，则该删除就成为规格说明的一部分。如果代码 /数据需要转换，
则该转换就成为开发过程的一部分。
成功的因素：
鉴定可以作为开发基础的现有代码 /数据，分辨为准备将来的工作应当做些什么。
M3 — 规模估计，阶段划分
前序的活动：使用现有的代码 /数据。
后继的活动：需求形式化，能力分析。
估计时间：非常快，即使最大的设计通常会在一到两天内完成。
通常执行一次还是多次：一次，之后每个后续的开发阶段会访问这个步骤。
可以提交：开发阶段的标识。
在一般性需求收集完成之后，下一步就是估计系统的规模并且划分开发过程的各个阶段。
如果要开发的系统比较大，那么将它分为几个阶段是非常重要的。这样做之后，开发过程被
划分成为一些小的可以管理的单元。当然，不同的开发阶段应该被组织成为有意义的序列，
这样第二阶段将基于第一阶段，第三阶段将基于第二和第一阶段，以此类推。
这个步骤的输出，在需求很大而应该分段的情况下，将是把通常的需求分为可行的、可
管理的阶段。
成功的因素：
继续的增量开发过程是经济和可行的(并且在组织的政策范围内)。
M4—需求形式化
前序的活动：规模估计，阶段划分。
后继的活动：ERD说明书，功能分解。
估计时间：不确定，取决于系统的规模，系统的范围是否定义得好，以及此前的设计具
有多少不确定性。
通常执行一次还是多次：每个开发阶段一次。
可以提交：形式化需求说明书。
一旦完成需求收集、规模估计和阶段划分(如果需要的话)，下一步就是对其形式化。在这
一步，开发者需要保证：
■ 已经收集的需求是完备的，达到合理的可能的程度。
■ 需求经过组织整理。
188 数据仓库
下载
■ 需求是可读的，可理解的，并且在足够低的细节层次是有效的。
■ 需求之间不存在冲突。
■ 需求之间没有重迭。
■ 操作型需求和DSS需求已经分开。
这个步骤的输出是正式的需求定义，准备用于详细设计。
成功的因素：
产生一个简洁的、组织好的、可读的、可操作的、量化的、完备的、可用的需求集合，
这也是开发用的一个文档。
CA — 能力分析
前序的活动：规模估计，阶段划分。
后继的活动：ERD说明书，功能分解。
估计时间：取决于系统的规模，但是如果有评价的工具和专心的计划者，对于适当规模
的系统，两到三周是一个合理的估计。
特别的考虑：能力计划的作用在历史上是混乱的，包括一些不值得特别考虑的不相关的因
素。保持开发过程中的能力计划部分集中与切题是很重要的。否则，会成为前进的障碍。
这个被分析的工程享用的资源总量需要在开发的早期阶段被估计。特别要考虑以下几点：
■ 直接存取存储设备( DASD)的消费。
■ 软件需求(包括系统软件、工具、特别定制代码、网络软件、接口软件)。
■ CPU消费。
■ I/O利用。
■ 主存需求。
■ 网络/通道利用。
不仅要分析原始的需求，还应把事务的到达率、峰值 -周期处理、处理模式、响应时间需
求、可用性需求以及平均故障时间需求等作为考虑因素。
另外，如果需要定购硬 /软件，那么超前时间和老化时间必须计算在内，以保证当检查应
用的时候资源已经到位。
开发的这个阶段的输出是保证需要到位的资源事实上已经到位。
成功的因素：
不用奇怪当需要时资源已经到位，获得资源需要的超前时间，以及需要的大量资源。
PREQ1 — 技术环境定义
前序的活动：信息处理环境的建立。
后继的活动：规模估计，阶段划分。
估计时间： N/A。
通常执行一次还是多次： N/A。
特别的考虑：偶尔，从头开始建立一个应用系统是必需的，包括定义技术环境。如果是
这样的情况，技术定义是在数据 -驱动开发方法的边界之外的。
为了继续下去，技术环境的定义是必要的。如果技术环境此时没有被定义，结果将是产
下载
附录 189
生系统“颠簸”。简单地说，直到技术环境被定义之后，开始详细的设计才有意义。
某些设计元素超出这点之外，取决于一个或另外一个先前提到的技术基础。至少，下面
这些必需确定：
■ 使用的硬件平台。
■ 使用的操作系统。
■ 使用的DBMS。
■ 使用的网络软件。
■ 使用的开发语言。
不论使用什么硬件、软件和网络，确立下面的内容也是有益的：
■ 节点驻留处定义(对网络系统)。
■ 记录的系统管理。
成功的因素：
一个强健的、可工作的技术定义满足所开发系统的需求。
D1—实体关系图 (ERD，Entity Relationship Diagram)
前序的活动：需求形式化。
后继的活动：数据项目集合说明书。
估计时间：即使最大的系统，如果设计者知道他们要做什么的话两周就足够了。但如果
他们不知道，那么需要的时间是不确定的。
可以提交：主要主题领域的标识。
通常的正式需求集合需要标识组成系统的主要主题和这些主要主题之间的关系。主要主
题应该处于最高的抽象层次，这是个规则。
典型的主要主题是顾客、产品、事务，诸如此类。对主要主题之间的关系要进行标识，
同样还要标识关系的基数。
这个步骤的输出是组成系统的主要主题的标识以及它们之间的关系。
成功的因素：
所有的主要主题已被标识出来，使得不存在领域中的冲突；它们是在最高的抽象层次上
标识的。
一个主要的成功因素是只用原始数据建模。另一个成功的因素是在 E R D建模开始之前，
已经定义了模型的范围。
D2 — 数据项目集合(DIS，Data Item Sets)
前序的活动：ERD定义。
后继的活动：性能分析，数据存储定义。
估计时间：每个主题领域需要一个月。
通常执行一次还是多次：每个主题领域一次。
每个主题将来都要分裂(在细节级别上)成为 DIS(数据项目集合)。 DIS包括数据的属性，属
性的分组和关键字。另外，对数据的“类型”也要标识。这里的其他数据结构包括连接器( 代
表关系)和第二组数据。这个步骤的输出是对在 D1中标识的主要主题领域添加内容。
190 数据仓库
下载
成功的因素：
所有类型的主要主题都被标识出来；所有的连接器都被正确地标识；所有的关系都用连
接器标识；所有的属性都被标识；所有的属性依照它们对数据组键码的共享关系分组；所有
多次出现的属性组和单次出现的属性组分离开来；所有递归关系被设计成最一般情况下所需
的形式。这里只能出现原始数据。导出数据在其他环节标识、存储和管理。
D3 — 性能分析
前序的活动：数据项目集合的开发。
后继的活动：物理数据库设计。
估计时间：每个主题领域需要一个星期，除非主题领域非常巨大。
特别的考虑：如果数据量或处理的数量非常少，这个步骤可以略去。
如果数据量、处理的数量、网络通信量、数据和处理的增长量或处理的峰值周期将引发
大量的活动，那么就需要执行这个步骤。如果上述情况一个也不出现，就不需要这个步骤。
这个步骤是处理实际的数据反规范化问题。特别要考虑的是，设计归并表的实践，选择
性地引入冗余，创建通用导出数据池，创建数据数组，以及更进一步分离访问概率存在很大
差异的数据。
如果这个活动完成，输出将反映一个更加流水线化的设计，对于数据规范化的优点没有
或只有一点不利。
成功的因素：
依据数据和访问与更新数据的程序，好的设计使访问和更新更为有效。这个步骤做得合
适，可以保证有效地利用资源。
D4 — 物理数据库设计
前序的活动：性能分析。
后继的活动：伪代码开发。
估计时间：每个表的设计一天。
通常执行一次还是多次：每个表一次。
特别的考虑：如果这个步骤的输入不正确或是含糊不清，这个步骤的工作量将比估计要
大得多。
可以提交：表，数据库物理设计。
现在D3和(或) D4的输出用来生成一个物理数据库的设计。输出的一些特性包括：
■ 索引。
■ 数据的物理属性。
■ 划分策略。
■ 键码的指明。
■ 聚类和交叉。
■ 管理变长数据。
■ NULL/NOT NULL说明。
■ 参照完整性。
下载
附录 191
这个步骤的输出是实际的数据库的规范说明，说明是针对 D B M S或所采用的任何数据管
理软件/规范的。
成功的因素：
正确地完成这个分析步骤，把对数据、性能、更新、访问、可用性、重组织和数据重构
等的逻辑设计的所有考虑，转化为可工作的数据库设计。
P1 — 功能分解
前序的活动：需求形式化。
后继的活动：0层上下文规范说明。
估计时间：取决于系统的规模和不确定性的程度(以及已经确立的范围的稳固性和明确性)。
作为一般规则，对合理规模的系统两个星期是足够的。
从需求文档进入功能分解。功能分解只是把系统完成的大的功能细分为一系列相继的较
小的功能(有时细分到称为原语的层次)。
这个过程的输出是大功能的分解，描述从高层次到低层次所进行的不同的活动。
成功的因素：
本节反映的仅是需要设计的功能。这个步骤要考虑到已经作为或将要作为构件块的其他
功能。正确地完成这个步骤，将产生可理解的、有组织的、可读的和完备的文档。
P2 — 0层上下文
前序的活动：功能分解。
后继的活动：1-n层上下文规范说明书。
估计时间：三天。
功能分解的 0层上下文是在最高抽象层次上描述开发的各个主要活动。处理规范说明的 0
层上下文对应于数据建模的 ERD。
成功的因素：
正确地完成后，这个步骤产生的文档仅说明系统的主要活动及其间的关系。
p3 — 1-n层上下文
前序的活动：0层上下文规范说明。
后继的活动：DFD规范说明。
估计时间：每个功能一天。
通常执行一次还是多次：每个功能一次。
可以提交：完整的功能分解(注意：许多步骤构成这个提交)。
功能分解的其余层次描述所发生的更详细的活动。处理设计中的 1 - n层上下文对应于数据
设计中的数据项集合 (DIS)。
成功的因素：
这个过程正确完成时，所有主要的活动被分解到原语层次。这个分解是有序的、有组织
的和完备的，并且与活动流是一致的。
P4 — 数据流图( DFD)
192 数据仓库
下载
前序的活动：1-n层上下文规范说明。
后继的活动：算法规范说明。
估计时间：每个活动一个小时(在原语层次)。
通常执行一次还是多次：每个活动一次。
可以提交：每个处理过程的数据流图。
在每一个上下文层次 n — 原语层次 — 一个D F D被抽取出来。 D F D指明一个处理过程
的输入和输出，为建立处理过程所需要的存储，以及这个处理过程的简要说明。一个 D F D可
以在高于n的上下文层次上完成，前提是可以编写对于那个层次的程序或处理过程。
成功的因素：
每个原语层次的活动的输入和输出都被标识出来，活动流也被标识出来。对数据存储作
了概述，每个活动要做的工作做了说明。
P5 — 算法规范说明；性能分析
前序的活动：DFD规范说明。
后继的活动：伪代码。
估计时间：每个必需说明的原语层次上的活动需要五分钟到两天不等。
D F D为原语定义的处理过程进一步分解为详细的算法说明。换句话说，在这个步骤，要
概述实际出现的每一步处理。
另外，如果性能成为一个问题，程序设计性能的好坏是要考虑的因素。这就要考虑诸如
下面的设计技术：
■ 把一个长时间运行的程序分解为一系列短程序。
■ 要求程序访问较少数量的数据。
■ 缩短一个数据段单元的锁定时间。
■ 把一个可能更新的锁定改变为只进行访问。
成功的因素：
正确地完成算法说明，把说明需要的所有细节都标识出来，而且只标识说明需要的细节，
每次标识一步，并且包含所有可能性。另外，一定要确保和标准工作单元 (SWU)的一致。
P6 — 伪代码
前序的活动：算法规范说明；物理数据库设计；数据存储设计。
后继的活动：编码。
估计时间：时间长短不一(视前一个活动而定)。
通常执行一次还是多次：每个活动一次(在原语层次)。
算法和程序说明书进一步精炼成为伪代码。设计者确保处理需要的所有数据都可以获
得。所有在计算、变换、更新等过程中用到的变量都在这里标识。任何松散的端点都要标
识。设计层次上的性能也在这里考虑。这个活动的输出是编码说明，为真正的代码作好准
备。
成功的因素：
程序说明的最后一关，包括：
下载
附录 193
■ 完备性。
■ 执行次序。
■ 所有需要的情况。
■ 所有的意外，包括错误处理和异常条件。
■ 代码结构。
P7 — 编码
前序的活动：伪代码。
后继的活动：通查。
估计时间：不定，每个活动从一天到两个星期不等。
可以提交：源代码。
伪代码被翻译成源代码。如果数据已经被恰当地定义了，而且伪代码的说明是完全的，
这个步骤就会顺利。这个步骤的输出是源代码。
成功的因素：
完整和高效地把伪代码翻译成代码，包括内部文档。正确完成之后，前面说明的所有需
求在这里都得到满足。
P8 — 通查
前序的活动：编码。
后继的活动：编译。
估计时间：每个活动一小时。
通查是对代码逐字逐句进行解释。目的是在测试之前发现编写代码的错误(或其他类型的
错误)。这个步骤的输出是尽可能免除错误的源代码。
成功的因素：
在编码前检测错误。这个步骤做得好，只剩下非常少的错误需要其他手段来发现。
P9 — 编译
前序的活动：通查。
后继的活动：单元测试，重点测试。
估计时间：每个活动一个小时或稍少。
通常执行一次还是多次：直到获得一个干净的编译。
源代码通过编译。所有在编译中发现的错误被改正。这个步骤的输出是编译过的代码，
准备用于测试。
成功的因素：
为测试准备的编译过的代码。
P10 — 单元测试。
前序的活动：编译。
后继的活动：实施。
估计时间：差别很大。
194 数据仓库
下载
通常执行一次还是多次：不定。
M1 会谈
数据收集
JAD会议
战略性计划
现有系统
M2
使用现有的代
PREQI 码、数据
技术环 M3 规模估计
境建立
阶段划分 CA
M4
需求形式化能力分析
GA1
P1 D1
功能分解 ERD 高层评审
D2
P2 DIS
0层上下文
D3
P3 对
1-n层上下文性能分析
GA2 每
P4 DFD(对每个部件 ) JA1 D4
设计个
数据存储物理数据评审
P5 库设计主
定义
算法说明性能分析
题
对
P6
每伪代码
个 P7
编码
过 M 主线
P8 PREQ 先决条件
程通查
D 数据分析
P9 P 分析过程
编译
GA 通常活动
P10 JA 联合活动
测试重点测试 ST ST 重点测试
P11 CA 能力分析
实施
图A-1 方法之一
测试编译过的代码。有几个层次的单元测试。最简单的(层次最低的)单元测试是编译过的
模块的自测试，确保它的功能能够完成。下一步，把编译过的代码加入到其他代码中使之一
下载
附录 195
同工作。新的单元测试层次是保证编译过的代码和与之接口的其他模块的集成。当大的模块
组准备共同测试时出现第三层单元测试。
这个步骤的输出是测试通过的代码，准备用于执行。
成功的因素：
如果实施是正确的，进入下一个步骤的代码在程序逻辑上就是正确的。而且，在代码进
入下一步之前所有情况都测试了，包括错误处理和异常条件。
P11 — 实施
前序的活动：单元测试；重点测试。
后继的活动：N/A。
可以提交：满足规范说明的系统。
在实施的过程中有许多活动。实施在一定程度上是一个不断进行的活动。实施的一些典
型的活动是：
■ 培训，讲授。
■ 程序的加载。
■ 数据的初始加载。
■ 需要时的数据的转换。
■ 监测工具的建立。
■ 文档编写。
■ 恢复，重组过程的建立。
这个步骤(如果这一步真正结束的话)的输出是一个满意的运行系统。
成功的因素：
这个过程完成后，会有一个快乐的用户。
A.2 开发数据仓库 — 方法之二
DSS1 — 数据模型分析
前序的活动：承担数据仓库建设的任务。
后继的活动：主题领域分析，“面包箱”分析，数据仓库设计。
估计时间：差别很大，取决于数据模型的状态和质量。
开始时要定义一个数据模型。数据模型需要：
■ 标识主要主题领域。
■ 清晰地定义模型的边界。
■ 把原始数据和导出数据分离。
■ 每个主题领域需要标识：
• 键码。
• 属性。
• 属性分组。
196 数据仓库
下载
• 属性分组之间的关系。
• 多重出现的数据。
• 数据的“类型”。
这个步骤的输出是对机构已经建立了一个可靠的数据模型的确认。如果模型没有满足指
定的标准，那么进程就应该停止直至模型达到质量标准。
成功的因素：
数据模型应该具有：
■ 主要主题领域的标识。
■ 每个主要主题有自己的独立的数据定义，包括：
• 数据的子类型。
• 数据的属性。
• 清晰地定义数据的关系。
• 定义数据分组。
• 定义键码。
另外，每个进入数据仓库的数据组应该有 DSS数据和纯操作型数据的描述。所有的 DSS数
据有自己的随时间变化的键码，通常指定为高层键码的低位。
DSS2 — “面包箱”分析
前序的活动：数据模型分析。
后继的活动：数据仓库数据库设计。
估计时间：从一天到两周不等，取决于范围定义得是否好，数据模型定义得是否好，等
等。
可以提交：粒度分析。
当数据模型已经分析并且到达足够好的质量，下一步就是“面包箱”分析。“面包箱”分
析是通过粗略估计确定 D S S环境的规模。如果数据量成为一个问题，重要的是一开始就应该
知道这个情况。“面包箱”分析大致来说就是知道数据仓库要处理多少数据。
“面包箱”分析的输出是简单的 — 如果数据仓库要容纳大量的数据，那么多层次粒度就
需要考虑了。如果数据仓库没有大量的数据，就没有必要考虑多层次粒度。
成功的因素：
对整个数据仓库环境的数据量的估计 — 以行的数目表示 — 在一年的限度内和五年的
限度内，这就是这个过程的结果。基于这个估计，可以决定是否需要采用多层次粒度。如果
需要多层次粒度，那么准确地定义多层次粒度也是这个步骤输出的一部分。
DSS3 — 技术评价
前序的活动：承担数据仓库建设的任务。
后继的活动：技术环境预备。
估计时间：一周。
可以提交：技术环境评价。
下载
附录 197
管理数据仓库的技术需求，与管理操作型环境中的数据和处理过程的技术需求和考虑因
素是非常不同的。这就是为什么独立的、集中的 DSS数据存储如此流行的原因。
成功的因素：
正确执行后，数据仓库的技术定义满足下列准则：
■ 管理大量数据的能力。
■ 允许灵活访问数据的能力。
■ 根据数据模型组织数据的能力。
■ 能够用许多技术接收和发送数据的能力。
■ 能够周期地把数据全部加载的能力。
■ 能够以一次一个集合或一次一个记录的方式访问数据的能力。
DSS4 — 技术环境准备
前序的活动：技术评价。
后继的活动：数据仓库设计；载入。
估计时间：一周到一个月。
当数据仓库的体系结构配置已经建立，下一步就是技术上确定如何实现这个配置。这里
要考虑的典型问题是：
■ 需求DASD的数量。
■ 需要什么链路 — 通过网络或进入网络。
■ 预期的处理量。
■ 如何使竞争的存取程序之间的处理冲突达到最小限度或减轻这种冲突。
■ 由控制数据仓库的技术产生的通信量。
■ 由控制数据仓库的技术产生的通信量的性质 — 或短或长的爆发。
成功的因素：
这个步骤正确执行后，成功的路上就不会有技术上的阻碍了。已经安装、分配、“老化”，
而且准备好接收数据的技术部件包括：
■ 网络。
■ DASD。
■ 管理DASD的操作系统。
■ 出入数据仓库的接口。
■ 管理数据仓库的软件。
■ 数据仓库。
DSS5 — 主题领域分析
前序的活动：数据模型分析。
后继的活动：源系统分析。
估计时间：一天。
通常执行一次还是多次：每个载入工程一次。
可以提交：下一个要建造哪个主题。
198 数据仓库
下载
要载入的主题领域已经选择了。第一个选择的主题领域必须大到足以有意义，而又小到
可以实现。如果有时某个主题领域确实大而且复杂，那么应该选择它的子集来实现。这个步
骤的输出是围绕一个主题的工作范围。
成功的因素：
这个阶段正确完成后，输出是下一阶段要载入的数据的定义。最初的几个载入，通常选
择小的主题。后来的载入，选择较大的主题，甚至是主题的子集。当正确完成后，选择的载
入主题适合开发数据仓库的当前阶段的需要。
DSS6 — 数据仓库设计
前序的活动：数据模型分析，源系统分析，“面包箱”分析。
后继的活动：程序规范说明。
估计时间：一周到三周。
可以提交：数据仓库的物理数据库设计。
数据仓库是基于数据模型设计的。一些终极的设计特性包括：
■ 如果确实需要多层次粒度的话，要做好不同层次粒度的调节。
■ 把数据定向到公司的主要主题。
■ 只出现原始数据和公共的导出数据。
■ 不存在非DSS数据。
■ 每个数据记录的时间变化量。
■ 在适宜的场合物理反规范化数据(例如保证性能的场合)。
■ 在把操作型环境中的数据引入到数据仓库的地方创建人工数据。
这个步骤的输出是一个数据仓库的物理数据库的设计。注意一开始不是整个数据仓库都
要详细地设计。最初只要把数据仓库的大结构设计出来就完全可以接受了，在后面的工作中
再添入细节。
成功的因素：
这个步骤正确执行后，其结果就是一个具有一定数量数据的数据仓库，这些数据可以用
相当有效的方式加载、访问和搜索。
DSS7 — 源系统分析
前序的活动：主题领域分析。
后继的活动：程序规范说明；数据仓库设计。
估计时间：每个主题领域一周。
可以提交：记录系统的标识。
当要载入的主题已经标识了，下一个活动就是在现有的系统环境中为主题标识源数据。
D S S数据有不同的数据源是再正常不过了。集成问题正是这一点上要考虑的。这个步骤考虑
的问题如下：
■ 当数据从操作型环境转移到数据仓库环境时的键码结构 /键码分辨率。
■ 属性。
下载
附录 199
• 如果有多个来源可以选择应如何处理。
• 如果没有来源可以选择应如何处理。
• 当数据被选择传输给 DSS环境时必须做何种变换 —编码/解码、转换，等等。
■ 从数据的当前值如何创建时间变化量。
■ 结构 —DSS数据结构如何从操作型数据结构中创建。
■ 关系 —操作型的关系如何在 DSS环境中体现。
这个步骤的输出是数据从操作型环境到 DSS环境的映射。
成功的因素：
在正确执行这个步骤后，服务于数据仓库需要的源系统使用的数据，就会是及时、完备、
准确、接近来源和易于访问的，并且与数据仓库需要的结构一致。
DSS8 — 规范说明
前序的活动：源系统分析，数据仓库设计。
后继的活动：编程。
估计时间：每个抽取 /集成程序一周。
通常执行一次还是多次：每个需要编写的程序一次。
当操作型环境和 D S S环境的接口勾画出来后，下一步就是以程序说明的形式将它形式化。
这里包括的某些主要问题是：
■ 我怎么知道扫描的是什么样的操作型数据？
• 操作型数据打上时间戳了吗 ?
• 是增量文件吗?
• 有系统日志或审计日志可以使用吗？
• 现有的源代码和数据结构可以改变以产生一个增量文件吗 ?
• 前映像和后映像文件需要都清除吗？
■ 一旦扫描后我如何存储输出？
• DSS 数据用预分配、预格式化吗 ?
• 添加数据吗 ?
• 替换数据吗 ?
• 在DSS环境进行更新吗 ?
这个步骤的输出是实际的程序规范说明，用于把数据从操作型环境引入数据仓库中。
成功的因素：
当正确完成后，这个步骤将会使数据的抽取和集成尽可能地高效和简单。 (这很少会是一
个顺利、简单的过程。 )
DSS9 — 编程
前序的活动：规范说明。
后继的活动：载入。
估计时间：每个抽取 /集成程序一周。
通常执行一次还是多次：每个程序一次。
可以提交：抽取、集成和时间－透视程序转换。
200 数据仓库
下载
这个步骤包含了所有编程的标准活动，例如：
■ 开发伪代码。
■ 编码。
■ 编译。
■ 通查。
■ 各种形式的测试 — 单元测试，重点测试。
成功的因素：
当正确完成后，这个步骤生成的代码将是高效、有文档说明、易于改变、准确和完备的。
DSS10 — 载入
前序的活动：编程，技术环境预备。
后继的活动：数据仓库的使用。
通常执行一次还是多次： N/A。
可以提交：可用的数据仓库。
这个步骤需要的仅仅是执行前面开发的 DSS程序。这里考虑的问题有：
■ 载入的频率
■ 清除载入数据
■ 老化载入数据(例如，运行帐务汇总程序)
■ 管理多层次粒度
■ 更新活样本数据(如果活样本数据表已经建立)
这个步骤的输出是已载入的具有功能的数据仓库。
每个主题
DSS1 DSS5 DSS7 DSS8 DSS9 DSS10
数据模主题源系统程序编程载入
型分析领域分析说明
DSS2 DSS6
“面包箱” 数据仓库数据
分析库设计
DSS3 DSS4
技术评价技术环境准备
图A-2 方法之二
下载
附录 201
成功的因素：
当正确完成后，这个步骤的结果是一个可访问的、可理解的、能够为 D S S群体的需要服
务的数据仓库。
A.3 启发式处理 — 方法之三
在体系结构设计环境中开发的第三个阶段是为分析的目的使用数据仓库的数据。当数据
载入到数据仓库环境中，就可以着手使用了。
在这个层次进行的开发和环境其他部分的开发有本质的不同。第一个大的不同是这个阶
段的开发过程总是从数据开始，即从数据仓库中的数据开始。第二个不同是在开发过程的开
始不知道需求是什么。第三个不同(其实是第一和第二个因素的副产品)是处理以极其重复的启
发式的方式完成。在其他类型的开发中，总是存在一定数量的重复。但是在数据仓库开发后
开始的 D S S部件开发，重复的整个性质改变了。处理中的重复在分析开发过程中是普通而且
重要的部分，比在其他场合要多得多。
在DSS部件开发中的步骤可以分为两类 — 重复出现的分析(有时称为“部门”的或“功
能”的分析)和真正的启发式处理(“个别”的层次)。
图A-3显示了在数据仓库开始载入后的开发步骤。
－为部门的， DEP1
例行的报告
报告的标准需求开发
－为启发式的
分析处理
为每个分析
IND1 IND2 IND4 IND5 IND6
决定需要的数编程抽分析回答定型化？

据取数据数据问题
IND3
为归并、分
析和其他数
据混合编
程
图A-3 方法之三
A.4 启发式DSS开发 — 方法之四
DEP1 — 重复的标准开发 — 为进行重复性的分析处理(通常称为提交标准报告)，通常

的需求-驱动处理出现了。这意味着下列的步骤(前面描述的)会重复进行：
M1 — 会谈，数据收集， JAD，战略计划，现有系统。
M2 — 规模估计，阶段划分。
202 数据仓库
下载
M3 — 需求形式化。
P1 — 功能分解。
P2 — 0层上下文。
P3 — 1-n层上下文。
P4 — 每个部件的 DFD。
P5 — 算法规范说明；性能分析。
P6 — 伪代码。
P7 — 编码。
P8 — 通查。
P9 — 编译。
P10 — 测试。
P11 — 实现。
另外，至少下列的部分将会在合适的时间进行：
GA1 — 高层评审。
GA2 — 设计评审。
开发的数据分析部件没有必要做，因为开发者从数据仓库中做数据分析。
这个活动的输出是在规范基础上产生的报告。
成功的因素：
当正确完成后，这个步骤保证满足规范报告的需要。这些需要通常包括：
■ 管理报告。
■ 会计报告。
■ 关键因素指示符报告。
■ 市场报告。
■ 销售报告。
可预知的和重复性的信息需要在这个功能中满足。
注意，对于高度迭代的处理，存在成功的因素，但是是由处理过程在整体上满足的。因
为需求没有预先定义，每次迭代的成功是带一定主观性的。
IND1 — 确定需要的数据
在这里，把数据从数据仓库中选择出来，以满足报告需求的潜在的应用。当开发者
在推测方面是训练有素的，就可以理解这个活动最初的前两三次，只能检索到一部分所
需的数据。
这个活动的输出是为将来的分析选择好数据。
IND2 — 编写抽取数据的程序
当为分析处理选择好了数据，下一步就是编写程序来访问和剥离数据。这个程序应
该写得容易修改，因为可以预见程序在很多情况下要运行，修改，然后再运行。
可以提交：从数据仓库中为 DSS分析抽出的数据。
IND3 — 混合，归并，分析
数据选择好了就准备分析。通常这意味着编辑数据，和其他数据混合，提炼。
下载
附录 203
204 数据仓库
下载
下载
附录 205
与所有其他的启发式过程一样，可以预见这个程序应该编写得易于修改，因此可以
快速再运行。这个活动的输出是完全可用于分析的数据。
可以提交：和其他相关数据的分析。
IND4 — 分析数据
当数据被选择和准备好后的问题就是“所得的结果满足分析人员的需要吗 ?”如果结
果不满足，则进行另一次迭代过程。如果结果满足，就开始准备最终的报告。
IND5 — 回答问题
最终报告的生成通常是在处理过程的多次循环后得到的。最终的总结很少能在一次
分析循环中得到。
IND6 — 定型化
最后的问题是考虑是否把生成的最终报告定型化。如果这个报告需要重复地运行，
那么把这个报告作为需求集合提交并且作为一种定期重复操作重建这个报告，就是很有
意义的了。
A.5 总结
不同的活动彼此之间的关系以及与数据体系结构的概念之间的关系如图 A-4中所示。
A.6 选择的主题
图形是描述数据 -驱动开发方法的属性的最好方法。图 A - 5显示出数据模型是数据 -驱动方

法的核心。
数据模型关系到操作型数据的设计，数据仓库中数据的设计，操作型数据的开发和设计
过程，以及数据仓库的开发和设计过程。图 A-5还显示了同一数据模型如何和每个活动和数据
库关联。
数据模型是标识跨越不同应用的通用性的关键。但是有人会问，“识别处理过程的通用性
也很重要吗 ?”
回答是当然的，识别跨越应用处理的通用性是很重要的。但是试图集中于处理的通用性
有几个问题 — 处理的改变更快于数据，处理趋向于紧密地混合通用的和独自的处理以至于
它们经常不可分离，而且典型的处理分析经常在设计的范围设置一个人为的小边界。数据本
质上比处理更加稳定。数据分析的范围比处理模型的范围更容易扩大。因此，把聚焦于数据
作为识别通用性的要旨很有意义。另外，这里的假设是如果发现数据的通用性，那么这个发
现会导致对应的处理过程的通用性。
因此，数据模型 — 跨越所有应用，反映企业的观点 — 是标识和统一数据和处理通用
性的基础。
A.6.1 提交
数据－驱动开发方法的步骤包括一个提交。事实上，一些步骤和另一些步骤共同构成一
个提交。然而对于大部分情况，方法的每个步骤都有独自的提交。
操作型系统的开发的处理过程分析部件的提交在图 A-6中显示。
206 数据仓库
下载
下载
附录 207
图A - 6显示会谈和数据收集处理的提交是一个原始的系统需求的集合。决定什么代码 /数
据可以重用的分析和规模估计 /阶段划分步骤产生一个描述开发阶段的提交。
• 会谈
• 数据收集
M1 • JAD 会议原始的系统需求
• 战略性计划
• 现有系统
M2 使用现有代码，数据
M3 规模估计，阶段划分开发的阶段
M4 需求形式化
形式化的需求
P1 功能分解
P2 0层上下文完全的功能分解
P3 1-n层上下文
P4 DFD(对每个部件 ) DFDs
P5 算法说明，性能分析
P6 伪代码
P7 编码程序
P8 通查
P9 编译
P10 测试
P11 实施完全的系统
图A-6 方法之六，开发生命周期中的提交
需求形式化的活动产生(不要惊讶)一个正式的系统规范说明的集合。功能分解活动的结果
是提交一个完整的功能分解。
208 数据仓库
下载
• 会谈
• 数据收集
M1 • JAD 会议原始的系统需求
• 战略性计划
• 现有系统
M2 使用现有代码，数据
M3 规模估计，阶段划分开发的阶段
M4 需求形式化形式化的需求
P1 ERD 主要主题领域
P2 DIS 中层细节数据模式
P3 性能分析
P4 物理数据库设计表，数据库物理设计
图A-7 方法之七，操作型数据分析的提交
D F D定义的提交是一个描述已经被分解的功能的 D F D集合。通常， D F D集合表现出分解

的初始层次。
编码活动产生的提交是程序。最后，实施活动产生一个完整的系统。
图A-7显示操作型系统数据分析的提交。
会谈和数据收集过程、规模估计和阶段划分活动以及需求形式化定义产生的提交和前面
讨论的一样。
ERD活动的提交是标识主要主题领域和它们之间的关系。 DIS活动的提交是每个主题领域
的完全特征化和规范化的描述。物理数据库设计的最后提交是实际的表或数据库设计，准备
在数据库管理系统中给出定义。
下载
附录 209
数据仓库开发工作的提交在图 A-8中显示，“面包箱”分析的结果是粒度和容量的分析。和
数据仓库数据库设计相关的提交是数据仓库表的物理设计。和技术环境准备相关的提交是建立
数据仓库存在的技术环境。注意这个技术环境可能是也可能不是操作型系统存在的同一环境。
DSS2
“面包箱”分析粒度分析
DSS6
数据仓库数据库物理数据库设计
设计
DSS4
技术环境准备为加载准备
DSS技术环境
图A-8 方法之八，预备的数据仓库提交
在反复进行的基础上，数据仓库载入活动的提交在图 A - 9中表示，其中显示出主题领域分
析的提交 — 数据仓库的每次载入 — 是选择一个主题(或可能是主题的子集)来载入。
DSS5 DSS7 DSS8 DSS9 DSS10
主题领域源系统分析规范说明编程载入
建立哪一记录系统抽取，集成，可用的数据

个主题领域的标识时基，仓库
编程转换
图A-9 方法之九，数据仓库开发步骤中的提交
源系统分析的提交是被考虑的主题领域的记录系统的标识。编程阶段的提交是抽取、集
成和把数据从当前值改变到时间变化量的程序。
数据仓库的载入的最后提交是数据仓库真正的载入。已经指出过载入数据到数据仓库是
一个不断进行的活动。
处理过程的启发式层次的提交不像在开发的操作型和数据仓库层那样容易定义。这个阶
段分析处理的启发式特性更形式化。然而，图 A - 1 0显示出一些基于数据仓库的启发式处理的
提交。
210 数据仓库
下载
图A - 1 0显示从数据仓库中抽出的数据是抽取程序的结果。后来的分析步骤提交的是基于
已经提炼的数据的进一步分析。最后数据分析提交的是满足条件的 (与可理解的 )需求。
IND1 IND2 IND4
确定需要的数据编程抽取数据分析数据完成的需求
数据从数据
编程归并、
仓库中抽出
分析和与其
他数据混合
和其他相关数据
的分析
图A-10 方法之十，启发式层次处理的提交
A.6.2 一个提交的线性流程
除了启发式处理，可以期望一个线性的提交流程。图 A - 11显示了执行数据 -驱动开发方法

的过程分析部件产生的提交的例子。
不成熟的
系统需求
开发的阶段
形式化的需求
完全的功能
分解
DFDs
程序
完整的系统
图A-11 方法之十一，操作型处理分析提交的线性流程
下载
附录 211
确实存在产生提交的线性流程的原因。然而，线性流程掩盖了两个重要方面：
■ 提交通常以重复的方式产生。
■ 在任何给定的层次有多重提交。换句话说，任何层次的提交能够在下一个低的层次上
产生多个提交，如图 A-12所示。
图A - 1 2显示单一的需求定义导致三个开发阶段。每个开发阶段经过需求定义形式化再进
行分解。从分解中，多个活动被标识了，并为每个活动创建一个 D F D。接下来，每个 D F D产
生一个或多个程序。最终，这些程序构成了完整系统的构架。
不成熟的
系统需求
开发的阶段
形式化的需求
完全的功能分解
DFDs
程序
完整的系统
图A-12 方法之十二，提交通常在低层次扩散为多个提交
A.6.3 估计开发需要的资源
看一下图 A - 1 2，当准确地指明了要产生多少个提交后，就能够合理地估计开发过程需要
多少资源了。
图A - 1 3显示了一个简单的技术，首先定义每个层次的提交，这样整个提交的数目就可以
知道了。然后建立每个提交所需的时间乘以每个提交的资源，产生一个需要雇员资源量的估
计。
212 数据仓库
下载
no del * del=______
no del * del=______
no del * del=______
no del * del=______
no del * del=______
no del * del=______
图A-13 方法之十三，估计系统的开发时间
A.7 SDLC/CLDS
前面的讨论提到这样一个事实，操作型系统在一种系统开发生命周期下创建，而 D S S系
经典系统开发的生命周期
需求
↓
分析
↓
设计
使用现有代
码、数据 ↓
编程
↓
测试
↓
集成
↓
实施
↓
维护
图A-14 方法之十四
下载
附录 213
统在另一种系统开发生命周期下创建。图 A-14显示操作型系统的开发生命周期，需求是起点。
下面的活动包括分析、设计、编程、测试、集成、实施和维护。
和D S S系统相关的系统开发生命周期在图 A - 1 5显示，其中 D S S处理从数据开始。当分析
的数据取得后(通常使用数据仓库)，接下来是编程、分析等后续步骤。 DSS数据的开发生命周
期的结束是一个可理解的需求。
A.7.1 数据字典
图A-16描述了数据字典所扮演的角色。
在操作型处理中的 ERD开发和文件编制、 DIS开发、物理数据库设计和编码等活动中，数
据字典起着核心的作用。数据字典在数据仓库开发的世界中的数据模型分析、主题领域选择、
源系统选择(记录标识系统)和编程中也起着重要作用。
－为部门的，
例行的报告
－为启发式的
分析处理
→集成数据 →实现数据 →测试数据 →编程 →分析 →设计 →需求
图A-15 方法之十五
A.7.2 现有系统怎样？
极少情况下，开发工作是在没有现有系统储备下全新进行的。现有系统确实没有给数据 -
驱动开发方法的 D S S部件带来任何问题。找到现有系统中的记录系统作为数据仓库数据的基
础是最通常的事情。
然而，对操作型环境中的现有系统需要作点说明。第一种使用现有操作型系统的方法是
试图在其上建造系统。如果这样是可能的，就会更富有生产力。但是很多情况不能在现有操
作型系统之上建造。
214 数据仓库
下载
规范说明
数据模型
主题领域源系统分析编程
分析
ERD
DIS
数据字典
性能分析
物理数据库设计
伪代码
编码
操作型开发数据字典在数据－驱动开发的开发过程中的角色
图A-16 方法之十六，数据仓库开发
第二种方法是试图修改现有操作型系统。有些情况可行，但大多数情况不可行。
第三种方法是大规模替换并且加强现有的操作型系统。在这种情况下，现有操作型系统
除了能为收集需求服务外别无用处。
大规模替换的一个变种是对现有操作型系统的一部分或全部进行转化。这要有一个基本
限制，这就是现有系统小而且简单。现有操作型系统越大、越复杂，系统转换的可能性就越
小。

数据仓库

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

数据仓库

Uploaded by

Copyright:

Available Formats

下载

Ashbrook, J. “Information Preservation”(从管理层的角度来看数据仓库 ), CIO Magazine,

1970 DASD 数据库 — 所有处理的

到了1 9 7 0年，一种存储和访问数据的新技术出现了。这就是 2 0世纪7 0年代见到的磁盘存

到了8 0年代，一些更新颖的技术开始涌现出来，比如个人计算机 ( P C )和第四代编程语言

• 细节的 • 大部分粒度 • 领域狭隘 • 暂时的

操作型 原子/数据仓库 部门/数据集市 个体

J.Jones现在的 J.Jones的信用 我们吸引越来越多 我们所分析的客户

在数据仓库环境中可以找到几条有关 J . J o n e s的记录，这些记录反映了 J . J o n e s的历史信息。

传统的SDLC 数据仓库 SDLC

图1-17 从生产环境中移走不需要的数据和信息型需求— 建造数据仓库的效果

基本顾客数据 基本顾客数据 顾客活动

customer ID customer ID customer ID

高细节级 — 低粒度级 低细节级 — 高粒度级

图2-11 数据仓库主要设计问题: 粒度、分割和适当设计

每月40 000 个字节 200个字节

搜寻175 000 000个记录, 搜寻1 750 000个记录,

• 30 天详细电话历史 10年电话历史 逐个地区活动 分析处理

J Jones 4月15日 上午11:01～11:21 四月份

J Jones 95%甚至更多的 DSS处理

分割是数据仓库中数据的第二个主要的设计问题 (在粒度问题之后 )，如图 2 - 11 b所示。数

图2-18 样本数据库— 另一种改变数据粒度的方法

在某些情况下 (如人口统计分析 )，样本数据库是非常有用的。但是对使用样本数据库有一

1月1日 １月2日 1月3日 …

2月1日 2月2日 2月3日 …

3月1日 3月2日 3月3日 …

第1天 第2天 第3天 … 第7天

第1周 第2周 第3周 … 第5周

第1月 第2月 第3月 … 第12月

第1年 第2年 第3年 … 第n年

第1天 第2天 第3天 … 第7天

第1年 第2年 第3年 … 第n年

1月1日 1月2日 1月3日 … • 需要许多存储空间

J Adams 123 Main Street

J Adams 123 Main Street J Adams 123 Main Street

J Adams 1月份至今 123 Main Street

J Adams 1月份至今 123 Main Street J Adams 123 Main Street

J Adams 1月份至今 123 Main Street

2.9 数据仓库— 标准手册

数据仓库与许多人 (管理人员、 D S S分析员、开发人员、计划人员等 )相关。而在大多数机

数据仓库是 D S S处理的基础，包含的都是档案信息，而且大部分是至少 2 4小时以前的。

相同的数据， 不同的数据 这里出现， 不同的关键字

作为一个 D I S详细情况的例子，如图 3 - 1 6所示。这是一个对于一个金融机构帐户的 D I S，

有时，在物理数据库的设计中引入导出 (即计算出的 )数据可以减少 I / O，图3 - 3 1给出了这

Jan 1 - 增加 TWQ - Taiwan

图3-38 当公司发现J Jones搬家后会发生什么？

图3-39 第一步是在操作型环境中改变J Jones的地址

可以将估计的行数和 DASD数作为粒度划分过程的输入，如图 4-2所示。

1 000 000 双重粒度级 10 000 000 双重粒度级

100 000 认真设计 1 000 000 认真设计

10 000 实际上任何设计都行 100 000 实际上任何设计都行

4.6 粒度的级别— 以银行环境为例

为了对数据进行高效地访问和更新，程序员 /设计者需要在物理的块 /页的一级上对数据的

图6-3 在分布式数据仓库谱系的另一端— 在局部层要做许多操作型处理

数据仓库A 数据仓库B 数据仓库C 数据仓库D

东北部数据仓库 中西部数据仓库 西部数据仓库 东南部数据仓库

数据仓库A 数据仓库B 数据仓库C 数据仓库D

数据仓库A 数据仓库B 数据仓库C 数据仓库D

非洲数据仓库 美国数据仓库 加拿大数据仓库 远东数据仓库 南美洲数据仓库

数据仓库A 数据仓库B 数据仓库C 数据仓库D

开发小组B特有的数据 开发小组 D特有的数据

平台A 平台B 平台C

在高级管理人员看来 E I S分析是怎样的呢？作为一个例子，见图7 - 1，它显示了一家保险

第一季度 第二季度 第三季度 第四季度 第一季度 第二季度

操作型原子/数据仓库部门/数据集市个体

J.Jones现在的 J.Jones的信用我们吸引越来越多我们所分析的客户

基本顾客数据基本顾客数据顾客活动

高细节级 — 低粒度级低细节级 — 高粒度级

• 30 天详细电话历史 10年电话历史逐个地区活动分析处理

J Jones 4月15日上午11:01～11:21 四月份

1月1日１月2日 1月3日 …

第1天第2天第3天 … 第7天

第1周第2周第3周 … 第5周

第1月第2月第3月 … 第12月

第1年第2年第3年 … 第n年

第1天第2天第3天 … 第7天

第1年第2年第3年 … 第n年

相同的数据，不同的数据这里出现，不同的关键字

东北部数据仓库中西部数据仓库西部数据仓库东南部数据仓库

非洲数据仓库美国数据仓库加拿大数据仓库远东数据仓库南美洲数据仓库

开发小组B特有的数据开发小组 D特有的数据

第一季度第二季度第三季度第四季度第一季度第二季度

第一季度第二季度第三季度第四季度第一季度第二季度

第一季度第二季度第三季度第四季度第一季度第二季度

决定需要的数编程抽分析回答定型化？

主题领域源系统分析规范说明编程载入

建立哪一记录系统抽取，集成，可用的数据

确定需要的数据编程抽取数据分析数据完成的需求