データベーススペシャリスト試験 2023年 午後1 問02
ホテルの予約システムの概念データモデリングに関する次の記述を読んで、設問よ。
ホテルを運営する X 社は、予約システムの再構築に当たり、現状業務の分析及び新規要件の洗い出しを行い、概念データモデル及び関係スキーマを設計した。
〔現状業務の分析結果 〕
1.ホテル
(1) 全国各地に10のホテルを運営している。 ホテルはホテルコードで識別する。
(2) 客室はホテルごとに客室番号で識別する。
(3) 客室ごとに客室タイプを設定する。 客室タイプはホテル共通であり、客室タイプコードで識別する。 客室タイプにはシングル、ツインなどがある。
(4) 館内施設として、レストラン、ショップ、プールなどがある。
2.会員
利用頻度が高い客向けの会員制度があり、会員は会員番号で識別する。 会員には会員番号が記載された会員証を送付する。
3.旅行会社
X 社のホテルの宿泊予約を取り扱う複数の旅行会社があり、旅行会社コードで識別する。
4.予約
(1) 自社サイト予約と旅行会社予約があり、予約区分で分類する。
(2) 自社サイト予約では、客は X 社の予約サイトから予約する。 旅行会社予約では、客は旅行会社を通じて予約する。 旅行会社の予約システムから X 社の予約システムに予約情報が連携され、どの旅行会社での予約かが記録される。
(3) 1回の予約で、客は宿泊するホテル、客室タイプ、泊数、客室数、宿泊人数チェックイン予定年月日を指定する。 予約は予約番号で識別する。
(4) 宿泊時期、予約状況を踏まえて、予約システムで決定した1室当たりの宿泊料金を記録する。
(5) 客が会員の場合、会員番号を記録する。 会員でない場合は、予約者の氏名と住所を記録する。
5.宿泊
客室ごとのチェックインからチェックアウトまでを宿泊と呼び、ホテル共通の宿泊番号で識別する。
6.チェックイン
フロントで宿泊の手続を行う。
(1) 予約有の場合には該当する予約を検索し、客室を決め、宿泊を記録する。 泊数、宿泊人数、宿泊料金は、予約から転記する。 泊数、宿泊人数 宿泊料金が予約時から変更になる場合には、変更後の内容を記録する。
(2) 予約無の場合には泊数、宿泊人数、宿泊料金を確認し、客室を決め、宿泊を記録する。
(3) 宿泊者が会員の場合、会員番号を記録する。 ただし、予約有の場合で宿泊者が予約者と同じ場合、予約の会員番号を宿泊に転記する。
(4) 一つの客室に複数の会員が宿泊する場合であっても記録できるのは、代表者1人の会員番号だけである。
(5) 宿泊ごとに宿泊者全員の氏名、住所を記録する。
(6) 客室のカードキーを宿泊客に渡し、チェックイン年月日時刻を記録する。
7.チェックアウト
フロントで客室のカードキーを返却してもらう。 チェックアウト年月日時刻を記録する。
8.精算
(1) 通常、チェックアウト時に宿泊料金を精算するが、客が希望すれば、予約時又はチェックイン時に宿泊料金を前払いすることもできる。
(2) 宿泊客が館内施設を利用した場合、その場で料金を支払わずにチェックアウト時にまとめて支払うことができる。 館内施設の利用料金は予約システムとは別の館内施設精算システムから予約システムに連携される。
9.会員特典
会員特典として、割引券を発行する。 券面には割引券を識別する割引券番号と発行先の会員番号を記載する。 割引券には宿泊割引券と館内施設割引券があり、割引券区分で分類する。 1枚につき、1回だけ利用できる。 割引券の状態には未利用、利用済、有効期限切れによる失効があり、割引券ステータスで分類する。
(1) 宿泊割引券
① 会員の宿泊に対して、次回以降の宿泊料金に充当できる宿泊割引券を発行し、郵送する。 1回の宿泊で割引券を1枚発行し、泊数に応じて割引金額を変える。 旅行会社予約による宿泊は発行対象外となる。 発行対象の宿泊かどうかを割引券発行区分で分類する。
② 予約時の前払いで利用する場合、宿泊割引券番号を記録する。 1回の予約で1枚を会員本人の予約だけに利用できる。
③ ホテルでのチェックイン時の前払い、チェックアウト時の精算で利用する場合、宿泊割引券番号を記録する。 1回の宿泊で1枚を会員本人の宿泊だけに利用できる。
(2) 館内施設割引券
① 館内施設割引券を発行し、定期的に送付している会員向けのダイレクトメールに同封する。 館内施設の利用料金に充当できる。 チェックアウト時の精算だけで利用できる。
② チェックアウト時の精算で利用する場合、館内施設割引券番号を記録する。 1回の宿泊で1枚を会員本人の宿泊だけに利用できる。 宿泊割引券との併用が可能である。
〔新規要件〕
会員特典として宿泊時にポイントを付与し、次回以降の宿泊時の精算などに利用できるポイント制を導入する。 ポイント制は次のように運用する。
(1) 会員ランクにはゴールド、シルバー、ブロンズがあり、それぞれの必要累計泊数及びポイント付与率を決める。 ポイント付与率は上位の会員ランクほど高くする。
(2) 毎月末に過去1年間の累計泊数に応じて会員の会員ランクを決める。
(3) チェックアウト日の翌日午前 0 時に宿泊料金にポイント付与率を乗じたポイントを付与する。 この場合のポイントの有効期限年月日は付与日から1年後である。
(4) 宿泊料金に応じたポイントとは別に、個別にポイントを付与することがある。この場合のポイントの有効期限年月日は1年後に限らず、任意に指定できる。
(5) ポイントを付与した際に、有効期限年月日及び付与したポイント数を未利用ポイント数の初期値として記録する。
(6) ポイントは宿泊料金、館内施設の利用料金の支払に充当でき、これを支払充当と呼ぶ。 支払充当では、支払充当区分 (予約時、チェックイン時、チェックアウト時のいずれか)、ポイントを利用した予約の予約番号又は宿泊の宿泊番号を記録する。
(7) ポイントは商品と交換することもでき、これを商品交換と呼ぶ。 商品ごとに交換に必要なポイント数を決める。 ホテルのフロントで交換することができる。 交換時に商品と個数を記録する。
(8) 支払充当、商品交換でポイントが利用される都度、その時点で有効期限の近い未利用ポイント数から利用されたポイント数を減じて、消し込んでいく。
(9) 未利用のまま有効期限を過ぎたポイントは失効し、未利用ポイント数を 0 とする。 失効の1か月前と失効後に会員に電子メールで連絡する。 失効前メール送付日時と失効後メール送付日時を記録する。
(10) ポイントの付与、支払充当、商品交換及び失効が発生する都度、ポイントの増減区分、増減数及び増減時刻をポイント増減として記録する。 具体例を表1に示す。

