アール‐ディー‐ビー【RDB】
読み方:あーるでぃーびー
《relational database》⇒リレーショナルデータベース
リレーショナル‐データベース【relational database】
読み方:りれーしょなるでーたべーす
データベースの方式の一。また、その方式で設計されたデータベース。データを複数の項目で構成された表で表す。固有の管理番号や項目名により、データを容易に抽出したり、結合したりできる。コンピューターを利用したデータベースの中では、最も一般的に利用されている。リレーショナル型データベース。関係データデース。RDB。
かんけい‐データベース〔クワンケイ‐〕【関係データベース】
読み方:かんけいでーたべーす
《relational database》⇒リレーショナルデータベース
RDB
別名:リレーショナル・データベース
データベース・ソフトウェアはデータ構造型と関係型の2種類がある。前者は、構造設計に基づいてデータを処理、保管するデータベース。後者は構造は造らず、端末の操作時に利用者の要求に応じて、関係するデータを取り出せるようにしたデータベース。RDBの特徴は主に4つ上げられる。①プログラムとデータが独立していること。従来のコンピュータでは、プログラムの中で、データの定義を行うが、これを分離したもの。この利点はプログラムの修正が簡単に出来ること。②従来のファイル型に対してリレーション型のデータ保管型式を採用していること。例えば、注文受注ファイル、購買履歴ファイル、RFMファイルの三つを作成したとする。従来のファイル型だとひとつ一つのファイルごとにしかアクセスできない。従って、3つのファイルに氏名を入れておかなければならない。リレーション型だと氏名ファイルを造っておけば、全部のファイルに氏名がなくてもよいという利点がある。③データの取扱がレコード(行)単位ではなく属性(列)単位であることにある。従来型だと、例えばひとつのレコードが氏名、住所、電話番号、性別、年齢で構成されていたとすると、情報の画面表示は全部を表示する。属性単位だと、氏名だけ、住所だけ、氏名・年齢・性別だけとか属性ごとの表示が可能。④簡単な操作言語(高水準言語)が準備されていること。この利点は、少しコンピュータに慣れているだけで、コンピュータの専門家の手助けを借りず、自分で情報を取り出す事が可能。以上4つの特徴があるが、統合すると、修正が簡単、使いやすく、柔軟性を可能にしているソフトウェアがRDBだといえる。
リレーショナル・データベース
リレーショナルデータベース
【英】relational database, RDB
リレーショナルデータベースとは、データベースの形式の一つで、関係モデルと呼ばれる概念に基づいてデータを扱うデータベースのことである。
リレーショナルデータベースでは、データにカラム(列)とレコード(行)が与えられ、テーブル(表)の中に配置して整理されている。それぞれのカラムやレコードを中心にデータを整理し直すことで、データの抽出操作を容易にできる。
リレーショナルデータベースは現在最も普及しており、単にデータベースといった場合にはリレーショナルデータベースを指していることも多い。
リレーショナルデータベースを操作・管理するためのシステムは、リレーショナルデータベース管理システム(RDBMS)と呼ばれる。代表的なリレーショナルデータベース管理システムとしては、Oracle社のOracleや、Microsoft社のSQL Server、OSSとして配布されているMySQLやPostgreSQLなどがある。
参照リンク
Oracle
Microsoft SQL Server
MySQL
PostgreSQL
関係データベース
関係データベース
関係データベース(かんけいデータベース、リレーショナルデータベース、英: 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) などの操作画面を持ち、利用者は画面上のボタンをクリックすることで、プログラム内部でクエリ文が組み合わせによって生成され、データベースに投げ掛けられ、戻ってきたデータをアプリケーション側で処理し、適切な画面上に表示されたり、表計算ソフトで開くためのファイル形式で答えが出力・提供されたりすることとなるため、最終的な利用者側ではクエリや関係 (リレーション) 等は全くと言ってよいほどに意識されていないことが多い。
脚注
- ^ 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
関連項目
- 関係モデル(リレーショナルモデル)
- 関係(リレーション)
- 候補キー
- 主キー
- 外部キー
- 関係の正規化
- 関係代数 (関係モデル)
- 関係論理(関係計算)
- 関係データベース管理システム - 関係データベース管理システムの比較
- トランザクション
- データ完全性(一貫性制約)
- データベース言語/問い合わせ言語
- データベース設計
- データモデリング
- オブジェクト関係データベース
- オブジェクトデータベース
- 射影
- 結合(関係代数)
- 和(関係代数・関係モデル)
- 選択(関係代数・選択演算)
- relational databaseのページへのリンク