CREATE VIEW (Transact-SQL)

Data aggiornamento: 17 novembre 2008

Crea una tabella virtuale che rappresenta i dati di una o più tabelle in modo alternativo. Deve essere la prima istruzione di un batch di query.

Icona di collegamento a un argomentoConvenzioni della sintassi Transact-SQL

Sintassi

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

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

Argomenti

  • schema_name
    Nome dello schema a cui appartiene la vista.
  • view_name
    Nome della vista. I nomi di vista devono essere conformi alle regole per gli identificatori. Il nome del proprietario della vista è facoltativo.
  • column
    Nome da assegnare a una colonna della vista. Il nome della colonna è necessario solo quando una colonna deriva da un'espressione aritmetica, una funzione o una costante, quando due o più colonne potrebbero altrimenti avere lo stesso nome (in genere a causa di un join) oppure quando a una colonna di una vista viene assegnato un nome diverso rispetto alla colonna da cui deriva. È inoltre possibile assegnare nomi di colonna nell'istruzione SELECT.

    Se column viene omesso, le colonne della vista acquisiscono gli stessi nomi delle colonne nell'istruzione SELECT.

    [!NOTA] Nelle colonne di una vista, le autorizzazioni assegnate per un nome di colonna rimangono valide tra istruzioni CREATE VIEW e ALTER VIEW, indipendentemente dall'origine dei dati sottostanti. Se, ad esempio, vengono concesse autorizzazioni per la colonna SalesOrderID in un'istruzione CREATE VIEW, un'istruzione ALTER VIEW può assegnare alla colonna SalesOrderID un nome diverso, ad esempio OrderRef, e mantenere le autorizzazioni associate alla vista che utilizza SalesOrderID.

  • AS
    Specifica le operazioni che la vista deve eseguire.
  • select_statement
    Istruzione SELECT che definisce la vista. Nell'istruzione è possibile specificare più di una tabella e altre viste. Per selezionare gli oggetti a cui viene fatto riferimento nella clausola SELECT della vista creata è necessario disporre di autorizzazioni appropriate.

    Non è necessario che una vista sia un semplice subset delle righe e delle colonne di una tabella specifica. È possibile creare una vista che utilizza più tabelle o altre viste tramite una clausola SELECT del grado di complessità desiderato.

    In una definizione di vista indicizzata l'istruzione SELECT deve essere riferita a una sola tabella oppure includere un JOIN tra più tabelle con aggregazioni facoltative.

    Le clausole SELECT utilizzate in una definizione di vista non possono includere gli elementi seguenti:

    • Clausole COMPUTE o COMPUTE BY

    • Clausola ORDER BY, a meno che nell'elenco di selezione dell'istruzione SELECT non sia presente anche una clausola TOP

      [!NOTA] La clausola ORDER BY viene utilizzata esclusivamente per determinare le righe restituite dalla clausola TOP nella definizione della vista. La clausola ORDER BY non garantisce risultati ordinati in caso di query sulla vista, a meno che tale clausola non venga specificata anche nella query.

    • Parola chiave INTO

    • Clausola OPTION

    • Riferimento a una tabella temporanea o a una variabile di tabella

    Poiché select_statement utilizza l'istruzione SELECT, è possibile utilizzare gli hint <join_hint> e <table_hint> come specificato nella clausola FROM. Per ulteriori informazioni, vedere FROM (Transact-SQL) e SELECT (Transact-SQL).

    In select_statement è possibile utilizzare funzioni e più istruzioni SELECT separate dall'operatore UNION o UNION ALL.

  • CHECK OPTION
    Impone a tutte le istruzioni di modifica dei dati eseguite sulla vista di soddisfare i criteri impostati nell'argomento select_statement. Quando una riga viene modificata tramite una vista, la clausola WITH CHECK OPTION assicura che i dati rimangano visibili nella vista dopo il commit della modifica.

    [!NOTA] Tutti gli aggiornamenti eseguiti direttamente sulle tabelle sottostanti di una vista non vengono verificati in base alla vista, anche se la clausola CHECK OPTION è specificata.

  • ENCRYPTION
    Esegue la crittografia delle voci della tabella sys.syscomments contenenti il testo dell'istruzione CREATE VIEW. Se si utilizza WITH ENCRYPTION, la vista non viene pubblicata nell'ambito della replica di SQL Server.
  • SCHEMABINDING
    Associa la vista allo schema della tabella o delle tabelle sottostanti. Quando la clausola SCHEMABINDING viene specificata, non è possibile apportare alla tabella o alle tabelle di base modifiche che hanno effetto sulla definizione della vista. È necessario prima modificare o eliminare la definizione della vista per rimuovere le dipendenze dalla tabella da modificare. Quando si utilizza SCHEMABINDING, l'argomento select_statement deve includere i nomi composti da due parti (schema**.**object) delle tabelle, delle viste o delle funzioni definite dall'utente a cui viene fatto riferimento. Tutti gli oggetti a cui viene fatto riferimento devono essere presenti nello stesso database.

    Le viste o le tabelle che fanno parte di una vista creata con la clausola SCHEMABINDING non possono essere eliminate, a meno che la vista non venga eliminata o modificata in modo che non sia più associata a uno schema. In caso contrario, nel Motore di database di SQL Server 2005 Microsoft viene generato un errore. Inoltre, l'esecuzione di istruzioni ALTER TABLE su tabelle che fanno parte di viste associate a schema ha esito negativo se tali istruzioni modificano la definizione della vista.

    La clausola SCHEMABINDING non può essere specificata se la vista contiene colonne con il tipo di dati alias.

  • VIEW_METADATA
    Specifica che l'istanza di SQL Server dovrà restituire alle API DB-Library, ODBC e OLE DB le informazioni sui metadati relativi alla vista anziché alla tabella o alle tabelle di base quando vengono richiesti metadati in modalità browse per una query che fa riferimento alla vista. I metadati in modalità browse sono metadati aggiuntivi che l'istanza di SQL Server restituisce a queste API sul lato client. Questi metadati consentono alle API sul lato client di implementare cursori sul lato client aggiornabili. I metadati in modalità browse includono informazioni sulla tabella di base a cui appartengono le colonne del set di risultati.

    Per le viste create con VIEW_METADATA, i metadati in modalità browse restituiscono il nome della vista anziché i nomi delle tabelle di base nella descrizione delle colonne della vista nel set di risultati.

    Quando si crea una vista con la clausola WITH VIEW_METADATA, tutte le relative colonne, esclusa una di tipo timestamp, sono aggiornabili se la vista include trigger INSTEAD OF INSERT o INSTEAD OF UPDATE. Per ulteriori informazioni sulle viste aggiornabili, vedere la sezione Osservazioni.

