用exp命令导出表结构，不导出表数据。只需在命令行里加一个参数rows=n即可。表示不导出表数据。

exp username/pwd@sid file=d:databak.dmp owner=(user)rows=n

********************************************************************************************************************

oracle exp/imp命令详解
时间：2006-06-20 14:30:55 来源：Linux联盟收集 作者：上上智
E:>exp help=y

通过输入 EXP 命令和用户名/口令，您可以
在用户 / 口令之后的命令:

实例: EXP SCOTT/TIGER

或者，您也可以通过输入跟有各种参数的 EXP 命令来控制“导出”的运行方式。
要指定参数，您可以使用关键字:

格式: EXP KEYWORD=value 或 KEYWORD=(value1,value2,...,valueN)
实例: EXP SCOTT/TIGER GRANTS=Y TABLES=(EMP,DEPT,MGR)
或 TABLES=(T1: P1,T1: P2)，如果 T1 是分区表

USERID 必须是命令行中的第一个参数。

关键字 说明（默认）
---------------------------------------------------
USERID 用户名/口令
FULL 导出整个文件 (N)
BUFFER 数据缓冲区的大小
OWNER 所有者用户名列表
FILE 输出文件 (EXPDAT.DMP)
TABLES 表名列表
COMPRESS 导入一个范围 (Y)
RECORDLENGTH IO 记录的长度
GRANTS 导出权限 (Y)
INCTYPE 增量导出类型
INDEXES 导出索引 (Y)
RECORD 跟踪增量导出 (Y)
ROWS 导出数据行 (Y)
PARFILE 参数文件名
CONSTRAINTS 导出限制 (Y)
CONSISTENT 交叉表一致性
LOG 屏幕输出的日志文件
STATISTICS 分析对象 (ESTIMATE)
DIRECT 直接路径 (N)
TRIGGERS 导出触发器 (Y)
FEEDBACK 显示每 x 行 (0) 的进度
FILESIZE 各转储文件的最大尺寸
QUERY 选定导出表子集的子句

下列关键字仅用于可传输的表空间
TRANSPORT_TABLESPACE 导出可传输的表空间元数据 (N)
TABLESPACES 将传输的表空间列表

E:>imp help=y

可以通过输入 IMP 命令和您的用户名/口令
跟有您的用户名 / 口令的命令:

实例: IMP SCOTT/TIGER

或者, 可以通过输入 IMP 命令和各种自变量来控制“导入”按照不同参数。
要指定参数，您可以使用关键字:

格式: IMP KEYWORD=value 或 KEYWORD=(value1,value2,...,vlaueN)
实例: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N
或 TABLES=(T1: P1,T1: P2)，如果 T1 是分区表

USERID 必须是命令行中的第一个参数。

关键字 说明（默认）
----------------------------------------------
USERID 用户名/口令
FULL 导入整个文件 (N)
BUFFER 数据缓冲区大小
FROMUSER 所有人用户名列表
FILE 输入文件 (EXPDAT.DMP)
TOUSER 用户名列表
SHOW 只列出文件内容 (N)
TABLES 表名列表
IGNORE 忽略创建错误 (N)
RECORDLENGTH IO 记录的长度
GRANTS 导入权限 (Y)
INCTYPE 增量导入类型
INDEXES 导入索引 (Y)
COMMIT 提交数组插入 (N)
ROWS 导入数据行 (Y)
PARFILE 参数文件名
LOG 屏幕输出的日志文件
CONSTRAINTS 导入限制 (Y)
DESTROY 覆盖表空间数据文件 (N)
INDEXFILE 将表/索引信息写入指定的文件
SKIP_UNUSABLE_INDEXES 跳过不可用索引的维护 (N)
ANALYZE 执行转储文件中的 ANALYZE 语句 (Y)
FEEDBACK 显示每 x 行 (0) 的进度
TOID_NOVALIDATE 跳过指定类型 id 的校验
FILESIZE 各转储文件的最大尺寸
RECALCULATE_STATISTICS 重新计算统计值 (N)

下列关键字仅用于可传输的表空间
TRANSPORT_TABLESPACE 导入可传输的表空间元数据 (N)
TABLESPACES 将要传输到数据库的表空间
DATAFILES 将要传输到数据库的数据文件
TTS_OWNERS 拥有可传输表空间集中数据的用户

***************************************************************
Oracle exp/imp导出导入工具的使用

一. 导出工具 exp

1. 它是操作系统下一个可执行的文件 存放目录/ORACLE_HOME/bin

exp导出工具将数据库中数据备份压缩成一个二进制系统文件.可以在不同OS间迁移

它有三种模式：
a. 用户模式： 导出用户所有对象以及对象中的数据；
b. 表模式： 导出用户所有表或者指定的表；
c. 整个数据库： 导出数据库中所有对象。

2. 导出工具exp交互式命令行方式的使用的例子
$exp oa1/123@oracle
连接到: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
输入数组提取缓冲区大小: 4096 >

导出文件: EXPDAT.DMP > D:/a.dmp

(2)U(用户), 或 (3)T(表): (2)U > 3

导出表数据 (yes/no): yes > yes

压缩区 (yes/no): yes >

已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集

即将导出指定的表通过常规路径...
要导出的表 (T) 或分区 (T: P): (按 RETURN 退出) > pfdept

. . 正在导出表 PFDEPT导出了 83 行
要导出的表 (T) 或分区 (T: P): (按 RETURN 退出) >return
导出成功终止, 但出现警告。

3. 导出工具exp非交互式命令行方式的例子
$exp oa1/123@oracle file=D:/all.dmp grants=y

说明:把oa1用户的所有表导出到文件D:/all.dmp

$exp oa1/123@oracle tables=(pfdept,pfuser) file=D:/all.dmp grants=y

说明:把oa1用户里两个表emp,dept导出到文件D:/all.dmp

$exp oa1/123@oracle tables=pfdept query="where predeptid=0745" file=D:/all.dmp

说明:在exp里面加上导出pfdept 的查询条件predeptid=0745

$exp parfile=username.par file=/directory1/username_1.dmp,/directory1/username_2.dmp filesize=2000M log=/directory2/username_exp.log

参数文件username.par内容
userid=username/userpassword
buffer=8192000
compress=n
grants=y

说明:username.par为导出工具exp用的参数文件,里面具体参数可以根据需要去修改

filesize指定生成的二进制备份文件的最大字节数
二.导入工具 imp

1. 它是操作系统下一个可执行的文件 存放目录/ORACLE_HOME/bin

imp导入工具将EXP形成的二进制系统文件导入到数据库中.

它有三种模式：
a. 用户模式： 导出用户所有对象以及对象中的数据；
b. 表模式： 导出用户所有表或者指定的表；
c. 整个数据库： 导出数据库中所有对象。

只有拥有IMP_FULL_DATABASE和DBA权限的用户才能做整个数据库导入

imp步骤：
(1) create table (2) insert data (3) create index (4) create triggers,constraints

2.导入工具imp交互式命令行方式的例子
$ imp
Import: Release 10.1.0.2.0 - Production on 星期一 9月 3 08:21:32 2007
Copyright (c) 1982, 2004, Oracle. All rights reserved.
用户名: system
口令:****
连接到: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
导入文件: expdat.dmp> D:/all.dmp
输入插入缓冲区大小（最小为 8192 ) 30720>
经由常规路径导出由EXPORT:V08.01.06创建的文件
警告: 此对象由 TEST 导出, 而不是当前用户
已经完成ZHS16GBK字符集和ZHS16GBK NCHAR 字符集中的导入
只列出导入文件的内容(yes/no)：no>
由于对象已存在, 忽略创建错误(yes/no)：no> yes
导入权限(yes/no)：yes>
导入表数据(yes/no)：yes>
导入整个导出文件(yes/no)：no> yes
. 正在将TEST的对象导入到 SCOTT
. . 正在导入表 "CMAMENU" 4336行被导入
成功终止导入，但出现警告。
3.导入工具imp非交互式命令行方式的例子

$ imp system/oracle fromuser=oa1 tables=(pfdept)
$ imp system/oracle fromuser=oa1 tables=(pfdept,pfuser)
$ imp system/oracle fromuser=oa1 touser=system
$ imp oa1/123 file = all.dmp full=y
$ imp oa1/123 file = all.dmp show=n buffer=2048000 ignore=n commit=y grants=y full=y log=D:/.log
$ imp oa1/123 parfile=params.dat
params.dat 内容
file=dba.dmp show=n ignore=n grants=y fromuser=oa1 tables=(pfdept,pfuser)

4.导入工具imp可能出现的问题

(1) 数据库对象已经存在
一般情况, 导入数据前应该彻底删除目标数据下的表, 序列, 函数/过程,触发器等;
数据库对象已经存在, 按缺省的imp参数, 则会导入失败
如果用了参数ignore=y, 会把exp文件内的数据内容导入
如果表有唯一关键字的约束条件, 不合条件将不被导入
如果表没有唯一关键字的约束条件, 将引起记录重复

(2) 数据库对象有主外键约束
不符合主外键约束时, 数据会导入失败
解决办法: 先导入主表, 再导入依存表
disable目标导入对象的主外键约束, 导入数据后, 再enable它们
(3) 权限不够
如果要把A用户的数据导入B用户下, A用户需要有imp_full_database权限

(4) 导入大表( 大于80M ) 时, 存储分配失败
默认的EXP时, compress = Y, 也就是把所有的数据压缩在一个数据块上.
导入时, 如果不存在连续一个大数据块, 则会导入失败.
导出80M以上的大表时, 记得compress= N, 则不会引起这种错误.

(5) imp和exp使用的字符集不同
如果字符集不同, 导入会失败, 可以改变unix环境变量或者NT注册表里NLS_LANG相关信息.
导入完成后再改回来.

(6) imp和exp版本不能往上兼容
imp可以成功导入低版本exp生成的文件, 不能导入高版本exp生成的文件
根据情况我们可以用

导入的时候总是出现警告

C:Documents and SettingsAaron>exp system/manager@prod tables=GL.GL_balanceS
query=" where period_name='2009-07'" file=D:/EXP/GL_balanceS.dmp grants=y

Export: Release 10.2.0.1.0 - Production on Mon Aug 10 17:12:16 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit
Production
With the Partitioning, OLAP and Data Mining options
Export done in ZHS16GBK character set and AL16UTF16 NCHAR character set

About to export specified tables via Conventional Path ...
Current user changed to GL
. . exporting table GL_BALANCES 3710 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Export terminated successfully with warnings.

exp apps/apps@prod tables=GL.GL_JE_BATCHES query="where actual_flag='A' and creation_date>=sysdate-5" file=D:/EXP/GL_JE_BATCHES.dmp grants=y

exp system/manager@prod tables=GL.GL_JE_BATCHES query="where actual_flag='A' and creation_date>=sysdate-5" file=D:/EXP/GL_JE_BATCHES.dmp grants=y

exp system/manager@prod tables=GL.GL_JE_headerS query="where actual_flag='A' and creation_date>=sysdate-5" file=D:/EXP/GL_JE_headerS.dmp grants=y

exp system/manager@prod tables=GL.GL_JE_LINES query=" where creation_date>=sysdate-5" file=D:/EXP/GL_JE_LINES.dmp grants=y
exp system/manager@prod tables=GL.GL_SETS_OF_BOOKS file=D:/EXP/GL_SETS_OF_BOOKS.dmp grants=y

exp system/manager@prod tables=GL.GL_PERIODS query="where period_name = '2009-07'" file=D:/EXP/GL_PERIODS.dmp grants=y

exp system/manager@prod tables=GL.GL_CODE_COMBINATIONS query=" where summary_flag='N'" file=D:/EXP/GL_CODE_COMBINATIONS.dmp grants=y

exp system/manager@prod tables=GL.GL_balanceS query=" where period_name='2009-07'" file=D:/EXP/GL_balanceS.dmp grants=y

发展史：吃水不忘挖井人，先记记创立者吧。

    统一建模语言UML（Unified Modeling Language）是由Grady Booch、Jim Rumbaugh和Ivar Jacobson三人共同努力，于1996年6月和10月发布。1997年11月17日，OMG采纳UML 1.1作为基于面向对象技术的标准建模语言，成为可视化建模语言事实上的工业标准。　　

    1、James Rumbaugh
    参与创立了称为对象建模技术（Object Modeling Technique，简写OMT）的早期建模语言。
    OMT包括对象模型、动态模型、功能模型用于分析、系统设计、对象设计和实现等步骤。
    2、Grady Booch
    开发了Booch方法，是一个面向对象的软件解决方案开发方法，用来分析、模型化和记录系统要求。
    使用对象图、状态转换图、交互图来进行逻辑建模和物理建模。
    3、Ivar Jacobson
    创立了面向对象的软件工程（Object-Oriented Software Engineering，简称OOSE）方法。OOSE是一种真正的面向对象的软件方法，突出的特点是Ivar Jacobson加入的用例驱动和方法。

（可惜，这三个人的名字不会读，有人标出音标来吗？英语水平太差。）

　　UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。

    UML可用于下列领域：
    1、机构的工作流程
    2、业务分析
    3、用户描述
    4、数据库设计
    5、对象设计
    6、组件
    7、部署（域和服务器）
    8、GUI设计

    UML是模型，不是实现，所以可用于任何类型的环境。在设计的方法，UML都独立于编程语言。当然，在某些位置，需要在UML模型做出一些决策，来反映物理和技术选择，这是UML的另一个强大特性。也就是说，不仅所有开发人员可使用UML，而且业务分析师和技术架构师能在了解所有要求、当前状态、未来状态、交互和约束前，不需要选择技术平台，即开始分析和设计解决方案。

    UML由图形符号组成，开发人员、分析师、客户、用户和其他股东都能理解。

    UML模型分为三类：功能、行为和实现。功能类别模型用来收集要求和描述功能。行为类别模型用于描述解决方案的对象和用户的行为。实现类别模型用于解决方案功能和行为的物理实现。
    1、功能模型：用例图、类图
    2、行为模型：交互图（顺序图和协作图）、状态图、活动图
    3、实现模型：组年图、部署图

功能类模型：包括用例图和类图，它们将准确了解解决方案的作用及开发方式。
用例图：用来收集用户要求。由行动者（actor）、用例（use case）及它们之间的关系组成。
1、行动者（actor）指与系统交互的某人或某事。行动者要么从解决方案接收信息，要么将信息传给系统。通常包括人（如用户）或另一个系统。行动者一般指一个角色，而非操作者。例如：如果两个操作者以完全相同的方式使用解决方案，则行动者是一个，而不是两个。
2、用例（Use Case）指一个过程。
类图：用于收集要求阶段。它提出总是，并验证系统确能完成要求。

行为类模型：描述解决方案的行为或交互。
1、交互图：包括顺序图和协作图。这两种图之间的区别在于：顺序图基于时间，按时间顺序显示出现的任务；而协作图显示任务和信息（对象）的交互方式。
2、状态图：显示对象的生命期。
3、活动图：描述工作流以及谁完成工作。

实现类模型：描述如何打包和实现解决方案。
1、组件图：指在解决方案中构建实际物理组件模型的方式。组件图可显示源代码组件、COM+组件及其它二进制和可执行文件。组件图还显示组件接口。
2、部署图：显示解决方案的部署方式，由处理器、设备和连接器构成。用来描述组件运行在哪些物理计算机上，以及解决方案如何与硬件交互。







用例图（use case diagram）

基本元素：
行动者（Actor）：有翻译为参与者、角色，感觉“角色”似乎更适合，更易于理解。微软中文VISIO中使用参与者。
关系（Relationship）
过程（Process）
包（Package)
系统边界（System Boundary）

关系用来指示行动者与哪些元素有关。行动者可能与其他行动者相关，也可与用例相关。行动者与用例相关，以表明它们从用例接收信息，或将输入或信息输给用例。
用例图包括三类关系：
communicates（通信关系）
uses（使用关系）
extends（扩展关系）

communicates关系表明行动者从用例接收信息，或向用例提供输入或信息。更可能的情况是，它表明行动者与用例交互，即行动者执行用例中包含的任务。communicates关系常被称为associations（关联关系）。

uses关系表示用例使用另一个用例提供的功能。

extends关系表明一个用例可使用另一个用例的功能。

uses和extends的区别：
extends表明的是一种可选决策
uses表明的是一种必选决策

顺序图（sequence diagram）
顺序图是以图形方式记录情景（scenarios）的方式。每当要记录一系列动作时，就可以构建顺序图。
顺序图包含元素：
对象（Objects）
激活（Activations）
消息（Messages）
注解（Notes）

对象是解决方案中的持久元素。它们可能是表、物理窗体或类。
激活是过程的执行，包括它等待嵌套过程执行的时间。
消息是对象之间执行的动作，消息标志着两个对象之间的通信，从而表示一个动作。
    消息：连接到两个不同对象生命线的连接点。此类消息表示一个动作，与接收对象的方法或操作相关，接收消息的对象执行这个请求上的动作。消息可含传给要执行方法的参数。
    消息（调用）：似乎与消息是一样的。
    消息（返回）：将信息返给对象的消息。
    消息（异步）：发送对象将消息发送给接收对象，并不等待接收对象的响应。
