为数据库设计秃了头的阿尔托莉雅---- 潘亮
前几周我们阿尔托莉雅组设计了楹联数字博物馆的数据库，并且和中华楹联协会进行了数据库合并。
下面讲一讲我们数据库设计中的心得和体会。
首先我们应该按照之前做的需求分析文档，对着需求一个个的思考，数据库应该存什么数据才能完成这些需求，应该怎么去存这些数据。随着你一个个需求分析完，不仅数据库的要存放什么数据明白了，整个程序大体上的设计思路也清晰了。
一开始我们是从尽可能减少冗余的角度来设计数据库的，把一些可有可无的属性新建一个表和主表关联起来。
比如我们将楹联中可有可无的简介、鉴赏、作者信息都新开了一个表。
但是在数据库设计评审时，边老师建议我们不要用这样的结构，尽量使用冗余，这样不仅数据库的设计简单、之后对数据库的操作简单、程序的效率也会高一些，而数据的冗余随着现如今磁盘容量的大幅度提升已经不算大问题了。使用冗余可以避免大量的连表操作（麻烦又低效）。
最后我们做成了这样的：
把可有可无的数据全部放入一个表中，可能有的表会不满足三范式（比如这里是否会员和所属协会显然是冗余的），但是不满足三范式的数据库不一定就是不好的，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。
我们在小组内共同设计数据库的时候，大家统一了某些特定字段用什么类型，之后合并的时候就简单，但是我们楹联数字博物馆和另外一组的中华楹联协会用的是同一个数据库，所以我们就面临着数据库合并的问题，然后合并的时候，他们的类型和我们的类型完全不一样，甚至内部的类型也有些不统一，我们组数据库重新整改+合并几乎等于重新写了一遍。。。
所以分块设计数据库之前，一定要先确认一个标准。
在设计数据库的时候，不同的实体之间的命名一定要区分开来，如果命名搞混了，powerDesigner会自动关联相同名称的属性，然后会出现各种意想不到的错误，我们在一开始设计数据库的时候，发现改一个表的属性，另一个表的属性也跟着改。。。就是因为命名的问题。
CDM生成PDM时，一对多关系会把一那一方的主键作为外键插入多的那一方；多对多关系生成一个新表，双方的主键作为整个主键；一对一关系就需要先确定主从关系，然后和一对多一样。
这是我们合并后最终的数据库，还是不容易啊~
