COMP1711 Data Modelling Assignment Part II Feel Good Clinic

14
Data Modelling Assignment Part II COMP1711 Flinders University Page 1 of 4 2020 COMP1711 Data Modelling Assignment Part II Feel Good Clinic DEADLINE: 11.55pm, Friday of Week 13 (6 th of November) This is not an assignment that can be done at the last minute! This assignment involves two electronic submissions (PDF and .sql via FLO). You are encouraged to work in pairs for this assignment, however it is not mandatory that you do so. You do not need to work with the same partner as Assignment Part I. A pair is two people. WORTH: The assignment is worth 30% of the assessment. 1 General Specification (a) Derive relations from the supplied Entity-Relationship Diagram given below into a logical model representation in terms of the relational data model. Identify a primary key for each relation and subsequently all foreign keys. You need to use the database description language (DBDL) as described in Chapter 17 of the textbook, for example You also need to justify the reasoning behind the derivation (e.g. why does it contain a foreign key, can the foreign key be NULL, why has a particular ON UPDATE been chosen, etc.), for example: Client is a strong entity. The composite attribute name has only its constituent simple attributes fName and lName listed. prefType has been merged into the Client entity from the Preference entity from a 1:1 States relationship with mandatory participation on both sides. staffNo has been posted into the Client relation from a 1:* Registers relationship where Client was the child and Staff was the parent. staffNo is NOT NULL as Client has mandatory participation in the Registers relationship. UPDATE CASCASE was chosen to update staffNo whenever the attribute changes in the Staff table. DELETE NO ACTION has been selected to stop Staff being deleted without first updating Client.

Transcript of COMP1711 Data Modelling Assignment Part II Feel Good Clinic

Page 1: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

Data Modelling Assignment Part II COMP1711

Flinders University Page 1 of 4 2020

COMP1711

Data Modelling Assignment Part II

Feel Good Clinic DEADLINE: 11.55pm, Friday of Week 13 (6th of November)

This is not an assignment that can be done at the last minute!

This assignment involves two electronic submissions (PDF and .sql via FLO).

You are encouraged to work in pairs for this assignment, however it is not mandatory that you do so.

You do not need to work with the same partner as Assignment Part I. A pair is two people.

WORTH: The assignment is worth 30% of the assessment.

1 General Specification

(a) Derive relations from the supplied Entity-Relationship Diagram given below into a logical

model representation in terms of the relational data model. Identify a primary key for each

relation and subsequently all foreign keys.

You need to use the database description language (DBDL) as described in Chapter 17 of the

textbook, for example

You also need to justify the reasoning behind the derivation (e.g. why does it contain a foreign

key, can the foreign key be NULL, why has a particular ON UPDATE been chosen, etc.), for

example:

Client is a strong entity. The composite attribute name has only its constituent

simple attributes fName and lName listed. prefType has been merged into the Client

entity from the Preference entity from a 1:1 States relationship with mandatory

participation on both sides. staffNo has been posted into the Client relation from a

1:* Registers relationship where Client was the child and Staff was the parent.

staffNo is NOT NULL as Client has mandatory participation in the Registers

relationship. UPDATE CASCASE was chosen to update staffNo whenever the

attribute changes in the Staff table. DELETE NO ACTION has been selected to stop

Staff being deleted without first updating Client.

Page 2: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

Data Modelling Assignment Part II COMP1711

Flinders University Page 2 of 4 2020

(b) Translate your answer to (a) into SQL (in a file .sql) and build the database using capabilities of

SQLite. Include the relevant DROP statements and specify ALL primary and foreign keys. If want

to demonstrate ISO SQL that is not available in SQLite than include as a comment, but ensure that

you have correct, runnable SQLite database as well. You also need to populate your database

(INSERT INTO …) with some sample data and perform some simple queries to ensure it works

correctly.

2 Submissions The submission of any work will be taken as your claim that it is your own work (or that of you and

your partner if working in pairs), i.e. that you cognitively and physically created it. It also signals your

agreement to re-do it or similar work under supervision if any doubts are raised about your

authorship of the work.

The required submission for Part II of the assignment is:

Submit part (a) on FLO as a PDF containing the description of the derived relations and your

reasoning behind the derivation of the relation.

Submit part (b) on FLO as a SQLite .sql file that can be executed on SQLite ver 3.x. You will be

penalised heavily if the file does not execute without errors.

You may also submit an assumption and clarification document to assist in interpreting your

derivations and implementation.

3 Assessment If you a working as a pair each member will receive the same overall mark.

The assignment is worth 30% of the total assessment. It will be marked out of 60. A guide to the

breakdown of the marks over the parts is

(a) 40 marks

(b) 20 marks

The assumption and clarification document will not formally assessed.

This is only a guide since the submissions are inter-dependent and will not be marked

independently. Inconsistencies between them will lose marks.

4 Specifications PLEASE base the design on the description i.e. treat the description like requirements. Failure to

adhere to the description is very poor professional practice. (If you really believe the description is

invalid, please discuss it with me as soon as possible.) I am quite happy, in consulting, to explain any

part of the description that is problematic. Also keep up to date on FLO for any clarifications.

Page 3: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

Data Modelling Assignment Part II COMP1711

Flinders University Page 3 of 4 2020

4.1 Feel Good Clinic

The Feel Good Clinic requires a system to manage the scheduling of appointments, in its mega-

surgery complex, and the billing of patients.

Each treatment room in the clinic has a unique number (N 3). Each doctor has a unique identifier

code (S 2) recorded along with their name (C), contact phone number (S 14) and one to three

qualifications (each S 10). Each doctor has one or two surgeries in which they work. More than one

doctor will use the same room at different times (a doctor only uses one room at a time.) but a

doctor will have a preferred room.

Each patient or customer is uniquely identified by a client number (N 8) which is assigned to them

when they first become associated with the clinic and is used for them thereafter. Also recorded is

their name (C), address (A). A customer is responsible for paying the bills for one or more patients.

Usually, but not always, this will include themselves. For instance, a parent might be a customer

without being a patient if they pay the bills for their child who is a patient.

For each actual patient, their birth-date (D) and their Medicare number (S 12) are also recorded,

along with which customer is currently responsible for paying for their treatment. The responsible

customer also has one to three contact phone numbers (S 14) and an email address (S 50).

For each service available, the prescribed code (S 4) is recorded along with a description (S 20) and

the current service fee ($ 3). Also identified are those doctors who give this service. Most doctors

give a large number of services but not all of them.

When a patient requires some treatment, one or more appointments are scheduled; each

appointment is for a particular date and starting time (D) with a specific doctor. Appointments are

made in hour blocks; on the hour. (At any one time there is only one appointment for a particular

surgery and a particular doctor). A patient does not have to be seen by the same doctor across

different appointments but each appointment is with a single doctor.

At the end of an appointment, an invoice is generated. Each invoice also a unique invoice number (N

5), it identifies the patient and the doctor involved, as well as the customer billed. It records the

relevant date (D), a clinical comment (S 200) if one is provided and the total fee ($ 4). The invoice

initially has a status (S 1) of ‘C’ (“completed”). At some later stage, the status is changed to ‘B’ (“bill

sent”) and eventually the status is changed to ‘P' (“paid”). Each of the invoice's include one to five

lines that identify the services given during the appointment.

Page 4: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

Data Modelling Assignment Part II COMP1711

Flinders University Page 4 of 4 2020

4.2 Operations and Questions The “Operations and Questions” are here to help verify/validate you design. You do not need to

provide answers to questions for the assignment.

• Add a new appointment

• Who has booked the most appointments?

• Find the doctor who gives the service X

• Which service is the most/least popular?

• Which doctor is used the most?

• Which treatment is used the most?

• List all the appointments for the month of X

• Which is the doctor has the smallest number of patients?

• Which service has made the clinic the most money?

• Which clients have not paid and what is the outstanding amount and the contact details?

• Which doctor has the most services offered?

• What service is required for appointment X?

5. Scope Creep! The customer loves the design that was create and, as always, the customer now has some more

ideas for you to include – otherwise known as “scope creep”. We usually try to avoid this but there

are a few good ideas that we will include:

• Doctors can vary the standard fee and fees may change. So we need to store the actual fee of a service given in an appointment. We can realise this as an attribute on the relationship Required For between service and appointment.

• Doctors must be able to work in more than 2 rooms, however, the Doctors Union has suggested that there must be a limit as how can a Doctor be expected to work in just any room! A resolution was made that doctors must nominate 10 rooms they will works in (it’s a really big mega clinic), but can still specify a preferred room. This will alter the multiplicity on the Works In relationship between Doctor and Room.

These changes have been included in the documentation below.

THE FOLLOWING PAGES CONTAIN A SOLUTION TO MODELLING THE ABOVE SCENARIO.

YOU ARE TO USE THIS SOLUTION TO DERIVE YOUR RELATIONS AND DATABASE TABLES

Page 5: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

COMP1711

Assumptions Student Name: Student Id: Student FAN: Student Name: Student Id: Student FAN:

Entity Assumptions

The clinic entity has been excluded from the ER Model as currently there is only one instance of a clinic, but if additional clinics are to be included in the system in future this entity can be included.

A customer can not exist in the database without one or both specialisations.

Relationship Assumptions

