教你轻松掌握数据仓库的规划和构建策略
教你轻松掌握数据仓库的规划和构建策略
数据仓库作为决策支持系统（DSS）的基础，具有面向主题的、集成的、不可更新的、随时间不断变化的特性。这些特点说明了数据仓库从数据组织到数据处理，都与原来的数据库有很大的区别，这也就需要在数据仓库系统设计时寻求一个适合于数据仓库设计的方法。在一般的系统开发规划中，首先需要确定系统的功能，这些系统的功能一般是通过对用户的需求分析得到的。从数据仓库的应用角度来看，DSS分析员一般是企业中的中高层管理人员，他们对决策支持的需求不能预先做出规范的说明，只能给设计人员一个抽象地描述。
这就需要设计人员在与用户不断的交流沟通中，将系统的需求逐步明确，并加以完善。因此数据仓库的开发规划过程实际上是一个用户和设计人员对其不断了解、熟悉和完善的过程。 数据仓库的开发应用规划是开发数据仓库的首要任务。只有制定了正确的数据仓库规划，才能使组织主要力量有序地实现数据仓库的开发应用。在数据仓库规划中一般需要经历这样几个过程：选择实现策略、确定数据仓库的开发目标和实现范围、选择数据仓库体系结构、建立商业和项目规划预算。 当数据仓库规划完成后，需要编制相应的数据仓库规划说明书，说明数据仓库与企业战略的关系，以及与企业急需处理的、范围相对有限的开发机会，重点支持的职能部门和今后数据仓库开发工作的建议，实际使用方案和开发预算，作为数据仓库实际开发的依据。
1、选择数据仓库实现策略
数据仓库的开发策略主要有自顶向下、自底向上和这两种策略的联合使用。自顶向下策略在实际应用中比较困难，因为数据仓库的功能是一种决策支持功能。这种功能在企业战略的应用范围中常常是很难确定的，因为数据仓库的应用机会往往超出企业当前的实际业务范围，而且在开发前就确定目标，会在实现预定目标后就不再追求新的应用，是数据仓库丧失更有战略意义的应用。由于该策略在开发前就可以给出数据仓库的实现范围，能够清楚地向决策者和企业描述系统的收益情况和实现目标，因此是一种有效的数据仓库开发策略。该方法使用时需要开发人员具有丰富的自顶向下开发系统的经验，企业决策层和管理人员完全知道数据仓库的预定目标并且了解数据仓库能够在那些决策中发挥作用。
自底向上策略一般从某个数据仓库原型开始，选择一些特定的为企业管理人员所熟知的管理问题作为数据仓库开发的对象，在此基础上进行数据仓库的开发。因此，该策略常常用于一个数据集市、一个经理系统或一个部门的数据仓库开发。该策略的优点在于企业能够以较小的投入，获得较高的数据仓库应用收益。在开发过程中，人员投入较少，也容易获得成效。当然，如果某个项目的开发失败可能造成企业整个数据仓库系统开发的延迟。该策略一般用于企业洗碗对数据仓库的技术进行评价，以确定该技术的应用方式、地点和时间，或希望了解实现和运行数据仓库所需要的各种费用，或在数据仓库的应用目标并不是很明确时，数据仓库对决策过程影响不是很明确时使用。
在自顶向下的开发策略中可以采用结构化或面向对象的方法，按照数据仓库的规划、需求确定、系统分析、系统设计、系统集成、系统测试和系统试运行的阶段完成数据仓库的开发。而在自底向上的开发中，则可以采用螺旋式的原型开发方法，使用户可以根据新的需求对试运行的系统进行修改。螺旋式的原型开发方法要求在较短的时间内快速的生成可以不断增加功能的数据仓库系统，这种开发方法主要适合于这样一些场合：在企业的市场动向和需求无法预测，市场的时机是实现产品的重要组成部分，不断地改进对与企业的市场调节是必需的；持久的竞争优势来自连续不断地改进，系统地改进是基于用户在使用中的不断发现。 自顶向下和自底向上策略的联合使用具有两种策略的优点，既能快速的完成数据仓库的开发与应用，还可建立具有长远价值的数据仓库方案。但在实践中往往难以操作，通常需要能够建立、应用和维护企业模型、数据模型和技术结构的、具有丰富经验的开发人员，能够熟练的从具体（如业务系统中的元数据）转移到抽象（只基于业务性质而不是基于实现系统技术的逻辑模型）；企业需要拥有由最终用户和信息系统人员组成的有经验的开发小组，能够清楚地指出数据仓库在企业战略决策支持中的应用。
2、确定数据仓库的开发目标和实现范围
为确定数据仓库的开发目标和实现范围，首先需要对企业管理者等数据仓库用户解释数据仓库在企业管理中的应用和发展趋势，说明企业组织和使用数据来支持跨功能系统的重要性，对企业经营战略的支持，以确定开发目标。在该阶段确认与使用数据仓库有关的业务要求，这些要求应该只支持最主要的业务职能部门，将使用精力集中在收益明显的业务上，使数据仓库的应用立即产生效果，不应该消耗太多的精力在各个业务上同时铺开数据仓库的应用。
在确定开发目标和范围以后，应该编制需求文档，作为今后开发数据仓库的依据。 数据仓库开发的首要目标是确定所需要信息的范围，确定用户提供决策帮助时，在主题和指标域需要哪些数据源。这就需要定义：用户需要什么数据？面向主题的数据仓库需要什么样的支持数据？为成功地向用户提交数据，开发人员需要哪些商业知识？哪些背景知识？这就需要定义整体需求，以文件的形式整理现存的记录系统和系统环境，对使用数据仓库中数据的候选应用系统进行标识、排序，构造一个传递模型，确定尺度、事实及时间标记算法，以便从系统中抽取信息且将他们放入数据仓库。通过信息范围确定可为开发人员提供一个良好的分析平台，和用户一起分析哪些信息是数据仓库需要的，进行商业活动需要什么数据。开发人员可以和用户进一步定义需要，例如数据分级层次、聚合的层次、加载的频率以及需要保持的时间表等。 数据仓库开发的另一个重要目标是确定利用哪些方法和工具访问和导航数据？虽然用户都需要存取并且检索数据仓库的内容，但是所存取的粒度有所不同，有的可能是详细的记录，有的可能是比较概括的记录或十分概括的记录。用户要求的数据概括程度不同，将导致数据仓库的聚集和概括工具的需求不同。
数据仓库还有具有一定功能来访问和检索图表、预定义的报表、多维数据、概括性数据和详细记录。用户从数据仓库中获得信息，应该有电子表格、统计分析器和支持多维分析的分析处理器等工具的支持，以解释和分析数据仓库中的内容，产生并且验证不同的市场假设、建议和决策方案。为将决策建议和各种决策方案向用户清楚地表达出来，需要利用报表、图表和图像等强有力的信息表达工具。 数据仓库开发的其他目标，是确定数据仓库内部数据的规模。在数据仓库中不仅包含当前数据，而且包含多年的历史数据。数据的概括程度决定了这些数据压缩和概括的最大限度。如果要让数据仓库提供对历史记录进行决策查询的功能，就必须支持对大量数据的管理。数据的规模不仅直接影响决策查询的时间，而且还将直接影响企业决策的质量。
在数据仓库的开发目标中，还有：根据用户对数据仓库的基本需求，确定数据仓库中数据的含义；确定数据仓库内容的质量，以确定使用、分析和建议的可信级别；哪种类型的数据仓库可以满足最终用户的需求，这些数据仓库应该具有怎样的功能；需要哪些元数据，如何使用数据源中的数据等。 数据仓库的开发目标多种多样，十分复杂，需要开发人员和用户在开发与使用的过程中不断交互完善。因此，在规划中需要确定数据仓库的开发范围。使开发人员能够根据需求和目标的重要性逐步进行，并且在开发中吸取经验教训，为数据仓库在企业中的全部实现提供技术准备。因此，在为数据仓库确定总体开发方向和目标以后，就必须确定一个有限的能够很快体现数据仓库效益的使用范围。在考虑数据仓库苦的应用范围时，主要从使用部门的数量和类型、数据源的数量、企业模型的子集、预算分配以及开发项目所需的时间等角度分析。
在分析这些因素时，可从用户的角度和技术的角度两方面进行。 从用户的角度应该分析哪些部门最先使用数据仓库？是哪些人员为了什么目的使用数据仓库？以及数据仓库首先要满足哪些决策查询？因为这些决策查询往往确定了关于数据维数、报表的种类，这些因素都将确定数据仓库定义时所需要的数量关系。查询的格式越具体，越容易提供数据仓库的维数、聚集和概括的规划说明。 从技术角度分析，应该确定数据仓库中元数据库的规模，数据仓库的元数据库是存储数据仓库中数据定义的模型。数据定义存储在仓库管理器的目录中，可以作为所有查询和报表工具构造和查询数据仓库的依据。元数据库的规模直接表示了数据仓库中必须管理的数据规模。通过对元数据库规模的管理，实际上就确定了数据仓库中所需要管理的数据规模。
3、数据仓库的结构选择
数据仓库的结构可以进行灵活的选择，可将组织所使用的各种平台进行恰当的分割，把数据源、数据仓库和最终用户使用的工作站分割开来进行恰当的设计。
（1）数据仓库的应用结构
基于业务处理系统的数据仓库 在这种结构中，将运作的数据用于无需修改数据的只读应用程序中。具有这种结构的数据仓库元数据库是一种虚库，而不是数据仓库自身的元数据。在数据仓库元数据库的直接指导下，对数据仓库的查询就是简单的从数据库中抽取数据。
单纯数据仓库
利用在数据仓库中的数据源净化、集成、概括和集成等操作，将数据源从业务处理系统中传输进集中的数据仓库，各部门的数据仓库应用只在数据仓库中进行。这种结构经常发生在多部门、少用户使用数据仓库的情况下。这里的集中仅仅是逻辑上的，物理上可能是分散的。
单纯数据集市
数据集市是指在部门中使用的数据仓库，因为企业中的各个职能部门都有自己的特殊需要，而统一的数据仓库可能不能满足这些部门的特殊要求。这种体系结构经常发生在个别部门对数据仓库的应用感兴趣，而组织中其他部门却对数据仓库的应用十分冷漠之时，由热心的部门单独开发式所采用。
数据仓库和数据集市
企业各部门拥有满足自己需要的数据集市，其数据从企业数据仓库中获取，而数据仓库从企业各种数据源中收集和分配。这种体系结构是一种较为完善的数据仓库体系结构，往往发生在组织整体对数据仓库应用感兴趣之时所采用的体系结构。
（2）数据仓库的技术平台结构 单层结构
单层结构主要是在数据源和数据仓库之间共享平台，或者让数据源、数据仓库、数据集市与最终用户工作站使用同一个平台。共享一个平台可以降低数据抽取和数据转换的复杂性，但是共享平台在应用中可能遇到性能和管理方面的问题，这种体系结构一般在数据仓库规模较小，而组织的业务系统平台具有较大潜力之时所采用。
客户/服务器两层结构
一层为客户机，一层为服务器，最终用户访问工具在客户层上运行，而数据源、数据仓库和数据集市位于服务器上，该技术机构一般用于普通规模的数据仓库。
三层客户/服务器结构
基于工作站的客户层、基于服务器的中间层和基于主机的第三层。主机层负责管理数据源和可选的源数据转换；服务器运行数据仓库和数据集市软件，并且存储仓库的数据；客户工作站运行查询和报表运用程序，且还可以存储从数据集市或数据仓库卸载的局部数据。在数据仓库稍具规模，两层数据仓库结构已经不能满足客户的需求，要讲数据仓库的数据存储管理、数据仓库的应用处理和客户端应用分开之时，可以采用这种结构。
多层式结构
这是在三层机构基础上发展起来的数据仓库结构，在该结构中从最内数据层到最外层的客户层依次是：单独的数据仓库存储层、对数据仓库和数据集市进行管理的数据仓库服务层、进行数据仓库查询处理的查询服务层、完成数据仓库应用处理的应用服务层和面向最终用户的客户层。体系层次可能多达五层，这种体系结构一般用于超规模数据仓库系统。
4、数据仓库使用方案和项目规划预算
数据仓库的实际使用方案与开发预算，是数据仓库规划中最后需要确定的问题。因为数据仓库主要用于对企业管理人员的决策支持，确保其实用性是十分重要的，因此需要让最终用户参与数据仓库的功能设计。这种参与是通过用户的实际使用方案进行的，使用方案是一个非常重要的需求模型。实际使用方案必须有助于阐明最终用户对数据仓库的要求，这些要求有的只使用适当的数据源就可以得到基本满足，而有的却需要来自企业外部的数据源，这就需要通过使用方案将这些不同的要求联系起来。 实际使用方案还可以将最终用户的决策支持要求与数据仓库的技术要求联系起来。因为当用户确定最终要求后，为元数据库的范围确定一个界限。还可以确定所需要的历史信息的数量，当根据特定的用户进行数据仓库的规划时，就可确定最终用户所关心的维度（时间、方位、商业单位和生产企业），因为维度与所需要的概括操作有明显的关系，必须选择对最终用户有实际意义的维度，如：“月”、“季度”、“年”等。最后，还可以确定数据集市/数据仓库的结构需要，使设计人员确定采用单纯数据仓库结构，还是单纯的数据集市结构或者是两者相结合的结构。
在实际使用开发方案确定后，还需要对开发方案的预算进行估计，确定项目的投资数额。投资方案的确定可以依据以往的软件开发成本，但是这种预算的评估比较粗糙。另一种方法是参照结构进行成本评估，也就是说，将数据仓库实际使用方案所确定的构件进行分解，根据各个构件的成本进行预算估算。数据仓库的构件包含在数据源、数据仓库、数据集市、最终用户存取、数据管理、元数据管理、传输基础等部分中，这些构件有的在企业原有信息系统中已经具备，有的可以选择商品化构件，有的则需要自我开发。根据这些构件的不同来源，可以确定比较准确的预算。 在完成数据仓库规划后，就需要编制数据仓库开发说明书，说明系统与企业战略目标的关系，以及系统与企业急需处理的范围相对有限的开发机会，所设想的业务机会的说明以及目标任务概况说明、重点支持的职能部门和今后工作的建议。数据仓库项目应有明确的业务价值计划开始，在计划中需要阐明期望取得的有形和无形的利益。无形利益包含利用数据仓库使决策完成得更快更好等利益。
业务价值计划最好由目标业务主管来完成，因为数据仓库是用户驱动的，应该让用户积极参与数据仓库的建设，在规划书中要确定数据仓库开发目标的实现范围、体系结构和使用方案及开发预算。
如何建立数据仓库架构
如何建立数据仓库架构
每一个数据仓库有一个架构。这架构要么是即时的或计划过的；或隐式的或形成文件的。不幸的是，许多数据仓库开发时并没有一个明确的架构，这极大的限制了它的灵活性。在没有架构的情况下，主题区域就无法契合在一起，它们之间的连接变得无目的，并且使整个数据仓库的管理和变更都难于进行。此外，虽然它可能看起来不重要，数据仓库的架构已成为选择工具时的框架。
让我们把开发一个数据仓库与建造一个真正的房屋进行比较。你如何建造一幢300万美元的大厦呢？更不用说建造一间10万美元的房子了。你要有蓝图、图纸、技术规范、和在多个层次细节上显示这个房子将如何进行建造的标准。当然，针对房子的各种子系统要有不同版本的蓝图，如管道工程、电气、暖通空调系统（HVAC）、通信、和空间。针对所有的家用的设备也有相应的标准，包括插头、灯具、卫生洁具、门的尺寸等。
对于数据仓库，架构是对数据仓库的元素和服务的一种描述，用具体细节说明各种组件如何组合在一起，和随着时间的推移系统将如何地发展。就像这房子的比喻，数据仓库架构是一套文件、计划、模型、图纸和规范，针对每个关键的组件区域有独立的分区，并且足够详细到让专业技术人员可以实施它们。
这并是一个需求文件。需求文件说明架构需要做些什么。数据仓库架构也不是一个项目计划或任务清单；它说明数据仓库是什么，而不是怎么去做或为什么去做。
一个数据仓库的开发也并不容易，因为相对于房屋的5000年建筑史，我们发展数据仓库系统只有20年的时间。因此，我们的标准还不多，工具和技术正在快速发展，关于我们已经拥有数据仓库系统的档案还很少，而且数据仓库的术语还有很大的出入。
所以，虽然开发一个架构是困难的，但它也是可能的，并且又是至关重要的。首先，最主要的是，架构应该受业务的驱动。如果你的要求是每夜进行更新，这一要求就该包含在架构内，而你必须弄清实现你目标的技术需求。下面是一些业务需求的例子，和针对每种需求的综合技术考量：
●每夜更新――充足的数据准备能力
●全球可用性—平行或分布式服务器
●顾客层次分析――大型服务器
●新数据源――带有支持元数据的灵活工具
●可靠性――工作的控制功能
关键组件区域
一个完整的数据仓库架构包括数据和技术因素。架构可以被分为三个主要区域。首先，是基于业务流程的数据架构。其次是基础设施，包括硬件、网络、操作系统和电脑。最后，是技术区域，包含用户所需的决策制定的技术以及它们的支持结构。对这些区域将在下文分小节进行详述。
●数据架构
如上所述，在整体数据仓库架构中的数据架构部分是受业务流程所驱动的。例如，在一个制造环境里，数据模型可能包括订单、装运和帐单。每一个区域都依据一套不同的维度。但是在数据模型中对相交维度的定义必须相同。所以相同数据项应该有同样的结构和内容，并有一个创建和维护的单一流程。
当你完成一个数据仓库架构并呈现数据给你的用户，就要做出对工具的选择，但随着需求的设定， 选择就会变窄。例如，产品的功能开始融合，就像多维联机分析处理（M OLAP）和关系型联机分析处理（ROLAP）。如果停留在你建造的立方体，多维联机分析处理（MOLAP）便可以了。它速度快又允许灵活的查询――在立方体的范围内。它的缺点是规模（整体上和一个维度内）、设计的局限性（受立方体结构所限）、需要一个专有的数据库。关系型联机分析处理（ROLAP）是多维联机分析处理（MOLAP）的一种替代方案，它克服了多维联机分析处理（MOLAP）的这些缺点。通常，混合联机处理（HOLAP）更受欢迎，它允许一部分数据存储在维联机分析处理（MOLAP）中，另一部分数据存储在关系型联机分析处理（ROLAP）中，折衷了各自的长处。
●基础设施架构
对硬件及数据库选择的问题在于其大小、扩展性和灵活性。在大约80%的数据仓库项目中，这并不困难，大多数企业有足够的力量来应对他们的需要。
在网络、检查数据来源、数据仓库准备区、以及它们之间的任何设施方面，要确保有足够的带宽用于数据的移动。
●技术架构
技术架构被元数据目录所驱动。一切都应该受元数据所驱动。服务应该依从表格所需的参数，而不是它们的硬编码。技术架构的一个重要组件是 ETL（提取、转换和加载）流程，它涵盖了五个主要区域：
●提取－数据来自多种数据源并且种类繁多。在这个区域如果有数据的应用时必须考虑对它的压缩和加密处理。
●转换－数据转换包括代理主键的管理、整合、去标准化、清洗、转换、合并和审计。
●加载－加载通常是利用加载最优化和对整个加载周期的支持对多种目标进行加载。
●安全－管理员访问和数据加密的策略。
●元件控制-－它包括元件的定义、元件安排（时间和事件）、监控、登录、异常处理、错误处理和通知。
数据准备区需要能够从多种数据源提取数据，如MVS、ORACLE、VM和其它，所以当你选择产品时要具体。它必须将数据进行压缩和加密、转化、加载（可能对多个目标）和安全处理。此外，数据准备区的活动要能够自动化进行。不同的供应商的产品做不同的事情，所以大多数企业将需要使用多种产品。
一个监控数据仓库使用的系统对查询的采集、使用的跟踪是有价值的，而且也有助于性能的调整。性能优化包括通过“管理者”工具进行的成本估算，而且应包括即时查询的时间表。有工具能够提供查询管理服务。可使用工具来针对这些和其它相关任务，如对前台的基于服务器的查询管理和来自于多种数据源的数据。也有工具可用于报表、连通性和基础设施管理。最后，数据访问块应包括报表的服务（如发布和订阅），还应包括报表库，调度程序和分布管理员。
关于元数据
在数据仓库流程中数据的创建和管理要遵循以下的“步骤”：
●数据仓库模型
●数据源的定义
●表的定义
●数据源到目标的映射
●映射和转换信息
●物理信息（表格空间，等）
●提取数据
●转移数据
●加载统计
●业务描述
●查询请求
●数据本身
●查询统计
为显示元数据的重要性，上述的步骤列表中只有三步包括了“真正”的数据－7、8和12。其他的一切都是元数据，而且整个数据仓库流程都依赖于它。元数据目录的专业技术要素包括：
●业务规则-－包括定义、推导、相关项目、验证、和层次结构信息（版本、日期等。）
●转移/转换信息-－源/目的地的信息，以及DDL（数据类型、名称等等。）
●操作信息-－数据加载的工作时间表、依存性、通知和信息的可靠性 （比如主机的重定向和加载平衡）。
●特定工具的信息-－图形显示信息和特殊功能的支持。
●安全规则-－认证和授权。
建立架构
在开发技术架构模型前，要先起草一份架构需求的文件。然后将每一项业务需求计划包含到它的架构中。根据架构的区域对这些内容进行分组（远程访问、数据准备、数据访问工具等）。了解它如何于其它区域相适应。采集区域的定义及其内容。最后提炼和形成模型的文件。
我们认识到开发一个数据仓库架构是困难的，因此要有一个周密细致的规划。但ZACHMAN框架又超出了大多数企业对数据仓库的需要，所以建议使用一个合理的折衷方案，它由四层流程所组成：业务需求、技术架构、标准和工具。
业务需求本质上驱动着架构，所以要对业务经理、分析师、高级用户进行访谈。从你的访谈中寻找主要的业务问题，以及企业战略、发展方向、挫折、业务流程、时间、可用性、业绩预期的指标。将它们一一妥善归档。
从IT的角度来看，跟现有的数据仓库/决策支持系统（DSS）的支持人员、联机分析处理（OLTP）应用组成员、数据库管理员们（DBA）；以及网络、操作系统和桌面支持人员进行讨论。也要与架构师和专业规划人员进行探讨。你应该从这些讨论中得知他们从IT的观点考虑数据仓库的意见。从中了解是否有现存的构架文件、IT原则、标准文件、企业数据中心等。
关于数据仓库并没有太多现存的标准，但对于许多组件来说是有标准的。下面是一些需要牢记的标准：
●中间设备－－开放数据库连接（ODBC）、对象链接与嵌入（OLE）、对象链接与嵌入数据库（OLE DB）、数据通信设备（DCE）、对象请求代理（ORB）和数据库编程（JDBC）
●数据库连接－－ODBC, JDBC, OLE DB, 和其它。
●数据管理－－ANSI SQL 和文件传输协议（FTP）
●网络访问－－数据通信设备（DCE）、域名服务器（DNS）、和 轻量目标访问协议（LDAP）
无论它们支持的是哪种标准，主流的数据仓库工具都受元数据所驱动。然而，它们通常并不互相共享元数据而且在开放性上也所有不同。所以，要仔细研究和购买工具。架构师是你选择适当工具的向导。
一个数据仓库架构需要具体到怎样的程度呢？这个问题要问的是：它有足够的信息可以让一个有能力的团队来建立一个满足业务需求的数据仓库吗？至于它要花多长时间，随着更多的人加入到它的开发中来（即：它变成了“复杂的技术策略”）和生成的系统需要变得更复杂（即"复杂的功能”），架构的完成会呈指数倍的发展。
像数据仓库中几乎所有的事情一样，一个迭代进程是最好的。你不能一次做完所有的事情因为它太大了， 而且业务不能等。同时，数据仓库的市场还没有完备。所以从流程中影响大、高价值部分开始，然后，利用你的成功去带动另外的阶段。
总结：
综上所述，建立一个数据仓库架构的好处如下：
●提供了一个组织结构的框架-－架构对什么是单独的组件、如何将它们组装在一起、谁拥有什么部分以及优先次序的问题划出了界线。
●提高了灵活性和维护性-－让你能快速加入新的数据来源，接口标准允许即插即用，模型和元数据允许影响分析和单点的变化。
●更快的开发和再利用-－数据仓库开发者更能够快速了解数据仓库流程、数据库内容和业务规则。
●管理和通信的工具-－定义未来方向和项目范围， 确定职务和职责、对供应商传达需求。
●协调多项任务同时进行——多种、相对独立的工作有机会成功地集合。
我们建议公司对准业务需求而又要务实一些。时刻跟上数据仓库产业的进步是很重要的。最后，请记住架构总是存在的：或隐性或具体的，或无计划或计划内的。经验证明，有一个计划内和具体的架构会使数据仓库与 商业智能项目有更多的成功机会。