ODABA database features

This chapter considers database features available without using the GUI framework and tools provided with the Object Development Environment (ODE).

ODABA provides many enhanced database features on one hand, and, on the other hand, tries to comply to standards as far as possible. Here, standard features and main extensions (differences to other database management systems) are listed.

The theoretical base for ODABA is Unified Database Theory, which defines abstract database model levels for different types of databases. ODABA combines the flexibility of key/value stores (P0) with the simplicity of relational databases (P1), the complexity of object-oriented databases (P2) and analytical features of data warehouse technologies (P3).

Physically, all database entries (instances and indexes) are referenced by a 32 byte entry descriptor, which contains version and schema version information, modification count and data base position. ODABA supports 64-bit identities (internal database entry number), which supports up to 9 223 372 036 854 775 808 database entries, which means for the moment practically: no limit.

• Meta-model

  The dictionary or resource database containing the application database schema and other application resources is an ordinary ODABA database based on a kind of meta-model. The meta-model describing the resource database covers following areas:

  • data model - containing type definitions for defining data types
  • documentation model - containing type definitions for documentation objects
  • administration model - containing basic administration type definitions (user, rights etc.)
  • functional model - containing type definitions for implementation classes, options and external resources.

  ODABA is, conceptually, terminology-oriented, i.e. is supports terminology based data modeling (Terminus) and allows creating database models from defined terminology models. In order to provide proper documentation, all development resources are linked with a documentation topic, which is typically maintained while developing an application.

  An extension is provided with the GUI framework, which requires a design model, which contains definitions for design classes in order to define GUI design resources (controls and forms).

• ODABA and Unified Database Theory

  The ODABA database management system supports different database model levels as being described in Unified Database Theory. Similar levels also have been encountered in Terminology Model, i.e. when reflecting subject area knowledge in terms of human language. Hence, ODABA not only unifies different database model levels, but also harmonizes human and technical languages.

  • Key/value stores

    P0 database models are typically provided as key/value stores. ODABA supports P0 databases by means of extension properties.

  • Entity-relationship models

    Relational databases (entity-relationship models) are considered to be P1 database models, which store data in well-structured instances that are collected in tables. P1 requirements are also fulfilled by object-oriented databases, which may store data in well-structured object instances collected in extents. This way, ODABA also supports P1 requirements.

  • Object-oriented database models

    Beside an instance schema, P2 database models allow storing any number of data collections (e.g. children of a person), which is typical for object-oriented databases. This also includes inverse relationships and inheritance, which also is considered as relationship. ODABA supports the requirements for object-oriented databases (ODMG 2003) and thus, implements also a P2 database model.

  • Aggregation schema

    P3 database features are typically implemented as aggregation schema (e.g. in data warehouse systems). P3 database models support set relation schemata in terms of subset/super set relations and (hierarchical) classification schemata. ODABA supports set hierarchies (subset/super set relations), classification and aggregation schemata, i.e. ODABA also fulfills requirements for P3 database models.

• 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.

  • Transient properties

    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

    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.

  • Extension attributes

    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').

  • Hierarchical enumerations

    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

    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

    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.

  • Weak-typed collections

    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.

  • Instance ownership

    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.

  • Copy model

    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.

• Versioning

  Different versioning strategies allow freezing the state of single object instances or a complete database. Several versioning strategies may be combined:

  • version scope - defines the scope for consistent version numbers (database, object space, owner or instance)
  • managed - provides a hierarchy of major and minor versions, where major versions define consistent version states and may be assigned to timestamps.
  • synchronized - version numbers are synchronized representing a temporal order of changes

  Moreover, online schema evolution allows extending a database schema without reorganizing running databases. Schema version uses managed versioning for the resource database, i.e. creating new schema versions will freeze the current schema version, which allows upgrading object instances later at run-time.

• Scalable servers

  ODABA may run with or without server - no different for the application. Platform independent database format also allows using databases on different hardware platforms and running applications in heterogeneous environments.

  • Local applications

    ODABA supports access to databases stored on a local computer. There is practically no difference between file server and local applications. In order to support concurrent applications on a local machine, ODABA distinguish between shared and exclusive database access, which is just a configuration option.

  • File server

    In order to run ODABA in a local network environment, ODABA applications do not need a database (object) server. One may develop and use an ODABA application just referring to a database file on on a shared device in a local network using file server support, which provides concurrent access to the database. It also means that database files can simply be moved from one place to another.

  • ODABA object server

    In order to support many users in a local network (LAN), an object server would perform better than simple file server applications. In order to run an application with an object server, the application's configuration file has to be changed slightly and an object server has to be setup. Usually, no changes in the application are necessary.

  • Replication server

    The ODABA replication server allows running databases on an internet server. Thus, clients distributed all over the world may access the same ODABA database. In order to run an application with a replication server, the application's configuration file has to be changed slightly and a replication server has to be provided in the internet. Usually, no changes in the application are necessary.

    Replication server access is transaction based and works on a local copy (replicate) of the master database. Replication server is the preferred access mode for distributed clients in the internet. Since reading data happens with local access speed, replication server access is fast as long as update load is low.

  • ODABA HTTP server

    The ODABA HTTP server (OHTTPServer) is a mean of communication with an ODABA database via HTTP internet protocol. This technique differs from previous server technologies an is intended for supporting WEB application and App development. ODABA supports all request types and also provides HTTP client features for testing complex requests.

    
    

