CREATE VIEW (Transact-SQL)

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW) SQL-Analyseendpunkt in Microsoft Fabric Warehouse in Microsoft Fabric SQL-Datenbank in Microsoft Fabric

Erstellt eine virtuelle Tabelle, deren Inhalt (Spalten und Zeilen) durch eine Abfrage definiert wird. Verwenden Sie diese Anweisung, um in einer oder mehreren Tabellen in der Datenbank eine Sicht der Daten zu erstellen. Eine Sicht kann z. B. für folgende Zwecke verwendet werden:

• Um die Darstellung einer Datenbank für jeden einzelnen Benutzer einzuschränken, zu vereinfachen und anzupassen.

• Als Sicherheitsmechanismus, indem Benutzern der Zugriff auf Daten über die Sicht ermöglicht wird, ohne diesen Benutzern jedoch die Berechtigungen für den direkten Zugriff auf die zugrunde liegenden Basistabellen zu gewähren.

• Um eine abwärtskompatible Schnittstelle zum Emulieren einer Tabelle bereitzustellen, deren Schema geändert wurde.

Transact-SQL-Syntaxkonventionen

Syntax

Syntax für SQL Server und Azure SQL-Datenbank

CREATE [ OR ALTER ] VIEW [ schema_name . ] view_name [ (column [ ,...n ] ) ]
[ WITH <view_attribute> [ ,...n ] ]
AS select_statement
[ WITH CHECK OPTION ]
[ ; ]  
  
<view_attribute> ::=
{  
    [ ENCRYPTION ]  
    [ SCHEMABINDING ]  
    [ VIEW_METADATA ]
}

Syntax für Azure Synapse Analytics und Parallel Data Warehouse.

CREATE VIEW [ schema_name . ] view_name [  ( column_name [ ,...n ] ) ]   
AS <select_statement>   
[;]  
  
<select_statement> ::=  
    [ WITH <common_table_expression> [ ,...n ] ]  
    SELECT <select_criteria>  

Syntax für Microsoft Fabric Warehouse- und SQL-Analyseendpunkt.

CREATE [ OR ALTER ] VIEW [ schema_name . ] view_name [  ( column_name [ ,...n ] ) ]   
[ WITH <view_attribute> [ ,...n ] ] AS <select_statement>   
[;]

<view_attribute> ::=
{  
    [ SCHEMABINDING ]  
}
  
<select_statement> ::=  
    [ WITH <common_table_expression> [ ,...n ] ]  
    SELECT <select_criteria>  

Argumente

OR ALTER

Gilt für: Azure SQL-Datenbank und SQL Server (ab SQL Server 2016 (13.x) SP1).

Ändert die Sicht nur, sofern diese bereits vorhanden ist.

schema_name
Ist der Name des Schemas, zu dem die Sicht gehört.

view_name
Der Name der Sicht. Sichtnamen müssen den Regeln für Bezeichner entsprechen. Das Angeben des Sichtbesitzernamens ist optional.

column
Der Name, den eine Spalte in einer Sicht erhalten soll. Das Angeben eines Spaltennamens ist nur erforderlich, wenn eine Spalte von einem arithmetischen Ausdruck, einer Funktion oder einer Konstanten abgeleitet wird oder wenn zwei oder mehr Spalten sonst denselben Namen haben können (gewöhnlich aufgrund eines Joins) oder aber wenn für die Spalte in einer Sicht ein anderer Name angegeben ist als die Spalte, von der sie abgeleitet wurde. Spaltennamen können auch in der SELECT-Anweisung zugewiesen werden.

Wenn column nicht angegeben ist, erhalten die Spalten der Sicht dieselben Namen wie die in der SELECT-Anweisung angegebenen Spalten.

Hinweis

In den Spalten für die Sicht gelten die Berechtigungen für einen Spaltennamen über eine CREATE VIEW- oder ALTER VIEW-Anweisung hinaus, unabhängig von der Quelle der zugrunde liegenden Daten. Wenn beispielsweise Berechtigungen für die SalesOrderID-Spalte in einer CREATE VIEW-Anweisung erteilt werden, kann die SalesOrderID-Spalte beispielsweise zu OrderRef mithilfe einer ALTER VIEW-Anweisung umbenannt werden und weiterhin über die mithilfe von SalesOrderID der Sicht zugeordneten Berechtigungen verfügen.

