本文以Java程序员的眼光来解释三范式，并附上例子，和这样设计会出现哪些问题。来更加通俗的讲述一下3大范式。最后附上BC范式的一点理解。
第一范式，每一个列不可再分。
对应我们设计就是不能出现重复的列。这个是关系数据库的基础没有人会犯这个错误（数据库也不让）。
下面举一个我们可能会犯错的例子。
学生表，（姓名，班级，年龄，性别，家庭住址，班主任姓名，班主任职称，所选课程，课程学分）。
这里如果是教育局查看所有所有的表，可能会出现，统计一下北京通州区的学生数量，统计一下北京海淀区的学生数量。这样没有办法统计了。所以在这个背景下，我们设计应该是。学生表（姓名，班级，年龄，性别，家庭所在市，家庭所在区，班主任姓名，班主任职称，所选课程，课程学分）。
理解：设计数据库的时候，根据业务最好把东西拆分成合适的粒子。我们还出现一个2的情况，就是字段不够了，也不能随便加数据库字段，我就把一个备用字段，中间用，“，”作为分隔符，放了好多东西，最后要分类统计，就2了。
第二范式，在第一范式的基础上，非主属性依赖于主属性。
还是上面的例子。
主属性，候选码，都是唯一的意思（也就是数据库中的主键）。如果学生姓名是唯一的，学生姓名也就是码，那么就有了主属性。如果每个学生只选择一门课程。那么课程也是唯一依赖于姓名。但是实际生活中，学生很容易重名，学生也要选择多门课程。所以以上违背第二范式。改变为，学生表（学号，姓名，班级，年龄，性别，家庭所在市，家庭所在区，班主任姓名，班主任职称，所选课程号） ，课程表（课程号，课程名称，课程学分）。
理解：程序中必须设置主键，一对多关系必须差分开，多对多也是一样。有的时候为了连表方便也把名称和主键都放在另一个表里。这样就省去连表了，但是会出现一种情况
教师的名称改变了，但是你学生表的老师名称没有改变。
第三范式，消除非主属性传递依赖。
学生表（学号，姓名，班级，年龄，性别，家庭所在市，家庭所在区，班主任姓名，班主任职称，所选课程号）
这时候，班主任依赖于学号，班主任名称依赖于班主任，间接依赖于学号，这就是传递依赖应该变为。
学生表（学号，姓名，班级，年龄，性别，家庭所在市，家庭所在区，班主任编号，所选课程号）
教师表（教师编号，姓名，职称）
理解：程序中除了主键其他信息不能出现在其他表中。（也就是任意两个表，不能出现重复的非主键字段）
BC范式，消除主属性传递依赖
假设学校脑抽，让录指纹方便打卡。学生表（学号，姓名，班级，年龄，性别，家庭所在市，家庭所在区，指纹）
这里就会出现指纹是唯一的，指纹依赖于学号，那么就出现了主属性依赖。
如果学生退学了，指纹信息也消失了，这个系统如果想要建立一个指纹库，那么不符合需求了。
这是候差分成，学生表（学号，姓名，班级，年龄，性别，家庭所在市，家庭所在区，指纹ID）。指纹表（指纹ID，指纹）
理解：1对1关系，最好也进行差分。
以上是个人理解，如果有错误，望读者指出，谢谢。