アドレス、この巨大な怪物

関係モデルを生むに至った研究の最大の動機は、データベース管理における論理的な側面と物理的な側面を明確に区別したいということであった。これをまず、データ独立の目標(data independence objective)と呼んでおこう。

E.F.コッド^[1]

関係型データベースにポインタはないというとき、物理レベルにおいてポインタが全くありえないということをいおうとしているのではない。逆に、そのようなレベルにおいてはポインタは確かに存在し得るし、実際にそうだろう。しかし、すでに説明したように、そのような物理レベルの記憶の詳細はすべて、関係型システムにおいてはユーザから隠蔽されている。

C.J.デイト^[2]

関係モデルはアドレスから自由になるために生まれた

　冒頭の引用においてコッドが「データ独立の目標」と呼んだ目標は、一言でいえばデータベースをアドレスから解放することでした。言い換えれば、関係モデル以前のデータベースのモデルである階層モデルや網モデルは、アドレスまみれだった、ということです(もっとも、私はこの両者に直に触れたことがありません。ただ、そうであったということを読んだだけです)。

　当然のことながら、私たちが欲しいのは「データ」であって、「データの在り処を示すアドレス」ではありません。そんなものは、もらったところで手間が増えるだけで嬉しくない。この点は、いくら強調してもしすぎることはありません。なぜなら、そうした希望に反して、計算機の中はアドレスで溢れているからです。のみならず、C言語やアセンブラを扱う場合には、プログラマがアドレスを意識して扱う必要まであります。

　しかし、データベースの世界においては、1969年、アドレスから自由になることに、ほぼ成功しました。プログラミングの世界で未だにポインタ操作が行われていることを考えれば、これは、非常に先駆的なことだったと言えるでしょう[3]。おかげで現在のDBエンジニアは、データの在り処を意識することなく、データの内容のみを気にすればよくなったのです。それでは、再び、コッド博士から。

計算機の番地ぎめでは、位置の概念がつねに重要な役割を果たしてきた。プラグ板の番地ぎめに始まって、絶対番地、相対番地、算術的な性質をもつ記号番地(アセンブリ言語における記号番地 A+3 や Fortran、Algol、PL/I の配列 X における要素の番地 X( I+1, J-1 ) など)は、いずれもそうである。関係モデルでは、位置による番地決めを一切排して、完全に内容による番地決めを採用した。関係データベースでは、関係の名前、主キーの値、属性の名前を使って、いかなるデータでも一意に呼び出すことができる。こうした内容呼び出しが可能になると、利用者は次のことをシステムまかせにできるのである。(1)データベースに新しい情報を置くにあたって、どこに置くのかの詳細。(2)データ検索にあたって、適当な呼出し経路を決めること。もちろんこの利点は、末端利用者だけではなくて、プログラマに対しても成立する! ^[4]

プログラミングに氾濫するアドレス

　関係モデルも、アドレスからデータベースを完全に解放したわけではありません。「 SELECT rowid FROM SomeTable; 」というクエリを実行すればすぐに分かるように、物理レベルで見ればデータは、相変わらず rowid というアドレスによって管理されています。しかし、このことをもってコッドの「データ独立の目標」は中途半端だったと結論づけるのは、少し酷です。私たちが使用可能な唯一の選択肢であるフォン・ノイマン型計算機が、データをアドレスで管理する以上、その上で動くプログラムもまた、同じ制限を受けなければならないからです。

　だから、むしろコッドは、自らに課せられた制限の中で何とか折り合いをつけるべく関係モデルを考案した、と考えるべきです。ですが、穏便なコッドと違って、そもそもフォン・ノイマン型計算機の仕様にけちをつける蛮勇の持ち主もいます。その一人がJ.バッカスです。 Fortran と BNF記法の発明者として知られ、1977年にその二つの功績によってチューリング賞を受けました（ちなみにコッドは81年の受賞者）。彼は、フォン・ノイマン型計算機のデータ管理方式の制限を受けることで、プログラミングの世界まで膨大なアドレスで氾濫したと指摘します。

