HOME


流通工房について

各フェーズ定義


トピックについて

Link


サイトマップ

書籍・プロフィール

サイト内検索

-------------------------









流通業・流通システムにおけるシステム設計の実務ノウハウが満載−流通工房

<要件定義1(データ構造)>
伝票
<吉田君>
 現行システムのファイルを見ると不要な項目もあるようなので、新システムのテーブル
 項目からは削除します。あと現行システムでは伝票系のデータはヘッダーと明細に分か
 れているけどこれを統合できないか、また伝票ごとにファイルが分かれているけど似た
 ような項目が多いのでこれを共通テーブルとしてまとめられないかを検討しようと思います

<早瀬>
 不要な項目については情報システム部の石川さんに十分確認をして不要であれば削っても
 いいね。ただ、その後のデータ構造については賛成できないな

<吉田君>
 どうしてですか。似たような項目については共通テーブル化するほうが「正規化」できる
 と思うのですが

<早瀬>
 確かにテーブル設計の視点から考えるとそうだね。でも重要なことは今回作るのは業務の
 基幹系システムということだ。これはまた別の機会に詳しく話すけど私たちの作る基幹系
 システムは「開発してリリースする」時点が終了ではない。
 「システム」としては「リリース」が「スタート」でそれから、このシステムがこのHOT
 スーパーの業務をサポートする動脈として動き出すわけだ。

 そのためには「業務」も考慮してデータ構造もロジックも考えるようにしておく必要がある。
 そこを、テーブル論理設計の際の「データ構造」の視点だけで考えると複雑にもなるし、
 これから設計する業務ロジックとも相性が悪くなり、効率の悪いアクセスパスなどが発生する。

 「業務」は「ミスによる修正作業」や外部企業との連携による「外的要素」による影響で
 複雑に見えるが「業務」の基本は「紙」をベースにした2次元の世界であり、そこで表現
 されている文字や項目、そこからの判断しかなく本来はシンプルなものなんだ。

 例えば伝票では通常伝票は「黒字」で印刷されていて、修正伝票は「赤字」で印刷されて
 いて項目もほとんど同じだ。ただ、修正伝票にはその「理由」をチェックあるいは記入する
 欄が追加されている。データ構造もその伝票にある項目をベースに設計をしておくことで
 その伝票を使った業務に必要な項目が網羅されていることになる。
  
 これを似たような項目を共通テーブル化し、データ区分で分けるようにし、項目が異なる
 もののみを外だしするといった設計をすると、登録ロジックでデータ区分の登録ミスなどの
 バグの元となったり、システムリリース後の運用の中でデータ調査や修正をする時に、
 データを絞り込み、結合して参照しないと「伝票」データの全体が見えなくなったり、
 画面などからではなくデータパッチで直接データを修正しなければならなくなったときに
 本来修正すべきデータ以外にも修正をしてしまい2重障害となることもある
 
 よって、伝票についてはテーブルはそれぞれで用意をし、ヘッダーと明細のテーブル構造
 とし、データ項目はそれぞれの伝票に表されている項目、伝票にない判断材料となる情報
 項目のみを追加しておくといった設計とするようにした方が良いんだ


【ポイント】
「発注」「仕入」などについてはかなり電子データ化されてきているが、まだ物理的な「伝票」
でのやり取りをしているケースが多い。そのような場合は、データ構造もできる限り物理的な
構造に近づけておいた方がよい。その方が取引先からの伝票での確認があったり、データ不具合
があったときの調査、データ修正などの場合に、調査、対応が行いやすい

これがデータ設計的には綺麗な「正規化」「共通化」だとしても、物理的な情報のレイアウトと
乖離しすぎていると、物理的な情報をデータ構造に頭の中で変換するなどの作業が発生し、直感
的に作業ができなくなる。

このようなケースではデータ設計的には共通化されておりシンプルに見えるが、システムリリース
後の、顧客へのシステム保守、運用の引継ぎ段階で、顧客側からは「わかりづらい」「調査しづらい」
といったクレームとなることが多い。

データ構造を検討する上では「業務」の視点とあわせて、「システム稼動後のシステム運用」の
視点でも考える必要がある

※伝票のヘッダー、明細のデータ構造について
 取引先も含め「伝票」でのやり取りはほとんどなく、データのみでの やり取りで完結するの
 であれば、「ヘッダー」と「明細」といったデータ構造に分ける必要がないケースもある。
 基本的には最小単位は「単品」であり、単品での「発注」「納品」「入荷」といったオペレーション
 が可能となるからだ。
 これは顧客企業と取引先との力関係、取引先のシステム対応レベル、顧客企業と取引先を含めた
 システム方針などによるので顧客ごとに確認をするようにして下さい




質問 このトピックの情報は役立ちましたか?
役に立った
目的の情報と異なったが、参考になった
役に立たなかった

コメント




結果