做程序员的或多或少都设计过一些数据库。我想，在没有很好的理论基础下，设计数据库时，最多遇到的问题恐怕是：是这样好呢，还是那样好。原因是数据库设计本身是一件灵活多变的事，虽说各种不同的设计条条大路通罗马。但数据库设计又不仅仅如此，我相信，同一需求前提下，两个优秀的设计师设计出来的数据库应该是非常相似，甚至几乎一样的。那么，今天先总体上来谈谈数据库的一般设计过程。

　　需求分析除外，数据库的实现分为以下几个主要过程：

　　1、概念结构设计，该阶段的主要产物是实体联系图，简称为E-R图；

　　2、关系模型的设计跟优化，该阶段的主要目的是把概念模型转化为关系模型，并主要从理论上来优化数据库；这部分将是体现一个数据库设计师能力的主要依据之一。

　　3、物理模型设计，该阶段主要内容是把关系模型真正用到具体的DBMS系统上去，如：Mysql、Oracle，再跟据需求的特点，及DBMS本身的特点，调整设计。

　　4、访问接口设计，包括：用户子模式设计，主要内容为设计视图，存储过程设计（理论上，这部份内容其实不用单独组成一个阶段；但这部分内容也有相当的重要性，所以这里，把它也单独提取出来）。

　　第一点、概念结构设计，也就是E-R图的设计。这部分没多少难点，我在这里只重新强调下几个概念：

　　● 实体：客观存在的，并可相互区分的事物称为实体

　　● 属性：实体的特征、特性、指标点

　　● 码：唯一标识实体的属性集

　　● 域：属性的取值范围

　　● 实体型：用实体名跟属性名来刻画的同类褓

　　● 实体集：同一类型的实体的集合

　　● 联系：在系统范围内的，跟需求相并的关联，主要是实体与实体之间的关联

　　第二点、关系模型的设计、优化。

　　前一点的重点主要是在对关系模型概念的理解，。前一点往往被人忽略，最简单的一个测试方法是：在我眼中，关系就是指联系么？答案是否定的。关于关系严格的定义我会在《第二篇：严格的概念认识——关系、关系模型》里说明。在这个阶段一定要时刻考虚到数据库的完整性，包括：实体完整性、参照完整性及用户定义的完整性。前两个完整性限定一般由DBMS本身来保证，而用户完整性是我们设计数据模型时必须仔细考虑的。这是一件比较烦锁的事，但对于以后在数据库上开发上层应用是非常有保障的。下面稍微详细地描述下各种完整性约束具体指什么：