UNIT OBJECTIVE

After studying this course, you should be able

to:
a. Explain what is Data Modeling
b. Explain what is ERD
c. Draw and construct ERD
d. Understand best practices in writing ERD
 Introduction
● The logical design of a
database is the same no
matter what the RDBMS is
going to be.
● Physical design is
specifically tailored to the
features and limits of a
particular RDBMS.
 Data Modeling
● Data modeling is a technique to document a software
system using diagrams and symbols. It is used to
represent communication of data.
● The highest level of abstraction for the data model is
called the Entity Relationship Diagram (ERD). It is a
graphical representation of data requirements for a
database.
 ERD
● An entity-relationship diagram (ERD) is a data modeling
technique that graphically illustrates an information
system’s entities and the relationships between those
entities. An ERD is a conceptual and representational
model of data used to represent the entity framework
infrastructure.
● The main value of carefully constructing an ERD is that
it can readily be converted into a database structure.
ERD
 3 Components of ERD

● Entities: Number of tables you need for your

database.
● Attributes: Information such as property, facts
you need to describe each table.
● Relationships: How tables are linked together.
ERD Notation
Styles
3 Components of ERD
 Steps in creating ERD

1. Identifying and defining the entities

2. Determining all interactions between the
entities
3. Analyzing the nature of
interactions/determining the cardinality of the
relationships
4. Create the ERD
 Symbols used in ERD
● Rectangles: This Entity Relationship Diagram symbol
represents entity types
● Ellipses : Symbol represent attributes
● Diamonds: This symbol represents relationship types
● Lines: It links attributes to entity types and entity types
with other relationship types
● Primary key: attributes are underlined
● Double Ellipses: Represent multi-valued attributes
Symbols used in
ERD
ERD Example
 Entity
● An entity can be place, person, object, event or a
concept, which stores data in the database.
 Weak Entity
● A weak entity is a type of entity which doesn't have its
key attribute. It can be identified uniquely by
considering the primary key of another entity. For that,
weak entity sets need to have participation.
 Attribute
● It is a single-valued property of either an entity-type or
a relationship-type.
 Primary Key
● Also known as PK, a primary key is a special kind of entity
attribute that uniquely defines a record in a database table. In
other words, there must not be two (or more) records that
share the same value for the primary key attribute.
 Foreign Key
● Also known as FK, a foreign key is a reference to a primary
key in a table. It is used to identify the relationships between
entities. Note that foreign keys need not be unique.
Attribute - Types
Attribute - Types
 Relationship
● Relationship is nothing but an association among two
or more entities. E.g., Tom works in the Chemistry
department.
 Relationship
● Relationship is nothing but an association among two
or more entities. E.g., Tom works in the Chemistry
department.

Chemistry
Tom Works Department
 Relationship
● Relationship is nothing but an association among two
or more entities. E.g., Tom works in the Chemistry
department.
 Relationship - Degree
● Degree: Number of entity types that participate in a
relationship
● Three cases
a. Unary: between two instances of one entity
b. Binary: between the instances of two entity
c. Ternary: among the instances of three entity
 Relationship - Degree
● Three cases
a. Unary: between two instances of one entity
b. Binary: between the instances of two entity
c. Ternary: among the instances of three entity
 Relationship - Cardinality
● Cardinality: Defines the numerical attributes of the
relationship between two entities or entity sets.
 Relationship - Cardinality
● Relationships can also have a property called
cardinality. Cardinality refers to the number of allowed
related rows between entities.
● Maximum cardinality: The highest number permitted.
● Minimum cardinality: The smallest number permitted.
● RDBMSs really don’t have ways to enforce cardinality
rules directly. Usually, these kinds of rules are enforced
by means of triggers and other extra-database code.
 Relationship - Cardinality
● For example, say an Account entity can have no
more than five email addresses in a related Email
entity. That would mean that the relationship has a
maximum cardinality of five. Let’s also say that
each account must have at least one email
account. That would make the minimum
cardinality of the relationship one.
 Relationship - Cardinality
● Cardinality: Defines the numerical attributes of the
relationship between two entities or entity sets.
Relationship - Participation/Connectivity
Relationship - Participation/Connectivity
Relationship - Participation/Connectivity
Relationship - Participation/Connectivity
Relationship - Participation/Connectivity
Relationship - Participation/Connectivity

● Zero to One
● Exactly One
Relationship - Participation/Connectivity
Resource Table

Book Table

Magazine Table
Relationship - Participation/Connectivity
Relationship - Participation/Connectivity

● Zero or More
● At least one or
more
Relationship - Participation/Connectivity
● One to many
Relationship - Participation/Connectivity
● One to many
Department Table

Employee Table
Relationship - Participation/Connectivity
● Many to Many
● Many–to-many relationships are common, and they
are legitimate relationships in logical terms, but no
database can implement them. A many-to-many
relationship means that each record in the primary
entity can have many related records in a second
entity and each record in the second entity can have
many related records in the primary entity.
Relationship - Participation/Connectivity
Relationship - Participation/Connectivity
● In any RDBMS, a many-to-many relationship must be resolved
into two one-to-many relationships. This is done by creating a
linking entity. In this case, the Magazine and the Subscriber
entities are linked by a Subscription entity. A subscriber
subscribes to one or more magazines. A magazine can be
subscribed to by zero-to-many subscribers. Often, as in this
case, creating the linking entity reveals a forgotten or
undiscovered entity, Subscription is more than a linking entity.
It is a legitimate entity with attributes of its own.
Relationship - Participation/Connectivity
Magazine Table

Subscriber Table

Subscription Table
Relationship - Participation/Connectivity
ER Model in 3 Levels of Abstraction

● Conceptual ERD / Conceptual data model

● Logical ERD / Logical data model
● Physical ERD / Physical data model
ER Model in 3 Levels of Abstraction
ER Model in 3 Levels of Abstraction
Conceptual ERD models the business objects
that should exist in a system and the
relationships between them.
ER Model in 3 Levels of Abstraction
Logical ERD is a detailed version of a Conceptual ERD. A
logical ER model is developed to enrich a conceptual
model by defining explicitly the columns in each entity
and introducing operational and transactional entities.
ER Model in 3 Levels of Abstraction
Physical ERD represents the actual design blueprint of a relational
database. A physical data model elaborates on the logical data
model by assigning each column with type, length, nullable, etc.
 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.
 Example
STEP 1 - Identify Entities
 Example
STEP 2 - Identify Relationship
 Example
STEP 3 - Identify Cardinality
 Example
STEP 4 - Identify Attributes
 Example
STEP 4 - Identify Attributes
 Example
STEP 5 - Create Modern ERD
 Best Practices in Writing ERD
● Eliminate any redundant entities or relationships
● You need to make sure that all your entities and
relationships are properly labeled
● There may be various valid approaches to an ER
diagram. 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
 Best Practices in Writing ERD
● Name every relationship, entity, and
attribute are represented on your diagram
● Never connect relationships to each other
● You should use colors to highlight important
portions of the ER diagram
Any questions?