ContextureDB（下書き）

はじめに

ContextureDB（略してCtDB）は、
関数型データモデルをベースにReactive ProgrammingやHaskellのArrowを参考に拡張を行ったDBモデルを持ち、
アプリケーションロジックの宣言的な記述やツリー状データによる入出力を特長とするDBMSです。
目的は、Webアプリケーション開発の省力化の実現です。
（パフォーマンスやスケーラビリティの向上は、現段階では目指していません。
計算量が時間的、空間的に、RDBMSを使用して開発された典型的なアプリケーションと同じオーダーであることを目標としています。）

関数型データベースについて

関数型データベースでは、値の集合と関数でデータを表現します。
例えば、社員IDと社員名、社員の年齢に関するデータを表現する場合、
RDBでは次のようになるでしょう。
社員ID, 名前, 年齢
1, 中野, 30
2, 藤原, 40
...

関数型データモデルでは、
次のようなルールにもとづき
社員IDをとり、社員名を返す関数と、
社員名 :: 社員ID -> 名前
1=>中野
2=>藤原

次のようなルールにもとづき
社員IDをとり、社員名を返す関数と、

社員年齢 :: 社員ID -> 年齢
1=>30
2=>40

で表されます。
このような関数は内部的にハッシュやbtreeのようなデータ構造をもっており、
当然変更することができます。
利点は、データとロジックを関数として統一的に扱う事ができるという点です。

関数型データモデルの歴史

関数型データモデルは、非常に古くからあり、最初のfunctional datamodel であるDAPLEXは
70年代につくられたようです。
The first functional data model DAPLEX was developed at MIT in the 70s

Reactive Programming

データフローや更新を伝播する仕組みに関するプログラミングパラダイムです。

a = 10
b = a * 2
a = 15
print b

このように、bがb = a * 2として定義されているとき、
aが変化したときに自動的にbの値を自動的に再計算して更新する仕組みをReactiveと呼びます。
Excelのような表計算ソフトが、一般的な例としてよく揚げられます。

http://d.hatena.ne.jp/maoe/20100109/1263059731
http://en.wikipedia.org/wiki/Dataflow

CtDBについて

CtDBは、値の集合であるObjectと、集合と集合を結ぶ関数であるArrowによってデータを表現します。
(用語は圏論とは直接関係ありません。)

Object

Objectには型があります。Integer型のObjectはInteger値の集合であり、String型のObjectは、
String値の集合です。
Identiry型のObjectというものもあり、これは正の整数で表されるIDの集合になります。

Arrow

Arrowは入力元のObjectと出力先のObjectを持ちます。
Arrowの型は入力元のObjectと出力先のObjectにより決まります。

Base Object

Objectの合成してObjectを生成する事や、
Arrowの演算から別のArrowを生成する事ができます。
一方、合成などの演算により生成されたのではない、基底となるObject/Arrowを
Base Object/Base Arrowと呼びます。
BaseであるObjectは、集合である自分の要素をデータを持ちます。
たとえば、
A = {1, 2, 3}
B = {3, 4, 5}
C = A | B (= {1, 2, 3, 4, 5})

のように、Aが、整数1,2,3を要素としてもつ集合、
Bが、整数3,4,5を要素としてもつ集合であり、
CがAとBの和集合として定義されるとき、
AとBはBase Objectであり、CはBase Objectではありません。
また、CがこのようにAとBの和集合として定義されるとき、
AやBの内容が変更されたとき、自動的にCの内容も更新されます。
たとえばBの要素として整数の6が追加された場合、同時にCも新たに6を要素としてもつことになります。

A = {1, 2, 3}
B = {3, 4, 5, 6}
C = A | B (= {1, 2, 3, 4, 5, 6})