データベーススペシャリスト 2023年 午後1 問02

解答の導き方

1. ホテル → 客室（下向き矢印）
   根拠：「客室はホテルごとに客室番号で識別する。」（1.(2)）および図2の関係スキーマに "客室（ホテルコード、 客室番号、 (ア)）" とあることから、客室はホテルに所属するため、ホテルから客室へのリレーションシップを補います。
2. ホテル → 予約（下向き矢印）
   根拠：「1回の予約で、 客は宿泊するホテル、 客室タイプ、 … を指定する。」（4.(3)）とあるため、予約は宿泊するホテルを指定する情報を持つことが明記されており、ホテルと予約の関係を補います。
3. 客室タイプ → 客室（下向きの矢印、図では2本）
   根拠：「客室ごとに客室タイプを設定する。 客室タイプはホテル共通であり、 客室タイプコードで識別する。」（1.(3)）により、客室タイプが客室に割り当てられる関係が必要です。図1では客室タイプから客室への矢印が複数描かれていますが、要点は「客室タイプが客室の属性的分類を提供する」ことです。
4. 旅行会社 → 予約（下向き矢印）
   根拠：「旅行会社の予約システムからX社の予約システムに予約情報が連携され、どの旅行会社での予約かが記録される。」（4.(2)）と明示されているため、旅行会社と予約の関係を補います。
5. 旅行会社 → 客室（図に描かれている直線）
   根拠：図1の描画で「旅行会社」矩形ボックスから真下に直線が伸び、その先に「客室」があるため、図に示された関係を補完します。業務本文4.(2)は旅行会社が予約情報を連携することを述べており、実務上の主要結びつきは旅行会社―予約ですが、概念モデル上は図1に示された旅行会社と客室の関連も考慮します（実装段階では予約を介して旅行会社と客室の関連が表現されるのが妥当です）。
6. 客室 → 予約（下向き矢印）
   根拠：図1に客室から予約へ下向きの矢印が描かれています。一方で本文4.(3)は予約で「客室タイプ」や「客室数」を指定することを明記し、具体的な客室番号はチェックイン時に決めると記載されています（6.(1)）。したがって、概念モデルでは客室と予約に関係を持たせる（予約が概念的に客室領域と関わる）ことを明示しつつ、具体的な客室の割当はチェックイン時に発生し宿泊に記録される点を押さえます。
7. 会員 → 割引券（右向き矢印）
   根拠：「割引券には割引券番号と発行先の会員番号を記載する。」（9より）とあるため、会員と割引券の所有関係（発行先）が必要です。
8. 割引券 —三角分岐—> 宿泊割引券 / 館内施設割引券（サブタイプの表現）
   根拠：「割引券には宿泊割引券と館内施設割引券があり、 割引券区分で分類する。」（9）と明記されているため、割引券をスーパータイプ、二つをサブタイプとして表現します。
9. 宿泊割引券 → 宿泊、館内施設割引券 → 宿泊（下向き矢印）
   根拠：宿泊割引券は「会員の宿泊に対して… 1回の宿泊で割引券を1枚発行」（9.(1)）とあり、館内施設割引券は「館内施設の利用料金に充当できる。 チェックアウト時の精算だけで利用できる。」（9.(2)）とあるため、両サブタイプが宿泊に関連します（発行元宿泊番号や利用の場面として宿泊と結びつく）。
10. 予約 → 宿泊（右向き矢印）および 予約 → 予約有宿泊（左下向き矢印）
    根拠：「予約有の場合には該当する予約を検索し、客室を決め、宿泊を記録する。」（6.(1)）とあるため、予約を起点に宿泊が作られる関係が必要です。図1ではさらに「予約有宿泊」という宿泊の区分（予約を持つ宿泊）を明示しているので、予約から予約有宿泊への結合も補います。
