リレーショナルデータベース（RDB）とは ― 表・行・列と表どうしのつながり

リレーショナルデータベース（RDB）とは、データを複数の表に分けて持ち、表どうしを共通の列でつないで扱うデータベースです。会員と注文、商品と在庫のような業務データの多くは、RDBの表に入っています。SQLを書くときも、テーブルを設計するときも、相手にするのはこの表です。

データベースにはRDB以外の種類もあります。どんな種類があるかはデータベースとはの記事で、表の形を使わない種類との違いはNoSQLの記事で説明しています。

RDBは、日本語で関係データベースといいます。ここでいう「関係」は表を指し、日常語の「関係」とは意味が違います。RDBの理論である関係モデルでは、表を関係（リレーション）と呼びますが、以下では表と書きます。

テーブルは行と列でできています。行の1件分をレコード、列の1つをフィールドと呼びます。

関係モデルの用語では、行をタプル、列を属性と呼びます。表から行や列を取り出す操作と、表どうしをつなぐ操作をまとめて、関係演算と呼びます。

表と列の定義がデータベースの構造のどの層に当たるかは、3層スキーマの記事を読むと分かります。

RDBでは、決まった列の値で表の行を見分けます。この列を主キーと呼びます。次の顧客テーブルでは、顧客IDが主キーです。

顧客IDの値は、行ごとに重ならないようにします。この決まりを一意性制約と呼びます。主キーには、空の値（NULL）も使えません。空の値では、どの行かを決められないためです。顧客IDのような値の付け方は、コード設計の記事にまとめました。

主キーの選び方や、複数の列を組にした複合キーは、主キーと外部キーの記事で詳しく説明しています。

RDBは、顧客と注文のように表を分けてデータを持ち、同じ値を入れた列で表どうしをつなぎます。次の注文テーブルでは、顧客IDの列が顧客テーブルの行を指しています。このように別の表の主キーと同じ値を持ち、その行を指す列を外部キーと呼びます。

注文5001と注文5003は、どちらも顧客ID101を指しています。このように、1人の顧客は複数の注文を持てます。主キーと違い、外部キーは複数の行で同じ値を使ってかまいません。

次の図は、注文テーブルの外部キーが、顧客テーブルのどの行を指すかを示しています。どちらの列にも、同じ顧客IDの値が入ります。

次の図で注文を選ぶと、その外部キーが指す顧客の行を表示します。

外部キーの値は、参照先の主キーに存在する値でなければなりません。この決まりを参照制約と呼びます。外部キーを設定してあれば、存在しない顧客IDを注文テーブルに入れようとしても、DBMSが拒否します。

参照制約で拒否される操作は、主キーと外部キーの記事で、操作を選んで確かめられます。SQLで主キーや外部キーを定義する書き方は、CREATE TABLEと制約の記事で説明しています。

ここまでの例は、すでにできあがったテーブルです。実際の設計では、テーブルを作る前に、顧客や注文のような管理の対象（エンティティ）を洗い出し、どう関連付けるかを決めます。その考え方は、E-R図の記事で説明しています。

• PostgreSQL Documentation「Constraints」（主キー・外部キーの制約）
• MySQL 8.4 Reference Manual「FOREIGN KEY Constraints」（外部キーの制約と削除時の動作）