（这一段好难理解，还不如这一段：
简单消息(Simple Message) 表示简单的控制流。用于描述控制如何在对象间进行传 递,而不考虑通信的细节。
同步消息(Synchronous Message) 表示嵌套的控制流。
操作的调用是一种典型的同 步消息。
调用者发出消息后必须等待消息返回,只有当处理消息的操作执行完毕后,调用 者才可继续执行自己的操作。
异步消息(Asynchronous Message) 表示异步控制流。
当调用者发出消息后不用等待 消息的返回即可继续执行自己的操作。
异步消息主要用于描述实时系统中的并发行为。
简单消息和同步消息感觉总是理解不清楚。
）

协作图：显示对象及相应关联
协作图包含三个基本元素：对象、链接（对象之间）、消息

对象包含名称、状态和行为。

协作图与顺序图的区别是：顺序图基于时间，但协作图不强调时间。在记录过程涉及的任务时，将构建协作图。与顺序图相比，协作图更面向对象，因为它强调的是消息和对象，而在顺序图，因为按基于时间的方式记录过程，所以强调的是过程路径。

活动图：用来构建业务过程工作流的模型。业务过程是一个过程，描述业务如何执行特定任务。业务过程涉及到所有行动者和过程。
活动图由以下元素构成：
1、泳道（Swimlanes）
2、活动（Activities）
3、转换（Transitions）
4、状态（States）
5、决策（Decisions）

每个泳道表示一个对象，对象负责泳道中发生的一切。
泳道中包含活动。活动表示对象所实现的功能。
每个活动必须正好有一个传出转换。转换有两种类型：对象流（指示活动与该活动相关的对象之间的关系），控制流（显示一个活动触发另一个活动或转换到一个新对象状态）
对象可能处于多种不同状态。对象可能有状态，也可能无状态。当对象有状态时，若执行一个或多个操作 ，或设置一个或多个属性时，则对象从一种状态转换成另一种状态。
决策基于不同条件向不同方向发展。

行为类型UML模型中的部分元素与.net语言有映射关系，具体包括：
包——命名空间（或系统）
顺序图：对象——通常是.net类的一个实例
顺序图：消息——通常是.net类的一个方法（或事件、属性）

类图（Class diagram）：用来确定解决方案的（静态）结构。通过类图，可看到将实现哪些类、COM+组年和ASP页面等。也可看到这些元素的交互方式。
当开发人员开发解决方案时，类图将是主要的信息来源，从中可详细了解要开发的操作代码，以及数据类型、参数和命名空间等信息。如果开发人员需要一些有关解决方案行为的支持信息，则可查看行为图，如顺序图和活动图等。

类图的主要元素包括：包、类、关系。

对类图而言，包有两个功能：
1、可构建组合相关元素的包，以构建模型的普通视图。
2、可表示命名空间。

类包含名称（Name）、特性（Attributes）、操作（Operations）

关系包含三种基本关系：Binary association（二元关联）、Dependency（依赖）、Generalization（泛化）。
二元关联：指定两个类是相关的，即它们以某些方式交互。
依赖关系：指一个类对另一个类的构建依赖，但不维护到该类对象的永久链接。如果更改一个类，则将影响所有依赖于这个特定类的所有类。一般地，依赖关系表明：依赖类至少调用其所依赖类的一个操作。依赖关系对代码生成没有任何影响，但在项目引用中有所表现。
泛化关系：指示一个类是另一个类的子类，并继承基类的公共操作和特性。

linux下的很软件都是 tar.gz后缀的，解压久了不用就忘了，写备忘。现我知的直接解压方法有两种

1.gunzip与tar

    在实例文档中复合类型和一些简单类型是在购买定单的模式文档中定义。而其他一些标准的简单类型则是作为XML Schema内置的简单类型的指令表的一部分定义的。

    在继续查阅购买订单模式文档之前，我们暂时离题来提一下实例文档和购买订单模式文档之间的联系。观察实例文档你可以看到购买订单模式文档并没有被提及。一个实例文档实际上不需要引用模式文档，当然尽管很多实例文档确实引用了，为了使这第一节简单化，我们一开始选择不引用。并且假设任何实例文档的处理器即使从实例文档中得不到任何信息，也能够包含购买订单模式文档的处理。在后面的章节，我们将介绍联系实例文档和模式文档的外部机制。

购买订单模式文档

购买订单模式文档包含在文件po.xsd中：


po.xsd，购买订单的Schema文档

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 <xsd:annotation>
  <xsd:documentation xml:lang="en">
   Purchase order schema for Example.com.
   Copyright 2000 Example.com. All rights reserved.
  </xsd:documentation>
 </xsd:annotation>

 <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

 <xsd:element name="comment" type="xsd:string"/>

 <xsd:complexType name="PurchaseOrderType">
  <xsd:sequence>
   <xsd:element name="shipTo" type="USAddress"/>
   <xsd:element name="billTo" type="USAddress"/>
   <xsd:element ref="comment" minOccurs="0"/>
   <xsd:element name="items"  type="Items"/>
  </xsd:sequence>
  <xsd:attribute name="orderDate" type="xsd:date"/>
 </xsd:complexType>

 <xsd:complexType name="USAddress">
  <xsd:sequence>
   <xsd:element name="name"   type="xsd:string"/>
   <xsd:element name="street" type="xsd:string"/>
   <xsd:element name="city"   type="xsd:string"/>
   <xsd:element name="state"  type="xsd:string"/>
   <xsd:element name="zip"    type="xsd:decimal"/>
  </xsd:sequence>
  <xsd:attribute name="country" type="xsd:NMTOKEN"
     fixed="US"/>
 </xsd:complexType>

 <xsd:complexType name="Items">
  <xsd:sequence>
   <xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
    <xsd:complexType>
     <xsd:sequence>
      <xsd:element name="productName" type="xsd:string"/>
      <xsd:element name="quantity">
       <xsd:simpleType>
        <xsd:restriction base="xsd:positiveInteger">
         <xsd:maxExclusive value="100"/>
        </xsd:restriction>
       </xsd:simpleType>
      </xsd:element>
      <xsd:element name="USPrice"  type="xsd:decimal"/>
      <xsd:element ref="comment"   minOccurs="0"/>
      <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
     </xsd:sequence>
     <xsd:attribute name="partNum" type="SKU" use="required"/>
    </xsd:complexType>
   </xsd:element>
  </xsd:sequence>
 </xsd:complexType>

 <!-- Stock Keeping Unit, a code for identifying products -->
 <xsd:simpleType name="SKU">
  <xsd:restriction base="xsd:string">
   <xsd:pattern value="\d{3}-[A-Z]{2}"/>
  </xsd:restriction>
 </xsd:simpleType>

</xsd:schema>
 
    购买订单模式文档由一个schema元素和一系列子元素组成，大多数子元素为element， complexType， 和simpleType，这些决定了在实例文档中的元素的表现方式和内容。

    通过出现在schema元素中的命名空间声明xmlns：xsd="http://www.w3.org/2001/XMLSchema"，在模式文档中的每一个元素都有一个与XML Schema命名空间相联系的命名空间前缀"xsd：".尽管任何前缀都能够被使用，但是，前缀"xsd："被约定用于表示XML Schema命名空间。通过使用同样的前缀，这样同样的关联也出现在内置的简单类型的名字中。例如，xsd：string.这种形式的关联的目的是用来标识元素和简单类型是属于XML Schema语言的词汇表而不是模式文档作者自己的词汇表。为了在这里清楚表示，我们仅提及元素的名字和简单类型（如simpleType）而忽略了它们的前缀"xsd：".

    让我们解释的更加通俗易懂一些吧，在javaSE中也有metadata的概念，最早的就算是JavaDoc了，在5.0之后，Annotation就是大量的使用metadata了，这是关于源代码的数据，具体来说就是关于Java的类、方法、字段等关联的附加数据。这些数据可以被Java的编译器或者其它工具（比如Java IDE 象eclipse+junit一样）来发现和使用。junit在4.0后也使用了Annotation也算是metadata的一种应用。可见metadata并不是什么高不可攀的技术，我们时刻都在使用。

    再来看看metadata在BI系统上的定义吧，元数据（Metadata）是关于数据、操纵数据的进程，以及应用程序的结构、意义的描述信息，其主要目标是提供数据资源的全面指南。元数据是描述数据仓库内数据结构和建立方法的数据，可将其按用途分为两类：技术元数据（Technical Metadata）、业务元数据（Business Metadata）和内联映射元数据（Inter-Mapping Metadata）。

    技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库的数据，主要包括数据仓库结构的描述（各个主题的定义，星型模式或雪花型模式的描述定义等）、ODS层（操作数据存储ODS .Operation Data Storage)的企业数据模型描述（以描述关系表及其关联关系为形式）、对数据稽核规则的定义、数据集市定义描述与装载描述（包括Cube的维度、层次、度量以及相应事实表、概要表的抽取规则）。另外，安全认证数据也作为元数据的一个重要部分进行管理。

业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够理解数据仓库中的数据。业务元数据包括以下信息:使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据来源;系统所提供的分析方法及公式、报表信息。

    内联映射元数据（Inter-Mapping Metadata）实现技术元数据与业务元数据的层间映射，使得信息系统的概念模型与物理模型相互独立，使企业的概念、业务模型重组，以及物理模型的变化相互透明。

    内联映射元数据从技术上为业务需求驱动、企业数据驱动的双驱动建设模型提供了重要保证,使信息系统的建设具有更高的灵活性与适应性。

    元数据是跟特定的数据对象有关的，换句话说，talend和kettle的元数据就是不一样的。ETL的元数据就和pentaho report 的元数据不一样，因为他们要描述的东西不一样。这些元数据的存储格式可以有多种，可以储存成XML格式的也可以是放在数据库里面的。事实上这两种最通用的，也是可以互补的两种，没有谁比谁重要之说。

    metadata储存在repository的地方,我不知道是不是所有的ETL工具都喜欢这么叫.每个repository都会选用数据库来储存,他们都是按照一定的格式,这些格式最后也是可以变成XML形式的.这是看每个工具的支持程度,kettle 就支持导出到XML格式,其他的工具我就不知道了.

    具体解释到kettle来说，metadata就是你定义的每一个动作.kettle的repository里面有如下一些表,我没有列出全部,从表的结构看一下kettle的metadata有哪些

1. R_DATABASE R_DATABASE_ATIRIBUTE R_DATABASE_CONTYPE R_DATABASE_TYPE

2. R_JOB R_JOB_HOP R_JOBENTRY R_JOBENTRY_ATIRIBUTE R_JOBENTRY_TYPE

3. R_LOG R_LOGLEVEL

4. R_STEP R_STEP_DATABASE

5. R_TRANS_ATIRIBUTE R_TRANS_HOP R_TRANS_CONDITION

6. R_USER R_VALUE R_PERMISSION

7. R_CLUSTER R_CLUSTER_SLAVE R_SLAVE

8. R_PARTITION R_PARTITION_SCHEMA

1 . database的链接信息.在R_DATABASE_TYPE 表里面包含了所有支持的数据库链接信息,一共是25种,算是支持非常的多了.

2. 任务设计部分的表,R_JOB_HOP 是指两个数据之间的链接部分, R_JOBENTRY_TYPE 是目前支持的操作种类,一共有27种,包括Transformation , Job , Shell , Mail , SQL ,FTP ,Table exists ,File Exists , JavaScript , Secure FTP , HTTP , Create File , Delete File , Wait for File , Put a file with SFTP , File Compare , BulkLoad into Mysql , Display Msgbox Info , Wait for , Zip file , XSL Transformatio, BulkLoad from Mysql into File , Abort Job , Get mails from POP , Ping a host , Dummy Job Entry .

其中BulkLoad 只跟Mysql有关,我感觉很奇怪,BulkLoad 是数据库批量处理的方式,大型数据库都是支持的,比如oracle就有sqlloader来支持批量处理,其他的大型数据库应该也有吧,而且在transform里面kettle也有oracle的支持，在任务设计的时候就只有mysql的支持，不知道什么原因.

最后一个Dummy Job Entry 就是什么都不做.

3. Log记录,loglevel 一共有6种,Nothing at all , Minimal loggin , Basic loggin , Detailed loggin , Debugging , RowLevel(very detailed).根据你自己的需要来选择log的级别.

4. 每一步操作的表格与你使用的数据库

5. 转换的定义.一共有70种不同的转化,你不会想看到全部列出来的,其中有几种很有用的,比如DimensionLookup , 它的解释就是"在一个数据仓库里更新一个渐变维,或者在这个维里查询信息.

还有基于关键字删除记录,

cuebOutput, 把数据写入一个cube,

从一个excel文件读数据,执行一个sql脚本,调用数据库的储存过程,

OraBulkLoader ,调用oracle 的bulk loader to load data ,(应该是指Oracle的SQLLOADER吧).

ProSAPCONN, 从一个SAP系统取数据.

MergeRows,合并两个数据流, 并根据某个关键字排序. 这两个数据流被比较，以标识相等的、变更的、删除的和新建的记录.

    插一句关于merge的概念，从网上copy下来的：

MERGE语句是Oracle9i新增的语法，用来合并UPDATE和INSERT语句。通过MERGE语句，根据一张表或子查询的连接条件对另外一张表进行查询，连接条件匹配上的进行UPDATE，无法匹配的执行INSERT。这个语法仅需要一次全表扫描就完成了全部工作，执行效率要高于INSERT＋UPDATE。

6. 用户与权限.一开始建立的用户有两种,admin和guest ,权限有5种,Read only access , Administrator , Use transformations , Use Jobs , Use schemas .

7. pentaho官方网站上面有一个新闻是关于在mysql的Kettle集群新记录：

    最近Kettle集群基于 Amazon Elastic Computing Cloud做了一次测试，单台服务器输出4000 rows/sec ，数据库为MySQL. 如果你发送数据通过sockets从一个master到5个slave servers, 你将获得 5x4000 row inserts/sec。集群的效果非常好.

    我个人也做过测试。数据库是oracle 10.2.0.1,内网连接，从一台机器的oracle到本地机器，没有集群，速度也大概是4000 多一点 ，数据量大概是16万。

8 . 数据库分区是数据库的高级特性之一，oracle的XE版和Enterprise版本的有一个差别就是XE版不支持分区。

    kettle还支持metadata搜索，可搜索的选项包括步骤，数据库连接和注释 ，可见metadata对于ETL的重要性就是它能够更好的管理你的数据，而不只是让你的数据呆在数据库里面。kettle对与数据库的元数据管理并不是很好，所谓数据库的元数据就比如数据库中表的名字，每一个column的信息，column的长度，每一个表的constrain，index等，而只有提供这些信息的管理才能够将ETL过程做的更好。下一篇介绍ETL质量控制的时候会看到oracle warehouse builder 对于这些数据管理是多么的强大，目前kettle的能力还不能算是非常的强大的。

    pentaho平台本身还有一种metadata , 在官方主页上是这么写的：

    pentaho metadata的能力是让管理员定义一个抽象层来显示数据库信息和商业流程，管理员用关系型数据库的表来表现相互之间的关系，为了复杂和含义模糊的数据库表和列而创建商用术语，为特性用户而设定权限参数，指定默认的数据格式，为多种语言部署提供翻译，商业用户可以使用pentaho新的ad hoc query能力查询他们想要的报表，比如订单的数量和按地区排序的客户开销，SQL可以自动取得这些信息。

    数据仓库的建模也需要用到metadata, oracle的数据仓库建模就是用的一种叫 Common Warehouse Metamodel 的metadata , CWM提供一个数据仓库的标准让不同的厂商集成和管理他们的数据，CWM建立在开发的标准XMI(XML for Metadata interchange) XML 和 UML2 作为建模语言。CWM 用UML2 定义一组核心类，这些类分作package（或者叫做子模型submodels)，每一个提供一个特定的数据仓库的domain , 比如 Relational , OLAP ,Transformation , CWM 提供一个强大的数据模型来实现数据仓库的Extraction , transformation , loading , integration and analysis ，没有一个单独的模型能够满足各种应用程序和开发工具的需求，但是CWM 为这些工具提供特定的扩展，它被设计用来支持关于metadata的快速开发，使用户能够通过扩展来满足他们的需求。

　　SQL主要包括数据定义、数据操纵（包括查询）和数据控制等三方面功能。SQL是一种非过程化程度很高的语言，用户只需说明"干什么"而无需具体说明"怎么干"语言简洁、使用方便功能强大，集联机交互与嵌入于一体，能适应广泛的使用环境。ORACLE数据库由三种类型的文件组成：数据库文件、日志文件和控制文件。

