Bases de données avancées

Transcription

1 Bases de données avancées travaux dirigés et travaux pratiques Nicolas Le Sommer, Gilles Gaffiot, Didier Bodganiuk et François Morice Département Informatique, IUT de Vannes Université de Bretagne Sud

2 Travaux dirigés

3 TD : Rappels sur l'algèbre relationnelle et le langage SQL Exercice Dans le cadre de cet exercice, nous considérons la base de données relationnelle bibliothèque dénie par les relations : auteur (idauteur : chaîne, nomauteur : chaîne, prenomauteur : chaîne), publication (idpublication : chaîne, titrepublication : chaîne, nbpages : entiers), motcle (idmot : chaîne, mot : chaîne), ecritpar (idpublication : chaîne, idauteur : chaîne), parlede (idpublication : chaîne, idmot : chaîne), et par les attributs suivants : nomauteur : nom d'un auteur (ex : Ullman ), idauteur : identiant d'un auteur (ex : aut2), titrepublication : titre d'une publication (ex : le modèle relationnel ), idpublication : identiant d'une publication (ex : pub), nbpages : nombre de pages de la publication (ex : 2), mot : mot clé associé à la publication (ex : SGBD), idmot : identiant du mot clé associé à la publication (ex : mc). Questions. Donnez une expression relationnelle permettant d'obtenir les titres des publications écrites par Ullman qui traitent de SGBD ou de langages. 2. Donnez une expression relationnelle retournant en résultat le nom et prénom des auteurs qui ont écrit une publication ayant un nombre de pages supérieur à Donnez une requête SQL appropriée pour chacune des questions précédentes. Exercice 2 Considérons la base de données emploi du temps caractérisée par les attributs Enseignant (E), Matière (M), Créneau Horaire (H), Salle (S) et Classe (C), et par les contraintes d'intégrités suivantes : aucun enseignant n'enseigne plus d'une matière ; un enseignant ne fait jamais cours à plus d'une classe à la fois ; il n'y a jamais deux enseignants en même temps dans une même salle ; une classe n'est jamais répartie dans des salles diérentes lors d'un même enseignement. Questions. Exprimez les contraintes précédentes sous formes de dépendances fonctionnelles 2. Ces dépendances permettent-elles d'assurer que deux classes ne peuvent avoir cours en même temps dans une même salle? 3. Quelles sont les clés? 4. Le schéma global est-il en 3NF? 5. Le schéma {EM, EHC, HCS} est-il valide, préserve-t-il les dépendances fonctionnelles?

4 TD 2 Élaboration d'un schéma relationnel à partir d'un diagramme de classes UML Présentation Dans le cadre de cet exercice, nous nous intéressons à une application de gestion des épreuves d'athlétisme. Cette application s'appuie sur une base de données relationnelle pour enregistrer les informations manipulées. La gure présente un diagramme de classes UML modélisant la base de données utilisée par cette application. Fig. Diagramme de classes modélisant la base de données utilisée comme support de stockage d'informations par l'application de gestion des épreuves d'athlétisme. Travail à réaliser. Traduisez à l'aide des règles présentées en cours le diagramme de classes UML de la gure en un ensemble de relations, et identiez les dépendances fonctionnelles inter-relations. Vous préciserez en outre les contraintes de cardinalité qui ne sont pas traduites dans ce schéma relationnel. Vous préciserez pour chaque contrainte leurs caractéristiques : contraintes de niveau attribut, de niveau table, d'obligation de présence, etc.

5 2. Construisez le graphe des dépendances fonctionnelles inter-relations, et proposez un ordre de création des tables. 3. Identiez les éventuels problèmes rencontrés lors de la mise à jours des tables. 2

