2004年 2月16日 作成 データ 設計技法 （チェン、コッド、ワーニエ） >> 目次 （テーマ ごと）
2008年 3月16日 補遺 　


　
　いわゆる 「基幹系の システム」 を対象にすれば、システム 作り （データベース 作りおよび プログラム 作成） の手法として、1970年以後 （今に至るまで）、以下の 3人が多大な影響を与えたことは確かである。

　（1） チェン （Chen P.）
　（2） コッド （Codd E.F.）
　（3） ワーニエ （Warnier J.D.)

　
　チェン 氏が提示した ER （Entity-Relationship） 手法は、概念設計の段階で使われ、データベース 化の対象を 「モノ」 として考えて、「モノ」 の構造を、主体 （entity） と [ 主体の間に成立する ] 関連 （relationship） として記述する手法である。

　コッド 氏が提示した セット・アット・ア・タイム 法は、設計段階で （データベース の物理設計手法として） 使われ、（主体集合は、すでに、記号化されているという前提に立って、） 属性集合を対象にして、属性集合のなかから、1つずつ データ を選んできて、関数的依存関係 を前提にした タプル （tuple） を生成する手法である。

　ワーニエ 氏が提示した、いわゆる 「ワーニエ・メソッド」 は、設計段階で （プログラム 構造の設計手法として） 使われ、インプット の データ 構造を前提にして、「反復と選択」 の アルゴリズム を構成する手法である。したがって、インプット の対象となる情報のなかに、いくつかの キー （主体集合） があれば、複合 キー 構成になった indexing を前提にした レコード・アット・ア・タイム 法である。

　
　さて、上述した 3つの手法の間には、以下の関係が成立する。

　（1） チェン ER と コッド 正規形 の関係
　（2） コッド 正規形 と ワーニエ・メソッド の関係

　（1） も （2） も、それぞれの手法が提示した目的・前提とは懸け離れた関係が起こってしまった。

　まず、チェン ER と コッド 正規形との関係のなかで起こった間違いは、コッド 正規形を チェン ER を使って記述してしまった、という点である。それぞれの手法の目的を正当に判断すれば、チェン ER を作図してから コッド 正規形を作るというのが正しい。ただし、チェン ER の entity は、かならずしも、コッド 正規形の テーブル には対応しないので、チェン ER から コッド 正規形への 「翻訳」 は、意外に、むずかしい。

　次ぎに、コッド 正規形と ワーニエ・メソッド との関係のなかで起こった間違いは、（プロダクト としての） RDB が （パージョンアップ のなかで） indexing を搭載したので、セット・アット・ア・タイム 法が、レコード・アット・ア・タイム 法として使われてしまった、という点である。そして、SQL が、（バージョンアップ のなかで） 「反復と選択」 の シンタックス を導入したので、セット・アット・ア・タイム 法を前提にした テーブル に対して、レコード・アット・ア・タイム 法の ワーニエ・メソッド を適用してしまった、という点である。

　
　チェン ER と コッド 正規形と ワーニエ・メソッド が提示した目的を理解して、システム 作りを、できるかぎり、単純にして整合性を実現するためには、以下の 2点を考えなければならない。

　（1） 事業の構造 （「モノ と関係」 を使って記述された構造） を、データベース の正規形として作る。
　　　　（概念設計と論理設計の統合）
　（2） レコード・アット・ア・タイム 法を使って、論理 ビュー を実現する。
　　　　（セット・アット・ア・タイム 法と レコード・アット・ア・タイム 法の統合）

　小生は、その やりかた の 1つとして、Ｔ字形 ER手法と INDEX-only を提示した。
　ほかの やりかた も作ることができると思うので、考えてみてほしい。



[ 補遺 ] （2008年 3月16日）

　本 エッセー で言及した 3人の説を学習には、まず、以下の文献を読んで下さい。

　（1） ワーニエ・プログラミング法則集、J. D. ワーニエ 著、鈴木君子 訳、日本能率協会.
　（2） "Relational Model for Large Data Banks", Codd E.F., CACM, Vol. 13 No. 6.
　（3） "The Entity-Relationship Model: Toward a Unified View of Data", ACM TOD, Vol. 1 No. 1.

