学校时的分布式数据库读书笔记(2)

第零章 数据库概述

1 基本概念

关系：一个关系就是一张二维表，每个关系要有一个关系名，一个关系可以存储为一个文件。

元组：表中的一行称为元组。

属性：表中的一列称为属性。

域：属性的取值范围。

关键字：属性或属性组合，其值能唯一地标识一个元组。

元数：关系模式中属性的数目。

关系中不允许出现重复元组

2 范式

2.1 范式定义

INF: 若关系模式R的每个属性都是不可分解的，则R∈1NF

 

2NF: 若R∈1NF，且每个非码属性都完全函数依赖于码属性，则R ∈2NF

 

3NF: 若R ∈2NF，且每个非码属性是传递函数依赖于候选码，则R ∈3NF

 

BCNF: 若R∈3NF，且没有一个非码属性是部分函数依赖或传递函数依赖于码属性，即每个非平凡函数依赖的左边必须包含键码，则R ∈BCNF

 

4NF: 若R ∈3NF，且没有非平凡多值依赖

2.2 范式示例说明

㈠ 第一范式

例如，如下的数据库表是符合第一范式的：

字段1	字段2	字段3	字段4

而这样的数据库表是不符合第一范式的：

字段1	字段2	字段3		字段4
		字段3.1	字段3.2

 

㈡ 第二范式

假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
　　(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
    这个数据库表不满足第二范式，因为存在如下决定关系(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况，下面的就是部分依赖，不满足完全依赖)：
　　(课程名称) → (学分)
　　(学号) → (姓名, 年龄)

由于不符合2NF，这个选课关系表会存在如下问题：
　　① 数据冗余：
　　同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
　　② 更新异常：
　　若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
　　③ 插入异常：
　　假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
　　④ 删除异常：
　　假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。

把选课关系表SelectCourse改为如下三个表：
　　学生：Student(学号, 姓名, 年龄)；
　　课程：Course(课程名称, 学分)；
　　选课关系：SelectCourse(学号, 课程名称, 成绩)。
　　这样的数据库表是符合第二范式的，另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。

㈢ 第三范式
　　在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：
　　关键字段 → 非关键字段x → 非关键字段y
　　假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
　　(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)

这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
　　(学号) → (所在学院) → (学院地点, 学院电话)
　　即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
把学生关系表分为如下两个表：
　　学生：(学号, 姓名, 年龄, 所在学院)；
　　学院：(学院, 地点, 电话)。
这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。

㈣ 第四范式

在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第四范式。禁止主键列和非主键列一对多关系不受约束。
　　假设仓库管理关系表为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范式的，消除了删除异常、插入异常和更新异常。

㈤ 第五范式

将表分割成尽可能小的块，为了排除在表中所有的冗余。

2.3 范式总结

在实际使用中，其实我们并不完全执行上面的规则。一般说来，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是设计数据库的高手了，BCNF的范式出现机会较少。如下图3是Microsoft SQL Server2000的Northwind示例数据库中的Customers表。可见其中也不满足第三范式。由于CustomerID->Address->PostalCode等。显然，存在传递函数依赖。但实际使用确没有太大影响。因为常识中大家都会一起修改相关项。而一般确定后也不会改动。这样的设计才编程时经常使用。因为查询时不需要连接，可以直接在一个表中进行查询。对大数量的数据和分布式数据库更是有效。

 

图3

3 实体关系图(ER图)

  在下面的具体实例中,使用的是PetShop数据库(网络上传播的为微软的.net的测试数据库,下载地址http://www.qddown.com/down.asp?id=2475&no=1.本文使用的是Petshop(1.5.2).msi版本).ER建模工具为Erwin4.1.4.图4是其表结构在ERwin下的ER图.

 

图4

3.1 1对1关系

    图5:Account中的userid和Signon中的username和Profile中的userid具有1对1的关系. 表中存在约束关系.并且Account中的userid必须同时在Signon和Profile中出现才可以插入.而Signon和Profile则没有限制.

 

图5

3.2 1对多关系

  如图6:Profile表中的favcategory与BannerData的主键favcategory具有外键约束,并且favcategory在Profile中可以重复出现. 并只能是在BannerData中出现的才可以插入.

 

图6

下图也是一对多的关系为什么出现的一个是菱形的图标?因为可以在Profile中在favcategory项上可以为空.而不必一定要出现在BannerData中.如果没有菱形图标就不允许为空。如下图7。

 

图7

3.3 多对多关系

     一门课程同时有若干学生选修，而一个学生有同时可以选多门课程，则学生与课程之间具有多对多关系。如图8.

 

图8

3.4 无任何约束的表

     没有限制的表，如图9。

 

图9

 

4 小结

本章主要介绍了几个基本概念，由于这几个概念经常用到，是以后很多问题的基础，所以讨论。范式问题是数据库的难点问题，也是设计数据库的核心问题，在设计数据库应该很好的遵守这些规则，但也有时候可以不遵守的情况，本文也举例说明。在实际工作中要根据具体情况具体分析。而实体关系图也是设计数据库的关键问题，同时开发工程师也需要理解系统设计人员发布的ER图。是开发不可避免并经常用到的问题。所以加以论述。而本章使用的MSSQL由于其简单易用，是学习的好工具，所以采用。采用Erwin也是由于许多的开发商使用和简单易用的特性的原因,另外用得好的是PowerDesigner由于稍显复杂,故未采用.

为什么关系中不允许有重复元组?可是我的程序验证却可以出现呢？

如果关系中有重复元组，那么就无法用键来标识唯一的元组。因此在关系模型中对关系作了限制。可是我在使用中的上述关系都没用到键约束。所以他们可以出现相同的元组。

文中使用了两种流行的数据库验证为了不失一般性。