数据仓库建模方法论ppt课件

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