Mapping generalization

Three mapping possibilities

Three principal techniques exist to solve the problem of table mapping:

1. Copying the generalized attributes into all the tables which represent the child classes (the abstract classes of the persistent generalization tree are not then represented in any table).

2. The basic class (which can be abstract) has its own database table. The tables of the child classes then reference it.

3. All the classes of a generalization tree are mapped to a single table.

Choosing the right mapping technique

There is no ideal solution to the problem of selecting the mapping.

1. Solution 1 is normally quicker when running the program, since it does not necessitate any further links or complex operations in order to access the data. However, it requires larger tables, since it will be necessary to duplicate the definition of the generalized columns.

2. Solution 2 is less redundant, but there can be problems with the management of identifiers. If this is the case, it is necessary to manage unique primary keys for all the tables of the persistent generalization graph. Furthermore, access, like updates, will be more costly.

3. Solution 3 is the quickest when running the program, and allows the reading and writing of any BaseClass descendent with a single database operation. As all BaseClass descendents can be found in a single table, polymorphic reading is straightforward. The drawback is that the storing of object attributes requires more space than is absolutely necessary. This waste of space depends on the depth of the generalization tree. Furthermore, mapping too many classes to a single table may cause poor performance and database deadlock problems.

Example of mapping possibilities

Figure 18. Example of mapping possibilities

Generalizing persistence

The persistence characteristic is a generalized characteristic. If the parent class is already persistent, generation detects that a child class is persistent. The {persistence} tagged value on derived classes is generally redundant (but nevertheless useful from a documentation point of view).

Example of generalizing persistence

Figure 19. Example of generalizing persistence

Note: In this case, B is automatically persistent.

Selecting your mapping technique

The generalization mapping method is chosen at base class level, using the following tagged values:

· Solution 1: {oneTablePerConcreteClass}, which is used by default

· Solution 2: {oneTablePerClass}

· Solution 3: {oneTable}

Example of one table per concrete class

Figure 20. Example of mapping with the {oneTablePerConcreteClass} tagged value

Note: The tagged value on the "Worker" class serves no purpose.

This maps the worker class as follows:

CREATE WORKER TABLE{

NUMBER …,

NAME …,

SALARY … ,

QUALIFICATION …

};

The result is shown in Figure 21 below.

Figure 21. Result of mapping with the {oneTablePerConcreteClass} tagged value

Generalization of the generation mode

If the mode for generating persistence is not defined in the current class, and owns a parent class, the mode will be generalized by it. An error is detected if the generalization type defined locally is incompatible with the previous rule.

Example with one table per class

Figure 22. Example of mapping with the {oneTablePerClass} tagged value

This maps the worker class as follows:

CREATE WORKER TABLE

NUMBER …,

QUALIFICATION …,

};

The result is shown in Figure 23 below.

Figure 23. Result of mapping with the {oneTablePerClass} tagged value

Example with one table

Figure 24. Example of mapping with the {oneTable} tagged value

This maps both the employee and the worker classes as follows:

CREATE EMPLOYEE TABLE

NUMBER …,

NAME …,

SALARY …,

QUALIFICATION …,

};

The result is shown in Figure 25 below.

Figure 25. Result of mapping with the {oneTable} tagged value

Without specifying the generalization mapping mode, the "one table per concrete class" mode is adopted.

If {oneTablePerClass} had been defined at the level of the "Worker" class, there would have been an error!

Applying this rule allows you to mix three mapping modes within the same database diagram, while fixing only one type of persistency per simple generalization tree.

Multiple generalization

This version of SQL Designer does not take into account the generalization of several persistent classes. Using persistent multiple generalization provokes an error during the generation of the package.

However, it is possible that a persistent class specializes a persistent class and one or more non-persistent classes.

Abstract class

Objecteering SQL Designer does not produce any tables corresponding to a derived abstract class with the "one table per concrete class" pattern. Indeed, such tables cannot contain any recordings.

Integrity

The current version of Objecteering SQL Designer does not generate any uniqueness constraints on keys between several classes that specialize the same class with the "one table per concrete class" pattern.

Generalization with the "one table per class" pattern implies the creation of outside keys in the child classes, which allow you to guarantee the existence of a recording in a parent class.

The automatic deletion by reflex of recordings through references from child classes towards their parent classes ("delete on cascade" notion) is not carried out.