　　数据字典是由ORACLE自动建立并更新的一组表，这些表中记录用户的姓名、描述表和视图以及有关用户权限等的信息。数据字典是只读的，只允许查询。也就是说数据字典是一种数据库资源，每个用户都可以访问数据字典，DBA可通过数据字典来监视ORACLE RDBMS的使用，并帮助用户完成其应用。ORACLE RDBMS本身也要利用数据库字典来管理和控制整个数据库。

　　提起数据库，第一个想到的公司，一般都会是Oracle。该公司成立于1977年，最初是一家专门开发数据库的公司。

      Oracle在数据库领域一直处于领先地位。1984年，首先将关系数据库转到了桌面计算机上。然后，Oracle的下一个版本，版本5，率先推出了分布式数据库、客户/服务器结构等崭新的概念。Oracle的版本6首创行锁定模式以及对称多处理计算机的支持……最新的Oracle8主要增加了对象技术，成为关系-对象数据库系统。目前，ORACLE产品覆盖了大、中、小型机等几十种机型，Oracle数据库成为世界上使用最广泛的关系数据系统之一。

Oracl入门基本知识

      1.一个表空间只能属于一个数据库。

　　2.每个数据库最少有一个控制文件（建议3个，分别放在不同的磁盘上）。

　　3.每个数据库最少有一个表空间（SYSTEM表空间）。

　　4.建立SYSTEM表空间的目的是尽量将目的相同的表存放在一起，以提高使用效率，只应存放数据字典。

　　5.每个数据库最少有两个联机日志组，每组最少一个联机日志文件。

　　6.一个数据文件只能属于一个表空间。

　　7.一个数据文件一旦被加入到一个表空间中，就不能再从这个表空间中移走，也不能再加入到其他表空间中。

　　8.建立新的表空间需要建立新的数据文件。

　　9.数据文件被ORACLE格式化为ORACLE块，Oracle9i以前版本中，ORACLE块的大小是在第一次创建数据库时设定的。

　　10.并且以后不能改变，要想改变，只能重建数据库。

　　11.一个段segment只能属于一个表空间，但可以属于多个数据文件。

12.一个区extent只能属于一个数据文件，即区间（extent）不能跨越数据文件。

　　13.PCTFREE和PCTUSED总和不能大于等于100。

　　14.单独一个事务不能跨越多个回滚段。

　　15.索引表不含ROWID值。

　　16.拥有不同大小的回滚段没有任何益处。

　　17.COMMIT后，数据不一定立即写盘（数据文件）。

　　18.一个事务即使不被提交，也会被写入到重做日志中。

　　19.Oracle 8.0.4中，在初始安装时建立的缺省数据库，实例名为ORCL 。

　　20.一个块的最大长度为16KB(有2K、4K、8K、16K)。
　　 每个数据库最大文件数（按块大小）
　　 2K块　　　　　　　　20000个文件
　　 4K块　　　　　　　　40000个文件
　　 8K块或以上　　　　　65536个文件

　　21.oracle server可以同时启动多个数据库 。

　　22.一套操作系统上可以安装多个版本的ORACLE数据库系统（UNIX可以，NT不可以）。

　　23.一套ORACLE数据库系统中可以有多个ORACLE数据库及其相对应的实例 。

　　24.每个ORACLE数据库拥有一个数据库实例（INSTANCE）（OPS除外）。

　　25.所以，一套操作系统上同时可以有多个oracle数据库实例启动。

Oracle数据库产品具有的优良特性

（1） 兼容性

　　Oracle产品采用标准SQL，并经过美国国家标准技术所（NIST）测试。与IBM SQL/DS，DB2，INGRES，IDMS/R等兼容。

（2） 可移植性

　　Oracle的产品可运行于很宽范围的硬件与操作系统平台上。可以安装在70种以上不同的大、中、小型机上；可在VMS、
DOS、UNIX、WINDOWS等多种操作系统下工作。

（3） 可联结性

　　能与多种通讯网络相连，支持各种协议（TCP/IP、DECnet、LU6.2等）。

（4） 高生产率

　　提供了多种开发工具，能极大的方便用户进行进一步的开发。

（5） 开放性

　　Oracle良好的兼容性、可移植性、可连接性和高生产率是Oracle RDBMS具有良好的开放性。

　　ORACLE产品主要包括数据库服务器、开发工具和连接产品三类。

数据库服务器

　　最新版本是8，但广泛应用的是7。版本7具有以下特色：

（1）多进程、多线索的体系结构

　　多进程、多线索的体系结构。Oracle7包括一个到多个线索进程、多个服务器进程和多个后台进程。线索进程负责监听用户请求，将用户请求链入内存的请求队列中，并将应答队列中的执行结果返给相应用户。服务器进程负责处理请求队列中的用户请求，并把结果链入应答队列。线程和线索的数目都可以根据当前工作负荷动态调整。Oracle7的进程结构能充分利用并行机上多处理机的能力，但由于其线索是用进程模拟的，由操作系统调度，这在一定程度上消弱了线索开销低的优越性。

（2）为提高性能改进核心技术

　　Oracle7改进了其核心技术。其并发控制机制更加精致，包括了无限制行级封锁、无竞争查询、线索的顺序号产生机制。在共享内存缓冲区中增加了共享的SQL Cache，提高了运行效率。

（3）高可用性

　　Oracle7提供了联机备份、联机恢复、镜像等多种机制保障系统具有高可用性和容错功能。

（4）SQL实现

　　Oracle7的SQL符合ANSI/ISO SQL 89标准。完整性约束符合ANSI/ISO标准的实体完整性和参照完整性约束。提供基于角色的安全性。

　　角色是一组权限的集合。有了角色的概念，安全管理机制可翼把表或其他数据库对象上的一些权限进行组合，将它们赋予一个角色。需要时只需将该角色授予一个用户或一组用户，这样可以降低安全机制的负担和成本。

　　针对集群和MPP并行计算机平台，Oracle7提供了并行服务器选件实现存盘共享。同时，Oracle7还为SMP、集群和MPP平台提供了并行查询选件，以实现并行查询、并行数据装载等操作。

　　Oracle7通过分布式选件提供分布式数据库功能。其分布式选件提供了多场地的分布式查询和多场地更新功能，具有位置透明性和场地自治性，提供全局数据库名，支持远程过程调用。

开发工具

　　Oracle提供的开发工具包是Developer/2000、Designer/2000、Discover/2000、Oracle Office等，它涵盖了从建模、分析、设计到具体实现的各个环节。

Developer/2000包括：

　　Oracle Forms用于快速生成基于屏幕的复杂应用，具有GUI界面和多媒体功能，主要用于操纵数据和查询。

　　Oracle Reports是快速生成报表的工具。能生成各种复杂的报表，同样能处理多媒体信息。

　　Oracle Graphics用于生成各种图形应用。

　　Oracle Books用于生成联机文档。

Designer/2000：

　　这是Oracle提供的CASE工具。该工具能够帮助用户对复杂系统进行建模、分析和设计。还可以帮助用户绘制ER图、功能分层图、数据流图和方阵图。

Discover/2000:

　　这是一个OLAP工具，主要用于支持数据仓库应用。它可以对历史数据进行挖掘，以找到发展趋势，对不同层次的概况数据进行分析，以便发现有关业务的详细信息。

　　Oracle Office适用于办公自动化的，能完成企业范围内的消息接收与发送、日程安排、日历管理、目录管理以及拼写检查。

     
       要开发一个基于数据库的应用系统，其中最关键的一步就是整个系统所依据的数据库的建模设计，从逻辑的到物理的，一个环节疏于设计，整个的应用系统便似建立在危房之上，随着开发过程的不断深入，它要随时面临着各种难以预料的风险，开发者要为修改或重新设计没有设计好的数据库系统而付出难以预料的代价。所以，一个良好的数据库设计是高效率的系统所必须的。

一、逻辑建模

      数据库设计的方法因具体数据库而异，但是建模阶段的相同的，所以可以用一些通用的工具来进行，如Rational rose,PowerDesigner等，这一阶段主要是依据系统的需求，获取与分析要实现的应用系统信息,进行数据内部以及外在关系的分析，从而有效地建立整个系统的数据结构（在关系数据库中通常称为表结构），在此基础上对数据库的数据量、数据流量、及响应速度的估算分析，这样数据模型就产生了。具体的操作准则是数据库的几个范式、用户的具体需求和分析者的经验，从数据库的性能、安全、方便管理、易于开发等方面出发，具体方法因分析员的喜好和习惯而异，可以不用工具，最好使用工具，能让分析过程简便，最主要是能生成一些图，如E-R图，让分析过程一目了然。

二、物理设计（  要注意的地方很多哦@）

      此步设计和系统将具体使用的数据库有关，也和数据库所运行的硬、软件平台有关，目的是尽量合理地给数据库分配物理空间，这一步在数据库设计中很重要，关系到数据库数据的安全和数据库的性能，具体的来说，这一步包括相应表空间的数据文件在磁盘上的分配，还要根据数据量的大小确定redolog文件、rollback段的大小，然后进行分配，这些文件的分配要遵循一些原则，本着利于备份，利于性能优化的原则，原则如下（以ORACLE数据库为例）：

1、为表和索引建立不同的表空间，禁止在系统表空间中放入非核心oracle系统成分的对象，确保数据表空间和索引表空间位于不同的磁盘磁盘驱动器上。

2、了解终端用户怎样访问数据，如果可能，将经常同时查询和频繁查询的对象放在不同的物理磁盘上。

3、当数据库包含允许用户并行访问不同数据元素的大对象时，将对象分割存放在多个磁盘上是有好处的。可以采用分区。在某个操作系统平台上定义拥有数百万行的表时，则更需小心，因为数据库文件的大小受到限止，这种限制是由操作系统而不是由oracle引起的。

4、在独立的各盘上至少创建两个用户定义的rollback表空间，以存放用户自己的rollback段。在初始化文件中安排rollback段的次序，使它们在多个磁盘之间进行切换。

5、将redo log文件放在一个读写较少的盘上。对于每个oracle 实例要建立两个以上的redo log 组，同组的两个成员放在不同的设备上。

6、确立表和索引的大小，这决定了保存它们所需的表空间的尺寸，也决定了哪些表空间物理地装在哪些盘上和哪些表空间可以结合在一起。具体的估算方法可以按照oracle 一些公式，这里还要按照各个表的具体特性，用途，定义它的存贮参数如（pctfree,pctused）。

三、关于数据库参数的设计

      每个数据库在建立时，都有缺省的参数设置，但是对于具体的应用要求参数设置可能不同，缺省的参数设置往往需要根据应用系统的特点而需要改动，如每个数据库的操作系统平台、instance 数目、各种内存大小的设置、采取的线程方式、备份方式等不同，具体的参数就一定要进行最为恰当的修改，这个步骤对数据库性能很重要，也是保证应用系统所要求的数据库功能得以实现重要一步。

四、与开发软件的接口问题

      数据库设计最后要考虑的是与要选择的开发软件之间的接口问题，要准备好接口程序，有些是第三方软件已经备好的，有些是数据库本身要具备的，如jdbc,bde,ado,等与数据库的接口，主要是考虑接口的可用性、效率问题。这一步主要从经验出发，因为这种产品不断出台，而且都是经过各商家的吹捧，要在实践中决定哪个是最适合。

      以上是数据库建模设计的几个重要步骤的大致分析，整个设计过程是不断地改进的，是数据库管理员、设计人员、开发人员共同完成的，只是各有侧重点不同，数据库管理员侧重于是2、3步的设计，设计人员侧重于1步的设计，而开发人员侧重于4步的设计，由于有些应用系统的编程环境和实际应用环境不同，所以要做两套设计，并注意两套设计的兼容性可移植性。

      该系统应用于大型企业集团，包括几十个分厂，基本数据均来源于各分厂，各分厂有一套access数据库，存贮着自己的人才档案信息，由各厂自己维护，定期传到总的数据库里，供劳资处各室查询、统计用,。这是一个分部式的数据库。

一、逻辑建模

      首先是对数据库的数据量、数据流量、及响应速度的估算分析，这一步对物理设计也是必须的，劳资系统的主要数据是人员档案，大概有100兆左右，还有人员配备等信息加上工种序列、工资等级、厂矿车间等各种编码，总的数据量大约在某些方面300兆左右。数据的输入、维护大部分在各厂矿进行，然后到处里集中，所以数据流量很大，对响应速度要求一般。

在逻辑建模上的工具上，采用Rantional rose 2000，根据用户的需求，设计各种use case view， 在 logic view中生成数据库的实体，及实体之间的E-R图，然后生成Data modeler,确定以后，用Schema generation在建好的数据库中的对应的用户下生成表。

详细的图很繁琐，在这里就不展示了。

二、物理设计

1、因为职工档案信息库很大，还有照片，所以把它分成两个表，把照片单独地放在一个表中，并且采用分区技术，在档案表、照片表上建立分区，不同的分区分别放在不同的表空间。

2、因为职工档案信息库里有许多编码，查询的时候要和编码库一起进行read操作，所以不把职工档案信息表和编码库放在一个表空间。

3、建立二个rollback 表空间，十个rollback段，分区放在二个表空间里，建立一个比较大的rollback段，因为职工档案信息表经常会有批量的修改与添加。

4、将redo log文件放在一个读写较少的盘上。建立三个redo log 组，同组的两个成员放在两个盘上。因为选用的是ARCHIVELOG的备份方式。

5、根据每个表的性质，确定其存贮的参数，如职工档案信息表的修改、删除、插入都比较多，所以把它的Pctfree 10,Pctused 80定大小，估算出它大致需要的block数，算出存放这些表的表空间的数据文件的大小。

6、根据用户的需求，建立一套数据库的安全体系。也就是总结出几种权限级别的用户，建立这些用户，并给这些用户赋上相应的仅限，供开发人员编程时使用。

三、参数的设置

缺省的初始化参数文件中，选择large。因为用户数很多，100个左右。

SHARED_POOL_SIZE, 与数据库大小有关，也与应用软件有关。这里设成缺省值的1.5倍。

DB_BLOCK_BUFFERS 根据所用服务器的内存与交易数的大小，设为25兆。

SORT_AREA_SIZE 根据所用服务器的内存，设为10兆

LOG_BUFFER 用缺省值的1.5倍。

DBWR_IO_SLAVES 设为1

ROLLBACK_SEGMENTS 根据交易量的大小，定为10个。分别放在两个磁盘上。

PROCESS 80

MTS_SERVERS 3

MTS_DISPATCHERS tcp,3

ARCHIVE_LOG_START TRUE 采用ARCHIVE方式备份。

这些参数的确定是暂时的，没有一个系统可以运行之前把参数确定得正好，需要在应用程序运行之后进行调整。

四、与开发软件的接口问题

     因为我们这个系统的开发软件用的是Borland c++builder 5,所以采用的是比较成熟的BDE的接口，它是Borland公司提供的，性能比较好。

以上是根据多年数据库管理、开发的实践总结而出的数据库建模与设计的大致思路，希望能对大家有所帮助。

Oracle数据库的备份与恢复

---- 当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的故障（包括机器故障、介质故障、误操作等），数据库有时也可能遭到破坏，这时如何尽快恢复数据就成为当务之急。如果平时对数据库做了备份，那么此时恢复数据就显得很容易。由此可见，做好数据库的备份是多么的重要，下面笔者就以ORACLE7为例，来讲述一下数据库的备份和恢复。ORACLE 数据库有三种标准的备份方法，它们分别为导出/导入（EXPORT/IMPORT）、冷备份、热备份。导出备份是一种逻辑备份，冷备份和热备份是物理备份。

---- 一、 导出/导入（Export/Import）

---- 利用Export可将数据从数据库中提取出来，利用Import则可将提取出来的数据送回Oracle数据库中去。

---- 1. 简单导出数据（Export）和导入数据（Import）

---- Oracle支持三种类型的输出：

---- （1）表方式（T方式），将指定表的数据导出。

---- （2）用户方式（U方式），将指定用户的所有对象及数据导出。

---- （3）全库方式（Full方式），将数据库中的所有对象导出。

---- 数据导出（Import）的过程是数据导入（Export）的逆过程，它们的数据流向不同。

---- 2. 增量导出/导入

---- 增量导出是一种常用的数据备份方法，它只能对整个数据库来实施，并且必须作为SYSTEM来导出。在进行此种导出时，系统不要求回答任何问题。导出文件名缺省为export.dmp，如果不希望自己的输出文件定名为export.dmp，必须在命令行中指出要用的文件名。

---- 增量导出包括三个类型：

---- （1）“完全”增量导出（Complete）

---- 即备份整个数据库，比如：

---- ＄exp system/manager inctype=complete file=990702.dmp

---- （2） “增量型”增量导出

---- 备份上一次备份后改变的数据。比如：

---- ＄exp system/manager inctype=incremental file=990702.dmp

---- （3） “累计型”增量导出（Cumulative）

---- 累计型导出方式只是导出自上次“完全” 导出之后数据库中变化了的信息。比如：

