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

合集下载

数据库系统课后习题及答案

数据库系统课后习题及答案第1章绪论习题参考答案1、试述数据、数据库、数据库管理系统、数据库系统的概念。

（3、4、5页）答：描述事物的符号记录称为数据；数据库是长期储存在计算机内的、有组织的、可共享的数据集合；数据库管理系统是位于用户与操作系统之间的一层数据管理软件; 数据库系统是指在计算机系统中引入数据库后的系统，一般由数据库、数据库管理系统(及其开发工具)、应用系统、数据库管理员和用户构成。

2．使用数据库系统有什么好处?（12页）答：数据库系统使信息系统从以加工数据的程序为中心转向围绕共享的数据库为中心的阶段，这样既便于数据的集中管理，又有利于应用程序的研制和维护，提高了数据的利用率和相容性，提高了决策的可靠性。

3．试述文件系统与数据库系统的区别和联系。

（8、9、10页）答：1）数据结构化是数据库与文件系统的根本区别。

在文件系统中，相互独立的文件的记录内部是有结构的，管其记录内部已有了某些结构，但记录之间没有联系。

数据库系统实现整体数据的结构化，是数据库的主要特征之一。

2）在文件系统中，数据的最小存取单位是记录，粒度不能细到数据项。

而在数据库系统中，存取数据的方式也很灵活，可以存取数据库中的某一个数据项、一组数据项一个记录或或一组记录。

3）文件系统中的文件是为某一特定应用服务的，文件的逻辑结构对该应用程序来说是优化的，因此要想对现有的数据再增加一些新的应用会很困难，系统不容易扩充。

而在数据库系统中数据不再针对某一应用，而是面向全组织，具有整体的结构化。

5．试述数据库系统的特点。

（9、10、11页）答：数据结构化；数据的共享性高、冗余度低、易扩充；数据独立性高；数据由DBMS统一管理和控制。

6．数据库管理系统的主要功能有哪些? （4页）答：数据定义功能、数据操纵功能、数据库的运行管理、数据库的建立和维护功能。

7．试述数据模型的概念（13页）、数据模型的作用、数据模型的三个要素。

（14、15页）答：数据模型(Data Model)也是一种模型，它是现实世界数据特征的抽象。

南京理工大学《数据库系统基础教程》试题和标准答案

一、选择题60(选择一个最合适的答案，在答题纸上涂黑)１.一个事务中的一组更新操作是一个整体,要么全部执行,要么全部不执行。

这是事务的：A．原子性B.一致性 C.隔离性 D.持久性２．在数据库的三级模式结构中,描述一个数据库中全体数据的全局逻辑结构和特性的是：Ａ．外模式 B．内模式 C.存储模式D．模式3．关于联系的多重性,下面哪种说法不正确？A.一个多对多的联系中允许多对一的情形。

B.一个多对多的联系中允许一对一的情形。

C．一个多对一的联系中允许一对一的情形。

Ｄ．一个多对一的联系中允许多对多的情形。

4.考虑学校里的"学生"和"课程＂之间的联系，该联系的多重性应该是:A. 一对一 B．多对一 C．一对多 D. 多对多5．下面哪种约束要求一组属性在同一实体集任意两个不同实体上的取值不同。