AS

Gibt die Aktionen an, die die Sicht ausführen soll.

select_statement
Die SELECT-Anweisung, die die Sicht definiert. In der Anweisung dürfen mehrere Tabellen und andere Sichten angegeben werden. Sie müssen über die entsprechenden Berechtigungen verfügen, um aus den Objekten auszuwählen, auf die in der SELECT-Klausel der erstellten Sicht verwiesen wird.

Eine Sicht muss nicht unbedingt eine einfache Teilmenge der Zeilen und Spalten einer bestimmten Tabelle sein. Mithilfe einer SELECT-Klausel beliebiger Komplexität kann auch eine Sicht erstellt werden, die mehr als eine Tabelle oder andere Sichten verwendet.

In einer indizierten Sichtdefinition muss die SELECT-Anweisung aus einer nur eine Tabelle betreffenden Anweisung oder aus einer sich über mehrere Tabellen erstreckenden JOIN-Anweisung mit optionaler Aggregation bestehen.

In der SELECT-Klausel einer Sichtdefinition darf Folgendes nicht enthalten sein:

• Eine ORDER BY-Klausel, es sei denn, eine TOP-Klausel ist in der Auswahlliste der SELECT-Anweisung vorhanden

  Wichtig

  Die ORDER BY-Klausel wird lediglich zur Ermittlung der Zeilen verwendet, die von der TOP- oder OFFSET-Klausel in der Sichtdefinition zurückgegeben werden. Durch die ORDER BY-Klausel wird keine bestimmte Ergebnisreihenfolge bei der Abfrage der Sicht sichergestellt, es sei denn, in der Abfrage selbst ist ebenfalls ORDER BY angegeben.

• Das INTO-Schlüsselwort

• Die OPTION-Klausel

• Ein Verweis auf eine temporäre Tabelle oder auf eine Tabellenvariable

Da select_statement die SELECT-Anweisung verwendet, ist es zulässig, die Hinweise <join_hint> und <table_hint> zu verwenden, wie in der FROM-Klausel angegeben. Weitere Informationen finden Sie unter FROM (Transact-SQL) und SELECT (Transact-SQL).

In select_statement können Funktionen und mehrere SELECT-Anweisungen verwendet werden, die durch UNION oder UNION ALL getrennt sind.

CHECK OPTION

Erzwingt, dass alle für die Sicht ausgeführten Datenänderungsanweisungen den Kriterien entsprechen müssen, die innerhalb von select_statement festgelegt wurden. Wenn durch eine Sicht eine Zeile geändert wird, stellt WITH CHECK OPTION sicher, dass die Daten nach dem Ausführen eines Commits für die Änderung in der Sicht weiterhin angezeigt werden.

Hinweis

Die Klausel CHECK OPTION gilt nur für Updates, die über die Ansicht vorgenommen werden. Sie gilt nicht für Updates, die direkt für die zugrunde liegenden Tabellen einer Ansicht durchgeführt werden.

ENCRYPTION

Gilt für: SQL Server 2008 (10.0.x) und höher sowie Azure SQL-Datenbank.

Verschlüsselt die Einträge in sys.syscomments, die den Text der CREATE VIEW-Anweisung enthalten. Mit WITH ENCRYPTION kann verhindert werden, dass die Sicht als Teil der SQL Server-Replikation veröffentlicht wird.

SCHEMABINDING

Bindet die Sicht an das Schema der zugrunde liegenden Basistabellen. Wenn SCHEMABINDING angegeben ist, können an der/den Basistabelle(n) keine Änderungen vorgenommen werden, die die Sichtdefinition betreffen können. Zunächst muss die Sichtdefinition selbst geändert oder gelöscht werden, um Abhängigkeiten in der zu ändernden Tabelle zu entfernen. Wenn Sie SCHEMABINDING verwenden, muss select_statement die zweiteiligen Namen (schema.object) der Tabellen, Sicht oder benutzerdefinierten Funktionen einschließen, auf die verwiesen wird. Alle Objekte, auf die verwiesen wird, müssen in derselben Datenbank vorhanden sein.

