| 2001年 4月15日 | 「備考」 として扱われる identifier | >> 目次 （テーマごと） |
| ● QUESTION | identifier がＴ字形 ER図の右側 （アトリヒ゛ュート） に記述されることはあるか。 | |
| ▼ ANSWER | ある。 コメント （備考） 扱いとなる。 | |
| 2006年 5月16日 補遺 | ||
|
identifier はＴ字形ＥＲ図の 「左側に」 記述されることが正当な記述である。したがって、identifier を 「右側に」 記述するということは、identifier として扱わないことを宣言している。
（1） identifier が管理番号 （認知番号） ではない。 |
|
（1） の具体例 （identifier が コメント 行扱い）
┌───────────────────────┐ │ 特約店 Ｒ│ ├───────────┬───────────┤ │特約店番号 │特約店名称 │ │ │店番号（Ｒ） │ │ │ │ │ │ │ └───────────┴───────────┘ |
|
[ 前提 ]
(1)-1 特約店番号と店番号は同一の店を記述している。 |
|
（2） の具体例 （名称 テーフ゛ル）
┌───────────────────────┐ │ 従業員 Ｒ│ ├───────────┬───────────┤ │従業員番号 │従業員名称 │ │ │住所コード（Ｒ） │ │ │番地 │ │ │ │ │ │ │ └───────────┴───────────┘ ┌───────────────────────┐ │ 住 所 Ｒ│ ├───────────┬───────────┤ │住所コード │住所名称 │ │ │ │ └───────────┴───────────┘ |
|
[ 前提 ]
(2)-1 住所 コート゛ は、住所名称を入手するための コート゛ に過ぎない。 |
|
[ 補遺 ] （2006年 5月16日）
この扱い （認知番号を T-account の右側に記述すること） そのものは、TM （Ｔ字形 ER手法） の文法として示されている訳ではない。この エッセー を公にしたあとで、この やりかた を 「認めるべきではない」 という ご意見を 多数 いただきました。私も、いまになって思えば、この エッセー を綴らないほうが良かったと反省しています。というのは、この やりかた を 「乱用」 する人たちが多いそうです。 この やりかた を認めた理由は、「みずからの （自社の） 管理過程のなかで、コート゛ を付番されていても、管理対象になっていない個体がある」 現象に対応するためでした。その現象の典型的な例が、以下の 2つの現象です。
（1） 取引先から送付される コート゛ （1） は、たとえば、取引先と取引する際に、取引先が かれらの コート゛ で情報を問い合わせてくるが、かれらの コート゛ は、自社の管理番号ではないという現象です。（2） は、テ゛ータ 入力を省力化するために導入された コート゛ です。いずれの現象も、TM （Ｔ字形 ER手法） の文法どおりに、独立した管理番号を付与された対象は、個体 （entity） としても、構文論上、齟齬はないでしょうね。たとえば、上述した 2つの例は、文法どおりに、以下の構造として記述することもできます。
｛特約店番号、特約店名称、...｝.
｛従業員番号、従業員名称、...｝. TM （Ｔ字形 ER手法） では、個体 （entity） を、「event と resource」 の 2つに分類しているので、この構造を、意味論上、解釈する際に、以下の疑問が起こります。
（1） 「店」 を 「resource」 として認知するのか。 「resource」 は、その性質として、「event」 に関与しますし、あるいは、「resource」 どうしの 「組」 は--言い換えれば、「resource」 を、2つ以上、組み合わせれば--、なんらかの事態 （「event」） を示します。 たとえば、｛特約店番号 (R)、店番号 (R)｝ が、どのような事態 （「event」） を示しているのかと問うてみれば、なんら、事業過程の事態を示していないで、コート゛ の 「読み替え （翻訳）」 にすぎない。というのは、特約店番号が指示している外延 （もの-のあつまり） と店番号が指示している外延 （もの-のあつまり） は同一だから。この対照表は、「コート゛ 変換 テーフ゛ル」 として作用しています。しかも、特約店と店が、「１対１」 に対応するのであれば--数学的に言えば、「全射かつ単射」 であれば--、店番号は、alias にすぎない。したがって、取引先が店番号で参照してきても、index-key さえ用意されていれば、対応できる現象です。言い換えれば、意味論的に、「店」 を 「resource」 として認知する有用性はない。
もう 1つの例である ｛従業員番号 (R)、住所 コート゛ (R)、番地｝ は、しかじかの従業員が、しかじかの住所に居住していることを示しています。ただ、｛住所 コート゛、住所名称、...｝ を 「resource」 として認知する意味はない。というのは、住所を、まず、単独に認知して、そして、住所と従業員を対応して、しかじかの従業員が、しかじかの住所に住んでいるという管理をしていないから。｛住所 コート゛、住所名称、...｝ は、名称 テーフ゛ル にすぎない。 この エッセー は、管理番号を意味論の観点から強く適用した例を示したのですが--コート゛ 体系上、独立した管理番号を付与されていても、認知番号としない例を示したのですが--、この措置が 「乱用」 されていることを私は耳にしています。たとえば、TMD （TM Diagram、Ｔ字形 ER図） を作成していて、リレーションシッフ゜ が錯綜するので、リレーションシッフ゜ （の線） を省略するために、「認知番号を T-account の右側に記述する」 というように 「乱用」 されていることも私の耳に入っています。そういう使いかたをされたら、TM （Ｔ字形 ER手法） の価値が半減してしまいます。というのは、そういう使いかたは、TM を テーフ゛ル 設計としてのみ使っているのであって、TM の特徴である 「『構造』 を作ってから、『意味』 を検証する」 という点 （セマシオロシ゛ー 的なアフ゜ローチ） を無視しているので、TM を （設計手法として使っていても、） 分析手法として使っていないから。 この エッセー に対して多数の反対意見をいただいたことを鑑みれば、この エッセー は綴るべきではなかったのかもしれない、、、。 |
| << もどる | HOME | すすむ >> | |
| データ解析に関するＦＡＱ | |||