Database Systems A Practical Approach to Design

Implementation and Management 6th Edition Connolly

Full download at:
Solution Manual:
https://testbankpack.com/p/solution-manual-for-database-systems-a-practical-approach-
to-design-implementation-and-management-6th-edition-by-connolly-and-begg-isbn-
0132943263-9780132943260/

SOLUTIONS TO REVIEW QUESTIONS

AND EXERCISES

FOR PART 7 – OBJECT DBMSs (CHAPTERS 27 – 28)

Database Systems: Instructor’s Guide - Part III

Solutions to Review Questions and Exercises

Chapter 27 Object-Oriented DBMSs – Concepts and Design ......................................................................... 3

Chapter 28 Object-Oriented DBMSs: Standards and Systems ....................................................................... 11

2
Database Systems: Instructor’s Guide - Part III

Chapter 27 Object-Oriented DBMSs – Concepts and Design

Review Questions

27.1 Describe the three generations of DBMSs.

First generation is the hierarchical and network DBMSs.

Second generation is the relational DBMSs.
Third generation is the object-oriented and object-relational DBMSs.

See Section 27.1.

27.2 Compare and contrast the different definitions of object-oriented data models.

Discussion of definitions provided in Section 27.2.1.

27.3 Describe the main modeling primitives of the functional data model.

The main modeling primitives are entities and functional relationships (see Section 27.2.2).

27.4 What is a persistent programming language and how does it differ from an OODBMS?

A language that provides its users with the ability to (transparently) preserve data across
successive executions of a program, and even allows such data to be used by different
programs (see Section 27.2.3). Main difference between PPL and OODBMS is that the
OODBMS tends to provide more DBMS-related services.

27.5 Discuss the difference between the two-level storage model used by conventional DBMSs and
the single-level storage model used by OODBMSs.

See Section 27.3.

27.6 How does this single-level storage model affect data access?

See Section 27.3.

27.7 Describe the main strategies that can be used to create persistent objects.

Checkpointing, serialization, and explicit paging. Explicit paging includes reachability-based and
allocation-based persistence (see Section 27.3.3).

27.8 What is pointer swizzling? Discuss the different approaches to pointer swizzling.

Action of converting OIDs to main memory pointers (See Section 27.3.1).

3
Database Systems: Instructor’s Guide - Part III

27.9 Describe the types of transaction protocol that can be useful in design applications.

See Sections 27.4.1 and 22.4.

27.10 Discuss why version management may be a useful facility for some applications.

There are many applications that need access to the previous state of an object. For example, the
development of a particular design is often an experimental and incremental process, the scope of
which changes with time. It is therefore necessary in databases that store designs to keep track of
the evolution of design objects and the changes made to a design by various transactions. See
Section 27.4.2.

27.11 Discuss why schema control may be a useful facility for some applications.

Engineering design is an incremental process and evolves with time. To support this process,
applications require considerable flexibility in dynamically defining and modifying the database
schema. For example, it should be possible to modify class definitions, the inheritance structure,
and specifications of attributes and methods without requiring system shutdown. See Section
27.4.3.

27.12 Describe the different architectures for an OODBMS.

See Section 27.4.4.

27.13 List the advantages and disadvantages of an OODBMS.

See Section 27.5.

27.14 Describe how relationships can be modelled in an OODBMS.

See the discussion on Section 27.6.2.

27.15 Describe the different modelling notations in the UML.

Expect discussion of the notations for:

 Structural diagrams, which describe the static relationships between components, and
include:
o class diagrams,
o object diagrams,
o component diagrams,
o deployment diagrams.
 Behavioral diagrams, which describe the dynamic relationships between components, and
include:
o use case diagrams,
o sequence diagrams,

4
Database Systems: Instructor’s Guide - Part III

o collaboration diagrams,
o statechart diagrams,
o activity diagrams.

Exercises

27.16 For the DreamHome case study documented in Appendix A, suggest attributes and methods
that would be appropriate for Branch, Staff, and PropertyForRent classes.

The attributes should be similar to those documented in the textbook. The student would be
expected to come up with standard get/set methods, such as GetStaffSalary, PutStaffSalary,
and then methods for registering new properties for rent, new owners, new clients,
appointments for viewings, and so on.

