ZUCC | HZCU 数据库原理 卷面题
1.ER设计题
考点:
1.1 基本元素:
基本元素:实体,属性,联系
实体和联系可以拥有属性
联系分为三类:
一对一 一对多 多对多
1.2 主码,外码:
主码,外码的概念
主码,候选码:唯一的标识一个元组的属性组的值
外码:其他关系(有时也可以包括本关系,例如学生(学号,班长)这个例子,班长是这个关系的外码(由学号表示,))的主码
例题:
给出描述,要求:
1.画出ER图
2.将ER图转换为关系模式,标识出外码和主码
2.SQL题
考点:
2.1 基本表:
新建基本表:
create table <TableName>(
COL1 Type1 [Limits],
COL2 Type2 [Limits],
...,
[Limits| primary key (COL.),
foreign key (Col..) references <Another_TableName>(COL.)]
);
修改基本表
alter table <TableName>
[add [New_col] <New_Col><New_Type> ][Limits]
[add <Limits>]
[drop [Old_col] <Old_col>][Limits]
[alter column <Col> <Type>][Limits]
增删查改:
//增删查改:
//增
insert into <TableName> values(?,?,?,?)
//删
delete from <TableName> where <Limits>
//查
select <Col><>... from <TableName>
where <Limits>
group by <Col> having <expression>
order by <Col> /DESC/ASC
//改
update <TableName> set <Col> where <Limits>
2.2 视图
新建视图:
create view <ViewName> as
select <Col><>... from <TableName>
where <Limits>
group by <Col> having <expression>
order by <Col> /DESC/ASC
2.3 授权:
/*授予*/
grant <Rights><..> /*like select; update (<Col>); insert; delete*/
on table <TableName> [col] ...(maybe)
to <U1>...
with grant option /*permit this user to grant this rights to other user*/
/*收回*/
revoke <Rights><..> /*like select; update (<Col>); insert; delete*/
on table <TableName> [col] ...(maybe)
from <U1>... cascade/*revoke all the rights from this user*/
例题:
Room(客房信息表)
代码 | 描述 | 数据类型 | 长度 | 约束条件 |
---|---|---|---|---|
rNo | 房间编号 | VARCHAR | 20 | 主码 |
rType | 房间类型 | VARCHAR | 50 | |
rPrice | 房价 | FLOAT |
Customer(顾客信息表)
代码 | 描述 | 数据类型 | 长度 | 约束条件 |
---|---|---|---|---|
cNo | 顾客编号 | VARCHAR | 20 | 主码 |
cName | 姓名 | VARCHAR | 50 | 不能为空 |
cAge | 年龄 | INT | ||
cTel | 电话 | VARCHAR | 20 |
Booking(订房信息表)
代码 | 描述 | 数据类型 | 长度 | 约束条件 |
---|---|---|---|---|
rNo | 职工号 | VARCHAR | 20 | 主属性,外码 |
cNo | 顾客编号 | VARCHAR | 20 | 主属性,外码 |
bDate | 入住日期 | DATE | 主属性 | |
bDays | 入住天数 | INT | 大于0 |
- 给出“订房信息表”的完整建表语句;
create table Booking(
rNo varchar(20) unique,
cNo varchar(20) unique,
bDate datetime unique,
bDays smallint check(bDays>0),
primary key(rNo,cNo,bDate)
foreign key(rNO) references to Room
foreign key(cNo) references to Customer
);
- 查询每次入住天数大于3天的顾客姓名和电话;
select Customer.cName, Customer.cTel from Customer,Booking
where Customer.cNo = Booking.cNo and bDays>3
- 查询没有被预定过的房间编号(要求使用相关子查询,否则不得分);
select rNo from Room where rNo not in (select rNo from Booking)
- 统计不同年龄的顾客的订房信息,显示:年龄,平均入住天数;
select cAge, avg(bDays) from Booking, Customer
where Booking.cNo=Customer.cNo group by cAge
- 将房间类型为’家庭房’的房间价格下调10%;
update Room set rPrice = 0.9*rPrice where rType like '家庭房'
- 创建视图V_INFO:’2020-4-30’后入住的顾客姓名,房间类型,入住天数;
create view V_INFO as
select cName,rType,bDays from Room,Booking,Customer
where Booking.cNo = Customer.cNo and Room.rNo = Booking.rNo
and bDate >= to_date('2020-4-30','yyyy-MM-dd')
- 将“客房信息表”的查询权限,赋给所有用户;
grant select on table Room to public
- 向“客房信息表”中插入一条新记录:房间编号为3028,房间类型为’三人间’,价格为320元;
insert into Room values('3028', '三人间',320.0)
- 删除年龄小于18岁的顾客的订房记录。
delete from Booking where cNo in (select cNo from Customer where cAge<18)
3.关系代数应用题
考点:
3.1 编写关系代数:
选择: σ
σ
C
o
l
N
a
m
e
(
T
a
b
l
e
N
a
m
e
)
σ_{ColName}(TableName)
σColName(TableName)
投影:Π
Π
C
o
l
N
a
m
e
(
T
a
b
l
e
N
a
m
e
)
Π_{ColName}(TableName)
ΠColName(TableName)
连接:⋈
<
R
>
⋈
R
Θ
S
<
S
>
<R>⋈_{RΘS}<S>
<R>⋈RΘS<S>
除法:÷
R
÷
S
R÷S
R÷S
3.2 查询树的启发式优化
1.尽可能先做选择运算
2.把投影和选择运算同时进行
3.把投影同其前或后的双目运算结合起来
4.把某些选择同在它前面要执行的笛卡尔积结合起来成为一个连接运算
5.找出公共子表达式
所得到的优化后的查询树有以下特征:
1.树叶一定是表
2.连接节点一定是连接。
3.根节点一点是投影。
4.在树叶之上,如果需要做选择,一定要在连接前先做选择。
4 范式应用题
第一范式(1NF):要求数据库表的每一列都是不可分割的原子数据项。
例:
学号 | 姓名 | 性别 | 家庭信息 |
---|---|---|---|
S001 | Matchalatter | 男 | 三人,浙江 |
可见:在"家庭信息"一属性有两个信息点。该关系不符合NF1
可修改为:
学号 | 姓名 | 性别 | 家 | 户籍 |
---|---|---|---|---|
S001 | Matchalatter | 男 | 三人 | 浙江 |
可见:每一项有一个信息点。该关系符合NF1
第二范式(2NF):在1NF的基础上,非码属性必须完全依赖于候选码
此处再次增加一下关于 候选码,主码,主属性,非主属性的定义:
码 主码 候选码:唯一的标识一个元组的属性组的值
主属性:任何一个候选码的属性
非主属性:不包含任何一个候选码的属性
外码:其他关系(有时也可以包括本关系,例如学生(学号,班长)这个例子,班长是这个关系的外码(由学号表示,))的主码
例:
读者号 | 图书号 | 读者姓名 | 借阅时间 | 归还时间 |
---|---|---|---|---|
S001 | R001 | Matchalatter | 2022/06/12 | Null |
可见:对于此关系R,R的主码是(“读者号”,“图书号”)。
对于"借阅时间"和"归还时间"这两个属性,他们完全依赖于主码
而对于"读者姓名"这一属性
它部分依赖于主码(“读者号”,“图书号”)完全依赖于主码的真子集"读者号"
所以该关系不符合NF2
可修改为两个关系:
读者号 | 图书号 | 借阅时间 | 归还时间 |
---|---|---|---|
S001 | R001 | 2022/06/12 | Null |
读者号 | 读者姓名 |
---|---|
R001 | Matchalatter |
可见:
对于关系一,满足了"借阅时间"和"归还时间"这两个属性完全依赖于主码
对于关系二,也满足了"读者姓名"完全依赖于"读者号"
所以,这两个关系满足NF2
第三范式(3NF):在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)
例:
学生号 | 学生姓名 | 所在系 | 系主任号 |
---|---|---|---|
S001 | Matchalatter | CS | T_CS001 |
可见:所有属性都完全依赖于学生号,所以满足2NF
**但是" 系主任号 "直接依赖的是 “所在系” **
所以,该表不符合3NF
可修改为两个关系:
学生号 | 学生姓名 | 所在系 |
---|---|---|
S001 | Matchalatter | CS |
所在系 | 系主任号 |
---|---|
CS | T_CS001 |
可见:
对于关系一,满足了"学生姓名"和"所在系"这两个属性仅完全依赖于主码
对于关系二,也满足了"系主任号"仅完全依赖于所在系"
所以,这两个关系满足NF3