2008年 6月 1日 「技術編-5　Ｔ字形 ER手法の記法」 を読む >> 目次に もどる
2013年 7月23日 補遺 　


　TM は、かつて、「Ｔ字形 ER手法」 という呼称でした──「Ｔ字形 ER手法」 という呼称を TM というふうに変更したのは、単に、呼称を変えたのではなくて、モデル としての整えかたが変わったからです。ただ、「Ｔ字形 ER手法」 でも TM でも、diagramming は同じです──すなわち、（学習簿記で使われている） 「Ｔ-account」 記法を流用しています。そして、記法として 「Ｔ-account」 形式を使ったので、「Ｔ字形 ER手法」 という呼称にしたという次第です。ただし、TM は、「Ｔ字形」 の頭文字 T と、「手法」 の英訳 Method の頭文字 M を使って、単に略語にした訳ではない点に注意してください。TM は、数学の モデル である Turing Machine （チューリング・マシーン） を もじって命名しました。というのは、モデル は──特に、データベース 設計 さらに 事業過程の分析において──、単なる記法 （diagramming） ではなくて、アルゴリズム (文法） をもった言語 L （経験論的な言語 L） でなければならないという思いを込めて、Turing Machine に範を仰いだからです。

　さて、TM （あるいは、Ｔ字形 ER手法） が 「Ｔ-account」 記法を使った理由は、以下の 2 点にあります。

　（1） 「命題論理」 を前提にして、ひとつの 「情報 （帳票、画面など）」 のなかで使われている語彙
　　　　を仕訳する。
　（2） 「Ｔ-account」 では、「左側」 に、個体指定子の関係文法を適用して、「右側」 に、恒真的な
　　　　「性質」 を記述する。（ここで云う 「恒真的」 は、「そのもの-の」 という意味で、ほかの個体
　　　　に影響されないというくらいの意味です。）

　（1） では、一般手続きとして、以下の 2つの手順を辿ります。

　（1）-1　データ （語彙） を、仕訳帳で、仕訳する。
　（1）-2　データ （語彙） を、元帳に、転記する。

　すなわち、ひとつの 「情報」 に対して、まず、ひとつの 「Ｔ-account」 を用意して、語彙を仕訳します──個体指定子を 「左側」 に仕訳し、「性質」 を 「右側」 に仕訳するという 「仕訳帳 （journal）」 を作成します。次に、「左側」 に仕訳された・それぞれの個体指定子ごとに 「元帳 （ledger）」 を作成します。この 「元帳」 が 「個体 （entity）」 です。この手続きの具体例は、「赤本」 の 177 ページ を参照してください。

　そして、（2） では、「Ｔ-account」 は、以下の 2 つの視点に立って読むことができます。

　（2）-1　「左側 （個体指定子）」 の定義が 「右側 （性質）」 に記述されている。
　（2）-2　「右側 （性質）」 を前提にして、「左側 （個体指定子）」 が指示する セット （集合） を作る。

　
　TM は、（2）-1 を前提にしていますが、（2）-2 を排除している訳ではない点に注意してください。


　　　　　　　定義 （S-P）
　　　　　┌────────┐
　　　　　｜　　　　　　　　↓
　┌─────────────────┐
　│　　　　　　　取引先　　　　　　Ｒ│
　├────────┬────────┤
　│取引先コード　　│取引先名称　　　│
　│　　　　　　　　│取引先電話番号　│
　│　　　　　　　　│　　　・　　　　│
　│　　　　　　　　│　　　・　　　　│
　│　　　　　　　　│　　　・　　　　│
　│　　　　　　　　│　　　・　　　　│
　└────────┴────────┘
　　　　　↑　　　　　　　　｜
　　　　　└────────┘
　　　　　　　生成 f (a1, a2, ..., an)

　（2）-1 の読みかたでは、この例で言えば、「取引先」 とは、しかじかの 「性質」 をもっている管理対象であると定義されています──たとえば、取引先 A は、名称 a かつ 電話番号 t をもっている、ということです。いっぽう、（2）-2 の読みかたでは、しかじかの 「性質」 が充足されたら、「取引先」 という外延を生成することができるということです──したがって、（2）-2 の読みかたは、いくつかの性質に対して、数学的な 「直積」 を構成したと考えて良いでしょうね。いずれの読みかたであっても──定義法であれ、関数法であれ──「充足」 概念が前提になっていますので、当然ながら、変項のなかに、「null」 を認めない点に注意してください。というのは、「null」 は、「undefined および unknown」 であって──慣例的に 「null-value （ヌル 値）」 という言いかたをしますが──「充足」 概念上、「値」 ではないから。したがって、データ 演算では、null を算式 （たとえば、等式） のなかで 「値」 として扱うことはできないのです。

　「個体 （entity）」 を定立したら、関係文法は、「Ｔ-account」 の 「左側」 を項として適用されます。ただし、「個体」 は、正確な 「集合 （セット）」 になっていない事に注意していて下さい。「個体」 を 「集合 （セット）」 として正確に整えるのは、文脈 （「関係」） が網羅的に検証された後でおこないます。

　2 チャンネル か どこかの wiki で、この 「Ｔ-account」 記法が 「キモい」 と非難されたそうですが （笑）、「Ｔ-account」 は、的確な目的のために使っているのであって、単なる diagramming （構文論を配慮していない画法） といっしょにしないでほしいですね （苦笑）。 □

　



[ 補遺 ] （2013年 7月23日）

　Ｔ之字記法は、「主題と条件」 という言いかたに変えました。 

　　　┌─────────────────┐
　　　│　　　　　　　　　　　　　　　　　│
　　　├────────┬────────┤
　　　│主題　　　　　　│条件1　　　　　 ｜
　　　｜　　　　　　　　｜　・　　　　　　｜
　　　｜　　　　　　　　｜　・　　　　　　｜
　　　｜　　　　　　　　｜　・　　　　　　｜
　　　｜　　　　　　　　｜条件n　　　　　 ｜
　　　│　　　　　　　　│　　　　　　　　│
　　　└────────┴────────┘
　「主題」 は ユーザ が定立した対象でなければならない──「事業」 を分析する限りにおいて、ユーザ が個体指示子を付与している事が要件であって、システム・エンジニア が勝手に 「主題」 を立ててはいけない。「条件」 は、勿論、「空でない」 事を要件としています （値が充足されていなければならない）──モデル 上 （形式上）、null を認めないという事では、TM は 2値論理を前提にしています。勿論、現実には、任意入力が認められているので、null が生ずるのですが、モデル 上、null を認めないと言っているだけで──その技術的対応には、サブセット や 「みなし entity」 を使うのですが──、null をなにがなんでも認めないと言っている訳ではない。

　TM は null が現実に存する事──たとえば、任意入力 （部分関数）──を認めて、それを技術的に どう扱うかを述べています。そして、2値論理を前提にして、モデル 上は null （値をもたない状態） を排除しています。「条件」 の直積で、null を認める場合 [ R (φ,・・・, φ) ] と認めない場合の扱いかたは 1980年代に論じられています。2値論理、3値論理、4値論理のいずれを使ってもよいのですが、モデル であれば、モデル 制作技術は いくつかの前提から推論規則を守って無矛盾性 （妥当な構造） を実現していなければならないことは当然でしょう。ちなみに、リレーショナル・データベース の生みの親たる E.F. Codd 氏は、4値論理を推奨しています。しかし、プロダクト としての リレーショナル・データベース （および、プログラム 言語のほとんど） は 3値論理を前提にしています。3値論理では、null の扱いには注意しなければならない── null は値ではなくて状態なので、その論理否定は （null を否定しても） null です。すなわち、¬ (T, N, F) ≡ (F, N, T)。 ¬ N が 3値論理において どう扱われるかを知らない プログラマ は毛頭いないと私は信じたいのですが、どうも現実はそうではない様です、、、。

　TM の呼称は、当初 Turing Machine をもじって名付けたのですが、最近では 「Theory of Models」 （数学基礎論の一分野、モデル 論） の略だと言っています。
　 << もどる HOME すすむ >>
　 目次にもどる