次の方法で共有

CREATE VIEW (Transact-SQL)

  • [アーティクル]

クエリによって内容 (列と行) が定義される仮想テーブルを作成します。 このステートメントを使用すると、データベースの 1 つまたは複数のテーブル内のデータのビューを作成できます。 たとえば、ビューは、次の目的で使用できます。

  • 各ユーザーのデータベースに対する認識を特化、簡素化、およびカスタマイズする。

  • 基になるベース テーブルに直接アクセスする権限をユーザーに与えずに、ユーザーがビューを介してデータにアクセスできるように設定することにより、セキュリティのメカニズムとして使用する。

  • テーブルのスキーマが変更された場合に、そのテーブルをエミュレートするための後方互換性インターフェイスを提供する。

トピック リンク アイコン Transact-SQL 構文表記規則

構文

CREATE VIEW [ schema_name . ] view_name [ (column [ ,...n ] ) ] 
[ WITH <view_attribute> [ ,...n ] ] 
AS select_statement 
[ WITH CHECK OPTION ] [ ; ]

<view_attribute> ::= 
{
    [ ENCRYPTION ]
    [ SCHEMABINDING ]
    [ VIEW_METADATA ]     }

引数

  • schema_name
    ビューが所属するスキーマの名前を指定します。

  • view_name
    ビューの名前を指定します。 ビュー名は、識別子の規則に従っている必要があります。 ビューの所有者名の指定は省略可能です。

  • column
    ビューの列に付ける名前を指定します。 列名が必要なのは、算術式、関数、または定数から列を導いた場合と、名前を付けないと (通常、結合によって) 2 つ以上の列の名前が同じになる場合、および、ビュー内の列に派生元と異なる列名を付ける場合に限られます。 列名は、SELECT ステートメントで指定することもできます。

    column を指定しなかった場合は、SELECT ステートメントの列の名前が、このビューの列名として使用されます。

    注意注

    ビューの列では、列名に対する権限は、基底となるデータのソースがどこにあるかにかかわらず、CREATE VIEW ステートメントまたは ALTER VIEW ステートメントを超えて適用されます。 たとえば、CREATE VIEW ステートメントで SalesOrderID 列に対して権限が与えられる場合、ALTER VIEW ステートメントでは SalesOrderID 列に OrderRef などの異なる列名を付けることができ、その後も SalesOrderID を使用してビューに関連付けられた権限を保持します。

  • AS
    ビューが行う動作を指定します。

  • select_statement
    ビューを定義している SELECT ステートメントを指定します。 このステートメントでは、複数のテーブルや他のビューを使用することもできます。 作成するビューの SELECT 句で参照されるオブジェクトから選択するには、適切な権限が必要です。

    ビューは、1 つの特定のテーブルの行と列の簡単なサブセットである必要はありません。 複雑な SELECT 句で、複数のテーブルまたは他のビューを使用するビューを作成することもできます。

    インデックス付きビュー定義では、SELECT ステートメントは、単一のテーブル ステートメントまたは複数のテーブルの JOIN (集計は省略可) にする必要があります。

    ビュー定義の SELECT 句に、次の要素を含めることはできません。

    • ORDER BY 句。ただし、SELECT ステートメントの選択リストに TOP 句が同時に含まれている場合は例外です。

      重要な注意事項重要

      ORDER BY 句は、ビュー定義において TOP 句または OFFSET 句によって返される行を特定する場合にのみ使用されます。 クエリ自体にも ORDER BY を指定しない限り、ビューをクエリしたときに、ORDER BY 句で順序どおりの結果が得られるかどうかは保証されません。

    • INTO キーワード。

    • OPTION 句。

    • 一時テーブルまたはテーブル変数の参照。

    select_statement では SELECT ステートメントが使用されるため、FROM 句で指定される <join_hint> および <table_hint> の各ヒントを使用できます。 詳細については、「FROM (Transact-SQL)」および「SELECT (Transact-SQL)」を参照してください。

    select_statement では、関数と複数の SELECT ステートメントを UNION または UNION ALL で区切って使用できます。

  • CHECK OPTION
    ビューに対して実行されるすべてのデータ修正ステートメントについて、select_statement 内部で設定された条件に従うよう強制します。 ビューを介して行を変更する場合は、WITH CHECK OPTION を使用すると、変更がコミットされた後もビューを介して確実にデータを表示できます。

    注意注

    ビューの基になるテーブルに対して直接更新が実行された場合は、CHECK OPTION を指定してもビューに対する確認は行われません。

  • ENCRYPTION
    CREATE VIEW ステートメントのテキストが含まれている sys.syscomments のエントリを暗号化します。 WITH ENCRYPTION を使用すると、そのビューを SQL Server レプリケーションの一部としてパブリッシュできなくなります。

  • SCHEMABINDING
    基になるテーブルのスキーマにビューをバインドします。 SCHEMABINDING を指定した場合、ベース テーブルに対してビュー定義に影響を与えるような変更は行えません。 まずビュー定義を変更または削除して、変更するテーブルとの依存関係を解消する必要があります。 SCHEMABINDING を使用する場合は、select_statement に、参照されるテーブル、ビュー、またはユーザー定義関数の名前として、2 つの部分から構成される名前 (schema**.**object) を指定する必要があります。 参照されるオブジェクトは、すべて同じデータベース内にあることが必要です。

    SCHEMABINDING 句を指定して作成されたビューが削除または変更されて、スキーマ バインドがなくならない限り、そのビューに参加しているビューまたはテーブルは削除できません。 スキーマ バインドが残っている場合は、データベース エンジンからエラーが返されます。 また、ビュー定義に影響を与える ALTER TABLE ステートメントを、スキーマ バインドを持つビューに参加しているテーブルに対して実行すると、ステートメントは失敗します。

  • VIEW_METADATA
    ビューを参照するクエリ用にブラウズ モード メタデータが要求されている場合、SQL Server インスタンスは、DB-Library、ODBC、および OLE DB API に対して、ベース テーブルではなくビューに関するメタデータ情報を返します。 ブラウズ モード メタデータは、SQL Server インスタンスからクライアント側 API に返される追加のメタデータです。 クライアント側 API ではこのメタデータによって、更新可能なクライアント側カーソルを実装できます。 ブラウズ モード メタデータには、結果セット内の列が属するベース テーブルの情報が含まれています。

    VIEW_METADATA で作成したビューの場合、ブラウズ モード メタデータでは結果セット内のビューの列の説明で、ベース テーブル名ではなくビュー名が返されます。

    WITH VIEW_METADATA を使用してビューを作成するとき、timestamp 列を除くすべての列は、ビューに INSTEAD OF INSERT または INSTEAD OF UPDATE トリガーが含まれている場合に更新可能になります。 更新可能なビューの詳細については、「解説」を参照してください。

