system: [SYSTEM]

user: 2. 例子 结合实际的房地产项目数据，具体考虑如下几个Web源数据和目标数据表格，表1~表3代表由非专家用户提供的源范例元组，同理表4和表5代表目标范例元组。 针对以上范例元组，对于房地产领域的数据分析师用户而言他们很容易会想到的初始映射规则集M如下： LAT(Idin 1 ， Idin 2 ， Idli) Ù LT(Idli， Name， L) ÙDT(Idk 1 ， Name'， L) Ù BT(Idin 1 ， St 1 ， L， Idk 1 ) ÙBT(Idin 2 ， St 2 ， L'， Idk 1 ) → $idS 0 ， idS 1 ， idS 3 ， idS 2 ， idS 4 : T3(idS 0 ， Name， L) ÙT1(St 1 ， Idin 1 ， idS 1 ) Ù T3(idS 1 ， Name'， L) ÙT2(L， Idin 1 ， idS 3 ) Ù T3(idS 3 ， Name'， L) ÙT1(St 2 ， Idin 2 ， idS 2 ) Ù T3(idS 2 ， Name'， L) ÙT2(L'， Idin 2 ， idS 4 ) Ù T3(idS 4 ， Name'， L) Table 1 Source instance E LAT (License Association Table) LT (License Table) Ldnum Zdnum Idlicense Idlicense Name Location 楼栋号 宗地号 许可证号 许可证号 楼盘名称 项目所在地 1Z# 2016-001 16357 16357 万科金地中山公园 沈阳市和平区 表1. 源实例E S Table 2 Source instance E DT (Developer Table) Iddeveloper Name Location 开发商编号 开发商名称 总部地址 K1 沈阳万科中山置业有限公司 沈阳市和平区 表2. 源实例E S Table 3 Source instance E BT (Building Parcel Association Table) Idinformation State Position Iddeveloper 编号信息 状态 位置 开发商编号 1Z# 已发证 沈阳市和平区 K1 2016-001 已出让 和平区水上运动学校 K1 表3. 源实例E S Table 4 Target instance E T1 (State Table) T2 (Address Table) State Idinformation Id Location Idinformation Id 状态 编号信息 开发商编号 地址信息 编号信息 开发商编号 已发证 1Z# a1 沈阳市和平区 1Z# a3 已出让 2016-001 a2 和平区水上运动学校 2016-001 a4 表4. 目标实例E T Table 5 Target instance E T3 (Developer License Association Table) Id Name Location 编号 名称信息 地址信息 a0 万科金地中山公园 沈阳市和平区 a1 沈阳万科中山置业有限公司 沈阳市和平区 a2 沈阳万科中山置业有限公司 沈阳市和平区 a3 沈阳万科中山置业有限公司 沈阳市和平区 a4 沈阳万科中山置业有限公司 沈阳市和平区 表5. 目标实例E T 首先通过以上的映射场景，我们可以观察到用户提供的范例元组可能没有被很好地选择，甚至与用户所想的映射M不一致。此外，用户提供的范例元组往往也不会是需要推断的映射规则集的解决方案或通用解决方案。在文献 [ 16 ] 的开创性工作的基础之上，学者们开始广泛研究关于映射规则集的生成和优化的问题例如文献 [ 17 ] [ 18 ]，但以上文献都假设了非常复杂的输入或更复杂的用户交互，显然这些文献里面的研究成果有待进一步改进。另外虽然本文中的目标元组回忆了数据实例，但它们与以上文献里面的实例相比，根本不同在于本文给出的目标解决方案并不是通用解决方案。 其次以上示例演示了本文部分的运行场景，其中一个非专业用户需要在显示城市房地产信息的两个数据库之间建立映射。源数据库模式由License Association Table、License Table、Developer Table和Building Parcel Association Table (分别缩写为LAT、LT、DT和BT)四个关系表组成，目标数据库模式由State Table、Address Table、Developer License Association Table (分别抽象为T1、T2、T3和T4)三个关系表组成。以上示例中用户为源和目标数据库提供的范例元组又可分别记为E S 和E T 。 通过以上示例我们还可以观察到每个表所包含的元组数量都非常少，且用户并不打算提供完整的实例，而只是提供一小组具有代表性的元组。我们也可以很容易地观察到以上示例元组中的一些固有的歧义，比如常量沈阳市和平区既代表预售许可表项目地址(在关系LT中)，也代表具体的楼栋地址(在相应的关系BT中)，此外以上示例中的具体楼栋地址和宗地地址恰好与开发商总部的地址在同一城市的同一个行政区。如果我们将这些示例元组视为基础事实，我们将会把它们翻译为如上所示的映射规则集M。然而，这样的映射并没有很好地解释范例元组，因为首先它假设所有的解决方案都必须包含同一家房地产开发商，且此开发商的总部地址与所开发的楼盘的详细楼栋地址和其所获得的宗地地址恰好与位于同一个城市。其次是预售楼盘的项目地址必须和地产开发公司的总部在同一城市的同一行政区。因此，从逻辑的角度来看，这样的映射方式太过于具体。此外，这种映射在真实的映射场景中可能会非常庞大并且不利于后续映射设计人员理解，因为它完全嵌入了所有的范例元组正如前文所说，我们的映射规范过程是建立在最终用户示例元组之上，这就可能导致我们设计的映射规则集不能够很好的解释原始数据。因此，本文的研究目的旨在构建一个能够为非专家用户提供映射规则集设计服务的通用框架系统，同时将以上由非专家用户提供的初始范例元组抽象为形如(E S ， E T )这样的输入对作为系统的输入，则交互式映射规范问题就是通过与用户进行布尔交互来发现映射M'，使得(E S ， E T )满足M'并且M'逻辑蕴含M，并最终导出更小的或者更加接近用户心目中的可控的映射规则集。本文的主要贡献总结如下： 1) 映射通常在企业IT和其他一些领域例如数据架构师(也称为工程映射的开发人员)中被指定和测试。本文仔细分析了以往用于帮助工程映射人员设计映射规则的一些范例通过大量的文献查阅发现其中的不足之处，在借鉴别人的研究方法的基础上提出了一个更适用于非专家用户的模式映射规范设计框架系统，并适用于一般的GLAV [ 19 ] 映射。其中每优化一条映射规则，系统都会就布尔查询问题自动的与用户进行交互。 2) 经过本文方法(即初始规则预处理、原子优化、连接优化)处理后所生成的映射具有不可约的右边。再结合冗余映射消除这就保证了经过优化后的映射是标准形式的映射 [ 20 ]。直观地说就是与庞大的初始映射规则集相比，优化后的映射规则对于非专家用户来说更容易理解。 3) 本文提出并实验测量了与可能映射空间相对应的类树形结构的两种映射空间探索策略(即自上而下探索策略和自下而上探索策略)，并最终确定了自上而下的探索策略的效率比自下而上的探索策略效率高。 4) 结合具体的项目在实际的地产数据集上进行了实验，验证了本文方法的可行性。