**Atomicité** en SQL fait référence à l'une des propriétés ACID, qui garantit que nous utilisons des transactions lors de l'interrogation des données à l'aide de SQL.    
Dans le contexte des bases de données SQL, l'atomicité garantit que **toutes les opérations** au sein d'une unité logique particulière sont complétées, ou **aucune d'entre elles** ne l'est.
## Traitement des transactions en SQL

## Caractéristiques clés


- **Rollback** : Si une partie échoue (par exemple, en raison d'une erreur ou d'une violation de contrainte), la transaction entière est annulée, rétablissant les modifications ;

- **Commit** : Si toutes les opérations réussissent, la transaction est validée, rendant les modifications permanentes.

## Création de transactions en SQL
En SQL, chaque **instruction individuelle** est considérée comme une transaction.    
Cependant, nous pouvons créer manuellement des transactions qui contiennent plus d'une instruction.

Imaginons un scénario où nous avons deux tables :

- la table `BankAccounts`, qui comprend les colonnes suivantes : `account_number` (clé primaire), `account_holder` et `balance` ;


- la table `UserLogs` avec
les colonnes : `account_number`, `action`, `timestamp`, etc. La combinaison de `account_number` et `timestamp` est une clé primaire composite de cette relation.



<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Bank Database</title>
</head>
<body>
<style>
  table {
    width: 80%;
    margin: 20px auto;
    border-collapse: collapse;
    border: 1px solid #ddd;
  }
  th,
  td {
    padding: 10px;
    text-align: left;
  }
  th {
    background-color: #f2f2f2;
  }
  tr:nth-child(even) {
    background-color: #f2f2f2;
  }
  tr:hover {
    background-color: #ddd;
  }
  th strong {
    font-weight: bold;
  }
  td strong {
    font-weight: bold;
  }
</style>


<table border="1">

  <tr>
    <th>account_number</th>
    <th>account_holder</th>
    <th>balance</th>
  </tr>
  <tr>
    <td>789</td>
    <td>Alice Johnson</td>
    <td>3500.00</td>
  </tr>
  <tr>
    <td>101</td>
    <td>Bob Brown</td>
    <td>4500.00</td>
  </tr>
  <tr>
    <td>202</td>
    <td>Emily Jones</td>
    <td>6000.00</td>
  </tr>
  <tr>
    <td>303</td>
    <td>Michael Davis</td>
    <td>800.00</td>
  </tr>
  <tr>
    <td>404</td>
    <td>Sarah Wilson</td>
    <td>12000.00</td>
  </tr>
  <tr>
    <td>505</td>
    <td>David Taylor</td>
    <td>300.00</td>
  </tr>
  <tr>
    <td>606</td>
    <td>Emma Thomas</td>
    <td>7500.00</td>
  </tr>
  <tr>
    <td>707</td>
    <td>Daniel Martinez</td>
    <td>1000.00</td>
  </tr>
  <tr>
    <td>808</td>
    <td>Olivia Rodriguez</td>
    <td>900.00</td>
  </tr>
  <tr>
    <td>909</td>
    <td>Sophia Lee</td>
    <td>2500.00</td>
  </tr>
  <tr>
    <td>123</td>
    <td>John Doe</td>
    <td>5000.00</td>
  </tr>
  <tr>
    <td>456</td>
    <td>Jane Smith</td>
    <td>2000.00</td>
  </tr>
</table>

<br>


