基于對象型層次型數據庫的 IFC 數據存儲研究

曾 強 張其林， 張金輝

(1.同濟大學 土木工程學院，上海 200092； 2.上海同磊土木工程技術有限公司，上海 200092； 3.上海土木工程結構健康監測工程技術研究中心，上海 200092)

引言

為了解決建筑工程項目的各個參與方間信息交換的困難，國際交互操作性聯盟IAI(International Alliance for Interoperability)制定了一種用于描述、交換和共享建筑信息的國際化規范工業基礎類IFC(Industry Foundation Classes)，并且IFC4的版本已經成為ISO國際標準(ISO 16739)[1]。當前BIM技術主要通過IFC標準進行數據交換，該標準基于面向對象的方法定義建筑模型的數據結構。

通常情況下，可以直接通過符合IFC標準的IFC文件進行BIM數據的存儲與管理。然而在涉及多專業和大量復雜實體的IFC數據時，由于數據量龐大，應用復雜，且多專業參與進行數據模型的協同操作與處理，則需要基于數據庫進行BIM數據的存儲與管理[2]。一直以來都有學者進行基于數據庫的IFC工程模型存儲、管理和信息交換的研究。這種基于數據庫的IFC數據存儲和信息管理服務被IFC Wiki定義為IFC模型服務器(IFC model server)[3]。許多研究將復雜的查詢和緩慢的性能確定為以前開發的IFC模型服務器的主要局限性。隨著建筑物信息模型的大小增加，查詢和性能問題會變得更加嚴重。導致查詢復雜和性能降低的主要原因之一是，傳統的IFC模型服務器是基于E.F. Codd提出的關系數據庫(RDB)概念構建的[4]。由于RDB的穩定性和定義良好的查詢語言SQL(稱為結構化查詢語言)，大多數商業數據庫系統仍是基于RDB。但是，RDB作為IFC模型服務器的基礎存在一個關鍵缺點：IFC的定義是基于對象的，而RDB不是。雖然之后也有不少學者提出基于對象關系型數據庫的解決方案，例如Kang等分析了如何利用對象關系型數據庫Cubrid存儲IFC數據[5]，但是仍然都無法擺脫RDB作為底層實現的固有缺陷。

為了解決這一難點，本文提出了一個基于對象型層次型數據庫 InterSystems IRIS 的IFC數據存儲的實現方案，可以實現復雜建筑模型的高效存儲和讀取，并且在數據交換過程中完全符合IFC標準的模式。

1 基于對象型層次型數據庫的IFC數據存儲方案設計

對象型層次型數據庫是一類以基于層次模型的MUMPS(Massachusetts General Hospital Utility Multi-Programming System)技術作為底層存儲方案，擴展出支持面向對象數據模型的數據庫[6]。常見的層次型數據庫有InterSystems IRIS和GT.M，GT.M由于不支持面向對象的數據模型，不能稱作對象型層次型數據庫。同時，不同于傳統的對象關系型數據庫，對象型層次型數據庫可以完全支持面向對象數據模型的概念，如類、對象、繼承、抽象類等。

InterSystems IRIS作為一個分布式的多維模型數據庫是成熟的對象型層次型數據庫的代表，其分布式架構提供了優秀的水平擴展能力。本節介紹了對象型層次型數據庫在存儲IFC模型數據時的優勢，以及基于InterSystems IRIS的IFC模式映射和讀寫接口的實現過程。

1.1 InterSystems IRIS 數據庫技術要點

InterSystems IRIS是InterSystems 公司基于Caché 開發的新一代分布多維模型數據庫，它的底層實現是MUMPS(Massachusetts General Hospital Utility Multi-Programming System)技術，其核心概念是被稱做Global的多維稀疏數組。MUMPS技術擁有非常強大的表達能力，Caché在其基礎之上映射出了面向對象的數據庫模式，并且利用關系模式映射實現了關系型數據庫的結構[7]。同時集成了符合標準的SQL實現，還引入了ODBC、JDBC等接口以及SOAP和RESTful 等技術，使同一數據可以同時表現為稀疏數組、表、對象、XML 格式文件和JSON 格式文件等不同的形式，以適應完全不同的應用場景。InterSystems IRIS 沿用了Caché的核心存儲技術，加入了包括集群、水平擴展、大數據分析和商業智能等等現代數據庫特性，以用于更復雜的數據存儲和處理的場景[8]。

