浅谈BI领域的数据模型设计

金融it

/**********************************/
目录：
第一部分：基础概念
第二部分：设计方式
第三部分：银行业数据模型基本概念介绍
第四部分：银行业数据模型分主题介绍
第五部分：ODS和EDW
/**********************************/
第一部分：基础概念
1.什么是LDM(Logic Data Module)
    LDM是一个业务组织的信息表示方式
    不是Database
    平台独立
    是对业务数据的逻辑表示
    定义存在的数据实体和它们之间的关系
    业务人员通过LDM就可以知道其业务问题能否被解决
2.LDM的特点
    稳定性：
        可以长期满足业务需求
    正确性：
        对真实世界的业务one-to-one 的数据映射
    共享性：
        不是为特定部门或特定应用需求而设计
    灵活性：
        当业务环境变化后，只要进行最小的改动
3.LDM的行业特性
    不同行业有不同的LDM参考模型
    通信(Communication) cLDM
    金融(Financial) FISLDM
    医疗(HealthCare)
    零售(Retail)
    交通(Transportation)
    旅游(Travel)
    制造(Manufacture)
4.为什么要使用LDM(实施端)
    减少成本(cost savings)
    降低风险(Reduce Risk)
    1:1 Mapping(LDM->PDM)
    低维护量(Low Maintenance)
    沟通(Communication)
    全企业级(Cross Functional)
    客户中心(Customer Centric)
5.为什么要用LDM(客户端)
    生成一个精确(accurate)和一致(consistent)的业务数据视图
    对业务规则的清晰表达
    可以超越当前数据的局限,提供数据集成的路线图
    对各个层级的参与者提供沟通的手段
6.建模框架( Data Modeling Frame Work)

7.LDM(Logic Data Module)和PDM(Physical Data Module)


8.LDM和ERD
    ERD (Entity Relationship Diagram)
    ERD 是一个标准建模技术，对LDM进行图形化的表达
    ERD技术可以通过不同的产品进行体现：
        Erwin
        Power Designer
        Visio
    ERD 需要表达：
        实体(Entity)。所有事物
        关系(Relationship)。不同业务实体之间的关联关系
        属性(Attribute)。实体或者关系的数据事实(data fact)，是最低层级的信息，且业务含义不可拆分
        主键(Primary Key)
        关系描述符(Relationship Descriptor)
        外键(Foreign Key)

9.LDM和Table Layout (表样式)
    Table Layout 通过在LDM中加入样例数据(sampling data)，使得业务人员可以更直观的理解数据。
    键属性用蓝色表示，非键属性用红色表示

第二部分：设计方式
    建模方式：
        第一步:定义业务需求与范围（Requirement)
        第二步:定义实体(Entity)
        第三步:定义关系(Relationship/PK/FK)
        第四步:定义属性(No-key Attribute)
        第五步:验证模型(Verify)
        第六步:正则化(Normalization)
        第七步:历史数据建模(History Modeling)
第一步:定义业务需求和范围
    LDM的构建是一个渐进的过程，也是随着企业业务和管理模型不断扩展而演进的。
    LDM是对信息的表示方式，信息的分类就是主题，通过主题定义信息的范围
    同一主题的内容也可能随着业务进行扩充
第二步:定义实体
    什么是实体：
        需要表达和维护的信息就是实体，可以包括人、地点、产品等任何概念。实体是逻辑模型的概念，对应物理模型就是表。
    实体的名称：
        在整个模型中是唯一的
        一般是一个名词(如客户)，可以加上修饰词(如VIP客户)
        实体定义时会发生的错误：
        同义不同名(如员工worker和雇员employee)
        同名不同义(如产品和促销都定义为product)
    实体中的主键(Primary Key)：
        主键是实体中的每个实例（instance） 区别于其他实例的标志。在物理模型中，主键是不同行(row)的区分标志。
        在定义实体时，一般要最先定义主键。在图形表示的时候，一般放在最前面。
    定义主键的一些原则：
        每个实体（表）必须要有主键。即使表是multiset（可能出现重复记录）也必须要有主键。
        每个表只能有一个主键。
        主键值必须唯一（ANSI标准允许不唯一，为了保证数据加载性能，可能主键值不唯一）
        主键值不能为空
        主键值不能被修改
        主键值可以由多个值构成。
