どうもこんにちは、開発のKomaDです。
桜前線も本州をおおむね通過し、残すところは北海道くらい。こんな暖かい季節はなんだか初心に帰って勉強したいという思いが強くなりますよね。
Webアプリケーションの業界でも、長年変わらない「基本」というとどんなものがあるだろうかと考えてみたところ、とにかく昔から使われて続けているデータベースの基本など良いのではと思いました。
そこで今日は「基本」をとにかく突き詰めていくために、そもそものリレーショナルデータベース（RDB)の考案者であるE.F.Coddの論文を読んで勉強してみようと思います。
この論文はCoddがRDBの構想を一般に発表した論文で、公開されているものを読むことができます。
公開されている原文 https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
（こちらで和訳されている方がいらっしゃいます。 http://blog.benkyoenkai.org/2011/12/2011-12-1613it.html）
基本を学ぶという意味では、もちろんこちらの論文を読んでいただいたほうが良いですが、重要な内容を、３ポイントほどにわけて書いてみました。下の記事も読んでいただければ、論文の内容がわかりやすくなるかもしれません。
1. 論文の書かれた背景
まずは、論文の内容に入っていくまえに、論文が書かれた背景を理解しなくてはいけませんね。
１つ目のポイントは論文の書かれた時代背景です。
この論文はタイトルにあるように、大規模な共用のデータ保存システムの構想をテーマとしています。
当時存在していたデータベースは、階層型あるいはネットワーク型と呼ばれるようなものでしたが、Coddが提案するRDBはこれら既存のデータベースの短所を克服する特長を持っていました。
論文中では、1.2 DATA DEPENDENCIES IN PRESENT SYSTEMS でその当時の現行システムの実装についてふれられていますので、この辺りを中心に見ていきましょう。
その当時のデータベースは、ディレクトリのように配置されたファイルにデータを保存したり、あるいはそれらをネットワークのようにポインタで接続してデータを表現するような構造を持っていました。(例としてあげられている階層型データベースのIMSなどは現在でも利用されています。)
こうしたデータモデルでつくられた当時のデータベースの短所を、Coddは以下のようにまとめています。
- Ordering Dependence (レコードの保存順への依存)
- Indexing Dependence (インデックスの参照方法への依存)
- Access Path Dependence (データへのアクセス経路への依存)
ここで依存といわれているのは、アプリケーションがDBに問い合わせするときに、上記の３つのようなDBの内部構造に依存して問い合わせをしてしまうということです。
つまり、当時のDBでは、データのレコードの保存順やインデックス、アクセス経路などを、アプリケーションが明示的に考慮して処理する必要があり、それに合わせた作りこみをする必要があったわけです。
現在のRDBであれば、レコードの保存順やデータへのアクセス経路、インデックスなどは、RDBMSが管理してくれるものであって、その変更がアプリケーションの作りに影響することはありません。今では当然に思えるような機能も、当時のデータベースの短所が、リレーショナルモデルという新しいデータモデルによって克服され、可能になったものだったのです。
2. データをリレーションとして保管するとは
ではリレーショナルモデル以降から実現された特長がどのようなものか読んだ上で、肝心のリレーショナルモデルがどのようにデータを保管するのか見てみましょう。
リレーションと呼ばれているものが何であるかは、論文では、1.3 A RELATIONAL VIEW OF DATA に説明があります。そこでは「リレーション」とは数学用語でいうところのそれと定義を同じくするものだと書かれています。
「リレーション」としてデータを保管するとはどのようなことなのでしょうか。
まず、リレーションの定義は、「Rは、デカルト積 S1×S2×...×Snの部分集合である」というものです。
（Rというのはリレーションのこと、Sというのはそのリレーションがもつ個々の要素の集合です。）
例えば、果物に関する属性が３つあり、それぞれ「名前」「味」「色」だとします。
--------------------------------
S1 = { リンゴ, ミカン, メロン }
S2 = { あまい, すっぱい }
S3 = { 赤, 黄, 緑 }
--------------------------------
※果物の名前や色が３つしかない、味の種類が２つしかないというのはおかしいかもしれませんが、単純化するためにこう考えてみましょう。
それではこの３つの集合（S1, S2, S3）を使ってデカルト積をとります。デカルト積というのは、複数の集合からそれぞれ任意の要素を取ったときの、すべての組の集合のことになります。
ですから、３つの集合からは、
----------------------------------------
リンゴ あまい 赤
リンゴ あまい 黄
リンゴ あまい 緑
リンゴ すっぱい 赤
リンゴ すっぱい 黄
リンゴ すっぱい 緑
ミカン あまい 赤
ミカン あまい 黄
ミカン あまい 緑
ミカン すっぱい 赤
・・・・・
----------------------------------------
というようにつづいていく、計18個の組み合わせ要素からなる集合ができます。これがデカルト積です。
さらに、リレーションの定義はこのデカルト積の”部分集合"というものでした。
先ほど計18個組み合わせを作ったところからもわかるように属性のデカルト積の組すべてが存在する（真である）わけでないことがあります。(データベースについて言えば、存在しないデータとは記録されないデータのことですから、例えば「ミカン あまい 緑」というデータが保管されないならばそれは真でないということになります。)
このようにして、集合（属性）を組み合わせた結果から真であるところのものを残した結果がリレーションと呼ばれるものになります。
ここで重要なのは、「果物の名前」「味」といった属性も集合であり、その組み合わせでできるリレーションも集合である、というようにデータが集合から成るようにできていることです。
結果、出来上がった「リレーション」は普通の表のような見た目になっています。
しかし、リレーションとしてデータを持つことで、それまではありえなかったデータに対する操作が実現されるようになります。リレーションが集合であるという特徴から、それに対して集合演算を行うことができるようになるのです。集合演算の内容は論文中では、2.1 OPERATIONS ON RELATIONS の内容にあたります。
これは、データベースの勉強をし始めるときにでてきた「射影」だとか「制限」、「結合」のような操作のことです。
SQLだと、SELECT文のなかで、SELECT句に対象の列を指定するのは「射影」、INNER JOIN句の指定は「結合」、WHERE句で条件を設定するのは「制限」にあたります。
こうした記述は普段SQLを書くときに当たり前のように使うものですが、これが可能になるのも、リレーショナルモデルがデータを集合として取り扱うモデルだからです。保管されたデータを、その保管形式によらず、クエリ言語によって自由に成形して出力できるのはCoddが提案した新しいデータモデルがなくてはありえないことだったのです。
Coddはこの論文で、リレーションとしてデータを保管することを提案したわけですが、それは逆に言えば人間が記録したいと考えるデータはすべていくつかの属性の要素を組み合わせたものだという気づきに基づくものです。
データベースの設計において新しいデータモデルを構想するというのは、いわば人間が記録するという一般的な営為全体を要件としてとらえてそれを実現する設計を行うということです。Coddはこの大きな問いに対して一つ回答することができたのです。
3. リレーションへの問い合わせ言語
ここまで、リレーションの考え方をDBに適用するアイデアの部分を見てきましたが、リレーションから自由に集合を取り出せるとしても、その問い合わせ方法を形式化できるのかという課題がまだあります。そこで、Coddはもう少しリレーションに対する問い合わせの方法についても、アイデアを持っていました。
３つ目のポイントとして、リレーションに対するクエリの方式について書かれた部分、論文中では、1.5 SOME LINGUISTIC ASPECTS の内容を見ていきます。
ここでは、複数個のリレーションに対して問い合わせを行い、操作者が望むデータの集合を返す言語が構想されています。
データがリレーションとして保管されていれば、「述語論理」にもとづいた方式で問い合わせをできるだろう、とCoddは構想していました。
ここで述語論理という言葉が出てきましたが、言い換えれば、何らかの論理式により問い合わせができるということを意味しています。
述語論理に基づいた論理式では、「すべての…について…である」というような記述をすることができます。（例えば「すべての色について黄色である果物」というように。）そして、述語論理を解釈することによって得られる結果は何らかの集合です。（例えば上の式からは「黄色い果物」の集合が得られます。）
ですから、データがリレーションとして保管されていることは、集合演算を行えるというだけではなく、そのクエリを述語論理に基づいた式として記述できるという特長ももたらすことになります。リレーションとしてデータを保管しておけば、自由に表を作り出せるだけでなく、論理式で表現できるような望むデータを自由に取り出せるようになるのです。
ただ、述語論理に基づいて問い合わせを行うためには、条件があります。それはリレーションに含まれる要素の組（テーブル上の１行）が命題として成立するものであって、リレーションが命題の集合であることです。
例えば、先ほどの例にあった果物のテーブルは、それぞれの行を「名前がりんごの赤色であまい果物が存在する」という様な命題だとしてとらえることができます。その結果「すべての色が赤である果物」というような式を解釈して、その結果の要素として合致する命題を含めることができます。
論文では1.4 NORMAL FORM に正規形についての言及がありますが、このような操作を可能にするためにはリレーションは正規形(第一正規形)である必要があります。第一正規形すら満たしていないテーブルだと、リレーションを命題の集合としてとらえることができません。
まとめると、RDBにおいて、テーブルの行と呼ばれているものは、ある命題であり、くだけた言い方をすれば、RDBにおいては保存されるデータの最小単位は、何らかの記述というか「文」のようなものであるといえます。
一つ一つのデータが文のような表現であることが可能なために、RDBは非常に柔軟な表現力をもってデータを保存することができます。しかし、同時にその一つのデータ（行）はある集合の一要素であることが明確に定義されているために、集合演算や述語論理による問いあわせの対象とすることができます。
このように、表現力を持ちつつ定式化も行われるという優れたデータモデルをCoddは提案していたのです。
これらのアイデアは当時の既存のDBの問題点を一気に解消するものであったという実務的な側面もありますが、これだけ深い問題の解決ができる構想をCoddが提示できたのは、人間が何かを記録し、参照する営為それ自体を一般化して設計に反映したからではないでしょうか。
Coddが定義した人間の営為においては、データとは人間にとって何らか有意味な命題であり、参照はその命題の集合に対しておこなわれます。こうしたものの見方はもちろん数学や論理学を出発点としたものだといえばそのとおりですが、「人間」が何かの記録を保管するときその記録の最小単位は何なのかという問いがなくては得ることのできない視点であったように思えます。
この論文の発表当時はまだRDBの実装も業務への利用も始まっていませんでしたが、それでもこれだけ完成された構想をすることができたのは、理論的な面での基礎が固められていたことと同時に、そのような人間の営為に対する洞察があったからではないだろうかと思えてきます。
この論文をよむことでデータベースについての基礎を学べるのはもちろんですが、こうした普遍的な人間の行為に対してもシステムを設計できるのだということに、IT技術が持つ深みのようなものを感じられる気がしています。
ぜひ、論文のほうも実際に読んでいただき、このあたりの深みも味わっていただければと思います。
シャノンでは、技術的深みを味わうのが大好きなメンバーを募集中です。
