Commandes SQL

Le Struc­tu­red Query Language, re­pré­senté par l’abré­via­tion SQL, compte parmi les langages de pro­gram­ma­tion les plus connus. Il fait office d’interface uni­ver­selle per­met­tant le travail avec des données re­la­tion­nelles ou des systèmes de gestion de base de données re­la­tion­nelle (SGBDR). Ce langage est ca­rac­té­risé par un nombre dé­con­cer­tant de commandes SQL. Nous allons vous présenter les plus im­por­tantes, ainsi que leurs modèles sous-jacents.

Les commandes SQL per­met­tent d’ordonner à un système de gestion de base de données (SGBD) d’exécuter certaines tâches. Il peut notamment s’agir de définir des tables et leur structure, d’insérer, de modifier ou de supprimer des données et d’effectuer des requêtes.

Dif­fé­rentes normes ISO ou ANSI encadrent la portée des commandes SQL. De plus, il existe plusieurs dialectes spé­ci­fiques à l’im­plé­men­ta­tion. De cette manière, les im­plé­men­ta­tions des prin­ci­paux four­nis­seurs tels que Post­greSQL, MySQL, Oracle DBMS et Microsoft SQL Server disposent toutes de leur propre variante pour ce langage. Certains four­nis­seurs possèdent leurs propres commandes ; la plupart du temps, leurs dif­fé­rences con­cer­nent surtout les fonctions liées au trai­te­ment des chaînes de ca­rac­tères et d’autres données.

En réalité, SQL est composé de plusieurs sous-langages, chacun d’eux portant sur un domaine différent et bé­né­fi­ciant de ses propres commandes. Découvrez avec nous les prin­ci­paux types de commandes SQL.

De façon ap­proxi­ma­tive, il est possible de répartir les commandes SQL les plus im­por­tantes en cinq sous-langages. Voici, pour chaque sous-langage, un aperçu de son domaine d’uti­li­sa­tion et de ses commandes :

SQL est un langage dé­cla­ra­tif, ce qui le distingue de la plupart des autres langages de pro­gram­ma­tion po­pu­laires. En d’autres termes, il décrit le résultat à atteindre sans pour autant préciser les étapes exactes qu’il convient de suivre pour arriver à cet objectif. Cette par­ti­cu­la­rité donne un langage avec des commandes qui sont souvent plus longues, mais qui nécessite gé­né­ra­le­ment moins de lignes de code que les langages im­pé­ra­tifs, plus con­ven­tion­nels.

À titre d’exemple, in­té­res­sons-nous à la commande SQL « DROP TABLE IF EXISTS ». Comme vous l’avez sans doute compris, cette commande unique permet de supprimer une table si celle-ci existe déjà :

Pour créer un exemple de code aux fonctions si­mi­laires avec Python, il est né­ces­saire d’appeler plusieurs d’entre elles, avec une ra­mi­fi­ca­tion sur deux lignes dif­fé­rentes :

Comme vous avez pu le constater, une seule commande SQL peut contenir plusieurs mots-clés. Ainsi; les dif­fé­rentes commandes se res­semblent sur le plan visuel. Prenons par exemple les deux commandes SQL « CREATE TABLE » et « CREATE OR REPLACE VIEW » ; si, de prime abord, elles semblent toutes deux être des ex­pres­sions d’une commande « CREATE » sous-jacente, il n’en est rien. Ces commandes se res­semblent, mais elles sont to­ta­le­ment in­dé­pen­dantes l’une de l’autre.

Comme c’est également le cas d’autres langages, certaines commandes SQL peuvent prendre en charge des pa­ra­mètres. La plupart du temps, il s’agit de noms de bases de données, de tables ou de colonnes. Ici, nous pouvons par exemple in­ter­ro­ger les colonnes « Name » (nom) et « Age » (âge) de la table « People » (personnes) :

