大数据、云计算、数据中台……，这些概念伴随着互联网、智能制造、人工智能等技术的突破发展，已经成为支撑这些新领域的核心。就数据建模与管理而言，这是一个比较成熟、发展比较久的研究领域，其中有不少成熟的框架、模型、算法。但从数据管理的基本要素看，无论是大数据、云计算，还是工业互联网应用等，要实现数据的综合利用，需要对数据进行集中的存储、处理及应用，这其中数据仓库是一个关键。同样，对于现在的企业信息化建设而言，即便不考虑“云计算、大数据“等新技术的应用，如何利用已有的数据资源，实现数据资产化，对企业的经验业务进行综合支撑，也需要重新考虑数据仓库等技术的重新应用。因此，虽然数据仓库不是一个新概念，但在新的应用场景下，如何创新性地构建、应用，是一个值得探讨的话题。
从理论上看，数据仓库具有面向主题的、集成的、不可更新的、随时间不断变化的特性。
这些特点说明了数据仓库从数据组织到数据处理，都与原来的数据库有很大的区别，这也就需要在数据仓库系统设计时寻求一个适合于数据仓库设计的方法。在一般的系统开发规划中，首先需要确定系统的功能，这些系统的功能一般是通过对用户的需求分析得到的。从数据仓库的应用角度来看，数据仓库分析员一般是企业中的中高层管理人员，他们对决策支持的需求不能预先做出规范的说明，只能给设计人员一个抽象地描述。这就需要设计人员在与用户不断的交流沟通中，将系统的需求逐步明确，并加以完善。因此数据仓库的开发规划过程实际上是一个用户和设计人员对其不断了解、熟悉和完善的过程。
数据仓库的开发应用规划是开发数据仓库的首要任务。只有制定了正确的数据仓库规划，才能使组织主要力量有序地实现数据仓库的开发应用。在数据仓库规划中一般需要经历这样几个过程：
选择实现策略；
确定数据仓库的开发目标和实现范围；
选择数据仓库体系结构；
建立商业和项目规划预算。
数据仓库的开发策略主要有自顶向下、自底向上和这两种策略的联合使用。自顶向下策略在实际应用中比较困难，因为数据仓库的功能是一种决策支持功能。这种功能在企业战略的应用范围中常常是很难确定的，因为数据仓库的应用机会往往超出企业当前的实际业务范围，而且在开发前就确定目标，会在实现预定目标后就不再追求新的应用，是数据仓库丧失更有战略意义的应用。由于该策略在开发前就可以给出数据仓库的实现范围，能够清楚地向决策者和企业描述系统的收益情况和实现目标，因此是一种有效的数据仓库开发策略。该方法使用时需要开发人员具有丰富的自顶向下开发系统的经验，企业决策层和管理人员完全知道数据仓库的预定目标并且了解数据仓库能够在哪些决策中发挥作用。
自底向上策略一般从某个数据仓库原型开始，选择一些特定的为企业管理人员所熟知的管理问题作为数据仓库开发的对象，在此基础上进行数据仓库的开发。
因此，该策略常常用于一个数据集市、一个管理系统或一个部门的数据仓库开发。该策略的优点在于企业能够以较小的投入，获得较高的数据仓库应用收益。在开发过程中，人员投入较少，也容易获得成效。当然，如果某个项目的开发失败可能造成企业整个数据仓库系统开发的延迟。
该策略一般用于企业希望对数据仓库的技术进行评价，以确定该技术的应用方式、地点和时间，或希望了解实现和运行数据仓库所需要的各种费用，或在数据仓库的应用目标及数据仓库对决策过程影响不是很明确时使用。
在自顶向下的开发策略中可以采用结构化或面向对象的方法，按照数据仓库的规划、需求确定、系统分析、系统设计、系统集成、系统测试和系统试运行的阶段完成数据仓库的开发。
而在自底向上的开发中，则可以采用螺旋式的原型开发方法，使用户可以根据新的需求对试运行的系统进行修改。螺旋式的原型开发方法要求在较短的时间内快速的生成可以不断增加功能的数据仓库系统，这种开发方法主要适合于这样一些场合：在企业的市场动向和需求无法预测，市场的时机是实现产品的重要组成部分，不断地改进对与企业的市场调节是必需的；持久的竞争优势来自连续不断地改进，系统地改进是基于用户在使用中的不断发现。
自顶向下和自底向上策略的联合使用具有两种策略的优点，既能快速的完成数据仓库的开发与应用，还可建立具有长远价值的数据仓库方案。
但在实践中往往难以操作，通常需要能够建立、应用和维护企业模型、数据模型和技术结构的、具有丰富经验的开发人员，能够熟练的从具体（如业务系统中的元数据）转移到抽象（只基于业务性质而不是基于实现系统技术的逻辑模型）；企业需要拥有由最终用户和信息系统人员组成的有经验的开发小组，能够清楚地指出数据仓库在企业战略决策支持中的应用。
为确定数据仓库的开发目标和实现范围，首先需要对企业管理者等数据仓库用户解释数据仓库在企业管理中的应用和发展趋势，说明企业组织和使用数据来支持跨功能系统的重要性，对企业经营战略的支持，以确定开发目标。在该阶段确认与使用数据仓库有关的业务要求，这些要求应该只支持最主要的业务职能部门，将使用精力集中在收益明显的业务上，使数据仓库的应用立即产生效果，不应该消耗太多的精力在各个业务上同时铺开数据仓库的应用。在确定开发目标和范围以后，应该编制需求文档，作为今后开发数据仓库的依据。
数据仓库开发的首要目标是确定所需要信息的范围，确定用户提供决策帮助时，在主题和指标域需要哪些数据源。这就需要定义：
用户需要什么数据？
面向主题的数据仓库需要什么样的支持数据？
为成功地向用户提交数据，开发人员需要哪些商业知识？哪些背景知识？
这就需要定义整体需求，以文件的形式整理现存的记录系统和系统环境，对使用数据仓库中数据的候选应用系统进行标识、排序，构造一个传递模型，确定尺度、事实及时间标记算法，以便从系统中抽取信息且将他们放入数据仓库。
通过信息范围确定可为开发人员提供一个良好的分析平台，和用户一起分析哪些信息是数据仓库需要的，进行商业活动需要什么数据。
开发人员可以和用户进一步定义需要，例如数据分级层次、聚合的层次、加载的频率以及需要保持的时间表等。
数据仓库开发的另一个重要目标是确定利用哪些方法和工具访问和导航数据。
虽然用户都需要存取并且检索数据仓库的内容，但是所存取的粒度有所不同，有的可能是详细的记录，有的可能是比较概括的记录或十分概括的记录。用户要求的数据概括程度不同，将导致数据仓库的聚集和概括工具的需求不同。数据仓库还有具有一定功能来访问和检索图表、预定义的报表、多维数据、概括性数据和详细记录。用户从数据仓库中获得信息，应该有电子表格、统计分析器和支持多维分析的分析处理器等工具的支持，以解释和分析数据仓库中的内容，产生并且验证不同的市场假设、建议和决策方案。
为将决策建议和各种决策方案向用户清楚地表达出来，需要利用报表、图表和图像等强有力的信息表达工具。
数据仓库开发的其他目标，是确定数据仓库内部数据的规模。在数据仓库中不仅包含当前数据，而且包含多年的历史数据。数据的概括程度决定了这些数据压缩和概括的最大限度。如果要让数据仓库提供对历史记录进行决策查询的功能，就必须支持对大量数据的管理。数据的规模不仅直接影响决策查询的时间，而且还将直接影响企业决策的质量。
在数据仓库的开发目标中，还有：
根据用户对数据仓库的基本需求，确定数据仓库中数据的含义；
确定数据仓库内容的质量，以确定使用、分析和建议的可信级别；
哪种类型的数据仓库可以满足最终用户的需求，这些数据仓库应该具有怎样的功能；
需要哪些元数据，如何使用数据源中的数据；
等等。
数据仓库的开发目标多种多样，十分复杂，需要开发人员和用户在开发与使用的过程中不断交互完善。因此，在规划中需要确定数据仓库的开发范围。使开发人员能够根据需求和目标的重要性逐步进行，并且在开发中吸取经验教训，为数据仓库在企业中的全部实现提供技术准备。因此，在为数据仓库确定总体开发方向和目标以后，就必须确定一个有限的能够很快体现数据仓库效益的使用范围。在考虑数据仓库的应用范围时，主要从使用部门的数量和类型、数据源的数量、企业模型的子集、预算分配以及开发项目所需的时间等角度分析。在分析这些因素时，可从用户的角度和技术的角度两方面进行：
哪些部门最先使用数据仓库？
哪些人员为了什么目的使用数据仓库？
数据仓库首先要满足哪些决策查询？
因为这些决策查询往往确定了关于数据维数、报表的种类，这些因素都将确定数据仓库定义时所需要的数量关系。查询的格式越具体，越容易提供数据仓库的维数、聚集和概括的规划说明。
从技术角度分析，应该确定数据仓库中元数据库的规模，
数据仓库的元数据库是存储数据仓库中数据定义的模型。数据定义存储在仓库管理器的目录中，可以作为所有查询和报表工具构造和查询数据仓库的依据。元数据库的规模直接表示了数据仓库中必须管理的数据规模。通过对元数据库规模的管理，实际上就确定了数据仓库中所需要管理的数据规模。
数据仓库的结构可以进行灵活的选择，可将组织所使用的各种平台进行恰当的分割，把数据源、数据仓库和最终用户使用的工作站分割开来进行恰当的设计。
（1）数据仓库的应用结构
在这种结构中，将运作的数据用于无需修改数据的只读应用程序中。具有这种结构的数据仓库元数据库是一种虚库，而不是数据仓库自身的元数据。在数据仓库元数据库的直接指导下，对数据仓库的查询就是简单的从数据库中抽取数据。
利用在数据仓库中的数据源净化、集成、概括和集成等操作，将数据源从业务处理系统中传输进集中的数据仓库，各部门的数据仓库应用只在数据仓库中进行。这种结构经常发生在多部门、少用户使用数据仓库的情况下。这里的集中仅仅是逻辑上的，物理上可能是分散的。
数据集市是指在部门中使用的数据仓库，因为企业中的各个职能部门都有自己的特殊需要，而统一的数据仓库可能不能满足这些部门的特殊要求。这种体系结构经常发生在个别部门对数据仓库的应用感兴趣，而组织中其他部门却对数据仓库的应用十分冷漠之时，由热心的部门单独开发式所采用。
企业各部门拥有满足自己需要的数据集市，其数据从企业数据仓库中获取，而数据仓库从企业各种数据源中收集和分配。这种体系结构是一种较为完善的数据仓库体系结构，往往发生在组织整体对数据仓库应用感兴趣之时所采用的体系结构。
（2）数据仓库的技术平台结构
单层结构主要是在数据源和数据仓库之间共享平台，或者让数据源、数据仓库、数据集市与最终用户工作站使用同一个平台。共享一个平台可以降低数据抽取和数据转换的复杂性，但是共享平台在应用中可能遇到性能和管理方面的问题，这种体系结构一般在数据仓库规模较小，而组织的业务系统平台具有较大潜力之时所采用。
一层为客户机，一层为服务器，最终用户访问工具在客户层上运行，而数据源、数据仓库和数据集市位于服务器上，该技术结构一般用于普通规模的数据仓库。
基于工作站的客户层、基于服务器的中间层和基于主机的第三层。主机层负责管理数据源和可选的源数据转换；服务器运行数据仓库和数据集市软件，并且存储仓库的数据；客户工作站运行查询和报表运用程序，且还可以存储从数据集市或数据仓库卸载的局部数据。在数据仓库稍具规模，两层数据仓库结构已经不能满足客户的需求，要将数据仓库的数据存储管理、数据仓库的应用处理和客户端应用分开之时，可以采用这种结构。
这是在三层结构基础上发展起来的数据仓库结构，在该结构中从最内数据层到最外层的客户层依次是：单独的数据仓库存储层、对数据仓库和数据集市进行管理的数据仓库服务层、进行数据仓库查询处理的查询服务层、完成数据仓库应用处理的应用服务层和面向最终用户的客户层。体系层次可能多达五层，这种体系结构一般用于超规模数据仓库系统。
数据仓库的实际使用方案与开发预算，是数据仓库规划中最后需要确定的问题。
因为数据仓库主要用于对企业管理人员的决策支持，确保其实用性是十分重要的，因此需要让最终用户参与数据仓库的功能设计。这种参与是通过用户的实际使用方案进行的，使用方案是一个非常重要的需求模型。实际使用方案必须有助于阐明最终用户对数据仓库的要求，这些要求有的只使用适当的数据源就可以得到基本满足，而有的却需要来自企业外部的数据源，这就需要通过使用方案将这些不同的要求联系起来。
实际使用方案还可以将最终用户的决策支持要求与数据仓库的技术要求联系起来。
因为当用户确定最终要求后，为元数据库的范围确定一个界限。还可以确定所需要的历史信息的数量，当根据特定的用户进行数据仓库的规划时，就可确定最终用户所关心的维度（时间、方位、商业单位和生产企业），因为维度与所需要的概括操作有明显的关系，必须选择对最终用户有实际意义的维度，如：“月”、“季度”、“年”等。最后，还可以确定数据集市/数据仓库的结构需要，使设计人员确定采用单纯数据仓库结构，还是单纯的数据集市结构或者是两者相结合的结构。
在实际使用开发方案确定后，还需要对开发方案的预算进行估计，确定项目的投资数额。
投资方案的确定可以依据以往的软件开发成本，但是这种预算的评估比较粗糙。另一种方法是参照结构进行成本评估，也就是说，将数据仓库实际使用方案所确定的构件进行分解，根据各个构件的成本进行预算估算。数据仓库的构件包含在数据源、数据仓库、数据集市、最终用户存取、数据管理、元数据管理、传输基础等部分中，这些构件有的在企业原有信息系统中已经具备，有的可以选择商品化构件，有的则需要自我开发。根据这些构件的不同来源，可以确定比较准确的预算。
完成数据仓库规划后，就需要编制数据仓库开发说明书，说明系统与企业战略目标的关系，以及系统与企业急需处理的范围相对有限的开发机会，所设想的业务机会的说明以及目标任务概况说明、重点支持的职能部门和今后工作的建议。
数据仓库项目应有明确的业务价值计划开始，在计划中需要阐明期望取得的有形和无形的利益。无形利益包含利用数据仓库使决策完成得更快更好等利益。业务价值计划最好由目标业务主管来完成，因为数据仓库是用户驱动的，应该让用户积极参与数据仓库的建设，在规划书中要确定数据仓库开发目标的实现范围、体系结构和使用方案及开发预算。
综合以上，数据仓库的规划与构建，不是一个一蹴而就的过程，更不是一个单纯的技术问题，不能简单认为将数据进行了集中的清理、存储，就可以构建一个好的数据仓库。
真正要想让数据仓库成为企业内数据资产的有效载体，需要与业务需求紧密融合，将技术与业务需要，以及经营决策要求综合考虑，形成一整套既包含管理模型、要求，又有技术标准、规范的综合体。
同时，从应用的层面，要考虑由点到线再到面的拓展途径，先围绕主要业务需求展开数据的综合管理，逐步拓展到更广泛的领域，这其中要做好业务与数据模型的综合构建，确定业务逻辑与数据逻辑的对应关系，从而能让数据的分析结果为业务及管理提供有效支撑。
因此，只有将数据仓库作为企业数据资产的有效载体，在未来新技术应用的过程中，才能更好地对接新技术要求，将新的技术有效、快速地融入到企业实际需求中，构建出更为强劲的数据平台。
