関係モデル

1970年のモデル発表から数年後、コッドは欠落情報を扱うために3値論理（真、偽、欠落/ NULL ）バージョンを提案し、彼の『データベース管理のためのリレーショナルモデル バージョン2』（1990年）ではさらに一歩進んで4値論理（真、偽、欠落しているが適用可能、欠落しているが適用不可）バージョンを提案した。^{[ 5 ]}

リレーションは、見出しと本体から構成されます。見出しは属性の集合を定義し、各属性には名前とデータ型（ドメインと呼ばれることもあります）があります。この集合に含まれる属性の数は、リレーションの次数またはアリティです。本体はタプルの集合です。タプルはn個の値の集合であり、nはリレーションの次数です。タプル内の各値は、一意の属性に対応します。^{[ 6 ]} この集合に含まれるタプルの数は、リレーションのカーディナリティです。^{[ 7 ] : 17–22}

リレーションは、再割り当て可能なリレーション変数（relvar）によって表現されます。 ^{[ 7 ]： 22-24}データベースはrelvarの集合です。^{[ 7 ]： 112-113}

このモデルでは、データベースは情報原理に従います。すなわち、任意の時点で、データベース内のすべての情報は、関係変数によって識別される関係内の属性に対応するタプル内の値のみによって表現されます。^{[ 7 ]： 111}

データベースは、任意のブール式を制約として定義できます。すべての制約が真と評価される場合、データベースは一貫性があります。そうでない場合は、一貫性がありません。データベースのリレ変数への変更によってデータベースが一貫性のない状態になる場合、その変更は不正であり、成功してはなりません。^{[ 7 ] : 91}

一般的に、制約は関係比較演算子を使用して表現され、理論的には「～の部分集合である」（⊆）という演算子だけで十分である。^{[ 8 ]}

制約の2つの特殊なケースは、キーと外部キーとして表現されます。

ユーザー（またはプログラム）は、クエリを送信することによってリレーショナルデータベースからデータを要求します。クエリに応答して、データベースは結果セットを返します。^{[ 2 ]}

多くの場合、複数のテーブルのデータは結合によって1つに結合されます。概念的には、これは行のすべての可能な組み合わせ（デカルト積）を取得し、答え以外のすべてをフィルタリングすることによって行われます。^{[ 2 ]}

結合以外にも、関係演算は数多くあります。これには、射影（列の一部を削除するプロセス）、制限（行の一部を削除するプロセス）、ユニオン（類似した構造を持つ 2 つのテーブルを結合する方法）、差分（一方のテーブルにはあるが他方のテーブルにはない行をリストアップする）、交差（両方のテーブルに存在する行をリストアップする）、積（前述のように、一方のテーブルの各行を他方のテーブルの各行と結合する）などがあります。参照する他の資料によっては、他にも多くの演算子があり 、その多くは上記の演算子に基づいて定義できます。これらには、セミ結合、外部結合や外部ユニオンなどの外部演算子、さまざまな形式の除算などがあります。さらに、列の名前を変更する演算子、集計演算子、関係値を属性として許可する場合（関係値属性）、グループ化やグループ解除などの演算子もあります。^{[ 2 ]}

リレーショナルデータベースの柔軟性により、プログラマーはデータベース設計者が想定していなかったクエリを作成できます。その結果、リレーショナルデータベースは、元の設計者が予見しなかった方法で複数のアプリケーションで使用できます。これは、長期間（おそらく数十年）使用される可能性のあるデータベースにとって特に重要です。^{[ 2 ]}このため、リレーショナルデータベースの概念と実装は企業で非常に人気があります。^{[ 9 ]}

リレーションは、脆弱な異常の種類に基づいて分類されます。第一正規形にあるデータベースはすべての種類の異常に対して脆弱ですが、ドメイン/キー正規形にあるデータベースは変更異常がありません。正規形は階層構造になっています。つまり、最も低いレベルは第一正規形であり、データベースは下位の正規形のすべての要件を満たさなければ、上位レベルの正規形の要件を満たすことはできません。^{[ 10 ]}