Osservazioni

È possibile creare una vista solo nel database corrente. Una vista può includere al massimo 1.024 colonne.

Quando si esegue una query tramite una vista, il Motore di database verifica che tutti gli oggetti del database a cui viene fatto riferimento nell'istruzione esistano e siano validi nel contesto dell'istruzione e che le istruzioni di modifica dei dati non violino le regole di integrità dei dati. Se la verifica ha esito negativo, viene visualizzato un messaggio di errore. In caso contrario, l'azione viene convertita automaticamente in un'operazione sulla tabella o sulle tabelle sottostanti.

Se si tenta di utilizzare una vista che dipende da una tabella o una vista eliminata, il Motore di database visualizza un messaggio di errore. Se viene creata una nuova tabella o vista per sostituire quella eliminata e la struttura della nuova tabella non è diversa rispetto alla tabella di base precedente, la vista risulta di nuovo utilizzabile. Se la struttura della nuova tabella o vista è diversa, la vista deve essere eliminata e ricreata.

Se una vista non viene creata tramite la clausola SCHEMABINDING, è consigliabile eseguire sp_refreshview quando vengono apportate modifiche agli oggetti sottostanti la vista che influiscono sulla definizione di tale vista. In caso contrario, le query sulla vista possono generare risultati imprevisti.

Quando si crea una vista, le relative informazioni vengono archiviate nelle viste del catalogo sys.views, sys.columns e sys.sql_dependencies. Il testo dell'istruzione CREATE VIEW viene archiviato nella vista del catalogo sys.sql_modules.

Una query che utilizza un indice su una vista definita tramite espressioni numeric o float può generare un risultato diverso rispetto a una query simile che non utilizza l'indice sulla vista. Tale differenza può essere dovuta a errori di arrotondamento generati durante l'esecuzione di operazioni INSERT, DELETE o UPDATE sulle tabelle sottostanti.

