数据仓库和企业资源规划| DWH 和 ERP

档案 数据 中央：历史教育 进化

90 世纪 XNUMX 年代企业技术的两个主导主题是： 数据仓库 和企业资源规划。 长期以来，这两种强大的潮流一直是企业 IT 的一部分，但从未有过交集。 就好像它们是物质和反物质一样。 但这两种现象的发展不可避免地导致了它们的交叉。 如今，企业面临着如何使用 ERP 的问题 数据仓库。 本文将概述问题是什么以及公司如何解决这些问题。

在开始时…

一开始有 数据仓库. 数据仓库 是为了对抗事务处理应用系统而创建的。 早期的记忆 数据 它的目的只是与事务处理应用程序相对应。 但现在对于什么是“什么是”有更复杂的观点 数据仓库。 在当今世界 数据仓库 它被插入到一个可以称为“公司信息工厂”的结构中。

企业信息工厂 （CIF）

企业信息工厂具有标准的架构组件：一个转换和代码集成级别，集成了 数据 而我 数据 他们从应用环境转向了环境 数据仓库 该公司的; A 数据仓库 所在公司的 数据 详细而完整的历史。 这 数据仓库 公司的结构是构建环境所有其他部分的基础 数据仓库; 操作数据存储 (ODS)。 ODS 是一种混合结构，包含 数据仓库 以及 OLTP 环境的其他方面； 数据集市，不同部门可以拥有自己的版本 数据仓库; 一种 数据仓库 公司的“哲学家”可以在 72 小时内提交查询，而不会对公司造成有害影响。 数据仓库; 和近线存储器，其中 数据 老和 数据 可以廉价地存储大量细节。

ERP 与 LA 的结合 企业信息工厂

ERP 在两个地方与企业信息工厂合并。 首先作为基本应用程序（基线），提供我 数据 申请的 数据仓库。 在这种情况下我 数据作为交易过程的副产品生成，被集成并加载到 数据仓库 该公司的。 第二点ERP与CIF、ODS的结合点。 事实上，在许多环境中，ERP 被用作经典的 ODS。

如果使用 ERP 作为基本应用，则同样的 ERP 也可以作为 ODS 在 CIF 中使用。 无论如何，如果 ERP 要同时用于这两个角色，则两个实体之间必须有明确的区别。 也就是说，当ERP同时扮演核心应用和ODS的角色时，必须区分这两个架构实体。 如果单个 ERP 实施尝试同时履行这两个角色，那么该结构的设计和实施将不可避免地出现问题。

单独的 ODS 和基本应用

导致架构组件划分的原因有很多。 也许分离架构的不同组件最明显的问题是架构的每个组件都有自己的视图。 基线应用程序的用途与 ODS 不同。 尝试重叠

对 ODS 世界采用基线应用程序视图（反之亦然）并不是正确的工作方式。

因此，CIF中ERP的首要问题是验证基线应用程序和ODS之间是否存在区别。

企业中的数据模型 信息工厂

为了实现 CIF 架构不同组件之间的凝聚力，必须有一个模型 数据。 的型号 数据 它们充当架构的各个组件（例如基线应用程序和 ODS）之间的链接。 的型号 数据 它们成为从 CIF 的不同架构组件中获取正确含义的“知识路线图”。

与这一概念齐头并进的是，应该有一个大型且单一的模型 数据。 显然必须有一个模型 数据 对于每个组件，还必须有一条连接不同模型的合理路径。 架构的每个组件 – ODS、基线应用程序、 数据仓库 公司的情况等等.. – 需要自己的模型 数据。 因此必须对这些模型如何进行精确定义 数据 它们相互连接。

移动我 数据 ERP 的数据 仓库

如果原产地 数据 是基线应用程序和/或 ODS，当 ERP 插入 数据 在 数据仓库，这种插入必须发生在最低的“粒度”级别。 简单地总结或汇总我 数据 因为它们来自 ERP 基线应用程序或 ERP ODS 并不是正确的做法。 这 数据 需要详细信息 数据仓库 形成 DSS 流程的基础。 这样的 数据 数据集市和探索将在很多方面被重塑 数据仓库.

位移为 数据 从ERP基线应用环境到 数据仓库 公司的运作是以相当轻松的方式进行的。 此移动在 ERP 中更新或创建后大约 24 小时发生。 事实上，有一个“懒惰”的运动 数据 在 数据仓库 公司允许 数据 从 ERP 到“存款”。 有一次，我 数据 存储在基线应用程序中，然后您可以安全地移动 数据 ERP在企业中的应用。 由于“懒惰”运动，另一个目标得以实现 数据 它是运营流程和 DSS 之间的明确划分。 随着“快速”运动 数据 DSS 和运营之间的分界线仍然模糊。

伊尔·莫维门托·德伊 数据 从 ERP ODS 到 数据仓库 公司定期进行评估，通常是每周或每月。 在这种情况下，运动 数据 它是基于“清理”旧的需要 数据 历史学家。 当然，ODS 包含我 数据 比 数据 历史学家发现 数据仓库.

位移为 数据 在 数据仓库 它几乎从未进行过“批发”（以批发商的方式）。 将表从 ERP 环境复制到 数据仓库 它没有任何意义。 更现实的方法是移动选定的单位 数据。 只有我 数据 自上次更新以来已发生变化 数据仓库 他们是那些应该搬进的人 数据仓库。 知道哪些的一种方法 数据 自上次更新以来发生了变化是查看时间戳 数据 在ERP环境中发现。 设计者选择自上次更新以来发生的所有更改。 另一种方法是使用变更捕获技术 数据。 通过这些技术，可以对日志和日记磁带进行分析，以确定哪些是 数据 必须从 ERP 环境迁移到 数据仓库。 这些技术是最好的，因为可以从 ERP 文件读取日志和日记磁带，而不会进一步影响其他 ERP 资源。

其他并发症

CIF 中的 ERP 问题之一是其他应用程序源或应用程序会发生什么情况 数据 他们必须贡献的消耗臭氧层物质 数据仓库 但它们不是 ERP 环境的一部分。 鉴于 ERP（尤其是 SAP）的封闭性，尝试集成来自外部资源的密钥 数据 与 数据 移动时来自 ERP 数据 在 数据仓库，这是一个很大的挑战。 我的概率到底是多少 数据 ERP 环境之外的应用程序或 ODS 将集成到 数据仓库？ 实际上几率非常高。

寻找 数据 来自 ERP 的历史记录

我的另一个问题 数据 ERP 的本质是源于需要 数据 历史学家在 数据仓库。 通常情况下 数据仓库 他需要 数据 历史学家。 而ERP技术通常不存储这些 数据 历史性的，至少没有达到必要的程度 数据仓库。 当大量 数据 ERP 环境中的历史开始累积，该环境需要清理。 例如，假设一个 数据仓库 必须装载五年 数据 历史记录，而 ERP 最多保留六个月的这些信息 数据。 只要公司满意收集一系列 数据 随着时间的推移，历史学家认为使用 ERP 作为数据源是没有问题的。 数据仓库。 但当 数据仓库 他必须回到过去并找到诸神 数据 如果 ERP 之前没有收集和保存历史记录，那么 ERP 环境就会变得低效。

ERP 和元数据

关于 ERP e 需要考虑的另一个因素 数据仓库 是关于 ERP 环境中存在的元数据的元数据。 正如元数据从 ERP 环境流向 数据仓库，元数据必须以相同的方式移动。 此外，元数据必须转换为基础设施所需的格式和结构 数据仓库。 操作元数据和 DSS 元数据之间存在很大差异。 操作元数据主要针对开发人员和

程序员。 DSS 元数据主要面向最终用户。 ERP 应用程序或 ODS 中的现有元数据需要进行转换，而这种转换并不总是简单明了。

采购 ERP 数据

如果 ERP 被用作 数据 为 数据仓库 必须有一个坚固的界面来移动 数据 从ERP环境到环境 数据仓库。 该接口必须：

• ▪ 易于使用
• ▪ 允许访问 数据 ERP 的
• ▪ 取其含义 数据 即将被转移到 数据仓库
• ▪ 了解访问 ERP 时可能出现的限制 数据 ERP 的：
• ▪ 参照完整性
• ▪ 层级关系
• ▪ 隐含的逻辑关系
• ▪ 应用约定
• ▪ 所有结构 数据 由ERP支持，等等......
• ▪ 高效地访问 数据， 通过提供：
• ▪ 直接移动 数据
• ▪ 获得变更 数据
• ▪ 支持及时访问 数据
• ▪ 了解格式 数据， 等等… 与 SAP 接口 该接口可以有两种类型：自制的或商业的。 一些主要的交易界面包括：

• ▪ SAS
• ▪ 棱镜解决方案
• ▪ D2k 等... 多种 ERP 技术 将 ERP 环境视为单一技术是一个很大的错误。 ERP 技术有很多种，每种技术都有自己的优势。 市场上最知名的供应商是：

• ▪ SAP
• ▪ 甲骨文财务
• ▪ 仁科
• ▪ JD 爱德华兹
• ▪ 班恩 树液 SAP是最大、最完整的ERP软件。 SAP应用程序包括许多领域的多种类型的应用程序。 SAP 享有以下声誉：

• ▪ 非常大
• ▪ 实施起来非常困难且昂贵
• ▪ 需要许多人和顾问来实施
• ▪ 需要专门人员来实施
• ▪ 实施需要很长时间 此外，SAP 因能记住其 数据 非常小心，使得 SAP 领域之外的人很难访问它们。 SAP 的优势在于它能够捕获和存储大量数据 数据。 最近，SAP 宣布打算将其应用程序扩展到 数据仓库。 使用 SAP 作为供应商有很多优点和缺点 数据仓库。 一个优点是 SAP 已经安装并且大多数顾问已经了解 SAP。
  SAP 作为供应商的缺点 数据仓库 还有很多：SAP在世界范围内没有经验 数据仓库 如果 SAP 是 数据仓库，需要“取出”i 数据 从 SAP 到 数据仓库. 拿督 SAP 的封闭系统跟踪记录不太容易让我从 SAP 进入其中（？？？）。 有许多遗留环境为 SAP 提供支持，例如 IMS、VSAM、ADABAS、ORACLE、DB2 等。 SAP 坚持采用“并非此处发明”的方法。 SAP 不想与其他供应商合作使用或创建 数据仓库。 SAP 坚持自己开发所有软件。

SAP虽然是一家大而强的公司，却试图重写ELT、OLAP、系统管理甚至核心代码的技术。 数据库 这太疯狂了。 而不是与供应商采取合作的态度 数据仓库 长期以来，SAP 一直遵循“他们最了解”的方针。 这种态度阻碍了 SAP 在以下领域取得成功： 数据仓库.
SAP 拒绝允许外部供应商及时、优雅地访问其数据 数据。 使用的本质是 数据仓库 很容易访问 数据。 SAP的整个历史都是建立在让访问变得困难的基础上的 数据.
SAP缺乏处理大量数据的经验 数据; 在...方面 数据仓库 有大量的 数据 SAP 从未见过并管理这些大量的 数据 你需要有合适的技术。 SAP显然没有意识到进入该领域存在的这一技术障碍 数据仓库.
SAP 的企业文化：SAP 致力于获得成功 数据 从系统中。 但要做到这一点，你需要有不同的心态。 传统上，擅长将数据引入环境的软件公司并不擅长将数据传递到其他环境。 如果 SAP 成功实现这种类型的转变，它将成为第一家这样做的公司。

总之，企业是否应该选择SAP作为供应商是值得商榷的。 数据仓库。 一方面存在非常严重的风险，另一方面回报却很少。 但还有另一个原因阻碍选择 SAP 作为供应商 数据仓库。 因为每个公司都应该有相同的 数据仓库 所有其他公司的？ 这 数据仓库 这是竞争优势的核心。 如果每个公司都采用相同的 数据仓库 获得竞争优势虽然并非不可能，但却很困难。 SAP 似乎认为 数据仓库 它可以被视为 cookie，这是他们“获取数据”应用程序心态的进一步标志。

没有其他 ERP 供应商能像 SAP 那样占据主导地位。 毫无疑问，会有一些公司会追随 SAP 的道路。 数据仓库 但想必这些 数据仓库 SAP 的创建将非常庞大、昂贵且耗时。

这些环境包括银行柜员处理、航班预订流程、保险索赔流程等活动。 交易系统的性能越高，操作流程和 DSS（决策支持系统）之间分离的必要性就越明显。 然而，使用人力资源和人事系统，您永远不会面临大量交易。 当然，当一个人被雇用或离开公司时，这就是一笔交易的记录。 但相对于其他系统，HR和人事系统根本没有太多的事务。 因此，在人力资源和人事系统中，数据仓库的需求并不完全明显。 在许多方面，这些系统代表了 DSS 系统的合并。

但如果您正在处理数据仓库和 PeopleSoft，则还必须考虑另一个因素。 在许多环境中，我 数据 人力资源和个人资源相对于公司的主要业务来说是次要的。 大多数公司从事制造、销售、提供服务等。 人力资源和人事系统通常是次要的（或支持）公司的主要业务。 因此，这是模棱两可且不方便的 数据仓库 人力资源和人事支持分开。

PeopleSoft 在这方面与 SAP 有很大不同。 对于 SAP，必须有一个 数据仓库。 对于 PeopleSoft，情况就不那么清楚了。 PeopleSoft 可以选择数据仓库。

对我来说最好的事情是 数据 PeopleSoft 是 数据仓库 可用于存档 i 数据 与老年人力和个人资源有关。 公司想要使用的第二个原因 数据仓库 a

PeopleSoft 环境的不利之处在于允许访问和自由访问分析工具， 数据 由仁科公司提供。 但除了这些原因之外，在某些情况下，最好不要使用数据仓库 数据 仁科。

总结一下

关于建设的想法有很多 数据仓库 在 ERP 软件内。
其中一些是：

• ▪ 拥有一个 数据仓库 这就像行业中的其他事情一样吗？
• ▪ ERP 的灵活性如何 数据仓库 软件？
• ▪ ERP 数据仓库 软件可以处理大量 数据 它位于一个数据仓库 竞技场”？
• ▪ ERP 供应商在简单且廉价的情况下所做的跟踪记录是什么？ 数据？ （ERP 供应商在交付廉价、准时、易于访问的数据方面的记录如何？）
• ▪ ERP 供应商对DSS 架构和企业信息工厂的理解如何？
• ▪ ERP 供应商了解如何实现 数据 内环境，还了解如何导出它们？
• ▪ ERP 供应商对数据仓库工具的开放程度如何？
  在确定放置位置时必须考虑所有这些因素 数据仓库 它将接待我 数据 ERP 和其他 数据。 一般来说，除非有令人信服的理由不这样做，否则建议进行构建 数据仓库 ERP 供应商环境之外。 卡皮托洛1 BI组织概述要点：
  信息存储库的工作原理与商业智能 (BI) 架构相反：
  企业文化和 IT 可能会限制构建 BI 组织的成功。

技术不再是 BI 组织的限制因素。 建筑师和项目规划者面临的问题不是技术是否存在，而是他们是否能够有效地实施可用的技术。

对于许多公司来说 数据仓库 它只不过是一种被动存款，用于分配 数据 给有需要的用户。 这 数据 它们从源系统中提取并填充到目标结构中 数据仓库。 该 数据 如果运气好的话，它们也可以被清洁。 然而，没有增加或收集任何额外价值 数据 在此过程中。

