数据库基础教程CH1 答案

合集下载

数据库原理Ch1-4

数据库原理Ch1-4

(5)域(Domain) • 属性的取值范围,如年龄的域是(14~40), 性别的域是(男,女)。 (6)分量 • 每一行对应的列的属性值,即元组中的一 个属性值,如学号、姓名、年龄等均是一 个分量。 (7)关系模式 • 对关系的描述,一般表示为:关系名(属 性1,属性2,……属性n),如:学生(学 号,姓名,性别,年龄,系别)。
出产日期 产品号 产品名 型号 年 2004 月 05 日 12
032456
风扇
A134






表中有表的示例
不符合关系模型的实例
职工 号
86051
姓 名
陈 平
职 称
讲 师
工 资 基 本
105
扣 除 职 务
15
实 发
115.5
工 龄
9.5
房 租
6
水 电
12
. . .
. . .
. . .
.
. . .
C5
C1 C2 C4 C1 C2
70
0 70 85 93 85
T4
T4 T5 T5
C2
C3 C5 C7
S4
S5
C3
C2
83
89
(1)关系(Relation) • 一个关系对应一张二维表,如图1.9的五张表对应 五个关系,如学生表、课程表。 (2)元组(Tuple) • 表格中的一行,如S表中的一个学生记录即为一 个元组。 (3)属性(Attribute) • 表格中的一列,相当于记录中的一个字段,如S 表中有五个属性(学号,姓名,性别,年龄,系 别)。 (4)关键字(Key) • 可唯一标识元组的属性或属性集,也称为关系键 或主码,如S表中学号可以唯一确定一个学生, 为学生关系的主码。

数据库原理教程习题答案全

数据库原理教程习题答案全

数据库原理教程习题答案全集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#0000000000第1章数据库系统概述习题参考答案税务局使用数据库存储纳税人(个人或公司)信息、纳税人缴纳税款信息等。

典型的数据处理包括纳税、退税处理、统计各类纳税人纳税情况等。

银行使用数据库存储客户基本信息、客户存贷款信息等。

典型的数据处理包括处理客户存取款等。

超市使用数据库存储商品的基本信息、会员客户基本信息、客户每次购物的详细清单。

典型的数据处理包括收银台记录客户每次购物的清单并计算应交货款。

DBMS是数据库管理系统的简称,是一种重要的程序设计系统。

它由一个相互关联的数据集合和一组访问这些数据的程序组成。

数据库是持久储存在计算机中、有组织的、可共享的大量数据的集合。

数据库中的数据按一定的数据模型组织、描述和存储,可以被各种用户共享,具有较小的冗余度、较高的数据独立性,并且易于扩展。

数据库系统由数据库、DBMS(及其开发工具)、应用系统和数据库管理员组成。

数据模型是一种形式机制,用于数据建模,描述数据、数据之间的联系、数据的语义、数据上的操作和数据的完整性约束条件。

数据库模式是数据库中使用数据模型对数据建模所产生设计结果。

对于关系数据库而言,数据库模式由一组关系模式构成。

数据字典是DBMS维护的一系列内部表,用来存放元数据。

所谓元数据是关于数据的数据。

DBMS提供如下功能:(1)数据定义:提供数据定义语言DDL,用于定义数据库中的数据对象和它们的结构。

(2)数据操纵:提供数据操纵语言DML,用于操纵数据,实现对数据库的基本操作(查询、插入、删除和修改)。

(3)事务管理和运行管理:统一管理数据、控制对数据的并发访问,保证数据的安全性、完整性,确保故障时数据库中数据不被破坏,并且能够恢复到一致状态。

(4)数据存储和查询处理:确定数据的物理组织和存取方式,提供数据的持久存储和有效访问;确定查询处理方法,优化查询处理过程。

数据库原理基础教程英文版答案CH1 作业(1)

数据库原理基础教程英文版答案CH1 作业(1)