6 TD 3 Élaboration d un schéma relationnel à partir d un diagramme de classes UML Présentation Dans le cadre de cet exercice, nous nous intéressons à une application bancaire. Cette application s appuie sur une base de données relationnelle pour enregistrer les informations qu elle manipule. Le diagramme de classes UML modélisant cette base de données est présenté dans la figure. TypeCompte NoTypCpte () LibTypCpte < de type Compte NoCompte () Solde Client NumClient () NomClient PrenomClient AdresClient..*..* connu de > < appartient Agence NumAgence () < concerne effectue > Operation NumOperation () DateOperation TypeOperation Montant TelAgence dirige ou-ex travaille dans Agent < conseille NumAgent () NomAgent PrenomAgent AdresseAgent SalaireAgent Legende : () indique les identifiants FIG. Diagramme de classes modélisant la base de données utilisée comme support de stockage d informations par l application bancaire considérée. Ce diagramme UML est completé par l ensemble de contraintes suivantes :. Le montant d une opération est toujours positif. 2. Le type d opération est soit RETRAIT soit DEPOT. 3. Le type de compte considéré est soit un compte COURANT soit un compte d EPARGNE. 4. Par défaut, la date d opération est la date du jour courant.

7 5. Un client possède toujours un nom et un prénom. 6. Un client est conseillé par un agent qui travaille dans l agence qui connaît ce client. 7. Un client ne doit pouvoir retirer de l argent que sur un compte qui lui appartient. 8. Un client ne doit pas pouvoir effectuer un retrait dont le montant est supérieur au solde du compte concerné par cette opération de retrait. 9. Le directeur d une agence est mieux payé que les agents de son agence. 0. Aucun salaire ne doit être inférieur au SMIC. Travail à réaliser. À l aide des règles présentées en cours, traduisez le diagramme de classes UML de la figure en un ensemble de relations. Pour chacune des contraintes mentionnées ci-dessus, vous préciserez si elle peut (ou non) être implantée par le langage de description des données de SQL. Pour les contraintes pouvant être directement implantées au sein du script de création des structures de données, vous indiquerez les moyens utilisés pour vérifier ces contraintes (e.g. contrainte de type CHECK, contrainte d unicité, création de vues). 2. Construisez le graphe des dépendances fonctionnelles inter-relations, et proposez un ordre de création des tables. 3. Proposez un schéma relationnel (le plus fidèle possible au diagramme UML de la figure ) en indiquant les contraintes de cardinalité qui ne sont pas traduites dans ce modèle. Classez ces contraintes suivant leur type : contrainte d attribut, de table ou/et de base. 4. Identifiez les éventuels problèmes rencontrés lors de la mise à jours des tables. 2

8 TD 4 Définition et mise en œuvre de fonctions et de procédures en PL/SQL Présentation Dans le cadre de cet exercice, nous nous intéressons à l application bancaire du TD précédent. Afin de faciliter la manipulation et la mise à jour des informations contenues dans la base de donnée utilisée par cette application, nous souhaitons définir un ensemble de fonctions et de procédures PL/SQL pour automatiser certains des traitements appliqués à cette base de données. Travail à réaliser Écrivez dans le langage PL/SQL d Oracle une fonction getclientid retournant l identifiant d un client (ie. NumClient) à partir de son nom et de son prénom ; une procédure printaccounts capable d afficher le numéro et le libellé des différents comptes possédés par un client à partir de l identifiant de ce dernier (ie. NumClient) ; une fonction hasadebitbalance retournant vrai si le compte spécifié en paramètre est débiteur, et faux dans le cas contraire ; une fonction lastoperations capable de retourner les n dernières opérations effectuées sur un compte donné, n étant un des paramètres de cette procédure ; une procédure setaccountmanagementfees capable de débiter chaque compte courant géré par une agence donnée d un montant de M Euros pour frais de gestion de compte.

9 TD 5 Définition et mise en œuvre de triggers Présentation Dans le cadre de cet exercice, nous considérons une nouvelle fois la base de données présentée dans le TD 3. Afin d assurer la cohérence des informations contenues dans cette base de données, nous souhaitons mettre en œuvre des déclencheurs capables de vérifier les contraintes qui n ont pas pu être implantées par le langage de description de données de SQL. Ces contraintes sont le suivantes : Un client ne doit pouvoir retirer de l argent que sur un compte qui lui appartient. Un client ne doit pas pouvoir effectuer un retrait dont le montant est supérieur au solde du compte concerné par cette opération de retrait. Le directeur d une agence est mieux payé que les agents de son agence. Par ailleurs, on veut pourvoir fournir aux agents qui utilisent la base de données bancaire une vision des données adaptée à leurs besoins. Ainsi, on souhaite leur offrir notamment une vue leur permettant de percevoir le nom et le prénom des clients de l agence, ainsi que le numéro et le type du compte ou des comptes de ceux-ci. Travail à réaliser Écrivez dans le langage PL/SQL d Oracle les triggers permettant de vérifier les contraintes mentionnées ci-dessus, puis définissez en algèbre relationnelle et en SQL la vue présentée précédemment.

