User:Jasonf RAIMA/sandbox

RDM System
Developer(s)	Raima Inc.
Stable release	10.1
Operating system	Cross-platform
Type	DBMS
License	Commercial license
Website	RDM Embedded

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!

RDM System (for Raima Database Manager) is a high performance, ACID-compliant database management system divided into three packages for three environments; Mobile, Embedded and Desktop & Server. The RDM System 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 System Packages

The RDM System consists of the packages RDM Mobile Edition, RDM Embedded Edition and RDM Workgroup 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.

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 System and RDM Server. RDM System 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 (see 2.2 DATA Modeling below). 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

Mirroring

This adds mirroring to the core functionality. A mirror copy of a database is the basis for failover or switchover operations, allowing a system to continue operation in the event of certain types of system failures. Functions that report disruptions in the synchronization of a database can be reported to a High Availability Manager.

Replication

Replication adds the ability to move database updates from the RDM database to other types of databases through the use of action-for-action logs. This permits database aggregation from one or more RDM databases into SQL-based database servers.

Database Unions

Database Unions add the ability to view multiple identically-structured databases from multiple locations as though they are one database.

Interoperability

This feature adds ODBC, JDBC and ADO.NET access to the RDM databases, allowing third-party tools to access the data.

Indexing

The RDM System supports B-tree and hash indexes. 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. The RDM System mixes two conventional data modelling approaches: network and relational.

Network Data Model

The network data model manages parent/child relationships between database records through sets, which consist of direct links from owner to members, next/previous members, and back to the owner. The term "network model" refers to data structuring, as in a Bachman diagram,^[2] where any given record type may be "owned" by multiple set types, distinguishing a network structure from a simpler hierarchical structure. Raima's implementation of the network model is a simplification of the CODASYL DBTG Model,^[3] which is supported today in a few old mainframe DBMSs.

Relational Data Model

The relational data model manages relationships between data objects through value matching, and usually primary key/foreign keys.

Data Storage

The RDM System historically provided storage of data only on a disk drive, but now provides in-memory storage as an option. A permanent-storage device such as a disk drive provides recoverability if there is any kind of failure in the software or loss of power. As memory capacities have increased, in-memory databases have become feasible. In-memory databases are faster than disk-based databases, but do not have the same degree of durability and recoverability as disk-based databases. When an application can tolerate the loss of one or more transactions, then in-memory is a desirable option because of its speed advantage.

Transactions

For data integrity, the RDM System 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 the RDM System 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)^[4] is used to implement read-only-transactions in the RDM System , 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

Native C API

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

SQL API

The RDM System 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.

Data Types

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

The RDM System Applications

The RDM System 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)
^ IRS Resources. Part 2. Information Technology, Chapter 5. Systems Development, Section 13. Database Design Techniques and Deliverables. Retrieved 02 July 2009.
^ David M. Kroenke (1995). "14 The CODASYL DBTG Model". Database Processing: Fundamentals, Design, and Implementation. Prentice-Hall. pp. 406–441. ISBN 0-02-366881-4.
^ 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)

External links

Articles

[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] IRS Resources. Part 2. Information Technology, Chapter 5. Systems Development, Section 13. Database Design Techniques and Deliverables. Retrieved 02 July 2009.

[3] David M. Kroenke (1995). "14 The CODASYL DBTG Model". Database Processing: Fundamentals, Design, and Implementation. Prentice-Hall. pp. 406–441. ISBN 0-02-366881-4.

[4] 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)

[1]

[2]

[3]

[4]