范例：英文名为Normal Form，这是英国人E.F.Codd (关系数据库的祖先)在20世纪70年代提出关系数据库模型后总结的，范例是关系数据库存储目前有痕迹的共有8种范式，依次为1NF、2NF、3NF、BCNF、4NF、5NF、DKNF、6NF。 通常仅使用前三种范式：第一范式(1NF )、第二范式(2NF )、第三范式(3NF )。 让我简单介绍一下这三种范式。 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。
我会考虑这样的表。 【联系方式】(姓名、性别、电话) )。
在实际情况下，如果某个联系人有家庭电话和公司电话，这个表结构设计还没有达到1NF。 要配合1NF，分割列(电话)就可以了。 即【联系方式】(姓名、性别、家庭电话、公司电话)。 1NF容易分辨，但2NF和3NF容易混淆。 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
想想订单明细表吧。 【订单详细信息】(OrderID、ProductID、UnitPrice、Discount、Quantity、ProductName )。
因为知道一个订单可以订购多个产品，所以只有一个OrderID不能成为主键。 主键必须为(OrderID，ProductID )。 显然，“Discount (折扣)”、“Quantity (质量)”和“数量”完全取决于主键(OderID、ProductID ) )，而“UnitPrice”和“ProductName”仅取决于产品id。 所以订单详细信息表不适合2NF。 不符合2NF标准的设计容易产生冗馀的数据。
将【OrderDetail】表更改为【OrderDetail】(OrderID、ProductID、Discount、Quantity )和【Product】) ProductID、UnitPrice、Product
认为订单表单【Order】(OrderID、OrderDate、CustomerID、CustomerName、CustomerAddr、CustomerCity )的主键为) OrderID
其中，OrderDate、CustomerID、CustomerName、CustomerAddr、CustomerCity等非主键列都依赖于主键(OrderID )，因此为2NF 但是，问题是客户名称、客户addr、客户city不是直接依赖主键，而是直接依赖客户id (非主键列)，因为它只有传递后才依赖主键，所以3nn
【Order】为【Order】(OrderID，OrderDate，Customer )和【Customer】(CustomerID，CustomerName，CustomerAddr，customerer )
第二范式(2NF )和第三范式)的概念容易混淆，但区分它们的关键在于 第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。