A. 键(key）约束。

Ｂ．单值约束。

C．参照完整性。

D．域(domａin)约束6．关系模型要求各元组的每个分量的值必须是原子性的。

对原子性,下面哪种解释不正确: A.每个属性都没有内部结构。

ﻩＢ.每个属性都不可再分解。

Ｃ.各属性值应属于某种基本数据类型。

ﻩD.属性值不允许为ＮUＬL。

７．对于一个关系的属性(列)集合和元组（行）集合，下面哪种说法不正确:A.改变属性的排列次序不影响该关系。

B．改变元组的排列次序不影响该关系。

C.改变元组的排列次序会改变该关系。

D.关系的模式包括其名称及其属性集合。

８．若Ｒ是实体集R1与R２间的一个多对多联系,将其转换为关系R'，哪种说法不正确：Ａ.R'属性应包括R１与R2的所有属性。

B.R'属性应包括R1与R2的键属性。

C.R1与R２的键属性共同构成R'的键。

D.R'的属性应包括R自身定义的属性。

9.关于函数依赖的判断,下面哪种说法不正确？A.若任意两元组在属性A上一致，在Ｂ上也一致，则有A →B成立。

B.若任意两元组在属性A上一致,在B上不一致,则A → B不成立。

数据库系统基础教程课后答案

Solutions Chapter 44.1.14.1.2a)b)In c we assume that a phone and address can only belong to a single customer (1-m relationship represented by arrow into customer).In d we assume that an address can only belong to one customer and a phone canexist at only one address.If the multiplicity of above relationships were m-to-n, the entity set becomesweak and the key ssNo of customers will be needed as part of the composite keyof the entity set.In c&d, we convert attributes phones and addresses to entity sets. Since entitysets often become relations in relational design,we must consider more efficient alternatives.Instead of querying multiple tables where key values are duplicated, we can also modify attributes:(i) Phones attribute can be converted into HomePhone, OfficePhone and CellPhone. (ii) A multivalued attribute such as alias can be kept as an attribute where asingle column can be used in relational design i.e. concatenate all values. SQLallows a query "like '%Junius%'" to search the multiple values in a column alias.4.1.34.1.4a)b)c)The relationship "played" between Teams and Players is similar to relationship "plays" between Teams and Players.4.1.54.1.6 The information about children can be ascertained from motherOf and fatherOf relationships. Attribute ssNo is required since names are not unique.4.1.74.1.8a)(b)4.1.9AssumptionsA Professor only works in at most one department.A course has at most one TA.A course is only taught by one professor and offered by one department.Students and professors have been assigned unique email ids.A course is uniquely identified by the course no, section no, and semester (e.g. cs157-3 spring 09).4.1.10Given that for each movie, a unique studio exists that produces the movie. Each star is contracted to at most one studio.But stars could be unemployed at a given time. Thus the four-way relationship in fig 4.6 can be easily into converted equivalent relationships.Redundancy: The owner address is repeated in AccSets and Addresses entity sets. Simplicity: AccSets does not serve any useful purpose and the design can be more simply represented by creating many-to-many relationship between Customers and Accounts.Right kind of element: The entity set Addresses has a single attribute address.A customer cannot have more than one address.Hence address should be an attribute of entity set Customers.Faithfulness: Customers cannot be uniquely identified by their names. In real world Customers would have a unique attribute such as ssNo or customerNo4.2.2Studios and Presidents can be combined into one entity set Studios withPresidents becoming an attribute of Studios under following circumstances:1. The Presidents entity set only contains a simple attribute viz. presidentName. Additional attributes specific to Presidents might justify making Presidentsinto an entity set.4.2.34.2.4 The entity sets should have single attribute.a) Stars: starNameb) Movies: movieNamec) Studios: studioName. However there exists a many-to-many relationship between Studios and Contracts. Hence, in addition, we need more information aboutstudios involved. If a contract always involves two studios, two attributes such as producingStudio and starStudio can replace theStudios entity set. If a contact can be associated with at most five studios, it may be possible to replace the Studios entity set by five attributes viz.studio1, studio2, studio3, studio4, and studio5. Alternately, a compositeattribute containing concatenation of all studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searchingof such an attribute using query like '%keyword%'From Augmentation rule of Functional Dependency,givenB -> M (B=Baby, M=Mother)thenBND -> M (N=Nurse, D=Doctor)Hence we can just put an arrow entering mother.a) Put an arrow entering entity set Mothers for the simplest solution (As in fig.4.4, where a multi-way relationship was allowed, even though Movies alone could identify the Studio). However, we can display more accurate information with below figure.Again from Augmentation rule of Functional Dependency,givenBM -> DthenBMN -> DThus we can just add an arrow entering Doctors to fig 4.15. Below figure represents more accurate information however.4.2.6a)b) Transitivity and Augmentation rules of Functional Dependency allow arrow entering Mothers from Births. However, a new relationship in below figure represents more accurate information.c)Design flaws in abc above 1. As suggested above, using Transitivity and Augmentation rules of Functional Dependency, much simpler design is possible.4.2.7In below figure there exists a many-to-one relationship between Babies and Births and another many-to-one relationship between Births and Mothers. From transitivity of relationships, there is a many-to-one relationship between Babies and Mothers. Hence a baby has a unique mother while a birth can allow more than one baby.4.3.1a)b)A captain cannot exist without a team. However a player can (free agent). A recently formed (or defunct) team can exist without players or colors.c)Children can exist without mother and father (unknown).4.3.2a)The keys of both E1 and E2 are required for uniquely identifying tuples in Rb)The key of E1c)The key of E2d)The key of either E1 or E24.3.3Special Case: All entity sets have arrows going into them i.e. all relationships are 1-to-1Any KiOtherwise: Combination of all Ki's where there does not exist an arrow going from R to Ei.4.4.1No, grade is not part of the key for enrollments. The keys of Students and Courses become keys of the weak entity set Enrollments.4.4.2It is possible to make assignment number a weak key of Enrollments but this is not good design (redundancy since multiple assignments correspond to a course).A new entity set Assignment is created and it is also a weak entity set. Hence the key attributes of Assignment will come from the strong entity sets to which Enrollments is connected i.e. studentID, dept, and CourseNo.4.4.3a)b)4.4.4a)4.5.1Customers(SSNo,name,addr,phone)Flights(number,day,aircraft)Bookings(custSSNo,flightNo,flightDay,row,seat)Relations for toCust and toFlt relationships are not required since the weak4.5.2(a)(b)Schema is changed. Since toCust is no longer an identifying relationship, SSNo is no longer a part of Bookings relation.Bookings(flightNo,flightDay,row,seat)ToCust(custSSNO,flightNo,flightDay,row,seat)The above relations are merged intoBookings(flightNo,flightDay,row,seat,custSSNo)However custSSNo is no longer a key of Bookings relation. It becomes a foreign4.5.3Ships(name, yearLaunched)SisterOf(name, sisterName)4.5.4(a)Stars(name,addr)Studios(name,addr)Movies(title,year,length,genre)Contracts(starName,movieTitle,movieYear,studioName,salary)Depending on other relationships not shown in ER diagram, studioName may not be required as a key of Contracts (or not even required as an attribute of Contracts).(b)Students(studentID)Courses(dept,courseNo)Enrollments(studentID,dept,courseNo,grade)(c)Departments(name)Courses(deptName,number)(d)Leagues(name)Teams(leagueName,teamName)Players(leagueName,teamName,playerName)4.6.1The weak relation Courses has the key from Depts along with number. Hence there is no relation for GivenBy relationship.(a)Depts(name, chair)Courses(number, deptName, room)LabCourses(number, deptName, allocation)(b) LabCourses has all the attributes of Courses.Depts(name, chair)Courses(number, deptName, room)(c) Courses and LabCourses are combined into one relation.Depts(name, chair)Courses(number, deptName, room, allocation)4.6.2(a)Person(name,address)ChildOf(personName,personAddress,childName,childAddress)Child(name,address,fatherName,fatherAddress,motherName,motherAddresss)Father(name,address,wifeName,wifeAddresss)Mother(name,address)Since FatherOf and MotherOf are many-one relationships from Child, there is no need for a separate relation for them. Similarly the one-one relationshipMarried can be included in Father (or Mother). ChildOf is a many-manyrelationship and needs a separate relation.However the ChildOf relation is not required since the relationship can be deduced from FatherOf and MotherOf relationships contained in Child relation. (b)A person cannot be both Mother and Father.Person(name,address)PersonChild(name,address)PersonChildFather(name,address)PersonChildMother(name,address)PersonFather(name,address)PersonMother(name,address)ChildOf(personName,personAddress,childName,childAddress)FatherOf(childName,childAddress,fatherName,fatherAddress)MotherOf(childName,childAddress,motherName,motherAddress)Married(husbandName,husbandAddress,wifeName,wifeAddress)The many-many ChildOf relationship again requires a relation.An entity belongs to one and only one class when using object-oriented approach. Hence, the many-one relations MotherOf and FatherOf could be added as attributes to PersonChild,PersonChildFather, and PersonChildMother relations.Similarly the Married relation can be added as attributes to PersonChildMother and PersonMother (or the corresponding father relations).(c) For the Person relation at least one of husband and wife attributes will be null.Person(personName,personAddress,fatherName,fatherAddress,motherName,motherAddres ss,wifeName,wifeAddresss,husbandName,husbandAddress)ChildOf(personName,personAddress,childName,childAddress)4.6.3(a)People(name,fatherName,motherName)Males(name)Females(name)Fathers(name)Mothers(name)ChildOf(personName,childName)(b)People(name)PeopleMale(name)PeopleMaleFathers(name)PeopleFemale(name)PeopleFemaleMothers(name)ChildOf(personName,childName)FatherOf(childName,fatherName)MotherOf(childName,motherName)People cannot belong to both male and female branch of the ER diagram.Moreover since an entity belongs to one and only one class when using object-oriented approach, no entity belongs to People relation.Again we could replace MotherOf and FatherOf relations by adding as attributesto PeopleMale,PeopleMaleFathers,PeopleFemale, and PeopleFemaleMothers relations.(c)People(name,fatherName,motherName)ChildOf(personName,childName)4.6.4(a)Each entity set results in one relation. Thus both the minimum and maximum number of relations is e.The root relation has a attributes including k keys. Thus the minimum number of attributes is a. All other relations include the k keys from root along withtheir a attributes. Thus the maximum number of attributes is a+k.(b)The relation for root will have a attributes. The relation representing the whole tree will have e*a attributes.The number of relations will depend on the shape of the tree. A tree of eentities where only one child exists(say left child only) would have the minimum number of relations. Thus below figure will only contain 4 subtrees that contain root E1,E1E2,E1E2E3, and E1E2E3E4. With e entity sets, minimum e relations are possible.The maximum number of subtrees result when all the entities(except root) are at depth 1. Thus below figure will contain 8 subtrees that contain rootE1,E1E2,E1E3,E1E4,E1E2E3,E1E3E4,E1E2E4,and E1E2E3E4. With e entity sets, maximum 2^(e-1) relations are possible.(c)The nulls method always results in one relation and contains attributes from all e entities i.e. e*a attributes.Summarizing for a,b, and c above;#Components #RelationsMin Max Min MaxMethodstraight-E/R a a e eobject-oriented a e*a e 2^(e-1)nulls e*a e*a 1 14.7.14.7.2a)b)c)d)4.7.34.7.5Males and Females subclasses are complete. Mothers and Fathers are partial. All subclasses are disjoint.4.7.7We convert the ternary relationship Contracts into three binary relationships between a new entity set Contracts and existing entity sets.4.7.9a)b)c)4.7.10A self-association ParentOf for entity set people has multiplicity 0..2 at parent role end.In a Library database, if a patron can loan at most 12 books, them multiplicity is 0..12.For a FullTimeStudents entity set, a relationship of multiplicity 5..* must exist with Courses (A student must take at least5 courses to be classified FullTime.4.8.1Customers(SSNo,name,addr,phone)Flights(number,day,aircraft)Bookings(row,seat,custSSNo,FlightNumber,FlightDay)Customers("SSNo",name,addr,phone)Flights("number","day",aircraft)Bookings(row,seat,"custSSNo","FlightNumber","FlightDay")4.8.2a)Movies(title,year,length,genre)Studios(name,address)Presidents(cert#,name,address)Owns(movieTitle,movieYear,studioName)Runs(studioName,presCert#)Movies("title","year",length,genre)Studios("name",address)Presidents("cert#",name,address)Owns("movieTitle","movieYear",studioName)Runs("studioName",presCert#)b)Since the subclasses are disjoint, Object Oriented Approach is used. The hierarchy is not complete. Hence four relations are required Movies(title,year,length,genre)MurderMysteries(title,year,length,genre,weapon)Cartoons(title,year,length,genre)Cartoon-MurderMysteries(title,year,length,genre,weapon)Movies("title","year",length,genre)MurderMysteries("title","year",length,genre,weapon)Cartoons("title","year",length,genre)Cartoon-MurderMysteries("title","year",length,genre,weapon)c)Customers(ssNo,name,phone,address)Accounts(number,balance,type)Owns(custSSNo,accountNumber)Customers("ssNo",name,phone,address)Accounts("number",balance,type)Owns("custSSNo","accountNumber")d)Teams(name,captainName)Players(name,teamName)Fans(name,favoriteColor)Colors(colorname)For Displays association,TeamColors(teamName,colorname)RootsFor(fanName,teamName)Admires(fanName,playerName)Teams("name",captainName)Players("name",teamName)Fans("name",favoriteColor)Colors("colorname")For Displays association,TeamColors("teamName","colorname")RootsFor("fanName","teamName")Admires("fanName","playerName")e)People(ssNo,name,fatherSSNo,motherSSNo)People("ssNo",name,fatherssNo,motherssNo)f)Students(email,name)Courses(no,section,semester,professorEmail)Departments(name)Professors(email,name,worksDeptName)Takes(letterGrade,studentEmail,courseNo,courseSection,courseSemester)Students("email",name)Courses("no","section","semester",professorEmail)Departments("name")Professors("email",name,worksDeptName)Takes(letterGrade,"studentEmail","courseNo","courseSection","courseSemester")4.8.3a)Each and every object is a member of exactly one subclass at leaf level. We have nine classes at the leaf of hierarchy. Hence we need nine relations.b)All objects only belong to one subclass and its ancestors. Hence, we need not consider every possible subtree but rather the total number of nodes in tree. Hence we need thirteen relations.c)We need all possible subtrees. Hence 218 relations are required.class Customer (key (ssNo)){attribute integer ssNo;attribute string name;attribute string addr;attribute string phone;relationship Set<Account> ownsAcctsinverse Account::ownedBy;};class Account (key (number)){attribute integer number;attribute string type;attribute real balance;relationship Set<Customer> ownedByinverse Customer::ownsAccts;};4.9.2a)Modify class Account to contain relationship Customer ownedBy (no Set)b)Also remove set in relationship ownsAccts of class Customer.c)ODL allows a collection of primitive types as well as structures. To class Customer add following attributes in place of simple attributes addr and phone: Set<string phone>Set<Struct addr{string street,string city,string state}>d)ODL allows structures and collections recursively.Set<Struct addr{string street,string city,string state},Set<string phone>>Collections are allowed in ODL. Hence, Colors Set can become an attribute of Teams.class Colors(key(colorname)){attribute string colorname;relationship Set<Fans> FavoredByinverse Fans::Favors;relationship set<Teams> DisplayedByinverse Teams::Displays;};class Teams(key(name)){attribute string name;relationship set<Colors> Displaysinverse Colors::DisplayedBy;relationship set<Players> PlayedByinverse Players::Plays;relationship PLayers CaptainedByinverse Platyers::Captains;relationship set<Fans> RootedByinverse Fans::Roots;};class Players(key(name)){attribute string name;relationship Set<Teams> Playsinverse Teams::PlayedBy;relationship Teams Captainsinverse Teams::CaptainedBy;relationship Set<Fans> AdmiredByinverse Fans::Admires;};class Fans(key(name)){attribute string name;relationship Colors Favorsinverse Colors::FavoredBy;relationship Set<Teams> RootedByinverse Teams::Roots;relationship Set<Players> Admiresinverse Players::AdmiredBy;};4.9.4class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};4.9.5The struct education{string degree,string school,string date} cannot have duplication.Hence use of Sets does not make any different as compared to bags, lists, or arrays.Lists will allow faster access/queries due to the already sorted nature.4.9.6a)class Departments(key (name)) {attribute string name;relationship Courses offersinverse Courses::offeredBy;};class Courses(key (number,offeredBy)) {attribute string number;relationship Departments offeredByinverse Departments::offers;};b)class Leagues (key (name)) {attribute name;relationship Teams containsinverse Teams::belongs;};class Teams(key (name,belongs)) {attribute name,relationship Leagues belongsinverse Leagues::contains;relationship Players playinverse Players::plays;};class Players (key(number,plays)) {attribute number,relationship Teams playsinverse Teams::play;4.9.7class Students (key email) {attribute string email;attribute string name;relationship Courses isTAinverse Courses::TA;relationship Courses Takesinverse Courses::TakenBy;};class Professors (key email) {attribute string email;attribute string name;relationship Departments WorksForinverse Department::Works;relationship Courses Teachesinverse Courses::TaughtBy;};class Courses (key (no,semester,section)) {attribute string no;attribute string semester;attribute string section;relationship Students TAinverse Students::isTA;relationship Students TakenByinverse Students::Takes;relationship Professors TaughtByinverse Professors::Teaches;relationship Departments OfferedByinverse Departments::Offer;};class Departments (key name) {attribute name;relationship Courses Offerinverse Courses::OfferedBy;relationship Professors Worksinverse Professors::WorksFor;};4.9.8A relationship is its own inverse when for every attribute pair in the relationship, the inverse pair also exists. A relation with such a relationship is called symmetric in set theory. e.g. A relationship called SiblingOf in Person relation is its own inverse.4.10.1a)Customers(ssNo,name,addr,phone)Account(number,type,balance)Owns(ssNo,accountNumber)b)Accounts(number,balance,type,owningCustomerssNo)Customers(ssNo,name)Addresses(ownerssNo,street,state,city)Phones(ownerssNo,street,state,city,phonearea,phoneno)We can remove Addresses relation since its attributes are a subset of relation Phones.c)Fans(name,colors)RootedBy(fan_name,teamname)Admires(fan_name,playername)Players(name,teamname,is_captain)Teams(name)--remove subset of teamcolorTeamcolors(name,colorname)Colors(colorname)d)class Person {attribute string name;relationship Person motherOfinverse Person::childrenOfFemale;relationship Person fatherOfinverse Person::childrenOfMale;relationship Set<Person> childreninverse Person::parentsOf;relationship Set<Person> childrenOfFemaleinverse Person::motherOf;relationship Set<Person> childrenOfMaleinverse Person::fatherOf;relationship Set<Person> parentsOfinverse Person::children;};Person(name,mothername,fathername)The children relationship is many-many but the information can be deduced from Person relation. Hence below relation is redundant.Parent-Child(parent, child)4.10.2First consider each struct as if it were an atomic value i.e. key and value association pairs can be treated as two attributes. After applying normalization, the attributes can be replaced by the fields of the structs.4.10.3(a)Struct Card { string rank, string suit };(b)class Hand {attribute Set theHand;};(c)Hands(handId, rank, suit)Each tuple corresponds to one card of a hand. HandId is required key to identify a hand.class PokerHand{attribute Array Hand(Card card1,Card card2,Card card3,Cardcard4,Card card5)}PokerHandS(handId,rank1,suit1,,rank2,suit2,rank3,suit3,rank4,suit4,rank5,suit5) (e)class Deal {attribute Set <Struct PlayerHand { string Player, Hand theHand } > theDeal;}(f) PokerDeal consist of a player and array of five card deal.class PokerDeal{string Player,attribute Array Hand(Card card1,Card card2,Cardcard3,Card card4,Card card5)}(g) Above can similarly be represented by key player and a value consisting of five element array.(h)dealID is a key for Deals. Thus the relations for classes Deals and Hands are:Deals(dealID, player, handID)Hands(handID, rank, suit)A simpler relation Deals below can also represents the classes:Deals(dealID, player, rank, suit)(i)The relation Deals(dealID,card) cannot identify the hand to which a card belongs. Also two attributes are required for a card;its rank and suit.Deals(dealID, handID, rank, suit)4.10.4(a)C(a, f, g)(b)C(a, f, g, count)(c)C(a, f, g, position)(d)C(a, f, g, i, j)。

