chap6

Chapitre 7

Chapitre 6 : La protection de l'information

Comme nous l'avons évoqué dans le premier chapitre, un SGBD comprend trois niveaux d'abstraction différents. Le troisième chapitre est consacré au niveau conceptuel qui regroupe et gère l'ensemble des informations de l'entreprise. Le prochain s'intéresse aux méthodes de stockage du niveau interne. Nous nous plaçons ici au niveau externe, là où intervient l'utilisateur final dont on doit pouvoir contrôler les actions sur les données de la base.

La démarche consistant à centraliser les données induit un certain nombre de problèmes, tant pour l'utilisateur final d'un SGBD que pour les programmes chargés de contrôler la protection, et la cohérence des informations de la base.

La vision de l'entreprise qu'à l'utilisateur final est limitée à l'ensemble des informations liées à son travail (par exemple, le service du personnel ne se préoccupe pas de la gestion des stocks). Elle ne correspond donc pas au schéma global tel qu'il est décrit au niveau conceptuel. Le SGBD doit prendre en compte ce problème en recréant l'environnement de travail habituel de chaque utilisateur.

En outre, il est indispensable de limiter l'accès des utilisateurs aux informations de l'entreprise. De même que de nombreux systèmes d'exploitation offrent des possibilités de protection sur les fichiers par affectation de droits de lecture, d'écriture ou d'exécution, des moyens d'assurer la confidentialité des informations contenues dans la base doivent exister, dans les SGBD.

Toutefois, à la différence des systèmes d'exploitation, les objets sur lesquels ces droits doivent pouvoir être distribués sont plus variés. L'utilisateur d'un système d'exploitation possède un droit sur l'ensemble d'un fichier. L'exigence typique d'un utilisateur de SGBD est de demander des droits d'accès, non pas à une relation du niveau conceptuel, mais à un ensemble d'informations. Celles-ci sont issues d'un certain nombre de relations de ce niveau. La seule particularité de cet ensemble est sa conformité à un prédicat (cet ensemble de données répond à un critère de sélection).

En outre, la confidentialité n'est pas le seul facteur de contrôle des données d'un SGBD. Inroduisons maintenant la notion d'intégrité des données qui résulte de l'existence de liens sémantiques (appelés contraintes d'intégrité) entre les données de la base, lesquels doivent être vérifiés après chaque modification de la base.

VI.1. Les vues externes

Dans les modèles à base de pointeurs (hiérarchique et réseau), sont limitées les possibilités d'accès de l'utilisateur à des sous-schémas stricts du schéma de la base. Un certain nombre de champs du schéma initial peuvent être cachés ou renommés, mais la structure de l'information reste la même. Il est, par exemple, impossible à l'utilisateur final de définir son propre schéma provenant du "rapprochement" (ou jointure en relationnel) de deux schémas du niveau conceptuel. Ce qui signifie par exemple: - que l'on peut connaître les noms, prénoms et niveaux de tous les nageurs (masquage du numéro NN et remplacement de QUALITE en NIVEAU) ;

- que l'on ne peut pas connaître les noms et prénoms des nageurs d'excellent niveau (car on ne peut pas isoler les enregistrements des excellents nageurs des autres) ;

- que l'on ne peut pas connaître uniquement les noms de tous les nageurs et les dates auxquelles ces nageurs se sont baignés (impossibilité de changer la structure des enregistrements visibles donc de visualiser un résultat du type jointure dans le modèle relationnel).

La solution idéale à ces nombreux problèmes est de recréer, pour chaque utilisateur, sa propre vision de l'entreprise (sans avoir bien entendu à répéter l'information au sein de la base) en laissant au SGBD le soin de gérer la confidentialité et l'intégrité des données.

Le mécanisme des vues des SGBD relationnels a l'ambition de résoudre un grand nombre de problèmes que les modèles précédents n'ont pas su traiter. Nous verrons successivement les objectifs de ce système et constaterons ensuite la facilité de leur mise en śuvre. Nous évoquerons enfin, les limites de ce mécanisme.

VI.1.1. Les objectifs : voir le monde comme il n'est pas !

