16 Entity-Relationship Diagramming

16.1 Semantic Data Models

Database design is fundamentally a task in data modelling. A data model is an

architecture for data (chapter 10). Brodie has made a distinction between three
generations of data model (Brodie, 1984):

1. Primitive Data Models. In this approach objects are represented by record-

structures grouped in file-structures. The main operations available are read
and write operations over records.
2. Classic Data Models. These are the hierarchical, network and relational data
models. The hierarchical data model is an extension of the primitive data
model discussed above. The network is an extension of the hierarchical
approach. The relational data model is a fundamental departure from the
hierarchical and network approaches.
3. Semantic Data Models. The main problem with classic data models like the
relational data model is that they maintain a fundamental record-orientation.
In other words, the meaning of the information in the database - its
semantics - is not readily apparent from the database itself. The user of
databases using the classic approach must consciously apply semantic
information. For this reason, a number of so-called semantic data models
have been proposed (King and Mcleod, 1985). Semantic data models
(SDMs) attempt to provide a more expressive means of representing the
meaning of information than is available in the classic models.

Probably the most frequently cited of the SDMs is the Entity-Relationship data
model (E-R model) (Chen, 1976). In the E-R model the ‘real world’ is
represented in terms of entities, the relationships between entities and the
attributes associated with entities. Entities represent objects of interest in the
real world such as employees, departments and projects. Relationships represent
named associations between entities. A department employs many employees.

139
140 Information Systems Development

An employee is assigned to a number of projects. Employs and is assigned to are

both relationships in the Entity-Relationship approach. Attributes are properties
of an entity or relationship. Name is an attribute of the employee entity.
Duration of employment is an attribute of the employs relationship.

16.2 Entity Models

An entity model is a model of the entities, relationships and attributes in some

domain of discourse. An entity may be defined as ‘a thing which the enterprise
recognises as being capable of an independent existence and which can be
uniquely identified’ (Howe, 1986). A relationship can be defined as ‘an
association between entities’ (Beynon-Davies, 1992). An attribute is a property
of some entity.

16.2.1 Entities

An entity may be a physical object such as a house or a car, an event such as a

house sale or a car service, or a concept such as a transaction or order. Although
the term entity is the one most commonly used following Chen (1976) we
should really distinguish between an entity and an entity-type. An entity-type is
a category. An entity, strictly speaking, is an instance of a given entity-type.
There are usually many instances of entity-types.
Because the term entity-type is somewhat cumbersome, most people tend to
use the term entity as a synonym. We shall conform to this practice. It must be
remembered however that whenever we refer to an entity we mean an entity-
type.

16.2.2 Relationships

More than one relationship can exist between any two entities. For instance, the
entities house and person can be related by ownership and/or by occupation. In
theory, having identified a set of say 6 entities, up to 15 relationships could exist
between these entities. In practice, it will usually be quite obvious that many
entities are quite unrelated. Furthermore, the object of entity modelling is to
document only so-called direct relationships. For instance, direct relationships
exist between the entities Parent and Child and between Child and School. The
relationship between Parent and School is indirect; it exists only by virtue of the
child entity (Shave, 1981).
 Entity-Relationship Diagramming 141

16.2.3 Attributes

An entity is an aggregation of attributes. Values assigned to attributes are used

to distinguish one entity from another. Hence, deptNo, deptName, and location
are all attributes that characterise the Department entity. One or more of the
attributes of an entity are normally chosen as an entity identifier. The attribute
deptNo is a suitable identifier for the entity Department.

16.3 Semantic Modelling

The data needed to support a given information system does not usually fall
irrevocably into one of the three categories: entity, relationship and attribute. A
classic example is the data needed to be stored on marriages. Marriage could be
regarded as an entity with attributes such as date, place, and names of bride and
groom. It could similarly be regarded as the attribute marital status associated
with the entity Person. Finally, it could be represented as a relationship between
the entities Man and Woman.
One of the tasks of the entity modeller is to decide which of these viewpoints
is the most important for the information system under consideration. Hence,
data analysis is frequently referred to as semantic modelling (Date, 1990). The
aim is to represent data as it is perceived in the organisation under
consideration (Klein and Hirschheim, 1987).

16.4 Notation

Entity models are usually mapped out as entity-relationship diagrams (E-R

diagrams). The end product of entity-relationship diagramming is a model of
the entities and relationships in a particular domain of discourse.
An entity is represented on the diagram by a rectangular box in which is
written a meaningful name for the entity (figure 16.1a). A relationship between
entities is represented by drawing a line (sometimes labelled) between the
relevant boxes on the diagram (figure 16.1b). An attribute is represented by a
circle or oval attached by a line to the appropriate entity. The entity identifier is
underlined (figure 16.1c).
142 Information Systems Development

