曾 強(qiáng) 張其林， 張金輝

(1.同濟(jì)大學(xué) 土木工程學(xué)院，上海 200092； 2.上海同磊土木工程技術(shù)有限公司，上海 200092； 3.上海土木工程結(jié)構(gòu)健康監(jiān)測(cè)工程技術(shù)研究中心，上海 200092)

引言

為了解決建筑工程項(xiàng)目的各個(gè)參與方間信息交換的困難，國(guó)際交互操作性聯(lián)盟IAI(International Alliance for Interoperability)制定了一種用于描述、交換和共享建筑信息的國(guó)際化規(guī)范工業(yè)基礎(chǔ)類IFC(Industry Foundation Classes)，并且IFC4的版本已經(jīng)成為ISO國(guó)際標(biāo)準(zhǔn)(ISO 16739)[1]。當(dāng)前BIM技術(shù)主要通過IFC標(biāo)準(zhǔn)進(jìn)行數(shù)據(jù)交換，該標(biāo)準(zhǔn)基于面向?qū)ο蟮姆椒ǘx建筑模型的數(shù)據(jù)結(jié)構(gòu)。

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

為了解決這一難點(diǎn)，本文提出了一個(gè)基于對(duì)象型層次型數(shù)據(jù)庫 InterSystems IRIS 的IFC數(shù)據(jù)存儲(chǔ)的實(shí)現(xiàn)方案，可以實(shí)現(xiàn)復(fù)雜建筑模型的高效存儲(chǔ)和讀取，并且在數(shù)據(jù)交換過程中完全符合IFC標(biāo)準(zhǔn)的模式。

1 基于對(duì)象型層次型數(shù)據(jù)庫的IFC數(shù)據(jù)存儲(chǔ)方案設(shè)計(jì)

對(duì)象型層次型數(shù)據(jù)庫是一類以基于層次模型的MUMPS(Massachusetts General Hospital Utility Multi-Programming System)技術(shù)作為底層存儲(chǔ)方案，擴(kuò)展出支持面向?qū)ο髷?shù)據(jù)模型的數(shù)據(jù)庫[6]。常見的層次型數(shù)據(jù)庫有InterSystems IRIS和GT.M，GT.M由于不支持面向?qū)ο蟮臄?shù)據(jù)模型，不能稱作對(duì)象型層次型數(shù)據(jù)庫。同時(shí)，不同于傳統(tǒng)的對(duì)象關(guān)系型數(shù)據(jù)庫，對(duì)象型層次型數(shù)據(jù)庫可以完全支持面向?qū)ο髷?shù)據(jù)模型的概念，如類、對(duì)象、繼承、抽象類等。

InterSystems IRIS作為一個(gè)分布式的多維模型數(shù)據(jù)庫是成熟的對(duì)象型層次型數(shù)據(jù)庫的代表，其分布式架構(gòu)提供了優(yōu)秀的水平擴(kuò)展能力。本節(jié)介紹了對(duì)象型層次型數(shù)據(jù)庫在存儲(chǔ)IFC模型數(shù)據(jù)時(shí)的優(yōu)勢(shì)，以及基于InterSystems IRIS的IFC模式映射和讀寫接口的實(shí)現(xiàn)過程。

1.1 InterSystems IRIS 數(shù)據(jù)庫技術(shù)要點(diǎn)

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

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

圖1 InterSystems IRIS多維數(shù)據(jù)引擎

1.2 對(duì)象型層次型數(shù)據(jù)庫的優(yōu)勢(shì)

