Hatena::ブログ(Diary)

papandaDiary - Be just and fear not. このページをアンテナに追加 RSSフィード Twitter

2006-12-03 えぇと、2は何だっけ。

自分流モデリング探しの旅(2)〜T字形ER データベース設計技法

T字形ER データベース設計技法

T字形ER データベース設計技法

この書籍は、初版が1998年10月です。実に、8年前のものです。

1998年と言えば、私はまだ大学生でした。

なお、本書の続編が最近発刊されています。


私が、この本とであったのは、新人の頃。

日経ソフトウェアの上流工程を学ぼうという特集で紹介されていたのを

見て、購入しました。

しかし、買ってはみたものの、難しくよく分からない。

随分長い間、放置していたのを覚えています。


T字形ER手法とは何か?

データ設計技法ではなく、ビジネスを解析するための技法であると定義

されています。DOAの思想を根底に持っています。

T字形ER手法を構成するものは次のとおり。

5つの技法

  1. identifier
  2. resourceとevent
  3. 対照表
  4. 対応表
  5. サブセット

4つのルール

  1. resource:resource
  2. resource:event
  3. event:event
  4. 再帰

identifierの定義

identifierについては、コード体系の中に記述されているコードを

使うこととされている(実在するデータそのものに語らせるという思想がDOA)。

この、identifierとはいわゆる主キーのことではない。

identifierとは、モノ(entity)に与えられるコードである。

一方、主キーとは、プライマリキーとして存在するデータアクセス用のキーで

あって、ビジネスのコード体系を写像しているとは限らないのである。

このように、本書では、identifierと主キーを区別している。


しかし、ビジネスのコードが常に一意性を保証しているとは限らない。

つまり、ここでいうidentifierとは、一意性を保証できないことがある。

一意性は、主キーで保証することになると本書は言う。


例)支店ごとに取引の注文番号を採番する。

支店

支店コード


注文

注文番号

支店コード


注文番号は、identifierである。

主キーは、一意性を保証するため、注文番号+支店コードとなる。


概念は理解できる。

ただ、この当たりは、前項の楽々ERDレッスンでのべれられていた

「id」の導入の方が、個人的にはしっくりときてしまう。

システム側だけのコードとはいえ、コードを新設してしまうやり方は

DOA的にはNGもいいところなのだろう。

しかし、idを付与した方が、かえってコード体系に対して柔軟な

対応ができ、魅力的だ。

DOA的な思想からすれば、

「そんなコロコロ変わるコード体系は統一されていない」

という、そもそもの非難を浴びそうだが…。

参照キーの持たせ方。

次に重要なのが、リレーションシップの構築である。

その際、参照キーをどう実現するかが、ポイントとなる。

resourceとresourceをつなぐ場合:対照表を生成する。対照表はeventである。

 (例)従業員と営業所

     従業員-営業所の対照表を作成し、リレーションシップを保全する。

resourceとeventをつなぐ場合:event側に参照キーを持たせる。

 (例)顧客と注文

     注文entityに顧客コードを持たせる。

eventとeventをつなぐ場合

「1:1」「1:m」:時系列の遅い方に持たせる。

 (例)受注と請求(一つの受注に対し請求は一つ)

     請求に受注番号を持たせる。

「m:1」「m:m」:対応表を生成する。

 (例)受注と請求(複数の受注に対し請求は一つ)

     受注-請求の対応表を生成し、リレーションシップを保全する。


参照キーの与え方について、明確な方針ができて、本書の指針は、

とても参考になる。

Nullや種別の扱い。

以下のものについてはentityのサブセットとして切り出す。

  • entitiy生成時では、値がNullとなる属性

例えば、注文entityに対する、取消日。

これは、取消された注文entityを別途用意して管理するという

ことになるのだろう。

  • 種別コードや区分コードで表現されるもの

例えば、会員entityにおいて、正会員と仮会員のような区分を

もつ場合、ひとつのentityでまとめないということだ。


会員entityに対し、正会員、仮会員というサブセットを用意する。

これは、ワークフローでもあてはめることができそうだ。

例えば、承認ステータスという属性があるとする。

承認依頼前→承認待ち→一次承認済み→二次承認待ち→…

に対し、それぞれサブセットを生成する。

状態遷移を実現する。


まあ、サブセットとして切り出す切り出さないという以前に、

コードをきちんとマスタ化してよと思うシステムも多いわけで。

区分コード=1が何で、区分コード=2が何でという事実が、

DBに定義されていない場合、少なくともドキュメントが必要となる。

そのドキュメントすら、用意されていないと、プログラムを追うしか

無くなってしまう。

そして、プログラムでは当然の如く、マジックナンバーを使っている

わけです。


あとは、担当者に聞くか。

「えぇと、0は正会員で、1は仮会員で、2は…なんだっけ」

みたいな会話をいちいちする懐の深さがお互いにあればの話しですが。

何でわざわざそんな苦労するようなことをしなくてはいけない

DBになっているのだろう?

PLANですPLANです 2006/12/04 17:23 佐藤さんのT字型は理論が妙に難解でした。DBスコープとしては個別システム構築に適しているかと感じています。

papanda0806papanda0806 2006/12/04 21:42 T字型難解です。。。(PLANさんがおっしゃるのだから間違いないですね)

PLANですPLANです 2006/12/05 09:30 佐藤さんや椿さんが中心となってDOA+コンソーシアムを数年前に立上げていらっしゃいます。私も会員です。DOAネタがダウンロードできます。

papanda0806papanda0806 2006/12/05 11:24 PLANさん、ありがとうございます。
DOA+のことはつい先日知りまして、会員登録しました。
今後、活用させて頂こうと思っています。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/papanda0806/20061203/1165127104