この記事について
データベーススペシャリスト試験の解き方にはコツがあります。そのコツは多くの過去問に取り組む中で各自が編み出しています。
私が編み出したコツのうち、汎用的に使えそうなコツを集めてみました。もし参考になるものが1つでも見つかれば幸いです。
なお、私が解いた過去問の主な範囲は平成24～31年度となります。
心構え・準備
全部解けなくても落ち込まない・諦めない
午後問題は時間が足りないとしばしば感じました。時には全問解く前に時間切れとなることもありました。
ですが、基準点は60点となっています。つまり、6割解ければ合格を認められる実力があるということです。半分より少し解ければ合格の可能性があると考え、最後まで諦めずに頑張りましょう。
教科書の説明に納得がいかなければ他の著者の教科書もチェックしてみる
データベーススペシャリスト試験の教科書の半分は過去問解説といえます。ダウンロード提供の過去問解説を含めれば、大半が過去問解説です。
教科書の過去問解説に納得のいかないときは他の著者の教科書もチェックしてみましょう。著者によって解説の切り口が異なるため、新たな視点で気付きがあるかもしれません。また、IPAの解答例が唯一の解答とは限らないという発見をするかもしれません。
教科書の過去問解説の傾向の違いとして2冊を挙げます。リンク先は私が実際に参考とした年度版です。
データベーススペシャリスト（翔泳社、著者代表：三好康之）はIPAの解答例を重視した解説となっています。
データベーススペシャリスト合格教本（技術評論社、著者：金子則彦）はIPAの解答例を絶対視せず、著者の解答例を併記しています。
持ち込める物は最大限活用する
概念データモデルのリレーションシップをきれいに描くためには定規が必須です。フリーハンドで描いた線が曲がって描き直している時間はありません。定規を用意しましょう。
また、替えのシャープペンシル、消しゴムも用意しておきましょう。シャープペンシルは事前に替え芯を詰めておくことも忘れずに。
試験開始時刻の20分前に着席する
試験監督官からの注意事項の説明を受けるため、試験開始時刻の20分前に着席します。
説明が始まってから入室すると、試験監督官から個別説明を受けることになります。個別の説明が試験開始時刻までに終わらないと、同じ部屋の受験生全員が試験開始を待たされます。試験終了時刻もその分延びますが、その後の休憩時間が短くなることを考えると、自分だけでなく他の受験生も不利益を被ることになります。
自分のためだけでなく、他の受験生の為にも集合（着席）時間を守りましょう。
全般
関数従属性
関数従属性の見極め方
関数従属とは「項目Xの値を決定すると、項目Yの値が一つに決定される」ということが成立する時で、X→Yと表記されます。
「項目Yの値が一つに決定される」というのがポイントで、項目Yの値が複数決定する場合は関数従属性がありません。
○ 関数従属性が存在する場合の表現
「梱包ID：梱包を一意に識別するID」
梱包IDが決まれば梱包に関する属性が決まる。
「一つのラベルには、高々一つの手順書が対応付けられる。」
ラベルIDが決まれば手順書IDが決まる。
ただし、"高々" とは "多くとも" と同義であり、ラベルIDが決まっても対応する手順書IDが存在しないこともあります。被決定項が存在しないケースもある関数従属性が妥当であるかは議論の余地がありそうですが、過去の出題では関数従属性ありと判断しています（平成24年度午後Ⅰ問1設問1）。
× 関数従属性が存在しない場合の表現
「一つの手順書には、用途に応じて0個以上のラベルが対応付けられる。」
手順書IDが決まってもラベルIDが一つに決まるとは限らず、複数のラベルが対応することもある。
相互に関数従属性を持っている属性は推移的関数従属性において同じものとみなす
平成25年度午後Ⅰ問1設問2(1) の推移的関数従属性の問題を例に挙げます。
関数従属性の図からは以下のような関係が読み取れました。
{プロバイダID, サービス機能ID, 利用者ID} → {リソースID} ⇔ {URI} → {リソース種別, リソース名称, 配信スキーマ}
"{リソースID} ⇔ {URI}" は "{リソースID} → {URI}" かつ "{URI} → {リソースID}" であることを表現しています。
相互に関数従属性を持っている属性は推移的関数従属性において同じものとみなし、推移的関数従属性は以下の2つとなります。
{プロバイダID, サービス機能ID, 利用者ID} → {リソースID} → {リソース種別, リソース名称, 配信スキーマ}
{プロバイダID, サービス機能ID, 利用者ID} → {URI} → {リソース種別, リソース名称, 配信スキーマ}
関係スキーマ
概念データモデルと関係スキーマは番号を振って対応付ける
問題を解く中で概念データモデルと関係スキーマを繰り返し参照しますが、初見だとその位置関係などが頭に入っておらず、図から探し回ることがあります。参照回数が多いため、探し回ることによる時間ロスが無視できないほど大きくなります。
そこで、概念データモデルと関係スキーマに番号を振って対応付けします。お勧めはまず関係スキーマで上から順に番号を振り、それと対応する概念データモデルに番号を記入する方法です。余裕があれば問題文で登場する関係スキーマにも対応する番号を記入してもよいでしょう。
テーブル構造に対しても同じテクニックを使うことができます。ただし、関係スキーマとテーブル構造は必ずしも1:1とは限らない（変換の過程で分割・結合を行うことがある）ことに注意が必要です。
「未完成」のテーブル構造／関係スキーマ
問題で「未完成」のテーブル構造／関係スキーマを示されることがあります。穴埋め問題として出題されることがしばしばありますが、それ以外の問題を解くために出題されていない未完成部分を埋めるように求められることがあります。
平成26年度午後Ⅱ問2設問1(1) を例に挙げます。未完成の概念データモデルを完成させる出題でした。そして、未完成のテーブル構造として下図が示されていました。
【テーブル構造】
客室タイプ（客室タイプコード, 客室タイプ名, 定員, 備考）
客室（ホテルコード, 客室番号, 客室タイプコード, …）
未完成のテーブル構造に不自然な空行があることから、テーブルが追加されるであろうこと、またそれが概念データモデルに追加されることも想像できます。
ですが、このテーブル構造にはさらに未完成の部分がありました。"客室" に主キーがありません。実はこれも未完成の部分であり、概念データモデルのリレーションシップを追加するために必要な情報でした。
このように未完成の図に対しては出題の有無にかかわらず、不自然な箇所が無いか、それが実は未完成の部分でないかを見分けることが必要です。
関係スキーマの属性で主キーが先頭に並ぶとは限らない
関係スキーマの属性で主キーは先頭に並ぶことが多く、解答のヒントになります。ですが、これに反する記述のこともあるので、過信しないことが必要です。
平成25年度午後Ⅰ問1図1 で提示されていた関係スキーマです。
一見すると属性名称及び順序から "組織" の主キーは {組織ID} となりそうです。ですが、「表1 属性とその意味及び制約」で組織登録日付は『組織情報を登録、変更した日付。組織情報（組織名称、郵便番号）は、履歴が管理される。』とあり、"組織" の主キーは {組織ID, 組織登録日付} であったことが分かります。
属性名は具体的に命名する
例えば「社員コード」を参照する属性（外部キー）を命名する際に、「社員コード」のままとするか、「技術営業社員コード」のようにより具体的な命名とするべきか、悩むことがあります。
どちらが好ましいかは問題に付属する表記ルールに記載がありませんし、手持ちのテキスト2冊を確認しても明確な判断基準は示されていませんでした。また、解答例からもその基準を読み取ることができませんでした。
そこで、判断に迷った際は属性名をより具体的に命名するほうが好ましい、と考えることにしました。私のDAとしての師匠からも、項目名だけで項目の意味を分かるようにすべきと指導を受けてきたからです。
仮に具体的に命名しすぎて減点のリスクがあるとしても、逆に抽象的過ぎて減点されるリスクも考えられます。よって、このリスクを気にしすぎるのは妥当でないと判断しました。
概念データモデルと関係スキーマの対応関係を見直す
概念データモデルと関係スキーマは同時に出題されることが多いです。
概念データモデルの出題としては不足しているエンティティタイプやリレーションシップを追加することが求められます。一通り解き終えた後は関係スキーマとの対応関係を確認し、描き漏らしたエンティティタイプやリレーションシップが無いことを確認します。
複数のサブタイプを参照する際は共通のスーパータイプとリレーションシップを設定する
平成31年度午後Ⅱ問1設問1(1) を例に挙げます。
問題文には以下の記載がありました。
『内製成型材料には、そのレシピとして、1回の製造に使用する、幾つかの品目（生地材料又は原材料）とその使用量を設定する。』
【概念データモデル】
概念データモデルで "生地材料" と "原材料" は "貯蔵品目" のサブタイプとなっています。この場合、"成形材料レシピ" と "貯蔵品目" の間にリレーションシップを設定します。
テーブル構造の穴埋め問題は同じようなテーブルをヒントにする
テーブル構造の穴埋め問題では同様の意味・構成を持つテーブルが他に無いか、有ればそれをヒントに解けないかを考えます。
平成30年度午後Ⅱ問1設問1(1) を例にします。"一般経費申請" と "仮払金申請" のテーブル構造と業務の流れが似ています。ここから、"仮払金申請" の穴埋め箇所には "一般経費申請" と同様の項目が入ると推測できます。
親エンティティの主キー兼外部キーを引き継いだ時、子エンティティに外部キー参照を設定しなくてよい
平成25年度午後Ⅱ問2 を例に挙げます。
【関係スキーマ】
販売（店舗コード, 販売年月日, 販売連番, …）
販売明細（店舗コード, 販売年月日, 販売連番, 販売明細番号, …）
【概念データモデル】
"販売" の主キーの一部である "店舗コード" は "店舗.店舗コード" を外部キー参照しています。
"販売" の子エンティティである "販売明細" は "販売" の主キーを引き継ぎますが、"販売明細.店舗コード" で "店舗.店舗コード" を外部キー参照することはありません。これは親エンティティの "販売.店舗コード" で "店舗.店舗コード" を外部キー参照して参照整合性制約を保証しており、子エンティティはその保証も引き継ぐからです。
連関エンティティの主キーは関連するエンティティの主キーで構成されるとは限らない
連関エンティティの主キーは関連するエンティティの主キーを組み合わせて構成されることが多いですが、必ずしもそうとは限らないことに注意が必要です。
平成24年度午後Ⅱ問2設問2 を例に挙げます。
【関係スキーマ】
コース料理用プレート（コース料理用プレートコード）
コース料理構成（コース料理商品コード, 明細番号, コース料理用プレートコード）
【概念データモデル】
連関エンティティである "コース料理構成" の主キーは "コース料理" と "コース料理用プレート" の主キーを組み合わせて {コース料理商品コード, コース料理用プレートコード} とするのが定番です。ですが、ここでは問題文で "コース料理構成" の主キーとして {コース料理商品コード, 明細番号} という構成が与えられていました。そこで、"コース料理用プレートコード" は外部キーとして定義されることになりました。
物理設計
概念データモデルとテーブル構造でリレーションシップが一致するとは限らない
概念データモデルをテーブル構造へ変換するのには様々なパターンがあります。大まかなパターンを示した記事がありますので参照ください。
スーパータイプ／サブタイプのテーブルへの実装 - Qiita
概念データモデルからテーブル構造への変換に際し、リレーションシップに差異が出た例として、平成25年度午後Ⅱ問1設問1(1) を例に挙げます。
【概念データモデル】
【テーブル構造】
概念データモデルでは "調達先" というスーパータイプと、"支払先" と "仕入先" というサブタイプがあります。これをテーブル構造へ変換する際、"調達先" というテーブルにまとめています。
概念データモデルで "仕入先.支払先コード" から "支払先.調達先コード" を参照していたリレーションシップがありました。これはテーブル構造へ変換した際、"調達先.支払先コード" から "調達先.調達先コード" へのリレーションシップとなりました。
このように概念データモデルとテーブル構造の変換でリレーションシップの接続も変わることがあることに注意します。
関係スキーマとテーブル構造を混同しない
関係スキーマとテーブル構造を同一問題で取り上げることがあります。表記だけではいずれであるかを識別できないので、図の説明から「関係スキーマ」と「テーブル構造」のどちらであるかを判断してください。
平成26年度午後Ⅰ問3 を例に挙げます。この問題の図1で関係スキーマを、図2でテーブル構造を示していました。同じ "商品" でも概念データモデル⇒テーブル構造の変換（この例ではサブタイプをスーパータイプに統合）によって構成が異なっています。
【関係スキーマ】
単品商品（商品番号, 社内原価）
セット商品（商品番号, 化粧箱番号, 詰合せ日数）
【テーブル構造】
冷静にみれば判断できることでも、時間に追われると混同しがちなので気を付けましょう。
計算問題は端数に注意
試験では電卓を利用できないため、計算結果は計算しやすい数字になることがほとんどです。大きい数字の割り算で変な端数が出た時は計算ミスの可能性を疑ってみても良いかもしれません。
データ所要量の計算でありがちなミスを以下に挙げます。
- NULL識別用のフラグのサイズを含め忘れた。
- 問題文で NOT NULL 制約を指定しない列にはNULL識別用の1バイトのフラグを付加すると指示される。
- 空き容量率を考慮に入れ忘れた。
集約関数の対象が0行やNULLを含む場合の結果に注意
集約関数の対象行が0行やNULLを含む場合、結果として0ではなくNULLを返されることがあります。
参考記事を挙げます。
NULLと戯れる: 集約関数とNULL - Qiita
更新情報
2020/10/11
「概念データモデルと関係スキーマは番号を振って対応付ける」を追加しました。
2020/10/14
「サブタイプを見抜く」を追加しました。
2020/10/15
「サブタイプを見抜く」を別記事（概念データモデルのスーパータイプとサブタイプのパターン - ぱと隊長日誌）へ移動しました。
2020/10/26
以下の項目を追加しました。
- 持ち込める物は最大限活用する
- 試験開始時刻の20分前に着席する
- 午前Ⅰ対策として計算問題も準備する
