Le langage SQL acronyme de Structured Query Language (Langage Structuré de Requêtes), a été conçu pour gérer les données dans un SGBDR. A l’aide des DML (Data Manipulation Language ie les requêtes SELECT, INSERT, UPDATE, DELETE) il est possible de manipuler ces données qui sont stockées dans des tables. SQL nous propose une autre interface pour accéder à cette information: les vues.

Dans cet article, nous verrons comment créer et se servir des vues, puis avec quelques exemples pratiques, nous allons voir comment les utiliser le mieux possible.

Qu’est ce qu’une vue ?

Les vues sont des tables virtuelles issues de l’assemblage d’autres tables en fonction de critères. Techniquement les vues sont créées à l’aide d’une requête SELECT. Elles ne stockent pas les données quelles contiennent mais conservent juste la requête permettant de les créer.

La requête SELECT qui génère la vue référence une ou plusieurs tables. La vue peut donc être, par exemple, une jointure entre différentes tables, l’agrégation ou l’extraction de certaines colonnes d’une table. Elle peut également être créée à partir d’une autre vue.

Les vues sont souvent en lecture seule et ne permettent donc que de lire des données. Cependant MySQL permet la création de vues modifiables sous certaines conditions :

• La requête qui génère la vue doit permettre à MySQL de retrouver la trace de l’enregistrement à modifier dans la ou les tables sous-jacentes ainsi que celle de toutes les valeurs de chaque colonne. La requête SELECT créant la vue ne doit donc pas contenir de clause DISTINCT, GROUP BY, HAVING… et autres fonctions d’agrégation. La liste complète est disponible dans la documentation de MySQL.
• L’autre condition est que sa clause ALGORITHM ne doit pas être de valeur TEMPTABLE. Nous reviendrons sur ce point.

A quoi servent les vues ?

Les vues peuvent être utilisées pour différentes raisons, elles permettent de :

• Contrôler l’intégrité en restreignant l’accès aux données pour améliorer la confidentialité
  • Partitionnement vertical et/ou horizontal pour cacher des champs aux utilisateurs, ce qui permet de personnaliser l’affichage des informations suivant le type d’utilisateur.
• Masquer la complexité du schéma
  • Indépendance logique des données, utile pour donner aux utilisateurs l’accès à un ensemble de relations représentées sous la forme d’une table. Les données de la vue sont alors des champs de différentes tables regroupées, ou des résultats d’opérations sur ces champs.
• Modifier automatiquement des données sélectionnées (sum(), avg(), max(),…)
  • Manipuler des valeurs calculées à partir d’autres valeurs du schéma.
• Conserver la structure d’une table si elle doit être modifiée
  • Le schéma peut ainsi être modifié sans qu’il ne soit nécessaire de changer les requêtes du côté applicatif.

Les droits nécessaires

Pour créer une vue l’utilisateur doit avoir le droit CREATE VIEW. Il faut également avoir la permission de sélectionner toutes les colonnes qui apparaissent dans la commande SELECT spécifiant ce qu’est la vue.

De plus si la clause REPLACE est utilisée, le droit DROP est également nécessaire.

Le droit SHOW VIEW donne la possibilité d’exécuter la commande SHOW CREATE VIEW. Cette commande permet d’obtenir les informations de création d’une vue. Une autre façon d’obtenir ces informations est d’interroger la table view du schéma information_schema. Cette information sera exhaustive seulement pour les vues que vous avez créées.

GRANT SELECT, DROP, CREATE VIEW, SHOW VIEW ON `projet`.* TO 'secretaire'@'localhost';

(à suivre… syntaxe d’une vue)

http://dasini.net/blog/presentations/?#presentation_mysql

Vues

Des vues pour faciliter la visibilité

Les vues sont la plupart du temps utiles pour donner aux utilisateurs l’accès à un ensemble de relations représentées sous la forme d’une table. Une vue est une table virtuelle ; les données de la vue sont en fait des champs de différentes tables regroupées, ou des résultats d’opérations sur ces champs.

Des vues pour améliorer la confidentialité