IFC的核心設(shè)計(jì)思路是基于面向?qū)ο蟮乃枷?。IFC的最初定義是包含基于EXPRESS語言的實(shí)體關(guān)系模型和SPF(STEP Physical File)的數(shù)據(jù)格式，并在IFC4的版本中正式引入了等價(jià)的IFC XSD實(shí)體關(guān)系模型和XML的數(shù)據(jù)格式。數(shù)百個(gè)存在繼承關(guān)系的實(shí)體類型被劃分為了多個(gè)抽象層次。這種設(shè)計(jì)天然契合了對(duì)象型層次型數(shù)據(jù)庫的數(shù)據(jù)模型和存儲(chǔ)技術(shù)。因此，基于對(duì)象型層次型數(shù)據(jù)庫的IFC數(shù)據(jù)存儲(chǔ)具有以下三大優(yōu)勢(shì)：

第一，IFC格式到對(duì)象型層次型數(shù)據(jù)庫的模式映射難度較低。對(duì)象型數(shù)據(jù)的核心概念和面向?qū)ο蟮木幊趟枷胍恢拢琁FC標(biāo)準(zhǔn)中的類、對(duì)象、繼承和抽象類等等概念可以非常便捷地在支持面向?qū)ο髷?shù)據(jù)模型的數(shù)據(jù)庫中實(shí)現(xiàn)[9]。這大大降低了IFC格式抽象到數(shù)據(jù)庫中的實(shí)現(xiàn)難度，同時(shí)摒棄了傳統(tǒng)關(guān)系型數(shù)據(jù)庫中必不可少的關(guān)系表的這一抽象層。

第二，對(duì)象型層次型數(shù)據(jù)庫支持IFC格式的可擴(kuò)展性。為了在建筑行業(yè)極高復(fù)雜度的背景下實(shí)現(xiàn)最大的兼容，IFC標(biāo)準(zhǔn)提供了自定義實(shí)體和自定義屬性來達(dá)到較高的可擴(kuò)展性。傳統(tǒng)關(guān)系型數(shù)據(jù)庫和對(duì)象型層次型數(shù)據(jù)庫都具備一定的可擴(kuò)展性。但比較而言，對(duì)象型層次型數(shù)據(jù)庫的擴(kuò)展成本較低，實(shí)體類可以輕松擴(kuò)展自定義屬性，父類也可以輕松派生出新的子類[10]。而關(guān)系型數(shù)據(jù)庫則需要擴(kuò)展定義表結(jié)構(gòu)或者定義新的表，并且在設(shè)計(jì)新的表結(jié)構(gòu)時(shí)還要滿足不同范式的要求。

第三，對(duì)象型層次型數(shù)據(jù)庫在存儲(chǔ)IFC數(shù)據(jù)時(shí)具有較高的空間利用率。實(shí)際的工程項(xiàng)目中，由于建筑設(shè)計(jì)的獨(dú)特性，同一實(shí)體類的實(shí)例化對(duì)象往往不多。在傳統(tǒng)關(guān)系型數(shù)據(jù)庫的設(shè)計(jì)思路中，為了提高IFC數(shù)據(jù)的存儲(chǔ)效率，往往基于較高層次的父類或者抽象類來定義表結(jié)構(gòu)，這會(huì)導(dǎo)致同一表下的每一行數(shù)據(jù)差異較大，這大大提高了數(shù)據(jù)的冗余度，降低了空間利用率。而對(duì)象型層次型數(shù)據(jù)庫則不會(huì)有這一問題，由于底層MUMPS存儲(chǔ)技術(shù)在保證對(duì)象型模式實(shí)現(xiàn)時(shí)的性能同時(shí)還具有良好的空間利用率[11]。

第四，對(duì)象型層次型數(shù)據(jù)庫便于實(shí)現(xiàn)基于XML格式的SOAP服務(wù)，具有面向云服務(wù)的 IFC數(shù)據(jù)操作優(yōu)勢(shì)[12]。XML格式作為對(duì)象型層次型數(shù)據(jù)庫的數(shù)據(jù)交互格式之一，比較容易實(shí)現(xiàn) SOAP 技術(shù)來支持IFC 之類的對(duì)象型數(shù)據(jù)的云服務(wù)。

