データベース設計について

Question

追記
不適切な質問でした。申し訳ございません。削除できないので図等を削除してこのまま残します。

前提・実現したいこと

前提
自社製品や自社型はなく、顧客からの依頼で顧客専用の製品を作ります。
生産は完全受注生産で客先から指定された本数を作って納品します。

受注の基本的な流れは2パターンです

• 新規の製品の場合

サンプル作成→製品仕様決定→注文が出る

• リピート生産

顧客から製品番号と本数で注文がでる

現状(エクセル管理)
エクセルに製品一覧シートと注文一覧シートがあります。
製品新規の場合、製品仕様が確定後、製品一覧に登録(製品番号が振られる)→注文一覧に本数と製品番号を登録(注文番号が振られる)
製品既存の場合、注文一覧に本数と製品番号を登録
工場番号と注文番号を社員が認識しています。

作成したいシステムにアクセスするのは最大7名です。
注文は新規リピート合計10~20件です。

実現したいこと

• 月別売上げの作成

サンプル段階の未確定な売上と正式受注している売上を合わせた売上予測を月ごとに集計する
(サンプル段階でどの程度の金額を想定しているかは顧客から提示されます)

• 納品本数を注文ごとに集計する

(不良品が5%くらい毎回出ます)

データベース設計で考えたこと

パターン1：現状に即したテーブル設計-サンプルテーブル 製品テーブル 注文テーブル　集計テーブル…)
現在のエクセルの構成にサンプルテーブルを追加した形

メリット

• 注文NOが主キーなので、納品のSQLが簡単そう

デメリット

• 売上げ集計がやや面倒

　(月別売上げはサンプルテーブルの予測売上と注文テーブルの売上を結合して集計する)

パターン2:商談テーブル(サンプルと注文を一緒にしたテーブル)　製品テーブル 集計テーブル…

メリット

• 売上げが集計しやすい
• テーブルが1つ減るのでデータがシンプルになる

デメリット

• 注文NOを後からふる, 追加で入力する項目が増えるので、更新きちんと考えないといけなさそう
• 進捗の区分けが増える
• 注文一覧が必要な場合、WHEREで常に指定しないといけない 中間テーブルを作る？
• 納品テーブルを作っていったときに、主キーの商談IDでリレーションを考えた場合、SQLが面倒になりハードルが高そう
• 主キーではない注文NOを参照に使っていると後々エラーが起こりそう

パターン3：パターン２の商談Tのフィールドを細かくする
サンプルの予測売上と注文の売上のフィールドを分ける
進捗もサンプルと注文でフィールドを分ける

メリット

• 進捗の区分けが減るくらい

デメリット

• NULLが増える
• かえって月別売上集計が複雑になる

伺いたいこと

1. どんなテーブル設計にしようと思われるかご意見を伺いたいです。
2. パターン２か３にした場合、T納品でT製品を参照するための外部キーは注文Noにしてもいいのでしょうか？
3. これだけ別件なのですが、顧客はよく使うので、すべてのテーブルに顧客IDいれてますが、顧客名も入れるのはいけないのでしょうか？

　 中間テーブルで対応されるのでしょうか？

補足情報（FW/ツールのバージョンなど）

今のところすべてエクセルで行っています。エクセルのシートをテーブルとして、エクセルでSQL実行しています。
今後おそらくはACCESSを1アカウントだけ買ってもらって、社内フォルダにファイルを置き、エクセルから実行する形になるかと思います。
サーバー用にパソコン用意したほうがいいなどあるとは思いますが、そこらへんはまた別でご相談させていただければと思います。
とりあえずどんな事ができるのかをプレゼンできるようにし、予算を確保したいです。

どうぞよろしくお願い致します。

Comments

[m.ts10806]

>顧客からの依頼で顧客専用の製品を作ります。

でしたら、無料の厚意の無責任な他人にアドバイスを求めるのは間違っています。
きちんと責任負える相手にそれなりの対価を支払ってコンサルしてもらってください

