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

1.试述事务的概念及事务的4 个特性。
答:事务是用户定义的一个数据库操作序列,这些操作要么全做要么全不做,是一个不可分割的工作单位。
事务具有 4 个特性:原子性(Atomicity )、一致性(consistency )、隔离性( Isolation )和持续性(Durability )。
这4 个特性也简称为ACID 特性。
原子性:事务是数据库的逻辑工作单位,事务中包括的诸操作要么都做,要么都不做。
一致性:事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
隔离性:一个事务的执行不能被其他事务干扰。
即一个事务内部的操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能互相干扰。
持续性:持续性也称永久性(Perfnanence ) ,指一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。
接下来的其他操作或故障不应该对其执行结果有任何影响。
2 .为什么事务非正常结束时会影响数据库数据的正确性,请列举一例说明之。
答:事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
如果数据库系统运行中发生故障,有些事务尚未完成就被迫中断,这些未完成事务对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于一种不正确的状态,或者说是不一致的状态。
例如某工厂的库存管理系统中,要把数量为Q 的某种零件从仓库1移到仓库2 存放。
则可以定义一个事务T , T 包括两个操作;Ql = Ql 一Q , Q2= Q2 + Q。
如果T 非正常终止时只做了第一个操作,则数据库就处于不一致性状态,库存量无缘无故少了Q 。
3 .数据库中为什么要有恢复子系统?它的功能是什么?答:因为计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏是不可避免的,这些故障轻则造成运行事务非正常中断,影响数据库中数据的正确性,重则破坏数据库,使数据库中全部或部分数据丢失,因此必须要有恢复子系统。
恢复子系统的功能是:把数据库从错误状态恢复到某一已知的正确状态(亦称为一致状态或完整状态)。
数据库系统基础教程课后答案

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实例到打开状态。
数据库系统原理教程课后习题及答案(第十章)

第11章并发控制1 .在数据库中为什么要并发控制?答:数据库是共享资源,通常有许多个事务同时在运行。
当多个事务并发地存取数据库时就会产生同时读取和/或修改同一数据的情况。
若对并发操作不加控制就可能会存取和存储不正确的数据,破坏数据库的一致性。
所以数据库管理系统必须提供并发控制机制。
2 .并发操作可能会产生哪几类数据不一致?用什么方法能避免各种不一致的情况?答:并发操作带来的数据不一致性包括三类:丢失修改、不可重复读和读“脏’夕数据。
( l )丢失修改(lost update ) 两个事务 Tl 和T2读入同一数据并修改,T2提交的结果破坏了(覆盖了) Tl 提交的结果,导致Tl 的修改被丢失。
( 2 )不可重复读( Non 一 Repeatable Read ) 不可重复读是指事务 Tl 读取数据后,事务几执行更新操作,使 Tl 无法再现前一次读取结果。
( 3 )读“脏”数据( Dirty Read ) 读“脏’夕数据是指事务 Tl 修改某一数据,并将其写回磁盘,事务几读取同一数据后, Tl 由于某种原因被撤销,这时 Tl 已修改过的数据恢复原值,几读到的数据就与数据库中的数据不一致,则几读到的数据就为“脏”数据,即不正确的数据。
避免不一致性的方法和技术就是并发控制。
最常用的技术是封锁技术。
也可以用其他技术,例如在分布式数据库系统中可以采用时间戳方法来进行并发控制。
3 .什么是封锁?基本的封锁类型有几种?试述它们的含义。
答:封锁就是事务 T 在对某个数据对象例如表、记录等操作之前,先向系统发出请求,对其加锁。
加锁后事务 T 就对该数据对象有了一定的控制,在事务 T 释放它的锁之前,其他的事务不能更新此数据对象。
封锁是实现并发控制的一个非常重要的技术。
基本的封锁类型有两种:排它锁( Exclusive Locks ,简称 x 锁)和共享锁 ( Share Locks,简称 S 锁)。
排它锁又称为写锁。
Oracle10g数据库基础教程第三版答案

