1. 数据库、数据库管理系统、数据库系统、数据库管理员
- 数据库：DataBase，DB，就是信息的集合，或者说数据库是由数据库管理系统管理的数据的集合。
- 数据库管理系统：DataBase Management System，DMS，是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库。
- 数据库系统：Data Base System，DBS，由软件、数据库和数据库管理员组成。
- 数据库管理员：DataBase Administrator，负责全面管理和控制数据库系统。
2. 元组、码、候选码、主码、外码、主属性、非主属性
- 元组：是关系数据库的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。在二维表中，元组也称为行。
- 候选码：若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能唯一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么{学号}和{姓名，班级}都是候选码。
- 主码：也叫主键，主码是从候选码中选出来的。一个实体集中只能有一个主码，但可以有多个候选码。
- 外码：也叫外键。如果一个关系中的一个属性是另外一个关系中的主码，则这个属性为外码。
- 主属性：候选码中出现过的属性成为主属性。比如关系工人（工号，身份证，姓名，性别，部门），显然工号和身份证号都能唯一标识这个关系，所以都是候选码。工号、身份证这两个属性就是主属性。如果主码是一个属性组，那么属性组中的属性都是主属性。
- 非主属性：不包含在任何一个候选码中的属性称为非主属性。比如在关系学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。
3. ER图
Entity Relationship Diagram，实体联系图，提供了表示实体类型、属性和联系的方法。
ER图由3个要素组成：
- 实体：通常是现实世界的业务对象，当然使用一些逻辑对象也可以。比如对于一个校园管理系统，会涉及学生、教师、课程、班级等等实体。在ER图中，实体使用矩形框表示。
- 属性：即某个实体拥有的属性，属性用来描述组成实体的要素，对于产品设计来说可以理解为字段。在ER图中，属性使用椭圆形表示。
- 联系：即实体与实体之间的关系，在ER图中用菱形来表示，这个关系不仅有业务联系关系，还能通过数字表示实体之间的数量对照关系。例如，一个班级会有多个学生就是一种实体间的联系。
下图是一个学生选课的 ER 图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M: N）。另外，还有其他两种实体之间的关系是：1 对 1（1:1）、1 对多（1: N）。
4. 数据库范式
数据库设计范式：数据库表的设计依据。
- 第一范式：要求任何一张表必须有主键，每一个字段原子性不可再分。
- 第二范式：建立在第一范式的基础之上，要求所有非主键字段完全依赖主键，不要产生部分依赖。
- 第三范式：建立在第二范式的基础之上，要求所有非主键字段直接依赖主键，不要产生传递依赖。
按照以上范式设计数据库表，可以避免表中数据的冗余，空间的浪费。
第一范式
最核心，最重要的范式，所有表的设计都需要满足。
必须有主键，并且每一个字段都是原子性不可再分。
学生编号 学生姓名 联系方式 ------------------------------------------ 1001 张三 zs@gmail.com,1359999999 1002 李四 ls@gmail.com,13699999999 1001 王五 ww@163.net,13488888888
上表不满足第一范式
原因：第一，没有主键；第二，联系方式可以分为邮箱地址和电话：
学生编号(pk) 学生姓名 邮箱地址 联系电话 --------------------------------------------------------- 1001 张三 zs@gmail.com 1359999999 1002 李四 ls@gmail.com 13699999999 1003 王五 ww@163.net 13488888888
第二范式
建立在第一范式的基础之上，要求所有非主键字段必须完全依赖主键，不要产生部分依赖
学生编号 学生姓名 教师编号 教师姓名 ---------------------------------------------------- 1001 张三 001 王老师 1002 李四 002 赵老师 1003 王五 001 王老师 1001 张三 002 赵老师
多对多关系！（1个学生可能有多个老师，1个老师有多个学生）
上表满足第一范式；修改
学生编号 教师编号，两个字段联合做主键，复合主键（PK: 学生编号+教师编号）
学生编号+教师编号(pk) 学生姓名 教师姓名 ---------------------------------------------------- 1001 001 张三 王老师 1002 002 李四 赵老师 1003 001 王五 王老师 1001 002 张三 赵老师
上表不满足第二范式：张三”依赖1001，“王老师”依赖001，显然产生了部分依赖。
修改：使用三张表来表示多对多的关系
学生表 学生编号(pk) 学生名字 ------------------------------------ 1001 张三 1002 李四 1003 王五 教师表 教师编号(pk) 教师姓名 -------------------------------------- 001 王老师 002 赵老师 学生教师关系表 id(pk) 学生编号(fk) 教师编号(fk) ------------------------------------------------------ 1 1001 001 2 1002 002 3 1003 001 4 1001 002
总结：多对多设计，三张表，关系表两个外键！
第三范式
第三范式建立在第二范式的基础之上，要求所有非主键字典必须直接依赖主键，不要产生传递依赖。
学生编号（PK） 学生姓名 班级编号 班级名称 --------------------------------------------------------- 1001 张三 01 一年一班 1002 李四 02 一年二班 1003 王五 03 一年三班 1004 赵六 03 一年三班
1对多关系！（一个教室中有多个学生）
满足第一范式，有主键（学生编号）。
满足第二范式，因为主键不是复合主键，没有产生部分依赖。主键是单一主键。
不满足第三范式：一年一班依赖01，01依赖1001，产生了传递依赖。
修改：
班级表：一 班级编号(pk) 班级名称 ---------------------------------------- 01 一年一班 02 一年二班 03 一年三班 学生表：多 学生编号（PK） 学生姓名 班级编号(fk) ------------------------------------------- 1001 张三 01 1002 李四 02 1003 王五 03 1004 赵六 03
总结： 一对多，两张表，多的表加外键！