CH1 作业Fill in the blank.1、A data model is a notation for describing data or information. The description generally consists of three parts: 、、.2、and is called the schema for that relation.3、When clearing key (keys), an attribute or list of attributes may be declared or .4、If PRIMARY KEY is used, then attributes in S are not allowed to have as a value for their components.True or false1、The relational model is based on tables.2、SQL value can’t be NULL.3、Either says that no two tuples of the relation may agree in all the attribute(s) on the list.4、No attribute of a PRIMARY KEY can ever be NULL in any tuple. But attributes declared UNIQUE may have NULL’s, and there may be several tuples with NULL.5、Like HTML, the opening tag in XML can have atttribute = value pairs.Single choice.1、In the following figure, there are instances of two relations that might constitute part of abanking database. Indicate the following:The attributes of Account relation is.A.acctNo, type, balance B. acctNo, type C. acctNo, balance D. acctNom, type, balance2、How many different ways (considering orders of tuples and attributes) are there to represent a relation instance if that instance has:n attributes and m tuples?A. n!m!,B. (n-1)!m!,C. n!(m-1)!, D n!(m+1)!3、How many different ways (considering orders of tuples and attributes) are there to represent a relation instance if that instance has:Four attributes and five tuples?A.1440,B. 2880,C.576, D 7204、How many different ways (considering orders of tuples and attributes) are there to represent a relation instance if that instance has:Three attributes and three tuples?A. 20,B. 25,C.36, D 48Multiple choice1、In the following figure, there are instances of two relations that might constitute part of abanking database. Indicate the following:The tuples of Account relation are.A. (12345, savings, 12000)B. (34567, checking, 1000),C. (23456, checking, 1000)D. (34567, savings, 25)Essay question1、We suggested that there are many examples of attributes that are created for the purpose of serving as keys of relations. Give some examples.。

数据库基础课后习题及答案

数据库基础课后习题及答案

数据库基础课后习题及答案数据库基础课后习题及答案数据库是计算机科学中非常重要的一个概念,它用于存储和管理大量的数据。

在数据库基础课程中,学生通常需要完成一些习题来巩固所学的知识。

本文将介绍一些常见的数据库基础课后习题,并提供相应的答案。

一、选择题1. 数据库是指什么?A. 存储和管理数据的软件系统B. 存储和管理硬件设备的软件系统C. 存储和管理网络的软件系统D. 存储和管理操作系统的软件系统答案:A2. 数据库管理系统(DBMS)的主要功能是什么?A. 存储和管理数据B. 分析和处理数据C. 网络和通信D. 操作系统管理答案:A3. 下列哪个不属于数据库的特点?A. 数据共享B. 数据冗余C. 数据独立性D. 数据一致性答案:B4. 数据库中的数据是以什么形式存储的?A. 文件B. 表格C. 文本D. 图像答案:B5. 数据库中的主键是什么?A. 唯一标识一个记录的属性B. 存储在数据库中的所有数据C. 数据库中的表格D. 数据库中的索引答案:A二、填空题1. 数据库中的关系是指什么?关系是指数据之间的联系和关联。

2. 数据库中的SQL是什么意思?SQL是结构化查询语言(Structured Query Language)的缩写。

3. 数据库中的DDL是什么意思?DDL是数据定义语言(Data Definition Language)的缩写。

4. 数据库中的DML是什么意思?DML是数据操作语言(Data Manipulation Language)的缩写。

5. 数据库中的索引有什么作用?索引可以提高数据库的查询效率,加快数据检索的速度。

三、简答题1. 数据库的三级模式是什么?数据库的三级模式包括外模式、概念模式和内模式。

外模式是用户对数据库的直接接口,概念模式是数据库的全局逻辑结构,内模式是数据库在物理存储上的表示。

2. 数据库的ACID是什么意思?ACID是数据库事务的四个特性,包括原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)。

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

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

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)。

ch1参考答案

ch1参考答案

