【データベース】親がいないと存在できない！ER図の「弱実体」｜情報処理問題1000本ノック

データベースの概念設計（ER図）において、実体同士の深い絆を表す概念。「自分だけの力では番号を決められない」という、依存度の高い実体の性質を攻略しましょう。

1. 【 問題 】：ER図における実体の分類

【 問題 】 データベースの概念設計で用いられるER図（実体関連図）において、自分自身が持つ「属性（カラム）」だけではデータを一意に識別（特定）することができず、関連する「他の実体（親実体）」の主キーを取り込んで初めてデータを一意に識別できるようになる実体を何と呼ぶでしょうか？

① 強実体 (Strong Entity / 独立実体)
② 弱実体 (Weak Entity / 依存実体)
③ 連関実体 (Associative Entity)
④ サブタイプ実体 (Subtype Entity)

2. 正解：

正解： ② 弱実体（じゃくじったい）

3. 解説：親の番号を借りて、初めて一人前になるデータ

テーブル設計（データモデリング）において、単体では迷子になってしまう特殊な実体が存在します。それを表す言葉が弱実体（依存実体）です。

【弱実体の具体的なビジネス例】

・会社のシステムで「社員（親実体）」テーブルと、その「家族（子実体）」テーブルがあるとします。
・家族テーブルに「第1子」「配偶者」という【続柄（属性）】だけを持たせても、日本中に同じデータが溢れてしまい、誰の家族なのか一意に識別できません。
・そこで、親である社員テーブルの主キー（例：社員番号「S001」）を借りてきて、【社員番号：S001 ＋ 続柄：第1子】とセットにすることで、初めて世界に1人だけのデータとして一意に識別（特定）できるようになります。このときの「家族」のように、親なしでは識別できない実体を弱実体と呼びます。 ← ココが問題の正解！

※ER図の表記法（IE表記法やIDEF1Xなど）では、この弱実体を「角が丸い四角形」で表現したり、親との結びつきを「実線（依存リレーションシップ）」で表現したりして、普通のテーブルと明確に区別します。

[ 選択肢のひっかけポイント（すべてER図の高度な実体概念） ]
★ ① 強実体（独立実体）：弱実体の真逆です。他のテーブルに頼ることなく、自分自身の属性（例：社員番号、商品コードなど）だけでデータを一意に識別できる普通の主役級テーブルのことです。
★ ③ 連関実体：「多対多」の関連を持つテーブル同士（例：学生と授業）を結合するために、間に挟む「履修登録」のような中間テーブル（交差実体）のことです。
★ ④ サブタイプ実体：「社員」という共通データ（スーパータイプ）に対して、「正社員」「契約社員」のように、特定のグループだけに存在する固有の属性を小分けにした子テーブルのことです。

1. 理解のコツ: 「ホテルの部屋番号と、そこに置かれたアメニティ」に例えてみましょう。
・ホテルそのものは「強実体」です。「101号室」というだけで部屋を特定できます。
・しかし、部屋の中にある「ベッド」は、単に「ベッドA」という名前（属性）だけでは、どこの部屋のベッドか分かりません。「101号室（他の実体）の、ベッドA」という関連があって初めて、清掃員が一意に識別できますよね。この、場所を借りないと特定できないベッドのような存在が弱実体です。
2. 試験対策の視点: 「自身の属性では一意に識別できない」「他の実体との関連において識別できる」という定義フレーズが来たら「弱実体（依存実体）」が一択です。基本情報や応用情報の午前試験では、リレーショナルデータベースの概念設計やER図の読み取り問題において、データの主従関係（親子関係）を正しく見抜くための必須知識として出題されます。

---

4. まとめ

「親となるテーブルの主キーを分け与えてもらう（依存する）ことで、ようやく自身のデータを1行に特定できるようになる子側の実体構造」。これが弱実体です。この関係性を正しくER図に表現することは、データの登録・削除ルール（親が消えたら子も消す、など）をシステムに実装する上での重要な設計図となります。

【データベース】計算で出せるデータは保存しない？「導出属性」の設計思想｜情報処理問題1000本ノック

データベースのテーブル（実体）を設計する際、どの項目を保存すべきか。他の項目から自動的に計算して導き出せる「導出属性」の扱い方を攻略しましょう。

1. 【 問題 】：データモデルにおける属性の分類

