Protection de l’information Contraintes d’intégrité Vues Droits

Pratique d’un SGBD : PostgreSQL Où en sommes nous ? Objectifs des bases de données Modèle relationnel Algèbre relationnelle SQL Conception et rétro-conception Pratique d’un SGBD : PostgreSQL Protection de l’information Web/BD

Plan du document Contraintes d’intégrité slide 177 Définition et exemple CIs dans les SGBD Exemple SQL complet Problèmes liés aux CIs Notion de transaction Vues relationnelles slide 193 Gestion des droits slide 207 Conclusion slide 214 Et moi que dois-je faire ? slide 216 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.

Définition et exemple de contraintes d’intégrité Traduction des règles de gestion des données Etat cohérent de la base Vérifiées en permanence 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  ’, … Le degré d’un vin est supérieur à 7 Non nullité Nom de cru de vin obligatoire Comportementale Le degré d’un vin augmente Schéma de la BD Vins Vins(num, cru, annee, degre) Producteurs(num, nom, prenom, region) Recoltes(nprod, nvin, quantite) 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

CIs dans les SGBD (1) Comment les exprimer? SQL Extensions de SQL Contraintes d’intégrité CIs dans les SGBD (1) Comment les exprimer? SQL Extensions de SQL Quand les déclarer ? À la création du schéma de BD : CREATE TABLE À chaque définition d’attribut À la fin de la définition d’une relation Au cours de la vie de la BD : ALTER TABLE

CIs dans les SGBD (2) Non nullité des valeurs d'un attribut Définition des données CIs dans les SGBD (2) Non nullité des valeurs d'un attribut Unicité de la valeur d'un attribut ou d'un groupe d'attributs Valeur par défaut pour un attribut Contrainte de domaine Clé primaire (un attribut ou un groupe) Intégrité référentielle "minimale"

CIs dans les SGBD (3) Quelles CIs dans les normes Contraintes d’intégrité CIs dans les SGBD (3) Quelles CIs dans les normes SQL 86 : unicité, non nullité, vue avec « check option » SQL 89 : domaine, clé, intégrité référentielle avec « rejet » SQL2 (SQL92) : intégrité référentielle avec « cascade delete » et « cascade UPDATE » Qu’offrent les SGBD ? Peu de CIs en général Autres CIs vérifiées par programme

Exemple SQL complet Contraintes d’intégrité CREATE TABLE Vins ( num INTEGER PRIMARY KEY, cru CHAR (40) NOT NULL, annee INTEGER CONSTRAINT Cannee CHECK (annee BETWEEN 1970 AND 2010), degre NUMBER(4,2) CONSTRAINT Cdegre CHECK (degre BETWEEN 9.0AND 15.0)) ; CREATE TABLE Producteurs ( nom CHAR(40), prenom CHAR(40), region CHAR(40)) ALTER TABLE Producteurs ADD CONSTRAINT Cregion CHECK (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)

Problèmes liés aux CIs Cohérence Pas de règles contradictoires Contraintes d’intégrité Problèmes liés aux CIs Cohérence Pas de règles contradictoires Redondance age > 18 et age > 21 Optimisation Limiter au nombre minimal de données mises à jour pour la vérification Vérification sur certains types de màj uniquement

Plan du document Contraintes d’intégrité slide 177 … Notion de transaction Gestion des CIs Transaction A C I D Vues relationnelles slide 19 Gestion des droits slide 216 Conclusion slide 225 Et moi que dois-je faire ? slide 227 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.

Gestion des CIs Est-ce possible ? Déclarations de contraintes d’intégrité Etat cohérent de la base Vérifiées en permanence 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. Rien ne se perd, rien ne se crée 900 1000 100 100 100 000 Virer 100 €

Regrouper des opérations élémentaires (lire, écrire) Transaction Regrouper des opérations élémentaires (lire, écrire) Virement (cpte source, montant, cpte destinataire) Dire « je commence » Enlever montant au cpte source Ajouter montant au cpte destinataire Dire « j’ai fini »

Contraintes d’intégrité Propriétés A C I D

A ? Virement (cochon rose, 100, cochon vert) Dire « je commence » Enlever 100 au cochon rose Ajouter 100 au cochon vert Dire « j’ai fini »

C ? Virement (cochon rose, 100, cochon vert) Dire « je commence » Enlever 100 au cochon rose Ajouter 100 au cochon vert Ajouter 0,1 a mon compte Dire « j’ai fini » 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.

I ?        Virement (cochon rose, 100, cochon vert) Dire « je commence » Enlever 100 au cochon rose Ajouter 100 au cochon vert Dire « j’ai fini » Virement (cochon rose, 500, cochon vert) Dire « je commence » Enlever 500 au cochon rose Ajouter 500 au cochon vert Dire « j’ai fini »       

D ? Virement (cochon rose, 100, cochon vert) Dire « je commence » Enlever 100 au cochon rose Ajouter 100 au cochon vert Dire « j’ai fini »

Une transaction est ACID A : atomicity C : consistency I : isolation D : durability

Plan du document Contraintes d’intégrité Vues relationnelles Rappel d’architecture Exemple de vues Principe Objectif Syntaxe Exemples de création de vues Manipulations de la BD au travers des vues Suppression et renommage Critique des vues Gestion des droits Conclusion Et moi que dois-je faire ? 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 Rappel d’architecture Description des données : 3 niveaux d’abstraction Groupe ANSI/X3/SPARC (1975) Schéma externe 1 …. Schéma externe n Schéma conceptuel Schéma physique

