第九章 商业智能项目模型的建立

    9.4.1  ODS逻辑模型

    1．ODS逻辑模型设计

    ODS逻辑模型设计通过ODS统一信息视图区集成各类业务系统的源数据，以数据主题域作为设计的基础。ODS统一信息视图区有选择性的集成各类业务系统的数据，通过ETL数据抽取、转换、加载与业务系统进行交互，它主要保存与主题相关的、实时性的信息，因此ODS统一信息视图区具有准实时性的特点；而业务系统的数据通过一定的时间间隔，最终以主题的形式反映到ODS统一信息视图区中。如图9-11所示，用户可以访问ODS统一信息视图区，以便快速查询某个主题的信息。

图9-11  业务系统与ODS统一信息视图区的交互

    通过业务系统的不断完善和加强，ODS逻辑模型不断得到补充。企业从外部或者内部生产经营活动中获得各种业务数据，按照业务功能分成几类主题域，由ODS统一信息视图区描述各个主题域。如图9-12所示，美国国防部整体可以划分成人员与组织主题域、科技研发主题域、国防财政主题域、反恐主题域、安全主题域、作战计划主题域、能源主题域、通信主题域、人力资源主题域。

图9-12  美国国防部划分的主题域

    ODS统一信息视图区的逻辑模型可以用绿色表示中间库编码，橙色表示自己的私有编码，黄色表示统一编码。美国大兵实体关联各个编码实体，包括装备类型编码实体、通信地址编码实体、军衔等级编码实体、作战地区编码实体。其中装备类型编码实体和作战地区编码实体作为逻辑模型中的中间库编码，通信地址编码实体作为私有编码，军衔等级编码实体作为整个主题域的统一编码。它们都隶属于人员与组织主题域。该主题域下的各个编码实体如图9-13所示。

    2．ODS逻辑模型的设计步骤

    ODS逻辑模型设计主要考虑业务之间的关系和业务处理的流程。处理的步骤如下：

    （1）确定业务系统数据的范围

    在ODS逻辑模型设计中，确定业务系统数据范围是在调研的基础上进行的，然后再进行主题的划分，以确保主题需要的数据都能从业务系统中获得。逻辑模型设计过程中需要对各种业务模型进行合并或者拆分，然后再进行抽象，以便划分ODS数据主题的范围。

图9-13  人员与组织主题域的编码实体

    （2）对主题的定义

    根据调研的结果和业务系统数据的范围，对较大的数据主题进行分解、定义，以便形成各个主题。

    （3）确定主题的元素

    根据每个主题，分别定义实体、实体之间的关系，每个实体的属性和存储粒度等。

    （4）合并相同的实体及其属性

    对每个主题中相似的实体及其属性进行合并，保证各实体的一致性和唯一性。

    ODS逻辑模型的设计步骤如图9-14所示。

图9-14  ODS逻辑模型的设计步骤

    3．ODS的存储周期和存储粒度

    ODS的存储周期分为以下几种情况：

    1）当临时数据从ODS存储区加载到数据仓库后，需要删除ODS存储区中的临时数据。

    2）对于细节性或者汇总的数据，可以按照实际的业务需求，以年、季、月进行存储，并且删除过期数据。

    3）ODS存储区中如果存在一些有价值的数据，但是使用频率较低，则需要将数据备份到其他存储介质中，为以后使用作准备。

    总结：存储粒度的划分将直接影响ODS逻辑模型的设计和ODS存储区的数据量，ODS的存储粒度一般与源数据保持一致。

    4．ODS逻辑模型实例

    如图9-15所示，国家、省、地市、县、区等实体继承地区实体。

图9-15  ODS逻辑建模实例

    模型描述见表9-1～表9-7。

表9-1  国家

表9-2  省

表9-3  地市

表9-4  县

表9-5  区

表9-6  地区

