データベースシステムの基礎理論と実践

データベース技術は、情報の分類、組織化、符号化、保存、検索、保守といったデータ管理の側面を扱う、現代の情報システムの中核をなす要素です。本稿では、データ管理システムの進化から始まり、さまざまなデータモデル、SQLの基本、クエリ処理と最適化、そしてデータベースのセキュリティ、回復、並行処理、設計理論、最新技術に至るまで、データベースシステムの広範な知識を網羅します。

データ管理システムの進化

データ管理の歴史は、その時代における技術と要件に応じて進化してきました。主な段階は以下の通りです。

  • 1940年代～1950年代初頭: 手動管理システム

    データは通常、紙媒体で管理され、特定のソフトウェアによる統一的な管理は行われませんでした。アプリケーションはデータに強く依存し、データの共有は限定的でした。

  • 1950年代後半～1960年代中盤: ファイルシステム

    磁気ディスクや磁気ドラムといったハードウェアの登場により、データの永続的な保存が可能になりました。しかし、データはアプリケーションごとに管理され、データの重複が多く、統合的な制御が困難でした。

  • 1960年代後半以降: データベースシステム

    大容量ストレージとデータベース管理システム（DBMS）の登場により、データ管理は大きく変革しました。この時代には、IBMによるIMS（1968年）、DBTGによるネットワークデータモデル報告書（1969年）、E.F.コッドによるリレーショナルモデルの提案（1970年）など、画期的な進展がありました。

    データベースシステムは以下の主要な特徴を持ちます。

    • 構造化されたデータ: データが組織的かつ関連性を持って格納されます。
    • 高いデータ独立性: 物理データ独立性（物理ストレージの変更がアプリケーションに影響しない）と論理データ独立性（論理スキーマの変更がアプリケーションに影響しない）が実現されます。
    • データ冗長性の削減: データを一元的に管理することで、重複を最小限に抑えます。
    • データ共有: 複数のユーザーやアプリケーションがデータを同時に利用できます。
    • 統合されたデータ保護: セキュリティ、整合性、並行性制御、回復機能が提供されます。

データベースとDBMS

データベース（DB）は、コンピュータシステム内に永続的に保存され、構造化され、共有可能な大量のデータ集合です。データ間の関連性に基づいて組織化され、高いデータ独立性、少ない冗長性、そして複数のユーザーによる共有が可能です。

データベース管理システム（DBMS）は、ユーザーとオペレーティングシステムの中間に位置し、データベースを一元的に管理・保守するソフトウェアシステムです。データ定義、データ操作、実行管理、保守などの機能を提供し、データベースシステムの中核を担います。

DBMSの主要機能

  • データ定義機能: スキーマ、外部スキーマ、内部スキーマの定義を可能にするデータ定義言語（DDL）を提供します。
  • データ操作機能: データの検索、挿入、更新、削除を可能にするデータ操作言語（DML）を提供します。
  • データ保護機能: セキュリティ、整合性、並行性制御、回復といった機能を通じてデータを保護します。
  • 保守機能: ダンプ、データロード、統計収集、ストレージ管理など、データベースの運用をサポートします。

データモデル

データモデルは、現実世界の情報を抽象化し、形式的に表現するための枠組みです。主に以下の3つの要素で構成されます。

  • データ構造: データベース内のオブジェクトとその関係を記述する静的な特性です。
  • データ操作: データベースオブジェクトのインスタンスに対して許可される操作（クエリ、更新など）を記述する動的な特性です。
  • データ整合性制約: データの正確性、有効性、一貫性を保証するための規則です。

データモデルは、ユーザー視点の「概念データモデル」と、コンピュータシステム視点の「論理データモデル」および「物理データモデル」に分けられます。

データベースシステムアーキテクチャ

データベースシステムは、ユーザーがデータ管理の詳細を意識せずに抽象的にデータを扱えるよう、多階層構造を採用しています。この「3層スキーマアーキテクチャ」は、データのアクセス効率と物理ストレージへの最適な配置を両立させます。

  • 概念スキーマ（論理スキーマ）: データベース全体の論理構造と特性を記述します。データベース全体に対する単一の定義です。
  • 外部スキーマ（サブスキーマ、ユーザービュー）: 特定のユーザーやアプリケーションから見たデータの論理構造です。概念スキーマの部分集合であり、一つのデータベースに複数の外部スキーマが存在できます。セキュリティ対策としても機能し、ユーザーは許可されたデータのみにアクセス可能です。
  • 内部スキーマ（ストレージスキーマ）: データの物理構造と保存方法を記述します。一つのデータベースに一つのみ存在します。

これら3つのスキーマ間には「2段階のマッピング」が存在し、データ独立性を実現します。

  • 外部スキーマ・概念スキーマ間のマッピング: 外部スキーマと概念スキーマ間の対応関係を定義します。概念スキーマが変更されても、このマッピングを調整するだけで外部スキーマ（およびアプリケーション）は変更不要となり、論理データ独立性が保たれます。
  • 概念スキーマ・内部スキーマ間のマッピング: 概念スキーマと物理データストレージ間の対応関係を定義します。物理ストレージ構造が変更されても、このマッピングを調整するだけで概念スキーマは変更不要となり、物理データ独立性が保たれます。

データベースシステムの主要な役割

データベースシステムの開発と運用には、複数の役割を持つ専門家が関与します。

  • データベース管理者（DBA）: データベースの物理構造と戦略を決定し、システムの全体的な健全性とパフォーマンスを維持します。
  • システムアナリスト: ユーザーの要件を分析し、システム全体の設計を支援します。
  • アプリケーションプログラマ: データベースを利用するアプリケーションを開発します。
  • エンドユーザー: 開発されたシステムを利用してデータにアクセスします。

データモデルの種類

データモデルには、概念的な視点と物理的な視点から様々な種類があります。ここでは、E-R概念モデルを中心に、いくつかの論理データモデルについて概説します。

E-R（エンティティ・リレーションシップ）概念モデル

E-Rモデルは、現実世界の情報をユーザーが理解しやすい形で表現するための強力なツールです。主要な構成要素は以下の通りです。

  • エンティティ（実体）: 現実世界に存在し、他のものと区別できる事物や概念（例: 学生、書籍、授業）。長方形で表現されます。
  • 属性: エンティティが持つ特定の特性（例: 学生の名前、年齢）。楕円形で表現されます。
  • リレーションシップ（関連）: エンティティ間またはエンティティ内部のつながり。ひし形で表現されます。

