<< テーブル設計 データモデリングのエッセンス(2) | main | テーブル設計 データモデリングのエッセンス(4) >>

テーブル設計 データモデリングのエッセンス (3)

ビジネスイベント系テーブルの初期モデル

UMLのアクティビティ図とか業務フロー図で、業務のステップを洗い出す。
受注→出荷→請求→回収(入金)
一つ一つのステップが、ビジネスイベントそのもだから、それぞれ、テーブルにして記録すればよい。

私の場合は、ER図でビジネスイベントの発生順に左から右にイベント系のテーブルを並べる。つまり、ER図がビジネスプロセス図にもなっている。



主キーと外部キー

主キーは、受注番号などの自然キーではなく、システムで生成するサロゲートキー(代替キー)を使う。前回説明したように、受注変更の場合は、同じ受注番号で、別のレコードを作成するので、受注番号は、主キーにできない(しない)。

外部キーは、先行するイベントの主キーを参照する。

後続するイベントへの外部キーは先行イベント側に作成しないこと。ビジネスイベントの発生時点では、後続イベントの情報は存在しない。発生時点で存在しない情報は、記録できない。するべきではない。

イベントの発生順で外部キーを実装して、参照制約を宣言しておく。

ビジネスイベント系テーブルは What Who When

ビジネスイベントの記録は、What Who When が基本3点セット。

受注レコードの例:

What : 何を受注したか
Who1 : 誰から受注したか
Who2 : 誰が受注したか
Who3 : 誰が記録したか
When1: いつ受注したか
when2: いつ記録したか

3点セットといいながら、実は、6点セット。
ビジネスの記録は、行為者(誰が受注したか)と記録者(レコード作成者)は、別に管理したほうが実践的です。

When も、ビジネス上の受注日と、レコードを作成した日時は別に持つほうが良い。
ビジネスイベントが実際に発生した日時とデータベースに記録した日時は、通常は一致しません。

備考欄は別テーブル

ビジネスイベントの記録に備考欄や摘要欄を設けて、テキストを入力可能にすることも多い。
このテキスト情報は、別テーブルにして、受注レコードへの外部キーを持つべきです。イベントテーブルは、あくまでも、必ず記録できる、NOT NULL 制約のカラムだけで構成する。

イベントテーブルと備考欄テーブルに分けるのも、役割を単純化したテーブルを作る、というテーブル設計の原則の適用例です。関心の分離です。

イベントの基本情報だけで十分な業務と、備考欄にも関心がある業務は通常は別です。備考欄の内容によって発生する業務は、例外系の業務になることが多い。この例外系の業務用にシステム機能を設計・開発するときに、関心を分離したテーブルになっていることのメリットがでてきます。

Core Domain or Generic Subdomains ?

ビジネスイベントのテーブルは、Domain-Driven Design の Responsibility Layers の Operation Layer の永続化の実装パターンです。

Operation Layer (業務の層)であるビジネスイベントのモデリングやテーブル設計は、ビジネスアプリケーションの基本部分です。業務システムであれば、必ず、なんらかの実装が必要です。

この領域を「基幹システム」と呼ぶことがある。ただし、この部分は、業務システムにとって、必須ですが、中核( Core Domain ) とは限りません。そのビジネスにとって、競合との差別化のポイントや競争力の源泉こそが Core Domain としてモデリングと設計の重点になります。

私は、ビジネスイベント系のモデリングとテーブル実装は、ほとんど場合、Generic Subdomains だと思います。つまり、世の中に良いものがあれば、それを流用して活用する。最も優秀な人材は、この領域ではなく、もっと本質的な課題を担当させるべきでしょう。

既存のモノを利用する場合、パッケージソフトという選択肢があります。私は、それよりも、書籍で公開されている、汎用モデルを流用することが多い。
データモデルリソースブック
データモデルパターンズ
アナリシスパターン


パッケージソフトにせよ、公開モデルの流用にせよ、それを評価して、採用方針を決めるのは、もちろん、経験豊富で優秀な技術者が判断する。ただし、具体的な設計や実装は、そこそこの技術者にまかせる。あまり凝った設計をやりすぎないようにリードしてやる。

イレギュラーな処理のモデリング

ビジネスイベント系のモデリングをするために、現場でヒアリングをすると、さまざまなイレギュラーな処理や「特別の」やり方がいろいろでてくる。

そして、その「特別な処理」こそ、差別化の要因、競争優位の源泉と考えている人も多い。

ここの見極め、利害関係者での方針の共有は、重要な問題です。

私は、たいていの場合は「特別の処理」は、業務のムリ・ムラ・ムダであり、もっとシンプルにすることが、ビジネスの成功要因だと思います。そこを整理して、エネルギーをもっとほかの場所に向けることが成功要因になる。

ただ、競合との差別化を徹底した「特別の処理」で実現する、という道もあると思います。その方針が経営ビジョンから、日々のオペレーションレベルまで一貫して実施されるなら、すばらしい戦略になる可能性がある。

前者であれば、ビジネスイベント系のモデリングは、Generic Subdomains であり、既存のモデルやパッケージの活用を重視する。

後者であれば、Core Domain であり、優秀なメンバーを投入して「特別な処理」を効果的に進めることができる、オペレーションのモデリングを行い、システムの設計と実装を行う。

典型的なアンチパターンは、方針は、前者なのに、モデリングと設計は、後者、というパターンです。

Core Domain でない領域に、優秀な人材を投入して、時間とエネルギーを浪費する。


コメント
コメントする









この記事のトラックバックURL
トラックバック
時間とムダの科学
社長の話を読むことができて、面白かった。忙しくてまだ読んでいません。機会があれば,次回に・・・。同ジャンルの他作品より断然優れる。いちおし。自分の仕事に活用できたらいいなと思い購入。これを、読んで、現在、それを元に実践で勉強しています。色々な人の時間
  • 経営がいいと思う
  • 2007/09/26 4:03 PM
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM