CREATE VIEW (Transact-SQL)

Article
12/15/2008

Mis à jour : 17 novembre 2008

Crée une table virtuelle qui représente les données dans une ou plusieurs tables de manière alternative. CREATE VIEW doit être la première instruction d'un lot de requêtes.

Icône Lien de rubrique Conventions de syntaxe Transact-SQL

Syntaxe

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

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

Arguments

schema_name
Nom du schéma auquel appartient la vue.

view_name
Nom de la vue. Les noms des vues doivent se conformer aux règles applicables aux identificateurs. Vous n'êtes pas tenu de spécifier le nom du propriétaire de la vue.

column
Nom à utiliser pour une colonne dans une vue. L'attribution d'un nom à une colonne n'est obligatoire que lorsqu'une colonne est dérivée d'une expression arithmétique, d'une fonction ou d'une constante, lorsque plusieurs colonnes risquent de porter le même nom (généralement à cause d'une jointure), ou encore lorsqu'une colonne d'une vue reçoit un nom différent de la colonne de laquelle elle est dérivée. Les noms des colonnes peuvent également être attribués dans l'instruction SELECT.

Si vous ne spécifiez pas le paramètre column, les colonnes de la vue prennent les mêmes noms que les colonnes de l'instruction SELECT.

Remarque :
Dans les colonnes de la vue, les autorisations pour un nom de colonne s'appliquent d'un bout à l'autre d'une instruction CREATE VIEW ou ALTER VIEW, quelle que soit la source des données sous-jacentes. Par exemple, si des autorisations sont octroyées sur la colonne SalesOrderID dans une instruction CREATE VIEW, une instruction ALTER VIEW peut donner à la colonne SalesOrderID un autre nom, tel que OrderRef, et disposer néanmoins des autorisations associées à la vue qui utilise SalesOrderID.

Dans les colonnes de la vue, les autorisations pour un nom de colonne s'appliquent d'un bout à l'autre d'une instruction CREATE VIEW ou ALTER VIEW, quelle que soit la source des données sous-jacentes. Par exemple, si des autorisations sont octroyées sur la colonne SalesOrderID dans une instruction CREATE VIEW, une instruction ALTER VIEW peut donner à la colonne SalesOrderID un autre nom, tel que OrderRef, et disposer néanmoins des autorisations associées à la vue qui utilise SalesOrderID.

AS
Actions que la vue doit réaliser.

select_statement
Instruction SELECT qui définit la vue. Elle peut utiliser plusieurs tables et d'autres vues. Les autorisations nécessaires à la sélection à partir d'objets référencés dans la clause SELECT de la vue créée doivent être définies.

Une vue ne doit pas être un simple sous-ensemble de lignes et de colonnes d'une table particulière. Une vue peut être créée à l'aide de plusieurs tables ou d'autres vues avec une clause SELECT complexe.

Dans la définition d'une vue indexée, l'instruction SELECT doit être une instruction de table unique ou une jointure multitable avec une clause d'agrégation.

Les clauses SELECT faisant partie d'une définition de vue ne peuvent inclure les paramètres suivants :

la clause COMPUTE ou COMPUTE BY ;

une clause ORDER BY, sauf si une clause TOP figure également dans la liste de sélection de l'instruction SELECT ;

Remarque :
La clause ORDER BY est utilisée uniquement pour déterminer les lignes retournées par la clause TOP dans la définition de la vue. La clause ORDER BY ne garantit pas des résultats classés lorsque la vue est interrogée, sauf si ORDER BY est également spécifiée dans la requête proprement dite.

le mot clé INTO ;
la clause OPTION ;
une référence à une table temporaire ou à une variable de type table.

Étant donné que le paramètre select_statement utilise l'instruction SELECT, vous pouvez utiliser des indicateurs <join_hint> et <table_hint> comme précisé dans la clause FROM. Pour plus d'informations, consultez FROM (Transact-SQL) et SELECT (Transact-SQL).

select_statement peut utiliser des fonctions et plusieurs instructions SELECT séparées par UNION ou UNION ALL.

WITH CHECK OPTION.
Cette option impose que toutes les instructions de modification de données exécutées sur la vue respectent le critère défini dans select_statement. Lorsqu'une ligne est modifiée par l'intermédiaire d'une vue, WITH CHECK OPTION vérifie que les données resteront visibles dans la vue après validation de la modification.

Remarque :

Une mise à jour directe des tables sous-jacentes d'une vue n'est cependant pas vérifiée par rapport à la vue, même si CHECK OPTION a été précisé.

