「属性」と「関係」

pokarim @pokarim

@cocoatomo ２つ前のは間違いです。任意の深さのツリーを得るには、hoge = {id:id,buka:部下.hoge, name:社員名} と関係'を再帰的に定義する必要があります。

pokarim @pokarim

@cocoatomo すると例えば、[{id:001,buka:[{id:002,buka[[{id:003,buka:[],name:["three"]}], name:["two"]}] ,name:["one"]}]といった形の値が入出力に使える事になります。

pokarim @pokarim

@cocoatomo もちろんです。よろこんで！　今日はまた寝なきゃなので、もうちょっとだけまってください。寝ながら説明の組み立てを考えます。zzz

tomo🐧@learning @cocoatomo

@pokarim 同じく俺ももう寝るので, また明日 (以降) よろしくお願いします.

tomo🐧@learning @cocoatomo

@pokarim メモ代わりですが. 今 @pokarim さんが考えているものは Hypergraph になりませんかね? 思い付きですが.

pokarim @pokarim

@cocoatomo 知らなかったので調べました＞Hypergraph ノードのペアがグラフならノードの空でない集合がハイパーグラフってことでしょうか。

pokarim @pokarim

@cocoatomo Hypergraphは無向なんでしょうか？グラフやHypergraphが関係することもなんかありそうですね。

pokarim @pokarim

@cocoatomo 多値の話にいったん戻ります。ところで多値の反対、ひとつだけの値を指す言葉がわからないので、とりあえず単値と呼ぶことにします。

pokarim @pokarim

@cocoatomo 動機の出発点はデータベースを使うようなアプリケーションを、スキーマとロジック合わせてもっと簡単に記述したいということです。多値の扱いに関しても、仮想ターゲット的なアプリの記述やその変更をより簡単簡潔にするために、今のところ先述のようになってます。

pokarim @pokarim

@cocoatomo 最初は、単値->単値の関数と単値->多値の関数で考えていました。ただ、これだと関数を合成するときに、mapやconcatMap的なものをうまく使って型を合わせる必要があります。Excelなみに簡単にすることなのが目標なのでそこがまず問題でした。

pokarim @pokarim

@cocoatomo またRDBMSを使った開発の際に１対多から多対多への仕様変更があると、ロジックのあちこちを変更する必要があって煩雑で、これを解決したいというのもありました。

pokarim @pokarim

@cocoatomo それで見回してみるとjQueryがガチガチのプログラマでない人にも使いやすいと評判がよいというのが目にとまりました。jQueryが簡単な理由として扱っているオブジェクトが単数か複数か、もしくは存在しないのか考える必要がないというのがあるのではと考えました。

pokarim @pokarim

@cocoatomo でListモナドのように、関数はすべて単値->多値にして、合成するときは、f.g=g;f= lambda x:[z for y in f(x) for z in g(y)] のようにする約束にすればいいかなと。

pokarim @pokarim

@cocoatomo すべて型は単値->多値にしておいて、単値->単値にしたいような場合、戻り値の要素の数が１であるように制約条件をつける仕組みがあればいいと。そうすれば１対多から多対多への変更も構造の変更でなく制約の緩和だけで対応できます。

pokarim @pokarim

@cocoatomo RDB界隈ではNullの是非についての昔からもめているようですが、属性値が空集合であるということに近いんじゃないかと考えています。FPではNullでなくOptionやMaybeモナドが使われますが、...

pokarim @pokarim

@cocoatomo ListモナドがMaybeモナドの代わりになることはよく知られています。

pokarim @pokarim

@cocoatomo FPではNullになりうるIntの値を扱いたい場合は、Option[Int]なりMaybe Intなりを使います。これは型を厳密に考えれば、NullをとりうるIntの属性値の型は生のInt型ではなくHoge[Int]型であるということです。

pokarim @pokarim

@cocoatomo こう考えると、RDBでNullの是非についてもめるの原因もわかります。厳密にはRDBでNull的な値を表現するためには行が無い事、行の空集合でそれを表現するべきです。しかしそれを徹底するとテーブルの数が無闇に増えてしまい煩雑な上パフォーマンス上も不利です。

pokarim @pokarim

@cocoatomo RDBでのNullを含む比較演算等の結果はNullになります。これもMyabeモナドに近いですが、適切にISNULLを使わないと落とし穴にはまりがちでバッドノウハウの香りがします。

pokarim @pokarim

@cocoatomo そうするとRDBの属性値も本来は生の整数値などではなく整数の集合のようなものであるべきなのではないかと思えてきます。さらにそう考えると、1対多->多対多の移行の問題、交差エンティティにするべきかせざるべきかの問題も、同根である事がわかります。

pokarim @pokarim

@cocoatomo 翻って日常会話時に単複をどう扱っているか考えてみると、子供たちの父親たち、と言ったり彼の父親と言ったりする時、単数か複数か、それぞれに関連した集合の和なのか、といったことを考慮して構造が変わるような事はなく、〜達といった注釈的なものがつくだけです。

pokarim @pokarim

@cocoatomo 日常会話でも生の値は扱われずに、単数or複数や可能性、矛盾していたり存在しなければ空集合になりうるような、なんらかのコンテナに包まれた値を扱っているとアナロジー的に考えられます。Int値がNullをとりうる方が直感的には自然でありうることとも符合します。

pokarim @pokarim

@cocoatomo あと単値->多値でなく多値->多値を基本とした理由については、また後ほど。いったんあがります。

tomo🐧@learning @cocoatomo

@pokarim 対比させる場合は「一価」と「多価」ですね.

tomo🐧@learning @cocoatomo

@pokarim Hypergraph は始点と終点も集合にできたような覚えが…… 後で調べてみます.