数据建模师谈建模方法及技巧

接下来要讨论的是笔者曾经遇到的一个颇为棘手的事实表数据改变的问题，该事实表的主键随表中某些数据的变化发生改变。以其中的一个合同表为例，该合同表的主键是由“供货单位编号”＋“合同号”生成的智能主键，当其中的“供货单位编号”和“合同号”中任何一个发生变化时，该合同表的主键都会发生变化，给变化数据捕获带来了很大的麻烦。

项目中，笔者的处理方式是采用触发器的办法来实现变化数据捕获。具体的实现方式是：

1）建立一个新表作为保存捕获的数据表使用，其中字段有“原主键”、“修改后主键”、及其他需要的字段，称为“合同捕获表”。

2）在原合同表Delete和Update时分别建立触发器，当删除操作发生时，建在Delete上的触发器会插入一条记录到“合同捕获表”，其中“修改后主键”字段为空，表示该记录是删除的记录；当发生更新时，将“原主键”、“修改后主键”及其他需要记录的字段都保存入“合同捕获表”中，表示该记录被修改过，如果“原主键”和“修改后主键”不同，则表示主键被修改，如果相同，则表示主键没有被修改。

3）由于操作系统中的主键通常会成为数据仓库中事实表的退化维度，可能仍会起主键的作用。所以在数据加载时，需要分情况判断“合同捕获表”的数据来决定是否更新事实表中的退化维度。

可以说，这样的基于触发器的变化数据捕获方法并不是一个很好的选择。首先这需要对源系统有较大的权限；其次，触发器会给源系统的性能带来很大的影响。所以除非是没有别的选择，否则不建议采用这种方法。

而对于这样的情况，我们在建立操作型数据库系统时完全可以避免。下面是对操作型数据库系统建立者的几点建议：1）操作型系统的主键不要建立成智能型的，至少不要建立成会变化的。2）操作型系统的表中需要加入操作人和操作时间字段，或者直接加入时间戳。3）操作型系统中操作型数据最好不要直接在原值上修改，可以采用“冲红”的方式加入新的记录。这样后续建立数据仓库时就不需要考虑事实表数据的变化问题。

最后，期待各大数据库管理系统的厂商能尽快在DBMS层提供功能强大、简单好用的变化数据捕获功能，目前Oracle已经有了这个功能。毕竟技术方面复杂的事情留给厂商做是一个趋势，而我们做应用的则更关注于业务。