Data Modeling Using Entity

Relationship Model
Objectives
After studying this chapter, you should be able to:
• Concisely define each of the following key terms:
Entity, entity type, entity set, simple attribute,
composite attribute, single valued attribute, multi
valued attribute, derived attribute, key, relationship,
relationship set, relationship type, degree of
relationship, weak entity, attribute on relationship
type, relationship constraint, participation.
• Construct ER diagrams to represent a given scenario.
Introduction

Data Modeling is the first step in the process of database

design. This step is sometimes considered as a high-level
and abstract design phase (conceptual design). The aim
of this phase is to:
 Describe what data is contained in the database (e.g.
entities: students, lecturers, courses, subjects etc.)
 Describe the relationships between data items (e.g.
Students are supervised by Lecturers; Lecturers teach
Courses )
 Describe the constraints on data (e.g. Student Number
has exactly 8 digits; a subject has 4 or 6 unit of credits
only)
Degrees of Data Abstraction
External Model
 Represent the user's view of the database
 Contain multiple different external views
 Are closely related to the real world as perceived by
each user

 For example, the screens of ATM machines may have

different types of views.
Data Abstraction
 Conceptual model is independent of both software
and hardware. Changes in either hardware or DBMS
software have no effect on the database design at the
conceptual level.
 Once a DBMS is selected, you can then implement it.
This is the internal model. Here you create all the
tables, constraints, keys, rules, etc. This is often
referred to as the logical design or internal model.
 The physical model is simply the way the data is
stored on disk. Each database vendor has its own way
of storing the data.
Conceptual Model
 Provide flexible data-structuring capabilities
 Present a “community view”: the logical structure of
the entire database
 Contain data stored in the database
 Show relationships among data including
 a) Constraints
 b) Semantic information (e.g., business rules)
 c) Security and integrity information
Conceptual Model
 Consider a database as a collection of entities (objects)
of various kinds
 Are the basis for identification and high-level
description of main data objects; they avoid details
 Are database independent regardless of the database
you will be using
 For example, the information of the Bank customers
will have similar structure for all the banks.
Internal Model
 The three best-known Internal models are
 the relational data model,
 the network data model
 hierarchical data model.

 For example, Bank Muscat may be using Oracle for

customer data, while Oman Arab Bank may use Sybase
for the same.
Internal Model
Internal Model Does..
 Consider a database as a collection of fixed-size records
 Are closer to the physical level or file structure
 Are representations of the database as seen by the
DBMS.
 Require the designer to match the conceptual model‟s
characteristics and constraints to those of the selected
detabse product
 Involve mapping the entities in the conceptual model to
the tables in the relational model.
Physical Model
 Are the physical representation of the database
 Have the lowest level of abstractions
 Defines how the data is stored.
 Affects Run-time performance.
Physical Model
 File organization and access methods are described
here.
 Data encryption .
 Are the physical level – managed by the operating
system
 Provide concepts that describe the details of how data
are stored in the computer's memory
 For example, Bank Muscat uses the Windows
operating system, while Oman Arab Bank uses Linux.
2.1 Database Application Development
Process
Database Application Development is the
process of :
• obtaining real-world requirements,
• Analyze requirement,
• design the data and functions of the system
• implement the operations in the system.
 The main phases of the database application
development process
Requirement Collection and Analysis
• interview the customers (database users)
• The result of this step is a document including the detail
requirements of the users.
Data Modeling
high-level and abstract design phase (conceptual design)
 Describes what data is contained in the database (E.g
entities: students, lecturers, courses, subjects etc.)
 Describes the relationships between data items (E.g
Students are supervised by Lecturers; Lecturers teach
Courses )
 Describes the constraints on data (E.g Student Number
has exact 8 digits; A subject has 4 or 6 unit of credits only)
Database Design
Database Logical Design:
which define a database in a data model
of a specific DBMS.
Database Physical Design :
which define the internal database
storage structure , file organization or
indexing techniques.
Entity Relationship Model (ER Model)
 The entity relationship (ER) data model has existed for
over 35 years. It is well suited to data modeling for use
with databases because it is fairly abstract and is easy to
discuss and explain. ER models are readily translated to
relations. ER models, also called an ER schema, are
represented by ER diagrams.
 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 (ER Model)
 Here is an example of how these two concepts might be
combined in an ER data model:
 “Lecturer Mohammed (entity) teaches (relationship)
the Database Systems course (entity).”
 For the rest of this chapter, we will use a sample
database called the COMPANY database to illustrate
the concepts of the ER model. This database contains
information about employees, departments and
projects
 Entity, Entity Set, Entity Instance and
Entity Type
 An entity is an object in the real world with an
independent existence that can be differentiated from
other objects. An entity might be
 • An object with physical existence (e.g., Employee,
lecturer, student, car)
 • An object with conceptual existence (e.g., Spouse,
course, job, position)
 OR
 Entity is a Person, place, object, event or concept in
the user environment about which company wishes to
maintain the data.
 Entity, Entity Set, Entity Instance and
