Skip to content

Generalizations

Generalization is a special type of entity. In a generalization you have a base entity that holds common attributes and properties. The specialization entities holds specific information about its own entity. All entities within a generalization uses the same table to store their data. A discriminator column row_type is generated in the database code which will be used to identify between different derived (sub) entities.

It should be noted that each derived (sub) entity implements its own business logic (in model and source code files) including state machine and only uses the common table (of the base entity) to store and query data.

Model generalization entity using diagram

  1. Open or create a new overview diagram
  2. Check base entity included in the overview diagram. If currently not exists include it.
  3. Create new entity to be derived from the base entity. If it's already exists, include it to diagram.
  4. Create basedOn link from the derived entity to base entity. All inherited data will be included to the derived entity referring the base entity.
    If the derived entity already contains attributes, associations or states they will remain.
  5. Check that the derived entity's content is valid.
  6. Add additional attributes for the derived entity.
  7. Generate code for all entities. Database.cre, .api and.apy files will be generated.

Figure:  Sample of generalization in the overview diagram.

Model generalization entity using model file editor

  1. Create new base entity and add common attributes.
  2. In the source editor after the component name, type model command basedOn with its own entity name.
  3. Create new entity to be derived from the base entity.
  4. Open the base entity in the source editor and copy all it's attributes, references and states.
  5. Open derived entity in the source editor and paste them.
  6. In the source editor after the component name, type model command basedOn with the base entity name (i.e. this setting should occur both on the base and derived entities).
  7. Under the code gen properties, give the base entity's table name as DbTableName
  8. Add additional attributes for the derived entity.
  9. Generate code for all entities. Database.cre, .api and.apy files will be generated.

Considerations

  1. You should not insert records to the base entity (even if no hard error is raised if you do), only the derived entities are designed for inserts.
  2. Mandatory attributes may only exist in the base entity, but not in any derived entity (except for the derived attributes off course).

Starting from 25R2

we support online upgrades using Oracle EBR (Edition-Based Redefinition) technology. With EBR, an editioning view (EV) must be created for each table. The way BasedOn work is that a single parent entity can have multiple child entities, all of which share the parent’s table. No separate table is created for the child entities. Instead, the child-specific columns are added directly to the parent’s table through the child entities’ .cre files. As a result, the parent table contains columns defined by both the parent and its children.

The challenge arises when creating an editioning view for the parent table:

  • The parent entity does not have full knowledge of all columns in its table, particularly those introduced by the child entities.
  • This limitation prevents the parent from generating a complete and correct editioning view on its own.

To address this limitation, a new syntax has been introduced to explicitly list basedOn child entities as part of the parent entity definition. This ensures that the parent entity has full visibility of all columns (including those inherited from its children)

basedOnEntities {   
 includeBasedOnAttributes <Component>/<EntityName>; 
}

Behavior:

  • When this syntax is used, the code generation process will merge all attributes defined in the specified child entity (<EntityName>) into the parent entity.
  • If any attributes from the child entity already exist in the parent entity, those attributes will not be duplicated. The parent entity’s definition takes precedence for any overlapping attributes.
  • This merging logic should be applied consistently during generation of:
  • The parent table definition
  • The .cre and .edv files
  • Editioned views in the -base.views file

For the newly introduced syntax to function correctly within the parent entity, the following code generation properties must be configured on the associated child entity:

  • DbTableName should be set to the corresponding parent table.
  • GenerateStorageFile must be set to "no".

With these properties in place, the new syntax will effectively merge all attributes defined within the specified child entity into the code generation output.

codegenproperties {
   DbTableName         "<ParentTableName>";
   GenerateStorageFile "no";
}

Note on Column Overrides in Parent Storage Files

In earlier implementations, some developers defined child columns within the parent storage file by overriding the table. This was primarily due to the lack of support for accessing child columns at the parent level.

With the introduction of the enhanced basedOn syntax, such scenarios are now fully supported and handled by the framework. As a result, manual overrides of table columns that already exist in the child entity are no longer required.

Important: Continuing to override these columns in the parent storage file will result in them being replaced by the corresponding columns from the listed basedOnEntities, if those columns already exist in the child. Priority is given in the following order:

  1. Columns defined in the child entity
  2. Columns overridden in the parent storage file
  3. Columns defined in the parent entity itself