Entities

Customer BankAccount Branch

Relationship

holds
Customer BankAccount

Attributes

customerNo accountNo
holds
Customer BankAccount

customerName accountName

Figure 16.1: Entities, Relationships and Attributes

16.3.1 Properties of a Relationship

There are two properties of the concept of a relationship that are usually
considered important: we shall refer to them as cardinality and participation.
Cardinality (or degree) concerns the number of instances involved in a
relationship. A relationship can be said to be a 1:1 (one-to-one) relationship, a
1:M (one-to-many) relationship, or a M:N (many-to-many) relationship.
For instance, the relationship between bankaccounts and customers can be
said to be one-to-one (1:1) if it can be defined in the following way:

A bankaccount is held by at most one customer.

A customer may hold at most, one bankaccount.

In contrast, the relationship between bankaccounts and customers is one-to-

many (1:M) if it is defined as:

A customer holds many bankaccounts.

A bankaccount is held by at most one customer.

Finally, we are approaching a realistic representation of the relationship when

we describe it as being many-to-many (M:N). That is:
 Entity-Relationship Diagramming 143

A customer holds many bankaccounts.

A bankaccount may be held by many customers.

There are a number of competing notational devices available for portraying the
cardinality of a relationship. We choose to represent cardinality by drawing a
crows foot on the many end of a relationship (see figure 16.2a).
Participation (or optionality) concerns the involvement of entities in a
relationship. An entity’s participation is optional if there is at least one instance
of an entity that does not participate in the relationship. An entity’s
participation is mandatory if all instances of an entity must participate in the
relationship. The default participation is mandatory. If the participation is
optional we add a circle (an ‘O’ for optional) alongside the relevant entity (see
16.2b).

Degree/Cardinality

holds
Customer BankAccount

holds
Customer BankAccount

holds
Customer BankAccount

Optionality/Participation

holds
Customer BankAccount

holds
Customer BankAccount

Figure 16.2: Properties of a Relationship

16.4 Abstraction Mechanisms

The original Entity-Relationship model has been extended in a number of ways

(Teorey et al., 1986). One of the most important extensions is the support for
generalisation hierarchies (Smith and Smith, 1977). This allows us to declare
certain entities as subtypes of other entities. For instance, Manager, Secretary
144 Information Systems Development

and Technician might all be declared subtypes of an Employee entity. Likewise,

SalesManager, ProductionManager, etc., would all be declared subtypes of the
Manager entity. The important consequence of this facility is that entities lower
down in the generalisation hierarchy inherit the attributes and relationships of
entities higher up in the hierarchy. Hence, a sales manager would inherit
properties of managers in general, and indeed of employees in general.
Likewise, a sales manager would inherit the relationship of an employee to a
department.
In relatively simple cases it is convenient to indicate generalisation on an E-
R diagram by drawing disjoint or overlapping boxes (see figure 16.3a) (Harel,
1986). As the size of a diagram increases it is more practical to use a notation
built on relationship lines. In figure 16.3b we have represented generalisation
by an empty triangle (Rumbaugh et al., 1991).

Generalisation Product a
BankAccount
Bank Customer
Pension

Mortgage

b
Product

Pension Mortgage BankAccount

Figure 16.3: Generalisation Notations

The Abstraction mechanisms of aggregation and association can also be

represented on E-R diagrams.
Aggregation is the process by which a higher-level object is used to group
together a number of lower-level objects. For instance, iSBN, title, author,
publisher and dateOfPublication may all be aggregated together to form a Book
 Entity-Relationship Diagramming 145

entity. In the Entity-Relationship model, therefore, aggregation is implicit in

assigning attributes to an entity. Aggregation of entities can also appear on an
entity model. Hence, for instance, a Car entity might be built up of an assembly
of wheels, chassis, engine, etc. Assemblies of this kind can be represented by a
forked link from the aggregate entity to the part entities and a semi-circle at the
junction of relationship lines (see figure 16.4).
Association is a form of abstraction in which instances of one entity are
associated with instances of another entity. Association is, of course, implicit in
the way we define relationships on entity models.

Car

Wheel Chassis Engine

Figure 16.4: Aggregation

16.5 Validating an Entity Model against Requirements

A first-pass E-R diagram represents the basic structure of data needed in a given
information system. Most of the adherents of the technique recommend that an
entity model should be validated against some definition of processing
requirements. This definition will identify which entities and relationships must
be accessed, in what order, by what means, and for what purpose. A detailed
discussion of this topic is given in Beynon-Davies (1992).
Suppose we have the following extract from an E-R diagram representing an
educational application (figure 16.5) (Shave, 1981). We wish to validate this
entity model against a requirement to produce the staff/student ratio for a given
department. To perform this processing we need to access:

