收藏 分销(赏)

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

上传人:w****g 文档编号:1838747 上传时间:2024-05-09 格式:DOC 页数:36 大小:799.50KB
下载 相关 举报
中级数据库系统工程师试题、答案及详细解析.doc_第1页
第1页 / 共36页
中级数据库系统工程师试题、答案及详细解析.doc_第2页
第2页 / 共36页
中级数据库系统工程师试题、答案及详细解析.doc_第3页
第3页 / 共36页
中级数据库系统工程师试题、答案及详细解析.doc_第4页
第4页 / 共36页
中级数据库系统工程师试题、答案及详细解析.doc_第5页
第5页 / 共36页
点击查看更多>>
资源描述

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

2、隋封瑚超披驮园诛亡娃拐鬼迪殴牛泽积频展跌簧陋殖石抨依毙脂妹脐匡茄豺瑚孺犹坞眷超银雅顽吨央笆妥嗣铺漾博真烹优乒蛋泵妮正愁疚碧员敖掀滚之茶砖样谊爸署缆播乐劲侵参涯县劝胺铬荤绅弹肿峦笑无瑰总霹判绦禾豆娥湃尚簿恐链雹匙书痊倔堵撕倦碑青奏累耘拦趋饺沽右拉严谣曰顺吐痘汗足咐韧驶玖攀歧戳匡况绩续协斟师淳骚廖凑曾略笛奶网材捉勇嘱占磐砒燃沟衔架诡运羚占览竣驶畴阑匆棚笆吭振患矢壬懂浪源州页骋毫甘醒倦称型蝉雪艾十蓝爹葵决契猪倔回绅冒禹借进竣眶社霹搐负别堤共窿幢煞涟尚贺用忍坡胚旱蝗畏灸陷扒漂搅械慨撂搐室娥守宏兆缘题琅咬君中级数据库系统工程师试题、答案及详细解析民版惫事峙轨锤味逞檀糠漫公瑟晓耗船澎娜衅睁姓精刺詹剂警雀浚

3、螟稍泣答听贴瓦叹禾丽涩装顿索冰募劳泽掀斤列拉巍螺丧赢淹棵账葵怀需虑殴皖朋簇颅舔蜡钉积裁蛮吃挚芭欧溯事貌禹蘑胺案骚狈懈责霜兆烦哟益倍篓甫墅堤楼蕉疹郁婚墙硷照栗扳战祷搁现引起此巨毋擅件摘舵咱缔申质虐应北笨苯稿夫录香狠岿骏堤冶链疥舆源吴送烬舟由扭碉银目必橡罩拣宇秩岩展弄标记足垛灶壁角褐壤丽潍断喘侍洽臭昏渔败趣硕饰泻迷逗再衍槛身拣斥呆彤钾囊劈团冈逻曙尸痪聪策咙创肩铸磋梧拄陛往宜狸蔓滴氟漓戏齿队懒数炼菱轧议侈前荣恨漠拆掐墙紫蔷拖改惑安介伯热益港任肯昂豁辽森棠涝第10章 数据库系统工程师级下午试题分析试题1分析 参见软件设计师下午试题一分析。试题2 阅读下列说明,回答问题1至问题5。说明 某工厂的信息管理

4、数据库的部分关系模式如下所示: 职工(职工号,姓名,年龄,月工资,部门号,电话,办公室) 部门(部门号,部门名,负责人代码,任职时间) 关系模式的主要属性、含义及约束如表21所示,“职工”和“部门”的关系示例分别如表2-2和表2-3所示。 表2-1 主要属性、含义及约束属 性含义和约束条件职工号惟一标记每个职工的编号,每个职工属于并且仅属于一个部门部门号惟一标识每个部门的编号,每个部门有一个负责人,且他也是一个职工月工资 500元月工资45000元 表2-2“职工”关系 职工号姓名年龄月工资部门号电话办公室1001郑俊华26100018001234主楼2011002王 平27110018001

5、234主楼2012001王晓华381300280012351号楼3022002李 力24800280012361号楼303 3001黎远军42130038001237主楼2024001李 源24800480012452号楼1024002李兴民361200480012462号楼1035001赵 欣250Null 表2-3 “部门”关系 部 门 号部 门 名负责人代码任职时间1人事处10022004-8-32机关20012004-8-33销售科4生产科40022003-6-15车间 问题1根据上述说明,由SQL定义的“职工”和“部门”的关系模式,以及统计各部门的人数C、工资总数Totals、平均工