1.3 IFC的模式映射設(shè)計(jì)

為了利用InterSystems IRIS的面向?qū)ο竽Ｊ綄?duì)IFC數(shù)據(jù)庫進(jìn)行建模，首先需要設(shè)計(jì)IFC到InterSystems IRIS的模式映射。

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

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

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

1.3.1 IFC EXPRESS 格式的模式映射

根據(jù)國(guó)際標(biāo)準(zhǔn) ISO 10303-11 的定義，在EXPRESS語言中有五種數(shù)據(jù)類型：簡(jiǎn)單類型(Simple)、集合類型(Aggregation)、聲明類型(Named)、構(gòu)造類型(Constructed)和通用類型(Generalized)。因此，對(duì)于IFC物理格式中的各種數(shù)據(jù)類型， 在InterSystems IRIS中以替代類型進(jìn)行存儲(chǔ)。

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

(1)實(shí)體類型(ENTITY)

IFC EXPRESS中的實(shí)體類型是IFC數(shù)據(jù)的主要組成部分。因此，在數(shù)據(jù)庫中也是主要的存儲(chǔ)對(duì)象。實(shí)體類型的定義非常符合面向?qū)ο蟮乃枷?，可以通過InterSystems IRIS中的類進(jìn)行定義，并且可以實(shí)現(xiàn)實(shí)體類型包含屬性和繼承等特點(diǎn)。在IFC EXPRESS的實(shí)體類型中，主要包括抽象類和非抽象類。抽象類因?yàn)榫哂胁豢蓪?shí)例化的特點(diǎn)，理應(yīng)從%RegisteredObject類派生，而非抽象類需要作為獨(dú)立對(duì)象持久化存儲(chǔ)，應(yīng)從%Persistent類派生。然而在InterSystems IRIS中，從%RegisteredObject派生的類，由于不具有存儲(chǔ)特性，也就不會(huì)存儲(chǔ)在數(shù)據(jù)庫底層多維數(shù)組中，因此也無法參與一些查詢。在某些情況下需要查詢某一抽象類下所有派生類的實(shí)例，但由于抽象類從%RegisteredObject派生而來，不在數(shù)據(jù)庫中，在映射為關(guān)系模式時(shí)也找不到該類對(duì)映的表，因此以該類作為表名的SQL查詢便會(huì)失效。解決方法是將所有IFC類都從%Persistent類派生，即可執(zhí)行支持繼承特性的 SQL 查詢，并且不會(huì)對(duì)數(shù)據(jù)的存儲(chǔ)產(chǎn)生任何影響。

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

圖3 IfcWindow的模型映射

(2)集合類型(Aggregation)

在IFC EXPRESS中，集合類型通常作為實(shí)體類型的屬性出現(xiàn)。分為兩種情況，簡(jiǎn)單數(shù)據(jù)類型的集合和實(shí)體類型的集合。對(duì)于這兩種類型，在InterSystems IRIS中可以采取不同的兩種定義方式。

對(duì)于簡(jiǎn)單數(shù)據(jù)類型的集合，可以直接使用InterSystems IRIS中的%ArrayOfDataTypes或者%ListOfDataTypes來定義。

對(duì)于實(shí)體類型的集合，為了直接表達(dá)主實(shí)體和屬性實(shí)體之間的聯(lián)系，可以映射為InterSystems IRIS中的Relationship屬性。采用一對(duì)多的Relationship屬性可以描述出實(shí)體類型直接的關(guān)聯(lián)。在定義Relationship屬性時(shí)，需要在主實(shí)體和屬性實(shí)體的類定義中同時(shí)定義。Relationship屬性的定義包括三部分，關(guān)聯(lián)對(duì)象的類、關(guān)聯(lián)對(duì)象的基數(shù)(Cardinality 關(guān)鍵詞)、以及該屬性的反向?qū)傩?Inverse 關(guān)鍵詞)。反向?qū)傩缘囊饬x與IFC EXPRESS中INVERSE屬性的意義一致。根據(jù)IFC的定義規(guī)則，每個(gè)對(duì)象集合屬性的內(nèi)部實(shí)體類型中都存在一條與該集合屬性相應(yīng)的INVERSE屬性。因此在定義Relationship屬性時(shí)，可以利用INVERSE關(guān)鍵字找到對(duì)應(yīng)的反向?qū)傩缘拿Q。

