【共通】1. テクノロジ系＞1-3. 技術要素＞ 1-3-3. データベース｜情報処理問題1000本ノック

【データベース】処理能力のバロメーター！「QPS」｜情報処理問題1000本ノック

データベースの性能を測る際、単に「速い」ではなく数値で客観的に評価するための重要な指標を攻略しましょう。

1. 問題：データベースの性能指標

【問題】 データベースシステムにおいて、1秒間に実行（処理）されるクエリの回数を示す指標を何と呼ぶでしょうか？

ア、Latency イ、Throughput ウ、QPS エ、IOPS

2. 正解：パフォーマンス管理に関する正解

正解：ウ、QPS（Queries Per Second）

3. 解説：秒間の「さばき」の量

QPSは、そのデータベースがどれほど「忙しさ」に耐えられるか、あるいはどれほど効率的にリクエストを処理しているかを示す単位です。

【図解：QPSと関連指標の整理】

■ QPS (Queries Per Second)

・意味：1秒あたりのクエリ（検索・更新など）実行数。

・用途：DBの負荷状況の把握や、性能テストの結果測定。

■ レイテンシ (Latency) との違い

・QPSは「量（スループット）」：1秒間に何件こなせるか。

・レイテンシは「時間」：1つのクエリを投げてから結果が返るまでに何ミリ秒かかるか。

※レイテンシが短ければ、通常QPSは向上します。

[ セットで覚えたい周辺用語 ]

★ TPS (Transactions Per Second)：1秒あたりの「トランザクション」処理数。複数のクエリをまとめた1つの業務単位で数える場合に使い、QPSよりも厳格な負荷指標となります。

★ IOPS (Input/Output Operations Per Second)：ストレージが1秒間に読み書きできる回数。DBの性能のボトルネックを調べる際によく登場します。

1. 理解のコツ: ラーメン屋さんの厨房をイメージしてください。「1時間に何杯のラーメンを作れるか」がQPSです。「注文してからラーメンが出てくるまでの時間」がレイテンシです。
2. 試験対策の視点: 「1秒あたりの」「クエリ数」という言葉があればQPSです。システムのサイジング（どのくらいのスペックのサーバーを買うか）を検討する際の基準値として出題されます。

4. まとめ

「1秒間に処理されるクエリの数」。これがQPSです。この数値が高いほど、そのデータベースは多くのリクエストを同時にさばく能力があることを意味します。Webサービスの成長に合わせて、常に注視すべき健康診断の数値のようなものです。

【データベース】場所を問わず一括検索！「フェデレーションクエリ」｜情報処理問題1000本ノック

データがクラウド、オンプレミス、あるいは異なる種類のデータベースに分散していても、まるで一つの場所にまとまっているかのように検索できる「仮想的な統合」を攻略しましょう。

1. 問題：分散データの横断検索

【問題】 物理的に異なる場所にある複数のデータベースやストレージに対して、データを一か所に集約することなく、一つのクエリで横断的に検索・結合（JOIN）して結果を得る仕組みを何と呼ぶでしょうか？

ア、レプリケーションイ、フェデレーションクエリウ、データウェアハウスエ、正規化

2. 正解：分散システムに関する正解

正解：イ、フェデレーションクエリ（Federated Query）

3. 解説：移動させずに「その場」で読み取る

「フェデレーション（連盟）」という名の通り、自立した複数のデータベースが協力し合って一つの大きなデータベースのように振る舞います。

【図解：フェデレーションクエリのメリット】

■ 仕組み

・ユーザーは一つの「窓口」にSQL（クエリ）を投げます。

・システムが裏側で「MySQLにあるデータ」と「クラウドのオブジェクトストレージ（S3等）にあるデータ」をそれぞれ取得し、結合して返します。

■ メリット

・ETL（データ移行）が不要：データをコピーして運ぶ時間やコストがかかりません。

・最新性の確保：コピーではなく現地のデータを直接見るため、常に最新の状態を検索できます。

■ デメリット

・ネットワーク越しにデータを取得するため、一か所に集約されたDBに比べるとパフォーマンスが低下しやすい傾向があります。

[ 実例：クラウドでの活用 ]

