2006年 4月 1日 作成 | アトリビュート・リスト | >> 目次 (テーマ ごと) |
2010年 5月 1日 補遺 |
TMD (TM Diagram) は、「構造」 を記述する図である。TMD には、個体、個体の性質および(個体のあいだに成立している) 関係を記述するが、TMD のみが、システム を作るための ドキュメント ではない。TMD ばかりが注目されているようだが、TM を補助する ドキュメント として、以下が用意されている。
(1) アトリビュート・リスト
今回は、アトリビュート・リスト について語る。
(1) データ の定義 (桁数、文字・数値の属性、sign-bit の有無、小数点、範囲などを記述する。) システム 作りで最大に難しい点は、「前提 (validation-rule)」 を 1つの取りこぼしもしないで記述することにある。それを実現するために、「構造」 図は役立つ。たとえば、以下を例にする。
{取引先 コード、取引先名称、取引先住所、・・・}. 請求金額 (D) に対して、アトリビュート・リスト を作成するとして、「前提」 を、どのようにして記述すれば良いか 述べてみる。「前提」 は、以下の手順に従って記述する。
(1) リレーションシップ が成立している相手 entity の アトリビュート 1つずつに対して、
(2) 当該 アトリビュート が帰属する entity の ほかの アトリビュート 1つずつに対して、 たとえば、請求金額 (D) と (受注 entity のなかの) 受注日、受注数などと対照して、次に、請求 entity のなかの請求日などと対照する。
(1) 受注日が、或る一定期間のなかであれば、請求金額を割り引くことはあるか。
{受注番号、取引先 コード (R)、商品 コード (R)、受注日、受注数、・・・}.
(2) 受注数が、或る数量を超えたときには、請求金額を割り引くことはあるか。
{受注番号、取引先 コード (R)、商品 コード (R)、受注日、受注数、・・・}.
(3) 請求日を超えたときに、追徴金を課すことはあるか。
{受注番号、取引先 コード (R)、商品 コード (R)、受注日、受注数、・・・}. このように、アトリビュート 1つずつに対して、可能態を考えて、ユーザ といっしょに網羅性を検証すれば良い。アトリビュート・リスト の具体的な作成法については、以下の書物を参照されたい。 拙著 「データベース 設計論──T字形 ER」 (120 ページ)。 |
[ 補遺 ] (2010年 5月 1日)
取り立てて補遺はいらないでしょう。 |
<< もどる | ベーシックス | すすむ >> | |
▼ データベースの基礎知識 |