解説

〔aについて〕
店舗エリアエンティティと店舗エリア詳細エンティティが「1対多」の関係をもっていることに注目します。

1つの店舗が複数もつ要素を本文中から探すと、表1の種別Hの概要に「店舗エリアは，その店舗に来客が見込まれる会員の住居範囲を複数の郵便番号で定めた範囲として定義する」とあります。1つの店舗エリア番号には複数の郵便番号が紐づき、また見直しによる変動があるため、別途店舗エリア詳細エンティティで郵便番号の集合を管理していると考えられます。したがって、郵便番号が空欄aに入る属性となります。

図1には郵便番号に関連する属性として、店舗エンティティの「店舗郵便番号」、会員エンティティの「会員郵便番号」があり、いずれも「主体＋郵便番号」の形式となっています。単に「郵便番号」としてしまうと区別がつかないため、命名規則に従えば、店舗エリア詳細エンティティがもつ属性は「店舗エリア郵便番号」とするのが妥当です。

店舗エリア詳細エンティティには店舗エリア番号が同じで、郵便番号が異なる複数の組が存在することになりますから、各組を一意に特定するため、「店舗エリア郵便番号」は主キーとする必要があります。したがって、空欄aには「店舗エリア郵便番号」が入ります。

∴a＝店舗エリア郵便番号

〔bについて〕
商品エンティティとキャンペーン商品エンティティには共通の値を保持する属性「（キャンペーン）商品番号」があります。この属性「（キャンペーン）商品番号」は、商品エンティティ側では主キーであり、商品を一意に特定します。また、キャンペーン商品エンティティ側では「キャンペーン番号」属性とともに（複合）主キーであり、キャンペーンと商品の組を一意に特定します。

〔キャンペーンの概要〕に「各キャンペーンには，…，その実施を複数回に分けて行うことがある」とあるように、1つの商品について複数回のキャンペーンを行うことが予定されているため、キャンペーン商品エンティティには同一のキャンペーン商品番号をもつ複数のレコードが存在しえます。よって、商品エンティティとキャンペーン商品エンティティの多重度は「1対多」です。したがって、空欄bには「→」が当てはまります。

∴b＝→

【補足】
エンティティ間に関係がある場合、片方の主キー属性がもう片方の外部キー属性として存在します。キャンペーン商品エンティティの（複合）主キーは商品エンティティにはなく、逆に商品エンティティの主キーがキャンペーン商品エンティティにあるため、キャンペーン商品エンティティの「キャンペーン商品番号」属性が商品エンティティの主キーである「商品番号」属性を参照する外部キーであることが機械的にわかります。原則として、ある主キーをもつエンティティと、その主キーを外部キーに持つエンティティのカーディナリティ（多重度）は「1対多」です。

解説

図2のSQL文について先に全体像を確認します。()で括られている部分に注目すると、以下の構造になっているとわかります。副問合せによる表定義を含み複雑なものに見えますが、実際にはCK、UKの2つの表を結合（ON句）させ、その結果に対しSELECT文を実行しているだけに過ぎません。

【CKについて】
キャンペーン実施表から、指定したキャンペーン番号について、キャンペーン種別とその実施金額の一覧を得るものです。

【UKについて】
売上表、売上明細表、商品表を結合し、指定したキャンペーン番号について、キャンペーン種別とその合計売上、合計原価の一覧を得るものです。

〔cについて〕
主問合せのSELECT文の直後にあります。SELECT文の基本形は「SELECT 列名など FROM テーブル名」です。主問合せのSELECT文は、CKとUKの結合表を対象としますが、"SELECT"と対になる"FROM"がないので追加する必要があります。したがって、空欄cには「FROM」が入ります。

∴c＝FROM

〔dについて〕
空欄はCKとUKの2つの表の間に位置すること、またON句で両表を結合することがわかっているので、空欄dには結合方法が入ります。すなわち、内部結合（INNER JOIN）、左外部結合（LEFT OUTER JOIN）、右外部結合（RIGHT OUTER JOIN）などのうち、どれが適切かを考えることになります。

主問合せのSELECT文を見ると、「売上計」や「原価計」がNULLの場合に0へ置き換えるためにCOALESCEが使われています。しかし、UKの副問合せ内だけを見れば、売上明細表の「商品個数」「商品単価」、商品テーブルの「商品原価」がNULLになることはありません。このことから、NULLが発生するのはCKとUKを結合した結果と判断できます。CKとUKとの内部結合であれば、売上計や原価計がNULLにはなり得ないため、この結合は外部結合が必要とわかります。