★ AWSの「Amazon Athena」や「Redshift Spectrum」、Google Cloudの「BigQuery Omni」などが代表的です。これらを使うと、DB内のデータと、外部ストレージにあるCSVファイルを一発で結合して集計できます。

1. 理解のコツ: 「各国の出張所に電話をかけて、その場で在庫を確認して合計を出す本部」のようなイメージです。在庫データをすべて本部に送らせる（データ集約）のではなく、必要な時だけ各所に問い合わせるのがフェデレーションです。
2. 試験対策の視点: 「分散されたデータ」「集約することなく」「横断的に検索」というキーワードがあればフェデレーションクエリです。データレイクやマルチクラウドの話題と相性が良い用語です。

4. まとめ

「データを移動せず、複数のソースを一つのクエリで検索する」。これがフェデレーションクエリです。データが爆発的に増え、あちこちに分散している現代において、スピード感のある意思決定を支える強力な武器となります。

【データベース】読み書きをブロックしない！「多版同時実行制御（MVCC）」｜情報処理問題1000本ノック

データベースのパフォーマンスを落とさずに、複数のユーザーが同時にデータを読み書きするための高度な制御技術「MVCC」の仕組みを攻略しましょう。

1. 問題：高効率な同時実行制御

【問題】 リレーショナルデータベースにおいて、データの更新時に元のデータを直接書き換えるのではなく、新しい「版（バージョン）」を作成することで、読み込み処理と書き込み処理が互いにブロック（排他）されないように制御する方式を何と呼ぶでしょうか？

ア、2相ロック方式イ、多版同時実行制御（MVCC）ウ、楽観的並行性制御エ、デッドロック検知

2. 正解：トランザクション制御に関する正解

正解：イ、多版同時実行制御（MVCC：Multi-Version Concurrency Control）

3. 解説：バージョン管理による「待機」の解消

MVCCは、データに時間的な広がり（複数のバージョン）を持たせることで、一貫性と並列性を両立させる技術です。

【図解：MVCCの動作メカニズム】

■ 新しい「版」の作成

・データを更新する際、古いデータはそのまま残し、新しい値を持つ「新しい版」を追加します。

■ トランザクションIDによる管理

・各版には、それを作成したトランザクションIDやタイムスタンプが付与されます。

■ 読み込みと書き込みの両立

・書き込み中（新しい版を作成中）であっても、他のユーザーは「自分の開始時点よりも前の古い版」を読むことができるため、読み書きの競合（ロック待ち）が発生しません。

[ エンジニア視点の補足 ]

★ 不要な版の回収：古い版が溜まり続けるとディスクを圧迫するため、PostgreSQLの「VACUUM」のように、不要になった版を回収する仕組みが必要です。

★ 一貫性：各トランザクションは、実行開始時点の「スナップショット」を見ている状態になるため、データの整合性が保たれます。

1. 理解のコツ: 「上書き保存」ではなく、常に「別名で保存」を繰り返しているイメージです。古いファイルが残っているので、誰かが編集中でも他の人は古いファイルを読み続けられる、というのがMVCCの強みです。
2. 試験対策の視点: 「新しい版を作成」「読み書きが衝突しない」「トランザクションIDで管理」といったキーワードが出たらMVCCを指します。伝統的な「ロック方式」との違いを意識して覚えましょう。

4. まとめ

「データの新しい版を作成し、排他を行わずに同時実行性を高める」。これが多版同時実行制御（MVCC）です。大規模なアクセスをさばく現代のデータベースエンジンにおいて、心臓部とも言える重要な技術であることを押さえておきましょう。

【データベース】行を特定する鍵！「候補キー」｜情報処理問題1000本ノック

リレーショナルデータベースでは、膨大なデータの中から特定の1行（タプル）を確実に見つけ出すための「キー」の概念が不可欠です。複数のキーの違いを正確に攻略しましょう。

1. 問題：行を一意に識別する属性

【問題】 リレーショナルデータベースの表（リレーション）において、各行を一意に識別することができる最小の属性、または属性の組を何と呼ぶでしょうか？

ア、候補キーイ、主キーウ、外部キーエ、複合キー