InterSystems IRIS通過將Global映射為對象和關系數據表的方式來提供面向對象模式和關系模式的數據訪問。因此，可以通過三種主要方式使用InterSystems IRIS進行數據的存儲和管理，包括直接操作底層的Global、通過面向對象的數據模型進行操作以及通過SQL語言進行關系型映射的數據操作。無論使用哪種方式，底層數據均存儲于Global數組中。由于具有支持層次型、對象型、關系型等多種數據模式的特性，InterSystems IRIS將其數據核心稱為多維數據引擎，它的工作原理如圖1所示。

圖1 InterSystems IRIS多維數據引擎

1.2 對象型層次型數據庫的優勢

IFC的核心設計思路是基于面向對象的思想。IFC的最初定義是包含基于EXPRESS語言的實體關系模型和SPF(STEP Physical File)的數據格式，并在IFC4的版本中正式引入了等價的IFC XSD實體關系模型和XML的數據格式。數百個存在繼承關系的實體類型被劃分為了多個抽象層次。這種設計天然契合了對象型層次型數據庫的數據模型和存儲技術。因此，基于對象型層次型數據庫的IFC數據存儲具有以下三大優勢：

第一，IFC格式到對象型層次型數據庫的模式映射難度較低。對象型數據的核心概念和面向對象的編程思想一致，IFC標準中的類、對象、繼承和抽象類等等概念可以非常便捷地在支持面向對象數據模型的數據庫中實現[9]。這大大降低了IFC格式抽象到數據庫中的實現難度，同時摒棄了傳統關系型數據庫中必不可少的關系表的這一抽象層。

第二，對象型層次型數據庫支持IFC格式的可擴展性。為了在建筑行業極高復雜度的背景下實現最大的兼容，IFC標準提供了自定義實體和自定義屬性來達到較高的可擴展性。傳統關系型數據庫和對象型層次型數據庫都具備一定的可擴展性。但比較而言，對象型層次型數據庫的擴展成本較低，實體類可以輕松擴展自定義屬性，父類也可以輕松派生出新的子類[10]。而關系型數據庫則需要擴展定義表結構或者定義新的表，并且在設計新的表結構時還要滿足不同范式的要求。

第三，對象型層次型數據庫在存儲IFC數據時具有較高的空間利用率。實際的工程項目中，由于建筑設計的獨特性，同一實體類的實例化對象往往不多。在傳統關系型數據庫的設計思路中，為了提高IFC數據的存儲效率，往往基于較高層次的父類或者抽象類來定義表結構，這會導致同一表下的每一行數據差異較大，這大大提高了數據的冗余度，降低了空間利用率。而對象型層次型數據庫則不會有這一問題，由于底層MUMPS存儲技術在保證對象型模式實現時的性能同時還具有良好的空間利用率[11]。

第四，對象型層次型數據庫便于實現基于XML格式的SOAP服務，具有面向云服務的 IFC數據操作優勢[12]。XML格式作為對象型層次型數據庫的數據交互格式之一，比較容易實現 SOAP 技術來支持IFC 之類的對象型數據的云服務。

1.3 IFC的模式映射設計

為了利用InterSystems IRIS的面向對象模式對IFC數據庫進行建模，首先需要設計IFC到InterSystems IRIS的模式映射。

模式是指一種以格式化的計算機可讀符號組成的數據模型，主要用于進行數據格式的定義，包含數據類型、數據結構和約束等等。IFC模式(IFC schema)是指IFC數據模型的格式化定義。buildingSMART 組織參考工業數據標準EXPRESS和STEP，定義了IFC的最初的模式定義，后來逐漸發展出以XML Schem為基礎的模式定義[13]。因此，目前IFC主要提供兩種形式的模式描述文件，一種是擴展名為exp的EXPRESS格式數據文件，EXPRESS是一種結構化的且具有很強的可讀性的數據定義語言，完整定義了IFC模式的所有內容，這是IFC標準的默認模式定義格式。另一種是擴展名為xsd的XML Schema模式定義文件，其中包含了IFC模式的最小化描述，其實體定義只包含明確屬性，不包含INVERSE、WHERE 等等關鍵字定義的約束規則。

