ビュー (SQL)

データベースにおいて、ビューとは、データベースの限定された観点をユーザーに提示する、保存されたクエリの結果セットです。 ^[1]この事前に確立されたクエリコマンドは、データディクショナリに保存されます。リレーショナルデータベースの通常のベーステーブルとは異なり、ビューは物理スキーマの一部を形成しません。結果セットとして、ビューは、そのビューへのアクセスが要求されたときにデータベースのデータから動的に計算または照合される仮想テーブルです。関連する基礎テーブルのデータに適用された変更は、^その後のビューの呼び出しで表示されるデータに反映されます。

ビューはテーブルに比べて次のような利点があります。

• ビューはテーブルに含まれるデータのサブセットを表すことができます。したがって、ビューは基礎となるテーブルが外部に公開される度合いを制限することができます。つまり、特定のユーザーにはビューを照会する権限が与えられますが、ベーステーブルの残りの部分へのアクセスは拒否される可能性があります。^[2]
• ビューは複数のテーブルを結合して単一の仮想テーブルに簡素化することができます。^[2]
• ビューは集計テーブルとして機能し、データベース エンジンがデータ (合計、平均など) を集計し、計算結果をデータの一部として表示します。
• ビューはデータの複雑さを隠すことができます。たとえば、ビューは Sales2020 または Sales2021 として表示され、実際の基になるテーブルが透過的にパーティション分割されます。
• ビューを保存するために必要なスペースはごくわずかです。データベースにはビューの定義のみが含まれ、ビューが提示するすべてのデータのコピーは含まれません。
• ビューは、さまざまなユーザーが自然かつ直感的に理解できるような方法でデータを構造化します。^[2]

関数(プログラミング)が抽象化を提供できるのと同様に、データベース ビューも抽象化を提供できます。関数と同様に、データベース ユーザーはネストされたビューを操作できるため、1 つのビューで他のビューからデータを集約できます。ビューを使用しないと、第 2 正規形を超えるデータベースの正規化ははるかに困難になります。ビューを使用すると、ロスレス結合分解を簡単に作成できます。

基本表の行に順序が定義されていないのと同様に、ビューを通じて使用可能な行もデフォルトのソート順では表示されません。ビューはリレーショナル表であり、リレーショナル モデルは表を行のセットとして定義します。セットは順序付けられていないため (定義により)、ビューの行も順序付けられていません。したがって、ビュー定義のORDER BY句は意味がありません。SQL 標準 ( SQL:2003 ) では、CREATE VIEW コマンドのサブクエリで ORDER BY 句が許可されておらず、CREATE TABLE ステートメントでも拒否されています。ただし、ソートされたデータは、他の表と同じように、そのビューのクエリステートメントの一部としてビューから取得できます。ただし、一部の DBMS ( Oracle Databaseなど) は、この SQL 標準の制限に従っていません。

ビューは、読み取り専用または更新可能として定義できます。データベース システムがビュー スキーマから基礎となるベース テーブルのスキーマへの逆マッピングを決定できる場合、ビューは更新可能です。 更新可能なビューでは、 INSERT、UPDATE、およびDELETE操作を実行できます。読み取り専用ビューでは、DBMS が基礎となるベース テーブルへの変更をマップできないため、このような操作はサポートされません。ビューの更新は、キー保存によって行われます。

一部のシステムでは、ビューでの INSTEAD OFトリガーの定義がサポートされています。この手法により、ビューでの挿入、更新、または削除操作の代わりに、他のロジックを定義できます。したがって、データベース システムは読み取り専用ビューに基づいてデータ変更を実装できます。ただし、INSTEAD OF トリガーは、ビュー自体の読み取り専用または更新可能なプロパティを変更しません。

さまざまなデータベース管理システムでは、データの読み取り専用サブセットからビューを拡張しており、特にマテリアライズド ビューは、データ ウェアハウスでよく使用される、事前に実行された非仮想ビューです。マテリアライズド ビューは、データの静的スナップショットを提供し、リモート ソースのデータが含まれる場合があります。マテリアライズド ビューの精度は、更新の背後にあるトリガー メカニズムの頻度によって異なります。

マテリアライズド ビューはOracle Databaseによって導入されましたが、IBM Db2 は同じ目的でいわゆる「マテリアライズド クエリ テーブル」(MQT) を提供しています。Microsoft SQL Server は2000 バージョンでインデックス ビューを導入しました。これはテーブルから個別のインデックスのみを格納し、データ全体を格納しません。PostgreSQLは9.3 リリースでマテリアライズド ビューを実装しました。

ビューは、そのソース クエリと同等です。ビューに対してクエリを実行すると、クエリが変更されます。たとえば、次のような内容の accounts_view という名前のビューが存在するとします。

-- accounts_view: 
------------- 
SELECT name 、money_received 、money_sent 、( money_received - money_sent ) AS balance 、address 、... FROM table_customers c JOIN accounts_table a ON a . customer_id = c . customer_id 
       
       
           
       
	   
     
     
       

アプリケーションは次のような単純なクエリを実行できます。

-- シンプルなクエリ
------------ 
SELECT name , balance FROM accounts_view 
       
   

次に、RDBMS は単純なクエリを受け取り、同等のビューを置き換えて、次のものをクエリ オプティマイザーに送信します。

-- 前処理されたクエリ: 
------------------ 
SELECT name , balance FROM ( SELECT name , money_received , money_sent , ( money_received - money_sent ) AS balance , address , ... FROM table_customers c JOIN accounts_table a ON a . customer_id = c . customer_id ) 
       
    
               
               
                   
               
			    
               
                          

次に、オプティマイザーは不要なフィールドと複雑さを削除し (たとえば、親呼び出しではアドレスが使用されないため、アドレスを読み取る必要はありません)、クエリを SQL エンジンに送信して処理します。

• 双方向化