E-R模型
实体-联系数据模型的提出旨在方便数据库的设计。E-R数据模型采用了三个基本概念：实体集、联系集和属性，可以很好的描述现实世界的概念模型。
在用E-R模型设计数据库时，可以避免两个缺陷：数据冗余和不完整。但是，为了更加合理、科学的设计数据库，又出现了规范化。
好的关系数据库设计的特点：
关系数据库设计的目标是生成一组关系模式，使我们存储信息时避免不必要的冗余，并且让我们可以方便的获取信息。
生成的模式集的好坏首先决定于E-R模型设计的质量。什么是好的关系数据库，好的关系数据库应该具有如下的特点：尽量减小数据冗余，消除异常，如更新异常、删除异常等。
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就是范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
什么是数据冗余、更新异常和删除异常，下面通过一个例子来了解概念：
以一个学校的学生系统为例分析说明，首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话等信息。为了简单我们暂时只考虑这些字段信息，我们对于这些信息，说关心的问题有如下几个方面。
学生有那些基本信息 ；
学生选了那些课，成绩是什么 ；
每个课的学分是多少 ；
学生属于那个系，系的基本信息是什么。
首先我们考虑，把所有这些信息放到一个表中（学号，学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话）下面存在如下的依赖关系。
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
更新异常：
1）若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
2）假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
删除异常 ：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
关系型数据库中的范式：
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。
第一范式：
所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。
下面是一个未进行规范化的例子：
先对表做一个简单说明，employeeId是员工的id，departmentName是部门名称，job代表岗位，jobDescription是岗位说明，skill是员工技能，departmentDescription是部门说明，address是员工住址。
简单的说，第一范式就是每一个属性都不可再分。不符合第一范式则不能称为关系数据库。对于上表，可以看出Address是可以再分的，比如xx市xx路xx号，对其应用第一范式则需要将此属性分解到另一个表，如下：
第二范式：
在1NF的基础上，非码属性必须完全依赖于主键，在1NF基础上消除非主属性对主码的部分函数依赖。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
这样做的目的是进一步减少插入异常和更新异常。在上表中，departmentDescription是由主键DepartmentName所决定，但却不是由主键EmployeeID决定的，所以departmentDescription只依赖于两个主键中的一个，故要departmentDescription对主键是部分依赖，对其应用第二范式如下表：
第三范式：
在1NF基础上，任何非主属性不依赖于其它非主属性，在2NF基础上消除传递依赖。
第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
在上面经过第二范式化的表中，可以看出jobDescription是由job所决定的，则jobDescription依赖于job，具有传递依赖，不符合第三范式，对表进行第三范式后的关系图为：
BC范式：
在1NF基础上，任何非主属性不能对主键子集依赖，在3NF基础上消除对主码子集的依赖，即每个表中只有一个候选键。
满足3NF的关系模式，每个非主属性既不部分依赖于码也不传递依赖于码。满足BCNF的关系模式，每个决定因素都含有码。 如果一个关系模式满足BCNF，则一定满足3NF。
二者的区别在于，BCNF消除了可能存在的主属性对主码的部分依赖和传递依赖。这个问题有点拗口，主要是要弄明白属性，主属性，主码，决定因素的概念。
在上面的表中可以看出，每个员工的email都是唯一的（一般注册信息时，都只记录一个email），所以对其进行BC范式化后的关系图为：
第四范式：
R<U，F>∈1NF，如果对于R的每个非平凡多值依赖X→→Y（Y Í X），X都含有候选码，则R∈4NF。
简单的说，第四范式就是消除表中的多值依赖，也就是说可以减少维护数据一致性的工作。对于上面BC范式化的表，对于员工的skill，两个可能的值是“C#，sql，javascrip”和“C#，UML，ruby”，可以看出，这个数据库属性存在多个值，这就可能造成数据库内容不一致的问题，比如第一个值写的是“java”而第二个写的是“java，python”，解决办法是将多值属性放入一个新表，则第四范式化的关系图如下：
而对于skill表则可能的值为：
规范化与性能的考虑：
对上面数据库范式进行分解的过程不难看出，应用范式规划越高，表则越多，表多会带来很多问题：
1. 查询时要连接多个表，增加了查询的复杂度；
2. 查询时需要连接多个表，降低了数据库的查询性能；
因此，并不是应用规范化程度越高，效果就越好，所以要根据具体情况而定。在设计关系型数据库时我们要考虑到需求的分析，数据库在将来会做哪些业务操作，根据实际情况进行规范化，才会达到性能和结构的平衡。
通常，第三范式已经很大程度上减少了数据冗余，并减少了造成插入异常、更新异常和删除异常了。