Oracle11g数据库管理与开发基础教程课后习题及答案

Oracle11g数据库管理与开发基础教程课后习题及答案第⼀章选择题1、Oracle数据库服务器包含的两个主要组件是（AB）A、Oracle实例B、oracle数据库C、内存结构D、后台进程2、create database 创建Oracle数据库时创建的⽂件包括（AC）A、数据⽂件B、控制⽂件C、⽇志⽂件D、初始化参数⽂件3、创建Oracle数据库时，createdatabase语句中指出了需要创建的数据⽂件、⽇志⽂件存储路径和名称，但没有指出需要创建的控制⽂件，因此创建数据库之前需要创建（D）个控制⽂件。

A、0B、1C、2D、任意数量4、调⽤shutdown命令关闭Oracle数据库后，以下（D）命令关闭的数据库处于不⼀致状态。

A、shutdown normalB、shutdown transactionalC、shutdown immediateD、shutdown abort5、作为普通⽤户，只有当数据库处于以下（C）状态下才可连接访问。

A、NUMOUNTB、MOUNTC、OPEND、CLOSE填空题1、SGA可分为以下⼏种主要区域：（SGA固定）、（数据库缓冲区缓存）、（重做⽇志缓冲区）、（共享池）等。

2、Oracle实例有多种后台进程，其中每个数据库实例上必须启动的后台进程包括（数据库写⼊进程）、（⽇志写⼊进程）、（检查点进程）、（进程监视进程）、（系统监视进程）等。