本质上，被动 Dw 最多只能提供 i 数据 对用户协会来说是干净且可操作的。 信息创建和分析理解完全取决于用户。 判断是否DW(数据仓库）是否成功是主观的。 如果我们根据有效收集、整合和清理的能力来判断成功 数据 企业在可预测的基础上，那么是的，DW 是成功的。 另一方面，如果我们从整个组织对信息的收集、整合和利用的角度来看，那么数据仓库就是失败的。 DW 提供的信息价值很少甚至没有。 结果，用户被迫凑合，从而形成信息孤岛。 本章全面总结了公司的BI（商业智能）架构。 我们首先描述 BI，然后讨论信息设计和开发，而不是简单地提供信息。 数据 给用户。 然后讨论的重点是计算您的 BI 工作的价值。 最后，我们定义了 IBM 如何满足您组织的 BI 架构需求。

架构描述 商业智能组织

强大的面向交易的信息系统现在在每个大型企业中都很常见，有效地为世界各地的企业提供了公平的竞争环境。

然而，要保持竞争力，现在需要以分析为导向的系统，这些系统可以彻底改变公司重新发现和使用已拥有信息的能力。 这些分析系统源于对丰富性的理解 数据 可用的。 BI 可以提高整个企业的绩效。 公司可以改善客户与供应商关系、提高产品和服务的盈利能力、提供新的、更好的产品、控制风险以及大幅削减开支等许多其他收益。 借助具有市场目标的应用程序，您的公司终于开始使用 BI 将客户信息作为竞争资产。

拥有正确的业务工具意味着对关键问题有明确的答案，例如：

• ▪ 我们的哪一个 客户 它们是让我们赚更多钱，还是让我们赔钱？
• ▪ 我们最好的居住地 客户 和---关联 店/ 他们经常光顾的仓库？
• ▪ 我们的哪些产品和服务可以最有效地销售给谁？
• ▪ 哪些产品可以最有效地销售以及销售给谁？
• ▪ 哪种销售活动最成功？为什么？
• ▪ 哪些销售渠道对于哪些产品最有效？
• ▪ 我们如何改善与最优秀员工的关系 客户？ 大多数公司都有 数据 粗略地回答这些问题。
  操作系统产生大量的产品、客户和 数据 通过销售点、预订、客户服务和技术支持系统来开拓市场。 挑战在于提取和利用这些信息。 许多公司只从他们的一小部分中获利 数据 用于战略分析。
  I 数据 剩下的，经常和我一起 数据 从政府报告等外部来源以及其他购买的信息中获得的，是一个等待开发的金矿，并且 数据 它们只需要在您组织的信息环境中进行完善。

这些知识可以通过多种方式应用，从设计整体企业战略到与供应商的个人沟通，通过呼叫中心、发票、 网络 和其他要点。 当今的业务环境要求 DW 和相关 BI 解决方案的发展超越了运行传统的业务结构。 数据 哪个我 数据 在原子水平和“星/立方农场”上标准化。

要保持竞争力，就需要融合传统技术和先进技术，以支持广阔的分析领域。
总而言之，总体环境必须提高整个公司的知识，确保根据分析结果采取的行动是有用的，以便每个人都受益。

例如，假设您对自己的分类 客户 分为高风险或低风险类别。
如果此信息是通过模型挖掘或其他方式生成的，则必须将其放入 DW 中，并且任何人都可以通过任何访问工具（例如静态报告、电子表格、表格或在线分析处理 (OLAP)）来访问。

然而，目前大部分此类信息仍处于孤岛状态 数据 生成分析的个人或部门。 整个组织几乎没有可见性来理解。 只有将此类信息内容混合到企业数据仓库中，才能消除信息孤岛并提升数据仓库环境。
发展 BI 组织有两个主要障碍。
首先是组织本身及其纪律的问题。
虽然我们无法帮助组织策略更改，但我们可以帮助了解组织 BI 的组件、其架构以及 IBM 技术如何促进其开发。
要克服的第二个障碍是缺乏解决整个 BI 空间（而不是仅解决一个小组件）的方法的集成技术和知识。

IBM 正在努力应对集成技术的变化。 您有责任提供周到的设计。 这种架构必须使用选择用于无约束集成的技术来开发，或者至少使用遵守开放标准的技术。 此外，您的公司管理层必须确保 BI 工作按计划进行，并且不允许因自私议程或目标而产生信息孤岛。
这并不是说 BI 环境对不同用户的不同需求和要求的反应不敏感； 相反，这意味着这些个人需求和要求的实施是为了整个 BI 组织的利益。
BI 组织架构的描述可以在第 9 页的图 1.1 中找到。该架构展示了丰富的技术和技术组合。
从传统的角度来看，该架构包括以下仓库组件

原子层。

这是整个 DW 乃至战略报告的基础和核心。
I 数据 存储在这里将保留历史完整性、关系 数据 并包括派生指标，以及使用模型提取进行清理、集成和存储。
所有后续使用这些 数据 相关信息就是从这个结构中导出的。 这是挖矿的绝佳来源 数据 以及带有结构化 SQL 查询的报告

运营仓库 数据 或基于报告 数据（操作数据存储 (ODS) 或报告 数据库.)

这是一个结构 数据 专为技术报告而设计。

I 数据 在上面存储和报告的这些结构最终可以通过集结区域传播到仓库，在那里它可以用于战略信号发送。

暂存区。

大多数人的第一站 数据 用于仓库环境的是组织区域。
我在这 数据 它们被整合、清理并转化为 数据 将填充仓库结构的利润

数据集市。

这部分架构代表了以下结构 数据 专门用于 OLAP。 数据集市的存在，如果我 数据 存储在重叠的星型模式中 数据 关系环境中或文件中的多维 数据 特定 OLAP 技术（例如 DB2 OLAP Server）使用的机密是不相关的。

唯一的限制是该架构便于使用 数据 多维的。
该架构还包括关键的 Bi 技术和技术，这些技术和技术脱颖而出：

空间分析

空间对于分析师来说是一笔意外的信息，对于完全解决问题至关重要。 空间可以表示有关居住在某个位置的人的信息，以及有关该位置相对于世界其他地方的物理位置的信息。

要执行此分析，您必须首先将信息与纬度和经度坐标联系起来。 这称为“地理编码”，并且必须是仓库原子级别的提取、转换和加载 (ETL) 过程的一部分。

数据挖掘。

