多平台电力行业元数据管理UML建模与应用研究

付婷， 陈红， 方志坚， 陈智鹏， 王金发， 陈婷

(1. 国网福建省电力有限公司信息通信分公司， 福建， 福州 350001；2. 国网信通亿力科技有限责任公司， 福建， 福州 350001)

0 引言

目前电力企业在日常业务处理过程中会产生海量的数据，这些数据分散在各类信息化系统之中，比较孤立，难以关联起来挖掘潜在价值，如何集成多个异构数据源的数据进行统一规划管理是电力行业面临的难题。为了消除信息孤岛、有效管理，本文设计多平台电力行业元数据管理系统，按照主题划分数据域，构建统一标准的数据仓库，针对数据来源、影响范围、关联关系进行分析，为电力行业数据治理提供有效手段。

1 元数据解析

1.1 概念

元数据简单来说是描述数据的数据，指的是某类数据的数据结构、类型、约束等。比如书名、作业、出版社等就是一本书的元数据。它最主要的作用是对系统进行描述，如果缺少了元数据，那么已收集的数据就失去了价值。

1.2 分类

元数据没有明确要求如何分类，可以从多种维度进行划分，例如从记录形式可以分为结构化和非结构化，对于电力数据来说，可以根据用途分为业务元数据和技术元数据2类。

(1) 业务元数据：从业务角度去描述，提供一个语义层，描述业务信息、业务下是数据模型、数据属性、数据来源等。

(2) 技术元数据：主要记录建设和管理过程中需要使用的信息，包括视图、层次、维度、数据表、关联关系、转换规则等[1]。

1.3 管理方式与难点分析

包括建设、运行、维护在内的系统整体生命周期内一直都在产生元数据，根据存储方式的差异可以将元数据管理划分为分散式、集中式、联邦式几类。分散式是指存储在不同的局部数据库，通过接口进行数据提取，访问容易但交互较难。集中式是指从局部数据库采集之后统一存储，元数据与数据源独立，但数据同步频繁。联邦式是将以上2种方式结合，构建共享元数据库，局部存储可以异构，共享格式需统一。

在实际管理过程中，存在以下难点：

(1) 获取困难：由于数据源系统架构差异，很多平台具有闭源性，元数据采集方式各不相同且获取困难。

(2) 业务类元数据欠缺：技术类信息描述较多，业务类欠缺，不利于数据提取与数据挖掘。

(3) 模型变更频繁：随着企业业务变更，模型需要及时更新进行数据同步，管理过程有疏漏直接会影响数据质量。

2 关键技术及元数据建模

2.1 CWM标准

CWM(Common Warehouse Metamodel)是OMG采纳的开发式业界标准，可以实现不同的数据仓库、智能装置及元仓储库之间元数据共享与交换，提供了异构环境中数据交互、数据集成的标准模型，提供了元数据管理的语法，基于以下标准制定：

(1) UML：面向对象的标准图形化建模语言(Unified Modeling Language)，专注于产品模型与结构，跨平台的定义了CWM模型的语法语义。

(2) MOF：元对象工具(Meta Object Facility)是指构造、管理、集成元数据模型的框架，支持多种元数据，用于构建CWM模型并提供接口[2-3]。

(3) XML：元数据交换(XML Metadata Iterchange)标准可以将元数据转换为XML格式，提供了异构数据交换的规范。

2.2 UML建模语言

UML建模语言由语义、语法组成，语义提供简单统一的定义性的描述，语法描述符号含义，基本元素包括描述某个部分的事务、多个事务之间的关系以及由事务和关联关系构成的图。电力行业的数据来源于各个子平台，实现方式不一致，而且由于电力行业发展新系统投入力度也较大，对模型的扩展性有很高的要求，因此，本文采用UML建模语言来实现电力行业数据采集建模。

2.3 PowerDesigner建模工具

PowerDesigner是Sybase公司开发的建模工具，涵盖了模型开发与设计的各个环节，包括各种类图、包图、类、各个类之间的关系、各个类的属性等，提供了UML模型到关系数据库之间的映射，实现了模型到实际应用的数据库之间的转换。主要包括：

(1) 类：描述具有相同属性和行为的一类对象，包括多个属性和方法。

(2) 包：根据类的含义、用途，相关的划分到一组，即称为包。

(3) 关联：对象是独立的，但是属性有依赖关系，即为关联。

(4) 继承：继承其他对象的属性或行为，方便对类进行扩展。

(5) 组合/聚合：描述整体与部分的关系。

3 数据域划分与建模

电力系统按照时间顺序可以分为前期建设、运行管理、后期运维、后续演进等阶段，不同阶段会产生不同的元数据，同一阶段内按照用途区分也可以分为多种类别，本文设计的系统结合数据用途，将元数据划分为6个大的主题域之后再进行细分，具体如表1所示：

表1 数据域划分

结合电力数据特点，本文为6个主题域数据建模如下：

