Version 23 of RDBMS

Updated 2014-02-10 13:24:57 by RLE

RDBMS is the usual abbrevation for Relational Database Management System

Reading

Wikipedia
Database Defects ,by Cameron Laird and Kathryn Soraiz
this is actually about database design for RDBMSs, not about the systems themselves

Description

[Describe how rdbms differs from other dbms, and list a few examples.]

A database is a set of related data, a typical database has lists of values (tables of rows), each value is a list values (table columns), sometimes a value (a field) is itself a list of values (a record from another list, hence relational).

EMJ The word "related" above is used only in an informal sense, and the word "relational" at the end is just plain wrong. A database is relational because it is based on the mathematical concept of a relation, not for any other reason connected with the word "relate". Codd even gave a special meaning to the word "relationship" although it is pretty much unused these days. An analogy with lists might sometimes be useful (though not altogether accurate), but the idea that a "field" value may be a list is totally wrong - if a system allows that it is not relational.

SQL (the standard RDBMS language) is used to define the lists, the relations and to insert and retrieve values.

Some procedural language is typically used to define triggers and procedures, with compensates for what SQL can't do and adds more restrictions (control if you prefer) on the values in the DB.

Most rdbms(es) promises to be ACID compliant. ACID are (or should be) the properties of any db transaction . (A Atomicity, a transaction (TXN) is performed in its entirety or not at all) (C Consistency, a correct transaction takes the db from one consistent state to another) (I Isolation, until they become committed, updates by a transaction are not visible to other transactions) (D Durability, once committed changes must never be lost)

I personally find that between A and I, C seems redundant. It would be nice if someone can justify what C adds exactly. Possibly things such as a guarantee that changes are actually written to disk when the transaction completes. An inconsistent database would be one where some data (perhaps even references and other such internal book-keeping) has been updated but others have not been!

Question: what is considered a transaction in and what is not? Is data retrieval (Sql select statements) considered a transaction?

Sometimes it is said that rdbms is a database topology, other topologies include (network and hierarchical).

A not new variation of rdbms(es) is ORDBMS(es) or Object-relational db management systems.

Relational Database Systems

ADABASE D
AdabasTcl
db2tcl (DB2)
(is it true that DB2's native interface is so close to ODBC that TclODBC can be the basis for a "native" binding?)
The Datahub SDK, by Ed Hume
includes an in-memory SQL database at http://www.hume.com/
Duro a relational database library
open-source
Empress Tcl/Tk Interface
Informix
isqltcl
INGRES
Interbase
mSQL (mini SQL)
Blackbourn's Minerva miniSQL (mSQL?) binding miniSQL database interface (Blackbourn)
Microsoft Access
MS SQL Server
MrPersister
is a high level library on top of JDBC
MySQL
Oracle
debbie , Oratcl
PostgreSQL
RDB (dead link)
SQLite ,by D. Richard Hipp
Sybase
DB2
FrontBase
see the downloads area

NEM: There is an awful lot that could be said about RDBMSs. Firstly, it is probably worth distinguishing between a relational database, which is responsible for storing data as relations (sets of tuples, roughly), and a Relational DataBase Management System (RDBMS) which is responsible for managing access to such a database (e.g., takes care of concurrency issues, security, etc).

The underlying relational model (see Ratcl for an extension that provides access to relational operators) is quite closely related to first-order predicate logic (FOPL), as a (mathematical) relation can be identified with a predicate (boolean valued function) which determines set membership of elements in the relation. If SQL had been more closely based on FOPL then perhaps we wouldn't need ad-hoc triggers/stored-procedures.

Rule-based languages, such as CLIPS and others used in Expert Systems are usually much nearer to logic (and much more powerful than SQL), as is Prolog (which is a great language for learning about relations).

The connection to FOPL also partly explains why OO-relational mappings are sometimes a bit awkward: inheritance is a form of default reasoning ("all birds can fly", "a penguin is a bird, but it can't fly"), which is something of a tricky area in pure first-order logic, although there are several ways to do it (perhaps most explored in the area of semantic nets in AI).

There is much more to say here, but very little of it has much direct connection to Tcl. Tcl does, however, have many extensions for dealing with all sorts of databases (check the Category Database links).

See Also

SQL