第一范式(1NF )属性的原子性
第一种模式是数据库中的每列都是不可分割的基本数据项，并且同一列中不能有多个值。 这意味着实体中的一个属性不能有多个值，也不能有重复属性。 如果出现重复属性，则必须重建实体，并且新实体由重复属性组成。
请看照片
分析)购销有两个重叠的属性(数量和单价)，且进价和销售是可分割的，如果不满足原子性，即不满足第一范式，可以修改为以下两个实体
第二范式(2NF )属性完全依赖于主键
完全依赖概念：也就是说，非主键的某些属性不能依赖于主键的所有属性。
首先是1NF，它包括另外两个部分。 一个是表需要主键。 第二，未包含在主键中的列完全依赖于主键，并且不能只依赖于主键的一部分。
让我们考虑一下订单清单。 【OrderDetail】(OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName )。
因为知道一个订单可以订购多个产品，所以只有一个OrderID不是主键。 主键必须是(OrderID，ProductID )。 很明显，Discount (折扣)、Quantity (数量)完全依赖于主键) OderID、ProductID )，而UnitPrice、ProductName只依赖于ProductID。 所以OrderDetail表不符合2NF。 不符合2NF标准的设计容易产生冗馀数据。
将【OrderDetail】表添加到【OrderDetail】(OrderID，ProductID，Discount，Quantity )和【Product】) ProductID，单元打印，price
第三模式(3NF )首先为2NF，其中，非主键列必须直接依赖于主键，并且不能存在事务依赖。 这意味着非主键列a可能依赖于非主键列b，而非主键列b可能依赖于主键。
我们认为订单【OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity】的主键是(OrderID )
其中，OrderDate、CustomerID、CustomerName、CustomerAddr、CustomerCity等非主键列都依赖于主键(OrderID )，因此2NF 但是，问题是CustomerName、CustomerAddr、CustomerCity并不直接依赖主键，而是直接依赖CustomerID (非主键列)，因为这是传递后才依赖主键，所以3ndr
将【Order】改为【OrderID，OrderDate，CustomerID】(OrderID，OrderDate，Customer )和【CustomerID】) CustomerID，CustomerName，ctid
第二范式(2NF )和第三范式)的概念容易混淆。 区分它们的关键在于2NF )非主键列是完全依赖于主键还是依赖于主键的一部分。 3NF )非主键列是直接依赖于主键还是直接依赖于非主键列？