企业级统一数据模型研究与设计

江樱 王志强 戴波 刘鸿宁

【摘要】 本文从国网浙江省电力公司信息化建设现状出发，分析了公司数据资源现状，提出通过统一数据模型整合数据资源，实现跨业务数据有效贯通和共享融合，并对电力企业统一数据模型的设计思路、体系结构和设计方法进行了详细阐述。

【关键字】 数据模型 数据共享 融合 集成

一、引言

经过SG-186、SG-ERP等信息化工程的建设，国网浙江省电力公司业务信息化日趋完善，形成了ERP、PMS、营销、协同办公等业务大集中的信息化管理系统，企业整体信息化水平获得极大的提高。然而随着企业信息化建设的深入，原有的信息化建设模式已逐渐显现出一些不足之处。

由于缺乏企业级数据和应用功能的全局整体规划和统筹，传统“烟囱式”的信息化建设未能完全遵循数据模型标准，仅按照业务需求设计、创建较为独立的数据存储模型，导致同一业务主题数据标准不一致、数据重复存储，数据共享度低。

如何通过企业级统一数据模型有效存储、融合、共享海量的数据资源，是数据中心建设、运行顺畅的关键要素之一，也是消除系统间信息壁垒，共享数据资源，促进公司管理水平提升的必备基础。

二、模型设计原则

充分理解大型企业统一数据模型的需求和背景，为保证模型的稳定性和对业务支持的灵活性，在模型设计时主要遵循以下原则：

继承性原则： 模型设计以国家电网公司SG-CIM 2014年基准版为参考，对IEC继承、扩展和重新组织的方式而成，并依据浙江公司实际业务需求对模型作个性化扩展或调整；

完整性原则：模型设计遵循企业信息化建设成果，能跨应用、跨业务完整的表述公司全业务范围数据视图，并能全面支撑公司大数据分析与辅助决策；

一致性原则：模型设计来源于对业务的分析，需要指导数据持久化的实现，应保持业务需求、数据模型和物理实现的一致，减少数据的二义性；

前瞻性原则：为适应公司业务现状及发展需要，模型适当超前，保证模型设计的前瞻性，能够适用公司业务的发展变化；

适用性原则：为保证模型的适用性，将模型与规则分离，突出模型的业务描述，提出规则点，对规则本身不做详尽限制。

三、模型体系结构

概念模型

概念模型是种高层次、高度抽象的数据模型，基于对企业业务的分析，抽象出主要业务领域及相互关系。为了使模型更易于设计、理解与查看，概念模型使用主题域来表达业务范围及其关系，直接面向公司各业务领域，与职能部门的业务分工无关。各主题域可按照业务具体进一步划分，形成二级主题域，每个二级主题域下包含多个业务对象类。在概念模型层面，对业务对象进行高度抽象，列出主要业务类清单。

逻辑模型

逻辑模型是对概念模型的进一步分解和细化，需要明确概念模型中业务对象类及属性，需要准确清晰描述业务对象及属性的业务含义，需要通过继承、聚合、关联等方式反映业务对象类之间的关系，并描述这些关系的业务含义。

物理模型

物理模型是在逻辑模型的基础上，结合具体数据库系统特性，考虑信息系统对数据存储的基本要求，把逻辑模型转化为物理模型，在系统层面落地形成可实际使用的数据模型。

四、模型设计方法

基于企业级统一数据模型的设计原则和体系结构，通过制定统一模型设计技术规范，明确数据建模工具，统一数据建模模板，摸索出一套行之有效的基于大数据平台的企业级统一数据模型设计方法，包括概念模型、逻辑模型的以及物理模型的设计。

4.1概念模型设计方法

概念模型设计主要包括一级主题域、二级主题域、类的设计，从业务角度清晰阐述一级主题域、二级主题域、类的业务含义，从业务角度准确反映一级主题域间、二级主题域间的内在联系。

一级主题域的设计：按照电网企业的业务组织形式，对国际标准IEC61968/IEC61970公共信息模型（CIM）的基本类进行重新组织，以类似“元素周期表”的形式进行表示，划分为13个一级主题域，包括：客户、产品、市场、设备、电网、安全、财务、资产、人员、物资、项目、综合和金融。并根据一级主题域之间的业务关系形成一级主题域关系视图。

二级主题域的设计：按照公司具体业务对一级主题域进一步划分，形成二级主题域（元素）。如在项目主题域下设置项目组成、项目成本、项目进度、项目质量等二级主题域，在物资主题域下设置物料、供应商、采购、库存、配送等二级主题域，最终形成SG-CIM基本元素的一个集合。并根据二级主题域之间的业务关系形成二级主题域关系视图。

类的设计：对业务应用对象进行归纳、抽象，然后针对业务本质进行准确、全面的分析，最后在此基础上进行正确、合理的抽象。类的设计应尽量简单明了，避免引入过多的元素，对象能作属性对待时，应尽量作为属性处理，而不抽象成实体。结合业务需求，对“元素周期表”中各二级主题域（元素）所包含的基本类进行直接引用、继承及弱相关扩展，如在供应商二级主题域下设置供应商主数据、供应商违约、供应商不良行为、供应商绩效评价等类，最终形成符合电网企业业务需求的类清单。

