您好,欢迎来到华拓网。
搜索
您的当前位置:首页第三章 数据仓库设计

第三章 数据仓库设计

来源:华拓网
第三章 数据仓库设计

DW设计是一个操作型系统设计方法演变而来的范例。DW设计者不仅要设计一个数据库(DW用DB实现)和一个用户接口(数据展现部分)。而且还必须设计数据与OLTP系统的接口,数据装载策略,数据存取工具,用户培训方案和不间断的维护方案。即必须考虑许多在操作型系统设计中不必考虑的问题。本章的意图就是帮助你完善的理解如何建立和实现DW和在一个完整的DW设计必须考虑的问题。 我们要设计DW,首先要了解他的开发生命周期。

1 2 3 4 5 6 7 ------------需求驱动

传统的 收集 分析 设计 编程 调试 集成 实现 SDLC 需求

DW的 实现DW 集成数据 检验偏差 针对数据编程 设计DSS系

统 分析结果 理解需求 SDLC

---------------- 数据驱动

3.1 数据仓库开发的方法

建立一个DW一般需做以下五个方面的工作: 1、任务和环境的评估。 2、需求的收集和分析。 3、构造DW。

4、DW技术的培训。

5、回顾、总结和再发展。 一、 任务和环境的评估

1、目标:因为数据仓库是建立在原有的运行系统之上的,因此要结合单位的现状来明确数据仓库的目标任务。了解数据源所在系统和其中数据的状况、数据类型、工作平台、数据量、数据质量、DW的环境、网络技术状况。 2、目的: ⑴ 看DW的任务是否可行。

⑵ 所建立的DW是否是用户所期望的。 ⑶ 有没有不逾越的障碍。

⑷ 确定DW系统成功与否的基本原则。

3、组织:高层负责人参加并组织项目组。 人员:项目总负责人

与DW相关的业务部门负责人 计算机软/硬件负责人 DBA 网络人员

4、项目组的任务:初步确定主题 主题的层次结构 二、 需求的收集和分析。

1、任务: ⑴ 了解决策者现在的工作目标。

1

⑵ 现在获得决策支持信息的方法、渠道。 ⑶ 和竞争对手的差距。

⑷ 决策者希望DW提供什么。 ⑸ 制定系统的逻辑模型。

⑹ 分析数据源的物理存储状况、运行平台、数据质量、硬件、软件和网络的

限制条件。

2、分析文档。 ⑴项目概述。

⑵差距分析。

⑶系统基本架构图示。 ⑷逻辑模型。 ⑸物理模型。

⑹DW的初始装载和更新策略。 ⑺ DW的运行计划。

⑻决策信息展现的希望和需求。 ⑼ DW建成的时限。 三、 构造DW

构造数据仓库包括数据仓库的管理、数据仓库的组织和决策支持信息的展现三部分。

设计和编写数据抽取程序/工具。 设计和编写数据转换程序/工具。 1、DW的管理 设计和编写数据更新程序/工具。 设计和编写运行的接口程序。

建立这一阶段的所有管理的数据(元数据) 程序统一标准命名、建档。

初始装载 建立索引 2、DW的组织 建立数据视图

DW及工作平台的安全检查 装入数据和应用功能

建立此阶段的元数据。

3、决策支持信息的展现

利用多维数据展现、数据挖掘等一些工具可预先制作好许多常规的信息市场项目供支持决策使用,也可以直接操作主题数据以得出新的决策支持信息。 四、 数据仓库技术的培训。

培训内容:1、DW中的数据内容(包括逻辑模型、物理模型)、数据质量。 2、元数据的内容、位置,如何使用。 3、用户界面和功能介绍。

4、数据更新计划。 5、DW的安全规则。

6、从OLTP到DW的数据流。 7、全部的数据转换工作。

2

8、数据装载和更新的策略。

五、 回顾、总结和再发展。 1、哪些地方可以做得更好。

2、业务部门对开发的支持是否到位。 3、双方如何合作得更好。

4、什么是业务部门立竿见影的效益。 5、主题选择是否得当。

6、阶段成果是什么?反映如何?

7、DW采用是否提高了公司的竞争力。 8、投资回报率是否达到预计的水平。

六、 SAS数据仓库方法论 见图3-1 评 估

主要数据模型和DW 主题的选

择 需求调查

总 结

设 计 设计DW结构、数据建摸、过

程建摸

构 建 物理的DW 组装、应用程序编

码,测试、验收、

部 署 把DW展示给业务用户,培训。

图 3-1 SAS数据仓库方法论

总结:1、总结早期项目实施成功和失败的经验和公布以后努力的结果。

2、应用配置是否如愿实现,如有必要须调整计划。 3、评估项目对单位的影响和得益。

3.2 数据仓库的技术体系结构

DWS的技术体系结构如图3-2所示

3

