数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。 设计范式是不是很难懂呢?非也,大学教材上给我们一堆数学公式我们当然看不懂,也记不住。所以我们很多人就根本不按照范式来设计数据库。 实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本文将对范式进行通俗地说明,并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。 范式说明 第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。 例如,如下的数据库表是符合第一范式的:
假设仓库管理关系表为StorehouseManage(仓库ID,存储物品ID,管理员ID,数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系: (仓库ID,存储物品ID) →(管理员ID,数量) (管理员ID,存储物品ID) → (仓库ID,数量) 所以,(仓库ID,存储物品ID)和(管理员ID,存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系: (仓库ID) → (管理员ID) (管理员ID) → (仓库ID) 即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况: (1) 删除异常: 当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,"仓库ID"和"管理员ID"信息也被删除了。 (2) 插入异常: 当仓库没有存储任何物品时,无法给仓库分配管理员。 (3) 更新异常: 如果仓库换了管理员,则表中所有行的管理员ID都要修改。 把仓库管理关系表分解为二个关系表: 仓库管理:StorehouseManage(仓库ID,管理员ID); 仓库:Storehouse(仓库ID,数量)。 这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。
范式应用 我们来逐步搞定一个论坛的数据库,有如下信息: (1) 用户:用户名,email,主页,电话,联系地址 (2) 帖子:发帖标题,发帖内容,回复标题,回复内容 第一次我们将数据库设计为仅仅存在表: