数据仓库建模方法论_第1页
数据仓库建模方法论_第2页
数据仓库建模方法论_第3页
数据仓库建模方法论_第4页
数据仓库建模方法论_第5页
已阅读5页,还剩42页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、数据仓库建模方法学,数据仓库概念数据仓库数据体系结构逻辑数据模型数据模型标准化流程,主题,数据仓库领域的两位主管,Bill Inmon数据仓库的上级,数据仓库概念的创始人理论:公司信息工厂(cif)主要著作:数据仓库,数据仓库Ralph Kimball数据仓库著名学者理论:mutil dimensional architecture(MD)、企业数据仓库EDW、数据仓库特性、企业信息工厂、数据仓库总线、企业总线、总线体系结构表、多维体系结构与企业信息工厂体系结构比较多维数据库是将数据组织到多维数据存储中的数据管理系统。使用时必须将数据从关系数据库重新传输到多维数据库,然后才能访问多维数据库。也

2、称为面向交易的处理系统,其基本特征是能够立即将客户的原始数据传送到计算中心,并在很短的时间内提供处理结果。这样做的最大优点是,立即处理输入的数据,并及时回答。也称为实时系统(Real time System)。测量在线事务处理系统的重要性能指标是系统性能,它表示为实时响应时间(即用户从终端发送数据后计算机响应此请求所需的时间)。OLTP数据库旨在通过仅写入事务应用程序所需的数据,尽快处理单个事务。、on-line analytical processing、on-line transaction processing、OLTP和OLAP、ROLAP基于关系数据库的OLAP实现(Relation

3、al OLAP)、MOLAP 交易流、会计单位、金融工具、风险缓解、市场数据、度量结果、披露信息、数据挖掘模型、风险引擎数据接口、星型模型、报告模型、多维分析模型、风险计算引擎、信用风险、绩效度量和资本分配、法规遵从性和披露、市场风险数据仓库概念数据仓库模型逻辑数据模型标准化流程、主题、为什么需要逻辑数据模型、为实施复杂数据仓库系统提供规范和基础架构蓝图确定业务部门用户和IT分析人员之间的有效沟通业务需求解决业务问题统一识别部门之间重要业务定义和术语的所有业务表示、技术缓冲层ETL专用纯技术层完全与源系统结构匹配。 几乎源模型层基本上根据源系统建模使业务系统保持原始状态,统一模型层提供集成主题

4、设计的规格和共享,应用程序市场层使用按需定制多维建模聚合数据。数据挖掘模型、风险引擎数据接口、星型模型、报告模型、多维分析模型、摘要层次、交易方、财务、产品、资产、事件、内部机构、协议、测量结果、市场数据、LDM在数据仓库系统中的位置、设计思路比较、稳定可靠的性能:可以长时间保持稳定性,持续生成、更改,并回答无法预定义的业务问题。规格,易于理解:使用业务语言设计模型,使业务人员理解和使用模型更加方便;IT和业务部门人员之间的通信;25、逻辑视图(级别3)、主题领域(级别1)、概念(级别2)、逻辑数据模型的不同级别;逻辑数据模型的主题域;主题域确定新实体时,可以根据定义确定实体的相应主题域。根据

5、主题域划分工作量可以最大限度地减少重复工作量,并提供了基于数据的高级项目分区方法,以帮助交叉协调数据仓库项目选择。在确定项目开发顺序时,需要考虑业务优先级、技术实施难度、人员可用性等信息,以帮助通过数据仓库开发确定哪些相关业务专家,主题域模型目标提供对每个主题域的广泛理解,包括各种主题域的名称和定义,通过业务规则连接这些主题域,以形象地表示这些主题之间的依赖性和规则。由于主题域分层结构,主题域模型更容易复盖广泛的领域。业务规则可以为主题域模型添加更多的准确性和清晰度。通过直观地表示范围确定主题域及其业务规则,更容易确定要分析的模型的范围。引线主题域模型提供了全景视图,以帮助确定正在规划的应用程

6、序与现有应用程序共存的方式。下一步,企业需要哪些新功能?主题域模型提供了方向和指导。建立对业务的高级理解,为逻辑数据分析和建模奠定基础,主题域模型,概念模型,影响数据仓库粒度级别的关键因素,汇总数据将提高数据传递处理性能,聚合数据不会节省存储空间。因为生成摘要的详细信息可以继续保留。聚合带来的好处主要是,在线存储需求减少分析的标准化和数据传递性能的提高整合对象可以减少连接操作的数量,从而提高数据传递处理性能并提高一致性。数据隔离根据可靠性和用途隔离数据。可靠性分析根据单个数据属性是否经常更改将这些属性分组。数据仓库粒度级别、逆向标准化指南、风险数据集市汇总层、风险数据集市应用程序层、数据仓库概

7、念数据仓库逻辑数据模型数据模型标准化流程、主题、数据模型标准流程概述、项目准备和计划、项目准备和计划阶段,模型设计人员的主要作用是实施与模型相关的项目,包括确定数据源范围、最终提交内容和项目时间表,确定项目联系人在此阶段,将确定参与项目实施的所有人员(包括全职和兼职员工)的列表。在决定模型员工时,请考虑以下要求:熟悉建模工具的使用模型设计经验熟悉银行业务强大的通信表达能力数据敏感度、数据收集、实施战略制定模型相关数据源范围里程碑提交作业时间表、项目启动、项目启动阶段、模型设计者参与开发模型相关工作流、标准文档的客户化,组织整个项目组中的模型培训,明确数据模型在整个信息体系结构中的位置和作用,并

