関係モデル
SQL では CHECK OPTION をつけずに定義されたビューに対して更新を行うことができる。しかしその結果そうしたビューへの更新は必ずしも更新対象(当該ビュー)に反映されるわけではない。例えばSQLでは、ビューに対する INSERT の実行は可能であるが、追加された行がビューに反映されないことがある。またビューに UPDATE を行った場合、ビューから更新対象データが消える可能性がある。関係モデルでは、ビューに対する更新は基底関係変数に対する更新と同じ結果になることが必要である。
新しい 顧客ID 1234567890 をもつ顧客の「追加」を試みると、この追加は関係変数の設計に違反するため失敗する。 なぜなら 顧客ID は主キーであり顧客関係変数には既に顧客 1234567890 が存在するからである。 RDBMSは、整合性制約に違反することにより関係データベースを不整合な状態にするこのようなトランザクションを、拒絶しなければならない。
外部キーは、整合性制約であり、外部キーの値が別の関係の候補キーのいずれかの値に合致することを強制する。 例えば注文関係においては 顧客ID 属性が外部キーである。 結合は、複数の関係から一度に情報を引き出す演算である。 先の例の複数の関係で結合を行うことにより、全ての顧客、注文、請求書のデータを検索することができる。 もしこのとき特定の顧客に関する情報だけ必要なのであれば、制限条件を使って結合を行えば良い。
顧客 1234567890 の全ての注文を検索したい場合には、顧客ID 1234567890 をもつ全ての注文関係の組を取得し、取得した結果に対して 注文番号 に基づいて注文明細関係と結合すれば良い。
先に示したデータベース設計には欠陥がある。請求書関係変数が注文番号属性をもっているのである。これは、請求書関係変数の各々の組が一つずつ注文番号をもつということである。このことは各々の請求書にはそれぞれ必ず一つの注文があるということである。
関係の正規化は、多くの場合関係データベースの設計時にデータベース設計の論理的整合性とトランザクション性能の向上をめざして、行われる。
2008年現在、論理設計を関係モデルの視覚的表現により効果的に行うために、3つの図(ダイアグラム)の体系が広く使われている。
実体-関連図(entity-relationship diagram)
IDEF図 - アメリカ合衆国空軍が実体-関連図に基づいて開発したIDEF1X法で使われる
統一モデリング言語 (UML) - OMGにより策定されオブジェクト指向ソフトウェア開発などにおいて使われる
データを木構造で表現しようとすると、関係変数群を親子関連をもつ階層型モデルの構造にしなければならなくなるであろう。