|
2005年 4月 1日 |
基準編-1 「Ｔ字形 ER手法」 の位置づけ |
|
|
2010年 3月 1日 補遺 |
|
|
|
（1）
「event」
概念 （1）
「resource」
と 「resource」 （1）
「resource」
概念と 「event」
概念を マスター・ファイル と トランザクション・ファイル
としている。 （2） 対応表 （on-to mapping） と再帰 （recursive） を記述していない。 （3） タイプ （type） とセット （set） の違いを理解していない。 コッド 正規形が、「意味」 を制約条件として記述したことに対して、小生は、不満を感じていたので、データ 正規形を作る時点で、意味論（semantics）──「event および resource」 という指示関係──を導入したが、Ｔ字形 ER手法は、いまだ、データ 設計法としての性質が強かった。ただ、当時、小生が、ひたすら、狙っていた点は、SE の恣意性 （恣意的な認識） を排除することだった。Entity を認知するために、コード 体系を使った時点で、（事業過程そのものを対象にしないで、） 管理過程を対象にして、「情報」 のなかで、ことば が、いかに使われているか、という点を重視していたので、ウィトゲンシュタイン 氏の 「論理哲学論考」 を底本にして、Ｔ字形 ER手法を作ったが、いまだ、データ 設計法として、コッド 関係 モデル の影響のほうが強かった。 システム
作りとして、waterfall
モデル
を信用していない小生は、RAD
（Rapid
Application Development）を、1980年代後半から使っていた。そして、RAD
とＴ字形
ER手法は、それぞれ、相互作用を及ぼしながら、改良されてきた。 SDI/RAD
は、百万
ステップ くらいの システム であれば、10数名──DA、DBA
および
SWAT
チーム
の合計人数──が、6ヶ月以内に導入することを実績値として示してきた。この生産性を実現するためには、SDLC
の上流工程
（分析工程と設計工程）
が、2ヶ月くらい──最悪でも、3ヶ月ほど──で完了しなければならない。したがって、工程を短縮するためには、1つの手法を使って、（事業の）
管理過程の記述と データ 設計を、同時に実現しなければならなかった。 Ｔ字形 ER手法と SDI/RAD の相互作用 （関係） を、基準編-1 として、まとめた。 □
|
|
[ 補遺 ] （2010年 3月 1日） Ｔ字形 ER手法 （TM の前身） と RAD （今風に謂えば、Agile） の どちらが先に生まれたのかを私自身の記憶をたぐってみて ハッキリ と断言することができない──たぶん、ふたつは、相乗作用のなかで整えられてきたのだと思います。敢えて謂えば、RAD のほうが先だったと思います。というのは、RAD は、1980年代後半に 「原型」 を考えていて、Ｔ字形 ER 手法のほうは、私が独立開業したあとで [ 1990年代初頭に ] 整え始めたので。RAD を実施していた頃にも 「Ｔ之字」 の記法を使っていましたが、コッド 正規形を作るための仕訳帳であって──私の恩師 Eric Vesely 氏から習った やりかた であって [ 本 ホームページ 「黒本を読む」 基準編-5 参照 ]──、Ｔ字形 ER手法の特徴点になっている 「関係文法」 は いまだ提示されていなかった。つまり、当時、私の最大関心事は、RAD [ 具体的には、本 エッセー のなかで記したように、百万 ステップ 規模の システム を 10数名の プロジェクト 構成で 6ヶ月以内に導入すること ] にあったと推測していいでしょうね。 1980年代後半、コンピュータ 業界では、「生産性向上」 が テーマ になっていました。そして、当時、「SDLC （System Development Life Cycle） の全工程 （分析・設計・製造・保守） を自動化する」 ことを狙って CASE （Computer-Aided Software Engineering） ツール が マーケット に多数投入されました。私の処女作は、1989年に出版した 「CASE ツール 入門解説」 でした。ただし、私は、SDLC で使われている構造化手法を自動化しても さして生産性が向上するとは思っていなかったので、構造化手法の自動化とは違う やりかた を考えていて、CASE ツール のなかで、プロトタイプ （prototyping） を front-end にした ツール を使って システム を作って生産性を向上していました──当時、RAD という ことば を使ってはいなかった。RAD という ことば を使うようになった理由は、私が American Airline 社といっしょに講演した以後です。当時、American Airline 社が日本で講演をするので、私が前座でしゃべったのですが、かれらの やりかた が私の やりかた に似ていたので、かれらが使っていた ことば を借用した次第です。 当時、プロトタイプ で screen-painting した項目を対象にして、Ｔ之字の仕訳帳──上述した コッド 正規形を作るための仕訳帳──を使っていました。ただ、この時点で、私は、コッド 正規形の 「意味論」 が弱いことを実地の システム 作りで痛感していて、なんとか コッド 関係 モデル に対して 「意味論」 を補強したいと考えていました。この時点を Ｔ字形 ER手法の 「着想」 が生まれたときだとすれば、RAD とＴ字形 ER手法は、ほぼ、同じ時期に生まれたということになります。 RAD を実現するためには、本 エッセー のなかで綴りましたが、分析・設計は 2ヶ月 （あるいは、3ヶ月） で終わらなければならない。とすれば、分析と設計をべつべつに実施している時間的余裕はないので、分析と設計の二つを一つの モデル で同時に実現しなければならない。それがＴ字形 ER手法が出てくる要請だったと云っていいでしょうね。 Ｔ字形 ER手法を 「それなりの形で」──すなわち、「関係文法」 を明示した形で──示した著作が 「クライアント/サーバ データベース 設計 テクニック」 （1993年出版） だったと記憶しています。すなわち、この時点で、「event と resource」 という概念を導入して、以下の 「関係文法」 を公にしました。 （1）
「event-対-event」
の関係文法 これらの文法を作るときに、私は、「直積集合」 に そうとうに悩まされていました。「直積集合」 を使った 「関係」 の一般式は、以下のとおりです。 R { s1 ∈ X1, s2 ∈ X2, ・・・, sn ∈ Xn ∧ P (s1, s2, ・・・, sn }. この一般式においては、「項」 は あくまで 「項」 であって、「event」 だの 「resource」 だのという 「意味論」 を混入してはいけない。もし、「event と resource」 という概念を導入するのであれば、そして、それを なんらかの有向 グラフ として図にするのであれば、それぞれの 「項」 のあいだで 「対応表」 を作ればいい、と私は当初思っていたのですが──すなわち、「event-対-event」 において 「対応表」 を作り、「resource-対-resource」 において 「対応表」 を作り、「event-対-resource」 において 「対応表」 を作ればいいと思っていたのですが──、そういう やりかた （対応表） では、「事態」 の構成を形式化できない。たとえば、以下を考えてみます。 { 受注番号、顧客番号、商品番号、受注日、受注数 }. この構成を、もし、上述した 「対応表」 で記述すれば以下のようになるでしょう。 { 受注番号、受注日、受注数 }. { 顧客番号、顧客名称 }. { 商品番号、商品名称 }. { 受注番号、顧客番号 }. { 受注番号、商品番号 }. { 顧客番号、商品番号 }. この構成だと、「受注」 という 「事態」 が形式的に構成されていないので、現実的事態と モデル との指示関係 （意味論） が かえって逸脱してしまう。 Ｔ字形 ER手法の 「関係文法」──そして、それは、TM に そのまま継承されましたが──が整えられたのは、（「クライアント/サーバ データベース 設計 テクニック」 を執筆した以前で、） データベース 設計法の講師をしたとき、ハンドアウト に記されたのが最初だったと記憶しています。ハンドアウト を作成する数日前まで、「関係文法」 は、上述したように、すべての 「項」 （entity） のあいだで 「対応表」 を構成するという やりかた を考えていました──すなわち、「構成」 は、すべて、「対応表」 で記す [ ふたつの集合のあいだの写像を 「対応表」 で記す ]、と。そして、ハンドアウト を作成している最中に、「関係文法」 は、今の形として整えられました。もし、「対応表を使った構成法」 を 当時 公表していたら、、、と想像すると冷や汗が出ます──というのは、その やりかた には、なんら、理論的な妥当性がないので。 「event と resource」 という考えかたは、そもそも、項の 「並び」 を意識して導入されたので、全順序を示す 「event」 どうしの関係と半順序を示す 「resource」 どうしの関係を文法として構成するのは難しくなかったのですが、最大の論点になったのが、「event-対-resource」 の関係でした。当時から、私は、意味論上、「事態 （event）」 が事業を構成しているという考えかたを モデル の中核に置いていたので [ それは ウィトゲンシュタイン 氏の 「論理哲学論考」 からの影響でしたが ]──しかし、当時、「event」 を定義していなかったのですが──、たとえば、上述した 「受注」 の例でいえば、以下の構成を説明できる文法 （証明） を考えなければならないと思っていました。 { 受注番号、顧客番号 （R）、商品番号 (R)、受注日、受注数 }. ここで （R） は 「関与」 を示しているのですが、当時、本 エッセー で述べたように、いまだ、コッド 正規形の考えかたを継承していて、「外来 キー （あるいは、参照 キー）」 というふうに考えていました。この正規形を前提にして、「resource の identifier が event のほうに挿入される」 という文法にしていた次第です──したがって、当時、（R） に関して、理論的な証明は一切されていない。しかし、一見常識に思われる この考えかた [ resource の identifier が event のほうに挿入される、ということ ] が、その後、私を 10数年苦しめることになったのです。というのは、その構成が理論的に妥当であるという証明を考えなければならなかったので。 TM （Ｔ字形 ER手法の改良版） では、「関係文法」 は以下のように まとめられています──ただし、ここでは、「多値」 の論点を除いておきます。 （1）
「event-対-event」
の並びは、全順序 （先行・後続 関係） である。 （2）
「resource-対-resource」
の並びは、半順序である。 （3）
「event-対-resource」
の関係では、以下の規約を使う。 （4） ひとつの集合のなかの メンバー を並べる （再帰） ただし、（3） は、哲学的 ソリューション であって、数学的 ソリューション ではない点に注意してください。この点は、関係主義と実体主義とのはざまで グレーゾーン になっている点です──私の観る限りでは、この点に言及している数学者・哲学者は [ 関係主義の立場にいて、かつ、実体主義的な視点を持っている数学者・哲学者は ] ホワイトヘッド 氏と パース 氏だと思います。そして、私は、かれらの説を TM で借用しました。 |
|
|
|||
|
|
|||