数据仓库建模方法论

数据仓库建模方法论2024/3/25数据仓库建模方法论

数据仓库概念数据仓库数据架构逻辑数据模型数据模型标准化工艺流程主题数据仓库建模方法论数据仓库领域的两位大师BillInmon数据仓库之父，数据仓库概念的创始人理论：CorporateInformationFactory(CIF)主要著作：《数据仓库》、《企业信息工厂》主要著作：《数据仓库工具箱－维度建模的完全指南》、《数据仓库生命周期工具箱－设计、开发和部署数据仓库的专家方法》RalphKimball数据仓库方面的知名学者理论：MutildimensionalArchitecture(MD)

数据仓库建模方法论企业数据仓库EDW企业数据仓库定义：详细交易及相关业务数据的集合包含必要的内部与外部信息来自于多个数据源/业务操作系统保存一定的时间周期按照企业内业务规则所决定的模型来存储企业数据仓库作用：基于数据/信息来回答相关的业务问题和提供决策支持，并确保：一致、集成的数据存储任意的数据粒度在整个企业的业务范围保持企业内一致的信息视图企业内一致的信息视图（SingleVersionoftheTruth）>集成的企业信息（Integratedcorporateinformation）>不针对特定应用（Applicationneutral）>无冗余（Nonredundant）>用于报表和决策支持（Reportinganddecisionmaking）最详细的数据和信息（DetailedData）任何时候，针对任意数据，提出任意业务问题（Askanyquestion,anydata,anytime）数据仓库建模方法论数据仓库的特点数据仓库建模方法论企业信息工厂数据仓库建模方法论数据仓库总线数据仓库建模方法论企业总线数据仓库建模方法论总线架构矩阵数据仓库建模方法论多维体系结构与企业信息工厂体系结构比较方面多维体系结构企业信息工厂体系结构范围优先考虑业务单位范围优先考虑企业总体范围角度关心业务部门的需求多维建模师以企业视角，建立一致性维度。从企业角度解决供应源数据的问题，但并不是整个企业的数据必须在项目第一个阶段都处理。相反而是选择企业所有数据的一个子集。数据流实施方法采用自底向上的：如何快速的获取由用户控制的业务部门专有的数据，并最小限度的考虑整个企业的使用快速需求收集和实现过程使得为整个环境提供一致而可靠数据的任务变得复杂。实施方法是自顶向下的：企业数据利用业务需求将数据从数据源推至需要这些数据的地方，其核心问题是从最初的项目开始为任何数据集市的使用而集成企业数据。为了制定尽可能在整个企业范围内一致的主题域和业务数据需要增加模型开销，需要更多的时间和代价。但后续项目则需要较少时间和代价，尤其对于使用现有的、健全的主题域的业务单位更是如此。实现对存储空间最小需求，非冗余方式防止了在多个位置存储数据。这种特性使更新或删除异常最小化或者消除。易失性聚集数据集市：当业务过程发生变化，为了消除或减少对事实表重建，需要增加新的维或改变维。原子数据集市：由于事实表可能包含几亿甚至更多的数据，重建将会带来严重后果数据仓库模型是与过程无关的，它摒弃了由于处理过程影响而带来的变化数据仓库模型的设计依赖于企业的业务规则，而不依赖与在其上将运行什么查询。如果一个已经建好的数据集市需要改变或加强，可以根据存储在数据仓库中的细节数据合理且快速地进行重建灵活性多维设计是很多业务过程聚集在一起的结果。当处理请求发生变化时，多维数据库的设计未必能够适度地变化。数据仓库模型存放数据粒度级别为原子级别，原子级别可以任意组合。故可以支持将来未知需求。复杂性数据集市模型易于业务人员理解。可以很容易构建数据集市，然而，当一个一个地建立数据集市时，由于数据的企业视图的复杂性，对于这种结构，完成更新时相当复杂的。数据仓库中的细节数据是与处理过程无关的，因此数据仓库的数据模型使得数据不一致的风险最小。功能性为多维处理提供了理想环境，切片和切块、上钻和下钻等查询提供良好的性能支持数据挖掘、统计分析和即席查询持续维护总体目标是防止由于环境的后续构建、调整和优化而产生的高昂的代价。一个良好的数据仓库模型将为企业提供长久的服务，将提供如下回报：整个环境端到端一致性和集成性易于建立新的数据集市加强现有数据集市数据仓库和有关数据集市的维护和可持续发展数据仓库建模方法论OLTP与OLAP针对特定问题的联机数据访问和数据分析技术满足对数据进行多角度、快速、一致、交互、深入观察使用预定义的多维数据视图对数据进行分析处理，支持对数据的切片、切块、钻取。多维数据库是一种以多维数据存储形式来组织数据的数据管理系统，在使用时需要将数据从关系数据库中转载到多维数据库中方可访问。也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(RealtimeSystem)。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(ResponseTime)，即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。