Remarque :
Une mise à jour directe des tables sous-jacentes d'une vue n'est cependant pas vérifiée par rapport à la vue, même si CHECK OPTION a été précisé.

ENCRYPTION
Chiffre les entrées sys.syscomments qui contiennent le texte de l'instruction CREATE VIEW. L'utilisation de l'argument WITH ENCRYPTION évite la publication de la vue dans le cadre de la réplication SQL Server.

SCHEMABINDING
Lie la vue au schéma des tables sous-jacentes ou des autres tables. Si SCHEMABINDING est spécifié, la table ou les tables de base ne peuvent pas être modifiées d'une manière qui affecterait la définition de la vue. Cette dernière doit d'ailleurs être modifiée ou supprimée au préalable pour supprimer les dépendances par rapport à la table qui doit être modifiée. Lorsque l'argument SCHEMABINDING est spécifié, select_statement doit comprendre les noms à deux composantes (schema**.**object) des tables, des vues ou des fonctions utilisateur référencées. Tous ces objets référencés doivent se trouver dans la même base de données.

Les vues ou les tables impliquées dans une vue créée avec la clause SCHEMABINDING ne peuvent pas être supprimées, sauf si cette vue perd, à la suite de sa suppression ou de sa modification, la liaison au schéma. Dans le cas contraire, le moteur de base de données SQL Server 2005 de Microsoft génère une erreur. En outre, les instructions ALTER TABLE portant sur des tables impliquées dans des vues liées au schéma échouent si elles affectent la définition des vues.

SCHEMABINDING ne peut être ajouté si la vue contient des colonnes de données de type alias.

VIEW_METADATA
Spécifie que l'instance de SQL Server retourne aux API DB-Library, ODBC et OLE DB, les informations de métadonnées sur la vue, plutôt que sur la ou les tables de base, lorsque des métadonnées en mode Parcourir sont sollicitées pour une requête qui fait référence à la vue. Les métadonnées en mode Parcourir correspondent à des métadonnées supplémentaires que l'instance de SQL Server retourne à ces API clientes. Ces métadonnées permettent aux API clientes d'implémenter des curseurs clients pouvant être mis à jour. Les métadonnées en mode Parcourir comprennent des informations sur la table de base à laquelle appartiennent les colonnes de l'ensemble de résultats.

Dans le cas d'une vue créée par le biais de VIEW_METADATA, les métadonnées en mode Parcourir retournent le nom de la vue, et non celui de la table de base, lors de la description des colonnes de la vue comprise dans l'ensemble de résultats.

Lorsqu'une vue est créée à l'aide de VIEW_METADATA, toutes ses colonnes (à l'exception d'une colonne timestamp) peuvent être mises à jour si elle contient des déclencheurs INSTEAD OF INSERT ou INSTEAD OF UPDATE. Pour plus d'informations sur les vues pouvant être mises à jour, consultez les Notes ci-dessous.

Notes

Vous ne pouvez créer des vues que dans la base de données actuelle. Une vue ne peut faire référence qu'à un maximum de 1 024 colonnes.

Lorsque vous effectuez une requête par l'intermédiaire d'une vue, le moteur de base de données vérifie que tous les objets de base de données référencés dans l'instruction existent, qu'ils sont bien valides dans le contexte de l'instruction et que les instructions de modification de données ne violent pas les règles d'intégrité des données. Si une vérification échoue, le système retourne un message d'erreur. Si la vérification réussit, l'action est transformée en une action applicable dans la ou les tables sous-jacentes.

Si une vue dépend d'une table ou d'une vue qui a été supprimée, le moteur de base de données envoie un message d'erreur lors de toute tentative d'utilisation de la vue. Si une table ou une vue est créée pour remplacer celle qui a été supprimée et que la structure de la table n'est pas modifiée par rapport à la table de base précédente, la vue est de nouveau utilisable. Si la structure de la nouvelle table ou vue change, la vue doit être supprimée puis recréée.

Si aucune vue n'est créée avec la clause SCHEMABINDING, sp_refreshview doit être exécutée lorsque des modifications sont apportées aux objets sous-jacents de la vue qui affectent sa définition. Autrement, la vue risque de produire des résultats imprévisibles en cas d'interrogation.

Lors de la création d'une vue, des informations sur la vue sont stockées dans les affichages catalogue suivants : sys.views, sys.columns et sys.sql_dependencies. L'affichage catalogue sys.sql_modules contient le texte de l'instruction CREATE VIEW.

