Entity-Relationship Model

Data Model
A data model is a collection of conceptual tools for describing data,
data relationship, data semantics and consistency constraints.
Entity-Relationship Model: This is a higher-level data model. It is
based on a perception of a real world that consists of a collection of
basic objects, called entities and the relationship among these
objects.
Relational Model: This is a lower level model. It uses a collection
of tables to represent both data and relationships among those
data.
Designers often formulate database schema design by first
modeling data at a high level, using E-R model and then translating
it into the relational model.

Entity
An entity is a thing or object in the real world that is
distinguishable from all other objects. An entity has a set of
properties and the values for some set of properties may uniquely
identify an entity. An entity may be concrete, such as a person or a
book, or it may be abstract, such as loan, or a holiday, or a
concept.
Entity Set
An entity set is a set of entities of the same type that share the
same properties, or attributes.
Customer The set of all persons who are customers at a given
bank
Loan The set of all loans awarded by a particular bank

Attributes: An entity is represented by a set of attributes. Attributes

are descriptive properties possessed by each member of the entity
set. The designation of an attribute for an entity set expresses that
the database stores similar information concerning each entity in
the entity set; however, each entity may have its own value for
each attribute.
customer- customer-id, customer-name, customer-street,
customer-city
loan loan-number, amount
Domain or value set: For each attribute, there is set of permitted
values, called the domain or value set.
customer-name Set of all text strings of a certain length
loan-number Set of all strings of the form L-n, where n is a
positive integer
A database thus includes a collection of entity sets, each of which
contains any number of entities of same type.

Attribute Types:
Simple and Composite
Simple When an attribute is not possible to divided into subparts,
customer city, country
Composite Composite attributes can be divided into subparts i.e.
other attributes. Composite attributes help us to group together the
related attributes, making the modeling cleaner.
name first-name, middle-name, last-name
address street, city, state, zip-code (postal code)
street street-number, street-name, apartment-number
Single-valued and multi-valued
Single-valued when there exist a single value for a particular
entity, loan-number
Multi-valued When there exist a set of values for a specific
entity, phone-number, dependent-name of the employee entity set
Boundary can be assigned for a multi-valued attribute

Derived The value of this type of attribute can be derived from

the values of other related attributes or entities.
loans-held attribute in customer entity set - How many loans a
customer has from a bank
age attribute in customer entity set where there is a attribute
named date-of-birth. date-of-birth may be referred to as a base
attribute, or a stored attribute. The value of a derived attribute is not
stored, but is computed when required.
Null Value: An attribute can take a null value when an entity does
not have a value for it.
1. Not applicable middle name
2. Unknown a. missing the value does exist but we do not have
that information - name
b. not known do not know whether or not the value
actually exist
Common Example: apartment no.

Relationship
A relationship is an association among several entities
Relationship Set
A relationship set is a set of relationships of the same type.
Formally it is a mathematical relation on n>= 2 (possibly nondistinct) entity sets. If E1, E2, .., En are entity sets, then a
relationship set R is a subset of
{(e1, e2,., en) | e1 E1, e2 E3, ., en En }
Where (e1, e2, , en) is a relationship.
borrower association between customer and loan
loan-branch association between loan and branch
depositor association between customer and account
Participation: The association between entity sets is referred to as
participation, i.e. the entity sets E1, E2, ., En participate in
relationship set R.

Descriptive Attribute: A relationship may also have attributes

called descriptive attributes.
depositor : customer account, access-date (the most recent date
on which a customer accessed an account.

Degree of Relationship set: The number of entity set that

participate in the relationship set is called the degree of the
relationship set. A binary relationship is of degree 2; a ternary
relationship set is of degree 3.

Constraints
An E-R enterprise schema may define certain constraints to which
the contents of a database must conform. Two of the most
important constraints are:
A. Mapping Cardinalities or cardinality ratios
Mapping cardinalities express the number of entities to which
another entity can be associated via a relationship set. For a binary
relationship set R between entity sets A and B the mapping
cardinality must be one of the following:
1. One to one
2. One to many
3. Many to one
4. Many to many

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
One to many - An entity in A is associated with any number (zero or
more) entities in B. An entity in B, however, can be associated with
at most one entity in A

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) entities in A.
Many to many - An entity in A is associated with any number (zero
or more) entities in B and An entity in B can be associated with
any number (zero or more) entities in A.