第一章作业参考答案1.1、令A[1…60]=11,12,…,70,用算法BINARYSEARCH搜索下列x值时执行了多少次比较运算?(a)33 (b) 7 (c) 70 (d) 77解:当x=33,第一次比较中,数组的中间元素A[30]=40; 33<40,剩余的子序列为A[1…29]=11,12,…39;第二次比较中,A[15]=25;33>25,剩余的子序列为A[16…29]=26,27,…39;第三次比较中,A[22]=32; 33>32,剩余的子序列为A[23…29]= 33,…39;第四次比较中,A[26]=36;33<36;剩余的子序列为A[23…25]= 33,34,35;第五次比较中,A[24]=34;33<34;剩余的子序列为A[23]= 33;第六次比较中,A[23]=33;33=33;搜索成功共进行6次比较当x=7,第一次比较中,数组的中间元素A[30]=40; 7<40,剩余的子序列为A[1…29]=11,12,…39;第二次比较中,A[15]=25;7<25,剩余的子序列为A[1…14]=11,12,…24;第三次比较中,A[7]=17;7<17,剩余的子序列为A[1…6]=11,12,…16;第四次比较中,A[3]=13;7<13,剩余的子序列为A[1…2]=11,12;第五次比较中,A[1]=11;7<11,此时high=0;low=1;high<low;停止比较。

共进行6次比较当x=70,第一次比较中,数组的中间元素A[30]=40; 70>40,剩余的子序列为A[31…60]=41,42,…70;第二次比较中,A[45]=55;70>55,剩余的子序列为A[46…60]=56,57,…70;第三次比较中,A[53]=63;70>63,剩余的子序列为A[54…60]=64,65,…70;第四次比较中,A[57]=67;70>67,剩余的子序列为A[58…60]=68,69,70;第五次比较中,A[59]=69;70>69,剩余的子序列为A[60]=70;第六次比较中,A[60]=70;比较结束;共进行6次比较;当x=77,第一次比较中,数组的中间元素A[30]=40; 77>40,剩余的子序列为A[31…60]=41,42,…70;第二次比较中,A[45]=55;77>55,剩余的子序列为A[46…60]=56,57,…70;第三次比较中,A[53]=63;77>63,剩余的子序列为A[54…60]=64,65,…70;第四次比较中,A[57]=67;77>67,剩余的子序列为A[58…60]=68,69,70;第五次比较中,A[59]=69;77>69,剩余的子序列为A[60]=70;第六次比较中,A[60]=70;77>70,high=60;low=61;停止比较,共进行6次比较1.10:BOTTOMUPSORT对于数组A[1...16]的运作过程如下:共执行47次该算法执行的比较次数为:8+2+3+2+3+7+7+15=471.15 用Θ符号表示㏒2n+n+㏒㏒n。

数据库系统基础教程答案

数据库系统基础教程答案

SolutionsChapter 4 4.1.14.1.2a)b)c)In c we assume that a phone and address can only belong to a single customer (1-m relationship represented by arrow into customer).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 becomesweak and the key ssNo of customers will be needed as part of the composite key ofthe 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 alsomodify 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.4.2.1Redundancy: 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 with Presidents 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 Presidents into 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 about studios 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 composite attribute containing concatenation of all studio names in a contact can be considered. A separator character such as "$" can be used. SQL allows searching of such an attribute using query like '%keyword%'4.2.5From 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.b)c)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 R b)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 whichEnrollments is connected i.e. studentID, dept, and CourseNo.4.4.3a)b)。

数据库原理教程习题答案(全)

数据库原理教程习题答案(全)

0000000000第1章数据库系统概述习题参考答案税务局使用数据库存储纳税人(个人或公司)信息、纳税人缴纳税款信息等。

典型的数据处理包括纳税、退税处理、统计各类纳税人纳税情况等。

银行使用数据库存储客户基本信息、客户存贷款信息等。

典型的数据处理包括处理客户存取款等。

超市使用数据库存储商品的基本信息、会员客户基本信息、客户每次购物的详细清单。

典型的数据处理包括收银台记录客户每次购物的清单并计算应交货款。

1.2 DBMS是数据库管理系统的简称,是一种重要的程序设计系统。

它由一个相互关联的数据集合和一组访问这些数据的程序组成。

