ORACLE数据仓库建设

《ORACLE数据仓库建设》由会员分享，可在线阅读，更多相关《ORACLE数据仓库建设（53页珍藏版）》请在装配图网上搜索。

1、摘 要自20世纪90 年代以来,计算机技术发展迅猛,各通信商逐步开发出新的BI系统。实现给通信领域提出了充分利用数据仓库技术，将现有的海量数据构造成为可用、可控、可扩展的数据组织,以适应通信领域各级主管和业务人员的分析需要。在本论文中从数据仓库需求分析包括参与成员、各个成员所起到的作用；逻辑模型建设通过软件设计，确定表之间的关系；物理模型建设中对表和过程进行详细的审核，用来支持所提出的需求；数据仓库设计以ODS、DWD、DWA为层次，采用横向分层纵向分域的理念，进行具体的实施建立，并在后期提供了错误的应急措施、数据仓库的维护和优化。关键词： 数据仓库，物理模型，维护和优化English abs

2、tractSince the nineteen ninties, computer technology is developing rapidly, the communication business gradually developed a new BI system. Reality to communication field is presented for fully using data warehouse technology to existing data structures become available, controllable, scalable data

3、organization, to adapt to the field of communication at all levels of managers and business analysis.In this paper from the data warehouse requirement analysis includes the participation of members, each member of the role played by; logic model construction through software design, to determine the

4、 relationship between tables; physical model construction process table and detailed audit, used to support the proposed requirement; data warehouse design with ODS, DWD, DWA levels, the horizontally stratified longitudinal domain concept, specific implementation of the establishment, and in late st

5、age provides error emergency measures, data warehouse maintenance and optimization.Keywords： data warehouse, physical model, maintenance and optimization目录第一章 数据仓库概述11.1 本论文采用数据仓库的目的11.2 数据仓库的定义和特点11.3 数据仓库与数据库21.5 元数据31.5.1 技术元数据31.5.2 业务元数据31.5.3 元数据的作用41.6 数据仓库发展方向51.6.1 数据仓库的产生和发展51.6.2 数据仓库发展趋势

6、71.6.3 数据集市、集市群行业的发展方向81.6.4 基于Internet2、光处理器计算机和GGG技术的DW111.7建设数据仓库的必要性14第二章 数据仓库需求分析152.1 需求分析原因152.2 需求分析阶段152.2.1 需求分析成员确立162.2.2 需求会议18第三章 数据仓库总体设计193.1 数据仓库实施环境193.2 确定数据仓库开发的生命周期193.3 通讯数据仓库设计原则253.4 确定数据仓库系统的结构及各部分的主要功能26第四章 数据仓库详细设计314.1 逻辑模型设计314.2 物理模型设计32第五章 数据仓库实现345.1 ODS层建设345.1.1 接口数

7、据抽取345.1.2 数据抽取策略355.1.3 ODS层的作用365.2 DWD层建设365.2.1 DWD定义365.2.2 实体选取的原则365.2.3 字段选取的原则375.2.4 数据转换375.2.5 数据加载技术及策略385.3 DWA汇总层建设395.4 DWA衍生层建设40第六章 数据仓库后期运维426.1 数据仓库测试42 6.1.1 分析源文件426.1.2 开发策略和测试计划426.1.3 测试的开发与执行436.2 数据仓库后期维护436.2.1 数据仓库数据清理436.2.2 数据仓库模型更改446.3 数据仓库性能优化446.3.1 调整数据库服务器的性能446.

8、3.2 调整内存分配446.3.3 使用ORACLE的数据完整性约束456.3.4 使用数据库触发器456.3.5 使用存储过程466.3.6 应用程序调整46总结47致谢48参考文献49第一章 数据仓库概述1.1 本论文采用数据仓库的目的当前,通信行业(以联通为例)内部已经积累了大量的业务处理数据,但是这些数据分布在各级机构、各个部门中,而且数据的操作平台各异,有DOS 的、有Windows 的、有Unix 的、有Solaris 的;数据的来源复杂,有存储在硬盘上的,也有存储在磁带、光盘上的;数据的文件格式多样,有各种不同数据库的,也有文本文件型的,还有多媒体文件型的。这些数据是通信行业决策

9、的宝贵信息资源,在构造新的系统时必须要善加利用。数据仓库技术为解决充分有效的利用超大容量、多平台数据资源这个问题提供了方法和手段,能够充分利用现有的海量数据资源,并从中找出对通信的运作和决策有价值的信息。1.2 数据仓库的定义和特点数据仓库是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。（1） 数据仓库是面向主题的操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关

10、。（2） 数据仓库是集成的数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库。（3） 数据仓库是不可更新的数据仓库主要是为决策分析提供数据，所涉及的操作主要是数据的查询。（4） 数据仓库是随时间而变化的传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。（5） 汇总的操作性数据映射成决策可用的格式。（6） 大容量时间序列数据集合通常都非常大。（7） 非规范化的DW数据可以是而且经常是冗余的。（8） 元数据将描述数据的数据保存起来。（9） 数据源数据来自内部

11、的和外部的非集成操作系统。 1.3 数据仓库与数据库数据库已经在信息技术领域有了广泛的应用，我们社会生活的各个部门，几乎都有各种各样的数据库保存着与我们的生活息息相关的各种数据。作为数据库的一个分支，数据仓库概念的提出，相对于数据库从时间上就近得多。美国著名信息工程专家William博士在90年代初提出了数据仓库概念的一个表述，认为：“一个数据仓库通常是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，它用于对管理决策过程的支持。”这里的主题，是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不

