LEC-3: Entity-Relationship Model

1. Data Model: Collection of conceptual tools for describing data, data relationships, data semantics, and consistency
constraints.
2. ER Model
1. It is a high level data model based on a perception of a real world that consists of a collection of basic objects, called
entities and of relationships among these objects.
2. Graphical representation of ER Model is ER diagram, which acts as a blueprint of DB.
3. Entity: An Entity is a “thing” or “object” in the real world that is distinguishable from all other objects.
1. It has physical existence.
2. Each student in a college is an entity.
3. Entity can be uniquely identified. (By a primary attribute, aka Primary Key)
4. Strong Entity: Can be uniquely identified.
5. Weak Entity: Can’t be uniquely identified., depends on some other strong entity.
1. It doesn’t have sufficient attributes, to select a uniquely identifiable attribute.
2. Loan -> Strong Entity, Payment -> Weak, as instalments are sequential number counter can be generated

p
separate for each loan.
3. Weak entity depends on strong entity for existence.
4. Entity set

el
1. It is a set of entities of the same type that share the same properties, or attributes.
2. E.g., Student is an entity set.
3. E.g., Customer of a bank
5. Attributes
eH
1. An entity is represented by a set of attributes.
2. Each entity has a value for each of its attributes.
3. For each attribute, there is a set of permitted values, called the domain, or value set, of that attribute.
4. E.g., Student Entity has following attributes
A. Student_ID
B. Name
C. Standard
D. Course
od

E. Batch
F. Contact number
G. Address
5. Types of Attributes
1. Simple
1. Attributes which can’t be divided further.
C

2. E.g., Customer’s account number in a bank, Student’s Roll number etc.

2. Composite
1. Can be divided into subparts (that is, other attributes).
2. E.g., Name of a person, can be divided into first-name, middle-name, last-name.
3. If user wants to refer to an entire attribute or to only a component of the attribute.
4. Address can also be divided, street, city, state, PIN code.
3. Single-valued
1. Only one value attribute.
2. e.g., Student ID, loan-number for a loan.
4. Multi-valued
1. Attribute having more than one value.
2. e.g., phone-number, nominee-name on some insurance, dependent-name etc.
3. Limit constraint may be applied, upper or lower limits.
5. Derived
1. Value of this type of attribute can be derived from the value of other related attributes.
 2. e.g., Age, loan-age, membership-period etc.
6. NULL Value
1. An attribute takes a null value when an entity does not have a value for it.
2. It may indicate “not applicable”, value doesn’t exist. e.g., person having no middle-name
3. It may indicate “unknown”.
1. Unknown can indicate missing entry, e.g., name value of a customer is NULL, means it is missing as name
must have some value.
2. Not known, salary attribute value of an employee is null, means it is not known yet.
6. Relationships
1. Association among two or more entities.
2. e.g., Person has vehicle, Parent has Child, Customer borrow loan etc.
3. Strong Relationship, between two independent entities.
4. Weak Relationship, between weak entity and its owner/strong entity.
1. e.g., Loan <instalment-payments> Payment.
5. Degree of Relationship
1. Number of entities participating in a relationship.

p
2. Unary, Only one entity participates. e.g., Employee manages employee.
3. Binary, two entities participates. e.g., Student takes Course.
4. Ternary relationship, three entities participates. E.g, Employee works-on branch, employee works-on job.

el
5. Binary are common.
7. Relationships Constraints
1. Mapping Cardinality / Cardinality Ratio
1. Number of entities to which another entity can be associated via a relationship.
eH
2. One to one, Entity in A associates with at most one entity in B, where A & B are entity sets. And an entity
of B is associated with at most one entity of A.
1. E.g., Citizen has Aadhar Card.
3. One to many, Entity in A associated with N entity in B. While entity in B is associated with at most one
entity in A.
1. e.g., Citizen has Vehicle.
4. Many to one, Entity in A associated with at most one entity in B. While entity in B can be associated with
N entity in A.
od

1. e.g., Course taken by Professor.

5. Many to many, Entity in A associated with N entity in B. While entity in B also associated with N entity in
A.
1. Customer buys product.
2. Student attend course.
2. Participation Constraints
C

1. Aka, Minimum cardinality constraint.