リレーションシップの型

  • 1対1 (1:1): エンティティAの1つのインスタンスが、エンティティBの最大1つのインスタンスに対応します。
  • 1対多 (1:N): エンティティAの1つのインスタンスが、エンティティBの複数のインスタンスに対応します。
  • 多対多 (M:N): エンティティAの複数のインスタンスが、エンティティBの複数のインスタンスに対応します。

さらに、3つ以上のエンティティが関わる「多元リレーションシップ」も存在します。例えば、「プロジェクト」、「部品」、「サプライヤー」の間の「供給」リレーションシップは、どのサプライヤーがどのプロジェクトにどの部品を供給したかを詳細に記述できます。

階層モデル

データベースシステムで初期に登場したモデルで、データがツリー構造で表現されます。以下の条件を満たします。

  • ルートノードが1つだけ存在し、親ノードを持ちません。
  • ルートノード以外のすべてのノードは、必ず1つの親ノードを持ちます。

階層モデルは構造が単純で理解しやすく、検索効率が高いという利点がありますが、複雑な多対多のリレーションシップを直接表現するのが困難で、データの挿入や削除の操作が複雑になることがあります。

ネットワークモデル

階層モデルの制約を緩和し、より複雑な現実世界のリレーションシップを表現できるようにしたモデルです。以下の条件を満たします。

  • 複数のノードが親ノードを持たないことが許されます。
  • 1つのノードが複数の親ノードを持つことができます。

現実世界をより直感的に記述できる反面、構造が複雑になり、DDLやDMLの習得が難しいという課題があります。

リレーショナルモデル

1970年にE.F.コッドが提案し、1980年代以降、データベースの主流となりました。データは「関係（リレーション）」と呼ばれる二次元の表形式で表現されます。

  • 関係: 一つの表が、一つのエンティティ集合を記述します。
  • 属性: 表の列がエンティティの特性（属性）に対応します。
  • タプル: 表の行が、エンティティ集合における個々のインスタンスに対応します。
  • ドメイン: 属性が取りうる値の集合です。
  • キー: 1つ以上の属性から構成され、表内のタプルを一意に識別します。複数の候補キーの中から一つが主キーとして選択されます。

リレーショナルスキーマと整合性制約

関係の構造を記述するものを「リレーショナルスキーマ」と呼びます。例えば、Students(student_id, student_name, department)のように表現されます。

リレーショナルモデルでは、データの正確性と整合性を保証するために以下の「整合性制約」が重要です。

  • エンティティ整合性: 主キーのどの属性もNULL（未定義）であってはなりません。
  • 参照整合性: ある関係の外部キーの値は、参照される関係の主キーの値として存在するか、またはNULLである必要があります。
  • ユーザー定義整合性: アプリケーション固有のルール（例: スコアは0から100の範囲）を定義できます。

リレーショナルモデルはデータ構造が単純で、集合指向のデータ操作が可能であり、高いデータ独立性を提供します。また、強力な理論的基盤を持っているため、様々な応用に有利です。

オブジェクト指向データモデル

オブジェクト指向プログラミングの概念をデータベースに導入しようとする試みです。オブジェクト指向データモデルとリレーショナルデータモデルを組み合わせた「オブジェクトリレーショナルデータベースシステム」も存在します。しかし、一般的なデータモデルや理論的基盤の不足、クエリ最適化の難しさなどから、リレーショナルデータベースが依然として主流を占めています。

リレーショナルデータベースの詳細

関係モデルの基本概念

リレーショナルデータベースの中心にあるのは、数学的な「関係」の概念です。

  • ドメイン: 同一のデータ型を持つ値の集合です。例えば、学生IDのドメインは「6桁の文字型」などです。
  • デカルト積: 複数のドメインから要素を1つずつ選び出して作られる全ての順序組の集合です。その各要素を「タプル」と呼びます。
  • 関係（リレーション）: デカルト積の任意のサブセットであり、有限個のタプルからなる、正規化された二次元の表として扱われます。各列を「属性」と呼び、特定のドメインからの値を取ります。

正規化された関係の特性

  • 各列（属性）は同質であり、同一ドメインからの値を含みます。
  • 異なる列が同じドメインから来ていても問題ありませんが、異なる属性名を持ちます。
  • 列の順序は重要ではありません。
  • 各タプルは一意であり、重複するタプルは存在しません。
  • 行の順序は任意です。
  • 各要素（分量）はアトミック値（不可分なデータ項目）でなければなりません。

キーの種類

タプルを一意に識別する1つ以上の属性の集合を「キー」と呼びます。候補キーが複数ある場合、そのうちの1つを「主キー」として選択します。複数の属性で構成されるキーは「複合キー」と呼ばれます。

関係代数

関係代数は、関係を演算対象とし、関係を結果として返す抽象的なクエリ言語です。以下の演算子に分類されます。

伝統的な集合演算

対象となる関係RとSは、同じ属性構成（同次性）を持つ必要があります。

  • 和 ($\text{R} \cup \text{S}$): RまたはSに存在するすべてのタプルからなる関係。
  • 差 ($\text{R} - \text{S}$): Rに存在し、Sには存在しないすべてのタプルからなる関係。
  • 積 ($\text{R} \cap \text{S}$): RとSの両方に存在するすべてのタプルからなる関係。
  • デカルト積 ($\text{R} \times \text{S}$): Rの各タプルとSの各タプルのすべての組み合わせからなる関係。

専門の関係演算

これらの演算は、関係データベース特有のものです。

  • 選択 ($\sigma_{\text{F}}(\text{R})$): 関係Rの中から、条件Fを満たすタプル（行）を抽出します。
  • 射影 ($\Pi_{\text{A}}(\text{R})$): 関係Rの中から、指定された属性Aの列のみを抽出し、新しい関係を形成します。重複行は自動的に削除されます。
  • 結合 ($\text{R} \Join_{\text{F}} \text{S}$): 2つの関係RとSを、条件Fに基づいて結合します。
    • 条件結合: デカルト積に選択条件を適用したものと同等です。
    • 等値結合: 条件Fが等号演算子である結合です。
    • 自然結合: 共通の属性に対して等値結合を行い、重複する共通属性列を1つだけ残します。
  • 除算 ($\text{R} \div \text{S}$): ある関係Rの属性Xのタプルが、他の関係Sのすべてのタプルに関連付けられている場合、そのXの値を返します。

