採点されません。匿名です。 間違えることは学習の一部です。読むだけでもかまいません。

データベース(データベース方式・設計・データ操作・トランザクション処理・データベース応用)

テクノロジ系 / 技術要素

この単元の範囲

基本情報技術者試験のシラバスは、大分類3「技術要素」の中に中分類9として「データベース」を独立させている(直後の中分類10は「ネットワーク」)。ここでは、データベースという仕組みそのものの成り立ち(1. データベース方式)から、実際にテーブルを設計する手順(2. データベース設計)、SQLを使ったデータの読み書き(3. データ操作)、複数人が同時にアクセスしても壊れない仕組み(4. トランザクション処理)、そして分析やビッグデータ活用への応用(5. データベース応用)まで、5つの小分類を一気通貫で扱う。ITパスポートで触れた「表形式でデータを管理する」というイメージを土台に、なぜそのような設計・制御が必要になるのかを具体例とともに理解するのが到達目標になる。

1. データベース方式

1-1 データベースの種類と特徴

データベースには目的に応じて複数の方式がある。最も普及しているのは、データを行と列からなる表(テーブル)で管理するRDB(Relational Database:関係データベース)であり、これは表形式でデータを整理する構造型データベースの代表例である。歴史的には、組織図のような親子関係でデータをたどるHDB(Hierarchical Database:階層型データベース)、複数の親を持てるよう拡張したNDB(Network Database:網型データベース)が先行して存在した。近年利用が広がっている方式としては、プログラムのオブジェクトをそのまま保存するOODB(Object Oriented Database:オブジェクト指向データベース)、タグ構造を持つ文書をそのまま扱うXMLデータベース、複数サーバにデータを分けて持つ分散データベース、JSON文書のような単位でデータを保存するドキュメント指向データベース、集計処理に強い列指向データベース、人間関係やSNSのつながりを表現しやすいグラフデータベース、単純なキーと値の組でデータを持つキーバリュー型データベース、ディスクではなく主記憶上でデータを扱うことで高速化するインメモリデータベースがある。用途に応じてこれらを使い分ける、という視点が重要である。

1-2 3層スキーマアーキテクチャ

データベースの構造を利用者の視点から独立させるための考え方が3層スキーマアーキテクチャ(3層スキーマ構造)である。データベース全体の論理構造を定義する概念スキーマを中心に、利用者やアプリケーションごとに見える範囲を絞った外部スキーマ(副スキーマ)、実際の物理的な記憶装置上の格納方法を定義する内部スキーマ(記憶スキーマ)の3層に分ける。たとえば経理担当者には給与額を含む外部スキーマを、一般社員には氏名・部署のみの外部スキーマを見せる、といった形で同じ概念スキーマから複数の見え方を作れる点がこの構造の利点である。

1-3 データベースのデータモデルと関係モデル

データの構造を抽象化して表現したものがデータモデルであり、業務要件を表す論理データモデルと、実際の格納形式に近い物理データモデルに分けられる。代表的な論理データモデルには、表形式で表す関係モデル、親子構造で表す階層モデル、複数の親子関係を持てるネットワークモデル(網モデル)、ノードとエッジのつながりで表すグラフ型のデータモデルプロパティグラフトリプルストア)がある。基本情報で中心となるのは関係モデルであり、表そのものを関係(リレーション)、1行分のデータをタプル(行,組)、1列分の項目を属性(列,フィールド)、セルに入る具体的な値を実現値、その属性が取り得る値の範囲を定義域(ドメイン)、表の構造定義そのものを関係スキーマと呼ぶ。たとえば「社員」表であれば、社員1人分の行がタプル、「氏名」「部署」といった列が属性にあたる。

1-4 データベース管理システム(DBMS)

データベースを一元管理するソフトウェアがDBMSであり、表の構造を定義するデータベース定義機能、データの検索・更新を行うデータベース操作機能、複数利用者からの整合性・安全性を保つデータベース制御機能を中核に、障害からデータを守る保全機能、権限のない利用者からデータを守るデータ機密保護機能を備える。制御機能の内部では、複数のプログラムが同時にデータへアクセスしても矛盾が起きないようにする同時実行制御(排他制御)、障害発生時にデータを元の状態へ戻す障害回復、不正アクセスからデータを守るデータセキュリティが実現されている。これらの詳細は4章で扱う。

