1.1 传统数据集成
数据集成的目标是为多个自治数据源中的数据提供统一的存取。这一目标说起来容易，但实现起来已被证明异常困难，即使是针对少量几个结构化数据源，即传统的数据集成[Doan et al. 2012]。
为了理解数据集成中一些挑战性的问题，这里用一个航空领域的例子来说明。该领域的常见任务是跟踪航班的起飞和降落，检查航班时刻表以及预定航班等。
1.1.1 航班示例：数据源
我们有一些不同类型的数据源，包括：两个航空公司数据源Airline1和Airline2（如美国联合航空公司、美国航空公司、达美等），分别提供自家航空公司航班的信息；一个机场数据源Airport3，提供在某机场（如EWR、SFO）出发和到达航班的信息；以及一个旅行数据源Airfare4（如Kayak、Orbitz等），提供不同航班不同价位的票价信息；还有一个信息类数据源Airinfo5（如Wikipedia table），提供有关机场和航空公司的数据。
各数据源的样例数据如表1-1~表1-8所示。为简便起见，表中使用缩写的属性名，属性名的缩写和全称的对应关系见表1-9。下面解释各表的具体内容。
1．数据源Airline1
数据源Airline1提供两张关系表Airline1.Schedule（Flight Id, Flight Number, Start Date, End Date, Departure Time, Departure Airport, Arrival Time, Arrival Airport）和Airline1.Flight（Flight Id, Departure Date, Departure Time, Departure Gate, Arrival Date, Arrival Time, Arrival Gate, Plane Id）。加下划线的属性构成相应表的主键。Flight Id被用作两张表的连接键。
关系表Airline1.Schedule如表1-1所示，显示了航班的时间计划表。例如，Airline1.Schedule中的记录r11说明Airline1航空公司的49号航班在2013-10-01到2014-03-31期间，固定从EWR飞往SFO，起飞时间18:05，到达时间21:10。记录r12显示同一航班在2014-04-01到2014-09-30期间安排了另外的起飞降落时间。记录r13和r14分别显示了55号航班在2013-10-01到2014-09-30期间两个飞行段的安排，第一段从ORD飞到BOS，第二段从BOS飞到EWR。
关系表Airline1.Flight如表1-2所示，显示了Airline1.Schedule中航班的实际起飞和到达信息。例如，Airline1.Flight中的r21记录了对应于r11（FI等于123，为两者的连接键）的航班的一次具体的飞行，即PI（飞机号）为4013的飞机，实际于2013-12-21的18:45（比计划的时间18:05晚40分钟）从C98登机口起飞，并于2013-12-21的21:30（比计划的时间21：10晚20分钟）降落在81号登机口。记录r11和r21都用浅灰高亮显示以表示它们的关系。同一张表中的记录r22记录了航班r11的另外一次实际飞行，比计划的起飞降落时间有更大的延迟。记录r23和r24记录的是2013-12-29航班r13和r14的飞行信息。
2．数据源Airline2
数据源Airline2提供的信息类似于数据源Airline1，但是使用的是关系表Airline2.Flight（Flight Number, Departure Airport, Scheduled Departure Date, Scheduled Departure Time, Actual Departure Time, Arrival Airport, Scheduled Arrival Date, Scheduled Arrival Time, Actual Arrival Time）。
关系表Airline2.Flight如表1-3所示，包含计划的和实际的航班信息。例如，记录r31记录了Airline2航空公司的53号航班计划2013-12-21的15:30从SFO起飞，但实际延迟30分钟，计划2013-12-21的23:35抵达EWR，但实际晚点了40分钟，第二天（表中显示+1d）即2013-12-22到达。注意表中有一条关于Airline2航空公司49号航班的记录r35，它不同于Ailine1航空公司的49号航班。这表明不同航空公司可以使用相同的航班号。
不同于数据源Airline1，数据源Airline2没有发布出发登机口和到达登机口以及飞机号。这表明这些数据源的模式之间是有差异的。
3．数据源Airport3
数据源Airport3提供两张关系表Airport3.Departures（Air Line, Flight Number, Scheduled, Actual, Gate Time, Takeoff Time, Terminal, Gate, Runway）和Airport3.Arrivals（Air Line, Flight Number, Scheduled, Actual, Gate Time, Landing Time, Terminal, Gate, Runway）。
关系表Airport3.Departures如表1-4所示，仅发布了从EWR机场起飞的航班。例如，表中的记录r41记录了Airline1航空公司的49号航班，计划在2013-12-21的18:45从航站楼C的98号登机口出发，18:53从跑道2起飞。表中没有该航班的到达机场、到达日期和时间的信息。注意r41对应于记录r11和r21，同样用浅灰高亮显示。
关系表Airport3.Arrivals如表1-5所示，仅发布了到达EWR机场的航班。例如，表中的记录r51记录了Airline2航空公司的53号航班，计划2013-12-21到达，实际2013-12-22到达，于00:15在跑道2降落，00:21抵达航站楼B的53号登机口。表中没有该航班的出发机场、出发日期和时间。注意r51对应于记录r31。
不同于数据源Airline1和Airline2，数据源Airport3区分开航班离开/到达登机口的时间和在机场跑道上起飞/降落的时间。
4．数据源Airfare4
旅行数据源Airfare4发布对不同航空公司售票信息的比较，包括航班的时间计划Airfare4.Flight（Flight Id, Flight Number, Departure Airport, Departure Date, Departure Time, Arrival Airport, Arrival Time）以及机票价格Airfare4.Fares（Flight Id, Fare Class, Fare）。Flight Id被用作两表的连接键。
例如，如表1-6所示，Airfare4.Flight中的记录r61显示Airline1航空公司的航班A1-49计划于2013-12-21的18:05从Newark Liberty机场出发，并于当天的21:10抵达San Franciso机场。注意r61对应于记录r11、r21和r41。
关系表Airfare4.Fares中的记录如表1-7所示，给出了该航班的各类票价。例如，记录r71显示该航班的A类票价是$5799.00；FI456是连接键。
5．数据源Airinfo5
数据源Airinfo5发布的是关于机场和航空公司的信息，即关系表Airinfo5.AirportCodes（Airport Code, Airport Name）和Airinfo5.AirlineCodes（Air Line Code, Air Line Name）。
例如，如表1-8所示，Airinfo5.AirportCodes中的记录r81显示代号为EWR的机场是美国新泽西州的Newark Liberty机场。类似地，Airinfo5.AirlineCodes的记录r91显示代号为A1的航空公司是Airline1航空公司。
1.1.2 航班示例：数据集成
虽然5个数据源单独都是有用的，但当它们被集成在一起时，这些数据的价值将被大大提升。
1．集成数据源
首先，每个航空公司数据源（如Airline1、Airline2）都从与机场数据源Airport3的链接中获益，因为机场数据源提供了航班实际出发和到达的详细信息，如登机时间、起飞降落的时间和使用的跑道；这些可以帮助航空公司更好地分析航班延误的原因。其次，机场数据源Airport3也可以从与航空公司数据源（如Airline1、Airline2）的链接中获益，因为航空公司数据源提供了关于航班时刻表和整体飞行计划的详细信息（尤其是对那些多段飞行的航班，如Airline1的55号航班）；这些可以帮助机场更好地理解航班的飞行模式。第三，旅行数据源Airfare4可以通过链接航空公司数据源和机场数据源提供一些附加信息，例如历史上准点起飞/到达的统计数据等；而这些信息对预定航班的用户可能非常有用。这种关联使得信息源Airinfo5非常关键。这一点我们在后面会看到。最后，将所有这些不同数据源集成起来也会使用户获益，因为他们不需要分别去访问多个数据源才能获得自己想要的信息。
例如，查询“计算出上个月每个航班的计划和实际出发时间之间的平均延迟，以及实际登机和起飞时间之间的平均延迟”可以在集成起来的数据库上作答，却无法用任一单个的数据源回答。
然而，集成多个自治的数据源非常困难，经常需要大量人工的努力去理解每个数据源的数据语义以解决歧义性问题。让我们再一次看一下航班的示例。
2．语义歧义性
为了正确对齐各种数据源表，我们需要理解：i）同一概念信息在不同数据源中的表示可能非常不同；ii）不同概念信息在不同数据源中的表示可能很相似。
例如，数据源Airline1在表Airline1.Schedule中给出在一定日期范围内（由Start Date和End Date所指定）的航班时刻表，使用属性Departure Time和Arrival Time记录时间信息。然而，数据源Airline2在表Airline2.Flight中一起给出了航班时刻表和实际航班的飞行信息，每次不同的飞行用不同的记录描述，并且使用不同的属性名称，Scheduled Departure Date，Scheduled Departure Time，Scheduled Arrival Date，Scheduled Arrival Time。
又如，数据源Airport3既记录了航班的实际登机口出发/到达时间（表Airport3.Departures和表Airport3.Arrivals中的Gate Time），也记录了实际起飞/降落时间（表Airport3.Departures中的Takeoff Time和表Airport3.Arrivals中的Landing Time）。而Airline1和Airline2数据源只记录其中一种时间，具体地，仔细检查数据就会发现，数据源Airline1记录的是登机口出发/到达时间（表Airline1.Schedule和Airline1.Flight中的Departure Time和Arrival Time），而Airline2记录的是起飞/降落时间（表Airline2.Flight中的Scheduled Departure Time，Actual Departure Time，Scheduled Arrival Time，Actual Arrival Time）。
不同的概念信息表示得很相似，如属性Departure Date在数据源Airline1中表示实际出发日期（在表Airline1.Flight中），但是在数据源Airfare4中表示计划的出发日期（在表Airfare4.Flight中）。
3．实例表示歧义性
要将来自多个数据源的同一个数据实例关联在一起，我们需要意识到由于数据源的自治性，这些数据实例具有不同的表示形式。
例如，航班号在数据源Airline1和Airline2中被表示为数字（例如，r11中的49，r31中的53），在数据源Airfare4中被表示为数字和字母的组合（如，r61中的A1-49）。类似地，出发和到达机场在数据源Airline1和Airline2中被表示为三字母的编码（如EWR、SFO、LAX），但在Airfare4.Flight表中被表示为一个描述性的字符串（如Newark Liberty，San Francisco）。由于航班是由属性组合（Airline, Flight Number, Departure Airport, Departure Date）所唯一标识的，如果没有另外一张表（例如表1-8中的Airinfo5.AirlineCodes和Airinfo5.AirportCodes表）将航空公司编码和机场编码分别和它们描述性的名字对应起来的话，表Airline4.Flight中的数据将无法和Airline1、Airline2和Airline3中的相应数据关联起来。即使有这样的对应表，我们仍然需要使用近似字符串匹配的技术 [Hadjieleftheriou and Srivastava 2011]将Airfare4.Flight中的Newark Liberty匹配到Airinfo5.AirportCodes表中的Newark Liberty, NJ, US。
4．数据不一致性
为了融合来自不同数据源的数据，我们需要解决实例级的歧义性和数据源之间的不一致性。
例如，Airline2.Flight中的r32和Airport3.Arrivals中的r52存在着不一致（两者被高亮显示为蓝色以表明它们指的是同一航班）。r32表示Airline2航空公司的53号航班的原定到达日期和实际到达时间分别是2013-12-22和00:30，即实际到达日期和原定到达日期是同一天（不同于r31，其实际到达时间包含了（+1d），表明实际到达日期比原定到达日期晚一天）。然而，r52则记录了此航班的实际到达时间是2013-12-23的00:30。在集成的数据里，需要解决这样的不一致性。
另一个例子，Airfare4.Flight中的r62表示Airline1的49号航班在2014-04-05原定的出发和到达时间分别是18:05和21:10。虽然出发日期和Airline1.Schedule中的r12一致（r12和r62被高亮显示为绿色来表示它们之间的这种关系），但是原定的出发和到达时间却不一致，也许因为r62错误地使用了Airline1.Schedule中的r11中给出的过去的出发和到达时间。类似地，Airfare4.Flight中的r65表示Airline2的53号航班在2014-06-28原定的出发和到达时间分别是15:30和23:35。虽然出发日期和Airline2.Flight中的r33一致（r65和r33都被高亮显示为黄绿色以表明它们之间的关系），但是原定的出发和到达时间却不一致，也许因为r65错误地使用了Airline2.Flight中的r32给出的过去的出发和到达时间。再一次表明，这些不一致性在集成起来的数据里需要被解决。
1.1.3 数据集成：体系结构和三个主要步骤
传统数据集成的方法解决语义歧义性、实例表示歧义性和数据不一致性带来的挑战时使用的是一种流水线体系结构，主要包含三个步骤，如图1-1所示。
传统数据集成中的第一个主要步骤是模式对齐。它主要针对的是语义歧义性带来的问题，目标是理解哪些属性具有相同的含义而哪些属性的含义不同。其正式的定义如下。
给定某一领域内的一组数据源模式，不同的模式用不同的方式描述该领域。模式对齐步骤生成以下三种输出。
1）中间模式。它为不同数据源提供一个统一的视图，并描述了给定领域的突出方面。
2）属性匹配。它将每个源模式中的属性匹配到中间模式的相应属性。
3）模式映射。每个源模式和中间模式之间的映射用来说明数据源的内容和中间数据的内容之间的语义关系。
结果模式映射被用来在查询问答中将一个用户查询重新表达成一组底层数据源上的查询。
种种原因使得这一步并不简单。不同数据源可以用非常不同的模式描述同一领域，如前面的航班例子。他们可以用不同的属性名来描述同一属性（如Airline1.Flight中的Arrival Date、Airline2.Flight中的Actual Arrival Date以及Airport3.Arrivals中的Actual）。另外，数据源也会用相同的名字表示不同含义的属性（如Airport3.Departures中的Actual指的是实际出发日期，而Airport3.Arrivals中的Actual指的是实际到达日期）。
传统数据集成中的第二个主要步骤是记录链接。它主要针对的是实例表示歧义性所造成的问题，目标是理解哪些记录表示相同的实体而哪些不是。其正式的定义如下。
给定一组数据源，每个包含了定义在一组属性上的一组记录。记录链接是计算出记录集上的一个划分，使得每个划分类包含描述同一实体的记录。
即使已经完成了模式对齐，记录链接仍然很有挑战。不同的数据源会用不同的方式描述同一实体。例如，Airline1.Schedule中的r11和Airline1.Flight中的r21应该被链接到Airport3.Departures中的r41；然而，r11和r21没有显式地提到航空公司的名字，而r41没有显式地给出起飞机场，而要唯一确定一个航班，这两种信息都需要。另外，不同数据源可能使用不同的形式表示相同的信息（例如前面例子中讨论的表示机场的各种方式）。最后，在数百亿条记录中使用两两比较的方法来判定两条记录是否描述同一实体的方法是不可行的。
传统数据集成中的第三个主要步骤是数据融合。它主要针对的是数据质量带来的挑战，目标是理解在数据源提供相互冲突的数据值时在集成起来的数据中应该使用哪个值。其正式的定义如下。
给定一组数据项，以及为其中一些数据项提供值的一组数据源。数据融合决定每个数据项正确的值。
许多种原因都可能造成数据冲突，如输入错误、计算错误（例如，r32和r52的实际到达日期之间的不一致）、过时的信息（例如，r12和r62的原定出发和到达时间之间的不一致）等。
我们将在后面的章节逐一介绍每一步骤中所使用的各种方法。下面我们继续讨论当数据集成从传统数据集成演化到大数据集成时所带来的挑战和机遇。