Lecture Notes Unit 1 chapter 6 E-R MODEL

RDBMS - Unit I
Chapter 6
Database design and ER Model
Prepared By
Dr. S.Murugan, Associate Professor
Department of Computer Science,
AlagappaGovernment Arts College, Karaikudi.
(Affiliated by AlagappaUniversity)
Mailid: muruganjit@gmail.com
Reference Book:
Database System Concepts by Abraham Silberschatz, Henry
F.Korth , S. Sudharshan

6.2 The Entity-Relationship Model
➢ The entity-relationship (E-R) data model represents
the overall logical structure of a database.
➢ The E-R model is very useful in mapping the
meanings and interactions of real-world enterprises
onto a conceptual schema.
➢ The E-R data model employs three basic notions:
entity sets, relationship sets, and attributes.

6.2.1 Entity Sets
➢ An entity is a "thing" or "object" in the real world that
is distinguishable from all other objects.
➢ A set of attribute is called an Entity .
➢ An entity has a set of properties, and the values for
some set of properties may uniquely identify an entity.
➢ For instance, a person may have a person-id property
whose value uniquely identifies that person.

6.2.1 Entity Sets
➢ An entity set is a set of entities of the same type that
share the same properties, or attributes.
➢ A set of entity is called Entity set.
➢ For example, the set of all persons who are customers
at a given bank, can be defined as the entity set
customer.
➢ Similarly, the entity set loan might represent the set of
all loans awarded by a particular bank.

6.2.2 Relationship Sets
➢ A relationship is an association among several entities.
For example, we can define a relationship that
associates customer Hayes with loan L-15.
➢ A relationship set is a set of relationships of the same
type.
➢ For example, Figure 6.2 shows the relationship set
borrower to denote the association between
customers and the loans that the customers have.

6.2.3 Attributes
➢ For each attribute, there is a set of permitted values,
called the domain, or value set, of that attribute.
➢ The domain of attribute customer-name might be the
set of all text strings of a certain length(Ex: customer-
name char(25))

6.2.3 Attributes
➢ An attribute, as used in the E-R model, can be
characterized by the following attribute types.
➢ Simple and composite attributes: An Attribute can
not be divided into subpart is called simple attribute.
An Attribute can be divided into subpart is called
composite attribute.
➢ Example for Simple attribute: Age.
➢ Example for composite attribute: name. An
attribute name consisting of firstname, middle-
initial, and last-name.

6.2.3 Attributes
➢ Single-valued and multivalued attributes: An
attribute has single value for a specific entity is called
single attribute.
➢ For ex, the loan-number attribute for a specific loan
entity refers to only one loan number.
➢ An attribute has multiple value for a specific entity is
called multi-valued attribute.
➢ For example an employee may have zero, one, or
several phone numbers.

6.2.3 Attributes
➢ Derived attribute: The value for this type of attribute
can be derived from the values of other related
attributes is called derived attribute.
➢ For example the age of the employee may be
calculated from date-of-birth and current date.
Age=current_date – date_of_birth
➢ An attribute takes a null value when an entity does not
have a value for it. The null value may indicate "not
applicable"

6.3 Constraints
An E-R enterprise schema may define certain constraints
to which the contents of a database must conform.

6.3.1 Mapping Cardinalities
Mapping cardinalities, or cardinality ratios, express the number
of entities to which another entity can be associated via a
relationship set.

➢ An E-R enterprise schema may define certain
constraints to which the contents of a database must
conform.
➢ For a binary relationship set R between entity sets A
and B, the mapping cardinality must be one of the
following:
➢ One-to-one: An entity in A is associated with at most
one entity in B, and an entity in B is associated with at
most one entity in A. (See Figure 6.5a.)
➢ one-to-many: An entity in A is associated with any
number (zero or more) of entities in B. An entity in B,

can be associated with at most one entity in A. (See
Figure 6.5b.)
➢ Many-to-one: An entity in A is associated with at
most one entity in B. An entity in B, however, can be
associated with any number (zero or more) of entities
in A. (See Figure 6.6a.)
➢ Many-to-many: An entity in A is associated with any
number (zero or more) of entities in B, and an entity in
B is associated with any number (zero or more) of
entities in A. (See Figure 6.6b.)