2. データベース設計

2-1 データ分析

データベースを作る前段階として、業務で使われるデータの意味・関連性を整理するデータ分析を行う。同じ情報をあちこちの表に重複して持たないようにするデータ重複の排除が基本方針であり、データそのものではなく「データについてのデータ」であるメタデータ(項目名・型・桁数など)を、データディクショナリという辞書にまとめて管理する。

2-2 データベースの概念設計・論理設計

データ分析の結果をもとに、業務上の実体と関連を図式化するのが概念設計である。E-R図やUMLのクラス図を用いて、管理対象そのものであるエンティティ(例:「顧客」「商品」)、その性質を表す属性(例:顧客の氏名)、エンティティ同士のつながりであるリレーションシップ(例:「顧客が商品を注文する」)を表現し、その関連が「1対1」「1対多」「多対多」のどれにあたるかというカーディナリティを明らかにする(例:1人の顧客が複数回注文できるのは「1対多」)。概念設計で作った概念データモデルを、実装可能な論理データモデル(RDBであれば表構造)に落とし込むのが論理設計であり、この段階で列にあたるフィールド(項目)、行にあたるレコード、表全体であるファイルを定義し、値が入っていない状態を表すNULLの扱いや、同じ値を重複させない一意性制約を決める。

2-3 データの正規化

表の中にデータの重複や更新時の不整合が起きにくい構造にする作業が正規化である。1つの項目に複数の値を入れない状態にする第1正規形、主キーの一部だけに従属する項目(部分関数従属)を切り出して主キー全体に完全関数従属する状態にする第2正規形、主キー以外の項目同士が連鎖的に従属する推移関数従属を取り除く第3正規形という3段階で進める。たとえば「注文番号・商品コード・商品名・数量」という1つの表があると、同じ商品が何度も注文されるたびに商品名が重複して記録されてしまう。商品コードと商品名を「商品」表として独立させれば、商品名の変更時にも1か所を直すだけで済むようになる。これが正規化の実務的な効果である。

2-4 データベースの物理設計

論理設計で決めた表構造を、実際のディスク上にどう配置するかを決めるのが物理設計である。将来のデータ増加を見込んだディスク容量見積り、論理データ構造を物理的な格納領域へ対応づける論理データ構造のマッピング、検索や更新にかかる時間を事前に見積もる性能評価などを行う。

3. データ操作

3-1 データベースの操作(関係演算・集合演算)

関係データベースに対する操作は、数学の集合演算・関係演算として理論化されている。表同士に対する集合演算には和・差・積(共通)があり、関係データベース特有の演算である関係演算には、条件に合う行を取り出す選択、必要な列だけを取り出す射影、複数の表を結び付ける結合、割り算になぞらえて一方の表に含まれる組合せをすべて満たす行だけを抽出する、全組合せを作る直積がある。これらをまとめて関係代数と呼ぶ。SQLのSELECT文は、内部的にはこれらの関係演算の組合せとして実行されていると理解すると、SQL文の意味がつかみやすくなる。

3-2 データベース言語(SQL)

データベースを操作する言語は、表や制約を定義するDDL(Data Definition Language:データ定義言語)と、データの検索・更新を行うDML(Data Manipulation Language:データ操作言語)に大別される。利用形態としては、対話的にSQL文を1文ずつ実行する会話型SQLと、C言語などのプログラム中にSQL文を組み込む埋込みSQLがあり、SQLを単独で使う独立言語方式と、他のプログラム言語の中から呼び出す親言語方式が存在する。ほかに、モジュール言語、画面から操作するコマンド方式フォーム、検索条件を指定する問合せ(クエリ)という利用形態もある。