• Database access

  Database access works like accessing object instances in an object-oriented environment. The database appears like a huge storage area, which allows accessing data in different ways.

  • typed access - allows referring to property and type names as being defined in the database model. Typed access is supported for OSI and C++.
  • generic access - allows accessing data via property and value handle, which may form hierarchies. Generic access is supported for C#, C++ and OSI.
  • view access - allows accessing (usually derived) data via view definitions and aggregation schemata (C#, C++ and OSI).

  C++ and C# APIs provide traditional access interfaces to the database, but there is also a scripting language (OSI), that provides direct access to database. OSI is, syntactically, similar to Java or C++ and nearly as powerful.

  • Access interfaces

    ODABA supports several language interfaces in order to access database content in different ways. Access interfaces are provided for C++ (typed and generic access), C# (generic access) and ODABA Script Interface OSI (typed and generic access).

    ODABA also supports mixed implementation classes (C# and OSI or C++ and OSI).

    
    

  • Access handles

    Database access functionality is provided via handle classes on different access layers.

    • Dictionary - The dictionary or resource database contains database model definitions, but also GUI design resources and application methods.
    • Database - The data base contains application data. With one dictionary, one may run any number of databases.
    • ObjectSpace - An object space is a well-defined area (scope) within the database, which may contain data for a specific application area (geographical area, client, ...). Object spaces may form hierarchies. The database is the root object space,
    • Property - Properties refer to collections or instances and provide a wide area of access functionality.
    • Value - is, typically, an elementary data item, but may also refer to complex attributes or arrays.

    All access layers are supported by appropriate handle classes with the same name. Access handle are the base for generic data access, which is supported in C++, .net and OSI.

  • Typed access

    Typed access allows accessing properties and values by name as being defined in the database model. OSI supports typed access by nature. In order to support typed access in C++, C++ header files may be generated using ODE development tools. C# does not support typed access.

  • Views and aggregation schemata

    Similar to traditional databases, ODABA provides View definitions as well as ad-hoc views (SELECT statement). In contrast to traditional view definitions, elements of the SELECT statements (FROM, WHERE etc.) may also be referenced as operations in an operation path, which allows more flexible view definitions.

    Since views support basic aggregation by the GROUP BY operation, only, defining aggregation schemata has been introduced in ODABA just setting an aggregation option in the View definition. Complex aggregation schemata allow providing aggregated data on different aggregation levels.

• Concurrency behavior

  In order to avoid concurrency problems, ODABA provides internal and external locking and transaction features. Depending on handle access mode, ODABA forbids or permits concurrent instance update. An automatic update detection discovers and "repairs" conflicts in case of concurrent updates.

  • Transactions

    In order to make concurrent applications save, but also for improving performance (e.g. for maintenance processes), ODABA provides different transaction technologies:

    • Internal transactions - very short transactions started internally while running any update function.
    • Read transaction - started in order to block event generation (e.g. while iterating through a collection).
    • Pool transaction - Medium transaction storing changes in an internal area
    • File transaction - Long transaction storing changes in a file.
    • Work spaces - Very long transactions storing changes in hierarchical staging areas.

    In order to restore changes made after last backup, a recovery file may be written, which logs all transactions.

  • Implicit and explicit locking features

    In order to avoid concurrent updates, instances and indexes can be locked (read or write lock) temporarily. Several internal and external lock features are provided:

    • Implicit locks - are very short locks mainly used for indexes/collection updates. All resources updated within a transaction are locked until the end of transaction. Instances are also locked implicitly (write lock), when being read in write mode.
    • Read locks - read locks may be called by applications in order to prevent a resource from being read or updated by other processes or transactions.
    • Write locks - prevents an instance or collection from being updated by other processes or threads
    • Persistent locks - allows locking an instance or collection in the database permanently (write lock).
    • Key locks . special lock mechanism in order to reduce write lock time for collections (indexes) in longer transactions.

    There are some other types of locking global resources described in User's Guide and Reference Documentation.

• Event handling

  Database applications generate internal events usually indicating data modifications but also state changes in access handles (open, close, select instance etc.). Events may be received by event handlers (overloaded functions written in C++, C# or OSI), but may also be passed by process event handlers to other application components. Thus, database events are sent to GUI framework (when being used), in order to indicate state changes in data or access handles.

  In addition, the GUI framework generates a number of GUI events indicating state transitions in a GUI element (typically controls) or triggering an action. Similar to database events, GUI events may be overloaded by appropriate event handler functions.

  • Database events

    Database events are generated in order to signal different kinds of state transition referring to database resource or access handle state. Most events are designed as before- and after-events. Before-events may be used to suppress the state change in process.

    • Handle events - are generated, when opening or closing an access handle or when changing selected data in an access handle
    • Resource events - are generated, when database resources change, i.e. while creating, updating, storing or deleting instances or while removing or inserting instances from/into collections. Resource events are also generated when the intended state transition failed.
    • Server events - in order to synchronize states between client and server, the server sends events generated while processing a request back to the client, which also generates the events returned.
    • Application events - are user-defined events associating a special state transition or the database resource (e.g. income becomes greater than 10 000 ) with a specific (re)action. When the event is generated, the defined action is called in order to handle the event.

    Handle and resource events are generated on instance and property level, i.e. events are also generated for elementary attributes.

  • GUI framework events

    GUI framework events are generated in order to signal different kinds of state transition referring to GUI resource. Most events are designed as before- and after-events. Before-events may be used to suppress the state change in process. There are two kinds of GUI framework events.

    • Data events - are generated, when opening or closing the data source for a GUI resources, or when data in the GUI resource has been filled, updated or changed in another way.
    • GUI events - are generated, the state of a GUI resource (typically control) changes, e.g. when a control is opened or closed, or receives or loses focus.
    • Application events - are user-defined events associating a special state transition or the GUI resource (e.g. pressing keys Shift+Alt+I when the GUI resource has the focus) with a specific (re)action. When the event is generated, the defined action is called in order to handle the event.

  • Event handling

    The principles for handling events do not differ between GUI and database event. Mainly, events are handled in Context Classes assigned to database or GUI resources. There are three different ways of handling database events:

    • Overloaded event handler - In order to handle events, context classes have to be defined for corresponding database resource (database, object space, data type, property). Events generated call virtual event handler functions (dummy functions) that may be overloaded in the context class (OSI, C++, C#)
    • Process event handler - In order to provide kind of generic event handling, process event handlers may be provided. Process event handler register themselves to a property handle in order to receive property and instance events.
    • Associated action - Within GUI framework, but also for database, application events may be handled by associated actions. Actions are either function actions implemented in the context class of the database or GUI resource or associated window actions (e.g. requesting authorization before increasing the income),

• Accessing external data

  ODABA supports accessing external data via property and value handles, i.e. using the same functionality as for accessing the database. External data may be defined as ODABA data type with some restrictions caused by the external data format. ODABA also allows defining mapping schemata mapping database data types to external data types. Last but not least, ODABA supports data exchange with several external storage types.

  • File access

    Property handle functionality may also be used for accessing external files (XML, JSON, OIF, EFDS and CSV). External file structures may be defined in the dictionary or in the external file (e.g. as extended header in a CSV file or as separate file description).

    ODABA also provides a Directory class that allows accessing directories and files via property handles.

  • Object-relation mapper (ORM)

    An ORM allows running ODABA applications based on relational databases. An entity-relationship model is created from the database schema, which may be loaded into an ORACLE, MS SQL Server or MySQL database. Data is stored in the relational database, but an OR mapping layer provides additional features, which are not available in relational databases.

    Running an ODABA application based on relational databases does not support extended features as versioning or extension properties.

  • Data exchange

    ODABA provides import/export functions for storing/loading data from external files. File formats supported are CSV (no names, no hierarchies), ESDF (no names), XML, OIF and JSON.

    ODABA also supports defining an exchange mapping schema in order to import/export data partially and with different names and hierarchies in external files.

• Database utilities

  In order to support maintenance functions and other services, ODABA provides a number of utilities for copying, checking and repairing databases, but also for loading schema definitions (ODL), running OSI scripts and investigating the database via a command line shell.

  • Maintenance tools

    Maintenance tools are several tools for database backup, restore, copy, setup and check, but also for obtaining database statistics and database state information. Maintenance tools also include database repair utilities.

  • Language tools

    Language tools provide ODABA specific language tools:

    • ODL - Schema loader allows loading a database schema from an external ODL file.
    • OSI - OSI interpreter allows calling OSI functions from a command.
    • OShell - Command line tool that allows browsing through a database and creating, updating or deleting data.
    • OSI debugger - OSI provides a debug feature that allows debugging OSI functions for command line and GUI tools.

  • Database servers

    Several servers may be called from command line or started as daemon/service.

• GUI and database plugins

  Several GUI plugins might be used in connection with ODABA. There is a plugin interface for user-defined controls, which allows adding control types defined by external developers. RUN Software provides a number of user controls for graphical presentation, audio and video and other purposes. Moreover, a spell checker plugin is available on database level.