数据仓库系统(DWS)由数据仓库、仓库管理和分析工具三部分组成。
源数据：数据仓库的数据来源于多个数据源，包括企业内部数据、市场调查报告及各种文档之类的外部数据。
仓库管理: 在确定数据仓库信息需求后，首先进行数据建模，然后确定从源数据到数据仓库的数据抽取、清理和转换过程，最后划分维数及确定数据仓库的物理存储结构。元数据是数据仓库的核心，它用于存储数据模型和定义数据结构、转换规划、仓库结构、控制信息等。
数据仓库: 包括对数据的安全、归档、备份、维护、恢复等工作，这些工作需要利用数据库管理系统(DBMS)的功能。
分析工具用于完成实际决策问题所需的各种查询检索工具、多维数据的OLAP分析工具、数据开采DM工具等，以实现决策支持系统的各种要求。
数据仓库应用是一个典型的C/S结构。其客户端的工作包括客户交互、格式化查询及结果和报表生成等。服务器端完成各种辅助决策的SQL查询、复杂的计算和各类综合功能等。现在，一种越来越普遍的形式是三层结构，即在客户与服务器之间增加一个多维数据分析服务器。OLAP服务器能加强和规范决策支持的服务工作，集中和简化原客户端和DW服务器的部分工作，降低系统数据传输量，因此工作效率更高。
什么是联机分析处理(OLAP)
联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。
当今的数据处理大致可以分成两大类：联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。下表列出了OLTP与OLAP之间的比较。
OLAP是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或者满足在多维环境下特定的查询和报表需求,它的技术核心是"维"这个概念。
“维”是人们观察客观世界的角度,是一种高层次的类型划分。“维”一般包含着层次关系,这种层次关系有时会相当复杂。通过把一个实体的多项重要的属性定义为多个维(dimension)，使用户能对不同维上的数据进行比较。因此OLAP也可以说是多维数据分析工具的集合。
OLAP的基本多维分析操作有钻取(roll up和drill down)、切片(slice)和切块(dice)、以及旋转(pivot)、drill across、drill through等。
·钻取是改变维的层次，变换分析的粒度。它包括向上钻取(roll up)和向下钻取(drill down)。roll up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数;而drill down则相反，它从汇总数据深入到细节数据进行观察或增加新维。
·切片和切块是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片;如果有三个，则是切块。
·旋转是变换维的方向，即在表格中重新安排维的放置(例如行列互换)。
OLAP有多种实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP。
ROLAP 表示基于关系数据库的OLAP实现(Relational OLAP)。以关系数据库为核心,以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表:一类是事实表,用来存储数据和维关键字;另一类是维表,即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和外关键字联系在一起,形成了"星型模式"。对于层次复杂的维,为避免冗余数据占用过大的存储空间,可以使用多个表来描述,这种星型模式的扩展称为"雪花模式"。
MOLAP 表示基于多维数据组织的OLAP实现(Multidimensional OLAP)。以多维数据组织方式为核心,也就是说,MOLAP使用多维数组存储数据。多维数据在存储中将形成"立方块(Cube)"的结构,在MOLAP 中对"立方块"的"旋转"、"切块"、"切片"是产生多维数据报表的主要技术。
HOLAP表示基于混合数据组织的OLAP实现(Hybrid OLAP)。如低层是关系型的，高层是多维矩阵型的。这种方式具有更好的灵活性。
还有其他的一些实现OLAP的方法，如提供一个专用的SQL Server，对某些存储模式(如星型、雪片型)提供对SQL查询的特殊支持。
OLAP 工具是针对特定问题的联机数据访问与分析。它通过多维的方式对数据进行分析、查询和报表。维是人们观察数据的特定角度。例如，一个企业在考虑产品的销售情况时，通常从时间、地区和产品的不同角度来深入观察产品的销售情况。这里的时间、地区和产品就是维。而这些维的不同组合和所考察的度量指标构成的多维数组则是OLAP分析的基础，可形式化表示为(维1，维2，……，维n，度量指标)，如(地区、时间、产品、销售额)。多维分析是指对以多维形式组织起来的数据采取切片(Slice)、切块(Dice)、钻取(Drill-down和Roll-up)、旋转(Pivot)等各种分析动作，以求剖析数据，使用户能从多个角度、多侧面地观察数据库中的数据，从而深入理解包含在数据中的信息。
根据综合性数据的组织方式的不同，目前常见的OLAP主要有基于多维数据库的MOLAP 及基于关系数据库的ROLAP两种。MOLAP是以多维的方式组织和存储数据，ROLAP则利用现有
的关系数据库技术来模拟多维数据。在数据仓库应用中，OLAP应用一般是数据仓库应用的前端工具，同时OLAP工具还可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。
数据抽取、清洗与转换 BI项目中ETL设计
作者: , 出处:ITPub, 责任编辑: 叶江, 2007-05-14 13:39
ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析的依据ETL是BI项目最重要的一个环节，通常情况下ETL会花掉整个项目的1/3的时间，ETL 设计的好坏直接关接到BI项目的成败。ETL也是一个长期的过程，只有不断的发现问题并解决问题，才能使ETL运行效率更高，为项目后期开发提供准确的数据。
ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候也是从这三部分出发。数据的抽取是从各个不同的数据源抽取到ODS中(这个过程也可以做一些数据的清洗和转换)，在抽取的过程中需要挑选不同的抽取方法，尽可能的提高ETL的运行效率。ETL三个部分中，花费时间最长的是T(清洗、转换)的部分，一般情况下这部分工作量是整个ETL的2/3。数据的加载一般在数据清洗完了之后直接写入DW中去。
ETL的实现有多种方法，常用的有三种，第一种是借助ETL工具如Oracle的OWB、SQL server 2000的DTS、SQL Server2005的SSIS服务、informatic等实现，第二种是SQL方式实现，第三种是ETL工具和SQL相结合。前两种方法各有优缺点，借助工具可以快速的建立起ETL工程，屏蔽复杂的编码任务，提高速度，降低难度，但是欠缺灵活性。SQL的方法优点是灵活，提高ETL运行效率，但是编码复杂，对技术要求比较高。第三种是综合了前面二种的优点，极大的提高ETL的开发速度和效率。
数据的抽取
数据的抽取需要在调研阶段做大量工作，首先要搞清楚以下几个问题：数据是从几个业务系统中来?各个业务系统的数据库服务器运行什么DBMS?是否存在手工数据，手工数据量有多大?是否存在非结构化的数据?等等类似问题，当收集完这些信息之后才可以进行数据抽取的设计。
1、与存放DW的数据库系统相同的数据源处理方法
这一类数源在设计比较容易，一般情况下，DBMS(包括SQLServer，Oracle)都会提供数据库链接功能，在DW数据库服务器和原业务系统之间建立直接的链接关系就可以写Select 语句直接访问。
2、与DW数据库系统不同的数据源的处理方法。
这一类数据源一般情况下也可以通过ODBC的方式建立数据库链接，如SQL Server和Oracle之间。如果不能建立数据库链接，可以有两种方式完成，一种是通过工具将源数据导出成.txt或者是.xls文件，然后再将这些源系统文件导入到ODS中。另外一种方法通过程序接口来完成。
3、对于文件类型数据源(.txt,，xls)，可以培训业务人员利用数据库工具将这些数据导入到指定的数据库，然后从指定的数据库抽取。或者可以借助工具实现，如SQL SERVER 2005 的SSIS服务的平面数据源和平面目标等组件导入ODS中去。
4、增量更新问题
对于数据量大的系统，必须考虑增量抽取。一般情况，业务系统会记录业务发生的时间，可以用作增量的标志，每次抽取之前首先判断ODS中记录最大的时间，然后根据这个时间去业务系统取大于这个时间的所有记录。利用业务系统的时间戳，一般情况下，业务系统没有或者部分有时间戳。
数据的清洗转换
一般情况下，数据仓库分为ODS、DW两部分，通常的做法是从业务系统到ODS做清洗，将脏数据和不完整数据过滤掉，再从ODS到DW的过程中转换，进行一些业务规则的计算和聚合。
1、数据清洗
数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据和重复的数据三大类。
A、不完整的数据，其特征是是一些应该有的信息缺失，如供应商的名称，分公司的名称，客户的区域信息缺失、业务系统中主表与明细表不能匹配等。需要将这一类数据过滤出来，按缺失的内容分别写入不同Excel文件向客户提交，要求在规定的时间内补全。补全后才写入数据仓库。
B、错误的数据，产生原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车、日期格式不正确、日期越界等。这一类数据也要分类，对于类似于全角字符、数据前后有不面见字符的问题只能写SQL的方式找出来，然后要求客户在业务系统修正之后抽取;日期格式不正确的
或者是日期越界的这一类错误会导致ETL运行失败，这一类错误需要去业务系统数据库用SQL 的方式挑出来，交给业务主管部门要求限期修正，修正之后再抽取。
C、重复的数据，特别是维表中比较常见，将重复的数据的记录所有字段导出来，让客户确认并整理。
数据清洗是一个反复的过程，不可能在几天内完成，只有不断的发现问题，解决问题。对于是否过滤、是否修正一般要求客户确认;对于过滤掉的数据，写入Excel文件或者将过滤数据写入数据表，在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快的修正错误，同时也可以作为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉了，对于每个过滤规则认真进行验证，并要用户确认才行。
2、数据转换
数据转换的任务主要是进行不一致的数据转换、数据粒度的转换和一些商务规则的计算。
A、不一致数据转换，这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是XX0001，而在CRM中编码是YY0001，这样在抽取过来之后统一转换成一个编码。
B、数据粒度的转换，业务系统一般存储非常明细的数据，而数据仓库中的数据是用来分析的，不需要非常明细的数据，一般情况下，会将业务系统数据按照数据仓库粒度进行聚合。
C、商务规则的计算，不同的企业有不同的业务规则，不同的数据指标，这些指标有的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了之后存储在数据仓库中，供分析使用。
ETL日志与警告发送
1、ETL日志，记录日志的目的是随时可以知道ETL运行情况，如果出错了，出错在那里。
ETL日志分为三类。第一类是执行过程日志，是在ETL执行过程中每执行一步的记录，记录每次运行每一步骤的起始时间，影响了多少行数据，流水账形式。第二类是错误日志，当某个模块出错的时候需要写错误日志，记录每次出错的时间，出错的模块以及出错的信息等。第三类日志是总体日志，只记录ETL开始时间，结束时间是否成功信息。
如果使用ETL工具，工具会自动产生一些日志，这一类日志也可以作为ETL日志的一部分。
2、警告发送
ETL出错了，不仅要写ETL出错日志而且要向系统管理员发送警告，发送警告的方式有多种，常用的就是给系统管理员发送邮件，并附上出错的信息，方便管理员排查错误。
数据挖掘技术简介
作者: , 出处:专家博客, 责任编辑: 金璞, 2006-12-14 08:00
摘要：数据挖掘是目前一种新的重要的研究领域。本文介绍了数据挖掘的概念、目的、常用方法、数据挖掘过程、数据挖掘软件的评价方法。对数据挖掘领域面临的问题做了介绍和展望。关键词：数据挖掘数据集合
摘要：数据挖掘是目前一种新的重要的研究领域。本文介绍了数据挖掘的概念、目的、常用方法、数据挖掘过程、数据挖掘软件的评价方法。对数据挖掘领域面临的问题做了介绍和展望。
关键词：数据挖掘数据集合
1. 引言
数据挖掘(Data Mining)是从大量的、不完全的、有噪声的、模糊的、随机的数据中提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。随着信息技术的高速发展，人们积累的数据量急剧增长，动辄以TB计，如何从海量的数据中提取有用的知识成为当务之急。数据挖掘就是为顺应这种需要应运而生发展起来的数据处理技术。是知识发现(Knowledge Discovery in Database)的关键步骤。
2. 数据挖掘的任务
数据挖掘的任务主要是关联分析、聚类分析、分类、预测、时序模式和偏差分析等。
⑴关联分析(association analysis)
关联规则挖掘是由Rakesh Apwal等人首先提出的。两个或两个以上变量的取值之间存在某种规律性，就称为关联。数据关联是数据库中存在的一类重要的、可被发现的知识。关联分为简单关联、时序关联和因果关联。关联分析的目的是找出数据库中隐藏的关联网。一般用支持度和可信度两个阀值来度量关联规则的相关性，还不断引入兴趣度、相关性等参数，使得所挖掘的规则更符合需求。
⑵聚类分析(clustering)
聚类是把数据按照相似性归纳成若干类别，同一类中的数据彼此相似，不同类中的数据相异。聚类分析可以建立宏观的概念，发现数据的分布模式，以及可能的数据属性之间的相互关系。
⑶分类(classification)
分类就是找出一个类别的概念描述，它代表了这类数据的整体信息，即该类的内涵描述，并用这种描述来构造模型，一般用规则或决策树模式表示。分类是利用训练数据集通过一定的算法而求得分类规则。分类可被用于规则描述和预测。
⑷预测(predication)
预测是利用历史数据找出变化规律，建立模型，并由此模型对未来数据的种类及特征进行预测。预测关心的是精度和不确定性，通常用预测方差来度量。
⑸时序模式(time-series pattern)
时序模式是指通过时间序列搜索出的重复发生概率较高的模式。与回归一样，它也是用己知的数据预测未来的值，但这些数据的区别是变量所处时间的不同。
⑹偏差分析(deviation)
在偏差中包括很多有用的知识，数据库中的数据存在很多异常情况，发现数据库中数据存在的异常情况是非常重要的。偏差检验的基本方法就是寻找观察结果与参照之间的差别。
3.数据挖掘对象
根据信息存储格式，用于挖掘的对象有关系数据库、面向对象数据库、数据仓库、文本数据源、多媒体数据库、空间数据库、时态数据库、异质数据库以及Internet等。
4.数据挖掘流程
⑴定义问题：清晰地定义出业务问题，确定数据挖掘的目的。
⑵数据准备：数据准备包括：选择数据--在大型数据库和数据仓库目标中提取数据挖掘的目标数据集;数据预处理--进行数据再加工，包括检查数据的完整性及数据的一致性、去噪
声，填补丢失的域，删除无效数据等。
⑶数据挖掘：根据数据功能的类型和和数据的特点选择相应的算法，在净化和转换过的数据集上进行数据挖掘。
⑷结果分析：对数据挖掘的结果进行解释和评价，转换成为能够最终被用户理解的知识。
⑸知识的运用：将分析所得到的知识集成到业务信息系统的组织结构中去。
5.数据挖掘的方法
⑴神经网络方法
神经网络由于本身良好的鲁棒性、自组织自适应性、并行处理、分布存储和高度容错等特性非常适合解决数据挖掘的问题，因此近年来越来越受到人们的关注。典型的神经网络模型主要分3大类：以感知机、BP反向传播模型、函数型网络为代表的，用于分类、预测和模式识别的前馈式神经网络模型;以Hopfield的离散模型和连续模型为代表的，分别用于联想记忆和优化计算的反馈式神经网络模型;以ART模型、Koholon模型为代表的，用于聚类的自组织映射方法。神经网络方法的缺点是"黑箱"性，人们难以理解网络的学习和决策过程。
⑵遗传算法
遗传算法是一种基于生物自然选择与遗传机理的随机搜索算法，是一种仿生全局优化方法。遗传算法具有的隐含并行性、易于和其它模型结合等性质使得它在数据挖掘中被加以应用。
Sunil已成功地开发了一个基于遗传算法的数据挖掘工具，利用该工具对两个飞机失事的真实数据库进行了数据挖掘实验，结果表明遗传算法是进行数据挖掘的有效方法之一[4]。遗传算法的应用还体现在与神经网络、粗集等技术的结合上。如利用遗传算法优化神经网络结构，在不增加错误率的前提下，删除多余的连接和隐层单元;用遗传算法和BP算法结合训练神经网络，然后从网络提取规则等。但遗传算法的算法较复杂，收敛于局部极小的较早收敛问题尚未解决。
⑶决策树方法
决策树是一种常用于预测模型的算法，它通过将大量数据有目的分类，从中找到一些有价值的，潜在的信息。它的主要优点是描述简单，分类速度快，特别适合大规模的数据处理。最有影响和最早的决策树方法是由Quinlan提出的著名的基于信息熵的ID3算法。它的主要问题是：ID3是非递增学习算法;ID3决策树是单变量决策树，复杂概念的表达困难;同性间的相互关系强调不够;抗噪性差。针对上述问题，出现了许多较好的改进算法，如 Schlimmer 和Fisher设计了ID4递增式学习算法;钟鸣，陈文伟等提出了IBLE算法等。
⑷粗集方法
粗集理论是一种研究不精确、不确定知识的数学工具。粗集方法有几个优点：不需要给出额外信息;简化输入信息的表达空间;算法简单，易于操作。粗集处理的对象是类似二维关系表的信息表。目前成熟的关系数据库管理系统和新发展起来的数据仓库管理系统，为粗集的数据挖掘奠定了坚实的基础。但粗集的数学基础是集合论，难以直接处理连续的属性。而现实信息表中连续属性是普遍存在的。因此连续属性的离散化是制约粗集理论实用化的难点。现在国际上已经研制出来了一些基于粗集的工具应用软件，如加拿大Regina大学开发的KDD-R;美国Kansas大学开发的LERS等。
⑸覆盖正例排斥反例方法
它是利用覆盖所有正例、排斥所有反例的思想来寻找规则。首先在正例集合中任选一个种子，到反例集合中逐个比较。与字段取值构成的选择子相容则舍去，相反则保留。按此思想循环所有正例种子，将得到正例的规则(选择子的合取式)。比较典型的算法有Michalski 的AQ11方法、洪家荣改进的AQ15方法以及他的AE5方法。
⑹统计分析方法
在数据库字段项之间存在两种关系：函数关系(能用函数公式表示的确定性关系)和相关关系(不能用函数公式表示，但仍是相关确定性关系)，对它们的分析可采用统计学方法，即利用统计学原理对数据库中的信息进行分析。可进行常用统计(求大量数据中的最大值、最小值、总和、平均值等)、回归分析(用回归方程来表示变量间的数量关系)、相关分析(用相关系数来度量变量间的相关程度)、差异分析(从样本统计量的值得出差异来确定总体参数之间是否存在差异)等。
⑺模糊集方法
即利用模糊集合理论对实际问题进行模糊评判、模糊决策、模糊模式识别和模糊聚类分析。系统的复杂性越高，模糊性越强，一般模糊集合理论是用隶属度来刻画模糊事物的亦此亦彼性的。李德毅等人在传统模糊理论和概率统计的基础上，提出了定性定量不确定性转换模型--云模型，并形成了云理论。
6.评价数据挖掘软件需要考虑的问题
越来越多的软件供应商加入了数据挖掘这一领域的竞争。用户如何正确评价一个商业软件，选择合适的软件成为数据挖掘成功应用的关键。
评价一个数据挖掘软件主要应从以下四个主要方面：
⑴计算性能：如该软件能否在不同的商业平台运行;软件的架构;能否连接不同的数据源;操作大数据集时，性能变化是线性的还是指数的;算的效率;是否基于组件结构易于扩展;运行的稳定性等;
⑵功能性：如软件是否提供足够多样的算法;能否避免挖掘过程黑箱化;软件提供的算法
能否应用于多种类型的数据;用户能否调整算法和算法的参数;软件能否从数据集随机抽取数据建立预挖掘模型;能否以不同的形式表现挖掘结果等;
⑶可用性：如用户界面是否友好;软件是否易学易用;软件面对的用户：初学者，高级用户还是专家?错误报告对用户调试是否有很大帮助;软件应用的领域：是专攻某一专业领域还是适用多个领域等;
⑷辅助功能：如是否允许用户更改数据集中的错误值或进行数据清洗;是否允许值的全局替代;能否将连续数据离散化;能否根据用户制定的规则从数据集中提取子集;能否将数据中的空值用某一适当均值或用户指定的值代替;能否将一次分析的结果反馈到另一次分析中，等等。
7.结束语
数据挖掘技术是一个年轻且充满希望的研究领域，商业利益的强大驱动力将会不停地促进它的发展.每年都有新的数据挖掘方法和模型问世，人们对它的研究正日益广泛和深入。尽管如此，数据挖掘技术仍然面临着许多问题和挑战：如数据挖掘方法的效率亟待提高，尤其是超大规模数据集中数据挖掘的效率;开发适应多数据类型、容噪的挖掘方法，以解决异质数据集的数据挖掘问题;动态数据和知识的数据挖掘;网络与分布式环境下的数据挖掘等;另外，近年来多媒体数据库发展很快，面向多媒体数据库的挖掘技术和软件今后将成为研究开发的热点。
BI和ERP是互补的系统
作者: 佚名, 出处:中国商业智能网 , 责任编辑: 丁一凡, 2005-01-18 16:24 如何只用一句话就能使商业信息（Business Information 简称BI）、决策支持等新架构体系对用户产生新的诱惑力呢？
如何只用一句话就能使商业信息（Business Information 简称BI）、决策支持等新架构体系对用户产生新的诱惑力呢？BI是架构在ERP之上的，而决策支持是在BI基础上的再扩展。也就是说，新的架构体系使行业用户能够在现有企业数据仓库之上再创建一个“虚拟”企业，这意味着什么呢？
简单的说，就是行业用户可将现有的数据仓库资源整合到一个分布式的BI网络环境当中。像ERP一样，它是一种自上而下的透视方法。它能提高行业用户相关商业目标的执行潜力，并允许用户重组一种更精准的部门级操作流程；然后创建出整个公司目标执行的实时监视体系。
BI Vs ERP
在ERP环境中安装数据仓库是一个相当经济的建议。因为，从基础架构的角度上看，BI 数据库和ERP有许多共通之处。两者都采用分布式架构存储海量数据，因此，双方进行融合的可能性很大；两者都为大范围终端用户提供深度访问的能力；两者都具有高度的分布性和应用程序的可扩展性，尽管这种特性在BI上体现得不是很明显；两者基于同样的前提。即利用直接或者间接数据作为预测工作的信息参考。
在过去10年中，ERP技术和BI都有重大的发展，但它们的发展道路或多或少是并行的。两者的商业判断能力都有赖于信息技术，但功能特点却各自针对于商业智能（business intelligence）和业绩跟踪（performance tracking）的不同方面。
虽然存在类似之处，但BI和ERP绝对不是同一事物或是同一事物体的两个方面，它们是互补的系统。
它们最大的共性就是，它们使企业运行得更有效率、响应更及时并易于整合。因此，已实施了ERP的企业需要BI是显而易见的。
调高用户期望
行业客户实施ERP之后, 就建立起了新的业务处理模式。ERP系统所涉及的所有业务流程通过整合彼此协调，打破了原有的部门分割局面。公司内所有环节的信息获知能力都得到了提升，企业内外的业务处理瓶颈将被打破，响应速度也能相应改善。
BI能提高行业用户在关键领域的信息获知能力及掌控精度。首先，报告格式将大大改良,整合后的用户数据无疑使报告进行得更快、更及时、更精确。其次, 信息传输也将越来越实时化，在各部门周转时间将大为减少。最后，业务处理流程当中可能出现的问题和失误也易于及时发现，从而使纠错工作更加迅速和准确。
通过BI, 孤立、分散的企业数据按历史记录顺序彼此相关了，而且能按高效、易于提取的结构进行存储；行业用户由此就可以按不同的透视方法进行快速分析。与传输数据不同，一旦信息进入数据仓库或局部领域的数据集市，它就不可改变。它成为了分析型数据，而非传输型数据。因此，行业用户可以做的分析就不再是简单的总结，他们可以按自己设置的分析方法对数据进行任何深度的分析。这种数据仓库按照执行快速、灵活可变的形式组织起来，数据访问变得异常简便（用户不需专门应用软件就能访问，就像从书架上取下一本书一样方便）。
确定商业主题
接下来的环节就是重新定义信息及其应用方法。记录、文档等旧有概念已经过时。然而从行业用户的应用系统迁移开始,ERP数据库的应用环境变化却没能改变这种思维定式。
当今世界，行业用户面对的是一个崭新竞争环境,即商业目标(business object)精确实现的世界。商业目标的执行力并不依赖于时间的不同或管理级别的差异,这个目标不管是正执行的还是已经执行过的,都应该传达给企业各个层面，如部门级、公司级等。每个小目标的实现都可能对整个公司产生大的推动力。
商业目标实际上是一种信息“包”，它的作用要看行业用户对它如何定义以及如何处理。行业用户可以将它看成是一位虚拟化的员工，赋与它特定的工作职能，即它能胜任各种应用。
为了理解商业目标, 就必须首先知道元数据（Metadata）的概念。元数据是一种用来描述实际数据的信息;它主要用于应用程序和分析流程当中的数据交流工作。元数据是一种构建数据库的基本素材，它将用来构建BI数据模型。
商业目标对信息而言不仅是一种模板，它将定义出能被数据信息完成的商业任务，以及主要执行者的任务（从这个层面上说，商业目标是一名虚拟员工）。在此,定义一个数据模型的简便之处并没有被夸大。数据仓库涉及的终端用户都能获知这些任务信息;各部门的中层管理者都可以自己设置所需要的分析功能;从而打破部门分割的局限，帮助决策层进行管理。试想一下,如果一个公司CIO进行本地存货运输成本分析所使用的“成本会计”主题报告,一名基层仓库管理员在工作岗位上也可以及时使用，那么,该公司商品交易信息的时效性和精确性就会大大提高。此CIO就能及时确定该公司是否降低公司目录中的产品数量。
如何实现
在实际建造系统之时，行业用户的顾虑也不必太多，BI可以从很小的系统开始，而且它只需往ERP里面添加信息，而不是重建一个系统。BI平台独特之处是，在一种高度整合的ERP 环境下，它通常被隐藏于底层。为了简便起见，BI主要数据来源毫无疑问就是ERP数据库。BI是一种组织完善的表格驱动系统，在系统中，ERP数据库和ERP应用系统通过接口界面紧
密结合，元数据在它们之间流动；提取器（Extractors）从传输系统中提取合适的信息，然后将信息放入以商业目标为导向的数据库体系当中（程序编程接口API也在这个阶段进行工作）。
接下来就是BI引擎，它包含信息来源管理和转换系统、装载系统等。信息来源管理系统主要用于跟踪信息从何处来、到哪里去，它还定义所有的传输活动；转换、装载系统主要负责必要的数据规范操作。随后是元数据，这是一系列用功能术语完成信息定义工作。从这里开始, 建模、分析、相关主题展示等高级功能就开始运行。在此必须强调的是，数据仓库中的信息主要用于数据分析，它无法被BI用户修改或者升级。
数据建模师谈建模方法及技巧
作者: ocanod, 出处:博客, 责任编辑: 金璞, 2007-01-12 00:00
笔者从98年进入数据库及数据仓库领域工作至今已经有近八年的时间，对数据建模
工作接触的比较多，创新性不敢谈，本文只是将工作中的经验总结出来，供大家一同探讨和指正。提起数据建模来，有一点是首先要强调的，数据建模师和DBA有着较大的不同，对数据建模师来说，对业务的深刻理解是第一位的，不同的建模方法和技巧是为业务需求来服务的。而本文则暂时抛开业务不谈，主要关注于建模方法和技巧的经验总结。
笔者从98年进入数据库及数据仓库领域工作至今已经有近八年的时间，对数据建模工作接触的比较多，创新性不敢谈，本文只是将工作中的经验总结出来，供大家一同探讨和指正。
提起数据建模来，有一点是首先要强调的，数据建模师和DBA有着较大的不同，对数据建模师来说，对业务的深刻理解是第一位的，不同的建模方法和技巧是为业务需求来服务的。而本文则暂时抛开业务不谈，主要关注于建模方法和技巧的经验总结。
从目前的数据库及数据仓库建模方法来说，主要分为四类。
第一类是大家最为熟悉的关系数据库的三范式建模，通常我们将三范式建模方法用于建立各种操作型数据库系统。
第二类是Inmon提倡的三范式数据仓库建模，它和操作型数据库系统的三范式建模在侧重点上有些不同。Inmon的数据仓库建模方法分为三层，第一层是实体关系层，也即企业的业务数据模型层，在这一层上和企业的操作型数据库系统建模方法是相同的;第二层是数据项集层，在这一层的建模方法根据数据的产生频率及访问频率等因素与企业的操作型数据库系统的建模方法产生了不同;第三层物理层是第二层的具体实现。
第三类是Kimball提倡的数据仓库的维度建模，我们一般也称之为星型结构建模，有时也加入一些雪花模型在里面。维度建模是一种面向用户需求的、容易理解的、访问效率高的建模方法，也是笔者比较喜欢的一种建模方式。
第四类是更为灵活的一种建模方式，通常用于后台的数据准备区，建模的方式不拘一格，以能满足需要为目的，建好的表不对用户提供接口，多为临时表。
下面简单谈谈第四类建模方法的一些的经验。
数据准备区有一个最大的特点，就是不会直接面对用户，所以对数据准备区中的表进行操作的人只有ETL工程师。ETL工程师可以自己来决定表中数据的范围和数据的生命周期。下面举两个例子：
1)数据范围小的临时表
当需要整合或清洗的数据量过大时，我们可以建立同样结构的临时表，在临时表中只保留我们需要处理的部分数据。这样，不论是更新还是对表中某些项的计算都会效率提高很多。处理好的数据发送入准备加载到数据仓库中的表中，最后一次性加载入数据仓库。
2)带有冗余字段的临时表
由于数据准备区中的表只有自己使用，所以建立冗余字段可以起到很好的作用而不用承
担风险。
举例来说，笔者在项目中曾遇到这样的需求，客户表{客户ID，客户净扣值}，债项表{债项ID，客户ID，债项余额，债项净扣值}，即客户和债项是一对多的关系。其中，客户净扣值和债项余额已知，需要计算债项净扣值。计算的规则是按债项余额的比例分配客户的净扣值。这时，我们可以给两个表增加几个冗余字段，如客户表{客户ID，客户净扣值，客户余额}，债项表{债项ID，客户ID，债项余额，债项净扣值，客户余额，客户净扣值}。这样通过三条SQL就可以直接完成整个计算过程。将债项余额汇总到客户余额，将客户余额和客户净扣值冗余到债项表中，在债项表中通过(债项余额×客户净扣值/客户余额)公式即可直接计算处债项净扣值。
另外还有很多大家可以发挥的建表方式，如不需要主键的临时表等等。总结来说，正因为数据准备区是不对用户提供接口的，所以我们一定要利用好这一点，以给我们的数据处理工作带来最大的便利为目的来进行数据准备区的表设计。
行业借鉴经验：
数据仓库架构经验谈
对于数据仓库的架构方法，不同的架构师有不同的原则和方法，笔者在这里来总结一下当前常采用的架构方式及其优缺点。这些架构方式不限于某个行业，可以供各个行业借鉴使用。
首先需要说明的一点是，目前在数据仓库领域比较一致的意见是在数据仓库中需要保留企业范围内一致的原子层数据。而独立的数据集市架构(Independent data marts)没有企业范围内一致的数据，很可能会导致信息孤岛的产生，除非在很小的企业内或只针对固定主题，否则不建议建立这样的架构方式。联邦式的数据仓库架构(Federated Data Warehouse Architecture)不管是在地域上的联邦还是功能上的联邦都需要先在不同平台上建立各自的数据仓库，再通过参考(reference)数据来实现整合，而这样很容易造成整合的不彻底，除非联邦式的数据仓库架构也采用Kimball的总线架构(Bus Architecture)中类似的功能，即在数据准备区保留一致性维度(Conformed Table)并不断更新它。所以，这两种架构方式不在讨论范围之内。下面主要讨论剩下的三种架构方式。
1)三范式(3NF)的原子层+数据集市
这样的数据仓库架构最大的倡导者就是数据仓库之父Inmon，而他的企业信息工厂(Corporate Information System)就是典型的代表。这样的架构也称之为企业数据仓库(Enterprise Data Warehouse，EDW)。企业信息工厂的实现方式是，首先进行全企业的数据整合，建立企业信息模型，即EDW。对于各种分析需求再建立相应的数据集市或者探索仓库，其数据来源于EDW。三范式的原子层给建立OLAP带来一定的复杂性，但是对于建立更复杂的应用，如挖掘仓库、探索仓库提供了更好的支持。这类架构的建设周期比较长，相应的成本也比较高。
2)星型结构(Star Schema)的原子层+HOLAP
星型结构最大的倡导者是Kimall，他的总线架构是该类架构的典型代表。总线架构实现方式是，首先在数据准备区中建立一致性维度、建立一致性事实的计算方法;其次在一致性维度、一致性事实的基础上逐步建立数据集市。每次增加数据集市，都会在数据准备区整合一致性维度，并将整合好的一致性维度同步更新到所有的数据集市。这样，建立的所有数据集市合在一起就是一个整合好的数据仓库。正是因为总线架构这个可以逐步建立的特点，它的开发周期比其他架构方式的开发周期要短，相应的成本也要低。在星型结构的原子层上可以直接建立聚集，也可以建立HOLAP。笔者比较倾向于Kimball的星型结构的原子层架构，在这种架构中的经验也比较多。
3)三范式(3NF)的原子层+ROLAP
这样的数据仓库架构也称为集中式架构(Centralized Architecture)，思路是在三范式的原子层上直接建立ROLAP，做的比较出色的就是MicroStrategy。在三范式的原子层上定义ROLAP比在星型结构的原子层上定义ROLAP要复杂很多。采用这种架构需要在定义ROLAP是多下些功夫，而且ROLAP的元数据不一定是通用的格式，所以对ROLAP做展现很可能会受到工具的局限。这类架构和第一类很相似，只是少了原子层上的数据集市。
总结来说，这三种数据仓库的架构方式都是不错的选择。对于需要见效快、成本低的项目可以考虑采用第二种总线架构，对于资金充足并有成熟业务数据模型的企业可以考虑采用第一种架构或第三种架构。
应用难点技巧：
变化数据捕获经验谈
在数据仓库系统中，一个很重要的目的就是保留数据的历史变化信息。而变化数据捕获(Change Data Capture，CDC)就是为这个目的而产生的一项技术。变化数据捕获常用的方法有：1)文件或者表的全扫描对比，2)DBMS日志获取，3)在源系统中增加触发器获取，4)基于源系统的时间戳获取，5)基于复制技术的获取，6)DBMS提供的变化数据捕获方法等。其中，由DBMS提供变化数据捕获的方法是大势所趋，即具体的捕获过程由DBMS来完成。
像银行、电信等很多行业的操作记录生成后就不会改变，只有像客户、产品等信息会随时间发生缓慢的变化，所以通常的变化数据捕获是针对维度表而言的。Kimball对缓慢变化维的分析及应对策略基本上可以处理维度表的各种变化。
而对于一些零售行业，像合同表中的合同金额类似的数值在录入后是有可能会发生改变的，也就是说事实表的数据也有可能发生变化。通常对于事实表数据的修改属于勘误的范畴，可以采用类似缓慢变化维TYPE 1的处理方式直接更新事实表。笔者不太赞同对事实表的变化采用快照的方式插入一条新的事实勘误记录，这样会给后续的展现、分析程序带来太多的麻烦。
接下来要讨论的是笔者曾经遇到的一个颇为棘手的事实表数据改变的问题，该事实表的主键随表中某些数据的变化发生改变。以其中的一个合同表为例，该合同表的主键是由“供
货单位编号”+“合同号”生成的智能主键，当其中的“供货单位编号”和“合同号”中任何一个发生变化时，该合同表的主键都会发生变化，给变化数据捕获带来了很大的麻烦。
项目中，笔者的处理方式是采用触发器的办法来实现变化数据捕获。具体的实现方式是：
1)建立一个新表作为保存捕获的数据表使用，其中字段有“原主键”、“修改后主键”、及其他需要的字段，称为“合同捕获表”。
2)在原合同表Delete和Update时分别建立触发器，当删除操作发生时，建在Delete 上的触发器会插入一条记录到“合同捕获表”，其中“修改后主键”字段为空，表示该记录是删除的记录;当发生更新时，将“原主键”、“修改后主键”及其他需要记录的字段都保存入“合同捕获表”中，表示该记录被修改过，如果“原主键”和“修改后主键”不同，则表示主键被修改，如果相同，则表示主键没有被修改。
3)由于操作系统中的主键通常会成为数据仓库中事实表的退化维度，可能仍会起主键的作用。所以在数据加载时，需要分情况判断“合同捕获表”的数据来决定是否更新事实表中的退化维度。
可以说，这样的基于触发器的变化数据捕获方法并不是一个很好的选择。首先这需要对源系统有较大的权限;其次，触发器会给源系统的性能带来很大的影响。所以除非是没有别的选择，否则不建议采用这种方法。
而对于这样的情况，我们在建立操作型数据库系统时完全可以避免。下面是对操作型数据库系统建立者的几点建议：1)操作型系统的主键不要建立成智能型的，至少不要建立成会变化的。2)操作型系统的表中需要加入操作人和操作时间字段，或者直接加入时间戳。3)操作型系统中操作型数据最好不要直接在原值上修改，可以采用“冲红”的方式加入新的记录。这样后续建立数据仓库时就不需要考虑事实表数据的变化问题。
最后，期待各大数据库管理系统的厂商能尽快在DBMS层提供功能强大、简单好用的变化数据捕获功能，目前Oracle已经有了这个功能。毕竟技术方面复杂的事情留给厂商做是一个趋势，而我们做应用的则更关注于业务。
关于数据仓库数据质量问题探讨
作者: 黄鹏 , 出处:IT168, 责任编辑: 叶江, 2007-03-10 11:49
数据仓库的数据来自于多个数据源，所以数据的一致性很难得到保证，既然没有绝对的准确，那么就需要制定一个标准
一、数据质量和清洗
ETL是数据仓库的最重要的基础，良好的ETL从业务系统中抽取数据，转换数据质量，保证数据一致性，这样才能够保证各个独立的不同的数据源能够集成到一起，最终只有这样才能真正达到决策支持的目的。
数据清洗是ETL系统的一个最重要的步骤，数据的抽取和加载也是很必要的，但是他们只负责数据的迁移和重组格式。只有数据清洗才能真正改变数据，并且为了目标提供高质量的数据保证。
高质量数据意味着：
正确的。数据的值和描述一定是真实的和业务系统保持一致的。
明确的。数据的值和描述有且只能有一个意思
一致的。数据的值和描述在全局中也即数据仓库中都表示一个意思
完整的。这有两个方面。首先确保每一条数据都必须是有意义的(不能为NULL值)，其次要求我们在处理过程中不能有任何信息的“损失”
通常情况下，当BI/DW项目结束时，用户总是会将BI报表和OLTP报表或者明细报表进行比较，以检验数据仓库报表的准确性。一旦用户发现它们之间是不一致的或者误差超过一定比率，他们往往就会认为BI项目很失败。
没有绝对的准确，但是一定要知道为什么不准确，这是数据仓库项目的一个基本要求。
数据仓库的数据来自于多个数据源，所以数据的一致性很难得到保证，既然没有绝对的准确，那么就需要制定一个标准。因此我们建议和客户达成一种相对标准，定义一个可以接受的误差范围。在这个前提下，我们找到误差的原因，并给出分析报告，来提高客户的满意度和对数据仓库项目的信心，从而确保数据仓库项目成功的机率。
二、原因分析和解决思路
数据质量存在问题的根本原因在于数据源，保证数据质量是很困难的事情。这是事实，但是那一些潜在的问题会带来数据质量问题呢?可以归为以下几类：
1. 数据格式问题,l例如数据缺失，超出数据范围，无效数据格式等等。
2. 数据一致性问题，处于数据库性能考虑，有时候可能会有意的去掉一些外间或者检查约束。
3. 业务逻辑问题，这个很难说正确还是错误，通常是由于数据库设计得不够严格或者谨慎。
构造数据仓库系统时，完全理解业务系统的业务逻辑和整体情况是不可能的。我们不能完全去研究那些详细的设计文档，同时后来的很多需求变更也并不完全放映到文档上来，因此需要花费大量的时间去定位和分析其中的原因和变化。用户要求在进行ETL之前必须了解所有的业务逻辑和规则，显然也是不现实的。个人认为我们只需要了解和处理那些可能遭遇问题的数据。我们必须决定这些数据是拒绝呢还是处理。假如数据质量得不到保证的话，在后续的处理过程中，这样的错误将逐渐被放大。
正是因为数据质量问题贯穿于项目的整个生命周期，而且不能避免，我们必须面对而且给出解决办法，尽量把影响减小到最少。
通常情况下，当我们遇到错误数据，ETL一般提供以下4种解决办法：
1. 没有任何处理的通过记录
2. 通过记录，打上错误标记
3. 拒绝记录
4. 停止ETL任务共4页。 1 2 3 4 :
下面就这几种情况进行一下分析：
首先选项1明显不能保证数据质量，并将最终影响报表质量。
其次选项3也不能保证数据完整性，因为数据将发生遗弃，也将会影响报表质量。
再次选项4会影响ETL处理，导致数据仓库不能正常运行下去。
所以，最常见的处理方式就是选项2，首先保证这些记录顺利通过，然后记录一些错误标志，并通过报表反映出来。
这样做有以下四种好处：
1. 通过特殊处理确保了数据的完整性
2. 反映了数据仓库的数据源数据质量
3. 对数据质量可以有一个比较准确的度量
4. 确保了数据仓库的顺利实施和任务的正常调度
数据质量应该尽量确保在ETL环节中进行，因为每一点的错误都会导致后续处理的无限放大，同时数据仓库的处理是线性进行的，当发现错误时，很难回过头来对数据进行重新的处理。因此尽量把错误和数据质量问题消除在靠前的位置。
三、处理对策
数据清洗通常根据不同的情况进行处理，在这里没有办法一一列举，只能对常用的几种情况进行分析处理。
1. 维度：NULL值
假如维度数据为空，在数据处理时可能会导致错误的处理，通过SQL处理时事实表中可能会丢失这部分数据。
2. 维度：外键丢失
前者提到处于数据库性能考虑，业务系统有时候会放弃外间约束或者检查约束，但这样数据的完整性有时无法得到保证，当数据被修改或者删除的时候，这部分数据可能会变成孤儿数据。
3. 度量值：超出范围
假如没有约束和检查规则，原始数据表中的度量值可能为空或者超出预想的范围，当我们处理和计算这部分数据的时候，也会导致错误的结果。
4. 业务逻辑和录入错误
很显然，这部分错误，我们基本上是无能为力的，缺乏有效的验证和纠错，实际上数据仓库的流水线作业形式和巨大的数据量，让我们对这些数据的校验变得不太可能了。我们只
北京航空航天大学 机械工程及自动化学院 仓库管理系统数据库设计《数据库原理及应用》大作业 班级： 学号： 姓名： 2013-12-27
目录 摘要 (4) 关键字 (4) 引言 (5) 1．需求分析 (6) 2.2 引言 (6) 2.2需求分析阶段的目标与任务 (7) 2.2.1 处理对象 (7) 2.2.2 处理功能及要求 (7) 2.2.3.安全性和完整性要求 (8) 2.3需求分析阶段性成果 (8) 2.3.1 体会与收获 (8) 2.3.2仓库管理系统业务流程图 (9) 2.3.3 仓库管理系统数据流程图 (9) 2.3.4仓库管理系统数据字典 (13) 2.3.5 处理逻辑描述 (15) 3.概念设计阶段 (16) 3.1 引言 (16) 3.2任务与目标 (16) 3.3 阶段结果 (17) 4.逻辑设计阶段 (20) 4.1 逻辑设计的任务与目标 (20) 4.2 数据组织 (20)
4.2.1 将E-R图转换为关系模型 (20) 4.2.2 数据库模式定义 (22) 4.2.3 用户子模式的定义 (25) 4.3 数据处理 (26) 5.物理设计阶段 (27) 5.1 物理设计阶段的目标与任务 (27) 5.2数据存储方面 (27) 5.3 系统功能模块 (27) 5.3.1 货物基本信息的查询与更新模块 (27) 6.数据库实施阶段 (29) 6.1建立数据库、数据表、视图、索引 (29) 6.1.1 建立数据库 (29) 6.1.2 建立数据表 (29) 6.1.3 建立视图 (32) 6.1.4 建立索引 (32) 7.心得体会 (33)
数据库与数据仓库的区别是什么 简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。 “与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。 “不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库
归一大数据平台 数据仓库 系统设计说明书受控不受控
修改变更记录：
目录 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.1.1课题开发背景 商品库存管理系统是一个企业不可缺少的部分,它的内容对于企业的决策者和管理者来说都至关重要,所以商品库存管理系统应该能够为用户提供充足的信息和快捷的查询手段。但一直以来人们使用传统人工的方式管理仓库中的各种物资设备，这种管理方式存在着许多缺点,如:效率低、另外时间一长,将产生大量的文件和数据,这对于查找、更新和维护都带来了不少的困难。 随着科学技术的不断提高,计算机科学日渐成熟,其强大的功能已为人们深刻认识,它已进入人类社会的各个领域并发挥着越来越重要的作用。 作为计算机应用的一部分,使用计算机对物资信息进行管理,具有着手工管理所无法比拟的优点.例如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高人事劳资管理的效率,也是企业的科学化、正规化管理,与世界接轨的重要条件。因此，开发这样一套商品库存管理软件成为很有必要的事情。 1.1.2课题开发意义 大多数库存管理理论认为，库存是物理上和逻辑上库房库位的所有有形和无形物料极其价值的总和，具体包括成品、原材料、在制品、在途品、生产前物料、备品备件等。虽然持有一些库存是必要的，过量的库存却非但没有用处而且占用了资金。占用的资金对于公司发展、新产品开发等都是非常需要的；减少资金占用还可以大大减少来自银行贷款的利息和风险。对那些采购量特别大、采购件市场价格有波动的物料库存，加强库存管理效果更为明显。因此，平衡公司库存投资与其它资金需求至关重要。 随着我国经济的飞速发展，各种类型规模的公司企业迅速崛起，许多从事生产和经营管理的企业都有自己生产和销售的产品，而这些产品都需要储存在仓库中，对于每个企业来说，随着企业规模的不断扩大，产品数量的急剧增加，所生产产品的种类也会不断地更新与发展，有关产品的各种信息量也会成倍增长。面对庞大的产品信息量，如何有效地管理库存产品，对这些企业来说是非常重要的，库存管理的重点是销售信息能否及时反馈，从而确保企业运行效益。而库存管理又涉及入库、出库的产品、操作人员及客户等方方面面的因素，如何管理这些信息数据，是一项复杂的系统工程，充分
简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、
商业银行数据仓库 系统功能规格 版本：1.0 (初稿)
目录 1.概述 (4) 1.1.系统介绍 (4) 1.2.系统架构 (4) 1.3.体系结构 (5) 1.4.数据仓库治理系统(DWMS) (5) 1.4.1.................................. 数据采集模块 6 1.4. 2.................................. 数据转换模块 6 1.4.3.................................. 增量计算模块 6 1.4.4...................................... 调度模块 6 1.4.5...................................... 配置模块 6 1.5.O LAP逻辑模型 (7) 1.5.1...................................... 分析角度
7 1.5.1.1. ................................... 公共维 7 1.5. 2...................................... 分析主题 8 1.6.银行业数据仓库E-R模型 (Data Model) (10) 1.6.1.贷款客户分析(Data Model) (10) 1.6. 2...................... 存款客户分析(Data Model) 11 1.6.3...................... 内部账号分析(Data Model) 12 1.6.4...................业务及流淌性分析(Data Model) 13 1.6.5...................资产负债财务分析(Data Model) 14 1.6.6...................... 风险操纵分析(Data Model) 15 1.6.7...................... 现金配钞分析(Data Model) 16
体系结构 数据源 是数据仓库系统的基础，是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于RDBMS中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等等； 数据的存储与管理 是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心，则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）。 OLAP(联机分析处理)服务器 对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：ROLAP（关系型在线分析处理）、MOLAP （多维在线分析处理）和HOLAP（混合型线上分析处理）。ROLAP基本数据和聚合数据均存放在RDBMS之中；MOLAP基本数据和聚合数据均存放于多维数据库中；HOLAP基本数据存放于RDBMS之中，聚合数据存放于多维数据库中。 数据仓库系统的体系结构 数据仓库系统通常是对多个异构数据源的有效集成，集成后按照主题进行重组，包含历史数据。存放在数据仓库中的数据通常不再修改，用于做进一步的分析型数据处理。 数据仓库系统的建立和开发是以企事业单位的现有业务系统和大量业务数据的积累为基础的。数据仓库不是一个静态的概念，只有把信息适时的交给需要这些信息的使用者，供他们做出改善业务经营的决策，信息才能发挥作用，信息才有
**商业银行数据仓库 报表设计 版本：1.0 4/18/2020
目录 1.报表系统 (3) 1.1. 业务分析 (3) 1.2. 财务分析报表系统 (3) 1.2.1.资产业务分析（月） (3) 1.2.1.1. 资产规模增长情况分析 (4) 1.2.1.2. 资产增量变化情况分析 (4) 1.2.1.3. 资产结构变化情况分析 (4) 1.2.1.4. 贷款资产专项统计 (5) 1.2.2.负债业务分析 (5) 1.2.2.1. 负债规模增长情况分析表 (5) 1.2.2.2. 负债增量变动情况分析表 (5) 1.2.2.3. 负债结构变化情况分析表 (6) 1.2.2.4. 存款负债专项统计 (6) 1.2.3.所有者权益分析 (6) 1.2.3.1. 所有者权益增长情况分析 (6) 1.2.3.2. 所有者权益增量变动情况分析 (7) 1.2.3.3. 所有者权益结构变化情况分析 (7) 1.2.4.财务收支分析 (7) 1.2.4.1. 收支规模增长情况分析 (7) 1.2.4.2. 收支增量变动情况分析 (8) 1.2.4.3. 当期收支情况分析 (8) 1.2.4.4. 财务收支结构变动情况分析 (8) 1.2.4.5. 财务收支计划完成情况分析 (8) 1.2.5.财务比率分析 (9) 1.2.5.1. 各项财务比率分析表 (9) 1.3. 资金计划业务需求 (10) 1.3.1.资金头寸统计 (10) 1.3.2.资金负债管理指标 (10) 1.3.3.现金管理 (10) 1.3.3.1. 结算备付金统计 (10) 1.3.3.2. 库存现金统计 (11) 1.3.3.2.1. 即时余额统计 (11) 1.3.3.2.2. 日均余额统计 (11) 1.3.3.3. 业务量统计 (11) 1.3.4.票据贴现业务统计 (12) 1.4. 综合统计分析 (12) 1.4.1.存款统计 (12) 1.4.1.1. 存款结构统计 (12) 1.4.1.1.1. 日均存款统计 (12) 1.4.1.1.2. 存款即时余额统计 (12)
河南城建学院 《典型数据库》课程设计报告 课程名称：《典型数据库》课程设计 设计题目：仓库管理系统 指导教师： 班级： 学号： 学生姓名： 同组人员： 计算机科学与工程学院 2016年1月10日
目录
第1章概述 选题的背景与意义 1、背景： 随着信息技术的发展和国内外互联网技术应用水平的逐步提高，在企业管理过程中，传统的工作方式和管理模式已经难以满足现代社会的必然需求，实现企业现代化综合管理已经是提高国家政府机关和企事业单位各部门工作效率、规范化管理的必然发展趋势。随着经济全球化、信息网络化和物流现代化进程的全面推进，仓储供需量呈现爆炸式的增长，传统的仓库管理模式和管理系统，已根本满足不了现代社会全面信息化的严峻挑战，如何加强以信息化为指导的现代仓库管理技术已成为物流现代化走向成功的有效途径，如何将互联网技术和仓储物流的信息化技术紧密结合起来，开发出适应当前社会发展需要的、先进的现代化物流仓储管理技术平台，是现代化物流发展技术中一项基础的、又是很关键的、特别值得研究的子课题。ASP技术是面向对象编程的技术，可实现复杂数据库的操作；用ASP开发的Web应用程序安装在网络服务器上，运行在网络服务器上，因而ASP源程序的隐密安全系数性高；而ASP又是基于B/S模型架构的、开放式的Web服务器的应用程序开发技术，因此，采用ASP技术开发运行在服务器端的仓库管理信息系统平台是众多软件设计与开发人士的首要选择。本文比较全面地阐述了与ASP、ADO、B/S模式有关的理论技术，为构建Web仓库管理信息系统提供了必要的理论支持。首先分析了ASP技术的优势、特点及其工作原理，剖析了ASP工作的核心内涵，搭建了ASP技术的工作环境，为开发系统功能提供的必需的技术运行环境；分析了目前Web数据库最佳访问组件ADO技术的对象与数据集之间的关系，直接搭建了Web应用程序与数据库访问的联系梁；根据现代仓储市场的需求特点，对拟开发系统的功能进行了细致地分析与设计，建立了仓储数据管理的E-R模型图、数据库结构，分析了B/S架构模式的三层框架，构建了以该框架为模型的仓库管理信息系统，重点分析介绍了有关功能模块的ASP实现过程，成功地实现了基于ASP运行环境的仓库管理信息系统的开发与设计；并对本系统的各项功能进行了测试与分析，发现系统运行状态良好，人机交互友好，程序设计实现合理，达到了项目设计的目的和要求。最后，对本次的项目设计进行了总结与展望，发现了系统的构架模式关系着程序开发效率，对开发系统有着重要的影响意义，好马配好鞍，优秀的软件必然有优秀的构架。作为软件开发设计人员既要努力学好软件技术又要重视相关模式的学习，这样，就能达到事半功倍的效果，设计开发出
河北省工商银行 数据仓库系统建设方案 建 议 书
北京世纪明日网络科技有限公司 二零零零年三月 河北省工商银行数据仓库系统建设方案 目录 第一章前言 1.1数据仓库发展史 1.2竞争日趋激烈的金融市场 1.3中国专业银行面临的挑战 1.4中国专业银行实施数据仓库的意义 1.5中国专业银行实施数据仓库已具备的条件 第二章数据仓库总体概述 2.1 数据仓库基础 2.2 数据仓库技术概述 2.3 一个可扩展数据仓库的基本框架
2.4 一个数据仓库实施流程 第三章系统体系结构设计 3.1系统设计指导思想 3.2 方案总体框架图 3.3 系统体系结构设计 3.4 系统方案的组成 第四章银行数据仓库的建设 4.1 面向应用的OLTP系统和面向主题的OLAP系统 4.2 个性化服务的定义 4.3 业务探索/业务发掘 4.4 建立市场客户信息基础 4.5 利用数据仓库实现的基本模块 4.6 更高层次的开发应用 4.7 综合信息发布 第五章方案实施建议 5.1 开发模式 5.2 组织机构 5.3 项目实施进程
5.4 项目进度计划 第六章产品报价 6.1 软件产品报价 6.2 硬件产品报价 6.3 项目开发实施费用 第一章前言 1.1 数据仓库发展史 相对于许多行业而言，信息处理技术还是一门新兴的技术，但是其发展速度却几乎是最快的。随着计算机硬件技术的飞速发展，软件技术也是日新月异。 许多企业和机构已经建立了相对完善的OLTP（联机事物处理）系统。随着时间的推移，这些系统中积累了大量的历史数据，其中蕴含了许多重要的信息。通过对这些历史数据的分析和综合处理，可以找到那些对企业发展至关重要的业务信息，从而帮助有关主管和业务部门作出更加合理的决策。70年代中期出现的MIS（管理信息系统）实际上就是在这种背景下产生的。 但MIS具有极大的局限性。首先，它是按预先定义好的流程对数
如何构建银行数据仓库 数据仓库技术作为一项数据管理领域的新技术，其精髓在于针对联机分析处理(OLAP)提出了一种综合的解决方案，与以往很多技术不同的是，它主要是一种概念，在此概念指导下完成系统的构造。既没有可以直接购买到的现成产品，也没有具体的分析规X和实现方法，也就是说没有成熟、可靠且被广泛接受的数据仓库标准。在以往关系数据库的设计和实现中，不仅有详细的理论推导，还有无数的设计实例，无论你使用的是什么公司的数据库产品、开发工具，只要按照规X做，那么实现同一业务需求的方案都会很相似。而现有数据仓库的实现中，出现了MOLAP 方案和ROLAP方案的区别，出现了形形色色的数据仓库建模工具、表现工具，而设计人员的个人经验和素质也会在其中扮演很重要的角色。 数据仓库技术的实现方式 目前在数据仓库技术的实际应用中主要包括如下几种具体实现方式。 1、在关系数据库上建立数据仓库(ROLAP) 2、在多维数据库上建立数据仓库(MOLAP) MOLAP方案是以多维方式来组织数据，以多维方式来存储数据；ROLAP
方案则以二维关系表为核心表达多维概念，通过将多维结构划分为两类表:维表和事实表，使关系型结构能较好地适应多维数据的表示和存储。在多维数据模型的表达方面，多维矩阵比关系表更清晰且占用的存储更少，而通过关系表间的连接来查询数据的ROLAP系统，系统性能成为最大问题。MOLAP方案比ROLAP方案要简明，索引及数据聚合可以自动进行并自动管理，但同时丧失了一定的灵活性。ROLAP方案的实现较为复杂，但灵活性较好，用户可以动态定义统计和计算方式，另外能保护在已有关系数据库上的投资。 由于两种方案各有优劣，因此在实际应用中，往往将MOLAP和ROLAP 结合使用，即所谓的混合模型。利用关系数据库存储历史数据、细节数据或非数值型数据，发挥关系数据库技术成熟的优势，减少花费，而在多维数据库中存储当前数据和常用统计数据，以提高操作性能。 3、在原有关系库上建立逻辑上的数据仓库 由于目前正在运行的OLTP系统中已经积累了海量数据，如何从中提取出决策所需的有用信息就成为用户最迫切的需要。新建数据仓库固然能从功能、性能各方面给出一个完整的解决方案，但需要投入大量的人力、物力，并且数据仓库的建设和分析数据的积累需要一段时间，无法及时满足用户对信息分析的迫切需要。因此在筹建数据仓库的前期，可以采用一些合适的表现工具，在原有OLTP系统上建立起一个逻辑的数据仓库系统。尽管由于原有OLTP系统设计上的局限性，这样的系统可
电子与信息工程学院 课程设计报告 （2018-2019学年第二学期） 课程：面向对象程序设计 软件工程实践（数据库设计与开发）题目：企业仓库管理系统 专业班级： 组别： 小组成员： 指导教师： 完成周数： 2019年7月10日
第一章引言 1.1系统开发的背景 随着计算机的发展，生活中仅仅依靠人工管理商场里面大量的的商品会浪费大部分的人力物力，还会造成较高的人工失误，所以有必要开发一个商场库存管理系统来很大程度上减少失误和不必要的浪费。实现信息数字化管理，提高管理效率，降低经营成本。利用商场库存管理系统可以提高商场的运营，提高总体效率 1.2系统开发的意义与目的 仓库在现实生活中用途十分广泛，各种商城、超市要利用仓库存放物资，药房、医院等要利用仓库存放药品，企业、工厂等要利用仓库存放原材料、生产成品，因此仓库的管理成了一项十分重要的工作。人工管理仓库既费时又费力，而且容易造成混乱，严重时会影响商城、企业的正常运作，造成恶劣的后果。随着计算机技术的发展，如何快速，高效，便捷的管理仓库受到了高度的关注。本系统模拟仓库管理，系统主要针对于日常库存信息的管理，包括物资管理、仓库管理、入库操作、入库査询统计、出库操作、出库查询统计、库存查询统计等处理情況。用户可以通过相应的模块，对仓库里的物品的基本情况和库存数量进行查询，管理员通过简单的操作即可轻松的管理仓库，查询各项相关信息，并能进行入库和出库操作等。通过仓库管理系统的设计与实现，使我们巩固和加深对数据库基础理论和基本知识的理解，进一步掌握了使用数据库进行软件设计的基本思想和方法，提高了运用数据库理论解决实际问题的能力，锻炼了实际动手能力、创新能力，培养了调查研究、查阅技术文献、资料、手册以及编写文档的能力。 1.3开发工具简介 1.3.1数据库系统SQL Servers012： 作为新一代的数据平台产品，SQL Server 2012 不仅延续现有数据平台的强大能力，全面支持云技术与平台，并且能够快速构建相应的解决方案实现私有云
数据仓库二期之数据仓库系统项目 供应商征集要求 一、项目名称 数据仓库二期之数据仓库系统项目 二、项目背景 数据管控与数据仓库项目（以下简称“数据仓库项目”）一期工程于2013年12月正式进场实施，项目范围包括数据仓库平台、数据管控体系、数据应用系统三个子包内容，各子包系统已全部于2014年底前上线试运行，项目一期已于2015年4月底完成初验。 我行数据仓库项目一期工程包括数据仓库平台系统、数据管控体系、数据应用系统三个项目子包的内容，分别由高伟达、美商天睿（以下简称TD公司）以及宇信三家公司负责实施，具体实施情况如下： 1、项目子包一主要涉及数据仓库平台建设，项目组完成数据仓库平台中长期建设规划，引入先进的数据模型，建立数据仓库十大主题数据框架，基本实现上游21个主要业务系统关键业务数据入仓存储，并为下游管理驾驶舱、统一报表平台系统正式供数。 2、项目子包二主要涉及数据管控体系建设，项目组从规划咨询、制度规范、内容建设、系统平台四个方面推进并完成数据管控体系建设各项基础工作，已初步建立我行数据管控体系基础框架，为后续全行数据有效治理打下坚实基础。 3、项目子包三主要涉及管理驾驶舱、统一报表平台两个数据应用系统。管理驾驶舱系统创新了信息服务渠道，为我行中高层管理人员提供决策辅助信息；统一报表平台系统通过传统报表与灵活查询相结合的方式，为我行业务管理和统计分析人员提供超过200张报表及14项专题的的报表数据查询服务。 三、项目要求 我行数据仓库项目一期通过搭建基础平台、构建系统框架，已初步建立基础
框架。为确保数据仓库项目开发的延续性，充分发挥数据价值，切实提高数据质量，我行启动数据仓库项目二期工程建设，本次招标的数据仓库系统子包是二期工程的重要内容，通过本子包内容的实施，一方面拓展数据的使用范围，展现数据的应用价值；另一方面加大数据的整合，提升数据的质量，有效解决数据问题，为后续数据分析挖掘打好基础。同时，通过数据仓库建设，积累经验，为我行打造一支专业的数据管理、挖掘、分析团队。 数据仓库项目二期工程（数据仓库系统子包）主要包括对外供数、数据入仓以及数据挖掘三大部分内容。 （1）对外供数是项目二期的工作重点，主要包括对已纳入今年开发计划的部分新建系统（运营风险预警系统、EAST系统2.0等）提供数据支持，以及对当前存量的下游数据分析系统（反洗钱系统、监管报送系统、管理会计系统等）实施数据接口切换，将此部分系统的数据源由现有的多个系统逐步改为由数仓系统统一供数。 （2）数据入仓是对现有数据仓库数据的持续完善与补充，主要包括根据下游数据应用需求，对上游业务系统未入仓的新产品、新业务数据实施采集并入仓存储，并结合我行历史数据入仓要求，对部分关键业务系统2014及2013年的历史数据按数据仓库抽取、转换、载入要求实施入仓处理。 （3）数据挖掘服务是项目二期引入的新内容，项目组将作为全行数据挖掘与分析应用的连接处，借鉴并引入同业银行的创新数据思维，引导并统筹全行数据挖掘需求，与相关业务部门一起探讨大数据分析应用与业务模型设计，以微创新的方式推动各项业务创新与服务提升，深层次的挖掘数据价值。
银行信用卡数据仓库建设 一、需求分析 银行建立数据仓库的必要性。中国的银行业在发展过程中，已逐步实现了绝大多数核心业务的计算机处理，积累了大量的客户数据和经营数据，这些数据是银行的宝贵财富，如何利用这些数据，发掘有价值的信息，解决问题的关键是建立银行企业级的数据仓库，实现对银行所有经营信息和客户信息的有效存储，并针对银行不同部门的管理决策需要，进行多层次的数据加工处理，以多种方式呈现真正有价值的信息（例如，维度，商业需求用户数量等），满足银行管理决策和客户分析的需要。 由此可以看出，整合数据建立一个全银行统一的数据中心，对于银行来说是非常重要的。通过数据仓库技术，将x银行全国各地的数据整合，并对数据进行一系列的抽取、加工、清洗、加载，使得数据能够有很高的利用价值。通过智能化的报表加工工具Cognos来快速的生成多种多样的报表，从不同的维度来展现数据。这些报表对于管理层来说数据更准确、更有价值，而且还可以根据上级的不同需求来随时生成想要看到的报表。这些对于银行发展新的客户、改善与老客户的关系、提高市场竞争力和占有率是非常重要和迫切的。 二．维度分析 1）卡量分析 2）客户量分析
3）账户分析 通过对卡量、客户量和账户量分析指标的业务定义的分析，卡信息汇总表选取的入仓字段有卡号、开卡日期、激活日期、销卡日期、销卡日期、到期日、发卡机构。 通过对卡量、客户量和账户量分析指标的业务定义的分析，选取的入仓字段有机构代码、性别代码、客户号。 通过对卡量、客户量和账户量分析指标的业务定义的分析，选取的账号信息汇总表的入仓字段有账号、销户日期、账户状态、开户日期、销户日期、账户余额、逾期状态。 三、所用到的技术简单概述 1）ETL概述 E是Extraction的简写，表示数据的抽取；T是Transformation的简写，表示数据的转换；L是Loading的简写，表示数据的加载。ETL是数据抽取(Extraction)、转换(Transformation)、加载(Loading)的过程。 抽取(Extraction)，在数据仓库系统的建设中是对数据的操作，就是将数据从 各种原始的业务系统中读取出来，这是要建立数据仓库系统的所有工作的前提。
1 BI Business Intelligence，即商业智能，商务智能综合企业所有沉淀下来的信息，用科学的分析方法，为企业领导提供科学决策信息的过程。 BOSS业务运营支撑系 BPM企业绩效管理 BPR业务流程重整 CRM客户关系管理 CUBE立方体 DM（Datamart）数据集市数据仓库的子集，它含有较少的主题域且历史时间更短数据量更少，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库。 DM（DataMine）数据挖掘 DSS决策支持系统 EDM企业数据模型 3 ERP Enterprise Resourse Planning企业资源规划。它是一个以管理会计为核心的信息系统，识别和规划企业资源，从而获取客户订单，完成加工和交付，最后得到客户付款。换言之，ERP将企业内部所有资源整合在一起，对八个采购、生产、成本、库存、分销、运输、财务、人力资源进行规划，从而达到最佳资源组合，取得最佳效益。 4 ETL 数据抽取（Extract）、转换（Transform）、清洗（Cleansing）、装载（Load）的过程。构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终 按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。 KDD数据库中知识发现 5 KPI 企业关键业绩指标(KPI：KeyProcessIndication)是通过对组织内部流程的输入端、输出端的关键参数进行设臵、取样、计算、分析，衡量流程绩效的一种目标式量化管理指标，是把企业的战略目标分解为可操作的工作目标的工具，是企业绩效管理的基础。 LDM逻辑数据模型 6 MDD 多维数据库（Multi Dimesional Database,MDD）可以简单地理解为：将数据存放在一个n维数组中，而不是像关系数据库那样以记录的形式存放。因此它存在大量稀疏矩阵，人们可以通过多维视图来观察数据。多维数据库增加了一个时间维，与关系数据库相比，它的优势在于可以提高数据处理速度，加快反应时间，提高查询效率。 Metadata(元数据)，它是“关于数据的数据，其内容主要包括数据仓库的数据字典、数据的定义、数据的抽取规则、数据的转换规则、数据加载频率等信息。 MOLAP自行建立了多维数据库，来存放联机分析系统数据 7 ODS（四个特点） (Oprational Data Store)操作型数据存储，是建立在数据准备区和数据仓库之间的一个部件。用来满足企业集成的、综合的操作型处理需要，操作数据存储是个可选的部件。对于一些准实时的业务数据库当中的数据的暂时存储，支持一些同时关连到历史数据与实时数据分
数据仓库系统招标文件 二OO九年七月
目录 第一部分投标人须知..................................................... ... 招标人信息系统概况 .................................................. 总体说明............................................................ 适用范围 ........................................................ 招标人资料 ...................................................... 招标文件的解释权................................................ 投标文件的编写...................................................... 投标人基本条件 .................................................. 投标文件的组成 .................................................. 投标保证金 ...................................................... 投标报价 ........................................................ 投标文件的规定 .................................................. 递交投标文件的截止日期.......................................... 投标文件的修改和撤回............................................ 评标及中标通知...................................................... 保密事项............................................................ 第二部分招标项目要求………………………………………………………………………… 招标内容............................................................ 系统建设的总体原则 .................................................. 项目要求............................................................ 系统建设总体目标................................................ 数据仓库平台技术要求 (11) 系统一期建设需求 (12) 系统一期建设时间要求 (14) 系统建设方案要求……………………………………………………………… 系统技术方案要求..................................................... 数据仓库产品选型方案要求 (16) 系统硬件、软件及网络架构方案要求 (17) 系统实施方案要求 (17) 售后服务方案要求 (18) 系统安装、调试和验收 ................................................
银行数据仓库构建的方法论 中国农业发展银行李小庆 （专注、专业、专长。作者为金融信息化专家，管理学博士） 银行数据仓库是用于决策支持的、面向主题的、集成的、稳定的和随时间变化的数据集合，它的目标是辅助决策，因此其历史的、概括的数据比详细的、个别的记录更重要。由于数据仓库中的数据是集成化的数据，它可能来自多个（异种）操作数据库，可能跨越较长的时间周期，它比操作数据库大几个数量级。一般而言，企业级的数据仓库其数据量可达几TB至几十TB之间，工作负荷主要是查询和分析。通常，复杂的查询可以访问几百万条记录，执行许多的扫描、连接和聚合操作，在这里查询吞吐量和响应时间比事务吞吐量更重要。 目前，各家银行已就相关业务建立了数据仓库，并初步取得了应用效果。但是，当前数据仓库都是根据具体业务分类进行建设，只能实现业务范围内的单目标决策，为了实现综合目标决策支持，就需要将不同类型数据仓库中的数据再次集成起来，并对其进行存储、管理和维护。因此，本文提出银行数据仓库的概念，通过建立全行综合性的数据仓库，采用分析软件或挖掘工具进行分析和挖掘，实施多目标决策。也就是说综合银行现有的货币经营数据仓库、信贷业务数据仓库、银行卡数据仓库、人事数据仓库等数据仓库的进行再次整合，建立一个面向主题的、集成的、综合的和持久的数据集合，在此基础上进行多维分析和数据挖掘，为银行的业务进行综合分析和战略决策提供有力的数据平台。 一、数据仓库模型和创建过程描述 尽管数据仓库是面向主题的，并为分析需求保存了许多综合数据，但对各类银行业务分类建立数据仓库，因此建立面向所有主要业务和内部管理流程、具有综合性特征的数据仓库，成为当前银行创新业务品种、提高服务质量的实际需求。数据仓库分析和决策目标众多，相关需求千变万化，数据仓库的主题面临不断增加、完善和调整，同时随着数据的不断加载，数据仓库会越来越庞大。如果仅仅基于单一层次建立数据仓库，将使系统的性能低下，因此，在实际应用中应建立分层的数据仓库体系化结构。根据管理层次的需求，数据仓库体系化结构环境可分为三个层级：基础层级、部门层级和高级管理层级的数据仓库。 基础层级数据仓库中存放的是一些细节性的操作型数据，服务于高性能的偏向事务类的分析和全行统计类的分析。部门层级数据仓库中一般仅包括某类业务的全部导出数据，用于部门决策类分析。而高级管理层级的数据仓库的数据都是综合粒度的，用于银行高管人员启发式分析。数据仓库的体系化结构环境能较好地与银行的“高-中-低”形式的组织结构相对应。如普通OLAP分析人员主要应用基础层级数据仓库，进行日常业务分析处理和统计；中层管理主要应用部门层级数据仓库，它既包括一般业务处理，又可进行定量分析，做出一般决策和控制；高层管理应用高级管理层级数据仓库，主要任务是进行战略决策，需要进行复杂的分析加工。 由于当前各个厂商提供的数据仓库解决方案从系统架构到具体硬件软件功能划分都或多或少的存在差异，所以相对应的在数据仓库项目的分析、开发和实施过程中遵从的方法论也不尽相同。建立银行数据仓库是一项系统工程，需要组织各方面的资源，协调各方面的关系。可扩展数据仓库建设方法论的三个阶段主要包括：统一规划，设计和实施，评估和提高三个阶段，如下图所示。
基于数据仓库的图书管理系统1.ER图 图1-1 2.数据库表 1)读者信息表 表2-1reader表 字段名称rId major academy telephone borrowNum 数据类型 char(32) varchar(50) varchar(50) varchar(50) int 主键 Y N N N N 是否空 N N N N N 说明 主键 专业 学院 电话 借阅量
表2-2book 表 字段名称bId bName author price invNum category borrowDate position rId 数据类型 char(32) varchar(200) varchar(50) decimal(8,2) int varchar(50) varchar(50) varchar(50) char(32) 主键 Y N N N N N N N N 是否空 N N N N N N N N N 说明 主键 书图名称 作者 单价 库存量 图书分类 借阅日期 存放位置读 者ID(外键) 3)订单条目表 表2-4 orderItem表 字段名称orderItemId quantity bId price oId 数据类型 char(32) int char(32) float Char(32) 主键 Y N N N N 是否空 N N N N N 说明 主键 数量 图书ID 单价订单 ID(外键) 4)订单表 表2-5order表 字段名称oId orderTime adminId 数据类型 char(32) char(19) char(32) 主键 Y N N 是否空 N N N 说明 主键 下单时间 管理员ID
数据仓库与数据库的区别 简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM 了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，