例: Students(student_id, student_name, dept_name)、Grades(student_id, course_id, score)、Courses(course_id, course_title, credits)

  1. 「コンピュータ科学」学部の学生の学生IDと名前を検索:
    $\Pi_{\text{student\_id, student\_name}}(\sigma_{\text{dept\_name='コンピュータ科学'}}(\text{Students}))$
  2. 学生ID「ST001」が履修しているコースのタイトルを検索:
    $\Pi_{\text{course\_title}}(\sigma_{\text{Students.student\_id=Grades.student\_id AND Grades.course\_id=Courses.course\_id AND Students.student\_id='ST001'}}(\text{Students} \times \text{Grades} \times \text{Courses}))$
    これは自然結合を使ってより簡潔に表現できます:
    $\Pi_{\text{course\_title}}(\sigma_{\text{student\_id='ST001'}}(\text{Students} \Join \text{Grades} \Join \text{Courses}))$

拡張関係演算

  • 属性名の変更 ($\delta_{\text{old\_name} \to \text{new\_name}}(\text{R})$): 関係の属性名を変更します。
  • 外部結合 (Outer Join): 自然結合の拡張で、結合条件を満たさないタプルも結果に含め、対応する属性にはNULLを挿入します。左外部結合、右外部結合、全外部結合があります。

タプル関係演算とドメイン関係演算

関係代数が手続き的なクエリ言語であるのに対し、関係演算は述語論理に基づいてクエリ要件を記述する非手続き的な言語です。

  • タプル関係演算: タプル変数を使用し、クエリ対象となるタプルとその属性を指定し、条件式でタプルの属性値を制約します。
  • ドメイン関係演算: ドメイン変数を使用し、クエリ対象となるドメインの値を指定し、条件式でこれらの値間の関係を制約します。

これらの言語は表現能力において等価であり、SQLの基盤となっています。

リレーショナルデータベース標準言語SQL

SQL (Structured Query Language) は、データ定義、クエリ、操作、制御の機能が統合された、リレーショナルデータベースの標準言語です。非手続き的であり、集合指向の操作を特徴とします。

SQLのデータ定義

SQLは、データベーススキーマ、テーブル、ビュー、インデックスなどのオブジェクトを定義・管理するためのDDL機能を提供します。

スキーマの定義と削除

スキーマは、データベースオブジェクトの命名空間として機能します。

CREATE SCHEMA university_db AUTHORIZATION admin_user;
DROP SCHEMA university_db CASCADE; -- 関連するすべてのオブジェクトも削除

基本テーブルの定義

CREATE TABLE Students (
    student_id  CHAR(8)      NOT NULL PRIMARY KEY, -- 列レベル制約: 主キー
    full_name   VARCHAR(50)  NOT NULL,
    birth_year  INT,
    department  VARCHAR(30)  DEFAULT '未定',
    gender      CHAR(1)      CHECK (gender IN ('M', 'F')), -- 列レベル制約
    CONSTRAINT CHK_Age CHECK ( (2023 - birth_year) >= 18 ) -- テーブルレベル制約
);

CREATE TABLE Courses (
    course_id   CHAR(6)      NOT NULL PRIMARY KEY,
    course_title VARCHAR(100) NOT NULL UNIQUE,
    credits     INT          CHECK (credits > 0)
);

CREATE TABLE Enrollments (
    student_id  CHAR(8)      NOT NULL,
    course_id   CHAR(6)      NOT NULL,
    score       INT          CHECK (score BETWEEN 0 AND 100),
    PRIMARY KEY (student_id, course_id), -- 複合主キー
    FOREIGN KEY (student_id) REFERENCES Students(student_id) ON DELETE CASCADE,
    FOREIGN KEY (course_id)  REFERENCES Courses(course_id) ON DELETE RESTRICT
);
  • PRIMARY KEY: 主キー制約
  • UNIQUE: 一意性制約
  • NOT NULL: 非NULL制約
  • FOREIGN KEY ... REFERENCES ...: 参照整合性制約
  • CHECK: 値の範囲や条件を制約

基本テーブルの変更と削除

ALTER TABLE Students ADD email VARCHAR(100); -- 新しい列はデフォルトでNULL可
ALTER TABLE Students ALTER COLUMN full_name VARCHAR(60); -- 列のデータ型を変更
ALTER TABLE Students DROP COLUMN birth_year; -- 列を削除
DROP TABLE Enrollments; -- テーブルを削除

インデックスの作成と削除

インデックスは、データの検索速度を向上させるためのデータ構造です。

CREATE UNIQUE INDEX idx_student_name ON Students (full_name);
CREATE INDEX idx_enrollment_score ON Enrollments (score DESC);
DROP INDEX idx_student_name ON Students;

SQLの単一テーブルクエリ

データの検索はSELECT文で行われます。基本的な構文は以下の通りです。

SELECT [DISTINCT | ALL] カラムまたは式 [, カラムまたは式 ...]
FROM   テーブル名またはビュー名
[WHERE  条件式]
[GROUP BY グループ化カラム [HAVING グループ条件式]]
[ORDER BY ソートカラム [ASC | DESC] [, ソートカラム [ASC | DESC]] ...];

カラムの選択

  • 特定のカラム: SELECT student_id, full_name FROM Students;
  • すべてのカラム: SELECT * FROM Students;
  • 計算されたカラム: SELECT full_name, (2023 - birth_year) AS age FROM Students;
  • 重複の排除: SELECT DISTINCT department FROM Students;

条件付き検索 (WHERE句)

  • 比較演算子: =, >, <, >=, <=, <>, !=
  • 範囲指定: BETWEEN ... AND ..., NOT BETWEEN ... AND ...
  • 集合指定: IN (...), NOT IN (...)
  • 文字列パターンマッチ: LIKE 'パターン', NOT LIKE 'パターン' (%は任意文字列、_は任意一文字)
  • NULL値: IS NULL, IS NOT NULL
  • 複合条件: AND, OR, NOT

例:

-- コンピュータ科学部の2000年以降生まれの学生名
SELECT full_name FROM Students
WHERE department = 'コンピュータ科学' AND birth_year >= 2000;

-- 氏名が「山田」で始まる学生IDと名前
SELECT student_id, full_name FROM Students
WHERE full_name LIKE '山田%';

結果のソート (ORDER BY句)

-- 成績が降順で、同じ成績の場合は学生ID昇順で表示
SELECT student_id, course_id, score FROM Enrollments
ORDER BY score DESC, student_id ASC;

集約関数

  • COUNT(*): タプルの総数をカウント
  • COUNT(DISTINCT カラム名): カラムの一意な値の数をカウント
  • SUM(カラム名): カラムの合計値を計算
  • AVG(カラム名): カラムの平均値を計算
  • MAX(カラム名): カラムの最大値を検索
  • MIN(カラム名): カラムの最小値を検索
-- 総学生数
SELECT COUNT(*) FROM Students;

