浅谈BI领域的数据模型设计（二)
/**********************************/ 目录： 第一部分：基础概念 第二部分：设计方式 第三部分：银行业数据模型基本概念介绍 第四部分：银行业数据模型分主题介绍 第五部分：ODS和EDW /**********************************/ 第三部分：银行业数据模型基本概念介绍 1.什么是数据模型 模型是对现实世界特征的模拟和抽象。 数据模型是描述数据与数据之间的关系的图形化视图,它通过实体、 属性及其关系对企业运营和管理过程中涉及的所有业务概念和逻辑规则进行统一定义、命名和编码。 银行业数据模型定义了银行重要的业务概念和各个主题域内部主要实体与实体间的关系。 2.逻辑数据模型 一个逻辑数据模型是建立商业智能的基础框架，也是建立数据仓库系统的第一步， 并且是奠定现在或者将来为分析者提供有价值数据分析的重要基础。 逻辑数据模型描述模型实体以及它们如何关联，是以加强理解为目的而对所考察对象进行的抽象。 相对于物理数据模型，逻辑数据模型的设计是独立于特定数据库平台。 3.物理数据模型 物理数据模型描述模型实体的细节。包括通过使用特定数据库如何实施模型的信息。 在设计物理数据模型时需要考虑使用什么数据库、字段类型、长度、索引等，也要考虑应用程序的性能等因素。 4.逻辑数据模型特点 一个逻辑数据模型应该准确反映体现企业业务的并且为企业所关心的信息需求、规则和策略。 逻辑数据模型会被用来创建物理数据模型。 逻辑数据模型与具体平台无关。 只有在业务发生变化时，逻辑数据模型才会变化。 逻辑数据模型可以被业务部门所理解。 逻辑数据模型可以提供稳定性、可靠性、可获取性和可重用性。 5.逻辑数据模型的优点 反映了业务的事实和规则， 面向业务用户，强调需求而不是技术方案， 重点讨论对业务来说什么是重要的， 理解一部分数据和其他数据的关系， 形成一个一致的视图，避免了数据冗余和不同版本数据的存在， 是未来扩展地一个稳定的基础， 创建对业务问题和优先级的统一理解， 创建统一的业务语言， 促进业务人员与IT人员之间的信息交换。 6.逻辑数据建模的概念 (1)主题 (2)实体 (3)属性 (4)关系 (5)主键 (6)外键 (7)范式 (1)主题 根据数据仓库概念的含义，数据仓库拥有以下四个特点： a.面向主题。 操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离， 而数据仓库中的数据是按照一定的主题域进行组织。 主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。 b.集成的。 面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。 而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性， 以保证数据仓库内的信息是关于整个企业的一致的全局信息。 c.相对稳定的。 操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。 数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后， 一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。 d.反映历史变化。 操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息， 系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息， 可以对企业的发展历程和未来趋势做出定量分析和预测。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。 数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。 而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。 因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程。 当事人、内部机构 – 当事人 产品、协议、资产 – 金融产品及其购买过程 事件、营销、财务 – 交易过程及其结果 渠道、地域 – 支持银行业务的基本要素 实例：目前某某银行系统包括当事人、内部机构、产品、协议、事件、渠道、财务七个主题以及主题之间的关系， 模型的概貌如下图所示： (2)实体 实体：我们把客观存在并且可以相互区别的事物称为实体。 实体可以是实际事物，也可以是抽象事件,每个实体是由一组相似的对象组成，这些对象称为实例。 实体描述业务元数据（如客户、当事人实体）或元数据之间的关系（如当事人协议关系历史实体）。 根据实体的特征，我们将其划分为独立型实体（Independent Entity）和依赖型实体（Dependent Entity）。 独立型实体不依赖于其他实体存在；而依赖型实体中的主键必须是独立实体主键的一部分或者全部。 (3)属性 属性：描述实体的特性称为属性，如当事人实体中的当事人种类（个人当事人，机构当事人）。 属性可分为以下几种类型 主键（Primary Key） 识别实体实例唯一性的属性或属性组。 外键（Foreign Key） 父实体的PK通过关系加入到子实体中作为PK，此称之为外键 非键属性 （ Non Key） 不是实体主键属性的其他属性 基础名 （Basename） 外键的原来名称 角色名 （ Rolename ） 外键的新名称，表明取值是父实体属性的子集 (4)关系 关系是描述实体间关联性的表示。 关系数量（Cardinality）反映两个或多个实体间关系的业务规则。 标识关系（identifying relationship）： 实体主键迁移給子实体作为部分主键(PK) 实体須由父实体决定,其存在亦需依附父实体。 非标识强制关系 (Non-Identifying Mandatory Relationship)： 实体主键迁移給子实体作为非键属性(非PK) , 其表示並不能由父实体來决定子实体, 子实体不須由父实体决定,但其存在仍需依附父实体 (mandatory) 非标识非强制关系 (Non-Identifying Non-Mandatory Relationship)： 实体 PK 迁移到子实体当作非主键且与子实体为 非标识行 ( Non-Identifying )， 实体与父实体间的标识为独立存在性，实体信息本身不需完全依赖父实体。 多对多关系（Many-to-many relationship）： 两实体间存在多对多的关系。 递归关系 (Recursive relationship)： 同一个实体既是父也是子，任何递归关系必须是非标识的。 子类关系（Subtype relationship）： 子类实体和所属父实体的关系 。 子类（ Subtype ）和超类（Supertype）： 为了进一步描述一个实体集中某些实体的不同性质，可以从该实体集中取出一部分实体构成一个（或多个）新的实体集， 称新的实体集是原来实体集的子类，而原实体集是新实体集的超类。 (7)范式 第一范式 The key 第二范式 The whole key 第三范式 Nothing but the key 第一范式 定义：如果一个关系模式R 的每个属性值都是不可以再分的数据单位，那么关系模式R是第一范式的。 符合第一范式的特点有 (1)有主关键字 (2)主键不能为空， (3)主键不能重复 (4)字段不可以再分 第二范式 定义：如果一个关系模式R 满足第一范式，且每一个非键值属性完全依赖于主属性（主关键字），则满足第二范式。 第三范式 定义：如果一个关系模式R 满足第二范式，且每一个非主属性均非转递函数依赖于主属性，则该关系满足3NF。 实体中没有非键属性依赖另一个非键属性，即非键属性仅仅依赖于主键。 满足第三范式的关系必须满足以下三个条件： 每个属性的值唯一，不具有多义性； 每个非主属性必须完全依赖于整个主键，而非主键的一部分； 关系模式中不存在传递依赖。 7.逻辑数据模型举例 第四部分：银行业数据模型分主题介绍 1.PARTY主题： 当事人（PARTY）是指银行作为一个金融机构所服务的任意对象和感兴趣进行分析的各种个人或团体客户、潜在客户、代理机构、雇员、分行、部门等。 一个PARTY可以同时是这当中许多种角色。 该主题除了要存放各种基本信息之外，还可以存储当事人所拥有的固有资产类信息； 当事人和其他多个主题之间（账户、内部机构等）存在密切的关联； 建立银行客户的单一视图； 实现基于客户基本信息的分析； 为进行全面的客户关系管理和市场营销奠定基础； PARTY主题—主要实体： PARTY主题—主要分类： PARTY主题—主要关系： PARTY主题—主要派生数据： 2.Internal Organization主题： 内部组织机构是指金融机构的内部组织和业务单元，如分行、客服中心、支行、储蓄所、部门、销售团队等等。 是一种特殊的PARTY 包括所有的组织类型 体现内部机构之间复杂的关系 提供层次和矩阵结构 不仅包含自身的内部组织机构，还包括其他的内部组织 和多个主题有关联 Internal Organization-主要实体： Internal Org主题—主要关系： 3.PRODUCT主题： 产品是金融机构销售或提供的可市场化的产品、产品包和服务。 产品可以通过产品特征加以描述，产品特征是金融机构提供的所有可以应用于产品的有效产品特征。 它标识了金融机构在提供产品时的限制或附加条件。在银行业的例子有手续费、期限、允许的展期和提前通知的要求等。 产品与当事人、帐户之间都存在各种关系。 为满足银行内部管理的需要和适应不断变化的业务需求，可以根据实际情况结合产品特性将产品分组，如个人存款产品组、公司贷款产品组等 ，这些即“产品组”。 出于市场竞争的需要，或作为市场营销的结果，将一些产品打包、捆绑销售，称其为“产品包”。 PRODUCT主题—业务规则： 一个产品有一个命名和描述； 一个产品可能是一个产品包的一部分； 一个产品被若干个产品特征（feature）所描述； 一个产品特征可以应用于若干个产品； 产品可以被划分成产品组（group）； 一个当事人可以针对一个产品或产品包充当若干角色； 产品和产品的特征可以随着地区的不同而有所差异； PRODUCT主题– 关键实体： PRODUCT主题—分类： 4.AGREEMENT主题： AGREEMENT是金融机构与客户之间针对某种特定产品或服务而签立的契约关系。例如银行的帐户，保险公司的保单。 包括AGREEMENT的申请、报价、还价以及开立等完整信息。 建立AGREEMENT 、当事人、产品主题之间的关系，识别持有某种产品客户的特征，寻找具有相似特征的潜在客户销售相同的产品，实现交叉销售。 AGREEMENT主题与事件主题和内部机构主题也有密切的联系 AGREEMENT协议业务规则： 当金融机构与客户之间针对某种产品或服务的条款和条件达成协议时， 一个AGREEMENT就会被开立。 在一个时间点，一个AGREEMENT只能对应一种产品，该产品可能是一个产品包的一部分。 AGREEMENT可能是客户接受金融机构关于某项产品报价的结果。 一个AGREEMENT除了持有人外，可能与其他的当事人有关系，如受益人、共同签字人、担保人等，这些也是当事人对AGREEMENT的角色。 AGREEMENT也可能与其他AGREEMENT相关联，如一个帐户由于筹措资金的需要而被另一个帐户所取代，或一个帐户对另一个帐户提供担保。 AGREEMENT主题-主要实体： (1)协议唯一标识由两部分组成：协议号＋协议修饰符。其中“协议号”沿用源业务系统使用的编号（目前为帐号）， “协议修饰符”目前缺省填默认值，如果多个系统的协议号可能重复，则协议修饰符再根据不同的业务系统分配相应取值。 (2)活期帐户(18位)、定期(19位)、内部帐户(28位)、定期一本通(14位) (3)该实体记录了客户在金融机构开立的帐户的详细信息。一个帐户由Account Num和Account Modifier Num唯一识别。 AGREEMENT主题-主要关系： AGREEMENT主题-分类： AGREEMENT主题-与其他主题的关系： 5.EVENT主题： 事件是银行与客户或潜在客户之间的联系或交易活动，它记录了详细的行为和交易数据， 包括存取款、收费、计息、咨询投诉、查询、市场调查、网上交易等。 可能需要也可能不需要银行与客户的直接接触；可能与帐户相关，也可能与帐户无关； 可能与资金相关，也可能与资金无关。 通过事件可以帮助了解哪些客户使用哪些渠道做哪种交易事件， 交易金额多少、什么时间、在什么地点、与金融机构的哪位员工或部门打交道。 EVENT主题－关键实体： 事件实体记录了银行的所有交互活动。 事件作为总表，记录来自各个系统的所有事件信息，包括交易机构、交易日期、交易码、交易金额、交易涉及的协议等主要信息。 这些事件可能与资金相关，也可能与资金无关。可能与帐户相关，也可能与帐户无关。 事件属性中保留业务系统的交易码。 与事件相关的当事人记录在“当事人事件关系”中，一个事件可能与多个当事人相关， 包括引发事件的客户、联系客户的员工、处理事件的金融机构、购买事件的商户、提供电话服务的呼叫中心。 EVENT主题－关键分类： 储蓄事件记录了来自储蓄统版系统的事件信息，包括储蓄业务流水、非帐务流水、会计清算流水。 中间业务事件和汇兑事件，记录来自中间业务系统和汇兑系统的事件。 EVENT主题－关键关系： 事件关系历史——记录特殊事件如冲正事件、恢复事件、调整事件等与原交易事件的关系。 事件重要介质——记录交易过程中与重要介质间的关系，例如一笔来自汇兑系统的(包含帐户)事件和汇票号间存在着关系。 这些事件可能与资金相关，也可能与资金无关。可能与帐户相关，也可能与帐户无关。 6.CHANNEL主题： 用户通过渠道向金融机构获取关金融机构或金融机构产品信息以及使用金融产品。 金融机构通过渠道向用户销售产品或提供服务。 渠道与当事人、产品、帐号等其他实体存在各种关系。 渠道分为若干渠道类型。 CHANNEL主题 – 业务规则： 渠道分为若干类型，例如ATM渠道。 当事人可以和渠道之间存在一种或多种关系，也可以不存在任何关系。 一个帐户可以属于一个渠道或者通过一个渠道来进行管理。 渠道有自己的一些相关信息，例如功能，特征或地理位置。 一个渠道有其最大容量，例如每小时可以处理的业务笔数。 CHANNEL主题 - 渠道实体： 实体CHANNEL标识了所有金融机构用来与用户进行销售或服务联系时所使用的渠道。 一个渠道是用户用来接受有关金融机构或金融机构产品信息以及使用金融产品时的载体。 在实体CHANNEL 中每一个特定的渠道都有一个ID号相对应。例如，一台ATM机有一个ID号，一个POS终端也有一个ID号。 实体CHANNEL也包含了外部渠道。例如其他机构的ATM机器 CHANNEL主题—分类： 7.FINANCE财务 该主题直接与总帐相对应，是描述科目组织、控制、内部核算等核心科目帐务以及预算管理有关的内容。 FINANCE财务主题－主要实体： 会计科目描述会计科目的相关信息，对应会计不同的科目类型，包括资产类科目、贷款科目、负债类科目等。 会计科目余额历史描述每个机构每个科目在每天的财务实际值，包括发生额、笔数和余额。 储蓄科目余额详细信息描述每个机构每个科目在每天的财务实际明细值，包括现金、转帐等分类明细。 8.CAMPAIGN主题 营销活动是为了获取、维护、增强银行与客户的关系而开展的一些促销的活动； 营销活动是一些有组织的活动，其目的可以是为了把某些产品推向市场，也有可能是为了树立银行在市场上的形象； 完整的营销活动应该包括营销策略、营销行为以及营销活动的反馈信息； 收集营销活动的信息可以帮助银行发现最有效的营销方式，了解不同类型客户对营销活动的反馈； CAMPAIGN主题—业务规则： 营销活动的策略可能是很多层次的； 一个营销活动可能会导致实施一个或多个实际的促销事件； 一个营销活动可以通过和其他主题的关系，实现一些特别的活动，如只针对某些地区（LOCATION）； 只涉及某些产品（PRODUCT）、只在某些机构进行（内部组织机构）或者只和某类账户（ACCOUNT）相关； 一些外部的市场信息（如市场细分等）可以服务一些特定的营销活动； 高层营销策略会针对多种渠道设计，但是具体的一个营销事件只涉及一种渠道； 营销事件的结果可能会导致开立一个账户； 一个营销活动可能有多种优惠措施和条件； CAMPAIGN主题－主要实体： 营销实体主要记录营销活动计划收入、预计成本等。 自关联，可存放所有层次的营销策略， 营销活动与其他主题的关系。例如：营销活动地址关系历史，主要记录开展营销活动的地区 促销活动主要记录实际实施的一些结果的记录； 9.客户资产Asset 客户资产（ASSET）主题是所有可能采集到的各种客户的资产（负债）信息，包括有形的和无形的各种客户资产/负债， 同时还可以存储银行向外租赁的各种资产信息。 可能是客户的不动产、商品存货、珠宝、机动车辆、以及在其他金融机构的存款、贷款等。 客户资产Asset主题： 10.LOCATION主题 LOCATION主题是指银行希望关注或考察的任何层次的地理区域和地址。如国家、省份、城市、县、乡村等。 LOCATION主题包含“具体地址”、“地区”、“地理位置”等不同层次的信息。 该主题和事件、产品、渠道、内部组织机构、营销活动等主题都有着密切的联系。 LOCATION主题—业务规则： 一个地址可能是物理地址、电子地址、电话、邮箱地址等； 一个当事人可能有0～n个地址，这些地址又可以分成主地址、次选地址或者邮寄地址等； 账户的对帐单可能需要寄送到某个地址； 地区的定义可以根据银行不同目的进行设计，比如某项产品的销售区域或者某项评级的地区等； 可以体现具体地址和地区之间的关联； 内部组织机构可以覆盖多个地区； LOCATION主题—主要实体和分类： 第五部分：ODS和EDW 一个相对完整的BI数据架构： 各层设计重点： 整合模型层： 主题定义 框架设计 整合策略 实施方法 共性加工层： 应用筛选 应用提炼 应用集市层： 整体性 一致性 不同类型项目的数据层次建议： ODS： 技术缓冲层:视加工过程是否需要而定，非必须，但一般会有同源设计，基本不做处理 近源模型层:必须，是ODS核心模型层简单处理 整合模型层:视项目具体需求而定，非必须建设层次只针对必须整合且比较基础的部分才考虑建设此层 共性加工层:视项目具体需求而定，非必须建设层次 应用集市层:视项目具体需求而定，分仓内仓外两种建设策略 EDW： 技术缓冲层:视加工过程是否需要而定，非必须，但一般会有同源设计，基本不做处理 近源模型层:视项目具体需求而定，非必须建设层次 整合模型层:必须，是EDW核心模型层整合设计 共性加工层:建议保留兼顾业务需求和数据处理性能双方需求 应用集市层:视具体情况而定，分仓内仓外两种建设策略按单个应用分别建设 1.共性加工层 定位： 提供相对中性，具有业务意义的初级加工数据，支持上层应用的数据加工，或供业务人员的访问 特点： 全局考虑，提炼需求共性 多层次设计，多种数据粒度 侧重业务理解，蕴含丰富的业务规则 2.应用集市层 定位： 提供特定应用支持 特点： 面向应用 形式各异，各自独立 按需定制，满足特定业务的需求