Transcript 沒有投影片標題 - Tunghai University

Chapter 4
Enhanced Entity-Relationship and Object Modeling
4.1 Subclasses, Superclasses, and Inheritance
4.2 Specialization and Generalization
4.3 Constraints and Characteristics of Specialization and Generalization
4.4 Modeling of UNION Types Using Categories
4.5 An Example UNIVERSITY EER Schema and Formal Definitions
for the EER Model
4.6 Conceptual Object Modeling Using UML Class Diagrams
4.7 Relationship Types of Degree Higher Than Two
4.8 Data Abstraction and Knowledge Representation Concepts
4.9 Summary
4-1
database applications
• traditional
– database processing applications in business and
industry
• newer applications
–
–
–
–
–
–
–
–
–
CAD/CAM
telecommunications
images and graphics
multimedia
data mining
data warehousing
GIS
databases for indexing the World Wide Web
...
4-2
Enhanced ER (EER) model
•
•
•
•
•
•
modeling concepts of the ER model
subclass and superclass (type inheritance)
specialization and generalization (constraints)
category (UNION)
attribute and relationship inheritance
UNIVERSITY database in EER model
4-3
subclass
attributes
relationships
• entity type (a type of entity)
– e.g., EMPLOYEE
• entity set (collection of entities of that type)
– e.g., current set of EMPLOYEE entities
• subclass (vs superclass)
– e.g., SECRETARY, ENGINEER, TECHNICIAN,
MANAGER, SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE
‧An entity must also be a member
• class/subclass relationship
of the superclass
‧An entity can be a member of any
– e.g., EMPLOYEE/SECRETARY number of subclasses
‧It is not necessary that every
entity in a superclass be a member
of some subclasses.
4-4
subclass (continued)
• Implementation
– A member entity of the subclass represents the
same real-world entity as some member of the
superclass
the same entity but in specific role
– A distinct record that is related via the key
attribute to its superclass entity
• type inheritance
Besides specific (or local) attributes
and relationships,
– An entity that is a member of a subclass inherits
all the attributes of the entity as a member of the
superclass
– The entity also inherits all the relationships in
which the superclass participates
4-5
Specialization and Generalization
• specialization
– define a set of subclasses of an entity type
superclass
– {SECRETARY, ENGINEER, TECHNICIAN}
is a specialization of EMPLOYEE by job type
– {SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE} is a specialization of
EMPLOYEE by method of pay
• notation in EER diagram
4-6
Figure 4.1 EER diagram for representing specialization an d subclasses.
FName
Minit
LName
Name
Ssn
BirthDate
Address
EMPLOYEE
specific
(local)
attributes
completeness constraint:
completeness constraint :
partial specialization
total specialization
subset
symbol
Typing Speed
SECRETARY
disjointness
constraint
d
TGrade
TECHNICIAN
subset
symbol
subset
symbol
EngType
ENGINEER
disjointness
specific
constraint
disjoint
d
attributes
MANAGER
Pay Scale
Salary
HOURLY_EMPLOYEE
SALARIED_EMPLOYEE
MANAGES
Three specializations of EMPLOYEE:
PROJECT
(SECRETARY, TECHNICIAN, ENGINEER)
(MANAGER)
(HOURLY_EMPLOYEE, SALARIED_EMPLOYEE)
specific
relationship
BELONGS_TO
specific
relationship
TRADE_UNION
4-7
SECRETARY
.e
.e
.e
EMPLOYEE
e1
e2
e3
e4
e5
e6
e7
e8
.
.
.
.
.
.
.
.
1
4
5
ENGINEER
.e
.e
2
7
TECHNICIAN
Figure 4.2 Some instances of the spcialization of EMPLOYEE
into the {SECRERARY, ENGINEER, TECHNICIAN}
set of subclasses.
superclass/subclass relationship: 1:1 relationship
at the instance level
.e
.e
3
8
same entity in specialized role
4-8
Why including class/subclass
relationships?
• Certain attributes may apply to some but not all
entities of the superclass
– SECRETARY (attribute TypingSpeed)
– ENGINEER (attribute EngineerType)
• Some relationship types may be participated in
only by entities that are members of the subclass
– HOURLY_EMPLOYEE belongs to a trade
union 工會
4-9
Specialization process
• Define a set of subclasses of an entity type
• Establish additional specific attributes with
each class
• Establish additional specific relationship
types between subclass and other entity
types or other subclasses
4-10
Generalization
• Define a generalized entity type from the
given entity
types
subclass
– {CAR, TRUCK} as a specialization of
VEHICLE generalized superclass
– VEHICLE as a generalization of CAR and
TRUCK
alternative
generalization
VEHICLE
CAR
VEHICLE
TRUCK
CAR
specialization
TRUCK
4-11
(a)
NoOfAxles
NoOfPassengers
Price
Price
MaxSpeed
Tonnage
CAR
Vehicleld
TRUCK
LicensePlateNO
(b)
LicensePlateNo
Price
Vehicleld
NoOfPassengers
v1
v2
v3
v4
v5
VEHICLE
d
MaxSpeed
CAR
v1 v1
v2 v2
Vehicleld
v3 v3
v4 v4
v5 v5
LicensePlateNO
v1
v2
v3
v4
v5
v6
v7
NoOfAxles
Tonnage
TRUCK
Figure 4.3 Examples of generalization. (a) Two entity types CAR and TRUCK.
(b) Generalizing CAR and TRUCK into VEHICLE.
4-12
Constraints on
Specialization and Generalization
• single subclass only
– {MANAGER} specification
• predicate-defined subclasses
(condition-defined)
– determined by a condition
EMPLOYEE

