関係データベース

関係データベース（かんけいデータベース、リレーショナルデータベース、英: relational database）は、関係モデル（リレーショナルデータモデル、後述）にもとづいて設計、開発されるデータベースである。関係データベースを管理するデータベース管理システム（DBMS）を関係データベース管理システム（RDBMS）と呼ぶ。

Oracle Database、Microsoft SQL Server、MySQL、PostgreSQL、DB2、FileMaker、H2 Database などがRDBMSである関係データベースに含まれないデータベースは、NoSQL などを参照。
。

関係モデル

関係モデルは、IBMのエドガー・F・コッドが考案しE. F. Codd(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、現在もっとも広く用いられるデータモデルである。データベースの利用者は、クエリ（問い掛け）をデータベースに与え、データを検索したり、変更することができる。

データは表に似た構造で管理されるが、関係（リレーション）と呼ぶ概念でモデル化される。関係（リレーション）は組（タプル、表における行に相当する）、属性（アトリビュート、表における列に相当する）、定義域（ドメイン）、候補キー（主キー）、外部キーなどによって構成される。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
		薩摩黒豚ハム
									⋮
		⋮
		⋮
		⋮
		⋮
		⋮

この2つのデータ群を顧客番号で関連付け、顧客番号の代わりに顧客氏名のデータを要求すると、以下の表になる。通販会社は、これを参照して顧客の嗜好を判断し、新商品案内の送付を判断が可能となる。

+ 顧客名別売上
			顧客氏名
		商品1
		商品2
		商品3
		……
			相田孝之
		神戸和牛セット
									相田孝之
		薩摩黒豚ハム
									伊藤美香
		吟醸灘一本
		特選おつまみ
							内田浩二
		特売・生ハム
		粒マスタード
		マリーローランサン
					⋮
		⋮
		⋮
		⋮
		⋮

販売日を050116（2005年1月16日）で限定して、顧客番号で関連付け、商品と送り先（顧客住所）のデータを要求すると以下のとおり。通販会社はこれを参照して、注文された商品を箱に入れ、宅配便の送り状に宛先を記入して商品発送を行う。

+ 商品発送先
			送り先住所1+2
		顧客氏名
		商品1
		商品2
		商品3
		……
			東京都新宿区歌舞伎町x-x-x
		相田孝之
		神戸和牛セット
									埼玉県さいたま市高砂xx-xx
		内田浩二
		特売・生ハム
		粒マスタード
		マリー
		……
			⋮
		⋮
		⋮
		⋮
		⋮
		⋮

目的に合わせてデータを連結して求める表が得られことが関係データベースの最大の特徴である。データを連結する際の目安となる項をキーと呼ぶが、このキーは、全てのデータに一貫して一意である必要がある。この例では顧客番号がキーであるが、同じ顧客番号で複数の会員が登録されていると、データの抽出に異常が発生する。実際は不適切な重複キーを登録する時点で、クエリエラーとして返信される。

この様式は、相互のデータベースが個々に存在していることで、各々のデータベース内容の変更に対応させやすく、相互連結をクエリによって行うことで、逐次的に部分的な登録内容の変更がなされても、随時最新の情報を利用できる点で優れている。上記の例で例えるなら、顧客番号00001の相田氏が引越しをして住所が変った際に、顧客データベースだけを変更して、再び各々の同じクエリ（問い掛け）をデータベースに送信すれば、住所変更後のデータに更新されたものが返信されてくることとなる。

例について（備考）
上記例は、顧客データベースと販売データベースの2テーブル（上に述べたリスト状のデータ群）に分けたが、実際に業務を処理するデータベースは、さらに商品リストのテーブルが別に設けられ、この商品データベースでは各々の商品定価などの情報が管理される（もっといえば、商品データベースも様々な要素でいくつものテーブルに分解されるだろう）など、いくつものテーブルが連携して利用者にデータ提供を設計する。これはテーブル上のデータが重複する冗長性を避け、よりデータを管理しやすくするためである。これらもやはりキーによって相互連結されて利用される。

一度きちんと設計されたデータベースでは、複数のクエリもあらかじめ定型文（定型クエリ）の形で用意され、利用者は何も考えずに用意された定型のクエリを投げ掛けることで、随時最新のデータを元にした表を見ることができる。

これが実際の業務に利用されるアプリケーションソフトウェアの形ともなると、グラフィカルユーザインターフェース（GUI）などの操作画面を持ち、利用者は画面上のボタンをクリックすることで、プログラム内部でクエリ文が組み合わせによって生成され、データベースに投げ掛けられ、戻ってきたデータをアプリケーション側で処理し、適切な画面上に表示されたり、表計算ソフトで開くためのファイル形式で答えが出力・提供されたりすることとなるため、最終的な利用者側ではクエリやリレーション等は全くと言ってよいほどに意識されていないことが多い。

 脚注 

 関連項目 
 関係モデル（リレーショナルモデル）
 関係（リレーション）
 候補キー
 主キー
 外部キー
 関係の正規化
 関係代数 (関係モデル)
 関係論理（関係計算）
 関係データベース管理システム - 関係データベース管理システムの比較
 トランザクション
 ACID (コンピュータ科学)
 データ完全性（一貫性制約）
 データベース言語/問い合わせ言語
 SQL
 QUEL
 Tutorial D
 データベース設計
 データモデリング
 オブジェクト関係データベース
 オブジェクトデータベース
射影
結合（関係代数）
和（関係代数・関係モデル）
選択（関係代数・選択演算）

*
Category:データベース管理システム
Category:データモデリング
Category:関係モデル
Category:データベース理論
Category:エドガー・F・コッド