数据库系统基础教程第十章答案

合集下载

数据库应用基础教程答案

数据库应用基础教程答案【篇一：access数据库应用基础教程(第三版)习题及答案】txt>程（第三版）习题集答案第1章数据库系统概述1. 什么是数据库？什么是数据库系统？答：数据库（database）是存放数据的仓库，严格的讲，数据库是长期存储在计算机内,有组织的，可共享的大量数据集合。

数据库系统（database systems），是由数据库及其管理软件组成的系统。

它是为适应数据处理的需要而发展起来的一种较为理想的数据处理的核心机构。

它是一个实际可运行的存储、维护和应用系统提供数据的软件系统，是存储介质、处理对象和管理系统的集合体。

2. 什么是数据库管理系统？它有哪些主要功能？答：数据库管理系统(database management system)是一种操纵和管理数据库的大型软件，用于建立、使用和维护数据库，简称dbms。

它对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。

数据库管理系统的主要功能有：数据定义、数据操作、数据库的运行管理、数据组织、数据库的保护、数据库的维护和通信。

3. 说出几种常用的数据模型。

答：层次模型、网状模型、关系模型。

4. 什么是关系模型？答：关系模型是用二维表的形式表示实体和实体间联系的数据模型。

5. 简述数据库设计的步骤。

答：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的建立和测试、数据库运行和维护。

第2章 sql 语言简介1. 什么是sql语言？sql语言具有哪些特点和功能？答：sql是一种数据库查询和程序设计语言，用于存取数据以及查询更新和管理关系数据库系统。

sql的特点和功能有：查询，操作，定义和控制四个方面，sql语言具有高度的非过程化，语言简洁，语义明显，语法结构简单，直观易懂的特点。

sql语言即可以作为独立语言使用，用户可以在终端键盘上直接键入sql命令对数据库进行操作，也可以作为嵌入式语言，嵌入到其他高级语言中。

2. sql语言包含哪几个部分?答：sql语言包含4个部分：数据定义语言（ddl-data definition language）、数据查询语言（dql-data query language）、数据操纵语言（dml-data manipulation language）、数据控制语言（dcl-data control language）3. 在联接查询中，包含哪几类联接？答：联接可分为3类：（1）内部联接（典型的联接运算，使用类似于 = 或的比较运算符）。

《数据库基础与应用》课后习题答案

《数据库基础与应用》课后习题答案第一章数据库系统概论1. 人工管理、文件管理、数据库管理2. 依赖于3. 独立、联系4. 做什么、怎么做5. 文件、数据库6. 安全性、一致性、并发性、数据库恢复7. 兼容性强、可靠性高、地域范围广、数据量大、客户数多8. 主属性、非主属性9. 1对1、1对多、多对多10. 1、多11. 1、多12. 记录型、1对多13. 过程、集合14. 元组、属性15. 1、n16. 数据结构、集合运算、独立、数学17. 封装、继承、多态18. 操作系统、开发工具19. 全局模式、外模式、内模式20. 外模式和模式、模式和内模式21. 定义（描述）操纵22. 系统、用户第二章关系运算1. 关系数据结构、关系完整性规则、关系运算2. 域、列名（属性名）3. 1、多4. 候选、属性5. 学生号、非主6. 实体、参照、用户定义7. 空值、主码8. 并、交、差、笛卡尔积9. a1+b1、a2´b210. 选择、211. 4、312. Õ学生号、X、δ课程名=’程序设计’13. Õ课程号(X)、C第三章关系规范化基础1. X→Y、决定因素2. 非平凡、平凡3. 非平凡、完全4. X、Z5. X→(Y,Z)、合并性6. X、候选码7. (A,C)、28. A、19. (A,C,G)、310. 第三、无损连接、函数依赖11. 属性、元组、关系12. 数据冗余、操作异常（更新异常）13. 第一、314. 第一、215. 第二、216. 第二、17. BC第四章结构化查询语言--SQL一、填空题1. 视图、基本表2. 非过程化、集合3. KUCUN、LIU4. 列级、表级5. 主码、单值、外码、检查6. primary key、foreign key7. 建立、修改、删除8. 单行（单值）、多行（多值）9. 插入、修改、删除10. 表、建立11. 修改、查找12. 基本表、视图13. 没有影响、有影响14. create view、update、drop view15.投影、连接、选择16. group by、order by17. inner join、left join、right join二、根据主教材第四章所给的商品库和教学库，按照下列所给的每条SQL查询语句写出相应的功能。

数据库系统基础教程(第二版)课后习题答案2

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。

数据库基础课后习题及答案

数据库基础课后习题及答案数据库基础课后习题及答案数据库是计算机科学中非常重要的一个概念，它用于存储和管理大量的数据。

在数据库基础课程中，学生通常需要完成一些习题来巩固所学的知识。

本文将介绍一些常见的数据库基础课后习题，并提供相应的答案。

一、选择题1. 数据库是指什么？A. 存储和管理数据的软件系统B. 存储和管理硬件设备的软件系统C. 存储和管理网络的软件系统D. 存储和管理操作系统的软件系统答案：A2. 数据库管理系统（DBMS）的主要功能是什么？A. 存储和管理数据B. 分析和处理数据C. 网络和通信D. 操作系统管理答案：A3. 下列哪个不属于数据库的特点？A. 数据共享B. 数据冗余C. 数据独立性D. 数据一致性答案：B4. 数据库中的数据是以什么形式存储的？A. 文件B. 表格C. 文本D. 图像答案：B5. 数据库中的主键是什么？A. 唯一标识一个记录的属性B. 存储在数据库中的所有数据C. 数据库中的表格D. 数据库中的索引答案：A二、填空题1. 数据库中的关系是指什么？关系是指数据之间的联系和关联。

