Wikipedia

関係モデル

関係モデル（かんけいモデル、リレーショナルモデル、英語: relational model）はエドガー・F・コッドが集合論と述語論理に基づいて考案したデータベースモデルであり、関係データベース（リレーショナルデータベース）の基礎となっている。

モデル

編集

関係モデル（リレーショナルモデル）における基本的な前提は、あらゆるデータは n 項（n-ary）の関係（リレーション）で表現されるということである。 数学における関係は二項関係をいうが、関係モデルでは関係の概念を n 項に拡張している（nは0もしくは正の整数）。 一つの n 項の関係は、n個の定義域（ドメイン、後述する）の直積集合の部分集合である。

数学モデルでは推論は二値の述語論理で行う。 すなわち個々の命題について真か偽かのいずれかの評価を行う。 数学の命題は真か偽かの二値であり「未知の値」(unknown) や「不適切な値」(not applicable) のような第三の値は無い。 なおコンピュータ科学では「未知の値」や「不適切な値」はしばしばnullに対応づけられる。

関係モデルにおいては、二値論理が関係モデルの重要な要素であり三値論理を許容すべきでないと考える人々と、三値論理を関係モデルで許容できると考える人々がおり、研究者の間で見解が分かれている。

関係モデルではデータ（関係）の演算は関係代数あるいは関係論理（関係計算）を使って行う。 関係代数と関係論理は同等の演算能力をもつ。

関係モデルを活用することにより、関係データベースでデータベースを設計（データベース設計）する人はデータベースに格納する対象となる情報を、整合性を備え論理的に表現することができる。情報の整合性は、データベース設計で制約の宣言を行うことで実現することができる。

ここでいうデータベース設計は論理設計（スキーマ）と呼ばれることが多い。

関係モデルの理論には、関係の正規化という過程がある。 関係を正規化することにより、関係データベースであるデータベースの設計から、論理的に同等であり、かつ、いくつかの意味でより望ましい特性をもつデータベース設計を、導き出すことができる。一方で、アクセスプランの算出やその他関係モデルの実装、データ演算の詳細は、関係データベース管理システム（RDBMS）のエンジンにより制御されるのであって、論理設計は関知しない。論理設計はRDBMSでパフォーマンスチューニングのためによく行われる実践とは水準が異なる。ただしこうしたパフォーマンスチューニングでは論理設計の変更を必要とすることも多い。

 
関係モデルの概念

関係モデルの基礎的な要素は定義域; instance（ドメイン; domain）である。定義域はデータ型と同じ意味と考えて良い。現在は型（タイプ; type）と略されることも多い。

属性 (attribute) は、属性名と型名（定義域名）のペアから構成される。属性の名前と値のコンポーネントの順序づけられていない集合を組（タプル; tuple）という。属性値は、属性の定義域に適合する具体的な値である。属性値は、スカラ値もしくはより複雑な構造をもつ値である。

関係（リレーション; relation）は、見出し (heading) と本体 (body) から構成される。 見出しは順序づけられていない属性の集合である。本体は順序づけられていない組の集合である。n 項の関係の本体は n 組の集合から構成される。ある関係の見出しはその関係に含まれる組の見出しでもある。

関係は n 組の集合として定義される。数学の文脈においても、関係モデルの文脈においても、集合とは順序づけられていない要素の集まりである。

こうしたシステムは、関係モデルに準拠していないとして批判されることがある。数学では、組に含まれる要素間には順序が存在し、要素の重複は許容される。

関係モデルを考案したエドガー・F・コッドは、当初はこの数学上の定義を使って組を定義していた[1]。 後に組の概念は変更されたが、組という概念名は変わっていない。この優れた組の概念により、直ちに重要な帰結として、関係モデルの関係代数の直積演算において交換法則が成立した。

現在、表（テーブル; table）は関係の視覚的表現として広く受け容れられている。組は表の行 (row) の概念に似ている。 データベース言語 SQL では、表の列（カラム; column）が順序づけられていることに注意する必要がある。SQL は関係モデルに準拠していないとして批判されることがあり[誰?]、こうした順序づけの存在は批判の根拠の一つとなっている。

関係変数（リレーション変数; relvar; relation variable）は、特定の関係型の名前つきの変数である。どの時点においても、関係変数にはその型に対応した何らかの関係（関係値）が割り当てられている。関係が含む組の数は0の場合もある。

