数据库基础与应用第二版课后答案 王珊李盛恩编著

第2章习题参考答案第6小题三简答题（1）查询T1老师所授课程的课程号和课程名。

（2）查询年龄大于18岁男同学的学号、姓名、系别。

（3）查询“李力”老师所授课程的课程号、课程名和课时。

（4）查询学号为S1的同学所选修课程的课程号、课程名和成绩。

（5）查询“钱尔”同学所选修课程的课程号、课程名和成绩。

（6）查询至少选修“刘伟”老师所授全部课程的学生姓名。

（7）查询“李思”同学未选修的课程的课程号和课程名。

（8）查询全部学生都选修了的课程的课程号和课程名。

（9）查询选修了课程号为C1和C2的学生的学号和姓名。

（10）查询选修全部课程的学生的学号和姓名。

（11）查询选修课程包含“程军”老师所授课程之一的学生学号。

（12）查询选修课程包含学号S2的学生所修课程的学生学号。

第3章习题参考答案一、选择题1. B2. A3. C4. B5. C6. C7. B8. D9. A 10. 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 StudentADD SGrade CHAR(10)三、设计题1.(1) 查找在“高等教育出版社”出版，书名为“操作系统”的图书的作者名。

数据库原理及应用第二版答案数据库原理及应用是计算机专业的一门重要课程，它涉及到数据库的基本原理和应用技术，对于理解数据库系统的工作原理和实际应用具有重要意义。

本文将对数据库原理及应用第二版的相关问题进行解答，希望能够帮助读者更好地理解和掌握这门课程的知识。

1. 什么是数据库系统？数据库系统是由数据库和数据库管理系统（DBMS）组成的集合体。

数据库是按照数据结构来组织、存储和管理数据的仓库，而DBMS是用来管理数据库的软件系统，它可以提供数据的存储、检索、更新和管理等功能。

2. 数据库系统的特点有哪些？数据库系统具有数据结构化、数据共享、数据独立、数据安全、数据完整性、数据并发控制、故障恢复和数据备份等特点。

这些特点使得数据库系统能够更好地满足用户的需求，并且保证数据的安全性和稳定性。

3. 数据库系统的组成部分有哪些？数据库系统主要由数据库、数据库管理系统、应用程序和数据库管理员组成。

数据库是数据的集合，DBMS是管理和操作数据库的软件，应用程序是通过DBMS来访问和操作数据库的程序，而数据库管理员则负责数据库系统的维护和管理工作。

4. 数据库系统的三级模式结构是什么？数据库系统的三级模式结构包括外部模式、概念模式和内部模式。

外部模式是用户能够看到和使用的数据的逻辑结构，概念模式是整个数据库的逻辑结构，内部模式是数据库在存储介质上的物理结构。

5. 数据库系统的数据模型有哪些？数据库系统的数据模型主要包括层次模型、网状模型、关系模型和面向对象模型等。

其中，关系模型是目前应用最广泛的数据模型，它使用表格来表示数据和数据之间的关系。

6. 数据库系统的完整性约束有哪些？数据库系统的完整性约束包括实体完整性、参照完整性和用户定义的完整性约束。

实体完整性要求每个实体必须有一个主键，参照完整性要求外键的取值必须在被参照的主键中存在，用户定义的完整性约束是由用户自定义的完整性规则。

7. 数据库系统的事务是什么？数据库系统的事务是指作为单个逻辑工作单元执行的一系列操作，这些操作要么全部执行成功，要么全部执行失败。

