电信经营分析系统中的上下文

在数据仓库系统中，"维"表示分析问题的角度，所谓多维模型所能提供的分析功能，实际上也就是"能够从多个角度分析问题"，这个逻辑比较符合人的思维习惯，领导不是说"看问题要全面嘛"？从这个角度说，用于OLAP的多维模型还是很适合领导们使用的。但是实际上这个"分析角度"的内容可能只是一些业务术语，比如是一项费用的名称或者一个代理商的名称，而关于这项费用以及这个代理商相关的信息却严重不足，在某些时候，由于相关信息的缺乏，对数据表现出来的现象无法进行正确解释。

这些"相关信息"在数据仓库之父Bill Inmon的经典著作《数据仓库》（注：参见《数据仓库》第五章）中有过阐述，称为"数据仓库中的上下文信息"（Context），并且把上下文信息分成了三个级别：简单上下文（数据结构、字典等信息）；复杂上下文（产品价格、目标市场、组织结构等）；外部上下文（经济政策、竞争对手发展、人口数据等）。在经营分析系统中，目前的维设计中只包含了"简单上下文"，但我们在与系统的最终用户进行交流时，用户往往要求提供系统能够提供复杂上下文和外部上下文信息，例如：A分公司市场部用户要求我们把当地的人文统计信息录入系统，包括人口总量、人口构成、当地GDP水平等信息，显然这些数据在我们的系统之外，属于"外部上下文"；总公司和B分公司希望把套餐的有关信息录入系统，包括套餐的价格、目标用户群、制定部门、资费标准等信息，这些信息属于"复杂上下文"。

本来经营分析系统的数据主要来源于业务系统，但业务系统本身并不能提供用于分析的所有维度和信息，上述提到的"复杂上下文"和"外部上下文"往往在业务系统中并不存在，因此需要经营分析系统建立业务流程对复杂上下文和外部上下文信息进行捕获、收集和管理。笔者希望对经营分析系统中几个主要维度的上下文信息进行讨论。

1、 时间维（日期）

因为任何事实的发生都有时间因素，时间维几乎是任何主题所必备的维度。传统的时间维设计包含了一个分层的时间结构，如下表：

列标号	代码	名称
1	Day_ID	日期标识
2	Day_Desc	日期描述
3	Month_Desc	月份描述
4	Quarter_Desc	季度描述
5	Year_Desc	年描述

在这个结构中，包含了有关日期的基本信息，这些信息可以视为"简单上下文"，但在进行分析时往往会有一些特殊的要求，例如：

1）  我希望对比一下工作日与周末、节假日的市场发展情况，以决定进行营销活动的日期；

2）  我希望了解重大社会事件对话务量的影响，比如沈阳糖酒贸易洽谈会期间以及大连服装节期间话务量的变化情况；

3）  我感觉天气不好的时候人们不愿出门，天气状况也会影响某天的入网用户数，希望通过数据验证一下。

......

以上这些分析其实就数据本身而言，话务量、发展用户数等这些指标在数据仓库中都存在，但由于时间维上没有记录哪天是工作日，哪天是节假日，哪天的天气状况如何，哪段时期有什么社会活动，上述分析就变得异常困难。

如果考虑在日期维上增加一些信息，这个问题就可迎刃而解，如下表：

 

列标号	代码	名称
1	Day_ID	日期标识
2	Day_Desc	日期描述
3	Week_Desc	星期几描述
4	Weather_Desc	天气信息
5	Affair_Desc	事件信息
6	Month_Desc	月份描述
7	Quarter_Desc	季度描述
8	Year_Desc	年描述

 

有了这些信息，可以参照这些信息对数据进行解释，可以按照这些信息对数据进行查询和分析，但新的问题又产生了：这些信息本身并不是从业务系统中抽取出来的（业务系统可不需要这些"没有用"的东东！）那么这些信息如何收集和管理？

笔者认为如果用户确认需要这些上下文信息的话，开发商与用户应该就上下文的收集和管理制定业务流程，保证有人去维护管理这些信息，同时开发商应该提供录入这些信息的界面和方法。

1、 地理维

地理维与时间维非常类似，结构上有"地区->省->国家"几个层次，这个层次结构与运营商的组织机构基本一致，运营商在全国有一个总部公司，各省有分公司，而发展用户的基层单位则在各个地市。运营商一般都建立了一整套的指标考核体系，比如用户发展数量等，按照数量对比，可能发现一个省中A市用户数量是B市的10倍还多，，这是否就表明A市经营情况远好于B市呢？但是切莫轻易下这个结论，考虑一下以下情况：A市是省会城市，人口600万，人均月收入1000元，A市分公司的市场占有率为20％，而B市是偏远山区的一个老工业基地城市，人口只有40万，由于近年来大型企业普遍不景气，当地居民人均收入水平只有600元，而B市分公司的时长占有率达到了60％。通过这些信息，我们几乎得到了相反的结论：实际上是B市的经营状况要更好一些。