Le résultat d'une requête utilisant un index sur une vue définie à partir d'expressions numeric ou float peut être différent de celui d'une requête similaire n'utilisant pas l'index de la vue. Cette différence peut être le résultat d'erreurs d'arrondi survenues au cours d'opérations INSERT, DELETE ou UPDATE sur des tables sous-jacentes.

Le moteur de base de données enregistre les paramètres de SET QUOTED_IDENTIFIER et SET ANSI_NULLS lors de la création d'une vue. Ces paramètres d'origine servent à analyser la vue lorsque celle-ci est utilisée. Par conséquent, tout paramétrage d'une session client pour SET QUOTED_IDENTIFIER et SET ANSI_NULLS n'influe pas sur la définition de la vue lors de l'accès à la vue.

Remarque :
La façon dont le moteur de base de données interprète une chaîne vide, que ce soit comme un espace unique ou comme une vraie chaîne vide, dépend de la valeur du niveau de compatibilité. Si le niveau de compatibilité est inférieur ou égal à 65, le moteur de base de données interprète les chaînes vides comme des espaces simples. S'il est supérieur ou égal à 70, le moteur de base de données interprète les chaînes vides comme telles. Pour plus d'informations, consultez sp_dbcmptlevel (Transact-SQL).

La façon dont le moteur de base de données interprète une chaîne vide, que ce soit comme un espace unique ou comme une vraie chaîne vide, dépend de la valeur du niveau de compatibilité. Si le niveau de compatibilité est inférieur ou égal à 65, le moteur de base de données interprète les chaînes vides comme des espaces simples. S'il est supérieur ou égal à 70, le moteur de base de données interprète les chaînes vides comme telles. Pour plus d'informations, consultez sp_dbcmptlevel (Transact-SQL).

Vues pouvant être mises à jour

Pour modifier les données d'une table sous-jacente, vous pouvez utiliser une vue sous réserve que les conditions suivantes soient vraies :

Toute modification, y compris celles via les instructions UPDATE, INSERT et DELETE, doivent faire référence aux colonnes d'une seule et même table de base.
Les colonnes en cours de modification dans la vue doivent faire directement référence aux données sous-jacentes dans les colonnes des tables. Les colonnes ne peuvent pas être dérivées d'une autre façon, que ce soit par :
- une fonction d'agrégation : AVG, COUNT, SUM, MIN, MAX, GROUPING, STDEV, STDEVP, VAR et VARP ;
- un calcul, car la colonne ne peut être calculée à partir d'une expression utilisant d'autres colonnes ; de même, les colonnes formées par le biais des opérateurs UNION, UNION ALL, CROSSJOIN, EXCEPT et INTERSECT équivalent à une somme de calculs et ne peuvent donc pas être mises à jour.
Les colonnes en cours de modification ne sont pas affectées par l'utilisation des clauses GROUP BY, HAVING ou DISTINCT.
La clause TOP n'est utilisée nulle part avec la clause WITH CHECK OPTION dans le paramètre select_statement de la vue.

Les restrictions précédentes s'appliquent à toutes les sous-requêtes de la clause FROM participant à créer la vue, tout comme elles s'appliquent aussi à la vue même. De façon générale, le moteur de base de données doit pouvoir suivre les modifications de façon claire, à partir de la définition de la vue vers une table de base. Pour plus d'informations, consultez Modification de données par l'intermédiaire d'une vue.

Si les restrictions précédentes vous empêchent de modifier des données directement à travers une vue, voici quelques options à considérer pour vous aider :

Déclencheurs INSTEAD OF
Les déclencheurs INSTEAD OF peuvent être créés sur une vue pour que celle-ci puisse être mise à jour. Le déclencheur INSTEAD OF est exécuté à la place de l'instruction de modification de données sur laquelle il est défini. Ce déclencheur permet à l'utilisateur de spécifier l'ensemble d'actions à exécuter pour traiter l'instruction de modification de données. Par conséquent, si une instruction précise de modification de données (INSERT, UPDATE ou DELETE) détient un déclencheur INSTEAD OF associé à une vue, celle-ci peut être mise à jour par le biais de cette instruction. Pour plus d'informations sur les déclencheurs INSTEAD OF, consultez Conception de déclencheurs INSTEAD OF.
Vues partitionnées
Si la vue est dite « partitionnée », elle peut être mise à jour sous certaines conditions. Au besoin, le moteur de base de données fait la distinction entre une vue partitionnée locale d'une part, car cette vue et toutes les tables impliquées dans sa création figurent sur le même serveur SQL Server, et une vue partitionnée distribuée d'autre part, car au moins une des tables de la vue se trouve sur un serveur différent, voire distant.
Pour plus d'informations sur les vues partitionnées, consultez Création de vues partitionnées.

