関係データベース
関係データベース（かんけいデータベース、リレーショナルデータベース、英: relational database）は関係モデル（リレーショナルデータモデル、後述）にもとづいて設計、開発されるデータベースである。
現在では、データベースという語が関係データベースを指していることが多い。関係データベースを管理するためのソフトウェアを関係データベース管理システム (RDBMS) と呼ぶ。
Oracle Database、Microsoft SQL Server、MySQL、PostgreSQL、DB2、FileMaker、H2 Database などのデータベース管理システム (DBMS) がサポートするのは関係データベースである。関係データベースに含まれないデータベースは、NoSQL などを参照。
関係モデル
関係モデルはIBMのエドガー・F・コッドによって考案された[1]現在もっとも広く用いられているデータモデルである。複数の関係（リレーション）を基本的なデータ型とする。データベースの利用者は、クエリ（問い掛け）をデータベースに与え、複数の関係を連結させてデータを検索したり、変更することができる。
データは表に似た構造で管理され、複数のデータ群が関係（リレーション）と呼ばれる構造で相互連結可能である。関係は組（タプル、表における行に相当する）、属性（アトリビュート、表における列に相当する）、定義域（ドメイン）、候補キー（主キー）、外部キーなどによって構成される。SQLなどに代表されるデータベース言語（問い合わせ言語）を用いて、関係に対して制限・射影・結合・和・差・交わりなどの関係代数演算（集合演算を含む）ないし関係論理演算を行うことで結果を取り出す。
例
例えばある食品を扱う（架空の）通信販売会社における顧客管理データベースでは、顧客リストと物品販売リストは別々のデータ群であるが、顧客管理番号や顧客名などで連結して情報を抽出することが可能である。これを図表であらわすと、以下の通りになる。
- 食品通信販売会社におけるデータベースの例（※データは架空のもの）
| 顧客番号 | 顧客氏名 | 住所1 | 住所2 | 電話番号 |
|---|---|---|---|---|
| 00001 | 相田孝之 | 東京都新宿区 | 歌舞伎町x-x-x | 03-xxxx-xxxx |
| 00002 | 伊藤美香 | 神奈川県横浜市 | 中区山下町xx | 045-xxx-xxxx |
| 00003 | 内田浩二 | 埼玉県さいたま市 | 高砂xx-xx | 048-xxx-xxxx |
| ⋮ | ⋮ | ⋮ | ⋮ | ⋮ |
| 販売日 | 顧客番号 | 商品1 | 商品2 | 商品3 | …… |
|---|---|---|---|---|---|
| 050115 | 00002 | 吟醸灘一本 | 特選おつまみ | ||
| 050116 | 00001 | 神戸和牛セット | |||
| 050116 | 00003 | 特売・生ハム | 粒マスタード | マリーローランサン | |
| 050117 | 00001 | 薩摩黒豚ハム | |||
| ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ |
例えばこの二つのデータ群を顧客番号で関連付け、顧客番号の代わりに顧客氏名のデータを要求すると、以下のような表になる。通販会社では、これを見て、顧客がどういう物を好むか判断して、新商品の案内を送ったらいいかが把握できる。
| 顧客氏名 | 商品1 | 商品2 | 商品3 | …… |
|---|---|---|---|---|
| 相田孝之 | 神戸和牛セット | |||
| 相田孝之 | 薩摩黒豚ハム | |||
| 伊藤美香 | 吟醸灘一本 | 特選おつまみ | ||
| 内田浩二 | 特売・生ハム | 粒マスタード | マリーローランサン | |
| ⋮ | ⋮ | ⋮ | ⋮ | ⋮ |
また販売日を050116（2005年1月16日）で限定して、顧客番号で関連付け、商品と送り先（顧客住所）のデータを要求すると以下のとおり。通販会社はこれを見て、箱に注文された商品を入れ、宅配便の送り状に宛先を記入して商品発送を行うことができる。
| 送り先住所1+2 | 顧客氏名 | 商品1 | 商品2 | 商品3 | …… |
|---|---|---|---|---|---|
| 東京都新宿区歌舞伎町x-x-x | 相田孝之 | 神戸和牛セット | |||
| 埼玉県さいたま市高砂xx-xx | 内田浩二 | 特売・生ハム | 粒マスタード | マリー | …… |
| ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ |
このように、目的に合わせてデータを連結させ、求める表を得ることができるのが関係データベースの最大の特徴である。なおデータを連結する際の目安となる項をキーと呼ぶが、このキーは、全てのデータに一貫して一意である必要がある。この例では顧客番号がキーであるが、同じ顧客番号で複数の会員が登録されていると、データの抽出に異常が発生する（実際はそのような不適切な重複キーを登録する時点で、クエリエラーとして返信されてくる）。
この様式は、相互のデータベースが別々に存在していることで、各々のデータベース内容の変更に対応させやすく、また相互連結をクエリによって行うことで、逐次的に部分的な登録内容の変更がなされても、随時最新の情報を利用できる点で優れている。上記の例で例えるなら、顧客番号00001の相田氏が引越しをして住所が変った際に、顧客データベースだけを変更して、再び各々の同じクエリ（問い掛け）をデータベースに送信すれば、住所変更後のデータに更新されたものが返信されてくることとなる。
例について（備考）
なお上記の例では、説明の便宜上で顧客データベースと販売データベースという2つのテーブル（上に述べたリスト状のデータ群）に分けたが、実際にこのような業務を行うデータベースでは、さらに商品リストのテーブルが別に設けられ、この商品データベースでは各々の商品定価などの情報が管理される（もっといえば、商品データベースも様々な要素でいくつものテーブルに分解されるだろう）など、いくつものテーブルが複雑に連携しあって利用者にデータを提供するよう設計される。これはテーブル上のデータが重複する冗長性を避け、よりデータを管理しやすくするためである。これらもやはりキーによって相互連結されて利用される。
一度きちんと設計されたデータベースでは、複数のクエリもあらかじめ定型文（定型クエリ）の形で用意され、利用者は何も考えずに用意された定型のクエリを投げ掛けることで、随時最新のデータを元にした表を見ることができる。
これが実際の業務に利用されるアプリケーションソフトウェアの形ともなると、グラフィカルユーザインターフェース (GUI) などの操作画面を持ち、利用者は画面上のボタンをクリックすることで、プログラム内部でクエリ文が組み合わせによって生成され、データベースに投げ掛けられ、戻ってきたデータをアプリケーション側で処理し、適切な画面上に表示されたり、表計算ソフトで開くためのファイル形式で答えが出力・提供されたりすることとなるため、最終的な利用者側ではクエリや関係 (リレーション) 等は全くと言ってよいほどに意識されていないことが多い。
典拠
- ↑ E. F. Cood(1969) "A Relational Model of Data for Large Shared Data Banks" IBM Research Laboratory, California. 全文：http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
.PNG){kind=link}
