Unit-II

Entiff Relationships

2.1 History of Database Systems

L. 1968 File-Based : It is predecessor of database systems. In this data is
maintained in a flat file. Processing characteristics are determined by comrnon
use of magnetic tape medium.
o Data are stored in files with interface between programs and files. Mapping
happens between logical files and physical file, one file corresponds to one or
several programs
o Various access methods exits, e.g. Sequential, indexed, random
. Requires extensive programming in third-generation language such as
COBOL, BASIC.
o Limitations :

o Separation and isolation : Each program maintains its own set of data,
users of one program may not aware of holding or blocking by other
Programs.
o Duplication : Same data is held by different programs, thus, wastes
space and resources.
o High maintenance costs such as ensuing data consistency and controlling
access.

o Sharing granularity is very coarse.

o Weak security.
2. 1968-1980 Era of non-relational database : A database provides integrated and
structured collection of stored operational data which can be used or shared by
application systems. Prominent hierarchical database model was IBM's first
DBMS called IMS. Prominent network database model was CODASYL DBTG
model; IDMS was the most popular network DBMS.

(2-11
 - ,/-'

Database Management Systems 2-2 Entity Relationships

Hierarchical data model

o In Mid 1960s Rockwell partner with IBM created information Management
System (IMS). IMS DB /DC lead the mainframe database market in 70's and
early 80's.
o It is based on binary trees. It is logically represented by an upside down
tree, one-to many relationship between parent and child records.
o Advantages are : Efficient searching; Less redundant data; Data
independence; Database security and integrlty
o Disadvantages :

o Compleximplementation
o Difficult to manage and lack of standards, such as problem to add
empty nodes and can't easily handle many-many relationships.
o Lacks structural independence, such add up application programming
and use complexity.

Network data model

. Early 1960s, Charles Bachmann developed first DBMS at Honeywell,
Lrtegrated Data Store ( IDS)
o It in 1971 by the
standardized CODASYL group (Conference on Data
Systems Languages) -,

. It uses directed acyclic graph with nodes and edges

. Each record can have multiple parents :

o Composed of sets relationsHpr, a set represents a one to many

relationship between the owner and the member.
o Each set has owner record and member record.
o Member may have several owners.
o Main problems : System complexity and difficult to design and maintairu
Lack of structural independence.
The distinction of storing data in files and databases is that databases are intended
to be used by muftiple programs and types of users.
3. \97O-ptesent Era of relational database and database management system
(DBMS) : Based on relational calculus, shared collection of logically related
data and a description of this data, designed to meet the information needs
of an organization; System catalog/metadata provides description of data to
enable program-data independence; logically related data comprises entities,
attributes, and relationshipr of an orgarization's information. Data abstraction

)
I

L I
 Database Management Systems 2-3 Entity Relationships

allows view level, a way of presenting data to a group of users and logical
level, how data is understood to be when writing queries.
1970 : Ted Codd at IBM's San Jose Lab proposed relational models.

Two major projects start and both were operational in late 1970s.
o INGRES at University of California, Berkeley became commercial and
followed up POSTGRES which was incorporated into Informix.
o System R at IBM san Jose Lab, later evolved into DB2, which became
one of the first DBMS product based on the relational model. (Oracle
produced a similar product just prior to DB2.)
1976 : Peter Chen defined the Entity-reiationship(ER) model.
1980s : Maturation of the relational database technology, more relational
based DBMS were developed and SQL standard adopted by ISO and ANSI.
: Object-oriented DBMS (OODBMS) develops. Little success
1985
conunercially because advantages did not justify the cost of converting
billions of bytes of data to new format.
1990s : Incorporation of object-orientation in relational DBMSs, new
application areas, such as data warehousing and OLAP, web and Internet,
Interest in text and multimedia, enterprise resource planning (ERP) and
management resource planning (MRP)
o 1991, : Microsoft ships access, a personal DBMS created as element of
Windows gradually supplanted all other personal DBMS products.
r) 1995 : First Internet database applications
o 7997 : XML applied to database processing, which solves long-standing
database problems. Major vendors begin to integrate XML into DBMS
products.

2.2 Database Design and ER Diagrams

The entity-relationship (ER) data model allows us to describe the data in a
real-world enterprise in terms of entities and their relationshipr and is widely used to
develop an initial database design. The ER model is important primarily for its role in
database design. It provides useful concepts that allow us to move from an informal
I description of what users want from their database to a more detailed and precise,
I description that can be implemented in a DBMS.
S

)
]S,
)n
Database Management Systems 2-4 Entity Relationships Iletab€

2,2.1 Overview of Database Design

The six steps of database design are given below. The ER model is most relevant
to first three steps:
1-. Requirements Analysis : The first step in designing a database application is 23El
to understand what data is to be stored in the database, what applications
must be built on top of it, and what operations are performed on it. The 23.1
purpose of this step is to produce a description of the users' requirements. O