Vues partitionnées

Une vue partitionnée est définie par une opération UNION ALL portant sur des tables membres structurées de façon identique, mais elle est stockée sous forme de plusieurs tables séparées que ce soit sur une seule instance de SQL Server ou dans un groupe d'instances autonomes SQL Server, appelé « serveurs de bases de données fédérés ».

Remarque :
Le partitionnement des données en local s'effectue de préférence par le biais de tables partitionnées. Pour plus d'informations, consultez Tables et index partitionnés.

Lorsque vous concevez un schéma de partitionnement, il est indispensable d'identifier clairement les données appartenant à chaque partition. Par exemple, les données de la table Customers sont réparties dans trois tables membres à trois emplacements de serveur : Customers_33 sur Server1, Customers_66 sur Server2 et Customers_99 sur Server3.

Une vue partitionnée sur Server1 est définie de la façon suivante :

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

En général, une vue est dite partitionnée si elle se présente sous la forme suivante :

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

Conditions de création des vues partitionnées

La list de sélection
- Toutes les colonnes des tables membres doivent être sélectionnées dans la liste de colonnes de la définition de la vue.
- Les colonnes de position ordinale identique dans chaque liste de sélection (select list) doivent être de même type, notamment en ce qui concerne leur classement. Il n'est pas suffisant que les colonnes soient de type convertible de façon implicite, comme cela est généralement le cas pour UNION.
  De plus, au moins une colonne (par exemple <col>) doit apparaître dans toutes les listes SELECT à la même position ordinale. Pour que la colonne <col> soit définie, les tables membres T1, ..., Tn doivent respectivement posséder les contraintes CHECK C1, ..., Cn pour <col>.
  La contrainte C1 définie sur la table T1 doit se présenter sous la forme suivante :
```
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 >
```
- La définition des contraintes doit permettre à toute valeur de <col> de satisfaire au plus une des contraintes C1, ..., Cn de telle sorte que les contraintes forment un ensemble d'intervalles disjoints ou sans chevauchement. La colonne <col> sur laquelle les contraintes disjointes sont définies est appelée « colonne de partitionnement ». Notez que la colonne de partitionnement peut porter différents noms dans les tables sous-jacentes. Les contraintes doivent être dans un état activé et approuvé pour répondre aux conditions précédentes associées à la colonne de partitionnement. Si les contraintes sont désactivées, réactivez la vérification des contraintes à l'aide de l'option CHECK CONSTRAINT constraint_name de l'instruction ALTER TABLE, puis utilisez l'option WITH CHECK pour valider ces contraintes.
  Voici des exemples d'ensembles valides de contraintes :
```
{ [col < 10], [col between 11 and 20] , [col > 20] }
{ [col between 11 and 20], [col between 21 and 30], [col between 31 and 100] }
```
- La même colonne ne peut être utilisée qu'une seule fois dans la liste de sélection.
Colonne de partitionnement
- La colonne de partitionnement fait partie de la clé primaire de la table.
- Il ne peut pas s'agir d'une colonne calculée, d'une colonne d'identité, d'une colonne par défaut ou d'une colonne de type timestamp.
- Si une colonne d'une table membre comporte plusieurs contraintes, le moteur de bases de données ignore toutes les contraintes et n'en tient pas compte pour déterminer si la vue est ou non une vue partitionnée. Pour que les conditions associées à la vue partitionnée soient remplies, seule une contrainte de partitionnement doit être appliquée à la colonne de partitionnement.
- Aucune restriction ne s'applique sur la possibilité de mettre à jour la colonne de partitionnement.
Tables membres ou tables sous-jacentes T1, ..., Tn
- Les tables peuvent être des tables locales ou des tables provenant d'autres serveurs SQL Server référencées par le biais d'un nom à quatre composantes ou d'un nom basé sur OPENDATASOURCE ou OPENROWSET. La syntaxe OPENDATASOURCE et OPENROWSET permet de spécifier le nom d'une table, mais pas une requête directe. Pour plus d'informations, consultez OPENDATASOURCE (Transact-SQL) et OPENROWSET (Transact-SQL).
  Si une ou plusieurs tables membres sont distantes, la vue est appelée vue partitionnée de données distribuées, et des conditions supplémentaires s'appliquent. Ces conditions sont présentées plus loin dans cette section.