外部数据 数据管理员模块 DW的数据 数据传递模块 数据获取模块 中间件模块 数据访问模块 数据源 设计模块 信息目录模块 DW的元数据 外部元数据 管 理 模 块 图3-2 DataBase Association 公司定义的DW技术体系结构

一、 设计模块

功能:是由DW的设计者和管理者来设计和定义的DW的。在设计DW时必须考虑到的其他因素还包括DB和瞬时数据的处理。某些DW数据库还包括星型模型的非规范化DB设计。 二、 数据获取模块

功能:用于开发和运行数据获取应用程序,从源系统中获取数据并加到DW中。 内容:1、数据抽取规则——界定数据源。

2、数据情况——记录和字段的重组,增补丢失的字段值,数据的整性和一致

性检查。

3、数据增强——字段值的解码和转换,增加时间属性(若没有),数据的概括或者衍生值的计算。 4、数据传输。

5、生成的定义作为元数据存入信息目录模块。

三、 数据管理员模块。

功能:是DW用来生成、管理和访问仓库中数据(很可能还有元数据)的模块。一般

使用RDBMS或MDBMS(多维DBMS)。

四、 管理模块。

4

功能:完成维护DW环境的系统管理服务。 内容:1、管理数据获取操作。 2、仓库数据归档。 3、仓库数据备份。 4、仓库数据恢复。

5、访问DW的安全及授权等。 五、 信息目录模块

功能:帮助技术用户和业务用户访问DWS,通过一套维护和观察仓库元数据的工具实

现这一功能。

主要元素:1、源数据管理员:维护、输入/出仓库元数据。 2、技术元数据。

3、信息助理:为最终用户提供访问元数据的简单方法,有些产品能帮助用

户产生、编写、运行查询、报表、分析并预定仓库中找不到数据和信息。

六、 数据访问模块

功能:提供访问工具,使用户访问和分析仓库中的数据。 访问工具:1、查询、报表自动生成和数据分析工具。 2、能访问RDBMS的多维分析工具。 3、能访问MDBMS的多维分析工具。

4、运行4GL或可视化程序设计语言的DSS应用程序开发工具。 七、 中间件模块

功能:将DW数据与最终用户工具连接起来,专门中间件:

①智能数据仓库中间件——位用户提供从业务角度、数据仓库的视角;并能监视和跟踪对DW的访问情况。

②分析服务器——能改善对RDBMS数据进行多维分析的效果。

八、 数据传递模块

功能:将数据集合分布到其他DW和最终用户产品中,如电子报表。数据的传递可以在一天中的某一时刻进行,也可以在一个外部事件结束时进行。

3.3数据仓库和数据模型

数据仓库的设计和OLTP系统的设计一样,也需要先进行模型的设计。

一、 不同层次模型之间的关系.。

1、 企业数据模型:特点:只包含原始数据。OLTP、DW的数据模型均源于企业模型。 2、 操作型数据模型

特点:①基本等价于企业数据模型。②在数据库设计之前要加入性能因素。 3、 DW数据模型。

特点:①去掉纯操作性数据。

②给键码增加时间因素 ③合适之出增加导出数据

④把OLTP系统中数据关系变为人工关系。

4、稳定性分析:根据各个属性的变化特征将这些属性分组(例如按更改频率)。就把原始数据一个表分成多表,完成数据聚集。 二、 数据模型

5

数据模型的级别:

OLTP:概念模型 逻辑模型 物理模型 DW: 高层模型 中间层模型 底层模型 1、 高层建模:实体关系表示方法(ERD)

高层建模的特点是实体和关系,如图3-3所示。实体的名字放在椭圆内,实体间的关系用箭头描述。箭头的方向和数量表示关系的基数,只有直接的关系才标示。

一个实体或者主要主体

1:n 的关系 1:1的关系 n:1的关系

零件 供应商 订单 装配 图3-3 实体关系图

在ERD层的实体位于最高抽象层,那些实体属于模型的范畴,那些不属于,应该有集成范围定义数据模型的边界。而且集成范围需要在建摸之前进行定义。

企业RED由很多反映了整个企业不同人员的不同观点的单个RED合成的。集成的方法可以参照数据库设计时的局部ERD 向 全局ERD 集成的方法。所以,建立企业ERD的方法是: 方法:① 首先在建模之前定义数据模型的边界

② 先建立企业内部不同群体的高层数据模型,然后进行集成组成企业的ERD. 2.中间层数据模型(DIS----Data Item Set 数据项集)

对高层模型中标识的每个主要的主题域或实体都要建一个中间层模型(DIS可称为逻辑模型,它是对ERD的细分), ① DIS和ERD的关系

6

DIS DIS ERD DIS DIS 图 3-4 DIS和ERD的关系 ERD中的每一个实体将来都会被他的DIS所定义 ② DIS的构造

初始数据组-----初始数据组对每个主要主题域存在且只存在一次,它有在每个主要主题域只出现一次的属性,初始数据组有属性和键码

