数据仓库实践-第二课 衣带渐宽终不悔,为伊消得人憔悴

数据仓库实践系列课程第二课

衣带渐宽终不悔，为伊消得人憔悴王国维在《人间词话》说：“古今之成大事业、大学问者，必经过三种之境界：‘昨夜西风凋碧树。独上高楼，望尽天涯路’。此第一境也。‘衣带渐宽终不悔，为伊消得人憔悴。’此第二境也。‘众里寻他千百度，蓦然回首，那人却在，灯火阑珊处’。此第三境也。”

王国维认为治学第一境界：“昨夜西风凋碧树。独上高楼，望尽天涯路”，这词句出晏殊的《蝶恋花》，原意是说，“我”上高楼眺望所见的更为萧飒的秋景，西风黄叶，山阔水长，案书何达？在王国维此句中解成，做学问成大事业者，首先要有执着的追求，登高望远，瞰察路径，明确目标与方向，了解事物的概貌。

王的治学第二境界是说：“衣带渐宽终不悔，为伊消得人憔悴。”这引用的是北宋柳永《蝶恋花》最后两句词，原词是表现作者对爱的艰辛和爱的无悔。若把“伊”字理解为词人所追求的理想和毕生从事的事业，亦无不可。王国维以此两句来比喻成大事业、大学问者，不是轻而易举，随便可得的，必须坚定不移，经过一番辛勤劳动，废寝忘食，孜孜以求，直至人瘦带宽也不后悔。

王的治学第三境界是说：“众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。”是引用南宋辛弃疾《青玉案》词中的最后四句。王国维以此词最后的四句为“境界”之第三，即最终最高境界。要达到第三境界，必须有专注的精神，反复追寻、研究，下足功夫，自然会豁然贯通。课程安排（一）总学时：15学时，其中12学时理论，3学时联系，课后作业估计有5学时（二）考核方法：平时考勤：30分理论答题：30分随堂练习：20分课后作业：20分（三）教材《数据仓库生命周期工具箱》kimball等著，清华大学出版社《数据仓库工具箱》-维度建模权威指南，kimball等著，清华大学出版社（四）教学方法讲师讲解课程，布置家庭作业（利用网络资源完成讲师制定任务）；随堂作业，现场完成作业结业考试，检查教学成果综合练习，提升学习成果目23456TeradataFS_LDM模型介绍IBMIIW模型介绍维度模型设计第三范式模型设计汇聚数据财富

挖掘潜力无限录数据建模导论1SysbaseIWS模型介绍7案例-模型案例说明第5页目录IBM与联动优势公司项目机密II数据模型方法论I客户洞察III数据模型建设路径IV数据模型关键成果V项目交付件I数据模型概述数据建模导论-主要内容数据模型是对现实世界数据特征的抽象，搭建了从业务到应用的桥梁

业务数据根据信息需求抽象出逻辑数据，定义其描述、分类与关系业务人员提出业务需求，并描述业务需求所需的信息内容应用针对业务和数据特性组合应用架构，支撑实际业务应用CustomerDataProductDataAccountDataTransactionData业务人员技术人员数据建模基本概念定义重要的业务概念和彼此的关系，如客户、供应商、合作伙伴、产品、合同、渠道、财务等。企业级概念数据模型关于整个企业需要信息的完整模型，包含了数据实体和实体间的关系、属性、定义、描述和范例。企业级逻辑数据模型定义某系统重要的业务对象之间的本质联系，包含了数据实体和实体间的关系、属性、定义、描述和范例。可扩展为企业级数据模型。系统逻辑数据模型企业级逻辑数据模型（LDM）战略规划运营管理发展方向业务开拓企业级概念数据模型（CDM）业务需求系统逻辑数据模型（LDM）技术应用物理数据模型（PDM）数据模型在企业中的位置数据模型是从应用需求，数据定义到数据仓库设计和建设的蓝图。通过数据关系展现业务过程，是将现实世界的业务概念与信息世界的数据应用相关联的工具。是数据管理、数据分析和交流的重要手段。市场为导向客户为中心效益为目标建立数据模型的重要意义9企业数据模型优化数据架构完善数据标准提升数据质量指导数据标准框架建设指导数据标准中信息属性制定形成企业主题域数据模型根据数据主题调研数据分布，规划可信数据源统一指导应用建设，增强数据一致性协助进行数据质量问题分析，发现问题原因建立数据模型的重要意义第10页目录IBM与联动优势公司项目机密II数据模型方法论I客户洞察III数据模型建设路径IV数据模型关键成果V项目交付件I数据模型概述数据建模导论-主要内容IBM数据模型方法论-五大层级、九大主题A：可以用九大数据概念来描述B：用层次化的概念术语来组织业务信息，采用业务人员熟悉的语言C：用ER图描述业务信息，不考虑实施层面的约束，只维护逻辑视图C‘用ER图描述应用数据，考虑具体实施层面的约束，引入派生数据或去范式化的数据D：描述物理数据结构，考虑系统部署层面的约束ALevelBLevelCPrimeLevelDLevelCLevel参与人合约条件产品位置分类业务方向m事件资源项针对数据库特性将数据逻辑物化为数据库表，支撑实际应用根据数据实体描述、分类，抽取出数据逻辑，并利用ER图描述其关系根据业务对象抽象出数据概念和数据实体，定义其描述、分类与关系数据模型建设思路数据需求概念数据模型（CDM）逻辑数据模型（LDM）根据业务对象抽象出数据概念和数据实体，定义其描述、分类与关系业务人员提出业务需求，并描述业务需求所需的数据内容根据数据实体描述、分类，抽取出数据逻辑，并利用ER图描述其关系物理数据模型（PDM）针对数据库特性将数据逻辑物化为数据库表，支撑实际应用CustomerDataProductDataAccountDataTransactionData业务人员技术人员业务使用数据模型客户信息数据模型财务管理数据模型……1、EDM实体模型4、PDM物理模型3、LDM逻辑模型2、CDM概念模型数据模型设计流程数据模型1,EDM层面的实体模型代表了对业务最重要的信息属性，是建立基础数据模型的基本流程。描述了最重要的业务概念和应用实体。2,CDM层面的数据模型其实是EDM的业务属性描述，细化分解了EDM的具体定义和概念组合。3,LDM则是CDM的进一步解释说明，描述了详细的逻辑关系和相关属性字段。4,PDM是在数据库中的实体物理模型，包含了具体的表定义，模式定义等。数据模型建设原则以及相应决策点14正确性和完整性通用性可操作性数据模型应包含正确并且全面的业务概念，支持相关的业务活动。企业数据模型应支持业务规则的多变性，以最少的改动支持业务规则的变动。相应决策点企业数据模型应便于应用，可与日常操作和实例容易结合。决策点一：业务人员帮助提供和完善业务概念定义。决策点二：数据模型的详细程度满足数据分析要求相应决策点决策点三：关注数据的当前状态。决策点四：各主题数据与数据间的关系尽量在父类建立，并通过关系类型的定义说明各类关系。相应决策点决策点五：从对象封装角度看到的有共性的数据概念，可封装成同一父类数据实体。前瞻性企业数据模型除了支持现有的业务与数据需求外，还应在一定程度上支持行业先进概念与企业未来的需求。相应决策点决策点六：借鉴参考模型决策点七：以融合前瞻性的业务需求作为数据模型的输入关联性模型中的数据与数据间应有关联性。孤立的数据所体现的价值往往少于相关联的数据，数据间的关联性可加强数据用于未来分析的价值。相应决策点决策点八：数据实体的主键为无业务含义的代理标识，方便体现数据与数据间应有的关联性。第15页目录IBM与联动优势公司项目机密II数据模型方法论I客户洞察III数据模型建设路径IV数据模型关键成果V项目交付件I数据模型概述数据建模导论-主要内容源系统入仓梳理数据中心应用需求业务应用需求源系统表级、字段级分析重要参考九大数据概念的分类、描述和关系映射筛选分析数据中心逻辑数据模型固定报表、管理驾驶舱、KPI需求源系统调研IBM参考模型七大主题：当事人产品渠道协议事件营销财务数据中心LDM数据中心逻辑模型建设路径数据模型主题视图设计