表9-7  地区范围类型

    9.4.2  数据仓库逻辑模型

    1．数据仓库逻辑模型设计

    数据仓库逻辑模型是对概念模型的进一步细化和分解，主要描述了实体、属性以及实体之间的关系。数据仓库逻辑模型设计的主要工作（见图9-16）有：

    1）以概念模型为基础，进一步分解、细化当前的主题域。

    2）定义合适的数据来源。

    3）确定数据仓库存储的粒度。

    4）确定数据仓库模型中的实体、属性以及实体之间的关系。

图9-16  数据仓库逻辑模型设计的主要工作

    2．确定数据仓库的存储粒度

    数据仓库逻辑设计主要解决数据仓库的粒度划分问题。粒度层次的划分直接决定了数据仓库中的数据量和查询方式。要选择一个合适的粒度级，除了业务上的需求，更需要项目经验的积累。在细节程度很高的数据上建立轻度汇总会浪费数据库资源，降低查询的灵活性，但是会减少数据仓库中的数据量，提高数据仓库运行的效率。而如何确定数据仓库的存储粒度，需要得到用户的认可。

    3．确定数据仓库的存储

    数据仓库的存储一般是稳定的，不易变化的。对于查询频率高的业务数据，需要将数据存放到数据仓库中；对于一些查询频率低的，并且已经超出了存储期限的业务数据，应该分离到外部存储介质上，以备将来查询使用。

    4．数据仓库的建模方法

    数据仓库一般的建模方法是通过调研的结果和业务系统详细说明文档，经过分析、梳理列出所有可能的数据主题。根据分析得出的数据主题，结合相关业务的关注点可以划分出各个主题域。主题域通常是联系较为紧密的数据主题的集合。例如，从调研中获悉该业务包含以下数据主题：客户基本信息、客户信用信息、客户资产信息、毕业学校信息、出生日期、地址信息、岗位信息、联系方式信息、婚姻状况信息。可以根据业务的关注点，将这些数据主题划分成员工信息主题域和客户主题域。其中，员工信息主题域包含毕业学校信息、出生日期、地址信息、岗位信息、联系方式信息、婚姻状况信息；客户主题域包含客户基本信息、客户信用信息、客户资产信息。

    员工信息主题域和客户主题域如图9-17所示。

图9-17  员工信息主题域和客户主题域

    5．数据仓库主题域设计

    主题域设计是数据仓库逻辑模型建设中重要的一步，因为它反映了企业主要的业务活动和内容，根据企业活动的特点和业务之间的关联关系进行主题域的划分。主题域描述了企业活动的核心内容，如图9-18所示，北大西洋公约组织(北约)的主题域设计包含了北约的宗旨、会议、组织机构、战略、主要事件等主题域。

图9-18  主题域

    6．数据仓库主题设计

    主题设计是对主题域进一步分解、细化的过程。主题域下面可以有多个主题，主题还可以划分成更多的主题，而实体则是不可划分的最小单位。主题域、主题、实体的关系如图9-19所示。

图9-19  主题域、主题、实体的关系

    主题设计的原则如下：

    1）主题设计的命名方式与主题域的命名方式保持一致。

    2）对主题进行不断的细化、分解，直到明确模型中的业务概念为止。

    3）当主题细化、分解的工作完成之后，需要对主题或者实体之间的关系进行建模，从而理解相关的业务规则。

    例如，针对北大西洋公约组织(北约)主题域中的组织机构进行主题设计，如图9-20所示。

图9-20  组织机构主题域

    7．数据仓库逻辑模型设计

    针对会议主题域的逻辑模型设计如图9-21所示。

