信息化是建筑业发展战略的重要组成部分，而建筑信息模型(building information modelling, BIM)是建筑业信息化的基础，其核心是工程各种信息的集成、共享与交互^[1]。BIM信息的传递主要涉及3个维度：1)时间维度，即在建筑工程全生命周期(如规划、设计、施工、运维和拆除)内传递；2)专业维度，即在建筑工程涉及的多个设计专业(如建筑、结构、给排水、暖通等)间传递，避免或减少设计冲突^[2]；3)参与方维度，即在建筑工程利益相关方(如建设方、施工方、设计方等)间传递，避免信息孤岛和信息断层^[3]。BIM在建筑工程不同阶段、不同设计专业、不同参与方的应用，需要不同BIM应用软件(如Revit、Tekla Structures、Rhinoceros等)和数据类型的支持，即需要标准数据转换实现工程各阶段、各专业和各参与方之间的有效信息传递。

为此，buildingSMART提出工业基础类(industry foundation classes，IFC)^[4]作为BIM信息交换的标准^[3]。IFC标准采用面向对象的EXPRESS语言描述建筑产品数据，通过IFC文件进行存储和管理。尽管IFC标准为BIM综合应用及相关软件二次开发提供一定支持，但IFC文件自身存在局限性，例如不支持并行操作、缺乏安全性，且经常包含过多冗余信息，故不能成为信息系统数据存储的主要形式^{[1, 5]}。相比之下，数据库是长期存储在计算机内、有组织的、可共享的数据集合。因此，将IFC数据模型转换为数据库模型，不仅有利于BIM数据的共享和并行操作，还能有效提高数据的安全性、可靠性和持久性^[6-7]。

目前，将IFC数据模型映射为数据库模型的相关研究，可分为映射为关系型数据库和非关系型数据库两类。关系型数据库是依据关系模型创建的数据库，其中关系模型指二维表格模型，因而关系型数据库是由二维表及它们之间的联系组成的数据组织^[8]。非关系型数据库是指非关系型的、分布式的，且一般不保证遵守ACID(原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability))原则的数据存储系统。相比之下，关系型数据库成本低、有利于持久存储，而非关系型数据库支持多种存储格式、查询效率高、可扩展性强。对于关系型数据库，李小林等^[9]针对STEP标准利用数据字典实现了不同数据类型从EXPRESS数据向关系型数据库的转换，该方法的局限是需要手动创建数据表；张洋^[7]利用关系型数据库存储IFC数据，实现了IFC模型结构化数据的读取、保存、提取、集成和扩展，但仅侧重于建筑设计阶段，未对后期施工应用作进一步研究分析；成于思等^[1]在考虑继承关系和聚类关系的基础上定义了从IFC数据模型向关系型数据库模型的转换规则，但未考虑属性约束，因此难以转换全部信息；Solihin等^[10]根据星型模型将IFC数据转化为BIMRL模式，从而实现BIM数据的标准化SQL查询，可根据构件属性和空间位置检索，但仅提供只读访问，且与空间相关的检索效率较低。对于非关系型数据库，Faraj等^[11]提出了基于Web的IFC共享项目环境ŽWISPER，利用STEP工具ST-Developer实现EXPRESS的解析并映射到ObjectStore，但未系统比较其数据管理效率和对工程项目产生的经济价值；Tanyer等^[12]将IFC数据转存入面向对象数据库，开发新的4D规划工具，但转存后的IFC文件大小是原来的2~5倍，降低了系统性能；Lee等^[13]基于对象-关系数据库开发了对象-关系IFC服务器，通过简化继承结构和聚合概念的映射过程来提高查询性能，但未考虑数据库的其他操作性能；张迪等^[14]用对象-关系型数据库Oracle管理IFC数据，存储建筑数据模型，但仅定义4种数据类型的映射规则，亦未进一步分析其数据管理效率。