12、是像业务支撑系统那样是按照业务功能进行组织的。集成，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。 随时间变化，是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。二者的联系：数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。 二者的区别： （1） 出发点不同数据库是面向事务的设计，数据仓库是面向主题设计的。

13、 （2） 存储的数据不同数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 （3） 设计规则不同数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。（4） 提供的功能不同数据库是为捕获数据而设计，数据仓库是为分析数据而设计。（5） 基本元素不同数据库的基本元素是事实表，数据仓库的基本元素是维度表。（6） 容量不同数据库在基本容量上要比数据仓库小的多。（7） 服务对象不同数据库是为了高效的事务处理而设计的，服务对象为企业业务处理方面的工作人员，数据仓库是为了分析数据进行决策而设计的，服务对象为企业高层决策人员。1.5 元数据元数据

14、（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（TechnicalMetadata）和业务元数据（BusinessMetadata）。1.5.1 技术元数据技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式。l 汇总用的算法，包括度量和维

15、定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告。l 由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。1.5.2 业务元数据业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层。业务元数据主要包括以下：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的；具体包括以下：l (1)企业概念模型这是业务元数据所应提供的重要的，它表示企业数据模型的高层、整个企业的业务概念和相互关系。(2) 多维数据模型这是企业

16、概念模型的重要组成部分，确定业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式。l (3)业务概念模型和物理数据之间的依赖业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。1.5.3 元数据的作用u 描述哪些数据在数据仓库中。u 定义要进入数据仓库中的数据和从数据仓库中产生的数据。u 记录根据业务事件发生而随之进行的数据抽取工作时间安排。u 记录并检测系统数据一致性的要求和执行情况。u 衡量数据质量。 元数据

17、管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递，协调各模块和工具之间的工作。 我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。与元数据相关的数据仓库工具大致可分为四类： (1)数据抽取工具把业务系统中的数据抽取、转换、集成到数据仓库中，如Ardent的DataStage、CA（原P

18、latinum）的DecisionBase和ETI的Extract等。这些工具仅提供了技术元数据，几乎没有提供对业务元数据的支持。(2) 前端展现工具包括OLAP分析、报表和商业智能工具等，如MicroStrategy的DSSAgent、Cognos的PowerPlay、BusinessObjects的BO，以及Brio等。它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图，进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。 (3)建模工具为非技术人员准备的业务建模工具，这些工具可以提供更高层的与特定业务相关的语义。如CA的ERwin、Sy

19、sbase的PowerDesigner以及Rational的Rose等。 (4)元工具元数据通常存储在专用的数据库中，该数据库就如同一个“黑盒子”，外部无法知道这些工具所用到和产生的元数据是如何存储的。还有一类被称为元数据知识库（MetadataRepository）的工具，它们独立于其它工具，为元数据提供一个集中的存储空间。包括微软的Repository，CA的Repository，Ardent的MetaStage和的WCC等。1.6 数据仓库发展方向1.6.1 数据仓库的产生和发展现在基于业务数据的决策分析联机分析处理（OLAP），比以往任何时候都显得更为重要。如果说传统联机事务处理（OL

20、TP）强调的是更新数据库向数据库中添加信息，那么OLAP就是从数据库中获取信息、利用信息。事实上，将大量的业务数据应用于分析和统计原本是一个非常简单和自然的想法。但在实际的操作中，人们却发现要获得有用的信息并非如想象的那么容易：第一，所有OLTP强调的是密集的数据更新处理性能和系统的可靠性，并不关心数据查询的方便与快捷。联机分析和事务处理对系统的要求不同，同一个数据库在理论上都难以做到两全。第二，业务数据往往被存放于分散的异构环境中，不易统一查询访问，而且还有大量的历史数据处于脱机状态，形同虚设。第三，业务数据的模式针对事务处理系统而设计，数据的格式和描述方式并不适合非计算机专业人员进行业务上

21、的分析和统计。可以这么说，以前查询不到信息是因为数据太少了，而今天查询不到则是因为数据太多了。针对这一问题，人们设想专门为业务的统计分析建立一个数据中心，它的数据从OLTP系统中来、从外部数据源来、从历史业务数据中来这个数据中心是一个联机的系统，它是专门为分析统计和决策支持应用服务的，通过它可满足决策支持和联机分析应用所要求的一切。这个数据中心就叫做数据仓库。数据仓库就是一个作为决策支持系统和联机分析应用数据源的结构化数据环境。数据仓库所要研究和解决的问题就是从数据库中获取信息的问题。与关系数据库不同，数据仓库并没有严格的数学理论基础，它更偏向于工程。由于数据仓库的这种工程性，因而在技术上可以

22、根据它的工作过程分为：数据的抽取、存储和管理、数据的表现以及数据仓库设计的技术咨询四个方面。（1）数据的抽取数据仓库是一个独立的数据环境，它需要通过抽取过程将数据从联机事务处理系统、外部数据源、脱机的数据存储介质中导入数据仓库。数据抽取可以定时进行，但多个抽取操作执行的时间、相互的顺序、成败对数据仓库中信息的有效性则至关重要。（2）存储和管理数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库的特性，同时也决定了其对外部数据表现形式。要决定采用什么产品和技术来建立数据仓库核心，则需要从数据仓库的技术特点着手分析。u 如何完成对大量数据的存储和管理u 并行处理能力

