4.7.6
4.7.7
4.7.8
We convert the ternary relationship Contracts into three binary relationships
between a new entity set Contracts and existing entity sets.
4.7.9
a)
b)
c)
4.7.10
A self-association ParentOf for entity set people has multiplicity 0..2 at
parent role end.
4.8.1
Customers(SSNo,name,addr,phone)
4.8.2
a)
Movies(title,year,length,genre)
Studios(name,address)
Presidents(cert#,name,address)
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)
c)
Customers(ssNo,name,phone,address)
Accounts(number,balance,type)
Owns(custSSNo,accountNumber)
d)
Teams(name,captainName)
Players(name,teamName)
Fans(name,favoriteColor)
Colors(colorname)
e)
People(ssNo,name,fatherSSNo,motherSSNo)
f)
Students(email,name)
Courses(no,section,semester,professorEmail)
4.8.3
a)
Each and every object is a member of exactly one subclass at leaf level. We have
b)
All objects only belong to one subclass and its ancestors. Hence, we need not
c)
We need all possible subtrees. Hence 218 relations are required.
4.9.1
class Customer (key (ssNo)){
attribute integer ssNo;
attribute string name;
4.9.2
a)
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
4.9.3
Collections are allowed in ODL. Hence, Colors Set can become an attribute of
Teams.
class Colors(key(colorname)){
attribute string colorname;
relationship Set<Fans> FavoredBy
inverse Fans::Favors;
};
class Players(key(name)){
attribute string name;
relationship Set<Teams> Plays
};
class Fans(key(name)){
attribute string name;
relationship Colors Favors
};
4.9.4
class Person {
attribute string name;
relationship Person motherOf
};
4.9.5
The struct education{string degree,string school,string date} cannot have
4.9.6
a)
class Departments(key (name)) {
attribute string name;
relationship Courses offers
b)
class Leagues (key (name)) {
attribute name;
relationship Teams contains
inverse Teams::belongs;
};
4.9.7
class Students (key email) {
attribute string email;
attribute string name;
};
class Courses (key (no,semester,section)) {
attribute string no;
attribute string semester;
attribute string section;
relationship Students TA
inverse Students::isTA;
class Departments (key name) {
attribute name;
relationship Courses Offer
inverse Courses::OfferedBy;
relationship Professors Works
inverse Professors::WorksFor;
};
4.9.8
A relationship is its own inverse when for every attribute pair in the
4.10.1
a)
Customers(ssNo,name,addr,phone)
b)
Accounts(number,balance,type,owningCustomerssNo)
Customers(ssNo,name)
c)
Fans(name,colors)
RootedBy(fan_name,teamname)
d)
class Person {
attribute string name;
relationship Person motherOf
inverse Person::childrenOfFemale;
};
Person(name,mothername,fathername)
The children relationship is many-many but the information can be deduced from
4.10.2
First 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
4.10.3
(a)
Struct Card { string rank, string suit };
(b)
class Hand {
attribute Set theHand;
(d) Hand contains an array of 5 elements
(e)
class Deal {
attribute Set <Struct PlayerHand { string Player, Hand theHand }
> theDeal;
}
(h)
dealID is a key for Deals. Thus the relations for classes Deals and Hands are:
Deals(dealID, player, handID)
Hands(handID, rank, suit)
4.10.4
(a)
C(a, f, g)
(b)