[Database assignment is1060]UOL Student Number 090404702.docx

[Database assignment is1060]
UOL Student Number: 090404702
Introduction
Mable Skin Clinic has 5 different branches within the City of
Singapore. It offers medical treatment and consultation to the
public on various skin illnesses. Its popularity has grown its
customer base in Singapore. Mable’s 5 branches that are located
in various parts of Singapore handle tour enquiries and
bookings from customers.
Each branch is assigned with two skin specialist doctors.
Besides treating normal skin diseases these specialists hold
different field of expertise. Customers usually make bookings
on the specialists that they deem appropriate to their skin
illness.
Adding value to a company’s customer service by providing the
necessary information and instruction prior to a product or
service purchase is essential. The purpose of my report is to
showcase how a database management system is able to help a
Mable Skin Clinic use the data captured from its patients to
better serve them and also help the clinics to better manage and
plan the medical appointment schedules better.
Problem & Concern
There are some voices of concerned within the Mable’s
management that there is an increase in internal operational
problems and complaints from patients. The problems concerned
are listed below;
· Increase in the number of patients that cancelled their medical
appointment that they have previously made online at the very
last minute. This has certainly caused a disruption and wastage
of resources as the doctors and specialists were unproductive
during that appointment slot where the booking has been

cancelled.
· Customer complaints that the instruction and information prior
to the medical appointment are inaccurate.
· Employees do not have any reports to refer to.
· Management have problems tracking the customer’s data.
Mable skin clinic operates in 5 different locations in the city.
They are as follows;
1. Woodlands Branch
2. Bishan Branch
3. Jurong Branch
4. Orchard Branch
5. Tampines Branch
Data Analysis
Naming Data Items
Full Name
Assigned Name
Appointment No
Appt No
Clinic No
ClinicNo
Appointment Date
ApptDate
Appointment Time
ApptTime
Consultation Fee Only
ConsultationFee
Specialist No
SpecialistNo
Specialist Name
SpecialistName
Expertise
Expertise
Specialist Telephone No
SpecialistTelNo

Clinic Name
ClinicName
Room No
RoomNo
Booking No
BKNo
Booking Date
BKDate
Booking Time
BKTime
Booking Instructions
BKInst
Customer No
CustNo
Customer Name
CustName
Customer Address
CustAddr
Customer Telephone No
CustTelNo
Entity Types & Named Data Items
APPOINMENT (ApptNo,
ApptDate,ApptTime,ConsultationsFee, [ClinicNo])
Note: Different appointments may be held at the same clinic. []
represents a repeating group
BOOKING (BKNo, CustNo,ApptNo, BKDate,BKTime,BKInst,)
CLINIC (ClinicNo,RoomNo,ClinicName)
Note: Each clinics holds two unique room no.
CUSTOMER (CustNo, CustName, CustAddr, CustTelNo)
SPECIALIST (SpecsNo,ClinicNo,
Expertise,SpecsName,SpecsTelNo)
Notes: Each specialist will be assigned to a specific clinic.
Normalised Entity Relationship Diagram (ERD)

Place
BKNo
BOOKING
CUSTOMER
CustNo
Cater For
Assign-to
Consultation-by
SPECIALIST
SpecsNo
CLINIC
APPOINMENT
ClinicNo
ApptNo
Notes:
· CUSTOMER may place one or many BOOKING. A BOOKING
must be placed by one and only one CUSTOMER.
· An APPOINMENT may cater one or many BOOKINGs. A
BOOKING must be catered by one and only one
APPOINMENT.
· CLINIC may have an assignment of one or many
APPOINMENTs. An APPOINMENT must be assign to one and

only one CLINIC.
· A SPECIALIST may provide consultation to one or many
APPOINTMENTs. An APPOINTMENT may receive
consultation from one or many SPECIALISTs.
Tables
Total of 5 tables in the database have been created base on the
entity types. Below is the Customer table shown on Datasheet
View. A Primary key that hold unique datas from the entity
type.
It is through the design view that this selection of primary key
can be amended if required. The field names are design in order
to minimise any data misunderstandings throughout the analysis
and design process. When the identification is made easy, the
consistency of accuracy is maintained.
Queries
The query tool allows user to extract the specific data or
information that follows a certain requirements. Below is an
example of a Booking List Query.
Enter clinic number that user want to query on.
The ‘”All Access Objects” allows user to conveniently open
table, do queries, use forms and show report request.
Enter appointment date that user wants to query on.
Access will then generate the specific data that user wants to
extract, as per below examples of Booking List Query &
Specialist Doctor Details Query.

Switching to the design view, allows user to see the relationship
between the different entities with the help of the normalize
ERD. Base on the specific query requirements set, user could
customise the required data to suit the query request.
Forms
A form enables users to control the type of information that
were entered into a table and protects existing data from any
accidental error from the user. Below shows a Customer
Booking Entry Form that has been design to allow user to key in
the data received from customers into the required fields easily.
It also allows user to keep track of the records easily, and
therefore make amendments to any data more convenient.
Reports
The aims of the database report almost have the same objective
of a Query where user could extract the required information
but unlike query where the information is portrayed in a raw
tabular format. Reports in this case allows the generation of
compiled information in a more pleasing format that can be read
on screen or for the purpose of printing and distribution to more
than one user.
An example of a Booking List Report and Customer Report are
shown below, where the system made available the date of
printing, page summary and summation of figures if any.
Conclusion
Database system eliminates heavy usage of paperwork. A simple
query enables the user to generate information that it
specifically request. Mable Skin Clinic could better manage the
tracking of customer data with database system implementation
as it contributes to a more efficient workflow rather than the

paper files.
Internally, database system will aid Mable skin clinic in
communication better, especially when the clinic have 5
branches spread across the city. Faster report generation allows
employees to be more proactive and this could initiate courtesy
reminder calls to patients to confirm on their appointment
bookings. For larger companies with lager pool of customer
base, more sophisticated database system may be required.
Database projects are not always straight forward as I have
experienced, it involves careful planning and understand the
requirement needs of the business function, even then the data
analysis have to be carefully look at to create an accurate entity
relationship.
Page 7 of 7
DATABASE PROJECT
I need to prepare a report with 2 requirements
1) A carefully developed class diagram to show those aspects
of the world that the database will store data about
2) A normalised data model that serves as the design that you
will implement in software
The class diagram is the results of analysis work - studying the
world. The data model, which leads on from the class diagram,
is the result design work - taking the class diagram as ts starting
point. If the data model is well excuted, with its entries

identified, relations clearly expressed and attribute specified,
and then the rest of the project - its implementation using the
soft - will follow smoothly. In preparing the data model, you
must show evidence that they have explicitly considered issues
of normalisation.
Aim of Assignment
To demosrate an understanding of the basics of analysis and
design for databases as well as to provide evidence of the use of
the main feature of a database package.
You will be expected to demoestrate the following below,
through the analysis, design and construction of a small
database application:
· Selection of a suitable problem to be solved by a database
application
· production of a class diagram sing UML notation - this is a
logical database design that reflects the aspects of the world
that you store data about
Production of a set of normalised relations - a physical database
design
· Design of a data input screen or screens
· Design of a query screen
· Design of a report for use on screen and/or printing on paper.
You must choose your own database problems from the world
around you. Examples are;
1) College,
2) Local business, or
3) Something associated with some hobby or pastime.
Suitable problems are those that require the recording of data on
three to five related classes of things and allow the production
of a number of contrasting reports.

Examiners will give low marks to any student who submits a
database project that is just based on the customer-order model.
How to Prepare the Report for the Database Project
When preparing your report for the database assignment, you
are asked to include the following items.
· A description of the database problem tackled.
· A class diagram of the application, showing the various
classes identified and their associations. You must use UML
notation.
· The normalised relations that you will implement in the
software, showing the attributes and keys together with their
field type and ‘picture’ (for example, the type of data that is
held – text, a date, a number, etc).
· A sample table of the basic relations set up in the database
software together with a small amount of data.
· Designs for data input screens and reports and queries
produced.
· Very brief description of how the system is operated and the
commands used to undertake each task. (Note: it is assumed that
this is done by using interactive commands of the database
package, not by any programming.)
· Examples of the reports produced
The report must be produced with the aid of a word processor
and you are expected to insert relevant diagrams or screen shots
into the text. Diagrams should either be prepared using a
computer package, or perhaps done by hand and scanned in to

the document.
The total report should be about six to eight pages of carefully
laid out text, figures, diagrams and all examples of printouts or
other necessary computer-generated reports.
Simple Examples (Please don’t use these examples)
Consider this example. Develop a database that will allow a
person to review all the films that are on in London this week
and discover at which cinemas they are showing. The aim is to
help people plan their entertainment and book tickets.
At first sight this suggests two classes of things about which a
system will store data – various films and various cinemas – and
of course the association between them (an association is the
name we use for the link between things of one class and things
of another. This usage comes formula. Sometimes we express
the same idea as a ‘relationship’). 2001: A Space Odyssey – a
classic film from 1968 by Stanley Kubrick and in part about
computers – is showing at five particular cinemas. A user of the
database would want to know this to answer their query about
where the film is showing. But, just knowing where is not
enough. They will wanton know when. This will lead us to add
another class – another class of relevant thing in the world –
which we might call a showing or screening.
We will then need to reflect in our class diagram these three