23、u 针对决策支持查询的优化u 支持多维分析的查询模式，这也是关系数据库在数据仓库领域遇到的最严峻的挑战之一。（3）数据的表现数据表现是数据仓库的门面。这里说的主要是多维分析、数理统计和数据挖掘方面。（4）数据仓库设计的技术咨询数据仓库绝不是简单的产品堆砌，它是一个综合性的解决方案和系统工程。在数据仓库的实施过程中，技术咨询服务至关重要，是一个不可缺少的部分，它甚至于比购买产品更为重要。就目前的发展来看，建立数据仓库有两个基本条件：建立数据仓库的行业有较为成熟的OLTP系统，它为数据仓库提供客观条件；行业面临市场竞争的压力，它为数据仓库的建立提供外在的动力。另外建立大型数据仓库，成本也是较高的，

24、所以对企业的经济实力也是个考验。所以数据仓库的概念一经出现，就首先被应用于金融、电信、保险等行业。1.6.2 数据仓库发展趋势(1)数据仓库规模不断增长所有企业的数据仓库规模都将呈指数增长，数据源的增长以及企业对数据更好的获取能力推动了这种增长。另外存储成本也越来越便宜，因此企业能够保存更长期的数据。但数据增长也将使企业面临一些新问题，包括数据仓库的可升级性以及可能出现的性能问题。(2)数据集市的整合(3)客户数据集成许多企业如今很想跨越产品线、业务单位、渠道和地理各方面来综合地得到一个关于客户的单一视图，一种称之为客户数据集成（CDI）的解决方案应声而出，其核心部分由数据仓库和相关技术构成。

25、客户数据集成提供了对客户数据360的全方位视图，并使企业可以从任何一个接触点上对客户进行认识和做出反应。(4)开发商的整合由于企业都想得到完备的产品套件，数据仓库和商务智能开发商因此将越来越多的功能融合到他们的产品中去。(5)EAI和ETL工具的集成(6)快速反应的决策支持电子商务的不断增长驱使着企业去寻找共享数据和对机会快速反应的方法，虽然真正的实时决策支持基本是不可能的，但数据仓库技术的进步却使快速反应的决策支持得以实现。在数分钟或数秒钟内对数据进行分析和对事件做出反应的能力有助于企业在各方面的行动，比如供应链管理、客户服务和商务性能管理等。(7)非结构化信息的增长企业正面临着非结构化和半

26、结构化数据的增长，包括图像、声音、视频、XML以及其它的数据类型。同时，相关的技术也在不断出现，使企业可以采用跟以前处理传统的结构化数据资源的方式，来存储和挖掘这些数据。(8)越来越了解如何对“成功或失败”问题做出正确分析知识管理在企业仓促着手建立数据仓库或其它分析型知识库时，数据质量或元数据这些重要问题经常被忽视，其后果就是，很多企业现今发现他们的行动成功性打了不少折扣，因为他们不能确定“成功或失败”问题。数据质量问题和元数据的缺乏会严重影响用户对数据仓库的接受程度，也只能得到可怜的分析结果和不正确的决策。这是一个相当复杂的问题，需要花费时间和精力去确定他们。(9)强调应用程序VS数据仓库对

27、大多企业来说，数据仓库不再是单独的一件事。需要确定投资回报率。数据仓库项目跟以前一样是必需的，但可能会尽量跟应用程序联系起来以便于计算投资回报率和调整项目成本。(10)越来越注重盈亏问题艰难的经济环境迫使企业除了收入增长外，还得认真考虑收益率问题。这种不断增加的对盈亏问题的注意力影响到了IT项目，其中包括数据仓库，最终导致各级水平上的成本削减。新的数据仓库项目仍将不断进行，但是企业不会再妄想一步登天去做那些对盈利没有直接影响的事；它们还想有一个明确的商业案例，明确的投资回报率和更短的回报周期。1.6.3 数据集市、集市群行业的发展方向在数据仓库产品方面，微软是以其关系数据库SQL Server

28、作为它数据仓库核心的。微软的OLAP走的是ROLAP的路子，与其数据转换一样，属于常规的解决方案；而并行处理和决策支持扩展则不是SQL Server的强项。因此，整个解决方案仍面向中低端，价格取胜是关键。为此，微软在数据仓库市场中倡导了另一个概念数据集市(Data Mart)。所谓数据集市就是一个面向部门应用的、小型的数据仓库；所采用的技术与数据仓库相似，但存储的内容更加专题化。对于数据集市这样的规模，微软的解决方案便可成为理想的选择。虽然微软是无数IT人士“憎恨”的对象，但我们不得不承认，它在市场定位方面的工作一直很成功。其所坚持的走大众化、平民化道路的理念，从操作系统中的windows，办

29、公软件里得Office到数据库领域的SQL Sever等等,无一不是成功的案例。在这次数据仓库的较量中，微软又打起了数据集市的大旗。就目前情况而言，能够建立大型数据仓库的企业毕竟还局限于有雄厚实力的大型公司。而占市场相当比重的中小企业，一方面难以接受建立数据仓库高昂的成本，另一方面使用大型数据仓库来解决他们少量的工作也显得有些浪费。而此时数据集市则成了他们不错的选择。表1-1 数据集市与数据仓库的区别数据仓库数据集市数据来源OLTP、遗留系统、外部数据数据仓库范围企业级部门级、工作组级主题企业主题部门或专项主题数据粒度最细粒度较粗粒度数据结构3NTF星型、雪片型历史数据大量历史数据适度历史数据

