IPA データベース — 頻出論点と過去問

この分野の学び方

1. この分野の全体像

データベースは、業務の記録を表に収め、同時に読み書きされても障害が起きても内容が崩れないように保つための、設計と管理の技術です。表の読み取りを確かめるITパスポートの問いは、応用情報技術者の午前ではSQL文の実行結果や回復の対象を判定する問いになり、データベーススペシャリストの午前IIでは関数従属の推論や、隔離性水準ごとの挙動の比較にまで及びます。表の形を決める設計と正規化が土台にあり、その表を読み書きする処理の正しさと速さを保つ仕組みが、その上に積み重なっています。

2. 配下の論点の案内

• SQL・関係代数: 表の形が決まったあとに、その表へ問い合わせを書いて結果の行を追う論点です。応用情報技術者の午前ではSQL文を実行した結果の行数や空欄に入る字句を選び、データベーススペシャリストの午前IIでは3値論理の真理値や、商演算をほかの演算の組合せで表す問題まであります。

• データモデル・E-R/UML・キー: 業務の決まりを表と列、キーの形に移す設計の段階です。ITパスポートでは主キーや外部キーにする列と、表に行を追加する順序を選び、応用情報技術者の午前ではUMLの図から多重度や表への実装の解釈を読み取る問題が出ています。

• 正規化・関数従属: モデリングで決めた表の分け方を、属性どうしの決まり方から確かめ直す論点です。応用情報技術者の午前では表と業務の条件から満たしている正規形を判定し、データベーススペシャリストの午前IIでは分割後の表の数や、記号で表した関係の閉包と無損失分解の条件まで出題されています。

• トランザクション・同時実行制御: 複数の処理が同じデータを同時に使うときの、確定と取消しの単位を定めます。ITパスポートではコミットやACID特性について適切な記述を選び、データベーススペシャリストの午前IIでは、異状を防げる隔離性水準の下限や、次の図のような待ち状態の図からデッドロックで永久待ちになったトランザクションを挙げる問題が出題されています。

• 障害回復・バックアップ: 障害のあとにデータをどの時点へ戻すかを、ログとバックアップで決める運用の側の仕組みです。ITパスポートでは週ごとのフルと日ごとの差分のバックアップから復元に要るファイルを選び、応用情報技術者の午前では次の図のように各トランザクションの終わりと障害の時刻を並べた図から、やり直す処理と取り消す処理を見分けます。

• 分散DB・NoSQL: 一つのDBMSの中の確定と整合を複数のノードへ広げた論点で、表の形をとらないデータの持ち方も含みます。応用情報技術者の午前ではCAP定理やBASE特性の説明とJSON形式のデータの格納方法を選び、データベーススペシャリストの午前IIでは2相コミットの制御の正誤や、先頭の文字で振り分ける規則の名前を選ぶ問題があります。

• インデックス・物理設計: 表の論理的な形は変えずに、記憶装置上の格納とインデックスで検索の速さを左右する段階です。応用情報技術者の午前ではハッシュインデックスが向く検索条件や、オプティマイザが実行計画に使うものを選び、データベーススペシャリストの午前IIではB+木のノード分割後の形や、入れ子ループ法の結合の計算量を求めます。

3. 学習の順序の提案

「データモデル・E-R/UML・キー」で決める表と列、主キーと外部キーの形は、「正規化・関数従属」で分け方を確かめるときにも、「SQL・関係代数」で結合の条件を書くときにも、そのまま材料になります。「インデックス・物理設計」は、表の形とSQLの検索条件が分かったあとで、どの索引が効くかと結合の手間を比べる論点です。運用の側では、「トランザクション・同時実行制御」で学ぶ確定の有無が、「障害回復・バックアップ」で処理をやり直すか取り消すかの基準になり、「分散DB・NoSQL」は、その確定を複数のノードでそろえる場合へ話を広げます。

E-R図の空欄とその表を使うSQL文の空欄を一つの事例の中で埋めさせ、インデックスの効く列や排他制御の方式まで続けて問う大問は、応用情報技術者の午後にあります。システムアーキテクトの午後の大問は、ファイルの主キーの決め方や、企業の統合とシステムの刷新に伴うデータ移行を題材にしていました。データベーススペシャリストの午後I・午後IIの概念データモデリングの大問では、次の図のように概念データモデルの図と関係スキーマを対応させ、現状の業務と追加の要件からリレーションシップと関係スキーマの属性を補い、候補キーや正規形を判定する設問も出ています。実装と運用の大問は、オンライン処理とバッチ処理が同じ表を使うときのロックと隔離性水準、SQL文と索引による性能の見積りを扱います。障害のあとの回復の手順や、サービスを分けた構成でのデータの整合性の保ち方を問う大問もありました。

4. 分野をまたいで間違えやすいところ

3層スキーマのどの層で決める内容かを選ぶ問題は、「データモデル・E-R/UML・キー」と「インデックス・物理設計」の境目にあります。内部スキーマで決める作業を選ぶ問題では、更新の一貫性を保つための正規化が誤答肢にありました。正規化は表の分け方を決める論理の側の作業で、記憶装置の上でデータをどう置くかには関わりません。

DBMSが持つデータディクショナリと、組織がデータ項目の名前と意味をそろえるために作る辞書は、名前が似ていても入る分野が違います。前者はDBMSが処理のたびに自分で参照する情報で、この分野に入ります。後者は人が項目の意味を確かめるための取り決めで、命名規約やメタデータの管理とともにデータマネジメントの活動に入ります。

データウェアハウスのスタースキーマは、業務処理の表とは逆の向きに表を組みます。更新のたびの食い違いを防ぐために表を細かく分けるのが正規化で、スタースキーマは集計の問い合わせで結合する表を減らすために、切り口ごとの表の分け方をあえて粗くします。スタースキーマの表の役割を選ぶ問題には、AI・データ活用の分野にも入るものがありました。

データモデルの図と業務プロセスの図（システム開発技術分野）も、描く対象が異なります。次の図のように、E-R図やUMLのクラス図を用いたデータモデルは、業務で管理すべき情報項目のまとまりとそれらの間の多重度や主キー・外部キーの参照関係という静的な構造を表します。業務の手順や処理の間のデータの流れを表すDFDやアクティビティ図とは表す側面が違い、データモデルに描くのは処理の順序ではなく、記録として残る管理対象とその結びつきです。

同じデータの写しを別の場所に持つ仕組みでも、「障害回復・バックアップ」のバックアップと「分散DB・NoSQL」のレプリケーションでは、写しをいつまで新しく保つかが違います。データベースの複製を別のコンピュータに置いて同期させる機能の名前を選ぶ問題では、バックアップが誤答肢にありました。バックアップはある時点の写しを取って保管しておくもので、取ったあとの更新は写しに入りません。