2004年 5月16日 企業 コード >> 目次 (作成日順)
  ● QUESTION   企業 コード を、「すべての」 データ に記述することは良いか。
  ▼ ANSWER   原則として、だめ。
2009年 6月 1日 補遺  



 「連結」 会計のために、グループ 企業に対して、それぞれ、企業 コード が付与されている、とする。さて、企業 コード を、それぞれの企業が、自らの 「すべての」 データ に対して、付与することは 「無意味」 である。「すべて」 という概念──「すべての」 データ に対して、同じ述語 (性質) が帰して、同じ値 (定数) が付与される、ということ──は、「真理関数」 から切り離したほうが良い。形式系列 (真理関数) の一般項は、変項のみが対象となる。

 自らを記述する企業 コード は、「階の理論」 では、記述されている個々の データ に比べて、「階」 が 1つ上位にある。たとえば、チェン ER の entity 概念では、「主体型」 と 「関連型」 があるが、「入社」 を記述しようとすれば、以下のように記述できない。

    [ 主体型 ] 従業員 {従業員番号、従業員名称、・・・}---- [ 関連型 ] 入社 {入社日、・・・} ---- [ 主体型 ] (企業?)

 なぜなら、従業員は、「入社したあとに」 従業員になるのであって──「従業員」 と 「入社」 は関連を結ぶことはできないのであって──、「階」 が入り乱れている。企業 (「企業 コード」 として記述されている モノ) のなかで起こっている事態を記述する際、企業そのものを企業のなかで記述することはできない。

 ただし、複数の企業を対象にして、1つの データ 構造を記述するのであれば、企業 コード は、データ 構造のなかで、記述される。

 



[ 補遺 ] (2009年 6月 1日)

 本 エッセー の説明は、なんだか間怠 (まだる) っこしい言いかたをしていますね (苦笑)。

 (1) モデル の対象になっている現実的事態 (企業のなかで構成されている事業過程・管理過程)

    M ( e1, ・・・, en ).

   なお、e は entity を示し、M は モデル とします。

 (2) 企業 を N とすれば、

    M ⊆ N.

 もし、すべての事業が モデル 化されていれば、M = N となるでしょうね。
 このときに、N を a という 「定数」 で指示すれば、M ( a・e1, ・・・, a・en ).
 はたして、この 「定数」 には 「意味」 があるのか、というのが本 エッセー の論点です。
 M のなかで a を 「定数」 として使うことは、「無意味」 でしょうね。

 (3) ふたつの企業 { N, W } が合併した、とする。

 N の事業構成 M1 と W の事業構成 M2 は、一致しないのがふつうでしょう。
 M1 と M2 が 「完全に統一されるまで」 は、それぞれの スキーマ は local schema として継承されて、なんらかの global schema が導入されるでしょう──その global schema は、たぶん、interface として使われるでしょう。そういう状態であれば、M1 および M2 が、それぞれの スキーマ のなかで、自らの 「企業 コード」 を持つことは 「無意味」 でしょうね [ ただし、global schema のなかでは、「企業 コード」 が使われるでしょう ]。
 M1 および M2 を統一する手続きは、クライアント・サーバ 形態の スキーマ 構成手続きを流用できるでしょうね [ 拙著 「クライアント・サーバ データベース 設計」 を参照されたい ]。





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