Chapter 2: Data Modeling using ERD
E7C160A9.pdf
Objectives
After studying this chapter, you should be able to:
1.Define key terms such as Entity, Attributes
2.Explain Relationship, Cardinality Constraints
3.Construct ER diagrams to represent a given scenario.
Introduction
Data Modeling
is the first stage and a high-level picture of database design.
is the process of capturing the important concepts and
rules that shape a business and depicting them visually in a
diagram.
This diagram becomes the blueprint for designing the
physical thing.
Created by
macrovector at
www.freepik.com
Introduction
Aim of data modeling phase is to:
Describe what data is contained in the database.
(e.g. entities: Students, Lecturers, Courses, etc.)
Describe the relationships between data items.
(e.g. Students are supervised by Lecturers; Lecturers
teach Courses.)
Describe the constraints (Rules) on data.
(e.g. Student Number cannot be null)
Introduction
Common types of Database models
Flat file model.
Hierarchical model.
Network model.
Object-oriented model.
Relational model.
Database Development Process
The database development process includes collecting and
analyzing the data that a business needs to track, and then
diagramming the association of that data in an Entity-
Relationship Diagram (ERD).
Database Development Process
Major components in Database development process
Conceptual Model Features
Captures the functional and informational needs of a business.
Is based on current needs but may reflect future needs.
Addresses the needs of a business (what is conceptually ideal) but does not
address its implementation (what is physically possible).
Includes all entities and relationships among them.
Is called an entity relationship model (ERM).
Is illustrated with an ERD.
Specifies all attributes and relationship for each entity.
Entity Relationship Model Concepts
it can be used to represent the data requirements of a
business, and type of database that is used.
is a detailed, logical representation of the data for an
organization.
introduced by Peter Chen in 1976.
is a list of all entities and attributes as well as all relationships
between the entities that are of importance.
Entity Relationship Model Concepts
Goals of ER Modeling
Ensure that information appears only once.
Capture all required information.
Model no information that is derivable from other information
that is already modelled.
Locate information in a predictable, logical place
Entity Relationship Model Concepts
ER modeling is based on two concepts
Entities - defined as tables that hold specific information (data)
Relationships - defined as the associations or interactions
between entities
Entity Relationship Model Concepts
Steps to Build an ERD
Entity Relationship Diagrams (ERD)
An ERD is a model that identifies the concepts or entities that
exist in a system and the relationships between those entities.
Purposes of ERD
The database analyst/designer gains a better understanding of
the information to be contained in the database through the
process of constructing the ERD.
It serves as a documentation tool.
It is used to communicate the logical structure of the database
to users. In particular, it effectively communicates the logic of
the database to users..
Entity Relationship Diagrams (ERD)
Entities and Instance
An Entity can be a person, place, object, event or concept in the
end-user environment about which the company wishes to
maintain its data.
It is represented as a rectangle and entity name is written inside
the rectangle
EXAMPLES:
▶ Person: EMPLOYEE, STUDENT, PATIENT, DOCTOR
▶ Place: STORE, HOSPITAL, HEALTHCENTER
▶ Object: MACHINE, BOOK, CAR
▶ Event: SALE, REGISTRATION, RENEWAL
▶ Concept: ACCOUNT, COURSEEntity Relationship Model Concepts
Entity Relationship Diagrams (ERD)
Entities and Instance
Entities contain instances.
An entity instance is a single
occurrence of an entity.
Entities represent a set of instances
that are of interest to a particular
business or organization.
Entity Relationship Diagrams (ERD)
Attributes and its Types
Attributes describe entities and are the specific information that
must be known.
It is a single-valued property detail of an entity.
Attributes are represented by an oval.
Entity Relationship Diagrams (ERD)
Preferred Naming Convention
When assigning the names to an Entity or an Attribute, the following
rules are applied:
The entity name must be in capital, and first character of
attribute name must be capital.
The special characters (such as space, +, -, <, ? ) are not allowed
except underscore (‘_’).
The name cannot be repeated, except for the use of foreign
key/attribute.
Entity Relationship Diagrams (ERD)
Attributes and its Types
Simple attributes are:
those drawn from the atomic value domains;
also called single-valued attributes.
In a COMPANY database, an example of this would be:
Name = {‘Bassam’}
Age = {23}
Single or atomic attributes are attributes that cannot be
divided into subparts.
Entity Relationship Diagrams (ERD)
Attributes and its Types
Composite attributes are attributes that can be divided into smaller
subparts that represent basic attributes with independent meanings of
their own.
.
Entity Relationship Diagrams (ERD)
Attributes and its Types
Multivalued attributes are attributes that have a set of values for
each entity.
In a COMPANY database, an examples of a multi-valued attribute
is the degrees of an employee: BTech, MTech, PhD.
Entity Relationship Diagrams (ERD)
Attributes and its Types
Derived attributes are attributes that contain values calculated
from other attributes.
In the example here:
Age can be derived from the attribute Birthdate.
In this situation, Birthdate is called a stored attribute, which is
physically saved to the database
Entity Relationship Diagrams (ERD)
Attributes and its Types
Example of an entity with all types of attributes:
Entity Relationship Diagrams (ERD)
Key Identifier
A Key Identifier is an attribute or a group of attributes whose
values can be used to uniquely identify individual entity in an
entity set.
For the entity EMPLOYEE = {EmpID, Name, Address, Age, Salary}
Definite keys are any set that involve EmpID
Entity Relationship Diagrams (ERD)
Relationship, Relationship Instance, and Relationship Type
A relationship is a bidirectional, significant association between
two entities or between an entity and itself.
E.g. Employee (Ali) joins Project (Sohar Airport)
Relationship Instance is an association between entity instances,
where each relationship instance includes exactly one entity from
each participating entity type
Relationship type is a set of associations among entities of one or
more entity types.
Entity Relationship Diagrams (ERD)
Relationship, Relationship Instance, and Relationship Type
Example:
Entity Relationship Diagrams (ERD)
Types of Relationships
One – One
An instance of entity set ‘A’ is related to exactly one entity
instance of entity set ‘B’ and vice versa.
One – Many or Many – One
An instance of entity set ‘A’ is related to more than one entity
instance of entity set ‘B’.
Many – Many
An instance of entity set ‘A’ is related to more than one entity
instance of entity set ‘B’ and vice versa.
The maximum cardinality on either side of the relationship
represents type of relationship.
Entity Relationship Diagrams (ERD)
Degree of relationship type
Degree of relationship type is the number of participating
entity types.
There are two Degree of relationship types:
Unary (recursive) relationship type : the relationship
contains one entity.
Entity Relationship Diagrams (ERD)
Degree of relationship type
Binary relationship type: the relationship contains two entities
linked to each other. It is the most common.
Entity Relationship Diagrams (ERD)
Cardinality Constraint
Suppose there are two entity types A and B, which are
connected by a relationship. A cardinality constraint
specifies the number of instances of entity B that can (or
must) be associated with each instance of entity A.
Example:
Consider a store that rents CDs of the movies. A store may
stock more than one CD for each movie. Sometimes the
store may not have any CD for a given movie in the stock.
Entity Relationship Diagrams (ERD)
Cardinality Constraints
Cardinality is the term used in database relations to denote the
occurrences of data on either side of the relation. Cardinality
measures the quantity of something.
Minimum Cardinality
Maximum Cardinality
Minimum Cardinality
The minimum cardinality of a relationship is the minimum number
of instances of entity B that may be associated with each instance of
A. It is zero or one.
In the previous example, the minimum number of CDs of a given
movie at a given time is zero. Zero is the minimum cardinality.
Entity Relationship Diagrams (ERD)
Cardinality Constraints
Maximum Cardinality
The maximum cardinality of a relationship is the maximum number
of instances of entity B that may be associated with each instance of
A. It is one or many.
In the previous example, the maximum number of CDs of a given
movie at a given time is many (may be 2, 3, 4…). Many is the
maximum cardinality.
In general, participation in a relationship may be optional or
mandatory for the entities involved.
If the minimum cardinality is zero, participation is optional;
If the minimum cardinality is one, participation is mandatory.
Cardinality Example
An employee can work as a maximum on many projects but as a
minimum zero number of projects in case he is on a vacation. A
project to completed needs as a maximum on many employees but
as a minimum one employee
Max Cardinality
Min Cardinality
Entity Relationship Diagrams (ERD)
Basic ERD Notations
Entity Relationship Diagrams (ERD)
Basic ERD Notations
Entity Relationship Diagrams (ERD)
Attribute on Relationship
Attributes can be assigned to certain types of relationships as well
as to entities. An attribute of a many-to-many relationship such as
the "works-on" relationship between the entities employee and
project could be “Task_Assigned" or “Start_Date".
27
Entity Relationship Diagrams (ERD)
Weak Entity
Weak entity types are those whose existence depends on the
existence of other entity type
The weak entity types do not have key attributes of their own.
The keys of this type are partially or totally derived from strong
entity types.
28
Thank you