OLTP数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。On-LineAnalyticalProcessingOn-LineTransactionProcessing数据仓库建模方法论OLTP与OLAPOLTPOLAP用户操作人员,低层管理人员决策人员,高级管理人员功能日常操作处理分析决策DB设计面向应用面向主题数据当前的,最新的细节的,二维的历史的,聚集的,多维的集成的,统一的存取读/写数十条记录读上百万条记录工作单位简单的事务复杂的查询用户数上千个上百个DB大小100MB-GB100GB-TBROLAP表示基于关系数据库的OLAP实现（RelationalOLAP）MOLAP表示基于多维数据组织的OLAP实现（MultidimensionalOLAP）数据仓库建模方法论ROLAPMOLAP沿用现有关系数据库技术专用技术响应速度相对molap要慢性能好，响应速度快数据转载计算速度快数据转载速度慢存储空间耗费小，维数没有限制需要进行预计算，可能导致数据爆炸，维数有限，无法支持维的动态变化借助rdbms对数据存储，无文件大小限制受操作系统平台文件大小限制，难以达到tb级可以通过sql语句实现详细数据和概要数据的存储缺乏数据模型和数据访问的标准不支持预计算的读写操作无法完成维之间的运算无法完成多行计算支持高性能的决策支持计算复杂的跨维计算多用户读写操作行级计算ROLAPvsMOLAP数据仓库建模方法论

数据仓库概念数据仓库数据架构逻辑数据模型数据模型标准化工艺流程主题数据仓库建模方法论数据架构形态数据仓库建模方法论各数据架构比较数据仓库建模方法论源系统ODSEDW独立数据集市DataMart#1DataMart#2Non-conformedDimensionsandFacts从属数据集市DataMart#1DataMart#2ConformedDimensionsandConformedFactsDataMart数据集市类型数据仓库建模方法论活期存款定期存款零售信贷公司信贷债券投资票据信息同业拆借储蓄国债衍生品储蓄国债参与者交易流水会计单元理财产品风险缓释市场数据计量结果公共信息数据挖掘模型风险引擎数据接口星型模型报表模型多维分析模型风险计算引擎信用风险绩效衡量和资本分配合规性与披露市场风险操作风险流动性风险防欺诈和反洗钱EnterpriseDateWarehouseODS风险计量结果返回ODS多维分析汇总层应用层监管报表风险数据集市数据架构数据仓库建模方法论风险数据集市建设目标数据仓库建模方法论

数据仓库概念数据仓库模型逻辑数据模型数据模型标准化工艺流程主题数据仓库建模方法论为什么需要逻辑数据模型为复杂的数据仓库系统实施提供了规范和基础结构－蓝图促进业务部门用户和IT分析人员之间的有效沟通明确业务需求解决业务问题形成对重要业务定义和术语的统一认识具备跨部门，能够表达所有的业务数据仓库建模方法论

技术缓冲层ETL专用的纯技术层完全与源系统结构一致近源模型层基本依照源系统建模尽量保持业务系统原貌整合模型层面向整合主题设计提供规范和共享应用集市层面向应用按需定制多维建模汇总数据核心系统对公信贷票据系统储蓄国债市场数据核心系统对公信贷票据系统储蓄国债市场数据…..…..复杂交易复杂交易数据挖掘模型风险引擎数据接口星型模型报表模型多维分析模型汇总层当事人财务产品资产事件内部机构协议计量结果市场数据LDM在数据仓库系统中的地位数据仓库建模方法论ODSEDWDataMartDataMining目标•短期的，细节的，同源的数据存储；•直接提供基于源系统结构的简单原貌访问；•为BI环境中适合的业务需求提供支持•长期的，细节的，整合的数据存储；•为BI环境中适合的业务需求提供支持

•服务特定应用

•长期历史分析性指标汇总•为企业提供预测性、趋势分析性需求提供支持原则•简单处理，不考虑整合；•关注保留策略；