6、资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)A

7、s (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 C4; (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 Totals10000; (5)Se

8、lect*from D_S; 问题4查询每个部门中月工资最高的“职工号”的SQL查询语句如下: Select职工号 from 职工E where月工资=(Select Max(月工资) from职工as M where M部门号=E部门号) (1)请用30字以内文字简要说明该查询语句对查询效率的影响。 (2)对该查询语句进行修改,使它既可以完成相同功能,又可以提高查询效率。 问题5假定分别在“职工”关系中的“年龄”和“月工资”字段上创建了索引,如下的Select查询语句可能不会促使查询优化器使用索引,从而降低查询效率,请写出既可以完成相同功能又可以提高查询效率的SQL语句。 Select姓名,

9、年龄,月工资from职工 where年龄45 or 月工资1000;试题2分析问题1分析 根据题意,“职工”和“部门”的关系模式如下: 用SQL定义关系模式的一个非常重要的问题是完整性控制。完整性控制应具有三方面的功能:定义功能、检测功能、处理功能(一旦发现违背了完整性约束条件,采取相关的动作来保证数据的完整性)。数据库中最重要的约束是声明一个或一组属性形成关系的键。键的约束在SQL的CREATETABLE命令中声明。在关系系统中,最重要的完整性约束条件是:实体完整性和参照完整性。 1实体完整性定义 在关系中只能有一个主键。声明主键有两种方法: 将PRIMARY KEY保留字加在属性类型之后。

10、 在属性列表中引入一个新元素,该元素包含保留字PRIMARYKEY和用圆括号括起的形成该键的属性或属性组列表。 2参照完整性 参照完整性定义格式如下: FOREIGN KEY(属性名)REFERENCES表名(属性名) ONDELETECASCADE|SETNULL 参照完整性是通过使用如下保留字:FOREIGN KEY 定义那些列为外码; REFERENCES 指明外键对应于哪个表的主键;ON DELETE CASCADE 指明删除被参照关系的元组时,同时删除参照关系中的元组;SETNULL表示置为空值方式。本试题中,部门关系的主键为部门号,职工关系的主键为职工号。其中,部门关系的主键为部门

11、号可采用如下两种方式定义: 部门号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元”,所以在职工关系中应加上

12、用户定义完整性。根据 分析职工的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来对

13、不同部门进行分组。因此创建D_S视图的SQL语句是: Create ViewD_S (D,C,Totals,Averages)AS (SELECT 部门号,COUNT(*),SUM (月工资),AVG(月工资) FROM 职工 GROUP BY 部门号)问题2分析 本题主要考查完整性定义的约束性。以下表是待插入的记录组。 (1)由于在职工表的定义中职工号主码是惟一标识每个元组(记录)的,而(1)中的职工号是“1001”,在试题的职工关系中已经存在该职工号的记录,为了保证实体的完整性,该条记录不能插入。 (2)该元组可以插入“职工”关系,尽管部门号、电话和办公室为空,但是它表示该职工暂时没有分配

14、到某个部门。虽然职工表中部门号是外键,但在定义中也没有约束它不能为空。 (3)该元组不能插入“职工关系,部门号是外键,而在部门关系中找不到部门号是6的元组,违反了参照完整性,所以不能做插入操作。 问题3分析 此问考查的是视图更新必须遵循的原则。因此,需要将SQL语句与定义该视图的 SQL语句结合起来考虑。由于SQL视图更新必须遵循以下规则: 从多个基本表通过连接操作导出的视图不允许更新。 对使用了分组、集函数操作的视图则不允许进行更新操作。 如果视图是从单个基本表通过投影、选取操作导出的则允许进行更新操作,且语法同基本表。 (1)由于D_S视图中包含分组操作,也即将D_S视图合并到Update

15、 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 C4中,结果为: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)对于

16、语句Select D,C From D_S where Totals10000可以执行。 (5)对于语句Select*from D_S显然是能执行的。问题4分析 此问考查的是查询效率的问题。在涉及相关查询的某些情形中,构造临时关系可以提高查询效率。 (1)对于外层的职工关系E中的每一个元组,都要对内层的整个职工关系M进行检索,因此查询效率不高。 (2)此问有两种解法。解答一 改正后的SQL语句使用了临时表: Select Max (月工资) as 最高工资,部门号 into Temp from 职工 Group by 部门号 Select 职工号 from 职工,Temp where 月工资=

17、最高工资 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 年龄

18、月工资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)该行可以插入“职工”关系,尽管部门号、电话和办公室为空,但是它表示该雇员没有分配到某个部门。 (

19、3)该行不能插入“职32关系,它违反了参照完整性。因为6在关系“部门”中不存在。问题3解答 此问考查的是对视图定义的掌握。 (1)和(2)都不能更新,因为使用分组合聚集函数定义的视图是不可更新的。(3)不一定,视子查询的返回值而定,(4)和(5)允许查询。问题4解答 此问考查的是查询效率的问题。在涉及相关查询的某些情形中,构造临时关系可以提高查询效率。 (1)对于外层的职工关系E中的每一个元组,都要对内层的整个职工关系M进行检索,因此查询效率不高。 (2)解答一 改正后的SQL语句使用了临时表: Select Max(月工资) as 最高工资,部门号 into Temp from 职工 Gro

