范式是一组符合一定层次的关系模式，代表一个关系内属性之间关系的合理化程度。
图1:电子病历图
范式的目标
减少数据冗余；消除异常-插入、更新、删除和其他异常；更标准化的数据。00-1010范式是符合一定层次的关系模式的集合，表示关系内属性之间关系的合理化程度。简单来说，就是用来存储数据的表结构符合某个设计标准的级别。数据库范式也分为1NF、2NF、3NF、BCNF、4NF和5NF。一般我们在设计关系数据库的时候，最多考虑BCNF就够了。符合高级范式的设计必须符合低级范式，例如，符合2NF的关系模型必须符合1NF。第一范式(1NF)
所谓的第一范式(1NF)意味着表不能有多个值或重复的属性。如果有重复的属性，可能需要定义一个新的实体。新实体由重复的属性组成，新实体与原实体之间存在一对多的关系。在第一范式(1NF)中，表的每一行只包含一个实例的信息。
例如，在用户信息表中，如果用户有两个手机号码(1320000000，13245678912)，如果此时这两个手机号码存储在一个域中，将不满足第一范式。
在任何关系数据库中，第一范式(1NF)是关系模式的基本要求，不满足第一范式(1NF)的数据库就不是关系数据库。
第二范式(2NF)
第二种范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖，就是不能有只依赖一部分主键的属性。如果是这样的话，那么这个属性和这部分主键就应该分开，形成一个新的实体，新实体和原实体之间是一对多的关系。为了区分，通常需要在表中添加一列来存储每个实例的唯一标识。简而言之，第二个范例是非主要属性不部分依赖于主要关键字。
假设选课关系表为SelectCourse(学号、姓名、年龄、课程名、年级、学分)，关键字为组合关键字(学号、课程名)，因为有以下决定性关系：(学号、课程名)(姓名、年龄、年级、学分)这个数据库表不满足第二范式，因为有以下决定性关系：(课程名)
第三范式(3NF)
要满足第三范式(3NF)，必须先满足第二范式(2NF)。简而言之，第三范式(3NF)要求一个数据库表不包含其他表中已经包含的非主键信息。在第二范式的基础上，如果数据表中没有非关键字段对任何候选关键字段的传递函数依赖，则符合第三范式。
假设student关系表是Student(学号、姓名、年龄、学院、学院地点、学院电话号码)，关键字是单个关键字‘学号’，因为有以下决定性关系：(学号)(姓名、年龄、学院、学院地点、学院电话号码)。这个数据库符合2NF，但不符合3NF，因为有以下决定性关系：(学号)还会有数据冗余、更新异常、插入异常、删除异常，读者可以自己分析了解。将学生关系表分为以下两个表：学生：(学号、姓名、年龄、学院)；学院：(学院、地点、电话)这个数据库表符合第三范式，消除了数据冗余、更新异常、插入异常、删除异常。