Partager via


Scénarios d'utilisation des vues

Vous pouvez recourir aux vues pour affiner, simplifier et personnaliser la perception de la base de données par chaque utilisateur. Les vues peuvent être utilisées comme mécanismes de sécurité en permettant aux utilisateurs d'accéder aux données par le biais de la vue, sans leur accorder d'autorisations qui leur permettraient d'accéder directement aux tables de base sous-jacentes de la vue. Les vues peuvent servir à fournir une interface de compatibilité descendante afin d'émuler une table qui existait mais dont le schéma a changé. Cependant, vous pouvez aussi y recourir pour copier des données vers et à partir de Microsoft SQL Server afin d'améliorer les performances et de partitionner les données.

Mise en évidence de données spécifiques

Les vues permettent aux utilisateurs de se concentrer sur des données spécifiques qui les intéressent et sur les tâches spécifiques dont ils sont responsables, en n'intégrant pas dans la vue les données superflues ou sensibles.

Par exemple, une vue vBikes de l'exemple de base de données AdventureWorks2008R2 permettrait à un utilisateur de voir les noms de tous les vélos actuellement en stock. La vue élimine de la table Product tous les champs sauf Name et retourne uniquement les noms des vélos montés plutôt que des composants.

CREATE VIEW vBikes AS
SELECT DISTINCT p.[Name] FROM Production.Product p
    JOIN Production.ProductInventory i ON p.ProductID = i.ProductID
    JOIN Production.ProductSubCategory ps 
        ON p.ProductSubcategoryID = ps.ProductSubCategoryID 
    JOIN Production.ProductCategory pc 
        ON (ps.ProductCategoryID = pc.ProductCategoryID 
            AND pc.Name = N'Bikes')
        AND i.Quantity > 0

Simplification de la manipulation des données

Les vues permettent de simplifier la manière dont les utilisateurs manipulent des données. Vous pouvez définir comme vues des jointures, des projections, des requêtes UNION ainsi que des requêtes SELECT fréquemment utilisées de sorte que les utilisateurs n'aient pas à spécifier toutes les conditions et qualifications chaque fois qu'une nouvelle opération est effectuée sur ces données. Par exemple, il est possible de créer comme vue une requête complexe servant à créer des rapports et exécuter des sous-requêtes, des jointures externes et des agrégations pour extraire des données d'un groupe de tables. La vue simplifie l'accès aux données puisque la requête sous-jacente ne doit pas être écrite ou soumise chaque fois que le rapport est créé ; c'est la vue qui est interrogée. Pour plus d'informations sur la manipulation des données, consultez Principes de base des requêtes.

Bien que ce ne soit pas une requête complexe, la vue vBikes de l'exemple de base de données AdventureWorks2008R2 permet aux utilisateurs de se concentrer sur des données spécifiques sans avoir à construire les clauses JOIN nécessaires à la création de la vue.

Vous pouvez également créer des fonctions définies par l'utilisateur Inline dont le fonctionnement logique s'apparente à celui des vues paramétrées, ou des vues dont les paramètres figurent dans les conditions de recherche de la clause WHERE. Pour plus d'informations, consultez Fonctions définies par l'utilisateur inline.

Pour offrir la compatibilité descendante

Les vues vous permettent de créer une interface à compatibilité descendante pour une table lorsque son schéma change. Par exemple, une application peut avoir référencé une table non normalisée dotée du schéma suivant :

Employee(Name, BirthDate, Salary, Department, BuildingName)

Pour éviter le stockage redondant des données dans la base de données, vous pouvez choisir de normaliser la table en la divisant en deux tables :

Employee2(Name, BirthDate, Salary, DeptId)

Department(DeptId, BuildingName)

Pour fournir une interface avec compatibilité descendante qui continue de référencer les données de la table Employee, vous pouvez supprimer l'ancienne table Employee et la remplacer par la vue suivante :

CREATE VIEW Employee AS
SELECT Name, BirthDate, Salary, BuildingName
FROM Employee2 e, Department d
WHERE e.DeptId = d.DeptId

Les applications qui avaient l'habitude d'interroger la table Employee peuvent désormais se procurer leurs données à partir de la vue Employee. Il est inutile de modifier l'application si elle se contente de lire les données de la table Employee. Pour les applications qui mettent à jour les données Employee, l'ajout de déclencheurs INSTEAD OF à la nouvelle vue pour associer les opérations INSERT, DELETE et UPDATE aux tables sous-jacentes peut les aider. Pour plus d'informations, consultez Conception de déclencheurs INSTEAD OF.

Personnalisation des données

