简介
业务环境是在快速变化的，而业务数据的类型也是如此。一个成功的数据仓库解决方案的基础就是灵活的设计，这种设计可以适应不断变化的业务数据。数据仓库的架构和仓库数据的建模是仓库设计中的核心过程。
数据仓库的架构
当使用数据模型捕获业务需求时，您就已经完成了数据仓库设计中的部分工作。然而，正式的数据仓库设计应该从数据仓库的架构开始。
仓库架构是基于一些因素所做的关键决策，这些因素包括当前基础设施、业务环境、期望的管理和控制结构、实现工作的承诺和范围、企业所采用的技术环境的功能以及可用的资源等。
架构选择
仓库架构将决定数据仓库和数据集市本身的位置，以及控制所驻留的位置，或者反之。例如，数据可以驻留在集中进行管理的中心位置中。或者，数据可以驻留在集中或独立管理的分布式的本地和/或远程位置中。
有以下一些架构选择：
业务范围（Business-wide）的数据仓库
独立的数据集市
互连的数据集市
这些架构选择也可以组合使用。例如，数据仓库架构可以在物理上分布或集中管理。
业务范围的数据仓库架构
业务范围的数据仓库就是将支持整个或一大部分业务的数据仓库，该业务需要更加完全集成的数据仓库，跨部门和业务线（line of business）具有较高的数据访问和使用率。即基于整个业务需求设计和构造仓库。可以将之视作可跨整个企业使用的决策支持数据的公共存储库，或其中的一个大型子集。这里所使用的术语“业务范围（business-wide）”反映的是数据访问和使用的范围，而非物理结构。在整个企业中，业务范围的数据仓库在物理上可以是集中式的，也可以是分布式的。
独立的数据集市架构
独立的数据集市架构暗指单独的数据集市，这些数据集市是由特定的工作组、部门或业务线进行控制的，完全是为满足其需求而构建的。实际上，它们甚至与其他工作组、部门或业务线中的数据集市没有任何连通性。
图 1. 数据仓库架构选择
互连的数据集市架构
互连的数据集市架构基本上是分布式的实现。虽然不同的数据集市是在特定的工作组、部门或生产线中实现的，但它们可以是集成、互连的，以提供更加全局的业务范围的数据视图。实际上，在最高的集成层次上，它们可以成为业务范围的数据仓库。这意味着一个部门中的终端用户可以访问和使用另一部门中数据集市中的数据。
您应选择哪种架构？
如果您客户的业务和数据源是相对集中的，那业务范围的集中式数据仓库架构就是最明智的选择。这实际上对于中间市场的公司而言是很普遍的情况。否则，对于在地理上广泛分布的业务而言，互连的数据集市和业务范围的分布式数据仓库就是更加实用的选择。
独立的数据集市架构不是一种好方法，因为它违背了数据仓库的关键概念：数据集成。
数据仓库的实现方法
实现方法的选择受这些因素的影响：当前的 IT 基础设施、可用的资源、所选择的架构、实现的范围、对于跨企业进行的更大业务范围的数据访问的需求、投资回报率（return-on-investment）需求以及实现的速度。实现方法的选择是数据仓库设计中的重要部分；该决策需要在数据仓库项目的早期阶段做出。
自顶向下的实现
自顶向下的方法就是在单个项目阶段中实现数据仓库。自顶向下的实现需要在项目开始时完成更多计划和设计工作。这就需要涉及参与数据仓库实现的每个工作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据模型的有关决策一般需要在真正的实现开始之前就完成。
自底向上的实现
自底向上的实现包含数据仓库的计划和设计，无需等待安置好更大业务范围的数据仓库设计。这并不意味着不会开发更大业务范围的数据仓库设计；随着初始数据仓库实现的扩展，将逐渐增加对它的构建。现在，该方法得到了比自顶向下方法更广泛的接受，因为数据仓库的直接结果可以实现，并可以用作扩展更大业务范围实现的证明。
您应该选择哪种实现？
每种实现方法都有利弊。在许多情况下，最好的方法可能是某两种的组合。该方法的关键之一就是确定业务范围的架构需要用于支持集成的计划和设计的程度，因为数据仓库是用自底向上的方法进行构建。
在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时，您可以一个接一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库。这样的方法可以极好地适用于业务。每个数据集市都可以处理可识别的业务问题或主题领域，从而可以计算 ROI。构建团队可以测试并调整产品，而该方法也为构建团队提供了宝贵的学习曲线。
对于中间市场的公司，有一些额外的理由要采用自底向上的方法：
在中间市场的业务及其业务数据结构中，存在比企业业务数据中更多的易变性。
较小的公司通常存在有限的项目预算。
中间市场的公司需要快速解决方案以减轻其业务难度。
该类项目所需要的人员必须具有对业务的广泛理解以及特定业务领域的详细知识。找到这样的人是很困难的，但即使可以，使用他们的时间来进行数据建模也比让他们尽普通业务职责更加困难。
数据仓库基础设施
既然已经具有关于高级数据仓库架构的一些决策，您就可以开始考虑数据仓库应该具有什么组件了。
图 2. 商业智能基础设施组件的高级视图
数据仓库应具有上图中所描述的商业智能基础设施中的所有组件。本文将关注数据仓库的构造，其中涉及到了除信息分析之外的所有这些组件。
这些商业智能组件可以定义为：
数据源：当前可用的业务数据源和外部数据源以及将来可能存在的数据源的清晰定义。
数据获取：用于获得、清洗、转换和集成数据的 ETL（提取、转换和装入）过程。
业务数据仓库：仓库数据存储库的数据库。
数据传播：用于为数据集市聚集和增强数据的 ETL 过程。
数据集市：更加用户友好的数据结构中的数据仓库的子集。
信息分析（本解决方案中未涉及）。
元数据管理：业务需求、数据模型、ETL 过程设计、用户手册，等等。
系统管理：数据管理、数据仓库安全性、系统和数据库的备份和恢复，等等。
数据仓库的建模
数据只是所有业务活动、资源以及企业结果的记录。数据模型是对那些数据的组织良好的抽象，因此数据模型成为理解和管理企业业务的最佳方法是极其自然的。数据模型起到了指导或计划数据仓库的实现的作用。在真正的实现开始之前，联合每个业务领域的数据模型可以帮助确保其结果是有效的数据仓库，并且可以帮助减少实现的成本。
目标仓库数据的建模是将需求转换成图画以及支持表示那些需求的元数据的过程。出于易读性目的，本文将关于需求和建模的讨论相分离，但实际上这些步骤通常是重叠的。一旦在文档中记录一些初始需求，初始模型就开始成型。随着需求变得更加完整，模型也会如此。
最重要的是向终端用户提供良好集成并易于解释的数据仓库的逻辑模型。这些逻辑模型是数据仓库元数据的核心之一。为终端用户提供的简单性以及历史数据的集成和联合是建模方法应该帮助提供的关键原则。
仓库数据的建模与操作数据库的建模
在建模的过程中，请记住下列问题：
数据仓库应该是面向终端用户的。在数据库操作中，用户不直接与数据库进行交互。他们使用应用程序，这些应用程序具有预先定义的或固定的查询。数据仓库的数据库——特别是数据集市——与终端用户非常接近，它通常不具有固定的查询。因此，它必须更易于理解。
数据仓库应该是为数据分析而设计的。终端用户几乎直接处理数据，而且没有固定的工作流（除了这里和那里的少数例外）。终端用户对在仓库中记录数据不感兴趣，但他们需要从中获得信息。他们向仓库提出问题，通过所提取的信息测试并验证假设，重新构造事件链，分析那些事件以检测可能的模式或季节性的趋势，以及为将来做出推断和设计。
终端用户的需求可能是模糊或不完整的。这些不完整的需求需要灵活的建模过程和适合于进化开发的技术。灵活的进化软件开发的风险是不连贯和不一致的终端结果。在开发数据模型时，肯定需要注意这些问题。
数据仓库是集成的数据库集合，而非单个数据库。应将它构想为单个信息源，用于整个企业中所有的决策支持处理和所有的信息应用程序。数据仓库是一个“有机”物，如果在开始时还不够大，就还会趋于变大。
数据仓库包含属于不同信息主题领域的数据。这些主题领域可以是将数据仓库逻辑划分成几个不同（概念的，甚至或者是物理的）数据库的基础。数据仓库还可以包含不同类别的数据。
数据仓库通常包含历史数据，而不是日常操作数据的快照（snapshot）。必要的遗留数据库可能不可用，或者可能无法在足够细的层次上捕获，除非花费金钱并付出努力来改变遗留输入环境。因此，数据仓库启用项目通常涉及业务过程和源应用程序的重组（reengineering）。
两层数据仓库设计
如何进行数据仓库的建模可能是商业智能领域中最有争议的问题之一，而本文不会进行这方面的讨论