-- 平均スコアが80点以上のコースIDと平均スコア
SELECT course_id, AVG(score) FROM Enrollments
GROUP BY course_id
HAVING AVG(score) >= 80;

GROUP BY句は集約関数の適用範囲をグループごとに指定し、HAVING句はグループに対する条件を指定します。

SQLの結合クエリ

複数のテーブルから関連するデータを結合して取得します。

  • 内部結合 (INNER JOIN): 両方のテーブルで結合条件を満たす行のみを返します。
  • 自己結合 (SELF JOIN): テーブル自体を別のエイリアスを使って結合します。
  • 外部結合 (OUTER JOIN): 結合条件を満たさない行も結果に含めます。LEFT JOIN, RIGHT JOIN, FULL JOINがあります。
-- 各学生の氏名と、履修しているコースのタイトルおよびスコア
SELECT S.full_name, C.course_title, E.score
FROM   Students S
JOIN   Enrollments E ON S.student_id = E.student_id
JOIN   Courses C ON E.course_id = C.course_id;

-- コースID 'CS101'の平均スコアが90点以上の学生名
SELECT S.full_name
FROM   Students S
JOIN   Enrollments E ON S.student_id = E.student_id
WHERE  E.course_id = 'CS101'
GROUP BY S.student_id, S.full_name
HAVING AVG(E.score) >= 90;

-- 少なくとも1人の指導教員を持つコースのタイトルとその指導教員名
-- Teachers(teacher_id, teacher_name), Course_Teachers(course_id, teacher_id)
-- SELECT C.course_title, T.teacher_name
-- FROM Courses C
-- JOIN Course_Teachers CT ON C.course_id = CT.course_id
-- JOIN Teachers T ON CT.teacher_id = T.teacher_id;

SQLのネストされたクエリ

一つのSELECT文（サブクエリ）の結果を、別のSELECT文（親クエリ）の条件として使用します。

  • IN句を伴うサブクエリ: サブクエリの結果セットに含まれるかどうかを判定します。
  • 比較演算子を伴うサブクエリ: サブクエリが単一の値を返す場合に、比較演算子と共に使用します。
  • ANY / ALLを伴うサブクエリ: サブクエリの結果セットのいずれかの値/すべての値と比較します。
  • EXISTS / NOT EXISTSを伴うサブクエリ: サブクエリが1つ以上の行を返すかどうかを判定します。
-- 'データベース理論'を履修している学生の名前を検索
SELECT full_name FROM Students
WHERE student_id IN (
    SELECT student_id FROM Enrollments
    WHERE course_id = (SELECT course_id FROM Courses WHERE course_title = 'データベース理論')
);

-- 全てのコースを履修した学生の名前
SELECT S.full_name
FROM Students S
WHERE NOT EXISTS (
    SELECT C.course_id
    FROM Courses C
    EXCEPT
    SELECT E.course_id
    FROM Enrollments E
    WHERE E.student_id = S.student_id
);

SQLの集合クエリ

複数のSELECT文の結果セットを結合します。結果セットのカラム数とデータ型は一致する必要があります。

  • UNION: 重複する行を削除して結合します。
  • UNION ALL: 重複を削除せずに結合します。
  • INTERSECT: 両方の結果セットに存在する行のみを返します。
  • EXCEPT: 最初の結果セットに存在し、2番目の結果セットには存在しない行を返します。
-- コンピュータ科学部の学生と、20歳未満の学生のユニークな名前をリスト
SELECT full_name FROM Students WHERE department = 'コンピュータ科学'
UNION
SELECT full_name FROM Students WHERE (2023 - birth_year) < 20;

SQLのデータ操作

データの挿入 (INSERT)

  • 特定の行の挿入:
INSERT INTO Students (student_id, full_name, birth_year, department, gender)
VALUES ('S000008', '鈴木一郎', 2004, '電子情報工学', 'M');
  • サブクエリの結果を挿入:
-- 平均年齢を格納するテーブルを作成し、各学科の平均年齢を挿入
CREATE TABLE DeptAvgAge (
    dept_name VARCHAR(30) PRIMARY KEY,
    avg_age   INT
);
INSERT INTO DeptAvgAge (dept_name, avg_age)
SELECT department, AVG(2023 - birth_year) FROM Students GROUP BY department;

データの更新 (UPDATE)

-- 学生ID 'S000001'の学生の学科を'情報科学'に変更
UPDATE Students SET department = '情報科学' WHERE student_id = 'S000001';

-- 全学生の年齢を1歳増加
UPDATE Students SET birth_year = birth_year - 1;

-- 'データベース理論'コースの全成績を0にリセット
UPDATE Enrollments SET score = 0
WHERE course_id = (SELECT course_id FROM Courses WHERE course_title = 'データベース理論');

データの削除 (DELETE)

-- 学生ID 'S000002'の学生の情報を削除
DELETE FROM Students WHERE student_id = 'S000002';

-- すべての履修記録を削除
DELETE FROM Enrollments;

-- コンピュータ科学部の学生の履修記録を削除
DELETE FROM Enrollments WHERE student_id IN (
    SELECT student_id FROM Students WHERE department = 'コンピュータ科学'
);

ビュー (VIEW)

ビューは、一つまたは複数の基本テーブルから導出される仮想的なテーブルです。データは物理的に保存されず、ビューの定義だけがデータベースに保存されます。基になるテーブルのデータが変更されると、ビューのクエリ結果もリアルタイムに反映されます。

ビューの作成

CREATE VIEW CS_Students_View AS
SELECT student_id, full_name, department FROM Students WHERE department = 'コンピュータ科学';

-- WITH CHECK OPTION は、ビューを通じて行われる更新操作がビューの定義条件に違反しないことを保証します。
CREATE VIEW Senior_Students_View AS
SELECT student_id, full_name, (2023 - birth_year) AS age FROM Students WHERE (2023 - birth_year) >= 20
WITH CHECK OPTION;

ビューの削除

DROP VIEW CS_Students_View;

ビューは、ユーザー操作の簡素化、データへの多様な視点の提供、論理データ独立性の向上、機密データの保護、複雑なクエリの表現などに役立ちます。

データベースのセキュリティと整合性

セキュリティ制御

