User:Jasonf RAIMA/sandbox

RDM
Developer(s)	Raima Inc.
Stable release	11.0
Operating system	Cross-platform
Type	DBMS
License	Commercial license
Website	Raima Database Management

This is the user sandbox of Jasonf RAIMA. A user sandbox is a subpage of the user's user page. It serves as a testing spot and page development space for the user and is not an encyclopedia article. Create or edit your own sandbox here.

Other sandboxes: Main sandbox | Template sandbox

Finished writing a draft article? Are you ready to request review of it by an experienced editor for possible inclusion in Wikipedia? Submit your draft for review!

Raima Database Manager (or RDM) is a high performance, ACID-compliant database management system divided into three environments; Mobile, Embedded and Desktop & Server. RDM has been designed to utilize multi-core computers, networking (local or wide area), and in-memory or on-disk storage. It provides a low-level C API and a higher level SQL API. It has been ported to Windows, Linux, Unix and several real-time or embedded operating systems.

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.

History

Raima Inc., first released db_Vista, a single-user DBMS for C programmers in 1984. The database has been known as dbVISTA and RDM through the 90's. When Raima introduced a client-server version of the database the distinction was made between RDM and RDM Server. RDM was released in version 11 in 2012. An open source version of RDM, called db.*, was launched in 2000. Under Linux the db.* product was named db.linux.

Standard Functionality

Core Database Engine

The Core database engine is implemented as a linkable library, allowing it to become an embedded part of a C application. It is accessed by a low-level C API, and performs the basic DBMS functionality of data navigation and transactional updates. ACID properties, as defined by Jim Gray,^[1] are fully supported by the low-level engine.

Storage Media

An RDM database is composed of one or more computer files. Frequently, these files are stored in an operating system’s file system, which can be using disk drives, SD RAM, SSD or main memory as the storage media. RDM uses standard file I/O functions to access the file system.

An important issue with durable storage like disk and SD RAM is that an operating system will almost always maintain a cache of the file contents for performance reasons. If file updates are written into the file system, they first exist in the cache only. If the computer stops functioning before writing the cache contents to the permanent media, not only can the updates be lost, but the files may be left in an inconsistent state. To safeguard against this, RDM asks the operating system to “sync” a file at key moments, ensuring that the data is safe no matter when a computer may fail. The "sync" operation (synchronize to disk) will not return control to the program until the file contents exist on the permanent media. Any database system that guarantees the safety of data must have sync points in their transaction handling.

RDM also has its own internal in-memory file system that allocates RAM for storing file contents. This is much faster than permanent media storage, but is vulnerable to loss if there is a program or computer error.

Database Definition Language

Database files are named in the Database Definition Language (DDL) written by the programmer. RDM defines 6 different file types for database storage:

1. Database Dictionary—also called DBD file, and ends with a “.dbd” suffix. This contains a definition of the sizes and locations of all data stored in the other database files.

2. Data File—a data file stores records. It is typical to name a data file after the record type it stores, using a “.dat” suffix, or to name the database and use a sequential “.dNN” suffix. Each record is stored in a slot, which is stored in a page in a data file. For any given data file, the slot and page sizes are fixed. Normally, one type of record is stored in a data file, but multiple record types may be stored in the same file. A page is a unit of I/O, where everything in the page is either read from or written to the file as a unit.

3. Key File—a key file uses a b-tree indexing structure to maintain a sorted, direct-access list of keys. Like data files, their suffixes are usually “.key” or “.kNN”. Key files also use fixed-length pages and slots.

4. Hash File—hashing is a different method used to store and look up keys. Hashing allows quicker lookups than b-trees, but do not maintain key ordering.

5. Vardata File—variable-length strings are managed by storing a reference to the string in the data file, and storing the string, probably in fixed-length pieces, in a vardata file.

Data Modeling

Relational Model

RDM allows a database to be defined using SQL, the predominant relational database language. Relationships in a pure relational model are defined by comparing column values in one table to column values in another. Indexing is a common method to optimize the comparisons.

Network Model

Beneath the relational model in an RDM database is a network model, where all data is defined in terms of record types and fields. Fields may be indexed, and record types may have set relationships between them, which are defined as one-to-many, owner/member relationships.

Note that set relationships occupy space in the records, stored in the data files. The owner record will contain pointers to member records. Member records will contain pointers to the owner record, plus the next and previous members. This allows for quick navigation among the members of a set.

RDM uses the set construct to represent relational equi-joins, which will be shown in the DDL examples below. Data in RDM is modeled by creating DDL (Database Definition Language). When DDL is compiled, a database dictionary file (DBD, as defined above) is created.

Core DDL

The Core DDL defines records and indices, and identifies the files containing them.

SQL DDL

In RDM, the SQL DDL gets translated into Core DDL, and the extra information needed only by SQL is stored in a separate catalog file that is used together with the DBD file.

Runtime Library

The runtime library is linked into applications and performs database operations through the Core API, defined as a set of C functions. It keeps a cache of database file pages in its memory. Some of those pages may have been read from the database, others may have been created as new pages by the runtime library. The functions read or update the contents of the pages in the cache.

