Q&A
Rel_01が違うのです
発注先（販売店）と商品は「多対多」の関係（ある販売店はさまざまな商品を売っている／ある商品はさまざまな販売店で売られている）なので、商品から発注先をたどることはできません
前提・実現したいこと
現在、企業の発注履歴（どういうものを購入したか）を管理するデータベースをPostgreSQLで作成しております。
発注情報として、「商品」「発注先」「（その発注先における）担当者」があります（実際はもっと項目は多いですが）。
次のイメージです。
| 発注ID | 商品 | 発注先 | 担当者 |
|---|---|---|---|
| 1 | ペン | 文具屋 | 鈴木 |
| 2 | 枕 | 寝具屋 | 佐藤 |
| 3 | マウス | 電気屋 | |
| 4 | 鉛筆 | 文具屋 | 佐藤 |
| 5 | 消しゴム | 文具屋 | |
| 6 | ペン | なんでも屋 |
注文2の担当者である「寝具屋の佐藤」と、注文4の担当者である「文具屋の佐藤」は、名前が同じだけの別人です。また、担当者は空欄（不明）であることもあります（実際は、半分以上が空欄です）。
そこで、次のようにテーブルを作成しました。
商品テーブル↓
| id | 名前 |
|---|---|
| 1 | ペン |
| 2 | 枕 |
| 3 | マウス |
| 4 | 鉛筆 |
| 5 | 消しゴム |
発注先テーブル↓
| id | 名前 |
|---|---|
| 1 | 文具屋 |
| 2 | 寝具屋 |
| 3 | 電気屋 |
| 4 | なんでも屋 |
担当者テーブル↓
| id | 所属（発注先） | 名前 |
|---|---|---|
| 1 | 1 | 鈴木 |
| 2 | 1 | 佐藤 |
| 3 | 2 | 佐藤 |
発注テーブル↓
| 発注ID | 商品 | 発注先 | 担当者 |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 2 | 2 | 2 | 3 |
| 3 | 3 | 3 | 0 |
| 4 | 4 | 1 | 2 |
| 5 | 5 | 1 | 0 |
| 6 | 1 | 4 | 0 |
これらを結合すれば、冒頭の表を表現することができます。
発生している問題
問題としては、発注テーブルに、「発注先2、担当者1」といった、存在しない「発注先と担当者の組」を入力できてしまうことです。プログラム側ではもちろんチェックをしますが、データベース側でも制約を設けたいです。そもそもデータが冗長になっているので、うまい設計方法や、そのためのヒントをご教示いただけると幸いです。
調べたこと
CHECK制約→制約の中で他のテーブルを参照する方法がわからず断念
外部キー制約→複数の列に対して設定する方法がわからず断念
回答5件
0
発注先の人事を管理するわけじゃないんですから、発注先テーブルに担当者のカラムを持つべきです。
発注先の電話番号等と同じような、属性情報として扱わないと面倒です。
発注テーブルに発注先の担当者を持たせたいなら、発注先を選択時に発注先のテーブルから取得して初期値として設定し、変更可能にしておくとかじゃないでしょうか。
投稿2019/02/28 07:26
編集2019/02/28 08:02
総合スコア25195
0
こちらの方がイメージに近いのかな、と思い、書き直してみました。
投稿2019/03/02 06:13
総合スコア50
えっと、すみません。恐らく、質問者様の捉えている意味での商品、はこのERDでは品物に該当します。言葉の定義が曖昧ですみません。このERD内での商品テーブルは、if_発注先_商品としても良いかもしれません。
0
これで良いのではと思います。
発注先を指定したければ、担当者または商品の親テーブルをJOINすればいい、という作りです。
担当者が不明でない場合、商品と担当者の親の発注先IDが一致しなければ、はじく、という形で解決かと。
投稿2019/03/01 11:19
編集2019/03/01 11:23総合スコア50
「商品」が「発注先」を持つということでしょうか？
表の通り、「ペン」は「文具屋」でも「なんでも屋」でも買うことがあるので、それでは問題があるのです
誤読していたら申し訳ないです
同じペンでも、A社のペン、B社のペン、とあると思います。
M_商品のテーブルでは、どの会社のどの商品なのか、を商品idにより管理します。
ペン、という商品で集計を取る場合は、GROUP BY 商品名や、WHERE 商品名='ペン'などで絞れば、この作りで対応できると思います。
何が問題なのか、イマイチ把握できなかったので、回答になっていなかったらすみません。
「発注先」というのは「メーカー」ではありません（メーカーの列は、商品テーブルには存在します）。
「東急ハンズで買ったパイロットのペン」と「Amazonで買ったパイロットのペン」は同じ商品として管理します。
もちろん、「東急ハンズで買ったパイロットのペン」と「東急ハンズで買ったゼブラのペン」は違う商品です。
例として上げた発注テーブルの、ID1とID6を見比べていただければ。
ご説明ありがとうございます。
そうしましたら、名称はともかく、構造としては、先ほど、別途回答させていただきましたので、そちらの設計をすると良いかと思います。
要件がわからないので、何とも言えませんが、最終形として、最初の質問欄にある発注テーブルのような形を出す必要があるのであれば、私の先ほどの回答の図にある、T_発注、M_商品、M_品物を親をたどっていく形でJOINしたVIEWまたはテーブルを表示用に別途作成すると良いと思います。
私が提示しているのは、あくまで、論理の設計のみなので、物理のレベルでは、これらをくっつけたりして、作成し、管理と表示は分ける、という形を取るのがスマートかなと思います。
0
担当者テーブルの名前欄にNULLを許容して、すべての「発注先 - 担当者NULL」の組み合わせを登録、それから発注テーブルには担当者のみ登録して発注先を外す、という方策はどうでしょうか。
投稿2019/02/28 07:04
総合スコア145184
そうですね。
確かにあり得る方法だと思います。
ただ、そうすると、「商品：大根、発注先：八百屋、担当者：田中」のデータを挿入するときのフローは次のようになりますよね。
①商品テーブルに「大根」を追加
②発注先テーブルに「八百屋」を追加
③担当者テーブルに「八百屋、NULL」を追加
④担当者テーブルに「八百屋、田中」を追加
⑤発注テーブルに追加
……複雑になって大変だと思ったけど、整理してみると③が増えてるだけだからアリですね
検討してみます！
……と思いましたが、「発注」に対して本質的な「発注先」を外してしまうのは良くない気がしてきました
saziさんご指摘の通り、「担当者」の重要度が一段下がるのは間違いないので
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/02/28 07:30
2019/02/28 07:32
2019/02/28 07:39 編集
2019/03/01 01:01
2019/03/02 05:46
2019/03/02 06:52 編集
2019/03/02 06:42