图3 华为传输设备的管理信息树（MIB树）
按照管理对象类（MOC）的管理信息树（MIB树）定义，相应的被管对象实例（MOI）对象之间也会存在包含关系，并组合形成一棵更大的被管对象实例（MOI）包含树。被管对象实例（MOI）的名称即是按照该包含树的结构描述的，这种描述与它在实际设备中的所表现出来的层次相一致。例如：
/System=sampleSystem1/Subnetwork=sampleSubnetwork3/NE=sampleNE3
即表示一个网元，它是属于系统（System）为“sampleSystem1”，位于子网（Subnetwork）“sampleSubnetwork3”中，网元（NE）标识为“SampleNE3”。
虽然本数据管理方案借鉴了SNMP和CMIP的建模思想，却根据综合网管系统的实际情况，并结合SNMP和CMIP在使用中遇到的问题，对其信息模型增加或者简化了部分内容，形成了一个特有的解决方案。该解决方案与SNMP、CMIP信息模型的比较如表1所示。
表1 信息模型比较
如表1所示，本数据管理方案结合了SNMP和CMIP模型的优点，采用了相对简单的面向对象建模方式，避免了SNMP数据抽象度不够导致MIB混乱无法实现通用管理、而CMIP又过于复杂难于实现的缺点，比较适合综合网管系统的使用。
3.2关系建模过程
对于综合网管系统，对象间的关系管理则是更重要的内容。在综合网管系统中，存在“承载关系”、“拓扑关系”、“包含关系”等多种数据关系，对这些关系如何定义、抽象和管理，一直是网络管理信息模型没有涉及的部分。在本数据管理方案中，我们将这些“善变的关系”也进行了对象建模，并作为管理的重点内容。
被管对象间的复杂关系，我们通过定义各种“关系类”来抽象，用具体的“关系实例”来确定；某种被管对象（实例）与其他被管对象（实例）具有哪种关系，可以通过设置这种被管对象（实例）进入和退出某种关系类，来实现关系的管理。用户可通过设置这些关系，实现从不同的视角来观察对象。
资源对象间的关系，可以通过类和实例两个层面来定义：
第一层面，关系类（RelationshipClass，可缩写为RC），用于描述具体被管对象类（MOC）间的关系。例如描述“交换网元”类与“中继”类之间存在“交换网元-中继的拓扑关系”，还可以描述“传输网元”与“段”之间存在“传输网元-段的拓扑关系”。
关系类之间也会存在继承关系，如“交换网元-中继的拓扑关系”和“传输网元-段的拓扑关系”，我们可以将其进一步抽象成为“拓扑关系”。对“拓扑关系”，我们可以描述为：三元关系、参与对象为一个线对象和两个端点对象、线对象的两端为两个端点对象；对于“交换网元-中继的拓扑关系”，则除了以上定义之外，还需增加描述：线对象为中继（实例）、点对象为交换网元（实例）。
通过关系类（RC）之间的继承，使对象间关系在不同层次上都有相应的类对其进行描述，满足了系统在不同场合对关系进行分析的需要。例如：“拓扑关系”类，就可以在绘制全网拓扑图时使用；而在绘制交换网络拓扑图时，则会使用到“交换网元-中继的拓扑关系”类。
第二层面，关系实例（RelationshipInstance，可缩写为RI），用于确定具体被管对象实例（MOI）之间的关系，是关系类（RC）的实例化。例如沈阳市名为NE666交换网元与NE888交换网元之间存在直达中继I666-888，则这3个实体之间构成一个“交换网元-中继的拓扑关系”，是一条拓扑关系的实例。
通过类与实例两个层面的描述，从抽象到具体，逐步将对象间关系描述清楚，这就是我们所建立的关系模型；该模型实现了资源对象与对象间关系的分离管理，将对象间的耦合度降到了最低，也有利于关系的维护和管理。
在具体系统实现时，我们可以将MO与RO分别建表存储，从物理上实现对象与关系的分离管理，仅依靠表之间的外键实现关联。
下面，我们以一种状态计算引擎为例，说明这种方案在业务影响分析中的应用。该状态计算引擎描述如下：
（1）对每一个需要监控的被管对象实例（MOI）建立一个状态对象（StateElement，可缩写为SE），用来记录当前被管对象实例（MOI）的状态。
（2）状态对象（SE）之间存在一种特殊的关系：源-目的（source-target）关系，这种关系被用来进行状态传播。一旦源（source）对象的状态取值发生变化时，目的（target）对象的状态就会被重新计算。如果该目的（target）对象是另一个状态对象（SE）的源（Source），那么这种传播过程将会继续下去，直至不存在源-目的（Source-target）关系。
（3）状态的计算是通过状态对象（SE）内部一个特定的状态计算公式进行的，该公式可与被管对象实例（MOI）所属的被管对象类（MOC）相关。当状态对象（SE）接收到一个告警事件或者与其相关的源（source）对象状态发生变化时，该公式才会被触发。此时，状态对象（SE）的状态取值会根据计算出的结果进行修改，并有可能触发上送一个新的告警事件。
（4）告警上送和状态传播的具体过程如图4所示。
图4 告警上送和状态传播
根据我们对于被管对象类（MOC）与被管对象实例（MOI）的定义，我们可以抽象出以下几类状态对象（SE）：客户（customer）、业务（servicePackage）、通路（trail）、通道终结点（sncendpoint）、永久虚电路（pvc），并在他们之间建立源-目的（source-target）关系。
如图5所示，当通道终结点（sncendpoint）实体有告警产生时，状态就会按照箭头所示进行传播，最后影响到特定的业务、特定的客户。根据这种原则，我们可以建立更加复杂的传播关系，处理更加复杂的业务分析问题。
图5 状态传播示例
4、该方案的优点
从系统建设来说，使用该数据管理方案恰好满足了综合网管系统中数据量大、种类多、信息模型差异大的特点，大大增强了系统的扩展性和对不同设备接入的包容性，同时也有利于与资源系统的数据交换。
（1）以新设备接入为例，无论该设备网管采用何种网络协议进行管理，我们均可将其纳入本数据模型中，而不仅限于支持SNMP的设备。当系统需要接入一种新设备时，用户只需重新定义一套被管对象类（MOC）、一棵该设备相关的MIB树和若干关系类，即可以在不影响系统框架，不影响原有功能，且不修改系统代码的情况下，接入该新设备；系统需要新开发的内容只仅仅限定在接入模块部分，即插即用成为可能。