【 問題 】 データベースの概念設計（ER図の作成など）において、実体（エンティティ）が持つ属性（カラム）のうち、その値をデータベース内に物理的なデータとして直接保持しなくても、他の属性の値を基に計算や加工（演算）を行うことによって自動的に導き出すことができる項目を何と呼ぶでしょうか？

① 主キー属性 (Primary Key Attribute)
② 導出属性 (Derived Attribute)
③ 複合属性 (Composite Attribute)
④ 多値属性 (Multivalued Attribute)

2. 正解：

正解： ② 導出属性（どうしゅつぞくせい）

3. 解説：データの重複を無くし、矛盾（バグ）の芽を摘む

データベースの正規化や設計においては、「無駄なデータは持たない（一元管理）」が鉄則です。その中心にある概念が導出属性です。

【導出属性の具体例と設計上のメリット】

・具体例：お買い物のテーブルにおいて、「単価」と「数量」があれば、それらを掛け算することで「金額」が導き出せます。また、「生年月日」があれば、現在のシステム日付から「年齢」を導き出せます。この場合の「金額」や「年齢」が導出属性です。 ← ココが問題の正解！

・なぜ物理保存を避けるのか？：もし「金額」をわざわざ固定のデータとして保存してしまうと、後から「数量を3個から2個に変更したのに、金額のデータを書き換え忘れた」というミスが起きた際、データに矛盾（バグ）が発生してしまいます。そのため、導出属性はデータとして保存せず、SQL文の中で「単価 × 数量 AS 金額」のようにその都度計算させる（またはビューや生成列を使う）のが基本デザインとなります。

[ 選択肢のひっかけポイント（すべてER図の設計に関わる属性） ]
★ ① 主キー属性：テーブル内のデータを一意に（1行だけに）識別するための、重複も空（NULL）も許されない超重要なコード（社員番号や注文IDなど）です。
★ ③ 複合属性：「住所」という項目の中に「都道府県・市区町村・番地」が含まれているように、さらに細かく分解できる属性のことです（RDBの設計では通常、分解して保存します）。
★ ④ 多値属性：1人の社員に対して「保有資格」が複数あるように、1つの枠の中に複数の値が入ってしまう属性のことです（RDBでは第1正規化によって別テーブルに分離します）。

1. 理解のコツ: 「レシート」をイメージしてください。
・お店のレジで、「リンゴ 150円（単価）」を「3個（数量）」買ったとき、合計が「450円（金額）」になるのは小学生でも分かりますよね。この450円という数字は、わざわざ頭の中に暗記しておかなくても、150×3というルール（演算）さえ分かっていればいつでもその場で生み出せます。この、他の情報から後出しで計算できる項目が導出属性です。
2. 試験対策の視点: 「他の属性から演算を行うことで導出できる」「単価と数量から金額」というドンピシャの例え話が来たら導出属性が一択です。基本情報や応用情報の午前試験では、概念データモデル（リレーション）を正しく設計できているかを問う問題や、システム設計の「無駄なデータを持たせない」という正規化の思想の基本としてよく出題されます。

---

4. まとめ

「データベースの容量を節約し、かつデータの計算ミス（不整合）を防ぐため、他のデータからの計算によってその都度導き出すべき項目」。これが導出属性です。パフォーマンスの都合であえて物理保存する（サマリーテーブルを作る）場合もありますが、基本設計の段階では「計算で出せるものは、元データだけをスマートに持つ」というこの思想がデータモデリングの土台となります。

【データベース】データの独立性を守る3大設計図！「3層スキーマ」｜情報処理問題1000本ノック

プログラムの変更がデータベースに影響しないようにする魔法の壁。ビュー、テーブル、物理ディスクの3つの視点を整理する「3層スキーマ」を攻略しましょう。

1. 【 問題 】：データベースの3層スキーマ構造

【 問題 】 データベースの設計思想において、データの独立性を高めるためにデータを「外部スキーマ」「概念スキーマ」「内部スキーマ」の3つの階層に分けて定義する「3層スキーマ構造」に関する記述のうち、最も適切なものはどれでしょうか？

