数据库系统原理课后答案 第四章
数据库系统基础教程课后答案第四章
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。
数据库原理 关系运算 习题答案
数据库系统原理第四章关系运算课后习题答案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)非过程性语言：编程时只须指出需要什么信息，不必给出具体的操作步骤。
(完整word版)数据库原理第4版_习题参考答案(陈志泊)
习题参考答案第1章习题参考答案一、选择题1. C2. B3. D4. C5. D6. B7. A8. B9. D 10. B11. C 12. D 13. D 14. D 15. B16. C 17. D 18. A 19. D 20. A21. D 22. D 23. C 24. A 25. C二、填空题1. 数据库系统阶段2. 关系3. 物理独立性4. 操作系统5. 数据库管理系统（DBMS）6. 一对多7. 独立性8. 完整性控制9. 逻辑独立性10. 关系模型11. 概念结构（逻辑）12. 树有向图二维表嵌套和递归13. 宿主语言（或主语言）14. 数据字典15. 单用户结构主从式结构分布式结构客户/服务器结构浏览器/服务器结构16. 现实世界信息世界计算机世界第2章习题参考答案一、选择题1. A2. C3. C4. B5. B6. C7. B8. D9. C 10. A11. B 12. A 13. A 14. D 15. D 16. B 17. C二、填空题1. 选择（选取）2. 交3. 相容（或是同类关系）4. 并差笛卡尔积选择投影5. 并差交笛卡尔积6. 选择投影连接7. σf(R)8. 关系代数关系演算9. 属性10. 同质11. 参照完整性12. 系编号，系名称，电话办公地点13. 元组关系域关系14. 主键外部关系键15. R和S没有公共的属性16. 关系第3章习题参考答案一、选择题1. B2. A3. C4. B5. C6. C7. B 8. D 9. A 10. D 11. C 12. D二、填空题1.结构化查询语言（Structured Query Language）2.数据查询、数据定义、数据操纵、数据控制3.外模式、模式、内模式4.数据库、事务日志5.NULL/NOT NULL、UNIQUE约束、PRIMARY KEY约束、FOREIGN KEY约束、CHECK约束6.聚集索引、非聚集索引7.连接字段8.行数9.定义10.系统权限、对象权限11.基本表、视图12．（1）INSERT INTO S VALUES('990010','李国栋','男',19)（2）INSERT INTO S(No,Name) VALUES('990011', '王大友')（3）UPDATE S SET Name='陈平' WHERE No='990009'（4）DELETE FROM S WHERE No='990008'（5）DELETE FROM S WHERE Name LIKE '陈%'13．CHAR(8) NOT NULL14．o=o15．ALTER TABLE StudentADDSGrade CHAR(10)第4章习题参考答案一、选择题1. B2. B3. D4. B5. C6. D7. B8. D9. D 10. D11. A 12.C 13.D 14.B 15.B二、填空题1. 超键（或超码）2. 正确完备3. 属性集X的闭包X +函数依赖集F的闭包F +4. 平凡的函数依赖自反性5. {AD→C} φ6. 2NF 3NF BCNF7. 无损连接保持函数依赖8. AB BC BD9. B→φB→B B→C B→BC10. B→C A→D D→C11. AB1NF12. AD2NF13. BCNF14. 包含15. 函数依赖16. BCNF第5章习题参考答案一、选择题1. B2. B3. C4. A5. C6. D7. A8. C9. D 10. D11. B 12. B 13. A 14. D 15. A二、填空题1.安全性控制、完整性控制、并发性控制、数据库恢复2.数据对象、操作类型3.授权粒度、授权表中允许的登记项的范围4.原始数据（或明文）、不可直接识别的格式（或密文）、密文5.事务、原子性、一致性、隔离性、持久性6.丢失更新、污读、不可重读7.封锁、排它型封锁、共享封锁8.利用数据的冗余9.登记日志文件、数据转储10.事务故障、系统故障、介质故障11.海量转储和增量转储12.静态转储和动态转储13.完整性14.登录账号、用户账号15.public16.服务器、数据库第6章习题参考答案一、选择题1. B2. C3. C4. A5. C6. B7. C8. B9. D 10. C11. D 12. B 13. B 14. D 15. B16. B 17. A 18. C二、填空题1.数据库的结构设计、数据库的行为设计2.新奥尔良法3.分析和设计阶段、实现和运行阶段4.需求分析5.概念结构设计6.自顶向下、自底向上7.属性冲突、命名冲突、结构冲突8.逻辑结构设计9.确定物理结构、评价物理结构10.数据库加载11.运行和维护12.物理。
数据库原理习题与答案 第4章关系数据库方法
第四章．关系数据库方法习题：一．填空题1．关系操作的特点是。
2．一个关系模式的定义格式为。
3．在一个实体的表示信息中，称为关键字。
4．关系代数运算中，传统的集合运算有、、和。
5．关系代数使用对关系的运算来表达查询的，而关系演算是用查询的，它又分为演算和演算两种。
二．选择题1．关系数据库管理系统应能实现的专门关系运算包括。
A.排序、索引、统计B.选择、投影、连接C.关联、更新、排序D.显示、打印、制表2．通常情况下，下面的关系中不可以作为关系数据库的关系是。
A.R1（学生号，学生名，性别）B.R2（学生号，学生名，班级号）C.R3（学生号，学生名，宿舍号）D.R4（学生号，学生名，简历）3．自然连接是构成新关系的有效方法，一般情况下，当对关系R和S使用自然连接时，要求R和S含有一个或多个共有的。
A.元组B.行C.记录D.属性4．设有如图所示的关系R，经操作ΠA，B（σB=b(R)）的运算结果是______。
关系R：三．简答题1． 试述关系模型的三个组成部分。
2． 试述关系数据语言的特点和分类。
3． 试述关系模型的完整性规则。
在参照完整性中，为什么外部码属性的值也可以为空？什么情况下才可以为空？四．设有如图所示的三个关系S 、C 和SC ，将下列关系代数表达式用汉语表示出来，并求其结果。
A BCD1.∏学号，姓名，课程号(σ籍贯=‘上海’(S∞SC))2.∏姓名，课程号，成绩(S∞SC∞σ课程名=‘操作系统’（C）)3.∏姓名，年龄(S∞(∏学号，课程号(SC)÷∏课程号(C)))参考答案：一．填空题1．集合2．关系名（属性名1，属性名2，……属性名n）3．能唯一标识实体的属性或属性组4．笛卡尔积，并，交，差5．谓词表达，元组关系，域关系二．选择题1． B2． D3． D4． C三．简答题1．关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。
2．关系数据语言可以分为三类：（1）关系代数语言（2）关系演算语言，分为关系演算语言和域关系演算语言（3）具有关系代数和关系演算双重特点的语言，例如SQL这些关系数据语言的共同特点是：具有完备的表达能力，是非过程化的集合操作语言，功能强，能够嵌入高级语言中使用。
(完整版)数据库原理课后题答案
第1章1.试恳数据、数据库、数据库系统、数据库管理系统的概念。
答:（1）数据：描述事物的符号记录成为数据。
数据的种类有数字、文字、图形、图像、声音、正文等。
数据与其语义是不可分的。
（2）数据库：数据库是长期储存在计算机内的、有组织的、可共享的数据集合。
数据库中的数据按照一定的数据模型组织。
描述和储存，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
（3）数据库系统：数据库系统是指在计算机系统中引入数据库后的系统构成，一般由数据库、数据库管理系统（及其开发人具）、应用系统、数据库管理员构成。
（4）数据库管理系统：数据库管理系统是位于用户与操作系统之间的一层数据管理软件，用于科学地组织和存储数据、高效地获取和维护数据。
DBMS的主要功能包括数据定义功能、数据操作功能、数据库的建立和维护功能。
6. 试述数据库系统三级模式结构，这种结构的优点是什么？答：数据库系统的三级模式机构由外模式、模式和内模式组成。
外模式，亦称子模式或用户模式，是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。
模式亦称逻辑模式，是数据库中全体数据呃逻辑结构和特征的描述，是所有用户的公共数据视图。
模式描述的是数据的全局逻辑结构。
外模式涉及的是数据的内部逻辑结构，通常是模式的子集。
内模式，亦称存储模式，是数据在数据库内部的表示，即对数据的物理结构和存储方式的描述。
数据库系统的三级模式是对数据的三个抽象级别，它对数据的具体组织留给DBMS管理，使用户能逻辑抽象地处理数据，而不必关心数据在计算机中的表示和存储。
为了能够在内部实现这三个抽象层次的联系和转换，数据库系统在这三级模式之间提供了两层映像：外模式/模式映像和模式/内模式映像。
正是这两层映像保证了数据库系统中的数据能够具有较高的逻辑独立性和物理独立性。
7. 定义并解释下列术语。
数据库原理及应用课后答案第4章关系数据库设计理论
第4章关系数据库设计理论、选择题1、C2、B3、C4、C5、A9、D 10、B二、填空题1、数据依赖主要包括—函数_依赖、—多值—依赖和连接依赖。
2、一个不好的关系模式会存在_插入异常_、_删除异常_和—修改复杂_等弊端。
3、设X T Y为R上的一个函数依赖，若_对任意X的真子集X '均无XY存在__, 则称Y完全函数依赖于X.4、设关系模式R上有函数依赖X T Y和Y T Z成立若_Y不包含于X_且_Y T X不成立_，则称Z传递函数依赖于X。
5、设关系模式R的属性集为U, K为U的子集，若_K T U为完全函数依赖_，则称K 为R的候选键。
6、包含R中全部属性的候选键称_主属性_。
不在任何候选键中的属性称—非主属性7、Armstrong公理系统是—有效__的和—完备__的.8、第三范式是基于_函数_依赖的范式，第四范式是基于_多值_依赖的范式。
9、关系数据库中的关系模式至少应属于_第一_范式。
10、规范化过程，是通过投影分解，把_一个范式级别较低的_的关系模式“分解”为_若干个范式级别较高__的关系模式。
三、简答题1、解释下列术语的含义：函数依赖、平凡函数依赖、非平凡函数依赖、部分函数依赖、 完全函数依赖、传递函数依赖、范式、无损连接性、依赖保持性。
解：函数依赖：设关系模式R ( U ，F), U 是属性全集，F 是U 上的函数依赖集,X 和丫是U 的子集，如果对于R(U)的任意一个可能的关系 r ，对于X 的每一个具体值，Y 都有唯一的具 体的值与之对应，则称X 函数决定Y,或Y 函数依赖于X ，记X T Y 。
我们称X 为决定因素， Y 为依赖因素。
当Y 不函数依赖于 X 时，记作:©Y 。
当X T Y 且Y T X 时，则记作：X Y 。
平凡函数依赖：当属性集Y 是属性集X 的子集时，则必然存在着函数依赖X T Y ，这种类型的函数依赖称为平凡的函数依赖。
非平凡函数依赖： 如果Y 不是X 子集，则称X T Y 为非平凡的函数依赖。
数据库管理系统原理 第四章测验 测验答案 慕课答案 UOOC优课 课后练习 深圳大学
数据库管理系统原理第四章测验一、单选题(共40.00分)1. 在数据加密技术中，原始数据通过某种加密算法变换为不可直接识别的格式称为，请选择最恰当选项（）。
A. 密钥B. 密文C. 档案D. 密码正确答案：B2. GRANT SELECT ON TABLE SC TO PUBLIC;A. 把对表SC的查询权限授予名字为PUBLIC的用户B. 把对表SC的选择权限授予名字为PUBLIC的用户C. 把对表SC的查询权限授予所有用户D. 把对表SC的选择权限授予所有用户正确答案：C3. 数据库角色实际上是一组与数据库操作相关的各种（），请选择最恰当选项。
A. 事务B. 人员C. 数据D. 权限正确答案：D4. 哪个安全标准于1999年被ISO采用为国际标准并于 2001年被我国采用为国家标准（）。
A. TCSECV2.1版B. ITSECV2.1版C. CC V2.1版D. CTCPECV2.1版正确答案：C二、多选题(共33.00分)1. 在对用户授予列INSERT权限时，除了授权的列，其他列的值可能的取值为（）请选择最恰当的两个选项。
A. 随机值B. 默认值C. 主属性值D. 空值正确答案：C D2. 自主存取控制（Discretionary Access Control ，简称DAC），关于自主存取控制描述正确的有（）。
A. 用户对不同的数据对象有不同的存取权限B. 不同的用户对同一对象也有不同的权限C. 用户还可将其拥有的存取权限转授给其他用户D. 用户无权将其拥有的存取权限转授给其他用户正确答案：A B C答案解析：用户可将其拥有的存取权限转授给其他用户3. GRANT语句的中的参数WITH GRANT OPTION 的作用是（）。
A. 带有这个参数，表示用户“可以再授予”这个权限给其它用户。
B. 带有这个参数，表示用户执行GRANT语句中指定操作时，系统首先检查用户是否具有这个权限。
C. 没有指定这个参数表示用户“不可以再授予”这个权限给其它用户。
数据库系统原理知到章节答案智慧树2023年郑州大学
数据库系统原理知到章节测试答案智慧树2023年最新郑州大学绪论单元测试1.因为提出关系模型而获得图灵奖的是参考答案:E.F.Codd第一章测试1.在数据模型中，对数据静态特性描述的是（）参考答案:数据结构2.目前最流行的数据模型是（）参考答案:关系模型3.下面定义数据库中各种数据对象实例上允许的操作和操作规则的是（）参考答案:数据操作4.下面可以保证数据逻辑独立性的是（）参考答案:外模式-模式映像5.数据库管理系统的简称是（）参考答案:DBMS6.关系的每个属性必须取原子值（）参考答案:对7.数据模型的组成要素包括（）参考答案:数据结构 ;数据操纵 ;数据完整性约束第二章测试1.客观存在并可以相互区分的任何事物被称为（）参考答案:实体2.一个属性能被划分为更小部分的属性，该属性属于（）参考答案:复合属性3.实体集E1中的每个实体都可以与E2中的任意多个实体相关联，而E2中的每个实体最多与E1中的一个实体相关联，则E1和E2之间的联系属于（）参考答案:一对多联系4.实体的各种码中，包含无关紧要属性的码有（）参考答案:超码5.在实体-联系图中，联系集可以用（）参考答案:菱形框6.一个实体集的任何属性都不足以形成该实体集的码，该实体集被称为（）参考答案:弱实体集7.下面处理弱实体集正确的方法是（）参考答案:把它作为多值复合属性处理8.一个实体集的候选码只能有一个（）参考答案:对9.联系的类型有（）参考答案:多对多;一对一 ;多对一 ;一对多10.A实体和B实体是一对一的联系，转换成关系模式后，码可以是（）参考答案:B实体的码 ;A实体的码第三章测试1.下面对外码取值限制的是（）参考答案:参照完整性2.下面可以取空值的是（）参考答案:外码3.E-R图向关系模式转换时实体被转换为（）参考答案:关系4.E-R图向关系模式转换时对多值属性如何处理（）参考答案:为其创建一个新的关系模式5.如果联系是一对多的，转换成关系模型后码为（）参考答案:多端实体的码6.关系代数的五种基本运算是（）参考答案:并、差、投影、选择、笛卡儿积7.必须有同名属性才能进行的运算是（）参考答案:自然连接8.实体完整性是对外码取值的限制（）参考答案:错9.选择运算是传统的集合运算符（）参考答案:错10.下面属于参照完整性规则要求的是（）参考答案:外码取它所参照的表在主码上的某个取值;外码可能取空值第四章测试1.修改基本表结构的SQL语句是（）参考答案:ALTER TABLE2.定义外码的SQL语句是（）参考答案:FOREIGN KEY3.用于删除数据库对象的SQL语句是（）参考答案:DROP4.定义聚集索引使用下面哪个关键字（）参考答案:CLUSTER5.表达查询条件的子句是（）参考答案:WHERE子句6.下面哪个聚集函数是用来计数的（）参考答案:COUNT()7.当查询的结果为多个元组时，必须使用什么来保存查询结果（）参考答案:游标8.DBMS执行CREATE VIEW语句的时执行其中的SELECT语句，并保存结果。
数据库系统原理教程课后习题答案
第1章绪论1 ．试述数据、数据库、数据库系统、数据库管理系统的概念。
答：( l ）数据（Data ) ：描述事物的符号记录称为数据。
数据的种类有数字、文字、图形、图像、声音、正文等。
数据与其语义是不可分的。
解析在现代计算机系统中数据的概念是广义的。
早期的计算机系统主要用于科学计算，处理的数据是整数、实数、浮点数等传统数学中的数据。
现代计算机能存储和处理的对象十分广泛，表示这些对象的数据也越来越复杂。
数据与其语义是不可分的。
500 这个数字可以表示一件物品的价格是500 元，也可以表示一个学术会议参加的人数有500 人，还可以表示一袋奶粉重500 克。
( 2 ）数据库（DataBase ，简称DB ) ：数据库是长期储存在计算机内的、有组织的、可共享的数据集合。
数据库中的数据按一定的数据模型组织、描述和储存，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
( 3 ）数据库系统（DataBas 。
Sytem ，简称DBS ) ：数据库系统是指在计算机系统中引入数据库后的系统构成，一般由数据库、数据库管理系统（及其开发工具）、应用系统、数据库管理员构成。
解析数据库系统和数据库是两个概念。
数据库系统是一个人一机系统，数据库是数据库系统的一个组成部分。
但是在日常工作中人们常常把数据库系统简称为数据库。
希望读者能够从人们讲话或文章的上下文中区分“数据库系统”和“数据库”，不要引起混淆。
( 4 ）数据库管理系统（DataBase Management sytem ，简称DBMs ) ：数据库管理系统是位于用户与操作系统之间的一层数据管理软件，用于科学地组织和存储数据、高效地获取和维护数据。
DBMS 的主要功能包括数据定义功能、数据操纵功能、数据库的运行管理功能、数据库的建立和维护功能。
解析DBMS 是一个大型的复杂的软件系统，是计算机中的基础软件。
目前，专门研制DBMS 的厂商及其研制的DBMS 产品很多。
数据库系统概论第5版课后答案第4章 数据库安全性
第4章数据库安全性1.什么是数据库的安全性答：数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏。
2.数据库安全性和计算机系统的安全性有什么关系答：安全性问题不是数据库系统所独有的，所有计算机系统都有这个问题。
只是在数据库系统中大量数据集中存放，而且为许多最终用户直接共享，从而使安全性问题更为突出。
系统安全保护措施是否有效是数据库系统的主要指标之一。
数据库的安全性和计算机系统的安全性，包括操作系统、网络系统的安全性是紧密联系、相互支持的。
CC评估保证级（EAL）的划分4.试述实现数据库安全性控制的常用方法和技术。
答：实现数据库安全性控制的常用方法和技术有：1)用户标识和鉴别：该方法由系统提供一定的方式让用户标识自己的名字或身份。
每次用户要求进入系统时，由系统进行核对，通过鉴定后才提供系统的使用权。
2)存取控制：通过用户权限定义和合法权检查确保只有合法权限的用户访问数据库，所有未被授权的人员无法存取数据。
例如CZ 级中的自主存取控制( DAC ) , Bl 级中的强制存取控制（MAC ）。
3)视图机制：为不同的用户定义视图，通过视图机制把要保密的数据对无权存取的用户隐藏起来，从而自动地对数据提供一定程度的安全保护。
4)审计：建立审计日志，把用户对数据库的所有操作自动记录下来放入审计日志中，DBA 可以利用审计跟踪的信息，重现导致数据库现有状况的一系列事件，找出非法存取数据的人、时间和内容等。
5)数据加密：对存储和传输的数据进行加密处理，从而使得不知道解密算法的人无法获知数据的内容。
5.什么是数据库中的自主存取控制方法和强制存取控制方法答：自主存取控制方法：定义各个用户对不同数据对象的存取权限。
当用户对数据库访问时首先检查用户的存取权限。
防止不合法用户对数据库的存取。
强制存取控制方法：每一个数据对象被（强制地）标以一定的密级，每一个用户也被（强制地）授予某一个级别的许可证。
系统规定只有具有某一许可证级别的用户才能存取某一个密级的数据对象。
数据库系统原理04735课后习题答案
数据库系统原理04735课后习题答第一章.数据库系统基本概念1.1.名词解释（省略）1.2.人工管理阶段的数据管理有哪些特点?1)数据不保存在计算机里2)没有专门的软件进行对数据库管理3)只有程序概念，没有文件概念4)数据面向程序1.3.文件系统阶段的数据管理有哪些特点？1)数据以文件形式长期存储在外部存储器的磁盘上2)数据的逻辑结构和物理结构有了区别，但比较简单3)文件组织多样化，有了索引文件、链接文件和直接存取文件等4)数据不再属于某个特定程序，可重复使用，即数据面向应用5)对数据的操作以记录为单位1.4.文件系统阶段的数据管理有哪些缺陷？请举例说明？1)数据冗余、数据不一致、数据联系弱2)比如建立了职工档案、职工工资和职工保健三个文件，职工的电话在三个文件中重复出现，即数据冗余。
1.5.数据管理的数据库阶段产生的标志是哪三件事情？1)1968年IBM公司推出层次模型IMS系统2)1969年美国COＤＡＳＹＬ组织发布了ＤＢＴＧ报告3)1970年IBM公司的E .F.Codd连续发表论文，提出关系模型1.6.数据库阶段的数据管理有哪些特色？1)采用了数据模型表示复杂的数据结构2)有较高的数据独立性3)数据库系统提供了方便的用户接口4)数据库系统提供了四个方面的数据控制功能：数据库的恢复、数据的并发控制、数据的完整性、数据完全性。
5)增加了系统的灵活性：对数据的操作不一定以记录为单位，可以以数据项为单位。
1.7.高级数据库阶段有哪些技术？面向对象的概念建模、开放数据库互联技术1.8.逻辑记录与物理记录，逻辑文件与物理文件有哪些联系和区别？数据描述有两种形式：物理数据描述和逻辑物理描述。
物理数据描述是指数据在存储设备上的描述，物理数据是存储在物理设备上的数据，物理记录和物理文件都是用来描述存储数据的细节。
逻辑数据描述是用户或程序员以操作的数据形式的描述，逻辑记录和逻辑文件都是用户观点的数据描述。
1.9.数据抽象过程有哪些步骤？1)根据用户的需求，设计数据的概念模型。
04735数据库系统原理(2022版)课后习题参考答案
04735数据库系统原理（2022版）课后习题参考答案第一章数据库系统概述选择题B、B、A简答题1.请简述数据,数据库,数据库管理系统,数据库系统的概念。
P27数据是描述事物的记录符号，是指用物理符号记录下来的，可以鉴别的信息。
数据库即存储数据的仓库，严格意义上是指长期存储在计算机中的有组织的、可共享的数据集合。
数据库管理系统是专门用于建立和管理数据库的一套软件，介于应用程序和操作系统之间。
数据库系统是指在计算机中引入数据库技术之后的系统，包括数据库、数据库管理系统及相关实用工具、应用程序、数据库管理员和用户。
2.请简述早数据库管理技术中，与人工管理、文件系统相比，数据库系统的优点。
数据共享性高数据冗余小易于保证数据一致性数据独立性高可以实施统一管理与控制减少了应用程序开发与维护的工作量3.请简述数据库系统的三级模式和两层映像的含义。
P31答：数据库的三级模式是指数据库系统是由模式、外模式和内模式三级工程的，对应了数据的三级抽象。
第二章关系数据库选择题C、C、D简答题1.请简述关系数据库的基本特征。
P48答：关系数据库的基本特征是使用关系数据模型组织数据。
2.请简述什么是参照完整性约束。
P55答：参照完整性约束是指：若属性或属性组F是基本关系R的外码，与基本关系S的主码K相对应，则对于R中每个元组在F上的取值只允许有两种可能，要么是空值，要么与S中某个元组的主码值对应。
3.请简述关系规范化过程。
答：对于存在数据冗余、插入异常、删除异常问题的关系模式，应采取将一个关系模式分解为多个关系模式的方法进行处理。
一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式，这就是所谓的规范化过程。
第三章数据库设计选择题B、C、C简答题1.请简述数据库设计的基本步骤。
P66需求分析设计；概念结构设计；逻辑结构设计；物理结构设计；数据库设计；数据库的运行和维护。
1）一个实体型转换为一个关系模式。
数据库系统原理与设计(万常选版)第四章练习题和详细答案
数据库系统原理与设计（万常选版）第四章练习题和详细答案第四章关系系统及其优化一、选择题1.概念模型是现实世界的第一层抽象，这一类最著名的模型是（）。
A.层次模型B. 关系模型C. 网状模型D. 实体-关系模型2.区分不同实体的依据是（）。
A. 名称B. 属性C. 对象D. 概念3.关系数据模型是目前最重要的一种数据模型，它的三个要素分别为（）。
A.实体完整、参照完整、用户自定义完整B.数据结构、关系操作、完整性约束C.数据增加、数据修改、数据查询D.外模式、模式、内模式4.在（）中一个结点可以有多个双亲，节点之间可以有多种联系。
A.网状模型B. 关系模型C.层次模型D. 以上都有5.（）的存取路径对用户透明，从而具有更高的数据独立性、更好的安全保密性，也简化了程序员的工作和数据库开发建立的工作。
A.网状模型B. 关系模型D.层次模型 D. 以上都有6.在关系数据库中，要求基本关系中所有的主属性上不能有空值，其遵守的约束规则是（）。
A.数据依赖完整性规则B. 用户定义完整性规则C.实体完整性规则D. 域完整性规则选择题答案：二、简答题1.试述关系模型的三个组成部分。
答：关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。
2.试述关系数据语言的特点和分类。
答：关系数据语言可以分为三类：关系代数语言例如ISBL关系演算语言（元组关系演算语言例如APLHA，QUEL 和域关系演算语言例如QBE）具有关系代数和关系演算双重特点的语言例如SQL这些关系数据语言的共同特点是，具有完备的表达能力，是非过程化的集合操作语言，功能强，能够嵌入高级语言中使用。
3. 定义并理解下列术语，说明它们之间的联系与区别:（1）域，关系，元组，属性答：域：域是一组具有相同数据类型的值的集合。
关系：在域D1，D2，…，Dn上笛卡尔积D1×D2×…×Dn的子集称为关系，表示为R（D1，D2，…，Dn）元组：关系中的每个元素是关系中的元组。
- 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))))(基本思路：尽量提前做选择操作；在每个操作后，应做个投影操作，去掉不用的属性值。