2. Types, Partial & Total Participation.
3. Partial Participation, not all entities are involved in the relationship instance.
4. Total Participation, each entity must be involved in at least one relationship instance.
5. e.g., Customer borrow loan, loan has total participation as it can’t exist without customer entity. And
customer has partial participation.
6. Weak entity has total participation constraint, but strong may not have total.
8. ER Notations
C
od
eH
el
p
 LEC-4: Extended ER Features

1. Basic ER Features studied in the LEC-3, can be used to model most DB features but when complexity increases, it is
better to use some Extended ER features to model the DB Schema.
2. Specialisation
1. In ER model, we may require to subgroup an entity set into other entity sets that are distinct in some way with other
entity sets.
2. Specialisation is splitting up the entity set into further sub entity sets on the basis of their functionalities,
specialities and features.
3. It is a Top-Down approach.
4. e.g., Person entity set can be divided into customer, student, employee. Person is superclass and other specialised
entity sets are subclasses.
1. We have “is-a” relationship between superclass and subclass.
2. Depicted by triangle component.
5. Why Specialisation?
1. Certain attributes may only be applicable to a few entities of

p
the parent entity set.
2. DB designer can show the distinctive features of the sub entities.
3. To group such entities we apply Specialisation, to overall refine the DB blueprint.

el
3. Generalisation
1. It is just a reverse of Specialisation.
2. DB Designer, may encounter certain properties of two entities are overlapping. Designer may consider to make a
new generalised entity set. That generalised entity set will be a super class.
eH
3. “is-a” relationship is present between subclass and super class.
4. e.g., Car, Jeep and Bus all have some common attributes, to avoid data repetition for the common attributes. DB
designer may consider to Generalise to a new entity set “Vehicle”.
5. It is a Bottom-up approach.
6. Why Generalisation?
1. Makes DB more refined and simpler.
2. Common attributes are not repeated.
4. Attribute Inheritance
od

1. Both Specialisation and Generalisation, has attribute inheritance.

2. The attributes of higher level entity sets are inherited by lower level entity sets.
3. E.g., Customer & Employee inherit the attributes of Person.
5. Participation Inheritance
1. If a parent entity set participates in a relationship then its child entity sets will also participate in that relationship.
6. Aggregation
C

1. How to show relationships among relationships? - Aggregation is the technique.

2. Abstraction is applied to treat relationships as higher-level entities. We can call it Abstract entity.
3. Avoid redundancy by aggregating relationship as an entity set itself.
 LEC-8: Transform - ER Model to Relational Model

1. Both ER-Model and Relational Model are abstract logical representation of real world enterprises. Because the two
models implies the similar design principles, we can convert ER design into Relational design.
2. Converting a DB representation from an ER diagram to a table format is the way we arrive at Relational DB-design from
an ER diagram.
3. ER diagram notations to relations:
1. Strong Entity
1. Becomes an individual table with entity name, attributes becomes columns of the relation.
2. Entity’s Primary Key (PK) is used as Relation’s PK.
3. FK are added to establish relationships with other relations.
2. Weak Entity
1. A table is formed with all the attributes of the entity.
2. PK of its corresponding Strong Entity will be added as FK.
3. PK of the relation will be a composite PK, {FK + Partial discriminator Key}.
3. Single Values Attributes

p
1. Represented as columns directly in the tables/relations.
4. Composite Attributes
1. Handled by creating a separate attribute itself in the original relation for each composite attribute.

el
2. e.g., Address: {street-name, house-no}, is a composite attribute in customer relation, we add address-street-
name & address-house-name as new columns in the attribute and ignore “address” as an attribute.
5. Multivalued Attributes
1. New tables (named as original attribute name) are created for each multivalued attribute.
eH
2. PK of the entity is used as column FK in the new table.
3. Multivalued attribute’s similar name is added as a column to define multiple values.
4. PK of the new table would be {FK + multivalued name}.
5. e.g., For Strong entity Employee, dependent-name is a multivalued attribute.
1. New table named dependent-name will be formed with columns emp-id, and dname.
2. PK: {emp-id, name}
3. FK: {emp-id}
6. Derived Attributes: Not considered in the tables.
od