2. Conceptual Database Design : The information gathered in the requirements

analysis step is used to develop a high-level description of the data to be
stored in the database, along with the constraints over the data. This step
creates a conceptual schema for the database using a high level conceptual
data model. The conceptual schema is a concise description of the data
requirements of the users and includes detailed descriptions of entity types,
relationship types, and constraints. This step is often carried out using the ER
model, or a similar high-level data model.
3. Logical Database Design : Purpose of this step is to transform the conceptual
schema (which is at a high/ abstract level) into a (lower-level) representational
/ implementational model supported by whatever DBMS is to be used. This Fc
step is also called data model mapping.
t

2.2.2 Beyond ER Design I

I

ER modeling is sometimes considered as a complete approach for designing a I

logical database schema. This is incorrect as the ER diagram is just an approximate

description of the data, constructed using the inJormation collected during
requirements analysis. A more careful analysis can often refine the logical schema
obtained at the end of Step 3. Once we have a good logical schema, we must consider
performance criteria and design the physical schema. Finally, we must address
security issues and ensure that users are able to access the data they need, but not
data that we wish to hide from them. The remaining three steps of database design
are described below:
l-. Schema Refinement : The purpose of this step is to analyze t}ire collection of
relations in our relational database schema to identify potential problems, and
to refine it.
2. Physical Design : Purpose of this step is to decide upon the internal storage
structures, access paths (indexes), etc., that will be used in realizing the
representational model produced in previous phase.
3. Security Design : In this step, different user groups and different roles played
by various users (".g., the development team for a product, the customer
support representatives, the product manager) are identified. For each role and
user group, the parts of the database that they must be able to access and the

- | l- ,
 llatabase Management Systems 2-5 Entity Relationships

parts of the database that they should not be allowed to access are identified.
Steps are taken to ensure that they can access only the necessary parts.

is 2.3 Entities, Attributes and Entity Sets

1S

le 2.3.1 Entities and Entity Sets

. An entity is 'thing' or 'object' in the real world that is distinguishable from
:S all other objects. For example, each person in an enterprise is an entity. An
e entity has a set of properties, and the values for some set of properties may
p uniquely identify an entity. For instance, a Customer with Customer id
rI property with value C101 uniquely identifies that person.
a
)l
o An entity may be concrete, such as person or a book, or it may be abstract,
R
such as a loan, or a holiday.
o An entity set is a set of entities of the same type that share the same
rl properties, or attributes. The set of all customers at a given bank can be
rl defined as the entity set Customer.
.S
Following Fig. 2.L shows two entity sets :
i) Customer, with properties Customer_id, Customer_name, City.
ii) Account with properties Account no and Balance.
a
Customer id Customer name City
e
g c101 Hari Bombay

a c102 Ram Pune

r
c104 John Nashik
s
,t c303 Jm Solapur
n Customer

,t Account no Balance
t F.121 1000

4305 2000
e
p|417 500
e

4519 3000
t Account
r
I
e
Fig. 2.1 Entity sets Customer and Account
 Database Management Systems 2-6 Entity Relationships

2.3.2 Attributes
o An entity is represented by a set of attributes. Attributes are descriptive
--r properties possessed by each member of an entity set.
. The attributes of Customer entitty set are Custometid, Customer-name, and
City possible athibutes of the Account entity set are Account-no, and
Balance.
. Each entity has a value for each of its attributes. For instance, a particular
Customer entity may have the value 'C101' for attribute Custometid, 'Hari'
for Customer-name, and 'Bombay' for City.
o For each athibute, there is set of permitted values, called the domain, or
value set of that attribute. The domain of athibute Customer-name might be
set of all text strings of a certain length.

Types of attributes
Attributes are classified as :
. Simple
. Composite
. Single-valued
. Multi-valued
. Derived
i) Simple attribute : A simple attribute is an attribute composed of a single
component with an independent existence. Simple attributes can not be further
subdivided. Examples of simple attributes include Roll-No, Salary etc.
ii) Composite attribute : An attribute composed of multiple components each
with an independent existence is called a composite attribute.
. Examples of composite attributes are :

t) Name, which is composed of athibutes like first name, middte name and
last name.
2) Address, which is composed of other components like Street, City, Pincode.
iii) Single-valued attributes z A single-aalued attribute is one that holds a single
value for a single entity. Examples are Room-no, Customer]d. Single-valued
attributes are also called as atomic attributes.
iv) Multivalued attributes : A multiaalued attribute is one that holds multiple
values for a single entity. For example, a student entity can have multiple
values for the Hobby attribute such as reading, music, painting.

F
,
 Database Management Systems 2 -7 Entity Relationships

v) Derived attribute : A deriaed attributeis one that represent a value that is

