浅谈关系型数据库设计

Enhancer是一种以数据驱动的开发模式，想要玩转Enhancer就必须玩转数据库。

玩转数据库最重要的就是设计，设计优良的数据库，可以用更简单的SQL来获取数据；可以更方便的扩展业务；甚至能够 大幅度减轻日后维护工作。

对于关系型数据库来说，就好比“JS一切皆为对象”，“Linux一切皆文件”一样，“实体-关系”就是数据库的核心。

实体很好理解，就是业务逻辑中描述的对象，比如大学管理系统里面的：学生，班级，系，老师，课程，社团……这些都是实体。

关系就更抽象一些了，我们可以简单的把关系分成三类：1.一对一关系；2.一对多关系；3.多对多关系。

处理好实体以及这三类关系，就能设计出一个优良的数据库系统。

接下来结合大学管理系统的设计，说一说如何处理实体和这三类关系。

1.建立实体模型：

拿“学生”这个实体举例：一切仅与学生相关的（即与系统中其他实体无关的）属性集合就是“学生”实体。比如学号、姓名、身份证号……这些属性的集合就是学生实体，而所在班级、所在系……因为与系统中其他实体相关，所以不属于“学生”实体的一部分。

在“学生”实体的属性中，有一个属性包含着独一无二的特性：“学号”。它有两个鲜明的特性：（1）唯一：同一所大学里面每位同学的学号都不会与其他同学重复；（2）确定：入学时（学生数据插入到学生表时）学号就已经是一个明确的值而且今后不会发生改变。

所以我们可以使用一个学号代表一位同学，在建表时我们把有着这类特性的属性定义为“主键”。每一个实体都必须有一个主键，如果实体本身就有一个唯一确定的属性，那么就用这个属性做主键；否则可以使用自增长整数、特定规律的流水号或者GUID做为主键（ 非高并发非多来源数据不推荐GUID做主键）。

小结：建立实体模型两点最重要：（1）必须要有主键，在描述关系时就可以仅用主键 属性代表这个实体的某个个体；（2）排除与其他实体相关的属性。

2.一对一关系：

做个假设：我们已经建立好了“学生”和“班级”这两个实体，学校规定每个班级必须有一位班长，根据常识每位班长也 只可能是一个班级的班长，那么这就是一对一关系。

这时在描述这个关系时，我们就有了两种选择：

（1）08G02班的班长是学号为2008001的同学；

（2）学号为2008001的同学是08G02班的班长。

从自然语言的角度来看，这两种描述都是合理准确的。但是回到数据库设计，很明显班长一定是“学生”中的某个个体，不可能每位同学都是班长，所以我们应该采用第一种描述：在“班级”表中加上“班长”字段，填入班长同学的学号。

小结：“你眼中只有我，我眼中只有你”就是一对一关系。描述一对一关系时，要分清楚这两个“一”，在“更小的一”中建立关系描述字段。

3.一对多关系：

举例：“学生”和“班级”，每一位学生只能有一个班级，而每个班级可以有多名学生，这就是一对多关系。

在描述一对多关系时，也有两种选择：

（1）08G02班有学号从2008001到2008050共50位同学；

（2）学号为2008001 的同学属于08G02班；学号为2008002的同学属于08G02班……学号为2008050的同学属于08G02班。

从自然语言的角度来看，肯定是第一种描述更优。但是站到编程的角度：使用第一种描述，必须指定从和到（between...and...），这样指定就涉及两个对比运算（>=和<=）；而如果使用第二种描述，只需要一个对比运算（=），所以肯定是在“多”的表中建立描述字段，比如：在学生表中建立“所属班级”字段。

小结：“我属于你，你还有他”就是一对多关系。描述一对多关系时，在"多"中建立关系描述字段。

4.多对多关系：

举例：“学生”和“社团”，每位学生可以加入多个社团，一个社团也会拥有多名同学，这就是多对多关系。

在描述多对多关系时，我们应该新建一个关系表：社团成员表（学生学号——社团编号），通过关系表来连接“学生”和“社团”实体。

小结：“有时相遇，有时相望”就是多对多关系。描述多对多关系时，站哪边都不公平，只有站中间描述才合理。

总结：数据建库，首先需要理清实体，以实体为基础建表，之后分析每个实体之间的关系，根据关系类型补充关系描述字段（表）。