基于已有的数据库，可以使用IDA的reverse engineering功能生成物理模型，然后根据物理模型生成逻辑模型。
使用GOSALES数据库，下来以后安装在DB2 10.5.0.5上
物理模型里面重要的一环是看清child-parent relationship
比如分析表ORDER_HEADER的外键，可以从DB2的系统表里面查询这种关系
SELECT TBNAME,
RELNAME,
REFTBNAME,
DELETERULE,
UPDATERULE,
FKCOLNAMES,
PKCOLNAMES,
REFKEYNAME
FROM SYSIBM.SYSRELS
WHERE CREATOR = 'GOSALES' AND TBNAME = 'ORDER_HEADER'
WITH UR;
当把数据库reverse engineering到IDA以后，可以在界面上很明显的看到这种外键关系
为了更好的在图形界面上看清楚这种关系，可以new blank diagram，然后把5个外键拖进去，从而生成一个容易理解的物理模型。
ORDER_HEADER表是子表，其他表是父表。
子表的主键列是ORDER_NUMBER，由于这个主键列并不包含外键列，也就是说外键列不是子键列的一部分，那么这种关系称之为Non-identifying关系，其实我们建模的时候是不用太在意identifying和Non-identifying关系的，因为我们基本上都不用经过理论的指导来把握这种关系的，如果你有一个existing database，在反向工程到physical data model之后，IDA能自动识别这种关系。但是能在理论上把握这种关系，还是需要的，因为在业务逻辑方面，还是需要能辨别这种关系的，我会专门写一个blog在详谈这方面的例子。
在IDA里面，identifying和non-identifying的图形是不同的
拿其中的一个non-identifying关系来说
从DB2 DDL的角度看，是这么定义的
ALTER TABLE "GOSALES"."ORDER_HEADER"
ADD CONSTRAINT "FK_150447760" FOREIGN KEY
("RETAILER_SITE_CODE")
REFERENCES "GOSALESRT"."RETAILER_SITE_MB"
("RETAILER_SITE_CODE")
ON DELETE NO ACTION
ON UPDATE NO ACTION
ENFORCED
ENABLE QUERY OPTIMIZATION;
可以看出上面的几个截图其实都是那个DDL的各个部分的表示方式，我们有了物理模型，通过物理模型生成DDL的时候，应该可以知道生成的对应的关键表示是什么样子的。