説明

ビューは現在のデータベースでのみ作成できます。 CREATE VIEW は、クエリ バッチの最初のステートメントであることが必要です。 1 つのビューで保持できる列の数は最大 1,024 です。

ビューからクエリを実行すると、データベース エンジンでは、ステートメントで参照されているデータベース オブジェクトがすべて存在すること、データベース オブジェクトがステートメントのコンテキストで有効であること、およびデータ変更ステートメントがデータの整合性規則に違反していないことが確認されます。 確認に失敗すると、エラー メッセージが返されます。 確認に成功すると、指定した動作が、基になるテーブルに対する動作に変換されます。

削除されたテーブル (またはビュー) に従属しているビューを使用すると、データベース エンジンではエラー メッセージが返されます。 テーブルの構造が以前のベース テーブルから変わっていなければ、削除されたテーブルやビューの代わりになる、新しいテーブルまたはビューを作成すると、ビューは再び使用可能になります。 新しいテーブルまたはビューの構造が変化した場合は、ビューを削除し、再作成する必要があります。

ビューが SCHEMABINDING 句を使用して作成したものでない場合、ビューの基になっているオブジェクトに対して、ビューの定義に影響するような変更が行われた際には、sp_refreshview を実行する必要があります。 この操作を行わないと、ビューの照会時に、予期しない結果が表示される可能性があります。

