CSIT115-Winter 2025

Introduction to Entity Relation Diagram (ERD) and

Object Modelling
Lab Requirement:
Quiz:

 You will need to attempt the quiz on Moodle Next week worth of 2 Mark
 Quiz will be based on lab1 and lab2 plus lecture materials and practice questions
 The quiz will be done on terminals in the lab (not your laptop), so please make sure the
computer Infront of you is working and your MyUOWD account is active.
 Using your mobile phone, or any other methods for cheating is forbidden and you will get
ZERO.
 You get feedback on the quiz by end of the week

Submission:

 There is no submission for this lab

Attendance/Participation Mark:

 Attendance will be recorded

 Participation and proving you are attempting the questions has 1 mark
 Failing to attend at least 1hr30min of the session means you will be marked absent! And
will not get your lab participation mark.

Introduction to Entity Relationship Diagram

An Entity-Relationship Diagram (ERD) is a visual representation of the data model that shows
the relationships among different entities in a database. It is a commonly used tool in database
design to illustrate how different entities relate to each other.

There are three main elements to be identified in ERD. Entity and Attributes are usually indicated by
Nouns in the description and Verbs are to point out the relations.

Entity/Attributes

An object/class that is further described by a set of attributes. The best what to distinguish between
attribute and entity is to know that attributes doe not need further description. For example in
sentence below:

Employees are assigned a job. Each job has a job title and a salary_amount.

Here Job is described by two attributes jab_title and salary_amount therefore it is an entity. Job_title
and Salary_amount are attributes of the job and do not have further explanation.

Relations:

 One-to-One (1:1) Relationship:

1
In a one-to-one relationship, one entity in the relationship is associated with only one instance of
another entity, and vice versa. For example, consider a "Person" entity and a "Passport" entity. Each
person can have only one passport, and each passport is associated with only one person.

 One-to-Many (1:*) Relationship:

In a one-to-many relationship, one entity in the relationship can be associated with multiple
instances of another entity, but each instance of the second entity is associated with only one
instance of the first entity. For instance, in a "Department" and "Employee" relationship, one
department can have many employees, but each employee is associated with only one department.

 Many-to-Many (M:N) Relationship:

In a many-to-many relationship, one instance of an entity can be associated with multiple

instances of another entity, and vice versa. Consider a "Student" and "Course" relationship. A
student can enroll in multiple courses, and each course can have multiple students. In order to
represent a many-to-many relationship in an ERD, an associative entity (or junction table) is often
introduced. This intermediate entity helps resolve the complexity of directly connecting many
instances of one entity to many instances of another entity.

We have special type of entities, attributes and relations namely:

 Weak entity: is an entity that belongs to another entity, in other words, an entity
that is identified by the primary key of another entity. Weak entity usually cannot form a primary
key by it’s own attributes.

Example: For each employee we record employee’s dependents details including their name
and date of birth.

Dependents’ attributes are not unique but if we combine the name with the employee id
number it will become unique.

Keep in mind that weak entity is always a one to many relationship and is represented as
below.

2
  Linked Attribute: an attribute that describes the relation between entities. Consider
example below:
Employees works on various projects and for each project they have different hourly rate.
Here hourly rate cannot be an attribute in employee, neither in project cause only for a
project that employee works on we can decide what is the rate. So hourly_rate is an
attribute of the relation.

 Association Class: a linked attribute that is given a name and has relation with other entities.
When an order is shipped to client, details such as date of shipment, shipment cost and
shipment method is saved. Each customer service agent is responsible for tracking more
than one shipment.
In this example attributes likes date of shipment, shipment cost and shipment method are
linked attribute. But since these details are tracked by customer service agent, we need to
give it a name and add a relation, which converts it into association class.

ISA Relation (Generalization): When few entities share the same set of attributes, we create
a main class with shared attributes, and separate class for each of entities with its own
attributes. In sub-entities, you should not mention the ID as it will be inherited from the top
entities.
Imaging having part time and full time employees, both have EID, Email and address. But
Full time employee has salary and part time employee has hourly rate.
Generalization can be (Mendatory, OR), which means an instance has to be be in one of the
sub-entities.

3
4
Visit http://draw.io/ to draw the diagrams for below tasks

Task 1:

Scenario: Consider a university system that involves four main entities: Faculty, Student, School and
Course. The relationships between these entities are outlined as follows:

Faculty member Entity:

Attributes: FacultyID (Primary Key), FacultyName, Department, OfficeLocation, ContactNumber, etc.

Student Entity:

Attributes: StudentID (Primary Key), StudentName, Major, ContactEmail, AdmissionDate, etc.

Course Entity:

Attributes: CourseID (Primary Key), CourseName, Credits, Schedule, Department, etc.

School Entity:

Attributes: SchoolID (Candidate key), School Name (Candidate key), tel

Relationships:

Teaching Relationship (Faculty to Course):

 Every faculty member teaches one or more courses.

 Every course is taught by one or more faculty members.

Enrollment Relationship (Student to Course):

 Each course is taken by zero or more students.

 Each student takes one or more courses.

Advisor Relationship (Faculty to Student):

 Every faculty member advises zero or more students.

 Each student is advised by one or more faculty members.

Dean Relationship: (School to Faculty)

 Every school has one Dean who is a member of faculty

 Every faculty member belongs to a school

Draw and ERD for the above Scenario.

5
Task 2:

A database is to be designed for a college to monitor students' progress throughout

their course of study. The students are reading for a degree (such as BA, BA(Hons)
MSc, etc) within the framework of the modular system. The college provides a
number of module, each being characterized by its code , title, credit value, module
leader, teaching staff and the department they come from. A module is coordinated
by a module leader who shares teaching duties with one or more lecturers. A lecturer
may teach (and be a module leader for) more than one module. Students are free to
choose any module they wish but the following rules must be observed: some
modules require pre-requisites modules and some degree programs have
compulsory modules. The database is also to contain some information about
students including their numbers, names, addresses, degrees they read for, and
their past performance (i.e. modules taken and examination results).

link to solution recording

Task 3:
The Advising Center at a hospital is aiming to streamline its patient advising services by
implementing an "Advising Website." This digital platform is intended to efficiently manage patient
requests for advising appointments and ensure the appropriate assignment of health advisors based
on their areas of expertise. In this system, there are several entities, including "Patient," "Advisor,"
"Advising Session," "Health Speciality," and "Rating.".

Patients are required to log into the system, creating profiles that encompass basic information such
as PatientID, FirstName, LastName, PhoneNumber, Email, and a selected health speciality of interest.

Advisors, who are hospital staff, have profiles containing AdvisorID, FirstName, LastName,
OfficeLocation, PhoneNumber, Email, and a SpecialityID representing their knowledge in specific
health guidance areas. Advisors can have expertise in more than one health speciality.

Advising sessions are scheduled interactions between patients and advisors. The "Advising Session"
entity includes attributes like SessionID, Date, Time, Location (Meeting Room 4.26, Meeting Room
4.27, or Meeting Room 3.26), Speciality (e.g., Nutrition, Mental Health, Physiotherapy etc.), and
Rating Information from the Rating entity. Each advising session is associated with a specific patient
and advisor along with associated ratings.

A "Health Specialty" entity captures the various health specialties in which advisors can have
expertise. It includes attributes such as HealthAreaID and SpecialityAreaName.

For feedback purposes, a "Rating" entity is introduced, consisting of attributes like RatingID,
RatingValue and feedback. Patients have the opportunity to provide a numeric rating (e.g., 1 to 10)
and feedback in a free-form text box after each advising session.