2005年05月01日
H17午後I 問2設問2
H17午後I 問2
受注管理システムのデータベース設計
設問２（１）
テーブルの分割。いわゆるサービス問題
注文（注文番号，会員番号，注文日，注文受付日，商品番号，注文数量，取消しフラグ）
取消しフラグがヘッダにあるのか明細になるのか間違わないように。→『注文書の取消しは，注文書単位で行う。』
解答例：設問２（１）
注文（注文番号，会員番号，注文日，注文受付日，取消しフラグ）
注文明細（注文番号，商品番号，注文数量）
設問２（２）
不足している属性の補完。
図３の発送書から不足している属性をピックアップする。
・発送日
・発送番号
・発送数量 ・・・ 注文数量とは異なる。
・備考
・請求金額
このうち導出可能な請求金額は省く。
解答例：設問２（２）
注文：発送日，発送番号
注文明細：発送数量，備考
設問２（３）
一括発送に対応するため，既存の１つのテーブルの構造を変更し，新たにテーブルを一つ追加
現状，注文：発送＝１：１であるのを，多：１にすれば良い。
多側に発送番号を外部キーとして残し，発送を新たな別テーブルとする。
解答例：設問２（３）
変更： 注文（注文番号，会員番号，注文日，注文受付日，取消しフラグ，発送番号）
新規： 発送（発送番号，発送日）
この記事をLicWikiに埋め込む：
4 ：9：05/05/04 21:16:21 [RES]
>>3
ヅケよｍ９(´･∀･`)
> 注文書が、会員ごとと、勝手に判断してしまい
いやそれあり得んあり得ん(´･∀･)ﾉｼ 異なる会員に対して同じ注文番号を付与することがあるってこったろ？怖すぎｗ
注文書の主キーが注文番号なんて当たり前すぎるぞｍ９(･A･)
けどテーブル構造自体合ってるのなら部分点もあり得なくはないな(´･∀･)ﾉ
5 ：ＤＵＫＥ：05/05/04 21:52:15 [RES]
>>4 ：9
うん、そのとおりですね。馬鹿なことしてしまった。
設問２（２）は、ガッコさんの答えと同じだったと思うんだ。
設問２（３）は、アイテックが、導出属性の請求金額を
持たせているのが、気になるな？なぜ？
6 ：前スレ973：05/05/04 23:33:28 [RES]
設問2（2）
注文明細に足すのは、欠品フラグでもいいのかな？
欠品フラグが立っていれば、発送数量→0、備考→欠品(注文数量)と導出できるので。
で、俺、設問2（1）と（2）の部分なんて答えたか憶えてないんだけど、取り消しフラグを欠品の時に使うもんだと思って、注文明細に入れたような気がする。
だとすると、（2）はどう答えたんだ？＞俺
7 ：9：05/05/05 03:38:20 [RES]
>>5
アイテックのは普通にまちがえだろう
>>6
なんだよ欠品フラグって（ﾌﾟｹﾞﾗｗｗｗ
欠品なんて備考の一種だろ。そんな勝手なフラグ立てるのは危険だぞｍ９(´･A･`)
まあとりあえずそこは間違いなく間違えだなｗ
8 ：前スレ973：05/05/05 08:02:42 [RES]
>>7
いや、この設問の業務ルールなら、欠品フラグでも十分いけるぞ。したがって、正解。
と言いたいところだが、本当はなんて答えたんだろ？＞俺
9 ：g@kko：05/05/08 11:03:36 [RES]
>>2
それ，自分もやったよ。。。（遠い目）
今までの設問パターン（解答の書かせ方）が違うことにもっと留意が必要だったっす。
>>3
アイテック模試の場合，主キーの指摘の間違いは部分点ナシなんで，自己採点上は同様と考えていた方が良いかと。
>>5
＞設問２（３）は、アイテックが、導出属性の請求金額を
＞持たせているのが、気になるな？なぜ？
アイテックは対策本でも「導出属性を持たせるな」と書いているのに，他の問題の解答例では「導出属性を持たせたり」と一貫性がないんで，あんまり気にしていないです。
請求金額を導出できない理由がないので，持たせないのが正解と思われます。
>>6
＞注文明細に足すのは、欠品フラグでもいいのかな？
追加した属性の説明書きができないので，危険な気がします。
10個注文で5個欠品(5個発送)なんてことをしないので，要件的には問題ないと思います。
