下载掌阅APP，畅读海量书库
立即打开
联邦数据库的概念是由Heimbigner与Mcleod于1985年提出的 [5] ，联邦数据库系统是由一些彼此相互协作而又相对独立的成员数据库组成，该系统对其成员数据库按不同程度进行集成，联邦数据库管理系统对整体提供控制和协作。每个成员数据库又可以加入多个不同的联邦数据库系统，集中式和分布式的存储模式都是允许的 [6] 。基于联邦数据系统的集成是一种相对较早的集成方法。
一种构建联邦数据库的方法是将各数据源的数据视图集成为全局模式，用户在访问各数据源的数据时能够透明地以全局模式进行。用户直接在全局模式的基础上提交请求，由数据集成系统处理这些请求，转换成各个数据源在本地数据视图基础上能够执行的请求。这种模式集成方法的特点是直接为用户提供透明的数据访问方法。该方法集成度较高，用户参与少，但缺点是构建一个全局数据模式的算法复杂，扩展性差。另一种是在联邦模式下，各数据源之间相互提供访问接口，分享数据。数据库提供本地使用的同时也参与联邦系统的运作。该方法集成度不高，但其数据源的自治性强、动态性好，且联邦数据库系统不需要维护一个全局模式。使用联邦数据库集成方法，当集成系统的数量和规模很大时，则面临着工作量极大的困境。
联邦数据库系统具有以下特点。
（1）联邦数据库系统具有分布性：系统中数据可以分布在多个成员数据库中，成员数据库可存储在单个或多个计算机系统中，也可以存储在同一地点或通信系统连接的多个地点。
（2）联邦数据库系统具有自治性：自治性体现在成员数据库管理系统能够独立地控制成员数据库，但其他的数据库可以共享其中的数据。当联邦数据库系统调用成员数据库中的数据时，成员数据库中数据不会被修改及移动。成员数据库系统进入或离开联邦数据库系统时，对成员数据库系统的一致性不会造成影响。
（3）联邦数据库系统具有异构性：由于各成员数据库都是独立设计的，成员数据库的实现技术（硬件、通讯系统等）不一致、语义不一致造成了成员数据库系统之间的异构。
（4）联邦数据库系统具有透明性：透明性体现在设计良好的联邦数据库系统会很好地屏蔽成员数据库系统之间的差异，使用户感觉到联邦数据库作为一个整体系统存在。
联邦数据库系统的中心问题是如何能够将分布异构的数据库系统透明地集成起来，在用户看来，其作为一个整体系统存在，同时，不影响每个成员的自治性。
基于中间件的数据集成是目前比较常用的数据集成方法。中间件在异构数据源和应用程序间，其作用在于协调下面的各数据源系统，并为应用程序访问集成数据提供了一个统一的数据模式和数据访问接口。中间件方法通过构造一个逻辑视图使得不同数据源之间能映射到这个中间层，中间件并不存储具体的数据，只存储所有数据的逻辑模式，且不改变数据源数据的存储和管理方式，对于数据源数量较大且数据频繁变化的集成环境较为适用。
中间件注重全局查询的处理和优化，与联邦数据库系统相比，其优势在于能够集成非数据库形式的数据源，且查询性能很好，自治性强；中间件的缺点在于它通常只具有读取数据源数据的能力，而联邦数据库对成员数据库的读写都支持。除用于数据集成的数据库中间件外，还有远程过程调用中间件、消息中间件、对象请求代理中间件以及事务处理中间件等 [7] 。
中间件为开发人员提供统一的开发环境，隐藏操作系统的异构性，使程序设计的复杂程度降低。开发人员不用再考虑程序在不同操作系统上的移植工作，可专注于解决业务问题，从而显著提高了效率 [8] 。应用中间件可以降低应用系统开发的复杂程度，缩短开发周期，并且减少了系统维护、运行和管理的工作量。此外，中间件还能使不同操作系统、不同数据库上开发的应用系统集成起来，成为一个整体。中间件的这一作用，使得在技术不断更新发展之后，以往应用软件上所做的工作仍然可用，从而节约了企业的投入。
“数据仓库之父”William H.Inmon对数据仓库进行了定义：数据仓库是一个面向主题的、集成的、时变的和非易失的数据集合，用以支持管理部门的决策 [9] 。
（ 1 ） 面向主题： 数据仓库中的数据组织是围绕某些特定的分析目标进行的，这些特定的分析目标称为主题，如销售、产品、顾客等。数据仓库不是将各种数据无序、随意进行存储的数据集合，而是为了分析的目标主题，可支持围绕主题的高效分析而组织起来的。数据仓库存储模型将根据决策者的分析需求而构建，对于决策支持无用的数据将被排除，目的是提供特定主题的简明分析视图。
（ 2 ） 集成的： 数据仓库中的数据是从原有的多个异构数据库中按照一定的主题和规则抽取出来的，通过数据清理、转换等步骤以及集成技术，使命名约定、结构、属性度量等具有一致性。
（ 3 ） 时变的： 数据仓库中存储的数据会随时间不断变化，含有大量与时间相关的综合数据。这就需要不断进行数据内容的更新，包括将新产生的数据存入以及旧的数据转出。
（ 4 ） 非易失的： 数据仓库在数据存储上总是以物理方式分开进行，这种存储上的分离，使得数据仓库不需要并发控制、恢复以及事务处理等数据库系统的机制。
数据仓库对多个异构数据源中的数据进行集成，经过数据抽取、转换、清洗、加载后的数据具有统一的存储结构及较高的数据质量，使查询、深层数据分析及挖掘可在统一高质量的数据环境下进行。分析及挖掘结果将用来辅助决策的制定。
尽管数据仓库查询效率较高，但它是通过牺牲存储空间而实现的，数据集成因集中复制数据而消耗大量的存储空间，而且只能定期更新数据，因此无法实时反映数据的变化，实时性差。
按照数据仓库的结构，可将数据仓库划分为企业级数据仓库和部门级的数据集市。
企业级的数据仓库顾名思义是汇总了整个企业的数据，对所有需要的数据按照主题进行数据集成，集成的数据既有细节数据也有汇总数据，能够为企业各部门提供决策支持，但一般构建企业级的数据仓库需要耗费多年的时间来构建和完善。
数据集市一般是针对企业某些特定主题而构建的，是部门级别的，有时也被称为部门级的数据仓库。数据集市分为两种类型，一种是从属数据集市，另一种为独立数据集市。从属数据集市是在企业已有数据仓库基础上针对某些主题而构建的，其目的是为频繁访问数据仓库的重要业务部门提供一个快速高效的查询分析机制，而且能够缓解中央数据仓库的压力。独立的数据集市数据直接来源于各操作型数据库系统，它的数据提取过程与建立一个企业的数据仓库基本一样，只不过数据集市构建针对特定的主题，但前期数据获取的复杂程度并没有比数据仓库降低多少。相对于企业数据仓库构建花费大、周期长的问题，数据集市更受到一些规模小的企业所青睐，节省了开发周期与投资。但从长远角度来看，企业发展到一定规模后，多个数据集市将导致信息孤岛问题，而利用数据仓库可以解决从整个企业视图来分析数据的问题。
为了给航站楼旅客流量预测、航班行李需处理求预测、航站楼旅客流量异常预警以及旅客服务资源配置及调度仿真优化提供有效的数据支持，航站楼旅客服务资源动态配置及调度数据集成必须满足下述要求。
航站楼在管理相关的各业务管理信息系统时，每时每刻都在处理大量的事务，在此过程中，需要频繁地对数据库进行插入、删除、修改等操作，航站楼旅客服务资源动态配置及调度。若直接访问业务数据库势必影响业务数据库的运行效率，并且，业务数据库中通常存放的是当前或近期的业务数据，而航站楼旅客服务资源动态配置及调度则需要使用大量的历史业务数据来对旅客流量、行李处理需求等进行分析和预测。因此，航站楼旅客服务资源动态配置及调度数据集成需要建立一个能够装载大量历史业务数据的独立存储系统。
能够为航站楼旅客服务资源动态配置及调度提供全方位的数据支持，具体包括：
（1）能够按照航班、航空公司以及航站楼为分时段的离港旅客流量预测、行李处理需求预测，以及旅客流量异常预警提供数据支持；
（2）能够为旅客服务资源配置及调度方案的空间查询和旅客服务资源配置及调度仿真的可视化提供可共享的空间数据支持；
（3）能够为航站楼旅客服务流程仿真建模及验证提供数据支持。
航站楼旅客服务资源动态配置及调度从不同角度、不同汇总级别对来自多个业务系统的数据进行分析，即多维、多粒度的数据分析，为旅客服务资源的配置和调度决策提供了参考依据。多维数据分析是同时将影响决策的多个方面的数据加入到分析中，多粒度的数据分析是在不同汇总级别上的数据分析，如半小时的值机旅客流量、某天的值机旅客数量等。航站楼旅客服务资源动态配置及调度数据集成要充分考虑可能的数据分析方法，在维度和粒度上尽可能满足各种数据分析方法的数据需求。
航站楼旅客服务资源动态配置及调度的目的是能根据预测的分时段的旅客到达航站楼的流量及托运行李的数量动态地改变服务资源的配置及调度。因此，航站楼旅客服务资源动态配置及调度数据集成必须满足旅客流量和行李处需求预测等应用程序对数据查询的响应速度的要求，确保预测的结果能够及时地提供给旅客服务流程仿真和优化程序，使数据集成、旅客流量及行李处理需求预测、旅客服务流程仿真优化成为一个有机的整体，以满足资源配置及调度的实时性要求。
为满足航站楼旅客服务资源动态配置及调度的数据需求，提出基于数据集市的航站楼旅客服务资源动态配置及调度的数据框架。其中，数据集成部分由数据源、数据抽取—转换—装载（ETL）、航站楼平面布局数据模型、旅客服务流程数据模型、旅客流量预测及异常预警数据集市、行李处理需求预测数据集市、航班延误空间分析数据集市组成，集成部分如图2-2中虚线框所示。集成后的数据将用来进行数据挖掘，数据挖掘的结果将提供给最终的资源动态分配。集成后的流程由联机分析挖掘（Online Analytical Mining—OLAM）、流程仿真优化以及最终的资源动态分配组成，整体框架如图2-2所示。
图2-2 航站楼旅客服务资源动态分配及智能化调度的整体数据框架
航站楼旅客服务资源动态配置及调度的数据源在本章2.1.3节已经进行了概括介绍，本节将进一步阐述每个数据源的用途。
航站楼平面布局设计文档通常以CAD文档的形式存在，这些CAD文档经过空间ETL，将其中的信息转换为能够表示航站楼平面布局的空间对象或空间对象的集合，之后再将这些空间对象或空间对象的集合与它们的属性数据关联（如值机队列的长度等），并在应用程序间共享，则可为航站楼旅客服务资源配置及调度提供基于空间对象的查询服务，也可为旅客服务流程仿真的可视化提供必要的空间数据支持。
旅客服务流程人工调查数据包括：旅客服务流程各功能单元的开始时刻、结束时刻、计数周期内完成的事务数量、处理每个事务的平均时间、各功能单元的资源配置和调度、各功能单元间的逻辑关系，以及各功能单元间的信息流等。这些数据为航站楼旅客服务流程建模、仿真及优化提供数据支持。
从航站楼管理相关的业务系统提取的数据主要用于航站楼旅客流量流预测及异常预警、行李处理需求预测、航班延误空间分析。
航班控制系统中包含所有航班的具体信息，对这些信息统计分析可获得某机场所有离港航班的信息（包含首发及中转的航班）信息，包括：航班所属航空公司、航班号、航班日期、目的机场航班计划登机时间、航班计划离港时间、航班实际离港时间、航班是否延误、航班延误原因以及首发或中转数字索引等信息。当然，也可获得到港航班的所有信息。
航班开始值机前的一定时间内，订票系统会将该航班旅客的有关信息发给值机系统，旅客值机时，值机时间、托运行李的数量等信息会补充到该系统的数据库中。旅客有关的信息包括：姓名、性别、证件号码、航班ID、舱位等级代码及大件行李数量、质量等。
从机场的气象数据库中可获得每日的气象数据和历史气象数据。主要包括：中低空重要天气预告，高空风及温度预告，特别是对航班起降有较大影响的天气，比如降雨、降雪、大雾、大风以及沙尘暴等的持续时间、范围及程度。
人数自动统计软件将对航站楼离港大厅及到港大厅的出入口的视频监控拍摄的旅客人数进行自动统计，此部分旅客不仅包含乘机的乘客，还包含接送旅客的亲友。利用该系统的数据可分时段统计旅客的流量，时间段的选择需与旅客流量预测及异常预警的时段相对应。
该部分数据包括节假日数据、各航空公司舱位等级对照表、航班目的地代码对照表等。节假日数据除包含有“五一”、“十一”及春节等法定假日的具体日期，还有寒、暑假的日期范围。这些信息对旅客流量预测及预警具有重要参考价值。
数据仓库或数据集市建设面临一个关键问题就是要将原先分散在各独立业务系统或其他来源的异构数据重新按照主题进行集成，这个过程通常是复杂和烦琐的，为此，ETL应运而生。目前，尚未形成一个统一的ETL定义，Panos Vassiliadis对ETL的理解是：ETL是一种专业化的工具，用来解决数据仓库同构性问题、完成数据清洗及数据装载任务 [10] 。
由于数据清洗也是利用多源异构数据构建数据仓库的一个重要步骤，所以也被归并到ETL中。由此，ETL可分为数据抽取、清洗、转换与装载4个步骤。数据抽取是从多个异构的数据源中将需要的数据抽取并存放在一个统一的存储中，是数据输入过程；数据清洗是将源数据中数据缺失、错误、冗余等数据质量问题进行更正，使数据能够满足数据分析和数据挖掘的需求；数据转换是将抽取的异构数据按照设定的规则转换成数据仓库要求的统一形式；数据装载是将清洗转换后的数据装载到目标数据仓库或集市中。
ETL是数据仓库或数据集市构建过程的第一步也是至关重要的一步，它执行的好坏决定数据仓库或数据集市能否获得高质量的数据 [11] 。调查结果显示，企业数据仓库构建过程中，ETL实施所花费的时间将占总时间80%以上 [12] ，在ETL工具采购上的投资将占数据仓库构建总投资的三分之一以上 [13] ，这足以看出ETL的重要程度。
数据抽取是从与旅客到达相关的5大类数据源中提取出挖掘预测需要的数据，比如离港系统数据库具有近50个属性字段，而需要抽取的只是其中的一部分。因此，在进行数据抽取之前需要对业务数据库字段的语义进行深入研究，以便于确定哪些数据是需要抽取的。
多数据源异构是数据抽取部分所面临的主要问题。多源异构主要表现为字段名称、类型及值域等的不同，目前应对的方法大多通过统一元数据来进行统一化管理。
此外，数据的更新频率也是数据抽取阶段需要考虑的问题。要设定好更新频率，将新的数据以增量方式抽取出来，以时间戳作为增量的表示，并最终装载到数据集市中。
数据清洗主要解决数据质量问题。业务数据库中经常存在大量不完整的、含噪声的、不一致的数据 [14] 。用于分析或挖掘的数据质量将影响数据分析或挖掘的效率以及分析或挖掘结果的准确性，甚至导致错误的数据分析或挖掘结果。因此，联机在线分析处理及数据挖掘要求数据是“干净”的，在数据分析或挖掘前，数据清洗是非常必要的，它可以为数据分析或挖掘提供正确、干净的数据。
数据清洗主要任务是去除不完整的、错误的、含噪声的以及重复的数据。在本章中，不完整的数据，如旅客值机时间值缺失；错误的数据，如错误的离港时间；重复的数据，如同一天内的同一航班有两条离港记录，等等。
数据转换主要包含不一致数据的转换、数据粒度转换、新字段的构建以及业务规则计算等几部分内容 [15] 。
不一致数据的转换包括统一字段名称，如不同关系表中航班ID字段的命名有所不同（如FLTID、FLT_ID、SEG_FLTID等），需要将这些字段与数据仓库中的航班ID字段相对应；不一致数据的转换还包括数据格式的转换，如将不同日期格式的数据在数据仓库中以统一的格式存储；此外，不一致数据的转换还包括将数量单位的转换等。
数据粒度的转换是由于业务系统中存储的数据粒度过细，而数据仓库、数据集市需要的是将最细粒度汇总、聚合后的数据这个原因产生的，如旅客订票、值机数据库中的数据是关于每名旅客的，而数据仓库和数据集市关心的是每个航班、每段时间间隔的旅客人数，因此，要进行数据粒度的转换。
新字段的构建是在已有字段无法满足数据分析的需求时，在数据仓库中创建新的字段，如基于旅客值机时间及航班离港时间而建立的旅客提前到达时长字段等。
有时，指标值要经过复杂的逻辑计算，如将不同部门的计算规则统一，就涉及业务规则的计算。
数据装载是将抽取的数据经清洗和转换后，按照逻辑模型定义的表结构装入目标数据仓库或集市中。数据装载过程中，允许人工干预，并需要强大的系统日志、错误报告以及数据备份与恢复功能的支持。一般来说，数据仓库或数据集市的装载操作都是按确定的周期进行的。
航站楼平面布局数据模型是采用面向对象的建模方法，将航站楼平面布局设计文档中值机柜台、安检通道等对象类，抽象为地理空间数据库（Geodatabase）的要素类。利用该模型可将航站楼平面布局信息保存于地理空间数据库中，以便于航站楼平面布局信息在应用程序间共享。
首先，对实际获取的航站楼平面布局设计CAD文档（如图2-3所示）的注记内容进行整理，整理出航站楼内与旅客服务资源相关的所有空间对象类。
图2-3 航站楼平面布局CAD文档示例
以航站楼离港服务的设施、用房为例，整理出的空间对象类包括：①IDF，②安检信息监控机房（UPS），③安检机房，④安检通道，⑤安检用房，⑥办案室，⑦办公，⑧乘机手续办理、人工值机柜台，⑨问询、票务，⑩扣留物品保管仓库，
报关间，
爆炸物检查仪，
备餐，
哺乳间，
餐饮，
操作间，
查验处理室，
打包区，
大件行李，
档案室，登机口，
电梯，
毒品检查室，
风井，
服务间，
更衣休息，
工作通道，
公安用房，
广播，
贵宾，
海关办公，
国内中转，
行政案件处理室，
航站楼管理，
航站楼维修，
红色通道，
安检等候厅，
缉私警察，
急救室，
交通工具办理手续，
接种准备观察，
卡片存放，
卡证，
开包间，
开水间，
库房，
垃圾货物通道，
临时审查，
楼梯，
绿色通道，
母婴室，
排查留验，
派出所，
配电，
前室，
清洁间，
人身检查室，
人员扣留，
商业，
视频监控、机房，
搜身，
提示牌，
填单台，
头等舱候机室，
外事会晤，
卫生间，
问询中心，
物品扣留，
吸烟室，
洗消间，
现场备勤，
值班，
验讫章，
药品库，
业务用房，
液体检查仪，
医学检查，
音像制品审查，
银行，
应急处理室，
应急物资准备，
有偿服务，
预防接种，
证件鉴定，
中转休息室，
座椅，
值机用房，
自助值机，
国际中转，
行李寄存，
个别未命名用房，
航站楼轮廓。
然后，将上述的每一个对象类，对应到地理空间数据库Geodatabase的要素类，利用统一建模语言（United Modeling Language-UML）对要素类进行描述。Geodatabase模型构件与UML模型构件之间的对应关系如图2-4所示。
图2-4 Geodatabase模型构件与UML模型构件
以某航站楼二层离港区域为例，空间对象类包括：①国际候机厅，②国际离港安检，③边检，④海关，⑤卫检，⑥可转换航班候机楼，⑦国内候机厅，⑧国内离港安检，⑨航站楼办公区，⑩办理乘机手续、值机区，
公共设施区。利用UML描述的海关区Geodatabase空间数据模型如图2-5所示。
图2-5 海关区UML模型
最后，根据建立的航站楼平面布局数据模型，通过空间数据ETL过程，将航站楼平面布局设计文档中与旅客服务资源有关的空间对象装载到Geodatabase数据库，具体过程参见本章2.6.2节。
旅客服务流程数据模型使用关系模式描述旅客服务流程的视图，包括：
控制视图： 旅客服务流程间（或流程内部各活动间）的层次关系、顺序关系、分支关系和循环关系；
信息视图： 流程间或流程内活动间的信息的流向和内容；
组织视图： 参与活动的组织；
资源视图： 执行活动所需的资源，即活动的资源配置及调度；
基于旅客服务流程数据模型建立的数据库系统，可以将旅客服务流程的相关数据在应用程序间共享，为旅客服务资源的配置及调度的仿真优化提供数据支持。表2-1和表2-2分别是描述活动的关系模式和描述活动的执行顺序的关系模式。
表2-1 活动表
表2-2 活动的执行顺序表
数据集市是针对某个具有战略意义的应用或者某个具体部门建立的，具有一个或几个特定主题，用来支持用户利用已有的业务数据获得重要的竞争优势，或者找到进入新市场的具体解决方案 [16] 。航站楼旅客服务资源动态配置及调度数据集市用来为航站楼旅客流量预测及预警、航班行李处理需求预测以及航班延误空间分析提供数据支持，数据分析和数据挖掘可以根据需要选取不同的维度、粒度进行数据聚合，实现不同抽象级别的数据挖掘。
数据集市的逻辑结构可通过多维数据模型来定义。多维数据模型，也称“数据立方体”，由维表和事实表组成。事实表中包含事实的名称、度量和每个与事实表相关的维表的主键，度量通常是数值数据。与事实表相关的维是观察数据的特定角度，如对航站楼每小时客流量进行观察，时间就是一个维度。一个事实表通常有多个相关维，多维数据模型是OLAM的基础，它通过不同维度和不同粒度级别对度量进行不同细节的分析，同时，还具有结构简单、用户易于理解和使用、查询效率高等优点。
OLAM是OLAP与数据挖掘的有机结合。一方面，OLAM可在多维数据模型的基础上，根据需要选取维度指标进行预计算聚合，提高了查询响应速度；另一方面，OLAM可根据需要灵活选择或添加挖掘算法及可视化工具，为用户动态更换挖掘任务提供了灵活性 [17] 。
OLAM的核心是以“数据立方体”为基础的数据挖掘方法。OLAM要求数据立方体具有非传统的动态计算复杂维度和度量的能力 [18] 。由于OLAM需要计算多维之间的关系或维度的细节，这样的数据不可能都预先实体化。因此，需要联机动态计算“数据立方体”的一个或几个部分。
OLAM能够充分发挥OLAP和数据挖掘的优势。数据挖掘的结果通常很难完全满足用户预期的要求，用户在看到阶段性的挖掘成果之前根本不知道他想要挖掘哪种类型的知识，但是通过将数据挖掘与OLAP结合，用户可以参与到数据挖掘的过程中来，动态地提出数据挖掘需求，灵活快捷地选择挖掘工具。
为了支持OLAM，航站楼旅客服务资源动态配置及调度数据集市的多维数据模型必须考虑所有可能用到的数据挖掘算法的数据需求。