2005年02月04日

[ テクニカルエンジニア(データベース)/H16 ]

H16午後I 問2

H16午後I 問2
設問1(3)
iTAC@解答例速報掲示板より

午後1 問2 設問1(3) 投稿者:MyVitzRs 投稿日:4/18 22:38:05

解答例を基準にして、、、、
「実施年月」は、プロモーションIDにより一意に識別できるため、月別プロモーション別
商品売上集計テーブルに入れるのは、冗長では?

よって、「売上個数(売上個数累計)」「売上金額(売上金額累計)」の2項目でOKだと思います。


午後1 問2 設問1(3) 投稿者:Gypsy 投稿日:4/18 23:17:38

"前月"と"今月"の集計結果として別個に格納しておくために
「実施年月」は必要なのではないでしょうか?
そのために'月別'プロモーション別商品売上集計テーブルと
月別であることを明記してるんだと思います。

ただ前月の結果も入れるので「実施年月」ではなくて
「年月」の方が正しそうな気がします。

(といいつつ実施年月と解答してしまいましたが、、、)


午後1 問2 設問1(3)  投稿者:Gan 投稿日:4/18 23:55:51

私も年月は冗長だと思ったので、
「売上個数(売上個数累計)」「売上金額(売上金額累計)」
のみとしました。



公式解答例は「年月」は入っている。
 素直に考えれば,設問で「月別プロモーション別商品売上集計テーブル」となっているので,当然,「年月」は入るものと思うんだが・・・

年月が無かった場合を考えてみる

 前月の時点では,プロモーション対象商品ではない(一つの商品が2か月続けてプロモーションの対象となることはない)ことから
プロモーションID→実施年月(当月) は求められるが
プロモーションID→前月 は,実施年月-1ヶ月しなければならない。だが,標準SQLでは日付関数がないため,求められない。

設問もおかしい!
 「月別プロモーション別商品売上集計テーブル」の名前から,素直に受け取れば,主キーは{年月,プロモーションID,商品コード}である。
 しかし,前月時点では対象商品はプロモーションの対象となっていないため,プロモーションIDがない。つまりは,主キーの一部がNULLになってしまい,集計が出来ない。
 ここでの主キーは{年月,商品コード}であり,プロモーションIDは外部キーである。
 ゆえに,テーブル名は「月別商品別売上集計テーブル」とすべきである。

Posted by g@kko at 2005/02/04 10:39 | 個別記事表示 | コメントを見る (6) |
この記事をLicWikiに埋め込む:
コメント
2 :おみおみ:05/03/04 23:26:06 [RES]

>情報処理のための掲示板が生きてれば、去年の問題のログに関してはそっちのほうがはるかに有益だったんだがな

http://johobbs.lib.net/
↑ここのことでしょうか?
私もかなりお世話になってたので復活を望んでるんですけど。

>しかし,前月時点では対象商品はプロモーションの対象となっていないため,プロモーションIDがない。つまりは,主キーの一部がNULLになってしまい,集計が出来ない。

私は、プロモーションは実施する数ヶ月前に設定しているのかなと思いました。特にそういう記述はないですが、そう考えればプロモーションIDも主キーにできますよね。



3 :g@kko:05/03/05 00:10:00 [RES]

>>2 :おみおみ

http://johobbs.lib.net/
は,COMAXのサブドメインコースだったみたいだね。。。
http://www.comax.jp/ja/gserver/sdomain.html

googleのキャッシュももう効いていないっぽいし残念ですなぁ。。。


>プロモーションは実施する数ヶ月前に設定・・・

もうちょっと書いている内容を補足します。
〔プロモーションの概要〕から前提を
 プロモーション対象商品.商品コードの商品は,(プロモーション.実施年月-1)の月に別のプロモーションのプロモーション対象商品.商品コードに存在しない。と,読みました。

 どういうことかというと,今月,プロモーション対象になっている商品は,前月はどのプロモーションの対象になってはいけない。

 ひっくりかえすと,前月のプロモーション対象商品は,今月,プロモーション対象商品にできない。と。

この条件で,図2の「ホットカーペット」のインスタンスを考えると

 月別プロモーション別商品売上集計(年月,プロモーションID,商品コード,売上個数,売上金額)

200403,00001,00003,40,1120000
200402,NULL ,00003,10,350000

になるのではと思ったんですが。。。どうでしょう?


4 :おみおみ:05/03/05 09:27:44 [RES]

おはようございます。

>月別プロモーション別商品売上集計(年月,プロモーションID,商品コード,売上個数,売上金額)

プロモーションの前提に関してはそのとおりです。
しかし、「年月」とは関係なく、"プロモーション対象商品"テーブルでプロモーションIDと商品コードの組合せが設定されていれば、以下のタプルを生成できるはずです。前月はプロモーションが実施されていませんが、{プロモーションID,商品コード}の関係は有効です。

200403,00001,00003,40,1120000
200402,00001,00003,10,350000
     ~~~~~~~

うまく説明できてるかどうかわかりませんが。


5 :g@kko:05/03/05 09:59:21 [RES]

>>4 :おみおみ さん
 なるほど。
 プロモーションの予定がきちんと入っている(未来の実施年月のプロモーションがある)ことは必要ですね。

 また,「毎日のバッチ処理」で処理対象とする期間と条件が明示されていませんので,おみおみさんの考え方もありだと思います。

蛇足ですが,前月末に突然,翌月プロモーション対象となる場合(競合他社に対抗してなど)を考慮すると,前月実績の再編集(プロモーションIDを付与)も検討しなければいけませんね。


6 :おみおみ:05/03/05 10:42:17 [RES]

>5
私の中では解決が出ました。

プロモーションが決まって、"プロモーション"テーブルと"プロモーション対象商品"のタプルを生成してから、該当する商品に対して"月別プロモーション別商品売上集計テーブル"のタプルを作成する。

1ヶ月以上前に決まっているプロモーションの処理については既に述べたとおり問題ありません。

前月中(たとえば2/20)に決まったプロモーションについては、決まってから"月別プロモーション別商品売上集計テーブル"のタプルを作り、そのときにその月の売上個数と売上金額を集計する(期間:2/1~2/20 or 2/19)。その後は日次のバッチ処理で更新する。

これならプロモーションIDがなくて主キーにできないという問題は発生しません。
そして合理的です。なぜなら"月別プロモーション別商品売上集計テーブル"にはプロモーションの対象となっている商品の実施年月、前月のデータしか必要ないからです。プロモーションが決まる前に集計テーブルを作成すると、不要なデータを集計してしまうおそれがあります。以下の記述はそういうこと(プロモーションの対象になるかどうか分からないけどとりあえず全商品の集計をしている)ですよね?違ってたらごめんなさい。

>蛇足ですが,前月末に突然,翌月プロモーション対象となる場合(競合他社に対抗してなど)を考慮すると,前月実績の再編集(プロモーションIDを付与)も検討しなければいけませんね。


7 :g@kko:05/03/05 13:10:22 [RES]

>>6 :おみおみ さん
 おみおみさんの解釈のとおりです。

 ようは,「毎日のバッチ処理」が何をしているのか
 再集計するのか/再集計しないのか。と,いうことですね。

 私の「毎日のバッチ処理」の仮定は,その日の売上金額を当該年月のプロモーション別商品コード別に加算処理する。としています。
 これが,「毎月末のバッチ処理」とかだったら,その時点でのプロモーションで集計すると,仮定したんでしょうけど。。。

 どちらにしろ,設問では主キーの明示を求められていませんので,解答への影響はありませんね。