「属性と関係」のつづき
今回は、 http://togetter.com/li/71943 で話した属性と関係の話のつづきです。
オブジェクト指向やリレーショナルモデルでは、属性という概念が登場します。属性という用語／概念は、プログラマにはなじみ深いものです。あたりまえすぎて、もはや空気のような存在かもしれません。
この属性というものを使わずに、別の「関係」というものを使う関係指向という考え方について紹介します。*1
http://togetter.com/li/71943 では、OOとの比較、RDBとの比較、実装よりの話などが混在してしまいました。
そこで今回は、オブジェクト指向との比較に絞って話をします。*2
オブジェクト指向と関係指向の違い
クラスベースのオブジェクト指向では、まずクラスを定義します。クラスの定義には、属性の定義が含まれます。（メソッドの話は今回はしません。）そしてクラスから生成された各インスタンスは、クラス定義に基づいた属性を持ちます。
図にするとこんな感じです。（図はイメージです。）
オブジェクト指向では、属性値としての数値や文字列などの値もオブジェクトであると考えます。あるインスタンスが、他のオブジェクトを属性として「持つ」、あるいは、他のオブジェクトを知っているなどと表現します。
「持つ」にしろ、「知る」にしろ、属性に関する情報はオブジェクトの中に「含まれる」ことになります。
一方関係指向では、会社員や数値の集合があり、それらの集合の間に名前や身長などの関係があります。
図にするとこんな感じです。
会社員の集合に含まれるのは、他と区別することができる点としての会社員エレメントです。
先程のオブジェクト指向の例の会社員インスタンスとちがい、この会社員エレメントは、属性等の内部構造を持ちません。会社員エレメントは、識別するための情報を持っていれば良いので、01や02などのID番号を振ります。
各会社員がどんな名前であるか、身長がいくつであるか、といった情報は、名前という関係や身長という関係が持ちます。関係は、始点となる集合、終点となる集合の間を結ぶものとして定義されます。そしてその内部に、始点となる集合の要素と、終点の集合の要素の関係づけを持ちます。
「関係」が要素の対応関係の情報を持つという点を強調して図にするとこんな感じになります。
この「関係」は、始点となる集合の要素がひとつ決まれば、終点となる集合の要素が複数個（０個を含む）きまるもので、プログラミングでいう関数や連想配列に近いものです。この関係の正確な定義はまた別の機会にします。
各集合の要素は、文字列やIDといった単なる値であり、オブジェクト指向のインスタンスのような内部構造を持ちません。この点がオブジェクト指向と大きく異なるところです。
オブジェクト指向においては、すべてがオブジェクトであるということがよく言われますが、関係指向では、関係と値の集合という２週類を別のものとして扱います。
オブジェクト指向は一元論であり、関係指向は二元論であるといえるかも知れません。
まとめ
オブジェクト指向というパラダイムで、自分自身を見ると、名前や血液型など、様々な属性を備えた存在であるということになります。これらの属性情報は、各人が「持っている」「備えている」「知っている」ものであると考えます。
一方関係指向という見方で自分自身を見ると、ただアイデンティティだけが自分自身であり、名前や血液型というものは自分の内部にではなく、外部の関係性のなかにあるということになります。そして例えばこの人は田中さんで、あの人は鈴木さんで...と各人に文字列を対応づけるものが、名前という関係であるということになります。血液型であれば、各人をA型やB型といったものに対応づけるのが血液型であるということになります。
もちろんここでの目的は哲学的な話をすることではなく、より宣言的な記述で効率よくプログラミングをするためのモデルやそれに基づく処理系を構築することです。関係指向という見方も、目的ではなく手段です。この見方をもとに、どのようにアプリケーションの記述を行うかということが本題です。その本題にはいる導入として、まずはオブジェクト指向との見方の違いに絞って書いてみましたが、いかがでしたでしょうか。
ご意見ご感想ツッコミ等お待ちしております。<追記>
書いてみて思ったのですが、やっぱりこれだけ書いて終わりでは、なんのこっちゃだと思うので、全体の経緯や目的の話、実装よりの話、Reactive Programming関係の話、RDBとの対比、圏論との関係の話なども需要があれば書きたいと思います。
