数据仓库技术简介
作者:周永銮发布时间:2001/07/21
数据仓库是近年来兴起的一种新的数据库应用。在各大数据库厂商纷纷宣布产品支持数据仓库并提出一整套用以建立和使用数据仓库的产品是,业界掀起了数据库热。比如INFORMIXGONGSIDE公司的数据仓库解决方案;ORACLE公司的数据仓库解决方案;Sybase公司的交互式数据仓库解决方案等等。这同时也引起了学术界的极大兴趣,国际上许多重要的学术会议,如超大型数据库国际会议(VLDB),数据工程国际会议(Data Engineering)等,都出现了专门研究数据仓库(Data Warehousing,简记为DW)、联机分析处理(On-Line Analytical Processing,简记为OLAP)、数据挖掘(Data Mining, 简记为DM)的论文。对我国许多企业而言,在建立或发展自己的信息系统常常困扰于这样的问题:为什么要在原有的数据库上建立数据仓库?数据仓库能否代替传统的数据库?怎样建立数据仓库?等等。本章将简要介绍一下用到的数据仓库技术背景,并在下一章结合数据清理系统设计实例,更深一步阐述数据仓库技术在现实中的重大意义§1 从数据库到数据仓库传统的数据库技术是以单一的数据资源,即数据库为中心,进行事务处理、批处理、决策分析等各种数据处理工作,主要的划分为两大类:操作型处理和分析型处理(或信息型处理)。 操作型处理也叫事务处理,是指对数据库联机的日常操作,通常是对一个或一组纪录的查询和修改,主要为企业的特定应用服务的,注重响应时间,数据的安全性和完整性;分析型处理则用于管理人员的决策分析,经常要访问大量的历史数据。而传统数据库系统优于企业的日常事务处理工作,而难于实现对数据分析处理要求,已经无法满足数据处理多样化的要求。操作型处理和分析型处理的分离成为必然。
近年来,随着数据库技术的应用和发展,人们尝试对DB中的数据进行再加工,形成一个综合的,面向分析的环境,以更好支持决策分析,从而形成了数据仓库技术(Data Warehousing,简称DW)。作为决策支持系统(Decision-making Support System,简称DSS),数据仓库系统包括:
① 数据仓库技术;
② 联机分析处理技术(On-Line Analytical Processing,简称OLAP);
③ 数据挖掘技术(Data Mining,简称DM);
数据仓库弥补了原有的数据库的缺点,将原来的以单一数据库为中心的数据环境发展为一种新环境:体系化环境。如图1.1所示:
.....