随着模型设计工作的进行，模型中的实体会越来越多，因此需要根据不同的分类创建主题视图，将实体进行归纳。通常每个主题主要包括如下主题视图：存放该主题的关系实体，特别是和其他主题的关联关系存放该主题中的重要历史实体存放主题中核心实体的分类树存放该主题的重要实体，能反应主题的大致内容概述分类关系重要历史数据模型信息加工规则在逻辑模型设计时，我们需要将信息加工成子实体集、属性、历史表或关系表，加工规则如下：个人规则1：

加工成属性学历（大专，本科，研究生）个人规则2：

加工成子实体集研究生本科生大专生规则3：

加工成历史表个人当事人学历信息历史学历代码表规则4：

加工成关系表个人当事人协议关系历史协议数据模型信息加工原则加工成属性规则1仅表达某一实体实例的组成要素信息，没有更多的信息要表达，如商户的商户类型代码处理成商户实体的属性，性别处理成人个人实体的属性。加工成子实体集规则2每个分类项都有足够的个性信息需要承载，而且分类项之间的特色和差异比较明显，用子实体来描述各分类项。例如通过自然属性的分类，建立个人子实体和机构子实体。加工成历史表规则3某一实体关键属性会发生变化，并需要追溯其历史。则建立带有拉链的历史表承载变化的描述信息，如：“当事人状态历史”和“当事人状态代码表”，“当事人重要日期历史”和“日期类型代码表”。加工成关系表规则4关系表主要体现这7大主题之间的以及主题内部的关系，由业务规则和源系统两方面的信息决定。如果主题之间或主题内部在业务规则上有约束或联系存在，则需建立关系实体。例如：协议的开通与当事人和产品有关，则建立当事人协议关系，协议产品关系。而当事人与产品之间并强关联性，则无需建立当事人产品关系。如果有分析需求，则通过当事人协议关系，协议产品关系，找到当事人产品关系。第20页目录IBM与联动优势公司项目机密II数据模型方法论I客户洞察III数据模型建设路径IV数据模型关键成果V项目交付件I数据模型概述数据建模导论-主要内容数据模型总体架构数据模型设计充分参考了源系统信息调研的结果和应用需求的反馈，在此基础之上形成了LDM的5五大主题，包括：当事人、产品、协议、事件、渠道。新系统数据入仓后，再实现营销和财务主题：数据模型主题描述-当事人当事人当事人是指UMPAY关注，并且需要记录其信息的任何一个人或一组人。当事人主题可包含通过各种途径和方式购买UMPAY产品、接受UMPAY服务来满足其需求的个人或组织；和UMPAY有其他业务往来的对象；UMPAY出于营销、管理等目的而需要分析的对象；也包含UMPAY内部的组织机构和员工。目前数据模型中，当事人主题包括UMPAY的用户，商户，合作伙伴，员工，内部机构等。当事人主题将针对这些对象存放其基本的属性信息、联系信息、鉴别信息、状态信息等。分类视图第一层：个人和机构。第二层：外部机构和内部机构，员工、用户和合作方。第三层：通道用户和自有用户历史视图当事人名称历史当事人状态历史当事人重要日期历史当事人等级历史当事人鉴别信息历史当事人限额历史当事人地址历史当事人余额历史关系视图当事人协议关系历史当事人关系历史渠道当事人关系历史当事人业务线产品组关系历史当事人主题视图说明：灰色表示仅逻辑化处理的实体数据模型主题描述-产品产品主题

