数据库三大范式

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

数据库三大范式是为了消除数据冗余、避免更新异常、保证数据一致性而制定的设计准则，核心是“逐步规范化”，从基础到严格依次为：

第一范式（1NF）：原子性

• 核心要求：数据表中的每一列（属性）都必须是不可再分的原子值，不能存在复合属性、多值属性。
• 通俗理解：一列只能存一种类型的单一数据，不能拆分成多个子项（比如“姓名”不能拆成“姓+名”存放在同一列，若需拆分则需分为两列）。
• 示例：不符合1NF的列——“联系方式”（包含电话+微信）；符合1NF的列——“电话”“微信”分开存储。
• 实操案例：设计“学生信息表”，若初始设计为（学号，姓名，联系方式，地址），其中“联系方式”存储“138XXXX1234，wechat123”，“地址”存储“北京市海淀区XX街道XX小区”，均不符合1NF。优化后：拆分“联系方式”为“电话”“微信号”两列，拆分“地址”为“省份”“城市”“区县”“详细地址”四列，优化后表格为（学号，姓名，电话，微信号，省份，城市，区县，详细地址），每一列均为不可再分的原子值，符合1NF。

第二范式（2NF）：完全依赖

• 核心要求：在满足1NF的基础上，所有非主键属性必须完全依赖于主键（不能部分依赖），即主键必须是“候选键”（能唯一标识一条记录的最小属性集）。
• 通俗理解：非主键字段不能只依赖主键的一部分（比如主键是“订单号+商品号”，非主键“商品名称”只依赖“商品号”，就是部分依赖，不符合2NF）。
• 解决方式：拆分表格，将部分依赖的属性拆分到新表中，保证非主键完全依赖于完整主键。
• 实操案例：设计“订单详情表”，初始设计为（订单号，商品号，订单日期，商品名称，商品单价，购买数量），主键为“订单号+商品号”。其中“订单日期”仅依赖“订单号”，“商品名称”“商品单价”仅依赖“商品号”，均为部分依赖，不符合2NF。优化后：拆分为两个表——1. 订单表（订单号，订单日期），主键为“订单号”，非主键“订单日期”完全依赖主键；2. 订单商品表（订单号，商品号，购买数量），主键为“订单号+商品号”，非主键“购买数量”完全依赖主键；3. 商品表（商品号，商品名称，商品单价），主键为“商品号”，非主键完全依赖主键，三个表均符合2NF。

第三范式（3NF）：消除传递依赖

• 核心要求：在满足2NF的基础上，所有非主键属性不能传递依赖于主键（即非主键之间不能有依赖关系）。
• 通俗理解：A依赖主键，B依赖A，就是传递依赖（比如主键“学号”，非主键“系主任”依赖“系名”，而“系名”依赖“学号”，则“系主任”传递依赖于“学号”，不符合3NF）。
• 解决方式：继续拆分表格，将传递依赖的属性拆分到新表，确保非主键只直接依赖于主键。
• 实操案例：基于1NF、2NF优化后的“学生信息表”（学号，姓名，电话，微信号，省份，城市，区县，详细地址，系名，系主任），主键为“学号”。其中“系主任”依赖“系名”，“系名”依赖“学号”，“系主任”传递依赖于主键“学号”，不符合3NF。优化后：拆分为两个表——1. 学生表（学号，姓名，电话，微信号，省份，城市，区县，详细地址，系名），主键为“学号”，非主键均直接依赖主键；2. 系表（系名，系主任），主键为“系名”，非主键“系主任”直接依赖主键，两个表均符合3NF。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花