ECAM BASES DE DONNEES INTRODUCTION À SQL - *DB3T* - ICHEC Moodle
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
ECAM
BASES DE DONNEES
INTRODUCTION À SQL
*DB3T*
Edition 2018 M. De Vuyst, A. Lorge
© TOUS DROITS DE REPRODUCTION RESERVES
1 Rappel des notions de base de données..............................................................................4
1.1 Notion de SGBD (Système de Gestion de Bases de Données).......................................... 4
1.2 Le langage SQL – Exemples de base.................................................................................. 5
1.3 La programmation d’application..................................................................................... 16
1.4 Architecture des systèmes applicatifs.............................................................................. 16
2 Intégrité des données........................................................................................................18
2.1 Conception d’une base de données : quelques pistes de réflexion ................................ 18
2.2 Définitions........................................................................................................................... 19
2.3 Qui est responsable des contraintes d’intégrité ?........................................................... 20
2.4 Modélisation....................................................................................................................... 20
2.5 Sources de corruption d’une base de données ............................................................... 21
3 Transactions – mode connecté.........................................................................................22
3.1 Définitions........................................................................................................................... 22
3.2 Les primitives..................................................................................................................... 22
3.3 Définition d’une transaction............................................................................................. 23
3.4 Structures de transaction.................................................................................................. 23
3.5 Hiérarchie des transactions .............................................................................................. 26
3.6 Transaction et Intégrité..................................................................................................... 27
3.7 Transactions multi-instructions et gestion d’erreur. ...................................................... 29
4 Protection contre les incidents : journal et sauvegarde..................................................30
4.1 Exposé du problème........................................................................................................... 30
4.2 Gestion des tampons........................................................................................................... 30
4.3 Sauvegarde (Backup)......................................................................................................... 31
4.4 Journal (Log File)............................................................................................................... 32
4.5 Choix du matériel .............................................................................................................. 34
5 Régulation de la concurrence ..........................................................................................35
5.1 Principes ............................................................................................................................. 35
5.2 Exemples de concurrence.................................................................................................. 35
5.3 Sérialisabilité...................................................................................................................... 37
5.4 Techniques de verrouillage............................................................................................... 38
5.5 Problème de l’interblocage ............................................................................................... 41
5.6 Règles à suivre pour éviter des problèmes de blocage :................................................. 43
5.7 Choix des niveaux d’isolation pour SQL Server : .......................................................... 43
6 Gestion de l’intégrité : résumé..........................................................................................44
6.1 Architecture de validation ................................................................................................ 44
6.2 Techniques natives............................................................................................................. 45
6.3 Prédicats ............................................................................................................................. 45
6.4 Triggers – déclencheurs ou reflexes................................................................................. 46
6.5 Vues avec vérifications (Views with check option)......................................................... 48
6.6 Procédures stockées........................................................................................................... 49
1ère licence EI – Bases de données SQL – page 2,-
6.7 Modules d’accès ................................................................................................................. 49
6.8 Sections de codes distribuées dans les programmes d’application............................... 50
6.9 Procédures de validation attachées aux écrans de saisie................................................ 50
6.10 Programmes de validation avant chargement................................................................ 50
6.11 Programmes de validation après chargement................................................................ 50
6.12 Comportement en cas de violation .................................................................................. 51
7 Processeur de requêtes – aspect technique......................................................................52
7.1 Missions du processeur de requêtes.................................................................................. 52
7.2 Types d’optimisations des requêtes................................................................................... 52
7.3 Techniques d’exécution des requêtes................................................................................ 53
7.4 Optimisation des requêtes.................................................................................................. 55
7.5 Outils d’optimisation......................................................................................................... 57
8 Interfaces standardisées d’accès aux données (développement) ....................................58
8.1 Enoncé du problème........................................................................................................... 58
8.2 Approches propriétaires. .................................................................................................. 59
8.3 ODBC : Open DataBase Connectivity.............................................................................. 61
8.4 JDBC : Protocole « indépendant ».................................................................................... 64
8.5 OLE – DB : Approche «objets» microsoft........................................................................ 66
9 Bibliographie.....................................................................................................................70
10 Annexe : Aide mémoire - SQL Server
..........................................................................71
10.1 Etapes à suivre pour la conception de la base de données ............................................ 71
10.2 Conception des tables........................................................................................................ 72
10.3 Création des tables............................................................................................................ 73
10.4 Création des index............................................................................................................. 74
10.5 Création des vues .............................................................................................................. 75
10.6 Création de procédures stockées ..................................................................................... 75
10.7 Création de déclencheurs ................................................................................................. 76
10.8 Transact – SQL – instructions principales..................................................................... 78
10.9 Procédures stockées simulant les mises à jour cascadées.............................................. 80
Les notes ci-après sont partiellement inspirées d’un séminaire DB-Main des Facultés
Universitaires Notre Dame de la Paix à Namur. (Avec l’autorisation de l’auteur)
1ère licence EI – Bases de données SQL – page 3,-
1 Rappel des notions de base de données
1.1 Notion de SGBD (Système de Gestion de Bases de Données)
Un SGBD peut être perçu comme un ensemble de logiciels système permettant les opérations
suivantes
Définir des structures de données complexes modélisant des objets du monde réel ou des
associations entre objets.
Insérer, modifier, rechercher efficacement des données spécifiques dans une grande masse
d’informations.
Les objets accessibles sont partagés par de multiples utilisateurs, aussi bien en interrogation
qu’en mise à jour.
Chaque utilisateur doit avoir l’illusion d’être seul à manipuler les données.
Il faut pouvoir lui accorder des droits d’accès de manière très fine.
Les recherches peuvent être exécutées à partir de la valeur d’une donnée désignée par un nom
dans un ensemble d’objets nommés (par exemple ensemble des claviers inférieurs à 400 F),
mais aussi à partir de relations entre objets (par exemple produits commandés par un client
habitant telle localité).
Les données doivent être protégées contre tout incident.
Les performances doivent être acceptables, et auto adaptatives (gestion mémoire fonction de
la charge par exemple).
Des systèmes de sauvegardes doivent être prévus.
Le SGBD doit être capable de comprendre des requêtes faites à l’aide d’un langage unifié de
description et de manipulation des données (par exemple en SQL) On parlera de DDL : Data
Definition Language et de DML : Data Manipulation Language
EN PRATIQUE : Une base de données sera constituée d’une collection d’objets tels que des tables,
des vues et des procédures stockées. Chaque base de données a son propre journal des transactions
et garantit l’intégrité de tous les objets qui la composent.
Des gestionnaires de bases de données relativement primitifs (dBASE, ACCESS …) travaillent surtout
de manière séquentielle en ce qui concerne le stockage des informations. Ces gestionnaires se prêtent
particulièrement bien à des recherches et des parcours de type « scrolling » où on fait défiler les pages
de données à l’écran. Ils ne sont par contre pas adaptés à des recherches complexes, puisqu’ils
impliquent généralement un parcours de toutes les tables. Les systèmes plus élaborés stockeront leurs
informations dans des tables organisées sous forme d’arbres binaires et permettront de renvoyer aux
utilisateurs uniquement les enregistrements demandés (Orientés « jeu de résultats »).Ils ne seront par
contre pas très performants pour les traitements purement séquentiels.
1.2 Le langage SQL – Exemples de base
1.2.1 Définition et modification des structures de la BD (DDL – Data Definition
Language)
Création de tables, de colonnes, de clés (primaires et étrangères).
create table CLIENT
( NCLI char(4) not null,
NOM char(12) not null,
ADRESSE char(20) not null,
LOCALITE char(12) not null,
CAT char(2),
COMPTE decimal(9,2) not null,
primary key (NCLI)
)
1ère licence EI – Bases de données SQL – page 4,-
! ! not null , primary key
create table COMMANDE
(
NCOM char(4) not null,
NCLI char(4) not null,
DATE date not null,
primary key (NCOM),
foreign key (NCLI) references CLIENT on delete cascade
)
! ! not null, primary key, foreign key, delete cascade
create table DETAIL
(
NCOM char(4) not null,
NPRO char(5) not null,
QCOM decimal(4) not null,
primary key (NCOM, NPRO),
foreign key (NCOM) references COMMANDE, on delete restrict
foreign key (NPRO) references PRODUIT
)
! ! not null, primary key, foreign key – delete restrict
Toutes les manipulations de création de bases de données peuvent généralement se faire avec des outils
visuels permettant de créer automatiquement des scripts SQL, qui peuvent être stockés sous forme de
fichiers textes. Voir ci-après : exemple Access.
1ère licence EI – Bases de données SQL – page 5,-Suppression et modification de tables
drop table DETAIL
1ère licence EI – Bases de données SQL – page 6,-alter table PRODUIT add POIDS smallint
alter table PRODUIT drop PRIX
alter table CLIENT add primary key (NCLI)
alter table COMMANDE add foreign key FK-CLI (NCLI) references CLIENT
Création/suppression d'index
create index XLOC on CLIENT (LOCALITE asc)
create unique index XLIGNE on DETAIL (NCOM,NPRO)
drop index XLIGNE
1.2.2 Modification des données de la BD (DML – Data Manipulation Language)
Consultation / extraction des données
select NCLI, NOM from CLIENT where LOCALITE ='BRUXELLES'
select 'TVA de ', NPRO, ' = ', 0.21*PRIX*QSTOCK
from PRODUIT where QSTOCK > 500
select 'Namur', avg(COMPTE), count(*) from CLIENT where LOCALITE = 'Namur'
select NCOM,DATE from COMMANDE where NCLI in(select NCLI from CLIENT where
LOCALITE = 'Namur')
select NCOM, NCLI, DATE, NOM, ADRESSE from COMMANDE, CLIENT where COMMANDE.NCLI
= CLIENT.NCLI and CAT = 'C1' and DATE < '15/03/2018'
-- afficher toutes les informations des clients de catégorie C1 ayant --
effectué des commandes avant mars 2018.
select NCLI, count(*), sum(QCOM) from COMMANDE C, DETAIL L
where C.NCOM = L.NCOM and NPRO = 'PA60' group by NCLI having count(*) >= 2
order by NCLI
-- Recherche des N° de client, du nombre de produits commandé et du
-- montant total pour les clients ayant commandé plus de 2 produits PA60.
Modification des données
insert into COMMANDE values ('191','S712','12/04/2018')
insert into TABLE_CLIENT_BRUXELLES
select NCLI, NOM, ADRESSE
from CLIENT
where LOCALITE = 'BRUXELLES'
-- pas toujours possible (ACCESS)
delete from DETAIL where NPRO = 'PA60'
update PRODUIT
1ère licence EI – Bases de données SQL – page 7,-set PRIX = PRIX * 1.05
where LIBELLE like '%SAPIN%'
update PRODUIT P /* P devient synonyme de PRODUIT */
set QSTOCK = QSTOCK – (
select sum(QCOM) from DETAIL D
where D.NPRO = P.NPRO and D.NCOM in
(
select NCOM
from COMMANDE
where DATE >= '01/01/2018'
)
)
-- Ajustement du stock de produits en enlevant les quantités commandées
-- après le 1er janvier 2018.
Définition de vues
create View HABITUDE_ACHAT(LOCALITE, NPRO, VOLUME) as
select LOCALITE, P.NPRO, sum(QCOM*PRIX)
from CLIENT L, COMMANDE C, DETAIL D, PRODUIT P
where C.NCLI = L.NCLI and D.NCOM = C.NCOM and P.NPRO = D.NPRO
group by LOCALITE, P.NPRO
-- Afficher pour chaque localité les références de chaque produit avec
-- le nombre de produits commandés.
create view CLI(NCLI,NOM,ADR,LOC,CAT,CPTE) as
select NCLI,NOM,ADR,LOC,CAT,CPTE
from CLIENT
where CAT is null or CAT in ('B1','B2','C1','C2')
with check option
-- la vue est «vivante», et peut subir des modifications et insertions.
-- Le with check option interdit d’y insérer des valeurs différentes de NULL ou
-- B1 à C2 pour la catégorie.
1ère licence EI – Bases de données SQL – page 8,-Des outils automatiques de création de vues peuvent être employés.
-- INNER JOIN … ON … est équivalent à FROM annétu, branches WHERE …..
Contrôles d’accès (privilèges)
grant select,
update(QSTOCK)
on PRODUIT
to GPERS2, FINCT
grant all
on CLIENT
to GPERS2, FINCT
with grant option
grant run
on COMPTA01
to GES66
revoke update(QSTOCK)
on PRODUIT
from GPERS2
1ère licence EI – Bases de données SQL – page 9,-Les prédicats ou contraintes
Un prédicat (ou contrainte) est une condition faisant partie du dictionnaire de la base de données qui
sera vérifiée automatiquement après chaque modification. Certains gestionnaires de bases de données
distinguent les contraintes (modification de colonne ou de table) des assertions (évaluation au niveau de
la base de données – inter-tables, éventuellement liées à des utilisateurs)
create assertion ASSERTION_COMDET
check (
(select count(*) from COMMANDE where NCOM not in (select NCOM from DETAIL))
> 0
)
-- N’accepter aucune commande sans au moins un détail.
alter table DETAIL
add constraint C_QCOM check(QCOM > 0)
-- La quantité commandée doit être > 0
alter table CLIENT
add constraint C_SEXE check(SEXE is null or SEXE in ('M','F'))
-- sans commentaire
alter table DETAIL
add constraint C_Q
check(QCOMprocédures stockées (stored procedures) font partie du schéma de la base de données, et le gestionnaire
peut non seulement stocker le code pré-compilé (gain de temps), mais également stocker les éléments
lui permettant d’optimiser leur exécution.
Permet également de placer dans la base de données des éléments faisant partie de la logique
d’entreprise, sans duplication de code.
Exemple
La procédure ci-dessous supprime la ligne de détail dont elle reçoit le numéro de commande et le
numéro de produit. Si cette ligne est la dernière de sa commande, cette dernière est également
supprimée.
create procedure MAJ_CMD (in COM char(4), in PRO char(5))
begin
delete from DETAIL
where NCOM = COM and NPRO = PRO ;
if (select count(*) from DETAIL where NCOM = COM) = 0 then
delete from COMMANDE where NCOM = COM
end if ;
end ;
On pourra invoquer cette procédure par la commande suivante .
CALL MAJ_CMD(182,'PA60')
Autre exemple : appel d’une procédure « système »
Le champ Numéro édition devient Numero edition
EXECUTE sp_rename 'dbo.[Stock syllabus].[Numéro édition]', 'Tmp_Numéro edition',
'COLUMN' GO
EXECUTE sp_rename 'dbo.[Stock syllabus].[Tmp_Numéro edition]', 'Numéro edition',
'COLUMN' GO
1ère licence EI – Bases de données SQL – page 11,-Accès particulier aux données : les curseurs
En principe, les opérations
«SELECT
WHERE» sur les bases de
données relationnelles renvoient
toujours un ensemble complet de
lignes(modèle ensembliste
- jeux de résultats).
Les programmes utilisant
la base de manière interactive et en
ligne ne peuvent pas fonctionner
efficacement avec un bloc de
plusieurs milliers de lignes. Il
est plus pratique de travailler avec
un petit ensemble de
lignes à la fois.
Les curseurs mettent en place un
mécanisme permettant d’envoyer à
l’utilisateur un ensemble de lignes
sélectionnées une par une (modèle
séquentiel). Les systèmes
modernes de gestion de bases de
données proposent une fusion des
2 modèles d’accès aux
informations (ensembliste et
séquentiel)
Il existe des curseurs spécialisés pour les accès ODBC ou OLE-DB, qui renvoient en une fois un petit
nombre d’enregistrements.
Attention, l’utilisation des curseurs dans le cadre des mises à jour est dangereuse (blocage
d’enregistrements) ; des curseurs spéciaux existent pour gérer les appels Ole_DB ou ODBC.
Opérations possibles :
• Positionnement à une ligne donnée de l’ensemble de résultats.
• Extraction d’une ligne ou d’un bloc de lignes.
• Modifications possibles pour la ligne à la position courante.
• Permet d’appliquer plusieurs niveaux de visibilité pour les changements effectués par les
autres utilisateurs.
• SQL Server© supporte 2 méthodes pour demander un curseur:
• Transact-SQL: la syntaxe d’accès aux curseurs se base sur la norme SQL-92.
• Fonctions de curseurs suivant les standards API suivants :
• OLE DB
• ODBC (Open Database Connectivity)
• ADO (ActiveX Data Object)
• DB-Library
Procédure utilisée :
1. Associer un curseur à un ensemble résultat d’une commande select et en définir les
caractéristiques (mise à jour possible par exemple).
2. Exécuter la commande SQL pour initialiser et remplir le curseur.
3. Récupérer les lignes du curseur intéressantes (fetch).
4. Eventuellement, mettre à jour la ligne de la position courante du curseur.
5. Fermer le curseur.
1ère licence EI – Bases de données SQL – page 12,-En Transact-SQL, l’utilisateur doit attendre d’avoir reçu et récupéré l’ensemble complet des
résultats avant de pouvoir faire autre chose. Il n’y a utilisation de curseur que quand on utilise
la commande DECLARE CURSOR associée avec un SELECT.
En ODBC, OLE DB ou ADO, l’utilisation des curseurs est souvent implicite pour toutes les
opérations.
Curseurs – déclaration simple
DECLARE authors_cursor CURSOR
FOR SELECT * FROM authors
OPEN authors_cursor
FETCH NEXT FROM authors_cursor
-- .......
Curseurs : exemple d’utilisation avec parcours
USE pubs
GO
DECLARE authorcursor CURSOR FOR
SELECT au_fname, au_lname FROM authors ORDER BY au_fname, au_lname
OPEN authorcursor
FETCH NEXT FROM authorcursor
WHILE @@FETCH_STATUS = 0
BEGIN
-- ......
FETCH NEXT FROM authorcursor
END
CLOSE authorcursor
DEALLOCATE authorcursor
GO
1ère licence EI – Bases de données SQL – page 13,-Curseurs : exemple avec double parcours
DECLARE @au_id varchar(11), @au_fname varchar(20), @au_lname,
varchar(40),@message varchar(80), @title varchar(80)
PRINT "-------- Utah Authors report --------"
DECLARE authors_cursor CURSOR FOR
SELECT au_id, au_fname, au_lname
FROM authors
WHERE state = "UT"
ORDER BY au_id
OPEN authors_cursor
FETCH NEXT FROM authors_cursor
INTO @au_id, @au_fname, @au_lname
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT " "
SELECT @message = "----- Books by Author: " + @au_fname + " " + @au_lname
PRINT @message
-- Declare an inner cursor based on au_id from outer cursor.
DECLARE titles_cursor CURSOR FOR
SELECT t.title
FROM titleauthor ta, titles t
WHERE ta.title_id = t.title_id AND ta.au_id = @au_id
-- Variable value from outer cursor
OPEN titles_cursor
FETCH NEXT FROM titles_cursor INTO @title
IF @@FETCH_STATUS 0
PRINT " "
WHILE @@FETCH_STATUS = 0
BEGIN
SELECT @message = " " + @title
PRINT @message
FETCH NEXT FROM titles_cursor INTO @title
END
CLOSE titles_cursor DEALLOCATE titles_cursor -- Get the next author.
FETCH NEXT FROM authors_cursor
INTO @au_id, @au_fname, @au_lname
END
CLOSE authors_cursor
DEALLOCATE authors_cursor
GO
--------- Utah Authors report --------
----- Books by Author: Anne Ringer The Gourmet Microwave Is Anger the Enemy?
----- Books by Author: Albert Ringer Is Anger the Enemy? Life Without Fear
1ère licence EI – Bases de données SQL – page 14,-Possibilités d’optimaliser les requêtes SQL.
Les gestionnaires modernes permettent facilement d’évaluer le temps mis pour les différentes
opérations impliquées par des requêtes. Ils peuvent même mémoriser dans une base de données les
statistiques d’accès aux différents objets.
1ère licence EI – Bases de données SQL – page 15,-1.3 La programmation d’application
A condition d’avoir chargé les bonnes librairies dll (OLE DB ou ODBC), les programmes d’application
peuvent utiliser directement les outils SQL.
2 modes d’utilisation fondamentalement différents sont prévus
• Mode connecté (travail « en direct » vers la DB)
• Mode déconnecté (travail sur une copie locale en mémoire)
L’évolution actuelle de l’informatique, avec Internet, se fait plutôt en privilégiant le mode déconnecté.
MAIS
Les données sont copiées en mémoire (gourmand en ressources), et doivent s’y trouver en totalité
(imaginons une table avec 1.000.000 de lignes …) ; lors de la mise à jour, on risque des problèmes de
concurrence … il faudra vérifier chaque ligne modifiée pour voir si « quelqu’un d’autre » n’a pas modifié la
même ligne entretemps.
Il est à noter que des outils existent pour automatiser quelque peu le travail.
1.4 Architecture des systèmes applicatifs.
Application monolithique
Interface Traitement Accès aux
utilisateur données
Le programme comprend à la fois l’interface utilisateur, le traitement comprenant la « logique
commerciale » du produit, et les données. Typiquement, il y a un seul exécutable qui effectue toutes les
opérations.
Il n’y a dès lors aucune réutilisation possible des composants mis en œuvre. (FAT CLIENT)
1ère licence EI – Bases de données SQL – page 16,-Le programme comprend l’interface utilisateur et la « logique commerciale » du produit. Les traitements
de données sont délégués au gestionnaire de bases de données, qui peut se charger de la plupart des
vérifications liées à l’intégrité des données. Il peut également prendre en compte une partie de la logique
commerciale de par sa capacité d’utilisation des «réflexes », ou déclencheurs. (Emission automatique
de documents en fonction de l’état des bases de données, lancement de routines particulières
synchronisées avec des événements particuliers).
Le client reste relativement important et complexe, avec peu de réutilisation possible des composants.
(MEDIUM CLIENT)
1ère licence EI – Bases de données SQL – page 17,-2 Intégrité des données
2.1 Conception d’une base de données : quelques pistes de réflexion
Tables
En supposant que les données à stocker sont bien définies (discussions avec les utilisateurs),
comment créer des tables ?
• Toujours créer des tables avec un index unique (clé primaire)
• Eviter absolument les redondances d’information : ex : l’adresse du client doit se trouver en 1
seul endroit
• Si on a 2 éléments identiques de même poids (2 adresses, 2 résultats scolaires …) : toujours
travailler avec 2 tables, la table maître contenant le client avec un identificateur unique, la table
détail contenant les adresses référencées par le même identificateur (relation 1 à n)
• Eviter le plus possible les recherches avec like «%…..%», qui imposent un parcours séquentiel
coûteux, sans possibilité d’optimalisation. Dans ce cas, découper le champ en 2 parties.
Exemple, dans une adresse, ne pas mélanger le code postal et la commune, mais mettre un
champ code postal, et un champ commune
• Toute liaison 1 à 1 pourrait probablement être fusionnée en une seule table
• Toute liaison n à m impose nécessairement le recours à une table intermédiaire :
exemple : lien Professeurs – Syllabus
1 professeur peut
écrire plusieurs
ouvrages
1 ouvrage peut être écrit
par plusieurs professeurs
Index
• Choisir les clés primaires de façon efficace : les clés à incrémentation automatique qui imposent
toujours la manipulation de plusieurs tables en maître-détail ; exemple : table des branches et
des composantes – ce n’est pas très critique, mais on peut aussi créer des index sur base de
champs multiples
Chacune des tables peut être
manipulée de façon
indépendante ; des recherches
possibles. par année académique ou par
année d’études sont
Les 2 tables sont
définitivement liées entre elles,
la seule façon de faire des
sélections sur l’année d’études
est de passer par les branches.
1ère licence EI – Bases de données SQL – page 18,-2.2 Définitions
Intégrité (théorique)
Etat d'une base de données qui constitue une image fidèle du domaine d'application. Remarque :
impossible à vérifier.
Intégrité (pratique)
Etat d'une base de données qui respecte un ensemble de contraintes d'intégrité.
Remarque : techniquement vérifiable; simulation imparfaite de l'intégrité théorique.
Contrainte d'intégrité
Propriété formelle que les données et leur évolution doivent respecter à défaut de quoi elles sont
réputées corrompues.
Contrainte d'intégrité statique
Propriété formelle que les données doivent respecter à tout instant (ou à des instants prédéfinis), à
défaut de quoi elles sont réputées corrompues. Définit les états valides.
Contrainte d'intégrité dynamique
Ensemble des transitions d'état d'un objet considérées comme valides. Toute transition non valide
partant d'un état valide conduit à un état corrompu des données, même si cet état respecte toutes
les contraintes d'intégrité statiques.
Exemples de contraintes statiques
- Les domaines : exemple : valeurs permises (Sexe : (‘M’,’m’,F’,’f’)
intervalles date=(1/1/1970-31/12/1990)
règles de formation : code =[A-Z][0-9]*
valeurs exclues
- Les identifiants : contraintes d’unicité.
- Contraintes de coexistence : si un étudiant est inscrit, alors il a un login ECAM et réciproquement.
- Contraintes d’exclusivité : une personne a soit un salaire horaire, soit un traitement mensuel, mais
pas les deux.
- Contrainte au-moins-un.
- Contrainte exactement un.
- Contraintes d’inclusion de rôle : on ne peut commander un produit chez un fournisseur que s’il
propose ce produit.
- Contraintes d’exclusions de rôles : une entreprise qui loue un immeuble n’en est pas propriétaire, et
inversement.
- Contraintes intra-objet : dans une même table, pour une même commande, la quantité livrée doit
être inférieure ou égale à la quantité commandée.
- Contraintes de redondance : il est parfois intéressant de recopier des adresses dans la table des
commandes pour ne pas avoir à parcourir trop de tables.
Exemple de contraintes dynamique
L’attribut état-civil peut subir les transitions suivantes : C →M / M →S,D,V
D →M / V →M / S →D,V
1ère licence EI – Bases de données SQL – page 19,-2.3 Qui est responsable des contraintes d’intégrité ?
Le SGBD prend explicitement en charge(DDL) certaines contraintes
Domaine de valeurs Char(10), decimal(10,2), date
Colonnes obligatoires Not null
Identifiants Primary key, unique, unique index
Clés étrangères Foreign keys
On peut également programmer certaines contraintes
Prédicats Check – assertions
Déclencheurs Create triggers
Procédures stockées Create procedure
Les interfaces utilisateurs incluent en plus du code de validation des contraintes d’entreprise, mais avec
un risque accru de mauvaise gestion.
2.4 Modélisation
De nombreux outils permettent de modéliser les systèmes d’information de façon graphique et
conviviale ; ils permettent de passer du modèle conceptuel des données au modèle relationnel
correspondant. Cela permet facilement de créer des bases de données de façon pratiquement
automatisée.
1ère licence EI – Bases de données SQL – page 20,-2.5 Sources de corruption d’une base de données
• Introduction de données valides mais incorrectes : 1500,- au lieu de 5100,-. Impossible à tester.
• Données invalides : date de facturation antérieure à la date de commande
• Fausse manœuvre de l’utilisateur : oubli de lancer une procédure, pause-café…
• Erreur technique du logiciel (GPF, division par 0..)
• Erreur logique : mauvaise traduction d’organigramme
• Erreur de logiciel système (Bug SGBD)
• Attaques ciblées, fraudes, malveillances
• Attaques anonymes, virus
• Interactions parasites entre 2 processus concurrents (2 programmes modifient la même donnée ; le
dernier qui la réécrit a gagné)
• Incident matériel (Panne)
• Perte du support (Disque) • Destruction de l’installation (Naturel ou d’origine humaine)
1ère licence EI – Bases de données SQL – page 21,-3 Transactions – mode connecté
3.1 Définitions
Transaction : une transaction est l’unité fondamentale de traitement pour les accès à la base de données.
Elle est en principe constituée de plusieurs commandes SQL qui lisent et mettent à jour des éléments de
la base de données, mais la mise à jour effective ne se fait qu’à la fin de la transaction (commit). Même
en cas de panne du matériel ou du programme qui accède à la base de données à distance, la transaction
est toujours vue comme un tout. Elle possède nécessairement des propriétés A.C.I.D. :
• Atomicité : l’ensemble des instructions de la transaction est soit exécuté complètement
(succès), soit pas du tout (échec), mais jamais partiellement. Même en cas de panne de
courant en cours de transaction, le système doit revenir à l’état précédent.
• Cohérence : si la base de données était cohérente avant transaction, elle doit l’être après
(respect des contraintes d’intégrité).
• Isolation : la transaction doit s’effectuer comme si elle était seule à manipuler la base de
données. Il ne peut pas y avoir d’interférences avec les autres utilisateurs.
• Durabilité : si la transaction s’est terminée correctement, les modifications sont
permanentes, même en cas de panne matérielle.
3.2 Les primitives
Une instruction ou requête primitive jouit également des propriétés ACID. Le gestionnaire de base de
données fera appel à la notion de transaction pour les traitements internes induits par les contraintes
(cascade).
Exemple : delete from CLIENT where NCLI = 'C400'
Cette requête simpliste induira une transaction comportant énormément de modifications de la base de
données :
• Supprimer la ligne de CLIENT
• L’effet CASCADE supprimera plusieurs lignes de COMMANDE
• Qui induiront la suppression de plusieurs lignes de DETAIL
• Modification des INDEX de CLIENT, COMMANDE, DETAIL
A.C.I.D. doit être respecté dans ce cas de figure, sans interaction de l’utilisateur. Toutes les lignes en
cours de modification doivent être protégées des autres utilisateurs.
Il faut trouver un système pour pouvoir grouper des primitives : en effet la séquence suivante pose
problème :
Programme cafétéria Solution : 3.3
………
(Si incident : OK) (Si Incident : OK)
Enlever 1000 BEF au compte provision Primitive (
(Si incident : incohérence) Enlever 1000 BEF compte Provision
Ajouter 1000 BEF sur la carte MESS Ajouter 1000 BEF sur carte MESS
)
(Si incident : OK) (Si Incident : OK)
Définition d’une transaction
Une transaction est définie à l’aide de 3 primitives :
• Ouverture : begin transaction
1ère licence EI – Bases de données SQL – page 22,-• Clôture avec confirmation : commit transaction
• Clôture avec annulation : rollback transaction
Attention, certains SGBD n’ont pas de begin transaction explicite. Dès la première modification, il y a
transaction. La modification suivante donne lieu à un commit automatique, et au redémarrage d’une
transaction. A la déconnexion de la base de données, un rollback est lancé automatiquement.
Attention, un programme qui attaque le SGDB doit gérer lui-même les transactions ; voici un exemple
simple dans le cas du transfert d’argent vers un badge (portefeuille électronique):
--Demander le matricule et la somme
Get (‘matricule et somme :’,MAT,SOMME) ;
Begin transaction
Read(COMPTESPROV(NUM_MAT=MAT),RESULTAT) ;
If (PAS TROUVE) then GOTO ERREUR ;
RESULTAT.SOLDE := RESULTAT.SOLDE – SOMME ;
Update(COMPTESPROV,RESULTAT)
Read(CARTESMESS(NUM_MAT=MAT),RESULTAT) ;
If (PAS TROUVE) then GOTO ERREUR;
RESULTAT.SOLDE := RESULTAT.SOLDE + SOMME ;
Update(CARTESMESS,RESULTAT) ;
Commit transaction
--FIN NORMALE et Sortie
ERREUR : Rollback Transaction
--Sortie
1ère licence EI – Bases de données SQL – page 23,-3.4 Structures de transaction
Le schéma habituel d’un traitement de base de données est le suivant :
• Saisie des données, dialogue avec l’utilisateur
• Validation avec contrôles dans la base de données •
• Modifications de la base avec les données validées
Préparation
Acquisition données 1
Validation données 1
Mise à jour enregistrement 1
……
Acquisition données n
Validation données n
Mise à jour enregistrement n
Clôture
Exemple de structures : soit 2 opérations à faire simultanément
Séquence simple :
Acquisition donnée 1
Validation donnée 1
Mise à jour enregistrement 1
Acquisition donnée 2
Validation donnée 2
Mise à jour enregistrement 2
Décomposition 1 :
Begin transaction
Acquisition donnée 1
Validation donnée 1
Mise à jour enregistrement 1
Acquisition donnée 2
Validation donnée 2
Mise à jour enregistrement 2
Commit Transaction
Problèmes : l’acquisition est effectuée pendant la transaction : syndrome de la pause café, et
on pourrait avoir un problème de validation après écriture en base.
Décomposition 2 :
Begin transaction
Acquisition donnée 1
Validation donnée 1
Acquisition donnée 2
Validation donnée 2
Mise à jour enregistrement 1
Mise à jour enregistrement 2
Commit Transaction
Problème : l’acquisition est effectuée pendant la transaction : pause café
1ère licence EI – Bases de données SQL – page 24,-Décomposition 2bis :
Begin transaction
Acquisition donnée 1
Acquisition donnée 2
Validation donnée 1
Validation donnée 2
Mise à jour enregistrement 1
Mise à jour enregistrement 2
Commit Transaction
Problèmes : désynchronisation acquisition/validation et pause café
Décomposition 3 :
Acquisition donnée 1
Acquisition donnée 2
Begin transaction
Validation donnée 1
Validation donnée 2
Mise à jour enregistrement 1
Mise à jour enregistrement 2 Commit
Transaction
Problème : désynchronisation acquisition/validation
Décomposition 4 :
Acquisition donnée 1
Acquisition donnée 2
Validation donnée 1
Validation donnée 2
Begin transaction
Mise à jour enregistrement 1
Mise à jour enregistrement 2
Commit Transaction
Problèmes : ce qui a été validé avant la transaction risque de ne plus être valable dans la
transaction ; interaction des autres processus.
Décomposition 5 :
Acquisition donnée 1
Validation donnée 1
Acquisition donnée 2
Validation donnée 2
Begin transaction
Contrôle données 1
Contrôle données 2
Mise à jour enregistrement 1
Mise à jour enregistrement 2
Commit Transaction
Problème : consommation de ressources
1ère licence EI – Bases de données SQL – page 25,-3.5 Hiérarchie des transactions
• Programme hiérarchisé :
call A
Programme P
call C call E
call D
Modules niv. 2 A: B:
Modules niv. 3 C: D: E:
Primitive de modification de données call B
La structure des transactions ne ressemble pas du tout à ce modèle ; il n’existe pas de structure de sous-
transaction.
• Le même schéma sous forme de transaction deviendrait le suivant :
Begin Transaction Commit Transaction
call B
call A
P:
A: call C B: call D
call E
C: D: E:
Pour permettre un contrôle minimum, le schéma suivant peut être appliqué
BEGIN TRAN A SAVE TRAN B ROLLBACK TRAN B COMMIT TRAN A
Remarques :
• Aucun automatisme n’est prévu, le programmeur doit lui-même déterminer les niveaux de
transaction et les traitements d’erreur.
• Si une opération comprise dans une transaction déclenche un trigger, l’exécution du trigger
s’insère la plupart du temps dans la transaction à son point d’activation. Si le trigger échoue, la
transaction est annulée.
3.6 Transaction et Intégrité
• Une transaction doit garantir la cohérence de la base de données (ACID). Si la base de données est
cohérente à l’entrée de la transaction, elle doit l’être à la sortie, soit dans le même état (abort), soit
dans un nouvel état qui respecte aussi les contraintes d’intégrité (primary key, unique, foreign, not
null, check).
• Ceci pose un sérieux problème quand les contraintes ne sont satisfaites que suite à une séquence de
plusieurs primitives.
1ère licence EI – Bases de données SQL – page 26,-Exemples concrets :
1. Transfert d’un compte vers un autre : la somme des comptes est invariante. Après transfert vers le
premier compte, la BD est incohérente.
2. Introduction de commandes non vides : après création de la commande, la base est nécessairement
incohérente.
Si l’expression des contraintes est non déclarée, pas de problème. Si on ne déclare que l’une des
contraintes, il suffit de terminer par celle-là. Si l’expression d’au moins 2 contraintes est explicite, il
n’y a pas de solution. (Pas de commande sans détail et pas de détail sans commande)
Expression 1 : aucune contrainte
Create table COMMANDE (
NCOM integer not null primary key,
DATECOM date not null,
NCLI integer not null
) ;
Create table DETAIL(
NCOM integer not null,
NPRO integer not null,
QCOM decimal (8,2) not null,
primary key(NCOM,QCOM)
)
Tout ordonnancement est acceptable.
Begin TRANSACTION
Insert into COMMANDE values (…) ;
Insert into DETAIL values (…)
Commit TRANSACTION
Expression 2 : contrainte foreign key déclarée
Create table COMMANDE ( NCOM integer not null primary key,
DATECOM date not null,
NCLI integer not null
) ;
Create table DETAIL ( NCOM integer not null,
NPRO integer not null,
QCOM decimal (8,2) not null,
primary key(NCOM, QCOM)
foreign key (NCOM) references COMMANDE
)
Un seul ordonnancement valable :
Begin TRANSACTION
Insert into COMMANDE values (…);
Insert into DETAIL values (…)
Commit TRANSACTION
Begin TRANSACTION
Insert into DETAIL values (…) -- ERREUR REFERENTIELLE
Insert into COMMANDE values (…) ;
Commit TRANSACTION
1ère licence EI – Bases de données SQL – page 27,-Expression 3 : 2 contraintes déclarées
Create table COMMANDE ( NCOM integer not null primary key,
DATECOM date not null,
NCLI integer not null,
Check(NCOM in select NCOM from DETAIL)
);
Create table DETAIL ( NCOM integer not null,
NPRO integer not null,
QCOM decimal (8,2) not null,
primary key(NCOM,QCOM)
foreign key (NCOM) references COMMANDE
)
Aucune solution valable :
Begin TRANSACTION
Insert into COMMANDE values (…) ; -- ERREUR DE CHECK
Insert into DETAIL values (…)
Commit TRANSACTION
Begin TRANSACTION
Insert into DETAIL values (…) -- ERREUR REFERENTIELLE
Insert into COMMANDE values (…) ;
Commit TRANSACTION
Solution : débrayer la vérification des contraintes pendant la transaction
ALTER TABLE COMMANDE NOCHECK CONSTRAINT
Dès que les données existent : ALTER TABLE COMMANDE CHECK CONSTRAINT
Problème : Les données introduites ne sont pas testées ! ! Il faut dès lors les re-tester en renvoyant
des modifications « bidon », en remettant les mêmes valeurs en UPDATE.
Solution meilleure(Oracle) : à la création de table, il est possible de spécifier que la vérification
des contraintes sera d’office reportée au commit des transactions.
Create table COMMANDE ( NCOM integer not null primary key,
DATECOM date not null,
NCLI integer not null,
Check(NCOM in select NCOM from DETAIL)
Initially deferrable
) ;
Create table DETAIL ( NCOM integer not null,
NPRO integer not null,
QCOM decimal (8,2) not null,
primary key(NCOM,QCOM)
foreign key (NCOM) references COMMANDE
initially deferrable
)
3.7 Transactions multi-instructions et gestion d’erreur.
Soit la séquence suivante (sql server – le premier élément inséré est une clé unique):
BEGIN TRANSACTION
Insert Test VALUES(1,1)
Insert Test VALUES(1,2) -- Violation de clé unique
Insert Test VALUES(2,2)
COMMIT TRANSACTION
GO
1ère licence EI – Bases de données SQL – page 28,-Dans ce cas de figure, la transaction va insérer les 2 lignes correctes, et ne tiendra pas compte de
la 2ème. En effet, aucune vérification d’erreur n’a été faite entre les 2 instructions.
Une version correcte de cette transaction serait :
BEGIN TRANSACTION
Insert Test VALUES(1,1)
If @@ERROR 0 GOTO TRAN_ABORT Insert Test VALUES(1,2)
If @@ERROR 0 GOTO TRAN_ABORT Insert Test VALUES(2,2)
If @@ERROR 0 GOTO TRAN_ABORT
COMMIT TRANSACTION
GOTO FIN
TRAN_ABORT : ROLLBACK TRANSACTION
FIN : GO
Il est également possible de positionner un drapeau global à l’application, permettant d’avoir un
comportement prévisible d’annulation de toute la transaction en cas de problème
SET XACT_ABORT ON
BEGIN TRANSACTION
Insert Test VALUES(1,1)
Insert Test VALUES(1,2) -- Violation de clé unique : annulation
Insert Test VALUES(2,2)
COMMIT TRANSACTION
GO
Le gestionnaire SQL travaille TOUJOURS de cette façon quand une instruction unique modifie
plusieurs lignes (Atomicité)
1ère licence EI – Bases de données SQL – page 29,-4 Protection contre les incidents : journal et sauvegarde
4.1 Exposé du problème
En cas d’incident (fortuit ou intentionnel), la cohérence des données doit être garantie. Il faut pouvoir
repérer les données corrompues. Les propriétés A(tomicité) et D(urabilité) des transactions relèvent de
la protection contre les incidents.
Atomicité : en cas d’incident au sein de la transaction, les modifications déjà réalisées doivent être
défaites (rollback)
Durabilité : en cas d’incident après la clôture de la transaction, les données doivent être remises au
moins dans l’état où elles étaient à la sortie de la transaction.
Deux fichiers annexes protègent la base de données :
Le journal (LOG FILE)
La sauvegarde (BACKUP)
4.2 Gestion des tampons
Principe : Temps de transfert en mémoire : 10-7 sec (au plus) – Temps de transfert sur disque :
15msec (au mieux – le déplacement du bras se fait en 8msec dans les meilleurs cas).
La mémoire va au moins 150.000 fois plus vite que le disque.
EVITER ABSOLUMENT LES LECTURES ET ECRITURES SUR DISQUE !
TAMPON DISQUE
Programme
Donnée
0.1 microseconde
15000 microsecondes
Il est intéressant d’avoir un tampon en mémoire très important, mais en cas d’incidents, la mémoire est
définitivement perdue. Un schéma plus complet des échanges matériels est le suivant :
Programme SGBD SYSTEME d’EXPLOITATION CONTRÔLEUR
CACHE
TAMPON TAMPON CONTROLEUR
Programme
Var Abcdefg0123
Abcdefg0123
DISQUE (Pistes
Echange de secteurs et Secteurs)
Echange Echange de pages
d’enregistrements Echange de secteurs & pistes
1ère licence EI – Bases de données SQL – page 30,-Pour accélérer au maximum le processus, des algorithmes LRU (Last Recently Used) sont mis en place
pour gérer les accès aux tampons de mémoire.
En cas de lecture : le SGDB détermine si l’enregistrement est disponible dans le tampon. Soit il s’y
trouve : lecture instantanée, soit il ne s’y trouve pas : il y a recherche d’un cadre de stockage libre,
avec 2 cas d’espèce : soit il y a un cadre libre, et l’enregistrement est lu sur le disque (1 seule lecture),
soit il n’y a plus de place, et le cadre dont le contenu n’a plus été utilisé depuis le plus long temps
est écrasé. (S’il a subi une modification, il y a écriture sur disque)
En cas d’écriture : si l’enregistrement est disponible dans le tampon : mise à jour du tampon. S’il ne
s’y trouve pas : même comportement que ci-dessus.
On n’écrira les modifications sur disque que dans 4 cas :
Le cadre doit être libéré (LRU)
On demande la fermeture de la table ou de la BD
Le programme décide de vider le tampon(flush)
A la fin d’une transaction
Conclusions
Les données du tampon sont plus récentes que celles du disque
Les données du disque sont incohérentes
L’état courant de la base de données est constitué du tampon + le disque
En cas d’incident et de perte de mémoire centrale, la base de données est corrompue
On utilisera donc la technique du JOURNAL et du BACKUP pour garantir la cohérence.
4.3 Sauvegarde (Backup)
Copie complète ou partielle de la base de données prise à un instant de référence
Copie complète : version prête à l’emploi, demandant un temps très long pour sa fabrication
Copie partielle ou incrémentale : on ne stocke que les modifications depuis la dernière copie complète
; rapide mais la reconstitution complète est nécessairement lente.
La sauvegarde doit nécessairement être intégrée au SGBD, puisque celui-ci doit mémoriser de manière
très précise l’instant de la sauvegarde. La plupart des gestionnaires de SGBD intègrent une fonction de
sauvegarde automatisée, qui se lance à des moments choisis. L’intervenant humain n’a plus qu’à enlever
la cassette. (On peut également répliquer des bases de données pour garantir la continuation du service)
4.4 Journal (Log File)
Fichier séquentiel dans lequel sont consignées toutes les modifications de la base de données, ainsi que
l’historique des transactions.
Principe :
On écrit anticipativement dans le journal avant de lancer une transaction (image «avant »).
On effectue les opérations liées à la transaction .
On écrit dans le journal après clôture de la transaction (image « après »)
1ère licence EI – Bases de données SQL – page 31,-Vous pouvez aussi lire