2. 正解：データベースのキーに関する正解

正解：ア、候補キー

3. 解説：キーの階層構造を理解する

データベースにおける「キー」には役割に応じた階層があります。特に「候補キー」は全ての基本となります。

【図解：各種キーの定義】

■ 候補キー (Candidate Key)

・行を一意に識別できる「最小限」の組み合わせ。

・1つの表に複数存在することもあります（例：社員番号とメールアドレスなど）。

■ 主キー (Primary Key)

・候補キーの中から、設計者が運用上「これを使う」と決めた代表の1つ。

■ 外部キー (Foreign Key)

・他の表の主キーを参照し、表同士を関連付けるための属性。

[ 重要な性質 ]

★ 一意性制約：重複する値を持ってはいけない性質。

★ 非ナル制約：主キーに選ばれた属性は、空値（NULL）であってはいけないというルール。

★ 既約性：候補キーを構成する属性からどれか1つでも除くと、一意に識別できなくなる「最小構成」であること。

1. 理解のコツ: 「主キー」は、複数の「候補キー」という立候補者の中から選ばれた「当選者」だとイメージしてください。問題文で「一意に識別する属性」と広義に問われた場合は、そのベースとなる候補キーを指します。
2. 試験対策の視点: 「主キー」と「候補キー」の言葉の定義の差を突く問題は非常に多いです。また、2つ以上の属性を組み合わせて1つのキーにする「複合キー」も、候補キーや主キーの一形態であることを覚えておきましょう。

4. まとめ

「行を一意に識別する最小の属性（の組）」。これが候補キーです。適切なキーの設定は、データの重複を防ぎ、データベースの整合性を守るための最も重要なステップであることを押さえておきましょう。

【データベース】表の「縦」と「横」を数える！「次数」と「濃度」｜情報処理問題1000本ノック

リレーショナルデータベースの理論では、表（リレーション）の構造や規模を「次数」と「濃度」という言葉で表現します。どちらが「列」でどちらが「行」か、混乱しやすいポイントを攻略しましょう。

1. 問題：リレーションの特性

【問題】 あるデータベースの表において、定義されている「属性（列・項目）」の数と、格納されている「タプル（行・レコード）」の数を指す用語の組み合わせとして、正しいものはどれでしょうか？

ア、属性の数：濃度タプルの数：次数
イ、属性の数：次数タプルの数：濃度
ウ、属性の数：ドメインタプルの数：スキーマ
エ、属性の数：インスタンスタプルの数：カーディナリティ

2. 正解：データベースの基本用語に関する正解

正解：イ、属性の数：次数タプルの数：濃度

3. 解説：集合論から見た表の数え方

リレーショナルモデルは数学の集合論に基づいています。そのため、日常的な「列・行」ではなく、数学的な用語が使われます。

【図解：次数と濃度の違い】

■ 次数（Degree）

・表を構成する「列（属性）」の数のこと。

・例：[社員番号, 氏名, 部署名] の表なら、次数は「3」です。

■ 濃度（Cardinality：カーディナリティ）

・表に含まれる「行（タプル）」の数（データ件数）のこと。

・例：100人分のデータが入っていれば、濃度は「100」です。

[ 覚え方のヒント ]

★ 次数：関数の「二次式、三次式」のように、変数の数（項目の数）をイメージしましょう。

★ 濃度：カルピスの濃さのように、中にどれだけ要素（データ）が詰まっているか、というイメージで覚えましょう。

★ 変化の性質：運用中に「濃度」はデータの増減で激しく変化しますが、「次数」はテーブル定義変更（ALTER TABLE）をしない限り変わりません。

1. 理解のコツ: 実務では「カーディナリティ（濃度）」という言葉は、インデックスの効き具合（データの種類の多さ）を指す文脈でもよく使われます。理論用語としては「行の数」そのものを指すという点をまず押さえましょう。
2. 試験対策の視点: 午後問題や論理設計の問題で「このリレーションの次数はいくつか」といった問われ方をすることがあります。また、直積（デカルト積）の演算結果において、次数は「和」になり、濃度は「積」になる、といった計算問題への応用も重要です。

