CREATE VIEW (Transact-SQL)

Aktualisiert: 17. November 2008

Erstellt eine virtuelle Tabelle, die die Daten in einer Tabelle oder in mehreren Tabellen auf eine andere Weise darstellt. CREATE VIEW muss die erste Anweisung in einem Abfragebatch sein.

Transact-SQL-Syntaxkonventionen

Syntax

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

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

Argumente

• schema_name
  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 denselben Namen haben können (gewöhnlich aufgrund einer Verknüpfung) oder 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 z. B. Berechtigungen für die SalesOrderID-Spalte in einer CREATE VIEW-Anweisung erteilt werden, kann eine ALTER VIEW-Anweisung die SalesOrderID-Spalte umbenennen, z. B. in OrderRef. Die für die Sicht mit SalesOrderID zugeordneten Berechtigungen gelten weiterhin.

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

• select_statement
  Die SELECT-Anweisung, die die Sicht definiert. In der Anweisung können mehrere Tabellen und andere Sichten verwendet 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 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:

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

    Hinweis:
    Die ORDER BY-Klausel wird lediglich zur Ermittlung der Zeilen verwendet, die von der TOP-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, <join_hint>- und <table_hint>-Hinweise 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:
  Alle direkt für die zugrunde liegenden Tabellen einer Sicht ausgeführten Updates werden nicht anhand der Sicht geprüft, auch wenn CHECK OPTION angegeben ist.

• ENCRYPTION
  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 Tabelle(n). Wenn SCHEMABINDING angegeben ist, können an den Basistabellen keine Änderungen vorgenommen werden, die die Sichtdefinition betreffen. 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, Sichten 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 Microsoft SQL Server 2005-Datenbankmodul 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.

  SCHEMABINDING kann nicht angegeben werden, wenn die Sicht Spalten des Aliasdatentyps enthält.

• VIEW_METADATA
  Gibt an, dass die Instanz von SQL Server die Metadateninformationen der Sicht anstelle der Basistabellen 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 APIs auf dem Client zurückgegeben werden. Mit diesen Metadaten können die APIs auf dem Client aktualisierbare Cursor auf dem Client 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, können alle enthaltenen Spalten außer der timestamp-Spalte aktualisiert werden, sofern die Sicht INSTEAD OF INSERT- oder INSTEAD OF UPDATE-Trigger aufweist. Weitere Informationen zu aktualisierbaren Sichten finden Sie unter den Hinweisen.

Hinweise

Eine Sicht kann nur in der aktuellen Datenbank erstellt werden. Eine Sicht darf über maximal 1.024 Spalten verfügen.

Wenn eine Abfrage über eine Sicht durchgeführt wird, überprüft Datenbankmodul, 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. Wenn eine Überprüfung fehlschlägt, wird eine Fehlermeldung zurückgegeben. Bei einer erfolgreichen Überprüfung wird die Aktion in eine Aktion für die zugrunde liegenden Tabellen übersetzt.

Wenn eine Sicht von einer Tabelle oder Sicht abhängt, die gelöscht wurde, erzeugt Datenbankmodul eine Fehlermeldung, wenn ein Benutzer 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, sollte sp_refreshview ausgeführt werden, nachdem Änderungen an den der Sicht zugrunde liegenden Objekten vorgenommen wurden, die die Definition der Sicht betreffen. Andernfalls stellt die Abfrage der Sicht möglicherweise unerwartete Ergebnisse zur Verfügung.

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

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

Datenbankmodul 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.

Hinweis:

Mit der Einstellung des Kompatibilitätsgrads wird festgelegt, ob Datenbankmodul eine leere Zeichenfolge als einzelnes Leerzeichen oder als leere Zeichenfolge interpretiert. Ist der Kompatibilitätsgrad kleiner oder gleich 65, interpretiert Datenbankmodul leere Zeichenfolgen als einzelne Leerzeichen. Ist der Kompatibilitätsgrad gleich oder größer als 70, interpretiert Datenbankmodul leere Zeichenfolgen als leere Zeichenfolgen. Weitere Informationen finden Sie unter sp_dbcmptlevel (Transact-SQL).

