Manifesto - Conceptual Contexture

Introduction to Lattices and Orderを読みながらだんだんと考えがまとまってきたので書く。
・データフロー
・複数の種類の構造
・制約
上記の３つを自由に組み合わせることができるようにすれば、かなり便利なDBモデルができるのではないか、ということだ。あとは、これらの関係が変化するということもよくあるということ、わかりやすいGUIインターフェースを用意すること。こういう方向で開発を進めたい。
（以下、勉強中の概念・用語の入り乱れた説明なので、なにかおかしな言葉の使い方をしている可能性が高い。）

データフロー

ここでいうデータフローというのは、ソフトウェアアーキテクチャとしてのデータフローのことで、
データの変更が文字通り流れて伝播していく、という仕組みのこと。
wikipediaからの引用をのせておく。

ソフトウェアアーキテクチャとしてのデータフローは、ある変数の値が変更されたときに他の変数の値を自動的に再計算させるという考え方に基づいている。
データフロー言語はその原理を取り入れたもので、その意味では表計算ソフトが最も一般的な例であろう。例えば、表計算ソフトでは、あるセルに他のセルの値を使った計算式を対応付けることができる。そして、任意のセルの値を変更すると、自動的にその値に依存している他のセルの再計算が行われる。これは依存関係がある限りずっと続く。
http://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%AD%E3%83%BC

「表計算ソフトが最も一般的な例」とあるようにExcelでセルに"=A1+A2"と書いておいてA1のセルの値を変更すると、その変更が決定されたとたんに"=A1+A2"のセルの値も再計算されて変わるというあれだ。というか、Excelのあの仕組みをずっとイメージしていて、ちゃんと調べたら「データフロー」という名前が付けられていた、というだけの話だ、ほんとは。

複数の種類の構造

構造というのはデータ構造のことで、ツリーとか集合とか表とかtotal ordered setとかposetとかグラフとか、そいういうののこと。
XMLDBMSとかRDBMSだと、基本の構造がXMLなら要素のツリーとか、リレーショナルならタプルの集合、という具合に決まっている。もちろん基本構造が決まっているからこそ汎用的なインターフェースとしてSQLやxpathなんかが作りやすい、ということは当然ある。だが、基本構造が一つしかないと、その上に別の構造を保存しようとすると、なんらかのエンコーディングが必要になる。となると、アプリケーションプログラムがわで、Javaかなにかのプログラミングにより、エンコード、デコードとその際に制約を満たしているかのチェックなどをする必要がでてくる。DBMSとしては制約を満たしていて矛盾は無いデータだが、クライントとしてのアプリケーションソフト側から、もしくは末端のユーザからみれば矛盾したデータ、というのが存在してしまう確率も高まる。
ということで、はじめからツリーや集合や順序集合の「組合せ」としてデータベースのスキーマを定義できるようにすればいいのではないか、ということ。

制約

制約といっても、制約プログラミングのように制約充足問題をアルゴリズムで解く、というほどのものではなくて、単純なassertionとしての制約。契約プログラミングでいうところの契約。契約といってしまった方がいいのかも。
ここのデータには、１から１０までの整数しか入りません、とかそいうの。

この３つを組み合わせる

上記の３つを組み合わについて、以下述べる。

データフローと制約

たとえば、データフローとしてsum(入庫)-sum(出庫)=在庫と定義しておいて、在庫>0という制約をおけば、これの制約を破るような出庫のレコードの追加トランザクションはエラーとなる。

データフローと構造

「構造のデータフロー」というものを考える。
一番簡単なものはRDBでのカラムの追加。あるテーブルAのもとに、レコードa0,a1,a2...があるとする。
各レコードは、テーブルAがもつカラム定義に従うように、データを持つ、とここでは考える。するとかなりあいまいな表現になるが、
カラム定義of(A) = タプル構造of(a0) = タプル構造of(a1) = ...
となっていると考えられる。このときカラム定義of(A)が変更されれば、タプル構造of(a0)などが自動的に変更される。この構造変化の伝播をデータフローと同じものであると考える。
Ordered Setとして、X,Yがあったとき、もうひとつのOrdered Set ZをOrdered Setの積をつかってX × Y = Zと定義しておけば、Xに変化、たとえば要素の追加が行われたときは、それに伴ってZにも要素の追加が行われる。

構造と構造

RDBのJoin(結合)は、集合の積の部分集合として定義されている。CategoryのProductを使えば、ツリー同士のJoinなども容易に考えることができる。集合としてのデータの上に、Partial Ordered Setやツリーなどの構造が重なっている場合には、関手を定義しておけばいい。

構造と制約

たとえば、partial ordered setは、ツリーのような構造になっていることがある。たとえば「〜より偉い（もしくは本人）」という会社の中の社員同士の上下関係として２項関係≦を定義することを考える。
で、部長であればとにかく違う部署でも平社員より偉い、という関係ではなくて、命令系統的に真上にいるというか直属の上司をたどってたどり着けるような関係として定義する。すると、色々なことに使える。ワークフローや権限的な問題で、「より偉い」ならば閲覧や変更の権利があるとか、現実的にはなさそうだが「より偉い」なら「（給料も）より高い」というような制約もつけたりはずしたりできるように。あと、この「より偉い」という関係と「所属」という関係を分離できるようにすれば、変更や運用的な対応にも便利。