'''RDBMS''' is the usual abbrevation for
'''[relational database%|%Relational] [DBMS%|%Database Management System]'''
** See Also **
[SQL]:
** Reading **
[http://en.wikipedia.org/wiki/RDBMS%|%Wikipedia]:
[http://web.archive.org/web/20090524005207/http://ldn.linuxfoundation.org/column/database-defects%|%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]: [http://www.davudsplace.net/debbie1.html%|%debbie], [Oratcl]
[PostgreSQL]:
[ftp://ccfadm.eeg.ccf.org/pub/ctk/rdb.tar.Z%|%RDB] (dead link):
[SQLite] ,by [D. Richard Hipp]:
[Sybase]:
[DB2]:
[http://www.frontbase.com%|%FrontBase]: see the downloads area
----
<<discussion>>
[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 System]s 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).<<discussion>>
** See Also **
[SQL]:
<<categories>> Database | Glossary