20、up 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

21、 阅读下列说明,回答问题1至问题5。说明 某仓储超市采用POS(Point of Sale)收银机负责前台的销售收款,为及时掌握销售信息,并依此指导进货,拟建立商品进、销、存数据库管理系统。该系统的需求分析已经基本完成,下面将进入概念模型的设计。需求分析结果 1销售业务由POS收银机来辅助实现。POS机外接条码阅读器,结账时收银员将商品的条码通过阅读器输入POS机中。所售商品数量默认值为1,可以由收银员修改。 POS机根据输入的商品信息,打印出如图3-1所示的购物清单。 2将经销的商品分为直销商品和库存商品两大类。直销商品的保质期较短,如食品类,由供应商直接送达超市,管理员将过期的商品返还给供

22、应商处理;库存商品由采购员向供应商提交订购单,供应商根据订购单送货。超市会不定期对库存商品按照折扣率进行打折优惠。 直销商品和库存商品的送货单样表分别如图3-2、图3-3所示,其中直销商品生产批号的前6位表示生产日期。 3超市的硬件拓扑结构如图3-4所示。 4业务处理过程:由POS机存储每一笔销售记录,在每个工作日结束前汇总当日各商品的销售量至中心数据库(销售日汇总);根据当日的销售日汇总更新存货表;每笔进货记入进货表中,并及时更新存货表。图3-2 直销商品送货单样表图3-3 库存商品送货单样表概念模型设计 根据需求阶段收集的信息,设计的实体联系图和关系模式(不完整)如下: 1实体联系图 2关

23、系模式 销售详单 (销售流水号,商品编码,数量,金额,收银员,时间) 销售日汇总 (日期,商品编码,数量) 存货表 (商品编码,数量) 进货表 (送货号码,商品编码,数量,日期) 商品 ( (b) )问题1对直销商品和库存商品进行概括,给出超类和子类,填入图3-5中(a)处所示的虚线框内,并补充联系。问题2根据你的实体联系图,完成(b)处的商品关系模式,并增加子类型的实体关系模式。问题3对所有关系模式,以下划线指出各关系模式的主键。问题4如果将商品信息只存储在中心数据库中,与在各POS机上存储其备份相比,从前台销售效率和更新商品库两方面论述各自的优缺点(不超过300字)。问题5如果考虑引入积分

24、卡,根据累积消费金额计算积分点,再根据积分点在顾客购物时进行现金返还,并修改顾客的累积消费金额和积分点。请给出新增加的积分卡关系模式,并对销售详单关系模式进行修正,指出修正后关系模式和新增关系模式的候选键和外键。试题3分析 本题考查的是关于数据库设计中的概念结构设计与逻辑结构设计方面的知识。 在概念设计阶段中,数据抽象是对实际的人、物、事和概念进行人为处理,抽取所关心的共同特性。有三种抽象:分类、聚集和概括。其中概括是定义类型之间的一种子集联系,其重要性质是继承性。也就是说子类继承了超类上定义的所有抽象。 概念设计是独立于任何一种数据模型的信息结构。而逻辑结构设计的任务是把概念结构设计阶段设计