根據兩種IFC模式的定義格式可以實現IFC數據的兩種文件序列化存儲格式。利用 EXPRESS格式的模式定義實現的序列化數據格式符合STEP標準，擴展名為ifc。而利用 XML Schema模式定義實現的序列化數據格式被稱作XML(Extensible Markup Language， 可擴展標記語言)，擴展名為ifcxml。雖然XML Schema模式的定義僅包含IFC模式的最小化描述，但基于該模式所實現的IFC XML物理格式不會丟失任何IFC的模型信息。兩種格式各有優點，STEP物理格式文件數據組織更緊湊，表達同樣信息量的模型時，文件大小僅是 XML文件格式的三分之一。而XML格式文件可讀性更強，且能夠以XML解析程序處理，適合基于網絡的數據交換，且更容易實現SOAP網絡服務。

圖2 兩種IFC模式、模型與文件

1.3.1 IFC EXPRESS 格式的模式映射

根據國際標準 ISO 10303-11 的定義，在EXPRESS語言中有五種數據類型：簡單類型(Simple)、集合類型(Aggregation)、聲明類型(Named)、構造類型(Constructed)和通用類型(Generalized)。因此，對于IFC物理格式中的各種數據類型， 在InterSystems IRIS中以替代類型進行存儲。

IFC EXPRESS定義中的簡單數據類型和ENUMERATION類型在InterSystems IRIS中都有對映的原始類型，而其它的復雜數據類型(集合類型、實體類型和選擇類型)需要轉換成InterSystems IRIS的類或者屬性。下面對這些復雜類型的定義做詳細說明：

(1)實體類型(ENTITY)

IFC EXPRESS中的實體類型是IFC數據的主要組成部分。因此，在數據庫中也是主要的存儲對象。實體類型的定義非常符合面向對象的思想，可以通過InterSystems IRIS中的類進行定義，并且可以實現實體類型包含屬性和繼承等特點。在IFC EXPRESS的實體類型中，主要包括抽象類和非抽象類。抽象類因為具有不可實例化的特點，理應從%RegisteredObject類派生，而非抽象類需要作為獨立對象持久化存儲，應從%Persistent類派生。然而在InterSystems IRIS中，從%RegisteredObject派生的類，由于不具有存儲特性，也就不會存儲在數據庫底層多維數組中，因此也無法參與一些查詢。在某些情況下需要查詢某一抽象類下所有派生類的實例，但由于抽象類從%RegisteredObject派生而來，不在數據庫中，在映射為關系模式時也找不到該類對映的表，因此以該類作為表名的SQL查詢便會失效。解決方法是將所有IFC類都從%Persistent類派生，即可執行支持繼承特性的 SQL 查詢，并且不會對數據的存儲產生任何影響。

關于屬性的規定，在IFC EXPRESS的定義中，OPTIONAL作為可選屬性的限制，與InterSystems IRIS中的Required限制含義正好相反。因此，在進行實體類型的屬性映射時需要注意限定。以IfcWindow 為例說明在InterSystems IRIS中實體的定義：

圖3 IfcWindow的模型映射

(2)集合類型(Aggregation)

在IFC EXPRESS中，集合類型通常作為實體類型的屬性出現。分為兩種情況，簡單數據類型的集合和實體類型的集合。對于這兩種類型，在InterSystems IRIS中可以采取不同的兩種定義方式。

對于簡單數據類型的集合，可以直接使用InterSystems IRIS中的%ArrayOfDataTypes或者%ListOfDataTypes來定義。

對于實體類型的集合，為了直接表達主實體和屬性實體之間的聯系，可以映射為InterSystems IRIS中的Relationship屬性。采用一對多的Relationship屬性可以描述出實體類型直接的關聯。在定義Relationship屬性時，需要在主實體和屬性實體的類定義中同時定義。Relationship屬性的定義包括三部分，關聯對象的類、關聯對象的基數(Cardinality 關鍵詞)、以及該屬性的反向屬性(Inverse 關鍵詞)。反向屬性的意義與IFC EXPRESS中INVERSE屬性的意義一致。根據IFC的定義規則，每個對象集合屬性的內部實體類型中都存在一條與該集合屬性相應的INVERSE屬性。因此在定義Relationship屬性時，可以利用INVERSE關鍵字找到對應的反向屬性的名稱。

(3)選擇類型(SELECT)