データベースのセキュリティは、不正なアクセス、改ざん、破壊からデータを保護することを目的とします。一般的なメカニズムには以下があります。

  • ユーザー認証: ユーザー名とパスワード、デジタル証明書、ワンタイムパスワードなどにより、ユーザーの身元を確認します。
  • アクセス制御: 認証されたユーザーがどのデータオブジェクトに対してどのような操作（読み取り、書き込み、更新、削除など）を許可されるかを制御します。
    • 自主的アクセス制御（DAC）: データの所有者が他のユーザーへのアクセス権限を付与（GRANT）または剥奪（REVOKE）します。
    • 強制的アクセス制御（MAC）: 各データオブジェクトに機密レベルを、各ユーザーに許可レベルを割り当て、これらのレベルに基づいてアクセスを制限します。
  • ビューメカニズム: 特定のデータのみを公開することで、ユーザーがアクセスできる範囲を制限します。
  • 監査: データベースへのアクセス操作や変更をログに記録し、不正行為の追跡を可能にします。
  • データ暗号化: データを平文から暗号文に変換し、物理的な盗難や不正アクセスから保護します。
  • 統計機能のセキュリティ: 集約関数を悪用して個々の機密情報を推測することを防ぎます。
-- 特定のユーザーにStudentsテーブルへのSELECT権限を付与
GRANT SELECT ON Students TO user_viewer;

-- 特定のユーザーにEnrollmentsテーブルへのINSERT, UPDATE権限と、それをさらに他のユーザーに付与する権限を付与
GRANT INSERT, UPDATE ON Enrollments TO user_editor WITH GRANT OPTION;

-- 権限を剥奪
REVOKE SELECT ON Students FROM user_viewer;

データベースの整合性

データベースの整合性は、データの正確性、有効性、一貫性を維持するためのルールとメカニズムを指します。

  • エンティティ整合性: 主キーはNULL値であってはならず、一意である必要があります。
  • 参照整合性: 外部キーの値は、参照される主キーの値として存在するか、またはNULLである必要があります。違反時のアクション（ON DELETE CASCADE, ON DELETE SET NULL, ON DELETE RESTRICTなど）を定義できます。
  • ユーザー定義整合性: アプリケーション固有のビジネスルールやデータ制約です。CHECK制約、UNIQUE制約、NOT NULL制約などが使用されます。
-- Enrollmentsテーブルの学生IDの外部キー制約にON DELETE CASCADEを設定
ALTER TABLE Enrollments
ADD CONSTRAINT FK_StudentEnrollment
FOREIGN KEY (student_id) REFERENCES Students(student_id) ON DELETE CASCADE;

-- Coursesテーブルのcredits列に0より大きい値を要求するCHECK制約
ALTER TABLE Courses
ADD CONSTRAINT CHK_CreditsPositive CHECK (credits > 0);

トリガー

トリガーは、特定のデータベースイベント（INSERT、UPDATE、DELETE）が発生したときに自動的に実行される特別な手続きです。データの整合性維持やビジネスロジックの自動化に用いられます。

-- 学生のスコアが更新されたときに、更新ログテーブルに記録するトリガー
-- ScoreLogs(log_id PK, student_id, course_id, old_score, new_score, update_timestamp, updated_by)
CREATE TABLE ScoreLogs (
    log_id         SERIAL PRIMARY KEY,
    student_id     CHAR(8),
    course_id      CHAR(6),
    old_score      INT,
    new_score      INT,
    update_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_by     VARCHAR(50) DEFAULT CURRENT_USER
);

CREATE TRIGGER trg_AfterUpdateEnrollmentScore
AFTER UPDATE OF score ON Enrollments
FOR EACH ROW
WHEN (OLD.score IS DISTINCT FROM NEW.score) -- スコアが実際に変更された場合のみ
EXECUTE FUNCTION (
    INSERT INTO ScoreLogs (student_id, course_id, old_score, new_score)
    VALUES (NEW.student_id, NEW.course_id, OLD.score, NEW.score);
);

データベース回復技術

データベース回復技術は、様々な障害からデータを保護し、データベースを一貫性のある状態に戻すためのメカニズムです。その基盤となるのが「トランザクション」の概念です。

トランザクション

トランザクションは、データベースに対する一連の操作をまとめた、論理的な作業単位です。トランザクションは「オールオアナッシング」の原則に従い、すべて成功するか、すべて失敗（ロールバック）するかのいずれかです。

ACID特性

トランザクションは以下の4つの重要な特性（ACID特性）を満たす必要があります。

  • 原子性 (Atomicity): トランザクションは不可分な単位であり、すべて実行されるか、全く実行されないかのどちらかです。
  • 一貫性 (Consistency): トランザクションの開始時と終了時に、データベースは一貫性のある状態にある必要があります。
  • 隔離性 (Isolation): 並行して実行されるトランザクションは、互いに影響を与えず、あたかも直列に実行されたかのように見えます。
  • 永続性 (Durability): 一度コミットされたトランザクションによる変更は、システム障害が発生しても失われることはありません。
BEGIN TRANSACTION; -- トランザクション開始
-- 銀行口座AからBへ100単位送金
UPDATE Accounts SET balance = balance - 100 WHERE account_id = 'A101';
UPDATE Accounts SET balance = balance + 100 WHERE account_id = 'B202';
COMMIT; -- トランザクションを永続化
-- または ROLLBACK; -- トランザクションを破棄し、変更を元に戻す

障害と回復

データベースシステムで発生する可能性のある主な障害と、それに対する回復戦略です。

  • トランザクション内部障害: プログラムエラー、算術オーバーフロー、デッドロック、整合性制約違反など。通常はトランザクションのロールバック（UNDO）で回復します。
  • システム障害: ハードウェア故障、OSクラッシュなど、システムが予期せず停止する障害。データベースの内容は破壊されませんが、バッファ内の未書き込みデータが失われる可能性があります。未完了トランザクションはUNDO、コミット済みだがディスクに書き込まれていないトランザクションはREDOで回復します。
  • メディア障害: ディスクの破損など、ストレージ媒体の故障。最も深刻な障害であり、バックアップコピーとログファイルからの回復が必要です。
  • コンピュータウイルス: 意図的な破壊行為。

データダンプ（バックアップ）

データベース全体のコピーを作成するプロセスです。

  • 静的ダンプ: データベースへのアクセスを一時的に停止して行われるバックアップ。一貫性のあるコピーが得られますが、システムの可用性が低下します。
  • 動的ダンプ: ユーザーのアクセスを許可しながら行われるバックアップ。システム可用性は維持されますが、ダンプ中に発生した変更を記録するログファイルと組み合わせて使用されます。
  • 完全ダンプ: データベース全体の完全なコピーを作成します。
  • 増分ダンプ: 最後のダンプ以降に変更されたデータのみをバックアップします。

ログファイル