〔概念データモデルと関係スキーマの設計〕
1.概念データモデル及び関係スキーマの設計方針
(1) 概念データモデル及び関係スキーマの設計は、まず現状業務について実施しその後に新規要件に関する部分を実施する。
(2) 関係スキーマは第3正規形にし、多対多のリレーションシップは用いない。
(3) 概念データモデルでは、リレーションシップについて、対応関係にゼロを含むか否かを表す “○” 又は“●”は記述しない。
(4) サブタイプが存在する場合、他のエンティティタイプとのリレーションシップは、スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する。
2.〔現状業務の分析結果〕 に基づく設計
現状の概念データモデルを図1に、関係スキーマを図2に示す。


3.〔新規要件〕 に関する設計
新規要件に関する概念データモデルを図3に、関係スキーマを図4に示す。


解答に当たっては、巻頭の表記ルールに従うこと。 また、エンティティタイプ名、関係名、属性名は、それぞれ意味を識別できる適切な名称とすること。 関係スキーマに入れる属性名を答える場合、主キーを表す下線、外部キーを表す破線の下線についても答えること。
設問1:現状の概念データモデル及び関係スキーマについて答えよ。
(1)図1中の欠落しているリレーションシップを補って図を完成させよ。
模範解答

解説
解答の論理構成
-
「ホテル」と「予約」
- 【問題文】4.(3) にある「宿泊するホテル … を指定する」。予約はホテルを参照するため「ホテル」→「予約」。
-
「客室タイプ」と「客室」
- 【問題文】1.(3)「客室ごとに客室タイプを設定する」。客室が客室タイプを参照するので「客室タイプ」→「客室」。
-
「旅行会社」と「予約」
- 【問題文】4.(2)「どの旅行会社での予約かが記録される」。旅行会社を外部キーとして予約に保持するため「旅行会社」→「予約」。
-
「会員」と「割引券」
- 【問題文】9. に「券面には…発行先の会員番号を記載」とあることから「会員」→「割引券」。
-
「宿泊割引券」「館内施設割引券」と「宿泊」
- 【問題文】9.(1)①「1回の宿泊で割引券を1枚発行し…発行元宿泊番号を保持」
- 【問題文】9.(2)②「1回の宿泊で1枚を…利用できる」
従って両サブタイプが宿泊に外部キーを持つ。スーパータイプ「割引券」を介さずサブタイプ—宿泊を直接結ぶ。
-
方向性の確認
設計方針1.(2)「多対多のリレーションシップは用いない」に従い、すべて1対多(親→子)の実線矢印でモデル化する。
誤りやすいポイント
- 「客室」→「客室タイプ」と矢印方向を逆に描くミス
“設定する”主体は客室、参照されるのは客室タイプ。 - 「割引券」⇔「宿泊」の直接リンク
発行・利用はサブタイプ単位。スーパータイプとの関係を付けると第3正規形に抵触しやすい。 - 旅行会社と客室を結んでしまう
【問題文】1.(2)・4.(2) に客室と旅行会社の直接関係は記述されていない。
FAQ
Q: サブタイプとスーパータイプ両方に同じ外部キーを置くのはダメですか?
A: 設計方針1.(4)が示す通り「スーパータイプ又はいずれかのサブタイプの適切な方」のみとします。今回は発行・利用単位がサブタイプなのでスーパータイプには置きません。
A: 設計方針1.(4)が示す通り「スーパータイプ又はいずれかのサブタイプの適切な方」のみとします。今回は発行・利用単位がサブタイプなのでスーパータイプには置きません。
Q: 「予約有宿泊」へのリンクは追加不要ですか?
A: 不要です。図1に既に「宿泊」→「予約有宿泊」が描かれており、予約との多重リンクは単一で十分です。
A: 不要です。図1に既に「宿泊」→「予約有宿泊」が描かれており、予約との多重リンクは単一で十分です。
Q: 「割引券発行対象宿泊」とのリレーションは?
A: こちらも既に図1に存在します(「宿泊」→「割引券発行対象宿泊」)。追加の必要はありません。
A: こちらも既に図1に存在します(「宿泊」→「割引券発行対象宿泊」)。追加の必要はありません。
関連キーワード: ER図、リレーションシップ、第3正規形、サブタイプ、外部キー
設問1:現状の概念データモデル及び関係スキーマについて答えよ。
(2)図2中の(ア)〜(エ)に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
ア:客室タイプコード
イ:ホテルコード、客室タイプコード、旅行会社コード、宿泊割引券番号
ウ:ホテルコード、客室番号、宿泊割引券番号、館内施設割引券番号
エ:予約番号
解説
解答の論理構成
-
客室(ホテルコード、客室番号、(ア))
- “客室ごとに客室タイプを設定する。 客室タイプはホテル共通であり、客室タイプコードで識別する。”
- よって客室⇔客室タイプは多対1。“ホテル共通”なので主キーに含めず外部キー “客室タイプコード” だけを追加する。
-
予約(… 会員番号、(イ))
- “客は宿泊するホテル、客室タイプ…を指定する。” → ホテルを識別する “ホテルコード”、客室タイプを識別する “客室タイプコード” が必須。
- “どの旅行会社での予約かが記録される。” → “旅行会社コード”。
- “予約時の前払いで利用する場合、宿泊割引券番号を記録する。” → “宿泊割引券番号”。
- 以上 4 つを(イ)に列挙。
-
宿泊(… 会員番号、(ウ))
- チェックイン時に実際に割り当てた客室を保持するため “ホテルコード、客室番号”。
- 割引券利用は宿泊時でも起こる(宿泊割引券と館内施設割引券)
“チェックイン時の前払い…宿泊割引券番号を記録する。”“チェックアウト時の精算で利用する場合…館内施設割引券番号を記録する。” - したがって “宿泊割引券番号、館内施設割引券番号” を格納。
-
予約有宿泊(宿泊番号、(エ))
- “予約有の場合には該当する予約を検索し…宿泊を記録する。”
- 1 つの宿泊は必ず 1 つの予約に対応するため、追加属性は主キー “予約番号” だけでよい。
誤りやすいポイント
- 予約リレーションに“ホテルコード”を入れ忘れ、客室タイプだけでホテルを特定できると誤解する。
- 割引券番号を一つにまとめ、宿泊割引券と館内施設割引券を区別しない。
- 予約有宿泊にホテルや客室情報を重複配置し、第3正規形を崩してしまう。
- “館内施設の利用料金は…別の…システムから連携”という記述を“館内施設割引券は予約で利用できる”と取り違える。
FAQ
Q: 予約に“客室番号”を入れなくてよいのですか?
A: “1回の予約で…客室数”を指定するだけで具体的な客室は未確定です。確定するのはチェックイン時なので、客室番号は宿泊リレーションで保持します。
A: “1回の予約で…客室数”を指定するだけで具体的な客室は未確定です。確定するのはチェックイン時なので、客室番号は宿泊リレーションで保持します。
Q: 割引券番号を別テーブルに分けずに宿泊に持つと第3正規形違反ですか?
A: 割引券情報(割引金額など)は“割引券”リレーションで一元管理されており、宿泊側には外部キーだけを置くため第3正規形を満たします。
A: 割引券情報(割引金額など)は“割引券”リレーションで一元管理されており、宿泊側には外部キーだけを置くため第3正規形を満たします。
Q: 旅行会社経由の宿泊でも割引券は発行されますか?
A: “旅行会社予約による宿泊は発行対象外”とあり、発行可否を示す“割引券発行区分”を宿泊リレーションに持たせています。
A: “旅行会社予約による宿泊は発行対象外”とあり、発行可否を示す“割引券発行区分”を宿泊リレーションに持たせています。
関連キーワード: 第3正規形、外部キー、リレーションシップ、サブタイプ、正規化
設問2:現状の業務処理及び制約について答えよ。
(1)割引券発行区分の値が発行対象となる宿泊の条件を表 2 にまとめた。予約有の場合は番号1と2, 予約無の場合は番号3の条件を満たしている必要がある。表2中の(a)〜(d)に入れる適切な字句を答えよ。