関係モデルの基本的な原理は情報の原理である。あらゆる情報は関係に含まれるデータとして表現される。この原理から導き出されることとして、関係データベースは関係変数の集合であり、関係データベースに対するあらゆる検索の結果は関係として表現される。

関係データベースには整合性が強制的に適用される。関係データベースで論理スキーマの一部として整合性の制約が宣言され、RDBMS によって関係データベースにアクセスするあらゆるアプリケーションソフトウェアに対して強制的に適用される。関係データベースにアクセスするアプリケーションソフトウェアに関係データベースの整合性の規則を実装する必要があるわけではない。一般的に、制約は関係比較演算子を使って表現される。整合性制約を記述するには、理論的にはただ一つの関係比較演算子「—は—の部分集合である」(⊆) だけで十分である。実際には、便利ないくつかの短縮記法を使うことができるであろう。その中でもとりわけ重要なのは、候補キー（candidate key; 実際にはスーパーキー superkey）、外部キー (foreign key) の各制約である。

述語論理での解釈

編集

関係モデルの理解を深めるためには、関係の別の解釈、すなわち述語論理での解釈を理解することが、一つの方法である。このことについての説明をクリス・デイトの著書から引用する。[2]

  • まず、すべての関係変数には述語が関連づけられており、その関係変数の関係変数述語と呼ばれる。
  • 関係変数 R が述語 P を持つとすれば、ある時点で R に含まれる組 t はすべて、特定の命題 p を表すものと考えることができる。この命題は、t に含まれている属性値を引数として、その時点の P を呼び出す（またはインスタンス化する）ことによって得られる。
  • そして（非常に重要だが）このようにして得られた命題 p は、慣例として、それぞれ真に評価されると想定される。

このように実体化した組は真と評価される命題とみなすことができる。なぜかというと、関係の本体にその組が登場するからである。これに対し逆に、見出しが関係の見出しに適合するが関係の本体に存在しない全ての組は偽と評価される命題である。

この一つ前の文の根底にある仮説は閉世界仮説として知られており、関係モデルは閉世界仮説に依拠している。

関係の本体は述語論理の文脈では「外延」と呼ばれる。これは関係の本体が関係変数述語の外延として表現されると解釈できることが理由である。

データベースへの適用

編集

関係データベースにおける典型的な定義域は、整数型、文字列型、論理型などである。定義域の名前は、"int"、"char"、"boolean" など一連の名前が規定される。

属性は関係のデータ構造の一部として宣言され、属性の宣言ではその属性名と定義域の名前を指定する。組はデータベース言語として SQL を採用しているデータベースでは基本的に行と同じ概念である。

属性名の例は "name" や "age" などである。属性値は、特定の組の特定の属性に含まれる具体的な値（エントリ）であり、例えば "John Doe" や "35" などである。

関係は表に似たデータ構造の仕様でありまたデータ（本体）を含んでいる。見出しは関係のデータ構造の宣言である。本体は関係のデータ構造に含まれるデータである。

他のデータベースモデル

編集

関係モデル（リレーショナルモデル）以外のデータベースのモデルとしては、階層型データモデルやネットワーク型データモデルがある。 これらの古いアーキテクチャを使ったいくつかのシステムが、現在もデータセンターで使われており、大容量のデータを扱う必要がある場合や、既存のシステムが非常に複雑であるために関係モデルを採用したシステムに移行するには多大な費用を要する場合などに、使われている。

新しいデータモデルとしてはオブジェクト指向のデータモデルがあり、近年ではオブジェクトデータベースを使うことができるようになっている。 2009年現在では関係データベースと比べると使われる事例は少ないものの、少しずつ採用され始めている。 オブジェクトデータベースの有用性については見解が分かれている。 オブジェクトデータベースにはオブジェクト指向プログラミング言語との親和性が高いという特長がある。 一方で一部の人々は、オブジェクトデータベース管理システム (ODBMS) の多くは正統的な DBMS（データベース管理システム）というよりもむしろ DBMS 構築キットであるとして、あまり有用な技術とは認識していない。

関係モデルは形式化された最初のデータモデルである。関係モデルが定義された後に、非形式的なデータモデルが、階層型データベース（階層型データモデル）やネットワーク型データベース（ネットワーク型データモデル）を記述するために作られていった。階層型データベースとネットワーク型データベースは、関係データベース以前に既に存在していた。しかしそれらがモデルとして記述されたのは、関係モデルが定義された後のことであり、その目的はデータモデル間の比較をするための基礎を確立するためであった。

歴史

編集

19世紀のドイツの数学者ゲオルク・カントールは、集合論を考案した。

アメリカ合衆国の数学者 D・L・チャイルズは1968年の論文 "Description of a Set-Theoretic Data Structure" において、データやデータの検索を集合と集合演算を用いて表現する、集合論データ構造を考案した。集合と集合演算を採用することにより物理的データ構造からの独立性が実現された。これは当時としては先駆的な業績であった。

エドガー・F・コッドは、1970年の論文 "A Relational Model of Data for Large Shared Data Banks" で、関係モデル（リレーショナルモデル）をデータの一般モデルとして考案した。この論文では、チャイルズの1968年の論文も引用している。

その後、関係モデルは多くの人々によりモデルの修整や改良が行われた。クリス・デイトとヒュー・ダーウェンは著書 The Third Manifesto（第1版は1995年に出版された）において、関係モデルがその基本原理を損なうこと無く望ましい形でオブジェクト指向機能に対応する技法を提示した。

SQL標準

編集

SQL（Structured Query Language）は、最初に関係データベースの標準言語となったが、いくつかの面で関係モデル（リレーショナルモデル）から逸脱している。SQLは、これらの関係モデルからの逸脱を根拠として批判されることがある（Date C. J. "Database in Depth" 参照）。2008年現在、ISO SQL 標準は、関係モデルに言及しておらず、関係モデルの用語も概念も使っていない。しかしSQLを使って関係モデルに適合するデータベースを構築することは、いくつかのSQLの機能を使わなければ、可能である。

まずSQLの用語とそれに相当する関係モデルの用語の対応関係を示す。

SQLの用語と関係モデルの用語の対応関係
SQLの用語 関係モデルの用語
表（テーブル; table） 関係変数（リレーション変数; relvar; relation variable）
行（row） 組（タプル; tuple）
列（カラム; column） 属性（attribute）

以下にSQL標準における関係モデルからの逸脱を記述する。ただしSQL標準の全てを実装しているデータベース管理システム (DBMS) はほとんど存在しない。 ここで述べる関係モデルからの逸脱のいくつかについては、ほとんどの SQL DBMS で逸脱している。

NULLはほとんどの SQL DBMS にも存在するが、一つの表（関係モデルでは関係変数に相当）に同じ名称を2つ（以上）の列（属性に相当）に重複してつけることができるかどうか、名前の無い列が許容されるかどうかについては、SQL DBMS ごとにさまざまである。

行の重複
SQLの一つの表では、同一内容の行が2回以上出現することを許容する。関係モデルの一つの関係変数では、同一内容の組が2回以上出現することはありえない。
名前の無い列
SQLの表では、名前の無い列が存在することがあり、このためそのような列はSQLの式では参照できない。関係モデルでは、あらゆる属性に名前が必要であり参照可能である必要がある。
列の名前の重複
SQLの一つの表では、2つ以上の列に対して同じ名前をつけることができ、このためそのような列は明らかにあいまいでありSQLの式では参照できない。関係モデルの一つの関係変数では、2つ以上の属性に対して同じ名前をつけることはできず、そのためあらゆる属性は参照可能である。
列の順序づけの重要性
SQLの表では、列の順序が定義されており重要である。この結果の一つとして直積と和の演算のSQL実装は交換法則が成立する演算ではなくなっている。関係モデルの関係変数では、列は順序づけられていないため、直積演算と和演算における交換法則が成立する。
CHECK OPTION の無いビュー
SQL では CHECK OPTION をつけずに定義されたビューに対して更新を行うことができる。しかしその結果そうしたビューへの更新は必ずしも更新対象（当該ビュー）に反映されるわけではない。例えばSQLでは、ビューに対する INSERT の実行は可能であるが、追加された行がビューに反映されないことがある。またビューに UPDATE を行った場合、ビューから更新対象データが消える可能性がある。関係モデルでは、ビューに対する更新は基底関係変数に対する更新と同じ結果になることが必要である。
表は必ず1つ以上の列を持つ
SQLでは表は少なくとも1つの列を持つ必要があり、列が0個である表は定義できない。関係モデルでは属性が0個である関係が2つ存在する。そのうち1つは濃度（組の数）が1つであり、もう1つの関係は濃度が0である。関係モデルにおいてこの2つの関係は自由変数が0個である述語の外延を表現するために必要である。
NULL
NULLという特別な印（マーク）は、ある行のある列の値など、原則としてどこであれSQLの値を設定できるところであれば値の代わりにつけることができる。この関係モデルからの逸脱は、SQLにおいてこの場当たり的な概念の実装が三値論理の採用と関連しているという事実から、生じる。三値論理においては、NULLをNULL自身と比較すると真（true）とは評価されず、unknown という第三の値に評価される。またNULLをNULL以外の何かと比較すると偽（false）とは評価されず、unknown と評価される。比較におけるこのような振る舞いのために、NULLは値ではなく印（マーク）であると説明されるのである。関係モデルは排中律に依拠している。排中律のもとでは、真と評価されないものは何であれ偽と評価され、偽と評価されないものは何であれ真と評価される。関係モデルでは、関係の本体の全ての組の全ての属性には必ず値が割り当てられている。この逸脱は一部の人々の間で論争の対象となった。なぜなら、エドガー・F・コッド自身が最終的に特殊な印と四値論理の採用を提唱したからである。ただしこの四値論理の提唱はコッドの見解に基づいていた。コッドの見解とは値の代わりに特殊な印をつけたいと思う背景には2つの異なる理由があるということである。こうした経緯はさらに多くの異なる理由の発見するであろうような四値論理の採用に対する反対者を招き、19もの異なる理由が言及された。その場合は二十一値論理が必要となるであろう。SQL自体は、NULLを「未知の値」の表現以外にもいくつかの用途に使っている。例えば、空集合にSUM関数（合計値計算）を適用するとNULLとなる。これは0を意味する。空集合の平均値はNULLである。これは未定義を意味する。NULLは左外部結合の結果でも現れる。これは「右側には対応する行が存在しないため値は無い」を意味する。

