oracle 数据仓库与数据库的区别???????

[funny_god]

如题， 望高手解惑！！对于ORACLE 和数据仓库的学习，有什么好的建议！！！！！

[rucypli]

找本高手推荐得或者销量好的书 看

[BI_expert]

这是四大数据库的比较（SQLServer、Oracle、Sybase和DB2）您看看吧开放性:
　　SQL Server
　　只能在windows上运行，没有丝毫的开放性，操作系统的系统的稳定对数据库是十分重要的。Windows9X系列产品是偏重于桌面应用NT server只适合中小型企业。而且windows平台的可靠性，安全性和伸缩性是非常有限的。它不象unix那样久经考验，尤其是在处理大数据。
　　Oracle
　　能在所有主流平台上运行（包括 windows）。完全支持所有的工业标准。采用完全开放策略。可以使客户选择最适合的解决方案。对开发商全力支持。
　　Sybase ASE
　　能在所有主流平台上运行（包括 windows）。 但由于早期Sybase与OS集成度不高，因此VERSION 11.9.2以下版本需要较多OS和 DB级补丁。在多平台的混合环境中，会有一定问题。

　　DB2
　　能在所有主流平台上运行（包括windows）。最适于海量数据。DB2在企业级的应用最为广泛，在全球的500家最大的企业中,几乎85%以上用DB2数据库服务器，而国内到97年约占5%。
　　可伸缩性，并行性
　　SQL Server
　　并行实施和共存模型并不成熟。很难处理日益增多的用户数和数据卷。伸缩性有限。
　　Oracle
　　并行服务器通过使一组结点共享同一簇中的工作来扩展windowsNT的能力，提供高可用性和高伸缩性的簇的解决方案。如果windowsNT不能满足需要，用户可以把数据库移到UNIX中。Oracle的并行服务器对各种UNIX平台的集群机制都有着相当高的集成度。
　　Sybase ASE
　　虽然有DB SWITCH来支持其并行服务器，但由于DB SWITCH在技术层面还未成熟，且只支持版本12.5以上的ASE SERVER，因为DB SWITCH技术需要一台服务器充当SWITCH.
　　DB2
　　具有很好的并行性。DB2把数据库管理扩充到了并行的、多节点的环境。数据库分区是数据库的一部分，包含自己的数据、索引、配置文件、和事务日志。数据库分区有时被称为节点.
　安全性
　　SQL Server
　　没有获得任何安全证书。

　　Oracle Server
　　获得最高认证级别的ISO标准认证。
　　Sybase ASE
　　获得最高认证级别的ISO标准认证。
　　DB2
　　获得最高认证级别的ISO标准认证。
　　性能
　　SQL Server
　　多用户时性能不佳
　　Oracle
　　性能最高， 保持开放平台下的TPC-D和TPC-C的世界记录。
　　Sybase ASE
　　性能接近于 SQL Server。但在UNIX平台下的并发性要优与 SQL Server。
　　DB2
　　性能较高适用于数据仓库和在线事物处理。
　　客户端支持及应用模式
　　SQL Server
　　C/S结构，只支持windows客户，可以用ADO,DAO,OLEDB,ODBC连接.
　　Oracle
　　多层次网络计算，支持多种工业标准，可以用ODBC，JDBC，OCI等网络客户连接。
　　Sybase ASE
　　C/S结构，可以用ODBC，Jconnect，Ct-library等网络客户连接。
　　DB2
　　跨平台，多层结构，支持ODBC,JDBC等客户
　　操作简便
　　SQL Server
　　操作简单，但只有图形界面。

　　Oracle
　　较复杂，同时提供GUI和命令行，在windowsNT和unix下操作相同
　　Sybase ASE
　　较复杂，同时提供GUI和命令行。但GUI较差，常常无法及时状态，建议使用命令行。
　　DB2
　　操作简单，同时提供GUI和命令行，在windowsNT和unix下操作相同
　　使用风险
　　SQL Server
　　完全重写的代码，经历了长期的测试，不断延迟，许多功能需要时间来证明。并不十分兼
　　Oracle
　　长时间的开发经验，完全向下兼容。得到广泛的应用。完全没有风险。
　　Sybase ASE
　　向下兼容, 但是ct-library 程序不益移植。
　　DB2
　　在巨型企业得到广泛的应用，向下兼容性好。风险小。
　　经过上述比较，我们不难发现，DB2是最好的数据库。

[wjhx]

数据库是事务型的，数据仓库可以是多维的

[grcff]

数据仓库可以看成是数据库的一部分，两者都是用来存储数据的，只不过一般数据库是OLTP（联机事务处是）,里面存的是关系型数据，记录我们对数据的增删改查等操作。数据仓库是在数据库应用到一定程序之后而对历史数据的加工与分析；是处理两种不同用途的工具而已。

要学数据仓库，先把数据仓库的几大模块之间的关系及作用弄清楚，，再学起来就容易很多了啊。

[hot305]

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。

数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。

数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。

单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。

显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。

“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。

