数据仓库的定义&＃xff1a;
数据仓库是一个数据库&＃xff0c;其中包含了来自多个经过合并计算、集成、结构化的运行系统的数据&＃xff0c;因此它可用于支持一个企业的分析和决策支持。
Oracle具有数据访问结构的专门类型&＃xff0c;如位图索引、位图连接索引和物化视图来改善查询性能。OLAP软件用来以自顶向下的层次结构的方式来分析业务数据。它假定以迭代的方式出现&＃xff0c;在这种方式下&＃xff0c;问一个问题会导致问更多的其他问题。
数据仓库是为了在访问路径事先不知道的情况下更快地检索数据而设计的。信息经常是通过数据的大量积累汇总成概要信息&＃xff0c;钻取以便获得更详细的信息、或者查找模式和趋势来从其他数据中派生出来的。
在OLTP系统中&＃xff0c;实体关系图技术用来设计数据库的方案。每个实体设计成一个表&＃xff0c;属性变成列&＃xff0c;关系通过在运行时连接主键和外键列来表示。
规范化的设计为OLTP系统提供了优化的性能&＃xff1b;它支持经常更新数据的大量的事务处理。规范化通过将相关的数据放在一起存储在一个表中来消除冗余&＃xff0c;以此来确保表具有正确的结构。通过只有一份数据避免了更新异常&＃xff0c;数据的一致性得到维护。规范化数据后&＃xff0c;在没有为了改善性能而更新的数据列上可能会再次引入冗余。
在数据仓库中主要的活动是查询数据&＃xff0c;为了优化数据仓库的性能需要一个新的数据模型。维度建模的业界主要代言人和《The Data Warehouse Toolkit》一书的作者引入了星型设计方案&＃xff0c;这是为了适应OLAP处理而引入的一种新的设计数据库的方式。为了优化数据仓库的性能而使用维度建模的技巧。
建模的维度方法将数据组织称事实和维度表。它以一种用户容易理解的方式来表示数据。用户经常按季来询问销售结果报表&＃xff0c;并按照商场和地理区域来划分。销售数量是事实。商场、区域和季节是数据分析的纬度&＃xff0c;并用来组织数据。采用纬度建模的方法引入非规范化和冗余。
逻辑设计转换成物理表示将更好地优化性能和可管理性。因此定义了表、约束、索引和分区。
Oracle增加了许多支持纬度设计的特性。优化器可以识别星型设计方案。除了创建表和列之外还可以定义纬度来帮助以各种不同的方式分析数据。
由于运行的业务系统可能不包含历史数据&＃xff0c;可能没有可以用来分析的数据。而且&＃xff0c;设计方案不是为商务智能查询而设计的&＃xff0c;数据也没有为商务智能查询方便而进行结构化处理。而且数据仓库中的查询通常需要访问大量的数据&＃xff0c;这将会占用大量的内存、CPU和I/O资源。运行决策支持查询需要大量的计算处理能力来对数百万行数据进行排序和汇总&＃xff0c;这将会对运行的业务系统的性能造成影响。
使情况变得更为复杂的的是&＃xff0c;许多不同的业务运行系统运行在不同的硬件平台上&＃xff0c;具有不同的操作系统和不同的数据库管理系统。一些应用可能是购置的而另外一些是自行开发的。一些应用甚至没有可以共修改的源代码&＃xff0c;许多系统可能是几年前的系统。
分布式的数据库曾经被认为允许发出一个查询&＃xff0c;全局查询优化器可以透明地查找数据&＃xff0c;而且已尽可能快的速度返回给用户&＃xff0c;以致于用户从来没有意识到它位于异地的一台机器上。但是这样的系统从来没有真正实现过&＃xff01;
正因为这样一些原因&＃xff0c;数据需要从运行的业务系统移到一个分离的单独的数据仓库&＃xff0c;在数据仓库中数据在不同的机器上以相同的格式存储以便于分析。
构建数据仓库涉及到将数据从业务运行系统抽取出来&＃xff0c;有时还要将它与来自第三方的附加信息组合在一起&＃xff0c;转换成统一的格式&＃xff0c;并装载到数据库。
通常&＃xff0c;构建数据仓库80%的工作是抽取、转换和装载(ETL)过程&＃xff1a;查找数据&＃xff1b;编写程序抽取、过滤和清理数据&＃xff1b;然后将数据转换成统一的编码方案&＃xff1b;并将数据装载到数据仓库中。
业务操作数据必须从业务运行系统抽取出来拷贝到一个临时数据交换区&＃xff0c;这是一个数据被清理、转换、并为数据仓库准备的地方。有时有权限直接访问源业务运行系统&＃xff0c;但是&＃xff0c;经常这种访问权限时被严格限制的&＃xff0c;只能获得抽取出来的数据文件。业务运行系统通常是24*7*365方式运行的&＃xff0c;无论如何也不能影响它的运行性能。
为了能够在数据仓库中使用抽取出来的数据&＃xff0c;来自多个业务系统的数据必须被转换成统一的格式。对业务系统中数据的含义的理解和掌握是必需的。
*每个业务系统可能会用不同的名字或者主键来引用相同的数据项。
*每个系统可能会使用不同的编码方案。在数据仓库中数据必须被转换成统一的编码方案。
*一个表的一个属性可能会有不同的名字。
*不同的系统可能会使用不同的计量单位。
在设计转换过程时这些来自业务系统的不同的列名被映射到数据仓库中选择的公共的名字上并转换成统一的编码方案。一旦数据被转换&＃xff0c;就为装载到数据仓库做好了准备。通常数据转换区域和数据仓库位于不同的机器上&＃xff1b;因此&＃xff0c;需要将数据传输并移动到数据仓库所在的位置。如果转换后的数据是一个普通的文件&＃xff0c;可能需要使用FTP传输并使用SQL*Loader实用程序或者Oracle Data Pump进行装载。如果数据已经转换到一个Oracle数据库中&＃xff0c;可以使用可传输的表空间将一个表空间从一个数据库移到另外一个数据库。新数据通常是周期性地添加到数据仓库中的。它可以是在晚上或者在其他数据仓库没有被分析人员大量使用的时间成批地进行装载。Oracle 10g Asynchronouse Change Data Capture提供了一种接近实时装载数据的机制&＃xff0c;提供对最近的交易变更的访问方式。
除了自己拥有的数据外&＃xff0c;还可以购买来自外部数据供应商提供的数据添加到自己的数据仓库中。例如&＃xff0c;可以购买关于天气、人口统计和社会经济方面信息。使用的案例可能有&＃xff1a;
*添加按照天跟踪区域天气事件的数据
*添加客户人口统计数据
*了解哪一类客户购买哪一类产品
*添加邓.布公司的数据(该公司编制了许多大规模公司的信誉报告&＃xff0c;不论这些公司是公开发股的还是私有的)
构建数据仓库可能非常复杂&＃xff0c;经常需要大约18个月到三年的时间才能发布。因为数据仓库包含了许多主体范围并且跨越多个组织机构&＃xff0c;它还可能有很高的政治性。许多早期的数据仓库项目都失败了。
数据仓库是一个数据库&＃xff0c;其中包含了来自多个经过合并计算、集成、结构化的运行系统的数据&＃xff0c;因此它可用于支持一个企业的分析和决策支持。
Oracle具有数据访问结构的专门类型&＃xff0c;如位图索引、位图连接索引和物化视图来改善查询性能。OLAP软件用来以自顶向下的层次结构的方式来分析业务数据。它假定以迭代的方式出现&＃xff0c;在这种方式下&＃xff0c;问一个问题会导致问更多的其他问题。
数据仓库是为了在访问路径事先不知道的情况下更快地检索数据而设计的。信息经常是通过数据的大量积累汇总成概要信息&＃xff0c;钻取以便获得更详细的信息、或者查找模式和趋势来从其他数据中派生出来的。
在OLTP系统中&＃xff0c;实体关系图技术用来设计数据库的方案。每个实体设计成一个表&＃xff0c;属性变成列&＃xff0c;关系通过在运行时连接主键和外键列来表示。
规范化的设计为OLTP系统提供了优化的性能&＃xff1b;它支持经常更新数据的大量的事务处理。规范化通过将相关的数据放在一起存储在一个表中来消除冗余&＃xff0c;以此来确保表具有正确的结构。通过只有一份数据避免了更新异常&＃xff0c;数据的一致性得到维护。规范化数据后&＃xff0c;在没有为了改善性能而更新的数据列上可能会再次引入冗余。
在数据仓库中主要的活动是查询数据&＃xff0c;为了优化数据仓库的性能需要一个新的数据模型。维度建模的业界主要代言人和《The Data Warehouse Toolkit》一书的作者引入了星型设计方案&＃xff0c;这是为了适应OLAP处理而引入的一种新的设计数据库的方式。为了优化数据仓库的性能而使用维度建模的技巧。
建模的维度方法将数据组织称事实和维度表。它以一种用户容易理解的方式来表示数据。用户经常按季来询问销售结果报表&＃xff0c;并按照商场和地理区域来划分。销售数量是事实。商场、区域和季节是数据分析的纬度&＃xff0c;并用来组织数据。采用纬度建模的方法引入非规范化和冗余。
逻辑设计转换成物理表示将更好地优化性能和可管理性。因此定义了表、约束、索引和分区。
Oracle增加了许多支持纬度设计的特性。优化器可以识别星型设计方案。除了创建表和列之外还可以定义纬度来帮助以各种不同的方式分析数据。
由于运行的业务系统可能不包含历史数据&＃xff0c;可能没有可以用来分析的数据。而且&＃xff0c;设计方案不是为商务智能查询而设计的&＃xff0c;数据也没有为商务智能查询方便而进行结构化处理。而且数据仓库中的查询通常需要访问大量的数据&＃xff0c;这将会占用大量的内存、CPU和I/O资源。运行决策支持查询需要大量的计算处理能力来对数百万行数据进行排序和汇总&＃xff0c;这将会对运行的业务系统的性能造成影响。
使情况变得更为复杂的的是&＃xff0c;许多不同的业务运行系统运行在不同的硬件平台上&＃xff0c;具有不同的操作系统和不同的数据库管理系统。一些应用可能是购置的而另外一些是自行开发的。一些应用甚至没有可以共修改的源代码&＃xff0c;许多系统可能是几年前的系统。
分布式的数据库曾经被认为允许发出一个查询&＃xff0c;全局查询优化器可以透明地查找数据&＃xff0c;而且已尽可能快的速度返回给用户&＃xff0c;以致于用户从来没有意识到它位于异地的一台机器上。但是这样的系统从来没有真正实现过&＃xff01;
正因为这样一些原因&＃xff0c;数据需要从运行的业务系统移到一个分离的单独的数据仓库&＃xff0c;在数据仓库中数据在不同的机器上以相同的格式存储以便于分析。
构建数据仓库涉及到将数据从业务运行系统抽取出来&＃xff0c;有时还要将它与来自第三方的附加信息组合在一起&＃xff0c;转换成统一的格式&＃xff0c;并装载到数据库。
通常&＃xff0c;构建数据仓库80%的工作是抽取、转换和装载(ETL)过程&＃xff1a;查找数据&＃xff1b;编写程序抽取、过滤和清理数据&＃xff1b;然后将数据转换成统一的编码方案&＃xff1b;并将数据装载到数据仓库中。
业务操作数据必须从业务运行系统抽取出来拷贝到一个临时数据交换区&＃xff0c;这是一个数据被清理、转换、并为数据仓库准备的地方。有时有权限直接访问源业务运行系统&＃xff0c;但是&＃xff0c;经常这种访问权限时被严格限制的&＃xff0c;只能获得抽取出来的数据文件。业务运行系统通常是24*7*365方式运行的&＃xff0c;无论如何也不能影响它的运行性能。
为了能够在数据仓库中使用抽取出来的数据&＃xff0c;来自多个业务系统的数据必须被转换成统一的格式。对业务系统中数据的含义的理解和掌握是必需的。
*每个业务系统可能会用不同的名字或者主键来引用相同的数据项。
*每个系统可能会使用不同的编码方案。在数据仓库中数据必须被转换成统一的编码方案。
*一个表的一个属性可能会有不同的名字。
*不同的系统可能会使用不同的计量单位。
在设计转换过程时这些来自业务系统的不同的列名被映射到数据仓库中选择的公共的名字上并转换成统一的编码方案。一旦数据被转换&＃xff0c;就为装载到数据仓库做好了准备。通常数据转换区域和数据仓库位于不同的机器上&＃xff1b;因此&＃xff0c;需要将数据传输并移动到数据仓库所在的位置。如果转换后的数据是一个普通的文件&＃xff0c;可能需要使用FTP传输并使用SQL*Loader实用程序或者Oracle Data Pump进行装载。如果数据已经转换到一个Oracle数据库中&＃xff0c;可以使用可传输的表空间将一个表空间从一个数据库移到另外一个数据库。新数据通常是周期性地添加到数据仓库中的。它可以是在晚上或者在其他数据仓库没有被分析人员大量使用的时间成批地进行装载。Oracle 10g Asynchronouse Change Data Capture提供了一种接近实时装载数据的机制&＃xff0c;提供对最近的交易变更的访问方式。
除了自己拥有的数据外&＃xff0c;还可以购买来自外部数据供应商提供的数据添加到自己的数据仓库中。例如&＃xff0c;可以购买关于天气、人口统计和社会经济方面信息。使用的案例可能有&＃xff1a;
*添加按照天跟踪区域天气事件的数据
*添加客户人口统计数据
*了解哪一类客户购买哪一类产品
*添加邓.布公司的数据(该公司编制了许多大规模公司的信誉报告&＃xff0c;不论这些公司是公开发股的还是私有的)
构建数据仓库可能非常复杂&＃xff0c;经常需要大约18个月到三年的时间才能发布。因为数据仓库包含了许多主体范围并且跨越多个组织机构&＃xff0c;它还可能有很高的政治性。许多早期的数据仓库项目都失败了。
据发现数据仓库的许多优点被缩减到一个部门或者一个营业范围内解决一个具体的业务问题。数据仓库包含多个主题&＃xff0c;每个主题跨越多个营业范围提供一个数据合并的企业视图。数据集市是特定主题或者特定应用的数据仓库&＃xff0c;其中只包含一个营业范围(比如&＃xff0c;销售或者市场)的数据。数据仓库和数据集市之间的主要区别是它们包含的信息的范围不同。因为数据集市的范围更小&＃xff0c;数据来自更少的数据源&＃xff0c;通常实现的时间比较短。
根据信息的数据源的不同&＃xff0c;数据集市可以是独立的也可以是依赖于其他系统的。依赖于其他系统的数据集市的信息源是一个现存的数据仓库&＃xff0c;它的数据直接从业务系统中抽取。由于独立的数据集市可以很快地建立起来&＃xff0c;在90年代中后期数据集市非常流行&＃xff0c;企业的每个部门根据自己的需求构建了部门自己的数据集市。不幸的是&＃xff0c;创建了几个数据集市后新的问题又出现了。每个数据集市是它自己的“信息孤岛”。一个和显然的问题是有两张对同一个问题有不同的答案的报表。
独立的数据集市之所以可以很快地发布的原因之一是它们延迟了许多在后来随着数据集市的数量不断增长时需求变得迫切的关键决策。独立的数据集市的数据只有一个部门需要标识和理解而不需要完全了解整个公司的所有的数据。创建独立的数据集市避免了与创建通用命名和编码标准相关的政治性问题。其他问题来自于单个数据集市通常由另外的不同的自治的团队创建的事实。这些团队通常选择不同的硬件、软件并使用不同的工具。每个独立的数据集市都直接从业务系统获取它的数据。这样随着数据集市的添加&＃xff0c;可能没有足够多的空闲周期来运行多个数据抽取程序。每个数据集市做它自己的数据清理和转换&＃xff0c;还可能采用稍微不同的处理方式。这样很容易造成数据的不一致性。冗余和数据不一致性导致不同的答案&＃xff0c;造成很难根据这些数据进行决策。可以想象一下在将来的某个时间将这些不同的视图合并成一个统一的数据仓库该有多么困难&＃xff01;
根据前面的讨论&＃xff0c;业务系统的数据和数据仓库中的数据之间有很大的区别。业务数据是关于公司当前状态的数据&＃xff0c;用来管理日常的业务操作。数据仓库中的数据是信息化的&＃xff0c;包含了关于过去的历史记录。如果需要提供关于业务当前状态的信息来做战略决策以便支持支持日常的业务&＃xff0c;可以创建一个业务数据源(Operational Data Source&＃xff0c;ODS)作为信息管理架构的一部分。业务数据源包含经过验证和清理的面向主题的集成的数据。它用来支持业务查询和报表。例如&＃xff0c;客户服务企业需要访问帐户余额和账单信息。业务数据源以接近实时的速度更新&＃xff0c;因此它实时反映了当前的状态。业务数据源可以作为数据集市或数据仓库的数据源。
为了解决这些问题并且能够及时收回投资&＃xff0c;人们开始采用分段实施的方式每次只构建一个功能领域的数据仓库&＃xff0c;而不是一下子构建一个代表整个公司的数据仓库。图1.1展示了目前使用的最流行的架构。数据从OLTP系统和外部数据源中抽取&＃xff0c;装载到业务数据仓库和企业数据仓库中&＃xff0c;并装载到独立的数据集市中。
构建数据仓库和开发一个软件一样&＃xff0c;不可能在一个版本中解决所有的问题&＃xff0c;永远也不可能预见所有可能的应用。一整套改革计划的("big bang")方法的另一个问题是在今后的一些年里情况发生了变化&＃xff0c;用户的需求和现在不同了&＃xff0c;数据仓库的实现简直就是错的。最好是开发一个总体的架构&＃xff0c;构建一个具有允许分段创建的组件的框架。分段实施的方法提供了与业务的持续的沟通和反馈。界定实施的范围&＃xff0c;并计划每三到六个月改进一次。
报表、查询和分析工具变成了基于浏览器的工具了
1995年&＃xff0c;Oracle的创始人和CEO Larry Ellision首次引入了他的网络计算机的观点&＃xff1a;一台方便地运行通过Internet访问信息的应用程序的小的廉价的设备。尽管网络计算机从来没有赢得大量的市场份额&＃xff0c;以Internet为中心的商业计算的观点加速了PCs的价格的下降&＃xff0c;满足了更加便宜的简单的桌面计算的需求。在Web上发布报表的能力使得信息可以供几乎每个人使用。给公司员工、合作伙伴和客户提供实时的关键信息。再也不用非得到办公室去才能查看一个报表。只需走进当地的网吧或者从宾馆连接到Internet就可以了。将信息放在Internet(公司的Intranet或者World Wide Web)上意味着真正地可以随时随地地进行办公。
OLAP和数据挖掘功能已经被嵌入到了Oracle数据库中
OLAP最先由关系数据库之父Dr. E.F.Codd给出了定义。他指出关系数据库最初不是为了提供数据合成、分析和数据合并---被定义为多维分析的功能而提出的。多年来一直需要分离的分析数据库(如Oracle Express)来提供在关系数据库中不可以提供的功能。
Oracle中添加了许多适合OLAP查询的特性&＃xff0c;现在有可能直接将Oracle数据库用作OLAP。为了提供分析功能&＃xff0c;如排名次、移动窗口汇总、分期比较、比率到报表、统计函数、反向百分比、假设登记和分配、柱状图和第一、最后一个汇总等&＃xff0c;SQL语言已经进行了相应的扩展。多级汇总可以使用立方体、卷和分组子集来计算许多计算直接在服务器上完成。这些功能允许在不使用复杂的自连接和子查询的情况下直接表示OLAP查询&＃xff0c;并允许优化器选择一个更好的执行计划。
数据挖掘功能是随用于分类、预测和联合的企业版的数据挖掘选项提供的。数据挖掘是知识发现过程的一部分。通过使用统计技巧&＃xff0c;大量的数据可以转换成有用的信息数据就像是从传统的矿藏中提取出来的原材料&＃xff0c;当它被转换成信息时&＃xff0c;它才像一种贵重的金属。
数据挖掘从数据中提取新的信息。它允许企业从他们的数据仓库中提取珍贵的未知的信息&＃xff0c;并使用信息来做出更加重要的商业决策。
知识发现过程通常在不知道查询将发现怎样的规律的情况下进行。读取大量的数据&＃xff0c;寻找可以分组到一起的相似性来检测模型和趋势。OLAP和DSS工具察看预先定义好的与数据的结构关联的关系。这些关系是通过约束和纬度来表示的。数据挖掘检测的是与数据的内容关联的关系&＃xff0c;这些关系上未定义&＃xff0c;比如&＃xff0c;那些产品最容易搭配起来销售&＃xff0c;称为市场购物篮分析。长时间的对数据的分析可以用来发现行为中的没有预料到的模型。一个活动被执行的可能性有时是在另一个活动之后才能确定的。通用的数据挖掘程序包括客户保持&＃xff0c;欺诈发现和客户够模式。数据可能是寻找新的市场机会的矿藏。
OLAP工具允许用来回答这样的问题&＃xff1a;11月份熔岩灯的销量是否比上一年增长了&＃xff1f;数据挖掘工具有助于识别类似这样的问题的答案&＃xff1a;什么因素决定了熔岩灯的销量&＃xff1f;分析人员通过OLAP工具从一个问题或者一个假设开始并查询数据仓库来证明或者推翻他们的理论。通过数据挖掘工具该工作从分析人员那里转移给计算机。数据挖掘工具视同各种不同的技巧来解决各种不同的问题&＃xff0c;并可以用来回答类似这样的问题&＃xff1a;这个人最可能购买或者喜欢那个商品&＃xff0c;具有多大的或然性&＃xff1f;购买这个商品的人还可能购买哪些其他的商品&＃xff1f;这种个性化类型可以在Amazon.com上看到&＃xff0c;并且在许多其他的网站上也正变得越来越常见。
Oracle 10g中的数据仓库特性
为了改善数据仓库的性能和可管理性&＃xff0c;Oracle 10g专门引入了许多新的特性&＃xff1a;
*ETL处理
&Oracle Change Data Capture(CDC)简化了自上次数据抽取之后发生了变化的数据的识别过程。数据的变化可以通过使用基于触发器的机制与事务同步地识别&＃xff0c;也可以通过挖掘归档日志来异步地识别。
&Heterogeneous Transportable Tablespaces提供了在不同的一年关键平台之间移动大量的数据的高效的机制。
&外部表允许在数据加载到数据库或者从数据库中卸载时按照数据原来的形式来转换数据。
&Data Pump在Oracle数据库之间高速地移动大量数据和元数据的功能&＃xff0c;是Export和Import实用程序的替代产品。
*擅长分析的分析报告。商务智能计算可能需要SQL语言之外的扩展编程。为了解决这个问题&＃xff0c;许多分析计算功能已经添加到Oracle数据库中。
&通过新的SQL Model Clause&＃xff0c;关系数据可以被看作是一个多维的数组&＃xff0c;对这个数组可以应用像预算和预测这样的用于应用建模的类似于电子表格的算法。
*自动顾问
解决一个问题的最困难的事情之一是能够再生这个问题并捕捉问题发生时系统发生了些什么事情。在Oracle 10g中&＃xff0c;代表系统状态的性能统计可以被周期性地收集起来(缺省时是每小时一次)并存储在数据库中的Automatic Workload Repository(AWR)中。然后这些数据被Automatic Database Diagnostic Monitor(ADDM)分析来发现和诊断性能问题。它可以发现过度的I/O、CPU瓶颈、过度的解析、并发问题、PGA、缓存区缓存或者日志缓冲区大小问题。其中一些问题可以自动解决。例如&＃xff0c;Oracle 10g数据库可以自动地管理共享内存区域(SGA)&＃xff0c;为你消除为每个组件确定最优内存分配的需求。对其他们提可能会提供解决的建议。一个建议可能是执行新的顾问之一&＃xff0c;如SQL Tuning Advisor来调节一个执行很慢的SQL语句&＃xff0c;或者执行SQL Access Advisor来确定应该创建哪个索引或者物化视图来改善整个工作负荷的总体性能。
数据仓库的构建提出了许多挑战
数据仓库已经变成IT部门通过可用性和性能的服务层次协议来管理的业务操作的主流部分。因此数据仓库开发人员面临着许多挑战。他们必须确保随着数据仓库的数据量的增长&＃xff0c;数据仓库的性能得到很好的维护&＃xff0c;发展数据仓库来满足新的业务需求&＃xff0c;在不停止系统的情况下管理系统&＃xff0c;维护系统使系统免于非计划宕机&＃xff0c;在降低总体成本的同时做好所有这一切工作。
&管理数据仓库
随着数据仓库的数据增长到几个T的数据量及越来越高的高可用性需求的增加&＃xff0c;为分布在不同地区的用户维护好的系统性能变得异常重要。必须实施在线备份和恢复措施&＃xff0c;并且数据仓库中的数据的内容、用途和数据仓库中的活动必须得到很好的管理。
决策支持的工作负荷有着很大的差别。在一个OLTP系统中&＃xff0c;应用程序被调整得以尽可能快地处理许多一致的更新事务。在一个数据仓库中&＃xff0c;性能必须调整得尽可能处理更多的不同类型的查询。
应用模式为调整数据仓库已获得更好的性能奠定了基础。谁使用什么数据&＃xff1f;人们要查看哪个层次的汇总信息&＃xff1f;什么数据没有被用到&＃xff1f;数据是否以最高效的方式进行了结构化&＃xff1f;如果许多查询将一个表的数据与另外一个表进行连接&＃xff0c;那么取消规格化提前将它们连接起来可能更有好处。符合信息有助于确定在什么地方应该添加索引&＃xff0c;在什么地方应该将表合并&＃xff0c;以及在什么地方应该创建汇总信息。在发现和诊断性能问题和建议的解决办法方面&＃xff0c;前面提到的Oracle 10g数据库的新的诊断引擎可以提供大量的帮助。最后&＃xff0c;为了便于立即访问而将所有的详细数据保持在线的做法可能不再需要或者变得不再适用。数据可以在不保留副本的情况下被完全清除。或者可以被归档&＃xff0c;转移到一些廉价的介质如磁带或者CD-ROM上&＃xff0c;在以后需要的时候可以检索到。
&元数据的角色
元数据是描述在数据上其他数据和操作的数据。元数据是出于技术或者业务目的而被使用的。在业务系统到数据仓库的数据流动过程中数据被抽取、转换和汇总。需要技术元数据来描述这个过程&＃xff0c;对于适当的钻取更加精确的详细信息来说&＃xff0c;技术元数据是非常重要的。业务元数据允许终端用户确定数据仓库或者数据集市中那些数据是可用的以及如何访问这些数据。元数据提供了跨公司的数据的集成性和一致性。这里是不同部门描述他们对各种不同的术语(如product)的用法的地方。元数据存储在知识库中&＃xff0c;知识库通常是Oracle数据库中的一些表的集合。它可以被任何用户和工具所共享。
2000年&＃xff0c;Object Management Group(OMG)颁布了“通用数据仓库元模型”(Common Warehouse Metamodel, CWM)技术规范&＃xff0c;为所有的数据仓库和商务智能产品定义了元数据格式。该技术规范有包括Oracle和IBM公司的几个公司联合开发。自从该技术规范颁布后&＃xff0c;许多数据仓库产品已经发展得开始遵循该标准。
&日益增长的数据量
目前企业面临的最大的技术问题是数据量的爆炸。数据仓库是非常大的数据库。在2004年&＃xff0c;世界最大的商业数据仓库是用Oracle创建的&＃xff0c;数量已经达到30TB。有许多因素正在对这种数据量的增长在起作用。
*随着硬件的发展和存储成本的逐年持续下跌&＃xff0c;保存更多更加详细的历史数据在经济上成为可能。现在能够存储一个顾客在超市购买的每个产品的记录&＃xff0c;而不是他或她花费了25.75美元购买了5个商品这样的事实。
*企业正在存储这更长时期的越来越多的数据。
*出于不同的目的&＃xff0c;数据被存储了多次。创建索引和物化视图是为了改善查询的性能&＃xff0c;但是这些访问结构需要附加的空间&＃xff0c;进一步增加了数据库的大小。
*非结构化的数据可以被集成到传统的商务智能应用中。存储多媒体数据增加了数据库的大小。为了存储一个小时的视频信息大约需要1GB的存储空间。存储1分钟的音频数据需要1MB稍微少一点的空间。根据图像的类型和质量的不同&＃xff0c;一张图像的大小从20KB到60MB也不等。
*文档可以通过基于XML的元数据加以标签来标记并存储到Oracle数据库中。
但是&＃xff0c;数据仓库不应该被当成归档数据的知识库来使用&＃xff0c;这不是它的最初目的。
&更高的可用性
对于许多企业来说&＃xff0c;确保数据仓库的可用性正在变成越来越关键的任务。随着数据仓库在本质上变得更加贴近业务操作&＃xff0c;它给OLTP系统反馈信息&＃xff0c;在全球运作的企业中&＃xff0c;用户需要全天7*24小时&＃xff0c;全年365天地访问数据仓库。
Oracle数据库是为了消除计划停机的需求并经受任何失败&＃xff1a;系统失败、存储失败、站点失败、或者认为错误而设计的。如果一个服务器宕机了你的应用仍然可以保持运行。Real Application Clusters(RAC)使得应用程序具有高的可扩展性和更高的可用性&＃xff0c;正如前面所述&＃xff0c;是网格的基础。一个单独的数据库可以运行在集群在一起的服务器组上。随着附加的服务器添加到集群中&＃xff0c;应用程序可以在不进行修改的前提下进一步扩展来支持增加的吞吐量。Oracle Application Server可以具有负载均衡、集群农场的能力&＃xff0c;全部的配置可以使用Oracle Enterprise Manager Grid Control来管理。Data Guard可以被用来维护一个备用的数据库&＃xff0c;这是数据仓库的一个在事务上一直的副本&＃xff0c;可以用来确保在一个站点遇到灾难、人为错误或者数据损坏时以最小的中断来保持业务的连续。它也可以用来使计划停机维护(如硬件升级、或者Oracle软件的滚动升级)的时间降到最低。
*更多的用户更好的性能
在Web上发布报表的能力使得信息可以供更多的人来使用。随着数据仓库和商务智能工具使得越来越多的数据可以使用&＃xff0c;终端用户的数量也在急剧增长。对更好的性能的需求比以前更加重要。而且查询类型在复杂性上也与日俱增。
*新的应用类型
数据仓库正在被用来支持电子商务的新类型&＃xff0c;率先包含了客户关系管理和供应链管理。客户关系管理有助于吸引新的客户并开发客户的忠诚度特别实在显存客户的维持中非常重要。一个数据仓库包含了关于公司客户的信息并且经常是销售、市场和客户关心的应用的集成点。
数据仓库的未来
数据仓库下一步将发展到何方&＃xff1f;尽管没有人能够预测未来&＃xff0c;但是有一些趋势似乎正在进行中。
1.实时数据仓库
数据仓库正在发展得支持实时分析和决策。不是周期性地成批地更新数据仓库&＃xff0c;当一个事务在OLTP系统中提交时&＃xff0c;它将立刻变得在数据仓库中可以被使用&＃xff0c;提供实时决策的能力。这允许在支持战略决策的同时支持战术决策。它允许一个信用卡公司在诈骗发生时立刻发现并停止诈骗&＃xff0c;一个运输公司在有交通事故发生时立刻重新安排路由&＃xff0c;以及一个在线零售商根据客户的网上冲浪的行为来与特殊的贡献者进行交流。
Oracle 10g数据库Asynchronous Change Data Capture提供了一个以接近实时的方式装载数据的机制&＃xff0c;提供对最近的事务变化的访问。一旦数据到了数据仓库中&＃xff0c;就没有必要将它移到另外一个引擎中&＃xff0c;因为OLAP和数据挖掘功能现在就在Oracle数据库本地。
2.分离的数据集市的消失
将来的某一天我们有可能使用一个单独的数据库既作为OLTP又作为数据仓库。Oracle正在数据库中创建允许操作和分析能力混合的功能。采用这种方式&＃xff0c;就不再需要有一个单独的数据库来做OLTP、ODS、数据仓库、数据集市的事。这将消除大量的数据移动的需求---在这些数据库之间抽取、转换、装载、和复制---并减少集成和管理多个数据库的复杂性。在Oracle应用中&＃xff0c;OLTP和决策支持和报表使用RAC在同一个Oracle实例中完成。不再需要有单个的数据库引擎来负责关系数据、OLAP、数据挖掘或者ETL。这将大大简化数据仓库基础设施的操作和管理。当然仍然需要从多个数据源来集成数据&＃xff0c;除非所有的数据都存储到一个Oracle数据库中。
小结
我们从70年代的主机架构走到80年代的微型计算机再到90年代的客户服务器。在90年代末2000年代初&＃xff0c;Internet计算开始改变我们做任何事情的方式使得给大量的地域分布的用户群包括企业内部的和企业外部的客户和供应商发布商务智能应用程序成为可能。在90年代末许多公司大量的技术投资之后&＃xff0c;他们已经发现他们没有充分利用资产&＃xff0c;正在寻找降低操作成本的方式。数据合并和网格计算基于低成本的硬件&＃xff0c;可以提供大量的资金节约。
根据信息的数据源的不同&＃xff0c;数据集市可以是独立的也可以是依赖于其他系统的。依赖于其他系统的数据集市的信息源是一个现存的数据仓库&＃xff0c;它的数据直接从业务系统中抽取。由于独立的数据集市可以很快地建立起来&＃xff0c;在90年代中后期数据集市非常流行&＃xff0c;企业的每个部门根据自己的需求构建了部门自己的数据集市。不幸的是&＃xff0c;创建了几个数据集市后新的问题又出现了。每个数据集市是它自己的“信息孤岛”。一个和显然的问题是有两张对同一个问题有不同的答案的报表。
独立的数据集市之所以可以很快地发布的原因之一是它们延迟了许多在后来随着数据集市的数量不断增长时需求变得迫切的关键决策。独立的数据集市的数据只有一个部门需要标识和理解而不需要完全了解整个公司的所有的数据。创建独立的数据集市避免了与创建通用命名和编码标准相关的政治性问题。其他问题来自于单个数据集市通常由另外的不同的自治的团队创建的事实。这些团队通常选择不同的硬件、软件并使用不同的工具。每个独立的数据集市都直接从业务系统获取它的数据。这样随着数据集市的添加&＃xff0c;可能没有足够多的空闲周期来运行多个数据抽取程序。每个数据集市做它自己的数据清理和转换&＃xff0c;还可能采用稍微不同的处理方式。这样很容易造成数据的不一致性。冗余和数据不一致性导致不同的答案&＃xff0c;造成很难根据这些数据进行决策。可以想象一下在将来的某个时间将这些不同的视图合并成一个统一的数据仓库该有多么困难&＃xff01;
根据前面的讨论&＃xff0c;业务系统的数据和数据仓库中的数据之间有很大的区别。业务数据是关于公司当前状态的数据&＃xff0c;用来管理日常的业务操作。数据仓库中的数据是信息化的&＃xff0c;包含了关于过去的历史记录。如果需要提供关于业务当前状态的信息来做战略决策以便支持支持日常的业务&＃xff0c;可以创建一个业务数据源(Operational Data Source&＃xff0c;ODS)作为信息管理架构的一部分。业务数据源包含经过验证和清理的面向主题的集成的数据。它用来支持业务查询和报表。例如&＃xff0c;客户服务企业需要访问帐户余额和账单信息。业务数据源以接近实时的速度更新&＃xff0c;因此它实时反映了当前的状态。业务数据源可以作为数据集市或数据仓库的数据源。
为了解决这些问题并且能够及时收回投资&＃xff0c;人们开始采用分段实施的方式每次只构建一个功能领域的数据仓库&＃xff0c;而不是一下子构建一个代表整个公司的数据仓库。图1.1展示了目前使用的最流行的架构。数据从OLTP系统和外部数据源中抽取&＃xff0c;装载到业务数据仓库和企业数据仓库中&＃xff0c;并装载到独立的数据集市中。
构建数据仓库和开发一个软件一样&＃xff0c;不可能在一个版本中解决所有的问题&＃xff0c;永远也不可能预见所有可能的应用。一整套改革计划的("big bang")方法的另一个问题是在今后的一些年里情况发生了变化&＃xff0c;用户的需求和现在不同了&＃xff0c;数据仓库的实现简直就是错的。最好是开发一个总体的架构&＃xff0c;构建一个具有允许分段创建的组件的框架。分段实施的方法提供了与业务的持续的沟通和反馈。界定实施的范围&＃xff0c;并计划每三到六个月改进一次。
报表、查询和分析工具变成了基于浏览器的工具了
1995年&＃xff0c;Oracle的创始人和CEO Larry Ellision首次引入了他的网络计算机的观点&＃xff1a;一台方便地运行通过Internet访问信息的应用程序的小的廉价的设备。尽管网络计算机从来没有赢得大量的市场份额&＃xff0c;以Internet为中心的商业计算的观点加速了PCs的价格的下降&＃xff0c;满足了更加便宜的简单的桌面计算的需求。在Web上发布报表的能力使得信息可以供几乎每个人使用。给公司员工、合作伙伴和客户提供实时的关键信息。再也不用非得到办公室去才能查看一个报表。只需走进当地的网吧或者从宾馆连接到Internet就可以了。将信息放在Internet(公司的Intranet或者World Wide Web)上意味着真正地可以随时随地地进行办公。
OLAP和数据挖掘功能已经被嵌入到了Oracle数据库中
OLAP最先由关系数据库之父Dr. E.F.Codd给出了定义。他指出关系数据库最初不是为了提供数据合成、分析和数据合并---被定义为多维分析的功能而提出的。多年来一直需要分离的分析数据库(如Oracle Express)来提供在关系数据库中不可以提供的功能。
Oracle中添加了许多适合OLAP查询的特性&＃xff0c;现在有可能直接将Oracle数据库用作OLAP。为了提供分析功能&＃xff0c;如排名次、移动窗口汇总、分期比较、比率到报表、统计函数、反向百分比、假设登记和分配、柱状图和第一、最后一个汇总等&＃xff0c;SQL语言已经进行了相应的扩展。多级汇总可以使用立方体、卷和分组子集来计算许多计算直接在服务器上完成。这些功能允许在不使用复杂的自连接和子查询的情况下直接表示OLAP查询&＃xff0c;并允许优化器选择一个更好的执行计划。
数据挖掘功能是随用于分类、预测和联合的企业版的数据挖掘选项提供的。数据挖掘是知识发现过程的一部分。通过使用统计技巧&＃xff0c;大量的数据可以转换成有用的信息数据就像是从传统的矿藏中提取出来的原材料&＃xff0c;当它被转换成信息时&＃xff0c;它才像一种贵重的金属。
数据挖掘从数据中提取新的信息。它允许企业从他们的数据仓库中提取珍贵的未知的信息&＃xff0c;并使用信息来做出更加重要的商业决策。
知识发现过程通常在不知道查询将发现怎样的规律的情况下进行。读取大量的数据&＃xff0c;寻找可以分组到一起的相似性来检测模型和趋势。OLAP和DSS工具察看预先定义好的与数据的结构关联的关系。这些关系是通过约束和纬度来表示的。数据挖掘检测的是与数据的内容关联的关系&＃xff0c;这些关系上未定义&＃xff0c;比如&＃xff0c;那些产品最容易搭配起来销售&＃xff0c;称为市场购物篮分析。长时间的对数据的分析可以用来发现行为中的没有预料到的模型。一个活动被执行的可能性有时是在另一个活动之后才能确定的。通用的数据挖掘程序包括客户保持&＃xff0c;欺诈发现和客户够模式。数据可能是寻找新的市场机会的矿藏。
OLAP工具允许用来回答这样的问题&＃xff1a;11月份熔岩灯的销量是否比上一年增长了&＃xff1f;数据挖掘工具有助于识别类似这样的问题的答案&＃xff1a;什么因素决定了熔岩灯的销量&＃xff1f;分析人员通过OLAP工具从一个问题或者一个假设开始并查询数据仓库来证明或者推翻他们的理论。通过数据挖掘工具该工作从分析人员那里转移给计算机。数据挖掘工具视同各种不同的技巧来解决各种不同的问题&＃xff0c;并可以用来回答类似这样的问题&＃xff1a;这个人最可能购买或者喜欢那个商品&＃xff0c;具有多大的或然性&＃xff1f;购买这个商品的人还可能购买哪些其他的商品&＃xff1f;这种个性化类型可以在Amazon.com上看到&＃xff0c;并且在许多其他的网站上也正变得越来越常见。
Oracle 10g中的数据仓库特性
为了改善数据仓库的性能和可管理性&＃xff0c;Oracle 10g专门引入了许多新的特性&＃xff1a;
*ETL处理
&Oracle Change Data Capture(CDC)简化了自上次数据抽取之后发生了变化的数据的识别过程。数据的变化可以通过使用基于触发器的机制与事务同步地识别&＃xff0c;也可以通过挖掘归档日志来异步地识别。
&Heterogeneous Transportable Tablespaces提供了在不同的一年关键平台之间移动大量的数据的高效的机制。
&外部表允许在数据加载到数据库或者从数据库中卸载时按照数据原来的形式来转换数据。
&Data Pump在Oracle数据库之间高速地移动大量数据和元数据的功能&＃xff0c;是Export和Import实用程序的替代产品。
*擅长分析的分析报告。商务智能计算可能需要SQL语言之外的扩展编程。为了解决这个问题&＃xff0c;许多分析计算功能已经添加到Oracle数据库中。
&通过新的SQL Model Clause&＃xff0c;关系数据可以被看作是一个多维的数组&＃xff0c;对这个数组可以应用像预算和预测这样的用于应用建模的类似于电子表格的算法。
*自动顾问
解决一个问题的最困难的事情之一是能够再生这个问题并捕捉问题发生时系统发生了些什么事情。在Oracle 10g中&＃xff0c;代表系统状态的性能统计可以被周期性地收集起来(缺省时是每小时一次)并存储在数据库中的Automatic Workload Repository(AWR)中。然后这些数据被Automatic Database Diagnostic Monitor(ADDM)分析来发现和诊断性能问题。它可以发现过度的I/O、CPU瓶颈、过度的解析、并发问题、PGA、缓存区缓存或者日志缓冲区大小问题。其中一些问题可以自动解决。例如&＃xff0c;Oracle 10g数据库可以自动地管理共享内存区域(SGA)&＃xff0c;为你消除为每个组件确定最优内存分配的需求。对其他们提可能会提供解决的建议。一个建议可能是执行新的顾问之一&＃xff0c;如SQL Tuning Advisor来调节一个执行很慢的SQL语句&＃xff0c;或者执行SQL Access Advisor来确定应该创建哪个索引或者物化视图来改善整个工作负荷的总体性能。
数据仓库的构建提出了许多挑战
数据仓库已经变成IT部门通过可用性和性能的服务层次协议来管理的业务操作的主流部分。因此数据仓库开发人员面临着许多挑战。他们必须确保随着数据仓库的数据量的增长&＃xff0c;数据仓库的性能得到很好的维护&＃xff0c;发展数据仓库来满足新的业务需求&＃xff0c;在不停止系统的情况下管理系统&＃xff0c;维护系统使系统免于非计划宕机&＃xff0c;在降低总体成本的同时做好所有这一切工作。
&管理数据仓库
随着数据仓库的数据增长到几个T的数据量及越来越高的高可用性需求的增加&＃xff0c;为分布在不同地区的用户维护好的系统性能变得异常重要。必须实施在线备份和恢复措施&＃xff0c;并且数据仓库中的数据的内容、用途和数据仓库中的活动必须得到很好的管理。
决策支持的工作负荷有着很大的差别。在一个OLTP系统中&＃xff0c;应用程序被调整得以尽可能快地处理许多一致的更新事务。在一个数据仓库中&＃xff0c;性能必须调整得尽可能处理更多的不同类型的查询。
应用模式为调整数据仓库已获得更好的性能奠定了基础。谁使用什么数据&＃xff1f;人们要查看哪个层次的汇总信息&＃xff1f;什么数据没有被用到&＃xff1f;数据是否以最高效的方式进行了结构化&＃xff1f;如果许多查询将一个表的数据与另外一个表进行连接&＃xff0c;那么取消规格化提前将它们连接起来可能更有好处。符合信息有助于确定在什么地方应该添加索引&＃xff0c;在什么地方应该将表合并&＃xff0c;以及在什么地方应该创建汇总信息。在发现和诊断性能问题和建议的解决办法方面&＃xff0c;前面提到的Oracle 10g数据库的新的诊断引擎可以提供大量的帮助。最后&＃xff0c;为了便于立即访问而将所有的详细数据保持在线的做法可能不再需要或者变得不再适用。数据可以在不保留副本的情况下被完全清除。或者可以被归档&＃xff0c;转移到一些廉价的介质如磁带或者CD-ROM上&＃xff0c;在以后需要的时候可以检索到。
&元数据的角色
元数据是描述在数据上其他数据和操作的数据。元数据是出于技术或者业务目的而被使用的。在业务系统到数据仓库的数据流动过程中数据被抽取、转换和汇总。需要技术元数据来描述这个过程&＃xff0c;对于适当的钻取更加精确的详细信息来说&＃xff0c;技术元数据是非常重要的。业务元数据允许终端用户确定数据仓库或者数据集市中那些数据是可用的以及如何访问这些数据。元数据提供了跨公司的数据的集成性和一致性。这里是不同部门描述他们对各种不同的术语(如product)的用法的地方。元数据存储在知识库中&＃xff0c;知识库通常是Oracle数据库中的一些表的集合。它可以被任何用户和工具所共享。
2000年&＃xff0c;Object Management Group(OMG)颁布了“通用数据仓库元模型”(Common Warehouse Metamodel, CWM)技术规范&＃xff0c;为所有的数据仓库和商务智能产品定义了元数据格式。该技术规范有包括Oracle和IBM公司的几个公司联合开发。自从该技术规范颁布后&＃xff0c;许多数据仓库产品已经发展得开始遵循该标准。
&日益增长的数据量
目前企业面临的最大的技术问题是数据量的爆炸。数据仓库是非常大的数据库。在2004年&＃xff0c;世界最大的商业数据仓库是用Oracle创建的&＃xff0c;数量已经达到30TB。有许多因素正在对这种数据量的增长在起作用。
*随着硬件的发展和存储成本的逐年持续下跌&＃xff0c;保存更多更加详细的历史数据在经济上成为可能。现在能够存储一个顾客在超市购买的每个产品的记录&＃xff0c;而不是他或她花费了25.75美元购买了5个商品这样的事实。
*企业正在存储这更长时期的越来越多的数据。
*出于不同的目的&＃xff0c;数据被存储了多次。创建索引和物化视图是为了改善查询的性能&＃xff0c;但是这些访问结构需要附加的空间&＃xff0c;进一步增加了数据库的大小。
*非结构化的数据可以被集成到传统的商务智能应用中。存储多媒体数据增加了数据库的大小。为了存储一个小时的视频信息大约需要1GB的存储空间。存储1分钟的音频数据需要1MB稍微少一点的空间。根据图像的类型和质量的不同&＃xff0c;一张图像的大小从20KB到60MB也不等。
*文档可以通过基于XML的元数据加以标签来标记并存储到Oracle数据库中。
但是&＃xff0c;数据仓库不应该被当成归档数据的知识库来使用&＃xff0c;这不是它的最初目的。
&更高的可用性
对于许多企业来说&＃xff0c;确保数据仓库的可用性正在变成越来越关键的任务。随着数据仓库在本质上变得更加贴近业务操作&＃xff0c;它给OLTP系统反馈信息&＃xff0c;在全球运作的企业中&＃xff0c;用户需要全天7*24小时&＃xff0c;全年365天地访问数据仓库。
Oracle数据库是为了消除计划停机的需求并经受任何失败&＃xff1a;系统失败、存储失败、站点失败、或者认为错误而设计的。如果一个服务器宕机了你的应用仍然可以保持运行。Real Application Clusters(RAC)使得应用程序具有高的可扩展性和更高的可用性&＃xff0c;正如前面所述&＃xff0c;是网格的基础。一个单独的数据库可以运行在集群在一起的服务器组上。随着附加的服务器添加到集群中&＃xff0c;应用程序可以在不进行修改的前提下进一步扩展来支持增加的吞吐量。Oracle Application Server可以具有负载均衡、集群农场的能力&＃xff0c;全部的配置可以使用Oracle Enterprise Manager Grid Control来管理。Data Guard可以被用来维护一个备用的数据库&＃xff0c;这是数据仓库的一个在事务上一直的副本&＃xff0c;可以用来确保在一个站点遇到灾难、人为错误或者数据损坏时以最小的中断来保持业务的连续。它也可以用来使计划停机维护(如硬件升级、或者Oracle软件的滚动升级)的时间降到最低。
*更多的用户更好的性能
在Web上发布报表的能力使得信息可以供更多的人来使用。随着数据仓库和商务智能工具使得越来越多的数据可以使用&＃xff0c;终端用户的数量也在急剧增长。对更好的性能的需求比以前更加重要。而且查询类型在复杂性上也与日俱增。
*新的应用类型
数据仓库正在被用来支持电子商务的新类型&＃xff0c;率先包含了客户关系管理和供应链管理。客户关系管理有助于吸引新的客户并开发客户的忠诚度特别实在显存客户的维持中非常重要。一个数据仓库包含了关于公司客户的信息并且经常是销售、市场和客户关心的应用的集成点。
数据仓库的未来
数据仓库下一步将发展到何方&＃xff1f;尽管没有人能够预测未来&＃xff0c;但是有一些趋势似乎正在进行中。
1.实时数据仓库
数据仓库正在发展得支持实时分析和决策。不是周期性地成批地更新数据仓库&＃xff0c;当一个事务在OLTP系统中提交时&＃xff0c;它将立刻变得在数据仓库中可以被使用&＃xff0c;提供实时决策的能力。这允许在支持战略决策的同时支持战术决策。它允许一个信用卡公司在诈骗发生时立刻发现并停止诈骗&＃xff0c;一个运输公司在有交通事故发生时立刻重新安排路由&＃xff0c;以及一个在线零售商根据客户的网上冲浪的行为来与特殊的贡献者进行交流。
Oracle 10g数据库Asynchronous Change Data Capture提供了一个以接近实时的方式装载数据的机制&＃xff0c;提供对最近的事务变化的访问。一旦数据到了数据仓库中&＃xff0c;就没有必要将它移到另外一个引擎中&＃xff0c;因为OLAP和数据挖掘功能现在就在Oracle数据库本地。
2.分离的数据集市的消失
将来的某一天我们有可能使用一个单独的数据库既作为OLTP又作为数据仓库。Oracle正在数据库中创建允许操作和分析能力混合的功能。采用这种方式&＃xff0c;就不再需要有一个单独的数据库来做OLTP、ODS、数据仓库、数据集市的事。这将消除大量的数据移动的需求---在这些数据库之间抽取、转换、装载、和复制---并减少集成和管理多个数据库的复杂性。在Oracle应用中&＃xff0c;OLTP和决策支持和报表使用RAC在同一个Oracle实例中完成。不再需要有单个的数据库引擎来负责关系数据、OLAP、数据挖掘或者ETL。这将大大简化数据仓库基础设施的操作和管理。当然仍然需要从多个数据源来集成数据&＃xff0c;除非所有的数据都存储到一个Oracle数据库中。
小结
我们从70年代的主机架构走到80年代的微型计算机再到90年代的客户服务器。在90年代末2000年代初&＃xff0c;Internet计算开始改变我们做任何事情的方式使得给大量的地域分布的用户群包括企业内部的和企业外部的客户和供应商发布商务智能应用程序成为可能。在90年代末许多公司大量的技术投资之后&＃xff0c;他们已经发现他们没有充分利用资产&＃xff0c;正在寻找降低操作成本的方式。数据合并和网格计算基于低成本的硬件&＃xff0c;可以提供大量的资金节约。
OLTP(Online Transaction Processing)联机事务处理
general ledger总账
staging area 临时数据交换区
京公网安备 11010802041100号