Sichten oder Tabellen, die Bestandteil einer mit der SCHEMABINDING-Klausel erstellten Sicht sind, können erst dann gelöscht werden, wenn diese Sicht gelöscht oder geändert wurde, sodass keine Schemabindung mehr vorhanden ist. Andernfalls löst Datenbank-Engine einen Fehler aus. Darüber hinaus schlagen ALTER TABLE-Anweisungen für Tabellen fehl, die Bestandteil von Sichten mit Schemabindung sind, wenn diese Anweisungen die Sichtdefinition betreffen.

Hinweis

In Azure Synapse Analytics unterstützen Sichten derzeit keine Schemabindung. Weitere Informationen finden Sie unter T-SQL-Sichten mit dediziertem SQL-Pool und serverlosem SQL-Pool in Azure Synapse Analytics.

VIEW_METADATA

Gibt an, dass die Instanz von SQL Server die Metadateninformationen der Sicht anstelle der Basistabelle(n) an die DB-Library-, ODBC- und OLE DB-APIs zurückgibt, wenn Metadaten des Durchsuchenmodus für eine Abfrage angefordert werden, die auf die Sicht verweist. Bei Metadaten des Durchsuchenmodus handelt es sich um zusätzliche Metadaten, die von der Instanz von SQL Server an diese clientseitigen APIs zurückgegeben werden. Mithilfe dieser Metadaten können die clientbasierten APIs aktualisierbare clientbasierte Cursors implementieren. Metadaten des Durchsuchenmodus enthalten Informationen zu der Basistabelle, zu der die Spalten im Resultset gehören.

Bei Sichten, die mit VIEW_METADATA erstellt wurden, geben die Metadaten des Durchsuchenmodus den Sichtnamen anstelle der Basistabellennamen zurück, wenn Spalten aus der Sicht im Resultset beschrieben werden.

Wenn eine Sicht mit WITH VIEW_METADATA erstellt wird, sind alle enthaltenen Spalten außer der Spalte timestamp aktualisierbar, wenn die Sicht den Trigger INSTEAD OF INSERT oder INSTEAD OF UPDATE aufweist. Weitere Informationen zu aktualisierbaren Sichten finden Sie unter Hinweise.

Bemerkungen

Eine Sicht kann nur in der aktuellen Datenbank erstellt werden. Bei CREATE VIEW muss es sich um die erste Anweisung in einem Abfragebatch handeln. Für eine Sicht sind maximal 1.024 Spalten zulässig.

Wenn eine Abfrage für eine Sicht durchgeführt wird, überprüft Datenbank-Engine, ob alle Datenbankobjekte, auf die in der Anweisung verwiesen wird, vorhanden sind, ob sie im Kontext der Anweisung gültig sind und ob Datenänderungsanweisungen gegen die Regeln der Datenintegrität verstoßen. Schlägt eine Überprüfung fehl, wird eine Fehlermeldung zurückgegeben. Andernfalls wird die Aktion in eine Aktion für die zugrunde liegende Tabelle bzw. Tabellen übersetzt.

Wenn eine Sicht von einer Tabelle oder Sicht abhängt, die gelöscht wurde, erzeugt Datenbank-Engine eine Fehlermeldung, wenn jemand versucht, die Sicht zu verwenden. Wenn eine neue Tabelle oder Sicht, deren Struktur sich nicht von der vorherigen Basistabelle unterscheidet, erstellt wird, um die gelöschte zu ersetzen, wird die Sicht wieder verwendbar. Wenn sich die Struktur der neuen Tabelle oder Sicht ändert, muss die Sicht gelöscht und neu erstellt werden.

Wenn eine Sicht nicht mit der SCHEMABINDING-Klausel erstellt wurde, führen Sie sp_refreshview aus, nachdem Änderungen an den der Sicht zugrunde liegenden Objekten vorgenommen wurden, die die Definition der Sicht betreffen. Andernfalls liefert die Abfrage der Sicht möglicherweise unerwartete Ergebnisse.

Beim Erstellen einer Sicht werden die Informationen zu dieser in den folgenden Katalogsichten gespeichert: sys.views, sys.columns und sys.sql_expression_dependencies. Der Text der CREATE VIEW-Anweisung wird in der Katalogsicht sys.sql_modules gespeichert.

Das Ergebnis einer Abfrage, die einen Index für eine mit den Ausdrücken numeric oder float definierte Sicht verwendet, kann sich von einer ähnlichen Abfrage unterscheiden, die nicht den Index für die Sicht verwendet. Dieser Unterschied kann durch Rundungsfehler während INSERT-, DELETE- oder UPDATE-Aktionen in den zugrunde liegenden Tabellen verursacht werden.

