消除数据仓库的误区（一），

消除数据仓库的误区（一），

近两年，许多大型企业纷纷开始规划或者实施基于数据仓库技术的决策支持系统、客户关系管理系统、综合管理信息系统等各类应用分析平台。但在数据仓库项目的实施过程中，仍然存在不少对数据仓库概念的误解和应用的误区，希望本文能够帮助大家澄清部分焦点问题。

数据仓库是解决方案。

数据仓库的定义比较多，现在国内使用比较广泛的是被尊称为数据仓库之父的Bill Inmon所下的定义：“数据仓库是面向主题的、集成化的、稳定的、随时间变化的数据集合，用以支持管理决策的过程。”
最常见的误解是把数据仓库当成产品，我们常见的Oracle、DB2、Teradata、SQL Server等都只是数据库产品（Sybase除外，其数据库与数据仓库分别是两种不同的产品），需要配合相应的ETL工具、数据展现与挖掘工具、硬件平台等，通过专业技术服务的开发与集成才能整合成符合特定需求的数据仓库解决方案。
数据仓库和业务处理系统一样都是一种解决方案，两者都需要一个数据库来进行驱动，只是两种系统的工作特性和负载完全不同，使得它们对于所用数据库引擎的要求也不一样。在评估数据仓库平台时需要特别注意这一点。
从工程的角度来看，数据仓库是一个集成的解决方案，由多种产品和专业技术服务组成，提供了一种对数据进行存储与分析的技术手段。
从结构上来看，一个数据仓库系统一般可以分为数据采集、数据的存储与管理、数据展现三个层次，每个层次都牵涉到一定的软硬件产品。中间的数据存储与管理层是整个数据仓库解决方案的核心，系统是否具有线性、可扩展性能和并行处理性能，主要取决于中间层的平台。

目的是数据的综合分析

我们实施数据仓库的目的不是保存数据，而是对大量的历史数据进行综合的分析和处理，帮助进行决策支持。因此明确数据仓库的信息访问流程非常重要。
如图所示，业务人员登录到WEB服务器后，其分析请求被传递到数据存取工具服务器。对于预先定义的报表或者多维分析，将直接从OLAP服务器返回查询结果。对于动态的分析请求，则被转换成SQL并提交给中央数据库，经过处理后把查询结果返回到前台，以一定的方式进行展现。
现在国内许多数据仓库系统在使用时都局限于预先定义的多维分析和报表处理，限制了更能体现业务价值的动态分析和数据挖掘。国外一些先进企业的数据仓库系统在这方面就有很丰富的经验。他们十分注重对业务人员进行信息访问工具的培训，鼓励业务人员直接访问数据仓库，进行各种复杂分析和综合处理，以最大程度地挖掘业务价值。

“星形模式更适合数据仓库”说法过于片面

数据仓库中一个重要的环节就是建模，其中逻辑建模主要采用第三范式(Third Normal Form，简称3NF)和星形模式(Star Schema)两种方式。究竟哪一种方式更适合数据仓库呢？
模型规范化的过程是一种无损分解，可以从第一范式一直分解到第五范式。目前在数据仓库领域进行逻辑数据建模，大家的共识是规范到第三范式，因为更高阶的范式主要用来处理组合主键的问题，而在物理实施时还需要根据实际情况进行一定的不规范化(De-Normalize)处理。因此，用第三范式来描述数据仓库模型已经足够规范了。
星形模式的基本特点是由多个维表(Dimension Table)和事实表(Fact Table)组成。维表代表了相关的分析维度，事实表则是这些不同维度上的计算结果。星形模式存储了系统在不同维度上的预处理结果，因此进行多维分析时速度很快，但如果分析范围超出了预定义的维度，那么增加维度将是很困难的事情。
由于第三范式和星形模式的特点不同，简单地认为“星形模式更适合数据仓库”或者“第三范式更适合数据仓库”都显得过于片面。一般来说，通常使用第三范式来描述数据仓库系统后台的详细数据存储关系，在此基础上再根据特定的分析需求建立适当的星形模式，用于刷新OLAP服务器的立方体(Cube)，以方便前端数据查询和预定义的多维分析。