derivable from the value of a related attribute or set of attributes. For example,
the age athibute can be derived from the date of birth attribute.

2.4 Relationships and Relationship Sets

A relationship expresses an association among several entities. A relationship set is
a set of relationships of the same type.
For example, consider two entities Person and Company as shown n Fig. 2.2.
relationslip Worlcs-for represents association between Person and Company. This
bfoEry relationship set.

Fig. 2.2 An E-R diagram

Entity role
The function that an entity plays in a relationship is called that entity's role. A
is one end of an association.
Consider following Fig. 2.3 (a).

Fig. 2.3 (a) Role names for an association

shown in Fig. 2.3 (a) Person and Company participates in associatiort'Works-for'.
assurnes the role of Employee with respect to Company. A Company assumes the
ernployer with respect to Person.
relationship may also have attributes called descriptive attributes. Consider a
set Depositor with entity sets Customer and Account. We c.rn associate
access-date to the depositer relationship to specify the most recent date on
e customer accessed an account as shown in Fig. 2.3 (b).

'
 Database Management SYstems 2-8 Entity Relationships

Fig. 2.3 (b) Relationship set with descriptive attribute

Types of relationshiPs
i) Unary relationship : A unary relationship exists when Ern association
maintained within a single entity.
For example, boss and worker distinguish the two employees participating
the manage association as shown in following Fig- 2-4.

Fig. 2.4 Association between two objects of the same entity set
ii) Binary relationship : A binary relationship exists when two entities €ue
associated. For example, the Book - Publisher relationshiP shown in Fig. 2-5 is
a binary relationship.

Fig. 2.5 A binary relationshiP

iii) Ternary relationship : A ternary relationship exists when there are three
entities associated. For example, the entities Teacher, Subject and Student are
related using a ternary relationship called 'Teaches' as shown in Fi9.2.6.

,\

2
lHabase Management Systems 2-9 Entity Relationships

Fig. 2.6 Ternary relationship

iv) Quaternary relationship : A quaternary relationship exists when there are four
entities associated. An example of quaternary relationship is 'sfud.ies, where
four entities are involved- Sfudent, Teacher, Subject and Course-material. It
is shown tn Fig. 2.7.

Ftg. 2.7 A quaternary relationship

Keys
A key allows us to identify a set of atbributes and thus distinguishes entities from
r other. Keys also help uniquely identify relationshpr, and thus disfnguish
from each other.

types of keys are :

. Superkey
. Candidate key
. Primary key
. Foreign key
 2-10 Entity RelationshiPs
Database Management SYstems

Super key : A superkey is a set of one or more attributes

that allows us to
l. Roll-No attribute
identify uniquely an entity in the entity set' For example, the
of the entrty set 'student' distinguishes one student entitY from another'
and we are
2. candidate key : A superkey may contain extraneous attributes
often interest in the smallesi superkey. A superkey for which
no subset is a
superkey is called a candidate key'
For example, student-name and student-street, are sufficient to uniquely
identify one particular student. Hence, Roll-No, and {student-Name'
student_street) are candidate keys. Although the attributes
Roll-No and
student_Name together can distinguish Customer entities,
their combination
Roll-No alone is a candidate
does not form a candidate key. Sin; the attribute
kuy.
primary key : It is a cand.idate key that is chosen by the database designer as
For example'
the principal means of identifying entities within an entity set'
key should be
Roll-No is a primary set of 'stuJent' entity set. The primary
For instance' the
chosen such that its attributes are never or rarely, changed'
key, since it is
Address field of a Person should not be patt of the primary
tikely to change. Social security on the other hand, are guranteed
to never
change.
that
Foreign key : An attribute or set of attributes, within one relation ljttl:
the candidate k"y of some (possibly the same) relation' For example'
branch to
inclusion of Branchno in ntanct, and staff relation links each
Branch-no
details of staff working at that branch. In the Branch relation,
primary key. Ho*"rr"rl in the staff relation the Branctt-":
:T*S::jitt:
Branch-no i
match staff to the Branch office th"y work in. L:r the staff relation,
foreign keY.

2.6 Introudction to ER Diagram

2.6.1 GomPonents of E-R Model

graphically using E-
The overall logical structure of a database can be expressed
components shown i
diagrams. such a diagram consists of the following maior
Fig. 2.8.
Following Fig. 2.9 shows an E-R diagram for banking system'
It consists of
set Borrower.
entity sets, Customer and. Loan related through binary relationship
attributes associated with Customer are Customer-id, Customer-name/
Amount'
Customer-address. The athibutes of Loan are Loan-no and

t\

!-
F
ips Database Management Systems 2-11 Entity Relationships

,to
Component name Symbol Description
ute

1) Rectangles Represents entity sets

are
isa
2) Ellipses Represents attributes