Datenbank-Engine speichert die Einstellungen für SET QUOTED_IDENTIFIER und SET ANSI_NULLS, wenn eine Sicht erstellt wird. Diese Originaleinstellungen werden zum Analysieren der Sicht wiederhergestellt, wenn die Sicht verwendet wird. Deshalb haben alle Clientsitzungseinstellungen für SET QUOTED_IDENTIFIER und SET ANSI_NULLS keine Auswirkungen auf die Sichtdefinition, wenn auf die Sicht zugegriffen wird.

In der Fabric SQL-Datenbank können Ansichten erstellt werden, sie werden jedoch nicht in die Fabric OneLake gespiegelt. Weitere Informationen finden Sie unter Einschränkungen der Fabric SQL-Datenbankspiegelung.

Aktualisierbare Sichten

In Azure Synapse Analytics werden derzeit aktualisierbare Ansichten, DML-Trigger (vom Typ AFTER oder INSTEAD OF) und partitionierte Ansichten nicht unterstützt. Weitere Informationen finden Sie unter T-SQL-Sichten mit dediziertem SQL-Pool und serverlosem SQL-Pool in Azure Synapse Analytics.

Sie können die Daten einer zugrunde liegenden Basistabelle über eine Sicht ändern, wenn die folgenden Bedingungen erfüllt sind:

• Alle Änderungen, einschließlich UPDATE-, INSERT- und DELETE-Anweisungen, dürfen nur von einer Basistabelle aus auf Spalten verweisen.

• Die Spalten, die in der Sicht geändert werden, müssen direkt auf die zugrunde liegenden Daten der Tabellenspalten verweisen. Die Spalten können nicht auf andere Art abgeleitet werden, wie etwa über:

  • Eine Aggregatfunktion: AVG, COUNT, SUM, MIN, MAX, GROUPING, STDEV, STDEVP, VAR und VARP.

  • Eine Berechnung. Die Spalte kann mit einem Ausdruck, der andere Spalten verwendet, nicht berechnet werden. Spalten, die mithilfe der Mengenoperatoren UNION, UNION ALL, CROSSJOIN, EXCEPT und INTERSECT erstellt werden, werden berechnet und sind daher auch nicht aktualisierbar.

• Die geänderten Spalten sind von den GROUP BY-, HAVING- oder DISTINCT-Klauseln nicht betroffen.

• In der Anweisung select_statement der Sicht wird TOP nicht zusammen mit der Klausel WITH CHECK OPTION verwendet.

Die vorigen Einschränkungen gelten, so wie für die Sicht selbst, für alle Unterabfragen in der FROM-Klausel der Sicht. Im Allgemeinen muss Datenbank-Engine Änderungen von der Sichtdefinition an einer Basistabelle eindeutig nachverfolgen können. Weitere Informationen finden Sie unter Modify Data Through a View (Ändern von Daten über eine Sicht).

Wenn Sie aufgrund der vorigen Einschränkungen die Daten nicht direkt über eine Sicht ändern können, sollten Sie die folgenden Optionen berücksichtigen:

• INSTEAD OF-Trigger

  Für eine Sicht können INSTEAD OF-Trigger erstellt werden, um sie aktualisierbar zu machen. Der INSTEAD OF-Trigger wird anstelle der Datenänderungsanweisung ausgeführt, für die der Trigger definiert ist. Mithilfe dieses Triggers kann der Benutzer die Gruppe von Aktionen angeben, die erforderlich sind, um die Datenänderungsanweisung zu verarbeiten. Wenn also ein INSTEAD OF-Trigger einer Sicht für eine angegebene Datenänderungsanweisung (INSERT, UPDATE oder DELETE) vorhanden ist, ist die entsprechende Sicht über diese Anweisung aktualisierbar. Weitere Informationen zu INSTEAD OF-Triggern finden Sie unter DML-Trigger.

• Partitionierte Sichten

  Wenn es sich bei der Sicht um eine partitionierte Sicht handelt, ist sie mit gewissen Einschränkungen aktualisierbar. Bei Bedarf unterscheidet Datenbank-Engine zwischen lokalen partitionierten Sichten (als Sichten, bei denen sich alle beteiligten Tabellen und die jeweilige Sicht selbst auf derselben SQL Server-Instanz befinden) und verteilten partitionierten Sichten (als Sichten, bei denen sich mindestens eine der Tabellen auf einem anderen Server oder Remoteserver befindet).

