基于TMF SID的高可扩展性数据模型
前言
此文根据TMF SID规范撰写，欢迎大家提出建议和意见。
TMF文档版权信息
Copyright © TeleManagement Forum 2013. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to TM FORUM, except as needed for the purpose of developing any document or deliverable produced by a TM FORUM Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in the TM FORUM IPR Policy, must be followed) or as required to translate it into languages other than English.
作为网管系统，最大的挑战是如何满足通用需求的同时快速满足个性化需求，除了与组织架构、流程体系等紧密相关外，软件可扩展性、平台化水平和灵活性至关重要。有一句话很经典：“最好的架构师是能够在软件开发所涉及的诸多内部因素和外部因素寻求最佳的平衡”，一个高度平台化的系统，对高可扩展性是非常关注的。
可扩展性是指软件适应增长和变化的能力，可扩展越好，表示软件适应“变化”的能力越强。对于一般系统来说，主要面临3个方面的增长：
1、 不断增长的数据管理需求，包括数据量和数据种类的增加；
2、 不断增长的终端用户需求，包括用户访问量的增加；
3、 不断增长的功能类型需求。
系统的可扩展性更多的体现在系统架构设计方面，包括但不限于以下几个方面：
- 需求分层：按照需求的通用性分层，比如公共平台层、产品平台层、省级扩展层等；
- 数据模型的可扩展性：支持数据建模，通过元数据实现数据结构的扩展，不依赖于硬编码，动态生成用户界面；
- 业务流程的可扩展性：支持流程建模，通过活动节点和控制逻辑的自定义，实现流程自动化；
- 模块化或组件化：添加、删除、增强、重构某些组件，对于其他组件的影响微乎其微；
- 高性能：包括高吞吐量、高并发和低延迟，通过很少的软件改动甚至只是硬件设备的添置，实现系统处理能力的线性增长。
实现系统可扩展性的软件技术包括：
- 自动代码生成：例如Eclipse和VisualStudio等IDE工具（集成开发环境）；
- 动态编译：动态装载和执行代码，例如Java和.NET都提供了动态编译的手段；
- 元数据：元数据允许程序语言自动以非特定语言的方式对其自身进行描述；
- XML语言：包括Xlink、Xpointer、XSL和XML Schema等；
- 插件技术：为系统添加功能或者提供系统某些性能时，只需要添加一些文件即可，不需要在程序中修改和添加代码；
- 反射技术：允许系统在运行时装载和执行插件，无需在组件之间进行源代码编译。
本文主要谈的是数据模型的高可扩展性，而不是系统的高可扩展性，当然数据模型的高可扩展性可以带来系统的高可扩展性。一般来说，与其它手段相比（如中间件设计），良好数据模型设计能够以较低的成本实现系统的高可扩展性。
数据模型的可扩展性主要考虑以下3个因素：
1、 是否满足现有的业务需求；
2、 是否易于应对未来可能的数据需求变化并保持数据模型的稳定性；
3、 是否易于应对未来可能的业务需求变更并保持数据模型的灵活性；
4、 是否高效。对开发人员来是否简单，对系统运行来说是否高效。
至少在NFV/SDN这种颠覆性的技术到来之前，以无线专业2G、3G、LTE为例，尽管其通信技术发生了变化，但网管系统的资源数据模型并不需要发生大的变化。例如，将LTE资源纳入管理后，网管系统不需要修改其数据库结构，而是能够通过简单的配置（甚至不需要增加或修改软件代码）实现对eNodeB和eUtranCell等LTE资源数据的管理。
以TD无线专业的资源业务模型为例，如果完全按照下图1红色虚线框中的模型设计网管系统的RNC节点、NodeB节点、RNC逻辑设备、NodeB逻辑设备等资源数据模型及其数据库E-R图，那么当数据管理范围扩大至LTE资源时，不得不按同样的方式为eNodeB节点、eNodeB逻辑设备、eUtranCell等资源实体建立相应的系统数据库表，系统业务逻辑层和数据访问层的代码也相应要增加或者修改。
上述TD无线专业资源模型与TMF官方社区中的一个问题很类似，TMFSID组主席John Reilly对其作出了回答。
有人提出这样一个问题：
如何使用SID为BTS、BSC、MSC、HLR建模？是否可以通过继承的方式从SID创建出BTS、BSC、MSC、HLR实体？
John Reilly的回答：
有2种方式可以实现BTS、BSC、MSC、HLR的建模：
第一种，使用“复合资源规格”和“资源特征规格”实体，并通过其实例间接地实现BTS、BSC、MSC、HLR等资源的建模，而不是显式地创建“复合资源”实体的子类，如BTS实体、BSC实体、MSC实体、HLR实体。例如，可以为每类设备创建对应的“复合资源规格”实例，并为每个设备的属性创建对应的“资源特征规格”实例。
第二种，显式地创建“复合资源”实体的子类，如BTS实体、BSC实体、MSC实体、HLR实体。
具体内容请浏览：
http://www.tmforum.org/community/communities/information_framework_sid/f/6/t/171339.aspx
从上面的讨论内容可以看出，JohnReilly在解决这类问题时推荐使用SID中的“复合资源规格”和“资源特征规格”实体，不需要为SID扩展出BTS、BSC、MSC、HLR等新的实体。这种处理方式的原因是：
对于SID的扩展，JohnReilly表示也可以使用其它现有的标准，如3GPP NRM模型。
1. 设计模式的基本概念
上面讲到的“复合资源规格”和“资源特征规格”实体分别属于SID设计模式中的规格模式（Specification Pattern）和特征模式（Characteristic Pattern），规格模式和特征模式这2种设计模式被广泛应用于整个SID建模中。那么，什么是设计模式（Design Pattern）呢？TMF 给出的定义如下：
”Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”
每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。
设计模式的目的是为了提高模型的质量，特别是在内聚和耦合方面。TMF SID采用了多种设计模式，例如：
- 抽象模式
- 规格模式
- 特征模式
- 角色模式
- 合成模式
- 状态模式
- 类组模式
- 管理信息/方法模式
其中规格模式（SpecificationPattern）和特征模式（Characteristic Pattern）贯穿于整个SID模型中。
SID对规格模式（SpecificationPattern）的定义如下：
规格模式应用在需要描述一件物品或服务并且独立于任何这类物品或服务当前存在的实例。
规格模式使用规格实体（EntitySpecification）表示，规格实体不代表单个概念或事物的实例，而是一类概念或事物的信息。规格模式将实体不变的、相对固定的属性和行为与其可变的属性、行为分开定义。通过规格实体的定义，将通用的规则、属性分离出来单独定义，形成实体的“模板”。这可以让每个实体定义它们自己不同的属性，作为规格实体中定义的共同属性的补充。
SID对特征模式（CharacteristicPattern）的定义如下：
特征模式将实体和实体所具有的属性分离开，用单独的实体来描述属性。
规格模式和特征模式的优势在于：
图2给出了SID中规格模式和特征模式的典型结构。规格模式和特征模式的核心思想就是借助EntitySpecification创建出属于某一类实体的公共属性，借助RootEntityType创建出特定于某个实体的专有属性。其中，RootEntityType是SID建模过程中用到的一个实体，泛指“客户”、“产品”、“服务”等业务实体。
从上面的模型图可以看出：
- 规格实体（EntitySpecification）的实例定义了某一类实体；
- 特征规格实体（CharacteristicSpecification）定义了一类实体或多类实体的属性；
- 特征规格值实体（CharacteristicSpecValue）定义了各个特征规格实体可能的取值；
- 可以为规格实体（ProductSpecification）定义属性，也可以为产品实体（Product）、客户实体（Customer）定义属性。
那么，如何应用SID的“规格模式”和“特征模式”呢？
2. 规格模式和特征模式的介绍
下面以电商网站最常见的产品展示网页为例，结合图2规格模式和特征模式的典型结构，介绍规格模式和特征模式的应用。这个页面展现了一个名称为“LinksysUSB Ethernet Cable Modem DOCSIS”调制解调器。
上图中的“Linksys USBEthernet Cable Modem DOCSIS”是产品规格（ProductSpecification）的一个实例，产品规格（ProductSpecification）在图2中表示为EntitySpecification。上图中每个Tab页（FEATURES功能、DESCRIPTION描述、ADDITIONAL INFO额外信息、SHIPPING INFO物流信息）分别构成了一个特征规格（CharacteristicSpecification）的实例，其中“功能”特征规格（CharacteristicSpecification）是一个集合，它由每一行功能点的特征规格（CharacteristicSpecification）实例组成。CharacteristicSpecRelationship实例用于组合每一行功能点的实例成为一项“功能”。EntitySpecCharUse实例有一个可以设置为true的canBeOverriden属性，表示这个特征不能拥有取值。
这个例子没有使用图2中的CharacteristicSpecValue实体和CharSpecValueRelationship实体，但这两个实体可以用来表示调制解调器的一组颜色，譬如将调制解调器的面板颜色（CharacteristicSpec）选择为蓝色（CharacteristicSpecValue），那么其背部颜色只能为黑色。以上规则可以通过一个CharSpecValueRelationship 实例实现，这个CharSpecValueRelationship实例关联蓝色和黑色，并将其charValueRelationshipType属性取值为“inclusive”，表示蓝色和黑色配合使用。CharacteristicSpecRelationship实体的charSpecSeq属性用来为组成CharacteristicSpecification的属性集合进行排序。例如，手机号码MSISDN按照顺序由CC（国家码）、NDC（7位国内目的码）和SN（4位用户号码）构成，charSpecSeq属性用来指定这个顺序。
minCardinality和maxCardinality属性用来指定与实例关联的取值数量，在这个例子中，调制解调器面板颜色的minCardinality和maxCardinality属性取值均为1，表示调制解调器面板颜色有且仅有1个颜色值。minCardinality为0表示其属性可以没有取值。
CharacteristicSpecifications和CharacteristicSpecValue实体都有一个valueType属性，因为CharacteristicSpecifications所关联的CharacteristicSpecValue取值可以是多种数值类型的组合，如字符串和整数的组合。当CharacteristicSpecValue所有实例的取值类型一致，则只需要设置CharacteristicSpecification的valueType属性。
一个CharacteristicSpecValues实例可以表示具体的值或者取值范围，例如，调制解调器的颜色值可以是具体的值，调制解调器的工作温度可以是一个取值范围。CharacteristicSpecValue的rangeInterval属性定义了valueFrom和valueTo自身的属性值是否是包含在内的，这相当于为valueFrom属性和valueTo属性增加了一个操作符，如“<=”或者“<”。
在一些模型中，属性的具体取值和取值范围分别用CharacteristicSpecValue实体的不同子类表示，为了简化建模，这里统一使用CharacteristicSpecValue表示这2种情况。此外，一些模型将取值的度量单位作为单独的实体，并用关系实体定义不同度量单位之间的换算关系。同样，这里没有考虑以上做法，当然这都可以作为SID的扩展进行建模。
有时对于一个实体的所有实例而言，有一些CharacteristicSpecifications总是设置为一个或一组固定的常量。例如，调制解调器的工作温度是一个固定的温度范围，此时canBeOverriden属性可以用于表示取值是否为常量。此外，可以采用为EntityCharacteristics赋值的方式扩展CharacteristicSpecValues。譬如，对于userIDs属性，除了具有CharacteristicSpecValues实例的取值外，还有一些CharacteristicValues实例的取值。CharacteristicSpecifications实体的extensible属性用来表示通过创建CharacteristicValues实例，从而增加一些新的CharacteristicSpeValues实例。
CharacteristicSpecifications可以被多个EntitySpecification和RootEntityType实例共用，EntitySpecCharUse定义了EntitySpecification实例如何使用CharacteristicSpecifications，RootEntityTypeCharUse定义了RootEntityType实例如何使用CharacteristicSpecifications。例如，CharacteristicSpecifications实例的name属性取值为“带宽”，在EntitySpecCharUse实例中这个“带宽”属性被重新命名为“下行带宽”，而在RootEntityTypeCharUse 实例中这个“带宽”属性被重新命名为“上行带宽”。由此可见，通过对EntitySpecCharUse和RootEntityTypeCharUse属性的重新赋值能够覆盖CharacteristicSpecification实例中的属性取值。再比如，CharacteristicSpecification实例的minCardinality属性取值为0，意味着CharacteristicSpecification指代的属性可以不用赋值，但是在其它情况下，CharacteristicSpecification指代的属性必须赋值，如此一来，minCardinality属性取值为1。
RootEntityTypeCharUse和EntitySpecCharUse的package属性用于表示属性组合，与没有显式继承的组合模式类似。当这个属性的取值为true的时候，minCardinality、maxCardinality、unique、canBeOverriden和extensible属性都不需要赋值。
EntitySpecification或者RootEntityType使用的CharacteristicSpecification取值可能需要进一步定义，这可以用CharacteristicSpecValue与RootEntityTypeCharUse和EntitySpecCharUse之间的关系实体实现。例如，名称为color的CharacteristicSpecification实例，其使用的CharacteristicSpecValue实例可能包含了所有颜色种类，但对于调制解调器来说，仅仅需要其中的部分颜色种类，这可以通过RootEntityTypeCharValueUse和EntitySpecCharValueUse为CharacteristicSpecification重新定义不同的默认值。
上面介绍了规格模式和特征模式的应用，那么如何实例化使用了这两种模式的实体呢？
应用了这两种模式的实体实例化主要由CharacteristicValue完成。下图3定义了CharacteristicValue和实体之间的关系，一个CharacteristicValue是某个实体实例的一个CharacteristicSpecification属性取值。在上面调制解调器的例子中，CharacteristicValue可以为blue（调制解调器面板颜色）和black（调制解调器背部颜色）。CharacteristicValue也可以与相关的CharacteristicSpecValue关联。
CharacteristicValue与CharacteristicSpecification关联，并且CharacteristicValue的value属性需要赋值的情况有以下2种：
2、 当一个属性的取值是从CharacteristicSpecValue定义的取值范围中选择而来，CharacteristicValue的value属性需要赋值为这个被选择的值。
当CharacteristicSpecValue的取值为一个具体的值或者是不可变更的值（即canBeOverrided属性设置为true），CharacteristicValue只需要与CharacteristicSpecValue实例进行关联，而不需要与CharacteristicSpecification实例关联。
3. 设计模式的应用举例
下图4为应用了规格模式和特征模式的部分资源实体的示例。
对图4中的资源实体说明如下：
按照TMF eTOM业务流程框架，资源规格（ResourceSpecification）、资源特征规格（ResourceCharacteristicSpecification）、资源特征规格值（ResourceCharacteristicSpecValue）的实例是在战略、基础设施和产品（Strategy, Infrastructure&Product）中的产品生命周期管理（ProductLifecycle Management）阶段产生的，具有静态的特点，与之相关的流程元素包括：
- 开发资源业务需求
- 开发资源规格
资源（Resource）、特征值（CharacteristicValue）的实例是在运维（Operations）中的业务开通（Fulfillment）阶段产生的，具有动态的特点，与之相关的流程元素包括：
- 分配和安装资源
- 配置和激活资源
如下图5所示。
基于规格模式和特征模式可以实现数据模型的高可扩展性，从而能够提高网管系统的高可扩展性，其带来的益处包括：
1、 极大降低后期的维护和升级成本；
2、 加快系统上线时间；
3、 提高系统产品化程度；
4、 提升系统平台化程度；
基于规格模式和特征模式的数据模型虽然其扩展能力优越、数据视角统一，但它也存在以下几个问题：
1、 这种设计会丢失一些业务含义，因此需要借助良好的元数据、码表解释完善数据的业务含义；
2、 缺乏满足业务规则的数据库约束信息，这需要借助元数据和业务逻辑代码实现；
3、 由于大部分数据集中在特征值（CharacteristicValue）实体中，物理化模型时会采用窄竖表和数据对象标识的方式实现对象和属性的抽象，这会导致系统性能问题：一方面，大量数据集中在少数的几张表中；另外一方面，上层应用可能需要大量的多表关联，竖转横操作。这两个问题可以通过数据库分库、分表、分区的方式，以及建立统一的数据访问接口视图（屏蔽底层具体实现）的方式解决。
附录：SID介绍。
SID（SharedInformation/Data Model，共享信息和数据模型）是TMF（Telecom Management Forum，电信管理论坛）倡导的Frameworx系列规范中的信息框架——Information Framework，其目的是为了满足信息通信服务行业对共享数据定义和模型共享的需求。SID定义了信息参考模型及标准描述语言，旨在通过创建一系列标准的、公共的术语提供一个参考模型框架。简言之，SID构建了TMF Frameworx框架中的信息模型。
SID不仅能够满足OSS系统的信息数据需求，同时还保持和eTOM（enhanced Telecom Operation Map，增强电信运营图）提出的业务流程及通用过程词汇表的一致性，其覆盖了所有eTOM业务流程所需要的信息，这意味着SID覆盖了一个电信运营商运营所需的大多数信息，为信息通信企业提供了一种有效组织其业务过程的方法，同时也方便了相互间的交流。SID模型从业务实体角度提供了信息数据参考模型和通用信息数据词汇表。具体而言，SID定义了eTOM业务流程相互作用的对象，SID模型和eTOM相结合则解释了这些“对象”如何相互作用，从而满足特定业务需求。
