[SQLのはじめ方] Part26: ビュー（VIEW）とマテリアライズドビュー

SQLの学習もいよいよ高度な内容に入ってきましたね！今回は、複雑なクエリをシンプルに見せたり、よく使う集計結果を保存しておいたりするのに便利な「ビュー（VIEW）」と「マテリアライズドビュー（Materialized View）」について学びます。

これらを使いこなせると、SQLの記述が楽になったり、データベースのパフォーマンスを改善したりできるので、ぜひマスターしましょう！💪

ビューは、一言で言うと「保存されたSELECT文」または「仮想的なテーブル」です。SELECT文の結果を、あたかも一つのテーブルのように扱えるように定義したものです。

ビュー自体は実際のデータを持っていません。ビューに対してクエリを実行すると、その都度、定義されたSELECT文が内部的に実行され、結果が返されます。

ビューの作成方法 (CREATE VIEW)

ビューはCREATE VIEW文を使って作成します。

CREATE VIEW ビュー名 AS
SELECT カラム1, カラム2, ...
FROM テーブル名
WHERE 条件式;
      

例：従業員テーブル（employees）から、東京本社勤務の従業員の名前と部署名を取得するビューを作成してみましょう。

-- employees テーブル (id, name, department, location)
-- departments テーブル (id, name) ※ 架空のテーブル

CREATE VIEW tokyo_employees AS
SELECT
    e.name AS employee_name,
    d.name AS department_name
FROM
    employees e
INNER JOIN
    departments d ON e.department_id = d.id
WHERE
    e.location = '東京本社';
      

これで、tokyo_employeesという名前のビューが作成されました。

ビューの使い方

ビューは通常のテーブルと同じようにSELECT文で参照できます。

SELECT * FROM tokyo_employees;
      

このクエリを実行すると、内部的にはCREATE VIEWで定義したSELECT文が実行され、東京本社勤務の従業員の名前と部署名が表示されます。

ビューのメリット ✨

• 複雑なクエリの簡略化: 長くて複雑なJOINや集計を含むクエリをビューとして定義しておけば、あとは簡単なSELECT文で結果を取得できます。
• セキュリティ向上: ユーザーにはビューへのアクセス権限のみを与え、元のテーブルへの直接アクセスを制限することで、見せたいデータだけを公開できます。
• 再利用性の向上: よく使うクエリをビューにしておくことで、何度も同じクエリを書く手間が省け、コードの再利用性が高まります。

ビューのデメリット・注意点 ⚠️

• パフォーマンス: ビューへのアクセスは、その都度定義されたSELECT文が実行されるため、元のクエリが複雑な場合はパフォーマンスが低下することがあります。
• 更新制限: ビューに対するINSERT, UPDATE, DELETE操作は、ビューの定義（複数のテーブルをJOINしている、集約関数を使っているなど）によっては制限されるか、実行できない場合があります。
• 依存関係: ビューは元のテーブルに依存しているため、元のテーブル構造が変更されるとビューが影響を受ける可能性があります。

マテリアライズドビューは、ビューと似ていますが、大きな違いは「クエリの結果を物理的に保存する」点です。ビューが仮想的なテーブルであるのに対し、マテリアライズドビューは「実体を持つテーブル」のようなものです。

クエリの結果を事前に計算して保存しておくため、参照時のパフォーマンスが非常に高速になります。ただし、元のデータが更新されても自動的には反映されず、手動またはスケジュールで「リフレッシュ（更新）」する必要があります。

注意 マテリアライズドビューの構文や機能は、使用するRDBMS（PostgreSQL, Oracleなど）によって異なります。MySQLには標準ではマテリアライズドビューの機能はありません（ただし、同様の仕組みをイベントスケジューラなどで実現することは可能です）。ここでは主にPostgreSQLを例に説明します。

マテリアライズドビューの作成方法 (CREATE MATERIALIZED VIEW)

PostgreSQLではCREATE MATERIALIZED VIEW文を使います。

-- PostgreSQL の例
CREATE MATERIALIZED VIEW ビュー名 AS
SELECT カラム1, カラム2, ...
FROM テーブル名
WHERE 条件式;
      

例：商品ごとの月間売上集計をマテリアライズドビューとして作成してみましょう。

-- sales テーブル (id, product_id, sale_date, amount) ※ 架空のテーブル

-- PostgreSQL の例
CREATE MATERIALIZED VIEW monthly_sales_summary AS
SELECT
    product_id,
    DATE_TRUNC('month', sale_date)::DATE AS sale_month,
    SUM(amount) AS total_amount,
    COUNT(*) AS sales_count
FROM
    sales
GROUP BY
    product_id,
    DATE_TRUNC('month', sale_date)
ORDER BY
    sale_month DESC,
    product_id;
      

これで、monthly_sales_summaryという名前で、集計結果が物理的に保存されたマテリアライズドビューが作成されました。

マテリアライズドビューの使い方

使い方はビューと同様で、通常のテーブルのようにSELECT文で参照できます。

SELECT * FROM monthly_sales_summary WHERE product_id = 101;
      

このクエリは、事前に計算され保存されている結果からデータを取得するため、非常に高速に動作します。

マテリアライズドビューの更新 (REFRESH)

元のテーブル（例：sales）のデータが更新されても、マテリアライズドビュー（monthly_sales_summary）は自動では更新されません。データを最新の状態にするには、REFRESH MATERIALIZED VIEW文を実行する必要があります。

-- PostgreSQL の例
REFRESH MATERIALIZED VIEW monthly_sales_summary;
      

このリフレッシュ操作は、データ量やクエリの複雑さによっては時間がかかる場合があります。そのため、夜間バッチなどで定期的に実行することが一般的です。

マテリアライズドビューのメリット 🚀

• パフォーマンス向上: クエリ結果を物理的に保持するため、参照速度が大幅に向上します。特に、集計やJOINが複雑で時間のかかるクエリに対して効果的です。
• 負荷分散: 参照クエリの負荷が元のテーブルではなくマテリアライズドビューにかかるため、元のテーブルへの負荷を軽減できます。

マテリアライズドビューのデメリット・注意点 ⚠️

• データの鮮度: リフレッシュしない限りデータは更新されないため、常に最新のデータが必要な場合には向きません。
• ストレージ消費: クエリ結果を物理的に保存するため、データ量に応じてストレージ容量を消費します。
• 更新コスト: リフレッシュ処理には時間とリソースが必要です。元のデータ量が多い場合や頻繁な更新が必要な場合、リフレッシュの負荷が高くなります。
• RDBMS依存: 標準SQLではなく、利用できるRDBMSが限られます（PostgreSQL, Oracle など）。

ビューとマテリアライズドビューは、それぞれの特性を理解して使い分けることが重要です。