ビューを作成すると、ビューに関する情報がカタログ ビュー sys.views、sys.columns、および sys.sql_expression_dependencies に格納されます。 CREATE VIEW ステートメントのテキストは、sys.sql_modules カタログ ビューに格納されます。

numeric または float 型の式で定義されたビューのインデックスを使用するクエリでは、ビューのインデックスを使用しない同様のクエリとは異なる結果セットが返されます。 この相違は、基になるテーブルに対して INSERT、DELETE、または UPDATE 操作を行った場合の丸め誤差によって発生することがあります。

ビューを作成すると、データベース エンジンでは、SET QUOTED_IDENTIFIER と SET ANSI_NULLS の設定が保存されます。 これらの元の設定は、ビューの使用時に、ビューの解析で使用されます。 したがって、ビューへアクセスするとき、SET QUOTED_IDENTIFIER と SET ANSI_NULLS のクライアント セッションの設定によってビュー定義に影響が生じることはありません。

更新可能なビュー

次の条件を満たす場合、ビューから基になるデータベース テーブルのデータを変更できます。

  • UPDATE、INSERT、DELETE ステートメントなどの変更で、1 つのベース テーブルのみの列を参照している。

  • ビューにある変更対象の列が、テーブルの列内にある基になるデータを直接参照している。 ただし次のような方法では、列は派生されません。

    • 集計関数 (AVG、COUNT、SUM、MIN、MAX、GROUPING、STDEV、STDEVP、VAR、および VARP)。

    • 計算。 他の列を使用する式を基にして列を計算することはできません。 計算に相当する set 演算子 UNION、UNION ALL、CROSSJOIN、EXCEPT、INTERSECT を使用して形成される列も計算されません。

  • 変更される列が、GROUP BY、HAVING、または DISTINCT 句の影響を受けない。

  • ビューの select_statement 内で、TOP が WITH CHECK OPTION 句と共に使用されていない。

以前の制限は、ビュー自体に適用されるのと同様に、ビューの FROM 句のサブクエリにも適用されます。 通常は、データベース エンジンでは、ビュー定義からベース テーブルへの変更を正確にトレースできる必要があります。 詳細については、「ビューを使用したデータ変更」を参照してください。

以前の制約によってビューから直接データを変更できない場合は、次の方法を試してください。

  • INSTEAD OF トリガー

    ビューに INSTEAD OF トリガーを作成して、そのビューを更新可能にできます。 INSTEAD OF トリガーは、そのトリガーが定義されているデータ変更ステートメントの代わりに実行されます。 このトリガーで、データ変更ステートメントを処理する一連の操作を指定できます。 したがって、特定のデータ変更ステートメント (INSERT、UPDATE、または DELETE) に対する INSTEAD OF トリガーがビューに存在する場合は、そのステートメントを介して対応するビューを更新できます。 INSTEAD OF トリガーの詳細については、「DML トリガー」を参照してください。

  • パーティション ビュー

    ビューがパーティション ビューである場合は、いくつかの制限の範囲内で更新可能です。 必要に応じて、データベース エンジンでは、ローカル パーティション ビュー (参加しているすべてのテーブルとビューが同じ SQL Server インスタンス上にあるビュー) と分散パーティション ビュー (ビュー内の少なくとも 1 つのテーブルが別のサーバーまたはリモート サーバー上にあるビュー) が区別されます。

パーティション ビュー

パーティション ビューは、同じ構造のメンバー テーブルの UNION ALL によって定義されるビューです。ただし、これらのメンバー テーブルは、同じ SQL Server インスタンス内、または連合データベース サーバーと呼ばれる SQL Server サーバー インスタンスの独立したグループ内に、複数のテーブルとして個別に格納されます。

注意注

1 台のサーバーに対してローカルでデータをパーティション分割する方法としては、パーティション テーブルをお勧めします。 詳細については、「パーティション テーブルとパーティション インデックス」を参照してください。

