规范化至3NF后album表artist_name字段冗余问题排查

你在规范化过程中遗漏的核心要点 #

1. 未预先识别所有独立业务实体
   规范化的前提是先梳理业务域内的所有独立实体，艺术家本身是和专辑完全独立的实体，不需要依附专辑数据存在，你仅拆分了专辑和歌曲的一对多关联，没有处理艺术家和专辑的一对多关联，直接将artist_name作为专辑表的属性存储，自然会产生冗余。
2. 对3NF的适用边界判断存在疏漏
   3NF的约束仅针对非主属性（不存在于任何候选键中的属性），要求非主属性既不部分依赖、也不传递依赖于候选键。而你定义的候选键包含{album_name, artist_name}，说明artist_name属于主属性，3NF并不约束主属性的冗余和关联异常，仅满足3NF的表结构依然可能存在主属性冗余问题。
3. 未识别全隐藏的函数依赖
   你仅梳理了专辑维度的函数依赖album_id -> album_name, artist_name, year，但忽略了artist_name可被独立的艺术家唯一标识决定，即存在artist_id -> artist_name的函数依赖，拆分出独立的艺术家表才能完全消除冗余。

修正后的表结构 #

• artist表（存储艺术家独立信息）

  artist_id(PK)	artist_name

• 调整后的album表（通过外键关联艺术家）

  album_id(PK)	album_name	artist_id(FK)	year

• song表可保留你原有结构不变

调整后同一艺术家的名称仅需存储1次，同时避免了三类异常：

• 更新异常：艺术家改名仅需修改artist表的1行记录
• 插入异常：新增艺术家不需要预先绑定对应专辑
• 删除异常：删除某张专辑不会连带丢失艺术家的基础信息

内容的提问来源于stack exchange，提问作者Meylis Matiyev