11. 宿泊 → 予約有宿泊 / 宿泊者 / 割引券発行対象宿泊（下向きに3本の矢印）
    根拠：
    • 「宿泊ごとに宿泊者全員の氏名、住所を記録する。」（6.(5)）により、宿泊と宿泊者の関連が必要です。
    • 「1回の宿泊で割引券を1枚発行し… 発行対象の宿泊かどうかを割引券発行区分で分類する。」（9.(1)）により、割引券発行の対象を表す割引券発行対象宿泊との関連が必要です。
    • また予約の有無で宿泊を分類する（予約有宿泊）ため、宿泊から予約有宿泊への関係も補います。

誤りやすいポイント

• 予約と客室を混同する誤り
  「1回の予約で、 客は宿泊するホテル、 客室タイプ、 泊数、 客室数、 … を指定する。」（4.(3)）であり、予約は客室タイプや客室数を指定する。具体的な客室番号はチェックイン時に決める（6.(1)）。したがって関係図で客室との関連を描く場合でも、関係スキーマでは客室番号を予約に直接持たせない設計が正しい場合が多い点に注意してください。
• 旅行会社に関する関係の解釈
  本文は「旅行会社の予約情報が連携され、どの旅行会社での予約かが記録される。」（4.(2)）と記載しており、旅行会社の主要な結びつきは予約です。図1に旅行会社→客室の線があるときは図の示す概念的関連を補いますが、「旅行会社が客室を所有する」と誤解しないこと（実装では予約を介して旅行会社を紐づけるのが妥当）。
• 割引券のサブタイプ用途の取り違え
  宿泊割引券と館内施設割引券は用途・発行条件・利用時期が異なります（例：宿泊割引券は旅行会社予約は発行対象外／館内施設割引券はチェックアウト時の精算のみ利用可）。サブタイプを分ける理由を設計段階で明確にし、属性を適切に振分けてください。
• 宿泊における会員情報の扱い
  「一つの客室に複数の会員が宿泊する場合であっても記録できるのは、代表者1人の会員番号だけである。」（6.(4)）一方で「宿泊ごとに宿泊者全員の氏名、住所を記録する。」（6.(5)）。会員番号は代表者分のみを宿泊に記録し、宿泊者は別エンティティで全員分を保持する点を忘れないでください。

FAQ

解答の導き方

• ア：客室タイプコード
• イ：ホテルコード、客室タイプコード、旅行会社コード、宿泊割引券番号
• ウ：ホテルコード、客室番号、宿泊割引券番号、館内施設割引券番号
• エ：予約番号

1. 設問文に「客室ごとに客室タイプを設定する。 客室タイプはホテル共通であり、 客室タイプコードで識別する。」とあります。これは各客室がどの客室タイプに属するかを参照する必要があることを意味します。
2. 図2の客室リレーションは（ホテルコード、客室番号、 (ア) ）となっており、客室はホテル内で客室番号と組で識別されるため、(ア) は参照先となる客室タイプのキーである 客室タイプコード を追加すればよいです。
3. 客室タイプが「ホテル共通」であるため、客室タイプの主キーは客室タイプコード単独です。したがって客室側に余分にホテルコードを含める必要はなく、客室タイプコード を外部キーとして非キー属性に追加します。

1. 設問文に「1回の予約で、 客は宿泊するホテル、 客室タイプ、 泊数、 客室数、 宿泊人数チェックイン予定年月日を指定する。 予約は予約番号で識別する。」とあり、予約は宿泊するホテルと客室タイプを記録する必要があると明示されています。よって 予約 に ホテルコード と 客室タイプコード を含めます。
2. また「旅行会社の予約システムからX社の予約システムに予約情報が連携され、どの旅行会社での予約かが記録される。」とあるため、旅行会社経由の予約の場合に備えて 旅行会社コード を持たせます（自社サイト予約ではNULL可）。
3. 「予約時の前払いで利用する場合、宿泊割引券番号を記録する。」とあるため、予約時利用の宿泊割引券を記録するための 宿泊割引券番号 を追加します。
4. 注意点：予約では「客室タイプ」を指定し、特定の客室番号はチェックイン時に決める（「予約有の場合には該当する予約を検索し、客室を決め、宿泊を記録する。」）ため、予約に 客室番号 を入れるのは誤りです。