第三步:定义关系(Relationship)
    什么是关系(Relationship)：                                                      
        关系是两个不同实体交互方式的表达（如客户购买产品，员工在那个部门）            
        直接关系与间接关系如下图所示，在模型中，只要定义直接关系，而不用定义间接关系。
   
    定义关系的原则：
        关系是唯一的（由涉及的表唯一标示)                                       
        关系对与实体内的所有实例都是适用的（物理模型中对表中的所有row都是适用的)
        需要定义关系的集合表达方式(cardinality)。如1：1、1:M、M:M   
    定义关系的步骤：
        Step1: 识别实体之间是否有关系                     
            是否存在关系                           
            是直接还是间接关系                     
            定义关系的名称                        
        Step2: 识别实体之间的集合表达方式      
            1:1                                    
            1:M                                    
            M:M   
                                             
        Step3:用外键(Foreign Key)将关系表达出来
            外键是表示两个实体中的实例的互相的数量关系
            外键定义的原则：                           
                一个实体可以有0/1/M个外键                 
                外键的值可以不唯一（1:M/M:M)              
                外键的值可以为空(客户可以没有账户)        
                外键的值可以被更改(客户的账户号可以被修改)
                外键可以由多个属性构成                    
                A表的外键的属性和值必须在B表中的PK中存在  
        定义M:M关系需要新建一个关系实体(Associative Entities)：                 
            客户与产品的关系是M:M关系，所以需要定义一个关系实体(订购 subscription)
            将A实体与B实体的主键放在一起，就构成了关系实体。                     
            关系实体的主键是A实体主键+B实体主键
        递归关系：
            在实体内部存在的关系，实体的外键是本实体的主键                                 
            如下图所示
            
            管理者本身也是一个员工                                                               
            MgrEmp# 是Empolyee外键，对应的主键是Empolyee的Emp#
第四步: 定义属性( Attribute Modeling)
    属性是描述实体(entity)的相关的、细节的数据项
    定义属性的原则:                              
        名称在本实体内唯一                          
        与本实体相关                                
        不能够被别的属性所描述                     
        有单一的值域空间                           
        属性应该是对实体内的所有实例都是有效的      
    属性的类型:                                 
        键属性（主键、外键）                        
        非键属性                                    
        派生属性，能够从别的属性中计算而得的属性
第五步:验证模型(Verify)   
    通过模型验证发现上述4步的问题，不断修正，多次循环。                        
    与客户讨论，确认客户的业务需求、业务问题和业务约束条件能否通过模型进行体现。
    不要考虑任何有关物理模型的问题。                                          
    但客户的业务需求能够通过模型进行表达，就结束模型的优化。
第六步:正则化(Normalization)
    正则化是设计实体的属性的规则，使得实体-属性能够更加精确的反应客观事实                  
    正则化的作用:                                                         
        减少数据冗余（避免数据多处存储）                                    
        减少由于数据修改导致的数据不一致（只修改了一处数据，而另一处忘了修改)
    正则化的原则“一个事实，一处存放”(one fact ,one place)              
    1NF，2NF，3NF 解决非键属性对主键的依赖性                             
    4NF, 5NF 解决是键属性互相之间的依赖关系。                           
    一般LDM建模只要求到3NF      
    什么是3NF:
        1NF: The Key（有主键，且没有重复的属性)                                                                                      
        2NF: The Whole Key (非键属性对主键的依赖关系)                                       
        3NF: And Nothing But Key(属性对主键依赖关系是直接的，而非间接的)                     
第七步:历史数据建模(History Modeling)
    业务人员不仅要对当前(current)的数据进行分析，而且要对数据的变化进行追踪(track)，而且需要对历史数据进行分析。
    这就要求对数据的变化历史进行建模，这就是历史数据建模(History Modeling)
   
    History Modeling的原则：
        Current和History：                                                                                                                                                                                                                  
            如果在模型中既存在当前实体(current entity)也存在历史实体(history entity)，那么当前实体的信息必然是冗余的。
            在设计LDM中，只需保留历史实体，在进行物理模型设计时，可以加上一个当前标志(current flag)，表明哪些记录是对应当前实体的信息。
        历史数据建模：                                                                                                                                                                                                                        
            将需要保存历史信息的属性放入到历史实体(History Entity)中。                                                                                                                                                                           
            时间属性作为主键的一部分。                                                                                                                                                                                                           
            历史实体(History entity)的主键必然是一个符合主键(包括多个属性)
第三部分：银行业数据模型基本概念介绍
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.应用集市层
        定位：                                                                           
            提供特定应用支持            
        特点：                        
            面向应用                    
            形式各异，各自独立         
            按需定制，满足特定业务的需求                                                      

来源https://blog.csdn.net/ding_shan/article/details/51037706
https://blog.csdn.net/ding_shan/article/details/51037738

