Unit 4: The Entity-Relationship (E-R) Data

Model

Entity, Attributes, Relationships and the E-R Diagram

Contents

• Introduction
• Key Definitions
• Entity, Entity Set and Entity Types
• Attributes
• Keys
• Nulls
• Relationships
Introduction

Data Models
• Data model is representation of
• things (or entities or classes) that are of importance to a system
• How the things relate to each other

• It is built and modified until it represents the system well enough to support a system model

• Data models are extended to become class diagrams in the Unified Modeling Language [UML] by
adding the behaviors of each entity to the model.
Introduction Continued…

Logical data modeling

• Method to discover data, relationships rules of a system, collectively called the system rules

Logical data models are the basis of:

• Physical data models, or actual databases
• Applications, parts of which can be automatically generated from the data model
Introduction Continued…

Example Student Records System Rules

• A student can be undergraduate or postgraduate but not both
• A student can enroll for maximum two courses per semester
• A semester runs for 6 months
• A course can run for many semesters
• A module is covered in one or more semesters
• E.t.c
Overview of the Student Records rules
• Says a lot about system structure
• Gives good picture of what database should look like
• Also gives good picture of underlying system rules
Introduction Continued…

• Entity Relationship Model (E-R Model)

• Also called E-R schema
• Based on two concepts
• Entities
• Relationships (association between entities)

• Graphically represented by the Entity Relationship Diagram (E-R Diagram)

Key Definitions

• Entity
• a thing or object in the real world with an independent existence that can be differentiated from other objects
• Entity Relationship Model
• The entity relationship model (ERM) is a conceptual model that represents the information structure of a problem
domain in terms of entities and relationships
• Entity set
• A collection of entities of an entity type at a particular point of time
• Entity Type
• a collection of the entities having similar attributes
• Attribute
• The characteristics or properties of an entity
Key Definitions Continued..

• multivalued attributes
• attributes that have more than one value for each entity
• derived attributes
• Attributes that contain values calculated from other attributes
• Relationships
• The associations or interactions between entities; used to connect related information between tables
• Key
• An attribute or group of attributes whose values can be used to uniquely identify an individual entity in an
entity set.
• Primary Key (PK)
• A key in a relational database that is unique for each record
• foreign key (FK)
• An attribute in a table that references the primary key in another table OR it can be null
• composite key
• composed of two or more attributes, but it must be minimal
Entity, Entity Set and Entity Types

Entity

Recall Definition:
- A thing or object in the real world with an independent existence that can be differentiated from other objects

Database Definition
- A thing, person, place, unit, object or any item about which the data should be captured and stored.

- An Entity can be:

- An object with physical existence (e.g., a lecturer, a student, a car)
- An object with conceptual existence (e.g., a course, a job, a position)
- Entities can be classified based on their strength.
Classes of Entities

• Entities can be classified as being Strong or Weak

Weak Entity
- An entity is considered weak if its existence depend on another entity. i.e, it cannot exist without a relationship with
another entity.
- Its primary key (Identity) is derived from the (identity) primary key of the parent entity
- Examples of Weak Entities:
- Spouse, in the COMPANY database, is a weak entity because its primary key is dependent on the Employee table.
Without a corresponding employee record, the spouse record would not exist.

- Address in a STUDENT database is a weak entity. Without a corresponding student record, the address record would
not exists.

- Account in a BANKING SERVICES database is a weak entity. Can you explain why this is so?
Classes of Entities Continued…

Strong Entity

- An entity is considered strong if it can exist apart from all of its related entities.

- Strong entities are also called Kernels: A table without a foreign key or a table that contains a foreign key that can contain
nulls

- Examples of Strong Entities:

- Student
- Lecturer
- Give more examples of naturally occurring entities
Entity Set and Entity Types

Entity Set: a collection of entities of an entity type at a particular point of time

• Collection of rows in a table at a particular time.
Example:
• The Entity Student(Student 1, Student 2,…, Student N) retrieved at a particular time.

Entity Type: a collection of the entities having similar attributes

• An Entity type becomes a table consisting of a set of fields.
• Example:
• an entity type STUDENT(Student_No, Firstname, Lastname, DOB)

Entity Occurrence: Instance of an entity type (A row in a table)

Example: A Row in STUDENT = {220019234, Nangolo, Sirkka, 20-08-1988}
Entity Set and Entity Types Continued…

• The E-R Diagram represents the Entity type for an Entity set
• The Entity type is represented as a Singular noun of the Entity set in a rectangle as shown in the
diagram below:
Represented as
Entity type StudentNo
• Student 1
• Student 2
Entity Set STUDENT •
STUDENT FirstName
•
•
• Student N
Surname