2. 数据库中的SQL是什么意思？SQL是结构化查询语言（Structured Query Language）的缩写。

3. 数据库中的DDL是什么意思？DDL是数据定义语言（Data Definition Language）的缩写。

4. 数据库中的DML是什么意思？DML是数据操作语言（Data Manipulation Language）的缩写。

5. 数据库中的索引有什么作用？索引可以提高数据库的查询效率，加快数据检索的速度。

三、简答题1. 数据库的三级模式是什么？数据库的三级模式包括外模式、概念模式和内模式。

外模式是用户对数据库的直接接口，概念模式是数据库的全局逻辑结构，内模式是数据库在物理存储上的表示。

2. 数据库的ACID是什么意思？ACID是数据库事务的四个特性，包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

数据库系统教程(第三版课后答案)免费下载.doc

第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:1联系：如果实体集E1中每个实体至多和实体集E2中的一个实体有联系，反之亦然，那么E1和E2的联系称为“1:1联系”。

·1:N联系：如果实体集E1中每个实体可以与实体集E2中任意个（零个或多个）实体有联系，而E2中每个实体至多和E1中一个实体有联系，那么E1和E2的联系是“1:N联系”。

·M:N联系：如果实体集E1中每个实体可以与实体集E2中任意个（零个或多个）实体有联系，反之亦然，那么E1和E2的联系称为“M:N联系”。

·数据模型：能表示实体类型及实体间联系的模型称为“数据模型”。

数据库教程（SQLServer）课后习题及答案

习题13、简述数据库系统的组成。

答：数据库系统一般由数据库、数据库管理系统（及其开发工具）、数据库管理员（DataBase Administrator ，DBA ）和用户组成。

4、试述数据库系统的三级模式结构。

这种结构的优点是什么？答：数据库系统的三级模式结构是指数据库系统是由外模式、模式和内模式三级构成，同时包含了二级映像，即外模式/模式映像、模式/内模式映像，如下图所示。

数据库应用1……外模式A 外模式B 模式应用2应用3应用4应用5……模式外模式/模式映像模式/内模式映像数据库系统的这种结构具有以下优点：（1）保证数据独立性。

将外模式与模式分开，保证了数据的逻辑独立性；将内模式与模式分开，保证了数据的物理独立性。

（2）有利于数据共享，减少了数据冗余。

（3）有利于数据的安全性。

不同的用户在各自的外模式下根据要求操作数据，只能对限定的数据进行操作。

（4）简化了用户接口。

按照外模式编写应用程序或输入命令，而不需了解数据库全局逻辑结构和内部存储结构，方便用户系统。

5、什么是数据的物理独立性与逻辑独立性？并说明其重要性。

答：（1）数据的物理独立性是指数据的物理结构（包括存储结构、存取方式等）的改变，存储设备的更换，物理存储的更换，存取方式改变等都不影响数据库的逻辑结构，从而不致引起应用程序的变化。

（2）数据的逻辑独立性是指数据库总体逻辑结构的改变，如修改数据模式，增加新的数据类型、改变数据间联系等，不需要相应修改应用程序。

（3）数据的独立性使得数据库中数据独立于应用程序而不依赖于应用程序，也就是说数据的逻辑结构、存储结构与存取方式的改变不影响应用程序。

相应的，数据的独立性也使得应用程序的编制不再依赖于数据的物理和逻辑结构，提高了应用程序的可移植性与鲁棒性。

从理论上说，数据的独立性可以使数据的组织和应用程序的编制完全分离。

8、什么是数据模型？答：数据模型（Data Model ）是一种抽象模型，是对现实世界数据特征的抽象。

(完整版)数据库原理课后题答案

第1章1.试恳数据、数据库、数据库系统、数据库管理系统的概念。

答:（1）数据：描述事物的符号记录成为数据。

数据的种类有数字、文字、图形、图像、声音、正文等。

数据与其语义是不可分的。

（2）数据库：数据库是长期储存在计算机内的、有组织的、可共享的数据集合。

数据库中的数据按照一定的数据模型组织。

描述和储存，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。

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

（4）数据库管理系统：数据库管理系统是位于用户与操作系统之间的一层数据管理软件，用于科学地组织和存储数据、高效地获取和维护数据。

DBMS的主要功能包括数据定义功能、数据操作功能、数据库的建立和维护功能。

6. 试述数据库系统三级模式结构，这种结构的优点是什么？答：数据库系统的三级模式机构由外模式、模式和内模式组成。

外模式，亦称子模式或用户模式，是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。

模式亦称逻辑模式，是数据库中全体数据呃逻辑结构和特征的描述，是所有用户的公共数据视图。

模式描述的是数据的全局逻辑结构。

外模式涉及的是数据的内部逻辑结构，通常是模式的子集。

内模式，亦称存储模式，是数据在数据库内部的表示，即对数据的物理结构和存储方式的描述。

数据库系统的三级模式是对数据的三个抽象级别，它对数据的具体组织留给DBMS管理，使用户能逻辑抽象地处理数据，而不必关心数据在计算机中的表示和存储。

为了能够在内部实现这三个抽象层次的联系和转换，数据库系统在这三级模式之间提供了两层映像：外模式/模式映像和模式/内模式映像。

正是这两层映像保证了数据库系统中的数据能够具有较高的逻辑独立性和物理独立性。

7. 定义并解释下列术语。

数据库系统教程_课答案(施伯乐)(第三版)