<table border="1">

  <tr>
    <th>account_number</th>
    <th>action</th>
    <th>timestamp</th>
  </tr>
  <tr>
    <td>789</td>
    <td>Account created for Alice Johnson</td>
    <td>2024-05-24 12:00:00</td>
  </tr>
  <tr>
    <td>101</td>
    <td>Account created for Bob Brown</td>
    <td>2024-05-24 12:01:00</td>
  </tr>
  <tr>
    <td>202</td>
    <td>Account created for Emily Jones</td>
    <td>2024-05-24 12:02:00</td>
  </tr>
  <tr>
    <td>303</td>
    <td>Account created for Michael Davis</td>
    <td>2024-05-24 12:03:00</td>
  </tr>
  <tr>
    <td>404</td>
    <td>Account created for Sarah Wilson</td>
    <td>2024-05-24 12:04:00</td>
  </tr>
  <tr>
    <td>505</td>
    <td>Account created for David Taylor</td>
    <td>2024-05-24 12:05:00</td>
  </tr>
  <tr>
    <td>606</td>
    <td>Account created for Emma Thomas</td>
    <td>2024-05-24 12:06:00</td>
  </tr>
  <tr>
    <td>707</td>
    <td>Account created for Daniel Martinez</td>
    <td>2024-05-24 12:07:00</td>
  </tr>
  <tr>
    <td>808</td>
    <td>Account created for Olivia Rodriguez</td>
    <td>2024-05-24 12:08:00</td>
  </tr>
  <tr>
    <td>909</td>
    <td>Account created for Sophia Lee</td>
    <td>2024-05-24 12:09:00</td>
  </tr>
  <tr>
    <td>123</td>
    <td>Account created for John Doe</td>
    <td>2024-05-24 12:10:00</td>
  </tr>
  <tr>
    <td>456</td>
    <td>Account created for Jane Smith</td>
    <td>2024-05-24 12:11:00</td>
  </tr>
</table>

</body>
</html>

Maintenant, considérons un scénario où nous avons l'intention de créer un **nouveau compte bancaire** et de générer simultanément une **entrée de journal** pour signifier l'ajout du nouveau compte.    
Il est impératif que ces deux actions, l'ajout du compte et l'enregistrement de l'événement, soient **traitées comme une seule unité logique** et doivent être enveloppées dans une seule transaction. Voici un exemple très basique de la façon dont nous pourrions faire cela avec une transaction :

```sql
-- Begin the transaction
BEGIN;

-- Insert a new bank account with account number 109, account holder Emma Watson, and initial balance of 0
INSERT INTO BankAccounts (account_number, account_holder, balance)
VALUES (109, 'Emma Watson', 0);

-- Step 2: Add log entry if the account was added
-- Insert a log entry into the UserLogs table indicating that a new account was added with account number 109
INSERT INTO UserLogs (account_number, action)
VALUES (109, 'New account added');

-- Commit the transaction, making the changes permanent
COMMIT;
```
Dans la requête ci-dessus, nous utilisons le bloc `BEGIN` pour signifier que toutes les instructions suivantes doivent être considérées comme une seule unité - si l'une d'elles n'est pas exécutée, aucune des instructions ne doit être exécutée.    
Le mot-clé `COMMIT` signifie la fin du bloc de transaction.

Que garantit le concept d'atomicité dans le contexte des transactions de base de données ?

Commencez un voyage passionnant à travers SQL avec Techniques Avancées en SQL. Apprenez les propriétés ACID importantes qui aident à maintenir l'exactitude des données dans les transactions de base de données. Découvrez des moyens avancés d'optimiser vos requêtes pour améliorer les performances de la base de données. Explorez des fonctionnalités spéciales de SQL comme les fonctions de fenêtre, les déclencheurs, le Langage de Contrôle des Données (DCL) et les bases de données NoSQL. Cela vous aidera à gérer la gestion moderne des bases de données avec confiance et efficacité.

Nous explorons maintenant les principes de base de l'ACID (Atomicité, Cohérence, Isolation, Durabilité) dans la gestion des bases de données. Apprenez comment ces principes garantissent des transactions fiables en assurant des opérations complètes, en maintenant la cohérence des données, en isolant les transactions concurrentes et en garantissant le stockage permanent des données.

Découvrez comment améliorer l'efficacité de vos requêtes SQL grâce à l'optimisation des index. Plongez dans l'importance des index dans la performance des bases de données, apprenez à les concevoir, les mettre en œuvre et les utiliser efficacement. Découvrez des stratégies pour choisir les index appropriés, comprendre leur impact sur les plans d'exécution des requêtes et optimiser la performance des requêtes grâce à la sélection et à l'utilisation des index.

Cette section explore des sujets essentiels tels que les Triggers, les Fonctions Fenêtres et le DCL (Data Control Language), offrant des aperçus complets sur leur mise en œuvre et leurs stratégies d'optimisation. De plus, elle navigue dans le paysage des SGBD NoSQL, fournissant une compréhension approfondie de son architecture, de ses avantages et de ses applications pratiques.