数据库系统教程习题答案(施伯乐)(第2版)_数据库原理和应用
数据库原理及应用(第2版)--课后习题参考答案
9．在利用概念层数据模型描述数据时，一般要求模型要满足三个要求。下列描述中，不属于概念层 数据模型应满足的要求的是 A A．能够描述并发数据 B．能够真实地模拟现实世界 C．容易被业务人员理解 D．能够方便地在计算机上实现 10．数据模型三要素是指 B
3
·4·
A．数据结构、数据对象和数据共享 B．数据结构、数据操作和数据完整性约束 C．数据结构、数据操作和数据的安全控制 D．数据结构、数据操作和数据的可靠性 11．下列关于实体联系模型中联系的说法，错误的是 A．一个联系可以只与一个实体有关 B．一个联系可以与两个实体有关 C．一个联系可以与多个实体有关 D．一个联系也可以不与任何实体有关 D
·1·
第 1 章 数据概述
一．选择题 1．下列关于数据库管理系统的说法，错误的是 C A．数据库管理系统与操作系统有关，操作系统的类型决定了能够运行的数据库管理系统的类型 B．数据库管理系统对数据库文件的访问必须经过操作系统实现才能实现 C．数据库应用程序可以不经过数据库管理系统而直接读取数据库文件 D．数据库管理系统对用户隐藏了数据库文件的存放位置和文件名 2．下列关于用文件管理数据的说法，错误的是 D A．用文件管理数据，难以提供应用程序对数据的独立性 B．当存储数据的文件名发生变化时，必须修改访问数据文件的应用程序 C．用文件存储数据的方式难以实现数据访问的安全控制 D．将相关的数据存储在一个文件中，有利于用户对数据进行分类，因此也可以加快用户操作数 据的效率 3．下列说法中，不属于数据库管理系统特征的是 C A．提供了应用程序和数据的独立性 B．所有的数据作为一个整体考虑，因此是相互关联的数据的集合 C．用户访问数据时，需要知道存储数据的文件的物理信息 D．能够保证数据库数据的可靠性，即使在存储数据的硬盘出现故障时，也能防止数据丢失 5．在数据库系统中，数据库管理系统和操作系统之间的关系是 A．相互调用 B．数据库管理系统调用操作系统 C．操作系统调用数据库管理系统 D．并发运行 6．数据库系统的物理独立性是指 D A．不会因为数据的变化而影响应用程序 B．不会因为数据存储结构的变化而影响应用程序 C．不会因为数据存储策略的变化而影响数据的存储结构 D．不会因为数据逻辑结构的变化而影响应用程序 7．数据库管理系统是数据库系统的核心，它负责有效地组织、存储和管理数据，它位于用户和操作 系统之间，属于 A A．系统软件 B．工具软件 C．应用软件 D．数据软件 8．数据库系统是由若干部分组成的。下列不属于数据库系统组成部分的是 A．数据库 B．操作系统 C．应用程序 D．数据库管理系统 B D
数据库原理与应用教程-(第二版)人民邮电出版社习题参考答案
习题参考答案第1章习题参考答案一、选择题1. C2. B3. D4. C5. D6. A7. A8. B9. D、10. B 11. C 12. D 13. A 14. D 15. B二、填空题1. 数据库系统2. 关系3. 物理独立性4. 操作系统5. 数据库管理系统（DBMS）6. 多对多7. 独立性8. 完整性控制9. 逻辑独立性10. 关系模型11. 概念结构（逻辑）12. 树有向图二维表嵌套和递归13. 宿主语言（或主语言）14. 数据字典15. 单用户结构主从式结构分布式结构客户/服务器结构浏览器/服务器结构第2章习题参考答案一、选择题1. A2. C3. C4. B5. B6. C7. B8. D9. C 10. A11. B 12. A 13. A 14. D 15. D二、填空题1. 选择（选取）2. 交3. 相容（或是同类关系）4. 并差笛卡尔积选择投影5. 并差交笛卡尔积6. 选择投影连接7. σf(R)8. 关系代数关系演算9. 属性10. 同质11. 参照完整性12. 系编号系名称，电话，办公地点13. 元组关系域关系14. 主键外部关系键15. R和S没有公共的属性三简答题（1）查询T1老师所授课程的课程号和课程名。
ΠCNO,CN（σTNO=’T1’（TC）*ΠCNO,CN（C）)（2）查询年龄大于18岁男同学的学号、姓名、系别。
ΠSNO, SN, Dept（σAge>18∧Sex=’男’（S））（3）查询“李力”老师所授课程的课程号、课程名和课时。
ΠCNO (ΠTNO（σTN=’李力’（T））*TC))* C（4）查询学号为S1的同学所选修课程的课程号、课程名和成绩。
ΠCNO,CN,Score（σSNO=’S1’（SC）*ΠCNO,CN（C））（5）查询“钱尔”同学所选修课程的课程号、课程名和成绩。
ΠCNO,CN,Score（ΠSNO（σSN=’钱尔’（S））*ΠCNO,CN（C）*SC）（6）查询至少选修“刘伟”老师所授全部课程的学生姓名。
数据库原理及应用第二版答案
数据库原理及应用第二版答案数据库原理及应用是计算机科学与技术专业的一门重要课程，涉及到数据库的基本原理、设计、管理和应用等内容。
本文将从数据库的概念、结构、设计、管理和应用等方面进行详细的介绍和解析，帮助读者更好地理解数据库原理及应用。
首先，数据库是指按照数据结构来组织、存储和管理数据的仓库，它是一个有组织的、可共享的数据集合。
数据库的结构一般包括数据、数据的结构、数据的存储和数据的管理等方面。
数据库的设计是指按照一定的原则和方法来设计数据库的结构和组织形式，以便于数据的存储、管理和应用。
数据库的管理是指对数据库进行维护、管理和优化，以保证数据库的安全、稳定和高效运行。
数据库的应用是指将数据库应用到实际的业务中，以满足用户的需求和提高工作效率。
其次，数据库的原理包括数据模型、数据库设计、数据库管理系统、数据库语言和数据库应用等方面。
数据模型是指对现实世界的数据进行抽象和描述，以便于在计算机系统中进行存储和处理。
数据库设计是指按照一定的原则和方法来设计数据库的结构和组织形式，以便于数据的存储、管理和应用。
数据库管理系统是指对数据库进行管理、维护和优化的软件系统，它提供了对数据库的访问、操作和控制等功能。
数据库语言是指对数据库进行操作和管理的语言，包括数据定义语言、数据操纵语言和数据控制语言等。
数据库应用是指将数据库应用到实际的业务中，以满足用户的需求和提高工作效率。
最后，数据库的应用包括数据库的设计、数据库的管理和数据库的应用等方面。
数据库的设计是指按照一定的原则和方法来设计数据库的结构和组织形式，以便于数据的存储、管理和应用。
数据库的管理是指对数据库进行维护、管理和优化，以保证数据库的安全、稳定和高效运行。
数据库的应用是指将数据库应用到实际的业务中，以满足用户的需求和提高工作效率。
综上所述，数据库原理及应用是计算机科学与技术专业的一门重要课程，涉及到数据库的基本原理、设计、管理和应用等内容。
本文从数据库的概念、结构、设计、管理和应用等方面进行了详细的介绍和解析，希望能够帮助读者更好地理解数据库原理及应用。
数据库原理和应用(第2版)习题参考答案解析
第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版)_数据库原理和应用
第2部分各章习题解答及自测题第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）教材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联系”。
·数据模型：能表示实体类型及实体间联系的模型称为“数据模型”。
数据库系统教程课后答案(施伯乐)(第二版)
目录第1部分课程的教与学第2部分各章习题解答及自测题第1章数据库概论1.1 基本内容分析1.2 教材中习题1的解答1.3 自测题1.4 自测题答案第2章关系模型和关系运算理论2.1基本内容分析2.2 教材中习题2的解答2.3 自测题2.4 自测题答案第3章关系数据库语言SQL3.1基本内容分析3.2 教材中习题3的解答3.3 自测题3.4 自测题答案第4章关系数据库的规范化设计4.1基本内容分析4.2 教材中习题4的解答4.3 自测题4.4 自测题答案第5章数据库设计与ER模型5.1基本内容分析5.2 教材中习题5的解答5.3 自测题5.4 自测题答案第6章数据库的存储结构6.1基本内容分析6.2 教材中习题6的解答第7章系统实现技术7.1基本内容分析7.2 教材中习题7的解答7.3 自测题7.4 自测题答案第8章对象数据库系统8.1基本内容分析8.2 教材中习题8的解答8.3 自测题8.4 自测题答案第9章分布式数据库系统9.1基本内容分析9.2 教材中习题9的解答9.3 自测题9.4 自测题答案第10章中间件技术10.1基本内容分析10.2 教材中习题10的解答10.3 自测题及答案第11章数据库与WWW11.1基本内容分析11.2 教材中习题11的解答第12章 XML技术12.1基本内容分析12.2 教材中习题12的解答学习推荐书目1．国内出版的数据库教材（1）施伯乐,丁宝康,汪卫. 数据库系统教程(第2版). 北京:高等教育出版社,2003（2）丁宝康,董健全. 数据库实用教程(第2版). 北京:清华大学出版社,2003（3）施伯乐,丁宝康. 数据库技术. 北京:科学出版社,2002（4）王能斌. 数据库系统教程(上、下册). 北京:电子工业出版社,2002（5）闪四清. 数据库系统原理与应用教程. 北京:清华大学出版社,2001（6）萨师煊,王珊. 数据库系统概论(第3版). 北京:高等教育出版社,2000（7）庄成三,洪玫,杨秋辉. 数据库系统原理及其应用. 北京:电子工业出版社,20002．出版的国外数据库教材（中文版或影印版）（1）Silberschatz A，Korth H F，Sudarshan S. 数据库系统概念(第4版). 杨冬青,唐世渭等译. 北京:机械工业出版社,2003（2）Elmasri R A，Navathe S B. 数据库系统基础(第3版). 邵佩英,张坤龙等译. 北京:人民邮电出版社,2002（3）Lewis P M,Bernstein A,Kifer M. Databases and Transaction Processing:An Application-Oriented Approach, Addison-Wesley, 2002（影印版, 北京:高等教育出版社；中文版，施伯乐等译，即将由电子工业出版社出版）（4）Hoffer J A,Prescott M B,McFadden F R. Modern Database Management. 6th ed. Prentice Hall, 2002（中文版，施伯乐等译，即将由电子工业出版社出版）3．上机实习教材（1）廖疆星,张艳钗,肖金星. PowerBuilder 8.0 & SQL Server 2000数据库管理系统管理与实现. 北京:冶金工业出版社,2002（2）伍俊良. PowerBuilder课程设计与系统开发案例. 北京:清华大学出版社,20034．学习指导书（1）丁宝康,董健全,汪卫,曾宇昆. 数据库系统教程习题解答及上机指导. 北京:高等教育出版社,2003（2）丁宝康,张守志,严勇. 数据库技术学习指导书. 北京:科学出版社,2003（3）丁宝康,董健全,曾宇昆. 数据库实用教程习题解答. 北京:清华大学出版社,2003 （4）丁宝康. 数据库原理题典. 长春:吉林大学出版社,2002（5）丁宝康,陈坚,许建军,楼晓鸿. 数据库原理辅导与练习. 北京:经济科学出版社,2001第1部分课程的教与学1．课程性质与设置目的现在，数据库已是信息化社会中信息资源与开发利用的基础，因而数据库是计算机教育的一门重要课程，是高等院校计算机和信息类专业的一门专业基础课。
数据库系统基础教程(第二版)课后习题答案
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 and the 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 itsown 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., Jeff Garcia 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 a relation 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 us BD->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 relationExercise 3.5.8(a)If all sets of attributes are closed, then there cannot be any nontrivial functional dependencies. 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 thecalculations 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,cs,cb, then if there is any other tuple t for the same person, there will also be another tuple that agrees with t except that it has,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.4You 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 directedBy 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 place an 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)> <!ATTLIST CUSTOMERcustId IDowns IDREFS><!ELEMENT NAME (#PCDATA)><!ELEMENT ADDRESS (#PCDATA)><!ELEMENT PHONE (#PCDATA)><!ELEMENT SSNO (#PCDATA)><!ELEMENT ACCOUNT (NUMBER, TYPE, BALANCE)><!ATTLIST ACCOUNTacctId IDownedBy IDREFS><!ELEMENT NUMBER (#PCDATA)><!ELEMENT TYPE (#PCDATA)><!ELEMENT BALANCE (#PCDATA)>]>Database Systems: TheComplete BookSolutions 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 queryoptimization. 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 attributefrom 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 that do 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)。
数据库原理与应用教程(第二版)(陈志泊主编)参考答案
习题参考答案第1章习题参考答案一、选择题1. C2. B3. D4. C5. D6. A7. A8. B9. D、10. B 11. C 12. D 13. A14. D 15. B二、填空题1. 数据库系统2. 关系3. 物理独立性4. 操作系统5. 数据库管理系统（DBMS）6. 多对多7. 独立性8. 完整性控制9. 逻辑独立性10. 关系模型11. 概念结构（逻辑）12. 树有向图二维表嵌套和递归13. 宿主语言（或主语言）14. 数据字典15. 单用户结构主从式结构分布式结构客户/服务器结构浏览器/服务器结构第2章习题参考答案一、选择题1. A2. C3. C4. B5. B6. C7. B8. D9. C 10. A11. B 12. A13. A14. D 15. D二、填空题1. 选择（选取）2. 交3. 相容（或是同类关系）4. 并差笛卡尔积选择投影5. 并差交笛卡尔积6. 选择投影连接7. σf(R)8. 关系代数关系演算9. 属性10. 同质11. 参照完整性12. 系编号系名称，电话，办公地点13. 元组关系域关系14. 主键外部关系键15. R和S没有公共的属性三简答题（1）查询T1老师所授课程的课程号和课程名。
ΠCNO,CN（σTNO=’T1’（TC）*ΠCNO,CN（C）)（2）查询年龄大于18岁男同学的学号、姓名、系别。
ΠSNO, SN, Dept（σAge>18∧Sex=’男’（S））（3）查询“李力”老师所授课程的课程号、课程名和课时。
ΠCNO (ΠTNO（σTN=’李力’（T））*TC))* C（4）查询学号为S1的同学所选修课程的课程号、课程名和成绩。
ΠCNO,CN,Score（σSNO=’S1’（SC）*ΠCNO,CN（C））（5）查询“钱尔”同学所选修课程的课程号、课程名和成绩。
ΠCNO,CN,Score（ΠSNO（σSN=’钱尔’（S））*ΠCNO,CN（C）*SC）（6）查询至少选修“刘伟”老师所授全部课程的学生姓名。
数据库技术及应用第二版课后答案
数据库技术及应用第二版课后答案【篇一：数据库原理及应用(第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．客户/服务器结构可以提供数据共享功能，而用文件服务器结构存储的数据不能共享数据库是相互关联的数据的集合，它用综合的方法组织数据，具有较小的数据冗余，可供多个用户共享，具有较高的数据独立性，具有安全控制机制，能够保证数据的安全、可靠，允许并发地使用数据库，能有效、及时地处理数据，并能保证数据的一致性和完整性。
数据库系统及应用(第二版)习题解答-
数据库系统及应用(第二版)习题解答习题一1. 什么是数据库?数据库是相互关联的数据的集合,它用综合的方法组织数据,具有较小的数据冗余,可供多个用户共享,具有较高的数据独立性,具有安全控制机制,能够保证数据的安全、可靠,允许并发地使用数据库,能有效、及时地处理数据,并能保证数据的一致性和完整性。
2. 简要概述数据库、数据库管理系统和数据库系统各自的含义。
数据库、数据库管理系统和数据库系统是三个不同的概念,数据库强调的是相互关联的数据,数据库管理系统是管理数据库的系统软件,而数据库系统强调的是基于数据库的计算机应用系统。
3. 数据独立性的含义是什么?数据独立性是指数据的组织和存储方法与应用程序互不依赖、彼此独立的特性。
这种特性使数据的组织和存储方法与应用程序互不依赖,从而大大降低应用程序的开发代价和维护代价。
4. 数据完整性的含义是什么?保证数据正确的特性在数据库中称之为数据完整性。
5. 简要概述数据库管理员的职责。
数据库管理员的职责可以概括如下:(1 首先在数据库规划阶段要参与选择和评价与数据库有关的计算机软件和硬件,要与数据库用户共同确定数据库系统的目标和数据库应用需求,要确定数据库的开发计划;(2 在数据库设计阶段要负责数据库标准的制定和共用数据字典的研制,要负责各级数据库模式的设计,负责数据库安全、可靠方面的设计;(3 在数据库运行阶段首先要负责对用户进行数据库方面的培训;负责数据库的转储和恢复;负责对数据库中的数据进行维护;负责监视数据库的性能,并调整、改善数据库的性能,提高系统的效率;继续负责数据库安全系统的管理;在运行过程中发现问题、解决问题。
6. 文件系统用于数据管理存在哪些明显的缺陷?文件系统用于数据管理明显存在如下缺陷:(1 数据冗余大。
这是因为每个文件都是为特定的用途设计的,因此就会造成同样的数·2·《数据库系统及应用》习题解答据在多个文件中重复存储。
(2 数据不一致性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第2部分各章习题解答及自测题第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联系”。
·数据模型：能表示实体类型及实体间联系的模型称为“数据模型”。
·概念数据模型：独立于计算机系统、完全不涉及信息在计算机中的表示、反映企业组织所关心的信息结构的数据模型。
·结构数据模型（或逻辑数据模型）：与DBMS有关的，直接面向DB的逻辑结构、从计算机观点对数据建模的数据模型。
·层次模型：用树型（层次）结构表示实体类型及实体间联系的数据模型称为层次模型。
·网状模型：用有向图结构表示实体类型及实体间联系的数据模型称为网状模型。
·关系模型：用二维表格表达实体集的数据模型。
·外模式：是用户用到的那部分数据的描述。
·概念模式：数据库中全部数据的整体逻辑结构的描述。
·内模式：DB在物理存储方面的描述。
·外模式/模式映象：用于定义外模式和概念模式之间数据结构的对应性。
·模式/内模式映象：用于定义概念模式和内模式之间数据结构的对应性。
·数据独立性：应用程序和DB的数据结构之间相互独立，不受影响。
·物理数据独立性：在DB的物理结构改变时，尽量不影响应用程序。
·逻辑数据独立性：在DB的逻辑结构改变时，尽量不影响应用程序。
·主语言：编写应用程序的语言（如C一类高级程序设计语言），称为主语言。
·DDL：定义DB三级结构的语言，称为DDL。
·DML：对DB进行查询和更新操作的语言，称为DML。
·过程性语言：用户编程时，不仅需要指出“做什么”，还需要指出“怎么做”的语言。
·非过程性语言：用户编程时，只需指出“做什么”，不需要指出“怎么做”的语言。
·DD（数据字典）：存放三级结构定义的DB，称为DD。
·DD系统：管理DD的软件系统，称为DD系统。
1.2 试解释DB、DBMS和DBS三个概念。
答：DB是长期存储在计算机内、有组织的、统一管理的相关数据的集合。
DBMS是位于用户与OS之间的一层数据管理软件，它为用户或应用程序提供访问DB的方法。
DBS是实现有组织地、动态地存储大量关联数据、方便多用户访问的计算机硬件、软件和数据资源组成的系统，即采用数据库技术的计算机系统。
1.3 人工管理阶段和文件系统阶段的数据管理各有哪些特点？答：人工管理阶段主要有四个特点：数据不保存在计算机内；没有专用的软件对数据进行管理；只有程序的概念，没有文件的概念；数据面向程序。
文件系统阶段主要有五个特点：数据以“文件”形式长期保存；数据的逻辑结构与物理结构有了区别；文件组织已多样化；数据面向应用；对数据的操作以记录为单位。
1.4 文件系统阶段的数据管理有些什么缺陷？试举例说明。
答：主要有三个缺陷：数据冗余；数据不一致性；数据联系弱。
例如学校里教务处、财务处、保健处建立的文件中都有学生详细资料，譬如联系电话，家庭住址等。
这就是“数据”冗余；如果某个学生搬家，就要修改三个部门文件中的数据，否则会引起同一数据在三个部门中不一致；产生上述问题的原因是这三个部门的文件中数据没有联系。
1.5 数据管理的数据库阶段产生的标志是哪三件事情？答：进入数据库阶段的标志是20世纪60年代末发生的三件事件：·1968年IBM公司研制的IMS系统是一个典型的层次DBS；·1969年美国CODASYL组织DBTG报告，提出网状DBS的概念；·1970年美国IBM公司的E.F.Codd发表论文，提出关系模型的思想。
1.6 数据库阶段的数据管理有哪些特点？答：主要有五个特点：采用数据模型表示复杂的数据结构；有较高的数据独立性；为用户提供了方便的用户接口；提供了四个方面的数据控制功能；对数据的操作以数据项为单位，增加了系统的灵活性。
1.7 与“文件”结构相比，“数据库”结构有些什么不同？答：与文件结构相比，数据库结构主要有下面三点不同：·数据的结构化。
文件由记录组成，但各文件之间缺乏联系。
数据库中数据在磁盘中仍以文件形式组织，但这些文件之间有着广泛的联系。
数据库的逻辑结构用数据模型来描述，整体结构化。
数据模型不仅描述数据本身的特点，还要描述数据之间的联系。
·数据独立性。
文件只有设备独立性，而数据库还具有逻辑独立性和物理独立性。
·访问数据的单位。
访问文件中的数据，以记录为单位。
访问数据库中的数据，以数据项（字段）为单位，增加了系统的灵活性。
1.8 什么是数据独立性？在数据库中有哪两级独立性？答：数据独立性是指应用程序与DB的数据结构之间相互独立。
在物理结构改变时，尽量不影响应用程序，称为物理数据独立性；在逻辑结构改变时，尽量不影响应用程序，称为逻辑数据独立性。
1.9 分布式数据库系统和面向对象数据库系统各有哪些特点？答：DDBS主要有三个特点：·数据物理上分布在各地，但逻辑上是一个整体；·每个场地既可以执行局部应用，也可以执行全局应用；·各地的计算机由数据通信网络相连接。
面向对象数据系统主要有两个特点：·面向对象数据模型能完整地描述现实世界的数据结构，能表达数据间嵌套、递归的联系。
·具有面向对象技术的封装性和继承性的特点，提高了软件的可重用性。
1.10 逻辑记录与物理记录，逻辑文件与物理文件有些什么联系和区别？答：逻辑数据是用户用以操作的数据形式，是抽象的概念化数据。
物理数据是实际存放在存储设备上的数据。
逻辑数据与物理数据在结构上可以差别很大，需通过两级映象来进行数据传输和格式转换。
从以上的解释可以看出，逻辑记录和逻辑文件是用户在程序中使用的记录和文件，而物理记录和物理文件是指磁盘上的记录和文件。
逻辑记录、文件与物理记录、文件在结构、组成上有很大的差异，而数据管理软件就是通过三级结构两级映象来实现逻辑数据与物理数据之间的转换。
1.11 试述ER模型、层次模型、网状模型、关系模型和面向对象模型的主要特点。
答：ER模型直接表示实体类型及实体间联系，与计算机系统无关，充分反映用户的需求，用户容易理解。
层次模型的数据结构为树结构，记录之间联系通过指针实现，查询较快，但DML属于过程化的，操作复杂。
网状模型的数据结构为有向图，记录之间联系通过指针实现，查询较快，并且容易实现M:N联系，但DML属于过程化的语言，编程较复杂。
关系模型的数据结构为二维表格，容易为初学者理解。
记录之间联系通过关键码实现。
DML属于非过程化语言，编程较简单。
面向对象模型能完整描述现实世界的数据结构，具有丰富的表达能力，能表达嵌套、递归的数据结构。
但涉及的知识面较广，用户较难理解，这种模型尚未普及。
1.12 数据之间联系在各种结构数据模型中是怎么实现的？答：在层次、网状模型中，数据之间的联系通过指针实现的；在关系模型中，数据之间联系通过外键和主键间联系实现的；在面向对象模型中，数据之间嵌套、递归联系通过对象标识符（OID）实现的（见第8章）。
1.13 DB的三级模式结构描述了什么问题？试详细解释。
答：DB的三级模式结构是对数据的三个抽象级别，分别从外部（用户）级、概念级和内部级去观察数据库。
外部级是用户使用的局部数据库的逻辑结构，其描述称为外模式。
概念级是DB的整体逻辑结构，其描述称为概念模式。
内部级是DB的物理结构，其描述称为内模式。
1.14 试述概念模式在数据库结构中的重要地位。
答：数据按外模式的描述提供给用户，按内模式的描述存储在磁盘中，而概念模式提供了连接这两级的相对稳定的中间观点，并使得两级的任何一级的改变都不受另一级的牵制。
1.15 试叙述用户、DB的三级模式结构、磁盘上的物理文件之间有些什么联系和不同？答：用户、外模式、概念模式、内模式和物理文件中的记录分别称为用户记录、外部记录、概念记录、内部记录和物理记录。
用户记录与外部记录的结构是一致的，它们之间只是数据传输问题。
而外部记录、概念记录和内部记录之间的结构可能是不一致的，除了数据传输问题，还有格式转换问题。
内部记录与物理记录的结构是一致的，它们之间只是数据传输问题。
1.16 数据独立性与数据联系这两个概念有什么区别？答：数据独立性是指应用程序和DB的数据之间相互独立，不受影响，对系统的要求是“数据独立性要高”，而数据联系是指记录之间的联系，对系统的要求是“数据联系密切”。
1.17 试述DBMS的工作模式和主要功能。
答：DBMS的工作模式有六点：·接受应用程序的数据请求和处理请求；·将用户的数据请求转换成低层指令；·实现对DB的操作；·从对DB的操作中接受查询结果；·对查询结构进行处理；·将处理结果返回给用户。
DBMS的主要功能有DB的定义、操纵、保护、维护和数据字典等五个功能。