An Object-Oriented Approach

An Object-Oriented Approach

Another strategy for converting isa-hierarchies to relations is to enumerate all the possible subtrees of the hierarchy. For each, create one relation that represents  entities that have elements in exactly those subtrees; the schema for this relation has all the attributes of any entity set in the subtree. We refer to this approach as "object- oriented", since it is motivated by the assumption that entities are "objects" that belong to one and only one class.

Example : Examine the hierarchy of the following figure;

The movie hierarchy

There are four possible subtrees including the root:

1. Movies alone.
2. Movies and Cartoons only.
3. Movies and Murder-Mysteries only.
4. All three entity sets.

We must create relations for all four "classes". Since only Murder-Mysteries contributes an attribute that is unique to its entities, there is actually some repetition, and these four relations are:

Movies(title, year, length, filmType)
MoviesC(title, year, length, filmType)
MoviesMM(title, year, length, filmType, weapon)
MoviesCMM(title, year, length, filmType, weapon)

Had Cartoons had attributes unique to that entity set, then all four relations would have different sets of attributes. As that is not the case here, we could combine Movies with MoviesC (i.e., create one relation for non-murdermysteries) and combine MoviesMM with MoviesCMM (i.e., create one relation for all murder mysteries), although doing so loses some information - which movies are cartoons.

We should also think how to handle the relationship Voices from Cartoons to Stars. If Voices were many-one from Cartoons, then we could add a voice attribute to MoviesC and MoviesCMM, which would represent the Voices relationship and would have the side-effect of making all four relations different. However, Voices is many-many, so we need to create a separate relation for this relationship. As usual, its schema has the key attributes from the entity sets connected; in this case

Voices(title, year, starName)

would be a correct schema.

One might think whether it was essential to create two such relations, one connecting cartoons that are not murder mysteries to their voices, and the other for cartoons that are murder mysteries. However, there does not appear to be any advantage to doing so in this case.