---- ＄exp system/manager inctype=cumulative file=990702.dmp

---- 数据库管理员可以排定一个备份日程表，用数据导出的三个不同方式合理高效地完成。

---- 比如数据库的备份任务可作如下安排：

---- 星期一：完全导出（A）

---- 星期二：增量导出（B）

---- 星期三：增量导出（C）

---- 星期四：增量导出（D）

---- 星期五：累计导出（E）

---- 星期六：增量导出（F）

---- 星期日：增量导出（G）

---- 如果在星期日，数据库遭到意外破坏，数据库管理员可按以下步骤来恢复数据库：

---- 第一步：用命令CREATE DATABASE重新生成数据库结构；

---- 第二步：创建一个足够大的附加回段。

---- 第三步：完全增量导入A：

---- ＄imp system./manager inctype= RECTORE FULL=Y FILE=A

---- 第四步：累计增量导入E：

---- ＄imp system/manager inctype= RECTORE FULL=Y FILE =E

---- 第五步：最近增量导入F：

---- ＄imp system/manager inctype=RESTORE FULL=Y FILE=F

---- 二、 冷备份

---- 冷备份发生在数据库已经正常关闭的情况下，当正常关闭时会提供给我们一个完整的数据库。冷备份是将关键性文件拷贝到另外位置的一种说法。对于备份Oracle信息而言，冷备份是最快和最安全的方法。冷备份的优点是：

---- 1．是非常快速的备份方法（只需拷贝文件）

---- 2．容易归档（简单拷贝即可）

---- 3．容易恢复到某个时间点上（只需将文件再拷贝回去）

---- 4．能与归档方法相结合，作数据库“最新状态”的恢复。

---- 5．低度维护，高度安全。

---- 但冷备份也有如下不足：

---- 1．单独使用时，只能提供到“某一时间点上”的恢复。

---- 2．在实施备份的全过程中，数据库必须要作备份而不能作其它工作。也就是说，在冷备份过程中，数据库必须是关闭状态。

---- 3．若磁盘空间有限，只能拷贝到磁带等其它外部存储设备上，速度会很慢。

---- 4．不能按表或按用户恢复。

---- 如果可能的话（主要看效率），应将信息备份到磁盘上，然后启动数据库（使用户可以工作）并将所备份的信息拷贝到磁带上（拷贝的同时，数据库也可以工作）。冷备份中必须拷贝的文件包括：

---- 1．所有数据文件

---- 2．所有控制文件

---- 3．所有联机REDO LOG文件

---- 4．Init.ora文件（可选）。

---- 值得注意的是冷备份必须在数据库关闭的情况下进行，当数据库处于打开状态时，执行数据库文件系统备份是无效的

---- 下面是做冷备份的完整例子：

---- （1） 关闭数据库＄sqldba lmode=y

---- SQLDBA >connect internal;

---- SQLDBA >shutdown normal;

---- （2） 用拷贝命令备份全部的时间文件、重做日志文件、控制文件、初始化参数文件

---- SQLDBA >! cp < file > < backup directory >

---- （3） 重启Oracle数据库

---- ＄sqldba lmode=y

---- SQLDBA >connect internal;

---- SQLDBA >startup;

---- 三、 热备份

---- 热备份是在数据库运行的情况下，采用archivelog mode方式备份数据的方法。所以，如果你有昨天夜里的一个冷备份而且又有今天的热备份文件，在发生问题时，就可以利用这些资料恢复更多的信息。热备份要求数据库在Archivelog方式下操作，并需要大量的档案空间。一旦数据库运行在archivelog状态下，就可以做备份了。热备份的命令文件由三部分组成：

---- 1．数据文件一个表空间一个表空间地备份。

---- （1）设置表空间为备份状态

---- （2）备份表空间的数据文件

---- （3）恢复表空间为正常状态

---- 2．备份归档log文件。

---- （1）临时停止归档进程

---- （2）log下那些在archive redo log目标目录中的文件

---- （3）重新启动archive进程

---- （4）备份归档的redo log 文件

---- 3．用alter database backup controlfile命令来备份拷贝文件

---- 热备份的优点是：

---- 1．可在表空间或数据文件级备份，备份时间短。

---- 2．备份时数据库仍可使用。

---- 3．可达到秒级恢复（恢复到某一时间点上）。

---- 4．可对几乎所有数据库实体作恢复。

---- 5．恢复是快速的，在大多数情况下在数据库仍工作时恢复。

---- 热备份的不足是：

---- 1．不能出错，否则后果严重。

---- 2．若热备份不成功，所得结果不可用于时间点的恢复。

---- 3．因难于维护，所以要特别仔细小心，不允许“以失败而告终”。

      Codd提出OLAP的12条准则来描述OLAP系统：
      准则1 OLAP模型必须提供多维概念视图
      准则2 透明性准则
      准则3 存取能力推测
      准则4 稳定的报表能力
      准则5 客户/服务器体系结构
      准则6 维的等同性准则
      准则7 动态的稀疏矩阵处理准则
      准则8 多用户支持能力准则
      准则9 非受限的跨维操作
      准则10 直观的数据操纵
      准则11 灵活的报表生成
      准则12 不受限的维与聚集层次

      当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。下表列出了OLTP与OLAP之间的比较。

	OLTP	OLAP
用户	操作人员,低层管理人员	决策人员,高级管理人员
功能	日常操作处理	分析决策
DB 设计	面向应用	面向主题
数据	当前的, 最新的细节的, 二维的分立的	历史的, 聚集的, 多维的集成的, 统一的
存取	读/写数十条记录	读上百万条记录
工作单位	简单的事务	复杂的查询
用户数	上千个	上百个
DB 大小	100MB-GB	100GB-TB

　　在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

一、数据库和信息系统
　　(1)数据库是信息系统的核心和基础，把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的
　   　功能，使信息系统可以方便、及时、准确地从数据库中获得所需的信息。
　　(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。
　　(3)数据库设计是信息系统开发和建设的重要组成部分。
　　(4)数据库设计人员应该具备的技术和知识：
　　　 　数据库的基本知识和数据库设计技术
　　　　 计算机科学的基础知识和程序设计的方法和技巧
　　　 　软件工程的原理和方法
　　　　 应用领域的知识

二、数据库设计的特点
　　数据库建设是硬件、软件和干件的结合
　　　三分技术，七分管理，十二分基础数据
　　　技术与管理的界面称之为“干件”
　　数据库设计应该与应用系统设计相结合
　　　结构（数据）设计：设计数据库框架或数据库结构
　　　行为（处理）设计：设计应用程序、事务处理等
　　结构和行为分离的设计
　　　传统的软件工程忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究，忽视了对行为的设计
　　如图：

　　　　　　   　
三、数据库设计方法简述
　　手工试凑法
　　　设计质量与设计人员的经验和水平有直接关系
　　　缺乏科学理论和工程方法的支持，工程的质量难以保证
　　　数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价
　　规范设计法
　　　手工设计方
　　　基本思想
　　过程迭代和逐步求精
　　规范设计法(续)
　　典型方法：
　　(1)新奥尔良（New Orleans）方法：将数据库设计分为四个阶段
　　　　S.B.Yao方法：将数据库设计分为五个步骤
　　　　I.R.Palmer方法：把数据库设计当成一步接一步的过程
　　(2)计算机辅助设计
　　　　ORACLE Designer 2000
　　　　SYBASE PowerDesigner

四、数据库设计的基本步骤
　　数据库设计的过程(六个阶段)
　  1.需求分析阶段
　　　准确了解与分析用户需求（包括数据与处理）
　　　是整个设计过程的基础，是最困难、最耗费时间的一步
　　2.概念结构设计阶段
　　　是整个数据库设计的关键
　　　通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型
　　3.逻辑结构设计阶段
　　　将概念结构转换为某个DBMS所支持的数据模型
　　　对其进行优化
　　4.数据库物理设计阶段
　　　为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
　　5.数据库实施阶段
　　　运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果
　　　建立数据库，编制与调试应用程序，组织数据入库，并进行试运行
　　6.数据库运行和维护阶段
　　　数据库应用系统经过试运行后即可投入正式运行。
　　　在数据库系统运行过程中必须不断地对其进行评价、调整与修改
　　设计特点:
　　　在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

　　设计过程各个阶段的设计描述：
　　如图：
         

五、数据库各级模式的形成过程
　　1.需求分析阶段：综合各个用户的应用需求
　　2.概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式(E-R图)
　　3.逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式
　　4.物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

六、数据库设计技巧

　　1. 设计数据库之前（需求分析阶段）

　　1) 理解客户需求，询问用户如何看待未来需求变化。让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。

　　2) 了解企业业务可以在以后的开发阶段节约大量的时间。

　　3) 重视输入输出。

　　在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。
　　举例：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。

　　4) 创建数据字典和ER 图表

　　ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。

　　5) 定义标准的对象命名规范
　　数据库各种对象的命名必须规范。

　2. 表和字段的设计（数据库逻辑设计）

　　表设计原则

　　1) 标准化和规范化
　　数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
　　举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。
　　事实上，为了效率的缘故，对表不进行标准化有时也是必要的。

　　2) 数据驱动
　　采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
　　举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

　　3) 考虑各种变化
　　在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
　　举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

　　字段设计原则

　　4) 每个表中都应该添加的3 个有用的字段
dRecordCreationDate，在VB 下默认是Now()，而在SQL Server 　　• 下默认为GETDATE()
sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT 　　• USER
nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因 　　•

　　5) 对地址和电话采用多个字段
　　描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

　　6) 使用角色实体定义属于某类别的列
　　在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
　　举例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。

　　7) 选择数字类型和文本类型尽量充足
　　在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。
　　而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

　　8) 增加删除标记字段
　　在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。

　　3. 选择键和索引（数据库逻辑设计）


　　键选择原则：

　　1) 键设计4 原则

为关联字段创建外键。 　　•
所有的键都必须唯一。 　　•
避免使用复合键。 　　•
外键总是关联唯一的键字段。 　　•

　　2) 使用系统生成的主键
　　设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。

　　3) 不要用用户的键(不让主键具有可更新性)
　　在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。

　　4) 可选键有时可做主键
　　把可选键进一步用做主键，可以拥有建立强大索引的能力。

　　索引使用原则：

　　索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
　　1) 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
　　2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
　　3) 不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。
　　4) 不要索引常用的小型表
　　不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。

　　4. 数据完整性设计（数据库逻辑设计）

　　1) 完整性实现机制：

　　实体完整性：主键
　　参照完整性：
　　父表中删除数据：级联删除；受限删除；置空值
　　父表中插入数据：受限插入；递归插入
　　父表中更新数据：级联更新；受限更新；置空值
　　DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制

　　用户定义完整性：
　　NOT NULL；CHECK；触发器

　　2) 用约束而非商务规则强制数据完整性

　　采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。

　　3) 强制指示完整性
　　在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

　　4) 使用查找控制数据完整性
　　控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。

　　5) 采用视图
　　为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

　　5. 其他设计技巧

　　1) 避免使用触发器

　　触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

　　2) 使用常用英语（或者其他任何语言）而不要使用编码

　　在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。

　　3) 保存常用信息

　　让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复（对Access）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。

　　4) 包含版本机制

　　在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。

　　5) 编制文档

　　对所有的快捷方式、命名规范、限制和函数都要编制文档。
　　采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
　　对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。

　　6) 测试、测试、反复测试
　　建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。

　　7) 检查设计
　　在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

BI   

Business Intelligence
商业智能，也看到有些媒体里写作商务智能
综合企业所有沉淀下来的信息，用科学的分析方法，为企业领导提供科学决策信息的过程
。  


BOSS

业务运营支撑系统:Business Operations Support Systems,简称BOSS


BPM   

企业绩效管理


BPR   

业务流程重整（Business Process Reengineering）,指利用数据仓库技术，发现并纠正企
业业务流程中的弊端的一项工作。数据仓库的重要作用之一。


CRM   

Customer Relationship Management
客户关系管理。CRM是选择和管理有价值客户及其关系的一种商业策略，CRM要求以客户为
中心的商业哲学和企业文化来支持有效的市场营销、销售与服务流程。


Data mart   

即数据集市，或者叫做“小数据仓库”。如果说数据仓库是建立在企业级的数据模型之上
的话。那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面
向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。


DM

DM （Data Mine）数据挖掘.
数据挖掘是一个从大型数据库中提取以前未知的，可理解的，可执行的信息并用它来进行
关键的商业决策的过程。


DSS   

决策支持系统（Decision Support system），相当于基于数据仓库的应用。决策支持就是
在收集所有有关数据和信息，经过加工整理，来为企业决策管理层提供信息，为决策者的
决策提供依据。


DW   

Data warehouse
本世纪80年代中期，“数据仓库之父”William H.Inmon先生在其《建立数据仓库》一书中
定义了数据仓库的概念，随后又给出了更为精确的定义：数据仓库是在企业管理和决策中
面向主题的、集成的、与时间相关的、不可修改的数据集合。与其他数据库应用不同的是
，数据仓库更像一种过程，对分布在企业内部各处的业务数据的整合、加工和分析的过程
。而不是一种可以购买的产品。


EAI   

Enterprise Application Integration
企业应用整合,即通过信息技术将企业内部各种应用整合起来
。


EDM   

Enterprise Data Model
企业数据模型


EIP   

Enterprise Information Portal
企业信息门户
EAI(企业业务程序综合)+BPI(业务处理过程综合)


EIS   

领导信息系统（Executive Information System）,指为了满足无法专注于计算机技术的领
导人员的信息查询需求，而特意制定的以简单的图形界面访问数据仓库的一种应用。


EIS   

企业信息系统


ERP

Enterprise Resourse Planning
企业资源规划。它是一个以管理会计为核心的信息系统，识别和规划企业资源，从而获取
客户订单，完成加工和交付，最后得到客户付款。
  换言之，ERP将企业内部所有资源整合在一起，对采购、生产、成本、库存、分销、运输
、财务、人力资源进行规划，从而达到最佳资源组合，取得最佳效益。



ETL   

数据抽取（Extract）、转换（Transform）、清洗（Cleansing）、装载（Load）的过程。
构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先
定义好的数据仓库模型，将数据加载到数据仓库中去。


KDD   

KDD（Knowledge Discovery in Database）数据库中知识发现。是基于数据库的知识发现
，指的是从大型数据库或数据仓库中提取人们感兴趣的知识，这些知识是隐含的、事先未
知的、潜在有用的、易被理解的模式。


KPI  
企业关键业绩指标(KPI：Key Process Indication)是通过对组织内部流程的输入端、输出
端的关键参数进行设置、取样、计算、分析，衡量流程绩效的一种目标式量化管理指标，
是把企业的战略目标分解为可操作的工作目标的工具，是企业绩效管理的基础。


LDM  
逻辑数据模型


mdd  
多维数据库（MultiDimesional Database,MDD）可以简单地理解为：将数据存放在一个
n维数组中，而不是像关系数据库那样以记录的形式存放。因此它存在大量稀疏矩阵，人们
可以通过多维视图来观察数据。多维数据库增加了一个时间维，与关系数据库相比，它的
优势在于可以提高数据处理速度，加快反应时间，提高查询效率。


Metadata

Metadata(元数据)，它是“关于数据的数据”在地理空间信息中用于描述地理数据集的内
容、质量、表示方式、空间参考、管理方式以及数据集的其他特征，它是实 现地理空间信
息共享的核心标准之一。目前，国际上对空间元数据标准内容进行研究的组织 主要有三个
，分别是欧洲标准化委员会(CEN/TC 287)、美国联邦地理数据委员会(FGDC)和国 际标准化
组织地理信息/地球信息技术委员会(ISO/TC 211)。


MOLAP   

严格遵照Codd的定义，自行建立了多维数据库，来存放联机分析系统数据的Arbor Softwa
re,开创了多维数据存储的先河，后来的很多家公司纷纷采用多维数据存储。被人们称为M
uiltDimension OLAP,简称MOLAP，代表产品有Hyperion(原Arbor software) Essbase、Sh
owcase STRATEGY等。


ODS

(oprational Data Store)操作型数据存储，对于一些准实时的业务数据库当中的数据的暂
时存储，支持一些同时关连到历史数据与实时数据分析的数据暂时存储区域


OLAP   

OLAP(online analytical processing)概念最早是由关系数据库之父E.F.Codd于1993年提
出的。当时,Codd认为联机事务处理(OLTP)已不能满足终端用户对数据库查询分析的需要,
SQL对大数据库进行的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数
据库进行大量计算才能得到结果,而查询的结果并不能满足决策者提出的需求。因此Codd提
出了多维数据库和多维分析的概念,即OLAP。Codd提出OLAP的12条准则来描述OLAP系统：


准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力推测
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次



PDM

物理数据模型


ROLAP  

基于Codd的12条准则，各个软件开发厂家见仁见智，其中一个流派，认为可以沿用关系型
数据库来存储多维数据，于是，基于稀疏矩阵表示方法的星型结构（starschema）就出现
了。后来又演化出雪花结构。为了与多维数据库相区别，则把基于关系型数据库的OLAP称
为Relational OLAP，简称ROLAP。代表产品有Informix Metacube、Microsoft SQL Serve
r。  


SCM  
Supply Chain Management
供应链管理。SCM就是对企业供应链的管理，是对供应、需求、原材料采购、市场、生产、
库存、定单、分销发货等的管理，包括了从生产到发货、从供应商的供应商到顾客的顾客
的每一个环节。



Spiral Development  
螺旋式开发


Waterfall Development  
瀑布式开发


前端工具：主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种基于数据仓库或数据集市
的应用开发工具。其中数据分析工具主要针对OLAP服务器，报表工具， 数据挖掘工具主要针对数据仓库。

比较流行的BI平台：IBM   DB2II(Inforamtion Integrator,信息集成器)
                                   微软的BI平台
                                    BO(Business Object)
                                   Brio
                   
                   
目前提供的DM产品的厂商非常多：
                   SAS Enterprise Miner
                   NCR Teradata Warehouse Miner
                   SPSS Clementine 7.0
                   IBM  DB2 Intelligent Mine
                   SQL Server 2000数据挖掘组件
                   Oracle9i Data Mining
                   CA CleverPath Predictive Analysis Server
                   德门软件DMiner等。



NGBOSS是对业务支撑系统的重构，有3个特点：

（1 ）从流程和业务能力着手，整合营销流程和服务流程，构建CRM 体系；

（2）对智能业务和传统业务、话音和数据业务的支撑进行统一的规划，实现3G业务运营能力的飞跃；

（3）重新规划和设计BOSS 系统的体系架构，进一步提升业务支撑网的先进性、易用性、可扩展性和标准化程度。

CRM 体系：
什么叫CRM？CRM最原始的定义是销售自动化，是怎么把销售人员的销售过程通过一个软件管理起来，
这是CRM原始的定义。随着发展，CRM的面逐渐扩大了。现在提CRM是从一个广义角度来说，讲的是以客户为核心的管理系统。
是怎样保证信息系统以客户为核心，这部分叫CRM。

网友问电信级的CRM市场，可能是针对一些广义的CRM的概念，就是以客户为核心的CRM系统。它的范围大一些，包括销售的管理，服务的过程，整个营销过程都会在这个范围之内。我感觉电信级CRM市场应该是有一个广阔的发展空间。为什么呢？到今年年底，按照WTO的规定整个电信市场是要开放的，这样电信必须把信息化系统整合成以客户为核心的理念才能迎接未来的挑战。2006年对电信运营商来说，如何建立一个CRM体系是很关键的，我相信今年或者明年会有一个长足的发

sap  是一家公司， www.sap.com
     www.tcp.org----看什么那些数据仓库厂家的数据仓库是最好的， 提供了一些性能的比较
    
  几家做的比较好的CRM系统： 1.  sap  的crm
      2.   peoplesoft CRM , 仁科， ORACLE收购的一个公司
      3. siebel 的CEM

       先说业务建模，业务建模一般分两类。第一类是为了解决某个业务问题而建立一个业务模型或者数据模型。第二类是将企业的业务状况、业务流程及用户对业务的分析视角等信息用计算机的语言表示出来。这两类建模从方法到目的都是不同的。

     第一类，举例来说，对客户信用状况的评价，这需要从业务的角度来考虑反映客户信用状况的因素各占多少比重等等内容，这些是业务人员需要完成的工作，有大量的领域知识在里面。这部分建模的结果有些会反映到信息系统中，有些就只是咨询，反映到用户的日常工作中。

     第二类，是对企业业务状况的描述，如贷款和抵押品之间是什么关系，与抵押品相关的信息都有那些、产品内部的层级关系，用户分析问题的业务视角等等，这些内容需要业务人员和信息人员共同参与完成，最终体现在信息系统之中也就是开发人员使用的数据表。

      对于KPI的建模是属于第一类业务建模，它的重点在于哪些因素会影响KPI，影响的比重有多大。但是计算KPI需要的因素以及对这些因素的数据需求都属于第二类业务建模。

       再说数据建模，数据建模也分为两个步骤，第一类是逻辑模型，第二类是物理模型。这两类模型的差别并不是很大。

       第一类，逻辑模型，也称为实体关系模型（维度建模可以认为是实体关系建模中的一种），是用计算机术语表示出来的业务状况以及业务分析视角。事实上，逻辑模型就是前面提到的第二类业务模型。我们是做信息系统的，所作的东西最终都是要体现在计算机里，所以，第二类业务模型和数据模型之间的距离并不大。

       第二类，物理模型，是将逻辑模型转化成的物理表，这里会出于性能、效率和易用性等考虑对逻辑模型做一些处理。这些处理在逻辑模型中也存在。将逻辑模型转化为物理模型需要DBA的参与。

       而我们在日常工作中提到的业务建模一般是指第一类业务建模，即从业务的角度来设计KPI等内容。我们在日常工作中提到的数据建模一般是指第二类业务建模，也是第一类数据建模。这两类原本就是同一份工作。也许有很牛的公司会将这两部分分开，请完全不懂技术的业务专家来设计这部分。但大部分情况下这部分是需要业务和技术都懂的人来完成。我理解innovate511提到的数据建模应该是这类和业务也直接相关的建模，而不是纯数据的建模。（请innovate511确认。）

      我们再看DW和BI，一般DW里不会有第一类业务模型，但是一定会有第一类业务模型需要的数据，也可能有第一类业务模型分析的结果。而BI里可能有第一类业务模型，也可能没有第一类业务模型，例如对数据进行OLAP分析就不一定有第一类业务模型。但是勿庸置疑的是，无论是DW还是BI，它的目的都是为业务服务的。所以说业务驱动BI、DW或者说需求驱动BI、DW都是一定的。但是归根到底，DW和BI都是用来辅助分析的，真正提高企业效益的是使用DW和BI的分析人员。从非技术层面来促进BI成功我的感觉更像是借助BI来提出的管理咨询，而不是信息技术咨询。

    要开发一个基于数据库的应用系统，其中最关键的一步就是整个系统所依据的数据库的建模设计，从逻辑的到物理的，一个环节疏于设计，整个的应用系统便似建立在危房之上，随着开发过程的不断深入，它要随时面临着各种难以预料的风险，开发者要为修改或重新设计没有设计好的数据库系统而付出难以预料的代价。所以，一个良好的数据库设计是高效率的系统所必须的。

一、逻辑建模

数据库设计的方法因具体数据库而异，但是建模阶段的相同的，所以可以用一些通用的工具来进行，如Rational rose,PowerDesigner等，这一阶段主要是依据系统的需求，获取与分析要实现的应用系统信息,进行数据内部以及外在关系的分析，从而有效地建立整个系统的数据结构（在关系数据库中通常称为表结构），在此基础上对数据库的数据量、数据流量、及响应速度的估算分析，这样数据模型就产生了。具体的操作准则是数据库的几个范式、用户的具体需求和分析者的经验，从数据库的性能、安全、方便管理、易于开发等方面出发，具体方法因分析员的喜好和习惯而异，可以不用工具，最好使用工具，能让分析过程简便，最主要是能生成一些图，如E-R图，让分析过程一目了然。

二、物理设计

此步设计和系统将具体使用的数据库有关，也和数据库所运行的硬、软件平台有关，目的是尽量合理地给数据库分配物理空间，这一步在数据库设计中很重要，关系到数据库数据的安全和数据库的性能，具体的来说，这一步包括相应表空间的数据文件在磁盘上的分配，还要根据数据量的大小确定redolog文件、rollback段的大小，然后进行分配，这些文件的分配要遵循一些原则，本着利于备份，利于性能优化的原则，原则如下（以ORACLE数据库为例）：

1、为表和索引建立不同的表空间，禁止在系统表空间中放入非核心oracle系统成分的对象，确保数据表空间和索引表空间位于不同的磁盘磁盘驱动器上。

2、了解终端用户怎样访问数据，如果可能，将经常同时查询和频繁查询的对象放在不同的物理磁盘上。

3、当数据库包含允许用户并行访问不同数据元素的大对象时，将对象分割存放在多个磁盘上是有好处的。可以采用分区。在某个操作系统平台上定义拥有数百万行的表时，则更需小心，因为数据库文件的大小受到限止，这种限制是由操作系统而不是由oracle引起的。

4、在独立的各盘上至少创建两个用户定义的rollback表空间，以存放用户自己的rollback段。在初始化文件中安排rollback段的次序，使它们在多个磁盘之间进行切换。

5、将redo log文件放在一个读写较少的盘上。对于每个oracle 实例要建立两个以上的redo log 组，同组的两个成员放在不同的设备上。

6、确立表和索引的大小，这决定了保存它们所需的表空间的尺寸，也决定了哪些表空间物理地装在哪些盘上和哪些表空间可以结合在一起。具体的估算方法可以按照oracle 一些公式，这里还要按照各个表的具体特性，用途，定义它的存贮参数如（pctfree,pctused）。

三、关于数据库参数的设计

每个数据库在建立时，都有缺省的参数设置，但是对于具体的应用要求参数设置可能不同，缺省的参数设置往往需要根据应用系统的特点而需要改动，如每个数据库的操作系统平台、instance 数目、各种内存大小的设置、采取的线程方式、备份方式等不同，具体的参数就一定要进行最为恰当的修改，这个步骤对数据库性能很重要，也是保证应用系统所要求的数据库功能得以实现重要一步。

四、与开发软件的接口问题

数据库设计最后要考虑的是与要选择的开发软件之间的接口问题，要准备好接口程序，有些是第三方软件已经备好的，有些是数据库本身要具备的，如jdbc,bde,ado,等与数据库的接口，主要是考虑接口的可用性、效率问题。这一步主要从经验出发，因为这种产品不断出台，而且都是经过各商家的吹捧，要在实践中决定哪个是最适合。

以上是数据库建模设计的几个重要步骤的大致分析，整个设计过程是不断地改进的，是数据库管理员、设计人员、开发人员共同完成的，只是各有侧重点不同，数据库管理员侧重于是2、3步的设计，设计人员侧重于1步的设计，而开发人员侧重于4步的设计，由于有些应用系统的编程环境和实际应用环境不同，所以要做两套设计，并注意两套设计的兼容性可移植性。

下面结合一个实际开发的劳资管理系统中的数据库设计，对以上几个步骤做进一步解释。

该系统应用于大型企业集团，包括几十个分厂，基本数据均来源于各分厂，各分厂有一套access数据库，存贮着自己的人才档案信息，由各厂自己维护，定期传到总的数据库里，供劳资处各室查询、统计用,。这是一个分部式的数据库。

一、逻辑建模

     首先是对数据库的数据量、数据流量、及响应速度的估算分析，这一步对物理设计也是必须的，劳资系统的主要数据是人员档案，大概有100兆左右，还有人员配备等信息加上工种序列、工资等级、厂矿车间等各种编码，总的数据量大约在某些方面300兆左右。数据的输入、维护大部分在各厂矿进行，然后到处里集中，所以数据流量很大，对响应速度要求一般。

    在逻辑建模上的工具上，采用Rantional rose 2000，根据用户的需求，设计各种use case view， 在 logic view中生成数据库的实体，及实体之间的E-R图，然后生成Data modeler,确定以后，用Schema generation在建好的数据库中的对应的用户下生成表。

    详细的图很繁琐，在这里就不展示了。

二、物理设计

     1、因为职工档案信息库很大，还有照片，所以把它分成两个表，把照片单独地放在一个表中，并且采用分区技术，在档案表、照片表上建立分区，不同的分区分别放在不同的表空间。

     2、因为职工档案信息库里有许多编码，查询的时候要和编码库一起进行read操作，所以不把职工档案信息表和编码库放在一个表空间。

      3、建立二个rollback 表空间，十个rollback段，分区放在二个表空间里，建立一个比较大的rollback段，因为职工档案信息表经常会有批量的修改与添加。

      4、将redo log文件放在一个读写较少的盘上。建立三个redo log 组，同组的两个成员放在两个盘上。因为选用的是ARCHIVELOG的备份方式。

       5、根据每个表的性质，确定其存贮的参数，如职工档案信息表的修改、删除、插入都比较多，所以把它的Pctfree 10,Pctused 80定大小，估算出它大致需要的block数，算出存放这些表的表空间的数据文件的大小。

       6、根据用户的需求，建立一套数据库的安全体系。也就是总结出几种权限级别的用户，建立这些用户，并给这些用户赋上相应的仅限，供开发人员编程时使用。

三、参数的设置

缺省的初始化参数文件中，选择large。因为用户数很多，100个左右。

SHARED_POOL_SIZE, 与数据库大小有关，也与应用软件有关。这里设成缺省值的1.5倍。

DB_BLOCK_BUFFERS 根据所用服务器的内存与交易数的大小，设为25兆。

SORT_AREA_SIZE 根据所用服务器的内存，设为10兆

LOG_BUFFER 用缺省值的1.5倍。

DBWR_IO_SLAVES 设为1

ROLLBACK_SEGMENTS 根据交易量的大小，定为10个。分别放在两个磁盘上。

　　
            　　PROCESS 80
            　　
            　　MTS_SERVERS 3
            　　
            　　MTS_DISPATCHERS tcp,3

ARCHIVE_LOG_START TRUE 采用ARCHIVE方式备份。

    这些参数的确定是暂时的，没有一个系统可以运行之前把参数确定得正好，需要在应用程序运行之后进行调整。

四、与开发软件的接口问题

     因为我们这个系统的开发软件用的是Borland c++builder 5,所以采用的是比较成熟的BDE的接口，它是Borland公司提供的，性能比较好。

     以上是根据多年数据库管理、开发的实践总结而出的数据库建模与设计的大致思路，希望能对大家有所帮助。

　　数据库的最初雏形据说源自美国一个奶牛场的记账薄(纸质的，由此可见，数据库并不一定是存储在电脑里的数据^_^)，里面记录的是该奶牛场的收支账目，程序员在将其整理、录入到电脑中时从中受到启发。当按照规定好的数据结构所采集到的数据量大到一定程度后，出于程序执行效率的考虑，程序员将其中的检索、更新维护等功能分离出来，做成单独调用的模块，这个模块后来就慢慢发展、演变成现在我们所接触到的数据库管理系统(DBMS)——程序开发中的一个重要分支。

　　下面进入正题，首先按我个人所接触过的程序给数据库设计人员的功底分一下类：
　　１、没有系统学习过数据结构的程序员。这类程序员的作品往往只是他们的即兴玩具，他们往往习惯只设计有限的几个表，实现某类功能的数据全部塞在一个表中，各表之间几乎毫无关联。网上不少的免费管理软件都是这样的东西，当程序功能有限，数据量不多的时候，其程序运行起来没有什么问题，但是如果用其管理比较重要的数据，风险性非常大。
　　２、系统学习过数据结构，但是还没有开发过对程序效率要求比较高的管理软件的程序员。这类人多半刚从学校毕业不久，他们在设计数据库表结构时，严格按照教科书上的规定，死扣E-R图和3NF(别灰心，所有的数据库设计高手都是从这一步开始的)。他们的作品，对于一般的access型轻量级的管理软件，已经够用。但是一旦该系统需要添加新功能，原有的数据库表差不多得进行大换血。
　　３、第二类程序员，在经历过数次程序效率的提升，以及功能升级的折腾后，终于升级成为数据库设计的老鸟，第一类程序员眼中的高人。这类程序员可以胜任二十个表以上的中型商业数据管理系统的开发工作。他们知道该在什么样的情况下保留一定的冗余数据来提高程序效率，而且其设计的数据库可拓展性较好，当用户需要添加新功能时，原有数据库表只需做少量修改即可。
　　４、在经历过上十个类似数据库管理软件的重复设计后，第三类程序员中坚持下来没有转行，而是希望从中找出“偷懒”窍门的有心人会慢慢觉悟，从而完成量变到质变的转换。他们所设计的数据库表结构有一定的远见，能够预测到未来功能升级所需要的数据，从而预先留下伏笔。这类程序员目前大多晋级成数据挖掘方面的高级软件开发人员。
　　５、第三类程序员或第四类程序员，在对现有的各家数据库管理系统的原理和开发都有一定的钻研后，要么在其基础上进行二次开发，要么自行开发一套有自主版权的通用数据库管理系统。

　　我个人正处于第三类的末期，所以下面所列出的一些设计技巧只适合第二类和部分第三类数据库设计人员。同时，由于我很少碰到有兴趣在这方面深钻下去的同行，所以文中难免出现错误和遗漏，在此先行声明，欢迎大家指正，不要藏私哦8)