Aktualisierbare Sichten

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.
• Im select_statement-Wert für die Sicht wird TOP nicht zusammen mit der WITH CHECK OPTION-Klausel 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 Datenbankmodul Änderungen von der Sichtdefinition an einer Basistabelle eindeutig nachverfolgen können. Weitere Informationen finden Sie unter Ä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. Ist also ein INSTEAD OF-Trigger einer Sicht für eine angegebene Datenänderungsanweisung (INSERT, UPDATE oder DELETE) vorhanden, ist die entsprechende Sicht über diese Anweisung aktualisierbar. Weitere Informationen zu INSTEAD OF-Triggern finden Sie unter Entwerfen von INSTEAD OF-Triggern.
• Partitionierte Sichten
  Wenn es sich bei der Sicht um eine partitionierte Sicht handelt, ist sie mit gewissen Einschränkungen aktualisierbar. Bei Bedarf unterscheidet Datenbankmodul 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).
  Weitere Informationen zu partitionierten Sichten finden Sie unter Erstellen von partitionierten Sichten.

Partitionierte Sichten

Bei einer partitionierten Sicht handelt es sich um eine Sicht, die durch eine UNION ALL-Anweisung von Elementtabellen 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, vereinte Datenbankserver genannt.

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

Im Allgemeinen gilt eine Sicht als partitioniert, wenn sie 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 sollten alle Spalten der Elementtabellen aufgeführt sein.

   • Die Spalten an derselben Ordnungsposition jeder select list sollten denselben Typ haben, einschließlich Sortierungen. Es reicht nicht aus, 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. Diese <col>-Spalte sollte so definiert sein, dass die Elementtabellen T1, ..., Tn über CHECK-Einschränkungen (C1, ..., Cn) verfügen, die entsprechend in <col> definiert sind.
     Die für T1 definierte Einschränkung C1 muss 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 sollten 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ätsspalte, eine Standardspalte oder eine timestamp-Spalte darf hierfür nicht verwendet werden.
   • Wenn für eine Spalte einer Elementtabelle mehrere Einschränkungen festgelegt sind, ignoriert das Datenbankmodul alle diese Einschränkungen und berücksichtigt sie nicht bei der Ermittlung, ob die Sicht eine partitionierte Sicht ist. Damit die Bedingungen für partitionierte Sichten erfüllt werden, sollte für die Partitionierungsspalte nur eine Partitionierungseinschränkung festgelegt sein.
   • Für Partitionierungsspalten gelten keine Einschränkungen hinsichtlich der Aktualisierbarkeit.
3. Elementtabellen oder zugrunde liegende Tabellen T1, ..., Tn
   • Bei den Tabellen handelt es sich entweder um lokale Tabellen oder um Tabellen von anderen Computern, 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).
     Wenn eine oder mehrere Elementtabellen 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, deren Tabellen mithilfe der UNION ALL-Anweisung kombiniert werden.
   • Die Elementtabellen dürfen nicht über Indizes verfügen, die für berechnete Spalten der Tabelle erstellt werden.
   • Für alle Elementtabellen sollte gelten, dass ihre PRIMARY KEY-Einschränkungen auf der gleichen Anzahl von Spalten basieren.
   • Für alle Elementtabellen einer Sicht sollte dieselbe Einstellung für ANSI-Leerstellen festgelegt sein. Diese Einstellung kann entweder mit der Option user options 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 muss für alle Spalten in der Sicht Werte bereitstellen, auch wenn die zugrunde liegenden Elementtabellen über eine DEFAULT-Einschränkung für diese Spalten verfügen oder NULL-Werte zulassen. Für die Spalten in der Elementtabelle, die über DEFAULT-Definitionen verfügen, können die Anweisungen nicht explizit das DEFAULT-Schlüsselwort verwenden.
