Database model

ODABA supports all features typical for object-oriented database models as (multiple) inheritance, attributes, references/relationships, inverse relationships etc., which are based on ODMG standard of the database management group ODMG 2003. But also, ODABA provides several useful model extensions.

Persistent object types may contain transient properties (attributes or references), which are evaluated when accessing these properties. Transient properties may be defined as simple attributes (like age calculated from birth date), but may also refer to complex data type or collections resulting from complex operations.

Generic attributes are those, which allow storing any number of values that are presented depending on the current environment. Typically, language depending data is stored in generic attributes.

By means of generic attributes ODABA supports multilingual features in documentation topics that allow providing documentation in any number of languages.

ODABA allows extending particular object instances by property (attribute, reference, relationship) extensions at run-time, i.e. different instances of a given type may get different extension properties (one person gets a 'comment' attribute, another 'last journey').

ODABA supports hierarchical enumerations (classifications). In contrast to ordinary enumerations, beside value (code) and name ODABA enumerators provide a number of additional information:

• label - language depending name
• title - short description
• description - detailed description
• type - related data type (class)
• condition - constraint applying to object instances of the class (data type) defined by the enumerator

Set relations allow defining subset/super set relationships. Extent collection may form set hierarchies of any level. Relationship collections may refer to one super set.

Shared inheritance allows two or more object instances inheriting from the same base instance (e.g. two Employee instances may inherit from/refer to the same Person instance, when a person is employed more than once.

Usually, collections (references, relationships, extents) are (strong) typed, i.e. all instances referenced in the collection belong to the same type. Weak-typed collections as supported in ODABA, only require that all instances in the collection are based on a common type (e.g. a weak-typed Person collection may contain Person , Employee and Student instances, which all inherit from Person ). Consequently, ODABA also supports untyped ( VOID ) collections, which may contain instances of any type.

The ODABA database model is defined in a way, that for each instance exactly one owner property is defined. This makes it much easier to decide, whether an instance must be removed, only from a collection or deleted completely.

Besides, other options are available for controlling the automatic instance deletion behavior.

When copying instances between or within databases, problems may arise, especially, when using deep copy option (i.e. copying an instance and all its referenced instances recursively). Usually, default copy rules are sufficient to avoid unlimited recursions by defining primary and secondary relationships for relationship pairs (relationship and it's inverse). Complex database models may, however, cause copy conflicts and require a specific copy model, which defines the sequence of extents to be copies and copy options for relationships.