1. Database Systems 4th edition Connolly and Begg Chapter 11
CM2020: Introduction to
Database Systems
Conceptual Modelling with
The Entity Relationship Model
Database Systems 4th edition
Connolly and Begg Chapter 11
Nirmalie Wiratunga

2. Aim of Lecture Outline the steps involved in designing a database
Explain the first phase: Conceptual Modelling
Study a particular conceptual model:
Entity Relationship (ER) Model
By the end you should be able to
Explain what conceptual design is, and how it is used
Represent a real-world situation as an ER Model
Understand an ER model constructed by someone else
This lecture is on Conceptual Modelling, which is the first step in designing a database, before you even think about creating any tables.

3. Role of Conceptual Modelling within the design process
Real-World Organisation / Problem
Identify key concepts and data needs Create a conceptual model
Conceptual Data Model
Logical Data Model
Convert model to structures required by database (relational, object-oriented, etc.)
This is how conceptual modelling fits into the overall design process.
When designing a DB, you start with a real world situation or organisation such as a library or an estate agent, and end up with a database on the disc. This slide shows the steps in between.
1) Identify important concepts: library, books borrowers. How do they relate?
2) Analyse the user’s requirements, so that you’re sure you know what you want the system to do.
What queries the system will have to answer, what reports you want it to generate.
If you’re doing this job for a paying customer, it’s a good idea to produce an agreed user requirements document, listing the user’s requirements and all the assumptions you’re making about the model - then he can’t turn round at the end and say that the DB doesn’t behave as he intended.
Getting to the real world to a conceptual model is in general a difficult problem, and undergraduate students get an entire course on it.
In general there isn’t a single right answer; there will usually be many different ways of modelling a given real-world situation, some better than others. It’s also an iterative process; that means that typically you come up with an idea for a model, then discover that it doesn’t quite work, so you have to go back and refine it.
For the purposes of this course, we’ll stick to relatively simple examples.
Physical Model (via DBMS)
Implement using a DBMS (MSA, ORACLE): create tables, add data, constraints, etc.

4. The Conceptual Data Model
Abstract view of situation
Identify important entities and relationships between them
Library: Books, Members, Carpets
Member borrows Book
Use human understandable terms, not computer terms
Tables, Combo Boxes, Foreign Keys…
Implementation independent
One form is the Entity Relationship (ER) model
Basis for the next step: the logical model
Forming the conceptual model is the first stage in designing a database. So, what IS the conceptual model? What does it contain?
Easier to illustrate with examples, but basically the conceptual model a high level description of a situation or problem,
Estates and physical resources might well might want to keep track of how old the carpets are.
What is important depends on the need of the client.
Identifying the most important things, and leaving out the less important details.. It mainly includes objects and the relationships between them, and constraints on the objects.
For example, in a library, objects might be members and books. Members BORROW books, so that forms a relationship between members and books; and say members can only borrow 6 books at a time, that’s a constraint. It’s important that it’s expressed in the user’s terms, so talk about books and borrowers, not tables and records and combo-boxes.

5. Simplicity of ER modelling
Suppose we wish to record details of staff working on project.
Works_on
ER diagram
Staff
Project
Tables
Staff
StaffId Name Title
WorksOn
Project 1 ∞ 1
StaffId ProjectId
ProjectId Name StartDate ∞
The first step according to the approach we teach here is to create an entity relationship model.
After all, the final object is to create a relational database, so why not just talk to the customer about what he wants, define your tables, type in the data, take your money and go?
For complex problems that’s unlikely to be very successful. In the next couple of slides I’ll try to give a couple of reasons why.
ER diagram is simpler.
In a more realistic situation, when there are MANY entities in the diagram, ER diagram is a lot easier to follow
ER diagrams are simpler than the table representation

6. Purpose of ER modelling?
ER model is simpler and easier to understand
Helps discussions with customers and fellow-workers
Separates
Modelling the real-world problem situation
Designing the DB tables for a DBMS (e.g. MSA)
Most large organisations will require ER Modelling
(Last bit)
If you try to create the tables without doing the ER modelling first, then you’re trying to do two things at once. You’re both trying to understand and model the real-world situation, and you’re also trying to fit it into the format required by a relational database. That’s quite hard, and for all but the simplest tasks, you aren’t likely to get very good results.
If you do it in TWO steps, you can first of all concentrate on the situation you’re trying to model; then, once you’ve built the model, the second step is to convert the model to tables, and you can concentrate on the particular requirements of a relational database.
So, those are two reasons why it’s a good idea to start the design process with ER modelling.
If you’re writing a DB for the fish and chip shop down the road, all they’ll care about is that you deliver something that works. However, if you become a professional software engineer, you will almost certainly be required to carry out some form of modelling as part of the database design process, so it’s probably a good idea to learn it while you’re here

