[go: up one dir, main page]

0% found this document useful (0 votes)
217 views4 pages

Specialization and Generalization Lattices and Hierarchies

Download as doc, pdf, or txt
Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1/ 4

Specialization and Generalization Lattices and Hierarchies

A specialization may be a subclass, and also have a subclass specified on it.


For example, in the figure above, Engineer is a subclass of Employee, but also a
super class of Engineering Manager.
This means that every Engineering Manager, must also be an Engineer.
Specialization Hierarchy has the constraint that every subclass participates as a
subclass in only one classsubclass relationship, i.e. that each subclass has only
one parent. This results in a tree structure.
Specialization Lattice has the constraint that a subclass can be a subclass of
more than one classsubclass relationship. The figure sho!n above is a
specialization lattice, because Engineering"Manager participates has more than
one parent classes.
#n a lattice or hierarchy, the subclass inherits the attributes not only of the direct
superclass, but also all of the predecessor super classes all the !ay to the root.
A subclass !ith more than one super class is called a shared subclass. This leads
to multiple inheritance, !here a subclass inherits attributes from multiple classes.
#n a lattice, !hen a superclass inherits attributes from more than one superclass,
and some attributes are inherited more than once via different paths $i.e. Engineer,
Manager and %alaried Employee all inherit from Employee, that are then inherited
by Engineering Manager.
#n this situation, the attributes are included only once in the subclass.
Modeling Union Types using Categories
#n the subclass&superclass relationship types !e have seen so far, each has a single
superclass.
Employee
%ecretary Technician Engineer Manager %alaried"Emp 'ourly Emp
Engineering Manager
d d
This means that in a particular subclasssuper class relationship $Engineer,
Engineering Manager( even though the subclass has more than one subclasssuper
class relationship, each relationship is bet!een a single super class and subclass.
There are situations !hen you !ould li)e to model a relationship !here a single
subclass has more than one super class, and !here each super class represents a
different entity type.
The subclass !ill represent a collection of ob*ects that is a subset of the +,#-,
of the distinct entity types.
This type of subclass is a union type, or category subclass.
See Text Example, page 99.
A category has t!o or more super classes that may be distinct entity types, !here
other super classsubclass relationships have only one super class.
#f !e compare the Engineering Manager subclass, it is a sub class of each of the
three super classes, Engineer, Manager and %alaried employee, and inherits the
attributes of all three. An entity that exists in Engineering Manager exists in all
three super classes. This represents the constraint that an Engineering Manager
must be an Engineer, a Manager, A,. a %alaried Employee. #t can be thought of
as an A,. condition.
/y contrast, a category is a union of its subclasses. This means that an entity that
is a subclass of a union, exists in -,01 -,E of the super classes. An o!ner may
be a 2ompany, -3 a /an) -3 a 4E3%-,, but not more than one.
A category can be partial or total. A total category holds the union of A00 its
super classes, !here a partial category can hold a subset of the union.
#f a category is total, it can also be represented as a total specialization.
Comparison of Registered Vehicle
Category to Vehicle
5.
6.
The first example implies that every car and truc) is also a vehicle. #n the second
example, a registered vehicle can be a car or a truc), but every car and truc) is not
a registered vehicle.
-ther examples7
+niversity $3esearcher(

8ehicle
2ar Truc)
d
3egistered"8ehicle
2ar Truc)
u
Example 9.65
.esign a database to )eep trac) of information for an art museum. Assume that the
follo!ing re:uirements !ere collected.
The museum has a collection of A3T"-/;E2T% . Each art ob*ect has a uni:ue
#.,o, and Artist, if )no!n, a 1ear $!hen created, if )no!n( a Title and a
.escription. The art ob*ects are categorized in several !ays, as discussed belo!.
A3T"-/;E2T% are categorized based on types. There are three main types,
4ainting, %culpture and %tatue, plus an <-ther= category for those that don=t fit
into one of the categories above.
A 4A#,T#,> has a 4aintType $oil, !atercolor, etc( a material on !hich it is
2ra!n-n $paper, canvas, !ood( and %tyle $modern, abstract etc(
A %2+04T+3E or a %TAT+E has a Material from !hich it !as created $!ood,
stone, etc( 'eight, ?eight and %tyle.
An art ob*ect in the -T'E3 category has a Type$print, photo, etc( and %tyle.
A3T"-/;E2T% are also categorized as 4E3MA,E,T"2-00E2T#-,, !hich
are o!ned by the museum $.ateAc:uired, !hether it is -n.isplay or %tored and
2ost( or /-33-?E., !hich has information on the 2ollection $!here it !as
borro!ed from(, .ate/orro!ed, and .ate3eturned.
A3T"-/;E2T% also have information describing their country&culture using
information on countryculture of -rigin $#talian, Egyptial, American, #ndian etc(
and 4eriod$3enaissance, Modern, Ancient(
The museum )eeps trac) of A3T#%T%=s information, if )no!n7 ,ame, .ate/orn,
.ate.ied, 2ountry-f-rigin, 4eriod, Main%tyle and .escription. The name is
assumed uni:ue.
.ifferent E@'#/#T#-,% occur, each having a ,ame, %tart.ate and End.ate.
E@'#/#T#-,% are related to all the art ob*ects that !ere on display during the
exhibition.
#nformation is )ept on other 2-00E2T#-,% !ith !hich the museum interacts,
including ,ame $uni:ue(, Type $museum, personnel etc(, .escription, Address,
4hone and 2ontact4erson.
.ra! an EE3 schema for this application. 3ecord any assymptions you ma)e.

You might also like