Raima Database Manager

RDM

Developer(s)	Raima
Stable release	12.0
Operating system	Cross-platform
Type	DBMS
License	Commercial license
Website	Raima Database Manager

Raima Database Manager (or RDM) is a small footprint, high performance, ACID-compliant embedded database management system designed for use in embedded systems applications. RDM has been designed to utilize multi-core computers, networking (local or wide area), and on-disk or in-memory storage management. RDM provides support for multiple application programming interfaces (APIs): low-level C API, C++, and SQL(native, ODBC, JDBC, ADO.NET, and LabView). RDM is highly portable and is available on Windows, Linux, Unix and several real-time or embedded operating systems. A source-code license is also available.

RDM has support for both non-SQL (record and cursor level database access) and SQL database design and manipulation capabilities. The non-SQL features are important for the most resource-restricted embedded system environments where high performance in a very small footprint is the priority. SQL is important in providing a widely known standard database access method yet in a small enough footprint for most embedded systems environments.

History

Raima Inc.originally released RDM in 1984 and was called db_VISTA. It was one of the first microcomputer network model database management systems designed exclusively for use with C language applications. A companion product called db_QUERY was introduced in 1986, which was the first SQL-like query and report writing utility for a network model database.

A db_VISTA derivative DBMS designed to provide a high performance, transaction processing client-server SQL DBMS called Raima Database Server (RDS) was released in 1993.This was the first DBMS that provided an ODBC API as its native SQL interface. It was also the first SQL system that incorporated use of the network model inits DDL features. Soon thereafter, RDS was renamed Velocis and in 2001, RDM Server. Version 8.4 of RDM Server was released in 2012.

Uninterrupted development of RDM (also known as RDM Embedded) has continued where the most recent feature additions include database mirroring use in support of highly available (HA) systems, database replication, multi-version concurrency with read-only transactions, multiple transactional file server access, encryption, and an SQL designed specifically for use in embedded systems applications. Version 12.0 of RDM was released in 2013.

Also in 2013, RDM introduced the first,on-platform SQL DBMS available for use with National Instruments' LabView graphical programming language and was named the National Instruments' LabView Embedded Tools Network Product of the Year.^[1]

Product Features

Database Design Language (DDL)

Non-SQL(core) DDL Features:

C struct-like record type (table) declarations.

Network model set declarations for defining 1-many inter-record relationships.

Support for direct, B-tree, and hashed record access.

In-memory database or file declarations. A database can be designed to be either on-disk or in-memory or a hybrid where some parts reside in-memory while others are stored on disk.

Circular record types (tables). Circular tables store a user-specified maximum number of records (rows). When that maximum has been reached, newly inserted records are stored in the location occupied by the oldest one. Circular tables are important for storing status data on resource-restricted devices.

Supported datatypes: 8, 16, 32, and 64 bit signed or unsigned integers, float, double, decimal (BCD), fixed or variable-length character or wide character, binary or character large objects (blobs), date, time, timestamp, guid/uuid, and db_addr (database address—aka, rowid).

Support for struct and array data fields.

Optional user-control over database file organization and page sizes.

SQL DDL Features:

Declared referential integrity support automatically implemented using RDM's network model sets.

Support for direct, B-tree, and hashed row access.

In-memory database or table declarations.

Circular tables.

Virtual tables declarations that provide SQL access to external data sources (e.g., real-time sensor data).

Supported data types: boolean, tinyint, smallint, integer, bigint, decimal, real, float/double, binary/varbinary, long varbinary, char/varchar, wchar/wvarchar, long varchar, long wvarchar, date, time, timestamp, guid/uuid, rowid (foreign and primary keys).

domain declarations.

Transactional File Server

The RDM Transactional File Server (TFS) specializes in the serving and managing of database files on a given medium. The TFS is a set of functions called by the RDM runtime to manage the sharing of database files among one or more runtime library instances. In a normal multi-user configuration, the TFS functions are wrapped into a server process called TFServer. Standard TCP/IP can be used to make the connection, whether the runtime library and TFServer are on the same computer or different computers. However, when on the same computer a faster, shared-memory protocol is available by default.

The figure shows that one RDM client runtime may have connections to multiple TFServers, and one TFServer may be used by multiple client runtimes. To the applications using the RDM runtime and the TFServers, the locations of the other processes are invisible, so all processes may be on one computer, or all may be on different computers. This provides opportunities for true distributed processing.

Raima Database Manager Transactional File Server Operation

A TFServer should be considered a “database controller” in much the same way as a disk controller manages a storage device. A TFS is initialized with a root directory in which are stored all files managed by the TFS. If one computer has multiple disk controllers, it is recommended that one TFServer be assigned to each controller. This facilitates parallelism on one computer, especially when multiple CPU cores are also present.

A complete application system may have multiple TFServers running on one computer, and multiple computers networked together. Each TFServer will be able to run in parallel with the others, allowing the performance to scale accordingly.

The TFS functions are used by the RDM runtime, so the programmer has no visibility of the calls made to them. These functions are made available to the runtime library in three forms. For descriptive reasons,we call them TFSr, TFSt and TFSs:

TFSt: The actual, full-featured TFS functions, called directly by the runtime library. Supports multiple threads in a single application.

TFSr: The RPC (Remote Procedure Call) library. When called by the runtime library, these functions connect to one or more TFServer processes and call the TFS functions within them. A client/server configuration.

TFSs: “Standalone” TFS functions called directly by the runtime library, but intended only for single-process use (if multiple threads are used, each must be accessing a different database only). To be used for high-throughput batch operations while the database(s) are otherwise offline. Unsafe (but fast) updates are allowed.

Database Unions

RDM's database union feature provides a unified view of multiple identically structured databases. Since RDM allows highly distributed data storage and processing, this feature provides a mechanism for unifying the distributed data, giving it the appearance of a single, large database.

As a simple illustration, consider a widely distributed database for an organization that has its headquarters in Seattle, and branch offices in Boston, London and Mumbai. Each office owns and maintains employee records locally, but the headquarters also performs reporting on the entire organization. The database at each location has a structure identical to the others, and although it is a fully contained database at each location, it is also considered a partition of the larger global database. In this case, the partitioning is based on geographical location. The mechanism for querying a distributed database is simple for the programmer. When the database is opened,all partitions are referenced together, with OR symbols (“|”) between the individual partition names.

Partitioning and unified queries are also used for scaling the performance. Consider a database where each operation begins with a lookup of a record’s primary key. If the“database” is composed of four partitions, each stored on the same multi-core computer, but on different disks controlled by different disk controllers then the only requirement is a scheme that divides the primary key among the four partitions. If that scheme is a modulo of the primary key, then the application quickly determines which partition to store a record into or read the record from. Since there are multiple CPU cores to run the multiple processes (both the applications and the TFSs), and the four partitions are accessible in parallel (the four controllers permit this), the processing capacity is four times larger than with a single-core, single-disk, and single-partition configuration.

Database Encryption

RDM allows all database content to be encrypted before it is transported across a network and written to the database files. RDM's encryption supports the Rijndael/AES encryption algorithm with 128, 192 or 256 bit keys based on an application-specified encryption key.

Database Mirroring and HA Support

Database mirroring in RDM reproduces an exact, byte-for-byte copy of a master database onto the mirrored (or slave) database. Database mirroring is an important database feature for applications that require high availability (HA) where should a TFServer fails for some reason, then the application's HA monitor can automatically switch over to the mirrored TFServer.

RDM provides synchronous mirroring where each transaction that is committed on the master TFServer is also securely committed to the mirror TFServer. RDM also provides a set HA support API functions that can be called from the application's HA monitor to monitor the operational status of the TFServers.

Mirroring can also be used to support maintaining multiple copies of a database in which updates are only made to the master but readers are directed to one of the mirrored slaves in order to distribute many possible database readers across multiple computers. In this situation, it is not necessary for the master to wait for each slave to confirm a successful commit of each transaction and the mirroring process can run asynchronously.

RDM database mirroring requires that the master and all mirrored databases be maintained on the same computer/operating system platforms.

Database Replication

Replication is similar to mirroring but it not really intended for HA support but for transferring all or, more likely, portions of one database (master) to another database (slave). Replication is designed to work where the databases are not necessarily being maintained on the same platform. The slave databases can be other RDM managed databases or they can be a 3rd party DBMS.

RDM's replication includes support for multiple master to single slave selective replication of circular table data—important for embedded computers and devices at the edge of the data grid where status and condition monitoring occurs. The status data stored in each master's circular table is replicated to a central control systems which maintains a permanent history of all device statuses which can then be made available for a variety of time series and other analyses.

RDM also provides a database change notification API library that allows a slave to access the master replication logs without the data be stored and managed in a database. This allows, for example, a master to store device control information in a database that is replicated to the device through the notification API in order to efficiently control device operation.

SQL

RDM SQL has been designed specifically for use in embedded systems applications. Some of the more important features of RDM SQL include:

