Une vue offre une manière différente d’examiner les données dans une ou plusieurs tables. L’instruction VIEW (vue) est une table virtuelle constituée d’une instruction SQL SELECT qui accède aux données d’une ou plusieurs tables ou vues.
Une vue contient des lignes et des colonnes, tout comme une vraie table. Les champs d’une vue sont des champs d’une ou plusieurs tables réelles de la base de données.
Voici la syntaxe de création de vue :
CREATE VIEW nom-view
AS requete
Où, requete signifie n’importe quelle instruction SQL SELECT.
Exemple:
Créez une vue nommée VW_PROJET sur la table TB_PROJET qui contient uniquement les lignes avec un numéro de projet (PROJET_NO) commençant par les lettres “SP”.
CREATE VIEW VW_PROJET
AS SELECT *
FROM TB_PROJET
WHERE SUBSTR(PROJET_NO, 1, 2) = 'SP'
Nous pouvons interroger la vue ci-dessus comme suit :
L’instruction ALTER VIEW régénère une vue existante en modifiant une colonne de type référence pour ajouter une portée. L’instruction ALTER VIEW active ou désactive également une vue à utiliser dans l’optimisation des requêtes.
Voici la syntaxe de modification de la vue :
ALTER VIEW nom_vue
ALTER colonne nom-colonne ADD SCOPE nom-table
[ENABLE/DISABLE QUERY OPTIMIZATION]
Vous utilisez la commande ALTER VIEW pour régénérer une vue non valide après avoir modifié l’une des tables de base afin de vous assurer que la vue reste valide.
Une base de données (DB2) est un ensemble de tables de données ou d’entités associées. Par exemple, une base de données typique pour une organisation comprendrait un client, une commande et des tables de détails de commande. Toutes ces tables sont liées les unes aux autres d’une manière ou d’une autre. Dans cet exemple, les clients ont des commandes et les commandes ont des détails de commande. Même si chaque table existe par elle-même, collectivement, les tables constituent une base de données.
La base de données est un groupe d’espaces de table et d’espaces d’index logiquement liés, qui à leur tour contiennent respectivement des tables et des index.
La base de données par défaut, DSNDB04, est prédéfinie dans le processus d’installation de DB2.
Espace table (Table Space)
Les données sont en fait stockées dans une structure appelée espace table (Table Space).
Chaque espace table est corrélé à un ou plusieurs ensembles de données VSAM physiques individuels dans les volumes DASD du groupe de stockage.
Chaque espace table contient une ou plusieurs tables.
Il existe trois types d’espace table différents :
Espace de table simple
Espace table segmenté
Espace table partitionné
Nous parlerons en détail de l’espace de la table tout en traitant des ” verrous ” (Locks) au chapitre “DB2 – Verrous“.
Espace d’indexation (Index Space)
Un espace d’index est la structure de stockage sous-jacente pour les données d’index.
Chaque espace d’index correspond à un ou plusieurs ensembles de données VSAM physiques individuels dans les volumes DASD du groupe de stockage.
Il est automatiquement créé par DB2 chaque fois qu’un index est créé. Il ne peut y avoir qu’un seul index dans un espace d’index.
Table
Les tables sont des structures logiques gérées par le gestionnaire de base de données.
Lorsque vous stockez des informations dans votre classeur, vous ne les jetez pas simplement dans un tiroir. Au lieu de cela, vous créez des fichiers dans le classeur, puis vous classez les données associées dans des fichiers spécifiques.
Dans le monde des bases de données, ce fichier s’appelle une table. Une table est un fichier structuré qui peut stocker des données d’un type spécifique. Une table peut contenir une liste de clients, un catalogue de produits ou toute autre liste d’informations.
Chaque table a un nom, et dans une table, chaque colonne a un nom. Aucun ordre particulier n’est conservé parmi les lignes d’une table, mais les lignes peuvent être récupérées dans un ordre déterminé par les valeurs de leurs colonnes. Les données d’un tableau sont logiquement liées. Toutes les données de table sont affectées à des espaces table.
Un tableau est constitué de données disposées logiquement en colonnes et en lignes.
Colonne (Column)
Les tableaux sont constitués de colonnes. Une colonne contient une information particulière dans un tableau.
La colonne est un champ unique dans une table. Tous les tableaux sont constitués d’une ou plusieurs colonnes.
La meilleure façon de comprendre cela est d’envisager les tables de base de données comme des grilles, un peu comme des feuilles de calcul. Chaque colonne de la grille contient une information particulière. Par exemple : dans une table “client“, une colonne contient le numéro de client, une autre contient le nom du client, et l’adresse, la ville, l’état et le code postal sont tous stockés dans leurs propres colonnes.
Ligne (Row)
Les données d’une table sont stockées dans des lignes.
La ligne est un enregistrement dans une table.
Encore une fois, en envisageant un tableau comme une grille de style feuille de calcul, les colonnes verticales de la grille sont les colonnes du tableau et les lignes horizontales sont les lignes du tableau.
Par exemple, une table client peut stocker un client par ligne. Le nombre de lignes dans la table est le nombre d’enregistrements qu’elle contient.
Types de tableaux
Table de base : une table de base est créée avec l’instruction CREATE TABLE et est utilisée pour contenir des données utilisateur persistantes.
Table de résultats : une table de résultats est un ensemble de lignes que le gestionnaire de base de données sélectionne ou génère à partir d’une ou plusieurs tables de base pour répondre à une requête.
Table récapitulative : une table récapitulative est une table définie par une requête qui est également utilisée pour déterminer les données de la table. Les tables récapitulatives peuvent être utilisées pour améliorer les performances des requêtes. Si le gestionnaire de base de données détermine qu’une partie d’une requête peut être résolue à l’aide d’une table récapitulative, le gestionnaire de base de données peut réécrire la requête pour utiliser la table récapitulative.
Table temporaire : une table temporaire déclarée est créée avec une instruction DECLARE GLOBAL TEMPORARY TABLE et est utilisée pour contenir des données temporaires au nom d’une seule application. Cette table est supprimée implicitement lorsque l’application se déconnecte de la base de données.
Index
Un index est une aide à l’accès aux données qui peut être créée sur une table. C’est un ensemble ordonné de pointeurs vers les lignes d’une table.
Chaque index est basé sur les valeurs des données dans une ou plusieurs colonnes d’une table. Un index est un objet distinct des données de la table. Lorsque vous créez un index, le gestionnaire de base de données construit la structure et la maintient automatiquement.
Un index peut servir les objectifs suivants :
Améliorer les performances. Dans la plupart des cas, l’accès aux données est plus rapide avec un index. Fournit un moyen rapide de rechercher des lignes dans une table en fonction de leurs valeurs dans les colonnes clés.
Applique les règles d’unicité en définissant une colonne ou un groupe de colonnes en tant qu’index unique ou clé primaire.
Fournit un ordre logique des lignes d’une table en fonction des valeurs des colonnes clés.
Regroupe les lignes d’une table dans le stockage physique selon l’ordre de l’index défini.
Vue (View)
Une vue offre une manière différente d’examiner les données dans une ou plusieurs tables. La vue est une table virtuelle constituée d’une instruction SQL SELECT qui accède aux données d’une ou plusieurs tables ou vues.
Une vue ne stocke jamais de données. Lorsque vous accédez à une vue, l’instruction SQL qui la définit est exécutée pour dériver les données demandées.
Une vue comporte des colonnes et des lignes, tout comme une table de base. Toutes les vues peuvent être utilisées comme des tables de base pour la récupération de données.
Vous pouvez utiliser des vues pour contrôler l’accès aux données sensibles, car les vues permettent à plusieurs utilisateurs de voir différentes présentations des mêmes données. Par exemple, plusieurs utilisateurs peuvent accéder à une table de données sur les employés. Un responsable voit des données sur ses employés, mais pas sur les employés d’un autre service. Un chargé de recrutement voit les dates d’embauche de tous les employés, mais pas leurs salaires ; un agent financier voit les salaires, mais pas les dates d’embauche. Chacun de ces utilisateurs travaille avec une vue dérivée de la table de base. Chaque vue apparaît comme une table et a son propre nom.
Lorsque la colonne d’une vue est directement dérivée de la colonne d’une table de base, cette colonne de vue hérite de toutes les contraintes qui s’appliquent à la colonne de la table de base. Par exemple, si une vue inclut une clé étrangère de sa table de base, les opérations d’insertion et de mise à jour utilisant cette vue sont soumises aux mêmes contraintes référentielles que la table de base. De plus, si la table de base d’une vue est une table parent, les opérations de suppression et de mise à jour utilisant cette vue sont soumises aux mêmes règles que les opérations de suppression et de mise à jour sur la table de base.
Une vue peut devenir inopérante (par exemple, si la table de base est supprimée) ; si cela se produit, la vue n’est plus disponible pour les opérations SQL.
La meilleure façon de reconnaître les vues est de regarder un exemple. (Vous étudierez plus en détail les SQL. Cet exemple est juste pour vous faire comprendre le concept de vues).
Vous avez les trois tables suivantes :
Clients
Commandes
Détails de la commande
Vous devez récupérer les clients qui ont commandé un produit spécifique.
Les détails de la colonne sont les suivants :
La requête est la suivante :
SELECT NOM_CLIENT, PRENOM_CLIENT
FROM CLIENTS, COMMANDES, DETAILSWHERE CLIENTS.ID_CLIENT = COMMANDES.ID_CLIENT
AND DETAILS.NUM_COMMANDE = COMMANDES.NUM_COMMANDE
AND ID_PRODUIT = 'BANANE' ;
Toute personne ayant besoin de ces données devrait comprendre la structure de la table, ainsi que la façon de créer la requête et de joindre les tables. Pour récupérer les mêmes données pour un autre produit (ou pour plusieurs produits), la dernière clause WHERE devrait être modifiée.
Imaginez maintenant que vous puissiez encapsuler toute cette requête dans une table virtuelle appelée “PRODUITS”. Vous pourriez alors simplement faire ce qui suit pour récupérer les mêmes données :
SELECT NOM_CLIENT, PRENOM_CLIENTFROM PRODUITS
WHERE ID_PRODUIT = 'BANANE' ;
C’est là que les vues entrent en jeu. “PRODUITS” est une vue et, en tant que vue, elle ne contient aucune colonne ni donnée. Au lieu de cela, il contient une requête, la même requête utilisée ci-dessus pour joindre correctement les tables.
Pourquoi utiliser les vues ?
Voici quelques utilisations courantes des vues :
Pour extraire des données de plusieurs tables.
Pour réutiliser les instructions SQL.
Pour simplifier les opérations SQL complexes. Une fois la requête écrite, elle peut être réutilisée facilement, sans avoir à connaître les détails de la requête sous-jacente elle-même.
Pour exposer des parties d’un tableau au lieu de tableaux complets.
Pour sécuriser les données. Les utilisateurs peuvent avoir accès à des sous-ensembles spécifiques de tables au lieu de tables entières.
Pour modifier le formatage et la représentation des données. Les vues peuvent renvoyer des données formatées et présentées différemment de leurs tables sous-jacentes.
Pour la plupart, une fois les vues créées, elles peuvent être utilisées de la même manière que les tables. Vous pouvez effectuer des opérations SELECT, filtrer et trier des données, joindre des vues à d’autres vues ou tables, et éventuellement même ajouter et mettre à jour des données. Certaines restrictions s’appliquent à ce dernier élément. La chose importante à retenir est que les vues ne sont que cela, des vues sur des données stockées ailleurs. Les vues ne contiennent pas de données elles-mêmes, de sorte que les données qu’elles renvoient sont extraites d’autres tables. Lorsque des données sont ajoutées ou modifiées dans ces tables, les vues renverront ces données modifiées.
Il existe des problèmes de performances avec les vues car les vues ne contiennent aucune donnée, toute récupération nécessaire pour exécuter une requête et qui doit être traitée chaque fois que la vue est utilisée. Si vous créez des vues complexes avec plusieurs jointures et filtres, ou si vous imbriquez des vues, vous constaterez peut-être que les performances sont considérablement dégradées. Assurez-vous de tester l’exécution avant de déployer des applications qui utilisent beaucoup les vues.
Synonyme
Autre nom privé pour une table ou une vue.
Un synonyme ne peut être utilisé que par la personne qui l’a créé.
Lorsqu’une table ou une vue est supprimée, tous les synonymes qui y sont définis sont également supprimés.
Alias
Nom défini localement pour une table ou une vue dans le même sous-système DB2 local ou dans un sous-système DB2 distant. Les alias confèrent à DB2 une indépendance d’emplacement car un alias peut être créé pour une table sur un site distant, évitant ainsi à l’utilisateur de spécifier le site qui contient les données. Les alias peuvent également être utilisés comme un type de synonyme global car ils peuvent être consultés par n’importe qui, pas seulement par leur créateur.
Lorsqu’une table/vue est supprimée, tous les alias définis dessus ne sont PAS supprimés.
Utilisez des synonymes pour le développement de programmes, utilisez des alias pour les applications distribuées et utilisez des vues pour la sécurité et l’adhésion.
Le tableau suivant donne la différence entre “Synonyme” et “Alias” :
Synonyme
Alias
Un autre nom pour une table ou une vue qui doit résider dans le sous-système DB2 local
Un autre nom pour une table ou une vue qui peut résider dans le sous-système DB2 local ou distant
Ne peut être utilisé que par son créateur
Peut être utilisé par n’importe qui, y compris son créateur
Est supprimé lorsque la table/vue correspondante est supprimée
Pas supprimé même lorsque la table/vue correspondante est supprimée
Différences entre Synonyme et Alias
Stockage physique des données
La figure suivante représente la façon dont les données sont stockées physiquement dans le système DB2 :
Pools de mémoire tampon (Buffer Pool)
Les pools de mémoire tampon sont des zones de stockage virtuel dans lesquelles DB2 stocke temporairement des pages d’espaces table ou d’index.
Les pools de mémoire tampon améliorent les performances de la base de données. Si une page de données nécessaire se trouve déjà dans le pool de mémoire tampon, cette page est accessible plus rapidement que si cette page devait être lue directement à partir du disque. Le gestionnaire de base de données a des agents dont les tâches consistent à récupérer les pages de données du disque et à les placer dans le pool de mémoire tampon (prefetchers), et à réécrire les pages de données modifiées du pool de mémoire tampon sur le disque (nettoyeurs de page).
La lecture et l’écriture de pages de données vers et depuis le disque sont appelées entrée/sortie disque (E/S). Éviter l’attente associée aux E/S disque est le principal moyen d’améliorer les performances de la base de données. La manière dont vous créez le pool de mémoire tampon et configurez le gestionnaire de base de données et les agents associés au pool de mémoire tampon contrôle les performances de la base de données.
Dans DB2, vous avez la possibilité d’allouer 80 pools de mémoire tampon :
50 pools de mémoire tampon 4K et
10 pools de mémoire tampon 8K, 16K et 32K.
Le pool de mémoire tampon par défaut est BP0.
Relation entre les espaces de table et les pools de mémoire tampon
Chaque espace table est associé à un pool de mémoire tampon spécifique dans une base de données. Un tablespace est associé à un bufferpool. La taille du pool de mémoire tampon et de l’espace de table doit être identique. Plusieurs pools de mémoire tampon vous permettent de configurer la mémoire utilisée par la base de données pour augmenter ses performances globales.
Tailles des pools de mémoire tampon
La taille de la page du pool de mémoire tampon est définie lorsque vous utilisez la commande “CREATE DATABASE“. Si vous ne spécifiez pas la taille de la page, elle prendra la taille de page par défaut, qui est de 4 Ko. Une fois le bufferpool créé, il n’est plus possible de modifier la taille de la page ultérieurement