classes. Below are two simple examples of such class diagrams
with the second one showing some of the attributes (data items)
that we would want to store for items of each of the three
classes.
Figure 2.1: A simple class diagram for films and cinemas.
The label 0..* at each end of the association in Figure 2.1 means
that there can be zero, 1 or more films showing at a particular
cinema (the cinema may be closed this week for redecoration),
and that there can be zero, 1 or more cinemas showing a
particular film. The key to database analysis is to be able to
think about such associations and how they are expressed
accurately in the class diagram. The ‘many to many’
relationship in Figure2.1 above, which is how the world looks at
first sight, becomes resolved into the idea of a new class called
‘Showing’ which allows us to specify a particular film being
shown at a particular cinema at a particular time–hence the
simple 1 at one end of the associations shown in Figure
2.2below.
As an exercise explain what change you would make to the
diagram in Figure 2.2 if a single showing could include up to
four separate films. To get to the full answer to this question
will require that you have studied Chapter 8, but even if this is
your first read through the subject guide, you should be able to
take the first steps to allow for this detail to be faithfully
recorded in the class diagram.
Figure 2.2: A class diagram for films, showings and cinemas.
Example 1
A database for the Human Resources department of a company

to hold information on employees and the department they work
for. Data to be held include the employee’s:
• Family and first names
• Age
• Sex
• Address of residence
• Date of joining the company
• Department (administration, distribution, manufacturing)
• Job title (assistant, technician, specialist, consultant, manager)
• Head of their department (another employee)
• Line manager to whom they report
• Qualifications held
• Training courses attended.
The system should have an input screen to allow new employees
to be added to the database and a screen to allow employees
who leave to be deleted.
Similarly it should be possible to add or delete departments
(this is an organisation that likes to reorganise itself) and to
record when an employee moves from one department to another
or from one job title to another (for example, a move or a
promotion).
The system should produce the following reports on screen and
on paper:
• A report that lists all female employees with an MSc.
• A report that shows, for each department, the employees
sorted by family name.
• A report that shows all employees who joined the company
before a given date in date order.
• A query to show an employee’s line manager.
Example 2
A database is to hold information on students, the courses they

take and the teachers who teach them. Data to be held will
include a student’s:
• Name
• Sex
• Age
• address
• Courses taken.
Each course has a name and meets up to three times during the
week (for example, Tuesday 10–11, Wednesday 4–6). A course
can have one or more teachers. The details of the teachers to be
stored are:
• Name
• Telephone number
• Qualification.
The system will allow a teacher to record homework marks for
students.
The system should have input screens to allow new students to
be added to the database and a screen to allow students who
leave to be deleted. Similarly, it should be possible to add or
delete courses and teachers as well as to record a change in who
is teaching or taking which courses.
The system must produce, on screen and on paper, a report that
shows:
• A query of all the people who teach a certain student
• A report of all students who have done 60 per cent or less of
their homework assignments
• A report, by course, of the students enrolled sorted by family
name (for example, a register)
• A query as to all teachers who are teaching more than two
courses
• A list of all students who should be in class at a given time
(say, Friday between 9.00 am and 2.00 pm).

4
Chapter 8: Tools and methods for analysis and design
109
Chapter 8: Tools and methods for
analysis and design
8.1 Introduction
The previous chapter introduced and discussed the approach to
setting
up and running a development project. In this chapter we look
in more
detail at the tools and methods that a professional systems
developer
(a knowledge worker) might use. We focus in particular on
analysis,
sometimes called systems analysis, and the kind of work that
establishes
the detail of the information requirements. We also consider
some aspects
of design – in particular, design of a relational database. This
part of the
syllabus is directly relevant to your project work.
8.1.1 Aims of the chapter
The aims of this chapter are to:
• introduce you to object oriented modelling for the
analysis task and the
Unified Modeling Language (UML)

• discuss the two UML diagrams: namely, the class diagram
and the use
case diagram
• offer you guidance on how to develop such diagrams for
your project
work
• introduce the normalisation of a data model.
8.1.2 Learning outcomes
By the end of this chapter, and having completed the Essential
reading and
activities, you should be able to:
• describe the purpose and uses of the Unified Modeling
Language
(UML)
• explain the purpose and basic structures found in two
UML diagrams:
the Use Case diagram and the Class diagram
• undertake analysis work to allow you to draw a simple use
case
diagram using the UML notation
• undertake analysis work to allow you to draw a simple
class diagram
using the UML notation
• prepare a set of normalised relations using the entity–
relation model
and thus complete your database coursework.
8.1.3 Essential reading

Laudon, K.C. and J.P. Laudon Management information
systems: managing the
digital firm. (Boston; London: Pearson, 2013) thirteenth edition
[ISBN
9780273789970 (pbk)] Chapters 7, 13 and 14.
Curtis, G. and D. Cobham Business information systems:
analysis, design
and practice. (London: Prentice Hall, 2008) sixth edition [ISBN
9780273713821]. Chapters 10, 11, 13 and 16.
8.1.4 Further reading
Avgerou, C. and T. Cornford Developing information systems:
concepts,
issues and practice. (London: Macmillan, 1998) second edition
[ISBN
9780333732311] Chapters 2, 3, 4 and 5 cover systems
development in
some detail and depth.
IS1060 Introduction to information systems
110
Fitzgerald, B., N. Russo and E. Stolterman Information systems
development:
methods-in-action. (Berkshire: McGraw Hill, 2002) [ISBN
9780077098360].
Pressman, R. Software engineering: a practitioner’s approach.
(London: McGraw
Hill, 2009) [ISBN 9780071267823].

8.1.5 References cited
Kent, W. ‘A simple guide to five normal forms in relational
database theory’,
Communications of the ACM 26(2) 1983, pp.120–25.
8.1.6 Synopsis of chapter content
This chapter introduces the object oriented approach to systems
analysis,
the Unified Modeling Language (UML) and the two diagrams
from UML
that you are expected to understand and use. These are the use
case
diagram and the class diagram. The chapter goes on to discuss
how a
class diagram as an analysis output can be used as the basis
from which
to develop a design for a database obeying the entity–
relationship model.
Finally, the chapter introduces the process of normalisation that
is used
to ensure that a database records data efficiently, is
maintainable and can
safely and successfully be updated. The overall process of
developing a
database analysis and then a design is the basis for your
database project.
8.2 Techniques used in object oriented modelling
Reading activity
Read Chapter 13 of Laudon and Laudon (2013) and Chapter 16
of Curtis and Cobham
(2008).

The lifecycle model introduced in the last chapter includes the
key activity
of ‘analysis’. Once the broad direction of a project has been
established
effort is needed to explore, understand and document the new
system in
both its business processes and its main technical elements.
This must be
done in order that in the next phase designers are appropriately
briefed.
The analyst’s work is to provide the required detail so that a
system can be
built (programmed, configured, new jobs and roles established,
databases
established, etc).
The person who does this analysis work, the systems analyst,
needs to be
able to provide a high-level overview of:
• what things the proposed system will do for its
users/sponsors, their
requirements including, in particular, their information needs
• where data comes from and then goes to in the wider
world
(remember: information systems are open systems and therefore
get
data from the world around them and return it to that world)
• what data processing should take place, first at a high
level of
generalisation and abstraction, and then in increasing detail
• what data needs to be stored, or more specifically, what

things in the
world will need to be represented by some stored data.
These are almost all posed as ‘what’ questions, and it is a broad
but
useful generalisation to say that analysis is mostly about ‘what’,
while the
subsequent phase of ‘design’ is about the ‘how’; in particular
the ‘how’ of
technology.
For this subject, you are expected to understand and be able to
use two
basic techniques used in systems analysis as a way to express
answers to
111
these ‘what’ questions – the specification of a new system. Both
are based
on specific diagrams, although they will usually need to be
accompanied by
some detailed textual descriptions too.
The two diagrams we will use are named:
• use case diagram
• class diagram (which is required to support the data
analysis and data
model you prepare for your database project).

These two diagrams are a part of the Unified Modeling
Language (UML),
a modern standard for documenting systems analysis work as
well as
systems design. UML has been established by an influential
industry body,
the Object Management Group (OMG) as an open standard.
Being an open
standard means that UML is freely available to be used by
anyone with
no license fees to pay – just as open source software is available
without
fees. As its name implies, UML is a language – a language for
building
models of information systems – and UML provides models
appropriate for
developing new information systems from an idea through to
implementing
an operational system. (UML version 2.4.1 the latest released in
July
2012 has a 1,000+ page specification, available at:
www.omg.org/spec/
UML/2.4.1/Infrastructure/PDF/ You will be glad to know that
you are not
expected to read any of this document!)
As a modelling language UML includes model elements
(fundamental
concepts), notations (visual versions of model elements) and
guidelines
(idioms of usage or recommendations).
What UML is not is a specified process for development activity
or some
other version of the lifecycle. Another way to say this is that it
is not a

