第一范式(1NF)
强调的是列的原子性，即列不能够再分成其他几列。
第二范式(2NF)
首先是 2NF，另外包含两部分内容一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
第三范式(3NF)
首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
第三范式通常已经可以满足业务需求了，表之间的关系也比较清楚了，容易维护。但是为什么要反范式呢？
首先我们需要了解到定义数据库范式的历史背景，在20世纪70年代到80年代范式基本完善定型。在那个时候的系统下：一个硬盘的大小有限，一般也就几百兆（价格也比较高），上网的人也少，所以范式的理论强调减少依赖，降低冗余节省空间的使用。而现在最普通的硬盘都是500G，大一点的就上T了而且价格便宜，同时上网人数也增多了，数据库面临则高并发，业务逻辑复杂，低延迟的要求。很难在遵循这范式的基础上进行数据库设计开发，那么适当的降低范式，增加冗余，用空间来换时间是值得的。最低可以把范式降低到1NF。
通常在设计数据库时遵循以下原则：
1.核心业务使用范式。在类似交易有关的这种敏感核心业务中，强调数据安全和一致性，需要遵循范式保证数据唯一和一致。具体什么是核心业务视情况而定。
2.弱一致性需求——反ACID。在一些对数据一致性要求不高的场合，不必完全遵循ACID，出现适当的数据不一致是可以容忍的。如在线人数，静态页等。当下流行的NoSQL技术，就是基于弱一致性需求，降低数据完整性和一致性换取效率的。
3.空间换时间，冗余换效率。由于一条可见的记录被拆分到多个表中记录，当数据量比较大的时候，联表查询就比较费时，sql语句也变的比较复杂，难于优化。此时就需要适当的冗余了。在统计报表，视图中就是对这一条规则的体现。统计报表通常会对很多列，有的时候多达上百列，需要对几个十几个表进行联表，数度缓慢，使用人数一多可能会时数据库服务器宕机。这种情况就需要使用冗余表了，冗余表一般符合第一和第二范式。冗余表一边是定期转储。
4.避免不必要的冗余。范式理论不是说反就反的，反范式理论不是不要范式，而是在必要时创建冗余表或者总结表。不必要的冗余任然是要避免的。所有的规则都是有使用场景的，我们不应该固守规则，在某些情况下，应懂得变通。