Partitionierte Sichten

Hinweis

In Azure Synapse Analytics werden derzeit partitionierte Ansichten nicht unterstützt. Weitere Informationen finden Sie unter T-SQL-Sichten mit dediziertem SQL-Pool und serverlosem SQL-Pool in Azure Synapse Analytics.

Bei einer partitionierten Sicht handelt es sich um eine Sicht, die durch eine UNION ALL-Anweisung von Mitgliedstabellen definiert ist, die dieselbe Struktur aufweisen, jedoch getrennt voneinander in mehreren Tabellen entweder in derselben Instanz von SQL Server oder in einer Gruppe von eigenständigen Instanzen von SQL Server-Servern gespeichert sind, die vereinte Datenbankserver genannt werden.

Hinweis

Die bevorzugte Methode zum lokalen Partitionieren von Daten auf einem Server ist die mithilfe partitionierter Tabellen. Weitere Informationen finden Sie unter partitionierte Tabellen und Indizes.

Beim Entwurf eines Partitionierungsschemas muss offensichtlich sein, welche Daten zu den einzelnen Partitionen gehören. Die Daten der Customers-Tabelle sind beispielsweise auf drei Mitgliedstabellen an drei Serverstandorten verteilt: Customers_33 auf Server1, Customers_66 auf Server2 und Customers_99 auf Server3.

Eine partitionierte Sicht auf Server1 wird wie folgt definiert:

--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 member table on Server3.  
SELECT *  
FROM Server3.CompanyData.dbo.Customers_99;  

Im Allgemeinen gilt eine Sicht als partitioniert, wenn sie die folgende Form aufweist:

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

Bedingungen für das Erstellen von partitionierten Sichten

1. Die SELECT-list

   • In der Spaltenliste der Sichtdefinition wählen Sie alle Spalten der Mitgliedstabellen aus.

   • Stellen Sie sicher, dass die Spalten an derselben Ordnungsposition jeder select list denselben Typ aufweisen, einschließlich Sortierungen. Es ist nicht ausreichend, wenn die Spalten implizit konvertierbar sind, wie dies für UNION generell der Fall ist.

     Demnach muss mindestens eine Spalte (z. B. <col>) in allen SELECT-Listen an derselben Ordnungsposition vorhanden sein. Definieren Sie <col> so, dass die Mitgliedstabellen T1, ..., Tn über CHECK-Einschränkungen C1, ..., Cn verfügen, die entsprechend in <col> definiert sind.

     Die für C1 definierte Einschränkung T1 muss die folgende Form haben:

     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 >  
     

   • Die Einschränkungen müssen so festgelegt sein, dass jeder angegebene Wert von <col> höchstens eine der Einschränkungen C1, ..., Cn erfüllt, sodass die Einschränkungen eine Gruppe von getrennten oder nicht überlappenden Intervallen bilden. Die <col>-Spalte, für die die getrennten Einschränkungen definiert sind, wird Partitionierungsspalte genannt. Beachten Sie, dass die Partitionierungsspalte in den zugrunde liegenden Tabellen unterschiedliche Namen haben kann. Die Einschränkungen müssen sich im enabled- und trusted-Status befinden, damit sie die zuvor genannten Bedingungen für die Partitionierungsspalte erfüllen. Wenn die Einschränkungen deaktiviert sind, aktivieren Sie die Einschränkungsprüfung erneut mit der Option CHECK CONSTRAINT constraint_name von ALTER TABLE. Verwenden Sie die Option WITH CHECK, um die Einschränkungen zu überprüfen.

     Die folgenden Beispiele zeigen gültige Einschränkungsgruppen:

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

   • Die mehrfache Verwendung einer Spalte in der Auswahlliste ist nicht zulässig.

2. Partitionierungsspalte

   • Die Partitionierungsspalte ist Teil der PRIMARY KEY-Einschränkung der Tabelle.

   • Eine berechnete Spalte, eine Identitätspalte, eine Standardspalte oder eine timestamp-Spalte darf hierfür nicht verwendet werden.

   • Wenn es für eine Spalte einer Mitgliedstabelle mehrere Einschränkungen gibt, ignoriert die Datenbank-Engine alle diese Einschränkungen und berücksichtigt sie nicht, wenn ermittelt wird, ob die Sicht eine partitionierte Sicht ist. Damit die Bedingungen für partitionierte Sichten erfüllt werden, stellen Sie sicher, dass es für die Partitionierungsspalte nur eine Partitionierungseinschränkung gibt.

   • Für Partitionierungsspalten gelten keine Einschränkungen hinsichtlich der Aktualisierbarkeit.

