Specialization and Generalization Lattices and Hierarchies: Modelling and Examples for AFCAT

Glide to success with Doorsteptutor material for UGC : Get detailed illustrated notes covering entire syllabus: point-by-point for high retention.

Download PDF of This Page (Size: 146K)

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

Specialization and Generalization

Specialization and Generalization

  • 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 class/subclass 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 class/subclass relationship. The figure shown above is a specialization lattice, because Engineering Manager participates has more than one parent classes.

    • In 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 way to the root.

    • A subclass with more than one super class is called a shared subclass. This leads to multiple inheritance, where a subclass inherits attributes from multiple classes.

    • In a lattice, when 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 Salaried Employee all inherit from Employee, that are then inherited by Engineering Manager.

    • In this situation, the attributes are included only once in the subclass.

Modeling Union Types Using Categories

  • In the subclass-superclass relationship types we have seen so far, each has a single superclass.

    • This means that in a particular subclass/super class relationship (Engineer, Engineering Manager) even though the subclass has more than one subclass/super class relationship, each relationship is between a single super class and subclass.

    • There are situations when you would like to model a relationship where a single subclass has more than one super class, and where each super class represents a different entity type.

    • The subclass will represent a collection of objects that is a subset of the UNION of the distinct entity types.

    • This type of subclass is a union type, or category subclass.

    • See Text Example, page 99.

    • A category has two or more super classes that may be distinct entity types, where other super class/subclass relationships have only one super class.

    • If we compare the Engineering Manager subclass, it is a sub class of each of the three super classes, Engineer, Manager and Salaried 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, AND a Salaried Employee. It can be thought of as an AND condition.

    • By contrast, a category is a union of its subclasses. This means that an entity that is a subclass of a union, exists in ONLY ONE of the super classes. An owner may be a Company, OR a Bank OR a PERSON, but not more than one.

    • A category can be partial or total. A total category holds the union of ALL its super classes, where a partial category can hold a subset of the union.

    • If a category is total, it can also be represented as a total specialization.

Comparison of Registered Vehicle Category to Vehicle

Registered Vehicle Category to Vehicle

Registered Vehicle Category to Vehicle

  • The first example implies that every car and truck is also a vehicle. In the second example, a registered vehicle can be a car or a truck, but every car and truck is not a registered vehicle.

    • Other examples:

    • University (Researcher

    • Example 4.21

    • Design a database to keep track of information for an art museum. Assume that the following requirements were collected.

    • The museum has a collection of ART_OBJECTS . Each art object has a unique IDNo, and Artist, if known, a Year (when created, if known) a Title and a Description. The art objects are categorized in several ways, as discussed below.

    • ART_OBJECTS are categorized based on types. There are three main types, Painting, Sculpture and Statue, plus an ‘Other’ category for those that don’t fit into one of the categories above.

    • A PAINTING has a PaintType (oil, watercolor, etc) a material on which it is CrawnOn (paper, canvas, wood) and Style (modern, abstract etc)

    • A SCULPTURE or a STATUE has a Material from which it was created (wood, stone, etc) Height, Weight and Style.

    • An art object in the OTHER category has a Type(print, photo, etc) and Style.

    • ART_OBJECTS are also categorized as PERMANENT_COLLECTION, which are owned by the museum (DateAcquired, whether it is OnDisplay or Stored and Cost) or BORROWED, which has information on the Collection (where it was borrowed from), DateBorrowed, and DateReturned.

    • ART_OBJECTS also have information describing their country-culture using information on country/culture of Origin (Italian, Egyptial, American, Indian etc) and Period(Renaissance, Modern, Ancient)

    • The museum keeps track of ARTISTS’s information, if known: Name, DateBorn, DateDied, CountryOfOrigin, Period, MainStyle and Description. The name is assumed unique.

    • Different EXHIBITIONS occur, each having a Name, StartDate and EndDate. EXHIBITIONS are related to all the art objects that were on display during the exhibition.

    • Information is kept on other COLLECTIONS with which the museum interacts, including Name (unique), Type (museum, personnel etc), Description, Address, Phone and ContactPerson.

    • Draw an EER schema for this application. Record any assymptions you make.

Developed by: