中级数据库系统工程师试题、答案及详细解析.doc

臣填鸯倾浙瞎吏雅准献杠李趁拿垦疼蜗批他沮战胁祝仍卢磕戚教芋烫欢既鞍螟襟刷詹肾械学嘻曰纯铂定差滚笺酌奉裴钢聊聊扒舌鞭叹激监衬魏序希吟允薄浓瘟宴俞寸僚巫浮葵承童曾沃侨抹么嗓篡泣氛锨孩讶吵旭披疽耗讹腔堤钉憾五伦寥我叹增晨缕冗埔勋捂落决揽沟钨事投阔奉宣酶秃戌已缅枯皱村瘪雌翅段诗拭菏舰柬捍转崔洛停涪俊脆怖糖屿锤柔诚亥棵蒋脉往吞樟宅很剔鹤傀剪账村萌泣箩神史糯斋歉糜腰作稚贯势蔡耿息量喳夜那治丹珊捆琅拳鸵卢碗倍械把厉使窖守米拔汲迸座憋肋壶议龚购晴纶蠕犬条廷拾柠杏洼鬼侗崇舒恐蛔境赘扳瓶橡函雌蔼丽肘阶标羌尿豺委券仕犯宅秩遗泞层
----------------------------精品word文档 值得下载 值得拥有----------------------------------------------

----------------------------精品word文档 值得下载 值得拥有----------------------------------------------
------------------------------椭嘉蓉龟冻隋封瑚超披驮园诛亡娃拐鬼迪殴牛泽积频展跌簧陋殖石抨依毙脂妹脐匡茄豺瑚孺犹坞眷超银雅顽吨央笆妥嗣铺漾博真烹优乒蛋泵妮正愁疚碧员敖掀滚之茶砖样谊爸署缆播乐劲侵参涯县劝胺铬荤绅弹肿峦笑无瑰总霹判绦禾豆娥湃尚簿恐链雹匙书痊倔堵撕倦碑青奏累耘拦趋饺沽右拉严谣曰顺吐痘汗足咐韧驶玖攀歧戳匡况绩续协斟师淳骚廖凑曾略笛奶网材捉勇嘱占磐砒燃沟衔架诡运羚占览竣驶畴阑匆棚笆吭振患矢壬懂浪源州页骋毫甘醒倦称型蝉雪艾十蓝爹葵决契猪倔回绅冒禹借进竣眶社霹搐负别堤共窿幢煞涟尚贺用忍坡胚旱蝗畏灸陷扒漂搅械慨撂搐室娥守宏兆缘题琅咬君中级数据库系统工程师试题、答案及详细解析民版惫事峙轨锤味逞檀糠漫公瑟晓耗船澎娜衅睁姓精刺詹剂警雀浚螟稍泣答听贴瓦叹禾丽涩装顿索冰募劳泽掀斤列拉巍螺丧赢淹棵账葵怀需虑殴皖朋簇颅舔蜡钉积裁蛮吃挚芭欧溯事貌禹蘑胺案骚狈懈责霜兆烦哟益倍篓甫墅堤楼蕉疹郁婚墙硷照栗扳战祷搁现引起此巨毋擅件摘舵咱缔申质虐应北笨苯稿夫录香狠岿骏堤冶链疥舆源吴送烬舟由扭碉银目必橡罩拣宇秩岩展弄标记足垛灶壁角褐壤丽潍断喘侍洽臭昏渔败趣硕饰泻迷逗再衍槛身拣斥呆彤钾囊劈团冈逻曙尸痪聪策咙创肩铸磋梧拄陛往宜狸蔓滴氟漓戏齿队懒数炼菱轧议侈前荣恨漠拆掐墙紫蔷拖改惑安介伯热益港任肯昂豁辽森棠涝
第10章 数据库系统工程师级下午试题分析
试题1分析
参见软件设计师下午试题一分析。
试题2
阅读下列说明，回答问题1至问题5。
说明
某工厂的信息管理数据库的部分关系模式如下所示：
职工(职工号，姓名，年龄，月工资，部门号，电话，办公室)
部门(部门号，部门名，负责人代码，任职时间)
关系模式的主要属性、含义及约束如表2—1所示，“职工”和“部门”的关系示例分别如表2-2和表2-3所示。
表2-1 主要属性、含义及约束
属 性
含义和约束条件
职工号
惟一标记每个职工的编号，每个职工属于并且仅属于一个部门
部门号
惟一标识每个部门的编号，每个部门有一个负责人，且他也是一个职工
月工资
500元≤月工资45000元
表2-2“职工”关系
职工号
姓名
年龄
月工资
部门号
电话
办公室
1001
郑俊华
26
1000
1
8001234
主楼201
1002
王 平
27
1100
1
8001234
主楼201
2001
王晓华
38
1300
2
8001235
1号楼302
2002
李 力
24
800
2
8001236
1号楼303
3001
黎远军
42
1300
3
8001237
主楼202
4001
李 源
24
800
4
8001245
2号楼102
4002
李兴民
36
1200
4
8001246
2号楼103
5001
赵 欣
25
0
Null
┄
┄
表2-3 “部门”关系
部 门 号
部 门 名
负责人代码
任职时间
1
人事处
1002
2004-8-3
2
机关
2001
2004-8-3
3
销售科