1. 設問文に「客室ごとのチェックインからチェックアウトまでを宿泊と呼び、 ホテル共通の宿泊番号で識別する。」とあるため、宿泊は実際に割り当てられた特定の客室（ホテルコード＋客室番号）を参照する必要があります。客室は（ホテルコード, 客室番号）で識別されているので、宿泊にも両方を外部キーとして持たせます。
2. 割引券について、チェックイン時やチェックアウト時に利用する記録が必要であることが次の記述から読み取れます。例えば「ホテルでのチェックイン時の前払い、 チェックアウト時の精算で利用する場合、宿泊割引券番号を記録する。」および「チェックアウト時の精算で利用する場合、館内施設割引券番号を記録する。」。したがって 宿泊 に 宿泊割引券番号 と 館内施設割引券番号 を持たせます（どちらも該当時に記録）。
3. 会員番号については「宿泊者が会員の場合、 会員番号を記録する。ただし、予約有で宿泊者が予約者と同じ場合、予約の会員番号を宿泊に転記する。」とあり、宿泊側の会員番号は代表者1人分のみを保持する設計でよいことが裏付けられます（図2ですでに会員番号が列挙されています）。

1. 図1で「宿泊」から三角分岐して「予約有宿泊」があることから、予約がある宿泊はサブタイプとして表現されています。設計方針に「サブタイプが存在する場合、他のエンティティタイプとのリレーションシップは、スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する。」とあるため、予約と関わる関係はサブタイプ側（予約有宿泊）に置くのが妥当です。
2. 実務記述にも「予約有の場合には該当する予約を検索し、客室を決め、宿泊を記録する。」とあり、予約と宿泊（予約有宿泊）を紐づけるために 予約番号 を追加します。
3. 重要な点は、宿泊の主キーである 宿泊番号 は既に存在するため、予約有宿泊の主キーは引き続き 宿泊番号（スーパータイプから継承）であり、追加する 予約番号 は外部キーとして扱うことです。従って 予約番号 を主キーに置き換えてはいけません（以前に指摘された誤りの是正点）。

誤りやすいポイント

• 客室タイプが「ホテル共通」である点の誤解
  「客室タイプはホテル共通であり、 客室タイプコードで識別する。」とある場合、客室タイプの主キーは客室タイプコード単独です。ここから「ホテルコードを客室タイプの主キーに含める」や「客室側でわざわざホテルコードを重ねて客室タイプのキーにする」と誤解しやすいですが不要です。客室側は（ホテルコード, 客室番号）で既に一意ですから、客室タイプは外部キー 客室タイプコード のみにすれば足ります。
• 予約に客室番号を入れてしまうミス
  予約で指定するのは「客室タイプ」であり、特定の客室番号はチェックイン時に決める、という記述を見落とすと、誤って予約側に客室番号を入れてしまいます。図2は予約に客室番号を持たせていない設計を想定しています。
• 予約有宿泊の主キー誤認（重要）
  サブタイプの表現として 予約有宿泊 がある場合、宿泊番号（スーパータイプの主キー）を主キーとして継承し、予約番号は外部キーである点を誤って逆にしないこと。予約番号を主キーにしてしまうと宿泊番号の一意性を失い、設計ミスになります。
• 割引券の記録場所（予約時と宿泊時）を取り違える点
  宿泊割引券は予約時に使う場合（予約に記録）とチェックイン/チェックアウト時に使う場合（宿泊に記録）があるので、どちらの場面で記録するかを設問文から正しく読み分ける必要があります。館内施設割引券はチェックアウト時の精算でのみ使える点も注意。

FAQ

解答の論理構成

