「多値 （多価関数）」 は、Ｔ字形 ER手法を TM に変更するうえで、重大な変更のひとつでした。拙著の出版順で言えば、「黒本」 では、複数の値が充足される項において、「選言 （OR） 関係」 を 「多義」 として──この時点では、「多義」 というふうに説明していて、「多値」 という語を使っていなかった──「連言 （AND） 関係」 を いわゆる 「HDR-DTL （one-header-many-details）」 構成としていて、「多義」 と 「HDR-DTL」 構成とを べつべつの カテゴリー で観ていましたが、「論考」 でも、「HDR-DTL」 構成を いまだ 関数の観点で掴み切れていなかった。

　「HDR-DTL」 構成を関数の観点で扱って──すなわち、ひとつの合成関数として扱って──具象 カテゴリー・ファンクター （言い換えれば、クラス 概念） で説明したほうが至極簡単であることに気づいた時期は、「論考」 を出版した後でした。そして、「多義 （多価関数において、値が排他的 「OR」 関係になる現象）」 と 「HDR-DTL （多価関数において、値が併存的 「AND」 関係になる現象）」 を 「多値関数」 の観点で統一的に説明した拙著が 「赤本」 です。言い換えれば、「多値」 が 「OR」 関係あるいは 「AND」 関係のいずれであるかという観点で整えました。すなわち、「赤本」 では、多値を以下の ふたつの クラス で考えるようになった次第です。

　（1） M_OR （多値の排他的選言関係）
　（2） M_AND （多値の併存的連言関係）

　実地の仕事では、M_OR のことを 「MO」 と云い、M_AND のことを 「MA」 と云うことが多い。

　M_OR の文法そのものは、「赤本」 103 ページ で例示したように簡単ですので、本 ページ で改めて補足説明するまでもないでしょう。

　M_OR について、ひとつだけ補足説明するならば、「上限」 の問題でしょうね。M_OR が生じる現象に対して、「多値の配列 （いわゆる 「項の横持ち」） を排除して、正規形として一価関数の構成にする理由は、「上限」 が不明だからというふうに説明されることが多いようですが、そういう説明では モデル の構成要件 （前提） にそぐわない。たとえば、以下の構成を例にして考えてみましょう。

　　{ 従業員番号、従業員名称、・・・、部門 コード (R)、部門 コード (R)、・・・ }.

　従業員が 「転部」 した履歴を記録する、とします。そのときに、部門 コード を いくつ定義すればいいのかわからない──すなわち、「上限」 がわからない──ので、実際に生じた事実を記録するように、以下の構成にする、というふうに説明されることが多いようです。

　　{ 従業員番号、従業員名称、・・・ }.
　　{ 従業員番号 (R)、部門 コード (R) }.

　{ 従業員番号 (R)、部門 コード (R) }. の データ を 「並べる」 ために、なんらかの配慮がいるのですが、ここでは、争点に 直接 関与しないので省略しておきます。

　さて、もし、「上限」 が不明だからというふうに説明するのであれば、「1年間の売上高を記録する構成」 の非妥当性を説明できないでしょう。

　　{ 売上高 （1月）、売上高 （2月）、・・・、売上高 （12月）}.

　1年は 12ヶ月で構成されるので、「上限」 は 12月です──言い換えれば、13月はない。
　「配列」 が モデル 上──すなわち、多値関数において──妥当でない 「本当の理由」 は、モデル の正当化条件・真理条件を破るからです。すなわち、たとえば、上述の売上高の 「配列」 において、いま、4月までの値が充足されているとします──言い換えれば、5月以後の値は充足されていないとします。そうすれば、5月以後の値は、「真 （事実的な F-真）」 を問えない。すなわち、「真とされる値」 でない状態は 「構成 （モデル）」 の中に入れない──というか、もっと正確に言えば、「充足していない状態」 は値ではない──というのが正しい 「解釈」 でしょうね。 □