产品是指提供给市场，能满足客户的某种需求，可从中赚取实际或潜在收益的各种货物（有形）与服务（无形）。UMAPY的产品是指UMAPY独立开发的或基于商户的商品而衍生出来，用于向客户（用户）提供，满足用户需求的，并为UMAPY带来收益的产品。该主题记录了产品的名称，价格，付费方式以及产品源于商户的信息。商户的商品是UMPAY产品的衍生基础，因此也属产品主题范畴，但仅作为商品存放，而不作为产品。即商品不是UMPAY的产品，而是产品的重要组成部分。例如金山杀毒软件是金山公司这一商户的商品，而“通过北京移动话费购买金山公司的金山杀毒软件”则是UMPAY的产品。分类视图第一层：支付产品和业务产品。第二层：业务产品分科技产品和电商产品第三层：按业务线分为通信账户产品、EPS产品等历史视图产品状态历史产品名称历史产品价格历史关系视图协议产品关系历史产品渠道关系历史产品产品组关系历史产品主题视图数据模型主题描述-协议协议主题协议是两个或两个以上当事人之间潜在或实际的约定，协议正式提供并确认与协议目的相关的规则和义务。协议主题包含了当事人之间达成的合约，这些合约可以是文本的也可以是电子的。通常情况下协议的子类是按照协议性质用途划分，主要包括：（1）产品协议，即：识别两个当事人之间关于产品购买的协议。该协议明确其中一方自另一方取得产品使用权，一个产品可对应多个产品协议。（2）合作协议，即：企业和其他机构之间的合作项目签订的协议。（3）雇佣合同，即指企业雇佣员工的协议。UMPAY的数据模型中，目前协议主题仅是关于产品的协议，包含客户（用户）在购买产品时与UMPAY达成的各种合约，例如：包月服务协议、公共事业缴费协议、空充业务协议等。该主题记录了协议生效日期，有效期，涉及金额等信息。分类视图第一层：支付协议和业务协议。第二层：按业务线分为包月协议、资金归集协议等历史视图协议状态历史协议重要日期历史协议金额历史关系视图协议产品关系历史协议渠道关系历史协议关系历史当事人协议关系历史协议主题视图数据模型主题描述-渠道渠道主题渠道指在多个当事人之间为了特定目的传递信息或产品的通道，渠道是直接或间接进行产品服务、客户沟通、产品销售的途径。渠道主题包含了业务开展过程中的各种关注的接触渠道信息。UMPAY的接触渠道可以是产品的销售渠道、可以是业务办理过程中的接入渠道也可以是某业务的支付渠道。用户通过这些渠道获取产品信息、进行业务交易。支付渠道主要记录各业务条线在进行支付时使用的渠道，例如：IPS，嗖付工行网银，手机银行卡工行网银，北京移动等；接入渠道主要是从技术的口径定义的发生一笔业务时的接入渠道，例如：发生一笔手机缴话费业务时，其接入渠道可以来自网银，IVR或UMPAY统一分配的短信渠道；销售渠道主要指UMPAY将产品挂接在某WEB页面上供客户浏览购买用的URL地址。分类视图支付渠道、接入渠道和销售渠道历史视图渠道状态历史关系视图协议渠道关系历史渠道当事人关系历史产品渠道关系历史渠道主题视图数据模型主题描述-事件事件主题事件是指业务运营过程中希望记录的已发生或将发生的事情。事件主题包含了UMPAY关注的活动明细信息，例如：UMPAY在业务开展过程中的支付行为、客户购买产品时下订单进行交易，UMPAY与商户或银行的对账活动。每一个活动记录将包括涉及的当事人、发生的时间、交易的产品和使用的支付渠道，以及涉及的金额等重要信息。分类视图订单交易支付退款对账差错其他（风控、客服、OA）事件主题视图第32页目录IBM与联动优势公司项目机密II数据模型方法论I客户洞察III数据模型建设路径IV数据模型关键成果V项目交付件I数据模型概述数据建模导论-主要内容数据模型设计项目最终成果文档序号文档名称用途描述1UMP_EDW_LDM.erwin展现逻辑数据模型视图2UMP_LDM_翻译.xls实体和属性的翻译3UMP_EDW_代码表加载.xls需要硬编码的代码表梳理4UMP_EDW表和字段级分析_XX系统_.xlsx源系统入仓调研和映射信息5UMP_数据模型设计规范.doc数据模型设计规范描述6UMP_EDW逻辑数据模型设计说明书_总册.doc逻辑数据模型的总体架构、原则7UMP_EDW逻辑数据模型设计说明书_XX分册.doc详细阐述各主题的设计思想和内容目23456TeradataFS_LDM模型介绍IBMIIW模型介绍维度模型设计第三范式模型设计汇聚数据财富

挖掘潜力无限录数据建模导论1SysbaseIWS模型介绍7案例-模型案例说明35TeradataFS-LDM介绍主要内容逻辑数据模型基本概念NCR

FS-LDM

LDM定制化工作步骤36数据仓库数据仓库与数据库的区别数据库系统（生产系统）：面向应用、事务驱动的实时性高数据检索量少只存当前数据数据仓库系统（决策系统）：面向主题、分析和决策实时性要求不是特别高数据检索量大存储大量的历史数据和当前数据以银行为例储蓄客户对公信用卡其他产品渠道交易机构37数据仓库系统数据流规划ETL服务器数据清洗／转换／加载文本文件储蓄信用卡对公总帐数据源面向应用3NF数据集市DataMart最终用户银行逻辑数据模型保留详细交易数据面向主题3NF建模LDMLDM面向分析主题汇总数据StarSchema建模数据仓库38数据组织的基础与目标保留详细交易数据数据一次导入，多次使用保证数据的一致性数据跨业务系统和业务平台集成银行所有的数据业务用户对数据有一致的、统一的理解逻辑数据模型（LDM）39用图形的方式展现业务规则由一系列表和实体详细描述组成数据仓库组织数据的方法是IT人员和业务人员沟通的工具独立于技术逻辑数据模型基本概念逻辑数据模型是用来发现、记录和沟通业务,展现业务规则的详细“蓝图”。40客户/团体(party)PartyId(PK)______________PartyNameEventId(PK)__________________TransactionTypeTransactionAmountAccountId(FK)交易/事件(event)帐户(ACCOUNT)AccountId(PK)__________________AccountTypeAccountOpenDateAccountCloseDateisholderofhasactivityof业务规则:

一个客户拥有一个或多个帐户

一个帐户可能被一个或多个客户持有.

一个帐户可能与一个或多个交易／事件相关一个交易事件只涉及一个帐户P实体(Entity)

关系(Relationship)属性(Attributes)主键(KeyAttribute)逻辑数据模型举例1:MN:M41LDM的益处是当前和未来数据的集成蓝图是实现业务智能(BusinessIntelligence)的基础用统一的逻辑语言描述业务系统的规则能更好的控制数据冗余便于开发人员和业务人员进行业务沟通能约束数据仓库开发处理流程的行为规范，为数据仓库的开发提供一种稳定的、长期的、可靠的和精确的技术准则。

是物理数据库设计的基础42LDM设计方法与原则LDM建模方法第三范式（3NF）星型结构（StarSchema）雪花状结构（SnowflakeSchema）LDM设计原则采用第三范式（3NF）设计利用业界已成功的模型－NCRFS-LDM3NF基础数据模型StarSchema汇总数据/已知应用模型Snowflake星型结构的演变43TeradataFS-LDM介绍主要内容逻辑数据模型基本概念NCR

FS-LDM

LDM定制化工作步骤44NCR

FS-LDM全球二百多家金融机构经验的总结描述了银行的各类业务以及这些业务之间的关系，通过定义实体、实体的属性以及实体之间的关系来描述具体的银行业务逻辑蕴含了现代商业银行分析决策和客户关系管理的各个方面是满足第三范式（3NF）的数据模型高起点，缩短周期、降低风险、节约投资NCR金融业逻辑数据模型45NCRFS-LDM产品研发历程1996199719981999200020012/96–研发开始4/96–产品验证9/96–第一个客户

2/00-获得专利!12/00–版本4.0

-保险业务增强

-电子商务(点击流分析)

-隐私功能(choice/consent)

-提供ImageMark接口2001版本5.0:

-商业银行业务增强

-经纪/投资业务增强

-信用卡业务增强2002/2003:

-集团寿险

-健康险

-数据管理20028/97–版本1.0–银行业务–服务支持12/98–版本2.0–功能增强–行为分析模型–服务支持5/99–版本2.111/99–版本3.0–增加保险业务–多币种支持–贡献度分析数据模型

