ここ何年か、Webアプリケーション開発や、ある企業へのERP(NetSuite)とEDI(企業間電子取引)導入・運用に関わる中で、「リレーショナル・データベースよりも、XMLとか階層型のようなものが良いのではないか」と漠然と考えていました。
Webアプリケーションの開発では、機能の追加で頻繁にスキーマの変更が起こります。たとえばブログのコメント機能に、コメントへの返信機能を追加する際には、少なくともコメント間に関連を張る必要がありますし、仮に「○階層まで表示」という機能が必要なら、レベルのような項目も必要になります。そうすると、コメントの削除機能も、コメント間の関連を考慮した形に変更する必要が出てきます。
企業のシステムだと、「注文」と「注文明細」のような1:nの関係が色々出てきますが、一般的なリレーショナル・モデルだと2つのテーブルに分かれてしまいます。これだと、「Excelは結構使いこなしているが、SQLを書けるわけではない」程度の社内ユーザーには、扱いにくいデータになってしまいます。また、システム間で注文を送信しようとした場合に(たとえば倉庫システムに出荷指示を出す場合に)、複数のファイルを送信するのかという問題が出てきます。
折に触れて調べているうちに、データベース研究の歴史をまとめた"What goes around, comes around"(Joseph M. Hellerstein, Michael Stonebraker)という論文を知りました。タイトルを直訳すると、「去り行くものは、再び巡り来る」ですが、ここでは「データモデルの歴史: 輪廻は巡る」とします。長年、データベースの研究をしてきた著者が、1960年代から2000年頃までの同分野の歴史と議論をまとめたもので、私の上記の悩みにとても参考になったので、簡単に紹介します。
なお、原文は"Readings in Database Systems, 4th. ed."という書籍(通称Red Book)の第1章として出版されています。
Readings in Database Systems (The MIT Press)
- 作者: Joseph M. Hellerstein,Michael Stonebraker
- 出版社/メーカー: The MIT Press
- 発売日: 2005/01/07
- メディア: ペーパーバック
- クリック: 1回
- この商品を含むブログを見る
論文の概要
この論文では、下記の9つのデータモデルについて、概要と特長、廃れた理由・流行した理由などがまとめられています。
モデル | 時期 |
---|---|
階層型 (IMS) | 60年代後半〜70年代 |
ネットワーク型(CODASYL) | 70年代 |
リレーショナル | 70年代と80年代初期 |
ERモデル | 70年代 |
拡張リレーショナル(R++) | 80年代 |
セマンティック | 70年代後半と80年代 |
オブジェクト指向(OODB) | 80年代後半と90年代初期 |
オブジェクト・リレーショナル(OR) | 80年代と90年代初期 |
半構造化(XML) | 90年代後半と現在 |
自分がポイントだと思った点
だいたい書かれている順に挙げます。
- 階層型やネットワーク型のデータベースは、リレーショナルデータベースより古い。
- データベースの要件は後から変わるものなので、物理構造や論理スキーマが変更されても既存のコードがそのまま動く、「データ独立性」(data independence)が重要である。
- リレーショナルデータベースは、階層型とネットワーク型に比べて、データ独立性の問題を大きく改善した。
- ERモデルは、リレーショナルモデルとは別に発明されたものである。人類には理解困難な(と原文に書いてある)「関数従属性」の概念を使わないため分かりやすく、スキーマ設計の分野で成功した。
- 新しいアイデアの商品が成功するには、性能面・機能面の大幅な改善が必要であること、大手のコミットが得られること、顧客の"major pain"を解決するものであること、などが必要。
- Postgresはオブジェクト・リレーショナルDBの代表格であり、ユーザー定義の型・関数・アクセスメソッド(インデックス)を、エンジンに直接追加できることがポイント。
- XMLの"schema last"アプローチは、実際のデータの大半は構造化データに多少のフリーテキスト項目を加える程度で済むので、結局のところ、限定的な用途しかない。
- XMLSchemaは複雑すぎて普及しない。サブセットが開発されるであろう。
- semantic heterogeneity(たとえば同じ"給与"というフィールド名であっても、通貨が違ったり、税込かどうかが違ったりして、比較できるとは限らない)の問題は、単にXMLを導入したからといって解決するわけではない。
- XMLは、単にファイアウォールを越えられるプロトコルであるという理由で、ネットワーク越しのデータ交換には普及するだろう。SOAPも同様。
XMLについて考察
2017年になって見てみると、XML SchemaとSOAPは、システム間のデータ交換目的でも、あまり普及していないという印象です。欧州では、ビジネスデータ交換用のebXMLとかあるんですけどね…。
また昨今の、RESTでJSONを返すAPIの普及と、さらにJSON SchemaというJSONデータの仕様記述言語が提案されている状況を、「XML SchemaとSOAPの再発明でもったいない」と思っていましたが、以下のように捉えると、良い取り組みかもしれないと考え直しています。
- REST(というかHTTP(S))もファイアウォールを越えられるプロトコルである。
- JSON SchemaとRESTは、複雑すぎるXML SchemaとSOAPの現実的な単純化である(SOAPでも、リモートプロシージャ呼出し指向でなく、メッセージ指向で設計すればRESTと似たようなものが作れる)
この記事を書き終えてから調べたら、Red Bookの第5版が2015年にオンラインで公開されていました。既存の論文は参照の形で含まれるという、C++の仕様書のような構成になっています。オンライン版のChapter 1にXMLと、その後に出現したJSONについてのStonebraker氏の考察が出ていて、興味深いです。http://www.redbook.io/
残念ながら、システム間の情報交換フォーマットとしての側面には触れられていないのですが…。
終わりに: メタな教訓
最後に、この論文を読んで私が得た、メタな教訓を挙げておきます。
- 教訓a: アカデミアの知識の蓄積は、やはり大きい。優秀な集団が、特定分野の研究を専門的にしているのだから当たり前だが、もっと実業にも活用したい。
- 教訓b: 自分のように、すでに答えの出ている問題に悩み、車輪の再発明をしそうになることはある。30年もすると、技術の発展のコンテクストは忘れられがちなので、定年退職する頃に、自分がかかわって来た分野の歴史を書き残すのは有意義かもしれない。
教訓aについてすぐできることとして、情報処理学会誌の購読を始めました。今は、入会にあたって推薦者も不要で、会費も、技術的にしっかりした月刊誌の購読料とだけ考えても非常にリーズナブルな上に、過去記事もWebでPDFが読めて便利なので、おススメです。まったくの個人的な感想ですが、情報処理学会誌を読んでいると、昔のbitという雑誌の雰囲気を思い出します。
教訓bは、自分にとってはまだ先の話ですが、頭の片隅に置いておきたいと思います。