回帰 （recursive） は、数学的には、「帰納的に可算である」 ことをいう。すなわち、自然数の集合 A が、原始帰納的関数 g： N → N を使って、A ＝ { g (0), g (1),・・・} と表現されるなら、A は、「帰納的に可算である」 という。「帰納的に可算である」 ということは、A の メンバー を並べる計算手順がある、ということ──ただし、メンバー は、大きさの順に並んでいなくてもいいし、同じ値がくりかえされてもよい。さらに、空集合も帰納的に可算である、とされる。

　数学的な回帰を応用して、データ 構造では、以下の 2点を、再帰の前提としている。

　（1） 「自己言及」 型の構造である。
　（2） メンバー のあいだには、「先行・後続」 関係 （あるいは、階の関係） が成立する。

　したがって、再帰の典型的な構造として、「部品構成」 や 「伝票の赤黒方式」 がある──それらのほかにも、代替品の指示や、工程の構成や、コール する （calling） プログラム と コール される （called） プログラム などがあって、再帰の適用は、多い。

　さて、「抱き合わせ」 セールス の対象となる商品 （2つの商品） は、再帰の構造かどうか、という点を以下の 2つの状態のなかで考えてみる。

　（1） 「抱き合わせ」 セールス の商品は、事前に、構成されている （ルール 化されている）。
　（2） 「抱き合わせ」 対象は、事前に構成されていない。

　もし、たとえば、陳腐化のおそれがある商品を一掃するために、「抱き合わせ」 形態として、セールス を促進をしたのであれば──たとえば、陳腐化のおそれがある商品 B を、商品 A と抱き合わせて セールス したのであれば──「抱き合わせ」 商品かどうか、という点は、データ として、記録の対象にはならないかもしれない。もし、利益計画の一環として、「抱き合わせ」 セールス を実施したのであれば──たとえば、商品 B を半値にして、商品 A と抱き合わせた セールス の限界利益と、商品 A と商品 B を、それぞれ、個々に セールス した際の限界利益を比較するのであれば──、「抱き合わせ」 の構成は、記録されていなければならない。

　（2） であれば、2つの商品が組みになって セールス されたのだから、{ 商品 コード (R)、商品 コード (R) } は、1つの組番号として置換してもよい。セールス した事実と、商品が セールス の際に編成する構成は、べつの意味である。もし、「抱き合わせ」 商品に対して、新たな商品 コード （疑似 コード） を使うのであれば、以下の記述となる。

　　売上 HDR　{ 売上伝票番号、売上日、・・・}. [ E ]
　　売上 DTL　{ 売上伝票番号、商品 コード (R)、数量 }. [ E ]
　　★ 商品コードには、通常の商品コードと疑似コードの いずれか が記述される。

　　商品　{ 商品 コード、商品名称、値段、・・・}. [ R ]
　　商品. 商品. 再帰　{ 商品 コード (R)、商品 コード (R)、商品 コード [ 疑似 コード ] (R) }.　 [ 再帰 ]
　　★ 疑似 コードは、再帰の性質 （Ｔ字形の右側） のなかに記述して良い。

　
　たとえば、「抱き合わせ」 が、商品 A 1個に対して、商品 B が 2個である （あるいは、複数個） であれば、再帰のなかに、「員数」を記述する。

　ただし、上述した構造は、（DA 有段者向けの） 簡略された構造であって、たとえば、構造を観て、DTL の商品 コード のなかに、疑似 コード が記述されることは、なかなか、理解しにくい。正確には、以下の構造が正しい。

　　売上 HDR　{ 売上伝票番号、売上日、・・・}. [ E ]
　　売上 DTL　{ 売上伝票番号、商品 コード (R)、数量 }. [ E ]

　　商品 [ R ]
　　　｜
　　　× null （商品名称）
　　　│
　　　├ { 商品 コード、商品名称、値段、・・・}
　　　│
　　　└ { 商品 コード、値段、・・・} [ 抱き合わせ ]

　　商品. 商品. 再帰　｛商品 コード [ 疑似 コード ](R)、商品 コード (R) }.　 [ 再帰 ]

　
　もし、「抱き合わせ」 用の商品 コード を用意しないのであれば、以下の構造となるかもしれない。

　　売上 HDR　{ 売上伝票番号、売上日、・・・}. [ E ]
　　売上 DTL　{ 売上伝票番号、商品 コード (R)、数量、値段 }. [ E ]

　　商品　{ 商品 コード、商品名称、値段、・・・}. [ R ]

　
　そして、売上 DTL の商品の値段のなかに、「抱き合わせ」 セールス した際の値段──たとえば、商品 A に対して、抱き合わせにした商品 B の値段を半値にするとか──が記述されるかもしれない。そうだとすれば、売上 DTL は、サブセット となる （値段が null になる）。

　　売上 HDR　{ 売上伝票番号、売上日、・・・}. [ E ]
　　売上 DTL　{ 売上伝票番号、商品 コード (R)、数量、値段 }. [ E ]
　　　｜
　　　× null （値段）
　　　│
　　　├ { 売上伝票番号、商品 コード (R)、数量 }
　　　│
　　　└ { 売上伝票番号、商品 コード (R)、数量、値段 } [ 抱き合わせ ]

　　商品　{ 商品 コード、商品名称、値段、・・・}. [ R ]

　あるいは、抱き合わせにした 2つの商品のそれぞれに対して値段を割引くかもしれない。どの商品と、どの商品が 「抱き合わせ」 セールス の対象になったのかという構成は──店の人が知っているが──、データ 構造のなかには、明示的に記述されない。もし、「抱き合わせ」 構成を、明示的に記録したいのであれば、構成を、コンピュータ のなかに、入力しなければならない。

　
　さて、「抱き合わせ」 構成を、再帰として、扱ってきたが、その扱いは、厳正に言えば、少々、論点になる。
　「抱き合わせ」 構成として、以下の 2つが想像できる。

　（1） 2つの商品のあいだには、なんらかの 「主従」 関係が成立している。
　（2） 2つの商品は、相互補充的な関係が成立して、1つの ペア・セット （組） に近い。

　（1） は、たとえば、前述したように、商品 B を半値にして、商品 A と抱き合わせて、商品 A あるいは 商品 B の販促を目的とした形態が考えられる。こういう形態であれば、「抱き合わせ」 構成は、再帰となる。
　論点になるのは、（2） のように、「対等な──並べる手順が考慮されない──抱き合わせ」 である。この形態は、「構成 （validation-rule）」 を示す対照表として記述される。しかしながら、対照表は、2つの entity （resource） のあいだに成立する関係である。しかも、「構成 （validation-rule）」 を示す対照表は、理論的には、（アルゴリズム の I/O 化であって、） 現実の事態と データ （event 概念） としての指示関係ではない。しかも、再帰は、あたかも、対照表を作る 2つの entity （resource） が、たまたま、同じになっている 　( aRb として、a ＝ b ) 現象として考えることもできる。

　再帰では、厳正に言えば、メンバー を並べる手順がなければならない。しかし、現実的には、「商品 A に対して、商品 B は、抱き合わせの関係にある」 という言いかたと、「商品 A と商品 B を抱き合わせにする」 という言いかたには、ほとんど、相違がないのではないか。逆の言いかたをすれば、「商品 A と商品 B を抱き合わせにする」 という意味を、「商品 A に対して、商品 B は、抱き合わせ関係にある」 として理解しても良い、ということになるのではないか。とすれば、（2） も、再帰として記述しても良い、と思う。

　「抱き合わせ商品」 という小さな現象であっても、データ 構造として、再帰や HDR-DTL や サブセット などの様々な構造が選択される （構造を作ることになる）──それらのなかから、適正な構造を選ぶことになる （作ることになる）。したがって、1つの デザイン・パターン を適用することはできない。