数据库实验2-1答题文件(答案)
数据库习题及答案
一．选择题：1.数据库分析与设计中，其设计对象称客观世界的〔〕A.逻辑对象B.目标对象C.实体对象D.需求对象答案：B 〔150〕2. 数据库物理设计完成后，进入数据库实施阶段，以下各项中不属于实施阶段的工作是〔〕A.建立库构造B.扩大功能C.加载数据D.系统调试答案：B 〔150〕3. 通常用以下的顺序来完成数据库的设计工作〔〕A.概念设计、物理设计、逻辑设计B.逻辑设计、概念设计、物理设计C.概念设计、逻辑设计、物理设计D.物理设计、逻辑设计、概念设计答案：C 〔150〕4. 在数据库设计中，在概念设计阶段可用E-R方法，其设计出的图称为〔〕A.实物示意图B.实用概念图C.实体表示图D.实体联系图答案：D 〔153〕5. E-R图是数据库设计的工具之一，它适用于建立数据库的〔〕A.概念模型B.逻辑模型C.构造模型D.物理模型答案：A 〔155〕6.在关系数据库设计中，完成设计关系模式的任务是属于〔〕A.需求分析阶段B.概念设计阶段C.逻辑设计阶段D.物理设计阶段答案：C 〔157〕7. 数据库逻辑设计的主要任务是〔〕A.建立E-R图和说明书B.创立数据库说明C.建立数据流图D.把数据送入数据库答案：B 〔158〕二．填空题1. 数据库概念设计是在数据需求分析根底上进展的，其目的是分析数据间的在语义关联，在此根底上建立一个数据的______________。
答案：抽象模型〔152〕2. 数据库的逻辑设计的根本方法是将E-R图转换成指定RDBMS中的______________，此外还包括关系的规化以及性能调整，最后是约束条件设置。
答案：关系模式〔156〕3. 数据库的逻辑设计的根本方法是将E-R图转换成指定RDBMS中的关系模式，此外还包括______________以及性能调整，最后是约束条件设置。
答案：关系的规化〔156〕4. 数据库的逻辑设计的根本方法是将E-R图转换成指定RDBMS中的关系模式，此外还包括关系的规化以及______________，最后是约束条件设置。
数据库考试题及答案
数据库考试题及答案一、选择题（每题2分，共20分）1. 在关系数据库中，用来表示实体间关系的是：A. 属性B. 关系C. 键D. 域答案：B2. SQL语言中的“SELECT”语句用于：A. 插入数据B. 更新数据C. 查询数据D. 删除数据答案：C3. 数据库管理系统（DBMS）的主要功能不包括：A. 数据存储B. 数据恢复C. 数据加密D. 数据查询答案：C4. 以下哪个不是数据库的完整性约束：A. 实体完整性B. 参照完整性C. 用户定义完整性D. 索引完整性答案：D5. 在关系数据库中，主键是用来：A. 唯一标识一个表中的每一行B. 存储表中的数据C. 建立表与表之间的关系D. 排序表中的数据答案：A6. 数据库规范化的目的是：A. 提高查询速度B. 减少数据冗余C. 增加数据安全性D. 降低存储成本答案：B7. 在SQL中，用于删除表中数据的语句是：A. DROPB. DELETEC. REMOVED. ERASE答案：B8. 数据库的并发控制主要解决的问题是：A. 数据丢失B. 数据重复C. 数据不一致D. 数据泄露答案：C9. 在数据库设计中，E-R图主要用于：A. 表示数据的存储结构B. 表示数据的流程C. 表示数据的逻辑结构D. 表示数据的物理结构答案：C10. 数据库的事务具有以下哪个特性，确保操作的原子性：A. 一致性B. 持久性C. 隔离性D. 原子性答案：D二、简答题（每题10分，共30分）1. 请简述数据库的三大范式，并举例说明。
答案：数据库的三大范式包括：- 第一范式（1NF）：要求数据库表的每一列都是不可分割的基本数据项，即表中的所有字段都应该只包含原子性的值，不能有集合、数组或重复的数据。
- 第二范式（2NF）：在第一范式的基础上，要求表中没有部分依赖，即非主键字段完全依赖于主键。
- 第三范式（3NF）：在第二范式的基础上，要求表中没有传递依赖，即非主键字段只能依赖于主键，不能依赖于其他非主键字段。
数据库系统基础教程(第二版)课后习题答案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、2章 习题答案
目前,几乎所有企业或部门的信息系统都以数据库系统为基础,都使用数据库。例如,一个工厂的管理信息系统(其中会包括许多子系统,如库存管理系统、物资采购系统、作业调度系统、设备管理系统、人事管理系统等),学校的学生管理系统,人事管理系统,图书馆的图书管理系统,等等都适合用数据库系统。
5.试述数据库系统的特点。
当需要改变模式时(例如增加新的关系、新的属性、改变属性的数据类型、改变数据间的联系等)，由数据库管理员对各个外模式／模式的映象作相应改变，而使外模式保持不变，从而不必修改或重写应用程序改。而应用程序是依据数据的外模式编写的，保证了数据与程序的逻辑独立性。简称数据的逻辑独立性。
特定的应用程序是在外模式描述的数据结构上编制的，它依赖于特定的外模式，与数据库的模式和存储结构独立。不同的应用程序有时可以共用同一个外模式。数据库的二级映象保证了数据库外模式的稳定性，从而从底层保证了应用程序的稳定性，除非应用需求本身发生变化，否则应用程序一般不需要修改。
6.某工厂生产若干产品，每种产品由不同的零件组成。有的零件可用在不同的产品上，这些零件由不同的原材料制成，不同零件所用的材料可以相同。这些零件按所属的不同产品分别放在仓库中，原材料按照类别放在若干仓库中。请用E-R图画出此工厂产品，零件，材料，仓库的概念模型。
《数据库原理与应用》课后习题参考答案
《数据库原理与应用》课后习题参考答案第一章作业参考答案1. 单项选择题C C D B C2. 判断题对错错错对3填空题网状模型用户商业智能数据挖掘系统设计4简答题1）数据模型是指描述事物对象的数据组成、数据关系、数据约束的抽象结构及其说明。
数据模型是指描述事物对象的数据组成、数据关系、数据约束的抽象结构及其说明。
数据模型是指描述事物对象的数据组成、数据关系、数据约束的抽象结构及其说明。
3〕数据约束：用于描述数据结构中数据之间的语义联系、数据之间的制约和依存关系，以及数据动态变化的规则。
主流数据库采用关系图模型。
数据库典型数据模型：层次数据模型网状数据模型关系数据模型其它数据模型〔如对象数据模型、键值对数据模型、列式数据模型。
〕2）数据库——是一种依照特定数据模型组织、存储和管理数据的文件，数据库文件一般存放在辅助存储器以便长久保存。
数据库具有如下特点：数据不重复存放；提供应多种应用程序访问；数据结构独立于使用它的应用程序；对数据增、删、改、检索由统一软件进行管理和控制。
3）数据库(Database)是一种依照特定模型组织、存储和管理数据的数据结构。
在数据库中，不仅存放了数据，而且还存放了数据与数据之间的关系。
数据库内部元素：用户表：用户在数据库中创建的数据库表；系统表：数据库中系统自带的数据库表；视图：数据库中用于对数据进行查询的虚拟表；索引：数据库中用于加快数据查询的索引项；约束：数据库中对数据、数据关系施加的规则；存储过程：数据库内部完成特定功能处理的程序；触发器：数据库内部因数据变化自动执行的一类存储过程等等4）数据库系统包括：用户、数据库应用程序、数据库管理系统和数据库四个组成要素。
5）数据库管理系统〔Database Manage System，DBMS 〕——是一种专门用来创建数据库、管理数据库、维护数据库，并提供对数据库访问的系统软件。
数据库管理系统〔DBMS〕主要功能：创建数据库和表; 创建支持结构,如索引等; 读取数据库数据; 修改数据库数据; 维护数据库结构; 执行规则; 并发控制; 提供安全性; 执行备份和恢复等等第二章作业参考答案1 单项选择题C B D A A2. 判断题对对错对错3填空题全外连接数据约束候选键用户定义完整性4简答题外码键1）在关系模型中，使用“关系”来存储“实体”中的数据。
数据库课后答案
第1章习题一、填空题1. 在数据管理技术发展历程的几个阶段中，在（人工管理）阶段数据不能保存。
2. 数据模型由以下三要素组成：（数据结构）、数据操作和数据的约束条件。
3. 数据模型按不同的应用层次分成三种类型，它们是：概念数据模型、（逻辑数据模型）、（物理数据模型）。
4. E-R模型属于（概念数据）模型，结构数据模型指层次、网状、关系。
5. 数据库专家们提出了数据库系统分级的系统结构模型，整个系统分为三级，它们分别是（外模式）、（模式）和（内模式）。
二、选择题1．在文件系统阶段，操作系统管理数据的基本单位是（A ）。
A.文件B.记录C.程序D.数据项2. 数据管理技术发展过程中，文件系统与数据库系统的重要区别是数据库具有（C）。
A.数据可共享B.数据无冗余C.特定的数据模型D.有专门的数据管理软件3. 在数据库的数据模型中有（A）。
A.网状模型、层次模型、关系模型B.数字型、字母型、日期型C.二数值型、字符型、逻辑型D.数学模型、概念模型、逻辑模型4. 用表格形式的结构表示实体类型以及实体类型之间联系的数据模型是（A）。
A.关系数据模型B.层次数据模型C.网状数据模型D.面向对象数据模型5. 描述概念模型的常用方法是（D）。
A.建立数据模型方法B.需求分析方法C.二维表方法D.实体－联系方法三、判断题1. 数据库管理员是专门从事数据库设计、管理和维护的工作人员。
（√）2. 计算机的数据管理技术经历了人工管理、文件系统管理和数据库系统三个阶段。
（√）3. 逻辑数据模型（又称数据模型），它是一种面向客观世界、面向用户的模型；它与具体的数据库系统无关，与具体的计算机平台无关。
（⨯）4. 数据模型通常由数据结构、数据操作和完整性约束三部分组成。
（√）5. 内模式亦称为子模式或用户模式，描述的是数据的局部逻辑结构。
（⨯）四、简答题1．解释数据库、数据库管理系统和数据库系统的概念。
答：数据库(DataBase）是具有统一结构形式、可共享的、长期储存在计算机内的数据的集合。
(完整word版)数据库原理与应用(1,2章)练习1-带答案
第一章、第二章内容练习一1.Access数据库的类型是A)层次数据库B)网状数据库C)关系数据库D)面向对象数据库2．数据库DB、数据库系统DBS、数据库管理系统DBMS三者之间的关系是A）DBS包括DB和DBMS B）DBMS包括DB和DBSC）DB包括DBS和DBMS D）D．DBS就是DB，也就是DBMS 3. 在关系数据库中，二维表的行称为A）域B）元组C）关键字D）属性4. 完整性规则不包括A）实体完整性B）参照完整性C）用户定义完整性D）属性完整性5. 关系型数据库管理系统，所谓关系是指A）各条记录中的数据彼此有一定的关系B）一个数据库文件与另一个数据库文件之间有一定的关系C）二维表格D）数据库中各个字段之间彼此有一定的关系6. 在概念模型中，一个实体集对应于关系模型中的一个____________。
A）元组B）字段C）属性D）关系7. 关于关系模式的关键字，以下说法正确的是____________。
A．一个关系模式可以有多个主关键字B．一个关系模式可以有多个候选关键字C．主关键字可以取空值D．有一些关系模式没有关键字8. 关系数据库通过主索引实现了数据的____________。
A）更新完整性B）域完整性C）实体完整性D）参照完整性9.规范化理论是关系数据库进行逻辑设计的理论依据，根据这个理论，关系数据库中的关系必须满足：每一个属性都是（）。
A.长度不变的B.不可分解的C.互相关联的D.互不相关的10.已知关系模式R（A，B，C，D，E）及其上的函数依赖集合F＝{A→D，B →C ，E→A }，该关系模式的候选码是（）。
A.ABB.BEC.CDD.DE11．关系模式的候选码可以有1个或多个，而主码有（）。
A.多个B.0个C.1个D.1个或多个12．关系数据库规范化是为了解决关系数据库中（）的问题而引入的。
A.提高查询速度B.插入、删除异常和数据冗余C.保证数据的安全性D.结构13．在数据库系统的三级模式之间，提供两层映象的作用是提高（）A．数据的一致性B．数据的独立性C．数据的完整性D．操作的可行性14．实体完整性规则是指关系中（）A．元组值不允许空B．属性值不允许空C．主码值不允许空D．外码值不允许空15．在数据库设计中，将E－R模型转换成关系数据模型的过程属于（）A．需要分析阶段B．逻辑设计阶段C．概念设计阶段D．物理设计阶段16．在数据库逻辑结构设计中，将E-R模型转换为关系模型应遵循相应原则。
数据库原理及应用第二版-第-章习题答案-课后习题
第1章数据库概述1．试说明数据、数据库、数据库管理系统和数据库系统的概念。
答：数据是描述事物的符号记录，是数据库中存储的基本对象。
数据库是存放数据的仓库，是长期存储在计算机中的有组织的、可共享的大量数据的集合。
数据库管理系统是一个专门用于实现对数据进行管理和维护的系统软件。
数据库系统是指在计算机中引入数据库后的系统，一般由数据库、数据库管理系统（及相关的实用工具）、应用程序、数据库管理员组成。
2．数据管理技术的发展主要经历了哪几个阶段？答：数据管理技术的发展主要经历了文件管理和数据库管理两个阶段。
3．与文件管理相比，数据库管理有哪些优点？答：将相互关联的数据集成在一起，具有较少的数据冗余，程序与数据相互独立，保证数据的安全可靠，最大限度地保证数据的正确性，数据可以共享并能保证数据的一致性。
4．在数据库管理方式中，应用程序是否需要关心数据的存储位置和存储结构？为什么？答：不需要。
因为在数据库系统中，数据的存储位置以及存储结构保存在数据库管理系统中，从数据到物理存储位置的转换是由数据库管理系统自动完成的。
5．在数据库系统中，数据库的作用是什么？答：在数据库系统中，数据库是存放数据的场所。
6．在数据库系统中，应用程序可以不通过数据库管理系统而直接访问数据文件吗？答：不能。
7．数据独立性指的是什么？它能带来哪些好处？答：数据独立性指的是数据的逻辑独立性和物理独立性。
逻辑独立性带来的好处是当表达现实世界信息的逻辑结构发生变化时，可以不影响应用程序；物理独立性带来的好处是当数据的存储结构发生变化时，可以不影响数据的逻辑组织结构，从而也不影响应用程序。
8．数据库系统由哪几部分组成，每一部分在数据库系统中的作用大致是什么？答：数据库系统由四个主要部分组成，即数据库、数据库管理系统、应用程序和系统管理员。
数据库是数据的汇集，它以一定的组织形式存于存储介质上；数据库管理系统是管理数据库的系统软件，它可以实现数据库系统的各种功能；系统管理员负责数据库的规划、设计、协调、维护和管理等工作；应用程序指以数据库数据为核心的应用程序。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第2章VisualFoxPro入门
实验2-1 初识VFP
实验要求
打开其中的“实验2-1答题文件.doc”文件，简答或按题目要求实现如下操作。
实验
1．VFP的安装与卸载
●卸载VFP操作步骤：
（1）单击“开始”按钮，单击打开“控制面板”，再双击“添加或删除程序”打开“添加或删除程序”面板，选中需要卸载（删除）的VFP程序，单击“更改/删除”按钮，如图1-1-1所示。
按照提示步骤即可完成卸载（删除）VFP程序的操作。
图1-1-1卸载（删除）VFP程序
●安装VFP操作步骤：
（1）双击老师提供的资料“VFP60.RAR”，解压缩到文件夹VFP60，双击文件夹VFP60中的SETUP.EXE安装图标，开始进行安装，如图1-1-2所示。
图1-1-2卸载（删除）VFP程序
（2）单击“下一步”按钮，出现如1-1-3所示界面，单击选中“接受协议”。
图1-1-3VFP程序用户许可协议
（3）单击“下一步”按钮，出现如1-1-4所示界面，要求用户输入产品的ID号，如果正确，“下一步”按钮变为可选状态。
图1-1-4输入产品的ID号
（4）单击“下一步”按钮，选择公用安装文件夹的位置，默认安装路径是“C:\Program Files\Microsoft Studio\Common”，用户可单击“浏览”按钮，重新指定路径，如图1-1-5所示。
图1-1-5选择安装目标文件夹
（5）单击“下一步”按钮，进入VFP的安装程序界面，单击“继续”按钮，按提示完成一系列操作，如图1-1-6所示。
图1-1-6安装程序界面
（6）安装结束后，显示安装成功的界面，如图1-1-7所示。
单击“确定”按钮完成安装。
图1-1-7安装成功界面
2．VFP的启动方法
用不同的方法启动VFP，认识VFP6的主窗口，了解VFP的菜单栏。
（1）VFP的启动方法有：
方法一：单击“开始”按钮，选择【程序】→【Microsoft Visual FoxPro 6.0】→【Microsoft Visual FoxPro 6.0】，即可启动VFP程序。
方法二：直接双击桌面上的快捷图标“Microsoft Visual FoxPro 6.0”即可启动VFP 程序。
（2）Visual FoxPro主窗口界面即Visual FoxPro的工作环境，启动Visual FoxPro 6.0后，打开如图1-1-8所示的界面，了解VFP的菜单栏。
标题栏
菜单栏
工具栏
显示区
命令窗口
图1-1-8VFP主窗口界面
3．退出VFP的方法
●退出VFP的方法有：
方法一：单击VFP 主窗口的关闭按钮。
方法二：在命令窗口中输入QUIT命令。
方法三：选择菜单【文件】→【退出】命令。
方法四：双击标题栏左上角的“”控制图标。
方法五：单击标题栏左上角的“”控制图标，在控制菜单中选“关闭”命令。
方法六：按Alt+F4键。
4．VFP的默认目录设置
●操作步骤如下：
假设要设置的默认目录为E:\DA TA，在E盘根目录下文件夹“DATA”已经存在；
方法一：在命令窗口输入命令
SET DEFAULT TO E:\DATA
方法二：使用菜单设置
（１）打开VFP6后，选择菜单【工具】→【选项】，在弹出的“选项”对话框中，单击“文件位置”选项卡，选择“默认目录”，如图1-1-9所示；
图1-1-9“选项”对话框
（２）单击右下角“”按钮，弹出如图1-1-10的“更改文件位置”
对话框；
图1-1-10“更改文件位置”对话框
（３）单击选中“使用（U）默认目录”选项卡，再单击“”按钮，弹出如图1-1-11
的“选择目录”对话框，在驱动器下拉列表中选择E：盘，在当前工作目录中选择“E:\DATA”，单击“选定”按钮，返回“更改文件位置”对话框，单击“确定”按钮，返回“选项”对话框，再单击“确定”按钮完成默认目录的设置，如图1-1-12所示；
图1-1-11“选择目录”对话框
图1-1-12默认目录设置完成
5．VFP有几种操作方式？有何利弊？
（1）交互操作方式
交互操作方式包括命令方式、菜单工作方式和工具操作方式三种。
命令方式是指在命令窗口输入命令，按回车键，系统立即执行该命令并在显示区中显示结果。
使用命令方式为用户提供了一个直接操作的手段，这种方法能够直接使用系统的各种命令和函数，有效地操纵数据库，但需要熟悉命令格式和函数的细节。
菜单工作方式是指通过菜单的选择来完成操作。
这样用户不需要记忆命令的具体格式，而是按指定要求通过菜单交互来完成操作数据库的目的。
其突出的特点是操作简单、直观且容易掌握。
工具操作方式是指应用VFP系统的许多工具如设计器、向导和生成器等交互式开发工具。
利用这些工具可以非常方便地完成创建表、表单、数据库、查询和报表以及管理数据的操作。
另外，系统将菜单中一些常用功能通过工具条的方式放置在屏幕上，单击相应的工具图标就可以进行操作。
（2）程序执行方式
程序执行方式是指将多条命令编写成一个程序，通过运行这个程序达到操作数据库的目的。
程序执行方式突出的特点是运行效率高、可重复执行。
VFP的程序设计和其他高级语言的程序设计是一样的。