• Der in die Partitionierungsspalte eingefügte Wert sollte mindestens eine der zugrunde liegenden Einschränkungen erfüllen. 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 Elementtabelle ein DEFAULT-Wert definiert ist.
• PRIMARY KEY-Spalten können nicht mit einer UPDATE-Anweisung geändert werden, wenn die Elementtabellen Spalten vom Typ text, ntext oder image aufweisen.
• Die in der Sicht enthaltenen Spalten, bei denen es sich um eine IDENTITY-Spalte in einer oder mehreren Elementtabellen handelt, können nicht mit der INSERT- oder UPDATE-Anweisung geändert werden.
• Wenn eine der Elementtabellen eine timestamp-Spalte enthält, kann die Sicht nicht mithilfe einer INSERT- oder UPDATE-Anweisung geändert werden.
• Wenn eine der Elementtabellen einen Trigger oder eine ON UPDATE CASCADE/SET NULL/SET DEFAULT- oder ON DELETE CASCADE/SET NULL/SET DEFAULT-Einschränkung hat, können Daten nicht geändert werden.
• INSERT-, UPDATE- und DELETE-Aktionen für eine partitionierte Sicht sind nicht zulässig, wenn eine Selbstverknüpfung mit derselben Sicht oder mit einer der Elementtabellen in der Anweisung vorhanden ist.
• Der Massenimport von Daten in eine partitionierte Sicht wird nicht unterstützt, wenn bcp oder die BULK INSERT- oder INSERT ... SELECT * FROM OPENROWSET(BULK...)-Anweisungen beim Massenimport von Daten verwendet werden. Sie können jedoch mit der INSERT-Anweisung mehrere Zeilen in eine partitionierte Sicht einfügen. Weitere Informationen finden Sie unter Massenexportieren von Daten aus einer Sicht und Massenimportieren von Daten in eine Sicht.

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

Zusätzliche Bedingungen für verteilte partitionierte Sichten

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

• Es wird eine verteilte Transaktion gestartet, um die Unteilbarkeit bei allen durch die Aktualisierung betroffenen Knoten sicherzustellen.
• Die Option XACT_ABORT SET sollte auf ON festgelegt werden, damit INSERT-, UPDATE- oder DELETE-Anweisungen verwendet werden können.
• Jede smallmoney- oder smalldatetime-Spalte einer Remotetabelle, auf die in einer partitionierten Sicht verwiesen wird, wird als money- bzw. datetime-Spalte zugeordnet. Daher sollten die entsprechenden Spalten (in derselben Ordnungsposition in der SELECT-Liste) der lokalen Tabellen vom Typ money bzw. datetime sein.
• 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 Elementtabellen und die partitionierte Sichtdefinition vorhanden sind, erstellt der SQL Server 2005-Abfrageoptimierer intelligente Pläne, die Abfragen zum effizienten Zugriff auf Daten in den Elementtabellen verwenden. Mit den CHECK-Einschränkungsdefinitionen kann der Abfrageprozessor die Verteilung der Schlüsselwerte den Elementtabellen 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 Elementtabellen möglicherweise auf Remoteservern gespeichert sind, löst die Instanz von SQL Server 2005 verteilte Abfragen also so auf, dass nur eine minimale Menge an verteilten Daten übertragen werden muss. Weitere Informationen zur Auflösung von Abfragen für partitionierte Sichten in SQL Server 2005 finden Sie unter Auflösen verteilter partitionierter Sichten.

Überlegungen zur Replikation

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

• Wenn die zugrunde liegenden Tabellen in der Merge- oder Transaktionsreplikation mit Abonnements mit Aktualisierung beteiligt sind, sollte die uniqueidentifier-Spalte ebenfalls in der SELECT-Liste eingeschlossen sein.
  Alle INSERT-Aktionen für die partitionierte Sicht müssen einen NEWID()-Wert für die uniqueidentifier-Spalte bereitstellen. Alle UPDATE-Aktionen für die uniqueidentifier-Spalte müssen NEWID() als Wert bereitstellen, da das DEFAULT-Schlüsselwort nicht verwendet werden kann.
• Die Replikation von Aktualisierungen, die mithilfe der Sicht ausgeführt werden, ist identisch mit der Replikation von Tabellen in zwei verschiedenen Datenbanken. Die Tabellen werden also von unterschiedlichen Replikations-Agents bedient, und die Reihenfolge der Aktualisierungen 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

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.Contact-Tabellen der AdventureWorks-Datenbank. Mit diesen Daten werden Name und Einstellungsdatum der Mitarbeiter von Adventure Works Cycles bereitgestellt. Die Ansicht könnte für die Person erstellt werden, die für die Nachverfolgung von Jubiläen verantwortlich ist. Dieser Person wird jedoch nicht der Zugriff auf alle Daten dieser Tabellen gewährt.