6.3.2 Keys
➢ The values of the attribute of an entity must be
uniquely identified.
➢ In other words, no two entities in an entity set are
allowed to have exactly the same value for all
attributes.

6.3.3 Participation Constraints
➢ The participation of an entity set E in a relationship set
R is said to be total if every entity in E participates in
at least one relationship in R.
➢ If only some entities in E participate in relationships in
R, the participation of entity set E in relationship R is
said to be partial.
➢ For example, we expect every loan entity to be related
to at least one customer through the borrower
relationship. Therefore the participation of loan in the
relationship set borrower is total.
➢ customer in the borrower relationship set is the partial.

6.3.3 Participation Constraints

6.4 Entity-Relationship Diagrams
➢ An E-R diagram can express the overall logical
structure of a database graphically.
➢ E-R diagrams are simple and clear.
➢ An ER diagram consists of the following major
components:
➢ Rectangles, which represent entity sets.
➢ Ellipses, which represent attributes.
➢ Diamonds, which represent relationship sets.

➢ Lines, which link attributes to entity sets and entity
sets to relationship sets.
➢ Double ellipses, which represent multivalued
attributes.
➢ Dashed ellipses, which denote derived attributes.
➢ Double lines, which indicate total participation of an
entity in a relationship set.
➢ Double rectangles, which represent weak entity sets.

An E-R diagram can express the overall logical structure
of a database graphically.
E-R diagrams are simple and clear.
An ER diagram consists of the following major
components:
Rectangles, which represent entity sets.
Ellipses, which represent attributes.
Diamonds, which represent relationship sets.

➢ Consider the entity-relationship diagram in Figure 6.7,
which consists of two entity sets, customer and loan,
related through a binary relationship set borrower.
➢ The attributes associated with customer are customer-
id ,customer-name, customer-street, and customer-city.
The attributes associated with loan are loan-number
and amount.
➢ The relationship set borrower may be many-to-many
(Fig. 6.7), one-to-many (Fig. 6.8 a) , many-to-one
(Fig. 6.8 b) , or one-to-one (Fig. 6.8 c).
➢ To distinguish among these types, we draw either a
directed line (→) or an undirected line ( ) between
the relationship set and the entity set.

Figure 6.7 shows many-many relationship

➢ In Figure 6.9, the access date attribute attached to the
relationship set depositor to specify the most recent
date on which a customer accessed that account.

Figure 6.11 shows the role indicators mannger and
worker between the employee entity set and the
works_for relationship set.

➢ Figure 6.12 consists of the three entity sets employee,
job, and branch, related through the relationship set
works-on.

➢ A double line from loan to borrower, as in Figure
6.13, indicates that each loan must have at least one
associated customer.

6.5 Entity-Relationship Design lssues
6.5.1 Use of Entity Sets versus Attributes
➢ Choice mainly depends on the structure of the
enterprise being modeled, and on the semantics
associated with the attribute in question.
➢ Consider the entity set employee with attributes
employee_id, employee-name and telephone-number.
➢ In the above structure the telephone number may be
zero or one or more than one.
➢ The alternative design may be The employee entity
set with attributes employee-id and employee_name.
➢ The telephone entity set with attributes
telephonenumber and location

6.5 Entity-Relationship Design lssues
6.5.1 Use of Entity Sets versus Attributes

6.5.2 Use of Entity Sets versus Relationship Sets
➢ Possible guideline is to designate a relationship set to
describe an action that occurs between entities.
➢ In Fig 6.16, Each loan is represented by a
relationship between a customer and a branch.
➢ If every loan is held by exactly one customer and is
associated with exactly one branch.
➢ With this design, we cannot represent conveniently a
situation in which several customers hold a loan
jointly.
➢ To handle such a situation, we must define a separate
relationship for each holder of the joint loan.

6.5.2 Use of Entity Sets versus Relationship Sets