当然与地理相关的这些信息还可以用于制定营销政策等经营决策的参考信息，具有很高的实用价值。

鉴于此，在地理维中加入一些复杂上下文信息，如下：

 

列标号	代码	名称
1	City_ID	地区标识
2	City_Desc	地区描述
3	City_Population	地区人口总量
4	City_GDP	地区人均GDP水平
5	City_Ref_Doc	地区宏观信息文档存放路径及名称
6	Province_Desc	省份名称
7	Country_Desc	国家名称

由于地理信息非常复杂，地理维中只保存了地区人口总量、人均GDP水平等信息，更多的信息希望用专门的文档去描述，因此设计了一个"地区宏观信息文档存放路径及名称"的字段，引用一份外部的文档，用文档去描述更多的地理信息，这份文档属于典型的"外部上下文"，通过记录外部上下文的位置的方式，建立外部上下文与简单上下文、复杂上下文以及数据本身的联系。

地理上下文信息与时间上下文还有所不同，时间上下文信息随时间不断变化和增加，几乎需要有人每天去维护和更新，而地理上下文信息相对要"静止"得多，维护的频度也要低得多。

1、 分销渠道维

电信企业的分销商非常多，是市场营销活动的主要执行者，是市场开拓的先锋，对分销渠道的管理和分析都是经营活动中的重要内容之一。但在业务系统中，并不一定记录分销商的很多信息，也不一定对分销商进行分类。从分销商资料表进行查询可以得到成千上万的记录，但仅仅是分销商的一些名称，显然如果不对代理商分类是很难得到有价值的分析结果的。另外，对于代理商的相关信息，除了代理商名称之外，代理商的规模、地址等信息也非常缺乏或不准确。

传统的分销渠道维也简单得几乎"简陋"，只包含分销渠道标识和分销渠道描述两个信息，显然这是远远不够的，对众多的代理商需要进行多种方法的分类，比如按照地区分类、按照渠道类型分类（营业厅、直销员、代理商等）、按照代理商级别分类等。改进的维表设计包括如下信息：

 

列标号	代码	名称
1	Agent_ID	分销渠道标识
2	Agent_Desc	分销渠道描述
3	AgentKind_Desc	分销渠道类型描述
4	Agent_City	分销渠道所属地区
5	Agent_Level	分销渠道级别
6	Agent_Contract	分销商合同路径名称
7	Agent_Detail	分销商详细信息文档路径及名称

在分销商维中，存在多种层次：

1）  分销渠道->分销渠道类型；

2）  分销渠道->分销渠道所属地区；

3）  分销渠道->分销渠道级别

以上三种层次可以构成在OLAP分析中三个不同的数据"钻取路径"，但分销渠道类型、分销渠道所属地区、分销渠道级别三者之间并不存在层次关系。对代理商的信息实际上可以记录更多信息，诸如地址、联系人、联系方式等，这些信息可以作为结构化信息构成代理商信息维表中的字段，本文主要探讨原理，故此处不对这些信息进行细致分析。同时，代理商信息中还引用了两个外部上下文信息：分销商合同、分销商详细信息文档路径。

1、 套餐维

"套餐"是电信运营商为用户提供的产品的具体表现形态，一个套餐中包含多种业务（子业务），一个套餐对应一组相关的资费标准。套餐的制定和销售过程实际是一个产品的策划、论证、生产、销售、服务过程，在这一系列的活动中，有大量信息应该予以记录，就好比一个产品的设计图纸或设计文档一样。但目前的实际情况，可能电信企业的产品生产太过容易，往往一个地市营销单位，一年就可以制定出上百种套餐了，笔者到南方某省调研的时候了解到该省目前的套餐种类已经超过1万种！真是让人惊叹，虽然目前套餐制定越来越个性化，品种多也很容易理解，但这么多的套餐是否真的那么合理？是否每种套餐都有完成的分析和策划过程？是否有明确的目标用户群和完整的营销策划？该省公司市场部也提出同样的问题，现实情况是大家普遍觉得套餐制定随意性大、针对性差，很多都是因为盲目跟进竞争对手营销行为的产物，套餐成本和盈利分析无从谈起。

