Introduction to Health Informatics
Database concepts (3)
Database concepts (3):
Object models and Databases
by Robin Beaumont
e-mail: robin@robinbt2.free-online.co.uk
Contents
2.
LEARNING OUTCOMES CHECK LIST FOR THE SESSION................................................... 2-2
3.
INTRODUCTION ........................................................................................................................ 3-3
4.
A STRATEGY FOR SPECIFYING YOUR DATA REQUIREMENTS FOR A DATABASE ........ 4-3
5.
MODELLING DATABASES ....................................................................................................... 5-4
5.1 Classes and tables, objects and records ................................................................................ 5-4
5.2 Associations and relational DBMSs ........................................................................................ 5-5
5.2.1
One to many relationships .............................................................................................. 5-5
5.2.2
Many to many relationships ............................................................................................ 5-6
6.
THE MEANING OF RELATIONSHIPS (SEMANTICS) .............................................................. 6-7
7.
THE CONSULTATIONS MODEL .............................................................................................. 7-8
8.
THE LOG BOOK MODEL .......................................................................................................... 8-9
9.
THE HOSPITAL MODEL ........................................................................................................... 9-9
10.
THE DENTISTS MODEL .................................................................................................... 10-11
11.
SUMMARY ......................................................................................................................... 11-11
12.
CHECK WHAT YOU HAVE LEARNT ................................................................................ 12-11
13.
REFERENCES ................................................................................................................... 13-11
14.
ANSWERS TO EXERCISES .............................................................................................. 14-12
This handout is part of a course. For details of other material that
should be read before this please see Section 7.1 at:
http://robinbt2.free-online.co.uk/virtualclassroom/contents.htm
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 2-1
Introduction to Health Informatics
Database concepts (3)
2. Learning outcomes check list for the session
Each of these seminar sessions aims to provide you with a number of skills (the 'be able to's' below) and
appropriate information (the 'know what's' below). These are listed below. After you have completed the
session you should come back to these points ticking off those you feel happy with.
Learning outcome
Tick
box
Understand the relationship between a class and a
table

Understand the relationship between a object and a
record

Understand the relationship between an association
in a object diagram and a relationship in a relational
database (i.e. Access)

Indicate in an object model where foreign keys will
need adding to allow the creation of relationships in
Access

Understand how resolution tables relate to object
models

Be able to translate an object diagram into one or
more tables

Understand what the term 'semantics' refers to when
discussing databases

Be aware of the difference between data and
knowledge bases

Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 2-2
Introduction to Health Informatics
Database concepts (3)
3. Introduction
In database concepts 2 we discussed the concept of relationships in a Relational database Management
System (RDBMS). Working through the session an attempt was made to work out the various relationships
between tables and it became clear that some type of diagram would ease the problem significantly.
Since that time we have looked at object modelling. This session brings together the object model diagram
and the concept of the 'relationship' as found in a database. It describes the extremely important connection
between a method of designing the blueprint for a database (the object model) and the actual
implementation of it (the Access exercises).
This session, like most of the course, only skims the surface of the topic. You can find out much more about
linking Object models to database design in R Rumbaugh et al 1991 and more recently Blaha & Premerlani
1998. The Blaha et al book also provides an example in Access as well as a nice complex prescriptions
example on p.203. This session begins by describing the link between Object modelling and database
design and then moves on to discuss how exactly it is achieved.
4. A strategy for specifying your data requirements for
a database
The process of designing any computer system can be considered to consist of specifying two important
aspects, the what, that is the data (i.e. remember garbage in garbage out), and the how, that is the what it
does. Considering the process aspect; a system is worse than useless if it is difficult to use (i.e. for
entering or retrieving information), or hinders rather than facilitates working practices (i.e. If a system is
planned to be used in the consultation it should be easier rather than more difficult to prescribe and allow
the user to collect data in the way they would normally). Whilst the process aspect is as important as the
data side of things we will concentrate on the 'what' side of
things in this session.
Jargon
Object model
=
Design blueprint
Specifying
It is vitally important to get the design right but his involves
many revisions resulting partly from feedback from using the
actual database. For each iteration the object model allows
you to create a blueprint (model, specify, design whatever
term you want) of the data and the DBMS allows you to
create (implement, develop whatever) the actual database.
(Data dictionary)
Database
When people first start developing databases they always
make two fundamental errors. Firstly, they rush to a
computer to play with the DBMS, and secondly, they believe
they can create a perfect database by specifying a model
without creating a prototype of some sort.
Implementing
In the diagram the data dictionary is shown as a half way
house between the 'high level' object model(s) and the actual
database. Depending upon your inclination it is often not
necessary to produce a data dictionary as a detailed
description of each object is adequate - it's basically up to
you and whoever you may be working with (See Blaha & Premerlani 1998 for more detail).
(Access)
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 4-3
Introduction to Health Informatics
Database concepts (3)
5. Modelling databases
We have already discussed object models ('Introduction to object modelling (1)'). In fact databases are
simply a collection of objects themselves. More specifically the 'table' idea, which we have considered so
far, is simply a way of allowing the computer, via a piece of software called a DBMS, to store attribute and
instance details of objects. This all sounds rather abstract so I will now provide some examples. We will
first consider classes individually then the associations between them.
5.1 Classes and tables, objects and records
Class:
Class name
Patient
Attributes
Patient ID
First name
Surname
DOB
Sex
Address
Actions
See doctor
Database table
Table name = Patient:
ID
First name
Surname
DOB
Etc.
Class name becomes table name (not always)
Attributes in class model = fields in database
The above diagram demonstrates the relationship between a class and a DBMS table structure. The
attributes in the class diagram become fields in a table where the table name is the same as the class
name. Taking this one step further a object (class instance) is equivalent to a record in a table in the
database.
Database table
Table name = Patient:
Patient objects:
(Patient)
214
John
Smith
01/01/55
male
23 station st.
ID
(Patient)
023
Mary
Allan
21/11/65
female
23 pink lane.
214
023
First name
John
Mary
Surname
Smith
Allan
DOB
Etc.
01/01/55
21/11/65
Class Instances (objects) become table records
Value in object model = data item in database
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 5-4
Introduction to Health Informatics
Database concepts (3)
5.2 Associations and relational DBMSs
In 'Introduction to object modelling (1)' we discussed the idea of associations (e.g. one to one and one to
many associations). In fact this is pretty much the same as a 'relationship' in a relational DBMS e.g.
Access. Relational databases are based upon mathematical set theory. The standard book on the subject
is Date C J. 1995 (6th ed.) An introduction to database systems. The Relational database model was first
described by Codd in 1970. He subsequently defined a set of rules based upon mathematical principles.
His papers are referenced in Date 1995.
Examples are given below of the relationship between associations in object models and relationships in
relational DBMSs.
5.2.1 One to many relationships
Consider the relationship between a doctor and patient. One doctor may have many patients. (forget the
situation of a patient having more than one doctor for the moment). This can easy be draw using
Rumbaugh’s' standard symbols:
Doctor
Patient
'A doctor has zero or more patients'
But how do we turn the above into something that can be represented as one or more tables. In other
words something that can be used by a computer.
In database concepts 2 the concept of the relationship and foreign key where introduced. A foreign key is
a primary key in one table that is embedded in another (or the same) table. In the example given below
doctor ID is the foreign key value in the patient object. It allows the implementation in a DBMS of the
association shown in the above Rumbaugh class diagram.
Dr Leg has two patients, John Smith and Mary Allan
Doctor ID.
(Doctor)
12345
Walter
Leg
male
01/04/70
…
…
(Patient)
023
Mary
Allan
21/11/65
female
23 pink lane.
12345
(Patient)
214
John
Smith
01/01/55
male
23 station st.
12345
Doctor
Doctors ID
in the patient
object
'references' the
doctor object.
Exercise:
Re-draw the object instances
as records in two tables. If you
have problems refer back to the
previous section.
Patient
The foreign key is in this
side of the relationship
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 5-5
Introduction to Health Informatics
Database concepts (3)
5.2.2 Many to many relationships
Now for the more complex situation.
The one to many situation described above is rather restrictive as some patients may have more than one
doctor. In other words the above model does not cater for all situations that could occur. The previous,
database concepts (2) handout provided details how the many to many relationship situation is resolved by
the creation of a separate resolution table. This does not affect the Object diagram as it is not really
necessary to shown the table required in the database to solve the problem. However, some people do
prefer you to do this and it may help you create the database.
Dr Leg has two patients, John Smith and Mary Allan
Dr Thomson has one patient, John Smith
(Doctor)
12345
Walter
Leg
male
01/04/70
…
…
(Doctor)
98765
Dave
Thomson
male
06/04/50
…
…
(Patient)
023
Mary
Allan
21/11/65
female
23 pink lane.
(Patient)
214
John
Smith
01/01/55
male
23 station st.
How do we
link them?
A Dr has zero or more patients. A patient belongs to one or more Drs.
1+
Patient
Doctor
The foreign keys
added to a new
'resolution' table
Patient Table:
Doctor Table:
12345
98765
Walter
Dave
Leg
male
Thomson male
023
214
01/04/70
06/04/50
Mary
John
Allan
Smith
21/11/65 female
01/01/55 male
'resolution' table
12345
12345
98765
023
214
214
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 5-6
Introduction to Health Informatics
Database concepts (3)
6. The meaning of relationships (semantics)
People get very excited by attributing a great deal of knowledge and meaning to databases. In the '80s a
great deal of research went on in developing 'semantic models'. These were basically modelling techniques
which had a wider range of modelling symbols, such as inheritance which we have come across in object
oriented modelling. The standard semantics of models are entities (classes), properties (attributes =fields),
relationships and subtypes (date p.350). Therefore the meaning, or rather the semantics of the model are
these elements nothing more or nothing less. Date 1995 p346 - 371, provides, for this area of work, an
unusually lucid account of semantic modelling i.e. what we have been doing in this chapter with the models.
Because no diagrammatic modelling technique can fully explain the complexity required in some databases,
narratives are added which frequently take the form of sets of rules or constraints (e.g. if patient female and
between 15 -40 years alert doctor to cervical screaming). They usually require programmers to implement,
although a lot can be done with filtering out certain records and querying the records in some way. Such
databases that contain these rules are frequently referred to as Knowledge bases. Although, nowadays
the word is often used for any database regardless of its' complexity.
It is possible to derive the models we have been using from a set of narrative statements. Such statements
have in the past been called predicates (date p.97) but are now more commonly called 'business rules'.
We have been doing this in a very simple way by providing a set of sentences (a narrative) describing the
object model in each of the object diagrams in this handout.
The 'meaning' of the data is also closely related to the very important idea of 'functional dependency'.
Basically the dependency between various pieces of data (for example your can't have a blood result
without first having a patient). This is closely related to a process known as normalisation which provides a
method to ensure the data is correctly structured in terms of functional dependency which will be considered
latter in the course.
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 6-7
Introduction to Health Informatics
Database concepts (3)
7. The consultations model
This model will be used as the basis for the practical sessions with Access. Mark this page as you
will need to constantly refer back to it.
Exercise 1:
Mark on the relevant objects in the diagram below which foreign keys will need adding to them
for the model to work in a referential DBMS. The answer can be found at the end of this handout.
A doctor has zero or more patients. A patient can only belong to one
doctor. A patient can have zero or more episodes. A episode is related
to one patient. A episode has zero or more primary, secondary and
other diagnoses associated with it. A diagnosis is only related to one
episode.
Doctor
Patient
Other
diagnosis
Episode
Primary
diagnosis
Secondary
diagnosis
Notice this is what you were trying to describe in the exercise at the end of section 2.7 Database concepts
(2).
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 7-8
Introduction to Health Informatics
Database concepts (3)
8. The Log Book Model
Exercise 2:
Consider what information you would need to keep if you where to develop an electronic log book
to allow you to analyse:
Type of patients seen
Type of procedures you were involved in
Level of competence for each procedure
Success of the interventions you were involved with
Any other areas you might consider to be important
9. The Hospital Model
Examples of other modes are given below.
1. The hospital conceptual model part A.
A operating theatre has zero or more sessions allocated to it which are either routine or emergency.
A theatre has one or more nurses allocated to it.
Operating
Theatre
+1
Nurse
Emergency
session
Routine
session
Adapted from OU M866 book 1 p52
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 9-9
Introduction to Health Informatics
Database concepts (3)
2. The hospital conceptual model part B (adapted from Open University M866 book 1 p52)
A team of doctors provide treatment.
A team is specific to one specialty.
The team only has one consultant.
A team has one or more junior doctors.
Team
Note: this diagram will be developed
substantially through the course.
Assumption:
A doctor may provide zero treatments
Consultant
+1
Treatment
Junior Dr
Adapted from OU M866 book 1 p52
3. The hospital conceptual model part C (adapted from OU M866 book 1 p52)
A ward has zero or more patients. Each ward has zero or more nurses.
Each nurse and patient is allocated to only one ward.
A patient has zero or more treatments. Each treatment is unique to a particular patient.
A treatment may consist of zero or more prescriptions. A prescription is unique to a treatment
A prescription has one or more drugs. A drug is related to one or more prescriptions.
Ward
Adapted from OU M866 book 1 p52
Nurse
Treatment
Patient
Prescription
+1
+1
Drug
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 9-10
Introduction to Health Informatics
Database concepts (3)
Exercise 3:
For the three models above indicate in which class (entity) the foreign keys will need to be added
for implementation in a relational DBMS.
10. The Dentists Model
Exercise 4: Draw the object model which is implied from the information given below. The
answer is given at the end of this handout. .
A dental practice has one or more dentists and zero or more dental nurses.
Each dentist has zero or more clients. Each client receives zero or more treatment sessions.
Each session has a cost associated with it.
11. Summary
In this session we have investigated the idea of mapping 'relationships' from object models onto a DBMS
On a more theoretical level we have discussed the 'semantics' of such models.
12. Check what you have learnt
Now go back to the beginning of the material for the session and read the 'Learning outcomes check list' for
the session. How many can you tick? If you are not sure about any particular ones read again through the
relevant material if that fails please contact me.
13. References
Blaha M Premerlani W 1998 Object-oriented Modeling and design for Database applications: Includes UML.
Prentice Hall [web site: http://www.ontassociates.com]
Date C J. 1995 (6th ed.) An introduction to database systems
Reingruber Michael C.
Chichester
Gregory William W 1994 The Data Modeling Handbook John Wiley & Sons
Rumbaugh J Blaha M Premerlani W Eddy F Lorensen W 1991 Object Oriented Modeling and Design.
Prentice Hall International.
Open University 1993 Relational Database Systems M866 (Five books; Introduction to database
technology, The Relational Modal, Normalisation, Using SQL, SQL database management) [These are
excellent resources with many exercises and clear concise explanations].
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 13-11
Introduction to Health Informatics
Database concepts (3)
14. Answers to exercises
Exercise 1:
Mark on the relevant objects in the diagram below (consultations model) which foreign keys will need
adding to them for the model to work in a referential DBMS.
Answer: In patient object, Dr ID. In Episode object Dr ID and Patient ID. In each of the diagnosis tables
episode ID.
Exercise 4:
Draw the object model which is implied from the information given below. A dental practice has one or
more dentists and zero or more dental nurses. Each dentist has zero or more clients. Each client receives
zero or more treatment sessions. Each session has a cost associated with it.
A dental practice has one or more dentists and zero or more dental nurses.
Each dentist has zero or more clients. Each client receives zero or more treatment
sessions. Each session has a cost associated with it.
Dental
practice
+1
client
Nurse
dentist
Treatment
session
cost
Document Info:
Robin Beaumont Tel:0191 2731150
e-mail: robin@robinbt2.free-online.co.uk
Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc
Date: 28/03/00
Robin Beaumont 16/02/2016 Tel:0191 2731150 e-mail: robin@robinbt2.free-online.co.uk Source: Laptop; D:\533564847.doc
Page 14-12