インピーダンスミスマッチからは、どのような問題が発生するのでしょうか? 代表的な問題は、OOAで設計した部分とDOAで設計した部分との間のインターフェイスを設計する作業の難易度が高くなり、それ故、出来上がった設計が正しいかどうかを検証することも難しくなるということです。
ここでは、第1回「JavaとDBのデータモデルはナゼすれ違う?」で説明した「開発手法の違いによるインピーダンスミスマッチ」の内容に触れながら、具体的にどのような問題があるのかを説明します。
(1)データモデリングにおける基本思想の違い
データモデリングにおける基本思想の違いを以下の表にまとめます。
観点 | OOA | DOA |
---|---|---|
「何をベースに定義するか?」という観点から | 業務的な振る舞いの視点からデータをとらえる(業務駆動型) | 業務要件から必要とされるデータに重きを置いてアプローチする(データ駆動型) |
システムとしての最適化を行う観点から | オブジェクト指向における考え方(汎化など)を用いることで、拡張性やメンテナンス性のよいデータモデルを分析・検討し、定義する | データベースとしての物理的なテーブルの構造が(正規化などにより)最適化されるようにデータモデルを分析・検討し、定義する |
表2 OOAとDOAのデータモデリングにおける基本思想の違い |
上記の違いから最終的に出来上がるデータモデルの作りも異なってしまうため、これらのインターフェイス部分の設計は複雑になります。
(2)OOAとDOAのデータ構造のギャップ
OOAで作成されるデータモデルとDOAで作成されるデータモデルでは、データ保持方法が異なります。前者は関連する情報を1つのオブジェクトにまとめて保持しますが、後者は関連する情報を複数の表に分割して保持することがあります。このようなデータ構造のギャップがあるため、OOAで作成されるデータモデルとDOAで作成されるデータモデルを対応付けるには非常に手間がかかります。
(3)開発組織におけるギャップ
OOAとDOAとのミスマッチは非常に重要な問題ですが、この部分が軽視されてしまうケースがあります。例えば、「ビジネスロジックをOOAで設計」し、「データベースをDOAで設計」する場合、別のチームや組織に分かれて作業をすることがあります。それらのチーム間のコミュニケーションギャップから設計上の不整合が発生し、作業が手戻りすることがあります。特に会社や作業場所が異なるなど、チーム間での距離が大きいとこういった問題が発生しやすくなります。
OOAとDOAを併用して、永続化処理の分析・設計を行う際、インピーダンスミスマッチに起因する問題の影響を小さくするには何が有効でしょうか。
第一に必要なのは「入念な準備」です。つまり、OOAとDOAを併用して永続化処理の分析・設計を行うに当たっては、「永続化処理分析・設計をどのようなプロセスで実施するかを決める」ことが必要です。そして、プロセスを決めるためには、さらに以下の作業を事前に行う必要があります。
ここでは、これらの作業について具体的な例を紹介しつつ説明します。
(次ページに続く)
Copyright © ITmedia, Inc. All Rights Reserved.
Database Expert 記事ランキング