En réalité, les commandes SQL cor­res­pon­dent plutôt à des ins­truc­tions. Il existe d’autres cons­truc­tions syn­taxiques qui, dans une certaine mesure, agissent également comme des commandes. Voici une pré­sen­ta­tion des prin­ci­paux éléments syn­taxiques du langage SQL :

Une base de données structure ses données de manière hié­rar­chique à l’aide de dif­fé­rentes couches de mémoire, qui vont du serveur de la base de données jusqu’à la valeur en­re­gis­trée dans un champ. Étant donné que SQL est en mesure de contrôler tous les aspects d’un système de gestion de base de données re­la­tion­nelle (SGBDR), des commandes SQL existent pour chacune des couches sus­men­tion­nées. Voici un aperçu de la hié­rar­chie des dif­fé­rents objets d’un système de gestion de base de données re­la­tion­nelle :

En plus des prin­ci­paux objets des systèmes de gestion de base de données re­la­tion­nelle présentés ci-dessus, il est également possible d’utiliser d’autres objets tels que les vues (Views) et les pro­cé­dures stockées (Stored Pro­ce­dures). Des commandes SQL propres à chacun de ces objets existent également. Dé­cou­vrons à présent les commandes relatives aux cinq sous-langages prin­ci­paux de SQL :

1. Data De­fi­ni­tion Language (DDL) : langage de dé­fi­ni­tion des données
2. Data Ma­ni­pu­la­tion Language (DML) : langage de ma­ni­pu­la­tion des données
3. Data Query Language (DQL) : langage d’in­ter­ro­ga­tion des données
4. Data Control Language (DCL) : langage de contrôle des données
5. Tran­sac­tion Control Language (TCL) : langage de contrôle des tran­sac­tions

Avec ces commandes SQL, vous pouvez définir des struc­tures de données. Toutes ces commandes agissent sur des objets agrégés, comme les bases de données, les tables ou encore les index. Un objet agrégé peut stocker plusieurs ensembles de données ; un ensemble de données va quant à lui contenir plusieurs champs, chacun de ces champs étant associé à une colonne. La colonne permet de définir le type de données contenu par le champ (un nombre, une chaîne de ca­rac­tères, une valeur booléenne…). Il est de plus possible de spécifier des res­tric­tions pour les valeurs de ces colonnes : « doit être unique », « ne peut pas être nulle », etc.

Les bases de données sont toujours au sommet des systèmes de gestion de base de données re­la­tion­nelle (SGBDR). Des commandes SQL per­met­tent de créer ou encore de supprimer celles-ci :

Pour créer une base de données, il faut d’abord définir son schéma. Celui-ci est essentiel si vous voulez utiliser ef­fi­ca­ce­ment votre base de données. Il nécessite une con­cep­tion des plus mé­ti­cu­leuses et une re­pré­sen­ta­tion des dif­fé­rentes tables et de leurs as­so­cia­tions. En règle générale, le schéma d’une base de données se développe à partir de dia­grammes entité-as­so­cia­tion ou de dia­grammes UML spé­ci­fiques.

Le schéma de la base de données prend donc la forme d’une des­crip­tion abstraite, tandis que sa structure se crée en utilisant les commandes SQL cor­res­pon­dantes. La dé­fi­ni­tion des tables s’effectue avec leurs colonnes et leurs types, et les éventuels liens entre celles-ci sont ma­té­ria­li­sés par des Foreign Keys (c’est-à-dire des « clés étran­gères »). Vous avez toujours la pos­si­bi­lité de modifier cette structure par la suite, à l’aide d’autres commandes SQL. Découvrez avec nous les prin­ci­pales commandes que vous pouvez utiliser :

L’une des pro­prié­tés im­por­tantes des systèmes de gestion de base de données (SGBD) consiste à garantir la cohérence des données. Vous pouvez donc décider que les champs de certaines colonnes ne doivent pas être vides ou que les valeurs contenues par ceux-ci doivent rester dans les limites au­to­ri­sées. Il s’agit là de Cons­traints (con­traintes). De la même manière, les Foreign Keys (ou clés étran­gères) per­met­tent d’exiger l’éta­blis­se­ment de liens corrects entre plusieurs tables.