解决方案 »

  1.   

    to  pengdali(大力)非常感谢您的答复,数据仓库的介绍我也看过一些,可是还是没有看到我要的答案,请你直接给我一个答案好吗?
    问题还是上面的那个:
    数据仓库有没有适用范围啊?比如要求数据库结构比较简单,数据表之间的关系不能太复杂之类的?还是只要是大数据量的数据库都可以应用数据仓库带来的好处?
      

  2.   

    你不一定要用olap但你可以建立自己的数据仓库表,等条件成熟再导入到olap中,这样你又可以在短时间解决统计速度问题,以后又可以利用数据仓库的强大功能
      

  3.   

    那在导入olap之前如何解决速度问题?还是分表存放?
      

  4.   

    我觉得当前还有一种选择就是运用SQL SERVER的全文检索功能,具体实施你自己看一下。
      

  5.   

    to  pengdali(大力)你的意思就是要么要数据仓库,要么就是用分表存放?
      

  6.   

    其实在ms-sqlserver中,有联合视图的概念,所谓联合视图,是将几个不同的表何成在一起,形成逻辑视图,比如你将1,2,3的月份分别建表,在用联合视图将它合在一起。
    如果速度你还嫌弃慢,你可以使用linux+oracle,速度绝对快,我曾经做过一个项目,就是话单备份系统,每个月的数据是一亿条记录,当然是条件查询,也不过是几秒钟的事情。不过我看你的数据规模,sqlserver因该可以处理的,用linux很麻烦,真的
      

  7.   

    在SQL2000中引入了分区视图的概念,非常适合你说的情况,你可以看看SQL2000的Online Book,用分区视图搜索一下就可以找到。跟Oracle的分区表有异曲同工之妙.
      

  8.   

    to eliotbao() 分区视图的概念能解决速度问题吗?
      

  9.   

    不!数据仓库和你分不分表存放没有关系,我支持分表存放,就像上面说的可以用分区视图来访问所有的表,但对与历史数据的统计,不得不考虑速度与数据量,一个简单的历史统计、分析、需要几分钟出来结果,那你的设计是失败的,你必须考虑使用数据仓库技术,它很简单,只要你去用,不一定非要olap,关键是概念,当然olap是强大的我也在学习.想到什么说说什么,请见谅,希望你能明白!
      

  10.   

    用单表,用索引。特别对where子句、group by子句、order by子句、join子句所用的字段。
    在Access数据库中跑十年的数据(百万条)也还不慢。
    请再观察一下其它问题:内存够么?CPU 运算能力够么?如果它老是调用虚拟内存,如何能快呢?
      

  11.   

    我之所以不想用分表存放是因为其对编程带来的麻烦,没有单表平板式的来的爽。可是单表我又担心数据量大了,一年的数据就有3千万左右的记录,五年的数据会有1亿多了,如果对这么个规模的表进行很复杂的查询,可能要同五六张表关联,where子句、group by等等都要用到,不知sql server 2000是否可以做到在30秒之内完成。
    你们所说的分区视图我想就是把同样结构的许多表虚拟成一张单表使用,我想这样还是解决不了速度问题。
    至于数据仓库我到是很感兴趣,不过估计一时还上不了手。
      

  12.   

    分区视图,  MS SQL SERVER 联机丛书
      

  13.   

    to b615n(周围走) 
    每年有3000万呢
      

  14.   

    哈哈,还是用单表好!我的理由是:
    1)编程、维护都很简单。
    2)5年后,计算机速度不知道提高多少倍了,而且,SQLServer性能也可能改进到跟Oracle差不多。
    3)能用3年以上系统的真的不多。
    4)再没有信心,自己插入1亿条记录测试一下查询时间,再把结果×2作保守估计。
      

  15.   

    首先,如果你的大部分报表如果只要统计当月的数据,刚同意你按表分开放。然后每个月的数据放入数据仓库中进行抽取:)OLAP支持多表的聚合
      

  16.   

    数据仓库解决的是数据挖掘,共享,和大数据量存储有什么根本关系?
    mrzxc 等说的好,考虑你的系统,注意负载平衡,查询优化,25 万并不大,可以建一个表,然后按mrzxc 的3 4 5 7 优化。
      

  17.   

    对于统计类查询来说,数据仓库(olap)确实不错。如果确实放到一个表中,可以考虑索引、数据、日志分盘存放(通过文件和文件组)。
      

  18.   

    索引+分成小表
    ________________________________
    海关用MS SQL SERVER?够胆大,不如用DB2或ORACLE?
      

  19.   

    我有个思路
    用单表存所有记录 all_data_table
    1另外建立一个表this_month_table保存当月记录,在插入数据时
    用触发器 ,把记录同时插入到  all_data_table
    2对存在最近月份查询最多的几个月,可以建立 n个表,保存最近的n个月的记录
      

  20.   

    不要分开存。如果用oracle, 它有partition, 对开发没有影响,还可以考虑。用sql server, 不要这样做。五年不过是一两千万条纪录。我们的CRM数据库就有这么大。我当前项目的数据库最大的表也有八百万条纪录。普通查询速度没问题。关键看你的应用。如果仅是selectivity高的查询,如一个查询只返回几十条,几百条,几千条纪录(也就是说,你的系统是偏oltp的),那么只要索引建好了,速度不成问题。不要忘了,索引的查询时间是对数级的,数据量翻一倍,查询时间也差不了一秒。而如果你的系统是DSS的,如要支持对大量数据的扫描分析,生成报表,那么分表也不顶事。(你无论如何需要扫描这些表的)。
    此时就需要olap, data warehouse等技术。或者,如果需求简单,最土的,你可以run一些nightly job, 预先把数据扫描分析做了。
      

  21.   

    一年300万的记录表,作为单表还是不算大的,mrzxc(过客)说的没错,设计海量数据库需要靠的因素很多。我认为你需要考虑系统经常查询的列是那些,建立合适的索引会提高查询效率,另外建立索引的时候,注意列的选择性。表的列的取舍也可以做些文章,并不是符合范式的设计就是合理的。考虑一下,经常写入的那些列和那些经常读取单修改的概率小的列应该分开存放。另外SQL2000有索引视图,根据数据被访问频率的差异建立索引视图,比如,每个月的数据.
    数据仓库是复杂的解决方案,如果您的历史数据变更可能性小的话,可以考虑用数据仓库。
    但是前端应用程序的开发需要做工作,比如利用MDX等
      

  22.   

    ajoo(聪明的一猪)说的好,看看应用是什么模式的,没有放之四海皆准的方案,OLAP和OLTP系统数据库设计上会有很大的差别,有的时候是需要牺牲存储空间来获得查询效率,比如用冗余列,实际上数据库仓库就是规范的后者。
      

  23.   

    分开存放,而且不觉得写程序有什么麻烦的,关键问题在于你是否建立了合理的结构,我感觉,应该建立一个索引表,实际上查询就是先查索引表,然后查具体的表的过程,一点都不麻烦。按照时间段分开存放是一个好主意,也可以按照其他的字段值来存放。比如按照处理部门来存放,还可以按照多个字段值的不同来分开存放。数据库的查询速度不是一个问题,如果是一个数据库服务器,那么要叫你的网络管理员,把这个数据库服务器好好调整一下,一些没有用的功能就去掉,一些服务也要去掉,如果调整的好,我觉得Windows的性能和Linux是差不多的,问题是很多人调整不好。服务器要用好一点的,数据要放在专门的网络存储器上面,这样成本小一点,多个服务器堆叠可以使用同一个存储器,性价比比较高。放在服务器的硬盘里面不是一个好办法,速度快不了的。特别是在大量用户同时查询的时候,服务器会不堪重负的。
      

  24.   

    速度,影响它的因数太多了,且数据量越大越明显。
    1、存储
       将硬盘分成NTFS格式,NTFS比FAT32快,并看你的数据文件大小,1G以上你可以采用多数据库文件,这样可以将存取负载分散到多个物理硬盘或磁盘阵列上。2、tempdb
       tempdb也应该被单独的物理硬盘或磁盘阵列上,建议放在RAID 0上,这样它的性能最高,不要对它设置最大值让它自动增长3、日志文件
       日志文件也应该和数据文件分开在不同的理硬盘或磁盘阵列上,这样也可以提高硬盘I/O性能。4、分区视图
       就是将你的数据水平分割在集群服务器上,它适合大规模OLTP,SQL群集上,如果你数据库不是访问特别大不建议使用。5、簇索引
       你的表一定有个簇索引,在使用簇索引查询的时候,区块查询是最快的,如用between,应为他是物理连续的,你应该尽量减少对它的updaet,应为这可以使它物理不连续。6、非簇索引
       非簇索引与物理顺序无关,设计它时必须有高度的可选择性,可以提高查询速度,但对表update的时候这些非簇索引会影响速度,且占用空间大,如果你愿意用空间和修改时间换取速度可以考虑。7、索引视图
       如果在视图上建立索引,那视图的结果集就会被存储起来,对与特定的查询性能可以提高很多,但同样对update语句时它也会严重减低性能,一般用在数据相对稳定的数据仓库中。8、维护索引
       你在将索引建好后,定期维护是很重要的,用dbcc showcontig来观察页密度、扫描密度等等,及时用dbcc indexdefrag来整理表或视图的索引,在必要的时候用dbcc dbreindex来重建索引可以受到良好的效果。不论你是用几个表1、2、3点都可以提高一定的性能,5、6、8点你是必须做的,至于4、7点看你的需求,我个人是不建议的。打了半个多小时想是在写论文,希望对你有帮助。
      

  25.   

    可以分地区建库,多加几台服务器,利用sql server的分布式事务协调或者数据转换服务(声明,我没弄过啊)类似的机制实现数据库之间的数据查询,可否?