数据的库系统基础的教程第四章答案.pdf

.Solutions Chapter 4 a b c In c we assume that a phone and address can only belong to a single 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 bees weak and the key ssNo of customers will be needed as partof the posite key of the entity set.In c&d,we convert attributes phones and addresses to entity sets.Since entity sets often bee 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:Phones attribute can be converted into HomePhone,OfficePhone and CellPhone.a b c The relationship played between Teams and Players is similar to relationship plays between Teams and Players.a Assumptions A 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.Given 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 asssNo or customerNo Studios and Presidents can be bined into one entity set Studios with Presidents being an attribute of Studios under followingcircumstances: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.aStars:starName bMovies:movieName cStudios:studioName.However there exists a many-to-many relationship between Studios and Contracts.Hence,in addition,we need more informationabout studios involved.If a contract always involves two studios,two attributes such as producingStudio and starStudio can replace the Studios entity set.If a contact can be associated with at most five studios,it may be possible to replace the Studios entityset by five attributes viz.studio1,.studio2,studio3,studio4,and studio5.Alternately,a posite attribute containing concatenation ofall 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%From Augmentation rule of Functional Dependency,given B-M then BND-M Hence we can just put an arrow entering mother.a Put an arrow entering entity set Mothers for the simplest solution.However,we can display more accurate information with below figure.b c Again from Augmentation rule of Functional Dependency,given BM-D then BMN-D Thus we can just add an arrow entering Doctors to fig 4.15.Below figure represents more accurate information however.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.c Design flaws in abc above 1.As suggested above,using Transitivity and Augmentation rules of Functional Dependency,much simpler design is possible.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.a b A captain cannot exist without a team.However a player can.A recently formed team can exist without players or colors.c Children can exist without mother and father.a The keys of both E1 and E2 are required for uniquely identifying tuples in R b The key of E1 c The key of E2 d The key of either E1 or E2 Special Case:All entity sets have arrows going into them i.e.all relationships are 1-to-1 Any Ki Otherwise:bination of all Kis where there does not exist an arrow going from R to Ei.No,grade is not part of the key for enrollments.The keys of Students and Courses bee keys of the weak entity set Enrollments.It is possible to make assignment number a weak key of Enrollments but this is not good design.A new entity set Assignment is created and it is also a weak entity set.Hence the key attributes of Assignment will e from thestrong entity sets to which Enrollments is connected i.e.studentID,dept,and CourseNo.a b c a b Customers Flights Bookings Relations for toCust and toFlt relationships are not required since the weak entity set Bookings already contains the keys of Customers and Flights.Schema is changed.Since toCust is no longer an identifying relationship,SSNo is no longer a part of Bookings relation.Bookings ToCust The above relations are merged into Bookings However custSSNo is no longer a key of Bookings relation.It bees a foreign key instead.Ships SisterOf Stars Studios Movies Contracts Depending on other relationships not shown in ER diagram,studioName may not be required as a key of Contracts.Students Courses Enrollments Departments Courses Leagues Teams Players The weak relation Courses has the key from Depts along with number.Hence there is no relation for GivenBy relationship.Depts Courses LabCourses LabCourses has all the attributes of Courses.Depts Courses LabCourses Courses and LabCourses are bined into one relation.Depts Courses Person ChildOf Child Father Mother.Since FatherOf and MotherOf are many-one relationships from Child,there is no need for a separate relation for them.Similarly the one-one relationship Married can be included in Father.ChildOf is a many-many relationship 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.A person cannot be both Mother and Father.Person PersonChild PersonChildFather PersonChildMother PersonFather PersonMother ChildOf FatherOf MotherOf Married 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.For the Person relation at least one of husband and wife attributes will be null.Person ChildOf People Males Females Fathers Mothers ChildOf People PeopleMale PeopleMaleFathers PeopleFemale PeopleFemaleMothers ChildOf FatherOf MotherOf 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 attributes to PeopleMale,PeopleMaleFathers,PeopleFemale,and PeopleFemaleMothers relations.People ChildOf 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 with their a attributes.Thus the maximum number of attributes is a+k.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 e entities where only one child exists 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 are at depth 1.Thus below figure will contain 8 subtrees that contain root E1,E1E2,E1E3,E1E4,E1E2E3,E1E3E4,E1E2E4,and E1E2E3E4.With e entity sets,maximum 2 relations are possible.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;#ponents#Relations Min Max Min Max Method straight-E/R a a e e object-oriented a e*a e 2 nulls e*a e*a 1 1 a b c d Males and Females subclasses are plete.Mothers and Fathers are partial.All subclasses are disjoint.We convert the ternary relationship Contracts into three binary relationships between a new entity set Contracts and existing entity sets.a b c A 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 least 5 courses to be classified FullTime.Customers Flights Bookings Customers Flights Bookings a Movies Studios Presidents Owns Runs Movies Studios Presidents Owns Runs b Since the subclasses are disjoint,Object Oriented Approach is used.The hierarchy is not plete.Hence four relations are required Movies MurderMysteries.Cartoons Cartoon-MurderMysteries Movies MurderMysteries Cartoons Cartoon-MurderMysteries c Customers Accounts Owns Customers Accounts Owns d Teams Players Fans Colors For Displays association,TeamColors RootsFor Admires Teams Players Fans Colors For Displays association,TeamColors RootsFor Admires e People People f Students Courses Departments Professors Takes Students Courses Departments Professors Takes a 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 attribute integer ssNo;attribute string name;attribute string addr;attribute string phone;relationship Set ownsAccts inverse Account:ownedBy;.class Account key attribute integer number;attribute string type;attribute real balance;relationship Set ownedBy inverse Customer:ownsAccts;a Modify class Account to contain relationship Customer ownedBy 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 Set d ODL allows structures and collections recursively.SetStruct addrstring street,string city,string state,Set Collections are allowed in ODL.Hence,Colors Set can bee an attribute of Teams.class Colorskey attribute string colorname;relationship Set FavoredBy inverse Fans:Favors;relationship set DisplayedBy inverse Teams:Displays;class Teamskey attribute string name;relationship set Displays inverse Colors:DisplayedBy;relationship set PlayedBy inverse Players:Plays;relationship PLayers CaptainedBy inverse Platyers:Captains;relationship set RootedBy inverse Fans:Roots;class Playerskey attribute string name;relationship Set Plays inverse Teams:PlayedBy;relationship Teams Captains inverse Teams:CaptainedBy;relationship Set AdmiredBy inverse Fans:Admires;class Fanskey attribute string name;relationship Colors Favors inverse Colors:FavoredBy;relationship Set RootedBy inverse Teams:Roots;relationship Set Admires inverse Players:AdmiredBy;class Person .attribute string name;relationship Person motherOf inverse Person:childrenOfFemale;relationship Person fatherOf inverse Person:childrenOfMale;relationship Set children inverse Person:parentsOf;relationship Set childrenOfFemale inverse Person:motherOf;relationship Set childrenOfMale inverse Person:fatherOf;relationship Set parentsOf inverse Person:children;The struct educationstring degree,string school,string date cannot have duplication.Hence use of Sets does not make any different as pared to bags,lists,or arrays.Lists will allow faster access/queries due to the already sorted nature.a class Departmentskey attribute string name;relationship Courses offers inverse Courses:offeredBy;class Courseskey attribute string number;relationship Departments offeredBy inverse Departments:offers;b class Leagues key attribute name;relationship Teams contains inverse Teams:belongs;class Teamskey attribute name,relationship Leagues belongs inverse Leagues:contains;relationship Players play inverse Players:plays;class Players key attribute number,relationship Teams plays inverse Teams:play;class Students attribute string email;attribute string name;relationship Courses isTA inverse Courses:TA;relationship Courses Takes inverse Courses:TakenBy;class Professors attribute string email;attribute string name;relationship Departments WorksFor inverse Department:Works;relationship Courses Teaches.inverse Courses:TaughtBy;class Courses key attribute string no;attribute string semester;attribute string section;relationship Students TA inverse Students:isTA;relationship Students TakenBy inverse Students:Takes;relationship Professors TaughtBy inverse Professors:Teaches;relationship Departments OfferedBy inverse Departments:Offer;class Departments attribute name;relationship Courses Offer inverse Courses:OfferedBy;relationship Professors Works inverse Professors:WorksFor;A 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.a Customers Account Owns b Accounts Customers Addresses Phones We can remove Addresses relation since its attributes are a subset of relation Phones.c Fans RootedBy Admires Players Teams-remove subset of teamcolor Teamcolors Colors d class Person attribute string name;relationship Person motherOf inverse Person:childrenOfFemale;relationship Person fatherOf inverse Person:childrenOfMale;relationship Set children inverse Person:parentsOf;relationship Set childrenOfFemale inverse Person:motherOf;relationship Set childrenOfMale inverse Person:fatherOf;relationship Set parentsOf inverse Person:children;.Person The children relationship is many-many but the information can be deduced from Person relation.Hence below relation is redundant.Parent-Child First consider each struct as if it were an atomic value i.e.key and value association pairs can be