有关数据库范式

本文详细介绍了数据库设计中的第一、第二、第三范式以及BCNF范式的基本概念与应用,通过实例解析如何消除数据冗余,避免更新、插入与删除异常。

数据库范式

范式用于规定关系数据库表结构的一种规范,以减小数据的冗余。

范式主要有以下几种:

BCNF范式第三范式第二范式∈第一范式

它们之间是一个子集关系,满足第二范式必满足第一范式

 

下面就来仔细说说这些范式:

一、         第一范式

通俗的说就是数据库中不能表中有表,某一列中不能再嵌套其他列,请看下面这个表结构

学号

姓名

院系及专业

学院

专业

       院系及专业这一列里又嵌套了两列就不符合第一范式

改正:

学号

姓名

院系

专业

      

 

这样学生表就符合第一范式

二、         第二范式

主键如果是多个列组合起来的,找不到一列完全依赖于部分主键

比如这样一张表

学生

课程

老师

老师职称

教材

教室

上课时间

某学生上一门课,上课的地点、老师、老师的职称、所用教材、时间一定是确定的,那么(学生、课程)联合起来组成了该表的主键

但是(课程à教材),就找到了一列完全依赖于部分主键

 

?这样的部分依赖会造成什么样的影响呢

1)数据冗余

共有m个学生选《数据结构》这门课,那么数据结构的教材就要出现m

2)更新异常

①如果要修改《数据结构》这一门课的教材,那么就得把所有选该课的记录都要修改,太麻烦了

②如果有学生没有选课,那么该学生的信息无法加入

           ③如果有的课程没有学生选,那么该课程的信息无法查询

3)删除异常

如果某学生撤消了选课记录,重新选择,那么在删除选课记录时将课程信息也删除了找不到该课程所用的教材

         →→→改正

         将上表分离成两个表:

学生

课程

老师

老师职称

教师

上课时间

  

课程

教材

 

三、第三范式-------不能有传递依赖

在上面

学生

课程

老师

老师职称

教师

上课时间

        表中,(学生,课程)→老师→老师职称,老师与老师职称间存在传递依赖

       ?产生的影响

①    老师职称改变,需要在表中修改很多次

②    某学生不选哪个老师的课,该老师的职称信息无从查找

③    某老师刚来学校报到,现无学生选他的课那么该老师的信息无法插入到表中

          →→→改正:

将表继续拆分为两个表

学生课程老师教室上课时间

 

老师

老师职称

 四、BCNF范式

    【该部分内容引自百度空间http://hi.baidu.com/cy005/item/feea7816f399ce3db93180a2

      鲍依斯-科得范式(BCNF):在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

   假设仓库管理关系表为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, 存储物品ID, 数量)。

   这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。

 

### 数据库范式的概念 数据库范式是指由E.F.Codd提出的关于关系数据库设计的一系列规则和标准,这些规则帮助开发者减少数据冗余并增强数据一致性[^3]。通过遵循不同的范式级别(从1NF到更高的形式如5NF),可以逐步优化数据库结构。 #### 第一范式 (1NF) 第一范式要求表中的每一列都必须是原子性的,即不可再分的基本数据项[^1]。这意味着每一条记录都应该是一个单一值而不是一组重复的值或者列表。 #### 第二范式 (2NF) 第二范式建立在第一范式的基础上,进一步规定所有的非主属性完全依赖于整个主键而非其部分组件[^2]。这有助于防止部分函数依赖带来的问题。 #### 第三范式 (3NF) 第三范式是在满足前两者的前提下,消除了任何非主属性对候选关键字之间的传递函数依赖关系[^2]。这样做的目的是为了确保没有间接的数据关联影响整体架构稳定性。 ### 应用场景分析 尽管高阶范式提供了更好的逻辑独立性和较少的数据重复率,但在实际项目开发当中并非总是追求最高程度的形式化处理。例如,在某些特定条件下允许一定程度上的去规范化(反范式),以便换取读取速度方面的改进: - **低频写入高频读取环境**:在这种环境中适当引入一些冗余信息可能会显著加快查询响应时间因为减少了必要的联接次数[^4]。 - **实时报表生成系统**:当面对复杂的汇总计算需求时预先聚合结果存储下来也可以有效降低在线事务处理的压力从而提升用户体验质量。 然而需要注意的是过度使用这种方法不仅增加了磁盘占用还容易引发同步错误所以应当谨慎评估利弊后再决定实施策略。 ```sql -- 示例SQL语句展示如何创建符合3NF的关系型表格 CREATE TABLE Orders ( OrderID INT PRIMARY KEY, CustomerID INT NOT NULL, -- 假设Customer有单独一张表 FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID), OrderDate DATE NOT NULL ); CREATE TABLE OrderDetails ( DetailID INT AUTO_INCREMENT PRIMARY KEY, OrderID INT NOT NULL, ProductID INT NOT NULL, Quantity INT DEFAULT 0 CHECK (Quantity >= 0), Price DECIMAL(8 , 2 ) UNSIGNED , FOREIGN KEY (OrderID) REFERENCES Orders(OrderID), FOREIGN KEY (ProductID) REFERENCES Products(ProductID) ); ``` 以上代码片段展示了两个相互关联但各自保持良好分离度的实体定义方式——订单及其明细条目分别存放在不同地方并通过外键机制维持联系;这样的安排正好体现了良好的实践原则之一就是尽量避免不必要的嵌套复合类型字段存在于此同时又能很好地适应未来扩展可能性变化趋势的要求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值