‘methodology’ – a methodology being a tightly coupled and
prescriptive
process for how to develop systems. So we can and will use
elements
of UML for all kinds of development work and in support of all
kinds
of development approaches. What UML does, as a language, is
allow
developers and other people to express and communicate ideas
about
a new system – often using diagrams and pictures – but it is up
to the
developers, managers and users to determine what needs to be
expressed,
and what the right sequence of activities is for developing
models and
moving forward towards the new information system.
For the purposes of this course we are going to introduce and
use only a
small sub-set of UML. If you take further courses in this area
you will learn
more UML, principally in the course IS3139 Software
engineering:
theory and application. The two diagrams we will use are:
Use case diagram: to capture users’ overall requirements. A use
case
diagram defines the boundary of the system under analysis and
identifies
actors (people, and perhaps other information systems) who
participate
with the (technical) system, and the ‘things that they want to get
done’.
Class diagram: to capture the static structure of a proposed

system in
terms of classes (types of relevant objects or ‘things’) and their
relationships
to one another. We focus in particular on business classes that
relate
to relevant things in the domain of a new system. Put in plain
English,
business classes are the ‘types of things in the real world that
we will need
to know about’. So, if a new system is going to process orders
sent in by
customers for various products, we can immediately identify
some classes:
Customers, Orders, Products. In simple terms, we might say that
a ‘class’
is suggested any time we use a noun in our description. Here is
another
example of a simple description of a system and some classes
that emerge.
112
‘On any given day the new system will allocate available
aeroplanes to
fly specific flights between two airports and then allocate a
qualified pilot
to take charge of the flight.’ Here we can see immediately four
potential
classes (nouns): pilots, aeroplanes, airports and flights. Each
one is quite
plausible as important things a system would need to store some
data

about.
8.2.1 Use case diagram
Reading activity
Read Chapter 16 of Curtis and Cobham (2008).
The use case diagram is about actors (people who act (do
things) in the
world) and what they want a system to do to help them. In order
to get
things done they use or become part of an information system.
To say that
they ‘become part of’ is an example of a sociotechnical view of
information
systems which are always a part technical, part social and
organisational.
Actors might, sometimes, also include other computers or
databases if
they will be interacting with the system we are considering.
Strictly, we
should say that an actor is a ‘role’, not a person, and one person
(or even
computer) could take on more than one role with respect to a
system.
In the example below, a person could be both a nurse and a
patient – a
nurse one day and a patient the next – these being two roles
they can play
depending on circumstances. Within the broad structure of UML
an actor
and a use case are model elements and the diagram below shows
the usual
notation used to depict them.

Prescribe
medicines
Administer
medicines
Review medicines
Supply medicines
Doctor
Nurse
Pharmacist
Figure 8.1: A simple use case diagram showing an electronic
prescribing (eP)
system for a hospital to support the giving of medicines to
patients.
The phrase use case may not sound quite right in English on
first
hearing. It comes from a Swedish author (Jacobson). Perhaps it
sounds
better in Swedish. However, the phrase and the concept has
caught on
113
and is widely used to convey the notion of ‘a case of somebody
using a

system to do something’, which is a very appropriate way to
document
systems requirements during systems analysis, in particular
functional
requirements. So a use case says that ‘this actor/these actors
will use (for
example, be involved with) the information system to help
achieve this
task/these tasks’.
The notation is very simple. A stick figure stands for the
(human) actor. An
oval represents a whole and complete task the system will do
(the use case
itself) and this is given a short and imperative name (book
course, enter
order, check credit, administer medicines). In the example
above, the four
use cases all relate to medicines being given to patients in a
hospital and
the activities of various actors. We have also chosen to add two
borders on
this diagram. Symbolically, at least, the outer border shows the
boundary
of the information systems, and the inner one the boundary of
the
technical, programmed, computer systems – but such boundaries
are not
really needed unless they really help to explain the context.
All actors shown on a diagram must be related to at least one
use case,
and all use cases on a diagram must have at least one actor
associated
with them. An actor sends a message or otherwise stimulates a
use case,

or the use case sends a message to the actor, and this provokes
some
response.
Each use case (oval) in the diagram should be a whole operation
from the
perspective of the actors involved, and provide some value to
the actors.
The most common error in developing a use case is to break it
down into
too fine a detail at first. Remember, this is intended to provide a
high-level
and user-oriented description of what a system can do – not any
internal
design detail.
A new system under analysis may require many use case
diagrams each
showing some distinct sub-set of functional requirements. In
general
there is a premium on keeping a use case diagram simple and
direct so
everybody can understand it.
There are various elaborations possible in the diagram, with
notations to
allow use case diagrams to express some more ideas about the
general
architecture of a system and the tasks it supports. One use case
can make
use of another in a <<includes>> relationship. An arrow from
the user to
the used indicates this. This is a simple ‘subroutine’
relationship – one use
case uses another for a particular task. A use case can also be
modelled in

terms of an <<extends>> relationship, in which one use case is
based on
another, but extends its functionality or deals with some special
case.
In the use case diagram below the cook can make a cake, and to
do this
they will (always, often, usually) measure flour. But this is a
separate
use case because other use cases may also need to include the
same
activity. Sometimes the cook will bake a cake that needs to be
iced. So we
recognise this as a special case where we must add an extra
activity to
add the icing. The usual advice is to be very careful in using
these extra
elements – the principal aim of a use case diagram is to be
simple and
understandable and detail can come later. You can read more
about these
two elaborations in Curtis and Cobham (2008) Chapter 16.
114
Cook
Make a cake
Measure flour
Add icing

«include»
«extend»
Figure 8.2 A use case diagram illustrating <<include>> and
<<extend>>
associations.
The use case diagram captures and shows very well the basic
ideas of
what a system is supposed to do, but a diagram alone is seldom
enough
to convey all the detailed information that is required. Thus it is
usually
necessary to provide some textual description to accompany the
use case
diagram, as well as a textual description of each actor (who
exactly they
are) and each use case in the diagram. Such a description will
include the
objectives for the use case, how it is initiated, how it delivers
value (for
example, supports the overall systems purpose), and any
required pre-
conditions, etc.
To develop a use case diagram (or set of diagrams for real sized
systems)
we usually start with finding (some of) the actors.
Who needs the system; who uses the system; who supports or
manages
the system; who benefits from the system? Remember too that
an actor
does not have to be a human role; an actor could be a device, or

another
computer based system that is outside the current system’s
scope.
Once we have found some relevant actors we can start to
express their
needs in terms of broad functionality – the use cases. Use cases
are there
to get things done, to process or retrieve information, or to
monitor
activity and report on events. By asking these types of question
we will be
starting to think about the possible shape of a future system.
The above example is of a use case diagram for an everyday
activity
familiar to most of us from television and films, if not real life,
i.e. giving
medicines to a patient in a hospital. Information systems are
increasingly
used to support this activity, often described as electronic
prescribing
(eP) systems. Three actors are shown in Figure 8.1. The Doctor
who
prescribes medicines, the Nurse who administers them to a
patient and the
Pharmacist who supplies the medicines and also reviews and
checks the
prescription. Each of these roles (people) will interact with the
computer.
Each has to get something done to fulfil the overall purpose of
the system
which is to provide safe, timely and appropriate medicines to
patients.
You may think that a patient should be shown as one of the

actors here –
indeed, perhaps they should – but in most such systems the
patient does
not directly interact with the computer system. We certainly
could imagine
a case where they would, for example, need to confirm they
have received
their medicines, or to review their own medicine history.
Mothers may
want to know what inoculations (medicines) their children have
had, or
on leaving hospital another doctor may want to review the
record. With
that in mind, try to add to the above diagram a Patient actor and
a suitable
use case.
For now there are four use cases (ovals) shown in the diagram –
that
is, four ‘chunks of functionality’ that we think we want the
software to
incorporate to support the work processes of these medical
staff. You
115
should be able to appreciate that the very simplicity of the
diagram is
its strength. For example, you could have a good discussion
with nurses,
doctors and pharmacists about this diagram, probably everybody
would

quickly understand it, and they could probably tell you a lot of
extra detail
about each use case – for example, detail on the how part.
How is important of course, but the use case diagram is not
intended to
say much about about how things are done by the computer, just
what
and to who it is done. For example, we may know that there is
an implied
sequence of events here: probably in the rough order prescribe,
check,
supply, administer. But the use case diagram does not concern
itself with
this. At the start of a development effort it is important not to
add too
much detail – that can come later. Indeed UML has other
specific diagrams
(tools) to capture the sequence of events and the messages that
would
link together these use cases and actors – for example, the
object-sequence
diagram, but we do not consider this diagram in this course.
Activity
The TOPCAR taxi company is working to develop a new
information system to support
corporate credit accounts. So far they have come up with this
loose textual description of
the system.
A client company can make a request for a credit account, in
which case one or more
credit checks is made. If these are positive, a credit account is
set up on file.