1. 会員であることの判定
   【問題文】「(4) 一つの客室に複数の会員が宿泊する場合であっても記録できるのは、代表者1人の会員番号だけである。」
   また図2 “宿泊（宿泊番号、…、会員番号、…）” に “会員番号” が存在します。
   よって割引券発行対象判定の第1条件は “該当する宿泊の会員番号がNULLでないこと”。
   ⇒ (a) 宿泊、(b) 会員番号
2. 旅行会社予約は対象外
   【問題文】「旅行会社予約による宿泊は発行対象外となる。」
   判定方法は2通り。
   ① “予約区分” が “自社サイト予約” のみを対象にする。
   ② “旅行会社コード” がNULLなら旅行会社経由ではないと判断できる。
   図2 “予約（予約番号、…、予約区分、…、会員番号、旅行会社コード）”
   よって (c) は “予約区分” または “旅行会社コード”、(d) はそれぞれ “自社サイト予約” または “NULL”。
3. 予約無しの場合
   【問題文】「予約無の場合には泊数、宿泊人数、宿泊料金を確認し、… 宿泊を記録する。」
   予約が無い場合は“宿泊”しか参照できないため、条件3も “宿泊.会員番号” をチェックすることになる。

誤りやすいポイント

• “予約.会員番号” を使うと条件3（予約無の場合）を判定できなくなる。
• “旅行会社コード = ''（空文字）” と考えてしまう。仕様ではNULLが正しい。
• “宿泊区分” という属性名があると勘違いする。図2にそのような属性は無い。

FAQ

解答の論理構成

1. 割引券の状態について
   【問題文】「割引券の状態には未利用、利用済、有効期限切れによる失効があり、割引券ステータスで分類する。」
   ⇒ 条件1は “使える状態か” をチェックするので
   e＝割引券ステータス、f＝未利用
2. 割引券の種類について
   【問題文】(1)宿泊割引券 ②「予約時の前払いで利用する場合、宿泊割引券番号を記録する。」
   ⇒ 条件2は “宿泊割引券であるか” を確認するので
   g＝割引券区分、h＝宿泊割引券
3. 本人利用の確認について
   【問題文】(1)宿泊割引券 ②「1回の予約で1枚を会員本人の予約だけに利用できる。」
   ⇒ “本人” をDBで担保するには割引券と予約の “会員番号” を一致させる必要があるので
   i＝会員番号、j＝会員番号

誤りやすいポイント

• 条件1と条件2を逆にし、「未利用」を “割引券区分” に当てはめてしまう。
• 割引券を持たない非会員予約で「会員番号」がNULLになり得る点を見落とし、本人確認条件を不要と判断する。
• 「宿泊割引券」と「館内施設割引券」を区別せず、どちらも予約時に使えると誤解する。

FAQ

解答の論理構成

1. 会員と会員ランクの関係
   要件(1)では「会員ランクにはゴールド、 シルバー、 ブロンズがあり、それぞれの必要累計泊数及びポイント付与率を決める」とあります。さらに(2)で「毎月末に過去1年間の累計泊数に応じて会員の会員ランクを決める」とされているため、
   ・“会員ランク”１ ←― N “会員”
   の１対多リレーションシップが成立します。
2. 会員とポイント増減の関係
   要件(10)に「ポイントの付与、 支払充当、商品交換及び失効が発生する都度、 …をポイント増減として記録する」と明記されています。また表1では“会員番号”が主キー先頭に配置されているため、
   ・“会員”１ ←― N “ポイント増減”
   が必須です。
3. ポイント増減と４種のイベントの継承構造
   要件(10)は「ポイントの付与、 支払充当、商品交換及び失効」を統一名称“ポイント増減”で扱うと示しており、図4でも“ポイント増減”の下に４行のサブタイプ表が並びます。このことは設計方針1.(4)「サブタイプが存在する場合…スーパータイプ又はいずれかのサブタイプの適切な方との間に設定」に合致し、
   ・スーパータイプ：“ポイント増減”
   ・サブタイプ　　：“ポイント付与”／“ポイント失効”／“支払充当”／“商品交換”
   という「ＩＳ－Ａ」の分岐（▽）を設定します。
