数据库重构探讨系列(2)-CFANZ编程社区

数据库重构探讨系列(2)

接上一篇文章，《数据库重构探讨系列(1)》

4、数据库重构实例
“余额Balance”列实际上描述的是“账户Account”实体，而不是“顾客Customer”实体。
因此如图所示，需要把“余额Balance”列从“顾客Customer”表移出，加入到“账户Account”表中。

数据库重构探讨系列(2)_数据库

重构的迭代活动如下：

(1) 验证数据库重构是否合适；
这个重构有意义吗？变更真的需要现在进行吗？值得这样去做吗？

(2) 选择最合适的数据库重构技术；
真正需要重构的是“使用正式数据源”

(3) 让原来的数据库Schema过时；
需要一个转换期，即“过时期”

(4) 前测试、中测试和后测试；
要能够轻易验证数据库在变更之后仍能与应用一起工作，就有信心对数据库Schema进行变更，做到这一点的唯一途径就是采用测试驱动开发TDD的方式。
TDD方式中，编写一个测试，编写足够代码，通常是使用数据定义语言DDL，来完成该测试。继续以这种方式工作，直到数据库重构完全实现。

(4.1) 测试数据库Schema；
数据库重构会影响数据库Schema，故需编写面向数据库的测试。可以从许多方面来检查数据库Schema：
· 存储过程和触发器
· 参照完整性RI
· 视图定义
· 缺省值
· 数据不变式
数据库测试工具：管理测试数据的工具DBUnit；测试存储过程的工具SQLUnit；还有针对数据测试的商业工具。

(4.2) 测试应用程序使用数据库Schema的方式；

(4.3) 检验数据迁移的有效性；
许多数据库重构技术要求迁移源数据，比如将数据值Customer.Balance复制到Account.Balance，需要检验每位顾客的正确余额确实进行了拷贝。

(4.4) 测试外部程序代码。

· 修改数据库Schema；

以上面的例子，需要加入Account.Balance列和两个触发器：SynchronizeAccountBalance和SynchronizeCustomerBalance。
完成此事的DDL代码：

ALTER TABLE Account ADD Balance Numeric;
 COMMENT ON Account.Balance 'Move of Customer.Balance column, finaldate=2006-06-14';
 CREATE OR REPLACE TRIGGER SynchronizeCustomerBalance
   BEFORE INSERT OR UPDATE
   ON Account
   REFERENCE OLD AS OLD NEW AS NEW
   FOR EACH ROW
   DECLARE
   BEGIN
     IF :NEW.Balance IS NOT NULL THEN
       UpdateCustomerBalance;
     END IF
   END;
 /
 COMMENT ON SynchronizeCustomerBalance 'Move of Customer.Balance column to Account,
 dropdate = 2006-06-14';
 CREATE OR REPLACE TRIGGER SynchronizeAccountBalance
   BEFORE INSERT OR UPDATE OR DELETE
   ON Customer
   REFERENCE OLD AS OLD NEW AS NEW
   FOR EACH ROW
   DECLARE
   BEGIN
     IF DELETING THEN
       DeleteCustomerIfAccountNotFound;
     END IF
     IF (UPDATING OR INSERTING) THEN
       IF :NEW.Balance IS NOT NULL THEN
         UpdateAccountBalanceForCustomer;
       END IF;
     END IF;
   END;
 /
 COMMENT ON SynchronizeAccountBalance 'Move of Customer.Balance column to Account, dropdate=2006-06-14'

对每次重构采用一些小脚本，原因是：简单性、正确性、版本控制。

实现重构的一个重要方面是，确保数据库Schema变更的部署遵守了公司的数据库开发指南。

· 迁移源数据；
当发现需要编写支持文档来描述一个表、一个列或一个存储过程时，说明需要对这部分Schema进行重构，使其更易于理解。
也许一次简单的改名就可以避免几段说明文档。设计越清晰，就越少需要文档。

· 修改外部访问程序；
数据库Schema变更时，常常需要重构原有的外部程序。

· 运行回归测试；
实现重构的一部分工作是对它进行测试，确保它能工作。

· 对工作进行版本控制；
把重构置于配置管理CM的控制之下。

· 宣布此次重构。
需要向感兴趣的各方沟通已经完成的数据库重构。
宣布工作的一个重要方面是更新相关的文档。还需要更新数据库的物理数据模型PDM。
注意：不用发布不成熟的数据模型。

数据库重构过程：