Database Control	Create or destroy databases. Open or close databases.
Transaction Control	Begin, commit or abort transactions.
Locking Functions	Lock records for shared reading or exclusive writing.
Record/Set Create/Delete	Create or delete records, connect and disconnect records from sets.
Navigation	Key lookup and scanning. Set scanning. Sequential scanning.
Read/Write Data	Read or write entire record contents or individual field contents.

TFS

The Transactional File Server (TFS) specializes in the serving and managing of files on a given medium. The TFS is a set of functions called by the runtime library to manage the sharing of database files among one or more runtime library instances.

In-Memory Operation

Files within RDM databases may be declared as “in memory,” meaning that those files are maintained in RAM while the other files are stored in a file system (this may be referred to as hybrid storage).

Database Unions

Database Unions allow highly-distributed data storage and processing. This provides a mechanism for unifying the distributed data, giving it the appearance of a single, large database.

Interoperability

ODBC, JDBC and ADO.NET are able to be used as standard interfaces. ODBC is already implemented as a C API, meaning that C/C++ programmers can write programs that access the database through ODBC functions. This API may be used within any environment. On Windows, the ODBC driver has been provided for access from third party tools. JDBC and ADO.NET permit connection using the standard methods.

Mirroring

Mirroring creates one or more additional copies of a database. And rather than just copying files, the process involves copying transaction logs so that mirror copies are updated incrementally and synchronously.

Replication

Replication can be used within RDM packages as an action-for-action movement of data, rather than byte-for-byte, as it is with mirroring. Because of the replication of database actions, it is possible to aggregate data from multiple RDM master databases into a single database.

Indexing

RDM supports B-tree and hash indexes^[2]. The index’s can contain a single or multiple segments (simple or compound).

Data Models

A DBMS represents and structures data so that it "models" some sort of real-life data. RDM mixes two conventional data modelling approaches: network and relational.

Transactions

For data integrity, RDM supports the ACID transaction model ensuring a set of changes are applied atomically as a group, or none of them are applied, resulting in a database always being in a consistent state.

Multi-User Support

Multi-User access is facilitated by running a separate TFS (Transactional File Server) process that manages the database files and which acts as a server to multiple applications that have linked RDM runtime library int their process space. The TFS requires locking so that one application cannot overwrite updates made by another. This is the Isolation part of ACID. Runtimes connect to a TFS (more than one may be used by a runtime) through TCP/IP, so it may be on the same computer as the TFS, or visible through a domain name.

Multi-Version Concurrency Control

Multi-Version Concurrency Control (MVCC)^[3] is used to implement read-only-transactions in RDM , meaning that a virtual snapshot of a database is marked for a reading task, and this snapshot is readable until the read-only-transaction is terminated by the task, even if it is being concurrently updated. The purpose of the functionality is to avoid read locks, thus improving multi-user performance.

APIs

Five programming APIs are supported; C, C++, RSQL API, ODBC and iOS.

Native C API

RDM’s core C API is over 150 library low-level functions for all database operations.

SQL API

RDM SQL has been designed for embedded systems applications. As such, it provides a subset of the ANSI/ISO standard SQL that is suitable for running on a wide variety of computers and embedded operating systems many of which have limited computing resources.

C++ API

A database DDL (Database Definition Language) can be compiled to produce a set of C++ objects with methods that allow navigation and manipulation of a database in an intuitive C++ API^[4].

ODBC

ODBC is built on top of RSQL, and is the standard API for accessing SQL databases.

iOS

iOS is used in RDM Mobile Edition.

Data Types

RDM supports signed and unsigned integer (16, 32 or 64 bit), character string (UTF-8 or UNICODE), float, double, and BLOB fields.

RDM Applications

RDM based applications are used today in all major industries including Aerospace & Defense, Automotive, Business Automation, Financial, Government, Industrial Automation, Medical, and Telecommunication.

References

^ Gray, Jim, and Reuter, Andreas (1993), Distributed Transaction Processing: Concepts and Techniques, Morgan Kaufmann, ISBN 1-55860-190-2{{citation}}: CS1 maint: multiple names: authors list (link)
^ Bridgwater,Adrian (2011). "Embedded Dataflow At Warp Speed".
^ Gerhard Weikum (2002). "5 Multiversion Concurrency Control". Transactional Information Systems. Morgan Kaufmann. pp. 211–213. ISBN 1-55860-508-8. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
^ Parsons, Jeff (2011). "Building a C++ interface for your embedded DBMS".

External links

Articles

Category:Proprietary database management systems Category:Embedded databases

[1] Gray, Jim, and Reuter, Andreas (1993), Distributed Transaction Processing: Concepts and Techniques, Morgan Kaufmann, ISBN 1-55860-190-2{{citation}}: CS1 maint: multiple names: authors list (link)

[2] Bridgwater,Adrian (2011). "Embedded Dataflow At Warp Speed".

[3] Gerhard Weikum (2002). "5 Multiversion Concurrency Control". Transactional Information Systems. Morgan Kaufmann. pp. 211–213. ISBN 1-55860-508-8. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[4] Parsons, Jeff (2011). "Building a C++ interface for your embedded DBMS".

[1]

[2]

[3]

[4]