Le mécanisme des vues permet de répondre aux besoins suivants : - adaptation aux applications Les applications ne doivent pas dépendre du schéma adopté au niveau conceptuel. L'utilisateur manipule plus naturellement les données sous leur forme habituelle plutôt que de devoir les retrouver et les traiter au sein d'une quantité importante de données parasites.
- intégration des applications existantes Les données vues par l'utilisateur étant les mêmes que celles disponibles avant d'avoir accès à un SGBD, il doit pouvoir, grâce à de faibles modifications, aisément adapter ses anciennes applications.
- dynamique du schéma de la base Les modifications du schéma conceptuel, parfois nécessaires pour des raisons de performances ou de nouveaux besoins, ne doivent pas impliquer de changements des schémas du niveau externe si ces derniers n'évoluent pas. Si cette règle est respectée, ces modifications n'entraînent pas non plus la réécriture des applications du niveau externe.
- confidentialité et sécurité L'administrateur de la base définit les vues et les utilise pour définir précisémment les droits d'accès d'un utilisateur. Ces derniers peuvent ainsi dépendre de la valeur des informations.
- décentralisation de l'administration d'une BD Chaque utilisateur ou chaque équipe de développement évoluant au niveau externe doit être responsable des données qu'il gère avec ses propres droits. Il devient administrateur de sa vue et peut déléguer ses droits à un autre utilisateur.
- hétérogénéité des modèles Pouvoir présenter un accès homogène et unifié à un ensemble de bases de données de types différents est particulièrement intéressant . Le mécanisme de vue permet cette vision unique.

VI.1.2. Le relationnel simplifie les vues

Le modèle relationnel, grâce à la manipulation ensembliste des données, autorise la définition d'un ensemble particulier de tuples à l'aide d'un critère de recherche. Ces tuples peuvent être composés à partir de plusieurs relations de base. Le résultat de n'importe quelle requête est une relation au même titre que n'importe quelle relation effectivement implantée en machine ; les résultats d'une requête constituent ainsi une relation ordinaire qui peut servir de base à une nouvelle manipulation.

Définir une vue revient alors à déterminer le critère qui permet de rassembler les tuples désirés et de les présenter sous la forme souhaitée. Une telle opération se réalise aisément à l'aide de l'algèbre relationnelle, mais est encore simplifiée par l'utilisation des langages assertionnels des systèmes relationnels actuels.

Dans un systèmme relationnel, la notion d'une vue est donc quasi identique à une interrogation de la base. Attention cependant : la création d'une vue définit le critère d'obtention de la vue désirée. Les tuples résultats ne sont pas réellement constitués ; le mécanisme reste entièrement virtuel. Nous allons maintenant en donner quelques exemples.

Exemple 1 :

Créer la vue des nageurs dont la qualité est bonne ou excellente.
CREATE VIEW BONS_NAGEURS AS SELECT NN, NOM, PRENOM, QUALITE
FROM NAGEURS
WHERE QUALITE IN ('Excellente', 'Bonne'); Exemple 2 : Des vues peuvent être définies à partir d'autres vues . Créer la vue des nageurs appartenant à BONS_NAGEURS et dont la qualité est excellente.
CREATE VIEW CHAMPIONS AS SELECT NN, NOM, PRENOM
FROM BONS_NAGEURS
WHERE QUALITE = 'Excellente'; Exemple 3 : On peut aussi créer la vue des mauvais nageurs :
CREATE VIEW MAUVAIS_NAGEURS AS SELECT NOM, PRENOM
FROM NAGEURS
WHERE QUALITE = 'Mauvaise'; Exemple 4 : Des vues peuvent également être crées à partir de critères plus complexes. Par exemple, créer la vue des exploits, c'est-à-dire des nageurs ayant pris des bains de plus de 10 heures. On souhaite conserver des informations sur le nom et le prénom du nageur, le nom de la plage où a eu lieu l'exploit, ainsi que la date et la durée du bain.
CREATE VIEW EXPLOITS AS SELECT N.NN, N.NOM, N.PRENOM, N.QUALITE, P.NOMP, B.DATE, B.DUREE
FROM NAGEUR N, BAIGNADE B, PLAGE P
WHERE N.NN = B.NN
AND B.NP = P.NP
AND B.DUREE > 600mn ;

