2005年12月 1日 基準編-17 繰返項目の排除 >> 目次にもどる
2010年11月 1日 補遺  

 

 「繰返項目 (repeating data)」 を アトリビュート に限れば、「黒本」 に綴られていることは正しい。
 しかし、その記述は、下手くそですね (苦笑)。

 というのは、当時、「繰返項目 (repeating data)」 を アトリビュート に限ったがために、いわゆる 「HDR-DTL」 (one-header-many-details) を 「多値 (many-value)」 の観点から検討できない状態に陥ってしまった。そのために、96ページ から 99ページ に及んで、「HDR-DTL」 を検討しているが挫折している。「黒本」 は、以下の点を見落としてしまっている。

 (1) 「繰返項目 (repeating data)」 を、semantics の観点では、「多義」 として理解しなければならない。

 (2) 「多義」 は、「多値」 のなかで (「OR 関係」 と 「AND 関係」 として、) 考えなければならない。

 (3) 「多義」 は、「多値」 の 「OR 関係」 である。

 
 さらに、「黒本」 では、いまだ、「データ の周延」 に関して、妥当な検討をしていないことが窺える。というのは、「黒本」 の初版 (1998年) では、(「多義」 を除去して、アトリビュート を並べるために導入した) 「種別 コード」 を 認知番号といっしょにして、T字形表記のひだりに記述している。この時点では、「区分 コード」 と 「種別 コード」 のちがいを、いまだ、理解できていなかった──それを理解できるようになったのは、「論考」 を記述していたときである)。

 なお、当時、「繰返項目」 を排除するために作成した データセット に対して、「ER (Entity. Role)」 という略称を付与していたが、今では、「MO (Multi-valued OR)」 という言いかたに訂正している。 □

 



