sdi - Page: blackbook-17

2005年11月16日	基準編-16　「Ｔ字形 ER図」の作成手順	>> 目次にもどる
2010年10月16日補遺

　

　Ｔ字形 ER図を作成するやりかたには、以下の 2つがあります。

　　（1）情報-仕訳法 ^（参考）
　　（2）語い-転記法

　
　情報-仕訳法というのは、1つの「情報」を単位にして、認知番号とアトリビュートを仕訳するやりかたです。語い-転記法とは、認知番号およびアトリビュートを、個々に、対象とするやりかたです。

　「黒本」では、語い-転記法しか述べていない。
　情報-仕訳法は、「論考」のなかで、はじめて述べられた。

　43ページの図「作成手順」は、読み返してみて、上手にまとめている、と思う──自画自賛です（笑）。
　ただ、「event」を判断するために、「...する」という動詞形の簡易判断法を使っているのは、まずい、と思う。その点を除けば、語い-転記法として、いまでも、使っている手順である。「Event」である、ということは、「日付の帰属性」にある。

　語い-転記法は、「データ項目の意味を（或る程度）知っている」人たち向け──すなわち、自社の DA 向け──のやりかたであって、ソフトウェアハウスの DA が使うには、データ項目（の意味）を初見で理解しなければならないので、難しいかもしれない。初見であっても、データ項目の意味を、文脈のなかで判断しやすいようにしたやりかたが、情報-仕訳法である。

　情報-仕訳法と語い-転記法を使用比率で対比してみれば、──正確な統計を取っていないので、推測で言うのは危険なのだが──、たぶん、情報-仕訳法が 3割くらいで、語い-転記法が 7割くらいではないか、と推測される。私は、最近（2000年以後）、（語い-転記法ではなくて、）情報-仕訳法を指導している。その理由は、作成が簡単である（効率的である）から。そして、情報-仕訳法を最初に学習しても、（自社の DA あるいはエンドユーザであれば、データ項目の意味を知っているので、個々のデータ項目を対象にした）語い-転記法のほうに、次第に、そして、自然に移っていきます。

　情報-仕訳法であれ、語い-転記法であれ、最終アウトプットは、当然ながら、同じです。

　
（参考）
「情報-仕訳法」は、いままで、命題論理方式と云っていたやりかたで、「語い-転記法」はコード体系方式と云っていたやりかたです。 □

[ 補遺 ] （2010年10月16日）

　「Ｔ字形 ER 手法」を「TM 」に変えて以後 [ 2005 年以後 ]、「TM 」の技術を説明する際に、私は（本エッセーのなかで述べている）「情報-仕訳法」しか説明しないようになりました。というのは、「情報-仕訳法」のほうが、entity 生成の技術を説明しやすいので。ちなみに、「情報-仕訳法」では、「（語彙の）仕訳」および「（語彙の）元帳への転記」という用語を使っていて、「元帳」──すなわち、個体指定子ごとに語彙を分類記載した帳簿──を entity というふうに説明しています。
　「情報-仕訳法」のみを説明しても、本エッセーのなかで述べているように、TM を実地に使って、TM の技術に慣れれば、「語彙-転記法」を次第に [ 自然と ] 使うようになるようです。

　「黒本」基準編-16 の記述のなかで私が後悔している点は、entity を「event と resource」というそれぞれのクラスに分類するときに、「『...する』という動詞を使えばいい」というふうに説明した点です。というのは、「黒本」の出版後、2 チャンネルで、「Ｔ字形 ER手法」の非難が書き込まれたそうで、「...する」という動詞形の判断は、「Ｔ字形 ER手法の独自なやりかたではなくて、動詞形・名詞形を使うやりかたは昔からあった」という書き込みがあるそうです。私は、「『...する』という動詞形を使えばいい」というふうに綴ったときに、entity の分類規準にするなどと（あるいは、「event」の定義にするなどと）重々しく考えていたのはなくて、せいぜい、簡便法として使えばいいとしか思っていなかったし──基準編-16 のなかでも、「簡便法」だと綴っていますし──、「time-stamp」が「event」の特徴点であることを明らかにしています。そういう非難をしたひとは、たぶん、基準編-16 を実際に読んでいないのではないかしら。

　たとえば、以下の entity を考えてみます。

　　　　{ 分類コード、分類名称 }.

　この entity （「分類」）は、たとえ、「...する」という動詞形を付与して単語として意味が通じても──すなわち、「分類する」という単語として考えても──、「event」ではなくて「resource」です。なぜなら、「日付（たとえば、分類日）」が存在しないので。言い換えれば、「分類する」という行為・出来事ではない、ということ。「...する」という動詞形は、あくまで「簡便法」であって正式な定義ではない。逆に言えば、動詞形・名詞形などということを論点にしているようなやりかたは怪しい、ということ──「動詞形・名詞形というやりかたは昔からあった」と 2 チャンネルに書き込んだひとは、いったい、どういうやりかたを参考にしていたのかしら。

　「Ｔ字形 ER手法」（および、TM）では、「event」であるどうかを判断するために「日付」の帰属性を問うことにしているのですが、2 チャンネルで、それに対しても非難が書き込まれたそうです（笑、そして苦笑）──「すべてのデータには日付が付与される」という非難だそうですが、「データに付与される日付は、データの登録日・更新日 [ IRM 上の日付 ] 」であって、事業過程で起こった経済行為の日付 [ 取引日 ] ではないことぐらいわかるでしょうに。2 チャンネルに批評を書き込んでいる人たちは、批評対象をちゃんと調べないで批評したがる族のようですね。

　本エッセーのなかで「作成手順」を上手にまとめていると自画自賛していますが、今の時点から振り返って観れば、そのまとめは、とても拙い（苦笑）。「作成手順」は、現時点（2010 年10 月）で──今後、更なる改良を施すかもしれないのですが──、以下の 5 つのワークフローとして整えられています。

　（1）個体（entity）を構成する。
　　　（情報の仕訳、語彙の転記）
　　　　　　　　　　↓
　（2）個体（entity）を仕訳する。
　　　（「event と resource」の分類）
　　　　　　　　　　↓
　（3）関係（relation）を構成する。
　　　（4つの関係文法）
　　　　　　　　　　↓
　（4）個体が集合（set）として正しいか調べる[ 集合を整える]。
　　　（サブセット、多値）
　　　　　　　　　　↓
　（5）個体が「事実」として正しいか調べる[ F-真を整える]。
　　　（みなし entity、クラス）

　（1）から（4）は、「構文論」の考慮点で、（5）は「意味論」の考慮点です。

	<< もどる	HOME	すすむ >>
	「Ｔ字形ＥＲデータベース設計技法」を読む