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

分类： 数据仓库与数据挖掘

/**********************************/
目录：
第一部分：基础概念
第二部分：设计方式
第三部分：银行业数据模型基本概念介绍
第四部分：银行业数据模型分主题介绍
第五部分：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)的主键必然是一个符合主键(包括多个属性)