関係データベース

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

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

Oracle DatabaseMicrosoft SQL ServerMySQLPostgreSQLDB2FileMakerH2 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 薩摩黒豚ハム

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

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

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

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

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

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

例について(備考)[編集]

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

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

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

脚注[編集]

  1. ^ 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

関連項目[編集]