B. 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.

Keys
The values of the attributes of an entity must be such that they can
uniquely identify the entity from the entity set. In other words, no
two entities in an entity set are allowed to have exactly the same
value for all attributes.
A key allows us to identify a set of attributes that suffice to
distinguish entities from each other. Keys also help uniquely
identify relationships, and thus distinguish relationships from each
other.

A. Entity Sets
1. Superkey A superkey is a set of one or more attributes that,
taken collectively, allow identifying uniquely an entity in the entity
set. A superkey may contain extraneous attributes.
customer {customer-id}, {customer-name, customer-id}, {all
attribute}
customer-name is not a superkey
2. Candidate Key The superkey for which no proper subset is a
superkey is a candidate key. So the minimul superkeys are called
is candidate keys.
It is possible that several distinct sets of attributes could serve as a
candidate key.
{customer-name, customer-street}, {customer-id}
{customer-id, customer-name} is not a candidate key because
customer-id itself is a super key/candidate key.

3. Primary Key The primary key is to denote a candidate key that

is chosen by the database designer as the principal means of
identifying entities within the entity set.
A key (primary, candidate and super) is the property of the entity
set, rather than of the individual entities.
So, Primary key Candidate Key Super key
B. Relationship Sets
Superkey
Let R be a relationship set involving entity sets E1, E2, .., En. Let
Primary Key (Ei ) denote the set of attributes that forms the primary
key for entity set Ei. Assume for now that the attribute names of all
the primary keys are unique, and each entity set participates only
ones in the relationship. The composition of the primary key for a
relationship set depends on the set of attributes associated with the
relationship set R.

i) If the relationship set R has no attributes associated with

it (descriptive attribute/s), then the set of attributes
Primary Key (E1 ) U Primary Key (E2 ) U..U Primary Key
(En )
describes an individual relationship in set R.
ii) If the relationship set R has attributes a1, a2, , am
associated with it, then the set of attributes
Primary Key (Ei ) U Primary Key (E2 ) U..U Primary Key
(En ) U { a1, a2, , am }
describes an individual relationship in set R.
iii) In both the above cases, the set of attributes
Primary Key (Ei ) U Primary Key (E2 ) U..U Primary Key
(En )
forms the superkey for the relationship set.

Primary Key: The structure of the primary key for the relationship
set depends on the mapping cardinalities of the relationship set.
Depositor customer and account with attribute access-date
1. many to many the primary key of depositor consists of the
union of the primary keys of customer and account
2. many to one from customer to account - the primary key of
depositor is simply the primary key of customer (many sided)
3. one to many from customer to account - the primary key of
depositor is simply the primary key of account (many sided)
4. one to one from customer to account - the primary key of
depositor is either of the entity set (customer or account)

Weak Entity Sets and Strong Entity Sets

Strong Entity Set: An entity set that has a primary key is termed
as strong entity set.
Weak Entity Set: An entity set may not have sufficient attributes to
form a primary key. Such an entity set is termed as weak entity set.
Payment = (payment-number, payment-date, payment-amount)
Identifying or Owner entity set: For a weak entity set to be
meaningful, it must be associated with another entity set, called the
Identifying or Owner entity set
Every weak entity must be associated with an identifying entity, i.e.,
the weak entity set is said to be existence dependent on
identifying entity set.
The identifying entity set is said to own the weak entity set that it
identifies.

Identifying Relationship: The relationship associating the weak

entity set with the identifying entity set is called the identifying
relationship.
The identifying relationship is one to many from the identifying
entity set to weak entity set and the participation of weak entity set
in the relationship is total.
Discriminator: The discriminator in the weak entity set is a set of
attributes that distinguish entities in the weak entity set that depend
on one particular strong entity. This is also called the partial key of
the entity set.
Payment no. of weak entity set payment is the discriminator
The primary key of the identifying entity set plus the discriminator of
the weak entity set forms the primary key of a weak entity set.
{loan no., payment no.} is the primary key of weak entity set
payment where loan no. is the primary key of the identifying entity
set loan

