2日目: RDBMSの基本を徹底解剖！テーブル、スキーマ、インデックスの役割
はじめに：データベースの「設計図」を理解する
昨日は、データベースとデータウェアハウスの大きな違いについて解説しました。データベースが日々の業務を支える「在庫管理システム」だとすれば、今日はそのシステムの「設計図」にあたる部分を詳しく見ていきます。
リレーショナルデータベース（RDBMS）は、単なるデータの箱ではありません。データが規則正しく、効率的に整理されるように、いくつかの重要な概念に基づいて設計されています。今回は、その中でも特に重要なテーブル、スキーマ、インデックスの3つに焦点を当て、それぞれの役割と関係性を深掘りしていきます。
1. RDBMSの基本構成要素：テーブル（Table）
リレーショナルデータベースを構成する最も基本的な要素がテーブルです。テーブルは、データを格納するための表形式の構造で、Excelのスプレッドシートをイメージすると分かりやすいでしょう。
- 行（Row）: データの1つのまとまりです。レストランの例で言えば、「ある注文のレコード」や「あるお客様のレコード」に相当します。これを「タプル（Tuple）」と呼ぶこともあります。
- 列（Column）: データの属性を定義します。例えば、「注文ID」「商品名」「数量」「価格」といった項目が列になります。これを「アトリビュート（Attribute）」と呼ぶこともあります。
テーブルの例：ordersテーブル
| order_id (注文ID) | customer_id (顧客ID) | order_date (注文日) | total_price (合計金額) |
|---|---|---|---|
| 101 | C001 | 2024-08-01 | 3500 |
| 102 | C002 | 2024-08-01 | 5200 |
| 103 | C001 | 2024-08-02 | 4100 |
このように、テーブルは関連するデータを論理的にまとめ、管理しやすくする役割を担っています。
【データ型と制約：テーブル設計の基礎】
テーブルを設計する際には、各列に格納するデータの種類を明確にする「データ型（Data Type）」と、データの整合性を保つための「制約（Constraint）」を定義します。
-
データ型:
-
VARCHAR/VARCHAR2: 可変長の文字列。 -
INT/NUMBER: 整数や数値。 -
DATE/DATETIME: 日付や日時。 -
BOOLEAN/TINYINT: 真偽値。
-
-
制約:
-
PRIMARY KEY: テーブル内の各行を一意に識別するための制約です。ordersテーブルのorder_idのように、絶対に重複しない値を持つ列に設定します。 -
FOREIGN KEY: 他のテーブルの主キーを参照するための制約です。ordersテーブルのcustomer_idは、customersテーブルのcustomer_id（主キー）を参照することで、データの整合性を保ちます。 -
NOT NULL: この列にはNULL（値なし）を許可しないことを保証します。 -
UNIQUE: この列の値が一意であることを保証します。PRIMARY KEYとの違いは、NULLを1つだけ許容する点です。
-
これらのデータ型と制約を適切に設定することで、データの品質を高く保ち、アプリケーション側の不具合を防ぐことができます。
2. 論理的なグループ分け：スキーマ（Schema）
テーブルがデータを格納する箱だとすれば、スキーマは、その箱（テーブル）を種類ごとに整理する「フォルダ」のようなものです。
スキーマは、関連する複数のテーブルや、インデックス、ビューなどのデータベースオブジェクトを論理的にグループ化するために使われます。
-
ユーザー管理: スキーマは、ユーザーやロールと関連付けられることが多いです。例えば、
salesスキーマには営業部門の担当者しかアクセスできないようにしたり、hrスキーマには人事部門しかアクセスできないようにすることで、セキュリティと管理を強化できます。 -
名前空間の管理: 異なるスキーマに同じ名前のテーブルを作成することも可能です。例えば、
sales.ordersとhr.ordersのように、スキーマ名が異なることで、名前の衝突を防ぎ、データベース全体を整理された状態に保てます。
Oracleではユーザーとスキーマが1対1で対応する論理的な概念として、MySQLではデータベース自体がスキーマとして扱われるなど、製品によって定義が若干異なりますが、役割としては「論理的なグループ分け」であると理解しておけば問題ありません。
【スキーマ設計の重要性】
スキーマ設計は、データベース全体の構造を決定する最も重要な工程の一つです。適切なスキーマ設計は、データの保守性、拡張性、そしてパフォーマンスに直結します。
- 保守性: 関連するオブジェクトがまとまっているため、管理が容易になります。
- 拡張性: 新しい業務が追加された場合でも、既存のスキーマに影響を与えることなく、新しいスキーマを作成して対応できます。
- セキュリティ: スキーマごとにアクセス権限を細かく設定できるため、情報漏洩のリスクを低減できます。
3. データ検索の高速化：インデックス（Index）
テーブルに大量のデータが格納されると、特定のデータを探し出すのに時間がかかってしまいます。これを解決するのがインデックスです。
インデックスは、書籍の 「索引」 をイメージすると分かりやすいでしょう。ページを最初から最後までめくる代わりに、索引を使って目的のキーワードが記載されているページ番号を素早く見つけることができます。
データベースでも同様に、特定の列にインデックスを作成することで、WHERE句などで指定した条件に一致するデータを高速に検索できるようになります。
【インデックスがない場合】
SELECT * FROM employees WHERE last_name = '田中';
このクエリを実行すると、データベースはemployeesテーブルのすべての行を1つずつ調べて、「田中」を探します。これを「フルスキャン」と呼び、データ量が多いと時間がかかります。
【インデックスがある場合】
last_name列にインデックスを作成しておくと、データベースはインデックスを調べて「田中」がどの行にあるかをすぐに特定できます。これにより、必要な行だけを効率的に読み取ることができ、検索速度が劇的に向上します。
【インデックスの種類と特性】
インデックスにはいくつかの種類があり、それぞれ特性が異なります。
-
B-Treeインデックス: 最も一般的なインデックスで、ツリー構造でデータを管理します。等価検索（
=)、範囲検索（>、<）など、幅広い検索条件に有効です。 -
複合インデックス: 複数の列を組み合わせて作成するインデックスです。
WHERE句で複数の列を条件として指定するクエリのパフォーマンスを改善します。 - 全文検索インデックス: 文字列の中身を高速に検索するためのインデックスです。
しかし、インデックスにはデメリットもあります。
- ディスク容量: インデックス自体もデータとして保存されるため、ディスク容量を消費します。
- 更新コスト: データの追加、更新、削除のたびに、インデックスも更新する必要があるため、これらの処理のパフォーマンスが低下する可能性があります。
したがって、インデックスは闇雲に作成するのではなく、検索のパフォーマンスが重要となる列に絞って適切に設計する必要があります。これはデータベースチューニングにおいて非常に重要なスキルです。
まとめ：これからの学習に向けて
- テーブル: データを格納する基本的な箱
- スキーマ: テーブルを論理的にグループ化するフォルダ
- インデックス: データ検索を高速化する書籍の索引
これらの概念は、OracleでもMySQLでも共通して使われるデータベースの基礎中の基礎です。データベースを設計する際や、パフォーマンスを改善する際に必ず向き合うことになります。
明日は、今日学んだ基礎知識を活かし、実際にOracle Databaseの環境構築と基本操作をハンズオン形式で解説します。手を動かしながら、これらの概念がどのように使われているのかを体験してみましょう。
【今後のロードマップ】
- 明日（3日目）: ハンズオン！Oracle Databaseの環境構築と基本操作
- 4日目: MySQLで学ぶ！Webアプリケーションでのデータベース活用術
- 5日目: SQLの壁を乗り越える！OracleとMySQLで共通して使えるクエリとTips