此外，一些研究专门对映射后的关系型数据库和面向对象数据库的文件管理效率进行比较分析。例如，黄忠东等^[15]比较了基于关系型数据库和面向对象数据库实现标准数据存储界面的优缺点，虽然面向对象数据库的模式转换更直接，但是考虑到关系型数据库相关技术更成熟，拥有标准的数据模式和接口，且应用更广泛，故关系型数据库在现阶段更适用。Jeong等^[16]比较了使用关系型数据库和对象-关系型数据库查询含有9 115个对象的IFC文件的效率，发现除查询简单对象外，对象-关系型数据库的查询效率更高。陆宁等^[17]对两种具有代表性的数据库——面向对象数据库Versant Object Database 8和关系型数据库SQL Server 2005在插入、查询、更新和删除数据方面的效率进行比较，发现对于超过数万实体构成的IFC数据，面向对象数据库的管理效率相对更高。Lee等^[13]通过案例测试发现对象-关系数据库的查询性能优于关系型数据库，且数据规模越大，差别越大，原因在于IFC采用面向对象的EXPRESS语言，因此面向对象数据库能够更直接、自然地表示EXPRESS的语义，对大量IFC数据的处理效率也相对更高。然而，EXPRESS和面向对象数据库的数据类型并不一一对应，且不同面向对象数据库的模式差异较大，可移植性较低^[15]。另外，由于关系型数据库拥有以下优点，即丰富的计算机编程语言接口、成熟的商业软件和配套工具软件，从促进建筑信息有效传递的角度出发，选择将IFC数据模型映射为关系型数据库模型更有利于实现BIM数据的传递和共享。

综上所述，虽然现有研究对于IFC数据到关系型数据库的自动映射已经取得一定进展，但仍存在以下局限：未考虑完整约束导致信息丢失，未进一步分析其映射效率和数据管理效率，且应用主要集中于建筑设计阶段，较少考虑施工阶段。因此，仍需要一种通用的转换方法，不仅实现各种BIM软件导出的IFC数据模型到关系型数据库模型的自动映射，还应在关系型数据库中尽量保留原始的构件信息，以便在此基础上针对后期施工应用进行二次开发。为此，本研究基于面向对象的Java语言提出一种IFC数据模型至关系型数据库模型的自动映射方法，进一步比较该方法和直接操作IFC文件在信息传递完整性和数据管理效率方面的差异，并通过2个施工应用案例，验证所提出方法的专业应用前景。

1 自动映射方法构建 1.1 IFC模型数据结构概述

IFC标准作为国际通用的BIM数据标准，采用面向对象的EXPRESS语言描述建筑产品数据。这意味着IFC既可以描述真实的物理对象，如门、窗等，也可以表示抽象的概念，如组织过程^[7]。IFC数据模型由4个层次构成，从低到高依次为资源层、核心层、共享层和领域层，各层之间遵循“重力原则”，即每个层次只能引用同层次或低层次的信息。

一个完整的IFC数据模型由实体(entity)、类型(type)、函数(function)、规则(rule)、属性集(property set)和数量集(quantity set)构成。实体是由属性与约束定义的信息集，是IFC数据模型的核心。类型定义作为IFC模型的主要组成部分，包括3种数据类型：定义类型(defined type)、枚举类型(enumeration type)和选择类型(select type)。函数和规则用于计算或者约束实体的属性，亦可用于验证模型的正确性。属性集则是属性的集合，用于描述事物和概念，可以被不同的对象引用。数量集是定量信息的集合，也可以被不同的对象引用。表 1展示IFC4x1中模型元素在各功能层的数量分布。

1.2 映射规则构建

为实现IFC数据在关系型数据库中的持久存储，本研究将构建从IFC到Java再到MySQL数据库的映射规则。IFC模型由大量实体对象组成，实体是IFC信息交换的载体，通过实体、类型、函数、规则、属性集值和数量集值的引用进行定义，下面分别建立相应的映射规则。