30、优化处理海量数据、数据探索便于访问分析、快速查询索引高度索引高度索引数据集市可以分为两种类型:独立型数据集市和从属型数据集市。独立型数据集市直接从操作型环境获取数据，从属型数据集市从企业级数据仓库获取数据。作为快速解决企业当前存在的实际问题的一种有效方法，独立型数据集市成为一种既成事实。独立型数据集市是为满足特定用户的需求而建立的一种分析型环境，它能够快速地解决某些具体的问题，而且投资规模也比数据仓库小很多。但独立数据集市也存在一些问题：u 冗余数据。随着独立数据集市数量的增长，数据冗余量也不断增长，这种冗余是由于每个独立数据集市都有一个整体数据的备份而引起的，但这些数据中有不少通常并不是必需

31、的。u 冗余流程。数据仓库的体系结构可以对所有数据集市的共同活动进行集中化，没有数据仓库，这些流程就必须为每个数据集市进行复制，这将大大增加维护DSS所需的员工数量。u 较低的可伸缩性。独立数据集市直接读取运作系统的文件或表，这极大限制了DSS的伸缩能力。u 非集成。独立数据集市是由自成体系的团队建立的，而且一般是为不同的部门建立的，导致这些数据集市没有进行集成，而且没有一个会包含了整个企业的视图。因此，如果CEO让信息部门提供一个获利能力最强的客户列表，那么从每个数据集市分析到的答案都将是不同的。独立型数据集市的存在会给人造成一种错觉，似乎可以先独立地构建数据集市，当数据集市达到一定的规模再

32、直接转换为数据仓库。实际上多个独立的数据集市的累积，是不能形成一个企业级的数据仓库的。如果企业最终想建设一个全企业统一的数据仓库，想要以整个企业的视图分析数据，独立型数据集市恐怕不是合适的选择。现在的业内人士普遍认为，从属型数据集市在体系结构上比独立型数据集市更稳定，可以作为数据集市未来建设的主要方向。从属型数据集市不过是在数据仓库与最终用户之间又增加了一套汇集、优化系统。这样的设计也许对提高整个系统的反应速度方面有一定帮助，但却削弱了数据集市相当重要的一项优势廉价。其成本甚至超过了单一数据仓库系统，不利于此类技术的大众化、平民化发展。另一种比较理想的方式是，企业先就其最急需的领域建立独立型数

33、据集市，而后随着需求的变化、实力的增强逐步建立更多的数据集市。这些数据集市之间保持一种高度的统一与协调机制，构成一个完整的群体，我把它称作数据集市群。数据集市群的优势主要表现在以下几方面：(1) 成本低廉初始成本为初始数据集市的成本加上集市群控制器的成本。虽然比只有几个数据集市的成本高，但与数据仓库相比还是便宜很多。而且其投入产出比也更容易预测。(2) 冗余度低由于加入了集市群控制器，各数据集市中的数据被统一调度，统一规划。从而消除了数据集市件容易发生的数据冗余、不一致等问题。(3) 后期维护容易当集市群因某种需求而要加入新的数据集市时，所要考虑的问题仅是新的模块需要那些数据，原有集市群能提供

34、那些数据。根据这两点去设计新的数据集市，而不必对原有集市群做什么调整。(4)数据集市群策划和设计数据集市群的建立需要前期的精心策划、设计和标准化的接口设计。只有解决好这些问题，才能保证以后新建的集市能够与原来的群顺利实现对接及整体效果最佳。目前看来这还是一项相当复杂的工程，但其一旦实现，给数据仓库行业带来的震动将是难以想象的。信息源数据集市信息源数据仓库数据集市数据集市信息源数据集市数据集市控制器图1-1 独立型数据集市图1-2 从属型数据集市图1-3 数据集市群1.6.4 基于Internet2、光处理器计算机和GGG技术的DW(1)Internet21996年由一些大学和高科技公司组成的联

35、盟开发的，旨在提供超高速的连接速度，该项目的目标是领先于商用互联网3-4年的时间。目前的Internet2已经是第三代了，今年早些时候，其骨干网的数据传输速率已经升级为10Gbps。目前大部分的公共互联网使用2.5Gbps，一些运营商正在将它们的连接升级至10Gbps。P2P应用、高清晰视频会议、实验室设备的远程操作、分布式计算等应用都可以在Internet2上运行。目前，由于受带宽的限制，这些应用的大规模部署还很缓慢，而Internet2则能够满足这些应用对带宽的需求。通过Internet2进行的音乐会转播每秒钟能够发送250GB的数据，这比标准的拨号连接要快4000倍，比有线电视连接要快8

36、00倍。研究人员仍然在研究如何进一步提高Internet2的效率和速度的问题。研究人员还在开发新的中间件技术，使通过网络的协作更无缝更安全。在目前的互联网上，应用程序本身必须提供中间件所提供的识别、授权、安全等服务。通过语言标准化和兼容性，中间件将大大提高先进网络应用的易用性。在过去的15年中，互联网的速度每年都会翻一番。研究人员相信，这种每年增长100%的趋势在未来还会持续下去。Internet2的研究人员已经在研究新一代的超高速网络。速度为10Gbps的Abilene网络的平均运行速度为1Gbps-2Gbps。另外在高等教育领域，用户对带宽的需求的增长将呈几何级数增长，因此新应用的需求将超

