改进数据仓库逻辑设计（原）

改进数据仓库逻辑设计（原） (2009-08-05 22:33)

分类： Data Warehouse

今天读了Verónika Peralta, Raúl Ruggia 的一篇paper《Using Design Guidelines to Improve Data Warehouse Logical Design 》对其中的一个案例做一个总结，希望能对同行有一定的启发。
此数据集市主要记录的信息是一个电信公司对顾客通话时间的记录。
概念模型阶段主要涉及到customer维,date维。customer维主要涉及4个level：state, city, customer 和 department 。
Date维主要涉及2个level：year 和 month 。事实表主要涉及的就是通话时间，用Duration表示。下面是最初的设计：
CUSTOMERS-(customer_id,department,city_id,state_id,customer_name,income,city_name,state_name,country)
DATES-(month,year)
SUPPORT-(month,customer_id,minutes)
大家一看就能看出这个设计的问题，customer是大量的，他们都有重复的city，state，country。这样会产生很大的数据冗余，产生维护的困难。可以对CUSTOMER维做如下修改。

 

改进一：
CUSTOMERS-(customer_id,department,city_id,customer_name,income)
CITIES-(city_id,state_id,city_name,state_name,country)
感觉设计有了一定的改善，但是仔细想想，不难想到，客户的city不是一直不变的，如果客户的city发生变化，如果直接更新customer维，将导致原来的city查询的客户丢失。可以为客户信息建立版本号，可以解决数据丢失的问题。

 

改进二：
CUSTOMERS-(customer_id,department,city_id,customer_name,income,version)
CUSTOMER_HISTORY-(customer_id,version,city_id)
CITIES-(city_id,state_id,city_name,state_name,country)
SUPPORT-(month,customer_id,version,minutes)
另一个问题有产生了，随着事实表SUPPORT数据量的增大，查询性能也就是不可避免的一个问题，比如说通过部门，城市查询上一个月客户的总通话时间，那么查询效率就会降低，为了提高查询性能，需要物化数据到以下表。

 

改进三：
SUPPORT_YEAR_CITY-(year,city_id,minutes)
这一个表书记录某一年某一个城市总的通话时间。我们可以看到，这里需要city_id，这也反过来说明了改进一带来的好处。
事实上，有些维属性可能被用户访问得非常频繁，比如，大部分用户都是通过city_name来查询的。事实上，我们可以为不同的属性存储不同级别的冗余数据。

 

改进四：
CUSTOMERS-(customer_id,department,city_id,customer_name,income,version,state_name)
CITIES-(city_id,state_id,city_name,state_name,country)
把state_name冗余存放在CUSTOMERS维表中的好处是，到我们通过STATE_NAME来查询客户时，我们不需要做关联CUSTOMERS和CITIES。说明一下，做哪个属性的冗余要依据不同的业务需求来定。
随着数据集市的数据开始膨胀，一些问题又还是暴露出来了，人们发现，大部分对通话时间的查询主要的都是查询最近一段时间的数据，查找历史数据的情况较少。这样，我们可以建立两个事实表，一个是通过最近的N月和城市聚合的通话时间数据。另一个事实表是通过历史的年和城市聚合的通话时间数据。

 

改进五：
CURRENT_SUPPORT-(month,customer_id,version,minutes)
HISTORICAL_SUPPORT-(year,city_id,minutes)
此次改进说白了就是把SUPPORT做了一个聚合，把month聚合到year，把customer聚合到city，然后存储在历史support表中。
随后，客户又提了一个需求，需要查询通话时间长的客户的数量，比如通话时间1000分钟以上多少个，1000到500有多少个，这样的需求是经常出现的，这种重要的客户哪个企业都不希望丢失的，那么又需要对以上的模型做一定的改进，可以把客户通话的时间分成一些range。

 

改进六：
CUSTOMER_QUANTITY-(month,city_id,duration_range,quantity)
本书作者最后还做了以下改进：

 

改进七：
ANUUAL_CUSTOMER_QUANTITY-(year,city_id,duration_range,quantity)
大家可以想想为什么这样做，有什么好处。哈哈。

以下是最后产生的模型：
DATES-(month,year)
CUSTOMERS-(customer_id,department,city_id,customer_name,income,version,state_name)
CUSTOMER_HISTORY-(customer_id,version,city_id)
CITIES-(city_id,state_id,city_name,state_name,country)
CURRENT_SUPPORT-(month,customer_id,version,minutes)
HISTORICAL_SUPPORT-(year,city_id,minutes)
CUSTOMER_QUANTITY-(month,city_id,duration_range,quantity)
ANNUAL_CUSTOMER_QUANTITY-(year,city_id,duration_range,quantity)

总结：
最后的设计模型和最初的有天翻地覆的变化，变化主要是考虑和处理实际需求相关的信息。
大家不禁要问，什么样的实际需求相关的信息需要被处理呢？我将在后续的文章中讲到。