管理数据仓库的实施项目.pptxVIP

成功地管理数据仓库的实施;如何成功地实施数据仓库项目;常听到人们说:让我们建一个数据仓库吧;但是， 超过60%的数据仓库项目是失败的 ;失败的最主要原因是什么? 对要建立的数据仓库没有清晰的定义 如果你没有一个明确的，确定的目标要完成，你怎么能够成功呢? 低估了实施 数据抽取和转换的时间/工作量即使考虑到，也是很不充分的 允许范围不断增加，超出了可以做到的范围;失败的最主要原因是什么? 但是很可能, 导致失败的最主要原因是“用户”没有参与进来 没有与用户会面交谈或咨询用户 系统建设不是针对使用者的需求 闭门造车的方式建立系统 系统的建设不是针对解决任何特定的问题;导致的结果: 以上种种最终导致精神上的崩溃 太多的工作 太少的时间 事情变化太快 不知道目的是什么 漫无目的地徘徊，这样领导项目很难跟随;很有可能，项目/计划的管理者根本没有了解或考虑一些关键的方面： 哪些方面………;用户 谁是 “用户”? 他们需要一个数据仓库吗? 他们的需求到底是什么? 更快的报表? 新的报表? 他们什么时候需要一个系统? 他们愿意付钱或提供资金开发吗?;哪些关键的方面?;报表 有没有清楚地详细说明报表的定义? 是已有的报表吗? 还是希望有的报表清单? 列出的报表，是否有优先顺序? 与所有用户就报表的定义和内容达成一致了吗?;数据 需要什么数据? 数据从哪里来? 谁 “拥有” 数据? 你能访问到这些数据吗? 有多少数据是必需的 是否有足够的带宽获得这些数据? 数据刷新/传递的需求是什么?;谁也不能担保成功。但是通过以下的努力，你可以有最大的机会得到一个有用的系统： 以一种仔细地、有系统地和结构化的方式实施数据仓库. 制定出一个计划 严格按计划执行 不要超越范围 不要超越需求;如何能够成功？;如何能够成功？;以恰当的方式实施 也许这种恰当的实施方式会花更长的时间和更多的精力，但却能使你更有可能： 成功 交付一个有用的系统 提交你所承诺的 保住你的工作. ;我应该做什么?;我能做什么？;我能做什么？;我能做什么？;总结起来;详细的实施步骤;决定你所要建立的是什么 企业级数据仓库? 即席查询服务器? 常规的报表服务器? 单独专注的数据集市? 根据用户的需要做出你的决定 实施范围要限定在你能实际做到的范围内!!!!!! ;定义系统需求 基于用户的需要 正式的文档，准确地描述最终的系统所能完成的功能 与用户一起复审需求, 即. 进行正式的系统需求复审 不要让范围扩大 – 瞄准最初的目标/规划 提交一个系统需求规格说明书 ;定义系统需求 不要陷入需求的“分析怪圈” 决定你能做到什么 锁定那些需求，舍弃其他，放到未来的阶段 确保向用户概述了你能够实施的内容 这样也许不能使所有的用户都满意，但是，成功地实现了用户需要的一部分（子集）比试图建立一个超级系统却以失败而告终，什么都不能交付好的多。 ;投入和费用要实际 基于系统需求分析 确定完成需求所必需的资源 人员 时间/进度 硬件/软件 不要乐观地估计 会发生意外的问题 计划赶不上变化 错误不可避免!;制订一个正式的项目计划 基于 系统需求分析 成本估计 进度估计 可用资源 将范围局限在你能够做到的范围之内 提交正式的项目计划 ;制订一个正式的项目计划 切记: 正式的项目计划可以确保每一个人（管理者和开发人员）及时了解开发的最新情况，及时发现开发中出现的问题。 ;制订一个正式的项目计划 最后, 记住: 承诺少一点，然后交付多一点 要比 承诺太多，令人失望 更好 ;进行详细的数据分析 基于用户的需要和报表 找到提供报表所需数据的遗留/现有的系统 获得任何/所有关于现有数据的文档 获得对所有数据源的访问和使用权 决定是否需要有抽取程序 ;进行详细的数据分析 确定必需的转换 数据的清洗? 查找Lookup/确认? 合并? 你想要这个过程自动执行吗? 抽取, 转换, 装载 (ETL) 工具? 定制代码和/或脚本?;进行详细的数据分析 确定必需的数据更新频度 需要多长时间刷新一次数据? 如何更新数据? 自动化的过程 复制 ETL工具 定制的代码和/或手工的脚本 ;进行详细的数据分析 数据分析应获得以下结果 数据字典, 包含 遗留（Legacy)的数据定义及其分布位置 新的数据仓库的数据定义 数据规模，类型，单位，例外，等等。 这还不是数据模型，此时你还没有足够的信息来建立系统的模型。;进行详细的数据分析 数据分析应获得以下结果 接口文档, 包含: 将数据从现有系统迁移到数据仓库的ETL过程 转换 规则/标准 刷新/实时性需求和详细规格说明;下一步? 系统需求分析和数据分析是详细系统设计的基础 记住: 基础不好，设计也不会好且非常局限 稳固的基础将为设计奠定一个坚实、可扩的基础;详细系统设计 再次强调，这项工