10 Travaux pratiques

11 TP Interrogation de bases de données relationnelles et création de structures relationnelles simples Exercice Dans ce premier exercice, nous considérons une base de données relationnelle «épicerie» constituée des relations suivantes : client (cli_number, cli_name, cli_category) cli_number : clé primaire de la relation cli_categorie : clé étrangère référençant l attribut cat_label de la relation client_category product(prod_number, prod_label, prod_price) prod_number : clé primaire de la relation client_category(cat_label, cat_reduction) cat_label : clé primaire de la relation delivery(del_prod_num, del_cli_num, del_quantity) (del_prod_num, del_cli_num) : clé primaire de la relation del_prod_num : clé étrangère référençant l attribut prod_number de la relation product del_cli_num : clé étrangère référençant l attribut cli_number de la relation client Donnez les requêtes SQL permettant de répondre aux questions suivantes :. Quels sont les noms des clients de catégorie C qui ont été livrés en cacahuètes? 2. Quels sont les numéros des produits qui n ont pas été livrés? 3. Quels sont les numéros des produits qui ont été livrés au client numéro 3 et au client numéro 5? 4. Quels sont les noms des clients qui ont été livrés en jambon et qui bénéficient de plus de 5% de réduction? Pour créer la base de données vous permettant de répondre aux questions précédentes, vous utiliserez le script script_tp-.sql, script que vous trouverez dans le répertoire gl-5 dans votre forum.

12 Exercice 2 Le dictionnaire des données est l ensemble des informations gérées par le SGBD afin de savoir quelles sont les données des bases, comment elles sont structurées, implantées, qui y a accès, etc. Le dictionnaire regroupe notamment les informations des trois niveaux de schémas : schémas externes, schéma conceptuel et schéma interne. Dans un SGBD relationnel, le dictionnaire des données est généralement organisé sous forme de relations. Le schéma des relations du dictionnaire s appelle le "méta schéma". L intérêt de ce choix est que le SGBD (tout comme les utilisateurs) dispose de toute la puissance du langage de manipulation des données pour accéder et mettre à jour le dictionnaire.. Interrogez le dictionnaire des données Oracle afin de lister les tables présentes dans votre base de données grâce à la commande suivante : select * from user_tables 2. Pour obtenir une description de l une de ces tables, vous pouvez utiliser la commande suivante : describe nom_de_la_table. Exercice 3 Dans le cadre de cet exercice, il vous est demandé de créer, de modifier et de supprimer une table, ainsi que d ajouter, de supprimer et de mettre à jour des données dans cette table. Ces opérations pourront être définies au sein d un script SQL (i.e. fichier ayant l extension.sql). Question Créez la table acteurs dont le schéma relationnel est le suivant : acteurs (id_acteur : entier ; prenom : chaîne (5), nom : chaîne (5) ) Exécutez le script de création. Exécutez le une nouvelle fois. Que remarquez vous? Question 2 Définissez au sein de votre script l instruction SQL permettant de détruire la table acteurs, et exécutez votre script. Question 3 Modifiez votre script afin que l instruction SQL de création de la table acteurs précise la clé primaire id_acteur et la contrainte de présence obligatoire pour les attributs nom et prenom. Question 4

13 Insérez les tuples suivants dans la table acteurs, et expliquez, le cas échéant, les éventuels messages d erreurs. (, 'Alain', 'Delon') (2,'Jean', 'Gabin') (3,'Isabelle', 'Adjani') (,'Catherine','Deneuve') (4,'Jean','Reno') Question 5 Modifiez le second tuple de la table acteurs afin que le champ nom de ce tuple prenne la valeur NULL. Expliquez ce qui ce passe. Question 6 Supprimez le premier tuple de la table acteurs.