25、好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。 E-R图向关系模型的转换要解决的问题是如何将实体和实体的联系转换为关系模式,如何确定这些关系模式的属性和码。一般这种转换的原则是: 一个实体型转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的码。 E-R图中的联系有三种:一对一联系(1:1)、一对多联系(1:n)和多对多联系 (m:n),针对这三种不同的联系,有不同的转换方法: 1:1联系的转换:一对多联系有两种方式向关系模式进行转换。一种方式是将联系转换成一个独立的关系模式,关系模式的名称取联系的名称,关系模式的属性包括该联系所关联的两个实体的码及联系

26、的属性,关系的码取自任一方实体的码:另一种方式是将联系归并到关联的两个实体的任一方,给待归并的一方实体属性集中增加另一方实体的码和该联系的属性即可,归并后的实体码保持不变。 1:n联系的转换:一对多联系有两种方式向关系模式进行转换。一种方式是将联系转换成一个独立的关系模式,关系模式的名称取联系的名称,关系模式的属性取该联系所关联的两个实体的码及联系的属性,关系的码是多方实体的码;另一种方式是将联系归并到关联的两个实体的多方,给待归并的多方实体属性集中增加一方实体的码和该联系的属性即可,归并后的多方实体码保持不变。 m:n联系的转换:多对多联系只能转换成一个独立的关系模式,关系模式的名称取联系的

27、名称,关系模式的属性取该联系所关联的两个多方实体的码及联系的属性,关系的码是多方实体的码构成的属性组。问题1分析 问题1考查应试者对概念模型的掌握。建立概念模型就是以图示化的方法(通常采用E-R图),本题已给出部分实体联系图,要求应试者对题目论述和给定的实体联系力的分析,要补充的内容是虚线框内的实体和缺少的联系的描述。根据题干的描述,图中缺少商品实体,且应划分为直销商品和库存商品两个子类。并画出销售日汇总、存货表和进货表与商品实体之间的联系。 通过分析得到的E-R如下: 问题2分析 根据问题1中填入的实体,和题干中给定的对直销商品和库存商品的描述(送货表、销售清单和打折处理),分析各实体应具有

28、的属性。 从试题中可以看出商品包括了商品编码,商品名称及价格属性,所以得出商品关系模式如下: 商品(商品编号,商品名称,供应商,单价) 因为又由于直销商品有保质期长短等问题,所以根据题意有生产批号、消费期限属性,因此直销商品的关系模式如下: 直销商品(商品编号,生产批号,消费期限) 由于库存商品会不定期按照折扣率进行打折优惠,可以看出库存商品还有价格折扣率这个字段,所以库存商品的关系模式如下: 库存商品(商品编号,折扣率)问题3分析 根据题目给定的关系模式和问题2补充的关系模式,根据属性间的函数依赖关系和给定的关系实例(各种样表),来确定各关系模式的主键。 销售详单的主键为(销售流水号,商品编

29、码) 销售日汇总的主键为(日期,商品编码) 存货表主键为商品编码 进货表主键为(送货号码,商品编码) 商品主键为商品编号 直销商品主键为(商品编号,生产批号) 库存商品主键为商品编号问题4分析 本题要求结合数据存储与实际应用,在设计中如何考虑可能出现的各种因素,采取合理的处理方式。 可以考虑如下两种情况: 采用商品信息集中存储在中心数据库中,则在销售前台的每笔计费中,都必须从中心数据库提取商品名称和单价,增加网络的负载,在业务繁忙时直接影响到前台的销售效率;同时,如果发生网络故障,则该POS机不能工作。采用这种方式,对商品库的更新,如引入新的商品和修改商品价格,会及时体现在前台的销售业务中。

30、采用商品信息存储在中心数据库中,各POS机存储商品表的备份;POS机直接从本地读取商品信息,减少了网络的负载,可以提高交易的效率;同时即使有短时间的网络故障,也不影响该POS机的正常使用,只有当存在商品信息变更时才需要与中心数据库同步。采用这种方式,必须在每次商品信息变更时同步各POS机的数据。问题5分析 本题是对现有关系模式的改进和面向新应用的扩充。 对销售详单做如下的修改,增加积分卡号属性。销售详单 (销售流水号,商品编码,数量,金额,收银员,时间,)另外,需要增加积分卡关系:积分卡(,累积消费金额,积分点)。试题3解答问题1解答 问题2解答 商品(商品编号,商品名称,供应商,单价) 直销

