『基礎からわかるMDA (モデル駆動型アーキテクチャ) なぜモデリングするのか?』

■『基礎からわかるMDA (モデル駆動型アーキテクチャ) なぜモデリングするのか?

MDAの目的は、「開発資産の経年劣化の予防」です。

プログラム言語の寿命は短い。フレームワークの寿命はもっと短い。
システム設計を実装技術に依存してしまうと、設計の寿命まで短くなってしまいます。

コンパイラのおかげで、C言語で書かれたプログラムがあたらしいプラットフォームでも動作するので、プログラムを長く使用することができます。

MDAも同じです。
プラットフォームに依存しないことで、実装技術が変化しても開発資産の経年劣化を最小限に抑えます。
データベースの設計を概念設計・論理設計・物理設計に分けることと、よく似ていると思いました。

MDAというと「ソースコードの自動生成」の話題が取り上げられやすいですが、MDAの本質はそこではありません。
本書を読んで、MDAの目的・考え方がよくわかりました。

MDAを短期間で評価することはできないと思いました。
システムをいくつかのプラットフォームに移植して、長い間システムを使い続けて、それでようやくMDAの価値を実感できるのではないでしょうか。

本書の最後の章「第6章 MDAの将来」では、Steve Cook氏のMDA批判の論点と、Mechael Guttman氏の反論が紹介されています。
MDAび長所ばかりでなく、短所・欠点・課題について知ることができ、より広い視点を持つことができるところも良いです。

本書は、MDAに興味関心のある技術者が、MDAの基礎・概要を知るのにおすすめの本です。

■参考

データベースのイベントデータからリソースを独立して管理する

独習データベース設計』を読んで勉強中です。

顧客・取引先・商品など、リソースデータは企業にとって財産です。

リソースデータになる得るものを、イベントデータに紛れ込んだままにしておくのはもったいない。

イベントデータにリソースが紛れ込むことがないように、リソースはリソースとして管理できるように、データベースを設計します。

たとえば予約データや受注データに顧客の情報が含まれる場合は、顧客属性を抽出して、独立して管理するようにします。

予約テーブル

予約番号
予約者名
予約住所
予約電話番号
商品コード

予約テーブルに含まれている顧客情報は別に管理するようにします。

顧客テーブル

顧客番号
名前
住所
電話番号

“リソースデータはイベントデータに紛れ込ませない”
このような視点を持っていなかったので、参考になりました。

とてもいい本です。お勧めです。

リソースの断面管理

独習データベース設計』を読んで勉強中です。

「リソースの断面管理」
といって何かわかりますか?

私はわかりませんでしたが、テーブルの設計を見ると一目瞭然です。

ある基準日を境にインスタンスを変更する時、断面管理が必要になります。

たとえば商品テーブルがあったとして、

商品コード
商品価格

商品価格の変更ある場合は、主キーに「適用年月日」を追加しして次のようにします。

商品コード
適用年月日
商品価格

商品価格が2011年4月1日から変わる場合は、テーブルのデータは次のような感じになります。

商品コード 適用年月日 商品価格
A001 2010/4/1 800
A001 2011/4/1 1000

データベース設計のデザインパターン本が欲しいです。

■2011年10月4日 追記

もう少し複雑なパターンを教えていただきました。
http://ameblo.jp/hatsanhat/entry-10981349243.html

名前付けの重要性

独習データベース設計』を読んで勉強中です。

独習データベース設計』の第8章は「ネーミング標準」。
名前付けに1つの章を割いて説明しています。
名前づけの重要性を再確認しました。

一口に「顧客」といっても人によって意味が違ってきます。
製造の人は仕入れ先を、営業の人は取引先を顧客と呼んでいるかもしれません。
適切な名前を付けることは、しっかりしたデータベース設計には重要なことです。

ユニークな名前を付けることで、プログラムの変更する時の影響範囲を測定することも容易になります。