データベーススペシャリスト 2009年 午後1 問03

解答の導き方

1. 目的の確認
   図3のSQL文は「SELECT * FROM 顧客 WHERE 顧客コード = :顧客コード AND 適用開始日 <= CURRENT_DATE AND ( (a) OR (b) )」であり、これは「現在日付の顧客属性情報を1行読み込む」ための文です。したがって該当行は「適用開始日 <= CURRENT_DATE」を満たし、かつ CURRENT_DATE が当該行の有効期間内にある必要があります。
2. 有効期間の定義を問題文から読み取る
   問題文に「適用終了日が未定の場合は、NULLが設定される」とあります。さらに表の例（例えば変更連番3の適用終了日が2009-05-31で変更連番4の適用開始日が2009-06-01となっている先日付の例）から、有効期間は開始日を含み終了日も含む連続した日付範囲で扱われていることがわかります（前行の適用終了日と次行の適用開始日が連続している）。
3. CURRENT_DATEが有効期間に含まれる条件を式にする
   日付範囲 [適用開始日, 適用終了日] にCURRENT_DATEが含まれるための条件は次のとおりです。
   • 適用開始日 <= CURRENT_DATE（図3の既存条件）
   • そして（適用終了日 >= CURRENT_DATE）または（適用終了日 IS NULL）であること。
     • 「適用終了日 IS NULL」は、終了日未定（現行行）の扱いを確実に取り込むために必要です。
     • 「適用終了日 >= CURRENT_DATE」は、適用終了日が設定されている行のうち、当日を含む行を取り込むための条件です。
4. したがって図3中の(a),(b)に入る字句は次になります。
   a：適用終了日 >= CURRENT_DATE 又は 適用終了日 = CURRENT_DATE
   b：適用終了日 IS NULL

誤りやすいポイント

• 「適用終了日 = CURRENT_DATE」を誤りと決めつける
  設問1の時点では先日付の行がないので「= CURRENT_DATE」も正解です（解答例も両方を挙げています）。先日付の変更を考える設問2以降では「>= CURRENT_DATE」が必要になります。
• NULLの扱いを忘れる誤り
  SQLでの比較はNULLに対して真にならないため、「適用終了日 >= CURRENT_DATE」だけだと終了日がNULL（現行の有効行）であるレコードが除外されます。必ず「適用終了日 IS NULL」を明示するか、代替手段でNULLを扱う必要があります。
• 「> CURRENT_DATE」を使う誤り
  終了日がちょうど当日の行（当日まで有効）を取り落とします。図の運用から終了日は当日を含むため、">=" を用いるべきです。
• 日時成分による比較ミス
  カラムが日時（時刻を含む）型の場合は 時刻成分 によって期待と異なる結果になることがあります。図中のCURRENT_DATEは日付を表す予約語なので日付単位の比較を前提にしていますが、実装時は型を揃える注意が必要です。

FAQ

解答の論理構成

1. 目的確認
   図4のSQL文は「優遇レベルが変更された日を調べる」ものです。したがって直前行と優遇レベルが異なる行だけを抽出する必要があります。
2. 自己結合のキー
   where句に
   AND (c) = Y.変更連番
   とあるため、Y側が「X側の次の連番」であることを示す式を入れます。履歴テーブルは表2で「変更連番…1ずつ増加する整数が付与される。連番に抜けはない。」と定義されているので、一意に次行を示すのは「X.変更連番 + 1」です。
3. 優遇レベル差異の判定
   同一行を結んだだけでは優遇レベルが変わったか分かりません。問題文には「優遇レベルが変更された日を調べる(例えば、表4のような結果行を求める)」と書かれています。そこで (d) に優遇レベルの不一致条件を置きます。XとYは隣接行なので、異なるときだけ抽出すればよく、式は「X.優遇レベル」と「Y.優遇レベル」を比較します。where句ではY.優遇レベル と比較するため (d) には「X.優遇レベル」が入ります。
4. 以上より
   c: X.変更連番 + 1
   d: X.優遇レベル

誤りやすいポイント

• 変更連番のずらしかたを「−1」としてしまう
  Xが最新行、Yが前行と誤解すると逆になります。where句の (c) = Y.変更連番 の向きを確認しましょう。
• 優遇レベル比較で「=」を使い抽出できない
  変更を検出するので不一致条件 (≠) が必要です。
• 変更連番に「NULL存在可能」と勘違い
  表2に「連番に抜けはない」と明記されています。NULLは入りません。

FAQ

解答の導き方

1. 次の行Yをどう特定するか
   　表の定義に「変更連番は、1から始まり1ずつ増加する整数が付与される。連番に抜けはない。」とあります。したがって、ある行Xの次の変更連番は「X.変更連番 + 1」であり、次の行Yはこの連番を持つ行です。これが（c）に入る式の根拠です。
2. 同一顧客かどうかの照合
   　指摘事項①の条件は「同一顧客の適用期間は、連続していなければならない。」ですから、比較対象のYはXと同じ顧客でなければなりません。SQLの内側でYの顧客をXに合わせるため、比較式として「X.顧客コード = Y.顧客コード」を使います。これが（e）に入るべき字句です。
3. 連続の判定方法
   　「日にちが抜けたり、重なったりしてはならない」とあるので、連続しているとは「次の行の適用開始日が、直前行の適用終了日の翌日と一致する」ことを意味します。直前行の終了日の翌日を求めるためにNEXT_DAY(X.適用終了日) が与えられているため、連続していない条件はNEXT_DAY(X.適用終了日) <> Y.適用開始日 になります。これが（f）に入る字句です。

• e：X.顧客コード
• f：Y.適用開始日

誤りやすいポイント

• （c）をX.変更連番 − 1としてしまう誤り：次の行を探すのに「−1」を使うと前の行を探してしまい、論理が逆になります。表の「連番に抜けはない」を根拠に「+1」を使う必要があります。
• 終了日と開始日を直接比較してしまう誤り：連続の定義は「終了日の翌日」と「次の開始日」が一致することなので、NEXT_DAYを使わずにX.適用終了日 = Y.適用開始日 とするとオフバイワン（1日ずれる）になります。
• XとYの顧客照合を忘れる誤り：複数顧客のデータが混在するため、必ず同一顧客（顧客コード）で照合しないと誤検出します。
• NULLの扱いを誤る誤り：現行適用中の行は適用終了日がNULLなので、対象外にする条件（X.適用終了日 IS NOT NULL）が必要です。
• 削除行（顧客削除時に適用終了日に削除日付が入る）の扱いの誤解：このSQLは「次の行が存在するか」を EXISTS で確認しているため、末尾の削除行（次の行がない行）はそもそも検出対象になりません。削除行も検出したい場合は別条件が必要です。

FAQ

解答の導き方

1. 図3のSQLの意図を確認します。図3は「適用開始日 <= CURRENT_DATE」を条件にし、さらにもう一つの条件群（(a) または (b)）で現在日に有効な行を選ぶ設計です。実務上この(a)/(b)は通常「適用終了日 IS NULL」または「適用終了日 >= CURRENT_DATE」を意味します。つまり図3は「適用開始日 <= CURRENT_DATEかつ （適用終了日 IS NULLまたは 適用終了日 >= CURRENT_DATE）」を満たす行を選ぶ意図です。
2. C333333の該当行を条件と照らします（問題文の表の該当行をそのまま参照します）。
   • 変更連番3: 適用開始日2009-02-01、適用終了日2009-05-31
     → 適用開始日 <= 2009-05-25を満たす（2009-02-01 ≤ 2009-05-25）、適用終了日 >= 2009-05-25も満たす（2009-05-31 ≥ 2009-05-25）。
   • 変更連番5: 適用開始日2009-05-25、適用終了日2009-05-31
     → 適用開始日 <= 2009-05-25を満たす（等号も含む）、適用終了日 >= 2009-05-25も満たす（2009-05-31 ≥ 2009-05-25）。
