范式：
英文名称是 Normal Form，是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。但通常用到的只是前三种范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。
第一范式（1NF）：强调的是列的原子性，即列不能分割（已经是最精确的描述）。
例：有这样一个表，【联系人】（姓名，性别，电话）。在实际使用中一个联系人有家庭电话和私人手机号。那么这中表就不符合第一范式（电话这列不具有原子性）。可改为【联系人】（姓名，性别，家庭电话，手机号）
第二范式（2NF）：在第一范式的基础上，还要遵循两个条件。一，表必须有一个主键。二，其它列必完全依赖与主键。
例：有一个订单明细表：【OrderIDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)，因为一个订单可以有多个商品，所以在这个表中一个OrderID是不足以成为主键的，显而易见Discount，Quantity是完全依赖于主键OrderID，但UnitPrice，ProductName只是依赖于ProductID，所以不符合第二范式。
要符合第二范式可以拆为：【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）。
第三范式（3NF）：在第二范式的基础上，非主键列必须直接依赖于主键，不能传递依赖。
例：还是一个订单列表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
总结：一般而言范式越高分的越精确。
数据库五大约束：
- primary KEY:设置主键约束；
- UNIQUE：设置唯一性约束，不能有重复值；
- DEFAULT 默认值约束；
- NOT NULL：设置非空约束，该字段不能为空；
- FOREIGN key :设置外键约束。
注意：
- 只有INNODB的数据库引擎支持外键；
- 主键默认非空，默认唯一性约束，只有主键才能设置自动增长，自动增长一定是主键，主键不一定自动增长；