二次数据组-----有对每个主要主题域可以存在多次的属性,从初始数据组有一链接指向二次数据组有多少个可以出现多次的不同数据组,就含有多少个二级数据组。 连接数据组

用于本组主题域与其它主要主题域之间的联系,体现了ERD中实体间的关系,它将数据从一个实体与另一个实体联系起来。

一般情况下,连接数据组往往是一个主题的公共码主键,从而建立了两个主题域间的相互联系。

类型数据组-----指出数据的类型

数据的类型由指向右边的不同数据组组成,主要有左边的超类型数据组和右边的子类型数据组。

逻辑模型的基本结构由图3-5所示

基本数据组 超类型 子类型 连接数据组 二次数据组 连接数据组 图3-5 逻辑模型的基本结构 ③ 数据组的稳定性

基本数据组稳定性大于初始数据组,初始数据组的稳定性大于类型数据组 ④ 逻辑模型示例:见图6-6

7

账号 账号 账号 地址 抵押 姓名 信用额度 委托人 贷款 利息 评估 性别 开户时间 账号 账号 省 账号 时间 市 最小存款 制造商 最小余额 型号 县 街道 邮政编码 非抵账号 账号 押贷信用卡类型 客户编号 责任人 款 信用卡限额 种类

图 3-6 逻辑模型示例图 在图3-6中,其客户名称、性别和开户时间等有关客户固定描述信息的数据项内容是基本不变的,所以他们可列入基本数据组。

客户的地址、文化程度、电话等虽然基本稳定,但是存在改变的可能性,因而列入二级数据组;

客户的贷款、存款情况、担保以及信用卡消费记录是频繁变动的数据项,故列入类型数剧组。

逻辑模型为DW开发者与使用者相互之间在进行DW开发时的交流与讨论的工具。 逻辑模型设计时,应保证DW中的所有元素包含在数据模型中。 3. 物理数据模型

逻辑模型可采用星型模型和雪花模型,主要是设计事实表、维表。 物理数据模型是依据中间层的逻辑数据模型创建的,他通过确定模型的键码属性和模型的

物理特性,扩展中间层模型而建立的,物理数据模型就由一系列表所构成,其中最主要的是事实表模型和维表模型,另外根据性能要求,对有关表模型进行调整,并确定有关的索引设置。

[1 ]事实表模型设计

以图3-6的金融企业客户主体逻辑模型可以设计出下面的事实表模型 客户事实表

客户基本情况表(账号,姓名,出生地,开户时间…) 客户变动情况表(账号,省,市,县,街道,邮编…) 客户贷款事实表

客户房屋贷款事实表(账号,地址,委托人,评估...) 客户汽车贷款事实表(账号,时间,制造商,型号...) 客户存款事实表

客户存款表1(账号,时间,最小存款数,最小余额...)

8

客户存款表2(账号,时间,最小存款数,最小余额..) 客户担保事实表

客户担保事实表1(账号,时间,责任人,种类,担保余额....)

事实表是DW中的最大表,在设计时,一定注意使事实表尽可能的小,因为过大的事实表在表的处理、备份和恢复、用户查询等方面要用较长时间。

减少事实表大小的方法: ① 减少列的数量 ② 降低每列的大小 ③ 把历史数据归档 ④ 对行进行分割 [2] 维模型设计

维表模型也需要根据逻辑模型设计,维度表的属性必须具有以下特征: ①可用文字描述 ②有规定的限制(约束)

③属性取离散值 ④在分析中可提供行标题

最常用的维表应该直接参考事实表,而不应间接。这种方法可以最小化表的连接数量,提高系统的性能。 客户主体维度表模型

时间维度表(年,月,日)

地点维度表(省,市,县,街道) 贷款维度表(抵押贷款,非抵押贷款) 维属性就是用户获取数据的窗口 [3]. DW物理模型的性能问题 提高DW性能的技术 合并表

把需连接的几个表的记录合并成一个表,物理的放在一起. 建立数据序列

经常按某个固定顺序访问并处理一组数据记录,可严格按顺序存放到一个或几个连续的物理块中. 引入冗余

进行关系规范化的逆操作,即反规范化的处理 引入冗余和合并表的区别

合并表示将两个或多个相关表的相关记录物理上放在一起,但逻辑上不变,仍是多表,没改变多表的关系模式,且合并表只是对表记录的存取策略的改进,并没有冗余的数据.

引入冗余则是对表的关系模式的改变.把原来规范化的表,变成有数据冗余的规范化级别低的表。

表的物理分割

分割依据 : 存取频率

数据的稳定性 生成导出数据

事先在原始数据上进行汇总或计算,生成导出数据。 优点:

◆ 减少I/O次数; ◆ 免去计算汇总步骤;

9

◆ 避免不同用户重复计算可能产生的误差

建立广义索引

