HOME


流通工房について

各フェーズ定義


トピックについて

Link


KeyWordランキング

サイトマップ

書籍・プロフィール

サイト内検索

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









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

<要件定義1(データ構造)>
【商品マスタ
<吉田君>
 商品マスタは商品マスタの他、店別商品マスタや取引先別商品マスタなどがありますね。
 流通業のシステムにおいて商品マスタ関連は非常に重要と聞いたのですが、データ設計
 およびマスタメンテナンス画面の留意点を教えて下さい

<早瀬>
 必ず商品マスタと店別商品マスタは必要だね。取引先別商品マスタは管理するデータ項目、
 企業により作成したり作成しなかったりする。一応商品マスタ関連のそれぞれのマスタの特徴
 は下記に記載しておいた。

 それから、画面設計においてはまず項目ごとに登録部署を確認しておくことが重要だ。
 ついマスタメンテナンス画面はそれぞれのマスタごとにメンテナンス画面を作成しがちだが、
 商品マスタについては登録する部署ごとに必要項目をまとめた画面としておく方がよい。
 これは当然登録する部署ごとに画面でのデータ登録が完結するようにするためだ。それに
 その登録部署で決められない項目がさらに「登録必須項目」だったとしたら「必須項目未入力」
 でデータ登録が出来なくなってしまうね。

 なお、初期登録の場合は1つの部署で商品マスタ、店別商品マスタ、取引先別商品マスタに
 ついての登録を一連の作業で行うことが多いので、それぞれ「商品マスタ登録画面」、「店別
 商品マスタ登録画面」とするのではなく、画面遷移の中でそれぞれの項目を登録できるように
 しておくと業務オペレーション上は使いやすいね。だからどの項目がどの部署で登録されるか、
 また、さらにはその部署でも登録タイミングが同じなのか、違うのか、登録順序はどのように
 なっているのかといったことを把握しておくことが重要なんだ


【ポイント】
ネーミングはそれぞれで決めてもらえばよいが、商品マスタ関連で基本的に必要となるマスタ群
を以下に記載しておきました

●商品マスタ
 商品コード(JAN、UPC、インストア含む)をKeyとして、商品名、規格名(それぞれ漢字、カナ双方)
 レシート品名、サイズ、色、メーカコード、標準売価、登録日、廃番日、ケース入数などの商品
 の属性情報を管理するマスタ

●商品管理マスタ
 商品コードに商品分類を割り当てるマスタ
 商品に対する商品分類は変更されることがあるため、有効開始日、終了日を持った履歴構造と
 した方がよく、「商品管理マスタ」などとして商品マスタから外だしして管理するとよい

●商品取引条件マスタ
 商品に対する取引先、仕入原価、発注単位数など発注関連情報を管理するマスタ。
 こちらも有効期間を持った履歴構造としておくと良い
 また、1つの商品に対して取引先条件を複数登録、管理することが多い。
 これを正規化すると商品コード、取引先コードがkeyとなるがデータアクセスパフォーマンス、
 データメンテナンスなどの保守・運用の観点からは以下のように正規化を崩した形のテーブル
 構造にした方が良い

 <テーブル構造例>
 商品コード(key)
 取引先コード1
 仕入原価1
 取引先コード2
 仕入原価2
 仕入先コード3
 仕入原価3

 これは汎用機のファイル設計でよく見られる構造的であり、RDBのデータ設計上は正規化を崩す
 ことになるためよくもめるのだが、開発およびリリース後のデータメンテナンス、パフォーマンス
 チューニングを考えると私の経験上はこの形が良いと考えている

 (参考情報)
  テーブルの論理設計では完全に正規化した上で正規化を崩すパターン、大枠を作っておき正規化
  していくパターンなどいろいろあるが、「正規化を崩すかどうかの判断」の1つはそのテーブル
  自身および、そのテーブルと結合することが多いテーブルのデータ件数と結合時のパフォーマンス
  による。もし、データ件数が数百件〜数万件レベルの小規模のシステムの場合はあまり真剣に
  パフォーマンスを意識しなくても良いと考える

  ただ、仮に店舗で取り扱う商品が

  ・5万商品

  とした場合

  ・店舗ごとに取扱商品が一部異なる
  ・取扱いが終了した過去の商品などもデータ上は一定期間保持する

  ことなどで

  ・商品マスタだけで20万件くらい

  になることも多い。さらに取引条件が1商品あたり平均3件とすると

  ・正規化すると 20万件×3=60万件

  また、店別商品マスタ(店舗数×商品マスタ件数)や発注伝票データ、仕入伝票データ
  (これも規模によるが数百万件〜数千万件となることが多い)などとの結合を考えると
  あまり正規化しすぎるとテスト終盤で実件数がデータ移行された環境でテストした瞬間に
  パフォーマンス的に破綻することとなる

●取引先別商品マスタ
 取引先コード、商品コードをkeyにリードタイムや発注単位数、発注形態、納品形態、
 返品可否など取引先ごとの商品取扱条件を管理するマスタ

●店別商品マスタ
 店コード、商品コードをkeyに取引先、発注単位数、原価、売価、リードタイム、発注形態、
 納品形態、取扱状況など店舗における売価や発注制御関連情報を管理するマスタ。
 管理情報は変更されることがあるため有効期間をもった履歴構造としておく方が良い
 頻繁に条件が変更される項目がある場合は、その項目だけ外だしして管理することも検討する。
 だだ、履歴構造の複数のテーブルの結合はやはりパフォーマンスに影響するので、あまり分散
 して管理をしすぎないように注意すること



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

コメント




結果