[ 補遺 ] (2010年11月 1日)

 「多義」 を多値関数として把握して、多値関数において、それぞれの値のあいだの関係が 「OR 関係」 「AND 関係」 のいずれかにあることを体系立って整えることができたのは、拙著 「論考」 を執筆した後でした。そして、拙著 「赤本」 において、多値関数を 「OR 関係」 と 「AND 関係」 の ふたつに分けて、それぞれ、説明しています。

 構文論 (syntax) 上、多値関数は、「OR 関係」 であろうが 「AND 関係」 であろうが、多値を それぞれ一価の従属関数として翻訳してしまえばいいのですが──データ 正規化では、いわゆる 「繰返項目の排除」 と云われている手続きですが──、論点となるのは、その形式的構成を観て、「意味」 が読み取れるかどうかという点です。すなわち、いくつかの一価の従属関数として記述された多値が、「排他的関係」 にあるのか、それとも、それらが同時に成立するのか、という条件を記述しなければならない、ということ。この点は、構文論上 [ 記号の演算 ] の論点として扱えばいいのか、意味論上 [ 記号の外側に立った 「記号の意味」 ] の論点として扱えばいいのかを私は迷ったのですが、一応、意味論上の論点として扱っています。多値の 「OR 関係」 「AND 関係」 は、形式的構造を観て一目で判断できるように記述されていなければならない、と私は考えました。そうでなければ、形式的構成は、事業の 「意味」 を記述していない、と。多値の 「OR 関係」 「AND 関係」 は、TMD (TM Diagram、有向 グラフ) 上、一目で把握できる記述になっています。

 多値関数を 「関係文法」 のなかに入れて扱うべきかどうか を私は とても悩みました。多値関数が 「関係」 を示している限りにおいて、「関係文法」 として扱うのが正当なのですが、もし、「関係文法」 のなかで扱うと、「関係文法」 の記述が込み入るし、多値関数の 「OR 関係」 「AND 関係」 を対比して説明したほうが把握しやすいので、TM の体系では、多値関数を 「関係文法」 から切り離して説明するようにしました。TM の体系は、以下のとおり。

 (1) 個体の認知 (entity の認知)
 (2) 並び (関係の対称性・非対称性)
 (3) 関係文法 (関係と関数)
 (4) 切断 (セット と サブセット)
 (5) 多値 (「OR 関係」 と 「AND 関係」)

 多値関数の 「AND 関係」 には ずいぶんと [ 7年ほど ] 悩まされてきて──多値関数の 「AND 関係」 を どのように説明すればいいか、という点を ずいぶんと悩んできて──、拙著 「赤本」 で 「ファンクター」 (関数の クラス) を導入しました。言い換えれば、セット 概念のほかに クラス 概念を導入した、ということ。「ファンクター」 を導入しなくても、「合成関数」 を使って説明することもできるのですが、「ファンクター」 を使ったほうが、TM’ [ TM ではない点に注意されたい ] を説明しやすいので、クラス 概念を導入しました。というのは、TM’ [ TM + みなし概念 ] において、「みなし概念」 は、クラス 概念を使っているので、TM を TM’ へ拡張するには、クラス 概念を結節点にしたほうが違和感を覚えないので。

 TM (あるいは、TM’) は、以下の考えかたで体系を組んでいます。

  合意 → L-真 → F-真

 「合意」 というのは、ユーザ が使っている言語を文字列として見做 (みな) して言語の使用法に従って 「entity」 を抽出する、という意味です。そして、「L-真」 は、構文論 (記号の演算) 上の手続き [ 関係文法 ] に従って構成された 「無矛盾な」 真 (構文論上の真) のことを云います。「無矛盾な」 構成は いくつも組めるのですが、それらのなかで、「現実的事態」 と一致する真 (意味論上の真) が 「F-真」 です──したがって、「F-真」 は (いくつか構成される 「L-真」 のなかで) 一つしかない。すなわち、「現実的事態」 と 「形式的構成」 が一致している、ということ。

 TM (あるいは、TM’) では、L-真の構成に対して F-真を験証するときに、クラス 概念を使っています。すなわち、TM (あるいは、TM’) は、「セット で作って、クラス で整える」 という体系になっています。その手続きにおいて、転換点 (クラス 概念の導入) になるのが多値関数の 「AND 関係」 です。セット と クラス とのあいだで継ぎ目を感じないように巧みに組んであります (笑)。

 ちなみに、「種別 コード」 は、構文論上、多値の データ を 「並べる」 ために導入された コード であって──本来、こんな人為的な コード を導入したくないのですが [ というのは、ユーザ 言語を変形しないことが原則なので ]、関数上 f (x, y) として記述された 「全順序」 を データベース は認識しないので、「並び」 を構成するために導入しなければならなかった。「種別 コード」 の典型的な使用法──データ を並べるために使う値──は、「自然数 (1,・・・, N) でしょうね。例えば、以下を考えてみます。

  (a) {商品番号、商品名称、・・・、商品単価、商品単価}.

 最初の商品単価 (正価格) の値を 100 として、次の商品単価 (割引価格) の値を 80 とします。この多値関数 [ OR 関係 ] を一価関数に翻訳すれば、以下のようになるでしょう。

  (b) {商品番号、商品名称、・・・}┼──<{商品番号 (R)、商品単価、単価種別 コード}.

 (a) の構成 [ 配列 ] では、物理的な並び──すなわち、(100, 80)──が 「意味」 を示していますが、多値関数になっているので、多値を排除した構成が (b) です。(b) では、商品単価が 2つの一価関数 [ 従属関数 ] として構成されているので、「並び」 を構成しなければならない。「並び」 を構成するために 「単価種別 コード」──たぶん、その値は、1 と 2 を使うでしょう──を導入して、{ 1, 100 } { 2, 80 } [ すなわち、(100, 80)] というふうに並べます。「種別 コード」 は、単純に言えば、データ を並べるために使う自然数と思っていいでしょう。ただ、実際の事業では、「区分 コード」 (切断) と 「種別 コード」 (並び) という語が混同されていることも多いようなので──たとえば、「特約店種別 コード」 とか──、「種別 コード」 が 「区分 コード」 の意味で使われているのか、それとも 「並び」 を構成するために使われているのかを注意していてください。







  << もどる HOME すすむ >>
  「T字形ER データベース設計技法」を読む