Oracle10g数据库基础教程第三版答案Oracle数据库是一个以数据为中心的数据库系统,它提供了一种按需要和按层次结构进行分层存储的多层数据库结构。
它能够提供对所有类型的数据进行存储、查询和处理的能力,是集众多优势于一身的分布式系统。
数据库包括哪些数据呢?1.文件:如目录;2.表:例如商品名称或条形码;3.日志记录:如电子邮件、日志和系统报告,如故障定位等等。
它分为以下几种类型:1)关系型(cross-priority):是由一组数据组成,每个数据都是唯一的,与其他信息互不干扰,能够满足数据一致性要求;2)非连续性(practice):是指数据库的某个部分连续进行工作,不受中断发生时间影响;3)按类存储空间(data storage):通常称为非连续性存储空间或不定存储空间;4)按应用程序定义(Application Regulations):是系统实现不同功能或扩展应用程序所需的接口。
具体是指在数据库环境中,通过使用各种类型的软件而建立一个能满足数据库系统各功能之间互操作需求、同时又满足不同用户需要的网络和存储环境。
如 Oracle系统中有一套专门用于保存有关数据库操作及其所有处理过程的数据库文件系统,这种软件称为Oracle Exchange。
1.如果使用 Java语言,我们应该如何使用数据库程序?Java是面向对象程序语言。
Java语言具有很强的可移植性,对于数据处理类,可以使用通用的函数,而对于数据表示类不需要使用函数,例如,数据表达类就是通过与字节表的耦合获取字节表,也可以通过变量的映射来获取字节表。
在 Java编程中, Java的许多表达式都具有相似的实现特性:如 JSON方法(可以通过引用将函数映射到已有表达式); Java函数和非Java函数间的隔离;使用非整数运算符等。
在应用程序或系统设计阶段时,应用程序或系统设计就是要将数据输入到应用程序或系统中来,实现对数据以及整个系统的控制、协调和管理。
Oracle-10g数据库基础教程-参考答案资料

Oracle数据库基础教程参考答案第1章Oracle数据库概述1.简答题(1)数据是描述事物的符号,是数据库中存储的基本对象。
在计算机中,用记录的形式来描述数据。
数据与数据的解释即数据的语义是紧密结合的。
数据库是指按一定的数据模型组织、描述和存储的数据的集合。
数据库管理系统是位于操作系统与用户之间的一层数据管理软件。
数据库系统是指数据库、数据库管理系统与计算机系统的结合。
通常,在不引起混淆的情况下将数据库系统简称为数据库。
(2)数据库管理系统的主要功能包括:数据定义、数据操纵、数据库运行与控制、数据库建立与维护、数据字典定义以及数据通信等。
数据库管理系统的内部分多个层次,由应用层、语言定义及其翻译处理层、数据存取层、数据存储层、操作系统以及数据库组成。
(3)数据库系统由数据库、操作系统、数据库管理系统、开发工具、应用系统、数据库管理员以及数据库用户组成。
(4)概念模型是用简单、清晰、用户易于理解的概念来描述现实世界具体事物及事物之间的关系。
它是现实世界到信息世界的抽象,是数据库设计人员进行数据库设计的工具,与具体的数据库管理系统无关。
组织数据模型是从数据组织方式的角度来描述信息,它决定了数据在数据库中的组织结构。
(5)E-R图由3个要素组成:实体、联系与属性。
实体之间的联系有1:1、1:n、n:n三种类型。
(6)Oracle之所以得到广大用户的青睐,其主要原因在于:支持多用户、大事务量的事务处理、提供标准操作接口、实施安全性控制和完整性控制、支持分布式数据处理、具有可移值性、可兼容性和可连接性。
(7)目前市场上常见的关系数据库管理系统包括Oracle、DB2、Sybase和SQL Server等。
Oracle是当今最大的数据库厂商Oracle公司的数据库产品。
它是世界上第一个商品化的关系型数据库管理系统,也是第一个推出与数据库结合的第四代语言开发工具的数据库产品。
DB2是IBM公司于1983年推出的一个商业化关系数据库管理系统,它是基于System R 基础上实现的。
第10章面向对象数据库-PPT精选文档

