はじめに
この文章は、クリス・デイトの「The Birth of the Relational Model - Thirty Years of Relational (1)」の要約です。非常によくまとまっているので、本当は和訳を全文掲載したいぐらいですが、さすがに著作権の関係上それはできません。その代わりと言ってはなんですが、私なりに解説と注釈を入れて少しでも読みやすくしようと心がけています。
二つの論文
コッドが関係モデルの概念を提唱した最初の論文は、「Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks」、1969年のことです。しかし残念ながらこの論文は、掲載されたのが『IBM Research Report』という社内報であったため、一般の注目を集めませんでした。
しかし翌70年、今度は権威ある学術誌『Communications of ACM』に「A Relational Model of Data for Large Shared Data Banks」というタイトルで掲載されます。こうして関係モデルが世に出ることとなります。ただし、「理論的でアカデミックで数学的なトーンだったので、DBの専門家でも実際に読んだことのある人はごく少数に違いない」とデイトは言っています。自慢するわけではありませんが、私は読みました。しかし実務に直結する内容ではないので、特に興味がなければ現場のエンジニアが読む必要はないと思います。
コッドの功績
「コッドの最大の功績は、データベースを科学の領域へ導いたことにある」とデイトは言います。「それによって、多くの重要な問題に科学的手法を適用できるようになった」。コッドがもたらした関係モデルの基礎的方法として、デイトは以下の3つを挙げています。
- データベース操作の基礎に述語論理(predicate logic)を使用したこと
- 関係代数(relational algebra)を定義したこと
- 関係計算(relational calculas)を定義したこと
- 制限(restrict :混同しやすいが、SQLのSELECTとは機能的に全く別物[2])
- 射影(project)
- 積(product)
- 和(union)
- 交わり(intersect)
- 差(difference)
- 結合(join)
- 分割(divide)
1969年の論文
1969年の論文は以下の6章から成っています。
- データを関係として見ること(A Relational View of Data)
- いくつかの言語的側面(Some Linguistic Aspects)
- 関係に対する操作(Operations on Relations)
- 表現可能な関係、名前をもつ関係、記憶関係(Expressible, Named, and Stored Relations)
- 導出可能性、冗長性、一貫性(Derivability, Redundancy, and Consistency)
- データ・バンクの制御(Data Bank Control)
A Relational View of Data
この章では、関係モデルそのものと若干のキーの概念、すなわち後に関係モデルの「構造的側面」と呼ばれる側面が論じられます。関係の操作、後に「操作的側面」と呼ばれる側面は扱われません。
ここで、関係の概念が初めて数学的に定義されます。ただ、70年の論文における定義の方が簡潔で分かりやすいので、ここではそちらの定義を紹介します。関係は以下のたった一つの式によって与えられます。
R ⊆ (D1 × D2 × D3 ・・・ × Dn)
読み下しましょう。「関係Rは定義域D1,D2,・・・Dnの直積の部分集合である」。この定義の解説は、「なぜ関係モデルという名前なの？」を参照してください。大雑把に言えば、テーブルの「各列が取りうる値(定義域)」の「考えうる全ての組み合わせ(直積)」によって得られる行の集合から、任意の行を取り出して作ったテーブル、という感じです。本当は「テーブル」という実装レベルの概念を関係と同一視するのは不正確なのですが、イメージはそんなところです。
「数学的には非の打ち所がないが」と、デイトは続けます。「今から振り返ると、この定義には若干の欠点がある」。
第1の欠点：属性と定義域の区別
この論文には、確かに属性という用語が登場するのですが、正式な定義が与えらていないうえに、使用方法も一貫性を欠いていました。結果として、データベース業界には属性と定義域の違いに関する混乱が広がったと、デイトは言います。そしてその混乱は未だに続いていると。
第2の欠点：順序は関係ない
コッドは70年の論文で「ユーザは順序を持った関係を扱うべきではない。順序を持たない関係を扱うべきだ」と述べています。実際、関係はその定義上、属性も組も順序を持ちません。それは、数学の集合が順序の概念を持たないのと同様です。デイトが見るところ、この数学的な純粋性を保とうと設けられた制限は、DBの専門家から関係モデルに対する関心を削ぐことになってしまったようです。とりわけ、SQLが左から右という列の順序を持っていたため、SQL設計者の関心を関係モデルに惹きつけられなかったことを、デイトは惜しんでいます。
第3の欠点：関係値(relation value)と関係変数(relation variable)にまつわる混乱
これは本当に混乱しがちな点です。そして現実に、ずっとこの二つの概念についての混乱が存在しました。デイトもこの問題を短い連載の中で扱うことは無理だとして匙を投げています(「どうか私が匙を投げたことで混乱が更に酷くなりませんように！」)。私も、詳しくは別に一章を割くとして、ここは手短に済ませます。
何も修飾語なしに「関係」と言うとき、それは関係変数と同義です。関係変数とは、その名の通り、関係を値として格納する変数のことです。私たちがCREATE文でテーブルを作成するとき、実は「テーブル変数」を作成しているのです。そしてある特定の時刻においてそのテーブルが保持する行集合全体が「テーブル値」というわけです。関係値と関係変数の対比は、数学の値と変数の対比と類似しています。変数というのは、要するに値を入れるための容器なのです。
ところが、コッドの論文では、この点について紛らわしい記述が現れます。例えば「時間変化する(time-varying)」関係という言い回しが出てきますが、これは関係変数を意味しています。関係値は時間変化などしないからです。
さて、69年の論文の続きを追いましょう。次にコッドが紹介する概念は、DBエンジニアには馴染みの深い、重要なものです。そう、「キー」です。コッドがこの論文で単に「キー」と言う場合、それは今で言うスーパーキーを指します[3]。「冗長ではないキー」と言う場合は、候補キーのことです。
ちなみに、70年の論文になると、単に「キー」と言う代わりに「主キー」という言葉が導入されます。しかし注意が必要です。この「主キー」は現在私たちが呼ぶところの主キーのことではなく、スーパーキーのことです。理由は以下の二つです。
- 冗長性を許す
- 一つの関係に複数存在してよい
70年の論文では、外部キーも紹介されています(69年の論文にもそのアイデアは簡単に示されていましたが、外部キーという用語は登場しませんでした)。しかし、その定義は今から見ると不必要に制限の厳しいものです。コッド曰く「外部キーは主キーであってはならない」。――なぜこんな制限が課されていたのでしょうね？ もちろん、現在のRDBMSではこんな制限はありません。主キー兼外部キーという設計をすることは何の問題もなく可能です。
第1部はここまでです。第2部へ進みましょう。
注
[1] 関係代数の出力が再び関係であることを、閉包性(closure property)と呼びます。入力と出力が共に関係なので、ある演算の出力を別の演算の入力にすることが可能です。和の射影をとるとか、制限の結合をとる、といった具合です。これによって、入れ子構造の記述が可能になり、SQL においてサブクエリを実現できます。
関係の閉包性は、整数の閉包性と似ています。整数もまた、和、差、積の演算について閉じているがゆえに、入れ子の演算が可能になっています(整数は商については閉じていません。理由は、1÷2の結果を見れば明白でしょう)。
[2] 制限(restrict)は、現在では多くの場合、選択(select)と呼ばれます。しかしこれはSQLのSELECTとの混同をますます助長する紛らわしい呼び名です。実際は、SQLのSELECTは、8つの演算の全ての機能を合わせたよりもさらに強力な機能を持っています。参照：C.J.デイト『データベースシステム概論 第6版』(丸善 1997) p.157
[3] 念のためスーパーキーについて説明します。A1, A2, A3, A4 という4つの属性を持つ関係があったとします。このうち、{ A1, A2 } の組み合わせでタプルを一意に識別できたとします。この { A1 ,A2 } の組み合わせが今で言う主キーです。
ここで、{ A1, A2, A3 } という組み合わせをスーパーキーと呼びます。主キーに余計な（=冗長な）非キー属性 A3 がくっついてます。このスーパーキーでも、もちろんタプルを一意に識別可能です。同じように、{ A1, A2, A4 ] や {A1, A2, A3, A4 } もスーパーキーです。
作成者：ミック
作成日：2009/04/18
最終更新日：2017/06/22
Tweet