C. 数据仓库 — 生命周期

概述

  • 第一步：程序/项目规划
  • 第二步实施（程序/项目管理）：业务需求定义
  • 技术结构设计
  • 产品选择安装
  • 维度建模
  • 物理设计：ETL设计与开发
  • BI应用设计：BI应用开发
  • 第三步部署（程序/项目管理）
  • 第四步
  • 发展 — 重新规划程序/项目
  • 维护

程序/项目规划与管理

  • 评估准备
  • 一个强有力的执行业务主管理想情况下，业务主管具有成功完成其他内部活动的经历。他们应该是能够说服其他领导支持该项目的政策上精明的领导。如果首席信息官是指定赞助商，则项目将会冒更大的风险。我们更喜欢现实的承诺而不是业务同事。
  • 一个强大的、解决DW/BI活动的引人注目的动机。DW/BI项目需要解决关键的业务问题，这一工作需要为获得成功的开始和健康的生命期而获取资源。
  • 评估可行性数据可行性：从实际的操作型源系统中收集的数据能够支持业务的需求吗？技术和资源的可行性
  • 范围及论证
  • 先考虑单一业务过程，在考虑多过程项目。在确定项目范围的时候，要避免“太”原则 — 项目时间表“太”短暂，涉及“太”多的系统，包含“太”多的位于“太”多不同位置的具有“太”多不同分析需求的用户。
    项目论证需要评估与DW/BI初启工作有关的利益和成本。
  • 人员配备
  • 从业务层面考虑，需要以下角色的人
  • 业务发起人：有可能是老板
  • 业务驱动者：实际执行的人
  • 业务领导者：有时候由业务驱动者扮演
  • 业务用户：需要尽早且经常性地参与确定项目范围和业务需求。
  • 人员配置
  • 业务分析师
  • 数据管理师
  • BI应用设计人员/开发人员
  • 以下角色来自IT组织
  • 项目经理
  • 技术架构师
  • 数据架构师/建模者
  • 数据库管理员
  • 元数据协调人
  • ETL架构师/设计人员
  • ETL开发人员
  • 规划的开发及维护
  • DW/BI项目的范围极易发生变化，在面对变化时，应该具有多种选择：
  • 增加范围：铜鼓增加时间、资源或预算
  • 执行零和游戏：以放弃某些要求为交换条件而保持原有范围（这里的范围指的是时间、资源或预算）不变
  • 或者说“不”：并非直接否定，而是通过将变化当成增强的需求来处理

业务需求定义

  • 需求预规划
  • 讨论话题
  • 不要问数据的粒度和维度的问题。应该问他们希望做什么，为什么要做，他们是如何制定决策的，他们希望未来能制定什么样的决策。
  • 方式：用户访谈或用户联席会。调查表并非是获取需求的合理工具，因为它们是平面的、二维的。其选项是我们提前考虑好的答案，无法获得更深入的情况。
  • 确定及筹备需求小组
  • 选择、调度和准备业务代表
  • 在目标用户团队内部，应当垂直地覆盖组织。DW/BI项目小组自然地趋向于构建强大的分析能力。尽管他们的见识是有价值的，但是不能忽略企业高级和中层管理人员。否则就会过度关注战术，而把握不住小组的战略方向。
  • 收集业务需求
  • 初启：会议开始几分钟，应该确定以业务为中心的基调。
  • 访谈流程：让业务用户说清楚他们做什么和为什么要做。此后，通常会询问一些受访者的关键指标度量，确定他们是如何跟踪进展并成功地将这些指标直接放入到维度模型中。不需要直接问，他们就会将其关键业务过程和事实告诉您。
  • 形成最终文档：访谈进入最后总结阶段时，请每个受访者提出有关项目成功的关键评判标准。当然，关键评判标准应该是可度量的。
  • 指导以数据为中心的访谈
  • 目标是查明在建立需求的动力前，需要的核心数据是否已经存在。在访谈过程中，深入了解一些初期的随后需要提供的数据分析结果。例如：一些关键数据字段的领域值和计数，这样可以确保您不至于站在流沙之上。
  • 文档化需求
  • 需求优先级

技术路径

  • 技术架构设计
  • 建立架构工作组
  • 收集与架构有关的需求
  • 架构需求文档化
  • 建立架构模型
  • 确定架构实现阶段
  • 设计并定义子系统
  • 建立架构规划
  • 评审及确定技术架构
  • 产品选择与安装
  • 了解公司的采购流程
  • 建立产品评价矩阵
  • 进行市场调研
  • 评价的选项列表不要太多
  • 必要情况下构建原型系统
  • 选择产品、安装试验以及谈判

数据路径

  • 维度建模 — 维度建模过程与任务
  • 概述
  • 关键输入：初始的总线矩阵和详细的业务需求
  • 建模过程的交付成果：高级维度建模、详细维度表和事实表设计以及问题日志
  • 维度建模过程流程
  • 准备
  • 高级维度模型
  • 详细维度模型开发（迭代与测试）
  • 模型评审与验证
  • 最终设计文档
  • 组织工作
  • 确定参与人，特别是业务代表们
  • 业务需求评审
  • 利用建模工具
  • 利用数据分析工具
  • 利用或建立命名规则
  • 日历和设施的协调
  • 维度模型设计
  • 统一对高层气泡图的理解尽管有经验的设计人员可能会设计出初始的高层维度模型并展示给小组用户评审，但是我们不建议采用这种方法，因为它没有使整个小组参与到过程中。
  • 开发详细的维度模型
  • 确定维度及其属性
  • 确定事实
  • 确定缓慢变化维度技术
  • 建立详细的表设计文档
  • 对模型出现的问题进行跟踪
  • 维护并更新总线矩阵
  • 模型评审与验证
  • IT评审
  • 核心用户评审
  • 广泛的业务用户评审
  • 形成设计文档，文档包括：
  • 项目的简短描述
  • 高级数据模型图
  • 详细的针对每个事实和维度表的维度设计工作单
  • 开发的问题
  • 物理设计：物理数据库实现细节随平台和项目的不同而存在较大的差异
  • 开发命名机及数据库标准
  • 表明和类名是用户体验的关键。同时还需要确定是否允许存在空值。
  • 开发物理数据库模型
  • 应该尽早建立在开发服务器中，以便能够被ETL开发小组使用。
  • 开发初始索引规划
  • 设计聚合，包括OLAP数据库
  • 出于性能要求，有时候需要建立聚集表当性能度量被聚集后，要么删减维度，要么将度量与遵守原子基本维度的缩减上卷维度关联。由于不可能建立、仓储、管理所有理论上可能存在的聚集，因此需要考虑两个主要的评价因素
  • 考虑从需求文档中获取的业务用户的访问模式，以及通过监控实际使用模式所获得的输入
  • 通过评价数据的统计分布以提供划算的聚集点
  • 确定物理存储细节
  • ETL设计与开发

BI应用路径

  • BI应用规范
  • 收集示例报表以确定包含大约10~15个BI报表和分析应用。
  • BI应用开发

总结活动

  • 部署
  • 维护和发展
  • 用户支持
  • 教育或培训
  • 技术支持
  • 程序支持