2001年 4月15日 「備考」 として扱われる identifier >> 目次 (作成日順)
  ● QUESTION   identifier がT字形 ER図の右側 (アトリヒ゛ュート) に記述されることはあるか。
  ▼ ANSWER   ある。 コメント (備考) 扱いとなる。
2006年 5月16日 補遺  


 identifier はT字形ER図の 「左側に」 記述されることが正当な記述である。したがって、identifier を 「右側に」 記述するということは、identifier として扱わないことを宣言している。
 そのような典型的な例としては、以下の 2つの事例がある。

  (1) identifier が管理番号 (認知番号) ではない。
  (2) identifier が管理番号ではあるが、テ゛ータ 構造を生成する コート゛ として使わない。




(1) の具体例 (identifier が コメント 行扱い)

 ┌───────────────────────┐
 │          特約店         R│
 ├───────────┬───────────┤
 │特約店番号      │特約店名称      │
 │           │店番号(R)     │
 │           │           │
 │           │           │
 └───────────┴───────────┘

[ 前提 ]

(1)-1 特約店番号と店番号は同一の店を記述している。
(1)-2 特約店番号は、T字形 ER図を作成している組織が附番している認知番号である。
(1)-3 店番号は、T字形 ER図を作成している組織が附番している番号ではない
    (たとえば、 取引している相手が附番している管理番号である)。
(1)-4 店番号に附属する アトリヒ゛ュート がない。
    したがって、店番号を使って、「店」 を生成する有用性がない
    (「resource」 の有用性がない)。




(2) の具体例 (名称 テーフ゛ル)

 ┌───────────────────────┐
 │          従業員         R│
 ├───────────┬───────────┤
 │従業員番号      │従業員名称      │
 │           │住所コード(R)   │
 │           │番地         │
 │           │           │
 │           │           │
 └───────────┴───────────┘

 ┌───────────────────────┐
 │          住 所         R│
 ├───────────┬───────────┤
 │住所コード      │住所名称       │
 │           │           │
 └───────────┴───────────┘


[ 前提 ]

(2)-1 住所 コート゛ は、住所名称を入手するための コート゛ に過ぎない。
(2)-2 したがって、住所 コート゛ を使って、「住所」 を生成する有用性がない
    (「住所」 を 「resource」 として扱う有用性がない)。



[ 補遺 ] (2006年 5月16日)

 この扱い (認知番号を T-account の右側に記述すること) そのものは、TM (T字形 ER手法) の文法として示されている訳ではない。この エッセー を公にしたあとで、この やりかた を 「認めるべきではない」 という ご意見を 多数 いただきました。私も、いまになって思えば、この エッセー を綴らないほうが良かったと反省しています。というのは、この やりかた を 「乱用」 する人たちが多いそうです。

 この やりかた を認めた理由は、「みずからの (自社の) 管理過程のなかで、コート゛ を付番されていても、管理対象になっていない個体がある」 現象に対応するためでした。その現象の典型的な例が、以下の 2つの現象です。

  (1) 取引先から送付される コート゛
  (2) 名称 テーフ゛ル

 (1) は、たとえば、取引先と取引する際に、取引先が かれらの コート゛ で情報を問い合わせてくるが、かれらの コート゛ は、自社の管理番号ではないという現象です。(2) は、テ゛ータ 入力を省力化するために導入された コート゛ です。いずれの現象も、TM (T字形 ER手法) の文法どおりに、独立した管理番号を付与された対象は、個体 (entity) としても、構文論上、齟齬はないでしょうね。たとえば、上述した 2つの例は、文法どおりに、以下の構造として記述することもできます。

   {特約店番号、特約店名称、...}.
   {店番号}.
   {特約店番号 (R)、店番号 (R)}.

   {従業員番号、従業員名称、...}.
   {住所 コート゛、住所名称、...}.
   {従業員番号 (R)、住所 コート゛ (R)、番地}.

 TM (T字形 ER手法) では、個体 (entity) を、「event と resource」 の 2つに分類しているので、この構造を、意味論上、解釈する際に、以下の疑問が起こります。

  (1) 「店」 を 「resource」 として認知するのか。
  (2) 「住所」 を 「resource」 として認知するのか。

 「resource」 は、その性質として、「event」 に関与しますし、あるいは、「resource」 どうしの 「組」 は--言い換えれば、「resource」 を、2つ以上、組み合わせれば--、なんらかの事態 (「event」) を示します。

 たとえば、{特約店番号 (R)、店番号 (R)} が、どのような事態 (「event」) を示しているのかと問うてみれば、なんら、事業過程の事態を示していないで、コート゛ の 「読み替え (翻訳)」 にすぎない。というのは、特約店番号が指示している外延 (もの-のあつまり) と店番号が指示している外延 (もの-のあつまり) は同一だから。この対照表は、「コート゛ 変換 テーフ゛ル」 として作用しています。しかも、特約店と店が、「1対1」 に対応するのであれば--数学的に言えば、「全射かつ単射」 であれば--、店番号は、alias にすぎない。したがって、取引先が店番号で参照してきても、index-key さえ用意されていれば、対応できる現象です。言い換えれば、意味論的に、「店」 を 「resource」 として認知する有用性はない。

 もう 1つの例である {従業員番号 (R)、住所 コート゛ (R)、番地} は、しかじかの従業員が、しかじかの住所に居住していることを示しています。ただ、{住所 コート゛、住所名称、...} を 「resource」 として認知する意味はない。というのは、住所を、まず、単独に認知して、そして、住所と従業員を対応して、しかじかの従業員が、しかじかの住所に住んでいるという管理をしていないから。{住所 コート゛、住所名称、...} は、名称 テーフ゛ル にすぎない。
 この エッセー に先だって 461ヘ゜ーシ゛ に記載した例を示すべきだったかもしれない。

 この エッセー は、管理番号を意味論の観点から強く適用した例を示したのですが--コート゛ 体系上、独立した管理番号を付与されていても、認知番号としない例を示したのですが--、この措置が 「乱用」 されていることを私は耳にしています。たとえば、TMD (TM Diagram、T字形 ER図) を作成していて、リレーションシッフ゜ が錯綜するので、リレーションシッフ゜ (の線) を省略するために、「認知番号を T-account の右側に記述する」 というように 「乱用」 されていることも私の耳に入っています。そういう使いかたをされたら、TM (T字形 ER手法) の価値が半減してしまいます。というのは、そういう使いかたは、TM を テーフ゛ル 設計としてのみ使っているのであって、TM の特徴である 「『構造』 を作ってから、『意味』 を検証する」 という点 (セマシオロシ゛ー 的なアフ゜ローチ) を無視しているので、TM を (設計手法として使っていても、) 分析手法として使っていないから。

 この エッセー に対して多数の反対意見をいただいたことを鑑みれば、この エッセー は綴るべきではなかったのかもしれない、、、。




  << もどる HOME すすむ >>
  データ解析に関するFAQ