rely
me/
and 3) Diamonds Represents relationship sets
tion
late
4) Lines Links attributes to entity sets
& entity sets to relationship sets
tr as 5) Double ellipses Represents multivalued attributes
Ple,
lbe t-\
6) Dashed ellipses Represents derived attributes
the
it is
ever 7) Double rectangles Represents weak entity sets

rches Represents total participation of

8) Double lines
the an entity in a relationship set
r tlrc
rob Fig. 2.8 E-R diagram symbols
ts to
noi

7r
7tr
:-
Fig. 2.9 E-R diagram corresponding to Customers and Loans
tt
ET
Gardinality
-l
in E-R diagram that is represented by two ways :

line (+)
line (-)
 Database Management SYstems 2-12 Entity RelationshiPs

relati
1. One-to-one relationship : Following Fig. 2.'!.0 represents one-to-one
f between two entities i 'Manager' and 'Departrn ent' , related through a

relationshiP'Manages'.

Fig. 2.10 One'to'one relationship

relationshiP
2. one-to-many relationship : Following Fig. 2.11' shows one-to-many
between entities : 'Departnent' and 'Employee', related through
binary
relationship 'Has'.

Fig. 2.11 One'to'many relationship

3. Many-to-one relationshiP :

Following Fig. 2.12 shows many-to-one relationship between entity sets

'students' ut a 'GFM', relates through binary relationship 'Have'' The
interpretation is, many students have one GFM (Guardian Facility Member)'

Fig. 2.12 Many-to'one relationship

4. Many-to-many relationship : Following Fig. 2.13_ shows many-to-many
relationship between entity sets 'Employee' and 'Coutse', related through
binary relationshiP']oins'.

i1
l
T

Database Management Systems 2-13 Entity Relationships

Fig. 2.13 Many-to-many relationship

2) Representation of Role
The ftrnction that an entity plays in a relationship is called its role. They are useful
rt-hen the meaning of a relationship set needs classification. For example, the
relationship Works-for might be ordered pairs of employees (first is Manager, second
is Worker).
In the E-R diagram, this can be show^ by labelling the lines connecting entities
rectangles) to relationshipr (diamonds) as shown in Fig. 2.r4.

Fig. 2.14 E-R diagram with role indication

3) Sample E-R Diagrams

al E-R diagram with an attribute attached to a relationship set

Fig' 2.15 E-R diagram with an attribute attached to a relationship set

M a relationship set has some attributes associated with it, then we tink these
ffibutes to that relationship set. For example, in Fig. 2.75 the access-date attribute is
:rta6hgd to the relationship set depositer to specify the most recent date on which a
s-tomer accessed that account.
 2-14 Entity RelationshiPs
Database Management SYstems

ii) E-R diagram with composite multivalued and derived attribute

7'
-

Primary keY

Address

attribute
Fig. 2.16 E-R diagram with composite, multivalued and derived
As shown in Fig. 2.1.6'Name' is a composite attribute with comPonent
attributes
with
First-name, Last-name. similarly Address is also a composite attribute
attribute and Age
component attributes Street, Crty, State, Pin. Ph no is a multivalued
is a derived attribute.

iii) Total participation of an entity set in a relationship set

that each
As shown in Fig. 2.I7, a double line from Loan to Borrower indicates
Loan must have at least one associated customer.

Fig. 2.17 Total ParticiPation of an entity set in a relationship set

i1
\
 &tabase Management Systems 2-15 Entity Relationships

t) Gardinality limits on relationship sets

Fi1.2.18 Gardinality limits on relationship sets

As shown in Fig. 2.18, the edge between Customer and Borrower has cardinality
*
int 0 indicate that Customer has zero or more loans. The constraint 0 .....
the edge between Borrower and Loan (1 ... 1) indicates that a loan must have one
associated with it.

Ef, diagram for Book Glub

-Fig. 2.L9 shows an E-R diagram for Book Club.

s
h
e

b
le
7.s

Fig. 2.19 E-R diagram of the book club

7- -'-
Database Management Systems 2-16 Entity Relationships

The book club has members. The book club sells books to its members. The
members places orders for books, which the book club fulfills. Each order contains one
or more than one book. The books are written by author(s). The Publisher publishes
the book.
An author can write more than one book and a book can have more than one
author. A book is published by a publisher, but a publisher publishes many books. A
member can place more than one order. He also can choose not to place an order. The
book club sells many books. The book club example is converted into an E-R diagram
and is shown in Fig. 2.19.

vi) E-R diagram for banking enterprise

-
-

Fig. 2.20 E-R diagram for banking enterprise

.\
IbDase Management Systems 2-17 Entity Relationships

vii) E-R diagram for insurance database

Fig. 2.21 E-R diagram for insurance database

Zl Additional Features of The E-R Model
An E-R enterprise schema may define certain constraints to which the contents of
e &base system must conform.
Two main important types of constraints are:
o Key Constraints/ Mapping Cardinalities
. Participation Constraints

