第三步：开发

　　数据轨道开发步骤主要有两个部分：第一个涉及将数据模型映射到其对应的物理设计(实质是关系数据仓库和OLAP立方体的蓝图)，规划数据库的大小，必要时对表进行分块，为数据仓库对象设定命名约定以便业务用户和技术用户都能适应，并制定索引和识别索引候选名单的策略。第二部分涉及数据从外部数据源到数据仓库的提取转换加载(ETL)。包含在第二部分但不局限于这一部分的是数据转换服务( DTS )/SQL Server整合服务( SSIS)补丁的开发与测试，导入/导出和T-SQL脚本开发和测试，以及对外部数据源组件的数据整合测试，这些数据不会导入到数据仓库。

　　技术轨道的开发步骤包括审查，测试和选择产品，并提供其作品的体系结构设计。为了组成通信链路的各个层--物理层、数据链路层、网络层以及传输层，会话和表现层，这样做是必需的。虽然许多产品把多层无缝打包到一个解决方案，但有必要认识到这些层中的每一个在未来的负载要求和性能要求，并提前为这些需求作好准备。为了从新的数据仓库交付数据，您应该选定数据仓库的服务器和存储解决方案，以及新的，最终用户面临的硬件。这样做是为了产品数据仓库和分期数据库--DTS/SSIS软件包和T-SQL脚本在这里执行，从外部数据源导入数据，以及把可操作和精心料理的数据导入到关系数据仓库和OLAP立方体中。根据发掘阶段收集到的需求，您的数据仓库环境可能还要支持数据集市，快照，和报告数据库，因此，也要准备为这些方面考虑环境。

　　应用轨道开发步骤听起来很简单：只要开发终端用户应用程序。然而，这可能是整个过程中最复杂和费时的任务，并且可能是代价最高的--如果没有认真制定和考虑成功的度量标准。正是在这一阶段，范围蠕变(不断增加特性和功能，而不考虑对其他两个轨道的设计和开发的影响)可能像鱼雷一样破坏项目。除了开发终端用户应用程序，您也不得不制定测试这些应用程序的计划，您需要制定终端用户培训计划以便用户能学会如何使用这些应用软件。在每一个里程碑，你必须确保获得相关各方的签字或验收。

　　这可能听起来很明显，但多少令人惊讶的是不知道有多少开发项目是在产品环境中阶段化和测试的!别这样做，只是不要这样做!为开发，测试，和组件划分搭建一个单独的物理环境。对业务系统要这样做--同样，对BI/数据仓库也要这样做。

　　第四步：部署

　　部署数据仓库和部署交易数据库是不一样的，通常，您以一种快速、包罗万象的风格部署一个交易数据库-周五晚上终端用户在使用旧式系统，而周一上午他们登录到新的数据库。数据仓库通常是递增式地部署到整个企业的各类用户中。这种递增的速度和各个组使用数据仓库的次序是包含在部署阶段中部署计划的一部分。

　　理想的情况下，数据仓库的部署以一种迅速级联的层次进行，首先是技术就位--服务器，存储设备，通信链接等，系统软件的安装，测试并准备投入产品。然后是数据轨道各组件的展开--数据仓库数据库(关系型和OLAP )的建立，以及ETL进程的联机。在最终的应用层添加之前往往会打住一下，当您通过ETL进程让数据流从外部来源进入各种不同的数据仓库数据库和立方体时，进行必要的测试和调整。然后应用层被部署。您可能想要逐渐地部署应用层，因为企业内部的不同人员有不同的等级。

　　作为一个PM，你发挥着非常重要的作用。在你的指导和引导下，三个轨道将按预定计划到达部署阶段，避免数周数月的“误点”忧虑。一旦技术和数据轨道就绪并测试，并准备继续，那么开始展开应用层。没有用户界面( UI)的数据仓库对任何人都是没用的，而一个尺寸不足，弱工程系统架构的数据仓库会因性能太差而不会被企业用户采用。

　　第五步：每一天

　　日常业务运营的管理是非常重要的;而这常常在规划和开发过程中被忽视。你不仅必须确保定期(每日，每周等)进行维护，包括硬件和软件，还必须要不断监视所有系统的性能和增长。正如我一开始所说，数据仓库永远不会结束;随着越来越多的用户发现数据的内在价值，并创造新的，有时甚至是具有挑战性的方式来查询数据仓库，它会继续增长和扩大。有些PM的任务有时你必须准备承担，包括确保所有的系统(硬件，通信链路，系统软件)的全面运作，打最新的补丁和升级。当业务瓶颈出现时尽可能快地诊断和解决问题; 确保所有需要做备份的系统及时备份，实际上，有备份工作定义和计划，并要求所有的备份恢复测试，后续测试，开发，或报告数据库。

