1 引 言

    传统的数据库技术是单一的数据库资源，即以数据库为中心，进行从事务处理、批处理到决策分析等各种类型的数据处理工作。

    近年来，计算机技术正在向着两个不同的方向拓展：一是广度计算，二是深度计算。广度计算的含义是把计算机的应用范围尽量扩大，同时实现广泛的数据交流，互联网就是广度计算的特征。深度计算是人们对以往计算机的简单的数据操作。目前对深度操作已提出了更高的要求，希望计算机能够更多地参与数据分析与决策制定等领域。数据仓库的出现，将操作型环境和分析型环境进行了分离，划清了数据处理的分析型环境与操作型环境之间的界限，从而由原来的以单一数据库为中心的数据环境发展为以数据仓库为中心的一种新的体系化环境。

    数据仓库技术以改进后的数据库技术作为存储数据和管理资源的基本手段，以统计分析技术作为分析数据和提取信息的有效方法，通过人工智能、神经网络、知识推理等数据挖掘方法发现数据背后隐藏的规律，从而实现从“数据→信息→知识”的过程，为企业的管理阶层提供各种层次的决策支持。

    呼叫中心作为提高服务质量的有效手段，已经在各个电信运营商得到了广泛的应用，随着呼叫中心的发展其数据呈现出爆炸性增长的趋势，但是数据管理的手段还远远没有跟上呼叫中心发展的脚步，很多有价值的数据就淹没在数据的增长中。为了缓解这一状况，我们将数据仓库技术引入到呼叫中心领域，为呼叫中心运营商提供全套的解决方案。用数据仓库来保存海量数据，用联机分析处理和数据挖掘技术来多角度的分析数据，发掘以往用户不能直接看到的数据，发现长期稳定的趋势，帮助用户决策，从而提高呼叫中心的服务水平和使用效率，帮助运营商提供市场竞争力，同时为呼叫中心提供更广阔的发展空间，让呼叫中心跨出电信企业的门槛，进入各家大企业。

2 呼叫中心数据仓库的构建

    2.1 呼叫中心分析主题的确定

    数据仓库是按主题组织的，根据现有呼叫中心业务，可以确立如下的分析主题：

    1)呼叫平台运营情况分析：包括系统接入话务量分析、系统服务质量和处理能力分析、系统呼出话务量分析、话务员工作情况分析和客户呼叫行为分析。

    2)业务情况分析：包括电子工作流分析、来电原因分析、自动业务分析、话务员质检分析。

    3)外呼业务数据分析：包括电话销售和电话调查。

    2.2 呼叫中心数据仓库的设计

    2.2.1 呼叫中心数据仓库系统的体系结构和系统结构

    呼叫中心数据仓库解决方案体系结构如图1所示。整个系统包括三大部分：数据源、中央数据仓库和应用系统部分。
 

图1 呼叫中心数据仓库系统体系结构图

    呼叫中心的数据库选择SQL SERVER 2000，其系统结构如图2所示。
 

图2 呼叫中心数据仓库系统系统结构图

    2.2.2 系统的逻辑模型设计

    以与呼叫平台运营情况相关的分析主题为例，按照维度建模的规则，为这些主题建立逻辑模型。根据维表的特点，模型设计成星型结构。

    系统的逻辑模型主要包括：

    1)系统接入话务量分析主题逻辑模型；
    2)系统服务质量和处理能力分析主题逻辑模型；
    3)系统呼出话务置分析主题逻辑模型；
    4)作情况分析主题逻辑模型；
    5)叫行为分析主题逻辑模型。

    2.2.3 ETL模块的设计

    ETL是数据仓库构建以及运行中相当重要的一个部分，它直接影响着数据的正确性以及分析的时效性。

    在数据仓库的构建阶段，需要通过ETL过程将原来的业务数据抽取到数据仓库中，这个过程相当于数据仓库的初始化，通常是相当耗时的，当数据仓库真正运行起来之后，系统通过ETL过程定期的将业务系统中的更新的数据转移到数据仓库中，以保证分析的时效性，这个过程虽然数据量相对于数据仓库初始化来说要小得多，但是，由于此时分析系统已经上线运行，所以它的抽取周期以及抽取策略需要精心的设计，否则将会消耗过多的系统资源，从而影响前端的响应。图3为ETL的处理流程。
 

图3 ETL模块的处理流程

    该ETL模块主要实现两个功能。

    1)定时将业务数据和话单文件中相关的数据导入分析系统的临时数据库，并同时导入细节数据库，临时数据库用于计算综合数据并实现增量数据的自动导入。

    2)定时调用后台存储过程，将临时数据库中的数据按分析主题的要求进行整理，综合，然后转入后台的数据仓库。