4. まとめ

「横（項目数）が次数、縦（データ件数）が濃度」。このシンプルな区別が、複雑なデータベース理論を解くための第一歩です。用語を正確に使い分けられるようにしておきましょう！

【データベース】SQL操作の土台！「基底表（ベーステーブル）」｜情報処理問題1000本ノック

データベースには、実際にデータが格納されている「実体のある表」と、利便性のために作られた「仮想的な表」があります。全ての操作の根源となる「基底表」を攻略しましょう。

1. 問題：表の結合と元となる表

【問題】 SQLのSELECT文やビュー（VIEW）を定義する際、その元となる、実際にディスク上にデータが格納されている表のことを何と呼ぶでしょうか？

ア、結合表イ、スキーマ表ウ、基底表エ、導出表

2. 正解：データベースの構造に関する正解

正解：ウ、基底表

3. 解説：データの「実体」と「見かけ」

リレーショナルデータベース（RDB）において、表（テーブル）は大きく「基底表」と「導出表（仮想表）」の2つに分類されます。

【図解：基底表とビューの関係】

■ 基底表（Base Table）

・CREATE TABLE文で定義され、実際にハードディスクなどの記憶装置にデータが書き込まれている表。

■ ビュー（View）／ 導出表

・1つ以上の基底表から、特定の列や行を抽出・結合して作られた仮想的な表。

・ビュー自体にはデータの実体はなく、参照されるたびに基底表からデータを取り出します。

[ 運用のポイント ]

★ 更新の制限：ビューに対してUPDATEやINSERTを行う場合、その操作が「どの基底表のどの行か」を一意に特定できる必要があります（結合されたビューなどは更新できない場合が多い）。

★ 正規化：基底表を適切に正規化（第3正規形など）し、冗長性を排除することがDB設計の基本です。

1. 理解のコツ: 「基底表は本物の書類」で、「ビューはその書類の必要な部分だけをコピーしたり、複数の書類を重ねて見せている透過シート」のようなものです。透過シート上の文字を書き換えるには、元の書類（基底表）が特定できなければなりません。
2. 試験対策の視点: 「元となる表」というキーワードが出たら基底表を指します。また、ビューの定義を削除しても基底表のデータは消えない、といった「実体か仮想か」という区別を問う問題も頻出です。

4. まとめ

「SQLやビューの定義の元になる、実体を持った表」。これが基底表です。データベースのパフォーマンスや整合性を支えるのは、この基底表の設計（物理設計・論理設計）そのものであることを押さえておきましょう。

【データベース】万が一に備える！バックアップの3大方式｜情報処理問題1000本ノック

データベースの運用において、データのバックアップは命綱です。バックアップにかかる「時間」と、復旧（リストア）にかかる「手間」のバランスを考えた3つの方式を整理しましょう。

1. 問題：バックアップの運用と種類

【問題】 データベースのバックアップ方式において、前回のバックアップの種類（フル、差分、増分）に関わらず、「最後に行ったバックアップ以降に追加・変更されたデータ」のみを抽出して保存する方式を何と呼ぶでしょうか？

① フルバックアップ ② 差分バックアップ ③ 増分バックアップ ④ 累積バックアップ

2. 正解：データ管理・運用に関する正解

正解： ③ 増分バックアップ

3. 解説：何を基準に「差」をとるか

バックアップには、すべてのデータをとる「フル」と、一部をとる「差分」「増分」があります。特に「差分」と「増分」の違いが試験で最も狙われます。

【図解：バックアップ方式の比較】

■ フルバックアップ

・基準：なし（すべて）

・特徴：時間はかかるが、これ1つで復旧可能。

■ 差分バックアップ（Differential）

・基準：「最後のフルバックアップ」からの変更分。

・特徴：復旧には「フル ＋ 最新の差分1つ」が必要。

■ 増分バックアップ（Incremental）

・基準：「前回のバックアップ（種類問わず）」からの変更分。

・特徴：バックアップ時間は最短。ただし復旧には「フル ＋ 以降のすべての増分」が必要。

[ メリット・デメリットの比較 ]

★ 増分：毎日のバックアップデータ量は少ないが、復旧時にいくつものファイルを順に適用する手間がかかる。