7. Generalisation
1. Method-1: Create a table for the higher level entity set. For each lower-level entity set, create a table that
includes a column for each of the attributes of that entity set plus a column for each attribute of the primary key
of the higher-level entity set.
For e.g., Banking System generalisation of Account - saving & current.
1. Table 1: account (account-number, balance)
C

2. Table 2: savings-account (account-number, interest-rate, daily-withdrawal-limit)

3. Table 3: current-account (account-number, overdraft-amount, per-transaction-charges)
2. Method-2: An alternative representation is possible, if the generalisation is disjoint and complete—that is, if no
entity is a member of two lower-level entity sets directly below a higher-level entity set, and if every entity in
the higher level entity set is also a member of one of the lower-level entity sets. Here, do not create a table for
the higher-level entity set. Instead, for each lower-level entity set, create a table that includes a column for each
of the attributes of that entity set plus a column for each attribute of the higher-level entity sets.
Tables would be:
1. Table 1: savings-account (account-number, balance, interest-rate, daily-withdrawal-limit)
2. Table 2: current-account (account-number, balance, overdraft-amount, per-transaction-charges)
3. Drawbacks of Method-2: If the second method were used for an overlapping generalisation, some values such
as balance would be stored twice unnecessarily. Similarly, if the generalisation were not complete—that is, if
some accounts were neither savings nor current accounts—then such accounts could not be represented with
the second method.
8. Aggregation
1. Table of the relationship set is made.
2. Attributes includes primary keys of entity set and aggregation set’s entities.
3. Also, add descriptive attribute if any on the relationship.

p
el
eH
od
C
Lec-8-X-TrasfomatmfmERM.IE del .

]
loan → Loan - numb amount

weak Entity payment

_

/ /
payment
-
date
payment
-
amount

¥
 attribute
*
Comport attribute → sep . for each component .

Customers le

| / statehood / /
customer - name address at - add -
-

pincode add streetno

-

/
add streetname
-

* Multi value
- attribute

F-t-E-m.nu relative .

↑
]
emp-idfdname-fenp-id.ae
name

↓
Rk . .
☒
Generated -

method I
=

*
Aggregation
= -
-
-
-
-
-
-
-
-
-

,
,

I '

iemf-AE-lbm.TT
"

i
' - -
-

Entity
- -

1¥
- - - - - -

work
-

- on .

/managef
(
Table
m-gr-id-P-id-b-E-ig.pk
'

manages
,
 Unary
.RU#vship:rE..T--:.
*

we will add another attribute in

Employee table .

Urich will be F. K .

Emp
201
-
id
( name

- -
-

/ joining
-
-
date
-

/ Snp
205
_

mgr _
id

\
- - 205
202
- -
-

205
- - - 1 -
-
- , Null .

mi• 1Peno
* I :| →

Person / )
id
- ,
Name
, sponged
SFK}
 *
M →
com!
④ Come ( id > Title ic◦mf-
M\prere
"

prerealid-E-idt-p.gg
②

4¥11 ↓
LED
 * FB Relational Model

(1) User _
profile ( username ,
name -

first ,
name - last,
password ,
DOB )
(2) her -

profile -
email ( username SEK ] ,
email )

(3) user -

profile -
contact ( m#kÉÉr)
(4) friendship ( profile -
,
_
req # k3 profile accept# k3)
_
→ compound key

(5) post -
like t.p-st.li#id timestamp , ,
post id # k }
-

,
username { f. k3)

(6) user -

post / Post_id_ ,
created -

timestamp ,
modified timestamp
-

,
tent content
-

,
username
)
{ f. K ]
(7) user -

post image (
-

po_tidÉnage± )
(8) her -

post -
video ( _
po-t-idt.ES/video--ur )
(9) post - comment ( po_st--id, text content
-

, timestamp , post id -
username )
,

{ 8.1<3 [Jk)
Figure 12.23 shows a secondary hash index
on the account file, for the search key account-number. The hash function in the figure
computes the sum of the digits of the account number modulo 7. The hash index has
seven buckets, each of size 2 (realistic indices would, of course, have much larger bucket sizes).
One of the buckets has three keys mapped to it, so it has an overflow
bucket. In this example, account-number is a primary key for account,soeachsearch
key has only one associated pointer. In general, multiple pointers can be associated
with each key.