3. したがって図3の条件を満たす行は変更連番3と変更連番5の2行になるため、図3のSQLは複数行を返します。図3は「現在日付の顧客属性情報を1行読み込む」目的で設計されているため、この状況は想定外です。
4. 補足（実行結果の扱いについて）: 生のSELECT文は複数行の結果セットを返して実行自体は成功することが多いですが、図3のように「1行を期待する処理」（SELECT INTOや単一行を前提としたホスト言語の処理）で呼ぶと「単一行を期待しているのに複数行来た」ことで実行時エラー（単一行想定の処理で失敗する）となる可能性があります。したがって試験での短答は「結果行が複数行になる」が基本解答で、実務的な注意として「単一行期待の処理では実行時エラーになる場合がある」と補足説明する必要があります。

誤りやすいポイント

• 「適用開始日 <= CURRENT_DATE」の等号（等しい日付も含む）を見落とし、当日変更を選ばないと誤判断する。
• 重複（適用期間の重なり）があると複数行になる点を見落とす（今回の変更連番3と5が重複）。
• 生のSELECTは複数行返しても必ずしもSQLが『失敗する』とは限らない点を混同する（ただし単一行期待の文脈ではエラーになる）。
• 変更連番4（適用開始日2009-06-01）は2009-05-25の時点では選ばれない点を誤って含める。

FAQ

解答の論理構成

1. 制約の確認
   • 指摘事項①より「変更連番が1以外の場合の適用開始日は、変更連番が一つ前の行の適用終了日と連続していなければならない」（設問2(3) では変更連番を適用順番に読み替える）
2. イベントの整理
   • “2009-05-24” までは電話番号 “333-2222”・優遇レベル “2”
   • “2009-05-25” に電話番号変更を受付（優遇レベルはまだ “2”）
   • “2009-06-01” から優遇レベル “3” を適用
3. 行の割付
   • 3行目が “2009-02-01” ～ “2009-05-24” レベル “2” で確定
   • 4行目は受付日 “2009-05-25” を起点に電話番号 “333-3333”・優遇レベル “2”・適用終了日 “2009-05-31”
   • 5行目は先日付 “2009-06-01” 開始、電話番号 “333-3333”・優遇レベル “3”・適用終了日 NULL
4. 値の確定
   よって
   (g) = “333-3333” (h) = “2” (i) = “333-3333” (j) = “3”

誤りやすいポイント

• 先日付処理を1行で済ませようとして期間が重複／欠落する
• 電話番号変更と優遇レベル変更を同じ行で更新し、受付日が記録できなくなる
• 適用終了日NULLの行は必ず1行だけという暗黙ルールを忘れる

FAQ

解答の導き方

1. 同一の適用開始日に複数の変更依頼がある場合
   　複数の属性変更（例えば氏名変更と電話番号変更）が、受付日が異なるにもかかわらず適用開始日を同一日に指定されることがあります。顧客テーブルは「ある適用開始日からの状態」を1行で表すため、その行には変更受付日を1つしか格納できません。別行として同一適用開始日を持つ行を追加すると、指摘事項①の「同一顧客の適用期間は、連続していなければならない」に抵触したり、期間が重複・欠落するため不整合が生じます。したがって、同一適用開始日に異なる受付日を持つ複数の依頼を漏れなく残せません。
   　（例：5月1日に氏名変更受付、5月10日に電話変更受付、いずれも適用開始日を6月1日に指定した場合、顧客テーブルの1行に2つの受付日を入れられない。）
2. 先日付で設定した適用開始日より前に顧客が削除される場合
   　問題文は「顧客コードが削除されたときは、当該顧客行は削除されず、削除日付が設定される」としています。先日付の変更は適用開始日が将来日付の行を作成して記録する運用例が示されていますが、顧客がその適用開始日より前に削除されると、削除処理の結果（削除日付の設定や将来行の無効化・整理）によっては、先に作成した「適用開始日＝将来日付」の行が最終データ上残らない、あるいは意味を持たない状態になる可能性があります。その結果、その行に記録していた変更受付日が最終的に参照できなくなる場合があります。
   　（例：5月20日に6月1適用で行を追加して受付日を記録したが、5月25日に顧客が削除されると、最終データに先日付行が残らないため受付日の記録が失われる可能性がある。）

