• 1. 黄毅俊 2013年3月 TERADATA 数据模型 介绍
  • 2. 数据仓库的定义 面向主题 Subject Oriented 典型的主题领域:当事人;产品;事件;协议 集成的 Integrated 数据来自分散的系统,需要进行统一的抽取,加工,加载 相对稳定的 Non-Volatile 不可更新,提供决策分析 随时间变化 Time Variant 数据仓库中的时间期限要远远长于操作型系统中的时间期限(5~10年) 数据仓库中的数据是一系列某一时刻生成的复杂的快照 数据集合
  • 3. 目录LDM基本概念BOS LDM介绍LDM设计流程
  • 4. 4ETL服务器数据清洗/转换/加载 文本文件主机中间业务信贷EBank数 据 源面向应用 3NF数据集市 Data Mart最终用户银行逻辑数据模型 保留详细交易数据 面向业务主题 3NF 建模FS-LDM面向分析主题 汇总表/中间表 Star Schema 建模 数据仓库LDM在数据仓库系统中的地位
  • 5. 什么是LDM? LDM - Logical Data Model 逻辑数据模型 通常用图示来代表业务数据组织的一种形式. 通过数据和关系反映业务的一个过程,. 定义需要追踪和管理的各种重要实体、属性和关系; 是进行数据管理、分析和交流的重要手段,也是IT和业务人员沟通的桥梁; 为复杂的数据管理提供了结构基础 你能想象建造一个房子而没有设计图吗? 驾驶汽车穿越国家而没有地图?
  • 6. 为复杂的数据仓库系统实施提供了规范和基础结构-蓝图 促进业务部门用户和IT分析人员之间的有效沟通 明确业务需求 解决业务问题 形成对重要业务定义和术语的统一认识 具备跨部门、中性的特征,能够表达所有的业务为什么需要LDM?
  • 7. 7Subject(主题)Entity(实体)3rd Normal Form (第三范式)Relationship (关系)Attribute (属性)Key Attribute(键值)Business Rule (业务规则)?Logical vs Physical (逻辑 VS. 物理)模型中常见的术语
  • 8. 逻辑数据模型表现方式客户/团体(party)Party Id (PK) ______________ Party NameEvent Id (PK) __________________ Transaction Type Transaction Amount Account Id (FK)交易/事件(event)帐户(ACCOUNT)Account Id (PK) __________________ Account Type Account Open Date Account Close Dateis holder ofhas activity of业务规则: 一个客户拥有一个或多个帐户 一个帐户可能被一个或多个客户持有. 一个帐户可能与一个或多个交易/事件相关 一个交易事件只涉及一个帐户P实体(Entity) 关系 (Relationship)属性 (Attributes)主键 (Key Attribute)1:MN:M
  • 9. 9PARTYParty Id (PK) ______________ Party NameACCOUNTAccount Id (PK) __________________ Account Type Account Open Date Account Close Dateis holder ofPACCOUNTAccount Id (PK) __________________ Account Type Account Open Date Account Close DatePARTYParty Id (PK) ______________ Party NamePARTY_ACCT_RELATIONParty Id (FK) Account Id (FK)Role Code (FK)Associative Entity (关联实体)关联实体的建立
  • 10. 10找出共性,集中存放,易于应用程序的开发 减少多个实体间的关联,使模型更加清晰Super TypeSub Type超级父类实体的建立
  • 11. 目录LDM基本概念BOS LDM介绍LDM设计流程
  • 12. FS-LDM是预先构建的逻辑数据模型,利用它可以直接开始数据仓库模型设计 FS-LDM是一个成熟的产品,有专业的研发团队和市场销售人员以及完善的技术支持 在一个集成的模型内支持银行、保险、以及证券代理业务 提供投资保护 是全球金融业数据仓库经验的结晶 自1997年以来超过200个客户成功实施 灵活易扩展的设计,采用面向主题的设计方法,在增加功能的同时不需要重构整个数据仓库Teradata Financial Services LDM
  • 13. 逻辑数据模型(LDM) 用ERwinTM 建模工具建立的实体关系图 运用信息工程建模技术设计 (IE) 3NF 用业务术语命名和描述 国家和应用中性的 全面的文档 结构上模块化 自1996几乎每年一个新版本 当前版本12.0 Teradata FS-LDM 12.0统计信息 十大主题 3,115 实体 12,799 属性Teradata FS-LDM 特征
  • 14. 2/96 – 开始研发 8/97 版本 1.0 零售银行业务 八个主题域 服务支持(非销售版)12/98 版本 2.0 支持Teradata 渠道OLAP管理分析产品 增强银行业务5/99 版本 2.1 – 销售版 11/99 版本 3.0 增加保险业务 (寿险/财险) 支持多币种 支持Teradata价值分析产品(客户利润贡献度)2/00 获取专利 12/00 版本 4 .0 增强保险业模型 支持电子商务(点击流/Web渠道) 支持支票影像传输 隐私数据12/01版本 5.0 商业银行业务 经纪/投资业务 增加信用卡业务6/04 版本 7.0 支持信用风险管理 (Basel II) 增强财务管理/总账 增强经纪/投资业务 开始IAS 1/03 – 版本 6.0 增加财务/总账主题 集团寿险 健康险6/06 – 版本 8.0 市场风险 增强信用风险 支持DecisionPoint财务分类账12/07 版本 9.0 保险行业企业风险管理 反洗钱 非结构化文本 呼叫中心导航 营销机会、cell、步骤和响应 残值和代位清偿3/09 版本 10.0 资本市场 人力资本管理 整合网站渠道分析10/09 版本 11.0 行业模型通用化 技术调整199619971998199920002001-22003200620072008-92004-52010强大的产品更新能力
  • 15. FS-LDM 十大主题 账户持有者 借款人 员工 交易对手 家庭房子 汽车 现金 机器设备贷款/存款账户 申请 报价 合同/工具 个贷产品 存款产品 商业贷款产品 总账 会计科目 日记账分录存款 催收 还款 ATM 柜面 网银 市场促销 防欺诈活动分行 部门 团队物理地址 电子邮件地址 网站地址 电话号码 地理区域
  • 16. BOS LDM概述 - 覆盖的源系统序号源系统简称中文描述分类表数量入仓年份备注1S00总账服务支撑32008 2S02信用卡业务处理492008 3S04T24核心业务处理18102008 4S05客户经理分析4120102012换版5S06个贷业务处理12620102012换版6S07信贷管理业务处理282010 7S10电话银行渠道272010 8S11第三方存管外联282010 9S12对私前置渠道332010 10S13对公前置渠道112010 11S14基金代销外联3420102012换版12S15中间业务平台业务处理52010 13S16签约平台服务132010 14S17个人理财分析1462010 15S20资金转移定价分析212012 16S21整合平台渠道752012 17S22开放式理财业务处理192012 18S23电子国债外联132012 19S24银保通外联152012 20S25个人黄金外联222012 
  • 17. 1. 当事人主题当事人(PARTY)是指上海银行所服务的和感兴趣进行分析的任意对象。当事人可以是一个独立的人,也可以是一组人组成的机构、团体等。当事人分为个人当事人、机构当事人和家庭,他们是和上海银行有业务往来或者出于市场营销、分析管理等各种需要而希望关心和分析的个体或群体。 从数据仓库模型角度考虑,主要包括以下几类当事人信息: 在上海银行登记注册开立账户的单位、个人普通客户; 和上海银行有业务往来的其他金融机构(如国内同业、海外代理行等); 上海银行行内机构和员工(特殊的当事人,在内部机构主题下) 当前尚未成为本行的客户,但可以从行内业务系统或第三方获取较完善的基本信息的当事人。这部分客户是本行潜在客户。
  • 18. 1. 当事人主题 - 实例账户的持有人 账户的共同持有人 借款人 执行者 联合签名者/共同申请人 员工 受益人 竞争对手 家庭/成员 交易对手特约/联名商户 担保人 投资者 咨询顾问 ……
  • 19. 1. 当事人主题 - 当事人主表数据来源 信用卡: 客户S02_TBL_CSM_CSTBSC 商户S02_TBL_CMM_MERBSC T24核心:S04_CUST 客户经理:客户信息S05_T01_CUSTOMER_INFO 客户经理S05_T01_MANAGER_INFO 个贷:合作企业基本信息S06_TC_CORP 客户基本信息S06_TC_CUST 客户配偶信息S06_TC_CUSTMATE 担保人信息S06_TC_ASSUINFO 信贷:客户信息S07_CUSTOMER_INFO 。。。。。。 共涉及16个源系统54组信息 主键说明 当事人编号为唯一主键 当事人编号产生规则=S**[系统代号]+NNN[组别号+原当事人编号
  • 20. 1. 当事人主题 - 当事人主表查看数据SQL DATABASE PDATA; SEL TOP 100 * FROM T01_PARTY 模拟业务需求 需要查看T24内有多少客户?信贷系统有多少客户?个贷系统有多少客户? SEL TOP 100 * FROM T01_PARTY WHERE PARTY_TYPE_CD =‘G’//T24客户 SEL TOP 100 * FROM T01_PARTY WHERE PARTY_TYPE_CD =‘CD_011’//信贷客户 SEL TOP 100 * FROM T01_PARTY WHERE PARTY_TYPE_CD =‘CD_005’//个贷客户 那如何找一个客户号为20120322000058的信贷客户? 其他字段解释 当事人分类代码来区分对公对私. 要学会查看代码表 SEL * FROM T99_PARTY_TYPE_CDE SEL * FROM T99_PARTY_CLS_CDE
  • 21. 1. 当事人主题 - 当事人分类
  • 22. 1. 当事人主题 - 个人当事人分类(具体见ERWIN)
  • 23. 1. 当事人主题 - 机构当事人分类(具体见ERWIN)
  • 24. 1. 当事人主题 - 当事人重要信息实体
  • 25. 1. 当事人主题 - 当事人关系实体
  • 26. 1. 当事人主题 - 重要实体介绍当事人 A party is any individual, organization or household that is of interest to the enterprise. 当事人鉴别信息历史 The numbers that may be assigned to a Party for identification purposes, as specified by Party Identification Type. Example: Social Security Number, Passport Identification, Driver's License. 当事人评级历史 This entity represents the risk grade assignment for a given Party for a given period of time. 当事人统计信息历史 This entity tracks the party metrics over time. 当事人状态历史 This entity contains the history of the status of the party.
  • 27. 1. 当事人主题 - 重要实体介绍当事人额度历史 This entity contains information about limits at the party level such as credit limit. A credit limit at the Party (Customer) level may not be the sum of related account limits - and is usually less than the sum. 当事人关系历史 This entity defines the relationships between parties - individual and individual; individual and organization; organization and organization; individual and household and household and household relationships. A party can be part of many relationships. A party can have many types of relationships with another party. Examples of relationships could be employee-employer, Husband - Wife, household-member, father-son, supplier to the enterprise, or competitor to the enterprise.
  • 28. 1. 当事人主题 – 入实体举例主题是较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念,每一个主题基本对应一个宏观的分析领域。 范式化的主题举例 温州某公司 来申请一笔批发和零售业的单位短期抵押质押贷款10W,在申请资料中需要填写该公司的CEO、CFO信息;提供公司的组织机构代码证、营业执照;提供公司的员工人数、年销售收入。提供公司的创建信贷关系时间、高新技术企业标志等。 系统分配的客户编号、 CEO、CFO 入当事人 组织机构代码证、营业执照 入当事人鉴别信息历史 员工人数、年销售收入 入当事人统计信息历史 创建信贷关系时间、高新技术企业标志 入信贷客户
  • 29. 历史表举例 温州某公司 2012年4月1日开户的授信额度100W 2012年10月1日的授信额度调整为500W 当事人额度历史举例 会计日期 为2012年4月1日是记录为 会计日期 为2012年10月1日是记录为 SQL SEL TOP 100 * FROM T01_PTY_LMT_H WHERE PARTY_ID = ‘S0700120120322000058’ 理解最大日期30001231的概念,如何来记录历史数据,什么情况会产生断链? 1. 当事人主题 - 历史表查看数据当事人编号额度类型代码开始日期额度金额结束日期S07002201001128CD_00120120401100W30001231当事人编号额度类型代码开始日期额度金额结束日期S07002201001128CD_00120120401100W20121001S07002201001128CD_00120121001500W30001231
  • 30. 还记得数据仓库的定义吗? 模型是如何来实现定义中的目标? 在我们的模型中能看到源系统的表结构吗? 源系统修改表结构数据仓库的模型结构需要同步改吗? 假设现在业务需求是查看2012年底信用卡8000594994客户的信用额度,该如何查询呢? [信用卡系统只保留当前额度] Lmt_Type_Cd = ‘CD_001’信用额度1. 当事人主题 - 问题思考我爱思考
  • 31. 银行产品(PRODUCT)是指为拓展市场占有率,满足客户更广泛需求而制定的可营销的交易品种集合,产品是金融机构向用户销售的或提供给客户所使用的服务。产品必须是能够面向市场、面向客户的,并且必须要有回报发生的。 为满足银行内部管理的需要和适应不断变化的业务需求,可以根据实际情况结合产品特性将产品分组,如个人存款产品组、公司贷款产品组等 ,这些即“产品组”。 出于市场竞争的需要,或作为市场营销的结果,将一些产品打包、捆绑销售,称其为“产品包”。 2. 产品主题
  • 32. 2. 产品主题
  • 33. 2. 产品主题
  • 34. 3. 协议主题协议(AGREEMENT)是金融机构与客户之间针对某种特定产品或服务而签立的契约关系,它可以是多样化的,如账户、客户和银行签订的合同等。 包括协议的申请、报价、还价以及开立等完整信息。
  • 35. 当金融机构与客户之间针对某种产品或服务的条款和条件达成协议时, 一个AGREEMENT就会被开立。 在一个时间点,一个AGREEMENT只能对应一种产品,该产品可能是一个产品包的一部分。 AGREEMENT可能是客户接受金融机构关于某项产品报价的结果。 一个AGREEMENT可以被一个或多个当事人持有。如一个帐户可以有多个当事人一起持有, 帐户持有人是当事人对AGREEMENT的角色,多个当事人共同使用一个帐户时,必须开立联名户。 一个AGREEMENT除了持有人外,可能与其他的当事人有关系,如受益人、共同签字人、担保人等,这些也是当事人对AGREEMENT的角色。 AGREEMENT也可能与其他AGREEMENT相关联,如一个帐户由于筹措资金的需要而被另一个帐户所取代,或一个帐户对另一个帐户提供担保。 3. 协议主题 - 业务规则
  • 36. 36活期存款账户 定期存款账户 养老金账户 信用卡 担保合同 贷款合同 内部投资账户 证券买卖账户 信用证 基金账户 保单 ……3. 协议主题 - 协议实例
  • 37. 3. 协议主题 - 协议主表数据来源 T24:小额抵质押贷款S04_MG_MORTG_II 国债账户S04_TEM_STA_BOND_CONTR 个人理财合约S04_TEM_WM_CONTR_II 个贷:额度表S06_BQUOTAVALUE 发放资料S06_BRELE 信贷:信贷合同S07_BUSINESS_CONTRACT 信贷解决 S07_BUSINESS_DUEBILL 共涉及11个源系统50组信息 主键说明 由协议编号和协议修饰符双主键构成 协议编号保留原系统的帐号、合同号、借据号等 协议修饰符由来源系统代码+组别号
  • 38. 3. 协议主题 – 重要实体
  • 39. 3. 协议主题 - 重要实体介绍 协议表 This entity contains information about agreements between two or more parties. 协议科目余额历史 上海银行特有实体,负责把T24账号映射出会计科目。 协议余额历史 记录协议余额变动情况.[实际余额,逾期余额,本金余额…] 协议金额历史 记录协议发生额变动情况[交易金额,税收金额,利息收入...] 协议状态历史 This entity contains the history of the status of the account, such as active, inactive, or pending closure. 协议日期历史 记录协议各种日期类型的变动情况.[实际到期日,下次还款日,利率变动日期
  • 40. 协议利率历史 [执行利率,罚息利率…] 协议额度历史 [信用额度,有效信用额度,临时信用额度…] 协议期限历史 [贷款期限,存续期,当前逾期期数…] 申请表 This entity identifies all applications for a financial institution product, for which a PARTY needs to qualify. Currently this applies to insurance accounts and loan type accounts including credit card and current accounts. Even though an application is really an early state of an account, it is included here as a separate entity from Account. 介质 A means by which a customer has access to one or more accounts. Examples of types include credit card plastic, key chain card, cell phone, and personal computer. A device may access more than one account such as both credit card and banking accounts. 3. 协议主题 - 重要实体介绍
  • 41. 协议介质关系历史 This entity relates an ACCESS DEVICE such as a credit or debit card to an account. An account can have many devices associated with it (e.g., one each for husband and wife) and a device can be used with many accounts (e.g., savings and checking). 协议机构关系历史 [协议的所属机构,签约机构,经办机构…] 协议当事人关系历史 This associative entity defines the relationships that this account has with parties.[持有关系,委托关系,担保关系] 协议关系历史 This entity identifies relationships between accounts and identifies the type of relationship.[合同与借据,贷款合同与担保合同]3. 协议主题 - 重要实体介绍
  • 42. 3. 协议主题 – 入实体举例 信用卡入此主题的主要源表 S02_TBL_ACM_CRDACC 卡片账户表 S02_TBL_ACM_ACCBSC 财务明细基本信息表超限日期\最后还款日等卡账与财务账的关系与客户的关系卡账与卡号的\财务账与还款账户有效信用额度\取现额度等当前账龄当前余额\本金余额等超限金额\本期消费金额等账户等级等财务账状态[正常,自动关闭]
  • 43. 3. 协议主题 – 申请
  • 44. 3. 协议主题 – 介质
  • 45. 内部机构(INTERNAL ORGANIZATION)是一个比较宽泛的概念,可以是正式机构,也可以是一些具有特定功能的团队。本模型中内部机构是指上海银行的内部组织和业务单元,如分行、支行、储蓄所、部门、销售团队等。 内部机构是一种特殊的当事人,是当事人的子类 内部机构包括所有帐务机构和管理机构,由于未作机构整合,先采用机构编号和来源系统代码做双主键。4. 内部机构主题
  • 46. 4. 内部机构主题
  • 47. 事件(EVENT是银行与客户或潜在客户之间的联系或交易活动,它记录了详细的行为和交易数据,包括存取款、收费、计息、咨询投诉、查询、市场调查、网上交易等。 可能需要也可能不需要银行与客户的直接接触;可能与帐户相关,也可能与帐户无关;可能与资金相关,也可能与资金无关。 通过事件可以帮助了解哪些客户使用哪些渠道做哪种交易事件,交易金额多少、什么时间、在什么地点、与金融机构的哪位员工或部门打交道。5. 事件主题
  • 48. 5. 事件主题
  • 49. 6. 地域主题 地域(LOCATION)是希望观察和分析的任何区域,既包括传统类型的地址信息(如国家、地区、城市、区县、街道等),又包括如电话信息、电子地址、邮箱、黄页等信息。客户可以用于和银行的交互和沟通,也可以被用于某个特殊的场合(比如对帐单寄送地址等)。 由于地址信息(除国家、地区、省份外)目前各业务系统无法实现唯一地址识别,技术实现有很大困难。地址信息主要体现在其他主题的附属信息中,如当事人地址关系等。Main Street
  • 50. 6. 地域主题
  • 51. 6. 地域主题 – 重要实体 当事人地址关系历史.
  • 52. 7. 营销主题 营销活动是为了获取、维护、增强银行与客户的关系而开展的一些促销的活动; 营销活动是一些有组织的活动,其目的可以是为了把某些产品推向市场,也有可能是为了树立银行在市场上的形象; 完整的营销活动应该包括营销策略、营销行为以及营销活动的反馈信息; 收集营销活动的信息可以帮助银行发现最有效的营销方式,了解不同类型客户对营销活动的反馈;
  • 53. 营销活动的策略可能是很多层次的; 一个营销活动可能会导致实施一个或多个实际的促销事件; 一个营销活动可以通过和其他主题的关系,实现一些特别的活动,如只针对某些地区(LOCATION);只涉及某些产品(PRODUCT)、只在某些机构进行(内部组织机构)或者只和某类账户(ACCOUNT)相关; 一些外部的市场信息(如市场细分等)可以服务一些特定的营销活动; 高层营销策略会针对多种渠道设计,但是具体的一个营销事件只涉及一种渠道; 营销事件的结果可能会导致开立一个账户; 一个营销活动可能有多种优惠措施和条件. 7. 营销主题 – 业务规则
  • 54. 7. 营销主题 – 原型设计
  • 55. 7. 营销主题 – 实际落地
  • 56. 8. 渠道主题 渠道(CHANNEL)主题所描述的是当各种事件发生时,当事双方(主要是指客户和银行)进行交互和接触的手段及方法,通过它客户与银行进行接触、购买产品、使用服务并交流信息。 用户通过渠道向金融机构获取关金融机构或金融机构产品信息以及使用金融产品。金融机构通过渠道向用户销售产品或提供服务。
  • 57. 渠道分为若干类型,例如ATM渠道。 当事人可以和渠道之间存在一种或多种关系,也可以不存在任何关系。 一个帐户可以属于一个渠道或者通过一个渠道来进行管理。 渠道有自己的一些相关信息,例如功能,特征或地理位置。 一个渠道有其最大容量,例如每小时可以处理的业务笔数。 8. 渠道主题 - 业务规则
  • 58. 8. 渠道主题
  • 59. 9. 财务主题 财务(FINANCE)主题主要包括银行的总帐信息,是描述科目组织、控制、内部核算等银行核心科目帐务以及预算管理有关的内容。该主题抽象地描述了银行内部帐务的组织模式,能够适应不同的科目组织体系。
  • 60. 9. 财务主题
  • 61. 10. 资产主题 资产(PARTY ASSET)主题是所有可能采集到的各种客户的资产(负债)信息,也包括银行以如向外租赁等业务形式与客户相关的资产信息。这些信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等。 可能是客户的不动产、商品存货、珠宝、机动车辆、以及在其他金融机构的存款、贷款等。
  • 62. 10. 资产主题
  • 63. 主题实体表数量应用依赖表T009026T015830T022412T0319690T0495T05298168T0643T0750T0873T09198T1041T99338由于代码表不配依赖难以精确统计物理模型应用使用分析
  • 64. FS-LDM 十大主题财务 资产当事人地域地理区域,物理的或电子的地址单个人或一组人 事件会导致同客户达成合同的金融或非金融的事件内部组织金融机构或保险公司内部的业务单元协议在客户和金融机构之间达成的关于特定产品的协议产品一种可以在市场上交易的产品或服务,包括条款或条件营销为了获取、挽留客户或提高用户的使用率而采取的战略、计划或促销活动渠道客户和金融机构或保险公司进行接触的途径企业内部的会计信息当事人所有的具有价值且能够获得受益的事物
  • 65. 目录LDM基本概念BOS LDM介绍LDM设计流程
  • 66. 源系统数据是如何入模型的? 信息分析 (ID)逻辑数据 模型设计 (LDM)物理数据 模型设计 (PDM)源和目标 对应关系 (SDM)ETL加载 策略的设计 (ETL)元数据管理 (Metadata)系统长期 运营维护 变更管理
  • 67. 信息分析步骤提供ID资料 系统级分析 数据表级分析
  • 68. 信息分析步骤 - 1.提供ID资料需要提供的资料,每个源系统 用户手册 系统设计书 数据字典 UAT环境 每个源系统制定专门联系人,负责业务沟通及问题解答 本阶段的工作是ID工作的起点和基础
  • 69. 信息分析步骤 - 2.系统级分析源系统分析是从系统层面、业务功能层面、产品层面对源系统进行分析、描述 系统整体性介绍 系统建设背景、目标和定位、设计思想 目前有没有基于该系统完成的分析应用,如果有请详细说明分析应用名称、开发商、使用软硬件、数据周期、业务应用功能简要描述、数据更新机制简要描述。 系统的物理结构图 系统的逻辑结构图 系统实施情况介绍 系统何时完成建设并且投产运行 近期有没有什么改造和升级的计划,如果有,请进行详细说明升级改造的原因,改造计划,改造造成的变动影响等。 如果正在推广的研发和推广的项目,能够具体说明研发进度和推广进度 系统技术介绍 系统使用的软件和硬件平台描述 系统每日工作的时间窗口 是否有日终等批处理操作,如果给出时间窗口 如果系统对外提供数据,提供增量数据还是全量数据 如果系统对外提供数据,建议的数据提供接口模式 如果系统对外提供数据,预估提供数据的时间窗口
  • 70. 信息分析步骤 - 3.数据表级分析基于对源系统的整体分析及样本数据的查看,对每个数据表进行分析 表的性质 字段性质 代码表 数据质量 产出物 《BOS-DW-ID-0301-99-(XXX系统)概览》 .ppt 《BOS-DW-ID-0301-06-LDM(XXX系统)》.er1 《BOS-DW-ID-0301-04-源业务系统数据表概况(XXX系统) 》.xls 《BOS-DW-ID-0301-05-简要数据映射(XXX系统) 》.xls
  • 71. 信息分析步骤 - 3.数据表级分析 产出物
  • 72. 信息分析步骤 - 3.数据表级分析 产出物
  • 73. 信息分析 (ID)逻辑数据 模型设计 (LDM)物理数据 模型设计 (PDM)源和目标 对应关系 (SDM)ETL加载 策略的设计 (ETL)元数据管理 (Metadata)系统长期 运营维护 变更管理模型设计
  • 74. 模型设计步骤Logical Views For Semantic layerPhysical Data Model Foundation Layer Reference Enterprise Logical Data ModelBOS Project Logical Data ModelSubset of FS-LDMCustomized for client requirementsDesigned for Users, BI, Security, geography, S/W tools and applicationsPDMLDMData Warehouse EnvironmentTeradata’s Financial Services Logical Data Model (FS-LDM) Eg. Cubes, views, stars, snowflakesBusiness and Reporting requirementsAggregations, calculations
  • 75. 信息分析 (ID)逻辑数据 模型设计 (LDM)物理数据 模型设计 (PDM)源和目标 对应关系 (SDM)ETL加载 策略的设计 (ETL)元数据管理 (Metadata)系统长期 运营维护 变更管理脚本设计
  • 76. SDM模板从PDM的角度出发,以PDM中的表和字段为目标,从各源系统中找到对应的源表和源字段;一个数据映射Excel文档对应一个主题、一个区域的数据映射关系,其中一个Sheet描述一个目标表,主要包括以下内容: 基本信息描述 ETL作业信息 字段映射描述 表关联描述 更新记录SDM模板
  • 77. SDM模板 – 字段映射信息
  • 78. 算法名称算法说明备注F1:Delete/Insert该算法会首先删除目标表数据,再插入当前数据适用于源数据为全量的情形F2:Upsert根据指定的比对字段,已经在目标表中的,对其进行Update,不在目标表中的(新增)进行插入无论全量、增量都支持F3:History Chain该算法会根据指定的比对字段与目标表进行比对,状态更新了的数据对目标表中数据进行关链,即置End_Date=‘${TX_DATE}’,并新增一条开始日期为‘${TX_DATE}’,结束日期为${MAXDATE}的记录,对于新增的数据,插入记录的开始日期为‘${TX_DATE}’,结束日期为${MAXDATE}无论全量、增量都支持,不过该算法不会像F5那样自动比对找出删除增量,并根据删除数据对目标表进行关链 F4:Economy History Chain算法与F3类似,不同的是如果更新的数据的状态字段都为空值、零值,则仅对这些数据进行关链,不再新增一条开始日期为‘${TX_DATE}’,结束日期为${MAXDATE}的记录,这样下一次加载时这些数据将不会再参与比对(因为参与比对的数据的结束日期为${MAXDATE})无论全量、增量都支持F5:FullData History Chain该算法与F3不同的是它会自动比对找出删除增量,并根据删除数据对目标表进行关链适用于源数据为全量的情形F6:Two-PK History Chain该算法与F3类似,不同的是它在源数据为增量的前提下,它不会对目标数据进行关链操作(因为有些业务含义本身有一对多、多对多的情况,比如:协议当事人关系历史,这样无法根据属性变更就断定目标表中的相关关系就该终止而对其进行关链)无论全量、增量都支持。全量时可以在SDM中指定一个选项,对数据执行关链。F7:Self History Chain可以针对来的数据为多个日期的情形,首尾相连拉出轨迹链无论全量、增量都支持I:Append直接追加适用于源数据为增量的情形SDM模板 – 算法说明
  • 79. 对数据变化都要记录吗结束根据业务分析要求F3/F5策略当前数据对历史数据有影响吗需要基于日期的连续历史轨迹吗I策略F2策略F1策略YESNOYESNONOYESSDM模板 – 策略选取依据
  • 80. 利用Minerva生成 Perl Scripts
  • 81. Question… ?