　　一、树型关系的数据表
　　不少程序员在进行数据库设计的时候都遇到过树型关系的数据，例如常见的类别表，即一个大类，下面有若干个子类，某些子类又有子类这样的情况。当类别不确定，用户希望可以在任意类别下添加新的子类，或者删除某个类别和其下的所有子类，而且预计以后其数量会逐步增长，此时我们就会考虑用一个数据表来保存这些数据。按照教科书上的教导，第二类程序员大概会设计出类似这样的数据表结构：

类别表_1(Type_table_1)
名称　　　　　类型　　　　约束条件　　　说明
type_id 　 int 　 无重复　　 类别标识，主键
type_name　　 char(50) 不允许为空 类型名称，不允许重复
type_father int 不允许为空 该类别的父类别标识，如果是顶节点的话设定为某个唯一值

　　这样的设计短小精悍，完全满足3NF，而且可以满足用户的所有要求。是不是这样就行呢？答案是NO！Why？

　　我们来估计一下用户希望如何罗列出这个表的数据的。对用户而言，他当然期望按他所设定的层次关系一次罗列出所有的类别，例如这样：
总类别
　　类别1
　　　　类别1.1
　　　　　　类别1.1.1
　　　　类别1.2
　　类别2
　　　　类别2.1
　　类别3
　　　　类别3.1
　　　　类别3.2
　　……

　　看看为了实现这样的列表显示(树的先序遍历)，要对上面的表进行多少次检索？注意，尽管类别1.1.1可能是在类别3.2之后添加的记录，答案仍然是N次。这样的效率对于少量的数据没什么影响，但是日后类型扩充到数十条甚至上百条记录后，单单列一次类型就要检索数十次该表，整个程序的运行效率就不敢恭维了。或许第二类程序员会说，那我再建一个临时数组或临时表，专门保存类型表的先序遍历结果，这样只在第一次运行时检索数十次，再次罗列所有的类型关系时就直接读那个临时数组或临时表就行了。其实，用不着再去分配一块新的内存来保存这些数据，只要对数据表进行一定的扩充，再对添加类型的数量进行一下约束就行了，要完成上面的列表只需一次检索就行了。下面是扩充后的数据表结构：

类别表_2(Type_table_2)
名称　　　　　类型　　　　约束条件　　　 说明
type_id 　 int 　 无重复　　 类别标识，主键
type_name　　 char(50) 不允许为空 类型名称，不允许重复
type_father int 不允许为空 该类别的父类别标识，如果是顶节点的话设定为某个唯一值
type_layer char(6) 限定3层,初始值为000000 类别的先序遍历，主要为减少检索数据库的次数

　　按照这样的表结构，我们来看看上面例子记录在表中的数据是怎样的：

type_id type_name type_father type_layer
1 总类别 0 000000
2 类别1 1 010000
3 类别1.1 2 010100
4 类别1.2 2 010200
5 类别2 1 020000
6 类别2.1 5 020100
7 类别3 1 030000
8 类别3.1 7 030100
9 类别3.2 7 030200
10 类别1.1.1 3 010101
……

　　现在按type_layer的大小来检索一下：SELECT * FROM Type_table_2 ORDER BY type_layer

列出记录集如下：

type_id type_name type_father type_layer
1 总类别 0 000000
2 类别1 1 010000
3 类别1.1 2 010100
10 类别1.1.1 3 010101
4 类别1.2 2 010200
5 类别2 1 020000
6 类别2.1 5 020100
7 类别3 1 030000
8 类别3.1 7 030100
9 类别3.2 7 030200
……

　　现在列出的记录顺序正好是先序遍历的结果。在控制显示类别的层次时，只要对type_layer字段中的数值进行判断，每2位一组，如大于0则向右移2个空格。当然，我这个例子中设定的限制条件是最多3层，每层最多可设99个子类别，只要按用户的需求情况修改一下type_layer的长度和位数，即可更改限制层数和子类别数。其实，上面的设计不单单只在类别表中用到，网上某些可按树型列表显示的论坛程序大多采用类似的设计。

　　或许有人认为，Type_table_2中的type_father字段是冗余数据，可以除去。如果这样，在插入、删除某个类别的时候，就得对type_layer 的内容进行比较繁琐的判定，所以我并没有消去type_father字段，这也正符合数据库设计中适当保留冗余数据的来降低程序复杂度的原则，后面我会举一个故意增加数据冗余的案例。

　　
　　二、商品信息表的设计
　　假设你是一家百货公司电脑部的开发人员，某天老板要求你为公司开发一套网上电子商务平台，该百货公司有数千种商品出售，不过目前仅打算先在网上销售数十种方便运输的商品，当然，以后可能会陆续在该电子商务平台上增加新的商品出售。现在开始进行该平台数据库的商品信息表的设计。每种出售的商品都会有相同的属性，如商品编号，商品名称，商品所属类别，相关信息，供货厂商，内含件数，库存，进货价，销售价，优惠价。你很快就设计出4个表：商品类型表(Wares_type)，供货厂商表(Wares_provider)，商品信息表(Wares_info)：

商品类型表(Wares_type)
名称　　　　　类型　　　　约束条件　　　 说明
type_id 　 int 　 无重复　　 类别标识，主键
type_name　　 char(50) 不允许为空 类型名称，不允许重复
type_father int 不允许为空 该类别的父类别标识，如果是顶节点的话设定为某个唯一值
type_layer char(6) 限定3层,初始值为000000 类别的先序遍历，主要为减少检索数据库的次数

供货厂商表(Wares_provider)
名称　　　　　类型　　　　约束条件　　　 说明
provider_id int 　 无重复　　 供货商标识，主键
provider_name char(100) 不允许为空 供货商名称

商品信息表(Wares_info)
名称　　　　 类型　　　　约束条件　　　 说明
wares_id int 　 无重复　　 商品标识，主键
wares_name char(100) 不允许为空 商品名称
wares_type　　 int 不允许为空　　　　　　　　　　 商品类型标识，和Wares_type.type_id关联
wares_info char(200) 允许为空 相关信息
provider int 不允许为空 供货厂商标识，和Wares_provider.provider_id关联
setnum int 初始值为1 内含件数，默认为1
stock int 初始值为0 库存，默认为0
buy_price money 不允许为空 进货价
sell_price money 不允许为空 销售价
discount money 不允许为空 优惠价

　　你拿着这3个表给老板检查，老板希望能够再添加一个商品图片的字段，不过只有一部分商品有图片。OK，你在商品信息表(Wares_info)中增加了一个haspic的BOOL型字段，然后再建了一个新表——商品图片表(Wares_pic)：

商品图片表(Wares_pic)
名称　　　　 类型　　　　约束条件　　　 说明
pic_id int 　 无重复　　 商品图片标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
pic_address　 char(200) 不允许为空　　　　　　　　　　 图片存放路径

　　程序开发完成后，完全满足老板目前的要求，于是正式启用。一段时间后，老板打算在这套平台上推出新的商品销售，其中，某类商品全部都需添加“长度”的属性。第一轮折腾来了……当然，你按照添加商品图片表的老方法，在商品信息表(Wares_info)中增加了一个haslength的BOOL型字段，又建了一个新表——商品长度表(Wares_length)：

商品长度表(Wares_length)
名称　　　　 类型　　　　约束条件　　　 说明
length_id int 　 无重复　　 商品图片标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
length　 char(20) 不允许为空　　　　　　　　　　 商品长度说明

　　刚刚改完没多久，老板又打算上一批新的商品，这次某类商品全部需要添加“宽度”的属性。你咬了咬牙，又照方抓药，添加了商品宽度表(Wares_width)。又过了一段时间，老板新上的商品中有一些需要添加“高度”的属性，你是不是开始觉得你所设计的数据库按照这种方式增长下去，很快就能变成一个迷宫呢？那么，有没有什么办法遏制这种不可预见性，但却类似重复的数据库膨胀呢？我在阅读《敏捷软件开发：原则、模式与实践》中发现作者举过类似的例子：7.3　“Copy”程序。其中，我非常赞同敏捷软件开发这个观点：在最初几乎不进行预先设计，但是一旦需求发生变化，此时作为一名追求卓越的程序员，应该从头审查整个架构设计，在此次修改中设计出能够满足日后类似修改的系统架构。下面是我在需要添加“长度”的属性时所提供的修改方案：

　　去掉商品信息表(Wares_info)中的haspic字段，添加商品额外属性表(Wares_ex_property)和商品额外信息表(Wares_ex_info)2个表来完成添加新属性的功能。

商品额外属性表(Wares_ex_property)
名称　　　　 类型　　　　约束条件　　　 说明
ex_pid int 　 无重复　　 商品额外属性标识，主键
p_name char(20) 不允许为空 额外属性名称

商品额外信息表(Wares_ex_info)
名称　　　　 类型　　　　约束条件　　　 说明
ex_iid int 　 无重复　　 商品额外信息标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
property_id　 int 不允许为空　　　　　　　　　　 商品额外属性标识，和Wares_ex_property.ex_pid关联
property_value char(200) 不允许为空 商品额外属性值

　　在商品额外属性表(Wares_ex_property)中添加2条记录：
ex_pid p_name
1 商品图片
2 商品长度

　　再在整个电子商务平台的后台管理功能中追加一项商品额外属性管理的功能，以后添加新的商品时出现新的属性，只需利用该功能往商品额外属性表(Wares_ex_property)中添加一条记录即可。不要害怕变化，被第一颗子弹击中并不是坏事，坏的是被相同轨道飞来的第二颗、第三颗子弹击中。第一颗子弹来得越早，所受的伤越重，之后的抵抗力也越强8)

　　三、多用户及其权限管理的设计
　　开发数据库管理类的软件，不可能不考虑多用户和用户权限设置的问题。尽管目前市面上的大、中型的后台数据库系统软件都提供了多用户，以及细至某个数据库内某张表的权限设置的功能，我个人建议：一套成熟的数据库管理软件，还是应该自行设计用户管理这块功能，原因有二：
　　1.那些大、中型后台数据库系统软件所提供的多用户及其权限设置都是针对数据库的共有属性，并不一定能完全满足某些特例的需求；
　　2.不要过多的依赖后台数据库系统软件的某些特殊功能，多种大、中型后台数据库系统软件之间并不完全兼容。否则一旦日后需要转换数据库平台或后台数据库系统软件版本升级，之前的架构设计很可能无法重用。

　　下面看看如何自行设计一套比较灵活的多用户管理模块，即该数据库管理软件的系统管理员可以自行添加新用户，修改已有用户的权限，删除已有用户。首先，分析用户需求，列出该数据库管理软件所有需要实现的功能；然后，根据一定的联系对这些功能进行分类，即把某类用户需使用的功能归为一类；最后开始建表：
　　
功能表(Function_table)
名称　　类型　 约束条件　　　说明
f_id int 　 无重复　　 功能标识，主键
f_name char(20) 不允许为空 功能名称，不允许重复
f_desc char(50) 允许为空 功能描述

用户组表(User_group)
名称　　 类型　 约束条件　　　说明
group_id int 无重复 用户组标识，主键
group_name char(20) 不允许为空 用户组名称
group_power char(100) 允许为空 用户组权限表，内容为功能表f_id的集合

用户表(User_table)
名称　　　　类型　　　　约束条件　　　说明
user_id int 无重复 用户标识，主键
user_name char(20) 无重复 用户名
user_pwd char(20) 不允许为空 用户密码
user_type int 不允许为空 所属用户组标识，和User_group.group_id关联

　　采用这种用户组的架构设计，当需要添加新用户时，只需指定新用户所属的用户组；当以后系统需要添加新功能或对旧有功能权限进行修改时，只用操作功能表和用户组表的记录，原有用户的功能即可相应随之变化。当然，这种架构设计把数据库管理软件的功能判定移到了前台，使得前台开发相对复杂一些。但是，当用户数较大(10人以上)，或日后软件升级的概率较大时，这个代价是值得的。

　　四、简洁的批量m:n设计
　　碰到m:n的关系，一般都是建立3个表，m一个，n一个，m:n一个。但是，m:n有时会遇到批量处理的情况，例如到图书馆借书，一般都是允许用户同时借阅n本书，如果要求按批查询借阅记录，即列出某个用户某次借阅的所有书籍，该如何设计呢？让我们建好必须的3个表先：

书籍表(Book_table)
名称　　　类型　　　　约束条件　　　说明
book_id int 无重复 书籍标识，主键
book_no char(20) 无重复 书籍编号
book_name char(100) 不允许为空 书籍名称
……

借阅用户表(Renter_table)
名称　　　　类型　　　　约束条件　　　说明
renter_id int 无重复 用户标识，主键
renter_name char(20) 不允许为空 用户姓名
……

借阅记录表(Rent_log)
名称　　　类型　　　　约束条件　　　说明
rent_id int 无重复 借阅记录标识，主键
r_id int 不允许为空 用户标识，和Renter_table.renter_id关联
b_id int 不允许为空 书籍标识，和Book_table.book_id关联
rent_date datetime 不允许为空 借阅时间
……

　　为了实现按批查询借阅记录，我们可以再建一个表来保存批量借阅的信息，例如：

批量借阅表(Batch_rent)
名称　　　类型　　　约束条件　　　说明
batch_id int 无重复 批量借阅标识，主键
batch_no int 不允许为空 批量借阅编号，同一批借阅的batch_no相同
rent_id int 不允许为空 借阅记录标识，和Rent_log.rent_id关联
batch_date datetime 不允许为空 批量借阅时间

　　这样的设计好吗？我们来看看为了列出某个用户某次借阅的所有书籍，需要如何查询？首先检索批量借阅表(Batch_rent)，把符合条件的的所有记录的rent_id字段的数据保存起来，再用这些数据作为查询条件带入到借阅记录表(Rent_log)中去查询。那么，有没有什么办法改进呢？下面给出一种简洁的批量设计方案，不需添加新表，只需修改一下借阅记录表(Rent_log)即可。修改后的记录表(Rent_log)如下：

借阅记录表(Rent_log)
名称　　　类型　　　约束条件　　　说明
rent_id int 无重复 借阅记录标识，主键
r_id int 不允许为空 用户标识，和Renter_table.renter_id关联
b_id int 不允许为空 书籍标识，和Book_table.book_id关联
batch_no int 不允许为空 批量借阅编号，同一批借阅的batch_no相同
rent_date datetime 不允许为空 借阅时间
……

　　其中，同一次借阅的batch_no和该批第一条入库的rent_id相同。举例：假设当前最大rent_id是64，接着某用户一次借阅了3本书，则批量插入的3条借阅记录的batch_no都是65。之后另外一个用户租了一套碟，再插入出租记录的rent_id是68。采用这种设计，查询批量借阅的信息时，只需使用一条标准T_SQL的嵌套查询即可。当然，这种设计不符合3NF，但是和上面标准的3NF设计比起来，哪一种更好呢？答案就不用我说了吧。

　　五、冗余数据的取舍
　　上篇的“树型关系的数据表”中保留了一个冗余字段，这里的例子更进一步——添加了一个冗余表。先看看例子：我原先所在的公司为了解决员工的工作餐，和附近的一家小餐馆联系，每天吃饭记账，费用按人数平摊，月底由公司现金结算，每个人每个月的工作餐费从工资中扣除。当然，每天吃饭的人员和人数都不是固定的，而且，由于每顿工作餐的所点的菜色不同，每顿的花费也不相同。例如，星期一中餐5人花费40元，晚餐2人花费20，星期二中餐6人花费36元，晚餐3人花费18元。为了方便计算每个人每个月的工作餐费，我写了一个简陋的就餐记账管理程序，数据库里有3个表：

员工表(Clerk_table)
名称　　　　类型　　　　约束条件　　　说明
clerk_id int 无重复 员工标识，主键
clerk_name char(10) 不允许为空 员工姓名

每餐总表(Eatdata1)
名称　　　 类型　　　　约束条件　　　说明
totle_id int 无重复 每餐总表标识，主键
persons char(100) 不允许为空 就餐员工的员工标识集合
eat_date datetime 不允许为空 就餐日期
eat_type char(1) 不允许为空 就餐类型，用来区分中、晚餐
totle_price money 不允许为空 每餐总花费
persons_num int 不允许为空 就餐人数

就餐计费细表(Eatdata2)
名称　　类型　　约束条件　　　说明
id int 无重复 就餐计费细表标识，主键
t_id int 不允许为空 每餐总表标识，和Eatdata1.totle_id关联
c_id int 不允许为空 员工标识标识，和Clerk_table.clerk_id关联
price money 不允许为空 每人每餐花费

　　其中，就餐计费细表(Eatdata2)的记录就是把每餐总表(Eatdata1)的一条记录按就餐员工平摊拆开，是个不折不扣的冗余表。当然，也可以把每餐总表(Eatdata1)的部分字段合并到就餐计费细表(Eatdata2)中，这样每餐总表(Eatdata1)就成了冗余表，不过这样所设计出来的就餐计费细表重复数据更多，相比来说还是上面的方案好些。但是，就是就餐计费细表(Eatdata2)这个冗余表，在做每月每人餐费统计的时候，大大简化了编程的复杂度，只用类似这么一条查询语句即可统计出每人每月的寄餐次数和餐费总帐：

