2006年 7月 1日

応用編-11　対照表と event

>> 目次に もどる

2011年 6月 1日 補遺

　本節に示した 「銀行口座」 の例は、構文論上、正しい。
　しかし、意味論上、正しいかどうか は争点になると思う。

　[ 構成-1 ]

　　｛銀行 コード、名称、・・・｝.

　　｛預金種別 コード、名称、・・・｝.

　　｛口座番号、・・・｝.

　　｛銀行 コード (R)、預金種別 コード (R)｝.

　　｛銀行 コード (R)、預金種 コード (R)、口座番号 (R)、口座名義人、・・・｝.

　
　たとえば、以下を考えてみる。

　[ 構成-2 ]

　　銀行 HDR
　　｛銀行 コード、名称、・・・｝.

　　銀行 DTL
　　｛銀行 コード、口座番号、預金種別 コード、（口座名義人）、残高｝.
　　（注意//→ 「銀行 コード ＋ 口座番号」 が認知番号である。）

　
　意味論上、[ 構成-1 ] は、銀行が管理している構成であり、[ 構成-2 ] が、ユーザ 企業の 「口座」 構成になる。というのは、ユーザ 企業は、たとえば、預金種別の性質や口座番号の性質を管理しない。そして、銀行口座は、「多値の AND」 関係である （言い換えれば、複数の口座が、同時に、並列できる）。

　もし、この前提に立つのであれば、「黒本」 77ページ の データ 構成は、（ユーザ 企業の観点からすれば、） そもそも、起こり得ない構成である。 □

[ 補遺 ] （2011年 6月 1日）

　「黒本」 77ページ の例で示した構造は間違っているということです。申し訳ない。

　「黒本」 を執筆したときには──何を言おうが言い訳になってしまいますが （苦笑）──、いまだ、「構文論」 と 「意味論」 を ごっちゃにしていました。それらを ちゃんと扱えるようになったのは、「論考」 以後です。特に、「意味論」 については、「赤本」 以後に ちゃんと意識できるようになりました。

　本 エッセー で示した [ 構成-1 ] でも システム作りは成功しますが、たとえ実装形が成功したとしても、かならずしも、事業を正確に分析したことにはならないでしょうね。事業を正確に分析しなくても正確なシステムを作ることができるというのでは、エンジニアとして落第でしょう [ まぐれ当たりと言われても反論できないでしょうね、私の ミス です、申し訳ない ]。

<< もどる

HOME

すすむ >>

「Ｔ字形ＥＲ データベース設計技法」を読む