2003年 1月16日 アトリビュート・リスト の 「前提」 欄 >> 目次 (作成日順)
  ● QUESTION   アトリビュート・リスト の 「前提」 を作成する コツ はあるか。
  ▼ ANSWER   ない (少々、あるが、ない、と思ったほうがよい)。
2008年 2月 1日 補遺  



 アトリビュート・リスト では、最低限、以下の 4つの項目を記述しなければならない。

  (1) データ 値 (データ の定義)
  (2) 前提 (バリデーション・ルール)
  (3) セキュリティ (照会・更新の権限)
  (4) 計算式(導出規則)

 「前提 (baseline ともいう)」 は、自らが帰属する entity を起点にして、以下の 2つを対象として ルール を検証する。

  (1) ターゲット entity のなかに記述されている アトリビュート
  (2) 自らが帰属する entity のなかに記述されている アトリビュート

 (数学的な) 「順序 (並び)」 は以下の 3つである。

  (1) 小さい (a < b)
  (2) 等しい (a = b)
  (3) 大きい (a > b)

 「event-対-event」 では、時系列の 「順序対」 が成立する。
 したがって、同じ性質の アトリビュート であれば、以下の検証をすればよい。
 (49ページ 「event の並び」 を参照されたい。)

  (1) 小さい (たとえば、受注日 < 請求日、受注数 < 出荷数 など)
  (2) 等しい (たとえば、受注日 = 請求日、受注数 = 出荷数 など)
  (3) 大きい (たとえば、受注日 > 請求日、受注数 > 出荷数 など)

 ただし、「event-対-resource」 や 「resource-対-resource」 では、「順序対 (並び)」 が成立しないので バリデーション・ルール の検証は 「機械的に」 判断できない。

 たとえば、「event-対-resource」 として、(「請求」 entity の) 「請求金額」 と (「顧客」 entity の) 「住所」 では、請求の際に、物品代金のほかに、配送地域という観点から、「送料」 が付随費用として算入されなければならないという ルール を 「機械的に」 導出することはできない。

 また、たとえば、「resource-対-resource」 として、(「地域」 entity の) 「名称」 と (「商品」 entity の) 「名称」 では、「地域限定 (かつ、期間限定)」 の セールス が適用されるという ルール を 「機械的に」 導出することはできない。

 あるいは、たとえば、「event-対-event」 でも、異質の アトリビュート を対象とすれば、(「受注」 entity の) 「受注日」 と (「請求」 entity の) 「請求金額」 では、或る期間内の受注日は 「特売日」 なので割引が適用されるという ルール を 「機械的に」 導出することはできない。

 そういう ルール を思い浮かぶかどうかという点は、(財務会計論・原価計算の通論を読んで) 「付随費用」 の知識を習得しているかどうか、あるいは、(マーケティング の通論を読んで) セールス・プロモーション の知識を習得しているかどうか、という点に負う。言い換えれば、システム・エンジニア の FOR (Frame Of Reference、参照枠) 次第である。FOR の拡大は、(直接的な 「体験」 ではなくて) 読書量と思考力に依存することは間違いない。なぜなら、直接的な体験は領域も質も量も限られているから。

 



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

 最近 (2007年の春以後)、本 エッセー のなかで記した 「前提 (baseline)」 のことを、数学的な用語法に近づけて、「制約・束縛」 というふうに言っています。

 データ 設計で難しい点は、データを構成することよりも、データ に付与される 「制約・束縛」 を 「網羅する」 点にあります。データ を 「構成する」 作業は、構文論 (文法) の 「一般手続き」 に従えば良いので、さほど、難しい作業ではないでしょう。データ に付与される 「制約・束縛」 は、それぞれの企業・事業ごとに違っていて、パターン を流用できるほどに単純ではない。というのは、それぞれの entity の 「意味」 は、「構成」 のなかで──言い換えれば、「文脈」 のなかで──定立されているのであって、それぞれの 「文脈」 のなかで、「制約・束縛」 を網羅しなければならないから。「制約・束縛」 を一つも取りこぼさないように枚挙するには、どうすれば良いか、という点が データ 設計法の最大難事です。

 「構成 (文脈)」 のなかで 「制約・束縛」 を枚挙して網羅するために用意された資料が 「アトリビュート・リスト」 です。「制約・束縛」 を枚挙して網羅する やりかた は、本 エッセー のなかで記したので、取り立てて、補足説明はいらないでしょう。ただ、本 エッセー のなかでも綴っていますが、「制約・束縛」 を枚挙して網羅する ちから は、「モデル (生成規則・指示規則)」 の技術とはべつの知力です。その知力は、事業過程・管理過程に関する知識を習得していることが、まず、前提になります。それらの知識を どのくらい習得していなければならないか という目安は、拙著 「IT コンサルタント の スキル」 で示しましたので、ご一読下さい。ただ、それらの知識があれば、かならずしも、「制約・束縛」 を網羅できるようになる訳ではない点に注意して下さい。それらの知識を参照項にして、さらに、「文脈」 のなかで、個々の具体的な データ に関する 「『制約・束縛の可能態』 を リスト できる」 思考力がなければならないでしょうね。そして、この思考力は、速習で体得できる訳ではない。日本語を話すことができるからといって、日本語で ロジカル に考えられる訳ではないでしょう。この思考力は、日頃、意識的に養うようにしなければならない技術です。システム・エンジニア の実力とは、この思考力にある、と私は思っています。




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