ビューの基本構文
CREATE VIEW（ビューの作成）
CREATE VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE 条件;
ALTER VIEW（ビューの変更）
ALTER VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE 条件;
DROP VIEW（ビューの削除）
DROP VIEW view_name;
目次
ビュー（VIEW）とは
ビューの基本概念と役割
ビューはSELECTの結果を仮想テーブルとして再利用する仕組みです。
物理的なデータを保持せず、定義されたクエリを通じて基になるテーブルへアクセスします。
これにより、複雑な結合やフィルタ条件を一箇所に集約して再利用でき、アプリケーション側のSQLを簡潔に保てます。
また列や行を制限したビューを公開することで、必要最小限のデータだけを見せる権限制御の入口としても機能します。
テーブルとの違い
テーブルは行データを物理的に格納しますが、ビューは定義（SELECT文）のみを持ちます。
クエリ実行時に定義が展開されるため、原則として更新・削除のI/Oは基テーブルで行われます。
一部の条件を満たす場合のみ、ビュー経由での更新が可能ですが、常に可能ではありません。
また、ビュー単体にはインデックスを直接持てませんが、後述のインデックス付きビューは例外的に結果を物理化します。
ビューの作成と基本構文
CREATE VIEWの基本構文
ビューはCREATE VIEWで定義します。
基本構文は次のとおりです。
CREATE VIEW schema_name.view_name AS
SELECT 列1, 列2, ...
FROM スキーマ.テーブル
WHERE 条件;
推奨事項として、名前はスキーマ名を含めた二部名で管理し、意図がわかる命名規則（例: vw_SalesDaily）を採用します。
依存テーブルや列に変更が入るとビューが無効化される場合があるため、定義はリポジトリでバージョン管理するのが実務的です。
実際の作成例（SELECTベース）
売上テーブルと顧客テーブルを結合し、直近30日の売上を返すビューの例です。
CREATE VIEW dbo.vw_RecentSales AS
SELECT
s.SaleId,
s.SaleDate,
s.Amount,
c.CustomerName
FROM dbo.Sales AS s
JOIN dbo.Customers AS c
ON c.CustomerId = s.CustomerId
WHERE s.SaleDate >= DATEADD(DAY, -30, CAST(GETDATE() AS date));
この定義により、アプリ側は SELECT * FROM dbo.vw_RecentSales; と書くだけで必要な結合・期間条件を再利用できます。
クエリの重複や記述ミスを防ぎ、保守性が向上します。
ビューの更新・削除
ALTER VIEWでの変更方法
ビューの定義変更はALTER VIEWを使います。
依存関係を崩さずに定義を入れ替えられます。
ALTER VIEW dbo.vw_RecentSales AS
SELECT
s.SaleId,
s.SaleDate,
s.Amount,
c.CustomerName,
s.Channel
FROM dbo.Sales AS s
JOIN dbo.Customers AS c
ON c.CustomerId = s.CustomerId
WHERE s.SaleDate >= DATEADD(DAY, -60, CAST(GETDATE() AS date)); -- 期間を60日に変更
変更後は依存オブジェクト（他のビュー、ストアド、レポート）への影響を確認します。
本番では変更前後の差分と実行計画を比較し、性能劣化がないかをチェックするのが安全です。
DROP VIEWでの削除
不要になったビューはDROP VIEWで削除します。
複数のビューをまとめて削除することも可能です。
DROP VIEW IF EXISTS dbo.vw_RecentSales;
削除前に依存関係を棚卸しし、参照元のアプリやレポートがないかを確認しましょう。
誤削除に備え、作成スクリプトはバージョン管理で復元できる状態にしておくと安心です。
ビューのメリットと注意点
メリット（再利用性・セキュリティ・メンテナンス性）
ビューは複雑なロジックを隠蔽し、再利用を促進します。
アプリケーションは単純なSELECTで済むため、変更耐性が高まります。
また列・行の公開範囲を限定したビューを提供すれば、テーブル本体への直接アクセスを避けつつ権限制御がしやすくなります。
基テーブルが変わってもビューのインターフェイスを維持すれば、アプリ側の変更を最小限に抑えられます。
注意点（パフォーマンス・更新制限など）
ビューは定義を展開して実行するため、複雑すぎる結合やネストは実行計画を悪化させる恐れがあります。
必要に応じてインデックスや統計情報を調整し、実行計画を確認しましょう。
また、複数テーブルを結合したビューは常に更新可能ではありません。
主キーの一意性が保てないなど、更新制約に該当するとINSERT/UPDATE/DELETEが拒否されます。
インデックス付きビュー（Indexed View）とは
仕組みと利用条件
インデックス付きビューは、ビューの結果を物理的に保持する仕組みです。
初回にクラスタ化インデックスを付与すると結果がマテリアライズされ、特定の集計や結合が高速化します。
ただし、WITH SCHEMABINDING などの条件を満たす必要があります。
CREATE VIEW dbo.vw_SalesSummary
WITH SCHEMABINDING AS
SELECT
s.CustomerId,
COUNT_BIG(*) AS Cnt,
SUM(s.Amount) AS TotalAmount
FROM dbo.Sales AS s
GROUP BY s.CustomerId;
CREATE UNIQUE CLUSTERED INDEX IX_vw_SalesSummary
ON dbo.vw_SalesSummary(CustomerId);
これにより、SELECTはビュー上のインデックスを利用して高速化される可能性があります。
一方で、基テーブル更新時のメンテナンスコストは増加します。
実務での注意点（制約・ロック・更新コスト）
インデックス付きビューは更新時にビューの結果も維持する必要があるため、INSERT/UPDATE/DELETEのコストが増えます。
また、定義に使える関数や構文には制約があり、柔軟性が下がる点に注意が必要です。
集計・分析の高速化が目的で、更新頻度が低いテーブルに対して適用するのが効果的です。
ビューの実務活用例
部門別売上ビューの作成例
ビジネス部門ごとに参照する列を最適化したビューを用意すると、現場ごとの要件に合わせた最小限のデータ公開が可能です。
CREATE VIEW dbo.vw_SalesForFinance AS
SELECT s.SaleDate, s.Amount, t.TaxRate
FROM dbo.Sales s
JOIN dbo.Tax t ON t.TaxId = s.TaxId;
CREATE VIEW dbo.vw_SalesForMarketing AS
SELECT s.SaleDate, s.Amount, c.Region, c.AgeGroup
FROM dbo.Sales s
JOIN dbo.Customers c ON c.CustomerId = s.CustomerId;
こうした分割により、部署別のダッシュボードやレポートが作りやすくなり、不要な列の露出を避けられます。
権限を制御するためのビュー設計
テーブルへの直接権限を与えず、ビューに対してSELECT権限のみを付与する設計は有効です。
行レベルの制御が必要な場合は、ログイン情報やユーザー属性で絞り込む条件をビュー定義に組み込みます。
さらに厳密な制御が必要なら、行レベルセキュリティ（Row-Level Security）との併用も検討します。
まとめ
ビューは、複雑なクエリの再利用、権限制御、メンテナンス性向上に寄与する強力な抽象化手段です。
まずはCREATE/ALTER/DROPの基本操作を押さえ、実務で繰り返し使うSELECTをビュー化してみましょう。
パフォーマンス課題が出た場合は、定義の簡素化やインデックス調整、必要に応じてインデックス付きビューの適用を検討します。
さらに高度な制御（WITH CHECK OPTION、SCHEMABINDINGなど）は応用編で扱う前提とし、まずは基礎を確実に身につけることが重要です。
参考リンク（Microsoft公式ドキュメント）
0 件のコメント:
コメントを投稿