数据库是持久储存在计算机中、有组织的、可共享的大量数据的集合。

数据库中的数据按一定的数据模型组织、描述和存储,可以被各种用户共享,具有较小的冗余度、较高的数据独立性,并且易于扩展。

数据库系统由数据库、DBMS(及其开发工具)、应用系统和数据库管理员组成。

数据模型是一种形式机制,用于数据建模,描述数据、数据之间的联系、数据的语义、数据上的操作和数据的完整性约束条件。

数据库模式是数据库中使用数据模型对数据建模所产生设计结果。

对于关系数据库而言,数据库模式由一组关系模式构成。

数据字典是DBMS维护的一系列内部表,用来存放元数据。

所谓元数据是关于数据的数据。

1.3 DBMS提供如下功能:(1)数据定义:提供数据定义语言DDL,用于定义数据库中的数据对象和它们的结构。

(2)数据操纵:提供数据操纵语言DML,用于操纵数据,实现对数据库的基本操作(查询、插入、删除和修改)。

(3)事务管理和运行管理:统一管理数据、控制对数据的并发访问,保证数据的安全性、完整性,确保故障时数据库中数据不被破坏,并且能够恢复到一致状态。

(4)数据存储和查询处理:确定数据的物理组织和存取方式,提供数据的持久存储和有效访问;确定查询处理方法,优化查询处理过程。

(5)数据库的建立和维护:提供实用程序,完成数据库数据批量装载、数据库转储、介质故障恢复、数据库的重组和性能监测等。

数据库系统原理教程课后习题及答案(第一章)

数据库系统原理教程课后习题及答案(第一章)

第1章绪论1 .试述数据、数据库、数据库系统、数据库管理系统的概念。

答:( l )数据(Data ) :描述事物的符号记录称为数据。

数据的种类有数字、文字、图形、图像、声音、正文等。

数据与其语义是不可分的。

解析在现代计算机系统中数据的概念是广义的。

早期的计算机系统主要用于科学计算,处理的数据是整数、实数、浮点数等传统数学中的数据。

现代计算机能存储和处理的对象十分广泛,表示这些对象的数据也越来越复杂。

数据与其语义是不可分的。

500 这个数字可以表示一件物品的价格是500 元,也可以表示一个学术会议参加的人数有500 人,还可以表示一袋奶粉重500 克。

( 2 )数据库(DataBase ,简称DB ) :数据库是长期储存在计算机内的、有组织的、可共享的数据集合。

数据库中的数据按一定的数据模型组织、描述和储存,具有较小的冗余度、较高的数据独立性和易扩展性,并可为各种用户共享。

( 3 )数据库系统(DataBas 。

Sytem ,简称DBS ) :数据库系统是指在计算机系统中引入数据库后的系统构成,一般由数据库、数据库管理系统(及其开发工具)、应用系统、数据库管理员构成。

解析数据库系统和数据库是两个概念。

数据库系统是一个人一机系统,数据库是数据库系统的一个组成部分。

但是在日常工作中人们常常把数据库系统简称为数据库。

希望读者能够从人们讲话或文章的上下文中区分“数据库系统”和“数据库”,不要引起混淆。

( 4 )数据库管理系统(DataBase Management sytem ,简称DBMs ) :数据库管理系统是位于用户与操作系统之间的一层数据管理软件,用于科学地组织和存储数据、高效地获取和维护数据。

DBMS 的主要功能包括数据定义功能、数据操纵功能、数据库的运行管理功能、数据库的建立和维护功能。

解析DBMS 是一个大型的复杂的软件系统,是计算机中的基础软件。

目前,专门研制DBMS 的厂商及其研制的DBMS 产品很多。

数据库基础教程CH1 答案

数据库基础教程CH1 答案