27.17 Produce use case diagrams and a set of associated sequence diagrams for the DreamHome case
study documented in Appendix A.

Students should use the “Data Transactions” sections of Appendix A to derive a list of use
cases. The diagrams should be similar to those seen in Figure 27.20 for use cases and 27.21
for sequence diagrams. In Section A.1 the actor is Branch User, and in Section A.2 the actor is
Staff User.

27.18 Produce use case diagrams and a set of associated sequence diagrams for the University
Accommodation Office case study documented in Appendix B.1.

Students should use the “Query Transactions” sections of Appendix B.1 to derive a list of use
cases. The diagrams should be similar to those seen in Figure 27.20 for use cases and 27.21
for sequence diagrams. The actor is administrative user.

27.19 Produce use case diagrams and a set of associated sequence diagrams for the Easy Drive
School of Motoring case study documented in Appendix B.2.

Students should use the “Query Transactions” sections of Appendix B.2 to derive a list of use
cases. The diagrams should be similar to those seen in Figure 27.20 for use cases and 27.21
for sequence diagrams. The actor is administrative user.

27.20 Produce use case diagrams and a set of associated sequence diagrams for the Wellmeadows
Hospital case study documented in Appendix B.3.

Students should use the “Transaction Requirements” sections of Appendix B.3 to derive a list
of use cases. The diagrams should be similar to those seen in Figure 27.20 for use cases and
27.21 for sequence diagrams. The actor is hospital worker.

5
Database Systems: Instructor’s Guide - Part III

27.21 You have been asked by the Managing Director of DreamHome to investigate and prepare a
report on the applicability of an OODBMS for your organization. The report should compare
the technology of the RDBMS with that of the OODBMS, and should address the advantages
and disadvantages of implementing an OODBMS within the organization, and any perceived
problem areas. Finally, the report should contain a fully justified set of conclusions on the
applicability of the OODBMS for DreamHome.

A well-presented report is expected. Justification must be given for any recommendations

made.

27.22 For the relational Hotel schema in the Exercises at the end of Chapter 4, suggest a number of
methods that would be applicable to the system. Produce an object-oriented schema for the
system.

Some methods might be:

createNewHotel destroyHotel changeHotelName
getHotelName
createNewRoom destroyRoom changeRoomPrice
changeRoomType getRoomPrice getRoomType
createNewGuest destroyGuest changeGuestName
changeGuestAddress getGuestName getGuestAddress
createNewBooking destroyBooking changeRoomNumber
changeDates getDateFrom getDateTo

Room Hotel
Contains
roomNo {PK} hotelNo {PK}
hotelNo {PK} 1..* 1..1 hotelName
type city
price
createNewHotel
createNewRoom destroyHotel
destroyRoom changeHotelName
changeRoomPrice getHotelName
changeRoomType
getRoomPrice
getRoomType

1..1

Gets

1..*

Booking Makes Guest

hotelNo {PK} guestNo {PK}
guestNo {PK} 1..* 1..1 guestName
dateFrom {PK} guestAddress
dateTo
roomNo createNewGuest
destroyGuest
createNewBooking changeGuestName
destroyBooking changeGuestAddress
changeRoomNumber getGuestName
changeDates getGuestAddress
getDateFrom
getDateTo

6
Database Systems: Instructor’s Guide - Part III

27.23 For the relational Project schema in the Exercises at the end of Chapter 5, suggest a number of
methods that would be applicable to the system. Produce an object-oriented schema for the
system.

27.24 For the relational Library schema in the Exercises at the end of Chapter 5, suggest a number of
methods that would be applicable to the system. Produce an object-oriented schema for the
system.

27.25 Produce an object-oriented database design for the DreamHome case study documented in
Appendix A. State any assumptions necessary to support your design.

The student should produce a model similar to Figure 16.9 with some methods added. You
may prefer to get the student to do this particular exercise in two parts: one to produce an
object-oriented design for the Staff view and one for the Branch view.

27.26 Produce an object-oriented database design for the University Accommodation Office case study
presented in Appendix B.1. State any assumptions necessary to support your design.