① 外部スキーマは、ハードディスク上の物理的なデータの配置やインデックスの構造を定義する。
② 概念スキーマは、個々のユーザーやアプリケーションプログラムが必要とするデータの見取り図（ビュー）を定義する。
③ 内部スキーマは、データベース化の対象となる現実世界のデータ全体を、論理的なデータモデル（テーブル構造）として定義する。
④ 概念スキーマの変更が外部スキーマに影響を与えない性質を「論理的データ独立性」、内部スキーマ（物理構成）の変更が概念スキーマに影響を与えない性質を「物理的データ独立性」と呼ぶ。

2. 正解：

正解： ④ 概念スキーマの変更が外部スキーマに影響を与えない性質を「論理的データ独立性」、内部スキーマ（物理構成）の変更が概念スキーマに影響を与えない性質を「物理的データ独立性」と呼ぶ。

3. 解説：誰から見たデータか？3つの視点をスッキリ分離

3層スキーマ構造の目的は、「データ構造や保存場所が変わっても、プログラム（システム）を書き直さなくて済むようにする（データの独立性）」ことです。そのために、役割を3つの階層に分けています。

【3層スキーマの定義と役割】

■ 外部スキーマ（利用者・プログラムの視点）
・役割：個々のユーザーやアプリケーションが「見たい形」にカスタマイズした設計図です。関係データベース（RDB）では「ビュー（仮想テーブル）」などがこれに該当します。

■ 概念スキーマ（データベース全体の論理的視点）
・役割：開発者やDBMSから見た、データベース全体の「本来のテーブル構造（論理構造）」です。データの重複を無くす「正規化」を行い、実体の「テーブル」として定義します。

■ 内部スキーマ（ハードウェア・物理の視点）
・役割：データを「ハードディスクやSSDのどこに、どうやって保存するか」「インデックス（索引）をどう配置するか」という、物理的なファイル構成を定義する設計図です。

[ 選択肢のひっかけポイント（すべて主語が入れ替わっている罠） ]
★ ①：ハードディスク上の物理的な配置を定義するのは「内部スキーマ」です。
★ ②：ユーザーやプログラムが必要とする見取り図（ビュー）を定義するのは「外部スキーマ」です。
★ ③：データ全体を論理的なテーブル構造として定義するのは「概念スキーマ」です。
→ 正解の④は、この3層に分けることで「物理構成（内部）を変えてもテーブル（概念）は壊れない（物理的独立性）」「テーブル（概念）を多少いじってもビュー（外部）で吸収できる（論理的独立性）」という最大のメリットを正しく説明しています。

1. 理解のコツ: 「一戸建ての家」に例えてみましょう。
・住人が毎日目にする「リビングやキッチンの内装（使いやすさ）」が外部スキーマです。
・大工さんや建築士が共有する「柱の位置や部屋の間取り図面（全体の構造）」が概念スキーマです。
・床下の基礎工事や「コンクリート、鉄骨の物理的な配置」が内部スキーマです。
・もし「床下の鉄骨を最新の頑丈なものに変えた（内部の変更）」としても、部屋の間取り（概念）や住人の暮らし（外部）には何も影響しませんよね。これがデータの独立性です。
2. 試験対策の視点: 「外部＝ビュー（利用者側）」「概念＝テーブル（全体論理）」「内部＝ディスク（物理保存）」という対応関係のペアを絶対に脳内でブレさせないようにしてください。基本情報・応用情報の午前試験では、各スキーマの定義をシャッフルしたひっかけ問題や、「論理的／物理的データ独立性」という言葉の意味を問う問題が非常によく狙われます。

---

4. まとめ

「データベースの設計図を、プログラム側の都合（外部）、データ全体の構造（概念）、ストレージの都合（内部）の3つに切り離し、お互いの変更が響かないようにする工夫」。これが3層スキーマです。この思想があるからこそ、私たちはインフラのハードウェアを増強（内部を変更）しても、今動いている業務システム（外部）を一切止めることなく、そのまま使い続けることができるのです。

【データベース】データの出し入れを直接担うコア部品！「ストレージエンジン」｜情報処理問題1000本ノック

データベース管理システム（DBMS）の内部で、実際にハードディスクやメモリにアクセスしてデータを書き換えているのは誰か？その心臓部となるコンポーネントを攻略しましょう。

1. 【 問題 】：DBMSの内部構成とコンポーネント

【 問題 】 データベース管理システム（DBMS）を構成するソフトウェアモジュール（コンポーネント）のうち、ユーザーが発行したSQL文の要求に基づき、メモリ（バッファプール）やディスクなどの物理ストレージ上にある実際のデータブロックを操作し、データの検索、追加、更新、削除（CRUD処理）を直接管理・実行するコアな部品はどれでしょうか？

