Updated DB Implementation

DB Implementation/TD/TD1.md

+---
+author: Robin VAN DE MERGHEL
+date: 2023
+title: Bases de données
+lang: fr
+geometry: margin=2cm
+---
+
+# Cours magistral 1
+
+- Histoire des bases de données (du FBI à IBM)
+- Introduction sur les bases de données relationnelles
+  - Les contraintes
+    - Les contraintes d'intégrité
+    - Les contraintes implicites
+- TD 1 (wtf)
+
+## TD1
+
+### Exercice 1
+
+On va considérer 3 tables : `Conference`, `Specialite` et `AnneeConf` :
+
+```plantuml
+@startuml
+!define primary_key(x) <b><color:#b8861b><&key></color> x</b>
+!define foreign_key(x) <color:#aaaaaa><&key></color> x
+!define column(x) <color:#efefef><&media-record></color> x
+!define table(x) entity x << (T, white) >>
+
+table( conference ) {
+    primary_key( idConf ) : int
+    column( sigle ) : varchar
+    column( nomConf ) : varchar
+    column( porteeConf ) : varchar
+    foreign_key( idSpé ) : int
+}
+
+table( specialite ) {
+    primary_key( idSpé ) : int
+    column( libelle ) : varchar
+}
+
+table( anneeConf ) {
+    primary_key( annee ) : int
+    foreign_key( idConf ) : int
+    column( ville ) : varchar
+    column( pays ) : varchar
+}
+
+conference <-  anneeConf
+specialite <- conference
+
+@enduml
+```
+
+#### Question 1 et 2
+
+> **Donner les super-clés des tables `Spécialité`, et `AnneeConf`.**
+
+Les super-clés de `Specialite` sont :
+
+- `idSpé` (car c'est la clé primaire)
+- `idSpé` + `libelle`
+
+Les super-clés de `AnneeConf` sont :
+
+- `annee` et `idConf` (car c'est la clé primaire)
+- `idConf`, `annee` et `ville`
+- `idConf`, `annee`, `ville` et `pays`
+
+
+#### Question 3
+
+> **On va considérer que la base de donnée est remplie comme suit :**
+
+
+> | idSpé | libelle |
+> |-------|---------|
+> | 0     | DB |
+
+
+> | idConf | sigle | nomConf | porteeConf | idSpé |
+> |--------|-------|---------|------------|-------|
+> | 0 | BDA | BD annuelle | France | 0 |
+
+> | idConf | annee | ville | pays |
+> |--------|-------|-------|------|
+> | 0 | 2022 | Clermont-Ferrand | France |
+
+
+> **Donner les clés étrangères de ces 3 tables (`Specialite`, `Conference` et `AnneeConf`).**
+
+- `idConf` est une clé étrangère de `AnneeConf`, elle référence `idConf` de `Conference`
+- `idSpé` est une clé étrangère de `Conference`, elle référence `idSpé` de `Specialite`
+- `Specialite` n'a pas de clé étrangère, car elle n'en référence pas d'autres
+
+En effet on le voit sur le schéma suivant :
+
+```mermaid
+graph LR
+    AnneeConf --> Conference
+    Conference --> Specialite
+```
+
+##### Question 4.1
+
+> **Que se passe-t-il avec : `INSERT INTO Specialite VALUES (0, 'maths')` ?**
+
+Il y a une erreur car la contrainte de clé primaire est violée par cette insertion.
+
+##### Question 4.2
+
+> **Que se passe-t-il avec : `INSERT INTO AnneConf VALUES (0, 2021, `Paris`, `France`)` ?**
+
+La clé primaire n'est pas violée (la clé est `idConf` + `annee`). Donc l'insertion est possible.
+
+On obtient donc :
+
+> | idConf | annee | ville | pays |
+> |--------|-------|-------|------|
+> | 0 | 2022 | Clermont-Ferrand | France |
+> | 0 | 2021 | Paris | France |
+
+##### Question 4.3
+
+> **Que se passe-t-il avec : `INSERT INTO AnneConf VALUES (1, 2022, `Sydney`, `Australie`)` ?**
+
+L'insertion viole la clé étrangère de la table `AnneeConf` car il n'y a pas de `idConf` = 1 dans la table `Conference`.
+
+##### Question 4.4
+
+> **Que se passe-t-il avec : `INSERT INTO Conference VALUES (1, `VLDB`, `VLDB`, `mondiale`, 0)` ?**
+
+Il n'y a pas de problème car la clé primaire n'est pas violée et la clé étrangère est présente dans la table `Specialite`.
+
+On obtient donc :
+
+> | idConf | sigle | nomConf | porteeConf | idSpé |
+> |--------|-------|---------|------------|-------|
+> | 0 | BDA | BD annuelle | France | 0 |
+> | 1 | VLDB | VLDB | mondiale | 0 |
+
+##### Question 4.5
+
+> **Que se passe-t-il avec : `DELETE FROM Conference WHERE idConf = 0` ?**
+
+La suppression est possible car la clé primaire n'est pas violée. Il existe bien une clé primaire avec `idConf` = 0.
+
+#### Question 5
+
+> **Modifier (très simplement) l’ensemble des opérations précédentes pour qu’elles soient appliquées en ne violant aucune contrainte.**
+
+On peut modifier les opérations précédentes de la manière suivante :
+
+```sql
+INSERT INTO Specialite VALUES (1, 'maths');
+INSERT INTO AnneConf VALUES (1, 2021, 'Paris', 'France');
+INSERT INTO Conference VALUES (1, 'VLDB', 'VLDB', 'mondiale', 1);
+DELETE FROM Conference WHERE idConf = 0;
+```
+
+On ne viole aucune contrainte avec ces requêtes car on a ajouté une nouvelle spécialité et on a modifié les clés étrangères de `Conference` et `AnneeConf`.
+
+### Exercice 2
+
+#### Question 1
+
+> **Donner le script de création des tables `PERSONNE`, `AUTEUR` et `ECRIT` pour le schéma relationnel donné ci-dessous. N’oubliez pas de spécifier les différentes contraintes d’intégrité.**
+
+Le schéma relationnel est le suivant :
+
+```plantuml
+@startuml
+
+
+!define primary_key(x) <b><color:#b8861b><&key></color> x</b>
+!define foreign_key(x) <color:#aaaaaa><&key></color> x
+!define column(x) <color:#efefef><&media-record></color> x
+!define table(x) entity x << (T, white) >>
+
+table(Personne) {
+
+    primary_key( idPers ) : int
+    column( nom ) : varchar
+    column( prenom ) : varchar
+
+}
+
+table( Auteur ) {
+
+    primary_key( idPers ) : int
+    column( labo ) : varchar
+    foreign_key( idSpe ) : int
+
+}
+
+table( Specialite ) {
+
+    primary_key( idSpe ) : int
+    column( libelle ) : varchar
+
+}
+
+table( Lecteur ) {
+
+    foreign_key( primary_key( idPers ) ) : int    
+    column( email ) : varchar
+    column( adresse ) : varchar
+    column( ville ) : varchar
+    column( code ) : int
+    column( pays ) : varchar
+
+}
+
+table( Ecrit ) {
+
+    foreign_key( primary_key( idPers ) ) : int
+    foreign_key( primary_key( idConf ) ) : int
+    column( ordre ) : int
+
+}
+
+table( Conference ) {
+
+    primary_key( idConf ) : int
+    column( sigle ) : varchar
+    column( nomConf ) : varchar
+    column( porteeConf ) : varchar
+    foreign_key( idSpe ) : int
+
+}
+
+table( AnneeConf ) {
+
+    foreign_key( primary_key( idConf ) ) : int
+    primary_key( annee ) : int
+    column( ville ) : varchar
+    column( pays ) : varchar
+
+}
+
+table( Article ) {
+
+    primary_key( idArt ) : int
+    column( titre ) : varchar
+    column( typeArt ) : varchar
+    column( format ) : varchar
+    column( emplacement ) : int
+    column( taille ) : int
+    foreign_key( annee ) : int
+    foreign_key( idConf ) : int
+
+}
+
+table( Telechargement ) {
+
+    primary_key( idTelechargement ) : int
+    column( dateTelechargement ) : date
+    column( vitesse ) : int
+    foreign_key( idArt ) : int
+    foreign_key( idPers ) : int
+
+}
+
+Lecteur --> Personne
+Ecrit --> Auteur
+Auteur -> Personne
+Auteur --> Specialite
+Conference -> Specialite
+AnneeConf -> Conference
+Article -> AnneeConf
+Ecrit -> Article
+Telechargement -> Article
+Telechargement -> Lecteur
+
+@enduml
+```
+
+
+Le script de création des tables est le suivant :
+
+```sql
+CREATE TABLE Personne (
+    idPers INT NOT NULL,
+    nom VARCHAR(50) NOT NULL,
+    prenom VARCHAR(50) NOT NULL,
+    PRIMARY KEY (idPers)
+);
+
+CREATE TABLE Auteur (
+    idPers INT NOT NULL,
+    labo VARCHAR(50) NOT NULL,
+    idSpe INT NOT NULL,
+    PRIMARY KEY (idPers),
+    FOREIGN KEY (idPers) REFERENCES Personne(idPers),
+    FOREIGN KEY (idSpe) REFERENCES Specialite(idSpe)
+);
+
+CREATE TABLE Ecrit (
+    idPers INT NOT NULL,
+    idConf INT NOT NULL,
+    ordre INT NOT NULL,
+    PRIMARY KEY (idPers, idConf),
+    FOREIGN KEY (idPers) REFERENCES Personne(idPers),
+    FOREIGN KEY (idConf) REFERENCES Conference(idConf)
+);
+```
+
+#### Question 2
+
+> **Vider la table avec des auteurs.**
+
+On peut vider la table avec des auteurs avec la requête suivante :
+
+```sql
+DELETE FROM Auteur;
+```
+
+#### Question 3
+
+> **Supprimer les tables PERSONNE, AUTEUR et ECRIT.**
+
+On peut supprimer les tables avec la requête suivante :
+
+```sql
+DROP TABLE Ecrit;
+DROP TABLE Auteur;
+DROP TABLE Personne;
+```
+
+### Exercice 3
+
+#### Question 1
+
+> **Écrire une requête SQL pour récupérer les spécialités.**
+
+On peut récupérer les spécialités avec la requête suivante :
+
+```sql
+SELECT * FROM Specialite;
+```
+
+#### Question 2
+
+> **Écrire une requête SQL pour récupérer les sigles et noms des conférences.**
+
+On peut récupérer les sigles et noms des conférences avec la requête suivante :
+
+```sql
+SELECT sigle, nomConf FROM Conference;
+```
+
+#### Question 3
+
+> **Écrire une requête SQL pour récupérer sans répétition les villes où une conférence a eu lieu.**
+
+On peut récupérer les villes où une conférence a eu lieu avec la requête suivante :
+
+```sql
+SELECT DISTINCT ville FROM AnneeConf;
+```
+
+#### Question 4
+
+> **Écrire une requête SQL pour récupérer les noms de conférence associée aux villes et l’année où elle a eu lieu.**
+
+On peut récupérer les noms de conférence associée aux villes et l'année où elle a eu lieu avec la requête suivante :
+
+```sql
+SELECT nomConf, ville, annee FROM AnneeConf NATURAL JOIN Conference;
+```

DB Implementation/TD/TD2.md

+---
+title: TD 2 Implémentation BDD
+author: VAN DE MERGHEL Robin
+date: 2023
+lang: fr
+geometry: margin=2cm
+---
+
+# Exercice 1
+
+> **Considérons les deux transactions suivantes :**
+> `T1 : READ(A,t) ; t := t+2 ; WRITE(A,t) ; READ(B,t) ; t=t*3 ; WRITE(B,t) ; COMMIT`
+> `T2 : READ(B,s) ; s := s*2 ; WRITE(B,s) ; READ(A,s) ; s=s+3 ; WRITE(A,s) ; COMMIT`
+
+
+## Question 1
+
+> **Donner les plans correspondant aux exécutions en série $(T_1,T_2)$ et $(T_2,T_1)$**
+
+Avc $(T_1, T_2)$ :
+
+| $T_1$ | $T_2$ | A | B |
+|-------|-------|---|---|
+| $r(A, t)$ | | $a$ | |
+| $t:=t+2$ | | $a$ | |
+| $w(A, t)$ | | $a+2$ | |
+| $r(B, t)$ | | $a+2$ | $b$ |
+| $t:=t\times 3$ | | $a+2$ | $b$ |
+| $w(B, t)$ | | $a+2$ | $b\times 3$ |
+| $commit$ | | $a+2$ | $b\times 3$ |
+| | $r(B, s)$ | $a+2$ | $b\times 3$ |
+| | $s:=s\times 2$ | $a+2$ | $b\times 3$ |
+| | $w(B, s)$ | $a+2$ | $b\times 6$ |
+| | $r(A, s)$ | $a+2$ | $b\times 6$ |
+| | $s:=s+3$ | $a+2$ | $b\times 6$ |
+| | $w(A, s)$ | $a+5$ | $b\times 6$ |
+| | $commit$ | $a+5$ | $b\times 6$ |
+
+
+État final : $A = a+5$ et $B = b\times 6$
+
+Avec $(T_2, T_1)$ :
+
+| $T_2$ | $T_1$ | A | B |
+|-------|-------|---|---|
+| $r(B, s)$ | |  | $b$ |
+| $s:=s\times 2$ | |  | $b$ |
+| $w(B, s)$ | |  | $b\times 2$ |
+| $r(A, s)$ | | $a$ | $b\times 2$ |
+| $s:=s+3$ | | $a$ | $b\times 2$ |
+| $w(A, s)$ | | $a + 3$ | $b\times 2$ |
+| $commit$ | | $a + 3$ | $b\times 2$ |
+| | $r(A, t)$ | $a + 3$ | $b\times 2$ |
+| | $t:=t+2$ | $a + 3$ | $b\times 2$ |
+| | $w(A, t)$ | $a + 5$ | $b\times 2$ |
+| | $r(B, t)$ | $a + 5$ | $b\times 2$ |
+| | $t:=t\times 3$ | $a + 5$ | $b\times 2$ |
+| | $w(B, t)$ | $a + 5$ | $b\times 6$ |
+| | $commit$ | $a + 5$ | $b\times 6$ |
+
+État final : $A = a+5$ et $B = b\times 6$
+
+
+## Question 2
+
+> **Montrer que les exécutions $(T_1,T_2)$ et $(T_2,T_1)$ sont équivalentes, en commençant sur un exemple de base de données initial.**
+
+
+On a les deux mêmes états finaux, donc les deux exécutions sont équivalentes.
+
+## Question 3
+
+> **Donner l'exemple d'une exécution de $T_1$ et de $T_2$ qui fait appraître un problème de lectures impropres.**
+
+Avec $(T_1, T_2)$ :
+
+
+| $T_1$ | $T_2$ | A | B |
+|-------|-------|---|---|
+| $r(A, t)$ | | $a$ | |
+| $t:=t+2$ | | $a$ | |
+| $w(A, t)$ | | $a+2$ | |
+| $r(B, t)$ | | $a+2$ | $b$ |
+| $t:=t\times 3$ | | $a+2$ | $b$ |
+| | $r(B, s)$ | $a+2$ | $b$ |
+| | $s:=s\times 2$ | $a+2$ | $b$ |
+| | $w(B, s)$ | $a+2$ | $b\times 2$ |
+| | $r(A, s)$ | $a+2$ | $b\times 2$ |
+| | $s:=s+3$ | $a+2$ | $b\times 2$ |
+| | $w(A, s)$ | $a+5$ | $b\times 2$ |
+| $w(B, t)$ | | $a+5$ | $b\times 2$ |
+| $commit$ | | $a+5$ | $b\times 2$ |
+| | $commit$ | $a+5$ | $b\times 2$ |
+
+
+On a $a+3$ dans $A$, modifié par $T_2$, alors que $T_1$ n'a pas encore commit.
+
+
+## Question 4
+
+> **Donner l'exemple d'une exécution de $T_1$ et de $T_2$ qui fait appraître un problème de perte de mise à jour.**
+
+
+Avec $(T_1, T_2)$ :
+
+| $T_1$ | $T_2$ | A | B |
+|-------|-------|---|---|
+| $r(A, t)$ | | $a$ | |
+| $t:=t+2$ | | $a$ | |
+| $w(A, t)$ | | $a+2$ | |
+| $r(B, t)$ | | $a+2$ | $b$ |
+| $t:=t\times 3$ | | $a+2$ | $b$ |
+| | $r(B, s)$ | $a+2$ | $b$ |
+| | $s:=s\times 2$ | $a+2$ | $b$ |
+| | $w(B, s)$ | $a+2$ | $b\times 2$ |
+| | $r(A, s)$ | $a+2$ | $b\times 2$ |
+| | $s:=s+3$ | $a+2$ | $b\times 2$ |
+| | $w(A, s)$ | $a+5$ | $b\times 2$ |
+| $w(B, t)$ | | $a+5$ | $b\times 2$ |
+| $commit$ | | $a+5$ | $b\times 2$ |
+| | $commit$ | $a+5$ | $b\times 2$ |
+
+
+On a $a+3$ dans $A$, modifié par $T_2$, alors que $T_1$ n'a pas encore commit.
+
+
+# Exercice 2
+
+> **Considérons les deux transactions suivantes :**
+> `T1 : r1(a) w1(a) w1(b) r1(b) commit1`
+> `T2 : r2(b) w2(b) r2(a) w2(a) commit2`
+
+
+## Question 1
+
+> **Donner trois exécutions sérialisables de $T_1$ et $T_2$.**
+
+On a :
+
+$$E_1 = (T_1, T_2) = r_1(a) \ w_1(a) \ w_1(b) \ r_1(b) \ r_2(b) \ w_2(b) \ r_2(a) \ w_2(a) \ commit_1 \ commit_2$$
+
+| $T_1$ | $T_2$ |
+|-------|-------|
+| $r_1(A)$ | |
+| $w_1(A)$ | |
+| $w_1(B)$ | |
+| $r_1(B)$ | |
+| $commit_1$ | |
+| | $r_2(B)$ |
+| | $w_2(B)$ |
+| | $r_2(A)$ |
+| | $w_2(A)$ |
+| | $commit_2$ |
+
+
+On a :
+
+$$E_2 = (T_2, T_1) = r_2(b) \ w_2(b) \ r_2(a) \ w_2(a) \ r_1(a) \ w_1(a) \ w_1(b) \ r_1(b) \ commit_2 \ commit_1$$
+
+| $T_2$ | $T_1$ |
+|-------|-------|
+| $r_2(B)$ | |
+| $w_2(B)$ | |
+| $r_2(A)$ | |
+| $w_2(A)$ | |
+| $commit_2$ | |
+| | $r_1(A)$ |
+| | $w_1(A)$ |
+| | $w_1(B)$ |
+| | $r_1(B)$ |
+| | $commit_1$ |
+
+On a aussi :
+
+| $T_1$ | $T_2$ |
+|-------|-------|
+| $r_1(A)$ | |
+| $w_1(A)$ | |
+| $commit_1$ | |
+| | $r_2(B)$ |
+| | $w_2(B)$ |
+| | $commit_2$ |
+| $w_1(B)$ | |
+| $r_1(B)$ | |
+| $commit_1$ | |
+| | $r_2(A)$ |
+| | $w_2(A)$ |
+| | $commit_2$ |
+
+Équivalent à :
+
+$$E = r_1(a) \ w_1(a) \ commit_1 \ r_2(b) \ w_2(b) \ commit_2 \ w_1(b) \ r_1(b) \ commit_1 \ r_2(a) \ w_2(a) \ commit_2$$
+

DB Implementation/TD/plantuml-images/a4d8dc42f5f8613a2a64383303ec3ec29a47ca54.uml

+@startuml
+!define primary_key(x) <b><color:#b8861b><&key></color> x</b>
+!define foreign_key(x) <color:#aaaaaa><&key></color> x
+!define column(x) <color:#efefef><&media-record></color> x
+!define table(x) entity x << (T, white) >>
+
+table( conference ) {
+    primary_key( idConf ) : int
+    column( sigle ) : varchar
+    column( nomConf ) : varchar
+    column( porteeConf ) : varchar
+    foreign_key( idSpé ) : int
+}
+
+table( specialite ) {
+    primary_key( idSpé ) : int
+    column( libelle ) : varchar
+}
+
+table( anneeConf ) {
+    primary_key( annee ) : int
+    foreign_key( idConf ) : int
+    column( ville ) : varchar
+    column( pays ) : varchar
+}
+
+conference <-  anneeConf
+specialite <- conference
+
+@enduml
\ No newline at end of file

DB Implementation/TD/plantuml-images/b024c666f5bd66d27319d0b4d89345fbb5f1e25e.uml

+@startuml
+
+
+!define primary_key(x) <b><color:#b8861b><&key></color> x</b>
+!define foreign_key(x) <color:#aaaaaa><&key></color> x
+!define column(x) <color:#efefef><&media-record></color> x
+!define table(x) entity x << (T, white) >>
+
+table(Personne) {
+
+    primary_key( idPers ) : int
+    column( nom ) : varchar
+    column( prenom ) : varchar
+
+}
+
+table( Auteur ) {
+
+    primary_key( idPers ) : int
+    column( labo ) : varchar
+    foreign_key( idSpe ) : int
+
+}
+
+table( Specialite ) {
+
+    primary_key( idSpe ) : int
+    column( libelle ) : varchar
+
+}
+
+table( Lecteur ) {
+
+    foreign_key( primary_key( idPers ) ) : int    
+    column( email ) : varchar
+    column( adresse ) : varchar
+    column( ville ) : varchar
+    column( code ) : int
+    column( pays ) : varchar
+
+}
+
+table( Ecrit ) {
+
+    foreign_key( primary_key( idPers ) ) : int
+    foreign_key( primary_key( idConf ) ) : int
+    column( ordre ) : int
+
+}
+
+table( Conference ) {
+
+    primary_key( idConf ) : int
+    column( sigle ) : varchar
+    column( nomConf ) : varchar
+    column( porteeConf ) : varchar
+    foreign_key( idSpe ) : int
+
+}
+
+table( AnneeConf ) {
+
+    foreign_key( primary_key( idConf ) ) : int
+    primary_key( annee ) : int
+    column( ville ) : varchar
+    column( pays ) : varchar
+
+}
+
+table( Article ) {
+
+    primary_key( idArt ) : int
+    column( titre ) : varchar
+    column( typeArt ) : varchar
+    column( format ) : varchar
+    column( emplacement ) : int
+    column( taille ) : int
+    foreign_key( annee ) : int
+    foreign_key( idConf ) : int
+
+}
+
+table( Telechargement ) {
+
+    primary_key( idTelechargement ) : int
+    column( dateTelechargement ) : date
+    column( vitesse ) : int
+    foreign_key( idArt ) : int
+    foreign_key( idPers ) : int
+
+}
+
+Lecteur --> Personne
+Ecrit --> Auteur
+Auteur -> Personne
+Auteur --> Specialite
+Conference -> Specialite
+AnneeConf -> Conference
+Article -> AnneeConf
+Ecrit -> Article
+Telechargement -> Article
+Telechargement -> Lecteur
+
+@enduml
\ No newline at end of file

DB Implementation/cm5.md

+---
+author: Robin VAN DE MERGHEL
+date: 2023
+title: Bases de données
+lang: fr
+geometry: margin=2cm
+---
+
+| | partagé | exclusif |
+|- | --- | --- |
+| partagé | accepté | refusé |
+| exclusif | refusé | refusé |
+
+Si un élément est vérouillé de manière partagée et exclusive alors on dira qu'il est vérrouillé de manière exclusive.
+
+| $T_1$ | $T_2$ | A | B |
+| --- | --- | --- | --- |
+| $s_1(A)r_1(A)$ |  | 25 | 25 |
+| $A = A+10$ |  | - | - |
+| $X_1(A)W_1(A)u_1(A)$ | - | 125 | - |
+| - | $s_2(A)r_2(A)$ | - | - |
+| - | $A = 2A$ | - | - |
+| - | $X_2(A)w_2(A)u_2(A)$ | 250 | - |
+| - | $s_2(B)r_2(B)$ | - | - |
+| - | $B = 2B$ | - | - |
+| - | $X_2(B)w_2(B)u_2(B)$ | - | 50 |
+| $s_1(B)r_1(B)$ | - | - | - |
+| $B=B+100$ | - | - | - |
+| $x_1(B)w_1(B)u_1(B)$ | - | - | 150 |
+
+On a une utilisation valide des verrous, qui se suffit pas pour obtenir la sérialisabilité.
+
+# Verrouillage en deux phases (2PL)
+
+Pour assurer la sérialisabilité, on considère le protocol de verrouillage en deux phases (2PL).
+
+Dans chaque transaction, tous les verrous sont déposés avant que le premier verrou ne soit relâché.
+
+Deux phases de verrouillage :
+
+- acquisition des verrous
+- relâchement des verrous
+
+![Évolution des verrous](img/verrous.jpg)
+
+## Exemple
+
+| $T_1$ | $T_2$ | A | B |
+| --- | --- | --- | --- |
+| $s_1(A)r_1(A)$ |  | 25 | 25 |
+| $A = A+100$ |  | - | - |
+| $X_1(A)w_1(A)X_1(B)u_1(A)$ |  | 125 | - |
+|  | $s_2(A)r_2(A)$ | - | - |
+| | $A = 2A$ | - | - |
+| | $X_2(A)w_2(A)$ | 250 | - |
+| | $s_2(B)$ | - | - |
+| $r_1(B)$ |  | - | - |
+| $B = B+100$ |  | - | - |
+| $w_1(B)u_1(B)$ |  | - | 125 |
+| | $s_2(B)u_2(A)r_2(B)$ | - | - |
+| | $B = 2B$ | - | - |
+| | $X_2(B)w_2(B)u_2(B)$ | - | 250 |
+
+# Un risque d'interblocage
+
+Il y a un risque d'interblocage (dead lock) si avec le protocole 2PL, c'est à dire une situation où des transations sont forcée d'attendre indéfiniment un verrou obtenu par une autre transaction.
+
+
+| $T_1$ | $T_2$ |
+| --- | --- |
+| $s_1(A)r_1(A)$ |  |
+| | $s_2(B)r_2(B)$ |
+| $A = A+100$ |  |
+| | $B = 2B$ |
+| $X_1(A)w_1(A)$ |  |
+| | $X_2(B)w_2(B)$ |
+| $s_1(B)$ |  |
+| | $s_2(A)$ |
+| *en attente* |  *en attente* |
+
+## Exercice
+
+> **Rajouter des verrous et voir en quoi ça change l'exécution**
+
+$$E = r_1(A) \ r_2(B) \ r_3(C) \ W_1(B) \ W_2(C) \ W_3(A)$$
+
+$$E = r_1(A) \ r_2(B) \ r_3(C) \ W_3(B) \ W_1(C) \ W_2(A)$$
+
+
+### Cas 1 
+
+![Execution](img/Execution.jpg)
+
+### Cas 2
+
+![Execution](img/Execution2.jpg)
+
+# Exécutions réparables en cascade
+
+On note :
+
+- $C_i$ commit de la transaction
+- $a_i$ annulation de la transaction
+
+## Exemple
+
+| $T_1$ | $T_2$ | A | 
+| --- | --- | --- | 
+| $r_1(A)$ |  | 25 |
+| $A = A+100$ |  | - |
+| $w_1(A)$ |  | - |
+|  | $r_2(A)$ | - | 
+| | $A = 2A$ | - |
+| | $w_2(A)$ | 250 |
+| | $C_2$ | - |
+| $a_1$ |  | - |
+
+L'action de $T_2$ ne peut-être conserve car elle repose sur celle de $T_1$, qui a été annulée, mais $T_2$ ne peut être annulée car elle a été validée.
+
+## Définition
+
+Une exécution est reparable en cascade si chaque transaction est validée après les transactions dont elle a lu des données modifier.
+
+Tu peux reverse avec `ROLLBACK`(merci frérot)
+
+Ryadh a une information très importante : Il a besoin d'aide pour le projet. #JeSuisRyadh.
+oui c mwa
+
+$$E_1 = w_1(A) \ w_1(B) \ w_2(A) \ r_2(B) \ C_1 \ C_2$$
+
+$E_1$ est réparable car $T_2$ lit une valeur modifiée par $T_1$, et $T_2$ est validée après $T_1$.
+
+$$E_2 = w_2(A) \ w_1(B) \ w_1(A) \ r_2(B) \ C_1 \ C_2$$
+
+$E_2$ est réparable, mais non sérialisable.
+
+$$E_3 = r_1(A) \ r_2(B) \ w_2(B) \ w_1(A) \ r_3(B) \ r_2(A) \ w_3(A)$$
+
+Si $T_1$ est annulée, alors $T_2$ et $T_3$ doivent être annulées.
+
+On observe une annulation en cascade.
+
+## Définition
+
+Une execution est sous annulation en cascade (SAC), si toutes les transactions lisent des valeurs modifier issues uniquement de transactions déjà validées.
+
+## Exemple
+
+- $E_1$ n'est pas SAC.
+
+-  $E_4 : w_1(A) \ w_2(A) \ C_1 \ r_2(B) \ C_2$
+
+- $E_4$ est un SAC
+
+## Proposition
+
+Si une exécution est SAC, alors elle est réparable en cascade.
+
+## Définition
+
+Une exécution avec verrous est stricte si dans chaque transaction, aucun verrou exclusif n'est relâché avant que la transaction ne soit validée ou annulée.
+
+![Verrous exclusifs](img/Verrous%20Exclusifs.jpg)
+
+## Proposition
+
+Une exécution stricte est sérialisable et sans annulation en cascade.
+
+![Graphique](img/graphique.jpg)
+