7. Contents Components of an ER model Entity Relationship
Entity sets and descriptions
Relationship
Functional and membership class descriptions
Constraints and Assumptions
Putting it all together with example ER Models
Advance concepts
Inheritance
Recursion
Ternary relationships
I’ve given you some simple examples of an ER model.
I now want to look at the components of the model in more detail.

8. Components of an ER Model
The ER Model consists of four items:
1. An ER Diagram (using Bachman Notation)
- graphical representation of the entities and the relationships between them
2. A formal description of each entity in terms of its attributes and identifiers
3. Descriptions of the meaning of relationships
4. Descriptions of any constraints on the system and of any assumptions made
Note: the completion of an ER Model is iterative and unlikely to be successful first time round

9. Example of a realistic ER diagram
Makes
Driver
Trip
Vehicle
Incurs
Includes
Uses
Food Processor
Expense
Maintenance
Engineer
Qualification
Holds
Customer
Stop
Delivers
Receives
Food Processor Type
Has
Undergoes
Visits
Date-obtained
Performs
Staff
Most of the examples in this lecture have been very simple.
This slide makes the point that a realistic ER diagram will include LOTS of entities and relationships.

10. How do you obtain an ER Model ?
Given a specification, you need to identify the following concepts:
Entities: ‘things’ with physical or conceptual existence - usually nouns
Relationships: between entities - usually verbs
Attributes: of each entities and sometimes relationships
any constraints or assumptions

11. Identify ER Concepts in a Specification
Entity Attribute Relationship
Departments control many projects and each department has many employees. Each employee works on only one project at a time. A project’s start date must be before the project’s target completion date.
Entities: departments, projects, employees
Relationships: control - between departments and projects
has - between departments and employees
works_on - between employees and projects
You may be given a description of a situation and have to come up with a conceptual model.
That means you have to identify the entities, relationships, attributes and constraints.
Date is a noun, but it doesn’t have any relationships, and it doesn’t have any attributes of it own, so it’s simplest to make start date and end datae attributes of project.
The slides is an example of the first steps in going from a textual description to an ER model.
Attributes: Start date, completion date for project. NI number, name, address for employee.
Constraints: A project’s start date must be before its target completion date.

12. Contents Components of an ER model Entity Relationship
Entity sets and descriptions
Relationship
Functional and membership class descriptions
Constraints and Assumptions
Putting it all together with example ER Models
Advance concepts
Inheritance
Recursion
Ternary relationships
I’ve given you some simple examples of an ER model.
I now want to look at the components of the model in more detail.

13. Entity Definition Entity Set: a collection of similar entities
real-world object distinguishable from other objects and described using a common set of attributes.
Diagrammatically shown as
Entity Set: a collection of similar entities
E.g. all employers, all students
the set tends to have the same number of attributes
must have a primary key
entity-name

14. Entity Examples Delivery database College registration database
Drivers Customers Deliveries Invoice
College registration database
Student Instructor Classroom Course
Restaurant database
Menu Recipe Ingredient Order
Personal Music database ?

15. Descriptions of entities
Properties of entities are called attributes
Simple or composite e.g. name (firstname, surname)
Identifiers: One or more unique attributes are chosen as an identifier for the entity (a.k.a. primary key)
Single or multi-valued e.g. hobbies {cycling,reading,music}
Derived e.g. TotalCost (UnitCost * Quantity)
Entity description = Entity name + identifier + other attributes
Entity Set: the set of entity descriptions
Primary Key
Two John Browns, or two Harpreet Singhs in the MSc class.
Entities in the ER model have quite a lot in common with tables in a database.
They have attributes and primary keys, for example.
When you come to create your database, each entity will turn into a table.
However, an entity is not the same thing as a table!!!

