携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第15天，点击查看活动详情 >>
数据库的三大范式
为了后面能否详细讲述三大范式并举例，所以在这里先放出一个实例表格（后面根据范式的要求对其进行拆分、修改）
第一范式（确保每一列都保持原子性）
原子性，顾名思义，就是要求每一列都是原子，不可再分；什么叫列可再分，或者不可再分呢？
举个例子，上图中“价格”所在列就包含了两种属性：单价和折后价；这就违背了原子性了，因为这个列明明是可以在分的（分为单价列、折后价列）
像上图这样拆分之后（单价和折后价单独成列），该表就符合数据库的第一范式了。
第二范式（保证每一列都是和主键有关的）
第二范式是在第一范式的基础上提出的，所以满足第二范式就一定满足第一范式，也就是说要想符合第二范式必须先满足第一范式。
（第一范式是第二范式的必要条件，反过来第二范式是第一范式的充分条件）
看下图：
因为表中单靠订单号是不符合主键唯一性了，所以要采用联合主键的方式确定每一条记录；假如联合主键为（订单号，产品编码）
上表虽然符合了第一范式，但却不符合第二范式！
因为像产品名称和单价这些并不依赖订单号（联合主键的一部分），需要拆分为不同的表，以确保表中的列都是依赖主键的（如果是联合主键的话，就需要依赖联合主键的所有）
进行以下拆分：
经过拆分为多个表格，以保证每个表格中的每一列都依赖主键。
第三范式（确保每个列都是直接依赖主键，而不存在间接依赖）
请看下面这个表格：
上表中，订单号 -> 用户名称 -> 用户ID，因此如果要修改其中某一项信息的时候就会牵涉较广了（耦合），即用户信息不能单独管理了。
再次拆分处理：
总结
这一次主要介绍了数据库中常见的三种范式，从一到三要求主键提高，第 i - 1范式是第 i 范式的必要条件。
当然啦，在日常实际开发当中，可能并不会完全遵守三大范式，只能说是具体情况具体分析，假如当前情况在表存在冗余的时候，更方便，那就允许存在一定的冗余。