Entity Type
An Entity is person, place, object, event,
or concept. For Example:
 Person: EMPLOYEE, STUDENT, PATIENT
 Place: STORE, WAREHOUSE, STATE
 Object: MACHINE, BUILDING,
AUTOMOBILE
 Event: SALE, REGISTRATION, RENEWAL
 Concept: ACCOUNT, COURSE, WORK
CENTER
 An Entity Type defines a collection of similar
entities

 An Entity instance is a single occurrence of an

entity type

 An Entity Set is a collection of entities of an entity

type at a point of time. In ER diagram, an entity
type is represented by a name in a box
In ER diagram, an entity type is represented by a
name in a box
Entity Set
Attribute and its Types
 An attribute is a property or characteristic of an entity
type.
 Each entity is described by a set of attributes.
 E.g. Employee = (Name, Address, Age, Salary)
In the diagram, each attribute is represented by an oval
with a name inside.
Naming convention
 While assigning the names to Entity or 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.

The following are the examples valid names of entity or attribute:

 MYDATA, Result, Total_Score, FinalBILL
The following are examples of invalid names:
 Tot Mark, Husband+Name, Department . Head
Types of Attributes
 SIMPLE attributes are attributes that are drawn
from the atomic value domains
E.g. Name = {John}; Age = {23}

 COMPOSITE
E.g. Address may consist of “Number”, “Street”
and “Suburb” → Address = {59 + ‘Meek Street’ +
‘Kingsford’}
Types of Attributes
 MULTIVALUED attributes: Attributes that
have a set of values for each entity
E.g. Degrees of a person: ‘ BSc’ , ‘MIT’, ‘PhD’
 DERIVED attributes: Attributes Contain
values that are calculated from other
attributes
Eg. Age can be derived from attribute
DateOfBirth. In this situation, DateOfBirth
might be called Stored Attribute
Notation of Composite attribute in ER Diagram

Notation of Multi valued attribute in ER Diagram

Notation of Derived attribute in ER Diagram

KEYS
 An important constraint on the entities is the key. Key
is an attribute or a group of attributes whose values can
be used to uniquely identify individual entity in an
entity set.
 For example, for the entity EMPLOYEE = {EID}

Key Notation
Key Identifier
 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 example, for the entity EMPLOYEE = {EmpID, Name,
Address, Age, Salary}
 Definite keys are any set that involve EmpID
 Possible keys might be {Name, Address}
 Unlikely keys: {Name}, {Age}

 There is a key that is chosen by the database designer used

as an identifying mechanism for the whole entity set,
known as primary key. This key is indicated by underlying
attributes in the ER model.
Key Identifier
 There is a key that is chosen by the database designer
used as an identifying mechanism for the whole entity
set, known as primary key. This key is indicated by
underlying attributes in the ER model.
Relationship, Relationship Instance, Relationship
Set and Relationship Type
 Relationship is an association among several entities
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
A relationship is a meaningful association between or
among entity types.
 To illustrate, consider the entity type EMPLOYEE and
COURSE. This is many to many relationships because each
employee may complete any number of courses.
Relationship type
 In the ER diagram, relationship type is
represented by a diamond with a name inside
and connects by straight line to the rectangles
representing entity type.

Relationship type notation

Degree of Relationship Type
 The degree of a relationship type is the number of
participating entity types.
 Unary (Recursive) relationship type is the relationship
that involves only one entity type. However, the same
entity type participates in a relationship type in
different roles.
Supervise Relationship
Degree of Relationship Type
Unary relation
In ER model, we have the diagram
Many-to-many relationship example
 Binary relationship type: This relationship type has
two entity types link together. This is the most common
relationship.
 For example the “Joins in” relationship between
EMPLOYEE and PROJECT

The ER diagram for this relationship type is :

Joins in Binary relationship
Many to Many Relationship
Example: An employee can join in several
projects and a project can have several
employees
Many-to-many relationship notation
 Cardinality and Cardinality
Constraints
 Cardinality is the term used in database
relations to denote the occurrences of data
on either side of the relation.
 Cardinality Constraints : 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.
 Minimum Cardinality
The minimum cardinality of a relationship
is the minimum number of instances of entity
B that may be
 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.
Basic ERD Notations
Basic ERD Notations
Basic ERD Notations
Attributes of Relationship Types
 Attributes may be associated with a many-to-many (or one-
to-one) relationship, as well as with an entity. For example,
suppose the organization wishes to record the date (month
and year) when an employee start each project. This
attribute is named Start_Date.

Attribute in relationship example

 Referring to Figure above, you will notice
that Start_Date has not been associated
with either the EMPLOYEE or PROJECT
entity. That is because Start_Date is a
property of the relationship Join In, rather
than a property of either entity. In other
words, for each instance of the relationship
Join In, there is a value for Start_Date.
Weak Entity Type
 Weak entity types are those whose existence depends on
the existence of other entity type.
 The weak entity type does not have key attributes of their
own. The keys of this type are partially or totally derived
from strong entity types

In ER diagram, weak entity and strong/weak relationship are denoted by

double box/diamond
The End