リレーショナルモデル(RM )は、1969年にイギリスのコンピュータ科学者エドガー・F・コッドによって初めて説明された一階述語論理と一致する構造と言語を使用してデータを管理するアプローチであり、[1] [2]すべてのデータはタプルで表現され、関係にグループ化されます。リレーショナルモデルに基づいて編成されたデータベースは、リレーショナルデータベースです。
リレーショナル モデルの目的は、データとクエリを指定するための宣言的な方法を提供することです。つまり、ユーザーはデータベースに含まれる情報とデータベースから取得したい情報を直接指定し、データベース管理システム ソフトウェアが、データを格納するためのデータ構造とクエリに応答するための取得手順の記述を処理します。
ほとんどのリレーショナル データベースはSQLデータ定義とクエリ言語を使用します。これらのシステムは、リレーショナル モデルに対するエンジニアリング近似と見なせるものを実装しています。SQLデータベース スキーマ内のテーブルは述語変数に対応し、テーブルの内容はリレーションに対応し、キー制約、その他の制約、および SQL クエリは述語に対応します。ただし、SQL データベースは多くの点でリレーショナル モデルから逸脱しており、Codd は元の原則を損なう逸脱に対して激しく反対しました。[3]
歴史
リレーショナルモデルは、データの一般的なモデルとしてエドガー・F・コッドによって開発され、その後クリス・デイトやヒュー・ダーウェンなどによって推進されました。1995年の「第三の宣言」で、デイトとダーウェンは、リレーショナルモデルがどのようにして特定の「望ましい」オブジェクト指向機能に対応できるかを実証しようとしました。[4]
拡張機能
1970年のモデルの発表から数年後、コッドは欠損情報に対処するために3値ロジック(True、False、欠損/ NULL )バージョンを提案し、さらに1990年の著書『データベース管理のためのリレーショナルモデル バージョン2』ではさらに一歩進んで4値ロジック(True、False、欠損はあるが適用可能、欠損はあるが適用不可)バージョンを提案した。[5]
概念化
基本概念