The student should produce a model similar to that given in the solution to Exercise 16.16 with
some methods added.

27.27 Produce an object-oriented database design for the EasyDrive School of Motoring case study
presented in Appendix B.2. State any assumptions necessary to support your design.

The student should produce a model similar to that given in the solution to Exercise 16.18 with
some methods added.

27.28 Produce an object-oriented database design for the Wellmeadows Hospital case study presented
in Appendix B.3. State any assumptions necessary to support your design.

The student should produce a model similar to that given in the solution to Exercise 16.21 with
some methods added. Again, you may prefer to get the student to do this particular exercise based
on the particular views that have been identified (Charge Nurse, Director, and Personnel).

7
 Database Systems: Instructor’s Guide - Part III

27.29 Repeat Exercises 27.22 to 27.28 but produce a schema using the functional data model.
Diagramatically illustrate each schema.

(a) Hotel case study.

string
string string
string

hotelName hotelName
string city
hotelNo
RoomIn city string
hotelNo Room Hotel
sex
Contains

Gets BookingFor

string
guestName
date
MadeBy guestNo
dateFrom string
Booking
Guest
dateTo Makes
date guestAddress
string

8
 Database Systems: Instructor’s Guide - Part III

(b) University Accommodation Office case study

Sample solution as follows (only primary key shown):

string

invoiceNo

Invoice

Generates GeneratedFor
string string
placeNo
leaseNo
Provides For
Accommodation Room Lease

RoomIn LeaseFor sex

string
IS-A IS-A
hallNo flatNo Requests RequestedBy
string

Hall Flat

Has string

matricNo
InspectionFor

Inspection Student
ManagedBy Manages

Undertakes NOKFor AttendedBy Attends

UndertakenBy HasNOK

Staff NOK Course

sex

staffNo courseNo

string string

Using the above two diagrams as exemplars and the solutions to Exercises 27.23 and 25.28,
should be relatively straightforward to create the diagrams for the remaining case studies.

9
Database Systems: Instructor’s Guide - Part III

27.30 Using the rules for schema consistency given in Section 27.4.3 and the sample schema given
in Figure 27.11, consider each of the following modifications and state what the effect of the
change should be to the schema:

(a) adding an attribute to a class

(b) deleting and attribute from a class
(c) renaming and attribute
(d) Making a class S a superclass of a class C
(e) removing a class S from the list of superclasses of a class C
(f) creating a new class C
(g) deleting a class
(h) modifying class names.

See Section 27.4.3.

10
Database Systems: Instructor’s Guide - Part III

Chapter 28 Object-Oriented DBMSs: Standards and Systems

Review Questions

28.1 Discuss the main concepts of the ODMG Object Model. Give an example to illustrate each of
the concepts.

The ODMG OM is a superset of the OMG OM and specifies the following basic modeling
primitives:
 The basic modeling primitives are the object and the literal. Only an object has a unique
identifier.
 Objects and literals can be categorized into types. All objects and literals of a given type
exhibit common behavior and state. A type is itself an object. An object is sometimes
referred to as an instance of its type.
 Behavior is defined by a set of operations that can be performed on or by the object.
Operations may have a list of typed input/output parameters and may return a typed
result.
 State is defined by the values an object carries for a set of properties. A property may be
either an attribute of the object or a relationship between the object and one or more
other objects. Typically, the values of an object’s properties can change over time.
 An ODMS stores objects, enabling them to be shared by multiple users and applications.
An ODMS is based on a schema that is defined in the Object Definition Language
(ODL), and contains instances of the types defined by its schema.

See Section 28.2.2.

28.2 What is the function of the ODMG Object Definition Language?

ODL is a language for defining the specifications of object types for ODMG-compliant
systems, equivalent to the Data Definition Language (DDL) of traditional DBMSs. Its main
objective is to facilitate portability of schemas between compliant systems while helping to
provide interoperability between ODMSs. The ODL defines the attributes and relationships of
types and specifies the signature of the operations, but it does not address the implementation
of signatures. The syntax of ODL extends the Interface Definition Language (IDL) of the
CORBA. The ODMG hope that the ODL will be the basis for integrating schemas from
multiple sources and applications. See Section 28.2.3.