Nel Motore di database le impostazioni delle opzioni SET QUOTED_IDENTIFIER e SET ANSI_NULLS vengono salvate in fase di creazione di una vista. Queste impostazioni originali vengono utilizzate per analizzare la vista quando viene utilizzata. Pertanto, tutte le impostazioni di sessione del client per SET QUOTED_IDENTIFIER e SET ANSI_NULLS non hanno effetto sulla definizione della vista durante l'accesso alla vista.

[!NOTA] L'impostazione del livello di compatibilità determina se una stringa vuota viene interpretata dal Motore di database come un singolo spazio o come una reale stringa vuota. Se il livello di compatibilità è minore o uguale a 65, le stringhe vuote vengono interpretate dal Motore di database come singoli spazi. Se il livello di compatibilità è maggiore o uguale a 70, le stringhe vuote vengono interpretate dal Motore di database come reali stringhe vuote. Per ulteriori informazioni, vedere sp_dbcmptlevel (Transact-SQL).

Viste aggiornabili

È possibile modificare i dati di una tabella di base sottostante tramite una vista solo se vengono soddisfatti i requisiti seguenti:

  • Tutte le modifiche, incluse le istruzioni UPDATE, INSERT e DELETE, devono fare riferimento a colonne di una sola tabella di base.
  • Le colonne modificate nella vista devono fare riferimento direttamente ai dati sottostanti nelle colonne della tabella. Le colonne non possono essere derivate in altro modo, ad esempio tramite:
    • Una funzione di aggregazione: AVG, COUNT, SUM, MIN, MAX, GROUPING, STDEV, STDEVP, VAR e VARP.
    • Un calcolo. La colonna non può essere calcolata tramite un'espressione che utilizza altre colonne. Le colonne create mediante gli operatori sugli insiemi UNION, UNION ALL, CROSSJOIN, EXCEPT e INTERSECT sono considerate un calcolo e non sono aggiornabili.
  • Le colonne da modificare non sono interessate da clausole GROUP BY, HAVING o DISTINCT.
  • La clausola TOP non può essere utilizzata in tutte le posizioni dell'argomento select_statement della vista in combinazione con la clausola WITH CHECK OPTION.

Le restrizioni sopra indicate sono valide sia per qualsiasi subquery nella clausola FROM della vista sia per la vista stessa. In genere, il Motore di database deve essere in grado di tracciare senza ambiguità le modifiche dalla definizione della vista a una tabella di base. Per ulteriori informazioni, vedere Modifica di dati tramite una vista.

Se le restrizioni sopra indicate non consentono di modificare i dati direttamente tramite una vista, è possibile ricorrere alle soluzioni seguenti:

  • Trigger INSTEAD OF
    È possibile creare trigger INSTEAD OF per una vista in modo da renderla aggiornabile. Questo trigger viene eseguito in sostituzione dell'istruzione di modifica dei dati in cui è definito e consente all'utente di specificare il set di azioni che devono essere eseguite per elaborare l'istruzione di modifica dei dati. Pertanto, se è disponibile un trigger INSTEAD OF per una vista in un'istruzione di modifica dei dati specifica (INSERT, UPDATE o DELETE), la vista corrispondente risulta aggiornabile tramite l'istruzione. Per ulteriori informazioni sui trigger INSTEAD OF, vedere Progettazione di trigger INSTEAD OF.
  • Viste partizionate
    Se la vista è partizionata, è aggiornabile ma con particolari restrizioni. Quando necessario, il Motore di database effettua una distinzione tra viste partizionate locali, ovvero le viste nelle quali tutte le tabelle coinvolte e la vista stessa si trovano nella stessa istanza di SQL Server, e viste partizionate distribuite, ovvero le viste nelle quali almeno una tabella della vista risiede in un server diverso o remoto.
    Per ulteriori informazioni sulle viste partizionate, vedere Creazione di viste partizionate.

Viste partizionate

Una vista partizionata è una vista definita tramite un'istruzione UNION ALL eseguita su tabelle membro con la stessa struttura, ma archiviate separatamente sotto forma di più tabelle nello stessa istanza di SQL Server oppure in un gruppo di istanze autonome di server SQL Server denominato federazione di server di database.

[!NOTA] Il metodo consigliato per il partizionamento locale dei dati in un server prevede l'utilizzo di tabelle partizionate. Per ulteriori informazioni, vedere Tabelle e indici partizionati.

