H23午後2問2設問(4)

gawaさん  
(No.1)
入庫の関係スキーマの空欄v, w, yは、出庫番号と1対1のリレーションシップがあるので、出庫番号を外部キーとして登録する。
ここまでは理解できるのですが、解答例だと、入庫先拠点コードや部材番号も属性として書かれております。これらは、出庫エンティティの出庫先拠点コードと部材コードから導出可能な気がするので、わざわざ入庫エンティティの属性として定義するのは冗長に感じるのですが、どなたか解説いただけないでしょうか?
2022.08.14 16:07
GinSanaさん 
DB シルバーマイスター
(No.2)
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2011h23_1/2011h23tokubetsu_db_pm2_qs.pdf

P27(10)のルール
1対1のリレーションがある場合の外部キーは、後からインスタンスが発生する側に配置する

そうなると、入庫の方が後からインスタンスが発生するから、そっちに定義したのかな、とは
思いましたが、だったらなんで出庫にも書いた?ってなるんですが、どうも今から考えてもいまいちぴんとこない・・・

・・・ので、調べたらおんなじ疑問がありましたね。三好のPDF読んだときよりしっくりくる
okwave.jp/qa/q8032693.html
データベーススペシャリスト平成23年午後II問2| OKWAVE
(4)の関係スキーマを完成させる問題で、v、w、yの解答が腹に落ちません。
これらの解答では、”入庫元拠点コード”属性の代わりに外部キー”出庫番号”属性が入っています。
この場合、”出庫番号”属性があれば、”入庫元拠点コード”属性以外の”入庫拠点コード”、”部品部材番号”属性についても外部キーから参照できるため、不要とならないでしょうか。

ある解説によると、
「人為的なミスや不慮の事故などにより、出庫の記録と実績とが異なる場合がある。具体的に言うと、入庫拠点、対象部材、及び、入庫数である。実績を確認できるのは入庫の時点である。したがって、これらの属性を入庫側に持たせる必要がある。」
とありましたが、上記を想定するならば、”入庫元拠点コード”属性も入庫側にもたせる必要があると思うのですが…。

もやもやが晴れず、是非ご回答頂ければと思います。

入庫情報に"出庫番号"属性がある。
”入庫元拠点コード”属性は、"出庫番号"属性から参照できる。
しかし、解説にあるように
"出庫番号"属性から参照した"入庫拠点""対象部材""入庫数"の各属性は、
実際に入庫される時点で異なっている可能性があるので、
別途保持しないといけない。

というのは、配送先がxx倉庫のはずがxx営業所に持って言ってしまい、間違えたのはわかっているがいったん営業所在庫とする⇒"入庫拠点"が一致しない。
配送するときに入れ間違えたため"対象部材"が違っていた⇒"対象部材"が一致しない。
配送中に1個壊れてしまった。⇒"入庫数"が一致しない。
(壊れた処理を入庫側で行うなら一致させて壊れた処理をしてもいいのですが、出庫側で行うなら、
  一致させてはいけないです。出庫側で、1個出庫取り消しして不良品振り替えします。)
※入庫拠点の在庫を正しくしようと考えるので出庫と一致しない入庫を可能にしないといけないです。

一方で、"出庫番号"に対する”入庫元拠点コード”(つまりは、出庫した元拠点)は、
入力ミス以外にかわる可能性がないです。(入力ミスなら元を変えるだけ。)
ということで別途保持する必要はないです。
※出庫した拠点の情報は、入庫拠点の在庫に影響ないです。

2022.08.14 17:47
gawaさん  
(No.3)
なるほど、早速ありがとうございます。言われてみると、まぁそういうこともあるかな、という感じですが、他の年度の入庫・出庫の事例で、こういう考え方でスキーマ決めてる例を見たことないので、モヤモヤしますね。
2022.08.14 20:50
GinSanaさん 
DB シルバーマイスター
(No.4)
こういう倉庫の在庫記録は令和2年と平成27年(平成27年はやや特殊寄りな構成)くらい(※)ですが、たぶん23年の反省を踏まえたんだか、エンティティ構成が違和感ないんですよね。重複して持たなくなったというか
※午後2しか見てないけど、だいたいそんなもんかな・・・
2022.08.14 22:06

返信投稿用フォーム

スパム防止のためにスレッド作成日から30日経過したスレッドへの書込みはできません。

その他のスレッド


Pagetop