数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。

1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。

2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。

3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。

[jxym001]

引用 4 楼 grcff 的回复:

数据仓库可以看成是数据库的一部分，两者都是用来存储数据的，只不过一般数据库是OLTP（联机事务处是）,里面存的是关系型数据，记录我们对数据的增删改查等操作。数据仓库是在数据库应用到一定程序之后而对历史数据的加工与分析；是处理两种不同用途的工具而已。 要学数据仓库，先把数据仓库的几大模块之间的关系及作用弄清楚，，再学起来就容易很多了啊。

数据仓库的几大模块是哪些？

[u010184320]

这个不大好说，一般情况下是不一样的

[jiaht418]

个人感觉数据仓库几个大的部分： 1、ETL 2、数据集成（用RLOAP或者专门的数据仓库服务器） 3、元数据管理 4、数据分析、数据挖掘 5、数据展示

[to2my2]

数据仓库便于数据分析

[coder_geek]

引用 6 楼 hot305 的回复:

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。 “与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。 “不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。 数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。 补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。 1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。 2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。 3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。

说得很细，很全面，学习到了！求指教关于数据仓库的入门。谢谢

[南风bu竞]

只知道星星和雪花

[babyqian84]

引用 11 楼 jiaht418 的回复:

个人感觉数据仓库几个大的部分： 1、ETL 2、数据集成（用RLOAP或者专门的数据仓库服务器） 3、元数据管理 4、数据分析、数据挖掘 5、数据展示

6楼的是理论分析，很到位，11楼算是白话文告诉你其实数据仓库在干什么。 我理解楼主的意思，就想搞明白数据仓库到底是什么，总有个实物吧，接触了一段时间发现这实物就是数据库啊，所以就困惑了。因为我本人也是很讨厌专业术语，枯燥的理论这种东西，实在很虚，心里怎么都没有踏实感。我以我的经验，再把6楼的思想，按照11楼的分块部分白话文一下。 举个简单的例子，假设我们有一家小卖部，每天卖多少，营业额是多少，细心的老板可能还记个账，心里有个底，粗心的连帐都不记。那么这种规模，完全不需要什么数据库，数据仓库，每天大概挣多少，每年挣多少心里不是都清清楚楚的。随着生意好了，我们翻新成一家小超市，卖更多的产品，不用任何市场调研，用常识就能判断货品范围，卖几个月也能总结出进货量，出货量，这时候可能要请几个工人，账目就要记起来了，一家店的时候，我们用本子，或者电脑EXCEL记一下也是可以的，但扩张了几个连锁店后，如果你是老板，你也不放心每家店都靠这样记的吧，然后你就要考虑买POS机，每天的销售记录仔仔细细都在系统（数据库）里面存着，这就是业务处理数据库，如果这时候所发生的业务就几十万的量，放在一张hist表中，也许下一句复杂点的SQL也能做出一些简单条件的业绩报表，但是如果连锁超市往超级市场SUPERmart方向发展，那业务处理量大了之后，hist表大到不能直接在上面下复杂SQL了，下了之后超市实时的业务处理会受到影响，而且不能我每次需要这样的SUMMARY数据都用彪悍的方法来QUERY吧，并且，这时候我们对业绩分析的要求也提高了，就不仅仅局限于按照时间（天，周，月，季度，年度）或按照品种来进行统计，我可能要细分，比如老板要求你统计每个周六周日下午三点以后的刷卡的交易额，并且其中同一张单子中有购买两种以上类别（日用，食品，体育等）的单子情况，（这里我只是举例，这也涉及到商业智能了，这些分析可能可以给大老板的一些决策提供一些参考。但是不是所有老板都会有这方面的想法），但作为日常的分析，我们可能需要写一些额外的程序进行数据分析，并且把这些数据保存到另外一个业务分析数据库中。 至此，我想说明的是，数据仓库这个概念，跟我们一些企业日常在做的工作，整个界限是模糊的，你可以认为我们做的工作中，已经有部分工作在系统的进行数据处理的就是在做数据仓库，不一定是要使用什么级别的数据库，或者使用什么工具。 所以，现在我的超市规模大了，但是我也已经有了数据库，已经做了一部分有条理或没条理的数据整理工作，这种工作可能是老板要求，我们被动去做的，或者我们根据工作经验主动事先做好的。但现在大老板是一个有商业思想并且认可BI的理念的，即，他有很高的职位和权利，有号召能力，认可数据的重要性，认可数据分析带来的参考意义，愿意花钱去做。愿意花钱去做是最关键的，因为有些公司不大不小的尴尬境地导致很难判断做了不能确定是否可以带来明显的商业利益，那做了干嘛呢？不如不做。 如果真要做的话，以前做好的东西未必是会摈弃的，因为在做数据仓库前，最主要的是分析业务模型，需求，然后按照规则整理数据，可能以前有些模块已经做得很好就不需要更改了。做的内容主要就是把原来的整理好，没有做的模块做好，或者做一些更高层次的数据分析，总结一些有指导意义的KPI值，做一些辅助工具等等。 那么，作为学院派，选择了数据仓库到底要学习什么呢？ 首先打好基础，11楼提到的模块中，ETL是很重要一部分，到底有多少层etl，要做多少数据抽取的工作，取决于需求和业务处理逻辑，一般1，2层，很复杂的来个3，5层不为过。ETL有很多工具，但说到底就是把数据抽取出来并整理好，比如从事务表中把一天的10多万笔记录统计成一条记录，以日期为主键记录到另一张以天为单位的SUMMARY表中，那么这个过程可以用工具来完成，也可以自己写程序来完成，存储过程，C，JAVA都可以，主要就是逻辑嘛。自己写的好处是知道原理。这里举个很简单的例子，有一次我需要用他部门的数据进行二次SUMMARY，定时任务常常跑不出来，记录是空的，但是我的程序LOG都正常，后来发现我使用的他部门的这张表是他们用工具从别处同步过来的，配置表数据量不大，每次全部更新是没问题的，在ORACLE 中也就几句话： delete from table_name; insert into table_name select * from table_name@otherdb; commit; 即便没有DBLINK,用其他方法也很简单，可偏偏他们使用的这个工具有点小问题，就是没有把delete和insert放在同一个transaction，导致更新时会出现很短暂的表为空的情况，在程序性能很差的时候放大为几秒钟，就这几秒钟的空档偶尔被我的程序踩中，所以我更新不到数据。搞笑的是对方的人员只会用工具，对这么简单的ORACLE常识都不了解，还口口声声说他们没问题，导致我不得不写个脚本监控抓他现行。 这个例子扯远了，我是在说基础知识的重要性，你学习java是好的，c也好，都不会荒废的。各种数据库，都玩玩，多写写。工具，了解就好，不要指望工具帮你解决所有问题。 元数据的管理涉及到数据库备份等问题，也是具体问题具体分析。 数据分析方面和行业都有关联，毕竟主要是业务逻辑的事儿。 数据展示倒是很重要的一块，分析了那么多，总要有展示的地方，就是报表，报表对有些行业很重要，实时性，准确性，稳定性各方面，但往往又受不到重视，因为地位上肯定远不及业务系统的可用性来的高，但花样很多，开发要求也越来越高，各种的bs的，CS的，二次开发的需求都有可能出来，谈不上有经验没经验，需求来了就得上，所以还是多学些技术比较靠谱。sap的bo,ibm的cognos，做的一般都巨贵，一般企业还是自己定制的比较多。 数据仓库更多的是概念，专业术语，去书城翻翻书看看，连买都不要买。有的企业数据分析也得涉及到unix，perl什么的，或者可能需要你了解甚至做部分的分布式业务系统的开发，就涉及更多了。所以，你的专业知识学了还是有用的，matlab学好了也是有好处的，比如金融分析师，MBA这类的，不是都用MATLAB嘛！技术的基础打打好，英语学学好，指不定将来进入哪个行业，用到哪些技能呢，学多了总是相通的。 以上一点浅显的愚见，有点乱，楼主随便感受一下吧。