リレーションは、見出しと本体から構成されます。見出しは、それぞれが名前とデータ型(ドメインと呼ばれることもあります)を持つ属性のセットを定義します。このセット内の属性の数は、リレーションの次数またはアリティです。本体はタプルのセットです。タプルはn個の値のコレクションであり、nはリレーションの次数であり、タプル内の各値は一意の属性に対応します。[6] このセット内のタプルの数は、リレーションのカーディナリティです。[7] :17–22
関係は関係変数またはrelvarsによって表され、再割り当てが可能です。[7] :22–24 データベースはrelvarsの集合です。[7] :112–113
このモデルでは、データベースは情報原則に従います。つまり、データベース内のすべての情報は、属性に対応するタプル内の値のみで表現され、関係はrelvarsによって識別されます。 [7] : 111
制約
データベースは、任意のブール式を制約として定義することができます。すべての制約がtrueと評価された場合、データベースは一貫しています。そうでない場合は、データベースは不整合です。データベースの relvars への変更によりデータベースが不整合な状態になる場合、その変更は不正であり、成功してはいけません。[7] : 91
一般に、制約は関係比較演算子を使用して表現されますが、理論的には「サブセットである」(⊆) という演算子 1 つだけで十分です。[引用が必要]
制約の 2 つの特殊なケースは、キーと外部キーとして表現されます。
キー
候補キー、または単にキーは、リレーション内の各タプルを一意に区別することが保証された属性の最小のサブセットです。リレーション内の各タプルは一意でなければならないため、すべてのリレーションには必ずキーがあり、キーは属性の完全なセットである場合があります。各タプルを一意に区別する方法が複数ある場合があるため、リレーションには複数のキーがある場合があります。[7] : 31–33
属性は、キーでなくても、タプル間で一意である場合があります。たとえば、会社の従業員を表すリレーションには、ID と名前という 2 つの属性がある場合があります。現在同じ名前を持つ従業員がいなくても、最終的に現在の従業員と同じ名前の新しい従業員を雇う可能性がある場合、属性サブセット {名前} はキーではありません。逆に、サブセット {ID} がキーである場合、これは現在ID を共有する従業員がいないだけでなく、今後も ID を共有する従業員がいないことを意味します。[7] : 31–33
外部キー
外部キーとは、別の関係R 2のキーに対応する関係R 1の属性{A}のサブセットであり、 {A}へのR 1の射影は{A}へのR 2の射影のサブセットであるという性質を持つ。言い換えれば、R 1のタプルに外部キーの値が含まれている場合、対応するキーの同じ値を含む対応するタプルがR 2に存在しなければならない。 [7] : 34
関係演算
ユーザー (またはプログラム) は、クエリを送信してリレーショナル データベースからデータを要求します。クエリに応じて、データベースは結果セットを返します。
多くの場合、複数のテーブルのデータは、結合によって 1 つに結合されます。概念的には、これは行の可能な組み合わせ (デカルト積) をすべて取得し、答え以外のすべてをフィルタリングすることによって行われます。
結合以外にも、関係演算は多数あります。これらには、射影 (一部の列を削除する処理)、制限 (一部の行を削除する処理)、結合 (類似の構造を持つ 2 つのテーブルを結合する方法)、差 (一方のテーブルにあり、もう一方のテーブルにはない行をリストする)、積 (両方のテーブルにある行をリストする)、積 (前述のように、一方のテーブルの各行をもう一方のテーブルの各行と結合する) が含まれます。参照する他のソースに応じて、他の演算子が多数あります。その多くは、上記の演算子に基づいて定義できます。これらには、準結合、外部結合や外部結合などの外部演算子、およびさまざまな形式の除算が含まれます。さらに、列の名前を変更する演算子、要約または集計演算子、および関係値を属性として許可する場合 (関係値属性)、グループ化やグループ化解除などの演算子があります。
リレーショナル データベースの柔軟性により、プログラマーはデータベース設計者が想定していなかったクエリを作成できます。その結果、リレーショナル データベースは、元の設計者が予期していなかった方法で複数のアプリケーションで使用できます。これは、長期間 (数十年) 使用される可能性のあるデータベースにとって特に重要です。これにより、リレーショナル データベースのアイデアと実装は、企業で非常に人気が高まっています。
データベースの正規化
リレーションは、脆弱な異常の種類に基づいて分類されます。第 1 正規形のデータベースは、すべての種類の異常に対して脆弱ですが、ドメイン/キー正規形のデータベースには変更異常はありません。正規形は本質的に階層的です。つまり、最下位レベルは第 1 正規形であり、データベースは、まず下位の正規形の要件をすべて満たさなければ、上位レベルの正規形の要件を満たすことはできません。[8]
論理的解釈
リレーショナルモデルは形式的なシステムです。関係の属性は論理 命題の集合を定義します。各命題はタプルとして表現できます。関係の本体はこれらのタプルのサブセットであり、どの命題が真であるかを表します。制約は、真でなければならない追加の命題を表します。リレーショナル代数は、これらの命題から結論を正当に 推論できる論理ルールの集合です。[7] : 95–101
タプルの定義では、属性の空集合に対応する、値を持たない唯一の空のタプルが許される。関係の次数が 0 の場合(つまり、見出しに属性が含まれない場合)、その関係はカーディナリティ 0 (本体にタプルが含まれない)またはカーディナリティ 1 (本体に単一の空のタプルが含まれる)のいずれかになる。これらの関係はブール値の 真理値を表す。次数が 0 でカーディナリティ 0 の関係はFalseであり、次数が 0 でカーディナリティ 1 の関係はTrueである。[7] : 221–223
例
Employees の関係に属性{Name, ID}が含まれている場合、タプル{Alice, 1}は命題「ID 1のAliceという名前の従業員が存在する」を表します。この命題は真または偽です。このタプルが関係の本体に存在する場合、命題は真 (そのような従業員が存在する) です。このタプルが関係の本体にない場合、命題は偽 (そのような従業員は存在しない) です。[7] : 96–97
さらに、{ID}がキーの場合、タプル{Alice, 1}と{Bob, 1}を含む関係は次の矛盾を表します。
- Aliceという名前と ID 1 を持つ従業員が存在します。
- Bobという名前と ID 1 を持つ従業員が存在します。
- 同じIDを持つ従業員は複数存在しません。
爆発原理によれば、この矛盾により、システムは任意の命題が真であると証明できる。データベースはこれを防ぐためにキー制約を強制する必要がある。[7] : 104
例
データベース
いくつかのrelvars (関係変数) とその属性の記述の理想的で非常に単純な例:
- 顧客 (顧客ID、名前)
- 注文 (注文 ID、顧客 ID、請求書 ID、日付)
- 請求書 (請求書 ID、顧客 ID、注文 ID、ステータス)
この設計には、Customer、Order、および Invoice の 3 つの relvars があります。太字の下線付きの属性は候補キーです。太字でない下線付きの属性は外部キーです。
通常、1 つの候補キーが選択され、主キーと呼ばれ、他の候補キー(代替キーと呼ばれる) よりも優先して使用されます。
候補キーは、タプルが重複しないことを強制する一意の識別子です。これにより、セットの基本定義に違反して、リレーションが別のもの、つまりバッグになります。外部キーとスーパーキー (候補キーを含む) は両方とも複合キーにすることができます。つまり、複数の属性で構成できます。以下は、例の Customer relvar のリレーションを表形式で表したものです。リレーションは、relvar に帰属できる値と考えることができます。
顧客関係
ID 123の新しい顧客を挿入しようとすると、顧客 IDが主キーであり、すでに顧客123が存在するため、relvar の設計に違反することになります。DBMSは、整合性制約違反によってデータベースの整合性が失われるこのようなトランザクションを拒否する必要があります。ただし、 Name フィールドは主キーの一部ではないため、この新しい顧客が一意の ID を持っている限り、 Aliceという名前の別の顧客を挿入することは可能です。
外部キーは、属性セットの値が別のリレーションの候補キーから取得されることを強制する整合性制約です。たとえば、 Order リレーションでは、属性Customer ID は外部キーです。結合は、複数のリレーションから一度に情報を取得する操作です。上記の例の relvars を結合することで、データベースに対して、すべての Customers、Orders、および Invoices を照会できます。特定の顧客のタプルのみが必要な場合は、制約条件を使用してこれを指定します。 Customer 123のすべての Orders を取得する場合は、データベースに対してクエリを実行して、 Customer IDが123である Order テーブルのすべての行を返すことができます。
上記のデータベース設計には欠陥があります。請求書の relvar には注文 ID 属性が含まれています。そのため、請求書の relvar の各タプルには注文 ID が 1 つ含まれ、各請求書に対して注文が 1 つだけあることを意味します。しかし、実際には、請求書は複数の注文に対して作成される場合もあれば、特定の注文に対して作成される場合もあります。さらに、注文の relvar には請求書 ID 属性が含まれているため、各注文には対応する請求書があることを意味します。しかし、これも現実世界では常に当てはまるとは限りません。注文は複数の請求書で支払われることもあれば、請求書なしで支払われることもあります。つまり、注文ごとに請求書が多数あり、請求書ごとに注文が多数ある可能性があります。これは、注文と請求書の間の多対多の関係です (非特定関係とも呼ばれます)。この関係をデータベースで表すには、注文と請求書の対応を指定する役割を持つ新しい relvar を導入する必要があります。
OrderInvoice (注文 ID、請求書 ID )
これで、Order relvar は、Invoice relvar と同様に、OrderInvoice テーブルと1 対多の関係を持つようになりました。特定の Order のすべての Invoice を取得する場合は、 Order 関係のOrder ID がOrderInvoice のOrder IDと等しく、OrderInvoice のInvoice ID がInvoice のInvoice IDと等しいすべての注文をクエリできます。
リレーショナルデータベースへの応用
リレーショナル データベースのデータ型は、整数のセット、文字列のセット、日付のセットなどです。リレーショナル モデルでは、サポートされる型は指定されません。
属性は通常、列、タプルは行、リレーションはテーブルとして表されます。テーブルは列定義のリストとして指定され、各列定義は一意の列名とその列に許可される値の型を指定します。属性値は、特定の列と行のエントリです。
データベースrelvar (関係変数) は、一般にベース テーブルと呼ばれます。割り当てられた値の見出しは、常にテーブル宣言で指定されたとおりであり、本体は更新演算子(通常は INSERT、UPDATE、または DELETE) によって最後に割り当てられた値です。クエリの評価から得られるテーブルの見出しと本体は、そのクエリで使用される演算子の定義によって決まります。
SQL とリレーショナル モデル
当初はリレーショナル データベースの標準言語として推進されていた SQL は、いくつかの点でリレーショナル モデルから逸脱しています。現在のISO SQL 標準では、リレーショナル モデルについて言及されておらず、リレーショナル用語や概念も使用されていません。[要出典]
リレーショナル モデルによれば、リレーションの属性とタプルは数学的なセットであり、順序付けされておらず一意である。SQL テーブルでは、行も列も適切なセットではない。テーブルには重複する行と重複する列の両方が含まれる場合があり、テーブルの列は明示的に順序付けされている。SQL では、欠落データを示すためにNull値を使用するが、リレーショナル モデルにはこれに相当するものがない。行は未知の情報を表すことがあるため、SQL はリレーショナル モデルの情報原則に準拠していない。[7] : 153–155, 162
集合論的定式化
リレーショナル モデルの基本概念は、リレーション名と属性名です。これらは、「Person」や「name」などの文字列として表され、通常は変数とを使用して範囲を指定します。もう 1 つの基本概念は、数値や文字列などの値を含む アトミック値のセットです。
最初の定義は、テーブル内の行またはレコードの概念を形式化する タプルの概念に関するものです。
次の定義は、リレーショナル モデルで定義されているようにテーブルの内容を形式化する リレーションを定義します。
- 関係
- リレーションは、ヘッダー と本体 を持つタプルであり、すべてのドメイン を持つタプルのセットです。
このような関係は、通常、一階述語論理の述語の拡張と呼ばれるものと密接に対応していますが、ここでは述語内の場所を属性名で識別します。通常、リレーショナル モデルでは、データベース スキーマは、一連の関係名、これらの名前に関連付けられたヘッダー、およびデータベース スキーマのすべてのインスタンスに保持される 制約で構成されると言われています。
- 関係宇宙
- ヘッダー上の関係ユニバースは、ヘッダーを持つ空でない関係の集合です。
- リレーションスキーマ
- リレーション スキーマは、ヘッダーと、ヘッダーを持つすべてのリレーションに対して定義される述語で構成されます。リレーションは、ヘッダーを持ち、を満たす場合、リレーション スキーマを満たします。
主要な制約と機能的依存関係
関係制約の最も単純かつ最も重要なタイプの 1 つは、キー制約です。これは、特定のリレーショナル スキーマのすべてのインスタンスで、タプルが特定の属性の値によって識別できることを示しています。
スーパーキーは、連結された列の値がすべての行にわたって一意となる列ヘッダーのセットです。正式には次のようになります。
- スーパーキーは、属性名の有限セットとして記述されます。
- スーパーキーは、次の場合に関係に保持されます。
- そして
- となるような2 つの異なるタプルは存在しません。
- スーパーキーは、関係ユニバース内のすべての関係で保持される場合に、関係ユニバースでも保持されます。
- 定理:スーパーキーが上の関係宇宙で成立するのは、および がで成立する場合に限ります。
- 候補キー
候補キーは、さらに細分化して別のスーパーキーを形成することができないスーパーキーです。
機能的依存性とは、タプル内の値がそのタプル内の別の値から派生する可能性があるという特性です。
- 関数依存性 (略して FD) は、属性名の有限集合として記述されます。
- 関数従属関係は次の場合に成立します。
- そして
- タプル、
- 関数従属性は、関係宇宙内のすべての関係において成立する場合に成立します。
- 単純な機能的依存関係
- 関数従属性は、 上のすべての関係ユニバースで成り立つ場合、ヘッダーの下で自明です。
- 定理: FD がヘッダーの下で自明であるためには、かつその場合に限ります。
- 閉鎖
- アームストロングの公理:ヘッダー の下のFD 集合の閉包はと書かれ、次のようなの最小のスーパーセットです。
- (反射性)
- (推移性)と
- (増強)
- 定理:アームストロングの公理は健全かつ完全です。ヘッダーと、のサブセットのみを含む FD の集合が与えられた場合、内のすべての FD が成り立つ 上のすべての関係宇宙で が成り立つ場合のみ、 が成り立ちます。
- 完了
- 有限の FD 集合の下での有限の属性集合の完備化は、 と書かれ、次のような の最小のスーパーセットです。
- 属性セットの完了は、特定の依存関係が FD セットの閉包内にあるかどうかを計算するために使用できます。
- 定理: FD の集合が与えられた場合、 の場合に限ります。
- 還元不可能なカバー
- FD の集合の既約被覆とは、次のような FD の集合です。
- そのようなものは存在しない
- は単一集合であり、
- 。
関数従属性から候補キーを導出するアルゴリズム
関数従属性から候補キーを導出するアルゴリズムは、
入力:ヘッダーHのサブセットのみを含むFDの集合S 、出力:候補キーとして保持されるスーパーキーの集合Cである。
Sのすべての FDが成り立つH
上のすべての関係宇宙
C := ∅ // 候補キーが見つかりました
Q := { H } // 候補キーを含むスーパーキー
while Q <> ∅ do 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
代替案
その他のモデルには、階層型モデルやネットワークモデルなどがある。これらの古いアーキテクチャを使用するシステムの中には、大量のデータを必要とするデータセンターや、既存のシステムが非常に複雑で抽象的であるため、リレーショナルモデルを採用したシステムに移行するにはコストがかかりすぎるような場所で現在でも使用されているものがある。また、新しいオブジェクト指向データベース[ 9]やDatalog [10]も注目に値する。
Datalog は、リレーショナル モデルのようなデータのリレーショナル ビューと、ロジック プログラミングのような論理ビューを組み合わせたデータベース定義言語です。リレーショナル データベースでは、リレーショナル計算またはリレーショナル代数を使用し、和集合、積集合、差集合、直積などのリレーショナル演算を使用してクエリを指定しますが、Datalog では、 if、or、notなどの論理接続詞を使用して、データベース自体の一部として関係を定義します。
最小固定小数点演算子を導入しなければ再帰クエリを表現できないリレーショナルモデルとは対照的に、[11] Datalogでは新しい論理接続子や演算子を導入することなく再帰関係を定義できます。
参照
注記
参考文献
- ^ Codd, EF (1969)、大規模データバンクに格納された関係の導出可能性、冗長性、一貫性、調査レポート、IBM。
- ^ Codd, EF (1970). 「大規模共有データバンクのリレーショナルデータモデル」Communications of the ACM . クラシック. 13 (6): 377–87. doi : 10.1145/362384.362685 . S2CID 207549016. 2007-06-12 にオリジナルからアーカイブ。
- ^ Codd, E. F (1990)、『データベース管理のためのリレーショナルモデル』、Addison-Wesley、pp. 371–388、ISBN 978-0-201-14192-4。
- ^ 「デイトとダーウェンの『第三の宣言』は永続的な影響を与えたか?」。Computer Science Stack Exchange 。 2024年8月3日閲覧。
- ^ Date, Christopher J. (2006). 「18. 3 値および 4 値ロジックが機能しない理由」。データベースの Date: Writings 2000–2006。Apress。pp. 329–41。ISBN 978-1-59059-746-0。
- ^ 「DBMS のタプル」GeeksforGeeks 2023 年 2 月 12 日。2024年 8 月 3 日閲覧。
- ^ abcdefghijklm Date, Chris J. (2013).コンピュータプロフェッショナルのためのリレーショナル理論: リレーショナルデータベースの本質とは(第 1 版). セバストポル、カリフォルニア州: O'Reilly Media. ISBN 978-1-449-36943-9。
- ^ David M. Kroenke,データベース処理: 基礎、設計、実装(1997)、Prentice-Hall, Inc.、130~144 ページ
- ^ Atkinson, M., Dewitt, D., Maier, D., Bancilhon, F., Dittrich, K. および Zdonik, S.、1990。オブジェクト指向データベース システム宣言。演繹的およびオブジェクト指向データベース (pp. 223-240)。North-Holland。
- ^ Maier, D., Tekle, KT, Kifer, M. および Warren, DS、2018。「Datalog: 概念、歴史、および展望」。『宣言型論理プログラミング: 理論、システム、およびアプリケーション』(pp. 3-100)。
- ^ Aho, AV および Ullman, JD、1979 年 1 月。データ検索言語の普遍性。プログラミング言語の原理に関する第 6 回 ACM SIGACT-SIGPLAN シンポジウムの議事録 (pp. 110-119)。
さらに読む
- Date, Christopher J. ; Darwen, Hugh (2000)。将来のデータベース システムの基礎: 第 3 のマニフェスト。型継承の包括的なモデルを含む、データのリレーショナル モデルに対する型理論の影響に関する詳細な研究(第 2 版)。マサチューセッツ州レディング: Addison-Wesley。ISBN 978-0-201-70928-5。
- ——— (2007).データベースシステム入門(第8版)ボストン:ピアソンエデュケーション。ISBN 978-0-321-19784-9。
