Teradata基础教程 - read.pudn.comread.pudn.com/downloads129/ebook/551038/Teradata_basic.pdf · 1 . 第一章数据仓库基本概念 1.1 背景介绍...

Teradata基础教程

. I .

目目目目录录录录

第一章第一章第一章第一章数据仓库基本概念数据仓库基本概念数据仓库基本概念数据仓库基本概念 .................................................................................................................. 1

1.1 背景介绍.................................................................................................................................... 1

1.2 OLTP与OLAP ........................................................................................................................... 2

1.3 数据仓库系统的查询特点 ........................................................................................................ 5

1.4 详细数据与小结数据(DETAIL DATA与SUMMARY DATA)......................................................... 6

1.5 数据仓库与数据集市(DATA WAREHOUSE与DATA MART)....................................................... 9

1.6 TERADATA的出现 .................................................................................................................... 14

1.7 如何衡量数据仓库引擎 .......................................................................................................... 15

1.7.1 TPC-D ............................................................................................................................. 16

1.7.2 TPC-H/R.......................................................................................................................... 28

1.8 NCR可扩展数据仓库方法论与实施框架 .............................................................................. 31

1.8.1 NCR可扩展数据仓库方法论 ......................................................................................... 31

1.8.2 NCR可扩展数据仓库框架 ............................................................................................. 37

1.8.3 NCR可扩展数据仓库合作伙伴...................................................................................... 40

第二章第二章第二章第二章 TERADATA关系型数据库管理系统概要关系型数据库管理系统概要关系型数据库管理系统概要关系型数据库管理系统概要 .......................................................................... 42

2.1 TERADATA数据库的设计思想................................................................................................. 42

2.2 TERADATA数据库的体系结构................................................................................................. 43

2.2.1 Teradata V1/DBC体系结构 ............................................................................................ 43

2.2.2 Teradata V1/NCR 3600体系结构 ................................................................................... 48

. II .

2.2.3 开放的Teradata V2/SMP体系结构 ................................................................................ 58

2.2.4 Teradata V2/MPP体系结构............................................................................................ 64

2.3 TERADATA 的并行处理机制............................................................................................... 73

2.4 WINDOWS平台的TERADATA数据库 ........................................................................................ 77

2.5 TERADATA多媒体数据库 ........................................................................................................ 78

第三章第三章第三章第三章 TERADATA数据库的数据分配机制数据库的数据分配机制数据库的数据分配机制数据库的数据分配机制 .................................................................................. 81

3.1 哈希算法、主索引、与数据分配 .......................................................................................... 81

3.2 TERADATA数据分配示例 ........................................................................................................ 84

3.3 主索引与表的创建 .................................................................................................................. 87

3.4 哈希冲突与不唯一主索引 ...................................................................................................... 89

3.5 TERADATA数据库系统的在线升级......................................................................................... 92

第四章第四章第四章第四章 TERADATA数据库的数据访问机制数据库的数据访问机制数据库的数据访问机制数据库的数据访问机制 .................................................................................. 94

4.1 基于主索引的数据访问 .......................................................................................................... 94

4.2 基于唯一次索引USI的数据访问............................................................................................ 97

4.3 基于非唯一次索引NUSI的数据访问 ................................................................................... 101

4.4 全表扫描................................................................................................................................ 105

4.5 总结........................................................................................................................................ 107

第五章第五章第五章第五章如何选择主索引如何选择主索引如何选择主索引如何选择主索引 .................................................................................................................. 110

5.1 TERADATA数据库中的AMP与PDISK .................................................................................. 110

5.2 数据记录的分配 .................................................................................................................... 112

5.3 选择主索引的基本原则 ........................................................................................................ 117

第六章第六章第六章第六章数据库的空间管理、用户管理、访问权限数据库的空间管理、用户管理、访问权限数据库的空间管理、用户管理、访问权限数据库的空间管理、用户管理、访问权限 ...................................................................... 119

. III .

6.1 TERADATA中的用户与数据库............................................................................................... 119

6.1.1 数据库........................................................................................................................... 119

6.1.2 用户............................................................................................................................... 123

6.2 TERADATA数据库的层次型结构........................................................................................... 124

6.3 拥有者(OWNER)与创建者(CREATOR) ................................................................................... 129

6.4 TERADATA数据库的访问权限............................................................................................... 131

6.4.1 访问权限概述 ............................................................................................................... 131

6.4.2 显式权限 ....................................................................................................................... 143

6.4.3 监控权限 ....................................................................................................................... 143

6.4.4 如何检查一个用户或数据库的权限 ........................................................................... 144

6.4.5 GRANT命令的操作 ...................................................................................................... 148

6.4.6 REVOKE命令的操作.................................................................................................... 150

第七章第七章第七章第七章数据保护与恢数据保护与恢数据保护与恢数据保护与恢复复复复 .................................................................................................................. 152

7.1 锁(LOCK) ................................................................................................................................ 152

7.2 优先权(PRIORITY) .................................................................................................................. 158

7.3 交易完整性(TRANSACTION INTEGRITY)................................................................................. 160

7.4 临时流水(TRANSIENT JOURNAL)............................................................................................ 161

7.5 永久流水(PERMANENT JOURNAL).......................................................................................... 161

7.6 FALLBACK保护 ...................................................................................................................... 163

第八章第八章第八章第八章客户端访问客户端访问客户端访问客户端访问TERADATA数据库的方法数据库的方法数据库的方法数据库的方法 ............................................................................ 168

8.1 概述........................................................................................................................................ 168

8.2 TERADATA数据库的编程接口............................................................................................... 170

8.2.1 调用层接口CLI............................................................................................................. 170

8.2.2 嵌入式预处理器 ........................................................................................................... 171

. IV .

8.2.3 ODBC............................................................................................................................ 172

8.3 TERADATA应用工具 .............................................................................................................. 173

8.3.1 BTEQ............................................................................................................................. 174

8.3.2 FastLoad ....................................................................................................................... 175

8.3.3 MultiLoad...................................................................................................................... 177

8.3.4 FastExport..................................................................................................................... 178

8.3.5 TPump ........................................................................................................................... 178

第九章第九章第九章第九章使用使用使用使用TERADATA的主要客户分析的主要客户分析的主要客户分析的主要客户分析 .................................................................................... 179

9.1 零售业.................................................................................................................................... 180

9.2 消费品制造与零售业供货商 ................................................................................................ 182

9.3 货运业.................................................................................................................................... 183

9.4 客运业.................................................................................................................................... 185

9.5 电信业.................................................................................................................................... 186

9.6 健康保险业 ............................................................................................................................ 188

9.7 金融业.................................................................................................................................... 191

9.8 共用事业类 ............................................................................................................................ 193

9.9 其它行业................................................................................................................................ 194

附录一附录一附录一附录一 CLIENT/SERVER结构下的结构下的结构下的结构下的TERADATA数据库数据库数据库数据库 ............................................................ 213

附录二附录二附录二附录二 TERADATA ODBC驱动程序设置驱动程序设置驱动程序设置驱动程序设置.................................................................................... 216

附附附附录三录三录三录三 QUERYMAN介绍介绍介绍介绍 .............................................................................................................. 220

附录四附录四附录四附录四 WINDDI介绍介绍介绍介绍....................................................................................................................... 227

. 1 .

第一章第一章第一章第一章数据仓库基本概念数据仓库基本概念数据仓库基本概念数据仓库基本概念

1.11.11.11.1 背景介绍背景介绍背景介绍背景介绍

相对许多行业而言，信息处理技术还是一门新兴的技术，但其发展速度却几乎

是最快的。随着计算机硬件技术的飞速发展，软件技术也是日新月异。

从目前的情况来看，许多企业和机构已经建立了相对完善的OLTP(联机事务处

理)系统。随着时间的推移，这些系统中积累了大量的历史数据，其中蕴含了许多

重要的信息。通过对这些历史数据的分析和综合处理，可以找到那些对企业发展至

关重要的业务信息，从而帮助有关主管和业务部门作出更加合理的决策。七十年代

中期出现的MIS(管理信息系统)实际上就是在这种背景下产生的。

但MIS具有很大的局限性。首先，它基本上是按照预先定义好的流程对数据作

相应的处理，因此只能对预先描述好的业务问题进行回答；其次，由于开发工具的

限制，对它的修改也不太方便，特别是当业务流程发生变化，模型需要调整时，这

种修改变得更加困难；最后，由于数据的不断积累，数据量迅速增加，普通的商用

数据库(即OLTP数据库)难以处理。系统的扩展存在很大的限制。

. 2 .

在这种情况下，MIS逐步发展到了数据仓库。世界上最早的数据仓库是NCR公

司为全美、也是全世界最大的连锁超市集团Wal*Mart在1981年建立的，而最早将

数据仓库提升到理论高度进行分析并提出数据仓库这个概念的则是著名学者Bill

Inmon，他对数据仓库所下的定义是：数据仓库是面向主题的、集成的、稳定的、

随时间变化的数据集合，用以支持管理决策的过程。由此可见，数据仓库是一个综

合的解决方案，主要用来帮助企业有关主管部门和业务人员作出更符合业务发展规

律的决策。因此，在很多场合，决策支持系统也成了数据仓库的代名词。

1.21.21.21.2 OLTP与与与与OLAP

OLTP(联机事务处理On-Line Transaction Processing)系统也称为生产系统，

它是事件驱动、面向应用的，比如银行的储蓄系统就是一个典型的OLTP系统。

OLTP的基本特点是：

! 数据在系统中产生

! 基于交易的处理系统 (Transaction-Based)

! 每次交易牵涉的数据量很小

! 对响应时间要求非常高

! 用户数量非常庞大，主要是操作人员

! 数据库的各种操作主要基于索引进行

. 3 .

OLAP (联机分析处理On-Line Analytical Processing)是基于数据仓库的信息

分析处理过程，是数据仓库的用户接口部分。OLAP系统是跨部门、面向主题的，

其基本特点是：

! 本身不产生数据，其基础数据来源于生产系统中的操作数据(Operational

Data)

! 基于查询的分析系统

! 复杂查询，经常使用多表连结、全表扫描等，牵涉的数据量往往十分庞大

! 响应时间与具体查询有很大关系

! 用户数量相对较小，其用户主要是业务人员与管理人员

! 由于业务问题的不固定，数据库的各种操作不能完全基于索引进行

从数据库结构来看，如果用银行作为一个例子，两者的区别可以用图1-1 来表

示：

. 4 .

生生生生生生生生生生生生生生生生

面面面面面面面面面面面面面面面面

贷贷贷贷贷贷贷贷

信信信信面面面面信信信信

储储储储储储储储

数数数数数数数数数数数数数数数数生生生生生生生生

面面面面面面面面面面面面面面面面

客客客客客客客客

供供供供面面面面供供供供

生生生生产产产产

图1-1 面向应用的OLTP系统与面向主题的OLAP系统

对银行而言，一般都针对其各项业务开发了相应的OLTP系统，用于解决银行

日常的生产自动化问题，如储蓄系统、信用卡系统等。这些系统都是用来处理银行

的日常业务的。而图中右边显示的数据仓库系统则是面向主题的。到底哪些内容是

主题呢？这与具体要解决的业务问题有关系。对银行来说，客户是一个永恒的主

题，要研究客户的消费行为和心理，就要对客户进行各种分类，以此解决哪些客户

的信用好、哪些客户的风险较大，等等诸如此类的问题。另外，银行的产品(如贷

. 5 .

款、储蓄等业务项目)也是一个值得研究的主题，据此可以分析这些产品的市场定

位情况。

1.31.31.31.3 数据仓库系统的查询特点数据仓库系统的查询特点数据仓库系统的查询特点数据仓库系统的查询特点

数据仓库和生产系统不同，它保存的是历史交易数据，因此用户针对数据仓库

的交易主要是查询。数据仓库的查询和生产系统的查询有很大的区别。

针对生产系统的查询都比较简单，不常使用表的连接操作(Table Join)，每次

操作所牵涉的数据量很小。这类问题的特点是“知道自已要找什么”，例如根据银行

帐号查余额。这类操作往往是基于索引进行的，如帐号可以作为储蓄系统的索引。

由于这些特点，数据量大小对系统性能影响不大。

而针对数据仓库系统的查询大都非常复杂，主要有两种：一种以报表为主，从

数据库中产生各种形式的业务报表。这种查询是预先规划好的 (Pre-Defined

Query)；另一种则是随机的、动态的查询(Ad-Hoc Query)，对查询的结果也是不能

预料的。例如世界上最大的连锁超市集团Wal*Mart曾利用查询和数据挖掘工具发

现周末时啤酒与一次性尿布顾客一块购买的机会最大，结果出人意料。经过分析，

原来是美国的太太们在周末时常叮嘱她们的丈夫在下班后为小孩买尿布，而丈夫们

在买尿布时又顺手捎带些啤酒。发现这一规律后，Wal*Mart就在它的各个连锁商

. 6 .

店里把这两种商品放在一起，方便父亲们购买，结果这两种商品的销售量都增加了

很多。这个故事已经成了数据仓库成功应用的经典案例。

数据仓库中的查询由于其复杂性，会经常使用多表的联接、累计、分类、排序

等操作，这些大都要对整个表进行搜索(Full Table Scan)，特别消耗系统资源，而

且每次查询返回的数据量一般都很大。对于Ad-Hoc查询而言，经常需要根据上次

查询的结果进行进一步的搜索和分析，以便找到蕴含在数据中的潜在规律。

根据这些特点，数据库大小对数据仓库系统的性能影响很大。当数据仓库投入

使用后，各业务部门的要求会越来越多，使得数据仓库中数据量的增长速度很快，

因此设计数据仓库时，系统的可扩展能力是必须考虑的重要因素之一。

另外，系统的并行处理能力是另一个要考虑的重要因素。因为查询的复杂性，

每个查询将占用很多的系统资源，如果并行处理能力不强，当多个用户同时发出交

易请求时，响应时间可能长得不可容忍。

1.41.41.41.4 详细数据与小结数据详细数据与小结数据详细数据与小结数据详细数据与小结数据(Detail Data与与与与Summary Data)

在数据仓库中经常要谈到详细数据与小结数据，图1-2 清楚地说明了详细数据

与小结数据的作用和区别。左边一列记载了扫描仪在每个连锁店每天的交易细节

. 7 .

(数量、交易时间、交易地点、类型、客户、售货员等等)，中间一列记录了扫描仪

每天按连锁店分类的交易汇总情况，右边一列记录了扫描仪每周按连锁店分类的交

易汇总情况。由此可见，小结可以是多种层次的。

扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫数数数数数数数数

121

1563807

149. . .

2

数数类类号

F K

14

. . .

NN

1234001123400112340011234001

. . .

P KF K

POS 扫扫序序号

4022

32

12340051234005

. . . . . . . . .

. . .

. . .. . .. . .

. . .

. . .12340271234027

. . .

. . .123404612340461234046

. . .

. . .12346391234639

. . .

. . .

2807. . .. . .

177807

2. . .. . .

2177. . .

33

. . .

. . .613

. . .

. . .11

. . .

. . .

. . .

. . .. . .. . .2222222

. . .

. . .Jun 01Jun 02Jun 03Jun 04Jun 05Jun 06Jun 07

分分编号

扫扫日日

F KP K

扫扫扫扫扫扫扫扫扫扫扫扫日日日日扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫

1111111

. . .

. . .110126127144102344410

NN, DD

. . . . . .2 22 22 22 22 22 22 2

. . .Jun 01Jun 02Jun 03Jun 04Jun 05Jun 06Jun 07

. . .5047322037

144126

. . . . . .

. . . . . .. . .. . .

. . .

. . .

. . . . . .. . . . . .

1. . .

2. . .

Jun 07. . .

1363. . .

周周日日

扫扫扫扫扫扫扫扫扫扫扫扫周周周周扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫

NN, DDF KP K

. . .

. . .. . .. . .

. . .

. . .. . .. . .

22 Jun 07 456. . .. . .

. . .

. . .. . .. . .

. . .

. . .

... ... !扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫扫数数数数数数数数详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详详

类类号

数数分分编号

类类号数数

图1-2 详细数据与小结数据

. 8 .

详细数据中包含了许多有价值的信息，经小结处理后，可能会丢失这些信息。

举例来说，市场行销人员规划在某个星期二和星期三进行扫描仪的产品推销活动

(如采取一些优惠措施)，如果他们只知道每周扫描仪的销售量，怎么能看出这个推

销活动的效果？又如何来分析客户的购买行为？

由此可见，为了更准确地分析市场发展规律，提高企业的竟争优势，数据仓库

中应该存储尽可能详细的数据，为决策提供更加可靠、更加丰富的信息。如前面提

到的Wal*Mart集团，其全世界所有连锁店每天的交易数据都会通过卫星传送到在

美国的中央数据仓库。如果你买两枝同样型号但不同颜色的铅笔，在数据仓库中都

是两条记录，因为据此可以分析对不同颜色铅笔的需求规律，从而确定货存量等。

当然，在一个实际的数据仓库系统中，考虑到性能上的多种原因，需要保存一

定的小结数据，但一个基本的原则是：首先要保存详细数据，然后再保存小结数

据。产生小结数据后，不能将详细数据丢弃。因为从详细数据中可以产生小结数

据，反过来则不能从小结数据推导出详细数据。

既然详细数据的作用如此重要，为什么还要对其进行小结处理呢？主要原因可

能是：

1. 数据仓库的引擎--数据库系统--不适合处理大量的数据。前面已经说明，

在数据仓库中数据量大小对系统整体性能影响很大，而能在OLTP系统中

处理TB级数据并不能代表在数据仓库中也能处理TB级数据，因为两者是

. 9 .

完全不一样的环境。对详细数据进行不同级别的小结处理后，可以提高系

统性能。当然这样做的代价是浪费了系统的存储空间。

2. 降低存储系统投资。在以前，存储介质是非常昂贵的。而现在对一些专用

系统来说，情况还是没有什么太大的改善。

3. 降低MIPS投资。尽管计算机性能已经有了很大提高，开放系统的价格一降

再降，但直到现在，专用大型主机(Mainframe)的MIPS仍然非常昂贵。

由此可见，选择能支持TB级数据仓库的数据库系统和在开放环境下建立数据

仓库是非常重要的。

1.51.51.51.5 数据仓库与数据集市数据仓库与数据集市数据仓库与数据集市数据仓库与数据集市(Data Warehouse与与与与Data Mart)

数据集市也是当前非常热门的一个术语，一种比较常见的误解是认为两者的差

别只是数据量的大小而已。事实上，数据仓库是企业级的，能为整个企业各个部门

的运行提供决策支持手段；而数据集市是部门级的，一般只能为某个局部范围内的

管理人员服务。有些供应商也称之为部门级数据仓库 (Departmental Data

Warehouse)。

. 10 .

在数据集市领域，主要的供应商和支持者以美国红砖(Red Brick)公司为代

表，其总裁Ralph Kimball在1997年12月的一篇论文中提出，数据仓库只不过是一

些数据集市的集合而已。认为企业多建立一些数据集市，将来自然就形成了数据仓

库。而数据仓库之父Bill Inmon在1998年1月立即撰文反驳，旗帜鲜明地指出：你你你你

可以在大海中捕到很多的小鱼并堆积起来，但它们仍然不是鲸鱼。可以在大海中捕到很多的小鱼并堆积起来，但它们仍然不是鲸鱼。可以在大海中捕到很多的小鱼并堆积起来，但它们仍然不是鲸鱼。可以在大海中捕到很多的小鱼并堆积起来，但它们仍然不是鲸鱼。

数据集市有两种，即独立的数据集市(Independent Data Mart)和从属的数据集

市(Dependent Data Mart)。从图1-3 可以清楚地看到数据仓库、从属数据集市与

独立数据集市之间的关系：


操操数数操操操中中数数数数

企企企企企企企企数数数数数数数数数数数数数数数数

储储储储储储储储生生生生生生生生

信信信信面面面面信信信信生生生生生生生生

。。。。。。。。。。。。

市市市市市市市市市市市市财财财财财财财财市市市市。。。。。。。。。。。。

从从数数集市

独独数数集市

. 11 .

图1-3 数据仓库与数据集市逻辑结构示意图

图中左边表示的是企业数据仓库的逻辑结构。我们看到，其中的数据来自于各

生产系统，把它们的操作数据按照企业数据仓库物理模型结构的定义转换过来。注

意这种转换并非一对一的复制，即不是把生产系统中的某个表原封不动地复制到数

据仓库中来。事实上，数据转换是一个非常复杂的过程，要把生产系统中的各项数

据按照数据仓库模型的定义进行各种加工，然后把与某个主题相关的信息都转换并

集中到数据仓库中的对应主题表来，比如把各生产系统中与客户有关的数据都转换

到数据仓库的客户表中。采用这种中央数据仓库的做法，可以保证数据的一致性(A

Single Version of the Truth)。

图1-3中间表示的是从属数据集市的逻辑结构。所谓从属，是指它的数据直接

来自于中央数据仓库。显然，这种结构仍能保持数据的一致性。一般为那些访问数

据仓库十分频繁的关键业务部门建立从属的数据集市，这样可以较好地提高查询的

反应速度。另外一个原因是：在设计数据仓库的逻辑模型时，为了保证结构清楚，

降低数据冗余度，一般都按第三范式(3NF: 3rd Normal Form)来设计。但在物理实

现时，出于性能方面的考虑，常常要作非正则处理(De-Normalize)，使得中央库的

复杂性增加，不易维护，数据冗余。因此，当中央数据仓库十分庞大时，我们一般

. 12 .

不对中央库作非正则处理，而是建立一个从属数据集市，对它作非正则处理。这样

做既能提高响应速度，又能保证整个系统的易维护性，其代价是增加了对数据集市

的投资。

图1-3右边描述了独立数据集市的逻辑结构，它的数据直接来源于各生产系

统。许多企业在计划实施数据仓库时，往往出于投资方面的考虑，最后建成的就是

这种结构的独立数据集市，用来解决个别部门比较迫切的决策问题。从这个意义上

讲，它和企业数据仓库除了在数据量大小和服务对象上有所区别外，逻辑结构并无

多大区别，也许这是把数据集市称为部门数据仓库的主要原因。关键问题在于：随

着需求的增加，数据量也会迅速增加，系统规模将迅速扩大。是把原来的独立数据

集市扩展成为图中左边的企业数据仓库呢？还是为各部门分别建立独立的数据集市

最后形成如图1-4所示的繁杂系统？

. 13 .


独独数数集市

市市市市市市市市市市市市。。。。。。。。。。。。财财财财财财财财市市市市

储储储储储储储储生生生生生生生生

信信信信面面面面信信信信生生生生生生生生

图1-4 多个独立数据集市

在这种结构中，IT部门必须设计多个数据转换程序，把各生产系统的操作数据

分别转换到每个独立数据集市中，以便保持数据的一致性。显然，这种策略将使整

个系统变得非常复杂而且难于维护，在投资方面更是得不偿失，因为硬件系统的投

资呈比例增加，软件方面的投资和维护方面的投资则呈指数形式增加。

. 14 .

既然这种分布式的独立数据集市结构有诸多问题，为什么还有一些企业在这样

做呢？回答是“不得已而为之”，因为硬件平台或者数据库在扩展性方面限制太多，

并行处理能力不够，无法处理大量的数据，最后只能形成这种尴尬局面。

1.61.61.61.6 Teradata的出现的出现的出现的出现

根据上面的讨论，我们已经确认，数据仓库和传统的OLTP系统有很大的区

别，它需要对海量的历史交易数据作大范围的搜索、分析等综合处理，普通的

OLTP数据库难当此任。因此，需要一种专门针对数据仓库应用而设计的数据库管

理系统。

1976年Teradata公司成立，瞄准了联机分析处理这一市场，公司的目标是要

设计出能够处理大数据量的数据库计算机。1984年Teradata公司推出了当时世界

上第一个基于海量并行处理技术(MPP)的商用系统，硬件平台是DBC(Data Base

Computer)，操作系统为TOS(Teradata OS)。1989年Teradata公司和NCR公司合

作，一起研制下一代数据库计算机。1992年Teradata公司被AT&T公司收购，并与

NCR公司合并，开始将封闭数据库计算机系统移植到开放平台。1996年NCR公司

推出了UNIX平台下的Teradata关系数据库管理系统。1998年推出了Windows NT

平台下的Teradata关系数据库管理系统。

. 15 .

Teradata是一个关系数据库管理系统，能够把企业的交易转变成关系。它采用

标准的SQL查询语言，但独特的内部结构特别适合于处理复杂查询数据仓库应用。

其良好的扩展性能够随着业务的发展而发展，从GB级扩展到100TB以上。目前世

界上最大的数据仓库是SBC Communications Inc的数据仓库，数据量达到128TB，

就是采用Teradata数据库实现的。

著名的评估机构Gartner Group于1994年将Teradata评为“商用并行处理的领

导者”，1996年进一步指出，“只有NCR的Teradata证明了其可扩展性”。1999年对

数据仓库厂商的评测中，又将NCR公司及其数据库Teradata列为第一。我们知

道，对于一个实际应用的数据仓库而言，并行处理能力和可扩展性是至关重要的两

大因素，而Teradata正是通过其大量的实际应用而获此殊荣的。

在数据库专业杂志“数据库编程与设计”(Database Programming & Design)每

年的评选数据库十二大产品(Database Dozen)的活动中，Teradata已经连续第7年

入选。在1999的评选中，该杂志认为，“Teradata代表了数据库技术的发展方向”。

1.71.71.71.7 如何衡量数据仓库引擎如何衡量数据仓库引擎如何衡量数据仓库引擎如何衡量数据仓库引擎

既然数据仓库系统与普通的OLTP生产系统有很大的区别，而作为数据仓库引

擎的数据库管理系统，其性能的优劣对整个数据仓库解决方案的成功实施又起着举

. 16 .

足轻重的作用，那么，如何来衡量一个数据库管理系统是否适合作为数据仓库引擎

呢？

目前国际上标准的计算机系统的测试组织是TPC，TPC定义了专门针对决策支

持系统(即数据仓库系统)的基准测试指标。

TPC(Transaction Processing Performance Council)是一个非赢利的国际组

织，专门定义交易处理和数据库的测试标准。主要基准测试指标有TPC-C、 TPC-

H/R、TPC-W，TPC-C适用于OLTP环境，TPC-H/R适用于决策支持环境， TPC-

W适用于基于WEB的电子商务环境。TPC有40多个成员，主要为计算机系统供应

商和数据库供应商，也包括研究机构、系统集成商和最终用户，其成员有 NCR、

IBM 、 HP 、 SUN 、 COMPAQ 、 DELL 、 EMC 、 ORACLE 、 SYBASE 、

INFORMIX、MICROSOFT等。

1.7.11.7.11.7.11.7.1 TPC-D

由于TPC-H/R是TPC在1999年才开始采用的新的基准测试，以代替原先的

TPC-D基准测试。因此，让我们首先来回顾一下比较熟悉的TPC-D基准测试及其

结果。

. 17 .

TPC-D是早期衡量决策支持系统的测试指标，主要考虑以下三方面的数据指

标：

! QppD(Query Processing Power D)

这个数据指标描述了系统的复杂查询处理能力。(D表示这个结果是按

照TPC-D标准测得的，下同)

! QthD(Query Throughput D)

这个数据指标表示流量测试结果，它描述了系统在多个用户同时进行

复杂查询时的处理能力。换言之，它也代表了系统的并行处理能力。

! QphD(Query Price-Performance D)

价格/性能。

显然，前面两个指标的数据越大越好，而最后一个则越小越好。当然，首先要

考虑的应该是能否满足业务上的需求。

需要作些说明的是流量测试结果。尽管它描述了系统处理并发查询请求的能

力，但并非所有厂商的流量测试是在多用户状态下进行的，因为TPC-D给了供应商

们一个选择：直接进行多用户状态下的流量测试；或者先在单用户状态下进行测

试，然后利用测得的处理能力指标QppD和流量指标的计算公式来“计算”出QthD。

如何区分这两种测试结果呢？只要简单浏览TPC-D的测试概要 (Executive

Summary)，上面清楚地说明了在作流量测试时的STREAM数目。STREAM数实

. 18 .

际上代表了同时递交查询请求的用户个数。如果是单用户状态下进行测试，则只能

发现一个 STREAM，即STREAM00。

TPC-D的测试是在不同的数据库级别上进行，主要可供参考的是100GB、

300GB、1TB和3TB四个级别的测试结果。NCR公司参加了全部四个级别的TPC-D

测试。尤其值得注意的是，Teradata在以上四个级别的测试全部在同一个系列的软

硬件平台下进行，而且无论在哪一个级别均处于第一位，并且所有流量测试均为多

用户状态，这充分说明了其良好的线性可扩展能力与并行处理能力。

. 19 .

表1-1从IDEAS公司网站下载的TPC-D测试结果排名(至1999年4月1日之前的比

较)

Database Size 100GBDatabase Size 100GBDatabase Size 100GBDatabase Size 100GB

Position

TPC-D Power

Qppd

QthD

QphD

$/QphD

Database

1

NCR WorldMark 5200

45,691.5

5,087.3

15,246.20

318.00

Teradata V2R3.0

2

NCR WorldMark 4400

17,115.2

869.1

3,856.80

83.00

Teradata V2R3.0

3

Compaq ProLiant 6500 Xeon

14,026.3

4,500.0

7,944.70

181.00

IBM DB2 UDB EEE 5.2.0

4

Sun Enterprise 3500

13,738.7

2,551.0

5,920.10

182.00

Oracle8i v8.1.5.1.1

5

NEC Express5800 HV8600

13,554.3

2,143.6

5,390.30

113.00

Oracle8i v8.1.5.1.1

6

Siemens Primergy 870-40

10,018.5

1,554.1

3,945.80

91.00

Oracle8i v8.1.5.1.1

7

IBM Netfinity 7000 M10

8,199.1

1,265.3

3,220.90

115.00

Oracle8i v8.1.5.1

8


6,506.3

1,304.8

N/A

111.00

Oracle8i v8.1.5.1

9


4,977.9

747.8

1,929.40

123.00

DB2 UDB 5.2.0

10

IBM RS/6000 S70 Advanced

4,226.5