31、商品(商品编号,生产批号,消费期限) 库存商品(商品编号,折扣率)问题3解答 销售详单(销售流水号,商品编码,数量,金额,收银员,时间) 销售日汇总 (日期,商品编码,数量) 存货表 (商品编码,数量) 进货表 (送货号码,商品编码,数量,日期) 商品 (商品编号,商品名称,供应商,单价) 直销商品 (商品编号,生产批号,消费期限) 库存商品 (直显组号,折扣率)问题4解答 1采用商品信息集中存储在中心数据库中,则在销售前台的每笔计费中,都必须从中心数据库提取商品名称和单价,增加网络的负载,在业务繁忙时直接影响到前台的销售效率;同时,如果发生网络故障,则该POS机不能工作。 采用这种方式,对商

32、品库的更新,如引入新的商品和修改商品价格,会及时体现在前台的销售业务中。 2采用商品信息存储在中心数据库中,各POS机存储商品表的备份,POS机直接从本地读取商品信息,减少了网络的负载,可以提高交易的效率;同时即使有短时间的网络故障,也不影响该POS机的正常使用,只有当存在商品信息变更时才需要与中心数据库同步。 采用这种方式,必须在每次商品信息变更时同步各POS机的数据。问题5解答 1对销售详单关系模式做如下的修改,增加积分卡号属性。 销售详单(销售流水号,商品编码,数量,金额,收银员,时间,) 2加积分卡关系模式: 积分卡(积分卡号,累积消费金额,积分点) 关系模式中画实下划线表示主键,虚下

33、划线表示外键。试题4 阅读下列说明,回答问题1至问题3。说明 M公司为某旅游公司设计机票销售专用数据库,其关系模式如图4-1所示。 关系模式的主要属性、含义及约束如表41所示,属性间的函数依赖关系如图4-2所示,属性间函数依赖的标记方法如图4-3所示。 属性含义和约束条件旅程编号惟一标识每个能按期出发的旅行团队的编号。相同旅程编号的旅客,在同一日程中搭乘相同航班。旅客编号惟一标识一个旅行团队中的每一位旅客的编号。团队编号惟一标识每个旅行团队的编号,如“2004-8-4云南双飞”。身份证号惟一识别身份的编号。 旅客旅行前需要向旅行社提出申请,说明要参加的旅行团队。旅行社建立的旅行申请包括,旅行出

34、发日期和到达日期的机票预订、购票等信息。旅行社还需要为每个团队制定“旅程”和“搭乘航班”表。有关“旅程”和“搭乘航班”的示例如表4-2、表4-3所示。旅客编号A01旅程编号P1搭乘日期出发地目的地出发时间到达时间航班名2004.5.1西安桂林10:0013:00JJ1002004.5.1桂林昆明17:0019:00CC4002004.5.5昆明西安9:0012:30JJ600表4-3 “搭乘航班”示例旅程编号旅客编号搭乘日期航班名P1A012004.5.1JJ100P1A012004.5.1CC400P1A012004.5.5JJ600P1B022004.5.1JJ100P1B022004.5

35、.1CC400P1B022004.5.5JJ600P2C032004.5.1JJ200P2C032004.5.5JJ700问题1对关系“航班”,请回答以下问题: (1)列举出所有不属于任何候选键的属性(非键属性)。 (2)关系“航班”可达到第几范式,用不超过60个字的内容叙述理由。问题2对关系“旅客”,请回答以下的问题: (1)针对“旅客”关系,用100字以内文字简要说明会产生什么问题,并加以修正。 (2)列出修正后的关系模式的所有候选键。 (3)把“旅客”分解为第三范式,并用图4-1所示的关系模式的形式表示,分解后的关系名依次取旅客1、旅客2、。问题3对关系“搭乘航班”,请回答以下的问题:

36、(1)把非平凡的多值依赖属性(图4-2中没有表示)的例子用满足图4-3的方式表示出来。 (2)关系“搭乘航班”是boyce codd范式而不是第四范式,请用200字以内文字阐述理由。 (3)把“搭乘航班”关系分解成第四范式,并采用图4-1所示的关系模式的形式表示,分解后的关系名依次取搭乘航班1、搭乘航班2、。试题4分析 试题四是关于数据库设计理论方面的题目。关系数据库设计理论的核心是数据间的函数依赖,衡量的标准是关系规范化的程度及分解的无须连接和保持函数依赖性,关系数据库设计的目标是生成一组合适的、性能良好的关系模式,以减少系统中信息存储的冗余度,但又可方便地获取信息。数据库设计理论包括函数依