[babyqian84]

不好意思，在回复的时候把你的背景和另一个帖子搞混了，网页开太多了，所以，有些不太对，不过也可以参考一下吧

[funny_god]

引用 16 楼 babyqian84 的回复:

不好意思，在回复的时候把你的背景和另一个帖子搞混了，网页开太多了，所以，有些不太对，不过也可以参考一下吧

说的相当棒，呵呵这个帖子是我刚工作的时候发的，现在也过了快一年了，之前总逛论坛但不爱登陆，今晚突然想起来了，就上来看看，我还在做仓库这块，平时写存储过程的时候还是少。ETL工具居多，眼下项目已经上线，主要是上线后的维护，保证批量执行时效，学者做做SQL优化。

[babyqian84]

引用 17 楼 scwanghao86 的回复:

[quote=引用 16 楼 babyqian84 的回复:] 不好意思，在回复的时候把你的背景和另一个帖子搞混了，网页开太多了，所以，有些不太对，不过也可以参考一下吧

说的相当棒，呵呵这个帖子是我刚工作的时候发的，现在也过了快一年了，之前总逛论坛但不爱登陆，今晚突然想起来了，就上来看看，我还在做仓库这块，平时写存储过程的时候还是少。ETL工具居多，眼下项目已经上线，主要是上线后的维护，保证批量执行时效，学者做做SQL优化。[/quote] 那就继续加油吧，工具有工具的好处和优势，但要尽量去搞明白背后原理。肯花钱买工具都是有钱的公司阿，^_^ 我记得有本书名大概叫数据仓库生命周期工具箱，偏管理方面的，术语不少，可以去书店翻翻看了解一下

[avalon]

帖子的回复内容不错，特此登录顶！！

[funny_god]

哈哈，过了很长时间，我今天又上来看看，数据仓库生命周期工具箱下了个电子版的，但是工作忙了也没时间看了。

[Harry_Burt]

说的不错，学习了