Small footprint—no SQL views or security is provided as these are usually unnecessary in embedded systems apps and their absence helps to keep the SQL footprint small.^[2]

Standard SQL transaction and referential integrity support.

The SQL system catalog and stored procedures can be stored in a file or as statically declared data structures in C modules.

Cost-based query optimization with a rich set of built-in scalar and aggregate functions. A variety of table access methods are available for consideration by the optimizer: direct row access (through rowid primarykeys), optimal primary/foreign key join access through network model sets, B-tree and hash indexes.

Ability to extend SQL capabilities through C-based user-defined scalar and aggregate functions.

Ability to extend SQL capabilities through C-based user-defined virtual table interfaces that provide SQL access to external data sources such as real-time sensor data.

Database table import/export to/from comma-delimited or XML files.

Ability to have read-only access from SQL to a non-SQL (i.e.,core level) database. This means, for example, that a remote RDM SQL application can access a non-SQL RDM database running on a very resource-restricted device.

Application Programming Interfaces

RDM provides application programming interfaces that allow application development in a variety of programming languages:

Core (C) API—RDM's low-level, record-oriented, navigational C API. Two access methods are supported. The currency model allows the programmer complete control over how record occurrences are accessed through the network model sets. The cursor model can be used which encapsulates the network model navigation within a cursor, greatly simplifying record access programming.

C++ API—Uses methods which have been created from the RDM non-SQL DDL specification.

Native SQL C API—Similar to the ODBC API but designed specifically for RDM SQL so that it is both more efficient (e.g., it doesn't have to handle all of the ODBC features that aren't supported by RDM SQL) and easier to use (e.g., C enum types are extensively used instead of ODBC's #define constants).

ODBC—The Open Database Connectivity API for C program access to RDM SQL. RDM's implementation does not require the use of the ODBC driver manager except when needed by a 3rd party ODBC tool (e.g., MS Access).

JDBC—The Java Database Connectivity API for Java program access to RDM SQL.

ADO.NET—Microsoft's .NET API for any MS-Windows program access to RDM SQL.

LabView—National Instrument's graphical programming language API to RDM SQL.

Besides the above database manipulation APIs, RDM also provides a variety of support APIs that are available for use by RDM applications. Two of note are:

Non-C data type manipulation API—provides access to all of the BCD arithmetic functions as well as a rich set of functions for manipulating date, time, and timestamp data values.

Platform Support Package API—provides access to the operating system independent functions used by RDM itself including: memory management, thread management and synchronization primitives.

Supported Platforms

RDM has been ported to a wide variety of computers and operating systems. Packages are available for the following platforms:

MS Windows 32, 64 bit

Linux 32, 64 bit

Android

QNX Neutrino ARM/x86/PPC 32 bit

Wind River VxWorks

Green Hills Integrity

Mac OS X 64 bit

HPUX PA-Risc/Itanium 32, 64 bit

Solaris SPARC/x86 32, 64 bit

AIX PPC 32, 64 bit.

RDM Packages

RDM consists of the packages RDM Mobile Edition, RDM Mobile Plus Edition, RDM Embedded Edition, RDM Embedded Plus Edition, RDM Workgroup Edition and RDM Workgroup Plus Edition for the different environments. RDM Mobile Edition is a database management system for a smartphone or tablet device. RDM Embedded Edition is a database management system for embedded devices. RDM Workgroup Edition is a database management system for desktop and server environments. The plus versions include additional functionality such as mirroring and replication.

Customers and Applications

RDM based applications are used today in all major industries including Aerospace & Defense, Automotive, Business Automation, Financial, Government, Industrial Automation, Medical, and Telecommunication. A sampling of RDM users includes the following:

Mitsubishi Electric—iQ Platform C Controller PLC

Schneider Electric—"ezXOS" in OASyS DNA product

Hydro-Québec—CEDA system to manage set up and configuration of power plantalternators

General Dynamics—"TIEF" – Tactical Information Exchange Capability database agent

Boeing—"AWACS"– Airborne Warning and Control System's radar electronics system.

Raytheon—low-level tactical flight profile management in Pave Hawk

Lockheed Martin—flight simulators

Benu Networks—Broadband Service Delivery Platform

Johnson & Johnson—VITROS patient systems

Beckman Coulter—UniCel DxC 800 Synchron clinical system

Siemens—RapidPoint 400 medical fluid test equipment

IBM—ClearCase source code control system

Magellan Navigation—MAPSEND GPS used in PC-based and embedded products

NSE—reliable stock trade data storage

NCDEX—real-time database services for trading application