6つめの応用情報技術者の科目A暗記用のブログです。
昨日は第1章～第5章まで、Ankiデータの修正作業で大変でした。今日は新たに第6章をやってまいりたいと思います。
さて、今日も元気に暗記データ、作成してまいりましょう！（ほぼQwenが頑張るんですが…）
第6章 データベース
データベース設計
| 単語 | 意味 |
|---|---|
| データベースの設計 | データベースの設計とは、現実世界の情報をコンピュータ上で効率よく管理・利用できるように整理し、構造を決める作業です。たとえば、学校の生徒情報や図書館の貸出履歴などをどう保存するかを考えます。目的は、データの重複を避け、正確で速くアクセスできるシステムを作ることです。設計が甘いと、後で修正が難しくなり、システム全体の信頼性が下がります。 |
| データベースの設計手順 | データベース設計は、大きく3段階に分かれます：①概念設計（何を扱うかを抽象的に決める）、②論理設計（テーブルや関係を定義）、③物理設計（実際のハードウェア上での配置）。この順序で進めることで、ビジネス要件から実装まで一貫性を持たせられます。途中で飛ばすと、後々「こんなはずじゃなかった」というトラブルになります。 |
| 概念設計 | 概念設計は、ユーザーの要求をもとに「何を管理したいのか」を抽象的に整理する段階です。たとえば、「顧客」「注文」「商品」といった“もの”と、それらの“関係”を洗い出します。この段階では具体的なテーブル名やカラム名は決めず、E-R図を使って視覚的に表現します。IT知識がなくても理解できるレベルで行うのがポイントです。 |
| 概念データモデル | 概念データモデルは、概念設計の結果を形式化したものです。最も代表的なのは「E-Rモデル（Entity-Relationship Model）」で、実体（Entity）と関連（Relationship）で構成されます。このモデルはDBMS（データベース管理システム）に依存せず、どんなシステムでも共通に使える“青写真”です。これにより、開発者とユーザーの認識ズレを防げます。 |
| データ分析 | データ分析は、既存の業務や文書（例：伝票、帳票）から必要なデータ項目を抽出する作業です。たとえば、受注伝票から「注文日」「顧客ID」「商品コード」などを拾い出します。このプロセスで漏れがあると、後でデータが足りないと気づき、再設計が必要になります。丁寧な分析が高品質なDBの第一歩です。 |
| データ項目の標準化 | 同じ意味のデータでも、部署ごとに呼び方が違う（例：「顧客番号」vs「得意先コード」）と混乱します。そこで、全社で統一した名称・型・単位を決めるのが「データ項目の標準化」です。これにより、システム間連携がスムーズになり、保守性も向上します。国際標準（ISO/IEC 11179など）も参考にされます。 |
| トップダウンアプローチ | トップダウンアプローチは、全体像（例：企業全体の業務）から細部（例：個別の取引）へと設計を進める方法です。まず大枠のE-R図を作り、徐々に詳細化します。全体の一貫性が保ちやすく、大規模システムに向いていますが、初期の抽象化が難しいという課題もあります。 |
| ボトムアップアプローチ | ボトムアップアプローチは、既存の帳票やファイルから個別のデータ項目を拾い上げ、徐々に統合していく方法です。小規模システムや既存システムの改修に適しています。ただし、全体の整合性が取りにくく、後で大きな修正が必要になるリスクがあります。 |
| 論理設計 | 論理設計では、概念モデルを具体的な「テーブル構造」に変換します。たとえば、E-R図の「顧客」実体を「customers」というテーブルにし、属性をカラムにします。この段階ではまだDBMSの種類（MySQL、Oracleなど）は意識せず、純粋に関係モデルに基づいて設計します。 |
| 論理データモデル | 論理データモデルは、論理設計の成果物で、主に「関係モデル（テーブル形式）」で表現されます。ここでは、主キー、外部キー、制約などが明確に定義されます。このモデルは、プログラマがアプリケーションを開発する際の“設計図”となります。 |
| 階層モデル | 階層モデルは、データを木構造（親子関係）で表現する古いモデルです。例：会社 → 部署 → 社員。親は複数の子を持てるが、子は1つの親しか持てません。IBMのIMSなどで使われましたが、柔軟性に欠けるため、現在はほとんど使われていません。 |
| 網モデル | 関係モデルは、データを「表（関係）」の集まりとして扱う数学的モデルです。各行（タプル）は一意で、列（属性）にはドメイン（定義域）が定められています。このモデルは、1970年にE.F.コッド博士が提唱し、今日のRDBMSの基礎となっています。 |
| 関係モデル | 関係モデルは、データを「表（テーブル）」の集まりとして扱う現代の主流モデルです。各行が1つのレコード、各列が属性に対応します。数学の「集合論」に基づいており、SQLなどの言語で操作できます。柔軟性・簡潔性・理論的堅牢性が評価され、ほぼすべての現代DBで採用されています。 |
| 関係モデルへの変換 | E-R図などの概念モデルを関係モデルに変換するには、実体→テーブル、属性→カラム、関連→外部キーまたは中間テーブルにします。特に「多対多」の関連は、新たに「結合テーブル」を作る必要があります。 |
| 非NULL制約 | 非NULL制約（NOT NULL制約）は、「そのカラムに空（NULL）を許さない」というルールです。たとえば、顧客名がNULLだと困るので、customer_name NOT NULLと指定します。これにより、必須情報の抜けを防げます。 |
| 検査制約 | 検査制約（CHECK制約）は、カラムの値が特定の条件を満たすことを強制するものです。例：age >= 0 AND age <= 150。これにより、不正なデータ（例：年齢が-5歳）の登録を防げます。SQLではCHECK (条件式)で定義します。 |
| 物理設計 | 物理設計は、論理モデルを実際のハードウェア上で効率よく動かすための設計です。インデックスの配置、ファイルの分割、キャッシュ設定などが含まれます。たとえば、よく検索されるカラムにインデックスを張ると、検索が速くなります。DBMSの特性を深く理解する必要があります。 |
| 3層スキーマ構造 | データベースは、①外部スキーマ（ユーザー視点）、②概念スキーマ（全体論理構造）、③内部スキーマ（物理記憶）の3層で構成されます。これにより、ある層の変更が他の層に影響しにくくなり、柔軟なシステム設計が可能になります。 |
| データの独立性 | データの独立性とは、ある部分を変更しても他の部分に影響を与えない性質です。3層スキーマのおかげで、たとえば物理記憶方式を変えてもアプリケーション（外部スキーマ）はそのまま動きます。これは大規模システムの保守性を高めます。 |
| 論理データ独立性 | 論理データ独立性は、「概念スキーマが変わっても外部スキーマ（アプリ）が影響を受けない」性質です。たとえば、新しいカラムを追加しても、古いプログラムはそのまま使えます。ビュー（仮想テーブル）を使うことで実現されます。 |
| 外部スキーマ | 外部スキーマは、個々のユーザーまたはアプリケーションが見る「仮想的なテーブル」です。実際のテーブルの一部だけを見せたり、複数テーブルを1つに見せたりできます。セキュリティや使いやすさの向上に役立ちます。 |
| 概念スキーマ | 概念スキーマは、組織全体のデータ構造を記述したもので、すべてのテーブル・キー・制約が定義されています。DBA（データベース管理者）が管理し、アプリ開発者はこれに基づいてプログラムを書きます。 |
| 内部スキーマ | 内部スキーマは、データがハードディスク上にどう格納されるか（ファイル形式、インデックス構造、圧縮方法など）を定義します。ユーザーからは見えず、DBMSが自動で処理します。 |
| インメモリデータベース | インメモリデータベースは、データをメモリ上に常駐させて高速処理を実現するDBです。従来のディスクベースDBより100倍以上高速で、リアルタイム分析や金融取引に使われます。2026年現在、SAP HANAやRedisなどが代表的です。 |
| E-R図 | E-R図（Entity-Relationship Diagram）は、データベースの概念設計を視覚的に表現する図です。「実体」「属性」「関連」の3要素で構成され、関係性を直感的に理解できます。ソフトウェア（例：MySQL Workbench、draw.io）で簡単に描けます。 |
| E-R図の構成要素 | E-R図の主な構成要素は、①実体（長方形）、②属性（楕円）、③関連（菱形）です。実体は「顧客」のような名詞、属性は「名前」「年齢」、関連は「注文する」のような動詞で表されます。現代では属性を実体の内側に書く簡略形も一般的です。 |
| 実体（エンティティ） | 実体とは、現実世界で識別可能な“もの”や“概念”です。例：「学生」「商品」「注文」。データベースでは1つの実体が1つのテーブルに対応します。実体は「強実体」と「弱実体」に分けられ、後者は他に依存して存在します。 |
| インスタンス | インスタンスは、実体の1つ1つの具体例です。たとえば、「実体：学生」に対して、「山田太郎」「佐藤花子」がインスタンスです。テーブルの1行が1つのインスタンスに対応します。 |
| 識別子 | 識別子（Identifier）は、実体のインスタンスを一意に識別する属性です。例：学生ID、ISBNコード。これが後に「主キー」となり、重複や曖昧さを防ぎます。自然キー（現実のID）と代理キー（自動採番）があります。 |
| 属性 | 属性は、実体の特徴を表すデータ項目です。例：「学生」実体の属性は「名前」「学年」「メールアドレス」など。属性には「単純属性（1値）」「複合属性（住所など）」「多値属性（複数電話番号）」がありますが、関係モデルではすべて単純属性に分解します。 |
| 関係（リレーションシップ） | 関連は、2つ以上の実体の間の関係を表します。例：「学生が授業を受講する」。関連には「1対1」「1対多」「多対多」の3種類があり、それぞれテーブル設計が異なります。多対多は特別な処理が必要です。 |
| 「多対多」から「1対多」への変換 | 「多対多」関連（例：学生と授業）は、直接テーブルにできません。そこで、中間テーブル（例：enrollments）を作り、「学生─1対多─enrollments─多対1─授業」と2つの「1対多」に分解します。この中間テーブルを「連関エンティティ」と呼びます。 |
| 連関エンティティ | 連関エンティティ（Associative Entity）は、多対多関連を解決するために導入される中間テーブルに対応する実体です。自身の属性（例：受講日、成績）を持つこともあり、単なる接続役を超えて重要なデータを保持します。 |
| 独立エンティティ | 独立エンティティは、他の実体に依存せずに存在できる実体です。例：「顧客」「商品」。これらの主キーは、他のテーブルの値に依存しません。通常は「強実体」と同義です。 |
| 依存エンティティ | 依存エンティティは、他の実体が存在しないと意味を持たない実体です。例：「注文明細」は「注文」がなければ存在できません。主キーに親の主キーを含むことが多く、「弱実体」とほぼ同じ意味です。 |
| 弱エンティティ（弱実体） | 弱エンティティは、他の実体（所有者）に依存して存在し、単独では一意に識別できない実体です。E-R図では二重長方形で表されます。主キーは、所有者の主キー＋独自の識別子で構成されます（例：注文ID + 明細番号）。 |
| 強エンティティ（強実体） | 強エンティティは、単独で一意に識別でき、他の実体に依存しない実体です。例：「社員」「部門」。主キーは自身の属性だけで構成され、E-R図では通常の長方形で表されます。 |
| ループ構造の表現 | ループ構造（再帰的関連）とは、同じ実体同士が関連するケースです。例：「社員が他の社員を上司とする」。E-R図では、1つの実体から出て戻ってくる関連線で表現し、ロール名（例：「上司」「部下」）を付けて区別します。 |
関係データベース
| 単語 | 意味 |
|---|---|
| 関係データベース | 関係データベース（RDB）は、関係モデルに基づいて構築されたデータベースです。データはすべてテーブル形式で保存され、SQL（Structured Query Language）で操作します。代表的な製品には、Oracle、MySQL、PostgreSQL、SQL Serverがあります。 |
| タプル | タプル（tuple）は、関係（テーブル）における1行のデータを指します。例：(101, "山田", 20) は1つのタプルです。各タプルは、属性の値の組で構成され、重複は原則として禁止されます。 |
| 属性の定義域 | 属性の定義域（ドメイン）とは、その属性が取り得る値の集合です。例：「年齢」のドメインは「0～150の整数」。ドメインを定義することで、不正な値（例：年齢が"ABC"）を事前に防げます。SQLではデータ型（INT, VARCHARなど）で近似的に表現します。 |
| 定義域の定義 | ドメインは、属性の意味と制限を明確にするための仕組みです。たとえば、「郵便番号」のドメインは「7桁の数字」。複数の属性が同じドメインを共有すれば、整合性が保たれます。理論的には、ドメイン名を定義して再利用できます（例：CREATE DOMAIN zip_code AS CHAR(7)）。 |
| 関係データベースのキー | キーは、タプルを一意に識別するための属性（または属性の組）です。主キー、外部キー、候補キーなどがあり、データの整合性と検索効率の根幹を担います。 |
| スーパキー | スーパキーは、重複のないタプルを識別できる属性の集合です。例：（学生ID, 名前）はスーパキーだが、実は（学生ID）だけで十分。つまり、スーパキーは「過剰でもOK」ですが、最小限ではない可能性があります。 |
| 候補キー | 候補キーは、スーパキーのうち「最小限の属性」で構成されるものです。つまり、余分な属性が1つもないスーパキーです。1つのテーブルに複数の候補キーがある場合、その中から1つが主キーに選ばれます。 |
| 主キー | 主キー（Primary Key）は、テーブル内で1つだけ選ばれた候補キーで、各レコードを一意に識別します。NULLを許さず、重複も禁止されます。例：顧客テーブルの「customer_id」。主キーがあることで、他のテーブルから参照（外部キー）が可能になります。 |
| 外部キー | 外部キー（Foreign Key）は、他のテーブルの主キーを参照するカラムです。例：注文テーブルの「customer_id」は、顧客テーブルの主キーを指します。これにより、テーブル間の整合性（参照整合性）が保たれます。 |
| 参照制約 | 参照制約（Referential Integrity Constraint）は、「外部キーの値は、参照先の主キーに存在していること」を保証するルールです。これにより、存在しない顧客IDの注文が登録されるのを防げます。削除時や更新時の動作（CASCADE, RESTRICTなど）も定義できます。 |
| 代用のキー設定 | 代用キー（Surrogate Key）は、業務上自然なIDがない場合に、DBが自動で採番する主キー（例：AUTO_INCREMENT）です。利点はシンプルで高速、欠点は意味を持たないことです。自然キー（例：メールアドレス）と比べて、安定性が高いのが特徴です。 |
正規化
| 単語 | 意味 |
|---|---|
| 関数従属 | 関数従属（Functional Dependency）とは、「属性Aの値が決まれば、属性Bの値が1つに決まる」関係です。記号では A → B と書きます。例：「学生ID → 氏名」。これは正規化の基礎となる概念です。 |
| 独立属性（決定項） | 関数従属 A → B において、Aを「決定項（Determinant）」または独立属性と呼びます。これは、他の属性の値を決定する側の属性です。主キーは、他のすべての属性を関数的に決定します。 |
| 従属属性（従属項） | 関数従属 A → B において、Bを「従属項（Dependent）」と呼びます。これは、Aの値に依存して決まる属性です。例：「商品コード → 商品名」なら、「商品名」が従属項です。 |
| 部分関数従属 | 部分関数従属とは、複合主キーの一部だけで他の属性が決まってしまう状態です。例：主キー（注文ID, 商品ID）→ 注文日。ここで「注文日」は「注文ID」だけで決まるので、部分従属。第2正規化で解消します。 |
| 完全関数従属 | 完全関数従属とは、属性が主キー全体に依存している状態です。例：（学生ID, 授業ID）→ 成績。この場合、「成績」は両方のIDがないと決まらないので、完全従属。これは正規化された良い状態です。 |
| 推移的関数従属 | 推移的関数従属とは、A → B かつ B → C のとき、A → C が成り立つ関係です。例：学生ID → 学科 → 学科長。すると「学生ID → 学科長」が推移的に成立。これは第3正規化で排除します。 |
| 完全推移的関数従属 | 完全推移的関数従属は、主キー → 非キー属性X → 非キー属性Y のように、主キーから間接的に従属する関係です。第3正規化では、このような非キー属性間の従属を別のテーブルに分離します。 |
| 正規化の手順 | 正規化は、第1正規化 → 第2正規化 → 第3正規化 → （必要ならBC正規化）と段階的に進めます。各ステップで特定の異常（更新・挿入・削除の問題）を解消し、データの整合性と効率を高めます。 |
| 第1正規化 | 第1正規化（1NF）は、「繰り返し属性や複合属性をなくし、すべての属性を原子値（これ以上分割できない値）にする」ことです。例：「電話番号1, 電話番号2」を別テーブルに分ける。これにより、SQLで扱えるようになります。 |
| 修正時異常 | 修正時異常（Update Anomaly）とは、同じ情報が複数箇所に存在するため、1か所だけ更新されて整合性が崩れる問題です。例：顧客住所が複数注文レコードに含まれていて、1つだけ更新漏れ。正規化で解消します。 |
| 挿入時異常 | 挿入時異常（Insertion Anomaly）とは、関連データがないとレコードが登録できない問題です。例：まだ注文していない顧客の情報を登録できない。これはテーブルが分離されていないために起こります。 |
| 削除時異常 | 削除時異常（Deletion Anomaly）とは、不要なデータを削除した結果、必要な情報まで失われる問題です。例：注文を全削除したら、顧客情報も消えてしまった。正規化でテーブルを分離すれば防げます。 |
| 第2正規化 | 第2正規化（2NF）は、第1正規化済みのテーブルで「部分関数従属をなくす」ことです。複合主キーの場合、主キーの一部に依存する属性を別テーブルに分離します。これにより、更新異常が減ります。 |
| 第3正規化 | 第3正規化（3NF）は、「非キー属性同士の関数従属（推移的従属）をなくす」ことです。主キーに直接依存しない属性を別のテーブルに移します。例：「学生 → 学科 → 学科長」を「学生テーブル」と「学科テーブル」に分離。 |
| 正規化と非正規化 | 正規化はデータ整合性を高めますが、検索が遅くなることがあります。そこで、パフォーマンス重視の場面では「非正規化（Denormalization）」——意図的に冗長データを許容する——を行います。バランスが重要です。 |
関係データベースの演算
| 単語 | 意味 |
|---|---|
| 集合演算 | 関係データベースの演算には、集合論に基づく「集合演算」と、関係専用の「関係演算」があります。集合演算は、同じ属性構造を持つ2つのテーブルに対して行えます。 |
| 和、共通、差 | 和（UNION）は、2つのテーブルの全レコードを結合（重複除去）。共通（INTERSECT）は、両方に存在するレコードのみ。差（EXCEPT/MINUS）は、片方にあってもう片方にないレコード。これらはSQLで直接サポートされます。 |
| 直積 | 直積（Cartesian Product）は、2つのテーブルのすべての行を組み合わせた結果です。例：Aテーブルが3行、Bが4行なら、12行の結果に。通常はWHEREで絞る（＝結合）ため、単体では使われません。 |
| 関係演算 | 関係演算は、関係モデル専用の操作で、代表的なものに「選択」「射影」「結合」「商」があります。これらを組み合わせて、任意のクエリが表現可能です（関係完全性）。 |
| 選択と射影 | 選択（Selection）は、条件に合う行を取り出す操作（例：年齢>20）。射影（Projection）は、必要な列だけを取り出す操作（例：名前とメールだけ表示）。SQLでは WHERE と SELECT に対応します。 |
| 結合 | 結合（Join）は、2つのテーブルをある条件で横に連結する操作です。最もよく使われる演算で、主に「等結合（Equi-Join）」や「外部結合（Outer Join）」があります。 |
| 等結合 | 等結合は、2つのテーブルの特定カラムの値が等しい行だけを結合します。例：注文テーブルと顧客テーブルを customer_id で結合。SQLの JOIN ... ON がこれに相当します。 |
| 商 | 商（Division）は、「ある条件をすべて満たすもの」を求める高度な演算です。例：「全商品を注文した顧客」を探す。SQLではサブクエリやEXCEPTで実現しますが、直感的ではありません。 |
| 結合演算の種類 | 結合には、①内部結合（INNER JOIN）、②左外部結合（LEFT OUTER JOIN）、③右外部結合（RIGHT OUTER JOIN）、④完全外部結合（FULL OUTER JOIN）があります。外部結合は、対応する行がなくても片方のデータを残すのが特徴です。 |
SQL
| 単語 | 意味 |
|---|---|
| SQL文の種類 | SQL（Structured Query Language）は、データベースを操作するための言語で、大きく4つに分類されます：①DDL（データ定義言語：CREATEなど）、②DML（データ操作言語：SELECT, INSERTなど）、③DCL（データ制御言語：GRANT, COMMITなど）、④カーソル操作（DECLARE CURSORなど）。これらを組み合わせて、データの作成・検索・更新・削除・権限管理が可能です。 |
| CREATE | CREATEは、テーブルやビュー、インデックスなどの「データベースオブジェクト」を新しく作る命令です。これはDDL（データ定義言語）に属します。たとえば、CREATE TABLE students (...) で学生テーブルを作成できます。一度作ると、アプリケーションからその構造を使ってデータを扱えます。 |
| DROP | DROPは、テーブルやビューなどのオブジェクトを完全に削除するDDL命令です。 例： DROP TABLE students;注意点は、データもすべて消えること。誤って実行すると復旧が難しいため、本番環境では慎重に使います。逆に、開発中は気軽に構造をリセットできる便利な命令でもあります。 |
| ALTER | ALTERは、既存のテーブル構造を変更するDDL命令です。 例： ALTER TABLE students ADD COLUMN email VARCHAR(100);でメール欄を追加できます。列の削除、型変更、制約追加なども可能。ただし、一部のDBMSでは制限があるため、事前に確認が必要です。 |
| SELECT | SELECTは、データを「読み取る」DML命令で、最もよく使われるSQLです。 例： SELECT name FROM students;で名前一覧を取得。WHEREやGROUP BYと組み合わせれば、条件検索や集計も可能。データを壊さない安全な操作なので、初心者も最初に学ぶべき命令です。 |
| INSERT | INSERTは、新しいデータをテーブルに「追加」するDML命令です。 例： INSERT INTO students (id, name) VALUES (1, '山田');列の順番や数に注意が必要で、NOT NULL制約に違反するとエラーになります。大量データ投入にも使われ、ETL処理の基本です。 |
| UPDATE | UPDATEは、既存のデータを「修正」するDML命令です。 例： UPDATE students SET name = '佐藤' WHERE id = 1;WHERE句を忘れると全行が更新されてしまうので、非常に危険。テスト環境で必ず確認し、必要ならトランザクションで囲みましょう。 |
| DELETE | DELETEは、データを「削除」するDML命令です。 例： DELETE FROM students WHERE id = 1;これもWHEREを忘れると全データ消失！ 実際の業務では「論理削除（deletedフラグを立てる）」を使うことも多いです。物理削除は不可逆なので、特に注意が必要です。 |
| GRANT | GRANTは、ユーザーに特定の権限（例：SELECT, INSERT）を「与える」DCL命令です。 例： GRANT SELECT ON students TO user1;セキュリティの要で、最小権限の原則（必要な権限だけ与える）が重要。権限漏洩を防ぐために、定期的な見直しが推奨されます。 |
| REVOKE | REVOKEは、GRANTで与えた権限を「取り消す」DCL命令です。 例： REVOKE INSERT ON students FROM user1;退職者や役割変更時に必須。権限管理は監査（Audit）対象にもなるため、ログを残すことが一般的です。 |
| COMMIT | COMMITは、トランザクション（一連の操作）を「確定」する命令です。 例：銀行振込で「口座Aから引く→口座Bに足す」の両方が成功したらCOMMIT これにより、他のユーザーから変更が見えるようになります。ACID特性（原子性・一貫性・隔離性・耐久性）の要です。 |
| ROLLBACK | ROLLBACKは、トランザクション中の変更を「全部取り消す」命令です。 例：途中でエラーが起きたらROLLBACKで元に戻せます。 これにより、データの不整合を防げます。多くのDBMSでは、明示的にBEGIN TRANSACTIONしない限り、各DMLが自動コミットされます。 |
| DECLARE CURSOR | DECLARE CURSORは、複数行の結果を1行ずつ処理するための「カーソル」を定義する命令です。 例： DECLARE s_cursor CURSOR FOR SELECT name FROM students;主にストアドプロシージャ内で使われ、アプリケーション側でループ処理する代わりになります。 |
| OPEN | OPENは、DECLAREで定義したカーソルを「実行して開く」命令です。 例： OPEN s_cursor;これにより、内部でクエリが実行され、結果セットが準備されます。FETCHで1行ずつ取り出す前に行う必要があります。 |
| FETCH | FETCHは、カーソルから「次の1行を取り出す」命令です。 例： FETCH s_cursor INTO :name_var;（:name_varはホスト変数）繰り返し実行することで、全行を順に処理できます。行がなくなるとSQLCODEに終了コードが入ります。 |
| CLOSE | CLOSEは、カーソルを「閉じる」命令です。 例： CLOSE s_cursor;これにより、メモリやロックが解放されます。使用後は必ずCLOSEし、必要ならDEALLOCATEで定義も削除します。リソースリークを防ぐためのマナーです。 |
| FROM句 | FROM句は、SELECT文で「どのテーブルからデータを取るか」を指定します。 例： SELECT * FROM students;複数テーブルを指定すれば結合（JOIN）の対象に。サブクエリやビューも指定可能で、SQLの出発点となる重要な句です。 |
| WHERE句 | WHERE句は、「条件に合う行だけを取り出す」ためのフィルタです。 例： SELECT * FROM students WHERE age > 18;比較演算子（=, <>, > など）や論理演算子（AND, OR）を使えます。NULLとの比較には特別な述語（IS NULL）が必要です。 |
| GROUP BY句 | GROUP BYは、同じ値を持つ行を「まとめて」集計するための句です。 例： SELECT dept, COUNT(*) FROM employees GROUP BY dept;で部署ごとの人数を表示。SELECT句にはGROUP BYの列か集計関数しか書けません。 |
| HAVING句 | HAVINGは、GROUP BYでまとめたグループに対して「さらに条件をかける」句です。WHEREは個々の行に作用するのに対し、HAVINGはグループ全体に作用します。 例： ... HAVING COUNT(*) > 5;で5人以上の部署だけ表示。 |
| SELECT句 | SELECT句は、「どの列を表示するか」を指定します。* なら全列、name, age なら特定列。集計関数（SUM, AVGなど）や式（price * 1.1）も書けます。別名（AS）を付けることで、出力を見やすくできます。 |
| 論理演算子 | 論理演算子は、複数の条件を組み合わせるのに使います。AND（両方成立）、OR（いずれか成立）、NOT（否定）。 例： WHERE age > 18 AND city = 'Tokyo';優先順位に注意し、必要なら()で囲みましょう。条件が複雑になると可読性が下がるので、適度に整理しましょう。 |
| IS NULL述語 | NULL（未入力）は普通の値ではないので、= では比較できません。代わりに IS NULL または IS NOT NULL を使います。例： SELECT * FROM students WHERE email IS NULL;でメール未登録者を抽出。データ品質チェックに頻出です。 |
| BETWEEN述語 | BETWEENは、「ある範囲内」の値を指定する述語です。 例： WHERE age BETWEEN 18 AND 25; は age >= 18 AND age <= 25と同じ。 日付や数値でよく使われ、可読性が高いのが利点。境界値を含む（閉区間）ことに注意。 |
| IN述語 | INは、「複数の値のどれかに一致」する条件です。 例： WHERE city IN ('Tokyo', 'Osaka');サブクエリとも組み合わせられ、 WHERE id IN (SELECT customer_id FROM orders); のように使えます。ORより簡潔で高速な場合があります。 |
| LIKE述語 | LIKEは、文字列の「部分一致検索」に使います。% は任意の文字列、_ は1文字を表す。例： WHERE name LIKE '山%';で「山」で始まる名前を検索。大文字小文字の区別はDBMSにより異なる（MySQLは区別しないが、PostgreSQLは区別）。 |
| グループ化 | グループ化は、集計関数でデータを要約します。SUM(salary)：給与合計AVG(score)：平均点MAX(price)：最高価格MIN(date)：最古の日付COUNT(*)：全行数（NULL含む）COUNT(email)：emailがNULLでない行数例： 1 SELECT dept, AVG(salary), COUNT(*) 2 FROM employees 3 GROUP BY dept; |
| 出力順の指定 | ORDER BY句で結果の並び順を指定します。 例： ORDER BY name ASC;（昇順）、ORDER BY salary DESC;（降順）複数列も可能： ORDER BY dept, salary DESC;。大量データではパフォーマンスに影響するため、インデックス設計が重要です。 |
| 単語 | 意味 |
|---|---|
| 表の結合 | 結合（Join）は、複数のテーブルを「関連付けて1つの結果にする」操作です。主キーと外部キーでつなぎ、例：顧客と注文を結合して「誰が何を買ったか」を表示。内部結合と外部結合があり、目的に応じて使い分けます。 |
| 内結合 | 内結合（INNER JOIN）は、両方に存在する行だけを結合します。 例： 1 SELECT c.name, o.date 2 FROM customers c INNER JOIN orders o ON c.id = o.customer_id; 注文のない顧客は表示されません。これが最も基本的な結合です。 |
| 外結合 | 外結合（OUTER JOIN）は、片方のテーブルの行を「強制的に残す」結合です。LEFT/RIGHT/FULLの3種類があり、データの欠落を防ぎたいときに使います。 例：注文のない顧客も表示したい場合にLEFT OUTER JOINを使います。 |
| 左外結合 | 左外結合（LEFT OUTER JOIN）は、FROM句の左側のテーブルの全行を残します。右に該当がない場合はNULL。 例： 1 SELECT c.name, o.date 2 FROM customers c LEFT JOIN orders o ON c.id = o.customer_id; （※LEFT JOINはLEFT OUTER JOINの省略形） |
| 右外結合 | 右外結合（RIGHT OUTER JOIN）は、右側のテーブルの全行を残します。左に該当がない場合はNULL。 例： 1 SELECT c.name, o.date 2 FROM customers c RIGHT JOIN orders o ON c.id = o.customer_id; 注文はあるが顧客情報がない（異常データ）場合に使われることも。 |
| 完全外結合 | 完全外結合（FULL OUTER JOIN）は、両方のテーブルの全行を残します。どちらかにしかない行は、他方をNULLで埋めます。 例： 1 SELECT c.name, o.date 2 FROM customers c FULL OUTER JOIN orders o ON c.id = o.customer_id; MySQLはサポートしていないが、PostgreSQLやOracleは対応。 |
| COLESCE式 | COALESCE（コアレス）は、複数の値の中から「最初のNULLでない値」を返す関数です。 例： COALESCE(phone_home, phone_mobile, '連絡先なし')NULLを代替値に置き換えるのに便利で、レポート作成でよく使われます。 |
| 表に相関名（別名）を設定する方法 | 相関名（別名）は、テーブルや列の名前を一時的に短くする機能です。ASキーワードで指定。 例： 1 SELECT e.name AS employee_name, d.name AS dept_name 2 FROM employees AS e JOIN departments AS d ON e.dept_id = d.id; ASは省略可能ですが、可読性向上のため明記が推奨されます。 |
| 3つの表を結合する方法 | 3つ以上のテーブルも順次JOINできます。 例：社員＋部署＋国： 1 SELECT e.name, d.name, c.country_name 2 FROM employees e 3 JOIN departments d ON e.dept_id = d.id 4 JOIN countries c ON d.country_id = c.id; 結合順は意味を持ち、パフォーマンスにも影響します。 |
| 副問合せ | 副問合せ（サブクエリ）は、SELECT文の中に別のSELECTを入れる技術です。 例： 1 SELECT name 2 FROM students 3 WHERE score > (SELECT AVG(score) FROM students); これで平均点より高い学生を抽出。入れ子にできるが、深すぎると読みにくくなります。 |
| 相関副問合せとEXISTS | 相関副問合せは、外側のクエリの値を内側で使うサブクエリです。EXISTSと組み合わせて「存在するか」を判定。 例： 1 SELECT name 2 FROM customers c 3 WHERE EXISTS ( 4 SELECT 1 FROM orders o WHERE o.customer_id = c.id 5 ); 注文がある顧客だけを抽出。効率的で、INより高速な場合があります。 |
| SQLによる集合演算の実現 | 集合演算は、同じ構造の2つの結果に対して行います。 和： SELECT ... UNION SELECT ...（重複除去）共通： SELECT ... INTERSECT SELECT ...差： SELECT ... EXCEPT SELECT ...（MySQLはサポートせず）直積： SELECT * FROM A, B;（WHEREなしの結合）例（和）： 1 SELECT name FROM part_time 2 UNION 3 SELECT name FROM full_time; |
| 自然結合 | 自然結合（NATURAL JOIN）は、同じ名前の列を自動で結合キーにする機能。 例： 1 SELECT * FROM customers NATURAL JOIN orders; customersとordersに共通の customer_idがあれば、それをON句なしで結合。便利だが、意図せず結合されるリスクあり。明示的なJOINが安全。 |
| WITH句 | WITH句（共通テーブル式：CTE）は、一時的な名前付き結果を作れます。再利用や可読性向上に。 例： 1 WITH high_score AS ( 2 SELECT * FROM students WHERE score > 90 3 ) 4 SELECT name FROM high_score WHERE grade = 'A'; 再帰クエリにも使われ、PostgreSQLやSQL Serverで強力。 |
| CASE式 | CASE式は、条件分岐で値を返します。 例： 1 SELECT name, 2 CASE 3 WHEN score >= 90 THEN 'A' 4 WHEN score >= 80 THEN 'B' 5 ELSE 'C' 6 END AS grade 7 FROM students; レポートでカテゴリ分けするのに最適。 |
| INSERT文 | INSERTで1行追加： 1 INSERT INTO students (id, name, age) 2 VALUES (101, '田中', 17); 複数行も可能： 1 INSERT INTO students VALUES (102, '鈴木', 18), (103, '佐々木', 16); 列を省略するとDEFAULTまたはNULLが入ります。 |
| UPDATE文 | UPDATEでデータ修正： 1 UPDATE students 2 SET age = 18 3 WHERE id = 101; 複数列も可： 1 UPDATE students 2 SET age = 18, name = '田中太郎' 3 WHERE id = 101; WHEREを忘れないように！ |
| DELETE文 | DELETEで行削除： 1 DELETE FROM students WHERE id = 101; 全削除は： DELETE FROM students; （※TRUNCATE TABLEの方が高速だが、ロールバック不可） |
| 参照関係を持つ表の更新 | 外部キーで参照されている行を更新・削除すると、参照整合性違反でエラーになります。 例： 1 -- ordersテーブルがcustomers.idを参照中 2 DELETE FROM customers WHERE id = 1; -- エラー！ これを防ぐため、参照動作を定義します。 |
| NO ACTION | NO ACTIONは、「親を削除・更新しようとしたとき、子が存在すればエラーにする」参照動作です。これがデフォルト。 例： 1 CREATE TABLE orders ( 2 customer_id INT, 3 FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE NO ACTION 4 ); 整合性を厳格に保ちたい場合に使います。 |
| RESTRICT | RESTRICTは、NO ACTIONとほぼ同じで、「操作を拒否する」動作です。SQL標準では違いがあるが、多くのDBMS（例：MySQL）では同義。 例： FOREIGN KEY (dept_id) REFERENCES departments(id) ON UPDATE RESTRICT 更新を禁止したいときに使います。 |
| CASCADE | CASCADEは、「親が削除・更新されたら、子も連動して削除・更新する」動作です。 例： 1 CREATE TABLE orders ( 2 customer_id INT, 3 FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE 4 ); 顧客を削除したら、その注文も全部消える。便利だが、誤操作に注意。 |
| SET DEFAULT | SET DEFAULTは、親が削除されたとき、子の外部キーを「DEFAULT値」に設定します。 例： 1 FOREIGN KEY (manager_id) REFERENCES employees(id) ON DELETE SET DEFAULT ただし、MySQLはサポートしておらず、PostgreSQLやSQL Serverで利用可能。 |
| SET NULL | SET NULLは、親が削除されたとき、子の外部キーをNULLにします。 例： 1 CREATE TABLE orders ( 2 customer_id INT, 3 FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE SET NULL 4 ); ただし、その列がNOT NULLだと使えません。柔軟な設計に役立ちます。 |
データ定義言語
| 単語 | 意味 |
|---|---|
| CREATE TABLE文 | CREATE TABLEでテーブル構造を定義します。 例： 1 CREATE TABLE students ( 2 id INT PRIMARY KEY, 3 name VARCHAR(50) NOT NULL, 4 age INT CHECK (age BETWEEN 0 AND 150), 5 email VARCHAR(100) UNIQUE 6 ); 主キー、NOT NULL、CHECK、UNIQUEなどの制約を同時に設定できます。 |
| 列制約 | 列制約は、列単位でデータのルールを定義します。 ・非NULL： NOT NULL・一意性： UNIQUE・検査： CHECK (score >= 0)・参照： REFERENCES other_table(id)（外部キー）・DEFAULT： DEFAULT '不明'これらを組み合わせて、データ品質を担保します。 |
| 表制約 | 表制約は、複数列にまたがるルールを定義します。主に「複合主キー」や「複合外部キー」に使います。 例： 1 CREATE TABLE enrollments ( 2 student_id INT, 3 course_id INT, 4 PRIMARY KEY (student_id, course_id), 5 FOREIGN KEY (student_id, course_id) REFERENCES schedule(student_id, course_id) 6 ); 列制約では表現できない関係を扱えます。 |
| SQLのデータ型 | 主なデータ型： ・文字型： CHAR(n)（固定長）、VARCHAR(n)（可変長）、TEXT（長文）・数値型： INT（整数）、DECIMAL(p,s)（固定小数点）、FLOAT（浮動小数点）・日付型： DATE, DATETIME, TIMESTAMP・ビット型： BOOLEAN（真偽値）、BIT(n)（ビット列）DBMSごとに細かい違いがあるので、公式ドキュメント要確認。 |
| 実表の定義例 | 部門表： 1 CREATE TABLE departments ( 2 dept_id CHAR(4) PRIMARY KEY, 3 dept_name VARCHAR(50) NOT NULL, 4 location VARCHAR(100) 5 ); 社員表： 1 CREATE TABLE employees ( 2 emp_id INT PRIMARY KEY, 3 name VARCHAR(50) NOT NULL, 4 dept_id CHAR(4), 5 salary DECIMAL(10,2), 6 FOREIGN KEY (dept_id) REFERENCES departments(dept_id) 7 ); 外部キーで関連付けられています。 |
| データベースのトリガ | トリガ（Trigger）は、「特定の操作（INSERT/UPDATE/DELETE）が起こったとき自動で実行されるプログラム」です。 例：社員が追加されたら、部門の人数を更新 ただし、過剰な使用はパフォーマンス低下やデバッグ困難の原因になるため、慎重に。 |
| ビューの定義 | ビューは、「仮想テーブル」で、実際のデータは持たず、SELECT文の結果を表のように見せます。CREATE VIEWで定義し、複雑なクエリをシンプルにしたり、セキュリティ（特定列のみ公開）に使えます。 |
| ビューとは | ビューは、実テーブルから派生した「見かけ上のテーブル」です。データは保存されず、参照時にクエリが実行されます。 例：「営業部の社員だけ見えるビュー」を作れば、他の部署の情報が隠せます。 |
| ビューの目的 | ビューの主な目的は3つ： ①複雑なクエリの簡略化 ②セキュリティ（列・行の制限） ③論理的なデータ独立性（実テーブル構造変更時にアプリ影響を軽減） ただし、更新可能なビューには制限があります。 |
| CREATE VIEW文 | 1 CREATE VIEW sales_staff AS 2 SELECT emp_id, name, salary 3 FROM employees 4 WHERE dept_id = 'SALE'; これで、 SELECT * FROM sales_staff; と簡単に出力可能。 |
| ビューの更新 | ビューは常に更新可能とは限りません。単純なSELECT（集計・DISTINCT・結合なし）ならUPDATE/INSERT/DELETE可能。複雑なビューは「INSTEAD OFトリガ」で更新ロジックを自作する必要があります。 |
| アクセス権限の付与 | 1 GRANT SELECT, INSERT ON employees TO hr_user; 2 GRANT ALL PRIVILEGES ON DATABASE company_db TO admin; 細かく権限をコントロールでき、セキュリティポリシーに従って設定します。 |
| アクセス権限の取消 | 1 REVOKE INSERT ON employees FROM hr_user; 2 REVOKE ALL PRIVILEGES ON DATABASE company_db FROM temp_user; 権限の見直しは、定期的に行うべきセキュリティ対策です。 |
埋込み方式
| 単語 | 意味 |
|---|---|
| 静的SQL | 静的SQLは、プログラムに直接埋め込まれたSQLで、実行前に構文が確定しています。 例（C言語埋込み）： 1 EXEC SQL SELECT name INTO :name_var FROM students WHERE id = :id_var; 高速で安全だが、柔軟性に欠けます。 |
| 動的SQL | 動的SQLは、実行時に文字列としてSQLを組み立てます。 例（Python）： 1 cursor.execute("SELECT * FROM students WHERE age > %s", (min_age,)) 柔軟ですが、SQLインジェクション対策（プレースホルダ使用）が必須。 |
| ホスト変数 | ホスト変数は、アプリケーションの変数とSQLをつなぐ橋渡しです。埋込みSQLで :var_name のように使います。SQL内で値を受け渡すのに不可欠で、型の一致に注意が必要です。 |
| カーソル処理 | カーソルで複数行をループ処理： 1 EXEC SQL DECLARE s_cur CURSOR FOR 2 SELECT id, name FROM students WHERE grade = 'A'; 3 EXEC SQL OPEN s_cur; 4 LOOP: 5 EXEC SQL FETCH s_cur INTO :id, :name; 6 IF (sqlcode == 100) GOTO DONE; -- 行なし 7 /* 処理 */ 8 GOTO LOOP; 9 DONE: 10 EXEC SQL CLOSE s_cur; バッチ処理でよく使われます。 |
| FETCHで取り出した行の更新 | カーソルで取得した行を直接更新するには、「更新可能カーソル」を使います。 例： 1 EXEC SQL DECLARE u_cur CURSOR FOR 2 SELECT name FROM students WHERE age < 18 3 FOR UPDATE OF name; 4 EXEC SQL OPEN u_cur; 5 EXEC SQL FETCH u_cur INTO :name; 6 EXEC SQL UPDATE students SET name = :new_name WHERE CURRENT OF u_cur; WHERE CURRENT OF で現在行を指定。ロックも自動でかかるため安全です。 |
データベース管理システム
| 単語 | 意味 |
|---|---|
| トランザクション | トランザクションとは、データベースに対する「ひとまとまりの処理」のことです。例えば、銀行で「AさんからBさんに1万円送金する」には「Aの残高を減らす」「Bの残高を増やす」という2つの操作が必要ですが、これらを1つのトランザクションとして扱います。途中で失敗したら、すべて元に戻す（ロールバック）仕組みがあります。これにより、データの信頼性が保たれます。 |
| ACID特性 | ACIDは、トランザクションが正しく動作するために必要な4つの性質の頭文字です：Atomicity（原子性）、Consistency（一貫性）、Isolation（隔離性）、Durability（耐久性）。これらがそろって初めて、データベースは信頼できる状態を維持できます。たとえば、ATMで引き出し中に停電しても、お金が二重に引き出されたり、引き出せなかったりしないようにするためのルールです。 |
| 原子性 | 原子性（Atomicity）とは、「トランザクション内の処理は、すべて成功するか、すべて失敗するかのどちらか」であるという性質です。途中で失敗したら、それまでに行った変更をすべて取り消します。たとえば、商品購入時に「在庫を減らす」「売上を加算する」の両方が完了しないと、取引は成立しません。この「全部 or 全部じゃない」が原子性です。 |
| 一貫性 | 一貫性（Consistency）とは、トランザクションの前後でデータベースが「正しい状態（制約を満たした状態）」を保つことです。たとえば、口座残高がマイナスになってはいけないというルールがある場合、トランザクションがそれを破らないようにします。これは、アプリケーションのロジックだけでなく、DBMSの整合性制約（例：NOT NULL、UNIQUE）によっても守られます。 |
| 隔離性 | 隔離性（Isolation）とは、複数のトランザクションが同時に実行されていても、「まるで1つずつ順番に実行されたかのように見える」性質です。たとえば、AとBが同じ口座から同時に引き出そうとしても、お互いの操作が干渉せず、正しい残高になるように制御されます。これを実現する仕組みが「同時実行制御」です。 |
| 耐久性 | 耐久性（Durability）とは、一度コミット（確定）されたトランザクションの結果は、その後どんな障害（停電・クラッシュなど）が起きても失われないという性質です。たとえば、注文が「完了しました」と表示された後でサーバーが落ちても、その注文はちゃんと保存されています。これは、ログファイルへの書き込み（WALプロトコル）などによって実現されます。 |
| 同時実行制御 | 同時実行制御（Concurrency Control）は、複数のトランザクションが同時に動いても、ACID特性（特に隔離性）を守るための仕組みです。並行性制御とも呼ばれます。たとえば、2人が同じ商品の最後の1個を買おうとしても、片方だけが成功し、もう片方は失敗するように調整します。主な方法には「ロック方式」と「MVCC（多版同時実行制御）」があります。 |
| ロック | ロックとは、あるトランザクションがデータを操作している間、他のトランザクションがそのデータにアクセスできないように「鍵をかける」仕組みです。たとえば、Aさんが商品の在庫を更新中なら、Bさんはその在庫を見たり変更したりできません。ロックには「共有ロック（読み取り用）」と「専有ロック（書き込み用）」があります。 |
| 変更消失 | 変更消失（Lost Update）とは、2つのトランザクションが同じデータを同時に更新し、片方の変更がもう片方に上書きされて消えてしまう現象です。例：AとBが同時に残高100円の口座に+50円すると、正しくは200円になるはずが、150円になってしまう。ロックやMVCCで防げます。 |
| 待ちグラフ | 待ちグラフ（Wait-for Graph）は、トランザクション同士の「待機関係」を表す有向グラフです。ノードがトランザクション、辺が「待っている」関係を示します。このグラフに「閉路（ループ）」があればデッドロックと判定され、DBMSはその中の1つをロールバックして解除します。リアルタイムで監視することで、システムが停止しないようにします。 |
| ロック方式 | ロック方式は「2相ロック（2PL）」が代表的です。これは「ロックを取得するフェーズ」と「ロックを解放するフェーズ」の2段階に分かれ、途中でロックの取得と解放を混ぜません。これにより、隔離性が保証されます。ただし、デッドロックのリスクがあるため、注意が必要です。 |
| 木規約 | 木規約（Tree Protocol）は、階層構造（例：ファイルシステム）のデータを効率的にロックする方式です。親ノードをロックしてから子ノードをロックするルールで、デッドロックを防ぎつつ、並行性を高めます。たとえば、フォルダAの中のファイルBを編集するには、まずAにロックをかけ、次にBにかけます。 |
| 専有ロック | 専有ロック（Exclusive Lock、占有ロックとも言う）は、「書き込み」を行うときに使うロックで、他のどのトランザクションもそのデータを読む・書くことができなくなります。例：商品在庫を更新中は、誰もその在庫情報を参照できません。排他的で安全ですが、並行性は下がります。 |
| 共有ロック | 共有ロック（Shared Lock）は、「読み取り」のときに使うロックで、複数のトランザクションが同時に同じデータを読むことができます。ただし、誰かが共有ロックをかけている間は、専有ロック（書き込み）はできません。これにより、「読込は並列可能、書込は排他」を実現します。 |
| ロックの粒度 | ロックの粒度（Granularity）とは、ロックの単位の大きさです。たとえば「テーブル全体」「1行」「1ページ」など。粒度が粗い（例：テーブルロック）とオーバーヘッドは小さいが並行性が低く、細かい（行ロック）と逆になります。DBMSは用途に応じて最適な粒度を選びます。 |
| 多版同時実行制御 | MVCC（Multi-Version Concurrency Control：多版同時実行制御）は、ロックを使わずに同時実行を実現する方式です。各データの「過去のバージョン」を保持し、トランザクションは自分に合ったバージョンを参照します。PostgreSQLやOracleが採用しており、読み取りと書き込みが衝突せず、高い並行性を実現します。 |
| その他の同時実行制御方式 | ロックやMVCC以外にも、「時刻印方式」「楽観的方式」があります。時刻印方式は各トランザクションにタイムスタンプを割り当て、順序を決めて処理します。楽観的方式は「衝突しないだろう」と仮定し、最後にチェックして問題があればやり直します。モバイルや分散環境で有効です。 |
| 時刻印方式 | 時刻印方式（Timestamp Ordering）は、各トランザクションにユニークなタイムスタンプを割り当て、その順序で処理を決定する方式です。古いトランザクションが新しいデータにアクセスしようとした場合、ロールバックされることがあります。時刻印アルゴリズムとも呼ばれ、リアルタイム性より一貫性を重視します。 |
| 楽観的方式 | 楽観的同時実行制御（Optimistic Concurrency Control）は、「通常は衝突しない」と仮定し、トランザクションをロックなしで実行し、コミット直前に衝突チェックを行います。もし衝突していればロールバックして再実行します。Webアプリやモバイルアプリでよく使われ、オーバーヘッドが少ないのが特徴です。 |
| 障害回復 | 障害回復（Recovery）とは、システム障害・トランザクション障害・媒体障害などが発生した後に、データベースを正しい状態に戻す仕組みです。ログファイルやバックアップを活用し、ACID特性の「耐久性」を保証します。2026年現在、クラウドDBでは自動リカバリが標準化されています。 |
| システム障害 | システム障害とは、OSクラッシュ・停電・メモリエラーなどにより、メモリ上のデータが失われるが、ディスク上のデータは無傷な状態です。この場合、ログファイルを使って「コミット済みのトランザクションは再適用（redo）」「未コミットのものは取消（undo）」することで復旧します。 |
| トランザクション障害 | トランザクション障害とは、プログラムエラーや制約違反などにより、特定のトランザクションが正常に終了できない状態です。この場合、そのトランザクションだけをロールバックし、他のトランザクションには影響を与えません。DBMSは自動でundo処理を行い、一貫性を保ちます。 |
| 媒体障害 | 媒体障害とは、ハードディスクの故障などにより、ディスク上のデータが物理的に破損する障害です。最も深刻で、ログやバックアップからの完全復旧が必要です。RAIDやクラウドストレージによる冗長化が、2026年では一般的な対策です。 |
| DBMSの仕組み | DBMS（Database Management System）は、データの格納・検索・更新・保護を一元管理するソフトウェアです。内部には「クエリプロセッサ」「トランザクションマネージャ」「ストレージエンジン」などがあり、これらが協調して動作します。代表的なものにMySQL、PostgreSQL、Oracleがあります。 |
| ログ（ログファイル） | ログファイルは、トランザクションの開始・更新内容・コミットなどの履歴を記録したファイルです。障害時に「何がどこまで完了していたか」を判断するのに不可欠です。2026年では、ログは圧縮・暗号化され、リアルタイムでリモートに同期されるのが主流です。 |
| WALプロトコル | WAL（Write-Ahead Logging）プロトコルは、「データをディスクに書き込む前に、必ずログを先に書き込む」というルールです。これにより、障害後でもログから復旧できます。PostgreSQLやSQLiteなど多くのDBMSが採用しており、耐久性の根幹を支えています。 |
| システム障害からの回復 | システム障害後、DBMSは起動時にログを読み込み、まず「未完了トランザクションをundo」し、次に「コミット済みだがディスクに反映されていないものをredo」します。このundo/redo方式により、データベースは常に一貫性のある状態に戻ります。 |
| undo/redo方式 | undo/redo方式は、ログを使って障害から復旧する手法です。undoは「未コミットの変更を取り消し」、redoは「コミット済みだがディスクに反映されていない変更を再適用」します。ログには「Before Image（変更前）」と「After Image（変更後）」の両方が記録されます。 |
| チェックポイントスタート | チェックポイント法は、復旧時間を短縮するため、定期的に「全トランザクションの状態を記録」する仕組みです。チェックポイント以降のログだけを処理すればよいため、大規模DBでも高速復旧が可能です。2026年では、インクリメンタルチェックポイントが主流です。 |
| トランザクション障害からの回復 | トランザクション障害時は、そのトランザクションに関連するログをたどり、undo処理で変更をすべて元に戻します。他のトランザクションには影響せず、一貫性が保たれます。アプリケーション側で再試行を促すこともありますが、DBMSが自動で処理するのが基本です。 |
| 媒体障害からの回復 | 媒体障害時は、最新のバックアップ（フル＋差分または増分）をリストアし、その後のログをredoして最新状態に復元します。RPO（許容データ損失量）とRTO（復旧目標時間）に基づき、バックアップ戦略を設計します。クラウドでは自動フェイルオーバーが標準です。 |
| フルバックアップ | フルバックアップは、データベース全体をまるごとコピーする方式です。復旧が簡単ですが、時間がかかり容量も大きいです。週1回など定期的に行い、他のバックアップ方式と組み合わせるのが一般的です。 |
| 差分バックアップ | 差分バックアップは、前回のフルバックアップ以降に変更されたデータだけを保存します。復旧時は「フル＋最新の差分」だけで済み、増分より簡単ですが、日が経つほどサイズが大きくなります。 |
| 増分バックアップ | 増分バックアップは、直前のバックアップ（フルまたは増分）以降の変更のみを保存します。容量効率は良いですが、復旧には「フル＋すべての増分」が必要で、手順が複雑です。頻繁なバックアップに向いています。 |
| データ復旧の要件 | RPO（Recovery Point Objective）は「許容できる最大データ損失量」、RTO（Recovery Time Objective）は「許容できる最大復旧時間」です。例：金融システムではRPO=0（1秒も損失不可）、RTO=5分など。これらに基づき、バックアップ頻度や冗長構成を設計します。 |
| 問合せ処理の効率化 | 大量データから素早く答えを得るには、問合せ（クエリ）の実行計画を最適化する必要があります。インデックスの利用、結合順序の最適化、不要な処理の削除などが行われます。これが「クエリオプティマイザ」の役割です。 |
| インデックス | インデックスは、データ検索を高速化するための「目次」のような構造です。本の索引と同じで、特定の値を探すのに全ページを読まずに済みます。ただし、更新時にはインデックスも更新されるため、書き込み性能は若干低下します。 |
| B＋木インデックス | B＋木（B＋ Tree）は、バランスの取れた木構造で、範囲検索や等価検索に強いインデックスです。リーフノードが連結リストになっており、MySQLやOracleのデフォルトインデックスとして広く使われています。2026年でも主力です。 |
| ビットマップインデックス | ビットマップインデックスは、各値に対して「どの行が該当するか」をビット列で表現します。例：性別が「男」なら 1010…。AND/OR演算で高速にフィルタリングでき、データウェアハウスで人気です。ただし、更新頻度が高いと非効率です。 |
| ハッシュインデックス | ハッシュインデックスは、キーをハッシュ関数で変換し、直接アドレスを計算してアクセスします。等価検索に極めて高速ですが、範囲検索には使えません。RedisやIn-Memory DBでよく使われます。 |
| 複合インデックス | 複合インデックス（連結インデックスとも言う）は、複数の列を組み合わせたインデックスです。例：(都道府県, 年齢)。WHERE句で両方を使うクエリが高速になります。ただし、列の順序が重要で、左から使われます（左接頭辞ルール）。 |
| オプティマイザ | オプティマイザは、SQLクエリを受け取り、最も効率的な実行計画を生成するDBMSの機能です。インデックスの有無、テーブルサイズ、統計情報などを基に、結合方法やアクセスパスを選びます。 |
| コストベースのオプティマイザとは？ | コストベースのオプティマイザ（CBO）は、各実行計画の「コスト（I/O、CPU時間など）」を推定し、最も安いものを選ぶ方式です。これに対し、古くは「ルールベース」（固定ルール）もありましたが、2026年ではCBOが標準です。 |
| データベースのチューニング | チューニングとは、性能を最大化するための調整作業です。インデックス追加、SQLの書き換え、メモリ割り当て変更、パーティショニングなどが含まれます。監視ツールでボトルネックを特定し、段階的に改善します。 |
| 複数ディスクへの分割 | I/O負荷を分散させるため、データファイルを複数のディスクに分けて配置します。これにより、並列読み書きが可能になり、スループットが向上します。SSD RAIDやクラウドのストレージプールが2026年では主流です。 |
| 表の分割 | 大きなテーブルを「パーティション（分割）」に分けることで、クエリ性能と管理性を向上させます。例：日付で分割し、1か月分だけをスキャン。範囲パーティショニング、リストパーティショニング、ハッシュパーティショニングがあります。 |
| データベースの再編成 | 長期間使用すると、データの断片化や不要なスペースが蓄積されます。再編成（Reorganization）で、データを整理し、パフォーマンスを回復します。オンライン再編成機能を持つDBMSも増え、稼働中でも実施可能です。 |
分散データベース
| 単語 | 意味 |
|---|---|
| 分散データベースシステムの機能 | 分散データベースは、複数のサーバー（サイト）にデータを分散配置し、1つのDBのように扱えるシステムです。各地域のユーザーが近くのサーバーにアクセスでき、可用性・拡張性が高いのが特徴です。2026年では、グローバル企業の標準アーキテクチャです。 |
| 6つの透過性 | 分散DBが使いやすいのは、「透過性（Transparency）」があるからです。具体的には：①位置、②複製、③移動、④障害、⑤性能、⑥並行 の6種類。ユーザーは「裏で分散していること」を意識せずに操作できます。 |
| 透過性の実現 | これらの透過性は、分散DBMSの内部で「クエリ変換」「レプリカ選択」「障害検出」「負荷分散」などの機能が自動で働くことで実現されます。ユーザーは単一DBと同じSQLで操作でき、システムが裏で最適化します。 |
| 集中管理方式 | 集中管理方式では、1つのサイトがデータディクショナリや制御機能を一手に担います。シンプルですが、そのサイトが障害点（SPOF）になりやすく、2026年ではあまり使われていません。 |
| 分散管理方式 | 分散管理方式では、制御機能も複数サイトに分散されます。耐障害性が高く、スケーラブルですが、実装は複雑です。Google SpannerやCockroachDBがこの方式を採用しています。 |
| 異なるサイト間での表結合 | 分散DBでJOINを行うと、ネットワーク越しにデータを転送する必要があり、コストがかかります。そのため、「セミジョイン」など通信量を減らす特殊なアルゴリズムが使われます。 |
| セミジョイン法 | セミジョインは、結合に必要なキーだけを送って、不要なレコードを事前に除外する手法です。例：Aサイトの顧客IDだけをBサイトに送り、該当する注文だけを返してもらう。通信量を大幅に削減できます。 |
| ハッシュセミジョイン法 | ハッシュセミジョインは、セミジョインの一種で、ハッシュ関数を使ってキーを分類し、必要なデータだけを転送します。大規模データでは効率的で、MapReduce系処理と相性が良いです。 |
| 入れ子ループ法 | 入れ子ループ結合（Nested Loop Join）は、一方のテーブルの各行に対して、もう一方を全走査する単純な方法です。小規模データ向きで、分散環境では通信コストが高くなるため避けられます。 |
| マージジョイン法 | マージジョイン（ソートマージ結合）は、両テーブルを結合キーでソートし、順番にマッチさせる方法です。ソート済みなら非常に高速ですが、分散環境ではソート自体にコストがかかります。 |
| ハッシュ結合 | ハッシュ結合は、一方のテーブルをハッシュテーブルに載せ、もう一方をスキャンして結合します。メモリに収まるなら高速ですが、分散環境ではハッシュのシャーディングが鍵になります。 |
| アクセス透過性 | アクセス透過性とは、ユーザーがローカルDBと同じSQLやAPIで分散DBにアクセスできることです。裏でネットワーク通信や変換が行われても、ユーザーには見えません。 |
| 障害透過性 | 障害透過性（障害透明性とも言う）は、一部のサイトがダウンしても、他のサイトで処理を継続できることです。レプリケーションと自動フェイルオーバーで実現されます。 |
| 複製透過性 | 複製透過性（重複透過性とも言う）は、同じデータが複数のサイトにコピー（レプリカ）されていても、ユーザーは1つのように扱える性質です。更新時は全レプリカを同期します。 |
| 規模透過性 | 規模透過性は、システムに新しいサイトを追加しても、アプリケーションを変更せずに使えることです。スケーラビリティの要です。 |
| 移動透過性 | 移動透過性は、データや処理を別のサイトに移動しても、アプリケーションが影響を受けないことです。負荷分散やメンテナンス時に活用されます。 |
| 位置透過性 | 位置透過性は、データがどのサイトに物理的に存在するかをユーザーが知る必要がないことです。クエリは論理名で指定し、DBMSが実際の場所を解決します。 |
| 性能透過性 | 性能透過性は、分散構成でも、単一DBと同等の応答性能を維持することを目指す性質です。負荷分散やキャッシングで実現されます。 |
| 並行透過性 | 並行透過性は、複数のトランザクションが異なるサイトで同時に実行されても、一貫性が保たれることです。2相コミットなどで実現されます。 |
| 分散データベースの更新同期 | 複数のレプリカを更新する際、すべてを同時に更新するのは難しく、遅延が生じます。そのため、「強整合性」か「結果整合性（Eventual Consistency）」のどちらを取るかが設計の鍵です。 |
| レプリケーション | レプリケーションは、同じデータを複数のサイトにコピーしておく仕組みです。可用性と読み取り性能を向上させますが、更新時の同期が課題です。同期型と非同期型があります。 |
| 2相コミットメント制御 | 2PC（2相コミット）は、分散トランザクションを安全にコミットするプロトコルです。 ・第1フェーズ（準備）：コーディネータが全参加者に「コミットできるか？」を問い合わせ、全員がOKなら次へ。 ・第2フェーズ（決定）：全員に「コミットせよ」と指 示。1人でもNGなら全員にロールバックを指示します。 ただし、コーディネータ障害時にブロックする弱点があります。 |
| 3相コミットメント制御 | 3PC（3相コミット）は、2PCの弱点を改善したプロトコルで、第2フェーズの間に「プリコミット」状態を追加します。これにより、コーディネータ障害時でも参加者が自律的に判断できますが、実装が複雑で、2026年でも2PCが主流です。 |
データベース応用
| 単語 | 意味 |
|---|---|
| データウェアハウス | データウェアハウス（DWH）は、分析用に設計された大規模データベースです。業務DB（OLTP）とは異なり、大量の履歴データを格納し、複雑な集計クエリを高速に処理します。ETL（抽出・変換・読み込み）でデータを統合します。 |
| 多次元データベース | 多次元データベースは、データを「立方体（キューブ）」として扱い、時間・地域・商品カテゴリなどの次元で分析します。スライスやダイスといった操作で、自由に視点を変えられます。 |
| OLAP | OLAP（Online Analytical Processing：オンライン分析処理）は、多次元データをインタラクティブに分析する技術です。 ・スライス：1つの次元を固定して切り出す（例：2025年のデータだけ見る）。 ・ダイス：複数の次元を範囲指定して切り出す（例：2025年×東京×家電）。 ・ロールアップ：詳細から集計へ（例：日次 → 月次）。 ・リルダウン：集計から詳細へ（例：全国 → 都道府県）。 これにより、経営判断を迅速に支援します。 |
| MOLAP | MOLAP（Multidimensional OLAP）は、データを多次元キューブ形式で事前集計して格納する方式です。クエリは極めて高速ですが、データ更新に時間がかかり、柔軟性に欠けます。 |
| ROLAP | ROLAP（Relational OLAP）は、通常のリレーショナルDB上でOLAPを実現する方式です。柔軟性が高く、大規模データ向きですが、MOLAPより速度は劣ります。SnowflakeやBigQueryがROLAP寄りです。 |
| スタースキーマ | スタースキーマは、DWHでよく使われるテーブル設計で、中央に「ファクトテーブル」、周囲に「ディメンションテーブル」が放射状に配置されます。シンプルで高速な集計が可能です。 |
| ファクトテーブル | ファクトテーブルは、数量・金額などの「測定値（メジャー）」と、ディメンションへの外部キーを持つテーブルです。例：売上金額、販売日、店舗ID、商品IDなど。 |
| ディメンションテーブル | ディメンションテーブルは、分析の軸（次元）を提供するテーブルです。例：商品マスタ（商品名、カテゴリ）、店舗マスタ（住所、地域）など。属性情報が多く、更新頻度は低いです。 |
| データマイニング | データマイニングは、大量データから隠れたパターンやルールを発見する技術です。マーケティング、不正検出、医療診断などに応用され、AIと密接に関係しています。 |
| マーケットバスケット分析 | マーケットバスケット分析は、「一緒に買われる商品の組み合わせ」を発見する手法です。例：「ビールとおむつ」。アソシエーションルール（支持度・信頼度）で評価します。 |
| 決定木分析 | 決定木分析（デシジョンツリー、意思決定ツリーとも言う）は、条件分岐の木構造で分類・予測を行う手法です。例：「年齢>30 かつ 所得>500万 → 購入あり」。解釈が簡単で、ビジネスに使いやすいです。 |
| ニューラルネットワーク | ニューラルネットワークは、人間の脳を模した機械学習モデルで、大量のデータから複雑なパターンを学習します。画像認識や自然言語処理で威力を発揮し、データマイニングの高度化に貢献しています。 |
| クラスタ分析 | クラスタ分析は、似たデータをグループ（クラスタ）に分ける手法です。例：顧客を「高所得・若年層」「低所得・高齢層」などに分類。マーケティングセグメンテーションに活用されます。 |
| CEP | CEP（Complex Event Processing）は、リアルタイムでイベントストリームを分析し、パターンを検出する技術です。例：不正取引の即時検出、IoTセンサーの異常検知。Apache Flinkなどが代表的です。 |
| NoSQL | NoSQLは、「関係モデルにとらわれない」データベースの総称です。スケーラビリティと柔軟性を重視し、SNS、IoT、リアルタイムアプリで使われます。ACIDよりBASEを重視します。 |
| NoSQLデータベース | NoSQL DBは、キーバリュー、ドキュメント、カラム、グラフの4タイプに大別されます。それぞれ用途に特化しており、2026年ではハイブリッドDB（例：MongoDB + SQL）も登場しています。 |
| キーバリューDB | キーバリューDB（キーバリューストア、KVSとも言う）は、キーで値を高速に取得するシンプルなDBです。例：Redis、DynamoDB。キャッシュやセッション管理に最適です。 |
| カラム指向DB | カラム指向DBは、列単位でデータを格納し、集計クエリに強い構造です。例：Apache Cassandra、Bigtable。大量のセンサーデータやログ分析に使われます。 |
| ドキュメント指向DB | ドキュメント指向DB（例：MongoDB）は、JSONのような階層データをそのまま格納できます。スキーマレスで開発が速く、Webアプリに最適です。 |
| グラフ指向DB | グラフDB（例：Neo4j）は、ノードとエッジで関係性を表現し、「友達の友達」のような複雑な関連検索に強いです。SNSや詐欺検出で活躍します。 |
| BASE特性 | BASEは、Basically Available（常に利用可能）、Soft state（状態が変わる可能性あり）、Eventually consistent（結果整合性）の略です。結果整合性とは、「すぐには一致しないが、時間が経てば最終的に一致する」という考え方で、NoSQLの哲学です。 |
| データレイク | データレイクは、構造化・非構造化データをそのまま大量に貯める「湖」です。DWHが「洗練された水」なら、データレイクは「原水」。AI分析の原料として2026年も重要です。 |
| オープンデータ | オープンデータは、誰でも自由に利用・加工・再配布できる公共データです。政府や自治体が公開し、イノベーション創出に貢献しています。2026年、日本でもマイナンバー連携データが拡充中です。 |
| データサイエンティスト | データサイエンティストは、データから価値を生み出す専門家です。求められる能力は3つ。 ・ビジネス力：課題を理解し、データで解決策を提案。 ・データサイエンス力：統計・機械学習でモデル構築。 ・データエンジニアリング力：データ収集・加工・可視化の実装。 この「3つの脚」が揃って初めて、現場で成果を出せます。 |
ブロックチェーン
| 単語 | 意味 |
|---|---|
| ブロックチェーン | ブロックチェーンは、取引履歴を「ブロック」として鎖のようにつなぎ、改ざん不能にする分散台帳技術です。ビットコインの基盤ですが、今や金融・物流・医療など幅広く応用されています。 |
| 分散型台帳技術 | 分散型台帳技術（DLT）は、中央管理者なしに、複数の参加者が同じ台帳を共有・管理する仕組みです。ブロックチェーンはその一種で、他にDAG（Directed Acyclic Graph）方式もあります。 |
| P2Pネットワーク | P2P（Peer-to-Peer）ネットワークは、各ノードが対等に通信し合うネットワークで、ブロックチェーンの基盤です。中央サーバーが不要で、耐障害性と拡張性に優れます。 |
| CAP定理 | CAP定理は、「分散システムは、一貫性（Consistency）、可用性（Availability）、分断耐性（Partition tolerance）のうち、最大2つしか同時に満たせない」という理論です。ブロックチェーンはCP（一貫性＋分断耐性）を重視します。 |
| 仮想通貨マイニング | マイニングは、新しいブロックを生成し、報酬（新規コイン＋手数料）を得る作業です。膨大な計算（プルーフ・オブ・ワーク）で競い合い、ネットワークのセキュリティを担保します。2026年、環境負荷低減のためPoS（プルーフ・オブ・ステーク）が主流になりつつあります。 |
みんなで使おう！Ankiアプリで暗記しよう
Ankiアプリの記事と、現時点までに作成されたAnkiアプリのデータへのリンクを掲載しております。どうぞご利用ください。
本日分までのAnkiアプリデータはこちら。
firestorageダウンロード
firestorage.com
パスワードは「shirakawa」です。お間違えのないように。
参考図書
応用情報技術者の資格勉強をするにあたり、科目A対策として以下の教科書を使用しています。できれば、こちらもAnkiアプリと併用しながらご利用いただければと思います。暗記した内容とのつながりが理解できるようになるのでオススメですよ。
ポチップ
合わせて読みたい
最後に
いかがでしたでしょうか？
1章につき2日で予定を組み直したのですが、第6章のデータベースは分量が多くて大変でした。
正直、ここまで暗記データを入力してきて、（ここまでの知識が必要か？）とも思っています。しかし、「応用情報技術者を取った」という人にはある程度の責任が伴うと思うのです。つまり、それは「知識」です。資格を取るだけなら、過去問道場の過去問を解いていれば科目Aは受かることでしょう。でも、科目Bを視野に入れるとそうはいきません。そういう前提で、私は、この暗記にこだわってみています。
作成したAnki用データをAnkiアプリを使って活用していただければと思います。
先日修正したAnkiデータは、すべての章に反映させております。
まだまだ応用情報技術者の勉強は始まったばかりです。皆さん一緒に頑張りましょう！
白川秋
ではでは、参考までに
コメント