自20世纪90 年代以来,运算机技术进展迅猛,各通信商逐步开发出新的BI系统。实现给通信领域提出了充分利用数据仓库技术，将现有的海量数据构造成为可用、可控、可扩展的数据组织,以适应通信领域各级主管和业务人员的分析需要。
在本论文中从数据仓库需求分析包括参与成员、各个成员所起到的作用；逻辑模型建设通过软件设计，确定表之间的关系；物理模型建设中对表和过程进行详细的审核，用来支持所提出的需求；数据仓库设计以ODS、DWD、DWA为层次，采纳横向分层纵向分域的理念，进行具体的实施建立，并在后期提供了错误的应急措施、数据仓库的爱护和优化。
关键词： 数据仓库，物理模型，爱护和优化
English abstract
Since 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 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 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 stage provides error emergency measures, data warehouse maintenance and optimization.
Keywords： data warehouse, physical model, maintenance and optimization
名目
第一章 数据仓库概述 .............................................................................................................. 0 1.1 本论文采纳数据仓库的目的 ......................................................................................... 0 1.2 数据仓库的定义和特点 ................................................................................................. 0 1.3 数据仓库与数据库 ......................................................................................................... 1 1.5 元数据 ............................................................................................................................. 2 1.5.1 技术元数据 .............................................................................................................. 2 1.5.2 业务元数据 .............................................................................................................. 2 1.5.3 元数据的作用 .......................................................................................................... 3 1.6 数据仓库进展方向 ......................................................................................................... 4 1.6.1 数据仓库的产生和进展 .......................................................................................... 4 1.6.2 数据仓库进展趋势 .................................................................................................. 6 1.6.3 数据集市、集市群—行业的进展方向 .................................................................. 7 1.6.4 基于Internet2、光处理器运算机和GGG技术的DW ....................................... 10 1.7建设数据仓库的必要性 ................................................................................................ 13 第二章 数据仓库需求分析 .................................................................................................... 14 2.1 需求分析缘故 ............................................................................................................... 14 2.2 需求分析时期 ............................................................................................................... 14 2.2.1 需求分析成员确立 ................................................................................................ 15 2.2.2 需求会议 ................................................................................................................ 17 第三章 数据仓库总体设计 .................................................................................................... 18 3.1 数据仓库实施环境 ....................................................................................................... 18 3.2 确定数据仓库开发的生命周期 ................................................................................... 18 3.3 通讯数据仓库设计原则 ............................................................................................... 24 3.4 确定数据仓库系统的结构及各部分的要紧功能 ....................................................... 25 第四章 数据仓库详细设计 .................................................................................................... 30 4.1 逻辑模型设计 ............................................................................................................... 30 4.2 物理模型设计 ............................................................................................................... 31 第五章 数据仓库实现 ............................................................................................................ 33 5.1 ODS层建设 .................................................................................................................... 33
5.1.1 接口数据抽取 ........................................................................................................ 33 5.1.2 数据抽取策略 ........................................................................................................ 34 5.1.3 ODS层的作用 ......................................................................................................... 35 5.2 DWD层建设................................................................................................................ 35 5.2.1 DWD定义 ................................................................................................................ 35 5.2.2 实体选取的原则 .................................................................................................... 35 5.2.3 字段选取的原则 .................................................................................................... 36 5.2.4 数据转换 ................................................................................................................ 36 5.2.5 数据加载技术及策略 ............................................................................................ 37 5.3 DWA汇总层建设 ........................................................................................................... 38 5.4 DWA衍生层建设 ........................................................................................................... 39 第六章 数据仓库后期运维 .................................................................................................... 41 6.1 数据仓库测试 ............................................................................................................... 41 6.1.1 分析源文件 ............................................................................................................ 41 6.1.2 开发策略和测试打算 ............................................................................................ 41 6.1.3 测试的开发与执行 ................................................................................................ 42 6.2 数据仓库后期爱护 ....................................................................................................... 42 6.2.1 数据仓库数据清理 ................................................................................................ 42 6.2.2 数据仓库模型更换 ................................................................................................ 43 6.3 数据仓库性能优化 ....................................................................................................... 43 6.3.1 调整数据库服务器的性能 .................................................................................... 43 6.3.2 调整内存分配 ........................................................................................................ 43 6.3.3 使用ORACLE的数据完整性约束 ......................................................................... 44 6.3.4 使用数据库触发器 ................................................................................................ 44 6.3.5 使用储备过程 ........................................................................................................ 45 6.3.6 应用程序调整 ........................................................................................................ 45 总结 .......................................................................................................................................... 46 致谢 .......................................................................................................................................... 47 参考文献 .................................................................................................................................. 48
第一章 数据仓库概述
1.1 本论文采纳数据仓库的目的
当前,通信行业(以联通为例)内部差不多积存了大量的业务处理数据,然而这些数据分布在各级机构、各个部门中,而且数据的操作平台各异,有DOS 的、有Windows 的、有Unix 的、有Solaris 的;数据的来源复杂,有储备在硬盘上的,也有储备在磁带、光盘上的;数据的文件格式多样,有各种不同数据库的,也有文本文件型的,还有多媒体文件型的。这些数据是通信行业决策的宝贵信息资源,在构造新的系统时必须要善加利用。数据仓库技术为解决充分有效的利用超大容量、多平台数据资源那个问题提供了方法和手段,能够充分利用现有的海量数据资源,并从中找出对通信的运作和决策有价值的信息。
1.2 数据仓库的定义和特点
数据仓库是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中猎取信息的问题。数据仓库的特点在于面向主题、集成性、稳固性和时变性。
（1）数据仓库是面向主题的
操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关怀的重点方面，一个主题通常与多个操作型信息系统相关。
（2）数据仓库是集成的
数据仓库的数据有来自于分散的操作型数据，将所需数据从原先的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库。
（3）数据仓库是不可更新的
数据仓库要紧是为决策分析提供数据，所涉及的操作要紧是数据的查询。 （4）数据仓库是随时刻而变化的
传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳固的数据以只读格式储存，且不随时刻改变。
（5）汇总的
操作性数据映射成决策可用的格式。
（6）大容量
时刻序列数据集合通常都专门大。 （7）非规范化的
DW数据能够是而且经常是冗余的。 （8）元数据
将描述数据的数据储存起来。 （9）数据源
数据来自内部的和外部的非集成操作系统。
1.3 数据仓库与数据库
数据库差不多在信息技术领域有了广泛的应用，我们社会生活的各个部门，几乎都有各种各样的数据库储存着与我们的生活息息相关的各种数据。作为数据库的一个分支，数据仓库概念的提出，相关于数据库从时刻上就近得多。美国闻名信息工程专家William博士在90年代初提出了数据仓库概念的一个表述，认为：“一个数据仓库通常是一个面向主题的、集成的、随时刻变化的、但信息本身相对稳固的数据集合，它用于对治理决策过程的支持。”那个地点的主题，是指用户使用数据仓库进行决策时所关怀的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。
集成，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是通过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。
随时刻变化，是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个时期的信息。通过这些信息，能够对企业的进展历程和以后趋势做出定量分析和推测。
二者的联系：
数据仓库的显现，并不是要取代数据库。目前，大部分数据仓库依旧用关系数据库治理系统来治理的。能够说，数据库、数据仓库相辅相成、各有千秋。
二者的区别： （1）动身点不同
数据库是面向事务的设计，数据仓库是面向主题设计的。 （2）储备的数据不同
数据库一样储备在线交易数据，数据仓库储备的一样是历史数据。 （3）设计规则不同
数据库设计是尽量幸免冗余，一样采纳符合范式的规则来设计，数据仓库在设计是有意引入冗余，采纳反范式的方式来设计。
（4）提供的功能不同
数据库是为捕捉数据而设计，数据仓库是为分析数据而设计。 （5）差不多元素不同
数据库的差不多元素是事实表，数据仓库的差不多元素是维度表。 （6）容量不同
数据库在差不多容量上要比数据仓库小的多。 （7）服务对象不同
数据库是为了高效的事务处理而设计的，服务对象为企业业务处理方面的工作人员，数据仓库是为了分析数据进行决策而设计的，服务对象为企业高层决策人员。
1.5 元数据
元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据能够关心数据仓库治理员和数据仓库的开发人员专门方便地找到他们所关怀的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（TechnicalMetadata）和业务元数据（BusinessMetadata）。
1.5.1 技术元数据
技术元数据是储备关于数据仓库系统技术细节的数据，是用于开发和治理数据仓库使用的数据，它要紧包括数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式。
汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、集合、汇总、预定义的查询与报告。
由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取操纵）。
1.5.2 业务元数据
业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层。业务元数据要紧包括以下：使用者的业务术语所表达的数
据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的；具体包括以下： (1)企业概念模型
这是业务元数据所应提供的重要的，它表示企业数据模型的高层、整个企业的业务概念和相互关系。
(2)多维数据模型
这是企业概念模型的重要组成部分，确定业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。那个地点的数据立方体表示某主题领域业务事实表和维表的多维组织形式。 (3)业务概念模型和物理数据之间的依靠
业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所表达。
1.5.3 元数据的作用
描述哪些数据在数据仓库中。
定义要进入数据仓库中的数据和从数据仓库中产生的数据。 记录依照业务事件发生而随之进行的数据抽取工作时刻安排。 记录并检测系统数据一致性的要求和执行情形。 衡量数据质量。
元数据治理的要紧任务有两个方面：
一是负责储备和爱护元数据库中的元数据；二是负责数据仓库建模工具、数据猎取工具、前端工具等之间的消息传递，和谐各模块和工具之间的工作。 我们了解到元数据几乎能够被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的都提到了关于对元数据的治理。但遗憾的是关于元数据的治理，各个解决方案都没有明确提出一个完整的治理模式；它们提供的仅仅是对特定的局部元数据的治理。与元数据相关的数据仓库工具大致可分为四类： (1)数据抽取工具
把业务系统中的数据抽取、转换、集成到数据仓库中，如Ardent的DataStage、CA（原Platinum）的DecisionBase和ETI的Extract等。这些工具仅提供了技术元数据，几乎没有提供对业务元数据的支持。
(2)前端展现工具
包括OLAP分析、报表和商业智能工具等，如MicroStrategy的DSSAgent、
Cognos的PowerPlay、BusinessObjects的BO，以及Brio等。它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图，进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。
(3)建模工具
为非技术人员预备的业务建模工具，这些工具能够提供更高层的与特定业务相关的语义。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。
(4)元工具
元数据通常储备在专用的数据库中，该数据库就如同一个“黑盒子”，外部无法明白这些工具所用到和产生的元数据是如何储备的。还有一类被称为元数据知识库（MetadataRepository）的工具，它们独立于其它工具，为元数据提供一个集中的储备空间。包括微软的Repository，CA的Repository，Ardent的MetaStage和的WCC等。
1.6 数据仓库进展方向 1.6.1 数据仓库的产生和进展
现在基于业务数据的决策分析——联机分析处理（OLAP），比以往任何时候都显得更为重要。假如说传统联机事务处理（OLTP）强调的是更新数据库——向数据库中添加信息，那么OLAP确实是从数据库中猎取信息、利用信息。事实上，将大量的业务数据应用于分析和统计原本是一个专门简单和自然的方法。但在实际的操作中，人们却发觉要获得有用的信息并非如想象的那么容易：
第一，所有OLTP强调的是密集的数据更新处理性能和系统的可靠性，并不关怀数据查询的方便与快捷。联机分析和事务处理对系统的要求不同，同一个数据库在理论上都难以做到两全。
第二，业务数据往往被存放于分散的异构环境中，不易统一查询访问，而且还有大量的历史数据处于脱机状态，形同虚设。
第三，业务数据的模式针对事务处理系统而设计，数据的格式和描述方式并不适合非运算机专业人员进行业务上的分析和统计。
能够这么说，往常查询不到信息是因为数据太少了，而今天查询不到则是因为数据太多了。针对这一问题，人们设想专门为业务的统计分析建立一个数据中心，它的数据从OLTP系统中来、从外部数据源来、从历史业务数据中来……那
个数据中心是一个联机的系统，它是专门为分析统计和决策支持应用服务的，通过它可满足决策支持和联机分析应用所要求的一切。那个数据中心就叫做数据仓库。数据仓库确实是一个作为决策支持系统和联机分析应用数据源的结构化数据环境。数据仓库所要研究和解决的问题确实是从数据库中猎取信息的问题。
与关系数据库不同，数据仓库并没有严格的数学理论基础，它更偏向于工程。由于数据仓库的这种工程性，因而在技术上能够依照它的工作过程分为：数据的抽取、储备和治理、数据的表现以及数据仓库设计的技术咨询四个方面。
（1）数据的抽取
数据仓库是一个独立的数据环境，它需要通过抽取过程将数据从联机事务处理系统、外部数据源、脱机的数据储备介质中导入数据仓库。数据抽取能够定时进行，但多个抽取操作执行的时刻、相互的顺序、成败对数据仓库中信息的有效性则至关重要。
（2）储备和治理
数据仓库的真正关键是数据的储备和治理。数据仓库的组织治理方式决定了它有别于传统数据库的特性，同时也决定了其对外部数据表现形式。要决定采纳什么产品和技术来建立数据仓库核心，则需要从数据仓库的技术特点着手分析。
如何完成对大量数据的储备和治理 并行处理能力
针对决策支持查询的优化
支持多维分析的查询模式，这也是关系数据库在数据仓库领域遇
到的最严肃的挑战之一。 （3）数据的表现
数据表现是数据仓库的门面。那个地点说的要紧是多维分析、数理统计和数据挖掘方面。
（4）数据仓库设计的技术咨询
数据仓库绝不是简单的产品堆砌，它是一个综合性的解决方案和系统工程。在数据仓库的实施过程中，技术咨询服务至关重要，是一个不可缺少的部分，它甚至于比购买产品更为重要。
就目前的进展来看，建立数据仓库有两个差不多条件：
建立数据仓库的行业有较为成熟的OLTP系统，它为数据仓库提供客观条件； 行业面临市场竞争的压力，它为数据仓库的建立提供外在的动力。另外建立大型数据仓库，成本也是较高的，因此对企业的经济实力也是个考查。因此数据仓库的概念一经显现，就第一被应用于金融、电信、保险等行业。
1.6.2 数据仓库进展趋势
(1)数据仓库规模不断增长
所有企业的数据仓库规模都将呈指数增长，数据源的增长以及企业对数据更好的猎取能力推动了这种增长。另外储备成本也越来越廉价，因此企业能够储存更长期的数据。但数据增长也将使企业面临一些新问题，包括数据仓库的可升级性以及可能显现的性能问题。
(2)数据集市的整合 (3)客户数据集成
许多企业现在专门想跨过产品线、业务单位、渠道和地理各方面来综合地得到一个关于客户的单一视图，一种称之为客户数据集成（CDI）的解决方案应声而出，其核心部分由数据仓库和相关技术构成。客户数据集成提供了对客户数据360°的全方位视图，并使企业能够从任何一个接触点上对客户进行认识和做出反应。
(4)开发商的整合
由于企业都想得到完备的产品套件，数据仓库和商务智能开发商因此将越来越多的功能融合到他们的产品中去。
(5)EAI和ETL工具的集成 (6)快速反应的决策支持
电子商务的不断增长促使着企业去查找共享数据和对机会快速反应的方法，尽管真正的实时决策支持差不多是不可能的，但数据仓库技术的进步却使快速反应的决策支持得以实现。在数分钟或数秒钟内对数据进行分析和对事件做出反应的能力有助于企业在各方面的行动，比如供应链治理、客户服务和商务性能治理等。
(7)非结构化信息的增长
企业正面临着非结构化和半结构化数据的增长，包括图像、声音、视频、XML以及其它的数据类型。同时，相关的技术也在不断显现，使企业能够采纳跟往常处理传统的结构化数据资源的方式，来储备和挖掘这些数据。
(8)越来越了解如何对“成功或失败”问题做出正确分析——知识治理 在企业仓促着手建立数据仓库或其它分析型知识库时，数据质量或元数据这些重要问题经常被忽视，其后果确实是，专门多企业现今发觉他们的行动成功性打了许多折扣，因为他们不能确定“成功或失败”问题。数据质量问题和元数据的缺乏会严峻阻碍用户对数据仓库的同意程度，也只能得到悲伤的分析结果和不正确的决策。这是一个相当复杂的问题，需要花费时刻和精力去确定他们。
(9)强调应用程序VS数据仓库
对大多企业来说，数据仓库不再是单独的一件事。需要确定投资回报率。数据仓库项目跟往常一样是必需的，但可能会尽量跟应用程序联系起来以便于运算投资回报率和调整项目成本。
(10)越来越注重盈亏问题
艰巨的经济环境迫使企业除了收入增长外，还得认真考虑收益率问题。这种不断增加的对盈亏问题的注意力阻碍到了IT项目，其中包括数据仓库，最终导致各级水平上的成本削减。新的数据仓库项目仍将不断进行，然而企业可不能再妄图一步登天去做那些对盈利没有直截了当阻碍的事；它们还想有一个明确的商业案例，明确的投资回报率和更短的回报周期。
1.6.3 数据集市、集市群—行业的进展方向
在数据仓库产品方面，微软是以其关系数据库SQL Server作为它数据仓库核心的。微软的OLAP走的是ROLAP的路子，与其数据转换一样，属于常规的解决方案；而并行处理和决策支持扩展则不是SQL Server的强项。因此，整个解决方案仍面向中低端，价格取胜是关键。为此，微软在数据仓库市场中倡导了另一个概念——数据集市(Data Mart)。所谓数据集市确实是一个面向部门应用的、小型的数据仓库；所采纳的技术与数据仓库相似，但储备的内容更加专题化。关于数据集市如此的规模，微软的解决方案便可成为理想的选择。
尽管微软是许多IT人士“憎恨”的对象，但我们不得不承认，它在市场定位方面的工作一直专门成功。其所坚持的走大众化、平民化道路的理念，从操作系统中的windows，办公软件里得Office到数据库领域的SQL Sever等等,无一不是成功的案例。在这次数据仓库的较量中，微软又打起了数据集市的大旗。就目前情形而言，能够建立大型数据仓库的企业如何说还局限于有雄厚实力的大型公司。而占市场相当比重的中小企业，一方面难以同意建立数据仓库高昂的成本，另一方面使用大型数据仓库来解决他们少量的工作也显得有些白费。而现在数据集市则成了他们不错的选择。
表1-1 数据集市与数据仓库的区别
数据来源 范畴 主题 数据粒度 数据结构 历史数据 优化 索引 数据仓库 OLTP、遗留系统、外部数据 企业级 企业主题 最细粒度 3NTF 大量历史数据 处理海量数据、数据探究 高度索引
数据集市能够分为两种类型:独立型数据集市和从属型数据集市。独立型数据集市直截了当从操作型环境猎取数据，从属型数据集市从企业级数据仓库猎取数据。
作为快速解决企业当前存在的实际问题的一种有效方法，独立型数据集市成为一种既成事实。独立型数据集市是为满足特定用户的需求而建立的一种分析型环境，它能够快速地解决某些具体的问题，而且投资规模也比数据仓库小专门多。
但独立数据集市也存在一些问题：
数据集市 数据仓库 部门级、工作组级 部门或专项主题 较粗粒度 星型、雪片型 适度历史数据 便于访问分析、快速查询 高度索引 冗余数据。随着独立数据集市数量的增长，数据冗余量也不断增长，这
种冗余是由于每个独立数据集市都有一个整体数据的备份而引起的，但这些数据中有许多通常并不是必需的。
冗余流程。数据仓库的体系结构能够对所有数据集市的共同活动进行集
中化，没有数据仓库，这些流程就必须为每个数据集市进行复制，这将大大增加爱护DSS所需的职员数量。
较低的可伸缩性。独立数据集市直截了当读取运作系统的文件或表，这非集成。独立数据集市是由自成体系的团队建立的，而且一样是为不同
极大限制了DSS的伸缩能力。
的部门建立的，导致这些数据集市没有进行集成，而且没有一个会包含了整个企业的视图。因此，假如CEO让信息部门提供一个获利能力最强的客户列表，那么从每个数据集市分析到的答案都将是不同的。
独立型数据集市的存在会给人造成一种错觉，看起来能够先独立地构建数据集市，当数据集市达到一定的规模再直截了当转换为数据仓库。实际上多个独立的数据集市的累积，是不能形成一个企业级的数据仓库的。假如企业最终想建设一个全企业统一的数据仓库，想要以整个企业的视图分析数据，独立型数据集市
可能不是合适的选择。现在的业内人士普遍认为，从属型数据集市在体系结构上比独立型数据集市更稳固，能够作为数据集市以后建设的要紧方向。
从属型数据集市只是是在数据仓库与最终用户之间又增加了一套聚拢、优化系统。如此的设计也许对提高整个系统的反应速度方面有一定关心，但却削弱了数据集市相当重要的一项优势——廉价。其成本甚至超过了单一数据仓库系统，不利于此类技术的大众化、平民化进展。另一种比较理想的方式是，企业先就其最急需的领域建立独立型数据集市，而后随着需求的变化、实力的增强逐步建立更多的数据集市。这些数据集市之间保持一种高度的统一与和谐机制，构成一个完整的群体，我把它称作——数据集市群。 数据集市群的优势要紧表现在以下几方面：
(1)成本低廉
初始成本为初始数据集市的成本加上集市群操纵器的成本。尽管比只有几个数据集市的成本高，但与数据仓库相比依旧廉价专门多。而且其投入产出比也更容易推测。
(2)冗余度低
由于加入了集市群操纵器，各数据集市中的数据被统一调度，统一规划。从而排除了数据集市件容易发生的数据冗余、不一致等问题。
(3)后期爱护容易
当集市群因某种需求而要加入新的数据集市时，所要考虑的问题仅是新的模块需要那些数据，原有集市群能提供那些数据。依照这两点去设计新的数据集市，而不必对原有集市群做什么调整。
(4)数据集市群策划和设计
数据集市群的建立需要前期的精心策划、设计和标准化的接口设计。只有解决好这些问题，才能保证以后新建的集市能够与原先的群顺利实现对接及整体成效最佳。目前看来这依旧一项相当复杂的工程，但其一旦实现，给数据仓库行业带来的震动将是难以想象的。
数据集市 信息源
图1-1 独立型数
据集市 数据集市 数据仓库 数据集市 信息源 图1-2 从属型数
据集市
数据集市 操纵器 信息源 数据集市 图1-3 数据集
1.6.4 基于Internet2、光处理器运算机和GGG技术的DW
(1)Internet2
1996年由一些大学和高科技公司组成的联盟开发的，旨在提供超高速的连接速度，该项目的目标是领先于商用互联网3-4年的时刻。目前的Internet2差不多是第三代了，今年早些时候，其骨干网的数据传输速率差不多升级为10Gbps。目前大部分的公共互联网使用2.5Gbps，一些运营商正在将它们的连接升级至10Gbps。
P2P应用、高清晰视频会议、实验室设备的远程操作、分布式运算等应用都能够在Internet2上运行。目前，由于受带宽的限制，这些应用的大规模部署还专门缓慢，而Internet2则能够满足这些应用对带宽的需求。通过Internet2
进行的音乐会转播每秒钟能够发送250GB的数据，这比标准的拨号连接要快4000倍，比有线电视连接要快800倍。
研究人员仍旧在研究如何进一步提高Internet2的效率和速度的问题。研究人员还在开发新的中间件技术，使通过网络的协作更无缝更安全。在目前的互联网上，应用程序本身必须提供中间件所提供的识别、授权、安全等服务。通过语言标准化和兼容性，中间件将大大提高先进网络应用的易用性。
在过去的15年中，互联网的速度每年都会翻一番。研究人员相信，这种每年增长100%的趋势在以后还会连续下去。Internet2的研究人员差不多在研究新一代的超高速网络。速度为10Gbps的Abilene网络的平均运行速度为1Gbps-2Gbps。另外在高等教育领域，用户对带宽的需求的增长将呈几何级数增长，因此新应用的需求将超过目前的公共IP网络的带宽也是专门自然的。
(2)以后高性能运算机
按照摩尔定律，每过18个月，微处理器硅芯片上晶体管的数量就会翻一番。随着大规模集成电路工艺的进展，芯片的集成度越来越高，也越来越接近工艺甚至物理的上限，最终，晶体管会变得只有几个分子那样小。以摩尔速度进展的微处理器使全世界的微电子技术专家面临着新的挑战。尽管传统的、基于集成电路的运算机短期内还可不能退出历史舞台，但旨在超越它的超导运算机、纳米运算机、光运算机、DNA运算机和量子运算机正在跃跃欲试。与传统硅芯片运算机不同，光运算机用光束代替电子进行运算和储备：它以不同波长的光代表不同的数据，以大量的透镜、棱镜和反射镜将数据从一个芯片传送到另一个芯片。
从上个世纪80年代起，光子运算机就成为新一代运算机的进展方向。2003年10月底，全球首枚嵌入光核心的商用向量光学数字处理器——由以色列一公司研发的Enlight在美国波士顿军事通信展览会上露面，引起了业界莫大的关注。因为，它的显现预示着运算机将进入光学时代。以光速进行运算，运行速度达到每秒8万亿次——这相当于一台超级运算机的运算能力。但超级运算机动辄采纳上千个处理器同时工作，才能实现如此的运算速度。以去年问世的“地球模拟器”为例，这台号称全球运算速度最快的超级运算机峰值运算速度为35.86万亿次，而那个速度是由它的5120个处理器共同制造出来的。
由于Enlight强大的性能，能够被广泛运用在大型多媒体广播系统、机场安全检查系统和医学数据库系统等方面。比如在移动通信领域，采纳Enlight进行多用户检测，即通过重复运算一系列方程式，能解除同一基站内用户间的相互干扰。一枚单独的Enlight就能够同时支持2000个用户，并幸免相互干扰。而在生物科技方面，Enlight强大的运算能力，能够大大缩短生物技术运算必需的基因数据配对和基因与多基体配对过程。
“光子运算具有庞大的潜力，能够做常规运算无法办到的事。”德国达姆施塔特大学的科尔内利娅·登茨博士长期致力于光运算研究。她表示，采纳光学技术不但能够极大地提升运算机的运算速度，而且能够让运算机系统模拟人脑的思维活动，同时比人脑的处理速度快上数千倍，从而实现真正的人工智能。科学家的推测不是没有依据的。到2020年，硅芯片的运算速度和微型化进展都将止步不前。而与此同时，网络和其他行业进展带来的海量数据运算需要和更快的传输需求，将迫使人们不得不寻求革命性的变革。
(3)网格技术
网格运算因为在结构上酷似电力网络而得名。在九十年代中期，网格作为一种共享运算的方法被正式提出，并第一在科研领域应用。后来，为了降低成本，专门多企业也打算利用闲置的资源，网格开始逐步进入商业市场，并由此为许多产业带来了新的机遇。
网格技术是一种趋势，这是毋庸置疑的。就像运算机最初是大型主机，进展到更加通用的小型机，现在则又有了更多的选择。这其中有成本的缘故，有硬件技术的进展，也说明大伙儿都在期待一个更加开放的平台。网格技术正是这种趋势进展的一个必定。
尽管网格的进展还面临专门大的困难，有业内人士说，“网格的处境就看起来10年前的Internet和3年前的Linux一样，正在从技术运算进入商业运算。”然而，曾经价格高昂的网格运算差不多进入各个组织机构及跨国公司，广泛应用到金融和工程仿真，医学研究和石油勘探领域，发挥着庞大的作用：汽车制造商们正实施更多的模拟程序以使汽车更安全；娱乐公司更细致地描画数字人像以求逼确实成效……对企业来说，网格无疑是极具价值的工具，以后几年，将会有更多的网格进入市场。
为了在以后的进展潮流中占据有利的战略地位，世界各国都纷纷加紧了网格研究的步伐。 一些发达国家和跨国公司已为此投下了巨资。在具体实施中，IBM全球服务部和其业务合作伙伴一起，共同提供各种与网格有关的服务，包括一个网格创新工作室(用于关心企业在其业务中实施网格)以及专业化的行业专用课程。在产品方面，IBM eServer产品线也形成了一个能够用来设计和开发网格解决方案、甚至治理整个网格的坚实平台；其 DB2产品和工具也支持网格运算解决方案，使得能快速、方便地建设复杂的数据基础设施。
(4)数据仓库、联机系统的进展
依照长久以来的体会，运算机的软硬件进展一直是互相促进、互为动力的。以上所述的以后高性能运算机、Internet2、网格技术等等差不多为我们勾勒出了一幅美好的画面。更强大的运算工作站、惊人的信息传输速度、更优化的网络
和谐机制，这些无疑都给以后软件业的进展带来了更宽敞的施展空间。就如同现在的PC机使用的内存，比10年前硬盘的储备容量还大一样。许许多多现在认为不可能实现或相当复杂的工作，对那时的运算机系统来说只是是小儿科而以。到那时对一个包含5千万条记录的DW作一次完整分析，也仅仅需要几秒钟的时刻。
因此我们有理由相信在新一代的应用系统中，数据仓库将在一开始便被纳入系统设计的考虑，联机分析会应用于普遍的事务处理系统之中。在数据治理上，联机事务处理和数据仓库在应用中相对独立，使联机事务处理系统本身更加简洁高效，同时分析统计也更为便利。面向行业的数理统计学向更为普遍的应用进展，并集成到应用系统的数据仓库解决方案中。它们将立足于数据仓库提供的丰富信息，更好地为业务决策服务。
1.7建设数据仓库的必要性
企业建立数据仓库是为了填补现有数据储备形式差不多不能满足信息分析的需要。数据仓库理论中的一个核心理念确实是：事务型数据和决策支持型数据的处理性能不同。企业在它们的事务操作收集数据。在企业运作过程中：随着定单、销售记录的进行，这些事务型数据也连续的产生。为了引入数据，我们必须优化事务型数据库。处理决策支持型数据时，一些问题经常会被提出：哪类客户会购买哪类产品？促销后销售额会变化多少？等，事务型数据库能够为这些问题作出解答，然而它所给出的答案往往并不能让人十分中意。在运用有限的运算机资源经常常存在着竞争。在增加新信息的时候我们需要事务型数据库是闲暇的。而在解答一系列具体的有关信息分析的问题的时候，系统处理新数据的有效性又会被大大降低。另一个问题就在于事务型数据总是在动态的变化之中的。决策支持型处理需要相对稳固的数据，从而问题都能得到一致连续的解答。
数据仓库的解决方法包括：将决策支持型数据处理从事务型数据处理中分离出来。数据按照一定的周期（通常在每晚或者每周末），从事务型数据库中导入决策支持型数据库——既“数据仓库”。数据仓库是按回答企业某方面的问题来分“主题”组织数据的，这是最有效的数据组织方式。
第二章 数据仓库需求分析
2.1 需求分析缘故
需求分析的成败直截了当阻碍到数据仓库的成败实施。关于一个严格完整的数据仓库项目来说，需求分析应该属于数据仓库项目的第二个过程，第一时期属于数据仓库项目定义时期，对项目范畴、项目评估、可行性研究分析和投资回报等相关进行定义，也是一个不容忽视的时期。
第一数据仓库失败的典型表现形式：
图2-1 数据仓库失败图示
（1）项目超过预算
（2）没有在规定的时刻内完成 （3）没有实现要求的功能 （4）用户不中意 （5）系统性能不满足要求
2.2 需求分析时期
在进入需求分析的初级时期时必须要先确立数据仓库项目组人员（其中包括公司接口规范人员、接口人员、数据开发人员、ETL调度人员、稽核人员、页面展现人员等），对局方联通进行接洽商讨等相关工作。
2.2.1 需求分析成员确立
（1）接口规范人员：用来确定当前经分能否支撑局方提出的需求，通过商讨，判定当前拥有的接口是否满足需要，或是重新确定新的接口，来支撑项目的实施。如图，例如对联通融合业务进行商讨，判定接口是否能够实施。
图2-2 接口规范制定流程
（2）接口人员：负责承接省分上传的数据，进行初步的稽核，确认是否需要迟传、通报等，并通过ETL调度，调起节点。判定ETL能否成功调起，所承担的负载最大值等。
图2-3 接口入库流程
（3）数据库开发人员：进行项目的开发和实施，通过与局方商量，依照需求估量项目实施周期。通过Powerdesigner、PL/SQL等工具，进行设计开发。
（4）ETL调度人员：在开发人员脚本成功开发后，由ETL统一并行调度，保证及时触发节点，并实时监控。
图2-4 ETL调度实例
（5）稽核人员：实时的对数据进行详细的稽核校验，确保数据无误，能够及时准确的上传至页面。专门是对重要字段进行反复校验，及时通过邮件反馈。
（6）页面展现人员：当稽核人员确定数据无误时，由页面展现人员进行页面展现，供局方人员使用，确保数据的实时准确。有些情形下还会有项目和谐和会议记录等人员参加。
2.2.2 需求会议
在做需求分析之前，一样需要对局方进行接口的确定，以保证总部和省分以统一的接口进行上传和接收，并通过接口规范来得到双方的确认，会议的目的确实是公司与局方在各个方面达成一致，启发局方提出更贴近数据仓库的需求，具体想要得到哪些数据，期望得到哪些结果。需求会议一方面是为了排除局方在进行需求确认时的数据仓库的盲区，更重要的一方面是让局方明白建设数据仓库开发的过程和困难，还有一方面确实是能够得到局方配合来完成项目及时准确的实施。
第三章 数据仓库总体设计
3.1 数据仓库实施环境
数据库以ORACLE为基础，POWERDESIGNER进行数据模型的确定加工，PL/SQL DEVELOPER软件进行具体的过程开发。
3.2 确定数据仓库开发的生命周期
由于数据仓库最佳结合了业务惯例和信息系统技术，因此，一个成功的数据仓库实施需要这两方面的不断和谐，以均衡其所有的需要，要求，任务和成果。
数据仓库项目有3个轨道(tracks)：数据轨道，技术轨道和应用层轨道。当在整理任何数据库项目打算时，建议以这三个轨道为模板来治理和同步活动。
数据库生命周期治理方法(Discover, Design, Develop, Deploy, Day to Day , Defend, Decommission), 昵称“7D法”。
数据仓库的构建从来可不能真正终止。不像传统的数据库在部署后的一段时刻里保持相对的不变，数据仓库始终处于不断的变化之中，以应对它所服务的业务环境的变化。当今的业务环境更加复杂，并涉及比以往任何时候都要快的变化。处理这种几乎是不断的变化是企业的最大挑战之一。这确实是什么缘故数据仓库团队中的每一个人，包括技术决策者( TDMs ) 和业务决策者( BDMs )，都必须处在同一阵线上，使用同一种生命周期治理方法，以使他们的认识完全得到统一。只有如此，才有可能对已实施的数据仓库、企业的构想和宗旨进行调整。
(1)挖掘
任何规模和领域的数据库项目离开了开始的挖掘时期都将失败。那个时期也被称为“需求分析和定义”， 挖掘时期需要以业务为中心，专门是数据仓库项目，因为数据仓库的输出需要支持组织的目标。挖掘这一步实质上确实是调查，应该不断地问六个差不多问题(什么，如何，在何处，谁，何时和什么缘故)，记录好答案，并把这些答案包含在您起草的解决方案中。
在“7步”的前3步(挖掘，设计，开发)中，必须对业务主和技术专家进行集中的和谐，项目经理(PM)应该促成这一进程。项目经理作为一个独立的专业人员，要紧关怀项目的及时上线、预算在操纵范畴内，有预期的运行成效;项目经理在得到各方的反馈意见后，负责制定严格的路线，里程碑和成功指标。假如项目里
没有PM,这些将成为您的工作。
在挖掘时期，PM必须收集三个轨道的信息，即技术轨道，数据轨道和应用层轨道。在其他任务中，PM必须确定利益相关者和用户，必须明白得他们各自的角色和相应的数据/视图 需求。PM必须明白本组织的绩效治理策略：目标是什么，倡议什么以及跟踪业务和项目健康状况的支撑度量标准/关键绩效指标。假如上述策略的任何部分遗漏了，该项目专门有可能失去最终用户的评分，这可能会导致低的采纳通过率和以后资金的丢失。换句话说，该项目将失败，而不管项目任务执行得有多么完美。
(2) 设计
设计这一步的要紧活动是定义描述数据仓库的语义和概要模型。这些模型必须解决企业用户的治理信息系统(MISs)和商务智能( BI )分析需要。关于数据仓库项目，能够为关系型数据仓库创建概念和逻辑数据模型，为表示多维立方体创建三维模型。能够使用决策矩阵，以关心确定每个三维模型需要包含些什么;沿Y轴方向列出被数据仓库支持的关键业务流程，沿X轴方向列出建议的维。那个矩阵将作为当前开发、以后扩展和跨组织集成的向导。在设计时期建立的模型必须反映第一时期收集的六个问题的答案。标识数据仓库相关的所有数据源(内部和外部的)，业务/交易数据库和展平文件是个好注意。同时应该明确说明哪些数据将被导入数据仓库，哪些只会简单地作为外部数据源引用。
通常，技术轨道有自己的PM，但仍旧可能需要填补那个角色。数据仓库能够增长为专门大的内容和十分广泛的范畴，因此有必要在数据仓库部署之前恰当地规划其大小。第一在纸上估量其大小，如此您就能够大致把握当数据仓库投入产品应用时所需的处理器速度和磁盘容量。同时需要估算一天的业务终端用户数量以及他们使用的应用(例如，对立方体做一个专门分析，或者从关系数据仓库中取出缓存的报告)，也要估算数据仓库一年中将会储备的数据量。只是因为数据仓库是一个进展中的工作，可能会需要两年和五年推测，同样，其处理能力和数据储备需求将随着时刻的推移不断增加。数据仓库设施包括各种硬件，通信和软件解决方案，所有这一切都必须协同工作，为终端用户提供一个工作的数据仓库。如此需要足够的时刻来打算和测试将如何整合所有这些不同的组成部分。
跟技术轨道一样，应用轨道可能有自己的PM或由一个主导的软件开发人员充当这一角色。假如你的工作是与此人和谐以同步任务。假如不是，那工作描述会扩大。应用层包括猎取从数据仓库收集到的输出，通常是MIS报告和BI分析结果。MIS报告常是屏幕显示，外表板，和打印副本的形式，它们关心企业治理者做出运行日常业务所需的战术决策。这些输出相对比较容易界定、编码和被一系列标准化的进程抓取，这些进程运行在可预定环境中。应用层的BI部分是一
组查询和响应，以关心执行治理作出战略决策，推动商务运营。BI解决方案往往是非结构化的，专门难预定义，因为他们倾向于用一种专门的方式探究数据。记分牌，图形和数据透视表是BI的应用例子，它们能刺激更多的数据探究，而这可能导致公司内部战略方向的改变。
在那个时期许多方法要求原型或试点项目。“7D法”不需要。至多，作为应用层的设计活动中的一部分，能够做一个“点击模式”--一种输入/输出屏幕的快速出现模型，不涉及或只有极少的代码但却能给利益攸关方可视化的概念，同时又可不能吃掉宝贵的时刻和资源。假如试点或原型是必要的，那么选择其中的一个切片(slice)作为试点，完成“7D法”的每一步。“7D法”不区分试点，原型和产品系统--它们都被视为项目。
假如按照“7D法”设计了一个原型，同时最终进入了产品(大多数原型差不多上如此)，然后要选择比第一个切片更认真地选择第二个切片。假如这些切片不能成功地集成在一起，假如他们不支持我们在挖掘步骤发觉的企业宗旨和意图，那么整合彼此只会遇到困难，在某些情形下，甚至全然不可能。
(3) 开发
数据轨道开发步骤要紧有两个部分：
第一个涉及将数据模型映射到其对应的物理设计(实质是关系数据仓库和OLAP立方体的蓝图)，规划数据库的大小，必要时对表进行分块，为数据仓库对象设定命名约定以便业务用户和技术用户都能适应，并制定索引和识别索引候选名单的策略。
图3-1 通过POWERDESIGNER工具建表
第二部分涉及数据从外部数据源到数据仓库的提取转换加载(ETL)。包含在第二部分但不局限于这一部分的是数据转换服务( DTS )/SQL Server整合服务( SSIS)补丁的开发与测试，导入/导出和T-SQL脚本开发和测试，以及对外部数据源组件的数据整合测试，这些数据可不能导入到数据仓库。
图3-2 ETL监控流程
技术轨道的开发步骤包括审查，测试和选择产品，并提供其作品的体系结构设计。为了组成通信链路的各个层--物理层、数据链路层、网络层以及传输层，会话和表现层，如此做是必需的。尽管许多产品把多层无缝打包到一个解决方案，但有必要认识到这些层中的每一个在以后的负载要求和性能要求，并提早为这些需求作好预备。为了从新的数据仓库交付数据，应该选定数据仓库的服务器和储备解决方案，以及新的，最终用户面临的硬件。如此做是为了产品数据仓库和分期数据库--DTS/SSIS软件包和T-SQL脚本在那个地点执行，从外部数据源导入数据，以及把可操作和精心办理的数据导入到关系数据仓库和OLAP立方体中。依照挖掘时期收集到的需求，数据仓库环境可能还要支持数据集市，快照，和报告数据库，因此，也要预备为这些方面考虑环境。
应用轨道开发步骤听起来专门简单：只要开发终端用户应用程序。然而，这可能是整个过程中最复杂和费时的任务，同时可能是代价最高的--假如没有认真制定和考虑成功的量度标准。正是在这一时期，范畴蠕变(不断增加特性和功能，而不考虑对其他两个轨道的设计和开发的阻碍)可能像鱼雷一样破坏项目。除了开发终端用户应用程序，不得不制定测试这些应用程序的打算，我们需要制定终端用户培训打算以便用户能学会如何使用这些应用软件。在每一个里程碑，必须确保获得相关各方的签字或验收。
(4) 部署
部署数据仓库和部署交易数据库是不一样的，通常，能够用一种快速、包罗万象的风格部署一个交易数据库，而数据仓库通常是递增式地部署到整个企业的各类用户中。这种递增的速度和各个组使用数据仓库的次序是包含在部署时期中部署打算的一部分。
理想的情形下，数据仓库的部署以一种迅速级联的层次进行，第一是技术就位--服务器，储备设备，通信链接等，系统软件的安装，测试并预备投入产品。然后是数据轨道各组件的展开--数据仓库数据库(关系型和OLAP )的建立，以及ETL进程的联机。在最终的应用层添加之前往往会打住一下，当通过ETL进程让数据流从外部来源进入各种不同的数据仓库数据库和立方体时，进行必要的测试和调整。然后应用层被部署。您可能想要逐步地部署应用层，因为企业内部的不同人员有不同的等级。
作为一个PM则发挥着专门重要的作用。在准确的指导和引导下，三个轨道将按预定打算到达部署时期，幸免数周数月的“误点”担忧。一旦技术和数据轨道就绪并测试，并预备连续，那么开始展开应用层。没有用户界面( UI)的数据仓库对任何人差不多上没用的，而一个尺寸不足，弱工程系统架构的数据仓库会因性能太差而可不能被企业用户采纳。
(5)日常治理
日常业务运营的治理是专门重要的;而这常常在规划和开发过程中被忽视。不仅必须确保定期(每日，每周等)进行爱护，包括硬件和软件，还必须要不断监视所有系统的性能和增长。数据仓库永久可不能终止;随着越来越多的用户发觉数据的内在价值，并制造新的，有时甚至是具有挑战性的方式来查询数据仓库，它会连续增长和扩大。有时必须预备承担，包括确保所有的系统(硬件，通信链路，系统软件)的全面运作，打最新的补丁和升级。当业务瓶颈显现时尽可能快地诊断和解决问题; 确保所有需要做备份的系统及时备份，实际上，有备份工作定义和打算，并要求所有的备份复原测试，后续测试，开发，或报告数据库。
业务不是静止的，它们必须不断地改造自己，以保持竞争力。数据仓库数据治理员的职责确实是跟踪数据的使用，评估数据的重要性，并检测业务什么时候开始需要转变。随着业务模式的变化，将会需要更新，更好，更灵活，可能更复杂的用户应用程序，数据治理员应该能感知到这些要求。有时，当业务方向和重点变化到了一定的程度，就需要重新进入挖掘时期，生命周期将回到原点。洗涤，漂洗，重复下去。
(6)防护
爱护数据仓库涉及的不仅仅是采取定期备份或确保没有任何应用程序包括SQL查询可能会开放给SQL注入式攻击。我们必须打算整个范畴和宽度的监控爱护，因为数据仓库包含了企业最宝贵的资产--它的数据，以一种通过编译的，清理过的，以及(在某些情形下)信息化了的格式存在。
数据仓库的威逼通常分为两类，物理的和逻辑的。物理方面的威逼能够是外部的(龙卷风，洪水，火灾，地震)或内部(有意的，偶然的)。防止来自物理方面威逼的做法既能够是采纳简单的限制访问运算机和通信室，也能够如位于地理上相距甚远的容错站点上的镜像服务器般复杂(且昂贵)。物理防备取决于复原时刻和复原点目标，也确实是多少时刻数据仓库离线和多少数据丢失我们能够承担。
逻辑威逼要复杂得多，仅仅因为数据仓库环境的自然特性。操作系统可能会失败，数据库治理系统可能会崩溃，一个或多个应用程序可能有意无意损坏、销毁、误解数据(专门显现在承担数据仓库给养任务的ETL过程中)。扫瞄器的用户界面差不多把嵌入式SQL调用暴露给了SQL注入式攻击。每一个潜在的威逼都必须查明和处理; 在威逼发生之前制定补救措施要比它们发生之后好得多。PM的工作是为整个数据仓库安装制定一个全面的防备。
(7) 退役
可能有一天当数据仓库，或一个组件部分(分期数据库，数据集市，报告数据库，立方体)不再符合要求，解除它的时刻就到了。并非每一个数据库都能够
不断重构或升级，以满足新的要求。有时候，仅仅是需要丢弃和重建，专门是假如数据库实例是“规范建立的”，即没有适当的架构充分反映企业的目标和意图。在这种情形下，必须同步进程。
一样来说，退役步骤以如下三种方式之一发生：没有更换的退役;移交式退役;和逐步到位/逐步剔除的退役。“没有更换的退役”是指数据库用来执行的功能不再需要。不仅是数据库退休了，在它之上的执行功能也退休了。 “移交式退役”说明另一个数据库将取代退役的数据库，同时其对应的执行功能也将从旧的数据库迅速转移到新的。某一天，用户可能访问旧的数据库，而翌日他们将访问新的。“逐步到位/逐步剔除的退役”说明旧的和新的数据库将并存运行一段时刻，而功能和用户逐步从旧的转移到新的，直到最后再也没有用户或功能运行旧的数据库时，它就能够退役了。每个方案都有其风险和回报;我们必须确定何时风险大于收益，确定哪种打算最适合您的情形。然后与技术轨道和应用轨道的其他人员协同工作，打算和执行，以确保无缝转换。
(8)良性循环
在与这些数据仓库的各个组件打交道的过程中，随后将会有新一轮的发觉，这期间会评估随着时刻而进展的新需求。发生这种情形可能来自从储备在数据仓库中的数据收集到的信息。这些新的要求可能会导致扩大增强一个或多个轨道的设计和解决方案。我们需要将这些变化反映到现有的数据仓库中，如此就能够部署更新、更好的、用户期望利用的解决方案。为保持数据仓库像不可思议的机器一样运行，一些新的要求可能会导致日常运作的变化。
随着时刻的推移，生命周期的多次迭代过程会导致数据仓库紧密联系于企业结构，直到数据仓库和业务成为无缝的整体。关于这一难题，PM的职责是确保所有活动和任务差不多上按照规范进行，被既定的成功指标同意，并被同步部署。
3.3 通讯数据仓库设计原则
（1）主题域设计原则
模型共划分10个域，M域是其中一个单独的域—企业治理域，DWA模型设计遵循主体域划分原则。
（2）规范性设计原则
统一模型命名规范、数据组织规范（包括时刻粒度、数据粒度）。 （3）完整性设计原则
考虑业务覆盖范畴的完整性和模型设计的完整性。 （4）稳固性设计原则
将实体差不多属性与实体业务分类属性分离，在实体分类属性发生变化时，
只需要增加实体分类关系数据记录即可，对模型本身不产生阻碍。
（5）前瞻性设计原则
同时采纳自底向上和自顶向下的方式设计模型，其中自顶向下要紧基于业务需求进行模型设计，完全覆盖到所有需求，自底向上要紧基于业务逻辑而非业务需求进行模型设计，保证在有新需求时，底层模型能够对其进行支撑。
（6）扩展性设计原则
实体扩展性原则，模型设计中实体内只保留最细粒度的差不多维，粗粒度或上层的属性通过属 性依靠关系实体来表现，如此在扩充属性或者扩充实体关系时，只增加表现属性依靠关系的实体即可。 通常情形下，数据仓库的实体扩展，可不能阻碍核心实体和核心实体关系。
3.4 确定数据仓库系统的结构及各部分的要紧功能
数据仓库系统由数据猎取、数据储备和数据访问组成。从多个信息源中猎取原始数据，通过必要的清理转换后装入数据仓库，通过数据仓库访问工具，向用户提供统一、和谐和集成的信息环境，支持企业全局的决策过程。数据仓库系统的具体结构，如图所示。各组成部分功能如下：
图3-3 数据仓库系统的结构
（1）数据源。数据仓库有多个异构的内部和外部数据源，如各个OLAP系统的操作型数据、文本文件、HTML文件及知识库等，各数据源的数据组织格式可能不一致，因此在这些数据进入数据仓库之前要进行必要的整理加工。
（2）设计模块。用于为数据仓库的源数据库和目标数据库建立信息模型。因为数据进入数据仓库之前必须通过检验，排除可能隐藏的错误。为了满足决策支持和深入分析的需要，数据需通过专门的整理、加工和重新组织，才能装到数据仓库中。设计模块确实是承担描述数据的检验、整理、加工的需求和相应过程及步骤。
（3）元数据库。用于储备数据模型和元数据。其中，元数据定义了数据的意义及系统各组成部件之间的关系。元数据包括关键字、属性、数据描述、物理数据结构、源数据结构、映射及转换规则、综合算法、代码、缺省值、安全要求、变化及数据时限等。
（4）数据抽取模块。该模块是依照元数据库中的数据源定义、数据抽取规则定义对异地异构数据源进行清理、转换，对数据进行重新组织和加工，装载到数据仓库的目标库中。转换是保证目标数据库中数据的一致性，这种不一致的形式是多样的，为了集成这些不一致的数据必须进行转换。数据抽取能够手工编程来实现，也能够用数据仓库厂商提供的工具来实现。
（5）DW治理工具。为数据仓库的运行提供治理手段，以PL/SQL DEVELOPER为例，包括安全治理和储备治理等。这是由于在数据仓库的日常运行中，需要不断监控数据仓库的状态，包括资源的使用情形、用户操作的合法性和数据的安全性等多个方面。
（6）数据仓库和数据集市。用于储备重新组织和整理后的数据。目前数据仓库一样基于传统的关系型数据库治理系统，因为传统的关系型数据库治理系统成本和复杂性低，同时已为宽敞企业所熟悉，而且它能满足数据仓库应用环境下的大部分功能需求。但在某些规模专门大的决策支持应用场合卜，专用的多维数据库具有一定优势。数据集市是支持某一部分或特定商业需求的DSS应用的集合。数据集市中的数据仍具有数据仓库的特点，只只是数据集市中的数据是专为某一部门或某个特定商业需求所定制的。数据集市的结构和数据仓库类似。企业在建立数据仓库的过程中，由于数据仓库的规模较大，在原先分散的操作刑环境基础上建立一个大而全的数据仓库，事实上施周期长，见效慢，费用昂贵，这是企业不情愿的，因此能够考虑先建立数据集市，再扩充到数据仓库的思想，从企业最关怀的业务开始，以最少的投资，完成企业当前的需求，以猎取最快的回报，然后不断扩充和完再，直至建立全局的数据仓库。
（7）OLAP服务器。OLAP在数据仓库基础上实现多维数据分析和操作，是功能强大的多用户的数据操纵引擎，专门用来支持和操作多维数据结构，为前端工具提供多维数据视图及服务。
（8）前端数据访问和分析模块。该模块为用户提供一整套数据访问和分析工具，以实现深层次的综合分析和决策。这些工具不但要提供一样的数据访问功能，如查询、汇总、统计等，还要提供对数据的深入分析功能，即数据挖掘的功能，如数据的比较、趋势分析、模式识别等。数据访问和分析工具包括用户查询、分析和报表生成工具，数据挖掘工具，多维分析工具以及用客户机/服务器工具开发的前端应用。其中多维分析工具能够提供多维分析能力，数据挖掘工具分析大量的历史数据，从中发觉业务进展规律，推测以后趋势，关于特定的不能直截了当采纳现有工具的业务需求，可考虑用客户机/服务器工具开发相应的前端应用。
（9）粒度
主题中事实表的数据粒度说明，这种粒度能够通过对维的层次限制加以说明，也能够通过对事实表数据的业务细节程度进行说明。数据仓库的数据单位中储存数据的细化或综合程度的级别。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。 确定数据粒度的差不多准则
数据仓库中包含大量数据表，这些数据表中的数据以什么粒度来储备，会对信息系统的多方面产生阻碍。在做数据仓库设计时，设计者确定以数据的什么层次作为粒度的划分标准，将直截了当阻碍到数据仓库中数据的储备量及查询质量，并进一步阻碍到系统是否能满足最终用户的分析需求。一样情形下，依照数据粒度划分标准能够将数据仓库中的数据划分为：详细数据、轻度总结、高度总结三级或更多级。在确定数据粒度时，应注意的一条原则是：细化程度越高，粒度越小；细化程度越低，粒度越大。确定数据粒度是数据仓库设计的基础，当数据粒度合理确定后，设计和实现的其他问题就会变得专门容易，相反，假如没有合理地确定粒度，后续的工作就会专门难进行下去。 数据粒度划分差不多方法
在数据仓库逻辑设计过程中如何确定数据粒度，目前还没有一个精确度量的方法，设计时应考虑的重点放在数据仓库中数据的储备量大小及数据是否满足最终客户需求上。
通信行业属于数据密集型行业，在日常的工作中积存了大量交易、财务、账务数据。通过建立数据仓库，利用数据仓库提供的强大数据分析能力，能使通信行业在提升客户服务、提高资产质量、降低成本上起到专门重要的作用。在数据仓库中确定数据粒度，第一是数据储备量的估算，在那个地点可采纳粗略估算的方法来估算数据仓库中将要使用到的DASD（直截了当存取储备设备）数量。面对数据仓库中确定的各主题域，设计者要建立若干事实表，对每一个表中可能储
备的最多和最少数据进行估确实是估算DAS能够以数量级为估算单位初步估量行数的上下限。关于以后数据量变化趋势，则只能以市场变化情形为依据来估算数据量的变化情形。例如通信行业，能够依照过去若干年的客户变化情形，估量以后一年内客户数量的变化，进而估量5～10年的变化情形（注意要估算最多和最少的情形）。对每个事实表进行如上估算后，结合估算事实表的索引项大小，能够运算出最大、最小的DASD数。以通信行业的数据仓库系统Oracle作为DBMS，得到数据量估算表（见表3-1）。
表3-1 数据量估算表
表空间名字 SYSTEM TEMP1 TOLS USERS 小计 TS_ORIGEN_TABLE 表空间说明 系统表空间 系统临时表空间 系统应用表空间 系统用户表空间 系统 用途 MIN(M) X1 X2 X3 X4 T1 行大小*MIN(行数) 事实表 TS_DC_IDX 数据中心索引表空间 总计 估量索引项大小 MAX(M) Y1 Y2 Y3 Y4 T2 行大原始层表 小*MAX(行数) 估量索引项大小 S1 S2 从表3-1我们得到了DASD的最大最小估算数据和行数的最大最小估算值，紧接着确实是确定数据粒度了。这时能够参照行业体会值来确定是否需要双重或多重粒度，除非是轻量级的数据仓库，一样均需要双重粒度，大多数情形下数据仓库需要多重粒度。表3-2是行业体会值。
表3-2 数据粒度体会值
一年期 10,000,000行 1,000,000行 100,000行 10,000行 双重粒度级 双重粒度 都能够 都能够 五年期 20,000,000行 10,000,000行 1,000,000行 100,000行 双重粒度级 双重粒度 都能够 都能够 假如数据仓库只需要单一粒度，则数据粒度的级别就没有重大的意义，因此数据粒度级别是针对多重粒度而言显现的一个概念。我们应着重分析的对象是主题领域中某个确定的“维度”。关于双重粒度和多重粒度的级别设计问题，唯独可行的方法是采纳推测方法。在做数据仓库设计时，无法得到精确的需求，只有拿出了具体的设计方案后，才能得到具体有用的信息，因此推测法的动身点是项目的大致需求和实际开发体会。总的来说，针对特定的主题域、特定的维度到底在何种级别上建立汇总数据，要依照项目大小来做决定，在太低细节级数据上建立汇总会使该汇总没有任何实际意义，处理数据时将消耗大量资源；在太高细节级上建立汇总数据将会使处理时过多依靠真实档案。在设计通信行业数据仓库时，粒度级别是如此确定的：假如要对客户交易行为分析，能够确定如下分析维度，交易方式（现场、非现场）、交易手段（互联网、 、热键、刷卡）、交易时刻等等。在设计数据仓库时，多重粒度的设计是毫无疑问的了。数据粒度级别的确定，应该第一考虑的是在详细数据的基础上以较低级别来汇总数据（如以交易日为单位），那么做年度数据分析时，系统必定要消耗专门大资源；但假如在较高级别上汇总数据（以年为单位），则极有可能需要向下挖掘数据来分析其月或者日的数据。因此，你唯独可行的方法是推测，进而与DSS分析员交流来确定数据粒度级别。在那个地点，采纳三重粒度设计方案，数据仓库中包括详细数据、按月汇总数据、按年汇总数据。通过上述几个步骤，差不多符合要求的数据粒度差不多确立，在最终确定往常必须与用户反复讨论，确定数据粒度划分是否符合所有主题域分析需求。
第四章 数据仓库详细设计
4.1 逻辑模型设计
实际数据仓库项目建设中，往往存在用户业务需求范畴难已确定、需求超前、需求的随时应变等情形，传统的瀑布式系统开发方法适用于需求确定的开发，但难以适应类似分析型系统的建设，许多项目也因此导致失败，为此一种表达分而治之，分时期实施的螺旋式开发方法应运而生。
螺旋式开发方法将庞大的需求任务目标分成几个时期，按照问题定义、系统分析、系统设计、开发、实现、爱护和系统总结评估的流程来进行，通过不断扩大开发范畴的方式逐步完善数据仓库系统。逻辑数据模型建立一个统一的、共享的基础数据平台，为各个业务部门的不同业务需求提供一致的、规范的数据，其结构是为了满足各种不同的分析逻辑的要求而设计的。目前业界许多大公司如：IBM，NCR，ORACLE 等提出了各自的数据模型，随分类视角不尽相同，但从不同侧面反映了通信行业需求和进展的全景和特点。这些逻辑数据模型的组织规划是围绕通信业务活动的要紧主题领域进行的，是多功能的和集成的，如客户、产品、账户、机构和渠道等。逻辑数据模型是一个可扩展的、动态的模型，是实际项目中的信息参考模型。结合通信行业现有分布数据中心的特点，提出基于逻辑数据模型的分布式数据仓库结构，上述结构采纳分步实施，自底向上的方法，具体项目实施中可选择数据质量较好、系统相对集中的数据中心进行数据集市试点，等成功后再逐步推广，最后构建全局数据仓库，这种方式较为符合通信行业的实际需求，能够快速见效，提高了系统成功率，且通过统一逻辑数据模型的映射差不多能满足单一数据视图的要求。能够通过ETL 数据抽转换加载提高数据质量，并通过元数据治理来保证数据集市间，数据集市和数据仓库间数据映射的唯独性。
统一数据架构是基于联通全企业的整体数据规划，本期打算第一实现B域和M域的数据模型整合，构建企业级的统一数据仓库，并在后期考虑O域数据的整合。
图3-4 数据仓库架构
4.2 物理模型设计
(1)DB-DW 架构，数据仓库最典型的架构是DB-DW 结构。 数据仓库典型的建设方法有两种：
一种是自顶向下，第一建立全局级的数据仓库，然后从中抽取数据建立面向各个部门的数据集市这种方法，所有数据在进入数据仓库前进行清洗和转换，能够保证数据的一致性，这种架构一样适用于相对独立集中或规模较小的企业；
另一种是自底向上的建设方法，即第一建立一个或几个数据集市，分布实施现解决企业面临的局部问题，然后再从个数据集市中抽取数据构建统一的数据仓库。因此形成了两种数据仓库体系结构DW-DM 和DM-DW，其中DM(Data Mart)是数据集市。
(2)DB-ODS-DW 架构
ODS(Operational Data Store)是用于支持企业日常的全局应用的数据集合，ODS 解决企业日常性的问题，只存放当前或近期的数据，同操作型数据库类似，其数据可进行联机增加、删除、更新等修改，这又有别于数据仓库，数据仓库中数据只是增加，没有修改，因此这又形成了数据仓库DB-ODS-DW 的架构。
从技术角度看，集中式的数据仓库为企业提供统一的数据视图，数据一致性能够得到专门好保证，因此许多厂商公司企业都采纳集中的数据仓库方案，然构建一个集中数据仓库，不仅耗时，而且费劲，投入专门大，产出效益专门缓慢，集中式的数据仓库的存取瓶颈和安全性总究是不容忽视的问题；同时许多大型企业或公司大多采纳总分的组织治理模式，即总公司下设立了分布各地的下属分公司，这种模式不仅是现代企业顺应业务进展和市场要求的选择，而且也是实行区
域差异化进展的基础，再次网络技术和并行处理技术的进展也为数据仓库技术进展提供了空间，由此催生了分布式数据仓库应用架构。分布式数据仓库应用架构是由总分数据仓库结构组成，分部数据仓库储备对局部决策有意义的数据，总部数据仓库储备对全局有意义的数据。它将从局部数据仓库和总部的操作环境中抽取数据。
第五章 数据仓库实现
5.1 ODS层建设
ODS层是一个面向主题的、集成的、可变的、当前的细节数据层,负责对接口进行抽取，该层更多的存在详单，是动态实时变化的，数据整合层一样是指构建ODS （Operational Data Store，操作性数据储备区）的过程，有些构建过程中可能会做成Stage+ODS； 数据整合层是整个系统中数据的统一入口，能够说是为数据仓库提供数据预备的工作区,经常被作为数据仓库的数据处理的过渡，以降低直截了当进行数据处理的复杂度。
5.1.1 接口数据抽取
接口数据抽取确实是依照数据仓库系统数据模型的需求，从相应的业务系统、外数据源等中抽取需要的数据。抽取出来的数据需要通过转换，采取同步或异步的方式加载到数据仓库系统中，来满足总部数据的统一规范。源数据接口要紧分析数据仓库的数据来源，包括源数据系统平台、结构等。典型的源数据接口包括数据库接口(ODBC、 OLEDB、专用数据库驱动接口)和文件接口。关于不同平台、不同形式、不同业务以及不同数据量的源数据，将采取不同的数据抽取接口。
在数据抽取时需要重点考虑数据抽取的效率。对数据抽取接口的选择必须重点考虑数据平台、源数据形式、业务系统的性能要求以及业务量和数据量大小。依照抽取的源数据形式，选择数据抽取接口的原则建议为以下几点：
关于数据形式为关系型数据库的系统，建议采纳ODBC、OLEDB或专用数据库
驱动接口方式。
关于数据形式是文件方式的源数据，一样直截了当进入转换和加载流程。 关于业务系统性能要求较高、业务量大、不能阻碍系统性能的系统，一样应
当采纳高性能的数据抽取接口，比如：专用数据库驱动接口、OLEDB接口等。 关于数据量专门大的业务系统数据的抽取，必须采纳高效率的数据接口，比
如专用的API接口，进行编程。
鉴于通信行业的源数据具有数据量专门大、业务系统工作负荷重和业务系统性能实时性的要求较高的特点，建议关于移动数据抽取接口一样情形下采纳专用数据库驱动接口，必要的时候采纳API接口编程实现数据的抽取，以提高数据抽
取效率同时减少对业务系统的性能的阻碍。下图为ODS加工流程
图5-1 ODS加工流程
5.1.2 数据抽取策略
数据的抽取必须能够充分满足数据仓库系统分析及决策支持的需要，同时必须保证不能阻碍业务系统的性能，因此进行数据抽取时必须充分考虑这些因素，制定相应的策略。就抽取数据的时效性而言，包括增量抽取、完全抽取等方式。增量抽取即每次只抽取自上次数据抽取以来产生的增量数据。增量抽取的优点是抽取的数据量小，从而转换和加载的数据量也小，能够极大提高数据加载性能。
完全抽取是抽取业务系统中指定业务的所有数据，建议在两种情形下采纳完全抽取方式：
数据量专门小，采纳完全抽取方式性能更高时； 无法分离出增量数据时。
数据抽取的时机，必须尽可能躲开业务系统的高峰时段，联通通常在00:00-03:00对数据进行抽取。关于通信业务系统的数据抽取，计费、账务等数据采纳增量抽取；关于营业系统，比如客户信息的变动等，则提供增量信息，假如只能够采纳完全抽取，然后在数据仓库系统中进行处理的方法。关于其他的业务系统，由于数据量相对比较小，能够依照实际情形制定相应的数据抽取策略。
5.1.3 ODS层的作用
(1)快速接收数据采集过程传过来的大量数据，缩短数据采集时刻，减少数据采集对应用系统的冲击；
(2)实现对跨系统、多数据源的统一数据采集，提高了采集数据的可靠性和一致性；
(3)所有文本式的数据，应先在整合层集中，再作后续处理；
(4)所有的数据后续处理，因为数据整合层，而统一了接口，降低了技术复杂性和网络不良等因素；
(5)数据整合层储存了要加载的数据，幸免了数据转换过程对数据源的直截了当操作，减少了对数据源的阻碍；
(6)当数据仓库中的数据转换出错或失败时，能够从数据整合层中再次抽取数据进行转换，而不必从数据源系统中抽取，减少的数据源系统的负载，也提高了系统的效率。
5.2 DWD层建设 5.2.1 DWD定义
DWD是数据仓库的细节数据层，为各种分析类应用提供细节性数据支持，是数据仓库的核心，同时为以后需求的扩展提供历史数据支持。
DWD层的模型设计，需要围绕企业核心业务过程展开，关注业务过程中的核心业务事件和业务实体，以企业级数据模型规范为指导，其数据域的划分遵从企业级数据模型域的划分。
5.2.2 实体选取的原则
原则1：业务过程中的核心事件实体及相关维度，长期沉淀，如：通话详单、缴费等
原则2：业务过程中的核心业务实体及相关维度，长期沉淀，如：客户、产品、订购实例、渠道等
原则3：业务过程中产生的可度量实体及相关维度，长期沉淀，如：帐单、佣金等。
原则4：面向处理流程的信息，不需要沉淀，如：出帐规则实体。
原则5：操纵流程类的信息，不需要沉淀，如：审批过程类信息。
5.2.3 字段选取的原则
原则1：删除与规则相关的字段。如：删除 订购实例信用额度 实体 中 信用评估规则标识 字段。
原则2：增加和分析相关的属性或集团统一编码。如：用户资料，增加用户归属片区等属性，渠道资料，增加集团统一渠道标识。
原则3：增加时刻戳或时刻拉链字段：针对不同类型数据，考虑时刻处理方式。关于增量数据，直截了当增加时刻戳，如：通话详单类数据。关于全量数据，即可采纳时刻拉链（生效时刻和失效时刻），也可时刻戳方式，或者混合方式如：用户资料类数据。
5.2.4 数据转换
(1)数据转换的要紧功能
数据转换是指对从业务系统中抽取的源数据依照数据仓库系统模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证数据按要求装入数据仓库。假如显现以下缘故可能会使数据转换工作变得复杂： 源数据系统同数据仓库系统在模型上的差异性。
源数据系统平台不一致：数据仓库系统的数据源可能包括基于不同平台的数
据库的数据。
源数据结构的不一致：有些数据源由于历史的缘故，导致同一个表 在不同
的时期数据结构不一致。 源数据定义不规范导致错误数据。 对数据的约束不严格，导致无意义数据。 存在重复记录。
由于平台系统的不同，可能会存在大量的转码工作。
(2)数据转换技术和策略
依照实际情形，数据转换工作一样会在以下几个环节中具体实现： 在抽取过程中进行数据处理。
使用异步数据加载，以文件的方式处理。 在数据加载过程中进行数据处理。
进入数据仓库以后再进行数据处理。采纳在数据抽取过程中进行数据转换
时，必须考虑抽取的性能以及对业务系统性能的阻碍；采纳异步数据加载需要以文件方式处理时，必须充分考虑中间磁盘的储备量以及ETL 整个流程的和谐性工作和大量的非SQL语句的编程；采纳在数据加载过程中进行数据转换时，必须考虑加载性能；采纳先将数据装载到数据仓库后再处理时，必须考虑数据仓库引擎的海量数据处理能力。
(3)关于移动经营分析系统数据仓库的数据转换工作，建议分别采取如下策略：
关于数据量比较大的计费、账务等数据，其特点是数据比较规范，域的合法
性检查工作可不能太多，可能存在的工作确实是不同字段的重新组合、汇总等工作。能够采取将数据装载到数据仓库以后再进行数据的组合、汇总等处理工作。
关于营业系统中的开户等信息，由于历史缘故，各地点移动公司的该部分数
据在关键信息上可能会存在信息不全或部分信息不符合规则的问题，比如早期开户的开户信息可能缺少个人的差不多信息(性别、年龄、身份证号码等)、出生年月不准确、字段值不符合字段类型要求等，而这些信息关于用户的分析是极其重要的，专门是在进行多维分析时。因此必须采纳在抽取时以文件的方式进行数据的清洗、抽取、组合等转换工作。
关于其它如客户服务数据等，依照实际情形采纳相应的转换措施。
5.2.5 数据加载技术及策略
要紧加载技术：使用数据仓库引擎厂商提供的数据加载工具进行数据加载和通过数据仓库引擎厂商提供的API编程进行数据加载。在两种数据加载技术中，前一种关于开发人员来讲操作比较简便；后一种方法需要部分程序编写工作，但性能上可能会好一些。依照实际的系统及数据量情形进行权衡。数据加载策略要紧包括两方面的内容：加载周期及数据追加策略。
数据追加策略是指数据每次是如何向数据仓库系统中追加的。动态数据仓库是数据仓库系统以后的进展趋势，利用动态数据仓库能够实现数据仓库同业务系统的协同工作，将数据仓库系统的功能由战略制定扩展到战术实施。这就要求数据仓库中的数据必须同数据库中的数据保持同步。依照通信业务数据的实际情形，对不同业务系统采纳不同的加载周期，但必须保持同一时刻业务数据的完整性。关于营业系统数据，比如开户、账户修改、销户等信息，以及计费详单等信息，采纳每日加载一次或与业务系统信息周期同步；客户账务信息同出账周期同
步；其它信息依照具体情形，最好是采纳最小加载周期。
数据的追加策略能够依照数据的抽取策略以及业务规则来确定，一样建议采纳3种类型：直截了当追加、全部覆盖、更新追加。
(1)直截了当追加是指每次加载时直截了当将数据追加到目的表中。关于典型的流水数据，一样采纳此方法。关于详单信息、账务信息等采纳直截了当追加的方式。
(2)全部覆盖：这部分表抽取的本身确实是整个表的所有数据(包括当前和历史)，因此采纳整表覆盖方式。关于帐户信息，假如不能够提供增量数据，最好的方法确实是采纳全部覆盖的方式。
(3)更新追加：部分表需要连续记录业务的状态变化，需要通过当前的最新状态同历史状态数据进行比对，采纳更新追加的方式更新历史表。具体采取何种方式，需要综合考虑效率、业务实现等诸多因素。
5.3 DWA汇总层建设
业务事件：选取DWD层中需要进行汇总处理的核心业务事件。
数据粒度：依照选取的核心业务事件，确定事件中核心的业务实体ID,选取最细粒度的核心实体ID作为汇总最小数据粒度。
维度层次：梳理核心业务实体ID和分析相关的重要维度的可集合的维度层次。
集合度量：确定事实表中的可加性度量和基于实体信息的度量，作为汇总的集合度量。
图5-2 DWA汇总场景图
冗余设计：考虑查询性能和ETL加工性能，适量增加汇总维度的冗余。 汇总模型：通过对维度的限制和聚合，设计汇总数据模型。
DWA汇总层侧重轻度汇总，该部分围绕DWD层核心业务事件展开，保留到核心业务实体ID级、数据粒度由细变粗、选取常用维度、保留事件的业务度量，进行数据轻度汇总和沉淀。
5.4 DWA衍生层建设
DWA衍生层是围绕DWD层核心业务实体（个人客户、集团客户、产品、订购实例、产品、渠道等）进行信息衍生，将核心业务实体参与事件的信息属性化，由原先站在事件角度看问题转换为站在核心业务实体角度看问题，该部分与DWD层一同构成核心业务实体的统一数据视图。该层原则上依靠DWD层，关于生产型模型缺失的情形，又有应用需求的，在本层进行了补充，如首次通话时刻等。DWA层应该采纳反规范化冗余设计，快速支持数据访问和应用开发；DWA层只能保证相对稳固，随着分析需求的增加，需要进行不断扩展。
（1）DWA设计步骤 1、业务实体选 取 选取围绕DWD层核心业务实体，作为信息衍生 分析核心业务实体相关应用需求，确定围绕核心业务实体衍生的规则。 是否是对核心业务实体参与事件属性化衍生；是否是按照维度层次考虑查询性能和ETL加工性能，适量增加衍生维度的冗余。 通过对业务衍生规则梳理，设计衍生数据 2、衍生规则确定 3 、冗余设计考虑 4、衍生模型设计 图5-3 DWA设计图
图5-4 衍生信息表
图5-5 汇总信息表
第六章 数据仓库后期运维
6.1 数据仓库测试
数据仓库的测试实际上它与其它测试项目并无多大区别。差不多的系统分析和测试过程在那个地点仍旧有效。
6.1.1 分析源文件
在测试联通数据仓库部署时，通常都会有一份相关的说明文件。尽管这些文件关于创建差不多的测试策略专门有用，但经常会缺少一些关于测试开发与执行的详细资料。有时会有一些其它文件说明技术上的细节问题，即从源到目标的转化（source-to-target mappings）说明文件。这些文件详细说明了数据的来源、如何对数据进行操作，以及储备到哪里。假如能拿到这些文件，关于系统设计的文件在设计测试策略时也会变得更加有用。
6.1.2 开发策略和测试打算
分析了各种各样的源文件后，就要开始创建测试策略。从生命周期和质量的角度来看，增量测试是测试数据仓库的最好方法。这从本质上意味着从开发过程的早期开始，将各种小组件交付给测试人员。那个方法的要紧优点是幸免交付过大的组件，能够从早期开始检验缺陷，并使调试变得简单。此外，那个方法还有助于在开发与测试周期中建立详细的过程。具体到数据仓库测试，即是对数据猎取分段表，然后是增量表、差不多的历史表格、BI视图等的测试。
另一个制定数据仓库测试策略的要紧问题是基于分析（analysis-based）的测试方式和基于查询（analysis-based）的测试方式的选择。纯基于分析的方法是让测试分析师通过分析目标数据和相关标准运算出预期结果。基于查询的方法有相同的差不多分析步骤，但更进一步，用SQL查询语言编写预期结果。这为今后建立回来测试过程节约了专门大精力。假如测试是一次性的，那么用基于分析的方式就足够了，因为通常这种方式较快一些。反之，假如联通对回来测试有连续的需求，那么基于查询的方式会更为合适。
6.1.3 测试的开发与执行
测试的开发，要依照上行需求的稳固性和分析过程决定。假如情形变动比较频繁，那么早期进行的测试开发可能大部分都会被废弃。应该实时进行的整合的测试开发和执行过程通常会更有成效。在设计测试开发和执行过程的框架时，参考一下测试分类总是有用的。通常数据仓库的测试分类有： 记录计数（预期与实际对比） 副本记录 参考数据有效性 参照完整性 错误与专门逻辑 增量过程与历史过程 操纵栏值与默认值
除这些分类外，还能够参考缺陷分类学，比如Larry Greenfield的分类。 测试执行时，准确的状态报告过程是经常被忽略的一个方面。在确定团队里的其他人明白你的方法的前提下，测试分类和测试进度能够保证他们对测试状态也有一个清晰的概念。有了详细的规划并坚持到底，以及良好的沟通，就能建立一个数据仓库测试过程，取得中意的成果。
6.2 数据仓库后期爱护 6.2.1 数据仓库数据清理
数据仓库实际本身存在冗余，沉淀的更多是历史数据，为数据挖掘提供充足的数据量，用来支撑数据决策。但过多的数据会导致数据仓库性能下降，那个地点的数据要紧指脏数据，历史时刻过长沉淀数据，由于表空间大小有限，一味的扩展容量并非长久之策，需要对数据仓库进行定期清理。以联通为例，通常只保留当前3个月的数据，对更长时刻的数据进行清理，采纳自下而上的原则，删除底层数据，只保留上层的数据。
6.2.2 数据仓库模型更换
数据仓库建设完成后，理论上是不能轻易更换，但通常要依照联通的实时要求，进行模型的修改，如联通制定新接口时，需要手工对储备过程的接口来源表进行替换。当联通提出新的需求时，就要重新梳理数据仓库结构，建立新过程，来满足联通的需要。
6.3 数据仓库性能优化 6.3.1 调整数据库服务器的性能
Oracle数据库服务器是整个系统的核心，它的性能高低直截了当阻碍整个系统的性能，为了调整Oracle数据库服务器的性能，要紧从以下几个方面考虑：
调整操作系统以适合Oracle数据库服务器运行，Oracle数据库服务器专门大程度上依靠于运行服务器的操作系统，假如操作系统不能提供最好性能，那么不管如何调整，Oracle数据库服务器也无法发挥其应有的性能。 (1)为Oracle数据库服务器规划系统资源
据已有运算机可用资源， 规划分配给Oracle服务器资源原则是：尽可能使 Oracle服务器使用资源最大化，专门在Client/Server中尽量让服务器上所有资源都来运行Oracle服务。 (2)调整运算机系统中的内存配置
多数操作系统都用虚存来模拟运算机上更大的内存，它实际上是硬盘上的一定的磁盘空间。当实际的内存空间不能满足应用软件的要求时，操作系统就将用这部分的磁盘空间对内存中的信息进行页面替换，这将引起大量的磁盘I/O操作，使整个服务器的性能下降。为了幸免过多地使用虚存，应加大运算机的内存 (3)为Oracle数据库服务器设置操作系统进程优先级
不要在操作系统中调整Oracle进程的优先级，因为在Oracle数据库系统中，所有的后台和前台数据库服务器进程执行的是同等重要的工作，需要同等的优先级。因此在安装时，让所有的数据库服务器进程都使用缺省的优先级运行。
6.3.2 调整内存分配
Oracle数据库服务器保留3个差不多的内存高速缓存，分别对应3种不同类型的数据：库高速缓存，字典高速缓存和缓冲区高速缓存。库高速缓存和字典
高速缓存一起构成共享池，共享池再加上缓冲区高速缓存便构成了系统全程区(SGA)。SGA是对数据库数据进行快速访问的一个系统全程区，若SGA本身需要频繁地进行开释、分配，则不能达到快速访问数据的目的，因此应把SGA放在主存中，不要放在虚拟内存中。内存的调整要紧是指调整组成SGA的内存结构的大小来提高系统性能，由于Oracle数据库服务器的内存结构需求与应用紧密相关，因此内存结构的调整应在磁盘I/O调整之前进行。 (1)库缓冲区的调整
库缓冲区中包含私用和共享SQL和PL/SQL区，通过比较库缓冲区的命中率 决定它的大小。要调整库缓冲区，必须第一了解该库缓冲区的活动情形，库缓冲区的活动统计信息保留在动态性能表v$librarycache数据字典中，可通过查询该表来了解其活动情形，以决定如何调整。 (2)数据字典缓冲区的调整
数据字典缓冲区包含了有关数据库的结构、用户、实体信息。数据字典的命中率，对系统性能阻碍极大。数据字典缓冲区的使用情形记录在动态性能表v$librarycache中，可通过查询该表来了解其活动情形，以决定如何调整。 (3)缓冲区高速缓存的调整
用户进程所存取的所有数据差不多上通过缓冲区高速缓存来存取，因此该部分的命中率，对性能至关重要。缓冲区高速缓存的使用情形记录在动态性能表v$sysstat中，可通过查询该表来了解其活动情形，以决定如何调整。
6.3.3 使用ORACLE的数据完整性约束
当为应用建表时，应当为一些有专门要求的数据加上适当的完整性约束，如此就能实现由数据库本身而不是应用程序来约束数据符合一定的条件。数据库服务器端的完整约束的执行操作是在比SQL语句级别更低的系统机制上优化，它与客户端无关，只在服务器中运行，不需在Client 端和Server端之间传递SQL语句，有效地减轻网络I/O负担。
6.3.4 使用数据库触发器
完整约束性只能实现一些较简单的数据约束条件，对一些较复杂的事物处理规则就无能为力，这时最好不要在应用程序中实施复杂的程序操纵，而是应当采纳数据库触发器来实施复杂的事物规则。数据库触发器能实现由数据库本身，而不是应用程序，来约束数据符合复杂的事物处理规则，同时容易创建，便于治理，幸免大量的网络I/O。
6.3.5 使用储备过程
Oracle的储备过程和储备函数是命名的能完成一定功能同时储备在Server端的PL/SQL的集合。包是一种把有关的过程和函数组织封装成一个数据库程序单元的方法。它们相关于应用程序的过程、函数而言，把SQL命令储备在Server端。使用储备过程和储备函数，应用程序不必再包含多个网络操作的SQL语句去执行数据库服务器操作，而是简单调用储备过程和储备函数，在网络上传输的只是调用过程的名字和输出结果，如此就可减少大量的网络I/O。
6.3.6 应用程序调整
（1）SQL语句的优化
SQL语句的执行速度，能够受专门多因素的阻碍而变化。但要紧的阻碍因素是：驱动表、执行操作的先后顺序和索引的运用。能够由专门多不同的方法间接地改变这些因素，以达到最优的执行速度。那个地点要紧探讨当对多个表进行连接查询时应遵循的优化原则。
（2）建立和使用视图、索引
利用视图能够将基表中的列或行进行裁减、隐藏一部分数据，同时能够将涉 及到多个表的复杂查询以视图的方式给出，使应用程序开发简洁快速。利用索引能够提高查询性能，减少磁盘 I/O，优化对数据表的查询，加速SQL语句的执行。但任何时候建立索引都能提高性能，何时建立索引应当遵循以下原则：该表常用来在索引列上查询，该表不常更新、插入、删除等操作，查询出来的结果记录数应操纵在原表的2%～4%。
（3）使用 Oracle 的数组接口
当一个客户应用程序插入一行或用一个查询来向服务器要求某行时，不是发 送具有单个行的网络包，而是采纳数组处理，即把要插入的多个行或检索出的多个行缓冲在数组中，然后通过专门少的几个包就可在网上传送这些数组。例如，一个给定的Select语句返回2000行数据，每行平均大小为40个字节，数据包的大小为4kB，而数组大小参数(arraysize)设置为20 ，则需从服务器发送100个数据包到客户机。假如简单地把(arraysize)设置为2000，那么同样的操作只需要传送 20个数据包。如此就减少了网络的传输量，提高了所有应用的性能。
总结
通过开发数据仓库，我更加系统全面的把握了ORACLE体系结构和数据仓库的差不多知识和编程技巧，并在开发数据仓库过程中使我的建模和开发能力得到了进一步的提高。对储备过程的明白得有了更加深刻的认识。
在建设数据仓库的过程中我学到：数据模型建立的好坏将决定着的数据仓库的高可用性，良好的需求分析将是成功开发的前提。在进行数据仓库建立前，应该用充足的时刻去把需求分析做好，反复校验数据仓库模型，写出相关的开发文档等。然后再开始编写过程和一系列的建表，如此在前期基础扎实的情形下，进行数据仓库的具体开发，会更加得心应手。
此外，我认为，在这次设计数据仓库中遇到了一些问题。问题要紧存在于对数据仓库分层和分域的明白得，在通过学习和借鉴书籍资料，也慢慢克服了这些困难，使自己有了更为全面的认识。
因此，数据仓库本身也有一些不足之处，我也会虚心学习，不断完善，争取更上一层楼。
致谢
在此论文撰写过程中，曾遇到过许多的困难，都在老师和同学们的关心下，使自己对数据仓库有了更深的明白得。专门要强烈感谢我的论文指导老师——王亮老师，他对我进行了无私的指导和关心，不厌其烦的关心进行论文的修改和改进。在此表示最衷心的感谢！
参考文献
[1]杨森,王翰虎;面向主题的数据仓库体系结构[J];运算机应用;2007年S1期
[2]刘丽芳;商业数据仓库系统的设计与实施[D];北京工业大学;2005年 [3]李侃;基于数据仓库的决策支持系统的开发与应用[J];大连大学学报;2010年06期
[4]熊忠阳,张玉芳,吴中福;数据仓库数据加载技术[J];重庆大学学报(自然科学版);2010年02期
[5]黄梯云，运算机基础知识及治理信息系统．北京：中国经济出版社，2006 [6]王海亮，林立新;ORACLE10g PL/SQL编程.中国水利水电出版社,2010 [7]盖国强;深入浅出Oracle—DBA入门、进阶与诊断案例.中国邮电出版社,2020
[8]谭怀远;让Oracle跑的更快：Oracle10g性能分析与优化思路.电子工业出版社,2011
[9]徐玉金;SQL性能的调整.清华大学出版社,2020 [10]张家宏;ORACLE分析函数.北京大学.2020
因篇幅问题不能全部显示，请点此查看更多更全内容