DW中的数据量巨大,要依靠各种各样的索引技术来提高设计大数据量的查询的速度。在向DW装载数据时,就根据用户的需求建立\"广义索引\"概要文件,最大宗的购买,不活跃的用户,最近的发货等. 4.数据模型和反复开发 ①反复开发的理由:

* 业界成功的记录强烈的建议这样做

* 最终用户在完成第一遍之前不能明白的提出需求

* 只有实际结果切实而且明确时,管理部门才能做出充分的承诺 * 需要很快看到可视化结果 ②数据模型在反复开发中的作用

数据模型在每遍开发中起着路标的作用,因为所有的开发都是数据模型驱动的,每遍后续开发都是建立在前一遍开发的基础上,结果就是都在统一的数据模型上进行不同的开发,各遍开发的结果将产生一个内聚的高度和谐的整体.

如果没有数据模型,重复的开发不能构成一个内聚的模式,有许多重叠和缺乏一致性.

3.4 数据仓库的粒度设计

DW开发中最重要的设计问题之一是决定DW的粒度,如果粒度设计恰当,则DW其他方面的设计和实现就较容易,它是体系结构设计环境成功的关键.

粒度级别的选择主要是对管理多大数据量和使用数据单元详细程度的一种处理,数据越详细,粒度越小,级别就越低;粒度越大,数据汇总级别就高.

在本节介绍利用量纲分级和反馈技术确定粒度的方法和相关原则. 一、粒度确定

1.粗略估计

要确定合适的粒度级,首先要粗略估算DW中将来的数据量和所需的直接存取设备

数(DASD)

其步骤如下:

第一步:对每一个已知的表

计算一个记录所占字节数的最大、最小值(按字节算) 对一年内:可能的最大最小记录数 对五年内:可能的最大最小记录数 对每个表的关键字大小(字节数)

一年总的最大空间=最大记录所占空间*一年内最大记录数 一年总的最小空间=最小记录所占空间*一年内最小记录数 累加索引空间

第二步:对所有已知的表重复第一步 粗略数据估计完后,就要计算一下索引所占的空间,对每张表确定关键字的长度和原始表中是否每个记录都存在关键字。

数据量估计的上限和下限就等于记录的最高估计数和最小估计数分别乘以记录的最大、最小长度再加上索引次数乘以索引的长度。 2. 粒度划分过程的输入

10

根据空间估算的结果,可将估计的记录数和DASD数作为粒度划分过程的输入,与粒度的阈值进行比较,看是应该采用那种粒度。

表3-1 粒度阈值表 一年期 五年期 10,000,000 双重粒度级且认真设计 20,000,000 双重粒度级且认真设计 1,000,000 双重粒度级 10,000,000 双重粒度级 100,000 认真设计 1,000,000 认真设计 10,000 实际上任何设计都行 100,000实际上任何设计都行 表中的数据为记录数 对于五年期,行的总数大致以数量级改变。 对五年以后的推测:

① 在管理DW中的大量数据时,将有更多的专门技术可用。 ② 硬件费用有所下降

③ 可以使用更强大的软件工具 ④ 最终用户更加专业化

在分析时只考虑到DW中的记录数,而没有考虑总字节数,因为不管记录的字节长短,索引项的数量是没有变化的,因此被索引的记录的实际大小才影响决定DW是否采用双粒度级策略。

3.确定粒度级别

完成简单查询分析之后,就要确定粒度级别。基本方法:

① 猜测一个粒度(凭直觉、经验) ② 设计、载入数据到DW ③ 让DSS分析员看到数据 如不合理重复上述步骤。 最终用户的态度:“既然我看到了我能够做些什么,我就能告诉你什么是真正有用的。” 4.反馈循环的技巧 <1> 反馈循环技巧

① 用很小而很快的步伐建立DW的最初几个部分,仔细听取用户的意见,随时准备调整。 ② 使用原型法,并使用从原型中收集的观察结果而使反馈循环起作用 ③ 学习别人确定粒度的经验 ④ 与用户一起进行反馈处理

⑤ 看看本机构现在有了什么在运转

⑥ 进行联合应用程序设计会议,并模拟其输出已得到想要的反馈。 <2> 提高数据粒度的方法

① 当源数据置入DW时,对它进行汇总;

② 当源数据置入DW时,对它求平均或进行计算;

③ 把最大/最小的设定值置入DW; ④ 只把显然需要的数据置入DW;

⑤ 用条件逻辑选取记录的一个子集置入DW;

经验规则:在第一次的设计周期中,如果50%的工作是正确的,则整个设计就是成功的。 5.粒度划分学例

① 银行环境

操作型环境中约60天的业务数据

由于其信息量较大,设计成双重粒度级。

11

在DW中: ◆轻度汇总存十年的每月汇总的账户信息 ◆当前细节级数据存30天

在这个级别并不是把OLTP系统中所有的字段都送到DW中,只有对分析有价值的信息字段才被存储。

30天之后,把这部分细节数据送到磁带上,腾出的空间存放下一个30天的当前细节级数据。 ② 制造业环境

