Topic 4

Entity
Database Design
And Development
Relationship
(ER) Modeling
Nor Azlina Binti Aziz Fadzillah
FSKM
UiTM NS, Kampus Seremban
Learning Objectives
The main characteristics of entity relationship components

How relationships between entities are defined, refined, and incorporated into the
database design process

How ERD components affect database design and implementation

That real-world database design often requires the reconciliation of conflicting goals
Entity Relationship Model (ERM)

Conceptual database as viewed by end user

Database’s main components

• Entities
• Refers to the entity set and not to a single entity
occurrence
• Attributes
• Characteristics of entities
• Relationships
• Association between entities that always operate in both
directions
 ER Diagram Examples

Example:
In a University database,
we might have entities for
Students, Courses, and
Lecturers.

Students entity can have

attributes like Rollno,
Name, and DeptID.

They might have

relationships with
Courses and Lecturers.
 Attributes
Required attribute • Must have a value, cannot be left empty

Optional attribute • Does not require a value, can be left empty

Domain • Set of possible values for a given attribute

Identifiers • One or more attributes that uniquely identify each entity instance

Composite identifier • Primary key composed of more than one attribute

Composite attribute • Attribute that can be subdivided to yield additional attributes

Simple attribute • Attribute that cannot be subdivided

Single-valued attribute • Attribute that has only a single value

Multivalued attributes • Attributes that have many values

• Attribute whose value is calculated from other attributes
Derived attribute
• Derived using an algorithm
Advantages and Disadvantages of Storing Derived Attributes
 Relationships

• Entities that participate in a relationship

Participants

• Describes the relationship classification

Connectivity

• Expresses the minimum and maximum number of entity

occurrences associated with one occurrence of related
Cardinality entity
 Cardinality

Defines the numerical attributes of

the relationship between two entities
or entity sets.

Different types of cardinal

relationships are:
•One-to-One Relationships
•One-to-Many Relationships
•Many to One Relationships
•Many-to-Many Relationships
Existence Dependence

Existence dependence Existence independence

Entity exists in the database only when Entity exists apart from all of its related
it is associated with another related entities
entity occurrence Referred to as a strong entity or
regular entity
RELATIONSHIP STRENGTH

Strong Entity ▪ Primary key of the related entity contains a

(identifying) relationships primary key component of the parent entity
 RELATIONSHIP STRENGTH

▪ Primary key of
Weak the related
Entity entity does not
contain a
(non-
identifying) primary key
relationship component of
the parent entity

In above ER Diagram examples, "Trans No" is a discriminator within

a group of transactions in an ATM.
Weak Entity
Conditions:
• Existence-dependent
• Has a primary key that is partially or totally derived from parent entity in the relationship

Database designer determines whether an entity is weak based on business rules

 One entity occurrence
does not require a
Optional participation corresponding entity
occurrence in a
particular relationship

Relationship
Participation One entity occurrence
Mandatory requires a
corresponding entity
participation occurrence in a
particular relationship
 Crow’s Foot Symbols

COURSE AND CLASS IN

A MANDATORY
CLASS IS OPTIONAL TO COURSE RELATIONSHIP
RELATIONSHIP DEGREE

Indicates the number of Unary relationship:

Binary relationship: Ternary relationship:
entities or participants Association is
Two entities are Three entities are
associated with a maintained within a
associated associated
relationship single entity

Recursive
relationship:
Relationship exists
between occurrences of
the same entity set
THREE TYPES OF RELATIONSHIP DEGREE

ER REPRESENTATION OF
RECURSIVE RELATIONSHIPS
Associative Entities
Also known as composite or bridge entities

Used to represent an M:N relationship between two or more entities

Is in a 1:M relationship with the parent entities

Composed of the primary key attributes of each parent entity

May also contain additional attributes that play no role in connective process
Converting the M:N Relationship into Two
1:M Relationships
 Developing an ER Diagram
Create a detailed narrative of the organization’s description of
Create
operations

Identify Identify business rules based on the descriptions

Identify Identify main entities and relationships from the business rules

Develop Develop the initial ERD

Identify the attributes and primary keys that adequately describe

Identify
entities

Revise and review Revise and review ERD

Each school is administered by a dean who is professor. Each department may offer NO or MANY courses.

Each professor can be dean of only one school.

Each school comprises several department