图9-21  会议主题域的逻辑模型设计

    模型描述如下：

    1）军事委员会：北约军事、政治的决策机构，同时向北约秘书长、北大西洋理事会、防务计划委员会等提供建议，是北约的最高军事机构。

    2）国际军事参谋部：是北约军事委员会的执行机构，负责制订军事计划、提出有关军事政策的建议，负责执行北约军事委员会的各种决定。

    3）战区司令部：北约军事委员会下辖的战区司令部。

    4）负责北约防务：由北约军事委员会负责领导北约防务的问题。

    5）实施军委会的政策和计划：由国际军事参谋部负责实施军委会的政策和计划。

    6）各战区编码：包括目前北约所有的战区名称及其战区编码。

    逻辑模型中的实体可以分成两个部分：普通实体和从其他主题中引用的实体。在图9-21中，军事委员会是从其他主题中引进的，所以可以将它标成黄色以示区分。

    其他的实体，例如国际军事参谋部、战区司令部等都是模型中普通的实体，以绿色表示，实体和实体之间的关系也可以分成普通的对应关系和汇总关系。             

    8．数据仓库逻辑模型建设方案

    数据仓库逻辑模型建设方案如图9-22所示。

    （1）通过轻度汇总或者高度汇总的方式架构数据仓库逻辑模型

    通过轻度汇总或者高度汇总的方式架构逻辑模型，针对整个数据仓库项目，标准化地管理层次编码，根据不同的类型编码（例如地区编码、人员类型编码）多角度地实现数据的汇总和标准化，明确各项汇总数据在数据仓库中的粒度。虽然这种建模方式相对容易实现，但是存在一定的缺陷，就是对各种特殊的、灵活多变的查询所需求的支持性较差，只适合一般相对稳定的查询需求。

    （2）通过提供相对细节的数据架构数据仓库逻辑模型

    针对特殊的、灵活的查询需求，可以提供粒度级别相对较细节的数据作为数据仓库逻辑建模的基础，这样可以满足更长远的需求。但是这种建模方式相对难度较大，开发周期较长，需要技术开发人员与设计人员理解的业务规则更多。

    总结：在设计数据仓库逻辑建模方案的时候，通常采用两种方式相结合的方法。针对灵活多变的查询分析需求，尽量将数据的粒度级别更细节化；对于相对稳定的查询需求，更倾向于通过对数据的轻度汇总或者高度汇总去架构数据仓库逻辑模型。

图9-22  数据仓库逻辑模型建设方案

    9．数据仓库逻辑模型实例

    图9-23所示的数据仓库逻辑模型包含客户信息实体、潜在客户信息实体、信用卡客户评价类型实体、对信用卡客户的评价实体、信用卡客户基本信息实体、信用卡客户基本信息汇总实体。其中信用卡客户基本信息实体包含了客户编码、客户名称、立户时间、个人信息更改时间、销户时间、办卡数量等属性。立户时间、销户时间和个人信息更改时间保证了该实体的历史信息分析，办卡数量是该实体需要分析的指标项。信用卡客户评价类型实体存储了信用卡客户所有的评价类型编码和名称。该模型满足第三范式，信用卡客户基本信息汇总实体是根据信用卡客户基本信息实体里面的立户时间、销户时间，按照年月进行汇总，计算出客户的数量。同时信用卡客户基本信息实体继承了客户信息的基本属性。

图9-23  数据仓库逻辑模型

    模型描述见表9-8～表9-13。

表9-8  客户信息

表9-9  潜在客户信息

表9-10  信用卡客户评价类型

表9-11  对信用卡客户的评价

表9-12  信用卡客户基本信息汇总

表9-13  信用卡客户基本信息

     9.4.3  数据集市逻辑模型

    1．数据集市逻辑模型的设计

    数据集市是针对特定的某个主题域，或者按照部门进行划分的数据集合。这些数据是经过ETL工具的抽取、转换、加载及其一系列的汇总计算转化而成的，是在数据仓库的基础上建立起来的。数据集市在整体结构上，应该符合立方体的规则和即席查询的要求。通过ETL工具为数据仓库生成满足条件的立方体数据，立方体则是多维报表查询和商业智能展现分析的数据提供者。

    数据集市逻辑模型设计的主要工作（见图9-24）包括以下方面。

图9-24  数据集市逻辑模型设计的主要工作