従業員のリレーションに属性が含まれている場合${\displaystyle \{名前,ID\}}$⁠、次にタプル⁠${\displaystyle \{アリス,1\}}$⁠は「 IDが1のAliceという名前の従業員が存在する」という命題を表します。この命題は真または偽です。このタプルがリレーション本体に存在する場合、命題は真です（そのような従業員が存在します）。このタプルがリレーション本体に存在しない場合、命題は偽です（そのような従業員は存在しません）。 ^{[ 7 ]： 96-97}

さらに、もし${\displaystyle \{ID\}}$はキーであり、タプルを含むリレーションです。${\displaystyle \{Alice,1\}}$そして​​${\displaystyle \{Bob,1\}}$⁠は次のような矛盾を表すだろう。

1. アリスという名前でIDが1の従業員が存在します。
2. ボブという名前の従業員がいて、IDは1です。
3. 同一のIDを持つ従業員は複数存在しません。

爆発原理の下では、この矛盾によってシステムは任意の命題が真であることを証明できてしまう。データベースはこれを防ぐためにキー制約を強制する必要がある。^{[ 7 ]： 104}

関係変数（relvar）とその属性を記述した、理想化された非常にシンプルな例を以下に示します。

• 顧客（顧客ID、名前）
• 注文（注文ID、顧客ID、請求書ID、日付）
• 請求書（請求書ID、顧客ID、注文ID、ステータス）

この設計では、顧客、注文、請求書の 3 つのリレバルがあります。太字で下線が引かれている属性は候補キーです。太字ではなく下線が引かれている属性は外部キーです。

通常、候補キーのうち1つがプライマリキーと呼ばれ、他の候補キー（代替キーと呼ばれる）よりも優先的に使用されます。

候補キーは、タプルが重複しないことを保証する一意の識別子です。重複すると、セットの基本定義に違反して、リレーションが別のもの、つまりバッグになってしまいます。外部キーとスーパーキー（候補キーを含む）はどちらも複合キー、つまり複数の属性で構成できます。以下は、例の Customer relvar のリレーションを表形式で示したものです。リレーションは、relvar に帰属できる値と考えることができます。

ID 123を持つ新規顧客を挿入しようとすると、顧客 ID は主キーであり、既に顧客123が存在するため、リレバレッジの設計に違反します。DBMSは、整合性制約違反によってデータベースの一貫性を損なうようなトランザクションを拒否する必要があります。ただし、名前フィールドは主キーの一部ではないため、新しい顧客に一意の ID があれば、 Aliceという名前の別の顧客を挿入することは可能です。

外部キーは、属性セットの値が別のリレーションの候補キーから取得されることを強制する整合性制約です。たとえば、Order リレーションでは、 Customer ID属性が外部キーです。結合は、複数のリレーションから一度に情報を取得する操作です。上記の例のリレーション変数を結合することで、データベースからすべての Customers、Orders、および Invoicesをクエリできます。特定の顧客のタプルのみが必要な場合は、制限条件を使用してこれを指定します。顧客123のすべての Orders を取得したい場合は、データベースをクエリして、 Customer ID 123の Order テーブルのすべての行を返すことができます。

上記のデータベース設計には欠陥があります。Invoice relvar には Order ID 属性が含まれています。そのため、Invoice relvar の各タプルには 1 つの Order ID が含まれ、これは各請求書に対して正確に 1 つの注文が存在することを意味します。しかし実際には、1 つの請求書は複数の注文に対して作成される場合もあれば、特定の注文に対して作成される場合もあります。さらに、Order relvar には Invoice ID 属性が含まれており、各注文に対応する請求書が存在することを意味します。しかしこれも現実世界では必ずしもそうではありません。1 つの注文が複数の請求書で支払われる場合もあれば、請求書なしで支払われる場合もあります。つまり、1 つの注文に対して複数の請求書が存在し、1 つの請求書に対して複数の注文が存在する可能性があります。これは、注文と請求書の間の多対多の関係 (非特定関係とも呼ばれます) です。この関係をデータベースで表現するには、注文と請求書の対応関係を指定する役割を持つ新しい relvar を導入する必要があります。