実装

編集

エドガー・F・コッドが考案しクリス・デイトやヒュー・ダーウェンなどの人々により説明されてきた意味での、関係モデル（リレーショナルモデル）に基づいた関係データベース管理システム (RDBMS) の真の実装を開発しようという試みは、これまでいくつか行われてきた。しかし2008年現在の時点では広く採用されるに至った成功例は無い。近年のこうした試みの一つとして Dataphor (Alphora社) という RDBMS がある。

論争

編集

エドガー・F・コッド自身は、1970年に関係モデル（リレーショナルモデル）を公表して数年後に、欠損情報を扱うために関係モデルの三値論理バージョンを提唱した。そして論文 The Relational Model for Database Management Version 2 (1990) における関係モデルの四値論理バージョンの提唱へとさらに一歩踏み出した。しかしこれらが実装されることは全く無かった。その理由はおそらくそのモデルが複雑であったためであろう。

SQLのNULLの概念は三値論理システムの一部をなすものと想定されていた。しかしSQL標準とその実装に含まれた論理的齟齬によりすぐに崩壊した。 先の#SQL標準の節を参照。

論理設計

編集
→詳細は「データベース設計」を参照

関係の正規化は、多くの場合関係データベースの設計時にデータベース設計の論理的整合性とトランザクション性能の向上をめざして、行われる。

2008年現在、論理設計を関係モデルの視覚的表現により効果的に行うために、3つの図（ダイアグラム）の体系が広く使われている。

データを木構造で表現しようとすると、関係変数群を親子関連をもつ階層型モデルの構造にしなければならなくなるであろう。

データベース例

編集

簡単な複数の関係変数と属性の設計例

  • 顧客（顧客ID、税ID、名前、住所、市、県、郵便番号、電話番号）
  • 注文（注文番号、顧客ID、請求書番号、注文日、納品予定日、条件、状況）
  • 注文明細（注文番号、請求書番号、製品コード、数量）
  • 請求書（請求書番号、顧客ID、注文番号、日付、状況）
  • 請求書明細（請求書番号、明細番号、製品コード、出荷数量）
  • 製品（製品コード、製品名）

以上を表にすると、以下のようになる。
顧客表

顧客ID 税ID 名前 住所 市 県 郵便番号 電話番号

注文表

注文番号 顧客ID 請求書番号 注文日 納品予定日 条件 状況

注文明細表

注文番号 請求書番号 製品コード 数量

請求書表

請求書番号 顧客ID 注文番号 日付 状況

請求書明細表

請求書番号 明細番号 製品コード 出荷数量

製品表

製品コード 製品名

この設計では次の6つの関係変数がある。

  • 顧客、注文、注文明細、請求書、請求書明細、製品