1.2.1 实体映射规则

对于实体映射规则，区别于EXPRESS语言支持多重继承，IFC的实体是单继承的，这与Java面向对象继承的概念一致，因此IFC的实体在映射过程中分别对应Java类和关系型数据库的表。

1.2.2 类型映射规则

如表 2所示，IFC的定义类型转换为Java类中的基本数据类型或者String类型，在MySQL数据库中则存储为对应的基本类型。IFC的枚举类型映射为Java中的枚举类型，由于枚举类型的取值均为字符串，因此对应MySQL数据库用varchar类型存储。对于选择类型，把IFC的选择类型对应的类的值存储到Java中的String类型，在MySQL数据库中则存储为varchar类型。比如，IfcActorSelect是选择类型，可供选择的类型有IfcPerson、IfcPersonAnd-Organization和IfcOrganization 3种，解析过程中根据IFC文件的内容首先映射到Java对应的这3种类型(IfcPersonAndOrganization、IfcOrganization和IfcPerson)中，各类型中的值用String类型存储，而在MySQL数据库中用varchar类型存储。

1.2.3 函数和规则的映射规则

IFC的函数对应Java类中的函数名，但这些函数不在MySQL数据库中存储。规则对应于Java类中的逻辑过程，也不在MySQL数据库中存储。

1.2.4 属性集和数量集的映射规则

IFC的属性集和数量集，虽然在不同功能层的不同模块中有各自的字段名，但都映射为Java类中基本数据类型或者String类型，因此在MySQL数据库中存储为基本类型中的varchar类型。

1.3 IFC数据解析和映射

完成IFC数据模型到MySQL数据库模型映射规则的构建后，需要对IFC数据进行解析。本研究在jdk1.8开发环境下，采用Java语言，使用hibernata开源库，采用buildingSmart提供的开源解析引擎(IFCjar包为com.apstex.ifc4x2toolbox.jar)，通过设计与IFC标准对应的Java类以及类的属性对IFC数据进行深度解析，部分属性采用一对一映射，部分属性则采用一对多映射，实现IFC共享层实体类(IFC4x1共48种)的自动解析与映射。以某个实际工程IFC模型中的IfcBeam实体为例，如表 3所示，该实体包含GlobalId、OwnerHistory、Representation等多种属性。其中，梁的总编号属性属于一对一映射，其属性名为GlobalId，数据类型为IfcGloballyUniqueId，对应的Java类自定义属性名为GlobalId，数据类型为String；而梁的表示属性属于一对多映射，其属性名为Representation，数据类型为IfcProductRepresentation，对应的Java类的自定义属性名有多个，包括：体积属性名Volume，数据类型为double；长度属性名Length，数据类型为double；横截面尺寸属性名SectionB和SectionH，数据类型均为double。

1.4 IFC数据自动存取

经过上述数据解析与映射，IFC数据将暂存在Java对象中，可通过开源的对象关系映像框架Hibernate将Java对象数据进一步映射到MySQL数据库中，进而实现IFC数据在关系型数据库中的持久存储。仍以表 3中的IfcBeam实体为例，根据映射规则，IfcBeam实体映射为MySQL数据库中的IfcBeam表；Java类中自定义属性GlobalId在MySQL数据库IfcBeam表中对应的字段名为GlobalId，数据类型为varchar；Java类中自定义属性Volume在MySQL数据库IfcBeam表中对应的字段名为Volume，数据类型为double。本研究采用的Hibernate是一个全自动的Object Relational Mapping (ORM)框架，能够对连接Java和数据库的Java DataBase Connectivity (JDBC)进行封装，实现自动创建数据库表并生成SQL操作语句。

1.5 信息自动检索与处理

