オルタナティブ・ブログ > 「神奈河、神名川、上無川 。」 >

読めばベタに分かる、タイトルどおりのブログ

[経験談シリーズ]システム開発がうまくいかなかった訳(2)~”論理”=”物理”

»

以前、このシリーズ(?)の第一回として、論理”から”物理”の際の抜け落ちというのを書かせていただいたが、今度は逆パターン、というか、亜流というか・・・。

前回は、DOA的アプローチで、論理ERDから物理ERDにモデリングをする際に、項目の条件が変わってしまった、という話だったが、今度は、論理=物理として実装したお話。

実は今回の場合、業務アプリケーションそのものにおいては、現時点直接的には問題は発生していない。

じゃあ何がうまくないのか?というと、OLAP・BI等での利用について、である。

マスターのような情報、トランザクション情報だけではなく、フラグ、およびトランザクションデータの属性情報のようなものまで、全て論理的に別エンティティになっているものが、そのまま物理的実装がされており、結果として、BI等でそのエンティティそのままでビューを作ると、実ユーザーは、そのエンティティのリレーションをもの凄く意識して作らない限り、自分達の求める情報を導き出すことができなくなってしまった。

したがって、代理である程度システム提供側で決め撃ちのリレーションをはったビューを作成することになったのだが、そうなると当然、実ユーザーによっては、本来求めたい結果を導き出すことができないケースが出てくる。そうなると、結果として、一旦BIツールで抜き出した結果を、更にCSV等で出力後、マクロ等で加工する、という必要が出てきてしまい、本来のBIツールの利用法が全くできなくなってしまった。

とは言え、情報系での利用目的を最重視してしまうと、当然、業務系のアプリケーションで今のパフォーマンスが導き出せているかどうか、という保証も無い。

自分が直接関わった案件では無かったが、業務系と情報系のDBを両立させる、もしくはどのように切り離すか、というバランスの取り方が非常に大事である、ということは話を聞いて改めて痛切に感じた。要求側自身も「DB設計は開発側の仕事」と決め付けずに積極的に関わり、開発・実装側自身も「今のデータの使われ方は一元的な利用とは限らない」と要求側自身の関与を求める、という歩み寄りが必要だと感じている。

Comment(2)

コメント

よくERPの導入に際して、『ここにもそこにもあそこにもデータが蓄積されるので在庫がリアルタイムにわかります』という売り文句がありますが、それがアクティブな在庫なのかどうかはわからないという話を思い出しました。
確かにデータベースに登録されたレコードは把握できますが、ステータスが売約済で発送前の在庫と言っても現金の前金で決済が終わっているものから、与信限度ギリッギリのお客様に掛で売っているものまでありえるわけで、そういったケースでも物理と論理の差を念頭に置いておかなくてはならないのかなと思います。

>yoheiさま
コメントありがとうございました。おっしゃるとおり、と思います。
論理がきちんと描けてなければ、そもそもデータ体系が存在しないのだから、業務ができる訳がなく、物理がきちんと描けてなければ、「何を実現したかったんだっけ?」の部分で大きく業務効率に影響が出てしまいます。
そういう意味では、最近言葉を見ることが少なくなりましたが、あらためて「DOA」重要だと思ってます。

コメントを投稿する