[gentaro]

> サーバー用にパソコン用意したほうがいいなどあるとは思いますが、そこらへんはまた別でご相談させていただければと思います。
> とりあえずどんな事ができるのかをプレゼンできるようにし、予算を確保したいです。

なんか他人に「自分の仕事を代わりにやってくれ」「俺の仕事をタダで手伝ってくれ」って言ってるに等しいように見えるんで、自分でできないなら金払って人雇えよ、と思うわな。

業務システムを設計する知識ってのは、プロならそれこそ「飯のタネ」なんで、あなたがプロならその価値ぐらいわかるはずだし、逆にあなたに頼めば無償で働いてくれるのか？と訊ねたい。

質問内容はともかく、スタンスが気にいらねー。

[退会済みユーザー]

生産管理システムとか受注生産システムとか、お金さえあれば既成のシステムを導入したほうがいいんですけどね。大塚商会とか持ってなかったっけ。アラジンオフィスでもいいような気もしますけども。

[bors]

m.ts10806様
無料で利用しようとして、申し訳ございませんでした。
gentaro様
以前同じようにエクセルのみ使用と言った際に、サーバーたてたほうがいいというコメントを頂いたので、同様のご指摘があるだろうなと思ったので、先に言及してしまいました。また、ほかの方からご指摘受けてますが、ここでご相談するべきではないことでした。申し訳ありません。
ただの事務員が独学で勉強しただけなので、価値がわかっていませんでした。不快な思いをさせて申し訳ありませんでした。
gentaro様
零細企業のため、費用がかけれません。それで自分でできればと思ったのですが自分が考えているよりだいぶ大ごとな気がします。コメントありがとうございました。

[m.ts10806]

＞零細企業のため、費用がかけれません
誰がしようとコストはかかってるので、専門知識も経験もない状態で下手に自身で合間にやるより
専門家にやってもらったほうが確実で安く済みます。
ですから、IT企業でも総務系の業務ソフトは信頼も実績もある既存製品を使うのです。

[68user]

teratail で仕事に関する質問をしてはいけないというルールがあるんでしたっけ。

[K_3578]

＠68userさん
推奨していない質問に仕事に関する質問をしてはいけないとは書いてないですけど、
モラル的に考えて顧客の依頼に協力してくれって言うのは無償の善意で成り立っている場で質問するべき
事ではない、ということかと思います。

それと、仮にここから具体案なんかが出て、それを参考に質問者が物を作り上げた場合
不特定多数の場で顧客の依頼情報を公開したとして責任問題になっても知らないぞって事ですかね。

Answer 1

多数のご指摘を受けたため、回答を削除させて頂きました。

Comments

[bors]

ご返答遅くなって申し訳ございません。ご回答いただきありがとうございます。
サンプルは顧客の商品ですので、売ることはありません。
ご指摘の通りサンプル制作は1回ではありません。ただ仮の売り上げを把握するためだけに、サンプルテーブルを作りました。
サンプル制作に4か月程度かかるため、新規とリピートを一緒のテーブルにして、注文Noをふると、注文番号順に並べた時に、納期がバラバラになるため、それなら最初から分けたほうがいいのかなと思った次第です。

[causal.effect]

コメント削除

[causal.effect]

コメント削除

[m.ts10806]

むしろ業務の内容を全世界からアクセスできる場所に公開するのは企業としての危機すらあり得ますけどね。
場合によってはコード公開するよりマズいんでは。

[bors]

causal.effect様
うまく伝えられず申し訳ございません。ご回答ありがとうございました。

[bors]

m.ts10806様
このコメント後にしばらくしたら削除致します。

[m.ts10806]

質問を編集したとしても、編集履歴から確認可能ですよ。
「投稿の削除ポリシー」のページにあるように回答がついた質問は「直接は」削除できません。
運営に相談してください。

[bors]

度々すいません。削除できないので、空白にするのもよくないと思い、図だけの削除しました。
申し訳ございません。

