Vue (SQL)

Dans une base de données , une vue est l' ensemble des résultats d'une requête stockée qui présente une perspective limitée de la base de données à un utilisateur. Cette commande de requête préétablie est conservée dans le dictionnaire de données . Contrairement aux tables de base ordinaires dans une base de données relationnelle , une vue ne fait pas partie du schéma physique : en tant qu'ensemble de résultats, il s'agit d'une table virtuelle calculée ou collationnée dynamiquement à partir des données de la base de données lorsque l'accès à cette vue est demandé. Les modifications appliquées aux données d'une table sous-jacente pertinente sont reflétées dans les données affichées lors des invocations ultérieures de la vue.

Les vues peuvent offrir des avantages par rapport aux tables :

• Les vues peuvent représenter un sous-ensemble des données contenues dans une table. Par conséquent, une vue peut limiter le degré d'exposition des tables sous-jacentes au monde extérieur : un utilisateur donné peut avoir l'autorisation d'interroger la vue, tout en se voyant refuser l'accès au reste de la table de base.
• Les vues peuvent joindre et simplifier plusieurs tables en une seule table virtuelle.
• Les vues peuvent agir comme des tables agrégées, où le moteur de base de données agrège les données ( somme , moyenne , etc.) et présente les résultats calculés dans le cadre des données.
• Les vues peuvent masquer la complexité des données. Par exemple, une vue peut apparaître sous le nom de Sales2020 ou Sales2021, partitionnant de manière transparente la table sous-jacente réelle.
• Les vues prennent très peu de place à stocker ; la base de données contient uniquement la définition d'une vue, pas une copie de toutes les données qu'elle présente.
• Les vues structurent les données d'une manière que les classes d'utilisateurs trouvent naturelle et intuitive.

Tout comme une fonction (en programmation) peut fournir une abstraction , une vue de base de données peut également le faire. Dans un autre parallèle avec les fonctions, les utilisateurs de bases de données peuvent manipuler des vues imbriquées, ainsi une vue peut agréger des données provenant d'autres vues. Sans l'utilisation de vues, la normalisation des bases de données au-dessus de la deuxième forme normale deviendrait beaucoup plus difficile. Les vues peuvent faciliter la création d'une décomposition de jointure sans perte.

Tout comme les lignes d'une table de base ne sont pas triées de manière définie, les lignes disponibles via une vue n'apparaissent pas avec un tri par défaut. Une vue est une table relationnelle et le modèle relationnel définit une table comme un ensemble de lignes. Comme les ensembles ne sont pas triés (par définition), les lignes d'une vue ne le sont pas non plus. Par conséquent, une clause ORDER BY dans la définition de la vue n'a pas de sens ; la norme SQL ( SQL:2003 ) n'autorise pas une clause ORDER BY dans la sous-requête d'une commande CREATE VIEW, tout comme elle est refusée dans une instruction CREATE TABLE. Cependant, des données triées peuvent être obtenues à partir d'une vue, de la même manière que n'importe quelle autre table, dans le cadre d'une instruction de requête sur cette vue. Néanmoins, certains SGBD (tels qu'Oracle Database ) ne respectent pas cette restriction de la norme SQL.

Les vues peuvent être définies comme étant en lecture seule ou pouvant être mises à jour. Si le système de base de données peut déterminer le mappage inverse du schéma de vue vers le schéma des tables de base sous-jacentes, la vue est alors modifiable. Les opérations INSERT , UPDATE et DELETE peuvent être effectuées sur des vues modifiables. Les vues en lecture seule ne prennent pas en charge ces opérations car le SGBD ne peut pas mapper les modifications aux tables de base sous-jacentes. Une mise à jour de vue est effectuée par préservation de clé.

Certains systèmes prennent en charge la définition de déclencheurs INSTEAD OF sur les vues. Cette technique permet de définir une autre logique d'exécution à la place d'une opération d'insertion, de mise à jour ou de suppression sur les vues. Ainsi, les systèmes de base de données peuvent implémenter des modifications de données basées sur des vues en lecture seule. Cependant, un déclencheur INSTEAD OF ne modifie pas la propriété de lecture seule ou de mise à jour de la vue elle-même.

Différents systèmes de gestion de bases de données ont étendu les vues à partir de sous-ensembles de données en lecture seule , en particulier les vues matérialisées : des vues pré-exécutées, non virtuelles, couramment utilisées dans l'entreposage de données . Elles donnent un instantané statique des données et peuvent inclure des données provenant de sources distantes. La précision d'une vue matérialisée dépend de la fréquence des mécanismes de déclenchement derrière ses mises à jour.

Les vues matérialisées ont été introduites par Oracle Database , tandis qu'IBM Db2 fournit des « tables de requêtes matérialisées » (MQT) dans le même but. Microsoft SQL Server a introduit dans sa version 2000 des vues indexées qui stockent uniquement un index séparé de la table, mais pas l'intégralité des données. PostgreSQL a implémenté les vues matérialisées dans sa version 9.3.

Une vue est équivalente à sa requête source. Lorsque des requêtes sont exécutées sur des vues, la requête est modifiée. Par exemple, s'il existe une vue nommée accounts_view avec le contenu suivant :

-- comptes_vue : 
------------- 
SELECT nom , argent_reçu , argent_envoyé , ( argent_reçu - argent_envoyé ) AS solde , adresse , ... FROM table_clients c JOIN comptes_table a ON a . customer_id = c . customer_id

alors l'application pourrait exécuter une requête simple telle que :

-- Requête simple 
------------ 
SELECT nom , solde FROM comptes_vue

Le SGBDR prend ensuite la requête simple, remplace la vue équivalente, puis envoie les éléments suivants à l' optimiseur de requêtes :

-- Requête prétraitée : 
------------------ 
SELECT nom , solde FROM ( SELECT nom , argent_reçu , argent_envoyé , ( argent_reçu - argent_envoyé ) AS solde , adresse , ... FROM table_customers c JOIN comptes_table a ON a . customer_id = c . customer_id )

L'optimiseur supprime ensuite les champs inutiles et la complexité (par exemple, il n'est pas nécessaire de lire l'adresse, puisque l'invocation parent ne l'utilise pas) puis envoie la requête au moteur SQL pour traitement.