■

業務アプリのデータ構造は、ほどほど複雑だ。
ほころびの多いアナロジーになってしまうが、忘却関手の話を読んだとき、業務アプリつくるときにＲＤＢにデータをマップする作業を連想した。

群とか全順序集合とか、数学的な構造は、集合＋αで定義することが多い。というか、集合論が公理化に使われたぐらいだから、当然普通の数学的な構造は集合を使って定義できる。順序集合なんかは、まず基本の集合と、その集合の要素間の順序関係の集合、この二つで定義できる。逆に言えば、集合をふたつ見つけてきて、この二つの集合は条件を満たしているので、ふたつをセットで考えることで順序集合だとみなせますね、とかできる。
で、圏論で面白いのに、忘却関手ってのがある。集合と、その順序関係がセットになってるときに、「順序関係」のところだけを「忘れてしまえ！」とやると、順序集合から
ただの集合へマッピングすることができる。
マッピングすることはできるけど、それやっちゃったら、要素間に順序関係があったことはわすれちゃうよね、ということで忘却関手というらしい。
で、もちろん厳密な議論じゃなくてイメージだけの話だけど、
ＲＤＢで業務アプリをつくるときも、これと似た構造があるように思える。ＲＤＢってのは、基本的に集合である。制約条件もつけられるが、あんまりこみいった制約を付けることはできないので、ここでは無視するとする。
で、ＲＤＢは集合なので、どんなデータ構造でもマッピングすることはできるけど、やっぱり色々大切なことを忘れてしまっている。
忘れてしまった分については、毎度Ｊａｖａとかでプログラミングして、整合性をたもつように面倒みていると。そんなふうに見える。
業務アプリで扱うデータっていうのは全体で見ると、ただの集合、とかただのツリーとかでは決してなくて、ツリーとか集合とか順序集合とかそんなものがいろいろと組み合わさってできているのだと思う。
つまり、ＲＤＢなら、「すべては一階述語論理の命題の集合であらわせる！」とか、オブジェクト指向なら「すべてはオブジェクトだ！」とか、ＸＭＬＤＢなら「とりあえずツリーって柔軟だから、ぜんぶツリーにしとけばいいんじゃね？」とか。。。
そんなことをいいはって一度整理できたーと思うわけだけど、
色々つじつまが合わないところとかがでてきてしまうので、
それに関してはしょうがないから毎回チューリング完全な言語でプログラミングをして、なんとかつじつまをあわせましょうね、
とやってるんじゃないか。
つじつまあわせのベストプラクティス（＝デザインパターン）は、もうたくさんだ。

この際、全部をいちどシンプルな構造にマッピングする、という考えはあきらめて、業務アプリがあつかうデータ構造を、ツリーとか集合とか順序とかグラフとかの組合せでできてますねー、と分析して、それをそのまま格納できるようなモデルを用意するしかないんじゃないか。というか用意しようと思う。