[m.ts10806]

解決してしまったからもっと削除されにくくなった。
まぁ運営に相談してくださいね。内容次第では文言の置き換えやサーバー上から画像削除してもらえるかもしれませんが、すぐに対応してもらえるとは限りません。ご自身のリテラシーから出てしまったことだとも言えますしね。

[bors]

m.ts10806様
運営に削除依頼をメールを致しました。
causal.effect様
巻き込んでしまい申し訳ございません。

Answer 2

どんなテーブル設計にしようと思われるかご意見を伺いたいです。

• 業務分析とモデリングを適切に行って設計をする
• 第三正規形までは確実に正規化を行う

ですが、おそらくは隠れている要件もあるでしょうから「どんなテーブル設計にしようと思われるか」と言われても難しいです。

そのあたりが絞り込めない様であれば、
実際にSQLを組んでみて機能が成立するくらいまではご自身で試してみるのが良いかと思いますよ。

現状だと、「設計のレビューをして下さい」みたいな質問と捉えられても仕方ない状況に思います。

パターン２か３にした場合、T納品でT製品を参照するための外部キーは注文Noにしてもいいのでしょうか？

「いいのでしょうか？」と言うのが、質問の意図が分からないのですが、実際に組んでみると良いと思います。

これだけ別件なのですが、顧客はよく使うので、すべてのテーブルに顧客IDいれてますが、顧客名も入れるのはいけないのでしょうか？
中間テーブルで対応されるのでしょうか？

各テーブルの性質次第です。
顧客テーブルと直接紐づいている必要があるのであれば必要ですし、「他のテーブルの子要素なので親要素を辿れば顧客にたどり着くが、めんどくさいので入れておく」であれば更新が面倒になったりするのでやらない方が良いです。
この辺も、一旦可能な限り理論的に説明できる形でモデリングをしてから、明確な理由を持てるところに限って設計を崩していく　という形にするのが良いです。

今のところすべてエクセルで行っています。エクセルのシートをテーブルとして、エクセルでSQL実行しています。
今後おそらくはACCESSを1アカウントだけ買ってもらって、社内フォルダにファイルを置き、エクセルから実行する形になるかと思います。
サーバー用にパソコン用意したほうがいいなどあるとは思いますが、そこらへんはまた別でご相談させていただければと思います。
とりあえずどんな事ができるのかをプレゼンできるようにし、予算を確保したいです。

さすがにこの辺はteratailの範囲内とは思えないので、別のところで相談された方が良いです。

Comments

[bors]

ご回答頂きありがとうございます。
>SQLを組んでみて機能が成立するくらいまではご自身で試してみるのが良いかと思います
実際パターン１である程度作って動くとこまで行っているのですが、2のほうが楽じゃないかと思い始め、試してみる前に聞いてしまいました。外部キーは主キーでしかリレーションを組んだことがなかったので漠然と不安になって聞いてしまいました。実際にやってみます。
>他のテーブルの子要素なので親要素を辿れば顧客にたどり着くが、めんどくさいので入れておく
この考えだったので正規形を守れるようにコードを書けるようにします。
サーバーの件は申し分けございませんでした。ご回答いただきありがとうございます。

[tanat]

> 実際パターン１である程度作って動くとこまで行っているのですが、2のほうが楽じゃないかと思い始め、試してみる前に聞いてしまいました。

なるほど。
それでパターン2が1に比べるとやけにふわっとしてたのですね。

そういう意味ではSQLアンチパターン　という書籍がとても参考になるので、一度読まれてみるといいと思います。
(基本的には)避けた方が良い設計が紹介されている名著です。

[bors]

アドバイスありがとうございます。アンチパターン購入します！！

[退会済みユーザー]

業務分析の問題な気がするから、SQL アンチパターンなやつの一歩手前の学習がいるんじゃないかなぁ。。。

ところで、この規模のモノって内製するもんなの？
パット見て未経験者にはしんどそうに見えたんですけど。