Après l’étape de modélisation des données, utilisant le modèle relationnel, vient l'étape de la mise en pratique.
Le système d'information repose sur un programme essentiel, le système de gestion de buses de données relationnel.
Ce dernier est un logiciel permettant :
- de créer des bases de données, c’est-à-dire des ensembles de tables ;
- de créer des tables en spécifiant leurs schémas ;
- de spécifier des contraintes d'intégrité, telles que les clés primaires et étrangères ou encore des contraintes de domaine ou des contraintes utilisateur ;
- d'ajouter des données à des tables, mais uniquement si ces entités
respectent les contraintes ;
- de mettre à jour ou de supprimer des données dans des tables et de supprimer des tables ;
- d'interroger les données grâce à des programmes écrits dans un langage de requêtes ;
- d'assurer la sûreté des données, par exemple en garantissant que même en cas de problème matériel (coupure de courant, défaut sur un disque les données sont récupérables.
De plus, le SGBD devant permettre des accès simultanés aux données de la part de plusieurs utilisateurs, il est souvent architecturé sur un modèle client-serveur.
Le serveur est le programme qui à effectivement accès aux données et les clients sont des programmes émettant des ordres (requête, mise à jour, etc.) et affichant les résultats de ces derniers.
Dans ce contexte multi-utilisateur, le SGBD permet de plus de définir des droits d'accès différents aux données selon les utilisateurs.
Ainsi, un SBGD possède des utilisateurs munis d’identifiants et de mots de passes (comme un système d’exploitation).
Les utilisateurs ont des droits différents (consultation simple de tables, mise
à jour de leurs tables ou droits d'administration permettant de configurer
le SGBD).
Un aspect fondamental des SGBD modernes et du langage SQL est que le programmeur de bases de données ne spécifie jamais comment récupérer les données. Il ne programme aucun algorithme, ne spécifie jamais de structure de données.
Certaines structures de données fixées sont connues
des SGBD : arbres, table de hachage.
Le programmeur avancé peut guider le SGBD dans le choix initial de représentation, mais il est la plupart du
temps fait automatiquement.
Au moment d'écrire sa requête, le programmeur n'indiquera jamais qu’il souhaite utiliser un tri fusion par exemple, mais simplement qu'il souhaite obtenir les données dans un certain ordre.
Le système fera alors le meilleur choix possible d'algorithme en fonction des informations à sa disposition (statistiques sur les données des tables, tailles de ces dernières, caractéristiques du système d’exploitation et du matériel sur lequel il s'exécute).
Dans ce contexte, SQL est parfois qualifié de langage déclaratif, c'est-à-dire un langage dans lequel on indique (on « déclare ») les résultats qu’on souhaite obtenir, pas la manière dont on souhaite les calculer.
Avant les années 1960, le principal moyen de stockage pour les ordinateurs était la bande magnétique.
Le traitement de données était donc réalisé en lots (batch en anglais), c'est-à-dire qu'une partie des données était rapatriée depuis la bande magnétique jusqu’en mémoire principale, traitée, puis les résultats affichés ou restockés sur bande. Puis le lot suivant de données était lu, traité et affiché, et ainsi de suite.
L'arrivée des systèmes à accès direct (comme les disquettes et disques durs) a changé la façon d’accéder aux données et les traitements que l’on pouvait espérer en faire.
En premier lieu, le modèle « hiérarchique » est proposé. Il reproduit, sur disque, les structures de données en mémoire.
Dans ce modèle, les données sont organisées en structures ou enregistrements (qui associent des clés à des données, comme les dictionnaires de Python).
Une particularité est que les enregistrements sont liés entre eux au moyen de pointeur, de manière à former
des listes chaînées ou des arbres (d’où le nom de système hiérarchique).
Les «requêtes» de l’époque sont donc semblables aux algorithmes de recherche dans ces structures de données.
Comme nous l'avons vu, Edgar F. Codd introduit en 1970 le modèle relationnel. Apparaissent à partir de cette époque des SGBD relationnels, comme System
R d'IBM, le premier à proposer une implémentation du langage SQL.
System R n'est cependant qu’un projet de recherche utilisé chez quelques industriels comme cas d'étude. Le premier SGBD commercial est Oracle, commercialisé par la société Relational Software en 1979 (devenue
depuis Oracle Corporation).
Les logiciels propriétaires tels qu'Oracle, mais aussi DB/2 d'IBM ou Sybase (maintenant SAP ASE), sont pendant des années la seule alternative viable pour les entreprises.
Avec le développement du Web au milieu des années 1990, le besoin de solutions logicielles moins onéreuses et plus ouvertes augmente.
En effet, les SGBD propriétaires étaient non seulement coûteux, mais aussi conçus pour fonctionner sur des serveurs aux architectures spécifiques, hors de portée des particuliers, des associations et des petites entreprises.
C’est dans ce contexte que naissent des alternatives telles que MySQL (maintenant MariaDB) en
1995 puis PostgreSQL en 1996. Ces dernières sont devenues au cours des 25 dernières années des logiciels robustes, capables de concurrencer dans de
nombreux cas les alternatives propriétaires.
En parallèle de l'évolution des systèmes, le langage SQL a lui aussi évolué. Cette évolution s'est faite de manière anarchique, de nombreux éditeurs de logiciels rajoutant leur propres extensions non standardisées.
Ce phénomène d’«enfermement» (vendor lock-in en anglais) est toujours d’actualité et rend difficile la présentation du langage SQL. Certaines opérations basiques doivent êtres déclinées selon tous les dialectes de SQL utilisés par les différents systèmes.
Une des raisons est le peu d'intérêt qu'ont les éditeurs
de systèmes commerciaux à faciliter la migration de leurs clients chez des systèmes concurrents.
Mettre ici les résultats.
Comme expliqué aux séquences précédentes, une action du monde réel (on parle parfois de processus métier) peut être modélisée par des ordres SQL donnés à un SGBD.
Si Alice (dont la carte a le code barre '19833284474405') emprunte le livre Ravage (dont l'ISBN est '978-2072534911') le 1er février 2020, la borne d'emprunt (qui exécute un programme graphique permettant de scanner les cartes et livres) eflectuera
l’ordre SQL suivant :
INSERT INTO emprunt VALUES
('19833284474405', '978-2072534911', '2020-02-15') ;
On voit ici que l’action d'emprunter se traduit par un seul ordre SQL.
Nous avons déjà vu qu'il est inutile de vérifier avant l'emprunt que le livre a effectivement été rendu (et pas juste redéposé en rayon sans passer par la borne).
En effet, si l'ISBN du livre est toujours dans la table emprunt, alors la contrainte d’intégrité faisant de l’attribut isbn une clé primaire sera violée et le SGBD renverra une erreur.
Le programme s’exécutant sur la borne pourra alors afficher un message d'erreur à l'usager.
Mettre le résultat ici.
Considérons maintenant une action plus complexe, consistant à sortir un livre de l'inventaire, par exemple s'il est en trop mauvais état pour être emprunté.
Ce processus d'apparence simple cache de nombreuses subtilités.
En effet, retirer une entrée de la table livre viole la contrainte de clé étrangère sur l’attribut isbn dans la table auteur_de.
Il faut donc d’abord retirer les lignes correspondantes dans cette table. Il peut y en avoir plusieurs si un livre à plusieurs auteurs. De plus, il peut être souhaitable, si
on à supprimé le dernier livre d’un auteur, de supprimer aussi cet auteur de la base.
Ce processus peut s'exprimer par plusieurs ordres SQL.
Supposons que l’on veuille supprimer le livre Les Aventures de Huckieberry Finn
d'ISBN ’978-2081509511?.
DELETE FROM auteur_de WHERE isbn = '7978-2081509511';
DELETE FROM auteur
WHERE NOT (a_id IN (SELECT a_id FROM auteur_de));
DELETE FROM livre WHERE isbn = '978-2081509511' ;
Le premier ordre supprime la référence au livre dans la table auteur_de.
Le deuxième ordre supprime de la table auteur tous les auteurs dont l’identifant (attribut a_id) n'apparaît pas dans la table auteur_de grâce à une requête imbriquée dans la clause WHERE.
Enfin, le livre est supprimé de la table livre par le troisième ordre.
Ces trois ordres forment un tout qu’on ne doit pas dissocier. En effet, considérons maintenant la situation suivante :
un usager a reposé le livre en rayon sans passer par une borne pour le rendre. Il reste donc dans la table
emprunt une référence vers l’ISBN de ce livre (contrainte de clé étrangère) et le dernier ordre et seulement celui-ci va échouer.
Mettre le résultat ici (code et figure).
Ajoutons une telle entrée dans la table emprunt et regardons ce qui se produit :
INSERT INTO emprunt VALUES ('934701281931682','978-2081509511','2020-02-01');
DELETE FROM auteur_de WHERE isbn = '978-2081509511';
DELETE FROM auteur
WHERE NOT (a_id IN (SELECT a_id FROM auteur_de));
DELETE FROM livre WHERE isbn = '978-2081509511';
ERROR: update or delete on table \"livre\" violates foreignDETAIL: Key (isbn)=(978-2081509511) is still referenced
from table \"emprunt\"
SELECT * FROM auteur WHERE nom = 'Twain';
Nos données sont dans un état incohérent, car les deux premiers ordres DELETE sont exécutés sans problème, retirant de la base l’auteur du livre et la relation entre ce dernier et le livre, alors que livre est toujours présent dans la base (la dernière requête SELECT ne renvoie aucun résultat). On souhaite donc que, si l’un des trois ordres échoue, les trois ordres soient annulés.
Mettre le résultat ici (code et figure).
Cette notion fondamentale des SGBD s’appelle une transaction. Une transaction est une séquence d'instructions SQL (requêtes, mises à jour) qui
forment un tout et doivent soit toutes réussir, soit toutes être annulées, afin de laisser la base dans un état cohérent.
Le langage SQL supporte bien évidemment les transactions. Pour déclarer qu’une suite d'ordres est une transaction, il suffit de la faire précéder de START TRANSACTION. On pourra alors la conclure par l'instruction COMMIT afin de valider la transaction.
L'instruction ROLLBACK permet de manuellement annuler la transaction. Il est à noter que si une erreur se produit lors d’une transaction, alors toutes les tables
sont remises dans leur état d'avant la transaction au moment du COMMIT ou du ROLLBACK (qui ont alors le même effet).
INSERT INTO emprunt VALUES ('934701281931582', '978-2081509511', '2020-02-01');
START TRANSACTION;
DELETE FROM auteur_de WHERE isbn = '978-2081509511';
DELETE FROM auteur
WHERE NOT (a_id IN (SELECT a_id FROM auteur_de));
DELETE FROM livre WHERE isbn = '978-2081509511';
COMMIT;
ERROR: update or delete on table “Livre” violates foreign
key constraint \"emprunt_isbn_fkey\" on table \"emprunt\"
DETAIL: Key (isbn)=(978-2081509511) is still referenced
from table \"emprunt\"
SELECT * FROM auteur WHERE nom = ’Twain”’;
ERROR: current transaction is aborted, commands ignored
until end of transaction block
ROLLBACK;
SELECT * FROM auteur WHERE nom = ‘Twain’;0 Twain | Mark
Comme on le voit, à l'issue de la transaction, c’est-à-dire après l'exécution de l’ordre ROLLBACK, la table auteur à été restaurée dans son état d'avant la
transaction.
Mettre le résultat ici (code et figure).
On peut noter qu'une syntaxe populaire, ne faisant pas partie du standard, mais supportée par tous les SGBD modernes, est celle utilisant le mot clé BEGIN pour START TRANSACTION et END pour ROLLBACK/COMMIT :
BEGIN;
DELETE FROM auteur_de WHERE isbn = '978-2081509511';
DELETE FROM auteur
WHERE NOT (a_id IN (SELECT a_id FROM auteur_de));
DELETE FROM livre WHERE isbn = '978-2081509511';
END;
Mettre le résultat ici (code et figure).
Mettons en œuvre une transaction plus complexe maintenant, permettant d'ajouter l'auteur Mark Twain s’il n’est pas déjà dans la table auteur !.
START TRANSACTION;
SELECT * INTO mark_present
FROM auteur
WHERE nom = 'Twain' AND prenom = 'Mark';
SELECT MAX(a_id) AS m INTO max_a_id
FROM auteur
WHERE (SELECT COUNT(*) FROM mark_present) = 0;
INSERT INTO auteur
(SELECT m+1, 'Twain', 'Mark'’
FROM max_a_id WHERE m IS NOT NULL);
DROP TABLE mark_present;
DROP TABLE max_a_id;
COMMIT ;
La première requête sélectionne toutes les lignes de la table auteur pour lesquelles le nom et le prénom sont ceux de Mark Twain et sauve ce résultat dans la table mark_present.
Si Mark Twain est bien présent, alors (au moins) une ligne sera copiée dans cette table.
Si Mark Twain n’est pas présent, alors la table mark_present sera vide.
La deuxième requête est plus subtile. Elle sélectionne les plus grands a_id de la table auteur pour lesquels la table temporaire mark_present est vide (son « COUNT » vaut 0). On peut remarquer que cette condition est indépendante de la ligne que l’on considère.
Ainsi, si la table mark_present est vide, alors la condition est toujours vraie.
La requête va donc renvoyer le maximum de fois les a_id de la table, car toutes les lignes sont sélectionnées.
À l'inverse, si mark_present est non vide, alors la condition est toujours fausse et aucun a_id n’est sélectionné. Dans ce cas, la fonction
d’agrégation renvoie la valeur spéciale NULL.
Pour résumer, les deux premiers ordres SELECT ensemble ont pour effet de mettre dans une colonne m
d’une table temporaire max_a_id le plus grand identifiant présent dans la table auteur si Mark Twain en est absent et NULL s’il est présent.
Le dernier ordre utilise enfin un « INSERT avec SELECT ». Le SELECT imbriqué renvoie le triplet (m+1, ‘Twain’, Mark’) si la colonne m de la table max_a_id est non NULL. Comme dans ce cas-ci m contient le plus grand
a_id de la table auteur, m+1 est un nouvel identifiant et est donc bien une clé primaire valide.
Si m est NULL, aucune insertion n'est faite (car Mark
Twain est déjà présent).
Les deux derniers ordres DROP détruisent les tables temporaires créées dans cette transaction.
Notons que si un problème survient durant la transaction, l'ordre ROLLBACK aura aussi pour effet de supprimer les tables temporaires créées pendant la transaction.
Mettre le résultat ici (code et figure).
Les propriétés ACID sont quatre garanties offertes par les SGBD relationnels concernant les transactions.
L'acronyme ACID est constitué des initiales des quatre propriétés : Atomicité, Isolation, Cohérence, Durabilité.
Atomicité : Par ce terme, on désigne le fait qu’une transaction est «tout ou rien».
Soit la transaction est arrivée à son terme, et les données sont alors modifiées, soit elle a échoué, et toutes les modifications sont annulées pour restaurer la base de données dans l’état où elle était avant la transaction.
Cohérence : Les transactions doivent faire passer la base d’un état cohérent à un autre état cohérent.
À l'issue d’une transaction, en particulier, toutes les contraintes d'intégrité doivent être vérifiées.
Isolation : Si deux transactions s’exécutent simultanément, alors leur exécution doit produire le même effet que si on les avait exécutées l’une
après l'autre (une transaction ne peut en particulier pas observer un état intermédiaire où certaines modifications n’ont pas été validées par un COMMIT).
Durabilité : Une transaction validée par un COMMIT est valide « pour de bon ».
Le système s’assure donc que, quels que soient les problèmes logiciels ou matériels qui pourraient survenir (défaillance de disque dur, panne de courant, etc.), les mises à jour d’une transaction validée ne sont jamais perdu.
Nous illustrons la propriété d'isolation avec l'exemple suivant. Supposons que l’on tente d'exécuter de manière simultanée deux copies de la transaction
«ajout de Mark Twain si absent» décrite plus haut.
Une manière simple de procéder consiste à ouvrir deux connexions à la base de données et de rentrer les deux séries d’ordres dans chacune de ces connexions.
START TRANSACTION; SELECT * INTO mark_present FROM auteur WHERE nom = 'Twain' AND prenom = 'Mark’; SELECT MAX(a.id) AS m INTO max_a_id FROM auteur WHERE (SELECT COUNT (*) FROM mark_present) = 0; INSERT INTO auteur (SELECT m+1, 'Twain', 'Mark' FROM max_a_id WHERE m IS NOT NULL); DROP TABLE mark_present; DROP TABLE max_a_id; COMMIT ; | START TRANSACTION; SELECT * INTO mark_present FROM auteur WHERE nom = 'Twain' AND prenom = 'Mark’; SELECT MAX(a.id) AS m INTO max_a_id FROM auteur WHERE (SELECT COUNT (*) FROM mark_present) = 0; INSERT INTO auteur (SELECT m+1, 'Twain', 'Mark' FROM max_a_id WHERE m IS NOT NULL); DROP TABLE mark_present; DROP TABLE max_a_id; COMMIT |
Supposons que ces deux transactions soient envoyées au même moment au SGBD (par exemple parce que deux documentalistes souhaitent ajouter Mark Twain). Si ces deux transactions sont exécutées l’une après l'autre :
- la première ajoute Mark Twain dans la base;
- la seconde, trouvant Mark Twain dans la base, ne fait rien.
Si ces deux transactions étaient exécutées en parallèle de façon naïve, leurs ordres pourraient s’entremêler de la façon suivante :
- la transaction de gauche recherche Mark Twain et ne le trouve pas;
--la transaction de droite recherche Mark Twain et ne le trouve pas non plus ;
- la transaction de gauche détermine un certain identifiant et ajoute Mark Twain ;
- la transaction de gauche est validée par son COMMIT;
- la transaction de droite détermine le même identifiant (car elle travaille sur la version de la table telle qu’elle était en début de transaction) et tente d'ajouter Mark Twain, mais viole alors la contrainte de clé
Le modèle ACID interdit un tel comportement, car le résultat de l'exécution séquentielle {tout se passe bien car la deuxième transaction ne fait rien) est différent de l'exécution en parallèle des deux transactions.
Un système dans lequel cela serait possible ne posséderait pas la propriété d'isolation.
En pratique, les SGBD modernes évitent cette situation en bloquant la deuxième transaction dès qu'elle accède à une table en cours d'utilisation par une autre transaction.
Dans notre scénario, la transaction de droite serait «bloquée» sur son premier SELECT (qui détermine si Mark Twain est présent), tant que la transaction de gauche n’a pas exécuté son COMMIT. Elle sera alors
débloquée et ne fera rien, car le SELECT trouvera Mark Twain dans la table.
Mettre le résultat ici (code et figure).
Nous terminons ce tour d'horizon des SGBDSs par une courte introduction à l’utilisation d’un SGBD depuis un langage de programmation.
Nous utilisons Python, mais les concepts présentés ici sont facilement transposables dans d’autres langages (tels que PHP pour la création d’un site web
riche).
L'une des difficultés d'une telle présentation repose sur le fait que, pour chaque SGBD existant, certaines lignes spécifiques propres à ce SGBD sont nécessaires.
Ainsi, ces lignes seront différentes selon que l’on se connecte à PostgreSQL, MariaDB ou encore Oracle.
Un programme (simple) interagissant avec un SGBD effectue généralement les actions suivantes :
1. Connexion au SGBD. C’est lors de cette phase que l’on spécifie où se trouve le SGBD (par exemple en donnant son adresse IP), le nom d'utilisateur et le mot de passe, ainsi que d’autres paramètres système.
2. Envoi d'ordres au SGDB. On crée (le plus souvent dans des chaînes de caractères) des ordres SQL.
3. On récupère les données correspondant aux résultats dans des structures de données du langage (par exemple dans des tableaux Python).
4. On peut ensuite exécuter du code Python sur les données récupérées.
Mettre le résultat ici (code et figure).
Le programme ci-dessus importe en premier lieu le module mysql.connector, qui permet de se connecter au SGBD MariaDB (mysql). Si l’on souhaite se connecter à un autre SGBD), il faudra changer cette ligne pour charger le bon module.
Attention, si le module mysql n'est pas présent sur votre ordinateur. Il faut se rendre dans le programme Python avec le terminale de commande (cmd) et exécuter la commande ci-dessous:
C:\\Users\\Your Name\\AppData\\Local\\Programs\\Python\\Python36-32\\Scripts>python -m pip install mysql-connector-pythonEn cas de problème d'installation de mysql.connector, il faut prevenir le professeu.
Un aspect important du langage Python est que ces concepteurs ont défini une interface unifiée d'accès aux bases de données.
Ainsi, même si les SGBD visés sont différents, les méthodes Python utilisées seront toujours les mêmes, ce qui rend le code facilement portable d'un SGBD à un autre.
Programme — SELECT depuis Python
import mysql.connector as sgbd
#Entrer l'adresse IP du serveur ou le nom de domaine
HOST = \"217.182.207.90\" # ou \"domaine.com\"
#Le nom de la base de données
DATABASE = \"DBuser?\" #changer le ? par le numero donnée par le professeur
#Le nom de l'utilisateur de la DB
USER = \"user?\"
# Le mot de passe de l'utilisateur
PASSWORD = \"mot de passe de la base\"
#connexion à la SGDB
cnx = sgbd.connect(host=HOST, database=DATABASE, user=USER, password=PASSWORD)
print(\"Connecté à:\", cnx.get_server_info())
c = cnx.cursor()
c.execute (\"SELECT * FROM livre WHERE annee < 1990\")
for l in c.fetchall():
print(l[0], l[2])
cnx.close()
Attention, vous devez modifier les paramètres : USER, DATABASE et PASSWORD.
Tester le code et mettre les résultats ci-dessous.
Nous avons choisi d'importer le module mariadb sous le nom générique sgbd ce qui évitera de devoir changer de nom dans la suite du programme si on change
de SGBD.
Le programme établit ensuite une connexion vers le SGBD. Il utilise pour cela la fonction connect du module. Cette dernière prend en argument des paramètres nommés.
Nous en donnons trois ici :
le paramètre host permet de spécifier le nom ou l'adresse du serveur et les paramètres user
et password permettent de donner le nom d'utilisateur et le mot de passe à utiliser pour se connecter au SGBD.
Le résultat de cet appel est un objet représentant la connexion au serveur (une exception est levée si jamais la connexion échoue).
L'objet cnx est celui qui est utilisé dans toute la suite
pour communiquer avec le SGBD.
La première chose à faire est la création
d'un curseur (variable c) au moyen de la méthode .cursor() de l’objet de connexion.
Un curseur représente essentiellement un ordre SQL.
Les deux principales méthodes que nous présentons sur les curseurs sont les suivantes :
- execute(s, p) permet d'exécuter un ordre SQL s, Ce dernier est simplement représenté par une chaîne de caractères Python, pouvant contenir une succession d'ordres séparés par des « ; ». Le paramètre p est
optionnel et est un tableau de valeurs Python dont l’utilisation sera détaillée dans la suite.
Notons que cette méthode ne renvoie aucun résultat.
Elle transmet juste l’ordre SQL au SGBD, qui va calculer un résultat.
- fetchall() renvoie tous les résultats du dernier ordre passé, sous la forme d’un tableau de n-uplets de valeurs Python. Chaque n-uplet représente une ligne de résultat de la requête.
Les valeurs sont ordonnées comme pour le résultat d’un SELECT. Un appel à fetchall() « réinitialise » le curseur. Si on appelle fetchall() deux fois, le deuxième appel renverra un tableau vide. Il faut ré-exécuter une requête pour obtenir de nouveau un résultat.
Dans le programme ci-dessus, on a donc exécuté une requête renvoyant tous les livres dont l’année est inférieure à 1990.
Comme on le voit, les valeurs ont été automatiquement traduites : les chaînes de caractères SQL (type VARCHAR) sont représentées par des chaînes
de caractères Python. Les entiers (type INTEGER) sont devenus des entiers Python.
Le programme parcourt cette liste de n-uplets au moyen d’une boucle for et affiche que le titre et l’année. Pour cela, il accède aux éléments d’indices 0 et 2 de chaque n-uplet.
Enfin, le programme se termine en fermant la connexion vers le SGBD. La méthode .close() est similaire à celle utilisée sur les descripteurs de fichiers et permet de libérer les ressources associées à la connexion (côté Python et côté SGBD).
Mettre le résultat ici (code et figure).
Une fonctionnalité importante est la possibilité de pouvoir insérer dans des ordres SQL des valeurs venant du monde Python, par exemple saisies par
l'utilisateur.
Nous illustrons cela avec le programme ci-dessous. Dans ce dernier, on demande à l'utilisateur de saisir une chaîne de caractères.
On veut ensuite exécuter la requête SELECT * FROM livre WHERE titre LIKE ’%s%' où s est la chaîne saisie par l'utilisateur. Nous utilisons ici la facilité fournie par la méthode .execute().
Programme — Recherche paramétrée
import mysql.connector as sgbd
#Entrer l'adresse IP du serveur ou le nom de domaine
HOST = \"217.182.207.90\" # ou \"domaine.com\"
#Le nom de la base de données
DATABASE = \"DBuser?\" #changer le ? par le numero donnée par le professeur
#Le nom de l'utilisateur de la DB
USER = \"user?\"
# Le mot de passe de l'utilisateur
PASSWORD = \"mot de passe de la base\"
#connexion à la SGDB
cnx = sgbd.connect(host=HOST, database=DATABASE, user=USER, password=PASSWORD)
print(\"Connecté à:\", cnx.get_server_info())
c = cnx.cursor()
texte = input (\"Texte à rechercher dans le titre :\")
c = cnx.cursor()
motif = '%' + texte + '%';
c.execute(\"SELECT * FROM livre WHERE titre LIKE %s\", \\
[ motif ])
for l in c.fetchall():
print(l[0], l[2])
cnx.close()
Il est possible de laisser dans la requête des «trous» dénotés par les caractères « %s ». Ces trous sont ensuite remplacés par les valeurs se trouvant dans le tableau passé en second paramètre à .execute() (le premier trou est remplacé par la première valeur du tableau et ainsi de suite).
Ainsi, si l'utilisateur saisit la chaîne Ast, alors la variable
motif contiendra la chaîne '%Ast%’.
La requête envoyée au SGBD sera alors
la suivante :
SELECT * FROM livre WHERE titre LIKE '%Ast%'
Il serait tentant de créer ia requête directement en Python au moyen de concaténations. On pourrait ainsi écrire directement
c.execute(\"SELECT * FROM livre WHERE titre LIKE '\" + motif + \"'\")
Cette approche est à proscrire et ne doit en aucun cas être utilisée?. En effet, le code ci-dessus est particulièrement fragile et peut être modifié par un utilisateur mal intentionné.
Ce dernier pourraît par exemple saisir comme texte :
'; DROP TABLE emprunt; SELECT * FROM livre WHERE titre = '
La requête formée et envoyée au SGBD serait alors :
SELECT * FROM livre WHERE titre LIKE '%';
DROP TABLE emprunt ;
SELECT * FROM livre WHERE titre = '%';
Le SGBD exécutera alors les ordres en séquence et en particulier le deuxième lui indiquant de supprimer la table emprunt.
Une telle subversion s'appelle une injection de code SQL. De nombreuses failles de sécurité » des sites
web sont en fait basées sur des injections de code SQL. Une telle faille n’est pas présente dans le programme ci-dessus. En effet, ce dernier laisse le soin à la méthode execute d'insérer le texte. Cette dernière va donc correctement échapper la chaîne de caractères et le programme effectuera la requête inoffensive
SELECT * FROM livre WHERE titre LIKE '%';DROP TABLE emprunt;SELECT * FROM livre WHERE titre = '%';
où toute la partie soulignée fait partie de la chaîne de caractères recherchée.
Cette requête essaye de trouver un livre dont le titre est littéralement
'; DROP TABLE emprunt; SELECT * FROM livre WHERE titre = '
Mettre le résultat ici (code et figure).
Pour chacun des scénarios suivant dire laquelle des quatre propriétés ACID est mise en jeu.
1. Une transaction tente d'insérer 20 lignes dans une table. L'insertion
de la 19° ligne échoue, à cause d’une contrainte de clé primaire. La
transaction est annulée et ancune des lignes ne se retrouve dans la
table.
2. Une table T2 contient des clés étrangères, référençant les clés d’une
table T,. On exécute une transaction arbitraire qui modifie T2. Après
la transaction 72 contient toujours des clés étrangères.
3. On exécute intégralement une transaction, validée par un « COMMIT ».
La machine exécutant le SGBD subit une panne de courant. Au redé-
marrage, l'effet de la transaction à bien été pris en compte.
4. Sur une table T contenant une colonne n de type INTEGER, on exécute
deux transaction, « en même temps ». La première ajoute 1 à toutes
les cases de la colonne n et la seconde retire 1 à ces même cases. Le
contenu de la table T après exécution (sans erreur) est le même.
Solution page 495 0
Mettre le résultat ici (code et figure).
1. Atomicité.
2. Cohérence.
3. Durabilité.
4. Isolation.
On considère la base de données de la médiathèque. On suppose qu'un utilisateur à perdu sa carte, dont le code barre est '11111111111111'. Un employé lui crée une nouvelle carte, dont le code barre est '222222222222222'.
Donner une transaction permettant de réaliser le processus de « remplacement de carte ».
Mettre le résultat ici (code et figure).
On doit modifier deux tables au sein de la même
transaction. Attention, on ne peut pas brutalement mettre à jour la table emprunt pour changer le code barre, ni la table usager, car il y a une contrainte de clé étrangère sur le code_barre. On procède donc de la façon suivante :
START TRANSACTION;
SELECT * INTO tmp FROM emprunt
WHERE code_barre = '111111111111111';
DELETE FROM emprunt WHERE code_barre = '111111111111111';
UPDATE usager SET code_barre = '222222222222222'
WHERE code_barre = '111111111111111';
INSERT INTO emprunt
(SELECT '222222222222222', isbn, retour FROM tmp);
DROP TABLE tmp;
COMMIT;
Le premier ordre sauvegarde dans une table temporaire tous les emprunts.
Ensuite, on modifie la table usager. Comme il n’y a plus d'emprunt correspondant à cet usager,la mise à jour ne viole pas de contrainte.
On peut ensuite réinsérer les lignes sauvegardées en utilisant la valeur fixe '222222222222222'. On n'oublie pas de détruire la table temporaire en fin de transaction.
Sur un site web de réservation de billets de trains, un usager peut consulter la liste des billets qui répondent à certains critères (destination, date, prix, etc.).
Lorsqu'il trouve un billet à sa convenance, il peut le
sélectionner puis l’acheter.
On suppose que la base de données du site stocke tous les billets disponibles dans une unique table billet_a_vendre où les billets possèdent
un attribut « id INTEGER PRIMARY KEY » et d’autres attributs que l’on ne précise pas.
Les billets vendus sont stockés dans une table « billet_vendu », ayant le même schéma que «billet_a_vendre».
On suppose enfin que la recherche se fait par un simple
SELECT id FROM BILLET_A_ VENDRE WHERE ...;
où les critères sont ceux cochés sur le site.
1. Étant donné un identifiant de billet, donner le code SQL de la transaction.
2 Expliquer pourquoi il est possible que quelqu'un trouve un billet à sa convenance, mais qu’au moment de l'achat le billet ne soit plus disponible.
3. Pour « corriger » le problème précédant, on décide de mettre la recherche et l'achat dans la même transaction. Quel nouveau problème (bien plus grave) est causé par cette approche ?
Solution page 496 D
Mettre le résultat ici (code et figure).
1. Voici la transaction :
START TRANSACTION;
INSERT INTO billet_vendu
(SELECT *
FROM billet_a_vendre
WHERE id = 1);
DELETE FROM billet_a_vendre WHERE id = i;
COMMIT ;
2. Le « SELECT ... » permettant de rechercher un billet peut s'exécuter en parallèle avec un achat. Supposons qu’il reste un billet disponible et deux acheteurs. Le premier acheteur trouve ce billet avec un « SELECT ». Le second acheteur trouve aussi ce billet. Les deux entament une transaction d'achat (celle trouvée à la question 1). Si la transaction réussit pour le premier acheteur, alors elle va échouer pour le second acheteur (le « SELECT » imbriqué ne va rien renvoyer).
3. Si on met tout le processus de recherche et d'achat dans une même transaction, alors cela veut dire que deux utilisateurs ne peuvent pas chercher en même temps, car le SGBD va bloquer toutes les transactions, sauf une, pour garantir la propriété d'isolation.
Considérons une table :
CREATE TABLE T (id INTEGER PRIMARY KEY, jour DATE, heure TIME, tmp DECIMAL(5,2));
Cette table permet d'enregistrer des relevés de température faits par une sonde. Chaque relevé possède un identifiant unique, le jour du relevé, l'heure
du relevé et la température relevée.
Supposons données trois valeurs j (un
jour),h (une heure) et t une température.
Écrire une transaction qui ajoute la nouvelle entrée en choisissant automatiquement un nouvel identifiant.
On pourra, dans un premier temps, considérer qu’il y a des données dans la table T, puis complexifier la transaction pour gérer le cas de la table vide.
Mettre le résultat ici (code et figure).
START TRANSACTION;
CREATE TABLE id_max_tmp (id INTEGER) ;
INSERT INTO id_max_tmp VALUES (-1);
INSERT INTO id_max_ tmp (SELECT MAX(id) FROM T);
INSERT INTO T (SELECT 1+MAX(id), j, h, t
FROM id_max_tmp
WHERE NOT (id IS NULL));
DROP TABLE id_max_tmp;
COMMIT;
La transaction crée une table temporaire id_max_tmp. On y insère une valeur par défaut valant -1. On y insère ensuite le plus grand identifiant trouvé dans la table T. Si la table T est vide, cette requête insère NULL dans la table id_max_tmp. Si la table est non vide, elle insère le plus grand identifiant. table id_max_tmp et on lui ajoute 1.
On l'utilise comme valeur d'insertion avec les constantes j, h et t.
On détruit ensuite la table temporaire.
Considérons la table T des relevés de température de l’exercice précédent. On considère deux ordres exécutés en parallèle :
SELECT MIN(jour) FROM T WHERE tmp >= 40;
qui renvoie le jour la plus ancien pour lequel la température a dépassé 40°.
UPDATE T SET tmp = tmp * 1.8 + 32;
qui convertit toutes les températures en degrés Farenheit.
Est-ce que la propriété ACID d'isolation garantit que la requête SELECT MIN... , renvoie toujours le même résultat quel que soit l’ordre d'exécution
des deux requêtes ?
Mettre le résultat ici (code et figure).
Exercice 164, page 343 Non, la propriété d'isolation n'offre pas cette ga-
rantie. Elle permet juste de s’assurer que la requête « SELECT MIN... »
donnera un résultat qui correspond soit à une exécution où elle précède en-
tièrement la mise à jour, soit à une exécution où elle suit entièrement la mise
à jour. En d’autres termes, la requête ne peut pas observer une table T où
seulement une partie des lignes ont été mises à jour.
En s'inspirant du programme python de connexion à une SGBD, écrire un programme Python qui sauvegarde l’intégralité de la table usager dans un fichier CSV nommé usager.csv.
On pourra utiliser le module Python csv
","title":"Exercice"},{"edit":"Mettre le résultat ici (code et figure).
import csv
import mysql.connector as sgbd
#Entrer l'adresse IP du serveur ou le nom de domaine
HOST = \"217.182.207.90\" # ou \"domaine.com\"
#Le nom de la base de données
DATABASE = \"DBuser?\" #changer le ? par le numero donnée par le professeur
#Le nom de l'utilisateur de la DB
USER = \"user?\"
# Le mot de passe de l'utilisateur
PASSWORD = \"mot de passe de la base\"
#connexion à la SGDB
cnx = sgbd.connect(host=HOST, database=DATABASE, user=USER, password=PASSWORD)
print(\"Connecté à:\", cnx.get_server_info())
with open(\"usager.csv\", \"w\") as fichier:
csvf = csv.writer(fichier)
#on écrit l'en-tête
csvf.writerow([\"nom\", \"prenom\", “adresse\" ,\\
“cp\", \"ville\", \"email\", \"code _barre\"])
#on se connecte à la base
c = cnx.cursor()
#on exécute la requête renvoyant tous les livres
c.execute(\"SELECT * FROM livre\")
#on écrit chaque ligne dans Le fichier
for l in c.fetchall(0):
csvf.writerow(l)
cnx.close()
En s'inspirant du programme python sur les SGBD, écrire un programme Python qui demande à l'utilisateur de saisir deux années, recherche tous les livres publiés entre ces deux années et crée un fichier HTML contenant une table présentant les résultats
","title":"Exercice"},{"edit":"Mettre le résultat ici (code et figure).
import mysql.connector as sgbd
#Entrer l'adresse IP du serveur ou le nom de domaine
HOST = \"217.182.207.90\" # ou \"domaine.com\"
#Le nom de la base de données
DATABASE = \"DBuser?\" #changer le ? par le numero donnée par le professeur
#Le nom de l'utilisateur de la DB
USER = \"user?\"
# Le mot de passe de l'utilisateur
PASSWORD = \"mot de passe de la base\"
#connexion à la SGDB
cnx = sgbd.connect(host=HOST, database=DATABASE, user=USER, password=PASSWORD)
print(\"Connecté à:\", cnx.get_server_info())
a1 = int(input(\"Saisir la première année : \"))
a2 = int(input(\"Saisir la deuxième année : \"))
with open(\"res.html\", \"w\") as fichier:
fichier.write(\"\"\"</DOCTYPE html>
<html>
<head><title></title></head>
<body><table>\"\"\")
c = cnx.cursor()
#on exécute la requête renvoyant tous les livres
c.execute(\"\"\"SELECT * FROM livre
WHERE annee >= %s AND annee <= %s\"\"\", \\
[a1, a2])
for lig in in c.fetchall():
fichier.write(\"<tr>\")
for col in lig:
fichier.write(\"<td>\")
fichier.write(str(col)
fichier.write(\"</td>\")
fichier.write(\"</tr>\\n\")
fichier.write(\"</table></body></html>\")
cnx.close()