DDLでは、実際にデータを格納する実表を作成する際、文字型数値型日付型などの型を列ごとに指定し、値の重複を禁じる一意性制約、他表の値を参照させる参照制約、値の範囲を制限する検査制約、NULLを禁止する非NULL制約、利用者ごとのアクセス権を設定する。DMLの中心となるSELECT文では、件数や合計を求める集約関数、文字列の一部一致検索に使うパターン文字列、同じ表を複数回扱うときに使う相関名のほか、範囲を指定するBETWEEN・候補群を指定するIN述語、グループごとに集計するグループ化、結果を並べ替える処理、SELECT文の中に別のSELECT文を埋め込む副問合せ、外側の問合せの値を参照する相関副問合せを扱う。データの追加・更新・削除・権限付与を行うINSERT文UPDATE文DELETE文GRANT文もこの区分に含まれる。プログラム言語に埋め込むSQLでは、検索結果を1行ずつ取り出すためのカーソルという仕組みを使う。

4. トランザクション処理

複数の処理をひとまとまりの単位として扱うトランザクションを安全に実行する仕組みが、この小分類の中心テーマである。

4-1 同時実行制御(排他制御)

複数の利用者が同時に同じデータを更新しようとすると矛盾が生じる。これを防ぐのが同時実行制御(排他制御)であり、代表的な手段がロック方式である。データの更新中は他者からの読み書きを禁じる専有ロック、読み取りのみを許す共有ロックがあり、ロックをかける範囲の大小をロック粒度と呼ぶ。ロックのかけ方によっては、複数のトランザクションが互いに相手のロック解除を待ち続けてしまうデッドロックが発生し得る。ほかに、資源の空き状況を管理するセマフォ方式、複数のデータベースにまたがる更新をすべて成功させるか、すべて取り消すかを制御するコミットメント制御(具体的な手順である2相コミットメント)がある。

4-2 障害回復

障害が起きてもデータを守れるよう、更新履歴をジャーナルファイル(ログファイル)として記録しておく。定期的にデータベースの状態を記録しておくチェックポイントを設けておくことで、障害復旧の作業範囲を絞り込める。復旧の方向には、正常に完了した更新をログをもとにやり直すフォワードリカバリ(ロールフォワード)と、未完了の更新を取り消して元に戻すバックワードリカバリ(ロールバック)の2種類がある。システム再起動の方式には、直近のチェックポイントとジャーナルファイルを使ってロールフォワード・ロールバックにより回復してから起動するウォームスタート(通信障害など軽微な障害向け)と、バックアップファイル全体からデータベースを復元してから起動するコールドスタート(ディスク破損など重大な障害向け)がある。

4-3 トランザクション管理(ACID特性)

トランザクションが満たすべき4つの性質をまとめてACID特性と呼ぶ。処理が「全部成功」か「全部失敗」のどちらかにしかならないことを保証する原子性(Atomicity)、処理の前後でデータベースの整合性が保たれることを保証する一貫性(Consistency)、複数のトランザクションが同時に実行されても互いに干渉しないことを保証する独立性(Isolation)、処理が完了した結果は障害が起きても失われないことを保証する永続性(Durability)の4つである。銀行口座の振込を例にすると、「引き落とし」と「入金」が両方成功するか両方失敗するかのどちらかになる(原子性)、口座残高の合計は振込前後で変わらない(一貫性)、他の振込処理の途中経過が見えない(独立性)、振込完了後に停電しても記録が消えない(永続性)、という形で理解できる。

4-4 データベースの性能向上

検索を高速化する仕組みがインデックスである。データベースの負荷を軽減するため、重複を許さないユニークインデックス、データの物理的な並び順自体をインデックスの順序に揃えるクラスタ化インデックス、木構造で探索する最も一般的なB-treeインデックス、値の有無をビット列で表すビットマップインデックス、ハッシュ値で高速に照合するハッシュインデックス、検索に必要な列をインデックス自体に含めて実表参照を省くカバリングインデックス、全文検索で使われる転置インデックスなど、目的に応じたインデックス種別を使い分ける。

4-5 データへのアクセス制御

データベースへの権限は用途ごとに細かく分けて設定できる。接続する権限、データを検索する参照権限、新規登録する挿入権限、更新する権限、データを消す削除権限などを利用者・役割ごとに割り当てることで、必要最小限の操作しか許可しない運用が可能になる。

5. データベース応用

5-1 データベースの応用(データ分析基盤)