的提取 数据 使我们的公司能够增加数量 客户，预测销售趋势并允许管理与 客户 (客户关系管理），以及其他 BI 举措。

的提取 数据 因此，它必须与以下结构相结合： 数据 并由仓库流程支持，以确保相关技术和工艺的有效和高效利用。

正如 BI 架构所示，Dwhouse 的原子级别以及数据集市是一个极好的来源 数据 用于提取。 这些相同的设施也必须是提取结果的接收者，以确保最广泛的受众可用。

代理。

有各种“代理”来检查客户的每一点，例如公司的操作系统和数据仓库本身。 这些代理可以是经过训练的高级神经网络，可以了解每个点的趋势，例如基于促销的未来产品需求，基于规则的引擎对 拿督 一系列情况，甚至是向“高层管理人员”报告异常情况的简单代理人。 这些过程通常是实时发生的，因此必须与其运动紧密结合 数据。 所有这些结构 数据、技术和技巧保证您不会花一晚上的时间来生成您的 BI 组织。

这项活动将逐步开展，针对小点。
每个步骤都是一个独立的项目工作，在 DW 或 BI 计划中称为迭代。 迭代可以包括实施新技术、从新技术开始、添加新结构 数据 ，加载我 数据 额外的，或随着对您的环境的分析的扩展。 本段将在第 3 章中进行更深入的讨论。

除了传统的 DW 结构和 BI 工具之外，您还需要设计 BI 组织的其他功能，例如：

客户接触点（客户接触点） 点）。

与任何现代组织一样，有许多客户接触点表明如何为您带来积极的体验 客户。 有零售商、总机运营商、直邮、多媒体和印刷广告等传统渠道，也有电子邮件和网络等更流行的渠道， 数据 必须获取、运输、清洁、加工具有某些接触点的产品，然后在设施中进行填充 数据 商业智能的。

基础知识 数据 运营和用户协会（Operational

数据库和用户社区）。
在接触点的末端 客户 找到了基础 数据 公司的应用程序和用户社区。 这 数据 现有的是 数据 必须将传统的东西结合起来并与 数据 从接触点流出以满足必要的信息。

分析师。 （分析师）

BI 环境的主要受益者是分析师。 正是他从当前的开采中受益 数据 可操作，与不同来源集成 数据 ，增强了地理分析（地理编码）等功能，并以 BI 技术呈现，支持提取、OLAP、高级 SQL 报告和地理分析。 报告环境的主要分析师界面是 BI 门户。

然而，分析师并不是唯一从 BI 架构中受益的人。
管理者、大型用户协会、甚至会员、供应商等 客户 他们应该在企业 BI 中找到好处。

反馈回路。

BI 架构是一个学习环境。 发展的一个特征原则是允许持久的结构 数据 通过使用的 BI 技术和用户采取的操作进行更新。 一个例子是客户评分。

如果销售部门对客户评分进行建模以使用新服务，那么销售部门不应该是唯一从该服务中受益的群体。

相反，模型提取应该作为企业内数据流的自然部分来执行，并且客户评分应该成为仓库信息上下文的集成部分，对所有用户可见。 以 Bi-bI 为中心的 IBM 套件（包括 DB2 UDB、DB2 OLAP Server）包含大部分主要技术组件，如图 1.1 中定义。

我们使用书中该图所示的架构来为我们提供一定程度的连续性，并演示每个 IBM 产品如何融入整个 BI 方案。

提供信息内容（Providing 信息内容）

设计、开发和实施 BI 环境是一项艰巨的任务。 设计必须满足当前和未来的业务需求。 建筑图纸必须完整，以包含设计阶段发现的所有结论。 执行必须始终致力于单一目标：开发设计中正式呈现的 BI 架构并以业务需求为基础。

很难说纪律能够确保相对成功。
这很简单，因为您不会一次性开发出 BI 环境，而是随着时间的推移逐步完成。

然而，识别架构的 BI 组件很重要，原因有两个： 您将指导所有后续的技术架构决策。
您将能够有意识地计划技术的特定使用，即使您可能几个月都不会重复需要该技术。

充分了解您的业务需求将影响您为架构购买的产品类型。
设计和开发您的架构可确保您的仓​​库

这不是一个随机事件，而是一个精心构建的“深思熟虑”的事件。 歌剧 艺术作为混合技术的马赛克。

设计信息内容

所有初始设计都必须关注并确定当前和未来整体环境所需的关键 BI 组件。
了解业务需求很重要。

即使在任何正式设计开始之前，项目规划者通常也可以立即识别一两个组件。
然而，您的架构可能需要的组件的平衡并不容易找到。 在设计阶段，架构的主要部分将应用程序开发 (JAD) 会话与确定业务需求的任务联系起来。

有时，这些需求可以委托给查询和报告工具。
例如，用户表示，如果他们想要自动生成当前报告，则必须通过集成两个当前报告并添加从两个当前报告的组合中得出的计算来手动生成该报告。 数据.
尽管此要求很简单，但它定义了在为组织购买报告工具时必须包含的特定功能。

设计师还必须追求额外的要求才能获得完整的画面。 用户想要订阅此报告吗？
是否生成报告子集并通过电子邮件发送给各个用户？ 他们想在公司门户中看到此报告吗？ 所有这些要求都是根据用户的要求替换手动报告的简单需求的一部分。 这些类型的需求的好处是每个人（用户和设计者）都了解报告的概念。

然而，还有其他类型的业务需要我们进行规划。 当业务需求以战略业务问题的形式表述时，专家设计人员很容易辨别度量/事实和维度需求。

如果 JAD 用户不知道如何以业务问题的形式陈述他们的需求，设计人员通常会提供示例来启动需求收集会话。
专家设计师不仅可以帮助用户了解策略交易，还可以帮助用户了解如何形成策略交易。
第 3 章讨论了需求收集方法； 现在我们只想指出需要针对所有类型的 BI 需求进行设计。

战略性业务问题不仅是业务需求，也是设计线索。 如果你必须回答一个多维问题，那么你必须记住，呈现我 数据 维度，如果您需要存储 数据 多维的，你必须决定你要采用什么类型的技术或技巧。

您是否实施保留的立方星型模式，或两者都实施？ 正如您所看到的，即使是一个简单的业务问题也会对设计产生重大影响。 但这些类型的业务需求是常见的并且可以理解，至少对于具有项目经验的设计师和规划者来说是这样。

关于 OLAP 技术和支持已经有足够的讨论，并且有各种各样的解决方案可用。 到目前为止，我们已经提到需要将简单的报告与业务维度需求结合在一起，以及这些需求如何影响技术架构决策。

但哪些需求是用户或 Dw 团队不容易理解的？ 您需要空间分析吗？
的提取模型为 数据 它们会成为你未来的必要组成部分吗？ 谁知道？

值得注意的是，这些类型的技术并不为一般用户社区和 Dw 团队成员所熟知，部分原因可能是因为它们通常由一些内部或第三方技术专家处理。 这是此类技术产生的问题的一个极端例子。 如果用户无法描述业务需求或以向设计人员提供指导的方式构建业务需求，那么他们可能会被忽视，或者更糟糕的是，可能会被忽视。

当设计者和开发者无法认识到这些先进但关键技术之一的应用时，问题就变得更加严重。
正如我们经常听到设计师说的那样：“好吧，为什么我们不把它放在一边直到我们得到其他东西呢？ “他们真的对优先事项感兴趣，还是只是回避他们不理解的要求？ 这很可能是最后一个假设。 假设您的销售团队传达了一个业务需求，如图 1.3 所示，正如您所看到的，该需求以业务问题的形式构建。 该问题与典型的维度问题的区别在于距离。 在这种情况下，销售团队希望了解每月产品、仓库和库存的总销售额。 客户 居住在距其购买仓库 5 英里范围内的人。

可悲的是，设计师或建筑师可以简单地忽略空间组成部分，说：“我们有客户、产品和 数据 的存款。 让我们保持距离直到下一次迭代。

“错误的答案。 这类业务问题都与 BI 有关。 它代表了对我们业务的更深入了解，并为我们的分析师提供了强大的分析空间。 BI 不仅仅是简单的查询或标准报告，甚至是 OLAP。 这并不是说这些技术对您的 BI 不重要，但它们本身并不能代表 BI 环境。

信息环境设计 （针对信息内容进行设计）

现在我们已经确定了区分各种基本组件的业务需求，它们必须包含在整体架构设计中。 一些 BI 组件是我们最初工作的一部分，而另一些组件则需要几个月的时间才能实施。

然而，所有已知的要求都反映在设计中，因此当我们需要实现特定技术时，我们已做好准备。 该项目的某些内容将反映传统思维。

这一套 数据 用于支持后续使用 数据 以我们已确定的业务问题为指导的维度。 随着附加文档的生成，例如设计开发 数据，我们将开始正式化我如何 数据 它们在环境中传播。 我们已经确定需要代表我 数据 以维度的方式，将它们（根据具体的具体需求）划分为数据集市。

下一个要回答的问题是：这些数据集市将如何建设？
你建造星星来支撑立方体，还是仅仅建造立方体，或者仅仅建造星星？ （或正确的立方体，或正确的星星）。 为所有需要原子层的依赖数据集市生成架构 数据 获得？ 允许独立的数据集市获取我 数据 直接从操作系统？

您将尝试标准化哪种 Cube 技术？

你有大量的 数据 维度分析所需的数据，还是您需要每周从您的国家销售人员处获取立方体，还是两者都需要？ 您是否构建了像用于财务的 DB2 OLAP Server 或用于销售组织的 Cognos PowerPlay 多维数据集一样强大的东西，或者两者兼而有之？ 这些重大的架构设计决策将从现在开始影响您的 BI 环境。 是的，您已经确定了对 OLAP 的需求。 现在你将如何实施这种技术和技术？

一些最先进的技术如何影响您的设计？ 假设您已确定组织中的空间需求。 即使您几个月内不打算制作空间组件，您现在也必须回忆起建筑图纸版本。 建筑师今天必须根据需要进行设计。 预测对生成、存储、执行和提供访问的空间分析的需求 数据 空间。 这反过来应该成为您当前可以考虑的软件技术类型和平台规范的约束。 例如，管理系统 数据库 您为原子层执行的关系层 (RDBMS) 必须具有强大的可用空间范围。 这将确保在分析应用程序中使用几何和空间对象时获得最佳性能。 如果您的 RDBMS 无法处理 数据 （以空间为中心）内部，所以你必须建立一个 数据库 （以空间为中心）外部。 这使问题管理变得复杂并损害您的整体性能，更不用说为 DBA 带来的额外问题了，因为他们可能对 DBA 的基础知识了解甚少。 数据 空间也是如此。 另一方面，如果您的 RDMBS 引擎处理所有空间组件，并且其优化器了解空间对象的特殊需求（例如索引），那么您的 DBA 可以轻松处理问题的管理，并且可以最大限度地提高性能。

此外，您需要调整暂存区域和原子环境层以包括地址清理（a

空间分析的关键要素），以及随后的空间物体的保存。 既然我们引入了明确方向的概念，绘图版本的继承仍在继续。 一方面，该应用程序将决定您的 ETL 工作所需的软件类型。

您是否需要 Trillium 等产品为其提供干净的地址，或者您选择的 ETL 供应商来提供该功能？
目前，重要的是您要了解在开始实施仓库之前必须完成的设计水平。 上面的示例应该演示必须遵循任何特定业务需求的识别的众多设计决策。 如果正确，这些设计决策会促进环境的物理结构、所使用的技术的选择以及信息内容的传播流之间的相互依赖性。 如果没有这种传统的 BI 架构，您的组织将受到现有技术的混乱组合的影响，最多松散地缝合在一起以提供明显的稳定性。

维护信息内容

为您的组织带来信息的价值是一项非常艰巨的任务。 如果没有足够的理解和经验，或者没有适当的规划和设计，即使是最好的团队也会失败。 另一方面，如果你有很好的直觉和详细的计划，但没有执行纪律，那么你只是在浪费你的金钱和时间，因为你的努力注定会失败。 信息应该很明确：如果您缺乏其中一项或多项技能、理解/经验或规划/设计或实施纪律，它将削弱或破坏 BI 组织的建设。

您的团队准备充分吗？ 您的 BI 团队中是否有人了解 BI 环境中可用的庞大分析环境以及维护该环境所需的技巧和技术？ 您的团队中是否有人能够认识到高级应用程序与高级应用程序之间的差异

静态报表和OLAP，或者ROLAP和OLAP之间的区别？ 您的团队成员之一是否清楚地认识到如何提取以及它可能如何影响仓库或仓库如何支持提取性能？ 团队成员了解的价值 数据 空间还是基于代理的技术？ 您是否有人欣赏 ETL 工具相对于消息代理技术的独特应用？ 如果你没有，那就买一个。 BI 比规范化原子层、OLAP、星型模式和 ODS 大得多。

拥有识别 BI 需求及其解决方案的理解和经验对于您正确形式化用户需求以及设计和实施其解决方案的能力至关重要。 如果您的用户社区难以描述需求，那么仓库团队的工作就是提供这种理解。 但如果仓库团队

如果不认识 BI 的具体应用（例如数据挖掘），那么 BI 环境通常仅限于被动存储库并不是最好的事情。 然而，忽略这些技术并不会降低它们的重要性以及它们对组织商业智能能力的出现以及您计划培育的信息环境的影响。

规划必须包括绘图的概念，两者都需要有能力的个人。 此外，设计需要团队仓库理念并遵守标准。 例如，如果您的公司已经建立了一个标准平台，或者已经确定了您想要在整个平台上标准化的特定 RDBMS，那么团队中的每个人都有责任遵守这些标准。 通常，团队（向用户社区）公开标准化的需求，但团队本身不愿意遵守公司其他领域甚至类似公司也建立的标准。 这不仅是虚伪的，而且表明该公司没有能力利用现有资源和投资。 这并不意味着不存在需要非标准化平台或技术的情况； 然而，仓库的努力

他们应该小心翼翼地捍卫企业的标准，直到业务要求另有规定为止。

建立 BI 组织所需的第三个关键要素是纪律。
这完全取决于个人和环境。 项目规划者、发起人、架构师和用户必须了解构建公司信息环境所需的纪律。 设计师必须以补充社会其他必要努力的方式指导他们的设计工作。

例如，假设您的公司构建了一个具有仓库组件的 ERP 应用程序。
因此，ERP 设计人员有责任与仓库环境团队合作，以免竞争或重复已经开始的工作。

纪律也是整个组织必须解决的主题，通常由执行层制定并委托给管理层。
管理者是否愿意遵守设计好的方法？ 一种承诺创建最终将为企业所有领域带来价值的信息内容的方法，但可能会损害个人或部门的议程？ 请记住这句话：“考虑所有事情比只考虑一件事更重要”。 这句话对于 BI 组织来说是正确的。

不幸的是，许多仓库将精力集中在试图瞄准特定部门或特定用户并为其带来价值，而很少考虑整个组织。 假设主管请求仓库团队提供帮助。 团队在 90 天的时间内做出响应，不仅包括交付经理定义的通知要求，还包括确保所有 数据 在被引入所提出的立方体技术之前，碱基在原子水平上混合。
这项工程的增加确保了仓库企业将从中受益 数据 对于经理来说是必要的。
然而，该高管与外部咨询公司进行了交谈，后者提出了类似的申请，并在不到 4 周的时间内交付。

假设内部仓库团队有能力，那么高管就有选择。 谁可以支持培养信息资产企业所需的额外工程学科，或者可以选择快速构建自己的解决方案。 最后一种似乎被频繁选择，并且只能用于创建只对少数人或个人有利的信息容器。

短期和长期目标

架构师和项目设计师必须正式制定 BI 组织整体架构的长期愿景和发展计划。 这种短期收益和长期规划的结合代表了 BI 工作的两个方面。 短期收益是 BI 的一个方面，与仓库的迭代相关。

这是规划者、建筑师和赞助商专注于满足特定商业需求的地方。 正是在这个层面上建造了物理结构、购买了技术并实施了技术。 它们绝不是为了满足特定用户社区定义的特定要求而设计的。 所做的一切都是为了满足特定社区定义的特定要求。
然而，长期规划是 BI 的另一个方面。 规划和设计确保任何物理结构的建造、技术的选择和实施都着眼于企业。 长期规划提供了所需的凝聚力，以确保从任何短期收益中产生商业利益。

证明您的 BI 工作的合理性

Un 数据仓库 它本身没有内在价值。 换句话说，仓库技术和实现技术之间没有内在的价值。

任何仓库工作的价值都可以在仓库环境和随着时间的推移培养的信息内容所执行的操作中找到。 在尝试估计任何房屋计划的价值之前，这是需要理解的关键点。

很多时候，建筑师和设计师试图将价值应用于仓库的物理和技术组件，而事实上，该价值是基于受到仓库和良好获取的信息积极影响的业务流程。

建立 BI 的挑战在于：如何证明投资的合理性？ 如果仓库本身没有内在价值，项目设计者必须调查、定义和形式化那些将使用仓库来改进特定业务流程或受保护信息的价值或两者兼而有之的个人所获得的利益。

让事情变得复杂的是，任何受仓储工作影响的业务流程都可能提供“相当大”或“轻微”的好处。 相当大的好处提供了衡量投资回报 (ROI) 的切实指标，例如，在特定时期内延长库存周转时间或降低每次发货的运输成本。 很难用有形价值来定义微妙的好处，例如更好地获取信息。

连接您的项目以了解 业务请求

项目规划者常常试图将仓库价值与无形的企业目标联系起来。 通过宣称“仓库的价值取决于我们满足战略要求的能力”，我们以愉快的方式开始了讨论。 但仅凭这一点还不足以确定库存投资是否有意义。 最好将仓库迭代与特定的已知业务需求联系起来。

衡量投资回报率

计算仓库环境中的投资回报率可能特别困难。 如果有优势的话，那就特别困难了

特定重复的原则是一些无形的或不易测量的东西。 一项研究发现，用户认为 BI 计划有两个主要好处：

• ▪ 培养制定决策的能力
• ▪ 创建信息访问权限
  这些好处是软（或温和）好处。 很容易看出我们如何根据硬（或主要）效益（例如降低运输成本）来计算投资回报率，但我们如何衡量做出更好决策的能力呢？
  当项目规划者试图说服公司投资特定的仓库工作时，这绝对是一个挑战。 增加销售额或降低成本不再是推动 BI 环境的中心主题。
  相反，您正在考虑更好地访问信息的业务请求，以便特定部门可以更快地做出决策。 这些战略驱动因素恰好对企业同样重要，但更加模糊，更难以用有形的指标来描述。 在这种情况下，计算投资回报率即使不是无关紧要，也可能会产生误导。
  项目规划者必须能够向高管展示有形价值，以决定特定迭代的投资是否值得。 但是，我们不会提出计算投资回报率的新方法，也不会提出任何支持或反对的论据。
  有许多文章和书籍讨论计算投资回报率的基础知识。 您可以研究一些特殊的价值主张，例如 Gartner 等组织提供的投资价值 (VOI)。 相反，我们将专注于您需要考虑的任何投资回报率或其他价值主张的核心方面。 应用投资回报率 除了关于与 BI 工作相关的“硬”收益与“软”收益的争论之外，在应用 ROI 时还需要考虑其他问题。 例如：

将太多的节省归因于 DW 的努力，但无论如何都会实现
假设您的公司从大型机架构迁移到分布式 UNIX 环境。 因此，通过该努力可能（或可能不会）实现的任何节省不应完全归因于仓库（如果有的话）。

不考虑所有事情的代价是高昂的。 还有很多事情需要考虑。 考虑以下列表：

• ▪ 启动成本，包括可行性。
• ▪ 具有相关存储和通信功能的专用硬件的成本
• ▪ 软件成本，包括管理成本 数据 和客户端/服务器扩展、ETL 软件、DSS 技术、可视化工具、调度和工作流应用程序以及监控软件，.
• ▪ 结构设计成本 数据，随着创建和优化
• ▪ 与 BI 工作直接相关的软件开发成本
• ▪ 现场支持成本，包括性能优化，包括软件版本控制和帮助操作 应用“大爆炸”投资回报率。 将仓库构建为单一的、巨大的工作注定会失败，因此，即使计算大型企业计划的投资回报率，其报价也是令人惊讶的，规划人员继续做出无力的尝试来估计整个工作的价值。 如果人们普遍知道并接受估计具体的重复是困难的，那么为什么规划者还要试图对业务计划赋予货币价值呢？ 这怎么可能？ 除了少数例外，这是不可能的。 不要这样做。 现在我们已经确定了计算 ROI 时不应该做的事情，以下几点将帮助我们建立可靠的流程来评估 BI 工作的价值。

获得投资回报率共识。 无论您选择哪种技术来评估 BI 工作的价值，都必须得到各方（包括项目设计者、发起人和业务主管）的同意。

将投资回报率降低到可识别的部分。 合理计算投资回报率的必要步骤是将计算重点放在特定项目上。 然后，您可以根据满足的特定业务需求来估计值

定义成本。 如前所述，必须考虑大量成本。 此外，成本不仅必须包括与单次迭代相关的成本，还必须包括与确保符合企业标准相关的成本。

定义好处。 通过将投资回报率与特定业务需求明确联系起来，我们应该能够确定满足需求所带来的好处。

降低成本，效益迫在眉睫。 这是根据净现值 (NPV) 进行估值的最佳方式，而不是试图预测未来收益的未来价值。

将分割投资回报率的时间控制在最低限度。 它在您的投资回报率中长期使用，并有详细记录。

使用多个 ROI 公式。 预测 ROI 的方法有很多种，您应该计划是否使用其中的一种或多种，​​包括净现值、内部收益率 (IRR) 和投资回收期。

定义可重复的过程。 这对于计算任何长期价值至关重要。 应记录一个可重复的过程，以供所有项目后续遵循。

列出的问题是专家在仓库环境中定义的最常见问题。 管理层坚持提供“大爆炸式”投资回报率，这令人非常困惑。 如果您通过将所有投资回报率分解为可识别的、有形的部分来开始计算，那么您很有可能估算出准确的投资回报率评级。

有关投资回报率收益的问题

无论您的福利是什么，无论是软福利还是硬福利，您都可以使用一些基本问题来确定其价值。 例如，使用简单的缩放系统（从 1 到 10），您可以通过使用以下问题来衡量任何工作的影响：

• 您如何评价对以下内容的理解 数据 关注贵公司的这个项目吗？
• 您如何估计该项目带来的流程改进？
• 您将如何衡量本次迭代现在提供的新见解和推论的影响
• 根据所学到的知识，新的高性能计算环境会产生什么影响？ 如果这些问题的答案很少，那么该公司可能不值得进行投资。 高分问题表明价值显着增加，应作为进一步调查的指南。 例如，流程改进的高分应该引导设计人员检查流程是如何改进的。 您可能会发现所获得的部分或全部收益是有形的，因此可以轻松应用货币价值。 充分利用第一次迭代 仓库 企业努力的最大成果通常是在最初的几次迭代中。 这些早期的努力传统上为公众建立了最有用的信息内容，并帮助为后续的 BI 应用奠定了技术基础。 通常每个后续子序列 数据 仓库项目为企业整体带来的附加价值越来越少。 如果迭代没有添加新主题或满足新用户社区的需求，则尤其如此。

此存储功能也适用于不断增长的堆栈 数据 历史学家。 由于后续的努力需要更多 数据 还有更多 数据 随着时间的推移，大部分都被倒入仓库 数据 与所使用的分析变得不太相关。 这些 数据 他们经常被称为 数据 处于休眠状态，并且保持它们总是很昂贵，因为它们几乎从未被使用过。

这对项目发起人意味着什么？ 从本质上讲，早期赞助商分担的费用超出了投资成本。 这是主要的，因为它们是建立仓库广泛的技术和资源环境层（包括有机）的动力。

但这些第一步会带来最高的价值，因此项目设计者通常必须证明投资的合理性。
在 BI 计划之后完成的项目可能具有较低的直接成本（与第一个相比），但为公司带来的价值较少。

组织所有者需要开始考虑扔掉积累的东西 数据 以及不太相关的技术。

数据挖掘：提取 给

许多架构组件需要不同的数据挖掘技术和技术——
例如，用于检查兴趣点的不同“代理” 客户，该公司的操作系统和 dw 本身。 这些代理可以是根据 POT 趋势进行训练的高级神经网络，例如基于促销的未来产品需求； 基于规则的引擎对一组做出反应 拿督 情况，例如医疗诊断和治疗建议； 甚至是负责向高层管理人员报告异常情况的简单代理。 一般这些提取过程 数据 si

实时验证； 因此，他们必须与运动完全结合起来。 数据 斯特西。

在线分析处理 处理

在线分析

切片、切块、滚动、向下钻取和执行分析的能力
假设分析属于 IBM 技术套件的重点范围。 例如，DB2 存在在线分析处理 (OLAP) 功能，它将维度分析引入到软件引擎中。 数据库 相同的 。

这些函数向 SQL 添加维度实用程序，同时利用作为 DB2 自然组成部分的所有优势。 OLAP 集成的另一个例子是提取工具，DB2 OLAP Server Analyzer。 该技术允许快速、自动地分析 DB2 OLAP Server 多维数据集，以定位和报告值 数据 对于业务分析师来说，整个立方体是不寻常或意外的。 最后，DW Center 特性为架构师提供了一种方法来控制 DB2 OLAP 服务器多维数据集的配置文件，作为 ETL 过程的自然组成部分。

空间分析 空间分析

空间代表全景图所需分析锚点（线索）的一半
分析广泛（时间代表另一半）。 如图 1.1 所示，仓库的原子级包括时间和空间基础。 时间戳按时间进行锚定分析，地址信息按空间进行锚定分析。 时间戳按时间进行分析，地址信息按空间进行分析。 该图显示了地理编码 - 将地址转换为地图中的点或空间中的点的过程，以便在分析中使用距离和内部/外部等概念 - 在原子级别进行，以及可用于的空间分析分析师。 IBM 提供与环境系统研究所 (ESRI) 共同开发的空间扩展，以 数据库 DB2 使空间对象可以作为普通对象的一部分进行存储 数据库 相关的。 数据库2

Spatial Extenders 还提供所有 SQL 扩展以利用空间分析。 例如，用于查询的 SQL 扩展
地址之间的距离或点是否位于定义的多边形区域内部或外部，是 Spatial Extender 的分析标准。 更多信息请参见第 16 章。

数据库- 常驻工具工具 数据库-居民

DB2 具有许多 BI 驻留 SQL 功能，可帮助执行分析操作。 这些包括：

• 用于执行分析的递归函数，例如“查找所有可能的飞行路径” 旧金山 a 纽约“。
• 用于排序、累积函数、立方体和汇总的分析函数可促进通常仅在 OLAP 技术中执行的任务，现在已成为引擎的自然组成部分 数据库
• 能够创建包含结果的表
  我买东西 数据库 领导者将更多 BI 功能融入到 数据库 相同的。
  主要供应商 数据库 他们正在将更多的 BI 功能融入到 数据库 相同的。
  这为 BI 解决方案提供了更好的性能和更多的执行选项。
  DB2 V8 的特性和功能将在以下章节中详细讨论：
  技术架构和数据管理基础（第 5 章）

• DB2 BI 基础知识（第 6 章）
• DB2 物化查询表（第 7 章）
• DB2 OLAP 函数（第 13 章）
• DB2 增强型 BI 特性和功能（第 15 章） 简化的数据传输系统 输送系统 数据 简

图1.1中描述的架构包括许多结构 数据 身体的。 其一是仓库 数据 操作。 一般来说，ODS是一个面向主题的、集成的、当前的对象。 例如，您将构建一个 ODS 来支持销售办公室。 ODS 销售将补充 数据 来自许多不同的系统，但只会保留例如今天的交易。 ODS 还可以每天更新多次。 与此同时，这些进程推动 数据 集成到其他应用程序中。 该结构专门设计用于集成 数据 当前和动态，并且可能是支持实时分析的候选者，例如提供给服务代理 客户 通过从仓库本身提取销售趋势信息来获取客户当前的销售信息。 图 1.1 所示的另一个结构是 dw 的形式状态。 这不仅是执行必要集成的地方，而且还保证了集成的质量 数据，以及转变的 数据 的进货仓库，但它也是可靠的临时存储区域 数据 可用于实时分析的重复。 如果您决定使用 ODS 或暂存区，这是填充这些结构的最佳工具之一 数据 使用不同的操作源就是DB2的异构分布式查询。 此功能由称为 DB2 Relational Connect（仅查询）的可选 DB2 功能和 DB2 DataJoiner（一个单独的产品，为异构分布式 RDBMS 提供查询、插入、更新和删除功能）提供。

这项技术使建筑师能够 数据 打结 数据 通过分析过程进行生产。 该技术不仅可以适应实时分析可能​​出现的几乎任何复制需求，而且还可以连接到各种数据库 数据 最流行的包括 DB2、Oracle、Sybase、SQL Server、Informix 等。 DB2 DataJoiner 可用于填充结构 数据 正式作为 ODS，甚至是仓库中代表的永久表，旨在快速恢复即时更新或用于销售。 当然，这些相同的结构 数据 可以使用填充

另一项旨在复制的重要技术 数据，IBM DataPropagator 关系。 （DataPropagator 是中央系统的独立产品。DB2 UNIX、Linux、Windows 和 OS/2 包括数据复制服务 数据 作为标准功能）。
另一种移动方法 数据 在企业周围运行的是企业应用程序集成商，也称为消息代理。这种独特的技术可以对定位和移动进行无与伦比的控制 数据 公司周边。 IBM 拥有使用最广泛的消息代理 MQSeries 或该产品的变体，其中包括以下要求： 电子商务行业、IBM WebSphere MQ。
Per più discussione su come sfruttare MQ per sostenere un magazzino e un ambiente BI, visitare 网站 del libro. Per ora, è sufficiente dire che questa tecnologia è un mezzo eccellente per catturare e trasformare (utilizzando MQSeries Integrator) 数据 为 BI 解决方案招募集中（有针对性）的操作员。 MQ 技术已集成并打包到 UDB V8 中，这意味着现在可以像管理 DB2 表一样管理消息队列。 焊接排队消息的概念和宇宙 数据库 关系走向强大的交付环境 数据.

零延迟 零延迟

IBM 的最终战略目标是零延迟分析。 定义为
Gartner认为，BI系统必须能够推断、吸收并向分析师按需提供信息。 当然，挑战在于如何混合 数据 当前和实时的，具有必要的历史信息，例如我 数据 相关模式/趋势，或提取的理解，例如客户分析。

此类信息包括，例如，身份识别 客户 高风险或低风险或我选择哪些产品 客户 如果他们的购物车中已有奶酪，他们很可能会购买。

实现零延迟实际上取决于两个基本机制：

• 完全联合 数据 使用 BI 创建的既定技术和工具进行分析
• 一个输送系统 数据 高效确保实时分析真正可用 这些零延迟的先决条件与 IBM 设定的和上述的两个目标没有什么不同。 的近距离交配 数据 它是 IBM 无缝集成计划的一部分。 并创建一个交付系统 数据 效率完全取决于简化交付过程的可用技术 数据。 因此，IBM 的三个目标中的两个对于实现第三个目标至关重要。 IBM 正在有意识地发展其技术，以确保仓库工作实现零延迟。 总结/综合 BI 组织提供了构建环境的路线图
  迭代地。 必须对其进行调整以反映您当前和未来的业务需求。 如果没有广泛的架构愿景，仓库迭代只不过是中央仓库的随意实现，对于创建一个广泛的、信息丰富的企业几乎没有什么作用。 项目经理面临的第一个障碍是如何证明开发 BI 组织所需的投资的合理性。 虽然投资回报率计算仍然是仓库实施的支柱，但准确预测变得越来越困难。 这催生了其他方法来确定您的钱是否物有所值。 例如，投资价值2 (VOI) 被作为一种解决方案进行推广。 这是建筑师的责任 数据 项目规划者有意生成并向用户协会提供信息，而不是简单地向他们提供服务 数据。 两者之间存在巨大差异。 信息可以影响决策和有效性； 相对而言，我 数据 它们是获取这些信息的基础。

即使我对来源持批评态度 数据 为了满足业务请求，BI 环境应该在创建信息内容方面发挥更大的作用。 我们必须采取额外的步骤来清理、集成、转换或以其他方式创建用户可以采取行动的信息内容，然后我们必须确保这些合理的行动和决策反映在 BI 环境中。 如果我们将仓库降级为仅服务于 数据，确保用户协会将创建采取行动所需的信息内容。 这确保了他们的社区能够做出更好的决策，但企业却因缺乏他们所使用的知识而受到困扰。 拿督 当架构师和项目规划人员在 BI 环境中启动特定项目时，他们仍然对整个企业负责。 BI 迭代的这种双面特征的一个简单示例可以在源代码中找到 数据。 所有 数据 收到的特定业务请求必须填充在第一个原子层中。 这确保了企业信息资产的开发，以及管理、解决迭代中定义的特定用户请求。

什么是数据仓库？

数据仓库 自 1990 年以来，它一直是信息系统架构的核心，并通过提供可靠的集成平台来支持信息流程 数据 历史数据作为后续分析的基础。 这 数据仓库 它们可以轻松地集成到不兼容的应用程序系统的世界中。 数据仓库 它已经演变成一种趋势。 数据仓库 组织和存储我 数据 基于长期历史时间视角的信息和分析过程是必要的。 所有这一切都需要对建设和维护进行大量和持续的承诺 数据仓库.

那么什么是 数据仓库？ 一 数据仓库 是：

• ▪ 主题导向
• ▪ 集成系统
• ▪ 不同时间
• ▪ 非易失性（无法擦除）

的集合 数据 用于支持流程实施中的管理决策。
I 数据 插入 数据仓库 在大多数情况下，它们源自操作环境。 这 数据仓库 它是由一个存储单元创建的，该存储单元在物理上与系统的其余部分分开，其中包含 数据 以前是由对源自操作环境的信息进行操作的应用程序进行转换的。

a 的字面定义 数据仓库 值得深入解释，因为描述仓库的特征有重要的动机和潜在含义。

学科方向 方向 专题

a的第一个特征是 数据仓库 是它面向公司的主要参与者。 试验指南 数据 它与更经典的方法形成鲜明对比，后者涉及将应用程序面向流程和功能，这是大多数较新的管理系统所共享的方法。

操作世界是围绕金融机构的贷款、储蓄、银行卡和信托等应用程序和功能而设计的。 dw 的世界是围绕客户、卖家、产品和活动等主要主题组织的。 围绕主题的协调会影响设计和实施 数据 在dw里找到的。 更重要的是，主题影响关键结构中最重要的部分。

应用程序的世界受到数据库设计和流程设计的影响。 dw 的世界专注于建模 数据 以及关于设计的 数据库。 流程设计（以其经典形式）不是 dw 环境的一部分。

过程/功能应用的选择和主题的选择之间的差异也表现为研究内容的差异。 数据 在详细的层面上。 这 数据 dw 的不包括 i 数据 申请时不会用于 DSS 流程

运营导向 数据 包含我 数据 立即满足对 DSS 分析师可能有用也可能没有用的功能/处理要求。
面向运营的应用程序的另一个重要方式 数据 与......不同 数据 德国之声在 dei 报告中 数据。 该 数据 操作根据活动的业务规则维护两个或多个表之间的连续关系。 这 数据 数据仓库的数据跨越了一个时间范围，数据仓库中发现的关系有很多。 许多交易规则（以及相应的许多关系） 数据 ) 代表在仓库中 数据 两个或多个表之间。