OLTP系统中存放的是订单,由于量少,设计成单粒度,只要轻度综合,不要当前细节级。DW中存放10年的订单历史。

3.5 数据仓库开发

数据仓库的开发是一个基于不断循环、逐步增长的生命周期模式,是一个用户和开发人员对其不断了解、熟悉和完善的过程。

本节提供可以用来指导开发数据仓库技术的准则。可以把它当作一个框架,来展示不同类型DW 项目的定制方法。框架中的每一重大步骤都与实践联系紧密。除了提供方法之外,还指出每一步骤需要注意什么。 一、 数据模型分析

前序的活动:承担数据仓库建设的任务 后继的活动:主题领域分析,“面包箱”分析,数据仓库设计 估计时间:差别很大,取决于数据模型的状态和质量 通常执行一次还是多次:一次 1、 数据模型的要求 (开始时要定义一个数据模型)

(1) 标示主要主题领域;

1

(2) 清晰地定义模型的边界; (3) 把原始数据和导出数据分离; (4) 每个主题领域需要标识;

<I> 键码 <II>属性

<III>属性分组

<IV>属性分组之间的关系 <V>多重出现的数据 <VI>数据的类型

这个步骤的输出是对机构已经建立了一个可靠的数据模型的确认,如果模型没有满足指定的校准,那么进程就应该停止直至达到质量校准。((1)体现此步的重要性;(2)指出该部没完成应该怎么办。)

2、 数据模型成功的标志:

(1) 主要主题领域的标识;

(2) 每个主要主题有自己的独立的定义,包括: <I>数据的子类型

<II>数据的属性

<III>清晰地定义数据的关系 <IV>定义数据分组

12

<V>定义键码——所有的DSS数据都有自己随时间变化的键码

二、“面包箱”分析

前序的活动:数据模型分析 后继的活动:数据仓库数据库设计

估计时间:从一天到两周不等,取决于范围定义得是否好,数据模型定义得是否好等。 通常执行一次还是多次:一次。 可以提交:粒度分析。

功能:通过粗略估计确定DSS环境的规模。――即知道DW要处理多少数据 目的:根据DW中的数据确定粒度设计。 成功的因素:

1、对整个DW环境的数据量的估计;

一年~五年;

2、如果需要多层粒度,输出多层粒度定义。 三、技术评价

前序的活动:承担数据仓库建设的任务 后继的活动:技术环境准备 估计时间:一周

通常执行一次还是多次:一次 可以提交:技术环境评价。

该阶段的任务是根据数据仓库建设所必备的条件,评价目前开发组人员的技术水平。 成功的因素:

1、管理大量数据的能力; 2、允许灵活访问数据的能力; 3、根据数据模型组织数据的能力;

4、能够用许多技术接受和发送数据的能力; 5、能够周期地把数据全部加载的能力;

6、 能够以一次一个集合或一次一个记录的方式访问数据的能力; 四、技术环境准备

前序的活动:技术评价

后继的活动:数据仓库设计、载入。 估计时间:一周到一个月。 通常执行一次还是多次:一次

该阶段的任务是:选择实现DW的软/硬件资源、开发平台、DBMS网络、开发工具......

2

当DW的体系结构配置已经建立,下一步就是技术上确定如何实现这个配置。 1、要考虑的典型问题是:

(1) 需求DASD(Direct Access Storage Disk,直接存取存储设备)的数量; (2) 需要什么链路――通过网络或进入网络; (3) 预期的处理量;

(4) 如何使竞争的存取程序之间的处理冲突达到最小限度或减轻这种冲突; (5) 由控制DW的技术产生的通信量;

(6) 由控制DW的技术产生的通信量的性质——或长或短的爆发。

13

2、成功的因素:

这个步骤正确执行后,成功的路上就不会有技术的阻碍了。 接收数据的技术部件,准备就绪: (1) 网络; (2) DASD;

(3) 管理DASD的操作系统; (4) 出入DW的接口; (5) 管理DW的软件; (6) DW。 五、主题领域分析

前序的活动:数据模型分析 后继的活动:源系统分析 估计时间:一天

通常执行一次还是多次:每个载入工程一次。 可以提交:下一个要建造哪个主题。。

1、 主题领域――围绕一个主题的工作范围、内容。第一个选择的主题领域必须大到足

以有意义,而又小到可以实现。

如果有时某个主题领域确实大而且复杂,那么应该选择它的子集实现。 2、 内容:

(1) 给出主题域范围――有什么? (2) 所需的细节水平; (3) 生成初步概括表。 3、 成功的因素:

最初选择小的主题;

后来选择大的主题,甚至是主题的子集。

选择的载入主题适合开发DW的当前阶段的需要。 此阶段将主题域模型化、规范化。 六.DW设计

前序的活动:数据模型分析、源系统分析、“面包箱分析”。 后继的活动:程序规范说明 估计时间:一周到三周。 通常执行一次还是多次:一次

