|
関係モデル
関係モデル（かんけいモデル、リレーショナルモデル、英語: 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]
このように実体化した組は真と評価される命題とみなすことができる。なぜかというと、関係の本体にその組が登場するからである。これに対し逆に、見出しが関係の見出しに適合するが関係の本体に存在しない全ての組は偽と評価される命題である。 この一つ前の文の根底にある仮説は閉世界仮説として知られており、関係モデルは閉世界仮説に依拠している。 関係の本体は述語論理の文脈では「外延」と呼ばれる。これは関係の本体が関係変数述語の外延として表現されると解釈できることが理由である。 データベースへの適用関係データベースにおける典型的な定義域は、整数型、文字列型、論理型などである。定義域の名前は、"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標準の全てを実装しているデータベース管理システム (DBMS) はほとんど存在しない。 ここで述べる関係モデルからの逸脱のいくつかについては、ほとんどの SQL DBMS で逸脱している。 NULLはほとんどの SQL DBMS にも存在するが、一つの表（関係モデルでは関係変数に相当）に同じ名称を2つ（以上）の列（属性に相当）に重複してつけることができるかどうか、名前の無い列が許容されるかどうかについては、SQL DBMS ごとにさまざまである。
実装エドガー・F・コッドが考案しクリス・デイトやヒュー・ダーウェンなどの人々により説明されてきた意味での、関係モデル（リレーショナルモデル）に基づいた関係データベース管理システム (RDBMS) の真の実装を開発しようという試みは、これまでいくつか行われてきた。しかし2008年現在の時点では広く採用されるに至った成功例は無い。近年のこうした試みの一つとして Dataphor (Alphora社) という RDBMS がある。 論争エドガー・F・コッド自身は、1970年に関係モデル（リレーショナルモデル）を公表して数年後に、欠損情報を扱うために関係モデルの三値論理バージョンを提唱した。そして論文 The Relational Model for Database Management Version 2 (1990) における関係モデルの四値論理バージョンの提唱へとさらに一歩踏み出した。しかしこれらが実装されることは全く無かった。その理由はおそらくそのモデルが複雑であったためであろう。 SQLのNULLの概念は三値論理システムの一部をなすものと想定されていた。しかしSQL標準とその実装に含まれた論理的齟齬によりすぐに崩壊した。 先の#SQL標準の節を参照。 論理設計→詳細は「データベース設計」を参照
関係の正規化は、多くの場合関係データベースの設計時にデータベース設計の論理的整合性とトランザクション性能の向上をめざして、行われる。 2008年現在、論理設計を関係モデルの視覚的表現により効果的に行うために、3つの図（ダイアグラム）の体系が広く使われている。
データを木構造で表現しようとすると、関係変数群を親子関連をもつ階層型モデルの構造にしなければならなくなるであろう。 データベース例簡単な複数の関係変数と属性の設計例
以上を表にすると、以下のようになる。
注文表
注文明細表
請求書表
請求書明細表
製品表
この設計では次の6つの関係変数がある。
太字でかつ下線のついた属性の集合は候補キー（candidate key）である。太字でない下線のついた属性は外部キー (foreign key) である。 一つの関係変数に複数の候補キーがある場合は、複数の候補キーから一つを任意で選び主キー (primary key) とする。候補キーが一つである場合は、必然的にその候補キーが主キーとなる。主キーは他の候補キーよりも選好して使われる。主キー以外の候補キーを代理キー (alternate key) と呼ぶ (ただしこのデータベース設計例では代理キーは無い) 。 候補キーは一意識別子 (unique identifier) であり、関係変数に組の重複を許さないよう強制するはたらきがある。組の重複が有ると集合の基本的定義に違反することとなり関係ではない別のもの（bag; バッグ）になってしまう。外部キーとスーパーキー（superkey; 候補キーを部分集合として含むキー）は複合している場合がある。つまり一つではなく複数の属性から構成されている場合がある。 次に顧客関係変数を表形式で記述する。関係は関係変数に割り当てられる値（関係値）と考えることができる。 例: 顧客関係変数
新しい 顧客ID 1234567890 をもつ顧客の「追加」を試みると、この追加は関係変数の設計に違反するため失敗する。 なぜなら 顧客ID は主キーであり顧客関係変数には既に顧客 1234567890 が存在するからである。 RDBMSは、整合性制約に違反することにより関係データベースを不整合な状態にするこのようなトランザクションを、拒絶しなければならない。 外部キーは、整合性制約であり、外部キーの値が別の関係の候補キーのいずれかの値に合致することを強制する。 例えば注文関係においては 顧客ID 属性が外部キーである。 結合は、複数の関係から一度に情報を引き出す演算である。 先の例の複数の関係で結合を行うことにより、全ての顧客、注文、請求書のデータを検索することができる。 もしこのとき特定の顧客に関する情報だけ必要なのであれば、制限条件を使って結合を行えば良い。 顧客 1234567890 の全ての注文を検索したい場合には、顧客ID 1234567890 をもつ全ての注文関係の組を取得し、取得した結果に対して 注文番号 に基づいて注文明細関係と結合すれば良い。 先に示したデータベース設計には欠陥がある。請求書関係変数が注文番号属性をもっているのである。これは、請求書関係変数の各々の組が一つずつ注文番号をもつということである。このことは各々の請求書にはそれぞれ必ず一つの注文があるということである。しかし現実には、一つの請求書は複数の注文に対して発行することができる。また注文無しの請求書が実際に発行されることもあろう。さらに、注文関係変数は請求書番号属性をもつ。これは各々の注文はそれぞれ対応する一つの請求書をもつことを意味する。 しかし現実世界ではこれは必ずしも真ではない。一つの注文が複数の請求書を通して発行される場合もある。また請求書無しで支払いを行うこともあるであろう。すなわち、複数の請求書が一つの注文と対応することがあり、複数の注文が一つの請求書に対応することがある。これは注文と請求書の間に「多対多」の関連があるということである（「特定の関連は無い」ともいう）。この関連を関係データベースで表現するために、新しい関係変数を導入する必要があるであろう。 この新しい関係変数の役割は注文と請求書の関連を指定することである: 注文請求書（注文番号、請求書番号）
ここで、注文関係変数は注文請求書関係変数との間に、注文関係変数と顧客関係変数の間の関連と同じく、一対多関連がある。 特定の注文に対する全ての請求書を検索したい場合、
という条件をつけて全ての請求書を検索することができる。 脚注
参考文献
関連項目
外部リンク
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
