Comprendre l'importance de l'indépendance des niveaux dans une base de données
Maîtriser l'utilisation des vues pour gérer les accès et renforcer la confidentialité
Explorer le rôle du dictionnaire de données dans la gestion des niveaux
Rappel du problème
La situation :
Il peut être nécessaire de réorganiser certaines parties de l'application pour cause de :
Performances
Évolutivité
Il faut :
Pouvoir le faire sans changer son comportement
« modularité » entre les différents niveaux de l'application (analogie avec l'esprit objet)
Les trois niveaux des applications de bases de données
« Logique » : tables relationnelles
« Physique » : détails de leur organisation physique sur le disque
« Externe » : programmes accédant aux tables relationnelles
Norme ANSI 1978
Exemple d'architecture
Visualisation de l'organisation des trois niveaux et leurs relations
Motivation : Exemple 1 - Performances
Les performances d'une requête sont influencées par le stockage physique des données
Possibilité de modifier cette organisation sans toucher aux tables relationnelles
Le niveau logique doit être séparé du niveau physique pour permettre des optimisations indépendantes
Motivation : Exemple 2 - Évolutivité
Les fonctionnalités évoluent, nécessitant des modifications de tables
Les programmes existants doivent fonctionner de la même manière malgré les changements
Le niveau externe doit rester indépendant du niveau logique
Outils fournis par le SGBD
Vues : facilitent l'indépendance entre niveaux externe et logique
Dictionnaire de données : maintient l'indépendance entre niveaux logique et physique
Exemple d'utilisation d'une vue
Situation :
Table : Billet (client, destination, prix)
Tâche : Secrétaire gère les clients pour Saint Tropez
Requête simplifiée :
select client
from billet
where destination like'St Trop%';
Problèmes avec la requête directe
Confort : Toto maîtrise mal SQL et les tables de l'application
Grandes quantités : la requête est réexécutée à chaque fois
Confidentialité : accès non nécessaire à certaines colonnes ou lignes
Indépendance des niveaux : requête échoue si réorganisation des tables
Principe de solution : Alias
Le programmeur associe un alias à la requête
Toto utilise uniquement cet alias
Définition des vues
Une vue est une table virtuelle dont le contenu est défini par une requête
Son contenu peut être :
Recalculé à chaque appel
Matérialisé (et maintenu par le système)
Création d'une vue
createview billetsainttrop asselect client
from billet
where destination like'St Trop%'
(Matérialisation ou non : hors programme)
Remarque :
revokeselecton billet from toto;
Conséquences de l'utilisation des vues
Toto tape simplement :
select*from billetsainttrop;
Confort : pas de quotient SQL complexe
Grandes quantités : gain de temps si matérialisé
Confidentialité respectée : Toto ne connaît que la table virtuelle billetsainttrop
Indépendance des niveaux : requête inchangée malgré réorganisation des tables
Avantages supplémentaires des vues
Maintenance :
Factorisation des requêtes dans l'application via « appel à la vue »
Pas de duplication de code
Vocabulaire clé
Le programme du niveau externe est indépendant du niveau logique : les mises à jour du niveau logique ne
l'affectent pas
Le programme du niveau externe satisfait la propriété d'indépendance par rapport au niveau logique
Remarque sur les mises à jour du schéma
La mise à jour du schéma est SPI (Sans Perte d'Information) si elle ne
perd pas d'information nécessaire à la vue
Exemple : Cette requête rendrait impossible de produire le même
résultat
altertable billet dropcolumn destination;
L'indépendance des niveaux
L'indépendance des niveaux est possible si, et seulement si, la mise à jour est SPI
Règles pour les mises à jour des vues
Cas particuliers selon le type de jointure ou de calcul
Exemple :
insertinto billetsainttrop values...
dépend des contraintes
d'intégrité
Résumé : Vues
Le concept de vue permet de gérer :
Indépendance des niveaux
Confidentialité
Grandes quantités
Facilite le confort d'utilisation et la maintenance
Le dictionnaire de données
Utilisé pour :
Indépendance des niveaux : traduction entre logique et physique
Répertorier les informations sur les objets de la base
Stocké dans des tables système accessibles via des vues
Exemple de requêtes sur le dictionnaire de données
Accéder aux tables système pour obtenir des informations sur la base
select*from dictionary;select table_name from user_tables;select table_name from all_tables where owner ='PHPARIS';
Indépendance du niveau physique
Certaines mises à jour n'obligent pas le système à réorganiser le disque
Exemple : ajout ou suppression d'une colonne d'une table
Assuré par le dictionnaire de données
Indépendance du niveau logique
Le niveau logique (tables) ne dépend pas du niveau externe (vues)
Récapitulatif
Indépendance des niveaux :
Indépendance du niveau externe par rapport aux mises à jour du schéma logique : assurée par les vues
Indépendance du niveau logique par rapport aux mises à jour du niveau physique : assurée par le
dictionnaire de données
Compétences à acquérir
Analyse :
Détecter et illustrer les occurrences d'indépendance des niveaux dans une application
Décrire le comportement d'une application en présence de vues
Construction :
Gérer l'indépendance des niveaux dans une application
Utiliser le dictionnaire de données pour récupérer des informations essentielles
Confidentialité et encapsulation
Confidentialité : droits d'accès
Une procédure stockée est un objet de la base de données, avec ses propres droits
d'accès.
L'appel d'une procédure stockée est une « action » qui peut être limitée par des droits d'accès.
Autorisation : Les droits d'accès définissent qui peut exécuter une procédure.
Format : (utilisateur, exécuter, procédure)
Exemple : grant execute on p to toto autorise l'utilisateur toto à exécuter la
procédure p.
Encapsulation : Le code de la procédure p peut accéder aux tables même si
l'utilisateur qui l'exécute n'a pas les droits directs.
Le propriétaire de la procédure doit disposer des droits sur les tables utilisées.
Permet d'exposer certaines actions sans donner un accès direct aux tables sous-jacentes (principe de
confidentialité).
Démo : Exemple de gestion des droits d'exécution sur une procédure.
Application : encapsulation
Utilisation des outils de confidentialité pour autoriser un utilisateur à exécuter un traitement sans
accès direct aux tables.
Principe :
Interdire totalement l'accès direct aux tables sensibles.
Créer une procédure qui effectue le traitement nécessaire, encapsulant ainsi l'accès aux données.
Accorder des droits d'exécution sur cette procédure seulement, et non sur les tables.
Cette approche protège l'intégrité et la sécurité des données en limitant les actions disponibles pour
les utilisateurs.
Analogie : Similaire à l'utilisation de méthodes dans un programme Java pour encapsuler
l'accès aux attributs privés d'une classe.
Confidentialité PL/SQL : compétences à acquérir
Encapsulation : Savoir quand et comment appliquer le principe d'encapsulation pour
protéger les données sensibles.
Comprendre les cas d'utilisation pour limiter l'accès direct aux tables et contrôler l'accès via des
procédures stockées.
Limitations du système de droits SQL :
Certaines situations de confidentialité ne peuvent pas être complètement assurées avec les commandes
GRANT et REVOKE seules.
Exemple : Protéger les données personnelles tout en permettant des calculs globaux (agrégats).
Solution possible : encapsuler l'accès dans des procédures et fonctions PL/SQL.
Acquérir ces compétences permet de gérer la sécurité et l'accès aux données de manière plus granulaire et
sécurisée.
Pour obtenir le PDF de ces diapositives et les imprimer, cliquez sur ici et utilisez ensuite l'imprimante PDF de votre navigateur.
l'imprimante PDF de votre navigateur.