自己开发了一个股票软件，功能很强大，需要的点击下面的链接获取：
https://www.cnblogs.com/bclshuai/p/11380657.html
数据库范式
目录
1 关键码... 1
2 依赖... 1
3 范式... 2
1 关键码
1) 超键：在关系中能唯一标识元组的属性或属性集称为关键模式的超键。
2) 候选键：不含有多余属性的超键称为候选键。也就是在候选键中在删除属性就不是键了。
3) 主键：用户选作元组标识的候选键称为主键。一般不加说明，键就是指主键。
4) 外键：如果模式R中属性K是其他模式的主键，那么K在模式R中称为外键。
2 依赖
（1）部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
举个例子：学生基本信息表R中（学号，身份证号，姓名）当然学号属性取值是唯一的，在R关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
（2）完全函数依赖：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
例子：学生基本信息表R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在R关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；
（3）传递函数依赖：设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
例子：在关系R(学号 ,学院号, 学院地址)中，(学号)->(学院号),学院号->学院地址，所以是传递函数依赖关系；
（4）多值依赖：属性值之间存在多对多的关系，如下图所示，一个课程，有多个老师上，一个课程，也有多个不同的年级要上，course多值依赖teacher，course多值依赖class。存在多对多或者一对多的关系。
3 范式
（1）第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。例如学生表中高三2班，这是一个复合属性，需要拆分为年级（高三）和班级（2班）之后，才满足第一范式。
（2）第二范式（2NF）：关系模式R属于第一范式，存在唯一标识记录的主键，不存在非关键字段对任一候选关键字段的部分函数依赖。例如学生表的（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
（3）第三范式（3NF）：关系模式R属于第二范式，且每个非主属性都不传递依赖于键码。例如学生关系表为Student(学号，姓名，年龄，所在学院，学院地点，学院电话)，(学号)->(学院号),学院号->学院地址，所以存在传递函数依赖关系。要符合第三范式，要消除传递依赖关系，拆分为两个表格
学生：(学号，姓名,年龄，所在学院)；
学院：(学院，地点，电话)。
（4） BC范式（BCNF）：关系模式R属于第三范式，不存在任何字段对任一候选关键字段的传递函数依赖，相对于第三范式，就是候选关键字之间不存在传递依赖。例如(仓库ID,存储物品ID,管理员ID,数量)，且有一个管理员只在一个仓库工作，一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
(仓库ID,存储物品ID) →(管理员ID,数量)
(管理员ID,存储物品ID) → (仓库ID,数量)
所以(仓库ID,存储物品ID)和(管理员ID,存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系，不满足BCNF范式。
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
总结
第一范式：消除了复合属性，例如高三2班；
第二范式：不存在非主属性对主属性的部分依赖。例如（学号，身份证号）->（姓名）；
第三范式，消除了非候选主键属性对候选主键属性的传递依赖。
BCNF范式：消除候选主键之间的传递依赖关系。
消除决定因素 | 1NF
| ↓ 消除非主属性对码的部分函数依赖
函数依赖 | 2NF
| ↓ 消除非主属性对码的传递函数依赖
| 3NF
| ↓ 消除主属性对码的部分和传递函数依赖
| BCNF
| ↓ 消除非平凡且非函数依赖的多值依赖
| 4NF
| ↓消除不是由候选码所蕴含的连接依赖
| 5NF