模範解答
a:宿泊
b:会員番号
c:予約区分 又は 旅行会社コード
d:自社サイト予約 NULL
解説
解答の論理構成
-
会員であることの判定
【問題文】「(4) 一つの客室に複数の会員が宿泊する場合であっても記録できるのは、代表者1人の会員番号だけである。」
また図2 “宿泊(宿泊番号、…、会員番号、…)” に “会員番号” が存在します。
よって割引券発行対象判定の第1条件は “該当する宿泊の会員番号が NULL でないこと”。
⇒ (a) 宿泊、(b) 会員番号 -
旅行会社予約は対象外
【問題文】「旅行会社予約による宿泊は発行対象外となる。」
判定方法は2通り。
① “予約区分” が “自社サイト予約” のみを対象にする。
② “旅行会社コード” が NULL なら旅行会社経由ではないと判断できる。
図2 “予約(予約番号、…、予約区分、…、会員番号、旅行会社コード)”
よって (c) は “予約区分” または “旅行会社コード”、(d) はそれぞれ “自社サイト予約” または “NULL”。 -
予約無しの場合
【問題文】「予約無の場合には泊数、宿泊人数、宿泊料金を確認し、… 宿泊を記録する。」
予約が無い場合は“宿泊”しか参照できないため、条件3も “宿泊.会員番号” をチェックすることになる。
誤りやすいポイント
- “予約.会員番号” を使うと条件3(予約無の場合)を判定できなくなる。
- “旅行会社コード = ''(空文字)” と考えてしまう。仕様では NULL が正しい。
- “宿泊区分” という属性名があると勘違いする。図2にそのような属性は無い。
FAQ
Q: 「予約区分」と「旅行会社コード」の両方を使わずにどちらか一方で良いのですか?
A: はい。いずれか一方で旅行会社経由かどうかを判定できます。「予約区分 = 自社サイト予約」でも「旅行会社コード が NULL」でも意味は同じです。
A: はい。いずれか一方で旅行会社経由かどうかを判定できます。「予約区分 = 自社サイト予約」でも「旅行会社コード が NULL」でも意味は同じです。
Q: 予約有の場合だけ“宿泊.会員番号”を参照するのは冗長に感じます。
A: 割引券発行判定では宿泊代表者が会員かどうかを確実に判断する必要があるため、実際にチェックインした “宿泊” で確認する方が確実です。
A: 割引券発行判定では宿泊代表者が会員かどうかを確実に判断する必要があるため、実際にチェックインした “宿泊” で確認する方が確実です。
Q: “会員番号” が NULL でも他の宿泊者が会員の場合はどうなりますか?
A: 【問題文】「記録できるのは、代表者1人の会員番号だけである。」とあるため、代表者が非会員なら割引券発行対象外です。
A: 【問題文】「記録できるのは、代表者1人の会員番号だけである。」とあるため、代表者が非会員なら割引券発行対象外です。
関連キーワード: 正規化、外部キー、NULL値、条件判定、リレーションシップ
設問2:現状の業務処理及び制約について答えよ。
(2)予約時に割引券を利用する場合の制約条件を表3にまとめた。番号 1〜3 全ての条件を満たしている必要がある。、予約時に割引券を利用する場合の制約条件を表3にまとめた。番号1〜3 全ての条件を満たしている必要がある。表3中の(e)~(j)に入れる適切な字句を答えよ。