3、Oracle数据库的逻辑存储结构是（表空间）、（段）、（区）、（数据块）等。

4、Oracle数据库逻辑上的表空间结构与磁盘上的物理（数据）⽂件相关联。

5、下⾯连接字符串采⽤的是（简易连接）命名⽅式。

CONNECT Scott/tiger@dbs:1525@/doc/727db4ff03768e9951e79b89680203d8ce2f6aac.html编程题1.写出以下操作的SQL*PLUS命令语句：先启动Oracle实例到“已启动实例状态”，再修改Oracle实例到“数据库已装载状态”，最后修改Oracle实例到打开状态。

数据库课后答案71737

数据库课后答案71737(总95页)--本页仅作为文档封面，使用时请直接删除即可----内页可以根据需求调整合适字体及大小--目录第1部分课程的教与学第2部分各章习题解答及自测题第1章数据库概论基本内容分析教材中习题1的解答自测题自测题答案第2章关系模型和关系运算理论基本内容分析教材中习题2的解答自测题自测题答案第3章关系数据库语言SQL基本内容分析教材中习题3的解答自测题自测题答案第4章关系数据库的规范化设计基本内容分析教材中习题4的解答自测题自测题答案第5章数据库设计与ER模型基本内容分析教材中习题5的解答自测题自测题答案第6章数据库的存储结构基本内容分析教材中习题6的解答第7章系统实现技术基本内容分析教材中习题7的解答自测题自测题答案第8章对象数据库系统基本内容分析教材中习题8的解答自测题自测题答案第9章分布式数据库系统基本内容分析教材中习题9的解答自测题自测题答案第10章中间件技术基本内容分析教材中习题10的解答自测题及答案第11章数据库与WWW基本内容分析教材中习题11的解答第12章 XML技术基本内容分析教材中习题12的解答第2部分各章习题解答及自测题第1章数据库概论基本内容分析本章的重要概念（1）DB、DBMS和DBS的定义（2）数据管理技术的发展阶段人工管理阶段、文件系统阶段、数据库系统阶段和高级数据库技术阶段等各阶段的特点。

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

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

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

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