DOB
Existence Dependency

• Defined as the existence of an entity, which is dependent on the existence of the related entity.

• Has a mandatory Foreign Key (i.e Foreign Key CANNOT be NULL)

• Example:
• Weak Entities are Existence-dependent (Click on link to revisit Weak Entities)
Different Kinds of Entities

• Independent Entities

• Dependent Entities

• Characteristic Entities
Different Kinds of Entities Continued..

Independent Entities
• Also referred to as Kernels

Kernels have the following characteristics:

• They are the building blocks of a database.
• The primary key may be simple or composite.
• The primary key is not a foreign key.
• They do not depend on another entity for their existence.

Example:
• Strong Entities are Independent entities (Click on link to revisit Strong Entities)
Different Kinds of Entities Continued..

Dependent Entities
• Also referred to as Derived Entities. They depend on other entities for their meaning.

Have the following characteristics:

• They are said to be existence dependent on two or more kernels.
• Many to many relationships become associative tables with at least two foreign keys.
• They may contain other attributes.
• The foreign key identifies each associated table.
• There are three options for the primary key:
1. Use a composite of foreign keys of associated tables if unique
2. Use a composite of foreign keys and a qualifying column
3. Create a new simple primary key (Surrogate key)
Example: Student Records database (Marks Table)
Different Kinds of Entities Continued..

Characteristic Entities
• They provide more information about another table (Usually an independent entity)

Have the following characteristics:

• Represent multivalued attributes.
• Describe other entities.
• Typically have a one to many relationship.
• The foreign key is used to further identify the characterized table.
• Options for primary key are as follows:
1. Use a composite of foreign key plus a qualifying column
2. Create a new simple primary key
Example: Banking Services Database:
CustomerAccount Table (Will store of all types of accounts held by the customer at the bank)
Attributes

• Each Entity is described by a set of attributes (Recall definition of Attribute).

• Each attribute associated with an entity has:
• A name
• A domain of legal values
• Represented by an Oval shape with the name inside it on the E-R Diagram
• The example E-R diagram below shows the entity STUDENT with its associated attributes StudentNo, FirstName,
Surname, DOB.

STUDENT

StudentNo FirstName Surname Address

 Types of Attributes

Simple Attributes
• Drawn from the atomic value domains
• Also called as single-valued attributes
• (E.g. StudentNo, Firstname, Surname)
Composite Attributes
• Consist of a hierarchy of attributes Composite Attribute
STUDENT
• (E.g. Residential Address) Residential
StudentNo Address
Suburb

Simple Attributes FirstName Surname Street

Erf
Number
Types of Attributes Continued…

Multivalued Attributes
• Have a set of values for each entity type
• E.g. the different Accounts of a customer at the bank (Cheque, Investment, Credit Etc..)

Derived Attributes Age CUSTOMER

• Contain values calculated from other attributes
• E.g. Customer’s Age.
Accounts
FirstName Surname

NB: Note the kind of lines used in the E-R diagram to represent multivalued or derived attributes
Keys

• An important constraint on an entity.

• The key is an attribute or a group of attributes whose values can be used to uniquely identify an
individual entity in an entity set.

Types of Keys
• Candidate key
• Composite key
• Primary Key
• Secondary Key
• Alternate Key
• Foreign Key
Keys Continued…

Candidate Key
• A candidate key is a simple or composite key that is unique and minimal.
• It is unique because no two rows in a table may have the same value at any time.
• It is minimal because every column is necessary in order to attain uniqueness.

• From the Student Records database, if the entity is: STUDENT(StudentNo, IDNo, FirstName, LastName, CourseID)
• Possible candidate keys are:
• StudentNo
• IDNo
• FirstName and LastName – Assuming no student has the same name as the other
• LastName and CourseID – Assuming that no two students with the same last name can register for the same
course
Keys Continued…

Composite Key
• A composite key is composed of two or more attributes, but it must be minimal.
• From the Candidate Keys in the previous slide, possible composite keys are:
• FirstName and LastName – Assuming no student has the same name as the other
• LastName and CourseID – Assuming that no two students with the same last name can register for the same course

Primary Key (PK)

• A candidate key that is selected by the database designer to be used as an identifying mechanism
for the whole entity set (tuples)
STUDENT
• Must not be null
DOB
• Indicated on E-R Diagram by underlining the attribute StudentNo
• E.g. STUDENT(StudentNo, FirstName, Lastname, DOB) FirstName LastName
Keys Continued…