　私は、20歳代後半、アーサー・アンダーセン に入社して、ワーニエ・メソッド を指導され──当時、アンダーセン の コンサルティング 部 （現、アクセンチュア 社） は、「Method-1」 という システム作りの独自の メソドロジー をもっていて──、「Method-1」 のなかで、ワーニエ・オワ （Warnier/Orr） 法を使っていました。ワーニエ・オワ 法は、J.D. Warnier 氏が作って、Ken Orr 氏が補足した 「構造化」 手法です。当時、アンダーセン では、プログラム の スペック を ワーニエ・オワ 法で記述することになっていました。私は、当時、プログラマ だったので──下手な プログラマ でしたが（笑）──、ワーニエ の構造的 プログラミング を遵守していました。当時は 1970年代の後半だったので、われわれは、日本で、ワーニエ・メソッド の 「第一期生」 でした。ただ、遺憾ながら、私は、当時、構造化手法を まじめに学習しなかった。私が、ワーニエ・メソッド を丁寧に学習したのは、アンダーセン を退社して、アシスト 社に入社してからでした。

　私の そもそもの専門領域は、会計学 （財務会計論） と生産管理 （MRP Ⅱ） だったのですが、なにかの 「時代のいたずら」 で、アシスト 社に入社してから、リレーショナル・データベース を日本に導入・普及する役目を担うことになりました──当時、日本では、RDB が、いまだ、使われていなかった。私は、RDB に関して、当初、DBA を担当していたのですが、データ 設計法を普及するために、DA の仕事に転職することになって、コッド 関係 モデル （実際には、コッド 関係 モデル を簡便化した正規化手続き） と チェン ER 手法を日本に普及する役割を果たすことになりました。そして、私は、当時、本 エッセー のなかで述べた間違い （コッド 正規形を チェン ER図で描くこと） を日本中にまき散らしてしまいました、、、（懺悔）。

　私は、本 ホームページ のあちこちで公言しているように、コッド 関係 モデル 派です。私の作った データ 設計法が、当初、「Ｔ字形 ER手法」 というよびかたをしたので、まるで、チェン ER手法の仲間のように、世間では、見られているようですが、私は、チェン ER手法を、全然、信用していない。さらに、「Ｔ字形 ER手法」 は、当初 （1990年頃）、データ 設計法として生まれたのですが──コッド 関係 モデル を実地の仕事で使いやすいようにするために作ったのですが──、2000年頃から、コッド 関係 モデル を 「意味論」 として使うようにするために、「論理的意味論」 の性質を強めてきました。そのために、「Ｔ字形 ER手法」 というよびかたがふさわしくないので、2005年に、「TM （Ｔ字形 ER手法の改良版）」 というよびかたに変えました。

　1980年代から、システム 作りのやりかたとして、ウォーターフォール (waterfall） 型 （分析 → 設計 → 製造 → 保守） が使われてきたのですが、システム 作りのなかで、私が一貫して狙っていた点は、「分析」 と 「設計」 の乖離を根絶することでした。その乖離を根絶するためには、設計法は、「モデル」 として、以下の 2点を実現していなければならない。

　（1） 「構成」 を作るための生成規則をもっている （構文論の観点）
　（2） モデル のなかの 「項 （個体）」 と現実的事態には指示関係がある （意味論の観点）

　この 2点を実現するためには、モデル は、当然ながら、「論理的意味論」 となります。

　モデル （あるいは、アルゴリズム） は、そもそも、いわゆる 「数学基礎論」 から生まれました。
　ワーニエ・メソッド や コッド 関係 モデル を学習すると同時に──それらの モデル は、数学の集合論を前提にしているので──、「数学基礎論」 を学習して下さい。こういう基本的な数学技術を習得していないと、モデル を単なる 「画法」 と思い違いしてしまうので。チェン ER 手法など、「画法」 にすぎない、と判断して宜しい。




　 << もどる ベーシックス すすむ >>
　 ▼ データベースの基礎知識