数据仓库-交付过程

  • 简述

    数据仓库永远不是静态的;它随着业务的扩展而发展。随着业务的发展,其需求不断变化,因此数据仓库的设计必须能够适应这些变化。因此,数据仓库系统需要具有灵活性。
    理想情况下,应该有一个交付过程来交付数据仓库。然而,数据仓库项目通常会遇到各种问题,导致难以按照瀑布方法所要求的严格有序的方式完成任务和可交付成果。大多数时候,需求没有被完全理解。只有在收集和研究所有需求后,才能完成架构、设计和构建组件。
  • 运输方式

    交付方法是为交付数据仓库而采用的联合应用程序开发方法的一种变体。我们已经分阶段进行数据仓库交付流程,以最大限度地降低风险。我们将在此处讨论的方法不会缩短总体交付时间尺度,但会确保通过开发流程逐步交付业务收益。
    Note− 交付过程分为多个阶段以降低项目和交付风险。
    下图解释了交付过程的各个阶段 -
    运输方式
  • 资讯科技策略

    数据仓库是需要业务流程产生收益的战略投资。需要 IT 战略来为项目获取和保留资金。
  • 商业案例

    业务案例的目标是估计使用数据仓库应该获得的业务收益。这些好处可能无法量化,但需要明确说明预计的好处。如果数据仓库没有明确的业务案例,那么业务往往会在交付过程的某个阶段出现可信度问题。因此在数据仓库项目中,我们需要了解商业案例进行投资。
  • 教育和原型设计

    组织尝试数据分析的概念,并在确定解决方案之前就拥有数据仓库的价值进行自我教育。这是通过原型设计解决的。它有助于理解数据仓库的可行性和好处。小规模的原型制作活动可以促进教育过程,只要 -
    • 原型解决了定义的技术目标。
    • 在展示可行性概念后,可以丢弃原型。
    • 该活动涉及数据仓库最终数据内容的一小部分。
    • 活动时间尺度是非关键的。
    要提前发布并带来商业利益,请牢记以下几点。
    • 确定能够发展的架构。
    • 关注业务需求和技术蓝图阶段。
    • 将第一个构建阶段的范围限制在能够带来业务收益的最小范围内。
    • 了解数据仓库的短期和中期要求。
  • 业务需求

    为了提供高质量的可交付成果,我们应该确保了解总体要求。如果我们了解短期和中期的业务需求,那么我们可以设计一个解决方案来满足短期需求。然后可以将短期解决方案发展为完整解决方案。
    在此阶段确定以下方面 -
    • 要应用于数据的业务规则。
    • 数据仓库中信息的逻辑模型。
    • 即时需求的查询配置文件。
    • 提供此数据的源系统。
  • 技术蓝图

    该阶段需要交付满足长期需求的整体架构。此阶段还交付必须在短期内实施以获得任何业务利益的组件。蓝图需要确定以下内容。
    • 整体系统架构。
    • 数据保留政策。
    • 备份和恢复策略。
    • 服务器和数据集市架构。
    • 硬件和基础设施的容量计划。
    • 数据库设计的组成部分。
  • 构建版本

    在这个阶段,第一个生产可交付成果被生产出来。此生产可交付成果是数据仓库的最小组件。这个最小的组件增加了商业利益。
  • 历史加载

    这是将所需历史记录的其余部分加载到数据仓库的阶段。在此阶段,我们不会添加新实体,但可能会创建额外的物理表来存储增加的数据量。
    让我们举个例子。假设构建版本阶段交付了一个具有 2 个月历史价值的零售销售分析数据仓库。此信息将允许用户仅分析最近的趋势并解决短期问题。在这种情况下,用户无法识别年度和季节性趋势。为帮助他这样做,可以从存档中加载最近 2 年的销售历史记录。现在40GB数据扩展到400GB。
    Note− 备份和恢复过程可能会变得复杂,因此建议在单独的阶段执行此活动。
  • 即席查询

    在此阶段,我们配置一个用于操作数据仓库的临时查询工具。这些工具可以生成数据库查询。
    Note− 当数据库被大量修改时,建议不要使用这些访问工具。
  • 自动化

    在此阶段,运营管理流程完全自动化。这些将包括 -
    • 将数据转换为适合分析的形式。
    • 监视查询配置文件并确定适当的聚合以维护系统性能。
    • 从不同的源系统提取和加载数据。
    • 从数据仓库中的预定义定义生成聚合。
    • 备份、恢复和归档数据。
  • 扩大范围

    在此阶段,扩展数据仓库以满足一组新的业务需求。范围可以通过两种方式扩展 -
    • 通过将附加数据加载到数据仓库中。
    • 通过使用现有信息引入新的数据集市。
    Note− 此阶段应单独执行,因为它涉及大量工作和复杂性。
  • 需求演变

    从交付过程的角度来看,需求总是多变的。它们不是静态的。交付过程必须支持这一点,并允许这些更改反映在系统中。
    这个问题通过围绕业务流程中数据的使用设计数据仓库来解决,而不是现有查询的数据需求。
    该体系结构旨在改变和发展以满足业务需求,该过程作为伪应用程序开发过程运行,其中不断将新需求提供给开发活动并产生部分可交付成果。这些部分可交付成果被反馈给用户,然后进行返工,确保整个系统不断更新以满足业务需求。