（7）DBSDBS的组成，DBA，DBS的全局结构，DBS结构的分类。

数据库系统基础教程_[全文]

第一章数据库系统的世界The Worlds of Database Systems数据库系统的发展数据库管理系统的结构未来的数据库系统*§1.1 数据库系统的发展c一、术语1.数据库是长期储存在计算机内的、有组织的、可共享的数据的集合。

*2.数据库管理系统数据库系统基础教程A First Course in Database SystemsDBMS - DataBase Management System是处理数据库访问的软件。

提供数据库的用户接口。

DBMS的目的：提供一个可以方便地、有效地存取数据库信息的环境*3.数据库系统是指在计算机系统中引入数据库后的系统*数据库最终用户应用系统应用开发工具DBMS操作系统数据库管理员DBA数据库系统构成应用程序员*保存信息的两种不同方法：永久性的系统文件、数据库系统。

文件方式的问题：数据的冗余和不一致数据访问困难数据孤立完整性问题原子性问题并发访问异常安全性问题二、文件系统与数据库系统*数据库方法能较好地解决以上的问题数据的独立性有效地访问数据减少应用程序的开发时间数据的一致性和安全性统一的数据管理并发的数据访问三、为什么用数据库*几种模型：基于树的层次模型基于图的网状模型物理相关、无高级查询语言基于表的关系模型物理无关、支持高级查询语言，基于对象的面向对象模型OOOR四、数据库模型的发展定长记录*关系数据库系统属性元组*关查询语言SQL语言SELECT balanceFROM AccountsWHERE accountNO = 67890;关系数据库系统*DBMS的组成数据、元数据存储管理程序事务管理程序查询处理程序§1.2 数据库管理系统的结构数据元数据存储管理程序查询处理程序事务管理程序模式更新更新查询*数据、元数据关于数据结构的信息（关于数据的数据）索引（INDEX）DBMS的组成*存储管理程序文件管理程序缓冲区管理查程序DBMS的组成*查询处理程序查询优化磁盘访问，是查询的主要代价；索引是查询优化的利器DBMS的组成*事务管理程序事务：是用户定义的一个数据库操作序列事务的四个特性原子性A一致性C隔离性I持久性DDBMS的组成*客户-服务器程序体系结构浏览器-服务器体系结构DBMS的组成*客户-服务器程序体系结构浏览器-服务器体系结构§1.3 未来的数据库系统第二章数据库建模Database Modeling*数据库的设计步骤需求收集和分析设计概念结构设计逻辑结构设计物理结构物理实现*数据库的设计步骤需求收集和分析用户关心什么用户要什么结果设计概念结构设计逻辑结构设计物理结构物理实现*数据库的设计步骤需求收集和分析设计概念结构存什么关系（联系）如何ODL或E/R图，是各种数据模型的共同基础设计逻辑结构设计物理结构物理实现*数据库的设计步骤需求收集和分析设计概念结构设计逻辑结构用什么数据模型数据库的模式（database schema）用户子模式设计物理结构物理实现*数据库的设计步骤需求收集和分析设计概念结构设计逻辑结构设计物理结构数据怎么存根据DBMS产品、环境特点物理实现*数据库的设计步骤需求收集和分析设计概念结构设计逻辑结构设计物理结构物理实现运行DDL装入测试数据应用程序*数据库的设计步骤想法需求ODLE / R关系RDBMSOODBMS*§2.1 ODL对象定义语言Object Definition Language以面向对象的观点、方法，说明数据库的概念结构可方便地直接转换成OODBMS 的说明经过努力，可以转换成RDBMS 的说明*面向对象的设计对象标识—OID对象与对象的区别类具有相同特性的对象归为一类对象的归并必须有意义属于同一类的对象其特性必须相同*面向对象的设计对象的三个特性属性：特性联系：引用方法：函数接口说明interface < 名字> {< 特性表>}*属性对象某方面的特征，属性就是数据只由基本数据类型构成属性的类型，不能是类、也不能从类中构造Interface Movie { //Movie Class 的ODL说明attribute string title;attribute integer year;attribute integer length;attribute enum Film { color, blackAndWhite } filmType;};*Interface Star {attribute string name;attribute Struct Addr{ string street,string city } address;};记录结构类型*联系对象的引用对象的关联对象集合的引用（1:N）Relationship Set < Star > stars;单一对象集合的引用（1:1）Relationship Star starOf;*反向联系ODL要求显式表示存在的反向联系Interface Movie { //Movie Class 的ODL说明attribute string title;attribute integer year;attribute integer length;attribute enum Film { color, blackAndWhite } filmType;relationship Set < Star > starsinverse Star :: starredIn; //Star与Movie的联系};联系的多重性N:N在联系中，每个C都和D的集合有关，而在反向联系中，每个D都和C的集合有关N:1在联系中，每个C都和唯一的D有关，而在反向联系中，每个D都和C的集合有关1:1在联系中，每个C都和唯一的D有关，而在反向联系中，每个D都和唯一的C有关*Interface Moive{……relationship Set <Star> starsinverse Star :: staredIn;relationship Studio ownedByinverse Studio :: owns;};Interface Star{……relationship Set <Moive> staredIninverse Moive :: stars;};Interface Studio{……relationship Set <Moive> ownsinverse Moive :: ownedBy;};NNN1*ODL中的类型基本类型原子类型接口类型结构类型，可由以下类型组合而成集合无重复，次序无关包可重复，次序无关列表可重复，次序相关数组结构*§2.2 实体联系图（E/R）用图形的方法，描述实体及实体间的联系世界由一组称作实体的基本对象及这些对象间的联系组成元素实体（Entity）客观存在并可相互区别的事件或物体对应于ODL中的对象实体集（Entity Set）同类（具有相同类型、相同性质）实体的集合对应于ODL中的类用矩形表示*§2.2 实体联系图（E/R）元素属性（Attribute）实体所具有的某一特性用与实体集相连的椭圆表示联系（Relationship）实体集之间的关联可涉及多个实体集可表示双向的联系用与相应的实体集相连的菱形表示*MoviesStarsStars-inlenghtfilmTypetitleyearnameaddress*E/R联系的多重性N与1的表示MoviesStarsStars-inStudiosPresidentsRunsMoviesStudiosOwns*联系的多向性E/R图能方便地描述两个以上实体集间的联系StarsMoviesContractsStudios一个制片公司与一位特定的影星签约来演一部特定的电影*联系中的角色实体集在联系中的作用参与联系的实体集互异只标注联系名同一实体集在一个联系中多次出现标注联系名及角色名Sequel-ofMoviesOriginalSequelStarsMoviesContractsStudiosStudio of starProducing studio*联系中的属性联系中可以包含属性由联系而产生的属性可为由联系产生的属性建立实体集StarsMoviesContractsStudiossalary*将多向联系转换成二元联系新增连接实体集引入连接实体集至原实体集的多对一的联系*§2.3 设计原则真实性设计应当忠于规范存什么避免冗余任何事物只表达一次避免引入过多的元素选择合适的元素类型属性？类/实体集？联系集？*§2.4 子类特殊化与概括子类与超类属性的继承*ODL中的子类子类继承其超类的所有特性属性联系Interface Cartoon : Movie {relationship set < Star > voices;}*ODL中的多重继承类的层次一个类可以有多个超类Interface MurderMystery : Movie{attribute string weapon;}Interface Cartoon-MurderMystery : Cartoon,MurderMystery { }*E/R中的子类IsaE/R中的继承*§2.5 对约束的建模建模包含对现实世界的对象及联系的描述，也包含对它们的一些约束键码单值约束参照完整性约束域的约束一般约束*键码在类的范围内唯一标识一个对象（或者在实体集的范围内唯一标识一个实体）的属性或属性集一个类中的两个对象（或一个实体集中的两个实体）在构成键码的属性集上取值不能相同ODL中键码的表示interface Movie( key (title,year) ) {……}*超码一个或多个属性的集合，能在一个实体集中唯一地标识一个实体一个类（或实体集）中可能有多个超码候选码其任意真子集都不为超码的超码一个类（或实体集）中可能有多个候选码主码从候选码中选取的一个，一个类（实体集）中只有一个主码E / R图中只能表示主码：主码属性名加上下划线*单值约束要求某个角色的值是唯一的，如键码当一个属性为单值时可以要求该属性值存在（not null）可以允许该属性值任选（null）构成键码的属性，必须有值存在（not null）*参照完整性约束要求由某个对象引用的值在数据库中确实存在参照与被参照、引用与被引用参照完整性约束的操作（各产品不同）禁止删除被引用的对象级联删除/ 修改E/R图中参照完整性的表示MoviesStudiosOwns*§2.6 弱实体集弱实体集的属性不足以形成主码有主码的实体集称为强实体集弱实体集只有作为一对多联系的一部分（多）才有意义弱实体集与其拥有者之间的联系是标识性联系CrewsUnit-ofStudiosnumbernameaddr*§2.7 关于联系集联系集的成份参加联系的实体集的主码联系集的属性联系中属性的决策(二元联系)1:1 联系集的属性：放到任意一端1:N 联系集的属性：放到N 端N:M联系集的属性：只能留在联系集中*联系集的取舍（二元联系）1:1联系：将一端的主码作为另一端的属性1:N联系：将一端的主码作为N 端的属性N:M联系：必须保留联系集联系集的键码（二元联系）1:1联系：任意一端的主码1:N联系：N端的主码N:M联系：参加联系的所有实体集的主码*ODL、E/R建模关心：存什么数据、关系如何不关心：用什么数学模型、DBMS产品透过E/R图，便于与用户交流*作业思考所有带*的练习，并上网查阅解答练习2.1.7 / 2.2.8 / 2.3.2 / 2.5.3 / 2.5.4 /2.6.4(a) 第三章关系数据模型The Relational Data Model*ODL、E/R到关系模型的转换关系模型的设计理论*§3.1 关系模型的基本概念逻辑数据模型是用户从数据库所看到的数据模型与DBMS有关层次、网状、关系、面向对象关系数据模型数据结构两维的扁平表数据操作关系代数关系演算数据的完整性实体完整性参照完整性用户定义的完整性*现实世界的实体以及实体间的各种联系均用关系表示关系数据库系统是建立在关系模型上的数据库系统关系数据库是表的集合*模型和模式数据模型是描述数据的手段数据模式是用给定的数据模型对具体数据的描述属性元组域型值联系关系的联系是通过关联属性的值连接的*SnoSnameSsexSagesdept95001张三男25CS95002李四女24CS96101王五23MA96001赵六男23CS关系( 表)属性(列、字段)元组(行、记录)域(string,{男，女})Student ( sno, sname, ssex, sage, sdept )*关系实例关系→实体集、类关系的实例→元组的集合元组→实体、对象数据库实例→给定时刻数据库中数据的一个快照*§3.2 从ODL设计到关系设计ODL设计是概念设计的产物( Using OO )ODL描述→关系模式→实现*ODL属性→关系属性原子属性类→关系属性→属性非原子属性（复杂数据类型）必须转换成原子属性记录结构结构的每个item对应一个属性多值集合针对每个值建立一个元组会产生冗余→需规范化*ODL属性→关系属性（续）其他类型属性（包、数组、列表）针对每个元素建立一个元组增加一个记数属性，表示包的成员号定长数组扩展为多个属性*ODL联系→关系描述单值联系联系的类型为一个类增加一个（组）属性，存放相关类的键码属性（组）将类之间的联系→关系之间的联系*ODL联系→关系描述（续）多值联系联系的类型为某个类的集合类型1 : N、N : M增加一个键码属性为集合的每个成员建立一个元组其他原始属性重复多次（与集合成员的个数相等）导致大量的冗余，需要规范化*键码是必需的选择合适的属性（组）作为键码学号、工号、身份证号…...增加计数属性联系与反向联系在联系的双方均有联系的描述→冗余ODL：双向描述E/R：相关的键码值进行连接*§3.3 从E/R图到关系的设计E/R与ODL描述的差异联系作为独立的概念←→联系嵌套在类定义中结构化数据←→允许使用集合、聚集类型联系可以有属性←→联系无属性E/R →关系模式→实现*实体集到关系的转换非弱实体集实体集名→关系名属性→属性弱实体集为弱实体集建立关系属性：弱实体集的属性+ 辅助实体集的键码*E/R联系到关系的转换用关系表示联系联系名→关系名属性→属性+ 相关实体集的键码属性（集）多向联系的转换注意，属性的命名*§3.4 子类结构到关系的转换ODL中的子类一个对象完全属于一个类子类继承其超类的特性E/R中的子类分层结构通过与ISA联系有关的实体集进行扩展*用关系表示ODL子类每个子类都有自己的关系包含该子类的所有特性（含继承特性）在一个关系中含有所有属性Movie(title,year,length,filmType,studioName,starName)Cartoon(title,year,length,filmType,studioName,starName,voice) MurderMystery(title,year,length,filmType,studioName,starName,weapon)Cartoon- MurderMystery(title,year,length,filmType,studioName,starName,voice, weapon)*在关系模型中表示isa 联系子类的信息被分散到上层的几个关系中与ISA联系有关的实体集拥有相同的键码Movie(title,year,length,filmType)Cartoon(title,year)MurderMystery(title,year, weapon)Voice(title,year,name)*使用NULL值合并关系将关系描述成一个‘全集’属性：所有可能的属性描述：允许Null值层次越高，取Null值的属性越多Movie (title,year,length,filmType,studioName,starName,voice, weapon) 只是一种方法而已*作业思考所有带*的练习，并上网查询解答练习3.2.3 / 3.3.1 / 3.4.1 / 3.5.3 /*§3.5 函数依赖数据依赖函数依赖多值依赖数据依赖是针对数据模式，而不是特定的实例*函数依赖（FD）属性之间的联系假设给定X 属性的值，就知道Y的值，那么X 函数决定Y如果R的两个元组在属性A1,A2,…,An上一致，则它们在另一个属性B上也一致，那么A1,A2,…,An函数决定B，记作A1A2…An→Bif A1A2…An→B1 thenA1A2…An→B2 A1A2…An→B1 B2 ... Bm……A1A2…An→Bm*关系的键码如果一个或多个属性的集合{A1A2…An}满足如下条件，则该集合为关系R的键码：1.这些属性函数决定该关系的所有其他属性2. {A1A2…An}的任何真子集都不能函数决定R的所有其他属性*超键码包含键码的属性集称为超键码*寻找关系的键码（来自E/R）来自实体集的关系的键码就是该实体集的键码属性对于二元联系R：N：M，相关两个实体的键码都是R的键码属性N：1，多端实体集的键码是R的加码属性1：1，任意一端实体集的键码是R的键码对于多向联系R：如果多向联系R有一个箭头指向实体集E，则响应的关系中，除了E的键码以外，至少还存在一个键码。

数据库系统概论(第4版)第四章到十一章习题答案

第四章习题习题1．什么是数据库的安全性？答：数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏。

2．数据库的安全性和计算机系统的安全性有什么关系？答：安全性问题不是数据库系统所独有的，所有计算机系统都有这个问题。

只是在数据库系统中大量数据集中存放，而且为许多最终用户直接共享，从而使安全性问题更为突出。

数据库的安全性和计算机系统的安全性，包括操作系统、网络系统的安全性是紧密XXX、相互支持的。

5．试述实现数据库安全性控制的常用方法和技术。

答：（1）用户标识和鉴别：该方法是由系统提供一定的方式让用户标识自己的名字和身份。

每次用户要求进入系统时，由系统进行核对，通过鉴定后才能提供系统的使用权。

（2）存取控制：通过用户权限定义和合法权检查确保只有合法权限的用户访问数据库，所有未被授权的人员无法存取数据。

例如C2级中的自主存取控制（DAC），B1级中的强制存取控制（MAC）。

（3）视图机制：为不同的用户定义不同的视图，把数据对象限制在一定的范围内，通过视图机制把要保密的数据对无权存取的用户隐藏起来，从而自动地对数据提供一定程度的安全保护。

（4）审计：建立审计日志，把用户对数据库的所有操作自动记录在审计日志中。

DBA可以利用审计跟踪的信息，重现导致数据库现有状况的一系列事件，找出非法存取数据的人、时间和内容等。

（5）数据加密：对存储和传输的数据进行加密处理，从而使得不知道解密算法的人无法获知数据的内容。

6．什么是数据库中的自主存取控制方法和强制存取控制方法？答：自主存取控制方法：定义各个用户对不同数据对象的存取权限。

当用户对数据库访问时首先检查用户的存取权限。

防止不合法用户对数据库的存取。

强制存取控制方法：每一个数据对象被（强制地）标以一定的密级，每一个用户也被（强制地）授予某一级别的许可证。

系统规定只有具有某一许可证级别的用户才能存取某一个密级的数据对象。

7．SQL语言中提供了哪些数据控制（自主存取控制）的语句？请试举几例说明它们的使用方法。

数据库系统教程课后习题答案(部分)--何玉洁李宝安

第一部分基础理论第1章数据库概述1．试说明数据、数据库、数据库管理系统和数据库系统的概念。

数据：描述事务的符号记录数据库：存储数据的仓库数据库管理系统：用于管理和维护数据的系统软件数据库系统：计算机中引入数据库后的系统，包括数据库，数据库管理系统，应用程序，数据库管理员2．数据管理技术的发展主要经历了哪几个阶段？两个阶段，文件管理和数据库管理9．数据独立性指的是什么？应用程序不因数据的物理表示方式和访问技术改变而改变，分为逻辑独立性和物理独立性。

物理独立性是指当数据的存储结构或存储位置发生变化时，不影响应用程序的特性；逻辑独立性是指当表达现实世界的信息内容发生变化时，不影响应用程序的特性。

10．数据库系统由哪几部分组成？由数据库、数据库管理系统、应用程序、数据库管理员组成。

第2章数据模型与数据库系统的结构4．说明实体一联系模型中的实体、属性和联系的概念。

实体是具有公共性质的并可相互区分的现实世界对象的集合。

属性是实体所具有的特征或性质。

联系是实体之间的关联关系。

6．数据库系统包含哪三级模式？试分别说明每一级模式的作用。

外模式、模式和内模式。

外模式：是对现实系统中用户感兴趣的整体数据结构的局部描述，用于满足不同用户对数据的需求，保证数据安全。

模式：是数据库中全体数据的逻辑结构和特征的描述，它满足所有用户对数据的需求。

内模式：是对整个数据库的底层表示，它描述了数据的存储结构。

7．数据库管理系统提供的两级映像的作用是什么？它带来了哪些功能？两级映像是外模式/模式映像和模式/内模式映像。

外模式/模式映像保证了当模式发生变化时可以保证外模式不变，从而使用户的应用程序不需要修改，保证了程序与数据的逻辑独立性。

模式/内模式映像保证了当内模式发生变化，比如存储位置或存储文件名改变，可以保持模式不变，保证了程序与数据的物理独立性。

两级印象保证了应用程序的稳定性。

第3章关系数据库1．试述关系模型的三个组成部分。

数据结构、关系操作集合、关系完整性约束2．解释下列术语的含义：(3)候选码当一个属性或属性集的值能够唯一标识一个关系的元组，而又不包含多余的元素，则称该属性或属性集为候选码。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

Section 1 Exercise 11.1.1 a)Exercise 11.1.3Exercise 11.1.5In the semistructured model, nodes represent data elements, i.e., entities rather than entity sets. In the UML model, nodes of all types represent object sets, and the data is not represented at all. Section 2Exercise 11.2.1<? xml version = "1.0" encoding = "utf-8" standalone = "yes" ?><StarMovieData><Star starID = "cf" starredIn = "sw"><Name>Carrie Fisher</Name><Address><Street>123 Maple St.</Street><City>Hollywood</City></Address><Address><Street>5 Locust Ln.</Stree><City>Malibu</City></Address></Star><Star starID = "mh" starredIn = "sw"><Name>Mark Hamill</Name><Address><Street>456 Oak Rd.</Street><City>Brentwood</City></Address></Star><Movie movieID = "sw" starsOf = "cf mh"><Title>Star Wars</Title><Year>1977</Year></Movie></StarMovieData>Exercise 11.2.2Title Year Length Genre1939 231 Drama Gone with theWindStar Wars 1977 124 SciFi Wayne’s World1992 95 ComedyFigure 2.3: The Relation MoviesThe relation Movies in XML:<Movies><Movie><Title>Gone with the Wing</title><Year>1939</year><Length>231</length><Genre>Drama</genre></Movie><Movie><Title>Star Wars</Title><Year>1977</year><Length>124</length><Genre>SciFi</genre></Movie><Movie><Title>Wayne’s World</Title><Year>1992</year><Length>95</length><Genre>Comedy</genre></Movie></Movies>Exercise 11.2.3An empty element can be represented as a SubElement whose childID value is null (or a prede-fined ID that does not map to any element).Exercise 11.2.4DocRoot(docID, rootElementID)Element(elementID, position)ElementAttribute(elementID, name, value)ElementValue(elementID, value)SubElementOf(parentID, childID)Section 3Exercise 11.3.1<?xml version = "1.0" encoding = "utf-8" standalone = "yes" ?><StarMovieData><Star starID = "cf" starredIn = "sw tesb rotj hahs"><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 tesb rotj"><Name>Mark Hamill</Name><Address><Street>456 Oak Rd.</Street><City>Brentwood</City></Address></Star><Star starID = "hf" starredIn = "sw tesb rotj fw"><Name>Harrison Ford</Name></Star><Star starid = "md" starredIn = "tbi"><Name>Matt Damon</Name></Star><Movie movieID = "sw" starsOf = "cf mh hf"><Title>Star Wars</Title><Year>1977</Year></Movie><Movie movieID = "tesb" starsOf = "cf mh hf"><Title>The Empire Strikes Back</Title><Year>1980</Year></Movie><Movie movieID = "rotj" starsOf = "cf mh hf"><Title>Return of the Jedi</Title><Year>1983</Year></Movie><Movie movieID = "fw" starsOf = "hf"><Title>Firewall</Title><Year>2006</Year></Movie><Movie movieID = "hahs" starsOf = "cf"><Title>Hannah and Her Sisters</Title><Year>1985</Year></Movie><Movie movieID = "tbi" starsOf = "md"><Title>The Bourne Identity</Title><Year>2002</Year></Movie></StarMovieData>Exercise 11.3.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)>]>Exercise 11.3.3<!DOCTYPE Sport [<!ELEMENT SPORT(TEAM*, FAN*)><!ELEMENT TEAM(NAME, PLAYER+, COLOR+)><!ATTLIST TEAMcaptain IDREF #REQUIREDteamID ID #REQUIRED><!ELEMENT PLAYER(NAME)><ATTLIST PLAYERplayerID ID #REQUIRED><!ELEMENT FAN(NAME, COLOR*)><ATTLIST FANfavoriteTeams IDREFSfavoritePlayers IDREFS><!ELEMENT COLOR (#PCDATA)><!ELEMENT NAME (#PCDATA)>]>Exercise 11.3.4<!DOCTYPE Genealogy [<!ELEMENT GENEALOGY(PERSON*)><!ELEMENT PERSON EMPTY><ATTLIST PERSONname CDATA #REQUIREDpersonID ID #REQUIREDmotherID IDREFfatherID IDREFchildrenID IDREFS>]>Exercise 11.3.5Relation schema: RELATIONNAME(attribute list)<!DOCTYPE RELATIONNAME [<!ELEMENT RELATIONNAME(ROW*)><!ELEMENT ROW(attribute list)>for each attribute T in the attribute list<!ELEMENT T (#PCDATA)>]note: the singular form of the relation name should used in place of ROWSection 4Exercise 11.4.1<Movies><Movie><Title>Star Wars</Title><Year>1977</Year></Movie></Movies><Movies><Movie><Title>Star Wars</Title><Year>’77</Year> </Movie></Movies>Exercise 11.4.2<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="/2001/XMLSchema"><xs:complexType name="Movies"><xs:sequence><xs:element name="Movie" minOccurs="0" maxOccurs="unbounded"> <xs:complexType><xs:sequence><xs:element name="Title" type="xs:string" /><xs:element name="Year" type="xs:integer" /></xs:sequence></xs:complexType></xs:element></xs:sequence></xs:complexType></xs:schema>Exercise 11.4.3<!DOCTYPE MOVIES [<!ELEMENT Title (#PCDATA)><!ELEMENT Year (#PCDATA)><!ELEMENT Genre (#PCDATA)><!ELEMENT Movies (Movie*)><!ELEMENT Movie (Title, Year, Genre?)>]><!DOCTYPE STARS [<!ELEMENT Stars (Star+)><!ELEMENT Star (Name, Address, StarredIn*)><!ELEMENT Name (#PCDATA)><!ELEMENT Address (#PCDATA)><!ELEMENT StarredIn EMPTY><!ATTLIST StarredIntitle CDATA #IMPLIEDyear CDATA #IMPLIED>]>Note: DTD is not as granular as XML schema; some restrictions in XML schema cannot be en-forced in DTD without modifying the structures of the XML it defines.。