数据仓库建模方法论,数据仓库概念 数据仓库数据架构 逻辑数据模型 数据模型标准化工艺流程,主题,数据仓库领域的两位大师,Bill Inmon 数据仓库之父，数据仓库概念的创始人 理论： Corporate Information Factory(CIF) 主要著作：数据仓库、企业信息工厂 ,主要著作：数据仓库工具箱维度建模的完全指南、 数据仓库生命周期工具箱 设计、开发和部署数据仓库的专家方法 ,Ralph Kimball 数据仓库方面的知名学者 理论：Mutildimensional Architecture(MD),企业数据仓库EDW,数据仓库的特点,企业信息工厂,数据仓库总线,企业总线,总线架构矩阵,多维体系结构与企业信息工厂体系结构比较,OLTP与OLAP,针对特定问题的联机数据访问和数据分析技术 满足对数据进行多角度、快速、一致、交互、深入观察 使用预定义的多维数据视图对数据进行分析处理，支持对数据的切片、切块、钻取。 多维数据库是一种以多维数据存储形式来组织数据的数据管理系统，在使用时需要将数据从关系数据库中转载到多维数据库中方可访问。,也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(Response Time)，即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。OLTP 数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。,On-Line Analytical Processing,On-Line Transaction Processing,OLTP与OLAP,ROLAP表示基于关系数据库的OLAP实现（Relational OLAP）,MOLAP表示基于多维数据组织的OLAP实现（Multidimensional OLAP）,ROLAP vs MOLAP,数据仓库概念 数据仓库数据架构 逻辑数据模型 数据模型标准化工艺流程,主题,数据架构形态,各数据架构比较,数据集市类型,活期存款,定期存款,零售信贷,公司信贷,债券投资,票据信息,同业拆借,储蓄国债,衍生品,储蓄国债,参与者,交易流水,会计单元,理财产品,风险缓释,市场数据,计量结果,公共信息,数据挖掘 模型,风险引擎数据接口,星型模型,报表模型,多维分析模型,风险计算引擎,信用风险,绩效衡量和资本分配,合规性与披露,市场风险,操作风险,流动性风险,防欺诈和反洗钱,Enterprise Date Warehouse,ODS,风险计量结果返回ODS,多维分析,汇总层,应用层,监管报表,风险数据集市数据架构,风险数据集市建设目标,数据仓库概念 数据仓库模型 逻辑数据模型 数据模型标准化工艺流程,主题,为什么需要逻辑数据模型,为复杂的数据仓库系统实施提供了规范和基础结构蓝图 促进业务部门用户和IT分析人员之间的有效沟通 明确业务需求 解决业务问题 形成对重要业务定义和术语的统一认识 具备跨部门，能够表达所有的业务,技术缓冲层 ETL专用的纯技术层 完全与源系统结构一致,近源模型层 基本依照源系统建模 尽量保持业务系统原貌,整合模型层 面向整合 主题设计 提供规范和共享,应用集市层 面向应用 按需定制 多维建模 汇总数据,.,.,数据挖掘模型,风险引擎数据接口,星型模型,报表模型,多维分析模型,汇总层,当事人,财务,产品,资产,事件,内部机构,协议,计量结果,市场数据,LDM在数据仓库系统中的地位,设计思路比较,EDW逻辑数据模型设计目标,中性的，共享的：不针对某个特别的应用而设计； 灵活的，可扩展的：存放最详尽的历史数据，业务发生变化时易于扩展，适应复杂的实际业务情况； 稳定的，经得起考验的：能够在很长时间内保持稳定性，回答不断产生、不断变化且无法预先定义的业务问题； 规范的，易懂的：使用业务语言进行模型设计，易于让业务人员理解和使用，有助于IT和业务部门人员的沟通,25,逻辑视图 (第三级),主题区域 (第一级),概念 (第二级),逻辑数据模型的不同级别,逻辑数据模型的主题域,主题域模型案例-市场风险数据集市,主题域模型案例-信用卡数据集市,主题域模型优点 指导业务数据模型开发 有助于数据一致性，避免冗余。当确定一个新的实体时，基于定义可以确定实体的恰当地主题域。 根据主题域划分工作量，可使重复工作量最小化，并有利于相互协调 指导数据仓库项目选择 为基于数据的项目分组提供了一种高层次划分方法。在确定项目开发顺序时，应该同时考虑业务优先级、技术实现难度、 人员可用性等信息 指导数据仓库开发 有助于确定哪些相关的业务专家,主题域模型目标 提供广泛的理解 提供对每一个主题域的理解，包括各个主题域的名称和定义，通过业务规则将这些主题域联系起来，形象地表达这些主题之间依赖关系和规则。因为在主题域层次，所以，主题域模型更容易覆盖广泛的领域。业务规则使主题域模型增加更多的准确性和清晰性。 确定范围 通过形象地表达主题域和他们的业务规则，我们能够更容易地识别出将要分析的模型的范围。 指引方向 主题域模型能够提供全景视图，可以帮助我们确定：计划中的应用程序和现有的应用程序将怎样共存。下一步，企业将需要什么样新功能。主题域模型提供方向和指南。 建立对业务的高层次理解，为逻辑数据分析和建模打下基础,主题域模型,概念模型,影响数据仓库粒度级别的主要因素,汇总数据 汇总数据能够改善数据交付处理性能，汇总数据不会节省存储空间，因为创建汇总的细节可能会继续被保留。汇总提供的好处主要包括： 在线存储需求减少 分析的标准化以及数据交付性能的改善 合并实体通过减少连接操作的数量，提高了数据交付处理的性能，并且可以增强一致性。 分离数据 根据稳定性和用法来分离数据。稳定性分析根据各个数据属性是否经常变化的特性将这些属性进行分组。,数据仓库粒度级别,逆规范化指南,风险数据集市-汇总层,风险数据集市-应用层,数据仓库概念 数据仓库数据架构 逻辑数据模型 数据模型标准化工艺流程,主题,数据模型标准工艺概述,项目准备与策划,在项目准备与策划阶段，模型设计人员的主要职责是参与制定模型相关的项目实施策略，包括确定数据源范围，明确最终提交物和项目日程等。此外，模型设计人员在进场前可参与提出客户相关资料的具体需求，包括一些参考模板，以保证后续工作的输入。,确定项目人员 本阶段将确定参与项目实施的所有人员名单，包括全职和兼职人员。其中，在确定模型人员时，需考虑对人员进行如下要求： 熟悉使用建模工具 拥有丰富模型设计经验 熟悉银行业务 较强的沟通表达能力 具备数据敏感性,收集资料,制定实施策略 明确与模型相关的 数据源范围 里程碑 提交物 工作日程,项目启动,在项目启动阶段，模型设计人员参与模型相关的工作流程制定、标准文档的客户化，负责在整个项目组范围内组织模型培训，明确数据模型在整个信息架构中的定位和作用，并就工作方法达成共识。,制定工作流程 划分不同小组的工作边界 确定模型组人员的工作分工 确定项目组内部以及对外的工作模式 对公司标准项目实施流程进行客户化,进行模型培训,介绍源系统 由客户介绍源系统，内容包括： 系统架构/设计思想/系统定位 业务功能/重要流程 关键数据表以及关系 和其他系统的关系,系统需求,在系统需求阶段，模型设计人员参与配合业务顾问（以业务顾问为主导），进行需求分析、业务访谈工作，对需求人员所编写的业务需求说明书就模型相关部分进行确认。,业务访谈 业务访谈阶段 访谈议程及内容设定：访谈目的/访谈方式/调查问卷 调查问卷填写：填写说明/双方交流问卷反馈内容 访谈过程记录：专人负责记录/录音 联系人员确认：确定对口联系人，跟进未尽事宜 模型设计人员参与业务访谈过程 内容总结阶段 模型设计人员参与文档整理：访谈纪要的整理发送/调查 问卷的收集整理/不明确问题的确认 业务调研总结报告 报告编写、确认总结报告,需求分析 业务数据分析 涉及的指标 查询条件 分析维度 统计口径 计算公式 处理周期 功能分析 目的与用途 流程调研 报表格式、展现方式 权限分配、用户管理 补录数据 对业务需求说明书的模型相关内容要求 报表类需求需包含： 对报表需求分类，简述报表的目的。 报表的访问频度、使用部门、权限要求 报表数据项定义、查询条件 报表样式 分析类需求需包含： 对分析类需求分类，简述分析的目的 访问频度、使用部门、权限要求 分析维度定义 分析指标定义,信息调研,本阶段工作由模型设计人员主导，在系统需求调研的基础上进行系统数据满足度分析。模型设计人员解读业务需求说明书中产生的问题，记入业务需求问题跟踪单进行跟踪确认. 业务顾问需根据数据满足度中的数据缺口，确认或变更相应业务需求说明书的内容。,构建概念模型,本阶段工作由模型设计人员主导进行，主要工作包括建立主题域，确认重要业务关系，生成概念模型。如果项目中有规范小组，则由规范小组主导“规范关键定义”的工作。,逻辑数据模型详细设计,本阶段工作由模型设计人员主导，进行逻辑数据模型设计。业务人员需对模型人员提出的重要规则及处理原则进行确认。,物理数据模型设计,本阶段的工作由技术人员主导，将逻辑数据模型转化成可具体实施的物理数据模型,逻辑模型设计人员提供支持。物理数据模型与平台紧密相关，在实际的数据库平台上谈论物理数据模型具有更高的可操作性,系统开发与单元测试,在系统开发与单元测试阶段，模型设计人员主要起到支持的作用，为开发人员解释模型，支持开发人员的数据映射和关联关系验证等工作，协助验证单元测试的结果，并根据测试发现的问题进行相应修改和变更。,支持模块开发 对模型进行说明和解释 支持数据映射 支持关联关系验证,协助模块单元测试 协助单元测试结果验证,协助进行错误原因分析 修改、完善设计 根据开发和测试中发现的问题 调整模型，进行模型变更,完善优化,逻辑数据模型健康性检查 逻辑数据模型健康性检查是针对逻辑数据模型设计与维护中的关键项目定期进行评估与回顾的活动，及早发现可能存在的问题与不足，提升人员认知，给出合理化改进建议，完善规范与流程，保持逻辑数据模型健康持续发展，从而为各项工作提供逻辑清晰、设计规范、架构合理、使用方便的逻辑数据模型，提升数据服务质量。,架构层面健康性检查 整体架构检查 检查主题是否完整 检查主题间关系是否完整、准确 检查涵盖的业务范围是否合理 检查支持和服务的应用领域是否合理 主题架构检查 检查各主题的核心分类是否符合现状、是否具备扩展性 检查核心实体的业务定义是否准确和清晰 检查是否采用了父子结构和重要关联关系表等技术 检查业务规则的表达是否合理 检查是否有细分的子主题，划分的详略程度是否合适,管理流程健康性检查 版本检查 检查有没有使用工具进行版本控制 检查不同版本的划分是否具有标准 核实每次发生版本变化的主要原因是什么 检查历史版本如何管理、版本是否有简要说明 维护检查 检查是否有源系统变更管理流程 检查是否有分析需求变更管理流程 检查是否有统计汇总加工规则变化管理流程 元数据检查 检查模型是否具备发布机制 检查模型是否能够与元数据保持同步 检查业务人员是否能查询到所需信息,业务层面健康性检查 易用性检查 检查用户了解模型与数据的所有方式 检查是否有帮助文档 检查是否有培训体系 一致性检查 检查现有业务规则的处理是否为大家接受 检查新的或者变化的业务规则的处理方法 了解使用中的主要问题有哪些方面 检查业务规则在不同层次之间是否一致 完整性检查 检查业务应用中是否发现缺失的业务信息 核实缺失业务信息的原因 检查已采纳的业务数据是否完整、是否一致,完善优化,物理数据模型优化检查 进行物理数据模型优化的工作要点 检查字段命名是否符合规范 参考物理模型设计阶段制定的命名规则进行检查； 对不符合规范的字段了解