「キマイラ飼育記」は「関手的データモデル・ブログ」に変わりました -- みたいな状態。
どうして僕が関手的データモデルに興奮してイレ込んでいるのか？ まずは「面白いから」と答えるでしょうが、それだけではありません。長年に渡り、そして今でも僕を悩ませている問題に対して、関手的データモデルが解決、少なくとも解決のヒントを与えてくれるからです。
ソフトウェアシステムを変更すると、それまで使えていたデータが使えなくなる、あるいは、そのシステムに依存している他のプログラムが動かなくなることがあります。これは好ましくないので、ソフトウェアの世界では互換性が重視されます。
しかし、システムが発展していく途上では、互換性の維持が困難だったり、互換性を捨てる判断が妥当になることもあります。そんなときでも、「古いデータを守ってくれ」「今のプログラムをそのままで動くようにしてくれ」という圧力はかかります。設計者や実装者は難しい局面に立たされます。
ここで、理想的な状況を想定、あるいは妄想してみましょう。システムAがA'に変わるとき、次のようなことが出来るならどうでしょうか。
- AがA'に変わるとき、互換性が保てるかどうかを自動的に判断できる。
- 互換性が保てないときは、どうすれば今までのデータ／プログラムを移行（マイグレーション／ポーティング）できるかが分かる。
- 移行のためのマイグレーション／ポーティングの仕組みも自動的に作られる。
まるで夢のようです。現実的な目標とは、とうてい思えません。もちろん僕も、そんなバカげた目標に向かって走ろうなんて考えたことはありません。「夢が現実になる可能性」を感じさせてくれるナニカに出会った経験がなかったからです。可能性がない夢はたわ言です。
さて、スピヴァック理論＝関手的データモデルの現時点における最大のウリは、データマイグレーション関手が構成できることです。スキーマSとS'のあいだに関手 F:S→S' があれば、データマイグレーション関手を構成可能です。
SとS'がまったく無関係に設計されたスキーマのときは、SとS'のあいだの対応（関手）を作るのは難しいでしょう。しかし、Sをちょっと手直ししてS'にしたときなら、“差分”としての関手の定義は比較的容易でしょう。スキーマ発展（schema evolution）の関手 F:S→S' が定義できるなら、対応するデータマイグレーション・ツールは自動的に作れる可能性があります。
「データマイグレーションはできてもプログラムのポーティングは無理に決まってる」 -- いや、そうとも言えません。関手的データモデルのスキーマとは、単なる圏でした。関係モデルのデータベーススキーマに限定しているわけではありません。型と関数／メソッド（の宣言）を含む圏でもかまいません。
Sが、プログラム構成素を対象／射とする圏であるとき、関手 M:S→Set は集合圏におけるSのモデルです。このMは、少し抽象化された実装インスタンスとなります。この状況設定は、「スキーマ＝圏、データ＝関手」と考える関手的データモデルの枠組みから外れてません。関手Mは、「データベーススキーマSのデータベースインスタンス」と呼ぶよりは、「ソフトウェア指標Sの実装インスタンス」と呼ぶのがふさわしいですが。
ソフトウェア指標Sとは、外部に公開しているインターフェイスのことです。SをS'へと仕様を変更するソフトウェア発展関手 G:S→S' が定義できるなら、データマイグレーション関手の構成とまったく同様に、ソフトウェアポーティング関手が構成できるでしょう*1。
と、この話も「まるで夢のようです」。しかし、「夢が現実になる可能性」の根拠が存在しています。まるっきり“たわ言”じゃないと思っています。まー、風邪気味で若干熱があるので“うわ言”かもしんないけど。