14 TP 2 Élaboration d'un schéma relationnel à partir d'un diagramme de classes UML et utilisation du SQL*Loader d'oracle 2 séances Présentation Quand on dispose d'un grand volume de données, il est peut être dicile et laborieux d'insérer chacune de ces données dans les tables de la base de données considérée via la commande INSERT. An de faciliter l'insertion de données dans les tables d'une base de données, Oracle ore un utilitaire de chargement de données baptisé SQL*Loader. Cet utilitaire permet de remplir les tables d'une base de données avec les informations contenues dans des chiers externes. Sous linux cet utilitaire prend le nom de sqlldr (ou sqlload). Le principe de fonctionnement du SQL*Loader d'oracle est illustré dans la gure. Fig. Principe de fonctionnement de SQL*Loader Pour insérer les données dans les tables SQL*Loader utilise deux chiers principaux : le chier de données, qui contient les informations à chargées, et le chier de contrôle, qui dénit des informations telles que le nom du chier de

15 données et les chiers d'erreurs, le mode de remplissage de la table (ajout, remplacement ou insertion), la (ou les) table(s) d'acceuil, les règles d'identication des champs dans le chier de données, l'ordre et le type des attributs dans le chier de données. Le nom du chier de données est généralement suxé par.dat et celui du chier de contrôle par.ctl. 2

16 Le format du chier de contrôle est le suivant : LOAD DATA INFILE {<fichier de données> *} BADFILE <fichier des données erronées> DISCARDFILE <fichier des données rejetéees> {APPEND REPLACE INSERT} INTO TABLE <table d'accueil> FIELDS TERMINATED BY '<caractère>' -- séparateur de champs [OPTIONALLY ENCLOSED BY '<caractère>'] -- emballage des donnés [TRAILING NULLCOLS] -- derniers champs vides ( <champ > [<type>], -- ordre des champs <champ 2> [<type>], -- < type> est optionnel..., <champ n> [<type>] ) [BEGINDATA -- si INFILE = * <données>] -- si INFILE = * Les données non chargées sont placées dans des chiers spéciques (cf BAD- FILE et DISCARDFILE). Le chier des données rejetées (.bad) contient les données ayant provoquée une erreur Oracle lors de leur insertion ou les données pour lesquelles il est impossible de déterminer s'il faut les charger (cf condition WHEN). Le chier des données écartées contient les données ne répondant pas aux conditions de chargement. Le chargement s'eectue soit en mode ajout (APPEND), soit en mode remplacement des tuples existants (REPLACE) après suppression, soit en mode insertion dans une table obligatoirement vide (INSERT). La liste des champs indique l'ordre des champs dans le chier de données (pas dans la table d'accueil). Le type des champs indique le type dans le chier de données. Chaque type est ensuite converti dans le type du champ de la table d'accueil. Les chiers peuvent être organisés de la manière suivante : matable.sql (script de création de la table d'accueil), matable.ctl (chier de controle du chargement par sqlload), matable.dat (chier des données à charger), matable.csh (script csh d'exécution de toutes les opérations). La liste des chiers produits par l'appel de sqlldr (ou sqlload) est la suivante : matable.log (trace d'éxécution du chargement), matable.bad (données non chargées), matable.dis (données non chargées). Le script matable.csh pourrait être par exemple : #!/usr/bin/tcsh -xvf # Création de la table d'accueil 3

17 # Chargement des données sqlldr control=matable # Examen du fichier.log more matable.log # Examen des données chargées Travail à réaliser. Consultez les diérents chiers contenus dans le répertoire gl-5 de votre forum. 2. En vous inspirant des chiers que vous venez de consultez et en utilisant les résultats obtenus en travail dirigé, construisez la base de données relative à la gestion des épreuves d'athlétisme. Le diagramme UML modélisant cette base de données est présenté dans la gure ci-dessous. Fig. 2 Diagramme de classes modélisant la base de données utilisée comme support de stockage d'informations par l'application de gestion des épreuves d'athlétisme. 3. Lorsque vous avez créé l'ensemble de vos tables, initialisez chacune de celles-ci avec au moins cinq tuples en utilisant le SQL Loader d'oracle. 4. Eectuez ensuite quelques requêtes sur les tables ainsi remplies an d'en vérier le contenu. Vous devez rendre un ensemble de scripts SQL contenant toutes les opérations SQL que vous avez eectuées pour créer et initialiser les tables, et vérier le contenu de celles-ci. Vous documenterez ce script an d'expliquer votre démarche et vos choix de conception. 4