ログファイルは、トランザクションによるデータベースへのすべての更新操作を記録するファイルです。回復処理の要となります。

  • ログエントリの内容: トランザクションID、操作タイプ（INSERT/DELETE/UPDATE）、操作対象（レコードIDなど）、更新前データ（旧値）、更新後データ（新値）など。
  • ログの役割: トランザクション障害、システム障害、メディア障害からの回復を支援します。
  • ログの書き込み順序: データベースにデータを書き込む前に、必ずログレコードをディスクに書き込む「先行書き込みログ (WAL)」ルールが厳守されます。

チェックポイント

チェックポイントは、システム障害からの回復時間を短縮するための技術です。定期的にシステムの安定した状態（コミット済みのトランザクションがディスクに書き込まれた状態）をログファイルに記録します。

回復プロセスは、最新のチェックポイントからログを読み込み始めることで、不要なUNDO/REDO操作を削減できます。

データベースミラーリング

データベースの全体または重要な部分を別のディスクに複製（ミラー）し、DBMSが主データベースとミラーリングされたデータの整合性を保証します。メディア障害が発生した場合、ミラーディスクを使用してシステム運用を継続でき、ダウンタイムを最小限に抑えられます。

並行制御

複数のトランザクションが同時に実行される「並行処理」は、システムのスループットと応答性を向上させますが、データの一貫性を損なう可能性のある問題を引き起こすことがあります。並行制御は、これらの問題を解決し、トランザクションの隔離性を保証する役割を担います。

並行操作に起因する問題

  • 更新の消失 (Lost Update): 複数のトランザクションが同じデータを同時に更新しようとしたとき、一方のトランザクションの更新が他方によって上書きされ、失われる問題です。
  • 反復不能読み取り (Unrepeatable Read): あるトランザクションがデータを2回読み取った際に、その間に別のトランザクションがデータを更新したため、2回目の読み取り結果が1回目と異なる問題です。
  • ダーティリード (Dirty Read / Read Uncommitted): あるトランザクションが、まだコミットされていない（ロールバックされる可能性のある）別のトランザクションの変更データを読み取ってしまう問題です。

封鎖（ロック）メカニズム

ロックは、トランザクションがデータオブジェクトにアクセスする前に、そのオブジェクトをロックして他のトランザクションからのアクセスを制御するメカニズムです。主要なロックタイプは以下の通りです。

  • 排他ロック (Exclusive Lock / X-Lock): データオブジェクトへの書き込み操作の前に取得されます。X-Lockが設定されている間は、他のどのトランザクションもそのオブジェクトに対してS-LockもX-Lockも取得できません。
  • 共有ロック (Shared Lock / S-Lock): データオブジェクトへの読み取り操作の前に取得されます。S-Lockが設定されている間は、他のトランザクションもS-Lockを取得して読み取りは可能ですが、X-Lockは取得できません。

ロックの互換性マトリックスは以下のようになります。

X-Lock リクエスト S-Lock リクエスト
既存のX-Lock 不互換 不互換
既存のS-Lock 不互換 互換

封鎖プロトコル

ロックの適用、保持、解除のルールを定義したものです。

  • 第一水準プロトコル: トランザクションがデータを更新する前にX-Lockを取得し、トランザクションの終了まで保持します。更新の消失を防ぎます。
  • 第二水準プロトコル: 第一水準に加えて、データを読み取る前にS-Lockを取得し、読み取り後に解除します。ダーティリードを防ぎます。
  • 第三水準プロトコル: 第二水準に加えて、S-Lockもトランザクションの終了まで保持します。反復不能読み取りを防ぎます。

ライブロックとデッドロック

  • ライブロック: 複数のトランザクションがリソースを巡って常に状態を変化させながら互いに待ち続ける状況で、どのトランザクションも進行できない状態です。先着順のロック取得ポリシーで回避できます。
  • デッドロック (Deadlock): 複数のトランザクションが互いに相手が保持しているリソースの解放を待ち、どのトランザクションも進行できなくなる状況です。
    • デッドロックの予防: 一括ロック法（トランザクション開始時に必要なすべてのロックを一度に取得する）、順序ロック法（リソースにグローバルな順序を付け、その順序でロックを取得する）などがあります。
    • デッドロックの検出と解決: タイムアウト法や待機グラフ法でデッドロックを検出し、犠牲者トランザクションを選択して強制的にロールバックすることで解決します。

直列化可能性 (Serializability)

並行して実行されるトランザクションのスケジューリングが正しいとされる基準です。スケジューリングの結果が、それらのトランザクションを何らかの順序で直列に実行した場合と同じになる場合に、そのスケジューリングは「直列可能である」と判断されます。

「衝突直列化可能性」は、直列化可能性の十分条件であり、衝突する操作（異なるトランザクションが同じデータにアクセスする読み書き/書き書き操作）の順序を変更せずに直列なスケジューリングに変換できる場合に成立します。

2相ロック (Two-Phase Locking / 2PL)

2相ロックは、直列化可能なスケジューリングを生成するための最も一般的なロックプロトコルです。

  • 拡張フェーズ (Growing Phase): トランザクションは新しいロックを要求できますが、既存のロックを解放することはできません。
  • 縮小フェーズ (Shrinking Phase): トランザクションはロックを解放できますが、新しいロックを要求することはできません。

2相ロックプロトコルに従うすべてのスケジューリングは直列可能であることが保証されますが、デッドロックが発生する可能性はあります。

封鎖粒度と意図ロック

封鎖粒度 (Granularity of Locking)とは、ロックが適用されるデータオブジェクトの大きさのことです。粒度が大きいほど、ロック管理のオーバーヘッドは減少しますが、並行性は低下します。粒度が小さいほど、並行性は向上しますが、ロック管理のオーバーヘッドが増加します。

例えば、データベース全体、テーブル、ページ、タプル、属性といった様々な粒度が考えられます。

多粒度ロック (Multi-Granularity Locking)は、異なる粒度でロックを適用することを可能にし、システムの柔軟性とパフォーマンスを向上させます。これをサポートするために、意図ロック (Intent Locks)が導入されます。意図ロックは、より下位の粒度のオブジェクトにロックが設定されることを示すために、上位の粒度のオブジェクトに設定されるロックです。

  • 意図共有ロック (Intention Shared Lock / IS-Lock): このノードの子孫ノードのいずれかにS-Lockが設定されることを意図しています。
  • 意図排他ロック (Intention Exclusive Lock / IX-Lock): このノードの子孫ノードのいずれかにX-Lockが設定されることを意図しています。
  • 共有意図排他ロック (Shared Intention Exclusive Lock / SIX-Lock): このノード自体にS-Lockを設定し、その子孫ノードのいずれかにX-Lockが設定されることを意図しています。

