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

 

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

  (1) 情報-仕訳法 (参考)
  (2) 語い-転記法

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

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

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

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

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

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

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

 



[ 補遺 ] (2010年10月16日)

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

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

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

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

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

 「T字形 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 すすむ >>
  「T字形ER データベース設計技法」を読む