2r-1 Key Gonstraints

M"ppi^g cardinalities express the number of entities to which another entity
h Gociated via a relationship set.
kr a binary relationship set R between entity sets A and B, the mapping
dinalities must be one of the following :

il 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 i^ A, as shown in Fig. 2.22.
Example : A Customer with single
account at given Branch is shown
by one-to-one relationship as given
in Fig. 2.23.

Fig. 2.22 One-to-one mapping cardinality

 2-18 Entity RelationshiP
Database Management SYstems

Fig. 2.23 One'to-one relationship

ii) One-to-many : An entity in A is associated with any number of entities (
or more) in B. An entiff in B, however, can be associated with at most
entity in A.

Fig. 2-24 ne-to'many mapping cardinality

Example : A Customer having two accounts at a given Branch
is shown
one-to-many relationship as given below'

Fig. 2.25 One'to-many relationship

iii) 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 .2 P;

entities in A. Ther

Total
be tot

For

tions
Fig. 2.26 Many-to-one mapping cardinality Th
Database Management SYstems 2-19 Entity RelationshiPs

Example : Many emPloYees works for a company. This relationship is shown

by many-to-one as given below.

Fig. 2.27 Many-to'one relationship

iv) 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 anv number (zeto or
more) of entities in A.

Fig. 2.28 Many'to-many relationship

Example : Employee works on number of projects and project is handled by
number of empltyees. Therefore, the relationship between Employee and
project is many-to-many as shown below'

Fig. 2.29 Many-to-many relationship

Z7 2 ParticiPation Gonstraints
There are two gpes of participation constraints :

I Tffil participation : The participation of an entity set E in a relationship set R is said

D be total if every entity in E participates in at least one relationship in R.

I partial participation : If only some entities in E participate in relationships in R, the

prtkipation 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
f-,gh the Borrower relationship. Therefore, the participation of Loan in the
ddionship set Borrower is total. While, a bank customer may or may not have a
hL Therefore, the participation of Customer in the Borrower relationshiP is partial'
F- 2 -20 Entity RelationshiPc
Database Management SYstems

I
2.7.3 Weak Entities
'r
]"" Existence dependencies
If the existence of entity x depends on the existence of entity }/, then x is said to
be existence dependent on y. If y is deleted, so is x. Entity y is said to be a dominart
entity, and x is said to be subordinate entity.
Consider the entity set 'Loan' and the entity set 'Payment' that keeps informatim
about all the payments that were made in connection to a particular loan. TtE
payment entitl set is described by the attributes Payment-no, Payment-date and
payment_amount. We form a relationship set Loan-payment between these two entilr
from Loan to Payment. Every Payment entity must be
tty. If a Loan entity is deleted, then all its associated
be deleted. In contrast, Payment entities can be deleted
from the database without affecting any loan. The entity set Loan is therefore
dominant entity set which is also called as strong entity set, artd the entity set Paymert
is subordinate which is also called as weak entity set, in Loan-payment relationship.
Following Fig. 2.30 (a) shows the dominant entity set 'Loan' and subordinate entilr
set 'Payment' connected by relationship 'Loan-payment"

Fig. 2.30 (a) Existence dependency

Entities are classified as being strong or weak entity types. An entity that is
set on
existence dependent on some other entity is called a weak entity type.An entity
which weak entity set depends, is called strong mtity set.
For example, following Fig. 2.30 (b) shows weak entity set 'Parent' which depends
on strong entity set 'EmPloYee'.

Fig. 2.30 (b) Strong and weak entities

tt!
ps Database Management Systems 2-21 Entity Relationships

I 2.7.4 Class Hierarchies

In certain situations, some objects in a class have properties that are not shared by
to all objects in the class.
ant . In such a case, we might consider that, groups of objects with shared
properties form subclasses of the whole class
ion . The subclass-superclass relationship is an inheritance, and are often called
lhe
is-a relationshipr because a member of the subclass is-a member of the
urd
superclass.
tity
be . The relationship between superclass and subclass is represented using Class
ted Hierarchies.
ted The basic ER model fails to describe completely the reality of the data to be stored.
ore
With the increase in the types of the database applications, the basic concepts of the
ent
ER modeling are not sufficient to represent the requirements of the complex
applications, such as specialization and generalization (class hierarchies). The ER
tity model that supports these additional semantic concepts is called Extended Entity
Relntionship (EER) Model.
The EER model includes all the concepts of the original E-R model together with
the following additional concepts:
. SPecializations
o Generalization
o Aggregation

L7.4.1 Specialization
"Specialization is the process of designating subgroupings within an entity set."
Specialization is a top-down process. Consider an entity set Persory with attributes
Name, Street, and City. A Person may be further classified as one of the following.
1S