（有关如何详细解释之间的关系 数据 是在 DW 中处理的，我们参考有关该问题的技术主题。）
除了功能/流程应用程序选择和主题选择之间的根本区别之外，从其他角度来看，操作系统和应用程序之间是否存在更大的区别？ 数据 和德国之声。

整合 整合

dw环境最重要的一点是我 数据 在 dw 中发现很容易集成。 总是。 无一例外。 dw 环境的本质是我 数据 包含在仓库限制内的内容是集成的。

整合以多种不同的方式展现出来——一致的识别约定、一致的变量测量、一致的编码结构、物理属性 数据 一致，等等。

多年来，各种应用程序的设计者就如何开发应用程序做出了许多决定。 设计者的应用程序的风格和个性化设计决策以一百种方式展现出来：编码、关键结构、物理特征、识别约定等方面的差异。 许多应用程序设计人员创建不一致应用程序的集体能力是传奇的。 图 3 列出了应用程序设计方式中的一些最重要的差异。

编码： 编码：

应用程序设计者以不同的方式选择了性别领域的编码。 设计师将性别表示为“m”和“f”。 另一位设计师将性别表示为“1”和“0”。 另一位设计师将性别表示为“x”和“y”。 另一位设计师将性别描述为“男性”和“女性”。 性别如何进入 DW 并不重要。 “M”和“F”可能和整部剧一样好。

重要的是，无论性场源自何处，该场都会以一致的整合状态到达 DW。 因此，当字段从以“M”和“F”格式表示的应用程序加载到 DW 时， 数据 必须转换为DW格式。

属性的测量：测量 属性：

多年来，应用程序设计人员选择了多种方式来测量管道。 设计师存储 数据 管道的长度（以厘米为单位）。 另一位应用程序设计者存储 数据 管道的英寸数。 另一位应用程序设计者存储 数据 管道流量（百万立方英尺每秒）。 另一位设计师以码数存储管道信息。 无论来源如何，当管道信息到达 DW 时，都必须以相同的方式进行测量。

根据图 3 所示，集成问题几乎影响到项目的各个方面——物理特性 数据，拥有多个来源的困境 数据、识别样本、格式不一致的问题 数据 不一致等。

无论设计主题是什么，结果都是一样的 – i 数据 必须以单一且全局可接受的方式存储在 DW 中，即使底层操作系统以不同方式存储它们 数据.

当 DSS 分析师查看 DW 时，分析师的目标应该是利用 数据 那些在仓库里的，

而不是怀疑其可信度或一致性 数据.

时间差异

所有 数据 在 DW 中，它们在某个时间点是准确的。 这一基本特征 数据 在DW中它与那些有很大不同 数据 运行环境中发现。 这 数据 操作环境的信息与访问时一样精确。 换句话说，在访问驱动器时的操作环境中 数据，预计它将反映访问时的精确值。 因为我 数据 在 DW 中，精确到某个时间点（即，不是“现在”），据说我 数据 在 DW 中发现的是“时间方差”。
时间方差为 数据 by DW 有多种方式被提及。
最简单的方法是我 数据 DW 的代表 数据 长期来看——五到十年。 操作环境所代表的时间范围比当今的当前值短得多，最多六十九分钟
必须运行良好且可用于事务处理的应用程序必须携带最低数量的 数据 如果他们允许任何程度的灵活性。 因此，操作应用程序的时间范围很短，就像音频应用程序设计主题一样。
“时间方差”在 DW 中出现的第二种方式是在关键结构中。 DW 中的每个关键结构都隐式或显式地包含一个时间元素，例如日、周、月等。 时间元素几乎总是位于 DW 中串联键的底部。 在这些情况下，时间元素将隐式存在，例如在月末或季度末复制整个文件的情况。
显示时间方差的第三种方式是 i 数据 DW 的信息一旦正确注册，就无法更新。 这 数据 出于所有实际目的，DW 的内容是一长串快照。 当然，如果快照拍摄不正确，则可以修改快照。 但假设快照正确拍摄，它们不会在拍摄后立即被修改。 在一些

在某些情况下，修改数据仓库中的快照可能是不道德的，甚至是无效的。 这 数据 可操作，在访问时精确，可以根据需要进行更新。

非挥发性

DW的第四个重要特性是它是非易失性的。
逐条记录地定期对操作环境进行更新、插入、删除和修改。 但基本的操控 数据 DW 中需要的就简单多了。 DW中只发生两种操作——初始加载 数据 并访问 数据。 没有更新 数据 （一般意义上的更新）在DW中作为正常的处理操作。 操作处理和 DW 处理之间的这种基本差异会产生一些非常重要的后果。 在设计层面，需要谨慎对待异常更新并不是DW的一个因素，因为 数据 没有进行。 这意味着在物理设计层面，可以自由地优化对 数据，特别是在处理物理规范化和非规范化主题时。 DW 操作简单性的另一个结果是用于运行 DW 环境的底层技术。 必须支持内联逐条记录更新（操作处理中经常出现这种情况）要求该技术在看似简单的情况下拥有非常复杂的基础。
支持备份和恢复、事务和完整性的技术 数据 死锁情况的检测和修复相当复杂，对于DW处理来说不是必需的。 DW的特点、设计导向、集成 数据 在 DW 内，时间差异和管理简单性 数据，这一切都导致了一个与经典操作环境非常非常不同的环境。 几乎所有的来源 数据 的DW是运行环境。 人们很容易认为存在大量冗余 数据 两个环境之间。
其实很多人的第一印象就是冗余度很大 数据 运行环境和环境之间

DW。 这种解释是肤浅的，表明对 DW 中发生的事情缺乏了解。
事实上有最小的冗余 数据 操作环境和我之间 数据 DW 的。 考虑以下几点：我 数据 他们被过滤了 拿督 从运行环境切换到DW环境。 许多 数据 它们永远不会超出操作环境。 除了我 数据 DSS 处理所需的信息在环境中找到方向

▪ 时间范围 数据 一种环境与另一种环境有很大不同。 这 数据 在操作环境上他们都很新鲜。 这 数据 在德国之声，他们的年龄要大得多。 仅从时间范围来看，作战环境与数据仓库之间几乎没有重叠。

▪ DW 包含 数据 摘要在环境中从未发现过

▪ 我 数据 当它们过渡到图 3 时，它们经历了根本性的转变，这表明大多数 数据 如果它们被选择并移动到 DW，则会进行重大修改。 换句话说，大多数 数据 当它被移入数据仓库时，它在物理上发生了根本性的改变。 从集成的角度来看，它们并不相同 数据 驻留在操作环境中。 考虑到这些因素，冗余 数据 两个环境之间的冗余是罕见事件，导致两个环境之间的冗余度低于 1%。 仓库结构 DW 具有独特的结构。 有不同级别的摘要和详细信息来划分 DW。
DW 的各个组件是：

• 元数据
• 给 当前详细信息
• 给 旧细节
• 给 稍微总结一下
• 给 高度总结

到目前为止，主要关注的是 数据 当前详细信息。 这是主要问题，因为：

• I 数据 当前的细节反映了最近发生的事件，这些事件总是引起人们极大的兴趣和
• i 数据 当前细节的信息量很大，因为它是以最低粒度级别存储的，并且
• i 数据 当前的详细信息几乎总是存储在磁盘内存中，访问速度快，但使用起来昂贵且复杂 数据 细节越老 数据 存储在某些内存中 块。 它被偶尔访问并以与 数据 当前详细信息。 虽然不强制存储在替代存储介质上，但由于数据量很大 数据 结合零星的访问 数据，内存支持 数据 较旧的详细数据通常不存储在磁盘上。 这 数据 稍微总结一下就是 数据 它们是从发现的低细节水平提炼到当前细节水平的。 此级别的 DW 几乎总是存储在磁盘存储上。 建筑师面临的设计问题 数据 这一级别的DW的构建有：

• 上面总结的是​​什么时间单位
• 哪些内容、属性会稍微总结一下内容 数据 下一个级别 数据 在DW中发现的是 数据 高度概括。 这 数据 高度概括的内容紧凑且易于访问。 这 数据 高度总结有时会在DW环境中找到，而在其他情况下我会发现 数据 在 DW 所在的技术的直接墙壁之外可以找到高度概括的内容。 （无论如何，我 数据 高度概括是 DW 的一部分，无论我在哪里 数据 是物理安置的）。 DW 的最后一个组成部分是元数据。 在许多方面，元数据与其他元数据处于不同的维度 数据 DW 的元数据不包含任何 拿督 直接取自操作环境。 元数据在DW中具有特殊且非常重要的作用。 元数据用作：

• 帮助 DSS 分析师查找 DW 内容的目录，
• 绘制地图的指南 数据 我如何 数据 已经从操作环境转变为DW环境，
• 用于总结之间的算法的指南 数据 当前详细信息 ei 数据 稍微总结一下，我 数据 高度概括，元数据在 DW 环境中发挥的作用比在操作环境中发挥的作用大得多 旧细节存储介质 磁带可用于存储此类内容 数据。 事实上，旧存储应考虑多种存储介质 数据 的细节。 取决于体积 数据、访问频率、工具成本和访问类型，其他工具完全有可能需要 DW 中旧的详细程度。 数据流 有一个正常且可预测的流程 数据 在DW里面。
  I 数据 他们从运行环境进入DW。 （注意：这条规则有一些非常有趣的例外。但是，几乎所有 数据 从运行环境进入DW）。 拿督 该 数据 从运行环境进入DW，就如前面介绍的那样进行改造。 在进入DW的条件下，我 数据 输入当前的详细程度，如图所示。 它驻留在那里并一直使用，直到发生以下三个事件之一：

• 被净化，
• 总结，和/或 ▪è DW 中过时的流程将移动到 i 数据 当前详细信息a 数据 旧细节，基于年龄 数据。 过程

摘要使用详细信息 数据 计算我 数据 略概括和高度概括的水平 数据。 所示流程有一些例外（稍后将讨论）。 然而，通常对于绝大多数人来说 数据 在DW中发现，流 数据 如图所示。