当然这种现实的情况要解决起来绝非易事，关系到运营商的管理流程、业务操作流程，而这些信息的管理则需要进一步完善业务系统的软件设计。作为经营分析系统，目前尚且无法获取完整的信息，但在系统设计时，引入必要的套餐上下文信息还是非常必要的。建议的套餐产品信息维表结构应包含如下信息：

列标号	代码	名称
1	DnnrKnd_ID	套餐类型ID
2	DnnrKnd_Desc	套餐类型描述
3	Service_Desc	业务类型
4	City_Desc	地区描述
5	TargetUsers_Desc	目标用户群信息
6	InUseDate	套餐推出时间
7	ValidPeriod	套餐有效期
8	MonRent	月租标准
9	FeeStandard	资费标准
10	DesignDept	制定单位
11	Memo	备注信息

其中的"备注信息"可以是一段描述，也可以引用外部文档。与其他维的不同之处在于，套餐产品维不仅需要经常维护，而且需要建立完整的业务流程进行维护工作。

1、 费用类型维

费用类型与分销渠道、套餐的类似之处在于数据众多，电信企业的计费规则越来越复杂，各种费用类型也越来越多，一般营帐系统中的费用类型代码均有几百种，假定把这几百种费用类型的费用都用图表（例如柱状图）展现出来，对分析员来说将是一种灾难，数据无法看清楚，而且也无从进行细致分析，鉴于此，对费用类型进行有效分类是非常必要的，常用的分类方法包括：

1）  按照业务类型进行分类；

2）  按照收费性质进行分类（月租费、通话费、增值业务费等）；

另外还有特殊的情况，对同一种费用细目，不同的分析员可能希望归入不同的费用类别，例如A套餐月最低消费188元，用户甲某月消费了150元，但需要缴纳188元费用；乙用户某月消费了300元，除了188元最低费用之外还多了112元。对于业务分析人员来说，分析员张先生希望把188元最低消费作为月租费处理，因为这部分费用每月固定收取；而分析员李先生认为188元最低消费中包含了"免费通话时长"，实际上那188元是这些"免费通话时长"的通话费，也就是说，188元实际全都是通话费，而不是月租，因此李先生分析时把188元作为通话费处理。这样李先生和张先生的分类方法产生了冲突，在系统中设计中则需要兼顾两个人的要求。

考虑了上述各种因素的费用类型维可能是如下的结构：

 

列标号	代码	名称
1	Fee_ID	费用细项标识
2	Fee_Desc	费用细项描述
3	FeeKind_Desc	费用类型描述
4	Service_Desc	业务类型
5	FeeKind_Template1	费用分类模板1
6	FeeKind_Template2	费用分类模板2

在上表中，除了传统的分类方法之外，还提供了两种费用分类模板，以便不同的分析员根据需要选择不同的分类模板进行数据分析。

1、 费用分段维

费用分段维是用于对用户的消费层次进行分析时使用的一个维，在现实的分析活动中，费用分段维有两个重要的设计要求：

1）  支持不同的分段方法，有人希望10元一段进行分析，有人则希望50元一段进行分析，设计需要灵活支持；

2）  费用分段本身可以代表不同的含义，比如当月总话费的分段（含月租）、当月通话费分段（不含月租）、用户月均消费金额分段等，这些"分段"都是对消费金额的分段，因此希望设计中能够共享同一个维设计。

数据仓库系统中"数值分层"类型的维有很多，例如年龄分段、通话次数分段、平均通话时长分段等，这些维所面临的问题也都大致相同。过去在设计数据仓库设计中很少考虑这样的问题，维表结构比较简单，只包含"费用值->费用分段"这样两个层次，所幸一般"费用值"都是细到1元的（这样做的主要目的是ETL容易实现），同时这样处理也可以保证在分层时可以任意划分。为了支持更加灵活的分析需求，费用分段维可以参照如下形式：

列标号	代码	名称
1	Charge_ID	费用值标识（实际就是取整后的费用值）
2	Charge_Desc	费用值描述
3	TotalChargeSegment_Desc	总话费分段
4	CallChargeSegment_Desc	通话费分段
5	ChargeSegmentTemplate1	费用分段模板1
6	ChargeSegmentTemplate2	费用分段模板2

与费用类型维类似的是，费用分段维也预先设计了两个分段模板以支持不同分析员的不同分段分析要求。同时还可以将"总话费分段"、"通话费分段"理解为预先确定的费用分段模板。

 

在经营分析系统中，其他维基本都是由业务系统中的业务代码表派生出来的，处理规则相对来说比较简单，在整个系统中使用频率最高的几个维度均已在本文中予以讨论，但本文的主要目的是说明一种思路和方法，在具体的项目中，对每个维的上下文定义和数值分层标准，需要与系统的最终用户共同确定。