Secondary Key
• A secondary key is an attribute used strictly for retrieval purposes (can be composite), for
example: Phone and Last Name
Alternate Key
• Alternate keys are all candidate keys not chosen as the primary key

Foreign Key
• A foreign key (FK) is an attribute in a table that references the primary key in another table OR it
can be null.
• Both foreign and primary keys must be of the same data type.
• In our example entity STUDENT(StudentNo, IDNo, FirstName, LastName, CourseID), the attribute
CourseID is a foreign key because it references the primary key CourseID in the entity COURSE.
Nulls

A null is a special symbol, independent of data type, which means either unknown or inapplicable.
• It does not mean zero or blank.
Features of null include:
• No data entry
• Not permitted in the primary key
• Should be avoided in other attributes
Can represent
• An unknown attribute value
• A known, but missing, attribute value
• A “not applicable” condition
• Can create problems when functions such as COUNT, AVERAGE and SUM are used
• Can create logical problems when relational tables are linked
Relationships

• Association between two or more entities

• Used to connect related information between entities

Types of Relationships
• One-to-Many (1:M)
• One-to-One (1:1)
• Many-to-Many (M:N)
• Unary (Recursive)
• Ternary
Relationships Continued…

One to Many (1:M) Relationship

• A one to many (1:M) relationship should be the norm in any relational database design
• For example: One department has many Employees that work there. Therefore the relationship is
a one-to-many as shown in the diagram below:
DeptID
EmpID

EMPLOYEE N Works 1 DEPARTMENT

Name In
Office
Address

Salary Name

Relational Schema of the above E-R Diagram:

EMPLOYEE(EmpID, Name, Address, Salary, DeptID)
DEPARTMENT(DeptID, Name, Office)
Relationships Continued…

One to One Relationship (1:1)

• A one to one (1:1) relationship is the relationship of one entity to only one other entity, and vice
versa.
• It should be rare in any relational database design.
• In fact, it could indicate that two entities actually belong in the same table.
• An example from the COMPANY database is one employee is associated with one spouse, and one
spouse is associated with one employee
Relationships Continued…

Many to Many (M:N) Relationship

• Many to many (M:N) relationship cannot be implemented as such in the relational model
• For example: Where an Employee has different start dates for different projects, we therefore
need a JOIN(EmpID, Code and StartDate) entity to break the M:N into further 1:M relationships.
Code
EmpID

EMPLOYEE N Joins 1 PROJECT

Name In
Name
Address

Salary Budget

StartDate
Relational Schema
EMPLOYEE(EmpID, Name, Address, Salary)
PROJECT(Code, Name, Budget)
JOIN(EmpID, Code, StartDate)
Relationships Continued…

Mapping an M:N Relationship to 1:M

• For each M:N binary relationship, identify two relations.
• A and B represent two entity types participating in R.
• Create a new relation S to represent R.
• S needs to contain the PKs of A and B. These together can be the PK in the S table OR these
together with another simple attribute in the new table S can be the PK.
• The combination of the primary keys (A and B) will make the primary key of S.
Relationships Continued…

Unary Relationship
• also called recursive, is one in which a relationship exists between occurrences of the same entity
type
• The primary and foreign keys are the same, but they represent two entities with different roles
• separate column can be created that refers to the primary key of the same entity set

Supervisor
EmpID

Name EMPLOYEE Supervises

Address
Supervisee
Salary
Relational Schema
EMPLOYEE(EmpID, Name, Address, Salary, SuperID)
Relationships Continued…

Ternary Relationship
• A relationship type that involves many to many relationships between three tables

• Mapping Ternary (Many-to-Many) Relationships

• For each n-ary (> 2) relationship, create a new relation to represent the relationship.
• The primary key of the new relation is a combination of the primary keys of the participating entities that
hold the N (many) side.
• In most cases of an n-ary relationship, all the participating entities hold a many side.
Relationships Continued…

Ternary Relationship
Code
SID

SUPPLIER M Supplies
N PROJECT
Name
Name
Address
Quantity Date
Budget

N
PART

Relational Schema
PartID Colour
SUPPLIER(SID, Name, Address)
PartName
PROJECT(Code, Name, Budget)
PART(PartID, Name, Colour)
SUPPLY(SID, Code, PartID, Quantity, Date)
Home Work

NOTE: When it comes to E-R Modelling, Practice makes perfect!

• Ensure to carry out this exercise and present it during class

1. Create an Entity Relationship Model of a Student Records Database

a. Identify the following:
i. Entities
ii. Attributes
iii. Relationships
iv. Cardinality
b. Map out the M:N relationships accordingly

2. Represent your E-R Model using the E-R Diagram.

3. E-R Diagram to be presented in the next the online class.