on o Customer
. Employee
nds Each of these Person types is described by a set of attributes that includes all the
athibutes of entity set Person plus additional attributes. For example, Customer
errtities may be further described by Customer id and Employee entities by
Employee_code and Salary.
Fig. 2.31 shows specializatiory which is represented by triangle. The lable ISA
stands for "is a", arrd represents, for example, that Customer "is a" Person. The ISA
relationship may also be referred to as a superclass-subclass relationship.
 Database Management SYstems 2 -22 Entity RelationshiPe

Fig. 2.31 Specialization and generalization

2] .4.2 Generalization

"Generalization is the Process of defining a more general entrty type from a set of
specialized entity !ryes."
Generali zation is a bottom-up approach. This approach results in the identifica
of a generaltzed superclass from the original subclasses

Consider that the attributes of 'Customer' entity are Customer id, Name, Street,'
and an 'Employee' entity atbributes are Employee-code,, Street, City and Salary'
the entity sets Employee and Customer have several attributes in conunon.
conunonufiay can be expressed by generalization which is a containment relatic
that efsts between a higher-level entity set and one or more lower-level entity
As shown in Fig. 2.31, person is a higher-level entity set and Customer and E-P
can lower-levellntity sets. In other words, Person is a superclass if Customer
Employee are subclasses.

i\
I
lps Database Management Systems 2-23 Entity Relationships

Constraints in specialization and generalization allow us to capture some of the

important business rules that apply to the relationships.

a) One type of constraint involves determining which entities can be members of a

qir-en lower-level entity set. Such membership may be one of the following :
. Condition defined : In condition-defined lower-level entity sets, membership
is evaluated on the basis of whether or not an entity satisfies an explicit
condition or predicate. For example, assume that the higher-level entity set
Account is having attribute Account_type. Orly those entities that satisfy the
condition Account_type = "Savings account" are allowed to belong to the
lower-level entity set 'Savings_account'. All entities that satisfy the condition
Account_type = "checking account" are included in checking account.
. LJser defined : These types of constraints are defined by user. For example,
let us assume that, after 3 months of employment bank employees are
assigned to one of four work teams. We therefore represent the teams as four
lower-level entity sets of the higher-level Employee entity set. A given
Employee is assigned to one of the four teams by incharge of the teams.

:, A second type of constraint relates to whether or not entities may belong to more
ian one lower-level entity set within a single generalization. The lower-level entity
-Li may be one of the following :
. Disjoint : A disjointness constraint requires that an entity belong to only one
lower-level entity set. For example, da Account entity may be either
Saving_account or Checking_account. It satisfies just one condition at a time.
. Overlapping : In overlapping generaltzation, the same entity may belong to
tion
more than one lower-level entity set within a single generalization.
For example, a single manager may participate in more than one work team.
Cit)-
-\nother example is, assume from Person, two entities Customer and Employee,
hus,
IhLs
re derived. The generaltzation is overlapping if an Employee can also be a customer.
ship : -\ final constraint, is a completeness constraint on a generaltzatron/specialization,
set_s.
r-hich specifies whether or not an entity in the higher-level entity set must belong to
)vee
rt ieast one of the lower-level entity sets within the generalization/specialization. This
and
---xr-straint may be one of the following :
o Total generalization or specialization : Each higher-level entity must belong
to a lower-level entity set.
 Database Management SYstems 2 '24 Entity

. partial generalization or specialization : Some higher-level entities may

belong to any lower-level entity set. Partial generalization is the default.
.ur, ,f".ify total generaltzation in an E-R diagrarn by using a double line
connect the box representing the higher-level entity set to the trian
symbol.
For example : Employees are assigned to a team only after 3 months on the
Some Employee entities may not be members of any of the lower-level team
e

sets. We may characterize the team entity sets more fully as a partial, overla
specialization of EmPloyee.
The generalization of Checkingaccount and Savings-account into Account is
total disjoint genenltzation.

2.7 .4.3 Attribute Inheritance

,,A crucial property of the higher and lower-level entities created by specializati
and generalization is attribute inheritance"'
The attributes of the higher-level entity sets are said to be inherited by
lower-level entity sets. For example, Customer and Employee inherit the atributes
the Person. Thus, Customer is described by Name, Street, City and with addi
athibute Customer-id. Similarly, Employee is described by Name, Street, City
additional attributes Employee-code and Salary'

2.7.5 Aggregation
One limitation on E-R model is that it cannot express relationshiPt
relationshiPs.
Consider a quaternary relationship Manages between Employee, Branch, Iob,
Manager. using the basic E-R modeling constructs, we obtain the E-R diagram
showrr in Fig. 2.32. (See Fig. 2.32 on next Page)
There is redundant information in the resultant figure, since every
Branch, fob combination in Manages is also in works-on.
The best way to model above situation is to use aggregation- Aggregation is
abstraction through which relationships are treated as higher-level entities. Thus,
relationship set Works-on relating the entity sets Employee, Branch and Iob
considered as a higher level entity set called Works on. We can then create a

