You are on page 1of 41

Chapter 4 – Entity Relationship (ER)

Modeling

1
Learning Objectives
• After completing this chapter, you will be able to:
• Identify the main characteristics of entity relationship components
• Describe how relationships between entities are defined, refined, and
incorporated into the database design process
• See how ERD components affect database design and implementation
• Understand that real-world database design often requires the reconciliation
of conflicting goals

2
The Entity Relationship Model (ERM)
• Forms the basis of an entity relationship diagram (ERD)
• Conceptual database as viewed by end user

3
Database Components
• Database’s main components
1. Entities
2. Relationships
3. Attributes
4. Keys (PK,FK , etc..)
5. Cardinality
6. Existence Dependence
7. Relationship Strength
8. Relationship Participation
9. Relationship Degree
10.Associative (Composite) Entities

4
1.Entities (1 of 2)

Entity :“things” is any object , place , person, product etc. that you want to track
/store in database. ( think like it is container or template)
• Refers to the entity set and not to a single entity occurrence
• ERM corresponds to a table—not to a row—in the relational environment
• ERM refers to a table row as an entity instance or entity occurrence
• In Chen, Crow’s Foot, and UML notations, an entity is represented by a
rectangle that contains the entity’s name
• The entity name, a noun, is usually written in all capital letters

Entity Name

Entity Attributes

5
1.Entities (2 of 2)
Entity : “things” or any object , place , person, product etc. (representation of class )
Entity Instance : singe occurrence of an entity

•Most variations SQL are not case sensitive however name convention should be consistent

Entity
Instances

Attributes StudentID LastName FirstNAme StudentAddress

Entity 00001 Smith John 555 PineApple Lane


Instances 00002 Smith Jane 555 PineApple Lane
00003 Davidson Brandon 2223 Oak Street

6
2.Relationships
• Relationship illustrate the association between two entities and the entities
that participle in a relationship are called “participants”.
• They are presented as straight line and operates both direction.
• Usually relationship has a name expressed as a verb and written on the
relationship line
Works

fills
Teaches

7
3.Attributes (1 of 3)
• Characteristics of attributes

• Required attribute: must have a value and cannot be left empty


• Last name , phone Number , SSN etc..
• Optional attribute: does not require a value and can be left empty
• Middle Name , Employee’s spouse name etc..
• Domain: set of possible values for a given attribute
• Date of birth > Date , Student grades > Char > A to F or 0 to 100.

8
3.Attributes (2 of 3)
• Characteristics of attributes

• Identifier(Primary Keys): one or more attributes that uniquely identify each entity
instance
• SSN , LastName + EmailAddress , LastName + BirthDate , can be atomic or composite
• Key attributes are underlined in the table structure.
• StudentTable(Lastname , FistName, SSN, PhoneNumber , etc…)
• Composite identifier: primary key composed of more than one attribute that can be
subdivided to yield additional attributes
• Simple attribute: (Atomic) attribute that cannot be subdivided

9
3.Attributes (3 of 3)
• Single vs Multivalued attributes
• Single-valued attribute:attribute that has only a single value
• RoomNumber , CostumerId etc. Keep in mind that a single-valued attribute is not
necessarily a simple attribute.
• Multivalued attributes: attributes that have many values
• Hobbies ,PhoneNumbers etc..
• Derived vs Stored Attributes
• Derived Attribute : Attributes derived (computed) from other stored
attribute. For example age from Date of Birth and Today’s date.
• Stored Attribute : An attribute, which cannot be derived from other attribute,
is known as stored attribute. For example, BirthDate of employee
• Complex Attributes : composite + multivalued attributes = complex attributes. ( multiple address ,
multiple phone number with area codes etc..)

10
4.Keys

• Keys are very important part of Relational database model. They are
used to establish and identify relationships between tables and also
to uniquely identify any record or row of data inside a table.
• Primary Key (PK)
• Foreign Key (FK)

11
5.Connectivity and Cardinality
• Connectivity: noting but relationship classification
• Include 1:1, 1:M, and M:N
• Cardinality: expresses the minimum and maximum number of entity
occurrences associated (or linked ) to the number of occurrence in other entity
• In the ERD, cardinality is indicated by placing the appropriate numbers beside the
entities, using the format (x, y)
• In general ; As cardinality is the maximum number of connections between table rows
(either one or many), modality is the least number of row connections! Modality also
only has two options, 0 being the least or 1 being the least.

12
5.Connectivity and Cardinality
Example Max 1 Max M
Connectivity : either 1:1 or 1:M depends constrains Min 1 Min 1

Perhaps lecturer can teach only one class in semester !


Conceptual ! teaches

Let’s say we have businesses rule about number of teaches


class
(1 ,1) (1,4)
• Instructor can teach only 4 class per semester
<cardinality will be here 4>

• How about professors can teach 3 class per


semester ?

13
6.Existence Dependence (1 of 2)
• Existence dependence
• Entity exists in the database only when it is associated with another related
entity occurrence
• Referred to as a weak entity
• Has a primary key that is partially or totally derived from parent entity in
the relationship

What happens payment entity ,if we delete loan


entity ?

weak

14
6.Existence Dependence (2 of 2)
• Existence independence
• Entity exists apart from all of its related entities
• Referred to as a strong entity or regular entity

What happens loan entity ,if we delete payment


entity ?
strong

• Database designer determines whether an entity is weak or strong


• Based on business rules

15
7.Relationship Strength
• Weak (non-identifying) relationship
• It cannot exist without the entity which it has a relationship
• Primary key of the related entity does not contain a primary key component of the
parent entity
• Strong (identifying) relationships
• Primary key of the related entity contains a primary key component of the parent
entity

16
8.Relationship Participation
• Optional participation (min. cardinality is 0)
• Any instance of one entity might participate in a relationship with another entity, but
this is not compulsory
• Mandatory participation (min. cardinality is 1)
• At least one instance of one entity must participate in a relationship with another entity

There are four main types of membership relationships


1. Mandatory for both entities: A member of staff must be assigned to a given department, and any department must have staff. There
can be no unassigned staff, and it is not possible to have an 'empty' department.
2. Mandatory for one entity, optional for the other: Any member of staff must be attached to a department, but it is possible for a
department to have no staff allocated.
3. Optional for one entity, mandatory for the other: A member of staff does not have to be placed in a department, but all departments
must have at least one member of staff.
4. Optional for both entities: A member of staff might be assigned to work in a department, but this is not compulsory. A department
might, or might not, have staff allocated to work within it.

17
Relationship Degree
• Indicates the number of entities or participants
associated with a relationship
• Unary relationship: association is
maintained within a single entity
• Recursive relationship: relationship exists
within a single entity type

• Binary relationship: two entities are


associated

• Ternary relationship: three entities are


associated

18
Example
Vehicle Relationship Manufacturing Division
• Corolla
• Camry • Compaq Car
• Rav4 • SUV
• C-HR • Jeep
• Prius Built • Van
• Yaris • Truck
• Highlander • Hybrid
• 4Runner • Maintenance
• Sienna • Logistic Support
• Tacoma
• Tundra

19
Example •

Vehicle Built Manufacturing Division


• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •

20


Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •

What is the degree of relationship ?


What is the connectivity ( relationship classification)?
What is the participation ?
What is the Cardinality ?

21


Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •

What is the degree of relationship ?


<Indicates the number of entities or participants associated with a relationship>
What is the connectivity ?
< nothing but relationship classification 1:1, 1:M, and M:N>

22


Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •

What is the degree of relationship ? =2


<Indicates the number of entities or participants associated with a relationship>
What is the connectivity ? = 1:M
< nothing but relationship classification 1:1, 1:M, and M:N>

23


Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •

What is the participation ?