在IFC EXPRESS中，選擇類型也作為實體類型的屬性出現。選擇類型的底層類型可以是任意IFC類型，在數據庫中無法進行類型明確的存儲，因此需要對每個選擇類型做特殊處理，定義為從%SerialObject派生的類。該類型可以被實例化作為實體的屬性，但不會進行獨立存儲，隨使用它的類一起存儲。由于InterSystems IRIS中所有的類型在存儲時實際都以%String來保存，故屬性值定義可以為%String，只是在提取屬性值時要在外部用屬性的類型做強制類型轉換。

1.3.2 IFC XML Schema 格式的模式映射

XML Schema是IFC模式的另一種定義格式。自IFC2x3開始，buildingSMART便開始提供XML Schema文件。IFC XML Schema的數據類型主要包括XSD文件本身的Schema文件所定義的簡單數據類型和IFC所擴展的復雜數據類型，它們分別可以映射為InterSystems IRIS中的內置簡單數據類型和自定義類的復雜數據類型。

(1)XSD Schema 中的簡單數據類型

XSD Schema中的部分簡單數據類型可以直接映射為InterSystems IRIS中的簡單數據類型。但是另一些簡單數據類型無法使用其系統命名空間的數據類型，但是由于InterSystems IRIS擁有良好的XML支持，其在XSD命名空間中擴展了所有其它的數據類型。

(2)IFC XML Schema 定義的復雜數據類型

所有由IFC XML Schema復雜數據類型映射生成的類均可以派生自%Persistent 和%XML.Adaptor(InterSystems IRIS支持多類繼承)，其中%Persistent用來將類的定義和實例化的數據持久化存儲到底層的多維數組中，而%XML.Adaptor類則實現了XML的存儲和讀取相關的方法，為直接使用IFCXML的數據提供了便利。

另外，抽象類和在自定義類中的數組類型屬性需要特別注意。

對于抽象元素或類型的處理，同樣為了保證在某些情況下查詢抽象類下所有派生類的實例，將其映射成為從%Persistent類派生，而不是從%RegisteredObject派生。

對于IFC XML Schema中定義的數組類型，采用類似于IFC EXPRESS中的集合類型的處理方式，將集合從屬類和元素類之間的聯系映射為InterSystems IRIS中一對多的Relationship屬性。具體實現方式參考上一節關于集合類型的映射規則。雖然在XML Schema中無法實現INVERSE的約束類型，但是通過使用Relationship可以間接實現在IFC EXPRESS中的INVERSE約束。

(3)利用 XML Schema 的類生成實現IFC XML Schema 的自動映射

InterSystems IRIS為了簡化XML的使用，在%XML的命名空間中提供了SchemaReader類來簡化XML Schema到類定義的自動生成。具體方法是在創建%XML.Utils.SchemaReader的實例之后，設定該實例的屬性來完成對數組類型和抽象元素的處理，還有關于XML生成的屬性設置也非常必要，具體在下一節介紹，然后，利用 Process 的方法即可自動生成類定義。

1.4 基于IFC XML Schema的IFC數據的存儲和讀取方案

XML作為一種廣泛使用的網絡通信數據格式，在IFC模型服務器中有著更大的應用優勢。同時，InterSystems IRIS對XML有著更加完整的支持，在類的定義、XML數據的導入和導出方面都有比較成熟的實現方案。雖然在IFC的標準中，XML Schema只是IFC模式的最小化實現，但是仍然可以保證IFC數據和STEP格式的一致性，建筑信息本身不會丟失。因此，基于IFC XML Schema實現InterSystems IRIS數據庫對IFC數據的存儲和讀取是相對更加便利的方案。本文以下的應用系統的構建和工程實踐的測試均基于IFC XML Schema的格式來進行。

1.4.1 IFC XML數據的存儲

在通過IFC XML Schema文件定義好所有的類之后，便可以將IFC XML數據導入InterSystems IRIS了。InterSystems IRIS在XML Tool中提供了%XML.Reader類實現XML到對象的映射，可以將XML文件的元素實例化成所有由%XML.Adaptor派生的類的對象。%XML.Reader類還可以間接完成對XML文件的Schema驗證。

存儲IFC XML數據的具體步驟是，先實例化一個%XML.Reader的對象，用于讀取和驗證IFC XML文件數據，并解析成為XML DOM樹，再通過Correlate方法建立XML元素和類的對應關系，然后可以從XML DOM樹上找到對應元素，再利用元素信息實例化相關的類。最后調用對象的%Save()方法將對象存儲到Global多維數組中。下面以從filename變量所指的文件導入IFC模型數據到IRIS中的“IFC4.ifcXML”類(也對應為關系型模型下的一張表)為例，說明IFC XML的存儲過程。

