データベース大得意の方に質問します。

あなたの商品マスタの考え方を教えてください。このフィールドは必須だろ。
商品の内容に応じてテーブルは分けたほうがいい。いや全ての商品は一つのテーブルで管理した方がいいだろ。
とか何でもOKです。参考になるページや考え方を教えてください。

回答の条件
  • 1人2回まで
  • 登録:2006/06/20 16:53:03
  • 終了:2006/06/27 16:55:16

回答(5件)

id:SG5-NA No.1

SG5-NA回答回数18ベストアンサー獲得回数32006/06/20 18:24:35

ポイント20pt

この情報だけでテーブルを設計することはちょっと難しいので

私の場合のよく使うパターンを書きます。

☆テーブル名:商品マスタ

列1:SEQ(PrimaryKey)

列2:商品コード(Index;重複可)

列3:商品名

列4:なんとか区分

・・・

列X  :最新区分("0"or"1")

列X+1:削除フラグ

列X+2:登録年月日

列X+3:更新年月日

列X+4:削除年月日

マスタをこのような形で定義し、

ビューを組み合わせて使います。

☆ビュー名:商品マスタ_最新

列1:SEQ(PrimaryKey)

列2:商品コード(Index;重複可)

列3:商品名

where条件:最新区分=1かつ削除フラグ=0

☆ビュー名:商品マスタ_なんとか区分1

列1:SEQ(PrimaryKey)

列2:商品コード(Index;重複可)

列3:商品名

where条件:最新区分=1かつ削除フラグ=0かつなんとか区分=1

という感じで必要に応じてビューを作ります。

利点

・マスタが論理削除なので古いデータでもマスタ参照できる

・テーブルは1つだけ

欠点

・ビューの管理をきちんとしないといけない

ちなみにSEQ列は数値型がお勧めです

id:rizo

ありがとうございます。やはり倫理削除がいいですよね。大変参考になりました。

2006/06/20 20:57:33
id:maamaamaa No.2

maamaamaa回答回数266ベストアンサー獲得回数62006/06/20 18:32:10

ポイント20pt

商品がどの様なものかわかりませんが、商品マスタ関連で忘れがちなことを記載します。

(1)同一商品でも仕入先が複数ある(仕入価格も別)場合も考慮する。

(2)販売仕切価格も商品マスタに持たせる場合は、販売先によって別々の仕切設定を可能にする。

(3)商品の改廃が発生するので、その履歴が追える様に設計する。分析の場合、例えば前値(仕入値も仕切値も)が必要になることがあります。

(4)自社商品コードやJANコード等とは別に、仕入先(ベンダ)のコードも保持した方が良い。ルート品の場合は、販売先(顧客)で使用するコードも必要となることがあります。

id:rizo

仕入先や販売仕切・・・うーん奥が深いですね。

勉強になります。

2006/06/20 20:58:41
id:Ark-is No.3

Ark-is回答回数39ベストアンサー獲得回数02006/06/20 18:43:53

ポイント20pt

すみません。予め、3点質問させて下さい。


質問① 「商品マスタ」を使用するのはどういった機能においてなのか、まず確認させて下さい。

(製造工程管理/在庫管理/販売管理/会計管理など)

それとも統合システムなのでしょうか?

それにより、必須項目が異なってくることと思います。

(恐らく、この後の回答者にとっても)

それとも「品目マスタ」ではなく「商品マスタ」と呼ぶことで、販売管理のみに絞っておられるんでしょうか?


質問② また、日本語のみ対応(言語拡張の予定なし)か、多言語対応(英語など、今後拡張の予定あり)なのかも教えて下さると助かると思います。


質問③ 商品の件数(商品名の数)と、商品のバリエーション(大きさや鮮度、素材により取り扱い方法が異なるもの)の大体の数を教えて下さい。


ただ、共通で必要となるのは「商品コード」が主キーとなるという点かと思います。

その他の項目としては、用途(名称管理、製造/在庫/販売管理など)に応じて、補佐的なテーブルを作成することを前提として、それら補佐テーブルを効率的に検索するための「外部キー」を設定することをお勧めできます。


「商品名」を「商品マスタ」へ含めたいところですが、商品名称の変更、しかも「xxxx年xx月xx日から変更する」という要件が発生しうることを予想すると、「商品名称マスタ」として外出しにし、「商品名」と「使用開始日付」により管理した方が、厳密に管理できるという経験があります。