使用数据仓库

不同级别的情况并不奇怪 数据 在 DW 内，它们没有得到不同级别的使用。 一般来说，概括的程度越高，我的理解就越多。 数据 他们被使用了。
许多用途发生在 数据 高度概括，而旧的 数据 的细节几乎从未被使用过。 有充分的理由将组织转移到资源利用模式。 更多总结我 数据，到达目的地的速度越快、效率越高 数据。 如果一个 店 发现在DW的细节层面做了很多处理，那么相应消耗了大量的机器资源。 尽快处理尽可能高水平的摘要符合每个人的最佳利益。

对于许多商店来说，DW 之前环境中的 DSS 分析师已经使用 数据 在细节层面。 在许多方面，到达 数据 详细摘要类似于安全毯，即使有其他级别的摘要可用。 建筑师的活动之一 数据 是让 DSS 用户不再持续使用 数据 在最低的细节层次上。 架构师有两种动机： 数据:

• 通过安装退款系统，最终用户为消耗的资源付费，
• 这表明当行为 i 时可以实现非常好的响应时间 数据 处于高水平的总结，而较差的响应时间则来自于 数据 处于低水平 其他考虑因素 还有一些其他 DW 构建和管理注意事项。
  首先要考虑的是指数。 这 数据 在更高级别的摘要中，它们可以自由索引，而我 数据

在较低的细节级别上，它们非常庞大，以至于可以简单地对其进行索引。 出于同样的原因，我 数据 在高细节水平上可以相对容易地重组，而体积 数据 在较低的水平，它是如此之大，以至于我 数据 它们不能轻易翻新。 因此，模型 数据 设计完成的正式工作为几乎完全在当前详细程度应用的 DW 奠定了基础。 换句话说，建模活动 数据 几乎在所有情况下，它们并不适用于摘要级别。 另一个结构性考虑因素是细分 数据 由 DW 提供。

分区可以在两个级别上完成——在 数据库 以及在应用程序级别。 在级别划分中 数据库中， 数据库 了解各部门并相应地对其进行控制。 在应用程序级别进行划分的情况下，只有程序员知道划分情况，并且由他负责管理它们

低于水平 数据库，很多工作都是自动完成的。 自动管理部门存在很多不灵活性。 在应用程序级别划分的情况下 数据 该 数据仓库，很多工作给程序员带来了压力，但最终的结果是管理上的灵活性 数据 在 数据仓库

其他异常

虽然该组件的 数据仓库 它们的工作原理几乎适用于所有情况 数据，有一些有用的例外需要讨论。 一个例外是 数据 公开汇总数据。 这些都是 数据 已计算出的摘要 数据仓库 但它们被社会所利用。 这 数据 公共摘要存储和管理在 数据仓库，尽管如前所述，它们是计算出来的。 会计师致力于制作这样的季刊 数据 例如收入、季度支出、季度利润等。 会计师所做的工作是外部的 数据仓库。 但是，我 数据 在公司内部“内部”使用 – 从 市场营销、销售等另一个不被讨论的异常现象是 数据 外部。

另一种特殊的 数据 可以在一个中找到 数据仓库 是永久详细数据的数据。 这些导致需要永久存储 数据 出于道德或法律原因，在详细层面上。 如果公司使其员工接触危险物质，则有必要 数据 详细且永久。 如果一家公司生产涉及公共安全的产品，例如飞机零部件，则需要 数据 永久性细节，以及公司是否签订危险合同。

公司不能忽视细节，因为在接下来的几年里，如果发生诉讼、召回、有争议的建筑缺陷等情况，公司将面临巨大的损失。 该公司的风险敞口可能很大。 结果就有了一种独特的 数据 称为永久详细数据。

摘要

Un 数据仓库 是一个面向对象的、集成的、时变的、集合 数据 非易失性以支持行政部门的决策需求。 每个显着功能 数据仓库 有其影响。 另外还有四个级别 数据 该 数据仓库:

• 旧细节
• 当前详细信息
• 给 稍微概括一下
• 给 高度概括的元数据也是 数据仓库. 抽象的 存储的概念 数据 最近受到很多关注，已经成为90后的潮流，这要归功于一个人的能力 数据仓库 克服决策支持系统（DSS）和执行信息系统（EIS）等管理支持系统的局限性。 即使这个概念 数据仓库 看起来很有希望，实施我 数据仓库 由于大规模的仓储流程可能会出现问题。 尽管仓储项目非常复杂 数据，许多供应商和顾问库存 数据 他们声称存储 数据 电流不会造成任何问题。 然而，在这个研究项目开始之初，几乎没有进行过独立、严谨、系统的研究。 因此，很难说，当它们建成时，行业中实际发生了什么 数据仓库。 本研究探讨了仓储实践 数据 旨在加深对澳大利亚实践的理解。 文献综述为实证研究提供了背景和基础。 这项研究有许多发现。 首先，这项研究揭示了在发展过程中出现的活动。 数据仓库。 在许多领域，我 数据 聚集证实了文献中报道的做法。 二、影响行业发展的问题和问题 数据仓库 是由本研究确定的。 最后，澳大利亚组织获得的与使用相关的好处 数据仓库 已被揭露。

第1章

研究背景

数据仓库的概念在 90 世纪 1996 年代受到广泛关注并成为一种新兴趋势（McFadden 1996、TDWI 1997、Shah 和 Milstein 1997、Shanks 等人 1998、Eckerson 2000、Adelman 和 Oates 1999）。 这可以从贸易出版物中越来越多的关于数据仓库的文章中看出（Little 和 Gibson 1995）。 许多文章（例如，参见 Fisher 1995、Hackathorn 1995、Morris 1996a、Bramblett 和 King 1996、Graham 等人 1996、Sakaguchi 和 Frolick 1997、Alvarez 1997、Brousell 1997、Clarke 1997、McCarthy 1997、O' Donnell 1998、 Edwards 1999、TDWI XNUMX）报告了实施 i 的组织获得的显着收益 数据仓库。 他们通过成功实施的轶事证据、高投资回报率 (ROI) 数字以及提供开发指导方针或方法来支持他们的理论。 数据仓库

（Shanks 等人，1997 年；Seddon 和 Benjamin，1998 年；Little 和 Gibson，1999 年）。 在一个极端的例子中，格雷厄姆等人。 (1996) 报道三年投资的平均回报率为 401%。

然而，当前的许多文献都忽略了开展此类项目所涉及的复杂性。 的项目 数据仓库 它们通常是复杂的和大规模的，因此如果不仔细控制，失败的可能性很高（Shah和Milstein 1997，Eckerson 1997，Foley 1997b，Zimmer 1997，Bort 1998，Gibbs和Clymer 1998，Rao 1998）。 它们需要大量的人力和财力资源以及时间和精力来建造它们（Hill 1998，Crofts 1998）。 所需的典型时间和资金分别约为两年和两到三百万美元（Braly 1995、Foley 1997b、Bort 1998、Humphries et al. 1999）。 这需要时间和财务手段来控制和整合数据仓库的许多不同方面（Cafasso 1995，Hill 1998）。 除了硬件和软件考虑之外，其他功能也因提取而异 数据 的加载过程 数据，管理更新和元的内存容量 数据 对于用户培训，必须予以考虑。

在这个研究项目开始时，数据仓库领域的学术研究很少，特别是在澳大利亚。 从当时的期刊或其他学术著作中发表的有关数据仓库的文章的缺乏就可以明显看出这一点。 许多现有的学术著作描述了美国的经验。 数据仓库领域学术研究的缺乏引发了对严格研究和实证研究的呼声（McFadden 1996，Shanks et al. 1997，Little and Gibson 1999）。 特别是对实施过程的研究 数据仓库 需要开展以扩展有关实施的一般知识 数据仓库 并将作为未来研究的基础（Shanks et al. 1997, Little and Gibson 1999）。

因此，本研究的目的是研究当组织执行和使用 i 时实际发生的情况。 数据仓库 在澳大利亚。 具体来说，本研究将涉及对整个开发过程的分析。 数据仓库，从启动和规划开始，一直到设计、实施以及随后在澳大利亚组织内的使用。 此外，该研究还将通过确定可以进一步改进实践以及可以最小化或避免低效率和风险的领域，为当前的实践做出贡献。 此外，它将作为其他研究的基础 数据仓库 澳大利亚，并将填补目前文献中存在的空白。

研究问题

本研究的目的是研究实施中涉及的活动 数据仓库 以及澳大利亚组织对它们的使用。 特别是，研究了有关项目规划、开发、运营、使用和所涉及风险的要素。 所以本研究的问题是：

“目前的做法是什么？ 数据仓库 在澳大利亚？”

为了有效地回答这个问题，需要一些辅助研究问题。 特别是，从文献中确定了三个子问题（在第 2 章中提出）来指导本研究项目： 数据仓库 来自澳大利亚组织？ 您遇到过哪些问题？

体验到哪些好处？
在回答这些问题时，采用了采用调查的探索性研究设计。 作为一项探索性研究，上述问题的答案并不完整（Shanks et al. 1993，Denscombe 1998）。 在这种情况下，需要进行三角测量来改进这些问题的答案。 然而，调查将为未来研究这些问题的工作提供坚实的基础。 第三章详细讨论了研究方法的论证和设计。

研究项目的结构

本研究项目分为两部分：数据仓库概念的情境研究和实证研究（见图1.1），下面分别讨论。

第一部分：情境研究

研究的第一部分包括回顾有关各种类型数据仓库的当前文献，包括决策支持系统（DSS）、执行信息系统（EIS）、案例研究 数据仓库 和的概念 数据仓库。 此外，论坛的成果 数据仓库 由莫纳什 DSS 研究团队领导的专家和从业者会议小组为这一阶段的研究做出了贡献，该研究旨在深入了解 数据仓库 并识别采用它们所涉及的风险。 在这个背景研究期间，建立了对问题领域的理解，为后续的实证研究提供背景知识。 然而，这是在研究进行期间持续进行的过程。

第二部分：实证研究

相对较新的数据仓库概念，尤其是在澳大利亚，需要进行调查来全面了解用户体验。 通过广泛的文献回顾确定问题域后，就开始执行这一部分。 在背景研究阶段形成的数据仓库概念被用作本研究初始调查问卷的输入。 此后，对调查问卷进行了审查。 您是以下方面的专家 数据仓库 参加了测试。 测试初始问卷的目的是检查问题的完整性和准确性。 根据测试结果，对调查问卷进行修改，并将修改后的版本发送给调查参与者。 然后对返回的调查问卷进行分析 数据 以表格、图表和其他格式。 这

的分析结果 数据 它们构成了澳大利亚数据仓库实践的快照。

数据仓库概述

数据仓库的概念随着计算机技术的进步而发展。
它旨在克服决策支持系统（DSS）和执行信息系统（EIS）等应用支持组所面临的问题。

过去这些应用程序的最大障碍是这些应用程序无法提供 数据库 分析所必需的。
这主要是由管理工作的性质造成的。 公司管理层的利益根据所涉及的领域不断变化。 因此我 数据 对于这些应用来说，它们必须能够根据要处理的部件快速改变。
这意味着我 数据 必须以适当的形式提供用于所要求的分析。 事实上，应用程序支持小组过去发现收集和集成非常困难 数据 来自复杂且多样的来源。

本节的其余部分概述了数据仓库的概念，并讨论了如何 数据仓库 可以克服应用程序支持小组的问题。
“数据仓库” 于 1990 年由 William Inmon 推广。他经常引用的定义是 数据仓库 作为一个集合 数据 面向主题的、集成的、非易失性的、随时间变化的，以支持管理决策。

使用这个定义 Inmon 强调我 数据 居住在一个 数据仓库 他们必须具备以下4个特征：

• ▪ 主题导向
• ▪ 集成
• ▪ 非易失性
• ▪ 随时间变化 以主题为导向的 Inmon 意味着我 数据 在 数据仓库 在最大的组织领域

模型中定义的 数据。 例如所有 数据 关于我 客户 包含在主题区域中 客户。 同样所有 数据 与产品相关的信息包含在“产品”主题区域中。

集成 Inmon 意味着我 数据 来自不同平台、系统和位置的信息被组合并存储在一个地方。 因此 数据 相似的必须转换为一致的格式，以便可以轻松添加和比较。
例如，男性和女性在一种系统中用字母 M 和 F 表示，在另一种系统中用 1 和 0 表示。 为了正确地集成它们，必须转换一种或两种格式以使两种格式相同。 在这种情况下，我们可以将 M 更改为 1，将 F 更改为 0，反之亦然。 学科导向和综合性表明 数据仓库 旨在提供功能性和横向视野 数据 来自公司。

通过非易失性他的意思是我 数据 在 数据仓库 保持一致并更新 数据 这不是必需的。 相反，每一次的改变 数据 原件被添加到 数据库 该 数据仓库。 这意味着历史的决定 数据 包含在 数据仓库.

对于有时间的变量 Inmon 表示 i 数据 在 数据仓库 始终包含 ei 时间指示器 数据 它们通常会跨越一定的时间范围。 例如一个
数据仓库 可包含5年的历史值 客户 从 1993 年到 1997 年。历史记录和时间序列的可用性 数据 允许您分析趋势。

Un 数据仓库 他可以自己收集 数据 来自 OLTP 系统；来自来源 数据 组织外部和/或其他特殊捕获系统项目 数据.
I 数据 提取物可以经过清洁过程，在这种情况下我 数据 在存储之前进行转换和集成 数据库 该 数据仓库。 然后我 数据

范围内的居民 数据库 该 数据仓库 可供最终用户登录和恢复工具使用。 使用这些工具，最终用户可以访问组织的集成视图 数据.

I 数据 范围内的居民 数据库 该 数据仓库 它们以详细格式和摘要格式存储。
摘要的级别可能取决于内容的性质 数据。 该 数据 详细内容可能包括 数据 当前和 数据 历史学家
I 数据 特许权使用费不包含在 数据仓库 直到我 数据 在 数据仓库 已更新。
除了存储 数据 他们自己，一个 数据仓库 它还可以存储不同类型的 拿督 称为元数据描述 数据 他的居民 数据库.
元数据有两种类型：开发元数据和分析元数据。
开发元数据用于管理和自动化数据的提取、清理、映射和加载过程 数据 在 数据仓库.
开发元数据中包含的信息可能包含操作系统的详细信息、要提取的元素的详细信息、模型 数据 该 数据仓库 以及转换的业务规则 数据.

第二种类型的元数据，称为分析元数据，使最终用户能够探索数据的内容。 数据仓库 找到 数据 可用及其以清晰的非技术术语表达的含义。

因此，分析元数据充当了之间的桥梁 数据仓库 和最终用户应用程序。 该元数据可以包含业务模型、描述 数据 对应于业务模型、预定义的查询和报告、用户访问的信息和索引。

分析和开发元数据必须组合成单个集成的遏制元数据才能正常运行。

不幸的是，许多现有工具都有自己的元数据，并且目前没有现有的标准

允许数据仓库工具集成此元数据。 为了改变这种情况，许多主要数据仓库工具的交易者成立了元数据委员会，后来成为元数据联盟。

该联盟的目标是建立一个标准的元数据集，允许不同的数据仓库工具转换元数据
他们的努力导致了元数据交换规范 (MDIS) 的诞生，该规范将允许 Microsoft 档案和相关 MDIS 文件之间交换信息。

的存在 数据 汇总/索引和详细信息使用户能够从以下位置执行 DRILL DROWN（钻探）： 数据 索引到详细的，反之亦然。 的存在 数据 详细的历史记录可以创建随时间变化的趋势分析。 此外，分析元数据可以用作目录 数据库 该 数据仓库 帮助最终用户找到 数据 必要的。

与 OLTP 系统相比，其支持分析的能力 数据 和报告， 数据仓库 它被视为更适合信息处理的系统，例如提出和响应查询以及生成报告。 下一节将详细介绍两个系统的差异。

数据仓库 针对 OLTP 系统

组织内的许多信息系统旨在支持日常运营。这些系统称为 OLTP 系统，捕获不断更新的日常事务。

I 数据 在这些系统中，它们经常被修改、添加或删除。例如，客户从一个地方搬到另一个地方后，他的地址就会发生变化。在这种情况下，将通过修改地址字段来注册新地址 数据库。这些系统的主要目标是降低交易成本，同时减少处理时间。 OLTP 系统的示例包括订单输入、工资单、发票、制造、客户服务等关键操作 客户.

与为基于事务和事件的流程创建的 OLTP 系统不同，我 数据仓库 创建的目的是为基于分析的流程提供支持 数据 和决策过程。

这通常是通过集成 i 来实现的 数据 来自各种 OLTP 和外部系统的单个“容器” 数据，如上一节所述。

Monash 数据仓库流程模型