37、过目前的公共IP网络的带宽也是很自然的。(2)未来高性能计算机按照摩尔定律，每过18个月，微处理器硅芯片上晶体管的数量就会翻一番。随着大规模集成电路工艺的发展，芯片的集成度越来越高，也越来越接近工艺甚至物理的上限，最终，晶体管会变得只有几个分子那样小。以摩尔速度发展的微处理器使全世界的微电子技术专家面临着新的挑战。尽管传统的、基于集成电路的计算机短期内还不会退出历史舞台，但旨在超越它的超导计算机、纳米计算机、光计算机、DNA计算机和量子计算机正在跃跃欲试。与传统硅芯片计算机不同，光计算机用光束代替电子进行运算和存储：它以不同波长的光代表不同的数据，以大量的透镜、棱镜和反射镜将数据从一个芯片传送

38、到另一个芯片。 从上个世纪80年代起，光子计算机就成为新一代计算机的发展方向。2003年10月底，全球首枚嵌入光核心的商用向量光学数字处理器由以色列一公司研发的Enlight在美国波士顿军事通信展览会上露面，引起了业界莫大的关注。因为，它的出现预示着计算机将进入光学时代。以光速进行计算，运行速度达到每秒8万亿次这相当于一台超级计算机的运算能力。但超级计算机动辄采用上千个处理器同时工作，才能实现这样的运算速度。以去年问世的“地球模拟器”为例，这台号称全球运算速度最快的超级计算机峰值运算速度为35.86万亿次，而这个速度是由它的5120个处理器共同创造出来的。由于Enlight强大的性能，能够被广

39、泛运用在大型多媒体广播系统、机场安全检查系统和医学数据库系统等方面。比如在移动通信领域，采用Enlight进行多用户检测，即通过重复计算一系列方程式，能解除同一基站内用户间的相互干扰。一枚单独的Enlight就可以同时支持2000个用户，并避免相互干扰。而在生物科技方面，Enlight强大的运算能力，可以大大缩短生物技术运算必需的基因数据配对和基因与多基体配对过程。“光子运算具有巨大的潜力，能够做常规计算无法办到的事。”德国达姆施塔特大学的科尔内利娅登茨博士长期致力于光计算研究。她表示，采用光学技术不但可以极大地提升计算机的运算速度，而且可以让计算机系统模拟人脑的思维活动，并且比人脑的处理速度

40、快上数千倍，从而实现真正的人工智能。科学家的预测不是没有依据的。到2015年，硅芯片的运算速度和微型化发展都将止步不前。而与此同时，网络和其他行业发展带来的海量数据运算需要和更快的传输需求，将迫使人们不得不寻求革命性的变革。(3)网格技术网格计算因为在结构上酷似电力网络而得名。在九十年代中期，网格作为一种共享计算的方法被正式提出，并首先在科研领域应用。后来，为了降低成本，很多企业也打算利用闲置的资源，网格开始逐步进入商业市场，并由此为许多产业带来了新的机遇。网格技术是一种趋势，这是毋庸置疑的。就像计算机最初是大型主机，发展到更加通用的小型机，现在则又有了更多的选择。这其中有成本的原因，有硬件技

41、术的发展，也说明大家都在期待一个更加开放的平台。网格技术正是这种趋势发展的一个必然。尽管网格的发展还面临很大的困难，有业内人士说，“网格的处境就好像10年前的Internet和3年前的Linux一样，正在从技术计算进入商业计算。”但是，曾经价格高昂的网格计算已经进入各个组织机构及跨国公司，广泛应用到金融和工程仿真，医学研究和石油勘探领域，发挥着巨大的作用：汽车制造商们正实施更多的模拟程序以使汽车更安全；娱乐公司更细致地描绘数字人像以求逼真的效果对企业来说，网格无疑是极具价值的工具，未来几年，将会有更多的网格进入市场。为了在未来的发展潮流中占据有利的战略地位，世界各国都纷纷加紧了网格研究的步伐。

42、 一些发达国家和跨国公司已为此投下了巨资。在具体实施中，IBM全球服务部和其业务合作伙伴一起，共同提供各种与网格有关的服务，包括一个网格创新工作室(用于帮助企业在其业务中实施网格)以及专业化的行业专用课程。在产品方面，IBM eServer产品线也形成了一个可以用来设计和开发网格解决方案、甚至管理整个网格的坚实平台；其 DB2产品和工具也支持网格计算解决方案，使得能快速、方便地建设复杂的数据基础设施。(4)数据仓库、联机系统的发展根据长久以来的经验，计算机的软硬件发展一直是互相促进、互为动力的。以上所述的未来高性能计算机、Internet2、网格技术等等已经为我们勾勒出了一幅美好的画面。更强大

43、的计算工作站、惊人的信息传输速度、更优化的网络协调机制，这些无疑都给未来软件业的发展带来了更广阔的施展空间。就如同现在的PC机使用的内存，比10年前硬盘的存储容量还大一样。许许多多现在认为不可能实现或相当复杂的工作，对那时的计算机系统来说不过是小儿科而以。到那时对一个包含5千万条记录的DW作一次完整分析，也仅仅需要几秒钟的时间。所以我们有理由相信在新一代的应用系统中，数据仓库将在一开始便被纳入系统设计的考虑，联机分析会应用于普遍的事务处理系统之中。在数据管理上，联机事务处理和数据仓库在应用中相对独立，使联机事务处理系统本身更加简洁高效，同时分析统计也更为便利。面向行业的数理统计学向更为普遍的应