Il suffit d’utiliser une série de clauses dans les ins­truc­tions relatives à la dé­fi­ni­tion des données pour spécifier les con­traintes ap­pli­cables aux dif­fé­rentes colonnes. Voici quelques-unes de ces con­traintes (sans exemple) :

Si les tables de votre base de données sont déjà définies, vous devez vous occuper des opé­ra­tions sur les dif­fé­rents ensembles de données. En utilisant les commandes SQL ap­pro­priées, vous pouvez insérer, modifier et supprimer des ensembles de données. Dans ce contexte, il est également question des opé­ra­tions CRUD de base (Create, Read, Update, Delete, soit « Créer, lire, mettre à jour et supprimer »), qui se re­trou­vent également dans les bases de données NoSQL :

Attention : les clauses ou les fonctions « WHERE », « SET » et « VALUES » que vous voyez dans les exemples ci-dessus peuvent également ap­pa­raître dans d’autres si­tua­tions. Elles portent toujours le même nom, mais les règles encadrant leur uti­li­sa­tion peuvent toutefois lé­gè­re­ment différer. Nous vous con­seil­lons donc de faire preuve de prudence lorsque vous utilisez les commandes SQL « UPDATE » et « DELETE FROM » sans la clause « WHERE ». Si vous le faites, sachez que tous les ensembles de données contenus dans la table concernée seront modifiés ou supprimés.

La commande « SELECT » est peut-être la plus connue parmi toutes celles que compte le langage SQL. Elle vous permet en effet d’in­ter­ro­ger les données d’une base de données. En règle générale, cela n’a pas pour effet de modifier la base de données. Il n’est donc pas rare que la commande « SELECT » soit mise à la dis­po­si­tion des analystes. Dé­cou­vrons ensemble les prin­ci­paux com­po­sants de la commande SQL « SELECT » :

La commande SQL « SELECT » est la seule qui permet d’in­ter­ro­ger des données, mais ses pos­si­bi­li­tés d’uti­li­sa­tion sont nom­breuses. Il existe en effet une série de clauses pouvant vous aider à filtrer, trier et regrouper les données générées ; découvrez-les ci-après.

La commande SQL « SELECT » renvoie in­va­ria­ble­ment un Result Set, ou « jeu de résultats ». D’un point de vue con­cep­tuel, un jeu de résultats peut être re­pré­senté comme une table avec des colonnes contenant des valeurs. D’un point de vue pratique, il est souvent né­ces­saire de filtrer ces résultats, de les trier ou encore de limiter le nombre d’ensembles de données générés. Pour chaque cas d’uti­li­sa­tion, il existe une clause que vous pouvez utiliser dans le cadre de votre commande SQL « SELECT » :

En plus d’améliorer votre jeu de résultats, vous pouvez également combiner des requêtes sur plusieurs tables. À titre de rappel, une commande SQL « SELECT » renvoie un jeu de résultats. Certaines commandes SQL peuvent donc, con­for­mé­ment aux règles de la théorie des ensembles re­la­tion­nels, vous permettre de fusionner deux jeux de résultats.

Pour vous expliquer dans le détail le fonc­tion­ne­ment des commandes SQL per­met­tant d’associer des requêtes, nous devrions faire appel à des exemples plus complexes, avec la dé­fi­ni­tion de plusieurs tables. Ici, nous avons donc choisi de ne vous présenter aucun exemple de code. Dé­cou­vrons ensemble les prin­ci­pales opé­ra­tions que vous pouvez utiliser dans ce contexte :