Durante la progettazione di uno schema di partizione, è necessario individuare con chiarezza i dati appartenenti a ogni partizione. Ad esempio, i dati della tabella Customers vengono distribuiti in tre tabelle membro su tre server: Customers_33 su Server1, Customers_66 su Server2 e Customers_99 su Server3.

Una vista partizionata in Server1 viene definita nel modo seguente:

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

In generale, una vista viene definita partizionata se utilizza il formato seguente:

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

Requisiti per la creazione di viste partizionate

  1. Elenchi di selezione (select_list)
    • Tutte le colonne delle tabelle membro devono essere incluse nell'elenco di colonne della definizione della vista.

    • Alle colonne che si trovano nella stessa posizione ordinale in ogni select list deve essere associato lo stesso tipo, incluse le regole di confronto. Non è sufficiente che il tipo di dati delle colonne supporti la conversione implicita, come nel caso di operazioni UNION.
      Inoltre, è necessario che almeno una colonna, ad esempio <col>, sia presente in tutti gli elenchi di selezione nella stessa posizione ordinale. La colonna <col> deve essere definita in modo che le tabelle membro T1, ..., Tn includano rispettivamente i vincoli CHECK C1, ..., Cn in <col>.
      Il vincolo C1 definito nella tabella T1 deve avere il formato seguente:

      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 >
      
    • I vincoli devono essere tali per cui qualsiasi valore specificato di <col> può soddisfare al massimo uno dei vincoli C1, ..., Cn e devono quindi costituire un set di intervalli disgiunti o non sovrapposti. La colonna <col> in cui sono definiti i vincoli disgiunti è denominata colonna di partizionamento. Si noti che nelle tabelle sottostanti tale colonna può avere nomi diversi. Per soddisfare i requisiti della colonna di partizionamento sopra descritti, i vincoli devono essere abilitati e attendibili. Se i vincoli sono disabilitati, è necessario riabilitare il controllo dei vincoli tramite l'opzione CHECK CONSTRAINT constraint_name dell'istruzione ALTER TABLE e convalidarli tramite l'opzione WITH CHECK.
      Negli esempi seguenti vengono illustrati alcuni set di vincoli validi:

      { [col < 10], [col between 11 and 20] , [col > 20] }
      { [col between 11 and 20], [col between 21 and 30], [col between 31 and 100] }
      
    • Nell'elenco di selezione non è consentito utilizzare più volte la stessa colonna.

  2. Colonna di partizionamento
    • Deve fare parte della colonna PRIMARY KEY della tabella.
    • Non può essere una colonna calcolata, Identity, predefinita o timestamp.
    • Se una colonna di una tabella membro ha più vincoli, vengono ignorati tutti i vincoli, anche quando è necessario determinare se la vista è partizionata. Per soddisfare i requisiti per la creazione di viste partizionate, è necessario che la colonna di partizionamento includa un solo vincolo di partizionamento.
    • Non sono previste restrizioni per quanto concerne l'aggiornabilità della colonna di partizionamento.
  3. Tabelle membro o tabelle sottostanti T1, ..., Tn
    • Possono essere tabelle locali o tabelle presenti in altri computer che eseguono SQL Server a cui viene fatto riferimento tramite un nome in quattro parti oppure un nome basato su OPENDATASOURCE o OPENROWSET. La sintassi di OPENDATASOURCE e OPENROWSET consente di specificare un nome di tabella, ma non una query pass-through. Per ulteriori informazioni, vedere OPENDATASOURCE (Transact-SQL) e OPENROWSET (Transact-SQL).
      Se una o più tabelle membro sono remote, la vista viene definita vista partizionata distribuita ed è necessario rispettare alcuni ulteriori requisiti descritti di seguito in questa sezione.
    • Non è possibile inserire una stessa tabella due volte nel set di tabelle combinate tramite l'istruzione UNION ALL.
    • Le tabelle membro non possono includere indici creati su colonne calcolate della tabella.
    • Tutti i vincoli PRIMARY KEY delle tabelle membro devono riguardare lo stesso numero di colonne.
    • L'impostazione per il riempimento ANSI deve essere la stessa per tutte le tabelle membro della vista. Questa impostazione può essere configurata tramite l'opzione user options della stored procedure sp_configure oppure tramite l'istruzione SET.

Requisiti per la modifica di dati nelle viste partizionate

Le istruzioni che consentono di modificare i dati nelle viste partizionate sono soggette alle restrizioni seguenti:

  • L'istruzione INSERT deve fornire valori per tutte le colonne della vista, anche se le tabelle membro sottostanti includono un vincolo DEFAULT per tali colonne o supportano valori Null. Per le colonne delle tabelle membro che includono definizioni DEFAULT, nelle istruzioni non è consentito specificare la parola chiave DEFAULT in modo esplicito.

  • Il valore inserito nella colonna di partizionamento deve soddisfare almeno uno dei vincoli sottostanti. In caso contrario, l'operazione di inserimento provoca una violazione di vincolo e ha esito negativo.

  • Nelle istruzioni UPDATE non è possibile specificare la parola chiave DEFAULT come valore nella clausola SET, anche se alla colonna è associato un valore DEFAULT definito nella tabella membro corrispondente.

  • Se le tabelle membro includono colonne di tipo text, ntext o image, non è possibile modificare le colonne PRIMARY KEY tramite un'istruzione UPDATE.

  • Le colonne Identity della vista incluse in una o più tabelle membro non possono essere modificate tramite un'istruzione INSERT o UPDATE.

  • Se una delle tabelle membro include una colonna di tipo timestamp, non è possibile modificare la vista tramite un'istruzione INSERT o UPDATE.

  • Se una delle tabelle membro include un trigger oppure un vincolo ON UPDATE CASCADE/SET NULL/SET DEFAULT o ON DELETE CASCADE/SET NULL/SET DEFAULT, i dati non possono essere modificati.

  • Le operazioni INSERT, UPDATE e DELETE eseguite su una vista partizionata non sono consentite se includono un self join con tale vista o con una delle tabelle membro.

  • L'importazione di massa di dati in una vista partizionata non è supportata da bcp o dalle istruzioni BULK INSERT e INSERT ... SELECT * FROM OPENROWSET(BULK...). Tuttavia, è possibile inserire più righe in una vista partizionata tramite l'istruzione INSERT. Per ulteriori informazioni, vedere Esportazione o importazione di massa dei dati da o in una vista.

    [!NOTA] Per aggiornare una vista partizionata, l'utente deve disporre delle autorizzazioni INSERT, UPDATE e DELETE per le tabelle membro.

Requisiti aggiuntivi per le viste partizionate distribuite

Per le viste partizionate distribuite, ovvero le viste nelle quali una o più tabelle membro sono remote, devono essere soddisfatti i requisiti aggiuntivi seguenti:

  • Per garantire l'atomicità in tutti i nodi interessati dall'aggiornamento, viene avviata una transazione distribuita.
  • Per consentire il corretto funzionamento delle istruzioni INSERT, UPDATE o DELETE, è necessario impostare l'opzione XACT_ABORT SET su ON.
  • Le colonne di tipo smallmoney e smalldatetime di tabelle remote a cui viene fatto riferimento in una vista partizionata vengono mappate rispettivamente sui tipi di dati money e datetime. Pertanto, le colonne corrispondenti delle tabelle locali, ovvero le colonne che occupano la stessa posizione ordinale nell'elenco di selezione, devono essere di tipo money e datetime.
  • Qualsiasi server collegato nella vista partizionata non può essere di tipo loopback, ovvero non deve puntare alla stessa istanza di SQL Server.

L'impostazione dell'opzione SET ROWCOUNT viene ignorata per le operazioni INSERT, UPDATE e DELETE che coinvolgono viste partizionate aggiornabili e tabelle remote.

Quando sono disponibili le tabelle membro e la definizione della vista partizionata, nell'utilità Query Optimizer di SQL Server 2005 vengono creati automaticamente piani appropriati in cui le query vengono utilizzate in modo efficiente per l'accesso ai dati di tabelle membro. Con le definizioni di vincoli CHECK, in Query Processor viene eseguito il mapping della distribuzione dei valori chiave nelle tabelle membro. Quando un utente inoltra una query, viene eseguito un confronto tra il mapping e i valori specificati nella clausola WHERE, quindi viene creato un piano di esecuzione che comporta il trasferimento di una quantità minima di dati tra i server membri. Sebbene sia possibile che alcune tabelle membro si trovino in server remoti, le query distribuite vengono risolte dall'istanza di SQL Server 2005 in modo che la quantità di dati distribuiti da trasferire sia minima. Per ulteriori informazioni sulla risoluzione di query su viste partizionate in SQL Server 2005, vedere Risoluzione di viste partizionate distribuite.