对于映射得到的MySQL关系型数据库，还应实现数据库的高效访问，即信息自动检索与处理。实际操作中通常需要返回大量数据并面向互联网传输，因此本研究在进行数据库输出时把相关属性封装在一个类中，序列化为JSON数据，实现同时返回多行数据，也便于后期进行网络数据交换。其操作过程如下：1)客户端向服务端请求数据查询接口，同时传递所查询构件的特征信息(如关键字段GlobalId)；2)服务端根据接收到的特征信息(如关键字段GlobalId)检索MySQL数据库，将查询到的构件数据转换为JSON数据并返回给客户端；3)客户端通过解析返回的JSON数据，获得构件的尺寸、位置、体积、方向等信息。

2 自动映射方法性能分析

为验证上述自动映射方法的有效性，下文通过一个实际工程项目的BIM数据，对比直接操作IFC数据和操作映射得到的关系型数据库在信息传递完整性和数据管理效率方面的差异。选择上述测试指标的原因是信息传递完整性保证了方法的可用性，而数据管理效率则体现其经济效益。

2.1 信息传递完整性对比

BIM实现有效信息传递的前提是保证信息传递的完整性。当前IFC数据是以IFC文件的形式存储，通过兼容IFC的建模软件(如Revit)将建筑模型导出为IFC文件，但此形式不便于直接和关系型数据库比较。考虑到Revit可以通过“导出—ODBC数据库—机器数据源—新建—用户数据源(系统数据源)—SQL Server Native Client—自定义名称和服务器—身份验证—选择数据库—选择账号—登录服务器—Revit导出数据”实现关系型数据库中IfcBeam表的自动导入，为更直观地比较，本研究对比Revit自动导出的IfcBeam表和利用本研究所提出方法映射得到的关系型数据库中IfcBeam表在包含属性上的差别，进而分析得到二者在信息传递完整性方面的差异，结果如表 4所示。由表 4可见，映射得到的关系型数据库中IfcBeam表所包含的信息更完整，新增Coordinates、Directions等十多种属性。根据下文提出的应用前景，这些新增的属性可用于智慧工地、支持自动化吊装等，比如可以根据构件的基本信息如Span、SectionB、SectionH、Weight和Coordinates等确定吊车选型，利用IsExternal和ContourVertex属性信息筛选吊臂长度。

2.2 数据管理效率

为验证所提出方法的映射效率能否满足实时性要求，本研究分别统计实现1、5、10、15和20万行IFC数据自动映射需要的时间，且为保证实验数据的可靠性，每个统计结果取10次测试结果的平均值，如表 5所示。实验环境为搭载Windows 10操作系统的个人计算机，配备Intel Core i7-6700K @ 4.00 GHz 4核处理器和32 GB内存。由表 5可见，对于10万行及以下数量级的IFC数据，其自动映射时间在2 min以内，可满足工程实时性需求。此外，数据库管理主要涉及数据的增删查改。工程实践中通常依靠应用软件对IFC实体对象进行增加和删除，而对IFC文件的数据操作主要是数据查询和修改。为比较上述两个方法在数据管理效率上的差异，本研究还进一步对比直接操作IFC文件和操作映射得到的关系型数据库对不同数量级IFC数据进行修改和查询的用时情况。

二者的数据查询效率对比结果如表 5所示。对于同一构件类型的数据(即同一张表上的数据)，表 5结果表明，虽然查询关系型数据库的首次用时高于直接查询IFC文件，但是查询关系型数据库的二次用时明显低于直接查询IFC文件。其原因在于关系型数据库首次查询后将同一构件类型的数据缓存于内存中，从而降低二次查询此类数据的耗时，且数据量越大，关系型数据库二次耗时的降低效果越显著；直接查询IFC文件则与此相反，每次都需要重新检索IFC文件，因此其首次用时和二次用时相差不大。实际工程应用中通常需要多次查询同一构件类型数据，因此使用关系型数据库的查询效率高于直接查询IFC文件。