Based on this sentence “When a patient requires some treatment, one or more appointments are scheduled” I am assuming that the service/s required for an appointment are determined when an appointment is scheduled so there is a relationship between appointment and services. I assume that the services in an invoice are the services that were required for the appointment the invoice is for. In the real world the services a patient thinks they need and what services a doctor determines a patient actually needs during the appointment could be different. A relationship is not required to be modelled for invoice and patient or invoice and doctor as this information can be derived from appointment which has a relationship with invoice.

A relationship is not required to be modelled for invoice and responsible customer as this information can be derived from appointment which has a relationship invoice, then appointment has a relationship with patient and patient has a relationship with responsible customer.

Relationship Entity Assumptions

A patient is not added to the system without having a responsible customer who pays for that patient (Could be themself).

A patient can only have one responsible customer who pays for them (Could be themself).

A patient can exist in the database without having an appointment scheduled for the patient.

A room can exist in the database without there being an appointment for that room.

A doctor can exist in the database without there being an appointment with that doctor.

A service can exist in the database without being required for an appointment.

An appointment cannot exist in the database without being scheduled for a patient.

An appointment cannot exist in the database without being for a room.

An appointment cannot exist in the database without being with a doctor.

An appointment cannot exist in the database without having at least one service required for the appointment.

Page 6: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

COMP1711

Since an Invoice has one to five lines dedicated to the services, this could indicate that there are 1 to 5 services required for an Appointment.

A room can exist in the database without a doctor who works in the room.

A service can exist in the database without a doctor who gives that.

A doctor can exist in the database without having a service that the doctor gives.

Attribute Assumptions

Most attributes will be NOT NULL, unless it is specified in the specification as being optional in some way.

RelevantDate of an invoice is not the appointment date. RelevantDate could be something else such as a payment due date.

Totalfee is calculated based on the sum of current service fees for the appointment that the invoice is generated for. Assuming current service fees do not change.

PreferredRoom can be demonstrated as a Boolean attribute in the works In relationship.

Page 7: COMP1711 Data Modelling Assignment Part II Feel Good Clinic
Page 8: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

COMP1711

A room has none, more or more doctor/s who prefer the room. A doctor gives none, one or more service/s. A service has none, one or more doctors who give that service. A doctor is identified on an invoice for an appointment that doctor was assigned to.

Service General term for the treatment of a patient by a doctor at the clinic. Each service has a prescribed code, description, current service fee and any doctors who give the service.

Treatment A service can be required for none, one or more appointment/s. An appointment has one to five services required for the appointment. A doctor gives none, one or more service/s. A service has none, one or more doctors who give that service. A service is identified on an invoice for an appointment that required that service. A service current service fee is used in the calculation of the total fee of an invoice for an appointment that required that service.

Appointment General term for a scheduled date and one hour time slot for a patient to receive service/s from a doctor in a room in the clinic. Each appointment has a date, starting time, patient, doctor, room and required service/s.

A patient can have none, one or more appointment/s scheduled for that patient. An Appointment is scheduled for one patient. A room can be used for none, one or more appointment/s. An appointment is for one room. A doctor can have none, one or more appointment/s. An appointment is with one doctor. A service can be required for none, one or more appointment/s. An appointment has one to five services required for the appointment. An appointment can have none or one invoice generated for the appointment. An invoice is generated for one appointment. Appointments are made in hour blocks; on the hour.

Invoice General term for billing details for an appointment and status. Each invoice includes a unique invoice number, the relevant date, total fee and the details of the appointment the invoice is for which include the patient, responsible customer, doctor and services given. An invoice can optionally include a clinical comment.

Bill Billing

An appointment can have none or one invoice generated for the appointment. An invoice is generated for one appointment. An invoice initially has a status of ‘C’ (“completed”). At some later stage, the status is changed to ‘B’ (“bill sent”) and eventually the status is changed to ‘P' (“paid”).

Page 9: COMP1711 Data Modelling Assignment Part II Feel Good Clinic
Page 10: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

COMP1711

doctor to work in. Every doctor has a preferred room.

A room could have none, more or more doctor/s who work in the room. e.g. Dr Trent could work in room 001 with a preference to work in room 001.. e.g. Dr Siamak could work in rooms 001 and 002 with a preference to work in room 002.

Gives A doctor gives one or more service/s.

A doctor could give none, one or more service/s. A service could have none, one or more doctors who gives that service. e.g. Dr Trent could give Therapy. e.g. Dr Trent and Dr Siamak could both give Therapy.

Page 11: COMP1711 Data Modelling Assignment Part II Feel Good Clinic
Page 12: COMP1711 Data Modelling Assignment Part II Feel Good Clinic
Page 13: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

COMP1711 Works In PreferredRoom Indicates whether the room that

the doctor works in is the room that the doctor prefers to work in. Can either be yes or no (true or false).

Boolean (Yes or No)

Page 14: COMP1711 Data Modelling Assignment Part II Feel Good Clinic

actualFee

1..10