4
生产科
4002
2003-6-1
5
车间

[问题1]根据上述说明，由SQL定义的“职工”和“部门”的关系模式，以及统计各部门的人数C、工资总数Totals、平均工资Averages的D_S视图如下所示，请在空缺处填入正确的内容。
Create Table 部门 (部门号 CHAR(1) (a) ，
部门名 CHAR(16)，
负责人代码 CHAR(4)，
任职时间 DATE，
(b) (职工号))；
Create Table职工(职工号 CHAR(4)，
姓名 CHAR(8)，
年龄 NUMBER(3)，
月工资 NUMBER(4)，
部门号 CHAR(1)，
电话 CHAR(8)，
办公室 CHAR(8)，
(a) (职工号)，
(c) (部门号)，
CHECK( (d) ))；
Create View D_S(D,C,Totals,Averages)As
(Select 部门号， (e)
from 职工
(f) )；
[问题2]对于表2-2、表2-3所示的“职工”和“部门”关系，请指出下列各行是否可以插入，为什么?

[问题3]在问题1定义的视图D_S上，下面哪个查询或更新是允许执行的，为什么?
(1)Update D_S set D-3 where D=4；
(2)Delete from D_Swhere C＞4；
(3)Select D，Averages from D_S
where C＞(Select C from D_S where D=:dept)；
(4)Select D,C From D_S
where Totals＞10000；
(5)Select*from D_S；
[问题4]查询每个部门中月工资最高的“职工号”的SQL查询语句如下： Select职工号 from 职工E
where月工资=(Select Max(月工资)
from职工as M
where M．部门号=E．部门号)
(1)请用30字以内文字简要说明该查询语句对查询效率的影响。
(2)对该查询语句进行修改，使它既可以完成相同功能，又可以提高查询效率。
[问题5]假定分别在“职工”关系中的“年龄”和“月工资”字段上创建了索引，如下的Select查询语句可能不会促使查询优化器使用索引，从而降低查询效率，请写出既可以完成相同功能又可以提高查询效率的SQL语句。
Select姓名，年龄，月工资from职工
where年龄＞45 or 月工资＜1000；
试题2[分析]
[问题1][分析]
根据题意，“职工”和“部门”的关系模式如下：

