基于對象型層次型數(shù)據(jù)庫的 IFC 數(shù)據(jù)存儲研究

曾 強 張其林， 張金輝

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

引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 IFC的模式映射設計

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

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

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

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

1.3.1 IFC EXPRESS 格式的模式映射

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

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

(1)實體類型(ENTITY)

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

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

圖3 IfcWindow的模型映射

(2)集合類型(Aggregation)

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

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

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

(3)選擇類型(SELECT)

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

1.3.2 IFC XML Schema 格式的模式映射

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖4 IFC XML 的存儲過程

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

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

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

圖5 IFC4. Entity 類的定義

2 IFC數(shù)據(jù)存儲方案可行性驗證

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

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

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

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

(2)驗證結果

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

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

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

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

3 結論和展望

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

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