数据库知识总结(二)

本文借鉴了http://jacki6.iteye.com/blog/774866 

参照完整性：一个关系中给定属性集上的取值也在另一个关系的某一个属性集的取值中出现。

每个属性可能取值的域，域约束。

create domain AccountType char(1)

                    constraint account-type

                               check(value in ('Checking','Saving')

create table depositor

      (customer-name char(20),

       account-number  char(20),

       primary key (customer-name,account-number)

       foreign key(customer-name) references customer

       check(balance>0))

 

触发器

指明什么条件（触发器被检测的事件和触发器执行满足的条件）下触发器执行，采取什么动作

插入电话号码值为空用null替代

create trigger setnull-trigger before update on r

referencing new row as nrow

for each row

when nrow.phone-number=''

set nrow.phone-number=null

 

 关系数据库的设计

第一范式：某个域不可分就被认为是原子的，关系模式R的所有属性都是原子的。也就是无重复的列。

第二范式：非主属性完全依赖于主属性（主键），消除部分子函数依赖。完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

这个数据库表不满足第二范式，因为存在如下决定关系：

(课程名称) → (学分)

(学号) → (姓名, 年龄)

即存在组合关键字中的字段决定非关键字的情况。

第三范式：属性不依赖于其他非主属性，消除传递依赖。

如果关系模式R是第二范式，且每个非主属性都不传递依赖于R的候选键，则称R为第三范式模式。

谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。

(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)

这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：

(学号) → (所在学院) → (学院地点, 学院电话)

 

BC范式：若关系模式R是第一范式，且每个属性都不传递依赖于R的候选键。

(仓库ID, 存储物品ID) →(管理员ID, 数量)

(管理员ID, 存储物品ID) → (仓库ID, 数量)

所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。