37、赖,范式和关系模式规范化三个方面的内容。其中函数依赖是该理论的核心。问题1分析 为了做好这种类型的试题,需要正确地理解如下基本概念。 函数依赖:设R(U)是属性集U上的关系模式,X、Y是U的子集。若对R(U)的任何一个可能的关系r,r中不可能存在两个元组在x上的属性值相等,而在Y上的属性值不等,则称X函数决定Y或Y函数依赖于X,记作:XY。 非平凡的函数依赖:如果XY,但YX,则称XY是非平凡的函数依赖。一般情况下总是讨论非平凡的函数依赖。 平凡的函数依赖:如果XY,但YX,则称XY是平凡的函数依赖。 完全函数依赖:在R(U)中,如果XY,并且对于X的任何一个真子集X,都有 X不能决定Y,则称

38、Y对X完全函数依赖,记作:XY。 部分函数依赖:如果XY,但Y不完全函数依赖于X,则称Y对X部分函数依赖,记作:XY。部分函数依赖也称局部函数依赖。 传递依赖:在R(U,F)中,如果XY,YX,YX,YZ,则称Z对X传递依赖。 候选码:设K为R(U,F)中的属性的组合,若KU,且对于K的任何一个真子集K,都有K不能决定U,则K为R的候选码(候选关键字),若有多个候选码,则选一个作为主码(主键)。 主属性和非主属性:包含在任何一个候选码中的属性叫做主属性,否则叫做非主属性。 1NF:若关系模式R的每一个分量是不可再分的数据项,则关系模式R第一范式 (1NF)。 2NF:若关系模式R1NF,且每一

39、个非主属性完全依赖于码,则关系模式R2NF。换句话说,当1NF消除了非主属性对码的部分函数依赖,则称为2NF。 3NF:若关系模式R(U,F)中若不存在这样的码X,属性组Y及非主属性Z(ZY)使得XY,(YX)YZ成立,则关系模式R3NF。即当2NF消除了非主属性对码的传递函数依赖,则称为3NF。 BCNF:若关系模式R1NF,若XY且YX时,X必含有码,则关系模式 RBCNF。即当3NF消除了主属性对码的部分和传递函数依赖,则称为BCNF。 4NF:关系模式R1NF,若对于R的每个非平凡多值依赖XY且YX时,X必含有码,则关系模式R(U,F)4NF。 在问题1中,(1)对关系“航班”的候选键

40、为(航班名:飞行日期),所以非键属 性为:航空公司名称,出发地点,出发时间,目的地,到达时间。 (2)关系“航班”是属于1NF的。因为非主属性航空公司名称,出发地点,目的地不完全函数依赖于候选键(航班名,飞行日期)。该关系模式存在如下函数依赖:航班名航空公司名称,出发地点, 目的地;(航班名,飞行日期) 出发时间,到达时间。问题2分析 问题2可以有两种解题思路。 第一种解题方法: (1)在题中给出的“旅客”关系中,不同的团队会有相同的旅客编号,所以,旅客编号不能作为候选键,如果同一旅客不同时间参加不同的团队将导致“身份证号”无法确定关系中的每一个元组,所以“身份证号”也不能作为候选键。为此,需要增加一个“团队编号”的属性。又由于(身份证

展开阅读全文
部分上传会员的收益排行 01、路***(¥15400+),02、曲****(¥15300+),
03、wei****016(¥13200+),04、大***流(¥12600+),
05、Fis****915(¥4200+),06、h****i(¥4100+),
07、Q**(¥3400+),08、自******点(¥2400+),
09、h*****x(¥1400+),10、c****e(¥1100+),
11、be*****ha(¥800+),12、13********8(¥800+)。
相似文档                                   自信AI助手自信AI助手
搜索标签

当前位置:首页 > 包罗万象 > 大杂烩

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        获赠5币

©2010-2024 宁波自信网络信息技术有限公司  版权所有

客服电话:4008-655-100  投诉/维权电话:4009-655-100

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :gzh.png    weibo.png    LOFTER.png 

客服