« マージ処理はコードを理解すべきである~チケット駆動開発の発展形 | トップページ | リーンソフトウェア開発のリンク »

2013/05/03

DOAはOOA以前に表記法の問題点がある

UMLモデリングで有名な平澤さんの記事を見つけたのでメモ。
ラフなメモ書き。

椿先生のデータモデリング本 - UMLモデリングレッスン執筆日誌

データモデル表記読み替えハンドブック: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

データベース設計で派生関係は難しい: プログラマの思索

【1】DOAは日本独自の歴史を持ち、業務モデリングに特化したノウハウも多い。
でも、データモデル表記読み替えハンドブック: プログラマの思索にも書いたけれど、TH法、T字形ER、渡辺式、IDEF1Xなどの記法がたくさんありすぎて、正直読みづらい。
個人的には、ER図はIDEF1Xが一番すっきりしていて読みやすいが、業務フローも考慮すると渡辺式が分かりやすいと思う。

最近考えているのは、ER図を基本にして、業務フローと画面UIを組み合わせたモデリング技術としてDOAを再構築できないか、ということ。
UMLのように、一つのモデルを静的モデル(クラス図)だけでなく、動的モデル(シーケンス図、状態遷移図)の観点でも表現して、モデルを洗練させていったり、モデルの整合性を保証するようにしたいのだ。
その点では、渡辺式の3要素技法はよく考えられていると思う。

【2】IDEF1Xの記法とUMLのクラス図の記法の対比を下記にまとめてみた。

IDEF1XがIE記法よりも優れていると思う点は、親子関係と参照関係、派生関係の違いが一目で分かることだ。
OOAであいまいに表現される関連は、DOAでは親子関係と参照関係ではっきり表現できる。
親子関係による複合キー、参照関係による外部キーは全く意味が違うのに、OOAでは一つの関連でしか表現できないため、本来の業務ロジックの表現力が弱いと思う。
また、IE記法では、派生関係の記述力が弱い。また、親子関係と参照関係は、1対他の同じ線で引く表現しか無いため、記述力が弱いと思う。

データモデリングの初心者がER図を書くと、親子関係を多用する時が多い。
よく使われるのは、ヘッダ・明細の親子関係だ。
帳票や画面からテーブルを類推する時、すぐにヘッダ・明細は分かるので、親子関係ばかりのER図になる。

だが、DOAによるモデリングの基本は外部キーを使った参照関係によって、テーブル間のリレーションシップを表現して、業務ロジックを表現する所にあると思う。
DOAに慣れていない人は、外部キーの使い方が良くない。
注文明細にある商品名の表示ぐらいしか、外部キーを使っていない。

本来は、受注→請求→売上計上→入金(売掛金回収)のような一連の業務フローにおいて、外部キーでリレーションシップを表現して、データの登録・更新・削除に合わせて業務ロジックを表現できるようにすべきなのだ。

テーブルの親子関係はOOAのコンポジションに相当するため、一つのエンティティ、つまり、データのライフサイクルが同じものとして捉えられる。
無意味に分割してもあまり意味が無い。

子テーブルは複合キーという主キーを持つが、主キーは普通は更新不可なので、子テーブルのデータを入れ替えたい時に主キーを更新したくなる場合があり、その時に外部キーを使っていないと、他テーブルとのデータの整合性が取れなくなる時がある。
特に、トランザクションテーブル同士の参照関係を上手く使えれば、柔軟なテーブル設計になる時が多いと思う。

【3】外部キーによるリレーションシップには、「暗黙的なリレーションシップ」と呼ばれる別のパターンもある。

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索にも書いたけれども、複数のテーブルを結合したビューで参照制約が存在する場合、「暗黙的なリレーションシップ」「動的な参照関係」とか「継承属性」と呼ぶ。

実際の現場では、継承属性が存在する時があり、実はテーブル間のリレーションシップが存在するがゆえに、業務ロジックの制約を表現している時がある。
しかし、継承属性をモデルから読み取るには、ER図をかなり読み込んでいないと難しい。

【4】DOAにもOOAと同様に派生関係(継承関係)は存在するが、共存と排他の2種類の意味があり、区別して使うのは意外に難しい。

データベース設計で派生関係は難しい: プログラマの思索にも書いたけれども、OOAの継承に似た排他という関係と、NULL値を排除するための共存という関係を使い分ける必要がある。

法人顧客と個人顧客、生産管理に出てくる品目や製造・出庫指図などは、DOAの派生関係で表現できるが、理解は意外に難しいものだ。

【5】DOAがOOAよりも面白い点の一つは、業務モデリングと密接に絡んだ場合、会計簿記の仕訳の概念が必然的に出てくることだ。
製造業で、原材料を仕入れて倉庫に入れれば、「仕入//買掛金」というお金の記録が発生する。
小売業で、商品を顧客に現金払いで売ったならば、「現金//売上」というお金の記録が発生する。
つまり、それぞれの業務でデータが流れる時に、カネが発生し、それを記帳する必要が出てくる。
そして、そこから、在庫管理や会計帳簿の話につながっていくわけだ。

一技術者の観点から離れて、実際のビジネスの現場で働いている事務の女性や経理担当者にヒヤリングしてみると、彼らはお金の流れにとても敏感であることがよく分かる。
彼らは税理士や会計士などのような監査部門の人達に対応しているため、ITに弱くても、会社の実務にはかなり強い。

DOAと会計の関係に触れた本としては、渡辺幸三さんの本「販売管理システムで学ぶモデリング講座 (DB Magazine SELECTION)」と梅田弘之さんの本「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」がベストではないかと思っている。
そして、DOAと会計の関係をもっと分かりやすく表現できないのか、という問題意識も持っている。
その辺りで考えたことは、Blogに残していく。

|

« マージ処理はコードを理解すべきである~チケット駆動開発の発展形 | トップページ | リーンソフトウェア開発のリンク »

モデリング」カテゴリの記事

コメント

コメントを書く



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


コメントは記事投稿者が公開するまで表示されません。



« マージ処理はコードを理解すべきである~チケット駆動開発の発展形 | トップページ | リーンソフトウェア開発のリンク »