OrderInvoice (注文ID、請求書ID )

さて、Order関連変数とInvoice関連変数は、OrderInvoiceテーブルに対して1対多の関係を持っています。特定の注文のすべての請求書を取得したい場合は、 Order関連変数のOrder IDがOrderInvoiceのOrder IDと等しく、かつOrderInvoiceのInvoice IDがInvoiceのInvoice IDと等しいすべての注文をクエリできます。

SQLは当初、リレーショナルデータベースの標準言語として推進されましたが、いくつかの点でリレーショナルモデルから逸脱しています。現在のISO SQL規格では、リレーショナルモデルについて言及しておらず、リレーショナル用語や概念も使用していません。

関係モデルによれば、リレーションの属性とタプルは数学的な集合であり、順序付けされておらず、一意である。SQLテーブルでは、行も列も適切な集合ではない。テーブルには重複する行と重複する列の両方が含まれる可能性があり、テーブルの列は明示的に順序付けられている。SQLは欠損データを示すためにNULL値を使用するが、これは関係モデルには対応する値がない。行は未知の情報^を表す可能性があるため、SQLは関係モデルの情報原則に準拠していない。^{[ 7 ]： 153-155、162}

関係制約の中で最も単純かつ重要なタイプの1つがキー制約です。これは、特定の関係スキーマのすべてのインスタンスにおいて、タプルが特定の属性の値によって識別できることを示しています。

スーパーキー

スーパーキーとは、連結された列の値がすべての行で一意となる列ヘッダーのセットのことです。正式には、次のようになります。

スーパーキーは、属性名の有限集合として記述されます。

スーパーキー${\displaystyle K}$関係において保持する${\displaystyle (H,B)}$もし：

• ${\displaystyle K\subseteq H}$そして
• 異なる2つのタプルは存在しない${\displaystyle t_{1},t_{2}\in B}$そのため${\displaystyle t_{1}[K]=t_{2}[K]}$。

スーパーキーはリレーションユニバース内で保持されます${\displaystyle U}$すべての関係においてそれが成り立つ場合${\displaystyle U}$。

定理：スーパーキー${\displaystyle K}$関係の宇宙で保持する${\displaystyle U}$以上${\displaystyle H}$かつその場合に限り${\displaystyle K\subseteq H}$そして${\displaystyle K\rightarrow H}$保持する${\displaystyle U}$。

候補キー

候補キーとは、それ以上分割して別のスーパーキーを形成することができないスーパーキーのことである。

スーパーキー${\displaystyle K}$関係ユニバースの候補キーとして保持する${\displaystyle U}$スーパーキーとして保持される場合${\displaystyle U}$そして、真部分集合は存在しない${\displaystyle K}$スーパーキーとしても保持される${\displaystyle U}$。

機能的依存性

関数従属性とは、タプル内の値が、そのタプル内の別の値から導き出せる性質のことである。

関数従属性（略してFD）は次のように記述されます。${\displaystyle X\rightarrow Y}$のために${\displaystyle X,Y}$属性名の有限集合。

機能的依存性${\displaystyle X\rightarrow Y}$関係において保持する${\displaystyle (H,B)}$もし：

• ${\displaystyle X,Y\subseteq H}$そして
• ${\displaystyle \forall }$タプル${\displaystyle t_{1},t_{2}\in B}$、${\displaystyle t_{1}[X]=t_{2}[X]~\Rightarrow ~t_{1}[Y]=t_{2}[Y]}$