16. Entity Sets Entity Sets Supervisor Student do NOT include foreign keys
at the conceptual modelling stage
Supervisor(staffID, name, jobTitle, address)
Student(studentID, name, address, staffId*)
Other Examples of Entity Sets: Driver(driver#, first-name, surname, address, #points) Exam(module#, student#, grade)
In ER model, relationship is indicated by line.
Don’t need to use a FK as well – that would be superfluous.
Also ER model is meant to be independent of the kind of database you’re going to create.
You might be building a network database which doesn’t have foreign keys! Then you’d find you couldn’t do it.
In an ER model, the attributes of an entity are properties of that entity alone, NOT properties of any entity which it may be linked to

17. Contents Components of an ER model Entity Relationship
Entity sets and descriptions
Relationship
Functional and membership class descriptions
Constraints and Assumptions
Putting it all together with example ER Models
Advance concepts
Inheritance
Recursion
Ternary relationships
I’ve given you some simple examples of an ER model.
I now want to look at the components of the model in more detail.

18. Relationships An association among entities.
Supervisor supervises student
Relationships are described in terms of their
Functionality
Membership Class
Attributes
supervises
Supervisor
Student

19. Relationship: Functionality
Each supervisor can supervise many students, but each student has only one supervisor
supervises
Supervisor
Student
Functionality answers two questions:
Can the supervisor have more than one student? Yes
Can the student have more than one supervisor? No
So we’re interested in the MAX number of each entity involved: is it 1 or many?
DO BACHMAN diagram of lecturer/course
Professor heads department. Each department is headed by exactly one professor. DO BACHMAN
Now another example...

20. Functionality Types
1- to -1
1- to many
many to -1
many to many
Functionality types are based on different mappings between entities

21. Relationship: Membership Class
A supervisor does not have to supervise any students. A student has to have a supervisor.
supervises
Supervisor
Student
Supervisor’s participation in supervision is optional
Student’s participation in supervision is mandatory
The membership class answers two questions:
Must the supervisor have at least one student? No
Must the student have at least one supervisor? Yes
So we’re interested in the MIN number of each entity involved: is it 0 or 1? Where, 0 means optional and 1 means mandatory
DO BACHMAN diagram of lecturer/course
Professor heads department. Each department is headed by exactly one professor. DO BACHMAN
Now another example...

22. Combining Functionality and Membership
A student must have at least one supervisor, and not more than one supervisor
supervises
Supervisor
Student
A supervisor may supervise no students, or may supervise many students

23. Relationship: Example 1
Hamilton
Castle School
Paul
Stevens
High School
Brian
Hill School
Walters
employ
School
Teacher
Every school must employ atleast one or more Teachers Every teacher must work in at most one school

24. Relationship: Example 2
Hamilton
Castle School
Paul
Stevens
High School
Brian
Hill School
Walters
employ
School
Teacher
Every school must employ one or more Teachers Every teacher may work in zero or one school
- Paul does not work in any school

25. Relationship: Example 3
Hamilton
Castle School
Paul
Stevens
High School
Brian
Hill School
Walters
employ
School
Teacher
Schools can employ many teachers, but
some schools have yet to recruit.
Some teachers do not work whilst others work in a school.

26. Relationship: Example 4
Hamilton
Castle School
Paul
Stevens
High School
Brian
Hill School
Walters
employ
School
Teacher
Schools can employ many teachers, but some schools have yet to recruit
All teachers must work in a school.

27. Description of Relationships
supervises
Supervisor
Student
Functionality: one to many, written [1:M] many to many, written [M:N] one to one, written [1:1]
Membership class: optional to mandatory, written [o:m]
Description of relationship is therefore: Supervises: Supervisor supervises student [1:M] [o:m]
Note this is the third component of the model, but it makes sense to include it here along with the discussion of relationships

28. Description of Relationships with Attributes
Assistant works in Lab for many hours per week.
hours
Assistant
Lab
works_in
Does every assistant have to work in a lab?
Does every lab have an assistant.
Can one assistant work in several different labs?
Description of relationship
works_in(hours): assistant works in lab [M:N] [o:m]

29. Contents Components of an ER model Entity Relationship
Entity sets and descriptions
Relationship
Functional and membership class descriptions
Constraints and Assumptions
Putting it all together with example ER Models
Advance concepts
Inheritance
Recursion
Ternary relationships
I’ve given you some simple examples of an ER model.
I now want to look at the components of the model in more detail.

30. Descriptions of Constraints / Assumptions
Examples of constraints:
#points on driver’s license must be less than 11
pickup_date must be before delivery_date
Driver title must be Mr, Mrs or Ms
Examples of Assumptions
Typically involve assumptions made about a relationship’s membership and/or functionality
CONSTRAINTS: These are useful, because when you come to create the DB, they can be represented as validation rules which prevent users from entering invalid data.
I’ve now told you everything you need to know about basic ER modelling.
There are a few additional features which you can include in your ER diagram

31. Contents Components of an ER model Entity Relationship
Entity sets and descriptions
Relationship
Functional and membership class descriptions
Constraints and Assumptions
Putting it all together with example ER Models
Advance concepts
Inheritance
Recursion
Ternary relationships
I’ve given you some simple examples of an ER model.
I now want to look at the components of the model in more detail.

32. Example ER model: a staff project management system
ER diagram
supervises
Supervisor
Student
Entity Sets
Supervisor(StaffID, Name, JobTitle, Address)
Student(StudentID, Name, Address, date_enrolled, completion_date, DOB)
Relationships
Supervises: Supervisor supervises student [1:M] [o:m]
Constraints/Assumptions
Student’s date_enrolled must be before completion_date

33. Example ER model: A library System
ER diagram
return-date
borrows
Member
Book
Entities
Book(ISBN, title, author,…)
Member(MemberID, name, address, phone#, …)
Relationships
Borrows(return-date) – members borrow books [1:M][o:o]
Constraints and assumptions:
A member can borrow up to 6 books at once
Each book can be borrowed by at most one member
Before explaining the entity relationship model in detail, I’m going to show you a very simple example of one, so that you can see where we’re heading
An entity relationship model consists of entities, attributes and relationships. Entities are objects, usually corresponding to nouns in the description A library has books and members. So the objects in our model will be books and members.
Attributes are properties of things.
Atts for book will be title, author, etc.. Atts for member will be name, address, etc. There is also a relationship between members and books, where members borrow books.
We shall also be concerned with what is called the FUNCTIONALITY of relationships. What functionality means in the library example is how many books a member can borrow, here it’s 6, and how many members can borrow one book.

34. Contents Components of an ER model Entity Relationship
Entity sets and descriptions
Relationship
Functional and membership class descriptions
Constraints and Assumptions
Putting it all together with example ER Models
Advance concepts
Inheritance
Recursion
Ternary relationships
I’ve given you some simple examples of an ER model.
I now want to look at the components of the model in more detail.

35. Advanced Concepts of ER diagrams
ER Diagram, which is part of the ER Model, can become more complex i.e., we may have the following:
Entity Subsets and Supersets
Complex Relationships
Involuted or Recursive Relationships
Ternary Relationships

36. Entity subsets and supersets
Staff
makes
Driver
Trip
has
Branch
performs
Engineer
Maintenance
Branch has many Staff.
Engineers perform many maintenance tasks.
Drivers make many trips.

37. Unusual Relationships
Recursive
manages
Employee
Ternary
works on
Project
Programmer
The manages relationship can be converted into an attribute that is part of the employee entity.
Sometimes the relationship needs to be converted into a table itself.
Convert works on
into an entity
Site

38. Summary ER Modelling A conceptual design technique
Is independent of the type of logical model / database you’re going to transform it into
Contains entities, attributes, relationships and constraints/assumptions
ER Diagram is a graphical representation using the Bachman notation
Connolly and Begg Relational Databases uses the Chen notation

39. More examples of Bachman Notation
governs
Principal
University
A principal must govern exactly one university
A university can’t have more than one principal, and may have no principal
Description: Principal governs university [1:1] [m:o]
commands
Dark Lord
Minion
This is recap Right-hand column indicates functionality - maximum number of instances involved in relationship.
Extra symbols at the bottom indicate participation constraints - minimum numbers involved in relation.
Note how the numbers and the symbols relate - there is some duplication of information.
When drawing diagram, you can either attach attributes them to entities, or list them separately below the diagram. Probably better to list them below, so as not to clutter the diagram. The main function of the diagram is to show the relationships between entities; the attributes are just additional details.
A dark lord may have no minions, or he may have many minions.
A minion must have exactly one Dark Lord
Description: Dark Lord commands minion: [1:M] [o:m]

40. Identify Entities and Attributes
Entity Attribute Relationship
“We need a database to track the movement of stock items. Each item has a code number and comes from a particular supplier. Each item can be used on one of many platforms. Each platform has a name and location”.
Each supplier has an id code, name, address and phone number”.
Each location has a latitude, longitude, and sea area name.
Lessons from this example:
It isn’t always obvious what the entities should be.
Occam’s razor is a good rule; don’t create any more entities than you have to.