3 检度的确定

    按数据来源来分，我们可以将分析主题分成两大类，一是与呼叫相关的分析，数据来源于话单表，二是话务员工作情况的分析，数据来源于话务员操作详单。

    呼叫相关数据是呼叫中心中数据量最大的部分，每一个呼叫都将在话单表中记录其详细信息。对于一个呼叫量大的呼叫中心，我们采用双重粒度来存储系统运营数据。对于近一年的细节数据，我们保留在数据仓库中，并定期进行聚合，因为话务员最小的换班时间单位是半小时，所以这里聚合的时间粒度确定为半小时。细节数据过期后，可根据实现情况删除数据或将数据转移到磁带等大容量设备上，为新的细节数据腾出空间。

    相对于系统运营数据，话务员工作情况数据较小，但这类数据由于与话务员考核有关，所以比较重要。因此，我们同样也采用双重粒度，细节数据保留1年，综合级数据粒度为半小时。

4 分区的确定

    对于当前细节级的细节数据，由于数据量庞大，不利于查询和数据转移等操作，因此我们采用分区策略。用户查询细节数据一般是按月查询，所以我们将系统运营和话务员工作情况细节数据按月分区存储。

5 呼叫中心多维数据库设计

    5.1 OLAP分析模型的建立

    OLAP是基于数据仓库的信息分析处理过程，与呼叫平台相关的分析主题主要有五个：

    1)系统接入话务量分析主题，
    2)系统服务质量和处理能力分析主题，
    3)系统呼出话务量分析主题；
    4)话务员工作情况分析主题；
    5)客户呼叫行为分析主题。

    对于多维数据集的建立，可以先建立话务员工作情况多维数据集以及系统服务质量和处理能力多维数据集，然后由这两个多维数据集组成一个虚拟多维数据集，实现话务员工作情况分析主题。

    5.2 维度的设计

    5.2.1 维的结构

    分析模型确立后，开始定义详细的维度。主要分为以下几个维度：时间，地区，呼叫中心号，虚拟中心号，客户级别，接入码，图4多维数据集逻辑模型    媒体类型、业务类型和工号，每个维度又根据时间的不同而分为六个层次，具体就是年，季度、月、日、小时和半小时。

    5.2.2 维的键值与显示值、排序问题

    维的键值是与事实表做表连接用的，然而维的键值通常是代码，用户希望看到的是维的内容，这可以通过调整维的显示值来实现。我们也可设置维的属性使维按键值排序。例如：将“工号”维的第一层次“班组”的显示值设为字段“班组名称”，并按键值“班组号码”排序；将“工号”维的第二层次“工号”的显示值设为字段“话务员名称”，并按键值“工号”排序。

    5.3 度量与计算列的设计

    在系统服务质量和处理能力分析模型中，我们确立了66个指标。其中大部分指标都是对事实表中列值求和，这种我们称为度量，例如：人工接通数是事实表中列。人工接通数”求和。但有部分指标是对已存在的度量的重新计算，我们称为计算列，计算列并不占用存储空间。

    系统服务质量和处理能力分析模型中的计算列有：15秒接通率，20秒接通率，人工接通率，自动接通率，自动通话均长，等待应答均长，人工通话均长，接通排队等待均长，呼损排队等待均长，人工呼损数，自动呼损数，人工通话时长90秒以上次数，排队等待数。设计好的多维数据集如图4所示。
 

图4 多维数据集逻辑模型

    5.4 多维数据集的物理设计

    SQL Server2000 AnalySis services提供了三种存储方式：MOLAP，ROLAP和HOLAP。考虑到呼叫中心数据仓库的特点和系统的稳定性，我们选用了MOLAP存储方式。

    选择了存储方式后，我们需要对数据进行聚合，聚合是对多维数据集源数据的预先综合计算，用以提高查询的响应速度。然而，大量的聚合对存储容量和聚合时间的消耗可能是非常巨大的。因此，应该控制聚合的数量，以便在查询速度和存储容量之间取得一个平衡。有三种方法加以控制：

    1)设定聚合的存储空间上限；
    2)设定性能提升上限；
    3)观察“性能与大小”图的处理变化，    直到点击“停止”。
6 前端结果展现

    多维数据集建立后，就可以通过前端展示工具访问多维数据集，以下是通过Microsoft Excel连接到0LAP服务器的展现结果。见图5、6、7、8所示。
 

图5 全省2008年季度报表


图6 全省2006年各地区呼入量报表


图7 全省2006年3月份每天的系统呼入话务量柱状图


图8 2006年全省各地市市话呼入量饼图

7 结 语

    传统的呼叫中心发展到现在已经能够比较好的解决提高服务质量的问题，能够在日常的工作中获取大量对运营商有价值的数据，本文着重研究将数据仓库和OLAP技术引入呼叫中心，帮助呼叫中心运营商从海量的营运数据中抽取出能够直接反映呼叫中心运菅状况的数据，为呼叫中心运营商作出运营决策提供直接的信息支持。同时本文从设计到实现全方面的考虑，最终采用的Microsoft SQL Server的数据仓库解决方案，有实现简单，成本低，维护方便等优点。在技术方面，结合呼叫中心的实际情况，在构建数据仓库时主要用到双重粒度、分区等技术，在建立OLAP分析主题时用到虚拟维度等技术。