Ô Ï ¶ ó B
ô Ð Ê Ô 1 ¡ ¡ ô Ð Ê Ô r ½ · · ¨1 ¡ ¡ ½ · · ¨s
14
10.1 对象与类
10.1.3 类
类(Class)是对具有共同属性和方法的对象全体的 概括描述,它相当于关系模型中的关系模式。类给出 了属于其全部对象属性与行为的抽象定义,类中对象 仅是类定义中的一个实体,即对象实例。学生是一个 类,一个具体学生,例如John就是学生类中一个对象 实例。与关系模型需要首先描述关系模式类似,对象 模型也首先需要抽象描述具有共同属性的对象的类, 按照类来定义属性和方法,从而避免对每个对象一一 重复定义。查询操作等方法也定义在类上。
6
10.1 对象与类
10.1.1 对象
对象具有封装性、隐蔽性与稳定性等重要特性。 (1)封装性 封装(encapsulation)是使对象的外 部界面与内部实现之间实行清晰隔离的一种技术,是 OO模型的主要特征之一。封装使得用户只能看到对 象外在的界面信息(正如规格说明等),而看不到对 象内部的信息(如方法实现细节),对象内部信息对 于用户是屏蔽的。封装的意义首先在于安全性保证, 其次在于相关模块的可扩展性。
12
10.1 对象与类
10.1.2 消息
例 设一个对象A要求对象B完成其中的某种操作,则 只需向对象B发送一个消息即可。B接收到这个消息后, 根据消息模式找到与之匹配的方法,执行该方法后将 执行的结果又以消息的形式发送给对象A。
13
10.1 对象与类
10.1.2 消息
Ô Ï ¶ ó A
ô Ð Ê Ô 1 ¡ ¡ ô Ð Ê Ô n ½ · · ¨1 ¡ ¡ ½ · · ¨m á ¹ ½ û Ï û Ï ¢ ÷Ó µ Ã Ï û Ï ¢
数据库系统基础教程答案