t\
ships Database Management Systems 2-25 Entity Relationships

not
We
Le to
ngle

e job.
entity
PPiNg

tisa

zation

y the
Fig. 2.32 E-R diagram with redundant rerationships
tes of
tional
r and ftionship manager between Works-on and manager to represent who manages
ft tasks.
Hg. 2.33 shows E-R with aggregation.

monS

t, and
rm as

loyee,

is an
s, the
ob is
rinary

Fig. 2.33 E-R diagram with aggregation

 Entity RelationshiPs

)Ea Various design issues related to E-R model are given below :

2.8.1 Entity Sets Vs Aftributes

. Consider the entity set employee with athibutes : emp-id' emP-name/
telephone-flo, emP-salarY.
r The athibute telephone-no in entity set employee is an entity in its own
right with affiributes : telephone-no and location ; the location can be office
or home.
r If we consider this view ; the employee entity set is redefined as follows :
* The employee entity set with attributes emp id, emP-name, emp-salary'
* The telephone entity set with attributes telephone-no and location'
* The relationship set emp-telephone, denoting the association between
employee and telePhone.
These alternatives are shown in following Fig. 2.34:

. Here the question is whether to represent telephone-no as attribute or as

entity set. In other words : what constitutes an attribute ? and what
of
constitutes an entity set ? The distinctions mainly depend on the structure
the real-world enterprise being modelled, and on the semantics associated
with the athibute in question.

(b)

Fig. 2.34 Alternatives for employee and telephone

:
'! I

i
Habase Management Systems 2-27 Entity Relationships

2,8.2 Entity Set Vs Relationship Sets

o It is not always clear whether an object is best expressed by an entity set or
a relationship set.
. A bank loan can be modelled as an entity.
o An alternative is to model a loan not as an entity, but as a relationship
between customers and branches with loan-no and amount as descriptive
attribute.

2-t.3 Binary Vs Ternary Relationship

Some relationshipt that appear to be non-binary may be better represented using
hinary relationshipr.
. For example, A ternary relationship parenfs, relating a child to his/her father
and mother, is best replaced by two binary relationshpr, father and mother.
Using two binary relationshipr allows partial information (e.g. only mother
being know).
o But there are some relationshipr that are naturally non-binary. Example :
works-on.
r In general, any non-binary relationship can be represented using binary
relationshipr by creating an artificial entity set.
. Replace R between entity sets A, B and C by an entity set E, and three
relationship sets :
1. Rn, relating E and A
2. Rr, relating E and B
3. RC, relating E and C
o Create a special identiV^g attribute for E.
. Add any attributes of R to E.
o For each relationsHp (ui, bi, c1) in R, create : '

1. a new entity ei in the entity set E

2. add (ei,?,) to R4
3. add (ei, bi) to Rg
4. add (ei, ci) to Rs

2J'.4 Placement of Relationship Attributes

It can make access-date an attribute of account, instead of a relationship attribute, if
cnch account can have only one customer i.e., the relationship from account to
os'tomer is many to one, or equivalently, customer to account is one to many.
 2 -28 Entity RelationshiPs
Database Management SYstems

2.8.5 Aggregation Vs Ternary Relationship

is mainly
The choice between using aggregation or a ternary relationshipto an enttty
relates a relationship set
determined by the existence or u ,"lutionship that
second relationship set). The choice also depends
on certain:- i-fncrikr
integrity
set (or
DEL
consider the ER diagram shown in
\v^

constraints that we want to express. For example, r_ ^-- ^I

;Cffi:';;;;ilr';',il
r r5' L'rv' Hs; a project can be sponsored bv anv number or
is
ic.
tt i".-'t"t" t'tt" more proJec :ts' and
departments, a department can sPonsor one or
--l ^^^L sPonsorship
each -6n6c^1.clrin
,-^ -^-) rL^ o+l-t"ilrrrlp
until attribute nf
of
If we don't need to record the "-+il
",ffi;';;-;;;;; "-prov"es. s€r]' Sponsors 2' ^ ^L^-^'- shown in i
monitors, then we can use a ternary relationship,
Fig. 2.36.
constraint that each sponsorship (of a project by
the
u deparfiment) be
Consider
LDT\^LT LI

at most one emPloyee. we cannot express his conltr* Tl::::^t-T:

\-\JI

monitored by V V
IIT\JILTL\'.L9V J

sponsors 2 relationshiP set' On the other hand'

