Programme Introduction aux BD et aux SGBD Le modèle relationnel Le langage de requête SQL La conception d’une BD relationnelle Protection des informations Perspectives des BD

Protection des informations Respect des règles de gestion des données (contraintes d’intégrité) Définition de schémas externes (vues relationnelles) Définition de droits d’accès en fonction des utilisateurs La protection des informations recouvre trois aspects: le respect des règles de gestion des données (contraintes d’intégrité); la définition de schémas externes; la définition de droits d’accès en fonction des utilisateurs. Lors de la définition des relations, il est possible de définir des règles de gestion des données: les contraintes d’intégrité. Une contrainte d’intégrité est une règle spécifiée sur les données, pour définir un état cohérent de la base. Trois niveaux de description ont été définis selon le groupe ANSI/X3/SPARC (1975) La centralisation de toutes les données au sein du niveau conceptuel induit un certain nombre de problèmes: l’utilisateur final est perdu compte-tenu du volume d’information mis à sa disposition; la gestion des accès à l’information doit être réalisée par programmes; la cohérence des informations doit être gérée par programmes... La définition du schéma externe a pour but de personnaliser l’information en fonction de l’utilisateur: accès aux seules informations pertinentes; présentation des données suivant la logique de cette catégorie d’utilisateur... D’autre part ce mécanisme permet de restreindre l’accès aux informations et ainsi d’assurer la protection des données. Il est par exemple possible de ne pas donner accès à un attribut dans une relation (le salaire d’un employé doit rester une donnée confidentielle). Cette première fonctionnalité est assurée par un mécanisme de vues. Associer à ce mécanisme filtrant les informations, il est possible de définir des droits d’accès à chacun des objets constituant la base de données. Ainsi, il est possible de donner des droits en lecture, en écriture à un objet de la base de données pour une catégorie d’utilisateurs.

Contraintes d’intégrité Règles de gestion des données Etat cohérent de la base Vérifiées en permanence La gestion automatique des CI est un des outils les plus important des SGBD Accès non conforme => action rejetée

Exemples de contraintes d’intégrité Modèle relationnel : Unicité de la clé (num dans vins) CI référentielle (nvin vers num) Domaine : Année entre 1970 et 2000 Région : ‘ Bourgogne ’, ‘ Beaujolais  ’, … Non nullité : Nom de cru de vin obligatoire Comportementale: Le degré d’un vin est supérieur à 7 Le degré d’un vin augmente Schéma de la BD Vins Vins(num, cru, annee, degre) Producteurs(num, nom, prénom, region) Recoltes(nprod, nvin, quantité) CIs structurelles : Modèle relationnel (unicité de clé) CIs comportementales : Liées aux applications CIs intra-relation : Une seule relation (non nullité d ’un attribut) CIs inter-relation : Plusieurs relations (intégrité référentielle) Domaine : base (entier, réel, date,.... ), Intervalle de valeurs ou liste de valeurs Non nullité : obliger à renseigner un attribut “ Non nullité ” ne signifie pas “ non nul ”! Non nullité souvent définie pour les attributs constituant la clé Unicité : clé(p. ex, clé candidates non choisies comme clé primaire) Clé étrangère : liens entre les relations Groupe d’attribut d’une relation constituant la clé d’une autre relation Vérifications: Insertion / Suppression / MàJ cascade Contraintes temporelles : maîtriser l’évolution des données Contraintes avec agrégat : règle sur un ensemble de tuples Contraintes d ’inclusion : Toutes les villes de résidences des employés sont des sites de l ’entreprise Contraintes générales : contraintes appartenant à plusieurs catégories Contraintes “ temporelles agrégatives ”: le nombre de projet sur lequel travaille un employé ne peut pas décroître

Les CIs dans les SGBD Quand les déclarer ? Comment les exprimer? À la création du schéma de BD Au cours de la vie de la BD Comment les exprimer? SQL Extensions de SQL Qu’offrent les SGBD ? Peu de CIs en général Autres CIs vérifiées par programme

Les CIs dans les SGBD (2) Normes : Définition d ’une CI SQL 86 : unicité, non nullité, vue avec « check option » SQL89 : domaine, clé, intégrité référentielle avec « rejet » SQL2 (SQL92) : intégrité référentielle avec «cascade delete et update » Définition d ’une CI 2 possibilités: À chaque définition d’attribut À la fin de la définition d’une relation