SELECT clerk_name AS personname,COUNT(c_id) as eattimes,SUM(price) AS ptprice FROM Eatdata2 JOIN Clerk_tabsle ON (c_id=clerk_id) JOIN eatdata1 ON (totleid=tid) WHERE eat_date>=CONVERT(datetime,'"&the_date&"') AND eat_date

　　想象一下，如果不用这个冗余表，每次统计每人每月的餐费总帐时会多麻烦，程序效率也够呛。那么，到底什么时候可以增加一定的冗余数据呢？我认为有2个原则：

　　１、用户的整体需求。当用户更多的关注于，对数据库的规范记录按一定的算法进行处理后，再列出的数据。如果该算法可以直接利用后台数据库系统的内嵌函数来完成，此时可以适当的增加冗余字段，甚至冗余表来保存这些经过算法处理后的数据。要知道，对于大批量数据的查询，修改或删除，后台数据库系统的效率远远高于我们自己编写的代码。
　　２、简化开发的复杂度。现代软件开发，实现同样的功能，方法有很多。尽管不必要求程序员精通绝大部分的开发工具和平台，但是还是需要了解哪种方法搭配哪种开发工具的程序更简洁，效率更高一些。冗余数据的本质就是用空间换时间，尤其是目前硬件的发展远远高于软件，所以适当的冗余是可以接受的。不过我还是在最后再强调一下：不要过多的依赖平台和开发工具的特性来简化开发，这个度要是没把握好的话，后期维护升级会栽大跟头的。

1. 数据仓库工具箱（第二版）
2. 数据仓库生命周期工具箱
3. The Data Warehouse ETL Toolkit
4. Wiley.Mastering.Data.Warehouse.Aggregates.Solutions.for.Star.Schema.Performance.Jul.2006

看你想先用什么内容了。如果需要多维分析，可以先学习mondrian和jpiovt。如果需要报表，可以先学习jfreereport。pentaho的整体架构过于复杂，不要想一下子都掌握。

pentaho的demo其实是一个包含BI基础框架和演示例子的平台。xaction是构成业务流程的基本单位。Pentaho Design Stduio很重要，它是xaction的设计工具。它可以调用Kettle，Report Designer等工具的生成结果，来完成多维分析和报表的展示。另外，如果仅仅是做多维分析和报表并且对pentaho不了解，可以考虑只使用mondrian和jpivot，再加上其它的报表工具就可以了。

或者闲来无聊看看号称当前最尖端的科学 统一场论！——我也不知道是说啥的
http://en.wikipedia.org/wiki/Unified_Field_Theory

Pentaho合作伙伴商业问题FAQ Pentaho合作伙伴商业问题FAQ文档地址：http://www.pentaho.org/images/stories/pentahopartnerfaq.pdf

   数据仓库技术的实现方式

目前在数据仓库技术的实际应用中主要包括如下几种具体实现方式。
1、在关系数据库上建立数据仓库(ROLAP)

2、在多维数据库上建立数据仓库(MOLAP)

    MOLAP方案是以多维方式来组织数据，以多维方式来存储数据；ROLAP方案则以二维关系表为核心表达多维概念，通过将多维结构划分为两类表:维表和事实表，使关系型结构能较好地适应多维数据的表示和存储。在多维数据模型的表达方面，多维矩阵比关系表更清晰且占用的存储更少，而通过关系表间的连接来查询数据的ROLAP系统，系统性能成为最大问题。MOLAP方案比ROLAP方案要简明，索引及数据聚合可以自动进行并自动管理，但同时丧失了一定的灵活性。
    ROLAP方案的实现较为复杂，但灵活性较好，用户可以动态定义统计和计算方式，另外能保护在已有关系数据库上的投资。
    由于两种方案各有优劣，因此在实际应用中，往往将MOLAP和ROLAP结合使用，即所谓的混合模型。利用关系数据库存储历史数据、细节数据或非数值型数据，发挥关系数据库技术成熟的优势，减少花费，而在多维数据库中存储当前数据和常用统计数据，以提高操作性能。

3、在原有关系库上建立逻辑上的数据仓库
    由于目前正在运行的OLTP系统中已经积累了海量数据，如何从中提取出决策所需的有用信息就成为用户最迫切的需要。新建数据仓库固然能从功能、性能各方面给出一个完整的解决方案，但需要投入大量的人力、物力，并且数据仓库的建设和分析数据的积累需要一段时间，无法及时满足用户对信息分析的迫切需要。因此在筹建数据仓库的前期，可以采用一些合适的表现工具，在原有OLTP系统上建立起一个逻辑的数据仓库系统。尽管由于原有OLTP系统设计上的局限性，这样的系统可能无法实现很多分析功能，但这样一个系统中数据结构固定、信息分析需求相对稳定成熟，因此数据仓库的建模、实现过程会相对容易、便捷；同时，这样的系统也会成为将来真正数据仓库建设的原型。

信息系统与数据仓库的关系

    由于数据量大、数据来源多样化，在商业银行构建管理信息系统时，不可避免地会遇上如何管理这些浩如烟海的数据，以及如何从中提取有用的信息的问题；而数据仓库的最大优点在于它能把企业网络中不同信息岛上的商业数据集中到一起，存储在一个单一的集成的数据库中，并提供各种手段对数据进行统计、分析。因此可以说，在银行使用数据仓库构建管理信息系统，既有压力，又有数据基础，它们之间的联系是必然的，难以割舍的。
数据仓库在商业银行的应用范围包括存款分析、贷款分析、客户市场分析、相关金融业分析决策(证券、外汇买卖)、风险预测、效益分析等。

   在银行信息系统构建时，由于历史情况和现实需求的不同，存在两种途径:

1、建设新系统

   由于目前国内商业银行对银行内部运营的监管，缺乏很好的数据搜集机制，因此可以在构建管理信息系统时，分数据收集录入和数据汇总分析两部分来考虑。这样的系统中由于不需考虑大量历史数据的处理问题，同时考虑到搜集过程中可能存在多个数据来源，因此可以在系统建设的同时构建数据仓库，将搜集来的各种数据通过数据抽取整合到数据仓库中。

2、完善原有系统
  而对于已经存在OLTP系统，其中沉淀了大量历史数据，则可以先在原有系统上建立逻辑数据仓库，即使用数据分析的表现工具，在关系模型上构建一个虚拟的多维模型。当系统需求稳定后，再建立物理数据仓库，这样既节省投资，又缩短开发工期。

实现中需要注意的问题

一、模型设计中的问题

    模型设计(包括逻辑模型设计和物理模型设计)是系统的基础和成败的关键，在实际操作中，视实现技术的不同应分别对下列问题引起注意。

1、直接构建数据仓库

   直接构建数据仓库时，必须按业务分析的要求重组OLTP系统中的数据，并要按不同侧重点分别组织，使之便于使用。

*主题的确定

   主题是一个逻辑概念，它应该能够完整、统一地刻画出分析对象所涉及的各项数据以及相互联系。划分主题的根据主要来源于两方面:对原有固定报表的分析和对业务人员的访谈。原有固定报表能较好地反映出以往工作对数据分析的需求，而且数据含义和格式相对成熟、稳定，在模型设计中需要大量借鉴。但仅仅满足于替代目前的手工报表还远远不应是构建管理信息系统的目标，还应该通过业务访谈，进一步挖掘出日常工作中潜在的更广、更深的分析需求。只有这样，才能真正了解构建数据仓库模型所需的主题划分。

*分析内容的细化

   主题的划分实际上是与分析内容的范围直接相关的，一旦主题划分清楚了，下一步就是细化分析的具体内容以及根据分析内容的性质确定它在数据仓库中的位置。通常维元素对应的是分析角度，而度量对应的是分析关心的具体指标。一个指标究竟是作为维元素、度量还是维属性，取决于具体的业务需求，但从实际操作中可以总结出如下的概念性经验:作为维元素或维属性的通常是离散型的数据，只允许有限的取值；作为度量的是连续型数据，取值无限。如果一定要用连续型数据作为维元素，则必须对其按取值进行分段，以分段值作为实际的维元素。判断分析指标是作为维元素还是维属性时，则需要综合考虑这个指标占用的存储空间与相关查询的使用频度。
   需要特别强调的是，在细化分析内容的过程中，务必解决指标的歧义问题。在不同报表中以及在业务访谈中同一名称的指标，是否是在同样条件限定下，通过同样方法提取或计算得到的，它们之间的相互关系是什么，这些问题都必须从熟悉业务的分析人员那里得到准确、清晰的答案，否则将会影响到模型设计、数据提取、数据展现等多个方面。

*粒度的设计

   数据仓库模型中所存储的数据的粒度将对信息系统的多方面产生影响。事实表中以各种维度的什么层次作为最细粒度，将决定存储的数据能否满足信息分析的功能需求，而粒度的层次划分、以及聚合表中粒度的选择将直接影响查询的响应时间。
   如果同一个信息系统要在大范围、多层次上同时运行，如部门级和企业级，还应考虑不同层次的数据仓库采用不同的粒度。

*模型设计中的技巧

   复合指标尤其是比率类指标的定义，必须注意累加时是先加减后乘除，还是反之。户数、笔数的计算，这类指标在分析或报表中经常出现，但不需要作为单独的指标物理存在于数据库中，但定义分析模型时一定应该准备。度量的时间特性，针对分析指标在时间维上的不同表现，可分为可累加指标、半可累加指标和不可累加指标。

2、在原有数据基础上构建逻辑数据仓库

    如果直接使用OLTP系统中的数据进行数据分析处理，会遇到许多麻烦，有时甚至是不可能实现的。这并不是说关系数据库不好，而是因为其设计思路不适应较大规模数据分析。因此在使用这种方法时，需要注意下列问题的处理:

*不同的时间单位

    这是实现过程中最常遇到的问题，也往往是最难解决的问题。OLTP系统中存储的时间往往采用与实际业务发生相同的时间单位，如帐务数据单位为日期，财务报表单位为月或半年。而面向分析时，往往要将不同时间单位的数据统一到同一个结果中，这样就必须存在适当的转换机制才能实现。


*冗余信息

   所谓冗余信息，就是指不同关系表中存在的同一含义的字段，而同一含义不仅指这些字段的取得或计算方式一样，还指它们成立的条件一样，例如截止某一时间同一地区的同一贷种的贷款余额。在OLTP系统中，这样的字段往往是基于性能考虑而设计的，而在面向分析设计模型时，为了保证结果的唯一性和准确性，就必须用且只用其中之一的数据产生分析结果。

*表间连接

   由于OLTP系统中表的设计面向业务处理，既要保证数据的完整性、一致性，又要考虑响应时间，因此表与表之间既相对独立，又相互依赖。在设计数据仓库逻辑模型时，对表间的连接必须做出相应取舍，既要保证分析数据能通过连接取得或计算出，又要避免出现环路，造成分析数据的歧义。另外，不同的连接途径还会出现不同的查询速度，影响数据分析的响应性能。

*统计表的设计

  如果上述问题不能在原有数据库基础上得到很好的解决，那么权益之计就是构建统计表，即简单化的数据仓库，形式类似数据仓库的事实表，定时计算统计数据放入，将时间、冗余、连接等问题摈除，进行简单分析。

二、数据抽取中的问题

  数据抽取是一件技术含量不高，但非常烦琐的工作，必须有专人负责数据抽取的工作。在对其进行设计时，要注意的问题有:

1、数据抽取的规则要作为元数据进行规范和管理，抽取过程中的源表、源字段、目的表、目的字段、转换规则以及转换条件都要作好详细记录。这样不仅便于编程人员实现，而且在抽取规则或逻辑模型发生变化时也便于修改。

2、如何记录业务数据库中的变动情况是数据抽取中一个重要的环节。由于数据仓库中按时间保存数据，因此不同时间点之间数据的差异就成为一个关键性因素。通常可以利用数据库管理系统提供的手段在数据库级产生数据变动日志，根据日志再判断数据的变动情况完成抽取，这样是一个从性能、可操作性以及对原业务系统的影响等多方面综合考虑都比较理想的方法。

3、当数据仓库中同一表中的数据来自于原有系统中不同的表，甚至不同的库时，抽取时务必保证这些数据单位一致，而且都满足同一时间条件。

4、数据抽取不仅要考虑数据的提取，还要考虑抽取的时间安排和执行方式，这样才是一个完整的数据抽取方案，也才能保证抽取出来的数据准确、可用。


三、后期维护、优化中的问题


数据仓库的建设是一个长期工作，它同其他系统一样需要在运行的过程中不断进行调整、完善。这其中包括两方面的工作:

1、性能
   数据仓库涉及海量数据的查询，数据的大量写入读出，不仅对数据库系统的要求很高，而且与OLTP系统的要求极为不同，因此在系统设计、实施和维护的过程中，数据仓库系统的性能都是一个不可忽视的问题。尤其是在运行期间，要密切关注应用对系统资源的消耗情况，针对应用的特点及时对系统进行调整，包括调整数据库参数、数据分片放置、创建特殊索引乃至提高系统配置等。

2、模型
   应用与需求是相互促进、不断发展的，随着信息系统建成运行，用户在对系统了解不断加深的过程中，也会对系统提出更新更高的要求。如何在最小投入的前提下满足用户的需求，也是一个值得注意和潜心研究的问题。首先要尽可能挖掘现有系统的潜力，其次考虑，对主题的增加或可在现有系统上增加少量指标就可解决的需求，对系统进行适当调整，最后才考虑对系统进行重构，尽可能减小系统建设中的投入。

数据仓库应用的深化


   按照上述方法实现的应用中，主要完成了报表的生成和日常业务的分析，这并不能给企业带来真正的效益，也远远没有发挥出数据仓库的应用价值。随着应用的深入，可以由企业的技术人员与业务人员紧密配合，规划出对企业有实际价值的应用模型，并根据实际业务的发展不断调整模型自身的参数，以期找出企业运作过程中的规律，即在数据仓库上进行数据挖掘，构建DSS系统，这样才能充分体现构建数据仓库的意义，从而最终为企业带来效益。

   尽管数据仓库技术还需要不断发展、完善，但只要企业能认识到信息分析的重要性，业务人员和技术人员能真正配合起来，相信不久的将来会有更多的实用成果出现。

　　在事务处理系统中的数据，主要用于记录和查询业务情况。随着数据仓库（DW）技术的不断成熟，企业的数据逐渐变成了决策的主要依据。数据仓库是一种面向决策主题、由多数据源集成、拥有当前及历史总结数据、以读为主的数据库系统，其目的是支持决策。数据仓库要根据决策的需要收集来自企业内外的有关数据，并加以适当的组织处理，使其能有效地为决策过程提供信息。数据仓库中的数据是从许多业务处理系统中抽取、转换而来，对于这样一个复杂的企业数据环境，如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。元数据是关于数据、操纵数据的进程和应用程序的结构和意义的描述信息，其主要目标是提供数据资源的全面指南。元数据不仅定义了数据仓库中数据的模式、来源以及抽取和转换规则等，而且整个数据仓库系统的运行都是基于元数据的，是元数据把数据仓库系统中的各个松散的组件联系起来，组成了一个有机的整体。

　　一、元数据
　　1、元数据的概念
　　按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。
　　技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息：
　　数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；
　　业务系统、数据仓库和数据集市的体系结构和模式；
　　汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告；
　　由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。

　　业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的信息；具体包括以下信息：
　　企业概念模型：这是业务元数据所应提供的重要的信息，它表示企业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数。
　　多维数据模型：这是企业概念模型的重要组成部分，它告诉业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式。
　　业务概念模型和物理数据之间的依赖：以上提到的业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。

　　2、元数据的作用
　　在数据仓库系统中，元数据机制主要支持以下五类系统管理功能：（１）描述哪些数据在数据仓库中；（２）定义要进入数据仓库中的数据和从数据仓库中产生的数据；（３）记录根据业务事件发生而随之进行的数据抽取工作时间安排；（４）记录并检测系统数据一致性的要求和执行情况；（５）衡量数据质量。
　　与其说数据仓库是软件开发项目，还不如说是系统集成项目，因为它的主要工作是把所需的数据仓库工具集成在一起，完成数据的抽取、转换和加载，OLAP分析和数据挖掘等。它的典型结构由操作环境层、数据仓库层和业务层等组成。
　　其中，第一层（操作环境层）是指整个企业内有关业务的OLTP系统和一些外部数据源；第二层是通过把第一层的相关数据抽取到一个中心区而组成的数据仓库层；第三层是为了完成对业务数据的分析而由各种工具组成的业务层。图中左边的部分是元数据管理，它起到了承上启下的作用，具体体现在以下几个方面：
　　便于集成
　　提高系统的灵活性
　　保证数据的质量
　　帮助用户理解数据的意义