Exercises 2.3.1In this exercise we introduce one of our running examples of a relational database schema. The database schema consists of four relations, whose schemas are: Product (maker, model, type)PC (model, speed, ram. hd, price)Laptop (model, speed, ram, hd, screen, price)Printer (model, color, type, price)The Product relation gives the manufacturer, model number and type (PC, laptop, or printer) of various products. We assume for convenience that model numbers are unique over all manufacturers and product types; that assumption is not realistic, and a real database would include a code for the manufacturer as part of the model number. The PC relation gives for each model number that is a PC the speed (of the processor, in gigahertz), the amount of RAM (in megabytes), the size of the hard disk (in gigabytes), and the price. The Laptop relation is similar, except that the screen size (in inches) is also included. The Printer relation records for each printer model whether the printer produces color output (true, if so), the process type (laser or ink-jet, typically), and the price.Write the following declarations:a) A suitable schema for relation Product.b) A suitable schema for relation PC.c) A suitable schema for relation Laptop.d) A suitable schema for relation Printer.e)An alteration to your Printer schema from (d) to delete the attribute color.f)An alteration to your Laptop schema from (c) to add the attribute od(optical-disk type, e.g., cd or dvd). Let the default value for this attribute be 'none' if the laptop does not have an optical disk.Exercise 2.3.1aCREATE TABLE Product (maker CHAR(30),model CHAR(10) PRIMARY KEY,type CHAR(15)); Exercise 2.3.1b CREATE TABLE PC (model CHAR(30),speed DECIMAL(4,2),ram INTEGER,hd INTEGER,price DECIMAL(7,2) );Exercise 2.3.1cCREATE TABLE Laptop ( model CHAR(30),speed DECIMAL(4,2),ram INTEGER,hd INTEGER,screen DECIMAL(3,1),price DECIMAL(7,2) );Exercise 2.3.1dCREATE TABLE Printer ( model CHAR(30),color BOOLEAN,type CHAR (10),price DECIMAL(7,2) ); Exercise 2.3.1eALTER TABLE Printer DROP color; Exercise 2.3.1fALTER TABLE Laptop ADD od CHAR (10) DEFAULT ‘none’;Exercises 2.3.2This exerCÌse introduces another running example,concerning World War 11 capital ships. It involves the following relations:Classes(class , type , country , numGuns , bore , displacement)Ships(name , class , launched)Battles(name,date)Outcomes(ship , battle , result)Ships are built in "classes" from the same design, and the class is usually named for the first ship of that class. The relation Classes records the name of the class, the type ('bb' for battleship or 'bc' for battlecruiser) , the country that built the ship, the number of main guns, the bore (diameter of the gun barrel, in inches) of the main guns, and the displacement (weight, in tons). Relation Ships records the name of the ship, the name of its class, and the year in which the ship was launched. Relation Batt1es gives the name and date of battles involving these ships, and relation Outcomes gives the result (sunk, damaged, or ok) for each ship in each battle.Write the following declarations:a) A suitable schema for relation Classes.b) A suitable schema for relation Ships.c) A suitable schema for relation Batt1es.d) A suitable schema for relation Outcomes.e)An alteration to your Classes relation from (a) to delete the attribute bore.f)An alteration to your Ships relation from (b) to include the attribute yardgiving the shipyard where the ship was built.Exercise 2.3.2aCREATE TABLE Classes ( class CHAR(20),type CHAR(5),country CHAR(20),numGuns INTEGER,bore DECIMAL(3,1),displacement INTEGER );Exercise 2.3.2bCREATE TABLE Ships ( name CHAR(30),class CHAR(20),launched INTEGER ); Exercise 2.3.2cCREATE TABLE Battles (name CHAR(30),date DATE);Exercise 2.3.2dCREATE TABLE Outcomes (ship CHAR(30),battle CHAR(30),result CHAR(10));Exercise 2.3.2eALTER TABLE Classes DROP bore; Exercise 2.3.2fALTER TABLE Ships ADD yard CHAR(30Exercises 11.1.1Since there is no schema to design in the semistructureddata model, we cannot ask you to design schemas to describe different situations Rather, in the following exercises we shall ask you to suggest how particular data might be organized to reflect certain facts.a)Add to Fig, 11.1 the facts that Star Wars was directed by GeorgeLucas and produced by Gary Kurtz.b)Add to Fig. 11.1 information about Empire Strikes Back andReturn of the Jedi, including the facts that Carrie Fisher and MarkHamill appeared in these movies.c)Add to (b) information about the studio (Fox) for these moviesand the address of the studio (Hollywood)Exercise 11.1.1a)b)c)Suggest how typical data about banks and customers, as in Exercise 4.1.1, could be represented in the semistructured model.Answer:Exercises 11.1.3Suggest how typical data about players, teams, and fans, as was described in Exercise 4.1.3, could be represented in the semistructured model.Suggest how typical data about a genealogy, as was described in Exercise 4.1.6, could be represented in the semistructured model.Answer:。