(1) 网络资源元数据

网络资源元数据包括逻辑资源和物理资源以及业务系统、资源规格等。其中：逻辑资源包括传输网、交换网等；物理资源包括光缆、管线、电缆等。本文以光缆为例，结合光缆的网状结构，设计光纤型号模型包括如下字段：唯一标识、名称、编码、使用评估、管束结构、管束数、芯数、纤芯型号、光缆结构、光缆外径、光缆类型、短路电流、抗拉强度、生产商、光纤内管束色谱等[4-5]。

(2) 网络行为元数据

网络行为元数据是系统运行过程中产生的告警数据、状态以及性能数据。本文以告警数据为例，设计告警元数据模型包括如下字段：告警id、告警设备id、告警对象、告警级别、告警类型、描述、告警时间、系统、确认状态、确认人、机框id、槽位id、板卡id、机房名称、电路名称等。

(3) 业务元数据

业务元数据包括系统信息、业务信息、业务类型以及承载通道、网元等。业务元数据模型需包括：唯一标识id、业务类型、名称、等级、保护装置类型、区域、投运时间、备注等。

(4) 运维元数据

运维元数据包括运维过程中产生的各类工单及相关管理数据，电力系统的运维管理包括通信调度、故障工单、检修、运行分析、资源维护等。本文以故障工单为例，设计模型包括：唯一标识id、工单状态、工单编号、故障内容、故障类型、来源、等级、生成时间、报备时间、报备人员、联系方式、是否影响业务、处理方法等。

(5) 网络规划元数据

网络规划元数据包括光缆、传输、交换网等的规划数据，设计模型包括：规划标识id、项目信息、版本、规划单位、提交时间、内容等。

(6) 供应商元数据

电力系统的各类资源通常由供应商提供，本文以供应设备为例，对相关信息建模如下：设备标识id、设备名称、类型、数量、生产厂家、供应商、出厂编号、出厂时间、投运时间、升级履历、备注等。

4 开发环境

本系统所需开发环境如下。

操作系统：Windows Server 2012 R2

开发语言：Java

中间件：Tomcat7.0.77

前端：Vue2.5.2

后端：Spring4.3.13

数据库：MySQL5.7

5 元数据管理系统核心功能设计

5.1 功能架构

基于目前电力行业元数据管理的现状，多平台元数据管理系统需要集成各个异构平台的数据，功能模块主要划分为采集、存储与分析，结构如图1所示。

(1) 采集层：集成多平台数据，异构数据转换为统一格式后存入元数据库。

(2) 应用层：对元数据的来源管理、入库审核、血缘分析、影响范围分析、关联性分析、查询、编辑、历史版本查询等。

(3) 展现层：用户操作界面，查询属性、分析结果等[6]。

5.2 技术架构

本系统设计时后端处理采用Spring框架，前端展示采用Vue技术，控制策略利用MVC模式，技术整体架构如图2所示。

图2 技术架构

5.3 元数据采集

元数据采集是整个元数据管理的基础，是一个从各类异构平台获取原始数据后进行格式规范化存入最终数据库的过程。由于多平台数据格式各不相同，需要进行数据适配，并且涉及目录挂靠、多次采集、数据更新、入库审核、记录日志等。具体流程如图3所示。

图3 元数据采集流程

5.4 元数据存储

元数据数据库是元数据管理的核心，电力系统数据仓库所有的数据都将存储在元数据数据库之中。元数据数据库与其他普通数据库不同的一点在于需要进行异构元数据交互，它的数据模型结构和语义必须具备统一标准，而且有规范的数据交互协议，各个厂商各个系统均可以进行数据转换，利于系统集成。本文基于CWM标准来设计元数据存储数据库，最终通过数据类型映射在MySQL数据库中实现，映射为实际数据库关系模型。

5.5 元数据分析

元数据分析主要分为影响分析、关联分析与血缘分析。

(1) 影响分析：分析数据影响范围，正向分析数据终点，帮助电力企业解决无法精准定位问题。

(2) 关联分析：分析信息重要性，实现评估，帮助电力企业重要数据优化。

(3) 血缘分析：分析数据来源，反向分析数据起点，帮助电力企业实现数据追溯。

5.6 元数据管理

元数据管理主要管理互相之间的关联关系以及元数据的基础信息，包括前端展示的元数据信息查询、关联关系维护、修改元数据属性、增删改查原始记录、历史版本管理等，发挥出收集存储的元数据的深层价值[7]。

6 总结

本文介绍了元数据的作用与管理难点，采用业界通用标准建立了电力行业网络资源、网络行为、业务、运维、规划、供应商6个数据域的元数据模型，深入研究元数据的采集、存储与数据分析维度，为电力元数据的统一管理提供了可行方案。但由于电力通信网的发展，本文设计的各类模型及系统功能模块都需要进行扩展与调整，因此，元数据模型的延展性提升是后续将持续研究的方向。