前回の 「技術編-22 サブセット の周延」 では、以下の点を説明しました。

　（1） 集合の性質について語ることを 「集合的」と云い、メンバー の性質について語ることを 「周延的」 と云う。

　（2） 切断を適用すれば、メンバー のあいだには 「まじわり」 は生じない。

　（3） 論理の OR は、算術の ＋ と同値である。したがって、メンバー の総和 （union） は、集合の基数になる。

　本編 「技術編-23 サブセット の 『交わり』」 では、上述の （2） を確認しているだけなので、取り立てて補足説明はいらないでしょう。「切断」 の規則を破っているのであれば、その 「区分 コード」 は、その entity のなかに帰属しないので、entity から排除しなければならない。

　ちなみに、周延した状態の例として示されている ｛ 取引先区分. 取引先. 対照表 ｝ は、「L-真」 であっても 「F-真」 でないことに注意していてください。したがって、この対照表は、データ に関する 「制約・束縛」 を記述しているのであって、「個体」 を指示している訳ではない。この対照表は 「F-真」 ではないので、データベース のなかに実装しないはずの データ ですが──すなわち、プログラム の アルゴリズム として記述するか、あるいは、DD （Data Dictionary） のなかに定義すべき データ　ですが──、私は実装するように指導しています。というのは、以下の ふたつの理由のため。

　（1） もし、プログラム のなかで アルゴリズム として記述すれば、
　　　（この例で言えば、） 2³ の場合分けを記述しなければならない （一般的に言えば、2ⁿ）。
　　　そうすれば、プログラム の生産性が悪くなるし、保守性も悪い。

　（2） マーケット に出ている データベース は、データベース を一元管理するほどの DD を搭載していない。

　以上の理由から、この対照表を データベース のなかに実装しています。そうすれば、プログラム の アルゴリズム が ひとつの単純な関数引き （SELECT 文） で終わるので、プログラム の生産性・保守性が高い。そして、実際の システム 保守では、データ に関する 「制約・束縛」 が変更頻度の多いことも、この対照表を実装する理由の ひとつです。ただし、逆に言えば、この対照表は、あくまで 「L-真」 であって 「F-真」 でないことを忘れないでください。 □