建立一个数据仓库并不是一个简单的任务，不应该由一个人单独完成。由于数据仓库最佳结合了业务惯例和信息系统技术，因此，一个成功的数据仓库实施需要这两方面的不断协调，以均衡其所有的需要，要求，任务和成果。我很乐意与大家分享我在规划和管理任何数据库项目时采用的方法，这些数据库包括交易数据库，数据仓库，和混合型数据库。由于我生活在关系数据库和数据仓库以及用以支撑它们的数据提取，转换和加载(ETL )过程中，所以我会集中在这些领域讨论我的方法。然而，您可以将这些方法扩展到整个栈--OLAP立方体和如报告，特征分析(ad-hoc analysis)，记分卡和仪表盘展示之类的信息传递应用。
我不是吃撑了要告诉一个真正的项目经理( PM )如何做他或她的工作，相反，我写的这些是为那些数据库管理员和开发者，他们没有好运气能与有经验的项目经理一起工作;同样也适合这样的IT专业人员，他们被突然要求：“建立一个数据仓库“，并且需要自己扮演项目经理的角色。我的讨论不会是完整的，但我希望这会给您足够的信息来让您的项目球滚起来。
如图1所示，数据仓库项目有3个轨道(tracks)：数据轨道，技术轨道和应用层轨道。当您在整理任何数据库项目计划时，我建议您以这三个轨道为模板来管理和同步您的活动。当您向技术决策者( TDMs ) ，商业决策者( BDMs ) ，和所有其他该数据仓库项目参与者讲解您的计划时，您也可以把图1当作一个高级的概要图来使用。
使用一种生命周期管理方法
我鼓励您利用您的组织可以提供的资源，比如设计，开发和部署系统和软件的技术和方法。如果贵公司对于这些工作没有采用任何正式的方法，继续前进吧，您可采用我为我自己的数据库项目开发的7D数据库生命周期管理方法(Discover, Design, Develop, Deploy, Day to Day , Defend, Decommission), 昵称“7D法”。
我的“7D”数据库生命周期管理方法讲的是数据库的生命周期管理，而不是相关的软件(应用程序)和硬件的生命周期。图1包括了软硬件轨道，但我不会进一步阐述它们的管理。为了成功实施数据库生命周期的方法，有必要调整和同步数据库生命周期的里程碑、硬件和应用软件。
数据仓库的构建从来不会真正结束。不像传统的数据库在部署后的一段时间里保持相对的不变，数据仓库始终处于不断的变化之中，以应对它所服务的业务环境的变化。当今的业务环境更加复杂，并涉及比以往任何时候都要快的变化。处理这种几乎是不断的变化是企业的最大挑战之一。这就是为什么数据仓库团队中的每一个人，包括技术决策者( TDMs ) 和业务决策者( BDMs )，都必须处在同一阵线上，使用同一种生命周期管理方法，以使他们的认识完全得到统一。只有这样，才有可能对已实施的数据仓库、企业的构想和宗旨进行调整。在图1中，我已经展示了我的“7D法”的7个步骤，本文将带领您完成每一步。
第一步：发掘
我保证任何规模和领域的数据库项目离开了开始的发掘阶段都将失败。这个阶段也被称为“需求分析和定义”， 发掘阶段需要以业务为中心，特别是数据仓库项目，因为数据仓库的输出需要支持组织的目标。发掘这一步实质上就是调查，您应该不断地问六个基本问题(什么，如何，在何处，谁，何时和为什么)，记录好答案，并把这些答案包含在您起草的解决方案中。
在“7步”的前3步(发掘，设计，开发)中，必须对业务主和技术专家进行集中的协调，项目经理(PM)应该促成这一进程。项目经理作为一个独立的专业人员，主要关心项目的及时上线、预算在控制范围内，有预期的运行效果;项目经理在得到各方的反馈意见后，负责制定严格的路线，里程碑和成功指标。如果项目里没有PM,这些将成为您的工作。
在发掘阶段，PM必须收集图1所示的三个轨道的信息，即技术轨道，数据轨道和应用层轨道。在其他任务中，PM必须确定利益相关者和用户，必须理解他们各自的角色和相应的数据/视图 需求。PM必须知道本组织的绩效管理策略：目标是什么，倡议什么以及跟踪业务和项目健康状况的支撑度量标准/关键绩效指标。如果上述策略的任何部分遗漏了，该项目很有可能失去最终用户的评分，这可能会导致低的采用通过率和未来资金的丢失。换句话说，该项目将失败，而不管项目任务执行得有多么完美。
第二步： 设计
设计这一步的主要活动是定义描述数据仓库的语义和概要模型。这些模型必须解决企业用户的管理信息系统(MISs)和商务智能( BI )分析需要。对于数据仓库项目，您可以为关系型数据仓库创建概念和逻辑数据模型，为表示多维立方体创建三维模型。您可以使用决策矩阵，以帮助确定每个三维模型需要包含些什么;沿Y轴方向列出被数据仓库支持的关键业务流程，沿X轴方向列出建议的维。这个矩阵将作为当前开发、未来扩展和跨组织集成的向导。在设计阶段建立的模型必须反映第一阶段您收集的六个问题的答案。标识数据仓库相关的所有数据源(内部和外部的)，业务/交易数据库和展平文件是个好注意。您也应该明确说明哪些数据将被导入数据仓库，哪些只会简单地作为外部数据源引用。
通常，技术轨道有自己的PM，但您仍然可能需要填补那个角色。数据仓库可以增长为非常大的内容和十分广泛的范围，因此有必要在数据仓库部署之前恰当地规划其大小。首先在纸上估计其大小，这样您就可以大致把握当数据仓库投入产品应用时所需的处理器速度和磁盘容量。您需要估算一天的业务终端用户数量以及他们使用的应用(例如，对立方体做一个特别分析，或者从关系数据仓库中取出缓存的报告)，也要估算数据仓库一年中将会存储的数据量。只是因为数据仓库是一个进展中的工作，您需要两年和五年预测，同样，其处理能力和数据存储需求将随着时间的推移不断增加。数据仓库设施包括各种硬件，通信和软件解决方案，所有这一切都必须协同工作，为终端用户提供一个工作的数据仓库。您需要足够的时间来计划和测试您将如何整合所有这些不同的组成部分。
跟技术轨道一样，应用轨道可能有自己的PM或由一个主导的软件开发人员充当这一角色。如果你是幸运的，你的工作将是与此人协调以同步任务。如果不是，那你的工作描述会扩大。应用层包括获取从数据仓库收集到的输出，通常是MIS报告和BI分析结果。MIS报告常是屏幕显示，仪表板，和打印副本的形式，它们帮助企业管理者做出运行日常业务所需的战术决策。这些输出相对比较容易界定、编码和被一系列标准化的进程抓取，这些进程运行在可预定环境中。应用层的BI部分是一组查询和响应，以帮助执行管理作出战略决策，推动商务运营。BI解决方案往往是非结构化的，很难预定义，因为他们倾向于用一种特别的方式探索数据。记分牌，图形和数据透视表是BI的应用例子，它们能刺激更多的数据探索，而这可能导致公司内部战略方向的改变。
在这个阶段许多方法要求原型或试点项目。“7D法”不需要。至多，作为应用层的设计活动中的一部分，你可以做一个“点击模式”--一种输入/输出屏幕的快速呈现模型，不涉及或只有极少的代码但却能给利益攸关方可视化的概念，同时又不会吃掉宝贵的时间和资源。如果试点或原型是必要的，那么选择其中的一个切片(slice)作为试点，完成“7D法”的每一步。“7D法”不区分试点，原型和产品系统--它们都被视为项目。
如果按照“7D法”设计了一个原型，并且最终进入了产品(大多数原型都是这样)，然后您必须比第一个切片更仔细地选择第二个切片。如果这些切片不能成功地集成在一起，如果他们不支持您在发掘步骤发现的企业宗旨和意图，那么您在创建“烟囱”， 这是信息的群岛，整合彼此只会遇到困难，在某些情况下，甚至根本不可能.
第三步：开发
数据轨道开发步骤主要有两个部分：第一个涉及将数据模型映射到其对应的物理设计(实质是关系数据仓库和OLAP立方体的蓝图)，规划数据库的大小，必要时对表进行分块，为数据仓库对象设定命名约定以便业务用户和技术用户都能适应，并制定索引和识别索引候选名单的策略。第二部分涉及数据从外部数据源到数据仓库的提取转换加载(ETL)。包含在第二部分但不局限于这一部分的是数据转换服务( DTS )/SQL Server整合服务( SSIS)补丁的开发与测试，导入/导出和T-SQL脚本开发和测试，以及对外部数据源组件的数据整合测试，这些数据不会导入到数据仓库。
技术轨道的开发步骤包括审查，测试和选择产品，并提供其作品的体系结构设计。为了组成通信链路的各个层--物理层、数据链路层、网络层以及传输层，会话和表现层，这样做是必需的。虽然许多产品把多层无缝打包到一个解决方案，但有必要认识到这些层中的每一个在未来的负载要求和性能要求，并提前为这些需求作好准备。为了从新的数据仓库交付数据，您应该选定数据仓库的服务器和存储解决方案，以及新的，最终用户面临的硬件。这样做是为了产品数据仓库和分期数据库--DTS/SSIS软件包和T-SQL脚本在这里执行，从外部数据源导入数据，以及把可操作和精心料理的数据导入到关系数据仓库和OLAP立方体中。根据发掘阶段收集到的需求，您的数据仓库环境可能还要支持数据集市，快照，和报告数据库，因此，也要准备为这些方面考虑环境。
应用轨道开发步骤听起来很简单：只要开发终端用户应用程序。然而，这可能是整个过程中最复杂和费时的任务，并且可能是代价最高的--如果没有认真制定和考虑成功的度量标准。正是在这一阶段，范围蠕变(不断增加特性和功能，而不考虑对其他两个轨道的设计和开发的影响)可能像鱼雷一样破坏项目。除了开发终端用户应用程序，您也不得不制定测试这些应用程序的计划，您需要制定终端用户培训计划以便用户能学会如何使用这些应用软件。在每一个里程碑，你必须确保获得相关各方的签字或验收。
这可能听起来很明显，但多少令人惊讶的是不知道有多少开发项目是在产品环境中阶段化和测试的!别这样做，只是不要这样做!为开发，测试，和组件划分搭建一个单独的物理环境。对业务系统要这样做--同样，对BI/数据仓库也要这样做。#p#
第四步：部署
部署数据仓库和部署交易数据库是不一样的，通常，您以一种快速、包罗万象的风格部署一个交易数据库-周五晚上终端用户在使用旧式系统，而周一上午他们登录到新的数据库。数据仓库通常是递增式地部署到整个企业的各类用户中。这种递增的速度和各个组使用数据仓库的次序是包含在部署阶段中部署计划的一部分。
理想的情况下，数据仓库的部署以一种迅速级联的层次进行，首先是技术就位--服务器，存储设备，通信链接等，系统软件的安装，测试并准备投入产品。然后是数据轨道各组件的展开--数据仓库数据库(关系型和OLAP )的建立，以及ETL进程的联机。在最终的应用层添加之前往往会打住一下，当您通过ETL进程让数据流从外部来源进入各种不同的数据仓库数据库和立方体时，进行必要的测试和调整。然后应用层被部署。您可能想要逐渐地部署应用层，因为企业内部的不同人员有不同的等级。
作为一个PM，你发挥着非常重要的作用。在你的指导和引导下，三个轨道将按预定计划到达部署阶段，避免数周数月的“误点”忧虑。一旦技术和数据轨道就绪并测试，并准备继续，那么开始展开应用层。没有用户界面( UI)的数据仓库对任何人都是没用的，而一个尺寸不足，弱工程系统架构的数据仓库会因性能太差而不会被企业用户采用。
第五步：每一天
日常业务运营的管理是非常重要的;而这常常在规划和开发过程中被忽视。你不仅必须确保定期(每日，每周等)进行维护，包括硬件和软件，还必须要不断监视所有系统的性能和增长。正如我一开始所说，数据仓库永远不会结束;随着越来越多的用户发现数据的内在价值，并创造新的，有时甚至是具有挑战性的方式来查询数据仓库，它会继续增长和扩大。有些PM的任务有时你必须准备承担，包括确保所有的系统(硬件，通信链路，系统软件)的全面运作，打最新的补丁和升级。当业务瓶颈出现时尽可能快地诊断和解决问题; 确保所有需要做备份的系统及时备份，实际上，有备份工作定义和计划，并要求所有的备份恢复测试，后续测试，开发，或报告数据库。
业务不是静止的，它们必须不断地改造自己，以保持竞争力。数据仓库数据管理员的职责就是跟踪数据的使用，评估数据的重要性，并检测业务什么时候开始需要转变。随着业务模式的变化，将会需要更新，更好，更灵活，可能更复杂的用户应用程序，数据管理员应该能感知到这些要求。有时，当业务方向和重点变化到了一定的程度，就需要重新进入发掘阶段，生命周期将回到原点。洗涤，漂洗，重复下去。
第六步：防护
捍卫你的数据仓库涉及的不仅仅是采取定期备份或确保没有任何应用程序包括SQL查询可能会开放给SQL注入式攻击。你必须计划整个范围和宽度的捍卫，因为数据仓库包含了企业最宝贵的资产--它的数据，以一种经过编译的，清理过的，以及(在某些情况下)信息化了的格式存在。
数据仓库的威胁通常分为两类，物理的和逻辑的。物理方面的威胁可以是外部的(龙卷风，洪水，火灾，地震)或内部(有意的，偶然的)。您可以防止来自物理方面威胁的做法既可以是采用简单的限制访问计算机和通信室，也可以如位于地理上相距甚远的容错站点上的镜像服务器般复杂(且昂贵)。物理防御取决于您的恢复时间和恢复点目标，也就是多少时间你的数据仓库离线你可以忍受和多少数据丢失你可以承担。
逻辑威胁要复杂得多，仅仅因为数据仓库环境的自然特性。操作系统可能会失败，数据库管理系统可能会崩溃，一个或多个应用程序可能有意无意损坏、销毁、误解数据(尤其出现在承担数据仓库给养任务的ETL过程中)。浏览器的用户界面已经把嵌入式SQL调用暴露给了SQL注入式攻击。每一个潜在的威胁都必须查明和处理; 在威胁发生之前制定补救措施要比它们发生之后好得多。PM的工作是为您的整个数据仓库安装制定一个全面的防御。如果你足够幸运有一个安全管理员，利用此人的专长和经验。
第七步：退役
可能有一天当数据仓库，或一个组件部分(分期数据库，数据集市，报告数据库，立方体)不再符合要求，解除它的时间就到了。并非每一个数据库都可以不断重构或升级，以满足新的要求。有时候，你仅仅是需要丢弃和重建，特别是如果数据库实例是“规范建立的”，即没有适当的架构充分反映企业的目标和意图。在这种情况下，作为PM，你必须同步进程。
一般来说，退役步骤以如下三种方式之一发生：没有更换的退役;移交式退役;和逐步到位/逐步淘汰的退役。“没有更换的退役”是指数据库用来执行的功能不再需要。不仅是数据库退休了，在它之上的执行功能也退休了。 “移交式退役”表明另一个数据库将取代退役的数据库，并且其对应的执行功能也将从旧的数据库迅速转移到新的。某一天，用户可能访问旧的数据库，而第二天他们将访问新的。“逐步到位/逐步淘汰的退役”表明旧的和新的数据库将并存运行一段时间，而功能和用户逐步从旧的转移到新的，直到最后再也没有用户或功能运行旧的数据库时，它就可以退役了。每个方案都有其风险和回报;作为PM你必须确定何时风险大于收益，确定哪种计划最适合您的情况。然后你必须与技术轨道和应用轨道的其他人员协同工作，计划和执行，以确保无缝转换。
良性循环
在您与这些数据仓库的各个组件打交道的过程中，随后将会有新一轮的发现，这期间你会评估随着时间而发展的新需求。发生这种情况可能来自从存储在数据仓库中的数据收集到的信息。这些新的要求可能会导致扩大增强一个或多个轨道的设计和解决方案。您需要将这些变化反映到现有的数据仓库中，这样您就可以部署更新、更好的、用户渴望利用的解决方案。为保持数据仓库像不可思议的机器一样运行，一些新的要求可能会导致日常运作的变化。
随着时间的推移，生命周期的多次迭代过程会导致数据仓库紧密联系于企业结构，直到数据仓库和业务成为无缝的整体。对于这一难题，PM的职责是确保所有活动和任务都是按照规范进行，被既定的成功指标接受，并被同步部署。即使您的数据仓库项目没有正式的PM，即使你是人力资源唯一列在这个项目上的人员，你仍然应该做一些PM会做的计划，并及时更新。然后，当管理层问：“数据仓库项目进展如何了?”你可以告诉他们项目目前处在什么阶段和已经干了些什么工作。
【编辑推荐】