1,092.6

2,148.90

589.00

DB2 UDB 5.2.0

. 20 .

Position TPC-D Throughput Qppd QthD QphD $/QphD Database

1

NCR WorldMark 5200

45,691.5

5,087.3

15,246.20

318.00

Teradata V2R3.0

2


14,206.3

4,500.0

7,944.70

181.00


3

Sun Enterprise 3500

13,738.7

2,551.0

5,920.10

182.00

Oracle8i v8.1.5.1.1

4


13,554.3

2,143.6

5,390.30

113.00

Oracle8i v8.1.5.1.1

5


10,018.5

1,554.1

3,945.80

91.00

Oracle8i v8.1.5.1.1

6


6,506.3

1,304.8

N/A

111.00

Oracle8i v8.1.5.1

7


8,199.1

1,265.3

3,220.90

115.00

Oracle8i v8.1.5.1

8

IBM RS/6000 S70 Advanced

4,226.5

1,092.6

2,148.90

589.00

DB2 UDB 5.2.0

9

NCR WorldMark 4400

17,115.2

869.1

3,856.80

83.00

Teradata V2R3.0

10


2,295.3

841.8

1,390.10

146.00

IBM DB2 UDB 5.2.0

Position

Price/Performance

Qppd

QthD

QphD

$/QphD

Database

1

NCR WorldMark 4400

17,115.2

869.1

3,856.80

83.00

Teradata V2R3.0

2


10,018.5

1,554.1

3,945.80

91.00

Oracle8i v8.1.5.1.1

3


6,506.3

1,304.8

N/A

111.00

Oracle8i v8.1.5.1

. 21 .

4


13,554.3

2,143.6

5,390.30

113.00

Oracle8i v8.1.5.1.1

5


8,199.1

1,265.3

3,220.90

115.00

Oracle8i v8.1.5.1

6


4,977.9

747.8

1,929.40

123.00

DB2 UDB 5.2.0

7


3,450.0

831.2

1,693.40

130.00

DB2 UDB 5.2.0

8


2,295.3

841.8

1,390.10

146.00

DB2 UDB 5.2.0

9


14,026.3

4,500.0

7,944.70

181.00


10

Sun Enterprise 3500

13,738.7

2,551.0

5,920.10

182.00

Oracle8i v8.1.5.1.1

Database Size 300GBDatabase Size 300GBDatabase Size 300GBDatabase Size 300GB

Position

TPC-D Power

QppD

QthD

QphD

$/QphD

Database

1

NCR WorldMark 5200

133,966.8

13,756.2

42,928.80

440.00

Teradata V2R3.0

2

HP 9000 V2500

56,243.7

7,540.0

20,593.20

204.00

Oracle8i v8.1.5.1

3

Compaq AlphaServer GS140

29,711.6

4,868.7

12,027.40

192.05

Oracle8i v8.1.5.1

4

IBM RS/6000 SP Model 550

10,469.6

6,166.5

8,035.00

721.00

DB2 UDB 5.2.0

. 22 .

5 Compaq AlphaServer GS140 8,273.1 3,487.8 5,371.70 999.00 INFORMIX IDS/AD/XP

8.21.UD2

6

HP NetServer LXr 8000

8,124.3

1,324.7

3,280.60

162.00

Oracle8i v8.1.5.1

7

Sun Ultra Enterprise 10000

8,113.2

3,343.9

5,208.60

1,400.00

INFORMIX Dynamic Svr

AD/XP 8.21

8

Sequent NUMA-Q 2000

(405MHz)

7,734.4

3,055.4

4,861.30

740.00

INFORMIX IDS/AD/XP

8.21.UD2

9

SGI Origin 2000 Rack

4,853.9

1,861.9

3,006.20

973.00

Oracle v8.0.4

10

Data General AViiON

AV20000

3,305.8

1,277.7

2,055.20

1,320.00

Oracle v8.0.4

Position

TPC-D Throughput

Qppd

QthD

QphD

$/QphD

Database

1

NCR WorldMark 5200

133,966.8

13,756.2

42,928.80

440.00

Teradata V2R3.0

2

HP 9000 V2500

56,243.7

7,540.0

20,593.20

204.00

Oracle8i v8.1.5.1

3


10,469.6

6,166.5

8,035.00

721.00

DB2 UDB 5.2.0

4


29,711.6

4,868.7

12,027.40

192.05

Oracle8i v8.1.5.1

5


8,273.1

3,487.8

5,371.70

999.00

INFORMIX IDS/AD/XP

8.21.UD2

. 23 .

6 Sun Ultra Enterprise 10000 8,113.2 3,343.9 5,208.60 1,400.00 INFORMIX Dynamic Svr

AD/XP 8.21

7

Sequent NUMA-Q 2000

(405MHz)

7,734.4

3,055.4

4,861.30

740.00

INFORMIX IDS/AD/XP

8.21.UD2

8

SGI Origin 2000

4,853.9

1,861.9

3,006.20

973.00

Oracle8 v8.0.4

9

Sun Enterprise 6000

3,270.6

1,477.8

2,198.50

1,553.00

INFORMIX OnLine XPS

8.20 UA2

10


8,124.3

1,324.7

3,280.60

162.00

Oracle8i v8.1.5.1

Position

Price/Performance

Qppd

QthD

QphD

$/QphD

Database

1


8,124.3

1,324.7

3,280.60

162.00

Oracle8i v8.1.5.1

2


29,711.6

4,868.7

12,027.40

192.05

Oracle8i v8.1.5.1

3

HP 9000 V2500

56,243.7

7,540.0

20,593.20

204.00

Oracle8i v8.1.5.1

4

NCR WorldMark 5200

133,966.8

13,756.2

42,928.80

440.00

Teradata V2R3.0

5

NCR WorldMark 4400

1,412.1

487.1

829.90

464.00

Teradata V2R2.1

6


1,585.0

518.6

906.60

518.00

Oracle8 v8.0.4

7


10,469.6

6,166.5

8,035.00

721.00

DB2 UDB 5.2.0

. 24 .

8 Sequent NUMA-Q 2000

(405MHz)

7,734.4 3,055.4 4,861.30 740.00 INFORMIX IDS/AD/XP

8.21.UD2

9

SGI Origin 2000

4,853.9

1,861.9

3,006.20

973.00

Oracle8 v8.0.4

10


8,273.1

3,487.8

5,371.70

999.00

INFORMIX IDS/AD/XP

8.21.UD2

Database Size 1TBDatabase Size 1TBDatabase Size 1TBDatabase Size 1TB

Position

TPC-D Power

Qppd

QthD

QphD

$/QphD

Database

1

NCR WorldMark 5200 (44

x 4-way)

366,509.5

24,142.0

94,065.30

273.00

Teradata V2R3.0

2

Sun Enterprise 10000 (64

way)

121,824.7

10,566.3

35,878.10

283.00

Oracle8i v8.1.5.1.2

3


way)

70,343.7

7,658.6

23,210.70

438.00

Oracle8i v8.1.5.1.1

4


(32 x 4-way)

36,872.0

8,166.9

17,353.10

352.00

DB2 UDB 5.2.0

5

Sequent NUMA-Q 2000

(64-way)

27,441.8

4,870.3

11,560.70

756.00

Oracle8i v8.1.5

. 25 .

6


way)

27,024.6

5,740.0

12,454.80

776.00

Oracle8i v8.1.5

7

IBM RS/6000 SP Model

550 (48 x 4-way)

19,137.5

10,661.5

14,284.10

797.00

DB2 UDB 5.2.0

8

Sun Enterprise 6000 (4 x

24-way nodes )

12,931.9

5,850.3

8,698.00

1,353.00


AD/XP 8.21

Position

TPC-D Throughput

Qppd

QthD

QphD

$/QphD

Database

1


x 4-way)

366,509.5

24,142.0

94,065.30

273.00

Teradata V2R3.0

2


550 (48 x 4-way nodes)

19,137.5

10,661.5

14,284.10

797.00

DB2 UDB 5.2.0

3


way)

121,824.7

10,566.3

35,878.10

283.00

Oracle8i v8.1.5.1.2

4


(32 x 4-way)

36,872.0

8,166.9

17,353.10

352.00

DB2 UDB 5.2.0

5


way)

70,343.7

7,658.6

23,210.70

438.00

Oracle8i v8.1.5.1.1

6


24-way nodes )

12,931.9

5,850.3

8,698.00

1,353.00


AD/XP 8.21

. 26 .

7


way)

27,024.6

5,740.0

12,454.80

776.00

Oracle8i v8.1.5

8

Sequent NUMA-Q 2000

(64-way)

27,441.8

4,870.3

11,560.70

756.00

Oracle8i v8.1.5

Position

Price/Performance

Qppd

QthD

QphD

$/QphD

Database

1


x 4-way)

366,509.5

24,142.0

94,065.30

273.00

Teradata V2R3.0

2


way)

121,824.7

10,566.3

35,878.10

283.00

Oracle8i v8.1.5.1.2

3


(32 x 4-way)

36,872.0

8,166.9

17,353.10

352.00

DB2 UDB 5.2.0

4


way)

70,343.7

7,658.6

23,210.70

438.00

Oracle8i v8.1.5.1.1

5

Sequent NUMA-Q 2000

(64-way)

27,441.8

4,870.3

11,560.70

756.00

Oracle8i v8.1.5

6


way)

27,024.6

5,740.0

12,454.80

776.00

Oracle8i v8.1.5

7


550 (48 x 4-way nodes)

19,137.5

10,661.5

14,284.10

797.00

DB2 UDB 5.2.0

. 27 .

8


24-way nodes )

12,931.9

5,850.3

8,698.00

1,353.00


AD/XP 8.21

Database Size 3TBDatabase Size 3TBDatabase Size 3TBDatabase Size 3TB

Position

TPC-D Power

Qppd

QthD

QphD

$/QphD

Database

1


x 4-way nodes)

431,349.7

15,580.5

81,979.40

313.00

Teradata V2R3.0

2


x 4-way nodes)

14,446.0

2,938.9

6,515.80

2,284.00

Teradata V2R2.1

Position

TPC-D Throughput

Qppd

QthD

QphD

$/QphD

Database

1


x 4-way nodes)

431,349.7

15,580.5

81,979.40

313.00

Teradata V2R3.0

2


x 4-way nodes)

14,446.0

2,938.9

6,515.80

2,284.00

Teradata V2R2.1

. 28 .

Position Price/Performance Qppd QthD QphD $/QphD Database

1


x 4-way nodes)

431,349.7

15,580.5

81,979.40

313.00

Teradata V2R3.0

2


x 4-way nodes)

14,446.0

2,938.9

6,515.80

2,284.00

Teradata V2R2.1