① クエリオプティマイザ (Query Optimizer)
② ストレージエンジン (Storage Engine)
③ トランザクションマネージャ (Transaction Manager)
④ データディクショナリ (Data Dictionary)

2. 正解：

正解： ② ストレージエンジン（Storage Engine）

3. 解説：SQLの命令を「物理的な動き」に変える心臓部

DBMSの内部は、いくつかの役割を持ったコンポーネントがチームワークで動いています。今回の正解であるストレージエンジンは、文字通りデータの「倉庫（ストレージ）」を動かす「エンジン（動力源）」です。

【ストレージエンジンの役割と具体例】

・ユーザーが「このデータを更新して」というSQL文を送ると、DBMSの上層部（クエリプロセッサ）がそれを解析します。
・その解析結果を受けて、実際に「ハードディスクの〇番地にあるデータを読み出す」「メモリ上のデータを書き換える」といった、最も泥臭い物理的なデータの出し入れ（検索や更新）を一手に引き受けるのがストレージエンジンです。 ← ココが問題の正解！

※有名なオープンソースのデータベース「MySQL」では、標準のストレージエンジンとして高い信頼性を持つ「InnoDB」が使われているほか、用途に応じて「MyISAM」や「Memory」といった異なる特性のストレージエンジンへ自由に入れ替える（差し替える）ことができる構造になっています。

[ 選択肢のひっかけポイント（すべてDBMSの超重要コンポーネント） ]
★ ① クエリオプティマイザ：送られてきたSQL文を見て、「どのインデックスを使えば一番速く検索できるか」という最適な実行計画（ルート）を自動で計算・決定する頭脳です。
★ ③ トランザクションマネージャ：データの排他制御（ロック）や、処理の確定（コミット）・取り消し（ロールバック）を管理し、データの整合性を守る司令塔です。
★ ④ データディクショナリ：テーブルの名前や列のデータ型、主キーの設定といった、データベース自身の設計図情報（メタデータ）を保管しているシステム領域です。

1. 理解のコツ: 「レストラン」に例えてみましょう。
・お客さんから注文（SQL）を取り、一番効率よく料理を出す順番（実行計画）を考えるフロア長がクエリオプティマイザです。
・それに対して、指示を受けて実際に冷蔵庫（ディスクやメモリ）を開け、肉や野菜（実際のデータ）を取り出して包丁で刻んだり炒めたり（検索や更新）する現場の「料理人」がストレージエンジンです。実務を直接動かすエンジンそのものです。
2. 試験対策の視点: 「DBMSのコンポーネント」「メモリやディスク上のデータ」「検索や更新を管理（直接操作）」という記述があれば「ストレージエンジン」が一択です。基本情報や応用情報の午前試験では、データベースの「外側（SQL文の使い方）」だけでなく、このように「内側（DBMSがどうやってデータを処理しているか）」のアーキテクチャを問う問題として非常に好まれる応用キーワードです。

---

4. まとめ

「SQLによる命令を具体的なディスクやメモリへのアクセスに翻訳し、データの検索・更新を物理的に実行する、DBMSの最下層で働く心臓部」。これがストレージエンジンです。普段私たちが何気なく叩いているSQL文の裏では、このストレージエンジンがミリ秒単位で超高速にデータをさばいてくれています。

【データベース】実務のデファクトスタンダード！「Read Committed」｜情報処理問題1000本ノック

データの安全性とシステムの処理速度。その2つが最も実用的なバランスで妥協（トレードオフ）した、実務で最頻出の分離レベル「Read Committed」を攻略しましょう。

1. 【 問題 】：トランザクション分離レベルの識別

【 問題 】 ANSI/ISOで定義されている4段階のトランザクション分離レベルのうち、他のトランザクションがコミット（確定）していない未確定の変更データの読み取り（ダーティリード）は防止されるが、自身の処理中に他のトランザクションがデータを更新・追加することによって発生する「ノンリピータブルリード」および「ファントムリード」の発生は許容されるものはどれでしょうか？

① Read Uncommitted (未コミット読み取り)
② Read Committed (コミット済み読み取り)
③ Repeatable Read (反復可能読み取り)
④ Serializable (直列化可能)