Les vues permettent à différents utilisateurs d'afficher des données de différentes manières, même lorsqu'ils utilisent les mêmes données simultanément. Cet avantage est particulièrement significatif lorsque des utilisateurs dont les intérêts et les niveaux de compétences diffèrent partagent la même base de données. Par exemple, vous pouvez créer une vue qui extrait uniquement les données relatives aux clients dont est chargé un gestionnaire de comptes. La vue peut déterminer les données à extraire en fonction de l'ID de connexion du gestionnaire de comptes qui se sert de la vue.

Exportation et importation de données

Au moyen des vues, vous pouvez exporter des données vers d'autres applications. Supposons, par exemple, que vous souhaitiez utiliser les tables Customer et SalesOrderHeader de la base de données AdventureWorks2008R2 pour analyser les données concernant les ventes à l'aide de Microsoft Excel. Pour y parvenir, vous pouvez créer une vue reposant sur les tables Customer et SalesOrderHeader. Ensuite, à l'aide de l'utilitaire bcp, vous pouvez exporter les données définies par la vue. Des données peuvent également être importées dans certaines vues, à partir de fichiers de données, au moyen de l'utilitaire bcp ou de l'instruction BULK INSERT, pour autant que des lignes puissent être insérées dans la vue au moyen de l'instruction INSERT. Pour plus d'informations sur les restrictions relatives à la copie de données dans des vues, consultez INSERT (Transact-SQL). Pour plus d'informations sur l'utilisation de l'utilitaire bcp et de l'instruction BULK INSERT pour copier des données vers et à partir d'une vue, consultez Exportation/Importation en bloc de données depuis/vers une vue.

Pour combiner des données partitionnées sur plusieurs serveurs

L'opérateur Transact-SQL UNION peut être utilisé dans une vue afin de combiner en un seul ensemble de résultats les résultats de deux ou plusieurs requêtes sur des tables séparées. L'utilisateur ne voit alors qu'une seule table, appelée vue partitionnée. Par exemple, si une table contient des données relatives aux ventes réalisées dans l'état de Washington, et une autre celles réalisées en Californie, il est possible de créer une vue résultant de l'UNION de ces deux tables. Cette vue représente les ventes réalisées dans les deux états.

Pour utiliser des vues partitionnées, vous devez créer plusieurs tables identiques, en spécifiant une contrainte qui détermine la plage de données pouvant être ajoutée à chaque table. La vue est ensuite créée à l'aide de ces deux tables de base. Lorsque vous interrogez la vue, SQL Server détermine automatiquement quelles tables sont affectées par la requête et ne référence que ces tables. Si, par exemple, une requête spécifie que seules les données relatives aux ventes pour la France sont requises, SQL Server ne lit que la table contenant ces données ; il n'accède à aucune autre table.

Les vues partitionnées peuvent reposer sur des données de plusieurs sources hétérogènes, par exemple des serveurs distants, pour créer une fédération de serveurs de bases de données. Par exemple, pour combiner des données provenant de serveurs distants différents dont chacun héberge des données relatives à un pays différent desservi par votre organisation, vous pouvez créer des requêtes distribuées qui extraient des données de chacune des sources de données, puis une vue basée sur ces requêtes distribuées. Toutes les requêtes ne lisent que les tables des serveurs distants qui contiennent les données requises par la requête ; le programme n'accède pas aux autres serveurs référencés par les requêtes distribuées dans la vue.

Si vous partitionnez des données sur plusieurs serveurs, les requêtes qui n'accèdent qu'à une fraction des données peuvent être exécutées plus rapidement car la quantité de données à analyser est moindre. Si les tables résident sur des serveurs différents ou sur un ordinateur équipé de plusieurs processeurs, chaque table impliquée dans la requête peut également être analysée en parallèle. Ceci peut améliorer les performances de la requête. De plus, les tâches de maintenance, telles la reconstruction d'index ou la sauvegarde d'une table, peuvent être effectuées plus rapidement.

Si vous utilisez une vue partitionnée, les données apparaissent toujours sous la forme d'une table unique et peuvent être interrogées comme telles sans qu'il ne faille référencer manuellement la table sous-jacente appropriée.

Notes

La méthode la plus adaptée pour le partitionnement de données locales vers un serveur reste à travers des tables partitionnées. Pour plus d'informations, consultez Tables et index partitionnés.

Les vues partitionnées peuvent être mises à jour si l'une des conditions suivantes est remplie :

  • si un déclencheur INSTEAD OF est défini sur la vue avec une logique prenant en charge les instructions INSERT, UPDATE et DELETE ;

  • si la vue comme les instructions INSERT, UPDATE et DELETE suivent les règles définies pour les vues partitionnées pouvant être mises à jour. Pour plus d'informations, consultez Création de vues partitionnées.