パーティション分割構成の設計時には、各パーティションに所属するデータを明確にする必要があります。 たとえば、Customers テーブルのデータは、3 か所のサーバー上の 3 つのメンバー テーブル (Server1 の Customers_33、Server2 の Customers_66、Server3 の Customers_99) に分散されます。

Server1 のパーティション ビューは次のように定義されます。

--Partitioned view as defined on Server1
CREATE VIEW Customers
AS
--Select from local member table.
SELECT *
FROM CompanyData.dbo.Customers_33
UNION ALL
--Select from member table on Server2.
SELECT *
FROM Server2.CompanyData.dbo.Customers_66
UNION ALL
--Select from mmeber table on Server3.
SELECT *
FROM Server3.CompanyData.dbo.Customers_99;

一般に、次の形式のビューをパーティション ビューといいます。

SELECT <select_list1>
FROM T1
UNION ALL
SELECT <select_list2>
FROM T2
UNION ALL
...
SELECT <select_listn>
FROM Tn;

パーティション ビューを作成する条件

  1. 選択リスト (select list)

    • メンバー テーブルのすべての列は、ビュー定義の列リストで選択する必要があります。

    • それぞれの select list の同じ位置にある列は、照合順序も含めて同じ型であることが必要です。 列が暗黙的に変換される型であるという条件だけでは十分ではありません。これは UNION の場合とは異なります。

      また、すべての選択リストの同じ位置に、少なくとも 1 つの列 (たとえば <col>) が指定されている必要があります。 この <col> は、メンバー テーブル T1, ..., Tn の <col> にそれぞれ CHECK 制約 C1, ..., Cn を指定することで定義します。

      テーブル T1 の制約 C1 は、次の形式で定義する必要があります。

      C1 ::= < simple_interval > [ OR < simple_interval > OR ...]
< simple_interval > :: = 
< col > { < | > | <= | >= | = < value >} 
| < col > BETWEEN < value1 > AND < value2 >
| < col > IN ( value_list )
| < col > { > | >= } < value1 > AND
< col > { < | <= } < value2 >

    • これらの制約は、<col> に指定したすべての値が C1, ..., Cn の制約の 1 つにのみ該当するような形式にする必要があります。つまり、連続せずかつ重複しない間隔を持つ制約セットを形成するように定義します。 連続しない制約が定義されている列 <col> は、パーティション分割列と呼ばれます。 パーティション分割列は、基になるテーブルではそれぞれ異なる名前が付いている場合があります。 前に示したパーティション分割列の条件を満たすには、パーティション分割列に対して制約が有効かつ信頼されている必要があります。 制約が無効な場合は、ALTER TABLE の CHECK CONSTRAINT constraint_name オプションを使用して制約チェックを再度有効にし、WITH CHECK オプションを使用して制約を検証します。

      次は、有効な制約のセットの例です。

      { [col < 10], [col between 11 and 20] , [col > 20] }
{ [col between 11 and 20], [col between 21 and 30], [col between 31 and 100] }

    • 選択リストで同じ列を複数回使用することはできません。

  2. パーティション分割列

    • パーティション分割列は、テーブルの PRIMARY KEY の一部です。

    • 計算列、ID 列、既定の列、または timestamp 列に対して指定することはできません。

    • メンバー テーブルの 1 つの列に複数の制約が定義されている場合、データベース エンジンではすべての制約が無視され、ビューがパーティション ビューであるかどうかを判断する際にそれらの制約は考慮されません。 パーティション ビューの条件を満たすには、パーティション分割列にパーティション分割制約を 1 つだけ定義する必要があります。

    • パーティション分割列の更新可能性に制限はありません。

  3. メンバー テーブルまたは基になるテーブル T1, ..., Tn

    • テーブルは、ローカル テーブルまたは SQL Server が実行されている他のコンピューター上のテーブルのいずれかになります。他のコンピューター上のテーブルの場合は、4 つの要素で構成される名前か、OPENDATASOURCE ベースまたは OPENROWSET ベースの名前で参照されます。 OPENDATASOURCE および OPENROWSET の構文では、テーブル名は指定できますが、パススルー クエリは指定できません。 詳細については、「OPENDATASOURCE (Transact-SQL)」および「OPENROWSET (Transact-SQL)」を参照してください。

      1 つ以上のメンバー テーブルがリモートにある場合、そのビューは分散パーティション ビューと呼ばれ、さらに条件が適用されます。 これらの条件については後で説明します。

    • UNION ALL ステートメントで組み合わせるテーブルのセットに、同じテーブルを 2 回指定することはできません。

    • メンバー テーブルでは、テーブル内の計算列上にインデックスを作成することはできません。

    • メンバー テーブルでは、すべての PRIMARY KEY 制約が同じ数の列に対して定義されている必要があります。

    • ビューのすべてのメンバー テーブルには、同じ ANSI PADDING 設定を指定する必要があります。 これは、sp_configure の user options オプションまたは SET ステートメントを使用して設定できます。