VI.2. Manipulation au travers des vues

VI.2.1. Consultation au travers des vues

L'interrogation exprimée sur une vue est toujours possible. Une vue est une relation virtuelle. Chaque requête portant sur la vue est transformée en une requête portant sur les relations réelles du niveau conceptuel. Celles à partir desquelles la vue a été définie.

Exemple 1 :

Rechercher, dans la vue BONS_NAGEURS, les noms des excellents nageur se prénommant Paul.
SELECT NOM
FROM BONS_NAGEURS
WHERE QUALITE = 'Excellente'
AND PRENOM = 'Paul';
Cette requête, exprimée au niveau conceptuel, devient :
SELECT NOM
FROM NAGEURS
WHERE QUALITE IN ('Excellente', 'Bonne')
AND QUALITE = 'Excellente'
AND PRENOM = 'Paul';
Après optimisation elle devient :
SELECT NOM
FROM NAGEURS
WHERE QUALITE = 'Excellente'
AND PRENOM = 'Paul';

VI.2.2. Influence sur l'optimisation des requêtes

Nous avons déjà mis en évidence dans le modèle relationnel la simplicité du concept de vue et de sa mise en śuvre . Dans ce paragraphe, nous revenons sur cette simplicité en étudiant son influence sur l'optimisation des requêtes.

Les vues sont des relations fictives (ou virtuelle, ou dérivée). Les requêtes formulées sur ces vues sont transformées, en requêtes à appliquer à des relations de base réellement implantées en machine.

Comment le SGBD transforme t-il le niveau vue en niveau conceptuel ? Il concatène simplement la requête de l'utilisateur à la requête créant la vue et optimise l'ensemble. Nous visualisons aisément ceci à l'aide des arbres algébriques.

Créer la vue correspond à un arbre algébrique :

la requête sur la vue correspond également à un arbre algébrique :

La requête transformée finalement appliquée aux relations correspond à un arbre algébrique résultant de la concaténation des deux précédents.

L'optimiseur peut en conséquence modifier l'arbre pour accélérer son exécution.

Cet exemple d'optimisation, ici très simple, ne met en jeu que des restrictions. Cette étape est cependant importante et parfois complexe : mettre bout à bout deux arbres optimisés séparément ne donne pas nécessairement un arbre global optimal. Repasser par l'optimiseur pour déterminer l'arbre optimal (descente des opérateurs unaires, ordonnancement des jointures…) est indispensable.

VI.2.3. Mise à jour à travers les vues