<Optional participation (min. cardinality is 0)
Any instance of one entity might participate in a relationship with another entity, but this is not
compulsory.>
<Mandatory participation (min. cardinality is 1)
Every instance of one entity must participate in a relationship with another entity>
24


Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars No Relationship
• Sienna • with any Car
• Tacoma •
• Tundra •

Participation (Vehicle)=1 Participation (Division)=0


What is the participation ?
<Optional participation (min. cardinality is 0)
Any instance of one entity might participate in a relationship with another entity, but this is
not compulsory.>
<Mandatory participation (min. cardinality is 1)
Every instance of one entity must participate in a relationship with another entity> 25


Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •

What is the Cardinality ?


<In general ; As cardinality is the maximum number of connections
between table rows (either one or many) >

26


Example
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •

Cardinality (Vehicle)=1 Cardinality (Division)=4

What is the Cardinality ?


<In general ; As cardinality is the maximum number of connections
between table rows (either one or many) >
27
Crow’s Foot Notation

28
The Entity Relationship Model

29
Crow’s Foot Notation Example

Registration for exams.

30
Chen Notation

31
Source :Wikipedia 32


Let’s call our example for Crow’s foot
Vehicle Built Manufacturing Division
• Corolla •
• Camry • • Compaq Car
• Rav4 • • SUV
• C-HR • • Van
• Prius • • Truck
• Yaris • • Hybrid
• Highlander • • Farm Vehicles
• 4Runner • • Electric Cars
• Sienna •
• Tacoma •
• Tundra •

Cardinality (Vehicle)=1 Cardinality (Division)=4


Participation (Vehicle)=1 Relationship =Built
Participation (Division)=0

(min,max) (min,max)
(0,M) (1,1) 33
Associative (Composite) Entities
• Used to represent an M:N relationship between two or more entities
• Has 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

M N

c
1 M M 1

34
Database Design Challenges: Conflicting Goals
• Database designers must often make design compromises that are triggered by
conflicting goals
• Fallow the design standards and best practices.
• High processing speed may limit the number and complexity of logically desirable relationships
• Maximum information generation may lead to loss of clean design structures and high
transaction speed

• Best practices.
• Prevent bad data from being entered into tables of interest.
• Enforce business logic at the database-level.
• Documentation of important database rules.
• Enforce relational integrity between any number of tables.
• Improve database performance.
• Enforce uniqueness.

35
Developing an ER Diagram-Example (1/4)
• Activities involved in building and ERD
1. Create a detailed narrative of the organization’s description of operations
2. Identify business rules based on the descriptions
3. Identify main entities and relationships from the business rules
4. Develop the initial ERD
5. Identify the attributes and primary keys that adequately describe entities
6. Revise and review ERD

36
Did you finalize your ERD?

37
Developing an ER Diagram-Example (2/4)
Task 1.Create a detailed narrative of the organization’s description of operations

• We have small training center and we teach number of topics. We have staff and
teachers who works in 5 classrooms every night.

Task 2. Identify business rules based on the descriptions


• Every student must take at least one course.
• Each course should have unique course id ( and perhaps section)
• Each course must have a name.
• Each professor must teach at least one class per semester
• Each professor must have their own unique ID , last name and name.

38
Developing an ER Diagram-Example (3/4)

Task3 :Identify main entities and relationships from the business rules

• Easy to understand
• Simple boxes ,lines and text
• Easy to enhanced
• Highly abstract –no details
Task4 :Develop the initial ERD
• Only “Entities” visible [tables]
• Translation from business You are in
requirements Conceptual Data Modeling Stage..
Developing an ER Diagram-Example (4/4)

Task5 :Identify the attributes and primary keys that adequately describe entities
Task6: Revise and review ERD
• Enhanced from conceptual model
• Add attributes for each entity
You are in
• Add Relationships
Logical Data Modeling stage..
• Add Cardinalates
• Decide Key attributes
• Primary keys
• Foreign Keys
• Still generic not pointing to any specific database.
register teach
Questions ?

41

You might also like