関係モデル
簡単な複数の関係変数と属性の設計例
顧客(顧客ID、税ID、名前、住所、市、県、郵便番号、電話番号)
注文(注文番号、顧客ID、請求書番号、注文日、納品予定日、条件、状況)
注文明細(注文番号、請求書番号、製品コード、数量)
請求書(請求書番号、顧客ID、注文番号、日付、状況)
請求書明細(請求書番号、明細番号、製品コード、出荷数量)
製品(製品コード、製品名)
以上を表にすると、以下のようになる。 顧客表
注文表
注文明細表
請求書表
請求書明細表
製品表
この設計では次の6つの関係変数がある。
顧客、注文、注文明細、請求書、請求書明細、製品
太字でかつ下線のついた属性の集合は候補キー(candidate key)である。太字でない下線のついた属性は外部キー (foreign key) である。
一つの関係変数に複数の候補キーがある場合は、複数の候補キーから一つを任意で選び主キー (primary key) とする。
関係変数(リレーション変数; relvar; relation variable)は、特定の関係型の名前つきの変数である。どの時点においても、関係変数にはその型に対応した何らかの関係(関係値)が割り当てられている。関係が含む組の数は0の場合もある。
関係モデルの基本的な原理は情報の原理である。あらゆる情報は関係に含まれるデータとして表現される。この原理から導き出されることとして、関係データベースは関係変数の集合であり、関係データベースに対するあらゆる検索の結果は関係として表現される。
関係データベースには整合性が強制的に適用される。関係データベースで論理スキーマの一部として整合性の制約が宣言され、RDBMS によって関係データベースにアクセスするあらゆるアプリケーションソフトウェアに対して強制的に適用される。関係データベースにアクセスするアプリケーションソフトウェアに関係データベースの整合性の規則を実装する必要があるわけではない。一般的に、制約は関係比較演算子を使って表現される。整合性制約を記述するには、理論的にはただ一つの関係比較演算子「—は—の部分集合である」(⊆) だけで十分である。実際には、便利ないくつかの短縮記法を使うことができるであろう。その中でもとりわけ重要なのは、候補キー(candidate key; 実際にはスーパーキー superkey)、外部キー (foreign key) の各制約である。
候補キーが一つである場合は、必然的にその候補キーが主キーとなる。主キーは他の候補キーよりも選好して使われる。主キー以外の候補キーを代理キー (alternate key) と呼ぶ (ただしこのデータベース設計例では代理キーは無い) 。
候補キーは一意識別子 (unique identifier) であり、関係変数に組の重複を許さないよう強制するはたらきがある。組の重複が有ると集合の基本的定義に違反することとなり関係ではない別のもの(bag; バッグ)になってしまう。外部キーとスーパーキー(superkey; 候補キーを部分集合として含むキー)は複合している場合がある。つまり一つではなく複数の属性から構成されている場合がある。
次に顧客関係変数を表形式で記述する。関係は関係変数に割り当てられる値(関係値)と考えることができる。