2. 正解：

正解： ② Read Committed（コミット済み読み取り）

3. 解説：「確定した事実」だけを信じる世界

Read Committedは、名前の通り「コミット（確定）されたデータだけを読み取る」というルールです。これにより、存在しない幻のデータを読んでしまう最悪の事態（ダーティリード）は100%防げます。

【なぜ他の2つの現象は起きてしまうのか？】

■ ノンリピータブルリードが起きる理由
・自分が1回目の読み込みをした後、他のトランザクションがデータを変更してコミットを完了したとします。
・Read Committedのルールは「コミットされたら読んでも良い」なので、自分が2回目の読み込みをすると、他人が確定させた最新の値（書き換わった後の値）が見えてしまいます。これが「同じ処理の中で、2回同じ場所を読んだのに値が変わってしまう（ノンリピータブルリード）」の原因です。

■ ファントムリードが起きる理由
・同様に、自分が検索した後に他人が新しいデータを挿入してコミットを完了すると、2回目の検索では、1回目には存在しなかったはずの「新しい行（ファントム）」が出現してしまいます。

[ 4段階のレベルと不整合の対応関係 ]
1. Read Uncommitted ＝ 【全て発生】（最速・最危険）
2. Read Committed ＝ 【ダーティ防止、残り2つは発生】（実務の標準） ← ココ！
3. Repeatable Read ＝ 【ダーティ・ノンリピ防止、ファントムのみ発生】
4. Serializable ＝ 【全て防止】（最堅牢・最遅）

1. 理解のコツ: 「オフィシャルの記者発表」をイメージしてください。まだ噂段階の未確定情報には一切耳を貸さず、公式発表（コミット）された情報だけを記事にするため、デマ（ダーティリード）を掴むリスクはありません。しかし、公式発表が朝と夕方で更新されれば、手元のニュース内容が変わる（ノンリピータブルリード）のは受け入れる、というスタンスです。
2. 試験対策の視点: 「ダーティリードは防ぐ（許容されない）」「ノンリピータブルリードとファントムリードは発生する（許容される）」という組み合わせが来たらRead Committedが一択です。多くのデータベースシステムでデフォルト（初期設定）に採用されているため、問題文での登場回数が圧倒的に多い最重要レベルです。

---

4. まとめ

「嘘のデータは読まないが、他人が確定させた最新の変化はそのまま受け入れる分離レベル」。これがRead Committedです。データの一貫性をある程度保ちつつ、データベースに余計なロック（待ち時間）をかけないため、大規模なアクセスを捌く現代のシステムにおいて最もバランスの良い設定とされています。

【データベース】最速だけど最も危険！ダーティリードを許す「Read Uncommitted」｜情報処理問題1000本ノック

データの正確性と、同時処理のスピードはトレードオフの関係にあります。今回は、4段階ある「トランザクション分離レベル」の中で最も制約が緩いレベルを攻略しましょう。

1. 【 問題 】：トランザクション分離レベル

【 問題 】 ANSI/ISOで定義されている4段階のトランザクション分離レベル（アイソレーションレベル）のうち、他のトランザクションがコミット（確定）していない未確定の変更データを読み取る現象（ダーティリード）の発生を許容するものはどれでしょうか？

① Read Uncommitted (未コミット読み取り)
② Read Committed (コミット済み読み取り)
③ Repeatable Read (反復可能読み取り)
④ Serializable (直列化可能)

2. 正解：

正解： ① Read Uncommitted（未コミット読み取り）

3. 解説：ロックをかけずにフライング読み込み

トランザクション分離レベルは、複数の処理が同時に動くときの「お互いの独立性の高さ」を表します。レベルが低いほど処理スピード（スルーブット）は上がりますが、不整合が起きやすくなります。

【4つの分離レベルと発生する現象のまとめ】

下に行くほどレベルが高く（厳格に）なり、有害な現象をブロックできます。

1. Read Uncommitted（←ココが正解！）
・特徴：他人が書き換えている最中のデータを「お構いなし」に読めます。
・発生する不整合：ダーティリード、ノンリピータブルリード、ファントムリード

2. Read Committed
・特徴：他人がコミットした（確定した）データだけを読みます。
・発生する不整合：ダーティリードを防ぐ（ブロックする）。残り2つは発生。