过程模型为 数据仓库 Monash 由 Monash DSS 研究小组的研究人员开发，基于以下文献： 数据仓库，关于支持系统领域开发的经验，关于与应用程序供应商的讨论 数据仓库，关于专家组的使用 数据仓库.

这些阶段是：启动、规划、开发、运营和解释。该图解释了开发的迭代或进化本质 数据仓库 使用放置在不同阶段之间的双向箭头进行处理。在这种情况下，“迭代”和“进化”意味着，在过程的每一步，实施活动总是可以向后传播到前一阶段。这是由项目的性质决定的 数据仓库 最终用户随时会提出其他请求。例如，在流程的开发阶段 数据仓库，最终用户请求新的维度或主题区域，这不是原始计划的一部分，必须将其添加到系统中。这会导致项目发生变化。结果是设计团队必须更改设计阶段迄今为止创建的文档的要求。在许多情况下，项目的当前状态必须返回到必须添加和记录新需求的设计阶段。最终用户必须能够看到所审查的具体文档以及在开发阶段所做的更改。在此开发周期结束时，项目必须从开发团队和用户团队获得良好的反馈。然后，反馈将被重新用于改进未来的项目。

容量规划
由于大量的 数据 它们自存在以来保留的历史。增长也可能是由于 数据 用户要求添加以增加价值 数据 他们已经拥有了。因此，存储要求 数据 可以显着增强（Eckerson 1997）。因此，必须通过进行容量规划来确保正在构建的系统能够随着需求的增长而增长（Best 1995、LaPlante 1996、Lang 1997、Eckerson 1997、Rudin 1997a、Foley 1997a）。
在规划数据库的可扩展性时，必须了解仓库大小的预期增长、可能进行的查询类型以及支持的最终用户数量（Best 1995、Rudin 1997b、Foley 1997a）。构建可扩展的应用程序需要将可扩展的服务器技术和可扩展的应用程序设计技术相结合（Best 1995，Rudin 1997b）。两者都是构建高度可扩展的应用程序所必需的。可扩展的服务器技术可以轻松且有利地添加存储、内存和 CPU，而不会降低性能性能（Lang 1997，电话 1997）。

有两种主要的可扩展服务器技术：对称多重处理 (SMP) 和大规模并行处理 (MPP)（IDC 1997，Humphries 等人 1999）。 SMP 服务器通常具有多个共享内存、系统总线和其他资源的处理器（IDC 1997，Humphries 等人 1999）。可以添加额外的处理器以增加其 威力 计算性的。另一种增加方法 威力 SMP服务器的本质，就是将众多的SMP机器组合起来。这种技术称为聚类（Humphries et al. 1999）。另一方面，MPP 服务器具有多个处理器，每个处理器都有自己的内存、总线系统和其他资源（IDC 1997，Humphries 等人 1999）。每个处理器称为一个节点。增加 威力 计算可以实现

向 MPP 服务器添加额外的节点（Humphries 等人，1999）。

SMP 服务器的一个弱点是过多的输入输出 (I/O) 操作可能会导致系统总线拥塞 (IDC 1997)。由于每个处理器都有自己的总线系统，因此 MPP 服务器内不会出现此问题。然而，每个节点之间的互连通常比SMP总线系统慢得多。此外，MPP 服务器可能会为应用程序开发人员增加额外的复杂性（IDC 1997）。因此，SMP和MPP服务器之间的选择可能受到许多因素的影响，包括应用程序的复杂性、性价比、所需的处理能力、阻止的dw应用程序以及系统规模的增加。 数据库 dw 和最终用户的数量。

在容量规划中可以采用多种可扩展的应用程序设计技术。人们使用各种通知期限，例如天、周、月和年。具有不同的通知期限， 数据库 它可以分为易于管理的分组部分（Inmon et al. 1997）。另一种技术是使用通过汇总而构建的汇总表 数据 da 数据 详细的。所以我 数据 总结比详细更紧凑，需要更少的内存空间。所以 数据 详细信息可以存储在更便宜的存储单元中，从而节省更多存储空间。虽然使用汇总表可以节省内存空间，但需要付出很大的努力才能使其保持最新并符合业务需求。然而，这种技术被广泛使用，并且经常与以前的技术结合使用（Best 1995、Inmon 1996a、Chauduri 和 Dayal
1997）。

定义 数据仓库 技术架构 dw 架构技术的定义

数据仓库的早期采用者主要设想的是数据仓库的集中实施，其中所有的 数据，包括我 数据 外部，被集成到一个单一的，
物理存储（Inmon 1996a、Bresnahan 1996、Peacock 1998）。

这种方法的主要优点是最终用户能够访问企业范围的视图 数据 组织（Ovum 1998）。另一个优点是它提供了标准化 数据 通过组织，这意味着 dw 存储库（元数据）中使用的每个术语只有一个版本或定义（Flanagan 和 Safdie 1997，Ovum 1998）。另一方面，这种方法的缺点是昂贵且难以构建（Flanagan 和 Safdie 1997，Ovum 1998，Inmon 等人 1998）。不久之后的存储架构 数据 集中化变得流行，提取进化的较小子集的概念 数据 支持特定应用程序的需求（Varney 1996、IDC 1997、Berson 和 Smith 1997、peacock 1998）。这些小系统是大系统的衍生品 数据仓库 集中。他们被命名为 数据仓库 依赖部门或依赖数据集市。依赖数据集市架构称为三层架构，其中第一层由 数据仓库 集中化，第二个包括存款 数据 部门，第三个包括访问 数据 以及分析工具（Demarest 1994，Inmon et al. 1997）。

数据集市通常是在 数据仓库 集中化的建立是为了满足特定单位的需求（White 1995，Varney 1996）。
数据集市存储 数据 与特定单位非常相关（Inmon et al. 1997, Inmon et al. 1998, IA 1998）。

这种方法的优点是不会出现 拿督 没有集成，我 数据 数据集市内的冗余度将减少，因为所有 数据 他们来自仓库 数据 融合的。另一个优点是每个数据集市及其来源之间的连接很少 数据 因为每个数据集市只有一个来源 数据。另外，有了这种架构，最终用户仍然可以访问 数据

企业组织。这种方法被称为自上而下的方法，其中数据集市是在 数据仓库 （孔雀 1998，戈夫 1998）。
由于越来越需要尽早显示结果，一些组织已经开始建立独立的数据集市（Flanagan 和 Safdie 1997，White 2000）。在这种情况下，数据集市有自己的 数据 直接从基础 数据 OLTP而不是来自集中和集成的仓库，因此无需在现场拥有中央仓库。

每个数据集市至少需要一个指向其来源的链接 数据。每个数据集市有多个连接的缺点是，与前两种架构相比，过多的连接 数据 显着增加。

每个数据集市必须存储所有 数据 本地要求对 OLTP 系统没有影响。这导致我 数据 它们存储在不同的数据集市中（Inmon et al. 1997）。这种架构的另一个缺点是，它导致在数据集市及其数据源之间创建复杂的互连。 数据 这很难执行和控制（Inmon et al. 1997）。

另一个缺点是最终用户无法访问公司信息的概述，因为我 数据 不同数据集市的数据没有集成（Ovum 1998）。
另一个缺点是数据集市中使用的每个术语可能有多个定义，这会产生不一致的情况。 数据 在组织中（Ovum 1998）。
尽管存在上述缺点，独立数据集市仍然吸引了许多组织的兴趣（IDC 1997）。使它们有吸引力的因素之一是它们的开发速度更快并且需要更少的时间和资源（Bresnahan 1996，Berson 和 Smith 1997，Ovum 1998）。因此，它们主要用作测试项目，可用于快速识别项目中的优点和/或缺陷（Parsaye 1995、Braly 1995、Newing 1996）。在这种情况下，试点项目中要实施的部分必须很小，但对组织来说很重要（Newing 1996，Mansell-Lewis 1996）。

通过检查原型，最终用户和管理人员可以决定是否继续或停止该项目（Flanagan 和 Safdie 1997）。
如果这一决定继续下去，其他行业的数据集市应该一次建立一个。根据最终用户构建独立数据矩阵的需求，有两种选择：集成/联合和非集成（Ovum 1998）

第一种方法，每个新的数据集市应该基于当前的数据集市和模型来构建 数据 公司使用（Varney 1996，Berson 和 Smith 1997，Peacock 1998）。使用模型的必要性 数据 公司的定义意味着必须确保数据集市中使用的每个术语只有一个定义，同时还要确保不同的数据集市可以组合起来以提供公司信息的概述（Bresnahan 1996）。这种方法称为自下而上，当财务手段和时间受到限制时是最佳方法（Flanagan and Safdie 1997, Ovum 1998, Peacock 1998, Goff 1998）。第二种方法，构建的数据集市只能满足特定单位的需求。联合数据集市的一个变体是 数据仓库 分布在其中 数据库 Hub 服务器中间件用于将多个数据集市合并到单个存储库中 数据 分布式（White 1995）。在这种情况下，我 数据 公司分布在多个数据集市中。最终用户请求被传输至 数据库 服务器集线器中间件，提取所有 数据 数据集市请求并将结果返回给最终用户应用程序。该方法向最终用户提供业务信息。然而，独立数据集市的问题仍然没有消除。还有另一种架构可以使用，称为 数据仓库 虚拟（White 1995）。然而，图 2.9 中描述的这种架构并不是数据存储架构。 数据 真实，因为它不会将负载从 OLTP 系统转移到 数据仓库 （德马雷斯特 1994）。

事实上，人们的要求 数据 最终用户的数据被传递到 OLTP 系统，OLTP 系统在处理用户请求后返回结果。虽然这种架构允许最终用户生成报告并提出请求，但它无法提供

数据 我的公司信息的历史和概述 数据 来自不同OLTP系统的未集成。因此，该架构无法满足以下分析： 数据 复杂如预测。

选择访问和恢复应用程序 数据

建设的目的 数据仓库 向最终用户传达信息（Inmon et al. 1997, Poe 1996, McFadden 1996, Shanks et al. 1997, Hammergren 1998）；一个或多个访问和恢复应用程序 数据 必须提供。迄今为止，用户可以选择各种各样的应用程序（Hammergren 1998，Humphries 等人 1999）。您选择的应用程序决定您的仓储工作是否成功 数据 在组织中，因为应用程序是组织中最明显的部分 数据仓库 到最终用户（Inmon et al 1997, Poe 1996）。要想成功a 数据仓库，必须能够支持分析活动 数据 最终用户（Poe 1996，Seddon 和 Benjamin 1998，Eckerson 1999）。因此，必须确定最终用户想要的“级别”（Poe 1996、Mattison 1996、Inmon 等人 1997、Humphries 等人 1999）。

一般来说，最终用户可以分为三类：执行用户、业务分析师和高级用户（Poe 1996，Humphries et al. 1999）。执行用户需要轻松访问预定义的报告集（Humphries 等人，1999）。这些比率可以通过菜单导航轻松访问（Poe 1996）。此外，报告应使用表格和模板等图形表示形式来呈现信息，以快速传达信息（Humphries 等人，1999）。业务分析师可能不具备自己从头开始开发报告的技术能力，但需要能够修改当前报告以满足他们的特定需求（Poe 1996，Humphries 等人 1999）。另一方面，高级用户是能够从头开始生成和编写请求和报告的最终用户类型（Poe 1996，Humphries 等人 1999）。他们是那些

他们为其他类型的用户开发报告（Poe 1996，Humphries et al. 1999）。

一旦确定了最终用户的要求，就必须选择访问和恢复应用程序 数据 在所有可用的方法中（Poe 1996，Inmon et al. 1997）。
进入 数据 检索工具可分为4类：OLAP工具、EIS/DSS工具、查询和报告工具以及数据挖掘工具。

OLAP 工具允许用户创建即席查询以及在 数据库 该 数据仓库。此外，这些产品允许用户深入了解 数据 从一般到详细。

EIS/DSS 工具提供执行报告，例如“假设”分析和对菜单驱动报告的访问。应预定义报告并将其与菜单合并以便于导航。
查询和报告工具允许用户生成预定义的特定报告。

数据挖掘工具用于识别关系，这些关系可以为被遗忘的操作提供新的线索。 数据 的数据仓库。

除了优化每种类型用户的需求外，所选工具还必须直观、高效且易于使用。它们还必须与架构的其他部分兼容，并且能够与现有系统一起工作。还建议选择价格合理、性能合理的数据访问和检索工具。其他需要考虑的标准包括工具供应商对其产品支持的承诺以及未来版本中的开发。为了确保用户参与使用数据仓库，开发团队让用户参与工具选择过程。在这种情况下，应该进行实际的用户评估。

为了提高数据仓库的价值，开发团队还可以提供对其数据仓库的 Web 访问。支持网络的数据仓库允许用户访问 数据 来自偏远地区或旅行时。此外信息还可以

通过减少培训费用以较低的成本提供。

2.4.3 数据仓库 运营阶段

该阶段由三个活动组成：定义数据刷新策略、控制数据仓库活动和管理数据仓库安全。

数据刷新策略的定义

初始加载后，我 数据 在 数据库 数据仓库的数据必须定期刷新以重现对其所做的更改 数据 原件。因此，您必须决定何时刷新、安排刷新的频率以及如何刷新数据 数据。建议刷新一下 数据 当系统可以离线时。刷新频率由开发团队根据用户需求确定。刷新数据仓库有两种方法：完全刷新和持续加载更改。

第一种方法，完全刷新，需要重新加载所有 数据 从头开始。这意味着所有 数据 所需的内容必须被提取、清理、转换并集成到每次刷新中。应尽可能避免这种方法，因为它需要大量时间和资源。

另一种方法是不断上传更改。这增加了我 数据 自上次数据仓库刷新周期以来已更改。识别新的或修改的记录可显着减少 数据 必须在每次更新时传播到数据仓库，因为只有这些 数据 将被添加到 数据库 的数据仓库。

至少有 5 种方法可用于提取 i 数据 新的或修改的。获得高效的数据刷新策略 数据 混合使用这些方法来捕获系统中的所有变化可能会很有用。

第一种方法使用时间戳，假设所有的都已分配 数据 编辑和更新时间戳，以便您可以轻松识别所有 数据 修改后的和新的。然而，这种方法尚未在当今的大多数操作系统中广泛使用。
第二种方法是使用由应用程序生成的增量文件，该文件仅包含对 数据。使用此文件还可以延长更新周期。然而，即使这种方法也没有在许多应用中使用。
第三种方法是扫描日志文件，该文件基本上包含与增量文件类似的信息。唯一的区别是日志文件是为恢复过程创建的，并且可能难以理解。
第四种方法是修改应用程序代码。然而，大多数应用程序代码都是陈旧且脆弱的；因此应该避免使用这种技术。
最后一种方法是比较 数据 带有主 dei 文件的源代码 数据.

数据仓库活动的控制

一旦数据仓库发布给用户，就必须对其进行长期监控。在这种情况下，数据仓库管理员可以采用一种或多种管理和控制工具来监控数据仓库的使用情况。特别是，可以收集有关人员及其访问数据仓库的时间的信息。快点 数据 收集到后，可以创建所执行工作的概况，该概况可以用作用户退款实施中的输入。 Chargeback 允许用户了解数据仓库处理成本。

此外，数据仓库审计还可以用于识别查询的类型、查询的大小、每天的查询数量、查询反应时间、到达的扇区以及查询的数量。 数据 处理。进行数据仓库审计的另一个目的是确定 数据 哪些未使用。这些 数据 可以将它们从数据仓库中删除以缩短时间

查询执行响应并监视增长 数据 谁居住在 数据库 的数据仓库。

数据仓库安全管理

数据仓库包含 数据 集成的、关键的、敏感的，可以很容易地达到。因此，应防止未经授权的用户使用它。实现安全性的一种方法是使用 del 函数 DBMS 为不同类型的用户分配不同的权限。这样，必须为每种类型的用户维护访问配置文件。保护数据仓库的另一种方法是对其进行加密，如 数据库 的数据仓库。进入 数据 和检索工具必须解密 数据 在将结果呈现给用户之前。

2.4.4 数据仓库 部署阶段

这是数据仓库实施周期的最后一个阶段。此阶段要进行的活动包括培训用户使用数据仓库和对数据仓库进行审查。

用户培训

在访问之前应进行用户培训 数据 数据仓库和检索工具的使用。一般来说，会议应该从介绍存储的概念开始 数据，数据仓库的内容，元 数据 以及工具的基本功能。然后，更高级的用户还可以研究数据访问和检索工具的物理表和用户特征。

进行用户培训的方法有很多。其中之一涉及根据领导力和沟通技巧从一组用户中选择许多用户或分析师。他们接受了熟悉系统所需了解的一切培训。培训结束后，他们返回工作岗位并开始教其他用户如何使用该系统。上

根据他们所学到的知识，其他用户可以开始探索数据仓库。
另一种方法是同时培训许多用户，就像参加课堂课程一样。这种方法适用于需要同时训练的用户较多的情况。另一种方法是单独培训每个用户，一个接一个。此方法适用于用户较少的情况。