4.2逻辑模型设计方法

逻辑模型设计主要包括对类卡片、类属性及类关系的设计，从业务角度清晰定义类的业务含义、属性及类间关系。

类卡片的设计：每个业务类设计一张类卡片，卡片内容包括类名称、类代码、类注释，其中类注释使用专业术语准确描述类的业务定义、业务用途、数据范围。类设计时，表达同一业务管理对象的类，应进行抽象合并；统计、分析、汇总及报表业务对象，不在数模设计中体现；配置、对象状态、数据加工过程及程序实现，所涉及的实体不在逻辑模型中设计体现。

类属性的设计：类属性表包括属性名、属性代码、属性的业务含义、数据类型、数据来源系统和责任部门。其中“数据类型”主要描述为：字符型、数值型、日期型；“数据来源系统”用来描述属性数据是由那个信息系统生成的；“责任部门”用来描述属性数据具体负责的部门。

类关系的设计：描述完整的业务含义，描述与其它业务类的引用关系。体现与其它业务类的数据消费关系，即B使用A的数据开展业务，则B类关系视图中需要体现A的主要业务类。

4.3物理模型设计方法

物理模型设计是逻辑模型在系统应用层的具体实现，以系统程序设计的视角，结合底层数据技术架构，基于关系型数据库，对逻辑模型实用化。物理模型在逻辑上被划分为4层，包括ODS（缓冲区）、ODS（统一视图区）、EDW（数据仓库层）及DM（数据集市层），逻辑架构如下图所示。

ODS（缓冲区），用于全量、持久存储来自各业务系统的原始业务明细数据，该层的数据结构与业务系统的基本一致，同时考虑数据增量与数据版本；

ODS（统一视图区），用于存储经过编码统一、数据同源、数据规范化后的企业级业务明细数据；

EDW（数据仓库层），用于存储支撑企业级分析应用的业务明细数据与轻量汇总数据，该层业务明细数据是由ODS（统一视图区）的数据通过业务整合形成，轻量汇总数据是根据业务逐步提炼形成；

DM（数据集市层），用于存储面向具体应用的加工及汇总数据，该层数据是根据具体业务逻辑进行复杂数据加工形成。

物理模型设计主要包括对ODS（缓冲区）、ODS（统一视图区）、EDW（数据仓库层）及DM（数据集市层）的数据库表设计。

所有数据库表设计时都要能够反应数据变更的历史记录，包括变更时间、变更前后的内容等信息；同时，也要能支撑以增量方式抽取数据。

ODS（缓冲区）的数据库表设计：基于源系统表，开展此层物理模型设计，该层的数据结构与业务系统的基本一致，同时考虑数据增量与数据版本，全量、持久存储来自各业务系统的原始业务明细数据。

ODS（统一视图区）的数据库表设计：基于逻辑模型OOM及源系统表，梳理设计实体的物理表结构；设计物理表结构要考虑数据同源、编码规范；要体现数据变更记录，即在表中增加源系统数据更新时间、源系统数据是否删除、模型数据更新时间字段；要体现逻辑模型中的关系，如果该关系在类中没有体现，则考虑在物理模型中将该关系建表；设计逻辑模型与物理模型的对应关系表和编码映射表；存储经过编码统一、数据同源、数据规范化后的企业级业务明细数据。

EDW（数据仓库层）的数据库表设计：基于逻辑模型OOM及统一视图层物理模型，根据业务对象进行表的合并，通过纵向合并、横向合并、业务合并，设计实体的物理表结构。纵向合并，同一个根节点引出的类可以进行合并，一般基类不考虑建表，子类建表，且将基类的属性放至子类中；横向合并，当同一个父类下多个子类的属性重合度较高时，将多个子类进行合并建表；业务合并，从业务应用出发根据业务应用需求将多个表进行合并。存储支撑企业级分析应用的业务明细数据与轻量汇总数据，该层业务明细数据是由ODS（统一视图区） 的数据通过业务整合形成；轻量汇总数据是根据业务逐步提炼形成。

DM（数据集市层）的数据库表设计：基于业务应用需求及数据仓库层物理模型，根据具体业务逻辑进行复杂数据加工，设计面向具体应用的数据库表，存储面向具体应用的加工及汇总数据。

五、结束语

企业级统一数据模型对于整合数据资源、深化数据治理、提升数据价值具有非常重要的意义，是体现公司信息化建设集约化和标准化的典型实例。国网浙江省电力公司根据自身业务特点并结合国网SG-CIM设计成果，设计一套涵盖公司各业务条线、唯一反应业务实体、含义清晰、体现业务流程、编码唯一的企业级统一数据模型，打破各专业横向共享壁垒和障碍，实现跨业务数据有效贯通、共享融合，有力支撑了公司大数据分析体系的建设，为公司的信息化建设积累了宝贵的经验。