anti-computer

　
　Ｔ字形 ER手法に関して、ウェッブの或るページでは、以下のコメントがされているそうです（小生は、そのページを観ていないのですが、知人が、そのページのなかに綴られていることを教えてくれました）。

　　　　Ｔ字形 ER手法は、「属人性」を排除するといっていながら、最後のほうでは、
　　　　Ｔ字形 ER手法を使うには、ＳＤＩ社のコンサルテーションをうけてねってこと
　　　　ですかね。

　この推測は、おおいなる「的はずれ」です（笑）。
　たとえば、コッド正規形を作成する際、コンサルテーションを依頼することなど、まず、ないでしょう。コッド正規形にしてもＴ字形 ER手法にしても、１日か２日ほどの教育をうければ、実地に使うことができます。モデルというのは、（モデルを作る側の観点から言えば、）理論的に、無矛盾性・完全性を保証して、技術的に、単純性・実効性を実現するような体系になっていますから、わずかの教育をうければ、実地に使うことができる仕組みになっています。

　もし、モデルを初めて使うので、モデルの使いかたや作成されたアウトプットの形式的記述に関して、不安があるようであれば、作成された図に対して、せいぜい、２回ほど、形式的記述のレビュー（検証）をしてもらえば良い、というくらいでしょうね。
　したがって、テーブル設計（ファイル設計）として、Ｔ字形 ER手法を使うなら、コンサルテーションなどいらないでしょう。

　モデルは、以下の２つの観点から検討されます。

　（１）構文論
　（２）意味論

　理論的な無矛盾性が論点になるのは、構文論の領域です。生成規則に従った無矛盾性を実現していないモデルは、「我流」であって、単なる作図作法に過ぎない。単なる作図作法なら、自らの「好み」に合うやりかた（使う記号が少ないとか、見栄えがよいとか）を選べば良いでしょうね。

　生成規則が示されていれば、モデルは、単純な「ルール」として提示することができます。
　たとえば、コッド正規形では、以下の２つの「ルール」を知っていれば良い。

　（１）関数従属性
　　　（テーブルのなかの或る属性値に対して、ほかの属性値が一意になる。）
　（２）包摂従属性
　　　（或るテーブルのキーは、ほかのテーブルのなかにも存在していなければならない。）

　たとえば、Ｔ字形 ER手法では、以下の４つのルールを知っていれば良い。

　（１）「resource と event」の対応関係
　（２）「event と event」の対応関係
　（３）「resource と resource」の対応関係
　（４）「再帰」

　単純なルールを使うために、コンサルテーションなどいらないでしょう（笑）。
　コンサルテーションが中核になる領域は、意味論の領域です。すなわち、構文論を前提にして記述された「構成（形式）」が、現実の世界（事業）と対比されたとき、事業のなかで、いかなる問題点が潜んでいて、どのような改善案を考えることができるか、という点を検討する際に、コンサルテーションが注目される、ということです。

　したがって、意味論を対象にするなら、技術以外の膨大な知識が前提になります。たとえば、会計学・経営学・マーケティング・生産管理などの事業に関する知識を習得していることが、データを解析するための前提になります。さらに、習得している知識を前提にして、問題点を感知して、改善案を提言しなければならない。そういう作業は、（データ設計の技術的な論点を超えて、）コンサルテーションが成立する仕事です。

　Ｔ字形 ER手法の推論ルールどおりに作図すれば、データを単純に整理できて、プログラムのアルゴリズムを I/O 化して（ソース・コードの作成を軽減できて）、システムのメンテナンスが簡易になる、というだけのことです。つまり、効率が向上する、というだけのことです。整理されたデータ構造やステップ数の軽減された--nested-IF の無くなった--プログラム構成が、効果的であるかどうか、という点は、Ｔ字形 ER手法の技術とは、べつの論点です。
　ただし、Ｔ字形 ER手法は、事業を解析できるような技術的な配慮もされているので、事業とデータベース設計との関係を検討する際には、コンサルテーションをうけたほうが良いでしょう、と僕は言っているだけであって、Ｔ字形 ER手法を、テーブル設計技法として使うために、コンサルテーションを導入しなさいと、一切、言っていない。

　Ｔ字形 ER手法は、「事業解析＝データ設計＝アルゴリズムの I/O 化」を同時に実現することを狙って作った技術です。もし、「データ設計＝アルゴリズムの I/O 化」を重視して使うなら、コンサルテーションはいらないでしょうね。ただ、もし、「事業解析＝データ設計」を重視して使うなら、コンサルテーションを導入したほうが良いでしょう。

　Ｔ字形 ER手法は、「事業解析＝データ設計＝アルゴリズムの I/O 化」を同時に実現することを狙って作った技術ですから、 SDLC^（注１）を前提にしていない。Ｔ字形 ER手法は、 RAD^（注２）向きの手法です。Ｔ字形 ER手法をテーブル設計技法として使うなら、 SDLC を前提にしても、役立つでしょう。ただし、 RAD は、そうとうな技術力を体得したプログラマでなければ使いこなすことができないので-- RAD は、だれでも、できるという技術ではないので--、 RAD を前提にして、Ｔ字形 ER手法を使うのであれば、 RAD の専門家たる SWAT チーム^（注３）を導入するのも当然のことでしょう。

　いまどき、データ設計が、単独の論点になる時代ではないでしょう（笑）。
　過去１０年の間、日本の企業は、いわゆる会計ビッグバンと呼ばれる環境変化を経験してきました。会計ビッグバンは、会計数値の測定規準・報告規準が変わったということばかりではなくて、事業のやりかたにも多大な影響を及ぼしています。つまり、「ゲームのルール」が変わった、ということです。
　新しいゲームのルールに対応するために、ゲームのルールが変わる以前に使っていたデータ構造が、今後も、適切なのかどうか、という点を検討する作業は、単なるテーブル設計の域を超える大作業です。

　Ｔ字形 ER手法は、或る目的を実現するために用意された単なる技術です。
　Ｔ字形 ER手法を、単なるテーブル設計技術として使っても良いし、事業の目的に合うようなデータベース構造を考える手段として使っても良し。手順に従えば使うことができる技術なら、技術を使う際、コンサルテーションはいらないけれど、技術を使って、事業を検討するとなれば、コンサルテーションを導入したほうが良い、ということです。
　技術（モデル）を使う際に、コンサルテーションを導入しなければならない、というような未熟な技術を僕は作ったつもりはない（笑）。ただし、事業に役立つように、データベース構造・システム構造を徹底的に検討するなら、コンサルテーションを導入したほうが良いでしょう。

　
　（2004年3月29日）