Database Systems: The Complete BookSolutions for Chapter 2Solutions for Section 2.1Exercise 2.1.1The E/R Diagram.Exercise 2.1.8(a)The E/R DiagramKobvxybzSolutions for Section 2.2Exercise 2.2.1The Addresses entity set is nothing but a single address, so we would prefer to make address an attribute of Customers. Were the bank to record several addresses for a customer, then it might make sense to have an Addresses entity set and make Lives-at a many-many relationship.The Acct-Sets entity set is useless. Each customer has a unique account set containing his or her accounts. However, relating customers directly to their accounts in a many-many relationship conveys the same information and eliminates the account-set concept altogether.Solutions for Section 2.3Exercise 2.3.1(a)Keys ssNo and number are appropriate for Customers and Accounts, respectively. Also, we think it does not make sense for an account to be related to zero customers, so we should round the edge connecting Owns to Customers. It does not seem inappropriate to have a customer with 0 accounts;they might be a borrower, for example, so we put no constraint on the connection from Owns to Accounts. Here is the The E/R Diagram，showing underlined keys andthe numerocity constraint.Exercise 2.3.2(b)If R is many-one from E1 to E2, then two tuples (e1,e2) and (f1,f2) of the relationship set for R must be the same if they agree on the key attributes for E1. To see why, surely e1 and f1 are the same. Because R is many-one from E1 to E2, e2 and f2 must also be the same. Thus, the pairs are the same.Solutions for Section 2.4Exercise 2.4.1Here is the The E/R Diagram.We have omitted attributes other than our choice for the key attributes of Students and Courses. Also omitted are names for the relationships. Attribute grade is not part of the key for Enrollments. The key for Enrollements is studID from Students and dept and number from Courses.Exercise 2.4.4bHere is the The E/R Diagram Again, we have omitted relationship names and attributes other than our choice for the key attributes. The key for Leagues is its own name; this entity set is not weak. The key for Teams is its own name plus the name of the league of which the team is a part, e.g., (Rangers, MLB) or (Rangers, NHL). The key for Players consists of the player's number and the key for the team on which he or she plays. Since the latter key is itself a pair consisting of team and league names, the key for players is the triple (number, teamName, leagueName). e.g., JeffGarcia is (5, 49ers, NFL).Database Systems: The Complete BookSolutions for Chapter 3Solutions for Section 3.1Exercise 3.1.2(a)We can order the three tuples in any of 3! = 6 ways. Also, the columns can be ordered in any of 3! = 6 ways. Thus, the number of presentations is 6*6 = 36.Solutions for Section 3.2Exercise 3.2.1Customers(ssNo, name, address, phone)Flights(number, day, aircraft)Bookings(ssNo, number, day, row, seat)Being a weak entity set, Bookings' relation has the keys for Customers and Flights and Bookings' own attributes.Notice that the relations obtained from the toCust and toFlt relationships are unnecessary. They are:toCust(ssNo, ssNo1, number, day)toFlt(ssNo, number, day, number1, day1)That is, for toCust, the key of Customers is paired with the key for Bookings. Since both include ssNo, this attribute is repeated with two different names, ssNo and ssNo1. A similar situation exists for toFlt.Exercise 3.2.3Ships(name, yearLaunched)SisterOf(name, sisterName)Solutions for Section 3.3Exercise 3.3.1Since Courses is weak, its key is number and the name of its department. We do not have arelation for GivenBy. In part (a), there is a relation for Courses and a relation for LabCourses that has only the key and the computer-allocation attribute. It looks like:Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, allocation)For part (b), LabCourses gets all the attributes of Courses, as:Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, room, allocation)And for (c), Courses and LabCourses are combined, as:Depts(name, chair)Courses(number, deptName, room, allocation)Exercise 3.3.4(a)There is one relation for each entity set, so the number of relations is e. The relation for the root entity set has a attributes, while the other relations, which must include the key attributes, have a+k attributes.Solutions for Section 3.4Exercise 3.4.2Surely ID is a key by itself. However, we think that the attributes x, y, and z together form another key. The reason is that at no time can two molecules occupy the same point.Exercise 3.4.4The key attributes are indicated by capitalization in the schema below:Customers(SSNO, name, address, phone)Flights(NUMBER, DAY, aircraft)Bookings(SSNO, NUMBER, DAY, row, seat)Exercise 3.4.6(a)The superkeys are any subset that contains A1. Thus, there are 2^{n-1} such subsets, since each of the n-1 attributes A2 through An may independently be chosen in or out.Solutions for Section 3.5Exercise 3.5.1(a)We could try inference rules to deduce new dependencies until we are satisfied we have them all.A more systematic way is to consider the closures of all 15 nonempty sets of attributes.For the single attributes we have A+ = A, B+ = B, C+ = ACD, and D+ = AD. Thus, the only new dependency we get with a single attribute on the left is C->A.Now consider pairs of attributes:AB+ = ABCD, so we get new dependency AB->D. AC+ = ACD, and AC->D is nontrivial. AD+ = AD, so nothing new. BC+ = ABCD, so we get BC->A, and BC->D. BD+ = ABCD, giving usBD->A and BD->C. CD+ = ACD, giving CD->A.For the triples of attributes, ACD+ = ACD, but the closures of the other sets are each ABCD. Thus, we get new dependencies ABC->D, ABD->C, and BCD->A.Since ABCD+ = ABCD, we get no new dependencies.The collection of 11 new dependencies mentioned above is: C->A, AB->D, AC->D, BC->A, BC->D, BD->A, BD->C, CD->A, ABC->D, ABD->C, and BCD->A.Exercise 3.5.1(b)From the analysis of closures above, we find that AB, BC, and BD are keys. All other sets either do not have ABCD as the closure or contain one of these three sets.Exercise 3.5.1(c)The superkeys are all those that contain one of those three keys. That is, a superkey that is not a key must contain B and more than one of A, C, and D. Thus, the (proper) superkeys are ABC, ABD, BCD, and ABCD.Exercise 3.5.3(a)We must compute the closure of A1A2...AnC. Since A1A2...An->B is a dependency, surely B is in this set, proving A1A2...AnC->B.Exercise 3.5.4(a)Consider the relationThis relation satisfies A->B but does not satisfy B->A.Exercise 3.5.8(a)If all sets of attributes are closed, then there cannot be any nontrivial functional dependenc ies. For suppose A1A2...An->B is a nontrivial dependency. Then A1A2...An+ contains B and thus A1A2...An is not closed.Exercise 3.5.10(a)We need to compute the closures of all subsets of {ABC}, although there is no need to think about the empty set or the set of all three attributes. Here are the calculations for the remaining six sets: A+ = AB+ = BC+ = ACEAB+ = ABCDEAC+ = ACEBC+ = ABCDEWe ignore D and E, so a basis for the resulting functional dependencies for ABC are: C->A and AB->C. Note that BC->A is true, but follows logically from C->A, and therefore may be omitted from our list.Solutions for Section 3.6Exercise 3.6.1(a)In the solution to Exercise 3.5.1 we found that there are 14 nontrivial dependencies, including the three given ones and 11 derived dependencies. These are: C->A, C->D, D->A, AB->D, AB-> C, AC->D, BC->A, BC->D, BD->A, BD->C, CD->A, ABC->D, ABD->C, and BCD->A.We also learned that the three keys were AB, BC, and BD. Thus, any dependency above that does not have one of these pairs on the left is a BCNF violation. These are: C->A, C->D, D->A, AC->D, and CD->A.One choice is to decompose using C->D. That gives us ABC and CD as decomposed relations. CD is surely in BCNF, since any two-attribute relation is. ABC is not in BCNF, since AB and BC are its only keys, but C->A is a dependency that holds in ABCD and therefore holds in ABC. We must further decompose ABC into AC and BC. Thus, the three relations of the decomposition are AC, BC, and CD.Since all attributes are in at least one key of ABCD, that relation is already in 3NF, and no decomposition is necessary.Exercise 3.6.1(b)(Revised 1/19/02) The only key is AB. Thus, B->C and B->D are both BCNF violations. The derived FD's BD->C and BC->D are also BCNF violations. However, any other nontrivial, derived FD will have A and B on the left, and therefore will contain a key.One possible BCNF decomposition is AB and BCD. It is obtained starting with any of the four violations mentioned above. AB is the only key for AB, and B is the only key for BCD.Since there is only one key for ABCD, the 3NF violations are the same, and so is the decomposition.Solutions for Section 3.7Exercise 3.7.1Since A->->B, and all the tuples have the same value for attribute A, we can pair the B-value from any tuple with the value of the remaining attribute C from any other tuple. Thus, we know that R must have at least the nine tuples of the form (a,b,c), where b is any of b1, b2, or b3, and c is any of c1, c2, or c3. That is, we can derive, using the definition of a multivalued dependency, that each of the tuples (a,b1,c2), (a,b1,c3), (a,b2,c1), (a,b2,c3), (a,b3,c1), and (a,b3,c2) are also in R.Exercise 3.7.2(a)First, people have unique Social Security numbers and unique birthdates. Thus, we expect the functional dependencies ssNo->name and ssNo->birthdate hold. The same applies to children, so we expect childSSNo->childname and childSSNo->childBirthdate. Finally, an automobile has a unique brand, so we expect autoSerialNo->autoMake.There are two multivalued dependencies that do not follow from these functional dependencies. First, the information about one child of a person is independent of other information about that person. That is, if a person with social security number s has a tuple with cn,cs,cb, then if there isany other tuple t for the same person, there will also be another tuple that agrees with t except that it has cn,cs,cb in its components for the child name, Social Security number, and birthdate. That is the multivalued dependencyssNo->->childSSNo childName childBirthdateSimilarly, an automobile serial number and make are independent of any of the other attributes, so we expect the multivalued dependencyssNo->->autoSerialNo autoMakeThe dependencies are summarized below:ssNo -> name birthdatechildSSNo -> childName childBirthdateautoSerialNo -> autoMakessNo ->-> childSSNo childName childBirthdatessNo ->-> autoSerialNo autoMakeExercise 3.7.2(b)We suggest the relation schemas{ssNo, name, birthdate}{ssNo, childSSNo}{childSSNo, childName childBirthdate}{ssNo, autoSerialNo}{autoSerialNo, autoMake}An initial decomposition based on the two multivalued dependencies would give us {ssNo, name, birthDate}{ssNo, childSSNo, childName, childBirthdate}{ssNo, autoSerialNo, autoMake}Functional dependencies force us to decompose the second and third of these.Exercise 3.7.3(a)Since there are no functional dependencies, the only key is all four attributes, ABCD. Thus, each of the nontrvial multivalued dependencies A->->B and A->->C violate 4NF. We must separate out the attributes of these dependencies, first decomposing into AB and ACD, and then decomposing the latter into AC and AD because A->->C is still a 4NF violation for ACD. The final set of relations are AB, AC, and AD.Exercise 3.7.7(a)Let W be the set of attributes not in X, Y, or Z. Consider two tuples xyzw and xy'z'w' in the relation R in question. Because X ->-> Y, we can swap the y's, so xy'zw and xyz'w' are in R. Because X ->-> Z, we can take the pair of tuples xyzw and xyz'w' and swap Z's to get xyz'w and xyzw'. Similarly, we can take the pair xy'z'w' and xy'zw and swap Z's to get xy'zw' and xy'z'w.In conclusion, we started with tuples xyzw and xy'z'w' and showed that xyzw' and xy'z'w must also be in the relation. That is exactly the statement of the MVD X ->-> Y-union-Z. Note that the above statements all make sense even if there are attributes in common among X, Y, and Z.Exercise 3.7.8(a)Consider a relation R with schema ABCD and the instance with four tuples abcd, abcd', ab'c'd, and ab'c'd'. This instance satisfies the MVD A->-> BC. However, it does not satisfy A->-> B. For example, if it did satisfy A->-> B, then because the instance contains the tuples abcd and ab'c'd, we would expect it to contain abc'd and ab'cd, neither of which is in the instance.Database Systems: The Complete BookSolutions for Chapter 4Solutions for Section 4.2Exercise 4.2.1class Customer {attribute string name;attribute string addr;attribute string phone;attribute integer ssNo;relationship Set<Account> ownsAcctsinverse Account::ownedBy;}class Account {attribute integer number;attribute string type;attribute real balance;relationship Set<Customer> ownedByinverse Customer::ownsAccts}Exercise 4.2.4class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemalerelationship Person fatherOfinverse Person::childrenOfMalerelationship Set<Person> childreninverse Person::parentsOfrelationship Set<Person> childrenOfFemaleinverse Person::motherOfrelationship Set<Person> childrenOfMaleinverse Person::fatherOfrelationship Set<Person> parentsOfinverse Person::children}Notice that there are six different relationships here. For example, the inverse of the relationship that connects a person to their (unique) mother is a relationship that connects a mother (i.e., a female person) to the set of her children. That relationship, which we call childrenOfFemale, is different from the children relationship, which connects anyone -- male or female -- to their children.Exercise 4.2.7A relationship R is its own inverse if and only if for every pair (a,b) in R, the pair (b,a) is also in R. In the terminology of set theory, the relation R is ``symmetric.''Solutions for Section 4.3Exercise 4.3.1We think that Social Security number should me the key for Customer, and account number should be the key for Account. Here is the ODL solution with key and extent declarations.class Customer(extent Customers key ssNo){attribute string name;attribute string addr;attribute string phone;attribute integer ssNo;relationship Set<Account> ownsAcctsinverse Account::ownedBy;}class Account(extent Accounts key number){attribute integer number;attribute string type;attribute real balance;relationship Set<Customer> ownedByinverse Customer::ownsAccts}Solutions for Section 4.4Exercise 4.4.1(a)Since the relationship between customers and accounts is many-many, we should create a separate relation from that relationship-pair.Customers(ssNo, name, address, phone)Accounts(number, type, balance)CustAcct(ssNo, number)Exercise 4.4.1(d)Ther is only one attribute, but three pairs of relationships from Person to itself. Since motherOf and fatherOf are many-one, we can store their inverses in the relation for Person. That is, for each person, childrenOfMale and childrenOfFemale will indicate that persons's father and mother. The children relationship is many-many, and requires its own relation. This relation actually turns out to be redundant, in the sense that its tuples can be deduced from the relationships stored with Person. The schema:Persons(name, childrenOfFemale, childrenOfMale)Parent-Child(parent, child)Exercise 4.4.4Y ou get a schema like:Studios(name, address, ownedMovie)Since name -> address is the only FD, the key is {name, ownedMovie}, and the FD has a left side that is not a superkey.Exercise 4.4.5(a,b,c)(a) Struct Card { string rank, string suit };(b) class Hand {attribute Set theHand;};For part (c) we have:Hands(handId, rank, suit)Notice that the class Hand has no key, so we need to create one: handID. Each hand has, in the relation Hands, one tuple for each card in the hand.Exercise 4.4.5(e)Struct PlayerHand { string Player, Hand theHand };class Deal {attribute Set theDeal;}Alternatively, PlayerHand can be defined directly within the declaration of attribute theDeal. Exercise 4.4.5(h)Since keys for Hand and Deal are lacking, a mechanical way to design the database schema is to have one relation connecting deals and player-hand pairs, and another to specify the contents of hands. That is:Deals(dealID, player, handID)Hands(handID, rank, suit)However, if we think about it, we can get rid of handID and connect the deal and the player directly to the player's cards, as:Deals(dealID, player, rank, suit)Exercise 4.4.5(i)First, card is really a pair consisting of a suit and a rank, so we need two attributes in a relation schema to represent cards. However, much more important is the fact that the proposed schema does not distinguish which card is in which hand. Thus, we need another attribute that indicates which hand within the deal a card belongs to, something like:Deals(dealID, handID, rank, suit)Exercise 4.4.6(c)Attribute b is really a bag of (f,g) pairs. Thus, associated with each a-value will be zero or more (f,g) pairs, each of which can occur several times. We shall use an attribute count to indicate the number of occurrences, although if relations allow duplicate tuples we could simply allow duplicate (a,f,g) triples in the relation. The proposed schema is:C(a, f, g, count)Solutions for Section 4.5Exercise 4.5.1(b)Studios(name, address, movies{(title, year, inColor, length,stars{(name, address, birthdate)})})Since the information about a star is repeated once for each of their movies, there is redundancy. To eliminate it, we have to use a separate relation for stars and use pointers from studios. That is: Stars(name, address, birthdate)Studios(name, address, movies{(title, year, inColor, length,stars{*Stars})})Since each movie is owned by one studio, the information about a movie appears in only one tuple of Studios, and there is no redundancy.Exercise 4.5.2Customers(name, address, phone, ssNo, accts{*Accounts})Accounts(number, type, balance, owners{*Customers})Solutions for Section 4.6Exercise 4.6.1(a)We need to add new nodes labeled George Lucas and Gary Kurtz. Then, from the node sw (which represents the movie Star Wars), we add arcs to these two new nodes, labeled direc tedBy and producedBy, respectively.Exercise 4.6.2Create nodes for each account and each customer. From each customer node is an arc to a node representing the attributes of the customer, e.g., an arc labeled name to the customer's name. Likewise, there is an arc from each account node to each attribute of that account, e.g., an arc labeled balance to the value of the balance.To represent ownership of accounts by customers, we place an arc labeled owns from each customer node to the node of each account that customer holds (possibly jointly). Also, we placean arc labeled ownedBy from each account node to the customer node for each owner of that account.Exercise 4.6.5In the semistructured model, nodes represent data elements, i.e., entities rather than entity sets. In the E/R model, nodes of all types represent schema elements, and the data is not represented at all. Solutions for Section 4.7Exercise 4.7.1(a)<STARS-MOVIES><STAR starId = "cf" starredIn = "sw, esb, rj"><NAME>Carrie Fisher</NAME><ADDRESS><STREET>123 Maple St.</STREET><CITY>Hollywood</CITY></ADDRESS><ADDRESS><STREET>5 Locust Ln.</STREET><CITY>Malibu</CITY></ADDRESS></STAR><STAR starId = "mh" starredIn = "sw, esb, rj"><NAME>Mark Hamill</NAME><ADDRESS><STREET>456 Oak Rd.<STREET><CITY>Brentwood</CITY></ADDRESS></STAR><STAR starId = "hf" starredIn = "sw, esb, rj, wit"><NAME>Harrison Ford</NAME><ADDRESS><STREET>whatever</STREET><CITY>whatever</CITY></ADDRESS></STAR><MOVIE movieId = "sw" starsOf = "cf, mh"><TITLE>Star Wars</TITLE><YEAR>1977</YEAR></MOVIE><MOVIE movieId = "esb" starsOf = "cf, mh"><TITLE>Empire Strikes Back</TITLE><YEAR>1980</YEAR></MOVIE><MOVIE movieId = "rj" starsOf = "cf, mh"><TITLE>Return of the Jedi</TITLE><YEAR>1983</YEAR></MOVIE><MOVIE movieID = "wit" starsOf = "hf"><TITLE>Witness</TITLE><YEAR>1985</YEAR></MOVIE></STARS-MOVIES>Exercise 4.7.2<!DOCTYPE Bank [<!ELEMENT BANK (CUSTOMER* ACCOUNT*)><!ELEMENT CUSTOMER (NAME, ADDRESS, PHONE, SSNO)> <!A TTLIST CUSTOMERcustId IDowns IDREFS><!ELEMENT NAME (#PCDA TA)><!ELEMENT ADDRESS (#PCDA TA)><!ELEMENT PHONE (#PCDA TA)><!ELEMENT SSNO (#PCDA TA)><!ELEMENT ACCOUNT (NUMBER, TYPE, BALANCE)><!A TTLIST ACCOUNTacctId IDownedBy IDREFS><!ELEMENT NUMBER (#PCDA TA)><!ELEMENT TYPE (#PCDA TA)><!ELEMENT BALANCE (#PCDA TA)>]>Database Systems: The CompleteBookSolutions for Chapter 5Solutions for Section 5.2Exercise 5.2.1(a)PI_model( SIGMA_{speed >= 1000} ) (PC)Exercise 5.2.1(f)The trick is to theta-join PC with itself on the condition that the hard disk sizes are equal. That gives us tuples that have two PC model numbers with the same value of hd. However, these two PC's could in fact be the same, so we must also require in the theta-join that the model numbers be unequal. Finally, we want the hard disk sizes, so we project onto hd.The expression is easiest to see if we write it using some temporary values. We start by renaming PC twice so we can talk about two occurrences of the same attributes.R1 = RHO_{PC1} (PC)R2 = RHO_{PC2} (PC)R3 = R1 JOIN_{PC1.hd = PC2.hd AND PC1.model <> PC2.model} R2R4 = PI_{PC1.hd} (R3)Exercise 5.2.1(h)First, we find R1, the model-speed pairs from both PC and Laptop. Then, we find from R1 those computers that are ``fast,'' at least 133Mh. At the same time, we join R1 with Product to connect model numbers to their manufacturers and we project out the speed to get R2. Then we join R2 with itself (after renaming) to find pairs of different models by the same maker. Finally, we get our answer, R5, by projecting onto one of the maker attributes. A sequence of steps giving the desired expression is: R1 = PI_{model,speed} (PC) UNION PI_{model,speed} (Laptop)R2 = PI_{maker,model} (SIGMA_{speed>=700} (R1) JOIN Product)R3 = RHO_{T(maker2, model2)} (R2)R4 = R2 JOIN_{maker = maker2 AND model <> model2} (R3)R5 = PI_{maker} (R4)Exercise 5.2.2Here are figures for the expression trees of Exercise 5.2.1 Part (a)Part (f)Part (h). Note that the third figure is not really a tree, since it uses a common subexpression. We could duplicate the nodes to make it a tree, but using common subexpressions is a valuable form of query optimization. One of the benefits one gets from constructing ``trees'' for queries is the ability to combine nodes that represent common subexpressions.Exercise 5.2.7The relation that results from the natural join has only one attribute from each pair of equated attributes. The theta-join has attributes for both, and their columns are identical.Exercise 5.2.9(a)If all the tuples of R and S are different, then the union has n+m tuples, and this number is the maximum possible.The minimum number of tuples that can appear in the result occurs if every tuple of one relation also appears in the other. Surely the union has at least as many tuples as the larger of R and that is, max(n,m) tuples. However, it is possible for every tuple of the smaller to appear in the other, so it is possible that there are as few as max(n,m) tuples in the union.Exercise 5.2.10In the following we use the name of a relation both as its instance (set of tuples) and as its schema (set of attributes). The context determines uniquely which is meant.PI_R(R JOIN S) Note, however, that this expression works only for sets; it does not preserve the multipicity of tuples in R. The next two expressions work for bags.R JOIN DELTA(PI_{R INTERSECT S}(S)) In this expression, each projection of a tuple from S onto the attributes that are also in R appears exactly once in the second argument of the join, so it preserves multiplicity of tuples in R, except for those thatdo not join with S, which disappear. The DELTA operator removes duplicates, as described in Section 5.4.R - [R - PI_R(R JOIN S)] Here, the strategy is to find the dangling tuples of R and remove them.Solutions for Section 5.3Exercise 5.3.1As a bag, the value is {700, 1500, 866, 866, 1000, 1300, 1400, 700, 1200, 750, 1100, 350, 733}. The order is unimportant, of course. The average is 959.As a set, the value is {700, 1500, 866, 1000, 1300, 1400, 1200, 750, 1100, 350, 733}, and the average is 967. H3>Exercise 5.3.4(a)As sets, an element x is in the left-side expression(R UNION S) UNION Tif and only if it is in at least one of R, S, and T. Likewise, it is in the right-side expressionR UNION (S UNION T)under exactly the same conditions. Thus, the two expressions have exactly the same members, and the sets are equal.As bags, an element x is in the left-side expression as many times as the sum of the number of times it is in R, S, and T. The same holds for the right side. Thus, as bags the expressions also have the same value.Exercise 5.3.4(h)As sets, element x is in the left sideR UNION (S INTERSECT T)if and only if x is either in R or in both S and T. Element x is in the right side(R UNION S) INTERSECT (R UNION T)if and only if it is in both R UNION S and R UNION T. If x is in R, then it is in both unions. If x is in both S and T, then it is in both union. However, if x is neither in R nor in both of S and T, then it cannot be in both unions. For example, suppose x is not in R and not in S. Then x is not in R UNION S. Thus, the statement of when x is in the right side is exactly the same as when it is in the left side: x is either in R or in both of S and T.Now, consider the expression for bags. Element x is in the left side the sum of the number of times it is in R plus the smaller of the number of times x is in S and the number of times x is in T. Likewise, the number of times x is in the right side is the smaller ofThe sum of the number of times x is in R and in S.The sum of the number of times x is in R and in T.A moment's reflection tells us that this minimum is the sum of the number of times x is in R plus the smaller of the number of times x is in S and in T, exactly as for the left side.Exercise 5.3.5(a)For sets, we observe that element x is in the left side(R INTERSECT S) - T。

数据库原理与应用第二版课后答案【篇一：数据库系统教程习题答案(施伯乐)(第2版)_数据库原理及应用】txt>第1章数据库概论1.1 基本内容分析1.1.1 本章的重要概念（1）db、dbms和dbs的定义（2）数据管理技术的发展阶段人工管理阶段、文件系统阶段、数据库系统阶段和高级数据库技术阶段等各阶段的特点。

（3）数据描述概念设计、逻辑设计和物理设计等各阶段中数据描述的术语，概念设计中实体间二元联系的描述（1:1，1:n，m:n）。

（4）数据模型数据模型的定义，两类数据模型，逻辑模型的形式定义，er模型，层次模型、网状模型、关系模型和面向对象模型的数据结构以及联系的实现方式。

（5）db的体系结构三级结构，两级映像，两级数据独立性，体系结构各个层次中记录的联系。

（6）dbmsdbms的工作模式、主要功能和模块组成。

（7）dbsdbs的组成，dba，dbs的全局结构，dbs结构的分类。

1.1.2本章的重点篇幅（1）教材p23的图1.24（四种逻辑数据模型的比较）。

（2）教材p25的图1.27（db的体系结构）。

（3）教材p28的图1.29（dbms的工作模式）。

（4）教材p33的图1.31（dbs的全局结构）。

1.2 教材中习题1的解答1.1 名词解释1.2 试解释db、dbms和dbs三个概念。

答：db是长期存储在计算机内、有组织的、统一管理的相关数据的集合。

dbms是位于用户与os之间的一层数据管理软件，它为用户或应用程序提供访问db的方法。

dbs是实现有组织地、动态地存储大量关联数据、方便多用户访问的计算机硬件、软件和数据资源组成的系统，即采用数据库技术的计算机系统。

1.3 人工管理阶段和文件系统阶段的数据管理各有哪些特点？答：人工管理阶段主要有四个特点：数据不保存在计算机内；没有专用的软件对数据进行管理；只有程序的概念，没有文件的概念；数据面向程序。

文件系统阶段主要有五个特点：数据以“文件”形式长期保存；数据的逻辑结构与物理结构有了区别；文件组织已多样化；数据面向应用；对数据的操作以记录为单位。

数据库技术与应用第二版课后答案【篇一：数据库技术与应用sql习题答案】class=txt>4. 启动查询分析器，在查询分析器中使用transact-sql 语句create database创建studb数据库。

然后通过系统存储过程sp_helpdb查看系统中的数据库信息create database studbsp_helpdb5. 在查询分析器中使用transact-sql语句alter database修改studb数据库的设置，指定数据文件大小为5mb，最大文件大小为20mb，自动递增大小文1mb。

alter database studbmodify file(name=studb,size=5mb,maxsize=20mb,filegrowth=1mb)7. 使用企业管理器将studb数据库的名称更改为student_db。

alter database studbmodify name=student_db8. 使用transact-sql语句drop database删除student_db数据库。

drop database student_db实验3 sql server 数据表的管理5. 使用transact-sql语句create table在studentsdb数据库中创建grade表。

create table grade(学号 char(4),课程编号 char(4),分数 decimal(5))8. 使用transact_sql语句insert into...values向studentsdb数据库的grade表插入以下数据：学号课程编号分数0004 0001 80use studentsdbgoinsert into gradevalues(0004,0001,80)9. 使用transact_sql语句alter table修改curriculum表的“课程编号”列，使之为非空。

第1章数据概述一．选择题1．下列关于数据库管理系统的说法，错误的是CA．数据库管理系统与操作系统有关，操作系统的类型决定了能够运行的数据库管理系统的类型B．数据库管理系统对数据库文件的访问必须经过操作系统实现才能实现C．数据库应用程序可以不经过数据库管理系统而直接读取数据库文件D．数据库管理系统对用户隐藏了数据库文件的存放位置和文件名2．下列关于用文件管理数据的说法，错误的是DA．用文件管理数据，难以提供应用程序对数据的独立性B．当存储数据的文件名发生变化时，必须修改访问数据文件的应用程序C．用文件存储数据的方式难以实现数据访问的安全控制D．将相关的数据存储在一个文件中，有利于用户对数据进行分类，因此也可以加快用户操作数据的效率3．下列说法中，不属于数据库管理系统特征的是CA．提供了应用程序和数据的独立性B．所有的数据作为一个整体考虑，因此是相互关联的数据的集合C．用户访问数据时，需要知道存储数据的文件的物理信息D．能够保证数据库数据的可靠性，即使在存储数据的硬盘出现故障时，也能防止数据丢失5．在数据库系统中，数据库管理系统和操作系统之间的关系是DA．相互调用B．数据库管理系统调用操作系统C．操作系统调用数据库管理系统D．并发运行6．数据库系统的物理独立性是指DA．不会因为数据的变化而影响应用程序B．不会因为数据存储结构的变化而影响应用程序C．不会因为数据存储策略的变化而影响数据的存储结构D．不会因为数据逻辑结构的变化而影响应用程序7．数据库管理系统是数据库系统的核心，它负责有效地组织、存储和管理数据，它位于用户和操作系统之间，属于AA．系统软件B．工具软件C．应用软件D．数据软件8．数据库系统是由若干部分组成的。

下列不属于数据库系统组成部分的是BA．数据库B．操作系统C．应用程序D．数据库管理系统9．下列关于客户/服务器结构和文件服务器结构的描述，错误的是DA．客户/服务器结构将数据库存储在服务器端，文件服务器结构将数据存储在客户端B．客户/服务器结构返回给客户端的是处理后的结果数据，文件服务器结构返回给客户端的是包含客户所需数据的文件C．客户/服务器结构比文件服务器结构的网络开销小D．客户/服务器结构可以提供数据共享功能，而用文件服务器结构存储的数据不能共享数据库是相互关联的数据的集合，它用综合的方法组织数据，具有较小的数据冗余，可供多个用户共享，具有较高的数据独立性，具有安全控制机制，能够保证数据的安全、可靠，允许并发地使用数据库，能有效、及时地处理数据，并能保证数据的一致性和完整性。

-数据库原理及应用第二版-第1-4章习题答案-课后习题数据库原理及应用第二版第1-4章习题答案课后习题---1. 第一章习题答案1.1 什么是数据库管理系统（DBMS）？提供三个具体例子。

DBMS是一种软件系统，用于管理和组织大量数据的存储和访问。

具体例子包括MySQL，Oracle和Microsoft SQL Server。

1.2 数据库系统由哪些基本组成部分构成？简要描述每个组成部分的功能。

数据库系统由以下组成部分构成：- 数据库：用于存储和组织数据的集合。

- 数据库管理系统（DBMS）：负责管理和操作数据库的软件系统。

- 应用程序：使用数据库中的数据进行特定任务的软件程序。

- 用户：通过应用程序和DBMS与数据库进行交互的人。

1.3 什么是数据库模式（schema）？它包括哪些内容？数据库模式是数据库的逻辑结构和特征的描述。

它包括实体（Entity）、属性（Attribute）、关系（Relationship）以及约束条件等内容。

1.4 什么是数据库实例（instance）？它包括哪些内容？数据库实例是指在内存中运行的数据库系统。

它包括当前数据库中的数据以及与之相关的缓冲区、连接信息和其他控制结构等内容。

1.5 简述数据库管理系统的主要功能。

- 数据定义功能：定义和描述数据库模式。

- 数据操作功能：实现对数据库的增、删、改、查等操作。

- 数据控制功能：管理用户访问权限，并确保数据的完整性和安全性。

- 数据库恢复功能：通过备份和恢复机制保护数据的持久性。

- 并发控制功能：维护多个用户同时访问数据库的一致性和隔离性。

2. 第二章习题答案2.1 数据库系统中的数据模型是什么？它的目的是什么？数据模型是数据库中数据的逻辑表示方式。

它的目的是描述数据之间的关系以及数据的特性和约束条件。

2.2 列举并简要描述常见的数据模型。

- 层次模型：将数据组织成树状结构，通过父节点和子节点之间的关系表示数据之间的层次关系。

第1章练习题答案一、选择题二、填空题1、数据定义、数据操纵2、文件系统阶段、数据库系统阶段3、属性、字段、元组、记录4、关键字(候选码)5、域6、属性名、属性到域的映象7、关系、关系8、投影9、选择运算、投影运算10、连接运算、自然连接三、简答题1、答：数据库（DataBase）是被长期存放在计算机内、有组织的、可以表现为多种形式的可共享的数据集合。

数据库管理系统（DataBase Management System，简称DBMS）是计算机系统软件，它的职能是有效地组织和存储数据、获取和管理数据，接受和完成用户提出的访问数据的各种请求。

数据库系统是指拥有数据库技术支持的计算机系统，它可以实现有组织地、动态地存储大量相关数据，提供数据处理和信息资源共享服务。

数据库系统是指在计算机系统中引入数据库后的系统，一般由数据库、数据库管理系统（及其开发工具）、应用系统、数据库管理员和用户构成。

2、答：关系是一张二维表，每个关系有一个关系名。

在计算机中，一个关系可以存储为一个文件。

在Visual FoxPro中，一个关系就是一个表文件。

元组是二维表中水平方向的行，有时也叫做一条记录。

属性是二维表中垂直方向的列，有时也叫做一个字段。

3、答：数据库系统由四部分组成：硬件系统、系统软件、数据库应用系统和各类人员。

4、答：常用的数据模型有层次模型、网状模型和关系模型。

层次模型的特点是：形状象一棵倒立的树，有且仅有一个结点无父结点，这个结点称为根结点，其他结点有且仅有一个父结点。

网状模型的特点是：形状象一张网，允许一个以上的结点无父结点，一个结点可以有多于一个的父结点。

关系模型的特点是：在关系中，数据的逻辑结构是一张二维表。

该表满足每一列中的分量是类型相同的数据；列的顺序可以是任意的；行的顺序可以是任意的；表中的分量是不可再分割的最小数据项，即表中不允许有子表；表中的任意两行不能完全相同。

层次模型对具有一对多层次关系的数据描述非常自然、直观、容易理解；网状模型主要是描述具有多对多关系的数据。

第1章数据概述一．选择题1．下列关于数据库管理系统的说法，错误的是CA．数据库管理系统与操作系统有关，操作系统的类型决定了能够运行的数据库管理系统的类型B．数据库管理系统对数据库文件的访问必须经过操作系统实现才能实现C．数据库应用程序可以不经过数据库管理系统而直接读取数据库文件D．数据库管理系统对用户隐藏了数据库文件的存放位置和文件名2．下列关于用文件管理数据的说法，错误的是DA．用文件管理数据，难以提供应用程序对数据的独立性B．当存储数据的文件名发生变化时，必须修改访问数据文件的应用程序C．用文件存储数据的方式难以实现数据访问的安全控制D．将相关的数据存储在一个文件中，有利于用户对数据进行分类，因此也可以加快用户操作数据的效率3．下列说法中，不属于数据库管理系统特征的是CA．提供了应用程序和数据的独立性B．所有的数据作为一个整体考虑，因此是相互关联的数据的集合C．用户访问数据时，需要知道存储数据的文件的物理信息D．能够保证数据库数据的可靠性，即使在存储数据的硬盘出现故障时，也能防止数据丢失5．在数据库系统中，数据库管理系统和操作系统之间的关系是DA．相互调用B．数据库管理系统调用操作系统C．操作系统调用数据库管理系统D．并发运行6．数据库系统的物理独立性是指DA．不会因为数据的变化而影响应用程序B．不会因为数据存储结构的变化而影响应用程序C．不会因为数据存储策略的变化而影响数据的存储结构D．不会因为数据逻辑结构的变化而影响应用程序7．数据库管理系统是数据库系统的核心，它负责有效地组织、存储和管理数据，它位于用户和操作系统之间，属于AA．系统软件B．工具软件C．应用软件D．数据软件8．数据库系统是由若干部分组成的。

下列不属于数据库系统组成部分的是BA．数据库B．操作系统C．应用程序D．数据库管理系统9．下列关于客户/服务器结构和文件服务器结构的描述，错误的是DA．客户/服务器结构将数据库存储在服务器端，文件服务器结构将数据存储在客户端B．客户/服务器结构返回给客户端的是处理后的结果数据，文件服务器结构返回给客户端的是包含客户所需数据的文件C．客户/服务器结构比文件服务器结构的网络开销小D．客户/服务器结构可以提供数据共享功能，而用文件服务器结构存储的数据不能共享数据库是相互关联的数据的集合，它用综合的方法组织数据，具有较小的数据冗余，可供多个用户共享，具有较高的数据独立性，具有安全控制机制，能够保证数据的安全、可靠，允许并发地使用数据库，能有效、及时地处理数据，并能保证数据的一致性和完整性。

数据库技术及应用第二版课后答案【篇一：数据库原理及应用(第2版)习题参考答案】．选择题1．下列关于数据库管理系统的说法，错误的是 ca．数据库管理系统与操作系统有关，操作系统的类型决定了能够运行的数据库管理系统的类型b．数据库管理系统对数据库文件的访问必须经过操作系统实现才能实现c．数据库应用程序可以不经过数据库管理系统而直接读取数据库文件d．数据库管理系统对用户隐藏了数据库文件的存放位置和文件名 2．下列关于用文件管理数据的说法，错误的是 da．用文件管理数据，难以提供应用程序对数据的独立性b．当存储数据的文件名发生变化时，必须修改访问数据文件的应用程序c．用文件存储数据的方式难以实现数据访问的安全控制 d．将相关的数据存储在一个文件中，有利于用户对数据进行分类，因此也可以加快用户操作数据的效率3．下列说法中，不属于数据库管理系统特征的是ca．提供了应用程序和数据的独立性b．所有的数据作为一个整体考虑，因此是相互关联的数据的集合 c．用户访问数据时，需要知道存储数据的文件的物理信息d．能够保证数据库数据的可靠性，即使在存储数据的硬盘出现故障时，也能防止数据丢失5．在数据库系统中，数据库管理系统和操作系统之间的关系是 d a．相互调用b．数据库管理系统调用操作系统c．操作系统调用数据库管理系统d．并发运行6．数据库系统的物理独立性是指 da．不会因为数据的变化而影响应用程序b．不会因为数据存储结构的变化而影响应用程序c．不会因为数据存储策略的变化而影响数据的存储结构d．不会因为数据逻辑结构的变化而影响应用程序7．数据库管理系统是数据库系统的核心，它负责有效地组织、存储和管理数据，它位于用户和操作系统之间，属于 aa．系统软件c．应用软件 b．工具软件 d．数据软件8．数据库系统是由若干部分组成的。

下列不属于数据库系统组成部分的是 ba．数据库c．应用程序b．操作系统 d．数据库管理系统9．下列关于客户/服务器结构和文件服务器结构的描述，错误的是da．客户/服务器结构将数据库存储在服务器端，文件服务器结构将数据存储在客户端b．客户/服务器结构返回给客户端的是处理后的结果数据，文件服务器结构返回给客户端的是包含客户所需数据的文件c．客户/服务器结构比文件服务器结构的网络开销小d．客户/服务器结构可以提供数据共享功能，而用文件服务器结构存储的数据不能共享数据库是相互关联的数据的集合，它用综合的方法组织数据，具有较小的数据冗余，可供多个用户共享，具有较高的数据独立性，具有安全控制机制，能够保证数据的安全、可靠，允许并发地使用数据库，能有效、及时地处理数据，并能保证数据的一致性和完整性。