De nouvelles difficultés surgissent lors de la mise à jour. Même si l'utilisateur possède des droits de modification sur la vue, les modifications qu'il souhaite apporter à la base demeurent indéfinies dans de nombreux cas. Voyons quelques exemples ; Exemple 1 : Peut-on insérer par la vue BONS_NAGEURS le tuple (73, 'Albert', 'COULE', 'Excellente') ? (on suppose que la clé NN=73 est libre). Cette insertion ne pose pas de problème si l'utilisateur possède un droit d'accès en insertion sur la vue. Tous les champs de la relation conceptuelle NAGEURS dont dépend la vue sont définis. L'insertion peut avoir lieu.
Exemple 2 : Peut-on insérer à travers la vue CHAMPIONS le tuple (73, 'Albert', 'COULE') ? (on suppose que la clé NN=73 est libre). Ce cas est déjà plus complexe, mais cette vue correspond à une seule valeur de l'attribut manquant QUALITE. L'insertion du tuple devient celle du tuple (73, 'Albert', 'COULE', Excellente') dans la relation NAGEURS.
Exemple 3 : Voyons maintenant un exemple de modifications. Si la modification au sein de la vue des BONS_NAGEURS du tuple (73, 'Albert', 'COULE', 'Excellente') en (73, Albert', 'COULE', 'Bonne') semble naturelle, transformer ce tuple en (73, 'Albert', 'COULE', 'Mauvaise') est moins évident : la modification qui fait disparaitre un tuple de la vue des BONS_NAGEURS est-elle autorisée? La question de savoir si ce droit doit être donnée ou non est intéressant. Un utilisateur a-t-il le droit de "faire disparaître" des tuples de sa vue ?
Exemple 4 : Peut-on maintenant insérer par la vue MAUVAIS_NAGEURS le tuple ('Albert', 'COULE') ?

Comme dans l'exemple numéro 2, la valeur de l'attribut QUALITE de la relation NAGEURS. Mais, dans le cas présent, la valeur de la clé, l'attribut NN, doit également être complétée tout d'abord, Albert COULE peut déjà être recensé dans une autre catégorie de la base. L'insertion peut n'être en fait qu'une modification. Par exemple, Albert COULE peut être recensé en tant que bon nageur. Il s'agit alors d'une modification avec les risques que cela comporte. Nous les avons évoqués dans l'exemple précédent.

Albert COULE peut être une personne différente de toutes celles qui sont déjà recensées dans la base. Dans ce cas le traitement doit être l'ajout d'un tuple dans la relation NAGEURS sous un numéro différent.

Exemple 5 : Enfin, pour insérer un tuple du type (73, 'Albert', 'COULE', NULL) depuis la vue BONS_NAGEURS on ne sait pas si le niveau d'Albert COULE est bon ou excellent. Doit-on accepter une telle insertion ? En effet, pour l'utilisateur de la relation NAGEURS, rien n'indique que Albert COULE est bon ou excellent nageur et non pas de niveau faible ou médiocre. L'étude de ces exemples nous montre que le mécanisme des vues externes, apporte des avantages en confidentialité et en confort de travail considérables, mais pose des problèmes non résolus dans le domaine des mises à jour. L'utilisateur qui dispose des droits nécessaires, n'est pas certain de pouvoir modifier certaines données auxquelles il a pourtant accès.

Les produits actuels limitent les mises à jour à travers les vues de façon drastique : seules les vues mono-relation sans fonction dont la définition conserve la clé sont concernées. Toutes les autres ne peuvent être manipulées qu'en interrogation.

VI.3. Confidentialité

La confidentialité assure la protection des données de la base contre les accès non autorisés.

Elle est généralement obtenue en définissant des autorisations diverses sur les objets susceptibles d'être manipulés par les usagers. Le choix de l'objet détermine la méthode de vérification des droits d'accès. Ces droits sont généralement de plusieurs sortes (lecture, modification et droit d'administration) car ils doivent répondre aux différentes exigences des utilisateurs.

Quelque soit la nature du SGBD, cette protection doit porter sur la plus petite unité d'information accessible par un utilisateur. Le modèle relationnel définie n'importe quel objet (relation, vue, ensemble de tuples, l'attribut d'une relation, d'une vue ou d'un tuple) par un simple critère permettant sa sélection. La définition des droitss sur tout objet, aussi petit soit il est théoriquement possible, mais l'encombrement occasionné par de telles informations nécessite une gestion trop gourmande en performances. Ainsi, la gestion de droits dans le système relationnels d'aujourd'hui est elle réduite aux seules relations et vues.

La plupart des Systèmes de Gestion de Bases de Données offrent, outre les droits habituels de lecture et de modification, des possibilités d'administration comparables aux services offerts par les systèmes d'exploitation. Un utilisateur peut ainsi transmettre ses propres droits, droits d'administration inclus, à un autre utilisateur. Les SGBD compensent ainsi partiellement les inconvénients de la centralisation qu'ils imposent.

VI.3.1. Autorisations sur une relation ou sur une vue

Les droits accordés - ou autorisations - sur les relations ou vues sont de trois types : - droit de consultation ;
- droit de modification (mises à jour, suppression, insertion) ;
- droit d'administration (définir les contraintes d'intégrité, attribuer les autorisations, détruire ou modifier le schéma de la relation). Insistons plus particulièrement sur le droit d'administration qui est la seule contre-partie à la centralisation à outrance des données. Chaque utilisateur retrouve un certain pouvoir de décision : il a le droit de déléguer tout ou partie de ses droits sur les relations créées.