USE AdventureWorks ;
GO
IF OBJECT_ID ('hiredate_view', 'V') IS NOT NULL
DROP VIEW hiredate_view ;
GO
CREATE VIEW hiredate_view
AS 
SELECT c.FirstName, c.LastName, e.EmployeeID, e.HireDate
FROM HumanResources.Employee e JOIN Person.Contact c on e.ContactID = c.ContactID ;
GO

B. Verwenden von WITH ENCRYPTION

Im folgenden Beispiel werden die Option WITH ENCRYPTION verwendet und berechnete, umbenannte und mehrfache Spalten dargestellt.

USE AdventureWorks ;
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. 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.

USE AdventureWorks ;
GO
IF OBJECT_ID ('dbo.SeattleOnly', 'V') IS NOT NULL
    DROP VIEW dbo.SeattleOnly ;
GO
CREATE VIEW dbo.SeattleOnly
AS
SELECT c.LastName, c.FirstName, a.City, s.StateProvinceCode
FROM Person.Contact AS c 
JOIN HumanResources.Employee AS e ON c.ContactID = e.ContactID
JOIN HumanResources.EmployeeAddress AS ea ON e.EmployeeID = ea.EmployeeID
JOIN Person.Address AS a ON ea.AddressID = a.AddressID
JOIN Person.StateProvince AS s ON a.StateProvinceID = s.StateProvinceID
WHERE a.City = 'Seattle'
WITH CHECK OPTION ;
GO

D. Verwenden integrierter Funktionen innerhalb einer Sicht

Im folgenden Beispiel wird die Definition einer Sicht gezeigt, die eine integrierte Funktion enthält. Wenn Sie Funktionen verwenden, müssen Sie für die abgeleitete Spalte einen Spaltennamen angeben.

USE AdventureWorks ;
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. 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
INSERT dbo.SUPPLY1 VALUES ('1', 'CaliforniaCorp');
INSERT dbo.SUPPLY1 VALUES ('5', 'BraziliaLtd');
INSERT dbo.SUPPLY2 VALUES ('231', 'FarEast');
INSERT dbo.SUPPLY2 VALUES ('280', 'NZ');
INSERT dbo.SUPPLY3 VALUES ('321', 'EuroGroup');
INSERT dbo.SUPPLY3 VALUES ('442', 'UKArchip');
INSERT dbo.SUPPLY4 VALUES ('475', 'India');
INSERT dbo.SUPPLY4 VALUES ('521', 'Afrique');
GO
--Create the view that combines all supplier tables.
CREATE VIEW 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;

Siehe auch

Verweis

ALTER TABLE (Transact-SQL)
ALTER VIEW (Transact-SQL)
DELETE (Transact-SQL)
DROP VIEW (Transact-SQL)
INSERT (Transact-SQL)
sp_depends (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)

Andere Ressourcen

Erstellen von gespeicherten Prozeduren (Datenbankmodul)
Verwenden von Bezeichnern als Objektnamen
Verwenden partitionierter Sichten
Sichtauflösung

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf

Version	Verlauf
17. November 2008	Geänderter Inhalt Im Abschnitt "Bedingungen für das Ändern von Daten in partitionierten Sichten" wurde die Massenimportbeschränkung hinzugefügt.
17. Juli 2006	Geänderter Inhalt Die Anweisung, dass die lokalen partitionierten Sichten nur für die Abwärtskompatibilität verfügbar sind und als veraltet markiert werden, wurde entfernt.
14. April 2006	Neuer Inhalt Im Abschnitt mit den Hinweisen wurden Informationen zum Ausführen von sp_refreshview für Sichten hinzugefügt, die nicht mit der SCHEMABINDING-Klausel erstellt wurden.
05. Dezember 2005	Neuer Inhalt Die Erläuterung des Zwecks der ORDER BY-Klausel in einer Sichtdefinition wurde hinzugefügt. Geänderter Inhalt: Es wurde die Erläuterung hinzugefügt, dass eine Sicht aktualisierbar ist, wenn TOP nicht im select_statement-Wert der Sicht zusammen mit der WITH CHECK OPTION-Klausel verwendet wird.