2003年 2月 1日 取引先が送ってくる コード >> 目次 (作成日順)
  ● QUESTION   取引先が送ってくる コード は identifier として扱うのか。
  ▼ ANSWER   identifier として扱うこともあれば、そうでないこともある。
2008年 2月16日 補遺  



 以下を例にして考えてみる。

 (1) A 社と B 社が取引をしている。B 社は A 社の関連企業である。
 (2) A 社は B 社に受注する。(受注番号が identifier である。)
 (3) A 社の受注 データ のなかで、営業所 コード が使われている。
   ただし、営業所 コード は A 社が使っている コード であって、B 社では独自の店番号を使っている。
 (4) B 社の店番号とA 社の営業所 コード には、「1-対-1」 の対応関係が成立している。
 (5) A 社が B 社に対して受注を照会するときには営業所 コード を使っている。

 さて、B 社用のT字形 ER図を作成してみる。

 営業所 コード の扱いは以下の 2つを考えることができる。

 (1) 営業所 コード を identifier として扱う。
 (2) 営業所 コード を identifier として扱わない。

 したがって、営業所 コード は、技術的には、以下の 3つとして扱うことができる。

 (1) identifier
 (2) アトリビュート
 (3) VE

 
1. 営業所 コード を identifier として扱う

 営業所 コード を identifier として扱えば、営業所 entity が生成される。
 営業所 entity と店 entity の間に対照表を生成して、対照表を 「コード 変換 テーブル」 として使う。

  受注 [ E ]
  { 受注番号、取引先 コード (R)、営業所 コード (R)、 受注日、受注数 }.

  営業所 [ R ]
  { 営業所 コード }.

  店 [ R ]
  { 店番号、 店名称 }.

  営業所. 店. 対照表:
  { 営業所 コード (R)、店番号 (R) }.

 
2. 営業所 コード を identifier として扱わない (アトリビュート として扱う)

 営業所 コード を identifier として扱わないで、 店 entity のなかの アトリビュート として扱う。
 営業所 コード は B 社の コード ではないので、B 社には営業所 コード に対する保守責任はない。
 したがって、営業所 コード を店番号に対する 「備考 (コメント 行)」 として扱う。
 そして、A 社からの問い合わせに対応するために──「コード 変換」 のために──、店 entity に対して、「営業所 コード + 店番号」 の インデックス を用意する。

  受注 [ E ]
  { 受注番号、取引先 コード (R)、営業所 コード (R)、 受注日、受注数 }.

  店 [ R ]
  { 店番号、店名称、営業所 コード (D) }.

 
3. 営業所 コード を identifier として扱わない (VE として扱う)

 営業所 コード が B 社の コード ではないことを明示するのなら、営業所 コード を VE として扱う。

  受注 [ E ]
  { 受注番号、取引先コード (R)、営業所 コード (R)、受注日、受注数 }.

  店 [ R ]
  { 店番号、 店名称 }.

  店. 営業所 [ VE ]
  { 店番号 (R)、営業所 コード (D) }.

 したがって、VE を コード 変換 テーブル として使うことができる。

 
4. identifier・アトリビュート・VE の相違点

 営業所 コード を identifier として使えば、「明示的に (explicitly)」 コード 変換 テーブル を対照表の形として生成することができる。ただ、論点になるのは、営業所 entity が B 社にとって保守責任があるのかどうかという点である。言い換えれば、B 社が営業所 entity を 「resource」 として管理するなら、アトリビュート として、なにを管理するのか、という点が論点になる。営業所 entity は単なる名称 テーブル に過ぎないのではないか、という点が論点になる。
 もし、名称 テーブル に過ぎないのなら、リレーションシップ は生成されないし、対照表も生成されない。
 ただし、B 社が A 社の関連企業であり、A 社の営業所を 「意識的に」 認知しているとすれば、営業所 entity は 「resource」 として成立する。

 営業所 コード を (店 entity の) アトリビュート にすれば、営業所 コード が 「備考」 扱いとなるが、コード 変換 テーブル を 「明示的に」 生成することができない。言い換えれば、営業所 コード は、あくまで、A 社の コード 体系であって、A 社から問い合わせがあれば参照できればよい──参照用の インデックス を用意しておけばよい──、という考えかたである。B 社は A 社の関連会社ではあるが、あくまで、独立した法人であるという意識が強い考えかたである。

 営業所 コード を VE 扱いにすれば、営業所 コード を店 entity から切り離して──B 社の データ 構造のなかでは A 社の営業所を排除して──、いっぽうでは、コード 変換 テーブル を用意するという考えかたである。 3つの やりかた のなかでは、B 社の独立性が一番強い考えかたである。

 以上の考えかたを参照して判断されたい。

 



[ 補遺 ] (2008年 2月16日)

 TM 上、「entity」 は、T之字で記述されますが、T之字は、以下を記すために導入されました。

             ┌─────────────────┐
             │      entity 名称      │
             ├────────┬────────┤
             │identifier   │性質(観察述語)│
             │        │        │
             │        │        │
             └────────┴────────┘

 T之字記法では、認知された 「entity」 に対して、どのような 「性質 (データ 項目)」 を管理対象として記録しているのか が、つねに問われます。言い換えれば、identifier を付与された 「entity」 の定義が 「性質」 として記述されるということです──あるいは、述語論理・集合論の観点に立って、しかじかの 「性質」 をもった対象として、かくかくの 「entity」 を定立している、というふうに 「解釈」 しても良いでしょうね (ただし、そういう 「解釈」 を TM は生成規則としている訳ではない点に注意して下さい)。いずれにしても、T之字では、「性質」 が、一切、記述されないという事態は、基本的に、「格外 (正常ではない)」 ということです。
 あるいは、もし、「entity」 が 「resource」 であれば、その 「性質」 として 「名称」 しか記録されていないという事態も、好ましい事態ではないでしょうね──というのは、「resource」 が (文字入力を省力するための) 単なる 「名称 ファイル」 にすぎないかもしれないから。

 本 エッセー で述べた 「取引先が送ってくる コード」 は、まさに、この事態でしょう。A 社が送ってくる 営業所 コード と B 社で使っている店番号との対応は、「全単射」 です──それらの すべての データ が、かならず、1-対-1 に対応します。そして、A 社の営業所 コード は、たとえ、「意義」 をもっていても、B 社の事業過程・管理過程のなかで──「文脈」 のなかで── 「意味」 を構成することがない。




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