-新巴塞尔协议支持46NCRFS-LDM八大主题地理位置地理区域，物理的或电子的地址.团体(Party)个人或团体机构事件一种资金或非资金的活动，可能需要也可能不需要银行与客户的直接接触内部组织金融机构的分支机构及业务单元帐户金融机构和客户之间为某种产品或金融服务而设置的一种约定产品任何市场化的产品或服务，包括这些产品的条款和条件行销活动为增加客户、保留客户、拓展业务而进行的策略、规划或促销事件渠道银行同客户交互或接触的各种渠道47isdomiciledat/isvehicleformanages/managedbyoffersorservices/isofferedorservicedbyisdeliveredvia/isvehicleformaybea/isaZisinvolvedwith/involvestargets/istargetedbytargets/istargetforistargetfor/targetscanbecontactedat/iscontactforismarketedby/marketsisvehiclefor/isconductedviahasactivityof/involvesrepresents/isrepresentedbyusesormanages/isusedormanagedby团体

帐户

事件渠道行销活动地理位置

内部组织产品

Note:Notallrelationships

areshownNCRCONFIDENTIAL(RESTRICTED)FS-LDMRelease4.0主题之间的关系说明48FS-LDM10MajorSubjectAreasProductEventAgreementChannelPartyPartyAssetFinanceLocationCampaignInternalOrganization491.团体(Party)主题是客户概念的外延可以是一个银行外部或内部的组织机构可以是一个具备相同目的的个体组合，例如协会、社会团体、家庭、亲友团、同学会等。Party的定义：

PARTY是指任意的个人或团体的金融业服务对象。比如：客户、潜在客户、国内组织、汽车商人、竞争者、雇员、分行、部门等等。501.Party主题的主要特点包括多种类型的个人和组织（客户、潜在客户、同业竞争者、特约商户等）提供party之间的任意关系（父子关系、雇主与雇员关系、夫妻关系、雇员与分行的关系等）包括家庭关系、市场分类和人口统计特征。与其他主题的密切关联

Party团体个人法人机构内部组织机构社团雇员家庭金融机构511.Party主题的主要实体521.国内银行客户分类示例个人组织个人个体工商户企业法人公司类客户房贷类客户金融机构类客户非法人单位事业单位及社会团体政府机关军队/武警53

包括产品和产品特性，通过产品特性来反映产品的特有属性。产品特性包括利率、期限、数量、费用等。

可以包括竞争对手的产品或服务2.产品(Product)主题产品的定义：

PRODUCT是指银行提供给金融服务对象的、市场化的、所有的产品和服务，包括这些产品的条款和条件。542.产品主题的主要特征可以组合成各种套装产品产品与条款和条件相关联产品及其特征可以按照内部管理的需要进行分组产品与其他主题都有关联为了满足市场销售的需要，产品可以组合打包。为了满足银行内部的管理需求，产品也可以按照不同的方法进行分组。总的说来，产品有以下几个特征:552.产品主题视图产品特性描述成本利润条款分类产品组产品包描述利率费用数量期限分类团体渠道关联特性组特性间关系关联地域产品特性相关信息562.产品主题主要实体572.国内银行产品分类示例产品类存款贷款信用卡服务类委托及代理资金类（同业拆借）投资类其它表外业务产品包个人住房组合贷款本、外币活期一本通境外筹资转贷债务重组非产品类联名卡／加油IC卡企业终端托收承付。。。583.帐户(Account)主题帐户的定义：

帐户是金融机构与客户之间针对某种特定产品或服务而签立的契约关系帐户的实质是一种合约（Contract）。银行提供了某种产品（Product）或某种服务（Service），并给出了这种产品或服务的报价（Quotation），客户（Customer）经过申请（Application）和还价（Bargain）后接受了该种产品或服务，这时，银行就同客户达成了一个协议（Agreement），这个协议就是帐户。59包括多种类型帐户，例如储蓄帐户、支票帐户、定期存款帐户、退休基金帐户、贷款帐户、信用卡帐户、保险帐户等。和其他主题都有关联3.帐户主题的主要特征帐户这种客户和金融机构之间的合约可能是面向利息的（贷款和存款等金融产品），也可能是面向费用的(保险箱，投资，保险等金融服务)。603.帐户(Account)分类帐户存款帐户流动帐户贷款帐户定期活期定期活期金融帐户投资帐户保险箱帐户613.帐户主题的主要实体623.国内银行帐户分类示例帐户外部帐内部帐资金帐户投资帐户虚拟帐户存款帐户贷款帐户流动帐户活期活期定期定期保证类结算类咨询类保管类整整、整零、零整、存本取息、教育储蓄、华侨等活期、定活、协定存款、通知存款当承兑汇票、信用证、保函等信用卡发放还款贷款展期以贷还贷额度贷款非表外代贷种63是party主题的子类型金融机构的分支机构及业务单元可以是正式组织：分行、分支机构、部门也可以是非正式组织：销售区域、团队等4.内部组织主题内部组织的定义：

是指金融机构的内部组织和业务单元，包括：分行、呼叫中心、销售区域、团队等等。同时，能够建立各组织单元之间的关系。644.内部组织主题主要特征包括所有的组织类型以及它们的相互关系提供层次和矩阵结构

和当事人、渠道、地理位置、产品、帐户、事件、行销活动等主题有关联

分行1分行2分行4地理位置1地理位置2银行分行3市场区域1市场区域265“交易”概念的外延事件可能与帐户相关，也可能与帐户无关。事件可能与资金相关，也可能与资金无关。5.事件(Event)主题事件的定义：

事件（EVENT）是一种资金或非资金的活动，可能需要也可能不需要银行与客户的直接接触，它记录了详细的行为和交易数据。包括存款、提款、付款、信用/借记卡年费、利息和费用、投诉、产品查询、地址查询、余额查询、市场调查、网上交易等。665.事件主题主要特征包含资金或非资金事件由银行或客户发起若干客户事件可以组成一个事务事件有相关的交易代码与其他主题有密切关联

67联系事件客户或潜在客户，与金融机构或金融机构的商户之间的各种联系行为。（如客户投诉）金融事件任何与资金相关的事件。（如取款）帐户事件任何与帐户相关的事件。（如帐户冻结、解冻等）5.事件分类方法685.事件主题主要实体696.地理位置(Location)主题

包括地理区域及它们之间的联系。地址可以是物理地址（如城市、街道等），也可以是电话号码或电子邮件地址等。地理位置的定义：

地理位置(Location)是指金融机构希望关注或考察的任何地理区域和地址。如国家、省份、城市、县、乡村等。70是金融机构用以获取客户、保持客户、争取潜在客户所使用的市场行为。是金融机构的产品和市场形象对客户有组织的展示包括非行销的一些市场行为，如对欺诈的侦测与防范等7.行销活动(Campaign)主题行销活动的定义：

行销活动是银行对客户开展的一系列的促销事件以及相应的策略和规划活动的组合。717.行销活动主题的主要特征包括从策略到执行的多层次的市场活动。大型的或有目标的活动与成本、收入、日期等有关与其他主题关联行销策略行销事件市场计划产品定位地理位置选择渠道选择行销渠道行销收益组织机构客户回应广告投入和实施面向公众的行销事件面向目标市场的行销事件分类行销活动主题视图72渠道（CHANNEL）是银行与客户进行交互和接触的手段和方法，通过它客户与金融机构发生交易并交流很多的信息。8.渠道(Channel)主题渠道一般包括:ATM、分行柜台、电话、POS、呼叫中心、电视、广播、报纸、网络、信件等。738.渠道主题的主要特征包括多种类型，只要是银行与客户的联系工具都可以成为一个渠道。能够考察渠道的分布和使用情况。和其他主题密切关联。748.渠道主题的主要实体758.国内银行渠道分类示例有形渠道柜台,ATM,POS…虚拟化渠道手机银行、网上银行…企业客户终端系统大众媒体一对一营销渠道