3. Mitgliedstabellen oder zugrunde liegende Tabellen T1, ..., Tn

   • Bei den Tabellen kann es sich entweder um lokale Tabellen oder um Tabellen von anderen Computern handeln, auf denen SQL Server ausgeführt wird, auf die entweder über einen vierteiligen Namen oder einen OPENDATASOURCE- oder OPENROWSET-basierten Namen verwiesen wird. Die OPENDATASOURCE- und OPENROWSET-Syntax kann zwar einen Tabellennamen angeben, nicht jedoch eine Pass-Through-Abfrage. Weitere Informationen finden Sie unter OPENDATASOURCE (Transact-SQL) und OPENROWSET (Transact-SQL).

     Falls eine oder mehrere Mitgliedstabellen Remotetabellen sind, wird die Sicht verteilte partitionierte Sicht genannt, und es gelten zusätzliche Bedingungen. Diese werden weiter unten in diesem Abschnitt beschrieben.

   • Eine Tabelle darf nicht zweimal in der Tabellengruppe enthalten sein, die mithilfe der UNION ALL-Anweisung kombiniert werden.

   • Die Mitgliedstabellen dürfen nicht über Indizes verfügen, die für berechnete Spalten der Tabelle erstellt werden.

   • Für alle Mitgliedstabellen gilt, dass ihre PRIMARY KEY-Einschränkungen auf gleich vielen Spalten basieren.

   • Alle Mitgliedstabellen einer Sicht weisen dieselbe Einstellung für die ANSI-Auffüllung auf. Diese Einstellung kann entweder mit der Option Benutzeroptionen in sp_configure oder mit der SET-Anweisung festgelegt werden.

Bedingungen für das Ändern von Daten in partitionierten Sichten

Die folgenden Einschränkungen gelten für Anweisungen, die Daten in partitionierten Sichten ändern:

• Die INSERT-Anweisung stellt für alle Spalten in der Sicht Werte bereit, auch wenn die zugrunde liegenden Mitgliedstabellen über eine DEFAULT-Einschränkung für diese Spalten verfügen oder NULL-Werte zulassen. Für diese Spalten in der Mitgliedstabelle, die über DEFAULT-Definitionen verfügen, können die Anweisungen nicht explizit das DEFAULT-Schlüsselwort verwenden.

• Der in die Partitionierungsspalte eingefügte Wert erfüllt mindestens eine der zugrunde liegenden Einschränkungen. Andernfalls schlägt die INSERT-Aktion mit einer Einschränkungsverletzung fehl.

• In einer UPDATE-Anweisung darf das Schlüsselwort DEFAULT nicht als Wert in der SET-Klausel angegeben werden. Dies gilt selbst dann, wenn in der entsprechenden Mitgliedstabelle ein DEFAULT-Wert definiert ist.

• Die in der Sicht enthaltenen Spalten, bei denen es sich um eine IDENTITY-Spalte in einer oder mehreren Mitgliedstabellen handelt, können nicht mit der INSERT- oder UPDATE-Anweisung geändert werden.

• Wenn eine der Mitgliedstabellen eine timestamp-Spalte enthält, können die Daten nicht durch eine INSERT- oder UPDATE-Anweisung geändert werden.

• Wenn eine der Mitgliedstabellen einen Trigger oder eine ON UPDATE CASCADE/SET NULL/SET DEFAULT- oder ON DELETE CASCADE/SET NULL/SET DEFAULT-Einschränkung hat, kann die Sicht nicht geändert werden.

• INSERT-, UPDATE- und DELETE-Aktionen für eine partitionierte Sicht sind nicht zulässig, wenn ein Selbstjoin mit derselben Sicht oder mit einer der Mitgliedstabelle in der Anweisung vorhanden ist.

