« システムの「基盤交換性」を見極める | トップページ | フォントを替えて設計・開発を快適に »

2014.04.06

オブジェクトモデリングとデータモデリング

 オブジェクトモデリングとデータモデリングはどこが違うのだろう。クラス図やER図といった成果物を比較するだけではわからない本質的な違いが両者にはある。

 オブジェクトモデリングは基本的に、対象をシミュレーションするために実施される。たとえばモデリング課題が「ファミリーレストラン」であれば、ファミリーレストランをコンピュータ上で動作させるための準備として、オブジェクトモデルは作られる。

 シミュレーションすることにも何らかの目的がある。たとえばそれは「従業員の役割に応じた作業と効率の決定」のためなのかもしれない。そういった意図にしたがって現実が解釈され、モデルに反映される。たとえば客やウェイトレスといった要素が組み込まれつつも、客のモンスター度だのウェイトレスの美人度といった属性が捨象されたりする。ようするにオブジェクト・モデラーは、なんらかの意図にしたがって対象を抽象化しながらも「写生」しようとしている。

 いっぽうのデータモデリングの目的は何なのか。「対象をシミュレーションするため」ではない。上例に沿って言えば、「ファミリーレストランの運用にともなう情報処理を合理化するためのデータ構造」を組み立てるために、それは実施される。そして、得られるデータ構造は現実の「写生」ではなく、使い勝手の良い道具立てとして「創案」される(「エンジニアリング」といってもいい)。つまり、データモデリングされるのは「ファミリーレストラン」そのものではなく、「ファミリーレストランを効果的に管理・運用するために必要な情報の形(帳簿組織)」である。

 この点ゆえに、データモデリングの対象は限定的だ。たとえば、オブジェクトモデリングの課題としていかにも挙げられそうな「自動販売機」などは、それだけではデータモデリングしようがない。「自動販売機の運用にともなう情報処理を合理化するためのデータ構造」は、自動販売機の外観やモジュール構造を眺めまわすだけでは考えようがないからだ。その機械を扱う事業や業務のあり方までを視野に置かねば、効果的な帳簿組織は見えてこない。

 では、その逆はどうか。「データモデリングしやすいが、オブジェクトモデリングしようがない課題」というものはあるのだろうか。おそらくない。データモデリングは複雑なデータ構造をともなう開発課題に向いているが、オブジェクトモデリングでそういう課題を扱えないわけではない。たとえば「生産管理システム」をシミュレーションするためにこれをオブジェクトモデリングすることも可能ではある。出来上がったモデルには、システムが扱う帳簿組織のあり方(またはそれらしきもの)も記述されているだろう。つまりオブジェクトモデリングが扱う分野は、データモデリングの適合分野を包含している(次図)。

┌─────────────────┐
| オブジェクトモデリングの対象  │
|                 │
|                 │
|                 │
|  ┌───────────┐  |
|  |データモデリングの対象│  |
|  |           │  |
|  └───────────┘  |
└─────────────────┘

 ただしこの関係は、モデリング技法としてのいずれかの優位性を意味するものではない。データモデリングには、帳簿組織のあり方を考えるための知見が盛り込まれている。射程範囲は狭いが、その領域を効果的に扱うための道具立てが揃っている。つまり、データモデリングの枠組みは「DSL(Domain Specific Language,ドメイン固有言語)」のひとつである。

 当然のことだが、DSLが存在する領域の課題についてはDSLを使ったほうがいい。じっさい、個々の業務システムをオブジェクトモデリングする試みもかつてはなされたものだが、そのスタイルは定着しなかった。モデリング技法として汎用的であるゆえに作業効率が悪かったからだろう。刺身包丁があるのなら、刺身を作るためにあえて五徳ナイフを使う意味はないということだ。

 ただ残念なことに、オブジェクトモデリングの発想を持ち込んだ形でデータモデリングされるケースが今でもある。データの論理構造をオブジェクトIDのような単独主キーのみで組み立てる「ID方式」などはその典型だ。もったいない。データモデリングの枠組みを利用するのであれば、関数従属性や正規化といったドメイン固有の知見も活用したほうがいい。そのほうが先人達の肩の上に乗れるので、堅実かつお得だからだ。

|

« システムの「基盤交換性」を見極める | トップページ | フォントを替えて設計・開発を快適に »

コメント

「ID方式」で設計そして実装されたテーブルをよく見ます。私も渡辺さんと同様、もったいないなあと思ってしまします。しかしながら、今、私が携わっているプロジェクトでは、ID方式ではなく、適切に親子関係、参照関係、継承関係等を駆使して設計されています(但し、一部のテーブル関係で親子関係にすべきとこを参照関係にしてるなどがあり、これは恐らく担当者が変わって適切に設計できなかったんだと思ってますw)。
しかしながら、当プロジェクトもそうですが、テーブル間のリレーションを適切に設計しておきながら、なぜ、実装において、外部キー制約などの制約をかけないで実装しているプロジェクトがほとんどなのでしょうか?(たまたま、私が携わっているプロジェクトだけがそうなのかもしれませんが・・・)
当制約をかけるメリットは、なんといっても、データの整合性が保たれ、アプリ側でその点を実装しなくても済むと思ってます。デメリットをあげるとすると、テストするときなど、データの整合性を意識してデータを作る必要がある程度でしょうか。
以上、長文になりましたが、渡辺さんのご見解はいかがでしょうか。

投稿: 清兵衛 | 2014.04.22 23:11

清兵衛さん

まっとうなDB設計が出来ているのに、惜しいですね。アプリの仕様が不要にごちゃごちゃしてしまいますからね。

ただ、DDLレベルでこまめに制約をかける方針でいってもいいのですが、これだとテーブル間のすべての制約を盛り込めません。とくに動的な制約についてはお手上げです。結果的に、制約の一部がDDLで、一部がアプリで表現されるという中途半端な形になる。もちろん、だからといって制約をぜんぶアプリで書く方針もいただけません。

これは、動的・静的を問わず制約を「テーブル仕様」として表現できるような開発基盤を用いることで解決できます。完璧をめざすのは難しいにせよ、8割がたの制約をそのように扱えるのであれば上等です。そのような基盤を用いることで、DDLレベルの制約をいっさいかけないスタイルをとれます。

ここらへんについては「DDLレベルの外部キー制約は不要」の記事で書いたのですが、もちろんその種の開発基盤を用いることが可能であれば、という前提です。使わないのであれば、少なくともデータモデル上で表現されている関連についてはDDLレベルで組み込むべきだとは思いますね。

投稿: わたなべ | 2014.04.23 09:21

渡辺さんご返答ありがとうございます。
別記事の方も読ませていただきました。
ただ、私の無能かつ浅学のため、理解できていない箇所があるので、下記にご質問させてください。
テーブル仕様として表現できるような開発基盤についてですが、具体的にはどういったものでしょうか。私が想像するには、共通部品かなと思いました。各機能(プログラム)が必ず使用するように共通部品を通してDBに制約を漏れ無く制御できるようにするなどなど。ただ、これは、渡辺さんもおっしゃってる通り、制約をアプリ側で書くことになるので宜しくないと思いました。
では、「テーブル仕様として表現できるような開発基盤」とは、一体なんなのかということで、プロシージャでもなく、もちろんトリガーでもない、と考えを巡らせて今日週末に至った次第です。
ただ、私が良いと思ってた、テーブルの制約を単純に適用するのは、別記事で渡辺さんが書かれていたのを読んで理解できました。有効区分のあるなしでなどなど、確かにあり得ると思いました。

さて、話は戻りまして、「テーブル仕様として表現できるような開発基盤」についてですが、具体的にどのようなものなのでしょうか。
長文になり恐縮ですが、どうぞご教授くださいませ。

投稿: 清兵衛 | 2014.04.25 22:55

清兵衛さん

 ひととおりの制約をテーブル仕様として表現できるような開発基盤の実例のひとつが、拙作のOSS基盤XEAD Driverです。これを使ってテーブルの仕様書を書けば、そこに書かれた制約が基盤上で実行されるすべてのアプリに適用されます。

 ここでいう「テーブルの仕様書」とは、通常のフィールド定義やキー定義の他に、結合定義や、レコード操作前後に実行されるべきスクリプトなど多彩な要素を含むものです。このスクリプトはトリガーやストアドに似ていますが、基盤上で実行されるアプリとプログラム域を共有する点で異なります。つまり、テーブル仕様が実行時にアプリの仕様と動的に統合されるということで、あたかもテーブル仕様がもともとアプリ定義上に書かれていたかのように振舞います。

 この考え方のポイントは「管理時と実行時のビューの分離」です。仕様管理上はアプリ定義とテーブル定義とがDSLによって別々に記述されるいっぽうで、実行時には単一のクラスとして統合される。アプリのクラスが実行されるとき、関連するテーブルのクラスと通信する、なんてまどろっこしいことはしない。起動される際にアプリがテーブルを飲み込んでしまう、というイメージです。

 動的参照のような複雑な制約についても、結合テーブルやスクリプトを用いることで端的に表現できるので、結果的に、テーブルに関数従属する仕様をひととおりテーブル側で管理できるようになります。「カエサルのものはカエサルへ。テーブルのものはテーブルへ」です。参考にしてください。

投稿: わたなべ | 2014.04.26 09:18

渡辺さん

ご返答ありがとうございます。ただ、1つだけ記述内容に大きな間違いがあります!
それは、「拙作のOSS基盤XEAD Driver」の中で、正しくは、「大傑作のOSS基盤XEAD Driver」
が正しいです。
このような素晴らしい、開発基盤があれば、設計そして開発も楽しくできそうな
気がします。

私は、XEADの方は、有効に使わせて頂いて大変満足しているのですが、
大傑作のXEAD Driverの方も積極的に使っていきたいと思いました。

XEADは、サンプルや付属していた確かhtmlのページのヘルプを見ながら、
学習してマスターしていった記憶があります。
XEAD Driverの方も、とっかかりは、そういった感じで学習して
マスターするのがいいでしょうか。
それとも、もっといい方法がありますでしょうか。

投稿: 清兵衛 | 2014.05.01 18:02

清兵衛さん

大傑作かどうかはわかりませんが(^^;、このような合理化策がもっと普及してほしいですね。そして、水ぶくれさせられた工数ではなく、技術力に裏打ちされた契約単価の高さで稼ぐ、そういう業界にしていきたいと思います。

言われているのはXEAD Modelerの操作援助に含まれているチュートリアルのことですね。XEAD Driverの学習のためにも同様の素材を用意する必要がありそうです。検討します。

投稿: わたなべ | 2014.05.06 11:03

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: オブジェクトモデリングとデータモデリング:

« システムの「基盤交換性」を見極める | トップページ | フォントを替えて設計・開発を快適に »