(数据来源：http://www.ideasinternational.com/benchmark/tpc/tpcd. html )

1.7.21.7.21.7.21.7.2 TPC-H/R

TPC-H和TPC-R是1999年4月提出来决策支持应用测试标准，以代替原来的

TPC-D。TPC-H用于随机动态查询(ad-hoc)，用户事先不知道查询，数据库管理员

不能为查询优化系统。TPC-R用于业务报表，事先知道查询，数据库管理员能够

为查询优化系统。TPC-H和TPC-R采用与TPC-D相同的数据模型，以及绝大部分

相同的查询，另外又增加了6个新的查询。这两个基准测试的目的是弥补 TPC-D某

些非常明显的漏洞(例如TPC-D只做只有一个用户的基准测试)。

TPC-H的数据指标包括：

! QphH(Query-per-Hour H)

. 29 .

这个数据指标描述了系统的复杂查询处理能力。(H表示这个结果是按

照TPC-H标准测得的，下同)

! $/QphH (Price/Query-per-Hour H)

价格/性能。

TPC-R的数据指标包括：

! QphR(Query-per-Hour R)

这个数据指标描述了系统的复杂查询处理能力。(R表示这个结果是按

照TPC-R标准测得的，下同)

! $/QphR (Price/Query-per-Hour R)

价格/性能。

显然，前面的指标的数据越大越好，而后面的指标则越小越好。

TPC-H和TPC-R是一个复杂的测试过程，其原始数据量也分成100GB、

300GB、1000GB、3000GB多个层次。每个数据仓库供应厂商都有一个小组，专

门进行TPC-H或者TPC-R的测试。NCR是目前唯一一个公布1TB级TPC-R测试结

果的厂商。

. 30 .

下面列出了主要的TPC-H/TPC-R测试结果，这些结果可以从TPC网站

(http://www.tpc.org)下载。

TPC-H，1TB测试结果

Company System QphH Price/QphH Database Date

Submitted

HP HP 9000 Superdome

Enterprise Server

9754 985US$ Informix XPS 8.31FD1 2001-02-13

IBM RS/6000 SP 550 12866 725US$ IBM DB2 UDB 7.1 2000-04-27

NCR WorldMark 5250 18542 693US$ Teradata V2R4.1 2001-05-07

Sun Sun Fire 6800 4529 802US$ IBM DB2 UDB EEE 7.2 2001-05-10

TPC-H，3TB测试结果

Company System QphH Price/QphH Database Date Submitted

NCR WorldMark 5250 18803 999US$ Teradata V2R4.1 2001-05-07

Sun Sun Starfire

Enterprise 10000

10764 1250US$ Oracle9i Database Ent.

Edition 9.0.1

2001-04-13

TPC-R，1TB测试结果

. 31 .

Company System QphR Price/QphR Database Date Submitted

NCR WorldMark 5200 21254 607US$ NCR Teradata V2R4.0 2000-03-6

NCR WorldMark 5200 17529 737US$ NCR Teradata V2R3.0 1999-08-23

1.81.81.81.8 NCR可扩展数据仓库方法论与实施框架可扩展数据仓库方法论与实施框架可扩展数据仓库方法论与实施框架可扩展数据仓库方法论与实施框架

“数据仓库是一个过程，而不是一个产品”。因此数据仓库的建设与传统的

OLTP系统的开发有很大的区别，实施一个数据仓库必须要有经验丰富的合作伙伴

的帮助和进行精心的规划。NCR公司已帮助各行各业的用户成功实施数据仓库应

用(包括世界上最大的几十个数据仓库系统)的时间已经超过15年，在数据仓库建设

方面积累了丰富的经验，并且形成了一套完整的、行之有效的数据仓库方法论和实

施框架，为了区别于其它系统，这套理论被称为可扩展数据仓库(Scalable Data

Warehouse，简称为SDW)。

1.8.11.8.11.8.11.8.1 NCR可扩展数据仓库方法论可扩展数据仓库方法论可扩展数据仓库方法论可扩展数据仓库方法论

整个数据仓库的实施过程可以用图1-5所示的循环图来表示，这也是NCR可扩

展数据仓库的基本方法论。

. 32 .

( )

图1-5 NCR可扩展数据数据仓库方法论

从图中可以看出，一个数据仓库系统的建设可以分成三个阶段，即数据仓库的

规划、数据仓库的设计与实施、和数据仓库的支持与完善。下面简单介绍一下在各

阶段所提供的主要服务：

. 33 .

数据仓库的规划数据仓库的规划数据仓库的规划数据仓库的规划

这一阶段包括以下内容：

业务探索：着重于和企业的有关业务部门共同分析并确定决策支持系统中要解

决的关键业务问题，对最后的目标达成共识。对这些问题要按优先级分类，分类原

则是它们对企业业务的影响和解决后所带来的利益。

信息采集与挖掘：对需求分析作进一步的精炼，一旦确定下来，就可以建立相

应的数据模型，使企业看到如何把数据转变成有用的信息，以及如何与关键业务问

题联系起来。当然，在这一阶段建立的模型是比较高层、比较粗略的，着重于业务

需求，为下一步作技术上的进一步细化处理打下基础。

数据仓库工作室：根据前面得到的信息建立一个适用于企业具体业务的数据仓

库工作室，对业务人员、技术人员和操作人员进行实际的培训，使有关人员进一步

了解数据仓库开发的全过程。

数据仓库逻辑建模：针对一个业务问题建立完整的逻辑模型，包括各个表的属

性，表与表之间的相互关系等。一个好的逻辑模型对系统的物理实施和今后的维护

都是非常重要的。用来进行建模的工具很多，较常用的有LogicWorks的ERwin

等。

. 34 .

数据仓库结构设计：根据企业的业务环境设计数据仓库的整体结构，确定数据

仓库的位置(集中式或分布式)、网络需求、用户访问数据仓库的方式等。

数据仓库的设计与实施数据仓库的设计与实施数据仓库的设计与实施数据仓库的设计与实施

这一阶段包括以下内容：

数据仓库解决方案就绪：对企业实施数据仓库的环境和各项条件作全面的评

估，它包括五项内容：1、技术评估：主要考察实施数据仓库的各项技术条件是否

满足，对现有的硬件、软件和网络环境作出评估，并确定有关远程数据访问、数据

共享、备份/重启/恢复等方面的需求。2、数据评估：确定现有的数据结构和数据特

征是否满足数据仓库的需要。3、功能评估：从技术和业务两方面来考虑数据仓库

开发的全过程，以确保所提出的方案能为企业的有关决策人员提供帮助。4、培训

评估：对企业数据仓库解决方案的项目参加人员和最终用户进行有关培训内容的评

估，以便配合当前环境进行决策支持系统的实施和集成。5、支持与服务评估：确

定企业在数据仓库系统投入运行后在支持与培训方面的需求，以充分发挥系统的作

用，提高可用性，从而保证用户的满意。

知识探索建模：所谓知识探索或者信息挖掘是基于数据仓库进行的，主要用来

给分析人员建立预测模型，因为有些问题不能直接从现有数据中找到答案。当传统

. 35 .

的数据访问工具(如SQL或其它OLAP工具)不能回答有关业务问题时，就必须开发

相应的预测模型。

数据挖掘与分析工具：根据前面定义的业务需求，我们将选择最合适的数据挖

掘与分析工具，针对已有数据运行这些工具并检测结果的准确性。

数据仓库物理模型设计：根据所建议的数据仓库方案计划、逻辑模型以及整体

结构，结合企业的现有环境，设计一个最优的物理模型。主要内容是：利用ERwin

这类工具将逻辑模型转换成物理模型；生成数据库；设计优化处理方法；对数据库

进行功能测试。

Client/Server应用开发：这一阶段的服务分成设计与实施两方面。设计内容包

括查询界面的确定以及特定应用的设计，和企业有关技术人员一起进行这些应用系

统完整的原型设计。然后根据原型定义、所选用的工具等进行下一步的实施。对于

数据仓库方案而言，其应用系统应能支持预先定义好的查询和随机查询。

数据转换：设计一个数据转换方案，把企业的已有数据和OLTP系统的数据按

照一定的原则转换并加载到数据仓库中。转换过程中将对数据进行清理、分类、提

取等操作，以保证数据的一致性和有效性。

数据仓库管理：提供一套完整的管理方法，以便更有效地管理数据仓库系统的

各个环节。主要三方面的内容：1、数据维护，指数据的更新、加载、备份、存

档、管理和还原，保证数据的一致性和兼容性；2、开发一些专用过程用于软件版

. 36 .

本的控制、硬件和软件的维护、错误报告方式等日常维护工作；3、操作管理，开

发一些专用过程用于操作的管理，如硬件和软件的升级、报告的记录、设计预防性

的维护方案等。

数据仓库的支持与完数据仓库的支持与完数据仓库的支持与完数据仓库的支持与完善善善善

这一阶段着重于数据仓库的维护和今后的进一步扩展，根据NCR公司实施数

据仓库的经验，其容量和用户会在投产后迅速增加。因此，数据仓库的实施是一个

循环的过程。这一部分的主要内容是：

企业系统支持：为企业提供全面的系统支持，如数据库、工具、应用程序、硬

件平台等，从而提高系统的可用性。

数据仓库逻辑模型回顾：在数据仓库投产后，随着企业业务的迅速扩展，可能

提出新的业务需求，这时需要对原来的逻辑模型进行扩展和调整，以进一步完善数

据仓库逻辑模型，解决新的业务问题。

数据仓库物理模型回顾：在上一步的基础上，将对数据仓库物理模型作相应的

扩展和调整。NCR将基于丰富的数据仓库设计和构建经验，和企业相关部门的用

户一起研究新的需求和设计方案，并进行分析，然后提出改进建议。

. 37 .

数据仓库调试：当企业中的应用程序或网络发生变化时，有可能导致一些数据

仓库的性能问题。此时应提供数据仓库调试服务，通过细致的分析找到问题所在。

这项分析覆盖网络、应用程序、用户、数据库结构、系统使用和其它相关领域。一

旦分析完成，应提出解决性能问题的建议。

数据仓库容量规划：随着企业业务的发展，数据量会逐渐增加，将会面临数据

仓库扩充的问题。供应商必须帮助客户来规划数据仓库的扩充。扩充可能包括额外

的应用程序、用户、数据、远程访问和操作等等。任何一种以上的扩充都可能会影

响现有数据仓库的容量和性能，所以提前计划将会减小对用户工作的影响。

数据仓库审计：数据仓库审计服务先评估目前企业数据仓库的使用情况，帮助

客户确定现有数据仓库的商业价值，然后提出改进措施来使数据仓库发挥出最大的

商业价值。评估领域包括数据仓库的灵活性和可扩充性、数据一致性、用户访问程

度、第三方数据提取工具的使用等等。

1.8.21.8.21.8.21.8.2 NCR可扩展数据仓库框架可扩展数据仓库框架可扩展数据仓库框架可扩展数据仓库框架

我们知道，数据仓库是一个发展迅速的市场，长期以来，NCR公司在这方面

做了许多开创性的工作，帮助许多国际公司和机构成功实施了数据仓库系统。因

. 38 .

此，NCR公司在数据仓库的分析、设计、实施、完善等方面具有丰富的经验。其

可扩展数据仓库解决方案的基本框架可以用图1-6来表示。

提提提提提提提提过过过过过过过过净净净净净净净净家家家家家家家家家家家家生生生生家家家家家家家家加加加加加加加加

Objects &Languages

数数数数数数数数数数数数加加加加

数数数数数数数数数数数数详详详详

信信信信信信信信信信信信信信信信

IT 面面面面客客客客

数数数数数数数数操操操操操操操操

/ 操操操操操操操操数数数数数数数数源源源源数数数数数数数数

企企企企企企企企中中中中中中中中数数数数数数数数数数数数数数数数

从从从从从从从从数数数数数数数数集集集集市市市市

复复复复复复复复复复复复复复复复复复复复

企企企企财财财财面面面面客客客客

数数数数数数数数数数数数数数数数

信信信信信信信信信信信信提提提提信信信信信信信信

分分分分类类类类生生生生统统统统人人人人信信信信人人人人人人人人决决决决决决决决决决决决

NCR 可可可可可可可可可可可可数数数数数数数数数数数数数数数数可可可可可可可可

. 39 .

图1-6 NCR可扩展数据仓库框架结构

从上图可以看出，整个框架主要分成三个部分：

" 数据装载数据装载数据装载数据装载：把所谓的操作数据或源数据利用一定的方法如提取(Extract)、过滤

(Filter)、清理(Scrub)、家庭关系识别(Household)等，从生产系统中转换到

中央数据仓库中。这种转换分成逻辑与物理两部分，即先根据业务问题建立数

据库逻辑模型，然后在此基础上构造物理模型，将操作数据加载到物理表中。

逻辑建模应该基于要解决的业务问题进行，而不是基于目前的系统能提供什么

数据进行。换言之，数据仓库的出发点是解决业务问题，而不只是单纯提供一

个信息转换与访问的工具。

" 数据管理数据管理数据管理数据管理：这一部分是整个数据仓库的心脏，根据数据仓库的特点，它必须采

用一个具有优良并行处理性能的关系数据库管理系统。当数据仓库非常庞大而

且复杂时，为了提高性能，可以建立一些面向部门应用的数据集市，这些数据

集市中的数据是从中央库中通过复制与传送等手段拷贝过来的。

. 40 .

" 信息访问信息访问信息访问信息访问：这一部分是前端工具，主要提供给有关业务部门访问数据仓库中的

信息使用，在这一部分一般都采用一些具有图形界面、交互功能强的查询工

具。

1.8.31.8.31.8.31.8.3 NCR可扩展数据仓库合作伙伴可扩展数据仓库合作伙伴可扩展数据仓库合作伙伴可扩展数据仓库合作伙伴

从前面的讨论不难理解这样的概念：即数据仓库不是一个现成的产品，而是一

个综合的解决企业复杂业务问题的过程，是一个集成的系统。在这个系统中，牵涉

到许多的环节，在每个环节都需要一些特定的软件工具来协助完成。NCR公司和

许多在各自领域处于领先地位的工具厂商具有良好的合作伙伴关系，共同来开发数

据仓库方面的应用。图1-7简单地描述了NCR在数据仓库各个环节上的一些合作伙

伴。

. 41 .

数数数数数数数数操操操操操操操操

企企企企企企企企数数数数数数数数数数数数数数数数信信信信信信信信

知知知知家家家家知知知知知知知知数数数数数数数数数数数数数数数数

● ETI● Prism● Apertus/Carleton

● SAS Institute● ID Centric

● BEZ

● Angoss● SABRE Decision Technologies● ISL*

● KD1● Quadstone● SAS

操操操操操操操操数数数数数数数数

家生类 OLAP● Platinum -InfoBeacon● Information

Advantage● MicroStrategy

OLAP/ 客客客客客客客客客客客客客客客客客客客客 & 报报报报报报报报● Platinum● Cognos● Andyne● Brio Technologies● Information Builders● SAS Institute● Seagate/Holistic● Business Objects● Software AG● White Light*● Aonix

面面面面面面面面 Campaign Management● Prime Response*● Exchange

SAS Applications● CFO Vision● HR Vision

Retail Partners● Stirling Douglass● Intrepid● RTMS

OLAP 信信信信信信信信

客客客客客客客客复复复复报报报报报报报报

面面面面面面面面

数数数数数数数数集集集集市市市市

● Microsoft● SAS Institute

● Synectics● Trillium

多多数数数● Pilot● SAS Institute● Broadbase

图1-7 NCR在数据仓库领域的合作伙伴

. 42 .

第二章第二章第二章第二章 Teradata关系型数据库管理系统概要关系型数据库管理系统概要关系型数据库管理系统概要关系型数据库管理系统概要

2.12.12.12.1 Teradata数据库的设计思想数据库的设计思想数据库的设计思想数据库的设计思想

Teradata数据库的设计思想源于这样朴素和简单的逻辑：无论计算机CPU发展

如何迅速，每个CPU的能力都是有限的，单台计算机在扩充时也很容易达到其上

限。因此，当一个任务非常复杂，需要耗费系统大量资源和执行时间时，如果能有

多台计算机共同执行任务，并且如果能把任务分解成许多小的而且简单的子任务，

并均衡地分派到多台计算机的多个CPU上，就有可能极大地提高整个系统的性能，

极大地缩短完成任务的时间。当然，如何协调各计算机系统中的各个CPU，使之协

同工作，也是要解决的关键技术问题之一。

为了实现这一朴素的设计理念，Teradata数据库的发明者们经过多年努力，终

于在1984年推出了适于大量数据的综合分析与处理的数据库软硬件平台Teradatat和

DBC，并将它们交付给包括Wal*Mart、AT&T、花旗银行(CityBank)、和K-Mart等

客户使用，取得了非常满意的效果。

. 43 .

2.22.22.22.2 Teradata数据库的体系结构数据库的体系结构数据库的体系结构数据库的体系结构

Teradata数据库在设计上和实现上遵从非共享(share nothing)的体系结构。

Teradata数据库自发明至今已经经历了许多重大转变，已经从版本1(Teradata V1)发

展到了目前的版本2(Teradata V2R4)，运行平台也已经从封闭的专用系统转变到了

开放的通用系统，但是最基本的体系结构是一致的，始终遵从非共享原则。

2.2.12.2.12.2.12.2.1 Teradata V1/DBC体系结构体系结构体系结构体系结构

1984年首次推出的Teradata V1数据库是在一台称之为“数据库计算机”的

DBC/1012上实现的，其体系结构如图2-1所示：

. 44 .

(IBM, Bull, Unisys )封封面封生生封

IFPIFP

YNET B

AMP AMP AMP AMP

DSU DSUDSUDSU

通通通通通通通通

通通通面会会会复 SQL 分分任财任任 YNET 通面

DBC

YNET A

TDP CLI 程序CLI 程序

终客

TDP: Teradata (Teradata Director Program) IFP: (Interface Processor)指指程序指指详详指

AMP: (Access ModuleProcessor)信提存存详详指 DSU: (Disk Storage Unit)磁磁信储磁磁

图2-1 Teradata V1体系结构(通道连接)

. 45 .

从上图来看，当时的Teradata数据库系统是以通道方式与大型封闭主机进行连

接，把大型封闭主机中的OLTP系统的历史数据提取过来进行分析和处理。

用户通过终端或直接从主机本身编写应用程序，编程界面为调用层接口CLI。

在封闭主机上有一个Teradata指引程序TDP，它将所有用户提交的交易请求进行打

包处理，然后传递到相应的接口处理器IFP。

IFP主要负责提供与主机的接口、会话层的控制、SQL的分解与任务调度、输

入数据转换以及与YNET的接口。它从TDP中收到信息包后，从中分解出具体的交

易请求，并对SQL语句进行优化处理，然后分解成多个子任务，最后把这些信息透

过YNET广播。

各个存取模块处理器AMP从YNET的广播信息中获取指令，到自己负责的磁盘

存储单元中进行相应的数据库操作，返回结果通过YNET汇总，最后回馈给前端用

户。

这里特别要注意的是，各个AMP的操作彼此独立，是一种逻辑上完全非共享

结构。这种松散耦合系统就是早期的海量并行处理机器。

当时的Teradata数据库系统仍是一种专用机器，其主要部件如IFP、AMP等都是

由硬件实现的，操作系统为TOS(Teradata Operating System)也是专用的。因此，在

. 46 .

出现后来的开放系统版本后，我们把原来的专用系统称为Teradata第一版：Teradata

V1。

随着Client/Server应用模式的出现，Teradata数据库系统进一步提供了通过LAN

的连接方式。这是通过在系统中增加一个新的通讯处理器COP(COmmunication

Processor)而实现的。此时Teradata数据库系统可以用图2-2来表示：

. 47 .

IFP IFP

YNET B

AMP AMP AMP AMP

DSU DSUDSUDSU


DBC

YNET A

终客

TDP: Teradata (Teradata Director Program) IFP: (Interface Processor)指指程序指指详详指

AMP: (Access ModuleProcessor)信提存存详详指 DSU: (Disk Storage Unit)磁磁信储磁磁

封封面封生生

TDP

CLI 程序

COP COP

PC 、信操、封

MTDP

CLI 程序

LAN

图2-2 Teradata V1体系结构(通道与LAN连接)

. 48 .

对应于封闭主机上的TDP，在PC、工作站等前端机器上有一个MTDP(Micro

TDP)，其作用和TDP是相同的。对Teradata而言，每一个LAN就是一个相应的主机

系统，在作系统配置时对应一个主机标识号(HOSTID)。

2.2.22.2.22.2.22.2.2 Teradata V1/NCR 3600体系结构体系结构体系结构体系结构

Teradata的设计和实现使得它具有非常强的并行处理能力。另一方面，它也具

有非常好的线性扩展能力，也就是说，当增加系统中的相应部件时，系统的整体性

能呈线性上升状态。举例来说，如果增加IFP或COP，则允许更多的用户同时访问

系统；如果增加AMP，则增加了系统的交易处理速度；如果增加磁盘，则允许存

储更多的数据。所以，当系统的数据量越来越多，或者并发用户数成倍增加时，处

理速度将会变慢，这时就可以考虑增加AMP以提供相同或更好的性能。

由于Teradata卓越的并行处理能力和线性扩展能力，它迅速占领了大型数据库

市场，许多国际大企业纷纷采用Teradata来构造其信息处理系统或者数据仓库。在

使用过程多中，其封闭的缺点开始逐渐暴露出来。最主要的问题在于缺少磁带等外

存设备，而增加这种设备又非常困难。

. 49 .

最初数据的备份是通过通道与封闭主机连接后，由主机的外存设备进行的。随

着数据量的增加，备份工作将占用主机很多资源。因此，需要把备份工作移到

Teradata数据库系统上进行，这就必须在系统中增加相应的磁带等外存设备。

Teradata公司并入NCR后，所作的一个非常重要的决策就是将Teradata数据库逐

步移植到UNIX平台。最早的一个产品是在1991年推出的NCR 3600海量并行处理

(MPP)计算机。作为DBC专用系统的升级换代产品，3600在许多功能方面都有了显

著的增强。整个系统由多个结点通过YNET联结而成一个MPP系统，而每个结点就

是一个处理能力很强的运行UNIX操作系统的SMP结点，既可以运行一般的应用，

也可以运行基于Teradata的数据库应用。这样的SMP节点在3600中被称为应用处理

器AP(Application Processor)。NCR 3600系统的体系结构如图2-3所示：

. 50 .

AP AP

YNET B


3600

YNET A

终客

AP: (Application Processor) 面面详详指 PE: (Parsing Engine)分分指分

AMP: (Access ModuleProcessor)信提存存详详指

封封面封生生

TDP

CLI 程序

AP AP

PC 、信操、封

MTDP

CLI 程序

PEPE AMP AMP AMP AMP

通通通面 LAN 通面

LAN

磁磁磁序

图2-3 NCR 3600 Teradata V1体系结构

. 51 .

AP直接与YNET相连，每个AP也负责处理所有与外界的接口。因此，IFP和

COP不再用来实现Teradata与外界的连接。但IFP和COP中的一些其它功能被保留下

来，并被转换到一个称为分析引擎PE(Parsing Engine)的新处理器中。PE主要负责

会话层控制(Session Control)、任务的分配、SQL语法的分析、分解与优化等任务。

由于AP是一个运行UNIX操作系统的SMP节点，对外设的管理和扩充都很方

便，可选外设的种类也非常多，因此，Teradata数据库系统不必再象以前那样只能

使用封闭主机的外设。另外我们也看到，在3600中还有一个显著的改进，就是用更

为通用和可靠的磁盘阵列(Disk Array)代替了原来专用的存储单元。利用RAID 技

术，使整个系统在安全性和高可用性等方面有了很大的提高。NCR 3600系统的逻

辑结构可以用图2-4来表示：

. 52 .

NPGS 通通通通程序

YNET

MTDP Telnet/Ethernet TDP

面面程序

PC/ 信操、封封面封

DISK

AP

PE

AMP

UNIX SVR4-RAS

TOS

TOS

PC/ 信操、

面面程序面面程序

面面程序

图2-4 NCR 3600 Teradata V1逻辑结构

. 53 .

从图中可以看到，PE和AMP仍然是一种专用部件，它们都由硬件实现，基于

TOS来运行。因此，如果从运行Teradata数据库的角度来看，3600仍然是一种专用

的数据分析和处理系统。如果不运行Teradata数据库，而只运行Oracle或Sybase等商

用数据库，则3600完全是一种开放系统。

通过上面的讨论，AP的主要功能和特点可以总结如下：

! SMP结点，结点内紧耦合(结点间松耦合)；

! 基于 UNIX操作系统，可以运行一般的应用；

! 支持各种 Database工具；

! 与封闭主机通过通道相连，由通道驱动程序(Channel Driver)驱动；

! 与工作站或 PC通过 LAN相连，由 NPGS(Network Protocol/Gateway

Software：网络协议/网关软件)来驱动；

! 与 UNIX Client通过消息队列、信号灯等机制进行信息交互；

! 提供 YNET驱动程序，使 AP透过 YNET与 PE进行信息交互。

YNET

在Teradata数据库的并行处理中，YNET起着非常重要的作用。这是Teradata发

明的一种智能、高速的节点互连技术，它的基本结构可以用图2-5来表示。

. 54 .

Ynet - BYnet - A

DSU

IFP1

IFP2

COP1

COP2

AMP1

AMP2

AMP3

AMP4

LAN 封封面封

PC/ 信操、封

DSU DSU DSU

图2-5 YNET基本结构

. 55 .

由图可知，YNET是一种倒Y结构的结点互连方式，这也是YNET的得名由来。

任何两个处理器之间都是两两互连的，因此，如果增加一个处理器，带宽也将线性

增加。这就是Teradata具有线性可扩展特点的奥秘所在。

Teradata数据库系统中同时有两个YNET网络，称为YNET A和YNET B，以全

双工方式运行，同时两者互为备份。因此在结点互连这一层次上，系统具有高可用

性。

分析引擎分析引擎分析引擎分析引擎PE和存取模和存取模和存取模和存取模块处理器块处理器块处理器块处理器AMP

在NCR 3600 Teradata数据库系统中，分析引擎PE取代了早期产品DBC中的 IFP

和COP，合并了两者的功能。但不一样的是，PE只和YNET进行信息交互，而不直

接与外部主机和工作站打交道。每个PE都具有自己的TOS、会话层控制软件、分解

器、调度器和YNET接口程序。

数据库中的所有记录是通过存取模块处理器AMP进行存取操作的，AMP中的

数据库管理软件实现了关系数据库管理系统的主要功能。Teradata数据库的数据分

配机制是哈希(Hashing)算法，它使得数据能均匀地分配到各个AMP所负责的存储

单元中，而每个AMP只负责它自己管理的一部分存储单元的数据库操作。另外，

各个AMP能通过YNET的协调实现并行处理。这样，当一个非常复杂的任务被分析

. 56 .

引擎PE分解成许多简单的子任务，这些简单的子任务又被YNET传给AMP时，所有

AMP同时工作，而每个AMP只完成与它自己有关的部分并返回结果。因此Teradata

数据库在处理决策支持系统中的复杂查询、动态查询等问题时具有非常快的响应速

度。

PE和AMP的主要功能可以用图2-6来描述。

. 57 .

AMP 数数数数数数数数数数数数数数数数

详详详详理理理理理理理理

Disk Cache RAM

Disk I/O

TOS

DSU

PE

会会会会会会会会会会会会复复复复分分分分分分分分指指指指任任任任任任任任指指指指

TOS

Ynet 指指指指指指指指

Ynet

AP

/ NPGS网网网网网网网网网网网网网网网网网网网网家家家家理理理理理理理理

Ynet Drivers Channel Driver 封封封封封封封封面面面面封封封封

UNIX SVR4-RAS

TCP/IP

Teradata 面面程序

Ynet 指指指指指指指指

图2-6 PE与AMP逻辑结构

. 58 .

2.2.32.2.32.2.32.2.3 开放的开放的开放的开放的Teradata V2/SMP体系结构体系结构体系结构体系结构

虽然NCR 3600数据库系统向开放系统迈进了一大步，但它的PE和AMP仍然由

硬件实现，并且运行专有的操作系统软件TOS。为了更好地走向开放平台，NCR公

司决定完全摒弃原来的专用部件，这样一方面可以降低成本，另一方面也将使系统

的配置变得更加灵活。

从1993年开始，NCR公司组织了专门的开发小组，在UNIX操作系统上重写了

TOS，在UNIX核心上增加了一个称之为并行数据库扩展(PDE: Parallel Database

Extension)的并行处理环境。1995年初NCR公司推出了完全基于UNIX开放平台的

Teradata数据库系统。这时的Teradata数据库已经是一个纯软件产品，原先由硬件实

现的AMP和PE现在完全由软件实现，称之为虚拟处理器(VPROC，Virtual

Processors)。为了和早期的专用系统相区别，纯软件方式的Teradata数据库被称为

Teradata第二版(Teradata V2)，而原来的专用系统被称为Teradata第一版(Teradata

V1)。由于Teradata数据库被引入国内的时间较晚，已没有机会使用Teradata V1产

品，因此在本书的叙述中，除特别申明，所说的Teradata数据库就是指Teradata V2

产品。

第一个Teradata V2数据库是在一个运行UNIX的SMP节点上实现的，其体系结

构如图2-7所示：

. 59 .

通通通通信信信信通通通通面面面面 AMP

分分分分分分分分指指指指分分分分PE

PE1

PE2

AMP1

AMP2

AMP4

AMP3

网网网网家家家家


SMP磁磁磁磁详详详详单单单单

UNIXPDE ( )并并并并并并并并数数数数数数数数数数数数可可可可可可可可并并并并并并并并

TCP/IP

封封封封封封封封面面面面封封封封生生生生生生生生

VNET

磁磁磁磁磁磁磁磁磁磁磁磁序序序序

图2-7 Teradata V2单节点SMP体系结构

从图2-7中可以看到，Teradata数据库系统与外界的接口有以下两种：

! 网关(Gateway)：所有支持 TCP/IP协议的计算机可以通过网关与 Teradata相

联，其交易请求和处理结果都是通过网关进行交互的。

. 60 .

! 通道(Channel)：对于一些封闭主机系统(Mainframe)，Teradata提供了一种

通道直连的方式进行信息的交互，即与主机的通道直接联接，速度非常

快。

交易请求通过网关或通道进入系统后，将传递给分析引擎PE。PE主要由分解

器(Parser)、优化器(Optimizer)、会话层控制(Session Control)和调度器(Dispatcher) 组

成，其逻辑结构如图2-8所示。

分分分分分分分分指指指指

P D E

任任任任任任任任指指指指

U N IX S V R 4 M P -R A S{ 代代T O S

优优优优净净净净指指指指

会会会会会会会会会会会会会会会会复复复复

图2-8 Virtual PE的逻辑结构

. 61 .

分解器(Parser)将接收到的SQL语句利用优化器分解成相关的数据操作步(AMP

Steps)，这些AMP步被传送给负责任务调度与派送的调度器，它再把这些AMP步传

给相应的虚拟AMP进行处理。

经PE处理的交易请求通过一个高速的信息传递层即VNET传至存取模块单元

AMP。AMP控制所有与数据库有关的操作，其逻辑结构如图2-9所示。

家家家家生生生生数数数数数数数数数数数数数数数数详详详详

P D E

/ 文文文文理理理理生生生生生生生生数数数数数数数数数数数数详详详详

U N IX S V R 4 M P -R A S{ 代代T O S

图2-9 Virtual AMP的逻辑结构

每个AMP只负载磁盘阵列的一部分磁盘，数据的分配是利用HASH机制经过

AMP均匀分布到各磁盘上的。因此，数据库中一个表的各条记录可能分布在不同

的磁盘上。这个过程完全自动进行，而对一般商用OLTP数据库来说，这个过程主

. 62 .

要是由DBA控制的。各个AMP并行处理，互不相关，交易处理结果在信息传递层

汇总后，直接返回给应用程序。

节点内的并行处理功能是通过一个模拟YNET的虚拟网络VNET实现的。在

Teradata V2数据库系统中，PE和AMP均是由软件实现的虚拟处理器VPROC。一个

VPROC实际上是由一组UNIX进程组成的，相互之间通过共享内存交换信息。

VNET在作信息交互时并不真正地将数据本身作移动，而是通过改变内存段的属主

(Owner)来实现，这样速度极快。任何时刻一个内存段只属于一个VPROC。VNET

与PE和AMP虚拟处理器VPROC的信息交互如图2-10所示：

. 63 .

写写写写操操操操操操操操

AMP1

AMP2PE1

内内内内信信信信

AMP3

读读读读操操操操操操操操

VNet

PE 1 PE 2

AMP 1 AMP 2 AMP 3 AMP 4

DiskR1, R4, R9

DiskR5, R2, R10

DiskR7, R3, R11

DiskR4, R8, R12

VNET

图2-10 VNET与VPROC的信息交互

. 64 .

从图2-8和2-9中可以看出，PE和AMP虚拟处理器与原来由硬件实现的相应处理

器的功能是基本相同的。另外，每种VPROC的个数可以根据系统与负载的实际情

况进行动态配置，这使得Teradata V2变得更加灵活和易于管理。

2.2.42.2.42.2.42.2.4 Teradata V2/MPP体系结构体系结构体系结构体系结构

以上简要介绍了Teradata V2数据库在一个SMP节点上的体系结构。NCR公司于

1996年初推出了全开放的WorldMark 5100系列海量并行处理计算机后，进一步实现

了Teradata V2数据库对MPP平台的支持。5100采用了一种称为通用节点(Common

Node)的技术，可以很方便地从5100S(单结点SMP系统)升级到5100M(多结点海量并

行处理系统)。举例来说，如果原有一台5100S计算机，当系统负载过重、处理能力

下降时，可以增加相同或类似的结点，与原来的结点通过一种性能比YNET更强的

BYNET网络组合成一个MPP系统，从而实现系统的线性扩展。

图2-11表示了一个基于NCR WorldMark系列MPP 计算机通用节点的Teradata V2

多节点MPP体系结构。

. 65 .

SMP 节节节节单单单单












(Clique)簇 (Clique)簇 (Clique)簇

BYNET

图2-11 Teradata V2多节点MMP体系结构

在每一个节点中，Teradata数据库依然保持Teradata V2/SMP体系结构。

NCR WorldMark系列系列系列系列MPP计算机计算机计算机计算机

WorldMark 5100系列计算机采用微通道总线结构。1997年底NCR公司推出了

基于PCI总线结构的WorldMark 4700/5150系列计算机。4700/5150系列计算机的每个

节点采用4个Intel Pentium Pro 200MHz CPU，4700和5150系列计算机所采用的结点

是相同的，唯一的区别是BYNET的扩展能力不一样。4700最多可以扩充到8个结

点，而5150则最多可以扩展到128个结点。换言之，当4700系统已经扩展到8个结点

. 66 .

后，如果需要继续扩充，则更换其中的BYNET网络，增加相应的5150结点，原

4700 MPP平台就变成了5150 MPP平台了。

NCR公司于1998年底推出了WorldMark 4800/5200系列计算机。4800/5200系列

计算机的每个节点采用4个Intel Pentium III Xeon 450MHz(后增强为550MHz)CPU，

单节点系统性能比同档4700/5150系列计算机提升2倍。4800最多可以扩展到4个节

点，而5200最多可以扩展到512个结点。与此同时，NCR公司投入专门的人力和物

力，将Teradata数据库系统从UNIX平台移植到日趋流行和成熟的Windows NT平

台，并于1999年4月发布了正式商业化的Teradata for Windows NT数据库版本。因

此，4800/5200系列计算机除继续支持NCR UNIX PM-RAS操作系统之上的Teradata

数据库应用以外，4800 MPP系统还增加了对Microsoft NT操作系统之上的Teradata

数据库的支持，这也是业界第一个NT平台的4节点MPP版本的数据库系统。

2000年4月，NCR公司推出了WorldMark 4850/5250系列计算机，用以支持于

2000年3月发布的海量并行处理Teradata数据库(V2R4)。WorldMark 4850/5250系列

计算机的每个节点采用4个Intel Pentium III Xeon 700MHz CPU，单节点系统性能比

同档4800/5200系列计算机提升25%。4800最多可以扩展到4个节点，而5200最多可

以扩展到512个结点。为使广大数据仓库的潜在用户有更大的选择余地，4850/5250

系列计算机除继续支持NCR UNIX PM-RAS操作系统之上的Teradata数据库应用，

4850 MPP系统继续支持Microsoft NT操作系统之上的Teradata数据库应用以外，

4850/5250系列计算机还进一步增加了对Winsows 2000操作系统之上的Teradata数据

. 67 .

库的支持，而且支持的节点数已达64个！这同样也是业界第一个如此大规模的

Windows平台的MPP版本的数据库系统。

2001年5月，NCR公司推出了WorldMark 4855/5255系列计算机。WorldMark

4855/5255系列计算机的每个节点采用4个Intel Pentium 900MHz CPU，性能比

4850/5250又有了很大提升。4855最多可以扩展到4个节点，而5255最多可以扩展到

512个结点。

图2-12是WorldMark 48xx/52xx系列计算机一个机柜的外形图。

. 68 .

图2-12 WorldMark 48xx/52xx外形图

. 69 .

图中最下面是三个冗余的UPS，为整个机柜供电。中间部分用来安置两个SMP

节点，最上面是两个BYNET模块和服务器管理模块SMC (Server Management

Chasis)。

当一个MPP系统中结点很多时，如何对整个系统进行管理呢？这是通过一个称

为AWS(Administration Workstation)的管理工作站来实现的。AWS是一台单独的小

型服务器，它利用内部网络与每个机柜的服务器管理模块SMC相连。SMC存在于

每个机柜中，与机柜内所有模块都有连接，将各模块信息收集起来汇总到AWS

上，包括磁盘阵列柜也可以通过SMC连接到AWS上。这样，通过AWS可以方便地

监控和管理整个系统。如图2-13所示。

. 70 .

1440 Disk Array

1440 Disk Array

M-LAN Loop

M-LAN Loop

CarsonChassis

CMIC2

AWS

S-LAN

UPS Chassis

UPS Chassis

P-LANHUB

UPS Chassis

UPS Chassis

UPS Chassis

Chassis ManagementBoards

Server ManagementChassis (3U)

ProcessingNode Chassis

BYNET Chassis

BYNET Chassis

ProcessingNode Chassis

NodeCabinetNCR Disk Cabinet

S-LAN

Server ManagementChassis (2U)

Chassis ManagementBoards

图2-13 AWS与MPP系统连接示意图

图中最左边是AWS，它是一台小型服务器。中间是一个磁盘阵列机柜，右边

是一个结点机柜。每个机柜中的所有模块以内部连接的方式与AWS进行连接。各

模块工作情况在AWS上以图形方式显示，如绿色表示正常、红色表示故障等，十

分直观。

. 71 .

BYNET V1和和和和BYNET V2

前面谈到，在NCR WorldMark系列计算机中，用于实现结点互联从而构成一个

统一的MPP平台的关键技术是BYNET。BYNET是NCR发明的一种由硬件实现的结

点互联网络技术，是一种内部网络，因此通过外部公共网不能访问它。

BYNET节点互连网络是一个双冗余、全双工的网络，以松耦合方式将多个

SMP节点高速连接起来。BYNET节点互连网络基于Banyan网络拓扑技术，具有折

叠式的榕树型(Folded BanYan Tree)结构，图2-14是一个连接64个节点的BYNET 内

部交换网络示意图。从图中可以看到，所有SMP结点都是两两互相连接的，因此当

MPP系统的节点增加时，系统内部的通信带宽也将线性增加，这也是NCR

WorldMark系列计算机具有优秀的线性可扩展能力的主要原因。

BYNET同时具有点对点和广播两种信息传播方式。广播技术在结点互联中非

常重要，通过它可以更好地实现结点间并行处理。目前市场上主要有三种结点互连

技术，BYNET是唯一具有信息广播功能的，也是唯一通过硬件来实现的，因此速

度最快。

. 72 .

单单单单点点点点单单单单信信信信信信信信复复复复点点点点信信信信信信信信信信信信复复复复

图2-14 BYNET逻辑结构和信息传播方式

NCR公司首次在 WorldMark 5100系列MPP计算机中引入BYNET技术和设备，

在随后推出的WorldMark 4700/5150系列MPP计算机中又将BYNET设备进一步完善

和增强，使互连节点总数达到128个。此时的BYNET节点互连网络传输率为每条网

络20Mbytes/Sec。刚刚谈过，BYNET是一个双冗余、全双工的节点互连网络，每个

节点连接两条BYNET网络，而且系统中所有节点两两互连。因此，一个8节点的

MPP系统，其系统内部通信带宽将到达8x20x2=320Mbytes/Sec的点对点通信传输

率。在新一代的WorldMark 48xx/52xx系列MPP计算机中，NCR公司又将BYNET技

术和设备提升到一个新高度，使互连节点总数达到512个，BYNET节点互连网络传

. 73 .

输率也达到每条网络60Mbytes/Sec。因此，一个8节点的52xx MPP系统，其系统内

部通信带宽将到达8x60x2=960Mbytes/Sec的点对点通信传输率。为了与

20Mbytes/Sec的BYNET网络相区别，将60Mbytes/Sec的BYNET网络称为BYNET

V2，而将20Mbytes/Sec的BYNET网络称为BYNET V1。

2.32.32.32.3 Teradata 的的的的并并并并行行行行处处处处理理理理机机机机制制制制

Teradata最显著的特色之一是其强大的并行处理能力，其实现方式被称为多维

并行处理机制，简单描述如下：

查询并行(Query并行)：这种并行处理是基于HASH数据分配机制实现的。每个

AMP都是一个VPROC，各自独立负责一部分数据的处理，相互之间没有关系，每

个节点一般配置4至16个这样的VPROC。所有关系运算如表的搜索、索引检索、投

影、选择、联接、聚集、排序等都是由各个VPROC并行进行的。

步内并行(Within-a-Step并行)：一个SQL查询进入系统后，首先由优化器进行

优化处理，分解成一些小的步骤，然后再分发给各VPROC进行处理。一个步骤可

能非常简单，如“搜索一个表并返回结果”；也可能非常复杂，如“按照某条件搜索

两个表，然后联接，结果投影到某几个列，对它们加和(SUM)后返回结果”。象这

. 74 .

种复杂查询将处理多个关系运算，每个关系运算在一个VPROC内将启动多个进程

来实现并行处理，称为步内并行。

多步并行(Multi-Step并行)：上面说过，一个SQL被分解成多个小的步骤，这些

步骤的执行将同时进行，称为多步并行。优化器分解一个SQL查询请求的原则是尽

可能使各步独立。在目前所有的DBMS产品中，只有Teradata实现了多步并行。

图2-15以一个复杂查询的实例形象地说明了Teradata的多维并行处理机制。

这里假设系统配置有4个虚拟处理器(VPROC)，某个复杂查询被优化器分解成

了7个步骤，图中SUPPLIERS、PARTS、PARTSUPP等为数据库中表的名字。在每

个步骤执行时，4个VPROC同时处理与各自相关的数据块，例如搜索SUPPLIERS表

(步骤1.1)，该表的记录是通过HASH算法均匀分布在4个VPROC各自负责的磁盘中

的，搜索时4个VPROC将同时进行，把相关的记录搜索出来，这就是所谓的查询并

行；步骤1.1和1.2、2.1和2.2也是同时执行的，这是所谓的多步并行；步骤2.2(或步

骤1.2)中包含有三个操作，它们借助于一种管线(Pipeline)的机制实现了步内的并行

处理。

. 75 .

Multi-Step 并并并并并并并并

Within-A-Step 并并并并并并并并完完完完操操

1. LineItem搜搜2. Orders搜搜3. Lineitem & Orders联指

Query 并并并并并并并并4 VPROC 完个个

详详复处处处家的数数

SUM 操操操操操操操操

文文文文理理理理文文文文文文文文

搜搜搜搜搜搜搜搜SUPPLIERS

联联联联指指指指PARTS &

PARTSUPP

SQLSteps

5

4

3

2.1 2.2

1.1 1.2

联联联联指指指指 LINEITEM& ORDERS

返返返返返返返返返返返返详详详详详详详详后后后后

文文文文理理理理文文文文文文文文

图2-15 Teradata的多维并行处理

除了上面描述的多维并行处理机制外，Teradata还作了进一步的优化和扩展，

使得处理复杂查询时响应速度进一步加快。举例来说，在多用户环境下，一个部门

中许多用户的查询常常是大同小异的，经过优化器分解后，它们具有一些相同的步

骤，由于每个步骤的执行结果会在一个系统缓冲区中暂存，相同的步骤往往只需要

执行一次即可。从而大大减少了磁盘I/O，提高了响应速度。

. 76 .

我们知道，对于OLTP系统来说，由于其查询相对简单，依靠建立适当的索引

就能保证查询的速度，从而对DBMS并行处理的能力要求不高。但对于数据仓库来

说，它主要提供的是OLAP应用，许多业务问题相当复杂，如果依靠索引来提高查

询速度，将存在两方面的问题：一是索引过多会占用太多的磁盘空间，增加系统的

复杂性和管理成本。许多OLTP DBMS用于数据仓库时，其磁盘使用率(Disk

Ratio，指数据库大小与真正的用户数据的比例)在5以上，有时甚至高达10，原因就

在于此。而基于Teradata建立的数据仓库，磁盘使用率一般在1.5至3之间。二是建

立一个索引意味着事先定义好一些与之相关的问题，当提出其它问题时常常需要建

立另外的索引。也就是说，索引只能解决那些预先定义好的问题，如一些业务报表

等。而数据仓库除了要产生大量的业务报表外，另一个主要的应用就是回答那些不

能预知的、动态的业务查询，我们称这种动态查询为Ad-hoc查询。你无法想象当管

理人员提出一个问题时，DBA回答说：“对不起，我没想到你会提这个问题，请稍

等一些，我建个索引就可以了”。因此，DBMS具有强大的并行处理能力是数据仓

库应用成功与否的关键。Teradata从诞生之日开始，就是专门针对OLAP应用设计

的，它的专长不在于OLTP，而在于OLAP，其内部的并行处理机制被设计得十分完

善。目前全世界已有900多个由Teradata驱动的数据仓库投入运行，市场份额超过

50%，这是为什么说Teradata是数据仓库专用引擎的有力佐证。

. 77 .

2.42.42.42.4 Windows平台的平台的平台的平台的Teradata数据库数据库数据库数据库

随着Teradata数据库系统在决策支持应用领域受到越来越广泛的重视，越来越

多的大型企业纷纷采用它来实施数据仓库系统。而另一方面，Microsoft的Windows

NT在操作系统的市场份额也逐渐扩大，许多中、小型企业开始把一些关键应用从

UNIX平台移值到NT平台。考虑到在NT市场尚没有一个专门针对决策支持应用的数

据库系统，NCR公司决定将UNIX平台上下的Teradata数据库移值到Windows NT平

台上来，以扩大Teradata数据库在中小型应用上的市场份额，以进一步巩固其在数

据仓库领域的领导地位。经过两年多的努力，NCR公司在1998年正式宣布了

Teradata for Windows NT的SMP版本，在1999年发布了Teradata for Windows NT的

MPP版本，在2000年再次发布了Teradata for Windows 2000的MPP版本，并且于同

年3月用16个节点的NCR WorldMark 5200计算机和Teradata for Windows 2000数据库

在业界第一个进行了基于Windows 2000操作平台的TPC-R基准测试，并公布了测试

结果。到目前为止，NCR是第一个也是目前唯一一个进行和公布基于Windows平台

TPC-R测试的厂商。

除了运行平台不同外，Teradata for Windows的内部结构和Teradata for UNIX完

全相同，也采用了相同的虚拟处理器技术来实现其完全并行处理机制。另外，许多

在Teradata for UNIX数据库的维护工具如CONFIG/RECONFIG、DIP、DBW等也都

随 Teradata for Windows数据库一起移植到了Windows平台，并且保持相同的操作方

式和命令集，使得数据库管理员只需要掌握一种平台数据库系统的操作和维护就可

. 78 .

以了。除特别说明外，本书所介绍的内容同时适用于Teradata for UNIX和Teradata

for Windows。

NCR公司已经发布了一个基于统一源代码的Teradata数据库版本V2R4，该版本

同时适应于UNIX平台(NCR UNIX SVR4 MP-RAS)和Windows平台(Microsoft

Windows NT 4.0和Windows 2000)，从而允许数据仓库的潜在客户根据其IT架构、

项目预算、人力资源等因素来选择适当的操作系统和相应的Teradata数据库。

2.52.52.52.5 Teradata多媒体数据库多媒体数据库多媒体数据库多媒体数据库

在传统的Teradata数据库中，可以存储各种图形、声音等多媒体文件，但只是

限于储存，而不能对它们进行匹配。比如要查找某个人的照片，必须根据相应的索

引而不能根据照片本身的特征来查询数据库。这不是真正意义上的多媒体数据库。

随着多媒体应用的日益普及，人们对多媒体数据库的需求也在增加。NCR公司

在1998年底推出了真正意义上的多媒体数据库，利用这种数据库，可以存储并对多

媒体对象进行各种处理。Teradata多媒体数据库的基本结构如图2-16所示。

. 79 .

Teradata 多多多多多多多多多多多多数数数数数数数数数数数数详详详详多多多多

CLIENT

网网网网任任任任指指指指

信储详存数数信储多多多点存

RDBMS ENGINEOBJECT SERVER

Teradata MultimediaDatabase

Object Identifier (OID)links from RDBMS recordsto stored objects

客客客复客财指客客点存的对指复点

Network

Runs User-Defined (UDFs)

Teradata 点点点点存存存存客客客客财财财财指指指指

图2-16 Teradata多媒体数据库基本结构

从图中来看，Teradata的多媒体服务是在原来的数据库引擎上并行地增加了一

个专门用于多媒体对象的对象服务器，该对象服务器内部和原来的RDBMS之间通

过对象标识OID(Object Identifier)将多媒体对象与其相关的一般数据对应起来。

Teradata提供一种多媒体SQL语言(M-SQL)来操作整个数据库。M-SQL是对标准SQL

的扩充，它在标准SQL的基础上增加了直接操纵多媒体对象的语句，使得从用户端

可以对多媒体对象进行有关模式匹配等真正意义上的多媒体数据库操作。

. 80 .

系统接收到来自客户端的交易请求后，由协调器来进行识别和分解，将与多媒

体操作有关的交易传送给对象服务器，而把传统的数据库操作则传给原来的

Teradata RDBMS。这样使得原来的Teradata用户可以非常方便地升级到多媒体数据

库。对新用户而言，这种配置也显得非常灵活，开始时只需要选用普通数据库，今

后有必要时再扩展到多媒体系统。

. 81 .

第三章第三章第三章第三章 Teradata数据库的数据分配机制数据库的数据分配机制数据库的数据分配机制数据库的数据分配机制

3.13.13.13.1 哈希算法、主索引、与数据分配哈希算法、主索引、与数据分配哈希算法、主索引、与数据分配哈希算法、主索引、与数据分配

哈希(HASH)的英文含意是把某种东西或事物搞得杂乱无章的意思。哈希算法

由此得名。其基本原理是这样的：将任何类型的数据作为输入，经过算法处理后，

其输出将是一个从0到某个整数之间的一个数。一个设计得好的哈希算法应该能做

到尽量打乱输入数据的规律或隐含的模式，而输出必须在上述范围内尽可能地均匀

分布。举例来说，如果一些人的姓以拚音字母S打头，则经过哈希算法处理后，其

输出不应在某个固定的组内，而应在整个范围内均匀分布。

Teradata数据库采用哈希(Hashing)算法作为其唯一的数据分配机制。它将表的

主索引作为哈希算法的输入值，并且利用一个矩阵结构的HASH MAP，将哈希运

算计算出来的输出值通过此矩阵与系统中的各个AMP进行映射。 HASH MAP中的

元素称为HASH BUCKET，它们实际上对应了系统中各个AMP的编号。这样，通过

HASH MAP就可以将一条记录“引导”到相应的AMP上进行操作。

. 82 .

目前，Teradata数据库的HASP MAP矩阵共有65536个BUCKETS。在Teradata数

据库中，一个经哈希算法处理后的输出是一个取值范围在0-232之间的32比特整数，

称为ROW

HASH值。它进一步分成两部分，前16比特就是对应HASH MAP的HASH

BUCKET，其取值范围为0-65535。

当用户向数据库插入一条记录时，Teradata利用哈希算法根据记录的主索引计

算出ROW HASH值，通过HASH MAP找到相对应的AMP，则该条记录即通过此

AMP存放到其管理的磁盘上。由于主索引值的不同和哈希算法的均匀性，一个表

的各条记录将均匀地分布到系统中各个AMP所管理的磁盘上。数据分配过程完全

自动进行，不需要DBA干预，这一点和其它OLTP数据库有很大的区别。Teradata数

据库的数据分配机制示意图3-1所示。

. 83 .

某某某某某某某某某某某某某某某某的的的的面面面面搜搜搜搜指指指指主主主主

Virtual PE

HASHING 算算算算算算算算

ROW HASH (32 BITS)

详详详详后后后后市市市市分分分分(16Bits)

BUCKET16 BITS

BYNET

BYNET 通通通通面面面面Hash Map

AMP 1

Hash Map

AMP 2

Hash Map

AMP 3

Hash Map

AMP 4

BYNET 通通通通面面面面 BYNET 通通通通面面面面 BYNET 通通通通面面面面

图3-1 Teradata数据库的数据分配机制示意图

. 84 .

Teradata数据库系统初始化时，将根据系统配置的AMP数量自动计算并形成

HASH MAP。如果进行了诸如增加磁盘、结点升级等工作，系统重新调整了AMP

数量(增强或减少)时，则通过执行Teradata数据库提供的一个系统配置工具

(Config/Reconfig)就能自动完成HASH MAP矩阵的修改工作，保证HASH MAP可以

正确映射重新调整后的AMP，而哈希算法本身不需要作任何调整。这一点和其它

商用数据库的哈希算法有根本性的区别。Teradata数据库的哈希算法经过十五年的

发展，已经十分完善，并获得过十余项专利。

3.23.23.23.2 Teradata数据分配示例数据分配示例数据分配示例数据分配示例

我们用一个实际的例子来说明数据分配过程。考虑下面插入一条记录的SQL语

句：

INSERT INTO order Values (7550, 16, 950420, ’0’),

分析引擎PE接受到此交易请求后，首先检查数据字典，确定表ORDER的主索

引是第一个字段，由此可知上述记录的主索引值是7550。通过哈希算法对7550进行

计算，其输出是一个32比特的

. 85 .

ROW HASH，假设结果为001AD6C7，故HASH BUCKET为001A。通过此

HASH BUCKET在HASH MAP中映射，对应的处理器是AMP 3。换言之，上述记录

将交给AMP 3处理，AMP 3插入到其管理的磁盘单元中。其过程如图3-2所示。

. 86 .

7550

0000000000011010 1101011011000111

HASHING 算算算算算算算算

ROW HASH (32 BITS) 详详详详后后后后市市市市分分分分

(16Bits)BUCKET16 BITS

001A

BYNET ( AMP )通通通通面面面面信信信信界界界界界界界界界界界界完完完完界界界界

HASH MAP


01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 0801 02 03 04 05 06 07 08 01 02 03 04 05 06 07 0801 02 03 04 05 06 07 08 01 02 03 04 05 06 07 0801 02 03 04 05 06 07 08 01 02 03 04 05 06 07 0801 02 03 04 05 06 07 08 01 02 03 04 05 06 07 0801 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08

0 1 2 3 4 5 6 7 8 9 A B C D E F

000102030405

图3-2 Teradata数据库的数据分配过程举例

. 87 .

概括来说，Teradata是以记录而非表为单位来存储数据的。这样，一个表的各

条记录将均匀分散在系统中所有磁盘上，不存在“热盘”问题。而且这个过程自动

进行，不需要数据库管理员的干预，不需要对磁盘作固定分区(如把某个表固定在

某个磁盘区域)。

3.33.33.33.3 主索引与表的创建主索引与表的创建主索引与表的创建主索引与表的创建

根据上面的讨论得知，在Teradata数据库中只有一种基于哈希算法的数据分配

机制，数据的分配是依靠对主索引进行哈希处理来完成的。因此，必须在创建表的

同时就确定主索引。下面是创建一个EMPLOYEE表的例子：

CREATE TABLE Employee

(gender CHAR(1) NOT NULL

,emp_number INTEGER NOT NULL

,lname CHAR(20) NOT NULL

,fname VARCHAR(20)

,salary_amount DECIMAL(10,2)

. 88 .

,dept_number SMALLINT

,job_code CHAR(3))

UNIQUE PRIMARY INDEX (emp_number);

我们看到，在创建表EMPLOYEE的同时，指定员工号emp_number为该表的主

索引。

如果在创建表时不明确指定主索引，Teradata数据库将把第一个非空字段当成

缺省的主索引，以便进行数据的分配。在上面的例子中，如果不指定emp_number

为主索引，则Teradata数据库将以性别gender作为主索引，这将使数据分配很不均

匀。举例来说，假设公司有100万个员工，其员工号将是唯一的，对员工号进行哈

希处理后的输出非常均匀，因此数据的分配也很均匀；而字段gender只可能有2种

取值：男或者女，由此产生的ROW HASH也只有两个值，数据的分配将极不均

匀。

因此，Teradata数据库要求在创建表的同时必须明确指定主索引，而数据库管

理员最重要的工作就是为每张数据表选择尽可能唯一的字段来作主索引。关于如何

选择主索引的问题我们将在第五章中进行更详细的讨论。

. 89 .

3.43.43.43.4 哈希冲突与不唯一主索引哈希冲突与不唯一主索引哈希冲突与不唯一主索引哈希冲突与不唯一主索引

前面谈到，哈希算法的输出范围从0到232。这虽然是一个很大的范围，但毕竟

是有限的。因此一定有机会产生这样的现象：即不同的输入值经哈希算法处理后得

到相同的结果。这被称为哈希冲突。另外一种情况是：如果选定的主索引是

NUPI(非唯一主索引)，其值不唯一，那么两条记录如果具有相同的主索引值，则产

生的 ROW HASH一定是一样的。

为了把一个表中的各条记录区为开来，必须考虑如何处理上面谈到的哈希冲突

和NUPI的问题。为此，Teradata数据库给每个ROW HASH 自动指定和维护一个32

比特的唯一值(Unique Value)，它与ROW HASH组合起来，构成一个唯一的记录标

识号(ROW ID)。图3-3表示了记录标识号的组成及其原理。

. 90 .

RO W HASH 主主主主唯唯唯唯详详详详主主主主

由生生生生并 32 多维维维维

由由由算算生 32 生维维维

(ROW ID)＝＝＝＝某某某某某某某某＝＝＝＝家家家家号号号号

搜搜搜搜指指指指主主主主 Row Hash

872872904721

54876548763339154876

1213

重重重重复复复复重重重重复复复复

冲冲冲冲冲冲冲冲

唯唯唯唯详详详详主主主主

NUPI由由由由由由由由冲冲冲冲冲冲冲冲复复复复

图3-3 记录标识号的组成及其原理

由图中可知，唯一值是由系统根据每个不同的ROW HASH自动形成和维护

的。这样，记录标识号实际上由8个字节共64比特组成。图3-4给出了一条记录的结

构示意图。

. 91 .

某某记任

某某＝家号

ROWHASH 唯详主

某某记任

某某处记记

面搜指主

2 记节 4 记节 4 记节变记 2 记节

图3-4 数据记录的组成

由图可知，记录标识号是数据记录的一个包头。各数据记录在磁盘中是按记录

标识号的升序顺序存放的，这样无形中形成了一种索引结构。因此，在Teradata数

据库中，对主索引不需要创建另外的子表，不存在额外的维护工作，这也是和其它

RDBMS不一样的。我们还可以看到，在一条记录的两头都有2个字节来表示记录长

度，这样可以方便AMP从任一方向来存取数据记录。

. 92 .

3.53.53.53.5 Teradata数据库系统数据库系统数据库系统数据库系统的在线升级的在线升级的在线升级的在线升级

得益于其独特的数据分配机制，Teradata数据库系统的重新配置和升级非常简

单。举例来说，一个两结点的WorldMark 4700 MPP平台，运行Teradata数据库，磁

盘阵列有4个RAID 5磁盘，系统中配置有4个AMP。随着数据量的增加，现要求增

加两列RAID 5磁盘。对大部分数据库而言，要完成这种工作必须先将系统中所有

数据备份出来，对新的磁盘系统重新划区，然后再加载数据。这样的过程很麻

烦，极容易出错，而且数据库管理员的工作量也很大。而对Teradata数据库而言，

这个过程是非常简单的，完全不需要将数据备份出来。数据库管理员只需要在增加

必要的硬件设备之后简单地运行一个CONFIG/RECONFIG工具，就可以在系统中增

加2个新的AMP，以管理新增的磁盘。同时，系统将重新自动计算新的HASH

MAP，以映射到新增的AMP，哈希算法本身不需要作任何调整。新的HASH MAP

生成后，数据库中原有的数据将在此基础上重新进行分配。经过计算，如果一条记

录仍应存储在原来的磁盘单元中，则不需要移动；如果一条记录主索引产生的

BUCKET所对应的AMP是新增加的两个AMP之一，则它将被重新分配到新的 AMP

所管理的存储单元中。这样，从4个AMP扩充到6个AMP，就只有三分之一的数据

作在线的重分配，极大地减少了系统升级的时间，也极大地减轻了数据库管理员的

工作强度。这个过程可以用图3-5来说明。

. 93 .

16,384

65,536 HASH BUCKETS

16,384 16,384 16,384

4 AM P AM P 16384 BUCKETS生生中系系完维界完系系完

16,384 16,384 16,384 16,384 空空空空空空空空

CONFIG 操详维作作生生作数系变净维数数并作真真重真分文

10,923 10,923 10,923 10,923 10,922 10,922

65,536 HASH BUCKETS

RECONFIG 操详维数数处通重真分文维完分客详的数数 4 AM P 2 从系从完系系的磁磁磁磁中从从真从加的完

AM P 系系的磁磁磁磁中

图3-5 Teradata数据库系统由4个AMP在线扩充到6个AMP

. 94 .

第四章第四章第四章第四章 Teradata数据库的数据访问机制数据库的数据访问机制数据库的数据访问机制数据库的数据访问机制

4.14.14.14.1 基于主索引的数据访问基于主索引的数据访问基于主索引的数据访问基于主索引的数据访问

我们用图4-1来说明在Teradata中基于主索引的数据访问过程。

. 95 .

BUCKET

报＝家号 32 BIT ROW HASH 主搜指主

PE BYNET 由多由由面的信信界信复 SQL 从扫扫从求中可求从分分指由由算算

BYNET Hash Bucket AMP通通通通面面面面维维维维界界界界面面面面从从从从界界界界界界界界

AMP 32 Row Hash 根根根根数数数数报报报报＝＝＝＝家家家家号号号号根根根根维维维维维维维维的的的的从从从从界界界界界界界界数数数数数数数数存存存存

SELECT * FROM tablename WHERE primaryindex = value ;

数数数数数数数数存存存存

数数数数数数数数某某某某某某某某

报＝家号搜指主

搜指主报＝家号

数数存界数

. 96 .

图4-1 基于主索引的数据访问

当PE接收到到图中的SQL交易请求后，分解器从数据字典中找到对应表的标识

号，同时通过数据字典来检查WHERE条件字句中的匹配项是否是主索引。当确认

是主索引后，将此索引值进行哈希处理，得到一个32比特的ROW HASH。将表标

识号、ROW HASH值以及主索引值本身一起在BYNET上广播，每个AMP都能收到

此广播信息，但只有一个与ROW HASH中的BUCKET对应的AMP才会执行数据库

读操作。该AMP利用ROW HASH和表标识号一起来定位数据块，将其读入内存。

然后在内存中根据记录标识号(ROW ID)来定位具体的数据记录，查询结果依照原

来的路径返回给前端。

由此可见，基于主索引的查询是一种单步AMP操作(One AMP Operation)，因

此速度非常快。但问题是，不是所有的业务查询都是针对主索引提出的。为了加快

速度，我们可以针对查询频率较高的字段建立次索引(Secondary Index)。次索引有

两种，即唯一的次索引USI(Unique Secondary Index)和不唯一的次索引NUSI(Non-

Unique Secondary Index)。下面我们分别讨论基于USI和NUSI的数据访问机制。

. 97 .

4.24.24.24.2 基于唯一次索引基于唯一次索引基于唯一次索引基于唯一次索引USI的数据访问的数据访问的数据访问的数据访问

唯一次索引USI可以在创建表的同时就定义，如：

CREATE TABLE Customer

(sex CHAR(1)

,cust_number INTEGER NOT NULL


,fname VARCHAR(20)

,address CHAR(40)

,telephone CHAR(15))

PRIMARY INDEX (lname)

UNIQUE INDEX (cust_number);

也可以在需要时单独建立，如：

CREATE UNIQUE INDEX (cust_number) ON Customer；

. 98 .

当分析引擎PE接收到一个SQL查询请求，并判断出WHERE条件子句中的匹配

字段是一个唯一次索引时，就会采取基于USI的数据访问策略。图4-2非常直观地描

述了这样的数据访问过程。

. 99 .

AdamsSmith

RiceWhite 555-4444

111-2222222-3333

666-555531

37

40

84107, 1536, 5638, 1640, 1

RowID Cust Name PhoneNUPI

AdamsSmith

AdamsBrown

444-6666333-9999666-7777555-6666

45

7274

98471, 1555, 6717, 2884, 1


YoungJonesBlack

Smith

444-5555

111-6666777-4444222-8888

1227

49

62

147, 1147, 2388, 1822, 1


Jones

SmithPeters

Marsh

777-6666555-7777555-7777888-2222

5651

7795

639, 1778, 3778, 7915, 9


面面面面报报报报面面面面报报报报面面面面报报报报面面面面报报报报

BYNET

Hash Maps Hash Maps

AMP 4

Hash Maps Hash Maps

SELECTFROM

WHERE

*CustomerCust = 56 ;

74775127

884, 1639, 1915, 9388, 1

244, 1505, 1744, 4757, 1

RowID Cust RowID

8498

5649

536, 5555, 6

778, 7147, 1

296, 1135, 1

602, 1969, 1

RowID Cust RowID31404595

638, 1640, 1471, 1778, 3

288, 1339, 1372, 2588, 1

RowID Cust RowID37721262

107, 1717, 2147, 2822, 1

175, 1489, 1838, 1919, 1

RowID Cust RowID

BYNET

Hash Maps Hash Maps

AMP 2

Hash Maps Hash Maps

由由算算

Parser分分指

报＝家号

100

Row Hash

602

USI 的主

56

报＝家号

100

Row Hash

778

唯详主

7

USI 子子子子报报报报 USI 子子子子报报报报 USI 子子子子报报报报 USI 子子子子报报报报

. 100 .

图4-2 基于唯一次索引USI的数据访问

首先，分析引擎PE接收到SQL交易请求后，利用数据字典判断出WHERE条件

子句中的匹配条件客户编号(Cust)是一个USI，因此，先对此USI值进行哈希处理，

处理后的ROW HASH值为602。同时，从数据字典中找到客户表的标识号为100。

PE把这两个值连同客户编号的值一起在BYNET上广播，以便确定由哪个AMP

来搜索相应的USI子表。从HASH MAP中可以确定是AMP 2，该AMP利用从

BYNET中得到的信息迅速从USI子表中定位数据块。

我们看到，在USI子表中只有三个子段，即针对USI计算出来的记录标识号

(ROW ID)、USI值本身和针对主索引在主表中计算出来的记录标识号。注意ROW

ID是由ROW HASH和一个数据库系统自动维护的唯一值组成的。从USI子表中定

位数据块后，可以从中找到主索引对应的ROW ID，由此得到主索引的ROW HASH

值为778，系统赋的唯一值为7。Teradata将它们连同表标识号100再次在BYNET上

广播，通过HASH MAP可以确定是AMP 4，该AMP利用上面得到的ROW ID可以直

接从主表中定位数据记录。

. 101 .

根据上面的分析可以得出这样的结论：和主索引一样，唯一次索引也是一种指

针，只不过主索引直接指向记录的存储位置，而唯一次索引则是指向主索引对应的

记录标识号，它相当于指向指针的指针。

利用唯一次索引进行的数据访问是一种双AMP操作(Two AMP Operation)，并

且这两次操作都不需要对全表进行搜索，因此速度很快。这就是建立唯一次索引能

提高系统查询速度的原因。当然，付出的代价是增加了一个基于USI的子表，对它

的存储和自动维护都需要耗费系统一定的资源。

4.34.34.34.3 基于非唯一次索引基于非唯一次索引基于非唯一次索引基于非唯一次索引NUSI的数据访问的数据访问的数据访问的数据访问

上一节我们讨论了基于唯一次索引进行的数据访问过程。当一个次索引的值不

具有唯一性时，它就是一个非唯一次索引NUSI(Non-Unique Secondary Index)。那

么，基于NUSI进行的数据访问过程又是怎样的呢？它能否提高系统的查询处理速

度呢？这是我们这一节要研究的内容。

假设客户表是这样创建的：

CREATE TABLE Customer

(sex CHAR(1)

,cust_number INTEGER NOT NULL

. 102 .


,fname VARCHAR(20)

,address CHAR(40)

,telephone CHAR(15))

PRIMARY INDEX (cust_number)；

该表的主索引是客户编号，而我们经常针对客户的姓进行查询。为了提高速

度，可以将客户的姓作为非唯一次索引NUSI。这可通过执行下面的SQL语句来实

现：

CREATE INDEX (lname) ON Customer；

图4-3表示了基于NUSI进行的数据访问过程：

. 103 .

SELECTFROM

WHERE

*Customerlname = dams?;慉

AdamsSmith

RiceWhite 555-4444

111-2222222-3333

666-555531

37

40

84107, 1536, 5638, 1640, 1

RowID Cust lname PhoneNUPI

AdamsSmith

AdamsBrown

444-6666333-9999666-7777555-6666

45

7274

98471, 1555, 6717, 2884, 1


YoungJonesBlack

Smith

444-5555

111-6666777-4444222-8888

1227

49

62

147, 1147, 2388, 1822, 1


Jones

SmithPeters

Marsh

777-6666555-7777555-7777888-2222

5651

7795

639, 1778, 3778, 7915, 9


BYNET

AMP 2AMP 1 AMP 3 AMP 4

AdamsSmith

RiceWhite 107, 1

536, 5638, 1640, 1432, 8

567, 3656, 1448, 1

Smith

AdamsBrown

717, 2471, 1555, 6884, 1432, 3

567, 2852, 1

Jones

SmithPeters

Marsh

639, 1778, 3778, 7915, 9

432, 5

262, 1

155, 1

396, 1YoungJonesBlack

Smith 147, 1147, 2388, 1822, 1

432, 1

262, 6448, 4

770, 1

RowID lname RowIDs RowID lname RowIDs RowID lname RowIDs RowID lname RowIDs

NUSI 子子子子报报报报 NUSI 子子子子报报报报 NUSI 子子子子报报报报 NUSI 子子子子报报报报

面面面面报报报报

由由算算

Parser分分指

报＝家号

100

Row Hash

567

NUSI 的主

Adams

面面面面报报报报面面面面报报报报面面面面报报报报

图4-3 基于非唯一次索引NUSI的数据访问

. 104 .

分析引擎PE从客户端接收到SQL交易请求后，用分解器对其分解。从数据字典

中判断出SQL语句的WHERE条件子句中的匹配字段是一个非唯一次索引NUSI，于

是采取基于NUSI的数据访问策略。先对此NUSI值"Adams"作哈希处理，得出ROW

HASH值为567。又从数据字典中确定表标识号为100，连同NUSI值一起在BYNET

上广播。

Teradata数据库对NUSI的处理与USI不一样，NUSI子表与相应的主表用同一个

AMP进行存储和维护。在进行数据访问时虽然也将NUSI值进行哈希处理，但结果

的HASH BUCKET被忽略，不用来决定由哪个AMP进行NUSI匹配。Teradata 将

ROW HASH、NUSI值本身、和表标识号对所有AMP广播，让每个AMP在各自的

NUSI子表中寻找匹配的数据。因此，所有AMP将同时操作，在各自的NUSI子表中

定位相应的数据块，但只有AMP 1和AMP 2中找到了匹配的数据。

和USI一样，在NUSI的子表中也只有三个子段：针对NUSI计算出来的记录标

识号(ROW ID)、NUSI值本身和针对主索引在主表中计算出来的记录标识号。

AMP 1在其负责的NUSI子表中找到一条匹配ROW HASH值567(NUSI值

"Adams"的ROW HASH结果)的记录，其对应的主索引的记录标识号为"638, 1"，即

主索引的ROW HASH值为638，系统赋的唯一值为1。同样，AMP 2在其负责的

NUSI子表中找到两条匹配的记录，其对应的主索引的记录标识号分别为"471, 1"和

. 105 .

"717, 2"，即主索引的ROW HASH值分别为471和717，系统赋的唯一值分别为1和

2。

上述信息连同表标识号100和NUSI值"Adams"再次在BYNET上广播，通过

HASH MAP的映射，由AMP 1和AMP 2在主表中直接定位相应的数据记录。

综上所述，基于非唯一次索引NUSI的数据访问是一种牵涉到所有AMP的操作

(All AMP Operation)。它分成两步进行：首先在NUSI子表中根据对NUSI值的哈希

处理结果在NUSI子表中寻找主索引的ROW HASH值，然后进一步在主表中来寻找

匹配的数据记录。这两个步骤分别依靠NUSI的ROW HASH和主索引的ROW

HASH值直接定位相应的数据块，不需要对全表进行搜索，因此速度也是很快的。

和唯一次索引的作用一样，非唯一次索引也可以看成是一个指向指针的指针。

建立NUSI同样可以提高数据访问的速度，所付出的代价则是增加了一个基于NUSI

的子表，对它的存储和自动维护同样需要耗费系统一定的资源。

4.44.44.44.4 全表扫描全表扫描全表扫描全表扫描

上面分别讨论了基于主索引、唯一次索引、和非唯一次索引进行的数据访问过

程。它们的速度都很快，但前提条件则是：客户所提交的查询请求必须基于索引进

. 106 .

行。对于OLTP系统而言，由于交易类型简单而且固定，我们完全可以针对定义好

的问题建立相应的索引。但对数据仓库系统来说，其基本的特征之一就是所谓的动

态查询(Ad-Hoc Query)。由于市场、环境等各方面因素的变化，我们不能把所有的

业务问题都预先描述出来，因此也无法预先建立相应的索引。另外，有相当多的问

题本身就无法基于索引来处理，如对表进行统计、排序，或在WHERE条件子句中

包含LIKE、BETWEEN运算符等等。这些问题在OLTP系统中不多，但却是决策支

持应用的一个基本特征。对于这些问题必须采用全表扫描(Full Table Scan，简称

FTS)的数据处理方式。下面就来讨论一下全表扫描的过程。

全表扫描对数据库系统的并行处理能力要求非常高，而这正是Teradata数据库

的强项。根据第三章关于数据分配的讨论，我们知道，在Teradata数据库中，一个

表的所有记录是根据主索引通过哈希算法处理后利用HASH MAP均匀地分配到各

个AMP所负责的存储单元中。以图4-4为例，客户表的数据被均匀地分配给各AMP

管理。当分析引擎PE接收到一个针对客户表的查询请求后，它首先决定采取什么

样的搜索策略。如果不能采取前面几节讨论的基于索引的数据搜索方法，它就采用

全表扫描的方法进行处理。

因此，对于一个复杂的查询任务，当需要使用全表扫描时，这个任务被分成了

许多个子任务并分派给系统中的所有AMP来完成，每个AMP只需要在它所负责的

存储单元中搜索到符合条件的数据记录，最后在BYNET一级汇总后返回即可。这

. 107 .

样，总的处理时间就是各AMP中最慢一个所花的时间，而不是所有AMP处理时间

的和。

客客客客客客客客报报报报

AMP nAMP 3AMP 2AMP 1

图4-4 全表扫描的处理过程

4.54.54.54.5 总结总结总结总结

本章分别讨论了Teradata数据库的几种数据访问机制。分析引擎PE的优化器将

自动决定采用何种最优化的数据访问策略。当查询问题针对主索引提出时，这将是

一种单AMP操作；如果针对唯一次索引USI提出，则是双AMP操作；如果针对非唯

. 108 .

一次索引NUSI查询，则是牵涉所有AMP的操作；除此以外则采用全表扫描。表4-1

比较了这几种数据访问策略的特性。

表4-1 各种数据访问策略的比较

基于主索引单AMP操作

基于唯一次索引(USI) 双AMP操作

基于非唯一次索引(NUSI) 全AMP操作

其它全表扫描

基于主索引的查询是最快的，而次索引则为系统提供了另外一条访问数据的途

径。次索引对数据的分配不产生任何影响，当建立一个次索引时，系统将创建一个

基于次索引的子表，这个表相对主表而言当然小得多。在次索引子表中存储有各主

索引值的ROW HASH，它相当于指向数据记录的一个指针。因此，只要搜索次索

引子表就能直接定位相应的数据记录。由于次索引子表相对主表而言要小得多，对

它的搜索速度很快，因此建立次索引可以很好地提高系统的查询速度。当然这是有

代价的：首先，次索引子表占用了额外的存储空间(主索引是不另占存储空间的)；

其次，数据记录的每次变化，也要求系统对次索引子表作自动的更新和维护，因此

占用了额外的处理器资源。表4-2总结了主索引和次索引的作用与特点。

. 109 .

表4-2 主索引与次索引的比较

索引的特征主索引次索引

是否必需 Yes No

每表最多有几个 1 32

每个索引最多由几个字段组成 16 16

允许唯一或者不唯一均可均可

是否影响数据分配 Yes No

是否可以动态的创建或删除 No Yes

是否影响处理性能 Yes Yes

是否允许多种数据类型的组合 Yes Yes

是否需要子表 No Yes

是否需要额外的处理 No Yes

当不能使用主索引或次索引进行数据查询时，系统将采取全表扫描的数据访问

策略。在全表扫描的情况下仍具有非常好的性能，这是Teradata数据库的一个基本

特征，表明了它具有非常强的并行处理能力。

. 110 .

第五章第五章第五章第五章如何选择主索引如何选择主索引如何选择主索引如何选择主索引

根据前面两章的讨论我们得知，在Teradata数据库中主索引起着非常重要的作

用：一方面，数据的分配依靠对主索引的哈希处理结果，选择好的主索引可以产生

比较均匀的数据分配，而选择不好的主索引可能导致数据的分配很不均匀，从而影

响系统性能；另一方面，基于主索引的数据访问只需要一个AMP操作就可直接定

位数据记录，因此是最快速的。

基于这两方面的原因，主索引选择的好坏对系统性能优劣影响较大。本章主要

内容就是讨论如何更好地选择主索引。

5.15.15.15.1 Teradata数据库中的数据库中的数据库中的数据库中的AMP与与与与PDISK

在前面的章节中已经介绍过，AMP是一种虚拟的处理器，用来完成对存储单

元的读写操作。事实上，在设计Teradata数据库系统时需要对存储系统进行规划，

而在配置Teradata数据库时，需要根据存储系统的规划指定AMP数量，以便使AMP

与存储单元对应起来。

. 111 .

无论是何种平台下的Teradata数据库，都不使用操作系统的文件系统来存储数

据，而是使用Teradata自己的文件系统。对于操作系统来说，这种磁盘区域被称为

Raw Slice(UNIX)或Raw Partition(Windows NT/2000)。而在Teradata数据库中，它们

被称为物理盘PDISK (Physical Disk)，这些物理盘必须大小相等或尽可能地相等。

安装Teradata数据库时，首先要指定哪些存储区域是PDISK，然后通过配置工

具将它们与AMP对应起来。换言之，每个AMP拥有自己的存储单元(PDISKs)，彼

此之间互不相关，不能相互借用存储单元。这是Teradata数据库能进行并行处理的

基础。

图5-1描述了一个4个AMP、每个AMP拥有2个PDISK的Teradata数据库配置示意

图。


PDISK 1

PDISK 2

PDISK 3

PDISK 4

PDISK 5 PDISK 7

PDISK 6 PDISK 8

. 112 .

图5-1 AMP与PDISK分配示意图

5.25.25.25.2 数据记录的分配数据记录的分配数据记录的分配数据记录的分配

根据上节的描述，Teradata数据库所能支配的存储空间(在Teradata中称为永久

空间Permanent Space)是均匀分配到每个AMP上的，并且相互之间的操作是彼此独

立的。而在第三章中我们谈到，Teradata数据库的数据分配是基于哈希算法进行

的，通过主索引的哈希处理结果来确定数据记录的物理存储位置。因此，如果主索

引选择不好，就有可能产生不均匀的数据分配。如某些AMP上分配太多的数据，

而另一些AMP上却很空闲，这样很容易就使系统空间溢出(Out of Space)。图5-2给

出了一个比较极端的例子。

图5-2 用一个ORDER表举例，订单的状态(STATUS)只有两种可能的取值

O(Open，表示尚未签单)或者C(Close，表示已签单)。如果用订单状态作为NUPI(非

唯一主索引)，它经哈希算法处理后的结果也只有两个。因此，只有两个AMP上能

分配到数据，而另两个AMP完全空闲，浪费了50%的存储空间。设想一下，如果系

统中有100个AMP，则将浪费98％的空间。显然，选择订单状态这样的属性作为主

索引是很不正确的。

. 113 .

表 ORDER

ORD CUST ORD DATE STATUS

PK

NUPI

7325

7324

7415

7103

7225

7384

7402

7188

7202

2

3

1

1

2

1

3

1

2

4/13

4/13

4/13

4/10

4/15

4/12

4/16

4/13

4/09

O

O

C

O

C

C

C

C

C

. 114 .

7103 1 4/10 O

7325 2 4/13 O


7402 3 4/16 C

7202 2 4/09 C

7225 2 4/15 C

7308 1 4/12 C

7188 1 4/13 C

7324 2 4/13 O7415 1 4/13 C

图5-2 极不均匀数据分配举例

仍以ORDER表为例，假设改选客户编号为NUPI，则得到了图5-3所示的结果。

表 ORDER


PK

NUPI

7325 2 4/13 O

. 115 .

7324

7415

7103

7225

7384

7402

7188

7202

3

1

1

2

1

3

1

2

4/13

4/13

4/10

4/15

4/12

4/16

4/13

4/09

O

C

O

C

C

C

C

C

7225 2 4/15 C

7325 2 4/13 0

7415 1 4/13 C

7384 1 4/12 C

7324 3 4/13 0

7402 3 4/16 C7103 1 4/10 C


7202 2 4/09 C

7188 1 4/13 C

图5-3 不均匀数据分配举例

. 116 .

这个结果与图5-2 的结果相比，已经有了改善。但由于客户编号的取值只有三

个不同的值，因此，仍有一个AMP上没有分配到数据。对于实际情况来说，一定

会有一些客户的订单比其它客户多，因此，用客户编号作主索引产生的数据分配结

果也是不均匀的。

现在改用订单号作为主索引，由于订单号也是主键，它一定是唯一的，因此这

是一个UPI。图5-4是基于订单号进行分配的结果，显然比前面两种好得多。

表 ORDER


PK

UPI

7325

7324

7415

7103

7225

7384

7402

7188

2

3

1

1

2

1

3

1

4/13

4/13

4/13

4/10

4/15

4/12

4/16

4/13

O

O

C

O

C

C

C

C

. 117 .

7202 2 4/09 C

7415 1 4/13 C

7202 2 4/09 C

7402 3 4/16 C

7325 2 4/13 C

7225 2 4/15 C

7188 1 4/13 C

7384 1 4/12 C

7324 3 4/13 C7103 1 4/10 C


图5-4 均匀的数据分配举例

5.35.35.35.3 选择主索引的基本原则选择主索引的基本原则选择主索引的基本原则选择主索引的基本原则

根据上一节的讨论，是不是意味着主索引必须是主键呢？不一定。事实上，如

果这样的话，就不会存在非唯一主索引了。

在选择主索引时，我们主要考虑以下因素：

! 每个表的记录数(需要考虑到今后的扩展)

. 118 .

! 表中每个字段有多少种不同的取值(比如性别只有两种可能的取值)

! 每种取值最多有多少条记录，平均有多少条记录(这些数据将影响每个

AMP上记录的分配个数)

! 每个字段的数据变化的概率大约有多少

! 对每个字段的访问频率大概为多少

在综合考虑上面各因素后，在保证数据分配尽可能均匀的前提下，尽量选择访

问频率高的字段或字段组合作为主索引，以充分发挥Teradata数据库的并行处理性

能。

. 119 .

第六章第六章第六章第六章数据库的空间管理、用户管理、访问权限数据库的空间管理、用户管理、访问权限数据库的空间管理、用户管理、访问权限数据库的空间管理、用户管理、访问权限

6.16.16.16.1 Teradata中的用户与数据库中的用户与数据库中的用户与数据库中的用户与数据库

和其它一些数据库管理系统不一样，在Teradata数据库中，用户与数据库是不

一样的两个概念。

6.1.16.1.16.1.16.1.1 数据库数据库数据库数据库

在Teradata数据库系统中，数据库是一个可管理的对象或者单元。从一般意义

上讲，数据库也常用来表示由RDBMS管理的整个系统，因此容易引起混淆。具体

意义应根据上下文来确定。

数据库由表、视图、宏等基本对象组成，并有相应的访问权限来控制客户端的

操作。在创建数据库时，必须定义其物理存储空间的大小，该存储空间称为永久空

间(PERMANENT SPACE简称为PERM SPACE)。PERM SPACE用来存储真正的数

据记录，但它只是一个逻辑的概念，表示该数据库可使用存储空间的上限，并没有

预先分配。当数据库的尺寸超过PERM SPACE的限制时，系统将提示空间溢出的错

. 120 .

误信息。对有些数据库来说，这时可能需要将系统中的数据备份出来，重新规划和

分区，然后加载数据。但在Teradata数据库系统中不需要这样做，因为PERM

SPACE只是一个逻辑概念，它表示的只不过是一个上限而已，当空间不够时，只要

系统中还有多余的空间，就可以动态修改其PERM SPACE，而不需要作任何数据库

重组的操作。这是Teradata非常重要、非常吸引人的特性之一，对数据库管理员

DBA而言是非常有意义的。

除了PERM SPACE以外，数据库还有另外一个概念SPOOL SPACE，它也是逻

辑上的一个概念，表示该数据库使用的SPOOL空间不能超过此上限。SPOOL空间

用于存储系统处理交易请求的一些中间结果。和永久空间一样，SPOOL空间也不

是预先分配的。事实上，整个系统中的空余空间都可以用作 SPOOL。

让我们举一个例子来说明PERM SPACE和SPOOL SPACE：假设一个Teradata

系统所拥有的永久空间为2GB，共有3个数据库A、B、C，其永久空间定义均为

500MB，SPOOL空间定义均为200MB，实际已使用的空间分别为400MB、300MB

和 200MB。这样，系统中尚未分配的永久空间为：

2000MB – 500MB – 500MB – 500MB = 500MB

系统中尚空闲的永久空间为：

. 121 .

2000MB – 400MB – 300MB – 200MB = 1100MB

A、B、C三个数据库尚能使用的永久空间分别为：

500MB – 400MB = 100MB

500MB – 300MB = 200MB

500MB – 200MB = 300MB

当某个数据库继续增长时，比如往数据库A中再增加约100MB数据，系统将提

示空间溢出。此时，可以通过MODIFY DATABASE命令从系统中尚未分配的

500MB永久空间中分配一定的存储空间给数据库A。

另外，对每个数据库定义了200MB的SPOOL SPACE，表示在此数据库上的操

作能使用的临时空间不能超过200MB。系统在处理交易请求时，临时空间的使用是

在什么存储位置，则视实际情况而定。换言之，系统中未分配数据记录的永久空间

为1100M，这些永久空间均可动态地被用作SPOOL SPACE。

对每个数据库定义一个SPOOL SPACE，只是为了安全上的考虑，防止不适当

的数据库操作将系统中的未分配空间耗尽，从而影响其它用户的使用。举例来说，

. 122 .

如果数据库A的SPOOL SPACE定义为1000MB，针对数据库A的一个复杂查询可能

没有设计好，比如对两个大表的连接操作是所谓的笛卡尔乘积(Product Join)，这时

A的SPOOL SPACE很快就会到达极限，如果系统中能使用的SPOOL空间总共只剩

下100MB，而此时恰好有其它用户同时在访问数据库，就一定会产生SPOOL空间

溢出，无法处理交易请求。因此，在定义数据库时，除了适当控制永久空间外，也

必须合理地定义其SPOOL空间。

创建一个数据库的命令举例：

CREATE DATABASE TestBase AS PERM = 200000000, SPOOL = 100000000;

该命令创建了一个测试数据库TestBase，其永久空间定义为200MB，SPOOL空

间不能超过100MB。注意，在Teradata数据库系统的缺省方式下，是不区分大小写

字母的。

修改此数据库的命令举例：

MODIFY DATABASE TestBase AS PERM = 300000000；

该命令将TestBase的永久空间修改为300MB，SPOOL空间定义不变。

. 123 .

6.1.26.1.26.1.26.1.2 用户用户用户用户

在有些数据库管理系统中没有用户的概念，其用户由操作系统来创建与管理。

在Teradata数据库系统中，用户是一个单独的概念，与操作系统中的用户没有关

系。用户和上面介绍的数据库类似，在创建一个用户时也可以定义永久空间和

SPOOL空间，它们的含意也完全相同。用户与数据库的唯一区别是：用户具有一

个帐号，可以通过此帐号来登录系统。因此，用户有一个口令，而数据库是没有口

令的。

在创建用户时，可以给他分配永久空间也可以不分配。没有永久空间的用户，

如果具有访问其它数据库的权限，也可以登录到系统中，根据相应的权限控制来操

作其它的数据库。当然，就数据库来说，其永久空间也可以为零，但这样做意义不

大。

创建一个用户的命令举例：

CREATE USER TestUser AS PERM = 200000000, SPOOL = 100000000,

PASSWORD = TestPassword;

修改一个用户，比如修改其密码的命令举例：

. 124 .

MODIFY USER TestUser AS PASSWORD = NewPassword;

6.26.26.26.2 Teradata数据库的层次型结构数据库的层次型结构数据库的层次型结构数据库的层次型结构

Teradata数据库系统以一种层次型结构来进行空间管理。当第一次安装好

Teradata系统时，系统将初始化整个存储空间，并创建系统用户与数据库以及相应

的系统表、视图、宏等对象。整个Teradata数据库的根用户称为DBC，这时的结构

如图6-1所示：

DBC

SysAdmin SystemFECrashdumpsPublic Default

图6-1 Teradata数据库系统的初始化结构

. 125 .

其中SysAdmin和SystemFE两个用户是提供给专业的维护人员使用的，用户

Crashdumps是Teradata数据库用来记录DUMP的。Public和Default是两个数据库，其

永久空间均定义为零，主要是为了保证与以前版本兼容而设置的。

根用户DBC的密码在系统安装后被初始化成DBC。DBC非常重要，最高的权

限均集中在DBC上，因此对DBC的密码要严格控制，不能随意泄露。当系统安装

后，应尽快修改其口令。

为了更好地管理系统，一般在系统安装后，我们都创建一个或几个用于管理的

用户，有的用来作安全性管理，有的用来作空间分配。

假设在一个比较小的环境下，我们只创建一个ADMIN用户来完成所有的管理

工作，其它所有用户可以按照组织或机构来分类，但它们均在ADMIN管理之下。

基本的步骤如下：

" 用DBC登录到系统；

" 为了确保系统中有足够的永久空间用作SPOOL，一般创建一个用户，如取名为

ReserveSpool，其永久空间一般定义为系统中可用永久空间的20%~30%。该

用户保留不作其它操作，这样，系统中一定能有足够的永久空间当作SPOOL

用。这种用途的用户也可以不在DBC下创建，而是以后通过下面创建的ADMIN

来建立，作用是相同的；

. 126 .

" 创建用户ADMIN，并分配足够的永久空间给ADMIN，因为其它所有用户的永久

空间都将来自于ADMIN；

" 将所有权限显示地授予DBC，如：GRANT ALL ON DBC TO DBC WITH

GRANT OPTION；这里使用了WITH GRANT OPTION选项，表示被授权方可

以将它接收到的权限再授给其它用户。

" 同样，将所有权限(也可视管理需要而定)授给新创建的ADMIN用户：GRANT

ALL ON ADMIN TO ADMIN WITH GRANT OPTION；这样，ADMIN就可以创

建并管理新的用户了。

" 改变DBC的密码：MODIFY USER DBC AS PASSWORD = NEWPASSWORD;

" 退出DBC；

从现在起，总是以ADMIN用户登录来完成必要的管理工作，所有新的用户均

从ADMIN下派生出去。不可随意在DBC下创建表或者其它的对象，以免破坏系统

表，这样可以确保DBC的安全。图6-2给出了一个实际系统的例子。

. 127 .

DBC

SYSADMIN Crashdumps SystemFE

ADMIN

USERADMIN ADMIN2ADMIN1 ADMIN3

USER1USER2USER3USER4USER5USER6USER7USER8USER9

APPL1

APPL2

APPL3

RESERVESPOOL

Production

Data

图6-2 Teradata数据库系统的层次型分配结构

在这个例子中，在DBC下创建了一个管理用户ADMIN，在ADMIN下继续分了

几个小组，其中USERADMIN主要用来进行用户的管理与维护。需要注意，在这种

层次型结构下，虽然永久空间没有预先分配，但在定义时每个用户的永久空间必须

. 128 .

来自于其直接拥有者。举例来说，假设系统初始化后DBC可用的永久空间为

500GB，创建ADMIN时定义其永久空间为450GB，则可观察到DBC的永久空间为

50GB。在ADMIN下创建用户USERADMIN，定义其永久空间为200GB，则可观察

到ADMIN的永久空间变为250GB。再创建一个用户ReserveSpool，以确保系统中有

足够的SPOOL空间，定义其永久空间为系统可分配永久空间大小的20%，即为

100GB。这样，ADMIN的永久空间将变为150GB。如果USERADMIN在其下面创建

用户USER1，其永久空间定义为10GB，则可观察到USERADMIN的永久空间变为

190GB，而ADMIN的永久空间定义不会发生变化。由此可见，永久空间的定义也

是层次型结构的，一个用户的永久空间来自于其直接拥有者，与其它用户无关。

拥有者与创建者在缺省情况下是同一个用户，在其它一些情况下则可能不是。

假设ADMIN有在USERADMIN下创建用户的权限，通过ADMIN登录后执行下面的

命令：

CREATE USER USER2 FROM USERADMIN AS PERM = 20000000000,

SPOOL = 10000000000, PASSWORD = USER2;

这样，由ADMIN在USERADMIN下创建了用户USER2，其永久空间为20GB，

SPOOL空间为10GB。换言之，USER2的创建者是ADMIN，而直接拥有者是

USERADMIN。

. 129 .

6.36.36.36.3 拥有者拥有者拥有者拥有者(Owner)与创建者与创建者与创建者与创建者(Creator)

拥有者也称为父辈(Parent)。我们知道，Teradata数据库系统的空间分配是一种

如图6-2 所示的层次型结构。在这样的结构中，一个对象是其下面所有对象的拥有

者，而一个对象由谁创建，谁就是该对象的创建者。

在图6-2 中，DBC是所有其它对象的拥有者，而所有这些对象都是DBC的后代

或孩子。ADMIN是其下面所有对象的拥有者，但与SysAdmin、SystemFE等无关。

同样，USERADMIN拥有用户USER1、USER2、...、USER9，但不拥有APPL1、

APPL2这些结构上与其无关的对象。对用户USER1来说，USERADMIN、ADMIN

和DBC均是它的父辈。由此可见，一个用户或数据库可以有任意数目的父辈，也可

以有任意数目的后代。

拥有权并非一成不变，可以在一定的条件下进行转让。例如，通过DBC或

ADMIN登录系统，可以将APPL1的拥有权从ADMIN1转让给ADMIN2。转让命令

为：

GIVE APPL1 TO ADMIN2；

. 130 .

当然，这要求发出这条命令的用户具有在ADMIN2下创建用户的权限。需要注

意的是，拥有权可以转让，但创建者是不可以改变的。换言之，一旦一个用户A创

建了另一个用户或者数据库B，那么A就永远是B的创建者。

如何检查一个用户或数据库具有哪些父辈或后代呢？在数据字典的一个视图

DBC.Children中存有这些信息，如果想检查用户APPL1的所有父辈(包括用户与数据

库)，可以执行下面的SQL命令：

SELECT PARENT FROM DBC.CHILDREN WHERE CHILD = 'APPL1';

如果想检查用户USERADMIN的所有后代(包括用户与数据库)，则可以执行下

面的命令：

SELECT CHILD FROM DBC.CHILDREN WHERE PARENT = 'USERADMIN';

. 131 .

6.46.46.46.4 Teradata数据库的访问权限数据库的访问权限数据库的访问权限数据库的访问权限

6.4.16.4.16.4.16.4.1 访问权限概述访问权限概述访问权限概述访问权限概述

Teradata数据库中所谓的访问权限是指某个用户对系统中一个对象(如用户、数

据库、表、视图、宏等)的操作权限，所有的SQL交易请求都受访问权限的控制。

总的说来，系统中认可的权限如表6-1所示。

表6-1 访问权限种类

权限缩缩缩缩写写写写权限缩缩缩缩写写写写缩缩缩缩写写写写

CHECKPOINT CP DROP MACRO DM REFERENCES RF

CREATE

DATABASE

CD DROP TABLE DT RESTORE RS

CREATE

MACRO

DM DROP USER DD ROLLBACK

DATABASE

CREATE

TABLE

CT DROP VIEW DV ROLLFORWARD

DATABASE

CREATE

USER

CD DUMP DP SELECT R

. 132 .

CREATE

VIEW

CV EXECUTE E TABLE

DATABASE INDEX IX UPDATE U

DELETE D INSERT I USER

DROP

DATABASE

DD MACRO VIEW

GRANT G

例如，CREATE USER表示在某个用户或数据库空间上拥有创建用户的权限。

权限的授予是通过GRANT命令进行的，例如：

GRANT SELECT ON USERA TO USERB WITH GRANT OPTION;

表示将对USERA中对象的SELECT权限授予给USERB，这样USERB就可以读

取USERA中的表、视图等对象了。由于带有WITH GRANT OPTION，因此USERB

还可以把它接收到的此权限再转授给其它用户或数据库。

权限的收回则是通过REVOKE命令来完成的。例如：

REVOKE SELECT ON USERA FROM USERB；

. 133 .

表示把对USERA的SELECT权限从USERB收回。这样，USERB就不能读取

USERA中的各种对象了。

在使用上述权限时需要注意以下事项：

! 这里的 DATABASE, TABLE, VIEW, MACRO, 和 USER权限表示同时允许

CREATE和 DROP操作，因此没有单独的一个缩写对应。例如：用户 A将

权限 DATABASE授予另一个用户 B，表示用户 B可以在 A所拥有的空间

内进行 CREATE/DROP DATABASE的操作。

! 当指明 CREATE或 DROP操作时，DATABASE与 USER相同，可以交互

使用。即 CREATE DATABASE权限与 CREATE USER权限没有区别。

! INDEX权限表示允许 CREATE/DROP INDEX操作。当然，INDEX只允许

对表进行操作。

! CHECKPOINT表示在永久流水上做一个逻辑记号，以便在进行数据恢复时

使用，这里表示相应的权限。

! REFERENCES用来定义一个字段或属性作为外键，这里表示相应的权限。

! DELETE表示是否具有删除记录的权限。

! EXECUTE表示执行宏的权限。

! UPDATE表示更新数据记录的权限。

! SELECT表示对一个对象进行读操作的权限。

! INSERT表示向一个表加记录的权限。

! CREATE表示执行 CREATE操作的权限。

. 134 .

! DROP表示执行 DROP操作的权限。

! 根据权限的不同，上述操作所针对的对象可以是数据库(Database)、用户

( User)、表(Table)、视图(View)、宏(Macro)或者表的某个字段(Column)。

对一个对象的访问权限共分三种：拥有权限(Ownership Rights)、自动权限

(Automatic Rights)和显示权限(Explicit Rights)。另外，如果需要访问Teradata数据

库系统的性能监视器(Performance Monitor)，则还有一个特殊的权限，称为监控权

(Monitro Privileges)。下面分别介绍这些权限。

拥有权限拥有权限拥有权限拥有权限

当一个用户，比如用户A，在其所属空间上创建新的用户、数据库等新的对象

时，A就成为这些新对象的拥有者，系统将自动授予A对这些新对象的访问权限，

称为拥有权。从结构上来看，A的父辈也是新创建对象的父辈，因此，系统也会把

对新对象的拥有权限授予A的所有父辈。由于拥有权是系统缺省授予的，也称隐含

权限(Implicit Rights)。

拥有权限具有以下两种形式：首先，它允许拥有者对它所拥有的对象执行

GRANT和REVOKE的命令，以便把它对此对象所拥有的任何权限(如SELECT、

. 135 .

EXECUTE、等等)GRANT/REVOKE给其它用户。注意，拥有权只意味着允许执行

GRANT和REVOKE命令，并不意味着拥有者对拥有的对象具有哪种权限。举例来

说，用户DBC拥有用户ADMIN，ADMIN中有一个表TABLEC，那么，ADMIN是

TABLEC的直接拥有者，而DBC则是TABLEC的间接拥有者，ADMIN和DBC均具

有对TABLEC的拥有权。当以DBC登录系统后，它可以授予它自己对TABLEC的任

何权限。在未显式地授予之前，DBC不能对TABLEC执行类似SELECT、INSERT之

类的操作。如果执行下面的命令：

GRANT SELECT, INSERT ON ADMIN.TABLEC TO DBC;

则DBC就可以对TABLEC执行SELECT和INSERT操作了，而允许执行这条命令

则是因为DBC对TABLEC具有隐含的拥有权。

其次，拥有者对它所拥有的对象隐含地具有CHECKPOINT、DUMP和

RESTORE的权限。

隐含权不包含执行任何形式的CREATE命令。例如，DBC创建用户ADMIN

后，ADMIN再在其空间下创建用户USERA，除非显式地授权，否则DBC不能在

USERA下创建用户、数据库或其它对象。事实上，如果DBC不将CREATE USER的

. 136 .

权限授予ADMIN，则ADMIN登录后也不能在它自己的空间上创建用户。这在下面

的自动权中还会谈到。

一个用户并不拥有它自己。因此，ADMIN创建用户USERA后，并不意味着授

予用户USERA任何形式的拥有权。换句话说，就是ADMIN没有授予用户USERA上

面谈到的两种形式的拥用权，因此，除非ADMIN显式地授权(通过WITH GRANT

OPTION)，否则USERA不能对它自己执行GRANT/REVOKE命令，以及执行

CHECKPOINT、DUMP和RESTORE命令。举例来说，当以USERA登录后，执行下

面的命令：

GRANT SELECT ON USERA TO ADMIN;

系统提示类似下面的错误信息：

The user does not have SELECT WITH GRANT OPTION access to database usera

即用户USERA不具有执行GRANT命令的权限。如果以ADMIN登录系统时，执

行：

. 137 .

GRANT SELECT ON USERA TO USERA WITH GRANT OPTION;

这样，USERA就具有将SELECT权限授予其它用户的权利。然后以USERA登

录，再执行前面同样的命令就不会提示出错了。

拥有权是唯一不可收回的权限。例如ADMIN对USERA具有拥有权，则任何用

户不能把ADMIN对USERA的拥有权通过REVOKE命令收回。另外，我们在后面还

有谈到系统表DBC.AccessRights，它记录了所有的权限，而拥有权是唯一不记录在

此系统表中的权限。

自动权限自动权限自动权限自动权限

自动权是指创建一个用户或其它对象时，由系统自动授予的权限。它也有两种

形式：

. 138 .

1、当创建一个用户时，系统将自动授予该用户对它自己进行操作的所有权

限，都是自动权限。这些自动权限包含哪些内容呢？让我们举例说明：ADMIN创

建用户USERA后，系统将自动执行下面的命令：

GRANT TABLE, VIEW, MACRO, SELECT, INSERT, UPDATE,

DELETE, DUMP, RESTORE, CHECKPOINT, EXECUTE

ON USERA TO USERA;

这些权限是USERA对它自己自动具有的权限。如果ADMIN创建的是数据库

DATABASEB，则系统将自动执行下面的命令：

GRANT TABLE, VIEW, MACRO, SELECT, INSERT, UPDATE,

DELETE, DUMP, RESTORE, CHECKPOINT, EXECUTE

ON DATABASEB TO DATABASEB;

2、当创建一个用户时，系统将自动授予创建者对被创建用户进行操作的所有

权限，这是自动权限的第二种形式。那么，这些自动权限又包含哪些内容呢？仍以

. 139 .

上面的例子来说明：ADMIN创建用户USERA后，除自动执行上面的命令外，还将

自动执行下面的命令：

GRANT USER, DATABASE, TABLE, VIEW, MACRO, SELECT,

INSERT, UPDATE, DELETE, WITH GRANT OPTION, DUMP, RESTORE,

CHECKPOINT, EXECUTE ON USERA TO ADMIN ;

如果ADMIN创建数据库DATABASEB，同样，系统还将执行下面的命令：

GRANT USER, DATABASE, TABLE, VIEW, MACRO, SELECT,

INSERT, UPDATE, DELETE, WITH GRANT OPTION, DUMP, RESTORE,

CHECKPOINT, EXECUTE ON DATABASEB TO ADMIN ;

上述两种形式的自动权限都将记录在系统表DBC.AccessRights中，每一个权限

就是该系统表中的一条记录。我们可以看到，自动权限不包含：

1、GRANT权限(通过WITH GRANT OPTION来完成)；以及2、对被创建者而

言，它在它自己空间CREATE/DROP用户或数据库的权限。

. 140 .

自动权是可以收回的。例如，对USERA来说，其任何拥有者(如ADMIN或

DBC)或其它对USERA具有REVOKE权的用户，可以将上述两种形式的自动权通过

REVOKE命令收回。如：

REVOKE USER ON USERA FROM USERA;

该命令即把USERA在其自己空间CREATE/DROP用户的权限收回了。当然，

作为其拥有者的ADMIN对它具有隐含的拥有权，因此，可以和上面的命令一样，

显示地执行下面的命令将被收回的权限再授予给USERA：

GRANT USER ON USERA TO USERA;

最后，根据上面两部分关于拥有权与自动权的讨论，我们可以得出下面的结

论：

! 拥有权是关于拥有者对其所拥有对象的访问权限，不可收回；

! 自动权是关于创建者与被创建者的操作权限，可以收回。

. 141 .

关于拥有权与自动权的一个例子关于拥有权与自动权的一个例子关于拥有权与自动权的一个例子关于拥有权与自动权的一个例子

下面用一个实例进一步说明拥有权和自动权。假设Teradata数据库系统的一部

分结构如图6-3所示：

DBC

ADMIN

USERADMIN ADMIN2

USER1USER2USER3USER4USER5USER6USER7USER8USER9

创创创

GRANT CREATE USER ON

USERADMIN TO ADMIN2;

CREATE USER USER9

FROM USERADMIN AS

PERM = 100000000 SPOOL = 50000000

PASSWORD = USER9;

图6-3 关于访问权限的一个实例

. 142 .

通过ADMIN登录系统后，执行了图中所示的命令：

GRANT CREATE USER ON USERADMIN TO ADMIN2;

这样，ADMIN2具有在USERADMIN的空间创建用户的权限。接下来，通过

ADMIN2登录系统，并执行图中所示的命令：

CREATE USER USER9 FROM USERADMIN

AS PERM = 100000000 SPOOL = 50000000 PASSWORD = USER9;

由于ADMIN2是USER9的创建者，故ADMIN2对USER9的访问权限记录被自动

加到系统表DBC.AccessRights中。这种自动权可以被收回。同样，USER9是被创建

者，故USER9对它自己的操作权限记录也被自动加到系统表DBC.AccessRights中。

这种自动权也可以被收回。

而用户DBC、ADMIN和USERADMIN都是USER9的拥有者，对USER9具有隐

含的拥有权。这种权限不会在系统表DBC.AccessRights中体现，也不可以被收回。

. 143 .

在任何需要的时候，这些拥有者均可通过显示的GRANT/REVOKE命令来把对

USER9的访问权限授予它们自己或其它用户。当然，此时会有相应的权限记录体现

在系统表DBC.AccessRights中。

6.4.26.4.26.4.26.4.2 显式权限显式权限显式权限显式权限

除了上面讨论的两种权限外，其它通过显式地执行GRANT命令而得到的权限

统称为显式权限。每执行一次显式地授权操作，就会有一条记录此权限的数据记录

插入到系统表DBC.AccessRights中去。

6.4.36.4.36.4.36.4.3 监控权限监控权限监控权限监控权限

监控权是用于控制对Teradata性能监视器的访问的。当具有这种监控权时，可

以监视和控制Teradata中的工作流程。如果因为某种原因，通过SQL的正常访问被

堵塞，如发生死锁或其它冲突，只要具有监控权，仍可以完成对系统的监控操作。

监控权包含以下种类：

. 144 .

表6-2 监控权限种类

权限缩写说明

MONITOR 指所有的监控权限

ABORTSESSION AS 中止任何正在进行或挂起的SESSION并退出

MONSESSION MS 收集所有当前登录的SESSION的信息以及系统资源使

用情况

SETSESSRATE SS 设置对系统监控的采样频率

MONRESOURCE MR 收集每个处理器可用性以及性能方面的信息

SETRESRATE SR 设置对处理器资源使用情况监控的采样频率

监控权也是通过GRANT/REVOKE命令来授予或收回的。

6.4.46.4.46.4.46.4.4 如何检查一个用户或数据库的权限如何检查一个用户或数据库的权限如何检查一个用户或数据库的权限如何检查一个用户或数据库的权限

当一个用户登录到系统后，如何检查它访问Teradata中各对象的权限呢？前面

已经谈过，系统的访问权限控制是记录在系统表DBC.AccessRights中，而拥有权则

不记录在此系统表中。为什么会这样呢？这是因为拥有权是根据对象的拥有关系

(父辈与后代)来确定的，而对象的这种拥有关系可以从另一个系统表DBC.Owners中

得到，因此不需要在DBC.AccessRights中再作记录。

. 145 .

前面已经介绍了如何检查一个用户或数据库具有哪些父辈以及哪些后代，通过

这些关系就可以确定拥有权。那如何检查一个用户或数据库的其它权限呢？由于

DBC.AccessRights是一个系统表，我们一般不直接操作该表。在对生产系统的管理

时，也不会把访问系统表的权限授予给其它任何用户。一般的做法是把对系统视图

的访问权限授予给相应的管理用户，这样比较安全。

Teradata中有一个系统视图DBC.AllRights，该视图记载了访问权限的所有信

息。如果要检查一个用户，比如用户USERA，所具有的任何权限，可以执行下面

的命令：

SELECT DatabaseName (FORMAT 'X(10)'),

TableName (FORMAT 'X(10)'),

AccessRight,

AllnessFlag

FROM DBC.AllRights

WHERE UserName = 'USERA';

系统返回类似表6-3的信息：

表6-3 访问权限返回举例

. 146 .

DatabaseName TableName AccessRight AllnessFlag

Usera All CU N

Usera All DU N

Usera All R N

Usera All U N

Usera All D N

Usera All CV N

Usera All CP N

关于该表的几点说明：

1、访问权限用一到两个字母的缩写形式来表示，参见表6-1和表6-2的缩写说

明。

2、如果权限被授予一个用户以及它的所有后代，那么AllnessFlag设置为"Y"，

否则设置为"N"。图中该标志均为N，表示这些权限不适应于USERA的后代。如果

在授权时，使用PUBLIC作为接收对象，则表示适应于所有用户。如：

GRANT SELECT ON USERA TO PUBLIC;

. 147 .

然后再执行下面的命令：

SELECT USERNAME,

DatabaseName (FORMAT 'X(10)'),

TableName (FORMAT 'X(10)'),

AccessRight,

AllnessFlag

FROM DBC.AllRights

WHERE AllNessflag = 'Y' AND DatabaseName='USERA';

系统返回：

UserName DatabaseName TableName AccessRight AllnessFlag

DBC usera All R Y

由此可知，DBC的所有后代均对USERA中的所有表具有SELECT权限(因为

AllnessFlag标志为"Y")

. 148 .

3、TABLENAME如果是"All"，表示该权限适用应数据库或用户(由

DATABASENAME指定)下的所有表。

6.4.56.4.56.4.56.4.5 GRANT命令的操作命令的操作命令的操作命令的操作

GRANT命令的一般格式如图6-4所示

ALL [PRIVILEGES]

ALL BUT privilege [, privilege] �

privilege [, privilege] �

MONITOR [PRIVILEGES]

MONITOR BUT NOT privilege [, privilege] �

UPDATE ([ALL BUT] ColumnName [, ColumnName] ?

REFERENCES ([ALL BUT) ColumnName [, ColumnName] ?

GRANT{ }DatabaseName

DatabaseNmae.ObjectName

ObjectName

* ON [ [] ]TOUserName [? UserName]

PUBLIC

ALL UserName

[WITH GRANT OPTION]

* MONITOR 注注注注界面家注注个注注注注详市分内注

. 149 .

图6-4 GRANT命令格式

图中大写字母表示关键词，小写字母表示要指定的对象或权限，中括号([ ])内

的内容为可选项。

需要强调的是，如果一个用户要把对一个对象的某种权限授予给其它用户，它

首先必须是此对象的拥有者，并且具有针对此权限的GRANT权利(即它的这种权利

在被给予时具有WITH GRANT OPTION选项)。

接收权限方可以是：

1、一个具体指定的用户或数据库；或

2、PUBLIC，表示整个Teradata中的用户与数据库。此时，在系统表

DBC.AccessRights中只会有一条针对DBC的记录，并且标志栏AllnessFlag为"Y"。这

是因为DBC是所有用户与数据库的拥有者。

3、ALL UserName，这里UserName是一个指定的用户与数据库。此时，被授

予的权限将适用于此指定用户或数据库的所有后代。换言之，在系统表

DBC.AccessRights中也只有一条针对接收方的记录，并且标志栏AllnessFlag为" Y

"。显然，ALL DBC与PUBLIC的作用是等同的。

. 150 .

6.4.66.4.66.4.66.4.6 REVOKE命令的操作命令的操作命令的操作命令的操作

REVOKE命令的语法和GRANT非常类似，如图6-5所示：

ALL [PRIVILEGES]

ALL BUT privilege [, privilege] �

privilege [, privilege] �

MONITOR [PRIVILEGES]

MONITOR BUT NOT privilege [, privilege] �

UPDATE ([ALL BUT] ColumnName [, ColumnName] ?

REFERENCES ([ALL BUT) ColumnName [, ColumnName] ?

REVOKE{ }DatabaseName

DatabaseNmae.ObjectName

ObjectName

* ON [ [] ]FROM

TO

UserName [? UserName]

PUBLIC

ALL UserName

[WITH GRANT OPTION]

* MONITOR 注注注注界面家注注个注注注注详市分内注

图6-5 REVOKE命令格式

. 151 .

当使用REVOKE命令从一个用户或数据库中收回某种权限时，在用户或数据库

前使用关键词FROM和TO是一样的，只不过在ANSI SQL中要求使用FROM。

为了执行REVOKE命令，发出此请求的用户必须具有被收回的权限，并且有

GRANT的权利(即有WITH GRANT OPTION选项)。

. 152 .

第七章第七章第七章第七章数据保护与恢复数据保护与恢复数据保护与恢复数据保护与恢复

从数据安全性方面来讲，Teradata达到了C-2级标准。我们在第六章中专门讨论

过系统的存取权限，这与安全性也有关系。本章将不再讨论存取权限的问题，而是

集中研究以下几方面的内容：

! 锁(Lock)

! 优先权(Priority)

! 交易完整性(Transaction Integrity)

! 临时流水(Transient Journal)

! 永久流水(Permanent Journal)

! FallBack保护

7.17.17.17.1 锁锁锁锁(Lock)

当系统中有并发用户时，必须有一种机制对数据记录进行保护，才能保证不同

用户访问到的是正确的信息。举例来说，当一个用户在更新一个表中的某条记录

时，另一个用户同时在读取这个表的相同记录。如果不加保护，后者访问到的就是

不完整或者不正确的信息。这种用来保护数据一致性的机制就是锁(Lock)。

. 153 .

Teradata系统中共有四种级别的锁，根据其级别从低到高的顺序排列如表7-1 所

示。

表7-1 Teradata中锁的类型及定义

ACCESS 当其它用户在对同一目标进行写操作时，允许对此目标进行读操

作。显然，这是一种级别最低的锁，有可能导致读出的信息不准

确。一般情况下它都不需要排队等候只有一种情况例外，那就是

当其它用户对同一目标持有下面要介绍的排他性锁(EXCLUSICE

Lock)时，它必须等这个排他性锁释放后才能进行操作。

READ 级别低于写(WRITE)锁和排他性锁(EXCLUSIVE)，因此只要当其它用

户对同一目标未持有这两种锁，就可以读取相应的信息。

WRITE 当对一目标有WRITE锁时，不允许其它用户对同一目标进行读写操

作，当然对使用ACCESS锁进行读数据的操作例外。级别仅低于排他

性锁EXCLUSIVE。

EXCLUSIVE 这是一种级别最高的锁，当持有这种类型的锁时，不允许其它任何

操作。一般用于修改数据库、表、视图的结构等场合。

表7-2总结了这四种锁的相互关系和排队等候情况：

. 154 .

表7-2 Teradata中四种锁的相互关系

申请所持有的锁

的锁无 ACCESS READ WRITE EXCLUSIVE

ACCESS 接受接受接受接受等候

READ 接受接受接受等候等候

WRITE 接受接受等候等候等候

EXCLUSIVE 接受等候等候等候等候

举例来说，如果一个目标已经被WRITE锁锁住，那么，当另外有READ、

WRITE以及EXCLUSIVE锁作用到此目标时，都必须等候，只有对此目标进行

ACCESS锁的操作才能接受。

那么我们要问，一个锁的作用域如何，是锁住一条记录、一个表或者是一个库

呢？这与实际的SQL操作有关系。Teradata锁作用域的基本原则是，在保证数据完

整性的前提下，尽可能小范围地上锁。例如，如果一个SQL语句是针对主索引PI或

者唯一次索引USI，在处理时可根据ROW HASH值唯一定位数据记录，因此在记录

级上锁，即只锁住具有相同ROW HASH值的数据记录。其它数据记录，既使在同

一个块中也能被其它用户同时访问。如果SQL语句中未提供主索引或者唯一次索

. 155 .

引，则必须进行全表扫描FTS(Full Table Scan)，因此必须锁住整个表。如果SQL语

句是对整个数据库进行处理，如创建、删除、修改库时，则必须在数据库这一级上

锁。

总结起来，在Teradata中，锁作用域从小到大有以下三种不同的作用范围：

! 记录级：在 SQL语句中提供了主索引或者唯一次索引时使用，根据索引值

可计算出 ROW HASH值，只锁住表中相同 ROW HASH值的记录。因此称

为 ROW HASH LOCK。

! 表级：作用范围为整个表，上锁后其它用户不能访问此表中的任何记录。

称为 TABLE LOCK。

! 数据库级：作用范围为整个数据库，上锁后其它用户不能访问此库中的任

何对象。称为 DATABASE LOCK。

根据上面的讨论，Teradata在处理SQL交易请求时，根据SQL语句的不同，所

上的锁也有区别。表7-3 总结了各种不同SQL操作下的上锁的类型以及作用域情

况。表中N/A表示Not Available，即不存在这种情况。

表7-3 Teradata中锁的类型、作用域与SQL操作的关系

. 156 .

SQL语句数据访问类型与锁作用域锁类型

PI或USI NUSI或FTS

SELECT ROW HASH TABLE READ

INSERT ROW HASH N/A WRITE

UPDATE ROW HASH TABLE WRITE

DELETE ROW HASH TABLE WRITE

CREATE, DROP, ALTER

TABLE

N/A TABLE EXCLUSIVE

CREATE, DROP,

MODIFY DATABASE

N/A DATABASE EXCLUSIVE

上表中总结了Teradata在处理SQL语句时自动上锁的类型以及锁的作用域，注

意这些锁是系统自动上的，Teradata也提供了一条命令来改变锁的类型。例如，对

表TableA已经上了READ锁，可以用下面的命令将其变为WRITE锁：

LOCKING TABLE TableA FOR WRITE;

. 157 .

需要注意的是，这种改变锁类型的操作只适应于从低级别的锁升级到高级别的

锁，只有READ锁可以降为ACCESS锁，其它降级操作都是不允许的。

在一些特别的情况下，系统中有可能发生死锁(DeadLock)。举例来说，用户A

在一个交易中对一个表的一条记录分别进行读(SELECT)与更新(UPDATE)的操作，

这可通过下面要谈到的BT与ET将两个SQL语句封装成一个交易。处理此交易时，

系统首先对表中的相应记录上一个READ锁。与此同时，用户B也对此表的同一条

记录进行读操作，这样，用户B也对此记录上了READ锁。现在用户A要对此记录作

更新操作，因此要把前面上的READ锁升级到WRITE锁。由于用户B也此记录已经

有READ锁，所以用户A必须等用户B的READ锁释放。恰好在此时，用户B也打算

更新此记录，也必须把前面上的READ锁升级到WRITE锁。显然，用户B也必须等

用户A的READ锁释放。这样就造成了死锁。

Teradata很快就能确定在一个AMP上造成的死锁，并通过将最后的交易回退

( ROLL BACK)而解决死锁问题。在不同AMP之间造成的死锁是通过分解器上的一

个后台进程来监测的，监测周期可由用户设定，监测出死锁后即可通过同样的方法

来解除。

. 158 .

7.27.27.27.2 优先权优先权优先权优先权(Priority)

Teradata中共设置了四种级别的优先权，从低到高分别是：

! 低(LOW)

! 中(MEDIUM)

! 高(HIGH)

! 急(RUSH)

Teradata根据每种任务优先级的不同，来安排相应的CPU服务策略。一个用户

在登录系统时可以决定以什么样的优先级登录，这是通过登录时使用的帐号字符串

(Account String)的前缀来决定的。每个用户可以设置200个不同的Account String，

每次登录时可以使用下面的格式来决定这个SESSION的优先级：

.LOGON UserName, Password, $L_TestName;

. 159 .

这里的ACCOUNT STRING是$L_TestName，前缀$L表示以低(LOW)优先级登

录。类似地，$M、$H、$R分别表示中、高、急等优先级。如果不指定ACCOUNT

STRING或未按上面的格式来写ACCOUNT STRING，则系统缺省为中等优先级。

表7-4总结了各种不同优先级所占用CPU服务的比较。

表7-4 Teradata中优先级汇总

优先级 ACCOUNT

STRING 前缀

说明

LOW $L 最低的优先级

MEDIUM $M 分配CPU服务时4倍于低优先级

HIGH $H 分配CPU服务时4倍于中优先级

RUSH $R 分配CPU服务时4倍于高优先级，一般保留给系统

管理员使用

ACCOUNT STRING除了可以决定登录优先级外，还可以包含一个表示日期或

时间的后缀，这样可以方便系统管理员的管理工作。

. 160 .

7.37.37.37.3 交易完整性交易完整性交易完整性交易完整性(Transaction Integrity)

在设计数据库系统特别是分布式数据库应用时，经常谈到所谓的二阶段提交

( Two-Phase Commit)，这实际上是为了保证交易的完整性而设计的。一个数据库交

易可以由一个或多个SQL语句组成。举例来说，如果一个交易由两条SQL语句组

成，假设第一条语句完成后系统发生故障，第二条语句未完成，这时的情况怎样

呢？在Teradata中，一个交易要么全部完整，要么全部失败，不可能出现部分完成

的情况。这样可以保证数据的完整性。在刚刚举的例子中，如果第一条语句执行后

发生故障，则系统在重启后将根据日志自动恢复到第一条语句执行前的状态。

那么Teradata中怎样决定一组SQL语句是一个交易还是几个交易呢？换言之，

如何确定交易的边界呢？表7-5回答了这个问题。

表7-5 Teradata中交易边界的确定

处理环境说明

预处理器在BT(Begin Transaction)与ET(End Transaction)之间的所有

. 161 .

SQL语句是一个交易

Teradata Macro 在一个宏内的所有SQL语句是一个交易

BTEQ或其它前端工具在分号之间的所有SQL语句是一个交易。换言之，一个

SQL交易应以分号结束

7.47.47.47.4 临时流水临时流水临时流水临时流水(Transient Journal)

临时流水在保证交易的完整性方面也有很大的作用。每次数据发生变化前，系

统都会自动维护一个交易前的备份，当交易成功后，此临时备份将自动被删除。显

然，临时流水是由系统自动维护的。

7.57.57.57.5 永久流水永久流水永久流水永久流水(Permanent Journal)

和临时流水不一样，永久流水是由用户自己定义来创建的，系统不会自动删

除。

永久流水有两种，即所谓的前像流水(Before Image)与后像流水(After Image)。

前者表示在数据变化前对要变化的原始数据作一备份，后者表示在数据变化后对变

. 162 .

动过的数据作一备份。不管是前像流水还是后像流水，都需要用户手工定义来创

建。创建时可以只定义一种流水，也可以两种都定义。

永久流水有什么作用呢？先看前像流水(Before Image Journal)。这种流水记录

了数据发生变化前的状态，如果在一些应用程序的处理出错时，比如数据加载完后

发觉有问题，这时可以使用前像流水来恢复到数据加载前的状态。配合校验点

(Checkpoint)，可以恢复到指定的某一点。总的来说，前像流水主要是用来保护应

用软件出错的情况。

再看后像流水（After Image Journal)。这种流水记录了数据发生变化后的状

态，主要用来进行增量备份与恢复。例如在备份大型数据库时，有些表特别大，大

到不能在一天的时间里完成备份，而平时系统要正常使用，这时可以使用后像流

水，每次只备份发生变化的一部分数据，到周末时再作完整的备份。这就是所谓的

增量备份。如果发生硬件故障，如磁盘出错，可以使用后像流水逐步恢复到发生故

障前的状态。这就是所谓的增量恢复。因此，后像流水可以用来保护硬件出错的情

况。

有关流水以及数据的备份与恢复的详细讨论请参见"Teradata实用程序和工具"

一书。

. 163 .

7.67.67.67.6 FallBack保护保护保护保护

为了加强系统的安全性和高可用性，Teradata还提供了一个FallBack的选项，它

也是人工定义的。

FallBack的原理很简单，就是在磁盘的另一个位置再保存一份相同的记录，这

样，当原始数据所在存储单元发生故障时，可以使用其备份，并且不会中断原来的

交易处理过程。当然，这是以额份的存储空间作为代价的。

定义一个表时，可以定义该表使用"FALLBACK"选项或者"NO FALLBACK"选

项。当使用FALLBACK选项后，该表中的每一条记录除了有一个主存储位置外，

还会在另一个地方有一个相应的备份。显然，为了保证安全，备份记录必须与主记

录不在同一个AMP上。

假设系统中有100个AMP，当某个AMP，假设是AMP 1，所控制的存储单元发

生故障时，所有其它99个AMP将接管其工作。换言之，AMP 1所管理的所有数据记

录的FALLBACK备份均匀分布在其它99个AMP所控制的存储单元上。这样，当一

个AMP发生故障时，系统性能下降了1%，几乎可以忽略不计。

仔细再考虑一下，如果AMP 1发生故障后，又有一个AMP 5发生故障。这种概

率(100个AMP中2个发生故障，概率为2%)还是有可能的。此时，由于AMP 1的所

. 164 .

管理数据记录的FALLBACK备份中有一部分在AMP 5上，因此，当两个AMP发生

故障时，系统就不能对外提供服务了。这种处理方式显然不合适。

为了解决此问题，Teradata引入了组(Cluster)的概念。把系统中的所有AMP按

照CLUSTER进行分类，如四个AMP为一个CLUSTER，如图7-1所示。图中各AMP

下的数字表示数据记录号，存储单元中横线上方的记录是正常的主记录，横线下方

的记录是FALLBACK的备份记录。AMP 1、AMP 2、AMP 3、AMP 4组成一个

CLUSTER，每个AMP所管理的数据记录的FALLBACK备份必须分布在同一个

CLUSTER中其它AMP的存储单元上。

当一个CLUSTER中某个AMP发生故障时，该组中其它AMP将接管其工作，这

样，系统性能将下降1/4。如果另一个CLUSTER中再有AMP发生故障，比如

AMP5，则此CLUSTER中的其它3个AMP也将接管AMP 5的工作。当同一个

CLUSTER中有两个AMP发生故障时系统才不能提供服务，这种概率相对来讲就很

低了。仍以 100个AMP为例，如果以4个AMP作为一个CLUSTER，则系统中共有25

个 CLUSTER，最多能允许25个AMP发生故障。当然，每有一个AMP发生故障，对

性能的影响也比较大，下降了1/4。

一般来说，在一个CLUSTER中可以配置2至16个AMP。这种配置可以动态调

整。

. 165 .

CLUSTER 4 AMP界界界界完完完完系系系系完完完完

114 382234 508 2762 5 1978

741 66 17 37 722 45882058 93



8 6222345 19 2750 78114 38

17 3772 24588 205893 7 41 66

图7-1 每个CLUSTER 4个AMP时的FALLBACK保护

对于图7-1所示的系统，如果调整为每个CLUSTER 2个AMP，则可以表示为图

7-2。

. 166 .



CLUSTER 2 AMP界界界界完完完完系系系系完完完完

114 382234 508 2762 5 1978

741 66 17 37 722 45882058 93

8 27 62223450 5 197811438

741 6620 5893 245 8817 37 72

图7-2 每个CLUSTER 2个AMP时的FALLBACK保护

当使用FALLBACK来保护数据时，系统可用性大大提高了，代价是增加了一

倍的存储空间。由于现在硬件的可靠性越来越高，因此除了特别重要的场合，如

REUTERS的信息发表系统，一般可以不使用FALLBACK进行保护。

在Teradata的MPP环境下，我们在第二章中已经介绍了，在存储单元这一级一

般可使用RAID 5或者RAID 1来进行保护，在结点级可以通过簇(Clique)来提供高可

. 167 .

用性，在BYNET这一级，由于BYNET是两路双工同时运行，互为备份。因此

Teradata整个系统的高可用性是非常突出的。

. 168 .

第八章第八章第八章第八章客户端访问客户端访问客户端访问客户端访问Teradata数据库的方法数据库的方法数据库的方法数据库的方法

8.18.18.18.1 概述概述概述概述

和其它商用数据库系统一样，Teradata也是一种关系型的数据库管理系统，支

持标准的ANSI SQL语言，并在此基础上作了一些扩展。因此，从客户端来访问

Teradata，实际上就是客户端把SQL交易请求传递到Teradata中，然后接收从

Teradata来的处理结果。

总的来说，从客户端访问Teradata可以在两种环境下进行：一、通过以通道

(Channel)连接的封闭主机来访问Teradata；或者，二、在TCP/IP网络环境下来访问

Teradata。图8-1总结了这两种访问方式。

. 169 .

CLI

面面程序

PC/ (TCP/IP )信操、并并封封面封

TeradataRDBMS

面面程序

CLI

ODBC

VB, 开知信信维开VC, PowerPuilder, Centura, OLAP处各 Tools 封

面面程序

C, Cobol 封预详详指

CLI

图8-1 前端访问Teradata数据库的两种方式

. 170 .

在封闭主机环境下，所采用的编程接口是调用层接口CLI(Call Level

Interface)，编程语言可以是嵌入C、COBOL等高级语言的预处理器，当然也可以直

接通过CLI来进行应用的开发。

在开放网络环境下，所用的编程接口既可以是调用层接口CLI，也可以是由

NCR公司提供的ODBC驱动程序。编程语言较多采用嵌入C的预处理器。如果使用

ODBC来访问Teradata，则更多地采用一些Client/Server下的开发工具，如Visual

Basic、Visual C/C++、PowerBuilder、Centura等，当然也可以使用一些专门的信息

存取工具如 GQL、BRIO、Cognos、SAS等。

8.28.28.28.2 Teradata数据库的编程接口数据库的编程接口数据库的编程接口数据库的编程接口

8.2.18.2.18.2.18.2.1 调用层接口调用层接口调用层接口调用层接口CLI

首先来看一下Teradata最基本的编程界面，即调用层接口CLI (Call Level

Interface)。CLI是作为前端开发工具提供给用户的，它实际上由9个子例程组成，分

别控制与Teradata会晤层的建立、SQL交易请求的递交、返回结果的提取等。CLI有

针对封闭主机的版本，也有TCP/IP网络环境下的版本。在Client/Server结构下，既

可以在UNIX机器下进行开发，也可以通过PC或工作站在Windows 95/98/NT下进行

. 171 .

开发。如果在Windows环境下，可以使用Visual Basic或其它开发工具来编程，非

常方便。CLI在Windows环境下的版本称为WinCLI。

在Windows环境下所开发的应用程序，一般都具有非常好的图形界面GUI

(Graphical User Interface)，而且有许多方便而且成熟的开发工具可以使用，能大大

缩短开发周期，因此WinCLI使用得非常广泛。例如NCR公司专门针对Teradata开发

的一个系统管理程序Teradata Manager，就是在WinCLI上面开发的。利用Teradata

Manager，可以非常方便而且直观地在PC上管理多个Teradata数据库系统。

利用CLI来开发应用软件，速度非常快。另外，也可以同时提交多个交易请求

给Teradata，进行并行处理。

8.2.28.2.28.2.28.2.2 嵌入式预处理器嵌入式预处理器嵌入式预处理器嵌入式预处理器

Teradata针对多种高级语言提供了可嵌入SQL语句的嵌入式预处理器，如C、

COLBOL、PL/I等。当然，最常用的还是基于C语言的嵌入式预处理器。这些软件

也有两个版本，分别在UNIX和WINDOWS环境下运行。

. 172 .

8.2.38.2.38.2.38.2.3 ODBC

很长一段时间以来，虽然SQL已经形成了一个标准，但在访问数据库的界面上

却一直没有得到统一。各个数据库厂商都提供了自己独特的网络连接界面，用户在

开发应用程序时不得不考虑多种编程界面，对应用软件作移植时非常麻烦。在这种

情况下，一些主要数据库厂商共同组成了一个所谓的SQL访问小组(SQL Access

Group)，决定制定一个共同的开放数据库互连ODBC (Open DataBase Connectivity)

标准，以统一对不同数据库系统进行信息访问的界面。这个组织作了许多的讨论，

但却没有取得实质性的进展。最后，Microsoft公司决定自己先开发出一个能实际应

用的ODBC标准来。他们很快在Windows环境下开发出一套ODBC的标准和相应的

驱动程序，并迅速得到了数据库厂商和其它开发厂商的认同，目前已成为事实上的

工业标准。几乎所有的第三方应用软件或工具软件开发厂商所开发的软件都能通过

ODBC和数据库系统进行连接，如Visual Basic、PowerBuilder等均能直接开发

ODBC界面的应用软件。

Microsoft公司开发了一个ODBC的管理程序(ODBC Manager)，提供了一个标准

的调用界面。其它各个数据库厂商所开发的ODBC驱动程序都必须按照规定的调用

界面来和ODBC管理程序进行交互。前端用户在开发应用程序时，所调用的ODBC

函数通过ODBC管理程序引导到相应的驱动程序来进行处理。ODBC管理程序位于

Windows的控制面板(Control Panel)下，进入后可以增加(Add)、删除(Remove)、或

. 173 .

者配置(Configure)各个数据源(Data Source)，每个数据源都对应一种数据库的ODBC

驱动程序，前端程序对ODBC的调用是通过数据源来进行的。

8.38.38.38.3 Teradata应用工具应用工具应用工具应用工具

Teradata数据库具有丰富的应用工具，用来对数据库进行备份、数据加载等，

这里简单介绍一些常用的几种工具，它们分别是：

! BTEQ

! FastLoad

! MultiLoad

! FastExport

! TPump

以上这些工具的最大特点是全部都是并行处理的，因此处理速度非常快。

这些工具都是基于CLI来开发的，既有封闭主机下的版本，也有开放网络环境

下的版本。目前除TPump外，其它均可在UNIX和DOS/Windows两种环境下运行。

它们的运行方式有两种，一种是交互式的，另一种是批处理方式。在批处理方式

. 174 .

下，需要编写一些脚本(Script)文件，除BTEQ外，一般我们都使用批处理方式。下

面简单介绍各个工具的基本特点，详细的使用方法可参见相关的编程手册。

8.3.18.3.18.3.18.3.1 BTEQ

BTEQ是Basic Teradata SQL的缩写，是最早也是最基本的访问Teradata的一个

工具，其主要功能如下：

! 通过交互方式或批处理方式来向 Teradata递交 SQL交易请求；

! 提供一个简单却功能完整的报表生成器(Report Writer)；

! 具有 EXPORT功能，把数据输出到用户定义的文件中；

! 具有 IMPORT功能，对用户指定的表进行记录的加载、更新、或者删除；

! 对性能进行统计分析；

! 根据返回的错误代码进行有条件的处理，这类似于 DOS下批处理文件的处

理方式；

! 具有完整的 HELP功能。

我们在Teradata SQL介绍中将更加详细地介绍BTEQ的功能和使用方法。

. 175 .

8.3.28.3.28.3.28.3.2 FastLoad

FastLoad是一种数据加载工具，用来把外部源数据加载到数据库中，加载过程

是完全并行的。在开发这个软件时，所追求的主要目标是速度，因此在功能上不如

BTEQ那么丰富。它只能用来作数据的加载，并且所加载的表必须是空表。而

BTEQ就没有这些限制，在作数据加载的同时，可以根据条件更新或者删除其它表

中的数据记录。

开发FastLoad的基本思想是：在加载数据时，系统花了较多的时间用来处理磁

盘输入输出，如果能减少磁盘I/O的次数，就能大大提高数据加载速度。我们还记

得，在第三章介绍数据分配时讲到，Teradata存储数据记录是按块进行的，每个数

据块为64K。数据记录的定位是根据基于主索引的ROW HASH值来确定的，在数据

块内与数据块之间各数据记录按ROW HASH的升序存放。因此，当往一个空表中

加载数据时，如果按照相同的规律在内存中组成一个较大的文件后再一次写到磁盘

上，就能大大提高数据加载速度。这就是FastLoad的基本原理。

FastLoad一般以批处理方式工作，这时需要事先编写一个脚本。它的特定可以

概括为以下几点：

! 只适用于往空表中加载数据。如果不是空表，可以先创建一个临时表，加

载完全再合并到原来的表中；

! 可在多个平台下工作，如封闭主机、UNIX平台以及在Windows环境下；

. 176 .

! 具有校验点(Checkpoint)和重启动(Restart)的功能。这在处理大批量数据时

特别有用。举例来说，如果一个文件中有 100万条数据记录需要加载到一

个表中，在批处理方式下，如果加载到 50万条记录时因为某种原因发生故

障而中断，如果没有校验点和重启动的功能，必须从头开始，这将浪费很

多时间。如果设置校验点为 4万，这样，如果在加载完 50万条记录后产生

故障，则系统在重启动时，将自动从第 48万条记录开始处理。这样效率

显然要高很多。

! 可以设置允许出错(如不符合条件的数据记录)的上限，同时能给出出错的

报告，便于调试。

! 支持 INMOD例程。由于 FastLoad脚本只能处理固定格式的外部文件，如

果一些数据文件的格式没有一致的规律，必须用程序先对其进行处理。

INMOD就是这样一种例程，它可以通过共享代码的形式与 FastLoad同时

使用。可以用 C、COBOL等来编写 INMOD程序。

! 在作数据加载时，比所有其它工具都快。

. 177 .

8.3.38.3.38.3.38.3.3 MultiLoad

FastLoad虽然很快，但功能上有很多限制；BTEQ功能很强，但在作数据加载

时没有校验点与重启动的功能。考虑到这些限制，NCR公司决定开发一个结合两者

优点的工具来进行数据的加载、删除和更新，这就是MultiLoad。

MultiLoad一般也以批处理方式工作，需要编写一个脚本文件。在给一个表加

载数据的同时，可以同时对其它表中的数据记录按照规定的条件进行更新或者删

除；它的处理速度没有FastLoad快，但比BTEQ要快很多。MultiLoad的主要特点可

以概括为：

! 支持完整的 SQL语法(除 SELECT外)。

! 发生故障时可以自动重新启动，不需要人工干预。

! 支持条件处理命令，如.IF、.ELSE、.ENDIF等。

! 支持用户定义和系统定义的变量。

! 可以同时(指一个MultiLoad操作)对五个表进行 20个插入(INSERT)、更新

(UPDATE)、删除(DELETE)操作，这些数据库操作要么完全成功，要么全

部失败，因此保证了数据库的完整性。

! 支持 INMOD程序。

. 178 .

8.3.48.3.48.3.48.3.4 FastExport

FastExport用来将数据从数据库中备份出来，一般也以批处理方式工作。它可

以和Teradata数据库同时建立多个会晤，即在处理一个脚本时自动建立多个连接，

因此备份速度很快。

FastExport具有自动重启动的功能，当发生某种故障而中断时，只需要重新递

交这个作业，系统能从原来中断处重新开始。

8.3.58.3.58.3.58.3.5 TPump

TPump可以实现和MultiLoad类似的功能，两者的主要区别在于：

! MultiLoad特别适合于大量数据的处理，而 TPump则在处理相对少量的数

据时更为有效，因此 TPump可用来进行数据的实时更新、加载等处理。

! MultiLoad同时最多允许 15个进程运行，而 TPump没有此限制。

! 相对而言，MultiLoad要耗费系统更多的资源，但它的速度也比 TPump要

快一点。

. 179 .

第九章第九章第九章第九章使用使用使用使用Teradata的主要客户分析的主要客户分析的主要客户分析的主要客户分析

Teradata是专门针对决策支持系统的特点而开发的关系数据库管理系统。根据

1996年在美国召开的大型数据库会议VLDB (Very Large Database Conference)的统

计，Teradata分别支持着目前世界上最大的数据库系统、最大的表以及最多的并发

用户数(指同一时刻访问数据库的用户)。

现在，NCR在全世界已经帮助1000余家客户实施了数据仓库系统，这些数据仓

库都由Teradata来驱动。各种环境下的实际应用充分显示了Teradata作为数据仓库专

用引擎的能力。

NCR公司每年都要召开一次全世界范围的Teradata用户大会，届时大部分

Teradata用户都将来参加，一起交流使用Teradata构造数据仓库应用的体会。如果我

们把这些使用Teradata的客户进行分类，大致可以分为以下9个行业：

! 零售业

! 消费品制造与零售业供货商

! 货运业

! 客运业

! 电信业

! 健康保险业

. 180 .

! 金融业

! 共用事业类

! 其它

我们将分别根据以上9个行业的应用来进行简单的介绍。

9.19.19.19.1 零售业零售业零售业零售业

对于大型的连锁超市集团公司来说，往往具有几百家甚至几千家分布在各地的

分店，他们都利用自动收银机POS等终端进行交易，这些终端都与总公司的中心数

据库连网。这样，在其生产系统中积累了大量的详细交易数据，蕴含了许多与业务

发展有关的有用信息。为了探索业务规律，必需把这些历史交易数据按一定的方式

转换到中心数据仓库中进行分析。主要的应用领域是以下几个方面：

! 商品的采购，价格的制定以及库存的管理

! 商场配置与货架排列

! 促销活动的策划

对比Wal*Mart和Sears两大零售业巨头的财富变化就能了解数据仓库对企业的

发展有多大的作用。直到1980年，Sears都是美国的第一大连锁超市集团，其零售

. 181 .

业霸主地位维护了几十年。从1980年起，Wal*Mart集团开始大量投资信息技术，他

们购买了Teradata，和NCR一起建立了世界上第一个数据仓库系统，用来帮助业务

人员和高层管理人员作出更好的决策。Teradata在Wal*Mart的成功，一直被业内人

士作为数据仓库成功应用的经典故事而广泛传诵，特别是所谓的"啤酒与尿布"的故

事，更是一时传为佳话，经常被媒体引用。从1986年起，Sears公司的营业额平均

每年增长4.3%，而利润率则从4.9%降到1.2%。与此同时，Wal*Mart公司的营业额

平均每年增长28%，利润率保持在4%以上。如果我们把这单纯地看成是一种巧

合，那么后来发生在Sears的故事就很难解释了：从1985年开始，Sears公司认识到

数据仓库系统在激烈的市场竟争环境下所起的关键作用，决定投资Teradata来建立

数据仓库系统，很快就实现了后来被《经济学家》杂志所评价的"历史上的最大转

折"。

其它使用Teradata建立数据仓库系统的零售商还有美国的Kmart, Meijer, Kohl's,

American Stores, Mervyns, Buttrey Food and Drug, QVC, 加拿大的Canadian Tire，英

国的WH Smith Books, Great Universal Stores，法国的Casino Supermarkets，瑞士的

Migrosgenossenschaftsbund，德国的Otto Versand以及澳大利亚的Pacific Dunlop等。

. 182 .

9.29.29.29.2 消费品制造与零售业供货商消费品制造与零售业供货商消费品制造与零售业供货商消费品制造与零售业供货商

这种行业的厂商和批发商类似，向上面提到的零售集团提供大量的消费品与其

它商品。一般来说，在商品卖给最终客户之前，他们是拿不到钱的。也就是说，他

们生产的商品以"托销"的形式经由上面谈到的零售商经销。利用Teradata，这些厂

商可以探索以下这些非常关键的业务问题：

! 商品如何定价；

! 某种商品应该生产多少才能保证适时供货，做到既不过量也不缺货；

! 如何衡量市场促销活动(包括广告、赠券等)的效果。

许多零售商和供货厂家都利用Teradata来共享一些业务信息，从而使零售商能

更好地进行库存管理，降低营销成本，这样才能降低商品价钱，最终客户和商家都

能得到更多的利益。

举例来说，在1993年夏天，全球家用电器制造厂商Whirlpool公司的一位工程

师通过数据仓库发现在已售出的几百台洗衣机中，有一个软管夹子装错了。他们迅

速采取措施，将正确的零件分发给用户，从而避免了由于漏水而造成进一步的财产

损失。如果真地发生这种情况，显然Whirlpool公司需要负责赔偿。

. 183 .

在这一行业使用Teradata的主要用户还有：Coca-Cola, Nike, Procter & Gamble,

Hallmark, Maybelline, Helene Curtis, 3M, Owens, Corning Glass, Karsten Ping以及Walt

Disney Home Video。

9.39.39.39.3 货运业货运业货运业货运业

在货运行业，承运商要把大量的货物运输到各个不同的城市及港口，所使用的

工具无非是船、大型卡车、飞机与火车。上面提到的大型零售集团及其供货商都是

货运行业的主要客户。在长期的经营活动中，承运商们的信息系统中保留了许多非

常有价值的历史数据，主要是关于：

! 每次货运的容量、接货与交货时间；

! 运输的成本、营业额与利润；

! 设备、运货单与提货单等。

通过综合分析这些信息和合理安排运输时间，既可以降低运输成本，提高利

润，又能帮助客户做到：

! 将原材料适时地送到生产工厂；

! 适时地生产与制造；

! 恰到好处的库存管理。

. 184 .

这样才能留柱更多的客户，特别是一些大型的客户，因为这些客户给公司带来

的利润最多，应该尽量给他们提供最好的服务。

美国的Conrail铁路运输公司指出，利用Teradata建立的数据仓库在帮助他们从

卡车运输公司手中抢回一些原来失去的大客户时起了很大的作用。在1994年召开的

Teradata用户大会上，该公司的客户后勤部主管Jim Horgan先生深有感触地谈到， "

现在我们能回答一些在三年前甚至不能想象的业务问题，而这些问题对我们公司的

业务发展又确实很重要。"利用Teradata，Conrail公司的业务人员能够更加精确而有

效地安排列车长途运输计划，并且更好地协调不同运输方式下的结算问题。当遇到

坏天气或自然灾害时，能够更加迅速地作出反应，调整运输计划。比如在1993年发

生密西西比河大洪水时，公司就非常迅速地调整了原来的运输路线，从而使客户避

免了损失。这样既保证了公司的利润，又取得了客户的信任，从而能把一些大客户

长期地留在公司。

以一个普通的工作日为例，Conrail公司要跟踪记录100000节列车车厢、1237列

列车以及不计其数的集装箱的信息，如果一次运输延误的话，将不可避免地使一些

工厂的装配线停止，由此产生的经济损失是很难估算的。因此，准时已经不再是一

种追求的目标，而是对运输行业的一项基本要求。

在运输行业使用Teradata建立数据仓库的用户还有：Burlington Northern Santa

Fe, Union Pacific, Norfolk Southern, American President Lines, Delta, QANTAS, British

Airways, American Airlines以及Canadian Airlines。

. 185 .

9.49.49.49.4 客运业客运业客运业客运业

这类行业主要是指航空公司的客运部分，现在国际上各航空公司之间竟争非常

激烈，因此，他们非常需要使用Teradata来解决下面的问题：

! 航运市场研究与针对常飞旅客的促销活动

! 客运量规划

! 利润与成本的核算

! 质量管理与客户服务

美洲航空公司是最早实施常飞旅客计划的，在1981年会员已达到一百万人，

1986年为三百万，而到了1994年已达到二千六百万。在其称为SABRE的订座系统

中积累了大量的历史交易数据，该系统由IBM最先进的十二台封闭主机组成，每天

要处理一百五十万条交易并增加约8000个新的会员。由Teradata驱动的数据仓库则

运行在NCR的WorldMark系列计算机平台上，每周约有35GB的原始数据以批处理

的方式从SABRE订座系统中装载到数据仓库中，进行各种分析和处理。举例来

说，美洲航空公司在给客户寄促销活动通知或奖券时，不像一些航空公司一样不加

区分，只要是乘过公司航班的旅客就寄。他们的做法是先在数据仓库中进行筛选，

. 186 .

根据一些综合评比的标准，找出比较好的客户，然后再有针对性地寄信。几年以

来，他们利用此系统共寄出了一亿五千万封促销信件，单这一项就为美洲航空公司

节省了约一亿美元。

在这一行业使用Teradata实施数据仓库的航空公司还有：美国的Delta航空公

司、德国的Lufthansa、澳大利亚的QANTAS、英国的British Airways、加拿大航空

公司等。

9.59.59.59.5 电信业电信业电信业电信业

NCR公司在国外电信行业有着非常成熟的数据仓库解决方案。由于很多国家的

电信市场处于自由竟争状态，有关企业迫切需要采用决策支持系统来解决诸如客户

行为分析、利润分析、预防欺诈等方面的问题。从国内的情况来看，经过这几年的

市场培育和快速成长后，经营环境也在产生激烈的变化：在外部经营环境上，如客

户对电信单位服务质量要求提高、来自有线电视宽带网的威胁、卫星传输的便利

性、无线寻呼和ISP业务经营的开放、Internet电话技术的出现等；内部环境上，如

邮政电信分家和内部机构调整、电信业务服务内容重叠造成相互竞争、盗用电话的

客户增加等等；所有这些因素使得电信经营所面临的问题更加复杂，营运成本大幅

增加，市场也相对进入成熟期，市场竞争比较激烈。如何在满足客户需求的前提

. 187 .

下，充分使用现有投资设备，达到降低成本、增加创收的目标是电信企业主管应该

关心的课题。

当前电信业巨头AT&T公司是Teradata最大也是最早的用户之一，它拥有数以

亿计的客户和巨大的网络资源，无论是在有线电信还是在无线通信方面都有强大的

实力。AT&T公司利用Teradata建立了几个数据仓库，分别解决以下各方面的问

题：

! 市场与销售

! 采购与库存管理

! 出租线路与租借线路的管理

! 财务、资金以及计费的管理

! 生产制造与发货渠道的管理

! 网络资源的管理与规划

! 客户行为分析

除了AT&T以外，世界上一些大型的电信公司都是NCR的用户，他们都使用

Teradata来建立数据仓库，帮助业务人员和公司主管来作出更有效更合理的分析和

决策。这些大型用户包括：Ameritech、比利时电信Belgacom、英国电信British

Telecom、美国的Bell South、Bell Atlantic、Motorola、GTE、Sprint、新西兰电信、

意大利电信、澳大利亚电信、爱尔兰电信、瑞典电信、加拿大联合电信等。

. 188 .

根据国外这些电信公司的发展经验，在市场成熟期间一个电信公司的成功经营

之道应该是：以更好的服务留住有利润的客户，提高通话量和利用率，用比竞争者

更低的成本争取到新客户，扩大市场份额；放弃无利润和信用差的客户，降低营运

风险和成本。NCR公司针对电信业的数据仓库解决方案称为Yield Management，正

是在这种指导思想下开发出来的。

9.69.69.69.6 健康保险业健康保险业健康保险业健康保险业

一个国家的全民素质高低，人口受教育程度是一个方面，人民的身体健康程度

则是另一个方面。如何保障人民的身体健康，除了需要有好的医疗设施，良好的健

康保证环境和完善的保险体制也是非常重要的。在这个行业，由于牵涉面很广，数

据源很杂，因些特别需要采用一个集中式的数据仓库，将各种信息集中起来进行分

析和处理。

台湾健康保险局就是一个很好的例子。信息系统建设是台湾健康及医药卫生改

革的重要组成部分，建立一个全面而完善的信息系统对于台湾健康保险局进行高效

率的运做是必不可少的，NCR公司帮助他们建立了这套系统。

台湾健康保险局的信息系统采用了Unix开放系统，关系型数据库和分布式客户

服务器的结构，联机用户有1700多位。两年内台湾健康保险局收集的数据包括45万

. 189 .

被保险单位的资料、3万家医院、7万家药店、2千1百万保险人的资料、每月2千万

门诊病人的申报资料以及每月20万住院病人治疗的申报资料。

为鼓励医院和卫生所通过电子方式提交请求，减低局内和医疗机构人员的工作

量，同时让医疗机构能于最快时间内拿到款项，规定如果医院和卫生所在截止日期

前提交电子方式申请，那么将可以保证在15天内支付款项。如果通过纸介质提交的

申请，将在30天内支付款项。自从引进这套系统以后，门诊病人通过电子方式提交

申请的比例超过90%，住院病人通过电子方式提交申请的比例超过95%。

在交易系统建立后的第二年，为保障被保险人的权益，防止不法分子与医疗单

位串通冒领保款，及有效制定医疗保险政策，台湾健康保险局于1997年委托NCR设

计数据仓库系统。目前该系统主要有三个子系统，分别为业务管理、医疗受益和财

务管理，提供保险人、专家学者及政府单位各种分析报告及提出决策应用。

将来的目标将集中在增强系统功能、减少人工处理工作量、增加处理速度和能

力、开发新的医疗服务、医疗资源分析、病人档案分析，并开发一个数据仓库原型

系统进行交互的动态分析和决策支持。

美国Anthem健康保险公司则是应用数据仓库提高经营业绩和服务质量的另一

个成功案例。它是由原来三家保险公司合并而成，年保险额为60亿美元，有超过6

百万的投保人，35万受益人，涉及美国多个州。这就意味着大量的信息需要调查，

如出险人是否有诈骗保险金的嫌疑；评价新政策的保险冒险性；通过更好的评价信

. 190 .

息来改善销售和服务。这都需要建立一个技术结构来确保公司一些战略计划的成

功，当然也需要满足公司未来的发展。

为了满足Anthem公司这种需求，NCR公司为其设计了完整可扩展的数据仓

库，它把原来三家保险公司的数据库整合成了一个大的集中式的数据仓库，而且为

多种商业用途准备了一种解决方案。由此一来，用户不用为一些信息等待几天或是

几个星期，而是马上就能够执行快速的复杂查询和分析，这在以前是不可想象的。

而且该数据仓库能够帮助Anthem公司减少失误，和受益人洽谈降低赔率，正确管

理风险，提高质量和投保人的投保款额。

除了上面介绍的两个企业外，其它采用Teradata建立数据仓库的健康保险业客

户还有：美国蓝盾保险公司，美国奥马哈互助会，健康联合协会等。

从我国的情况来看，由于目前公费医疗制度正面临重大改革，保险机构必须做

好充分准备以适应改革的发展需要。我国的很多保险公司虽然已建立了交易系统，

但随着医疗保险市场开放，竞争日趋激烈，保险业务也将更加复杂。要想在医疗改

革的潮流中提高服务质量，增强竞争力，提高经营业绩，建立数据仓库将是他们正

确的选择。

. 191 .

9.79.79.79.7 金融业金融业金融业金融业

在金融行业扮演主角的银行利用Teradata建立的数据仓库可以实现所谓的关系

银行(Relationship Bank)，因为对银行而言，对客户的管理以及与客户保持良好的

关系是非常重要的。

一般来说，银行都已经建立好面向应用的各种生产系统，如储蓄系统、信用卡

系统、贷款系统等，和客户进行交易的渠道也很多，如分行营业处、自动取款机、

呼叫中心、邮寄、Internet网等。在长期的经营活动中，这些系统中积累了大量的历

史数据，通过对这些数据的综合分析可以挖掘出许多对银行业务发展至关重要的信

息和规律。我们常常把各个生产系统的数据按照主题建模的方式集中到中央的数据

仓库，以便解决以下方面的问题：

! 对客户行为的分析

! 客户的分段与交叉行销

! 有针对性的目标市场行销

! 成本、营利额与利润的分析和管理

美洲银行就是使用Teradata建立数据仓库并获得成功应用的一个例子。该银行

在几年的时间内曾先后兼并过十几家小银行，由于系统太多而且分散，管理十分不

容易，要找到准确的业务数据也很难。举例来说，它要准确地了解各个分行的客户

. 192 .

资料就需要花很多的时间，最后的结果还不一定完全正确。为此，美洲银行投资

Teradata建立了一个中央的数据仓库，把各个分行系统中的数据都集中到中央库

来，一些以前要几个星期才能得到答案的业务问题现在只需要几分钟甚至更少，效

果非常明显。例如，业务人员可以分析在银行的客户群中，哪些类型或具有什么特

征的客户最有可能购买哪一种产品或服务。在美洲银行的数据仓库中存有280亿份

抵押贷款的资料，这套系统在1994年1月17日发生的洛杉机大地震中充分显示了其

价值。银行的住宅租赁部在几分钟内就确定了其遭受的损失。当时加洲分行的副总

裁Charles Griffin先生事后这样描述道："我们可以根据邮政编码进到每个区，看看

在遭受地震破坏的区域有多少以及有哪些类型的房产贷款"，根据这些信息，银行

可以迅速作出反应，拿出相应的对策来。

另外，在信用卡业务的拓展方面，数据仓库也起了很大的作用。一方面，通过

对数据仓库中客户信息的分析，识别出那些给银行带来更多利润并且信用好的客

户，对这些客户提供更好的服务；另一方面，对那些信用差的客户，则要想办法防

止其呆帐行为，降低风险。除此以外，还找出那些使用了银行其它服务却没有使用

信用卡服务或者使用其它银行信用卡服务的客户，并针对那些具有较好潜在利润可

供挖掘的客户群体设计促销活动，将这些客户吸引到美洲银行来。这样既拓展了信

用卡业务，又降低了促销成本。

一些大型的国际商业银行都已经使用Teradata来建立数据仓库，如Chemical

Bank、Chase Manhattan Bank、Banc One、Nationsbank、Dime Savings of New

. 193 .

York、Barclays Bank、Royal Bank of Canada、National Westminister Bank、Abbey

National Bank、Trustee Savings Bank、Credit Commercial De France、National Bank

(Australia)、Advance Bank (Australia)、Reuters News Service、Merrill Lynch、Capital

Group、台湾的中信银行等等。

9.89.89.89.8 共用事业类共用事业类共用事业类共用事业类

公用事业行业使用Teradata的也很多，比如在税务的管理与征收方面就是如

此。利用数据仓库进行管理，可以提高纳税人自觉纳税的比例，防止并识别欺诈行

为，跟踪各企业或公司的养老金支付纪录，确保按时按量的养老金缴付。

在1991年到1992年两年的时间里，澳大利亚的社会保险部给五百多万人支付了

总共超过278亿澳元的保险金。他们在1992年开始利用Teradata来建立一个全国范围

的数据仓库，到1993年，发现已经节省了超过1亿澳元的保险金，而且在可以预见

的将来，节省的资金会更多。因为利用此数据仓库，社会保险部发现并防止了许多

的欺诈行为，从而节省了保险金的支出。

意大利国家警察局利用Teradata来管理护照、车辆等其它数据。在欧洲共同

体，由于没有边检和护照的控制，对下面一些问题总是感到很棘手：

. 194 .

! 移民

! 人口失踪与罪犯通辑

! 伪造证件

! 武器偷运

! 车辆失窃与注册

例如，一个人进入法国并旅行几个星期后，进入意大利然后到其它非欧洲共同

体国家。在法国能查到某人进入的信息，在意大利则能查到某人离开的信息，但却

无法把这两个事件联系起来，换言之，不知道这两个人实际上是同一个人。在用

Teradata建立数据仓库后，实现了信息的共享，解决了诸如此类的问题。

在这一行业使用Teradata的其它用户还有：美国空军部、美国司法部、美国国

税局、中央情报局、美国国家疾病控制中心、密执安州社会保险局、德州健康保障

部等。

9.99.99.99.9 其它行业其它行业其它行业其它行业

除了上面列举的比较有代表性的几大行业外，其它行业使用Teradata的也很

多。如美国加州大学利用Teradata来进行疾病的分析等研究，他们把许多方面的信

息集中到数据仓库中，以便探索各种疾病或者人体器官等各方面的关系，如研究人

. 195 .

脑功能与其生理机制之间的复杂关系，或者研究一些特定病例的共性，找出其规律

并与医学界其它同行分享。

现已合并到波音公司的McDonnel Douglas在使用Teradata后，据称每年可节省

约2千万美元。该系统被用在以下几个方面：

! 生产制造与装配的协调以及物料的调度

! 生产计划调度

! 日常运行的管理

! 飞机的装配与质量跟踪

装配一台飞机需要成千上万的零件，因此在恰当的时间能拿到恰当的零件是非

常重要的。以前调度人员需要花好几天的时间来研究各种报表才能作出正确的计

划，而由于所花时间长往往这种计划会过时。利用Teradata来分析，现在他们只需

要几个小时就能作出正确无误的计划。

下面再列举几个其它行业使用Teradata的例子：

工具行业：法国电子设备公司

娱乐行业：Walt Disney公司

出版行业：McGraw Hill出版公司，Americtech Publishing等

. 196 .

汽车行业：福特公司，大众汽车公司

石油与天然气行业：Chevron

飞机与航天制造业：Boeing, McDonnel Douglas, Lockheed Martin

普通工业：3M，Thyssen Steel, Sumitomo Metals

根据截至到2000年9月30日的统计，目前NCR公司在全球范围已经实施并投产

的数据仓库超过1000家，其中有246家用户的数据库容量超过了1TB，这毫无疑问

地确立了NCR公司Teradata数据库在数据仓库市场的领导地位。上面所讨论的各个

行业的客户只是一些典型代表而已，我们将数据库容量在1TB以上的客户名单按照

行业总结成下面的表，供读者参考。

NCRNCRNCRNCR公司大型数据仓库客户名单公司大型数据仓库客户名单公司大型数据仓库客户名单公司大型数据仓库客户名单(Terabyte Club)(Terabyte Club)(Terabyte Club)(Terabyte Club)

(截至到2000年9月统计结果)

. 197 .

零售业总容量原始数据硬件平台 Teradata 结

点数

非 Teradata

结点数

1 Wal*Mart (1) (mkt

bskt/sales/inv, Sam's, Int'l)

74.5 TB 37 TB est 5200 128 nodes

2 Wal*Mart (2) (mkt

bskt/sales/inv, US stores)

74.5 TB 37 TB est 5200 128 nodes

3 Kmart (1) (Sales & Inv.) 60.6 TB 30 TB est 5200 88 nodes 4

4 JC Penney (1)

(Logistics/Merch)

30 TB 15 TB est. 5200 30 nodes

5 Major US Grocery Chain (1)

EDW

21 TB 10 TB est 5200 28 nodes

6 Sears (1) SPRS (Sales & Inv.) 21 TB 7.0 TB est. 5200 36 nodes 10

7 JC Penney (2) (Marketing) 15 TB 7.5 TB est 5200 12 nodes

8 Sears (2) (Leveraged Cust

Info)

14 TB 7.0 TB est. 5200 12 nodes 2

9 METRO AG (1)

Hypermarkets

13 TB 4.5 TB est 5200 20 nodes

10 Lowe's Co. (1) (Home Imp.) 8.6 TB 4.0 TB est 5200 12 nodes 2

11 Kmart (2) (Prod-Mktg) 8.1 TB 4.0 TB est 5150 48 nodes 2

12 Office Depot (1) 7.0 TB 3.5 TB est 5200 8 nodes

13 TESCO (1), UK 6.9 TB 3.4 TB est 5250 6 nodes

. 198 .

14 METRO AG (2) 6.6 TB 1.9 TB est 5200 10 nodes

15 Wal*Mart (3) (test/dev'l) 6.4 TB test/dev'l 5100 32 nodes

16 Midwest Grocer (sales & Inv.) 5.7 TB 2.8 TB est 5200 8 nodes 2 SDG

17 Casino Markets, France (coex) 5.1 TB 2.5 TB est 4800/5150 12 nodes

18 Federated (Assort) (Macy's,

Bloomies, etc.)

3.4 TB 1.7 TB est 5250 4 nodes

19 Office Depot (2) 3.4 TB 1.7 TB est 5200 6 nodes

20 Isetan, Japan (1) 3.4 TB 1.7 TB est 5200 6 nodes

21 Matsuzakaya, Japan 3.4 TB 1.7 TB est 5200 4 nodes

22 IZUMAYA, Japan 3.4 TB 1.7 TB est 5200 4 nodes

23 Ryohin Keikaku, Japan 3.0 TB 1.5 TB est 5200 6 nodes

24 Major US Grocery Chain (2)

DM

2.9 TB 1.4 TB est. 5200 4 nodes

25 Hallmark Cards (1) 2.8 TB 1.4 TB est 5250 4 nodes

26 METRO AG (3)

(Preproduction)

2.2 TB 800 gb est 5150 6 nodes

27 Limited, Lerner NY, Lane

Bryant


28 Wal*Mart (4) (Hot Spares) 2.3 TB no data 5200 6 nodes

29 Charming Shoppes 2.3 TB 1.1 TB est 5200 4 nodes

30 Kmart (3) (test/dev'l) 2.3 TB test/dev'l 5200 4 nodes

31 MYCAL, Japan 2.2 TB 1.1 TB est 4700 6 nodes

. 199 .

32 Migros, Turkey 2.0 TB 1.0 TB est 5200 2 nodes

33 Otto Versand, Germany 2.0 TB 1.0 TB est 5200 3 nodes

34 Office Depot (2) test 2.0 TB test/dev'l 4800 2 nodes

35 Dixon's, UK 1.9 TB 950 gb est. 4800/4700 6 nodes

36 Tesco (2), UK (Cust. Loyalty) 1.8 TB 900 gb est 5150 6 nodes

37 Major Italian Supermarket 1.8 TB 900 gb est 4700 4 nodes

38 Major Clothing Chain 1.7 TB 800 gb est 4800 2 nodes

39 GUS, UK (coex) 1.7 TB 859 gb est 4800/4700 8 nodes

40 JC Penney (3) (test) 1.7 TB test/dev'l 5200 2 nodes

41 FDB Danish Coop (coex) 1.7 TB 850 gb est 4800/4700 4 nodes

42 Senshukai, Japan 1.7 TB 850 gb est 4700 6 nodes

43 ASDA (Assoc Dairy), UK 1.5 TB 750 gb est 4700 4 nodes

44 La Rinascente SMA, Italy 1.4 TB 700 gb est 4800 2 nodes

45 AVA (EDEKA), Germany 1.4 TB 700 gb est 4800 2 nodes

46 JC Penney (4) HR DSS 1.4 TB 700 gb est 4800 1 node

47 Seibu Stores, Tokyo 1.4 TB 700 gb est 5200 4 nodes

48 Hallmark Cards (2) 1.4 TB 700 gb est 4800 2 nodes

49 METRO AG (4) SaturnMedia 1.4 TB 600 gb est 4700 4 nodes

50 Jyoshin Denki, Japan 1.4 TB 700 gb est 5100 5 nodes

51 Lowe's Co. (2) (Home Imp.) 1.3 TB test/dev'l 4800 2 nodes

52 Isetan, Japan (2) 1.3 TB 650 gb est 4700 6 nodes

53 Victoria's Secret Catalogue 1.2 TB 580 gb est 4700 4 nodes

. 200 .

54 Homestore.com 1.1 TB 550 gb est. 4850 1 node

55 Matsuzakaya, Japan 1.1 TB 550 gb est. 4800 2 nodes

56 Harrah's Hotels & Casinos 1.1 TB 550 gb est. 4800 2 nodes

57 NRI/Ito Yokado, 7-11, Japan 1.1 TB 550 gb est. 5200 8 nodes

58 MYCAL, Japan 1.1 TB 550 gb est. 4800 2 nodes

59 W.H. Smith Books, UK 1.1 TB 550 gb est. 4700 6 nodes

60 CWS/Coop Wholesale Soc'y,

UK

1.1 TB 550 gb est. 4700 6 nodes

61 Mitsukoshi, Japan 1.1 TB 550 gb est. 5200 4 nodes

62 The Warehouse, New Zealand 1.0 TB 500 gb est 4800 2 nodes

金融业总容量原始数据硬件平台 Teradata 结

点数

非 Teradata

结点数

63 Barclay's, UK (1) 13.8 TB 6.5 TB est 5200 24 nodes

64 Barclays, UK (2) 7.0 TB 3.5 TB est 5150 16 nodes

65 CommonWealth/EDS (1),

Australia


66 Lloyd's TSB, UK (1) 6.9 TB 3.4 TB est 5200 6 nodes

67 Bank of America (1) Nations 6.4 TB 3.2 TB est 5200 10 nodes

68 Forenings/Sverige (1), Sweden 5.1 TB 2.5 TB est 5250 6 nodes

69 National Australia Bank 3.4 TB 1.7 TB est 5250 6 nodes

. 201 .

70 Bancomer, Mexico 2.9 TB 1.4 TB est. 5150 8 nodes

71 E*Trade (Internet Stock

Trades)


72 Union Planters 2.7 TB 1.4 TB est. 4700 7 nodes

73 Tokai Bank, Japan 2.4 TB 1.2 TB est. 5100 8 nodes

74 CTIRCEAL, France 2.0 TB 1.0 TB est 5100 12 nodes 6

75 Allied Irish Bank (AIB) 1.7 TB 859 gb est 4850 2 nodes

76 ABN AMRO, Netherlands 1.7 TB 850 gb est 5150 4 nodes

77 JCB Bank, Japan 1.7 TB 850 gb est 5200 6 nodes

78 Fukuoka Bank, Japan 1.7 TB 850 gb est 5150 8 nodes

79 BNP, France- Bull Int'l (OEM) 1.7 TB 850 gb est 5150 6 nodes

80 Postbank, Germany 1.7 TB 850 gb est 5150 4 nodes

81 Toronto Dominion, Canada 1.6 TB 800 gb est 4700 6 nodes

82 CTCB, Taiwan 1.6 TB 800 gb est 4700 4 nodes

83 China Trust, Taiwan 1.5 TB 750 gb est 4700 3 nodes

84 First American (FAC) 1.4 TB 700 gb est. 5150 5 nodes

85 CELDA, France 1.4 TB 700 gb est. 4700 4 nodes

86 Commonwealth (2), Australia 1.3 TB 650 gb est. 4700 6 nodes

87 Barclays, UK (2) test 1.2 TB test/dev'l 4700 4 nodes

88 Union Bank of Norway 1.2 TB 600 gb est. 4700 4 nodes

89 St. George's, Australia 1.2 TB 600 gb est. 4700 5 nodes

90 Kyoto Chuo Shinkin, Japan 1.1 TB 550 gb est. 4850 2 nodes

. 202 .

91 Providian 1.1 TB 550 gb est. 5100 4 nodes

92 Forenings/Sverige (2), Sweden 1.1 TB 550 gb est. 5150 5100 6 nodes

93 Sumitomo, Japan 1.1 TB 550 gb est. 5150 4700 7 nodes

94 Shizuoka, Japan 1.1 TB 550 gb est. 5150 6 nodes

95 Asahi Bank, Japan (coex) 1.1 TB 550 gb est. 4700/5100 12 nodes

96 Bank of America (2) Nations 1.1 TB 550 gb est. 3600 ? Nodes

97 Shanghai Stock Exchange,

China


98 E Mart, Korea 1.0 TB 500 gb est 4850 2 nodes

99 Lloyds TSB, UK (2) 1.0 TB 340 gb est 5100 16 nodes

100 Shinhan Bank, Korea 1.0 TB 500 gb est 4800 4 nodes

101 ICICI, India 1.0 TB 500 gb est 4400 1 node

102 Royal Bank of Canada 1.0 TB 500 gb est 4700 6 nodes

103 Tokyo-Mitsubishi Bank 1.0 TB 500 gb est. 5150 6 nodes

PR

C

上海证券中央登记结算公司上海证券中央登记结算公司上海证券中央登记结算公司上海证券中央登记结算公司 1.6 TB 800 gb est. 5250 2 nodes

电信业总容量原始数据硬件平台 Teradata 结

点数

非 Teradata

结点数

104 SBC (1) (Southwestern Bell) 128 TB 64 TB est 5200 178 nodes 2

105 Mannesmann (MMO) 25 TB 12 TB est 5250/5200 26 nodes

. 203 .

106 AT&T Wireless WISDEM

Swing

10.5 TB 5.0 TB est 5250 16 nodes 2

107 AT&T CMD (1) (RAS/World

Class)

9.0 TB 4.5 TB est. 4800/5150 38 nodes

108 Telefonica Spain (1) 7.8 TB 3.9 TB est 5200 12 nodes

109 Lucent Microelectronics (1)

AR


110 Taiwan Cellular (TCC) 6.9 TB 3.5 TB est 5200 6 nodes 1

111 SBC (2) (SW Bell)

Test/DisRec

6.5 TB test/DR 5100 40 nodes 1

112 Telefonica Spain (2) 6.5 TB 3.2 TB est 5150 20 nodes

113 Vodafone, Australia 6.3 TB 3 TB est 5200 6 nodes

114 Airtouch/Verizon (Vodafone),

US

5.8 TB 2.9 TB est. 5200 11 nodes 1

115 AT&T BMD (Business) 5.8 TB 2.9 TB est. 5150 16 nodes 4

116 SBC (3) (SWB Wireless)

SBMS


117 Reuters (Financial Info), UK 5.7 TB 600 gb 5100 108 nodes

118 GTE Wireless (1) 5.0 TB 2.5 TB est 5250 5 nodes 4

119 ChungHwa, Taiwan 5.0 TB 2.5 TB est 4800/4700 12 nodes 1

120 Bell Canada (CGI - BCI) 5.0 TB 2.5 TB est 5150 9 nodes

212 Matchlogic 4.9 TB 2.4 TB est 5200 4 nodes

. 204 .

122 LG Telecom/Hyundai, Korea 4.8 TB 2.4 TB est 4800 4 nodes

123 Pannon GSM, Hungary 4.6 TB 2.3 TB est 5200 4 nodes

124 Lucent (1) CIO

WINS/ATTRA

4.5 TB 2.2 TB est. 5200 6 nodes

125 France Telecom (coex.) 4.5 TB 2.2 TB est 4800/5150 12 nodes

126 Bellsouth SIW (1) (Strategic) 4.3 TB 2.1 TB est. 5150 13 nodes

127 FarEasTone (1) (FET), Taiwan 4.2 TB 2.1 TB est. 4800/4700 8 nodes

128 Sprint PAR (1) (Res.) 4.0 TB 2.0 TB est. 5100 36 nodes 1

129 GTE Wireless (2) PIMS

Marketing


130 Telefonica Argentina YM

(coex)

3.7 TB 1.8 gb est 4800/4700 10 nodes

131 Telecom Italia/Olivetti (coex) 3.5 TB 1.7 TB est 4700/5100 15 nodes

132 Belgacom, Belgium- Mart 3.5 TB 1.7 TB est 5200 6 nodes

133 Sprint Pinnacle (2) (Bus.) 3.0 TB 1.5 TB est. 5100 27 nodes 1

134 Telekom Austria (1) 2.9 TB 1.5 TB est. 5150 15 nodes 1

135 FarEasTone (2) (FET), Taiwan 2.8 TB 1.4 TB est 4800 4 nodes

136 Belgacom, Belgium - EDW 2.8 TB 1.4 TB est. 5150 14 nodes 2

137 Lucent (2) Microelectronins

Financials

2.8 TB 1.4 TB est. 5200 2 nodes

138 BCP Telecom, Brazil (coex) 2.4 TB 1.2 TB est 4800/4700 5 nodes

139 NTT Nippon Tele, Japan 2.1 TB 1.0 TB est 5200 6 nodes

. 205 .

140 Telia CMA, Sweden (coex) 2.1 TB 1.0 TB est 4700/5100 8 nodes

141 AT&T C-ITS (IBM Global

Svcs)

2.0 TB 1.0 TB est 5150 19 nodes

142 Genuity (ex-

GTE/BellAtl/Nynex))


143 Pelephone, Israel 1.9 TB 900 gb est 4700 5 nodes

144 Albacom, Italy 1.7 TB 850 gb est 4800 4 nodes

145 AT&T CMD (2)

(PMDB/CARM Consumer)

1.7 TB 850 gb est 5150 10 nodes

146 Lucent Common NENG BC 1.5 TB 750 gb est 4850 2 nodes

147 Avaya (ex-Lucent) Avaya

ACE/ASAP/BFIPS

1.5 TB 750 gb est. 5100 16 nodes

148 Telekom Austria (2) 1.5 TB 750 gb est 5100 9 nodes 1

149 AT&T CFO FCIW 1.5 TB 750 gb est 5100 9 nodes

150 Lucent Microelectronics (3)

(test)

1.4 TB test/dev'l 4850 1 node

151 Cincinnati Bell 1.4 TB 700 gb est 4800 1 node

152 Vartec 1.4 TB 700 gb est 5150 4 nodes

153 Mobilkom, Austria (coex) 1.4 TB 700 gb est 4700/5100 7 nodes

154 Connect Austria 1.4 TB 700 gb est 4800 2 nodes

155 SBC (4) Billing 1.4 TB 700 gb est 5250 2 nodes

156 SBC (5) Ameritech AIMS 1.4 TB 700 gb est. 5100 4 nodes

. 206 .

157 AT&T Corp ITS Y2K lab 1.4 TB 700 gb est 5150 8 nodes

158 Netway, Austria 1.3 TB 650 gb est. 4800 2 nodes

159 SBC (6) SNET So. New

England (SBC)

1.2 TB 600 gb est. 5100 6 nodes

160 KT FREETEL/Samsung,

Korea


161 ETB Larga Distancia,

Colombia


162 Telenor, Norway 1.1 TB 550 gb est. 4800 2 nodes

163 Telecom Eirean (Ireland) 1.1 TB 550 gb est. 4700 4 nodes

164 Bellsouth (2) NIW (Network) 1.1 TB 550 gb est. 4700 7 nodes

165 Bellsouth (3) SIW (test) 1.1 TB 550 gb est. 4700 4 nodes

166 Bellsouth (4) BMIW 1.1 TB 550 gb est. 4700 4 nodes

167 AT&T ANS 1.1 TB 550 gb est 4800 2 nodes

168 AT&T NCS NCD 1.0 TB 500 gb est. 5100 12 nodes

169 AT&T Corp ITS COE 5150 1.0 TB 500 gb est. 5150 4 nodes

170 AT&T Corp ITS COE 4700 1.0 TB 500 gb est. 4700 4 nodes

171 AT&T Network Core 1.0 TB 500 gb est. 5100 10 nodes

172 AT&T Canada LDS 1.0 TB 500 TB est 4800 2 nodes

173 AT&T Network Systems 1.0 TB 500 gb est. 5100 6 nodes

. 207 .

交通运输业总容量原始数据硬件平台 Teradata 结

点数

非 Teradata

结点数

174 Delta Air Lines/Delta Tech. 8.6 TB 4.3 TB est 5150 20 nodes 1

175 QANTAS (1), Australia 4.6 TB 2.3 TB est 5250 6 nodes

176 Union Pacific Railroad 4.3 TB 2.1 TB est 5200 6 nodes

177 Burlington No. St. Fe RR

(coex)

3.3 TB 1.6 TB est. 4800/4700 10 nodes

178 Continental Airlines (coex) 3.2 TB 1.6 TB est. 4800/5150 12 nodes

179 British Airways 2.9 TB 1.5 TB est 5150 8 nodes

180 American Airlines/SABRE 2.8 TB 1.4 TB est 4800 4 nodes

181 QANTAS Australia (2) (coex) 2.6 TB 1.3 TB est 5150/5100 12 nodes

182 Lufthansa, Germany 2.3 TB 1.1 TB est 5200 6 nodes

183 Norfolk Southern Railroad 1.4 TB 700 gb est. 4700 8 nodes

184 SNCF French Railways 1.0 TB 500 gb est 4700+5100 7 nodes

制造业总容量原始数据硬件平台 Teradata 结

点数

非 Teradata

结点数

185 3M (Manufacturing) 10.5 TB 5.0 TB est 4800/5150 28 nodes

186 US Aerospace Co. (1) 8.4 TB 4.2 TB est 5150 46 nodes

187 NCR Corp. 6.9 TB 3.4 TB est. 5150/5100 40 nodes

188 Ford Motor (1) (Customer) 6.9 TB 3.4 TB est. 5200 8 nodes

. 208 .

189 Ford Motor (2) (Parts Inv.) 4.6 TB 2.3 TB est 5200 8 nodes

190 Ford Credit (3) Credit 4.3 TB 2.1 TB est 5200 6 nodes

191 US Aerospace Co. (2) 3.6 TB 1.8 TB est 5150 12 nodes 2

192 Global Beverage TCCC (US) 3.5 TB 1.7 TB est 5150 10 nodes

193 Global Bev. Bottler CCE (US)

(test)

2.9 TB test/devl 4800 4 nodes

194 Western Digital (Manufact)

OD

2.9 TB 1.4 TB est. 4700 8 nodes

195 US Aerospace Co (2) 1.7 TB 850 gb est 4700 8 nodes

196 Whirlpool (coex) 1.5 TB 750 gb est 4850/4800 4 nodes 1

197 US Sportswear

Maker/Lockheed


198 Intel 1.4 TB 700 gb est 5250 2 nodes

199 Standard Register 1.4 TB 750 gb est 4800 2 nodes

200 Levi Strauss 1.4 TB 750 gb est 4800 2 nodes

201 Sony, Japan 1.1 TB 550 gb est 4850 2 nodes

202 Procter & Gamble (Manufact) 1.1 TB 550 gb est 4700 6 nodes

保险业总容量原始数据硬件平台 Teradata 结

点数

非 Teradata

结点数

203 Merck Medco (1) (Drug 6.9 TB 3.5 TB est 5200 24 nodes

. 209 .

Maker)

204 Anthem Blue Cross BS (1) 4.6 TB 2.3 TB est 5250 8 nodes

205 Nationwide Mutual (1) 4.6 TB 2.3 TB est 5200 8 nodes 2

206 Columbia HCA 2.4 TB 1.2 TB est 5200 8 nodes

207 Blue Cross of IL & TX 2.2 TB 1.1 TB est 5150 10 nodes

208 Nationwide Mutual (2) 1.7 TB 860 gb est 5150 8 nodes 2

209 Hartford Insurance 1.4 TB 720 gb est 4800 4 nodes

210 RIACT Samsung Life, Korea

(1)


211 BKK Health, Germany (FSG

EMEA)

1.2 TB 400 gb est. 4700 6 nodes

212 eDirectHealth 1.1 TB 550 gb est 4850 2 nodes

213 Merck Medco (2) (test/devl) 1.1 TB Test/Devl 5200 4 nodes

214 Anthem Blue Cross BS (2) 1.1 TB 550 gb est 5150 6 nodes

215 RIACT Samsung Life, Korea

(2)


其它行业总容量原始数据硬件平台 Teradata 结

点数

非 Teradata

结点数

216 Federal Express 13.8 TB 6.7 TB est 5200 14 nodes 2

217 Equifax (Marketing DW) 11.5 TB 5.5 TB est 5200 8 nodes

. 210 .

218 Bull-Domestic (Envision) 2.9 TB 1.4 TB est 4800 2 nodes

219 Bull-Domestic (Angers) 2.9 TB 1.4 TB est 4800 2 nodes

220 Equifax (test/dev'l) 2.9 TB test/dev'l 5200 2 nodes

221 EDS (Elct. Data Sys), Texas 2.0 TB 1.0 TB est 5250 2 nodes

222 Lexis-Nexis (Finance Info

Srvc)

2.0 TB 1.0 TB est 4700 10 nodes

223 Bull Int'l (OEM) (HX7518) 1.7 TB 800 gb est 5150 6 nodes

224 Comdisco (Disaster Recovery) 1.6 TB DisRec

only

4700 6 nodes

225 Midwest Card Services (TNT

W2K)


226 Anderson Worldwide

Consulting


227 Bull Int'l (OEM) (HX7515) 1.4 TB 700 gb est 4700 4 nodes

228 SCANA - So. Carolina Energy 1.0 TB 500 gb est 4800 2 nodes

政府及公用事业总容量原始数据硬件平台 Teradata 结

点数

非 Teradata

结点数

229 Michigan Medical (Bull) 6.0 TB 3.0 TB est 5200 6 nodes

230 Illinois Medicade (Bull) 5.2 TB 2.6 TB est 5200 6 nodes

231 State of New York (Bull 4.6 TB 2.3 TB est 5200 4 nodes

. 211 .

HX0511)

232 Deutsche Post 3.4 TB 1.7 TB est 5200 4 nodes

233 US AAFES Army Air Force

Stores

3.2 TB 1.6 TB est 5150/5100 8 nodes 2

234 TRW/US DOD Diamond (1)

(coex)

2.8 TB 1.4 TB est 5250/5200 12 nodes 2

235 TRW/US DOD Diamond (2) 2.3 TB 1.1 TB est 5250 6 nodes

236 Minnesota (Bull) 2.3 TB 1.1 TB est 4800 2 nodes

237 Taiwan Bureau Nat'l Health

Ins


238 Australian Tax Office (ATO) 2.1 TB 1.0 TB est 5200 4 nodes

239 NADRA, Pakistan

Government



(coex)

1.4 TB 700 gb est 5150/5100 7 nodes


(test)

1.4 TB test/dev'l 5150 6 nodes

242 US DOJ: Dept of Justice 1.3 TB 600 gb est 5200 8 nodes

243 US IRS (tax) CRIS: Internal

Rev. Srvc

1.3 TB 650 gb est 5100 8 nodes 2

244 Australian Tax Office (ATO) 1.2 TB 600 gb est. 4700 4 nodes

245 La Poste/Chronpost, France 1.1 TB 550 gb est. 4800 2 nodes

. 212 .

246 Quebec Health Min (RAMQ) 1.0 TB 500 TB est 4800 2 nodes

. 213 .

附录一附录一附录一附录一 Client/Server结构下的结构下的结构下的结构下的Teradata数据库数据库数据库数据库

Teradata数据库完全支持Client/Server结构应用，它与Client的接口有两个：

CLI(Call Level Interface)和ODBC。CLI是Teradata的专用接口，其它工具不一定能支

持，如果自己编程或使用NCR公司发行的Teradata工具，可以利用CLI来与Teradata

进行连接。ODBC则是Microsoft开发的一种通用接口，几乎所有的前端工具都能支

持ODBC。因此，Teradata可以和任何具有ODBC接口的工具连接。

在Client/Server结构下，必须先创建一个HOSTS文件。一个典型的HOSTS文件

如下：

127.0.0.1 localhost

...

153.54.1.21 DemoCOP1

153.54.1.22 DemoCOP2

153.54.1.23 DemoCOP3

153.54.1.249 NCRcop1

153.54.1.228 LocalPC

...

. 214 .

这里需要作一个说明，在创建客户端HOSTS文件时，所有Teradata结点的别名

都由两部分组成，前一部分是Teradata系统名字，如上面的Demo和NCR，后一部分

是COP加上序列号，从1开始编号。别名不区分大小写。

这里表示客户端与两个Teradata系统相连，一个系统由三个结点组成，是一

个MPP环境，各结点的IP地址分别为153.54.1.21、153.54.1.22和

153.54.1.23，数据库系统名字为Demo。另一个系统只有一个结点，是一个SMP

环境，结点IP地址为153.54.1.249，系统名为NCR。

在MPP环境中，系统由多个单独的UNIX机器以松耦合方式组成并行处理系

统，每个结点有单独的IP地址，都连入系统网络。当客户端访问数据库时，如果指

定了IP地址，则表示是通过指定的某个结点来提交交易请求。这有两个缺点：一个

是系统不能均衡负载，如果所有的前端都通过一个结点来访问数据库，将造成此结

点负载过高，影响系统性能；另一个缺点是当此结点发生故障是，所有前端有户都

不能访问数据库。

所以在Teradata中，要求前端在访问数据库时不要指定IP地址，而是指定系统

名，如上面的Demo和NCR。这样，系统将在各结点之间自动进行负载平衡，并且

当某个结点发生故障时，同一个簇内的其它结点将自动接管其工作，保证了系统的

高可用性。当然在SMP环境中，由于只有一台机器，指定IP地址和指定系统名就没

有区别了。

. 215 .

由此可见，在MPP环境下，前端访问的不是某个具体的结点，而是整个

Teradata数据库。系统在各结点之间自动进行负载平衡并提供结点互为备份的高可

靠性，这是Teradata非常好的一个特点。

. 216 .

附录二附录二附录二附录二 Teradata ODBC驱动程序设置驱动程序设置驱动程序设置驱动程序设置

我们已经介绍过，Teradata对客户端的接口有CLI和ODBC两种。对CLI而言，

与连接有关的参数在编程序时指定。而ODBC是由Microsoft公司开发的一个开放数

据库互连标准，各数据库厂商都会开发相应的ODBC驱动程序，以动态连接库的形

式提供，而Microsoft公司则开发了一个ODBC管理员程序，通过它来调用各种数据

库的ODBC驱动程序。

NCR公司为Teradata提供了16位和32位两种ODBC驱动程序，在32位Windows

环境下，应安装32位ODBC驱动程序。安装过程很简单，执行第一张软盘上的

SETUP程序，整个过程自动进行。安装完成后，进入控制面板(Control Panel)下的

ODBC管理员程序(32-bit ODBC图标)，选择其中的" ODBC Drivers"标签，可以发现

Teradata ODBC驱动程序已经列入其中。除此以外，可能还会找到一些其它数据

库，如ACCESS、Oracle、SQL Server等的ODBC驱动程序。

为了通过ODBC与数据库进行连接，必须先定义相应的数据源(Data Source)。

不同数据库的数据源的配置不尽相同，图A2-1给出了对Teradata ODBC数据源名进

行配置的例子。对Teradata的ODBC而言，当增加或配置一个数据源时，需要定义

这样几个参数：

! 数据源名字 DSN (Data Source Name)

. 217 .

用来唯一标识一个访问Teradata数据库的数据源，该名字必须定义；

! 描述(Description)

对此数据源的简单描述，可选项；

! Teradata服务器名字或 IP地址

指定运行Teradata的数据库服务器的系统名字或相应的IP地址。对于MPP系

统，包含有多个结点，这里应该提供数据库系统名而不是某个结点的IP地址，也不

是某个结点的别名。这样，系统能在各个结点之间自动进行负载平衡。对于SMP系

统，由于只有一个结点，就没有区别了。系统名字应该在HOSTS文件中作为各结

点别名的一个公用部分。这一点在附录一中已经说明过了。

图A2-1 Teradata ODBC配置举例

. 218 .

当点击OK按钮退出Teradata ODBC设置时，将自动扫描HOSTS文件中的相应

定义，会填入某个结点的IP地址和相应的别名，不过这没关系，在真正进行数据库

连接时系统将自动选择负载最低的节点。

. 219 .

另外，在Kanji Format ( Kanji Format是用在日文系统中的)一栏中要选择Shift-

JIS (Windows, DOS or Windows-NT Compatible)

定义好数据源后，在前端工具中选择相应的数据源名DSN就可以连接到指定的

数据库中。目前绝大多数前端工具如Brio、GQL、SAS、Business Object、

Cognos、Visual Basic、Visual C++、PowerBuilder、Centura等都支持ODBC，它们

都可以和Teradata直接进行连接。

. 220 .

附录三附录三附录三附录三 QUERYMAN介绍介绍介绍介绍

QueryMan是NCR公司开发的基于Windows界面的一个前端工具，主要用来向

数据库系统提交SQL交易请求，也可用来向数据库中加载数据，或者把数据库中的

记录备份到指定格式的文本文件中。当然，这种数据的加载和备份只适用于小批量

的数据，对于较大批量的数据，采用专门的工具速度要快很多。它可以将以前的

SQL交易请求保存在一个历史(History)窗口中，通过鼠标左键可以选择以前键入的

SQL语句来执行，也可以修改后执行。QueryMan和BTEQ一样，只是一个编写和递

交SQL语句的工具，因此，在BTEQ中执行的所有SQL语句均可以在QueryMan中执

行。

QueryMan是用Visual Basic开发的一个工具软件，具有一个InstallShield，因此

安装过程非常简单。安装后在程序组中能找到QueryMan，执行时的界面如图A3-1

所示。

. 221 .

图A3-1 QueryMan界面

在最上面是菜单栏，有FILE、EDIT、VIEW、TOOLS等多个下拉式菜单，一些

常用的功能如建立与断开连接、执行查询、打印等以图标的方式显示在主菜单下的

工具栏(Toolbar)中。工具栏下面是两行信息栏(Information Bar)，表示当前的登录用

. 222 .

户、使用的数据源名DSN等。再下面是查询(Query)窗口，在这里可以键入、修改、

执行SQL交易请求。所有执行过的SQL交易都被保存在下面的历史(History)窗口

中。最下面是状态栏(Status Bar)，显示SQL交易执行的状态、时间等。这些模块除

主菜单和查询窗口外，其余均可通过VIEW来控制是否显示。

执行SQL交易前先要建立连接，点击" connect"按钮或选择TOOLS下的

CONNECT，将激活ODBC管理程序，提示选择一个数据源。如果选择了Teradata的

数据源，将弹出图A3-2所示的画面，要求输入用户名、密码、缺省数据库等信息。

输入正确后，信息栏中将显示" Connect successful, proceed with queries..."，表示

QueryMan与数据库连接成功，等待处理SQL交易。

. 223 .

图A3-2 QueryMan建立连接画面

此时可在查询窗口中输入SQL命令，然后按工具栏中的执行(Execute)按钮或主

菜单Tools下的Execute即可执行相应的SQL交易请求。执行结束后，所返回的结果

会在一个" Answer Set"窗口中显示出来，如图A3-3所示。

. 224 .

图A3-3 QueryMan执行查询后返回结果

结果窗口是以类似电子表格的方式显示，可以像操作Excel中的电子表格一

样，将整个结果集或其中一部分复制到Word、Excel等软件中进行处理。

. 225 .

利用QueryMan可以将数据库中的数据有选择地备份到文本文件中。假设要备

份表EMPLOYEE中的所有数据，在查询窗口中输入下面的SQL语句：

select * from customer_service.employee;

然后点击工具栏中的" Export Results"图标，或选择FILE菜单下的Export

Results，这时在信息栏下将出现一行提示：Results are redirected to a file or table。

执行上面的SQL语句，系统将弹出一个窗口，要求用户输入文件名，文件类型可以

是制表符分隔的文本文件(Tab Delimited)，也可以是ACCESS数据库文件，或者用

逗号分隔的电子表格文件 (Comma Seperated)。如果选择文本文件，第一行将是各

字段的名字，从第二行开始才是真正的数据记录。

利用QueryMan也可以将小批量的数据加载到数据库中。数据文件必须是以制

表符分隔的文本文件，并且从第一行开始就必须是真正的数据记录，而不是字段

名。

假设是给EMPLOYEE表中加载数据，先准备好待加载的数据文件，然后在查

询窗口输入下面的SQL语句：

. 226 .

insert into employee values (?,?,?,?,?,?,?,?,?);

在FILE菜单下选择Import Data，信息栏下将出现提示：Ready for Import

operation，表示可以加载数据。按执行按钮后，系统将提示选择数据文件。选择文

件后，系统自动开始将数据加载到指定的表中。

在上面的SQL语句中，每个问号表示一个字段。在QueryMan中用来加载数据

的SQL语句的一般格式是：

INSERT INTO tablename VALUES (?, ?, , 'Const', ?);

这表示：

! 该表必须有 5个字段；

! 数据文件中每行有三个用制表符分隔的数据，分别对应表的每一、二和第

五个字段；

! 第三个字段插入 NULL值；

! 第四个字段插入指定的常数值，这里是 Const字符串。

. 227 .

附录四附录四附录四附录四 WINDDI介绍介绍介绍介绍

WINDDI是NCR公司利用Visual Basic开发的一个基于Windows图形界面的专用

来控制和管理Teradata数据库的一个软件，是属于Teradata Manger一起发行的一个

模块，也可以单独订购。它的安装和QueryMan一样，也具有一个InstallShield，因

此安装很简单。

启动WINDDI后，先指定数据源，然后输入用户名和密码，即可建立与

Teradata的连接。初始画面如图A4-1所示。

. 228 .

图A4-1 WINDDI的初始画面

在最上面是主菜单，接下来是工具栏，包含了一些常用的功能，这些功能从主

菜单中都能找到。

. 229 .

WINDDI的左面以层次型结构的方式形象地描述了Teradata的空间结构，最上

面是DBC，接下来有一些系统用户和系统数据库，以及用户自创建的用户。系统的

数据字典在DBC下面，将光标移到DBC上面，然后点击工具栏中的ALL图标，就可

显示DBC下所有的表、视图和宏。如图A4-2所示。

图A4-2 DBC下的所有对象显示

. 230 .

WINDDI是一个非常方便实用的工具，几乎所有的Teradata管理任务都可以通

过它来完成，如创建、调整、删除、复制用户与数据库，权限的设置，数据库中具

体对象的操作等等，甚至还能通过它来递交SQL交易请求。

Teradata基础教程 - read.pudn.comread.pudn.com/downloads129/ebook/551038/Teradata_basic.pdf · 1 . 第一章 数据仓库基本概念 1.1 背景介绍...

Documents

Teradata基础教程 - read.pudn.comread.pudn.com/downloads129/ebook/551038/Teradata_basic.pdf · 1 . 第一章数据仓库基本概念 1.1 背景介绍...