8、就如何工作达成一致。确定划分不同组工作界限的工作流开发模型组人员的工作分配决策项目组内部和外部工作模型确定公司标准项目实施流程客户指定、模型培训、源系统介绍客户介绍源系统:系统体系结构/设计理念/系统定位业务功能/关键流程关键数据表、关系和其他系统的关系、系统要求、系统要求阶段,模型设计人员将成为业务顾问(由业务顾问主导),业务面试业务面试阶段设置面试议程和内容:面试目的/面试方法/问卷填写:说明填写/互换意见内容采访流程记录:确认联系人确认记录/录音人员确认:确认对应人员,后续活动模型设计人员参与业务面试流程内容摘要阶段模型设计人员整理文档:收集和整理面试配置文件/整理/整理/不明确需求分析

9、查看与业务数据分析相关的指标条件分析维统计口径计算公式处理周期功能分析目的和使用流程调查报告格式、显示方法权限分配、用户管理补充数据业务要求报表的模型相关内容要求报表类要求:报表要求分类、报表目的概览。 报告的访问频率、使用部门、权限要求报告数据项定义、查询条件报告样式分析类要求包括分析类要求分类、简要分析目的访问频率、部门使用、权限要求分析维定义分析指标定义、信息调查,在此阶段,由模型设计人员主导,并根据系统要求调查分析系统数据满足情况。模型设计者解释业务需求陈述中出现的问题,并将其记录在业务需求问题跟踪表中,以便进行跟踪确认。业务顾问应根据数据满意度的数据差距确认或更改相应业务要求报表的内

10、容。设置主题域、确认重要业务关系、创建概念模型等,构建模型设计者主导的概念模型。如果项目具有规范团队,则规范团队将主导“定义规范主要”操作。由模型设计者主导的逻辑数据模型详细设计,逻辑数据模型设计。业务代表应该确认模特职员提出的重要规则和处理原则。由技术人员主导的物理数据模型设计,转换为可以具体实施逻辑数据模型的物理数据模型,并由逻辑模型设计人员支持。物理数据模型与平台紧密相关,因此在实际数据库平台上谈论物理数据模型在更高的操作性、系统开发和单元测试、系统开发和单元测试阶段,模型设计者主要起到支持的作用,为开发人员解释模型,支持开发人员进行数据映射和相关性验证等工作,验证单元测试的结果,根据测

11、试中发现的问题进行适当的修改和更改,支持模块开发模型说明和解释支持数据映射支持相关性验证, 支持模块单元测试支持单元测试结果验证、错误原因分析修正支持、设计改进开发和测试中发现的问题协调模型、模型更改、优化、逻辑数据模型状态检查逻辑数据模型状态检查是逻辑数据模型设计和维护关键项目的定期评估和审查活动、尽早发现可能的问题和缺陷、提高人员意识、合理化改进建议、规格和流程改进、逻辑数据模型的健全和持续改进,体系结构级别运行状况检查全面体系结构检查项目之间的关系是否完整,适用的业务范围是否适当,是否合理检查支持和服务的应用。主题体系结构检查每个主题的核心分类是否正确,验证可扩展性确保核心实体的业务定义

12、正确明确使用父子结构和重要关联表等技术验证业务规则是否有详细的子主题,分隔的详细程度是否适当。 管理流程状态检查使用版本检查工具检查是否管理版本检查不同版本的标准验证每个版本更改的主要原因是如何管理检查历史版本,是否有版本的简要说明? 检查维护检查是否有活动的系统更改管理流程分析要求更改管理流程检查统计摘要处理规则更改管理流程元数据检查模型是否有发布机制检查模型是否可以与元数据保持同步业务人员是否可以查询所需信息。 业务级别运行状况检查易用性检查用户了解模型和数据的所有方法检查是否有有用的文档检查培训系统一致性检查现有业务规则的处理情况检查新业务规则或已更改业务规则的所有处理方法确定正在使用的

13、关键问题的内容检查业务规则在不同层之间的一致性完整性检查业务应用程序中是否存在缺失的项目检查业务信息丢失业务信息的原因检查已采用的业务数据是否完整、一致、完全优化。 检查物理数据模型优化检查用于优化物理数据模型的工作点检查字段命名符合规格参考物理模型设计阶段设置的命名规则:了解规格不足字段的原因并确定是否更正。 确保字段数据类型符合规格检查字段中的数据类型的处理规则、加载要求和应用要求。如果打开了数据类型指定,则必须对照数据类型指定进行检查。查找为数据量大小的前20个表加载此20个表的所有脚本。查找使用这20个表的所有脚本和查询。在这些脚本和查询中,查看这些大型表的常规用法(如条件)和实际性能绩效。结合上述信息,分析使用的数据库的物理特性是否合理(例如,分区、索引等)。例如,检查是否需要修改不合理的讨论:是否需要添加其他物理特性(如是否需要拆分大表、是否需要合并当前分离的表等)。提供初步测试后的更正建议在最慢的前20个脚本和一些具有代表性且可重用的较慢的随机查询中查找导致这些脚本和查询运

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论