4. 商品と商品交換の関係
   要件(7)「商品ごとに交換に必要なポイント数を決める。 …交換時に商品と個数を記録する」より、
   ・“商品”１ ←― N “商品交換”
   が必要です。支払充当・付与・失効には商品が関与しないため、接続するのは“商品交換”のみとなります。
5. 方向性（矢印）
   サブタイプへの矢印は“ポイント増減”から下方へ、逆に“商品”から“商品交換”へは従属方向で下向き矢印とすることで、模範図の形が確定します。

誤りやすいポイント

• “ポイント増減”と４サブタイプを横並びの別エンティティとして描き、スーパータイプ構造を忘れる。
• “商品”を“支払充当”にも誤って接続する。要件(6)は料金支払であって商品交換ではない点に注意。
• “会員”と“会員ランク”を多対多で描くミス。ランクは時点ごとに１つだけ保持するため１対多が正しい。
• 図3に存在しないエンティティ（例：予約や宿泊）との関係を追加してしまい減点となる。

FAQ

解答の論理構成

1. 会員ランク（オ）
   “会員ランクにはゴールド、シルバー、ブロンズがあり、それぞれの必要累計泊数及びポイント付与率を決める。”
   ⇒累計泊数はランク判定にだけ使う静的値なので“必要累計泊数”。付与計算用に“ポイント付与率”も必要。
2. 商品（カ）
   “商品ごとに交換に必要なポイント数を決める。”
   商品識別子は既に“商品コード”。残りは“商品名”と“ポイント数”。
3. ポイント増減（キ）
   “ポイントの付与、支払充当、商品交換及び失効が発生する都度、ポイントの増減区分、増減数及び増減時刻をポイント増減として記録する。”
   よって三属性を追加。連番はキーに含まれているため重複しない。
4. ポイント付与（ク）
   “有効期限年月日及び付与したポイント数を未利用ポイント数の初期値として記録する。”
   未利用は付与時点でのみ設定され、以後は消し込みで減算されるため本エンティティに保持。
5. ポイント失効（ケ）
   “失効の1か月前と失効後に会員に電子メールで連絡する。 失効前メール送付日時と失効後メール送付日時を記録する。”
   失効エンティティが扱うのは失効発生レコードなので“失効後メール送付日時”のみで十分。
6. 支払充当（コ）
   “支払充当では、支払充当区分 (予約時、チェックイン時、チェックアウト時のいずれか)…を記録する。”
   区分名をそのまま“支払充当区分”として追加。
7. 商品交換（サ）
   “交換時に商品と個数を記録する。”
   商品コードは商品表への外部キーなので商品コード、取引数量は“個数”。

誤りやすいポイント

• 有効期限と未利用ポイント数を「ポイント増減」に入れて第3正規形を崩してしまう。
• “失効前メール送付日時”まで「ポイント失効」に入れてしまい、将来のリレーションが冗長になる。
• “必要累計泊数”を“累計泊数”と誤記し、ランク判定用か実績値かを混同する。
• “商品交換”で商品名を直接持たせ、商品マスタとの重複を作ってしまう。

FAQ

解答の論理構成

1. 消込み対象の特定
   • 要件(8)は“未利用ポイント数から利用されたポイント数を減じて”と記述しており、0の場合は減算不能です。
   • したがって(a)は“未利用ポイント数が0より大きい”インスタンスとなります。
2. 消込み順序
   • 同じ(8)文で“有効期限の近い未利用ポイント数から”と明示されています。
   • 近い順＝早く到来する順ですから(b)は“有効期限年月日が近い順”となります。
3. 表1の用語利用
   • インスタンスの属性名として“未利用ポイント数”と“有効期限年月日”が表1に存在し、これらをそのまま用いる必要があります。

誤りやすいポイント

• 「ポイント増減時刻」順と読み違える
• “近い”を“遠い”と逆に解釈する
• 未利用ポイント数=0を含めてしまい対象外レコードを選択してしまう

FAQ