28.3 What is the function of the ODMG Object Query Language?

ODMG OQL is used to specify how database objects are retrieved and manipulated within the
application program (see Section 28.2.4).

11
Database Systems: Instructor’s Guide - Part III

28.4 How does the ODMG GROUP BY clause differ from the SQL GROUP BY clause? Give an
example to illustrate your answer.

The OQL GROUP BY has been extended to provide an explicit reference to the collection of
objects within each group (which in OQL is called a partition). See Example 28.6.

28.5 How does the ODMG aggregate functions differ from the SQL aggregate functions? Give an
example to illustrate your answer.

The OQL aggregate functions can be applied within the select clause or to the result of the
select operation. For example, the following two expressions are equivalent in OQL:

SELECT COUNT(s) FROM s IN salesStaff WHERE s.WorksAt.branchNo = ‘B003’;

COUNT(SELECT s FROM s IN salesStaff WHERE s.WorksAt.branchNo = ‘B003’);

Note, OQL allows aggregate functions to be applied to any collection of the appropriate type
and , unlike, SQL, can be used in any part of the query. See Example 28.5.

28.6 What is the function of the ODMG Object Interchange Format?

The Object Interchange Format (OIF) is a specification language used to dump and load the
current state of an ODMS to and from one or more files. OIF can be used to exchange
persistent objects between ODMSs, seed data, provide documentation, and drive test suites.
See Section 28.2.5.

28.7 Briefly discuss how the ODMG C++ language binding works.

A C class library is provided containing classes and functions that implement the ODL
constructs. In addition, OML (Object Manipulation Language) is used to specify how database
objects are retrieved and manipulated within the application program. To create a working
application, the C ODL declarations are passed through a C ODL preprocessor, which
has the effect of generating a C header file containing the object database definition and
storing the ODMS meta-data in the database. The user’s C application, which contains
OML, is then compiled in the normal way along with the generated object database definition
C header file. Finally, the object code output by the compiler is linked with the ODMS
runtime library to produce the required executable image. See Section 28.2.5.

Exercises

28.8 Map the object-oriented design for the Hotel case study produced in Exercise 27.22 to the ODMG
ODL.

class Hotel {
(extent hotels key hotelNo)
attribute string hotelNo;
attribute string hotelName;

12
Database Systems: Instructor’s Guide - Part III

attribute string city;

relationship set<Room> Contains inverse Room::ContainedIn;
…
}

class Room {
(extent rooms key hotelNo, roomNo)
attribute string hotelNo;
attribute string roomNo;
attribute string hotelName;
attribute string city;
relationship <Hotel> ContainedIn inverse Hotel::Contains;
relationship set<Booking> Gets inverse Booking::MadeFor;

changeRoomPrice(in roomNo:string, in float)raises(noSuchRoom);

changeRoomType(in roomNo:string, in char) raises(noSuchRoom);
…
}

class Guest {
(extent guests key guestNo)
attribute string guestNo;
attribute string guestName;
attribute string guestAddress;
relationship set<Booking> Makes inverse Booking::MadeFor;
…
}

class Booking {
(extent bookings key (hotelNo, guestNo, dateFrom))

attribute string hotelNo;

attribute string guestNo;
attribute date dateFrom;
attribute date dateTo;
attribute string roomNo;

relationship <Room> MadeFor inverse Room::Gets;

relationship Guest MadeFor inverse Guest::Makes;

createNewBooking(in Hotel, in Guest, in Room)

raises(noSuchHotel, noSuchGuest, hotelFull)
changeRoomNumber();
changeDates();
…
}

13
Database Systems: Instructor’s Guide - Part III

Show how the following queries would be written in OQL:

(a) List all hotels.

hotel

or to sort them:

sort h IN Hotel by h.name

(b) List all single rooms with a price below £20.00 per night.

SELECT h.rooms
FROM h IN hotel
WHERE h.rooms.price < 20

(c) List the names and addresses of all guests.

SELECT STRUCT(name:g.name, address:g.address)

FROM g IN guest

(d) List the price and type of all rooms at the Grosvenor Hotel.

