消除数据仓库的误区（二）

 能否同时支持星形模式与第三范式？

       笔者曾经看到一份某厂商提交给用户的报告，认为“Teradata只支持第三范式而不支持星形模式”。这就完全误解了逻辑数据模型与物理平台的关系。事实上，无论是星形模式还是第三范式，都是逻辑上的概念，与具体的物理平台并没有什么关系。
Teradata、UDB、Oracle、SQL Server等都是关系数据库产品，都能同时支持星形模式和第三范式。只是在物理实施时，由于各种数据库产品的特性、内部结构等方面的差异，当数据量很大时，一些数据库产品无法处理以规范方式（如第三范式）存储的海量数据，不得不采取星形模式或者其它不规范化方式（如小结表、预连接等）对数据进行预处理，以回答那些可以预知的业务问题。
      很多数据库产品都是基于联机交易处理系统（OLTP）设计的，其内部结构更适合于进行交易处理，并不适合于数据仓库中大量的复杂数据分析与综合处理。这些数据库用于数据仓库引擎时，往往中央存储采用第三范式建模，然后按照各种预知的需求建立大量的数据集市，前台业务用户只是访问这些数据集市，从而屏蔽了业务用户对后台详细数据的访问。

前端展现工具并不万能

       现在很多企业都在进行数据集中、统一平台与标准等工作，因此在选择数据仓库前端产品时，它们往往要问:能否选择一个统一的前端展现工具？哪些前端产品与哪些数据库产品的匹配性最好？
       不同的前端产品具有不同的市场定位和功能特点，虽然各种工具产品的功能与特点确实有许多交叉和重合，但基本上没有一种前端产品可以涵盖一个企业所有业务部门的需求。国外许多发展多年的数据仓库系统大多是根据不同类型用户的使用特点与需求而选用不同的前端工具。如果我们去考察一个数据仓库用户，往往会发现他们同时使用了SAS、BO、Brio、Cognos等多种工具。

磁盘容量不是越大越好

       磁盘容量越来越大，从早期的9GB、18GB，到现在的36GB、73GB、146GB，而且更高容量的磁盘还会不断出现。那么在配置数据仓库的存储系统时，是否磁盘容量越大越好？如果不是，应该如何进行选择？
数据仓库负载主要是SQL查询处理，需要扫描大量的数据，因此数据仓库系统对磁盘存储系统的I/O要求很高。而影响一个磁盘存储系统总体I/O带宽的主要因素是磁盘个数和磁盘转速。
       一般来说，随着磁盘数的增加，存储系统的I/O带宽也会相应增加。但磁盘数增加到一定程度，存储系统的I/O将趋于饱和。因此，存储系统的磁盘数并非越多越好。用户在进行选择时，要研究磁盘存储系统的I/O带宽与其磁盘数之间的关系图表，并注意存储系统的I/O能力在数据仓库负载不同时，会发生相应变化，一般情况下，可以认为数据仓库的典型负载为80%读、20%写。
       另一个影响存储系统I/O能力的主要因素是磁盘转速，转速越高，I/O越好。目前市面上的磁盘转速主要有7200转、10000转和15000转。我们在选择磁盘时，应该是转速越高越好，更准确地说，是平均到每单位存储容量上的带宽越高越好。

正确认识数据仓库的开放性

       现在很多人常常走入一个误区:把开放性理解成硬件平台能否支持多种操作系统或者数据库软件，数据库能否运行在多个操作系统或者硬件平台上。
       一个系统是否开放，我们主要考察它的可移植性、互操作性以及可扩展能力。从这几点要求来看，考察数据仓库系统的开放性与OLTP系统的开放性并没有什么区别。
       OLTP系统中的数据是自身在运行过程当中产生的，而数据仓库系统本身不产生数据，其数据需要从业务系统中获得。因此在考察数据仓库系统开放性时需要着重考察其对源数据的获取能力，Gartner Group把这种能力称之为适应性(Suitability)。
       另外，由于数据仓库系统与业务处理系统的应用完全不同，其数据模型也完全不一样，两个系统之间的ETL（数据抽取、转换与加载）是非常复杂的。因此我们在考察数据仓库系统的开放性时，需要着重考察其从业务系统获取数据的能力。

数据仓库难有统一的性能指标

        数据仓库系统中不同用户的信息访问特点不一样，一般用户的大部分需求可以从多维立方体、预定义报表中得到，这时，系统性能主要取决于网络传输速度、OLAP服务器的并发处理性能等因素。一般来说，这时的响应速度都在秒级。
对于数据仓库中的动态查询、数据挖掘等复杂分析，其性能主要取决于数据仓库引擎的并发处理能力和复杂SQL处理能力。但由于需求的不可预知性，很难定义明确的性能指标。
因此，我们在定义数据仓库系统性能指标时，应该根据不同用户的使用特点分别规划，然后再对资源进行合理的安排和调度，以满足大部分用户的性能要求。