c)

4.4.4 a)

b)

4.5.1

Customers(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 weak entity set Bookings already contains the keys of Customers and Flights.

4.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 into

Bookings(flightNo,flightDay,row,seat,custSSNo)

However custSSNo is no longer a key of Bookings relation. It becomes a foreign key instead.

4.5.3

Ships(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.1

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

LabCourses(number, deptName, room, allocation)

(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 relationship Married can be included in Father (or Mother). 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. (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.