Bases de données avancées

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
Travaux dirigés
TD 1 : Rappels sur l'algèbre relationnelle et le langage SQL
Exercice1
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 : aut12),
titrePublication : titre d'une publication (ex : le modèle relationnel ),
idPublication : identiant d'une publication (ex : pub1),
nbPages : nombre de pages de la publication (ex : 12),
mot : mot clé associé à la publication (ex : SGBD),
idMot : identiant du mot clé associé à la publication (ex : mc1).
Questions
1. 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 à 50.
3. 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
1. 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 ?
1
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 1
présente un diagramme de classes UML modélisant la base de données utilisée
par cette application.
1 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.
Fig.
Travail à réaliser
1. Traduisez à l'aide des règles présentées en cours le diagramme de classes
UML de la gure 1 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.
1
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
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 1.
TypeCompte
Compte
0..* N o C o m p t e ( 1 )
< de type
1
NoTypCpte (1)
LibTypCpte
Solde
0..*
1 < concerne
Client
NumClient (1)
1..*
NomClient
PrenomClient
AdresClient
1
0..*
0..*
Operation
NumOperation (1)
DateOperation
< appartient
TypeOperation
Montant
effectue >
0..*
1..*
Agence
1
connu de >
NumAgence (1)
TelAgence
1
dirige
1
ou-ex travaille
dans
1
0..*
Agent
NumAgent (1)
< conseille
1
Legende :
NomAgent
PrenomAgent
AdresseAgent
SalaireAgent
(1) indique les identifiants
F IG . 1 – 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 :
1. 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.
1
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.
10. Aucun salaire ne doit être inférieur au SMIC.
Travail à réaliser
1. À l’aide des règles présentées en cours, traduisez le diagramme de classes UML de la figure 1 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 1) 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
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.
1
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.
1
Travaux pratiques
TP 1
Interrogation de bases de données relationnelles
et création de structures relationnelles simples
Exercice 1
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 :
1. 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 15% 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-1.sql, script que vous trouverez dans le répertoire
gl-5 dans votre forum.
1
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.
1. 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 1 Créez la table acteurs dont le schéma relationnel est le suivant :
acteurs (id_acteur : entier ;
prenom : chaîne (15),
nom : chaîne (15)
)
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
– Insérez les tuples suivants dans la table acteurs, et expliquez, le cas échéant,
les éventuels messages d’erreurs.
(1, 'Alain', 'Delon')
(2,'Jean', 'Gabin')
(3,'Isabelle', 'Adjani')
(1,'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.
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 1.
Fig.
1 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
1
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
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 1> [<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 BADFILE 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
sqlplus @maTable
# Chargement des données
sqlldr control=maTable
# Examen du fichier .log
more maTable.log
# Examen des données chargées
sqlplus @maTableTests
Travail à réaliser
1. 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.
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.
Fig.
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
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 1.
TypeCompte
Compte
0..* N o C o m p t e ( 1 )
< de type
1
NoTypCpte (1)
LibTypCpte
Solde
0..*
1 < concerne
Client
NumClient (1)
1..*
NomClient
PrenomClient
AdresClient
1
0..*
0..*
Operation
NumOperation (1)
DateOperation
< appartient
TypeOperation
Montant
effectue >
0..*
1..*
Agence
1
connu de >
NumAgence (1)
TelAgence
1
dirige
1
ou-ex travaille
dans
1
0..*
Agent
NumAgent (1)
< conseille
1
Legende :
NomAgent
PrenomAgent
AdresseAgent
SalaireAgent
(1) indique les identifiants
F IG . 1 – 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 :
1. Le montant d’une opération est toujours positif.
1
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.
10. 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
1. 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