なぜRDBで木と階層構造を扱う手法が1冊の書籍に？
――『プログラマのためのSQLグラフ原論 リレーショナルデータベースで木と階層構造を扱うために』についてミックさんにうかがいます。最初に、本書がどういう本なのか教えていただけますか？
ミック：内容としては、リレーショナルデータベース（RDB）でグラフ構造の一つである木と階層構造を扱うための方法論「入れ子集合モデル」をメインに解説しています。RDBには大きな問題があり、入れ子集合モデルがそれを解決しうる手法だと見込まれています。その問題とは、そもそもRDBが持つ二次元の表形式では階層を持ったデータをきれいに扱うことができないというものです。これは何十年も前から知られていました。
RDBで木や階層構造を扱う手段としては、データをポインタ・チェーンで繋いだ配列として表す「隣接リストモデル」が唯一のものでしたが、これを実装するのはかなりたいへんで、使いにくいのです。この問題に対するいい解決策がなく諦めムードになっていたところに、ブレイクスルーになりうる手法として入れ子集合モデルが約10年前に登場したわけです。
これを初めて本格的に論じたのがジョー・セルコの『プログラマのためのSQL』で、そこでは一つの章を設けて紹介されています。本書も同じ著者によるもので、新しい手法の知見も溜まってきたことから『プログラマのためのSQL』のスピンオフに相当する形で『Joe Celko's Trees and Hierarchies in SQL for Smarties』としてまとめられました。本書はその第2版の翻訳です。
『SQL 第2版』でもお馴染みのミックさん
――なぜこのタイミングでの翻訳、出版となったのでしょうか？
ミック：階層構造に代表されるグラフデータは2000年代から急激に増加し、これを扱う必要性が高まってきました。SNSの人間関係はグラフで表しますし、XMLがウェブのデータ形式として一般的になってきたこともあります。いままでRDBであまり扱う必要のなかったこれらの階層構造データが存在感を増してきたため、日本でもその扱いに困っているエンジニアが増えてきていると思います。
ですので、本書で紹介されている手法にはかなり需要があるのではと思います。数学の知識は、あったほうが面白く読めますが、なくても読めますし実践できるでしょう。
入れ子集合モデルはまだまだ実験段階
――具体的にはどういったところに階層構造データが使われているのでしょうか。
ミック：最近は本当にいろいろなところで使われるようになりました。実例は本書の中でも私が付録として紹介していますが、例えばRedmineというオープンソースのプロジェクト管理ソフトウェアがあり、チケットの親子関係が階層構造を持っています。そしてこれを表現するために入れ子集合モデルが使われています。また、CakePHPというオープンソースのWebアプリケーションのフレームワークでは、ユーザーのアクセス権限を管理するテーブルでも階層関係の表現に入れ子集合モデルが利用されています。
あるいは、製造業で使用する部品表も階層構造データです。1台の自動車にどんな部品が使われているかを表現したデータはその古典的なものですね。ほかに、ECサイトでは商品のカテゴリを階層で表現しますから、そこでも利用されています。
ほかにも階層構造データを扱うサービスや業種は多々ありますから、これを扱おうとして苦労している方は本書を参考に、入れ子集合モデルなど紹介されている方法論を試してみると、解決の糸口が見つかるかもしれません。ただ、入れ子集合モデルはまだ実験的なものなので、すぐにフィットするかどうかは定かではありません。いくつかの欠点も指摘されています。
例えば、階層が深すぎるツリー、大規模なデータを扱おうとすると更新時にパフォーマンスが著しく低下してしまいます。ですので、読者の方の現場でどれくらい機能するかについては、やってみないと分からない状況ではあります。本書に興味を持って実践してみようという方も、基本的には小さめのデータでまずやってみるのがおすすめです。
巨大なツリーや頻繁に更新されるようなデータでは、私が知る限りまだ使われていません。本書ではそれに対する改良版も考えられていますが、完全解決というわけではないので、どうやってパフォーマンスを出していくかについては、少しずつ改良を重ねていく必要があるでしょう。アメリカでは入れ子集合モデルが採用されるプログラムが増えてきています。
RDBであらゆるデータを扱えるようになれば……
――現状では欠点があるにもかかわらずRDBで階層構造データを扱うのは、きちんと実現できたら楽だからですか？
ミック：そうです。というのは、従来の手法として使われている隣接リストでは、グラフのノードをすべてリストで表現しています。木の構造を一つ一つポインタで繋いでいく方法なんですが、これが非常に使いにくい。これしかなかった時代は仕方ないから使っていたというレベルで、かといって代替手段もない……と、かなり行き詰まっていました。
それを背景に、いまでは階層構造データを扱う手法について大きな流れが二つできました。一つはRDBで木や階層構造を扱うのはやめて、別のモデルに基づくデータベースで扱おうという流れです。XMLデータベースやグラフデータベースがそれです。こちらはグラフを簡単に扱えるデータベースを作ってしまったほうが楽だと考えたわけです。もう一つは、RDBの中でなんとかやりくりできないかというものです。本書で解説している手法ですね。
もちろん、一般のグラフを扱うならネイティブのグラフデータベースを使ったほうが素直ですね。本書で紹介している手法も、すべてのグラフを扱えるわけではないんです。人間関係のような循環してしまうグラフはそもそも扱えないので、限界もあるんですよ。
ただ、扱うデータをRDBだけで完結できるようになることは開発者にとっては魅力的です。RDBは基幹データを扱うために不可欠として、そのほかにデータベースを追加で構築することは、システムが複雑になりますから。データの移行や連携も考えなくていいので、RDBだけで済むならそれが一番楽だと考えるエンジニアは多いでしょう。
――いま階層構造データを従来の方法で扱っている方も、極力本書の手法で扱えるようになっておいたほうがいいのでしょうか。
ミック：無理には取り組まなくていいと思います。全員が右向け右で使えるほどの決定版ではありませんので、従来の方法――隣接リストなどでうまくいかなかった方が代替手段として検討する対象という位置づけです。
ベンダー依存的ではない手法としての入れ子集合モデル
――ミックさんご自身は、本書を読んでどんな感想を持たれましたか？
ミック：階層構造データの扱いは隣接モデルがメジャーな方法だったので、RDBでこれほどきれいに扱えるのか、こんな考え方があるんだ、と何度も気づかされました。実際に役に立つかどうかは横において、技術的・数学的に面白かったですね。発想の転換にもなりました。ですが、その反面、このやり方で大規模データを扱うとパフォーマンスが出ないこともすぐに分かりました。このまま大規模データが扱えないとしたら、メジャーになるかは微妙なところかもしれません。
ただ、特にベンダー独自拡張の機能に依存したくないエンジニアには読んでいただきたいですね。ベンダーも階層構造データを扱うために独自拡張を行なってきました。いまではかなり便利に楽に扱えるようになっています。しかしながら、それゆえにエンジニア側が独自拡張に頼りきると、データベース管理システムが変わった途端に何もできなくなってしまいます。
だからこそ、多くのエンジニアに標準的な方法論として入れ子集合モデルを知ってもらいたいんです。「RDBだけでやれるのでは」という可能性が生まれたわけですから、ぜひ目を向けてみてください。
――現状、国内では入れ子集合モデルはどれくらい認知されているのでしょうか。
ミック：メジャーではないと思います。私も記事や本で書いていますが、まだ知る人ぞ知る手法です。扱えるデータ量に限りがあるとはいえ、いまのうちに知っておいていただきたいですね。
――今後、よりパフォーマンスが出るように発展する流れはありますか？
ミック：あります。本書でも紹介されていますが、入れ子集合モデルの改良版として考えられている入れ子区間モデルがそうです。通常は座標に整数を使用しますが、整数である必要性はなく、小数を使えば更新時のパフォーマンス低下を抑えられます。しかし、小数はどうしてもコンピュータの性能によって扱える有効精度が制限されてしまいます。
もっと小数の精度が上がったハードウェアが登場すれば、入れ子区間モデルが一気に広まる可能性がありますね。私も10年後には、ハードの進化によってブレイクスルーが起きてもおかしくないと考えています。
RDBで階層構造データをうまく扱えなくて悩んでいる方へ
――ミックさんとしては、本書を通してどんなことを学んでもらいたいですか？
ミック：本書はRDBを扱うときに重要になる考え方である「物事を集合で見る」ことをストレートに学べる内容になっています。この考え方、そして入れ子集合モデルを使うときのSQLの書き方は、階層構造データ以外を扱う場合でも使えますから、ぜひ身につけていただきたいですね。
また、いま現場で木や階層構造を扱わないといけない立場で、しかしRDBでうまくできないと悩んでいる方は本書を読んでみる価値があると思います。特にRDBを諦め、XMLやJASONでアプリケーション側で実装して頑張ろうとしている方などは、検討の価値があると思います。
入れ子集合モデルに興味のある方はそれなりにいると思います。そのわりには日本では体系的に紹介されたことがほとんどありませんから、本書が一石を投じられることを願っています。