「製造単価」「販売価格」などの項目も、「商品名」と同様に管理できるでしょう。


この辺の発想の仕方については、下記の単語をキーワードに調べてみることをお勧めします。

「データベースの正規化」

「ER図(エンティティ-リレーション図)」

「DFD(データフローダイアグラム)」

id:rizo

回答ありがとうございます。

質問①

回答:販売管理にみに焦点をあてています。

質問②

回答:多言語対応の可能性あり

質問③

回答:商品数2000程度、商品には品物とサービスがあり。品物(例:パソコン)には数量や個数といった項目が必要。サービスには同一商品で年数が絡むものあり(例:サポート1年、サポート3年)。欲を言うとサポートに関しては、セレクトメニューで1年、3年・・・と選ばせたいのでその情報をどこに保存しておくか悩んでいます。まさか「サポート1年」から1年を取得するわけにもいかないので・・・

2006/06/20 21:07:19
id:nakunaru No.4

nakunaru回答回数4ベストアンサー獲得回数02006/06/20 20:36:55

ポイント20pt

情報が少なくてなんともいえない所があるのは上の方々と同じですが、販売管理系の場合、一般的には

・商品番号がキーとなる

・価格は商品マスタには持たせず、価格履歴テーブルに持たせる

・廃止商品は削除せず、削除フラグで管理する

あとは他の方が書いているように、もう少し情報があれば色々具体的なアドバイスが貰えるかと思います。

id:rizo

ありがとうございます。

価格は価格履歴ですか、受注明細などに持たせようと思っていたのですが、どちらがいいのでしょうか?悩みます・・・

2006/06/20 21:09:07
id:a98jed No.5

a98jed回答回数17ベストアンサー獲得回数12006/06/21 12:36:09

ポイント20pt

基本的にひとつのテーブルで管理すると

業務に変化があったときに対応がしづらいので

普通はテーブルを複数にわけ関連付ける方法をとります。

それを正規化といいます。

 

今回の場合

商品マスタを親にして

その他、仕入先や価格などを子にして

ぶら下げていきます。

 

使い方によりますが、実際使う場合には

VIEWを設定して、ひとつのマスタのように構成し、

それをつかって、

マスタの表示やメンテナンスに利用すると便利です。

 

マスタテーブルの一例

【・が付いているのはキー項目】

 

商品マスタ

 ・商品コード 

 ・有効開始日

  有効終了日

  商品種別

  販売単位

  最低販売数

  …

(有効開始~終了のかわりに、無効フラグで管理してもよい)

(商品種別はサービスと在庫品を区別したりする。)

 

 商品名称マスタ

 ・商品コード

 ・言語

 ・有効開始日

  有効終了日 

  商品名

(多言語のときは言語もキー項目にして作るといい)

(有効期間をキー項目にして管理すると期間を区切っての名称変更などに対応できる。)

 

 商品仕入先マスタ

 ・商品コード

 ・仕入先コード

 ・有効開始日

  有効終了日

  仕入先での商品コード

  …

(有効期間をキー項目にして管理すると仕入先商品コード変更などに対応できる。)

 

 価格マスタ

 ・商品コード

 ・販売先コード

 ・有効開始日

  有効終了日

  単価

  …

(有効期間をキー項目にして管理すると期間を区切った価格変更などに対応できる。)

 

もちろんこのほかに

仕入先、販売先(まとめて取引先としても良い)のマスタを登録しておく必要があります。


原則として

マスタのデータはテーブルからの物理削除はしないことです。

実績などを見る場合、過去分の伝票等に登録されている品目コードなどがもし削除されていたら、データが取れないか、エラーとなるでしょう。


価格はマスタより自動で取得し、初期値として受注伝票の明細にコピーを行い

それを上書き変更可能という方式をとると良いでしょう。


在庫テーブルは、マスタとは別に管理してください。

 ・場所

 ・品目

 ・状態(販売可能、出荷待、配送中、保留など)

  数量

  

状態の管理は重要です。

売っても良い商品と、資産としては自社のものだが売れない状態のものを区別するのに必要です。

ほんとは売る在庫がないのに受注したりといったことがなくなります。

サポートの期間や、保証の期間は

管理期間マスタなどを作成すればよいと思います。

管理期間マスタ

・品目コード

・子番号(期間の種類などの種別)

 期間の長さ

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません