2011年12月23日

渡辺幸三氏の「動的参照関係」について

関西IT勉強宴会のメーリングリストで、渡辺幸三氏が提案している「動的参照関係」について話題となっていたのだが、この概念についての理解がかならずしも共有されていないような気もしている(勘違いであればご免なさい)。

渡辺氏がブログで挙げている説明では、動的参照関係の説明のために、主に有効期間付きのマスタが例に採られている。一方、有効期間付きのマスタの設計は、昔から色々な考えが交錯し、業務システム設計の経験をある程度積んできた人ならば誰もがこれについては一家言持っている、といったテーマでもある。

そのため、私見ではあるが、動的参照関係の説明に有効期間付きのマスタを用いると、有効期間付きのマスタの是非や設計に関して百家争鳴状態になってしまい、動的参照関係じたいの意義になかなか議論が及ばないような気がするのである(有効期間付きのマスタについて、私が仕事を始めた四半世紀前!と今とで、基本的に同じような議論がなされていること自体、アプリケーション設計に関する知識が十分に確立されていないことの証左でもあって、それはそれで嘆かわしい事態だと思うが、これはまた別の問題でもある)。

私自身は、動的参照関係を、よくあるわりに見落としがちで、かつ、便利な概念であると考えているので、これは残念な状況である。

実際、有効期間付きのマスタ以外にも、動的参照関係を適用可能な場面はあるので、そういった例で説明することも、動的参照関係の理解につながるのではないかと思い、このエントリを書いてみることにした。

参考:動的参照関係に関する渡辺氏のエントリ


続きを読む
posted by keis at 23:21| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2008年06月14日

「販売管理システムで学ぶモデリング講座」を読んで

読終えてふと思った。

著者(渡辺さん)は、この本を書くより実際に販売 管理システムを作った方が楽だったに違いない。

販売管理システムで学ぶモ

デリング講座販売管理システムで学ぶモデリング講座
渡辺 幸三

翔泳社 2008-05-29


Amazonで詳しく見る
by G-Tools


続きを読む
posted by keis at 10:09| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2007年02月12日

データモデル洗練テクニック−「スコープ概念の抽出」と「参照関係の逆転」

データモデルを設計するときに役立つかもしれないテクニックをひとつ。


続きを読む
posted by keis at 16:39| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2006年10月08日

主キーの設計E−数学をちょっとだけ(その3)

シリーズになってしまった「主キーの設計」も今回でようやく終わりだ。前々回ではリレーションに対する代替案として「リレーション関数」なる概念をひねり出した。前回はリレーション関数モデルの上で正規形と正規化を再定義した。今回はリレーション関数モデルに関係代数を移築する。


続きを読む
posted by keis at 11:58| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2006年09月29日

主キーの設計D−数学をちょっとだけ(その2)

前回に引き続いて数学である。前回は「リレーション」の代わりに「リレーション関数」を土台としてリレーショナルモデルを再構築できないか、という提案をした。そして「リレーション関数」の数学的定義を作ってみた。今回は、この新たな基礎の上に、正規化理論を移築できないかを検討する。
続きを読む
posted by keis at 23:23| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2006年09月22日

主キーの設計C−数学をちょっとだけ(その1)

主キー論争の分析そのCである。
といっても、前のエントリーですでに、主キーの存在を抹殺したので、論争の焦点そのものが雲散霧消してしまった。今回は付け足しとして、数学の話をする。
この「主キーの設計」シリーズ、僕は近年稀に見る気合をいれて書いているのに、悲しいことに回を追うごとに読者は減っているようだ(:_;)。今回でさらに減ること請け合いだ。
読みたくない人は読まなくてよろしい(でもヒマだったら読んでね)。


続きを読む
posted by keis at 22:39| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2006年09月14日

主キーの設計B−いいとこ取りは可能か?

