目标及功能
数据仓库的基本特征为：面向主题的、集成的、稳定的、反应历史变化的、用于支持管理决策。数据仓库的基本功能有：（1）利用利用集成整合的操作性数据做出最明智的商业决策；（2）实现数据的多维分析；（3）分析和预测，数据挖掘实施，发现有价值的信息。
1企业范围内的信息共享。面向整个企业和最终用户，针对分析需要按照主题重组。形成一套全局的数据视图，并准确一致地保留历史。
2数据的多维度分析。能够进行快速访问，精确灵活分析，随心所欲的访问数据。直观、明显、简单、易用、切割、合并、下钻、上卷。
3内外部数据的有效集成，一致的展现数据（相对于原来从多个系统中出来的报表不一致）。适应性、扩展性、可维护性。使分散的、不一致的操作数据转换成集成的、统一的信息，最终为企业的各管理层提供决策的数据依据。
4 数据仓库是数据挖掘技术的关键和基础。利用数据挖掘技术在帮助用户理解现有信息，从当前和历史数据的分析中，获得简单的趋势分析，假设分析，预测分析等，对未来的企业状况做出完整、合理、准确的分析和预测。
1 规划分析
首先要确定数据仓库项目开发的目标。从用户角度分析，为用户提供哪些决策分析内容和功能。从技术角度分析，在确认划分的各个主题中需要哪些业务源数据，确定使用那种ETL工具去获取、清洗、转换、加载数据。使用什么样的工具来构建数据仓库的模型，确定数据仓库的实施范围。然后制定数据仓库项目目标和实施计划。
数据仓库的规划从分析操作型数据源开始，反映了企业业务处理的基本特征。研究和分析操作型数据源，是企业进行数据仓库设计的必要准备和先行步骤。分析源系统，并特别注意其对数据仓库有影响的数据项，对数据仓库的建设有这重要的意义。比如，源系统中的一些配置表可以作为数据仓库维表的原型；源系统中的一些报表也可以作为联机分析时的重要参照。源系统的很多对象在数据仓库设计时候都可以借鉴，但忌讳照搬，因为这样会对数据仓库的设计产生不良的影响。业界比较公认的一点是，数据仓库中存在的某些明显的继承性的缺点，往往是从源系统带过来的。
其次，对实施数据仓库项目开发的所有预算进行有效评估，编写详细的项目开发说明书，说明该数据仓库系统对企业发展的作用。内容包括：对工作概况的说明，重点支持该项目的业务部门和设计开发的工作计划等。EDW/BI的项目提供了由核心业务过程产生的关键绩效度量。业务边界的确定，需要将关注点聚焦在单独的业务过程。因为单独的业务过程常常是由单个主要的源系统模块支持的，所以集中关注单个业务过程有助于设计和开发迭代确定一个更易于处理的范围。较为合理的做法是仅从单个源系统中提取和转换数据，而不能一开始就试图从由多个源系统支持的多业务过程中提取和集成信息。
再次，开展概念模型设计工组，内容包括用户需求调研、模型的分析和需求定义等内容。先明确用户的需求，然后在理解用户需求的基础上，进行数据仓库概念模型的设计。包括撰写详细的用户需求分析调查表和针对概念模型的评审报告。
最后，在概念模型的基础上进行逻辑模型的分析和设计。所要分析的主题域有哪些，各个主题域中包含了哪些主题和实体，以及实体粒度层级的定义等。制定逻辑模型的评审报告和初步设计数据仓库ETL流程。
2 设计与实施
数据仓库项目的建设，最初可以围绕一个数据仓库核心项目进行设计，随着时间推移，逐步补充添加更多的项目，最后这个小的数据仓库就会增长为企业级数据仓库，掌控起公司所有的业务数据。最终，数据仓库需要支持整个或一大部分业务的需求，跨部门和业务线(line of business)具有较高的数据访问和使用率。在整个企业中，业务范围的数据仓库在物理上可以是集中式的，也可以是分布式的。数据仓库建设受如下因素的影响：当前IT基础设施、可用资源、所选架构、实现范围、对于跨部门进行的更大业务范围的数据访问的需求、投资回报率(return-on-investment)。
自顶向下的方法就是在单个项目阶段中实现数据仓库。自顶向下的实现需要在项目开始时完成更多计划和设计工作。这就需要涉及参与数据仓库实现的每个工作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据模型的相关决策一般需要在真正的实现开始之前就完成。
自底向上的实现包含数据仓库的计划和设计，无需等待安置好更大业务范围的数据仓库设计（这并不意味着不会开发更大业务范围的数据仓库设计）。随着初始数据仓库实现的扩展，将逐渐增加对它的构建。现在，该方法得到了比自顶向下方法更广泛的接受，因为数据仓库的直接结果可以实现，并可以用作扩展更大业务范围实现的证明。每种实现方法都有利弊。在许多情况下，最好的方法可能是某两种的组合。该方法的关键之一就是确定业务范围的架构需要用于支持集成的计划和设计的程度，因为数据仓库是用自底向上的方法进行构建。
在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时，可以一个接一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库。这样的方法可以极好地适用于业务。每个数据集市都可以处理可识别的业务问题或主题领域，从而可以计算ROI。
表1. 两种数据仓库设计方法优劣对比
2.1 数据仓库的主题
数据仓库是一个对企业和组织决策支持系统的集成办法，开发团队必须与用户沟通，密切关注客户需求，理解企业业务分析需求和企业运作的关键指标，在此基础上进行分析，并确定数据仓库的主题。数据仓库的设计中，在错综复杂的数据大集合面前，掌握住主题并不容易，如果使得主题落空，即使采用最好的技术也达不到预期的目的。
面向主题是指数据仓库中的数据是按照一定的主题域进行组织。主题是对业务数据的一种抽象，是在较高层次上对企业信息系统中的数据进行归纳、整理、综合、归类和分析利用的一个抽象概念。面向主题的数据组织和存储包含两个方面：根据源系统业务数据的特点进行主题数据的抽取和确定每个主题所包含的数据内容。一个主题通常与多个操作型信息系统相关，每一个主题基本对应一个宏观的分析领域，在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。分析主题是指用户使用数据仓库进行决策时所关心的重点方面，是对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。数据仓库在数据模型定义之前确定企业的主要主题域。例如典型的主题包括客户主题、产品主题、财务主题等。而客户主题包含：客户基本信息、客户信用信息、客户资产信息等。在构建数据仓库的时候，一般的方法是先确定几个基本而核心的主题，然后再将范围扩大，再逐步求精。
主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时，一般是一次先建立一个主题或企业全部主题中的一部分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。
确定主题边界实际上需要进一步理解业务关系，因此在确定整个分析主题后，还需要对这些主题进行初步的细化才便于获取每一个主题应该具有的边界。主题虽然在信息包图中只占据标题的位置，但是却是信息打包方法中最重要的部分，当主题定义好之后，数据仓库中的逻辑模型也就基本成形了。此时，需要在主题的逻辑关系模式中包含所有的属性及与系统相关的行为。数据仓库中的数据存储结构也需要在逻辑模型的设计阶段完成定义，需要向里面增加所需要的信息以及能充分代表主题的属性组。数据仓库的设计是一个螺旋发展的过程，在设计初始，没必要在数据仓库的数据库中体现所有的主题，选择最重要的主题作为数据仓库设计的试金石是很有必要的。
2.2 数据仓库逻辑层次
业务环境是在快速变化的，而业务数据的类型也是如此。一个成功的数据仓库解决方案的基础就是合理而兼容性高的架构以及灵活可而扩张的设计。这种架构和设计可以适应不断变化的业务数据。数据仓库的架构和仓库数据的建模设计是仓库设计中的核心任务。数据仓库的架构设计遵循商业智能体系的基本逻辑设计层次。通常，自下而上分为操作型数据层、数据缓冲过渡层、数据仓库层、数据集市层、数据应用分析层、数据可视化展示层。
操作型数据层，一般是ODS、操作型数据库。
数据缓冲过渡层，数据从ODS或者操作型数据库中被采集、清洗、转换加载至数据仓库的临时数据缓冲和过渡，增量加载机制在该层实现，判断数据的新增异动，控制数据的历史和版本。
数据仓库层，以原子层的粒度、按照主题的规划和数据存储。不面向特定应用，提炼多种应用的需求共性面向主题设计相对通用的实体对象，主数据高度集成，交易明细的数据轻度聚合，业务含义赋予维度分解为原始明细粒度的数据。降范式、预连接、适当冗余反三范式的设计。
数据集市层，集市层满足特定业务的需求，在基础数据层建设的基础上按应用需求粒度轻度汇总。数据集市的模型，主要是事实表和维度表的设计，最终为形式各异各自独立的星型模型。
数据应用分析层，是数据仓库辅助决策支持的最高层次，一般都是使用专业的商业智能工具来实现的。实施多维分析，方便用户从多主题、多角度计算汇总数据，增强了数据处理分析的灵活性和便捷性，通过对持续性数据的分析，提供数据对比分析（comparison）、趋势预测（trends）、假设分析（Assumption）、关系分析（ralationship）、核心KPI、信息及知识共享等。
数据可视化展示层，利用数据可视化工具：cognos、QlikView、Tableau等丰富的展现方式，实现数据展现的多维度要求。
图1 数据仓库逻辑层次示意图
2.3 数据仓库的模型
数据仓库模型设计是数据仓库建设过程中最为复杂的任务之一，设计人员不仅需要理解大量的业务需求，还需要熟悉企业已有操作型数据源系统的数据状况。正确的模型是用户需求的集中体现，是商业智能项目能否成功的重要因素之一。
目前国外比较成熟的数据仓库建模方法主要以bill Inmon(比尔·恩门)推崇的数据驱动 (data-driven)方法和Ralph Kimball（拉尔夫·金博尔）所提倡的业务驱动(demand-driven)建模方法为主。前者关注数据源系统数据，而忽视了企业最终用户的业务需求；后者仅强调满足各个业务部门的业务需求，从而导致数据仓库逻辑模型可能难以满足整个企业级的需要，并且，这种方法未考虑数据源问题，所以设计出的数据仓库可能会出现没有充分底层数据支持的情况。
概念模型是最高层次的数据模型，放映了数据仓库的主要主题和重要业务之间的关系。通常，在数据仓库实施之前，开发人员和业务人员对概念模型已经达成共识，因为概念模型反应的是核心的业务问题。概念模型的设计步骤如下：
从业务需求中提取重要的业务数据主题，并对业务主题数据作详细的解释，在业务数据主题基础上进行数据主题域的划分确定数据主题域的详细解释。
规划数据主题域概念模型，根据主题域的划分，细化内部的组织机构和业务关系。
表2 保险企业数据仓库核心数据主题域及解释
总之，概念模型建模的流程包含：对业务系统或者操作型数据系统（ODS）的详细说明，进行数据的梳理，列出数据主题详细的清单，并对数据主题做出尽可能完善的解释。然后经过归纳、分类、整理成各个数据主题域，列出每个主题域包含哪些部分，并对每个数据主题域做出详细解释，最后划分为主题域概念模型。
逻辑模型的设计是数据仓库实施中最重要的一步，因为它直接反映了业务部门的实际需求和业务规则，同时对物理模型的设计和实现具有指导作用。它的特点就是通过实体和实体之间的关系勾勒出整个企业的数据蓝图和规划。逻辑模型一般遵循第三范式，主要关注细节性的业务规则，同时需要解决每个主题域的包含哪些概念范畴和跨主题域的继承和共享的问题。在逻辑上建立数据模型的目的，是确定如何组建数据及数据之间的相互关系 ，以满足业务应用的需要。逻辑模型的构建需要以下几个步骤。
分析需求，列出需要分析的主题，需求目标、指标维度、维度层次、分析的指标、分析的方法、数据的来源、关注的对象等。
选择用户感兴趣的数据，通过业务需求将需要分析的指标分离抽取出来，转化成逻辑模型需要的实体。
在实体中需要增加时间戳属性，因为实体中需要保存各个阶段的历史数据。通常情况下，如果实体为统一编码则不需要时间戳属性。
需要考虑粒度层次的划分。数据仓库的粒度层次划分直接影响了数据仓库模型的设计，通常细粒度的数据模型直接从企业模型选择实体作为数据仓库逻辑模型的实体；而粗粒度的数据模型需要经过汇总计算得到相应的实体。粒度决定了数据仓库实现方式、性能、灵活性和数据仓库的数据量。
在粒度层次划分基础上，还需要进行关系模式的定义。关系模式一般采用第三范式的特点定义。对当前的主题进行关系模式的划分，形成各个实体、实体属性、实体之间的关系等内容。同时在逻辑模型框架的基础上对实体的中英文名称、属性、属性的值域进行明确、完善和细化，真实反映业务逻辑关系和业务规则。
数据仓库中广泛采用的模型设计有两种：关系型和多维型。普遍认为在数据仓库的设计方法中关系模型是“Inmon”方法，而多维模型是“Kimball”方法。关系型数据以一种称为“标准化”的形式存在。数据标准化是指模型设计会使数据分解成非常低的粒度级，标准化数据以一种孤立模式存在，这种情况下对数据表里的数据关系要求非常严格，一般遵循3NF范式。采用关系型设计的数据模型一般具有较强的灵活性和多功能性（可以支持数据的多种视图）。而多维模型一般有星型模式、雪花模式、混杂模式（又叫星系模式）。多维模型设计的最大优点在于访问的高效性。
关系模式，数据以最低粒度级和标准化形式存储；关系表间的关系已经定义好并且包含一个含有外键的关键字表；新表可以对关系表中的基本数据集定义新的汇总和筛选标准；也就是说可以很简单以一种形式创建关系表，再以另一种形式重新塑造这些表，这样做对于数据仓库环境来说是非常理想的。多维模型在直接访问数据方面是快速而高效的。从体系结构观点来看，在数据仓库设计基础方面关系模型是更好地支持数据仓库的模式，其原因是，数据仓库需要根据不同的议程和多种观察数据的方式来支持许多不同的用户组。也就是说，数据仓库对于访问已给定的用户并不是最佳的。相反，数据仓库可以以多种方式支持多个不同的用户。
数据仓库（EDW）的物理模型较常见的操作型数据库（ODS）的物理模型有很大不同。最明显的区别是：操作型数据库主要是用来支撑即时操作，对数据库的性能和数据质量要求都比较高，为了防止“garbage in，garbage out”，通常设计操作型数据库都要遵循几个范式的约束，除非少数情况下为了性能进行折衷，才可能出现冗余。数据仓库的建立并不是为了支撑即时操作，或者说，数据仓库的数据是来源于即时操作产生的数据，而不是直接来源于即时操作。所以它的数据质量是由操作性系统来保证的，而不是由几个范式来保证的。为了更好的跟踪历史信息，以及更快地产生报表，数据仓库的物理模型中存在着大量冗余字段。
2.4 数据仓库的集市
数据集市是为了满足特定的部门或者用户需求，按照多维的方式进行存储。包括定义维度、维度的层次、定义指标、指标的统计口径、指标多维度展现方式。以及生成面向决策分析需求的立方体。数据集市通常被定义为星型或者雪花模型，由事实表和维度表来组成。
事实表是与日俱增，而维度表则增长缓慢，所以绝对数字也不会太大。在事实表和维度表做连接查询的时候，会产生与事实表一样大的数据量，如果还需要group by等操作的话，导致结果就是：其一是会增加计算，其二是由于引入了计算，索引会失效。这个代价比引入冗余字段要大的多。总的说来，事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。
2.4.1 事实表设计
事实表是数据仓库星型结构中最重要的表，它直接放映了数据仓库应用的主题，包含了数据仓库中最基本、最主要的信息。一个事实表，通常包含了业务需求所关心的一系列指标值。一个事实表的行包括，具有可加性的数值型指标、与维表相连接的外键（通常具有两个或两个以上的外键），事实表的特征是，数据量庞大、内容相对狭窄、并且经常发生变化（新事件的发生、事实表中增加一条记录），适合各类指标值的聚集计算。数据仓库当中，事实表的建立是针对已经发生的事实的，是历史数据的存档，也就是说是不应该修改的（允许追加）。对于原始记录和新插入的记录，其他字段全部是相同的，也就是全部冗余的（为了追踪事实变化的历史）。主键都是冗余的，那么事实表一般是没有主键的。
事实表是由一个多方键（mutipartkey）标识的，该多方键是由来自同一业务过程中若干个相交维度表的外键所组成的。多方键意味着事实表通常描述的是多对多的关系。事实表的每一个外键都必须与维度表中的唯一主键相匹配（事实表的外键应当不为空，若为空则违背了参照完整性）。事实表仅有键和数值型度量值所组成，因此它具有健壮性和完整性的特点。
事实表的设计应从满足最终用户的要求和决策支持的基本需求出发，瞄准应用的主题，纵观和兼顾操作型数据源的结构和特性，以多维分析的模式满足数据仓库这种大数据容量、大吞吐量、高速相应的特有的环境。另一方面，事实表应该设计成简洁规范的形式，绝大多数数据项应该由数字键和数值组成，以便于累加和运算。并且数据项中避免冗长的描述性字符，事实表改进设计的关键也是将这些描述性的数据项目从事实表中剔除，并迁移到维度表中。
事实表的设计主要考虑的是选定与主题有关的度量，如销售量、销售额、成本、用户消费活动、产品服务情况等。在设计过程中要确定与维表链接的键。粒度的选择和确定主要取决于两方面的因素，一是操作性数据源中的粒度，二是用户最终进行联机分析所需要的明细程度（如钻入分析的细微程度、计算系统和数据库系统所能承受的数据量、总计报表的响应时间等）。一般来讲，星型结构中的维度变化对事实表的粒度有着非常重要的影响。比如，在一个有关销售的星型结构中引入一个新的维度（交易类型），可能会造成事实表的粒度向下一层。通常事实表中一般包含几个方面的内容：度量、维数标志符（作为外部键连接维表）、OLAP外键（链接其他事实表）、事实表属性描述、粒度（影响粒度的属性），图2为保险企业数据仓库基本理赔事实表的设计内容为例，阐述了事实表的主要组成部分。
图2 数据仓库基本理赔事实表设计
2.4.2 维度表设计
与事实表不同，维度表不具有健壮性和完整性，它们当中充满了“大而笨重”的描述性子段。维度表的属性一般有两个主要的用途：查询约束（过滤）和标记查询结果集。很多情况下，数据仓库的功能都与维度属性的质量及深度成正比例，健壮的维才能够产生健壮的查询和分析功能。维度表中的属性可以使用代码和缩写形式来定义，但最明智的做法是使用描述性字段。
维度表一般是有主键的。代表该类物质的一个单一个体，其他的属性一般都是表示层次关系的，在一个单独的维里面解析几个多对一的层次关系的情况比较常见。例如电商网站中的产品可以上卷（roll up）到品牌，而品牌可以上卷到类别，就可以用一个单独的产品维度来表示该层次关系，维度表存储了与品牌和类别描述相对应的属性。这样设计会在每个产品行中都产生有关品牌和类别的冗余存储。尽管可以将品牌和类别解码存储在单独的维度表中，但这样做仍然会干扰可理解性和查询性能。
维度表在汇总、插入分析、和扩展分析处理中很有用，维表能够说明事实表。维度表的设计可以借鉴源系统的结构作为雏形，但要深入全面的分析，进行必要的裁剪和提炼，不要照搬。维度表设计有以下几点建议：1) 建立维表主键，有时需要加入源系统的键进行比较；2)为反应历史变化，应加入时标以标识某些唯维在某个时期的有效性；3)处理缓慢变化的维，确定何种变化需要插入新的纪录，何种变化只需要更改源纪录，以产品维数为例，如果产品的型号规格变了，一般应插入新的纪录，以保障历史数据的正确性。（真实性）4)建立唯的版本号以适应历史变化，如对产品维来讲，针对型号的变动应该生成新的版本号。5)尽可能在整个行业中使用共享的维，或者对维进行合并、整合、使得它能够被整个企业/行业共享。
2.4.3 星型VS雪花型
星型模式和雪花模型的多维数据建模均以直观的方式组织数据，并支持高性能的数据访问。多维模型最常见的是星形模式。在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。星型模式位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。指标实体代表一系列相关事实，完成指定的功能。维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。星形模式虽然是一个关系模型，但是它不是一个规范化的模型。在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中的关系模式的基本区别。使用星形模式主要有两方面的原因:提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。
雪花模式在实际应用中，随着事实表和维表的增加和变化，星形模式会产生多种衍生模式，包括星系模式、星座模式、二级维表和雪花模式。雪花模式是对星形模式维表的进一步层次化，将某些维表扩展成事实表，这样既可以应付不同级别用户的查询，又可以将源数据通过层次间的联系向上综合，最大限度地减少数据存储量，因而提高了查询功能。雪花模式的维度表是基于范式理论的，因此是界于第三范式和星形模式之间的一种设计模式，通常是部分数据组织采用第三范式的规范结构，部分数据组织采用星形模式的事实表和维表结构。在某些情况下，雪花模式的形成是由于星形模式在组织数据时，为减少维表层次和处理多对多关系而对数据表进行规范化处理后形成的。雪花模式的优点是:在一定程度上减少了存储空间;规范化的结构更容易更新和维护。同样雪花模式也存在不少缺点:雪花模式比较复杂，用户不容易理解;浏览内容相对困难;额外的连接将使查询性能下降。在数据仓库中，通常不推荐“雪花化”。因为在数据仓库中，查询性能相对OLTP系统来说更加被重视，而雪花模式会降低数据仓库系统的性能。图3为数据仓库雪花模型示意。
图3数据仓库雪花模型示意
实际应用中，可以采取上述两种模型的混合体：如：中间层使用雪花结构以降低数据冗余度，数据集市部分采用星型以方便数据提取及和分析。有时候规范化和效率是一组矛盾。一般我们会采取牺牲空间（规范化）来换取好的性能，把尽可能多的维度信息存在一张“大表”里面是最快的。通常会视情况而定，采取折中的策略。
3 数据仓库的ETL过程
通常数据仓库中数据量较大，需要采取成熟的ETL工具进行抽取、转换和加载操作，以减低设计、开发和维护的复杂度，使得开发人员有更多的时间专注于业务转化规则的实现。ETL工作是数据仓库项目中耗时最长并且比较艰难的工作，ETL系统设计和开发对商业智能项目的成败产生至关重要的影响。所以，数据仓库中的ETL过程是构建数据仓库的重要一环节。用户从数据源（或者ODS系统）抽取出所需数据，经过数据清洗、转换等最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。转换操作，是按照预先设计好的规则，将抽取获得的数据进行清洗以及处理一些冗余、重复、或者有歧义的部分，最终使得本来异构的数据能够统一起来。转换操作归纳起来有以下内容。
表2 数据仓库ETL过程的主要操作
从另一个方面讲，数据仓库具有4或5层的逻辑设计，从操作型数据层、数据仓库层、数据集市层、数据应用分析层、数据可视化展示层。数据在持续的流转、被聚合、被汇总沿着特定的分析线条和分析主题。数据在数据仓库的加工、汇总和分析，也衍生了大量的ETL数据处理工作。图4为数据仓库中数据聚合汇总逻辑示意。
图4 仓库数据聚合汇总分析逻辑示意
4 数据仓库实施总结
企业数据仓库应用的成功之路并非一蹴而就。数据仓库应用的重点有两点，一个是应用层问题，一个是技术层问题。应用层问题。数据仓库应用是为了提供企业级的管理和决策信息，它的需求分析本身是一个探索的过程，要建造一个成功的数据仓库系统，必须要整理出完善的需求。因为，数据仓库应用系统是一个周而复始、生生不息的循环过程。技术层问题。这又分为数据模型、ETL、前端应用和系统管理几方面。数据模型是个大问题，数据仓库模型应该怎样构造，尤其是针对具体的行业，上升到业务模型的高度，更是众说纷纭。国外的厂商几乎都提供了自己的模型，按照自己的数据仓库实施方法来诠释。具体到中国的企业，直接拿过来用的还没有先例。企业要想真正走向数据仓库应用成功之路，只有也必须从国外的模型框框中突破出来，制定、裁剪、勇敢改造或者设计出符合中国企业特点的数据仓库模型。成功的数据仓库模型能够应付数据源以及业务逻辑的变化，能够弥补上面提到的系统的灵活性和稳定性的问题。数据仓库系统的管理目前是限制应用走向成熟的瓶颈，管理系统的目标是使数据循环体的各个环节都能达到可配置的状态，可以最大限度的提高系统的灵活性和稳定性。也可以将管理系统作为评价数据仓库应用是否成熟的重要标志。