意図ロックは、上位ノードに設定することで、下位ノードのロック状態を効率的に確認できるようにし、ロック衝突のチェックを高速化します。

リレーショナルデータベース設計理論

関係モデルのストレージ異常

設計が不適切なリレーショナルスキーマは、データの冗長性を引き起こし、以下の「ストレージ異常」と呼ばれる問題を引き起こします。

  • データ冗長性: 同じ情報が複数の場所に重複して保存され、ストレージの無駄やデータの一貫性問題を引き起こします。
  • 挿入異常: ある情報を挿入するために、まだ存在しない別の情報も挿入する必要がある問題です。
  • 削除異常: ある情報を削除した結果、意図せずに別の重要な情報も失われてしまう問題です。
  • 更新異常: 同じ情報が複数の場所に存在するため、更新時にすべての箇所を更新しないとデータが不整合になる問題です。

これらの異常は、データ間の依存関係が不適切に設計されたことに起因します。

関数従属性 (Functional Dependency / FD)

関数従属性は、関係内の属性間の制約を表し、現実世界の属性間の論理的な関連性を抽象化したものです。

  • 定義: 関係スキーマ$R(U)$において、属性集合$X \subseteq U$と$Y \subseteq U$があるとき、もし$R$の任意のインスタンスにおいて、どの2つのタプルも$X$の属性値が等しければ、$Y$の属性値も等しいならば、$X$は$Y$を関数的に決定する、または$Y$は$X$に関数的に従属する、といい、$X \to Y$と表記します。$X$を「決定項」、$Y$を「被決定項」と呼びます。
  • 自明な関数従属性: $Y \subseteq X$である場合、$X \to Y$は常に成立し、自明な関数従属性と呼ばれます。
  • 完全関数従属性: $X \to Y$が成立し、かつ$X$のいかなる真部分集合$X'$に対しても$X' \to Y$が成立しない場合、$Y$は$X$に完全関数従属するといいます。
  • 部分関数従属性: $X \to Y$が成立し、かつ$X$の真部分集合$X'$に対しても$X' \to Y$が成立する場合、$Y$は$X$に部分関数従属するといいます。
  • 推移的関数従属性: $X \to Y$と$Y \to Z$が成立し、$Y \not\to X$であり、$Z \not\subseteq Y$である場合、$Z$は$X$に推移的に従属するといいます。

関係スキーマの正規化

正規化は、関数従属性の理論に基づいて関係スキーマを分解し、ストレージ異常を排除してより良いデータベース設計を行うプロセスです。関係スキーマが満たすべき条件を「正規形（Normal Form / NF）」と呼びます。

  • 第一正規形 (1NF): 関係のすべての属性がアトミックな値（不可分な値）を持つこと。これはリレーショナルモデルの基本的な要件です。
  • 第二正規形 (2NF): 1NFであり、かつすべての非主キー属性が、すべての候補キーに完全関数従属すること。部分関数従属性を排除します。
  • 第三正規形 (3NF): 2NFであり、かつ非主キー属性が、候補キーに推移的に従属しないこと。推移的関数従属性を排除します。
  • ボイス/コッド正規形 (BCNF): 1NFであり、かつ関係内のすべての非自明な関数従属性$X \to Y$について、$X$が候補キーであること。3NFが排除できない特定の種類の依存関係を排除します。

例: 学生と成績のテーブルEnrollments(student_id, course_id, student_name, score)を考えます。主キーは(student_id, course_id)です。

  • student_id → student_nameという部分関数従属性が存在するため、このテーブルは2NFではありません。これをEnrollments_fixed(student_id, course_id, score)とStudents_info(student_id, student_name)に分解することで2NFになります。
  • さらに、department → dept_headのような推移的従属性（student_id → department → dept_head）が存在する場合、3NFではありません。これを分解することで3NFになります。

多値従属性 (Multivalued Dependency / MVD) と第四正規形 (4NF)

関数従属性では表現できない、より複雑な依存関係に対応するため、多値従属性が導入されました。

  • 定義: 関係スキーマ$R(U)$において、属性集合$X, Y \subseteq U$があるとき、もし$R$の任意のタプル$t$に対して、$t[X]$の特定の値が対応する$t[Y]$の値の集合を決定し、この集合が$R$の他の属性に独立であるならば、$X$は$Y$に多値従属する、といい、$X \twoheadrightarrow Y$と表記します。
  • 第四正規形 (4NF): 1NFであり、かつすべての非自明な多値従属性$X \twoheadrightarrow Y$について、$X$が関係のスーパーキーであること。多値従属性による冗長性を排除します。

関数従属性の公理と閉包

関数従属性の理論的な推論には、Armstrongの公理系が用いられます。これにより、ある関数従属性の集合$F$から論理的に導出されるすべての関数従属性（$F$の閉包$F^+$）を特定できます。

  • Armstrongの公理:
    1. 反射律: $Y \subseteq X \implies X \to Y$
    2. 増加律: $X \to Y \implies XZ \to YZ$
    3. 推移律: $X \to Y, Y \to Z \implies X \to Z$
  • 属性閉包 ($X_F^+$): 属性集合$X$から$F$に含まれる関数従属性を使って推論できるすべての属性の集合です。属性閉包の計算は、候補キーの特定や関数従属性の論理的含意の判定に不可欠です。

関数従属性集合の同値性と最小カバー

異なる関数従属性集合が同じ論理的な含意を持つ場合、それらは「同値である」と言われます。また、「最小関数従属性集合（最小カバー）」は、以下の条件を満たす関数従属性の集合です。

  • すべての関数従属性の右辺が単一属性である。
  • どの関数従属性も冗長ではない（その関数従属性を取り除くと、元の集合と論理的に同値ではなくなる）。
  • どの関数従属性の左辺も冗長ではない（その関数従属性の左辺から属性を取り除くと、元の集合と論理的に同値ではなくなる）。

データベース設計

データベース設計の概要

データベース設計は、特定のアプリケーション要件に基づいて、最適化された論理スキーマと物理構造を構築し、データベースとそのアプリケーションシステムを確立するプロセスです。効果的なデータストレージと管理、および多様なユーザー要件の充足を目指します。

データベース設計は通常、以下の6つの段階を経て進められます。

  1. 要件分析: ユーザーのデータ、処理、セキュリティ、整合性に関する要件を詳細に把握します。
  2. 概念構造設計: 収集した要件をDBMSから独立した概念モデル（例: E-Rモデル）に抽象化します。
  3. 論理構造設計: 概念モデルを選択したDBMSがサポートするデータモデル（例: リレーショナルモデル）に変換し、最適化します。
  4. 物理構造設計: 論理モデルに基づいて、最適なストレージ構造とアクセス方法を決定します。
  5. データベース実装: DDLとホスト言語を用いてデータベースを構築し、アプリケーションを開発、データをロードし、システムを試運転します。
  6. データベース運用と保守: システムの運用中にパフォーマンス監視、調整、バックアップ、回復、再編成などを行います。