44、用发展，并集成到应用系统的数据仓库解决方案中。它们将立足于数据仓库提供的丰富信息，更好地为业务决策服务。1.7建设数据仓库的必要性企业建立数据仓库是为了填补现有数据存储形式已经不能满足信息分析的需要。数据仓库理论中的一个核心理念就是：事务型数据和决策支持型数据的处理性能不同。企业在它们的事务操作收集数据。在企业运作过程中：随着定单、销售记录的进行，这些事务型数据也连续的产生。为了引入数据，我们必须优化事务型数据库。处理决策支持型数据时，一些问题经常会被提出：哪类客户会购买哪类产品？促销后销售额会变化多少？等，事务型数据库可以为这些问题作出解答，但是它所给出的答案往往并不能让人十分满意。在运用有

45、限的计算机资源时常常存在着竞争。在增加新信息的时候我们需要事务型数据库是空闲的。而在解答一系列具体的有关信息分析的问题的时候，系统处理新数据的有效性又会被大大降低。另一个问题就在于事务型数据总是在动态的变化之中的。决策支持型处理需要相对稳定的数据，从而问题都能得到一致连续的解答。 数据仓库的解决方法包括：将决策支持型数据处理从事务型数据处理中分离出来。数据按照一定的周期（通常在每晚或者每周末），从事务型数据库中导入决策支持型数据库既“数据仓库”。数据仓库是按回答企业某方面的问题来分“主题”组织数据的，这是最有效的数据组织方式。第二章 数据仓库需求分析2.1 需求分析原因需求分析的成败直接影响到

46、数据仓库的成败实施。对于一个严格完整的数据仓库项目来说，需求分析应该属于数据仓库项目的第二个过程，第一阶段属于数据仓库项目定义阶段，对项目范围、项目评估、可行性研究分析和投资回报等相关进行定义，也是一个不容忽视的阶段。首先数据仓库失败的典型表现形式： 图2-1 数据仓库失败图示（1）项目超过预算（2）没有在规定的时间内完成（3）没有实现要求的功能（4）用户不满意（5）系统性能不满足要求2.2 需求分析阶段在进入需求分析的初级阶段时必须要先确立数据仓库项目组人员（其中包括公司接口规范人员、接口人员、数据开发人员、ETL调度人员、稽核人员、页面展现人员等），对局方联通进行接洽商讨等相关工作。2.2

47、.1 需求分析成员确立（1） 接口规范人员：用来确定当前经分能否支撑局方提出的需求，经过商讨，判定当前拥有的接口是否满足需要，或是重新确定新的接口，来支撑项目的实施。如图，例如对联通融合业务进行商讨，判断接口是否可以实施。图2-2 接口规范制定流程（2） 接口人员：负责承接省分上传的数据，进行初步的稽核，确认是否需要迟传、通报等，并通过ETL调度，调起节点。判断ETL能否成功调起，所承受的负载最大值等。图2-3 接口入库流程（3）数据库开发人员：进行项目的开发和实施，通过与局方商议，根据需求预计项目实施周期。通过Powerdesigner、PL/SQL等工具，进行设计开发。（4）ETL调度人员

48、：在开发人员脚本成功开发后，由ETL统一并行调度，保证及时触发节点，并实时监控。图2-4 ETL调度实例（5）稽核人员：实时的对数据进行详细的稽核校验，确保数据无误，能够及时准确的上传至页面。尤其是对重要字段进行反复校验，及时通过邮件反馈。（6）页面展现人员：当稽核人员确定数据无误时，由页面展现人员进行页面展现，供局方人员使用，确保数据的实时准确。有些情况下还会有项目协调和会议记录等人员参加。2.2.2 需求会议在做需求分析之前，一般需要对局方进行接口的确定，以保证总部和省分以统一的接口进行上传和接收，并通过接口规范来得到双方的确认，会议的目的就是公司与局方在各个方面达成一致，启发局方提出更贴

49、近数据仓库的需求，具体想要得到哪些数据，渴望得到哪些结果。需求会议一方面是为了消除局方在进行需求确认时的数据仓库的盲区，更重要的一方面是让局方知道建设数据仓库开发的过程和困难，还有一方面就是能够得到局方配合来完成项目及时准确的实施。第三章 数据仓库总体设计3.1 数据仓库实施环境数据库以ORACLE为基础，POWERDESIGNER进行数据模型的确定加工，PL/SQL DEVELOPER软件进行具体的过程开发。3.2 确定数据仓库开发的生命周期由于数据仓库最佳结合了业务惯例和信息系统技术，因此，一个成功的数据仓库实施需要这两方面的不断协调，以均衡其所有的需要，要求，任务和成果。数据仓库项目有3

50、个轨道(tracks)：数据轨道，技术轨道和应用层轨道。当在整理任何数据库项目计划时，建议以这三个轨道为模板来管理和同步活动。数据库生命周期管理方法(Discover, Design, Develop, Deploy, Day to Day , Defend, Decommission), 昵称“7D法”。数据仓库的构建从来不会真正结束。不像传统的数据库在部署后的一段时间里保持相对的不变，数据仓库始终处于不断的变化之中，以应对它所服务的业务环境的变化。当今的业务环境更加复杂，并涉及比以往任何时候都要快的变化。处理这种几乎是不断的变化是企业的最大挑战之一。这就是为什么数据仓库团队中的每一个人，包