appli Direction des études Contexte technique Exemple de vues SE pour appli Service social Étudiant Chambre SE pour appli Bibliothèque Étudiant Livre SE pour appli Direction des études Étudiant UV Comment les données sont vues par les « utilisateurs » Représentations logiques Multiples Globalité des données Représentation logique Unique Schéma conceptuel Schéma physique Globalité des données Représentation physique des données. Comment les données sont mémorisées (fichiers, index, …) Unique

Principe Relation virtuelle Vues Principe Relation virtuelle Ensemble de tuples qui 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.

Objectifs Indépendance logique Adaptation aux applications Vues 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

Syntaxe CREATE VIEW nom_vue [{nom_attribut}] AS requête Exemple Vues Syntaxe CREATE VIEW nom_vue [{nom_attribut}] AS requête 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; Noms différents ….

Renommage obligatoire Vues Exemples CREATE VIEW crus (nom) AS SELECT DISTINCT cru FROM vins ; CREATE VIEW Clients_beaujolais_paris (num, nom, qte_cdee) AS SELECT Cl.num, Cl.nom, sum(qte) FROM Clients Cl, Commandes C, Vins V WHERE Cl.num = C.ncli AND C.nvin=V.nun AND V.cru = ‘ Beaujolais’ AND Cl.ville = ‘Paris’ GROUP BY Cl.num, Cl.nom; Renommage obligatoire

Relation : Parent (asc, dsc) Vues 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 DISTINCT ne doit pas être utilisée dans la requête Vues Mises à jour DISTINCT ne doit pas être utilisée dans la requête Clause FROM ne doit contenir qu'une seule relation; si la relation source est une vue, celle-ci doit vérifier cette contrainte Clause SELECT ne doit pas faire référence à des expressions, ou des fonctions Clause WHERE ne doit pas contenir de requête imbriquée Requête ne doit pas contenir de clause GROUP BY ni de clause HAVING

  Mises à jour (2) CREATE VIEW Vins_bordeaux AS Vues Mises à jour (2)  Tuples identifiables CREATE VIEW Vins_bordeaux AS SELECT num, annee, degre FROM vins WHERE cru = ‘Bordeaux ’; CREATE VIEW deg_moy_par_cru AS SELECT cru, avg (degre) GROUP BY cru ;  Augmenter la moyenne des degrés de 1?

Ajouter 10 à la quantité commandée Vues Mises à jour (3) CREATE VIEW Clients_beaujolais_paris (num, nom, qte_cdee) AS SELECT Cl.num, Cl.nom, sum(qte) FROM Clients Cl, Commandes C, Vins V WHERE Cl.num = C.ncli AND C.nvin=V.num AND V.cru = ‘Beaujolais’ AND Cl.ville = ‘Paris’ GROUP BY Cl.num, Cl.nom ;  Ajouter 10 à la quantité commandée par le buveur 10?

Suppression et renommage Vues Suppression 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 

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

Plan du document Contraintes d’intégrité Vues relationnelles Gestion des droits Techniques pour assurer la confidentialité Concepts SQL Privilèges Syntaxe Rôles Suppression de droit Droits et vues Conclusion Et moi que dois-je faire ? 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.

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

Privilèges Créateur d'une relation ou d'une vue = propriétaire Droits 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

Syntaxe GRANT <privilège> ON <objet> Droits Syntaxe defude GRANT SELECT ON vins TO lecocq; GRANT SELECT, UPDATE(cru) TO lecocq, bouzeghoub WITH GRANT OPTION; GRANT ALL lecocq SELECT * ON defude.vins ;  UPDATE defude.vins SET degre = degre * 1.1 ;  Si DBA défini un alias : FROM vins ;  GRANT <privilège> ON <objet> TO <utilisateur> [WITH GRANT OPTION]; 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 Droits 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 : regrouper un ensemble de droit On peut transmettre un rôle à : -un utilisateur - un autre rôle. Rôle      

Suppression de droit REVOKE <privilèges> ON <objet> Droits Suppression de droit REVOKE <privilèges> ON <objet> FROM <utilisateurs> Retire les droits transmis En cascade REVOKE ALL ON vins FROM defude;  12h  Un utilisateur ayant accordé un privilège peut le reprendre à l'aide de l'ordre REVOKE.  9h 13h 11h   13h  10h 14h  16h   Ou  ?

Droits 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

Plan du document Contraintes d’intégrité Vues relationnelles Gestion des droits Conclusion Et moi que dois-je faire ? 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.

Mécanismes complémentaires Contraintes d’intégrité Garantissent la cohérence des données Sécurité « sémantique », applicative Vues Délimitent des frontières d’accès, avec une granularité très fine Masquent la complexité interne Droits Spécifient les types d’accès, avec un système de droits riche

Plan du document Contraintes d’intégrité Vues relationnelles Gestion des droits Conclusion Et moi que dois-je faire ? 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.

Et moi que dois-je faire ? Relire les transparents Lire la documentation complémentaire : Notre cours rédigé : http://www-inf.it-sudparis.eu/COURS/bd/index.php?idr=45 Cours de Télécom ParisTech : http://perso.telecom-paristech.fr/~talel/cours/inf225/wwwbd/polyv7/chap6.htm Approfondir la notion de transaction : Cours de télécom ParisTech : http://perso.telecom-paristech.fr/~talel/cours/inf225/wwwbd/polyv7/chap8.htm Faire le QCM lié à ce cours sur moodle Pratiquer  faire les questions liées à la protection de l’information dans les annales récentes (ex création de table)  rendre le contrôle continu 2 en début de CI1 Mots-fléchés