数据仓库-交付流程
数据仓库从来都不是静态的；它随着业务的扩展而发展。随着业务的发展，其需求不断变化，因此数据仓库的设计必须能够适应这些变化。因此，数据仓库系统需要灵活。
理想情况下，应该有一个交付流程来交付数据仓库。然而，数据仓库项目通常会遇到各种问题，导致很难按照瀑布方法要求的严格有序的方式完成任务和交付成果。大多数时候，需求并没有被完全理解。只有收集和研究所有需求后才能完成架构、设计和构建组件。
运输方式
该交付方法是数据仓库交付所采用的联合应用程序开发方法的变体。我们已经分阶段进行了数据仓库交付流程，以最大程度地降低风险。我们将在这里讨论的方法不会缩短总体交付时间范围，而是确保通过开发过程逐步交付业务利益。
注- 交付过程分为多个阶段，以降低项目和交付风险。
下图解释了交付过程的各个阶段 -
信息技术战略
数据仓库是需要业务流程才能产生效益的战略投资。IT 战略需要为项目获取和保留资金。
商业案例
业务案例的目标是估计使用数据仓库应获得的业务收益。这些效益可能无法量化，但需要明确说明预计的效益。如果数据仓库没有明确的业务案例，那么业务在交付过程中的某个阶段往往会出现可信度问题。因此，在数据仓库项目中，我们需要了解投资的业务案例。
教育和原型制作
在确定解决方案之前，组织会尝试数据分析的概念并了解数据仓库的价值。这是通过原型设计来解决的。它有助于了解数据仓库的可行性和好处。小规模的原型制作活动可以促进教育进程，只要 -
该原型解决了既定的技术目标。
在展示可行性概念后，原型可以被丢弃。
该活动涉及数据仓库最终数据内容的一小部分。
活动时间范围并不重要。
为了尽早发布并带来商业利益，应牢记以下几点。
确定能够发展的架构。
重点关注业务需求和技术蓝图阶段。
将第一个构建阶段的范围限制到能够带来业务收益的最小范围。
了解数据仓库的短期和中期要求。
业务需求
为了提供高质量的交付成果，我们应该确保总体要求得到理解。如果我们了解短期和中期的业务需求，那么我们就可以设计一个解决方案来满足短期需求。然后可以将短期解决方案发展为完整的解决方案。
此阶段确定以下几个方面 -
要应用于数据的业务规则。
数据仓库内信息的逻辑模型。
查询配置文件的即时需求。
提供此数据的源系统。
技术蓝图
此阶段需要提供满足长期需求的整体架构。此阶段还提供必须在短期内实施才能获得任何业务利益的组件。蓝图需要确定以下内容。
- 系统整体架构。
- 数据保留政策。
- 备份和恢复策略。
- 服务器和数据集市架构。
- 硬件和基础设施的容量计划。
- 数据库设计的组成部分。
构建版本
在此阶段，将产生第一个生产交付物。该生产可交付成果是数据仓库的最小组件。这个最小的组件增加了商业利益。
历史负载
在此阶段，所需历史记录的其余部分将加载到数据仓库中。在此阶段，我们不会添加新实体，但可能会创建额外的物理表来存储增加的数据量。
让我们举个例子。假设构建版本阶段交付了一个具有 2 个月历史的零售销售分析数据仓库。这些信息将允许用户仅分析最近的趋势并解决短期问题。在这种情况下，用户无法识别年度和季节性趋势。为了帮助他做到这一点，可以从档案中加载最近两年的销售历史记录。现在40GB数据扩展到400GB。
注- 备份和恢复过程可能会变得复杂，因此建议在单独的阶段中执行此活动。
即席查询
在此阶段，我们配置一个用于操作数据仓库的即席查询工具。这些工具可以生成数据库查询。
注意- 当数据库被大量修改时，建议不要使用这些访问工具。
自动化
在此阶段，运营管理流程完全自动化。这些将包括 -
将数据转换为适合分析的形式。
监视查询配置文件并确定适当的聚合以维护系统性能。
从不同源系统提取和加载数据。
从数据仓库中的预定义定义生成聚合。
备份、恢复和归档数据。
扩大范围
在此阶段，数据仓库被扩展以满足一组新的业务需求。范围可以通过两种方式扩展 -
通过将附加数据加载到数据仓库中。
通过使用现有信息引入新的数据集市。
注- 此阶段应单独执行，因为它涉及大量的工作和复杂性。
需求演变
从交付过程来看，需求总是在变化的。它们不是静态的。交付流程必须支持这一点并允许这些更改反映在系统中。
通过围绕业务流程中数据的使用（而不是现有查询的数据要求）设计数据仓库，可以解决此问题。
该架构旨在更改和扩展以匹配业务需求，该流程作为伪应用程序开发流程运行，其中新的需求不断地输入到开发活动中并生成部分可交付成果。这些部分可交付成果被反馈给用户，然后进行重新设计，以确保整个系统不断更新以满足业务需求。