Each department belongs to only a single school.

 1:M relationship between COURSE
and CLASS.

CLASS is optional to COURSE

Each DEPARTMENT have one or more

PROFESSOR

Only one PROFESSOR chairs the

DEPARTMENT

No PROFESSOR is required to accept

the chair position

Therefore,
DEPARTMENT is optional to
PROFESSOR
PROFESSOR teach CLASS
CLASS is optional to PROFESSOR

BUSINESS RULE:

Professor teach no class or more CLASS

CLASS may be teaching by one

PROFESSOR
Components of the ERM
Database Design Challenges: Conflicting Goals

Conform Database design must conform to design standards

Need for high processing speed may limit the number and
Need complexity of logically desirable relationships

Need for maximum information generation may lead to loss

Need of clean design structures and high transaction speed
Various Implementations of the 1:1 Recursive
Relationship
Exercise 1
Given the following relational schema:

COURSE (CourseCode, CourseName)

SUBJECT (SubjectCode, SubjectName, TeacherCode)
TEACHER (TeacherCode, FName, LName, DeptCode)
COURSE_SUBJECT (CourseCode, SubjectCode, SubjectType)

1) Identify the primary key for each table

2) Briefly explain ONE (1) purpose of having primary key in database
Exercise 2
Consider the following relational schema:

Driver (driverID, driverName, driverContact, driverAdd, driverLicense)

Truck (truckID, truckName, truckDateBuy, truckWeight)
Journey (truckID, driverID)

a) Create a basic Crow's Foot ERD based on the above relational schema.

b) Write the business rules related to the above relational schemas.

DRIVER JOURNEY TRUCK

PK driverID FK truckID PK truckID
FK driverID
driverName
truckName,
driverContact
truckDateBuy,
driverAdd
truckWeight
driverLicense
Exercise 3
Create a Crow’s Foot ERD to include the following business rules for the
EaonCo company:

• Each sales representative writes many invoices.

• Each sales representative is assigned to one department.

SALES INVOICE

• Each invoice is written by one sales SALES DEPARTMENT

representative.
Exercise 4
How to Create an Entity Relationship Diagram (ERD)

➢ Steps to Create an ER Diagram

➢ Example: In a university, a Student enrolls in Courses. A student must be

assigned to at least one or more Courses. Each course is taught by
a single Professor. To maintain instruction quality, a Professor can
deliver only one course

Step 1) Entity Identification

We have three entities
•Student
•Course
•Professor
How to Create an Entity Relationship Diagram (ERD)
Step 2) Relationship Identification
We have the following two relationships
•The student is assigned a course
•Professor delivers a course
How to Create an Entity Relationship Diagram (ERD)
Step 3) Cardinality Identification
From the problem statement we know that,
•A student can be assigned multiple courses
•A Professor can deliver only one course
How to Create an Entity Relationship Diagram (ERD)
Step 4) Identify Attributes

Step 5) Create the ERD Diagram

Best Practices for Developing Effective ER
Diagrams
Eliminate any redundant entities or relationships

You need to make sure that all your entities and relationships are properly labeled

You need to make sure that the ER diagram supports all the data you need to store

You should assure that each entity only appears a single time in the ER diagram

Name every relationship, entity, and attribute are represented on your diagram

Consider the relationships between all entities and relate them with proper cardinality

Apply the technique of database normalization to re-structure the entities in a way that can
reduce data redundancy and improve data integrity.
 Summary
 ER Model in DBMS stands for an Entity-Relationship model
 The ER model is a high-level data model diagram
 ER diagrams are a visual tool which is helpful to represent the ER model
 ER diagrams in DBMS are blueprint of a database
 Entity relationship diagram DBMS displays the relationships of entity set stored in a database
 ER diagrams help you to define terms related to entity relationship modeling
 ER Model in DBMS is based on three basic concepts: Entities, Attributes & Relationships
 An entity can be place, person, object, event or a concept, which stores data in the database
(DBMS)
 Relationship is nothing but an association among two or more entities
 A weak entity is a type of entity which doesn't have its key attribute
 It is a single-valued property of either an entity-type or a relationship-type
 It helps you to defines the numerical attributes of the relationship between two entities or entity sets
 ER- Diagram DBMS is a visual representation of data that describe how data is related to each other
 While Drawing ER diagrams in DBMS, you need to make sure all your entities and relationships are
properly labeled.