51、括技术决策者( TDMs ) 和业务决策者( BDMs )，都必须处在同一阵线上，使用同一种生命周期管理方法，以使他们的认识完全得到统一。只有这样，才有可能对已实施的数据仓库、企业的构想和宗旨进行调整。(1)发掘任何规模和领域的数据库项目离开了开始的发掘阶段都将失败。这个阶段也被称为“需求分析和定义”， 发掘阶段需要以业务为中心，特别是数据仓库项目，因为数据仓库的输出需要支持组织的目标。发掘这一步实质上就是调查，应该不断地问六个基本问题(什么，如何，在何处，谁，何时和为什么)，记录好答案，并把这些答案包含在您起草的解决方案中。在“7步”的前3步(发掘，设计，开发)中，必须对业务主和技术专家进行

52、集中的协调，项目经理(PM)应该促成这一进程。项目经理作为一个独立的专业人员，主要关心项目的及时上线、预算在控制范围内，有预期的运行效果;项目经理在得到各方的反馈意见后，负责制定严格的路线，里程碑和成功指标。如果项目里没有PM,这些将成为您的工作。在发掘阶段，PM必须收集三个轨道的信息，即技术轨道，数据轨道和应用层轨道。在其他任务中，PM必须确定利益相关者和用户，必须理解他们各自的角色和相应的数据/视图 需求。PM必须知道本组织的绩效管理策略：目标是什么，倡议什么以及跟踪业务和项目健康状况的支撑度量标准/关键绩效指标。如果上述策略的任何部分遗漏了，该项目很有可能失去最终用户的评分，这可能会导致

53、低的采用通过率和未来资金的丢失。换句话说，该项目将失败，而不管项目任务执行得有多么完美。(2) 设计设计这一步的主要活动是定义描述数据仓库的语义和概要模型。这些模型必须解决企业用户的管理信息系统(MISs)和商务智能( BI )分析需要。对于数据仓库项目，可以为关系型数据仓库创建概念和逻辑数据模型，为表示多维立方体创建三维模型。可以使用决策矩阵，以帮助确定每个三维模型需要包含些什么;沿Y轴方向列出被数据仓库支持的关键业务流程，沿X轴方向列出建议的维。这个矩阵将作为当前开发、未来扩展和跨组织集成的向导。在设计阶段建立的模型必须反映第一阶段收集的六个问题的答案。标识数据仓库相关的所有数据源(内部和

54、外部的)，业务/交易数据库和展平文件是个好注意。同时应该明确说明哪些数据将被导入数据仓库，哪些只会简单地作为外部数据源引用。通常，技术轨道有自己的PM，但仍然可能需要填补那个角色。数据仓库可以增长为非常大的内容和十分广泛的范围，因此有必要在数据仓库部署之前恰当地规划其大小。首先在纸上估计其大小，这样您就可以大致把握当数据仓库投入产品应用时所需的处理器速度和磁盘容量。同时需要估算一天的业务终端用户数量以及他们使用的应用(例如，对立方体做一个特别分析，或者从关系数据仓库中取出缓存的报告)，也要估算数据仓库一年中将会存储的数据量。只是因为数据仓库是一个进展中的工作，可能会需要两年和五年预测，同样，其

55、处理能力和数据存储需求将随着时间的推移不断增加。数据仓库设施包括各种硬件，通信和软件解决方案，所有这一切都必须协同工作，为终端用户提供一个工作的数据仓库。这样需要足够的时间来计划和测试将如何整合所有这些不同的组成部分。跟技术轨道一样，应用轨道可能有自己的PM或由一个主导的软件开发人员充当这一角色。如果你的工作是与此人协调以同步任务。如果不是，那工作描述会扩大。应用层包括获取从数据仓库收集到的输出，通常是MIS报告和BI分析结果。MIS报告常是屏幕显示，仪表板，和打印副本的形式，它们帮助企业管理者做出运行日常业务所需的战术决策。这些输出相对比较容易界定、编码和被一系列标准化的进程抓取，这些进程运

56、行在可预定环境中。应用层的BI部分是一组查询和响应，以帮助执行管理作出战略决策，推动商务运营。BI解决方案往往是非结构化的，很难预定义，因为他们倾向于用一种特别的方式探索数据。记分牌，图形和数据透视表是BI的应用例子，它们能刺激更多的数据探索，而这可能导致公司内部战略方向的改变。在这个阶段许多方法要求原型或试点项目。“7D法”不需要。至多，作为应用层的设计活动中的一部分，可以做一个“点击模式”-一种输入/输出屏幕的快速呈现模型，不涉及或只有极少的代码但却能给利益攸关方可视化的概念，同时又不会吃掉宝贵的时间和资源。如果试点或原型是必要的，那么选择其中的一个切片(slice)作为试点，完成“7D法

57、”的每一步。“7D法”不区分试点，原型和产品系统-它们都被视为项目。如果按照“7D法”设计了一个原型，并且最终进入了产品(大多数原型都是这样)，然后要选择比第一个切片更仔细地选择第二个切片。如果这些切片不能成功地集成在一起，如果他们不支持我们在发掘步骤发现的企业宗旨和意图，那么整合彼此只会遇到困难，在某些情况下，甚至根本不可能。(3) 开发数据轨道开发步骤主要有两个部分：第一个涉及将数据模型映射到其对应的物理设计(实质是关系数据仓库和OLAP立方体的蓝图)，规划数据库的大小，必要时对表进行分块，为数据仓库对象设定命名约定以便业务用户和技术用户都能适应，并制定索引和识别索引候选名单的策略。图3-

