数据库的三大范式没有规则。 Java有很多规范，设计模式有七个原则。 数据库也同样有其规范。 按照规范设计和维护数据库是程序员的必备素质。 现在，关系数据库有第一模式(1NF )、第二模式(2NF )、第三模式(3NF )、总线代码模式(BCNF )这六个模式
本文只讨论了三种设计数据库表结构的规则约束，实际上局部变通例如，为了快速查询相关数据，可能允许存在冗余字段
前置知识：1.部分函数依赖：
将x、y作为关系r的两个属性的集合，当存在XY，x’为x的真子集，存在x’y时，y部分函数依赖于x。
例如，假设从AB中输出c，从a中也输出c，从b中也输出c，c的部分依赖于AB。
2 .完全函数依赖
设x，y为关系r的两个属性的集合，x’为x的真子集，存在XY，但每个x’都有x’！ Y说y的完全函数取决于x。
例如，如果可以从AB中得到c，但AB单独得不到c，则可以说c完全依赖于AB。
3 .传递函数依赖
x、y、z是关系r中相互不同的属性的集合，当xy(y )存在X )、YZ时，z传递函数依赖于x。
例如，在a中得到b，在b中得到c，但是在c中得不到b，在b中得不到a的情况下，成为c的传递依赖于a
第一范式：数据库表中的每一列不可分割。 即原子性例如：
本表中的“部门”应该分为两个字段。=="“部门名称”“部门”。
只有这样，才能专门查询“部门名称”和“职场”。
在第二范式(在满足第一范式的基础上(3358www.Sina.com/) )中，非主键全部与主键3358www.Sina.com/相关，并且主键的一部分(主要相对于联合主键
使用“订单编号”和“产品编号”作为合并主键。 在这种情况下，“产品价格”、“产品数量”均与整个合并主键相关，但“订单金额”和“订单时间”仅与合并主键的“订单编号”相关，与“产品编号”无关。 因此，只有主键的某些字段与之相关联，不满足第二模式。
将“订单金额”和“订单时间”移动到订单表中才符合第二范式
第三模式：基于第二模式，非主键列仅依赖于主键而不依赖于其它非主键。 这意味着表中的非主键字段和主键字段原子性是相关的，不允许间接关联。 例如：
表中“部门名称”与“员工编号”的关系应为“员工编号”“部门编号”“部门名称”。
在这个表中没有直接关系。 在这种情况下，会发生以下问题。
数据冗馀：“部门名称”多次重复。
插入异常：设立新部门时如果没有员工信息，则不能单独插入部门信息。 即使强行插入部门信息，员工表中没有员工信息的记录也同样是不正当的记录。
删除例外：删除员工信息也会删除部门信息，导致部门信息意外丢失。
更新例外：即使只更改一个部门的名称，也必须更新多个员工记录。
正确的做法是将上表分割为两个表，并以外键形式进行关联
“部门编号”和“员工编号”直接相关。
第二正则表达式的另一种表示形式是，这两个表通过外键关联，并且不保存冗馀字段。 例如，不能将“部门名称”保存在“员工表”中。
“部门编号”和“员工编号”直接相关。
第二正则表达式的另一种表示形式是，这两个表通过外键关联，并且不保存冗馀字段。 例如，不能将“部门名称”保存在“员工表”中。
学习灵活性：在某些情况下，可能允许存在冗馀字段以快速查询相关数据。 例如，在员工表中存储部门名称违背了第三模式，但不需要对部门表的相关查询。