• Der Massenimport von Daten in eine partitionierte Sicht wird nicht unterstützt, wenn bcp, BULK INSERT oder INSERT ... SELECT * FROM OPENROWSET(BULK...)-Anweisungen per Massenimport übertragen werden. Sie können mit der INSERT-Anweisung jedoch mehrere Zeilen in eine partitionierte Sicht einfügen.

  Hinweis

  Zum Aktualisieren einer partitionierten Sicht benötigt der Benutzer INSERT-, UPDATE- und DELETE-Berechtigungen für die Mitgliedstabellen.

Zusätzliche Bedingungen für verteilte partitionierte Sichten

Für verteilte partitionierte Sichten (bei denen eine oder mehrere Mitgliedstabellen Remotetabellen sind), gelten zusätzlich die folgenden Bedingungen:

• Eine verteilte Transaktion wird gestartet, um die Unteilbarkeit bei allen durch die Aktualisierung betroffenen Knoten sicherzustellen.

• Legen Sie die Option XACT_ABORT SET auf ON fest, damit INSERT-, UPDATE- oder DELETE-Anweisungen funktionieren.

• Alle Spalten in Remotetabellen des Typs smallmoney, auf die in einer partitionierten Sicht verwiesen wird, werden als money zugeordnet. Daher müssen die entsprechenden Spalten (in der gleichen Ordnungsposition in der Auswahlliste) in den lokalen Tabellen auch den Typ money aufweisen.

• Unter Datenbankkompatibilitätsgrad 110 und höher werden alle Spalten in Remotetabellen vom Typ smalldatetime, auf die in einer partitionierten Sicht verwiesen wird, als smalldatetime zugeordnet. Entsprechende Spalten in den lokalen Tabellen (in derselben Ordnungsposition in der Auswahlliste) müssen den Typ smalldatetime aufweisen. Dies ist eine Änderung des Verhaltens früherer Versionen von SQL Server, in denen sämtliche Spalten in Remotetabellen vom Typ smalldatetime, auf die in einer partitionierten Sicht verwiesen wird, als datetime zugeordnet werden. Die entsprechenden Spalten in lokalen Tabellen müssen den Typ datetime aufweisen. Weitere Informationen finden Sie unter ALTER DATABASE-Kompatibilitätsgrad (Transact-SQL).

• Ein an der partitionierten Sicht beteiligter Verbindungsserver kann kein Loopback-Verbindungsserver sein. Dies ist ein Verbindungsserver, der auf dieselbe Instanz von SQL Server verweist.

Die Einstellung der Option SET ROWCOUNT wird für INSERT-, UPDATE- und DELETE-Aktionen ignoriert, die aktualisierbare partitionierte Sichten und Remotetabellen betreffen.

Wenn die Mitgliedstabellen und die partitionierte Sichtdefinition vorhanden sind, erstellt der SQL Server-Abfrageoptimierer intelligente Pläne, die Abfragen zum effizienten Zugriff auf Daten in den Mitgliedstabellen verwenden. Mit den CHECK-Einschränkungsdefinitionen kann der Abfrageprozessor die Verteilung der Schlüsselwerte den Mitgliedstabellen zuordnen. Wenn ein Benutzer eine Abfrage ausgibt, vergleicht der Abfrageprozessor die Zuordnung mit den in der WHERE-Klausel angegebenen Werten und erstellt einen Ausführungsplan, für den nur eine minimale Menge an Daten zwischen den Mitgliedsservern übertragen werden muss. Obwohl einige Mitgliedstabellen möglicherweise auf Remoteservern gespeichert sind, löst die Instanz von SQL Server daher verteilte Abfragen so auf, dass nur eine minimale Menge von verteilten Daten übertragen werden muss.

Überlegungen zur Replikation

Die folgenden Überlegungen sind erforderlich, wenn Sie partitionierte Sichten für Mitgliedstabellen erstellen, die an der Replikation beteiligt sind:

• Wenn die zugrunde liegenden Tabellen an der Merge- oder Transaktionsreplikation mit Updateabonnements beteiligt sind, stellen Sie sicher, dass die Spalte uniqueidentifier ebenfalls in der Auswahlliste enthalten ist.

  Alle INSERT-Aktionen für die partitionierte Sicht müssen einen NEWID()-Wert für die Spalte uniqueidentifier bereitstellen. Alle UPDATE-Aktionen für die Spalte uniqueidentifier müssen NEWID() als Wert bereitstellen, da das DEFAULT-Schlüsselwort nicht verwendet werden kann.