数据库系统基础教程答案

数据库系统基础教程答案
4.2.6
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.

数据库基础教程课后习题答案(顾韵华)

数据库基础教程课后习题答案(顾韵华)

数据库基础教程课后习题答案(顾韵华)习题11、简述数据库系统的特点。

答:数据库系统的特点有:1)数据结构化在数据库系统中,采用统一的数据模型,将整个组织的数据组织为一个整体;数据不再仅面向特定应用,而是面向全组织的;不仅数据内部是结构化的,而且整体是结构化的,能较好地反映现实世界中各实体间的联系。

这种整体结构化有利于实现数据共享,保证数据和应用程序之间的独立性。

2)数据共享性高、冗余度低、易于扩充数据库中的数据能够被多个用户、多个应用程序共享。

数据库中相同的数据不会多次重复出现,数据冗余度降低,并可避免由于数据冗余度大而带来的数据冲突问题。

同时,当应用需求发生改变或增加时,只需重新选择不同的子集,或增加数据即可满足。

3)数据独立性高数据独立性是由DBMS的二级映像功能来保证的。

数据独立于应用程序,降低了应用程序的维护成本。

4)数据统一管理与控制数据库中的数据由数据库管理系统(DBMS)统一管理与控制,应用程序对数据的访问均经由DBMS。

DBMS提供四个方面的数据控制功能:并发访问控制、数据完整性、数据安全性保护、数据库恢复。

2、什么是数据库系统?答:在计算机系统上引入数据库技术就构成一个数据库系统(DataBase System,DBS)。

数据库系统是指带有数据库并利用数据库技术进行数据管理的计算机系统。

DBS有两个基本要素:一是DBS 首先是一个计算机系统;二是该系统的目标是存储数据并支持用户查询和更新所需要的数据。

3、简述数据库系统的组成。

答:数据库系统一般由数据库、数据库管理系统(及其开发工具)、数据库管理员(DataBase Administrator,DBA)和用户组成。

4、试述数据库系统的三级模式结构。

这种结构的优点是什么?答:数据库系统的三级模式结构是指数据库系统是由外模式、模式和内模式三级构成,同时包含了二级映像,即外模式/模式映像、模式/内模式映像,如下图所示。

应用1应用2应用3应用4应用5??外模式A外模式B??外模式/模式映像模式模式/内模式映像模式数据库数据库系统的这种结构具有以下优点:(1)保证数据独立性。

ch01习题及实验答案

ch01习题及实验答案

第一章习题及实验答案习题答案一、选择题1、D2、C3、B4、C5、D6、A7、C8、A9、B10、A二、填空题1、人工管理阶段(50年代初期)、文件系统阶段(50年代后期)、数据库系统阶段(60年代后期开始)2、模式、外模式和内模式3、数据库(DB)、数据库管理系统(DBMS)、应用程序、用户4、物理独立性、逻辑独立性5、SQL三、简答题1、答:一个完整的数据库系统由数据库(DB)、数据库管理系统(DBMS)、应用程序、用户和硬件组成。

最关键的部分是数据库管理系统(DBMS)。

2、答:数据库系统的特点主要有以下几个方面:(1)数据结构化(2)数据的共享性高,冗余度低,易扩充(3)数据独立性高(4)数据由DBMS统一管理和控制3、答:关系是关系模型的数据结构。

关系模式是关系的形式化描述。