　　业务不是静止的，它们必须不断地改造自己，以保持竞争力。数据仓库数据管理员的职责就是跟踪数据的使用，评估数据的重要性，并检测业务什么时候开始需要转变。随着业务模式的变化，将会需要更新，更好，更灵活，可能更复杂的用户应用程序，数据管理员应该能感知到这些要求。有时，当业务方向和重点变化到了一定的程度，就需要重新进入发掘阶段，生命周期将回到原点。洗涤，漂洗，重复下去。

　　第六步：防护

　　捍卫你的数据仓库涉及的不仅仅是采取定期备份或确保没有任何应用程序包括SQL查询可能会开放给SQL注入式攻击。你必须计划整个范围和宽度的捍卫，因为数据仓库包含了企业最宝贵的资产--它的数据，以一种经过编译的，清理过的，以及(在某些情况下)信息化了的格式存在。

　　数据仓库的威胁通常分为两类，物理的和逻辑的。物理方面的威胁可以是外部的(龙卷风，洪水，火灾，地震)或内部(有意的，偶然的)。您可以防止来自物理方面威胁的做法既可以是采用简单的限制访问计算机和通信室，也可以如位于地理上相距甚远的容错站点上的镜像服务器般复杂(且昂贵)。物理防御取决于您的恢复时间和恢复点目标，也就是多少时间你的数据仓库离线你可以忍受和多少数据丢失你可以承担。

　　逻辑威胁要复杂得多，仅仅因为数据仓库环境的自然特性。操作系统可能会失败，数据库管理系统可能会崩溃，一个或多个应用程序可能有意无意损坏、销毁、误解数据(尤其出现在承担数据仓库给养任务的ETL过程中)。浏览器的用户界面已经把嵌入式SQL调用暴露给了SQL注入式攻击。每一个潜在的威胁都必须查明和处理; 在威胁发生之前制定补救措施要比它们发生之后好得多。PM的工作是为您的整个数据仓库安装制定一个全面的防御。如果你足够幸运有一个安全管理员，利用此人的专长和经验。

　　第七步：退役

　　可能有一天当数据仓库，或一个组件部分(分期数据库，数据集市，报告数据库，立方体)不再符合要求，解除它的时间就到了。并非每一个数据库都可以不断重构或升级，以满足新的要求。有时候，你仅仅是需要丢弃和重建，特别是如果数据库实例是“规范建立的”，即没有适当的架构充分反映企业的目标和意图。在这种情况下，作为PM，你必须同步进程。

　　一般来说，退役步骤以如下三种方式之一发生：没有更换的退役;移交式退役;和逐步到位/逐步淘汰的退役。“没有更换的退役”是指数据库用来执行的功能不再需要。不仅是数据库退休了，在它之上的执行功能也退休了。 “移交式退役”表明另一个数据库将取代退役的数据库，并且其对应的执行功能也将从旧的数据库迅速转移到新的。某一天，用户可能访问旧的数据库，而第二天他们将访问新的。“逐步到位/逐步淘汰的退役”表明旧的和新的数据库将并存运行一段时间，而功能和用户逐步从旧的转移到新的，直到最后再也没有用户或功能运行旧的数据库时，它就可以退役了。每个方案都有其风险和回报;作为PM你必须确定何时风险大于收益，确定哪种计划最适合您的情况。然后你必须与技术轨道和应用轨道的其他人员协同工作，计划和执行，以确保无缝转换。

　　良性循环

　　在您与这些数据仓库的各个组件打交道的过程中，随后将会有新一轮的发现，这期间你会评估随着时间而发展的新需求。发生这种情况可能来自从存储在数据仓库中的数据收集到的信息。这些新的要求可能会导致扩大增强一个或多个轨道的设计和解决方案。您需要将这些变化反映到现有的数据仓库中，这样您就可以部署更新、更好的、用户渴望利用的解决方案。为保持数据仓库像不可思议的机器一样运行，一些新的要求可能会导致日常运作的变化。

　　随着时间的推移，生命周期的多次迭代过程会导致数据仓库紧密联系于企业结构，直到数据仓库和业务成为无缝的整体。对于这一难题，PM的职责是确保所有活动和任务都是按照规范进行，被既定的成功指标接受，并被同步部署。即使您的数据仓库项目没有正式的PM，即使你是人力资源唯一列在这个项目上的人员，你仍然应该做一些PM会做的计划，并及时更新。然后，当管理层问：“数据仓库项目进展如何了?”你可以告诉他们项目目前处在什么阶段和已经干了些什么工作。