Ayy3

时间停止吧,你是多么的美丽

保研记录

本人情况:

  • 本科院校:江苏某top4!
  • 本科专业:AI
  • 排名:1/87
  • 四级:595,六级:538
  • 竞赛:ICPC银若干,CCPC铜若干,JSCPC金银,CSP440,cf两紫名号(?)
  • 科研:无
  • 项目:水项目
  • 国奖,CCF优大(这俩感觉基本没用)
  • 偏就业向,未来偏向于做引擎开发。因此梦校是软微、南软和人大信专。

总结为A批,而且又菜又爱玩,不仅没拿到金牌,还因为这沟槽的网瘾,没有深入参与过含金量高的项目。不过好在大三因为一个队友去和大一的两位noi✌组队,另一个队友退出了,然后我也选择了退役,转去卷课内,得以保住rk。但就夏令营的情况来看,保rk弃acm是我做的一个非常正确的选择。

夏令营之前:

虽然我是AI专业,但是我对AI提不起一点兴趣,尤其是CV、NLP这些(别问我为什么没转专业)。大二ICPC赛季结束的时候被一个学长忽悠去做AI相关的科研,后面还进了某CV组,体会了一下开组会读paper做pre的氛围,也是感到十分不快。

后面大三上的时候考虑做过sys,虽然谈不上非常喜欢,但至少不反感。不过从大三开始入门sys说实话感觉有点晚了,而且AI的培养计划并不注重对计算机系统能力的培养,导致我甚至连CPU指令流水线这种基本概念都不清楚,加上保rk要学讨厌的课程,我没办法分配出太多精力出来,因此学术梦碎。

为什么选择就业向呢?首先我本身是一名ACM选手,非常喜欢coding。其次我也是个造轮子爱好者兼游戏爱好者,对工程较感兴趣,也开发过一些小型3D游戏。不过由于大学期间大部分时间在卷ACM和课内(基本在码python,pytorch那些,当调包侠),没有多少实践的机会(面南大的时候老师也指出了我这个问题,哈哈),因此也希望读研期间能精进自己的engineering能力。

总结来看,作为一名ACM败犬,我在选择读研方向上也是经历了一波三折的过程。期间经历了无数次痛苦,包括误入歧途、自我怀疑、被学长yygq。尤其是大三选择ACM退役的那段时间,感觉自己大学中唯一一件有意义的事情与我断绝了,只剩下一堆不喜欢的AI课程要卷,也不知道自己接下来的路该怎么走,每一步所做出的选择是否是正确的。不过好在就保研而言的结果还是能让我满意的。

夏令营情况:

学校 学院 类型 入营 结果
南京大学 cs 专硕 过线上测试,放弃线下
复旦大学 cs 专硕 撞nju和两门期末,放弃
南京大学 ai 学硕 放弃,不喜欢AI,但是因为是nju就报了,nju梦校
吉林大学 se 专硕 开的早,投着练练手,最后也是直接鸽了
哈尔滨工业大学(深圳) cs 专硕 × 正常,清北bar,投着玩
同济大学 cs 专硕 优营(第一个优营,感谢同济!)
上海交通大学 se 学硕 ipads太难,没sys基础,其余组方向不感兴趣,放弃
南京大学 se 专硕 优营,梦校
中山大学 cs 专硕 × ???海营我都没入?
中国人民大学 信院 专硕 撞nju,加上考虑到往年优营率低,放弃

可以看到,多亏了大三上学期选择放弃ACM,得以保住rk1,让我在没有任何科研项目的情况下入了很多营。但是实际上我只完整参加了两个,主要是今年和往年相比,夏令营的时间冲突的太多了,属于是大型车祸现场。特别是六月初得知ruc信院和南软冲突的时候,我真的有点破防。最后由于华五情节与优营率的考虑,选择了南软,鸽了ruc。

1. njucs

今年南计开的非常早,好像四月份就开了,然后五月初就截止报名。当时我根本没有做好准备,内心也是非常慌。

由于我夏令营的目标是南软,所以一开始是不想去南计的,因为按往年情况来看,南大cs,se,ai这三个夏令营只能去一个(njusz那里我不太清楚)。但是看绿裙说南大cs线上测不考虑冲突因素,可以放心参加,我就参加了(怎么说也是梦校)。

南计的线上笔试也算是著名的难,往年原题可以参考绿裙的github仓库(虽然很少)。范围大概是408+算法+编译原理+linux+其余杂项,题型是单选+多选,多选漏选超选错选皆不得分。我记得今年的题偏向于编译原理和数据结构。因为我本科AI的,很多课程没学过,因此大多数题都是蒙的,除去几个ACM中接触到的几个算法和数据结构(kmp,背包)。