このように、現在ではプログラミングとは基本的には、フォン・ノイマン型隘路を通る語の恐るべき交通量を計画し、細かく面倒を見ることである。そしてその交通量の多くは、意味のあるデータではなくて、それがどこにあるかを見つけるためのものなのである^[5]。

　プログラミング言語がアドレスに振り回された結果、「この20年間、プログラミング言語は現在の肥満した状態に向かって着実に進んできた」と^[6]、バッカスは嘆きます。彼の慨嘆からさらに20年以上が過ぎた現在でも、その状況は改善されていません。それどころか、はっきり、悪化の一途をたどっています。過去20年間、数多くの言語が誕生しましたが、そのどれもがアドレスという名の怪物から自由にはなれませんでした。

　Java は、アドレスを使用者からある程度隠蔽したという点で、C++ から進歩したと言えるかもしれません。しかし、内部を覗けばそこはやはりアドレスの洪水です。一般に、オブジェクト指向は、アドレスの氾濫に対する有効な対抗手段にはなりません。オブジェクトもまた、OID というアドレスによって管理されるからです。そして、プログラムが複雑になり、オブジェクトが次々と作成されれば、旧来の手続き型言語において変数が山のように宣言されていたときと状況は変わりません。実際は、変わらないどころかより深刻です。オブジェクトは変数や構造体に比べて非常に大きく複雑なデータであり、その分計算機への負担も大きいからです。

　変数 ―― これこそ、プログラム言語におけるアドレスの化身です。C言語において「int a;」と宣言し、「&a」の値を表示させてみてください。全ての変数はそれ自身が意味を持たないアドレスによって管理されています。そして、手続き型言語においてデータを扱うためには、変数に代入するしかありません。変数を使う限り、アドレスから逃れられないのです。裏を返せば、変数を使わないがゆえに、SQL はアドレスから自由な言語たりえたのです。

去り行かない老兵

　Lisp という言語があります。同じ関数型言語に分類されます。高級言語としては Fortran の次に古い歴史を持つ、既に老兵と呼んでよい世代の言語です。バッカスはかつて Lisp（に代表される関数型言語）に、ノイマン・スタイルからの解放の希望を託しました。確かにLispはその夢を託すだけに足る可能性を持った言語でした。私なら、その戦列にSQLも参加させたいところです。かつて関数型言語というのは、一部の物好きか計算機科学専攻の学生がはまる言語とみられていました。しかし今日、Hakell、Scalaなど洗練された新しい世代の言語が登場してきたことで、アドレスという怪物に対する戦いは、現在新たな局面を迎えているといってもよいでしょう。我々は、今度こそ勝つかもしれない。

注
[1] E.F.コッド「関係データベース：生産性向上のための実用的基礎」『ACMチューリング賞講演集』(共立出版、1989) p.458

[2] C.J.デイト『データベースシステム概論　第6版』(共立出版、1989) p.64

[3] この意見に対して、ポインタ操作の利点を挙げて反論することもできるでしょう。サイズの大きなデータ自体を直接扱うより、小さなアドレスを扱う方が効率がいいではないか、と。一理あります。ですが、私は速度よりはソースの可読性を重視します。速度の遅さは計算機の性能が良くなれば解決されますが、ソースの分かりにくさは何物も解決してくれないからです。だから、私は常々思うのですが、データベースにおけるパフォーマンス・チューニングの技術も本来は――常に全表走査のみによって十分速い応答速度が得られるなら――不要です。パフォーマンス・チューニングがデータベース技術の重要な一分野となっていることを考慮に入れても、なおそう思います。
　Keep it simple, stupid.

[4] コッド、p459

[5] ジョン・バッカス「プログラミングはフォン・ノイマン・スタイルから解放されうるか？関数型プログラミング・スタイルとそのプログラム代数」『ACMチューリング賞講演集』(共立出版　1989) p.90

[6] 同上、p.86