関係モデルは形式化された最初のデータモデルである。関係モデルが定義された後に、非形式的なデータモデルが、階層型データベース（階層型データモデル）やネットワーク型データベース（ネットワーク型データモデル）を記述するために作られていった。階層型データベースとネットワーク型データベースは、関係データベース以前に既に存在していた。しかしそれらがモデルとして記述されたのは、関係モデルが定義された後のことであり、その目的はデータモデル間の比較をするための基礎を確立するためであった。
歴史.
SQL標準.
まずSQLの用語とそれに相当する関係モデルの用語の対応関係を示す。
以下にSQL標準における関係モデルからの逸脱を記述する。ただしSQL標準の全てを実装しているデータベース管理システム (DBMS) はほとんど存在しない。
ここで述べる関係モデルからの逸脱のいくつかについては、ほとんどの SQL DBMS で逸脱している。
実装.
論争.
先の#SQL標準の節を参照。
論理設計.
関係の正規化は、多くの場合関係データベースの設計時にデータベース設計の論理的整合性とトランザクション性能の向上をめざして、行われる。
データを木構造で表現しようとすると、関係変数群を親子関連をもつ階層型モデルの構造にしなければならなくなるであろう。
データベース例.
簡単な複数の関係変数と属性の設計例
顧客表
注文表
注文明細表
請求書表
請求書明細表
製品表
次に顧客関係変数を表形式で記述する。関係は関係変数に割り当てられる値（関係値）と考えることができる。
例: 顧客関係変数.
RDBMSは、整合性制約に違反することにより関係データベースを不整合な状態にするこのようなトランザクションを、拒絶しなければならない。
外部キーは、整合性制約であり、外部キーの値が別の関係の候補キーのいずれかの値に合致することを強制する。
例えば注文関係においては 顧客ID 属性が外部キーである。
結合は、複数の関係から一度に情報を引き出す演算である。
先の例の複数の関係で結合を行うことにより、全ての顧客、注文、請求書のデータを検索することができる。
もしこのとき特定の顧客に関する情報だけ必要なのであれば、制限条件を使って結合を行えば良い。