The Entity-Relationship Model

The E-R (entity-relationship) data model views the real world as a set of basic
objects (entities) and relationships among these objects.
It is intended primarily for the DB design process by allowing the specification of
an enterprise scheme. This represents the overall logical structure of the DB.
ntities and ntity !ets
"elationships # "elationship !ets
$ttributes
%apping &onstraints
'eys
(rimary 'eys for "elationship !ets
The ntity "elationship Diagram
)ther !tyles of -" Diagram
"educing -" Diagrams to Tables
o "epresentation of !trong ntity !ets
o "epresentation of *ea+ ntity !ets
o "epresentation of "elationship !ets
,enerali-ation
$ggregation
Design of an -" Database !cheme
o %apping &ardinalities
o .se of ntity or "elationship !ets
o .se of /tended -" 0eatures
Entities and Entity Sets
$n entity is an object that e/ists and is distinguishable from other objects. 0or
instance1 2ohn 3arris with !.I.4. 567-89-:;<= is an entity1 as he can be uni>uely
identified as one particular person in the universe.
$n entity may be concrete (a person or a boo+1 for e/ample) or abstract (li+e a
holiday or a concept).
$n entity set is a set of entities of the same type (e.g.1 all persons having an
account at a ban+).
ntity sets need not be disjoint. 0or e/ample1 the entity set employee (all
employees of a ban+) and the entity set customer (all customers of the ban+) may
have members in common.
$n entity is represented by a set of attributes.
o .g. name1 !.I.4.1 street1 city for ??customer@@ entity.
o The domain of the attribute is the set of permitted values (e.g. the
telephone number must be seven positive integers).
0ormally1 an attribute is a function which maps an entity set into a domain.
o very entity is described by a set of (attribute1 data value) pairs.
o There is one pair for each attribute of the entity set.
o .g. a particular customer entity is described by the set A(name1 3arris)1
(!.I.4.1 567-89:-;<=)1 (street1 4orth)1 (city1 ,eorgetown)B.
$n analogy can be made with the programming language notion of type definition.
The concept of an entity set corresponds to the programming language type
definition.
$ variable of a given type has a particular value at a point in time.
Thus1 a programming language variable corresponds to an entity in the -"
model.
0igure 9-8 shows two entity sets.
*e will be dealing with five entity sets in this sectionC
branch1 the set of all branches of a particular ban+. ach branch is described by
the attributes branch-name1 branch-city and assets.
customer1 the set of all people having an account at the ban+. $ttributes are
customer-name1 S.I.N.1 street and customer-city.
employee1 with attributes employee-name and phone-number.
account1 the set of all accounts created and maintained in the ban+. $ttributes are
account-number and balance.
transaction1 the set of all account transactions e/ecuted in the ban+. $ttributes are
transaction-number1 date and amount.
Relationships & Relationship Sets
$ relationship is an association between several entities.
$ relationship set is a set of relationships of the same type.
Formally it is a mathematical relation on (possibly non-distinct) sets.
If are entity sets1 then a relationship set " is a subset of
where is a relationship.
0or e/ample1 consider the two entity sets customer and account. (0ig. 9.8 in the te/t). *e
define the relationship CustAcct to denote the association between customers and their
accounts. This is a binary relationship set (see 0igure 9.9 in the te/t).
,oing bac+ to our formal definition1 the relationship set CustAcct is a subset of all the
possible customer and account pairings.
This is a binary relationship. )ccasionally there are relationships involving more than
two entity sets.
The role of an entity is the function it plays in a relationship. 0or e/ample1 the
relationship works-for could be ordered pairs of employee entities. The first employee
ta+es the role of manager1 and the second one will ta+e the role of wor+er.
$ relationship may also have descriptive attributes. 0or e/ample1 date (last date of
account access) could be an attribute of the CustAcct relationship
Attributes
It is possible to define a set of entities and the relationships among them in a number of
different ways. The main difference is in how we deal with attributes.
&onsider the entity set employee with attributes employee-name and phone-
number.
*e could argue that the phone be treated as an entity itself1 with attributes phone-
number and location.
Then we have two entity sets1 and the relationship set EmpPhn defining the
association between employees and their phones.
This new definition allows employees to have several (or -ero) phones.
4ew definition may more accurately reflect the real world.
*e cannot e/tend this argument easily to ma+ing employee-name an entity.
The >uestion of what constitutes an entity and what constitutes an attribute depends
mainly on the structure of the real world situation being modeled1 and the semantics
associated with the attribute in >uestion.
Mapping onstraints
$n -" scheme may define certain constraints to which the contents of a database must
conform.
Mapping ardinalities! e/press the number of entities to which another entity
can be associated via a relationship. 0or binary relationship sets between entity
sets $ and B1 the mapping cardinality must be one ofC
8. "ne-to-oneC $n entity in $ is associated with at most one entity in B1 and
an entity in B is associated with at most one entity in $. (0igure 9.:)
9. "ne-to-manyC $n entity in $ is associated with any number in B. $n
entity in B is associated with at most one entity in $. (0igure 9.;)
:. Many-to-oneC $n entity in $ is associated with at most one entity in B. $n
entity in B is associated with any number in $. (0igure 9.<)
;. Many-to-manyC ntities in $ and B are associated with any number from
each other. (0igure 9.=)
The appropriate mapping cardinality for a particular relationship set depends on
the real world being modeled. (Thin+ about the CustAcct relationship...)
E#istence $ependencies! if the e/istence of entity D depends on the e/istence of
entity E1 then D is said to be e#istence dependent on E. ()r we say that E is the
dominant entity and D is the subordinate entity.)
0or e/ample1
o &onsider account and transaction entity sets1 and a relationship log
between them.
o This is one-to-many from account to transaction.
o If an account entity is deleted1 its associated transaction entities must also
be deleted.
o Thus account is dominant and transaction is subordinate.
%eys
Differences between entities must be e/pressed in terms of attributes.
$ super&ey is a set of one or more attributes which1 ta+en collectively1 allow us
to identify uni>uely an entity in the entity set.
0or e/ample1 in the entity set customer1 customer-name and S.I.N. is a super+ey.
4ote that customer-name alone is not1 as two customers could have the same
name.
$ super+ey may contain e/traneous attributes1 and we are often interested in the
smallest super+ey. $ super+ey for which no subset is a super+ey is called a
candidate &ey.
In the e/ample above1 S.I.N. is a candidate +ey1 as it is minimal1 and uni>uely
identifies a customer entity.
$ primary &ey is a candidate +ey (there may be more than one) chosen by the
DB designer to identify entities in an entity set.
$n entity set that does not possess sufficient attributes to form a primary +ey is called a
'ea& entity set( )ne that does have a primary +ey is called a strong entity set.
0or e/ample1
The entity set transaction has attributes transaction-number1 date and amount.
Different transactions on different accounts could share the same number.
These are not sufficient to form a primary +ey (uni>uely identify a transaction).
Thus transaction is a wea+ entity set.
0or a wea+ entity set to be meaningful1 it must be part of a one-to-many relationship set.
This relationship set should have no descriptive attributes. (*hyF)
The idea of strong and wea+ entity sets is related to the e/istence dependencies seen
earlier.
%ember of a strong entity set is a dominant entity.
%ember of a wea+ entity set is a subordinate entity.
$ wea+ entity set does not have a primary +ey1 but we need a means of distinguishing
among the entities.
The discriminator of a wea+ entity set is a set of attributes that allows this distinction to
be made.
The primary &ey of a 'ea& entity set is formed by ta+ing the primary +ey of the strong
entity set on which its e/istence depends (see %apping &onstraints) plus its
discriminator.
To illustrateC
transaction is a wea+ entity. It is e/istence-dependent on account.
The primary +ey of account is account-number.
transaction-number distinguishes transaction entities within the same account
(and is thus the discriminator).
!o the primary +ey for transaction would be (account-number transaction-
number".
)ust Remember! The primary +ey of a wea+ entity is found by ta+ing the primary +ey of
the strong entity on which it is e/istence-dependent1 plus the discriminator of the wea+
entity set.
*rimary %eys for Relationship Sets
The attributes of a relationship set are the attributes that comprise the primary +eys of the
entity sets involved in the relationship set.
0or e/ampleC
S.I.N. is the primary +ey of customer1 and
account-number is the primary +ey of account.
The attributes of the relationship set custacct are then (account-number S.I.N.".
This is enough information to enable us to relate an account to a person.
If the relationship has descriptive attributes1 those are also included in its attribute set. 0or
e/ample1 we might add the attribute date to the above relationship set1 signifying the date
of last access to an account by a particular customer.
4ote that this attribute cannot instead be placed in either entity set as it relates to both a
customer and an account1 and the relationship is many-to-many.
The primary +ey of a relationship set depends on the mapping cardinality and the
presence of descriptive attributes.
*ith no descriptive attributesC
many-to-many! all attributes in .
one-to-many! primary +ey for the ??many@@ entity.
Descriptive attributes may be added1 depending on the mapping cardinality and the
semantics involved (see te/t).
The Entity Relationship $iagram
*e can e/press the overall logical structure of a database graphically with an -"
diagram.
Its components areC
rectangles representing entity sets.
ellipses representing attributes.
diamonds representing relationship sets.
lines lin+ing attributes to entity sets and entity sets to relationship sets.
In the te/t1 lines may be directed (have an arrow on the end) to signify mapping
cardinalities for relationship sets. 0igures 9.5 to 9.87 show some e/amples.

Figure +(,! $n -" diagram

Figure +(-! )ne-to-many from customer to account

Figure +(.! %any-to-one from customer to account

Figure +(/0! )ne-to-one from customer to account
,o bac+ and review mapping cardinalities. They e/press the number of entities to which
an entity can be associated via a relationship.
The arrow positioning is simple once you get it straight in your mind1 so do some
e/amples. Thin+ of the arrow head as pointing t
"ther Styles of E-R $iagram
The te/t uses one particular style of diagram. %any variations e/ist.
!ome of the variations you will see areC
Diamonds being omitted - a lin+ between entities indicates a relationship.
o Gess symbols1 clearer picture.
o *hat happens with descriptive attributesF
o In this case1 we have to create an intersection entity to possess the
attributes.
4umbers instead of arrowheads indicating cardinality.
o !ymbols1 81 n and m used.
o .g. 8 to 81 8 to n1 n to m.
o asier to understand than arrowheads.
$ range of numbers indicating optionality of relationship. (!ee lmasri #
4avathe1 p <5.)
o .g (718) indicates minimum -ero (optional)1 ma/imum 8.
o &an also use (71n)1 (818) or (81n).
o Typically used on near end of lin+ - confusing at first1 but gives more
information.
o .g. entity 8 (718) -- (81n) entity 9 indicates that entity 8 is related to
between 7 and 8 occurrences of entity 9 (optional).
o ntity 9 is related to at least 8 and possibly many occurrences of entity 8
(mandatory).
Multivalued attributes may be indicated in some manner.
o %eans attribute can have more than one value.
o .g. hobbies.
o 3as to be normali-ed later on.
E#tended E-R diagrams allowing more detailsHconstraints in the real world to be
recorded. (!ee lmasri # 4avathe1 chapter 98.)
o &omposite attributes.
o Derived attributes.
o !ubclasses and superclasses.
o ,enerali-ation and speciali-ation.
Roles in E-R $iagrams
The function that an entity plays in a relationship is called its role. "oles are normally
e/plicit and not specified.
They are useful when the meaning of a relationship set needs clarification.
0or e/ample1 the entity sets of a relationship may not be distinct. The relationship works-
for might be ordered pairs of employees (first is manager1 second is wor+er).
In the -" diagram1 this can be shown by labelling the lines connecting entities
(rectangles) to relationships (diamonds). (!ee figure 9.88).

Figure +(//! -" diagram with role indicators
1ea& Entity Sets in E-R $iagrams
$ wea+ entity set is indicated by a doubly-outlined bo/. 0or e/ample1 the previously-
mentioned wea+ entity set transaction is dependent on the strong entity set account via
the relationship set log.
0igure 9.89) shows this e/ample.

Figure +(/+! -" diagram with a wea+ entity set
2onbinary Relationships
4on-binary relationships can easily be represented. 0igure 9.8:) shows an e/ample.

Figure +(/3! -" diagram with a ternary relationship
This -" diagram says that a customer may have several accounts1 each located in a
specific ban+ branch1 and that an account may belong to several different customers.
Reducing E-R $iagrams to Tables
$ database conforming to an -" diagram can be represented by a collection of tables.
*e@ll use the -" diagram of 0igure 9.8;) as our e/ample.

Figure +(/4! -" diagram with strong and wea+ entity sets
0or each entity set and relationship set1 there is a uni5ue table which is assigned the
name of the corresponding set. ach table has a number of columns with uni>ue names.
(.g. 0igs. 9.8; - 9.85 in the te/t).
Representation of Strong Entity Sets
*e use a table with one column for each attribute of the set. ach row in the table
corresponds to one entity of the entity set. 0or the entity set account1 see the table of
figure 9.8;.
*e can add1 delete and modify rows (to reflect changes in the real world).
$ row of a table will consist of an n-tuple where n is the number of attributes.
$ctually1 the table contains a subset of the set of all possible rows. *e refer to the set of
all possible rows as the cartesian product of the sets of all attribute values.
*e may denote this as
for the account table1 where and denote the set of all account numbers and all
account balances1 respectively.
In general1 for a table of n columns1 we may denote the cartesian product of
by
Representation of 1ea& Entity Sets
0or a wea+ entity set1 we add columns to the table corresponding to the primary +ey of
the strong entity set on which the wea+ set is dependent.
0or e/ample1 the wea+ entity set transaction has three attributesC transaction-number1
date and amount. The primary +ey of account (on which transaction depends) is
account-number. This gives us the table of figure 9.8=.
Representation of Relationship Sets
Get " be a relationship set involving entity sets .
The table corresponding to the relationship set " has the following attributesC
If the relationship has + descriptive attributes1 we add them tooC
$n e/ampleC
The relationship set CustAcct involves the entity sets customer and account.
Their respective primary +eys are S.I.N. and account-number.
CustAcct also has a descriptive attribute1 date.
This gives us the table of figure 9.8I.
2on-binary Relationship Sets
The ternary relationship of 0igure 9.8: gives us the table of figure 9.85. $s re>uired1 we
ta+e the primary +eys of each entity set. There are no descriptive attributes in this
e/ample.
6in&ing a 1ea& to a Strong Entity
These relationship sets are many-to-one1 and have no descriptive attributes. The primary
+ey of the wea+ entity set is the primary +ey of the strong entity set it is e/istence-
dependent on1 plus its discriminator.
The table for the relationship set would have the same attributes1 and is thus redundant
7enerali8ation
&onsider e/tending the entity set account by classifying accounts as being either sa#ings-
account or che$uing-account.
ach of these is described by the attributes of account plus additional attributes. (sa#ings
has interest-rate and che$uing has o#erdraft-amount.)
*e can e/press the similarities between the entity sets by generali8ation. This is the
process of forming containment relationships between a higher-level entity set and one
or more lo'er-level entity sets.
In -" diagrams1 generali-ation is shown by a triangle1 as shown in 0igure 9.86.

Figure +(/.! ,enerali-ation
,enerali-ation hides differences and emphasi-es similarities.
Distinction made through attribute inheritance.
$ttributes of higher-level entity are inherited by lower-level entities.
Two methods for conversion to a table formC
o &reate a table for the high-level entity1 plus tables for the lower-level
entities containing also their specific attributes.
o &reate only tables for the lower-level entities.
Aggregation
The -" model cannot e/press relationships among relationships.
*hen would we need such a thingF
&onsider a DB with information about employees who wor+ on a particular project and
use a number of machines doing that wor+. *e get the -" diagram shown in 0igure
9.97.

Figure +(+0! -" diagram with redundant relationships
"elationship sets work and uses could be combined into a single set. 3owever1 they
shouldn@t be1 as this would obscure the logical structure of this scheme.
The solution is to use aggregation.
$n abstraction through which relationships are treated as higher-level entities.
0or our e/ample1 we treat the relationship set work and the entity sets employee
and pro%ect as a higher-level entity set called work.
0igure 9.98 shows the -" diagram with aggregation.

Figure +(+/! -" diagram with aggregation
Transforming an -" diagram with aggregation into tabular form is easy. *e create a
table for each entity and relationship set as before.
The table for relationship set uses contains a column for each attribute in the primary +ey
of machinery and w
$esign of an E-R $atabase Scheme
The -" data model provides a wide range of choice in designing a database scheme to
accurately model some real-world situation.
!ome of the decisions to be made are
.sing a ternary relationship versus two binary relationships.
*hether an entity set or a relationship set best fit a real-world concept.
*hether to use an attribute or an entity set.
.se of a strong or wea+ entity set.
$ppropriateness of generali-ation.
$ppropriateness of aggregation.
Mapping ardinalities
The ternary relationship of 0igure 9.8: could be replaced by a pair of binary
relationships1 as shown in 0igure 9.99.

Figure +(++! "epresentation of 0igure 9.8: using binary relationships
3owever1 there is a distinction between the two representationsC
In 0igure 9.8:1 relationship between a customer and account can be made only if
there is a corresponding branch.
In 0igure 9.991 an account can be related to either a customer or a branch alone.
The design of figure 9.8: is more appropriate1 as in the ban+ing world we e/pect
to have an account relate to both a customer and a b
9se of Entity or Relationship Sets
It is not always clear whether an object is best represented by an entity set or a
relationship set.
Both 0igure 9.8: and 0igure 9.99 show account as an entity.
0igure 9.9: shows how we might model an account as a relationship between a
customer and a branch.

Figure +(+3! -" diagram with account as a relationship set
This new representation cannot model ade>uately the situation where customers
may have joint accounts. (*hy notF)
If every account is held by only one customer1 this method wor+s.
9se of E#tended E-R Features
*e have seen wea+ entity sets1 generali-ation and aggregation. Designers must decide
when these features are appropriate.
!trong entity sets and their dependent wea+ entity sets may be regarded as a
single ??object@@ in the database1 as wea+ entities are e/istence-dependent on a
strong entity.
It is possible to treat an aggregated entity set as a single unit without concern for
its inner structure details.
,enerali-ation contributes to modularity by allowing common attributes of
similar entity sets to be represented in one place in an -" diagram.
/cessive use of the features can introduce unnecessary comple/ity into the desig