PROFILPELAJAR.COM

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

Oracle Database、Microsoft SQL Server、MySQL、PostgreSQL、DB2、FileMaker、H2 Database などがRDBMSである^[1] 。

関係モデル

→詳細は「関係モデル」を参照

関係モデルは、IBMのエドガー・F・コッドが考案し^[2]、現在もっとも広く用いられるデータモデルである。データベースの利用者は、クエリ（問い掛け）をデータベースに与え、データを検索したり、変更することができる。

データは表に似た構造で管理されるが、関係（リレーション）と呼ぶ概念でモデル化される。関係（リレーション）は組（タプル、表における行に相当する）、属性（アトリビュート、表における列に相当する）、定義域（ドメイン）、候補キー（主キー）、外部キーなどによって構成される。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) などの操作画面を持ち、利用者は画面上のボタンをクリックすることで、プログラム内部でクエリ文が組み合わせによって生成され、データベースに投げ掛けられ、戻ってきたデータをアプリケーション側で処理し、適切な画面上に表示されたり、表計算ソフトで開くためのファイル形式で答えが出力・提供されたりすることとなるため、最終的な利用者側ではクエリや関係 (リレーション) 等は全くと言ってよいほどに意識されていないことが多い。

脚注

^ 関係データベースに含まれないデータベースは、NoSQL などを参照。
^ 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