Exemple CREATE TABLE VINS ( num integer PRIMARY KEY, cru char (40) NOT NULL, annee integer CONSTRAINT Cannee CHECK (annee between 1970 and 2000), degre number(4,2) CONSTRAINT Cdegre CHECK (degre between 9.0 and 15.0)) CREATE TABLE PRODUCTEURS ( nom char(40), prenom char(40), region char(40)) ALTER TABLE PRODUCTEURS add CONSTRAINT Cregioncheck (region in ('Bourgogne', 'Beaujolais', 'Alsace', 'Jura', 'Corse')) CREATE TABLE RECOLTES( nprod integer, nvin integer, quantite integer) ALTER TABLE RECOLTES add primary key (nprod, nvin) add constraint refVIN foreign key (nvin) references VINS(num) on delete cascade add constraint refREP foreign key (nprod) PRODUCTEURS(num) on delete cascade Contraintes au niveau attribut NULL | NOT NULL : obligatoire ou non UNIQUE Accepte les valeurs nulles, Génère un index automatiquement PRIMARY KEY Ne peut apparaître qu ’une seule fois / relation Génère un index automatiquement REFERENCES nom_relation (attribut) [ON DELETE CASCADE] “ON DELETE CASCADE ” : suppression automatique des tuples de la relation secondaire référençant un tuple de la relation primaire à supprimer Les attributs constituant la clé étrangère dans la relation secondaire doivent avoir le même domaine que les attributs constituant la clé primaire dans la relation Une clé étrangère peut référencer la même relation primaire CHECK condition Contraintes de domaines plus précises Si la clause CHECK n’est pas vérifiée, l’ordre SQL est annulé Contraintes sur les relations UNIQUE liste d’attributs PRIMARY KEY liste d’attributs FOREIGN KEY liste d’attributs REFERENCES nom_relation(attributs)

CI et transactions BD cohérente : toutes les CIs sont vérifiées Transaction = ensemble de traitements sur la BD Fait passer la BD d’un état cohérent à un autre état cohérent Il se peut que ces contraintes d’intégrité ne soit pas vérifiées au cours de la transaction Exécution atomique La notion de transaction sur une base de données permet de définir un ensemble de traitements sur la base de données la faisant passer d’un état cohérent à un autre état cohérent. A la fin d’une transaction, l’ensemble des contraintes d’intégrité définies doit être vérifié. Cependant, il se peut que ces contraintes d’intégrité ne soit pas vérifiées au cours de la transaction. BD incohérente ?

Problèmes liés aux CIs Cohérence Redondance Optimisation Pas de règles contradictoires Redondance Age > 18 et âge > 21 Optimisation Nombre minimal de données mises à jour en jeu pour la vérification Vérification sur certains types de màj uniquement

Protection des informations Respect des règles de gestion des données (contraintes d’intégrité) Définition de schémas externes (vues relationnelles) Définition de droits d’accès en fonction des utilisateurs La protection des informations recouvre trois aspects: le respect des règles de gestion des données (contraintes d’intégrité); la définition de schémas externes; la définition de droits d’accès en fonction des utilisateurs. Lors de la définition des relations, il est possible de définir des règles de gestion des données: les contraintes d’intégrité. Une contrainte d’intégrité est une règle spécifiée sur les données, pour définir un état cohérent de la base. Trois niveaux de description ont été définis selon le groupe ANSI/X3/SPARC (1975) La centralisation de toutes les données au sein du niveau conceptuel induit un certain nombre de problèmes: l’utilisateur final est perdu compte-tenu du volume d’information mis à sa disposition; la gestion des accès à l’information doit être réalisée par programmes; la cohérence des informations doit être gérée par programmes... La définition du schéma externe a pour but de personnaliser l’information en fonction de l’utilisateur: accès aux seules informations pertinentes; présentation des données suivant la logique de cette catégorie d’utilisateur... D’autre part ce mécanisme permet de restreindre l’accès aux informations et ainsi d’assurer la protection des données. Il est par exemple possible de ne pas donner accès à un attribut dans une relation (le salaire d’un employé doit rester une donnée confidentielle). Cette première fonctionnalité est assurée par un mécanisme de vues. Associer à ce mécanisme filtrant les informations, il est possible de définir des droits d’accès à chacun des objets constituant la base de données. Ainsi, il est possible de donner des droits en lecture, en écriture à un objet de la base de données pour une catégorie d’utilisateurs.

Vues relationnelles

Vues relationnelles (2) Objectifs : Indépendance logique Adaptation aux applications Intégration des applications existantes Dynamique du schéma de la base Confidentialité et sécurité Décentralisation de l’administration d’une BD Hétérogénéité des modèles

Vues relationnelles Relation virtuelle Définie par une requête SQL Ensemble de tuples n ’existe pas physiquement Calculable à l ’exécution Définie par une requête SQL Utilisable comme une relation Utilisable pour définir une autre vue 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: le résultat d’une requête peut servir de base à l’expression d’une autre requête.