6.5.3 Binary versus n-ary Relationship Sets
➢ Relationships in databases are often binary.
➢ it is always possible to replace a non-binary (n-ary, for
n > 2) relationship set by a number of distinct binary
relationship sets.
➢ For simplicity, consider the abstract ternary (n = 3)
relationship set R, relating entity sets A, B, and, c.
➢ we replace the relationship set R by an entity set E, and
create three relationship sets as shown in Figure6 .17:
➢ RA, relating E and A
➢ RB, relating E and B
➢ Rc, reiating E andC

6.5.3 Binary versus n-ary Relationship Sets

6.5.4 Placement of Relationship Attributes
➢ Can make access-date an attribute of account, instead
of a relationship attribute, if each account can have
only one customer
➢ That is, the relationship from account to customer is
many to one, or equivalently, customer to account is
one to many

6.6 Weak Entity Sets
➢ An entity set that does not has a primary key is
termed a weak entity set.
➢ An entity set that has a primary key is termed a
strong entity set.
➢ Sequence number is the payment number. payments
for different loans may share the same payment
number.
➢ For a weak entity set to be meaningful, it must be
associated with another entity set, called the
identifying or owner entity set.

6.7 Extended E-R Features
➢ Extended E-R features of specialization,
generalization, higher- and lower-level entity sets,
attribute inheritance and aggregation.

6.7.1 Specialization
➢ An entity set may include subgroupings of entities that
are distinct in some way from other entities in the set.
➢ As an example, consider an entity set person with
attributes person-id, name,street, and city. A person may
be further classified as customer and employee.
➢ Each of these person types is described by a set of
attributes that includes all the attributes of entity set
person plus possibly additional attributes.
➢ For example customer entrties may be described further
by an attribute creditrating, whereas employee entities
may be described further by the attribute salary.

6.7.2 Generalization
➢ Representation of more than one entity set with
common attribute is called generalization.
➢ There are similarities between the customer entity set
and the employee entity set.
➢ They have several attributes are common in the two
entity sets: namely, the identifier, name, street, and
city attributes.
➢ This commonality can be expressed by
generalization.

6.7.3 Attribute lnheritance
➢ The higher- and lower-level entities created by
specialization and generalization is attribute
inheritance. Figure 6.20 depicts a hierarchy of entity
sets.
➢ The attributes of the higher-level entity sets ire said
to be inherited by the lower-level entity sets.
➢ For example, customer and employee inherit the
attributes of person.
S.No. Higher Level Entity Set Lower Level Entity Set
1. Person Customer, Employee
2. Employee Officer, Teller, Secretary

Specialization & Generalization

6.7.4 Constraints on Generalizations
➢ The lower level entity set may be condition defined
or Disjoint.
➢ In condition defined, the condition may be defined
for the particular attribute.
➢ For example, The account entity set has the attribute
account_type and it contains the value either “saving”
or “Checking” account.
➢ In disjoint, An entity can satisfy only one condition.
➢ For example, The account entity set has the attribute
account_type and it contains the value either “saving”
or “Checking” account but can not be both.

6.7.4 Constraints on Generalizations
➢ The completeness constraint may be one of the
following.
➢ Total generalization or specialization: Each higher-
level entity set must belong to a lower-Ievel entity
set. [Ex: Employee has officer, teller and secretary]
➢ Partial generalization or specialization: Some
higher-level entity set may not belong to any lower-
level entity set. [Ex: Customer don’t have any lower
level entity set]

6.7.5 Aggregation
➢ One limitation of the E-R model is that it cannot
express the relationships among relationships.
➢ For example, the manager manages the employee
worked in various branches. We can not represent the
ER diagram like this [ Fig 6.12 & Fig. 6.21].
➢ Because it contains relationship redundancy.

6.7.5 Aggregation
➢ The above problem is solved by aggregation. The
Aggregation is an abstraction through which
relationships are treated as higher level entities.
➢ In Fig. 6.22, create a binary relationship manages
between works-on and manager to represent who
manages what tasks.

Lecture Notes Unit 1 chapter 6 E-R MODEL

More Related Content

What's hot

Similar to Lecture Notes Unit 1 chapter 6 E-R MODEL

More from Murugan146644

Recently uploaded

In this document

Lecture Notes Unit 1 chapter 6 E-R MODEL