パーティション ビューのデータを変更する条件

パーティション ビューのデータを変更するステートメントには、次の制限が適用されます。

  • INSERT ステートメントでは、基になるメンバー テーブルで列に DEFAULT 制約が定義されているか NULL 値が許容されている場合でも、ビューのすべての列に値を提供する必要があります。 メンバー テーブルの列に DEFAULT 定義がある場合、ステートメントではこれらの列に DEFAULT キーワードを使用できません。

  • パーティション分割列に挿入する値は、基になる制約の少なくとも 1 つを満たしている必要があります。満たしていない場合、INSERT 操作は制約違反で失敗します。

  • UPDATE ステートメントでは、対応するメンバー テーブルで列の DEFAULT 値が定義されている場合でも、SET 句の値として DEFAULT キーワードを指定することはできません。

  • ビューの列が、1 つ以上のメンバー テーブルで ID 列になっている場合、INSERT ステートメントまたは UPDATE ステートメントでこの列を変更することはできません。

  • メンバー テーブルのいずれかに timestamp 型の列が含まれている場合、データを INSERT または UPDATE ステートメントで変更することはできません。

  • メンバー テーブルに、トリガー、ON UPDATE CASCADE/SET NULL/SET DEFAULT 制約、または ON DELETE CASCADE/SET NULL/SET DEFAULT 制約が含まれている場合、ビューを変更することはできません。

  • ステートメント内に、同じビューまたはいずれかのメンバー テーブルとの自己結合が指定された場合、パーティション ビューに対して INSERT、UPDATE、および DELETE 操作は許可されません。

  • パーティション ビューへのデータの一括インポートは、bcp、または BULK INSERT および INSERT ... SELECT * FROM OPENROWSET(BULK...) ステートメントではサポートされていません。 しかし、INSERT ステートメントを使用することにより、パーティション ビューに複数の行を挿入できます。

    注意注

    パーティション ビューを更新するには、メンバー テーブルに対して INSERT、UPDATE、DELETE の各権限を持っている必要があります。

分散パーティション ビューの追加条件

分散パーティション ビュー (1 つ以上のメンバー テーブルがリモートの場合) では、次の追加条件が適用されます。

  • 更新によって影響を受けるすべてのノードにおいて原子性を保証するため、分散トランザクションが起動されます。

  • INSERT、UPDATE、または DELETE ステートメントが動作するには、XACT_ABORT SET オプションを ON に設定する必要があります。

  • パーティション ビューで参照されるリモート テーブルの smallmoney 型の列は、money としてマップされます。 このため、ローカル テーブルの対応する列 (選択リストの同じ順番にある列) も、money 型であることが必要です。

  • データベース互換性レベル 110 より下では、パーティション ビューで参照されるリモート テーブルの smalldatetime 型の列は、smalldatetime としてマップされます。 ローカル テーブルの対応する列 (選択リストの同じ順番にある列) は、smalldatetime であることが必要です。 この動作は、以前のバージョンの SQL Server から変更されています。以前のバージョンでは、パーティション ビューで参照されるリモート テーブルの smalldatetime 型の列は datetime としてマップされ、ローカル テーブルの対応する列は datetime 型であることが必要でした。 詳細については、「ALTER DATABASE 互換性レベル (Transact-SQL)」を参照してください。

  • パーティション ビューのリンク サーバーは、ループバック リンク サーバーとして使用できません。 ループバック リンク サーバーは、同じ SQL Server インスタンスを指すリンク サーバーです。

