数据库基础及其应用第四章课后作业
数据库系统基础教程第四章答案
!SolutionsChapter 4c we assume that a phone and address can only belong to a single customer (1-m relationship represented by arrow into customer).;……( # d) }In d we assume that an address can only belong to one customer and a phone can exist at only one address.If the multiplicity of above relationships were m-to-n, the entity set becomes weak and the key ssNo of customers will be needed as part of the composite key of the entity set.In c&d, we convert attributes phones and addresses to entity sets. Since entity sets often become relations in relational design,we must consider more efficient alternatives.Instead of querying multiple tables where key values are duplicated, we can also modify attributes:(i) Phones attribute can be converted into HomePhone, OfficePhone and CellPhone.(ii) A multivalued attribute such as alias can be kept as an attribute where a single column can be used in relational design . concatenate all values. SQL allows a query "like '%Junius%'" to search the multiple values in a column alias.：…《a)—b)c)、The relationship "played" between Teams and Players is similar to relationship "plays" between Teams and Players.、The information about children can be ascertained from motherOf and fatherOf relationships. Attribute ssNo is required since names are not unique.,%~Professor only works in at most one department.…A course has at most one TA.A course is only taught by one professor and offered by one department.Students and professors have been assigned unique email ids.A course is uniquely identified by the course no, section no, and semester . cs157-3 spring 09).$、(`that for each movie, a unique studio exists that produces the movie. Each star is contracted to at most one studio.But stars could be unemployed at a given time. Thus the four-way relationship in fig can be easily into converted equivalent relationships.(The owner address is repeated in AccSets and Addresses entity sets.Simplicity: AccSets does not serve any useful purpose and the design can be more simply represented by creating many-to-many relationship between Customers and Accounts.(Right kind of element: The entity set Addresses has a single attribute address. A customer cannot have more than one address.Hence address should be an attribute of entity set Customers.Faithfulness: Customers cannot be uniquely identified by their names. In real world Customers would have a unique attribute such as ssNo or customerNoand Presidents can be combined into one entity set Studios with Presidents becoming anattribute of Studios under following circumstances:1. The Presidents entity set only contains a simple attribute viz. presidentName. Additional attributes specific to Presidents might justify making Presidents into an entity set.{The entity sets should have single attribute.a) Stars: starNameb) Movies: movieNamec) Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more information about studios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace theStudios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entity set by five attributes viz. studio1, studio2, studio3, studio4, and studio5. Alternately, a composite attribute containing concatenation of all studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searching of such an attribute using query like '%keyword%'|)Augmentation rule of Functional Dependency,given$B -> M (B=Baby, M=Mother)thenBND -> M (N=Nurse, D=Doctor)Hence we can just put an arrow entering mother.a) Put an arrow entering entity set Mothers for the simplest solution (As in fig. , where amulti-way relationship was allowed, even though Movies alone could identify the Studio). However, we can display more accurate information with below figure.》》?b).{ 【~; c)Again from Augmentation rule of Functional Dependency,givenBM -> DthenBMN -> DThus we can just add an arrow entering Doctors to fig . Below figure represents more accurate information however.】Transitivity and Augmentation rules of Functional Dependency allow arrow entering Mothers from Births. However, a new relationship in below figure represents more accurate information.【c)Design flaws in abc above 1. As suggested above, using Transitivity and Augmentation rules of Functional Dependency, much simpler design is possible.[…In below figure there exists a many-to-one relationship between Babies and Births and another many-to-one relationship between Births and Mothers. From transitivity of relationships, thereis a many-to-one relationship between Babies and Mothers. Hence a baby has a unique mother while a birth can allow more than one baby./captain cannot exist without a team. However a player can (free agent). A recently formed (or defunct) team can exist without players or colors.c)Children can exist without mother and father (unknown).'keys of both E1 and E2 are required for uniquely identifying tuples in R (b)The key of E1c)The key of E2d)~The key of either E1 or E2Case: All entity sets have arrows going into them . all relationships are 1-to-1Any KiOtherwise: Combination of all Ki's where there does not exist an arrow going from R to Ei.）grade is not part of the key for enrollments. The keys of Students and Courses become keys of the weak entity set Enrollments.}It is possible to make assignment number a weak key of Enrollments but this is not good design (redundancy since multiple assignments correspond to a course). A new entity set Assignment iscreated and it is also a weak entity set. Hence the key attributes of Assignment will come from the strong entity sets to which Enrollments is connected . studentID, dept, and CourseNo.，,~for toCust and toFlt relationships are not required since the weak entity set Bookings already contains the keys of Customers and Flights.is changed. Since toCust is no longer an identifying relationship, SSNo is no longer a part of Bookings relation.Bookings(flightNo,flightDay,row,seat)ToCust(custSSNO,flightNo,flightDay,row,seat)The above relations are merged intoBookings(flightNo,flightDay,row,seat,custSSNo)<However custSSNo is no longer a key of Bookings relation. It becomes a foreign key instead.Ships(name, yearLaunched)SisterOf(name, sisterName)%…on other relationships not shown in ER diagram, studioName may not be required as a key of Contracts (or not even required as an attribute of Contracts).*(b)Students(studentID)Courses(dept,courseNo)Enrollments(studentID,dept,courseNo,grade)(c)Departments(name)Courses(deptName,number){(d)Leagues(name)Teams(leagueName,teamName)Players(leagueName,teamName,playerName)weak relation Courses has the key from Depts along with number. Hence there is no relation for GivenBy relationship.(a)^Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, allocation)(b) LabCourses has all the attributes of Courses.Depts(name, chair)·Courses(number, deptName, room)LabCourses(number, deptName, room, allocation)(c) Courses and LabCourses are combined into one relation.Depts(name, chair)Courses(number, deptName, room, allocation)?、FatherOf and MotherOf are many-one relationships from Child, there is no need for a separate relation for them. Similarly the one-one relationship Married can be included in Father (or Mother). ChildOf is a many-many relationship and needs a separate relation.!However the ChildOf relation is not required since the relationship can be deduced from FatherOf and MotherOf relationships contained in Child relation.(b)A person cannot be both Mother and Father.Person(name,address)PersonChild(name,address)PersonChildFather(name,address)；PersonChildMother(name,address)PersonFather(name,address)PersonMother(name,address)ChildOf(personName,personAddress,childName,childAddress)FatherOf(childName,childAddress,fatherName,fatherAddress)MotherOf(childName,childAddress,motherName,motherAddress)Married(husbandName,husbandAddress,wifeName,wifeAddress)》The many-many ChildOf relationship again requires a relation.An entity belongs to one and only one class when using object-oriented approach. Hence, the many-one relations MotherOf and FatherOf could be added as attributes toPersonChild,PersonChildFather, and PersonChildMother relations.Similarly the Married relation can be added as attributes to PersonChildMother and PersonMother (or the corresponding father relations).(c) For the Person relation at least one of husband and wife attributes will be null.^Person(personName,personAddress,fatherName,fatherAddress,motherName,motherAddresss,wifeName,wife Addresss,husbandName,husbandAddress)ChildOf(personName,personAddress,childName,childAddress):—cannot belong to both male and female branch of the ER diagram.Moreover since an entity belongs to one and only one class when using object-oriented approach, no entity belongs to People relation.Again we could replace MotherOf and FatherOf relations by adding as attributes toPeopleMale,PeopleMaleFathers,PeopleFemale, and PeopleFemaleMothers relations.(c)People(name,fatherName,motherName)ChildOf(personName,childName))entity set results in one relation. Thus both the minimum and maximum number of relations is e. The root relation has a attributes including k keys. Thus the minimum number of attributes is a. All other relations include the k keys from root along with their a attributes. Thus the maximum number of attributes is a+k.：、—(b)The relation for root will have a attributes. The relation representing the whole tree will have e*a attributes.The number of relations will depend on the shape of the tree. A tree of e entities where only one child exists(say left child only) would have the minimum number of relations. Thus below figure will only contain 4 subtrees that contain root E1,E1E2,E1E2E3, and E1E2E3E4. With eentity sets, minimum e relations are possible.The maximum number of subtrees result when all the entities(except root) are at depth 1. Thus below figure will contain 8 subtrees that contain rootE1,E1E2,E1E3,E1E4,E1E2E3,E1E3E4,E1E2E4,and E1E2E3E4. With e entity sets, maximum 2^(e-1) relations are possible.](c)The nulls method always results in one relation and contains attributes from all e entities . e*a attributes.Summarizing for a,b, and c above;,#Components #RelationsMin Max Min Max Methodstraight-E/R a a e e object-oriented a e*a e 2^(e-1) nulls e*a e*a 1 1?'):{}and Females subclasses arecomplete. Mothers and Fathers are partial. All subclasses are disjoint.、}convert the ternary relationship Contracts into three binary relationships between a new entity set Contracts and existing entity sets.self-association ParentOf for entity set people has multiplicity 0..2 at parent role end.In a Library database, if a patron can loan at most 12 books, them multiplicity is 0..12.For a FullTimeStudents entity set, a relationship of multiplicity 5..* must exist with Courses (A student must take at least。
数据库原理及应用(课后练习)---第4章_关系数据库设计理论
第4章关系数据库设计理论习题一、选择题1、C2、B3、C4、C5、A6、B7、A8、B9、D10、B二、填空题1、数据依赖主要包括_函数_依赖、_多值_依赖和连接依赖。
2、一个不好的关系模式会存在_插入异常_、_删除异常_和__修改复杂_等弊端。
3、设X→Y为R上的一个函数依赖，若_对任意X的真子集X’,均无X’→Y 存在__，则称Y完全函数依赖于X。
4、设关系模式R上有函数依赖X→Y和Y→Z成立，若_Y不包含于X_且_Y→X不成立_，则称Z传递函数依赖于X。
5、设关系模式R的属性集为U，K为U的子集，若_K→U为完全函数依赖_，则称K为R的候选键。
6、包含R中全部属性的候选键称_主属性_。
不在任何候选键中的属性称__非主属性_。
7、Armstrong公理系统是_有效__的和_完备__的。
8、第三范式是基于_函数_依赖的范式，第四范式是基于_多值_依赖的范式。
9、关系数据库中的关系模式至少应属于_第一_范式。
10、规范化过程，是通过投影分解，把_一个范式级别较低的_的关系模式“分解”为_若干个范式级别较高__的关系模式。
三、简答题1、解释下列术语的含义：函数依赖、平凡函数依赖、非平凡函数依赖、部分函数依赖、完全函数依赖、传递函数依赖、范式、无损连接性、依赖保持性。
解：函数依赖：设关系模式R（U，F），U是属性全集，F是U上的函数依赖集，X和Y 是U 的子集，如果对于R（U）的任意一个可能的关系r，对于X的每一个具体值，Y都有唯一的具体的值与之对应，则称X函数决定Y，或Y函数依赖于X，记X→Y。
我们称X为决定因素，Y为依赖因素。
当Y不函数依赖于X时，记作：X Y。
当X→Y且Y→X时，则记作：X Y。
平凡函数依赖：当属性集Y是属性集X的子集时，则必然存在着函数依赖X→Y，这种类型的函数依赖称为平凡的函数依赖。
非平凡函数依赖：如果Y不是X子集，则称X→Y为非平凡的函数依赖。
完全函数依赖与部分函数依赖：设有关系模式R（U），U是属性全集，X和Y是U的子集，X→Y，并且对于X的任何一个真子集X'，都有X'Y，则称Y对X完全函数依赖（Full−f Y。
《数据库基础与应用》 课后习题答案
《数据库基础与应用》课后习题答案第一章数据库系统概论1. 人工管理、文件管理、数据库管理2. 依赖于3. 独立、联系4. 做什么、怎么做5. 文件、数据库6. 安全性、一致性、并发性、数据库恢复7. 兼容性强、可靠性高、地域范围广、数据量大、客户数多8. 主属性、非主属性9. 1对1、1对多、多对多10. 1、多11. 1、多12. 记录型、1对多13. 过程、集合14. 元组、属性15. 1、n16. 数据结构、集合运算、独立、数学17. 封装、继承、多态18. 操作系统、开发工具19. 全局模式、外模式、内模式20. 外模式和模式、模式和内模式21. 定义（描述）操纵22. 系统、用户第二章关系运算1. 关系数据结构、关系完整性规则、关系运算2. 域、列名（属性名）3. 1、多4. 候选、属性5. 学生号、非主6. 实体、参照、用户定义7. 空值、主码8. 并、交、差、笛卡尔积9. a1+b1、a2´b210. 选择、211. 4、312. Õ学生号、X、δ课程名=’程序设计’13. Õ课程号(X)、C第三章关系规范化基础1. X→Y、决定因素2. 非平凡、平凡3. 非平凡、完全4. X、Z5. X→(Y,Z)、合并性6. X、候选码7. (A,C)、28. A、19. (A,C,G)、310. 第三、无损连接、函数依赖11. 属性、元组、关系12. 数据冗余、操作异常（更新异常）13. 第一、314. 第一、215. 第二、216. 第二、17. BC第四章结构化查询语言--SQL一、填空题1. 视图、基本表2. 非过程化、集合3. KUCUN、LIU4. 列级、表级5. 主码、单值、外码、检查6. primary key、foreign key7. 建立、修改、删除8. 单行（单值）、多行（多值）9. 插入、修改、删除10. 表、建立11. 修改、查找12. 基本表、视图13. 没有影响、有影响14. create view、update、drop view15.投影、连接、选择16. group by、order by17. inner join、left join、right join二、根据主教材第四章所给的商品库和教学库，按照下列所给的每条SQL查询语句写出相应的功能。
数据库系统基础教程课后答案第四章
4.2.7 In below figure there exists a many-to-one relationship between Babies and Births and another many-to-one relationship between Births and Mothers. From transitivity of relationships, there is a many-to-one relationship between Babies and Mothers. Hence a baby has a unique mother while a birth can allow more than one baby.
4.1.7
4.1.8 a)
(b)
4.1.9
Assumptions A Professor only works in at most one department. A course has at most one TA. A course is only taught by one professor and offered by one department. Students and professors have been assigned unique email ids. A course is uniquely identified by the course no, section no, and semester (e.g. cs157-3 spring 09).
4.2.4 The entity sets should have single attribute. a) Stars: starName b) Movies: movieName c) Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more information about studios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace the Studios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entity set by five attributes viz. studio1, studio2, studio3, studio4, and studio5. Alternately, a composite attribute containing concatenation of all studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searching of such an attribute using query like '%keyword%'
数据库技术及应用基础教程课后习题参考答案
《数据库技术及应用基础教程》部分课后习题参考答案(本答案仅供参考，如有误请指正)第1章练习题二：1.A 2.B 3.B 4.C第2章练习题一：1.C 2.D 3.C 4.A(题目中“状态”应更正为“网状”) 5.C6.B7.D8.C9.C 10.A11.A 12.C 13.B 14.C 15A16.D(题目中“为加以”应更正为“不加以”)第3章练习题二：1.C 2.D 3.A 4.A 5.A6.A7.A8.A9.B 10.C11.C 12.D13.B 14.A15.A(13题中“OpenFrom”应更正为“OpenForm”)练习题三：1.ACCESS2000数据库提供了选择查询、参数查询、交叉表查询、操作查询和SQL查询等五种查询方式。
2.表、查询、窗体、报表、数据访问页、宏和模块七大对象。
3.设计视图和窗体视图4.（）5.宏是能自动执行某种操作的命令的统称。
其功能是自动执行某种操作，控制程序流程。
6.报表由报表页眉、页面页眉、主题、页面页脚和报表页脚组成。
(p139)7.报表有纵栏式、表格式、图表报表、标签报表、子报表等类型(page133－138)8.ACCESS2000基本宏操作有53种。
实验题二：1.SELECT 书名,数量,位置AS 存放位置FROM 图书表;2.SELECT 单位,姓名, 借书人表.借书证号,借书日期,还书日期FROM 借书人表,借阅表WHERE 借书人表.借书证号=借阅表.借书证号;3.SELECT 出版社名,SUM(数量) AS 总数量FROM 图书表GROUP BY出版社名;4.SELECT 出版社名,书名,SUM(数量) AS 总数量FROM 图书表GROUP BY出版社名,书名;5.UPDA TE 图书表SET 数量=数量+5;第4章练习题三：1.（1）系统规划（2）表的设计和管理（3）根据数据表进行查询的设计和管理（4）窗体的设计和管理（5）报表的设计和管理（6）系统维护与管理。
数据库原理及应用第4章课后习题答案
习题61、说明数据库设计的特点。
1）三分技术，七分管理，十二分基础数据2）综合性3）结构（数据）设计和行为（处理）设计相结合2、试述数据库设计的过程3、试述数据库设计过程的各个阶段设计内容。
1）需求分析阶段需求分析是对用户提出的各种要求加以分析，对各种原始数据加以综合、整理，是形成最终设计目标的首要阶段。
需求分析是整个设计过程的基础，是最困难、最耗费时间的一步。
2）概念结构设计阶段概念结构设计是对用户需求进行进一步抽象、归纳，并形成独立于DBMS和有关软、硬件的概念数据模型的设计过程。
3）逻辑结构设计阶段逻辑结构设计是将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化的设计过程。
4）物理设计阶段数据库物理设计阶段，是将逻辑结构设计阶段所产生的逻辑数据模型，转换为某种计算机系统所支持的数据库物理结构的实现过程。
5）数据库实施阶段数据库实施阶段，即数据库调试、试运行阶段。
一旦数据库的物理结构形成，就可以用已选定的DBMS来定义、描述相应的数据库结构，装入数据库数据库，以生成完整的数据库，编制有关应用程序，进行联机调试并转入试运行，同时进行时间、空间等性能分析。
6）数据库运行和维护阶段数据库实施阶段结束，标志着数据库系统投入正常运行工作的开始。
在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
4、需求分析中发现事实的方法有哪些？1)跟班作业。
通过亲身参加业务工作来观察和了解业务活动的情况。
2)开调查会。
通过与用户座谈来了解业务活动的情况及用户需求。
3)检查文档。
通过检查与当前系统有关的文档、表格、报告和文件等，进一步理解原系统，并有利于提供与原系统问题相关的业务信息。
4)问卷调查。
5、需求分析阶段的设计目标是什么？调查的内容是什么？需求分析阶段的目标是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，确定企业的组织目标，明确用户的各种需求，进而确定新系统的功能，并把这些要求写成用户和数据库设计者都能够接受的文档。
数据库原理与应用教程(第三版)第四章课后习题答案
1. SELECT*FROM Student结果：2. SELECT Sname 姓名,Sage 年龄FROM StudentWHERE Sdept='计算机系'结果：3. SELECT Sno 学号,Cno 课程号,Grade 成绩FROM SCWHERE Grade BETWEEN 70 AND 804. SELECT Sname 姓名,Sage 年龄FROM StudentWHERE Sdept='计算机系'AND Sage>=18 AND Sage<=20 AND Ssex='男'5. SELECT MAX(Grade)最高分数FROM SCWHERE Cno='c01'6. SELECT MAX(Sage)最大年龄,MIN(Sage)最小年龄FROM StudentWHERE Sdept='计算机系'7. SELECT Sdept 系名,COUNT(*)学生人数FROM StudentGROUP BY Sdept8. SELECT Cname 课程名,COUNT(*)选课门数,MAX(Grade)最高分FROM Course,SCGROUP BY Cname9. SELECT Sno 学号,COUNT(*)选课门数,SUM(Grade)总成绩FROM SCGROUP BY SnoORDER BY'选课门数'ASC10. SELECT Sno 学号,SUM(Grade)总成绩FROM SCGROUP BY SnoHAVING SUM(Grade)>20010.CREAT TABLE BOOK（Snobook nchar(6) PRIMARY KEY,Snamebook nvarchar(30) NBOT NULL,Writer char(10) NOT NULL,Time smalldatetime,Price numeric(3,1))CREAT TABLE BOOKSHOP(Snoshop nchar(6) PRIMARY KEY,Snameshop nvarchar(30) NOT NULL,Tel char（8）CHECK(Tel =0 AND Tel <=9),Place nchar(40),Snoemail char(6))CREAT TABLE BOOKSELL（Snobook nchar(6) NOT NULL,Snoshop nchar(6) NOT NULL,Selltime smalltime NOT NULL,Snosell tinyint,PRIMARY KEY (Snobook, Snoshop, Selltime),FOREIGN KEY (Snobook) REFERENCES BOOK(Snobook), FOREIGN KEY (Snoshop) REFERENCES BOOK(BOOKSHOP) )11.ALTER TABLE BOOKADD Nomber intADD CONSTRAINT DF-NomberCHECK (Nomber>1000)12.ALTER TABLE BOOKSHOPDROP COLUMN Tel13.ALTER TABLE BOOKSELLALTER COLUMN Snosell int。
《数据库技术与应用》第4章 习题答案
《数据库技术与应用》第4章习题答案《数据库技术与应用》第4章习题答案第4章关系数据库标准语言sql1.试述关系数据库标准语言sql的特点。
求解：sql语言是一种功能强大、通用性好又简单易学的语言，主要特点包括：综合统一：sql语言将数据定义语言ddl、数据压低语言dml、数据掌控语言dcl的功能集于一体，语言风格统一，可以独立完成数据库生命周期中的全部活动。
高度非过程化：用sql语言展开数据操作方式只要明确提出“搞什么”，而无须阐明“怎么做”。
面向子集操作方式：sql使用子集操作方式方式。
不仅查阅的结果可以就是元组的子集，而且一次插入、更新、删除操作的对象也可以是元组的集合。
积极支持关系数据库的三级模式结构：外模式对应于视图(view)，模式对应于基本表中，内模式对应于存储文件。
简约易学，有效率功能强大：sql语言简约，只有少量关键字，语法直观。
sql的采用方式非常灵活，可以直接通过sql实现人机交互，还可以将sql语句嵌入到其他高级语言程序中来使用。
2.概述sql的基本功能。
解：sql语言就是一种综合的、通用型的、功能强大的关系数据库语言，集数据查阅(dataquery)、数据压低(datamanipulation)、数据定义(datadefinition)和数据掌控(datacontrol)功能于一体。
数据定义功能。
主要用于定义、删除和修改关系数据库中的对象，数据库对象主要包括基本表、视图等。
数据查阅功能。
运用select语句去同时实现查阅数据的功能。
数据压低功能。
主要用作减少、删掉和修正数据库中的数据。
数据掌控功能。
主要用以掌控用户对数据库的操作方式权限，包含数据库安全掌控和事物管理两部分。
3.什么是基本表？什么是视图？两者的区别和联系是什么？解：基本集是本身单一制存有的表中，在sql中一个关系就对应一个表中。
企图从一个或几个基本表中求出的表中。
企图本身不单一制存储在数据库中，就是一个虚表。
数据库应用基础第4章习题参考答案
习题1．选择题（1）设A、B两个数据表的记录数分别为3和4，对两个表执行交叉联接查询，查询结果中最多可获得（C ）条记录。
A．3 B. 4 C. 12 D. 81（2）如果查询的SELECT子句为SELECT A, B, C * D，则不能使用的GROUP B子句是（ A ）。
A．GROUP BY AB．GROUP BY A,BC．GROUP BY A,B,C*DD．GROUP BY A,B,C,D（3）关于查询语句中ORDER BY子句使用正确的是（ C ）。
A．如果未指定排序字段，则默认按递增排序B．数据表的字段都可用于排序C．如果在SELECT子句中使用了DISTINCT关键字，则排序字段必须出现在查询结果中D．联合查询不允许使用ORDER BY子句（4）在查询设计器中，不能与其他窗格保持同步的是（D ）。
A．关系图窗格 B. 网格窗格C．SQL窗格 D. 结果窗格（5）下列函数中，返回值数据类型为int的是（B）。
A．LEFT B. LENC．LTRIM D. SUNSTRING2．填空题(1) 在启动查询分析器时，在登录对话框中可使用（Local）作为本地服务器名称。
(2) 查询分析器窗口主要由对象浏览器和（查询）窗口组成。
(3) 从Windows“开始”菜单启动查询分析器后，默认数据库为（master）。
(4) 以表格方式显示的查询结果保存为（导出）文件，其文件扩展名为（csv）；以文本方式显示的查询结果保存为（报表）文件，其文件扩展名为（rpt）。
(5) 可使用（PRINT）或（SELECT）语句来显示函数结果。
(6) 在查询语句中，应在（SELECT）子句中指定输出字段。
(7) 如果要使用SELECT语句返回指定条数的记录，则应使用（TOP）关键字来限定输出字段。
(8) 联合查询指使用（UNION）运算将多个（查询结果）合并到一起。
(9) 当一个子SELECT的结果作为查询的条件，即在一个SELECT语句的WHERE子句中出现另一个SELECT语句，这种查询称为（嵌套）查询。
林子雨大数据技术原理及应用第四章课后作业答案
大数据技术原理与应用第四章课后作业黎狸1.试述在Hadoop体系架构中HBase与其他组成部分的相互关系。
HBase利用Hadoop MapReduce来处理HBase中的海量数据，实现高性能计算；利用Zookeeper作为协同服务，实现稳定服务和失败恢复；使用HDFS作为高可靠的底层存储，利用廉价集群提供海量数据存储能力; Sqoop为HBase的底层数据导入功能，Pig 和Hive为HBase提供了高层语言支持，HBase是BigTable的开源实现。
2.请阐述HBase和BigTable的底层技术的对应关系。
3.请阐述HBase和传统关系数据库的区别。
4.HBase有哪些类型的访问接口？HBase提供了Native Java API , HBase Shell , Thrift Gateway , REST GateWay , Pig , Hive 等访问接口。
5.请以实例说明HBase数据模型。
6.分别解释HBase中行键、列键和时间戳的概念。
①行键标识行。
行键可以是任意字符串，行键保存为字节数组。
②列族。
HBase的基本的访问控制单元，需在表创建时就定义好。
③时间戳。
每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引。
7.请举个实例来阐述HBase的概念视图和物理视图的不同。
8.试述HBase各功能组件及其作用。
①库函数：链接到每个客户端；②一个Master主服务器：主服务器Master主要负责表和Region的管理工作；③③许多个Region服务器：Region服务器是HBase中最核心的模块，负责存储和维护分配给自己的Region，并响应用户的读写请求9.请阐述HBase的数据分区机制。
每个行区间构成一个分区，被称为“Region”,分发到不同的Region服务器上。
10.HBase中的分区是如何定位的？通过构建的映射表的每个条目包含两项内容，一个是Regionde 标识符，另一个是Region服务器标识，这个条目就标识Region和Region服务器之间的对应关系，从而就可以知道某个Region被保存在哪个Region服务器中。
数据库系统基础教程第四章答案
SolutionsChapter 4 4.1.14.1.2a)b)c)In c we assume that a phone and address can only belong to a single customer (1-m relationship represented by arrow into customer).d)In d we assume that an address can only belong to one customer and a phone can exist at only one address.If the multiplicity of above relationships were m-to-n, the entity set becomes weak and the key ssNo of customers will be needed as part of the composite key of the entity set.In c&d, we convert attributes phones and addresses to entity sets. Since entity sets often become relations in relational design,we must consider more efficient alternatives.Instead of querying multiple tables where key values are duplicated, we can also modify attributes:(i) Phones attribute can be converted into HomePhone, OfficePhone and CellPhone.(ii) A multivalued attribute such as alias can be kept as an attribute where a single column can be used in relational design i.e. concatenate all values. SQL allows a query "like '%Junius%'" to search the multiple values in a column alias.4.1.34.1.4a)c)The relationship "played" between Teams and Players is similar to relationship "plays" between Teams and Players.4.1.54.1.6 The information about children can be ascertained from motherOf and fatherOf relationships. Attribute ssNo is required since names are not unique.4.1.74.1.8a)(b)4.1.9AssumptionsA Professor only works in at most one department.A course has at most one TA.A course is only taught by one professor and offered by one department.Students and professors have been assigned unique email ids.A course is uniquely identified by the course no, section no, and semester (e.g. cs157-3 spring09).4.1.10Given that for each movie, a unique studio exists that produces the movie. Each star is contracted to at most one studio.But stars could be unemployed at a given time. Thus the four-way relationship in fig 4.6 can be easily into converted equivalent relationships.4.2.1Redundancy: The owner address is repeated in AccSets and Addresses entity sets. Simplicity: AccSets does not serve any useful purpose and the design can be more simply represented by creating many-to-many relationship between Customers and Accounts.Right kind of element: The entity set Addresses has a single attribute address. A customer cannot have more than one address.Hence address should be an attribute of entity set Customers.Faithfulness: Customers cannot be uniquely identified by their names. In real world Customers would have a unique attribute such as ssNo or customerNo4.2.2Studios and Presidents can be combined into one entity set Studios with Presidents becoming an attribute of Studios under following circumstances:1. The Presidents entity set only contains a simple attribute viz. presidentName. Additional attributes specific to Presidents might justify making Presidents into an entity set.4.2.34.2.4 The entity sets should have single attribute.a) Stars: starNameb) Movies: movieNamec) Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more information about studios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace theStudios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entity set by five attributes viz. studio1, studio2, studio3, studio4, and studio5. Alternately, a composite attribute containing concatenation of all studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searching of such an attribute using query like '%keyword%'4.2.5From Augmentation rule of Functional Dependency,givenB -> M (B=Baby, M=Mother)thenBND -> M (N=Nurse, D=Doctor)Hence we can just put an arrow entering mother.a) Put an arrow entering entity set Mothers for the simplest solution (As in fig. 4.4, where a multi-way relationship was allowed, even though Movies alone could identify the Studio). However, we can display more accurate information with below figure.c)Again from Augmentation rule of Functional Dependency,givenBM -> DthenBMN -> DThus we can just add an arrow entering Doctors to fig 4.15. Below figure represents more accurate information however.4.2.6a)b) Transitivity and Augmentation rules of Functional Dependency allow arrow entering Mothers from Births. However, a new relationship in below figure represents more accurate information.c)Design flaws in abc above 1. As suggested above, using Transitivity and Augmentation rules of Functional Dependency, much simpler design is possible.4.2.7In below figure there exists a many-to-one relationship between Babies and Births and another many-to-one relationship between Births and Mothers. From transitivity of relationships, thereis a many-to-one relationship between Babies and Mothers. Hence a baby has a unique mother while a birth can allow more than one baby.4.3.1a)b)A captain cannot exist without a team. However a player can (free agent). A recently formed (or defunct) team can exist without players or colors.c)Children can exist without mother and father (unknown).4.3.2a)The keys of both E1 and E2 are required for uniquely identifying tuples in Rb)The key of E1c)The key of E2d)The key of either E1 or E24.3.3Special Case: All entity sets have arrows going into them i.e. all relationships are 1-to-1Any KiOtherwise: Combination of all Ki's where there does not exist an arrow going from R to Ei.4.4.1No, grade is not part of the key for enrollments. The keys of Students and Courses become keys of the weak entity set Enrollments.4.4.2It is possible to make assignment number a weak key of Enrollments but this is not good design (redundancy since multiple assignments correspond to a course). A new entity set Assignment is created and it is also a weak entity set. Hence the key attributes of Assignment will come from the strong entity sets to which Enrollments is connected i.e. studentID, dept, and CourseNo.4.4.3a)b)4.4.4a)b)Customers(SSNo,name,addr,phone)Flights(number,day,aircraft)Bookings(custSSNo,flightNo,flightDay,row,seat)Relations for toCust and toFlt relationships are not required since the weak entity set Bookings already contains the keys of Customers and Flights.4.5.2(a)Schema is changed. Since toCust is no longer an identifying relationship, SSNo is no longer a part of Bookings relation.Bookings(flightNo,flightDay,row,seat)ToCust(custSSNO,flightNo,flightDay,row,seat)The above relations are merged intoBookings(flightNo,flightDay,row,seat,custSSNo)However custSSNo is no longer a key of Bookings relation. It becomes a foreign key instead.4.5.3Ships(name, yearLaunched)SisterOf(name, sisterName)4.5.4(a)Stars(name,addr)Studios(name,addr)Movies(title,year,length,genre)Contracts(starName,movieTitle,movieYear,studioName,salary)Depending on other relationships not shown in ER diagram, studioName may not be required as a key of Contracts (or not even required as an attribute of Contracts).(b)Students(studentID)Courses(dept,courseNo)Enrollments(studentID,dept,courseNo,grade)(c)Departments(name)Courses(deptName,number)Teams(leagueName,teamName)Players(leagueName,teamName,playerName)4.6.1The weak relation Courses has the key from Depts along with number. Hence there is no relation for GivenBy relationship.(a)Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, allocation)(b) LabCourses has all the attributes of Courses.Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, room, allocation)(c) Courses and LabCourses are combined into one relation.Depts(name, chair)Courses(number, deptName, room, allocation)4.6.2(a)Person(name,address)ChildOf(personName,personAddress,childName,childAddress)Child(name,address,fatherName,fatherAddress,motherName,motherAddresss)Father(name,address,wifeName,wifeAddresss)Mother(name,address)Since FatherOf and MotherOf are many-one relationships from Child, there is no need for a separate relation for them. Similarly the one-one relationship Married can be included in Father (or Mother). ChildOf is a many-many relationship and needs a separate relation.However the ChildOf relation is not required since the relationship can be deduced from FatherOf and MotherOf relationships contained in Child relation.(b)A person cannot be both Mother and Father.Person(name,address)PersonChild(name,address)PersonChildFather(name,address)PersonChildMother(name,address)PersonFather(name,address)PersonMother(name,address)ChildOf(personName,personAddress,childName,childAddress)FatherOf(childName,childAddress,fatherName,fatherAddress)MotherOf(childName,childAddress,motherName,motherAddress)Married(husbandName,husbandAddress,wifeName,wifeAddress)The many-many ChildOf relationship again requires a relation.An entity belongs to one and only one class when using object-oriented approach. Hence, the many-one relations MotherOf and FatherOf could be added as attributes toPersonChild,PersonChildFather, and PersonChildMother relations.Similarly the Married relation can be added as attributes to PersonChildMother and PersonMother (or the corresponding father relations).(c) For the Person relation at least one of husband and wife attributes will be null.Person(personName,personAddress,fatherName,fatherAddress,motherName,motherAddresss,wifeName,wife Addresss,husbandName,husbandAddress)ChildOf(personName,personAddress,childName,childAddress)4.6.3(a)People(name,fatherName,motherName)Males(name)Females(name)Fathers(name)Mothers(name)ChildOf(personName,childName)People(name)PeopleMale(name)PeopleMaleFathers(name)PeopleFemale(name)PeopleFemaleMothers(name)ChildOf(personName,childName)FatherOf(childName,fatherName)MotherOf(childName,motherName)People cannot belong to both male and female branch of the ER diagram.Moreover since an entity belongs to one and only one class when using object-oriented approach, no entity belongs to People relation.Again we could replace MotherOf and FatherOf relations by adding as attributes toPeopleMale,PeopleMaleFathers,PeopleFemale, and PeopleFemaleMothers relations.(c)People(name,fatherName,motherName)ChildOf(personName,childName)4.6.4(a)Each entity set results in one relation. Thus both the minimum and maximum number of relationsis e.The root relation has a attributes including k keys. Thus the minimum number of attributes is a. All other relations include the k keys from root along with their a attributes. Thus the maximum number of attributes is a+k.The relation for root will have a attributes. The relation representing the whole tree will have e*a attributes.The number of relations will depend on the shape of the tree. A tree of e entities where onlyone child exists(say left child only) would have the minimum number of relations. Thus below figure will only contain 4 subtrees that contain root E1,E1E2,E1E2E3, and E1E2E3E4. With eentity sets, minimum e relations are possible.The maximum number of subtrees result when all the entities(except root) are at depth 1. Thus below figure will contain 8 subtrees that contain rootE1,E1E2,E1E3,E1E4,E1E2E3,E1E3E4,E1E2E4,and E1E2E3E4. With e entity sets, maximum 2^(e-1)relations are possible.(c)The nulls method always results in one relation and contains attributes from all e entities i.e. e*a attributes.Summarizing for a,b, and c above;#Components #RelationsMin Max Min MaxMethodstraight-E/R a a e eobject-oriented a e*a e 2^(e-1)nulls e*a e*a 1 14.7.14.7.2a)b)c)d)4.7.34.7.44.7.5Males and Females subclasses are complete. Mothers and Fathers are partial. All subclasses are disjoint.4.7.64.7.74.7.8We convert the ternary relationship Contracts into three binary relationships between a new entity set Contracts and existing entity sets.4.7.9a)c)4.7.10A self-association ParentOf for entity set people has multiplicity 0..2 at parent role end.In a Library database, if a patron can loan at most 12 books, them multiplicity is 0..12.For a FullTimeStudents entity set, a relationship of multiplicity 5..* must exist with Courses(A student must take at least5 courses to be classified FullTime.4.8.1Customers(SSNo,name,addr,phone)Flights(number,day,aircraft)Bookings(row,seat,custSSNo,FlightNumber,FlightDay)Customers("SSNo",name,addr,phone)Flights("number","day",aircraft)Bookings(row,seat,"custSSNo","FlightNumber","FlightDay")4.8.2a)Movies(title,year,length,genre)Studios(name,address)Presidents(cert#,name,address)Owns(movieTitle,movieYear,studioName)Runs(studioName,presCert#)Movies("title","year",length,genre)Studios("name",address)Presidents("cert#",name,address)Owns("movieTitle","movieYear",studioName)Runs("studioName",presCert#)b)Since the subclasses are disjoint, Object Oriented Approach is used. The hierarchy is not complete. Hence four relations are required Movies(title,year,length,genre)MurderMysteries(title,year,length,genre,weapon)Cartoons(title,year,length,genre)Cartoon-MurderMysteries(title,year,length,genre,weapon)Movies("title","year",length,genre)MurderMysteries("title","year",length,genre,weapon)Cartoons("title","year",length,genre)Cartoon-MurderMysteries("title","year",length,genre,weapon)c)Customers(ssNo,name,phone,address)Accounts(number,balance,type)Owns(custSSNo,accountNumber)Customers("ssNo",name,phone,address)Accounts("number",balance,type)Owns("custSSNo","accountNumber")d)Teams(name,captainName)Players(name,teamName)Fans(name,favoriteColor)Colors(colorname)For Displays association,TeamColors(teamName,colorname)RootsFor(fanName,teamName)Admires(fanName,playerName)Teams("name",captainName)Players("name",teamName)Fans("name",favoriteColor)Colors("colorname")For Displays association,TeamColors("teamName","colorname")RootsFor("fanName","teamName")Admires("fanName","playerName")e)People(ssNo,name,fatherSSNo,motherSSNo)People("ssNo",name,fatherssNo,motherssNo)f)Students(email,name)Courses(no,section,semester,professorEmail)Departments(name)Professors(email,name,worksDeptName)Takes(letterGrade,studentEmail,courseNo,courseSection,courseSemester)Students("email",name)Courses("no","section","semester",professorEmail)Departments("name")Professors("email",name,worksDeptName)Takes(letterGrade,"studentEmail","courseNo","courseSection","courseSemester")4.8.3a)Each and every object is a member of exactly one subclass at leaf level. We have nine classes at the leaf of hierarchy. Hence we need nine relations.b)All objects only belong to one subclass and its ancestors. Hence, we need not consider every possible subtree but rather the total number of nodes in tree.Hence we need thirteen relations.c)We need all possible subtrees. Hence 218 relations are required.4.9.1class Customer (key (ssNo)){attribute integer ssNo;attribute string name;attribute string addr;attribute string phone;relationship Set<Account> ownsAcctsinverse Account::ownedBy;};class Account (key (number)){attribute integer number;attribute string type;attribute real balance;relationship Set<Customer> ownedByinverse Customer::ownsAccts;};4.9.2a)Modify class Account to contain relationship Customer ownedBy (no Set)b)Also remove set in relationship ownsAccts of class Customer.c)ODL allows a collection of primitive types as well as structures. To class Customer add following attributes in place of simple attributes addr and phone:Set<string phone>Set<Struct addr{string street,string city,string state}>d)ODL allows structures and collections recursively.Set<Struct addr{string street,string city,string state},Set<string phone>>4.9.3Collections are allowed in ODL. Hence, Colors Set can become an attribute of Teams. class Colors(key(colorname)){attribute string colorname;relationship Set<Fans> FavoredByinverse Fans::Favors;relationship set<Teams> DisplayedByinverse Teams::Displays;};class Teams(key(name)){attribute string name;relationship set<Colors> Displaysinverse Colors::DisplayedBy;relationship set<Players> PlayedByinverse Players::Plays;relationship PLayers CaptainedByinverse Platyers::Captains;relationship set<Fans> RootedByinverse Fans::Roots;};class Players(key(name)){attribute string name;relationship Set<Teams> Playsinverse Teams::PlayedBy;relationship Teams Captainsinverse Teams::CaptainedBy;relationship Set<Fans> AdmiredByinverse Fans::Admires;};class Fans(key(name)){attribute string name;relationship Colors Favorsinverse Colors::FavoredBy;relationship Set<Teams> RootedByinverse Teams::Roots;relationship Set<Players> Admiresinverse Players::AdmiredBy;};4.9.4class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};4.9.5The struct education{string degree,string school,string date} cannot have duplication. Hence use of Sets does not make any different as compared to bags, lists, or arrays. Lists will allow faster access/queries due to the already sorted nature.4.9.6a)class Departments(key (name)) {attribute string name;relationship Courses offersinverse Courses::offeredBy;};class Courses(key (number,offeredBy)) {attribute string number;relationship Departments offeredByinverse Departments::offers;};b)class Leagues (key (name)) {attribute name;relationship Teams containsinverse Teams::belongs;};class Teams(key (name,belongs)) {attribute name,relationship Leagues belongsinverse Leagues::contains;relationship Players playinverse Players::plays;};class Players (key(number,plays)) {attribute number,relationship Teams playsinverse Teams::play;};4.9.7class Students (key email) {attribute string email;attribute string name;relationship Courses isTAinverse Courses::TA;relationship Courses Takesinverse Courses::TakenBy;};class Professors (key email) {attribute string email;attribute string name;relationship Departments WorksForinverse Department::Works;relationship Courses Teachesinverse Courses::TaughtBy;};class Courses (key (no,semester,section)) {attribute string no;attribute string semester;attribute string section;relationship Students TAinverse Students::isTA;relationship Students TakenByinverse Students::Takes;relationship Professors TaughtByinverse Professors::Teaches;relationship Departments OfferedByinverse Departments::Offer;};class Departments (key name) {attribute name;relationship Courses Offerinverse Courses::OfferedBy;relationship Professors Worksinverse Professors::WorksFor;};4.9.8A relationship is its own inverse when for every attribute pair in the relationship, the inverse pair also exists. A relation with such a relationship is called symmetric in set theory. e.g. A relationship called SiblingOf in Person relation is its own inverse.4.10.1a)Customers(ssNo,name,addr,phone)Account(number,type,balance)Owns(ssNo,accountNumber)b)Accounts(number,balance,type,owningCustomerssNo)Customers(ssNo,name)Addresses(ownerssNo,street,state,city)Phones(ownerssNo,street,state,city,phonearea,phoneno)We can remove Addresses relation since its attributes are a subset of relation Phones.Fans(name,colors)RootedBy(fan_name,teamname)Admires(fan_name,playername)Players(name,teamname,is_captain)Teams(name)--remove subset of teamcolorTeamcolors(name,colorname)Colors(colorname)d)class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};Person(name,mothername,fathername)The children relationship is many-many but the information can be deduced from Person relation. Hence below relation is redundant.Parent-Child(parent, child)4.10.2First consider each struct as if it were an atomic value i.e. key and value association pairs can be treated as two attributes. After applying normalization,the attributes can be replaced by the fields of the structs.4.10.3(a)Struct Card { string rank, string suit };(b)class Hand {attribute Set theHand;};(c)Hands(handId, rank, suit)Each tuple corresponds to one card of a hand. HandId is required key to identify a hand.(d) Hand contains an array of 5 elementsclass PokerHand{attribute Array Hand(Card card1,Card card2,Card card3,Card card4,Card card5)} PokerHandS(handId,rank1,suit1,,rank2,suit2,rank3,suit3,rank4,suit4,rank5,suit5)(e)class Deal {attribute Set <Struct PlayerHand { string Player, Hand theHand } > theDeal;}(f) PokerDeal consist of a player and array of five card deal.class PokerDeal{string Player,attribute Array Hand(Card card1,Card card2,Card card3,Cardcard4,Card card5)}(g) Above can similarly be represented by key player and a value consisting of five element array.(h)dealID is a key for Deals. Thus the relations for classes Deals and Hands are:Deals(dealID, player, handID)Hands(handID, rank, suit)A simpler relation Deals below can also represents the classes:Deals(dealID, player, rank, suit)(i)The relation Deals(dealID,card) cannot identify the hand to which a card belongs. Also two attributes are required for a card;its rank and suit.Deals(dealID, handID, rank, suit)4.10.4(a)C(a, f, g)(b)C(a, f, g, count)(c)C(a, f, g, position)(d)C(a, f, g, i, j)。
数据库系统基础学习知识教学教育资料第四章规范标准答案
SolutionsChapter 4 4.1.14.1.2a)b)c)In c we assume that a phone and address can only belong to a single customer (1-m relationship represented by arrow into customer).d)In d we assume that an address can only belong to one customer and a phone canexist at only one address.If the multiplicity of above relationships were m-to-n, the entity set becomesweak and the key ssNo of customers will be needed as part of the composite keyof the entity set.In c&d, we convert attributes phones and addresses to entity sets. Since entitysets often become relations in relational design,we must consider more efficient alternatives.Instead of querying multiple tables where key values are duplicated, we can also modify attributes:(i) Phones attribute can be converted into HomePhone, OfficePhone and CellPhone. (ii) A multivalued attribute such as alias can be kept as an attribute where asingle column can be used in relational design i.e. concatenate all values. SQLallows a query "like '%Junius%'" to search the multiple values in a column alias.4.1.34.1.4a)b)c)The relationship "played" between Teams and Players is similar to relationship "plays" between Teams and Players.4.1.54.1.6 The information about children can be ascertained from motherOf and fatherOf relationships. Attribute ssNo is required since names are not unique.4.1.74.1.8a)(b)4.1.9AssumptionsA Professor only works in at most one department.A course has at most one TA.A course is only taught by one professor and offered by one department.Students and professors have been assigned unique email ids.A course is uniquely identified by the course no, section no, and semester (e.g. cs157-3 spring 09).4.1.10Given that for each movie, a unique studio exists that produces the movie. Each star is contracted to at most one studio.But stars could be unemployed at a given time. Thus the four-way relationship in fig 4.6 can be easily into converted equivalent relationships.4.2.1Redundancy: The owner address is repeated in AccSets and Addresses entity sets. Simplicity: AccSets does not serve any useful purpose and the design can be more simply represented by creating many-to-many relationship between Customers and Accounts.Right kind of element: The entity set Addresses has a single attribute address.A customer cannot have more than one address.Hence address should be an attribute of entity set Customers.Faithfulness: Customers cannot be uniquely identified by their names. In real world Customers would have a unique attribute such as ssNo or customerNo4.2.2Studios and Presidents can be combined into one entity set Studios withPresidents becoming an attribute of Studios under following circumstances:1. The Presidents entity set only contains a simple attribute viz. presidentName. Additional attributes specific to Presidents might justify making Presidentsinto an entity set.4.2.34.2.4 The entity sets should have single attribute.a) Stars: starNameb) Movies: movieNamec) Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more information aboutstudios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace theStudios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entity set by five attributes viz.studio1, studio2, studio3, studio4, and studio5. Alternately, a compositeattribute containing concatenation of all studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searchingof such an attribute using query like '%keyword%'4.2.5From Augmentation rule of Functional Dependency,giventhenBND -> M (N=Nurse, D=Doctor)Hence we can just put an arrow entering mother.a) Put an arrow entering entity set Mothers for the simplest solution (As in fig.4.4, where a multi-way relationship was allowed, even though Movies alone could identify the Studio). However, we can display more accurate information with below figure.b)givenBM -> DthenBMN -> DThus we can just add an arrow entering Doctors to fig 4.15. Below figure represents more accurate information however.4.2.6a)b) Transitivity and Augmentation rules of Functional Dependency allow arrow entering Mothers from Births. However, a new relationship in below figure represents more accurate information.c)Design flaws in abc above 1. As suggested above, using Transitivity and Augmentation rules of Functional Dependency, much simpler design is possible.4.2.7In below figure there exists a many-to-one relationship between Babies and Births and another many-to-one relationship between Births and Mothers. From transitivity of relationships, there is a many-to-one relationship between Babies and Mothers. Hence a baby has a unique mother while a birth can allow more than one baby.4.3.1a)b)A captain cannot exist without a team. However a player can (free agent). A recently formed (or defunct) team can exist without players or colors.c)Children can exist without mother and father (unknown).4.3.2a)The keys of both E1 and E2 are required for uniquely identifying tuples in Rb)The key of E1c)The key of E2d)The key of either E1 or E24.3.3Special Case: All entity sets have arrows going into them i.e. all relationships are 1-to-1Any KiOtherwise: Combination of all Ki's where there does not exist an arrow goingfrom R to Ei.4.4.1No, grade is not part of the key for enrollments. The keys of Students and Courses become keys of the weak entity set Enrollments.4.4.2It is possible to make assignment number a weak key of Enrollments but this is not good design (redundancy since multiple assignments correspond to a course).A new entity set Assignment is created and it is also a weak entity set. Hence the key attributes of Assignment will come from the strong entity sets to which Enrollments is connected i.e. studentID, dept, and CourseNo.4.4.3a)b)4.4.4a)4.5.1Customers(SSNo,name,addr,phone)Flights(number,day,aircraft)Bookings(custSSNo,flightNo,flightDay,row,seat)Relations for toCust and toFlt relationships are not required since the weak4.5.2(a)(b)Schema is changed. Since toCust is no longer an identifying relationship, SSNo is no longer a part of Bookings relation.Bookings(flightNo,flightDay,row,seat)ToCust(custSSNO,flightNo,flightDay,row,seat)The above relations are merged intoBookings(flightNo,flightDay,row,seat,custSSNo)However custSSNo is no longer a key of Bookings relation. It becomes a foreign4.5.3Ships(name, yearLaunched)SisterOf(name, sisterName)4.5.4(a)Stars(name,addr)Studios(name,addr)Movies(title,year,length,genre)Contracts(starName,movieTitle,movieYear,studioName,salary)Depending on other relationships not shown in ER diagram, studioName may not be required as a key of Contracts (or not even required as an attribute of Contracts).(b)Students(studentID)Courses(dept,courseNo)Enrollments(studentID,dept,courseNo,grade)(c)Departments(name)Courses(deptName,number)(d)Leagues(name)Teams(leagueName,teamName)Players(leagueName,teamName,playerName)4.6.1The weak relation Courses has the key from Depts along with number. Hence there is no relation for GivenBy relationship.(a)Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, allocation)(b) LabCourses has all the attributes of Courses.Depts(name, chair)Courses(number, deptName, room)(c) Courses and LabCourses are combined into one relation.Depts(name, chair)Courses(number, deptName, room, allocation)4.6.2(a)Person(name,address)ChildOf(personName,personAddress,childName,childAddress)Child(name,address,fatherName,fatherAddress,motherName,motherAddresss)Father(name,address,wifeName,wifeAddresss)Mother(name,address)Since FatherOf and MotherOf are many-one relationships from Child, there is no need for a separate relation for them. Similarly the one-one relationshipMarried can be included in Father (or Mother). ChildOf is a many-manyrelationship and needs a separate relation.However the ChildOf relation is not required since the relationship can be deduced from FatherOf and MotherOf relationships contained in Child relation. (b)A person cannot be both Mother and Father.Person(name,address)PersonChild(name,address)PersonChildFather(name,address)PersonChildMother(name,address)PersonFather(name,address)PersonMother(name,address)ChildOf(personName,personAddress,childName,childAddress)FatherOf(childName,childAddress,fatherName,fatherAddress)MotherOf(childName,childAddress,motherName,motherAddress)Married(husbandName,husbandAddress,wifeName,wifeAddress)The many-many ChildOf relationship again requires a relation.An entity belongs to one and only one class when using object-oriented approach. Hence, the many-one relations MotherOf and FatherOf could be added as attributes to PersonChild,PersonChildFather, and PersonChildMother relations.Similarly the Married relation can be added as attributes to PersonChildMother and PersonMother (or the corresponding father relations).(c) For the Person relation at least one of husband and wife attributes will be null.Person(personName,personAddress,fatherName,fatherAddress,motherName,motherAddres ss,wifeName,wifeAddresss,husbandName,husbandAddress)ChildOf(personName,personAddress,childName,childAddress)4.6.3(a)People(name,fatherName,motherName)Males(name)Females(name)Fathers(name)Mothers(name)ChildOf(personName,childName)(b)People(name)PeopleMale(name)PeopleMaleFathers(name)PeopleFemale(name)PeopleFemaleMothers(name)ChildOf(personName,childName)FatherOf(childName,fatherName)MotherOf(childName,motherName)People cannot belong to both male and female branch of the ER diagram.Moreover since an entity belongs to one and only one class when using object-oriented approach, no entity belongs to People relation.Again we could replace MotherOf and FatherOf relations by adding as attributesto PeopleMale,PeopleMaleFathers,PeopleFemale, and PeopleFemaleMothers relations.(c)People(name,fatherName,motherName)ChildOf(personName,childName)4.6.4(a)Each entity set results in one relation. Thus both the minimum and maximum number of relations is e.The root relation has a attributes including k keys. Thus the minimum number of attributes is a. All other relations include the k keys from root along withtheir a attributes. Thus the maximum number of attributes is a+k.(b)The relation for root will have a attributes. The relation representing the whole tree will have e*a attributes.The number of relations will depend on the shape of the tree. A tree of eentities where only one child exists(say left child only) would have the minimum number of relations. Thus below figure will only contain 4 subtrees that contain root E1,E1E2,E1E2E3, and E1E2E3E4. With e entity sets, minimum e relations are possible.The maximum number of subtrees result when all the entities(except root) are at depth 1. Thus below figure will contain 8 subtrees that contain rootE1,E1E2,E1E3,E1E4,E1E2E3,E1E3E4,E1E2E4,and E1E2E3E4. With e entity sets, maximum 2^(e-1) relations are possible.(c)The nulls method always results in one relation and contains attributes from all e entities i.e. e*a attributes.Summarizing for a,b, and c above;#Components #RelationsMin Max Min MaxMethodstraight-E/R a a e eobject-oriented a e*a e 2^(e-1)nulls e*a e*a 1 14.7.14.7.2a)b)c)d)4.7.34.7.5Males and Females subclasses are complete. Mothers and Fathers are partial. All subclasses are disjoint.4.7.7We convert the ternary relationship Contracts into three binary relationships between a new entity set Contracts and existing entity sets.4.7.9a)b)c)4.7.10A self-association ParentOf for entity set people has multiplicity 0..2 at parent role end.In a Library database, if a patron can loan at most 12 books, them multiplicity is 0..12.For a FullTimeStudents entity set, a relationship of multiplicity 5..* must exist with Courses (A student must take at least5 courses to be classified FullTime.4.8.1Customers(SSNo,name,addr,phone)Flights(number,day,aircraft)Bookings(row,seat,custSSNo,FlightNumber,FlightDay)Customers("SSNo",name,addr,phone)Flights("number","day",aircraft)Bookings(row,seat,"custSSNo","FlightNumber","FlightDay")4.8.2a)Movies(title,year,length,genre)Studios(name,address)Presidents(cert#,name,address)Owns(movieTitle,movieYear,studioName)Runs(studioName,presCert#)Movies("title","year",length,genre)Studios("name",address)Presidents("cert#",name,address)Owns("movieTitle","movieYear",studioName)Runs("studioName",presCert#)b)Since the subclasses are disjoint, Object Oriented Approach is used. The hierarchy is not complete. Hence four relations are required Movies(title,year,length,genre)MurderMysteries(title,year,length,genre,weapon)Cartoons(title,year,length,genre)Cartoon-MurderMysteries(title,year,length,genre,weapon)Movies("title","year",length,genre)MurderMysteries("title","year",length,genre,weapon)Cartoons("title","year",length,genre)Cartoon-MurderMysteries("title","year",length,genre,weapon)c)Customers(ssNo,name,phone,address)Accounts(number,balance,type)Owns(custSSNo,accountNumber)Customers("ssNo",name,phone,address)Accounts("number",balance,type)Owns("custSSNo","accountNumber")d)Teams(name,captainName)Players(name,teamName)Fans(name,favoriteColor)Colors(colorname)For Displays association,TeamColors(teamName,colorname)RootsFor(fanName,teamName)Admires(fanName,playerName)Teams("name",captainName)Players("name",teamName)Fans("name",favoriteColor)Colors("colorname")For Displays association,TeamColors("teamName","colorname")RootsFor("fanName","teamName")Admires("fanName","playerName")e)People(ssNo,name,fatherSSNo,motherSSNo)People("ssNo",name,fatherssNo,motherssNo)f)Students(email,name)Courses(no,section,semester,professorEmail)Departments(name)Professors(email,name,worksDeptName)Takes(letterGrade,studentEmail,courseNo,courseSection,courseSemester)Students("email",name)Courses("no","section","semester",professorEmail)Departments("name")Professors("email",name,worksDeptName)Takes(letterGrade,"studentEmail","courseNo","courseSection","courseSemester")4.8.3a)Each and every object is a member of exactly one subclass at leaf level. We have nine classes at the leaf of hierarchy. Hence we need nine relations.b)All objects only belong to one subclass and its ancestors. Hence, we need not consider every possible subtree but rather the total number of nodes in tree. Hence we need thirteen relations.c)We need all possible subtrees. Hence 218 relations are required.class Customer (key (ssNo)){attribute integer ssNo;attribute string name;attribute string addr;attribute string phone;relationship Set<Account> ownsAcctsinverse Account::ownedBy;};class Account (key (number)){attribute integer number;attribute string type;attribute real balance;relationship Set<Customer> ownedByinverse Customer::ownsAccts;};4.9.2a)Modify class Account to contain relationship Customer ownedBy (no Set)b)Also remove set in relationship ownsAccts of class Customer.c)ODL allows a collection of primitive types as well as structures. To class Customer add following attributes in place of simple attributes addr and phone: Set<string phone>Set<Struct addr{string street,string city,string state}>d)ODL allows structures and collections recursively.Set<Struct addr{string street,string city,string state},Set<string phone>>Collections are allowed in ODL. Hence, Colors Set can become an attribute of Teams.class Colors(key(colorname)){attribute string colorname;relationship Set<Fans> FavoredByinverse Fans::Favors;relationship set<Teams> DisplayedByinverse Teams::Displays;};class Teams(key(name)){attribute string name;relationship set<Colors> Displaysinverse Colors::DisplayedBy;relationship set<Players> PlayedByinverse Players::Plays;relationship PLayers CaptainedByinverse Platyers::Captains;relationship set<Fans> RootedByinverse Fans::Roots;};class Players(key(name)){attribute string name;relationship Set<Teams> Playsinverse Teams::PlayedBy;relationship Teams Captainsinverse Teams::CaptainedBy;relationship Set<Fans> AdmiredByinverse Fans::Admires;};class Fans(key(name)){attribute string name;relationship Colors Favorsinverse Colors::FavoredBy;relationship Set<Teams> RootedByinverse Teams::Roots;relationship Set<Players> Admiresinverse Players::AdmiredBy;};4.9.4class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};4.9.5The struct education{string degree,string school,string date} cannot have duplication.Hence use of Sets does not make any different as compared to bags, lists, or arrays.Lists will allow faster access/queries due to the already sorted nature.4.9.6a)class Departments(key (name)) {attribute string name;relationship Courses offersinverse Courses::offeredBy;};class Courses(key (number,offeredBy)) {attribute string number;relationship Departments offeredByinverse Departments::offers;};b)class Leagues (key (name)) {attribute name;relationship Teams containsinverse Teams::belongs;};class Teams(key (name,belongs)) {attribute name,relationship Leagues belongsinverse Leagues::contains;relationship Players playinverse Players::plays;};class Players (key(number,plays)) {attribute number,relationship Teams playsinverse Teams::play;4.9.7class Students (key email) {attribute string email;attribute string name;relationship Courses isTAinverse Courses::TA;relationship Courses Takesinverse Courses::TakenBy;};class Professors (key email) {attribute string email;attribute string name;relationship Departments WorksForinverse Department::Works;relationship Courses Teachesinverse Courses::TaughtBy;};class Courses (key (no,semester,section)) {attribute string no;attribute string semester;attribute string section;relationship Students TAinverse Students::isTA;relationship Students TakenByinverse Students::Takes;relationship Professors TaughtByinverse Professors::Teaches;relationship Departments OfferedByinverse Departments::Offer;};class Departments (key name) {attribute name;relationship Courses Offerinverse Courses::OfferedBy;relationship Professors Worksinverse Professors::WorksFor;};4.9.8A relationship is its own inverse when for every attribute pair in the relationship, the inverse pair also exists. A relation with such a relationship is called symmetric in set theory. e.g. A relationship called SiblingOf in Person relation is its own inverse.4.10.1a)Customers(ssNo,name,addr,phone)Account(number,type,balance)Owns(ssNo,accountNumber)b)Accounts(number,balance,type,owningCustomerssNo)Customers(ssNo,name)Addresses(ownerssNo,street,state,city)Phones(ownerssNo,street,state,city,phonearea,phoneno)We can remove Addresses relation since its attributes are a subset of relation Phones.c)Fans(name,colors)RootedBy(fan_name,teamname)Admires(fan_name,playername)Players(name,teamname,is_captain)Teams(name)--remove subset of teamcolorTeamcolors(name,colorname)Colors(colorname)d)class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};Person(name,mothername,fathername)The children relationship is many-many but the information can be deduced from Person relation. Hence below relation is redundant.Parent-Child(parent, child)4.10.2First consider each struct as if it were an atomic value i.e. key and value association pairs can be treated as two attributes. After applying normalization, the attributes can be replaced by the fields of the structs.4.10.3(a)Struct Card { string rank, string suit };(b)class Hand {attribute Set theHand;};(c)Hands(handId, rank, suit)Each tuple corresponds to one card of a hand. HandId is required key to identify a hand.class PokerHand{attribute Array Hand(Card card1,Card card2,Card card3,Cardcard4,Card card5)}PokerHandS(handId,rank1,suit1,,rank2,suit2,rank3,suit3,rank4,suit4,rank5,suit5) (e)class Deal {attribute Set <Struct PlayerHand { string Player, Hand theHand } > theDeal;}(f) PokerDeal consist of a player and array of five card deal.class PokerDeal{string Player,attribute Array Hand(Card card1,Card card2,Cardcard3,Card card4,Card card5)}(g) Above can similarly be represented by key player and a value consisting offive element array.(h)dealID is a key for Deals. Thus the relations for classes Deals and Hands are:Deals(dealID, player, handID)Hands(handID, rank, suit)A simpler relation Deals below can also represents the classes:Deals(dealID, player, rank, suit)(i)The relation Deals(dealID,card) cannot identify the hand to which a card belongs. Also two attributes are required for a card;its rank and suit.Deals(dealID, handID, rank, suit)4.10.4(a)C(a, f, g)(b)C(a, f, g, count)(c)C(a, f, g, position)(d)C(a, f, g, i, j)。
数据库系统基础教程第四章答案解析
SolutionsChapter 4a>b>c>In c we assume that a phone and address can only belong to a single customer<1-m relationship represented by arrow into customer>.d>In d we assume that an address can only belong to one customer and a phone canexist at only one address.If the multiplicity of above relationships were m-to-n, the entity set becomesweak and the key ssNo of customers will be needed as partof the composite key ofthe entity set.In c&d, we convert attributes phones and addresses to entity sets. Since entitysets often become relations in relational design,we must consider more efficient alternatives.Instead of querying multiple tables where key values are duplicated, we can also modify attributes:<i> Phones attribute can be converted into HomePhone, OfficePhone and CellPhone. <ii> A multivalued attribute such as alias can be kept as an attribute where asingle column can be used in relational design i.e.concatenate all values. SQLallows a query "like '%Junius%'" to search the multiple values in a column alias.4.1.34.1.4a>b>c>The relationship "played" between Teams and Players is similar to relationship "plays" between Teams and Players.4.1.54.1.6 The information about children can be ascertained from motherOf andfatherOf relationships. Attribute ssNo is required since names are not unique.a><b>AssumptionsA Professor only works in at most one department.A course has at most one TA.A course is only taught by one professor and offered by one department.Students and professors have been assigned unique email ids.A course is uniquely identified by the course no, section no, and semester <e.g.cs157-3 spring 09>.Given that for each movie, a unique studio exists that produces the movie. Eachstar is contracted to at most one studio.But stars could be unemployed at a given time. Thus the four-way relationship infig 4.6 can be easily into converted equivalent relationships.Redundancy: The owner address is repeated in AccSets and Addresses entity sets. Simplicity: AccSets does not serve any useful purpose and the design can be more simply represented by creating many-to-many relationship between Customers and Accounts.Right kind of element: The entity set Addresses has a single attribute address.A customer cannot have more than one address.Hence address should be an attribute of entity set Customers.Faithfulness: Customers cannot be uniquely identified by their names. In realworld Customers would have a unique attribute such asssNo or customerNoStudios and Presidents can be combined into one entity set Studios withPresidents becoming an attribute of Studios under followingcircumstances:1.The Presidents entity set only contains a simple attribute viz. presidentName. Additional attributes specific to Presidents might justify making Presidentsinto an entity set.4.2.34.2.4 The entity sets should have single attribute.a>Stars: starNameb>Movies: movieNamec>Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more informationabout studios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace theStudios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entityset by five attributes viz. studio1, studio2, studio3, studio4, and studio5. Alternately, a composite attribute containing concatenation ofall studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searching of such an attribute using query like '%keyword%'From Augmentation rule of Functional Dependency,givenB -> M <B=Baby, M=Mother>thenBND -> M <N=Nurse, D=Doctor>Hence we can just put an arrow entering mother.a> Put an arrow entering entity set Mothers for the simplest solution <As in fig.4.4, where a multi-way relationship was allowed, even thoughMovies alone could identify the Studio>. However, we can display more accurate information with below figure.b>c>Again from Augmentation rule of Functional Dependency,givenBM -> DthenBMN -> DThus we can just add an arrow entering Doctors to fig 4.15. Below figure represents more accurate information however.a>b> Transitivity and Augmentation rules of Functional Dependency allow arrow entering Mothers from Births. However, a new relationship in below figure represents more accurate information.c>Design flaws in abc above 1. As suggested above, using Transitivity and Augmentation rules of Functional Dependency, much simpler design is possible.4.2.7In below figure there exists a many-to-one relationship between Babies andBirths and another many-to-one relationship between Births andMothers. From transitivity of relationships, there is a many-to-one relationship betweenBabies and Mothers. Hence a baby has a uniquemother while a birth can allow more than one baby.a>b>A captain cannot exist without a team. However a player can<free agent>. Arecently formed<or defunct> team can exist without players or colors.c>Children can exist without mother and father <unknown>.a>The keys of both E1 and E2 are required for uniquely identifying tuples in Rb>The key of E1c>The key of E2d>The key of either E1 or E2Special Case: All entity sets have arrows going into them i.e. all relationships are 1-to-1Any KiOtherwise: Combination of all Ki's where there does not exist an arrow goingfrom R to Ei.No, grade is not part of the key for enrollments. The keys of Students and Courses become keys of the weak entity set Enrollments.4.4.2It is possible to make assignment number a weak key of Enrollments but this is not good design <redundancy since multiple assignments correspond toa course>. A new entity set Assignment is created and it is also a weak entity set. Hence the key attributes of Assignment will come from thestrong entity sets to which Enrollments is connected i.e. studentID,dept, and CourseNo.a>b>c>a>b>Customers<SSNo,name,addr,phone>Flights<number,day,aircraft>Bookings<custSSNo,flightNo,flightDay,row,seat>Relations for toCust and toFlt relationships are not required since the weak entity set Bookings already contains the keys of Customers and Flights.<a><b>Schema is changed. Since toCust is no longer an identifying relationship, SSNois no longer a part of Bookings relation.Bookings<flightNo,flightDay,row,seat>ToCust<custSSNO,flightNo,flightDay,row,seat>The above relations are merged intoBookings<flightNo,flightDay,row,seat,custSSNo>However custSSNo is no longer a key of Bookings relation. It becomes a foreign key instead.Ships<name, yearLaunched>SisterOf<name, sisterName><a>Stars<name,addr>Studios<name,addr>Movies<title,year,length,genre>Contracts<starName,movieTitle,movieYear,studioName,salary>Depending on other relationships not shown in ER diagram, studioName may not be required as a key of Contracts<or not even required as an attribute of Contracts>.<b>Students<studentID>Courses<dept,courseNo>Enrollments<studentID,dept,courseNo,grade><c>Departments<name>Courses<deptName,number><d>Leagues<name>Teams<leagueName,teamName>Players<leagueName,teamName,playerName>The weak relation Courses has the key from Depts along with number. Hence there is no relation for GivenBy relationship.<a>Depts<name, chair>Courses<number, deptName, room>LabCourses<number, deptName, allocation><b> LabCourses has all the attributes of Courses.Depts<name, chair>Courses<number, deptName, room>LabCourses<number, deptName, room, allocation><c> Courses and LabCourses are combined into one relation.Depts<name, chair>Courses<number, deptName, room, allocation><a>Person<name,address>ChildOf<personName,personAddress,childName,childAddress>Child<name,address,fatherName,fatherAddress,motherName,motherAddresss>Father<name,address,wifeName,wifeAddresss>Mother<name,address>Since FatherOf and MotherOf are many-one relationships from Child, there is no need for a separate relation for them. Similarly the one-one relationshipMarried can be included in Father <or Mother>. ChildOf is a many-manyrelationship and needs a separate relation.However the ChildOf relation is not required since the relationship can be deduced from FatherOf and MotherOf relationships contained in Child relation.<b>A person cannot be both Mother and Father.Person<name,address>PersonChild<name,address>PersonChildFather<name,address>PersonChildMother<name,address>PersonFather<name,address>PersonMother<name,address>ChildOf<personName,personAddress,childName,childAddress>FatherOf<childName,childAddress,fatherName,fatherAddress>MotherOf<childName,childAddress,motherName,motherAddress>Married<husbandName,husbandAddress,wifeName,wifeAddress>The many-many ChildOf relationship again requires a relation.An entity belongs to one and only one class when using object-oriented approach. Hence, the many-one relations MotherOf and FatherOf could be added as attributes to PersonChild,PersonChildFather, and PersonChildMother relations.Similarly the Married relation can be added as attributes to PersonChildMother and PersonMother <or the corresponding father relations>.<c> For the Person relation at least one of husband and wife attributes will be null.Person<personName,personAddress,fatherName,fatherAddress,motherName,motherAddres ss,wifeName,wifeAddresss,husbandName,husbandAddress>ChildOf<personName,personAddress,childName,childAddress><a>People<name,fatherName,motherName>Males<name>Females<name>Fathers<name>Mothers<name>ChildOf<personName,childName><b>People<name>PeopleMale<name>PeopleMaleFathers<name>PeopleFemale<name>PeopleFemaleMothers<name>ChildOf<personName,childName>FatherOf<childName,fatherName>MotherOf<childName,motherName>People cannot belong to both male and female branch of the ER diagram.Moreover since an entity belongs to one and only one class when using object-oriented approach, no entity belongs to People relation.Again we could replace MotherOf and FatherOf relations by adding as attributesto PeopleMale,PeopleMaleFathers,PeopleFemale, and PeopleFemaleMothers relations.<c>People<name,fatherName,motherName>ChildOf<personName,childName><a>Each entity set results in one relation. Thus both the minimum and maximum number of relations is e.The root relation has a attributes including k keys. Thus the minimum number of attributes is a. All other relations include the k keys from root along withtheir a attributes. Thus the maximum number of attributes is a+k.<b>The relation for root will have a attributes. The relation representing the whole tree will have e*a attributes.The number of relations will depend on the shape of the tree. A tree of eentities where only one child exists<say left child only> would have the minimum number of relations. Thus below figure will only contain 4 subtrees that contain root E1,E1E2,E1E2E3, and E1E2E3E4. With e entity sets, minimum e relations are possible.The maximum number of subtrees result when all the entities<except root> are at depth 1. Thus below figure will contain 8 subtrees that contain rootE1,E1E2,E1E3,E1E4,E1E2E3,E1E3E4,E1E2E4,and E1E2E3E4. With e entity sets, maximum 2^<e-1> relations are possible.<c>The nulls method always results in one relation and contains attributes fromall e entities i.e. e*a attributes.Summarizing for a,b, and c above;#Components #RelationsMin Max Min MaxMethodstraight-E/R a a e eobject-oriented a e*a e 2^<e-1>nulls e*a e*a 1 1a>b>c>d>Males and Females subclasses are complete.Mothers and Fathers are partial. All subclasses are disjoint.We convert the ternary relationship Contracts into three binary relationships between a new entity set Contracts and existing entity sets.a>b>c>A self-association ParentOf for entity set people has multiplicity 0..2 atparent role end.In a Library database, if a patron can loan at most 12 books, them multiplicity is 0..12.For a FullTimeStudents entity set, a relationship of multiplicity 5..* mustexist with Courses <A student must take at least5 courses to be classified FullTime.Customers<SSNo,name,addr,phone>Flights<number,day,aircraft>Bookings<row,seat,custSSNo,FlightNumber,FlightDay>Customers<"SSNo",name,addr,phone>Flights<"number","day",aircraft>Bookings<row,seat,"custSSNo","FlightNumber","FlightDay">a>Movies<title,year,length,genre>Studios<name,address>Presidents<cert#,name,address>Owns<movieTitle,movieYear,studioName>Runs<studioName,presCert#>Movies<"title","year",length,genre>Studios<"name",address>Presidents<"cert#",name,address>Owns<"movieTitle","movieYear",studioName>Runs<"studioName",presCert#>b>Since the subclasses are disjoint, Object Oriented Approach is used.The hierarchy is not complete. Hence four relations are requiredMovies<title,year,length,genre>MurderMysteries<title,year,length,genre,weapon>Cartoons<title,year,length,genre>Cartoon-MurderMysteries<title,year,length,genre,weapon>Movies<"title","year",length,genre>MurderMysteries<"title","year",length,genre,weapon>Cartoons<"title","year",length,genre>Cartoon-MurderMysteries<"title","year",length,genre,weapon>c>Customers<ssNo,name,phone,address>Accounts<number,balance,type>Owns<custSSNo,accountNumber>Customers<"ssNo",name,phone,address>Accounts<"number",balance,type>Owns<"custSSNo","accountNumber">d>Teams<name,captainName>Players<name,teamName>Fans<name,favoriteColor>Colors<colorname>For Displays association,TeamColors<teamName,colorname>RootsFor<fanName,teamName>Admires<fanName,playerName>Teams<"name",captainName>Players<"name",teamName>Fans<"name",favoriteColor>Colors<"colorname">For Displays association,TeamColors<"teamName","colorname">RootsFor<"fanName","teamName">Admires<"fanName","playerName">e>People<ssNo,name,fatherSSNo,motherSSNo>People<"ssNo",name,fatherssNo,motherssNo>f>Students<email,name>Courses<no,section,semester,professorEmail>Departments<name>Professors<email,name,worksDeptName>Takes<letterGrade,studentEmail,courseNo,courseSection,courseSemester>Students<"email",name>Courses<"no","section","semester",professorEmail>Departments<"name">Professors<"email",name,worksDeptName>Takes<letterGrade,"studentEmail","courseNo","courseSection","courseSemester">a>Each and every object is a member of exactly one subclass at leaf level. We have nine classes at the leaf of hierarchy. Hence we need nine relations.b>All objects only belong to one subclass and its ancestors. Hence, we need not consider every possible subtree but rather the total number of nodes in tree. Hence we need thirteen relations.c>We need all possible subtrees. Hence 218 relations are required.class Customer <key <ssNo>>{attribute integer ssNo;attribute string name;attribute string addr;attribute string phone;relationship Set<Account> ownsAcctsinverse Account::ownedBy;};class Account <key <number>>{attribute integer number;attribute string type;attribute real balance;relationship Set<Customer> ownedByinverse Customer::ownsAccts;};a>Modify class Account to contain relationship Customer ownedBy <no Set>b>Also remove set in relationship ownsAccts of class Customer.c>ODL allows a collection of primitive types as well as structures. To class Customer add following attributes in place of simple attributes addr and phone: Set<string phone>Set<Struct addr{string street,string city,string state}>d>ODL allows structures and collections recursively.Set<Struct addr{string street,string city,string state},Set<string phone>> Collections are allowed in ODL. Hence, Colors Set can become an attribute of Teams.class Colors<key<colorname>>{attribute string colorname;relationship Set<Fans> FavoredByinverse Fans::Favors;relationship set<Teams> DisplayedByinverse Teams::Displays;};class Teams<key<name>>{attribute string name;relationship set<Colors> Displaysinverse Colors::DisplayedBy;relationship set<Players> PlayedByinverse Players::Plays;relationship PLayers CaptainedByinverse Platyers::Captains;relationship set<Fans> RootedByinverse Fans::Roots;};class Players<key<name>>{attribute string name;relationship Set<Teams> Playsinverse Teams::PlayedBy;relationship Teams Captainsinverse Teams::CaptainedBy;relationship Set<Fans> AdmiredByinverse Fans::Admires;};class Fans<key<name>>{attribute string name;relationship Colors Favorsinverse Colors::FavoredBy;relationship Set<Teams> RootedByinverse Teams::Roots;relationship Set<Players> Admiresinverse Players::AdmiredBy;};class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};The struct education{string degree,string school,string date} cannot have duplication.Hence use of Sets does not make any different as compared to bags, lists, or arrays.Lists will allow faster access/queries due to the already sorted nature.a>class Departments<key <name>> {attribute string name;relationship Courses offersinverse Courses::offeredBy;};class Courses<key <number,offeredBy>> {attribute string number;relationship Departments offeredByinverse Departments::offers;};b>class Leagues <key <name>> {attribute name;relationship Teams containsinverse Teams::belongs;};class Teams<key <name,belongs>> {attribute name,relationship Leagues belongsinverse Leagues::contains;relationship Players playinverse Players::plays;};class Players <key<number,plays>> {attribute number,relationship Teams playsinverse Teams::play;4.9.7class Students <key email> {attribute string email;attribute string name;relationship Courses isTAinverse Courses::TA;relationship Courses Takesinverse Courses::TakenBy;};class Professors <key email> {attribute string email;attribute string name;relationship Departments WorksForinverse Department::Works;relationship Courses Teachesinverse Courses::TaughtBy;};class Courses <key <no,semester,section>> {attribute string no;attribute string semester;attribute string section;relationship Students TAinverse Students::isTA;relationship Students TakenByinverse Students::Takes;relationship Professors TaughtByinverse Professors::Teaches;relationship Departments OfferedByinverse Departments::Offer;};class Departments <key name> {attribute name;relationship Courses Offerinverse Courses::OfferedBy;relationship Professors Worksinverse Professors::WorksFor;};A relationship is its own inverse when for every attribute pair in the relationship, the inverse pair also exists. A relation with such a relationship is called symmetric in set theory. e.g. A relationship called SiblingOf in Person relation is its own inverse.a>Customers<ssNo,name,addr,phone>Account<number,type,balance>Owns<ssNo,accountNumber>b>Accounts<number,balance,type,owningCustomerssNo>Customers<ssNo,name>Addresses<ownerssNo,street,state,city>Phones<ownerssNo,street,state,city,phonearea,phoneno>We can remove Addresses relation since its attributes are a subset of relation Phones.c>Fans<name,colors>RootedBy<fan_name,teamname>Admires<fan_name,playername>Players<name,teamname,is_captain>Teams<name>--remove subset of teamcolorTeamcolors<name,colorname>Colors<colorname>class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};Person<name,mothername,fathername>The children relationship is many-many but the information can be deduced from Person relation. Hence below relation is redundant.Parent-Child<parent, child>First consider each struct as if it were an atomic value i.e. key and value association pairs can be treated as two attributes. After applying normalization, the attributes can be replaced by the fields of the structs.<a>Struct Card { string rank, string suit };<b>class Hand {attribute Set theHand;};<c>Hands<handId, rank, suit>Each tuple corresponds to one card of a hand. HandId is required key to identify a hand.<d> Hand contains an array of 5 elementsclass PokerHand{attribute Array Hand<Card card1,Card card2,Card card3,Cardcard4,Card card5>}PokerHandS<handId,rank1,suit1,,rank2,suit2,rank3,suit3,rank4,suit4,rank5,suit5><e>class Deal {attribute Set <Struct PlayerHand { string Player, Hand theHand } > theDeal;}<f> PokerDeal consist of a player and array of five card deal.class PokerDeal{string Player,attribute Array Hand<Card card1,Card card2,Cardcard3,Card card4,Card card5>}<g> Above can similarly be represented by key player and a value consisting offive element array.<h>dealID is a key for Deals. Thus the relations for classes Deals and Hands are:Deals<dealID, player, handID>Hands<handID, rank, suit>A simpler relation Deals below can also represents the classes:Deals<dealID, player, rank, suit><i>The relation Deals<dealID,card> cannot identify the hand to which a card belongs. Also two attributes are required for a card;its rank and suit.Deals<dealID, handID, rank, suit><a>C<a, f, g><b>C<a, f, g, count>.<c>C<a, f, g, position><d>C<a, f, g, i, j>11 / 11。
数据库技术与应用课后习题答案
第一章习题答案1.1 选择题1. A2. C3. C4. B5. C6. A7. C8. B9. D 10. A 11. D 12. A 13. A1.2 填空题数据数据的逻辑独立性数据的物理独立性层次数据模型,网状数据模型,关系数据模型能按照人们的要求真实地表示和模拟现实世界、容易被人们理解、容易在计算机上实现实体、记录属性、字段码域一对一、一对多、多对多E-R模型E-R模型层次模型、网状模型、关系模型数据操作、完整性约束矩形、菱形、椭圆形层次模型、一对多网状模型关系模型关系外模式、模式、内模式三级模式、两级映像外模式、模式、内模式数据、程序数据逻辑、数据物理DBMS数据库管理系统、DBA数据库管理员1.4 综合题2.注：各实体的属性省略了3.第二章习题答案1.1 单项选择题1. C2. A3. B4. C5. C6. D7. A8. B1.2 填空题集合2. 能唯一标识一个实体的属性系编号, 学号,系编号关系, 元组, 属性关系模型,关系, 实体, 实体间的联系投影1.4 综合题1. πsnoσcno=’2’SC2. πsnoσcname=’信息系统’SCCOURSE3. πsno,SNAME,SAGESTUDENT第三章习题答案1.1select from jobs1.2select emp_id,fname+'-'+lname as 'Name' from employee1.3select emp_id,fname+'-'+lname as 'Name',Yeargetdate-Yearhire_date as 'worke time' from employee order by 'worke time'2.1select from employee where fname like 'f%'2.2select from employee where job_id='11'2.3select emp_id,fname+'-'+lname as 'Name', Yeargetdate-Yearhire_date as worketime from employeewhere Yeargetdate-Yearhire_date >5order by worketime2.4select from employee where castjob_id as integer>=5 and castjob_id as integer<=8 2.5select from employee where fname='Maria'2.6select from employee where fname like '%sh%' or lname like '%sh%'3.1select from sales where ord_date <'1993-1-1'4.1select distinct bh, zyh from stu_info wherebh inselect bh from stu_infogroup by bhhaving count>30 and count<40order by bh或者是select bh,zyh from stu_infogroup by zyh,bhhaving countbh>30 and countbh<40order by bh4.2select from gbanwhere bh like '计%'4.3select from gfiedwhere zym like '%管理%'4.4select xh,xm,zym,stu_info.bh,rxsj from stu_info,gfied,gban where nl>23and stu_info.zyh=gfied.zyh and stu_info.bh=gban.bh4.5select zyh,count from gbanwhere xsh='03'group by zyh第四章习题答案4.1 单项选择题：B 2、A 3、C 4、A 5、A 6、C 7、C 8、D 9、B 10、A 11、C或B,即书上121页例题中from的写法12、A 13、C 14、C 15、C4.2 填空题：drop tablealter table add <列名或约束条件>with check option基本表基本表distinct group by roder by数据定义数据操纵数据控制distinctlike % _自含式嵌入式10、order by asc desc4.3 综合题1、SELECT XH, XM, ZYM, BH, RXSJFROM STU_INFO, GFIEDWHERE STU_INFO.ZYH = GFIED.ZYH AND NL > 23 AND XBM = '男'2、SELECT ZYM 专业名, count 人数 FROM STU_INFO, GFIEDWHERE STU_INFO.XSH = '03' AND STU_INFO.ZYH = GFIED.ZYHGROUP BY ZYM注意：该题目中给出的条件XSH = '03'中的03代表的是“控制科学与工程”学院,信息学院的代码是12,大家可根据具体情况来做该题;3、SELECT bh,count as 人数 FROM STU_INFO GROUP BY bh4、SELECT XH, XM, XBM, BH FROM STU_INFOWHERE ZYH INSELECT ZYHFROM STU_INFOWHERE XM = '李明'ORDER BY XH5、SELECT DISTINCT GCOURSE.KCH, KM FROM STU_INFO, XK, GCOURSEWHERE XK.KCH = GCOURSE.KCH AND STU_INFO.XSH = '12'AND STU_INFO.XH = XK.XH该题中设计到的课程名称只有在GCOURSE表中存在,所以在题目开始的几个表中还应填加该表;另外把信息学院的代码改为12;6、SELECT COUNTDISTINCT KCH AS 选课门数, AVGKSCJ AS 平均成绩FROM STU_INFO, XKWHERE STU_INFO.XH = XK.XH AND XSH = '12'7、SELECT DISTINCT STU_INFO.XH, XM, BH, ZYM, KMFROM STU_INFO, XK, GFIED, GCOURSEWHERE KSCJ > 85 AND STU_INFO.XH = XK.XH AND XK.KCH = GCOURSE.KCH AND STU_INFO.ZYH = GFIED.ZYHORDER BY ZYM, BH, STU_INFO.XH8、SELECT STU_INFO.XH, XM, XSM, ZYM, BH, PYCCMFROM STU_INFO, XK, GDEPT, GFIEDWHERE KKNY = '20011' AND STU_INFO.XH = XK.XH AND STU_INFO.XSH = GDEPT.XSH AND STU_INFO.ZYH = GFIED.ZYHGROUP BY STU_INFO.XH, XM, XSM, ZYM, BH, PYCCMHAVING COUNT > 109、SELECT DISTINCT bhFROM STU_INFO10、DELETE FROM STU_INFOWHERE XH LIKE '2000%'或DELETE FROM STU_INFOWHERE LEFTXH,4 = '2000'11、ALTER TABLE STU_INFOADD BYSJ varchar812、UPDATE XKSET KSCJ = 60WHERE KSCJ BETWEEN 55 AND 59 andXH inSELECT xhFROM stu_infoWHERE zyh = '0501'andKCH inSELECT kchFROM gcourseWHERE km = '大学英语'前面已经考虑到在该题目中应该加入学生课程信息表GCOURSE13、UPDATE GCOURSESET KCXF=6WHERE KCH = '090101'14、CREATE TABLE CCOURSEKCH char6,KM varchar30,KCYWM varchar3015、CREATE VIEW ISE ASSELECTFROM STU_INFOWHERE XSH=’12’第五章课后答案5.11~7 BABABCB5.21 使属性域变为简单域消除非主属性对主关键字的部分依赖消除非主属性对主关键字的传递依赖2 平凡函数依赖3 Y也相同唯一的Y值5.31 函数依赖：P136定义5.1部分函数依赖：P138定义5.4完全函数依赖：P138定义5.4传递函数依赖：P138定义5.51NF:P139定义5.62NF:P141定义5.73NF:P142定义5.8BCNF:P144定义5.9在全码关系中R〈U,F〉中若存在这样的码X,属性组Y及非主属性Z 使得X→Y, Y→Z成立,所以全码关系R〈U,F〉∈3NF;在全码关系R〈U,F〉中,对于R中的函数依赖,若X→Y且X必含有码,所以全码关系R∈BCNF 2 1 R的码是Sno,Cno,R是1NF,因为Teacher和Title属性部分函数依赖于码Sno,Cno,所以R∈1NF2SCSno,Cno,GradeCTCno,teacher TTTeacher,title3 D->B C->A4 需求分析需求分析是数据库设计的第一个阶段,从数据库设计的角度来看,需求分析的任务是对现实世界要处理的对象组织、部门、企业等进行详细的调查了解,通过对原系统的了解,收集支持新系统的基础数据并对其进行处理,在此基础上确定新系统的功能;概念结构设计阶段将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计;简单地说数据库概念结构设计的任务就是根据需求分析所确定的信息需求,建立信息模型;如E-R模型;逻辑结构设计阶段数据库逻辑结构设计的任务是把概念结构设计阶段所得到的与DBMS无关的数据模式,转换成某一个DBMS所支持的数据模型表示的逻辑结构;数据库物理设计阶段数据库物理设计是对给定的关系数据库模式,根据计算机系统所提供的手段和施加的限制确定一个最适合应用环境的物理存储结构和存取方法数据库实施阶段在数据库实施阶段,设计人员运用DBMS提供的数据语言及其宿主语言,根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行数据库运行和维护阶段数据库应用系统经过试运行后即可投入正式运行;在数据库系统运行过程中必须不断地对其进行评价、调整与修改;包括：数据库的转储和恢复、数据库的安全性和完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造;P149最后一段ER图是用来描述某一组织单位的概念模型,提供了表示实体、属性和联系的方法;构成ER图的基本要素是实体、属性和关系;实体是指客观存在并可相互区分的事特；属性指指实体所具有的每一个特性;商店商店编号,商店名,地址,电话码：商店编号顾客顾客编号,姓名,性别,家庭住址,出生年月码：顾客编号消费商店编号,顾客编号,消费金额码：商店编号,顾客编号第六章习题答案6.1 单项选择题1、A2、D3、D4、D5、B6、D7、C6.2 填空题1、原子性一致性隔离性持续性 ACID2、软故障硬故障3、静态动态4、丢失修改不可重复读读“脏”数据5、自主存取控制强制存取控制6、实体完整性约束参照完整性约束用户自定义完整性约束6.4 综合题create table 读者借书证号 char10 primary key,姓名 varchar10 not null,年龄 tinyint not null,所在院系 varchar20 not nullcreate 图书图书号 char8 primary key,书名 varchar20 not null,作者 varchar10 not null,出版社 varchar30 not null,价格 real not null check价格>0 and 价格<=120create 借阅借书证号 char10 not null,图书号 char8 not null,借阅日期 datetime not null,primary key借书证号, 图书号,foreign key借书证号 references 读者借书证号,foreign key图书号 references 图书图书号实验4 答案Select xh,xm,xbm from stu_info,gdept where stu_info.xsh=gdept.xsh and gdept.xsm=’信息科学与工程’或 Select xh,xm,xbm from stu_info where xsh=select xsh from gdept where xsm=’信息科学与工程’Select stu_info.xh,xm,km from stu_info,xk,gcourse where stu_info.xh=xk.xh and xk.kch=gcourse.kch and kscj>85Select xh,xm,xsm from stu_info,gdept where stu_info.xsh=gdept.xsh and xh like ‘2000%’Select xh, xm from stu_info where xh in select xh from xk where kch=’090101’ and kscj<60或 select stu_info.xh,xm from stu_info,xk where stu_info.xh=xk.xh and kch=’090101’ and kscj<605. select stu_info.xh,xm,km from stu_info,xk,gcourse where stu_info.xh=xk.xh and xk.kch=gcourse.kch and xsh=’12’ and kscj<606. select stu_info.xh,xm,xsm from stu_info,xk,gdept where stu_info.xsh=gdept.xsh and stu_info.xh=xk.xh and kkny=’20011’ group by stu_info.xh,xm,xsm having count>=10实验5 答案1、2题参考实验4答案3. Select xh,xm,xbm,bh from stu_info where zyh in select zyh from stu_info where xm=’李明’ order by xh实验6答案Create view num_ban as select countdistinct bh from stu_infoCreate view ban as select distinct bh from stu_infoCreate view is_stu as select xm,xbm,bh from stu_info where xsh=’01’ orxsh=’02’Create view zhang_stu as select from stu_info where xsh=’01’ and xm like ‘张%’或 Create view zhang_stu as select from stu_info,gdept where xsm=’材料科学与工程’ and xm like ‘张%’ and stu_info.xsh=gdept.xsh8. Create view 材0168 as select stu_info.,xk. from stu_info,xk where bh=’材0168’ and stu_info.xh=xk.xhCreate view gaoshu _stu as select xm from stu_info,xk,gcourse where stu_info.xh=xk.xh and gcourse.kch=xk.kch and km=’高等数学’或 Create view gaoshu _stu as select xm from stu_info where xh inselect xh from xk where kch =select kch from gcourse where km=’高等数学’。
数据库系统基础教程第四章答案
SolutionsChapter 4c we assume that a phone and address can only belong to a single customer (1-m relationship represented by arrow into customer).d)If the multiplicity of above relationships were m-to-n, the entity set becomesweak and the key ssNo of customers will be needed as part of the composite keyof the entity set.In c&d, we convert attributes phones and addresses to entity sets. Since entitysets often become relations in relational design,we must consider more efficient alternatives.Instead of querying multiple tables where key values are duplicated, we can also modify attributes:(i) Phones attribute can be converted into HomePhone, OfficePhone and CellPhone. (ii) A multivalued attribute such as alias can be kept as an attribute where asingle column can be used in relational design . concatenate all values. SQLallows a query "like '%Junius%'" to search the multiple values in a column alias.a)b)c)The relationship "played" between Teams and Players is similar to relationship "plays" between Teams and Players.The information about children can be ascertained from motherOf and fatherOf relationships. Attribute ssNo is required since names are not unique.Professor only works in at most one department.A course has at most one TA.A course is only taught by one professor and offered by one department. Students and professors have been assigned unique email ids.A course is uniquely identified by the course no, section no, and semester . cs157-3 spring 09).that for each movie, a unique studio exists that produces the movie. Each star is contracted to at most one studio.But stars could be unemployed at a given time. Thus the four-way relationship in fig can be easily into converted equivalent relationships.The owner address is repeated in AccSets and Addresses entity sets.Simplicity: AccSets does not serve any useful purpose and the design can be more simply represented by creating many-to-many relationship between Customers and Accounts.Hence address should be an attribute of entity set Customers.Faithfulness: Customers cannot be uniquely identified by their names. In real world Customers would have a unique attribute such as ssNo or customerNoand Presidents can be combined into one entity set Studios with Presidents becoming an attribute of Studios under following circumstances:1. The Presidents entity set only contains a simple attribute viz. presidentName. Additional attributes specific to Presidents might justify making Presidentsinto an entity set.The entity sets should have single attribute.a) Stars: starNameb) Movies: movieNamec) Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more information aboutstudios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace theStudios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entity set by five attributes viz.studio1, studio2, studio3, studio4, and studio5. Alternately, a compositeattribute containing concatenation of all studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searchingof such an attribute using query like '%keyword%'Augmentation rule of Functional Dependency,givenB -> M (B=Baby, M=Mother)thenBND -> M (N=Nurse, D=Doctor)Hence we can just put an arrow entering mother.a) Put an arrow entering entity set Mothers for the simplest solution (As in fig. , where a multi-way relationship was allowed, even though Movies alone could identify the Studio). However, we can display more accurate information with below figure.b)c)Again from Augmentation rule of Functional Dependency,givenBM -> DthenBMN -> DThus we can just add an arrow entering Doctors to fig . Below figure represents more accurate information however.Transitivity and Augmentation rules of Functional Dependency allow arrowentering Mothers from Births. However, a new relationship in below figure represents more accurate information.c)Design flaws in abc above 1. As suggested above, using Transitivity and Augmentation rules of Functional Dependency, much simpler design is possible.In below figure there exists a many-to-one relationship between Babies and Births and another many-to-one relationship between Births and Mothers. From transitivity of relationships, there is a many-to-one relationship between Babies and Mothers. Hence a baby has a unique mother while a birth can allow more than one baby.captain cannot exist without a team. However a player can (free agent). A recently formed (or defunct) team can exist without players or colors.c)Children can exist without mother and father (unknown).keys of both E1 and E2 are required for uniquely identifying tuples in R b)The key of E1c)The key of E2d)The key of either E1 or E2Case: All entity sets have arrows going into them . all relationships are 1-to-1Any KiOtherwise: Combination of all Ki's where there does not exist an arrow going from R to Ei.grade is not part of the key for enrollments. The keys of Students and Courses become keys of the weak entity set Enrollments.It is possible to make assignment number a weak key of Enrollments but this is not good design (redundancy since multiple assignments correspond to a course).A new entity set Assignment is created and it is also a weak entity set. Hencethe key attributes of Assignment will come from the strong entity sets to which Enrollments is connected . studentID, dept, and CourseNo.for toCust and toFlt relationships are not required since the weak entity set Bookings already contains the keys of Customers and Flights.is changed. Since toCust is no longer an identifying relationship, SSNo is no longer a part of Bookings relation.Bookings(flightNo,flightDay,row,seat)ToCust(custSSNO,flightNo,flightDay,row,seat)The above relations are merged intoBookings(flightNo,flightDay,row,seat,custSSNo)However custSSNo is no longer a key of Bookings relation. It becomes a foreign key instead.Ships(name, yearLaunched)SisterOf(name, sisterName)on other relationships not shown in ER diagram, studioName may not be required as a key of Contracts (or not even required as an attribute of Contracts).(b)Students(studentID)Courses(dept,courseNo)Enrollments(studentID,dept,courseNo,grade)(c)Departments(name)Courses(deptName,number)(d)Leagues(name)Teams(leagueName,teamName)Players(leagueName,teamName,playerName)weak relation Courses has the key from Depts along with number. Hence there is no relation for GivenBy relationship.(a)Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, allocation)(b) LabCourses has all the attributes of Courses.Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, room, allocation)(c) Courses and LabCourses are combined into one relation.Depts(name, chair)Courses(number, deptName, room, allocation)FatherOf and MotherOf are many-one relationships from Child, there is no need for a separate relation for them. Similarly the one-one relationship Married can be included in Father (or Mother). ChildOf is a many-many relationship and needs a separate relation.However the ChildOf relation is not required since the relationship can be deduced from FatherOf and MotherOf relationships contained in Child relation. (b)A person cannot be both Mother and Father.Person(name,address)PersonChild(name,address)PersonChildFather(name,address)PersonChildMother(name,address)PersonFather(name,address)PersonMother(name,address)ChildOf(personName,personAddress,childName,childAddress)FatherOf(childName,childAddress,fatherName,fatherAddress)MotherOf(childName,childAddress,motherName,motherAddress)Married(husbandName,husbandAddress,wifeName,wifeAddress)The many-many ChildOf relationship again requires a relation.An entity belongs to one and only one class when using object-oriented approach. Hence, the many-one relations MotherOf and FatherOf could be added as attributes to PersonChild,PersonChildFather, and PersonChildMother relations.Similarly the Married relation can be added as attributes to PersonChildMother and PersonMother (or the corresponding father relations).(c) For the Person relation at least one of husband and wife attributes will be null.Person(personName,personAddress,fatherName,fatherAddress,motherName,motherAddres ss,wifeName,wifeAddresss,husbandName,husbandAddress)ChildOf(personName,personAddress,childName,childAddress)cannot belong to both male and female branch of the ER diagram.Moreover since an entity belongs to one and only one class when using object-oriented approach, no entity belongs to People relation.Again we could replace MotherOf and FatherOf relations by adding as attributesto PeopleMale,PeopleMaleFathers,PeopleFemale, and PeopleFemaleMothers relations.(c)People(name,fatherName,motherName)ChildOf(personName,childName)entity set results in one relation. Thus both the minimum and maximum number of relations is e.The root relation has a attributes including k keys. Thus the minimum number of attributes is a. All other relations include the k keys from root along withtheir a attributes. Thus the maximum number of attributes is a+k.(b)The relation for root will have a attributes. The relation representing the whole tree will have e*a attributes.The number of relations will depend on the shape of the tree. A tree of eentities where only one child exists(say left child only) would have the minimum number of relations. Thus below figure will only contain 4 subtrees that contain root E1,E1E2,E1E2E3, and E1E2E3E4. With e entity sets, minimum e relations are possible.The maximum number of subtrees result when all the entities(except root) are at depth 1. Thus below figure will contain 8 subtrees that contain rootE1,E1E2,E1E3,E1E4,E1E2E3,E1E3E4,E1E2E4,and E1E2E3E4. With e entity sets, maximum2^(e-1) relations are possible.(c)The nulls method always results in one relation and contains attributes fromall e entities . e*a attributes.Summarizing for a,b, and c above;#Components #RelationsMin Max Min Max Methodstraight-E/R a a e eobject-oriented a e*a e 2^(e-1) nulls e*a e*a 1 1and Females subclasses are complete. Mothers and Fathers are partial. All subclasses are disjoint.convert the ternary relationship Contracts into three binary relationships between a new entity set Contracts and existing entity sets.self-association ParentOf for entity set people has multiplicity 0..2 at parent role end.In a Library database, if a patron can loan at most 12 books, them multiplicity is 0..12.For a FullTimeStudents entity set, a relationship of multiplicity 5..* must exist with Courses (A student must take at least5 courses to be classified FullTime."SSNo",name,addr,phone)Flights("number","day",aircraft)Bookings(row,seat,"custSSNo","FlightNumber","FlightDay") "title","year",length,genre)Studios("name",address)Presidents("cert#",name,address)Owns("movieTitle","movieYear",studioName)Runs("studioName",presCert#)b)Since the subclasses are disjoint, Object Oriented Approach is used. The hierarchy is not complete. Hence four relations are required Movies(title,year,length,genre)MurderMysteries(title,year,length,genre,weapon)Cartoons(title,year,length,genre)Cartoon-MurderMysteries(title,year,length,genre,weapon)Movies("title","year",length,genre)MurderMysteries("title","year",length,genre,weapon)Cartoons("title","year",length,genre)Cartoon-MurderMysteries("title","year",length,genre,weapon)c)Customers(ssNo,name,phone,address)Accounts(number,balance,type)Owns(custSSNo,accountNumber)Customers("ssNo",name,phone,address)Accounts("number",balance,type)Owns("custSSNo","accountNumber")d)Teams(name,captainName)Players(name,teamName)Fans(name,favoriteColor)Colors(colorname)For Displays association,TeamColors(teamName,colorname)RootsFor(fanName,teamName)Admires(fanName,playerName)Teams("name",captainName)Players("name",teamName)Fans("name",favoriteColor)Colors("colorname")For Displays association,TeamColors("teamName","colorname")RootsFor("fanName","teamName")Admires("fanName","playerName")e)People(ssNo,name,fatherSSNo,motherSSNo)People("ssNo",name,fatherssNo,motherssNo)f)Students(email,name)Courses(no,section,semester,professorEmail)Departments(name)Professors(email,name,worksDeptName)Takes(letterGrade,studentEmail,courseNo,courseSection,courseSemester)Students("email",name)Courses("no","section","semester",professorEmail)Departments("name")Professors("email",name,worksDeptName)Takes(letterGrade,"studentEmail","courseNo","courseSection","courseSemester") and every object is a member of exactly one subclass at leaf level. We have nine classes at the leaf of hierarchy. Hence we need nine relations.b)All objects only belong to one subclass and its ancestors. Hence, we need not consider every possible subtree but rather the total number of nodes in tree. Hence we need thirteen relations.c)We need all possible subtrees. Hence 218 relations are required.Customer (key (ssNo)){attribute integer ssNo;attribute string name;attribute string addr;attribute string phone;relationship Set<Account> ownsAcctsinverse Account::ownedBy;};class Account (key (number)){attribute integer number;attribute string type;attribute real balance;relationship Set<Customer> ownedByinverse Customer::ownsAccts;};class Account to contain relationship Customer ownedBy (no Set)b)Also remove set in relationship ownsAccts of class Customer.c)ODL allows a collection of primitive types as well as structures. To class Customer add following attributes in place of simple attributes addr and phone: Set<string phone>Set<Struct addr{string street,string city,string state}>d)ODL allows structures and collections recursively.Set<Struct addr{string street,string city,string state},Set<string phone>>are allowed in ODL. Hence, Colors Set can become an attribute of Teams.class Colors(key(colorname)){attribute string colorname;relationship Set<Fans> FavoredByinverse Fans::Favors;relationship set<Teams> DisplayedByinverse Teams::Displays;};class Teams(key(name)){attribute string name;relationship set<Colors> Displaysinverse Colors::DisplayedBy;relationship set<Players> PlayedByinverse Players::Plays;relationship PLayers CaptainedByinverse Platyers::Captains;relationship set<Fans> RootedByinverse Fans::Roots;};class Players(key(name)){attribute string name;relationship Set<Teams> Playsinverse Teams::PlayedBy;relationship Teams Captainsinverse Teams::CaptainedBy;relationship Set<Fans> AdmiredByinverse Fans::Admires;};class Fans(key(name)){attribute string name;relationship Colors Favorsinverse Colors::FavoredBy;relationship Set<Teams> RootedByinverse Teams::Roots;relationship Set<Players> Admiresinverse Players::AdmiredBy;};Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};struct education{string degree,string school,string date} cannot have duplication.Hence use of Sets does not make any different as compared to bags, lists, or arrays.Lists will allow faster access/queries due to the already sorted nature.Departments(key (name)) {attribute string name;relationship Courses offersinverse Courses::offeredBy;};class Courses(key (number,offeredBy)) {attribute string number;relationship Departments offeredByinverse Departments::offers;};b)class Leagues (key (name)) {attribute name;relationship Teams containsinverse Teams::belongs;};class Teams(key (name,belongs)) {attribute name,relationship Leagues belongsinverse Leagues::contains;relationship Players playinverse Players::plays;};class Players (key(number,plays)) {attribute number,relationship Teams playsinverse Teams::play;};class Students (key email) {attribute string email;attribute string name;relationship Courses isTAinverse Courses::TA;relationship Courses Takesinverse Courses::TakenBy;};class Professors (key email) {attribute string email;attribute string name;relationship Departments WorksForinverse Department::Works;relationship Courses Teachesinverse Courses::TaughtBy;};class Courses (key (no,semester,section)) {attribute string no;attribute string semester;attribute string section;relationship Students TAinverse Students::isTA;relationship Students TakenByinverse Students::Takes;relationship Professors TaughtByinverse Professors::Teaches;relationship Departments OfferedByinverse Departments::Offer;};class Departments (key name) {attribute name;relationship Courses Offerinverse Courses::OfferedBy;relationship Professors Worksinverse Professors::WorksFor;};relationship is its own inverse when for every attribute pair in the relationship, the inverse pair also exists. A relation with such a relationship is called symmetric in set theory. . A relationship called SiblingOf in Person relation is its own inverse.can remove Addresses relation since its attributes are a subset of relation Phones.c)Fans(name,colors)RootedBy(fan_name,teamname)Admires(fan_name,playername)Players(name,teamname,is_captain)Teams(name)--remove subset of teamcolor Teamcolors(name,colorname)Colors(colorname)d)class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};Person(name,mothername,fathername)The children relationship is many-many but the information can be deduced from Person relation. Hence below relation is redundant.Parent-Child(parent, child)consider each struct as if it were an atomic value . key and value association pairs can be treated as two attributes. After applying normalization,the attributes can be replaced by the fields of the structs.Struct Card { string rank, string suit };(b)class Hand {attribute Set theHand;};(c)Hands(handId, rank, suit)Each tuple corresponds to one card of a hand. HandId is required key to identify a hand.(d) Hand contains an array of 5 elementsclass PokerHand{attribute Array Hand(Card card1,Card card2,Card card3,Cardcard4,Card card5)}PokerHandS(handId,rank1,suit1,,rank2,suit2,rank3,suit3,rank4,suit4,rank5,suit5) (e)class Deal {attribute Set <Struct PlayerHand { string Player, Hand theHand } > theDeal;}(f) PokerDeal consist of a player and array of five card deal.class PokerDeal{string Player,attribute Array Hand(Card card1,Card card2,Cardcard3,Card card4,Card card5)}(g) Above can similarly be represented by key player and a value consisting of five element array.(h)dealID is a key for Deals. Thus the relations for classes Deals and Hands are:Deals(dealID, player, handID)Hands(handID, rank, suit)A simpler relation Deals below can also represents the classes:Deals(dealID, player, rank, suit)(i)The relation Deals(dealID,card) cannot identify the hand to which a card belongs. Also two attributes are required for a card;its rank and suit.Deals(dealID, handID, rank, suit)C(a, f, g)(b)C(a, f, g, count)(c)C(a, f, g, position)(d)C(a, f, g, i, j)。
数据库原理及应用课后习题答案第4到6章
4.8 习题1. 简述数据库设计过程。
答：通常将数据库设计分为以下六个阶段：1) 需求分析阶段。
2) 概念设计阶段。
3) 逻辑设计阶段。
4) 物理设计阶段。
5) 实现阶段。
6) 运行维护阶段。
2. 简述数据库设计过程的各个阶段上的设计描述。
答：1) 需求分析：需求分析阶段应对系统的整个应用情况作全面的、详细的调查、确定用户的目标，收集支持系统总的设计目标的基础数据和对这些数据的要求，确定用户需求，并把这些要求写成用户和数据库设计者都能够接受的文档。
确定用户需求可以通过对不同层次的企业管理人员进行个人访问得到。
还应了解系统将来要发生的变化，充分考虑系统的可能的扩充和变动，使系统设计更符合未来发展方向。
2) 概念结构设计：概念模型可以看成是现实世界到机器世界的一个过渡的中间层次。
在设计数据库系统时，要把现实世界的事物通过认识和抽象转换为信息世界的概念模型，再把概念模型转换为机器世界的数据模型。
概念结构设计是整个数据库设计的关键通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。
3) 逻辑结构设计：逻辑结构设计将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化。
4) 物理结构设计：物理结构设计为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
5) 数据库实施：运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果，建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。
6) 数据库运行和维护：数据库应用系统经过试运行后即可投入正式运行。
3. 简述数据库设计的特点。
答：数据库设计的3个特点：(1) 反复性（Iterative）一个性能优良的数据库不可能一次性的设计完成，需要经过多次的、反复的设计。
(2) 试探性（Tentative）一个数据库设计完毕，并不意味着数据库设计工作的完成，还需要经过实际使用的检测。
通过试探性的使用，再进一步完善数据库设计。
数据库系统基础教程第四章答案
SolutionsChapter 4c we assume that a phone and address can only belong to a single customer (1-m relationship represented by arrow into customer).d)In d we assume that an address can only belong to one customer and a phone can exist at only one address.If the multiplicity of above relationships were m-to-n, the entity set becomes weak and the key ssNo of customers will be needed as part of the composite key of the entity set.In c&d, we convert attributes phones and addresses to entity sets. Since entity sets often become relations in relational design,we must consider more efficient alternatives.Instead of querying multiple tables where key values are duplicated, we can also modify attributes:(i) Phones attribute can be converted into HomePhone, OfficePhone and CellPhone.(ii) A multivalued attribute such as alias can be kept as an attribute where a single column can be used in relational design . concatenate all values. SQL allows a query "like '%Junius%'" to search the multiple values in a column alias.a) b)c)The relationship "played" between Teams and Players is similar to relationship "plays" between Teams and Players.The information about children can be ascertained from motherOf and fatherOf relationships. Attribute ssNo is required since names are not unique.Professor only works in at most one department.A course has at most one TA.A course is only taught by one professor and offered by one department.Students and professors have been assigned unique email ids.A course is uniquely identified by the course no, section no, and semester . cs157-3 spring 09).that for each movie, a unique studio exists that produces the movie. Each star is contracted to at most one studio. But stars could be unemployed at a given time. Thus the four-way relationship in fig can be easily into converted equivalent relationships.The owner address is repeated in AccSets and Addresses entity sets.Simplicity: AccSets does not serve any useful purpose and the design can be more simply represented by creating many-to-many relationship between Customers and Accounts.Right kind of element: The entity set Addresses has a single attribute address. A customer cannot have more than one address.Hence address should be an attribute of entity set Customers.Faithfulness: Customers cannot be uniquely identified by their names. In real world Customers would have a unique attribute such as ssNo or customerNoand Presidents can be combined into one entity set Studios with Presidents becoming an attribute of Studios under following circumstances:1. The Presidents entity set only contains a simple attribute viz. presidentName. Additional attributes specific to Presidents might justify making Presidents into an entity set.The entity sets should have single attribute.a) Stars: starNameb) Movies: movieNamec) Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more information about studios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace theStudios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entity set by five attributes viz. studio1, studio2, studio3, studio4, and studio5. Alternately, a composite attribute containing concatenation of all studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searching of such an attribute using query like '%keyword%'Augmentation rule of Functional Dependency,givenB -> M (B=Baby, M=Mother)thenBND -> M (N=Nurse, D=Doctor)Hence we can just put an arrow entering mother.a) Put an arrow entering entity set Mothers for the simplest solution (As in fig. , where a multi-way relationship was allowed, even though Movies alone could identify the Studio). However, we can display more accurate information with below figure.b)c)Again from Augmentation rule of Functional Dependency,givenBM -> DthenBMN -> DThus we can just add an arrow entering Doctors to fig . Below figure represents more accurate information however.Transitivity and Augmentation rules of Functional Dependency allow arrow entering Mothers from Births. However, a new relationship in below figure represents more accurate information.c)Design flaws in abc above 1. As suggested above, using Transitivity and Augmentation rules of Functional Dependency, much simpler design is possible.In below figure there exists a many-to-one relationship between Babies and Births and another many-to-one relationship between Births and Mothers. From transitivity of relationships, there is a many-to-one relationship between Babies and Mothers. Hence a baby has a unique mother while a birth can allow more than one baby.captain cannot exist without a team. However a player can (free agent). A recently formed (or defunct) team can exist without players or colors.c)Children can exist without mother and father (unknown).keys of both E1 and E2 are required for uniquely identifying tuples in Rb)The key of E1c)The key of E2d)The key of either E1 or E2Case: All entity sets have arrows going into them . all relationships are 1-to-1Any KiOtherwise: Combination of all Ki's where there does not exist an arrow going from R to Ei.grade is not part of the key for enrollments. The keys of Students and Courses become keys of the weak entity set Enrollments.It is possible to make assignment number a weak key of Enrollments but this is not good design (redundancy since multiple assignments correspond to a course). A new entity set Assignment is created and it is also a weak entity set. Hence the key attributes of Assignment will come from the strong entity sets to which Enrollments is connected . studentID, dept, and CourseNo.for toCust and toFlt relationships are not required since the weak entity set Bookings already contains the keys of Customers and Flights.is changed. Since toCust is no longer an identifying relationship, SSNo is no longer a part of Bookings relation. Bookings(flightNo,flightDay,row,seat)ToCust(custSSNO,flightNo,flightDay,row,seat)The above relations are merged intoBookings(flightNo,flightDay,row,seat,custSSNo)However custSSNo is no longer a key of Bookings relation. It becomes a foreign key instead.Ships(name, yearLaunched)SisterOf(name, sisterName)on other relationships not shown in ER diagram, studioName may not be required as a key of Contracts (or not even required as an attribute of Contracts).(b)Students(studentID)Courses(dept,courseNo)Enrollments(studentID,dept,courseNo,grade)(c)Departments(name)Courses(deptName,number)(d)Leagues(name)Teams(leagueName,teamName)Players(leagueName,teamName,playerName)weak relation Courses has the key from Depts along with number. Hence there is no relation for GivenBy relationship.(a)Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, allocation)(b) LabCourses has all the attributes of Courses.Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, room, allocation)(c) Courses and LabCourses are combined into one relation.Depts(name, chair)Courses(number, deptName, room, allocation)FatherOf and MotherOf are many-one relationships from Child, there is no need for a separate relation for them. Similarly the one-one relationship Married can be included in Father (or Mother). ChildOf is a many-many relationship and needs a separate relation.However the ChildOf relation is not required since the relationship can be deduced from FatherOf and MotherOf relationships contained in Child relation.(b)A person cannot be both Mother and Father.Person(name,address)PersonChild(name,address)PersonChildFather(name,address)PersonChildMother(name,address)PersonFather(name,address)PersonMother(name,address)ChildOf(personName,personAddress,childName,childAddress)FatherOf(childName,childAddress,fatherName,fatherAddress)MotherOf(childName,childAddress,motherName,motherAddress)Married(husbandName,husbandAddress,wifeName,wifeAddress)The many-many ChildOf relationship again requires a relation.An entity belongs to one and only one class when using object-oriented approach. Hence, the many-one relations MotherOf and FatherOf could be added as attributes to PersonChild,PersonChildFather, and PersonChildMother relations.Similarly the Married relation can be added as attributes to PersonChildMother and PersonMother (or the corresponding father relations).(c) For the Person relation at least one of husband and wife attributes will be null.Person(personName,personAddress,fatherName,fatherAddress,motherName,motherAddresss,wifeName,wifeAddres ss,husbandName,husbandAddress)ChildOf(personName,personAddress,childName,childAddress)cannot belong to both male and female branch of the ER diagram.Moreover since an entity belongs to one and only one class when using object-oriented approach, no entity belongs to People relation.Again we could replace MotherOf and FatherOf relations by adding as attributes toPeople(name,fatherName,motherName)ChildOf(personName,childName)entity set results in one relation. Thus both the minimum and maximum number of relations is e.The root relation has a attributes including k keys. Thus the minimum number of attributes is a. All other relations include the k keys from root along with their a attributes. Thus the maximum number of attributes is a+k.(b)The relation for root will have a attributes. The relation representing the whole tree will have e*a attributes.The number of relations will depend on the shape of the tree. A tree of e entities where only one child exists(say left child only) would have the minimum number of relations. Thus below figure will only contain 4 subtrees that contain root E1,E1E2,E1E2E3, and E1E2E3E4. With e entity sets, minimum e relations are possible.The maximum number of subtrees result when all the entities(except root) are at depth 1. Thus below figure will contain 8 subtrees that contain root E1,E1E2,E1E3,E1E4,E1E2E3,E1E3E4,E1E2E4,and E1E2E3E4. With e entity sets, maximum 2^(e-1) relations are possible.(c)The nulls method always results in one relation and contains attributes from all e entities . e*a attributes. Summarizing for a,b, and c above;#Components #RelationsMethodstraight-E/R a a e e object-oriented a e*a e 2^(e-1) nulls e*a e*a 1 1and Females subclasses arecomplete. Mothers and Fathers are partial. All subclasses are disjoint.convert the ternary relationship Contracts into three binary relationships between a new entity set Contracts and existing entity sets.self-association ParentOf for entity set people has multiplicity 0..2 at parent role end.In a Library database, if a patron can loan at most 12 books, them multiplicity is 0..12.For a FullTimeStudents entity set, a relationship of multiplicity 5..* must exist with Courses (A student must take at least5 courses to be classified FullTime."SSNo",name,addr,phone)Flights("number","day",aircraft)Bookings(row,seat,"custSSNo","FlightNumber","FlightDay") "title","year",length,genre)Studios("name",address)Presidents("cert#",name,address)Owns("movieTitle","movieYear",studioName)Runs("studioName",presCert#)b)Since the subclasses are disjoint, Object Oriented Approach is used. The hierarchy is not complete. Hence four relations are required Movies(title,year,length,genre)MurderMysteries(title,year,length,genre,weapon)Cartoons(title,year,length,genre)Cartoon-MurderMysteries(title,year,length,genre,weapon) Movies("title","year",length,genre)MurderMysteries("title","year",length,genre,weapon)Cartoons("title","year",length,genre)Cartoon-MurderMysteries("title","year",length,genre,weapon)c)Customers(ssNo,name,phone,address)Accounts(number,balance,type)Owns(custSSNo,accountNumber)Customers("ssNo",name,phone,address)Accounts("number",balance,type)Owns("custSSNo","accountNumber")d)Teams(name,captainName)Players(name,teamName)Fans(name,favoriteColor)Colors(colorname)For Displays association,TeamColors(teamName,colorname)RootsFor(fanName,teamName)Admires(fanName,playerName)Teams("name",captainName)Players("name",teamName)Fans("name",favoriteColor)Colors("colorname")For Displays association,TeamColors("teamName","colorname")RootsFor("fanName","teamName")Admires("fanName","playerName")e)People(ssNo,name,fatherSSNo,motherSSNo)People("ssNo",name,fatherssNo,motherssNo)f)Students(email,name)Courses(no,section,semester,professorEmail)Departments(name)Professors(email,name,worksDeptName)Takes(letterGrade,studentEmail,courseNo,courseSection,courseSemester)Students("email",name)Courses("no","section","semester",professorEmail)Departments("name")Professors("email",name,worksDeptName)Takes(letterGrade,"studentEmail","courseNo","courseSection","courseSemester")and every object is a member of exactly one subclass at leaf level. We have nine classes at the leaf of hierarchy. Hence we need nine relations.b)All objects only belong to one subclass and its ancestors. Hence, we need not consider every possible subtree but rather the total number of nodes in tree.Hence we need thirteen relations.c)We need all possible subtrees. Hence 218 relations are required.Customer (key (ssNo)){attribute integer ssNo;attribute string name;attribute string addr;attribute string phone;relationship Set<Account> ownsAcctsinverse Account::ownedBy;};class Account (key (number)){attribute integer number;attribute string type;attribute real balance;relationship Set<Customer> ownedByinverse Customer::ownsAccts;};class Account to contain relationship Customer ownedBy (no Set)b)Also remove set in relationship ownsAccts of class Customer.c)ODL allows a collection of primitive types as well as structures. To class Customer add following attributes in place of simple attributes addr and phone:Set<string phone>Set<Struct addr{string street,string city,string state}>d)ODL allows structures and collections recursively.Set<Struct addr{string street,string city,string state},Set<string phone>>are allowed in ODL. Hence, Colors Set can become an attribute of Teams. class Colors(key(colorname)){attribute string colorname;relationship Set<Fans> FavoredByinverse Fans::Favors;relationship set<Teams> DisplayedByinverse Teams::Displays;};class Teams(key(name)){attribute string name;relationship set<Colors> Displaysinverse Colors::DisplayedBy;relationship set<Players> PlayedByinverse Players::Plays;relationship PLayers CaptainedByinverse Platyers::Captains;relationship set<Fans> RootedByinverse Fans::Roots;};class Players(key(name)){attribute string name;relationship Set<Teams> Playsinverse Teams::PlayedBy;relationship Teams Captainsinverse Teams::CaptainedBy;relationship Set<Fans> AdmiredByinverse Fans::Admires;};class Fans(key(name)){attribute string name;relationship Colors Favorsinverse Colors::FavoredBy;relationship Set<Teams> RootedByinverse Teams::Roots;relationship Set<Players> Admiresinverse Players::AdmiredBy;};Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};struct education{string degree,string school,string date} cannot have duplication. Hence use of Sets does not make any different as compared to bags, lists, or arrays. Lists will allow faster access/queries due to the already sorted nature. Departments(key (name)) {attribute string name;relationship Courses offersinverse Courses::offeredBy;};class Courses(key (number,offeredBy)) {attribute string number;relationship Departments offeredByinverse Departments::offers;};b)class Leagues (key (name)) {attribute name;relationship Teams containsinverse Teams::belongs;};class Teams(key (name,belongs)) {attribute name,relationship Leagues belongsinverse Leagues::contains;relationship Players playinverse Players::plays;};class Players (key(number,plays)) {attribute number,relationship Teams playsinverse Teams::play;};class Students (key email) {attribute string email;attribute string name;relationship Courses isTAinverse Courses::TA;relationship Courses Takesinverse Courses::TakenBy;};class Professors (key email) {attribute string email;attribute string name;relationship Departments WorksForinverse Department::Works;relationship Courses Teachesinverse Courses::TaughtBy;};class Courses (key (no,semester,section)) {attribute string no;attribute string semester;attribute string section;relationship Students TAinverse Students::isTA;relationship Students TakenByinverse Students::Takes;relationship Professors TaughtByinverse Professors::Teaches;relationship Departments OfferedByinverse Departments::Offer;};class Departments (key name) {attribute name;relationship Courses Offerinverse Courses::OfferedBy;relationship Professors Worksinverse Professors::WorksFor;};relationship is its own inverse when for every attribute pair in the relationship, the inverse pair also exists. A relation with such a relationship is called symmetric in set theory. . A relationship called SiblingOf in Person relation is its own inverse.can remove Addresses relation since its attributes are a subset of relation Phones.c)Fans(name,colors)RootedBy(fan_name,teamname)Admires(fan_name,playername)Players(name,teamname,is_captain)Teams(name)--remove subset of teamcolorTeamcolors(name,colorname)Colors(colorname)d)class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};Person(name,mothername,fathername)The children relationship is many-many but the information can be deduced from Person relation. Hence below relation is redundant.Parent-Child(parent, child)consider each struct as if it were an atomic value . key and value association pairs can be treated as two attributes. After applying normalization,the attributes can be replaced by the fields of the structs.Struct Card { string rank, string suit };(b)class Hand {attribute Set theHand;};(c)Hands(handId, rank, suit)Each tuple corresponds to one card of a hand. HandId is required key to identify a hand.(d) Hand contains an array of 5 elementsclass PokerHand{attribute Array Hand(Card card1,Card card2,Card card3,Card card4,Card card5)}PokerHandS(handId,rank1,suit1,,rank2,suit2,rank3,suit3,rank4,suit4,rank5,suit5)(e)class Deal {attribute Set <Struct PlayerHand { string Player, Hand theHand } > theDeal;}(f) PokerDeal consist of a player and array of five card deal.class PokerDeal{string Player,attribute Array Hand(Card card1,Card card2,Card card3,Card card4,Card card5)}(g) Above can similarly be represented by key player and a value consisting of five element array.(h)dealID is a key for Deals. Thus the relations for classes Deals and Hands are:Deals(dealID, player, handID)Hands(handID, rank, suit)A simpler relation Deals below can also represents the classes:Deals(dealID, player, rank, suit)(i)The relation Deals(dealID,card) cannot identify the hand to which a card belongs. Also two attributes are required for a card;its rank and suit.Deals(dealID, handID, rank, suit)C(a, f, g)(b)C(a, f, g, count)(c)C(a, f, g, position)(d)C(a, f, g, i, j)。
数据库原理及应用chp4课后习题答案
第四章 关系规范化1. 设有关系模式R （职工名，项目名，工资，部门号，部门名，部门经理）（职工名，项目名，工资，部门号，部门名，部门经理） 如果规定：如果规定：每个职工可参加多个项目，各领一份工资；每个职工可参加多个项目，各领一份工资；每个项目只属于一个部门经理；每个项目只属于一个部门经理；每个部门只有一个经理。
每个部门只有一个经理。
该模式中，函数依赖关系如下图所示：该模式中，函数依赖关系如下图所示：试回答下列问题：试回答下列问题：(1) 请分析该模式是不是一个好的关系模式？为什么?（5分）分） (2) 试问关系模式R 最高已经达到第几范式？如果该模式不是一个好的模式，试用规范化理论对其进行分解使之达到第三范式。
( 5分）分）参考答案：参考答案： 2、(1) R （职工名，项目名，工资，部门号，部门名，部门经理）不是一个好的关系模式，因为：模式，因为：通过图中关系依赖图可以发现其码为（职工号，项目名）通过图中关系依赖图可以发现其码为（职工号，项目名）① 插入异常插入异常假设职工号为07102，部门号为S1的职工的职工还未还未还未参加项目，参加项目，因项目名是因项目名是主主属性，因此该学生学生的的信息无法插入R 。
② 删除异常删除异常假定某个职工个职工本来本来本来只参加只参加只参加了了项目名为“三建”的一个工的一个工程程。
现在因某种原某种原因，因，他连“他连“三三建”建”工工程也程也不参加不参加不参加了了。
因项目名是。
因项目名是主主属性，此操作将导致此操作将导致该该学生信息学生信息的的职工名项目名工资部门经理部门号部门名整个元组都要删除元组都要删除。
③ 数据冗余度大据冗余度大如果一个职工参加如果一个职工参加了了10个工个工程程，那么他的部门名的部门名称和称和称和部门经理的部门经理的部门经理的值就要重复值就要重复存储了10次。
④ 修改复杂修改复杂例如由于某种原某种原因，因，因，某某职工职工要改变要改变要改变所参所参所参与与的项目，的项目，在修改此在修改此在修改此职工职工职工元组元组元组的项目的项目名的名的同时同时同时，，还可能需要修改能需要修改其部门号，其部门号，部门名部门名称和称和称和部门经理。
数据库基础及其应用第四章课后作业
第四章结构化查询语言—SQL一、填空题1.数据库系统的外模式在SQL中称为(视图)，它由(基本表)产生出来。
2.SQL是高度(非过程化)和面向(集合)操作的语言。
3.由create schema KUCUN authorization LIU命令建立的一个数据库为(KUCUN)，所有者为(LIU)。
4.在SQL中，若一个完整性约束只涉及到一个列，则该完整性约束既可以作为(列级)完整性约束定义，也可以作为(表级)完整性约束定义，两者只选其一。
5.在列级和表级完整性约束中同时存在的约束分别为(主码)、(单值)、(外码)和(检查)等四种约束。
6.在SQL中，主码约束的关键字为(primary key)，外码约束的关键字为(foreign key)。
7.在SQL中，create table、alter table和drop table命令分别为在数据库中(建立)、(修改)和(删除)基本表结构的命令。
8.向基本表中插入数据有两种命令格式，一种称为(单行)插入格式，另一种称为(多行)插入格式。
9.在SQL中，insert、update和delete分别为对基本表进行(插入)、(修改)和(删除)记录操作的命令。
10.在SQL中，每个视图中的列可以来自不同的(表)，它是在原有表的基础上(建立)的逻辑意义上的新关系。
11.当建立一个视图后，通常只对它做(修改)和(查找)这两种操作。
12.在(基本表)中，通常不应包括由计算可以得到的属性，而在(视图)中，为了用户查询数据的方便，则需要包含它们。
13.当建立和删除一个视图时，对相应的基本表(没有影响)，当修改一个视图时，则对相应的基本表(有影响)。
14.在SQL中，建立视图、修改视图内容和删除视图的命令分别为(create view)、(update)和(drop view)。
15.在SQL新版的查询语句中，select选项实现(投影)运算，from选项实现(连接)运算，where 选项实现(选择)运算。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第四章结构化查询语言—SQL一、填空题1.数据库系统的外模式在SQL中称为(视图)，它由(基本表)产生出来。
2.SQL是高度(非过程化)和面向(集合)操作的语言。
3.由create schema KUCUN authorization LIU命令建立的一个数据库为(KUCUN)，所有者为(LIU)。
4.在SQL中，若一个完整性约束只涉及到一个列，则该完整性约束既可以作为(列级)完整性约束定义，也可以作为(表级)完整性约束定义，两者只选其一。
5.在列级和表级完整性约束中同时存在的约束分别为(主码)、(单值)、(外码)和(检查)等四种约束。
6.在SQL中，主码约束的关键字为(primary key)，外码约束的关键字为(foreign key)。
7.在SQL中，create table、alter table和drop table命令分别为在数据库中(建立)、(修改)和(删除)基本表结构的命令。
8.向基本表中插入数据有两种命令格式，一种称为(单行)插入格式，另一种称为(多行)插入格式。
9.在SQL中，insert、update和delete分别为对基本表进行(插入)、(修改)和(删除)记录操作的命令。
10.在SQL中，每个视图中的列可以来自不同的(表)，它是在原有表的基础上(建立)的逻辑意义上的新关系。
11.当建立一个视图后，通常只对它做(修改)和(查找)这两种操作。
12.在(基本表)中，通常不应包括由计算可以得到的属性，而在(视图)中，为了用户查询数据的方便，则需要包含它们。
13.当建立和删除一个视图时，对相应的基本表(没有影响)，当修改一个视图时，则对相应的基本表(有影响)。
14.在SQL中，建立视图、修改视图内容和删除视图的命令分别为(create view)、(update)和(drop view)。
15.在SQL新版的查询语句中，select选项实现(投影)运算，from选项实现(连接)运算，where 选项实现(选择)运算。
16.在SQL的查询语句中，(group by)选项实现分组统计功能，(order by)选项实现对结果表的排序功能。
17.在新版的SQL中，表之间的连接共有三种方式，对应的关键字分别为(inner join)、(left join)和(right join)。
18.在实际的数据库管理系统中，对数据库的操作方式有(命令交互)、(程序执行)和（窗口界面）三种。
19.在SQL中建立和删除数据库模式的命令分别为（create schema）和（dropschema）。
20.在SQL中完整性约束分为（列级）完整性约束和（表级）完整性约束两个方面。
21.在SQL中，列级完整性约束分为（6）各情况，表级完整性约束分为（4）种情况。
22.在列级和表级完整性约束中同时存在的约束分别为（主码）（单值）（外码）和（检查）四种约束。
23.在（列级）完整性约束中，每个约束只能涉及到一个属性；在（表级）完整性约束中，每个约束可以涉及多个属性。
24.在SQL中，单值约束的关键字为（Unique），检查约束的关键字为（check）。
25.向基本表插入数据时，可以在命令中例用关键字（Values）引出记录值，或者在命令中通过（Select）子句得到一个结果表。
26.在SQL中，对基本表进行插入、修改和删除记录的命令分别为（insert）、（update）和（delete）。
27.基本表属于全局模式的表，它是（实表），而视图则属于局部模式中的表，它是（虚表）。
28.在SQL中通过使用视图，能够使在关系规范化时被分解的关系（连接）起来，能够增强数据库的（安全）性。
29.在（基本表）中，通常不应包括由计算可以得到的属性；而在（视图）中为了用户查询数据的方便，则需要包含它们。
30.在SQL中，根据基本表建立一个视图时，包括建立了该视图的（结构）和（内容）两个方面。
31.在SQL中，create view、update和drop view命令分别为（建立）（修改）和（删除）视图的命令。
32.在SQL中，建立视图、修改视图内容和删除视图的命令分别为（create view）（update）和（drop view）。
33.在SQL的查询语句中，group by选项实现（分组统计）功能，order by选项实现对结果表的（排序）功能。
34.在新版的SQL中，查询所涉及的表及表之间的连接是在from选项中实现的，表之间的连接共有三种方式，分别称为（中间连接）（左连接）和（右连接）。
二、根据主教材第四章所给的商品库和教学库，按照下列所给的每条SQL查询语句写出相应的功能。
⑴在名称为商品库的数据库中包含有商品表1和商品表2，它们的定义分别为：商品表1(商品代号 char(8),分类名 char(8),单价 float,数量 int)商品表2(商品代号 char(8),产地 char(6),品牌 char(6),)⑵在名称为教学库的数据库中包含有学生、课程和选课三个表，它们的定义分别为：学生(学生号 char(7),姓名 char(6),性别 char(2),出生日期 datetime,专业 char(10),年级 int)课程(课程号 char(4),课程名 char(10),课程学分 int)选课(学生号 char(7),课程号 char(4),成绩 int)1.select x.商品代号,分类名,数量,品牌from 商品表1 x,商品表2 ywhere x.商品代号=y.商品代号从商品库中查询出每一种商品的商品代号、分类名、数量和品牌等信息。
2.select distinct 品牌from 商品表2从商品库中查询出所有商品的不同品牌。
3.select x.商品代号,分类名,产地,品牌from 商品表1 x,商品表2 ywhere x.商品代号=y.商品代号 and (品牌=’熊猫’ or 品牌=’春兰’)从商品库中查询出品牌为熊猫或春兰的所有商品的商品代号、分类名、产地和品牌。
4.select 课程.课程号,课程.课程名,count(*) as 选课人数from 课程,选课where 课程.课程号=选课.课程号group by 课程.课程号,课程.课程名从教学库中查询出每门课程被选修的学生数。
5.select *from 学生where 学生号 in (select 学生号from 选课group by 学生号 having count(*)=1)从教学库中查询出只选修了一门课程的全部学生。
6.select x.*from 课程 x,选课 ywhere x.课程号=y.课程号 and y.学生号=@s1and y.课程号 not in (select 课程号from 选课where 选课.学生号=@s2)从教学库中查询出学生号为@s1的学生所选修、而学生号为@s2的学生没有选修的全部课程。
注：@s1和@s2分别是已保存相应学生号的字符型变量7.select *from 课程where exists (select *from 选课where 课程.课程号=选课.课程号)从教学库中查询出所有已被学生选修的课程。
8.select *from 学生where exists (select *from 选课where 学生.学生号=选课.学生号group by 选课.学生号 having count(*)=3)从教学库中查询出同时选修了3门课程的全部学生。
9.select 专业,count(*) as 专业人数from 学生group by 专业order by 专业人数 desc从教学库中查询出每个专业的学生人数，并按人数多少降序排列。
10.select x.*,课程名,课程学分,成绩from 学生 x,课程 y,选课 zwhere x.学生号=z.学生号 and y.课程号=z.课程号order by x.学生号,z.成绩从教学库中查询出每个学生选课的全部情况，并依次按学生号和成绩排序。
11.select distinct 产地from 商品表2从商品库中查询出所有商品的不同产地。
12.select count（distinct 产地）as 产地数from 商品表2从商品库中查询出所有商品的不同产地总数。
13.select 学生.学号，count（*）as 选课门数from 学生，选课where 学生.学生号＝选课.学生号group by 学生.学生号从教学库中查询出每个学生选课的门数。
14.select distinct x.*from 学生 x，选课 y，选课 zwhere y.学生号＝z.学生号 and y.课程号<>z.课程号and x.学生号＝y.学生号从教学库中查询出至少选修了两门课程的全部学生。
15.select x.学生号，y.学生号，y.课程号from 选课 x，选课 ywhere x.学生号＝@s1 and y.学生号＝@s2 and x.课程号＝y.课程号从教学库中查询出学生号为@s1的学生和学生号为@s2的学生所选修的共同课程的课程号。
16.select * from 课程 where not exists（select * from 选课 where 课程.课程号＝选课.课程号）从教学库查询出所有未被学生选修的课程。
17.select * from 学生 where 学生号 in（select 学生号 from 选课 group by 学生号 having count（*）<=2）or not exists（select * from 选课 where 学生.学生号＝选课.学生号）从教学库中查询出最多选了2门课程（含未选任何课程）的全部学生。
18.select * from 学生 where not exists（select y.课程号 from 学生 x inner join 选课 y on x.学生号＝y.学生号where x.姓名＝@a and not exists（select * from 选课 where 学生.学生号＝选课.学生号 and y.课程号＝选课.课程号）)从教学库中查询出选修了姓名为@a的学生的全部选课的所有学生。
三、根据教材第四章所给的商品库和教学库，按照下列所给的每种功能写出相应的查询语句。
⑴在名称为商品库的数据库中包含有商品表1和商品表2，它们的定义分别为：商品表1(商品代号 char(8),分类名 char(8),单价 float,数量 int)商品表2(商品代号 char(8),产地 char(6),品牌 char(6),)⑵在名称为教学库的数据库中包含有学生、课程和选课三个表，它们的定义分别为：学生(学生号 char(7),姓名 char(6),性别 char(2),出生日期 datetime,专业 char(10),年级 int)课程(课程号 char(4),课程名 char(10),课程学分 int)选课(学生号 char(7),课程号 char(4),成绩 int)1.从商品库中查询出每种商品的商品代号、单价、数量和产地。