用户培训的目的是让您熟悉访问 数据 和检索工具以及数据仓库的内容。然而，一些用户可能会对培训课程期间提供的信息量感到不知所措。因此，必须进行一定数量的复习课程以获得持续的帮助并回答具体问题。在某些情况下，会形成一个用户组来提供此类支持。

收集反馈

一旦数据仓库推出，用户就可以使用我 数据 出于各种目的而驻留在数据仓库中。大多数情况下，分析师或用户使用 i 数据 在数据仓库中：

1. 1 识别公司趋势
2. 2 分析以下人员的购买概况 客户
3. 3 除以我 客户 和
4. 4 提供最好的服务 客户 – 定制服务
5. 5 制定策略 市场营销
6. 6 为成本分析提供有竞争力的报价并帮助控制
7. 7 支持战略决策
8. 8 识别脱颖而出的机会
9. 9 提高当前业务流程的质量
10. 10 检查利润

根据数据仓库的发展方向，可以对系统进行一系列的审查以获得反馈

来自开发团队和最终用户社区。
获得的结果可以考虑用于下一个开发周期。

由于数据仓库采用增量方法，因此从以前开发的成功和错误中吸取教训至关重要。

2.5 总结

本章讨论了文献中提出的方法。第 1 节讨论了数据仓库的概念及其在决策科学中的作用。第 2 节描述了数据仓库和 OLTP 系统之间的主要区别。在第 3 节中，我们讨论了 Monash 数据仓库模型，该模型在第 4 节中用于描述开发数据仓库过程中涉及的活动，这些论文并不是基于严格的研究。现实中发生的情况可能与文献报道的有很大不同，但是这些结果可以用来创建一个基本背景，强调本研究的数据仓库概念。

第3章

研究与设计方法

本章讨论本研究的研究和设计方法。第一部分展示了可用于检索信息的研究方法的一般视图，并讨论了为特定研究选择最佳方法的标准。在第 2 节中，讨论了根据刚刚公开的标准选择的两种方法；其中，将选择并采用其中一项，其原因见第 3 节，其中还列出了排除其他标准的理由。第 4 节介绍研究设计，第 5 节介绍结论。

3.1 信息系统研究

信息系统的研究不仅限于技术领域，还必须扩展到包括行为和组织目的。
这要归功于从社会科学到自然科学等各个学科的论文。这导致需要一系列涉及定量和定性方法的研究方法用于信息系统。
所有可用的研究方法都很重要，事实上，一些研究人员，如 Jenkins (1985)、Nunamaker 等人。 (1991) 和 Galliers (1992) 认为，在信息系统的各个领域进行研究并没有特定的通用方法；事实上，一种方法可能适合特定的研究，但不适用于其他研究。这使我们需要选择一种适合我们特定研究项目的方法：对于这个选择，Benbasat 等人。 (1987) 指出必须考虑研究的性质和目的。

3.1.1 研究的性质

基于研究性质的各种方法可以分为信息科学中广为人知的三种传统：实证主义、解释性和批判性研究。

3.1.1.1 实证研究

实证研究也称为科学或实证研究。它旨在：“通过观察构成社会世界的元素之间的规律性和因果关系来解释和预测社会世界将发生什么”（Shanks et al 1993）。

实证主义研究的另一个特点是可重复性、简化性和反驳性。此外，实证主义研究承认所研究的现象之间存在先验关系。
根据Galliers（1992）的说法，分类学是实证主义范式中包含的一种研究方法，但并不限于此，事实上还有实验室实验、现场实验、案例研究、定理论证、预测和模拟。研究人员承认，通过使用这些方法，可以客观、严格地观察所研究的现象。

3.1.1.2 解释性研究

解释性研究通常被称为现象学或反实证主义，诺伊曼（Neuman，1994）将其描述为“通过对自然情境中的人进行直接和详细的观察，对行为的社会意义进行系统分析，以得出理解和理解”。解释人们如何创造和维持他们的社交世界。”解释性研究拒绝观察到的现象可以被客观观察的假设。事实上，它们是基于主观解释。此外，解释性研究者不会将先验意义强加给他们研究的现象。

该方法包括主观/论证性研究、行动研究、描述性/解释性研究、未来研究和角色扮演。除了这些调查和案例研究之外，还可以包含在这种方法中，因为它们涉及复杂的现实情况下的个人或组织的研究。

3.1.1.3 批判性研究

批判性探究是社会科学中最不为人所知的方法，但最近受到信息系统研究人员的关注。社会现实是由人们以及社会系统及其行为和相互作用历史性地产生和再生产的哲学假设。然而，他们的能力受到许多社会、文化和政治因素的影响。

与解释性研究一样，批判性研究认为实证主义研究与社会背景无关，并且忽视了它对人类行为的影响。
另一方面，批判性研究批评解释性研究过于主观，并且不以帮助人们改善生活为目的。批判性研究与其他两种方法之间的最大区别在于其评估维度。实证主义和解释性传统的客观性是预测或解释现状或社会现实，而批判性研究的目的是批判性地评估和改变所研究的社会现实。

批判性研究者通常反对现状，以消除社会差异、改善社会条件。批判性研究致力于对感兴趣的现象进行过程性的观察，因此通常是纵向的。研究方法的例子有长期历史研究和民族志研究。然而，批判性研究尚未广泛应用于信息系统研究

3.1.2 研究目的

根据研究的性质，其目的可以用来指导研究人员选择特定的研究方法。研究项目的目的与研究在研究周期中的地位密切相关，研究周期由三个阶段组成：理论构建、理论检验和理论完善。因此，根据研究周期的时间安排，研究项目可以具有解释性、描述性、探索性或预测性目的。

3.1.2.1 探索性研究

探索性研究旨在调查一个全新的课题，并为未来的研究提出问题和假设。此类研究用于理论构建，以获得新领域的初步参考。通常使用定性研究方法，例如案例研究或现象学研究。

然而，也可以采用定量技术，例如探索性调查或实验。

3.1.3.3 描述性研究

描述性研究旨在详细分析和描述特定的组织情况或实践。这适用于构建理论，也可用于确认或挑战假设。描述性研究通常包括使用措施和样本。最合适的研究方法包括调查和前因分析。

3.1.2.3 解释性研究

解释性研究试图解释事情发生的原因。它建立在已经研究过的事实的基础上，并试图找出这些事实的原因。
因此，解释性研究通常建立在探索性或描述性研究的基础上，并辅助测试和完善理论。解释性研究通常采用案例研究或基于调查的研究方法。

3.1.2.4 预防性研究

预防性研究旨在预测正在研究的观察事件和行为（Marshall 和 Rossman 1995）。预测是对真理的标准科学检验。此类研究通常采用调查或分析 数据 历史学家。 （尹1989）

上述讨论表明，在特定研究中可以使用多种可能的研究方法。然而，必须有一种特定方法比其他方法更适合特定类型的研究项目。 （Galliers 1987，Yin 1989，De Vaus 1991）。因此，每个研究者都需要仔细评估各种方法的优缺点，以采取最适合自己的研究项目的研究方法。 （Jenkins 1985，Pervan 和 Klass 1992，Bonomia 1985，Yin 1989，Hamilton 和 Ives 1992）。

3.2.可能的研究方法

该项目的目的是与我一起研究澳大利亚组织的经验 数据 存储与开发 数据仓库. 拿督 目前，澳大利亚在数据仓储领域缺乏研究，本研究项目仍处于研究周期的理论阶段，具有探索性目的。探索澳大利亚组织采用数据仓库的经验需要对现实社会的解释。因此，该研究项目的哲学假设遵循传统的解释。

在对可用方法进行严格检查后，确定了两种可能的研究方法：调查和案例研究，可用于探索性研究（Shanks et al. 1993）。 Galliers (1992) 在他修订的分类法中论证了这两种方法对于这项特定研究的适用性，称它们适合于理论构建。以下两小节详细讨论每种方法。

3.2.1 调查研究方法

调查研究方法来源于古代人口普查方法。人口普查包括收集整个人口的信息。这种方法既昂贵又不切实际，特别是在人口众多的情况下。因此，与人口普查相比，调查通常侧重于收集少数人口代表或样本的信息（Fowler 1988，Neuman 1994）。样本反映了从中抽取的总体，具有不同的准确度，具体取决于样本结构、大小和所使用的选择方法（Fowler 1988，Babbie 1982，Neuman 1994）。

调查方法被定义为“通过问卷或访谈对特定时间点的做法、情况或观点进行快照，从中可以得出推论”。
”（Galliers 1992：153）[通过问卷或访谈对特定时间点的做法、情况或观点进行快照，从中可以做出推论]。调查通过提问的方式从一定数量的参与者那里收集有关研究某些方面的信息（Fowler 1988）。这些问卷调查和访谈，包括面对面的电话访谈和结构化访谈，也是收集信息的技术。 数据 最常用于调查（Blalock 1970，Nachmias 和 Nachmias 1976，Fowler 1988），也可以使用观察和分析（Gable 1994）。在所有这些收集方法中 数据，使用调查问卷是最流行的技术，因为它可以确保我 数据

收集到的数据是结构化和格式化的，因此有利于信息的分类（Hwang 1987，de Vaus 1991）。

当分析我 数据，调查策略通常采用定量技术，例如统计分析，但也可以使用定性技术（Galliers 1992，Pervan

和 Klass 1992，Gable 1994）。通常情况下，我 数据 收集的数据用于分析关联的分布和模式（Fowler 1988）。

虽然调查通常适用于解决“什么？”问题或由“什么？”问题引起的询问，例如“多少”和“多少”，但也可以通过“为什么”问题来询问（Sonquist 和 Dunkelberg 1977，Yin 1989） 。根据 Sonquist 和 Dunkelberg (1977) 的说法，探究性研究的目的是挑战假设、评估项目、描述人群以及开发人类行为模型。此外，调查可用于研究特定人群的意见、条件、意见、特征、期望甚至过去或现在的行为（Neuman 1994）。

调查使研究人员能够发现人群之间的关系，并且结果通常比其他方法更普遍（Sonquist 和 Dunkelberg 1977，Gable 1994）。调查使研究人员能够覆盖更大的地理区域并接触到许多受访者（Blalock 1970、Sonquist 和 Dunkelberg 1977、Hwang 和 Lin 1987、Gable 1994、Neuman 1994）。最后，调查可以提供其他地方无法提供的信息或分析所需形式的信息（Fowler 1988）。

然而，进行调查也存在一些限制。缺点是研究人员无法获得有关研究对象的大量信息。这是因为调查仅在特定时间进行，因此研究人员可以选择的变量和人员数量有限。

研究（Yin 1989，de Vaus 1991，Gable 1994，Denscombe 1998）。另一个缺点是进行调查在时间和资源方面可能非常昂贵，特别是当它涉及面对面访谈时（Fowler 1988）。

3.2.2.探究式研究方法

探究性研究方法涉及在规定的时间内对现实世界背景下的特定情况进行深入研究，研究人员无需进行任何干预（Shanks & C. 1993、Eisenhardt 1989、Jenkins 1985）。该方法主要用于描述特定情况下所研究的变量之间的关系（Galliers 1992）。调查可以涉及单个或多个案件，具体取决于分析的现象（Franz 和 Robey 1987、Eisenhardt 1989、Yin 1989）。

探究研究方法被定义为“一种实证探究，利用从一个或多个实体（例如个人、群体或组织）收集的多种来源，在其实际背景下研究当代现象”（Yin 1989）。这种现象与其背景之间没有明显的区别，也没有对变量进行实验控制或操纵（Yin 1989，Benbasat 等人 1987）。

收集神器的技巧有很多种 数据 可以采用询问法，包括直接观察、查阅档案记录、问卷调查、文件审查和结构化访谈。拥有多种收获技术 数据，调查使研究人员能够处理这两个问题 数据 同时进行定性和定量（Bonoma 1985，Eisenhardt 1989，Yin 1989，Gable 1994）。与探究方法的情况一样，探究研究者充当观察者或研究者，而不是所研究组织的积极参与者。

Benbasat 等人（1987）断言，探究方法特别适合构建研究理论，该理论从研究问题开始，并继续教育。

收集过程中的理论 数据。也适合舞台

在理论构建过程中，Franz 和 Robey (1987) 提出探究方法也可以用于复杂理论阶段。在这种情况下，根据收集的证据，验证或反驳给定的理论或假设。此外，该调查还适用于处理“如何”或“为什么”问题的研究（Yin 1989）。

与其他方法相比，调查使研究人员能够更详细地捕获重要信息（Galliers 1992，Shanks et al. 1993）。此外，调查使研究人员能够了解所研究过程的性质和复杂性（Benbasat 等人，1987）。

该调查方法有四个主要缺点。首先是缺乏受控扣除。研究者的主观性可以改变研究的结果和结论（Yin 1989）。第二个缺点是缺乏受控观察。与实验方法不同，探究研究者无法控制所研究的现象，因为它们是在自然背景下进行检查的（Gable 1994）。第三个缺点是缺乏可复制性。这是因为研究人员不太可能观察到相同的事件，并且无法验证特定研究的结果（Lee 1989）。最后，由于不可重复性，很难概括从一项或多项研究中获得的结果（Galliers 1992，Shanks et al 1993）。然而，所有这些问题都不是不可克服的，事实上，研究人员可以通过采取适当的行动将其最小化（Lee 1989）。

3.3.证明研究方法的合理性 阿多塔塔

从本研究的两种可能的研究方法来看，调查法被认为是最合适的。经过仔细考虑相关调查后，调查被放弃

优点和缺点。下面讨论本研究每种方法的适当性或不适当性。

3.3.1.研究方法不当 调查的

探究法需要对一个或多个组织在一段时间内的特定情况进行深入研究（Eisenhardt 1989）。在这种情况下，该期限可能会超出本研究给出的时间范围。不采用调查方法的另一个原因是结果可能缺乏严谨性（尹1989）。研究人员的主观性会影响结果和结论。另一个原因是这种方法更适合研究“如何”或“为什么”类型的问题(尹1989)，而本研究的研究问题是“什么”类型。最后但并非最不重要的一点是，仅从一项或几项调查中很难得出结论（Galliers 1992，Shanks et al. 1993）。基于此，本研究不选择调查研究方法。

3.3.2.便捷的搜索方式 调查

当进行这项研究时，数据仓库的实践尚未被澳大利亚组织广泛采用。因此，关于它们在澳大利亚组织内实施的信息并不多。可用信息来自已经实施或使用了 数据仓库。在这种情况下，调查研究方法是最合适的，因为它可以获取其他地方无法获得的信息或分析所需形式的信息（Fowler 1988）。此外，调查研究方法使研究人员能够深入了解特定时间的实践、情况或观点（Galliers 1992，Denscombe 1998）。需要进行概述以增加对澳大利亚数据仓库经验的了解。

此外，Sonquist 和 Dunkelberg (1977) 指出，调查研究的结果比其他方法更具有普遍性。

3.4.调查研究设计

关于数据仓库实践的调查于 1999 年进行。目标人群由对数据仓库研究感兴趣的澳大利亚组织组成，因为他们可能已经了解了 数据 他们存储这些信息，因此可以为本研究提供有用的信息。通过对数据仓库协会 (Tdwi-aap) 的所有澳大利亚成员进行初步调查，确定了目标人群。本节讨论本研究实证研究阶段的设计。

3.4.1.收获技术 数据

综合调查研究中常用的三种技术（即邮寄问卷、电话访谈和个人访谈）（Nachmias 1976，Fowler 1988，de Vaus 1991），本研究采用了邮寄问卷。采用后者的第一个原因是它可以覆盖地理上分散的人群（Blalock 1970，Nachmias 和 Nachmias 1976，Hwang 和 Lin 1987，de Vaus 1991，Gable 1994）。其次，邮寄问卷适合受过高等教育的参与者（Fowler 1988）。本研究的邮件调查问卷是发送给数据仓库项目发起人、主管和/或项目经理的。第三，当有安全邮件列表可用时，邮寄调查问卷就合适（Salant and Dilman 1994）。 TDWI，在本例中，是一个值得信赖的数据仓库协会，提供了其澳大利亚成员的邮件列表。与电话问卷或个人访谈相比，邮寄调查问卷的另一个优点是，它允许受访者更准确地回答，特别是当受访者必须查阅笔记或与其他人讨论问题时（Fowler 1988）。

一个潜在的缺点可能是通过邮寄进行调查问卷需要时间。通常，邮件调查按以下顺序进行：邮寄信件，等待回复，然后发送确认（Fowler 1988，Bainbridge 1989）。因此，总时间可能比个人面试或电话面试所需的时间更长。然而，总时间可以提前知道（Fowler 1988，Denscombe 1998）。进行个人访谈所花费的时间无法提前得知，因为每次访谈的时间各不相同（Fowler 1988）。电话访谈可能比邮寄问卷和个人访谈更快，但由于某些人无法参加而导致无答复率很高（Fowler 1988）。此外，电话采访通常仅限于相对较短的问题清单（Bainbridge 1989）。

