从实体和关系角度看 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 设计数据库模型从实体和关系角度看 PowerDesigner 设计数据库模型   从实体和关系角度看 PowerDesigner 设计数据库模型


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

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

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


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


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

但实际用时,为了降低约束,不让 school_id 在 student 表中作为主键,那么 Dependent 不勾选,Mandatory 表示强制,即一个学生必须有一个学校,而学校至少有一个学生,下图中默认允许学校没学生了,新开张的吧从实体和关系角度看 PowerDesigner 设计数据库模型

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

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

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

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

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


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




上一篇:给产品经理讲讲,什么是持续交付和DevOps


下一篇:禅道项目管理软件