一、数据库的介绍
数据库（Database）是存储与管理数据的软件系统，就像一个存入数据的物流仓库。每个数据库都有一个或多个不同的API接口用于创建，访问，管理，搜索和复制所保存的数据。我们也可以将数据存储在文件中，但是在文件中读写数据速度相对较慢，所以我们使用关系型数据库管理系统（RDBMS）来存储和管理的大数据量。
二、常见数据库技术品牌、服务与架构
发展了这么多年市场上出现了许多的数据库系统，最强的个人认为是Oracle，当然还有许多如：DB2、Microsoft SQL Server、MySQL、SyBase等，下图列出常见数据库技术品牌、服务与架构。
三、数据库的分类
数据库通常分为层次式数据库、网络式数据库和关系式数据库三种，而不同的数据库是按不同的数据结构来联系和组织的。而在当今的互联网中，最常见的数据库模型主要是两种，即关系型数据库和非关系型数据库。
关系型数据库代表：Oracle、MySql、SQL Server
非关系型数据库代表：Mongodb、Redis
四、E-R模型
- 当前物理的数据库都是按照E-R模型进行设计的
- E表示entry，实体
- R表示relationship，关系
- 一个实体转换为数据库中的一个表
- 关系描述两个实体之间的对应规则，包括
- 一对一
- 一对多
- 多对多
- 关系转换为数据库表中的一个列 *在关系型数据库中一行就是一个对象
五、三大范式
1、 什么是范式
要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。范式可以指导我们更好地设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。
2、三大范式
第一范式（1NF）
所谓第一范式（1NF）是指在关系模型中，对列添加的一个规范要求，所有的列都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
例如:表1-1中，其中”工程地址”列还可以细分为省份，城市等。在国外，更多的程序把”姓名”列也分成2列,即”姓”和“名”。
虽然第一范式要求各列要保存原子性，不能再分，但是这种要求和我们的需求是相关联的，如上表中我们对”工程地址”没有省份，城市这样方面的查询和应用需求，则不需拆分，”姓名”列也是同样如此。
表1-1 原始表
| 工程号 |
工程名称 |
工程地址 |
员工编号 |
员工名称 |
薪资待遇 |
职务 |
| P001 |
港珠澳大桥 |
广东珠海 |
E0001 |
Jack |
6000/月 |
工人 |
| P001 |
港珠澳大桥 |
广东珠海 |
E0002 |
Join |
7800/月 |
工人 |
| P001 |
港珠澳大桥 |
广东珠海 |
E0003 |
Apple |
8000/月 |
高级技工 |
| P002 |
南海航天 |
海南三亚 |
E0001 |
Jack |
5000/月 |
工人 |
第二范式（2NF）
在1NF的基础上，非Key属性必须完全依赖于主键。第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
例如:表1-1中，一个表描述了工程信息，员工信息等。这样就造成了大量数据的重复。按照第二范式，我们可以将表1-1拆分成表1-2和表1-3：
表1-2 工程信息表
| 工程编号 |
工程名称 |
工程地址 |
| P001 |
港珠澳大桥 |
广东珠海 |
| P002 |
南海航天 |
海南三亚 |
表1-3 员工信息表
| 员工编号 |
员工姓名 |
职务 |
薪资水平 |
| E0001 |
Jack |
工人 |
3000/月 |
| E0002 |
Join |
工人 |
3000/月 |
| E0003 |
Apple |
高级技工 |
6000/月 |
这样，表1-1就变成了两张表，每个表只描述一件事，清晰明了。
第三范式（3NF）
第三范式是在第二范式基础上，更进一层，第三范式的目标就是确保表中各列与主键列直接相关，而不是间接相关。即各列与主键列都是一种直接依赖关系，则满足第三范式。
第三范式要求各列与主键列直接相关，我们可以这样理解，假设张三是李四的兵，王五则是张三的兵，这时王五是不是李四的兵呢?从这个关系中我们可以看出，王五也是李四的兵，因为王五依赖于张三，而张三是李四的兵，所以王五也是。这中间就存在一种间接依赖的关系而非我们第三范式中强调的直接依赖。
现在我们来看看在第二范式的讲解中，我们将表1-1拆分成了两张表。这两个表是否符合第三范式呢。在员工信息表中包含：”员工编号”、”员工名称”、”职务”、”薪资水平”，而我们知道，薪资水平是有职务决定，这里”薪资水平”通过”职务”与员工相关，则不符合第三范式。我们需要将员工信息表进一步拆分，如下:
员工信息表：员工编号，员工名称，职务
职务表：职务编号，职务名称，薪资水平
现在我们已经了解了数据库规范化设计的三大范式，下面我们再来看看对表1-1优化后的数据表：
员工信息表(Employee)
| 员工编号 |
员工姓名 |
职务编号 |
| E0001 |
Jack |
1 |
| E0002 |
Join |
1 |
| E0003 |
Apple |
2 |
工程信息表(ProjectInfo)
| 工程编号 |
工程名称 |
工程地址 |
| P001 |
港珠澳大桥 |
广东珠海 |
| P002 |
南海航天 |
海南三亚 |
职务表(Duty)
| 职务编号 |
职务名称 |
工资待遇 |
| 1 |
工人 |
3000/月 |
| 2 |
高级技工 |
6000/月 |
工程参与人员记录表（Project_ Employee_info）
| 编号 |
工程编号 |
人员编号 |
| 1 |
P001 |
E0001 |
| 2 |
P001 |
E0002 |
| 3 |
P002 |
E0003 |
通过对比我们发现，表多了，关系复杂了，查询数据变的麻烦了，编程中的难度也提高了，但是各个表中内容更清晰了，重复的数据少了，更新和维护变的更容易了，哪