Requisiti per la replica

Per creare viste partizionate di tabelle membro coinvolte nella replica, devono essere soddisfatti i requisiti seguenti:

  • Se le tabelle sottostanti sono coinvolte nella replica transazionale o di tipo merge con sottoscrizioni aggiornabili, nell'elenco di selezione deve essere presente anche la colonna uniqueidentifier.
    Le operazioni INSERT eseguite sulla vista partizionata devono fornire un valore NEWID() per la colonna uniqueidentifier. Le operazioni UPDATE eseguite sulla colonna uniqueidentifier devono fornire il valore NEWID() in quanto non è possibile specificare la parola chiave DEFAULT.
  • La replica di aggiornamenti tramite la vista equivale alla replica di tabelle in due database distinti, ovvero le tabelle vengono gestite da agenti di replica diversi e l'ordine degli aggiornamenti non è garantito.

Autorizzazioni

Sono richieste l'autorizzazione CREATE VIEW nel database e l'autorizzazione ALTER nello schema in cui viene creata la tabella.

Esempi

A. Utilizzo di un'istruzione CREATE VIEW semplice

Nell'esempio seguente viene creata una vista tramite l'utilizzo di un'istruzione SELECT semplice. Una vista semplice risulta utile quando vengono eseguite query frequenti su una combinazione di colonne. I dati di questa vista derivano dalle tabelle HumanResources.Employee e Person.Contact del database AdventureWorks. I dati contengono informazioni sul nome e la data di assunzione dei dipendenti di Adventure Works Cycles. È possibile creare la vista per la persona incaricata di tenere traccia del periodo di assunzione dei dipendenti, senza però consentire a tale utente di accedere a tutti i dati di queste tabelle.

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. Utilizzo dell'opzione WITH ENCRYPTION

Nell'esempio seguente viene utilizzata l'opzione WITH ENCRYPTION e vengono illustrate colonne calcolate, colonne rinominate e colonne multiple.

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. Utilizzo della clausola WITH CHECK OPTION

Nell'esempio seguente viene illustrata una vista denominata SeattleOnly che fa riferimento a cinque tabelle e consente di applicare modifiche ai dati solo per i dipendenti che risiedono a Seattle.

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. Utilizzo di funzioni predefinite in una vista

Nell'esempio seguente viene illustrata una definizione di vista che include una funzione predefinita. Quando si utilizzano le funzioni, è necessario specificare un nome di colonna per la colonna derivata.

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. Utilizzo di dati partizionati

Nell'esempio seguente vengono utilizzate quattro tabelle denominate SUPPLY1, SUPPLY2, SUPPLY3 e SUPPLY4, corrispondenti alle tabelle dei fornitori di quattro uffici dislocati in aree geografiche diverse.

--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;

Vedere anche

Riferimento

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)

Altre risorse

Creazione di stored procedure (Motore di database)
Utilizzo degli identificatori come nomi di oggetti
Utilizzo di viste partizionate
Risoluzione delle viste

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche

Versione Cronologia

17 novembre 2008

Contenuto modificato:
  • Aggiunta della restrizione per l'importazione di massa nella sezione "Requisiti per la modifica di dati nelle viste partizionate".

17 luglio 2006

Contenuto modificato:
  • Eliminazione dell'affermazione indicante che le viste partizionate locali sono disponibili solo per compatibilità con le versioni precedenti e a breve risulteranno obsolete.

14 aprile 2006

Nuovo contenuto:
  • Nella sezione Osservazioni aggiunta di informazioni sull'esecuzione di sp_refreshview nelle viste non create tramite la clausola SCHEMABINDING.

5 dicembre 2005

Nuovo contenuto:
  • Aggiunta di un chiarimento sullo scopo della clausola ORDER BY nella definizione di una vista.
Contenuto modificato:
  • Chiarimento del fatto che una vista è aggiornabile se la clausola TOP non viene utilizzata in qualsiasi posizione nell'istruzione select_statement della vista in combinazione con la clausola WITH CHECK OPTION.