下载文档原格式
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数据库管理与开发基础教程课后习题及答案第⼀章选择题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数据库基础教程第三版答案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数据库基础教程参考答案第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 基础上实现的。
习题11、简述数据库系统的特点。
答：数据库系统的特点有：1）数据结构化在数据库系统中，采用统一的数据模型，将整个组织的数据组织为一个整体；数据不再仅面向特定应用，而是面向全组织的；不仅数据内部是结构化的，而且整体是结构化的，能较好地反映现实世界中各实体间的联系。
这种整体结构化有利于实现数据共享，保证数据和应用程序之间的独立性。
2）数据共享性高、冗余度低、易于扩充数据库中的数据能够被多个用户、多个应用程序共享。
数据库中相同的数据不会多次重复出现，数据冗余度降低，并可避免由于数据冗余度大而带来的数据冲突问题。
同时，当应用需求发生改变或增加时，只需重新选择不同的子集，或增加数据即可满足。
3）数据独立性高数据独立性是由DBMS 的二级映像功能来保证的。
数据独立于应用程序，降低了应用程序的维护成本。
4）数据统一管理与控制数据库中的数据由数据库管理系统（DBMS ）统一管理与控制，应用程序对数据的访问均经由DBMS 。
DBMS 提供四个方面的数据控制功能：并发访问控制、数据完整性、数据安全性保护、数据库恢复。
2、什么是数据库系统？答：在计算机系统上引入数据库技术就构成一个数据库系统（DataBase System ，DBS ）。
数据库系统是指带有数据库并利用数据库技术进行数据管理的计算机系统。
DBS 有两个基本要素：一是DBS 首先是一个计算机系统；二是该系统的目标是存储数据并支持用户查询和更新所需要的数据。
3、简述数据库系统的组成。
答：数据库系统一般由数据库、数据库管理系统（及其开发工具）、数据库管理员（DataBase Administrator ，DBA ）和用户组成。
4、试述数据库系统的三级模式结构。
这种结构的优点是什么？答：数据库系统的三级模式结构是指数据库系统是由外模式、模式和内模式三级构成，同时包含了二级映像，即外模式/模式映像、模式/内模式映像，如下图所示。
数据库应用1……外模式A 外模式B 模式应用2应用3应用4应用5……模式外模式/模式映像模式/内模式映像数据库系统的这种结构具有以下优点：（1）保证数据独立性。
数据库系统教程(第三版课后答案)免费下载第1章数据库概论1.1 基本内容分析本章的重要概念（1）DB、DBMS和DBS的定义（2）数据管理技术的发展阶段人工管理阶段、文件系统阶段、数据库系统阶段和高级数据库技术阶段等各阶段的特点。
（3）数据描述概念设计、逻辑设计和物理设计等各阶段中数据描述的术语，概念设计中实体间二元联系的描述（1:1，1:N，M:N）1.7 与“文件”结构相比，“数据库”结构有些什么不同？答：与文件结构相比，数据库结构主要有下面三点不同：数据的结构化。
文件由记录组成，但各文件之间缺乏联系。
数据库中数据在磁盘中仍以文件形式组织，但这些文件之间有着广泛的联系。
数据库的逻辑结构用数据模型来描述，整体结构化。
数据模型不仅描述数据本身的特点，还要描述数据之间的联系。
数据独立性。
文件只有设备独立性，而数据库还具有逻辑独立性和物理独立性。
访问数据的单位。
访问文件中的数据，以记录为单位。
访问数据库中的数据，以数据项（字段）为单位，增加了系统的灵活性。
1.8 什么是数据独立性？在数据库中有哪两级独立性？答：数据独立性是指应用程序与DB的数据结构之间相互独立。
在物理结构改变时，尽量不影响应用程序，称为物理数据独立性；在逻辑结构改变时，尽量不影响应用程序，称为逻辑数据独立性。
1.9 分布式数据库系统和面向对象数据库系统各有哪些特点？答：DDBS主要有三个特点：??数据物理上分布在各地，但逻辑上是一个整体；??每个场地既可以执行局部应用，也可以执行全局应用；??各地的计算机由数据通信网络相连接。
面向对象数据系统主要有两个特点：??面向对象数据模型能完整地描述现实世界的数据结构，能表达数据间嵌套、递归的联系。
??具有面向对象技术的封装性和继承性的特点，提高了软件的可重用性。
1.10 逻辑记录与物理记录，逻辑文件与物理文件有些什么联系和区别？答：逻辑数据是用户用以操作的数据形式，是抽象的概念化数据。
物理数据是实际存放在存储设备上的数据。
第1章1.试恳数据、数据库、数据库系统、数据库管理系统的概念。
答:（1）数据：描述事物的符号记录成为数据。
数据的种类有数字、文字、图形、图像、声音、正文等。
数据与其语义是不可分的。
（2）数据库：数据库是长期储存在计算机内的、有组织的、可共享的数据集合。
数据库中的数据按照一定的数据模型组织。
描述和储存，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
（3）数据库系统：数据库系统是指在计算机系统中引入数据库后的系统构成，一般由数据库、数据库管理系统（及其开发人具）、应用系统、数据库管理员构成。
（4）数据库管理系统：数据库管理系统是位于用户与操作系统之间的一层数据管理软件，用于科学地组织和存储数据、高效地获取和维护数据。
DBMS的主要功能包括数据定义功能、数据操作功能、数据库的建立和维护功能。
6. 试述数据库系统三级模式结构，这种结构的优点是什么？答：数据库系统的三级模式机构由外模式、模式和内模式组成。
外模式，亦称子模式或用户模式，是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。
模式亦称逻辑模式，是数据库中全体数据呃逻辑结构和特征的描述，是所有用户的公共数据视图。
模式描述的是数据的全局逻辑结构。
外模式涉及的是数据的内部逻辑结构，通常是模式的子集。
内模式，亦称存储模式，是数据在数据库内部的表示，即对数据的物理结构和存储方式的描述。
数据库系统的三级模式是对数据的三个抽象级别，它对数据的具体组织留给DBMS管理，使用户能逻辑抽象地处理数据，而不必关心数据在计算机中的表示和存储。
为了能够在内部实现这三个抽象层次的联系和转换，数据库系统在这三级模式之间提供了两层映像：外模式/模式映像和模式/内模式映像。
正是这两层映像保证了数据库系统中的数据能够具有较高的逻辑独立性和物理独立性。
7. 定义并解释下列术语。
ORACLE 10g 课后参考答案（答案仅供参考）第一章ORACLE 10g简介一、选择题1.下面不属于ORACLE 10g产品系列的是（D）A.Oracle数据库 10g标准版1B.Oracle数据库 10g标准版C.Oracle数据库 10g企业版D.Oracle数据库 10g网络版2.ORACLE 10g中的g表示（D）A.版本B.网络C.数据库D.网格计算3.下面关于ORACLE 10g数据库逻辑结构的描述错误的是（C）A.数据库由若干个表空间组成B.表空间由表组成C.表由数据块组成D.段由区间组成4.ORACLE管理数据库存储空间的最小存储单位是（A）A.数据块B.表空间C.表D.区间5.ORACLE分配磁盘空间的最小单位是（D）A.数据块B.表空间C.表D.区间6.下列不属于ORACLE表空间的是（D）A.大文件表空间B.系统表空间C.撤销表空间D.网格表空间7.当数据库服务器上的一个数据库启动时，ORACLE将分配一块内存区间，叫做系统全局区，英文缩写为（B）A.VGAB.SGAC.PGAD.GLOBAL二、填空题1.__视图__ 是虚拟的表，它在物理上并不存在。
可以把它看成是一个存储的查询。
2.创建___索引__可以提高读取数据的效率。
它的功能类似于书的目录，读者可以通过目录很快的在书中找到需要的内容。
3.有些表共享公共的列，并经常被同时访问，为了提高数据存取效率，把这些表在物理上存储在一起，得到的表的组合就是____簇____。
4.一个数据块对应磁盘上的一定数量的数据库空间，标准的数据块大小由初始参数（DB_BLOCK_SIZE ）指定。
5.每个数据库都至少有一个系统表空间，被称为__SYSTEM _表空间。
6.每个ORACLE数据库都由3种类型的文件组成：数据文件、日志文件、控制文件。
7.ORACLE有两种内存结构，即_系统全局区_和_程序全局区_。
三、简答题1.简述ORACLE数据库逻辑结构中各要素之间的关系。