日々の業務データを蓄積・整理したデータウェアハウス、そこから特定部門向けにデータを切り出したデータマートを土台に、多次元的にデータを集計・分析するOLAP(Online Analytical Processing)、大量データから規則性やパターンを見つけ出すデータマイニングが行われる。日々の業務処理そのものを指すOLTP(Online Transaction Processing)と対比されることが多い。複数システムに散らばったデータを一か所に集めて分析用に整える工程をETL(Extract/Transform/Load)(抽出・変換・格納の順)またはELT(Extract/Load/Transform)(先に格納してから変換)と呼び、表記ゆれや欠損値を整えるデータクレンジングもこの工程に含まれる。こうした分析基盤は、量・多様性・速度が従来のデータベースの想定を超えるビッグデータの活用や、契約書類を管理する文書管理システム、営業活動を支援する営業支援システムといった業務アプリケーションの土台にもなる。

5-2 分散データベース

複数のサーバにデータを分散して配置する分散データベースでは、利用者からは1つのデータベースであるかのように見える透過性が重要になる。データを複数拠点に複製しておくレプリケーション、複数拠点にまたがる更新をすべて確定するか取り消すかを制御するコミットメント制御2相コミットメント)は、拠点間でデータの整合性を保つための仕組みである。

5-3 データ資源管理

組織全体でデータという資源を体系的に管理する考え方がデータ資源管理である。データの所在・意味・型などを一元管理する仕組みとしてIRDS(Information Resource Dictionary System:情報資源辞書システム)があり、これは国際規格ISO/IEC 10027として枠組みが定義されている。データの格納形式は、表形式で厳密に型が決まった構造化データ、JSON・XMLのようにある程度の構造を持つ半構造化データ、画像や音声のように構造を持たない非構造化データに分けられる。近年ではセンサーなどから絶え間なく送られてくるストリーミングデータ、構造化・非構造化を問わず大量の生データをそのまま蓄積しておくデータレイク、複数拠点に分散したファイルをまとめて扱う分散ファイルシステムといった技術がデータ資源管理の対象として重要になっている。

---

参考文献

  • IPA「基本情報技術者試験シラバス Ver.9.2」大分類3「技術要素」中分類9「データベース」(本文p.28-31、目次上p.28): https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kpe-att/syllabus_fe_ver9_2.pdf
  • ISO/IEC 10027:1990(Information technology — Information Resource Dictionary System (IRDS) framework): https://www.iso.org/standard/17985.html
  • ISO/IEC 9075-1:2023(Information technology — Database languages SQL — Part 1: Framework。SQL標準は複数パートに分かれており、本リンクは最新版Part 1): https://www.iso.org/standard/76583.html
  • ACID特性の提唱経緯(Härder, T. and Reuter, A. (1983) "Principles of transaction-oriented database recovery")に関する解説: https://en.wikipedia.org/wiki/ACID

本資料は IPA(独立行政法人 情報処理推進機構)が公表する「基本情報技術者試験シラバス Ver.9.2」(大分類3「技術要素」中分類9「データベース」、シラバス本文p.28-31、目次上の掲載ページも同じくp.28)に基づく自作の解説テキストである。

  • シラバス本文の用語例・分類構成を参照しつつ、解説文・具体例は本資料著者(nomuraya-dojo)の独自作成である
  • IRDS(ISO/IEC 10027)、SQL標準(ISO/IEC 9075)、ACID特性の提唱経緯に関する記述は、シラバス本文には明記されていない周辺事実であり、公開されているISO規格情報・関連文献をもとに本資料著者が補足したものである
  • 末尾の「オリジナル演習問題」は IPA 過去問を模倣・転記せず、本資料著者が独自に作成したものである
  • シラバスそのものの著作権は IPA に帰属する。原文は IPA公式シラバスPDF を参照すること
  • 本資料の利用にあたっては、IPAの著作権・利用規約に従うこと

考えてみよう

既定では正解・不正解の判定はしません。自分のペースで「答えを見る」を。採点してほしい場合だけ「採点してほしい」を押してください。

問1

