「データ構造」 と 「名指し」 と 「定義域」 は、べつべつの論点です。

　たとえば、部品展開は、２項関係（親子関係）として記述することもできるし、３項関係として記述することもできるし--ただし、部品構成番号がある、という前提ですが--、あるいは、構成のすべてを記述することもできます。
　２項関係を使っている理由は、「構造」として、拡張性を実現しやすい構造だから--ではないでしょうか。

　もし、構成を、事実そのままに記述するのであれば、構成の階を、すべて、記述することが妥当な措置ですが、「データ構造」として、２項関係を導入している、ということでしょう。

　もし、構成のすべてを記述するとしたら、「親品番. 子品番. 孫品番...」となって、違う名前を付与することが、逆に、むずかしくなるのではないでしょうか。

　また、子品番としてのメンバーは、下位の階では、親品番になります。逆に言えば、１つのメンバーが、違う呼称になる、というのは、「構造 （親子関係）」として、「関係」に対して「名指し」をしたのであって、個々のデータ （メンバー） に対する「名指し」ではない、と思います。個々のメンバーに対する「名指し」は、あくまでも、（「論理モデル」では、） 「品番」でしょうね。
　「子品番」は、「関係」のなかで使われる呼称であって、事物を「名指す」呼称ではない、と思います。暁の明星も宵の明星も、「金星」です。

　もし、親品番とか子品番が、「呼称」だとすれば、レベル０に記述されるのは、「製品番号」であり、レベル１から或るレベルまで記述されるのは、「半製品番号」であり、或るレベルから leaf まで記述されるのは、「原材料番号」という呼称にしなければならない、という論法も成立します。

　「再帰」は、そもそも、「自己言及」型のタイプであって、１つの「類」のなかの２つの「種」というタイプではないので、定義域は、「後続」という関係のなかで示されます。「親品番」の定義域を、「子品番」が共有する訳ではない、と思います。「品番」としての定義域と、「親子関係」としての「関係」の定義域はちがいます。

　「親子関係」を「再帰」を使って、以下のように記述することが多いのですが、この単純な記述は、「あくまで」、「再帰」を、きわだって、意識するために使われているのであって、実地に使われるデータは、違う構造になっているはずです。

　　｛品目番号（Ｒ）、品目番号（Ｒ）、数量、...｝.

　
　というのは、「構成」では、「階数（上下関係、縦列の関係）」と「次数（横列の関係）」が、「原則的に」、記述されるはずです。ただ、次数は、実際のインスタンスが示しますので、「階数」のみを記述するはずです。この「階数」が、「再帰」の「関係」を記述します。

　　｛（部品構成番号）、階数、品目番号（Ｒ）、品目番号（Ｒ）、数量、LOW-LEVEL-FLAG｝.

　
　そして、LOW-LEVEL-FLAG を、「原則として」、記述するはずです。つまり、「継続あり」とか「もう打ち止め」とか、を示すために。

　したがって、「階数」が、「再帰」--あるいは、「親子関係」--を指示しますので、最初に記述されている「品番」は「親品番」という「意味」であり、次に記述されている「品番」は「子品番」という「意味」を示しているはずです。

　「論理モデル」では、「再帰」 （あるいは、「親子関係」） を、同じ「品番」を使って記述して、「階数」を使って「関係」を示します。
　「物理モデル」では、１つのテーブルのなかには、同じ名称があってはいけない、という規約があるので--なぜなら、「関係」も、物理的に記述されなければならないので--、「名指し」として （あるいは、定義域として）、「親品番」と「子品番」を使うのが当然でしょうね。

　僕自身は、「論理モデル」のなかで、｛品番（Ｒ）、品番（Ｒ）、...｝と示しても良いし、「関係」を明示するのなら、｛親品番（Ｒ）、子品番（Ｒ）、...｝と示しても良い、と思っています。

　同じような現象が、たとえば、「部門」を対象にして、「配賦部門」と「負担部門」などがありますが、或る「部門」は、配賦部門にもなれば、負担部門にもなる （AND/OR の関係） でしょう。

　
　（2004年11月16日）