•面向全局，数据整合•中性设计，灵活扩展•提供规范和共享•面向具体应用•按需设计

•针对业务目标、挖掘算法设计数据模型形式•偏源系统模型；•根据支持应用情况可以保留短期历史•面向主题设计；•偏范式化；•长期保留历史

•形式各异，依具体应用不同；

•一条记录表示一个观测•多条记录表示一个观测重点•理解源结构

•主题定义•框架设计•整合策略•实施方法•整体性•一致性•业务理解•数据理解•数据准备用途•业务原貌查询•即时报表•数据质量检查•灵活查询•整合规则检查•特定应用•特定业务专题设计思路比较数据仓库建模方法论EDW逻辑数据模型设计目标中性的，共享的：不针对某个特别的应用而设计；灵活的，可扩展的：存放最详尽的历史数据，业务发生变化时易于扩展，适应复杂的实际业务情况；稳定的，经得起考验的：能够在很长时间内保持稳定性，回答不断产生、不断变化且无法预先定义的业务问题；规范的，易懂的：使用业务语言进行模型设计，易于让业务人员理解和使用，有助于IT和业务部门人员的沟通数据仓库建模方法论逻辑视图(第三级)细节(第三级)主题区域(第一级)概念(第二级)逻辑数据模型的不同级别25数据仓库建模方法论逻辑数据模型的主题域数据仓库建模方法论主题域模型案例-市场风险数据集市数据仓库建模方法论主题域模型案例-信用卡数据集市数据仓库建模方法论主题域模型优点

指导业务数据模型开发有助于数据一致性，避免冗余。当确定一个新的实体时，基于定义可以确定实体的恰当地主题域。根据主题域划分工作量，可使重复工作量最小化，并有利于相互协调指导数据仓库项目选择为基于数据的项目分组提供了一种高层次划分方法。在确定项目开发顺序时，应该同时考虑业务优先级、技术实现难度、人员可用性等信息指导数据仓库开发有助于确定哪些相关的业务专家主题域模型目标

提供广泛的理解提供对每一个主题域的理解，包括各个主题域的名称和定义，通过业务规则将这些主题域联系起来，形象地表达这些主题之间依赖关系和规则。因为在主题域层次，所以，主题域模型更容易覆盖广泛的领域。业务规则使主题域模型增加更多的准确性和清晰性。

确定范围通过形象地表达主题域和他们的业务规则，我们能够更容易地识别出将要分析的模型的范围。

指引方向主题域模型能够提供全景视图，可以帮助我们确定：计划中的应用程序和现有的应用程序将怎样共存。下一步，企业将需要什么样新功能。主题域模型提供方向和指南。建立对业务的高层次理解，为逻辑数据分析和建模打下基础主题域模型数据仓库建模方法论概念模型数据仓库建模方法论影响数据仓库粒度级别的主要因素汇总数据汇总数据能够改善数据交付处理性能，汇总数据不会节省存储空间，因为创建汇总的细节可能会继续被保留。汇总提供的好处主要包括：在线存储需求减少