邮寄问卷的另一个弱点是较高的无答复率（Fowler 1988、Bainbridge 1989、Neuman 1994）。然而，已经采取了对策，将这项研究与可信数据仓库机构（即 TDWI）相关联（Bainbridge 1989，Neuman 1994），该机构向未回复者发送两封提醒信（Fowler 1988，Neuman 1994），并且还包括一封附加信解释研究的目的（Neuman 1994）。

3.4.2.分析单位

本研究的目的是获取有关数据仓库实施及其在澳大利亚组织内使用的信息。目标人群包括所有已经实施或正在实施的澳大利亚组织 数据仓库。然后以各个组织的名义进行注册。调查问卷已邮寄给有兴趣采用的组织 数据仓库。这种方法确保收集的信息来自每个参与组织最合适的资源。

3.4.3.调查样本

调查参与者的“邮件列表”是从 TDWI 获得的。从这份名单中，选出了 3000 个澳大利亚组织作为抽样的基础。向样本发送了一封额外的信函，解释调查的项目和目的，以及回复表和用于寄回填妥的调查问卷的预付费信封。在 3000 个组织中，有 198 个组织同意参与这项研究。预计回复数量如此之少 拿督 许多澳大利亚组织当时已经或正在其组织内采用数据仓库策略。因此，本研究的目标人群仅包括 198 个组织。

3.4.4.问卷内容

调查问卷的结构基于 Monash 数据仓库模型（之前在第 2.3 部分中讨论过）。调查问卷的内容基于第 2 章中介绍的文献分析。发送给调查参与者的调查问卷副本可在附录 B 中找到。调查问卷由六个部分组成，遵循所涵盖模型的各个阶段。以下六段简要总结了每个部分的内容。

A 部分：有关组织的基本信息
本节包含与参与组织概况相关的问题。此外，一些问题与参与者的数据仓库项目状态相关。调查分析中没有透露组织名称等机密信息。

B 部分：开始
本节中的问题与数据仓库启动活动相关。询问了有关项目发起人、担保人、所需技能和知识、数据仓库开发目标和最终用户期望的问题。

C 部分：设计
本节包含与规划活动相关的问题 数据仓库。特别是，问题涉及执行范围、项目持续时间、项目成本以及成本/效益分析。

D 部分：发展
在开发部分，存在与开发活动相关的问题 数据仓库：收集最终用户需求、来源 数据，逻辑模型 数据、原型、容量规划、技术架构和数据仓库开发工具的选择。

E 部分：操作
与操作和可扩展性相关的操作问题 数据仓库，它在下一阶段的发展中如何演变。那里 数据质量，刷新策略 数据，粒度 数据，可扩展性 数据仓库 以及安全问题 数据仓库 是所提出问题的类型之一。

F 部分：发展
本节包含有关使用的问题 数据仓库 由最终用户。研究人员对这个项目的目的和用途很感兴趣 数据仓库、所采取的审查和培训策略以及控制策略 数据仓库 采纳。

3.4.5。反应速度

尽管邮寄调查因回复率低而受到批评，但已采取措施提高回复率（如前面第 3.4.1 部分所述）。 “答复率”一词是指特定调查样本中对问卷做出答复的人数百分比（Denscombe 1998）。使用以下公式计算本研究的响应率：

回复人数
回复率 = ——————————————————————————– X 100 发送问卷总数

3.4.6。飞行员考试

在将问卷发送给样本之前，按照 Luck 和 Rubin (1987)、Jackson (1988) 和 de Vaus (1991) 的建议，通过进行试点测试来检查问题。试点测试的目的是揭示任何尴尬、模棱两可的表达和难以解释的问题，澄清所使用的任何定义和术语，并确定完成调查问卷所需的大致时间（Warwick 和 Lininger 1975，Jackson 1988，Salant和迪尔曼 1994）。根据 Davis e 的建议，试点测试是通过选择具有与最终受试者相似特征的受试者来进行的。 科森扎 （1993）。在这项研究中，选择了六名数据仓库专业人员作为试点对象。每次试点测试后，都进行了必要的修正。通过试点测试，参与者为问卷的最终版本的重塑和重置做出了贡献。

3.4.7.分析方法 给

I 数据 使用称为 SPSS 的统计程序包对从封闭式问卷中收集的调查进行分析。许多答复是使用描述性统计数据进行分析的。许多问卷被退回，但不完整。这些都经过更加仔细的处理，以确保我 数据 缺失并不是由于数据输入错误造成的，而是因为问题不适合注册人，或者注册人决定不回答一个或多个具体问题。这些缺失的响应在分析过程中被忽略 数据 并被编码为“- 9”以确保将它们排除在分析过程之外。

在准备调查问卷时，通过为每个选项分配一个数字来对封闭式问题进行预编码。然后使用该号码来准备 数据 分析期间（Denscombe 1998，Sapsford 和 Jupp 1996）。例如，B部分问题1列出了六个选项：董事会、高级管理人员、IT部门、业务部门、顾问和其他。在文件中 数据 SPSS中生成了一个变量来表示“项目发起人”，有六个值标签：“1”代表“董事会”，“2”代表“高级管理人员”等等。鉴于使用输入 SPSS 的相应数值，在一些封闭式问题中使用 Likertin 量表也可以轻松识别。对于具有非详尽答案（不互相排斥）的问题，每个选项都被视为具有两个值标签的单个变量：“1”表示“已标记”，“2”表示“未标记”。

开放式问题与封闭式问题的处理方式不同。这些问题的答案未输入 SPSS。相反，它们是手工分析的。使用此类问题使我们能够获取有关受访者自由表达的想法和个人经历的信息（Bainbridge 1989，Denscombe 1998）。在可能的情况下，对答复进行了分类。

为了分析 数据，使用简单的统计分析方法，例如响应频率、平均值、标准差和中位数（Argyrous 1996，Denscombe 1998）。
Gamma 检验在获得各变量之间关联的定量测量方面表现良好 数据 序数（Norusis 1983，Argyrous 1996）。这些测试是合适的，因为所使用的序数量表没有很多类别，并且可以在表格中显示（Norusis 1983）。

3.5 总结

本章讨论了本研究采用的研究方法和设计。

为特定研究选择最合适的研究方法会考虑到
考虑许多规则，包括研究的性质和类型，以及每种可能方法的优点和缺点（Jenkins 1985，Benbasat 等人 1097，Galliers 和 Land 1987，yin 1989，Hamilton 和 ives 1992，Galliers 1992 年，诺伊曼 1994 年）。鉴于澳大利亚缺乏关于采用数据仓库的现有知识和理论，本研究需要一种具有探索能力的解释性研究方法来探索澳大利亚组织的经验。选择的研究方法是为了收集有关澳大利亚组织采用数据仓库概念的信息。选择邮寄问卷作为收集方法 数据。研究方法和收集技术的理由 数据 本章将提供选定的内容。并对分析单位、样本、答卷比例、问卷内容、问卷预测试及结果分析方法等进行了讨论。 数据.

设计 数据仓库:

结合实体关系和维度建模

摘要
存储我 数据 是许多组织当前面临的主要问题。食品储藏发展的关键问题 数据 这是他的设计。
设计必须支持概念的检测 数据仓库 遗留系统和其他来源 数据 以及实施过程中的简单理解和效率 数据仓库.
许多存储文献 数据 建议使用实体关系建模或维度建模来表示设计 数据仓库.
在本文中，我们展示了如何将两种表示形式组合在一种绘图方法中 数据仓库。使用的方法是系统的

通过案例研究进行了检验，并确定了对从业者的许多重要影响。

数据仓库

Un 数据仓库 它通常被定义为“支持管理层决策的面向主题的、集成的、随时间变化的、非易失性的数据集合”（Inmon 和 Hackathorn，1994）。学科导向和综合性表明 数据仓库 旨在跨越 Legaci 系统的功能边界，提供集成的视角 数据.
时变影响事物的历史或时间序列性质 数据 在 数据仓库，从而可以分析趋势。非易失性表明 数据仓库 它不像 数据库 OLTP 的。相反，它会定期更新， 数据 来自内部和外部来源。这 数据仓库 它是专门为搜索而不是更新完整性和操作性能而设计的。
存储i的想法 数据 这并不新鲜，这是管理目的之一 数据 自六十年代以来（The Martin，1982）。
I 数据仓库 他们提供基础设施 数据 用于管理支持系统。管理支持系统包括决策支持系统（DSS）和执行信息系统（EIS）。 DSS 是一种基于计算机的信息系统，旨在改善人类决策。 EIS 通常是一个交付系统 数据 使企业领导者能够轻松访问 数据.
A的一般架构 数据仓库 突出了的作用 数据仓库 在管理支持方面。除了提供基础设施外 数据 对于 EIS 和 DSS，al 数据仓库 可以通过查询直接访问。这 数据 包含在一个 数据仓库 这些信息基于对管理信息需求的分析，从三个来源获得：内部遗留系统、专用数据采集系统和外部数据源。这 数据 在内部遗留系统中，它们经常是冗余的、不一致的、低质量的，并且以不同的格式存储，因此必须在将它们加载到系统中之前对它们进行协调和清理。

数据仓库 （英蒙，1992 年；麦克法登，1996 年）。这 数据 来自存储系统 数据 特别的和来自来源的 数据 外部通常用于增强（更新、替换）i 数据 来自遗留系统。

有许多令人信服的理由来开发 数据仓库，其中包括通过有效利用更多信息来改进决策（Ives 1995）、支持关注整体交易（Graham 1996）以及减少 数据 对于 EIS 和 DSS（Graham 1996，McFadden 1996）。

最近的一项实证研究发现，平均而言，投资回报率 数据仓库 三年后增加了 401%（Graham，1996）。然而，其他实证研究 数据仓库 发现重大问题，包括难以衡量和分配利益、缺乏明确目的、低估利益储存过程的目的和复杂性 数据，特别是关于来源和清洁度 数据。存储我 数据 可以被认为是管理问题的解决方案 数据 组织之间。操纵 数据 作为一种社会资源，多年来它一直是世界各地管理信息系统的关键问题之一（Brancheau et al. 1996，Galliers et al. 1994，Niederman et al. 1990，Pervan 1993）。

一种流行的管理方法 数据 在八十年代，这是一个模型的开发 数据 社会的。模型 数据 Social 旨在为新应用系统的开发提供稳定的基础 数据库 以及遗留系统的重建和集成（Brancheau 等人，2017）

1989 年，古德休等人。 1988：1992，Kim 和珠穆朗玛峰 1994）。然而，这种方法存在很多问题，特别是每项任务的复杂性和成本，以及产生切实结果所需的长时间（Beynon-Davies 1994，Earl 1993，Goodhue et al. 1992，Periasamy 1994，Shanks 1997） ）。

Il 数据仓库 它是一个独立的数据库，与遗留数据库共存，而不是取代它们。因此，它允许您直接管理 数据 并避免对遗留系统进行昂贵的重建。

现有的数据设计方法

仓库

建立和完善的过程 数据仓库 它应该更多地被理解为一个进化过程，而不是传统系统的开发生命周期（代西奥，1995 年，Shanks、O'Donnell 和 Arnott 1997a）。一个项目涉及很多流程 数据仓库 如初始化、规划；根据公司经理的要求获得的信息；来源、转化、清洁 数据 以及来自遗留系统和其他来源的同步 数据;正在开发的输送系统；监测 数据仓库;以及进化过程和构造的无意义 数据仓库 （Stinchi、O'Donnell 和 Arnott 1997b）。在这本杂志中，我们重点讨论如何绘制 数据 存储在这些其他进程的上下文中。有许多建议的架构方法 数据仓库 文学博士（Inmon 1994，Ives 1995，Kimball 1994 McFadden 1996）。对每种方法都进行了简要回顾，并分析了它们的优点和缺点。

Inmon (1994) 的方法 数据仓库 设计

Inmon (1994) 提出了四个迭代步骤来设计 数据仓库 （见图2）。第一步是设计模板 数据 社交来了解我如何 数据 可以通过拆分组织内的跨职能领域进行集成 数据 存放在地区。模型 数据 它是为存储而设计的 数据 与决策有关，包括 数据 历史学家，包括 数据 推导和汇总。第二步是确定实施的主题领域。这些是基于特定组织确定的优先级。第三步是画一个 数据库 对于主题领域，要特别注意包括适当的粒度级别。 Inmon 建议使用实体和关系模型。第四步，识别源系统 数据 需要并开发转换流程来捕获、清理和格式化我 数据.

Inmon 方法的优点在于该模型 数据 社会化为整合提供基础 数据 在组织和规划支持迭代开发的范围内 数据仓库。它的缺陷是模型设计的难度和成本 数据 社会，理解两个模型中使用的实体和关系模型的困难， 数据 社会和 数据 按主题领域存储，以及 数据 的绘图的 数据仓库 为了实现 数据库 相关但不适合 数据库 多维的。

Ives (1995) 的方法 数据仓库 设计

Ives（1995）提出了一种设计信息系统的四步方法，他认为该方法适用于设计 数据仓库 （见图 3）。该方法很大程度上基于信息系统开发的信息工程（Martin 1990）。第一步是确定目标、关键成功因素以及关键绩效指标。对关键业务流程和必要信息进行建模，引导我们建立模型 数据 社会的。第二步涉及开发定义架构 数据 按区域存储， 数据库 di 数据仓库、所需的技术组件、实施和操作所需的组织支持集 数据仓库。第三步包括选择所需的软件包和工具。第四步，详细设计和施工 数据仓库。艾夫斯指出，存储 数据 这是一个受约束的迭代过程。

艾夫斯方法的优势在于使用特定技术来确定信息需求，使用结构化流程来支持集成 数据仓库，适当的硬件和软件选择，以及多种表示技术的使用 数据仓库。它的缺陷是复杂性所固有的。其他包括难以发展许多水平 数据库 之内 数据仓库 在合理的时间和成本内。

Kimball (1994) 的方法 数据仓库 设计

Kimball (1994) 提出了五个迭代步骤来设计 数据仓库 （见图 4）。他的方法特别专注于独奏的设计 数据仓库 以及优先使用维度模型而不是实体和关系模型。 Kimball 分析这些维度模型是因为企业领导者更容易理解业务，处理复杂的咨询时效率更高，并且设计 数据库 体力更有效（Kimball 1994）。金博尔认识到，发展 数据仓库 它是迭代的，并且 数据仓库 可以通过将单独的表划分为共同维度的表来将其集成。

第一步是确定需要完善的特定主题领域。第二步和第三步涉及维度建模。在第二步中，测量确定主题领域中感兴趣的事物并将它们分组到事实表中。例如，在销售主题区域中，感兴趣的度量可能包括销售的商品数量和作为销售货币的美元。第三步涉及确定维度，即对事实进行分组的方式。在销售主题区域中，相关维度可能包括项目、位置和时间段。事实表具有将其链接到每个维度表的多部分键，并且通常包含大量事实。相反，维度表包含有关维度和可用于对事实进行分组的其他属性的描述性信息。关联的提议的事实和维度表由于其形状而形成所谓的星型模式。第四步涉及建立一个 数据库 多维度完善星形图案。最后一步是识别源系统 数据 需要并开发转换流程来捕获、清理和格式化我 数据.

Kimball 方法的优点包括使用维度模型来表示 数据 存储起来，使其易于理解并实现高效的物理设计。也可以轻松使用这两个系统的维度模型 数据库 关系可以完善或者系统 数据库 多维的。它的缺陷包括缺乏一些技术来促进在一个星形图案中规划或集成许多星形图案。 数据仓库 以及从极端非规范化结构设计成维度模型的难度 数据 在遗留系统中。

McFadden (1996) 的数据方法 仓库设计

McFadden (1996) 提出了一个五步方法来设计 数据仓库 （见图 5）。
他的方法基于对文献中的想法的综合，并专注于单一的设计 数据仓库。第一步涉及需求分析。尽管没有规定技术规范，但麦克法登的注释确定了这些实体 数据 规范及其属性，并参考 Watson 和 Frolick (1993) 读者进行需求捕获。
第二步，设计实体关系模型 数据仓库 然后由公司高管进行验证。第三步包括确定遗留系统和外部源的映射 数据仓库。第四步涉及开发、部署和同步过程 数据 在 数据仓库。最后一步，开发系统交付，特别强调用户界面。麦克法登指出，绘图过程通常是迭代的。

麦克法登方法的优势在于企业领导者参与确定需求以及资源的重要性 数据，他们的清洁和收集。它的缺陷包括缺乏分解大型项目的流程 数据仓库 在许多综合阶段，并且

难以理解设计中使用的实体和关系模型 数据仓库.

选择我们的不仅是那些与我们亲近的人。