更新可能なパーティション ビューとリモート テーブルに関連する INSERT、UPDATE、DELETE 操作では、SET ROWCOUNT オプションの設定は無視されます。

メンバー テーブルとビュー定義が準備されると、SQL Server のクエリ オプティマイザーでは、クエリを効率的に使用してメンバー テーブルからデータにアクセスする高度なプランが構築されます。 クエリ プロセッサでは、CHECK 制約の定義を使用して、キー値の分布が複数のメンバー テーブルにマップされます。 ユーザーがクエリを実行すると、クエリ プロセッサでは、マップと WHERE 句で指定した値とが比較され、メンバー サーバー間のデータ転送が最も少なくなる実行プランが構築されます。 したがって、いくつかのメンバー テーブルがリモート サーバー上にある場合でも、SQL Server インスタンスでは転送の対象となる分散データの量が最も少なくなる方法で分散クエリが解決されます。

レプリケーションに関する注意点

レプリケーションに関係するメンバー テーブルのパーティション ビューを作成するには、次の点に注意してください。

  • 基になるテーブルが、更新サブスクライバーとのマージ レプリケーションまたはトランザクション レプリケーションに関係する場合、選択リストには uniqueidentifier 列も含まれる必要があります。

    パーティション ビューに対する INSERT 操作では、uniqueidentifier 列の NEWID() 値を指定する必要があります。 uniqueidentifier 列に対する UPDATE 操作では、DEFAULT キーワードを使用できないので、NEWID() を値として指定する必要があります。

  • ビューを使用した更新のレプリケーションは、2 つの異なるデータベースでのテーブルのレプリケーションと同じです。つまり、テーブルは異なるレプリケーション エージェントで管理されるため、更新の順序は保証されません。

権限

データベースの CREATE VIEW 権限と、ビューが作成されているスキーマの ALTER 権限が必要です。

使用例

A. 単純な CREATE VIEW を使用する

次の例では、単純な SELECT ステートメントを使用してビューを作成します。 単純なビューは、列の組み合わせを頻繁にクエリする場合に便利です。 このビューのデータは、AdventureWorks2012 データベースの HumanResources.Employee テーブルと Person.Person テーブルから取得されます。 このデータには、Adventure Works Cycles の従業員の名前と採用日の情報が含まれています。 従業員の勤続祝いの担当者用にビューを作成することができますが、この担当者はテーブルのすべてのデータにアクセスできるわけではありません。

USE AdventureWorks2012 ;
GO
IF OBJECT_ID ('hiredate_view', 'V') IS NOT NULL
DROP VIEW hiredate_view ;
GO
CREATE VIEW hiredate_view
AS 
SELECT p.FirstName, p.LastName, e.BusinessEntityID, e.HireDate
FROM HumanResources.Employee e 
JOIN Person.Person AS p ON e.BusinessEntityID = p.BusinessEntityID ;
GO

B. 暗号化を使用する

次の例では、WITH ENCRYPTION オプションを使用して、計算列、名前変更された列、複数列を表示します。

USE AdventureWorks2012 ;
GO
IF OBJECT_ID ('Purchasing.PurchaseOrderReject', 'V') IS NOT NULL
    DROP VIEW Purchasing.PurchaseOrderReject ;
GO
CREATE VIEW Purchasing.PurchaseOrderReject
WITH ENCRYPTION
AS
SELECT PurchaseOrderID, ReceivedQty, RejectedQty, 
    RejectedQty / ReceivedQty AS RejectRatio, DueDate
FROM Purchasing.PurchaseOrderDetail
WHERE RejectedQty / ReceivedQty > 0
AND DueDate > CONVERT(DATETIME,'20010630',101) ;
GO

C. WITH CHECK OPTION を使用する

次の例では、5 つのテーブルを参照する SeattleOnly というビューを表示し、シアトル在住の従業員だけにデータ変更を許可します。

