从实体和关系角度看 PowerDesigner 设计数据库模型

从实体和关系角度看 PowerDesigner 设计数据库模型

太阳火神的美丽人生 (http://blog.csdn.net/opengl_es)

本文遵循“署名-非商业用途-保持一致”创作公用协议

转载请保留此句：太阳火神的美丽人生 -  本博客专注于 敏捷开发及移动和物联设备研究：iOS、Android、Html5、Arduino、pcDuino，否则，出自本博客的文章拒绝转载或再转载，谢谢合作。

还是从主体和关系出发，我们进行数据库建模。

和面向对象的 UML 建模有类似之处，只不过数据库建模是表间关联及最小范畴的界定。

当然五个泛式在数据库设计过程中的指导作用是不可或缺的，然而，如果你真的完全遵照五个范式设计出了数据库模型，那么你的设计本身就失败了！

因为那个结果一定是不太好用的，趋于极致的往往就是不合常理的。

适当的冗余，对于时间与空间的权衡，才是真正的数据库设计所遵循的至上法则，这其中无不时刻涉及实际业务环境因素，因地置宜，因时不同，因人而异！

马列矛盾理论告诉我们：数据库设计就是‘主体’和‘关系’的设计

这一篇中传达了主体和关系的概念。

在我所涉及到的数据库设计工具中，最喜欢 MySql WorkBench，其次是 ERWin，最后才是 PowerDesigner。

而 ERWin 当年就很难下到，现在下到了，居然没有 SQLSERVER2000的 DBLib 无法连接 SQLSERVER2008，这真有点扯了，那也是没办法的事情，有空儿再试试。

目前只能求其次，用 PowerDesigner 了。

相对 MySQL WorkBench 来讲，表的自增长 id，还是 MySQL WorkBench 做得好些，每个表都是 id，插入其它表做外键时，自动将表名加在 id 前。

即然开始用 PowerDesigner 了，那么就看看它的好吧，一步一步来做设计。

首先，我们得了解 PowerDesigner  中有概念模型、逻辑模型和物理模型，可以在概念模型中设计，并逐步生成后续两者，再由物理模型生成建库脚本或直接创建库。

反过来，从现有数据库反向生成物理模型，也是可以的。

  

上面 PowerDesigner  中表的设计，Name 和 Code 暂时都使用英文，因为我还不知道 Name 用中文，最后生成的数据库如何用 Code 中的英文。

这里的 Convert name into codes 选项勾后，也不起作用，不知是何原因。有了解的朋友，敬请指教。

从上面看出，表名 student ，自增长 id 也得加上表名 student_id，主要是这个名字全局唯一，所以都用 id 就会冲突。

下面 school 和 student 两表的关系是依赖关系，即学生因上了某所学校而称之为学生。

但实际用时，为了降低约束，不让 school_id 在 student 表中作为主键，那么 Dependent 不勾选，Mandatory 表示强制，即一个学生必须有一个学校，而学校至少有一个学生，下图中默认允许学校没学生了，新开张的吧

上面这种关系线，是一对多的关系，线即代表外键，在逻辑图和物理图中会生成这个外键 。

另一种是，一条关系线代表一种多对多的关系，会转换成一张表。

多出一张 relationship_2 的表，其中关联的两张表的主键形成了复合主键。

最终，核心在于考虑好表间的关系，这才是主要的，至于这个工具如何用，那都是其次了。