Syntaxe CREATE VIEW nom_vue [{nom_attribut}] AS requête [WITH CHECK OPTION ] “ WITH CHECK OPTION ” interdit : d’insérer des tuples qui ne respectant pas les restrictions de la vue de modifier un tuple en violant les contraintes définies sur la vue Exemple CREATE VIEW vins_beaujolais (no, nom, degre) AS SELECT num, cru, degre FROM vins WHERE cru=‘Beaujolais ’; La spécification des noms d’attributs de la vue est facultative. Par défaut, les attributs de la vue ont pour nom les attributs des relations utilisées dans la requête. La clause “ CHECK OPTION ” permet de définir des contraintes d’intégrité référentielles à vérifier lors des modifications de la base de données. Cette clause permet de vérifier que les mises à jour ou les insertions faites “ à travers la vue ” ne produisent que des tuples qui feront partie de la sélection de la vue. Une vue peut être utilisée pour contrôler l’intégrité des données grâce à la clause “ WITH CHECK OPTION ”. Cette option interdit: d’insérer des tuples qui ne respectant pas les restriction de la vue; de modifier un tuple en violant les contraintes définies sur la vue. On veut, par exemple, créer une vue respectant les condition suivantes: un employé parisien a toujours une commission un employé provincial n’a jamais de commission. CREATE VIEW Employé_com AS SELECT * FROM Employé WHERE (adresse ‘Paris’ AND Comm IS NOT NULL) OR (adresse <> ‘Paris’ AND Comm IS NULL) WITH CHECK OPTION;

Exemples Create view crus (nom) as select distinct cru from vins; Create view buveurs_beaujolais_paris (num, nom, qté_cdée) as select B. nb, B.nom, sum(qté) from buveurs B, cdes C, Vins V where B. nb = C.nb and C.nv=V.nv and V.cru = ‘ Beaujolais’ and B.ville = ‘Paris’ group by B. nb, B.nom;

Relation : Parent (asc, dsc) Exemples (2) Relation : Parent (asc, dsc) create view grand_parent (asc, dsc)as select P1.asc, P2.dsc from parent P1, parent P2 where P1.dsc = P2.asc; create view arr_grd_parent (asc, dsc) as select P.asc, GP.dsc from parent P, grand_parent GP where P.dsc=GP.asc;

Manipulation de la BD au travers des vues Consultation Toujours possible Nom de la vue dans la clause from SELECT * FROM vins_beaujolais; Mises à jour : Rarement possible Une vue peut être référencée dans un ordre SELECT au même titre qu’une relation. Tout se passe comme cette vue était une relation pour l’utilisateur. En fait, cette relation est virtuelle: seule la définition de la vue est stockée.

Mises à jour La clause DISTINCT ne doit pas être utilisée dans la requête La clause FROM ne doit contenir qu'une seule relation; si la relation source est une vue, celle-ci doit vérifier cette contrainte La clause SELECT ne doit pas faire référence à des expressions, ou des fonctions La clause WHERE ne doit pas contenir de requête imbriquée La requête ne doit pas contenir de clause GROUP BY ni de clause HAVING

Mises à jour (2)   Create view Vins_bordeaux as select nv, mil, deg from vins where cru = ‘Bordeaux ’ create view deg_moy_par_cru as select cru, avg (deg) group by cru  Tuples identifiables  Augmenter la moyenne des degrés de 1?

Ajouter 10 à la quantité commandée Mises à jour (2) Create view buveurs_beaujolais_paris (num, nom, qté,_cdée) as select B. nb, B.nom, sum(qté) from buveurs B, cdes C, Vins V where B. nb = C.nb and C.nv=V.nv and V.cru = ‘ Beaujolais ’ and B.ville = ‘ Paris ’ group by B. nb, B.nom  Ajouter 10 à la quantité commandée par le buveur 10?

Suppressions et renommage Destruction: DROP VIEW Toutes les vues qui utilisent cette vue sont automatiquement détruites Relation de base détruite => toutes les vues définies sur cette relation sont automatiquement détruites Renommage: RENAME ancien_nom TO nouveau_nom

Traitements des vues par un SGBD Techniques: Modification de question (Ingres) Restructuration d ’arbre algébriques (System/R) Matérialisation de la vue (Sabre)

Modification de question Principe: modification de la question posée sur la vue en réintégrant les relations de base Exemple create view recoltes10 as select nvin select * from recoltes from recoltes10 where nprod = 10 where qte > 250 select nvin from recoltes where nprod = 10 and qte > 250

Restructuration algébrique Nécessite une compilation préalable des vues Principe : fusionner les arbres algébriques optimiser le nouvel arbre

Matérialisation des vues Réalisée à l’exécution de la requête Principe : Matérialisation de la vue par exécution de la question la spécifiant Optimisation et exécution de la requête sur la vue, considérée comme une relation de base

Critiques des vues   Sécurité Différentes façons de voir la BD Indépendance logique Faciliter la manipulation  Mise à jour impossibles en général