分析的标准化以及数据交付性能的改善合并实体通过减少连接操作的数量，提高了数据交付处理的性能，并且可以增强一致性。分离数据根据稳定性和用法来分离数据。稳定性分析根据各个数据属性是否经常变化的特性将这些属性进行分组。影响因素描述当前业务需求粒度级别必须足以回答定位在该数据仓库迭代范围内的每一个业务问题。提供高的粒度级别增加了数据仓库和项目的开发成本，如果业务不需要细节，则增加的成本就没有商业价值。未来业务需求按照目前明确需求建立数据仓库，但在建立并抽取数据时要适应考虑未来的需求数据挖掘需求数据挖掘算法需要细节级明细数据派生数据需求派生数据在计算时使用了其它的数据元素，除非在代价和开发时间方面有很大增长，否则所选的粒度级别应该适用于存储所有用于派生其它数据元素的元素。操作系统粒度操作源系统中有效的细节级别，对于不同粒度的源系统需要决定是否在最低的公共级别上抽取数据，以使所有的数据很好的整合，或者从每一个系统中根据他的有效粒度来抽取数据。存储开销粒度级别对存储开销有很大影响备份和恢复数据仓库需要周期性地进行备份和恢复，细节越多，日常备份需要的时间也越多。数据仓库粒度级别数据仓库建模方法论逆规范化指南问题类型解决方法关系类型层次关系：子对父通常有很强的依赖性。倾向于将把这些概念逆规范化到一个实体同等关系：在独立的表中保存独立的实体，可以保证设计与业务规则保持一致。一对一关系：如果当一个实体值仅与来自另一个实体的一个实体值相关，反之亦然。倾向于逆规范化。确定关系：父实体决定子实体的意义。通常为事务处理数据到引用数据的关系和关系实体，在多对多关系引入的关系表被认为是子，而参与多对多关系的两个表被认为是父。在事务处理引用关系中，事务处理表是子，而引用表是父。通常，子表很大且易变。父表通常稳定的多且小。所以倾向于把这两个实体保存在各自的表中。参与率确定关系中每个实体的参与性。对于一个给定的父实体数值，大概会有几个子实体数值。父子关系越接近一对一，将父实体逆规范化到子实体，将有最小数量的冗余。父实体中有多少数据元素如果将父实体逆规范化到子实体，保证子实体中具有存放父实体的数据元素额外空间。使用率两个实体的耦合或相关程度如何。如果在许多用户查询和发布中，来自两个实体的数据元素将一起出现，那么，如果这些信息在同一表中而不是分布于多个表之内，则信息获取将会更快捷。父实体是否变化如果未来父实体不需要加入更多的数据元素或关系，那么新业务规则不会对父实体引起完整性和强制性影响。进行逆规范化的可行性就较强。如果未来父实体需要加入更多的数据元素或关系，那么新父实体数据元素会引起额外的冗余和空间。为了避免将来的维护和冗余问题，需要保持两个实体的独立性。变动对比率在同一时间周期内，两个实体的插入和更新频率是否相近。主要考虑性能和数据同步问题。即数据稳定性。数据仓库建模方法论风险数据集市-汇总层数据仓库建模方法论风险数据集市-应用层数据仓库建模方法论

数据仓库概念数据仓库数据架构逻辑数据模型数据模型标准化工艺流程主题数据仓库建模方法论步骤任务项目准备与策划模型设计人员的主要职责是参与制定模型相关的项目实施策略，包括确定数据源范围，明确最终提交物和项目日程等。此外，模型设计人员在进场前可参与提出客户相关资料的具体需求，，包括一些参考模板，以保证后续工作的输入。项目启动模型设计人员参与模型相关的工作流程制定、标准文档的客户化，负责在整个项目组范围内组织模型培训，明确LDM在整个信息架构中的定位和作用，并就工作方法达成共识。系统需求模型设计人员参与业务访谈、数据和功能的需求分析系统设计系统设计工作是模型组工作的主体，主要由模型小组主导。它包括：信息调研、构建概念模型、逻辑数据模型详细设计，以及物理数据模型设计。系统开发与单元测试模型设计人员主要起到支持的作用，为开发人员解释模型设计，协助验证单元测试的结果等，并根据测试发现的问题进行相应修改和变更。数据模型标准工艺概述数据仓库建模方法论项目准备与策划在项目准备与策划阶段，模型设计人员的主要职责是参与制定模型相关的项目实施策略，包括确定数据源范围，明确最终提交物和项目日程等。此外，模型设计人员在进场前可参与提出客户相关资料的具体需求，包括一些参考模板，以保证后续工作的输入。确定项目人员本阶段将确定参与项目实施的所有人员名单，包括全职和兼职人员。其中，在确定模型人员时，需考虑对人员进行如下要求：熟悉使用建模工具拥有丰富模型设计经验熟悉银行业务较强的沟通表达能力具备数据敏感性收集资料资料名称资料说明相关模板名称系统数据结构相关系统完整的数据结构（含字段/代码的取值说明和索引等信息）供分析用源系统数据字典模板.xls业务需求客户提供的各种业务需求材料

部门职能调查问卷对目标访问部门的职能/业务范围进行调研

访谈材料现状介绍/业务调查问卷/数据调查问卷

制定实施策略明确与模型相关的数据源范围里程碑提交物工作日程数据仓库建模方法论项目启动在项目启动阶段，模型设计人员参与模型相关的工作流程制定、标准文档的客户化，负责在整个项目组范围内组织模型培训，明确数据模型在整个信息架构中的定位和作用，并就工作方法达成共识。制定工作流程划分不同小组的工作边界确定模型组人员的工作分工确定项目组内部以及对外的工作模式对公司标准项目实施流程进行客户化进行模型培训介绍源系统由客户介绍源系统，内容包括：系统架构/设计思想/系统定位业务功能/重要流程关键数据表以及关系和其他系统的关系培训内容相关模板名称数据模型的基本概念、定位及常用的建模方法数据模型培训模板.ppt模型设计规范逻辑数据模型设计规范模板.pdf数据模型设计工具