金融it

/**********************************/
目录：
第一部分：基础概念
第二部分：设计方式
第三部分：银行业数据模型基本概念介绍
第四部分：银行业数据模型分主题介绍
第五部分：ODS和EDW
/**********************************/
第一部分：基础概念
1.什么是LDM(Logic Data Module)
    LDM是一个业务组织的信息表示方式
    不是Database
    平台独立
    是对业务数据的逻辑表示
    定义存在的数据实体和它们之间的关系
    业务人员通过LDM就可以知道其业务问题能否被解决
2.LDM的特点
    稳定性：
        可以长期满足业务需求
    正确性：
        对真实世界的业务one-to-one 的数据映射
    共享性：
        不是为特定部门或特定应用需求而设计
    灵活性：
        当业务环境变化后，只要进行最小的改动
3.LDM的行业特性
    不同行业有不同的LDM参考模型
    通信(Communication) cLDM
    金融(Financial) FISLDM
    医疗(HealthCare)
    零售(Retail)
    交通(Transportation)
    旅游(Travel)
    制造(Manufacture)
4.为什么要使用LDM(实施端)
    减少成本(cost savings)
    降低风险(Reduce Risk)
    1:1 Mapping(LDM->PDM)
    低维护量(Low Maintenance)
    沟通(Communication)
    全企业级(Cross Functional)
    客户中心(Customer Centric)
5.为什么要用LDM(客户端)
    生成一个精确(accurate)和一致(consistent)的业务数据视图
    对业务规则的清晰表达
    可以超越当前数据的局限,提供数据集成的路线图
    对各个层级的参与者提供沟通的手段
6.建模框架( Data Modeling Frame Work)

7.LDM(Logic Data Module)和PDM(Physical Data Module)


8.LDM和ERD
    ERD (Entity Relationship Diagram)
    ERD 是一个标准建模技术，对LDM进行图形化的表达
    ERD技术可以通过不同的产品进行体现：
        Erwin
        Power Designer
        Visio
    ERD 需要表达：
        实体(Entity)。所有事物
        关系(Relationship)。不同业务实体之间的关联关系
        属性(Attribute)。实体或者关系的数据事实(data fact)，是最低层级的信息，且业务含义不可拆分
        主键(Primary Key)
        关系描述符(Relationship Descriptor)
        外键(Foreign Key)

9.LDM和Table Layout (表样式)
    Table Layout 通过在LDM中加入样例数据(sampling data)，使得业务人员可以更直观的理解数据。
    键属性用蓝色表示，非键属性用红色表示

第二部分：设计方式
    建模方式：
        第一步:定义业务需求与范围（Requirement)
        第二步:定义实体(Entity)
        第三步:定义关系(Relationship/PK/FK)
        第四步:定义属性(No-key Attribute)
        第五步:验证模型(Verify)
        第六步:正则化(Normalization)
        第七步:历史数据建模(History Modeling)
第一步:定义业务需求和范围
    LDM的构建是一个渐进的过程，也是随着企业业务和管理模型不断扩展而演进的。
    LDM是对信息的表示方式，信息的分类就是主题，通过主题定义信息的范围
    同一主题的内容也可能随着业务进行扩充
第二步:定义实体
    什么是实体：
        需要表达和维护的信息就是实体，可以包括人、地点、产品等任何概念。实体是逻辑模型的概念，对应物理模型就是表。
    实体的名称：
        在整个模型中是唯一的
        一般是一个名词(如客户)，可以加上修饰词(如VIP客户)
        实体定义时会发生的错误：
        同义不同名(如员工worker和雇员employee)
        同名不同义(如产品和促销都定义为product)
    实体中的主键(Primary Key)：
        主键是实体中的每个实例（instance） 区别于其他实例的标志。在物理模型中，主键是不同行(row)的区分标志。
        在定义实体时，一般要最先定义主键。在图形表示的时候，一般放在最前面。
    定义主键的一些原则：
        每个实体（表）必须要有主键。即使表是multiset（可能出现重复记录）也必须要有主键。
        每个表只能有一个主键。
        主键值必须唯一（ANSI标准允许不唯一，为了保证数据加载性能，可能主键值不唯一）
        主键值不能为空
        主键值不能被修改
        主键值可以由多个值构成。
