【Normal Form】数据库表结构设计所遵从的范式

非主键必须完全依赖于主键，而不能只依赖于主键的一部分（联合主键）

不符合此特性的示例

博文《权限管理系统概要设计》有一系列用户权限的表，如果以此为例子，将其中的表结构设计为如下，则不符合第二范式：

USER_ID、ROLE_ID为主键，描述用户和角色的关联关系；STATUS描述这个关联关系是生效还是失效。

可以看出，STATUS是描述这段关联的，是依赖USER_ID、ROLE_ID的，即完全依赖于主键。

而USER_NAME是用户名称，它只依赖于USER_ID，即只依赖于主键的一部分。USER_NAME字段的设置不符合第二范式。

如果有一天，用户的名称需要修改，那么就要修改与此用户相关的每一笔关联的数据。

第三范式：非主键必须直接依赖于主键，而不是传递依赖或间接依赖

非主键必须直接依赖于主键，而不是传递依赖或间接依赖。

不符合此特性的示例

博文《权限管理系统概要设计》有一系列用户权限的表，如果以此为例子，将其中的表结构设计为如下，则不符合第三范式：

此为角色表，ID为角色ID，NAME为角色名称，STATUS为此角色是否生效，SYSTEM_ID为此角色所属的系统ID，SYSTEM_NAME为此角色所属的系统的名称。

可以看出SYSTEM_NAME为传递依赖，在角色表中SYSTEM_ID依赖与ID，而SYSTEM_NAME有依赖与SYSTEM_ID。SYSTEM_NAME字段的设置不符合第三范式。

后话

是不是数据库设计一定得严格遵守3范式呢？

这不一定，要视具体情况，实际上，常见许多情况故意设置冗余字段使系统查询更高效、更方便。

【Normal Form】数据库表结构设计所遵从的范式

标签：