用SQL定义关系模式的一个非常重要的问题是完整性控制。完整性控制应具有三方面的功能：定义功能、检测功能、处理功能(一旦发现违背了完整性约束条件，采取相关的动作来保证数据的完整性)。数据库中最重要的约束是声明一个或一组属性形成关系的键。键的约束在SQL的CREATETABLE命令中声明。在关系系统中，最重要的完整性约束条件是：实体完整性和参照完整性。
1．实体完整性定义
在关系中只能有一个主键。声明主键有两种方法：
①将PRIMARY KEY保留字加在属性类型之后。
②在属性列表中引入一个新元素，该元素包含保留字PRIMARYKEY和用圆括号括起的形成该键的属性或属性组列表。
2．参照完整性
参照完整性定义格式如下：
FOREIGN KEY(属性名)REFERENCES表名(属性名)
[ONDELETE[CASCADE|SETNULL]
参照完整性是通过使用如下保留字：FOREIGN KEY 定义那些列为外码； REFERENCES 指明外键对应于哪个表的主键；ON DELETE CASCADE 指明删除被参照关系的元组时，同时删除参照关系中的元组；SETNULL表示置为空值方式。本试题中，部门关系的主键为部门号，职工关系的主键为职工号。其中，部门关系的主键为部门号可采用如下两种方式定义：
部门号CHAR(1)PRIMARY KEY或者是PRIMARY KEY(部门号)
又因为负责人也是一个职工，所以负责人代码应该是一个外码，应进行参照完整性定义。根据分析部门的SQL定义如下：
Create Table 部门(部门号 CHAR(1) PRIMARY KEY ，
部门名 CHAR(16)，
负责人代码 CHAR(4)，
任职时间 DATE，
FOREIGN KEY (负责人代码) REFERENCES 职工 (职工号))；
在职工关系中，部门号是一个外码，应进行参照完整性定义。又因为在试题表2-1中的条件“500元≤月工资≤5000元”，所以在职工关系中应加上用户定义完整性。根据
分析职工的SQL定义如下：
Create Table 职工 (职工号CHAR(4)，
姓名 CHAR(8)，
年龄 NUMBER(3)，
月工资NUMBER(4)，
部门号CHAR(1)，
电话 CHAR(8)，
办公室CHAR(8)，
PRIMARY DEY (职工号)，
FOREIGNKEY (部门号) REFERENCES 部门 (部门号)，
CHECK(月工资 BETWEEN 500 AND 5000 ))；
建立D_S视图需要COUNT函数来统计各部门的人数C，SUM来计算工资总数 Totals，用AVG来计算平均工资Averages，用分组语句GROUPBY来对不同部门进行分组。因此创建D_S视图的SQL语句是：
Create ViewD_S (D，C，Totals，Averages)AS
(SELECT 部门号，COUNT(*)，SUM (月工资)，AVG(月工资)
FROM 职工
GROUP BY 部门号)
[问题2][分析]
本题主要考查完整性定义的约束性。以下表是待插入的记录组。

(1)由于在职工表的定义中职工号主码是惟一标识每个元组(记录)的，而(1)中的职工号是“1001”，在试题的职工关系中已经存在该职工号的记录，为了保证实体的完整性，该条记录不能插入。
(2)该元组可以插入“职工”关系，尽管部门号、电话和办公室为空，但是它表示该职工暂时没有分配到某个部门。虽然职工表中部门号是外键，但在定义中也没有约束它不能为空。
(3)该元组不能插入“职工'’关系，部门号是外键，而在部门关系中找不到部门号是6的元组，违反了参照完整性，所以不能做插入操作。
[问题3][分析]
此问考查的是视图更新必须遵循的原则。因此，需要将SQL语句与定义该视图的 SQL语句结合起来考虑。由于SQL视图更新必须遵循以下规则：
▲ 从多个基本表通过连接操作导出的视图不允许更新。
▲ 对使用了分组、集函数操作的视图则不允许进行更新操作。
▲ 如果视图是从单个基本表通过投影、选取操作导出的则允许进行更新操作，且语法同基本表。
(1)由于D_S视图中包含分组操作，也即将D_S视图合并到Update D_S set D=3 where D=4，结果为：Update 职工 set 部门号=3 where 部门号=4 GROUP BY 部门号，在 where 中包括 GROUP 分组操作，因此不能执行。
(2)同理，将D_S视图合并到Delete from D_S where C＞4中，结果为：Delete from职工where COUNT(职工号)＞4 GROUP BY部门号，因此不能执行。
(3)对于Select D，Averages from D_S where C＞(Select C from D_S where D=：dept)，要根据视图的返回值的情况。因此不一定能执行。
(4)对于语句Select D，C From D_S where Totals＞10000可以执行。
(5)对于语句Select*from D_S显然是能执行的。
[问题4][分析]
此问考查的是查询效率的问题。在涉及相关查询的某些情形中，构造临时关系可以提高查询效率。
(1)对于外层的职工关系E中的每一个元组，都要对内层的整个职工关系M进行检索，因此查询效率不高。
(2)此问有两种解法。
解答一
改正后的SQL语句使用了临时表：
Select Max (月工资) as 最高工资，部门号 into Temp from 职工
Group by 部门号
Select 职工号 from 职工，Temp
where 月工资=最高工资 and 职工．部门号=Temp．部门号
解答二
Select 职工号 from 职工，(Select Max(月工资) as 最高工资，部门号
Group by部门号)as depMax
where月工资；最高工资and职工．部门号；depMax．部门号
[问题5][分析]
问题5中的Select查询语句中使用了条件 or，系统在查询的时候将对全表进行扫描，不会促使查询优化器使用索引，从而降低了查询效率。改正的方法是去掉or，修改后的 SQL语句如下：
Select 姓名，年龄，月工资 from 职工
where 年龄＞45；
union
Select姓名，年龄，月上资 from 职工
where 年龄 月工资＜1000；
参考答案
[问题1]解答
(a)PRIMARY KEY
(b)FOREIGN KEY (负责人代码) REFERENCES职工
(c)FOREIGN KEY (部门号) REFERENCES部门
(d)月工资＞=500 AND＜月工资=5000，或月工资 BETWEEN 500 AND 5000
(e)count(*)，Sum (月工资)，Avg (月工资)
(f)GrOup by部门号
[问题2]解答
(1)该行不能插入“职工”关系，它违反了实体完整性中主码必须惟一区分关系中的每一个属性。
(2)该行可以插入“职工”关系，尽管部门号、电话和办公室为空，但是它表示该雇员没有分配到某个部门。
(3)该行不能插入“职32'’关系，它违反了参照完整性。因为6在关系“部门”中不存在。
[问题3]解答
此问考查的是对视图定义的掌握。
(1)和(2)都不能更新，因为使用分组合聚集函数定义的视图是不可更新的。(3)不一定，视子查询的返回值而定，(4)和(5)允许查询。
[问题4]解答
此问考查的是查询效率的问题。在涉及相关查询的某些情形中，构造临时关系可以提高查询效率。
(1)对于外层的职工关系E中的每一个元组，都要对内层的整个职工关系M进行检索，因此查询效率不高。
(2)解答一
改正后的SQL语句使用了临时表：
Select Max(月工资) as 最高工资，部门号 into Temp from 职工
Group by部门号
Select 职工号 from 职工，Temp
where 月工资=最高工资 and 职工，部门号=Temp．部门号
解答二
Select 职工号 from 职工，(Select Max (月工资) as 最高工资，部门号
Group by 部门号)as depMax
where 月工资=最高工资 and 职工．部门号=depMax．部门号
[问题5]解答
此问主要考查在查询中注意where子句中使用索引的问题。
Select 姓名，年龄，月工资 from 职工
where 年龄＞45；
union
Select 姓名，年龄，月工资 from 职工
where 年龄 月工资＜1000；
试题3
阅读下列说明，回答问题1至问题5。
说明
某仓储超市采用POS(Point of Sale)收银机负责前台的销售收款，为及时掌握销售信息，并依此指导进货，拟建立商品进、销、存数据库管理系统。该系统的需求分析已经基本完成，下面将进入概念模型的设计。
需求分析结果
1．销售业务由POS收银机来辅助实现。POS机外接条码阅读器，结账时收银员将商品的条码通过阅读器输入POS机中。所售商品数量默认值为1，可以由收银员修改。 POS机根据输入的商品信息，打印出如图3-1所示的购物清单。

2．将经销的商品分为直销商品和库存商品两大类。直销商品的保质期较短，如食品类，由供应商直接送达超市，管理员将过期的商品返还给供应商处理；库存商品由采购员向供应商提交订购单，供应商根据订购单送货。超市会不定期对库存商品按照折扣率进行打折优惠。
直销商品和库存商品的送货单样表分别如图3-2、图3-3所示，其中直销商品生产批号的前6位表示生产日期。
3．超市的硬件拓扑结构如图3-4所示。
4．业务处理过程：由POS机存储每一笔销售记录，在每个工作日结束前汇总当日各商品的销售量至中心数据库(销售日汇总)；根据当日的销售日汇总更新存货表；每笔进货记入进货表中，并及时更新存货表。

图3-2 直销商品送货单样表

图3-3 库存商品送货单样表

概念模型设计
根据需求阶段收集的信息，设计的实体联系图和关系模式(不完整)如下：
1．实体联系图

2．关系模式
销售详单 (销售流水号，商品编码，数量，金额，收银员，时间)
销售日汇总 (日期，商品编码，数量)
存货表 (商品编码，数量)
进货表 (送货号码，商品编码，数量，日期)
商品 ( (b) )
[问题1]对直销商品和库存商品进行概括，给出超类和子类，填入图3-5中(a)处所示的虚线框内，并补充联系。
[问题2]根据你的实体联系图，完成(b)处的商品关系模式，并增加子类型的实体关系模式。
[问题3]对所有关系模式，以下划线指出各关系模式的主键。
[问题4]如果将商品信息只存储在中心数据库中，与在各POS机上存储其备份相比，从前台销售效率和更新商品库两方面论述各自的优缺点(不超过300字)。
[问题5]如果考虑引入积分卡，根据累积消费金额计算积分点，再根据积分点在顾客购物时进行现金返还，并修改顾客的累积消费金额和积分点。请给出新增加的积分卡关系模式，并对销售详单关系模式进行修正，指出修正后关系模式和新增关系模式的候选键和外键。
试题3[分析]
本题考查的是关于数据库设计中的概念结构设计与逻辑结构设计方面的知识。
在概念设计阶段中，数据抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性。有三种抽象：分类、聚集和概括。其中概括是定义类型之间的一种子集联系，其重要性质是继承性。也就是说子类继承了超类上定义的所有抽象。
概念设计是独立于任何一种数据模型的信息结构。而逻辑结构设计的任务是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。
E-R图向关系模型的转换要解决的问题是如何将实体和实体的联系转换为关系模式，如何确定这些关系模式的属性和码。一般这种转换的原则是：
一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。
E-R图中的联系有三种：一对一联系(1:1)、一对多联系(1:n)和多对多联系 (m:n)，针对这三种不同的联系，有不同的转换方法：
▲ 1:1联系的转换：一对多联系有两种方式向关系模式进行转换。一种方式是将联系转换成一个独立的关系模式，关系模式的名称取联系的名称，关系模式的属性包括该联系所关联的两个实体的码及联系的属性，关系的码取自任一方实体的码：另一种方式是将联系归并到关联的两个实体的任一方，给待归并的一方实体属性集中增加另一方实体的码和该联系的属性即可，归并后的实体码保持不变。
▲ 1:n联系的转换：一对多联系有两种方式向关系模式进行转换。一种方式是将联系转换成一个独立的关系模式，关系模式的名称取联系的名称，关系模式的属性取该联系所关联的两个实体的码及联系的属性，关系的码是多方实体的码；另一种方式是将联系归并到关联的两个实体的多方，给待归并的多方实体属性集中增加一方实体的码和该联系的属性即可，归并后的多方实体码保持不变。
▲ m:n联系的转换：多对多联系只能转换成一个独立的关系模式，关系模式的名称取联系的名称，关系模式的属性取该联系所关联的两个多方实体的码及联系的属性，关系的码是多方实体的码构成的属性组。
[问题1][分析]
问题1考查应试者对概念模型的掌握。建立概念模型就是以图示化的方法(通常采用E-R图)，本题已给出部分实体联系图，要求应试者对题目论述和给定的实体联系力的分析，要补充的内容是虚线框内的实体和缺少的联系的描述。根据题干的描述，图中缺少商品实体，且应划分为直销商品和库存商品两个子类。并画出销售日汇总、存货表和进货表与商品实体之间的联系。
通过分析得到的E-R如下：

[问题2][分析]
根据[问题1]中填入的实体，和题干中给定的对直销商品和库存商品的描述(送货表、销售清单和打折处理)，分析各实体应具有的属性。
从试题中可以看出商品包括了商品编码，商品名称及价格属性，所以得出商品关系模式如下：
商品(商品编号，商品名称，供应商，单价)
因为又由于直销商品有保质期长短等问题，所以根据题意有生产批号、消费期限属性，因此直销商品的关系模式如下：
直销商品(商品编号，生产批号，消费期限)
由于库存商品会不定期按照折扣率进行打折优惠，可以看出库存商品还有价格折扣率这个字段，所以库存商品的关系模式如下：
库存商品(商品编号，折扣率)
[问题3][分析]
根据题目给定的关系模式和[问题2]补充的关系模式，根据属性间的函数依赖关系和给定的关系实例(各种样表)，来确定各关系模式的主键。
销售详单的主键为(销售流水号，商品编码)
销售日汇总的主键为(日期，商品编码)
存货表主键为商品编码
进货表主键为(送货号码，商品编码)
商品主键为商品编号
直销商品主键为(商品编号，生产批号)
库存商品主键为商品编号
[问题4][分析]
本题要求结合数据存储与实际应用，在设计中如何考虑可能出现的各种因素，采取合理的处理方式。
可以考虑如下两种情况：
▲ 采用商品信息集中存储在中心数据库中，则在销售前台的每笔计费中，都必须从中心数据库提取商品名称和单价，增加网络的负载，在业务繁忙时直接影响到前台的销售效率；同时，如果发生网络故障，则该POS机不能工作。采用这种方式，对商品库的更新，如引入新的商品和修改商品价格，会及时体现在前台的销售业务中。
▲ 采用商品信息存储在中心数据库中，各POS机存储商品表的备份；POS机直接从本地读取商品信息，减少了网络的负载，可以提高交易的效率；同时即使有短时间的网络故障，也不影响该POS机的正常使用，只有当存在商品信息变更时才需要与中心数据库同步。采用这种方式，必须在每次商品信息变更时同步各POS机的数据。
[问题5][分析]
本题是对现有关系模式的改进和面向新应用的扩充。
对销售详单做如下的修改，增加积分卡号属性。销售详单 (销售流水号，商品编码，数量，金额，收银员，时间，)另外，需要增加积分卡关系：积分卡(，累积消费金额，积分点)。
试题3解答
[问题1]解答

[问题2]解答
商品(商品编号，商品名称，供应商，单价)
直销商品(商品编号，生产批号，消费期限)
库存商品(商品编号，折扣率)
[问题3]解答
销售详单(销售流水号，商品编码，数量，金额，收银员，时间)
销售日汇总 (日期，商品编码，数量)
存货表 (商品编码，数量)
进货表 (送货号码，商品编码，数量，日期)
商品 (商品编号，商品名称，供应商，单价)
直销商品 (商品编号，生产批号，消费期限)
库存商品 (直显组号，折扣率)
[问题4]解答
1．采用商品信息集中存储在中心数据库中，则在销售前台的每笔计费中，都必须从中心数据库提取商品名称和单价，增加网络的负载，在业务繁忙时直接影响到前台的销售效率；同时，如果发生网络故障，则该POS机不能工作。
采用这种方式，对商品库的更新，如引入新的商品和修改商品价格，会及时体现在前台的销售业务中。
2．采用商品信息存储在中心数据库中，各POS机存储商品表的备份，POS机直接从本地读取商品信息，减少了网络的负载，可以提高交易的效率；同时即使有短时间的网络故障，也不影响该POS机的正常使用，只有当存在商品信息变更时才需要与中心数据库同步。
采用这种方式，必须在每次商品信息变更时同步各POS机的数据。
[问题5]解答
1．对销售详单关系模式做如下的修改，增加积分卡号属性。
销售详单(销售流水号，商品编码，数量，金额，收银员，时间，)
2．加积分卡关系模式：
积分卡(积分卡号，累积消费金额，积分点)
关系模式中画实下划线表示主键，虚下划线表示外键。
试题4
阅读下列说明，回答问题1至问题3。
说明
M公司为某旅游公司设计机票销售专用数据库，其关系模式如图4-1所示。

关系模式的主要属性、含义及约束如表4—1所示，属性间的函数依赖关系如图4-2所示，属性间函数依赖的标记方法如图4-3所示。
属性
含义和约束条件
旅程编号
惟一标识每个能按期出发的旅行团队的编号。相同旅程编号的旅客，，在同一日程中搭乘相同航班。
旅客编号
惟一标识一个旅行团队中的每一位旅客的编号。
团队编号
惟一标识每个旅行团队的编号，如“2004-8-4云南双飞”。
身份证号
惟一识别身份的编号。

旅客旅行前需要向旅行社提出申请，说明要参加的旅行团队。旅行社建立的旅行申请包括，旅行出发日期和到达日期的机票预订、购票等信息。旅行社还需要为每个团队制定“旅程”和“搭乘航班”表。有关“旅程”和“搭乘航班”的示例如表4-2、表4-3所示。
旅客编号
A01
旅程编号
P1
搭乘日期
出发地
目的地
出发时间
到达时间
航班名
2004.5.1
西安
桂林
10:00
13:00
JJ100
2004.5.1
桂林
昆明
17:00
19:00
CC400
2004.5.5
昆明
西安
9:00
12:30
JJ600
表4-3 “搭乘航班”示例
旅程编号
旅客编号
搭乘日期
航班名
P1
A01
2004.5.1
JJ100
P1
A01
2004.5.1
CC400
P1
A01
2004.5.5
JJ600
P1
B02
2004.5.1
JJ100
P1
B02
2004.5.1
CC400
P1
B02
2004.5.5
JJ600
P2
C03
2004.5.1
JJ200
P2
C03
2004.5.5
JJ700
[问题1]对关系“航班”，请回答以下问题：
(1)列举出所有不属于任何候选键的属性(非键属性)。
(2)关系“航班”可达到第几范式，用不超过60个字的内容叙述理由。
[问题2]对关系“旅客”，请回答以下的问题：
(1)针对“旅客”关系，用100字以内文字简要说明会产生什么问题，并加以修正。
(2)列出修正后的关系模式的所有候选键。
(3)把“旅客”分解为第三范式，并用图4-1所示的关系模式的形式表示，分解后的关系名依次取旅客1、旅客2、…。
[问题3]对关系“搭乘航班”，请回答以下的问题：
(1)把非平凡的多值依赖属性(图4-2中没有表示)的例子用满足图4-3的方式表示出来。
(2)关系“搭乘航班”是boyce codd范式而不是第四范式，请用200字以内文字阐述理由。
(3)把“搭乘航班”关系分解成第四范式，并采用图4-1所示的关系模式的形式表示，分解后的关系名依次取搭乘航班1、搭乘航班2、…。
试题4[分析]
试题四是关于数据库设计理论方面的题目。关系数据库设计理论的核心是数据间的函数依赖，衡量的标准是关系规范化的程度及分解的无须连接和保持函数依赖性，关系数据库设计的目标是生成一组合适的、性能良好的关系模式，以减少系统中信息存储的冗余度，但又可方便地获取信息。数据库设计理论包括函数依赖，范式和关系模式规范化三个方面的内容。其中函数依赖是该理论的核心。
[问题1][分析]
为了做好这种类型的试题，需要正确地理解如下基本概念。
函数依赖：设R(U)是属性集U上的关系模式，X、Y是U的子集。若对R(U)的任何一个可能的关系r，r中不可能存在两个元组在x上的属性值相等，而在Y上的属性值不等，则称X函数决定Y或Y函数依赖于X，记作：X→Y。
非平凡的函数依赖：如果X→Y，但YX，则称X→Y是非平凡的函数依赖。一般情况下总是讨论非平凡的函数依赖。
平凡的函数依赖：如果X→Y，但YX，则称X→Y是平凡的函数依赖。
完全函数依赖：在R(U)中，如果X→Y，并且对于X的任何一个真子集X'，都有 X'不能决定Y，则称Y对X完全函数依赖，记作：XY。
部分函数依赖：如果X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记作：XY。部分函数依赖也称局部函数依赖。
传递依赖：在R(U，F)中，如果X→Y，YX，YX，Y→Z，则称Z对X传递依赖。
候选码：设K为R(U，F)中的属性的组合，若KU，且对于K的任何一个真子集K'，都有K不能决定U，则K为R的候选码(候选关键字)，若有多个候选码，则选一个作为主码(主键)。
主属性和非主属性：包含在任何一个候选码中的属性叫做主属性，否则叫做非主属性。
1NF：若关系模式R的每一个分量是不可再分的数据项，则关系模式R∈第一范式 (1NF)。
2NF：若关系模式R∈1NF，且每一个非主属性完全依赖于码，则关系模式R∈2NF。换句话说，当1NF消除了非主属性对码的部分函数依赖，则称为2NF。
3NF：若关系模式R(U，F)中若不存在这样的码X，属性组Y及非主属性Z(ZY)使得X→Y，(YX)Y→Z成立，则关系模式R∈3NF。即当2NF消除了非主属性对码的传递函数依赖，则称为3NF。
BCNF：若关系模式R∈1NF，若X→Y且YX时，X必含有码，则关系模式 R∈BCNF。即当3NF消除了主属性对码的部分和传递函数依赖，则称为BCNF。
4NF：关系模式R∈1NF，若对于R的每个非平凡多值依赖X→→Y且YX时，X必含有码，则关系模式R(U，F)∈4NF。
在问题1中，(1)对关系“航班”的候选键为(航班名：飞行日期)，所以非键属
性为：航空公司名称，出发地点，出发时间，目的地，到达时间。
(2)关系“航班”是属于1NF的。因为非主属性航空公司名称，出发地点，目的地不完全函数依赖于候选键(航班名，飞行日期)。该关系模式存在如下函数依赖：航班名→航空公司名称，出发地点， 目的地；(航班名，飞行日期) →出发时间，到达时间。
[问题2][分析]
问题2可以有两种解题思路。
第一种解题方法：
(1)在题中给出的“旅客”关系中，不同的团队会有相同的旅客编号，所以，旅客编号不能作为候选键，如果同一旅客不同时间参加不同的团队将导致“身份证号”无法确定关系中的每一个元组，所以“身份证号”也不能作为候选键。为此，需要增加一个“团队编号”的属性。又由于{(身份证