第三章数据仓库设计
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、任务：⑴了解决策者现在的工作目标。
⑵现在获得决策支持信息的方法、渠道。
⑶和竞争对手的差距。
⑷决策者希望DW提供什么。
⑸制定系统的逻辑模型。
⑹分析数据源的物理存储状况、运行平台、数据质量、硬件、软件和网络的限制条件。
2、分析文档。
⑴项目概述。
⑵差距分析。
⑶系统基本架构图示。
⑷逻辑模型。
⑸物理模型。
⑹DW的初始装载和更新策略。
⑺DW的运行计划。
⑻决策信息展现的希望和需求。
⑼DW建成的时限。
三、构造DW
构造数据仓库包括数据仓库的管理、数据仓库的组织和决策支持信息的展现三部分。
设计和编写数据抽取程序/工具。
设计和编写数据转换程序/工具。
1、DW的管理设计和编写数据更新程序/工具。
设计和编写运行的接口程序。
建立这一阶段的所有管理的数据（元数据）
程序统一标准命名、建档。
初始装载
建立索引
2、DW的组织建立数据视图
DW及工作平台的安全检查
装入数据和应用功能
建立此阶段的元数据。
3、决策支持信息的展现
利用多维数据展现、数据挖掘等一些工具可预先制作好许多常规的信息市场项目供支持决策使用，也可以直接操作主题数据以得出新的决策支持信息。
四、数据仓库技术的培训。
培训内容：1、DW中的数据内容（包括逻辑模型、物理模型）、数据质量。
2、元数据的内容、位置，如何使用。
3、用户界面和功能介绍。
4、数据更新计划。
5、DW的安全规则。
6、从OLTP到DW的数据流。
7、全部的数据转换工作。
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-2 DataBase Association 公司定义的DW 技术体系结构
一、 设计模块
功能：是由DW 的设计者和管理者来设计和定义的DW 的。在设计DW 时必须考虑到的其他因素还包括DB 和瞬时数据的处理。某些DW 数据库还包括星型模型的非规范化DB 设计。 二、 数据获取模块
功能：用于开发和运行数据获取应用程序，从源系统中获取数据并加到DW 中。 内容：1、数据抽取规则——界定数据源。
2、数据情况——记录和字段的重组，增补丢失的字段值，数据的整性和一致
性检查。
3、数据增强——字段值的解码和转换，增加时间属性（若没有），数据的概括或者衍生值的计算。
4、数据传输。
5、生成的定义作为元数据存入信息目录模块。
三、 数据管理员模块。
功能：是DW 用来生成、管理和访问仓库中数据（很可能还有元数据）的模块。一般
使用RDBMS 或MDBMS （多维DBMS ）。
四、 管理模块。
功能：完成维护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、稳定性分析：根据各个属性的变化特征将这些属性分组（例如按更改频率）。就把
原始数据一个表分成多表，完成数据聚集。
二、数据模型
数据模型的级别：
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 的关系
ERD中的每一个实体将来都会被他的DIS所定义
②DIS的构造
初始数据组-----初始数据组对每个主要主题域存在且只存在一次，它有在每个主
要主题域只出现一次的属性，初始数据组有属性和键码
二次数据组-----有对每个主要主题域可以存在多次的属性，从初始数据组有一链
接指向二次数据组有多少个可以出现多次的不同数据组，就含有多少个二级数据组。
用于本组主题域与其它主要主题域之间的联系，体现了ERD中实体间的关系，它将数据从一个实体与另一个实体联系起来。
一般情况下，连接数据组往往是一个主题的公共码主键，从而建立了两个主题域间的相互联系。
数据的类型由指向右边的不同数据组组成，主要有左边的超类型数据组和右边的子类型数据组。
逻辑模型的基本结构由图3-5所示
图3-5 逻辑模型的基本结构
③数据组的稳定性
基本数据组稳定性大于初始数据组，初始数据组的稳定性大于类型数据组
④逻辑模型示例：见图6-6
图 3-6 逻辑模型示例图
在图3-6中，其客户名称、性别和开户时间等有关客户固定描述信息的数据项内容是基本不变的，所以他们可列入基本数据组。
客户的地址、文化程度、电话等虽然基本稳定，但是存在改变的可能性，因而列入二级数据组；
客户的贷款、存款情况、担保以及信用卡消费记录是频繁变动的数据项，故列入类型数剧组。
逻辑模型为DW开发者与使用者相互之间在进行DW开发时的交流与讨论的工具。
逻辑模型设计时，应保证DW中的所有元素包含在数据模型中。
3. 物理数据模型
逻辑模型可采用星型模型和雪花模型，主要是设计事实表、维表。
物理数据模型是依据中间层的逻辑数据模型创建的，他通过确定模型的键码属性和模型的
物理特性，扩展中间层模型而建立的，物理数据模型就由一系列表所构成，其中最主要的是事实表模型和维表模型，另外根据性能要求，对有关表模型进行调整，并确定有关的索引设置。
[1 ]事实表模型设计
以图3-6的金融企业客户主体逻辑模型可以设计出下面的事实表模型
客户基本情况表(账号，姓名，出生地，开户时间…)
客户变动情况表（账号，省，市，县，街道，邮编…）
客户贷款事实表
客户房屋贷款事实表(账号,地址,委托人,评估...)
客户汽车贷款事实表(账号,时间,制造商,型号...)
客户存款表1(账号,时间,最小存款数,最小余额...)
客户存款表2(账号,时间,最小存款数,最小余额..)
客户担保事实表1(账号,时间,责任人,种类,担保余额....)
事实表是DW中的最大表,在设计时,一定注意使事实表尽可能的小,因为过大的事实表在表的处理、备份和恢复、用户查询等方面要用较长时间。
减少事实表大小的方法：
①减少列的数量
②降低每列的大小
③把历史数据归档
④对行进行分割
[2] 维模型设计
维表模型也需要根据逻辑模型设计，维度表的属性必须具有以下特征：
①可用文字描述②有规定的限制（约束）
③属性取离散值④在分析中可提供行标题
最常用的维表应该直接参考事实表，而不应间接。这种方法可以最小化表的连接数量，提高系统的性能。
客户主体维度表模型
时间维度表（年，月，日）
地点维度表（省，市，县，街道）
贷款维度表（抵押贷款，非抵押贷款）
维属性就是用户获取数据的窗口
[3]. DW物理模型的性能问题
提高DW性能的技术
把需连接的几个表的记录合并成一个表,物理的放在一起.
建立数据序列
经常按某个固定顺序访问并处理一组数据记录,可严格按顺序存放到一个或几个连续的物理块中.
进行关系规范化的逆操作，即反规范化的处理
引入冗余和合并表的区别
合并表示将两个或多个相关表的相关记录物理上放在一起,但逻辑上不变，仍是多表,没改变多表的关系模式,且合并表只是对表记录的存取策略的改进,并没有冗余的数据.
引入冗余则是对表的关系模式的改变.把原来规范化的表，变成有数据冗余的规范化级别低的表。
分割依据: 存取频率
数据的稳定性
事先在原始数据上进行汇总或计算,生成导出数据。
优点:
◆减少I/O次数;
◆免去计算汇总步骤;
◆避免不同用户重复计算可能产生的误差
DW中的数据量巨大，要依靠各种各样的索引技术来提高设计大数据量的查询的速度。在向DW装载数据时,就根据用户的需求建立"广义索引"概要文件,最大宗的购买,不活跃的用户,最近的发货等.
4.数据模型和反复开发
①反复开发的理由:
* 业界成功的记录强烈的建议这样做
* 最终用户在完成第一遍之前不能明白的提出需求
* 只有实际结果切实而且明确时,管理部门才能做出充分的承诺
* 需要很快看到可视化结果
②数据模型在反复开发中的作用
数据模型在每遍开发中起着路标的作用,因为所有的开发都是数据模型驱动的,每遍后续开发都是建立在前一遍开发的基础上,结果就是都在统一的数据模型上进行不同的开发,各遍开发的结果将产生一个内聚的高度和谐的整体.
如果没有数据模型,重复的开发不能构成一个内聚的模式,有许多重叠和缺乏一致性.
3.4 数据仓库的粒度设计
DW开发中最重要的设计问题之一是决定DW的粒度,如果粒度设计恰当,则DW其他方面的设计和实现就较容易,它是体系结构设计环境成功的关键.
粒度级别的选择主要是对管理多大数据量和使用数据单元详细程度的一种处理,数据越详细,粒度越小,级别就越低;粒度越大,数据汇总级别就高.
在本节介绍利用量纲分级和反馈技术确定粒度的方法和相关原则.
一、粒度确定
1．粗略估计
要确定合适的粒度级,首先要粗略估算DW中将来的数据量和所需的直接存取设备数(DASD)
其步骤如下:
第一步:对每一个已知的表
计算一个记录所占字节数的最大、最小值（按字节算）
对一年内：可能的最大最小记录数
对五年内：可能的最大最小记录数
对每个表的关键字大小（字节数）
一年总的最大空间=最大记录所占空间*一年内最大记录数
一年总的最小空间=最小记录所占空间*一年内最小记录数
累加索引空间
第二步：对所有已知的表重复第一步
粗略数据估计完后，就要计算一下索引所占的空间，对每张表确定关键字的长度和原始表中是否每个记录都存在关键字。
数据量估计的上限和下限就等于记录的最高估计数和最小估计数分别乘以记录的最大、最小长度再加上索引次数乘以索引的长度。
2. 粒度划分过程的输入
根据空间估算的结果，可将估计的记录数和DASD数作为粒度划分过程的输入，与粒度的阈值进行比较，看是应该采用那种粒度。
对于五年期，行的总数大致以数量级改变。
对五年以后的推测：
①在管理DW中的大量数据时，将有更多的专门技术可用。
②硬件费用有所下降
③可以使用更强大的软件工具
④最终用户更加专业化
在分析时只考虑到DW中的记录数，而没有考虑总字节数，因为不管记录的字节长短，索引项的数量是没有变化的，因此被索引的记录的实际大小才影响决定DW是否采用双粒度级策略。
3．确定粒度级别
完成简单查询分析之后，就要确定粒度级别。基本方法：
①猜测一个粒度（凭直觉、经验）
②设计、载入数据到DW
③让DSS分析员看到数据
如不合理重复上述步骤。
最终用户的态度：“既然我看到了我能够做些什么，我就能告诉你什么是真正有用的。”4．反馈循环的技巧
<1> 反馈循环技巧
①用很小而很快的步伐建立DW的最初几个部分，仔细听取用户的意见，随时准备调整。
②使用原型法，并使用从原型中收集的观察结果而使反馈循环起作用
③学习别人确定粒度的经验
④与用户一起进行反馈处理
⑤看看本机构现在有了什么在运转
⑥进行联合应用程序设计会议，并模拟其输出已得到想要的反馈。
<2> 提高数据粒度的方法
①当源数据置入DW时，对它进行汇总；
②当源数据置入DW时，对它求平均或进行计算；
③把最大/最小的设定值置入DW；
④只把显然需要的数据置入DW;
⑤用条件逻辑选取记录的一个子集置入DW;
经验规则：在第一次的设计周期中，如果50%的工作是正确的，则整个设计就是成功的。5．粒度划分学例
①银行环境
操作型环境中约60天的业务数据
由于其信息量较大，设计成双重粒度级。
在DW中：◆轻度汇总存十年的每月汇总的账户信息
◆当前细节级数据存30天
在这个级别并不是把OLTP系统中所有的字段都送到DW中，只有对分析有价值的
信息字段才被存储。
30天之后，把这部分细节数据送到磁带上，腾出的空间存放下一个30天的当
前细节级数据。
②制造业环境
OLTP系统中存放的是订单，由于量少，设计成单粒度，只要轻度综合，不要当前
细节级。DW中存放10年的订单历史。
3．5 数据仓库开发
数据仓库的开发是一个基于不断循环、逐步增长的生命周期模式，是一个用户和开发人员对其不断了解、熟悉和完善的过程。
本节提供可以用来指导开发数据仓库技术的准则。可以把它当作一个框架，来展示不同类型DW 项目的定制方法。框架中的每一重大步骤都与实践联系紧密。除了提供方法之外，还指出每一步骤需要注意什么。
一、数据模型分析
前序的活动：承担数据仓库建设的任务
后继的活动：主题领域分析，“面包箱”分析，数据仓库设计
估计时间：差别很大，取决于数据模型的状态和质量
通常执行一次还是多次：一次
１、数据模型的要求（开始时要定义一个数据模型）
（１）标示主要主题领域；
（２）清晰地定义模型的边界；1
（３）把原始数据和导出数据分离；
（４）每个主题领域需要标识；
＜I＞键码
＜II＞属性
＜III＞属性分组
＜IV＞属性分组之间的关系
＜V＞多重出现的数据
＜VI＞数据的类型
这个步骤的输出是对机构已经建立了一个可靠的数据模型的确认，如果模型没有满足指定的校准，那么进程就应该停止直至达到质量校准。（（１）体现此步的重要性；（２）指出该部没完成应该怎么办。）
２、数据模型成功的标志：
（１）主要主题领域的标识；
（２）每个主要主题有自己的独立的定义，包括：
＜I＞数据的子类型
＜II＞数据的属性
＜III＞清晰地定义数据的关系
＜IV＞定义数据分组
＜V＞定义键码——所有的DSS数据都有自己随时间变化的键码
二、“面包箱”分析
前序的活动：数据模型分析
后继的活动：数据仓库数据库设计
估计时间：从一天到两周不等，取决于范围定义得是否好，数据模型定义得是否好等。
通常执行一次还是多次：一次。
可以提交：粒度分析。
功能：通过粗略估计确定DSS环境的规模。――即知道ＤＷ要处理多少数据
目的：根据ＤＷ中的数据确定粒度设计。
成功的因素：
１、对整个ＤＷ环境的数据量的估计；
一年～五年；
２、如果需要多层粒度，输出多层粒度定义。
三、技术评价
前序的活动：承担数据仓库建设的任务
后继的活动：技术环境准备
估计时间：一周
通常执行一次还是多次：一次
可以提交：技术环境评价。
该阶段的任务是根据数据仓库建设所必备的条件，评价目前开发组人员的技术水平。
成功的因素：
１、管理大量数据的能力；
２、允许灵活访问数据的能力；
３、根据数据模型组织数据的能力；
４、能够用许多技术接受和发送数据的能力；
５、能够周期地把数据全部加载的能力；
６、能够以一次一个集合或一次一个记录的方式访问数据的能力；
四、技术环境准备
前序的活动：技术评价
后继的活动：数据仓库设计、载入。
估计时间：一周到一个月。
通常执行一次还是多次：一次
该阶段的任务是：选择实现DW的软/硬件资源、开发平台、DBMS网络、开发工具．．．．．．当ＤＷ的体系结构配置已经建立，下一步就是技术上确定如何实现这个配2置。
１、要考虑的典型问题是：
（１）需求DASD（Direct Access Storage Disk，直接存取存储设备）的数量；
（２）需要什么链路――通过网络或进入网络；
（３）预期的处理量；
（４）如何使竞争的存取程序之间的处理冲突达到最小限度或减轻这种冲突；
（５）由控制DW的技术产生的通信量；
（６）由控制DW的技术产生的通信量的性质——或长或短的爆发。
２、成功的因素：
这个步骤正确执行后，成功的路上就不会有技术的阻碍了。
接收数据的技术部件，准备就绪：
（１）网络；
（２） DASD；
（３）管理DASD的操作系统；
（４）出入DW的接口；
（５）管理DW的软件；
（６） DW。
五、主题领域分析
前序的活动：数据模型分析
后继的活动：源系统分析
估计时间：一天
通常执行一次还是多次：每个载入工程一次。
可以提交：下一个要建造哪个主题。。
１、主题领域――围绕一个主题的工作范围、内容。第一个选择的主题领域必须大到足以有意义，而又小到可以实现。
如果有时某个主题领域确实大而且复杂，那么应该选择它的子集实现。
２、内容：
（１）给出主题域范围――有什么？
（２）所需的细节水平；
（３）生成初步概括表。
３、成功的因素：
最初选择小的主题；
后来选择大的主题，甚至是主题的子集。
选择的载入主题适合开发DW的当前阶段的需要。
此阶段将主题域模型化、规范化。
六．ＤＷ设计
前序的活动：数据模型分析、源系统分析、“面包箱分析”。
后继的活动：程序规范说明
估计时间：一周到三周。
通常执行一次还是多次：一次
可以提交：数据仓库的物理数据库的设计。。
１、任务：DW的物理数据库设计。
２、内容：DW是基于数据模型设计的。其主要设计内容有：
（１）域表；
（２）概括表——可能成为业务度量的最常用的维；
（３）星型连接和事实表；
（４）建立索引；
（５）备份和恢复。
３、设计特性：
（１）如果确实需要多层粒度，要做好不同层次粒度的调节；
（２）把数据定向到公司的主要主题；
（３）只出现原始数据和公共的导出数据；
（４）不存在非DSS数据；
（５）每个数据纪录的时间变化量；
（６）在适宜的场合物理反规范化数据；
（７）在把操作型环境中的数据引入到DW的地方创建人工数据。
４、成功的因素：
这个步骤成功执行后，其结果是一个具有一定数量数据的DW，这些数据可以用相当有效的方式加载、访问和搜索。
七、源系统分析――确定数据从何而来
前序的活动：主题领域分析
后继的活动：程序规范说明，数据仓库设计。
估计时间：每个主题领域一周。
通常执行一次还是多次：一次
可以提交：记录系统的标示。
１、功能：
从现有的系统环境中为主题标识数据，产生从操作型环境到DSS环境的映射。
２、内容：
（１）要列出可能成为数据源的系统或文件——筛选；
（２）确认完整性和业务问题——再次筛选，可能有处理异常；
（３）评价候选数据的质量、准确性和时效性，每个源系统都按照风险和使用收益区分了等级。除变换外，有些数据还需要清洁，故也要估计清洁的程度。
（４）相应更新数据模型；
（５）通过搜索可能的源系统，建立更多的域；
（６）分析源数据的使用情况；
（７）确认记录系统并编成文档。
意料之外的源文件设计的变动最容易阻碍DW项目进程。
３、应考虑的问题：
（１）当数据从操作型环境转移到DW环境时的键码结构／键码分辨率；
（２）属性：
＜I＞有多个来源可以选择应如何处理
＜II＞没有来源可以选择应如何处理
＜III＞当数据被选择传输给DSS环境时，必须作何种变换――编码／解码／转换等等。
（３）以数据的当前值如何创建时间变化量；
（４）结构——DSS数据结构如何从操作型数据结构中创建；
（５）关系——操作型的关系如何在DSS环境中体现。
４、成功的因素：
正确执行后，源系统的数据就会及时、完备、准确、接近来源和易于访3问，且与DW需求的结构一致。
八、规范说明（程序说明）技术体系结构中若干模块
前序的活动：源系统分析，数据仓库设计。
后继的活动：编程
估计时间：每个抽取、集成程序一周。
通常执行一次还是多次：每个需要编写的程序一次。
1、功能：完成操作型环境和DSS环境的接口的程序规范说明，用于把数据从操作型引入DW。
１、工作内容：
（１）数据变换规范：
要确定是使用变动数据搜索法还是快照法，为建立一个完整的主题区，大多数环境必须在多个区段和文件中运行传送程序。
（２）数据变换过程——要设计出能运行多种变换模块和变换程序的框架。
输出——包括时间和持续型在内的作业流。
（３）控制设计和评审程序：
检验数据的传送是否足够大，变换是否正确。
（４）确认业务度量：
＜I＞确定概括类型；
＜II＞确定概括位置，分为DW内部和DW外部；
＜III＞确定概括复杂粒度——在捕获元数据的地方概括。
（５）历史数据转换过程；
（６）测试数据——测试数据集；
（７） DW模型的修正。
３、主要问题：
（１）我怎么知道扫描的是什么样的操作型数据？
＜I＞打上时间戳了吗？
＜II＞是增量文件吗？
＜III＞有系统日志或审计日志可以用吗？
＜IV＞现有的源代码和数据结构可以改变以产生一个增量文件吗？
＜V＞前后映像文件需要删除吗？
（２）一旦扫描后我如何存储输出？
＜I＞ DSS数据用预分配、预格式化吗？
＜II＞添加数据吗？
＜III＞替换数据吗？
＜IV＞在DSS环境进行更新吗？
２、成功的因素：
正确完成，使数据的抽取和集成尽可能高效简单。
九、编程
前序的活动：规范说明
后继的活动：载入。
估计时间：每个抽取集成程序一周。
通常执行一次还是多次：每个程序一次
可以提交：。抽取、集成和时间 ----透视程序转换
１、功能：根据规范说明，编写程序源代码。
２、工作：
（１）开发伪代码
（２）编码
（３）编译
（４）通查
（５）测试——单元测试、重点测试
３、成功的因素：
正确完成后，生成的代码将是高效、有文档说明、易于改变、准确和完备的。
十、载入
前序的活动：编程、技术环境准备。
后继的活动：数据仓库的使用。
估计时间：N/A。
通常执行一次还是多次：N/A
可以提交：可用的数据仓库。
１、成果：可用的DW。
２、工作：执行DSS程序。
３、应考虑的问题：
（１）载入的频率
（２）清除载入数据
（３）老化载入数据
（４）管理多层次粒度
（５）更新活样本数据
４、成功的因素：
正确完成后，可产生一个可访问的、可理解的、能够为DSS群体的需要服务的DW。十一、开发流程图根据每个开发步骤的前驱后继关系，其开发流程图如图3-7 所示。
图 3-7 数据仓库开发流程
实际上，一个真正可用的ＤＷ还应该有最终用户访问统计、开发的步骤。
十二、开发实例——
证券市场数据仓库。略
3.6 解决方案（不讲了）
一、SAS提供的数据仓库解决方案根据SAS白皮书编写
１、SAS公司简介
美国North Carolina州立大学在1966年开始开发SAS(Statistical Analysis System)统计软件包。1997年成立SAS软件研究所，开始进行SAS的维护、开发、销售和教育工作。
由于使用SAS系统成功地建立了许多卓有成效的数据仓库。SAS公司的DW产品在1996年被美国著名的“Datamation”评为“当年度最佳产品”。在金融、电信、交通、制造、政府以及科研教育部门提供全面的软件解决方案。在DW、HOLAP、DM、Web发布等都有产品，在商务智能、DW、DM 和DSS软件位于全球第一。
２、SAS的数据仓库模型
提取数据ＯＬＡＰ
EIS
数据转换查询
机制Web
将数据装入数据挖掘
DW
CIS
运行机制数据的
可视化
数据仓库操作
规划、内容
管理
管理组织展现
图 3-8 SAS的数据仓库模型
3．SAS数据仓库的组成
（１） SAS系统的数据存取能力
SAS／Access产品——可对众多不同格式的数据进行访问、查询和分析，提供了目前许多流行的数据库软件和老的数据文件的接口，如DB2、Oracle、Sybase、CA-Ingres等等。利用SAS／Access可建立对应外部异构数据的一个统一的共同数据界面，提供的接口是双向的，既可将数据读入SAS系统，亦可在SAS系统中更新外部数据，或将数据加载到外部数据载体中。
（２）数据的清理和整合
在SAS的DW中有专门的机制进行引入数据的检查、核对和将不同来源数据进行整合的技术环节。
（３）数据仓库的加载和更新
从数据源到数据仓库一气呵成的集成式操作的能力是SAS DW技术的重要特点。
（４）按决策需要重组数据和信息
（５）丰富的决策数据处理能力
SAS/MDDB——构造最适宜OLAP操作的多维数据结构；
SAS/STAT ——覆盖了所有的数理统计分析方法，是国际上统计分析领域的标准
软件；
SAS/ETS——提供丰富的计量经济学和时间序列分析方法，是研究复杂系统和进行预测的有力工具；
SAS/OR——提供了全面的运筹学方法；
SAS/IML——提供了面向矩阵运算的编程语言；
SAS/Insight——可视化的数据探索工具，将统计方法和交互式图形统合在一起。
（６）灵活多样的结果展示方式
SAS／GRAPH——图形软件包。
三、SAS数据仓库的体系结构 SAS—DW的体系结构见图3-8
１、环境（Enviroment）
环境是SAS DW体系结构的总根，由两部分组成：
（１）数据仓库；（２）对数据源的定义。
构成了从数据采集到直接应用的完整的支持体系。
２、DW 可使用多个DW
一个DW中有多个数据集市。
３、主题（Subject）
在每个主题中有一个主题表系统，其中放置与此主题相关的各种数据
环境
数据仓库１
主题１
主题表系统（存放经过清洗、整合的数据，可以是表或视
图，结构重组）
主题表１
主题表ｎ
汇总表组１（定义数据汇总处理的层次维数和所分析的变
量）
SAS或DBMS汇总层次１．．．．．．
SAS或DBMS汇总层次６．．．．．．（表示所选择
汇总处理的时间维）
MDDB1．．．．．．
MDDBｎ．．．．．．
汇总表组ｎ．．．．．．
信息市场１（决策支持信息）
信息市场项目１．．．．．．具体决策信息
信息市场项目１．．．．．．
信息市场ｎ
主题ｎ
数据集市组１
数据集市１．．．．．．
数据集市ｎ
信息市场１．．．．．．
信息市场ｎ．．．．．．
数据集市组ｎ
数据仓库ｎ．．．．．．
运行数据定义组１（对要从数据源取出的数据进行定义的分组）
运行数据定义１（定义要取得数据）
数据文件１．．．．．．
数据文件ｎ
外部文件１．．．．．．
外部文件ｎ
2.5数据仓库模型的设计 数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计 进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容 概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。 概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界 数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些? . 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2，确定主要的主题域 在这一步中，要确定系统所包含的主题域，然后对每个主题域的内
数据仓库设计指南 在一般的数据仓库应用系统中，根据系统体系结构的不同，数据仓库设计的内容和范围不尽相同，并且设计方法也不尽相同，下面的两幅图示分别表示带有ODS的数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构。本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同，并且重点介绍带有ODS的体系结构中数据仓库的设计方法。GV1 =p}` 在数据仓库的设计指导思想中，数据仓库的概念定义是非常重要的，数据仓库概念规定了数据仓库所具有的几个基本特性，这些特性也正是对数据仓库设计结果进行检验的重要依据。M)_m= }d 根据Bill.Inmon的定义，“数据仓库是面向主题的、集成的、稳定的、随时间变化的，主要用于决策支持的数据库系统”。_R)tJ Ro ODS（Operational Data Store）是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。4\&P~kI 一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：#:1< R\H6m 1）在业务系统和数据仓库之间形成一个隔离层。[t"C/;S! 一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。,8mPV{U KU 2）转移一部分业务系统细节查询的功能 Cr 数据库与数据仓库的区别是什么 简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。 “与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。 “不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库 第1章数据仓库建设 1.1数据仓库总体架构 专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据，经过一系列综合诊断分析，以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施，为车辆的故障根因修复提供必要的支持。 根据专家系统数据仓库建设目标，结合系统数据业务规，包括数据采集频率、数据采集量等相关因素，设计专家系统数据仓库架构如下： 数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的容： 数据采集：负责从各业务自系统中汇集信息数据，系统支撑Kafka、Storm、Flume 及传统的ETL采集工具。 数据存储：本系统提供Hdfs、Hbase及RDBMS相结合的存储模式，支持海量数据的分布式存储。 数据分析：数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。 数据服务总线：数据系统提供数据服务总线服务，实现对数据资源的统一管理和调度，并对外提供数据服务。 1.2数据采集 专家系统数据仓库数据采集包括两个部分容：外部数据汇集、部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层（ODS）；部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。 1.2.1外部数据汇集 专家数据仓库数据源包括列车监控与检测系统（TCMS）、车载子系统等相关子系统，数据采集的容分为实时数据采集和定时数据采集两大类，实时数据采集主要对于各项检测指标数据；非实时采集包括日检修数据等。 根据项目信息汇集要求，列车指标信息采集具有采集数据量大，采集频率高的特点，考虑到系统后期的扩展，因此在数据数据采集方面，要求采集体系支持高吞吐量、高频率、海量数据采集，同时系统应该灵活可配置，可根据业务的需要进行灵活配置横向扩展。 本方案在数据采集架构采用Flume+Kafka+Storm的组合架构，采用Flume和ETL 工具作为Kafka的Producer，采用Storm作为Kafka的Consumer，Storm可实现对海量数据的实时处理，及时对问题指标进行预警。具体采集系统技术结构图如下: 归一大数据平台 数据仓库 系统设计说明书受控不受控 修改变更记录： 目录 1引言 (5) 1.1文档编制目的 (5) 1.2背景 (6) 1.3词汇表 (6) 1.4参考资料 (6) 2总体设计 (7) 2.1软件体系结构 (7) 2.2系统运行体系......................................................................... 错误！未定义书签。 2.2.1运行体系图..................................................................... 错误！未定义书签。 2.2.2程序/模块对应表............................................................ 错误！未定义书签。 2.3系统物理结构 (7) 2.4技术路线 (8) 3系统接口设计 (8) 3.1用户接口 (8) 4子系统/模块设计 (8) 4.1数据仓库 (8) 4.1.1ODL(操作数据)层设计 (8) 4.1.2BDL(数据仓库)层设计 (10) 4.1.3IDL(宽表)层设计 (11) 4.1.4PDL(应用)层设计 (12) 4.1.5PUB(维度)层设计 (15) 4.1.6数据导出设计 (16) 5数据结构与数据库设计 (17) 6外部存储结构设计 (17) 7故障处理说明 (17) 8尚需解决的问题 (18) 编写指南： 本模板力图给出系统设计阶段可能包括的基本信息，重点在于和需求分析文档相联系。描述系统整体情况。如果某个章节在项目或当前阶段中无法描述，则可保留其标题，注明“不 1.数据仓库概述 经过多年IT的建设，信息对于XXX 的日常管理已经日益重要，并逐渐成为重要的信息资产，信息资产的管理已经成为日常管理中一个非常重要的环节。如何管理和利用好XXX 内部纷繁的数据也越来越成为信息管理的一项重要工作。 在过去相当一段时间内，XXX 业务系统的构建主要围绕着业务的数据展开，应用的构建多是自下而上构建，主要以满足某个部门的业务功能为主，我们称之为业务处理的时代。这样的构建方式造成了一个个分立的应用，分立的应用导致了一个个的静态竖井。由于数据从属于应用，缺乏XXX 全局的单一视图，形成了一个个信息孤岛，分立的系统之间缺乏沟通，同样数据的孤岛导致只能获得片面的信息，而不是全局的单一视图。存储这些信息的载体可能是各种异构或同构的关系型数据库，也有可能是XML 、EXCEL 等文件。因此，构建新一代的一体化平台提上了日程并最终促成全域数据的管理方式，目的是覆盖XXX 各个环节的关键业务数据，完善元数据管理，形成全局的数据字典、业务数据规范和统一的业务指标含义，能够灵活的获取XXX 业务数据的单一视图（需要保证数据的一致性、完整性、准确性和及时性）。数据的交换和共享主要发生在上下级组织机构之间或同级的不同部门之间。最终，这些数据可以为部队分析、决策支持（多维分析、即席查询、数据挖掘）等应用提供更及时、准确、有效的支持。 数据仓库的目标是实现跨系统数据共享，解决信息孤岛，提升数据质量，辅助决策分析，提供统一的数据服务。同时，数据仓库的构建也面临着各种挑战，比如信息整合在技术上的复杂度、信息整合的管理成本、数据资源的获取、信息整合的实施周期以及整合项目的风险等。 数据仓库之路 FAQ FAQ目录 一、与数据仓库有关的几个概念 (3) 1.1 目录 (3) 二、数据仓库产生的原因 (8) 三、数据仓库体系结构图 (11) 四、数据仓库设计 (12) 4.1 数据仓库的建模 (12) 4.2 数据仓库建模的十条戒律： (13) 五、数据仓库开发过程 (14) 5.1 数据模型的内容 (14) 5.2 数据模型转变到数据仓库 (14) 5.3 数据仓库开发成功的关键 (15) 六、数据仓库的数据采集 (16) 6.1 后台处理 (17) 6.2 中间处理 (17) 6.3 前台处理 (18) 6.4 数据仓库的技术体系结构 (18) 6.5 数据的有效性检查 (20) 6.6 清除和转换数据 (20) 6.7 简单变换 (22) 6.8 清洁和刷洗 (24) 6.9 集成 (25) 6.10 聚集和概括 (27) 6.11 移动数据 (27) 七、如何建立数据仓库 (30) 7.1 数据仓库设计 (31) 7.2 数据抽取模块 (32) 7.3 数据维护模块 (33) 一、与数据仓库有关的几个概念 1.1 目录 ?Datawarehouse ?Datamart ?OLAP ?ROLAP ?MOLAP ?ClientOLAP ?DSS ?ETL ?Adhocquery ?EIS ?BPR ?BI ?Datamining ?CRM ?MetaData Data warehouse 本世纪80年代中期，“数据仓库之父”William H.Inmon先生在其《建立数据仓库》一书中定义了数据仓库的概念，随后又给出了更为精确的定义：数据仓 数据仓库数据库设计的心得总结 数据仓库是企业商业智能分析环境的核心，它是建立决策支持系统的基础。一个良好的数据仓库设计应该是构建商业智能和数据挖掘系统不懈的追求。下面把数据仓库数据库设计的心得做一小结。 一透彻理解数据仓库设计过程 商业智能和数据挖掘归根到底是“从实践中来，到实践中去”。也就是说现实需求决定系统需求，业务数据决定系统构架，最终使用的时候又必须作用于现实需求，同时通过决策的行为影响业务。那么可以把数据仓库的设计看做是前一部分，即“从实践中来”，数据仓库的应用可以看做是“到实践中去”。把“从实践中来”这个过程进行抽象，数据仓库的设计就是“客观世界→主观世界→关系世界”的过程。 在前面几节完成了6个任务：选择被建模主题的商业过程、确定事实表的粒度、区分每一个事实表的维和层、区分事实表的度量、确定每一个维表的属性、在D BMS中创建和管理数据仓库。实际上这些任务都可以归结到从客观世界到关系世界的过程。那么把这个过程再进行归纳，可以得到如图3-61所示的综合了模型、方法和过程的示意图。 图3-61 数据仓库设计过程的模型和方法示意图 二把握设计的关键环节 如果将时间、精力、金钱和人事优先花在前面的20%，那么这20%会创造出80% 的价值。这就是有名的2/8原则。下面将介绍在数据仓库设计中，哪些因素是属于这20%的范围。 1．需求 需求分析在任何如见项目中都是最为重要的因素之一。企业模型是从企业的各个视点对企业数据需求及数据间关系的抽象。通过将企业模型映射到数据库系统，可以很快地了解现有数据库系统完成了企业模型中的哪些部分，还缺少哪些部分。然后再将企业模型映射到数据仓库系统，发现企业需要的（或可以构造的）主题。通过这样的过程完成对企业数据需求和现有数据的了解，达到明了原有系统和需要建设的主题域间共性的目的。 2．关键性能指标（KPI） 一般而言，一个决策支持系统最重要的就是要呈现决策数据。而KPI就是决策过程中要显示的数据结果的部分，如销售数量、销售金额、毛利和运费等数值部分的数据。这些KPI是通过与相关的维表进行连接而映射出来的。在分析星形模式时，往往要首先确定KPI。 3．信息对象 信息对象是指在每个分析过程中那些会影响到决策的因素。以销售分析为例，时间、产品、员工与客户就是影响决策的大因子，而每个因子又可以分离出多个分层结构，如时间可分为年、季度、月、周和日等，员工可分为年龄层、年龄、年薪层、年薪和员工所在城市等，也就是影响决策的详细因子。这些都是信息对象。从这里我们可以看出，每个大因子如时间、产品、员工与客户等就可以构成如时间维表、产品维表、员工维表与客户维表等。而时间维表又可分为年、季度和日等字段。在分析和设计这些信息对象组成的维度时，需要注意维的唯一性和公用性，千万不要在不同的主题中定义多个表示同一内容的维，如果有可能，一个维表要尽量被多个主题共享。 4．数据粒度 在数据仓库的每个主题中，都必须考虑事实数据的粒度。粒度的具体划分将直接影响到数据仓库中的数据量及查询质量。在数据仓库开始进行分析时。就需要建立合适的数据粒度模型，指导数据仓库设计和其他问题的解决。如果数据粒度定义不当，将会影响数据仓库的使用效果，使数据仓库达不到设计数据仓库的目的。 5．数据之间的联系 在数据仓库中，不同主题的数据之间的物理约束或许不再存在，但无论这些数据如何变化，要知道必须有一些“键”在逻辑上保持着不同数据之间的联系，这样 数据仓库设计与实现 学号 128302106 姓名江晨婷 成绩 教师张丹平 二O一五年四月 数据仓库建设方案设计与实现 摘要：本文以博士学位调查为基础，创建方案，设计与实现数据仓库，通过对当前各种主流数据仓库软件在性能、价格等方面的对比，充分考虑统计业务、单位数量等实际情况，本系统决定采用SQL Server 2005数据仓库软件来构建综合信息分析系统的数据仓库。 关键词：数据仓库；联机分析；数据挖掘；博士学位 一、概述 数据仓库的设计一般从操作型数据开始，通常需要经过以下几个处理过程；数据仓库设计——数据抽取——数据管理。 1.数据仓库设计 根据决策主题设计数据仓库结构，一般采用星型和雪花模型设计其数据模型，在设计过程中应保证数据仓库的规范化和体系各元素的必要联系。 2.数据抽取 根据元数据库中的主题表定义、数据源定义、数据抽取规则定义对异地异构数据源进行清理、转换、对数据进行重新组织和加工，装载到数据仓库的目标库中。 3.数据管理 数据管理分为目标数据维护和元数据维护两方面。目标数据维护是根据元数据为所定义的更新频率、更新数据项等更新计划任务来刷新数据仓库，以反映数据源的变化，且对时间相关性进行处理。元数据是数据仓库的组成部分，元数据的质量决定整个数据仓库的质量。当数据源的运行环境、结构及目标数据的维护计划发生变化时，需要修改元数据。 二、博士学位授予信息年度数据统计分析 1.按主管部门统计 从主管部门的角度，分析在一个时间段（年）内，各主管部门所授予的博士学位信息统计。可回答如“2008，由某部门主管的，博士学位授予一共有多少，其平均学习年限是多少，脱产学习的有多少人?”等问题。具有表格和图形两种方式来展示分析结果。典型报表格式如表1所示 数据仓库和数据库有什么区别？ 通常情况下基于业务数据库数据分析人员也能完成数据分析需求，但是为什么要建数据仓库？ 没有数据仓库时，我们需要直接从业务数据库中取数据来做分析。 业务数据库主要是为业务操作服务的，虽然可以用于分析，但需要很多额度的调整。 一，业务数据库中存在的问题 基于业务数据库来做分析，主要有以下几个问题： 结构复杂，数据脏乱，难以理解，历史缺失，数据量大时查询缓慢。 结构复杂 业务数据库通常是根据业务操作的需要进行设计的，遵循3NF范式，尽可能减少数据冗余。这就造成表与表之间关系错综复杂。在分析业务状况时，储存业务数据的表，与储存想要分析的角度表，很可能不会直接关联，而是需要通过多层关联来达到，这为分析增加了很大的复杂度。 数据脏乱 因为业务数据库会接受大量用户的输入，如果业务系统没有做好足够的数据校验，就会产生一些错误数据，比如不合法的身份证号，或者不应存在的Null值，空字符串等。 理解困难 业务数据库中存在大量语义不明的操作代码，比如各种状态的代码，地理位置的代码等等，在不同业务中的同一名词可能还有不同的叫法。 这些情况都是为了方便业务操作和开发而出现的，但却给我们分析数据造成了很大负担。各种操作代码必须要查阅文档，如果操作代码较多，还需要了解储存它的表。同义异名的数据更是需要翻阅多份文档。 缺少历史 出于节约空间的考虑，业务数据库通常不会记录状态流变历史，这就使得某些基于流变历史的分析无法进行。比如想要分析从用户申请到最终放款整个过程中，各个环节的速度和转化率，没有流变历史就很难完成。 大规模查询缓慢 当业务数据量较大时，查询就会变得缓慢。 二，数据仓库解决方案 上面的问题，都可以通过一个建设良好的数据仓库来解决。 业务数据库是面向操作的，主要服务于业务产品和开发。 而数据仓库则是面向分析的，主要服务于我们分析人员。评价数据仓库做的好不好，就看我们分析师用得爽不爽。因此，数据仓库从产品设计开始，就一直是站在分析师的立场上考虑的，致力于解决使用业务数据进行分析带来的种种弊端。 数据仓库解决的问题 结构清晰，简单 数据仓库不需要遵循数据库设计范式，因此在数据模型的设计上有很大自由。 数据模型一般采用星型模型，表分为事实表和维度表两类。 其中事实表位于星星的中心，存储能描述业务状况的各种度量数据。 系统设计说明书 归一大数据平台 数据仓库 系统设计说明书 修改变更记录： 目录 1引言5 1.1文档编制目的 (5) 1.2背景 (6) 1.3词汇表 (6) 1.4参考资料 (6) 2总体设计7 2.1软件体系结构 (7) 2.2系统物理结构 (7) 2.3技术路线 (8) 3系统接口设计8 3.1用户接口 (8) 4子系统/模块设计8 4.1数据仓库 (8) 4.1.1O DL(操作数据层)设计 (8) 4.1.2B DL(事物层)设计 (10) 4.1.3I DL(宽表层)设计 (11) 4.1.4P DL(应用层)设计 (12) 4.1.5P UB(维度)库设计 (15) 4.1.6业务账(数据集市)库 (16) 4.1.7数据导出设计 (16) 5数据结构与数据库设计17 6外部存储结构设计 17 7故障处理说明17 8尚需解决的问题18 编写指南： 本模板力图给出系统设计阶段可能包括的基本信息，重点在于和需求分析文档相联系。描述系统整体情况。如果某个章节在项目或当前阶段中无法描述，则可保留其标题，注明“不适用”；如果需要对本模板的个别章节详细描述，也可将其形成单独的文档，成为本文档附件。 若文档中的某个章节已经在其他项目文档中加以描述，可保留标题，注明“参见（文档编号）（文档名称）（条款）”。 形成正式文档后须删除斜体字内容。 0 报告编制要求 这里列出本系统设计报告编制的经验性要求，须由系统设计人员参照其进行裁剪以确定本次报告编制的相关规定。 1引言 1.1文档编制目的 指导开发人员进行后期的开发工作； 指导测试人员进行解决方案级的系统测试； 1.2背景 叙述系统设计阶段的目标、作用范围以及其他应向读者说明的理解本报告所需的背景，如与公司其它软件之间的联系等。 1.3词汇表 列出本系统设计说明书中专门术语的定义、英文缩写词的原词组和意义、项目组内达成一致意见的专用词汇，同时要求继承全部的先前过程中定义过的词汇。 词汇名称词汇含义备注 备注中注明该词汇的来源，或有其他更详细的解释的文档位置；以及对该词汇的其他叫法。 1.4参考资料 需求规格说明书 系统架构设计说明书 第一章概述 1.数据挖掘的定义？（书P2，PPT_P8） 从大量的、不完全的、有噪声的、模糊的、随机的数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。 2.数据挖掘的源是否必须是数据仓库的数据？可以有哪些来源？（PPT_P14） 关系数据库、数据仓库、事务数据库、高级数据等 3.数据挖掘的常用方法？（P4、PPT_P29） 聚类分析、决策树、人工神经网络、粗糙集、关联规则挖掘、统计分析等 4.数据挖掘的过程包括哪些步骤，每一步具体包括哪些内容？（书P2-3，PPT_P17-19） 确定业务对象、数据准备、数据挖掘、结果分析与知识同化。 5.数据挖掘与数据仓库的关系（联系和区别）？书P6-7，PPT_P45-46 联系：1，数据仓库为数据挖掘提供了更好的，更广泛的数 据源 AHA12GAGGAGAGGAFFFFAFAF 2，数据仓库韦数据挖掘提供了新的支持平台。 3，数据仓库为更好地使用数据挖掘工具提供了方便 4，数据挖掘对数据仓库提供了更好的决策支持。 5，数据挖掘对数据仓库的数据组织提出了更高的要求 6，数据挖掘还为数据仓库提供了广泛的技术支持 区别：数据仓库是一种存储技术，它包含大量的历史数据、当前的详细数据以及综合数据，它能为不同用户的不同决策需要提供所需的数据和信息。~~数据挖掘是从人工智能机器学习中发展起来的，它研究各种方法和技术，从大量的数据中挖掘出有用的信息和知识。 第二章数据仓库 1.数据仓库的定义 数据仓库——是一个面向主题的、集成的、随时间而变化的、不容易丢失的数据集合，支持管理部门的决策定制过程。2.数据仓库数据的四大基本特征： 面向主题的、集成的、不可更新的、随时间变化的。 3.数据仓库体系结构有三个独立的数据层次： AHA12GAGGAGAGGAFFFFAFAF 数据仓库与数据库的区别 数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。 数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，数据仓库在设计是有意引入冗余。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计。 数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策 面向主题：而数据仓库中的数据是按照一定的主题域进行组织。 集成：对原有分散的数据库数据经过系统加工,整理得到的消除源数据中的不一致性 相对稳定：一旦某个数据进入数据仓库以后只需要定期的加载、刷新 反映历史变化通过这些信息，对企业的发展历程和未来趋势做出定量分析预测数据仓库建设是一个工程，是一个过程，而不是一种可以购买的产品 企业数据处理方式: 以联机事务处理形式信息，以联机分析处理形式处理信息，并利用信息进行决策；在信息应用过程中管理信息。 OLAP基本概念 从动态的多维角度分析数据，对数据进行钻取，以获得更为精确的信息 数据库设计是信息系统开发和建设中的核心技术。 信息技术基础设施的定义 ? ?可以从技术和服务两个角度来 定义信息技术基础设施 从技术角度来看，信息技术基础设 施---运营整个企业所必需的硬件 设施和软件系统的集合。 ?从服务角度定义信息技术基 础设施更为恰当，信息技术基 础设施是整个企业范围内由管 理层所决定的包括人和技术能 力的服务的组合。 信息技术的普及性已经达到相当成熟的阶段 ?信息技术本身对企业来说不 可或缺；尽管能为整个行业带 来彻底的变化，但它已经不能 为单个企业提供战略性的竞争 优势；因为资源的稀缺性。?另一方面，不同企业应用信息技术 的能力差异很大 ?企业在利用信息技术改进业 务流程、创新业务、管理技巧 大数据技术部 建设数据仓库的八个步骤2017年04月25日编制 建设数据仓库的八个步骤 摘要：建立数据仓库是一个解决企业问题的过程，业务人员往往不懂如何建立和使用数据仓库，发挥其决策支持的作用；信息部门的人员往往又不懂业务，不知道应该建立哪些决策主题。 关键词：数据仓库元数据 建设数据仓库 建立数据仓库是一个解决企业问题的过程，业务人员往往不懂如何建立和使用数据仓库，发挥其决策支持的作用；信息部门的人员往往又不懂业务，不知道应该建立哪些决策主题，从数据源中抽取哪些数据。因此数据仓库的项目小组应该由业务人员和信息部门的人员共同组成，双方需要相互沟通，协作开发数据仓库。 开发数据仓库的过程包括以下几个步骤。 1.系统分析，确定主题 建立数据仓库的第一个步骤就是通过与业务部门的充分交流，了解建立数据仓库所要解决的问题的真正含义，确定各个主题下的查询分析要求。 业务人员往往会罗列出很多想解决的问题，信息部门的人员应该对这些问题进行分类汇总，确定数据仓库所实现的业务功能。一旦确定问题以后，信息部门的人员还需要确定一下几个因素： ·操作出现的频率，即业务部门每隔多长时间做一次查询分析。 ·在系统中需要保存多久的数据，是一年、两年还是五年、十年。 ·用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。 ·用户所能接受的响应时间是多长、是几秒钟，还是几小时。 由于双方在理解上的差异，确定问题和了解问题可能是一个需要多次往复的过程，信息部门的人员可能需要做一些原型演示给业务部门的人员看，以最终确定系统将要实现的功能确实是业务部门所需要的。 2.选择满足数据仓库系统要求的软件平台 在数据仓库所要解决的问题确定后，第二个步骤就是选择合适的软件平台，包括数据库、建模工具、分析工具等。这里有许多因素要考虑，如系统对数据量、响应时间、分析功能的要求等，以下是一些公认的选择标准： ·厂商的背景和支持能力，能否提供全方位的技术支持和咨询服务。 ·数据库对大数据量（TB级）的支持能力。 ·数据库是否支持并行操作。 ·能否提供数据仓库的建模工具，是否支持对元数据的管理。 ·能否提供支持大数据量的数据加载、转换、传输工具（ETT）。 ·能否提供完整的决策支持工具集，满足数据仓库中各类用户的需要。 3.建立数据仓库的逻辑模型 具体步骤如下： （1）确定建立数据仓库逻辑模型的基本方法。 （2）基于主题视图，把主题视图中的数据定义转到逻辑数据模型中。 （3）识别主题之间的关系。 （4）分解多对多的关系。 （5）用范式理论检验逻辑数据模型。 北京甲骨文软件有限公司咨询经理鲁百年博士 一、国内信息化的现状 1、信息化建设的发展历史： 在国内信息化建设过程中，基本上是按照当时业务系统的需求进行建设，例如：在一个企业中，财务部门为了减少工资发放的差错，提高发放的效率，先建设一个工资发放和管理程序；为了报账和核对的需求，建设一个财务管理程序；在银行首先为了业务处理的方便，将最基本的手工记帐和处理的业务建成一个系统，过一段时间，如果有新的业务推出，就再建设一个新的系统，或在原系统的基础上增加新的业务处理。这样的结果使每个系统和系统之间缺少真正的信息沟通和信息交换。 2、为何要建立数据仓库： 前面我们讲过，业务系统各自为政，相互独立。当很多业务系统建立后，由于领导的要求和决策的需求，需要一些指标的分析，在相应的业务系统基础上再增加分析和相应的报表功能，这样每个系统就增加了报表和分析功能。但是，由于数据源不统一导致了对同一个指标分析的结果不相同。为了解决该问题，Bell Inman提出了数据仓库的概念，其目的是为了分析和决策的需要，将相互分离的业务系统的数据源整合在一起，可以为领导和决策层提供分析和辅助决策。 3、国内企业对数据仓库建设认识的误区： 大家对数据仓库的认识是将业务系统的数据进行数据抽取、迁移和加载（ETL），将这些数据进行整合存放在一起，统一管理，需要什么样的分析就可提供什么样的分析，这就是数据仓库。这样做的结果是花了一年到两年的时间都无法将整个企业业务系统的数据整合在一起，花钱多、见效慢、风险大。一年后领导问起数据仓库项目时，回答往往是资金不足，人力不够，再投入一些资源、或者再延长半年的时间就会见到效果，但是往往半年过后还是仅仅可以看到十几张或者几十张报表。领导不满意，项目负责人压力也很大，无法交待。这时，项目经理或者项目负责人才意识到，项目有问题，但是谁也不敢说项目有问题，因为这样显然是自己当时的决策失误。怎么办？寻找咨询公司或者一些大的厂商，答案往往是数据仓库缺乏数据模型，应该考虑数据模型。如果建设时考虑到整个企业的数据模型，就可以建设成企业级的数据仓库（EDW）。什么是数据模型，就是满足整 数据仓库与数据库的区别 简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM 了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上， 目录 一、概述 (2) 二、四科室需求 (3) 1、风险科需求 (3) 2、市场科需求 (13) 3、业务管理科需求 (14) 4、计划资金科需求 (15) 三、需求分析 (23) 1、维表 (23) 2、事实表 (23) 3、事务——业务处理过程及业务术语 (23) 4、主键 (24) 5、外键 (24) 四、系统结构图及业务数据流图 (25) 1、系统结构图 (25) 2、数据流图 (26) 五、源数据表结构 (27) 1、BCS系统 (27) 2、C ARDPOOL系统 (34) 3、NAS系统 (36) 4、BCS系统报表 (37) 六、生成表结构 (39) 七、码表结构 (43) 八、结果表结构 (50) 九、数据表创建方法 (51) 1、BCS系统 (51) 2、C ARDPOOL系统 (57) 3、NAS系统 (58) 4、生成表 (58) 5、码表 (62) 十、数据处理过程 (68) 1、目录结构 (68) 2、流程说明 (68) 十一、问题及处理方法 (80) 一、概述 Bill Inmon（数据仓库之父）在Building the Data Warehouse （John Wiley & Sons Inc., 1996）书中把数据仓库描述为一个“面向主题的、完整的、非易失的、不同时间的、用于支持决策管理的数据集合”。 数据仓库是只用于制作报表的数据库。 对我们而言，数据仓库是某个“宽广”的数据仓储。它包括许多的主题领域。而一个数据集市，恰恰相反，它把眼睛盯在商业活动的某个非常有限的部分上。它往往涉及某个单独主题或单个类型的分析。 在日常工作中，IT人员经常听到这样的抱怨：“我要求的报表怎么还没出来？”或者是“我要对XX报表做些修改，怎么还没结果？”等等。 在IT飞速发展的最近几年里，银行信用卡部先后针对业务上了一些计算机系统。这些系统的特点是：信息量规模小、数据经常实时更新、适用于业务人员快速录入数据、使用模式相对来说是可以预测的、模式很复杂、业务流程难以更改、数据在线保存的时间较短及各系统之间缺乏必要的联系等。这样的系统被称之为OLTP系统。OLTP系统的这些特点也就决定了有如此抱怨。 如何解决这些问题呢？我们首先想到的是：把数据集中、完整地存储在中心数据库中。所有的业务处理在中心数据库上进行。所有的报表工作脱离数据库。这听起来难道不是有点像一个数据仓库吗？我们为什么不在OLTP的业务系统数据库的基础上生成报表呢？答案很简单：因为报表经常需要大量的、长时间的数据做依据，然后经过大量的运算，才能得出你想要的结论。这对业务系统的正常运转影响很大，以至于业务系统无法正常运转。 当然，不是什么时候都需要一个数据仓库的。正如数据仓库的定义：是用于支持决策管理的数据集合。 中国银行北京分行从1986年6月1日发行第一张人民币长城卡到现在拥有将近20万的持卡人。从过去手工处理业务到现在拥有几个OLTP业务系统。信用卡业务有了飞速的发展。但也应看到信用卡市场的激烈竞争。如何给决策者及时提供决策支持信息，是在激烈的市场竞争中立于不败之地的关键。 数据仓库建设 商务智能（Business Intelligence）用于支持制定业务决策的技能、流程、技术、应用和实践。核心是通过数据提取、整理、分析，最终通过分析结果制定有关策略、规划，帮助企业了解新的趋势、抓住新的市场机会、发现潜在的威胁，达到资源的合理配置，节约成本提高效益。数据仓库是商业智能的基础，它为OLAP、数据挖掘提供分析和决策支持。 一、数据仓库概念 1.数据仓库定义 是一个面向主题的、集成的、相对稳定的、反映有有历史变化的数据集合，用于支持管理决策。具有以下特点： ●详细交易及相关业务数据的集合 ●包含必要的内部与外部信息 ●来自于多个数据源、业务操作系统 ●保存一定的时间周期 ●按照企业内业务规则决定存储模型 2.建设的必要性 目前大多数信息系统由于建设时间、建设方、各阶段需求不同，会出现一系列问题：缺乏整体规则、信息缺乏完整性、缺乏统一的信息管理标准和规范、信息孤岛、不具备大容量的数据管理和分析能力。 3.价值 ●提高管理决策的科学性和管理效率 ●信息的整合，可推动现在有信息管理体系的重构 ●打通信息孤岛全局共享，降低数据获取的难度 ●逐渐取代各类业务管理报表系统 ●运用历史数据发现规律 二、数据仓库建设 1.业务需求定义 梳理出所有业务过程，分析业务内容提取需求，对其相关的数据进行探查，并对各系统核心业务人员访谈，准确的了解业务需求情况，近期调研 2.技术体系结构 生命周期图 技术架构图： 3.数据仓库数据建模 数据模型是抽象描述现实世界的一种方法，是通过抽象的实体及实体之间的联系来表示现实世界中事务的相互关系的一种映射，数据仓库模型是数据模型中针对特定的数据仓库应用系统的特定模型。数据仓库建模方法种类较多，常见的三种是范式建模、维度建模、实体建模，每种方法本质上都是从不同的角度解决业务中的问题。 关于数据仓库建模单独用一篇来详细介绍，这儿仅对维度建模做基本的介绍，维度建模由数据仓库领域另一位大师Ralph Kimall所倡导，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型， 一、概述 二、四科室需求 1、风险科需求... 2、市场科需求... 3、业务管理科需求 4、计划资金科需求 三、需求分析 1、维表........................... 2、事实表......................... 3、事务——业务处理过程及业务术语 4、主键........................... 5、外键........................... 四、系统结构图及业务数据流图 1、系统结构图 2、数据流图 五、源数据表结构 1、BCS 系统..... 2、C ARDPOOL 系统 3、NAS 系统..... 4、BCS 系统报表. 六、生成表结构 七、码表结构 八、结果表结构 九、数据表创建方法 1、BCS 系统..... 2、C ARDPOOL 系统 3、NAS 系统..... 4、生成表......... 5、码表.......... 十、数据处理过程 1、目录结构 2、流程说明 一、问题及处理方法目录 3 13 14 15 23 23 23 23 24 24 25 25 26 27 27 34 36 37 39 43 50 51 51 57 58 58 62 68 68 68 80 、概述 Bill Inmon （数据仓库之父）在Building the Data Warehouse （John Wiley & Sons Inc., 1996）书中把数据仓库描述为一个“面向主题的、完整的、非易失的、不同时间的、用于 支持决策管理的数据集合”。 数据仓库是只用于制作报表的数据库。 对我们而言，数据仓库是某个“宽广”的数据仓储。它包括许多的主题领域。而一个数据集市，恰恰相反，它把眼睛盯在商业活动的某个非常有限的部分上。它往往涉及某个单独主题或单个类型的分析。 在日常工作中，IT人员经常听到这样的抱怨：“我要求的报表怎么还没出来？” 或者是“我要对XX 报表做些修改，怎么还没结果？”等等。 在IT飞速发展的最近几年里，银行信用卡部先后针对业务上了一些计算机系统。这些系统的特点是：信息量规模小、数据经常实时更新、适用于业务人员快速录入数据、使用模式相对来说是可以预测的、模式很复杂、业务流程难以更改、数据在线保存的时间较短及各系统之间缺乏必要的联系等。这样的系统被称之为OLTP系统。OLTP系统的这些特点也就决定了有如此抱怨。 如何解决这些问题呢？我们首先想到的是：把数据集中、完整地存储在中心数据库中。 所有的业务处理在中心数据库上进行。所有的报表工作脱离数据库。这听起来难道不是有点像一个数据仓库吗？我们为什么不在OLTP的业务系统数据库的基础上生成报表呢？答 案很简单：因为报表经常需要大量的、长时间的数据做依据，然后经过大量的运算，才能得出你想要的结论。这对业务系统的正常运转影响很大，以至于业务系统无法正常运转。 当然，不是什么时候都需要一个数据仓库的。正如数据仓库的定义：是用于支持决策管理的数据集合。 中国银行北京分行从1986年6月1日发行第一张人民币长城卡到现在拥有将近20万的 持卡人。从过去手工处理业务到现在拥有几个OLTP业务系统。信用卡业务有了飞速的发 展。但也应看到信用卡市场的激烈竞争。如何给决策者及时提供决策支持信息，是在激烈的市场竞争中立于不败之地的关键。数据库与数据仓库的区别是什么
数据仓库建设方案详细
数据仓库-系统设计说明书
数据仓库建设方案84099
数据仓库的开发设计过程
数据仓库数据库设计的心得总结
数据仓库设计文档模板
数据仓库和数据库
数据仓库-系统设计说明书
数据仓库复习题
数据仓库与数据库的区别
建设数据仓库的八个步骤
数据仓库建设的几点建议.doc
数据仓库与数据库
数据仓库分析系统整体设计方案 (1).doc
数据仓库建设方案-2018-3-28
数据仓库分析系统整体设计方案
相关主题
文本预览