(3)選擇類型(SELECT)

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

1.3.2 IFC XML Schema 格式的模式映射

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

(1)XSD Schema 中的簡(jiǎn)單數(shù)據(jù)類型

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

(2)IFC XML Schema 定義的復(fù)雜數(shù)據(jù)類型

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

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

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

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

(3)利用 XML Schema 的類生成實(shí)現(xiàn)IFC XML Schema 的自動(dòng)映射

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

1.4 基于IFC XML Schema的IFC數(shù)據(jù)的存儲(chǔ)和讀取方案

XML作為一種廣泛使用的網(wǎng)絡(luò)通信數(shù)據(jù)格式，在IFC模型服務(wù)器中有著更大的應(yīng)用優(yōu)勢(shì)。同時(shí)，InterSystems IRIS對(duì)XML有著更加完整的支持，在類的定義、XML數(shù)據(jù)的導(dǎo)入和導(dǎo)出方面都有比較成熟的實(shí)現(xiàn)方案。雖然在IFC的標(biāo)準(zhǔn)中，XML Schema只是IFC模式的最小化實(shí)現(xiàn)，但是仍然可以保證IFC數(shù)據(jù)和STEP格式的一致性，建筑信息本身不會(huì)丟失。因此，基于IFC XML Schema實(shí)現(xiàn)InterSystems IRIS數(shù)據(jù)庫對(duì)IFC數(shù)據(jù)的存儲(chǔ)和讀取是相對(duì)更加便利的方案。本文以下的應(yīng)用系統(tǒng)的構(gòu)建和工程實(shí)踐的測(cè)試均基于IFC XML Schema的格式來進(jìn)行。

1.4.1 IFC XML數(shù)據(jù)的存儲(chǔ)

在通過IFC XML Schema文件定義好所有的類之后，便可以將IFC XML數(shù)據(jù)導(dǎo)入InterSystems IRIS了。InterSystems IRIS在XML Tool中提供了%XML.Reader類實(shí)現(xiàn)XML到對(duì)象的映射，可以將XML文件的元素實(shí)例化成所有由%XML.Adaptor派生的類的對(duì)象。%XML.Reader類還可以間接完成對(duì)XML文件的Schema驗(yàn)證。

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

圖4 IFC XML 的存儲(chǔ)過程

這里的ifcXML是IFCXML文件中的根元素標(biāo)簽。在保存XML數(shù)據(jù)到IRIS時(shí)，reader對(duì)象可以遍歷所有的XML子元素來保存到對(duì)應(yīng)的類。因此，只需要調(diào)用與IFC4.ifcXML相關(guān)的reader即可存儲(chǔ)完整的IFCXML數(shù)據(jù)到數(shù)據(jù)庫中。但需要特別注意的是，當(dāng)遇到自定義類作為屬性時(shí)，需要調(diào)用%XML.New方法進(jìn)行屬性的構(gòu)造，因?yàn)樵搶傩缘膶?shí)例會(huì)保存在自己的類(表)中，屬性所屬類(表)中只保存它的記錄ID。

1.4.2 IFCXML數(shù)據(jù)的讀取

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

圖5 IFC4. Entity 類的定義

2 IFC數(shù)據(jù)存儲(chǔ)方案可行性驗(yàn)證

