Entities and Sub-Classes

If in an application domain an entity seems to exhibit distinct clustering of its instances then it is best to partition the instances into subsets. The basic idea is attributed to Smith and Smith [SMITH77]. A subset has all the properties defined for the class that it is sub-

setting and possibly defines more of its own; this is often called sub-classing. Each instance in a subset is also an instance in the original entity set of instances. For example the EMPLOYEE instances can be divided into either technical employees or administrative employees or neither (see figure 2.3). This is an example of sub-classing where TECHNICAL and ADMINISTRATIVE (ADMIN for short) are sub-classes of EMPLOYEE; and EMPLOYEE is loosely called a parent class. Both sub-classes would inherit attributes and relationships from their parent entity and are allowed to independently add their own attributes and relationships. Consequently sub-classing allows us to specify relationships concisely; for example a TECHNICAL instance (not just any EMPLOYEE) can use a piece of HARDWARE or SOFTWARE. Also sub-setting allows the entities to be organised in an entity’s hierarchy.

Conceptual Modelling - Page [ 16]

There are a number of options to this sub-setting. Firstly is sub-classing partial or total (see figure 2.4)? Secondly is sub-classing allowed to overlap or not (i.e. disjoint) between sub-classes of an entity (see figure 2.5)? If, for example, we have an EMPLOYEE who can be a TECHNICAL or an ADMIN instance, and there might be EMPLOYEEs who are neither, then our sub-class relation has a partial participation and also has disjoint sub-setting. Thirdly an instance can be included in a sub-class either by way of its attribute(s) value called a

predicate defined instance on its subclasses or by making it an arbitrary instance of a

subset (where this is called an explicit semantic relationship). An example of predicate defined sub-classing follows: let us assume we have two sub-classes, PERMANENT or CONSULTANT, of EMPLOYEE which has an attribute called STATUS that holds an indicator of the pay structure. In this case each PERMANENT and CONSULTANT instance should have the following value for the STATUS attribute of “full-time” and “part-time” respectively.

TECHNICAL ADMIN

EMPLOYEE

D

⊆

⊇

Fig 2.3 – EERM with Employee and its subclasses related through a disjoint and total relationship.

To draw the sub-class relation between a class and its sub-class use a circle and pair of edges to connect the relevant entities. Within the circle we print a “D” for disjointness and an “O” for overlapping – see figures 2.3 and 2.5. Also on the edge closer to the sub-class we draw the sub-set symbol (i.e.



) with the pointed edges in the direction of the sub-class. If the relation is total then the edge from the circle to the class is drawn in double line. If a sub-class relation is predicate defined then that predicate is written on the main edge (the edge from the class to the circle) and the value that satisfies on the edge from the circle to

Conceptual Modelling - Page [ 17]

the sub-class. As for drawing styles there are two main references: Elmasri [ELMAS10] and

Teorey [TEARE05]. PERMANENT CONSULTANT D Job Status ‘permanent’ ‘consultant’ Eno Job Status EMPLOYEE

⊆

⊇

Fig 2.4 – EERM with Employee and its subclasses related through a disjoint, total and predicate defined (i.e. Job Status) relationship.

In some references known for presenting sub-classing in EERM (e.g. [HULLR87]) it is allowed

having a number of sub-setting “relationships” radiating from the same entity. In figure 2.5 we have done this; EMPLOYEE has a theme of subsets based on TECHNICAL and ADMIN and another theme based on the subsets by PERMANENT and CONSULTANT. These two themes are independent from each other. This multiplicity of sub-setting does complicate the diagram and the entity’s hierarchy.

PERMANENT CONSULTANT EMPLOYEE O

U

I

TECHNICAL ADMIN D

U

I

⊇

⊇

Fig 2.5 – EERM with multiple sub-setting relationships

There is of course the ever present problem associated with inheritance – multiple

inheritance. This is possible in EERM and the resolution of conflicts is usually based on

Conceptual Modelling - Page [ 18]

is free to restrict his diagram to single inheritance; albeit making the design cluttered and repetitive.

As for entities and relationships, the sub-classing construct comes with a series of constraints that all instances involved must adhere to. Some of these constraints are static, while some others are transitional; in references [ELMAS10] and [TEORE05] one finds the

following. The static constraints include:

1) There should be no cycles in the entity-hierarchy through the sub-classing relation. 2) If sub-classing is restricted to a single inheritance then each entity can only be a sub-

class of at most one entity.

3) If a sub-classing relation is total then all instances of the parent entity must be an instance of at least one sub-class.

4) If the sub-classing relation is predicate defined then the discriminating value for each sub-class must be non-ambiguous. Also each instance of the sub-class has its defining attribute value satisfies any explicitly stated value in the diagram.

5) If the sub-classing relation is arbitrary (not defined with a predicate) and disjointness is specified then each instance of a sub-class in an instance of at most one sub-class.

The transitional constraints on the sub-classing relation include:

1) On introducing a new instance to an entity that has a total sub-class relation then by implication the same instance has to be made an instance of one of the sub-classes. Additionally on introducing a new instance to an entity that has a predicate defined and total sub-classes constraint then by implication that instance is also made an instance of the matching sub-classes.

2) On purging an entity instance then all the associations in its sub-classes are also deleted.

3) On changing the values of an instance’s attributes that affects the value that determine a predicate defined sub-class relation then that instance becomes the instance of the current sub-class that matches its new value. Migrating instances from one sub-class to another requires ad hoc procedures because other attribute values might not satisfy destination class properties.

Conceptual Modelling - Page [ 19]

In document An object-oriented data and query model (Page 31-35)