主キー論争の分析そのBである。
前のエントリーでは、コード派とID派の意見の相違の源泉には、コッド博士が作り出した正規化の理論の取り扱いをどうするか、という問題が横たわっているという仮説を提示した。そして、正規化の理論には「エンティティ」の居場所がなく、したがって(実質はエンティティ参照である)IDにも居場所がない、という僕の理解を説明した。


続きを読む
posted by keis at 23:43| Comment(3) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2006年09月07日

主キーの設計A−正規化って何ですか?

主キー論争の分析そのAである。
前のエントリーでは、最終的にできあがるデータベースの形について検討した。僕の結論は、内部識別子(アソシエーションの実装用の識別子)としてIDを用いることについては、コード派もID派も同意できるのではないかというものだった。
僕としては、コード派とID派の違いは、むしろ、今回検討するデータ設計の方法論に関するものだ、と思っている。


続きを読む
posted by keis at 15:11| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2006年09月03日

主キーの設計@

主キー論争(データベース設計で、どういうものをテーブルの主キーとすべきかという議論)が再燃しているようだ(こことかこことかこことかここ)。


続きを読む
posted by keis at 18:39| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2006年08月26日

コントロールデータの設計

EDPシステムの環境適応力を高めるために、ある種の情報をプログラムコードの中に埋め込むことを避け、設定ファイルやデータベース上に保存することがある。システムパラメータとかコントロールデータと呼ばれるものだ。


続きを読む
posted by keis at 13:20| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2006年08月10日

業務システムモデリング練習帳

渡辺幸三さんの新著「業務システムモデリング練習帳」を読んだ。渡辺さんの本はいつも、理論だけでなく具体的なサンプルシステムを示しながら書かれているのが素晴らしい。「リアリティへの執着」は、システム作りの掟の第一だ。
僕としては、第6章の「家計管理システム」がとりわけ気に入った。単純な収支管理システムを作るつもりが、色々なユーザー要件をちゃんと反映していくと、ついには本格的な複式簿記システムに成長してしまうところが楽しめる。「残高口座(=B/S勘定)」と「費目(=P/L勘定)」を別のテーブルとして扱っているのもいい感じだ(両者は発生的には別の概念だったと思うし、僕が提案している増減複式簿記の出発点も、B/S勘定とP/L勘定は違うよね?というところにある)。タイトルどおりモデリングの練習帳としてももちろん読めるが、業務に対する洞察が伝わってくるのが素敵だ。

渡辺さんの提唱されている「三要素分析法」の説明もわかりやすかった。三要素分析法では、個々別々にイベント駆動される「業務単位」を識別した上で、業務単位間の関係は業務フローに、一個の業務単位内での一連の手順はアクションツリーに記述する。一般的な業務フローは、両者を同一レベルで記述しようとするからわかりにくいのだとおっしゃっていると理解した。最近の仕事で、フローチャート型の業務フロー図にがっくりする機会(?)があったので、これには説得された。

渡辺さん、お疲れ様でした。


posted by keis at 20:48| Comment(2) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2005年08月07日

分類集計コード

前回書いた「コード設計の話」でちょっとふれた「ロールアップコード」と「階層化コード」について補足しておきたい。両方とも細かい点を除けば同じ性格のものなので、ここでは「分類集計コード」と呼んでおく。
続きを読む
posted by keis at 15:20| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2005年07月28日

コード設計の話

今日は地味な話をしたい。といってもいつも地味な話だが。コードや区分の設計は良いシステムを設計するうえでとても大切である。設計にあたっては業務要件をみたすためにどんなコードや区分が必要かという視点が最初にくるのはもちろんだが、それ以外にも考慮すべきことがある。変なコード設計のもとでプログラムを書くと条件判定が複雑化し、読みにくく変更しにくいシステムができあがる。  ここで書くことは、経験のある設計者はたぶん(私のように)先輩から教わるとか自分で体得しているのもので目新しくはないが、まとめて整理してある本も意外にないようである(私が知らないだけかもしれない)。
続きを読む
posted by keis at 14:34| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする

2005年06月03日

アプリケーション設計のポイント−業務制約の発見

業務上のルールが変わったときには、アプリケーションシステムの処理内容を調整する必要が生じる。そのさいプログラムを手直しすることなくユーザ自身の手によりシステムを調整できた方が望ましいという場合は多い。パッケージソフトのように多数の企業に導入することが想定されているシステムにおいてだけではなく、単一の組織で使用されるシステムでも業務ルールが変わることはごく普通に想定される。開発期間や費用とのトレードオフに注意するのは当然であるが、アプリケーションシステムにフレキシビリティを盛り込むことは重要である。以上のことはシステム設計者の間で広く理解されていると思う。

一方で、十分に認識されていないかもしれないのは、フレキシビリティに制約を設けることの重要性である。たとえ開発にかかる期間や費用の問題をさておいても、アプリケーションシステムはフレキシブルであればあるほど良いというものではない。フレキシブルすぎるとシステムの設定変更手続きが複雑化してユーザの手に負えなくなる。フレキシビリティがかえって業務上の隘路をつくってしまう。事実上ほとんど変更されないような点についてはフレキシビリティを排除するとともに、本当にフレキシビリティが必要とされる機能についても、そのなかみに制約を設けることがだいじなのだ。

じっさい、業務条件が変わるといっても、その変更は一定の枠というか制約条件の中での変更であることが多い。たとえば、そこそこの規模の会社の決算業務では、ほぼ例外なく「配賦計算」というものがでてくる。簡単化して言うと、配賦計算とは単一の「配賦元」の数値を複数の「配賦先」に割り振ることである。たとえば、総務部で支払った本社ビルの賃借料を、そのビルに入居している各部門に対して使用床面積比で配分して負担させる、といったぐあいである。「配賦元」の金額をどう把握するか、配賦先を何にするか、配分比の元データとして何の数値を使用するか、配賦元と配賦先がループしたらどうするか、等々、配賦計算に関する可変要素は多い。会計パッケージを売ったことのある方なら、配賦機能の詳細についてお客さまから重箱の隅をつつくような質問攻めにあったことがあるかもしれない。有能なシステム設計者であればあるほど、いっそのこと、四則演算やら関数やらを使った計算式をユーザが自由に設定できるしくみを作ればどうか、といった思いに駆られる。そうすれば、すべてユーザまかせにできるではないか。

しかし配賦計算には配賦計算なりの制約条件がある。もっとも目立つ制約は、すべての配賦先に配賦された数値を合計すると配賦元のもともとの数値と一致しなければならない、という条件である。この制約条件を満たすためには、計算上で端数が発生した場合にはどこかの配賦先で調整することが必要だ。上述した「計算式をユーザが設定する」方法を採ると、端数調整のための計算式もユーザが書くことになるだろう。つまり、この場合、業務上の制約条件を満たす責任が、システムではなくユーザに委ねられていることになる。

考え方にもよるだろうが、私は、これはあまりほめられた責任分担ではないと思う。業務上変わることのない制約条件が存在するなら、それを満たす責任はシステムに負わせるべきではないだろうか。そうした見方に立つと、配賦計算において「計算式をユーザが設定する」という仕様は、フレキシビリティ過剰というべきだろう。業務において不変の制約はシステムが保証し、可変な要素はユーザに委ねる。こうした不変要素と可変要素の切り分けが、アプリケーションにフレキシビリティを持ち込む際に肝要だと思うのである。

業務における不変要素を見つける作業はアプリケーション設計の醍醐味でもある。不変要素はいつでも明らかなかたちで認識されているわけではない。何を不変要素とみるのかは、ユーザやアプリケーション設計者による業務理解そのものでもある。隠された不変要素を見つけ、すっきりとした仕様が得られたときの喜びは格別だ。

以上、アプリケーション設計者の立場から問題を眺めてきたが、ユーザの立場からみると、これは「何でもできます」という宣伝文句に動かされるのは危険だということだ。何でもできるというのは本当か?といった面もあるが、本当に何でもできたらかえって困る、ということもあるのだ。

posted by keis at 23:03| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。