1. All staff of a department.

2. Each course taught by a member of staff.
3. Each student registered for a course.

This is indicated on the E-R diagram in figure 16.5 as a series of arrows.

146 Information Systems Development

Department

StaffMember

Module

Student

Figure 16.5: Validating an Entity Model

16.6 Producing a Relational Schema

E-R diagrams are generally drawn as a means of designing relational schema.

The process of transforming an E-R diagram into a relational database design
we refer to as accommodation. The process of accommodating E-R diagrams
involves the following steps:

1. Break down each many-to-many relationship into two one-to-many

relationships. This is done by interposing a link entity between the two
previous entities and drawing crow’s-feet to the link entity. The entity
identifiers for the two previous entities then become a compound entity
identifier for the link entity.
2. For each entity on our diagram we form a table, usually by making the entity
names plural.
3. The identifying attribute of each entity becomes the primary key of the table.
4. All other attributes of the entity become non-key attributes of the table.
5. For each one-to-many relationship post the primary key from the one end of
the relationship into the table on the many end of the relationship.
6. Optionality on the many end of a relationship tells us whether a foreign key
can be null or not. If the many end is mandatory the foreign key is not null.
If the many end is optional the foreign key can be null.
 Entity-Relationship Diagramming 147

Taking the educational application we transform all many-to-many

relationships to give us figure 16.6. Note, we have added some sample attributes
to the diagram. A skeleton relational schema expressed in the bracketing
notation is given below:

Departments(deptNo, deptName, ...)

StaffMembers(StaffNo, staffName, deptNo, ...)
Modules(moduleNo, moduleName, ...)
Students(studentNo, studentName, ...)
Allocation(staffNo, moduleNo, ...)
Registration(studentNo, moduleNo, ...)

deptNo
Department studentNo
deptName moduleNo
studentName
moduleName

StaffMember Module Student

staffNo

staffName
Allocation Registration

staffNo moduleNo moduleNo studentNo

Figure 16.6: Educational E-R Model

16.7 Case Study: A General Hospital Appointments and Operations System

Suppose we are given the brief of designing an appropriate information system

for the patients’ appointments and operations activities of a large general
hospital. Our initial analysis work provides us with the following brief
description of the existing manual system:

1. Patients must make an appointment at a given clinic session held at one of

the hospital’s clinics.
2. Doctors are allocated one or more appointments within a clinic session, but
only one doctor will be present at each appointment.
148 Information Systems Development

3. Operations are scheduled and allocated to one of a number of theatre

sessions held in the hospital’s operating theatres. Each doctor may perform a
number of given operations on patients. A given operation is done on only
one patient, but there may be more than one doctor in attendance.

From such a description, we get some initial idea of the important entities
involved in this system:

Clinic
ClinicSession
Appointment
Patient
Doctor
Operation
OperatingTheatre
TheatreSession

Note that we might have been tempted to add the entity Hospital to this list.
However, in this system there is only one instance of a hospital. Entities should
normally have many instances associated with them.
The text also gives some idea of relationships. A possible list is given below:

Patient - Operation
Doctor - Operation
Doctor - Appointment
Patient - Appointment
ClinicSession - Appointment
Clinic - ClinicSession
TheatreSession - Operation
Theatre - TheatreSession

Each of these relationships then needs to be characterised in terms of cardinality

and participation. For some relationships the text above does not provide
enough information. We therefore make a number of assumptions that would
have to be confirmed or otherwise by users. A possible diagram is given in
figure 16.7.
From this E-R diagram we arrive at the following relational schema by
applying the guidelines discussed in section 16.6.
 Entity-Relationship Diagramming 149

Clinics(clinicName, ....)
ClinicSessions(clinicName, sessionNo, ...)
Appointments(clinicName, sessionNo, patientNo, doctorNo, ....)
Patients(patientNo, ...)
Doctors(doctorNo, ...)
Operations(theatreName, theatreSession, operationNo, patientNo, ...)
Schedule(doctorNo, operationNo, ...)
Theatres(theatreName, ...)
TheatreSessions(theatreName, theatreSession, ...)

Note how we have formed compound keys in a number of tables, where the
foreign keys form part of the primary key. Note also how the table schedule
constitutes a link entity between doctors and operations.

Clinic

ClinicSession Doctor Theatre

Appointment TheatreSession

Patient Operation

Figure 16.7: Appointments and Operations Model

16.8 Goronwy Galvanising Case Study

