Le modèle relationnel des données produit un schéma de données relationnel qui faut écrire dans un langage compréhensible par les SGBD relationnelles. Le langage le plus utilisé est SQL : Structured Query Language (Langage de requêtes structurées) qui sert à :

➢ implémenter la base de données
➢ sécuriser la base de données
➢ manipuler les données
➢ réaliser un ensemble de requêtes en une transaction

Le langage SQL (Structured Query Language)

SQL est un langage d’interrogation structurée de données conçu dans les années 70. Il est devenu au travers de ses différentes versions, un langage complet de gestion de bases de données relationnelles. Pour gérer la base de données, SQL dispose de 4 catégories de langages.

Le Langage de Définition des Données (LDD) : Data Definition Language (DDL)

Il comporte l’ensemble des commandes SQL de gestion de la structure de chaque objet (table, vue, …) de la base de données notamment :

➢ la création (CREATE) des objets
➢ la modification (ALTER) des objets
➢ la suppression (DROP) des objets
➢ le renommage (RENAME) des objets
➢ …

Le Langage de Manipulation des Données (LMD) : Data Manipulation Language (DML)

Il comporte l’ensemble des commandes SQL réalisant les opérations suivantes sur les données :

➢ l’ajout (INSERT) des données dans une table
➢ la mise à jour (UPDATE) des données d’une table
➢ la suppression (DELETE) des données d’une table
➢ la visualisation (SELECT) des données d’une ou plusieurs tables

Le Langage de Contrôle des Données (LCD) : Data Control Language (DCL)

Il comporte l’ensemble des commandes SQL de gestion des droits d’accès aux tables et vues :

➢ l’autorisation (GRANT) d’accès
➢ l’interdiction (REVOKE) d’accès

Le Langage de Contrôle des Transactions (LCT) : Transaction Control Language (TCL)

Une transaction est un ensemble de requêtes SQL indivisible qui met à jour une base de données en garantissant sa cohérence. Elle comporte un début, une suite de requêtes SQL et une fin. Les transactions doivent respecter les principes résumés par l'acronyme ACID :

Atomicité

Une transaction doit être complètement exécutée ou totalement annulée. Dans ce sens, une transaction constitue une unité d'exécution dont les opérations doivent être annulées lorsque la transaction est interrompue. L'atomicité obéit au principe du « tout ou rien »

Cohérence

Il est possible qu'une transaction en cours d'exécution transgresse temporairement certaines contraintes de cohérence. Mais quand la transaction est terminée, le résultat final doit respecter de nouveau toutes les contraintes. Par conséquent, une transaction fait passer une base de données d'un état cohérent à un autre état cohérent et garantit l'absence de données contradictoires. La transaction représente donc une unité d'exécution qui doit maintenir la cohérence d'une base de données. La cohérence signifie l'absence de données contradictoires.

Isolation

Le principe de l'isolation exige que les modifications apportées à la base de données par les opérations d’une transaction en cours ne doivent être visibles qu’après leur validation. Ainsi, une donnée en cours de modification ne doit pas être accessible. L'isolation protège la base de données contre les effets de bord.

Durabilité

Une base de données doit être maintenue dans un état cohérent jusqu'à la validation des modifications effectuées par une transaction. Lors d'incidents (erreurs de programmation, interruptions du système ou pannes d'unités de stockage externes), la durabilité garantit que seule une transaction correctement exécutée et validée permet de valider de façon durable les modifications faites sur la base de données par les différentes opérations de la transaction.

Le principe ACID, fondamental aux SGBD garantit que chaque utilisateur transforme une base de données d'un état cohérent à un autre état cohérent. Les états intermédiaires incohérents restent invisibles depuis l'extérieur (à la transaction) et sont annulés en cas d'incident.

Une transaction n'a que deux issues possibles : le succès (COMMIT) ou l'échec (ROLLBACK). Il n'y a pas de situation intermédiaire.
Seuls les requêtes SQL qui modifient des données interviennent dans une transaction.
Une requête SELECT qui n'effectue qu'une lecture n'influe pas sur la cohérence des données.