概念モデルと論理モデルの違い（後編） - 設計者の発言
前編では、通常のデータ項目（値項目）に加えて「実体そのもの（実体項目）」を利用する点が、概念データモデルの特徴であると説明した。これによって「作為的なデータ項目」を持ち込まずに、管理対象をデータモデリングの俎上に置けるようになる。前編で説明した参照関係（モデル１）に続いて、もう少し例を見ていこう。 ＜モデル１＞（前編より再掲） 【社員管理表】[社員],社員名,生年月日,性別,... ＋ ￣￣￣ ｜ ① 山田 ... ｜ ② 鈴木 ... ｜ ③ 佐藤 ... ｜ └─…【活動履歴管理表】[活動履歴],[社員],[趣味],実施日,... ┌─… ￣￣￣￣￣ ｜ ⑥ ① ④ 9/11 ｜ ⑦ ③ ⑤ 9/12 ｜ ⑧ ① ④ 9/18
概念モデルと論理モデルの違い（前編） - 設計者の発言
管理会計システムの開発ツール「FusionPlace」の開発者であり会計士でもある杉本さんが、９月の「第19回関西IT勉強宴会」でたいへん興味深い発表をされた。それを聞いて、私の中で曖昧だった「概念データモデル」の位置づけがはっきりして、「論理データモデル」との違いが浮き彫りになった。この快適なスッキリ感をおすそわけしたい。 ■従来の「概念データモデル」の危うさ これまで「概念データモデル」という用語は「対象領域における重要なテーブルのみを示したデータモデル」くらいの意味で使われていた。１ページか２ページに収まるように重要なテーブルのみを置き、しばしばキーが省略された形で示される。一部を示すとたとえばこんな調子だ。 以前に書いた記事「危ういデータモデルを見破るコツ」で、概念データモデルと呼ばれる図面の上に「多対多」のテーブル関連が現れることを批判した。一部のテーブルを省略すれば必然的に「多
業務システム向けのデザインパターン - 設計者の発言
業務システム向けの有用なデザインパターンをいくつか紹介しよう。それらを設計上のイディオムとして覚えておけば、設計作業を効率化できる。 なお「デザインパターン」はもともとはクラス構造を設計するために広まったもので、IteratorやObserverといった数々の有用なイディオムが知られている。ところがそれらの知識は、業務システムのアプリを設計する場合にはほとんど役に立たない。なぜなら業務システム設計において問題になるのは、(1)どのようなDB構造に対する処理か、(2)どのようなUIをともなう処理であるか、の２点だからだ。 言い換えると、業務システムのアプリを設計する際に「クラス構造」を考える必要にせまられているとすれば、設計・開発環境による支援がショボ過ぎる。まるで、受注生産の工作機械を設計するときにボルトやネジの設計から始めているようなものだ。上述した２点の設計要素さえ押さえれば（それだけ
「印刷物を眺めながらの仕事」の衰退と罪深さ - 設計者の発言
かつて、業務システムには数多くの「帳票プログラム」が含まれていて、見積精度を損なう要因となっていた。開発に入ってから、さまざまな帳票プログラムをあらたに開発する必要が生じて話がこじれがちだった。年に数度しか使わない帳票とか、誰も必要性を理解できない帳票とかを求められたものだ。もちろん喜んで作った（追加工数をもらえる限りは）。 時は流れ、業務システムに含まれる帳票プログラムはすっかり減ってしまった。ＥＸＣＥＬに明細データを流し込むような仕組みさえ作れば、ユーザ自身がディスプレイ上で自由にソートや集計して眺められるようになったからだ。また、ＢＩのような集計・分析用ソフトウエアも普及した。かつてのように「さまざまな切り口での集計状況を眺めるための帳票」を個々にプログラミングする必要はなくなった。 今でも残っている帳票プログラムは、出荷指示書や実棚調査表、それに請求書といった特殊用途向けのものだ。
成果物のサイズとシステムの保守性 - 設計者の発言
「ＣＯＮＣＥＰＴＷＡＲＥ／販売管理」として公開している卸売業向け販売管理システムの基本設計情報ファイル(SalesOrosi.xead)のサイズは、１．８ＭＢである。 システムの規模感としては、テーブル定義が６８個、機能定義が２８０個、業務定義が６０個。これは小～中規模の業務システムに相当するが、機能設計書、ＤＢ設計書、ＥＲ図、業務マニュアル、データフロー図までを含めてのサイズなので、かなり小さい。それは、基本設計書を書くための専用エディタ(XEAD Modeler)を使って書いたからだ。ＥＸＣＥＬ方眼紙あたりを使えば５０ＭＢは下らないだろう。 そして、この基本設計書に沿って作られた詳細設計書(SalesOrosi.xeaf)のサイズは１．５ＭＢである。その実体はＸＭＬセグメントとJavaScriptコードがまとまったテキストファイルなのだが、この小ささで済んでいるのも、詳細設計書（仕様書
危ういデータモデルを見破るコツ - 設計者の発言
ひところよりもデータモデル（ＥＲ図）を作成することの重要性が理解されるようになったが、それでも形だけ整えられて納品されてしまうことがある。「納品しろと言われたからしかたなく作った」ようなモデルはヤバい。素人のイラストにもとづいて高層ビルを建てるような無茶を避けるために、危ういモデルを事前に見破るコツを知っておこう。 ただし、データモデルの「意味的な正しさ」は個別の問題なので立ち入らない。ここではその「見かけ」から危ういモデルを見破るための３つのポイントを紹介しよう。「キー設計が甘い」、「多対多を含んでいる」、「他の設計要素を支えない」といった兆候があれば注意したほうがいい。それぞれを説明しよう。 １．キー設計が甘い データモデルはデータ項目間の「関数従属性」と「ドメイン制約」を示すための図面である。それゆえに、キー属性がいい加減に設計されたモデルは役にたたない。キーはテーブルの存在証明のよ
「有効期間」を含むテーブルとの参照関係 - 設計者の発言
一次識別子に「有効期間」が含まれることがある。そんなテーブルに対して関連を張ってゆくと正規化違反を生じてしまうケースがある。これを避けるためには「動的参照関係」の知識と、これに対応した開発基盤が必要だ。よほど単純なＤＢでない限り「動的参照関係」のデータ要件は出現するものなので、実務者としてはしっかり理解しておきたい。 まず、有効期間とキーとの関わりを整理しておこう。「商品値引テーブル」を例にした場合のモデリングパターンをいくつか挙げよう。{...}内はキー（一次識別子）を表している。 (1)開始日・終了日ともに属性 [商品] {商品ID},商品名,... ＋ 12345 全自動漬物石ＴＳ１００ ｜ └―…[商品値引] {商品値引ID},商品ID,開始日,終了日,値引率,... 000001 12345 07/01 08/31 15 000002 12345 08/01 09/30
在庫引当から在庫推移へ（前編） - 設計者の発言
在庫管理分野でのデータ項目として「有効在庫（利用可能在庫）」と呼ばれるものがある。現在庫数量から「直近の出荷予定数量」を差し引いて得られる値を、事実上利用可能な在庫数量とみなして管理する。現在庫には直近の出荷予定が「引当」されていると考えるわけだ。式で表せば次のようになる。 有効在庫数量＝現在庫数量－Σ(直近の出庫予定数量) 現在庫が１００個だとして、直近での出荷予定が合計７０個だとすれば、有効在庫は３０個である。この時点で５０個の注文があったとする。有効在庫が３０個であることを知っていれば、すぐに出荷できる分３０個と、将来の入荷後に出荷できる分２０個とを分けて受注するといった事前の交渉が可能だ。いっぽう有効在庫を認識していないとすれば、すぐに出荷できる受注として５０個分をひとまとまりとして受け付けてしまうだろう。結果的に、出荷時点で欠品に気づいてあわてるハメになる。 在庫数量が規定レベル
業務マニュアルの作り方 - 設計者の発言
業務マニュアルをまとめるのは想像以上にやっかいな仕事である。とくに、コンピュータを用いて進める業務の場合、パネルや帳票（これらを合わせて入出力フォームと呼んでおく）の使い方を盛り込む必要があるのでややこしい。仕事の手順の軸、入出力フォームに関する説明の軸、および各手順における入出力フォームの使い方の軸とが複雑に交錯する。コンピュータ上の業務システムの仕様を巻き込んで周到に構造化しない限り、使いやすく保守しやすい業務マニュアルは生まれない。 ◆業務フローと業務マニュアル そもそも業務マニュアルとは何か。それはいわゆる「業務フロー」とはどう違うのか。まず、筆者が提唱する三要素分析法での、業務フローと業務マニュアルの位置づけを確認しておく。データフローダイアグラム（ＤＦＤ）で描かれた業務フローには、いくつかの「業務プロセス（個々の仕事の単位のこと）」が載っているが、それぞれの業務プロセスのあり方
システムの論理設計を構造化するための視点 - 設計者の発言
業務システムの論理設計を構造化するためのさまざまな視点がある。それらの意味合いを区別しないままに設計情報を漫然と眺めるだけでは、読み手として重要な項目を読み落とすし、設計者として複雑膨大な設計情報を「分割して統治」することにも失敗する。 「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」をとりあげて、システムのあり方を眺めるためのいろいろな視点を見てみよう。 ◆業務フローの視点で眺める ＸＥＡＤにおいてシステム定義は、ツリービュー上の「業務フロー」、「職種別担当業務」、「サーバーモジュール」の３つのまとまりとして示される。ひとつめのまとまりの「業務フロー」の下位には、「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」では「現預金口座管理の流れ」、「手形管理の流れ」、「売上収益回収の流れ」といった１６個の要素（ノード）が並んでいる。それぞれのノードを選択すると、データフローダイアグラム（ＤＦＤ）でまとめられた「業務（後
ユーザがなかなか仕様を決めてくれないって？ - 設計者の発言
「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。検討の過程で明確にされたいくつかの選択肢があって、ユーザに決断力がないゆえに決めきれていないとすれば、確かに困ったものだと思う。しかし「ユーザがどんなシステムにしたいかをなかなか明確に語ってくれない」といったレベルの悩みなのであれば、問題はどちらかといえば設計者の側にある。 ◆デートの過ごし方を決める過程 休日のデートの過ごし方に関して男性から尋ねられて、事細かに意向を説明してくれる女性はどちらかといえば少ない。たいていは「うーん、いい景色を見て、なにか美味しいものを何か食べたいな」なんて曖昧な答えが返ってくる。そのときに彼は「イイケシキだのナニカオイシイモノなんて曖昧な言い方をされてもわからない。もっと具体的に説明してくれないか」なんて言うだろうか。 そんなことを言う男がいるとすれば、彼女のいぶかる様子に気づくこと
分析設計手法のスタイルとオフショアの脅威 - 設計者の発言
顧客との打合せの場でどんどんモデリングするやり方を「その場方式」と筆者は呼んでいる。いっぽう、ユーザからヒアリングしたことをメモして持ち帰って机上でモデリングして、次回の打合せでその結果を示して検討するやり方を「持ち帰り方式」と呼んでいる。「持ち帰り方式」で対応できる案件も一定の比率で存在するので、そればかりを受注できる職場にいるのなら「その場方式」を身につける必要はない。しかし、「持ち帰り方式」の実践者はオフショアの脅威にさらされていることを知っておいたほうがいい。 ◆スクラッチ案件とリプレース案件 「持ち帰り方式」が有効なのは、メインフレームのオープン化プロジェクトを典型とする「リプレース案件」だ。顧客の生の声よりも、既存のコンピュータ内部のあり方をじっくり調査することで新システムを構想できる。もともと使っていたシステムが使いやすいものだったのであれば、新システムは「建材の刷新された住
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
生産管理システムのレファレンスモデル近日公開 - 設計者の発言
在庫引当から在庫推移へ（後編） - 設計者の発言