Figure 16.8 illustrates an E-R diagram drawn for the case of the Goronwy
Galvanising system. Note how we have distinguished between delivery advice
notes and despatch advice notes. The entity despatch is a breakdown of the
many-to-many relationship between Job and DespatchAdvice. In other words, a
given job can be recorded on more than one despatch advice note.
150 Information Systems Development

Delivery Despatch
Product
Advice Advice

Job

Despatch

Figure 16.8: Entity Model for Goronwy

Applying the rules of accommodation as described in section 16.6 would

mean that we arrive at the following set of skeleton table structures:

DespatchAdvices(despatchAdviceNo, ...)
DeliveryAdvices(deliveryAdviceNo, ...)
Jobs(jobNo, deliveryAdviceNo, productCode, ...)
Products(productCode, ...)
Despatches(despatchAdviceNo, jobNo, ...)

Fortunately, this relational schema matches closely with the one generated from
the determinancy diagrams in chapter 10. In many circumstances this will not
be the case. The analyst frequently has to reconcile the results from top-down
data analysis with the results from bottom-up data analysis. See Beynon-Davies
(1996) for a more detailed discussion of reconciliation. Figure 16.9 indicates
how we might modify the E-R diagram in figure 16.8 to exploit generalisation.
Here we have made delivery advices and despatch advices both subtypes of an
advice class.
 Entity-Relationship Diagramming 151

Advice
adviceNo
Delivery Despatch
Product
Advice Advice
adviceDate

Job

Despatch

Figure 16.9: Generalisation Applied to Goronwy

16.9 Conclusion

Entity modelling as represented by the technique of E-R diagramming is

primarily a database design technique. An E-R diagram is conventionally
referred to as a conceptual model of a database system. From this conceptual
model we derive a logical model expressed usually as a series of table structures
in third normal form. The final step in database development is to produce a
physical model. That is, a series of record structures expressed in the syntax of
some programming language or DBMS. If the DBMS is relational this step is
relatively straightforward. If physical structures are COBOL files then the
process is a little more convoluted but not difficult (Howe, 1986).

16.10 References

Beynon-Davies P. (1996). Database Systems. Macmillan, London.

Brodie M.L. (1984) On the Development of Data Models. In Brodie M.L.,
Mylopoulos J. and Schmidt T.W. (eds) (1984) On Conceptual Modelling:
Perspectives from Artificial Intelligence, Databases and Programming
Languages. Springer-Verlag, Berlin.
Chen P.P.S. (1976). The Entity-Relationship Model - Toward a Unified View of
Data. ACM Trans. on Database Systems. 1. 9-36.
Date C.J. (1990) An Introduction to Database Systems. Vol. 1. 5th ed. Addison-
Wesley, Reading, Mass.
Harel D. (1986) On Visual Formalisms. CACM. 31(5) May 514-529.
152 Information Systems Development

Howe D.R. (1986). Data Analysis for Database Design. (2nd Edn.). Edward
Arnold, London.
King R. and McCleod D. (1985) Semantic Data Models. In Bing Yao S. (ed.).
Principles of Database Design. Vol 1: Logical Organisations. Prentice-Hall,
Englewood Cliffs. N.J.
Klein H.K. and Hirschheim R.A. (1989). Four Paradigms of Information
Systems Development. CACM. 32(10) October 1199-1216.
Shave M.J.R. (1981). Entities, Functions and Binary Relations: steps to a
conceptual schema. The Computer Journal. 24(1).
Smith J.M. and Smith D.C.P. (1977) Database Abstractions: Aggregation and
Generalisation. ACM Trans. Database Sys. 2(2) 105-133.
Teorey T.J. Yang D., and Fry J.P. (1986). A Logical Design Methodology for
Relational Databases Using the Extended Entity-Relationship Model. ACM
Computing Surveys. 18 197-222.

16.13 Exercises

1. Produce an E-R diagram that represents the following information

describing a horses breeding register: A racing horse is identified by a
unique name. The date of birth of the horse and its sex are also recorded.
Each horse has a father and mother. The system must be able to produce a
genealogy for each horse.
2. Produce a set of table structures from the E-R diagram produced for 1.
3. Draw an extended E-R diagram to represent the following classification
problem: Lions and Tigers are big cats; BigCats are Mammals; Mammals
are Animals.
4. Draw an E-R diagram to represent the following assertions: An Employee
uses a CompanyCar; a given CompanyCar will be used by a number of
different employees; some employees do not use any company car; all
company cars are used by at least one employee.
5. Why do you think the accommodation process to COBOL file structures is
more involved than that for relational systems?
6. Produce an E-R diagram to handle the data on a supermarket bill or a gas
bill.