★ 差分：日を追うごとにバックアップデータ量は増えるが、復旧はフルと差分の2ステップで済む。

1. 理解のコツ: 「増分」は直前のバックアップからのバトンタッチ、「差分」は常に親玉（フル）との比較、と覚えましょう。試験問題で「前回のバックアップ以降」とあれば増分、「フルバックアップ以降」とあれば差分です。
2. 試験対策の視点: リストア（復旧）の手順についてもよく問われます。「フル＋増分1 ＋増分2…」といった順番を間違えないようにしましょう。また、ログファイルを用いた「ロールフォワード」との組み合わせも頻出テーマです。

4. まとめ

「前回のバックアップからの変更分だけを保存する」。これが増分バックアップです。ストレージ容量を節約できる反面、復旧手順が複雑になるというトレードオフの関係をしっかり押さえておきましょう！

【データベース】元通りに復元できる！「無損失分解」の定義｜情報処理問題1000本ノック

テーブルの正規化などで表を分割する際、ただ分ければいいというわけではありません。元の情報を完全に保持したまま分割できているか。それが「無損失分解」のポイントです。

1. 問題：情報が損なわれない分割の条件

【問題】 関係データベースにおいて、一つの表を二つ以上の表に分割（分解）した後、それらを自然結合させた結果が、元の表と完全に一致するような分割のことを何と呼ぶでしょうか？

① 垂直分解 ② 無損失分解 ③ 直積分解 ④ 正規化分解

2. 正解：正規化理論に関する正解

正解： ② 無損失分解

3. 解説：自然結合で元に戻せるか

テーブルを分割する際、適切なキー（共通の列）を残さずに分けると、後で結合したときに元の情報が復元できなくなったり、余計な行（偽のタプル）が発生したりします。「無損失分解」とは、分解しても情報の損失がなく、自然結合によって元の表を一意に再現できる性質を指します。

[ 無損失分解のポイント ]

・定義：分解された表を自然結合すると、元の表と等しくなること。

・条件：分解する際の共通属性が、少なくとも一方の表の主キー（または候補キー）である場合に成立します。

[ 関連用語の整理 ]

★ 正規化：冗長性を排除し、更新異常を防ぐために表を分割するプロセス。

★ 関数従属性：ある属性の値が決まれば、他の属性の値も一意に決まる関係。

★ 結合従属性：表をいくつかの部分に分解し、それらを再結合しても元の表を再現できる性質。

1. 理解のコツ: 「無損失」という言葉から、単純に「データが消えない」ことだと思われがちですが、実際には「結合したときに余計なデータが増えない（元の関係が壊れない）」ことも含まれます。パズルをバラバラにしても、正しく組み直せる仕組みが備わっている状態です。
2. 試験対策の視点: 第2正規形や第3正規形への分解は、すべてこの「無損失分解」であることが前提です。高度試験では、「表R(A, B, C)をR1(A, B)とR2(A, C)に分解したとき、無損失分解となる条件は？」といった形式で、関数従属性と絡めて問われることが多いです。

4. まとめ

「分割した表をくっつけたら、元通りになる」。これが無損失分解の核となる定義です。データベースの整合性を保ちながら、正しく正規化を行うための必須条件であることを押さえておきましょう！

【データベース】構造に縛られない柔軟性！ドキュメント型DBの定義｜情報処理問題1000本ノック

あらかじめ厳密な表形式を決めなくていい。データの追加や変更が激しい現代のアプリケーション開発で、圧倒的な支持を得ているのが「ドキュメント型データベース」です。

1. 問題：構造を定義せずにデータを管理する形式

【問題】 NoSQLデータベースの分類のうち、XMLやJSON形式といった「ドキュメント」と呼ばれる単位でデータを管理するものはどれでしょうか？この形式では、RDBのレコードに相当するデータごとに異なる構造を持たせることが可能です。

① キーバリューストア型 ② ドキュメント型 ③ グラフ型 ④ カラム指向型

2. 正解：NoSQLの分類に関する正解

正解： ② ドキュメント型

3. 解説：スキーマレスによる開発スピード