Email,Mail…76其他相关内容还有其它的相关内容：帐户申请（application）

包括帐户的申请条件和过程产品报价（quotation）

金融机构针对客户对某种特定产品的报价，同时作为帐户申请的限制条件。隐私（privacy） Party不愿公开的一些信息

77NCRFS-LDM小结FS-LDM集成了国际先进银行科学的、先进的管理经验，可以帮助建行加快与国际商业银行接轨。FS-LDM具有很大的可扩展性和灵活性。FS-LDM对数据仓库的物理数据模型（PDM）的设计具有指导作用，可以最大程度的缩短开发周期。78TeradataFS-LDM介绍主要内容逻辑数据模型基本概念NCR

FS-LDM

LDM定制化工作步骤79NCR逻辑数据模型客户化方法论FS－LDM介绍客户化研讨讲解模板产品当事人协议事件渠道内部机构应用验证数据验证合理性验证规范验证客户化FS-LDM前期准备项目组交流研讨分析源系统统一业务定义模型验证组建团队收集资料确定范围介绍源业务系统分析整理数据结构分析样本数据框架设计模型详细设计完善和回顾80NCR逻辑数据模型客户化方法论FS－LDM介绍客户化研讨讲解模板产品当事人协议事件渠道内部机构应用验证数据验证合理性验证规范验证客户化FS-LDM前期准备项目组交流研讨分析源系统统一业务定义模型验证组建团队收集资料确定范围介绍源业务系统分析整理数据结构分析样本数据框架设计模型详细设计完善和回顾81准备工作1—组建团队

银行领导

NCR领导应用小组NCR人员

银行人员数据建模小组

NCR人员(2~4)银行人员(2~4)项目总监

银行项目经理

NCR项目经理项目经理

资深业务顾问资深系统架构师

资深模型顾问资深技术顾问NCR专家顾问组

业务专家管理分析人员资深技术人员银行后援支持组技术人员：熟悉业务系统沟通能力强理解数据业务人员：熟悉业务规则掌握实际运作确认规范和定义数据规范小组NCR人员(1~2)

银行人员(2~3)ETL小组NCR人员

银行人员黄色部分是在数据仓库项目组中和LDM建设相关的人员82准备工作2—收集资料系统介绍包括系统架构、主要设计思想以及和其他系统的关系等。系统数据字典有完整的数据字典（含字段说明）供分析用。样本数据验证重要的、复杂的业务规则，帮助分析数据的使用规则。如果涉及到多个系统，应该保证各系统数据之间的同步性。83准备工作3—确定范围数据源范围客户化工作会涉及几个源业务系统？样本数据会选择多少机构、多长时间的数据？提交物客户化工作结束之后的提交物主要包括哪些？84准备工作—提交物源业务系统介绍材料

样本数据报送表组织架构建议和分工85NCR逻辑数据模型客户化方法论FS－LDM介绍客户化研讨讲解模板产品当事人协议事件渠道内部机构应用验证数据验证合理性验证规范验证客户化FS-LDM前期准备项目组交流研讨分析源系统统一业务定义模型验证组建团队收集资料确定范围介绍源业务系统分析整理数据结构分析样本数据框架设计模型详细设计完善和回顾86项目组交流研讨NCRFS-LDM产品培训

NCR资深建模专家就FS-LDM进行详细的介绍，主要包括数据模型的一些基本概念、常用的建模方法、FS-LDM各主题的定义和主要内容、关键实体和属性描述等。客户化研讨帮助项目组所有成员清楚地了解客户化过程，明确小组的工作方式和主要工作目标、任务，并且共同制定详细工作方式，才能够保证后续工作的顺利展开。就术语达成共识确定LDM定位和作用确定实施策略制定详细工作方式87交流研讨—提交物培训材料

学习资料88NCR逻辑数据模型客户化方法论FS－LDM介绍客户化研讨讲解模板产品当事人协议事件渠道内部机构应用验证数据验证合理性验证规范验证客户化FS-LDM前期准备项目组交流研讨分析源系统统一业务定义模型验证组建团队收集资料确定范围介绍源业务系统分析整理数据结构分析样本数据框架设计模型详细设计完善和回顾89分析源系统清晰了解现状为客户化提供基础介绍源业务系统系统架构/设计思想业务功能/重要流程系统定位和其他系统的关系分析整理数据结构了解每个表的用途分析每个字段的含义整理数据结构归纳分类数据表分析样本数据分析数据的填写规则验证业务规则查询某种规律关键点：有效的问题反馈机制完备的数据资料和文档90源业务系统分析—提交物源业务系统介绍数据结构整理数据字典整理数据表分类问题跟踪表91NCR逻辑数据模型客户化方法论FS－LDM介绍客户化研讨讲解模板产品当事人协议事件渠道内部机构应用验证数据验证合理性验证规范验证客户化FS-LDM前期准备项目组交流研讨分析源系统统一业务定义模型验证组建团队收集资料确定范围介绍源业务系统分析整理数据结构分析样本数据框架设计模型详细设计完善和回顾92客户化模型1—框架设计基于NCR的FS-LDM，根据所设定的目标和数据范围，确定需要建设的主题范围，构建LDM的原型框架。LDM原型框架决定数据仓库的数据组织原则和基本形式，也决定了数据仓库的应用范围和应用模式。 蓝本93客户化模型2—模型详细设计以上工作须有业务人员和熟悉业务系统的技术人员的参与和配合基于LDM原型框架，进行各主题的详细设计，主要任务包括：－创建各主题的实体和属性，并进行尽可能详细、准确的定义和说明；－建立各实体间的关系；尽可能准确地体现业务规则；－建立主题之间的关联，参照业务需求对实体和属性进行调整。设计过程中也需要对相关代码表进行整理，建立主外键关系；94客户化模型2—统一业务定义在详细了解FS-LDM的基础上，通过对源系统相关信息的了解和整理工作，IT人员和业务人员应该对一些重要的业务元素统一定义，包括：产品渠道当事人协议事件……及时确认！95客户化模型3—完善和回顾（1）与熟悉业务系统的技术人员进行交流和探讨：—是否正确理解了原业务系统的数据

—是否有重要的数据被遗漏—实体之间的关系是否正确（2）与业务专家进行模型的回顾和检讨：

—是否能够帮助实现业务需求—是否能够很容易地理解—重要的业务规则是否得以体现

