何处理哪些具有多个值的字段。 如学生基本情况信息表包括如下字段： （学号，姓名，性别，生日，家庭成员） 对于家庭成员字段而言，从逻辑上看，必须为一个值。虽然用户可能会输入多个值，如“父亲：张XX，母亲：李XX”，但是既然作为一个字段处理，那就代表一个家庭成员的信息。 如果需要进行个别家庭成员的查询，显然这时从逻辑上看，这个字段就不再是一个值。简单的单字段处理既不方便查询，也难以准确表达多个成员的区别。 相应的处理方案有两个： 一是横向扩展，如： （学号，姓名，性别，生日，父亲，母亲） 这种方案较为简单，设计思路是将逻辑上不是整体的字段继续分割为逻辑上为整体的字段。但是存在不易扩展的问题，难以有效表达更多的家庭成员，既便可以表达，冗余也会很多。 二是纵向扩展，如： （学号，姓名，性别，生日） （学号，家庭成员类别，姓名） 这个思路是采用ER分析方法，将其分为学生和家庭成员两个实体，联系为一对多。
4 范式的定义 4．1 函数依赖 4．1．1 定义 设R（U）是一个属性集U上的关系模式，X和Y是U的子集。若对于R（U）的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等， 则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。
4．1．2 分解合并原则 如X→Y1，X→Y2，则X→Y1，Y2 主要用于规范分析时简化依赖的表达，注意只限于函数依赖的右边。
4．1．3 转换规则 如X→Y，Y→Z，则X→Z 说明了传递函数依赖的存在，注意前提是没有Y→X。
4．1．4 等价原则 如X→Y，Y→X，则X和Y等价，记为X←→Y。 等价属性无需考虑相互之间的依赖关系，如下面的关系： 学生（学号，姓名，身份证号） 不存在下述依赖：学号→身份证号，身份证号→姓名
4．1．5 几个补充 1）函数依赖是针对所有关系实例而言的，非部分满足。 2）函数依赖是语义范畴的概念，会因时因地因需求而变化。
4．2 平凡函数依赖和非平凡函数依赖 4．2．1 定义 在关系模式R（U）中，对于U的子集X和Y，如果X→Y，但Y属于X，则称X→Y是平凡的函数依赖。 若X→Y，但Y不属于X，则称X→Y是非平凡的函数依赖。
4．2．2 平凡依赖规则 A1，A2…，An→B1，B2…，Bm等价于A1，A2…，An→C1，C2…，Ck，其中的C是B的子集，但C不包括在A中。 如下面的函数依赖都是平凡依赖：
学号→学号，姓名
学号，课程号→学号，成绩
皆可以化简为：
学号→姓名
学号，课程号→成绩
4．3 完全函数依赖和部分函数依赖
4．3．1 定义 在关系模式R（U）中，如果X→Y，并且对于X的任何一个真子集X’，都没有X’→Y，则称Y完全函数依赖于X，记作X—f→Y（f表示full）。 若X→Y，但Y不完全函数依赖于X(有X’→Y)，则称Y部分函数依赖于X，记作X—p→Y（p表示partial）。
4．3．2 码的定义 按照完全函数依赖的定义，可以给码下个严格定义： 设K为关系模式R
中的属性或属性组合。若K—f→U，则K称为R的一个侯选码（Candidate Key）。 若关系模式R有多个候选码，则选定其中的一个做为主码（Primary key）。 如何选择主码是有讲究的，如： 是选学号还是身份证号？ 是利用流水号还是有意义的字段？
4．4 传递函数依赖 在关系模式R（U）中，如果X→Y，Y→Z，且Y不包括在X中，并且没有Y→X，则称Z传递函数依赖于X。 如果Y→X，即X←→Y，则Z直接依赖于X。
4．5 范式
4．5．1 1NF 如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。 第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。但是满足第一范式的关系模式并不一定是一个好的关系模式。
4．5．2 2NF 若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于R的码，则R∈2NF。 从定义上看，2NF一定是1NF，反之并不一定。
4．5．3 3NF 关系模式R
中若不存在这样的码X、属性组Y及非主属性Z（Z不属于Y）, 使得X→Y，Y→Z，但没有Y→X成立，则称R
∈3NF。 从定义上看，3NF一定是2NF，因为部分函数依赖也可以理解为传递依赖，它的左边可以视为Y（X→Y），而右边可以视为Z，即如果存在部分函数依赖就不满足3NF定义要求，逆否命题即为3NF一定是2NF。 反之并不一定，即2NF不一定是3NF。
4．5．4 BCNF 关系模式R
∈1NF，如果对于R的每个函数依赖X→Y，若Y不属于X，则X必含有候选码，那么R∈BCNF。 从定义上看，BCNF一定是3NF和2NF。但是3NF不一定是BCNF，虽然很罕见，如下面的关系：
Students Teachers Courses
张亮 李玉山 管理学
张亮 刘卫国 计算机基础
王海 李玉山 管理学
王海 魏芳 英语
罗建军 刘卫国 计算机基础
说明： 1）一名教师只能带一门课程 2）一旦学生选择了一门课程，就确定了一名教师 相应的函数依赖为： Students，Courses→Teachers Teachers→Courses 如选择Students，Courses作为主码，则Teachers→Courses的存在会破坏BCNF的规定，所以上述关系不是BCNF，但是在Teachers→Courses依赖中没有任何非主属性对码传递依赖和部分依赖，满足3NF的条件。这也说明3NF的“不彻底”性主要表现在可能存在主属性对码的部分依赖和传递依赖。
总结：范式分析主要是为了降低数据冗余，实践证明它适用于单个关系(即对单张表的分析)的微观分析,宏观分析还是使用后来推出的ER 方法为好。实际生产中，我们可以先对需求进行E-R建模，得到关系表后再用范式分析方法”过滤“一遍以得到最终合理的表结构。
范式分析的一般步骤：
①找主键(主属性组)
②找出所有非主属性的函数依赖(决定关系)，完成了上述过程即完成了表的拆分。
经验表明，纯粹的主键(没有实际意义的属性，比如自增长的序号)在进行范式分析时可以先不考虑，范式分析结束后再把这个纯粹的主键添加到主属性组里(主属性组和那个纯粹的主键必然是一一对应关系)。
一直到BCNF都是只是解决的函数依赖问题，数据依赖还包括别的依赖，如多值依赖，这种问题不是BC范式能解决的。