関係データベース

出典: フリー百科事典『ウィキペディア（Wikipedia）』

関係データベース (かんけい—) は関係モデル（リレーショナルデータモデル、後述）にもとづいて設計、開発されるデータベースである。リレーショナルデータベースとも言う。

現在では、データベースという語が関係データベースを指していることが多い。関係データベースを管理するためのソフトウェアを関係データベース管理システム (RDBMS) と呼ぶ。

Oracle、SQL Server、MySQL、PostgreSQL、DB2、FileMaker、などのデータベース管理システムがサポートするのは関係データベースである。なお、現在でも利用されている関係データベースに含まれないデータベースには、IBMのIMSなどがある。

[編集] 関係モデル

関係モデルの概念

詳細は関係モデルを参照

IBMのエドガー・F・コッドによって考案された現在もっとも広く用いられているデータモデルである。複数の関係 (リレーション) を基本的なデータ型とする。データベースの利用者は、クエリ（問い掛け）をデータベースに与え、複数の関係を連結させてデータを検索したり、変更する事ができる。

データは表に似た構造で管理され、複数のデータ群が関係（リレーション）と呼ばれる構造で相互連結可能である。関係は組（タプル、表における行に相当する）、属性（アトリビュート、表における列に相当する）、定義域（ドメイン）、キーなどによって構成される。SQLなどに代表される問い合わせ言語 (データベース言語) を用いて、関係に対して選択・射影・結合・和・差・交わりなどの関係代数演算 (集合演算を含む) ないし関係論理演算を行うことで結果を取り出す。

[編集] 例

例えばある食品を扱う（架空の）通信販売会社における顧客管理データベースでは、顧客リストと物品販売リストは別々のデータ群であるが、顧客管理番号や顧客名などで連結して情報を抽出する事が可能である。これを図表であらわすと、以下の通りになる。

食品通信販売会社におけるデータベースの例（※データは架空のもの）

顧客
顧客番号　顧客氏名 　 住所１　　　　　住所２　　　　　電話番号
00001　　　相田孝之　　東京都新宿区　　歌舞伎町x-x-x　　03-xxxx-xxxx
00002　　　伊藤美香　　神奈川県横浜市　中区山下町xx 　　045-xxx-xxxx
00003　　　内田浩二　　埼玉県浦和市　浦和市高砂xx-xx　048-xxx-xxxx
　　　・
　　　・
　　　・

販売
販売日　顧客番号　　商品１　　　　商品２　　　　商品３・・・
050115　　00002　　　吟醸灘一本　　　特選おつまみ
050116　　00001　　　神戸和牛セット
050116　　00003　　　特売・生ハム　　粒マスタード　マリーローランサン
050117　　00001　　　薩摩黒豚ハム
　　　・
　　　・
　　　・

例えばこの二つのデータ群を顧客番号で関連付け、顧客番号の代わりに顧客氏名のデータを要求すると、以下のような表になる。通販会社では、これを見て、顧客がどういう物を好むか判断して、新商品の案内を送ったらいいかが把握できる。

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

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

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

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

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

[編集] 例について（備考）

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

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

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