「属性」と「関係」

pokarim @pokarim

RDBとかOOがデータモデリングに使う上でいまいちな理由のひとつは「属性」という考えにとらわれすぎてるから。

pokarim @pokarim

「属性」と考えると、常にその所有者となるオブジェクトがひとつ決まる必要がある。

pokarim @pokarim

オブジェクトと属性の間の所有関係がはっきりしていて、そのオブジェクト（だけ）がその属性を主体的に管理ないし知っていればいい場合は問題にはならない。むしろうまく行く。

pokarim @pokarim

そうでない場合、オブジェクトに関連した情報があるけれど、それを誰が所有すべきか明確でないような場合、例えば２種類のオブジェクトの間の関係性をどちらの（または両方の）属性とするかといった問題になる。

pokarim @pokarim

そこでテーブル設計で言えば、交差エンティティや中間テーブルといったものが出てくる訳だけど、そういったテクニック的なパターンが頻出する場合は、なにか別のものをエミュレートしているだけなんじゃないかと疑った方がいい。

pokarim @pokarim

@naka_aki_spl すごくわかります。長期的な話としては、むしろその間に区別がある事こそが問題の本質だと思っております。

tomo🐧@learning @cocoatomo

@pokarim もっと対等な「関係」の方が良いと思ってます。その関係自体に意味を持たせられないかなぁ。

pokarim @pokarim

他に問題になるパターンとしては、属性の所有者と管理者が一致しない場合。社員番号や社員評価はおれの属性だけど管理しているのは会社でおれに変戸口や閲覧の権限はない、みたいな場合。

pokarim @pokarim

属性がやたら沢山あるときも、やっぱり属性って微妙だなと思うはめになる。それに属性には、本質的には逆にたどるという操作が想定されてない。そこらへんも後からエミュレートするはめになる。

pokarim @pokarim

@cocoatomo ぼんやりはわかるのですが、対等というとどんなイメージでしょうか？kwsk!

pokarim @pokarim

@cocoatomo 「対等」の意味もうちょっと考えてみて、多分わかりました。自分がイメージしてるのと近そうです。間違ってたら適当につっこんでください。

tomo🐧@learning @cocoatomo

@pokarim 属性だと主従関係が強いので、もっと弱めた感じです。N:N の関係を表すのに、RDB ではマスタどうしを突き合わせる対照表を作りますが、それが第一級オブジェクトとして扱えないかなぁ? と妄想してます :)

pokarim @pokarim

@cocoatomo 大変興味深いですね。やっぱり近そうです。僕のイメージしているのは、集合と関係の圏"っぽい"ものです。

tomo🐧@learning @cocoatomo

あれ? Prolog って関係の表現できなかったっけ?

tomo🐧@learning @cocoatomo

@pokarim 発端は、「a と b は夫婦です」という情報を実装するときに、a にも b にも isPartner というメソッドを実装するの? という疑問です。 その圏の話も kwsk!

tomo🐧@learning @cocoatomo

---------- ここでちょっと脱線 ----------

tomo🐧@learning @cocoatomo

ふと思い出した RDB への違和感。 数学理論の関係代数を使ってるとはいうものの、実際には「関係」というより「函数」もしくは「多値函数」としてしか使ってないんじゃない?? 実装に落とす以上、キーを振るのはしょうがないのかな?

非実在naka aki @naka_aki_spl

@cocoatomo 理念上はキー(PKとかのことですよね)は必須じゃなく、「全部の」カラムが全く一致する行は2つ作れないという流れだったかなと思います。ただ実際はほんとに全カラム同じ値の行を複数作れちゃう実装は多いみたいっすね。ちょっとびびった。

非実在naka aki @naka_aki_spl

「実装上」ってのはそれこそ「絞り込むのの」コストという意味ではそういうことだろうな。

tomo🐧@learning @cocoatomo

@naka_aki_spl キーは PK のことです。 関数代数では、関数をタプルの「集合」で定義しちゃったもんで重複無しになりましたが、現実の実装だとその制限は苦しいですよね。集合を実装するのはコストがかかるのですよ。ここのギャップが気になります。

非実在naka aki @naka_aki_spl

@cocoatomo 実装の話になりますが、「制限が苦しい」んでしょうかね? むしろ馬鹿正直にそう振舞うよう実装しちまって、「ほら性能落ちるでしょ適切にPK考えろ藻前ら」という方向に振ってもいいような気がする。PKを作るというよりPKを「絞る」かんじ。

tomo🐧@learning @cocoatomo

@naka_aki_spl その RDBMS たぶん売れないwww 「理論的なことはどうでもいいから、一番速いやつを頼む。」っていうのがほとんどの現場の感覚でしょう。 その上で、インデックスや複合インデックスを張りまくってて遅くなってたら笑ってしまいますが :P

非実在naka aki @naka_aki_spl

@cocoatomo しー。それ言ったら激怒する人が(ry

非実在naka aki @naka_aki_spl

@cocoatomo そういや現物見たことないんでﾀｼｶベースですが、DB2あたりだとデータアクセスを見て自動で自分に適切なインデックスかましてくれる機能があるとか聞いたような記憶が…

tomo🐧@learning @cocoatomo

---------- 脱線ここまで ----------