為了驗(yàn)證基于對(duì)象型層次型數(shù)據(jù)庫的IFC數(shù)據(jù)存儲(chǔ)方案的可行性，本節(jié)選取了三種從簡(jiǎn)單到復(fù)雜的IFC模型，以IFC XML的格式存儲(chǔ)到InterSystems IRIS數(shù)據(jù)庫中，并讀取生成新的IFC XML模型數(shù)據(jù)，進(jìn)行對(duì)比驗(yàn)證。

(1)實(shí)驗(yàn)數(shù)據(jù)和環(huán)境

三種IFC模型分別對(duì)應(yīng)了實(shí)體數(shù)目百級(jí)、萬級(jí)和百萬級(jí)。其中最簡(jiǎn)單的模型來自于 buildingSMART提供的IFC樣例文件，較復(fù)雜的兩個(gè)模型來自Revit 2019的建筑項(xiàng)目樣例模型rac_basic_sample_project和rac_advanced_sample_project。

驗(yàn)證實(shí)驗(yàn)的硬件環(huán)境為英特爾i5-8400六核處理器、16 GB DDR4內(nèi)存和256 G固態(tài)硬盤，InterSystems IRIS數(shù)據(jù)庫版本為2020.1.0.215.0社區(qū)版，單節(jié)點(diǎn)運(yùn)行在Ubuntu 18.04 LTS 64位操作系統(tǒng)上。

(2)驗(yàn)證結(jié)果

按照以上實(shí)驗(yàn)數(shù)據(jù)和環(huán)境可以得到如表1 所示的實(shí)驗(yàn)驗(yàn)證結(jié)果。

表1 三種IFC模型的實(shí)驗(yàn)驗(yàn)證結(jié)果對(duì)比

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

從存儲(chǔ)和讀取的時(shí)間結(jié)果來看，最復(fù)雜的百萬級(jí)別模型存儲(chǔ)時(shí)間在一分鐘級(jí)別，但讀取時(shí)間只有十秒左右，原因在于存儲(chǔ)IFC XML數(shù)據(jù)時(shí)會(huì)進(jìn)行Schema的驗(yàn)證，消耗更多的時(shí)間。由于沒有進(jìn)行索引和數(shù)據(jù)庫參數(shù)配置的優(yōu)化，實(shí)驗(yàn)結(jié)果所體現(xiàn)的存取效率已經(jīng)比較令人滿意。

3 結(jié)論和展望

本文總結(jié)了BIM的核心技術(shù)之一IFC標(biāo)準(zhǔn)在數(shù)據(jù)庫存儲(chǔ)相關(guān)領(lǐng)域的研究進(jìn)展，針對(duì)傳統(tǒng)的基于對(duì)象關(guān)系型數(shù)據(jù)庫IFC數(shù)據(jù)存儲(chǔ)的缺陷，提出了一種基于對(duì)象型層次型數(shù)據(jù)庫的新型IFC數(shù)據(jù)存儲(chǔ)模型。同時(shí)，對(duì)比兩種IFC模式映射思路，設(shè)計(jì)了基于IFC XML Schema的數(shù)據(jù)庫定義方案。最后，利用三種不同實(shí)體數(shù)目級(jí)別的典型IFC模型進(jìn)行了實(shí)驗(yàn)，驗(yàn)證了該數(shù)據(jù)庫設(shè)計(jì)方案的數(shù)據(jù)一致性和存取效率。

不過展望BIM技術(shù)的發(fā)展趨勢(shì)，如何在兼容IFC標(biāo)準(zhǔn)的基礎(chǔ)上，實(shí)現(xiàn)版本控制和高級(jí)查詢等等更加復(fù)雜的應(yīng)用場(chǎng)景仍然值得進(jìn)一步研究。充分利用InterSystems IRIS或者其它新型數(shù)據(jù)庫的現(xiàn)代特性，如商業(yè)智能、大數(shù)據(jù)處理、集群等等，結(jié)合信息技術(shù)領(lǐng)域的最新成果，才能將BIM技術(shù)的應(yīng)用推向新的高度和廣度。