【データベース】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層スキーマ構造の最大の価値です。この構造を理解しておくことで、保守性が高く、変化に強いデータベース設計の基礎をマスターできます！

【データベース】データの「つながり」を管理する！グラフ型DBの正体｜情報処理問題1000本ノック

SNSの友人関係や物流のルート探索など、複雑に絡み合うデータの「関係性」を高速に処理したい。そんな時に活躍するのが、NoSQLの一種である「グラフ型データベース」です。

1. 問題：リンク構造を持つデータベース

【 問題 】 NoSQLデータベースの分類のうち、各データを「ノード（点）」、データ間のつながりを「エッジ（線）」として表現し、各レコードが他のレコードへのリンク（関係性）を持つ構造のものを何と呼ぶでしょうか？

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

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

正解： ③ グラフ型

3. 解説：関係性をたどるプロフェッショナル

一般的なRDB（関係データベース）で「友人の友人の友人」を探そうとすると、何度もテーブルを結合（JOIN）する必要があり処理が重くなります。一方、グラフ型は最初からデータ同士がリンクされているため、網の目をたどるように高速な探索が可能です。

[ グラフ型DBのポイント ]
・構成要素：データ本体である「ノード」と、関係性を示す「エッジ」で構成されます。
・得意分野：SNSのつながり、リコメンドエンジン、不正送金の検知、ネットワーク図の解析。

[ 他の選択肢との違い ]
★ キーバリューストア型：鍵と値のペアで保存する最も単純な構造（Redisなど）。
★ ドキュメント型：JSON形式などの自由な構造で保存する方式（MongoDBなど）。
★ カラム指向型：列単位でデータを保持し、集計処理に特化した方式（Cassandraなど）。

1. 理解のコツ: 「リンク（エッジ）自体がデータとして重みや意味を持っている」のがグラフ型の特徴です。例えばエッジに「親密度」というデータを持たせることで、より高度な解析が可能になります。
2. 最新トレンドの視点: 代表的な製品には「Neo4j」などがあります。最近ではAI（ナレッジグラフ）や、サイバー攻撃の感染経路特定といった高度なセキュリティ分析にもこのグラフ構造が応用されています。

---

4. まとめ

「点と線でつながりを管理する」。これがグラフ型データベースです。複雑なリレーションを扱うシステム設計において、RDBの限界を突破する選択肢として試験でも重要性が増しています！