Database Specialist Examination case studies
Database Specialist Examination · Put your knowledge to work in context.
データベーススペシャリスト試験（略号DB、英語名称Database Specialist Examination）は、IPAが実施する情報処理技術者試験の高度試験の一つです。企業活動を支える膨大なデータ群を管理し、パフォーマンスの高いデータベースシステムを構築して、顧客のビジネスに活用できるデータ分析基盤を提供するデータベース管理者やインフラ系エンジニアを目指す方に適しています。対象者像は、データベースに関係する固有技術を活用し、情報システム基盤の企画・要件定義・開発・運用・保守で中心的な役割を果たす人材です。データ資源管理、データモデリング、論理・物理設計、SQL、DBMSのトランザクション・同時実行制御・障害復旧・整合性、性能・運用・セキュリティ・データ利活用が横断的に問われます。2026年度はCBT方式により後期に実施され、科目A-1は30問50分、科目A-2は25問40分の四肢択一、科目B-1は90分で3問出題・2問解答、科目B-2は120分で2問出題・1問解答です。合計300分、60問出題・58問解答となります。現行試験制度は2026年度の実施をもって終了し、2027年度から新試験制度に移行予定です。対策は、概念データモデルと正規化を軸に、SQLを手で書き、障害・性能・セキュリティの事例で設計判断を説明する練習を重ねるのが有効です。過去問題は科目Aで知識の穴を確認し、科目Bで答案構成と時間配分を鍛えてください。. Topics on this exam: Data resource management and data modeling (概念データモデル, data standardization, repository), Database design (logical and physical design, normalization), SQL and database programming (data definition and manipulation), DBMS characteristics: transactions, concurrency control, recovery, integrity, and Database performance, operation, security, and data utilization platforms. The Database Specialist Examination case studies are 5 cases and about 635 words.
1医療機器メーカーの商品マスタ統合におけるコード体系と概念モデルの判断
中堅の医療機器メーカーA社は、旧X社と旧Y社の基幹システムを2025年4月に統合する。商品マスタは約12,000件で、うち約1,800件は両社が同一製品を別コードで持っている。旧X社の商品コードは5桁（大分類1桁＋中分類2桁＋連番2桁）で、大分類は「消耗品」「機器」「試薬」の意味を持つ。旧Y社は英字3桁＋数字4桁で、先頭3文字は製造工場コードである。商品名は全角と半角、カタカナと英字が混在し、「バイアル」と「VIAL」のように同一製品を指す表記が約300組ある。1つの製品に10本入・100本入の包装があり、JANコードと標準価格は包装単位で決まる。ロット番号は製造単位で管理し、同一ロットが複数の包装に分かれる。項目定義書は営業・購買・品質保証の3部門が別々に管理し、同じ「有効期限」が営業では「製造後月数」、品質保証では「最終使用日」を意味していた。データリポジトリは未整備で、重複定義の全量は把握できていない。現行は商品コードの先頭1桁を見て帳票の分類を切り替えており、業務側にコード依存の処理が残る。統合プロジェクトの期間は10か月、データ移行は3回のリハーサルを予定している。経営層は「製品を一意に識別できること」と「部門間で同じ言葉を使うこと」を最優先に求め、コードの意味は二次的としている。. 結論：意味を持たない不変のサロゲートコードを採用し、分類は属性として別に持つ。 現行は先頭1桁で帳票の分類を切り替えており、分類の追加・変更のたびにコード改番、関連データの更新、帳票ロジックの修正が必要になる。統合のタイミングでこの依存を切るのが最も安い。 意味コードは桁あふれや分類の追加に弱く、旧X社・旧Y社のような「工場コードを含む」体系は拠点統廃合で破綻する。 したがって新コードは連番＋チェックディジット（例：8桁）とし、大分類・カテゴリ・製造工場は属性列として保持する。帳票の分類は属性を参照するよう改修する。 旧コードの保持： 「商品コードマッピング」表に（旧システム, 旧コード）→ 新コード を保持する。1つの新コードに複数の旧コードが対応し得るため、主キーは（旧システム, 旧コード）とする。 名寄せの根拠（メーカー型番、包装、JANコード）を属性として残し、後から「なぜ同じ商品と判定したか」を追えるようにする。 表記ゆれ（バイアル／VIAL）はコードではなく、名称の同義語辞書で吸収する。コードを分けると在庫や集計が二重になる。 発番の主管部門、重複発番の防止、チェックディジットの検証ルールをリポジトリに定義する。. 分けるべき。 包装単位（10本入、100本入）ごとにJANコード、標準価格、発注単位が決まり、これらは商品だけからは決まらない。1表にまとめると包装の数だけ列を繰り返すことになり第1正規形に反する。 多重度：商品 1 - 0.. 包装単位。包装単位は商品に存在従属し、商品が消えれば包装も消える。主キーは包装ID、または（商品ID, 包装コード）。 ロットの位置づけ： ロットは製造単位であり、同一ロットが10本入と100本入の両方に詰められる。したがってロットを包装単位に従属させると同じロットが包装ごとに重複し、トレーサビリティが切れる。 ロットは商品に従属させ（商品 1 - 0..
65 words, under 1 min2病院の外来予約システムにおける正規化と一意性制約の設計
300床の急性期病院Bは、外来予約システムを刷新する。現行の予約テーブルは1行に予約ID、患者ID、患者氏名、患者電話番号、診療科コード、診療科名、医師ID、医師氏名、予約日時、予約種別、状態、作成日時を保持している。外来は1日約2,500件、年間約60万件、過去5年分をオンラインで保持している。患者マスタは別システムにあり、夜間バッチで連携している。患者の住所や電話番号の変更時に更新漏れが起き、過去の予約行に旧姓や旧電話番号が残る。診療科名の変更（「内科」から「総合内科」）では全予約行の更新が必要になり、夜間バッチが4時間を超えた。医師の異動時にも医師氏名の不整合が発生している。診療科は40、医師は180名である。さらに、同一患者が同一医師に対して同じ日に複数回予約を取れてしまい、月に約30件の苦情が出ている。予約の取消は行を残したまま状態フラグで管理し、取消率は約12%である。画面の検索は「医師ID＋予約日」が中心で、応答が2秒を超えることがあり、「患者ID」単独の検索も1日約800件ある。. 「医師ID＋予約日」検索の性能を改善する物理設計を、索引とパーティションの観点で述べよ。患者ID単独検索への配慮も含めること。. 関数従属： 予約ID → 患者ID, 医師ID, 予約日時, 予約種別, 状態, 作成日時 患者ID → 患者氏名, 患者電話番号 医師ID → 医師氏名, 診療科コード 診療科コード → 診療科名 判定： 主キーが単一列なので第2正規形は満たすが、予約ID → 患者ID → 患者氏名 のような推移的関数従属があり、第3正規形に違反する。診療科名も同様。 分解： 予約（予約ID, 患者ID, 医師ID, 予約日時, 予約種別, 状態, 作成日時） 患者（患者ID, 氏名, 電話番号） 医師（医師ID, 氏名, 診療科コード） 診療科（診療科コード, 診療科名） 予約時点の氏名を残す場合： 患者表を参照するのではなく、予約に「予約時氏名」という別属性として持つ。これは正規化違反ではなく、更新しないことを業務ルールとして明記した履歴属性である。属性名を「患者氏名」のままにすると、更新すべき項目と誤解されて同じ問題が再発する。連絡先も履歴が必要なら、患者連絡先（患者ID, 開始日, 電話番号）として期間付きで持つ。. ON 予約(患者ID,医師ID,予約日) WHERE 状態 < 'C'）、SQL Serverならフィルタ付きインデックスを使う。 別解として、取消時に一意制約用の列をNULLにする。NULLは一意制約上重複可能なので、取消行が何件あっても衝突しない。ただしこの列の意味をリポジトリに定義しておく。 午前・午後で同一医師の複数予約を許すなら、一意キーに時間帯区分を加える。制約を入れる前に業務ルールを確定させる。 制約違反時のエラーコードをアプリで捕捉し、患者に「同日の重複予約」と伝える導線を用意する。.
103 words, under 1 min3小売チェーンの売上集計SQLにおけるNULLと最新行抽出の誤り
全国120店舗を展開する小売チェーンCは、売上データ基盤を刷新した。売上明細テーブル sales detail は月間約900万行、2年分で約2億行を保持し、列は order id、line no、product id、qty、amount、status、updated at である。status は「S」（確定）、「C」（取消）、NULL（未確定）の3値で、NULLは全行の約2%を占める。商品マスタ product は約8万件、廃番商品テーブル discontinued は約4,000件で、product id にNULLを許す列がある。商品別の売上集計を status < 'C' の条件で作成したところ、経理部門の売上高より約2%少なくなった。廃番商品を除外するため NOT IN (SELECT product id FROM discontinued) と書いたレポートは、除外対象がないはずの商品まで含めて0件を返した。さらに、商品ごとに最後に更新された明細だけを抽出する処理を相関サブクエリで実装したが、実行に40分かかり、同じ updated at の行が複数ある商品で結果が実行ごとに変わることがある。アプリケーション側ではNULLを空文字に変換してから登録する改修が一部の画面でしか行われていない。. 商品別集計が経理の売上高より約2%少ない原因を特定し、修正SQLと検証方法を示せ。. NOT IN を使ったレポートが0件を返した原因を説明し、安全な書き換えを示せ。. 原因： SQLの3値論理。status < 'C' は status がNULLの行に対して UNKNOWN になり、WHERE句は TRUE の行だけを通すため、未確定（NULL）の約2%が集計から落ちる。差の2%はNULLの比率と一致しており、これで説明がつく。 修正SQL（未確定を含める場合）： COALESCE(status,'') < 'C' でも結果は同じだが、列に関数演算をかけると索引が使われにくくなるため、OR条件か status IN ('S') と業務定義で決めるのがよい。 まず業務定義の確認： 未確定を売上に含めるのか、確定（S）だけを売上とするのか。経理の数字が「確定ベース」なら、WHERE status = 'S' が正解であり、NULLを足すのは誤り。差が出た原因と、あるべき定義は別に切り分ける。 検証： 全体件数、status別の件数と金額、除外された件数をカウントし、経理の売上高と一致することを確認する。リグレッション防止に、NULLを含むテストデータを用意する。.
266 words, about 1 min4ECサイトの在庫引当における同時実行制御と障害復旧の判断
衣料品ECを運営するD社は、在庫テーブル stock（item id, warehouse id, qty, version）で引当を行っている。1日の注文は約8万件、セール時はピークで毎秒100件の引当要求が来る。現行処理は「SELECTで在庫を読む→アプリで充足判定→UPDATE qty = qty - n」の3段階で、分離レベルはREAD COMMITTEDである。version列を追加して楽観ロックにしたところ、ピーク時に更新件数0のエラーが1時間で約1,200件発生し、再試行3回で失敗する注文が約40件出た。同一商品に注文が集中するセール商品が原因と考えられている。また、夜間の引当バッチは倉庫ID→商品IDの順でロックを取り、オンライン処理は商品ID→倉庫IDの順でロックを取るため、デッドロックが週に数回発生している。バックアップは日次でフルを取得し、REDOログのアーカイブは30分ごとに行っている。経営層は「在庫の取り過ぎは絶対に避ける」と指示している。. オーバーセル（在庫の取り過ぎ）が起きる条件を、READ COMMITTEDの動作とともに説明し、確実に防ぐ実装を示せ。. 現在のバックアップ方式でのRPOを説明し、目標復旧点を5分にしたい場合の改善策と復旧手順を示せ。. FOR UPDATE で行ロックを取ってから判定・更新する。分離レベルを上げるだけでは不十分で、スナップショットを読む以上、アプリ側の判定ロジックと競合検出・再試行が前提になる。経営方針が「取り過ぎは絶対に避ける」なら、条件付きUPDATEを標準とする。.
107 words, under 1 min5自治体ポータルにおける問い合わせ検索の遅延とアクセス統制
人口約40万人の自治体Eは、住民向けポータルの問い合わせ履歴を同じDBで管理している。履歴テーブルは3年前は約50万件で検索は0.3秒だったが、現在は約2,800万件で、夜間バッチの後は25秒かかることがある。実行計画を見ると履歴テーブルの全表走査が選ばれており、統計情報の最終更新は14か月前、自動統計収集は無効化されている。索引は（受付日時）と（担当者ID）の単独索引が2本ある。主な検索条件は「担当者ID = ? AND 状態 IN ('未対応','対応中')」で、状態は3値、担当者は約400名である。夜間バッチは履歴を一括で更新し、その後VACUUMは実行されていない。また、退職者のDBアカウントが12件残存しており、監査ログは取得していない。本番データを匿名化せずに開発環境へコピーしており、開発者は本番DBにも接続できる。. 原因： 統計情報が14か月前で、50万件だった頃の行数・分布のまま。2,800万件の実態と乖離しており、選択率の見積りが誤って全表走査が選ばれている。自動統計収集が無効なので放っておくと悪化する。 バッチが大量更新した後にVACUUMが走っておらず、不要領域が膨らんで走査コストが上がっている。 単独索引しかなく、担当者IDと受付日時の組み合わせを効率よく絞れない。 優先順位： 1. 統計情報を更新し（ANALYZE）、自動収集を有効化する。これだけで計画が戻る可能性がある。 2.
94 words, under 1 minMore study resources for Database Specialist Examination
- Flashcards概念データモデル. 業務上のエンティティと関連を、DBMSや物理実装から独立して表現したモデル。属性や識別子を定義し、関係者間の合意形成と論理設計の入力に用いる。.
- Cheat sheet概念データモデルは業務上の実体（エンティティ）と関連を、DBMSや物理構造に依存せずに表現する。属性・識別子・多重度を定義する。.
- Key terms概念データモデル (conceptual data model). A business-level picture of the entities, relationships, and rules that an organization's data must capture, drawn without reference to any particular DBMS or physical storage arrangement.
- Common mistakes実務のER図がDBMSに作るテーブル定義と同一だと誤解し、概念モデルの目的（業務用語での合意形成）を意識していない。.
- Exam-day guideBring the original document, not a photocopy or a photo on your phone.