Download ch6

Chapter 6: Entity-Relationship Model
 Entity Sets
 Attributes
 Relationship Sets
 Mapping Cardinality
 Keys
 Extended E-R Features
 Design of an E-R Database Schema
 Reduction of an E-R Schema to Tables
Database System Concepts
6.1
©Silberschatz, Korth and Sudarshan
Entity Sets
 A database can be modeled as a collection of:
 entities, and
 relationships among those entities.
 An entity is an object that is distinguishable from other objects.
 Specific person, specific company, specific automobile
 Entities have attributes
 People have names and addresses
 An entity and its’ attributes are represented by a tuple
(342-97-4873, Smith, Main, Orlando)
 An entity set is a set of entities of the same type that share the same
properties and attributes.
 Set of all persons, set of all companies, set of all automobiles
Database System Concepts
6.2
©Silberschatz, Korth and Sudarshan
Entity Sets customer and loan
customer-id customer- customer- customername street
city
Database System Concepts
6.3
loan- amount
number
©Silberschatz, Korth and Sudarshan
Attributes
 The set of permitted values for an attribute is call the domain of
that attribute.
 Attributes can be one of several types:
 Simple
• height (in inches), weight (in ounces), last-name
 Composite
• name, address
 Single-valued
• any of the above
 Multi-valued attributes:
• phone-numbers, dependents, hobbies
 Derived attributes
• Can be computed from other attributes
• Age is derived from date-of-birth
Database System Concepts
6.4
©Silberschatz, Korth and Sudarshan
Attributes, Cont.
 Note that during modeling we are focused on what the relevant
data is, and not whether or how it will be in the database.
 Age vs. date-of-birth
Database System Concepts
6.5
©Silberschatz, Korth and Sudarshan
Composite Attributes
Database System Concepts
6.6
©Silberschatz, Korth and Sudarshan
Relationship Sets
 A relationship is an association among two (or more) entities
 Hayes is a depositor for account A-102
 The relationship is denoted by the tuple (Hayes, A-102)
 A relationship set is a mathematical relation among n  2 entities,
each taken from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}
where (e1, e2, …, en) is a relationship
 depositor is a relationship set, e.g., (Hayes, A-102)  depositor
Database System Concepts
6.7
©Silberschatz, Korth and Sudarshan
Relationship Set borrower
 Relationship sets can be visualized graphically.
Database System Concepts
6.8
©Silberschatz, Korth and Sudarshan
Relationship Sets (Cont.)
 An attribute can also be property of a relationship set.
 For instance, the depositor relationship set between entity sets
customer and account may have the attribute access-date
Database System Concepts
6.9
©Silberschatz, Korth and Sudarshan
Relationship Sets
with Attributes, Cont.
 Another example of a relationship set having attributes:
 Entities: Student and Course
 Relationship: Has-Taken
 Where does the attribute grade go?
Database System Concepts
6.10
©Silberschatz, Korth and Sudarshan
Degree of a Relationship Set
 The number of entity sets that participate in a relationship set is
referred to as the degree of that relationship set.
 Relationship sets that involve two entity sets are called binary.
 Most relationship sets in a database system are binary.
 Example of a ternary relationship set.
 Suppose employees of a bank may have jobs at multiple branches,
with different jobs at different branches.
 In such a case there is a ternary relationship set between employee,
job and branch.
Database System Concepts
6.11
©Silberschatz, Korth and Sudarshan
Mapping Cardinalities
 The mapping cardinality of a relationship set expresses the
number of entities to which one entity can be associated via
the relationship set.
 Most useful in describing binary relationship sets.
 For a binary relationship there are four types:
 One to one – legal US marriages
 One to many – academic advisors (at most one major)
 Many to one – same as one-to-many
 Many to many – depositors
Database System Concepts
6.12
©Silberschatz, Korth and Sudarshan
Mapping Cardinalities
One to one
One to many
Note: Some elements in A and B may not be mapped to any
elements in the other set
Database System Concepts
6.13
©Silberschatz, Korth and Sudarshan
Mapping Cardinalities
Many to one
Many to many
Note: Some elements in A and B may not be mapped to any
elements in the other set
Database System Concepts
6.14
©Silberschatz, Korth and Sudarshan
Mapping Cardinalities affect ER Design
 access-date could be an attribute of account instead of a
