-
「どうして関係モデルと呼ぶのですか」という質問がときどきある。どうして表形式（tabular）モデルと呼ばないのか、理由は２つある。(1)関係モデルを考えたころ、データ処理に携わる人たちの間では、複数の対象の間の関係（あるいは関連）は、つなぎデータ構造で表現されなければならないと考える傾向があった。この誤解を迎え討つために、関係モデルという名前を選んだ。(2)関係よりも表の方が、抽象水準が低い。表は、配列と同様に位置による呼出しが可能だという印象を与えるが、ｎ項関係ではそうではない。また表の情報内容が行の順番と無関係であるという点についても、表は誤解を招きやすい。しかし、こうした小さな欠点はあるにしても、関係の概念を表現するもっとも重要な手段は、依然として表である。表といえば、誰にでもわかる。
E.F.コッド[1]
関係の定義
"関係"などと抽象的な言葉使わなくても、"表"モデルでいいじゃない。だって結局、関係って二次元表のことなんでしょ？ このもっともな疑問は、関係モデルが生まれたときから、何度も発せられてきました。「関係関係って、関係っていったい何さ？」
この問いに対して、コッド自身が理由を二つ挙げて答えています。(1) の理由は、現在の DB エンジニアにはあまり関係ありません。ですが、(2) の方は、今でも考えてみる価値があります。つまり、関係と表はよく似てはいるが違うものということです。関係と表の代表的な相違点をいくつか挙げてみましょう。
- 関係には重複する組(tuple)は存在してはならないが、表には存在してもよい。つまり、関係は通常の集合だが、表は多重集合(multiset)である。
- 関係の組は上から下へ順序づけられていないが、表の行は上から下へ順序づけられている
- 関係の属性(attribute)は左から右へ順序づけられていないが、表の列は左から右へ順序づけられている
- 関係の全ての属性値は分割不可能だが[2]、表の列の値は分割可能
さて、それでは関係の正確な定義を行ないます。定義はただ一つの式によって与えられます。
R ⊆ (D1 × D2 × D3 ・・・ × Dn)
(関係を R、属性を Ai 、その属性の定義域を Di とする)
「関係 R は定義域 D1 , D2 , ･･････ Dn の直積の部分集合である」と読みます。直積はデカルト積とも呼ばれます。簡単な例を使って説明します。まず、3つの属性 a1, a2, a3 を持つ関係 R1 があるとします。属性とは列のことです。次に各属性の定義域を、以下のように決めます。定義域は数学の関数の定義域と同じで、「属性が取りうる値の範囲」です。今、属性 a1 は1種類、属性 a2 は2種類、属性 a3 は3種類の値をとることが可能です。各属性に対応する定義域を d1, d2, d3 と呼びましょう。
d1 = { 1 }
d2 = { 男 , 女 }
d3 = { 赤, 青 , 黄 }
では問題です。この三つの定義域を使って関係を作る場合、最大いくつのタプルを持つ関係が作られるでしょう？ 答えは6。式は簡単ですね。1 × 2 × 3 です。具体的に、全部のタプルを書き並べてみるとこうです。
| a1 | a2 | a3 |
| 1 | 男 | 赤 |
| 1 | 男 | 青 |
| 1 | 男 | 黄 |
| 1 | 女 | 赤 |
| 1 | 女 | 青 |
| 1 | 女 | 黄 |
この関係 R1 が、すなわち直積です。直積とは「各属性の定義域の値を使って作りうる組み合わせの最大集合」のことです。従って、上記の三つの定義域から作られる全ての関係 Rn は、この直積の部分集合です。例えば、R1 とは別の関係 R2 を、「R1 の1行目と2行目」からなる関係、と定義することができます。また注意する点として、タプルの数が 0 の関係も定義上ありえます[3]。
これが普段、私たちが何気なく「関係」モデルとか「リレーショナル・データベース」というときに使っている「関係（relation）」の意味です。この定義を最初に与えたのは創始者のコッドですが、実際には彼はこの「関係」という名前を自分の思いつきで付けたわけではありません。というのも、集合論では昔から「二つの集合の直積の部分集合」のことを「2項関係」と呼んでいたからです。コッドはそれを n 項に拡張しただけです。彼は数学者でもありましたから、当然、集合論の関係の概念も知っていて、名前を借用したわけです。
さて、それでは関係モデルに登場する用語と、普段使われる言葉との対応を表にしてみましょう。以下のようになります。
| 形式的な関係モデルの用語 | 非形式的な日常語 |
| 関係(relation) | 表またはテーブル |
| 組(tuple) | 行またはレコード |
| 濃度(cardinality) | 行数 |
| 属性(attribute) | 列またはフィールド |
| 次数(degree) | 列数 |
| 定義域(domain) | 列の取りうる値の集合 |
いかめしい用語が登場しますが、あまり気にする必要はありません。実務で列のことを「属性」とか行数のことを「濃度」と言っても何もいいことはありません。とにかく、関係モデルは数学の集合論を基礎に作られたので、元来の定義は集合論の式で書けるし、使われる用語も集合論の用語を流用している、というだけのことです。でも、理論的な厳密さを重視する人が書いた本なんか読むと、列のことを「属性」、行のことを「組」とか「タプル」と呼んでいたりするので、このぐらいは覚えておいて損はありません。
では、最後に練習問題をどうぞ。
関係データベースにおける関係(relation)の定義として適切なものはどれか。
ア. 2次元のデータ構造のことである。
イ. 組(タプル)を構成する属性の定義域の直積の部分集合である。
ウ．属性に対応する値の集合である。
エ. 二つ以上の実体を相互に関連付けた実体である。
(テクニカルエンジニア(DB)H13 午前問23[4])
関係データモデルにおいて属性Ａ、Ｂを考える。属性Ａのドメイン（定義域）はｍ個の要素から なる集合であり、属性Ｂのドメインはｎ個の要素からなる集合である。このとき、関係Ｒを Ｒ（Ａ、Ｂ）とすると、Ｒには最大何個のタプルがあるか (テクニカルエンジニア(DB)H13 午前問30改[5])
定義域の憂鬱
-
多くの読者がすでに自分で気付いていること――つまり、定義域とは実際は（現代的なプログラミング言語において理解されているような）データ型に他ならないということを述べて本節を締めくくろう。例えば以下はプログラミング言語 Pascal における正しい表現である。
type Day = { Sun, Mon, Tue, Wed, Thu, Fri, Sat };
var Today : Day;
ここでユーザ定義のデータ型を、"Day"（正しい値をちょうど七つもっている）、そのデータ型に関して定義されたユーザ定義の変数を "Today" とよんでいる(上記の七つの値を取るように制約付けられている)。この状態は、"Day" とよばれる定義域とその定義域上で定義された属性 "Today" を持つ関係型データベースに明らかに相似している。
C.J.デイト[6]
定義域（domain）という言葉が馴染みない人も少なくないと思います。定義域を実装した DBMS がまだほとんどないので、それも当然です。関係モデルの誕生時から存在する重要なキーワードの一つなのに（定義域が定まらないと関係を決定することさえできない！）、この概念は今までずいぶん冷遇されてきました。ですが SQL-92 になってようやく標準に取り入れられたので、今後、実装する DBMS は増えると思います。
定義域を実装した DBMS がまだ少ない、という言い方は、厳密には不正確なものです。非常に原始的なレベルの定義域は、逆に今ある全ての DBMS が実装しているからです。すなわちそれは、文字型や 数値型のような、スカラ型と呼ばれるデータ型のことです。属性の取りうる値の範囲を制限しているのだから、貧弱とはいえ、スカラ型だって一応は定義域の一種に違いありません。NUMBER(5) と宣言された列に「123456」という数や「abc」という文字列を格納することはできません。また、CHECK制約を使うことで、スカラ型のみを使うよりも細かい制限を行なうこともできます。文字型で宣言した sex という列に格納可能な値を '0' と '1' に制限する、など。
だから、現在の DBMSも、簡単ながら定義域を備えてはいるのです。ただ、あまり高度なことはできません。データベースをプログラミング言語に喩えて言うなら、現在の DBMS は、最初から用意された型は使用できるが、ユーザ定義型を宣言できないプログラミング言語に相当する、と言えるでしょう。
関係値と関係変数
昔、ギリシアのヘラクレイトスは「人は同じ川に二度足を踏み入れることはできない。なぜなら川の実質は絶えず変化するから」と言い、他方、我が国の鴨長明は「ゆく河の流れは絶えずして、しかも、もとの水にあらず」と言いました。少し逆説的に響く言葉で二人が表現しようとしたことは、「物の同一性を保証する基準は何か？」という問題です。
一体、何によって保証されるのでしょう。私たち人間の体は、一週間で全ての細胞が入れ替わるそうですが、すると私たちは一週間後には別人になっているのでしょうか。今日会話を交わした友人が、明日も同一人物であると、なぜ私たちは信じるのでしょうか。
閑話休題。関係値(relation value)と関係変数(relation variable)は、混同しやすい概念ですし、実際、データベースについての議論でも、しばしば混同されて使われます。普通、何の断りもなしに「関係」という言葉が使われる場合、それは「関係変数」を意味します。
混乱の一因は、コッドの初期論文において両者の区別が曖昧だったことにもあります。彼の論文には「時間変化する（time-varying）関係」という言葉が出てきますが、これは正確には「時間変化する関係変数」のことです。関係値は時間変化しないからです。ある任意の時刻に関係変数が取る値、それが関係値です。時間断片という言い方もできるかもしれません。
これは、数学やプログラム言語における変数と値の間に成り立つ関係と同じです。プログラムにおいて整数型の変数が整数の値を格納するように、関係モデルでは、関係型の変数に関係の値が格納されます。こう考えてみれば、最初に感じたほど奇異な区別でもありません。要は、私たちが学校で習う変数や値が、大体スカラ型の単一値タイプなので、関係のような複合的存在を一つの値と見なすことに慣れていないだけだったのです。
冒頭にご登場願ったヘラクレイトスと長明に変数と値の区別を教えてあげたら、二人はどんな反応をしたでしょうね。多分、ヘラクレイトスは「くだらん！ 変数などナンセンスだ！ この世に存在するは値のみ！」と怒り出し、長明は「うんうん、数学版方丈記じゃな」と頷くだろう、というのが私の想像です。
関係の関係は可能か？
唐突に何だこの問いは、と思うかもしれませんが、まあちょっと付き合ってください。前節の「関係を一つの値と見なす」観点をさらに発展させた話なのです。「関係の関係は可能か？」という問いは、以下のようにも言い換えられます。
再帰的な関係は可能か？
あるいは、
定義域に関係を含められるか？
あるいは、
二階述語論理に基づく関係モデルは可能か？
「関係の関係」は、理論的には可能です。1969年時点のコッドも、関係モデルの基礎に二階述語論理を使おうと考えていました。その証拠に69年の論文には「関係モデルは『二階』述語論理を基礎とする」という記述があります。ですが、70年の論文ではこの部分がさりげなく「一階」に置き換えられました。
その変心の理由は、私には分かりません。おそらく二階述語論理を関係モデルに適用すると、複雑になるわりに実用的なメリットが少ない、と考えられたのでしょう。確かに、二階述語論理を実装するためには、関係を定義域に含められる述語を定義する必要がありますし、関係に対する量化まで考慮するとなると、実現するのは結構大変そうです。
そこでこの章では、日の目を見ることがなかった二階述語論理に基づく関係モデルをちらっとお目にかけましょう。まず具体的なテーブルを見てください。
| 列1 | 列2 | 列3 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
100 | ||||||||||||||||||||||||||||||
|
そんなことより>>1よ、ちょっと聞いてくれないか・・・ |
どうも雑然としたテーブルになってしまいましたが、まあ、こういうことです。文字通り「関係の中に関係がある」状態です。こういう関係を含む列（属性）のことを関係値属性（Relation-Valued Attribute）といって、現在これを関係モデルで扱うための色々な研究が行なわれています。現在の方向性としては、いきなり二階の論理に踏み出す前に、一階の論理で関係値を扱えないかどうかが検討されています。
ともあれ、こういう「関係の関係」の存在を認めるならば、当然の拡張として「関係の関係の関係」や「関係の関係の関係の関係」も出てくることになり、二階どころかいくらでも高階の関係を考えることが可能になります。この再帰的関係は、ディレクトリと同じ構造です[7]。ディレクトリの中にディレクトリやファイルを置くことができるように、関係の中にも関係値やスカラ値を置くことができます。だから、高階の関係はまた、木構造にもなっています。
このような高階の関係を定義可能な DBMS は、現在のところまだありません。しかし SQL-99 の仕様を見ると、再帰SQL やコレクション型をサポートしており、そういう方向へ向かっていることは確かです。デイトなどは「真のリレーショナルシステムとは、 [関係値など] そうしたものすべてをサポートするリレーショナルモデルをサポートするシステムのことである」とまで断言します[8]。もしかしたら10年後、高階の関係を定義可能な DBMS が登場しているかもしれません。
リレーショナル・データベースの世界
コンピュータやプログラミング言語、様々なソフトウェアやミドルウェアというのは、もちろん第一に実用的なシステムを作るための道具ですから、エンジニアが最初にするべきことは、その扱い方を覚えることです。しかしまた、他の多くの道具がそうであるように、コンピュータの背後にも設計思想や原理といったものが存在します。少し自分が仕事をする世界に慣れてくると、そういう基本原理への知識欲が沸いてきてきます。本当に面白いのはそういう部分だからです。しかも、原理は決して実践と乖離したトリビア的なムダ知識ではなく、ちゃんとエンジニアとしての技量にもプラスのフィードバックが返ってきます（もちろん、意識してそうしようと思わないとムダ知識で終わりますが）。
だから、UNIX、C言語、オブジェクト指向言語、関数型言語、インターネットなど優れた技術については、必ずその設計思想や背景の歴史を解説する書籍や Web 上のドキュメントが整備されています。
翻って、データベース界を見渡すと、入門書やベンダの新機能を宣伝する書籍は山ほどあるのですが、重要な設計思想や原理に触れた本というのは、こと日本語に限った場合ほとんど存在しません。その理由は、
リレーショナル・データベースが大した技術ではないから
…… ではありません。いや、そう考える人は多いし、若かりし日の私も不覚にもそう思い込んでいました。ですが、今はそうは思いません。リレーショナル・データベースは、真剣にその原理を理解するに値する技術だと確信しています。事実、生まれ故郷のアメリカでは、原理を分かりやすく説明する優れた解説書がちゃんと存在しています[9]。一方、日本語でアクセスできる文献としては、およそ入門向けとは言えないデイトのサイコロ本『データベースシステム概論』（約1000ページ）が、ほとんど唯一の手がかりでした。こんな状況が日本の DB エンジニアにとって良い教育環境のはずがありません。
しかし、最近徐々に事態も好転の兆しを見せています。2006年2月に、「理論は実践的だ」をモットーに現場のエンジニアに分かりやすく原理を説いた好著『C.J.Dateのデータベース実践講義』
が翻訳されました。
本稿を読んで、「もしかしてデータベースは面白い世界かもしれない」という考えが頭をよぎったそこのあなた、この世界はあなたに豊かさを発見されるのを待っています。求めよ、さらば与えられん ―― 裏返すと、求めないと何も与えられない。ここはそういう世界です。
注
[1] E.F.コッド「関係データベース：生産性向上のための実用的基礎」『ACMチューリング賞講演集』(共立出版 1989) pp.457-58
[2] 属性が分割不可能ということは、第1正規化されているということです。従って、関係モデルにおける関係は全て「第1正規化された関係」を暗黙に意味します。分割可能な属性の例は、例えば、
| 名前 |
|---|
| しゅんすけ |
| たけし きよし |
| しんすけ |
の2行目のように、一つのセルに複数の値（たけし、きよし）が含まれるような場合です。Excel で作る表などではよく見かける形式ですが、データベースのテーブルには存在しえません。
ところが、標準SQL規格であるSQL:1999にいたって、状況が一変しました。配列（ARRAY)型がサポートされることになったからです。これによって、第1正規形を満たさないテーブルを作ることが可能になってしまいました。個人的には、どうしても必要でない限り、配列型をみだりに使うべきではないと思います。
[3]濃度が0の関係は、集合論で言えば空集合に当たります。もちろん、実装レベルでは「0行のテーブル」に相当します。
[4] 正解はイ。
ア：表のことです。一見正解に見えますが、表と関係は別物です。
ウ：定義域のことです。
エ：E-Rモデルにおける関連エンティティのことです。
[5] 正解は mn 個。「タプルの最大個数」を求めるということはつまり直積を求めるということです。
[6] C.J.デイト『データベースシステム概論 第6版』(丸善 1997) p.95
[7] ファイルシステムもデータベースも、どちらもデータを効率よく保存するための構造なのだから、両者が同じ木構造を取るのは、自然なことだったかもしれません。ただ、現在のリレーショナル・データベースは一階の関係しか定義できないので、ファイルシステムに喩えれば、「深さ１のディレクトリしか定義できないファイルシステム」に相当します。この意味で、ファイルシステムに比べるとリレーショナル・データベースの表現力は「貧弱」です。
[8] C.J.デイト『C.J.Dateのデータベース実践講義』
p.33
[9] もっとも、日本よりはずっと状況がましと想像されるアメリカでも、次のような告発を読むと、程度に差はあれ同種の問題は存在するようです。
「ベンダ、商業誌、「専門家」たちがデータベース・マネジメントについて語ったり書いたりすることの多くはどうでもよく、ミスリーディングか、さもなくば端的に間違っている。これはコンピュータ全般について言えることではあるが、特にデータベース分野においては知識の欠如が甚だしいために、そんなことはないと言い張る連中がいようとも、現実に技術は退歩しているのだ！」 （F.パスカル『Practical Issues in Database Management』 序文）
Copyright (C) ミック
作成日：2002/12/01
最終更新日：2017/06/22
Tweet