第三步:定义关系(Relationship)
    什么是关系(Relationship)：                                                      
        关系是两个不同实体交互方式的表达（如客户购买产品，员工在那个部门）            
        直接关系与间接关系如下图所示，在模型中，只要定义直接关系，而不用定义间接关系。
   
    定义关系的原则：
        关系是唯一的（由涉及的表唯一标示)                                       
        关系对与实体内的所有实例都是适用的（物理模型中对表中的所有row都是适用的)
        需要定义关系的集合表达方式(cardinality)。如1：1、1:M、M:M   
    定义关系的步骤：
        Step1: 识别实体之间是否有关系                     
            是否存在关系                           
            是直接还是间接关系                     
            定义关系的名称                        
        Step2: 识别实体之间的集合表达方式      
            1:1                                    
            1:M                                    
            M:M   
                                             
        Step3:用外键(Foreign Key)将关系表达出来
            外键是表示两个实体中的实例的互相的数量关系
            外键定义的原则：                           
                一个实体可以有0/1/M个外键                 
                外键的值可以不唯一（1:M/M:M)              
                外键的值可以为空(客户可以没有账户)        
                外键的值可以被更改(客户的账户号可以被修改)
                外键可以由多个属性构成                    
                A表的外键的属性和值必须在B表中的PK中存在  
        定义M:M关系需要新建一个关系实体(Associative Entities)：                 
            客户与产品的关系是M:M关系，所以需要定义一个关系实体(订购 subscription)
            将A实体与B实体的主键放在一起，就构成了关系实体。                     
            关系实体的主键是A实体主键+B实体主键
        递归关系：
            在实体内部存在的关系，实体的外键是本实体的主键                                 
            如下图所示
            
            管理者本身也是一个员工                                                               
            MgrEmp# 是Empolyee外键，对应的主键是Empolyee的Emp#
第四步: 定义属性( Attribute Modeling)
    属性是描述实体(entity)的相关的、细节的数据项
    定义属性的原则:                              
        名称在本实体内唯一                          
        与本实体相关                                
        不能够被别的属性所描述                     
        有单一的值域空间                           
        属性应该是对实体内的所有实例都是有效的      
    属性的类型:                                 
        键属性（主键、外键）                        
        非键属性                                    
        派生属性，能够从别的属性中计算而得的属性
第五步:验证模型(Verify)   
    通过模型验证发现上述4步的问题，不断修正，多次循环。                        
    与客户讨论，确认客户的业务需求、业务问题和业务约束条件能否通过模型进行体现。
    不要考虑任何有关物理模型的问题。                                          
    但客户的业务需求能够通过模型进行表达，就结束模型的优化。
第六步:正则化(Normalization)
    正则化是设计实体的属性的规则，使得实体-属性能够更加精确的反应客观事实                  
    正则化的作用:                                                         
        减少数据冗余（避免数据多处存储）                                    
        减少由于数据修改导致的数据不一致（只修改了一处数据，而另一处忘了修改)
    正则化的原则“一个事实，一处存放”(one fact ,one place)              
    1NF，2NF，3NF 解决非键属性对主键的依赖性                             
    4NF, 5NF 解决是键属性互相之间的依赖关系。                           
    一般LDM建模只要求到3NF      
    什么是3NF:
        1NF: The Key（有主键，且没有重复的属性)                                                                                      
        2NF: The Whole Key (非键属性对主键的依赖关系)                                       
        3NF: And Nothing But Key(属性对主键依赖关系是直接的，而非间接的)                     
第七步:历史数据建模(History Modeling)
    业务人员不仅要对当前(current)的数据进行分析，而且要对数据的变化进行追踪(track)，而且需要对历史数据进行分析。
    这就要求对数据的变化历史进行建模，这就是历史数据建模(History Modeling)
   
    History Modeling的原则：
        Current和History：                                                                                                                                                                                                                  
            如果在模型中既存在当前实体(current entity)也存在历史实体(history entity)，那么当前实体的信息必然是冗余的。
            在设计LDM中，只需保留历史实体，在进行物理模型设计时，可以加上一个当前标志(current flag)，表明哪些记录是对应当前实体的信息。
        历史数据建模：                                                                                                                                                                                                                        
            将需要保存历史信息的属性放入到历史实体(History Entity)中。                                                                                                                                                                           
            时间属性作为主键的一部分。                                                                                                                                                                                                           
            历史实体(History entity)的主键必然是一个符合主键(包括多个属性)
第三部分：银行业数据模型基本概念介绍
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.应用集市层
        定位：                                                                           
            提供特定应用支持            
        特点：                        
            面向应用                    
            形式各异，各自独立         
            按需定制，满足特定业务的需求                                                      

来源https://blog.csdn.net/ding_shan/article/details/51037706
https://blog.csdn.net/ding_shan/article/details/51037738