—回答、解决问题是否方便（3）对数据主题、实体、属性进行确认和完善；可能需要多次的讨论和交流96客户化模型—提交物概念模型框架模型模型命名规范客户化后LDM问题跟踪表97NCR逻辑数据模型客户化方法论FS－LDM介绍客户化研讨讲解模板产品当事人协议事件渠道内部机构应用验证数据验证合理性验证规范验证客户化FS-LDM前期准备项目组交流研讨分析源系统统一业务定义模型验证组建团队收集资料确定范围介绍源业务系统分析整理数据结构分析样本数据框架设计模型详细设计完善和回顾98模型的验证技术角度：

—是否符合建模规范

—是否有足够的文档支持业务角度：

—选取不同的业务需求，从不同的角度对模型进行验证；

—通过应用需求验证，评估数据组织的合理性；验证和评估结果将成为调整、完善模型的依据。99客户化模型—提交物模型验证文档验证后LDM

模型说明文档100NCR逻辑数据模型客户化方法论FS－LDM介绍客户化研讨讲解模板产品当事人协议事件渠道内部机构应用验证数据验证合理性验证规范验证客户化FS-LDM前期准备项目组交流研讨分析源系统统一业务定义模型验证组建团队收集资料确定范围介绍源业务系统分析整理数据结构分析样本数据框架设计模型详细设计完善和回顾101模型的实施确定数据类型，建立PDM；进行数据映射；制定抽取策略；转入ETL工作开发基础应用；进行用户培训和推广；制定下阶段工作目标和范围；102一个好的LDM应该是……中性的，共享的：不针对某个特别的应用而设计；灵活的，可扩展的：能以第三范式存放最详尽的数据，业务发生变化时易于扩展，适应复杂的实际业务情况；稳定的，经得起考验的：能够在很长时间内保持稳定性，回答不断产生、不断变化且无法预先定义的业务问题；规范的，易懂的：使用业务语言进行模型设计，易于让业务人员理解和使用，有助于IT和业务部门人员的沟通；103成功关键要素对源业务系统的了解完备的文档/数据资料学习沟通能力有效的问题解决机制和确认机制目23456TeradataFS_LDM模型介绍IBMIIW模型介绍维度模型设计第三范式模型设计汇聚数据财富

挖掘潜力无限录数据建模导论1SysbaseIWS模型介绍7案例-模型案例说明什么是IIW模型？IAA/IIW的保险业务数据模型(BDM)提供企业级的、通用和灵活的保险业务模型，而且保证业务人员可以方便使用。它独立于具体的保险业务和保险机构，通过模型的本地化和客户化，来满足某个具体的保险企业的使用。这些业务数据模型也与技术手段相脱离，专注为业务建模和业务分析提供一个稳定可用的基础平台。BDM由主题区域（SubjectArea）组成，主题区域分为2类，一类是：主视图（MainView），主要表示属于该主题区域的类（Type）、属性（Attribute）以及它们的关系；另一类是：外视图（ExternalView）主要表示和其他主题区域的关系。主视图-主题内部关系，外视图-多个主题间的关系IIW主题区域介绍（1）账户和资金（Account&Fund）包括能够支持保险公司构建运营上需要的各种账户。账户种类包括客户账户、准备金账户和资金。

活动（Activity）活动模块对被建模的保险公司有关的利益方的各种不同的活动给出了定义，特别是在承保和理赔管理领域里的一些活动。在承保过程中，被建模的保险公司需要对基于被保险人在职业和个人生活两方面从事的相关活动了解存在的风险。例如，一个保险公司可以决定不为某一行业承保，或不为某些爱好承保，或因增加的风险而要求更多的保险费。在理赔管理过程中，被建模的保险公司需要了解引起赔案的损失事件的背景环境。活动应描述不同的当事方在损失事件发生时的活动。这些活动的有效性将根据保险合同中所规定的条款而定，如果该条件不符合保险合同的规定，赔偿将不予以支付

评估与状况（AssessmentandCondition）包括情况、医疗情况、物品情况、地点情况、社交活动情况、经济的评估和用于市场分析的评分。

业务模型对象(BusinessModelObject)定义了在BDM所有对象的共同的特征。

类别(Catagory)将对象按照给定的条件组织在一起的结构。

IIW主题区域介绍（2）理赔（Claim）对相关保单提出支付受益的申请。

联系点和偏好（ContactPoint&Preference）包括了地址、电话号码、电子邮件地址和优先选择的联系点。

事件（Event）包括危险的自然现象或在理赔中典型的事故。

财务处理（FinancialTransaction）包括应付款项和支付（进或出）。

资金计划与管理（MoneyProvision）在合同上商定的或在理赔结算中所涉及的单次或多次付款计划。

当事方（Party）包括了人、机构组织、角色和当事方的名称。

地点（Place）是地理位置的细分，例如街道、城市、省和被国家认为是有特别的风险的或有市场吸引力的。

IIW主题区域介绍（3）

注册信息（Registration）当事方在官方的登记或其他业务上的实情。例如，社会保障号、护照、车辆标识号、产品注册号。

规范，产品和协议（Specification,Product&Agreement）包括保险公司销售产品的规范，各种保险公司和客户或业务伙伴签定的协议。

标准文本和通讯（StandardTextandCommunication）包括了预先定义了的文档规格书、一般文档和与客户联系的记录。

类型（Type）一个相互排它的分类方法，将对象的性质归类到一个类（class）。IIW模型图标说明基本实体：在类型层次结构中的根类型(例如：一个基本实体不依赖于其层次结构中更高层的类型)两个基本实体的关联。一个关联实体可以有一个或多个种类实体在类型层次结构中高层类型的子类。在该层次结构中，类型间相互不重叠。关联实体的子类。它的名称表示了关联的种类。帐户（Account）是帐户和基金主题区域的基本实体，货币资金帐户实体的子类负债帐户是子类实体；帐户关联实体（AccountRlship）表示了各帐户之间关联关系的抽象实体，帐户分配实体（AccountAllocation）是帐户金融资产关联实体（account-financialassetrlship）的子类实体。相关文档介绍，详见附件目23456TeradataFS_LDM模型介绍IBMIIW模型介绍维度模型设计第三范式模型设计汇聚数据财富