模型产品培训

【可选，依是否使用模型产品而定】

数据仓库建模方法论系统需求在系统需求阶段，模型设计人员参与配合业务顾问（以业务顾问为主导），进行需求分析、业务访谈工作，对需求人员所编写的《业务需求说明书》就模型相关部分进行确认。业务访谈业务访谈阶段访谈议程及内容设定：访谈目的/访谈方式/调查问卷调查问卷填写：填写说明/双方交流问卷反馈内容访谈过程记录：专人负责记录/录音联系人员确认：确定对口联系人，跟进未尽事宜模型设计人员参与业务访谈过程内容总结阶段模型设计人员参与文档整理：访谈纪要的整理发送/调查问卷的收集整理/不明确问题的确认业务调研总结报告报告编写、确认总结报告需求分析业务数据分析涉及的指标查询条件分析维度统计口径计算公式处理周期功能分析

目的与用途流程调研报表格式、展现方式权限分配、用户管理补录数据对《业务需求说明书》的模型相关内容要求报表类需求需包含：对报表需求分类，简述报表的目的。报表的访问频度、使用部门、权限要求报表数据项定义、查询条件报表样式分析类需求需包含：对分析类需求分类，简述分析的目的访问频度、使用部门、权限要求分析维度定义分析指标定义数据仓库建模方法论信息调研本阶段工作由模型设计人员主导，在系统需求调研的基础上进行系统数据满足度分析。模型设计人员解读《业务需求说明书》中产生的问题，记入《业务需求问题跟踪单》进行跟踪确认.业务顾问需根据数据满足度中的数据缺口，确认或变更相应业务需求说明书的内容。数据仓库建模方法论构建概念模型本阶段工作由模型设计人员主导进行，主要工作包括建立主题域，确认重要业务关系，生成概念模型。如果项目中有规范小组，则由规范小组主导“规范关键定义”的工作。数据仓库建模方法论逻辑数据模型详细设计本阶段工作由模型设计人员主导，进行逻辑数据模型设计。业务人员需对模型人员提出的重要规则及处理原则进行确认。数据仓库建模方法论物理数据模型设计本阶段的工作由技术人员主导，将逻辑数据模型转化成可具体实施的物理数据模型,逻辑模型设计人员提供支持。物理数据模型与平台紧密相关，在实际的数据库平台上谈论物理数据模型具有更高的可操作性数据仓库建模方法论系统开发与单元测试在系统开发与单元测试阶段，模型设计人员主要起到支持的作用，为开发人员解释模型，支持开发人员的数据映射和关联关系验证等工作，协助验证单元测试的结果，并根据测试发现的问题进行相应修改和变更。支持模块开发对模型进行说明和解释支持数据映射支持关联关系验证协助模块单元测试协助单元测试结果验证协助进行错误原因分析修改、完善设计根据开发和测试中发现的问题调整模型，进行模型变更数据仓库建模方法论完善优化逻辑数据模型健康性检查逻辑数据模型健康性检查是针对逻辑数据模型设计与维护中的关键项目定期进行评估与回顾的活动，及早发现可能存在的问题与不足，提升人员认知，给出合理化改进建议，完善规范与流程，保持逻辑数据模型健康持续发展，从而为各项工作提供逻辑清晰、设计规范、架构合理、使用方便的逻辑数据模型，提升数据服务质量。架构层面健康性检查整体架构检查检查主题是否完整检查主题间关系是否完整、准确检查涵盖的业务范围是否合理检查支持和服务的应用领域是否合理主题架构检查检查各主题的核心分类是否符合现状、是否具备扩展性检查核心实体的业务定义是否准确和清晰检查是否采用了父子结构和重要关联关系表等技术检查业务规则的表达是否合理检查是否有细分的子主题，划分的详略程度是否合适管理流程健康性检查版本检查检查有没有使用工具进行版本控制检查不同版本的划分是否具有标准核实每次发生版本变化的主要原因是什么检查历史版本如何管理、版本是否有简要说明维