3. Repeatable Read
・特徴：自分の処理中に、他人がデータを書き換えても自分には見えません。
・発生する不整合：ファントムリード（行が追加される現象）のみ発生。

4. Serializable
・特徴：すべての処理を順番に1つずつ実行するのと同様の状態にします。
・発生する不整合：すべての有害な現象を完璧に防ぎます（最も安全）。

[ 選択肢のひっかけポイント ]
★ ②：Read Committed（コミット済み読み取り）は、名前の通り「コミットされたデータしか読まない」レベルなので、ダーティリードは発生しません。

1. 理解のコツ: 「書類の承認プロセス」をイメージしてください。まだ上司のハンコ（コミット）が押されていない、作成中の下書き書類を勝手にデスクから持ち出して使い始めてしまうレベルがRead Uncommitted（未コミット読み取り）です。書類が後から破棄（ロールバック）されるリスクがありますが、完成を待たずにすぐ動けるのでスピードだけは最速です。
2. 試験対策の視点: 「ダーティリードを許容する」「最も分離レベルが低い」という条件が来たら「Read Uncommitted」が一択です。試験では、この4つの分離レベルと、3大有害現象（ダーティ／ノンリピータブル／ファントム）が「どこまで防げるか」の対応表を丸暗記しておくことが、データベース分野の得点王への近道です。

---

4. まとめ

「他の処理が確定していないデータでも、お構いなしに読み取ってしまう最も低い分離レベル」。これがRead Uncommittedです。お金の計算など、1円の狂いも許されないシステムでは絶対に選んではいけない設定ですが、多少の誤差が許される統計データの集計など、速度を限界まで追い求めたいケースで限定的に使われます。

【データベース】フライング厳禁！幻のデータを読んでしまう「ダーティリード」｜情報処理問題1000本ノック

複数の処理が同時に動くとき、未確定のデータを盗み見てしまうことで発生するバグ。データの一貫性を損なう代表的な現象「ダーティリード」を攻略しましょう。

1. 【 問題 】：同時実行制御における有害現象

【 問題 】 データベースの同時実行制御において、あるトランザクションが更新処理を行ったがまだコミット（確定）していない状態のデータを、別のトランザクションが読み込んでしまう現象を何と呼ぶでしょうか？

① ノンリピータブルリード（非再現可能読み取り）
② ダーティリード（Dirty Read）
③ ファントムリード（幻像読み取り）
④ ライトスキュー（Write Skew）

2. 正解：

正解： ② ダーティリード（Dirty Read）

3. 解説：コミット前の「怪しいデータ」に手を出した結果

ダーティリードの「ダーティ（汚れた）」とは、まだ正式に承認されていない、不正確な状態のデータを指します。これが起きると、システム全体の数字が狂う原因になります。

【ダーティリードが引き起こす最悪のシナリオ】

1. トランザクションAが、口座残高を「1万円」から「5万円」に書き換える（※まだコミットしていない）。
2. トランザクションBが、その書き換えられた「5万円」を読み取って別の処理を始める（これがダーティリード）。
3. その直後、トランザクションAでエラーが発生し、処理がロールバック（取り消し）され、残高は元の「1万円」に戻る。
→ 結果として、トランザクションBは「現実に存在しない（幻の）5万円」をベースに処理を進めてしまい、データが完全に矛盾します。

[ 防ぐための分離レベル ]
★ 最も低いレベルの「Read Uncommitted」では発生してしまいますが、一段階上の「Read Committed（確定データの読み取り）」以上の設定にすれば、このダーティリードは完全に防ぐことができます。

1. 理解のコツ: 「お店のレジ」をイメージしてください。店員さんが商品をカゴに入れながら「合計5,000円です」と画面に出した（未コミット）のを見て、あなたが財布から5,000円を出そうとした瞬間、「あ、すいません、今の商品2倍の値段でした！」と取り消されたような状態です。確定する前の数字を信じて行動すると、トラブルになりますよね。
2. 試験対策の視点: 「コミットされていない変更を読み取る」「ロールバックによって存在しないデータを参照してしまう」という記述があればダーティリードが一択です。3大有害現象（ダーティ、ノンリピータブル、ファントム）の中で最も基礎的であり、真っ先に防ぐべき現象として出題されます。

---

4. まとめ

「他のトランザクションが確定していない、取り消される可能性のあるデータを読み込んでしまう現象」。これがダーティリードです。これが発生しないよう、現代のほとんどのRDBMSでは、デフォルトでこの現象をブロックする設定（Read Committed以上）になっています。

