通用语义层数据建模方法论 V1.0-public

通用语义层数据模型建设思路内容提纲内容演讲人备注第一部分：通用语义层概述：回顾以往数据仓库模型设计思路：什么是通用语义层：通用语义层能解决什么问题：通用语义层有哪些特点第二部分：如何设计通用语义层第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排内容提纲内容演讲人备注第一部分：通用语义层概述：回顾以往数据仓库模型设计思路：什么是通用语义层：通用语义层能解决什么问题：通用语义层有哪些特点第二部分：如何设计通用语义层第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排 回顾数据仓库数据架构演变过程1.0实施方法特点：源数据一般直接抽取到缓冲层，缓冲层逻辑上在细分为全量区、增量区；基于缓冲层（当时叫ODS层）加工数据集市，集市分为明细汇总表、高粒度的汇总表；用户应用多集中在报表统计；个险银保团险电销财务接口文件缓冲层，（ODS）个险、银保、团险、财务、电销等数据集市（DM）明细汇总表，高度汇总表固定报表灵活查询多维分析1.5实施方法特点：缓冲层与数据集市模型设计思路与以往类似；整合层，参考了IBM的IIW、TD的FS_LDM模型，进行客户化；或者据此设计公司内部的企业模型；用户应用多样化，充分利用BI工具分析功能；管理驾驶舱实际上是仪表盘+固定报表个险银保团险电销财务接口文件缓冲层，（ODS）个险、银保、团险、财务、电销等数据集市（DM）明细汇总表DM1，高度汇总表DM2固定报表灵活查询多维分析整合层（DW）统一建模管理驾驶舱 I III IIIVIV增量信息难以捕获，造成模型设计难以保存历史，造成了模型设计有些“四不象”，实际上并没有学习到行业模型的精髓项目困目困难、困惑、困惑项目实施过程中遇到的困难、困惑ETL过程设计简单，代理主键的使用、更新与维护混乱数据集市一般根据应用来设计，集市表成“碎片”，且指标多次重复计算，集市之间存在误差（可能因为维度、指标口径不明确、加工频度、刷新频度、脚本错误等）数据集市根据实际需要分为明细汇总表、轻粒度汇总表、高度汇总表，至于为何这么分，并没有讲出所以然来IIIIII整合层按照范式的要求进行存储，在计算集市时，非常的不方便，效率低下，因此常将一些常见的维度信息关联好，存储起来，集市计算时使用以往数据仓库类项目模型设计成果示例当事人当事人事件事件协议集市模型，集市模型，这里甚至没有分里甚至没有分层困惑困惑！当前，数据仓库最佳实践之数据架构2.0实施方法特点：总结以往项目经验，规划出较为实用的一层，通用语义层，将基础指标的计算、维度梳理预处理，将多表关联处理成冗余的宽表，解决实际问题；提炼建模方法论，指导项目实际操作；少走弯路。个险银保团险电销财务接口文件缓冲层，（缓冲区、转换映射区、基础数据区）个险、银保、团险、财务、电销等数据集市（DM）分主题汇总（考虑复用）、特定应用汇总固定报表灵活查询多维分析通用语义层（存储明细数据、可多次复用的数据，解决维度与指标一致性的问题）管理驾驶舱制式报告动态报表资产接口文件内容提纲内容演讲人备注第一部分：通用语义层概述：回顾以往数据仓库模型设计思路：什么是通用语义层：通用语义层能解决什么问题：通用语义层有哪些特点第二部分：如何设计通用语义层第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排通用语义层起源与BO通用语义层（CommonSemanticLayer），检称CSL，最早起源与BO，目的在于让业务用户能够通过自己的业务术语，自由安全的访问、分析以及分享信息的技术，其特点是：业务用户自主操作提高用户对于各种企业数据的操作体验提供一致可信的数据，确保同一业务术语的引用能够贯穿整个企业让所有的商务智能工具都可以使用（只能用于BO）让信息部门可以控制和确保信息访问的安全性通用语义层带来的价值简洁一致的用户体验，让业务用户可以简便的访问企业内的数据；减少企业的培训成本；保障业务用户始终使用可信的信息业务用户自创式创建各种商务智能的内容可重用的查询、计算、参数、过滤条件、值列表简化用户使用为普通用户提供了一个简化的界面，访问复杂的企业数据降低BI项目的投入成本，保护现有IT数据投资扩展现有的BI平台的安全模式支持多数据源的语义层，提高服务质量支持完整BI项目生命周期，项目开发、测试、投产语义层与数据源的变化相同步支持和扩展数据库的安全性预定义的可重用的查询、参数、过滤、计算、值列表等给业务用用户带来的价来的价值给IT 用用户带来的价来的价值可理解性差可理解性差语义层过于复杂，难以理解，尤其是新老人员交替，沟通成本很高可复用性差可复用性差语义层的设计成果不能在多个BI工具中使用，过于依赖BI工具.重用程度不高可扩展性差可扩展性差语义层的扩展于与分拆影响较大，难以后期维护，为了降低影响范围，大多是在原来基础上，新增其他功能，致其复杂度越来越高；BO中的通用中的通用语义层实践践中遇到了一系列的中遇到了一系列的问题如如何解决这些问题呢？即能够享有通用语义层带来的价值，又能够规避这些问题。经过敏思苦想、群策群力，敏思苦想、群策群力，终于有了答案。于有了答案。敏思苦想群策群力奔走相告豁然开朗使用ETL的方式，将BO中的语义层搬到数据库中，简化加工逻辑、提供可扩展性和可复用性现在，我在，我们来来重新定重新定义通用通用语义层通用语义层模型设计基于业务（如保险）核心价值链上的核心业务对象和业务事件，采用维度总线架构思想来构建；业务对象通常用维度实现，业务事件通常用事实表实现，按照事实表的不同类型分为：累计快照事实表、周期快照事实表、交易基础事实表。通用语义模型设计面向管理决策和经营分析，是公共维度和共性基础指标的实现载体，支持80%以上的共性应用需求；通用语义模型设计采用维度化的逆范式设计模式，通常采用以下策略：预连接处理：按照总线架构维度和事实表的要求，将分散在多张相关实体表的数据属性进行预连接操作，使相关的维度尽可能组织在特定的维表或者事实表，如保单维、保单责任维、代理人维、客户维、赔案维等；预计算处理：按照总线架构维度和事实表的要求，对事实表中的基础指标进行加工计算，保证基础指标逻辑加工的“GoldenCopy”，如保单事件、核保事件、保全事件、查勘事件、理赔事件等；汇总处理：针对共性的复杂指标，按照对应的维度进行提前聚合处理，以保证共性复杂指标逻辑加工的“GoldenCopy”，避免重复加工，提供数据一致性和响应效率，如保单层面指标汇总，机构层面指标汇总，产品层面指标汇总，代理人层面指标汇总，客户层面指标汇总等；通用语义层模型的粒度尽可能保留到最细交易粒度（汇总处理除外），以保持模型间的连通性，并能够最大程度、最快速地响应新需求；以Sysbase的IWS模型为指导思想，进行通用语义层设计核心主题：LifePolicyEventLifeClaimTransactions关键度量主题：LifePolicyKeyMeasuresLifePolicyCostsKeyMeasuresLifeAgencyChannelKeyMeasuresLifeAgentChannelKeyMeasuresLifeProductCostsKeyMeasuresLifeUnderwritingCostsKeyMeasuresLifeClaimSummary（实际上也是KeyMeasures）其他应用主题视图：LifeQuotations&ProposalsLifeNewBusinessIWS模型主题主要分为事件表和度量表Life Policy Key MeasuresLife Insured Participant ProfileLife Insured Participant ProfileLife Policy EventIWS主题模型示例Customer ProfileInsurance Agency代理机构Geography位置Demography人口统计特征Behavior Scores行为Financial Scores财务Product产品Psychographics购买特征（消费行为）Since Date相关行为开始日期Begin Date初始日期End Date结束日期Assets资产Policy保单Policy Rating相关费率Policy Life Cycle status保单状态Application Date申请Payment Cat支付Insured ParticipantLife PolicyKey MeasureMaturity Date到期/满期日期Determination Date其他重要日期Currency货币IWS主题-保单KPI度量主题展示通用语义层框架构成-建模速成四步法公共维度、专用维度概貌事件表1.2.3.4.5.6.7.粒度到流水，或者特别明细，可以作为事件来看待，可以多次复用，用来计算指标1.2.3.4.5.6.7.业务中最为核心、最有价值的一个“名词”，如保险业的保单、客户；投资行业的证券、帐套、持仓；做拉链设计1.2.3.4.根据对业务的理解，或者从需求报表中提炼，了解具备主数据性质的公共维度数据、专用维度，从交易表和概貌表中梳理指标度量表1.2.3.4.5.表现形式就是从多个角度来看到相关的指标，如代理人kpi度量，则是站在代理人的角度来统计指标，那么常见的指标就有佣金、标准保费、新单件数、个人FYC、营业组FYC基于保基于保险业务核心价核心价值链和和业务事件分析的事件分析的维度度总线架构架构18审计管理保单KPI月度度量代理人KPI月度度量保单事件代理机构KPI月度度量风险管理绩效评估保险行业-通用语义层建模思路和方法产品KPI日度量保单概貌公共维度保单费用KPI月度度量通过分析，IWS模型主要由四类实体构成：概貌类表：存储实体历史信息；事件类表：存储明细交易信息；汇总类表：存储不同视角指标汇总信息，粒度一般到保单、责任或者代理人（机构）；公共维度表：分为有业务含义的实体快照信息、或基础公共信息；最为关键的表就是事件类表，是汇总表的计算基础，一般来说，事件类表主要有以下几类：构造累计快照事实表，分析生命周期时效，如新契约各种时效、理赔调查时效等构造交易基础事实表，分析交易数量、金额等，如承保保单保费、签单保费、累计批增批减等构造事件行为事实表，分析操作的工作量、行为变化等，如录单工作量、核保工作量、查勘工作量等基于基于投投资资产业务核心价核心价值链和和业务事件分析的事件分析的维度度总线架构架构19审计管理资产结构日/月度量投资估值日/月度量交易事件投资损益日/月度量风险管理绩效评估投资行业-通用语义层建模思路和方法风险管理月度量资产概貌公共维度资产持仓日/月度量通过分析，IWS模型主要由四类实体构成：概貌类表：存储实体历史信息；事件类表：存储明细交易信息；汇总类表：存储不同视角指标汇总信息，粒度一般到帐套、证券、科目；公共维度表：分为有业务含义的实体快照信息、或基础公共信息；最为关键的表就是事件类表，是汇总表的计算基础，一般来说，事件类表主要有以下几类：构造累计快照事实表，分析生命周期时效，如投诉问题解决时效等构造交易基础事实表，分析交易数量、金额等，如证券的成交数量、成交金额、成交均价减等构造事件行为事实表，分析操作的工作量、行为变化等，风险类指标等内容提纲内容演讲人备注第一部分：通用语义层概述：回顾以往数据仓库模型设计思路：什么是通用语义层：通用语义层能解决什么问题：通用语义层有哪些特点第二部分：如何设计通用语义层第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排1）源系统数据中的维度、事实表经过统一梳理、整合，使得事实表和汇总结果表中数据存在稳定的、一致的关联关系能解能解决决什什么么样的的问题？通用通用语义层能解能解决决什什么么问题？2）使得集市表不至于成“碎片”，基础指标在语义层已经计算完毕，尽量复用这些计算结果3）使得集市表间不同粒度指标汇总结果一致，都是来源于语义层。特例：更新频率等特殊要求4）能够快速响应业务用户提出的新的报表需求（前提：基于已有指标），缩短响应时间；5）使得BI工具内部建模简单，可读性好，且查询数据速度快，让开发人员集中精力在数据分析方式上6）数据仓库模型简单，可维护性、可扩展性好，能够使得系统更加稳定运行内容提纲内容演讲人备注第一部分：通用语义层概述：回顾以往数据仓库模型设计思路：什么是通用语义层：通用语义层能解决什么问题：通用语义层有哪些特点第二部分：如何设计通用语义层第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排通用语义层建设目标面向业务分析主题基于维度建模理论，以IWS行业模型设计理念作为指导思想支持多源异构数据集成交易粒度的业务明细数据、基础指标的汇总数据数据标准化、清洗、转换和整合企业级统一数据视图和数据模型标准化的实现载体通用语义层模型特性CSLCSL层层模型模型特性特性扩展性性能业务完整性标准与规范数据集成性数据可用性建模基本规范编码规则业务对象类型枚举类型标准命名规范数据的安全和存储策略数据的生命周期数据的可维护性ETL性能查询性能主流保险模型架构根据业务的核心价值链来整合源系统维度、指标数据对源数据质量的考虑增量策略的实现业务上的扩展分析粒度的扩展保险业务各环节商业智能应用分析体系CSL模型特性业务完整性业务上涵盖业务经营的各个环节：如保险行业承保、理赔、收付、渠道、客户、财务等；投资资产行业的资金、交易、持仓、估值、风险、绩效、财务等；能直接支持BI系统的相关应用：明细报表、清单查询、数据挖掘等；能间接提供固定报表、驾驶舱等应用数据需求CSLCSL模型模型特性特性扩展性性能业务完整性标准与规范数据集成性数据可用性CSL模型特性数据集成性参考国内外先进的保险模型架构或标准的研究：行业标准模型sysbaseIWS模型架构上对国内实务及系统的兼容性模型应充分考虑不同系统的差异性和可集成性，比如业务对象的分类、标准化、清洗规则CSLCSL模型模型特性特性扩展性性能业务完整性标准与规范数据集成性数据可用性模型应充分考虑各系统可能存在的数据质量问题，在数据管控体系未建立之前，应该具有一定的容错性建模过程中必须考虑源系统所能提供的增量策略，以便作出相应的调整CSL模型特性ETL性能对模型进行逆规范化的变换（即冗余字段）可以提高性能，以存储空间来换取查询效率。CSL的性能分查询性能和ETL性能，这两者通常是对立的，比如建索引可以提高查询性能，但会降低ETL性能；如多指标计算，然后再整合成同粒度下的一条记录；模型模型模型模型基本特性基本特性基本特性基本特性 CSLCSL模型模型特性特性扩展性性能业务完整性标准与规范数据集成性数据可用性CSL模型特性标准与规范建模基本规范业务对象类型枚举类型标准Code标准定义Codemapping编码规则主键编码规则Type或Code编码规则命名规范逻辑实体和属性命名物理表和字段命名视图、索引、约束、表空间等物理建模规范EDWEDW模型模型特性特性扩展性性能业务完整性标准与规范数据集成性数据可用性CSL模型特性数据可用性模型应考虑系统对历史数据的处理要求：最新状态（实体）、变更轨迹（实体概貌）、变更事件（业务活动）、在线历史备份表、离线归档或转储等模型管理的数据应便于维护，主要体现在数据可追溯、可核对、疑似数据质量容错机制等高可用性要求下的物理存储和容灾策略模型模型模型模型基本特性基本特性基本特性基本特性 CSLCSL模型模型特性特性扩展性性能业务完整性标准与规范数据集成性数据可用性CSL模型特性扩展性模型应能支持上层应用在功能上的扩充（业务范围）模型应尽可能支持源系统在业务功能上的扩充，保持模型架构上的相对稳定性（实体属性级）模型应考虑未来可能新增加数据源对模型架构的影响（系统级）模型模型模型模型基本特性基本特性基本特性基本特性 CSLCSL模型模型特性特性扩展性性能业务完整性标准与规范数据集成性数据可用性1.维度建模，采用维度建模方法，以需求驱动的方式进行设计，应用集市模型通常采用关系型星型/雪花型实现语义层设计注意事注意事项通用语义层一些常见问题2.维度一致性，应用集市模型维度要与通用语义模型维度保持一致性，即要么直接引用通用语义模型中维度，要么从通用语义模型中维度衍生出子维度3.平衡维度处理，层次化平衡维度的灵活分析，且维度和指标之间具有相关性，优先考虑建立多维Cube模型，通过OLAP分析支持用户需求；5.不平衡维度处理，或者部分维度和指标不具有相关性，从展示效率考了也可以建立多为Cube模型，用于支持报表展示，但最好不要开放cube给用户OLAP分析，以避免用户由于不能深入理解维度指标关系而误用6.维度应用复杂度，多维Cube模型维度不宜过多，最好不超过7个维度和5个层次，控制cube过度膨胀降低生成和使用效率；7.数据处理一致性，应用集市的数据绝大多数来自于通用语义层，以达到避免公共逻辑重复加工计算，保证数据一致性，提升新需求响应时效；部分集市用到的非公共维度/基础指标需要从整合数据层直接加工计算，这类应用应该控制在应用总量的20%以内；4.历史数据处理，应用集市要根据应用需求决定：是保留历史快照数据不变，还是回溯重算历史数据以及回溯时长等8.实时数据应用，采用从基础数据层加工实时数据+从通用语义层加工T+1数据相结合的模式内容提纲内容演讲人备注第一部分：通用语义层概述第二部分：如何设计通用语义层 O：建模方法概论：沟通建模思路：筹建模型组，确定双方分工：数据探查，分析数据源：提炼主题，并与用户沟通：需求分析，论证模型可行性：编写Mapping，再次探查数据源：模型物理化，提交词根、词库、建表脚本：后期版本维护第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排CSLModeldesignersolution1234567Formoracle通用语义层数据建模方法论沟通建模思路筹建模型组，确定双方分工数据探查，了解数据源提炼主题，与用户沟通需求分析，论证可行性编写完善Mapping，再次验证数据源模型物理化，提交词根、词库、建表脚本，后期回顾内容提纲内容演讲人备注第一部分：通用语义层概述第二部分：如何设计通用语义层 O：建模方法概论：沟通建模思路：筹建模型组，确定双方分工：数据探查，分析数据源：提炼主题，并与用户沟通：需求分析，论证模型可行性：编写Mapping，再次探查数据源：模型物理化，提交词根、词库、建表脚本：后期版本维护第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排I沟通建模思路-行业模型介绍行业模型介绍保险业通用数据模型介绍，如IIW，IAA,FS_LDM,主要包括数据模型的一些基本概念、常用的建模方法、模型中各主题的定义和主要内容、关键实体和属性描述等。数据模型建设案例介绍,介绍多家保险企业数据模型建设思路和建设成果行业模型建设过程交流p行业模型介绍p客户化过程研讨p讲解模板沟通建模思路客户化研讨 通用数据模型分析，各方案优缺点研讨 数据模型建设方向 数据模型方法论确定 数据模型建设提交文档清单 数据模型建设规范，如文档规范、模型设计规范、版本管理方法 交流数据模型建设过程与参与各方人员工作分工p行业模型介绍p客户化过程研讨p讲解模板沟通建模思路I沟通建模思路-客户化过程研讨讲解模板讲解数据建模过程和要求讲解数据源表和字段分析模板 讲解模板中字段枚举信息和使用要求 介绍模板中宏的使用情况 介绍数据建模过程中模板填写要求,含功能性要求、规范性要求、时效性要求p行业模型介绍p客户化过程研讨p讲解模板沟通建模思路I沟通建模思路-讲解模块1N沟通次数+80%+80%目标：获得用户认可，认同数据建模思路初步沟通，了解用户对模型设计的看法I沟通建模思路-注意事项提出个人看法探讨，要求寻找理论（或方法论）依据，主要是从行业模型和项目实践情况来谈正式沟通前，需要准备好ppt材料，显示出数据建模的专业性认可程度内容提纲内容演讲人备注第一部分：通用语义层概述第二部分：如何设计通用语义层 O：建模方法概论：沟通建模思路：筹建模型组，确定双方分工：数据探查，分析数据源：提炼主题，并与用户沟通：需求分析，论证模型可行性：编写Mapping，再次探查数据源：模型物理化，提交词根、词库、建表脚本：后期版本维护第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排前期准备-组建团队与角色分工筹建模型组p组建团队p收集资料p确定范围 甲方甲方领导领导 实施方领导实施方领导BIBI开发组开发组数据建模小组 甲方业务人员(24)甲方技术人员人员(24)实施方模型设计人员（24）项目总监项目总监 甲方甲方项目项目经理经理实施方项目实施方项目经理经理项目经理项目经理技术人员：熟悉业务系统数据库沟通待分析系统业务数据内部数据管理制度和标准规范业务人员：熟悉业务规则掌握实际运作确认规范和定义需求分析组需求分析组ETLETL开发组开发组业务专家：熟悉保险领域知识掌握待分析内容业务了解保险行业模型行业标准测试组测试组前期准备-收集资料筹建模型组p组建团队p收集资料p确定范围资料初步分析资料初步分析分析文档包含信分析文档包含信息是否够用息是否够用分析数据是否准分析数据是否准备完毕备完毕文档资料文档资料待分析系统设计待分析系统设计资料资料待分析系统数据待分析系统数据字典字典 待分析系统与本待分析系统与本期项目有关的报表期项目有关的报表资料收集资料收集样本数据样本数据 数据数据字典数据数据字典 筛选待分析源筛选待分析源表表 提交数据提取提交数据提取清单清单 待分析数据入待分析数据入库库数据了解数据了解 访谈业务人员访谈业务人员 访谈技术人员访谈技术人员前期准备-确定范围筹建模型组p组建团队p收集资料p确定范围确定范围确定范围待分析数据源和系统分布信息待分析数据源和系统分布信息确定样本数据提供方式、频率、范围、时间区间信息确定样本数据提供方式、频率、范围、时间区间信息 建设周期建设周期 模型数据保存时间模型数据保存时间 提交物提交物 要求要求 沟通机制沟通机制甲乙双方数据建模人员形成一个整体：筹建模型组，确定双方分工-注意事项1.“不择手段”让用户认可建模思路和建模过程2.千方百计让用户（数据建模干系人）参与到数据建模过程中3.初始阶段注重密切沟通与配合，使得用户尽快适应这种节奏4.后期数据建模阶段性成果宣导是共同设计成果、集体智慧结晶内容提纲内容演讲人备注第一部分：通用语义层概述第二部分：如何设计通用语义层 O：建模方法概论：沟通建模思路：筹建模型组，确定双方分工：数据探查，分析数据源：提炼主题，并与用户沟通：需求分析，论证模型可行性：编写Mapping，再次探查数据源：模型物理化，提交词根、词库、建表脚本：后期版本维护第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排：数据探查，分析数据源业务流流程程分分析析，根根据据业务核核心心价价值链筛选流流程程1业务对象象分分析析，将将流流程程涉涉及及的的事事件件和和维度度分分解解2业务数数据据分分析析，根根据据分分解解的的对象象去去了了解解数数据据源源3应用用指指标分分析析，分分析析指指标计算算逻辑4数数据据质量量分分析析，关关注注数数据据质量量问题5业务流程分析，根据流程分析，根据业务核心价核心价值链筛选流程流程承保承保保全保全理赔理赔收付费收付费保保险业务对象分析，象分析，将将流程涉及的事件和流程涉及的事件和维度分解度分解承保承保保全保全理赔理赔收付费收付费保保险业务事件分解业务事件分解事件分解事件分解事件分解事件分解Description of the contents扫描、受理登录录入、复核核保、承保、保单打印、回执1.承保事件*将一个个事件分解下来，待数据探查时任务分解将一个个事件分解下来，待数据探查时任务分解2.保全事件受理录入核保审批生效3.收付费续期应收、实收应付、实付冲正4.理赔报案立案理算审核签批结案*了解每个事件牵涉到哪个表，有什么样的资料供数据分析时参考了解每个事件牵涉到哪个表，有什么样的资料供数据分析时参考业务对象分析，象分析，将将流程涉及的事件和流程涉及的事件和维度分解度分解承保承保保全保全理赔理赔收付费收付费保保险1.机构、渠道、产品机构、渠道、产品2.代理人、代理机构代理人、代理机构3.保单、赔案保单、赔案4.投保人、被保人、受益人投保人、被保人、受益人维度度分解分解-公共公共维度度1.客户类型、证件类型客户类型、证件类型2.事件类型事件类型3.操作类型操作类型4.交费年期分段交费年期分段维度度分解分解-专项维度度业务数数据分析，根据分解的据分析，根据分解的对象去了解象去了解数数据源据源1.字段空值、无意义的字段字段空值、无意义的字段2.外部外部约束关系不匹配约束关系不匹配3.非法字符非法字符4.不和规则的编码不和规则的编码1.维度探查维度探查2.事件探查事件探查3.编码标准化编码标准化4.整理数据质量问题整理数据质量问题充分了解对象涉及的数据源充分了解对象涉及的数据源1.探查价值链中每个环节的重要事件；探查价值链中每个环节的重要事件；2.探查的内容包含该事件相关的源表、字段（字段探查的内容包含该事件相关的源表、字段（字段名称、字段借用、非法字符、空值、主外键不匹配、名称、字段借用、非法字符、空值、主外键不匹配、枚举类型）枚举类型）3.枚举字段梳理，标准化处理建议枚举字段梳理，标准化处理建议1.业务代码梳理业务代码梳理2.映射规则整理映射规则整理3.业务代码标准化处理业务代码标准化处理1.首先需要探查机构、渠道、首先需要探查机构、渠道、产品维度加工规则、数据质产品维度加工规则、数据质量、层级关系；量、层级关系；2.待分析事件时，补充探查待分析事件时，补充探查非主数据的维度信息；非主数据的维度信息；梳理指标关系应用指用指标分析，分析指分析，分析指标计算算逻辑探查指标逻辑数据核对及时确认探查结果探查成果探查成果确认确认 核对标准与核对核对标准与核对核对标准与核对核对标准与核对结果结果结果结果指标取数口径和指标取数口径和计算逻辑计算逻辑维度数据来源、维度数据来源、映射规则、标准映射规则、标准化编码化编码Q1：ETL如何设计如何设计？Q2：异常如何处理：异常如何处理？Q4：数据更新频度，业务哪：数据更新频度，业务哪些异常情况？指标汇总结果些异常情况？指标汇总结果以前是什么状况？以前是什么状况？Q3:数据质量如何数据质量如何检查？检查？事件表入库规则事件表入库规则数数据据质量量分析，分析，关关注注数数据据质量量问题内容提纲内容演讲人备注第一部分：通用语义层概述第二部分：如何设计通用语义层 O：建模方法概论：沟通建模思路：筹建模型组，确定双方分工：数据探查，分析数据源：提炼主题，并与用户沟通：需求分析，论证模型可行性：编写Mapping，再次探查数据源：模型物理化，提交词根、词库、建表脚本：后期版本维护第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排提提炼主主题与与用用户沟沟通，得到通，得到认可后，可后，进行后行后续工作工作保单事件保单事件保单保单KPIKPI度量度量代理人代理人KPIKPI度量度量代理机构代理机构KPIKPI度量度量产品产品KPIKPI度量度量机构机构KPIKPI度量度量内容提纲内容演讲人备注第一部分：通用语义层概述第二部分：如何设计通用语义层 O：建模方法概论：沟通建模思路：筹建模型组，确定双方分工：数据探查，分析数据源：提炼主题，并与用户沟通：需求分析，论证模型可行性：编写Mapping，再次探查数据源：模型物理化，提交词根、词库、建表脚本：后期版本维护第三部分：项目案例说明第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排需求分析，需求分析，论证模型可行性模型可行性I III IIIIIIIIIVIV检查需求报表和多维分析所需指标和维度，语义层是否满足？关注维度分类、指标口径，更新频率查缺补漏，将缺少的指标和维度或维度属性添加到语义层中关注指标归属的合理性，是否属于同一主题，并能解决一类相关问题，如将总保费收入和各类费用支出的指标放在一个主题，可以计算各类费用占比与甲方IT和业务人员共同审核语义层结果，基于业务人员经验，分解指标，并了解指标日常用途和数据要求通用通用语义层是否可用是否可用讨论：如果不懂业务或者不精通业务，那么如讨论：如果不懂业务或者不精通业务，那么如何建模？何建模？编写写Mapping，并并验证加工加工规则重点环节：1.讲解并讨论mapping模板，让开发人员能够读懂mapping，具备将mapping转换成程序的能力；2.验证mapping加工规则，保证转换的业务含义明确和技术标准规范，因为开发人员不具备这项能力；讨论：如何让讨论：如何让ETLETL人员参与到模型设计过程中，担心人员参与到模型设计过程中，担心ETLETL人员不能真正理解模型。人员不能真正理解模型。通用语义层数据模型信息处理规则通用语义层数据模型信息处理规则公共维度处理规则规则1梳理源系统维度信息编码，在维护其映射关系，为映射后的表分配代理主键；关注层次关系，对于机构来说，四级机构和五级机构的上下级关系不是很准确，实际指标计算时不能用户向上汇总；硬编码的维度适用excel宏的方式进行配置和维护；事件表处理规则规则2事件表处理方式有2种，一个是将事件全部集中在一张表，增加事件类型字段，全表多冗余字段，便于使用的同时，冗余字段增多，特别要注意不能字段借用；另外一种处理方式是创建多个事件表，结构清晰也便于维护；不方便的地方是某些指标需要综合多个业务数据，这样的话，就需要写多个脚本来分别计算指标，然后再汇总；概貌表处理规则规则3对于最为核心的最有价值的信息，如保单、客户或其他需要保留历史的重要业务对象，建立概貌表，增加拉链字段，使用拉链算法；需要关注增量数据是否能够准确捕获；度量表处理规则规则4日粒度和月粒度指标分别存储；度量表的指标要具备可复用性，且多为基础指标，其他衍生指标、复合指标需要分析，需要考虑是在语义层计算还是在集市层计算。原则上度量可以使用事件表、维度表、概貌表关联计算出来的，不直接基于缓冲层的表来计算参考数据类型参考词根参考词库建表脚本PDM设计如：DECIMAL(18,0)金额类（非对账系统）；INTEGER数量统计类（倍数，条数，天数等）词根包含内容有名词中文名称、名词英文简称、名词英文名称，如：动作、活动，ACT，Action词库包含所有模型中的字段内容，去重。模板中内容有属性名称、字段名称、字段类型，如有效时间，VALID_TM，TIMESTAMP包含主题归属、实体名称、表名称、属性名称、字段名称、字段类型、主键标记、分区字段标记说明模板填写要求，告知填写人员哪些是必填内容、哪些是模板自动生成内容；自动生成词库、自动生成建表语句；模型物理化，提交词根、词库、建表脚本模型物理化，提交词根、词库、建表脚本1.PDM设计，根据词库内容和命名规范，对LDM中的实体、属性、关系进行命名；2.利用ERWin导出建表语句，对这些语句进行版本管理，便于模型版本控制盒成果交付；3.代码表数据准备，源表字段级分析时，就会整理一些硬编码信息，利用excel宏将这些代码信息生成sql语句，便于ETL的开发、和将来生成上线代码表初始化；4.编写程序模板，模型加载一般分硬编码维度加载、公共维度表加载、专用维度加载、概貌表加载、事件表加载、度量表加载。5.根据ETL对源表数据的捕获方式（增量/存量），衍生出以下几种算法：全删全插算法，用与硬编码维度、专用维度加载；标准拉链算法，用于概貌表加载；DeSert算法，先删后插算法，用于事件表加载Upsert算法，先更新在插入记录，可用于度量表加载；过程说明-模型交付后期版本维护，建立起规范流程p应用验证p数据验证p合理性验证p规范验证模型验证技术角度：是否符合建模规范，加工规则是否正确是否有足够的文档支持业务角度：选取不同的业务需求，从不同的角度对模型进行验证；通过应用需求验证，评估数据组织的合理性；验证和评估结果将成为调整、完善模型的依据。修改记录，版本控制后期版本维护，模型验证，查错、查缺、补漏内容提纲内容演讲人备注第一部分：通用语义层概述第二部分：如何设计通用语义层第三部分：项目案例说明：某人寿集团数据仓库二期通用语义层设计过程：某人寿集团通用语义层设计成果第四部分：实践课：虚拟场景下设计通用语义层下次课程安排第五部分：附录：相关文档模板下次课程安排 1.沟通建模思路2.筹建模型组3.数据探查，了解数据源6.编写mapping，再次探查数据源7.模型物理化，提交词根词库脚本4.提炼主题，与用户沟通案例：某人寿集团数据仓库通用案例：某人寿集团数据仓库通用语义语义层设计过程层设计过程5.需求分析论证模型可行性8.模型回顾，检查开发成果实施程度不够，需要在今后总结文档模板，以模板的形式将数据探查过程规范化目前什么也没有做。目前什么也没有做。缺建表脚本，缺建表脚本，ETL开发人员根据模型自己创建开发人员根据模型自己创建案例：某人寿集团数据仓库通用案例：某人寿集团数据仓库通用语义语义层设计成果层设计成果提提炼主主题公共公共维度度常常规维度度基基础指指标内容提纲内容演讲人备注第一部分：通用语义层概述第二部分：如何设计通用语义层第三部分：项目案例说明：某人寿集团数据仓库通用语义层设计过程：某人寿集团数据仓库通用语义层设计成果第四部分：建模场景演练第五部分：实践课：虚拟场景下设计通用语义层下次课程安排第六部分：附录：相关文档模板下次课程安排小结：1.与用户沟通理论，聊IWS模型和项目案例，获取认同；2.与客户绑在一起，提炼主题；3.数据探查，主题、维度、属性、指标整理，填写“四方格”；4.需求分析，确定语义层是否支持5.组织用户评审，确认数据探查成果和数据模型设计成果；6.内部讲解，关注数据模型交付；