数据仓库建模方法论课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,数据仓库建模方法论,*,数据仓库建模方法论,2024/8/23,数据仓库建模方法论,数据仓库建模方法论2023/8/31数据仓库建模方法论,1,数据仓库概念,数据仓库数据架构,逻辑数据模型,数据模型标准化工艺流程,主题,数据仓库建模方法论,数据仓库概念主题数据仓库建模方法论,2,数据仓库领域的两位大师,Bill Inmon,数据仓库之父，数据仓库概念的创始人,理论： Corporate Information Factory(CIF),主要著作：数据仓库、企业信息工厂,主要著作：数据仓库工具箱维度建模的完全指南、,数据仓库生命周期工具箱 设计、开发和部署数据仓库的专家方法,Ralph Kimball,数据仓库方面的知名学者,理论：Mutildimensional Architecture(MD),数据仓库建模方法论,数据仓库领域的两位大师Bill Inmon主要著作：数据仓,3,企业数据仓库EDW,企业数据仓库定义：,详细交易及相关业务数据的集合􀂋,包含必要的内部与外部信息􀂋,来自于多个数据源/业务操作系统􀂋,保存一定的时间周期􀂋,按照企业内业务规则所决定的模型来存储,企业数据仓库作用：,基于数据/信息来回答相关的业务问题和提供决策支持，并确保：一致、集成的数据存储􀂾,任意的数据粒度􀂾,在整个企业的业务范围􀂾,保持企业内一致的信息视图,企业内一致的信息视图,（Single Version of the Truth）,集成的企业信息（,Integrated corporate information,）,不针对特定应用（,Application neutral,）,无冗余（,Non redundant,）,用于报表和决策支持（,Reporting and decision making,）,最详细的数据和信息,（,Detailed Data,）,任何时候，针对任意数据，提出任意业务问题,（,Ask any question, any data, any time,）,数据仓库建模方法论,企业数据仓库EDW企业数据仓库定义：企业数据仓库作用：企业内,4,数据仓库的特点,数据仓库建模方法论,数据仓库的特点数据仓库建模方法论,5,企业信息工厂,数据仓库建模方法论,企业信息工厂数据仓库建模方法论,6,数据仓库总线,数据仓库建模方法论,数据仓库总线 数据仓库建模方法论,7,企业总线,数据仓库建模方法论,企业总线数据仓库建模方法论,8,总线架构矩阵,数据仓库建模方法论,总线架构矩阵数据仓库建模方法论,9,多维体系结构与企业信息工厂体系结构比较,方面,多维体系结构,企业信息工厂体系结构,范围,优先考虑业务单位范围,优先考虑企业总体范围,角度,关心,业务部门,的需求,多维建模师以企业视角，建立一致性维度。,从,企业角度,解决供应源数据的问题，但并不是整个企业的数据必须在项目第一个阶段都处理。相反而是选择企业所有数据的一个子集。,数据流,实施方法采用,自底向上,的：如何快速的获取由用户控制的业务部门专有的数据，并最小限度的考虑整个企业的使用,快速需求收集和实现过程使得为整个环境提供一致而可靠数据的任务变得复杂。,实施方法是,自顶向下,的：企业数据利用业务需求将数据从数据源推至需要这些数据的地方，其核心问题是从最初的项目开始为任何数据集市的使用而集成企业数据。,为了制定尽可能在整个企业范围内一致的主题域和业务数据需要增加模型开销，需要更多的时间和代价。但后续项目则需要较少时间和代价，尤其对于使用现有的、健全的主题域的业务单位更是如此。,实现对存储空间最小需求，非冗余方式防止了在多个位置存储数据。这种特性使更新或删除异常最小化或者消除。,易失性,聚集数据集市,：当业务过程发生变化，为了消除或减少对事实表重建，需要增加新的维或改变维。,原子数据集市,：由于事实表可能包含几亿甚至更多的数据，重建将会带来严重后果,数据仓库模型是,与过程无关,的，它摒弃了由于处理过程影响而带来的变化,数据仓库模型的设计依赖于,企业的业务规则,，而不依赖与在其上将运行什么查询。,如果一个已经建好的数据集市需要改变或加强，可以根据存储在数据仓库中的细节数据合理且快速地进行重建,灵活性,多维设计是很多,业务过程聚集,在一起的结果。当处理请求发生变化时，多维数据库的设计未必能够适度地变化。,数据仓库模型存放数据粒度级别为,原子级别,，原子级别可以任意组合。故可以支持,将来未知需求,。,复杂性,数据集市模型,易于业务人员理解,。可以很容易构建数据集市，然而，当一个一个地建立数据集市时，由于数据的企业视图的复杂性，对于这种结构，完成,更新,时,相当复杂,的。,数据仓库中的细节数据是与,处理过程无关,的，因此数据仓库的数据模型使得数据不一致的风险最小。,功能性,为,多维处理,提供了理想环境，切片和切块、上钻和下钻等查询提供良好的性能,支持,数据挖掘,、,统计分析和即席查询,持续维护,总体目标是,防止由于环境的后续构建,、调整和优化而产生的高昂的代价。一个良好的数据仓库模型将为企业提供长久的服务，将提供如下回报：,整个环境端到端一致性和集成性,易于建立新的数据集市,加强现有数据集市,数据仓库和有关数据集市的维护和可持续发展,数据仓库建模方法论,多维体系结构与企业信息工厂体系结构比较方面多维体系结构企业信,10,OLTP与OLAP,针对特定问题的联机数据访问和数据分析技术,满足对数据进行,多角度、快速、一致、交互、深入观察,使用预定义的,多维数据视图,对数据进行分析处理，支持对数据的切片、切块、钻取。,多维数据库是一种以多维数据存储形式来组织数据的数据管理系统，在使用时需要将数据从关系数据库中转载到多维数据库中方可访问。,也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。这样做的最大优点是可以,即时,地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量,联机事务处理系统的一个重要性能指标是,系统性能,，具体体现为,实时响应时间,(Response,Time)，即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。OLTP 数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。,On-Line Analytical Processing,On-Line Transaction Processing,数据仓库建模方法论,OLTP与OLAP 针对特定问题的联机数据访问和数据分析技术,11,OLTP与OLAP,OLTP,OLAP,用户,操作人员,低层管理人员,决策人员,高级管理人员,功能,日常操作处理,分析决策,DB,设计,面向应用,面向主题,数据,当前的,最新的细节的,二维的,历史的,聚集的,多维的集成的,统一的,存取,读,/,写数十条记录,读上百万条记录,工作单位,简单的事务,复杂的查询,用户数,上千个,上百个,DB,大小,100,MB-GB,100,GB-TB,ROLAP,表示基于关系数据库的,OLAP,实现（,Relational OLAP,）,MOLAP,表示基于多维数据组织的,OLAP,实现（,Multidimensional OLAP,）,数据仓库建模方法论,OLTP与OLAPOLTPOLAP用户操作人员,低层管理人员,12,ROLAP,MOLAP,沿用现有关系数据库技术,专用技术,响应速度相对molap要慢,性能好，响应速度快,数据转载计算速度快,数据转载速度慢,存储空间耗费小，维数没有限制,需要进行预计算，可能导致数据爆炸，维数有限，无法支持维的动态变化,借助rdbms对数据存储，无文件大小限制,受操作系统平台文件大小限制，难以达到tb级,可以通过sql语句实现详细数据和概要数据的存储,缺乏数据模型和数据访问的标准,不支持预计算的读写操作,无法完成维之间的运算,无法完成多行计算,支持高性能的决策支持计算,复杂的跨维计算,多用户读写操作,行级计算,ROLAP vs MOLAP,数据仓库建模方法论,ROLAPMOLAP沿用现有关系数据库技术专用技术响应速度相,13,数据仓库概念,数据仓库数据架构,逻辑数据模型,数据模型标准化工艺流程,主题,数据仓库建模方法论,数据仓库概念主题数据仓库建模方法论,14,数据架构形态,数据仓库建模方法论,数据架构形态数据仓库建模方法论,15,各数据架构比较,数据仓库建模方法论,各数据架构比较数据仓库建模方法论,16,源系统,ODS,EDW,独立数据集市,Data Mart #1,Data Mart #2,Non-conformed,Dimensions and Facts,从属数据集市,Data Mart #1,Data Mart #2,Conformed Dimensions,and,Conformed Facts,Data Mart,数据集市类型,数据仓库建模方法论,源系统ODSEDW独立数据集市Data Mart #1Dat,17,活期存款,定期存款,零售信贷,公司信贷,债券投资,票据信息,同业拆借,储蓄国债,衍生品,储蓄国债,参与者,交易流水,会计单元,理财产品,风险缓释,市场数据,计量结果,公共信息,数据挖掘,模型,风险引擎数据接口,星型模型,报表模型,多维分析模型,风险计算引擎,信用风险,绩效衡量和资本分配,合规性与披露,市场风险,操作风险,流动性风险,防欺诈和反洗钱,Enterprise Date Warehouse,ODS,风险计量结果返回,ODS,多维分析,汇总层,应用层,监管报表,风险数据集市数据架构,数据仓库建模方法论,活期存款定期存款零售信贷公司信贷债券投资票据信息同业拆借储蓄,18,风险数据集市建设目标,数据仓库建模方法论,风险数据集市建设目标数据仓库建模方法论,19,数据仓库概念,数据仓库模型,逻辑数据模型,数据模型标准化工艺流程,主题,数据仓库建模方法论,数据仓库概念主题数据仓库建模方法论,20,为什么需要逻辑数据模型,为复杂的数据仓库系统实施提供了规范和基础结构蓝图,促进业务部门用户和,IT,分析人员之间的有效沟通,明确业务需求,解决业务问题,形成对重要业务定义和术语的统一认识,具备跨部门，能够表达所有的业务,数据仓库建模方法论,为什么需要逻辑数据模型为复杂的数据仓库系统实施提供了规范和基,21,技术缓冲层,ETL专用的纯技术层,完全与源系统结构一致,近源模型层,基本依照源系统建模,尽量保持业务系统原貌,整合模型层,面向整合,主题设计,提供规范和共享,应用集市层,面向应用,按需定制,多维建模,汇总数据,核心系统,对公信贷,票据系统,储蓄国债,市场数据,核心系统,对公信贷,票据系统,储蓄国债,市场数据,.,.,复杂交易,复杂交易,数据挖掘模型,风险引擎数据接口,星型模型,报表模型,多维分析模型,汇总层,当事人,财务,产品,资产,事件,内部机构,协议,计量结果,市场数据,LDM,在数据仓库系统中的地位,数据仓库建模方法论,技术缓冲层 ETL专用的纯,22,ODS,EDW,Data Mart,Data Mining,目标,短期的，细节的，同源的数据存储,；,直接提供基于,源系统结构,的简单,原貌访问,；,为BI环境中适合的业务需求提供支持,长期的，细节的，整合,的数据存储；,为BI环境中适合的业务需求提供支持,服务,特定应用, 长期历史分析性指标汇总, 为企业提供预测性、趋势分析性需求提供支持,原则,简单处理，不考虑整合；,关注保留策略；,面向全局，数据整合,中性设计，灵活扩展,提供规范和共享,面向具体应用,按需设计,针对,业务目标,、,挖掘算法,设计数据模型,形式,偏源系统模型；,根据支持应用情况可以保留短期历史,面向主题设计,；,偏范式化；,长期保留历史,形式各异，依具体应用不同；, 一条记录表示一个观测, 多条记录表示一个观测,重点,理解源结构,主题定义,框架设计,整合策略,实施方法,整体性,一致性, 业务理解, 数据理解, 数据准备,用途,业务原貌查询,即时报表,数据质量检查,灵活查询,整合规则检查,特定应用, 特定业务专题,设计思路比较,数据仓库建模方法论,ODSEDWData MartData Mining目标短,23,EDW逻辑数据模型,设计目标,中性的，共享的,：不针对某个特别的应用而设计；,灵活的，可扩展的,：存放最详尽的历史数据，业务发生变化时易于扩展，适应复杂的实际业务情况；,稳定的，经得起考验的,：能够在很长时间内保持稳定性，回答不断产生、不断变化且无法预先定义的业务问题；,规范的，易懂的,：使用业务语言进行模型设计，易于让业务人员理解和使用，有助于,IT,和业务部门人员的沟通,数据仓库建模方法论,EDW逻辑数据模型设计目标数据仓库建模方法论,24,逻辑视图,(第三级),细节,(第三级),主题区域,(第一级),概念,(第二级),逻辑数据模型的不同级别,数据仓库建模方法论,25,逻辑视图细节主题区域概念逻辑数据模型的不同级别数据仓库建模方,逻辑数据模型的主题域,数据仓库建模方法论,逻辑数据模型的主题域数据仓库建模方法论,26,主题域模型案例-市场风险数据集市,数据仓库建模方法论,主题域模型案例-市场风险数据集市数据仓库建模方法论,27,主题域模型案例-信用卡数据集市,数据仓库建模方法论,主题域模型案例-信用卡数据集市数据仓库建模方法论,28,主题域模型优点,指导业务数据模型开发,有助于,数据一致性,，,避免冗余,。当确定一个新的实体时，基于定义可以确定实体的恰当地主题域。,根据主题域,划分工作量,，可使,重复工作量最小化,，并有利于相互协调,指导数据仓库项目选择,为基于数据的项目分组提供了一种,高层次划分方法,。在确定项目开发顺序时，应该同时考虑,业务优先级,、,技术实现难度,、,人员可用性,等信息,指导数据仓库开发,有助于确定哪些,相关的业务专家,主题域模型目标,提供广泛的理解,提供对每一个主题域的理解，包括各个主题域的,名称和定义,，通过,业务规则,将这些主题域联系起来，形象地表达这些主题之间依赖关系和规则。因为在主题域层次，所以，主题域模型更容易覆盖广泛的领域。业务规则使主题域模型增加更多的准确性和清晰性。,确定范围,通过形象地表达主题域和他们的业务规则，我们能够更容易地识别出将要分析的模型的范围。,指引方向,主题域模型能够提供全景视图，可以帮助我们确定：计划中的应用程序和现有的应用程序将怎样共存。下一步，企业将需要什么样新功能。主题域模型提供方向和指南。,建立,对业务的高层次理解,，为逻辑数据分析和建模打下基础,主题域模型,数据仓库建模方法论,主题域模型优点主题域模型目标主题域模型数据仓库建模方法论,29,概念模型,数据仓库建模方法论,概念模型数据仓库建模方法论,30,影响数据仓库粒度级别的主要因素,汇总数据,汇总数据能够,改善数据交付处理性能,，汇总数据不会节省存储空间，因为创建汇总的细节可能会继续被保留。汇总提供的好处主要包括：,在线存储需求减少,分析的标准化,以及数据交付性能的改善,合并实体通过,减少连接操作,的数量，提高了数据交付处理的性能，并且可以,增强一致性,。,分离数据,根据,稳定性和用法,来分离数据。稳定性分析根据各个数据属性是否经常变化的特性将这些属性进行分组。,影响因素,描述,当前业务需求,粒度级别必须足以回答定位在该数据仓库,迭代范围内的每一个业务问题,。提供高的,粒度级别增加了数据仓库和项目的开发成本,，如果业务不需要细节，则增加的成本就没有商业价值。,未来业务需求,按照目前明确需求建立数据仓库，但在建立并抽取数据时要适应考虑未来的需求,数据挖掘需求,数据挖掘算法需要细节级明细数据,派生数据需求,派生数据在计算时使用了其它的数据元素，除非在代价和开发时间方面有很大增长，否则所选的粒度级别应该适用于,存储所有用于派生其它数据元素的元素,。,操作系统粒度,操作源系统中,有效的细节级别,，对于,不同粒度的源系统,需要决定是否在,最低的公共级别上,抽取数据，以使所有的数据很好的整合，或者从每一个系统中根据他的有效粒度来抽取数据。,存储开销,粒度级别对存储开销有很大影响,备份和恢复,数据仓库需要周期性地进行备份和恢复，细节越多，日常备份需要的时间也越多。,数据仓库粒度级别,数据仓库建模方法论,影响数据仓库粒度级别的主要因素汇总数据影响因素描述当前业务需,31,逆规范化指南,问题类型,解决方法,关系类型,层次关系,：子对父通常有很强的依赖性。倾向于将把这些概念逆规范化到一个实体,同等关系,：,在独立的表中保存独立的实体,，可以,保证设计与业务规则保持一致,。一对一关系：如果当一个实体值仅与来自另一个实体的一个实体值相关，反之亦然。倾向于逆规范化。,确定关系,：,父实体决定子实体的意义,。通常为事务处理数据到引用数据的关系和关系实体，在多对多关系引入的关系表被认为是子，而参与多对多关系的两个表被认为是父。在事务处理引用关系中，事务处理表是子，而引用表是父。通常，,子表很大且易变,。,父表通常稳定的多且小,。所以倾向于把这两个实体保存在各自的表中。,参与率,确定关系中每个实体的参与性,。对于一个给定的父实体数值，大概会有几个子实体数值。,父子关系越接近一对一,，,将父实体逆规范化到子实体,，将有最小数量的冗余。,父实体中有多,少数据元素,如果将父实体逆规范化到子实体，保证子实体中具有存放父实体的数据元素额外空间。,使用率,两个实体的耦合或相关程度如何,。如果在许多用户查询和发布中，来自两个实体的数据元素将一起出现，那么，如果这些信息在同一表中而不是分布于多个表之内，则信息获取将会更快捷。,父实体是否变化,如果未来父实体不需要加入更多的数据元素或关系，那么新业务规则不会对父实体引起完整性和强制性影响。进行逆规范化的可行性就较强。如果未来父实体需要加入更多的数据元素或关系，那么新父实体数据元素会引起额外的冗余和空间。为了避免将来的维护和冗余问题，需要保持两个实体的独立性。,变动对比率,在同一时间周期内，两个实体的插入和更新频率是否相近。主要,考虑性能和数据同步问题,。即数据稳定性。,数据仓库建模方法论,逆规范化指南问题类型解决方法关系类型层次关系：子对父通常有很,32,风险数据集市-汇总层,数据仓库建模方法论,风险数据集市-汇总层数据仓库建模方法论,33,风险数据集市-应用层,数据仓库建模方法论,风险数据集市-应用层数据仓库建模方法论,34,数据仓库概念,数据仓库数据架构,逻辑数据模型,数据模型标准化工艺流程,主题,数据仓库建模方法论,数据仓库概念主题数据仓库建模方法论,35,步骤,任务,项目准备与策划,模型设计人员的主要职责是参与制定模型相关的项目实施策略，包括确定数据源范围，明确最终提交物和项目日程等。此外，模型设计人员在进场前可参与提出客户相关资料的具体需求，包括一些参考模板，以保证后续工作的输入。,项目启动,模型设计人员参与模型相关的工作流程制定、标准文档的客户化，负责在整个项目组范围内组织模型培训，明确LDM在整个信息架构中的定位和作用，并就工作方法达成共识。,系统需求,模型设计人员参与业务访谈、数据和功能的需求分析,系统设计,系统设计工作是模型组工作的主体，主要由模型小组主导。它包括：信息调研、构建概念模型、逻辑数据模型详细设计，以及物理数据模型设计。,系统开发与单元测试,模型设计人员主要起到支持的作用，为开发人员解释模型设计，协助验证单元测试的结果等，并根据测试发现的问题进行相应修改和变更。,数据模型标准工艺概述,数据仓库建模方法论,步骤任务项目准备与策划模型设计人员的主要职责是参与制定模型相,36,项目准备与策划,在项目准备与策划阶段，模型设计人员的主要职责是参与制定模型相关的项目实施策略，包括确定数据源范围，明确最终提交物和项目日程等。此外，模型设计人员在进场前可参与提出客户相关资料的具体需求，包括一些参考模板，以保证后续工作的输入,。,确定项目人员,本阶段将确定参与项目实施的所有人员名单，包括全职和兼职人员。其中，在确定模型人员时，需考虑对人员进行如下要求：, 熟悉使用建模工具, 拥有丰富模型设计经验, 熟悉银行业务, 较强的沟通表达能力, 具备数据敏感性,收集资料,资料名称,资料说明,相关模板名称,系统数据结构,相关系统完整的数据结构（含字段/代码的取值说明和索引等信息）供分析用,源系统数据字典模板.xls,业务需求,客户提供的各种业务需求材料,部门职能调查问卷,对目标访问部门的职能/业务范围进行调研,访谈材料,现状介绍/业务调查问卷/数据调查问卷,制定实施策略,明确与模型相关的,数据源范围,里程碑,提交物,工作日程,数据仓库建模方法论,项目准备与策划在项目准备与策划阶段，模型设计人员的主要职责是,37,项目启动,在项目启动阶段，模型设计人员参与模型相关的工作流程制定、标准文档的客户化，负责在整个项目组范围内组织模型培训，明确数据模型在整个信息架构中的定位和作用，并就工作方法达成共识。,制定工作流程,划分不同小组的工作边界,确定模型组人员的工作分工,确定项目组内部以及对外的工作模式,对公司标准项目实施流程进行客户化,进行模型培训,介绍源系统,由客户介绍源系统，内容包括：,系统架构/设计思想/系统定位,业务功能/重要流程,关键数据表以及关系,和其他系统的关系,培训内容,相关模板名称,数据模型的基本概念、定位及常用的建模方法,数据模型培训模板.ppt,模型设计规范,逻辑数据模型设计规范模板.pdf,数据模型设计工具,模型产品培训【可选，依是否使用模型产品而定】,数据仓库建模方法论,项目启动在项目启动阶段，模型设计人员参与模型相关的工作流程制,38,系统需求,在系统需求阶段，模型设计人员参与配合业务顾问（以业务顾问为主导），进行需求分析、业务访谈工作，对需求人员所编写的业务需求说明书就模型相关部分进行确认。,业务访谈,业务访谈阶段,访谈议程及内容设定：访谈目的/访谈方式/调查问卷,调查问卷填写：填写说明/双方交流问卷反馈内容,访谈过程记录：专人负责记录/录音,联系人员确认：确定对口联系人，跟进未尽事宜,模型设计人员参与业务访谈过程,内容总结阶段,模型设计人员参与文档整理：访谈纪要的整理发送/调查,问卷的收集整理/不明确问题的确认,业务调研总结报告,报告编写、确认总结报告,需求分析,业务数据分析, 涉及的指标, 查询条件, 分析维度, 统计口径, 计算公式, 处理周期,功能分析, 目的与用途, 流程调研, 报表格式、展现方式, 权限分配、用户管理, 补录数据,对业务需求说明书的模型相关内容要求,报表类需求需包含：,对报表需求分类，简述报表的目的。,报表的访问频度、使用部门、权限要求,报表数据项定义、查询条件,报表样式,分析类需求需包含：,对分析类需求分类，简述分析的目的,访问频度、使用部门、权限要求,分析维度定义,分析指标定义,数据仓库建模方法论,系统需求在系统需求阶段，模型设计人员参与配合业务顾问（以业务,39,信息调研,本阶段工作由模型设计人员主导，在系统需求调研的基础上进行系统数据满足度分析。模型设计人员解读业务需求说明书中产生的问题，记入业务需求问题跟踪单进行跟踪确认.,业务顾问需根据数据满足度中的数据缺口，确认或变更相应业务需求说明书的内容。,数据仓库建模方法论,信息调研 本阶段工作由模型设计人员主导，在系统需求调研的基,40,构建概念模型,本阶段工作由模型设计人员主导进行，主要工作包括建立主题域，确认重要业务关系，生成概念模型。如果项目中有规范小组，则由规范小组主导“规范关键定义”的工作。,数据仓库建模方法论,构建概念模型 本阶段工作由模型设计人员主导进行，主要工作包括,41,逻辑数据模型详细设计,本阶段工作由模型设计人员主导，进行逻辑数据模型设计。业务人员需对模型人员提出的重要规则及处理原则进行确认,。,数据仓库建模方法论,逻辑数据模型详细设计 本阶段工作由模型设计人员主导，进行逻辑,42,物理数据模型设计,本阶段的工作由技术人员主导，将逻辑数据模型转化成可具体实施的物理数据模型,逻辑模型设计人员提供支持。物理数据模型与平台紧密相关，在实际的数据库平台上谈论物理数据模型具有更高的可操作性,数据仓库建模方法论,物理数据模型设计 本阶段的工作由技术人员主导，将逻辑数据模型,43,系统开发与单元测试,在系统开发与单元测试阶段，模型设计人员主要起到支持的作用，为开发人员解释模型，支持开发人员的数据映射和关联关系验证等工作，协助验证单元测试的结果，并根据测试发现的问题进行相应修改和变更。,支持模块开发,对模型进行说明和解释,支持数据映射,支持关联关系验证,协助模块单元测试,协助单元测试结果验证,协助进行错误原因分析,修改、完善设计,根据开发和测试中发现的问题,调整模型，进行模型变更,数据仓库建模方法论,系统开发与单元测试在系统开发与单元测试阶段，模型设计人员主要,44,完善优化,逻辑数据模型健康性检查,逻辑数据模型健康性检查是针对逻辑数据模型设计与维护中的关键项目定期进行评估与回顾的活动，及早发现可能存在的问题与不足，提升人员认知，给出合理化改进建议，完善规范与流程，保持逻辑数据模型健康持续发展，从而为各项工作提供逻辑清晰、设计规范、架构合理、使用方便的逻辑数据模型，提升数据服务质量。,架构层面健康性检查,整体架构检查, 检查主题是否完整, 检查主题间关系是否完整、准确, 检查涵盖的业务范围是否合理, 检查支持和服务的应用领域是否合理,主题架构检查, 检查各主题的核心分类是否符合现状、是否具备扩展性, 检查核心实体的业务定义是否准确和清晰, 检查是否采用了父子结构和重要关联关系表等技术, 检查业务规则的表达是否合理, 检查是否有细分的子主题，划分的详略程度是否合适,管理流程健康性检查,版本检查, 检查有没有使用工具进行版本控制, 检查不同版本的划分是否具有标准, 核实每次发生版本变化的主要原因是什么, 检查历史版本如何管理、版本是否有简要说明,维护检查, 检查是否有源系统变更管理流程, 检查是否有分析需求变更管理流程, 检查是否有统计汇总加工规则变化管理流程,元数据检查, 检查模型是否具备发布机制, 检查模型是否能够与元数据保持同步, 检查业务人员是否能查询到所需信息,业务层面健康性检查,易用性检查, 检查用户了解模型与数据的所有方式, 检查是否有帮助文档, 检查是否有培训体系,一致性检查, 检查现有业务规则的处理是否为大家接受, 检查新的或者变化的业务规则的处理方法, 了解使用中的主要问题有哪些方面, 检查业务规则在不同层次之间是否一致,完整性检查, 检查业务应用中是否发现缺失的业务信息, 核实缺失业务信息的原因, 检查已采纳的业务数据是否完整、是否一致,数据仓库建模方法论,完善优化逻辑数据模型健康性检查架构层面健康性检查管理流程健康,45,完善优化,物理数据模型优化检查,进行物理数据模型优化的工作要点,检查字段命名是否符合规范,参考物理模型设计阶段制定的命名规则进行检查；,对不符合规范的字段了解原因，并决定是否进行修改；,检查字段数据类型是否符合规范,检查字段的数据类型是否符合加工规则、加载需求及应用需求；,如果制订了数据类型规范，则应对照数据类型规范进行检查；,对数据量大小排在前二十名表,找出所有加载这二十张表的脚本；,找出所有使用这二十张表的脚本和查询；,考察这些脚本和查询中对这些大表的常见用法(比如如何下条件等)以及其实际性能表现;,结合上述信息分析其所用数据库物理特性是否合理(比如分区、索引等)，如不合理讨论是否应该修改；,考察是否还有进一步加入其他物理特性的必要性(比如对大表是否需要进行拆分处理、对目前拆的过散的表是否需要进行合并处理等)；,在初步测试后给出修改建议；,对运行最慢的前二十个脚本，以及有代表性及重用性的一些较慢的随机查询,找出导致这些脚本及查询运行较慢的关键表；,分析导致其运行效率较差的原因，判断是否有进一步物理优化的可能性；,在初步测试后给出修改建议；.,设计规范健康性检查,建模工具检查,业务规则检查,技术标准检查,外观美学检查,物理数据模型优化检查,物理模型优化检查是针对整个系统运行情况评估和回顾的一部分，及时检查并发现物理模型设计过程中的一些问题和不足，并及时加以改进和完善，使得整个系统运行更加稳定、高效。,进行物理数据模型优化的时机, 系统运行一段时间后，出现空间容量、执行效率、资源分配的问题时, 数据库版本升级后,数据仓库建模方法论,完善优化物理数据模型优化检查设计规范健康性检查物理数据模型优,46,演讲完毕，谢谢听讲,!,再见，see you again,3rew,2024/8/23,数据仓库建模方法论,演讲完毕，谢谢听讲!再见，see you again3rew,47,