Comme nous avons pu le voir, les requêtes SQL peuvent s’avérer assez complexes dans certaines cir­cons­tances. Dans les faits, il est souvent judicieux de répéter ces requêtes. En principe, il est possible de sau­ve­gar­der les commandes SQL con­cer­nées sous forme de code, puis de s’en servir en cas de besoin. Cette méthode n’est toutefois pas très efficace. Fort heu­reu­se­ment, des commandes SQL spéciales per­met­tent de sau­ve­gar­der des requêtes complexes di­rec­te­ment dans le système de gestion de base de données concerné, et ce, en tant qu’entités.

Pour commencer, in­té­res­sons-nous aux vues (Views en anglais). Une vue de la base de données cor­res­pond ap­proxi­ma­ti­ve­ment à une requête en­re­gis­trée. À titre de rappel, une requête renvoie un jeu de résultats présenté sous la forme d’une table. Au lieu d’ignorer ce jeu, nous choi­sis­sons de l’en­re­gis­trer en tant que vue. Le terme de « table virtuelle » est donc également utilisé pour désigner une vue. De manière générale, il n’est possible d’accéder à une vue qu’en mode lecture. Quelques commandes SQL peuvent vous permettre de tra­vail­ler avec les vues :

En plus des vues de la base de données, vous pouvez tirer parti des « pro­cé­dures stockées » (Stored Pro­ce­dures en anglais). Les pro­cé­dures stockées vous per­met­tent de répéter certaines requêtes et sont donc plus complexes que les vues. Elles peuvent prendre en charge des pa­ra­mètres, et ainsi assembler des requêtes de façon dynamique. Une procédure stockée peut en outre vous permettre de bé­né­fi­cier d’un accès en écriture aux données sous-jacentes. Nous vous pré­sen­tons ci-dessous les commandes SQL cor­res­pon­dantes, mais nous ne disposons pas d’assez de place pour vous proposer des exemples :

En utilisant une procédure stockée, vous déplacez le code du client vers le serveur. Une fois cette sé­pa­ra­tion effectuée, vous bé­né­fi­ciez d’une plus grande sécurité et de meil­leures per­for­mances. Si la « logique métier » contenue dans une procédure stockée se trouve en dehors du système de contrôle de version, cela peut vous être dom­ma­geable. Comme les pro­cé­dures stockées sont largement tri­bu­taires du système de gestion de base de données qui les entourent, un chan­ge­ment de four­nis­seur peut, dans le pire des scénarios, entraîner une perte de fonc­tion­na­lité.

Un seul serveur de bases de données peut renfermer plusieurs bases de données. Si vous souhaitez les ad­mi­nis­trer in­dé­pen­dam­ment les unes des autres, vous pouvez mettre en place des mé­ca­nismes de contrôle des accès. Vous avec donc la pos­si­bi­lité de définir le niveau des droits d’accès de chaque uti­li­sa­teur aux bases de données et aux tables que celles-ci con­tien­nent. Vous pouvez en outre créer des groupes dans lesquels vous pouvez ca­té­go­ri­ser vos uti­li­sa­teurs. Pour ce faire, deux commandes SQL sont par­ti­cu­liè­re­ment adaptées :

Les garanties apportées par les pro­prié­tés ACID cons­ti­tuent l’un des avantages de l’uti­li­sa­tion des systèmes de gestion de base de données re­la­tion­nelles (SGBDR). Pour faire court, elles ga­ran­tis­sent la bonne or­ga­ni­sa­tion et la bonne dé­fi­ni­tion de vos données. Sur le plan technique, elles utilisent des tran­sac­tions in­di­vi­sibles sous la forme d’Atomic Ope­ra­tions (« opé­ra­tions atomiques »). Soit la tran­sac­tion est exécutée en­tiè­re­ment et sans aucune erreur, soit une erreur se produit et les dif­fé­rentes étapes sont alors annulées. Dé­cou­vrons ensemble les commandes SQL pour le contrôle des tran­sac­tions :

Pré­sen­ta­tion des pro­prié­tés ACID men­tion­nées ci-avant :