• 同じ適用開始日に異なる変更受付日の顧客属性情報が存在する場合
• 先日付で設定した適用開始日より前に顧客コードを削除する場合

誤りやすいポイント

• 「適用開始日＝変更受付日」と混同する。先日付で適用開始日を指定する点を見落とすと誤答する。
• 同一の適用開始日は複数行で表現できると安易に考える。指摘事項①の連続性制約で矛盾が生じる。
• 削除の扱いを「行を単に追加する」と誤解する。問題文は「当該顧客行は削除されず、削除日付が設定される」としていることを忘れない。
• 「変更受付日」を顧客テーブルの単一列で済ませればよいと考えるが、イベント（受付）の粒度で残すなら別テーブル（ログ）が必要になる点を見落とす。

FAQ

解答の導き方

• 図5のZ抽出条件を満たすZ行が0件 → SQLの結果行が存在しない（問題文の指示に従えばその顧客の月間預入額は0円扱いになる）。
• Z行が1件 → 各取引はちょうど1回だけ結合されるので、SUMは正しい値になる。
• Z行が2件以上 → 各取引が複数回結合されるため、SUMは正しい値よりも大きくなる（重複集計）。

• 月間預入額は正しい（Z行が1件）：
  • A：3本の線分のうち、4月1日以降に始まり適用終了日がNULLの線分（4月中旬に○、右端が▶）だけが条件を満たす。
  • D：4月1日の直後に○があり、右端が▶の線分が1本だけで、これが条件を満たす。
  • F：4月30日より後に○があり、右端が▶の線分が1本だけで、これが条件を満たす。
  • G：4月1日の直後に○、4月30日の手前に●がある線分が1本だけで、これが条件を満たす。
• 正しい月間預入額よりも多くなる（Z行が2件以上 → 重複集計）：
  • B：4月1日より前に始まる線分は除外されるが、4月中に始まって4月中に終わる線分と、4月中に始まり右端が▶の線分の2本が条件を満たす。
  • E：3本の線分がいずれも4月1日以降に始まり、4月中に終わるか右端が▶なので、3本とも条件を満たす。
• 預け入れがあるにもかかわらず、月間預入額が0円である（Z行が0件 → 結果行が生成されない）：
  • C：4月1日より前に○があり、右端が▶の線分1本だけ。適用開始日が4月1日より前なので除外される。
  • H：4月1日より前に○、4月1日の直後に●がある線分1本だけ。適用開始日が4月1日より前なので除外される。
  • I：4月中に○、4月30日より後に●がある線分1本だけ。適用終了日が4月30日より後でNULLでもないので除外される。

• 月間預入額は正しい。：A、D、F、G
• 正しい月間預入額よりも多くなる。：B、E
• 正しい月間預入額よりも少なくなるが、0円ではない。：（該当なし）
• 預け入れがあるにもかかわらず、月間預入額が0円である。：C、H、I

誤りやすいポイント

• 図5の2つの日付条件を読み間違え、「適用期間が4月を含めばよい」と誤解する点。実際は「適用開始日 >= 2009-04-01」が必須で、4月開始以前に始まって継続している行は除外されます。
• 取引日と顧客の適用期間を結ぶ条件（X.取引日 とZ.適用開始日/適用終了日）を入れ忘れている点に気づかないこと。これがないと取引がZの複数行と結合されて重複集計が起こります。
• GROUP BY のキー（Z.支店番号、Z.顧客コード、Z.顧客名）が顧客ごとに不変である前提を見落とし、複数Z行が選ばれてもグループは1つにまとまり合算される点を理解していないこと。
• 「正しいより少なくなるが0ではない」パターンを想定して誤って選ぶこと。図5の構造ではそのパターンは発生しないため、選択肢は「多い／正しい／0（行なし→0円）」のいずれかになります。

FAQ