58、1 通过POWERDESIGNER工具建表第二部分涉及数据从外部数据源到数据仓库的提取转换加载(ETL)。包含在第二部分但不局限于这一部分的是数据转换服务( DTS )/SQL Server整合服务( SSIS)补丁的开发与测试，导入/导出和T-SQL脚本开发和测试，以及对外部数据源组件的数据整合测试，这些数据不会导入到数据仓库。图3-2 ETL监控流程技术轨道的开发步骤包括审查，测试和选择产品，并提供其作品的体系结构设计。为了组成通信链路的各个层-物理层、数据链路层、网络层以及传输层，会话和表现层，这样做是必需的。虽然许多产品把多层无缝打包到一个解决方案，但有必要认识到这些层中的每一个在未来

59、的负载要求和性能要求，并提前为这些需求作好准备。为了从新的数据仓库交付数据，应该选定数据仓库的服务器和存储解决方案，以及新的，最终用户面临的硬件。这样做是为了产品数据仓库和分期数据库-DTS/SSIS软件包和T-SQL脚本在这里执行，从外部数据源导入数据，以及把可操作和精心料理的数据导入到关系数据仓库和OLAP立方体中。根据发掘阶段收集到的需求，数据仓库环境可能还要支持数据集市，快照，和报告数据库，因此，也要准备为这些方面考虑环境。应用轨道开发步骤听起来很简单：只要开发终端用户应用程序。然而，这可能是整个过程中最复杂和费时的任务，并且可能是代价最高的-如果没有认真制定和考虑成功的量度标准。正是

60、在这一阶段，范围蠕变(不断增加特性和功能，而不考虑对其他两个轨道的设计和开发的影响)可能像鱼雷一样破坏项目。除了开发终端用户应用程序，不得不制定测试这些应用程序的计划，我们需要制定终端用户培训计划以便用户能学会如何使用这些应用软件。在每一个里程碑，必须确保获得相关各方的签字或验收。(4) 部署部署数据仓库和部署交易数据库是不一样的，通常，可以用一种快速、包罗万象的风格部署一个交易数据库，而数据仓库通常是递增式地部署到整个企业的各类用户中。这种递增的速度和各个组使用数据仓库的次序是包含在部署阶段中部署计划的一部分。理想的情况下，数据仓库的部署以一种迅速级联的层次进行，首先是技术就位-服务器，存储

61、设备，通信链接等，系统软件的安装，测试并准备投入产品。然后是数据轨道各组件的展开-数据仓库数据库(关系型和OLAP )的建立，以及ETL进程的联机。在最终的应用层添加之前往往会打住一下，当通过ETL进程让数据流从外部来源进入各种不同的数据仓库数据库和立方体时，进行必要的测试和调整。然后应用层被部署。您可能想要逐渐地部署应用层，因为企业内部的不同人员有不同的等级。作为一个PM则发挥着非常重要的作用。在准确的指导和引导下，三个轨道将按预定计划到达部署阶段，避免数周数月的“误点”忧虑。一旦技术和数据轨道就绪并测试，并准备继续，那么开始展开应用层。没有用户界面( UI)的数据仓库对任何人都是没用的，而

62、一个尺寸不足，弱工程系统架构的数据仓库会因性能太差而不会被企业用户采用。(5)日常管理日常业务运营的管理是非常重要的;而这常常在规划和开发过程中被忽视。不仅必须确保定期(每日，每周等)进行维护，包括硬件和软件，还必须要不断监视所有系统的性能和增长。数据仓库永远不会结束;随着越来越多的用户发现数据的内在价值，并创造新的，有时甚至是具有挑战性的方式来查询数据仓库，它会继续增长和扩大。有时必须准备承担，包括确保所有的系统(硬件，通信链路，系统软件)的全面运作，打最新的补丁和升级。当业务瓶颈出现时尽可能快地诊断和解决问题; 确保所有需要做备份的系统及时备份，实际上，有备份工作定义和计划，并要求所有的备

63、份恢复测试，后续测试，开发，或报告数据库。业务不是静止的，它们必须不断地改造自己，以保持竞争力。数据仓库数据管理员的职责就是跟踪数据的使用，评估数据的重要性，并检测业务什么时候开始需要转变。随着业务模式的变化，将会需要更新，更好，更灵活，可能更复杂的用户应用程序，数据管理员应该能感知到这些要求。有时，当业务方向和重点变化到了一定的程度，就需要重新进入发掘阶段，生命周期将回到原点。洗涤，漂洗，重复下去。(6)防护保护数据仓库涉及的不仅仅是采取定期备份或确保没有任何应用程序包括SQL查询可能会开放给SQL注入式攻击。我们必须计划整个范围和宽度的监控保护，因为数据仓库包含了企业最宝贵的资产-它的数据，以一种经过编译的，清理过的，以及(在某些情况下)信息化了的格式存在。数据仓库的威胁通常分为两类，物理的和逻辑的。物理方面的威胁可以是外部的(龙卷风，洪水，火灾，地震)或内部(有意的，偶然的)。防止来自物理方面威胁的做法既可以是采用简单的限制访问计算机和通信室，也可以如位于地理上相距甚远的容错站点上的镜像服务器般复杂(且