Defining base types
For defining base types, the Base type tab has to be selected. Now, one may select the base type to be updated or choose Append or Insert from the base type list context menu or from the list toolbar.
The base type insert dialog requests the base type name and type.
When using the complex data type name as base type name (always suggested), no type name needs to be entered. In order to refer to a complex data type defined in another active namespace, the namespace number has to be entered in the NSID field.
One may share base type instances with other specializations. In order to share a base type instance, an extent (superset) has to be defined for the base type, which contains the shared base type instances. By default, the extent is filled when creating a new base type with a complex data type that has got at least one extent.
The data type is filled automatically when creating a new base type. When changing the data type after defining the inverse relationship, the inverse relationship will be removed from the old related data type (when AutoUpdateInverse is set).
When defining a shared base type, an inverse relationship is requires. The name for the inverse relationship has to defined in the Inverse field. When not defining an inverse relationship, keys in indexes for the specialized data type cannot be maintained properly.
When AutoUpdateInverse has been enabled, the inverse relationship is creates automatically in the related data type definition. Except the cardinality for the inverse relationship and key definitions, which should be checked later on or by using the relationship edit button right of the Inverse field, the relationship definition is complete.
When only one specialized instance (e.g. maximum one student instance per person instance), the collection size for the relationship shown in the Dim. field should be set to 1.
When more than one specialized instances are allowed (a person might be employee in several companies), at least one key (typically the primary key) should be defined as access key for the relationship collection. Since key definitions are not yet available, it might be better to define attributes, keys and extent before defining the inverse relationship. In this case, the access key list for the relationship is initalized properly and need not to be updated later on.
In order to maintain inverse relationships properly, the option Options.Schema.Autoinitialize.AutoUpdateInverse should be set to AUTO (default) or YES. The option setting might be checked in the option dialog, which will be shown when selecting Tools/Option.... from the ClassEditor's main menu. In this case, the inverse relationship will be created automatically in the related data type. Otherwize, one has to create the inverse relationship in the related data type definition.
For persistent data types, generic types are not supported for base types. Generic types can be used for base types in transien data type definition (implementation classes), only.
Access privileges are not yet supported for persistent data types (e.g. in OSI functions). Only, when creating an implementation class for the persistent data type (C++ or C#), the privilege is interpreted according to the selected programming language).
The version for the base type shows the schema version for the base type definition. It cannot be changed.
Several options might be set for for base type definition, which influence the behavior of data type instances in the database.
Transient: Transient base types are not yet supported for persistent data types.
Virtual: Virtual is not yet supported for persistent data types, but for implementation classes.
Global Identity: Forces the database generating a global unique identity, when creating a new base type instance and the base type inherits from __OBJECT (system type).
Create: In order to allow creating new base type instances for the shared instance when creating a new specializedinstance, the option should be switched on. When the option is off, specialized instances can be created only, when a base type instance for being associated can be located in the superset.
Depends: When this option is set, base type instances are deleted, when deleting the specialized instance. The option should be set, when the inverse relationship is singular.
For shared base instances, one access key should be defined, which is also a unique access key in the superset of the base type. The key is used for looking up base type instances in the superset when creating new specialized instances.
By default, the key definition is set to the primary key of the base type's data type, or to the main access key of the superset (which is usually the same).
Source expressions cannot be defined for persistent data types, but might be defined for views.
One or more synonyms might be defined for the base type. In addition to original member names, synonyms might be used for accessing data using different member names. This allows, e.g. referring to old member names when upgrading the schema and changing member names for the one or other reason.