结果比较出乎意料,过了:

然鹅后续放弃了。

2. tongji cs

本来是没想报同济的,但是绿裙里有个同济的宣传大使,说这个学校就业非常好什么的,再加上夏令营时间也比较好,没和其它学校冲突,我就报了。(不是)

然而没想到的是今年同济cs夏令营的bar非常高,整个学院只入了我一个人。最后只能孤身一人前往上海。

同济的考核非常硬核,机考+笔试408+英语笔试+英语口试+面试,五脏俱全。是计分制,满分350.

机考的话非常简单,第一题是给定一个字符串,然后对串的每个字母在其对应的位置(例如a对应第1列,z对应26列)一行一行输出。第二题是找给定数独九宫格的冲突位置。第三题是输出数字三角形。我大概花了十几分钟就做完了,但是后面静查的时候发现了第二题的一个bug,及时改正。

笔试408+英语,非常难,时间也特别赶。我记得大题后两题我都直接空着(分别是计组画什么数据通路,以及计网给定一个802帧分析其内容,ip地址,协议什么的)。英语是一道阅读理解,一篇论文。

可以参考:https://zhuanlan.zhihu.com/p/658346474

面试,有九个老师围着你坐,轮流提问。一开始是让我英语自我介绍两分钟,然后是让我英语说transformer的原理。后面就提问了一些项目和专业课的知识,我记得问了我系统调用和普通函数调用的区别。最后一个问题出乎我意料,一个老师问了我高数题(我记得是分部积分啥的),这我咋会?感觉我这个组比较压力面,然而另一个哥们的组感觉非常友好,问了很多生活问题,还有思政题。

结果没想到是优营,分数还挺高,满分350拿了二百八十几分,应该是稳offer了。

面试那天雨非常大,emmm

3. njuse

南软是我夏令营的最高目标,毕竟华五+两年制+放实习,太适合我这种就业鼠鼠了。

南软的bar也是很神奇,隔壁江苏top3的rk2+ACM银没入营,我校只入了软工的rk1和我(套磁了一个导师,可能捞了我进去),同院计科的rk1也没入。但是南软同时放了若干双非非rk1的金牌✌入营。现在想想,当初ICPC没拿金的我选择保住rk1,真是太明智了。

南软安排又紧又松。紧是因为我一天半就走完了夏令营流程,松是因为南软通知事项的方式很随意,就建个群,然后有通知了就@全体成员发消息,公告都不带发的,也没有流程pdf,感觉就非常敷衍。

南软考核也比较全,笔试+机试+面试。

笔试的内容有五项,顺序依次为离散数学(群论+图论的证明题)、软件工程(画状态图,软件测试)、操作系统(页式内存,PV操作)、计算机网络(DNS,ALOHA协议,求极限(啊?))和数据库系统(B+树索引,递归查询sql语句,事务undo+redo),各占20分。开卷,但是考的很偏,我很多都没做出来。

机试的话,今年是四道算法题,没有了往年的面向对象题。今年南软的机试题普遍反映非常难,和隔壁南计的机试题(没有算法题)形成鲜明对比,我记得第一题是给定已有的面额值 ,要求你求出最少的需要补充的额外面额值的个数,在每个面额值的使用次数小于等于一个给定值 的情况下,能够相加组合得到范围 内的所有数。第二题是要你用两个平行于坐标轴的不相交矩形来包围给定的二维点集,要求两个矩形的面积和最小。第三题是给定一个坐标轴,坐标轴的第二象限有 头牛,每头牛占据一个单位长度,左开右闭,并按照 的速度(这里的速度是每 瞬移一个单位,注意)朝着 +x 方向移动。然后你在原点朝着 +y 方向观察,问给定每头牛的坐标,及其速度,问最多有多少头牛经过你的视线。第四题是给定一个二维平面,平面上有字母,空白以及障碍,要求除去障碍,每一个行或每一个列内部的连续块(连续的字母与空,障碍隔开)形成的序列是一个回文串。求你能够确定的最多的空白对应的字母的坐标数量,并给出最终局面。

由于我是ACMer,AK了,全场快300人中有10个AK的。没有签到题,感觉对一般人比较不友好。四道题的难度大概在div1a, b这种。解法分别为数学+贪心,排序+枚举切割的横/纵坐标,离散化+线段树,BFS。

我记得笔试交卷的时候,大家动静很大。然后有个监考老师露出了诡异的笑容,说:“诶,你们先别叫,下午再叫,下午才是正菜(早上笔试下午机试),现在只是给你们开开胃。欸,下午你们叫也叫不出来,哈哈哈,那个才叫酸爽。”当时给我们都整懵逼了。