The identifying relationship set should have no descriptive

attributes, since any required attributes can be associated with the
weak entity set.
1. A weak entity set can participate in relationships other than the
identifying relationship.
2. A weak entity set may participate as owner in an identifying
relationship with another weak entity set.
3. It is possible to have a weak entity set with more than one
identifying entity set. The primary key of the weak entity set would
consist of the union of the primary keys of the identifying entity sets
plus the discriminator of the weak entity set.

Entity-Relationship Diagram:
The E-R diagram can express the overall logical structure of a
database graphically. Such a diagram consists of the following
major components:
1. Rectangles, which represent entity sets
2. Ellipses, which represent attributes
3. Diamonds, which represent relationship sets
4. Lines, which link attributes to entity sets and entity sets to
relationship sets
5. Double ellipses, which represent multivalued attributes
6. Dashed ellipses, which denote derived attributes
7. Double lines, which indicate total participation of an entity in a
relationship set
8. Double rectangles, which represent weak entity set
9. Double diamond, identifying relationship set for weak entity set
Note: See symbols used in E-R notation (Figure 2.20)

Design Issues
1. Use of Entity Sets Vs Attributes
- What constitutes an attribute and what constitutes an entity set?
2. Use of Entity Sets Vs Relationship Sets
3. Binary Vs n-ary Relationship Sets
4. Placement of Relationship Attributes
a) Attributes of a one to many relationship set can be repositioned
to only the entity set on the many side of the relationship
b) For one to one relationship sets, the relationship attribute can be
associated with either one of the participating entity sets.
c) When an attribute is determined by the combination on
participating entity sets, rather than by either entity separately, that
attribute must be associated with the many to many relationship
set.

2.9 Reduction of an E-R Schema to Tables

Primary keys allow entity sets and relationship sets to be
expressed uniformly as tables which represent the contents of the
database.
A database which conforms to an E-R diagram can be represented
by a collection of tables.
For each entity set and relationship set there is a unique table
which is assigned the name of the corresponding entity set or
relationship set.
Each table has a number of columns (generally corresponding to
attributes), which have unique names.
Converting an E-R diagram to a table format is the basis for
deriving a relational database design from an E-R diagram.

Tabular Representation of Strong Entity Sets

Let E be a strong entity set with descriptive attributes a1, a2,.,an.
We represent this entity by a table called E with n distinct columns,
each of which corresponds to one of the attributes of E. Each row
in this table corresponds to one entity of the entity set E.
Example:
loan: loan-number, amount
customer: customer-id, customer-name, customer-street,
customer-city

Tabular Representation of Weak Entity Sets

Let A be a weak entity set with attributes a1, a2,.,am. Let B be a
strong set on which A depends. Let the primary key of the B
consists of b1, b2,.,bn. We represent the entity set A by a table
called A for each attribute of the set:
{a1, a2,.,am } U { b1, b2,.,bn }
Example:
payment: loan-number, payment-number, payment-date, paymentamount

Tabular Representation of Relationship Sets

Let R be a relationship set, let a1, a2,.,am be the set of attributes
formed by the union of the primary keys of each of the entity set
participating in R, and let the descriptive attributes (if any) of R be
b1, b2,.,bn .We represent the relationship set R by a table called
R for each attribute of the set:
{a1, a2,.,am } U { b1, b2,.,bn }
Example:
Entity set loan: loan-number, amount
Entity set customer: customer-id, customer-name, customerstreet, customer-city
Relationship set borrower: customer-id, loan-no

Redundancy of Tables
1. A relationship set linking a weak entity set to the corresponding
strong entity set is many to one relationship set and has no
descriptive attributes.
2. The primary key of a weak entity set includes the primary key of
strong entity set.

Example:
Strong Entity set loan: loan-number, amount
Weak Entity set payment: loan-number, payment-number,
payment-date, payment-amount
Identifying Relationship set loan-payment: loan-number, paymentno
So loan-payment table is redundant. In general, the table for the
relationship set linking a weak entity set to its corresponding strong
entity set is redundant.
Combination of Tables
If there are two entity sets A and B and there exist relationship set
R between them, 3 tables A, B, R can be generated using table
construction scheme.
1. one to one relationship from A to B - the primary key of R is
either of the entity set (A or B)

2. one to many from A to B - the primary key of R is simply the

primary key of B
These can be combined into 2 tables: A, BR
3. many to one from A to B - the primary key of R is simply the
primary key of A
These can be combined into 2 tables: AR, B
4. many to many the primary key of R consists of the union of the
primary keys of A and B
There is no other alternative but to keep all the 3 tables.
For all the above cases there should be total participation of the
entity sets in the relationship set. Combination of tables works
nicely in case of total participation. If there exists partial
participation and we combine the tables there will be null values for
some entities those do not participate in relationship.

Composite Attributes
Composite attributes are handled by creating a separate attribute
for each of the component attribute and there should not be a
separate column for the composite attribute itself.
Entity set customer: customer-id, name having composite attribute
name with component attributes first-name, middle-initial, lastname
Table customer : customer-id, first-name, middle-name, last-name

Multivalued Attributes
For a multivalued attribute M, we create a table T with a column C
that corresponds to M and columns corresponding to primary key
of the entity set or relationship set of which M is an attribute.
Entity set employee: employee-id, employee-name, dependentname
Table employee: employee-id, employee-name
Table dependent-name: employee-id, dname
Entity set customer: customer-id, date-of-birth, phone-no.
Table customer: customer-id, date-of-birth
Table cust-phone: customer-id, phone-no.

Extended E-R Features

1. Specialization
2. Generalization
3. Attribute Inheritance
4. Aggregation
Specialization: An entity set may include sub-grouping of entities
that are distinct some way from other entities of the entity set. The
process of designating sub-grouping within an entity set is called
specialization.
person = {name, street, city}
customer = {name, street, city, customer-id}
employee = { name, street, city, employee-id, salary}
account = {account-no., balance}
savings-account ={ account-no., balance, interest rate}
checking-account ={ account-no., balance, overdraft-amount}
Higher and lower level entity set or Super class and subclass

Generalization
The refinement of initial entity set into successive levels of entity
sub-groupings represents a top-down design process in which
distinctions are made explicit.
The design process may also proceed in a bottom-up manner, in
which multiple entity sets are synthesized into a higher level entity
set on the basis of common features. This commonality can be
expressed by generalization. Generalization is used to emphasize
the similarities among the lower level entity sets and to hide the
differences; it also permits an economy of representation in that
shared attributes are not repeated.
customer = {name, street, city, customer-id}
employee = { name, street, city, employee-id, salary}
person = {name, street, city}
savings-account ={ account-no., balance, interest rate}
checking-account ={ account-no., balance, overdraft-amount}
account = {account no., balance}

Constraints on Generalizations/Specialization
A. Type1: Constraint on which entities can be members of a given
lower-level entity set.
1. Condition-defined: In condition-defined lower-level entity sets,
membership is defined on the basis of whether or not an entity satisfies
an explicit condition or predicate. It is also called attribute-defined
generalization.
Example: Saving account and Checking account
2. User-defined: Used-defined lower-level entity sets are not
constrained by a membership condition; rather, the database user
assigns to a given entity set.
Example: Employee and Team
B. Type2: Constraint on whether or not entities may belong to more than
one lower-level entity set within a single generalization.

1. Disjoint: A disjointness constraint requires that an entity belong to

no more than one lower-level entity set.
Example: Saving account and Checking account
2. Overlapping: In overlapping generalizations, the same entity may
belong to more than one lower-level entity sets within a single
generalization.
Example: Employee and Team
C. Completeness constraint: specifies whether or not an entity in
the higher-level entity set must belong to at least one of the lowerlevel entity sets within the generalization/ specialization.
1. Total generalization or specialization: Each higher-level entity
must belong to a lower-level entity set.
Example: Saving account and Checking account
2. Partial generalization or specialization: Some higher-level
entities may not belong to any lower-level entity set.
Example: Employee and Team