Forcer tout utilisateur à passer par une vue, conduit à considérer que l'utilisateur à des droits uniquement sur ce qu'il voit. Le mécanisme est très souple et permet de définir un droit en fonction d'un critère de sélection. Ainsi, le directeur d'un service ne peut, dans le cas d'une relation EMPLOYE lire que les salaires des membres de son propre service. De nombreuses limitations, dues à l'impossibilité des mises à jours générales à travers les vues, limitent ce mécanisme à des utilisations particulières.

VI.3.2. La cession de droits

Dans le standard SQL, le mécanisme d'attribution et de révocation des droits reste classique : les droits portent les relations de base. La requête permettant de céder ou de retirer tout ou partie de ses droits à un autre usager est la suivante : GRANT | REVOKE <liste de droits> ON <nom de relation>
TO | FROM <listes d'usagers>
[WITH GRANT OPTION] Les droits possibles sont les suivants : SELECT
INSERT
UPDATE (nom d'attribut)
DELETE Le créateur d'une relation dispose de tous les droits sur la relation créée. Il a le droit d'administration, c'est à dire qu'il peut détruire ou modifier le schéma de sa relation. Il peut donner des droits aux autres usagers par la clause GRANT ; si la clause WITH GRANT OPTION est spécifiée, les droits sont transmissibles en aval. Notons que l'instruction REVOKE retire également les droits transmis en aval sur la relation, c'est à dire qu'un utilisateur peut se voir retirer ses droits, non seulement par celui qui les lui a concédés, mais aussi par un plus ancien donateur dont il ignorait l'existence... jusqu'au créateur lui-même.

VI.4. Intégrité sémantique

VI.4.1. Les différents types de contraintes

On dresse ici une typologie possible des contraintes d'intégrité : Domaine de variation C'est la définition du domaine auquel appartient la valeur d'un attribut (entier, réel, texte, date…). Chaque donnée de la base doit vérifier cette contrainte qui peut correspondre à une simple concordance de type (c'est le cas de l'entier) ou à une condition plus complexe (c'est le cas du type date qui suppose des connaissances le nombre de jour dans un mois, les années bissextiles, etc.).
Plages de valeurs C'est la restriction du domaine à un sous-ensemble d'un domaine. Par exemple, on peut imposer qu'un âge soit compris entre 0 et 150 ans, qu'aucun bain ne soit jamais pris entre novembre et mars…
Non nullité La "nullité" ne correspond pas à un entier de valeur 0 ou à une chaîne de caractères vide, mais, pour tout type, à une valeur indéfinie ou non renseignée lors d'une mise à jour (NULL). Il peut être indispensable d'interdire la nullité à certains champs pour la permettre à d'autres. Par exemple, une clé de relation doit avoir une valeur non nulle, que ce soit un numéro ou une chaîne de caractère, puisqu'elle est le seul moyen de distinguer deux tuples ayant les mêmes valeurs d'attributs.
Unicité L'unicité est également une notion importante, en particulier pour la définition des clés qui doivent être uniques.
Dépendances fonctionnelles Les dépendances fonctionnelles sont des contraintes d'intégrité. Par exemple, un numéro de sécurité sociale détermine un tuple définissant un individu.
Dépendances référencielles Elles indiquent que les valeurs d'un attribut (ou d'un groupe d'attributs) d'une relation R1 doivent déjà être définies dans un autre attribut (ou un autre groupe d'attributs). Par exemple, prendre un bain implique que NN et NP soient respectivement un individu et une plage et qu'ils figurent dans les tables appropriées. Un nageur peut exister sans nécessairement avoir pris de bain, mais un bain ne peut être pris que si le nageur existe.
Contraintes temporelles Ces contraintes vérifient l'évolution des données par rapport au temps. Par exemple, le salaire affecté à un poste ne peut pas diminuer.
Contraintes avec agrégats Ces contraintes ne portent pas sur la valeur d'un atome, mais sur une fonction concernant une collection de valeurs d'atomes. Par exemple, la durée moyenne des bains doit être supérieure à deux minutes.
Contraintes générales Il existe également des contraintes qui n'appartiennent à aucune des catégories définies ci-dessus et sont plus générales. Par exemple : le nombre de bains pris par une personne ne peut pas décroître. Cette contrainte fait intervenir à la fois la notion de contrainte temporelle et de contrainte avec agrégats.

VI.4.2. Comment définir une contrainte d'intégrité ?

Comme nous pouvons le constater, les contraintes qui viennent d'être décrites sont mises en śuvre de différentes façons. Par exemple, les contraintes exprimant les dépendances fonctionnelles servent à la conception du schéma de la base : c'est le processus de conception qui assure automatiquement la vérification des contraintes de dépendance fonctionnelle.

Toutefois, toutes les contraintes ne sont pas liées à l'étape de conception de la base. Le langage de manipulation de données doit donc permettre la définition des contraintes d'intégrités. Ces contraintes peuvent alors être considérées comme des propriétés (assertions) indépendantes les unes des autres. Toute modification de la base de données doit les respecter. Ce formalisme est d'ailleurs le mieux adapté au modèle relationnel.

VI.4.3. Comment regrouper (classer) les contraintes ?

On peut regrouper les contraintes d'intégrité suivant différents critères : leur coût de validation, leurs caractéristiques individuelles (la contrainte s'applique tuple à tuple) ou ensembliste (la contrainte s'applique sur un ensemble de tuples), le fait qu'elles soient spécifiques d'une relation qu'elles en mettent plusieurs en jeu, etc.

VI.4.4. Contraintes d'intégrités et transactions bases de données

La notion de transaction sur une base de données est définie comme un ensemble d'actions qui font passer la base d'un état cohérent à un autre état cohérent (une BD cohérente est une BD où toutes les contraintes d'intégrité sont satisfaites). Trois fonctions d'un SGBD sont concernées : le contrôle de concurrence, la fiabilité et l'intégrité sémantique. Nous ne traitons dans ce paragraphe que le troisième aspect : le respect de règles sémantiques.

Le problème concerne l'instant de vérification des différentes contraintes : à quel moment doit-on vérifier les contraintes d'intégrité ? Quelles sont les contraintes vérifiables au gré des mises à jour de la base. Quelles sont celles qui sont vérifiées à la fin de la transaction ? Voyons quelques exemples.

Exemple 1 :

Considérons la relation NAGEURS (NN, NOM, PRENOM, QUALITE) et imposons la contrainte :

"Tous les nageurs dont le numéro est supérieur à 1000 sont d'excellent niveau." Cette contrainte est vérifiable à chaque insertion de nouveau tuple ou à chaque modification de la relation NAGEURS.

Exemple 2 :

Considérons maintenant la même relation NAGEURS avec la contrainte d'intégrité suivante (contrainte avec agrégats) :

"Il doit y avoir autant de nageurs d'excellent niveau que de mauvaise qualité." Supposons que l'on désire insérer dans la base un ensemble de nouveaux nageurs. A chaque insertion de nageur d'excellente ou de mauvaise qualité, la contrainte n'est pas vérifiée. Pourtant, cette même contrainte peut très bien être vérifiée lorsque touts les nouveaux nageurs ont été ajoutés.

Notifier au SGBD que l'ensemble des modifications effectuées précédemment doit être validé et que les contraintes d'intégrité peuvent désormais être vérifiées s'avère donc indispensable . L'ensemble des modifications validées marque une période appelée transaction.

VI.5. Conclusions

Garantir la cohérence de l'information est un apport très important des Systèmes de Gestion de Bases de Données. L'utilisateur est libéré d'une tâche parfois difficile. Le système vérifie lui même des contraintes et des droits associés aux données. Vérifier les contraintes et les droits d'accès dans les PA des anciens systèmes était peu cohérent.

VI.6. Références

[Ullman 80] J. ULLMAN :"Principles of Databases Systems" Computer Sciences Press, 1980.

[Bancilhon 79] F. BANCILHON : "Supporting View Updates in Relational Databases" in Data Base Architectures, Bracchi Nijssen Editors, North Holland Publishing Company, 1979.

Chapitre 7