Une vue n’est pas forcément un regroupement de plusieurs tables mais peut être un sous ensemble d’une table (ou de plusieurs) ce qui permet de cacher des champs aux utilisateurs.

Par exemple il ne sera pas forcément utile à tout le monde d’accéder aux champs indiquant les bénéfices réalisés sur un projet dans votre base comptable. Vous pouvez donc créer une vue contenant tous les champs de la table projet sauf le champs bénéfice.

L’approche avec MySQL 5 sera donc plus souple car elle ne force plus un découpage de table pour gérer la confidentialité et les droits donnés aux utilisateurs. Les vues permettront de remplir ce rôle.

Les vues compliquent les mises à jour

Insérer ou modifier des données dans une vue n’est pas aussi simple que de faire un update dans une table. Pour pouvoir le faire il faut réfléchir de façon plus poussée au modèle conceptuel de données :

Une vue n’est pas forcément accessible en insertion / modification. Pour cela il faut qu’il n’y ait pas d’incompatibilité logique à ce qu’elle le soit.

• Tous les champs des tables possédant des contraintes d’intégrités (index unique, clés primaires ..) doivent être présent

• La vue ne doit pas posséder de regroupement ou d’exclusion ( GROUP BY , DISTINCT, UNION)

• Le plan d’exécution de la vue ne doit pas passer par une table temporaire

Les vues de MySQL 5 par la pratique

CREATE
[OR REPLACE]
VIEW view-name
[(column-list)]
AS select-statement

Créer une vue revient à appliquer un filtre à une ou plusieurs tables. Pour schématiser prenons une entreprise normale. Dans celle-ci il y a des employés regroupés sous le terme ‘personnel’. On regroupe ces employés par ‘catégorie’ en fonction de leur activité (administratif, informatique, commercial,…).

On peut créer une vue contenant l’ensemble des informaticiens avec le code suivant :

CREATE VIEW personnelinformatique

AS SELECT a.nom AS nom,a.prenom AS prenom,b.service AS service

from categorie b, personnel a

where a.fkCategorie = 1 and a.fkCategorie = b.pkCategorie;

Optimisation des vues de MySQL 5

CREATE

[ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]

[DEFINER = { user | CURRENT_USER }]

[SQL SECURITY { DEFINER | INVOKER }]

VIEW view-name

[(column-list)]

AS select-statement

[WITH [CASCADED | LOCAL] CHECK OPTION]

• La clause facultative «ALGORITHM» n’est pas standard. Elle permet d’optimiser votre code.

• MERGE utilise la requête SQL ayant servie à la création de la vue comme base d’opération.

• TEMPTABLE utilise une table temporaire créée pour stocker les résultats.

Par défaut l’optimiseur MySQL décide lui-même quelle option choisir (UNDEFINED). Pour améliorer les performances, il est généralement plus intéressant de le définir statiquement afin d’éviter à l’optimiseur de le découvrir à chaque exécution.

«DEFINER» assigne un créateur à la vue.

«SQL SECURITY» définit quelles seront les droits de l’utilisateur, lors de l’exécution de la vue. Deux valeurs sont possibles:

- DEFINER permet d’exécuter la vue avec les droits du créateur.

- INVOKER permet d’exécuter la vue avec ses propres droits.

Pour finir, la clause facultative CHECK OPTION permet de ne modifier que la vue ou du moins des informations qui respectent les contraintes de la vue. Ainsi dans notre exemple, avec la clause CHECK OPTION, il ne sera pas possible de modifier au travers de la vue « personnelInformatique » une personne ne travaillant pas dans le service informatique.

Manque

Le seul léger bémol est que la version 5.0 de MySQL ne disposera pas des vues matérialisées. Les vues matérialisées sont des données physiquement dupliquées dans le SGDB. Par exemple le résultat d’un calcul n’est plus à refaire pour chaque accès. Leur utilité se fait particulièrement sentir lors de traitements de tables très volumineuses .

Comparaison avec d’autres SGBD

Possibilité des vues avec MySQL 5.0

UPDATEABLE_KEY est une fonctionnalité de MySQL permettant de modifier une clef primaire par le biais d’une vue.