relationship attribute if each account can have only one
customer, i.e., if the relationship is one-to-many.
Database System Concepts
6.15
©Silberschatz, Korth and Sudarshan
E-R Diagrams
 Rectangles - entity sets
 Diamonds - relationship sets
 Ellipses - attributes:
 Double ellipses - multi-valued
 Dashed ellipses – derived
 Underlined - primary key attributes (will discuss later)
 Lines - connect attributes to entity sets, and entity sets to
relationship sets.
Database System Concepts
6.16
©Silberschatz, Korth and Sudarshan
E-R Diagram with Composite, Multivalued,
and Derived Attributes
Database System Concepts
6.17
©Silberschatz, Korth and Sudarshan
Relationship Sets with Attributes
Database System Concepts
6.18
©Silberschatz, Korth and Sudarshan
Roles
 The labels manager and worker are called roles; they specify how
employee entities interact via the works-for relationship set.
 Roles are indicated in E-R diagrams by labeling the lines that connect
diamonds to rectangles.
 Role labels are optional, and are used to clarify a relationship set
 Particularly helpful when entity sets of a relationship are not distinct
Database System Concepts
6.19
©Silberschatz, Korth and Sudarshan
Cardinality Constraints
 We express cardinality constraints by drawing either a directed
line (), signifying “one,” or an undirected line (—), signifying
“many,” between the relationship set and the entity set.
 If borrower were a one-to-one relationship:
 A customer would be associated with at most one loan
 A loan would be associated with at most one customer
Database System Concepts
6.20
©Silberschatz, Korth and Sudarshan
One-To-Many Relationship
 If borrower were a one-to-many relationship then a loan would be
associated with at most one customer, and a customer would be
associated with zero or more loans.
Database System Concepts
6.21
©Silberschatz, Korth and Sudarshan
Many-To-One Relationships
 If borrower were a many-to-one relationship then a loan would be
associated with zero or more customers, and a customer would
be associated with at most one loan.
Database System Concepts
6.22
©Silberschatz, Korth and Sudarshan
Many-To-Many Relationship
 A customer is associated with zero or more loans via borrower
 A loan is associated with zero or more customers via borrower
Database System Concepts
6.23
©Silberschatz, Korth and Sudarshan
Participation of an Entity Set
in a Relationship Set
 If every entity in an entity set participates in a relationship set, then that
entity set is said to have total participation in the relationship set.
 Total participation is indicated by a double-line
 Participation of loan in borrower is total since every loan must have
at least one customer associated with it via borrower
 If participation in a relationship set is optional for some entities then that
entity set is said to have partial participation in the relationship set.
 Participation of customer in borrower is partial
Database System Concepts
6.24
©Silberschatz, Korth and Sudarshan
Another Example
of Total Participation
 Consider a relationship between entity sets Student and
Faculty called Advises.
 Assuming each student has exactly one major:
 Every student has exactly one faculty advisor
 Some faculty don’t advise students
 In this case the Advises relationship set is:
 One to many from Faculty to Student
 Student participation is total
 In most universities, the Advises relationship is more likely
many-to-many, with the Student participation being total.
Database System Concepts
6.25
©Silberschatz, Korth and Sudarshan
Alternative Notation
for Cardinality Limits
 Specific cardinality limits can also express participation constraints
Database System Concepts
6.26
©Silberschatz, Korth and Sudarshan
Keys
 A super key of an entity set is a set of one or more attributes
whose values uniquely identify each entity.
 A candidate key of an entity set is a minimal super key
 customer-id is candidate key of customer
 account-number is candidate key of account
 Although several candidate keys may exist, one of the
candidate keys is selected to be the primary key.
 All others are referred to as secondary keys
 Later we will also discuss foreign keys and search keys.
