背景说明

利用PowerDesigner（下文简称PD）进行数据库设计时，其实没有什么固定的规范。但是数据库设计的目的，是为了在团队中沉淀和共享信息，所以设计文档的可读性非常重要。团队使用统一的标准规范来进行设计，才能够保障文档具有高可读性，进而提高团队协作的效率。

本文把一些在实践中经常使用的要求、经验、技巧列出来，可以作为小型团队的数据建模标准规范。

基于这些规范，建模团队可以：

基于模块化思路进行数据库建模；
最大化复用标准的字段类型，以及常用的字段；
优化界面上对象的布局和显示，方便排版和打印；
快速导出数据库设计文档；

注意 PD可以进行多种模型的设计，本文内容仅仅对物理模型设计（Physical Data Model）有效。

模块化结构

一般情况下，没有经验的建模人员会把所有的表都包含在一张图上。当表的数量超过30个的时候，所有表堆叠到一起看起来特别乱，特别复杂，严重影响了pdm的可读性。

下图是一个比较糟糕的例子

为了提高pdm的可读性，我们应该使用模块化结构来组织pdm，把整个系统按照相关性拆分成多个低耦合的模块，每个模块独立设计，并且在逻辑上独立管理。模块化设计可以让我们清楚的掌握，哪些模块有什么表，以及当前表属于哪一个模块。

按照实践中我们使用的规范，常用的模块包括

包（Package）：可以包含多张图，主要作用是从逻辑上拆分系统；
图（Diagram）：本质是一张画布，用来展现表之间的关系；
域（Domain）：复用的字段类型设置；
文档模板：快速生成设计文档；

样例如下图

复用对象

一个真实的案例，早期的身份证号码是15位长度，后来调整为18位。系统中很多表都有这个身份证号码字段，当发生长度变化的时候，就需要把每一个表里面的对应字段类型都修改过来，这种时候很容易发生遗漏。

避免这种问题的办法就是尽可能复用已有的对象。比如这个身份证长度，我们有两种复用方法

复用字段的类型属性
复用整个字段

字段类型域

预先用域定义常用的字段类型，在设计表字段的时候直接使用，就可以降低发生修改时候的工作量。

在定义域的过程中，不但可以指定类型、长度、not null、默认值等属性，还可以限制字段内容。如下图

设计表字段的时候，在字段的Properties页面直接引用域即可，如下图

字段

如果需要复用整个字段，只需要在表设计时复制字段即可。这里的复制不是Ctrl-C/V，正确的操作是

Add Columns 拷贝一个源字段的副本，名字是黑色
Replicate Columns 引用一个源字段，名字是灰色

如下图

备注为了方便复用字段，可以仿照Domain的做法，预先把常用的公共字段保存在一个专用的表里面（还可以设置这张专用表不自动生成DDL），其他地方引用即可。

主外键关联

因为数据库分表分库越来越普遍，所以业务系统的数据库中已经不再要求必须使用主外键（考虑到数据一致性，建议在可以使用的地方尽量使用）。

但是在pdm文档中，必须设计主外键关系，否则pdm无法体现表的关联关系，就会变成没有任何作用的一份形式文档。

使用表的替身（Shortcut）

为了保持高可读性，我们会把相关性高的表放在一张图里面显示，甚至会在一张图内人为划分多个区域显示不同的主题。

有时候就会出现这样的情况：

一个表要引用另一个包/图里面的表；
同一个表要展现在一张图的多个区域；

我们使用Shortcut，解决一个表需要出现在多个地方的问题。

先Ctrl-C源表，然后选择Paste as Shortcut，如下图

警告在需要删除有多个替身的对象时，一定要搞清楚，到底是删除这一个替身，还是删除整个对象。删除替身操作如下图

主外键的形式（物理/逻辑）

考虑到实际操作中的特殊场景，我们的要求是，保证pdm文档中有主外键关系，但是在生成建表DDL时可以没有主外键。即，要有逻辑主外键关系。

我们可以用不同的方式生成主外键，如下图

上图中的1，2都是使用Reference生成表之间的关系，但是2是逻辑外键。使用Reference的好处是，连接两张表的时候，PD会自动生成子表的外键字段。如t_phy_fk/t_logic_fk这两张表的vihicle_key字段就是自动生成的。

两者的区别就是在Reference Properties选择是否需要生成这个外键的DDL，如下图

再看一下两张表的建表DDL，逻辑外键不会出现在最终数据库脚本中。如下图

还有另外一种表示表关联关系的办法，就是使用Link来连接两张表（最上面图中标号3的虚线）。这种方式不是真正的主外键关联，不生成DDL，不能自动生成外键字段，并且Properties也不能确定哪些字段是关联字段。如果疏忽就可能遗漏了字段。如标号3的场景中，t_link_fk这张表就遗漏了vehicle_key这个字段！