可以提交:数据仓库的物理数据库的设计。。

1、任务:DW的物理数据库设计。

2、内容:DW是基于数据模型设计的。其主要设计内容有:

(1) 域表;

(2) 概括表——可能成为业务度量的最常用的维; (3) 星型连接和事实表; (4) 建立索引; (5) 备份和恢复。 3、设计特性:

(1) 如果确实需要多层粒度,要做好不同层次粒度的调节;

14

(2) 把数据定向到公司的主要主题; (3) 只出现原始数据和公共的导出数据; (4) 不存在非DSS数据;

(5) 每个数据纪录的时间变化量; (6) 在适宜的场合物理反规范化数据;

(7) 在把操作型环境中的数据引入到DW的地方创建人工数据。 4、成功的因素:

这个步骤成功执行后,其结果是一个具有一定数量数据的DW,这些数据可以用相当有效的方式加载、访问和搜索。 七、源系统分析――确定数据从何而来

前序的活动:主题领域分析

后继的活动:程序规范说明,数据仓库设计。 估计时间:每个主题领域一周。 通常执行一次还是多次:一次 可以提交:记录系统的标示。

1、功能:

从现有的系统环境中为主题标识数据,产生从操作型环境到DSS环境的 映射。 2、内容:

(1) 要列出可能成为数据源的系统或文件——筛选;

(2) 确认完整性和业务问题——再次筛选,可能有处理异常;

(3) 评价候选数据的质量、准确性和时效性,每个源系统都按照风险和使用收益

区分了等级。除变换外,有些数据还需要清洁,故也要估计清洁的程度。

(4) 相应更新数据模型;

(5) 通过搜索可能的源系统,建立更多的域; (6) 分析源数据的使用情况; (7) 确认记录系统并编成文档。

意料之外的源文件设计的变动最容易阻碍DW项目进程。

3、应考虑的问题:

(1) 当数据从操作型环境转移到DW环境时的键码结构/键码分辨率; (2) 属性:

<I>有多个来源可以选择应如何处理

<II>没有来源可以选择应如何处理

<III>当数据被选择传输给DSS环境时,必须作何种变换――编码/解码/

转换等等。

(3) 以数据的当前值如何创建时间变化量;

(4) 结构——DSS数据结构如何从操作型数据结构中创建; (5) 关系——操作型的关系如何在DSS环境中体现。 4、成功的因素:

3

正确执行后,源系统的数据就会及时、完备、准确、接近来源和易于访问,且与

DW需求的结构一致。

八、规范说明(程序说明) 技术体系结构中若干模块

15

前序的活动:源系统分析,数据仓库设计。 后继的活动:编程

估计时间:每个抽取、集成程序一周。

通常执行一次还是多次:每个需要编写的程序一次。

1、功能:完成操作型环境和DSS环境的接口的程序规范说明,用于把数据从操作型引 入DW。

1、 工作内容:

(1) 数据变换规范:

要确定是使用变动数据搜索法还是快照法,为建立一个完整的主题区,大多数环境必须在多个区段和文件中运行传送程序。

(2) 数据变换过程——要设计出能运行多种变换模块和变换程序的框架。

输出——包括时间和持续型在内的作业流。

(3) 控制设计和评审程序:

检验数据的传送是否足够大,变换是否正确。

(4) 确认业务度量:

<I>确定概括类型;

<II>确定概括位置,分为DW内部和DW外部;

<III>确定概括复杂粒度——在捕获元数据的地方概括。 (5) 历史数据转换过程;

(6) 测试数据——测试数据集; (7) DW模型的修正。 3、主要问题:

(1) 我怎么知道扫描的是什么样的操作型数据?

<I> 打上时间戳了吗? <II> 是增量文件吗?

<III> 有系统日志或审计日志可以用吗?

<IV> 现有的源代码和数据结构可以改变以产生一个增量文件吗? <V> 前后映像文件需要删除吗? (2) 一旦扫描后我如何存储输出?

<I> DSS数据用预分配、预格式化吗? <II>添加数据吗? <III>替换数据吗?

<IV>在DSS环境进行更新吗?

2、 成功的因素:

正确完成,使数据的抽取和集成尽可能高效简单。 九、 编程

前序的活动:规范说明 后继的活动:载入。

估计时间:每个抽取集成程序一周。 通常执行一次还是多次:每个程序一次 可以提交:。抽取、集成和时间 ----透视程序转换

1、功能:根据规范说明,编写程序源代码。

16

2、工作:

(1) 开发伪代码 (2) 编码 (3) 编译 (4) 通查

(5) 测试——单元测试、重点测试 3、成功的因素:

正确完成后,生成的代码将是高效、有文档说明、易于改变、准确和完备的。 十、 载入

前序的活动:编程、技术环境准备。 后继的活动:数据仓库的使用。 估计时间:N/A。