最简单的表示为:关系名(属性名1,属性名2,……,属性名n)其中的某个属性名i或某些属性名组为主键,要用下划线表明。

关系数据库是表或者说关系的集合4、答:DBMS 提供以下主要功能:(1)数据定义的功能。

DBMS提供数据定义语言(Data Definition Language,DDL)。

通过DDL,可以方便地定义数据库中的各种对象。

(2)数据操纵的功能。

DBMS提供数据操纵语言(Data Manipulation Language,DML)。

通过DML,实现数据库中数据的基本操作。

(3)数据库的运行管理(管理数据库)功能。

提供数据控制语言DCL(data control language),负责数据库在建立、运行和维护时由DBMS统一管理和统一控制。

(4)数据库的建立和维护功能(建立维护数据库)。

目前有许多数据库产品,如Oracle、SQL Server、DB2、MySQL 、Access等产品各以自己特有的功能,在数据库市场上占有一席之地。

5、答:数据独立性是指应用程序不因物理存储的改变而改变。

数据独立性分为:逻辑独立性、物理独立性。

ch1

ch1

图1-1 数据库系统的组成
1. 数据库(DataBase) 数据库是用来存储数据的,它是按一定结构 存储在计算机中相互关联的数据的集合。例如, 可以将描述学生的姓名、年龄、性别、家庭住址、 E-mail信箱等相关信息存储在一个数据库中;为了 加强对图书馆的图书管理,可以对每一本图书进 行分类编号,然后将描述图书的编号、书名,作 者、出版社、定价等相关信息存储在一个数据库 中等。 数据库中有两类数据,一类是用户数据,如 “学生表”中每个学生的信息;一类是系统数据, 如“学生表”中的结构,系统数据又称为是数据 字典。
2.文件系统阶段 20世纪50年代后期到60年代中期,硬件 方面有了磁盘、磁鼓等直接存储设备;软件上 有了专门的数据管理软件,一般为文件系统; 处理形式上不仅有了批处理,而且能联机实时 处理。所以,数据可以长期保存;可以由文件 系统管理数据,但是数据共享性仍然较差,冗 余度大,数据的独立性差。
早期的计算机主要应用于科学计算,随着 生产的发展,社会的进步,计算机应用进入了 数据处理的时代。在当今社会,计算机应用已 经涉足到社会的各个领域,人们的日常生活和 工作与计算机的关系也愈加紧密。 数据处理是计算机四大应用(科学计算、 过程控制、数据处理和辅助设计)的一个重要 方面。数据库技术是在文件技术的基础上发展 起来的,它是数据处理的一种最新的方法。本 章将从数据处理的发展过程简要地介绍数据库 系统所涉及的基本概念。
1.3 数据库模型
目前,数据库领域中最常用的数据 模型有四种,层次模型,网状模型,关 系模型和面向对象模型。
1.3.1 数据模型的基本概念 1.信息、数据和实体 信息是对客观事物或抽象概念的描述。 数据是表示信息的,是对客观事物或抽象 概念的符号化的描述。客观存在并可相互 区别的事物称为实体。如一名学生、一本 书、一个工程等。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

