在数据仓库的数据模型设计过程中，经常会遇到这样的需求：
- 数据量比较大;
2. 表中的部分字段会被update,如用户的地址，产品的描述信息，订单的状态等等;
3. 需要查看某一个时间点或者时间段的历史快照信息，比如，查看某一个订单在历史某一个时间点的状态，
比如，查看某一个用户在过去某一段时间内，更新过几次等等;
4. 变化的比例和频率不是很大，比如，总共有1000万的会员，每天新增和发生变化的有10万左右;
5. 如果对这边表每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费;拉链历史表，既能满足反应数据的历史状态，又可以最大程度的节省存储;举个简单例子，比如有一张订单表,6月20号有3条记录：
| 订单创建日期 | 订单编号 | 订单状态 |
| 2012-06-20 | 001 | 创建订单 |
| 2012-06-20 | 002 | 创建订单 |
| 2012-06-20 | 003 | 支付完成 |
到6月21日，表中有5条记录：
| 订单创建日期 | 订单编号 | 订单状态 |
| 2012-06-20 | 001 | 支付完成（从创建到支付） |
| 2012-06-20 | 002 | 创建订单 |
| 2012-06-20 | 003 | 支付完成 |
| 2012-06-21 | 004 | 创建订单 |
| 2012-06-21 | 005 | 创建订单 |
到6月22日，表中有6条记录：
| 订单创建日期 | 订单编号 | 订单状态 |
| 2012-06-20 | 001 | 支付完成（从创建到支付） |
| 2012-06-20 | 002 | 创建订单 |
| 2012-06-20 | 003 | 已发货（从支付到发货） |
| 2012-06-21 | 004 | 创建订单 |
| 2012-06-21 | 005 | 支付完成（从创建到支付） |
| 2012-06-22 | 006 | 创建订单 |
数据仓库中对该表的保留方法：
- 只保留一份全量，则数据和6月22日的记录一样，如果需要查看6月21日订单001的状态，则无法满足；
- 每天都保留一份全量，则数据仓库中的该表共有14条记录，但好多记录都是重复保存，没有任务变化，如订单002,004，数据量大了，会造成很大的存储浪费；
如果在数据仓库中设计成历史拉链表保存该表，则会有下面这样一张表：
| 订单创建日期 | 订单编号 | 订单状态 | dw_begin_date | dw_end_date |
| 2012-06-20 | 001 | 创建订单 | 2012-06-20 | 2012-06-20 |
| 2012-06-20 | 001 | 支付完成 | 2012-06-21 | 9999-12-31 |
| 2012-06-20 | 002 | 创建订单 | 2012-06-20 | 9999-12-31 |
| 2012-06-20 | 003 | 支付完成 | 2012-06-20 | 2012-06-21 |
| 2012-06-20 | 003 | 已发货 | 2012-06-22 | 9999-12-31 |
| 2012-06-21 | 004 | 创建订单 | 2012-06-21 | 9999-12-31 |
| 2012-06-21 | 005 | 创建订单 | 2012-06-21 | 2012-06-21 |
| 2012-06-21 | 005 | 支付完成 | 2012-06-22 | 9999-12-31 |
| 2012-06-22 | 006 | 创建订单 | 2012-06-22 | 9999-12-31 |
说明：
- dw_begin_date表示该条记录的生命周期开始时间，dw_end_date表示该条记录的生命周期结束时间；
- dw_end_date = ‘9999-12-31’表示该条记录目前处于有效状态；
- 如果查询当前所有有效的记录，则select * from order_his where dw_end_date = ‘9999-12-31′
- 如果查询2012-06-21的历史快照，则select * from order_his where dw_begin_date <= ‘2012-06-21′ and end_date >= ‘2012-06-21’，这条语句会查询到以下记录：
| 订单创建日期 | 订单编号 | 订单状态 | dw_begin_date | dw_end_date |
| 2012-06-20 | 001 | 支付完成 | 2012-06-21 | 9999-12-31 |
| 2012-06-20 | 002 | 创建订单 | 2012-06-20 | 9999-12-31 |
| 2012-06-20 | 003 | 支付完成 | 2012-06-20 | 2012-06-21 |
| 2012-06-21 | 004 | 创建订单 | 2012-06-21 | 9999-12-31 |
| 2012-06-21 | 005 | 创建订单 | 2012-06-21 | 2012-06-21 |
和源表在6月21日的记录完全一致：
| 订单创建日期 | 订单编号 | 订单状态 |
| 2012-06-20 | 001 | 支付完成（从创建到支付） |
| 2012-06-20 | 002 | 创建订单 |
| 2012-06-20 | 003 | 支付完成 |
| 2012-06-21 | 004 | 创建订单 |
| 2012-06-21 | 005 | 创建订单 |
可以看出，这样的历史拉链表，既能满足对历史数据的需求，又能很大程度的节省存储资源；
关于这种历史拉链表的etl刷新策略和方法，下次再谈吧。。。
历史拉链表的etl刷新策略和方法已更新，请参考阅读：
数据仓库中历史拉链表的更新方法
如果觉得本博客对您有帮助，请 赞助作者 。
转载请注明：lxw的大数据田地 » 数据仓库数据模型之：极限存储–历史拉链表