- Une table ne peut apparaître qu'une fois dans l'ensemble de tables combinées avec l'instruction UNION ALL.
- Dans les tables membres, il est impossible de créer des index sur les colonnes calculées de la table.
- Toutes les contraintes PRIMARY KEY des tables membres doivent être appliquées sur un nombre identique de colonnes.
- Les tables membres doivent avoir le même paramètre de remplissage ANSI. Ce dernier peut être défini à l'aide de l'option user options qui se trouve dans la base de données sp_configure ou par le biais de l'instruction SET.

Conditions de modification de données dans des vues partitionnées

Les restrictions suivantes s'appliquent aux instructions qui modifient des données dans les vues partitionnées :

L'instruction INSERT doit fournir des valeurs pour toutes les colonnes de la vue, même celles des tables membres sous-jacentes ayant une contrainte DEFAULT ou acceptant des valeurs NULL. Pour les colonnes de tables membres dont la contrainte porte sur la valeur DEFAULT, les instructions ne peuvent pas spécifier la valeur NULL ou utiliser le mot clé DEFAULT de manière explicite.
La valeur insérée dans la colonne de partitionnement doit respecter au moins une des contraintes sous-jacentes, sinon l'action INSERT échoue à la suite d'une violation de contrainte.
Les instructions UPDATE ne peuvent pas définir le mot clé DEFAULT comme valeur dans la clause SET même si une valeur DEFAULT est définie pour la colonne dans la table membre correspondante.
Les colonnes PRIMARY KEY ne peuvent pas être modifiées par le biais d'une instruction UPDATE si les tables membres possèdent des colonnes au format text, ntext ou image.
Les colonnes de la vue qui sont des colonnes d'identité dans une ou plusieurs tables membres ne peuvent pas être mises à jour par le biais d'une instruction INSERT ou UPDATE.
Si une des tables membres contient une colonne timestamp, la vue ne peut pas être mise à jour par le biais d'une instruction INSERT ou UPDATE.
Si l'une des tables membres contient un déclencheur ou une contrainte ON UPDATE CASCADE/SET NULL/SET DEFAULT ou ON DELETE CASCADE/SET NULL/SET DEFAULT, les données ne peuvent alors pas être modifiées.
Les actions INSERT UPDATE et DELETE sur une vue partitionnée ne sont pas autorisées s'il existe une jointure réflexive sur la vue ou sur une des tables membres indiquées dans l'instruction.

L'importation en bloc de données dans une vue partitionnée n'est pas prise en charge par bcp, ni par les instructions BULK INSERT et INSERT ... SELECT * FROM OPENROWSET(BULK...). Vous pouvez toutefois insérer plusieurs lignes dans une vue partitionnée à l'aide de l'instruction INSERT. Pour plus d'informations, consultez Exportation/Importation en bloc de données depuis/vers une vue.

Remarque :
Pour mettre à jour une vue partitionnée, l'utilisateur doit bénéficier des autorisations nécessaires pour effectuer les instructions INSERT, DELETE et UPDATE sur les tables membres.

Conditions supplémentaires relatives aux vues partitionnées distribuées

Dans le cas des vues partitionnées distribuées, qui impliquent une ou plusieurs tables membres distantes, les conditions supplémentaires suivantes s'appliquent :

Une transaction distribuée doit être démarrée pour garantir l'atomicité sur tous les nœuds affectés par la mise à jour.
Les instructions INSERT, UPDATE et DELETE ne fonctionnent que si l'option XACT_ABORT SET a la valeur ON.
Toutes les colonnes smallmoney et smalldatetime des tables distantes référencées dans une vue partitionnée sont respectivement mappées en types money et datetime. Par conséquent, les colonnes correspondantes dans les tables locales (de rang identique dans la liste de sélection) doivent être de type money et datetime.
Tout serveur lié dans une vue partitionnée ne peut pas être un serveur dont la liaison constitue un bouclage. En d'autres termes, un serveur lié ne peut pas pointer vers la même instance de SQL Server.

La valeur de l'option SET ROWCOUNT est ignorée pour les actions INSERT, UPDATE et DELETE impliquant des vues partitionnées pouvant être mises à jour et des tables distantes.

