A relational database is a database structured in accordance with the relational model. Strictly speaking the term refers to a specific collection of data but it is invariably employed together with the software used to manage that collection of data. That software is more correctly called a relational database management system (RDBMS). Relational database management systems incorporate many features from the relational model, but commercial RDBMSs also tend to diverge from the relational model in significant ways.

Edgar Codd, who proposed the relational model in a groundbreaking 1970 paper, introduced a set of rules and, in 1985, a scoring system to determine whether or not a particular database implementation was in fact "relational." By this standard most commercial database servers fail the test, although it's worth noting that there have been few implementations of "truly" relational database servers and these have not had anywhere near the same commercial success. This article will explain what a database which conforms to the relational model is and is not. See relational database management system for an examination of how real-world database server software functions.

Relational model

The relational model for database management is a data model based on predicate logic and set theory. Relational databases have features which correspond with features of the relational model. In order to make the software work well in the real world, relational database management systems add additional features such as indices which have no place in the relational model.

Mapping the relational model to a relational database

The core of the relational model is that all data can be organized into relations. Relations are a way of organizing the data which permit flexible and powerful operations on the stored values. A relation has two parts, the heading, which is called the metadata in a relational database, and the body, which is the data itself. Relational databases generally implement relations in the form of tables and views.

A relation's heading is a set of attributes, and an attribute consists of a name and a domain. An attribute in relational theory is usually implemented as a column in a relational database. The domain is the set of possible values which can be stored. For example, a relation could have an attribute called "Percentage" with a domain of the integers between 0 and 100, inclusive. This would most commonly be implemented in a relational database as a column with a name of "Percentage" and a domain that has the data type of integer and a constraint disallowing values outside of that range. Note, however, that the data type and the constraint are really just two different ways of limiting the possible values which can be stored; from a relational theory point of view they're doing essentially the same thing, which is describing the possible attribute values.

One area where relational database management systems tend to diverge from relational theory is that RDBMSs usually give their columns an order. For example, they have a "first column," which might be the primary key, and a "second column," which might be a name, and so on. This is required by the SQL standard but is proscribed by relational theory. Most real-world attributes don't have orders, either. If you were to describe a person you wouldn't say that their eye color comes "before" their height and "after" their name, but this is essentially what the SQL standard requires.

The body of a relation is a set of unordered tuples. A tuple is a collection of values, organized by attribute name rather than by a defined order. For example, we might say that the attribute value of the "Percentage" attribute for a particular tuple is 95. The tuples are unordered in two different senses: The attribute values they contain are identified by name rather than by a "position" within the tuple, and the tuple itself has no single position relative to other tuples. Tuples are generally implemented in relational databases as rows. As noted earlier, most RDBMSs diverge from the relational model in that they are required by SQL to have an order of columns, but it's reasonably common for a database server to not support a defined order for their rows, and this seeming limitation turns out to have a number of advantages both in theory and practice.

The relational model (and Codd's rule number four) requires that the metadata also be accessible in the same manner as the rest of the data, and nearly all RDBMSs support this rule by describing the metadata in "system tables." Hence, the heading and the body are distinct within a single relation, but are essentially the same thing in general.

Database normalization

Database normalization is the process of structuring real-world data in such a way that it meets the standards for a relational database.

Formal definition

Relational algebra

The relational algebra is a set of operations that manipulate relations as they are defined in the relational model and as such describes part of the data manipulation aspect of this data model. Because of their algebraic properties these operations are often used in database query optimization as an intermediate representation of a query to which certain rewrite rules can be applied to obtain a more efficient version of the query.

The exact set of operations may differ per definition and also depends on whether the unlabeled relational model (that uses mathematical relations) or the labeled relational model (that uses the labeled specialization of mathematical relations) is used. We will assume the labeled case here as this is the most common way the relational model is defined. That means that we assume that tuples are partial functions from attribute names to values. The value of the tuple t on the attribute a is denoted in this article as t(a).

A k-adic relation is a set of k-tuples that constitutes the extension of a k-adic predicate. However, these tuples differ from the more abstract tuples of mathematics by having more concrete qualities associated with the places of the relation. In this setting, the components of the tuples, called attribute values or feature values, are identified by means of attribute names or feature names. Queries and integrity constraints are expressed declaratively, without the use of iterative loops or pointers, using operators based on the relational algebra and relation comparisons. The relational algebra is complete with respect to first-order predicate calculus except that restrictions are imposed on the use of the logical operations of negation and disjunction in order to guarantee that database computations will be feasible in practice.

Schematic example of a relational database

A concept of relation that suffices to begin can be set out as follows.

• Defined in extension, a k-adic relation $L\backslash !$ is a set of k-tuples.

• A k-tuple $\backslash mathbf\{x\}$ is a sequence of k elements, $x\_1,\; \backslash ldots,\; x\_k$, called the components of the k-tuple. The components of the k-tuple $\backslash mathbf\{x\}$ are commonly indicated by writing either one of the following two forms:

$\backslash mathbf\{x\}\; =\; (x\_1,\; \backslash ldots,\; x\_k)$

$\backslash mathbf\{x\}\; =\; x\_1\; :\; \backslash ldots\; :\; x\_k$

It is critically important to understand that a relation, considered, as one says, in extension, is a set, in other words, an aggregate entity or a collection of things. Thus a k-tuple is not a relation, it is only an element of a relation, what is naturally enough called an elementary relation.

Table 1 shows how the k-tuples of a k-adic relation might be conceived in tabular form, with the k-tuple $\backslash mathbf\{x\}\_i\; =\; (x\_\{ij\})\_\{j=1\}^k\; =\; (x\_\{i1\},\; \backslash ldots,\; x\_\{ik\})\; =\; x\_\{i1\}\; :\; \backslash ldots\; :\; x\_\{ik\}$ supplying the entries for the $i^\{\backslash mbox\{\; th\}\}$ row of the Table.

See also

Application

• Database
• Database normalization
• Database table
• Database tuple
• Dimensional database
• Flat file database
• Temporal database

Implementation

• Relational database management system (RDBMS)
• Structured Query Language (SQL)

Theory

• Relation
• Relation construction
  • Relation composition
  • Relation reduction

• Cartesian product
• Projection
• Relational algebra
• Relational model

History

• De Morgan, Augustus (1806–1871)
• Boole, George (1815–1864)
• Peirce, Charles Sanders (1839–1914)
• Codd, Edgar Frank (1923–2003)
• Ullman, Jeffrey D. (1942– )

• Date, Christopher J. ()
• Darwen, Hugh ()
• Cantor, Georg

External links

• A Relational Model of Data for Large Shared Data Banks: By Edgar F. Codd
• Relational Database Principles by Colin Ritchie. ISBN 0826457134
• Database in Depth by Chris Date. ISBN 0596100124. A new book (2005) by perhaps the best-known author in this field.
• Limitations of the relational model
• Introduction to Relational Database Design
• 15 Seconds: Introduction to Relational Databases
• Introduction to Relational Databases
• Definition from Whatis.com
• Database Normalization

Data management

Relační databáze | Relationale Datenbank | Base de datos relacional | Base de données relationnelle | בסיס נתונים טבלאי | Relációs adatbázis | Relationele database | リレーショナルデータベース | Model relacyjny | Banco de dados relacional | Реляционные базы данных | Relationsdatabas | 关系数据库