Unsupported versions: 7.1
This documentation is for an unsupported version of PostgreSQL.
You may want to view the same page for the current version, or one of the other supported versions listed above instead.

# 1.2. Relational Data Model Formalities

The mathematical concept underlying the relational model is the set-theoretic relation which is a subset of the Cartesian product of a list of domains. This set-theoretic relation gives the model its name (do not confuse it with the relationship from the Entity-Relationship model). Formally a domain is simply a set of values. For example the set of integers is a domain. Also the set of character strings of length 20 and the real numbers are examples of domains.

The Cartesian product of domains D1, D2, ... Dk, written D1 × D2 × ... × Dk is the set of all k-tuples v1, v2, ... vk, such that v1D1, v2D2, ... vkDk.

For example, when we have k=2, D1={0,1} and D2={a,b,c} then D1 × D2 is {(0,a),(0,b),(0,c),(1,a),(1,b),(1,c)}.

A Relation is any subset of the Cartesian product of one or more domains: RD1 × D2 × ... × Dk.

For example {(0,a),(0,b),(1,a)} is a relation; it is in fact a subset of D1 × D2 mentioned above.

The members of a relation are called tuples. Each relation of some Cartesian product D1 × D2 × ... × Dk is said to have arity k and is therefore a set of k-tuples.

A relation can be viewed as a table (as we already did, remember The Suppliers and Parts Database where every tuple is represented by a row and every column corresponds to one component of a tuple. Giving names (called attributes) to the columns leads to the definition of a relation scheme.

A relation scheme R is a finite set of attributes A1, A2, ... Ak. There is a domain Di, for each attribute Ai, 1 <= i <= k, where the values of the attributes are taken from. We often write a relation scheme as R(A1, A2, ... Ak).

Note: A relation scheme is just a kind of template whereas a relation is an instance of a relation scheme. The relation consists of tuples (and can therefore be viewed as a table); not so the relation scheme.

## 1.2.1. Domains vs. Data Types

We often talked about domains in the last section. Recall that a domain is, formally, just a set of values (e.g., the set of integers or the real numbers). In terms of database systems we often talk of data types instead of domains. When we define a table we have to make a decision about which attributes to include. Additionally we have to decide which kind of data is going to be stored as attribute values. For example the values of SNAME from the table SUPPLIER will be character strings, whereas SNO will store integers. We define this by assigning a data type to each attribute. The type of SNAME will be VARCHAR(20) (this is the SQL type for character strings of length <= 20), the type of SNO will be INTEGER. With the assignment of a data type we also have selected a domain for an attribute. The domain of SNAME is the set of all character strings of length <= 20, the domain of SNO is the set of all integer numbers.