ある部門別の売上管理システムにおいて、経理部門には金額を含む項目を、営業部門には金額を除いた項目のみを見せたい。この要件を満たすため、同一のデータベースに対して利用者ごとに異なる見え方を定義する3層スキーマの構成要素はどれか。

ア 概念スキーマ

イ 内部スキーマ

ウ 外部スキーマ

エ 物理スキーマ

解答:ウ

解説: 利用者やアプリケーションごとに見える範囲を絞ったスキーマは外部スキーマ(副スキーマ)である。概念スキーマはデータベース全体の論理構造を定義するもので、特定利用者向けに項目を絞り込む役割は持たない。内部スキーマは物理的な記憶装置上の格納方法を定義する層であり、選択肢の「物理スキーマ」という呼称は3層スキーマ構造(概念・外部・内部)の正式名称ではない。

問2

「注文番号」と「商品コード」の複合キーを主キーとする注文明細表(注文番号,商品コード,商品名,数量)において、「商品名」が主キーの一部である「商品コード」だけで値が決まってしまっている状態を何と呼ぶか。

ア 完全関数従属

イ 部分関数従属

ウ 推移関数従属

エ 多値従属

解答:イ

解説: 主キーの一部の列だけに従属する状態を部分関数従属と呼び、これを解消して主キー全体に従属する状態(完全関数従属)に整理する過程が第2正規化である。推移関数従属は主キー以外の列同士が連鎖的に従属する状態を指し、第3正規化で解消する対象である。「多値従属」は本シラバスの用語例には含まれない発展的な概念であり、この設問の状態には当てはまらない。

問3

社員表(社員ID,部署,給与)から、部署ごとの平均給与を求めたうえで、平均給与が30万円以上の部署だけを抽出したい。この条件をSQLで指定する方法として最も適切なものはどれか。

ア WHERE句で「AVG(給与) >= 300000」と指定する

イ GROUP BY句で部署ごとにグループ化したうえで、HAVING句で「AVG(給与) >= 300000」と指定する

ウ ORDER BY句で「AVG(給与) >= 300000」と指定する

エ DISTINCT句で「AVG(給与) >= 300000」と指定する

解答:イ

解説: 集約関数(AVG)による集計結果に対する絞り込み条件は、グループ化した後の集計値に対して指定するHAVING句で行う。WHERE句は集約処理前の行単位の条件にしか使えず、集約関数の結果を直接指定することはできない。ORDER BY句は結果の並べ替え、DISTINCT句は重複行の除去を行う句であり、いずれも集計値による絞り込みには使わない。

問4

複数のトランザクションが同時に実行されても、互いの処理途中の状態が影響し合わないことを保証するACID特性はどれか。

ア 原子性(Atomicity)

イ 一貫性(Consistency)

ウ 独立性(Isolation)

エ 永続性(Durability)

解答:ウ

解説: 独立性(Isolation)は、複数のトランザクションが同時に実行されても互いの処理途中の状態(中間結果)が影響し合わないことを保証する特性である。原子性は処理が「全部成功」か「全部失敗」のどちらかにしかならないこと、一貫性は処理の前後でデータベースの整合性が保たれること、永続性は処理完了後の結果が障害が起きても失われないことを保証する特性であり、それぞれ独立性とは異なる観点を扱う。

問5

複数拠点に分散して配置されたデータベースに対して1つの更新処理を行う際、すべての拠点で更新を確定するか、1拠点でも失敗すればすべての拠点で更新を取り消すかを制御する仕組みを何と呼ぶか。

ア レプリケーション

イ 透過性

ウ 2相コミットメント

エ シャーディング

解答:ウ

解説: 複数拠点にまたがる更新をすべて確定させるか、すべて取り消すかを制御する仕組みは2相コミットメント(コミットメント制御の具体的な手順)である。レプリケーションはデータを複数拠点に複製しておく仕組み、透過性は利用者から見てデータが分散していることを意識させない性質を指し、いずれも更新の確定・取消しそのものを制御する仕組みではない。「シャーディング」はデータを複数サーバへ分割配置する一般的な手法を指す語で、本シラバスの用語例には明記されていない点にも留意したい。

力試ししたい方は クイズ形式の演習(任意) もあります。読むだけでも十分です。