　　二、数据仓库元数据管理现状
　　元数据管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递，协调各模块和工具之间的工作。
　　由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。当前市场上与元数据相关的数据仓库工具大致可分为四类：
　　1. 数据抽取工具：把业务系统中的数据抽取、转换、集成到数据仓库中，如Ardent的DataStage、CA（原Platinum）的Decision Base和ETI的Extract等。这些工具仅提供了技术元数据，几乎没有提供对业务元数据的支持。
　　2. 前端展现工具：包括OLAP分析、报表和商业智能工具等，如MicroStrategy的DSS Agent、Cognos的PowerPlay、Business Objects的BO，以及Brio等。它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图，进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。
　　3. 建模工具：为非技术人员准备的业务建模工具，这些工具可以提供更高层的与特定业务相关的语义。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。
　　4. 元数据存储工具：元数据通常存储在专用的数据库中，该数据库就如同一个“黑盒子”，外部无法知道这些工具所用到和产生的元数据是如何存储的。还有一类被称为元数据知识库（Metadata Repository）的工具，它们独立于其它工具，为元数据提供一个集中的存储空间。包括微软的Repository，CA的Repository，Ardent的MetaStage和Sybase的WCC等。

　　三、元数据管理的标准化
　　没有规矩不成方圆。元数据管理之所以困难，一个很重要的原因就是缺乏统一的标准。在这种情况下，各公司的元数据管理解决方案各不相同。近几年，随着元数据联盟MDC（Meta Data Coalition）的开放信息模型OIM（Open Information Model）和OMG组织的公共仓库模型CWM（Common Warehouse Model）标准的逐渐完善，以及MDC和OMG组织的合并，为数据仓库厂商提供了统一的标准，从而为元数据管理铺平了道路。
　　从元数据的发展历史不难看出，元数据管理主要有两种方法：
　　(1) 对于相对简单的环境，按照通用的元数据管理标准建立一个集中式的元数据知识库。
　　(2) 对于比较复杂的环境，分别建立各部分的元数据管理系统，形成分布式元数据知识库，然后，通过建立标准的元数据交换格式，实现元数据的集成管理。
　　下面我们分别介绍数据仓库领域中两个最主要的元数据标准：MDC的OIM标准和OMG的CWM标准。
　　1、MDC的OIM存储模型
　　MDC成立于1995年，是一个致力于建立与厂商无关的、不依赖于具体技术的企业元数据管理标准的非赢利技术联盟，该联盟有150多个会员，其中包括微软和IBM等著名软件厂商。1999年7月MDC接受了微软的建议，将OIM作为元数据标准。
　　OIM的目的是通过公共的元数据信息来支持不同工具和系统之间数据的共享和重用。它涉及了信息系统（从设计到发布）的各个阶段，通过对元数据类型的标准描述来达到工具和知识库之间的数据共享。OIM所声明的元数据类型都采用统一建模语言UML（Universal Modeling Language）进行描述，并被组织成易于使用、易于扩展的多个主题范围（Subject Areas），这些主题范围包括：
　　分析与设计（Analysis and Design）：主要用于软件分析、设计和建模。该主题范围又进一步划分为：UML包（Package）、UML扩展包、通用元素（Generic Elements）包、公共数据类型（Common Data Types）包和实体关系建模（Entity Relationship Modeling）包等。
　　对象与组件（Object and Component）：涉及面向对象开发技术的方方面面。该主题范围只包含组件描述建模（Component Description Modeling）包。
　　数据库与数据仓库（Database and Warehousing）：为数据库模式管理、复用和建立数据仓库提供元数据概念支持。该主题范围进一步划分为：关系数据库模式（Relational Database Schema）包、OLAP模式（OLAP Schema）包、数据转换（Data Transformations）包、面向记录的数据库模式（Record-Oriented Database Schema）包、XML模式（XML Schema）包和报表定义（Report Definitions）包等。
　　业务工程（Business Engineering）：为企业运作提供一个蓝图。该主题范围进一步划分为：业务目标（Business Goal）包、组织元素（Organizational Elements）包、业务规则（Business Rules）包、商业流程（Business Processes）包等。
　　知识管理（Knowledge Management）：涉及企业的信息结构。该主题范围进一步划分为：知识描述（Knowledge Descriptions）包和语义定义（Semantic Definitions）包。
上述主题范围中的包都是采用UML定义的，可以说UML语言是整个OIM标准的基础。虽然OIM标准并不是专门针对数据仓库的，但数据仓库是它的主要应用领域之一。目前市场上基于该标准的元数据管理工具已经比较成熟，例如微软的Repositry和CA的Repositry均采用了OIM标准。

　　2、OMG组织的CWM模型
　　OMG是一个拥有500多会员的国际标准化组织，著名的CORBA标准即出自该组织。公共仓库元模型（Common Warehouse Metamodel）的主要目的是在异构环境下，帮助不同的数据仓库工具、平台和元数据知识库进行元数据交换。2001年3月，OMG颁布了CWM 1.0标准。CWM模型既包括元数据存储，也包括元数据交换，它是基于以下三个工业标准制定的：
　　(1) UML：它对CWM模型进行建模。
　　(2) MOF（元对象设施）：它是OMG元模型和元数据的存储标准，提供在异构环境下对元数据知识库的访问接口。
　　(3) XMI（XML元数据交换）：它可以使元数据以XML文件流的方式进行交换。
　　
　　CWM为数据仓库和商业智能（BI）工具之间共享元数据，制定了一整套关于语法和语义的规范。它主要包含以下四个方面的规范：
　　(1) CWM元模型（Metamodel）：描述数据仓库系统的模型；
　　(2) CWM XML：CWM元模型的XML表示；
　　(3) CWM DTD：DW/BI共享元数据的交换格式
　　(4) CWM IDL：DW/BI共享元数据的应用程序访问接口（API）
　　下面重点讨论CWM元模型的组成，它与OIM规范一样，也是由很多包组成的。组成CWM元模型的包结构如图4所示。
　　(1) 元模型（MetaModel）包：构造和描述其它CWM包中的元模型类的基础。它是UML的一个子集，由以下四个子包组成：
　　a) 核心（Core）包：它的类和关联是该模型的核心，其它所有的包都以它为基础。
　　b) 行为（Behavioral）包：包括描述CWM对象行为的类与关联，并且它为描述所定义的行为提供了基础。
　　c) 关系（Relationships）包：包括描述CWM对象之间关系的类与关联。
　　d) 实例（Instance）包：包括表示CWM分类器（Classfier）的类与关联。　　
　　(2) 基础包（Foundation）：它包括表示CWM概念和结构的模型元素，这些模型元素又可被其他CWM包所共享，它由以下六个子包组成：
　　a) 业务信息（Business Information）包：包括表示模型元素业务信息的类与关联。
　　b) 数据类型（Data Types）包：包括表示建模者可以用来创建所需数据类型的结构的类与关联。
　　c) 表达式（Expressions）包：包括表示表达式树的类与关联。
　　d) 关键字和索引（Keys and Indexes）包：包括表示键和索引的类与关联。
　　e) 软件发布（Software Deployment）包：包括软件如何在数据仓库中发布的类与关联。
　　f) 类型映射（Type Mapping）包：包括表示不同系统之间数据类型映射的类与关联。
　　(3) 资源包（Resource）：用于描述数据资源的包，它包括以下四个子包：
　　a) 关系（Relational）包：包括表示关系型数据资源的元数据的类与关联。
　　b) 记录（Record）包：包括表示记录型数据资源的元数据的类与关联。
　　c) 多维（Multidimensional）包：包括表示多维数据资源的元数据的类与关联。
　　d) XML包：包括表示XML数据资源的元数据的类与关联。
　　(4) 分析（Analysis）包：它由以下五个子包组成：
　　a) 转换（Transformation）包：包括表示数据抽取和转换工具的元数据的类与关联。
　　b) OLAP包：包括表示OLAP工具的元数据的类与关联。
　　c) 数据挖掘（Data Mining）包：包括表示数据挖掘工具的元数据的类与关联。
　　d) 信息可视化（Information Visualization）包：包括表示信息可视化工具的元数据的类与关联。
　　e) 业务术语（Business Nomenclature）包：包括表示分类业务的元数据的类与关联。
　　(5) 管理（Management）包：用于描述数据仓库管理的包，它包括以下两个子包：
　　a) 仓库过程（Warehouse Process）包：包括表示仓库过程的元数据的类与关联。
　　b) 仓库操作（Warehouse Operation）包：包括表示仓库操作结果的元数据的类与关联。
　　在数据抽取过程中，数据从各个业务系统中被统一转换存储到中央数据仓库中。CWM中的转换模型定义了数据在源和目的之间移动的过程，其中不仅包括源和目标之间的参数，还包括转换中的业务逻辑。这些业务逻辑可能包括一些商业规则、类库甚至是用户脚本。数据仓库如果有一个规范的转换模型将给工具软件厂商和专业服务提供商带来极大的好处，例如，按照统一的规范厂商可以设计一个通用的模型从标准ERP包中抽取数据。工具厂商甚至可以随软件提供成熟的模型，集成商也可以将一个模型应用到多个项目中。
　　最终用户同样也能从CWM中受益，在使用商业智能分析软件进行多维分析的时候，用户往往会对数据的含义和来源产生疑问。CWM能够提供这些信息，用户可以清楚地看到数据来自哪个系统，并且是如何组成的。

　　3、CWM与OIM之间的关系
　　上两节分别介绍了与数据仓库相关的两个主要标准，CWM实际上是专门为数据仓库元数据而制定的一套标准，而OIM并不是针对数据仓库元数据的。OIM所关注的元数据的范围比CWM要广，CWM只限定于数据仓库领域，而OIM模型包括有：分析与设计模型、对象与组件、数据库与数据仓库、商业工程、知识管理等五个领域。OIM与CWM在建模语言的选择（都选择UML当做自己的描述语言）、数据库模型的支持、OLAP分析模型的支持、数据转换模型的支持方面都比较一致；但是OIM并不是基于元对象设施（MOF）的，这意味着用OIM所描述的元数据需要通过其它的接口才能访问，而CWM所描述的元数据可以通过CORBA IDL来访问；在数据交换方面，OIM必须通过特定的转换形成XML文件来交换元数据，而CWM可以用XMI来进行交换。尽管如此，由于OMG与MDC两个组织的合并，CWM也会与OIM相互兼容以保护厂商已有的投资。
　　需要说明的是，MDC与OMG组织已经合并，今后所有的工具都将遵循统一的CWM标准，不过支持CWM的工具才刚刚出现，而支持OIM标准的工具已经相对成熟。

　　四、元数据管理系统的设计与实现
　　1、设计原则
　　数据仓库环境下的元数据管理系统的建设是十分困难的。但是在实际项目的实施过程中，这个环节又是非常重要的。当前情况下，OMG组织的CWM标准将会成为数据仓库元数据领域事实上的标准，在元数据管理系统的建立过程中应尽量参考这个标准，这样使系统的可扩展性增强。可是在与之相关的工具成熟之前，我们完全可以采用OIM中的元模型（因CWM对OIM是兼容的）以及支持它的元数据管理工具进行元数据管理系统的建设，而且元数据所包含的范围很广。我们在建立元数据管理系统的时候，绝对不能盲目追求大而全，要坚持目标驱动的原则，在实施的时候要采取增量式、渐进式的建设原则。具体的建设步骤如下：
　　（1） 如果是在建设数据仓库系统的初期，那么首先要确定系统的边界范围，系统范围确定的原则是首先保障重点，不求大，只求精。
　　（2） 系统边界确定以后，把现有系统的元数据整理出来，加入语义层的对应。然后存到一个数据库中，这个数据库可以采用专用的元数据知识库，也可以采用一般的关系型数据库。
　　（3） 确定元数据管理的范围。比如，我们只想通过元数据来管理数据仓库中数据的转换过程，以及有关数据的抽取路线，以使数据仓库开发和使用人员明白仓库中数据的整个历史过程。
　　（4） 确定元数据管理的工具，采用一定的工具可以完成相应的工作。当前相关工具有微软的Repositry，它带有相应的编程接口，可以借助于它来完成元模型出入库的功能；与之相似的还有Platinum的OEE；另外还有Sybase的Wcc，它可以通过MDC以前的一个老标准――MDIS来集成抽取工具与转换工具，在一个窗口中就可以表示数据抽取与转换，并且可以把语义层以MDIS的格式导出到一个前端工具当中（比如Cognos的Improptu）。

　　2、元数据存储模式
　　元数据存在的状况是有差异的，系统层元数据应随数据库存在，且由建立在分布式网络数据库管理系统统一管理；数据集层次元数据可以随数据库存在也可随数据集存在；数据特征层次的元数据只能随数据集存在。
　　简单地，元数据存贮有两种形式：其一是以数据集为基础，即每一个数据集有一个对应的元数据文档，每一个元数据文件中包含对相应数据集的元数据内容。另一种存在方式是以数据库为基础（即元数据库），给一个数据库有一个元数据文件，该文件为一表格数据，它由若干项组成，每一项表示元数据的一个要素，其记录为每一个数据集的元数据内容。
　　两种存贮方式各有优缺点，对于第一种存储模式，其好处是调用数据时其相应的元数据也作为一个独立的文件被传输，相对数据库有较强的独立性，在对元数据进行检索时可以利用数据库的功能实现，也可以将元数据文件调到其它数据库系统中进行操作；其问题是：每一数据集都有一个元数据文档，那么在规模巨大的数据库中则会有大量的元数据文件，管理上极为不便。在第二中存在模式中，由于库中只有一个元数据文件，管理极为方便，添加或删除数据集只把该文件中添加或删除相应的记录项即可；但如果想获取某数据集的元数据时，实际得到的只是关系表格数据的一个记录，则要求数据用户使用的系统中可以接受这种特定形式的数据。因此推荐使用元数据库的方式。
　　元数据库是用于存储元数据的地方，元数据库最好选用主流的关系数据库管理系统，支持CWM标准。一个元数据库还包含那些用于操作和查询元数据的机制；建立元数据库的主要好处是提供了统一的关键数据结构和业务规则，易于将企业内部的多个数据集市有机的结合起来；特别是，现在一些客户倾向建立多个数据集市，而不是一个庞大无比的数据仓库。可以考虑在建立数据仓库（或数据集市）之前，先建立一个用于描述数据的、用于应用集成的元数据库，做好数据仓库实施的初期支持工作，对后续开发和维护有很大的帮助。在拥有不同厂商、不同功能和不同元数据库的环境下，要实现两种产品之间的元数据同步是非常富有挑战性的工作。因为必须从一种产品中获得足够详细的元数据，将其映射到另一种产品中，再指出两者意义或编码的差别；通常系统有数百、数千个元数据，必须对每个元数据重复这一过程。
　　在整个数据仓库环境中，元数据管理工具可以从各个数据仓库组件中收集元数据，存储到元数据库中，然后向业务用户传递和展示正确的信息。采集、集成和描述元数据可以扩展到十分广泛的范围，可以在设计和建模的过程中，可以在数据转换、清洗和过滤的过程中，也可以在数据移植的过程中；可以从数据库/数据存储软件，和前端展示工具中得到元数据。
　　元数据库为整个企业的宝贵信息提供了详细的记录，保存数据存储位置和商业含义、生成和维护数据的主体、数据驱动的应用处理、与其它数据的关系以及数据的转换过程等。元数据库保证了数据仓库数据的一致性和准确性，为企业进行数据质量管理提供数据依据。
另外，元数据库还支持强大的查询和报表生成工具，用户使用报表工具可以查询元数据库，从元数据库获得重要的决策支持信息。

　　3、元数据管理模式
　　元数据管理涉及到各个层次的元数据，管理的内容包括元数据的获取、元数据的更新、使用和面向应用项目的元数据使用处理等多个方面。元数据的管理涉及数据库、数据处理软件、数据使用系统、面向应用的数据分析等各个环节。下面给出了一种普通意义的以元数据信息系统为基础的元数据管理模式。
　　通常意义上的元数据管理是指元数据通过各种途径形成后，对其内容的添加、删除、更新等涉及内容改变的操作和元数据内容检索、查询、放置、组织等常规性元数据操作，从这种意义上元数据的管理可以通过两种方式实现，即系统管理模式和用户管理模式。系统管理模式是面向数据库的，由数据库管理系统专业人员完成，数据用户只有使用权，没有元数据的操作权，数据应用项目中新生成的数据集的元数据也有应用系统传递给数据库管理员，然后由数据库管理员统一管理。这种方式中，数据在处理过程中形成的动态元数据很难及时记录下来。另一种管理方式是用户管理模式，它是面向应用项目的，即允许某些数据用户在数据应用元数据的变动信息直接反馈给元数据库，这样则能保证元数据的动态更新和新生成数据集元数据的及时捕获及写入元数据文件。但这种模式中数据用户的权限要适当的控制，以避免数据库的破坏。通常对元数据的管理是采用两者结合的模式。
　　总之，建立元数据管理系统一定要坚持关注标准，又不被标准所束缚的原则，建立符合自身目标的元数据管理系统。