面试的话,虽然拿同济练过手,但是作为i人的我,还是很紧张。不过惊喜的是在面试前半个小时,我收到了同济优营的消息。拿到第一个offer的喜悦瞬间冲刷了我所有的焦虑,后续面试也不再紧张了。

具体面试内容也比较轻松,让你介绍你的项目经历,不问专业课。由于我的项目比较水,老师转而让我陈述大学期间做过的有意义的事情,我直接把我的ACM经历全炸出来,感觉老师也是比较感兴趣。期间问了我最喜欢的算法,我说树状数组,然后老师们似乎并不太清楚这个东西,我就大致介绍了一下它的功能和原理。后面稍微批评了我项目实践能力较为缺乏。最后一个老师问了一些关于实验室横向的问题,也是畅所欲言。

当然面试内容具体情况分组考虑,有的组会压力面,比如作英语自我介绍,翻译英语,问软工那些模型(瀑布、螺旋、敏捷开发)什么的,因此建议充分准备。

最后也因为机试AK,没有悬念地优营了。说实话当初面完南软就觉得自己稳了,以至于过于自信,后续的sjtu软就没去(当然也有懒得读论文的原因)。但说实话不建议大家这么干,有点冒险(

预推免情况:

估计不会报名预推免了,主要是除了ruc信院,感觉没有比南软更适合我的去处了。可惜ruc不开预推免,呜呜呜呜。

顺带一提,今年软微保研似乎改革,变成纯科研向了,鼠鼠top2梦碎。

数据库完整性

实体完整性

create table中用primary key定义

例:创建学生表Student,将Sno属性定义为主码:

1
2
3
4
5
6
7
8
create table student(
sno char(8),
sname char(20) unique,
ssex char(6),
sbirthdate date,
smajor varchar(40),
primary key(sno)
);

插入或对主码列进行更新操作时,关系数据库管理系统按照实体完整性规则自动进行检查。

  • 检查主码值是否唯一
  • 检查主码的各个属性是否为空

这种检查操作需要 遍历每一条记录,十分耗时。因此关系数据库管理系统一般都在主码上自动建立一个索引。例如B+树索引。

参照完整性

在create table中用foreign key短语定义哪些列为外码。

用references短语指明这些外码参照哪些表的主码。

例:关系SC中(Sno, Cno)是主码,Sno、Cno分别参照Student表的主码和Course表的主码。

1
2
3
4
5
6
7
8
9
10
create table sc(
sno char(8),
cno char(5),
grade smallint,
semester char(5),
teachingclass char(8),
primary key (sno, cno),
foreign key (sno) references student(sno),
foreign key (cno) references course(cno)
);

一个参照完整性将两个表中的相应元组联系起来。对被参照表和参照表进行增删改查操作时可能会破坏参照完整性,必须进行检查。

例:

  • 向SC表中增加一个元组,该元组的Sno属性值在表Student中找不到一个元组,其Sno属性值与之相等。
  • 修改SC表中的一个元组,情况如上
  • 从Student表中删除一个元组,造成SC表中某些元组的Sno属性值在Student中找不到一个元组对应
  • 修改Student表中的一个元组,情况如上

参照完整性违约处理:

  • 拒绝执行:一般为默认策略
  • 级联操作:当删除或修改被参照表的一个元组导致与参照表的不一致,则删除或修改参照表中的所有导致不一致的元组
  • 设置为空值:当删除或修改被参照表的一个元组导致不一致,则将参照表中所有造成不一致的元组的对应属性设置为空值

用户定义的完整性

针对某一具体应用的数据必须满足的语义要求。

属性上的约束

create table中定义属性约束

  • 列值非空 (not null)
  • 列值唯一 (unique)
  • 检查列值是否满足一个条件表达式 (check短语)

元组上的约束

在create table语句中可以用check短语定义元组间不同属性需满足的限制

完整性约束命名子句

constraint <完整性约束名> <完整性约束>

修改表中的完整性限制

使用alter table语句

例:

1
2
alter table student
add constraint c1 check(sno between '114514' and '1919810');

触发器

挖坑


作业

假设有下面两个关系模式

职工(职工号,姓名,出生日期,职务,工资,部门号),其中职工号为主码

部门(部门号,名称,经理姓名,电话),其中部门号为主码

用SQL定义这两个关系模式,要去在模式中完成以下完整性约束的定义:

  1. 定义每个模式的主码
  2. 定义参照完整性约束
  3. 定义职工年龄不超过65岁

oracle不支持constraint带有变量,这里需要使用触发器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
drop table 职工;
drop table 部门;

create table 部门(
部门号 char(8) primary key,
名称 varchar(20),
经理姓名 varchar(20),
电话 varchar(20)
);

create table 职工(
职工号 char(8) primary key,
姓名 varchar(20),
出生日期 date not null,
职务 varchar(20),
工资 decimal(10, 2),
部门号 char(8),
constraint fk_部门 foreign key(部门号) references 部门(部门号)
);

create or replace trigger ck_age
before insert or update on 职工
for each row
begin
if(extract(year from current_date) - extract(year from :new.出生日期) > 65) then
raise_application_error(-114514, '职工年龄不应超过65岁');
end if;
end;
/

测试:

1
2
3
4
5
insert into 部门 values('88488848', 'test1', 'name1', '114514');
insert into 职工 values('66666666', 'name2', TO_DATE('1980-01-15', 'YYYY-MM-DD'), 'job1', '1145.14', '88488848');
insert into 职工 values('66666666', 'name2', TO_DATE('1980-01-15', 'YYYY-MM-DD'), 'job1', '1145.14', '88488849');
insert into 职工 values('66666667', 'name2', TO_DATE('1980-01-15', 'YYYY-MM-DD'), 'job1', '1145.14', '88488849');
insert into 职工 values('66666667', 'name2', TO_DATE('1880-01-15', 'YYYY-MM-DD'), 'job1', '1145.14', '88488848');

前两行正确,后三行应出现错误:

摘自《数据库系统概论》第六章

关系数据理论

1. 问题

针对一个具体问题,如何构造一个适合它的数据模式

即应该构造几个关系,每个关系由哪些属性组成等。

不好的关系模式:

  • 数据冗余度太大,浪费存储空间
  • 更新异常
  • 插入异常
  • 删除异常

数据依赖

属性值间的相互关联。是数据内在的性质,是语义的体现

主要介绍函数依赖。

不合适的数据依赖,容易造成上述的4个问题。

2. 规范化

2.1 函数依赖

给定关系模式R(U, F)(本章忽略D域,DOM属性到域的映射),X和Y是U的子集。若对于R(U, F)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则称“X函数确定Y”或“Y函数依赖于X”,记作

X称为这个函数依赖的决定属性组,也称为决定因素

函数依赖是语义范畴的概念,只能根据数据的语义来确定函数依赖。例如“姓名->年龄”这个函数依赖只有在学生不重名的情况下成立。数据库设计者可以对现实世界作强制的规定。

函数依赖是指关系模式R在任何时刻的关系实例均要满足的约束条件。

非平凡函数依赖

只讨论非平凡函数依赖。平凡函数依赖没有意义。

完全函数依赖:若 ,但对于X的任何一个真子集X‘,都有 ,则称Y对X完全函数依赖,记作 。否则称为部分函数依赖,记作

传递函数依赖:在R(U, F)中,如果 ,则称Z对X传递函数依赖。记作

注意这里不能存在 ,否则X与Y是等价的,Z直接依赖于X。

2.2 码

设K为关系模式R(U, F)中的属性或属性组合。若 ,则称K为R的一个候选码

,则K称为超码。

若关系模式R有多个候选码,则选定其中的一个作为主码

主属性:包含在任何一个候选码的属性。

全码:整个属性组U是码。

外码:关系模式R的属性(组)X并非R的码,但X是另一个关系模式的码,则称X是R的外码。

主码与外码一起提供了表示关系间联系的手段。

2.3 范式 (不允许表中有表)

关系数据库的关系必须满足一定的要求。满足不同程度要求的为不同范式

一个低一级范式的关系模式,通过模式分解,可以转换为若干个高一级范式的关系集合。这种过程叫做规范化

1NF

如果一个关系模式R的所有属性都是不可分的数据项,则

不允许表中有表。

2.4 2NF (非主属性不允许部分依赖)

,且每一个主属性完全函数依赖于任何一个候选码,则

采用投影分解法可将一个1NF关系分解为多个2NF关系,可一定程度上减轻原1NF关系存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。但并不能完全消除。

不是很懂这里非主属性的意义所在。

2.5 3NF (非主属性不允许传递依赖)

设关系模式 ,若R中不存在这样的X、属性组Y及非主属性Z ,使得 成立,,则称

不是很懂这里Z是非主属性的意义所在。

不允许传递依赖,自然就不允许部分依赖。

2.6 BCNF(不依赖于非码)

设关系模式 ,若 时X必含有码,则

BC范式首先解决了3NF中主属性存在的部分依赖问题,例如3NF中可能某候选码中的一个子集可以—>另一个主属性,但是BCNF要求必须是码或码的超集才可以->。其次解决了3NF中主属性存在的传递依赖问题,这个也是类似的情况。

2.7 多值依赖

给定关系模式R(U,F),X,Y,Z是U的子集,且Z=U-X-Y。关系模式R中多值依赖 成立当且仅当对R的任意关系r给定的一对(x,z)值,有一组Y的值,这组值仅仅决定于x值而与z值无关。

等价定义

非平凡多值依赖:X->->Y,且Z不为空。若Z为空则为平凡多值依赖。

多值依赖的性质:

  • 对称性:若X->->Y,则X->->Z。(可以画个二分图???)
  • 传递性:若XYZ=U,X->->Y,Y->->Z,则X->->Z-Y
  • 函数依赖是多值依赖的特殊情况
  • 懒得写了

2.8 4NF

关系模式 ,如果对于R的每个非平凡多值依赖 ,X都含有码,则

4NF允许的非平凡多值依赖实际上是函数依赖。

3. 数据依赖的公理系统

模式分解算法的理论基础。函数依赖有一个有效且完备的公理系统——Armstrong公理系统

用途:

  • 求给定关系模式的码
  • 从一组函数依赖求得蕴含的函数依赖

逻辑蕴含:给定关系模式R(U, F),其任何一个关系r,若函数依赖X->Y都成立,则称F逻辑蕴含X->Y。

3.1 Armstrong公理系统

对关系模式 R(U, F) 有以下推理规则:

  • 自反律:若 ,则 为F所蕴含。
  • 增广律:若 为F所蕴含,且 ,则 为F所蕴含。
  • 传递律:若 为F所蕴含,则 为F所蕴含。

3.2 导出规则

可通过以上三条推理规则推出以下三条推理规则:

  • 合并规则:由
  • 伪传递规则:由
  • 分解规则:由

根据合并和分解规则,可得引理

成立的充分必要条件是 成立。

3.3 函数依赖闭包

闭包:在关系模式R(U, F)中为F所逻辑蕴含的函数依赖的全体叫做F的闭包,记为

属性集闭包:

判定 即判定

3.5 函数依赖集等价

如果 ,就说函数依赖集F覆盖G,或者F与G等价。

引理:F与G等价的充要条件是

3.6 最小依赖集

如果函数依赖集F满足:

  • F中任一函数依赖的右部仅含有一个属性。
  • F中不存在这样的函数依赖X->A,使得F与F-{X->A}等价。(即F中的函数依赖均不能由F中其他函数依赖导出)
  • F中不存在这样的函数依赖X->A,X有真子集Z使得F-{X->A}U{Z->A}与F等价。(F中各函数依赖左部为最小属性集)

则F为极小函数依赖集。

定理:每一个函数依赖集F均等价于一个极小函数依赖集,此 为F的最小依赖集

F的最小依赖集不一定是唯一的

求最小依赖集步骤:

  • 将F中的所有依赖右边化为单一元素
  • 去掉F中的所有依赖左边的冗余元素
  • 去掉F中的所有冗余关系

4. 保持函数依赖的模式分解

关系模式 的一个分解是指 ,(其中 ,并且没有 ),即

若满足 ,那么该分解是一个保持函数依赖的分解。(可以用上面3.5节中的引理来证明一个分解是否保持函数依赖)

4.1 转换为3NF

1、极小化处理

2、按照相同左部进行分组

可以证明得到的一定是一系列3NF,具体证明在书P190-191


作业

1、设有关系模式 ,其中

(1). 计算

解:设

计算 ,逐一扫描 中的各个函数依赖,得 。因此

计算 ,逐一扫描 中的各个函数依赖,发现无额外元素,即

因此

计算 ,逐一扫描 中的各个函数依赖,得 。因此

计算 ,逐一扫描 中的各个函数依赖,发现无额外元素,即

因此

(2). 求 的所有候选码,并说明理由。

解:求出单个属性所对应的属性闭包:

由于只有 包含 ,因此候选码内部必有

可得

通过额外枚举,可以发现只有上述 满足候选码性质。

(3). 最高满足第几范式?为什么?

解:由于 ,因此 部分依赖于候选码 ,不满足第二范式条件。

因此 最高满足第一范式。

2、设有关系模式 ,其中:,求 的最小依赖集。

解:

首先将所有函数依赖的右边转换为单一属性:

然后去除所有函数依赖的左边的冗余属性:

考虑函数依赖 ,由于 ,因此 为冗余属性。故进一步简化:

考虑 是否冗余:不冗余

考虑 是否冗余:不冗余

考虑 是否冗余:可从 与Armstrong推出,故冗余

此时

考虑 是否冗余:不冗余

考虑 是否冗余:可从 得出,故冗余

此时

考虑 是否冗余:不冗余

考虑 是否冗余:不冗余

故得到 的最小依赖集:

3、设有关系模式 ,其中:,试问 是否成立,若成立请给出证明过程。

解:成立。证明如下:

计算 ,逐一扫描 中的各个函数依赖,得 ,故

计算 ,逐一扫描 中的各个函数依赖,得 。因此可知 ,根据Armstrong公理的性质,可得出

4、试用Armstrong公理系统推导出下面的推理规则:若 ,则有

解:首先根据增广率,可由

再根据传递率,可由

5、已知学生关系模式 。其中: 学号、 姓名、 系名、 系主任名、 课程、 成绩。

(1)写出关系模式 的基本函数依赖和主码。

解:

主码:

(2)原关系模式 为第几范式?为什么?分解成高一级范式,并说明为什么?

解:为第一范式。首先对于关系模式 ,其所有属性都是不可分的属性,满足第一范式定义。

其次在该关系模式中,非主属性 部分函数依赖于主码 ,不满足第二范式定义。故 为1NF。

可以进行模式分解:。对于新关系模式 ,其主码为 ,故不存在部分函数依赖(但是存在传递依赖 ),故为第二范式。对于新关系模式 ,其主码为 ,不存在部分函数依赖,也为第二范式。

(3)将关系分解成第三范式,并说明为什么?

解:在(2)的基础上进一步分解:

对于 ,其只存在函数依赖 ,不存在传递依赖,故为第三范式。

对于 ,其只存在函数依赖 ,不存在传递依赖,故为第三范式。

对于 ,其只存在函数依赖 ,不存在传递依赖,故为第三范式。

6、设有关系模式 ,其中6个属性分别为学生的学号、姓名、年龄、教师的姓名、课程名及课程成绩。假设学生有重名,课程名也可能有重名。又假设教师无重名,且每个教师只教一门课,但一门课可有几个教师同时开设。当某个学生选定某门课后,其上课教师就固定了。

(1)试给出R的所有函数依赖(平凡函数依赖和部分函数依赖可不写)

解:

(2) 试给出R的所有候选码。

解:

不存在除 外的属性组被 依赖,故候选码必然包含 。也因此可推出候选码不包含

求出单个属性所对应的属性闭包:

可知 ,且

同样 ,且

除此之外,无其余候选码。

7、试证明任何一个二目关系模式 都属于

证明:

分以下三种情况讨论:

  • 关系模式 主码为 ,即全码,此时显然为
  • 主码为 ,此时必有 ,且 包含在码中,故满足 的定义。
  • 主码为 ,理由同上

证毕。

8、若 ,试证明

证明:利用反证法。

假设关系 中存在码 ,属性组 和非主属性 ,满足 ,即不满足 的定义。

由于 ,故 必包含码。

由于 包含码,故 能够决定其余属性组,包括 ,即 。这与假设中的 矛盾,故假设不成立。(本质上是通过让 等价来消除传递依赖。)

因此

9、设属性 两两不相交,且 。已知:元组 在数据库中,请给出哪些元组也必然在数据库中。

解:根据 ,可得出新的两个元组:,

根据 , 可得出新的四个元组:

10、给定关系 如下:

A B C D E

试给出至少2个非对称多值依赖。注:仅写结果不分析不得分。

解:首先有多值依赖 ,这是因为 相对于 有两个取值 ,且对于这两个取值,属性 都有对应属性值 ,即 取值只与 有关。

其次有多值依赖 ,这是因为 相对于 有四个取值 ,且对于这四个取值,属性 都有对应属性值 ,即 取值只与 有关。

数据库安全性

挖坑


作业(

有以下两个关系模式:

职工(职工号,姓名,年龄,职务,工资,部门号)

部门(部门号,名称,经理名,地址,电话号)

请用SQL的GRANT语句和REVOKE语句(加上视图机制)实现以下授权定义或存取控制功能:

首先建表:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
drop table 职工;
drop table 部门;

create table 职工(
职工号 VARCHAR(10) PRIMARY KEY,
姓名 VARCHAR(10),
年龄 SMALLINT,
职务 VARCHAR(12),
工资 NUMERIC(8, 2),
部门号 VARCHAR(10)
);
create table 部门(
部门号 VARCHAR(10) PRIMARY KEY,
名称 VARCHAR(16),
经理名 VARCHAR(10),
地址 VARCHAR(50),
电话号 VARCHAR(11)
);
insert into 职工 values('001', '王明', 35, '总经理', 8500, 'BM001');
insert into 职工 values('002', '李勇', 29, '架构师', 6200, 'BM002');
insert into 职工 values('003', '刘星', 30, '程序员', 5450, 'BM003');
insert into 职工 values('004', '张新', 32, '程序员', 5850, 'BM003');
insert into 职工 values('005', '周平', 30, '管理员', 6100, 'BM001');
insert into 职工 values('006', '杨兰', 24, '设计师', 4900, 'BM002');

insert into 部门 values('BM001', '部门一', '经理一', '地址一', '001');
insert into 部门 values('BM002', '部门二', '经理三', '地址二', '002');
insert into 部门 values('BM003', '部门三', '经理三', '地址三', '003');

创建用户:

1
2
3
4
5
6
7
8
9
10
create user c##wangming identified by 114514;
create user c##liyong identified by 114514;
create user c##liuxing identified by 114514;
create user c##zhangxin identified by 114514;
create user c##zhoupin identified by 114514;
create user c##yanglan identified by 114514;

grant connect, resource to c##wangming, c##liyong;
grant connect, resource to c##liuxing, c##zhangxin;
grant connect, resource to c##zhoupin, c##yanglan;

(1)用户王明对两个表有select权限。

1
2
grant select on 职工 to c##wangming;
grant select on 部门 to c##wangming;

(2)用户李勇对两个表有insert和delete权限。

1
2
grant insert, delete on 职工 to c##liyong;
grant insert, delete on 部门 to c##liyong;

(3)每个职工只对自己的记录有select权限。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
create view view_wangming as select * from 职工 where 姓名 = '王明';
grant select on view_wangming to c##wangming;

create view view_liyong as select * from 职工 where 姓名 = '李勇';
grant select on view_liyong to c##liyong;

create view view_liuxing as select * from 职工 where 姓名 = '刘星';
grant select on view_liuxing to c##liuxing;

create view view_zhangxin as select * from 职工 where 姓名 = '张新';
grant select on view_zhangxin to c##zhangxin;

create view view_zhoupin as select * from 职工 where 姓名 = '周平';
grant select on view_zhoupin to c##zhoupin;

create view view_yanglan as select * from 职工 where 姓名 = '杨兰';
grant select on view_yanglan to c##yanglan;

(4)用户刘星对职工表有select权限,对工资字段有更新权限。

1
2
grant select on 职工 to c##liuxing;
grant update(工资) on 职工 to c##liuxing;

(5)用户张新具有修改这两个表的结构的权限。

1
2
grant alter on 职工 to c##zhangxin;
grant alter on 部门 to c##zhangxin;

(6)用户周平具有对两个表的所有权限,并具有给其他用户授权的权限。

1
2
grant all privileges on 职工 to c##zhoupin with grant option;
grant all privileges on 部门 to c##zhoupin with grant option;

(7)用户杨兰具有从每个部门职工中select最高、最低、平均工资的权限,但不能查看每个人的工资:

1
2
3
4
5
6
create view emp_sal as
select 部门号, max(工资) "最高工资", min(工资) "最低工资", avg(工资) "平均工资"
from 职工
group by 部门号;

grant select on emp_val to c##yanglan;

计网——应用层复习

应用层是计算机网络体系结构的最顶层,是设计和建立计算机网络的最终目的。

客户/服务器方式(C/S方式)和对等方式(P2P方式)

网络应用程序运行在处于网络边缘的不同的端系统上,通过彼此的通信来共同完成某些任务。

开发一种新的网络应用首先要考虑的问题就是网络应用程序在各种端系统上的组织方式和它们之间的关系

客户/服务器方式

对等方式

动态主机配置协议DHCP

  • 互联网广泛使用的DHCP提供了即插即用联网机制
  • 这种机制允许一台计算机加入新的网络和获取IP地址,而不用手工配置

DHCP工作过程

DHCP使用客户-服务器方式

  • 需要IP地址的主机在启动时就向DHCP服务器广播发送发现报文(DHCP DISCOVER),这时该主机就成为DHCP客户。
  • 本地网络上所有主机都能收到此广播报文,但只有DHCP服务器才回答此广播报文
  • DHCP服务器先在其数据库查找该计算机的配置信息。若找到,则返回找到的信息。否则从服务器的IP地址池(address pool)中取一个地址给该计算机。DHCP服务器的回答报文叫做提供报文(DHCP OFFER)

DHCP工作方式

  • DHCP使用客户-服务器方式,采用请求/应答方式工作。
  • DHCP基于UDP工作(因为TCP不支持广播???),服务器运行在67号端口,DHCP客户运行在68号端口。

DHCP交互过程

首先,DHCP客户广播发送DHCP发现报文,包含

  • 事务ID
  • DHCP客户端的MAC地址

封装该报文的IP数据报的IP地址位0.0.0.0,目的地址为广播地址255.255.255.255

DHCP服务器收到DHCP发现报文后,根据其中封装的DHCP客户端的MAC地址来查找自己的数据库,如果查到匹配信息,则使用这些配置信息来构建并发送DHCP提供报文,如果没有则采用默认配置信息来构建报文并发送。

DHCP服务端将广播发送DHCP提供报文(DHCP OFFER)

  • 事务ID:DHCP客户端会与之前DHCP发送报文的事务ID进行对比,来判断该DHCP报文是否是自己的
  • 源IP地址:服务器的IP 目的IP地址:广播地址

这里DHCP客户可能会收到不止一个DHCP提供报文,会从中选择一个,一般选择先到的,并向所选择的DHCP服务器发送DHCP请求报文。

源地址:0.0.0.0,因为此时DHCP客户需要征求服务器同意,才可使用获得的IP

目的地址:广播地址,这样可以一次性通知所有DHCP服务器,告知它们是否把它们作为自己的DHCP服务器

所选择的DHCP服务器接收该请求,向DHCP客户发送DHCP确认报文

DHCP客户收到该报文后,就可以使用租用的IP地址。在使用前还会进行ARP检测。

DHCP中继代理

idea:给路由器配置DHCP服务器的IP地址,使之成为中继代理,这样就不用在每一个网络上都设置DHCP服务器。

总结

域名系统DNS

DNS是一个分布式系统,使大多数域名都能在本地解析。

因特网采用层次树状结构的域名结构。域名的结构由若干的分量构成,各分量之间用“点”隔开,分别代表不同级别的域名:

可以看见,名称相同的域名,其等级未必相同。

DNS使用分布在各地的域名服务器来实现域名到IP地址的转换。

域名服务器可以划分为以下4个不同的类型:

域名解析分为递归查询和迭代查询。

DNS报文使用运输层的UDP协议进行封装,运输层端口号53.

文件传送协议FTP

  • FTP是因特网上使用得最广泛的文件传送协议
    • FTP提供交互式的访问,允许客户指明文件的类型和格式,并允许文件具有存取权限
    • FTP屏蔽各计算机系统的细节,因而适合于在异构网络中任意计算机之间传送文件

FTP采用C/S方式

FTP客户计算机可将各种类型的文件上传到FTP服务器计算机,也可以从FTP服务器计算机下载文件。

FTP基本工作原理

FTP服务器监听熟知端口(端口号21),使客户进程能够连接上。

FTP客户随机选择一个临时端口号与其建立TCP连接,这条TCP连接用于FTP客户和服务器之间传送FTP相关控制命令

FTP服务器使用自己的熟知端口号20与客户建立TCP连接,用于传送文件

这是主动模式:建立数据通道时,FTP服务器主动连接客户。

对比,被动模式的端口号由协商决定

电子邮件

邮件发送和接收过程

简单邮件传送协议(SMTP)

可以发现,非常麻烦,根本记不住

电子邮件的信息格式

邮件读取

基于万维网的电子邮件

万维网WWW

  • 万维网是一个大规模的、联机式的信息储藏所

  • 万维网用链接的方法可以非常方便地从互联网的一个站点访问另一个站点,这种访问方式称为“链接”

  • 万维网以C/S方式工作,浏览器是客户程序,万维网文档所在计算机运行服务器程序

URL

超文本传输协议HTTP

传输过程

  • 在万维网客户程序与万维网服务器程序之间进行交互的协议
  • 使用TCP连接
  • 每个万维网网点都有一个服务器进程,它不断地监听TCP的端口80,以便发现是否有浏览器向它发出连接建立请求
  • 一旦监听到连接建立请求并建立了TCP连接后,浏览器就向万维网服务器发出浏览某个页面的请求

HTTP报文格式

请求报文:

响应报文:

在原有的无状态的http协议上增添了功能

万维网cache和代理服务器

  • 在万维网中还可以使用缓存机制以提高万维网的效率
  • 万维网缓存也称为Web缓存,可位于客户机,亦可位于中间系统上(代理服务器)
  • Web缓存把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时,若发现这个请求与暂时存放的请求相同,就返回暂存的响应,而不需要按照URL的地址去访问因特网的资源。

假设原始服务器的文档被修改,这时候代理服务器的文档就过期了。因此原始服务器通常会为每个响应的对象设置一个修改时间字段有效日期字段

若过期,但代理服务器的文档与原始服务器的文档一致,则原始服务器发送不带主体的响应:

若不一致,则需要发送封装有最新文档的报文:

完结撒花

0%