模範解答
e:割引券ステータス 又は 割引券区分
f:未利用 又は 宿泊割引券
g:割引券区分 又は 割引券ステータス
h:宿泊割引券 又は 未利用
i:会員番号
j:会員番号
解説
解答の論理構成
- 割引券の状態について
【問題文】「割引券の状態には未利用、利用済、有効期限切れによる失効があり、割引券ステータスで分類する。」
⇒ 条件1は “使える状態か” をチェックするので
e=割引券ステータス、f=未利用 - 割引券の種類について
【問題文】(1)宿泊割引券 ②「予約時の前払いで利用する場合、宿泊割引券番号を記録する。」
⇒ 条件2は “宿泊割引券であるか” を確認するので
g=割引券区分、h=宿泊割引券 - 本人利用の確認について
【問題文】(1)宿泊割引券 ②「1回の予約で1枚を会員本人の予約だけに利用できる。」
⇒ “本人” を DB で担保するには割引券と予約の “会員番号” を一致させる必要があるので
i=会員番号、j=会員番号
誤りやすいポイント
- 条件1と条件2を逆にし、「未利用」を “割引券区分” に当てはめてしまう。
- 割引券を持たない非会員予約で「会員番号」が NULL になり得る点を見落とし、本人確認条件を不要と判断する。
- 「宿泊割引券」と「館内施設割引券」を区別せず、どちらも予約時に使えると誤解する。
FAQ
Q: 「利用済」でも予約時に入力できてしまわないようにするには?
A: テーブル「割引券」で “割引券ステータス=未利用” に限定するチェック制約(CHECK 句)や、アプリケーション側の入力バリデーションで弾く実装が必要です。
A: テーブル「割引券」で “割引券ステータス=未利用” に限定するチェック制約(CHECK 句)や、アプリケーション側の入力バリデーションで弾く実装が必要です。
Q: 非会員予約で割引券番号が入力された場合はどう扱う?
A: 割引券と予約の “会員番号” が一致しないため条件3を満たさずエラー扱いとなります。
A: 割引券と予約の “会員番号” が一致しないため条件3を満たさずエラー扱いとなります。
Q: 「宿泊割引券」と「館内施設割引券」の両方を同一予約で使わせない仕組みは?
A: 今回の設問範囲外ですが、割引券区分をキーに UNIQUE 制約(予約番号、割引券区分)を設ける方法が典型です。
A: 今回の設問範囲外ですが、割引券区分をキーに UNIQUE 制約(予約番号、割引券区分)を設ける方法が典型です。
関連キーワード: 参照整合性、第3正規形、CHECK制約、エンティティ設計、ビジネスルール
設問3:新規要件に関する概念データモデル及び関係スキーマについて答えよ。
(1)図3中の欠落しているリレーションシップを補って図を完成させよ。なお、図3にないエンティティタイプとのリレーションシップは不要とする。
模範解答

