首先要理解“范例(NF )”是什么意思。 根据教材的定义，范式是“适合某一层次的关系模式集合，表示一个关系内部各属性之间联系的合理化程度”。 很难理解吧？ 实际上，可以将其大致理解为一个数据表的表结构相匹配的某个设计标准的级别。 就像装修房子买建材一样，最环保的是E0级，其次是E1级，还有E2级等。 范例也分为1NF、2NF、3NF、BCNF、4NF、5NF。 一般来说，我们设计关系数据库时，最多考虑BCNF就足够了。 符合高层次范式的设计，一定符合低层次范式。 例如，如果与2NF的关系模式一致，则一定与1NF一致。
33558 www.Sina.com/:无法重新划分符合1 nf标准的关系的每个属性。
1NF是所有关系数据库的最基本要求。 在关系数据库管理系统(RDBMS ) (如SQL Server、Oracle和MySQL )中创建数据表时，如果数据表设计不满足这一最基本的要求，操作将不会成功。 也就是说，只要是RDBMS中已经存在的数据表，就一定符合1NF。
但是，如果仅适合1NF设计，则数据的冗馀性过大，存在插入异常、删除异常、修正异常的问题
由于仅适用于1NF的数据库设计存在各种问题，因此需要提高设计标准，消除导致上述四个问题的因素，使之符合更高等级的范例(2NF )。 这就是所谓的“正规化”。
1NF的定义为) :关系理论中的严格定义在此不多介绍。 (因为涉及的地板很多)你只需要知道2NF对1NF进行了哪些改进就可以了。 其改进在于，2NF基于1NF消除了对非主属性代码的部分函数依赖。 接下来，对与该词相关的4个概念——“函数依赖”、“代码”、“非主属性”、“部分函数依赖”进行说明。
第二范式（2NF
在某个表中，属性(或属性组) x的值确定的情况下，如果一定能够确定属性y的值，则可以说y函数依赖于x，写为X Y。 姓名函数依赖于学号，可以说是学号写姓名。 但是，相反，由于可能出现同名的学生，所以可能存在不同的两个学生记录，这些名称的值相同，但对应的学校编号不同，所以不能说学校编号函数依赖于名称
完全函数依赖：
在一个表中，如果X Y并且对于x的任何真子集，x’y不成立，则y对于x完全函数为函数依赖：
如果y函数依赖于x，但同时y不完全依赖于x，那么称为y部分函数依赖于x
部分函数依赖：
假设z函数依赖于y，且y函数依赖于x。 严格来说，前提是y中还有另一个不包含的x，且y不依赖于z。 z传递函数称为依赖于x。
传递函数依赖：
设k为某表的属性或属性组，如果除k以外的所有属性都依赖于完全函数k，则k称为候补代码，简称代码。 实际上，在确定了k的情况下，如果还确定了该表中除k以外的所有属性的值，则k可以理解为代码。 一个表可以有一个以上的代码。 (在实际的APP应用中，为了方便，经常选择其中一个代码作为主代码。)
码：
其中一个代码中包含的属性成为主属性。
根据2NF的定义，判断的依据是实际上在数据表中看到非主属性是否依赖于代码的某些函数。 如果存在，数据表最多只满足1NF的要求，如果不存在，则满足2NF的要求。
判断方法如下
第一步：找到数据表中的所有代码。
步骤2 :根据步骤1中得到的代码，找到所有的主属性。
步骤3 (在数据表中，除所有主属性外，其余都是非主属性。
步骤4 :确定是否存在依赖于代码中某些函数的非主要属性。
第一步，您可以执行以下操作：
检查所有单个属性，确定该值后，确定是否可以确定所有其他属性值。
检查包含两个属性的所有属性组，并在确定该值后确定是否可以确定所有其他属性值。
显示三个属性(包括所有属性的所有属性组)，并在确定该值后检查是否可以确定所有其他属性值。
.
你看起来很麻烦。 但是我在这里有诀窍。 如果a是代码，则所有包含a的属性组(例如(a，b )、(a，c )、(a，b，c )等)都不是代码)，因为作为代码的请求具有“完全函数依赖”。
为了使表3满足2NF的要求，必须消除这些部分的函数依赖。 唯一的方法是将大数据表拆分为两个或多个更小的数据表。 在分割过程中，为了满足更高层次的范例要求，这个过程称为“模式分解”。 模式分解的方法不是唯一的(如果代码只有一个属性，则非主属性依赖于代码的某些函数，不能满足2NF的要求)。
主属性：
仅仅满足2NF的要求往往是不够的。 出现问题的原因是，非主属性对代码传递函数的依赖仍然存在。 为了进一步解决这些问题，必须改进满足2NF要求的数据表以满足3NF要求。
3NF在2NF
的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。。为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：选课（学号，课名，分数）学生（学号，姓名，系名）系（系名，系主任）
由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。
BCNF范式：
在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。
下面各用一句话简洁地描述：