1. Database
EER

2. Extended E-R Model
E-R model is sufficient for traditional database applications
Nontraditional applications (CAD, multimedia) have more complex requirements
Can extend traditional E-R diagrams with semantic data modeling concepts

3. Inheritance

4. EER IsA Notation Phone Name PERSON IsA STUDENT PROFESSOR ID Major
Class
Dept
Office

5. Specialization & Generalization
process of taking an entity and creating several specialized subclasses Top down design
Generalization
process of taking several related entities and creating a general superclass
Bottom up design
We will talk mainly of specialization, but most information will also apply to generalization

6. Extended E-R Features: Specialization
Top-down design process; we designate subgroupings within an entity set that are distinctive from other entities in the set.
These subgroupings become lower-level entity sets that have attributes or participate in relationships that do not apply to the higher-level entity set.
Depicted by a triangle component labeled ISA (E.g. customer “is a” person).
Attribute inheritance – a lower-level entity set inherits all the attributes and relationship participation of the higher-level entity set to which it is linked.

7. Specialization Example

8. Extended ER Features: 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.

9. Design Constraints on a Specialization/Generalization
Constraint on which entities can be members of a given lower-level entity set.
condition-defined
Example: all customers over 65 years are members of senior-citizen entity set; senior-citizen ISA person.
user-defined
Constraint on whether or not entities may belong to more than one lower-level entity set within a single generalization.
Disjoint
an entity can belong to only one lower-level entity set
Noted in E-R diagram by writing disjoint next to the ISA triangle
Overlapping
an entity can belong to more than one lower-level entity set

10. Non-disjoint, Non-covering
Every A can also be a B or a C, or both, or neither A
IsA B C o A B C

11. Disjoint, Non-covering
Every A can also be a B or a C or but not both A
IsA B C d A B C
disjoint

12. IS-A Relationship (cont’d)
Name
S.I.N.
Employee d
Staff
Teaching Assistant
Faculty
Position
Rank
Student #

13. Disjointness constraint
Specifies that an entity can be a member of at most one subclass
There can be no overlap between the subclasses
We use the notation of a d in a circle to symbolize that the subclasses are disjoint

14. Predicate-defined subclass
Pension
Plan Type
S.I.N.
Employee
Note: not all
employees included d
Staff
Faculty
Rank
Position

15. Attribute-defined subclass
S.I.N.
Jobtype
Employee
Jobtype d
“Faculty”
“Staff”
“Student”
Students
Faculty
Staff
Rank
Year
Rank

16. Overlap Entities are able to belong to more than one subclass
Notation is an o inside of a circle

17. Disjoint Constraints
Disjoint constraint when an entity can be a member of only one of the subclasses of the specialization.
STAFF d
FULL-TIME
STAFF
PART-TIME
STAFF
Hourly-rate
salary

18. Overlap S.I.N. Employee Jobtype A staff member may also be a student o
Faculty
Staff
Students
Rank
Rank
Year

19. Specialization constraints
Specializations can be predicate-defined or attribute-defined (otherwise called user-defined)
Disjointness constraint – specialization is disjoint or overlapping
Completeness constraint – specialization is total or partial

20. Design Constraints on a Specialization/Generalization (Cont.)
Completeness constraint -- specifies whether or not an entity in the higher-level entity set must belong to at least one of the lower-level entity sets within a generalization.
total : an entity must belong to one of the lower-level entity sets
partial: an entity need not belong to one of the lower-level entity sets

21. Completeness Constraint
May be total or partial
for total, every entity in the superclass must belong to a subclass
for partial, entities in the superclass do not need to be part of any subclass
notation for total and partial are the same as in a regular E-R diagram – single and double lines

22. Participation Constraints
Mandatory (total) participation where every member in the superclass must also be a member of a subclass.
STAFF
FULL-TIME
STAFF
PART-TIME
STAFF
Hourly-rate
salary

23. Participation Constraints
Optional (partial) participation where a member in the superclass need not belong to any of its subclasses.
STAFF
MANAGER
SECRETARY
SALES
PERSONNEL

24. Partial S.I.N. Jobtype Employee o Faculty Staff Students Rank Rank
Year

25. Total
S.I.N.
Employee
Jobtype o
Staff
Students
Faculty
Rank
Rank
Year

26. Hierarchies and Lattices
a tree-like structure where each subclass belongs to only one superclass
everything we have seen so far is a hierarchy
Lattices
a graph-like structure where a subclass can belong to more than one superclass

27. Lattice name Person student # Employee Student salary course
Teaching Assistant

28. EXample

30. Example

32. Aggregation
Represents a “part-of” relationship between entity types, where one represents the ‘whole’ and the other the ‘part’.
No inherited attributes; each entity has its own unique set of attributes.

33. 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

34. 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
Without introducing redundancy, the following diagram represents:
An employee works on a particular job at a particular branch
An employee, branch, job combination may have an associated manager

35. E-R Diagram With Aggregation

36. Aggregation
TEAM
MEMBER

37. ER Notation

38. Summary of Symbols (Cont.)

39. E-R Diagram for a Banking Enterprise

40. Case Study Design a DB consistent with the following facts.
Trains are either local trains or express trains, but never both.
A train has a unique number and an engineer.
Stations are either express stops or local stops, but never both.
A station has a unique name and an address.
All local trains stop at all stations.
Express trains stop only at express stations.
For each train and each station the train stops at, there is a time. 13

41. Design 1: bad
number
type
time
name
addr
StopsAt
trains
stations
engineer
type
Problem: does not capture the constraints that express trains only stop only at express stations and local trains stop at all local stations 15

42. Design 2: good number engineer train time name address ISA StopsAt2
local trains
stations
ISA
express trains
time
StopsAt1
express stations
local stations 16