また、本文冒頭に「キャンペーンを定期的に実施してきたが，売上に全く結びつかないものもあった」とあるように、指定したキャンペーンの中には、特定のキャンペーン種別での売上が発生していないものも想定されます。その場合、売上テーブルには該当するレコードが1件も作られません。ここで内部結合にしてしまうと、売上ゼロのキャンペーン種別は結果から抜け落ちてしまい、実施したキャンペーンの実績を確認することができません。

たとえ売上が発生しなくても、キャンペーン実施表にはそのキャンペーン番号とキャンペーン種別の組が存在しています。売上がなかった種別に関する実績をも結果に出力するためには、実施したキャンペーン種別の一覧であるCKの行をすべて残す必要があり、このためには外部結合が必要です。CKは結合される側の表（左側）となるので、使うのは左外部結合です。したがって、空欄dには「LEFT OUTER JOIN」が入ります（"OUTER"は省略可）。

∴d＝LEFT OUTER JOIN

〔eについて〕
空欄の直後にAS 原価計があるので、空欄eには原価の合計を求める集計関数が入るとわかります。

空欄eの1つ上では、売上計を求めるのに「売上明細.商品個数と売上明細.商品単価の積」の合計（SUM）が使われています。これをヒントにすると、原価の合計も同様に「商品個数と商品原価の積」を合計すればよいと考えられます。商品個数は売上計と同じくM.商品個数、商品原価は商品表（別名S）にあるのでS.商品原価を使います。したがって、空欄eには「SUM(M.商品個数 * S.商品原価)」が当てはまります（"M."，"S."は省略可）。

∴e＝SUM(M.商品個数 * S.商品原価)

解説

〔fについて〕
〔葉書を送る店舗エリアの見直し〕に、図3のSQL文での抽出対象について「❶対象の店舗における❷過去1年間に❸葉書キャンペーンで購入した会員」とあります。WHERE句ではU.店舗番号 = :店舗番号が❶、U.売上年月日 >= :一年前年月日が❷の要件に対応します。しかし、❸の条件は書かれていないため、空欄fには葉書キャンペーンに絞る条件式が入ります。

表1から、種別名が「葉書」に対応するキャンペーン種別は「H」であることが確認できます。SQL文に登場する2つのテーブル（売上、会員）のうち、キャンペーン種別列があるのは売上表（別名U）です。したがって、空欄fには「AND U.キャンペーン種別 = 'H'」が当てはまります（"U."は省略可）。

∴f＝AND U.キャンペーン種別 = 'H'

〔gについて〕
空欄部はGROUP BY句の後に位置すること、SELECT文を見るとグループ化で指定が必要な列は「会員郵便番号」のみであることから、空欄gにはORDER BYかHAVINGのどちらかが来ると考えられます。

〔葉書を送る店舗エリアの見直し〕では「売上実績数の降順に出力する」ことが求められています。しかし、図3のSQL文にはこれを満たす文が存在しないため、空欄gにはこれを追加する必要があります。出力順を指定するのはORDER BY句です。

売上実績数はSELECT句で列名が付けられているので、その列名を指定できます。ORDER BY句では、昇順を指定する場合は"ASC"（省略可能）、降順を指定する場合は"DESC"を列名の直後につけます。したがって、空欄gには「ORDER BY 売上実績数 DESC」が当てはまります。

∴g＝ORDER BY 売上実績数 DESC

解説

受けた指摘というのは「Webキャンペーン実績表は日次で実績を集計する想定になってしまっている」の部分です。

〔Webキャンペーン内容の定期的な見直しの検討〕からは、T社からのレポートからWebキャンペーン実績を作成するということが読み取れます。〔キャンペーンの概要〕には「T社からは，…実績を週次で集計したレポートが送付される」とあります。レポートは週次の集計単位なのに、それを記録する表が日次（実績年月日）で作られているのは矛盾しています。このため、表の構造を週次に合わせる対応が必要となります。したがって、答えは「Webキャンペーン実績表の集計粒度を日次から週次に修正する」です。

∴Webキャンペーン実績表の集計粒度を日次から週次に修正する