挖掘潜力无限录数据建模导论1SysbaseIWS模型介绍7案例-模型案例说明113IWS数据模型说明——主题核心主题：LifePolicyEventLifeClaimTransactions关键度量主题：LifePolicyKeyMeasuresLifePolicyCostsKeyMeasuresLifeAgencyChannelKeyMeasuresLifeAgentChannelKeyMeasuresLifeProductCostsKeyMeasuresLifeUnderwritingCostsKeyMeasuresLifeClaimSummary（实际上也是KeyMeasures）其他应用主题视图：LifeQuotations&ProposalsLifeNewBusiness114LifePolicyKeyMeasuresLifeInsuredParticipantProfileLifeInsuredParticipantProfileLifePolicyEvent115LifeAgencyChannelKeyMeasuresInsuranceAgencyProfileLifeAgentChannelKeyMeasuresInsuranceAgentProfile116LifeInsuranceProductLifeProductCostsKeyMeasures通过分析，IWS模型主要由四类实体构成：概貌类表：存储实体历史信息；事件类表：存储明细交易信息；汇总类表：存储不同视角指标汇总信息，粒度一般到保单、责任或者代理人（机构）；公用维度表：分为有业务含义的实体快照信息、或基础公共信息；CustomerProfileInsuranceAgency代理机构Geography位置Demography人口统计特征BehaviorScores行为FinancialScores财务Product产品Psychographics购买特征（消费行为）SinceDate相关行为开始日期BeginDate初始日期EndDate结束日期Assets资产Policy保单PolicyRating相关费率PolicyLifeCyclestatus保单状态ApplicationDate申请PaymentCat支付InsuredParticipantLifePolicyKeyMeasureMaturityDate到期/满期日期DeterminationDate其他重要日期Currency货币IWS数据模型说明——保单关键度量子模型个险业务分析-核心表结构示例IWS_TK(1)数据模型是一个简化版本的IWS模型，具体来说：（1）没有概貌类表，不存储历史信息，多简化为维度表，如保单、客户、代理人；（2）仅包含核心的保单事件表，对于理赔没有做相关事件表（3）没有KPI度量表，只有几个汇总表，粒度与IWS度量表相比较，粒度较粗，且针对需求设计，多以窄表的形式呈现；A表存储的内容主题相关性不足，难以理解；（4）实际应用中，派生出多个F表，分别用于保全、承保分析或统计使用；业务应用需求源系统表级、字段级分析；主要分析现有模型数据质量，听取用户修改意见逻辑分类，各主题功能定位映射筛选分析数据仓库逻辑数据模型固定报表、管理驾驶舱、KPI需求源系统调研IWS参考模型LifeAgencyChannelKeyMeasuresLifeAgentChannelKeyMeasuresLifeCustomerKeyMeasuresLifeClaimSummaryLifeClaimTransactionsLifePolicyEventLifePolicyCostsKeyMeasuresLifePolicyKeyMeasuresLifeUnderwritingCostsKeyMeasuresLifeProductCostsKeyMeasuresIWS_TK_LDM数据仓库CSL逻辑模型建设路径整理出需求中涉及的指标和维度矩阵；分析这些指标归属的主题；分析现有模型核心表字段，将其数据质量差、含义不明确、字段借用、含义与字段名称错误等问题找出来，予以调整；分析核心表功能定位，收集IT多年来对这些表的修改意见；了解IWS模型设计思想，并以此为蓝图，客户化泰康的数据模型；对于老BI客户化不足之处进行扩充与完善；数据模型主题描述-保单事件保单事件存储交易级别明细数据；粒度可以到保单、责任、渠道、代理人、中支；事件范围涵盖了新契约、承保、核保、保全、理赔、代理人职级变动等信息；宽表结构，不同事件都有部分字段空值，以存储空间换后续的处理效率；且便于运维管理；该表是计算指标最为核心的基础表；由于不存储历史信息，概貌表简化为常规维度表；历史信息的snap表以较多的存储空间换来了历史信息，指标计算与etl加工较为方便，二期继续保留；数据模型主题描述-关键指标度量保单关键指标度量一般存储粒度比保单事件稍粗，不到交易层面；根据实际需求情况，保单关键指标度量存储不同粒度指标汇总信息；只存储本月或者本日数据，一般不做MTD或者YTD，这些指标将在集市层中计算，ETL加工复杂度降低，且ETL处理效率会得到很大提高；老BI中的A表一般不再使用（除了个别复杂的指标，如继续率），涉及指标将分拆到语义层和集市层处理；产品、客户、代理人、代理机构涉及关键指标度量存储的粒度与各主题相关，粒度相对来，很细，足够常规报表统计需求；本期项目中，诸多指标，将根据指标主题性质，进行归来，纳入到不同主题的关键指标度量表中；这些关键指标度量表作用就是将常规指标提供计算，并存储下来，供集市层指标简单汇总使用；应用中，若干需要查询细粒度的指标数据，可以直接查询这些度量表度量表粒度相比事件表，一般要稍粗一些保单事件示例：模型基本结构解析1221.公共维度3.保单事件扩展、属性2.保单事件日期4.保单基础指标5.保单扩展维度数据模型信息加工原则核心维表处理规则规则1核对维度表在多处使用，且影响范围较广，因此不做大的改动，对于其中含义不明的字段、没有什么用处的字段、空值较多的字段进行排查，必要时可以核对多个维度表；核心保单事件表处理规则规则2该表示IWS模型的精髓，将保险业务进行简单的逆范式处理，存储保单各类操作事件，该表不做大的改变，继续沿用这一框架；检查个别字段数据质量问题MQT表、其他F表处理规则规则3根据IWS模型的涉及初衷，建立的某个主题的细粒度度量表，存储相关业务指标；指标的来源基于本期需求，同时根据经验，派生出一些中间指标，用于计算更为复杂的指标；主题的划分参考IWS，根据实际需要进行裁剪；公共类表处理规则规则4对于机构、产品、日期、月份、渠道处理规则，沿用以前的源表；个别字段进行去除，派生价值版块中涉及的一些公共维度，数据来源于D表，做新的报表时，使用同类的V88，这样结构清晰，D表用于CSL，V88统一用于集市；CSL层相关问题124CSL层在数据架构中是如何定位的？主要解决什么样的问题？公共维度和指标的单一视图，解决：a、指标维度的一致性；b、提高应用开发和响应效率；通用语义层细化到交易号粒度，与EDW的主要区别有哪些？在EDW中，没有维度和指标的概念，主要职责是合理地组织标准化数据；在CSL中，公共维度和指标按照保险核心价值链进行主题分类组织，这些维度和指标按照统一的算法逻辑进行标准化实现和数据加载；通用语义层的设计思路和步骤是什么？你们后边打算怎么做这一块的工作？设计思路：基于保险核心价值链的维度总线架构模型，数据粒度到交易号，建立模型之间的简单关联关系；通用语义层设计基本依据：I、基于保险核心价值链分析和应用需求分析的公共维度和基础指标构成的维度指标矩阵；II、基于事件梳理和对象梳理，构造业务对象标准维、事务粒度事实表、累计快照事实表、交易行为事实表等；客户化的策略和步骤，见CSL客户化方法论CSL层相关问题（续）125通用语义层对于一些复杂的特殊指标是如何考虑的，如已赚保费、满期赔付率、未决赔款等？对于复杂的特殊指标，建立公共汇总集市，如已赚保费、未决赔款、满期赔付率等，为相关应用提供一致的指标数据如何在后期的开发和运维过程中持续发展和完善通用语义层？坚持发展和完善通用语义层的基本原则；制定模型升级维护管理办法；专人管理模型升级维护；对于新增的公共维度和基础指标，分析与现有主题、维度、指标之间的关系，对于相同主题和粒度的，扩展现有模型；如果现有模型无法合理容纳，考虑建立新的主题模型；目23456TeradataFS_LDM模型介绍IBMIIW模型介绍维度模型设计第三范式模型设计汇聚数据财富