【データベース】1ミリの狂いも即座に許さない！「強い整合性」｜情報処理問題1000本ノック

分散データベースにおいて、「いずれ同じデータになる（結果整合性）」のではなく、「今この瞬間に全員が同じ最新データを共有する」という厳格な一貫性、強い整合性を攻略しましょう。

1. 【 問題 】：データの一貫性モデル

【 問題 】 分散データベースシステムにおいて、あるデータを更新した際、その処理が即座に反映され、それ以降にどのシステムやノードからデータを読み出しても、必ず最新の更新結果が返ってくることを保証する性質を何と呼ぶでしょうか？

① 最終整合性 (Eventual Consistency)
② 弱い整合性 (Weak Consistency)
③ 強い整合性 (Strong Consistency)
④ 因果整合性 (Causal Consistency)

2. 正解：

正解： ③ 強い整合性（Strong Consistency / ストロング・コンシステンシー）

3. 解説：「即座に反映」という絶対のルール

強い整合性は、従来のRDBMSのACID特性における「一貫性」を分散システムでも死守する考え方です。データのズレが許されない金融システムなどで必須となります。

【対比：強い整合性 vs 結果整合性】

■ 強い整合性（Strong Consistency）
・特徴：更新したら即座に全体へ反映。どこから読んでも「最新」。
・代償：全員の同期を待つため、書き込みの処理速度が落ちたり、通信が途切れた時にシステムが止まりやすい（可用性が下がる）。

■ 結果整合性（Eventual Consistency）
・特徴：更新した直後は古いデータが見えるかもしれないが、「いずれ（結果的に）」全員が同じ最新データに追いつく。
・利点：同期を待たないので超高速。一部のサーバーが死んでいても動き続けられる。

[ CAP定理との関係 ]
★ 分散システムでは「一貫性（C）」「可用性（A）」「分断耐性（P）」の3つのうち2つしか選べないという「CAP定理」があります。「強い整合性」を選ぶということは、一貫性（C）を最優先にするという意味です。

1. 理解のコツ: 銀行の口座残高をイメージしてください。AATMで現金を振り込んだら、別のBATMやスマホアプリで1秒後に残高を見ても、絶対に振り込み後の金額（最新）になっていなければ困ります。この「いつでもどこでも即座に最新」が強い整合性です。
2. 試験対策の視点: 「結果整合性に対して」「即座に反映を保証」「どのレプリカから読んでも同じ最新値」という表現があれば「強い整合性」が正解です。NewSQLなどの文脈でも非常によく出題されます。

---

4. まとめ

「更新処理を即座に反映し、常に最新の同一データを保証する特性」。これが強い整合性です。速度や可用性を犠牲にしてでも、データの正確性を最優先にするシステム設計の根幹となる概念です。

### 【データベース】過去の写し鏡で一貫性を保つ！「スナップショット分離」｜情報処理問題1000本ノック

データをロックして全員を待たせるのではなく、「処理を始めた瞬間のデータの写真（スナップショット）」を見せることで、超高速と高い整合性を両立する技術を攻略しましょう。

1. 【 問題 】：高度な同時実行制御

【 問題 】 トランザクションの同時実行制御において、各トランザクションが処理を開始した時点のデータベースの「スナップショット（一貫性のある過去のデータ状態）」を読み取ることで、他のトランザクションによる更新操作と衝突（ロックの競合）することなく、一貫した読み取りを可能にする分離レベルはどれでしょうか？

① Read Uncommitted
② スナップショット分離（Snapshot Isolation）
③ Read Committed
④ Serializable (厳格な悲観的ロック)

2. 正解：

正解： ② スナップショット分離（Snapshot Isolation）

3. 解説：「読者」と「筆者」が互いを邪魔しない

スナップショット分離は、MVCC（マルチバージョン同時実行制御）という技術を用いて実現されます。データを上書きするのではなく「古いバージョン」を残しておくことで、読み取り処理に過去のデータを提示します。

【スナップショット分離の3大メリット】

■ 読者は待たない、書く人も待たない
・誰かがデータを激しく更新していても、読み取り側は「自分が開始した時点のデータ」を読めばよいため、ロックによる順番待ちが発生しません。