圖4 IFC XML 的存儲過程

這里的ifcXML是IFCXML文件中的根元素標簽。在保存XML數據到IRIS時，reader對象可以遍歷所有的XML子元素來保存到對應的類。因此，只需要調用與IFC4.ifcXML相關的reader即可存儲完整的IFCXML數據到數據庫中。但需要特別注意的是，當遇到自定義類作為屬性時，需要調用%XML.New方法進行屬性的構造，因為該屬性的實例會保存在自己的類(表)中，屬性所屬類(表)中只保存它的記錄ID。

1.4.2 IFCXML數據的讀取

從 InterSystems IRIS的對象生成IFC XML數據需要注意幾個問題。首先是命名空間的處理，InterSystems IRIS和XML的命名空間具有不同的含義，另外，每一個版本的IFC XML Schema均定義了不同的命名空間。其次是對XML空子段或者空對象的處理，以及XML元素的順序問題。為了保證讀取出來的IFCXML數據仍然符合Schema的定義，并且不丟失任何IFC建筑模型信息，需要對這些問題進行特別的處理。InterSystems IRIS的%XML.Adaptor為這些問題的處理提供了便利，下面以IFC4.Entity為例說明如何保證XML數據讀取的一致性。

圖5 IFC4. Entity 類的定義

2 IFC數據存儲方案可行性驗證

為了驗證基于對象型層次型數據庫的IFC數據存儲方案的可行性，本節選取了三種從簡單到復雜的IFC模型，以IFC XML的格式存儲到InterSystems IRIS數據庫中，并讀取生成新的IFC XML模型數據，進行對比驗證。

(1)實驗數據和環境

三種IFC模型分別對應了實體數目百級、萬級和百萬級。其中最簡單的模型來自于 buildingSMART提供的IFC樣例文件，較復雜的兩個模型來自Revit 2019的建筑項目樣例模型rac_basic_sample_project和rac_advanced_sample_project。

驗證實驗的硬件環境為英特爾i5-8400六核處理器、16 GB DDR4內存和256 G固態硬盤，InterSystems IRIS數據庫版本為2020.1.0.215.0社區版，單節點運行在Ubuntu 18.04 LTS 64位操作系統上。

(2)驗證結果

按照以上實驗數據和環境可以得到如表1 所示的實驗驗證結果。

表1 三種IFC模型的實驗驗證結果對比

表1中第二至四列的結果分別表示原始模型和數據庫讀取的模型。從結果中可以看出，IFC XML文件大小以及ZIP壓縮文件大小在數據庫存儲前后有一定的差異，但實體數目沒有發生變化。為了進一步驗證前后數據的一致性，利用開源的xmldiff工具對XML數據進行節點比對，僅僅只有部分與IFC Schema定義相關的屬性信息發生變化，同時部分為空的數據在數據庫導出時去除，減少了無用信息。因此，從實驗結果來看，三種級別的IFC模型數據均未丟失，該數據庫方案提供了IFC數據的一致性保證。

從存儲和讀取的時間結果來看，最復雜的百萬級別模型存儲時間在一分鐘級別，但讀取時間只有十秒左右，原因在于存儲IFC XML數據時會進行Schema的驗證，消耗更多的時間。由于沒有進行索引和數據庫參數配置的優化，實驗結果所體現的存取效率已經比較令人滿意。

3 結論和展望

本文總結了BIM的核心技術之一IFC標準在數據庫存儲相關領域的研究進展，針對傳統的基于對象關系型數據庫IFC數據存儲的缺陷，提出了一種基于對象型層次型數據庫的新型IFC數據存儲模型。同時，對比兩種IFC模式映射思路，設計了基于IFC XML Schema的數據庫定義方案。最后，利用三種不同實體數目級別的典型IFC模型進行了實驗，驗證了該數據庫設計方案的數據一致性和存取效率。

不過展望BIM技術的發展趨勢，如何在兼容IFC標準的基礎上，實現版本控制和高級查詢等等更加復雜的應用場景仍然值得進一步研究。充分利用InterSystems IRIS或者其它新型數據庫的現代特性，如商業智能、大數據處理、集群等等，結合信息技術領域的最新成果，才能將BIM技術的應用推向新的高度和廣度。