a)
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.
d)
In d we assume that an address can only belong to one customer and a phone can exist at only one address.
If the multiplicity of above relationships were m-to-n, the entity set becomes weak and the key ssNo of customers will be needed as partof the composite key of the entity set.
4.2.7
In below figure there exists a many-to-one relationship between Babies and Births and another many-to-one relationship between Births andMothers. From transitivity of relationships, there is a many-to-one relationship between Babies and Mothers. Hence a baby has a uniquemother while a birth can allow more than one baby.
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Section 10.1
Exercise 10.1.1
(a) SELECT on MovieStar, SELECT on MovieExec. (b) SELECT on MovieExec, SELECT on Movies, SELECT on StarsIn. (c) SELECT on Movies, SELECT on Studio, INSERT on Studio (or INSERT(name)
Another way would be to start FollowOn tuples only from the tuples of movies that have more than two sequels (using a join similar to the one above but with three Sequel tables).
WITH RECURSIVE FollowOn(movLECT movie, sequel
FROM SequelOf
)
UNION
(SELECT F.movie, S.sequel
FROM FollowOn F, Sequel S
WHERE F.followOn = S.movie)
6
(d) One of the ways is to ?rst get all of the recursive tuples as for the original FollowOn in (a), and then subtract the those tuples that represent sequel or sequel of a sequel. Using the book ’ssyntax, the SQL would be:
9
WHERE mult = ’ single ’)
UNION
(SELECT PathSingle.class,
Rel.rclass
FROM PathSingle, Rel
WHERE PathSingle.rclass
= Rel.class
AND Rel.mult = ’ single ’
)
SELECT class, rclass
(e) We simply need to count the number of followon values per movie. Using the book ’ssyntax, the SQL would be:
WITH RECURSIVE FollowOn(movie, followOn) AS
<> Rel.mult
SELECT *
FROM Path;
mult) AS Rel.mult )
(f) WITH RECURSIVE Path(class, rclass) AS (SELECT class, rclass FROM Rel WHERE mult = ’ single ’) UNION (SELECT Path.class, Rel.rclass FROM Path, Rel WHERE Path.rclass = Rel.class AND Rel.mult = ’ single ’ )
After step (4), the grant diagram is as follows:
A
B
p
p
??
?
-
E p
?
?
C p ?
After step (5), the grant diagram is as follows:
A
B
p
p
??
?
?
C p
After step (6), the grant diagram is as follows:
WITH RECURSIVE Path(class, rclass,
(SELECT class, rclass, mult
FROM Rel
)
UNION
(SELECT Path.class, Rel.rclass,
FROM Path, Rel
WHERE Path.rclass
= Rel.class
AND Path.mult
FROM PathAll
EXCEPT
SELECT class, rclass
FROM PathSingle
;
(e) We include the edge label as part of the recursive relation and then, basically, we build the path as in (a) except we only add edges that have an opposite label.
FROM FollowOn F, Sequel S
WHERE F.followOn = S.movie)
SELECT movie, followOn
FROM FollowOn
EXCEPT
SELECT movie, sequel
FROM SequelOf;
(Similarly, NOT IN or NOT EXISTS can be used instead of EXCEPT).
(SELECT class, rclass
FROM Rel
)
UNION
(SELECT Path.class, Rel.rclass
FROM Path, Rel
WHERE Path.rclass = Rel.class)
SELECT *
FROM Path;
(b) WITH RECURSIVE Path(class, (SELECT class, rclass
WITH RECURSIVE FollowOn(movie, followOn) AS
(SELECT movie, sequel
FROM SequelOf
)
UNION
(SELECT F.movie, S.sequel
FROM FollowOn F, Sequel S
WHERE F.followOn = S.movie)
rclass) AS
8
FROM Rel WHERE mult = ’ single ’) UNION (SELECT Path.class, Rel.rclass FROM Path, Rel WHERE Path.rclass = Rel.class
AND Rel.mult = ’ single ’ ) SELECT * FROM Path;
Trips (x, y, dep , arr ) ← Flights (
Exercise 10.2.3
(a)
FollowOn (x, y ) ← SequelOf (x, y) FollowOn (x, y ) ← FollowOn (x , z) AND
SequelOf (z, y)
(b) Using the book ’ssyntax, the SQL is:
SELECT * FROM Path;
(d) This could be viewed as relation from (a) EXCEPT relation from (b).
WITH RECURSIVE PathAll(class,
rclass) AS
(SELECT class, rclass
(SELECT movie, sequel
FROM SequelOf
)
UNION
(SELECT F.movie, S.sequel
FROM FollowOn F, Sequel S
WHERE F.followOn = S.movie) SELECT movie
7
FROM FollowOn GROUPBY movie HAVING COUNT(followon)
tar). (g) REFERENCES on Studio, REFERENCES on MovieExec (or REFERENCES(name,
presC#) on Studio, REFERENCES(cert#, netWorth) on MovieExec). 2
Exercise 10.1.2
A p ??
Exercise 10.1.3
After step (5), the grant diagram is as follows:
A
B
p
p
??
?
-
D p
?
?
E p ?
D p ?
?
E p ?
Section 10.2
Exercise 10.2.1
(a) The rules for trips that have reasonable connections are:
>= 2;
(f) This is, in a sense,a reverse of (e) above, because to have at most one followon means that the total count of the tuples grouped by the given movie x must be no greater than 2 (one for the movie and its sequel, and the other for the sequel and its sequel). Using the book ’ssyntax, the SQL would be:
(c) WITH RECURSIVE Path(class, rclass) AS (SELECT class, rclass FROM Rel WHERE mult = ’ multi ’) UNION (SELECT Path.class, Rel.rclass FROM Path, Rel WHERE Path.rclass = Rel.class) UNION (SELECT Rel.class, Path.rclass FROM Path, Rel WHERE Rel.rclass = Path.class)