#連想リストのリストを<relation>であらわそうとすると、relation-column-namesをどうするかという問題に突き当たります。連想リストのリストはカラム名を一元管理していないからです。(object-set-relationがclassで管理できることと対照的です。)かといって、リレーショナル代数の演算ができないかというとそうでもない。無限カラムのリレーション(?)のような概念があるような感じです。
#RSSやATOMのような形式のsxmlもリードオンリーの<relation>で扱えるのかと考えてみるのですが、この場合はrelation-rowsをどうするかという問題にぶつかります。relation-column-names,relation-accessorはsxpathで定義できそうなのですが。
#各rowにあたるalistのcarのunionを取ればカラム名のリストは得られると思います。カラム名のリストを外延的に取れることは関係演算にとっては必須ではないかな? 今はエラーチェックに使ってるだけのような気もしてきた。それならあまり本質的ではないかもしれない。
#RSSはそのままだとツリー構造なので、そのまま<relation>にはマップできないでしょう。正規化して複数の<relation>を使うようにするか、3つ組に直して各rowを{subject,predicate,object}として扱うか、かなあ。
#連想リストをタプルとみなしたとき、カラム名に対応する値がない場合は不定ということにすればどうかと考えたのでした。この場合カラム名のチェックは必要ないというわけです。それが関係代数と整合性のある考えなのかどうかについてはよくわかりません。
#RSSについては、単に項目名とリンク、記述＋αのテーブルというくらいの認識でいたのでした。OpenSearchなどのAPIの結果をsxmlで扱うよりはrelationで扱ったほうがいいような気がしたのです。
#実用面から言えばrelation-column-namesは、単にテーブル形式での表示とかCSVへのダンプ等、全カラム名が必要になることが度々あるから用意しといたほうが便利でしょ、というノリでいい気がする。それならalist-relationはcolumn-namesを聞かれる度に計算するか、それが重すぎるようなら結果をキャッシュするとか、その程度で良いように思う。
#ただ、関係演算の定義に戻ると多くの議論がcolumn ga
#columnのセットが順序つき、既知、有限であることを前提にしてる (finitary relation) ように見えるのが気になる。
#util.relation書いた時も基本的な定義から出発してたんで、多分有限個のドメイン X1, …, Xk があって、各rowはそのデカルト積 X1 × … × Xk の要素、と考えたんだと思う。この定義だとcolumn-namesは最初から確定している。
#alist-relationは追加されるrowによってドメインの集合が動的に変化する、ということにすれば理屈の上でおかしなことにはならないと思うのだけれど、将来<relation>の上に作られる色々な最適化が効きにくくなることはあるかもしれない。
Gauche > Archives > 2012/07/08