USE AdventureWorks2012 ;
GO
IF OBJECT_ID ('dbo.SeattleOnly', 'V') IS NOT NULL
    DROP VIEW dbo.SeattleOnly ;
GO
CREATE VIEW dbo.SeattleOnly
AS
SELECT p.LastName, p.FirstName, e.JobTitle, a.City, sp.StateProvinceCode
FROM HumanResources.Employee e
    INNER JOIN Person.Person p
    ON p.BusinessEntityID = e.BusinessEntityID
    INNER JOIN Person.BusinessEntityAddress bea 
    ON bea.BusinessEntityID = e.BusinessEntityID 
    INNER JOIN Person.Address a 
    ON a.AddressID = bea.AddressID
    INNER JOIN Person.StateProvince sp 
    ON sp.StateProvinceID = a.StateProvinceID
WHERE a.City = 'Seattle'
WITH CHECK OPTION ;
GO

D. ビュー内部の組み込み関数を使用する

次の例では、組み込み関数を含むビュー定義を示しています。 関数を使用するときには、派生列に列名を指定する必要があります。

USE AdventureWorks2012 ;
GO
IF OBJECT_ID ('Sales.SalesPersonPerform', 'V') IS NOT NULL
    DROP VIEW Sales.SalesPersonPerform ;
GO
CREATE VIEW Sales.SalesPersonPerform
AS
SELECT TOP (100) SalesPersonID, SUM(TotalDue) AS TotalSales
FROM Sales.SalesOrderHeader
WHERE OrderDate > CONVERT(DATETIME,'20001231',101)
GROUP BY SalesPersonID;
GO

E. パーティション分割されたデータを使用する

次の例では、SUPPLY1、SUPPLY2、SUPPLY3、SUPPLY4 というテーブルを使用します。 これらのテーブルは、異なる国や地域にある 4 か所のオフィスの仕入れ先テーブルに対応しています。

--Create the tables and insert the values.
CREATE TABLE dbo.SUPPLY1 (
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 1 and 150),
supplier CHAR(50)
);
CREATE TABLE dbo.SUPPLY2 (
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 151 and 300),
supplier CHAR(50)
);
CREATE TABLE dbo.SUPPLY3 (
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 301 and 450),
supplier CHAR(50)
);
CREATE TABLE dbo.SUPPLY4 (
supplyID INT PRIMARY KEY CHECK (supplyID BETWEEN 451 and 600),
supplier CHAR(50)
);
GO
INSERT dbo.SUPPLY1 VALUES ('1', 'CaliforniaCorp'), ('5', 'BraziliaLtd');
INSERT dbo.SUPPLY2 VALUES ('231', 'FarEast'), ('280', 'NZ');
INSERT dbo.SUPPLY3 VALUES ('321', 'EuroGroup'), ('442', 'UKArchip');
INSERT dbo.SUPPLY4 VALUES ('475', 'India'), ('521', 'Afrique');
GO
--Create the view that combines all supplier tables.
CREATE VIEW dbo.all_supplier_view
WITH SCHEMABINDING
AS
SELECT supplyID, supplier
FROM dbo.SUPPLY1
UNION ALL
SELECT supplyID, supplier
FROM dbo.SUPPLY2
UNION ALL
SELECT supplyID, supplier
FROM dbo.SUPPLY3
UNION ALL
SELECT supplyID, supplier
FROM dbo.SUPPLY4;

関連項目

参照

ALTER TABLE (Transact-SQL)

ALTER VIEW (Transact-SQL)

DELETE (Transact-SQL)

DROP VIEW (Transact-SQL)

INSERT (Transact-SQL)

sys.dm_sql_referenced_entities (Transact-SQL)

sys.dm_sql_referencing_entities (Transact-SQL)

sp_help (Transact-SQL)

sp_helptext (Transact-SQL)

sp_refreshview (Transact-SQL)

sp_rename (Transact-SQL)

sys.views (Transact-SQL)

UPDATE (Transact-SQL)

EVENTDATA (Transact-SQL)

概念

ストアド プロシージャの作成