MANAGER
– (JobType = ‘Secretary’) <--- defining predicate
– attribute-defined specialization
(see Figure 4.4 at 4-14)
• membership condition on the same attribute of the superclass (defining
attribute)
• user-defined subclass
Membership is specified
– determined by the database users individually for each entity.
– {HOURLY_EMPLOYEE, SALARIED_EMPLOYEE}
4-13
FName
Minit
LName
Name
Ssn
BirthDate
Address
JobType
EMPLOYEE
Job Type
defining attribute
d
“Secretary”
Typing Speed
“Engineer”
“Technician”
SECRETARY
TGrade
TECHNICIAN
predicate condition
EngType
ENGINEER
Figure 4.4 Attribute-defined specialization on the JobType attribute of EMPLOYEE
4-14
Constraints (continued)
• disjointness constraint
– an entity can be a member of at most one of the
subclasses of the specialization
– attribute-defined specialization -->
defining attribute is singled-valued
– d : disjoint for attribute/user-defined subclass
– o : an entity may be a member of more than
one subclass of a specialization
4-15
PartNo
Description
PART
o
ManufactureDate
DrawingNo
overlap
SupplierName
BatchNo
MANUFACTURED_PART
ListPrice
PURCHASED_PART
Figure 4.5 Specialization with nondisjoint (overlapping) subclasses.
4-16
Constraints (continued)
• completeness constraint
(4-7)
– total specialization constraint
• every entity in the superclass must be a member of some
subclass in the specialization
• e.g., {HOURLY_EMPLOYEE, SALARIED_EMPLOYEE}
• notation: superclass
– partial specialization constraint
• an entity may not belong to any of the subclasses
• e.g., {SECRETARY, ENGINEER, TECHNICIAN}
4-17
Constraints (continued)
• disjointness and completeness constraints are
independent
–
–
–
–
Disjoint, total
Disjoint, partial
Overlapping, total
Overlapping, partial
• a superclass identified through generalization
process usually is total
4-18
Some insertion/deletion rules for
specialization/generalization
• Deleting an entity from a superclass
– it is automatically deleted from all the subclasses to which it
belongs
• Inserting an entity in a superclass
– it is mandatorily inserted in all predicate-defined (or
attribute-defined) subclasses for which it satisfies the
defining predicate
• Inserting an entity in a superclass of a total
specialization
– it is mandatorily inserted in at lease one of subclasses
4-19
Specialization/Generalization
Hierarchies and Lattices
• A subclass itself may have further
subclasses specified on it.
– Specialization hierarchy
• every subclass participates as a subclass in only one
class/subclass relationship
– Specialization lattice
• a subclass can be a subclass in more than one
class/subclass relationship
4-20
Figure 4.6 Specialization lattice with the shared subclass EMGINEERING_MANAGER..
EMPLOYEE
e1
e2
e3
e4
e5
e6
e7
e8
e9
e10
d
SECRETARY
TECHNICIAN
ENGINEER
d
MANAGER
HOURLY_EMPLOYEE
e1
e2
e3
e4
e5
e6
e7
e8
e8
e9
SALARIED_EMPLOYEE
ENGINEERING_MANAGER
e8 shared subclass
multiple inheritance
lattice
e6
e7
e8
e9
e10
e1
e2
e3
e4
e5
4-21
Sex
Name
Figure 4.7 Specialization lattice for a
UNIVERSITY database.
SSN
Address
PERSON
P1
P2
P3
P4
P5
EMPLOYEE
P6
P7
P8
P9
P10
o
ALUMNUS
BirthDate
An entity may exist in several
leaf nodes of the hierarchy
e.g. GRADUATE_STUDENT
RESEARCH ASSISTANT
STUDENT
Degrees
Year
d
Degree
Major
d
Percent Time
STAFF
FACULTY
Position
STUDENT_
ASSISTANT
Rank
Project
GRADUATE_
STUDENT
shared subclass
multiple inheritance DegreeProgram
d
(inherited only once)
leaf node
UNDERGRADUATE_
STUDENT
Class
Course
RESEARCH_ASSISTANT
TEACHING_ASSISTANT
A subclass inherits attributes of all its predecessor superclasses
4-22
Specialization/Generalization
in Conceptual Data Modeling
• top-down conceptual refinement process
– a specialization process
• bottom-up conceptual synthesis
– a generalization process
• combination
4-23
union type (or category)
• a single superclass vs. more than one superclass
– ENGINEERING_MANAGER is a subclass in three distinct
superclass/subclass relationship (4-21)
– Each has single superclass
• union type or category
– model a single superclass/subclass relationship with more than
one superclass
– the subclass represents a collection of objects that is (a subset
of) the UNION of distinct entity types
– e.g., OWNER is a subclass of the UNION of (COMPANY,
BANK, PERSON)
4-24
BName
BAddress
BANK
SSN
Name
Address
DriverLicenseNo
PERSON
P1
P2
P3
P4
CName
b1
b2
b3
Figure 4.8 Two categories: OWNER
and REGISTERED_VEHICLE.
c1
c2
COMPANY
u
P1
P2
b1
c1
CAddress
set union operation
OWNER
LienOrRegular
PurchaseDate
M
OWNS
N
LicensePlateNo
REGISTERED_VEHICLE
CYear
CMake
CModel
CStyle
CAR
Vehicleld
c1
c2
c3
c1
c2
u t1
set
union
operation
TYear
TMake
TModel
Tonnage
TRUCK
t1
Vehicleld
4-25
category vs. shared subclass
• intersection
Only cars & trucks can be
members of
REGISTERED_VEHICLE
Category
REGISTERED_VEHICLE
VS.
Partial:
VEHICLE may contain
other types of entities
generalized superclass
VEHICLE
– shared subclass (Fig. 4.6, 4-21) (Fig. 4.8, 4.25)
(Fig. 4.3, 4-12)
– ENGINEERING_MANAGER is a subset of the intersection of
ENGINEER, MANAGER, and SALARIED_EMPLOYEE
– an engineering manager must be an ENGINEER, a MANAGER,
and a SALARIED_EMPLOYEE
– ENGINEERING_MANAGER inherits all the attributes of its
superclasses
• union
– category (Fig. 4.8, 4-25)
– OWNER is a subset of the union of COMPANY, a BANK, or a
person
– an OWNER may be a COMPANY, a BANK, or a PERSON
– an OWNER entity inherits the attributes depending on the
superclass to which the entity belongs
4-26
A category can be total or partial.
(a)
COMPANY
PERSON
c1
c2
c3
c4
C1
C2
P1
P2
Figure 4.9 Categories. (a) Partial category
ACCOUNT_HOLDER that is a
subset of the union of two entity
types COMPANY and PERSON.
(b) Total category PROPERTY
and a similar generalization.
predicate conditions
u
partial
c1
c2
P1
ACCOUNT_
HOLDER
HAS_
ACCT
BANK
(b)
BUILDING
total category
b1
b2
b3
LOT
specialization/
generalization
PROPERTY
l1
l2
total
d
u
total
b1 l1
b2 l2
b3
PROPERYT
BUILDING
LOT
4-27
An Example UNIVERSITY
EER Schema
4-28
FName
Minit
LName
Ssn
BDate
Name
Sex
No
Street
AptNo
PERSON
City
State
Zip
Address
d
FOffice
FPhone
Rank
Salary
FACULTY
Class
1
ADVISOR N
M
COMMITTEE
College
Degrees
GRAD_STUDENT
P1
Title
N
No
GRANT
Agency
StDate
Start
M
BELONGS
CHAIRS
Year
STUDENT
N
1
1
Degree
N
SUPPORT
u
M
Time
N
End
1
REGISTERED
MINOR
1
INSTRUCTOR_RESEARCHER
N
N
MAJOR
Grade
1
TRANSCRIPT
1
TEACH N
CURRENT_SECTION
N
Sec#
Year
Qtr
SECTION
DEPARTMENT
N
DName
N
COLLEGE
1
CD
DPhone
M
CS
Office
1
1
COURSE
DC
N
COffice
Dean
C#
CName
CName
Figure 4.10 ERR conceptual schema for a UNIVERSITY database
Cdesc
4-29
Formal Definitions
• class
– a set or collection of entities, including any of the EER
schema constructs that group entities such as entity
types, subclasses, superclasses, and categories
• subclass S
– a class whose entities must always be a subset of the
entities in another class C (superclass) of the
superclass/subclass relationship C/S
– SC
4-30
Formal Definitions
(continued)
• specialization Z = {S1, S2, …, Sn)
– a set of subclasses that have the same superclass G
– G/Si is a superclass/subclass relationship
generalized entity type
•
•
•
•
generalization
n
total  S i  G
i 1
disjoint S i  S j  
predicate-defined
partial (otherwise)
overlapping (otherwise)
user-defined (otherwise)
– a predicate p on the attributes of G is used to specify which
entries in G are members of S
4-31
Formal Definitions
(continued)
• specialization Z (generalization G) is attribute-defined
attribute
– a predicate (A=ci) is used to specify membership in each
subclass Si in Z
• category T
– a class that is a subset of the union of n defining superclasses
D1, D2, …, Dn
– T  (D1  D2  …  Dn)
T  ( D1 P1   D2 P2   ...  Dn Pn )
• relationship type: allow class to participate in a
relationship
4-32
Conceptual Object Modeling
Using UML Class Diagrams
• UML - Universal Modeling Language
• OMT - Object Modeling Technique
4-33
Multipicities
min..max (* : no maximum limit)
(relationship constraints)
class
name
attributes
composite
attributes
operations
association
(relationship types)
domain
link attribute
(relationship attribute)
role
qualified
aggregation
(identifying
relationship)
role
reflexive
association
(recursive
relationship)
multivalued
attribute
is modeled
a class
a relationship between a
whole object and its
component parts
4-33.1
4-34
generalization / specialization
overlapping
disjoint
4-33.2
4-35
Relationships of Higher Degree
• Relationship types of degree 2 are called binary
• Relationship types of degree 3 are called ternary
and of degree n are called n-ary
• In general, an n-ary relationship is not equivalent
to n-binary relationships
4-34
4-36
Ternary Relationship Types
(a)
SName
ProjName
Quantity
PROJECT
SUPPLY
SUPPLIER
PartNo
The ternary relationship type SUPPLY
PART
(b)
SName
ProjName
M
SUPPLIER
ternary relationship
(c)
PROJECT
M
USES
PartNo
PART
N
(s,p), (j,p), (s,j) --?--> (s, j, p)
<---SName
SUPPLIER
owner
N
M
CAN_SUPPLY
more informative
SUPPLIES
1
Some DB tools permit
only binary relationship.
SS
N
Three binary relationship types.
They are not equivalent to SUPPLY
Quantity
N
identifying
relationship
PartNo
SUPPLY
N
SP
1
ProjName
N
SPJ
1
PROJECT
owner
SUPPLY represented as a weak entity type
PART
owner
4-35
4-37
TAUGHT_DURING
Semester
Year
Sem_Year
IName
INSTRUCTOR
OFFERS
SEMESTER
CAN_TEACH
OFFERED_DURING
CNumber
COURSE
Another example of ternary
versus binary relationship types.
(i,s,c) -----> (i,s), (s,c), (i,c)
<--?-- (i,s), (s,c), (i,c)
<----- (i,s), (s,c), (i,c) + CAN_TEACH (1:1)
Name
CName
CCI
CANDIDATE
Department
COMPANY
A weak entity type INTERVIEW,
with a ternary identifying relationship type.
Date
Dept/Date
INTERVIEW
RESULTS_IN
JOB_OFFER
The weak entity type
has two owner entity types.
4-36
4-38