通常执行一次还是多次:N/A 可以提交:可用的数据仓库。 1、成果:可用的DW。 2、工作:执行DSS程序。 3、应考虑的问题:

(1) 载入的频率 (2) 清除载入数据 (3) 老化载入数据 (4) 管理多层次粒度 (5) 更新活样本数据 4、成功的因素:

正确完成后,可产生一个可访问的、可理解的、能够为DSS群体的需要服务的DW。 十一、开发流程图 根据每个开发步骤的前驱后继关系,其开发流程图如图3-7 所示。

每个主题 1 5 7 8 9 10

数据模型 主题领域 源系统 程序 编程 载入 分析 分析 分析 说明

6 2 “面包箱” DW数据库 分析 设计

3 4 技术评价 技术环境准备

图 3-7 数据仓库开发流程

17

实际上,一个真正可用的DW还应该有最终用户访问统计、开发的步骤。 十二、开发实例——

证券市场数据仓库。略

3.6 解决方案(不讲了)

一、SAS提供的数据仓库解决方案 根据SAS白皮书编写 1、SAS公司简介 美国North Carolina州立大学在1966年开始开发SAS(Statistical Analysis System)统计软件包。1997年成立SAS软件研究所,开始进行SAS的维护、开发、销售和教育工作。

由于使用SAS系统成功地建立了许多卓有成效的数据仓库。SAS公司的DW产品在1996年被美国著名的“Datamation”评为“当年度最佳产品”。在金融、电信、交通、制造、政府以及科研教育部门提供全面的软件解决方案。在DW、HOLAP、DM、Web发布等都有产品,在商务智能、DW、DM 和DSS软件位于全球第一。 2、SAS的数据仓库模型 运行的 提取数据 OLAP 质量 数据 EIS

数据转换 查询 机制 Web 风险性 关系DB Metadata 将数据装入 数据挖掘 客户 DW 早期数据 CIS 产品 结构 运行机制 信息DB 数据的 可视化 市场 数据仓库 操作 SAS 规划、内容

管理 预测 其它数据 管理 组织 展现 图 3-8 SAS的数据仓库模型 3.SAS数据仓库的组成

(1) SAS系统的数据存取能力

SAS/Access产品——可对众多不同格式的数据进行访问、查询和分析,提供了目前许多流行的数据库软件和老的数据文件的接口,如DB2、Oracle、Sybase、CA-Ingres等等。利用SAS/Access可建立对应外部异构数据的一个统一的共同数据界面,提供的接口是双向的,既可将数据读入SAS系统,亦可在SAS系统中更新外部数据,或将数据加载到外部数据载体中。 (2) 数据的清理和整合

在SAS的DW中有专门的机制进行引入数据的检查、核对和将不同来源数据进行整合的技术环节。

18

(3) 数据仓库的加载和更新

从数据源到数据仓库一气呵成的集成式操作的能力是SAS DW技术的重要特点。

(4) 按决策需要重组数据和信息 (5) 丰富的决策数据处理能力

SAS/MDDB——构造最适宜OLAP操作的多维数据结构; SAS/STAT ——覆盖了所有的数理统计分析方法,是国际上统计分析领域的标准

软件;

SAS/ETS——提供丰富的计量经济学和时间序列分析方法,是研究复杂系统和进

行预测的有力工具;

SAS/OR——提供了全面的运筹学方法;

SAS/IML——提供了面向矩阵运算的编程语言;

SAS/Insight——可视化的数据探索工具,将统计方法和交互式图形统合在一起。 (6) 灵活多样的结果展示方式

SAS/GRAPH——图形软件包。

三、SAS数据仓库的体系结构 SAS—DW的体系结构见图3-8 1、环境(Enviroment)

环境是SAS DW体系结构的总根,由两部分组成: (1) 数据仓库;(2)对数据源的定义。

构成了从数据采集到直接应用的完整的支持体系。 2、DW 可使用多个DW

一个DW中有多个数据集市。 3、主题(Subject)

在每个主题中有一个主题表系统,其中放置与此主题相关的各种数据

19

环境

数据仓库1

主题1

主题表系统(存放经过清洗、整合的数据,可以是表或视

图,结构重组)

主题表1 主题表n

汇总表组1(定义数据汇总处理的层次维数和所分析的变量)

SAS或DBMS汇总层次1...... SAS或DBMS汇总层次6......(表示所选择 汇总处理的时间维) MDDB1...... MDDBn......

汇总表组n......

信息市场1 (决策支持信息) 信息市场项目1...... 具体决策信息 信息市场项目1......

信息市场n 主题n

数据集市组1

数据集市1...... 数据集市n 信息市场1......

信息市场n......

数据集市组n

数据仓库n......

运行数据定义组1(对要从数据源取出的数据进行定义的分组) 运行数据定义1(定义要取得数据)

数据文件1...... 数据文件n 外部文件1......

外部文件n

20

运行数据定义n......