■ 3大有害現象をすべて防止
・「ダーティリード」「ノンリピータブルリード」「ファントムリード」のすべてが発生しません（※実質的にRepeatable Read以上の堅牢性）。

■ ライトスキュー（Write Skew）という弱点
・非常に特殊なケースで、別々のデータを同時に更新し合うと、お互いのスナップショットが交差して矛盾（ライトスキュー）が起きる場合があります。

[ 現場での採用例 ]
★ PostgreSQL や Oracle、SQL Server など、現代の主要なRDBMSの多くが、このスナップショット（またはそれに類するMVCCの仕組み）をベースにして、高速かつ安全な並行処理を実現しています。

1. 理解のコツ: 共有ドキュメントをみんなで編集している時、あなたが「印刷（読み取り）」ボタンを押した瞬間の状態がそのまま印刷されるイメージです。印刷中に他の人が内容を書き換えても、あなたの手元の紙（スナップショット）は変わりません。
2. 試験対策の視点: 「開始した時点の」「ロックを伴わない一貫した読み取り」「MVCC」といったキーワードが出たらスナップショット分離です。データベースの性能を落とさずに整合性を保つための超重要技術として出題されます。

---

4. まとめ

「トランザクション開始時のデータ写真を見せることで、ロックなしで整合性を保つ仕組み」。これがスナップショット分離です。現代の高アクセスなWebシステムを支える、データベースエンジニア必須の教養です。

【データベース】読み取り中の変化を防ぐ！「反復可能読み取り（リピータブルリード）」｜情報処理問題1000本ノック

複数のトランザクションが同時に動くとき、どこまでデータの「割り込み」を許すか。4段階ある分離レベルのうち、上から2番目に厳格な「反復可能読み取り」を攻略しましょう。

1. 【 問題 】：トランザクションの分離レベル

【 問題 】 RDBMSのトランザクション分離レベル（アイソレーションレベル）のうち、「ダーティリード」と「ノンリピータブルリード（非再現可能読み取り）」の発生は防ぐことができるが、「ファントムリード（幻像読み取り）」が発生する可能性が残るものはどれでしょうか？

① 既存データの読み取り (Read Uncommitted)
② 確定データの読み取り (Read Committed)
③ 反復可能読み取り (Repeatable Read)
④ 直列化可能 (Serializable)

2. 正解：

正解： ③ 反復可能読み取り（Repeatable Read / リピータブルリード）

3. 解説：同じデータを何度読んでも「同じ」

「反復可能読み取り」という名前の通り、1つのトランザクションの中で同じデータを「反復」して何度読み込んでも、必ず同じ値が返ってくることを保証するレベルです。

【発生する現象の整理（起きない× / 起きる〇）】

・ダーティリード：×（発生しない）
　→ 他の人が「まだ確定していない（コミット前）」の怪しいデータを読めてしまう現象。
・ノンリピータブルリード：×（発生しない）
　→ 自分がさっき読んだデータを、他の人に「書き換え・削除」されて値が変わってしまう現象。
・ファントムリード：〇（発生する）
　→ 自分がデータを範囲検索している最中に、他の人がデータを「新規追加」したため、2回目に検索したときにデータが「幻（ファントム）」のように増えている現象。

[ 試験に出るマトリクス ]
★ Read Committed：ダーティだけ防ぐ（ノンリピータブルとファントムは起きる）
★ Repeatable Read：ダーティとノンリピータブルを防ぐ（ファントムだけ起きる）
★ Serializable：すべて防ぐ（完璧だが処理が遅い）

1. 理解のコツ: あなたが本棚の特定の小説（データ）を読んでいる間、他の人がその小説の文字を書き換えることはできません。これが反復可能読み取りです。ただし、他の人が本棚の隙間に「新しい別の本（ファントム）」をコッソリ差し込むことは止められない、というイメージです。
2. 試験対策の視点: 「ダーティとノンリピータブルは発生しない」「ファントムリードは発生する」という組み合わせは、試験でピンポイントに狙われます。英語名の「Repeatable Read」でも選べるようにしておきましょう。

---

4. まとめ

「自分が処理している間のデータ書き換えは許さないが、新規追加だけは防げないレベル」。これが反復可能読み取り（Repeatable Read）です。多くのRDBMS（MySQLなど）でデフォルトや推奨の設定として採用されている、非常に重要度の高い分離レベルです。