Abstractions, DDL, DML et SQL

Le SGBDR sert à nous abstraire une grande partie de la gestion de nos données.

Quand on accède ou modifie nos données, on aimerait pouvoir préciser le résultat souhaité sans s'occuper des détails de l'implémentation (comment faire).

Dans la vraie vie, quand on demande à quelqu'un de "préparer un gâteau au chocolat", nous le faisons de façon déclarative, c'est-à-dire, on a exprimé notre résultat désiré : le gâteau au chocolat.

Nous n'avons pas précisé comment préparer le gâteau, ni les étapes nécessaires pour le produire. Si on avait énuméré la recette, étape par étape, on l'aurait fait de manière impérative.

Notre SGDBR aura les prétentions vers le régime déclaratif, et pour la plupart, on préfère exprimer nous besoins finaux, au lieu des détails d’exécution (il y aura, comme toujours, des exceptions !)

Pour satisfaire cette demande déclarative, le SGBDR est obligé de nous abstraire certaines parties de son implémentation. Par exemple, l'accès aux disques, y compris le format des fichiers qui stockent nos données, est totalement abstrait du point de vue de l'utilisateur du SGBDR.

Nous intervenons principalement sur le niveau logique en tant de concepteur, développeur ou opérateur d'un SGBDR. Avec le langage SQL, nous exprimons nos souhaits, sans s'occuper de l'accès physique aux données sur le disque.

Ceci nous donne de l'indépendance au stockage, ou Physical Data Independance.

Notre SGBDR nous abstrait donc beaucoup de détails d'implémentation. En revanche, parfois, on se trouve dans la situation où l'on ne récupère pas forcément les données que l'on veut (nous nous exprimons mal nos besoins), ou la récupération prend trop de temps (la stratégie trouvée par le SGBDR pour satisfaire nos besoins n'est pas optimale), ou on essaye d'effectuer une opération qui met en péril la cohérence de nos données.

Pour s'en sortir, il est utile donc d'apprécier les différents niveaux d'abstraction, et penser à l'implémentation de chaque couche. De temps en temps, cette connaissance nous aide à débloquer un problème.

Par exemple, j'ai une requête SQL qui prend trop de temps. En étudiant le schéma dessus, je vois qu'il peut y avoir plusieurs endroits d'amélioration de ma requête :

• Peut-être le compilateur DML a pris trop de temps pour parser la requête et formuler une stratégie de récupération des données ?

• Peut-être j'ai demandé trop de données pour la RAM disponible sur la machine, et donc je suis rentré dans un état de pagination et thrashing__

• Peut-être ma demande se repose sur les colonnes non indexés ? Peut-être le disque même est de mauvaise performance ?

DDL : Data Definition Language

Nous distinguons entre les instructions de création de notre base de données, notamment en ce qui concerne le schéma de notre base, et les instructions d'accès et manipulation aux données.

Les instructions de création et modification d'un schéma composent le DDL, le data definition language.

A priori, le DDL est plutôt impératif dans sa nature, puisqu'on précise, dans un ordre spécifique, comment mettre en place la structure de notre base. En même temps, nous ne nous occupons pas des détails de l'implémentation au niveau stockage, donc à un autre niveau, le DDL est quand même déclaratif.

Le DDL s'occupe des sujets suivants :

• Préciser les relations (tables et colonnes)

• Préciser le type de données

• Préciser les contraintes sur les données pour avoir du sens

• Conditions d'intégrité référentielle

• Autorisation

On parle souvent d'un DDL pour le fichier contenant toutes les instructions pour créer une base de données. Normalement ce fichier contient les instructions SQL comme create table, alter table, drop table, etc.

DML : Data Manipulation Language

Ou bien query language. L'objectif est de faciliter l’accès aux données sans forcément préciser où ni comment.

Le DML consiste à des instructions select, insert, update, delete

SQL : Structured Query Language

SQL est le langage le plus globalement supporté pour la manipulation des données relationnelles. Ce langage avait pour ambition de pouvoir exprimer nos besoins de façon presque "naturelle".

Il est à la fois DDL, à la fois DML.;

En revanche, certaines marques de base de données se différencient dans les détails (notamment dans la partie DDL). Ex. MySQL vs Postgres SQL vs MariaDB vs Oracle etc.