type prices {attribute price : float; type: char;}

prices (SELECT STRUCT(price:h.rooms.price, type:h.rooms.type)
FROM h IN hotel
WHERE h.name = ‘Grosvenor Hotel’

(e) List all guests currently staying at the Grosvenor Hotel.

SELECT g
FROM g IN guests
b IN g.booked_for
h IN b.booking_for
WHERE b.dateFrom <= ‘01-01-05’ AND
b.dateTo >= ‘01-01-05’ AND
h.name = ‘Grosvenor Hotel’

(substitute ‘01-01-05’ for today’s date).

(f) List the details of all rooms at the Grosvenor Hotel, including the name of the guest
staying in the room, if the room is occupied.

define occupied as
SELECT STRUCT(h.rooms,

14
Database Systems: Instructor’s Guide - Part III

SELECT g.name
FROM g IN guest
b IN g.booked_for
h IN b.booking_for
WHERE b.dateFrom <= ‘01-01-15’ AND
b.dateTo >= ‘01-01-15’ AND
h.name = ‘Grosvenor Hotel’)
FROM h IN hotel
UNION
SELECT STRUCT(h.rooms, nil)
FROM h IN hotel, y IN occupied
WHERE h.rooms.roomNo != y.roomNo

(substitute ‘01-01-15’ for today’s date).

(g) List the guest details (guestNo, name and address) of all guests staying at the Grosvenor
Hotel.

SELECT STRUCT(guestNo:g.guestNo, name:g.name, address:g.address)

FROM g IN g IN guest
b IN g.booked_for
h IN b.booking_for
WHERE b.dateFrom <= ‘01-01-15’ AND
b.dateTo >= ‘01-01-15’ AND
h.name = ‘Grosvenor Hotel’

(substitute ‘01-01-15’ for today’s date).

28.11 Map the object-oriented database design for the DreamHome case study produced in Exercise
27.25 to the ODMG ODL.

Partial solution as follows:

class Branch {
(extent branches key branchNo)

attribute string branchNo;

attribute struct BranchAddress {string street, string city, string postcode} address;
attribute list< string> telNo[3];

relationship set<Registration> Registers inverse Client::IsRegisteredWith;

relationship Staff Has inverse Staff::WorksIn;
relationship Manager IsManagedBy inverse Manager::Manages;
relationship set<PropertyForRent> Offers inverse PropertyForRent IsOfferedBy;
}

15
Database Systems: Instructor’s Guide - Part III

class Person {
attribute struct PName {string fName, string lName} name;
}

class Staff extends Person {

(extent staff key staffNo)

attribute string staffNo;

attribute enum SetType {M, F} sex;
attribute date DOB;
attribute enum PositionType {Manager, Supervisor, Assistant} position;
attribute float salary;

relationship Branch WorksIn inverse Branch::Has;

relationship set<PropertyForRent> Oversees inverse PropertyForRent::IsOverseenBy;
relationship set<Registration> Processes inverse Registration::IsProcessedBy;
relationship set<Staff > Supervises inverse Staff::SupervisedBy;

increaseSalary(in Staff, in float) raises(noSuchPerson);

overseeProperty(in Staff, in PropertyForRent) raises(noSuchPerson, noSuchProperty);
moveBranch(in Staff, in from::Branch, in to::Branch) raises(noSuchPerson, noSuchBranch);
}

class Manager extends Staff {

(extent managers)

attribute date mgrStartDate;

attribute float bonus;

relationship Branch Manages inverse Branch::IsManagedBy;

}

class PropertyForRent {
(extent rentals key propertyNo)

attribute string propertyNo;

attribute struct PropertyAddress {string street, string city, string postcode} address;
attribute string type;
attribute integer rooms;
attribute float rent;

relationship Staff IsOverseenBy inverse Staff::Oversees;

relationship Branch IsOfferedBy inverse Branch::Offers;
relationship set<Advert> PlacedIn inverse Advert::Advertises;
relationship Owner IsOwnedBy inverse Owner::Owns;
relationship set<Viewing> Takes inverse Viewing::IsTakenBy;

16
Database Systems: Instructor’s Guide - Part III

relationship set<Lease> LeasedBy inverse Lease::LeaseFor;

rentOut(in PropertyForRent) raises(noSuchProperty);

}

class Client extends Person{

(extent clients key clientNo)

attribute string clientNo;

attribute string telNo;
attribute string prefType;
attribute float maxRent;

relationship Registration Agrees inverse Registration::RegistrationFor;

relationship set<Viewing> Requests inverse Viewing::IsRequestedBy;
relationship set<Lease> Holds inverse Lease::IsHeldBy;

rentProperty(in Client, in PropertyForRent) raises(noSuchClient, noSuchProperty);

register(in Client, in Branch) raises(noSuchClient, noSuchBranch);
arrangeViewing(in Client, in PropertyForRent) raises(noSuchClient, noSuchProperty);
}

28.12 Map the object-oriented database design for the University Accommodation Office case study
produced in Exercise 27.26 to the ODMG ODL.

Using the object-oriented design produced in Exercise 27.26 and the relational schema given
in the solution to Exercise 17.10, then the answer can easily be derived in a similar manner to
the two solutions above and the solution to Exercise 28.14 below.

28.13 Map the object-oriented database design for the EasyDrive School of Motoring case study
produced in Exercise 27.27 to the ODMG ODL.

Using the object-oriented design produced in Exercise 27.27 and the relational schema given
in the solution to Exercise 17.11, then the answer can easily be derived in a similar manner to
the two solutions above and the solution to Exercise 28.14 below.

28.14 Map the object-oriented database design for the Wellmeadows case study produced in
Exercise 27.28 to the ODMG ODL.

The following is a sample schema, not all methods are shown:

class Ward {
(extent wards key wardNo)

attribute string wardNo;

attribute string wardName;

17
Database Systems: Instructor’s Guide - Part III

attribute string location;

attribute integer totalBeds;
attribute string telExtn;

relationship list<WaitingList> HasWaitingList

inverse WaitingList::IsWaitingFor
{order_by WaitingList::listDate, wardReq};
relationship list<StaffRota> HasStaffRota
inverse StaffRota::OnShiftFor
{order_by StaffRota::wardNo, weekNo};
relationship set<Requisition> Receives inverse Requisition::ReqFor;
relationship Nurse IsChargeNurseFor inverse Nurse::ChargeFor;

assignChargeNurse(in Nurse) raises(noSuchNurse);

}

class Person {
attribute struct PName {string fName, string lName} name;
attribute string address;
attribute string telNo;
attribute date DOB;
attribute char sex;
}

deftype struct Qualification {date qDate, string qType, string institutionName;}

deftype struct WorkExperience {date sDate, date fDate, string position, string orgName;}
class Staff extends Person {
(extent staff key staffNo, NIN)

attribute string staffNo;

attribute string NIN;
attribute string position;
attribute float salary;
attribute integer sScale;
attribute integer weekHrs;
attribute char contType;
attribute char typePay;
attribute set<Qualification> qualifications;
attribute set< WorkExperience> experience;

relationship list<StaffRota> HasRota

inverse StaffRota::ShiftFor
{order_by StaffRota::staffNo, weekNo};

increaseSalary(in Staff, in float);

}

18
Database Systems: Instructor’s Guide - Part III

class Nurse extends Staff {

(extent nurses)

relationship Ward ChargeFor inverse Ward:: IsChargeNurseFor;

relationship set<Requisition> Makes inverse Requisition::IsMadeBy;

makeRequisition(in Nurse, in Pharmaceutical) raises(noSuchDrug);

}

class Consultant extends Staff {

(extent consultants)

relationship list<Appointment> Sees

inverse Appointment::IsSeenBy
{order_by Appointment::consStaffNo, aDate, appTime};

cancelAppointment(in Consultant, in Appointment);

}

class StaffRota {
(extent rotas)

attribute integer shift;

attribute integer weekNo;

relationship Ward OnShiftFor inverse Ward::HasStaffRota;

relationship Staff ShiftFor inverse Staff::HasRota;
}

deftype struct NextOfKin {string nName, string nRelationship, string nAddress, string nTelNo;}
deftype struct OutPatientAppointment {date outPatDate, time outPatTime;}
class Patient extends Person{
(extent patients key patNo)

attribute string patNo;

attribute char mStatus;
attribute date dateReg;
attribute <NextOfKin> NOK;
attribute set<OutPatientAppointment> appointment;

relationship Doctor IsReferredBy inverse Doctor::Refers;

relationship set<Appointment> Attends inverse Appointment::ApptFor;
relationship set<Medication> Takes inverse Medication::IsTakenBy;
relationship list<WaitingList> WaitsFor inverse WaitingList::IsOn;

19
Database Systems: Instructor’s Guide - Part III

changeDoctor(in from:Doctor, in to:Doctor) raises(noSuchDoctor);

cancelAppointment(in Appointment) raises(noSuchAppointment);
}

class Doctor {
(extent gps key (docName, clinicNo))

attribute string docName;

attribute string address
attribute string telNo;
attribute string clinicNo;

relationship set<Patient> GPFor inverse Patient::HasGP;

}

class Appointment {
(extent appointments key appNo)

attribute string appNo;

attribute date appDate;
attribute time appTime;
attribute string roomNo;

relationship Patient IsApptFor inverse Patient::HasAppt;

relationship Consultant IsSeenBy inverse Consultant::Sees;
}

class WaitingList {
(extent waiting )

attribute date listDate;

attribute interval duration;
attribute date placedDate;
attribute date exLeaveDate;
attribute date actLeaveDate;
attribute string bedNo;

relationship Ward IsWaitingFor inverse Ward::HasWaitingList;

relationship Patient IsOn inverse Patient::WaitsFor;

addToList(in Patient, in Ward) raises(noSuchPatient, noSuchWard);

removeFromList(in Patient, in Ward) raises(noSuchPatient, noSuchWard);
}

class Medication {
(extent medications)

20
Database Systems: Instructor’s Guide - Part III

attribute string unitsDay;

attribute string aMethod;
attribute date sDate;
attribute date fDate;

relationship Patient IsTakenBy inverse Patient::Takes;

relationship Pharmaceutical Contains inverse Pharmaceutical::Forms;

addMedication(in Patient, in Pharmaceutical) raises(noSuchPatient, noSuchDrug);

changeMedication(in Patient, in Pharmaceutical) raises(noSuchPatient, noSuchDrug);
}

class Pharmaceutical {
(extent drugs key drugNo)

attribute string drugNo;

attribute string dName;
attribute string description;
attribute string dosage;
attribute string methodAdmin;
attribute integer quantityStock;
attribute integer reorderLevel;
attribute float unitCost;

relationship set<Medication> Forms inverse Medication::Contains;

relationship set<Requisition> PFor inverse Requisition::PReqsFor;
relationship Supplier PIsProvidedBy inverse Supplier::PProvides;
}

class Non-Surgical/Surgical {
(extent supplies key itemNo)

attribute string itemNo;

attribute string iName;
attribute string iDescription;
attribute integer quantityStock;
attribute integer reorderLevel;
attribute float unitCost;

relationship set<Requisition> IFor inverse Requisition::IReqsFor;

relationship Supplier IIsProvidedBy inverse Supplier::IProvides;
}

class Requisition {
(extent requisitions key reqNo)

21
Database Systems: Instructor’s Guide - Part III

attribute string reqNo;

attribute integer quantReq;
attribute date dateOrder;
attribute date dateReceive;

relationship Ward ReqFor inverse Ward::Receives;

relationship Nurse IsMadeBy inverse Nurse::Makes;
relationship Pharmaceutical PReqsFor inverse Pharmaceutical::PFor;
relationship Non-Surgical/Surgical IReqsFor inverse Non-Surgical/Surgical::IFor;
}

class Supplier {
(extent suppliers key supplierNo)

attribute string supplierNo;

attribute string sName;
attribute string sAddress;
attribute string telNo;
attribute string faxNo;

relationship set<Pharmaceutical> PProvides inverse Pharmaceutical::PIsSuppliedBy;

relationship set<Non-Surgical/Surgical> IProvides inverse Pharmaceutical::IisSuppliedBy;
}

22