运行数据定义组n 图 3-8 SAS—DW的体系结构

四、SAS的数据仓库产品SAS/WA (SAS/Warehouse Administrator) 功能:

1、 定义DW和主题:

所定义的DW,可以建立在SAS数据库中,可建立在一般的DBMS中,还可以建立在SAS的多维数据库产品SAS/MDDB(MultiDemention Data Base)中。 2、传送和汇总整理数据

通SAS/WA的Process的Editor进行。 * 运行数据的映射(Mapping)

在此定义从输入数据源中取出哪些数据,这些数据如何转换,然后将他们装载到哪个主题数据表中去。 * 数据传送

将数据从其所在的计算机系统中选出,SAS/WA对它进行相应处理,然后用Proc UpLoad或Proc DownLoad在把它送到数据仓库所在的计算机系统中。如图3-9所示:

* 记录选取器

按照某些选取规则选出数据子集,形成DW的其他元素,如相应的表、数据集市或视图。 * 用户出口

除SAS/WA规定的DW操作外,用户可在多个环节上插入认为需要的数据操作。

DW主题表

开发者自编程序 数据映射

数据传输 运行数据定义 运行数据定义

运行数据定义

数据文件 数据文件 外部文件 图 3-9 数据传送

3、更新汇总数据

21

更新(1)原有表中进行更新;

(2)产生一个新的时间区间的数据新版本。

SAS/WA会按预先规定的规则产生一个新的汇总数据。 4、建立、管理和取用查看Metadata

在用SAS/WA建立DW的过程中,将形成一个若干个DW共用的Metadata:

(1) DW的各个元素所存放的地方;

(2) 在每台计算机系统中都有哪些DW的什么内容; (3) 如何从运行系统的数据源中取出所需的信息; (4) 其它DW管理源和用户间需要沟通的信息。 5、设置数据集市

二、ORACLE数据仓库解决方案

Oracle公司在20世纪90年代开始提供DW产品,2001年,Oracle推出了Oracle9i,在9i中DW的创建和管理功能是其中的重要组成。 1、 Oracle DW开发工具

Oracle 的DW开发工具分4类:

技术基础工具,分析应用工具,DW创建工具,DW维护工具。 (1)技术基础工具:

〈I〉Oracle Warehouse Builder为企业DW解决方案的设计、实施和管理,提供了一个完善的集成的框架;

〈II〉Oracle9i数据库

提供较好的数据存储性能,能较好地完成DW的创建工作; 〈III〉Oracle9i数据集市套件

提供构建数据集市所需的一些软件,例如:集中设计工具,提取数据的图形查询分析工具等;

〈IV〉Common Warehouse Metadata(CWM)主要用于构建、维护、管理和使用数据仓 库,包括技术和商业元数据,对数据进行管理和分析的工具,以及元数据信息交换。 (2)分析应用工具:

〈I〉面向高层的分析工具

Oracle Front Office——主要管理客户关系的全面产品,从市场营销到销售服务;

Oracle Sales Analyzer——分析营销数据。 这两个工具的结合,可提供有关销售的完整情况。从销售效果到销售环境以至定义新的产品和市场类别。

〈II〉面向底层的分析应用

a.Analyzer Activa——成本计算和管理软件包,具有实现动态成本计算与管理的能力。

b.Oracle Financial Analyzer——包含财务分析、规划、预算和报告功能,能够满足用户的低层要求。 c.Financial Analyzer——可直接链接数据源(例如账务系统),自动创建OLAP

分析系统以确保DW应用中的数据一致性。

〈III〉用于平衡高层和底层发展的分析应用 Balanced Scorecard——该工具为财务、客户、内部业务和学习/发展四个领

域进行信息分析提供了框架,通过这些领域,管理人员就可确定那项工作是公司战略获得成功的关键。

22

〈IV〉面向Oracle应用客户的分析应用工具

OBIS——Oracle Business Information System提供一种性能框架,能使用

互设定希望跟踪的主要性能指标,并且围绕这些性能指标定义误差级别,OBIS主要有事实管理、目标管理和异常管理组成。 (3)Oracle数据仓库创建工具

Oracle DataBase Configuration Assistant——Oracle数据构造助手(创建DW的工

具)。

Oracle Enterprise Manager ——Oracle企业管理器(创建表空间和事实表、维表)。

(4)Oracle DW维护工具

Oracle DW维护工具主要是指对DW进行数据装载,清理等操作的工具。 〈I〉 数据的导入、导出、装载用企业管理器完成; 〈II〉 NT环境下Oracle数据集市工具集; 〈III〉 代码生成工具; 〈IV〉 透明网关技术。

23

Copyright © 2019- huatuo3.cn 版权所有 湘ICP备2023017654号-3

违法及侵权请联系:TEL:199 1889 7713 E-MAIL:2724546146@qq.com

本站由北京市万商天勤律师事务所王兴未律师提供法律服务