三范式解析：
第一范式：数据库的列必须是原子的，不能通过逻辑再拆分。
比如你设计的一个表的列是这样的：
| 姓名年龄 | 班级学号 | 性别爱好 |
|---|---|---|
| 张三21 | 三班2002002 | 男足球 |
这样用起来就需要你逻辑拆分，而且还没办法跟其他表做关联查询。所以违反了第一范式。
第二范式：在满足第一范式的基础上，你设计的表的非主属性元素，要都完全依赖与表的每一个候选主属性。
比如你又设计了一个表：
| 商品编码 | 商品名称 | 商品价格 | 订单号 | 订单日期 |
|---|---|---|---|---|
| 1 | 牙刷110 | 2 | 111 | 一月 |
| 2 | 鼠标246 | 4 | 111 | 二月 |
| 3 | 饭盒653 | 5 | 222 | 三月 |
这个表总体来看，主属性是商品编码，因为表中多数字段都是在描述商品，但是后续的订单日期，就与商品关联不是很大了，包括订单号，如果这是描述商品的表，最好也是独立出去，拆成订单表，再通过中间表，描述两者之间的关联，才是符合第二范式的。
第三范式：在满足第一范式的基础上，一个表的非主属性不能出现在另一个表中。
比如：
商品表：
| 商品编码 | 商品名称 |
|---|---|
| 1 | 牙刷110 |
订单表：
| 订单编码 | 订单日期 |
|---|---|
| 111 | 一月 |
订单商品关联表：
| 订单编号 | 商品编码 | 商品名称 |
|---|---|---|
| 111 | 1 | 牙刷110 |
可以看到订单商品关联表中商品名称是冗余的，这种冗余在查询上看不出来来什么，但是一旦有场景需要修改商品名称，则需要你想起来所有冗余了这个字段的表，而往往实际应用中，很难注意到冗余字段被修改的情况，这样就把数据染脏了。
说明：
规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小。便于插入、删除和更新。遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是惟一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。
其根本目标是节省存储空问，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到范式不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
比如有些国标字典项，国家更新这些标准的概率很小，你在主表中存了编码，前端展示名称，就可以把这些名称冗余在主表中，省的每次都连表查询。