機能的依存性${\displaystyle X\rightarrow Y}$関係の宇宙で保持する${\displaystyle U}$すべての関係においてそれが成り立つ場合${\displaystyle U}$。

些細な関数依存性

ヘッダーの下では関数従属性は自明である${\displaystyle H}$もしそれが全ての関係宇宙で成り立つならば${\displaystyle H}$。

定理： FD${\displaystyle X\rightarrow Y}$見出しの下では些細なことです${\displaystyle H}$かつその場合に限り${\displaystyle Y\subseteq X\subseteq H}$。

閉鎖

アームストロングの公理：関数従属性の集合の閉包${\displaystyle S}$見出しの下${\displaystyle H}$と表記される${\displaystyle S^{+}}$は、の最小のスーパーセットです。${\displaystyle S}$すなわち、

• ${\displaystyle Y\subseteq X\subseteq H~\Rightarrow ~X\rightarrow Y\in S^{+}}$（再帰性）
• ${\displaystyle X\rightarrow Y\in S^{+}\land Y\rightarrow Z\in S^{+}~\Rightarrow ~X\rightarrow Z\in S^{+}}$（推移性）
• ${\displaystyle X\rightarrow Y\in S^{+}\land Z\subseteq H~\Rightarrow ~(X\cup Z)\rightarrow (Y\cup Z)\in S^{+}}$（拡張）

定理：アームストロングの公理は健全かつ完全である。ヘッダーが与えられた場合${\displaystyle H}$そしてセット${\displaystyle S}$FD のサブセットのみを含む${\displaystyle H}$、${\displaystyle X\rightarrow Y\in S^{+}}$かつその場合に限り${\displaystyle X\rightarrow Y}$すべての関係宇宙において成り立つ${\displaystyle H}$すべてのFDが${\displaystyle S}$保持する。^{[ 11 ]}

完了

有限個の属性の完了${\displaystyle X}$有限個のFDの下で${\displaystyle S}$と表記される${\displaystyle X^{+}}$は、の最小のスーパーセットです。${\displaystyle X}$すなわち、

• ${\displaystyle Y\rightarrow Z\in S\land Y\subseteq X^{+}~\Rightarrow ~Z\subseteq X^{+}}$

属性セットの完了度合いは、特定の依存関係が関数従属性のセットの閉包に含まれているかどうかを計算するために使用できます。

定理：集合が与えられたとき${\displaystyle S}$FDの、${\displaystyle X\rightarrow Y\in S^{+}}$かつその場合に限り${\displaystyle Y\subseteq X^{+}}$。

還元不可能なカバー

セットの還元不可能なカバー${\displaystyle S}$FD の集合は${\displaystyle T}$次のようなFD：

• ${\displaystyle S^{+}=T^{+}}$
• 存在しない${\displaystyle U\subset T}$そのため${\displaystyle S^{+}=U^{+}}$
• ${\displaystyle X\rightarrow Y\in T~\Rightarrow Y}$はシングルトンセットであり、
• ${\displaystyle X\rightarrow Y\in T\land Z\subset X~\Rightarrow ~Z\rightarrow Y\notin S^{+}}$。

関数従属性から候補キーを導出するアルゴリズムは、入力:ヘッダーHのサブセットのみを含む FD の集合S 、出力:候補キーとして保持されるスーパーキーの集合C です。H 上のすべての関係ユニバースであって、 Sのすべての FDが成り立つもの C := ∅ // 候補キーが見つかった Q := { H } // 候補キーを含むスーパーキー while Q <> ∅ do let K をQ の要素とするQ := Q  – { K } minimal := true for each X->Y in S do K' := ( K  – Y ) ∪ X // 新しいスーパーキーを導出 if K' ⊂ K then minimal := false Q := Q ∪ { K' } end if end for if minimalかつCにKの部分集合がない場合は、CからK のすべてのスーパー集合を削除するC := C ∪ { K } end if end while