数据库设计概述
目的：减少数据冗余
在设计和数据库有关的系统时，数据库表的设计至关重要，这些设计关系整个系统的架构，需要精心的仔细考虑。
数据库的设计主要包含了设计表结构和表之间的联系，在设计的过程中，有一些规则应该遵守。
1. 第一范式
列不可分
数据库表中的所有字段值都是不可分解的原子值，确保每列保持原子性。
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，
即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体。
新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。
例子
address:湖南省株洲市天元区泰山88号
某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。
但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，
这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。这样设计才算满足了数据库的第一范式。
第二范式
一个表中只能保存一种实体，不能部分依赖
一个表中只能保存一种实体，不可以把多种数据保存在同一张数据库表中。
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例必须可以被惟一的区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
要求实体的属性完全依赖于主关键字。不能部分依赖。
即：一张表存在组合主键时，其他非主键字段不能部分依赖。
例子
这张表有两个实体
存在多对多关系时只有一个字段作为主键是不够的。
这张表中的主键是学号和教师编号的组合
部分依赖，会产生冗余数据，需要分解表
分解如下：
学生
老师
联合主键
第三范式
表里面的列不能出现其它表的非主键字段，不传递依赖
员工信息表中列出部门编号后就不能再将部门名称、部门简介等其他非主键字段
满足第三范式（3NF）必须先满足第二范式（2NF）。
在第二范式的基础上，数据表中如果不存在非关键字段对关键字段的传递函数依赖则符合第三范式。
不能存在传递依赖。即：除主键外，其他字段必须依赖主键
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
例子
班级名称和班级信息这一组值没有必要的重复出现
班级信息并不直接依赖于学号（主键），而是依赖于班级号，也就是时说表中出现了传递依赖
解决这个问题的办法是把这些和学号（主键）没有直接联系的信息记录的新的表里面。