Lorsque les tables membres et la définition de la vue partitionnée sont implémentées, l'optimiseur de requête de SQL Server 2005 crée des plans intelligents qui utilisent des requêtes efficacement pour accéder aux données des tables membres. Grâce aux définitions de la contrainte CHECK, le processeur de requêtes effectue la répartition des valeurs de clé parmi les tables membres. Lorsqu'un utilisateur émet une requête, le processeur de requêtes compares le plan des références aux valeurs spécifiées dans la clause WHERE et crée un plan d'exécution impliquant un transfert de données minimal entre les serveurs membres. Par conséquent, bien que certaines tables membres puissent se trouver sur des serveurs distants, l'instance de SQL Server 2005 résout les requêtes distribuées de telle sorte que la quantité de données distribuées à transférer soit minime. Pour plus d'informations sur la manière dont SQL Server 2005 résout les requêtes sur des vues partitionnées, consultez Résolution de vues distribuées partitionnées.

À prendre en considération lors des réplications

Pour créer des vues partitionnées sur des tables membres entrant en jeu dans une réplication, les points suivants sont à prendre en considération :

Si les tables sous-jacentes sont impliquées dans une réplication de fusion ou transactionnelle avec la fonctionnalité d'abonnement aux mises à jour, la colonne uniqueidentifier doit aussi être ajoutée à la liste de sélection.
Toute action INSERT dans la vue partitionnée doit fournir une valeur NEWID() pour la colonne uniqueidentifier. En ce qui concerne les actions UPDATE portant sur la colonne uniqueidentifier, la valeur NEWID() doit alors être utilisée, le mot clé DEFAULT ne pouvant pas l'être.
La réplication de mises à jour opérées par le biais de la vue revient à répliquer des tables tirées de deux bases de données différentes : les tables sont servies par différents agents de réplication et l'ordre des mises à jour n'est pas garanti.

Autorisations

Nécessite l'autorisation CREATE VIEW dans la base de données et l'autorisation ALTER sur le schéma dans lequel la vue est créée.

Exemples

A. Utilisation d'une instruction CREATE VIEW simple

L'exemple suivant crée une vue par le biais d'une instruction SELECT simple. Une vue simple est utile lorsque vous interrogez régulièrement une combinaison de colonnes. Les données de cette vue sont tirées des tables HumanResources.Employee et Person.Contact de la base de données AdventureWorks. Ces données fournissent les noms et les informations relatives à la date d'embauche des employés de Adventure Works Cycles. La vue doit pouvoir être créée par la personne chargée de suivre les dates anniversaires d'embauche mais sans pour autant l'autoriser à accéder à toutes les données de ces tables.

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. Utilisation de l'option WITH ENCRYPTION

Cet exemple utilise l'option WITH ENCRYPTION et montre les colonnes calculées, les colonnes renommées et les colonnes multiples.

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. Utilisation de l'option WITH CHECK OPTION

Cet exemple montre une vue appelée SeattleOnly se reportant à cinq tables et n'autorisant des modifications de données que pour les employés vivant à 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. Utilisation de fonctions intégrées dans une vue

L'exemple suivant illustre la définition d'une vue qui inclut une fonction intégrée. Si vous utilisez des fonctions, vous devez attribuer un nom à la colonne dérivée.

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. Utilisation de données partitionnées

L'exemple suivant s'appuie sur les tables nommées SUPPLY1, SUPPLY2, SUPPLY3 et SUPPLY4. Ces tables correspondent aux tables des fournisseurs de quatre sièges situées dans des pays/régions distincts.

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

Voir aussi

Historique des modifications

Version	Historique
17 novembre 2008	Contenu modifié Ajout de la restriction sur l'importation en bloc dans la section « Conditions de modification de données dans des vues partitionnées ».
17 juillet 2006	Contenu modifié Suppression de la mention selon laquelle les vues partitionnées locales ne sont disponibles que pour des raisons de compatibilité descendante et qu'elles vont bientôt être abandonnées.
14 avril 2006	Nouveau contenu : Dans la section Remarques, ajout d'informations relatives à l'exécution de sp_refreshview sur les vues qui ne sont pas créées avec la clause SCHEMABINDING.
5 décembre 2005	Nouveau contenu Des éclaircissements ont été fournis quant au rôle de la clause ORDER BY dans la définition d'une vue. Contenu modifié : Des informations ont été fournies pour expliquer qu'une vue peut être mise à jour si la clause TOP n'est pas utilisée dans le paramètre select_statement de la vue avec la clause WITH CHECK OPTION.

Partager via