我这个问题已经花费一周的时间了,因为国内用MSSQL数据仓库的相对少,所以这问题一直没有得到解答。
在MICROSOFT的官方论坛上找到解决办法,但是我把补丁装上去以后,还是没有解决。我想是不是我环境的问题,如果哪个朋友自己机器上装有MSSQL2005或是2008的话,不管有没有用过数据仓库都请跟我联系一下。
这是一个学习的过程。补丁只有8M的大小,很快就会完成的。
谢谢了

解决方案 »

  1.   

    这问题已经在CSDN上问了一周了,已经不想再发什么信息了,如果有热心的朋友,请直接和我在线聊天。
      

  2.   

    .1 数据的抽取  数据的抽取是数据进入仓库的入口。由于数据仓库是一个独立的数据环境,它需要通过抽取过程将数据从联机事务处理系统、外部数据源、脱机的数据存储介质中导入到数据仓库。数据抽取在技术上主要涉及互连、复制、增量、转换、调度和监控等几个方面。数据仓库的数据并不要求与联机事务处理系统保持实时的同步,因此数据抽取可以定时进行,但多个抽取操作执行的时间、相互的顺序、成败对数据仓库中信息的有效性则至关重要。  在技术发展上,数据抽取所涉及的单个技术环节都已相对成熟,其中有一些是躲不开编程的,但整体的集成度还很不够。目前市场上所提供的大多是数据抽取工具。这些工具通过用户选定源数据和目标数据的对应关系,会自动生成数据抽取的代码。但数据抽取工具支持的数据种类是有限的;同时数据抽取过程涉及数据的转换,它是一个与实际应用密切相关的部分,其复杂性使得不可嵌入用户编程的抽取工具往往不能满足要求。因此,实际的数据仓库实施过程中往往不一定使用抽取工具。整个抽取过程能否因工具的使用而纳入有效的管理、调度和维护则更为重要。从市场发展来看,以数据抽取、异构互连产品为主项的数据仓库厂商一般都很有可能被其它拥有数据库产品的公司吞并。在数据仓库的世界里,它们只能成为辅助的角色。  3.2 数据的存储和管理  数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库的特性,同时也决定了其对外部数据表现形式。要决定采用什么产品和技术来建立数据仓库核心,则需要从数据仓库的技术特点着手分析。  数据仓库遇到的第一个问题是对大量数据的存储和管理。这里所涉及的数据量比传统事务处理大得多,且随时间的推移而累积。从现有技术和产品来看,只有关系数据库系统能够担当此任。关系数据库经过近30年的发展,在数据存储和管理方面已经非常成熟,非其它数据管理系统可比。目前不少关系数据库系统已支持数据分割技术,能够将一个大的数据库表分散在多个物理存储设备中,进一步增强了系统管理大数据量的扩展能力。采用关系数据库管理数百个GB甚至到TB的数据已是一件平常的事情。一些厂商还专门考虑大数据量的系统备份问题,好在数据仓库对联机备份的要求并不高。  数据仓库要解决的第二个问题是并行处理。在传统联机事务处理应用中,用户访问系统的特点是短小而密集;对于一个多处理机系统来说,能够将用户的请求进行均衡分担是关键,这便是并发操作。而在数据仓库系统中,用户访问系统的特点是庞大而稀疏,每一个查询和统计都很复杂,但访问的频率并不是很高。此时系统需要有能力将所有的处理机调动起来为这一个复杂的查询请求服务,将该请求并行处理。因此,并行处理技术在数据仓库中比以往更加重要。  大家可以注意以下,在针对数据仓库的TPC-D基准测试中,比以往增加了一个单用户环境的测试,成为"系统功力"(QPPD)。系统的并行处理能力对QPPD的值有重要影响。目前,关系数据库系统在并行处理方面已能做到对查询语句的分解并行、基于数据分割的并行、以及支持跨平台多处理机的群集环境和MPP环境,能够支持多达上百个处理机的硬件系统并保持性能的扩展能力。数据仓库的第三个问题是针对决策支持查询的优化。这个问题主要针对关系数据库而言,因为其它数据管理环境连基本的通用查询能力都还不完善。在技术上,针对决策支持的优化涉及数据库系统的索引机制、查询优化器、连接策略、数据排序和采样等诸多部分。普通关系数据库采用B树类的索引,对于性别、年龄、地区等具有大量重复值的字段几乎没有效果。而扩充的关系数据库则引入了位图索引的机制,以二进制位表示字段的状态,将查询过程变为筛选过程,单个计算机的基本操作便可筛选多条记录。由于数据仓库中各数据表的数据量往往极不均匀,普通查询优化器所得出得最佳查询路径可能不是最优的。因此,面向决策支持的关系数据库在查询优化器上也作了改进,同时根据索引的使用特性增加了多重索引扫描的能力。  以关系数据库建立的数据仓库在应用时会遇到大量的表间连接操作,而连接操作对于关系数据库来说是一件耗时的操作。扩充的关系数据库中对连接操作可以做预先的定义,我们称之为连接索引,使得数据库在执行查询时可直接获取数据而不必实施具体的连接操作。数据仓库的查询常常只需要数据库中的部分记录,如最大的前50家客户,等等。普通关系数据库没有提供这样的查询能力,只好将整个表的记录进行排序,从而耗费了大量的时间。决策支持的关系数据库在此做了改进,提供了这一功能。此外,数据仓库的查询并不需要像事务处理系统那样精确,但在大容量数据环境中需要有足够短的系统响应时间。因此,一些数据库系统增加了采样数据的查询能力,在精确度允许的范围内,大幅度提高系统查询效率。  总之,将普通关系数据库改造成适合担当数据仓库的服务器有许多工作可以做,它已成为关系数据库技术的一个重要研究课题和发展方向。可见,对于决策支持的扩充是传统关系数据库进入数据仓库市场的重要技术措施。  数据仓库的第四个问题是支持多维分析的查询模式,这也是关系数据库在数据仓库领域遇到的最严峻的挑战之一。用户在使用数据仓库时的访问方式与传统的关系数据库有很大的不同。对于数据仓库的访问往往不是简单的表和记录的查询,而是基于用户业务的分析模式,即联机分析。如图1.3所示,它的特点是将数据想象成多维的立方体,用户的查询便相当于在其中的部分维(棱)上施加条件,对立方体进行切片、分割,得到的结果则是数值的矩阵或向量,并将其制成图表或输入数理统计的算法。
    图 1.3 联机分析数据处理示意图 
    关系数据库本身没有提供这种多维分析的查询功能,而且在数据仓库发展的早期,人们发现采用关系数据库去实现这种多维查询模式非常低效、查询处理的过程也难以自动化。为此,人们提出了多维数据库的概念。多维数据库是一种以多维数据存储形式来组织数据的数据管理系统,它不是关系型数据库,在使用时需要将数据从关系数据库中转载到多维数据库中方可访问。采用多维数据库实现的联机分析应用我们称之为MOLAP。多维数据库在针对小型的多维分析应用有较好的效果,但它缺少关系数据库所拥有的并行处理及大规模数据管理扩展性,因此难以承担大型数据仓库应用。这样的状态直?quot;星型模式"在关系数据库设计中得到广泛的应用才彻底改变。几年前,数据仓库专家们发现,关系数据库若采用"星型模式"来组织数据就能很好地解决多维分析的问题。"星型模式"只不过是数据库设计中数据表之间的一种关联形式,它的巧妙之处在于能够找到一个固定的算法,将用户的多维查询请求转换成针对该数据模式的标准SQL语句,而且该语句是最优化的。"星型模式"的应用为关系数据库在数据仓库领域打开绿灯。采用关系数据库实现的联机分析应用称为ROLAP。目前,大多数厂商提供的数据仓库解决方案都采用ROLAP。  在数据仓库的数据存储管理领域,从当今的技术发展来看,面向决策支持扩充的并行关系数据库将是数据仓库的核心。在市场上,数据库厂商将成为数据仓库的中坚力量。   3.3 数据的表现  数据表现是数据仓库的门面。这是一个工具厂商的天下。它们主要集中在多维分析、数理统计和数据挖掘方面。  多维分析是数据仓库的重要表现形式,由于MOLAP系统是专用的,因此,关于多维分析领域的工具和产品大多是ROLAP工具。这些产品近两年来更加注重提供基于Web的前端联机分析界面,而不仅仅是网上数据的发布。  数理统计原本与数据仓库没有直接的联系,但在实际的应用中,客户需要通过对数据的统计来验证他们对某些事物的假设,以进行决策。与数理统计相似,数据挖掘与数据仓库也没有直接的联系。而且这个概念在现实中有些含混。数据挖掘强调的不仅仅是验证人们对数据特性的假设,而且它更要主动地寻找并发现蕴藏在数据之中的规律。这听起来虽然很吸引人,但在实现上却有很大的出入。市场上许多数据挖掘工具其实不过是数理统计的应用。它们并不是真正寻找出数据的规律,而是验证尽可能多的假设,其中包括许多毫无意义的组合,最后由人来判断其合理性。因此,在当前的数据仓库应用中,有效地利用数理统计就已经能够获得可观的效益。   3.4 数据仓库设计的技术咨询  在数据仓库的实施过程中,有一些更为基本的问题需要解答。它们包括:数据仓库提供哪些部门使用?不同的部门怎样发挥数据仓库的决策效益?数据仓库需要存放哪些数据?这些数据以什么样的结构存放?数据从哪里装载?装载的频率多少为合适?需要购置哪些数据管理的产品和工具来建立数据仓库?等等。这些问题依赖于特定的数据仓库系统,属于技术咨询的范畴。  事实上,数据仓库决不是简单的产品堆砌,它是综合性的解决方案和系统工程。在数据仓库的实施过程中,技术咨询服务至关重要,是一个不可缺少的部分,它甚至于比购买产品更为重要。目前,数据仓库的技术咨询主要来自数据仓库软件产品的供应商和独立的针对数据仓库技术的咨询公司。
    3.5 数据仓库技术九十年代来的进展  90年代以来,计算机技术,尤其是数据库技术的发展为DSS提供了技术支持;激烈的市场竞争促进了高层次决策人员对DSS的实际需求。两方面的共同作用,促成了以DW为核心、以O-LAP和DM工具为手段建设DSS的可行方案。数据库技术的发展 DW需要以下数据库技术的支持。  (1)高性能数据库服务器 DW的应用不同于传统DB的OLTP应用。传统DB的应用是操作型的,而DW的应用是分析型的,它需要高性能的DBMS核心的支持,以使较快地获得分析结果,这通常需数秒至数分钟。虽然比OLTP的响应时间长一些,但由于分析型应用涉及的数据量大,查询要求复杂,因此,对DBMS核心的性能要求更高,同DBMS必须具有良好的查询优化机制。  (2)并行数据库技术 DW中的数据量大,而且随着时间的延长,新的数据还会不断进入。DW中的数据库通常是GB甚至TB级的,可谓是超大规模数据库(VLDB)。而并行数据库技术是存储和管理VLDB,并提供对VLDB复杂查询处理的有效技术。   (3)数据库互操作技术 DW中的数据大多来自企业或行业中业已运行的OLTP数据库或外部的数据源。这些数据库常常是异构的,甚至是文件系统中的数据。DW必须从这些异构数据源中定期抽取、转换和集成所需要的数据,并把它们存入DW中。因此,异构数据源之间的互访和互操作技术是必需的。