ODABA provides many enhanced database features on one hand, and tries to comply to standards as far as possible on the other hand. Here, main extensions (and 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).
The ODABA database management system supports different database model levels as being described in Unified Database Theory. Similar levels 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.
P0 database models are typically provided as key/value stores. ODABA supports P0 databases by means of extension properties.
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
Besides 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 are considered as relationships. ODABA supports the requirements on object-oriented databases and is, hence, also a P2 database model.
OLAP database models
P3 database features are typically implemented in OLAP or data warehouse tools. 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) and partially classification schemata. The latter is still under development and planned to be released in version 12. Thus, ODABA partially fulfills requirements on P3 database models.
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.
ODABA applications do not need a server One may develop and use an ODABA application just referring to a database file on a local computer or on a shared device in a local network, which also provides concurrent access to the database. This also means that database files might simply be moved from one environment to another.
In order to support many users in a local network (LAN), an ODABA server would perform better than simple file server applications. In order to run an application with an ODABA server, the application's configuration file has to be changed slightly and an ODABA server has to be setup. Usually, no changes in the application are necessary.
In order to run an application from different places in the world, a different configuration allows running the application with an internet server including server bridges for optimizing the access from allover the world. The internet server (including bridges) has to be setup on a server hosted by an internet provider.
No SQL! Database access is much simpler. 99% of known use cases do not need to define queries or query elements. The database appears like a huge storage area, which allows accessing data via "pointers". C++ and .NET APIs provide traditional access interfaces to the database, but there is also a scripting language (OSI), which is, syntactically, similar to C++ and nearly as powerful.
ODABA supports many extensional features in order to simplify database maintenance and application development. Here is just a short list of most important feature extensions supported by ODABA.
ODABA guaranties a high level of database consistency. It automatically maintains not only local and global indexes for collections, but also inverse relationships, subset/superset relations, supports automatic deletion for unreferenced instances and several other features resulting from model requirements.
Persistent object types may contain transient properties, which are evaluated when accessing the 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.
Different versioning strategies allow freezing the state of single object instances or a complete database. Moreover, online schema evolution allows extending a database schema without reorganizing running databases. Creating new schema versions will freeze the current version, which allows upgrading object instances at run-time.
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 nor available in relational databases.
Running an ODABA application based on relational databases does not support extension features as versioning or extension properties.
Similar to triggers, ODABA supports implementing business rules for complex data types. In addition, one may also support business rules for properties. Moreover, ODABA also supports a causality model, which allows defining cause and actions by means of state transitions of object instances or properties.