挖掘潜力无限录数据建模导论1SysbaseIWS模型介绍7案例-模型案例说明内容提纲内容演讲人备注第一部分：通用语义层概述Ⅰ：回顾以往数据仓库模型设计思路Ⅱ：什么是通用语义层Ⅲ：通用语义层能解决什么问题Ⅳ：通用语义层有哪些特点第二部分：如何设计通用语义层第三部分：项目案例说明内容提纲内容演讲人备注第一部分：通用语义层概述Ⅰ：回顾以往数据仓库模型设计思路Ⅱ：什么是通用语义层Ⅲ：通用语义层能解决什么问题Ⅳ：通用语义层有哪些特点第二部分：如何设计通用语义层第三部分：项目案例说明

回顾数据仓库数据架构演变过程1.0实施方法特点：源数据一般直接抽取到缓冲层，缓冲层逻辑上在细分为全量区、增量区；基于缓冲层（当时叫ODS层）加工数据集市，集市分为明细汇总表、高粒度的汇总表；用户应用多集中在报表统计；个险银保团险电销财务接口文件缓冲层，（ODS）个险、银保、团险、财务、电销等数据集市（DM）明细汇总表，高度汇总表固定报表灵活查询多维分析1.5实施方法特点：缓冲层与数据集市模型设计思路与以往类似；整合层，参考了IBM的IIW、TD的FS_LDM模型，进行客户化；或者据此设计公司内部的企业模型；用户应用多样化，充分利用BI工具分析功能；管理驾驶舱实际上是仪表盘+固定报表个险银保团险电销财务接口文件缓冲层，（ODS）个险、银保、团险、财务、电销等数据集市（DM）明细汇总表DM1，高度汇总表DM2固定报表灵活查询多维分析整合层（DW）统一建模管理驾驶舱

IIIIVⅤ增量信息难以捕获，造成模型设计难以保存历史，造成了模型设计有些“四不象”，实际上并没有学习到行业模型的精髓项目困难、困惑项目实施过程中遇到的困难、困惑ETL过程设计简单，代理主键的使用、更新与维护混乱数据集市一般根据应用来设计，集市表成“碎片”，且指标多次重复计算，集市之间存在误差（可能因为维度、指标口径不明确、加工频度、刷新频度、脚本错误等）数据集市根据实际需要分为明细汇总表、轻粒度汇总表、高度汇总表，至于为何这么分，并没有讲出所以然来III整合层按照范式的要求进行存储，在计算集市时，非常的不方便，效率低下，因此常将一些常见的维度信息关联好，存储起来，集市计算时使用以往数据仓库类项目模型设计成果示例当事人事件协议集市模型，这里甚至没有分层困惑~！当前，数据仓库最佳实践之数据架构2.0实施方法特点：总结以往项目经验，规划出较为实用的一层，通用语义层，将基础指标的计算、维度梳理预处理，将多表关联处理成冗余的宽表，解决实际问题；提炼建模方法论，指导项目实际操作；少走弯路。个险银保团险电销财务接口文件缓冲层，（缓冲区、转换映射区、基础数据区）个险、银保、团险、财务、电销等数据集市（DM）分主题汇总（考虑复用）、特定应用汇总固定报表灵活查询多维分析通用语义层（存储明细数据、可多次复用的数据，解决维度与指标一致性的问题）管理驾驶舱制式报告动态报表资产接口文件内容提纲内容演讲人备注第一部分：通用语义层概述Ⅰ：回顾以往数据仓库模型设计思路Ⅱ：什么是通用语义层Ⅲ：通用语义层能解决什么问题Ⅳ：通用语义层有哪些特点第二部分：如何设计通用语义层第三部分：项目案例说明通用语义层起源与BO通用语义层（CommonSemanticLayer），检称CSL，最早起源与BO，目的在于让业务用户能够通过自己的业务术语，自由安全的访问、分析以及分享信息的技术，其特点是：业务用户自主操作提高用户对于各种企业数据的操作体验提供一致可信的数据，确保同一业务术语的引用能够贯穿整个企业让所有的商务智能工具都可以使用（只能用于BO）让信息部门可以控制和确保信息访问的安全性通用语义层带来的价值简洁一致的用户体验，让业务用户可以简便的访问企业内的数据；减少企业的培训成本；保障业务用户始终使用可信的信息业务用户自创式创建各种商务智能的内容可重用的查询、计算、参数、过滤条件、值列表简化用户使用为普通用户提供了一个简化的界面，访问复杂的企业数据降低BI项目的投入成本，保护现有IT数据投资扩展现有的BI平台的安全模式支持多数据源的语义层，提高服务质量支持完整BI项目生命周期，项目开发、测试、投产语义层与数据源的变化相同步支持和扩展数据库的安全性预定义的可重用的查询、参数、过滤、计算、值列表等给业务用户带来的价值给IT用户带来的价值可理解性差语义层过于复杂，难以理解，尤其是新老人员交替，沟通成本很高可复用性差语义层的设计成果不能在多个BI工具中使用，过于依赖BI工具.重用程度不高可扩展性差语义层的扩展于与分拆影响较大，难以后期维护，为了降低影响范围，大多是在原来基础上，新增其他功能，致其复杂度越来越高；BO中的通用语义层实践中遇到了一系列的问题如何解决这些问题呢？即能够享有通用语义层带来的价值，又能够规避这些问题。经过敏思苦想、群策群力，终于有了答案。。。。敏思苦想群策群力奔走相告豁然开朗使用ETL的方式，将BO中的语义层搬到数据库中，简化加工逻辑、提供可扩展性和可复用性现在，我们来重新定义通用语义层通用语义层模型设计基于业务（如保险）核心价值链上的核心业务对象和业务事件，采用维度总线架构思想来构建；业务对象通常用维度实现，业务事件通常用事实表实现，按照事实表的不同类型分为：累计快照事实表、周期快照事实表、交易基础事实表。通用语义模型设计面向管理决策和经营分析，是公共维度和共性基础指标的实现载体，支持80%以上的共性应用需求；通用语义模型设计采用维度化的逆范式设计模式，通常采用以下策略：预连接处理：按照总线架构维度和事实表的要求，将分散在多张相关实体表的数据属性进行预连接操作，使相关的维度尽可能组织在特定的维表或者事实表，如保单维、保单责任维、代理人维、客户维、赔案维等；预计算处理：按照总线架构维度和事实表的要求，对事实表中的基础指标进行加工计算，保证基础指标逻辑加工的“GoldenCopy”，如保单事件、核保事件、保全事件、查勘事件、理赔事件等；汇总处理：针对共性的复杂指标，按