太字でかつ下線のついた属性の集合は候補キー（candidate key）である。太字でない下線のついた属性は外部キー (foreign key) である。

一つの関係変数に複数の候補キーがある場合は、複数の候補キーから一つを任意で選び主キー (primary key) とする。候補キーが一つである場合は、必然的にその候補キーが主キーとなる。主キーは他の候補キーよりも選好して使われる。主キー以外の候補キーを代理キー (alternate key) と呼ぶ (ただしこのデータベース設計例では代理キーは無い) 。

候補キーは一意識別子 (unique identifier) であり、関係変数に組の重複を許さないよう強制するはたらきがある。組の重複が有ると集合の基本的定義に違反することとなり関係ではない別のもの（bag; バッグ）になってしまう。外部キーとスーパーキー（superkey; 候補キーを部分集合として含むキー）は複合している場合がある。つまり一つではなく複数の属性から構成されている場合がある。

次に顧客関係変数を表形式で記述する。関係は関係変数に割り当てられる値（関係値）と考えることができる。

例: 顧客関係変数

編集
顧客ID 税ID 名前 住所
1234567890 555-5512222 Jo Lee 323 Broadway
2223344556 555-5523232 Dorothy Red 1200 Main Street
3334445563 555-5533322 Linda de la Cruz 871 1st Street
4232342432 555-5325523 E. F. Codd 123 It Way

新しい 顧客ID 1234567890 をもつ顧客の「追加」を試みると、この追加は関係変数の設計に違反するため失敗する。 なぜなら 顧客ID は主キーであり顧客関係変数には既に顧客 1234567890 が存在するからである。 RDBMSは、整合性制約に違反することにより関係データベースを不整合な状態にするこのようなトランザクションを、拒絶しなければならない。

外部キーは、整合性制約であり、外部キーの値が別の関係の候補キーのいずれかの値に合致することを強制する。 例えば注文関係においては 顧客ID 属性が外部キーである。 結合は、複数の関係から一度に情報を引き出す演算である。 先の例の複数の関係で結合を行うことにより、全ての顧客、注文、請求書のデータを検索することができる。 もしこのとき特定の顧客に関する情報だけ必要なのであれば、制限条件を使って結合を行えば良い。

顧客 1234567890 の全ての注文を検索したい場合には、顧客ID 1234567890 をもつ全ての注文関係の組を取得し、取得した結果に対して 注文番号 に基づいて注文明細関係と結合すれば良い。

先に示したデータベース設計には欠陥がある。請求書関係変数が注文番号属性をもっているのである。これは、請求書関係変数の各々の組が一つずつ注文番号をもつということである。このことは各々の請求書にはそれぞれ必ず一つの注文があるということである。しかし現実には、一つの請求書は複数の注文に対して発行することができる。また注文無しの請求書が実際に発行されることもあろう。さらに、注文関係変数は請求書番号属性をもつ。これは各々の注文はそれぞれ対応する一つの請求書をもつことを意味する。

しかし現実世界ではこれは必ずしも真ではない。一つの注文が複数の請求書を通して発行される場合もある。また請求書無しで支払いを行うこともあるであろう。すなわち、複数の請求書が一つの注文と対応することがあり、複数の注文が一つの請求書に対応することがある。これは注文と請求書の間に「多対多」の関連があるということである（「特定の関連は無い」ともいう）。この関連を関係データベースで表現するために、新しい関係変数を導入する必要があるであろう。

この新しい関係変数の役割は注文と請求書の関連を指定することである:

注文請求書（注文番号、請求書番号）
これを表にすると、以下のようになる。
注文請求書表

注文番号 請求書番号

ここで、注文関係変数は注文請求書関係変数との間に、注文関係変数と顧客関係変数の間の関連と同じく、一対多関連がある。 特定の注文に対する全ての請求書を検索したい場合、

  • 注文関係の 注文番号 は注文請求書関係の 注文番号 と等しく
  • 注文請求書関係の 請求書番号 は請求書関係の 請求書番号 と等しい

という条件をつけて全ての請求書を検索することができる。

脚注

編集
[脚注の使い方]
  1. ^ Codd, E.F. (1970). “A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM 13 (6): 377–387. http://www.acm.org/classics/nov95/toc.html. 
  2. ^ Date, C. J. ほか (2006) p.78

参考文献

編集

関連項目

編集

外部リンク

編集
「https://ja.wiki.x.io/w/index.php?title=関係モデル&oldid=83426880」から取得