前言
此文根據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相結合則解釋了這些“對象”如何相互作用，從而滿足特定業務需求。