Thereafter, an authorised person from such a company can
phone up a dispatch clerk
and request a booking. When this happens, availability of a taxi
at the requested time is
checked, as is the credit status of the client company. If these
two checks are successful a
booking is made.
After the customer has used the taxi, the driver sends in a
record of the work, including
the time and the distance. The cost of the booking is calculated
and added to the account.
At the end of the month accounts are sent to client companies
for settlement.
Sketch a use case diagram for this system. First identify the
actors, then the ‘chunks of
functionality’ that these people interact with. Try to restrict
your diagram to five or fewer
use cases. Remember, you are not expected in a use case
diagram to be concerned
with sequences of events, and the use cases should have no
associations between them
(other than <<includes>> and <<extends>>. Remember too that
this is an exercise
in simplification. You will need to leave out some of the detail
while capturing the basic
functionality that is needed. This is never easy, not in exercises
or in real life systems
development.
8.3 Class diagrams and data models
Reading activity

Read Section 6.2, Chapter 6 of Laudon and Laudon (2013) and
Chapter 13 of Curtis and
Cobham (2008).
Use case diagrams are about modelling actors and the
functionality
they expect or need. Another important aspect of information
systems
development addressed during the analysis phase is establishing
in
appropriate detail (for example, not too much) the classes of
things that
a system will hold and use data about. The goal is to establish a
logical
model of the world around the system and the things there with
which
it interacts (again – think open systems). Once this logical
model is
established then designing the database element of a new system
can go
ahead (a ‘how’ question addressed in the design phase).
116
Here we must hold on to the distinction between analysis and
design.
Analysis is about needs, requirements and some idea of the
future
logical systems we are seeking to build (the what). Design will
take that
information and add the detail to allow the system actually to be
built (the

how).
For analysis we develop a class diagram based on UML
notation. UML
supports an object oriented approach to analysis and design, and
the basis
for object oriented model building is, unsurprisingly, objects
and classes
of objects. My VW Golf is an object that belongs to the class of
motor cars.
The class diagram is concerned with broad types of things
(classes; for
example, cars) rather than specific examples (objects; for
example, my VW
Golf). Orders not an order, students not a student, etc.
A class diagram is the basis for database development including
for
your project for this course. An object is an individual ‘thing’, a
class
describes the generality of such things. An object class (or just
‘class’ for
short) is an abstraction of a set of real world things – tangible
objects
(cars, boats, planes, products, books), but may also represent
roles
(student, customer, reviewer), incidents, events or activities
(election,
earthquake, examination), interactions (sales contract, review
request), or
specifications (orders, recipes, prescriptions).
When we build an analysis model we are, at least initially,
trying to build
a model of the environment within which a system will operate,
and with

which it has to maintain some level of correspondence. Thus, if
we have
customers or patients, or medicines or doctors out there in the
world, we
will want to model them within our new information system. In
this way,
we identify the object classes (or just classes) and use them to
build a
‘map’ or model of the domain. Later on in the development
process we will
shift our view towards software and detailed processes by which
things
happen. But for now, in analysis, it is the problem domain that
we focus
on.
The graphical depiction of a class is a box with up to three
compartments.
At the top we name the object (singular noun); in the middle we
describe
the attributes (data values) that the object should retain. At the
bottom
we can add the operations or functions, the things that the
object can do,
or the events that it can respond to. This is the basis of full-
blown object
oriented analysis and design, as taught in course IS3139
Software
engineering: theory and application, but for the purpose of this
course and your database coursework we ignore operations
within the
class model.
Identifying relevant classes, at least initially, is quite easy.
Think of
the electronic prescribing system introduced above. What are

the
types of ‘things’ that we want to collect and hold data about?
Patients,
prescriptions, medicines, for a start, plus perhaps administration
events
such as when medicines are given, checks done by pharmacists,
and
deliveries of stock to the ward. We probably also need to store
information
about the actors – doctors, nurses and pharmacists – to record
who does
what.
To keep it simple we will focus here on the prescribing activity
itself. One
way to think about a prescription is as an order written by a
doctor for
some medicines (one or more) to be given to the patient –
perhaps once
or perhaps regularly for a certain number of days. This
structure, of an
order for items for a customer (for example, a patient), is very
common
in all sorts of business situations, and is the most common
example of a
class model/data model found in textbooks. (See, for example,
Laudon
117
and Laudon (2012) Figure 6.11.) Below (Figure 8.3) is our
version of

this general model written using UML notation – and then the
model is
adapted for the specific case of prescriptions.
For the moment let us take the classes as given. We want to
concentrate
on the associations between classes. Note also that the class
boxes are
very simple. This is because we have not, as yet, defined any
attributes (or
operations). In the very early stages of analysis we do not need
to do this,
so keep it simple. There is plenty of ‘analysis information’
contained in the
diagram already.
What the diagram shows are some associations between classes.
In
our system we will need to be able to ‘follow’ these
associations so, for
example, a prescription can be ‘linked’ to a particular patient,
or we can
answer a query such as ‘name all the patients who are taking
medicine X’.
In the diagrams below we can interpret these associations in
specific ways.
Thus they say that there is a relationship between a customer
and an
order such that a customer can have 0 or more orders (0…*).
Each order
is made up of one or more line items. In other words, it is not
possible to
have an order for zero items (this may or may not make sense).
The black
diamond on the left of the line says that this association

between the two
classes is an ‘aggregation’. That is, a line item belongs to an
order, is a
part of it. If we delete the order for some reason, all the line
items are also
deleted. Note that customers and products are independent
classes, hence
no more of the open diamonds in the diagram. A line item is
associated
with one product and any given product can be associated with
zero or
more line items.
In the lower diagram this same structure tells us the same detail.
It says
that a prescription will be associated with just one patient, but
that a
patient can have 0 or more prescriptions. The diagram also tells
us that
a prescription can be for one or more items, and that each item
on a
prescription relates to a single medicine. All of this is useful
information to
check with the medical staff to make sure we have it right!
Here is a general version of this class diagram.
Customer Order ProductLine Item
1
0..*
0..*
1..* 1

Here is a version adapted for prescriptions.
Patient Prescription MedicineItem
1
0..*
0..*
1..* 1
Figure 8.3a and 8.3b: Two examples of a class diagram using
the same pattern.
These two diagrams were drawn using software freely available
at:
http://yuml.me/diagram/scruffy/class/draw
The script used to produce the first diagram is given below.
With this
software (an example of SaaS), you specify the diagram with
simple
text and the website draws the picture for you. You can find
many other
software packages and services that can do the same task.
// Order Order Line Class Diagram
[Customer]1--0..*[Order]
[Order]++--1..*[Line Item]
[Line Item]0..*--1[Product]

118
This class diagram shows the overall structure of the data that a
system
will need to store, shown in terms of different classes. This
provides a
useful notation and simple but powerful ideas to work with.
Using them
on a real problem should convince you.
To take this model forward to form a database design we use the
relational
database approach, in which data is considered as being stored
in square
tables, one table per class. The actual details of how the
computer stores
the data need not concern us in analysis activities – that is
largely taken
care of by database management software.
A table or relation has a number of columns representing the
items of
data to be stored related to any given object in a class (what we
call the
attributes). The rows represent the occurrences of items to store
data
about a particular item of the specified class. Now we have
come to the
design phase we change from calling these objects to calling
them entities.
It is a bit confusing but the word entity is the older term and the
entity-
relationship model preceded the object-class model. Just
remember: object

in analysis = entity in design. In this way, a table of patients
may have a
layout as shown in table 8.1; adding more patients would mean
adding
more rows.
Patient number# Patient name Age Gender Allergy
58447 Peter Small 23 Male Nuts
21944 Mary Jones 23 Female None
55633 Lola Smith 26 Female Nuts
18647 John Smith 28 Male None
419745 Mary Jones 18 Female Milk
Table 8.1: The patient relation.
We can write down the design of this relation in the following
form:
Patient(Patient number#, PatientName, Age, Gender, Allergy).
We can add this information about the attributes onto the class
diagram as
follows.
Patient
0..*
Patient No#
Patient Name

Age
Gender
Allergy
Prescription
1
Figure 8.4: Class diagram for the patient relation.
The relation itself is called PATIENT – it has so far five
attributes with
the names Patient Number, Patient Name, Age, Gender, Allergy.
The field
Patient Number has # after it to indicate that this is the key
field. The
value of the key field must be unique for each entry in the table
and here,
as in many cases, this is achieved by giving entities unique
reference
numbers – just as the books on the subject reading list have
unique ISBN
numbers and any database dealing with book titles might use
ISBN
numbers as the key.
In this simple case, we have only one key field, but it may be
the case that
two fields taken together form the key – a composite key. An
example
of a table with a composite key might be:

119
Vehicle (Model#, Engine size#, year#, price).
None of the attributes taken alone – model, engine size or year
– can
uniquely identify a particular type of vehicle (for example, a
2012, 1.6 litre
Honda Civic), but taken all together they do.
Note that in the Patient example none of the other fields can be
used as
the key – in particular, we have two people called Mary Jones,
two people
of 23 years of age and two people with a nut allergy.
The order in which the patients appear in the table is
unimportant, unlike
a simple sequential file structure. In the database approach, we
assume
that we will access records by using the values of the various
fields. For
example, patient number 23817 or all patients with a nut
allergy. Another
way of looking at this is to say that we are interested in one
class (type
of entity) – patients – and we have identified five attributes of a
patient,
including a key attribute.
Doing data analysis and building a data model for a real
information
system generally will require consideration of more than one
class as
we have seen. In this example, we have identified another three

classes:
Prescription, Item and Medicine. This leads to another three
relations:
Prescription(Prescription Number#, Patient Number, Date,
Doctor issuing, etc. )
Item(Item Number#, Prescription Number, Medicine number,
Dose, Frequency, etc.)
Medicine(Medicine Number#, Name, Unit Size, etc.)
What is the relation between the entities Patient, Prescription,
and Item?
Well, it is expressed in the class diagram above (see Figure 8.3)
as well as
in the relations above. In the relations we can see that all the
underlined
attributes link us to another entity. When the database is
working as part
of the information system we need to be able to make and
maintain these
relationships. As shown above we do this by using the key of
one relation
as an attribute in another. When it occurs in another relation it
is known
as a ‘foreign key’. So Medicine Number and Prescription
Number are
shown as attributes of the class Item, and each underlined to
indicate it is
a foreign key – the necessary links to Prescription and
Medicine.
In the above description of the class diagram we have spoken of
one
to many associations as indicated by a 1 and a 1..n at the ends

of the
line. This is known as the cardinality or multiplicity of the
association
or relationship. In general we might have many types of
multiplicity.
Consider, for example, the case of a new medicine that becomes
available
but at the present moment is not prescribed for any patient.
Activity
Take this simple example of an association; Footballers and
Football clubs. (Assume for the
moment that a player can only play for one club.) First draw the
appropriate class diagram
and show the multiplicity of the association. Then, assuming
that each resulting relation has
a key (Club Number# and Player Number#), how would you
represent this relationship? For
example, which relation (Club or Player) would contain a
foreign key and what would it be?
Now see if you can expand your model to allow a player to play
for a number of clubs.
The class model introduced above is intended to show us
important things
about associations out in the world and which an information
system and
its database needs to reflect. When we leave Analysis and come
to Design
it is important to ensure these real world relationships can be
accurately
represented in the developed database. With that in mind,
consider
the appropriate associations or relationships in the following
cases and

highlight any issues or questions that may arise:
120
• husbands and wives (think of the King Henry VIII)
• mothers and children
• football teams and players
• books and authors
• cinemas and films
• films and actors
• films and directors.
In general, we will find lots of many-to-many relations (M:N)
out in the
world (one film has many actors, one actor is in many films).
This poses
a problem when we come to database design and the use of
foreign keys.
Similarly, one-to-one relations may be suspect, because they
may suggest
that the two entities are one and the same. This is not always
the case
though. A one-to-one relation between two entities might
represent a
situation in time – as in drivers to cars during a race.

So far, this section has approached data modelling through a
simple
example and by appealing to a common sense understanding of
the way
the world is organised. In the situation of developing a data
model for a
new information system (including when working on your
project), the
sequence needs to be a bit more formalised:
• Identify and name classes of things about which data will
be stored.
• Identify and name the association among the classes.
• Draw a class diagram.
• Identify the attributes of each entity (example of a class)
and select the
key attribute(s).
• Ensure that the identified associations are supported
through the keys
(for example, the key of one relation is an attribute of the other
– a
foreign key).
8.3.1 Normalisation
Background reading
At this stage, we may seem to be finished and, indeed, a class
diagram
alone may be adequate to fulfil the needs of the analysis phase
of systems
development, but there is one further important step we must
undertake

as we develop our design – that is, normalisation.
Normalisation is not considered in detail in Laudon and Laudon
(2013)
but Curtis and Cobham (2008) does give an adequate coverage.
One of the
best short and easy-to-read explanations of normalisation is
found in Kent
(1983).
This is a process by which we make sure that the database we
are
designing will contain all the information we want, that the data
will
be accessible to us, and that the data is stored as far as possible
with
minimum redundancy and to support easy updating.
Normalisation is important for you as you study for this
course, because you may get examination questions about it,
but also because your database project is expected to include
a set of normalised relations.
The ideas behind normalisation are quite simple.
All entities (for example, of a particular class) must contain the
same
number of attributes – this is called the first normal form. This
rule
121

excludes variable repeating groups. Consider this example:
students may
study a variable number of subjects; this might imply a relation
with
a variable number of fields. For example, assume that a student
could
attend as many subjects as they wished:
Student(Student number#, Student name, Address, Subject1,
Subject2, Subject3,…)
This is wrong, because some students might have two subject
fields, some
three, or some five, etc. This does not fit the first normal form
rules.
We can approach this problem another way by seeing that it
suggests that
we have a many to many relation between Student and Subject.
That is,
one Student can take from zero to many subjects; and any one
Subject
can be taken by many students. The solution is to remove any
mention
of subjects from the Student relation and add a new relation (a
new
class), called Course, to ‘link’ a student to as many subjects as
they need,
and at the same time allow a subject to be linked to as many
students as
is required. This new relation Course can have many rows for
any one
student as needed, each representing one of their selected
subjects.
The resulting set of relations are then:

Student(Student number#, Student name, Address)
Subject(Subject number#, Subject name,…)
Course(Student number, Subject number…) = This is the link
between any one Student
and any one Subject.
Each entity (row) in Course represents an individual student
taking a
particular subject; further attributes such as individual
attendance or mark
achieved could be added here. In this way, the many-to-many
relation of
students to subjects is made into two one-to-many relations –
Student to
Course and Course to Subject.
To summarise the second and third normal forms we can say
that, ‘Any
attribute in a relation must provide a fact about the key, the
whole key
and nothing but the key’. We break this down a bit further.
Second normal
form is violated if a non-key field is a fact about a subset of a
key. In this
example, ‘Lecture hours’ is a fact about the subject – only one
part of
a composite key. The attribute ‘Lecture hours’ belongs in the
SUBJECT
relation because it only relates to the subject.
Course(Student number#, Subject number#, Examination mark,
Lecture hours)

If the original design was adhered to, the lecture hours would be
repeated
many times and any change would require many updates to the
database.
Also, if there were no students taking a particular subject –
perhaps
temporarily, for example, during the vacation – then there
would be no
possibility of storing the lecture hours’ data.
The third normal form is violated if a non-key field is a fact
about another
non-key field, as in:
Teacher(Staff number#, Department, Building)
Building may be a fact about the teacher (‘where their office is’
would be
OK) or about the department (where the department office is
would not
be OK). A better design is:
Teacher(Staff number#, Department)
Department(Department#, Office location)
Overall, normalisation helps to ensure that information is stored
only once
and that inconsistencies do not occur in a database when data is
added or
deleted.

122
The set of relations resulting for a college database after some
normalisation might be:
Student(Student number#, Name, Address, Staff number (of
tutor) )
Course(Student number#, Subject number#, Exam mark)
Subject(Subject number#, Lecture hours)
Teacher(Staff number#, Teacher name, Subject, Department)
Department(Department#, Location)
Note how the relations we need to record and use are supported
by using
the key or keys of one relation as non-key attributes of another.
Even so,
this example still has problems: consider the relation TEACHER
– is it
in third normal form? And are we sure that each teacher has
only one
subject?
Activity
As an exercise, redesign the model to solve these problems and
then draw the
appropriate class diagram.
Finally...once you have worked through from a class diagram to
a set
of normalised relations, it will be easy to implement the design
using a

database package. The only step remaining is to determine the
exact form
in which each field will be stored – for example, as integers,
real numbers,
character strings, dates, etc.
Activity
The TOPCAR taxi company is developing a database to be used
as part of a real-time
dispatch system. The intention is that customers can phone up
and make bookings for
taxis, requesting a particular type of vehicle (small car, large
car, minibus), or a particular
driver. Some customers have credit accounts with the company,
some do not.
i. Suggest candidate classes for this database, justifying your
choices.
ii. Identify and name the associations between the classes,
indicating their multiplicity.
iii. Draw the class diagram.
iv. Design the relevant relations with key attributes.
v. Identify and resolve any issues of normalisation you can see.
vi. Show how one identified association can be supported
through suitable keys.
8.4 Reminder of learning outcomes
Having completed this chapter, and the Essential reading and
activities,
you should be able to:

• describe the purpose and uses of the Unified Modeling
Language
(UML)
• explain the purpose and basic structures found in two
UML diagrams:
the Use Case diagram and the Class diagram.
• undertake analysis work to allow you to draw a simple use
case
diagram using the UML notation
• undertake analysis work to allow you to draw a simple
class diagram
using the UML notation
• prepare a set of normalised relations using the entity–
relation model
and thus complete your database coursework.
123
8.5 Test your knowledge and understanding
1. Do you believe that the Use Case diagram is too simple to be
of much
use in systems development work, or is its simplicity its most
valuable
characteristic?
Prepare a use case diagram for the following situations:

a. An ATM (cash machine) provided by a bank.
b. Ordering books on Amazon.
c. Using an online film database (as the example discussed in
Chapter
2 of the subject guide).
d. Checking in to a hotel at the reception desk.
Keep your answers simple with minimal Actors and carefully
chosen
Use Cases.
2. Explain clearly the difference between an <<include>> and
an
<<extend>> in a Use Case diagram. Find relevant examples of
the
use of each in books or online.
3. a. How does a class diagram help when undertaking analysis
work?
What essential questions can it allow you to answer or how
does it
clarify what a system should do?
b. Take the basic class diagram of Customer-Order and rewrite
it to
fit some other situation that is not usually described in these
terms.
For example, a situation where somebody or some thing (e.g. a
computer) asks for a list of things. Whatever example you
choose,
make sure that the associations have the right multiplicity.

4. Research the process of normalisation online and in
textbooks. On that
basis explain as many different types of problem that
normalisation is
intended to prevent or solve as you can.
5. a. Give three examples of relations that violate the second
normal
form, and explain why they do.
b. Give three examples of relations that violate the third normal
form,
and explain why they do.
Chapter 2: Preparing for the project work
19
2.1 Introduction
In this chapter, we introduce the coursework assignments
required for this
subject. We do this early on in the guide so that you start to
think about
the assignments at the beginning of your studies. You will
probably need
to do some associated work before you start the final
preparation of the
assignments and you should not rush into the work. In
particular, you need
to spend some time thinking about the possible areas that your
work will

relate to and the real world context or problem that your
database and
spreadsheet will address. You will also need to develop some
general skills
in using your software and spend a bit of time exploring its
capabilities.
Modern spreadsheets and database systems can do many things
– in the
jargon of the field we would say that they have many
functionalities and
you cannot, and should not, try to use all the features they offer
in your
coursework. However, you do need to have a good general
appreciation
of what is possible before you focus on your particular project.
Note
that the word ‘functionality’ is often used to describe what we
expect
a system or item of software to be able to do. Later in this guide
when
considering systems development we will talk about the related
concept
of a ‘requirement’ as a statement of desired or needed
functionality. A
major task of systems analysis work – work to develop a new
information
system – is discovering the requirements of people in the real
world, and
specifying them as functionalities that the technology should
provide. Thus
we speak of a ‘functional requirement’.
The syllabus requires you to submit two items of work for
marking.
Together, the two items of work count for 25 per cent of the
marks:

• preparation of a database project report (12.5 per cent)
• preparation of a spreadsheet project report (12.5 per cent).
These assignments are intended to provide students with the
opportunity
to select and undertake small ‘development’ projects using
common
computer tools; spreadsheets and databases, but also a word
processor
and perhaps a graphics editor for diagrams. The submitted
reports
are intended to document your work and to show how you
analysed a
particular problem and designed and implemented a computer-
based
solution.
In each case, the work must meet certain requirements and must
be
submitted in the form requested. Note also that we specify that
the marks
for this work are based principally on the report; that is, the
written
document, and not on the spreadsheet or database itself. This is
a subtle,
but important, distinction. Your job is to write a good report
that identifies
and explains the work that you have done.
The exact choice of project is up to you, and you will need to
work
carefully on identifying and developing your project ideas.
Projects are
intended to be individual works, so they must be different

to those of any other student with whom you are studying.
Make sure that your chosen project areas are distinct and in
an area with which you are familiar and interested. Thus our
recommendation is that your project should be developed out of
some
experience or interest that you have or some application that
you believe is
needed in the world around you. It should not be just a textbook
exercise.
20
In both database and spreadsheet projects the Examiners want to
see
evidence of the originality of the topic chosen as the basis for
the work
and for the data used. In our experience as Examiners we have
seen too
many students taking boring, abstract and over simple topics as
the basis
of their work, or just replicating work based on some standard
textbook
example. There is nothing wrong with reading textbooks on
databases or
spreadsheet modelling, or exploring examples provided with
your software
– indeed this is a good idea – but you must then go beyond any
examples
you have studied and create your own projects based on your
own
chosen application area.

2.1.1 Aims of the chapter
The aims of this chapter are to:
• introduce the two elements of coursework required to be
submitted for
assessment
• emphasise the need for you to choose suitable topics for
this work from
areas that are of interest to you
• indicate the methods and approaches we expect you to use
in doing
this work
• give guidance as to the content and structure of the
reports you will
prepare and the style of presentation we expect.
2.1.2 Learning outcomes
By the end of this chapter, and having completed the Essential
readings
and activities, you should be able to:
• develop and document small computer applications using
basic
packages (for example, word processor, database and
spreadsheet)
• recognise the need to work methodically and to meet
deadlines
• appreciate the distinction between analysis work and
design work
• apply simple analytical and design techniques to systems

development
• transform a paper design into a running application
• prepare a brief report on development work conveying a
problem
description, a design, and decisions taken with associated
reasons
• reflect this experience back on to the other parts of this
syllabus.
2.1.3 Background reading
To help you to appreciate the possibilities, it may be useful to
look at the
‘Hands on MIS Projects’ sections of the various chapters of
Laudon and
Laudon (2013). For example, at the end of Chapter 2, an
example is given
of a spreadsheet of purchasing data to be used to help inform
supply chain
management.
It is very important for you to understand that the written report
is what the Examiners mark. They do not receive any database
or
spreadsheet files to run on a computer. Examiners do not expect
any accompanying discs or files with the project work, and
if you submit discs and files, they will not be looked at. What
Examiners do expect to receive, printed on paper, is a coherent
account of
the problem you tackled, the approach used and key details of
how you
analysed, designed and implemented your solution. Any
accompanying

21
printouts, screenshots, database tables, and so on are only
intended to
support the written report and should be carefully chosen and
mentioned
in the report. If you just rely on lots of ‘printouts’ and fail to
write a
coherent report, the Examiners cannot give you many marks.
In the database project, there are two central requirements –
first, a
carefully developed class diagram to show those aspects of the
world that
your databases will store data about. Second, a normalised data
model
that serves as the design that you will implement in software.
The class
diagram is the result of analysis work – you studying the world.
The data
model, which leads on from the class diagram, is the result of
design work
– taking the class diagram as its starting point. If the data
model is well
executed, with entities identified, relations clearly expressed
and attributes
specified, then the rest of the project – its implementation using
the
software – will follow smoothly. In preparing the data model
students must
show evidence that they have explicitly considered issues of
normalisation.

The details of class diagrams, data models and normalisation
are topics
covered in Chapter 8 of this subject guide.
For the spreadsheet project, it is less easy to identify a specific
or
linked set of fundamental requirements. To achieve a good
mark, you need
to select an appropriate problem to tackle – one that has a
reasonable
quantity of data and an underlying computational model that
you can
implement. The best projects draw on real data that relate to
some area
that you really understand or have researched. Weak projects
are based
on made-up data or examples from books that provide models
that are too
simple or too generic. Remember too, good spreadsheets are
designed
according to sound principles. You thus need to give careful
consideration to who the user is and what they want, how the
spreadsheet
is structured, how it looks on the screen and on the page, and
the clear
separation of input data (independent variables) from formulae
and
parameters, intermediate results and final output (dependent
variables).
Equally, you should choose graphs and charts so as to provide
particular
and useful information to the user and not just generate them for
the sake
of showing off every feature of the spreadsheet package. For
example, pie
charts are easy to produce, but are you sure that a pie chart is

relevant in
providing the user of your spreadsheet with what they want or
need?
2.1.4 Essential reading
Databases
analysis, design
9780273713821] Chapter 13, Section 13.2.
[ISBN
9780273789970 (pbk)] Chapter 6, Section 6.2.
Spreadsheets
analysis, design
9780273713821] Chapter 7, Section 7.2.
[ISBN
9780273789970 (pbk)] Chapter 12, Section 12.3.

22
2.2 General rules for submission of assignments
For detailed guidance on completing and submitting
coursework, you
should refer to the most up-to-date edition of the booklet
entitled
Completing and submitting coursework and projects. This will
give you
submission details for all the project work related to this subject
and to
other subjects in the degree programme. A copy of the booklet
can be
found on the course area of the VLE.
The booklet contains other useful and important information −
for
example, telling you that you must retain a copy of your work
and that
you should obtain a receipt from the post office or courier
company when
you send it to the University. The booklet also explains that the
two work
assignments for Introduction to information systems must all be
bound together in a single volume in the sequence:
1. database assignment
2. spreadsheet assignment.
The form accompanying the project work (contained in the
booklet) must
be completely filled in and signed, and one copy should be used
as the first
page of each assignment. Among other things, the form asks for
details

of the hardware and software used in the preparation of the
assignment.
Simple straightforward answers are all that is required here; for
example,
Hardware: Samsung NC10 note book and HP LaserJet 2600n;
Software:
Microsoft Word 2007.
2.3 Database assignment
Reading activity
Read Section 13.2, Chapter 13 of Curtis and Cobham (2008),
Chapter 6 of Laudon and
Laudon (2013).
The aim of this assignment is to demonstrate an understanding
of the
basics of analysis and design for databases as well as to provide
evidence
of the use of the main features of a database package. In
carrying out this
assignment, you should refer to the class modelling section of
this guide
(Chapter 8) as well as the relevant bibliography. You will be
expected to
demonstrate the following through the analysis, design and
construction
of a small database application:
• selection of a suitable problem to be solved by a database
application
• production of a class diagram using UML notation– this is
a logical
database design that reflects the aspects of the world that you

store
data about
• production of a set of normalised relations – a physical
database design
• design of a data input screen or screens
• design of a query screen
• design of a report for use on screen and/or for printing on
paper.
Two example assignments are given below. These are intended
to illustrate the type of problem that you are expected to
tackle. You must choose your own database problems from
the world around you – from your college or a local business
or something associated with some hobby or pastime.
Suitable problems are those that require the recording of data on
three
23
or more related classes of things and allow the production of a
number
of contrasting reports. You should not attempt designs that
exceed five
classes. Two classes is probably too simple but may be the
starting point
for your work.
Consider this example. Develop a database that will allow a

person to
review all the films that are on in London this week and
discover at
which cinemas they are showing. The aim is to help people plan
their
entertainment and book tickets.
At first sight this suggests two classes of things about which a
system
will store data – various films and various cinemas – and of
course the
association between them (an association is the name we use for
the link
between things of one class and things of another. This usage
comes from
UML. Sometimes we express the same idea as a ‘relationship’).
2001: A
Space Odyssey – a classic film from 1968 by Stanley Kubrick
and in part
about computers – is showing at five particular cinemas. A user
of the
database would want to know this to answer their query about
where the
film is showing. But, just knowing where is not enough. They
will want
to know when. This will lead us to add another class – another
class of
relevant thing in the world – which we might call a showing or
screening.
We will then need to reflect in our class diagram these three
classes. Below
are two simple examples of such class diagrams with the second
one
showing some of the attributes (data items) that we would want
to store
for items of each of the three classes.

Film Cinema
0..*
0..*
Figure 2.1: A simple class diagram for films and cinemas.
The label 0..* at each end of the association in Figure 2.1 means
that there
can be zero, 1 or more films showing at a particular cinema (the
cinema
may be closed this week for redecoration), and that there can be
zero, 1
or more cinemas showing a particular film. The key to database
analysis
is to be able to think about such associations and how they are
expressed
accurately in the class diagram. The ‘many to many’
relationship in Figure
2.1 above, which is how the world looks at first sight, becomes
resolved
into the idea of a new class called ‘Showing’ which allows us to
specify a
particular film being shown at a particular cinema at a
particular time–
hence the simple 1 at one end of the associations shown in
Figure 2.2
below.
As an exercise explain what change you would make to the
diagram in
Figure 2.2 if a single showing could include up to four separate
films. To
get to the full answer to this question will require that you have
studied

Chapter 8, but even if this is your first read through the subject
guide, you
should be able to take the first steps to allow for this detail to
be faithfully
recorded in the class diagram.
Film
Title
Director
Length
Rating
Showing
Day
Time
Cinema
Name
Phone no
Address
0..*
0..*
1
1
Figure 2.2: A class diagram for films, showings and cinemas.

24
Chapter 8 of this guide contains a lot more neccessary detail
about
analysing and designing databases, but the two diagrams above
should
give you a basic understanding of the task, and an informal
introduction
to the class diagram. Please note also that the example used in
Chapter
8 of this guide (a database of customer orders for various
products) is
commonly used in textbooks (see for example Laudon and
Laudon (2013)
Section 6.2). It is a fairly complex class diagram but an
excellent one for
the purpose of illustrating the task of analysing and designing a
database.
It is not, however, appropriate as the main basis for your
database project.
This is for two reasons. First, you will have used it to
understand the topic,
it is not your own idea. Second, given that this is a complete
‘solution’
to a common database application (a business processing orders
from
customers), and is already fully worked out by somebody else,
using it
means that you do not have the opportunity to demonstrate your
ability as
a database analyst and designer. Thus the Examiners will give
low

marks to any student who submits a database project that is
just based on the customer-order model.
Example 1
A database for the Human Resources department of a company
to hold
information on employees and the department they work for.
Data to be held
include the employee’s:
• family and first names
• age
• sex
• address of residence
• date of joining the company
• department (administration, distribution, manufacturing)
• job title (assistant, technician, specialist, consultant,
manager)
• head of their department (another employee)
• line manager to whom they report
• qualifications held
• training courses attended.
The system should have an input screen to allow new employees
to be added

to the database and a screen to allow employees who leave to be
deleted.
Similarly it should be possible to add or delete departments
(this is an
organisation that likes to reorganise itself) and to record when
an employee
moves from one department to another or from one job title to
another (for
example, a move or a promotion).
The system should produce the following reports on screen and
on paper:
• A report that lists all female employees with an MSc.
• A report that shows, for each department, the employees
sorted by family
name.
• A report that shows all employees who joined the
company before a given
date in date order.
• A query to show an employee’s line manager.
25
Example 2
A database is to hold information on students, the courses they
take and the
teachers who teach them. Data to be held will include a

student’s:
• name
• sex
• age
• address
• courses taken.
Each course has a name and meets up to three times during the
week (for
example, Tuesday 10–11, Wednesday 4–6). A course can have
one or more
teachers. The details of the teachers to be stored are:
• name
• telephone number
• qualification.
The system will allow a teacher to record homework marks for
students.
The system should have input screens to allow new students to
be added to the
database and a screen to allow students who leave to be deleted.
Similarly, it
should be possible to add or delete courses and teachers as well
as to record a
change in who is teaching or taking which courses.
The system must produce, on screen and on paper, a report that

shows:
• a query of all the people who teach a certain student
• a report of all students who have done 60 per cent or less
of their
homework assignments
• a report, by course, of the students enrolled sorted by
family name (for example, a register)
• a query as to all teachers who are teaching more than two
courses
• a list of all students who should be in class at a given time
(say, Friday
between 9.00 am and 2.00 pm).
2.3.1 Reporting database assignments
When preparing your report for the database assignment, you
are asked to
include the following items.
• A description of the database problem tackled.
• A class diagram of the application, showing the various
classes
identified and their associations. You must use UML notation as
shown
in Chapter 8.
• The normalised relations that you will implement in the
software, showing
the attributes and keys together with their field type and
‘picture’ (for
example, the type of data that is held – text, a date, a number,

etc).
• A sample table of the basic relations set up in the database
software
together with a small amount of data.
• Designs for data input screens and reports and queries
produced.
• Very brief description of how the system is operated and
the commands
used to undertake each task. (Note: it is assumed that this is
done
by using interactive commands of the database package, not by
any
programming.)
• Examples of the reports produced.
26
The total report should be about six pages of carefully laid out
text, figures
and diagrams, with an absolute maximum of eight pages
including all
examples of printouts or other necessary computer-generated
reports.
Reports must be permanently bound (for example, well stapled,
not
secured by paper clips or just slipped into plastic binders). Each
page
should be numbered and should have your student number on it.

The
report must be produced with the aid of a word processor and
you
are expected to insert relevant diagrams or screen shots into the
text.
Diagrams should either be prepared using a computer package,
or perhaps
done by hand and scanned in to the document.
2.4 Spreadsheet assignment
Reading activity
Read Chapter 7, Section 7.2 of Curtis and Cobham (2008) and
Chapter 12, Section 12.3
of Laudon and Laudon (2013).
The aim of this assignment is to demonstrate an understanding
of the basis
of undertaking analysis and design for a spreadsheet, as well as
to provide
evidence of the use of some of the main features of a
spreadsheet package.
Spreadsheets are tools used for analytical modelling purposes;
namely,
the description of a situation by a set of quantifiable variables
and their
relations. One of the most common uses of spreadsheets is in
accounting
a company.
However, spreadsheets have proved useful in a variety of
contexts
including, for example, project management, engineering,
geology,
statistics and operational research. From a management

perspective
spreadsheets can be seen as a type of decision support system
(DSS) (see
also Chapter 3 of this guide).
For this assignment we recommend that you approach it broadly
as a
decision support system intended to help somebody to use some
data to
make a decision or to gain some extra insight, rather than as a
simple
structured descriptive report like a balance sheet.
What we mean by this is that the spreadsheet should be able to
help
somebody by manipulating or modelling some data (you could
say ‘playing
with’ some data) and allowing the user to input their own choice
of
variables or parameters in order to assess the resulting outputs.
The basis of a spreadsheet developed in this style will be an
analytical
model that relates different types of data (probably mostly
numerical data)
in order to offer some insight.
Such a model may be built in six steps:
1. Framing the problem.
2. Identifying the variables and parameters that describe the
problem –
the input to the model.
3. Quantifying as many of these variables and parameters as

possible.
4. Specifying the relations among variables and how they
combine – in
other words, the model you will use.
5. Specifying the required output from the model in terms of a
user’s
interrogation of the model – reports.
6. Testing the spreadsheet with carefully chosen data and
identifying and
correcting errors.
27
Curtis and Cobham (2008, pp.236–38) provide a very useful
brief design
methodology for a spreadsheet along these lines, distinguishing
five
elements:
1. user information
2. input data
3. logic (for example, the model)
4. report (what the user wants to see or know)
5. errors.

The word ‘methodology’ is used to describe a framework for
undertaking
some task, combined with some tools to be used. In information
systems,
and in particular in development of systems, methodologies are
often
proposed, adopted and critiqued. In this case the methodology
being
proposed is contained in the two lists given here – one a set of
sequential
and necessary tasks, the other a proposed general structure or
template for
the spreadsheet itself.
In the example in Curtis and Cobham (2008), worksheets and
the
workbook feature of the Excel spreadsheet package are used to
specify a
separate worksheet for each of these five elements. Doing this
may seem
too complex for a simple project, but it can help you to
concentrate on the
core distinctions between input data, model and output.
The benefits of analytical modelling flow from the ability of the
user to
adjust and interrogate the model. Therefore, flexibility and
robustness are
required qualities for the model. A great deal of good modelling
practice
when developing spreadsheets is incorporated in the two
fundamental
laws of spreadsheet modelling.
• The first law specifies that any cell on the spreadsheet
should contain

either a variable (number or text string) or a formula, but never
a
combination of the two.
• The second law requires that any item of input data or
model
parameter should appear only once. This helps ensure that you
will
not have problems with inconsistent data or when updating
some
value.
Figure 2.3: A spreadsheet abiding by the two laws of
spreadsheet modelling.
28
Figure 2.3 gives a simple example of the application of these
two laws. The
spreadsheet problem uses the interest rate as an input variable
or parameter
and it is entered in one spreadsheet cell only (in cell C4).
Thereafter the
model makes reference to that cell to use the interest rate in any
subsequent
calculation. You should thus never write the cell formula for
cell D8 as
=C8*0.065 (assuming that the interest rate was 6.5 per cent) and
you
would certainly never replicate such a formula. The correct
approach is to

enter the formula in cell D8 as =C8*$C$4 – the use of the $
signs makes an
absolute and unchanging reference to cell C4. This is a formula
that can be
copied or replicated down the column. In this way we can be
sure that all
the formulae in column D use the same reference to the interest
rate. If and
when we wish to change it we need only enter the new rate (say
8.5 per
cent) once. The alternative approach of writing the formula as
C8*0.065
would mean that we had to hunt down every use of 0.065 and
change it
and the potential for error in doing that would be very great.
Interrogation of an analytical model usually means the
generation of
numerical results, but it could be as textual data. More
sophisticated
interrogation practices include:
• What-if? analyses – What if the interest rate was to go up
by 2 per cent?
• Sensitivity analyses – If the cost of one component of a
manufactured
product was to double, how much would the overall cost go up?
• Goal-seeking analyses – How much must the marketing
budget be if we
are to achieve a 4 per cent growth in market share? This
spreadsheet
would be based on a model that relates sales to marketing
spend.

• Optimisation – What is the optimal mix of advertising
spend as
between newspaper advertisements and television commercials?
In each case, answers to these questions will require a particular
style of
interrogation of a basic model.
You are expected to consider the following areas in your project
work and
to write about this in your report:
• analysis of a problem domain in terms of variables and
relationships
incorporated in a model
• overall design of a spreadsheet for clarity and to support
an appropriate
style of interrogation (‘what-if?’, optimisation, etc.)
• use of appropriate functions for data manipulation (for
example, sort,
sum, average, look-up tables and other simple mathematical and
statistical functions)
• formatting of cells for text and numbers
• design of an onscreen and printed report from the
spreadsheet
• design of graphical reports including the choice of an
appropriate
graph type.
Activity

When choosing a graph as the output from a spreadsheet suggest
the type of data that
would be suitable for display using:
• a pie chart
• a bar chart or histogram
• an x/y plot or scatter plot.
Two example assignments are given below. These are intended
to illustrate
the type of problem that you are expected to tackle. As with the
database
29
project you must choose your own spreadsheet problems from
the world
around you – from your college or business or something
associated with
some hobby or pastime. Economic data, exchange rates, share
prices,
demographic data or even the weather report may provide
appropriate
data. Suitable problems are those that require you to summarise
or model
numerical data (say up to 80 raw data points), to show a result
or a trend,
to permit some ‘what-if?’ questions to be asked and to produce
a printed
report and a graphic chart. Our experience as Examiners

suggests that
projects based on basic accounting reports, balance sheets, flow
of funds,
etc. are not good topics for this project. They are usually so set
in their
format, and so reliant on simple addition and subtraction, that
you have
little opportunity to demonstrate your own analysis and design
skills.
Example 1
A spreadsheet is to be used by a motor racing team to calculate
the appropriate
volume of fuel to have in the race car at the start of the race. A
driver can have
more fuel, but the car will be heavier and will travel more
slowly. On the other
hand, if the car is light on fuel, it will have to refuel more often
– and that takes
time. Other relevant issues are the length of the race, the
running conditions
(fast or slow, wet or dry), the air temperature and an estimate of
what the
competition is going to do. A spreadsheet is needed to let the
team manager
and the driver evaluate alternative approaches. During the race,
the model can
be updated with the actual fuel usage and refuelling times.
This example is probably of no interest to most readers, but to a
car racing
fanatic it is a fascinating and a welcome challenge. Your task is
to find
something as interesting to you to serve as the basis of your
spreadsheet.

Example 2
A spreadsheet is used to analyse the tax position of an employed
person in your
country. This will need you to do some research into the exact
details of the
tax rules of your country and will include issues of income tax
as well as health
and other social insurances, pension contributions, etc. The
circumstances of an
individual – for example, married or with children – will also
generally affect
the amount of income taken in tax, as may other characteristics,
such as age or
student loans.
The spreadsheet can be used to generate a table and chart
showing the
marginal tax rate that applies at various levels of income – that
is the
percentage of income taken in tax and other deductions as
income rises. The
model may also answer the reverse question, ‘How much do I
need to earn
gross to take home a given net amount?’ This is an example of
goal seeking.
You might also use such a model to inform a politician about
the marginal tax
rate that various individuals face and as a way to model new
and perhaps fairer
policies.
2.4.1 Reporting spreadsheet assignments
When reporting your spreadsheet assignment, you need to
produce the

following items:
1. A description of the spreadsheet problem tackled.
2. A paper-based model of the problem representing the
relations
between the independent and dependent variables that you use.
This
may be in the form of a diagram or as arithmetical equations.
For
example, if a model was developed to cost products from a
factory it
might be based on formulae such as:
30
a. base cost = materials cost + handling charge;
b. manufacturing cost = (batch set-up cost/batch size) + (time
on
machine * hourly machine rate)
c. total cost = base cost + manufacturing cost
This can be shown as above as formulae, but might better be
shown in
a diagram.
3. The design criteria used in preparing the spreadsheet (choice
of
multiple spreadsheets in a workbook, layout, task breakdown,
choices

made in cell formatting, use of colour).
4. A description of the key formulae used in the model (for
example, as
written for the spreadsheet).
5. Steps taken to enforce data validation (input validation,
cross-checking
of calculations, reporting of error conditions), and overall
integrity of
the model (appropriate use of cell referencing, not mixing
variables
and numbers in the same formula, etc).
commands
used to undertake each major task.
7. One or more figures showing the spreadsheet as it appears on
the
screen in whole or in part.
8. Reports and appropriately annotated graphs.
Remember, the total report should not exceed six pages of
carefully laid
out text. As with the database work, examples of printouts and
other
necessary computer generated reports can be appended. The
assignment
should have a copy of the submission form as the front page.
Reports must
be permanently bound together with the database report (for
example,
well stapled, not secured by paper clips or just slipped into
plastic

binders). Each page should be numbered and have your student
number
on it. The report must be produced with the aid of a word
processor and
you are expected to insert relevant diagrams or screen shots into
the text.
2.5 Reminder of learning outcomes
Having completed this chapter, the appropriate project work,
activities and
the Essential reading, you should be able to:
• develop and document small computer applications using basic
packages (for example, word processor, graphics editor,
database and
spreadsheet)
• recognise the need to work methodically and to meet deadlines
• appreciate the distinction between analysis work and design
work
• apply analytical and design techniques to systems
development
producing a paper design
• transform a paper design into a running application
• prepare a brief report on development work conveying
decisions taken
and associated reasons
• reflect this experience back on the other parts of this syllabus.

31
2.6 Test your knowledge and understanding
1. Sketch a class diagram for the following situations:
a. A library database to include novels, their authors, the
various
editions available and the publishers. How would you handle
multiple copies of the same edition of the same book, such as
you
might find in a college library?
b. A database of music considering songs, albums, singers,
producers,
writers.
Keep your class diagrams as simple as you can, but note all
complexities or confusions that you might need to deal with
later.
2. What spreadsheet chart would you use for the following
situations:
a. Monthly rainfall data over three years.
b. Numbers in a country’s population within age groups and by
gender.
c. Gold price in US$ over three years.
3. Sketch a paper model of a spreadsheet for the following
situations:
a. Calculating Body Mass Index (BMI). Weight data may come

in
pounds, grams or stones and pounds. Height data in inches,
centimetres or feet and inches. (You can find the BMI formula
online if need be.)
b. The cost per student of a class trip to the theatre. This is to
include
tickets, hire of a bus, insurance and meals. The cost will depend
on
the number of students who choose to go; for example, bus hire
is
fixed for n= 1 to 50 while every 10th ticket is free from the
theatre.
4. For each of the classes shown in the class diagrams sketched
in
Question 1 above add some essential attributes that you would
want to
store data about. Are you sure that you have always placed the
data in
the right class? Are there situations where it may be debatable?

[Database assignment is1060]UOL Student Number 090404702.docx

More Related Content

What's hot (19)

Similar to [Database assignment is1060]UOL Student Number 090404702.docx (20)

More from danielfoster65629 (20)

Recently uploaded (20)

[Database assignment is1060]UOL Student Number 090404702.docx