• Die Replikation von Updates, die mithilfe der Sicht ausgeführt werden, entspricht der Replikation von Tabellen in zwei verschiedenen Datenbanken: Die Tabellen werden von unterschiedlichen Replikations-Agents bedient, und die Reihenfolge der Updates ist nicht sichergestellt.

Berechtigungen

Erfordert die CREATE VIEW-Berechtigung in der Datenbank und die ALTER-Berechtigung für das Schema, in dem die Sicht erstellt wird.

Beispiele

In den folgenden Beispielen wird die AdventureWorks2022 oder AdventureWorksDW2022-Datenbank verwendet.

A. Verwenden einer einfachen CREATE VIEW-Anweisung

Im folgenden Beispiel wird mithilfe einer einfachen SELECT-Anweisung eine Sicht erstellt. Eine einfache Sicht ist hilfreich, wenn eine Kombination mehrerer Spalten häufig abgefragt wird. Die Daten dieser Sicht stammen aus den HumanResources.Employee- und Person.Person-Tabellen der AdventureWorks2022-Datenbank. Mit diesen Daten werden Name und Einstellungsdatum der Mitarbeiter von Adventure Works Cycles bereitgestellt. Die Sicht könnte für die Person erstellt werden, die für die Nachverfolgung von Jubiläen verantwortlich ist. Dabei wird dieser Person nicht der Zugriff auf alle Daten dieser Tabellen gewährt.

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. Verwenden von WITH ENCRYPTION

Das folgende Beispiel verwendet die Option WITH ENCRYPTION und zeigt berechnete, umbenannte und mehrfache Spalten.

Gilt für: SQL Server 2008 (10.0.x) und höher sowie SQL-Datenbank

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. Verwenden von WITH CHECK OPTION

Im folgenden Beispiel wird die Sicht mit dem Namen SeattleOnly gezeigt, die auf fünf Tabellen verweist und Datenänderungen nur bei Mitarbeitern zulässt, die in Seattle leben.

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: Verwenden integrierter Funktionen innerhalb einer Sicht

Das folgende Beispiel zeigt die Definition einer Sicht, die eine integrierte Funktion enthält. Wenn Sie Funktionen verwenden, müssen Sie für die abgeleitete Spalte einen Spaltennamen angeben.

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. Verwenden von partitionierten Daten

Das folgende Beispiel verwendet Tabellen mit den Namen SUPPLY1, SUPPLY2, SUPPLY3 und SUPPLY4. Diese Tabellen entsprechen den Lieferantentabellen von vier Büros in verschiedenen Ländern/Regionen.

--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  
--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;  
GO
INSERT dbo.all_supplier_view VALUES ('1', 'CaliforniaCorp'), ('5', 'BraziliaLtd')    
, ('231', 'FarEast'), ('280', 'NZ')  
, ('321', 'EuroGroup'), ('442', 'UKArchip')  
, ('475', 'India'), ('521', 'Afrique');  
GO  

Beispiele: Azure Synapse Analytics und Analytics-Plattformsystem (PDW)

F. Erstellen einer einfachen Sicht

Im folgenden Beispiel wird eine Sicht erstellt, in dem nur einige Spalten aus der Quelltabelle gewählt werden.

CREATE VIEW DimEmployeeBirthDates AS  
SELECT FirstName, LastName, BirthDate   
FROM DimEmployee;  

G. Erstellen einer Sicht durch Verknüpfen von zwei Tabellen

Im folgenden Beispiel wird eine Sicht mithilfe der Anweisung SELECT mit OUTER JOIN erstellt. Die Ergebnisse der JOIN-Abfrage füllen die Sicht auf.

CREATE VIEW view1  
AS 
SELECT fis.CustomerKey, fis.ProductKey, fis.OrderDateKey, 
  fis.SalesTerritoryKey, dst.SalesTerritoryRegion  
FROM FactInternetSales AS fis   
LEFT OUTER JOIN DimSalesTerritory AS dst   
ON (fis.SalesTerritoryKey=dst.SalesTerritoryKey);  

Weitere Informationen

ALTER TABLE (Transact-SQL)
ALTER VIEW (Transact-SQL)
DELETE (Transact-SQL)
DROP VIEW (Transact-SQL)
INSERT (Transact-SQL)
Erstellen einer gespeicherten Prozedur
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)