二者的数据修改效率对比结果如表 6所示。修改关系型数据库的效率明显高于直接修改IFC文件，且随着构件数量从1万行增加到20万行，修改效率从186倍提升到429倍。这是由于IFC对象的属性修改后，需要更改整个文件的内容使修改生效，该过程相当于重写一次文件，所花费的时间长于修改关系型数据库，且随着数据量的增加，修改IFC文件所需的时间也增加。

3 应用前景分析

本研究提出的映射方法，不仅实现了IFC对象从IFC数据模型到关系型数据库模型的自动映射，还在一定程度上保证了信息传递的完整性，因此有潜力支持相关应用的二次开发。下面通过2个案例展示映射得到的关系型数据库的专业应用前景。

3.1 自动生成构件级进度计划

进度控制是工程项目管理三大控制之一，传统进度计划编制的基础是工作分解结构^[18]。由于IFC数据模型具有面向对象的特征，本文方法映射得到的关系型数据库是构件级的(见图 1)。在此基础上，自动生成进度计划需要进一步确定各构件的工作时间并增加工序约束。以某装配式框架结构项目为例，数据库中包含项目相关构件的基本信息，其吊装时间根据平均作业工效自动计算得到。系统确定构件吊装顺序的原则是：1)根据构件的标高自动确定其所在楼层，按所在楼层从低到高的顺序排列；2)对于在同一实际楼层内的构件，初始默认吊装顺序为柱－梁－板－楼梯－阳台，从而自动生成构件级进度计划，如图 2所示。

3.2 自动吊装对象智能识别

起重机是施工现场使用最广泛的设备之一^[19]，其作业自动化对于实现智能建造有重要意义，而吊装对象的自动识别是实现起重机自动化操作的前提。利用图像设备等采集构件信息是目前识别现场对象的常用手段，然而能够采集到的信息还非常有限，主要是构件的空间位置和颜色纹理信息。以移动式起重机的自动选型和定位为例，在潘在怡^[20]整理的约束基础上归纳出表 7所示的3个约束条件和对应的信息需求。但表 7中大部分信息无法直接通过传感器采集，需要从解析的BIM模型中获取或进行转换计算，比如构件质量可基于解析得到的材质信息和体积信息确定。为此，可以结合图像设备采集的构件特征信息和吊装构件基础数据库确定吊装对象，从而实现吊装构件的自动识别(见表 8)。从数据库中获得该构件的其他关键信息(如构件编码、质量、重心位置、安装位置等)，并在数据库中更新吊装构件的真实原始坐标，为下一步吊装路径自动规划作准备。

4 结论

本研究提出一种实现IFC数据模型到关系型数据库模型的自动映射方法，针对IFC模型元素建立从IFC到Java再到MySQL数据库的映射规则，从而实现建筑模型IFC数据到关系型数据库的自动映射，并结合实际工程的BIM数据，从数据完整性和数据管理效率2个方面对映射方法的成效进行了分析。在此基础上，进一步结合2个案例分析该映射方法得到的关系型数据库在施工阶段的专业应用前景。结果表明，本文方法不仅能够提高BIM数据管理的完整性和效率，还可促进智能建造的拓展应用和建筑业的信息化发展。具体如下：1)利用本文方法将IFC数据模型转换为关系型数据库模型后，信息更完整；2)所提出方法的映射效率满足工程实时性要求，关系型数据库的修改效率和综合查询效率都明显高于直接操作IFC文件的效率，且数据量越大，效率提升越显著；3)在映射得到的关系型数据库基础上进行二次开发，有潜力支持智能建造的拓展应用(如进度计划自动生成、吊装构件自动识别等)。

此外，本研究还存在一定的局限性。特别是在方法性能分析方面，仅考虑Revit导出的IFC文件及数据库表，没有考虑其他BIM软件导出的相关文件。在未来的研究中，将对此进行更为广泛的分析。

本文是在“2018年第4届全国BIM学术会议”上发表的《IFC数据到关系型数据库的自动映射方法研究》^[6]的扩展。