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