t*
*" " tY::tT:
t"^t::i"tl**l
u." aggregated relationship sponsors to the relationship
;ffi;; ;;;;;--f# foac'r\tt
reason
a constraint serves as einother
^fhar
Monitors in Fig. 2.g5. Thus, rn"-p1"r"nce of such
set'
for using aggregation rather than a ternary relationship

Fig. 2.35 Aggregation i

J\
\
Database Management Systems 2 -29 Entity Relationships

Fig. 2.36 Using ternary relationship instead of aggregation

23 Conceptual Design for Large Enterprise

designing E-R database
schema for large enterprise are given below :

o The use of an attribute or entity set to represent an object.

o whether a real-world concept is best expressed by an entity set or a
relationship set.
. The use of a ternary relationship versus a pair of binary relationshipr.
o The use of a strong or weak entity set.
o The use of specialization / generalization - contributes to modularity in the
design.
. The use of aggregation - can treat the aggregate entity set as a single unit
without concern for the details of its internal strucfure.

' Conceptual-design(specification of functional requirements)

. Logical-design phases
o Physical-design phase
 Database Management Systems 2-30 Entity Relationships

below :

o First step in database design is to identify data requirements. Data

requirements for Banking Enterprise is given below.
i) The bank is organized into branches.
ii) Bank customers are identified by their customer-id values.
iii) Bank employees are identified by their employee-id values.
irr)The bank offers two types oI accounts-saaing and checking accounts.
v) A loan originates at a particular branch and can be held by one or
more customers.
Second step in database design is to identify entity sets. Following entity sets
are required for given data requirement :
i) The branch entity set.
ii) Thte customer entity set.
iii) The employee entity set.
i.r) Two account entity sets.
v) the loan entity set.
vi) The weak entity set loan-payment.
. Third step in database design is to identify relationship sets. Following
relationship sets are required for given data requirement :

i) borrower.
ii) loan-branch.
iii) loan-payment.
iv) depositor.
v) cust-banlcer.

vi) works-for.
o Last step in database design is to draw E-R diagram using idenffied entity
sets and relationship sets.

University Questions with Answers

Q.1 Explain the dffirence between week entity and strong entity set ? How to represent
the strong entity and weak entity set through ER-dingrams.

Ans. : Refer section 2.7.3.

,\
Database Management SYstems 2-31 Entity RelationshiPs

The State Bnnk of Indin offers the fiae different types of accounts : Ioan, checking,
recurring deposits, Iocker accounts and fixed deposit. The Bank has a number tf
brartches and a client of the bank can open many accounts. A account can be ioint
and more than one client may operate an account. Identify the entities, attributes
what relationships exist among these entities and Tables. Draw the corresponding
E-R diagrnm.

Bank name

Branch Address

Branch Name

Client Name

:-sallment Amt.

'n=llment Date FD Maturitv Date

Fig. 2.37

Design a generalization-specialization hiernrchy for a motor-aehicle snles company.

The company sells motor-cycles, passenSer cars, rans and busses. lustify your
(attributes) should
placement of attributes at ench leael of hierarclry. Explain why they
not be placed at higher or lower leuel? Conaert the E-R diagrnm so tnade fo 3NF
relational scheme.
 Database Management SYstems 2 -32 Entity Relationships

r'

Fig. 2.38
Q.4 How can you gioe names to output columns in a query that are defined by arithmeti
or string expressions ? What support does SQL ffir for string pattern matching
Explain with an examPle.
Ans. : The example of query for giving names to output columns in a query that
defined by arithmetic or string expressions is given below :
select Author_nalne, sum (Unit-Price*0.15) "Royalty" ftom Book
group by Author-name;
Above query displays author narne and their royalty amount which is calcula
as 'Unit-price * 0.15' where Unit-price is a column in Book table.
String pattern matching : Refer section 2.I7.

Q.5 Exptain about the conceptual design with ER model

Ans. Refer section 2.9.

Q.6 What is the dffirence between total and partial participation ?

Ans. Refer section 2.7.2.

Q.7 Explain the database design for a banking enterprise.

I

Ans. Refer section 2.9.

Q.8 Erplain about the placement of relation ships attributes.,

Ans. Refer section 2.8.4.

r1
l

E
rships Ilatabase Management SYstems 2-33 Entity Relationships

eg Orgnnize the following fiels into a hierarchy for a bank's database : payment, saaing,
account, deposit, customer, Ioan nccount, wit.hdrawal'

hmetic
ching? Fig. 2.39
6d Q.10 Explain the dffirence between primary Vs n-ary relationship sets.
Lat are

Ans. :

Fig. 2.40
As shown in above diagram following ftrnctional dependencies are there in
student table.
Student-number -------) Student-Name
Student-number ----J Student-Major-dept
Student-number ------> Student-credits
Student-number Student advison_number
--J
Student-advison-number ---J Student-advison-name
Student-advison-number Student-advison-office-no
Student-advison-number -----+ Student-advison-phone-no
trtrtr