Exercises 2.3.1In this exercise we introduce one of our running examples of a relational database schema. The database schema consists of four relations, whose schemas are: Product (maker, model, type)PC (model, speed, ram. hd, price)Laptop (model, speed, ram, hd, screen, price)Printer (model, color, type, price)The Product relation gives the manufacturer, model number and type (PC, laptop, or printer) of various products. We assume for convenience that model numbers are unique over all manufacturers and product types; that assumption is not realistic, and a real database would include a code for the manufacturer as part of the model number. The PC relation gives for each model number that is a PC the speed (of the processor, in gigahertz), the amount of RAM (in megabytes), the size of the hard disk (in gigabytes), and the price. The Laptop relation is similar, except that the screen size (in inches) is also included. The Printer relation records for each printer model whether the printer produces color output (true, if so), the process type (laser or ink-jet, typically), and the price.Write the following declarations:a) A suitable schema for relation Product.b) A suitable schema for relation PC.c) A suitable schema for relation Laptop.d) A suitable schema for relation Printer.e)An alteration to your Printer schema from (d) to delete the attribute color.f)An alteration to your Laptop schema from (c) to add the attribute od(optical-disk type, e.g., cd or dvd). Let the default value for this attribute be 'none' if the laptop does not have an optical disk.Exercise 2.3.1aCREATE TABLE Product (maker CHAR(30),model CHAR(10) PRIMARY KEY,type CHAR(15)); Exercise 2.3.1b CREATE TABLE PC (model CHAR(30),speed DECIMAL(4,2),ram INTEGER,hd INTEGER,price DECIMAL(7,2) );Exercise 2.3.1cCREATE TABLE Laptop ( model CHAR(30),speed DECIMAL(4,2),ram INTEGER,hd INTEGER,screen DECIMAL(3,1),price DECIMAL(7,2) );Exercise 2.3.1dCREATE TABLE Printer ( model CHAR(30),color BOOLEAN,type CHAR (10),price DECIMAL(7,2) ); Exercise 2.3.1eALTER TABLE Printer DROP color; Exercise 2.3.1fALTER TABLE Laptop ADD od CHAR (10) DEFAULT ‘none’;Exercises 2.3.2This exerCÌse introduces another running example,concerning World War 11 capital ships. It involves the following relations:Classes(class , type , country , numGuns , bore , displacement)Ships(name , class , launched)Battles(name,date)Outcomes(ship , battle , result)Ships are built in "classes" from the same design, and the class is usually named for the first ship of that class. The relation Classes records the name of the class, the type ('bb' for battleship or 'bc' for battlecruiser) , the country that built the ship, the number of main guns, the bore (diameter of the gun barrel, in inches) of the main guns, and the displacement (weight, in tons). Relation Ships records the name of the ship, the name of its class, and the year in which the ship was launched. Relation Batt1es gives the name and date of battles involving these ships, and relation Outcomes gives the result (sunk, damaged, or ok) for each ship in each battle.Write the following declarations:a) A suitable schema for relation Classes.b) A suitable schema for relation Ships.c) A suitable schema for relation Batt1es.d) A suitable schema for relation Outcomes.e)An alteration to your Classes relation from (a) to delete the attribute bore.f)An alteration to your Ships relation from (b) to include the attribute yardgiving the shipyard where the ship was built.Exercise 2.3.2aCREATE TABLE Classes ( class CHAR(20),type CHAR(5),country CHAR(20),numGuns INTEGER,bore DECIMAL(3,1),displacement INTEGER );Exercise 2.3.2bCREATE TABLE Ships ( name CHAR(30),class CHAR(20),launched INTEGER ); Exercise 2.3.2cCREATE TABLE Battles (name CHAR(30),date DATE);Exercise 2.3.2dCREATE TABLE Outcomes (ship CHAR(30),battle CHAR(30),result CHAR(10));Exercise 2.3.2eALTER TABLE Classes DROP bore; Exercise 2.3.2fALTER TABLE Ships ADD yard CHAR(30Exercises 11.1.1Since there is no schema to design in the semistructureddata model, we cannot ask you to design schemas to describe different situations Rather, in the following exercises we shall ask you to suggest how particular data might be organized to reflect certain facts.a)Add to Fig, 11.1 the facts that Star Wars was directed by GeorgeLucas and produced by Gary Kurtz.b)Add to Fig. 11.1 information about Empire Strikes Back andReturn of the Jedi, including the facts that Carrie Fisher and MarkHamill appeared in these movies.c)Add to (b) information about the studio (Fox) for these moviesand the address of the studio (Hollywood)Exercise 11.1.1a)b)c)Suggest how typical data about banks and customers, as in Exercise 4.1.1, could be represented in the semistructured model.Answer:Exercises 11.1.3Suggest how typical data about players, teams, and fans, as was described in Exercise 4.1.3, could be represented in the semistructured model.Suggest how typical data about a genealogy, as was described in Exercise 4.1.6, could be represented in the semistructured model.Answer:。

相关文档
最新文档