www.youtube.com 本動画では、令和5年度 秋期 データベーススペシャリスト試験 午後Ⅰ 問2「ホテル予約システムの再構築」を題材に、提示された資料に基づいて、現状業務を概念データモデルと関係スキーマへ落とし込む手順と、新規要件であるポイント制（会員ランク、ポイント付与、ポイント利用、ポイント失効）を追加する際に、どのようなデータ構造が筋が通るのかを解説します。本問は、ホテル業務という分かりやすい題材である一方、割引券の利用タイミングと併用条件、予約と宿泊の関係、サブタイプの設計、ポイント消込のための残高管理など、要件の“ひっかけ”が複数仕込まれており、与件を丁寧に読み切れるかが合否を分けます。午後Ⅰでは、実装やUIの話ではなく、業務ルールを一意識別・外部キー・多重度・制約として正しくモデル化できるかが評価対象です。 まず全体像として、X社の予約システムは、ホテルと客室の管理、会員および旅行会社経由予約の受付、予約に基づく宿泊の実績管理、チェックイン・チェックアウトに伴う客室確定と精算、そして現行制度としての会員特典（宿泊割引券、館内施設割引券）の発行・利用を扱っています。ここに新規要件として、会員ランク制度とポイント制が導入され、宿泊実績に応じたポイント付与、ポイントの支払充当、商品交換、ポイント失効までを追跡できるようにする必要があります。試験としての狙いは、現状部分で「予約と宿泊は同一ではない」「割引券は種類と利用タイミングが異なる」「予約時点と宿泊実績時点で確定する属性が違う」という分離を正しく設計できるか、追加要件部分で「増減履歴と用途別詳細を分離する」「消込のために未利用残を保持する」という典型パターンを適用できるかにあります。 設問1は、現状の概念データモデルと関係スキーマの欠落部分を埋める問題ですが、ここで最も重要なのは、業務の時系列と確定タイミングを意識して、どの外部キーが予約時に決まり、どの外部キーが宿泊（チェックイン時）に決まるのかを取り違えないことです。概念データモデルのリレーションシップ補完では、客室タイプが客室を分類するマスタであり、客室タイプ1に対して複数客室が属するという1対多を表現するのが基本です。また、予約と宿泊の関係は、予約が成立しても宿泊が実施されないケースがあり得る一方、宿泊は予約に基づいて行われるという因果があるため、予約から宿泊への関連を持たせる必要があります。この部分を落とすと、予約と宿泊が独立してしまい、後段の割引券発行条件やポイント付与条件に必ず矛盾が出ます。 関係スキーマの空欄補完では、客室タイプがホテル共通で客室タイプコードで識別されるというルールから、客室タイプの主キーは客室タイプコードになります。予約に入る属性については、予約時点で分かるのは、どのホテルのどの客室タイプを押さえたか、旅行会社経由か自社サイトか、そして宿泊割引券を予約時に利用する場合はその割引券番号が予約と結び付く、という点です。ここでホテルコードと客室タイプコードを落とすと予約の対象が特定できず、旅行会社コードを持たせないと経路判定や割引券発行の除外条件に使えなくなります。割引券番号についても、予約時に利用できるのは宿泊割引券であるという要件がある以上、予約に宿泊割引券番号の外部キーを持たせる設計が自然です。旅行会社コードや宿泊割引券番号が必ずしも埋まらない点は、NULL許容の外部キーとして扱うことになりますが、午後Ⅰとしては「要件上、存在しない可能性がある参照」であることを読み取れているかが重要です。 宿泊に入る属性は、予約と同じものを再掲するのではなく、チェックイン時点で確定する情報を入れるのが筋です。宿泊では実際に割り当てた客室が確定するため、ホテルコードと客室番号が必要になります。ここで客室タイプで済ませるのではなく、客室番号まで落とすのが“実績”である宿泊の意味です。さらに本問の難所として、割引券が二種類あり、宿泊割引券は予約時に、館内施設割引券はチェックアウト時の精算で利用できるというタイミングの違いが提示されています。しかも与件上、宿泊割引券と館内施設割引券を併用し得ることを読み取らせる作りになっているため、宿泊側にも館内施設割引券番号を保持しておく必要があります。採点講評で、宿泊に館内施設割引券番号を書き忘れる誤答が多いとされるのは、まさにこの“利用タイミングが違うが宿泊実績に紐付けて管理する必要がある”という設計上の要点を落としているためです。サブタイプである予約有宿泊に予約番号を持たせるのも、宿泊の中でも予約に紐付くものだけが予約番号を参照できるというモデリング上の整合を取るためであり、ここを一般化して宿泊に直接予約番号を入れてしまうと、予約なし宿泊の扱いが破綻します。 設問2は、割引券の発行と利用に関する業務制約を、どのエンティティを参照して判定するのかという観点で整理する問題です。ここでの読解ポイントは、割引券が「予約」ではなく「宿泊の実績」に対して発行されること、そして発行対象が会員宿泊であり旅行会社経由予約は除外されるという条件が同時に成立している点です。予約有の場合でも、予約者と宿泊者が異なる可能性があるため、発行判定の基準は予約ではなく宿泊に置く必要がある、という論理を与件から導けるかが問われています。予約と宿泊を同一視してしまうと、ここで一気に矛盾が顕在化します。また、旅行会社経由を除外する条件は、予約区分で判定する、あるいは旅行会社コードがNULLか否かで判定する、といった実装可能な条件に落とす必要があります。午後Ⅰでは「旅行会社経由は対象外」と日本語で書くだけでは足りず、データとして何を見れば判断できるのかまで設計に落とし込めているかが評価の焦点になります。 予約時の割引券利用制約も同様で、状態として未利用であること、種類として予約時に使えるのは宿泊割引券であること、そして本人確認として会員本人の予約・宿泊だけに利用できることを、どの属性で検証するかに落とす必要があります。割引券ステータスとその値として未利用を確認する、割引券区分が宿泊割引券であることを確認する、会員番号の一致を確認するという形で、制約の根拠がデータ上で追えるようにしておくのが筋になります。割引券は“使える雰囲気”ではなく、システムが機械的に判定できる条件に分解されなければならず、本問はその分解を丁寧にやらせる構造です。 設問3は、新規要件であるポイント制を導入する際のデータ設計で、本問のもう一つの山場です。ポイント制の設計で重要なのは、ポイントが増減する事象が複数あることを前提に、共通部分と事象固有部分を分離し、履歴として矛盾なく残せる構造にすることです。典型解は、ポイント増減を共通のエンティティとして設け、ポイント付与、ポイント失効、支払充当、商品交換をそのサブタイプまたは1対1の関連でぶら下げる形になります。これにより、どの会員のポイントがいつ、何ポイント増減したのかという“台帳”をポイント増減で一元管理しつつ、付与なら有効期限や未利用ポイント数、失効なら通知日時、充当なら充当区分、交換なら商品コードと個数といった事象固有情報を持たせられます。ここで増減を事象ごとに別テーブルに分散させてしまうと、ポイント残高の整合や監査性が崩れやすく、消込処理の前提も不安定になります。 新規関係スキーマの属性補完では、会員ランクが何で決まるかというルールをデータとして持つ必要があるため、必要累計泊数とポイント付与率が妥当になります。商品は交換対象であり、交換に必要な情報として商品名と必要ポイント数が必要になります。ポイント増減は全事象の共通項として、区分、増減数、増減時刻を持たせるのが基本です。ポイント付与では、有効期限管理と消込管理が要件の本質であり、単に付与ポイントを記録するだけでは、後の利用でどの付与分が消費されたかを管理できません。そのため、有効期限年月日と未利用ポイント数を持たせる設計が合理的で、採点上もこの“残高を明細単位で持つ”発想ができたかが差になります。ポイント失効で失効後メール送付日時を保持するのは、失効処理が行われた事実と通知を業務的に追跡するためであり、単に失効したという結果だけでなく運用面の証跡を残す要件です。支払充当区分は、ポイント利用が予約時・チェックイン時・チェックアウト時など複数タイミングで発生し得ることを識別するために必要で、商品交換は商品コードと個数を保持しなければ何と交換したかが確定しません。 ポイント消込ロジックは、設計とアルゴリズムが接続する箇所で、未利用ポイント数が0より大きい付与レコードだけを対象とし、有効期限が近い順に消費するというルールを、データ項目として成立させる必要があります。未利用ポイント数があるからこそ「まだ使い切っていない付与分」を抽出でき、有効期限年月日があるからこそ順序付けができます。ここは、在庫の先入先出や期限切れ優先消費と同型の設計であり、DBスペシャリストとして頻出のパターンを、ポイント制という題材に適用できるかが問われています。逆に言えば、未利用ポイント数を持たない設計にすると、消込は毎回過去の利用履歴を総当たりして計算するしかなく、システム要件として現実的でなくなります。本問がこの項目を要求しているのは、論理設計が運用の実現性まで含むことを理解しているかを見たいからです。 本問の出題趣旨をまとめると、現状の予約・宿泊・精算・割引券という複合業務を、予約時点と実績時点の差を崩さずにモデル化できるか、そして追加要件のポイント制を、履歴一元管理と消込可能性を担保したデータモデルとして設計できるかを評価しています。採点講評で差がつきやすいのは、宿泊側への館内施設割引券番号の落とし、割引券発行判定を予約ではなく宿泊実績に置く点、ポイント付与に未利用ポイント数を持たせて消込を成立させる点です。これらはいずれも、与件の一文がそのまま設計制約になる箇所であり、読み飛ばしや思い込みで設計すると崩れるポイントになっています。 この動画を通じて視聴者が学べるのは、令和5年度 秋期 データベーススペシャリスト 午後Ⅰ 問2の解答根拠だけではありません。予約と実績の分離、種類とタイミングが異なる特典の管理、サブタイプを使った整合、共通台帳＋事象別詳細、残高を持つことで消込を実現する、といった午後Ⅰの設計問題で頻出の設計原則を、具体的に再現できる形で身に付けられます。 最後に、本動画を見る意義をまとめます。データベーススペシャリストの午後Ⅰは、設計の知識を問う試験であると同時に、与件の業務ルールをモデルの制約へ写像する試験です。本動画では、ホテル予約という題材を通じて、どこで確定する情報をどのエンティティに持たせるべきか、どの制約をどの属性で判定するのか、ポイント制の消込を成立させるためにどのデータ項目が不可欠かを、論理の流れとして整理しました。過去問の理解を、次の午後Ⅰ設計問題でも通用する実戦的な設計思考へ変えるために、ぜひ本動画を活用してください。
