集合の性質に対する考えかたを「集合的」といい、集合のメンバーに対する考えかたを「周延的」といいます。そして、「集合」としての性質が、そのまま、それぞれのメンバーに適用できる訳ではないし、それぞれのメンバーに属する性質が、そのまま、「集合」に適用できる訳ではないでしょうね。

　事物との事物のあいだに「関係」を結ぼうとすれば、それぞれの事物に対して、「集合的」な考えかたをしますし、インスタンス（メンバー）を対象にすれば、「周延的」な考えかたをします。したがって、「論理モデル」では、ＤＡは、「データ構造」を記述するために、集合を括る一般的な名称を使うでしょう--たとえば、「登録品番」や「出荷品番」に対して、「品番」のように。なぜなら、「論理モデル」では、「形式の妥当性」が論点になるから。
　いっぽう、ＤＢＡやプログラマは、「周延的」に考えます。なぜなら、個々のメンバーを対象にして、有限回の操作をするためには、「値の真理性」が論点になるから。

　ＤＡは、「論理モデル」のなかで、「品番」が、「登録」という事象と関与すれば、「登録品番」だし、「出荷」という事象と関与すれば、「出荷品番」として、考えるでしょうね、きっと。
　同じように、「日付」が、「受注」を記録するために使われたら、「受注日付」だし、「入社」を記録するために使われたら、「入社日付」として考えるでしょう、きっと。

　「論理モデル」は、「（世の中には） 同じ事物はない」ということを前提にして、事物を認知して、「構造 （事物と関係）」を記述します。したがって、「論理モデル」では、「（世の中には） 同じ事物はない」ということを示すために、なんらかの primary-key を使うはずです。「論理モデル」では、（インスタンスの一意性が検証されたら、） 一意性を実現している事物に対して、「命名規約」を適用する、というふうに考えているはずです。
　というのは、「論理モデル」では、（インスタンスを集合として記述するための） スキーマが、おもに、対象になっているので、「（共通の性質をまとめた） 名称」を使おうとします。

　そのために、「論理モデル」を記述するＤＡは、「品番」という呼称を使って、「登録」とか「出荷」を修飾語として考えるようです。そのために、プログラムのなかでは、以下のように、記述しなければならない、ということになります。

　　　　　　「品番 of 登録」（あるいは、「品番 of 出荷」など）

　
　この記述を、ＤＢＡやプログラマは、嫌います--というのは、プログラム作成の負荷が増えるので。ＤＢＡやプログラマは、個々のインスタンスを対象にしますので、「登録品番」と「出荷品番」を、べつべつの事物としてみなします。

　おそらく、「通論では」、「概念設計」のなかで、「登録品番」とか「出荷品番」という呼称を認知して、「論理設計」のなかで、それらを「品番」として括るでしょう。そして、ＤＡとＤＢＡとプログラマが喧嘩するでしょう（笑）。

　
　（2004年11月 8日）