18 TP 3 Conception d une base de données relationnelle à partir d un diagramme de classes UML et implantation de fonctions, de procédures et de triggers en PL/SQL 3 séances Présentation Dans le cadre de ce travail, nous considérons la base de données bancaire étudiée en travail dirigé. Cette base de données est décrite par le diagramme de classes UML présenté dans la figure. TypeCompte NoTypCpte () LibTypCpte < de type Compte NoCompte () Solde Client NumClient () NomClient PrenomClient AdresClient..*..* connu de > < appartient Agence NumAgence () < concerne effectue > Operation NumOperation () DateOperation TypeOperation Montant TelAgence dirige ou-ex travaille dans Agent < conseille NumAgent () NomAgent PrenomAgent AdresseAgent SalaireAgent Legende : () indique les identifiants FIG. Diagramme de classes modélisant la base de données utilisée comme support de stockage d informations par l application bancaire considérée. Ce diagramme UML est complété par l ensemble de contraintes suivantes :. Le montant d une opération est toujours positif.

19 2. Le type d opération est soit RETRAIT soit DEPOT. 3. Le type de compte considéré est soit un compte COURANT soit un compte d EPARGNE. 4. Par défaut, la date d opération est la date du jour courant. 5. Un client possède toujours un nom et un prénom. 6. Un client est conseillé par un agent qui travaille dans l agence qui connaît ce client. 7. Un client ne doit pouvoir retirer de l argent que sur un compte qui lui appartient. 8. Un client ne doit pas pouvoir effectuer un retrait dont le montant est supérieur au solde du compte concerné par cette opération de retrait. 9. Le directeur d une agence est mieux payé que les agents de son agence. 0. Aucun salaire ne doit être inférieur au SMIC. Ce travail, qui se déroulera sur 3 séances, consistera à concevoir sous Oracle la base de données décrite ci-dessus, à implanter des fonctions et des procédures permettant de manipuler facilement le contenu de cette base de données, ainsi que des triggers permettant de vérifier certaines propriétés de celle-ci lors de l insertion, de la modification et de la suppression des données. Travail à réaliser. Construisez la base de données banquaire sous Oracle en utilisant les informations données en annexe. 2. Lorsque vous avez créé l ensemble de vos tables, initialisez chacune de celles-ci avec au moins cinq tuples en utilisant le SQL Loader d Oracle. 3. Effectuez ensuite quelques requêtes sur les tables ainsi remplies afin d en vérifier le contenu. 4. Implantez les procédures et les fonctions suivantes : une fonction getclientid retournant l identifiant d un client (ie. NumClient) à partir de son nom et de son prénom ; une procédure printaccounts capable d afficher le numéro et le libellé des différents comptes possédés par un client à partir de l identifiant de ce dernier (ie. NumClient) ; une fonction hasadebitbalance retournant vrai si le compte spécifié en paramètre est débiteur, et faux dans le cas contraire ; une fonction lastoperations capable de retourner les n dernières opérations effectuées sur un compte donné, n étant un des paramètre de cette procédure ; une procédure setaccountmanagementfees capable de débiter chaque compte courant géré par une agence donnée d un montant de M Euros pour frais de gestion de compte. 5. Définissez un script SQL permettant d ajouter lors de la création de la base de données les triggers assurant : qu un client ne puisse retirer de l argent que sur un compte qui lui appartient. qu un client ne puisse pas effectuer un retrait dont le montant est supérieur au solde du compte concerné par cette opération de retrait. que le directeur d une agence est mieux payé que les agents de son agence. 6. Ajoutez des données dans vos tables afin de vérifier le bon fonctionnement de vos triggers. Vous devez rendre un ensemble de scripts SQL contenant toutes les opérations SQL que vous avez effectuées pour créer et initialiser les tables, et vérifier le contenu de celles-ci. Les procédures, les fonctions et les triggers seront définis au sein de scripts SQL spécifiques. Vous documenterez chacun de ces scripts afin d expliquer votre démarche et vos choix de conception. 2