数据库系统原理课后答案 第四章
数据库系统基础教程课后答案第四章
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%'
数据库系统原理04735课后习题参考答案
数据库系统原理课后习题第一章. 数据库系统基本概念1.1.名词解释DB——DB是长期存储在计算机内、有组织的、统一管理的相关数据的集合。
DB能为各种用户共享，具有较小冗余度、数据间联系紧密而又有较高的数据独立性等特点。
DBMS——是位于用户与操作系统之间的一层数据管理软件，它为用户或应用程序提供访问DB的方法，包括DB的建立、查询、更新及各种数据控制。
DBS——是实现有组织地、动态地存储大量关联数据、方便多用户访问的计算机硬件、软件和数据资源组成的系统，即它是采用数据库技术的计算机系统。
联系——是实体间的相互关系。
联系的元数——与一个联系有关的实体集个数。
１：１联系——如果实体集E1中每个实体至多和实体集E2中一个实体有联系，反之亦然，那么实体集E1和E2的联系称为“一对一联系”，记为“１：１”。
１：N联系——如果实体集E1中的每个实体可以与实体集E2中的任意个（０个或多个）实体有联系，而E2中的每个实体至多和E1中的一个实体有联系，那么称E1对E2的联系是一对多联系，记作：“１：N ”。
M：N联系——如果实体集E１中的每个实体可以与实体集E2中的任意个（０个或多个）实体有联系，反之亦然，那么称E1和E2的联系是“多对多联系”，记作“M：N”。
数据模型——在数据库技术中，我们用数据模型的概念描述数据库的结构和语义，对现实世界的数据进行抽象。
根据数据抽象级别定义了四种模型：概念数据模型、逻辑数据模型、外部数据模型和内部数据模型。
概念模型——表达用户需求观点的数据全局逻辑结构的模型。
逻辑模型——表达计算机实现观点的DB全局逻辑结构的模型。
主要有层次、网状、关系模型等三种。
外部模型——表达用户使用观点的DB局部逻辑结构的模型。
内部模型——表达DB物理结构的模型。
层次模型——用树型（层次）结构表示实体类型及实体间联系的数据模型。
网状模型——用有向图结构表示实体类型及实体间联系的数据模型。
关系模型——是由若干个关系模式组成的集合。
数据库系统原理教程课后习题及答案(第四章)
第4章数据库安全性1 ．什么是数据库的安全性？答：数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏。
2 ．数据库安全性和计算机系统的安全性有什么关系？答：安全性问题不是数据库系统所独有的，所有计算机系统都有这个问题。
只是在数据库系统中大量数据集中存放，而且为许多最终用户直接共享，从而使安全性问题更为突出。
系统安全保护措施是否有效是数据库系统的主要指标之一。
数据库的安全性和计算机系统的安全性，包括操作系统、网络系统的安全性是紧密联系、相互支持的，3 ．试述可信计算机系统评测标准的情况，试述TDI / TCSEC 标准的基本内容。
答：各个国家在计算机安全技术方面都建立了一套可信标准。
目前各国引用或制定的一系列安全标准中，最重要的是美国国防部（DoD ）正式颁布的《DoD 可信计算机系统评估标准》（伽sted Co 哪uter system Evaluation criteria ，简称TcsEc ，又称桔皮书）。
（TDI / TCSEC 标准是将TcsEc 扩展到数据库管理系统，即《可信计算机系统评估标准关于可信数据库系统的解释》（Tmsted Database Interpretation 简称TDI , 又称紫皮书）。
在TDI 中定义了数据库管理系统的设计与实现中需满足和用以进行安全性级别评估的标准。
TDI 与TcsEc 一样，从安全策略、责任、保证和文档四个方面来描述安全性级别划分的指标。
每个方面又细分为若干项。
4 ．试述T csEC ( TDI ）将系统安全级别划分为4 组7 个等级的基本内容。
答：根据计算机系统对安全性各项指标的支持情况，TCSEC ( TDI ）将系统划分为四组（division ) 7 个等级，依次是D 、C ( CI , CZ ）、B ( BI , BZ , B3 ）、A ( AI ) ，按系统可靠或可信程度逐渐增高。
这些安全级别之间具有一种偏序向下兼容的关系，即较高安全性级别提供的安全保护包含较低级别的所有保护要求，同时提供更多或更完善的保护能力。
数据库系统基础教程第四章答案
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. Sinceentity 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。
数据库原理与应用教程(第三版)第四章课后习题答案
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。
数据库原理教程习题答案(全)
0000000000第1章数据库系统概述习题参考答案税务局使用数据库存储纳税人（个人或公司）信息、纳税人缴纳税款信息等。
典型的数据处理包括纳税、退税处理、统计各类纳税人纳税情况等。
银行使用数据库存储客户基本信息、客户存贷款信息等。
典型的数据处理包括处理客户存取款等。
超市使用数据库存储商品的基本信息、会员客户基本信息、客户每次购物的详细清单。
典型的数据处理包括收银台记录客户每次购物的清单并计算应交货款。
1.2 DBMS是数据库管理系统的简称，是一种重要的程序设计系统。
它由一个相互关联的数据集合和一组访问这些数据的程序组成。
数据库是持久储存在计算机中、有组织的、可共享的大量数据的集合。
数据库中的数据按一定的数据模型组织、描述和存储，可以被各种用户共享，具有较小的冗余度、较高的数据独立性，并且易于扩展。
数据库系统由数据库、DBMS（及其开发工具）、应用系统和数据库管理员组成。
数据模型是一种形式机制，用于数据建模，描述数据、数据之间的联系、数据的语义、数据上的操作和数据的完整性约束条件。
数据库模式是数据库中使用数据模型对数据建模所产生设计结果。
对于关系数据库而言，数据库模式由一组关系模式构成。
数据字典是DBMS维护的一系列内部表，用来存放元数据。
所谓元数据是关于数据的数据。
1.3 DBMS提供如下功能：（1）数据定义：提供数据定义语言DDL，用于定义数据库中的数据对象和它们的结构。
（2）数据操纵：提供数据操纵语言DML，用于操纵数据，实现对数据库的基本操作（查询、插入、删除和修改）。
（3）事务管理和运行管理：统一管理数据、控制对数据的并发访问，保证数据的安全性、完整性，确保故障时数据库中数据不被破坏，并且能够恢复到一致状态。
（4）数据存储和查询处理：确定数据的物理组织和存取方式，提供数据的持久存储和有效访问；确定查询处理方法，优化查询处理过程。
（5）数据库的建立和维护：提供实用程序，完成数据库数据批量装载、数据库转储、介质故障恢复、数据库的重组和性能监测等。
数据库系统基础教程第四章答案
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)。
数据库系统基础教程第四章答案(完整资料).doc
【最新整理，下载后即可编辑】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)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 customerNo 4.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 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 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.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.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 Babiesand 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 R b)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)c)4.4.4a)b)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 weak entity set Bookings already contains the keys of Customers and Flights.4.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 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)(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)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 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,mot herAddresss,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 attributes to 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 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 rootE1,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.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.6。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
4.1 名词解释(1)关系模型：用二维表格结构表示实体集，外键表示实体间联系的数据模型称为关系模型。
(2)关系模式：关系模式实际上就是记录类型。
它的定义包括：模式名，属性名，值域名以及模式的主键。
关系模式不涉及到物理存储方面的描述，仅仅是对数据特性的描述。
(3)关系实例：元组的集合称为关系和实例，一个关系即一张二维表格。
(4)属性：实体的一个特征。
在关系模型中，字段称为属性。
(5)域：在关系中，每一个属性都有一个取值范围，称为属性的值域，简称域。
(6)元组：在关系中，记录称为元组。
元组对应表中的一行；表示一个实体。
(7)超键：在关系中能唯一标识元组的属性集称为关系模式的超键。
(8)候选键：不含有多余属性的超键称为候选键。
(9)主键：用户选作元组标识的一个候选键为主键。
（单独出现，要先解释“候选键”）(10)外键：某个关系的主键相应的属性在另一关系中出现，此时该主键在就是另一关系的外键，如有两个关系S和SC,其中S#是关系S的主键，相应的属性S#在关系SC中也出现，此时S#就是关系SC的外键。
(11)实体完整性规则：这条规则要求关系中元组在组成主键的属性上不能有空值。
如果出现空值，那么主键值就起不了唯一标识元组的作用。
(12)参照完整性规则：这条规则要求“不引用不存在的实体”。
其形式定义如下：如果属性集K是关系模式R1的主键，K也是关系模式R2的外键，那么R2的关系中， K的取值只允许有两种可能，或者为空值，或者等于R1关系中某个主键值。
这条规则在使用时有三点应注意： 1)外键和相应的主键可以不同名，只要定义在相同值域上即可。
2)R1和R2也可以是同一个关系模式，表示了属性之间的联系。
3)外键值是否允许空应视具体问题而定。
(13)过程性语言：在编程时必须给出获得结果的操作步骤，即“干什么”和“怎么干”。
如Pascal和C语言等。
(14)非过程性语言：编程时只须指出需要什么信息，不必给出具体的操作步骤。
各种关系查询语言均属于非过程性语言。
(15)无限关系：当一个关系中存在无穷多个元组时，此关系为无限关系。
如元组表达式{t|┐R(t)}表示所有不在关系R中的元组的集合，这是一个无限关系。
(16)无穷验证：在验证公式时需对无穷多个元组进行验证就是无穷验证。
如验证公式(u)(P(u))的真假时需对所有的元组u进行验证，这是一个无穷验证的问题。
4.2 为什么关系中的元组没有先后顺序?因为关系是一个元组的集合，而元组在集合中的顺序无关紧要。
因此不考虑元组间的顺序，即没有行序。
4.3 为什么关系中不允许有重复元组?因为关系是一个元组的集合，而集合中的元素不允许重复出现，因此在关系模型中对关系作了限制，关系中的元组不能重复，可以用键来标识唯一的元组。
4.4 关系与普通的表格、文件有什么区别?关系是一种规范化了的二维表格，在关系模型中，对关系作了下列规范性限制：1)关系中每一个属性值都是不可分解的。
2)关系中不允许出现相同的元组(没有重复元组)。
3)由于关系是一个集合，因此不考虑元组间的顺序，即没有行序。
4)元组中，属性在理论上也是无序的，但在使用时按习惯考虑列的顺序。
4.5 笛卡尔积、等值联接、自然联接三者之间有什么区别?笛卡尔积对两个关系R和S进行乘操作，产生的关系中元组个数为两个关系中元组个数之积。
等值联接则是在笛卡尔积的结果上再进行选择操作，从关系R和S的笛卡儿积中选择对应属性值相等的元组；自然连接则是在等值联接(以所有公共属性值相等为条件)的基础上再行投影操作，并去掉重复的公共属性列。
当两个关系没有公共属性时，自然连接就转化我笛卡尔积。
4.6 设有关系R和S（如下：）计算：4.7 设有关系R和S（如下：）计算：4.8 如果R是二元关系，那么下列元组表达式的结果是什么?{t|(u)(R(t)∧R(u)∧(t[1]≠u[1]∨t[2]≠u[2]))}这个表达式的意思是：从关系R中选择元组，该元组满足：第1分量值或第2分量值至少有一个不等于其他某元组。
由于R是二元关系，只有两个分量，由于没有重复元组，上述条件显然满足。
所以，这个表达式结果就是关系R。
4.9 假设R和S分别是三元和二元关系，试把表达式π1,5(σ2=4∨3=4(R×S))转换成等价的：(1)汉语查询句子；(2)元组表达式；(3)域表达式。
(1)汉语表达式：从R×S关系中选择满足下列条件的元组：第2分量（R中第2分量）与第4分量（S中第1分量）值相等，或第3分量（R中第3分量）与第4分量（S中第1分量）值相等；并取第1列与第5列组成的新关系。
(2)元组表达式：{t|(u)(v)(R(u)∧S(v)∧(u[2]=v[1]∨u[3]=v[1])∧t[1]=u[1]∧t[2]=v[2])} (3)域表达式:{xv|(y)(z)(u)(R(xyz)∧S(uv)∧(y=u∨z=u))}4.10 假设R和S都是二元关系，试把元组表达式{t|R(t)∧(u)(S(u)∧u[1]≠t[2])}转换成等价的： (1)汉语查询句子；(2)域表达式：(3)关系代数表达式。
(1)汉语表达式：选择R关系中元组第2分量值不等于S关系中某元组第1分量值的元组。
(2)域表达式:{xy|(u) (v)(R(xy)∧S(uv)∧(u≠y))}(3)关系代数表达式：π1,2(σ2≠3(R×S))4.11 试把域表达式{ab|R(ab)∧R(ba)}转换成等价的：(1)汉语查询句子；(2)关系代数表达式；(3)元组表达式。
(1)汉语查询句子：选择R中元组第1分量值与第2分量值互换后仍存在于R 中的元组。
(2)关系代数表达式：π1，2(σ1=4∧2=3(R×R))；(3)元组表达式：{t|(u)(R(t)∧R(u)∧t[1]=u[2]∧t[2]=u[1])}4.12 设有两个关系R(A，B，C)和S(D，E，F)，试把下列关系代数表达式转换成等价的元组表达式：(1)πA (R)；(2)σB='17'(R)；(3)R×S；(4)πA,F(σC=D(R×S))(1){t|(u)(R(u)∧t[1]=u[1])}(2){t|R(t)∧t[2]='17')}(3){t|(u)(v)(R(u)∧S(v)∧t[1]=u[1]∧t[2]=u[2]∧t[3]=u[3]∧t[4]=v[1]∧t[5]=v[ 2]∧t[6]=v[3])}(4){t|(u)(v)((R(u)∧S(v)∧u[3]=v[1]∧t[1]=u[1]∧t[2]=v[3])}4.13 设有三个关系：S(S#,SNAME,AGE,SEX)SC(S#,C#,GRADE)C(C#,CNAME,TEACHER)试用关系代数表达式表示下列查询语句。
(见下一题）4.14 试用元组表达式表示上题中各个查询语句。
(1)检索LIU老师所授课程的课程号、课程名。
πC#,CNAME(σTEACHER='LIU'(C)){t|(u)(C(u)∧C[3]='LIU'∧t[1]=u[1]∧t[2]=u[2])}(2)检索年龄大于23岁的男学生的学号与姓名。
πS#,SNAME(σAGE＞'23'∧SEX='男'(S)){t|(u)(S(u)∧u[3]＞'23'∧u[4]='男'∧t[1]=u[1]∧t[2]=u[2])}(3)检索学号为S3学生所学课程的课程名与任课教师名。
πCNAME,TEACHER(σS#='S3'(SC C)){t|(u)(v)(SC(u)∧C(v)∧u[1]='S3'∧v[1]=u[2]∧t[1]=v[2]∧t[2]=v[3])}(4)检索至少选修LIU老师所授课程中一门课程的女学生的姓名。
πSNAME(σSEX='女'∧TEACHER='LIU'(S SC C)){t|(u)(v)(w)(S(u)∧SC(v)∧C(w)∧u[4]='女'∧v[1]=u[1]∧v[2]=w[1]∧w[3]='LIU'∧t[1]=u[2])}(5)检索WANG同学不学的课程号。
πC#(C)-πC#(σSNAME='WANG'(S SC))或者，πC#(SC)-πC#(σSNAME='WANG'(S SC)) (全部课程号减去WANG同学所学的课程号){t|(u)(v)(C(u)∧SC(v)∧(u[1]=v[2]=>(w)(s(w)∧w[1]=v[1]∧W[2]≠'wang'))∧t[1]=u[1])}(从C中选择满足条件的元组：SC中的所有元组,如果学号与C中所选元组相同的话，其在S 中对应的姓名肯定不是'wang'。
)Notice:"p1=>p2"的含义是：如果p1为真，则p2为真。
(6)检索至少选修两门课程的学生学号。
πS#(σ1=4∧2≠5(SC×SC))SC自乘之后，再选择（同一个学号中两个课程号不同的元组)，投影。
{t|(u)(v)(SC(u)∧SC(v)∧u[1]=v[1]∧u[2]≠v[2])∧t[1]=u[1]}(7)检索全部学生都选修的课程的课程号与课程名。
πC#,CNAME(C(πS#,C#(SC)÷πS#(S))) (涉及到全部值时，应用除法，“除数”是"全部"){t|(u)(v)(w)(S(u)∧SC(v)∧C(w)∧u[1]=v[1]∧v[2]=w[1]∧t[1]=v[1]∧t[2]=V[2])}(8)检索选修课程包含LIU老师所授课程的学生学号。
πS#(σTEACHER='LIU'(SC C)){t|(u)(v)(SC(u)∧C(v)∧u[2]=v[1]∧v[3]='LIU'∧t[1]=u[1])}如果LIU老师有多门课程，则选修课程包含LIU老师所授全部课程的学生学号为：πS#,C#(SC)÷πC#(σTEACHER='LIU'(C))4.15 在教学数据库S、SC、C中，用户有一查询语句：检索女同学选修课程的课程名和任课教师名。
(1)试写出该查询的关系代数表达式；(2)试写出查询优化的关系代数表达式。
(1)πCNAME,TEACHER(σSEX='女'(S SC C))(2)优化为：πCNAME，TEACHER(CπC#(πS#,C#(SC)πS#(σSEX='女'(S))))(基本思路：尽量提前做选择操作；在每个操作后，应做个投影操作，去掉不用的属性值。