ドキュメント型は、RDB（関係データベース）のように「CREATE TABLE」で列をガチガチに定義する必要がありません（スキーマレス）。あるデータには「住所」があるけれど、別のデータにはない、といった不揃いな状態でもそのまま保存できるのが最大の特徴です。

[ ドキュメント型のポイント ]

・管理単位：JSONやBSONなどの形式で記述された「ドキュメント」。

・柔軟性：構造をあらかじめ決めておく必要がないため、仕様変更に強い。

・代表的な製品：MongoDB、CouchDB、Amazon DocumentDBなど。

[ 他の選択肢との違い ]

★ キーバリューストア型：単純な「鍵」と「値」のセットのみを扱う（中身の検索は苦手）。

★ グラフ型：ノードとエッジで「つながり」を管理する（SNSなどの関係性重視）。

★ カラム指向型：列単位でデータを保持し、大量データの集計を高速化する。

1. 理解のコツ: 「リレーショナルDBのレコードに対応するが、構造を決めておく必要はない」という点が、試験で最も狙われる定義です。ドキュメントの中にさらにドキュメントを入れ子にする（ネスト）構造も得意としています。
2. 最新トレンドの視点: Webアプリやモバイルアプリではデータ構造が頻繁に変わるため、開発初期からドキュメント型が選ばれるケースが増えています。高度試験では、RDBとの使い分けや、ACID特性の妥協（結果一貫性）といったトレードオフに関する知識も求められます。

4. まとめ

「ドキュメント単位で、自由な構造で保存する」。これがドキュメント型データベースの核となる定義です。RDBのような厳格さがない分、スピード感のある開発に適したアーキテクチャであることを押さえておきましょう！

【データベース】変更に強い設計の極意！3層スキーマ構造の正体｜情報処理問題1000本ノック

データベース設計の基本でありながら、最高の知恵が詰まった「3層スキーマ構造」。なぜわざわざ3つに分けるのか。それは、一部を変更しても他に影響を与えない「データ独立性」を確保するためです。

1. 問題：管理対象を定義するスキーマ

【問題】 データベースの3層スキーマ構造において、データの論理的な構造（管理対象の全体像）を定義し、開発者や管理者の視点からデータの本質を表現するスキーマはどれでしょうか？

① 外部スキーマ ② 概念スキーマ ③ 内部スキーマ ④ 物理スキーマ

2. 正解：スキーマの役割に関する正解

正解： ② 概念スキーマ

3. 解説：保守性を高める「3つの境界線」

役割ごとに境界線を引くことで、ある層の変更が他の層へ波及するのを防ぎます。これを「データ独立性」と呼び、システムの保守性を劇的に高めます。

[ 3層スキーマの役割 ]

・外部スキーマ（見せ方）：ユーザーやアプリが見る窓口。実務では「ビュー（VIEW）」に相当。

・概念スキーマ（論理）：データの全体像。実務では「テーブル定義（CREATE TABLE）」やER図に相当。

・内部スキーマ（持ち方）：物理的な保存方法。実務ではインデックスやファイル配置に相当。

[ データ独立性のメリット ]

★ 物理的データ独立性：ストレージの変更やインデックスの追加（内部）を行っても、テーブル定義（概念）やプログラムを直す必要がない。

★ 論理的データ独立性：テーブルを分割（概念）しても、ビュー（外部）を調整すれば、アプリ側のプログラムを一切修正せずに済む。

1. 理解のコツ: 概念スキーマが「本質」であり、それをどう見せるかが「外部」、どう保存するかが「内部」です。真ん中の概念スキーマがしっかりしているからこそ、両サイドの変化を吸収できるのです。
2. 試験対策の視点: 試験では「ビュー＝外部スキーマ」「テーブル＝概念スキーマ」という対応関係がよく問われます。また、ANSI/X3/SPARC（アンシ・スパーク）という用語と一緒に登場することもあるので、セットで覚えておきましょう。

4. まとめ

「ある層の変更を、その層だけで完結させる」。これが3層スキーマ構造の最大の価値です。この構造を理解しておくことで、保守性が高く、変化に強いデータベース設計の基礎をマスターできます！