2006年 4月 1日 作成 アトリビュート・リスト >> 目次 (テーマ ごと)
2010年 5月 1日 補遺  


 
 「構造」 は、「個体と(個体のあいだの) 関係」 で記述される。
 「個体」 の認知を、「性質」 の外延として考えるか (関係主義)、それとも、「個体」 を認知して、「性質」 を列挙するか (実体主義) は、論点になるが、TM では、実体主義の観点に立って、「合意された認知番号」 を使って、まず、「個体」 を認知する。

 TMD (TM Diagram) は、「構造」 を記述する図である。TMD には、個体、個体の性質および(個体のあいだに成立している) 関係を記述するが、TMD のみが、システム を作るための ドキュメント ではない。TMD ばかりが注目されているようだが、TM を補助する ドキュメント として、以下が用意されている。

  (1) アトリビュート・リスト
  (2) リレーションシップ の検証表
  (3) キー (index-key) の定義表
  (4) アルゴリズム の指示書

 今回は、アトリビュート・リスト について語る。
 アトリビュート・リスト は、その呼称が示しているように、アトリビュート (データ の項目) ごとに作成される。アトリビュート・リスト には、最低限、以下の項目が記述されなければならない。

  (1) データ の定義 (桁数、文字・数値の属性、sign-bit の有無、小数点、範囲などを記述する。)
  (2) 前提 (baseline とも云うが、validation-rule を記述する。)
  (3) ロック (参照・更新などの lock 情報を記述する。)
  (4) 計算式 (導出項目であれば、導出規則を記述する。)

 システム 作りで最大に難しい点は、「前提 (validation-rule)」 を 1つの取りこぼしもしないで記述することにある。それを実現するために、「構造」 図は役立つ。たとえば、以下を例にする。

  {取引先 コード、取引先名称、取引先住所、・・・}.
  {受注番号、取引先 コード (R)、商品 コード (R)、受注日、受注数、・・・}.
  {請求番号、受注番号 (R)、請求日、請求金額 (D)、・・・}.

 請求金額 (D) に対して、アトリビュート・リスト を作成するとして、「前提」 を、どのようにして記述すれば良いか 述べてみる。「前提」 は、以下の手順に従って記述する。

  (1) リレーションシップ が成立している相手 entity の アトリビュート 1つずつに対して
    起こりうる可能態を考える。

  (2) 当該 アトリビュート が帰属する entity の ほかの アトリビュート 1つずつに対して
    起こりうる可能態を考える。

 たとえば、請求金額 (D) と (受注 entity のなかの) 受注日、受注数などと対照して、次に、請求 entity のなかの請求日などと対照する。

  (1) 受注日が、或る一定期間のなかであれば、請求金額を割り引くことはあるか。
    (たとえば、特売 セール 期間とか。)

     {受注番号、取引先 コード (R)、商品 コード (R)、受注日、受注数、・・・}.
                                    ↑
                              ┌───┘
                              │
     {請求番号、受注番号 (R)、請求日、請求金額 (D)、・・・}.

  (2) 受注数が、或る数量を超えたときには、請求金額を割り引くことはあるか。
    (たとえば、大量買い付け--bulk buying--とか。)

     {受注番号、取引先 コード (R)、商品 コード (R)、受注日、受注数、・・・}.
                                          ↑
                              ┌───────┘
                              │
     {請求番号、受注番号 (R)、請求日、請求金額 (D)、・・・}.

  (3) 請求日を超えたときに、追徴金を課すことはあるか。
    (たとえば、延滞に対する受取利息とか。)

     {受注番号、取引先 コード (R)、商品 コード (R)、受注日、受注数、・・・}.
                        ┌───┐
                        ↓     |
     {請求番号、受注番号 (R)、請求日、請求金額 (D)、・・・}.

 このように、アトリビュート 1つずつに対して、可能態を考えて、ユーザ といっしょに網羅性を検証すれば良い。アトリビュート・リスト の具体的な作成法については、以下の書物を参照されたい。

   拙著 「データベース 設計論──T字形 ER」 (120 ページ)。



[ 補遺 ] (2010年 5月 1日)

 取り立てて補遺はいらないでしょう。





  << もどる ベーシックス すすむ >>
  データベースの基礎知識