えーと、かなりマイナー目の人です。データベース研究者。
現在のすべてのデータベースソフトは彼の研究成果をどこかしら取り入れて作られている、といって過言ではありません。
でも、データベースソフトと言う存在自体が、プログラマでないと使わないかも。
コンピューター以前からデータベースは存在していました。
コンピューター以前のデータベースとは、たとえば「カード」です。
図書館などでは、カードに書籍の情報を書き、簡単にソート（並び替え）できるようにしてありました。
カードの上部に穴を開け、ここをさらに切り取ると「切り欠き」になります。
この「穴」か「切り欠き」かで情報を示すと、カードを簡単に並び替えたり、探し出したりできます。
ややこしい話なので、詳細は別の方が書いた説明に譲ります。
ただ、この方法では、１種類の方法でしかソートできません。
IBM がパンチカード分類機を作って以降、「複数の方法で」ソートすることが可能になりました。
パンチカードにいくつか穴を開け、残りの部分に情報を書いておけばよいのです。
必要な時に、必要な情報で分類したり、抽出したり、集計したりできます。
カードにあいた穴で分類する、と言う意味で、これは先に書いた「切り欠きのあるカード」と変わりません。
しかし、これはもう現代的な意味での「データベース」と言って良いものでした。
さて、コンピューターが登場しても、初期のころのデータベースは、パンチカードを模倣した「カード型」データベースでした。
一連のデータに、ソートや抽出などのための「キー」を設定しておきます。
住所録などを作るにはこれで十分なのですが、実は少し規模の大きいデータを扱い始めると、問題が生じます。
たとえば、蔵書目録を作っていたとしましょう。タイトルや著者名、出版社名などを記録していきます。
出版社名や著者名は、複数の書籍について、同じものが記録されます。
個々のデータとしては「文字として」記録するのが普通です。そうしなくては読めないためです。
しかし、同じ文字列をたくさん記録してあるのは、記憶容量の無駄となります。
記憶容量を無駄遣いする、と言うことは、扱わねばならないデータが増え、検索も遅くなります。
効率よくするには、出版社や著者ごとに「コード」となる数字を割り振り、数字で管理すればよいのです。
コンピューターは数字の扱いは得意ですから、もっとも効率が良い方法となるでしょう。
ただ、この場合人間にとってはわかりにくいことこの上ないです。
せっかくデータベースがあるのだから、「著者コードのデータベース」や「出版社コードのデータベース」を作って、「蔵書のデータベース」と組み合わせることで、内部的には数字として扱いながら、人間に対してはわかりやすい表示を行う…
これは誰でも考えるアイディアです。
しかし、このアイディアを実際に使える形にするには、大変な努力が必要でした。
カード型データベースは現実を模倣しているので、使い方もイメージしやすいです。
しかし、複数のデータベースを自動的に組み合わせて適切な処理をしてくれるデータベースって、どうやれば実現できるのでしょう？
このように、複数のデータが密接に連携したデータベースを、リレーショナルデータベースと呼びます。
リレーショナルは「連携する」と言う意味です。
IBM は System R と呼ばれるプロジェクトで、リレーショナルデータベースを実現する方法を研究しました。
（おそらく R は Relation や Research の意味だったのでしょう）
ややこしいものを表現するにはカードのような「図」のイメージでは無理があります。なんらかの方法を記述する…プログラム言語が必要でした。
結果は SEQUEL という新しいコンピューター言語として得られました。
SEQUEL は Structured English Query Language の略と言うことになっています。
でも、英単語の sequel …何かによって生じる「結果」を導き出す、ということでしょうね。
SEQUEL は別の会社が商標を持っていることがわかり、後に名前を SQL と改めています。
これが、現代までデータベース言語として使われている、SQL です。
さて、今日の話の主役、ストーンブレーカー教授の話をしましょう。
System R は開発中から論文などで学術的な成果の発表が行われていました。
ストーンブレーカー教授は、「データベースを操作する言語」というアイディアを見て、独自実装を作り上げます。
この過程で、現代的な「性能の良いデータベース」を作るうえでの設計技法である、リプリケーションやＢツリーなどのテクニックも開発します。
この成果が、Ingres と呼ばれるデータベースシステムでした。
System R が実際に完成し、提供が開始されたのは 1977 年ですが、Ingres は1974年にはプロトタイプが動き始めています。
独自に作ったため System R の SQL とは互換性がありませんでしたが、IBM の System R が大型コンピューターでしか使えなかったのに対し、Ingres はミニコンピューターでも使うことができました。
この後、ストーンブレーカーは Ingres の商用化を行いますが、商用化がひと段落したところで、ふたたびデータベースの研究に戻ります。
＃Ingres のソース自体は公表されていたため、数多くの派生商品が生み出されました。
データベース大手の Sybase はストーンブレーカーの教え子が興した会社で、Microsoft と提携して MS SQL Server を作っています。
さて、研究に戻ったストーンブレーカー教授、今度は Postgres を作ります。
「post」とは、後に来るものの意味。Ingres よりも優れ、後を継ぐものだという名前でした。
Postgres は、 Ingres の文法を拡張し、非常に多彩な機能をもったデータベースでした。
目標の一つに「SQL では表現できないデータベースの実現」があり、完成したものは優れた性能を示したようです。
…が、Postgres が完成するころには、SQL はデータベース問い合わせ言語の標準となっていました。
どんなに優れたものでも、SQL ではないデータベースでは使われにくい状況になっていたのです。
Postgres も Ingres と同じようにオープンソース化され、各種派生ソフトを生み出します。
そのうちの一つが、フリーソフトで配布され、Postgres の言語部分を SQL に置き変えた「Postgres95」でした。
Postgres95 は、さらに名前を変えて PostgreSQL となります。
ストーンブレーカー教授はこの後もデータベースの研究を続けています…が、実際僕は詳しくないです (^^;;
なので、最後は僕の思い出話。
大学時代の恩師が、その昔データベース研究をしていたことがあり、Ｂツリー分割アルゴリズムの最適解を数学的に求めた、という話（自慢話？）を聞いたことがあります。
…えーと、いきなり専門的な話で申し訳ない。
データベースとは、「データの塊」を相手に、いかに上手に処理を行うか、というプログラムです。
Ｂツリーと言うのは、処理をしやすくしたデータの塊で、ここにデータを追加していきます。
データの塊の中にはわざとたくさん隙間が設けてあり、データを追加する際にはこの隙間をうまく使います。
データは塊の中で「綺麗に並んでいなくてはならない」決まりがあり、入れるべき場所を見つけたら、近くのデータを「スキマに寄せて」目的のデータを追加します。
こうすることで、データ追加のたびに他のメモリを操作しなくてはならない量を最低限に抑えます。
しかし、スキマはだんだん減っていきます。
どこかでデータの塊を「分割」して空き容量を増やす必要があるのですが、分割が遅すぎると処理速度が低下し、分割が速すぎるとメモリを無駄遣いします。
経験則では、大体データが７割を超えたら半分づつに分割するのが良いとされていました。
大学時代の恩師は、さまざまな計算の結果、これが数学的には 1/√2 で表現される、と解き明かしました。
…およそ 0.707ですけどね。経験則の７割と言うのは当たっていたわけですが、その数学的裏付けにはちゃんと意味があり、データベースの教科書などには大抵、教授の名前と共に簡単な証明が載っているそうです。
（もう20年も前に聞いた話で、その後技術はどんどん増えているので、今でも載っているのかは知りません）
Postgres95 は会社員時代に使ったことがあり、PostgreSQL も独立後に使おうと勉強しました。
当時はフリーのSQLデータベースは他になく、PostgreSQL はちょっとしたブームになっていました。
しかし、当時の PostgreSQL は「データを削除しても、実際にはメモリを使ったまま」という仕様があり、時々実際の削除を行う「VACUUM」が必要でした。
これにかかる時間が見積れないのが問題で…会社員時代は、会社の備品記録に使っただけなので問題ありませんでしたが、独立後は WEB プログラマをやっていたので「24時間無停止」が求められていました。
で、代わりに見つけたのが、当時はまだそれほど有名ではなかった MySQL。
PostgreSQL は、多少の問題はありましたが「完全な SQLデータベース」でした。
ところが、MySQL は SQLデータベースの「一部機能だけを」搭載したものでした。
しかし、そのかわりに MySQL は非常に高速に動作しましたし、無停止運用も可能でした。
今でも使っています。今ではずいぶん高機能になりましたね。
MySQL 自体はストーンブレーカー教授の作品ではありませんが、Ingres で実験した「性能の高いデータベース」を作るための成果は、ちゃんと盛り込まれています。
同じテーマの日記(最近の一覧)
関連ページ
エドガー・コッド 命日（2003）【日記 15/04/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 指摘ありがとうございました。Ingress だとゲームになっちゃうのか…。修正しました。 (2015-04-20 19:08:53)【azip77】 文中の Ingress Postgress の表記は、 Ingres Postgres に改めたほうがよいかと思います http://ja.wikipedia.org/wiki/Ingres (2015-04-20 16:00:05) |