Protection des informations Respect des règles de gestion des données (contraintes d’intégrité) Définition de schémas externes (vues relationnelles) Définition de droits d’accès en fonction des utilisateurs La protection des informations recouvre trois aspects: le respect des règles de gestion des données (contraintes d’intégrité); la définition de schémas externes; la définition de droits d’accès en fonction des utilisateurs. Lors de la définition des relations, il est possible de définir des règles de gestion des données: les contraintes d’intégrité. Une contrainte d’intégrité est une règle spécifiée sur les données, pour définir un état cohérent de la base. Trois niveaux de description ont été définis selon le groupe ANSI/X3/SPARC (1975) La centralisation de toutes les données au sein du niveau conceptuel induit un certain nombre de problèmes: l’utilisateur final est perdu compte-tenu du volume d’information mis à sa disposition; la gestion des accès à l’information doit être réalisée par programmes; la cohérence des informations doit être gérée par programmes... La définition du schéma externe a pour but de personnaliser l’information en fonction de l’utilisateur: accès aux seules informations pertinentes; présentation des données suivant la logique de cette catégorie d’utilisateur... D’autre part ce mécanisme permet de restreindre l’accès aux informations et ainsi d’assurer la protection des données. Il est par exemple possible de ne pas donner accès à un attribut dans une relation (le salaire d’un employé doit rester une donnée confidentielle). Cette première fonctionnalité est assurée par un mécanisme de vues. Associer à ce mécanisme filtrant les informations, il est possible de définir des droits d’accès à chacun des objets constituant la base de données. Ainsi, il est possible de donner des droits en lecture, en écriture à un objet de la base de données pour une catégorie d’utilisateurs.

Autorisations Techniques pour assurer la confidentialité: Définition de contraintes d'autorisation Contrôle de flux de données Contrôle d'inférence Cryptographie

Concepts SQL Notion d'utilisateur : User_name + mot de passe Notion de BD logique == propriétaire Classes d'utilisateurs hiérarchisées Utilisateur final : CONNECT Programmeur : RESSOURCE Administrateur : DBA Tout utilisateur doit posséder un nom d'utilisateur et un mot de passe pour pouvoir accéder à la base. C'est ce nom d'utilisateur qui déterminera les droits d'accès aux objets de la base.

Privilèges Créateur d'une relation ou d'une vue = propriétaire Peut donner un droit Peut autoriser à transmettre un droit Droits sur un objet : SELECT : consultation DELETE : suppression INSERT : insertion UPDATE : modification La protection des objets d'une base de données est décentralisée : c'est le créateur d'un objet qui possède tous les droits de lecture, de modification et de suppression de cet objet. Les autres utilisateurs n'ont aucun droit d'accès à cet objet, à moins que le créateur ne les leur accorde explicitement par une commande GRANT

Langage de définition de contraintes d'autorisation Defude GRANT SELECT ON vins TO carpentier; GRANT SELECT, UPDATE(cru) TO carpentier, assar WITH GRANT OPTION; GRANT ALL GRANT <privilège> ON <objet> TO <utilisateur> [WITH GRANT OPTION]; Carpentier select * on defude.vins Synonyme défini vins=defude.vins  on vins WITH GRANT OPTION autorise à transmettre les droits Le propriétaire d'une table peut donner des droits de lecture non pas sur la table entière, mais sur une vue basée sur la table. Ainsi, seules les informations faisant partie de la vue seront accessibles. Pour oracle, le nom complet d'une relation ou d'une vue est le nom donné par le créateur, préfixé par le nom du créateur. Par exemple scott.emp est le nom complet de la relation emp créée par l'utilisateur scott. Ceci permet à plusieurs utilisateurs de créer des objets de même nom sans qu'il y ait confusion. En revanche, pour accéder à un objet dont on n'est pas le créateur, il faut le désigner par son nom complet incluant le nom du créateur.

Rôles       Rôle Droit 1 (lect. sur vins) Droit 2 (lect. sur récoltes) Droit 3 (lect. sur prod.) Droit 1 (lect. sur vins) Droit 2 (lect. sur récoltes) Droit 3 (lect. sur prod.) Rôle Rôle : regrouper un ensemble de droit On peut transmettre un rôle à : -un utilisateur - un autre rôle.      

Droits et vues Donner des droits de lecture non pas sur la relation entière, mais sur une vue basée sur la relation => restreindre l’accès à quelques attributs CREATE VIEW vins_beaujolais AS SELECT num, cru, degre FROM vins WHERE cru=‘ Beaujolais ’; GRANT SELECT ON vins_beaujolais TO producteurs_beaujolais; Droits + vues => bonne protection des données

Retirer des droits REVOKE <privilèges> ON <objet> FROM <utilisateurs> Retire les droits transmis REVOKE ALL ON vins FROM defude; Un utilisateur ayant accordé un privilège peut le reprendre à l'aide de l'ordre REVOKE.