解説
解答の論理構成
-
「会員ランク」→「会員」
【問題文】「(1) 会員ランクにはゴールド、シルバー、ブロンズがあり、それぞれの必要累計泊数及びポイント付与率を決める。」
会員は必ず 1 つのランクを持ち、ランク側は多数の会員を持つので 1:N。 -
「会員」→「ポイント増減」
【問題文】「(10) ポイントの付与、支払充当、商品交換及び失効が発生する都度、... をポイント増減として記録する。」
ポイント増減は個々の会員に属する履歴であり、会員 1:N ポイント増減。 -
「ポイント増減」→各イベント(4 本)
同じ箇所で「付与」「支払充当」「商品交換」「失効」をすべて“ポイント増減”の一種として扱う必要がある。設計方針(4)より「スーパータイプ又はいずれかのサブタイプの適切な方」とあるため、「ポイント増減」⇔サブタイプのリレーションシップ 1:1(継承/可換関係)を設定。 -
「商品」→「商品交換」
【問題文】「(7) 商品ごとに交換に必要なポイント数を決める。」および「交換時に商品と個数を記録する。」
商品はマスタ、交換は取引明細。商品 1:N 商品交換。
以上 4 本を追加すれば論理整合が取れ、第3正規形も維持されます。
誤りやすいポイント
- 「会員」⇔「会員ランク」を多対多で捉える誤り
ランクは月次計算で上書きされる属性であり、多重所属は起こらない。 - 「商品交換」から「ポイント増減」を張る誤り
サブタイプ—スーパータイプ関係を逆に描くと冗長テーブルが発生。 - 「支払充当」から「予約」「宿泊」へ直接 1:N を追加する誤り
図3で要求されていないエンティティとの線を足すと出題条件「図3にないエンティティタイプとのリレーションシップは不要」に抵触。
FAQ
Q: 「ポイント付与」と「ポイント増減」は別テーブルにしなければいけませんか?
A: はい。設計方針(4)が示すスーパー/サブタイプ構造に合わせ、「ポイント増減」を履歴の共通項目テーブル、「ポイント付与」をその詳細テーブルとします。
A: はい。設計方針(4)が示すスーパー/サブタイプ構造に合わせ、「ポイント増減」を履歴の共通項目テーブル、「ポイント付与」をその詳細テーブルとします。
Q: 「商品交換」は「商品」だけでなく「会員」とも直接つなぐべきでは?
A: 「商品交換」→「会員」は「ポイント増減」を介してすでに関連付けられています。冗長な直接接続は正規化原則に反します。
A: 「商品交換」→「会員」は「ポイント増減」を介してすでに関連付けられています。冗長な直接接続は正規化原則に反します。
Q: 「会員ランク」更新時の履歴管理はどこで保持しますか?
A: 本設問の範囲はリレーションシップ補完のみです。ランク履歴を残すなら別途「会員ランク履歴」テーブルを設計しますが、今回は要求されていません。
A: 本設問の範囲はリレーションシップ補完のみです。ランク履歴を残すなら別途「会員ランク履歴」テーブルを設計しますが、今回は要求されていません。
関連キーワード: スーパータイプ、サブタイプ、1対多、正規化、マスタ明細
設問3:新規要件に関する概念データモデル及び関係スキーマについて答えよ。
(2)図4中の(オ)〜(サ)に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
オ:必要累計数、ポイント付与率
カ:商品名、ポイント数
キ:ポイント増減区分、ポイント増減数、ポイント増減時刻
ク:有効期限年月日、未利用ポイント数
ケ:失効後メール送付日時
コ:支払充当区分
サ:商品コード、個数
解説
解答の論理構成
-
会員ランク(オ)
“会員ランクにはゴールド、シルバー、ブロンズがあり、それぞれの必要累計泊数及びポイント付与率を決める。”
⇒累計泊数はランク判定にだけ使う静的値なので“必要累計数”。付与計算用に“ポイント付与率”も必要。 -
商品(カ)
“商品ごとに交換に必要なポイント数を決める。”
商品識別子は既に“商品コード”。残りは“商品名”と“ポイント数”。 -
ポイント増減(キ)
“ポイントの付与、支払充当、商品交換及び失効が発生する都度、ポイントの増減区分、増減数及び増減時刻をポイント増減として記録する。”
よって三属性を追加。連番はキーに含まれているため重複しない。 -
ポイント付与(ク)
“有効期限年月日及び付与したポイント数を未利用ポイント数の初期値として記録する。”
未利用は付与時点でのみ設定され、以後は消し込みで減算されるため本エンティティに保持。 -
ポイント失効(ケ)
“失効の1か月前と失効後に会員に電子メールで連絡する。 失効前メール送付日時と失効後メール送付日時を記録する。”
失効エンティティが扱うのは失効発生レコードなので“失効後メール送付日時”のみで十分。 -
支払充当(コ)
“支払充当では、支払充当区分 (予約時、チェックイン時、チェックアウト時のいずれか)…を記録する。”
区分名をそのまま“支払充当区分”として追加。 -
商品交換(サ)
“交換時に商品と個数を記録する。”
商品コードは商品表への外部キーなので商品コード、取引数量は“個数”。
誤りやすいポイント
- 有効期限と未利用ポイント数を「ポイント増減」に入れて第3正規形を崩してしまう。
- “失効前メール送付日時”まで「ポイント失効」に入れてしまい、将来のリレーションが冗長になる。
- “必要累計泊数”を“累計泊数”と誤記し、ランク判定用か実績値かを混同する。
- “商品交換”で商品名を直接持たせ、商品マスタとの重複を作ってしまう。
FAQ
Q: “ポイント付与率”は整数で良いですか?
A: 要件には “ポイント付与率は上位の会員ランクほど高くする” としかなく百分率・小数点の指定がないため、実装時に適切な型(整数%や小数)を決めます。概念設計では名称だけで十分です。
A: 要件には “ポイント付与率は上位の会員ランクほど高くする” としかなく百分率・小数点の指定がないため、実装時に適切な型(整数%や小数)を決めます。概念設計では名称だけで十分です。
Q: “未利用ポイント数”は常にポイント付与テーブルに置くのですか?
A: 付与時点での残高を持たせ、利用や失効時に更新(減算や0化)していく方式とします。履歴を残したい場合は増減テーブルで差分を追跡できます。
A: 付与時点での残高を持たせ、利用や失効時に更新(減算や0化)していく方式とします。履歴を残したい場合は増減テーブルで差分を追跡できます。
Q: “支払充当”エンティティには予約番号と宿泊番号の両方がありますがキーに入れますか?
A: いずれか一方が設定されるだけなので主キーには含めず、NULL許容または排他制約で実装します。
A: いずれか一方が設定されるだけなので主キーには含めず、NULL許容または排他制約で実装します。
関連キーワード: 第3正規形、エンティティ、外部キー、ポイント管理、データモデリング
設問3:新規要件に関する概念データモデル及び関係スキーマについて答えよ。
(3)ポイント利用時の消込みにおいて、関係 “ポイント付与” の会員番号が一致するインスタンスに対する次の条件について、表1の用語を用いてそれぞれ20字以内で具体的に答えよ。
(a):消込みの対象とするインスタンスを選択する条件
(b):(a)で選択したインスタンスに対して消込みを行う順序付けの条件
模範解答
(a):未利用ポイント数が0より大きい。
(b):有効期限年月日が近い順
解説
解答の論理構成
- 消込み対象の特定
- 要件(8)は“未利用ポイント数から利用されたポイント数を減じて”と記述しており、0の場合は減算不能です。
- したがって(a)は“未利用ポイント数が0より大きい”インスタンスとなります。
- 消込み順序
- 同じ(8)文で“有効期限の近い未利用ポイント数から”と明示されています。
- 近い順=早く到来する順ですから(b)は“有効期限年月日が近い順”となります。
- 表1の用語利用
- インスタンスの属性名として“未利用ポイント数”と“有効期限年月日”が表1に存在し、これらをそのまま用いる必要があります。
誤りやすいポイント
- 「ポイント増減時刻」順と読み違える
- “近い”を“遠い”と逆に解釈する
- 未利用ポイント数=0を含めてしまい対象外レコードを選択してしまう
FAQ
Q: “有効期限年月日が近い順”は昇順・降順どちらですか?
A: 有効期限が早く切れる方から処理するので昇順(小さい日付→大きい日付)です。
A: 有効期限が早く切れる方から処理するので昇順(小さい日付→大きい日付)です。
Q: 未利用ポイント数が同じで有効期限も同一の場合はどうなりますか?
A: 要件には追加規定がないため、実装側で増減連番などの二次キーを用いて任意に順序付けすれば要件を満たせます。
A: 要件には追加規定がないため、実装側で増減連番などの二次キーを用いて任意に順序付けすれば要件を満たせます。
関連キーワード: ポイント管理、有効期限、データモデリング、インスタンス更新
