2005年02月04日
H16午後I 問2
Ｈ１６午後I 問２
設問１（３）
iTAC@解答例速報掲示板より
午後１ 問２ 設問１（３） 投稿者：MyVitzRs 投稿日：4/18 22:38:05解答例を基準にして、、、、
「実施年月」は、プロモーションIDにより一意に識別できるため、月別プロモーション別
商品売上集計テーブルに入れるのは、冗長では？よって、「売上個数（売上個数累計）」「売上金額（売上金額累計）」の２項目でOKだと思います。
午後１ 問２ 設問１（３） 投稿者：Gypsy 投稿日：4/18 23:17:38"前月"と"今月"の集計結果として別個に格納しておくために
「実施年月」は必要なのではないでしょうか?
そのために'月別'プロモーション別商品売上集計テーブルと
月別であることを明記してるんだと思います。ただ前月の結果も入れるので「実施年月」ではなくて
「年月」の方が正しそうな気がします。(といいつつ実施年月と解答してしまいましたが、、、)
午後１ 問２ 設問１（３） 投稿者：Gan 投稿日：4/18 23:55:51私も年月は冗長だと思ったので、
「売上個数（売上個数累計）」「売上金額（売上金額累計）」
のみとしました。
公式解答例は「年月」は入っている。
素直に考えれば，設問で「月別プロモーション別商品売上集計テーブル」となっているので，当然，「年月」は入るものと思うんだが・・・
年月が無かった場合を考えてみる
前月の時点では，プロモーション対象商品ではない（一つの商品が２か月続けてプロモーションの対象となることはない）ことから
プロモーションＩＤ→実施年月（当月） は求められるが
プロモーションＩＤ→前月 は，実施年月－１ヶ月しなければならない。だが，標準ＳＱＬでは日付関数がないため，求められない。
設問もおかしい！
「月別プロモーション別商品売上集計テーブル」の名前から，素直に受け取れば，主キーは｛年月，プロモーションＩＤ，商品コード｝である。
しかし，前月時点では対象商品はプロモーションの対象となっていないため，プロモーションＩＤがない。つまりは，主キーの一部がＮＵＬＬになってしまい，集計が出来ない。
ここでの主キーは｛年月，商品コード｝であり，プロモーションＩＤは外部キーである。
ゆえに，テーブル名は「月別商品別売上集計テーブル」とすべきである。
この記事をLicWikiに埋め込む：
2 ：おみおみ：05/03/04 23:26:06 [RES]
>情報処理のための掲示板が生きてれば、去年の問題のログに関してはそっちのほうがはるかに有益だったんだがな
http://johobbs.lib.net/
↑ここのことでしょうか？
私もかなりお世話になってたので復活を望んでるんですけど。
>しかし，前月時点では対象商品はプロモーションの対象となっていないため，プロモーションＩＤがない。つまりは，主キーの一部がＮＵＬＬになってしまい，集計が出来ない。
私は、プロモーションは実施する数ヶ月前に設定しているのかなと思いました。特にそういう記述はないですが、そう考えればプロモーション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）の月に別のプロモーションのプロモーション対象商品.商品コードに存在しない。と，読みました。
どういうことかというと，今月，プロモーション対象になっている商品は，前月はどのプロモーションの対象になってはいけない。
ひっくりかえすと，前月のプロモーション対象商品は，今月，プロモーション対象商品にできない。と。
この条件で，図２の「ホットカーペット」のインスタンスを考えると
月別プロモーション別商品売上集計（年月，プロモーションＩＤ，商品コード，売上個数，売上金額）
200403,00001,00003,40,1120000
200402,NULL ,00003,10,350000
になるのではと思ったんですが。。。どうでしょう？
4 ：おみおみ：05/03/05 09:27:44 [RES]
おはようございます。
>月別プロモーション別商品売上集計（年月，プロモーションＩＤ，商品コード，売上個数，売上金額）
プロモーションの前提に関してはそのとおりです。
しかし、「年月」とは関係なく、"プロモーション対象商品"テーブルでプロモーションIDと商品コードの組合せが設定されていれば、以下のタプルを生成できるはずです。前月はプロモーションが実施されていませんが、{プロモーションID,商品コード}の関係は有効です。
200403,00001,00003,40,1120000
200402,00001,00003,10,350000
~~~~~~~
うまく説明できてるかどうかわかりませんが。
5 ：g@kko：05/03/05 09:59:21 [RES]
>>4 ：おみおみ さん
なるほど。
プロモーションの予定がきちんと入っている（未来の実施年月のプロモーションがある）ことは必要ですね。
また，「毎日のバッチ処理」で処理対象とする期間と条件が明示されていませんので，おみおみさんの考え方もありだと思います。
蛇足ですが，前月末に突然，翌月プロモーション対象となる場合（競合他社に対抗してなど）を考慮すると，前月実績の再編集（プロモーションＩＤを付与）も検討しなければいけませんね。
6 ：おみおみ：05/03/05 10:42:17 [RES]
>5
私の中では解決が出ました。
プロモーションが決まって、"プロモーション"テーブルと"プロモーション対象商品"のタプルを生成してから、該当する商品に対して"月別プロモーション別商品売上集計テーブル"のタプルを作成する。
1ヶ月以上前に決まっているプロモーションの処理については既に述べたとおり問題ありません。
前月中(たとえば2/20)に決まったプロモーションについては、決まってから"月別プロモーション別商品売上集計テーブル"のタプルを作り、そのときにその月の売上個数と売上金額を集計する(期間：2/1～2/20 or 2/19)。その後は日次のバッチ処理で更新する。
これならプロモーションIDがなくて主キーにできないという問題は発生しません。
そして合理的です。なぜなら"月別プロモーション別商品売上集計テーブル"にはプロモーションの対象となっている商品の実施年月、前月のデータしか必要ないからです。プロモーションが決まる前に集計テーブルを作成すると、不要なデータを集計してしまうおそれがあります。以下の記述はそういうこと(プロモーションの対象になるかどうか分からないけどとりあえず全商品の集計をしている)ですよね？違ってたらごめんなさい。
>蛇足ですが，前月末に突然，翌月プロモーション対象となる場合（競合他社に対抗してなど）を考慮すると，前月実績の再編集（プロモーションＩＤを付与）も検討しなければいけませんね。
