Introduction to E-R Model

Chapter 4
(Week 8,9 &10)
 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.
 Keys

 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
 Keys
 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.
 Keys

 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
 Keys

 In Branch-schema – {branch-name},
{branch-name, branch-city}, {all attribute}
are all superkeys. {branch-name, branch-
city} is not a candidate key, because
{branch-name} is a subset of {branch-
name, branch-city} and {branch-name}
itself is a superkey.
 However, {branch-name} is a candidate
key and also a primary key for our
purpose. {branch-city} is not a superkey,
since two branches in the same city may
have different names
 Keys

 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.
 Keys
 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.
 Keys

 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.
 Keys

 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.
 Keys

 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.
 Keys
 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)
 Keys

 Foreign key: In the context of relational

databases, a foreign key is a field (or
collection of fields) in one table that
uniquely identifies a row of another table
or the same table. In simpler words, the
foreign key is defined in a second table,
but it refers to the primary key in the first
table.
 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)
 Weak Entity Sets and Strong
Entity Sets
 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.
Weak Entity Sets and Strong
Entity Sets

 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.
Weak Entity Sets and Strong
Entity Sets

 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
Weak Entity Sets and Strong
Entity Sets

 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
Weak Entity Set
Weak Entity Sets and Strong
Entity Sets
 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.
 Weak Entity Sets and Strong
Entity Sets
 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
 Entity-Relationship Diagram
 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
 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
 Design Issues
 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.
 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.
 Reduction of an E-R Schema
to 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, payment-amount
 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 }
 Tabular Representation of
Relationship Sets
 Example:
Entity set loan: loan-number, amount
Entity set customer: customer-id,
customer-name, customer-street,
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.
 Redundancy of Tables
 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, payment-no
 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)
 These can be combined into 2 tables: AR, B
or A, BR
 Combination of Tables
 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
 Combination of Tables

 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, last-name
 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, dependent-name
 Multivalued Attributes

 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.
 Extended E-R Features
 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}
 Extended E-R Features
 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.

 Extended E-R Features
 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

 Constraints on
Generalizations/Specialization

 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.
 Constraints on
Generalizations/Specialization
 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

 Constraints on
Generalizations/Specialization
 C. Completeness constraint: specifies whether or
not an entity in the higher-level entity set must
belong to at least one of the lower-level 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
 Constraints on
Generalizations/Specialization

 2. Partial generalization or
specialization: Some higher-level
entities may not belong to any lower-
level entity set.
 Example: Employee and Team
 Abstraction

 Physical level describes how a record

(e.g., account) is stored (in a file (e.g.,
account.txt).
 Logical level: describes data stored in
database, and the relationships among
the data (database schema).
create table account (account-
number char(10), balance integer)
 Abstraction

 Database schema is used to specify

queries:
 Find the balance of the account with
account-number ‘131-01’
select account.balance
from account
where account.account-number =
‘131-01’
 Abstraction

 View level: application programs hide

details of data types. Views can also
hide information (e.g., balance) for
security purposes.
 Schema Diagram

 A database schema, along with primary

key and foreign key dependencies, can be
depicted pictorially by schema diagram.
 Each relation appears as a box, with the
attributes listed inside it and the relation
name above it.
 If there are primary key attributes, a
horizontal line crosses the box, with
primary key attributes listed above the line.
 Schema Diagram

 Foreign key dependencies appear as

arrows from the foreign key attributes
of the referencing relation to the
primary key of the referenced relation.
 E-R diagrams do not show foreign key
attributes explicitly, whereas schema
diagrams show them explicitly.
Schema Diagram
Thank
You