要件分析

要件分析の目的は、現実世界のオブジェクトとプロセスを詳細に調査し、新システムの機能、データ、セキュリティ、および整合性に関するすべてのユーザー要件を明確にすることです。構造化分析（SA）手法が一般的に用いられ、データフロー図やデータ辞書を通じて要件を表現します。

データ辞書は、データ項目、データ構造、データフロー、データストア、処理プロセスに関する詳細なメタデータを記述します。

概念構造設計

この段階では、要件分析で得られたユーザー要件を、DBMSに依存しない高レベルな「概念スキーマ」に変換します。E-Rモデルがその主要なツールです。

  • 設計手法: ボトムアップ（ローカルビューを設計し、それらを統合する）、トップダウン（グローバルフレームワークを定義し、詳細化する）、またはこれらの混合戦略が用いられます。
  • データ抽象化:
    • 分類 (Classification): オブジェクトと型の関係（例: 山田太郎は「学生」のメンバーである）。
    • 集約 (Aggregation): オブジェクトの構成要素の関係（例: 学生は「学籍番号」「氏名」「所属学科」で構成される）。
    • 汎化 (Generalization): 型間のサブセット関係（例: 「学部生」と「院生」は「学生」のサブタイプである）。
  • 局部ビューの統合: 各ユーザーグループのE-R図を統合する際には、属性衝突、命名衝突、構造衝突などの問題に対処し、データの冗長性を排除または管理します。

論理構造設計

概念構造設計で作成されたE-R図を、選択したDBMSがサポートする特定の論理データモデル（例: リレーショナルモデル）に変換します。

  • E-R図からリレーショナルモデルへの変換:
    • エンティティ型は関係スキーマに変換され、その属性は関係の列になります。
    • 1:1、1:N、M:N、N項関係などのリレーションシップは、それぞれ独立した関係スキーマになるか、関連するエンティティの関係スキーマに統合されます。
  • データモデルの最適化: 変換された関係スキーマは、正規化理論（2NF, 3NF, BCNF, 4NFなど）に基づいて最適化され、ストレージ異常が排除されます。
    • 水平分解: 関係のタプルを複数の部分集合に分割し、それぞれをサブ関係とします。
    • 垂直分解: 関係の属性を複数の部分集合に分割し、それぞれをサブ関係とします。
  • ユーザーサブスキーマの設計: ユーザーのアクセス権限や使用目的に応じて、ビュー（外部スキーマ）を定義し、データへのアクセスを簡素化したり、セキュリティを強化したりします。

物理設計

論理データモデルを基に、実際の物理ストレージにおけるデータ構造とアクセス方法を決定します。これは、DBMSの特性とアプリケーションのパフォーマンス要件に強く依存します。

  • 物理ストレージデバイス: 高速キャッシュ、メインメモリ、ディスク、光ストレージ、磁気テープなど。
  • ファイル構造: 無順序ファイル（ヒープ）、順序ファイル、ハッシュファイル。
  • インデックス構造: B+木が最も一般的であり、主キーインデックス、クラスタードインデックス、セカンダリインデックスなどがあります。
  • アクセス方法の選択: クエリの頻度、条件属性、結合条件、更新頻度などを考慮して、最適なインデックス（単一属性、複合、一意性）、クラスター、ハッシュの利用を決定します。
    • クラスタードインデックス: 物理的なデータ格納順序をインデックス順序と一致させ、範囲検索やソート操作の効率を向上させます。
  • データベースストレージ構造の設計: 関係、インデックス、クラスター、ログファイル、バックアップファイルの物理的な配置を決定します。アクセス時間、ストレージ利用率、メンテナンスコストを考慮します。
  • システム構成の最適化: DBMSが提供するメモリ割り当て、バッファサイズ、同時ユーザー数などのパラメータを調整します。

データベース運用と保守

データベースシステムの稼働後の長期的なタスクであり、システムの安定性、効率性、可用性を維持します。

  • 機能テストと性能テスト: システムの実装後、アプリケーションの機能とパフォーマンスが設計要件を満たしているかを確認します。
  • データベースのバックアップと回復: 定期的なデータダンプとログ管理を通じて、障害発生時のデータ損失を最小限に抑えます。
  • セキュリティと整合性制御: アクセス権限の管理、整合性制約の監視と適用を継続します。
  • パフォーマンス監視、分析、調整: データベースのパフォーマンスを定期的に監視し、必要に応じて物理構造やクエリを調整して最適化します。
  • データベースの再編成と再構築: データ量やアクセスパターンの変化に対応して、ストレージ構造を再編成したり（デフラグメント、空き領域の回収など）、必要に応じてスキーマを再構築（変更）したりします。

データベース設計は一度きりのプロセスではなく、システム運用を通じて継続的に評価、調整、改善される長期的な取り組みです。

データベースシステムの新たな技術

データベース技術は、リレーショナルモデルの確立以降も進化を続けており、様々な新しいパラダイムや技術が生まれています。

  • データモデルの進化:
    • 複雑なデータモデル: 1NFの制約を緩和し、入れ子になった構造や集合型を許容するデータモデル。
    • オブジェクト指向データモデル: オブジェクト指向の概念（カプセル化、継承、ポリモーフィズム）をデータ管理に適用。
    • XMLデータモデル: 半構造化データを扱うためのXMLベースのデータモデル。
    • NoSQLデータベース: リレーショナルモデル以外のデータ構造（キー・バリュー、ドキュメント、カラム指向、グラフなど）を採用し、大規模な分散環境や特定のアプリケーション要件に特化。
  • 関連技術との統合:
    • 並列データベース: 並列処理アーキテクチャ（共有メモリ、共有ディスク、シェアードナッシング）を利用して、大規模なデータ処理のパフォーマンスを向上。
    • アクティブデータベース: 特定のイベントや条件に基づいて自動的にアクションを実行するルールベースのシステム。
    • エンジニアリングデータベース: CAD/CAMなどのエンジニアリング設計データやドキュメントの管理に特化。
    • 空間データベース: 地理空間情報（位置、形状、サイズ、分布など）を効率的に格納、クエリ、分析できるデータベース。

タグ: リレーショナルデータベース SQL データベース設計 データモデル 関数従属性

8月3日 06:13 投稿

ホットタグ

©2026 異端開発室