PostgreSQL 7.1.3 Documentation
Prev | Chapter 1. SQL | Next

# 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 `v1` ∈ `D1`, `v2` ∈ `D2`, ... `vk` ∈ `Dk`.

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: `R` ⊆ `D1` × `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.

Prev | Home | Next
SQL | Up | Operations in the Relational Data Model