Précédent Remonter Suivant

Chapitre 1  SQL: langage de gestion du modèle relationnel

1.1  Intérêt de SQL

Tous les systèmes de gestion de données utilisent SQL pour l'accès aux données ou pour communiquer avec un serveur de données. SQL (Structured Query Language) est né à la suite des travaux mathématiques de Codd, travaux qui ont fondé les bases de données relationnelles. SQL, défini d'abord chez IBM au début des années 1970 a été formalisé par les standards SQL/86, SQL/89, SQL/92 et SQL/99. Toutes nos discussions seront centrés autour de SQL/92 (également appelé SQL 2)1, bien qu'il n'est pas le plus récent. En effet, SQL/99 (également appelé SQL 3) est trop récent et la mise en conformité des SGBDR actuels n'est faite que très lentement (cf. table 1.1, page ??).

Nous présentons trois raisons fondamentales qui justifient l'utilisation de SQL.
   
SQL/99 Feature Brief Description
   
SQL Data Type: String (BLOB, or Character (CLOB)) The ability to store either bit images or large character documents
SQLData Type: Boolean The ability to specify boolean data types, logic, and supporting rules
SQL Data Type: Ref Types The ability to have a DBMS generated or column value based pointer as a reference between rows of different tables.
SQL Data Type: Arrays The ability to have an ordered list of values within a column. Each value may be a RefType. Each may also be a ROW data structure
SQL Data Type: ROW Data Structures The ability to have groups of subcolumns within a column. Each may be an array or a RefType
SQL Data Type: User Defined Types The ability to completely define an non-traditional data type such as nautical distance.
Triggers The ability to specify the instigation of an action as a consequence of a state change in the database
Savepoints The ability to have cascading sets of soft commits that can be rolled back until there is a traditional hard-commit
Roles Security Enhancement The ability to define additional layers and kinds of security and the assignment of persons fulfilling the defined roles
Recursion The ability to fully model nested relationships such as hierarchies for organizations.
Information Scheman A virtual database defined as virtual tables and real SQL views on the virtual tables that contain the complete set of metadata in support of defined databases.
Call Level Interface The complete specification of a DBMS vendor independent set of database access routines similar to that contained in the Microsoft ODBC specification.
SQL Multi-Media: Full Text The complete set of data structures, special full-text operations and SQL routines that support the loading, accessing, and maintenance of full-text type of data such as books, manuscripts.
SQL Multi-Media: Spatial The complete library or set of data structures and routines that support spatial data types and operations on those data types
SQL Multi-Media: Still Image The complete library or set of data structures and routines that support still image data types and operations on those data types
SQL Programming Language A complete SQL DBMS encapsulated programming language that includes traditional assignment, looping, branching, If..Then...Else, and CASE type constructs.
Transaction, Connection, Session, and Diagnostics Management The ability to specify sessions and the management of those sessions in support of centralized or distributed type batch-type processing.
SQL/MED The routines and facilities in support of the management of types and classes of data that exists outside the domain of SQL.

Table 1.1 : Nouvelles fonctionnalités de SQL/99 (http://www.tdan.com/i016hy01.htm)

1.2  SQL dans l'architecture en couches des SGBD

Dans la phase d'analyse de systèmes d'information, on considère différents niveaux d'abstraction du système d'information : le niveau conceptuel, le niveau logique ou organisationnel et enfin, le niveau physique ou opérationnel.

Nous allons considérer ici différents niveaux de perception d'une base de données relationnelle. Un SGBD est fréquemment décrit par une structure en couches correspondant à des perceptions différentes des données, associées à des tâches différentes pour différents acteurs.

Pour plus de simplicité, nous distinguerons trois types d'acteurs : les administateurs de la base de données, les développeurs et les utilisateurs. Au niveau externe, proche de l'utilisateur, la perception est totalement indépendante du matériel et des techniques mises en oeuvre, tandis qu'au niveau le plus intérieur, se trouvent les détails de l'organisation sur disque et en mémoire.

Le schéma logique est l'ensemble de toutes les données pertinentes, toutes applications confondues. Il est rendu conforme à un modèle de représentation des données, et est totalement indépendant de la technologie utilisée. Nous choisissons le modèle relationnel. Ce niveau a un inconvénient : toutes les données sont accessibles à tout le monde. Cet ensemble vaste de données est trop touffu. Il est préférable de montrer à l'utilisateur (et au programmeur) une vue plus simple des données. On constitue ainsi des schémas externes. Par exemple, le gestionnaire du stock n'est concerné que par les données décrivant les articles en stock. S'il ne manipule que des bordereaux d'entrée, des bordereaux de sortie, et des fiches d'état du stock, ceux-ci constituent son schéma de perception externe. Le schéma interne fournit une perception plus technique des données, et enfin le schéma physique est dépendant du matériel et du logiciel de base.
Niveau externe.
Au niveau externe, les utilisateurs et développeurs d'application ont une perception limitée de la base de données. On parle de vue. Une vue peut être considérée comme une restriction du schéma logique à un type d'utilisateur. Ce niveau concerne les utilisateurs et les développeurs.
Niveau logique.
Traduction dans le modèle relationnel du schéma conceptuel. On précise à ce niveau les tables, les relations entre tables, les contraintes d'intégrité, les vues et les droits par groupe d'utilisateurs. Ce niveau concerne l'administrateur et les développeurs.
Niveau interne.
On définit les index et tous les éléments informatiques susceptibles d'optimiser les ressources et les accès aux données. Ce niveau concerne l'administrateur.
Niveau physique.
On y précise tout ce qui dépend du matériel et du système d'exploitation. Ce niveau concerne l'administrateur.
Cette découpe en niveaux présente les avantages suivants :

1.3  Structure générale du langage SQL

Les instructions essentielles SQL se répartissent en trois familles fonctionnellement distinctes et trois formes d'utilisation :

Selon la norme SQL/92, le SQL interactif permet d'exécuter une requête et d'en obtenir immédiatement une réponse. Le SQL intégré ( ou module SQL) permet d'utiliser SQL dans un langage de troisième génération (C, Cobol, ...), les instructions permettant essentiellement de gérer les curseurs. Le SQL dynamique est une extension du SQL intégré qui permet d'exécuter des requêtes SQL non connues au moment de la compilation. Hors norme, SQL est utilisable sous la forme de librairies de fonctions API (exemple : ODBC).

Dans le SQL interactif, le LDD (Langage de Définition de données) permet la description de la structure de la base (tables, vues, index, attributs, ...). Le dictionnaire contient à tout moment le descriptif complet de la structure de données. Le LMD (Langage de Manipulation de Données) permet la manipulation des tables et des vues. Le LCD (Langage de Contrôle des Données) contient les primitives de gestion des transactions et des privilèges d'accès aux données. Le tableau ci-dessous vous donne les principales primitives SQL et leur classification.
SQL interactif
LDD LMD LCD
CREATE SELECT GRANT
DROP INSERT REVOKE
ALTER DELETE CONNECT
  UPDATE COMMIT
    ROLLBACK
    SET

1
Aucun produit n'est entièrement conforme à la norme SQL/92, à cause des erreurs, omissions et incohérences de celle-ci.
Précédent Remonter Suivant