関係データベース




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


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




目次






  • 1 関係モデル


    • 1.1


      • 1.1.1 例について(備考)






  • 2 脚注


  • 3 関連項目





関係モデル





関係モデルの概念



関係モデルは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




関連項目




  • 関係モデル(リレーショナルモデル)

    • 関係(リレーション)

    • 候補キー

    • 主キー

    • 外部キー

    • 関係の正規化

    • 関係代数 (関係モデル)


    • 関係論理(関係計算)




  • 関係データベース管理システム - 関係データベース管理システムの比較


  • トランザクション
    • ACID (コンピュータ科学)



  • データ完全性(一貫性制約)


  • データベース言語/問い合わせ言語

    • SQL

    • QUEL

    • Tutorial D



  • データベース設計

  • データモデリング

  • オブジェクト関係データベース

  • オブジェクトデータベース








Popular posts from this blog

How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

is 'sed' thread safe

How to make a Squid Proxy server?