データベーススペシャリスト午後II 総合事例記述令和3年 秋期
午後II 問1
問1 データベースの実装に関するデータベース設計・実装
テーマ：マンション商談管理システムにおけるテーブル設計，制約，問合せ，およびバックアップ・リカバリの検討
左右2分割表示：左側の問題文をスクロールしながら右側の設問に解答できます
長文事例本文
図表クリックで拡大問1 データベースの実装に関する次の記述を読んで，設問1〜3に答えよ。
D社は，マンションの開発及び販売を手掛ける不動産会社である。D社では，販売業務で利用している商談管理システムの老朽化に伴い，システムの刷新を行っている。
〔業務の概要〕
1. 物件
(1) 販売対象のマンション全体を物件という。物件内の建物を棟といい，棟内の個々の住居を住戸という。
(2) 物件内の住戸を幾つかの販売期に分けて販売する。
2. 組織
(1) 物件の販売を行う拠点として，物件の近隣に販売センタを設営している。
(2) 販売センタには，販売業務を行う担当者を配置している。
(3) 販売センタの業務時間は毎日10〜19時である。
3. 販売業務
(1) 物件に興味をもった人を顧客といい，顧客ごと物件ごとに，商談の進捗度，接触回数，受注確度，希望面積，購入予算などを記録する。
(2) 担当者は，資料請求の受付，資料の送付，販売センタへの来場予約受付，来場時の応接，希望条件・購入予算などを記した要望書の取得，購入申込みの受付，抽選会の案内・実施などの営業活動を行う。担当者が顧客との間で行うこれらの活動を追客といい，“受付”（資料請求，来場予約など），“実施”（資料送付，来場時の応接など），“応対”（購入申込受領，問合せ対応など）の区分に分けて記録する。
(3) 追客を行うたびに商談管理システムにその内容を登録する。
4. 販売分析業務
販売促進のための分析業務である。業務に用いるミスマッチ分析表の例を図1に示す。図1は，住戸の仕様（販売価格，専有面積）と顧客の要望（購入予算，希望面積）との一致度合いを確認するための帳票で，販売価格，購入予算を範囲によって価格帯に，専有面積，希望面積を範囲によって面積帯に分け，価格帯と面積帯の組ごとに“住戸数（戸）／顧客数（名）”を表示する。空白は該当なしを表す。
| 物件コード：1234567 物件名：〇〇マンション ||||||
| :--- | :--- | :--- | :--- | :--- | :--- |
| 価格帯 ＼ 面積帯 | 50 ㎡未満 | 50 ㎡以上 60 ㎡未満 | 60 ㎡以上 70 ㎡未満 | 70 ㎡以上 80 ㎡未満 | 80 ㎡以上 |
| 3千万円未満 | 4戸 ／ 3名 | | ／ 2名 | | |
| 3千万円以上 4千万円未満 | | 4戸 ／ 4名 | 4戸 ／ 10名 | ／ 5名 | |
| 4千万円以上 5千万円未満 | | 4戸 ／ 1名 | 2戸 ／ 2名 | 1戸 ／ 2名 | ／ 1名 |
| 5千万円以上 6千万円未満 | | | 1戸 ／ | 2戸 ／ 1名 | ／ 2名 |
| 6千万円以上 | | | | 1戸 ／ | 2戸 ／ |
図1 ミスマッチ分析表の例
〔商談管理システムの概要〕
1. 関係スキーマ
商談管理業務の関係スキーマを図2に，主な属性とその意味・制約を表1に示す。
拡大
表1 主な属性とその意味・制約
| 属性名 | 意味・制約 |
| :--- | :--- |
| 顧客コード | 顧客を一意に識別するコード（6桁の半角英数字） |
| 物件コード | 物件を一意に識別するコード（7桁の半角英数字） |
| 販売価格，購入予算 | 販売価格，購入予算の金額（単位：万円，0〜99,999） |
| 専有面積，希望面積 | 住戸の面積（単位：平方メートル，0.00〜999.99） |
| 商談ステータス | '1'（接触開始），'2'（商談中），'3'（要望書取得），'4'（購入申込済），'5'（抽選済），'6'（仮契約済），'7'（本契約済），'8'（引渡済），'9'（追客中止）のいずれか |
| 契約ステータス | '6'（仮契約済），'7'（本契約済），'8'（引渡済）のいずれか |
| 追客区分 | '1'（受付），'2'（実施），'3'（応対）のいずれか |
| 追客種別 | 資料請求，資料送付，来場予約，来場応接，購入申込受領，問合せ対応など，追客の種類を識別するコード（2桁の半角英数字） |
| 接触日時 | 追客ごとに顧客との接触を開始した日時 |
| 最新接触日時 | 商談に紐付く追客の最新の接触日時 |
2. 外部システムとの連携
商談管理システムは，次のように外部システムとのデータ連携を行っている。
(1) 物件管理システムから物件情報（大エリア，小エリア，住所，鉄道事業者，沿線，駅，物件，最寄り駅，販売期，棟，住戸）の変更データを受領する。
(2) 自社のWebサイトから資料請求及び来場予約データを受領する。
(3) 契約システムから毎日複数回，契約データを受領する。
(4) 受領したデータは専用のアプリケーションソフトウェア（以下，APという）を用いて商談管理システムのデータベースに反映する。
3. 処理の例
商談管理システムにおける処理の例を表2に示す。
表2 処理の例
| 処理名 | 内容 |
| :--- | :--- |
| 処理1 | 物件管理システムから受領した物件情報の変更データを反映する。APは，関係ごとに追加，更新を記録したファイルを読み込み，データベースへの追加，更新を行う。 |
| 処理2 | Webサイトから受信する資料請求データには，資料請求日時，物件コード，顧客コード，氏名，住所コードなどが記録されている。同様に，来場予約データには，開始予定日時，物件コード，顧客コード，氏名などが記録されている。APは，追客の追加，新規顧客の追加，商談の追加又は最新接触日時の更新を行う。 |
| 処理3 | 同一の顧客を名寄せする。APは，一定の条件に基づいて同一の顧客を抽出し，名寄せ元の名寄せ先顧客コードを更新する。 |
| 処理4 | 契約システムから受領した契約データを基に，契約の契約ステータスを更新し，追客を追加する。 |
| 処理5 | 指定した物件コード，顧客コードに該当する全ての追客を対象に，接触日時，追客種別，追客概要を商談管理画面に表示する。追客概要は，本処理において追客区分ごとに固有な属性値を基にして作成した文字列である。例えば，来場予約受付の追客概要は，“予約日時：2021-10-10 11:00〜12:00”のようになる。 |
| 処理6 | 指定した物件コード，期間に該当する追客状況表を出力する。追客種別ごと接触日時の日ごとに件数を集計し，物件コード，年月日，資料請求数，来場予約数，来場応接数，購入申込受領数を出力する。 |
| 処理7 | 図1のミスマッチ分析表を出力するために，指定した物件コードに該当する住戸の販売価格から価格帯を，専有面積から面積帯を求め，両者の組ごとに住戸数を集計する。同じように，商談の購入予算から価格帯を，希望面積から面積帯を求め，両者の組ごとに顧客数を集計する。価格帯と面積帯の組ごとに，該当する住戸数と顧客数の片方又は両方を対応させて，価格帯，面積帯，住戸数，顧客数を抽出する。 |
〔RDBMSの主な仕様〕
商談管理システムで利用するRDBMSの主な仕様は次のとおりである。
1. ページ
RDBMSとストレージ間の入出力単位をページという。同じページに異なるテーブルの行が格納されることはない。
2. テーブル・索引
(1) テーブルの列にはNOT NULL制約を指定することができる。NOT NULL制約を指定しない列にはNULLか否かを表す1バイトのフラグが付加される。
(2) 主キー制約には，主キーを構成する列名を指定する。
(3) 参照制約には，列名，参照先テーブル名，参照先列名を指定する。制約に違反する追加，更新，削除は拒否される。
(4) 検査制約には，同一行の列に対する制約を記述する。
(5) 索引には，ユニーク索引と非ユニーク索引がある。
3. トリガ機能
テーブルに対する変更操作（追加，更新，削除）を契機に，あらかじめ定義した処理を実行する。
(1) 実行タイミング（変更操作の前又は後。前者のトリガをBEFOREトリガ，後者のトリガをAFTERトリガという），列値による実行条件を定義することができる。
(2) トリガ内では，変更操作を行う前の行，変更操作を行った後の行のそれぞれに相関名を指定することで，行の旧値，新値を参照することができる。
(3) BEFOREトリガの処理開始から終了までの同一トランザクション内では，どのテーブルに対しても変更操作を行うことはできない。
(4) トリガ内で例外を発生させることができる。
(5) トリガ内で発生した例外は，実行の契機となった変更操作に返却される。トリガ内で例外が発生した場合，変更操作を行うトランザクションは終了しないので，明示的なコミット又はロールバックが必要である。
4. バックアップ機能
(1) バックアップの単位には，データベース単位，テーブル単位がある。
(2) バックアップには，取得するページの範囲によって，全体，増分，差分の3種類がある。
① 全体バックアップには，全ページが含まれる。
② 増分バックアップには，前回の全体バックアップ取得後に変更されたページが含まれる。ただし，前回の全体バックアップ取得以降に増分バックアップを取得していた場合は，前回の増分バックアップ取得後に変更されたページだけが含まれる。
③ 差分バックアップには，前回の全体バックアップ取得後に変更された全てのページが含まれる。
(3) 全体及び増分バックアップでは，取得ごとにバックアップファイルが作成される。差分バックアップでは，2回目以降の差分バックアップ取得ごとに，前回の差分バックアップファイルが最新の差分バックアップファイルで置き換えられる。
5. 復元機能
(1) バックアップを用いて，バックアップ取得時点の状態に復元できる。
(2) 復元の単位はバックアップの単位と同じである。
(3) データベース単位の全体バックアップは，取得元とは異なる環境に復元することができる。
6. 更新ログによる回復機能
(1) バックアップを用いて復元した後，更新ログを用いたロールフォワード処理によって，障害発生直前又は指定の時刻の状態に回復できる。データベース単位の全体バックアップを取得元と異なる環境に復元した場合も同様である。
(2) 一つのテーブルの回復に要する時間は，変更対象ページのストレージからの読込み回数に比例する。行の追加時には，バッファ上のページに順次追加し，空き領域を確保してページが一杯になるごとに空白ページを読み込む。行の更新時には，ログ1件ごとに対象ページを読み込む。バッファ上のページのストレージへの書込みは，非同期に行われるので，回復時間に影響しない。
7. エクスポート機能
(1) テーブル単位にデータをファイルに抽出することができる。
(2) エクスポート対象テーブルの行の抽出条件を指定することができる。
8. インポート機能
(1) エクスポート機能で抽出したファイルを，インポート先の環境の同じ構造のテーブルに格納することができる。
(2) インポート先のテーブルに主キーが一致するデータが存在する場合の動作として，処理しない（SKIP），又は更新する（MERGE）のいずれかのオプションを指定することができる。未指定時はSKIPを指定した場合と同等となる。
〔実装するテーブルの設計〕
1. テーブルの列の追加
各テーブルには，登録担当者コード，登録TS，更新担当者コード，更新TSの各列を追加する。登録TSには行追加時の時刻印を，更新TSには行更新時の時刻印をそれぞれ設定する。また，行の削除は論理削除によって行うこととし，削除フラグ列（0：未削除，1：削除済）を追加する。
2. 関係“追客”及びそのサブタイプの実装方法検討
関係“追客”と，関係“受付”，“実施”，“応対”は，概念データモデルにおいてスーパタイプとサブタイプの関係にある。スーパタイプ，サブタイプのテーブルへの実装には次の方法①〜③があり，それぞれに，他の方法に比べて格納効率が悪い，他の方法では不要な選択・結合・和集合が必要になる，などの短所がある。そこで，表3を作成し，テーブル構造の特質に由来する実装上の短所をまとめた。短所がない場合は“−”を記入する。
方法① スーパタイプと全てのサブタイプを一つのテーブルにする。
方法② スーパタイプ，サブタイプごとにテーブルにする。
方法③ サブタイプだけを，それぞれテーブルにする。スーパタイプの属性は，列として各テーブルに保有する。
拡大
表3を基に，関係“追客”の実装方法を次のように判断した。
・方法③は，項目Aの短所からサブタイプ全体での主キーの一意性を，テーブルの一意性制約以外の方法によってチェックする必要があり採用し難い。
・表2中の処理5は表3の項目 エ に，処理6は表3の項目 オ に該当する。方法②では，処理5の応答時間に不安がある。
・方法①は，項目Bの短所による不利益はあるものの，項目D，Fに該当する処理は少なく，影響が限定的であることから方法①を採用する。
3. 制約の実装検討
外部システムとの連携によってデータの整合性が失われることのないように，データベースの制約を定義する。
(1) 参照制約
図2の関係スキーマのうち，物件情報である大エリア，小エリア，住所，鉄道事業者，沿線，駅，物件，最寄り駅，販売期，棟及び住戸をそのままテーブルとして実装し，参照制約を定義するとしたら，表2中の処理1では，制約に違反しないように各テーブルへの変更反映処理を行わなければならない。そこで，テーブルを順序付けしてグループ番号1〜6に分け，参照制約に違反しない限りできるだけ小さいグループ番号に配置することにして表4を作成した。グループ番号順に直列に処理を行い，同じグループ内のテーブルへの処理は並行して行う。
表4 変更データ反映処理のグループとテーブル（未完成）
| グループ番号 | テーブル名 |
| :---: | :--- |
| 1 | 大エリア，鉄道事業者 |
| 2 | 小エリア，沿線 |
| 3 | カ |
| 4 | キ |
| 5 | ク |
| 6 | 住戸 |
(2) 参照制約以外の制約
連携データの反映による整合性の喪失を防ぐための制約を，一意性制約，NOT NULL制約，検査制約，BEFOREトリガ，AFTERトリガのうち適切な方法を用いて定義する。制約とその定義内容を表5にまとめた。ここで，トリガ内の行の旧値を参照する相関名をOROW，新値を参照する相関名をNROWと定義するものとする。
表5 制約とその定義内容（未完成）
| 制約 | 定義内容 |
| :--- | :--- |
| 制約① 住戸には必ず0よりも大きい販売価格が設定されていなければならない。 | “住戸”テーブルに，“販売価格 > 0”をチェックする検査制約を定義する。 |
| 制約② 同じ顧客，接触日時及び追客種別の追客を行うことはない。例えば，重複する資料請求データがあればエラーを通知する。 | “追客”テーブルに， ケ |
| 制約③ 契約ステータスが後退する（例：本契約済が仮契約に戻る）ことはない。そのような契約の変更にはエラーを通知する。 | “契約”テーブルの行の更新を契機に， コ |
| 制約④ 契約ステータスはできるだけ最新の状態でなければならず，契約手続の開始後は，契約ステータスと商談の商談ステータスは一致していなければならない。 | “契約”テーブルの行の更新を契機に，NROW.契約ステータスに対応する商談ステータスの値を設定して“商談”テーブルを更新するAFTERトリガを定義する。 |
〔問合せの検討〕
表2の処理7に用いる問合せの内容を，次の要領で表6に整理した。
(1) 行ごとに構成要素となる問合せを記述する。結果を他の問合せで参照する場合は，行に固有の名前（以下，問合せ名という）を付ける。
(2) 列名又は演算には，テーブルから射影する列名又は演算によって求まる項目を“項目名=[演算の内容]”の形式で記述する。
(3) テーブル名又は問合せ名には，参照するテーブル名又は問合せ名を記入する。
(4) 選択又は結合の内容には，テーブル名又は問合せ名ごとの選択条件，結合の具体的な方法と結合条件を記入する。
表6 表2の処理7に用いる問合せの内容（未完成）
| 問合せ名 | 列名又は演算 | テーブル名又は問合せ名 | 選択又は結合の内容 |
| :--- | :--- | :--- | :--- |
| M1 | 棟コード，住戸コード，
価格帯=[販売価格 3000未満：1，4000未満：2，5000未満：3，6000未満：4，6000以上：5]，
面積帯=[専有面積 50未満：1，60未満：2，70未満：3，80未満：4，80以上：5] | 住戸 | 住戸から指定された物件コードに一致する行を選択 | | M2 | 価格帯，面積帯，住戸数=[価格帯，面積帯でグループ化した行数] | M1 | 全行を選択 | | T1 | 顧客コード，
価格帯=[購入予算 3000未満：1，4000未満：2，5000未満：3，6000未満：4，6000以上：5]，
面積帯=[希望面積 50未満：1，60未満：2，70未満：3，80未満：4，80以上：5] | 商談 | 商談から指定された物件コードに一致する行を選択 | | T2 | 価格帯，面積帯，顧客数=[価格帯，面積帯でグループ化した行数] | T1 | 全行を選択 | | R1 | 価格帯=[ サ ]，
面積帯=[ 網掛け ]，
住戸数，顧客数 | M2，T2 | M2の全行とT2の全行を選択し，価格帯，面積帯で完全外結合 | 注記 網掛け部分は表示していない。 表6中の“M1”の問合せを実装するためのSQL文の案を図3に示す。案1は，問合せをそのまま実装するもので，案2は，“価格帯”及び“面積帯”テーブルを追加することで，SQL文の変更なしに価格帯，面積帯の範囲を変えられるようにするものである。案2の①は“価格帯”及び“面積帯”テーブルを作成するSQL文，②は“価格帯”テーブルに行を追加するSQL文，③は追加したテーブルを用いて問合せの結果行を得るSQL文である。
拡大
〔バックアップ・リカバリの検討〕
1. 障害発生の想定
バックアップ・リカバリの検討に当たり，本番環境のデータベース（以下，本番DBという）で想定される障害ケースを検討し，表7に整理した。ここで，データベース単位の全体バックアップを毎日0時に取得しているものとする。
表7 想定した障害ケース
| 障害ケース | 障害状況 |
| :--- | :--- |
| 障害ケース① | ディスク装置に障害が発生し，テーブルのデータが全損した。 |
| 障害ケース② | 表2の処理2で，外部システムの不具合によって誤った来場予約データが大量に登録された。誤登録の行の更新担当者コードはSYSRAI01，誤登録の期間は2021-07-20の15:05:00〜15:10:00である。誤登録発生の前後の時間帯では，断続的に追客を記録する業務を行っている。また，誤登録の期間中，当該担当者コードによって誤登録以外の処理は行われていない。 |
| 障害ケース③ | 表2の処理3で，“顧客”テーブルのうち，名寄せ先顧客コードがNULLの行が誤更新によって不正な状態となった。誤更新が行われた直前の日時は2021-07-21 13:45:11であり，誤更新の発生中にも“顧客”テーブルへの追加及び更新が行われている。また，誤更新の発生後，商談管理システムは参照系機能だけを利用可能な状態で稼働させ，後続の処理への影響はない。 |
2. 障害ケース①の検討
障害ケース①のリカバリは，ディスク装置の復旧，バックアップからの復元，更新ログによる回復によって行う。このうち，“商談”及び“追客”テーブルの更新ログによる回復がリカバリに要する時間の大半を占めるので，回復に掛かる時間を試算し，業務への影響を調べることにした。試算に先立って，試算対象テーブルのデータ量及び更新ログ件数見積りを表8にまとめた。
表8 試算対象テーブルのデータ量及び更新ログ件数見積り
| テーブル名 | 見積行数 | 平均行長（バイト） | 1ページ当たりの平均行数 | 1時間当たりの更新ログ件数（追加） | 1時間当たりの更新ログ件数（更新） |
| :--- | :---: | :---: | :---: | :---: | :---: |
| 商談 | 630,000 | 720 | 10 | 5,000 | 50,000 |
| 追客 | 24,000,000 | 288 | 25 | 50,000 | 5,000 |
注記 テーブルを格納する表領域のページサイズを8,000バイト，空き領域率を10%とする。
(1) 回復に要する時間の試算
障害が18:00に発生し，10:00から8時間分の各テーブルへの追加，更新ログによる回復を想定し，更新ログが毎時均等に発生すると考える。また，1ページ当たりのストレージへのI/Oを10ミリ秒（0.01秒）とし，ストレージへのI/O以外のCPU処理，索引探索，ネットワーク通信などに掛かる時間を考慮しないものとして，次のように試算した。
① 障害発生時点で，“商談”テーブルには，追加40,000件，更新400,000件の更新ログがある。回復の際，ストレージへのI/Oは，追加では1ページ当たりの平均行数まではバッファ上で処理するので4,000回，更新ではバッファヒット率を0とすると400,000回，合わせて404,000回発生する。よって，回復に必要な時間は a 秒になる。
② 同様に，“追客”テーブルでは，回復時のストレージへのI/Oは，追加では b 回，更新では c 回発生するので，回復に必要な時間は d 秒になる。
(2) 回復時間短縮の対策
(1)の試算では回復時間が長い。回復時間を短縮するために，毎日12:00，14:00，16:00に“商談”及び“追客”テーブルのテーブル単位の増分又は差分バックアップを取ることを検討し，次の結論を得た。
① e 時間分の更新ログを適用すればよいので，“商談”テーブルの回復時間は，f 秒になる。
② バックアップからの復元に要する時間を考慮すると，“追客”テーブルは，増分と差分のどちらの方式でもほとんど変わらないが，“商談”テーブルは，増分バックアップよりも時間が掛からない差分バックアップを採用する。
3. 障害ケース②の検討
障害ケース②は，バックアップの復元及び更新ログによる回復によって誤登録発生直前の日時の状態にする方法では問題を解決できない。そこで，誤登録したデータを削除するため，次の処理を順次実行することにした。
・誤登録した“追客”テーブルの行を削除状態に更新する。
・誤登録によって作成された“商談”テーブルの行を削除状態に更新する。
・誤登録によって作成された“顧客”テーブルの行を削除状態に更新する。
・“商談”テーブルの最新接触日時を更新する。
“商談”テーブルの最新接触日時を更新するSQL文を図4に示す。ここで，更新担当者コード，更新TSを更新する処理は省略している。
拡大
4. 障害ケース③の検討
障害ケース③では，誤更新が行われた行だけを誤更新前の状態に戻し，誤更新の原因を排除した上で処理3を再実行することとした。そこで，本番DBとは別に，作業用のデータベース（以下，作業用DBという）を用意し，作業ミスに備えて本番DBの“顧客”テーブルの全ての行を退避した上で，RDBMSの機能を利用した復旧手順を検討し，表9に整理した。
拡大
拡大図2 関係スキーマ（一部省略）
拡大表3 実装方法の短所（未完成）
価格帯=[販売価格 3000未満：1，4000未満：2，5000未満：3，6000未満：4，6000以上：5]，
面積帯=[専有面積 50未満：1，60未満：2，70未満：3，80未満：4，80以上：5] | 住戸 | 住戸から指定された物件コードに一致する行を選択 | | M2 | 価格帯，面積帯，住戸数=[価格帯，面積帯でグループ化した行数] | M1 | 全行を選択 | | T1 | 顧客コード，
価格帯=[購入予算 3000未満：1，4000未満：2，5000未満：3，6000未満：4，6000以上：5]，
面積帯=[希望面積 50未満：1，60未満：2，70未満：3，80未満：4，80以上：5] | 商談 | 商談から指定された物件コードに一致する行を選択 | | T2 | 価格帯，面積帯，顧客数=[価格帯，面積帯でグループ化した行数] | T1 | 全行を選択 | | R1 | 価格帯=[ サ ]，
面積帯=[ 網掛け ]，
住戸数，顧客数 | M2，T2 | M2の全行とT2の全行を選択し，価格帯，面積帯で完全外結合 | 注記 網掛け部分は表示していない。 表6中の“M1”の問合せを実装するためのSQL文の案を図3に示す。案1は，問合せをそのまま実装するもので，案2は，“価格帯”及び“面積帯”テーブルを追加することで，SQL文の変更なしに価格帯，面積帯の範囲を変えられるようにするものである。案2の①は“価格帯”及び“面積帯”テーブルを作成するSQL文，②は“価格帯”テーブルに行を追加するSQL文，③は追加したテーブルを用いて問合せの結果行を得るSQL文である。
拡大図3 “M1”の問合せを実装するSQL文の検討例（未完成・一部省略）
拡大図4 “商談”テーブルの最新接触日時を更新するSQL文（未完成）
拡大表9 障害ケース③の復旧手順（未完成）
設問一覧 ＆ 解答・演習
まずは解答を作成してみましょう。「解答例を見る」をクリックするとIPA公式解答例と採点基準が開きます。
設問1 (1)記号・選択式
表3中の ア 〜 ウ に入れる適切な字句を答えよ。また，本文中の エ, オ に入れる表3中の項目A〜Gのいずれか一つを答えよ。
※直接入力してください
設問1 (2)記号・選択式
表4中の カ 〜 ク に入れる一つ又は複数のテーブル名を答えよ。
※直接入力してください
設問1 (3)記述問題
制限字数：60 字以内
表5中の ケ, コ に入れる適切な定義内容を，記入済みの例に倣って，ケ は40字以内，コ は60字以内で具体的に述べよ。
0 / 60 文字
設問1 (4)記述問題
制限字数：25 字以内
制約④のAFTERトリガ内で，“商談”テーブルの更新時にロック待ちタイムアウトによる例外が返却された場合，トリガの契機となる変更を行った表2中の処理4のAPではどのような処置を行うべきか。行うべき処置を二つ挙げ，それぞれ25字以内で述べよ。
0 / 25 文字
設問2 (1)記述問題
制限字数：40 字以内
表6中の問合せ名“R1”の下線部について，完全外結合を行う理由を40字以内で述べ，サ に入れる演算の内容を答えよ。
0 / 40 文字
設問2 (2)記号・選択式
図3中の シ 〜 ソ に入れる適切な字句を答えよ。
※直接入力してください
設問3 (1) (a)記号・選択式
本文中の a 〜 f に入れる適切な数値を答えよ。
※直接入力してください
設問3 (1) (b)記述問題
制限字数：30 字以内
本文中の下線部について，差分バックアップからの復元が増分バックアップからの復元よりも時間が掛からない理由を，30字以内で具体的に述べよ。
0 / 30 文字
設問3 (2) (a)記述問題
制限字数：60 字以内
バックアップの復元及び更新ログによる回復によって誤登録発生直前の日時の状態にする方法では問題を解決できない理由を，60字以内で述べよ。
0 / 60 文字
設問3 (2) (b)記号・選択式
図4は，相関副問合せを使用して更新を行うSQL文である。g に適切な字句を，h 〜 j に一つの適切な述語を入れ，SQL文を完成させよ。
※直接入力してください
設問3 (3)記述問題
障害ケース③について，表9中の k 〜 s に適切な字句を入れ，表を完成させよ。なお，m, p, s に入れる作業内容は，RDBMSの機能に指定する内容を含めてそれぞれ40字以内で記入すること。
0 文字
午後II長文記述の得点力を引き上げる定番対策書Amazon・楽天 公式提携
PR
IPA 厳選対策書徹底攻略 データベーススペシャリスト教科書 令和8年度株式会社わくわくスタディワールド 瀬戸 美月 著 / インプレス
DB徹底攻略株式会社わくわくスタディワールド 瀬戸 美月 著 / インプレス
徹底攻略 データベーススペシャリスト教科書 令和8年度
💡 推薦ポイント:午後I・午後IIの概念データモデル穴埋めや排他制御・性能設計の記述問題で確実に合格点を勝ち取る実践テクニックが満載です。
¥3,278（税込）
※本リンク先はプロモーション（アフィリエイト広告）が含まれています
【出題趣旨】IPA公式発表
【採点講評】IPA公式発表
本問に関連するデータベーススペシャリスト重要用語解説
本番形式・制限時間付きで演習する
令和3年 秋期 午後II（2問中1問選択・120分）を実戦演習モードで通し解答し、総合採点を受けられます。