规范化是一种形式化上数学处理过程，以确保每个实体只由一个关系来表示。
第一范式（1NF）：第一范式要示表中的行必须是唯一的，属性应该是原子的（atomic）。这个范式对关系的定义来说是冗余的，换句话说，如果一个表真可以表示一个关系，那么它一定符合第一范式。
行的唯一性是通过在表中定义一个唯一的主键而实现的。
对于属性，只能使用随属性的数据类型定义一起定义的操作来对它们进行操作。和集合定义具有主观性一样，属性的原子性也是主观的。例如，表示人的信息的地址，应该将它表示为一个属性（省市城）、三个属性（省，市，城）？结论要依应用程序而定。如果应用程序需单独处理地址的各个部分，那么将地址的各个部分分开保存是有意义的；否则，将地址分开保存就没有什么意义。
第二范式（2NF）：第二范式包括两条规则，首先数据必须满足第一范式，其次要求非键属性（nonkey attribute）和候选键属性之间必须满足一定的条件。对于每个候选键，每个非键属性都必须完全函数依赖于整个候选键。换句话说，一个非键属性不能只完全函数依赖于候选键的一部分。非正式地说，如果要获得任何非键属性值，就必须提供同一行中某个候选键的所有属性值。如果知道了一个候选键的所有属性值，就能够找到任意行的任意属性值。
假设定义了一个名为 Orders 的关系，用于表示有关订单和订单详情的信息。Orders 关系包含以下属性：orderid、productid、orderdate、qty、customerid，以及 companyname。主键是定义在 orderid 和 productid 上的复合主键。
因为其中存在非键属性部分依赖候选键（这个例子中的主键）的情况。例如，只通过 orderid 属性就可以找到订单的 orderdate,以及 customerid 和 companyname 属性。为了符合第二范式，需要将原来的关系拆分成两个关系：Orders 和 OrderDetails 属性。Orders 关系将包含以下属性：Orderid、orderdate 、customerid 及 companyname。主键定义在 orderid 上。OrderDetails 关系将包含以下属性：Orderid 、productid 及 qty，主键定义在 orderid、productid 上。
第三范式（3NF）：第三范式也有两条规则。首先，数据必须满足第二范式。其次，所有非键属性必须非传递依赖于候选键。通俗地说，这条规则意味着所有非键属性都必须互相独立。换句话说，一个非键属性不能依赖于其他非键属性。
接上例，我们的 Orders 和 OrderDetails 关系现在已经符合第二范式。此时在 Orders 关系中，我们要知道整个主键才能找到下订单的 customerid。同样，需要知道整个主键才能找到下订单的客户的公司名称。然而，customerid 和 companyname 属性也是互相依赖的。为了满足第三范式，需要增加一个 Customers 关系，它的属性包含 customerid (主键) 和 companyname, 并删除 Orders 关系中的 companyname 属性。
可以将第二范式和第三范式通俗地概括为：“每个非键属性都依赖于键，全部键，除了键没有别的”。