Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

SQL DML - M. TAIS TDI 1 SQL (partie LMD) I. Introduction ......................

SQL DML - M. TAIS TDI 1 SQL (partie LMD) I. Introduction ........................................................................................................................1 Présentation générale..........................................................................................................1 II. Architecture client-serveur et communication par SQL...................................................3 Bases de données en client-serveur .......................................................................................3 Les serveurs de transactions ..................................................................................................4 III. Catégories d'instructions..................................................................................................4 IV. Interroger une base – Langage de manipulation de données (LMD) : SELECT (1 ère partie) .....................................................................................................................................6 Traduction des opérateurs de projection, sélection, produit cartésien de l'algèbre relationnelle (1 ère partie)....................................................................................................6 Syntaxe générale de la commande SELECT......................................................................6 La clause SELECT :...........................................................................................................7 La clause ORDER BY........................................................................................................8 La clause WHERE..............................................................................................................9 SQL : Sous-Interrogations (sous-requètes)..........................................................................11 V. Interroger une base – Langage de manipulation de données (LMD) : SELECT (2 ème partie) ...................................................................................................................................14 1 La clause FROM (2 ème partie) : les jointures...............................................................14 .2 Les clauses GROUP BY et HAVING et les fonctions d'agrégation...........................21 VI. Traduction des opérateurs d'union, d'intersection, de différence et de division de l'algèbre relationnelle (2 ème partie)......................................................................................23 VII -Modifier une base – Langage de manipulation de données (LMD)............................26 .1 Insertion de n-uplets : INSERT INTO ........................................................................26 .2 Modification de n-uplets : UPDATE ..........................................................................27 .3 Suppression de n-uplets : DELETE ............................................................................28 I. Introduction Présentation générale Introduction Le langage SQL (Structured Query Language) peut être considéré comme le langage d'accès normalisé aux bases de données. Il est aujourd'hui supporté par la plupart des produits commerciaux que ce soit par les systèmes de gestion de bases de données micro tel que Access ou par les produits plus professionnels tels que Oracle. Il a fait l'objet de plusieurs normes ANSI/ISO dont la plus répandue aujourd'hui est la norme SQL2 qui a été définie en 1992. Le succès du langage SQL est dû essentiellement à sa simplicité et au fait qu'il s'appuie sur le schéma conceptuel pour énoncer des requêtes en laissant le SGBD responsable de la stratégie d'exécution. Le langage SQL propose un langage de requêtes ensembliste et assertionnel. Néanmoins, le langage SQL ne possède pas la puissance d'un langage de SQL DML - M. TAIS TDI 2 programmation : entrées/sorties, instructions conditionnelles, boucles et affectations. Pour certains traitements il est donc nécessaire de coupler le langage SQL avec un langage de programmation plus complet. De manière synthétique, on peut dire que SQL est un langage relationnel, il manipule donc des tables (i.e. des relations, c'est-à-dire des ensembles) par l'intermédiaire de requêtes qui produisent également des tables. Historique rapide  En 1970, E.F. CODD, directeur de recherche du centre IBM de San José, invente le modèle relationnel qui repose sur une algèbre relationnelle. Ce modèle provoque une révolution dans l'approche des bases des données.  En 1977, création du langage SEQUEL (Structured English Query Language) et mise en place du Système R, prototype de base de données reposant sur la théorie de CODD. SEQUEL continue de s'enrichir pour devenir SQL (Structured Query Language).  En 1981, la société ORACLE CORP lance la première version de son système de gestion de base de données relationnelle (SGBDR), IBM sort SQL/DS et RTI lance INGRES.  En 1982, IBM sort SQL/DS pour son environnement VM/CMS et l'ANSI (American National Standard Institute) lance un projet de normalisation d'un langage relationnel.  En 1983, IBM lance DB2 pour l'environnement MVS.  En 1986, la société SYBASE lance son SGBDR conçu selon le modèle Client- Serveur.  La première norme SQL (SQL-1) de l'ISO (International Standard Organisation) apparaît. Il existe désormais plusieurs dizaines de produits proposant le langage SQL et tournant sur des machines allant des micros aux gros systèmes.  Depuis, les différents produits phares ont évolué, la norme SQL est passée à SQL-2, puis SQL-3. SQL est désormais un langage incontournable pour tout SGBD moderne. Par contre, bien qu'une norme existe, on assiste à une prolifération de dialectes propres à chaque produit : soit des sous-ensembles de la norme (certaines fonctionnalités n'étant pas implantées), soit des sur-ensembles (ajout de certaines fonctionnalités, propres à chaque produit). Oracle et Informix dominent le marché actuel, SQL-Server (de Microsoft) tente de s'imposer dans le monde des PC sous NT. À côté des ces produits, très chers, existent heureusement des systèmes libres et gratuits : MySQL et PostgreSQL sont les plus connus. Bien que ces SGBDR n'aient pas la puissance des produits commerciaux, certains s'en approchent de plus en plus. Les différences notables concernent principalement les SQL DML - M. TAIS TDI 3 environnements de développement qui sont de véritables ateliers logiciels sous Oracle et qui sont réduits à des interfaces de programmation C, Python, Perl sous PostgreSQL. Il en va de même pour les interfaces utilisateurs : il en existe pour PostgreSQL, mais ils n'ont certainement pas la puissance de leurs équivalents commerciaux. II. Architecture client-serveur et communication par SQL Nous allons d'abord revoir les différents types d'application possibles pour la gestion de données distantes en commençant par les trois formes les plus simples. Monoposte. La base de données se trouve sur un poste et n'est pas accessible en réseau. Il faut, dans ce cas, penser à la notion de sécurité si plusieurs utilisateurs peuvent interroger la base (suppression accidentelle d'enregistrements). Multiposte, basée sur des terminaux , liés à un site central. C'est l'informatique multiposte traditionnelle. La gestion des données est centralisée. Les applications ont été écrites par le service informatique et seules ces applications peuvent interroger le serveur. Multiposte, basée sur un serveur de fichiers. C'est la première forme (la plus simple) d'architecture client-serveur. Si l'applicatif sur un PC souhaite visualiser la liste des clients habitant Paris, tous les enregistrements du fichier CLIENT transitent sur le réseau, entre le serveur et le client, la sélection (des clients habitant Paris) est faite sur le PC. Le trafic sur le réseau est énorme et les performances se dégradent lorsque le nombre de clients augmente. Les serveurs de fichiers restent très utilisés comme serveurs d'images, de documents, d'archives. De nouveaux besoins sont apparus :  diminuer le trafic sur le réseau pour augmenter le nombre de postes sans nuire au fonctionnement,  traiter des volumes de données de plus en plus grand,  accéder de façon transparente à des données situées sur des serveurs différents,  accéder aux données de façon ensembliste, même si les données sont distantes, afin de diminuer le travail du programmeur,  adopter des interfaces graphiques de type Windows pour les applicatifs clients. Bases de données en client-serveur Dans une architecture client-serveur, un applicatif est constitué de trois parties : l'interface utilisateur, la logique des traitements et la gestion des données. Le client n'exécute que l'interface utilisateur et la logique des traitements, laissant au serveur de bases de données la gestion complète des manipulations de données.  Le serveur de bases de données fournit des services aux processus clients. Les tâches qu'il doit prendre en compte sont : la gestion d'une mémoire cache, l'exécution de requêtes exprimées en SQL, exécuter des requêtes mémorisées, la gestion des transactions, la sécurité des données. SQL DML - M. TAIS TDI 4  Le client doit ouvrir une connexion pour pouvoir profiter des services du serveur. Il peut ouvrir plusieurs connexions simultanées sur plusieurs serveurs. Le client peut soumettre plusieurs requêtes simultanément au serveur et traiter les résultats de façon asynchrone.  Communication entre le client et le serveur. Puisque l'application doit pouvoir se connecter à divers serveurs de façon transparente, le langage de communication SQL doit être compatible avec la syntaxe SQL de chaque serveur pressenti. Or, malgré les normes, les dialectes SQL sont nombreux et parfois source d'incompatibilité. La seule façon de permettre une communication plus large est d'adopter un langage SQL standardisé de communication. Une couche fonctionnelle du client traduit les requêtes du dialecte SQL client en SQL normalisé. La requête transformée est envoyée au serveur. Celui-ci traduit la requête dans le dialecte SQL-serveur et l'exécute. Le résultat de la requête suit le chemin inverse. Le langage de communication normalisé le plus fréquent est l'ODBC (Open DataBase Connectivity) de Microsoft. Signalons également IDAPI (Integrated Database Application Programming Interface) de Borland. De plus, ces programmes permettent d'interroger des bases de données autres que relationnelles. Les serveurs de transactions Une transaction correspond à une procédure SQL, i.e. un groupe d'instructions SQL. Il y a un seul échange requête/réponse pour la transaction. Le succès ou l'échec concerne l'ensemble des instructions SQL. Ces serveurs sont essentiellement utilisés pour l'informatique de production (ou opérationnelle) pour laquelle la rapidité des temps de réponse est importante sinon essentielle. III. Catégories d'instructions Les instructions SQL sont regroupées en catégories en fonction de leur utilité et des entités manipulées. Nous pouvons distinguer cinq catégories, qui permettent : 1. la définition des éléments d'une base de données (tables, colonnes, clefs, index, contraintes, ...), 2. la manipulation des données (insertion, suppression, modification, extraction, ...), 3. la gestion des droits d'accès aux données (acquisition et révocation des droits), 4. la gestion des transactions, 5. et enfin le SQL intégré. Langage de définition de données Le langage de définition de données (LDD, ou Data Definition Language, soit DDL en anglais) est un langage orienté au niveau de la structure de la base de données. Le LDD permet de créer, modifier, supprimer des objets. Il permet également de définir uploads/Management/ cours-sql-dml.pdf