Database System Concepts
6.27
©Silberschatz, Korth and Sudarshan
Other Examples of Keys
 Student = (SS#, Name, Date-of-Birth, Status)
SS#
- Super key and candidate key
SS#, Name, DOB
- Super key, but not candidate key
SS#, Status
- Super key, but not candidate key
Name
- Neither
 Payment = (Payment#, Loan#, Date-Made, ID#)
Database System Concepts
ID#
- Super key, and candidate key
Payment#, Loan#
- Super key, and candidate key
ID#, Date-Made
- Super key, but not candidate key
Date
- Neither
6.28
©Silberschatz, Korth and Sudarshan
Keys in an ER Diagram
 A primary key of an entity set is specified in an ER diagram by
underlining the key attributes.
Database System Concepts
6.29
©Silberschatz, Korth and Sudarshan
Keys for Relationship Sets
 The combination of primary keys of the participating entity sets
forms a super key of a relationship set.
 (customer-id, account-number) is the super key of depositor
• Notes:
– This reflects the fact that a pair of entity sets can have at
most one relationship in a particular relationship set.
– If we wish to track all access-dates to each account by each
customer, we cannot assume a relationship for each access.
For this we could use a multi-valued attribute, however.
 Question: why primary and super in the above?
 The mapping cardinality of a relationship set will determine, in
part, what the candidate keys of the relationship set are.
Database System Concepts
6.30
©Silberschatz, Korth and Sudarshan
Design Issues
 Use of entity sets vs. attributes
 Is Telephone-Number an attribute or an entity set?
 Choice mainly depends on the structure of the enterprise being modeled, and
on the semantics/meaning associated with the attribute in question.
 Use of entity sets vs. relationship sets
 Is Loan an entity set or a relationship set?
 Possible guideline is to designate a relationship set to describe an action that
occurs between entities
 Binary versus n-ary relationship sets
 E.g., Family, as opposed to mother, father, brother, sister
 Although it is possible to replace any nonbinary (n-ary, for n > 2) relationship set
by a number of distinct binary relationship sets, a n-ary relationship set shows
more clearly that several entities participate in a single relationship.
 Placement of relationship attributes
Database System Concepts
6.31
©Silberschatz, Korth and Sudarshan
How about doing an ER design
interactively on the board?
Suggest an application to be modeled.
Weak Entity Sets
 An entity set that has a primary key is referred to as a strong
entity set.
 An entity set that does not have a primary key is referred to as a
weak entity set.
 A weak entity set is typically associated with an identifying entity
set (which is usually strong) via a total, one-to-many relationship.
Database System Concepts
6.33
©Silberschatz, Korth and Sudarshan
Weak Entity Sets, Cont.
 The discriminator (or partial key) of a weak entity set is the set of
attributes that distinguishes among all entities of the weak entity
set associated with one identifying entity.
 The primary key of a weak entity set has two parts:
 The primary key of the associated identifying entity set
 The weak entity set’s discriminator
Database System Concepts
6.34
©Silberschatz, Korth and Sudarshan
Weak Entity Sets (Cont.)
 A weak entity set is represented by double rectangles.
 The discriminator is underlined with a dashed line.
 Primary key for payment – (loan-number, payment-number)
Database System Concepts
6.35
©Silberschatz, Korth and Sudarshan
Weak Entity Sets (Cont.)
 Note: the primary key of the strong entity set is not explicitly
specified in the weak entity set, since it is implicit in the
identifying relationship.
 If loan-number were explicitly specified:
 Payment would be a strong entity set
 The nature of the relationship between payment and loan would not
be as clear
Database System Concepts
6.36
©Silberschatz, Korth and Sudarshan
More Weak Entity Set Examples
 In a university, a course is a strong entity and a course-offering can be
modeled as a weak entity.
Course = (course-number, name, description)
Course-offering = (semester, section-number, instructor)
 The discriminator of course-offering would be semester (including year)
and section-number (if there is more than one section).
 If course-offering were modeled as a strong entity then it would have
course-number as an attribute.
 The relationship with course would then be implicit in the course-number
attribute.
Database System Concepts
6.37
©Silberschatz, Korth and Sudarshan
Specialization and
Generalization Example
Database System Concepts
6.38
©Silberschatz, Korth and Sudarshan
Specialization
 Top-down design process; we designate sub-groupings within an entity
set that are distinctive from other entities in the set.
 These sub-groupings are referred to as lower-level entity sets.
 The lower-level entity sets may:
 Have attributes that do not apply to the higher-level entity set.
 Participate in relationships that do not apply to the higher-level entity set.
 A lower-level entity set is said to inherit all the attributes and relationships
from the higher-level entity set to which it is linked.
 Depicted by a triangle component labeled ISA (E.g. customer “is a”
person).
Database System Concepts
6.39
©Silberschatz, Korth and Sudarshan
Generalization
 A bottom-up design process – combine a number of entity sets
that share the same features into a higher-level entity set.
 Specialization and generalization are simple inversions of each
other; they are represented in an E-R diagram in the same way.
 The terms specialization and generalization are used
interchangeably.
 The ISA relationship also referred to as a superclass-subclass
relationship.
Database System Concepts
6.40
©Silberschatz, Korth and Sudarshan
Specialization
and Generalization, Cont.
 Multiple specializations of an entity set based on different features
are possible.
 permanent-employee vs. temporary-employee
 In addition to officer vs. secretary vs. teller
 Each particular employee would be a member of:
 One of permanent-employee or temporary-employee, and
 One of officer, secretary, or teller
Database System Concepts
6.41
©Silberschatz, Korth and Sudarshan
Design Constraints on
Specialization/Generalization
 In a specialization/generalization relationship:
 If an entity can belong to at most one lower-level entity set then
that relationship is said to be disjoint.
 If an entity can belong to more than one lower-level entity set
then that relationship is said to be overlapping.
 If an entity must belong to one of the lower-level entity sets then
that relationship is said to be total.
 If an entity need not belong to one of the lower-level entity sets
then that relationship is said to be partial.
 The above could be noted in any number of ways on the
diagram, e.g., by writing “disjoint” next to the relationship.
Database System Concepts
6.42
©Silberschatz, Korth and Sudarshan
Design Issues
 Now, there are even more design options:
 The use of a strong or weak entity set.
 The use of specialization/generalization.
Database System Concepts
6.43
©Silberschatz, Korth and Sudarshan
E-R Diagram
for a Banking Enterprise
Database System Concepts
6.44
©Silberschatz, Korth and Sudarshan
Summary of Symbols
Used in E-R Notation
Database System Concepts
6.45
©Silberschatz, Korth and Sudarshan
Summary of Symbols (Cont.)
Database System Concepts
6.46
©Silberschatz, Korth and Sudarshan
Alternative E-R Notations
Database System Concepts
6.47
©Silberschatz, Korth and Sudarshan
UML
 UML: Unified Modeling Language
 UML has many components to graphically model different
aspects of an entire software system
 UML Class Diagrams correspond to E-R Diagram, but several
differences.
Database System Concepts
6.48
©Silberschatz, Korth and Sudarshan
Summary of UML Class Diagram Notation
Database System Concepts
6.49
©Silberschatz, Korth and Sudarshan
UML Class Diagrams (Contd.)
 Entity sets are shown as boxes, and attributes are shown within the
box, rather than as separate ellipses in E-R diagrams.
 Binary relationship sets are represented in UML by just drawing a
line connecting the entity sets. The relationship set name is written
adjacent to the line.
 The role played by an entity set in a relationship set may also be
specified by writing the role name on the line, adjacent to the entity
set.
 The relationship set name may alternatively be written in a box,
along with attributes of the relationship set, and the box is
connected, using a dotted line, to the line depicting the relationship
set.

Non-binary relationships drawn using diamonds, just as in ER
diagrams
Database System Concepts
6.50
©Silberschatz, Korth and Sudarshan
UML Class Diagram Notation (Cont.)
overlapping
disjoint
*Note reversal of position in cardinality constraint depiction
*Generalization can use merged or separate arrows independent
of disjoint/overlapping
Database System Concepts
6.51
©Silberschatz, Korth and Sudarshan
UML Class Diagrams (Contd.)
 Cardinality constraints are specified in the form l..h, where l denotes
the minimum and h the maximum number of relationships an entity
can participate in.
 Beware: the positioning of the constraints is exactly the reverse of the
positioning of constraints in E-R diagrams.
 The constraint 0..* on the E2 side and 0..1 on the E1 side means that
each E2 entity can participate in at most one relationship, whereas
each E1 entity can participate in many relationships; in other words,
the relationship is many to one from E2 to E1.
 Single values, such as 1 or * may be written on edges; The single
value 1 on an edge is treated as equivalent to 1..1, while * is
equivalent to 0..*.
Database System Concepts
6.52
©Silberschatz, Korth and Sudarshan
Reduction of
an E-R Schema to Tables
 An E-R diagram can be converted to a collection of
tables, i.e., a relational database.
 Each entity set is converted to its’ own table.
 Each relationship set can be (but may or may not be)
converted to its’ own table.
 Each table has a number of columns, which generally
corresponding to the attributes in the corresponding entity
or relationship set.
Database System Concepts
6.53
©Silberschatz, Korth and Sudarshan
Representing Entity Sets as Tables
 A strong entity set reduces to a table with the same attributes.
Database System Concepts
6.54
©Silberschatz, Korth and Sudarshan
Composite and
Multi-valued Attributes
 Composite attributes are broken up:
 Example: attribute name with components first-name and last-name becomes two
attributes in the corresponding table: name.first-name and name.last-name.
 A multi-valued attribute M of entity E is represented by a new table with the
following attributes:
 The primary key of E
 An attribute corresponding to multi-valued attribute M
 Example:
Entity Set:
employee with attributes id#, name, phone#, dependents
Tables:
employee (id#, name, phone#)
dependent (id#, dname)
Database System Concepts
6.55
©Silberschatz, Korth and Sudarshan
Representing Weak Entity Sets
 A weak entity set becomes a table that includes a column for
the primary key of the identifying strong entity set.
Database System Concepts
6.56
©Silberschatz, Korth and Sudarshan
Representing Relationship
Sets as Tables
 A many-to-many relationship set is represented as a table with
columns for the primary keys of the two participating entity sets,
and any descriptive attributes of the relationship set.
 Example: for the borrower relationship set:
Database System Concepts
6.57
©Silberschatz, Korth and Sudarshan
Representing Relationship
Sets as Tables, cont.
 A Many-to-one relationship set can be represented just like a
many-to-many relationship.
 Technically this is not necessary, and in some cases it does
not result in a good design.
 Example:
Entity Sets:
account with attributes account-number, balance
branch with attributes branch-name, branch-city, assets
Relationship Set (total, many-to-one from account to branch):
account-branch with attributes account-number,
branch-name
Database System Concepts
6.58
©Silberschatz, Korth and Sudarshan
Representing Relationship
Sets as Tables, cont.
 The preceding could be converted to tables directly, or as
follows:
account (account-number, balance, branch-name)
branch (branch-name, branch-city, assets)
 Since the above relationship is total, a distinct table for the
relationship set is probably not necessary.
Database System Concepts
6.59
©Silberschatz, Korth and Sudarshan
Representing Relationship
Sets as Tables, cont.
 For one-to-one relationship sets, the extra attribute can be added
to either of the tables corresponding to the two entity sets.
 Similarly, other relationship attributes would be treated similarly.
 Note that either of the above could introduce null values if the
relationship is not total.
Database System Concepts
6.60
©Silberschatz, Korth and Sudarshan
Representing Specialization
as Tables
 Note: This discussion assumes a 2-level inheritance hierarchy.
 Exercise: Generalize it to an arbitrarily deep hierarchy.
 Method 1:
 Form a table for the higher level entity set.
 Form a table for each lower level entity set, including the primary key of
the higher level entity set and local attributes.
table
attributes
person
name, street, city
customer
name, credit-rating
employee
name, salary
 One Drawback: getting information about specific entities requires
accessing two tables
Database System Concepts
6.61
©Silberschatz, Korth and Sudarshan
Representing Specialization
as Tables cont.
 Method 2:
 Form a table for each entity set with all local and inherited attributes
table
table attributes
person
name, street, city
customer
name, street, city, credit-rating
employee
name, street, city, salary
 This method can be redundant:
 Some duplication for persons who are both customers and employees.
 If specialization is total, the table for the generalized entity is redundant.
• Explicit table may still be needed for foreign key constraints.
• For convenience, the generalized entity can an be defined as a “view”
relation containing union of specialization tables.
Database System Concepts
6.62
©Silberschatz, Korth and Sudarshan
Representing Specialization
as Tables
 Method 3: (not presented in the book)
 Form one table for the higher level entity set
 This table has one column for every attribute in every subclass.
table
attributes
person
name, street, city, credit-rating, salary
 Optionally, include a type attribute that indicates which subclass the stored
entity belongs to.
 One Drawback: Contains multiple nullable attributes.
 Sometimes referred to as a “junk drawer”
Database System Concepts
6.63
©Silberschatz, Korth and Sudarshan
Process Issues
 The book also defines the following (software
engineering steps):
 Specification of user requirements
 Conceptual design
 Specification of functional requirements
 Logical design
 Physical design
 These development/design steps, i.e., the process,
is typically company specific.
Database System Concepts
6.64
©Silberschatz, Korth and Sudarshan
End of Chapter 6
E-R Diagram with a Ternary Relationship
Database System Concepts
6.66
©Silberschatz, Korth and Sudarshan
Cardinality Constraints
on Ternary Relationship Sets
 We allow at most one arrow out of a ternary (or greater degree)
relationship to indicate a cardinality constraint
 An arrow from works-on to job indicates each employee works on at
most one job at any branch.
 If there is more than one arrow, there are two ways of defining the
meaning.
 E.g a ternary relationship R between A, B and C with arrows to B and C
could mean
 1. each A entity is associated with a unique entity from B and C or
 2. each pair of entities from (A, B) is associated with a unique C entity,
and each pair (A, C) is associated with a unique B
 Each alternative has been used in different formalisms
 To avoid confusion we outlaw more than one arrow
Database System Concepts
6.67
©Silberschatz, Korth and Sudarshan
Binary Vs. Non-Binary Relationships
 Some relationships that appear to be non-binary may be better
represented using binary relationships
 E.g. A ternary relationship parents, relating a child to his/her father and
mother, is best replaced by two binary relationships, father and mother
• Using two binary relationships allows partial information (e.g. only
mother being know)
 But there are some relationships that are naturally non-binary
• E.g. works-on
Database System Concepts
6.68
©Silberschatz, Korth and Sudarshan
Converting Non-Binary Relationships to Binary
Form
 In general, any non-binary relationship can be represented using binary
relationships 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. RA, relating E and A
3. RC, relating E and C
2.RB, relating E and B
 Create a special identifying attribute for E
 Add any attributes of R to E
 For each relationship (ai , bi , ci) in R, create
1. a new entity ei in the entity set E
3. add (ei , bi ) to RB
Database System Concepts
6.69
2. add (ei , ai ) to RA
4. add (ei , ci ) to RC
©Silberschatz, Korth and Sudarshan
Converting Non-Binary
Relationships, Cont.
 Also need to translate constraints
 Translating all constraints may not be possible
 There may be instances in the translated schema that
cannot correspond to any instance of R
• Exercise: add constraints to the relationships RA, RB and RC to
ensure that a newly created entity corresponds to exactly one entity
in each of entity sets A, B and C
 We can avoid creating an identifying attribute by making E a weak
entity set (described shortly) identified by the three relationship sets
Database System Concepts
6.70
©Silberschatz, Korth and Sudarshan
E-R Diagram for Exercise 2.10
Database System Concepts
6.71
©Silberschatz, Korth and Sudarshan
E-R Diagram for Exercise 2.15
Database System Concepts
6.72
©Silberschatz, Korth and Sudarshan
E-R Diagram for Exercise 2.22
Database System Concepts
6.73
©Silberschatz, Korth and Sudarshan
E-R Diagram for Exercise 2.15
Database System Concepts
6.74
©Silberschatz, Korth and Sudarshan
Existence Dependencies
 If the existence of entity x depends on the existence of
entity y, then x is said to be existence dependent on y.
 y is a dominant entity (in example below, loan)
 x is a subordinate entity (in example below, payment)
loan
loan-payment
payment
If a loan entity is deleted, then all its associated payment entities
must be deleted also.
Database System Concepts
6.75
©Silberschatz, Korth and Sudarshan
Aggregation
 Consider the ternary relationship works-on, which we saw earlier
 Suppose we want to record managers for tasks performed by an
employee at a branch
Database System Concepts
6.76
©Silberschatz, Korth and Sudarshan
Aggregation (Cont.)
 Relationship sets works-on and manages represent overlapping
information
 Every manages relationship corresponds to a works-on relationship
 However, some works-on relationships may not correspond to any
manages relationships
• So we can’t discard the works-on relationship
 Eliminate this redundancy via aggregation
 Treat relationship as an abstract entity
 Allows relationships between relationships
 Abstraction of relationship into new entity
Database System Concepts
6.77
©Silberschatz, Korth and Sudarshan
Aggregation (Cont.)
 Without introducing redundancy, the following diagram represents:
 An employee works on a particular job at a particular branch
 An employee, branch, job combination may (or may not) have an
associated manager
Database System Concepts
6.78
©Silberschatz, Korth and Sudarshan
E-R Diagram With Aggregation
Database System Concepts
6.79
©Silberschatz, Korth and Sudarshan
Relations Corresponding to
Aggregation
 To represent aggregation, create a table containing
 The primary key of the aggregated relationship,
 The primary key of the associated entity set
 Any descriptive attributes
Database System Concepts
6.80
©Silberschatz, Korth and Sudarshan
Relations Corresponding to
Aggregation (Cont.)
 Example: to represent aggregation manages between relationship works-
on and entity set manager, create a table:
manages(employee-id, branch-name, title, manager-name)
 Note: manager-name may be null.
 If this is acceptable, then table works-on is not required.
Database System Concepts
6.81
©Silberschatz, Korth and Sudarshan