2 MicroSql

Cours de langage SQL/921
Claude Belleil
Université de Nantes
1. Présentation générale 2
1.1. Introduction
SQL (Stuctured Query Language) est né à la suite des travaux mathématiques de

Codd, travaux qui ont fondé les bases de données relationnelles. Défini d'abord
chez IBM, SQL a subi trois tentatives de normalisation en 86, 89 et 92 (SQL 2 ou
SQL 92). Il existe au moins trois raisons fondamentales qui justifient l'utilisation de
SQL.
1 - La structuration et la manipulation des données sont devenues très complexes.

Pour une application de taille moyenne, la base de données contient fréquemment
plus de trente tables fortement interconnectées. Il est donc hors de question de
manipuler les données de façon algorithmique traditionnelle. Une requête SQL dans
un langage logique simple remplace plusieurs dizaines de lignes d'un langage de
programmation procédurale tel que C ou Cobol.
2 - Les architectures « client-serveur » sont aujourd’hui très répandues.. Tandis que
la station client exécute le code de l'application en gérant, en particulier, l'interface
graphique, le serveur optimise la manipulation et le contrôle des données. De plus,
les applications doivent être portables et gérer des données virtuelles, c'est-à-dire
émanant de n'importe quel serveur. Développer une application dans un
environnement hétérogène n'est possible que parce que la communication entre
l'applicatif client et le serveur est réalisée par des primitives SQL normalisées.
3 - Les applications à développer (même sur un PC) sont devenues de plus en plus
complexes. Le profil du programmeur a fortement changé. Il doit maintenant traiter
des données de plus en plus volumineuses, intégrer les techniques de manipulation
des interfaces, maîtriser la logique événementielle et la programmation orientée
1
Cours réalisé avec MicroSQL de MicroResearch PO Box 6104 Mitchelton Qld 4053 Australia
2
D'après Rémi Gilleron et Marc Tommasi
Introduction à SQL/92 - Université de Nantes - Claude Belleil 1
objet, tout cela dans un contexte d'architecture client-serveur où se côtoient les
systèmes d'exploitation et les protocoles de réseaux hétérogènes. L'accès et la
manipulation des données ne sont que l'un des aspects de la conception et de la
réalisation de programmes. On cherche donc à acquérir un environnement de
développement performant qui prend en charge un grand nombre de tâches
annexes. Des outils de développement sont apparus pour permettre au développeur
de se concentrer sur l'application proprement dite : générateurs d'écrans, de
rapports, de requêtes, d'aide à la conception de programme, de connexion à des
bases de données distantes via des réseaux. Dans tous ces outils, la simplicité et la
standardisation de ce langage de requêtes font que SQL est utilisé chaque fois
qu'une définition, une manipulation, ou un contrôle de données est nécessaire. SQL
est donc un élément central entre les divers composants d'un environnement de
développement dans une architecture client-serveur.
1.2. SQL dans l'architecture en couches des SGBD.
Dans la phase d'analyse des systèmes d'information, on considère différents

niveaux d'abstraction (voir le cours sur Merise) : le niveau conceptuel, le niveau
logique ou organisationnel et enfin, le niveau physique ou opérationnel.
On peut donc considérer 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é, on distingue trois types d'acteurs : les administrateurs de la

base de donnée, 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 œuvre, 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, 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.
1.2.1. 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.
1.2.2. 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.
1.2.3. 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.
1.2.4. 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 :
Les applications développées sont indépendantes du niveau interne. Tout

changement de stratégie d'accès, ou d'organisation des données entraîne une
modification au niveau interne, mais le schéma logique reste inchangé. Une requête
SQL précise le QUOI sans se préoccuper du COMMENT.
La distinction externe/logique assure (en partie) l'indépendance entre les

applications et le niveau logique. On peut enrichir le schéma logique sans modifier
les applications existantes pour toutes les vues non concernées par les
modifications apportées au schéma logique.
La distinction logique/interne permet de modifier les optimisations d'accès aux

données. Par exemple, si une application a des performances insuffisantes, il est
possible d'optimiser les accès (en introduisant de nouveaux index) et d'augmenter
les performances sans modifier l'application. La distinction interne/physique permet
une meilleure portabilité car seule la partie physique est dépendante du matériel et
du système d'exploitation.
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). Nous nous limitons au SQL
interactif.
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.
1.4. Principes de base d'une Base de Données relationnelle
Le terme relationnel provient de la définition mathématique d'algèbre relationnelle

(Codd 70). Une relation est un ensemble de tuples de données, on peut alors définir
des opérations algébriques sur les relations. Une table est un ensemble de tuples
de données distincts deux à deux. Elle est constituée d'une clé primaire et de
plusieurs attributs (ou colonnes) qui dépendent de cette clé. La clé primaire d'une
table est un attribut ou un groupe d'attributs de la table qui détermine tous les autres
de façon unique. Une table possède toujours une et une seule clé primaire. Par
contre, une table peut présenter plusieurs clés candidates qui pourraient jouer ce
rôle. Le domaine d'un attribut est l'ensemble des valeurs que peut prendre cet
attribut. Le domaine est constitué d'un type, d'une longueur et de contraintes qui
réduisent l'ensemble des valeurs permises. Une clé étrangère dans une table est
une clé primaire ou candidate dans une autre table. Les contraintes d'intégrité font
partie du schéma logique. Parmi celles-ci, on distingue
1 - les contraintes de domaine qui restreignent l'ensemble des valeurs que peut
prendre un attribut dans une table,
2 - les contraintes d'intégrité d'entité qui précisent qu'une table doit toujours avoir
une clé primaire
3 - les contraintes d'intégrité référentielles qui précisent les conditions dans
lesquelles peuvent être ajoutés ou supprimés des enregistrements lorsqu'il existe
des associations entre tables par l'intermédiaire de clés étrangères.
Une table (relation) est un ensemble de tuples. On peut donc appliquer à une table
les opérateurs algébriques usuels. Le résultat d'une opération ou requête est une
nouvelle table qui est exploitable à son tour dans une nouvelle opération. Tous les
opérateurs peuvent être dérivés de cinq primitives de base : la PROJECTION, la
SELECTION, l'UNION, la DIFFERENCE et le PRODUIT. L'opérateur de JOINTURE
qui peut être déduit des cinq primitives de base est cependant fondamental.

2. Présentation de MicroSQL (MicroResearch)
2.1. Préambule
Une base de données est un ensemble de données organisées. Les bases de

données peuvent être de plusieurs types, depuis le simple ensemble de fiches
cartonnées jusqu'à des systèmes informatiques contenant des quantités très
importantes d'informations. D'une façon plus spécifique, les bases de données
auxquelles nous nous intéressons ici sont des bases de données relationnelles
crées et maintenues dans un environnement d'ordinateur individuel (compatible IBM
PC). Les caractéristiques essentielles d'une base de donnée relationnelle sont:
1 - toutes les données apparaissent à l'utilisateur comme étant rangées dans

des tables.
2 - le langage de requête utilisé dans les opérations de gestion de la base
opère sur les tables de données de la base et génère des résultats sous forme de
nouvelles tables.
De plus, pour qu'une base de données soit décrite de façon totalement relationnelle,
l'intégrité des données stockées doit toujours être protégée contre des actions
indésirables de l'utilisateur. Cela est réalisé en définissant des contraintes
auxquelles de nouvelles données sont confrontées avant d'être acceptées dans le
système d'information. SQL permet l'implantation de tels schémas de protection.
2.1.1. Les valeurs NULL
Dans une table, un point d'interrogation (ou un tiret) à la place d'une information
indique la présence d'une valeur NULL. Attention au contresens possible. En
SQL, NULL signifie soit que la valeur n'existe pas, soit qu'elle est inconnue, mais en
aucune façon qu’elle est égale à zéro !
2.1.2. Types de données
SQL supporte de nombreux types de données, mais à ce stade, nous considérerons

qu'il n'y a que deux types de base:
le type caractère
le type numérique décimal
Le type de données qui peut être stocké dans la colonne d'une table est déterminé
au moment de la création de la table. Les noms et le texte en général doivent
toujours être rangés dans des colonnes définies comme ayant le type caractère
(n'importe quelle combinaison de lettres, chiffres ou caractères spéciaux
apparaissant sur la clavier d'un ordinateur personnel). Les valeurs numériques sont
habituellement rangées dans des colonnes ayant été définies comme de type
décimal (tout nombre valide de type entier ou réel).

En tant qu'utilisateur d'un système de base de données relationnelle, nous ne
sommes pas concernés par la façon dont les données sont physiquement
implantées. Elles apparaissent toujours et se comportent vis à vis de l'utilisateur
comme étant organisées sous forme de tables.
2.1.3. Clés des tables
Chaque table doit disposer d'une clé primaire qui consiste en une colonne ou une
combinaison de colonnes dans lesquelles chaque valeur identifie de façon unique
une ligne de la table.
2.1.4. Identificateurs en MicroSQL
Les identificateurs sont utilisés comme noms de tables ou de colonnes. Ils peuvent
comporter un maximum de 20 caractères comprenant lettres (a-z, A-Z), chiffres (0-9)
ou les caractères suivants : _@#$. le premier caractère ne peut être ni un tiret bas
(_), ni un chiffre. Un nom de base de données obéit aux même règles mais est limité
à une longueur de 8 caractères. Il est recommandé de choisir des noms de bases de
données, de tables et de colonnes qui correspondent aux informations stockées.
Les tables de la bases de données Ventes qui servira d'exemple tout au long
de ce cours ont les noms suivants:
cli (clients)
anc_cli (anciens clients)
emp (employés)
prod (produits)
succ (succursales)
fabric (fabrications)
ventes (ventes)
2.1.5. Langages de requêtes
Les systèmes de gestion de bases de données ont des langages spécifiques qui
facilitent l'accès et le contrôle des informations stockées. SQL (Structured Query
Language) a été développé à l'origine par IBM pour l'utilisation des systèmes de
bases de données relationnelles. Ce langage a été normalisé sur le plan
international. MicroSQL correspond à la norme du SQL/2 qui date de 1992. Il
possède la plupart des caractéristiques de cette norme pour ce qui concerne le SQL
direct (interactif):
- définition des structures de base de données

- insertion, destruction et modification des données
- recherche et extraction des données stockées avec production de rapports
- implémentation des contraintes d'intégrité
- contrôles d'accès aux données

MicroSQL est une implémentation du SQL/2 destiné à une utilisation individuelle sur
compatible PC.
2.2. Introduction à MicroSQL
2.2.1. L'écran de travail
L'interface MicroSQL est constitué des éléments suivants: une barre de menus en
haut de la fenêtre et une ligne de statut en bas. Immédiatement sous la barre des
menus se trouve une barre des outils qui fournit des accès rapides aux commandes
les plus souvent utilisées. Cette fenêtre principale peut recevoir de nombreuses
autres fenêtres qui peuvent être déplacées ou redimensionnées à volonté. Elle
permet également l'affichage de menus déroulants et de nombreuses boites de
dialogue. Tous cela peut être mis en œuvre soit avec le clavier, soit avec la souris.
Une aide contextuelle est également disponible sur chacun des éléments des menus
déroulants en appuyant sur F1. On accède au système d'aide général en cliquant
sur la commande Help de la barre des menus.
La barre des menus contient les éléments suivants: File, Edit, Table,
Structure, Command, Display, Procedure, Window and Help. Les informations
apparaissant sur la ligne statut comprennent des aides rapides, des messages
d'avertissement ou des informations sur l'état du système.
Le menu est activé en pressant sur F10 ou en cliquant sur une commande. Pour
désactivé le menu taper sur ESC ou sur F10 ou cliquer sur n'importe quelle zone de
la fenêtre principale. Chaque commande du menu possède une touche rapide qui
est indiquée par un caractère souligné. Une commande particulière du menu peut
donc être sélectionnée de différentes façons:
Quand le menu est actif:
en appuyant sur la touche rapide (raccourci)

en se déplaçant dans les menus déroulants avec les flèches
Quand le menu n'est pas actif:
en appuyant sur la touche ALT et sur la touche rapide de la commande

en cliquant sur la commande à l'aide de la souris.
2.2.1.1. FILE MENU ALT F
Ces commandes couvrent un ensemble d'opérations fondamentales telles que le

choix d'un chemin pour l'accès à une base de données ainsi que le chargement de
cette base.
2.2.1.1.1. Load Ctrl+L

Les tables de la base de données spécifiée sont rendues accessibles au système
SQL. La base de données est choisie à partir de la liste de celles qui ont été
définies dans le dictionnaire actif. Un fois chargée, son nom est affiché à droite de la
ligne de statut : current database : xxx.
2.2.1.1.2. Set
Les options disponibles donnent accès aux variables d'environnement. Les valeurs
peuvent être changées pour une session SQL à l'aide de boutons radios.
2.2.1.1.3. Save options
Les options sélectionnées par la commande Set sont sauvegardées sur le disque. Ils
seront restaurés lors de la prochaine session SQL.
2.2.1.1.4. Commit
Les changements réalisés dans les tables sont rendus permanents. Avant que ces
changements ne soient rendus permanents, la base de données peut être
restaurées dans l'état où elle se trouvait au moment de son chargement ou depuis la
dernière commande commit.
2.2.1.1.5. Rollback
Tous les changements réalisés dans les tables depuis la dernière commande
commit ou depuis le chargement de la base sont annulés.
2.2.1.1.6. Form Ctrl+F
Le sous système Form (écrans de saisies et de mises à jour des tables) est activé.
2.2.1.1.7. Erase
Le fichier de commande, requête ou procédure ainsi choisi est supprimé du disque.
2.2.1.1.8. Organise
Les tables de la base de données active sont triées sur la première de leur colonne
contenant la clé primaire ou sur un autre ensemble de colonnes spécifiées.

2.2.1.1.9. Print Ctrl+P
Une table résultat, le texte d'une commande ou d'une requête est envoyé vers
l'imprimante.
2.2.1.1.10. Exit Alt+F4
La session courante est arrêtée. Si des changements ont été réalisés dans les
tables et que la commande commit n'a pas été invoquée, un avertissement est
affiché avant que la session ne soit fermée.
2.2.1.2. EDIT MENU Alt+E
Les commandes de ce menu facilitent les opérations sur le presse-papier et

permettent à la dernière action d'édition d'être annulée.
2.2.1.2.1. Undo Alt+Backspace
La dernière opération d'édition est annulée et le texte est restauré dans son état
précédent.
2.2.1.2.2. Cut Shift+Delete
Le texte sélectionné est supprimé du presse-papier
2.2.1.2.3. Copy Ctrl+Insert
Le texte sélectionné est copié vers le presse-papier
2.2.1.2.4. Paste Shift+Insert
Le texte du presse-papier est insérer à la position du curseur
2.2.1.2.5. Delete
Le texte sélectionné est détruit
2.2.1.3. TABLE MENU Alt+T
Ce menu contient des commandes qui permettent d'accéder aux données d'une
table de différentes façons.

2.2.1.3.1. Select Ctrl+S
Une fenêtre de commande est ouverte afin de permettre la saisie d'une requête. Le
mot réservé SELECT constitue un des éléments de base de la recherche et de la
restitution d'informations dans une base de données relationnelle. Quand l'ensemble
du texte constituant la requête à été saisi, le bouton OK déclenche l'exécution, le
bouton CANCEL l'annulation. La touche de tabulation (TAB) permet de se déplacer
entre les différentes parties du texte de la fenêtre. On peut également cliquer avec la
souris sur une partie du texte. La commande SELECT est présentée de façon plus
approfondie dans les chapitres suivants.
2.2.1.3.2. Delete From
Cette commande est utilisée pour supprimer des lignes dans une table.
2.2.1.3.3. Insert into
Une fenêtre de commande est ouverte pour que le texte de la requête puisse être
saisi. Elle permet à de nouvelles lignes d'être insérées dans la table.
2.2.1.3.4. Update
On choisit cette commande pour modifier des valeurs dans une table. Les valeurs
utilisées peuvent être des constantes ou des valeurs déjà stockées dans la base de
données.
2.2.1.3.5. QBE New Box
Cette commande ainsi que les trois qui suivent fournissent un accès au système
QBE (Query By Exemple) qui sera présenté en détail plus loin. QBE est une
méthode visuelle de formulation des requêtes et de maintenance des données qui
peut, dans de nombreux cas, être utilisée de façon alternative à SQL. Une boite de
dialogue est ouverte et permet d'effectuer un choix entre table, condition ou
impression. Si la boîte concernant les tables est sélectionnée, une fenêtre de
dialogue supplémentaire est présentée permettant à l'utilisateur de choisir la table
sur laquelle il veut travailler.
2.2.1.3.6. QBE Execute Ctrl+X
Une fois qu'une opération a été définie en plaçant les valeurs appropriées dans la
fenêtre QBE, cette commande est utilisée pour compiler et exécuter la requête.

2.2.1.3.7. QBE View SQL
Avec MicroSQL, les entrées de la fenêtre QBE sont traduites en une requête
équivalente SQL. Cette commande permet de visualiser le code SQL ainsi produit
dans l'éditeur (Change editor).
2.2.1.3.8. QBE List
Les entrées de l'ensemble des boîtes QBE courantes sont listées sur l'imprimante ou
dans un fichier disque.
2.2.1.4. STRUCTURE MENU Alt+S
Les différentes commandes de ce menu font référence aux actions de création,

modification et destruction des structures de la base de données. Pour la création
d'une structure, une fenêtre est ouverte pour saisir le texte correspondant à cette
action après avoir sélectionné le type d'objet dans une boîte de dialogue.
2.2.1.4.1. Alter
Cette commande permet la modification de structure d'une table ou d'un domaine.
2.2.1.4.2. Create
La commande create permet de définir les structures fondamentales d'une base de

données. Une boite de dialogue complémentaire offre le choix entre les éléments
suivants :
Assertion
Database
Domaine
Synonyme
Table
View
2.2.1.4.3. Drop
Tous les éléments énumérés ci-dessus peuvent être supprimés du dictionnaire actif
par cette commande.
2.2.1.4.4. Include

Le résultat de la requête courante est stocké dans la base de données sous la forme
d'une table temporaire.
2.2.1.4.5. Release
Toutes les tables temporaires (Include) sont supprimées de la base de données.
2.2.1.5. COMMAND MENU Alt+C
Les options de ce menu permettent de manipuler les commandes et les requêtes de

différentes façons.
2.2.1.5.1. Change
La commande courante ou précédente, ainsi que la requête courante peuvent être

éditées. Seules les commandes comportant plus d'une ligne sont disponibles.
Cependant, toutes les commandes saisies ou éditées pendant une session SQL
sont accessibles à l'aide de Prior et Next.
2.2.1.5.2. List
Cette commande permet de lister des informations au sujet de différents éléments.

Normalement, l'information est affichée à l'écran, mais si les indicateurs Set Print ou
Set Disk sont sur On, les informations seront redirigées soit vers l'imprimante, soit
vers un fichier disque. Les éléments qui peuvent être traités sont les suivants :
Assertions
Checks
Command
Default
Domaine
Foreign keys
Previous (command)
Query
View
2.2.1.5.3. Recall
La commande ou la requête est chargée à partir d'un fichier du disque et placée

dans l'éditeur. Dans chaque cas, une boîte de dialogue présente la liste des
commandes ou requêtes présentes dans le répertoire de la base de données. Par
défaut, les commandes sont stockées dans des fichiers ayant une extension "*.cmd "
et les requêtes "*.qry ".

2.2.1.5.4. Save
La commande ou la requête courante est sauvegardée sur le disque. Un nom de

fichier est choisi à partir d'une liste présentée dans une boîte de dialogue, ou bien
un nouveau nom est tapé. Par défaut, les commandes sont sauvegardées dans des
fichiers ayant une extension "*.cmd " et les requêtes "*.qry ".
2.2.1.5.5. Start
Une requête ou une commande est chargée à partir du disque et exécutée. Dans les
deux cas, une boîte de dialogue est ouverte pour permettre de choisir la commande
ou la requête à partir de la liste de celles qui sont disponibles sur le disque.
2.2.1.5.6. Prior Command Gray —
Les commandes ou requêtes tapées ou éditées pendant une session SQL sont
stockées dans un fichier journal auquel on peut accéder dans l'ordre inverse des
entrées.
2.2.1.5.7. Next Command Gray +
On utilise cette option pour accéder aux commandes ou requêtes du fichier journal
dans l'ordre des entrées.
2.2.1.5.8. Windows
Une fenêtre vide est ouverte pour entrer le texte d'une commande ou d'une requête.
2.2.1.6. DISPLAY MENU Alt+D
Ce menu contient les commandes permettant de visualiser les descriptions de base

de données et de tables.
2.2.1.6.1. Describe Ctrl+D
Donne les détails des bases de données contenues dans le dictionnaire courant ou
d'une table choisie à partir de la base de données active.
2.2.1.6.2. Display
La table résultat courante est réaffichée. On notera que chaque nouvelle copie est
placée dans une fenêtre séparée qui peut être manipulée de façon indépendante.
2.2.1.6.3. Format
Une fenêtre est ouverte pour qu'une commande de Format puisse être tapée. Cela
permet de présenter le résultat de la requête courante de différentes façons. Ces
options de présentation ne s'appliquent qu'au résultat courant. Elles reprennent
leurs valeurs par défaut lors de l'entrée d'une nouvelle requête.
2.2.1.6.4. Format Options
Donne le détail de toutes les options de présentation disponibles.
2.2.1.6.5. Keep Dislay
Le contenu de la fenêtre résultat est sauvegardé dans une fenêtre permettant de

conserver l'information. En effet, le contenu des fenêtres résultats est perdu à
chaque nouvelle requête.
2.2.1.7. PROCEDURE MENU Alt+P
Les différentes commandes de ce menu traitent de la création et du fonctionement

des procédures de MicroSQL. Les procédures sont utilisées pour développer des
applications " clients ".
2.2.1.7.1. Edit Ctrl+E
Une procédure est sélectionnée pour être chargée dans l'éditeur de texte, ou bien le
nom d'une nouvelle procédure est saisie, puis le contrôle est donné à l'éditeur des
procédures.
2.2.1.7.2. Run Ctr+R
La procédure sélectionnée est chargée en mémoire puis exécutée.
2.2.1.7.3. Show Error
Une aide sur la dernière erreur de commande ou de requête est fournie. Cette
facilité est surtout utilisée quand une erreur survient pendant l'exécution d'une
procédure.
2.2.1.8. WINDOW MENU Alt+W

Ces commandes permettent de manipuler les fenêtres actives. De plus, lorsque
plusieurs fenêtres sont ouvertes, l'une d'entre elles peut être amenée au premier
plan en cliquant sur la commande appropriée. On note également que l'on peut
" faire tourner " les fenêtres en tapant CTRL+TAB ou en cliquant sur toute partie
encore visible d'une fenêtre se trouvant en arrière plan.
2.2.1.8.1. Tile
Toutes les fenêtres actives sont présentées de façon " tuilée "
2.2.1.8.2. Cascade
Toutes les fenêtres actives sont présentes en cascade.
2.2.1.8.3. Close All
Toutes les fenêtres actives sont fermées.
2.2.1.9. HELP MENU Alt+H
Il n'y a que deux commandes dans ce menu
2.2.1.9.1. Index
Le contrôle est passé au système d'aide de MicroSQL et les pages d'aide sont
affichées. L'information est alors disponible sous forme d'un hypertexte.
2.2.1.9.2. About
Donne les détails de la version de Micro SQL
2.2.1.10. TOOLBAR (Barre des outils)
La barre des outils est située sous la barre des menus dont nous venons de détailler
les éléments. Elle est constituée d'un ensemble de boutons qui fournissent un accès
rapide aux commandes les plus communément utilisées. Ces boutons sont libellés
avec une ou deux lettres permettant d'identifier leur fonction.
L Load Chargement d’une base

F Form Formulaire de saisie
S Select Construction d’une requête
D Describe Description d’une base ou d’une table
Qb QBE Table Box Construction d’une requête QBE
Qx QBE Execute Exécution d’une requête QBE
Cq Change Query Rappel de la dernière requête dans l’éditeur
Cc Change Command Rappel de la dernière commande dans l’éditeur
E Edit Edition d’une procédure
R Run Exécution d’une procédure
? Help Aide
En laissant un instant la flèche de la souris sur un de ces boutons, on provoque

l'affichage du nom de la commande. Quand une commande de la barre des outils
est active, elle apparaît en noir sur fond jaune et un bref message est affiché sur la
ligne de statut. Si la commande n’est pas active elle est en blanc sur fond gris.
2.2.1.11. STATUS BAR (ligne de statut)
La ligne de statut est située en bas de la fenêtre principale. Elle est utilisée pour
afficher des messages du système de gestion de la base de données active. Le nom
de celle-ci est signalé dans la partie droite. Quand une tâche est en cours
d’exécution, un message avertit l’utilisateur.
Pendant la saisie de données dans un formulaire, un message informe l’utilisateur
sur le type et le format de l’attribut en cours.
En dehors de ces informations, Ready et Wait indiquent si le système est prêt à
travailler ou s’il est en train d’exécuter une tâche.

3. Base de Données Relationnelle "Ventes"
3.1. Modèle Conceptuel des Données "VENTES"
Départ Succ Emp

Situation Direction 1,n
No Dept Directeur
0,n 1,1
Code Succ 0,n
No Emp
Nom Dept 1,1
Nom 0,1
0,n 1,n 1,n
0,n
Cli
Code_cli Ventes
Résidence Nom 1,n
1,1
Quant
Taux
Prod 1,n
Fabric Code Pr
1,n
Defauts Libelle
Quant
0,n
0,n Date
3.2. Schéma relationnel "VENTES" ( contenu des tables en annexe 1)
SUCC ( CODE_SUCC, #DEPT, #NO_DIR)

PROD(CODE_PR, LIBELLE)
CLI(CODE_CLI, NOM, TAUX, #DEPT)
ANC_CLI(CODE_CLI, NOM, TAUX, #DEPT)
DEPART(NO_DEPT,NOM_DEPT)
EMP(NO_EMP, NOM, #NO_DIR)
FABRIC(DATE,C_PROD, DEPT, DEFAUTS, QUANT)
VENTES(DATE, C_SUCC, C_CLI, NO_VEND, C_PROD, QUANT)
Remarques: Les attributs suivants (préfixés du nom des tables) appartiennent aux
mêmes domaines.
DEPART.NO_DEPT→ SUCC.DEPT,CLI.DEPT, ANC_CLI.DEPT, FABRIC.DEPT

EMP.NO_EMP→ SUCC.NO_DIR, EMP.NO_DIR, VENTES.NO_VEND
SUCC.CODE_SUCC → VENTES.C_SUCC
CLI.CODE_CLI → VENTES.C_CLI
PROD.CODE_PR → VENTES.C_PROD, FABRIC.C_PROD

3.3. La Base de données VENTES dans MicroSQL
3.3.1. Ouverture d'une session
Le chargement de la base de données active s'effectue en deux temps:
1 - Sélection du répertoire
Commandes [File] [Set]
Sélection
du chemin

Sélection du chemin par la commande [Path]
Choix du répertoire dans lequel la base de données est stockée:
[-a-] lecteur de disquette 3 pouces

[-c-] disque dur
etc….
[..] commande de "remontée" dans les répertoires
2 - Chargement de la base

Si le nom de la base de données n'apparaît pas à ce niveau, c'est que le répertoire
qui a été sélectionné n'est pas correct. En revanche, si le chargement a réussi, le
nom de la base de données active est noté en bas de l'écran, à droite:
3.3.2. Description de la base
Après le chargement d’une base de données [Load], le détail de son organisation se

trouve dans le dictionnaire des données qui peut être visualisé avec la commande
[Describe | Database]. Par exemple, voici la description de la base VENTES :
Le type real indique qu’il s’agit d’une table réelle, contenant des données présentent
sur le disque. L’autre type possible est view, que nous étudierons plus loin.
3.3.3. Description des tables
Une fois la base de données chargée, on peut accéder aux descriptions des tables
par la commande [Describe | Table].

Ainsi, la description de la table Cli (clients) fournit les informations suivantes :
• Nom de la table et type (real ou view)

• Nom des colonnes de la table et leur type de données
• Les colonnes contenant un attribut clé
• Les valeurs NULL autorisées ou non
• La largeur de chaque colonne en nombre de caractères
3.3.4. Les tables du système MicroSQL
Il existe deux tables système contenant des informations sur les autres tables de la
base de données active : systables et syscolumns. Le contenu de ces deux tables
peut être visualisé avec la command SELECT qui sera étudiée dans le chapitre
suivant.
Voici à titre d’exemple le contenu de ces deux tables dans la base de données
Ventes.
SELECT *
FROM systables
SELECT *
FROM syscolumns

SELECT *
FROM syscolumns
WHERE tabname = « EMP »

4. SQL : Langage de Manipulation des Données
4.1. Requêtes sur une table:
4.1.1. Remarques préalable
Dans la fenêtre principale de MicroSQL, une requête se construit de la façon

suivante :
1. Ouverture de la fenêtre des requêtes (query) soit par le menu [Table |Select], soit
par la barre des outils [S]
2. Saisie du texte de la requête (les commentaires et le numéro de la requête sont
placés entre {…} )
3. Exécution de la requête (OK)
4. Le résultat est affiché, le texte de la requête disparaît de l’écran.
5. On peut récupérer le texte de la requête par la commande [Command|Prior
command Gray -]
6. La sauvegarde s’effectue par [Command|Save]. On donne alors le nom Q1 … Qn
tel qu’il apparaît dans l’en-tête.
Pour éviter d’alourdir la présentation, chaque requête exemple de la suite de ce

cours sera présentée de la façon suivante :
4.1.2. Projection
4.1.2.1. Afficher le contenu d’une table
{ Q01 liste avec toutes les colonnes Question en langage naturel figurant
de la table FABRIC (fabrications) } dans le commentaire de la requête avec
le numéro de la sauvegarde (Q01)
SELECT *
FROM fabric
Texte de la requête (SQL)
Réponse:
Table résultat
{ Q02 liste avec toutes les colonnes

de la table EMP (Employés)} Exercices d’application
{ Q03 liste avec toutes les colonnes

de la table PROD (Produits) }
4.1.2.2. Choix des attributs
La clause SELECT permet de réaliser l’action la plus élémentaire sur une table :
sélectionner le ou les attributs de la table résultat. En algèbre relationnelle, cette
opération est appelée PROJECTION. Il existe donc une ambiguïté au niveau du
vocabulaire. Nous verrons par la suite que l’action de sélection telle qu’elle est
définie sur la plan algébrique est réalisée par une autre commande.
L’astérix (*) remplace tous les attributs de la table. Ainsi, pour reprendre l’exemple
précédent :
SELECT *
Est équivalent à
SELECT DATE,C_PROD,DEPT,DEFAUTS,QUANT

4.1.2.3. Sélectionner des attributs particuliers
Il est parfois nécessaire d’extraire des valeurs provenant de certaines colonnes .

Dans ce cas, seuls les attributs souhaités sont énumérés à la suite du SELECT.
{ Q04 liste avec c_prod (code produit)

et dept (département) de la table FABRIC }
SELECT c_prod, dept

FROM fabric
Réponse:
{ Q05 liste avec c_prod (code produit)

et quant (quantité) de la table FABRIC }
{ Q06 Nom des employés }
4.1.3. Elimination des doublons
Par défaut, SQL affiche toutes les lignes correspondant aux attributs cités dans le
SELECT. Le mot réservé DISTINCT permet de ne conserver qu’un exemplaire de
toutes les lignes identiques. Dans ce cas, il s’agit d’un équivalent de la projection
algébrique qui élimine les doublons par définition.
{ Q09 Dans quels départements y a-t-il des fabrications ? }
SELECT DISTINCT dept

FROM fabric
Réponse:

remarque: DISTINCT change la nature de la réponse. En éliminant les répétitions,
on obtient une réponse en compréhension par rapport à la question posée.
{ Q10 code des clients ayant effectués des achats }
{ Q11 liste des départements de fabrication avec les codes

des produits et élimination des doublons }
SELECT DISTINCT dept, c_prod

FROM fabric
Réponse:
Remarque: le DISTINCT agit sur l'ensemble des attributs cités. Dans le cas
précédent, c'est le couple 53 GC qui est éliminé .
{ Q12 Produits vendus dans les succursales (c_succ, c_prod) }
4.2. Les commandes de tris
L’ordre dans lequel sont affichées les données de la table résultat peut être contrôlé
par la commande ORDER BY suivi du nom de l’attribut sur lequel le tri interviendra.
Bien entendu les autres valeurs de chacune des lignes de la table résultat suivent
les mêmes réarrangements que l’attribut cité dans le tri !

{ Q13 Liste des dates, codes et défauts des fabrications, triée par défauts }
SELECT date, c_prod, defauts

FROM fabric
ORDER BY defauts
Réponse:
Sans autres précisions, le tri est ascendant. Cette action correspond au mot réservé
ASC . Un tri descendant est réalisé par le mot réservé DESC.
{ Q14bis liste avec toutes les colonnes de la table FABRIC

triée par défauts en ordre décroissant }
SELECT *
FROM fabric
ORDER BY defauts DESC
Réponse:

Un tri peut être demandé sur plusieurs attributs. Dans ce cas, il est réalisé dans
l’ordre des attributs cités, c’est à dire d’abord sur le premier attribut, puis pour toutes
les valeurs identiques de ce premier attribut, sur le second et ainsi de suite…
{ Q14 liste des fabrications avec dates, départements, codes et quantités,

triée par dates et par départements }
SELECT date, dept, c_prod, quant

FROM fabric
ORDER BY date, dept
Réponse:
On peut également préciser l’ordre de tri pour chacun des attributs :
{ Q15 liste des fabrications avec dates, départements, codes et quantités,

triée par dates en ascendant et par départements en descendant }

FROM fabric
ORDER BY date ASC, dept DESC
Réponse:

Les attributs utilisés pour le tri peuvent également être spécifiés par leur numéro
d’ordre dans le SELECT. Ainsi, la requête suivante est équivalente à la précédente :
{ Q16 liste des fabrications avec dates, départements, codes et quantités

triée par dates en ascendant et par départements en descendant }

FROM fabric
ORDER BY 1 ASC, 2 DESC
{ Q17 liste des ventes avec toutes les colonnes, triée sur les codes clients
par ordre croissant et sur les quantités par ordre décroissant }
4.3. Sélection avec une condition de recherche
4.3.1. La clause WHERE
Il est parfois nécessaire de sélectionner certaines lignes dans une table. On utilise
pour cela le mot réservé WHERE qui introduit une clause de sélection sous la forme
d’un prédicat. Chaque ligne (ou tuple) vérifiant le prédicat fera partie de la table
résultat. Il s’agit donc d’une SELECTION au sens algébrique.
Le prédicat est une expression logique composée d’une ou de plusieurs conditions
pouvant prendre la valeur VRAI ou FAUX. Les conditions peuvent être combinées
entre elles à l’aide des opérateurs logiques AND, OR et NOT.
Une condition peut prendre une des trois formes suivantes :
ATTRIBUT θ constante
ATTRIBUT θ ATTRIBUT
ATTRIBUT θ paramètre
où θ est un opérateur appartenant à l’ensemble :
= égal à
<> ou ^= différent de
> supérieur à
^> pas supérieur à
>= supérieur ou égal à
< inférieur à
^< pas inférieur à
<= inférieur ou égal à
De plus, une expression peut contenir un des mots réservés suivants3:
♦ Comparaison à un intervalle (BETWEEN)

♦ Comparaison à un ensemble (IN)
♦ Comparaison à un filtre (LIKE)
♦ Recherche d’une valeur inconnue (IS NULL)
♦ Recherche de TOUS ou AU MOINS UN (ALL, ANY)
♦ Prédicat existentiel (EXIST)
♦ Test d’unicité (UNIQUE)
4.3.2. Comparaison à une valeur
Nous sommes dans le cas:
ATTRIBUT θ constante
La constante doit appartenir au même domaine de définition que l’attribut, c’est à

dire posséder le même type et la même sémantique. En général, les constantes
doivent sont formées de la façon suivante :
♦ Les chaînes de caractères entre cotes : Nom = ‘Dupont’

♦ Les valeurs numériques : quant >= 23
♦ Les valeurs booléennes : Présent = TRUE
♦ Les dates se traitent selon le format choisi : Date = ‘02/12/97’ ou Date = ‘971202’
{ Q18 liste avec toutes les colonnes des clients de Loire-Atlantique }
SELECT *
FROM cli
WHERE dept = '44'
Réponse:
3
Ils feront l'objet d'une étude détaillée dans la suite de ce cours
{ Q19 liste avec toutes les colonnes, des produits ayant des défauts supérieurs à 10
}
SELECT *
FROM fabric
WHERE defauts > 10
Réponse:
{ Q20 liste des noms de clients alphabétiquement4 supérieurs à ‘Ingres’ }
SELECT nom
FROM cli
WHERE nom > ‘Ingres’
Réponse:
4
Attention au traitement des caractères nationaux dans les versions anglo-saxonnes des SGBDR!
{ Q21 liste avec toutes les colonnes des produits fabriqués en Mayenne }
SELECT *
FROM fabric
WHERE dept = '53'
Réponse:
{ Q22 Codes des produits vendus dans la succursale '1A' }
{ Q23 Noms des clients de Loire-Atlantique }
{ Q24 Numéro des Vendeurs ayant réalisés des ventes > 100 }
4.3.3. Valeurs inconnues ou indéterminées
La plupart des systèmes de bases de données non-SQL n'évaluent que TRUE et

FALSE. SQL offre un système plus large de tests en traitant également les valeurs
dites "inconnues" ou « indéterminées » (NULL).
On obtient ainsi les tables de vérité suivantes: V=VRAI, F=FAUX, I=INCONNU
ET V F I OU V F I NON
---------------------------- ---------------------------- -----------
V V F I V V V V V F
F F F F F V F I F V
I I F I I V I I I I

Si l'on observe bien à la fois la table du ET et la table du OU, il n'y a aucune
différence entre la valeur FAUX et la valeur INCONNUE puisqu'un résultat FAUX ou
INCONNU empêchera la ligne de la table d'être éditée. Cependant, la table de vérité
du NON met en évidence une différence très importante: l'inverse de INCONNU est
encore INCONNU !
Les mots réservés IS NULL, IS NOT NULL permettent de rechercher les lignes
d’une table ayant ou non des valeurs de ce type. On ne peut pas utiliser ces mots
réservés dans une expression contenant un opérateur de comparaison.
{ Q25 liste avec toutes les colonnes des produits pour lesquels
il n y a pas d'information de défauts }
SELECT *
FROM fabric
WHERE defauts IS NULL
Réponse:
{ Q26 liste avec toutes les colonnes des produits pour lesquels
il y a des informations de défauts }
SELECT *
FROM fabric
WHERE defauts IS NOT NULL
Réponse:

Lors de la définition de la table, l’attribut defauts n’a pas été déclaré NOT NULL :
Create table fabric(

date date not null,
c_prod character(2) not null,
dept character(2) not null,
defauts numeric(2)
quant integer,
primary key (date, c_prod, dept))
Dans ce cas, les mots réservé IS NULL et IS NOT NULL confondent donc les
valeurs inconnues ou indéterminées avec la valeur zéro !
4.3.4. Expressions de recherche et opérateurs AND, OR et NOT
On construit des expressions de recherche en utilisant des opérateurs logiques. On

peut utiliser autant de connecteurs que l'on souhaite, les expressions seront
évaluées de la gauche vers la droite. Les AND sont évalués avant les OR. L'ordre
des précédences peut être modifié par la mise en place de parenthèses.
Il n’y a pas d’équivalence automatique entre les ET et les OU utilisés en langage
naturel et les opérateurs logiques. En langue française, le ET logique est parfois
implicite. Il n’apparaît pas dans la forme de surface de la question posée. Ainsi, la
question suivante (Q27) pourrait se formuler de la façon suivante :
Liste des produits qui sont fabriqués à Paris ET qui ont plus de 16% de défauts.
Cette forme, qui fait apparaître clairement le ET logique est trop lourde pour être
utilisée en langage courant. La forme qui suit est plus naturelle, mais elle masque la
présence du ET logique.
{ Q27 liste des produits fabriqués à Paris avec des défauts > 16% }
SELECT DISTINCT c_prod

FROM fabric

WHERE
dept = '75'
AND
defauts > 16
Réponse:
En revanche, dans la question suivante le OU logique est exprimé de façon

explicite :
{ Q28 liste des produits fabriqués à Paris ou en Mayenne }

FROM fabric
WHERE
dept = '75'
OR
dept = '53'
Réponse:
La mise en place de parenthèses permet de contrôler l’ordre de précédence des

opérateurs. Ainsi, les deux exemples suivants illustrent ce problème.
{ Q29 liste des produits fabriqués en dehors de Paris et de la Mayenne }
SELECT *
FROM fabric
WHERE NOT (dept = '75' OR dept = '53')
Réponse:

La requête suivante donne une réponse différente !
SELECT *
FROM fabric
WHERE NOT dept = '75' OR dept = '53'
Réponse:
Dans la question suivante, le OU logique apparaît de façon explicite, le ET est

masqué par la présence de la virgule après « Mayenne ».
{ Q30 liste des produits fabriqués à Paris ou en Mayenne,

qui ont moins de 16% de défauts }
SELECT *
FROM fabric
WHERE
(dept = '75' OR dept = '53')
AND
defauts <16
Réponse:
{ Q31 numéros des produits vendus par les employés 11 et 24 }
{ Q32 numéros des produits vendus dans la succursale 1A, en quantités >= 30 }
{ Q33 liste des produits fabriques en quantités < 40 avec des défauts > 10 }
4.3.5. Les opérateurs spécialisés
4.3.5.1. Comparaison à un intervalle de valeurs
BETWEEN constante1 AND constante2 : On peut ainsi effectuer une sélection

dans une fourchette de valeurs. On note que les valeurs spécifiées par constante1
et constante2 sont incluses dans le test.
{ Q34 liste des produits fabriqués avec des défauts entre 12 ou 16%
SELECT date, c_prod, dept, defauts

FROM fabric
WHERE defauts BETWEEN 12 AND 16
Réponse:
{ Q35 liste des clients ayant un taux de remise entre 15 et 20% }
{ Q36 liste des ventes avec des quantités entre 100 et 300 }

4.3.5.2. Comparaison à un modèle intégrant des variables LIKE, NOT LIKE
Une expression de recherche avec LIKE ou NOT LIKE est utilisée quand on veut
retrouver des données qui ont des éléments en commun. Le caractère spécial '%'
ou '*' est utilisé pour remplacer n'importe quel groupe de caractères. Ainsi LIKE 'D%'
recherche toutes les chaînes commençant par D. Le caractère '_' ou '?' est utilisé
dans les recherches comme caractère de substitution non plus à un groupe de
caractères comme '%' ou '*' mais à un seul caractère.
{ Q37 liste des produits dont le nom commence par un 'c' }
SELECT *
FROM prod
WHERE libelle LIKE 'c%'
Réponse:
Remarque : pour une lettre : _, pour des groupes de lettres ( y compris 0 ) : %
{ Q38 liste des produits dont le nom contient 'ou' }
SELECT *
FROM prod
WHERE libelle LIKE '%ou%'
Réponse:
{ Q39 liste des produits dont le nom se termine par 'm' }
SELECT *
FROM prod
WHERE libelle LIKE '%m'
Réponse:
4.3.5.3. Les opérateurs ensemblistes IN, ALL, ANY
L’opérateur IN permet de sélectionner les lignes dont l’attribut spécifié contient une
valeur appartenant à l’ensemble cité.
{ Q40 Liste des produits fabriques à Paris ou en Mayenne }

FROM fabric
WHERE dept IN ('75', '53')
Réponse:
{ Q41 Liste des produits fabriqués ayant des défauts de 12 ou 15 }
SELECT date, c_prod, dept

FROM fabric
WHERE defauts IN (12,15)
Réponse:

ANY, ALL: Ces expressions ensemblistes se construisent à l’aide des opérateurs de
comparaison (=, <>, <, >, <=, >=). On ne peut les utiliser qu’avec des sous-
requêtes !
ANY: Il suffit que l'un des éléments soit présent dans l'ensemble pour que le test
donne VRAI:
=ANY égal à au moins un des (élément_1,.....,élément_n)

>ANY supérieur à au moins un des (élément_1,.....,élément_n)
<ANY inférieur à au moins un des (élément_1,.....,élément_n)
<>ANY différent de au moins un des (élément_1,.....,élément_n)
>=ANY supérieur ou égal à au moins un des (élément_1,....,élément_n)
<=ANY inférieur ou égal à au moins un des (élément_1,…..,élément_n)
ALL : Il faut que tous les éléments présents dans l'ensemble vérifient le test.
=ALL égal à tous les (élément_1,.....,élément_n)

>ALL supérieur à tous les (élément_1,.....,élément_n)
<ALL inférieur à tous les (élément_1,.....,élément_n)
<>ALL différent de tous les (élément_1,.....,élément_n)
>=ALL supérieur ou égal à tous les (élément_1,.....,élément_n)
<=ALL inférieur ou égal à tous les (item_1,.....,item_n)
IN : Equivalent à =ANY
L’utilisation de ALL et ANY pose de nombreux problèmes et conduit parfois à des

erreurs. Il est donc recommandé de ne les utiliser que si l’on a parfaitement compris
leur fonctionnement. Dans la plupart des cas, on peut leur substituer des requêtes
existentielles que nous étudierons plus loin.
4.3.6. Expressions numériques
Il est possible de construire des expressions de calcul à partir d’attributs ayant un

type numérique. On utilise pour cela les opérateurs suivants :

Opérateurs binaires Opérateurs unaires
+ Addition + Positif
- Soustraction - Négatif
* Multiplication
/ Division
Les opérateurs binaires * et / ont un niveau de précédence supérieur aux

opérateurs binaires + et -. Les niveaux de priorité peuvent être modifiés par
l’utilisation de parenthèses. D’autre part, la présence d’une valeur NULL donne
toujours un résultat indéterminé.
{ Q42 liste des produits fabriqués avec code produit et défauts multipliés par deux }
SELECT c_prod, defauts*2

FROM fabric
Réponse:
Remarque: A la ligne n°4, la valeur inconnue ne peut pas être traitée
4.3.7. Calcul de Dates et d’Heures
MicroSQL fournit, comme la plupart des SGBDR5, certaines facilités pour effectuer
des calculs temporels à partir de la date et de l’heure maintenues par le système
informatique (ici date et heure de l’horloge du PC).
Variable Type de donnée Valeur retournée

Sysday numérique Jour du mois
Sysmon numérique Numéro du mois
Sysyear numérique Numéro de l’année
Sysdate Caractère Date au format dd mmm yyyy
5
Système de Gestion de Bases de Données Relationnelles
Sysddate Numérique Date au format yyyymmdd
Sysmin Numérique Minute courante (0 – 59)
Syshour Numérique Heure courante (0 – 23)
Systime Caractère Heure au format hh:mmAM/PM
4.3.8. Les Fonctions
SQL fournit deux types de fonctions : les fonctions de calcul et les fonctions
scalaires.
Les fonctions de calcul s’appliquent à un ensemble de valeurs d’un même attribut et
retourne un résultat. Les fonctions scalaires renvoient un résultat pour chaque
occurrence de valeur d’un attribut.
4.3.8.1. Les fonctions de calcul
Le nombre de fonctions disponibles sur un SGBRD dépend de la politique du

constructeur. Cela peut donc aller de quelques fonctions de base, comme c’est le
cas pour MicroSQL, jusqu’à des bibliothèques très spécialisées dans certains
domaines comme les statistiques ou les calculs économiques.
Les fonctions de calcul disponibles ici sont les suivantes :
Avg, Count, Max, Min, Sum
Une fonction de calcul s’applique sur des ensembles de valeurs dans des colonnes
qui doivent obligatoirement être spécifiées soit dans la clause SELECT, soit dans la
clause HAVING sur laquelle nous reviendrons plus loin. En aucun cas, dans la
clause WHERE !
Avg et Sum doivent toujours avoir un argument de type numérique.

Count, Max et Min peuvent opérer sur des attributs de type numérique ou caractère.
De plus, quand elle est utilisée pour compter le nombre de lignes dans une table, la
fonction COUNT peut avoir un astérix (*) comme argument.
Les valeurs inconnues ou indéterminées sont toujours ignorées par les fonctions
Avg, Max, Min et Sum.
Les règles à respecter sur le plan formel pour les fonctions de calcul sont les
suivantes :
• L’argument de la fonction doit être entre parenthèses

• L’argument de la fonction peut être un nom de colonne (attribut) ou une
expression
• L’argument de la fonction ne peut pas contenir une autre fonction de calcul

• Une fonction de calcul ne peut apparaître que dans un SELECT ou un HAVING
• Si une fonction de calcul est appliquée sur un des éléments de la liste suivant la
clause SELECT, alors chacun des éléments de cette liste doit être également un
argument d’une fonction de calcul, sinon la clause GROUP BY, que nous
étudierons plus loin, doit être mise en œuvre.
Voici maintenant une série d’exemples illustrant le paragraphe précédent :
4.3.8.1.1. Le comptage des occurrences de nuplets ou d'attributs
{ Q43 Combien de lignes dans la table fabric }
SELECT COUNT (*)

FROM fabric
Réponse:
{ Q44 Combien de départements fabriquent des produits }
SELECT COUNT (DISTINCT dept)

FROM fabric
Réponse:
remarque: Attention, la table FABRIC contient des informations sur des

événements de fabrications. Lorsqu'un produit fait l'objet de plusieurs fabrications
dans un département, le numéro du département sera présent dans la table autant
de fois qu'il y a eu de fabrications. En éliminant les doublons, le DISTINCT permet
une réponse en compréhension plutôt qu'en extension.
{ Q45 Combien de numéros de directeurs dans la table emp }

SELECT COUNT ( no_dir)
FROM emp
Réponse:
Remarque : Comment expliquer la valeur 16 plutôt que 15 ? ?
{ Q46 Combien d'employés de l'entreprise ont des fonctions de direction }
SELECT COUNT (DISTINCT no_dir)

FROM emp
Réponse:
Même remarque que précédemment !
{ Q47 Combien de fabrications du produit DD }
SELECT COUNT ( *)
FROM fabric
WHERE c_prod = 'DD'
Réponse:

4.3.8.1.2. Les fonctions de calcul
{ Q48 Quelle est la moyenne des défauts pour les produits fabriqués en Mayenne}
SELECT AVG (defauts)

FROM fabric
WHERE dept = '53'
Réponse:
Remarque : Au moment de l’exécution de la requête, MicroSQL signale la présence

d’une valeur inconnue ou indéterminée dans la colonne qui sert d’argument à la
fonction. La moyenne n'est faite que sur deux lignes, la valeur NULL n’est pas prise
en compte.
{ Q49 Afficher la moyenne et la somme des quantités de produits DD }
SELECT AVG(quant), SUM(quant)

FROM fabric
WHERE c_prod = 'DD'
Réponse:
{ Q50 Afficher la moyenne et la somme des quantités de produits DD

en renommant les colonnes par des alias : MOY_Q et SOM_Q
SELECT AVG(quant) AS MOY_Q, SUM(quant) AS SOM_Q

FROM fabric
WHERE c_prod = 'DD'
Réponse:

remarque: Dans un autre formalisme on aurait écrit:
SELECT AVG(quant) MOY_Q, SUM(quant) SOM_Q
en remplaçant le mot réservé AS par un espace.
{ Q51 liste des produits fabriqués avec codes et défauts multipliés

par les quantités en renommant la colonne DEF_QUANT }
SELECT c_prod, defauts*quant AS DEF_QUANT

FROM fabric
Réponse :
4.3.8.2. Les fonctions scalaires
Une fonctions scalaire retourne une valeur pour chaque occurrence d’attribut.
Contrairement à la fonction de calcul, la fonction scalaire peut être emboîtée et
constituer l’argument d’une autre fonction scalaire. En général, SQL fournit les
fonctions suivantes :
Nom de la fonction Réalisation

Cast Conversion de type
Character_length Longueur d’une chaîne
Char_length Idem
Lower Chaîne en minuscules
Position Position d’une sous-chaîne dans une chaîne
Substring Extraction d’une sous-chaîne
Trim Suppression des espaces terminaux
Upper Chaîne en majuscules
{ Q52 Nom des employés en majuscules }
SELECT Upper(nom)
FROM emp
Réponse :
{ Q53 Dimension du nom d’employé le plus long }
SELECT Max(char_length(nom))
FROM emp
Réponse :

4.3.9. Fonctions de calcul avec regroupement des résultats
En SQL, le GROUP BY permet de réaliser des calculs intermédiaires dans des

tables ayant des occurrences d’attribut(s) qui sont répétées. Ces colonnes
contenant des valeurs identiques sont utilisées pour regrouper les résultats.
{ Q54 Afficher le code produit et la moyenne des quantités fabriquées

pour chaque produit }
SELECT c_prod, AVG(quant)

FROM fabric
ERREUR!!
Remarque: SQL va essayer d'afficher des codes produits en mettant une valeur de
calcul en face. Deux possibilités:
1 - soit il y a une énumération de tous les codes produits présents dans la table et le
seul affichage concernant les quantités ne peut être que la liste des quantités
présentes dans la table en face de chaque code produit. Dans ce cas, SQL ne sait
pas quoi faire de la fonction AVG()
2 - soit un calcul global est effectué sur les quantités et SQL ne sait pas quoi faire
de la commande SELECT c_prod
Il est donc nécessaire dans un pareil cas de préciser, au niveau de la requête, qu'il
faut effectuer un regroupement par occurrences de code produit.
{ Q55 Afficher le code produit et la moyenne des quantités fabriquées

SELECT c_prod, AVG(quant)

FROM fabric
GROUP BY c_prod
Réponse :

{ Q56 Moyenne des défauts par département }
SELECT dept, AVG(defauts)

FROM fabric
GROUP BY dept
Réponse:
SQL signale la présence d’une valeur inconnue ou indéterminée qui n’est pas prise
en compte dans le calcul !
Remarque: Le GROUP BY réalise deux opérations:
1- il trie par ordre croissant sur le nom de l'attribut (ou des attributs) cité dans le
SELECT
2- il exécute la fonction de calcul pour chaque ensemble de valeurs identiques de
l'attribut cité. C'est, en quelque sorte, une fonction de résultats intermédiaires.
ATTENTION: l'attribut (ou les) cité dans le GROUP BY doit être présent dans le
SELECT.
4.3.10. Fonctions de calcul avec regroupement et sélection
La clause HAVING dans une fonction de regroupement agit de façon similaire à un

WHERE. Il y a cependant une différence importante : elle ne s’applique qu’après
que les groupes aient été formés !
{ Q57 Liste des départements de fabrication et moyenne des défauts

pour les départements ayant une moyenne>10 }

FROM fabric
GROUP BY dept HAVING AVG(defauts) >10
Réponse:
Intuitivement, on pouvait imaginer de restreindre le calcul en employant le mot

réservé WHERE. Cependant, comme nous le verrons plus loin, le WHERE peut être
utilisé pour sélectionner les nuplets qui participent au calcul. Le HAVING n'agit pas
de même, il restreint l'édition des résultats. On peut exprimer la dernière ligne de la
requête précédente de la façon suivante:
REGROUPER PAR dept AYANT une MOYENNE(defauts) >10
{ Q58 Liste des départements de fabrication ( sauf Paris) et moyenne des défauts
pour les départements ayant une moyenne>10 }

FROM fabric
WHERE dept <> ‘75’
GROUP BY dept HAVING AVG(defauts) >10
Réponse:
La condition du HAVING agit toujours sur un regroupement, alors que le WHERE

agit sur chacune des lignes de la table considérée (voir exemple précédent).

De plus, la condition présente dans HAVING n’est pas obligatoirement celle qui est
présente dans le SELECT.
{ Q59 Plus grosses ventes réalisées par vendeur (No-vend)}
SELECT no_vend, MAX(quant)

FROM ventes
GROUP BY no_vend
Réponse:
{ Q60 Plus grosses ventes réalisées par vendeur (No_vend) ayant effectué plus de
trois ventes}
SELECT no_vend, MAX(quant)

FROM ventes
GROUP BY no_vend HAVING COUNT(*) >= 3
Réponse:

4.4. Requêtes sur plusieurs tables
4.4.1. La Jointure
Certains résultats nécessitent que des informations soient collectées à partir de

plusieurs tables. Ceci est réalisé grâce à l’opération de jointure. SQL dispose à la
fois d’une construction spécifique et d’opérateurs spécialisés qui permettent de
réaliser cette action.
4.4.1.1. La construction spécifique de jointure ( présentation intuitive)
Comparons le contenus de deux tables liées entres elles au niveau du MCD : la

table des fabrications et la table des produits.
{ Q61 Contenu de la table fabric }
SELECT *
FROM fabric
Réponse:
{ Q62 Contenu de la table prod }
SELECT *
FROM prod
Réponse:

L’observation des deux tables résultats fait apparaître que la colonne Code_pr de la
table des produits et la colonne C_prod de la table des appartiennent au même
domaine. Elles contiennent toutes les deux des codes de produits.
Intuitivement, il semble donc possible d’utiliser cette information commune pour
réaliser une association entre ces deux tables.
{ Q63 Une association entre prod et fabric }
SELECT *
FROM fabric, prod
Réponse (extrait):
Le résultat est surprenant au niveau du volume d’informations récupéré ( nombre de

lignes de prod X nombre de lignes de fabric). Une observation plus fine du début de
la table résultat nous permet de mettre en évidence le phénomène suivant :
La première ligne de la table fabric :
a été associée à toutes les lignes de la table prod :

Nous obtenons donc un résultat qui n’a aucune sémantique ! Nous avons effectué
un Produit cartésien entre les deux tables. Il s’agit d’une opération qui consiste à
associer sans aucune considération de sens, toutes les lignes d’une table à toutes
les lignes d’une autre.
Forme générique du Produit cartésien entre deux tables T1 et T2
SELECT *
FROM T1, T2
Pour obtenir le résultat souhaité, c’est à dire associer la ligne de la table fabric
concernant un produit, à la ligne de la table prod concernant ce même produit, il est
nécessaire d’installer une contrainte. Dans le cas évoqué ici, cette contrainte
pourrait s’énoncer de la façon suivante en langage naturel :
Il faut que le code de produit de la table des fabrications soit égal au code
produit de la table des produits :
c_prod = code_pr
{ Q64 Jointure entre prod et fabric selon c_prod et code_pr }
SELECT *
FROM fabric, prod
WHERE c_prod = code_pr
Réponse :

Forme générique de la jointure entre deux tables T1 et T2
SELECT *
FROM T1, T2
WHERE T1.Atx = T2.Aty
(Atx et Aty sont des attributs union-compatibles des tables T1 et T2, ils
appartiennent au même DOMAINE)
Les informations redondantes (c_prod et code_pr) sont éliminées par projection
{ Q65 Jointure entre prod et fabric selon c_prod et code_pr }
SELECT date, c_prod, libelle, dept, defauts, quant

FROM fabric, prod
WHERE code_pr = c_prod
Réponse:

4.4.1.2. Jointure entre trois tables
{ Q66 Pour insérer les noms des produits et les noms des départements,
il est nécessaire d'effectuer une jointure entre les trois tables
fabric, depart et prod }
SELECT date, c_prod, libelle, dept, nom_dept, defauts, quant

FROM depart, fabric, prod
WHERE
code_pr = c_prod { contrainte de jointure entre PROD et FABRIC }
AND
dept = no_dept { contrainte de jointure entre FABRIC et DEPART }
Réponse:

remarque: les jointures sont réalisées deux à deux, donc pour deux tables il est
nécessaire d'avoir une contrainte de jointure, pour trois tables deux contraintes, pour
n tables, n-1 contraintes.
4.4.1.3. Homonymie des attributs dans une requête de jointure
Quand les attributs de 2 tables ont le même nom, il faut lever l'ambiguïté en préfixant
le nom de l’attribut par celui de la table d’où il provient : on fait précéder le nom de
l'attribut du nom de la table en les séparant par un point :
NOM_TABLE.NOM_ATTRIBUT
{ Q67 exemple: nom des clients et nom des employés ayant réalisé les ventes }
SELECT cli.nom, emp.nom

FROM ventes, cli, emp
WHERE
c_cli = code_cli
AND
no_vend = no_emp
Réponse:
{ Q68 même requête que précédemment en renommant les attributs par des alias }

SELECT cli.nom AS Client, emp.nom AS Vendeur
FROM ventes, cli, emp
WHERE
c_cli = code_cli
AND
no_vend = no_emp
Réponse:
La plupart du temps, la jointure est utilisée pour « renseigner » une table issue d’une
association du MCD à l’aide des informations contenues dans la ou les tables issues
des entités du MCD. C’est un système de reconstruction de l’information mise en
troisième forme normale, afin de la rendre intelligible.
{ Q 69 "développement" de la table VENTES en renseignant tous les attributs clés

et en préfixant les attributs ambigus }
SELECT date, c_succ, nom_dept, cli.nom, no_vend, emp.nom, c_prod, libelle, quant
FROM ventes, cli, emp, succ, depart, prod
WHERE
c_succ = code_succ
AND
succ.dept = no_dept { ambiguïté entre "dept" de SUCC et "dept" de CLI }
AND
c_cli = code_cli
AND
no_vend =no_emp
AND
c_prod = code_pr
Réponse (extrait):
4.4.1.4. Contraintes de jointure et clause de sélection
On peut restreindre le résultat d’une jointure en introduisant une clause de sélection.
{ Q70 nom des vendeurs ayant réalisé des VENTES >100 }
SELECT nom, quant

FROM ventes, emp
WHERE
no_vend =no_emp
AND
quant>100
Réponse:

Remarque: il ne faut pas confondre dans le WHERE l’expression qui traduit une
contrainte de jointure entre deux tables:
no_vend = no_emp
de celle qui exprime une clause de sélection:
quant>100
4.4.1.5. Les opérateurs spécialisés de jointure
4.4.1.5.1. L’opérateur JOIN
En SQL, une jointure peut être construite directement en plaçant les mots réservés
NATURAL JOIN entre les deux noms de tables de la clause WHERE d’une requête.
Ce type de jointure n’est réalisable que lorsque les deux attributs utilisés ont le
même nom dans chacune des tables.
Par exemple, la table Fabric et la table Succ ont une colonne Dept en commun qui
indique, pour les succursales comme pour les fabrications, le département dans
lequel elles sont situées. Faire une jointure entre ces deux tables selon cet attribut,
c’est rechercher les fabrications qui ont lieu dans un département où il y a une
succursale.
{ Q71 Join naturel entre Fabric et Succ }
SELECT *
FROM fabric NATURAL JOIN succ
Réponse:

Remarque :
1. La véritable forme du join naturel est : NATURAL INNER JOIN. Cependant, la

plupart des SGBDR acceptent la forme restreinte NATURAL JOIN.
2. Quand une jointure de ce type est réalisée, l’attribut utilisé dans chacune des
deux tables n’est affiché qu’une fois dans la table résultat.
3. On peut réaliser un NATURAL JOIN sur plusieurs tables (ayant des nom
d’attributs communs). La forme générique est la suivante :
SELECT *
FROM Table1 NATURAL JOIN Table2 NATURAL JOIN Table3
4.4.1.5.2. La clause USING
Quand plusieurs colonnes de deux tables ont des nom identiques, on peut préciser
l’attribut sur lequel la jointure s’effectuera à l’aide du mot réservé USING(attribut).
Par exemple les deux tables Cli (clients) et Anc_cli (Anciens clients) ont des noms
d’attributs identiques. Pour réaliser un join naturel entre ces deux tables selon le
numéro de département, il est nécessaire de préciser USING(Dept).
{ Q72 Join avec USING – Noms des Clients résidant dans un département où
résident d’anciens clients }
SELECT DISTINCT nom

FROM cli JOIN Anc_cli USING(Dept)
Réponse:

{ Q73 Join avec USING – Noms des Anciens clients résidant dans un département
où résident des clients actuels }
SELECT DISTINCT nom

FROM anc_cli JOIN cli USING(Dept)
Réponse:
Remarques :
1. Quand le mot réservé USING est utilisé, on ne peut pas utiliser NATURAL.
2. Si plusieurs attributs sont cités dans le USING, ils doivent être séparés par des
virgules : USING(At1, At2)
4.4.1.5.3. La clause ON
Ce mot réservé permet de réaliser un JOIN entre deux tables n’ayant pas d’attributs
portant le même nom :
{ Q74 JOIN avec ON }
SELECT *
FROM cli JOIN depart
ON dept = no_dept

Réponse:
Remarques :
1. Le mot réservé NATURAL ne doit pas apparaître quand ON est présent.

2. Contrairement au join naturel, les noms des attributs utilisés pour la jointure
(dept, no_dept) apparaissent dans la table résultat.
3. La clause ON peut comporter plusieurs conditions. Elles sont alors reliées par
des connecteurs logiques.
4.4.1.5.4. Les OUTER JOIN
Jusqu’à présent, nous avons réalisé des jointures dites « internes ». Cela signifie
que dans la table résultat, on obtenait les lignes vérifiant la ou les clauses de
jointures. Pour reprendre un exemple précédent, quand on écrit la requête suivante :
SELECT *
FROM anc_cli JOIN ventes
ON code_cli = c_cli
la table résultat nous donne les lignes pour lesquelles la valeur présente dans
la colonne code_cli de la table anc_cli (anciens clients) est égale à la valeur
présente dans la colonne c_cli de la table des ventes.
Réponse:

Or, il existe des situations où l’on a besoin de visualiser dans la table résultat, non
seulement les lignes pour lesquelles la clause de jointure (ON code_cli = c_cli) a
réussi, mais également les lignes pour lesquelles elle a échouée, c’est à dire celles
pour lesquelles code_cli est différent de c_cli. Il existe donc deux possibilités :
1. Dans la table résultat, on reproduit toutes les lignes de la première table (table
de gauche) puis on met en correspondance les lignes de la deuxième table (table
de droite) quand la jointure est possible et des lignes contenant des valeurs
inconnues ou indéterminées quand elle n’est pas possible. C’est ce que l’on
appelle la demi-jointure gauche :
Table1 LEFT OUTER JOIN Table2
où table1 sera entièrement restituée (table de gauche dans l’expression)
2. Dans la table résultat, on reproduit toutes les lignes de la seconde table (table de
droite). Puis on met en correspondance les lignes de la première table (table de
gauche) de façon symétrique à ce qui vient d’être énoncé pour la demi-jointure
gauche. C’est ce que l’on appelle la demi-jointure droite :
Table1 RIGHT OUTER JOIN Table2
où table2 sera entièrement restituée (table de droite dans l’expression)
Voici deux exemples illustrant ce type de jointure :
{ Q75 demi jointure gauche entre Anc_cli et ventes }
SELECT *
FROM anc_cli LEFT OUTER JOIN ventes
ON code_cli = c_cli
Réponse (extrait):

{ Q75bis demi jointure droite entre anc_cli et ventes }
SELECT *
FROM anc_cli RIGHT OUTER JOIN ventes
ON code_cli = c_cli
Réponse (extrait):

Il existe également une commande permettant de réaliser conjointement la
demi-jointure gauche et la demi-jointure droite, l’équi-jointure :
Table1 FULL OUTER JOIN Table2
Dans ce cas, tous les nuplets de la table1 sont affichés, quand il n’y a pas de
jointure possible, des informations inconnues ou indéterminées sont affichées dans
la partie droite du résultat. Et de façon symétrique, tous les nuplets de la table2 sont
affichés, quand il n’y a pas de jointure possibles, des informations inconnues ou
indéterminées sont affichées dans la partie gauche du résultat.
{ Q76 équi-jointure entre anc_cli et ventes }
SELECT *
FROM anc_cli FULL OUTER JOIN ventes
ON code_cli = c_cli
Réponse (extrait):
4.4.1.5.5. Autres jointures
SQL comporte deux autres types de jointures :

1 - le CROSS JOIN qui correspond à une jointure non contrainte. Par exemple une
commande NATURAL JOIN dans laquelle les tables n’ont pas de noms de colonnes
communs se transforme en un CROSS JOIN. C’est l’équivalent d’un Produit
cartésien !
{ Q77 Cross join entre anciens clients et ventes }
SELECT *
FROM anc_cli CROSS JOIN ventes
Réponse (extrait):
2 – l’UNION JOIN qui provoque une union entre toutes les colonnes des deux
tables. Des valeurs inconnues ou indéterminées sont affichées en correspondance
des lignes de chacune des deux tables.
{ Q78 Union join entre anciens clients et ventes }
SELECT *
FROM anc_cli UNION JOIN ventes
Réponse (extrait):

4.4.2. Les tables virtuelles ou ALIAS
Dans un chapitre précédent, nous avons vu qu’il était possible de renommer un

attribut dans une requête. SQL dispose alors de deux noms différents pour un
même attribut : un nom réel (celui qui correspond à la description de la table dans le
système) et un nom que l’on pourrait qualifié de virtuel.
Or, il existe des situations où l’on doit pouvoir disposer de deux exemplaire de la
même table dans une requête. Cela est possible en utilisant la technique des ALIAS.
Pour les attributs, on gère les ALIAS dans le SELECT, pour une table, dans le
FROM. Comme pour les attributs, deux formalismes sont possibles :
1 – Génération d’un ALIAS de table avec un espace entre le nom de la table et

l’alias :
FROM Table1 Alias1, Table2 Alias2
2 – Génération d ‘un ALIAS avec le mot réservé AS
FROM Table1 AS Alias1, Table2 AS Alias2
Nous allons illustrer une des utilisations possible des tables virtuelles au travers
d’un exemple :
Quels sont les produits qui sont fabriqués à la fois en Gironde (33) et en Mayenne
(53) ? Une requête intuitive pourrait être:

{ Q79 produits fabriqués à la fois en Gironde (33) et en Mayenne (53) }
SELECT c_prod
FROM fabric
WHERE
Dept = ’33’
AND
Dept = '53'
Réponse:
Remarque: c'est le langage naturel (en Gironde et en Mayenne) qui nous a conduit
à construire la requête de cette façon là. En réalité, son échec est parfaitement
logique car l'attribut "dept" ne peut pas, en même temps, être égal à 33 et à 53 !
Si une réponse existe, elle peut être mise en évidence en associant tous les nuplets
de FABRIC à tous les nuplet de cette même table. Donc, en générant un produit
cartésien de la table FABRIC sur elle-même.
{ Q80 Produit cartésien de la table Fabric sur elle même par génération des tables
virtuelles f1 et f2 }
SELECT *
FROM fabric AS f1, fabric AS f2
Réponse (extrait – voir le détail ci-dessous ):

F1 → DATE C_PROD DEPT DEFAUTS QUANT DATE C_PROD DEPT DEFAUTS QUANT ← F2
-------- ------ ---- ------- ----- -------- ------ ---- ------- -----
02/07/87 GC 53 12 15 02/07/87 GC 53 12 15
02/07/87 GC 53 12 15 02/01/87 GC 53 0 55
02/07/87 GC 53 12 15 02/02/87 NM 75 17 93
02/07/87 GC 53 12 15 02/02/87 DD 53 25
02/07/87 GC 53 12 15 02/03/87 DD 33 22 46
02/07/87 GC 53 12 15 02/02/87 NM 33 15 25
02/07/87 GC 53 12 15 02/04/87 DD 44 12 25
02/07/87 GC 53 12 15 02/04/87 DD 75 15 25
02/07/87 GC 53 12 15 02/06/87 GC 44 4 43
02/01/87 GC 53 0 55 02/07/87 GC 53 12 15
02/01/87 GC 53 0 55 02/01/87 GC 53 0 55
02/01/87 GC 53 0 55 02/02/87 NM 75 17 93
02/01/87 GC 53 0 55 02/02/87 DD 53 25
02/01/87 GC 53 0 55 02/03/87 DD 33 22 46
02/01/87 GC 53 0 55 02/02/87 NM 33 15 25
02/01/87 GC 53 0 55 02/04/87 DD 44 12 25
02/01/87 GC 53 0 55 02/04/87 DD 75 15 25
02/01/87 GC 53 0 55 02/06/87 GC 44 4 43
02/02/87 NM 75 17 93 02/07/87 GC 53 12 15
02/02/87 NM 75 17 93 02/01/87 GC 53 0 55
02/02/87 NM 75 17 93 02/02/87 NM 75 17 93
02/02/87 NM 75 17 93 02/02/87 DD 53 25
02/02/87 NM 75 17 93 02/03/87 DD 33 22 46
02/02/87 NM 75 17 93 02/02/87 NM 33 15 25
02/02/87 NM 75 17 93 02/04/87 DD 44 12 25
02/02/87 NM 75 17 93 02/04/87 DD 75 15 25
02/02/87 NM 75 17 93 02/06/87 GC 44 4 43
02/02/87 DD 53 25 02/07/87 GC 53 12 15
02/02/87 DD 53 25 02/01/87 GC 53 0 55
02/02/87 DD 53 25 02/02/87 NM 75 17 93
02/02/87 DD 53 25 02/02/87 DD 53 25
→ 02/02/87 DD 53 25 02/03/87 DD 33 22 46
02/02/87 DD 53 25 02/02/87 NM 33 15 25
02/02/87 DD 53 25 02/04/87 DD 44 12 25
02/02/87 DD 53 25 02/04/87 DD 75 15 25
02/02/87 DD 53 25 02/06/87 GC 44 4 43
02/03/87 DD 33 22 46 02/07/87 GC 53 12 15
02/03/87 DD 33 22 46 02/01/87 GC 53 0 55
02/03/87 DD 33 22 46 02/02/87 NM 75 17 93
→ 02/03/87 DD 33 22 46 02/02/87 DD 53 25
02/03/87 DD 33 22 46 02/03/87 DD 33 22 46
02/03/87 DD 33 22 46 02/02/87 NM 33 15 25
02/03/87 DD 33 22 46 02/04/87 DD 44 12 25
02/03/87 DD 33 22 46 02/04/87 DD 75 15 25
02/03/87 DD 33 22 46 02/06/87 GC 44 4 43
02/02/87 NM 33 15 25 02/07/87 GC 53 12 15
02/02/87 NM 33 15 25 02/01/87 GC 53 0 55
02/02/87 NM 33 15 25 02/02/87 NM 75 17 93
02/02/87 NM 33 15 25 02/02/87 DD 53 25
02/02/87 NM 33 15 25 02/03/87 DD 33 22 46
02/02/87 NM 33 15 25 02/02/87 NM 33 15 25
02/02/87 NM 33 15 25 02/04/87 DD 44 12 25
02/02/87 NM 33 15 25 02/04/87 DD 75 15 25
02/02/87 NM 33 15 25 02/06/87 GC 44 4 43
02/04/87 DD 44 12 25 02/07/87 GC 53 12 15
02/04/87 DD 44 12 25 02/01/87 GC 53 0 55
02/04/87 DD 44 12 25 02/02/87 NM 75 17 93
02/04/87 DD 44 12 25 02/02/87 DD 53 25
02/04/87 DD 44 12 25 02/03/87 DD 33 22 46
02/04/87 DD 44 12 25 02/02/87 NM 33 15 25
02/04/87 DD 44 12 25 02/04/87 DD 44 12 25
02/04/87 DD 44 12 25 02/04/87 DD 75 15 25
02/04/87 DD 44 12 25 02/06/87 GC 44 4 43
02/04/87 DD 75 15 25 02/07/87 GC 53 12 15
02/04/87 DD 75 15 25 02/01/87 GC 53 0 55
02/04/87 DD 75 15 25 02/02/87 NM 75 17 93
02/04/87 DD 75 15 25 02/02/87 DD 53 25
02/04/87 DD 75 15 25 02/03/87 DD 33 22 46
…/…
02/06/87 GC 44 4 43 02/03/87 DD 33 22 46
02/06/87 GC 44 4 43 02/02/87 NM 33 15 25
02/06/87 GC 44 4 43 02/04/87 DD 44 12 25
02/06/87 GC 44 4 43 02/04/87 DD 75 15 25

Le produit cartésien a permis de mettre en évidence qu'il existe bien des produits
qui sont fabriqués en Gironde et en Mayenne :
→ 02/02/87 DD 53 25 02/03/87 DD 33 22 46
→ 02/03/87 DD 33 22 46 02/02/87 DD 53 25
Il est donc nécessaire de contraindre le Produit cartésien pour obtenir le résultat que
nous venons de mettre en évidence de façon intuitive.
{ Q81 produits fabriqués à la fois en Gironde (33) et en Mayenne (53) (suite)}
SELECT DISTINCT (f1.c_prod)

FROM fabric AS f1, fabric AS f2 { génération des tables virtuelles }
WHERE
f1.c_prod=f2.c_prod { contrainte de jointure }
AND
f1.dept =’53’
AND
f2.dept =’33’
Réponse:
Remarque: on peut écrire:
f1.dept =’53’
AND
f2.dept =’33’
car f1.dept et f2.dept sont des attributs de deux tables différentes. Ils peuvent donc
en même temps être égal à 53 pour l'un et à 33 pour l'autre.
{ Q81bis Codes des produits vendus à la fois dans la succursale 1A et dans la

succursale 1B }
4.5. Les VUES (Views)
Les vues sont dérivées des tables, contrairement à une table, une vue ne contient
pas de données, elle n'a pas d'existence permanente. Elle ne peut donc être utilisée
pour réaliser des mises à jour ou des destructions de données. Chaque fois qu'une
vue est utilisée dans une requête, la table correspondant a cette vue est créée. Il ne
s'agit pas de tables virtuelles. Les tables virtuelles sont des copies, des "clones" de
tables existantes. Elles ont obligatoirement la même structure et les mêmes données
que les tables dont elles sont issues.
Une vue ne correspond pas obligatoirement à une table dans sa totalité. Elle peut
être composée d'éléments d'une tables ( par projection ou sélection) ou de plusieurs
tables ( par jointure).
En général on crée une vue pour deux raisons:
1. Afin de réaliser des accès restreints. L'utilisateur ne voit qu'une partie des
données de la table dont est issue la vue
2. Améliorer l'interface utilisateur en construisant des vues qui sont des jointures
entre plusieurs tables. Par exemple on renseigne une table issue d'une association
en insérant les libellés correspondant aux clés présentes dans la table "association"
4.5.1. Création de vues par restrictions d'informations
Voici la commande de création d'une vue client2 avec une restriction sur l’attribut
"taux"6
CREATE VIEW client2 AS

SELECT code_cli, nom, dept
FROM cli
{ Q83 Affichage de toutes les colonnes et de toutes les lignes de la vue client2 }
SELECT *
FROM client2
Réponse:
6
Dans les requêtes de création des vues, les commentaires {…} ne sont pas autorisés!
Création d'une vue en renommant les colonnes
CREATE VIEW client3 (cc, nc, dc) AS

SELECT code_cli, nom, dept
FROM cli
Remarque: Les attributs sont renommés terme à terme:
Code_cli à cc
Nom à nc
Dept à dc
{ Q85 Afficher les colonnes en utilisant les noms créés pour la vue }
SELECT cc, nc
FROM client3
WHERE cc = 'AA'
Réponse:
4.5.2. Création de vues par adjonctions d'informations
Création d'une vue à partir d'une jointure entre deux tables
CREATE VIEW prodfabr AS

SELECT code_pr, libelle, dept, defauts
FROM prod, fabric
WHERE code_pr = c_prod
{ Q86 Afficher le contenu de la vue prodfabr }
SELECT *
FROM prodfabr
Réponse:

Création d'une vue avec des données calculées concernant la moyenne des
défauts et avec une colonne renommée
CREATE VIEW fab_moy AS

SELECT dept, c_prod, AVG(defauts) AS MOY_DEF
FROM fabric
GROUP BY dept, c_prod
{ Q88 Requête sur la vue fab_moy }
SELECT *
FROM fab_moy
Réponse:

4.6. Les Sous-requêtes
Jusqu'à présent, toutes les opérations de comparaisons ont été effectuées avec des
noms de colonnes ou des valeurs selon l'un des modèles suivants:
Attribut θ Valeur ( selection )

Attribut1 θ Attribut2 (clause de jointure)
avec θ ∈ {<, >, <=, >=, =, <>}
Or, il existe des situations où la partie droite de l'opérateur θ n'est pas encore
connue au moment de la construction de la requête. Dans ces cas, la partie droite
peut être déclarée comme une requête séparée (indépendante) que l'on appelle
"sous-requête".
Cette "sous-requête" est exécutée en premier et les données générées par son
exécution sont transmises à la requête dite "principale" qui, a son tour utilisera ces
résultats pour son exécution.
Dans une requête, l'ensemble constitué par les mots réservés :
SELECT…
FROM…
WHERE …
et des noms de tables et d'attributs correspondants constitue le BLOC de

QUALIFICATION.
Dans un système de sous requêtes simples, les blocs de qualifications sont
HOMOGENES c'est à dire que tous les attributs cités dans le SELECT et dans le
WHERE appartiennent aux tables citées dans le FROM.
Forme générique de la sous-requête:
SELECT T1.At1, T1.At2, T1.Atn…..

FROM T1
WHERE T1.Atx θ
(SELECT T2.Aty
FROM T2
WHERE T2.At……..);
Remarques:
1 - les 2 blocs de qualification sont homogènes, dans le bloc de qualification de la

requête principale autour de T1, dans la sous-requête autour de T2.
2 - de part et d'autre de l'opérateur θ les attributs cités doivent appartenir au même
domaine (ici, T1.Atx et T2.Aty).
3 - dans une requête construite avec une ou des sous-requêtes, on ne peut afficher
que les attributs de la requête principale.
4.6.1. Sous-requêtes simples
{ Q89 Sous-requêtes simples : informations de VENTES sur le client "Picasso" }

SELECT *
FROM ventes
WHERE c_cli =
(SELECT code_cli
FROM cli
WHERE nom = 'Picasso')
Réponse:
Nous allons à présent décomposer l’exécution de cette requête pour mettre en

évidence les trois phases distinctes :
• exécution de la sous-requête
• transmission du résultat à la principale
• exécution de la principale
Pour cela, nous utilisons les caractères réservés de commentaires ‘{… }’, afin de
« geler » l’exécution de certaines parties !
{ Q89_bis Sous-requêtes simples : informations de VENTES sur le client "Picasso" }
{ SELECT * Requête principale « gelée » par les

FROM ventes signes {…}
WHERE c_cli = }
SELECT code_cli Sous-requête sans les parenthèses.
FROM cli
WHERE nom = 'Picasso'
7
Il s'agit d'une opération d'exécution interne qui ne modifie pas le texte de la requête elle-même!
Réponse:
Ce qui correspond à la valeur renvoyée par la sous-requête. Le moteur SQL

va substituer de façon interne8 le résultat de la sous-requête à la requête
principale. On obtient donc une configuration du type:
SELECT *
FROM ventes
WHERE c_cli = "AA"
qui donnera les informations sur les ventes correspondant au client dont le code est
"AA".
{ Q90 Sous-requêtes simples : Clients ayant acheté plus de produits MW en un seul

achat que le total acheté par le client BB }
SELECT c_cli, quant

FROM ventes
WHERE
c_prod = 'MW'
AND
quant >
( SELECT SUM(quant)
FROM ventes
WHERE
c_cli = 'BB'
AND
c_prod = 'MW' )
Réponse:
8
Il s'agit d'une opération d'exécution interne qui ne modifie pas le texte de la requête elle-même!
Remarque: De telles questions peuvent désemparer les utilisateurs! En réalité, il
suffit pour les résoudre de les découper en parties élémentaires et en commençant
par la fin.
1 - le total de produit MW acheté par le client BB correspond à une requête

relativement classique:
SELECT SUM(quant)
FROM ventes
WHERE
c_cli = 'BB'
AND
c_prod = 'MW'
elle délivre le résultat intermédiaire:
2 - nous recherchons donc les clients pour lesquels une vente de produit MW a été
réalisée avec une quantité supérieure à la valeur renvoyée par la sous-requête.
SELECT c_cli, quant

FROM ventes
WHERE
c_prod = 'MW'
AND
quant > (la valeur renvoyée par la sous-requête : 41)

4.6.2. Sous-requêtes et opérateurs ensemblistes
Jusqu’à présent, la sous-requête renvoie une valeur unique. Or, il existe des
situations où la sous requête va renvoyer un ensemble de valeurs. Dès lors,
l’opérateur de comparaison entre sous-requête et requête principale doit être
ensembliste ( IN, NOT IN, θ ANY, θ ALL ).
Bien entendu, il appartient à l'utilisateur d’anticiper ces situations!
{ Q91 Produits achetés par les clients de Paris }

FROM ventes
WHERE c_cli IN
(SELECT code_cli
FROM cli
WHERE dept ='75')
Réponse:
{ Q92 Produits fabriqués à la fois dans la Mayenne et dans la Gironde }
SELECT c_prod
FROM fabric
WHERE
dept = '53'
AND c_prod IN
(SELECT c_prod
FROM fabric
WHERE dept ='33')
Réponse:
Remarque: C'est une autre façon de résoudre la question n° 79. En effet, la

technique des tables virtuelles permettait au travers d'une jointure entre la table
virtuelle f1 et la table virtuelle f2 de trouver les produits fabriqués en Gironde
(f1.dept = "33") , et ceux fabriqués en Mayenne (f2.dept = "53") en permettant de
relier ces deux expressions par un AND.
Dans la requête ci-dessus, on visite la table FABRIC dans la requête principale pour
trouver l'ensemble des produits fabriqués en Mayenne. La sous requête renvoie
l'ensemble des produits fabriqués en Gironde. La ligne de commande:
…/…
AND c_prod IN
…/…
permet de trouver l'intersection entre ces deux ensembles.
{ Q93 Produits qui ne sont fabriqués ni à Paris, ni en Gironde }
SELECT *
FROM fabric
WHERE c_prod NOT IN
( SELECT DISTINCT c_prod
FROM fabric
WHERE
dept ='75'
OR
dept ='33')
Réponse:

{ Q94 Produits vendus qui ne sont pas fabriqués en Loire-Atlantique }

FROM ventes
WHERE c_prod NOT IN
( SELECT c_prod
FROM fabric
WHERE dept = '44')
Réponse:
On peut essayer de résoudre cette question d’une façon différente, en inversant les
opérateurs :
• NOT IN devient IN
• dept = '44' devient dept <> '44'
{ Q94_bis Produits vendus qui ne sont pas fabriqués en Loire-Atlantique }

FROM ventes
WHERE c_prod IN
(SELECT c_prod
FROM fabric
WHERE dept <> '44')
Réponse:

Comparer avec la réponse précédente. Pourquoi est-elle différente?
4.6.3. Sous-requêtes emboîtées
Une sous-requête peut elle même contenir une autre sous-requête. Le niveau
d’emboîtement autorisé dépend des systèmes sur lesquels on travaille. Avec
MicroSQL, il est égal à huit.
Dans le cas des sous-requêtes emboîtées, la fermeture des parenthèses se fait à la
fin de la requête.
{ Q95 Clients qui ont acheté des produits à des vendeurs travaillant sous les
ordres de Jean-Paul Sartre }
SELECT DISTINCT c_cli { Numéros des Clients ayant acheté à des vendeurs }
FROM ventes { ayant ces Numéros d'Employés }
WHERE no_vend IN
(SELECT no_emp { Numéros des Employés dont le N° de directeur }
FROM emp { est celui de Sartre }
WHERE no_dir =
(SELECT no_emp { Numéro d'employé de Sartre }
FROM emp
WHERE nom = 'Sartre Jean Paul'))
Réponse:
Remarque : Dans la plupart des cas, il est possible de résoudre le problème

également par jointure. Voici par exemple, une alternative à la requête 96 :
SELECT DISTINCT c_cli

FROM ventes, emp AS E1, emp AS E2
WHERE
E1.nom = 'Sartre Jean Paul' { trouver le directeur dans E1 }
AND
E1.no_emp = E2.no_dir { le n° d’employé du directeur dans E1 }
AND { est le n° de directeur des employés dans E2 }
No_vend = E2.no_emp { n° des vendeurs ayant E2. no_dir comme directeur }
Réponse:

Ici, le problème se complique du fait qu’il est nécessaire de visiter deux fois la table
des employés. Une fois pour traiter le cas du directeur ('Sartre Jean Paul'), une
autre fois pour traiter le cas des vendeurs. La technique employée ici est celle des
tables virtuelles.
Si les deux techniques sont possibles ( requêtes emboîtées ou jointures), quelles

sont les avantages et les inconvénients de chacune :
Jointure :
AVANTAGES :
• Elle permet l’affichage des tous les attributs de toutes les tables participant à la
requête
• Elles est transposable en QBE (Query By Example)
INCONVENIENTS :
• Son coût est élevé ( mémoire et processeur )

• Elle est plus lente en exécution que son équivalent en requête emboîtée
Requête emboîtée :
AVANTAGES :
• Son coût ( mémoire et processeur ) est plus faible que la jointure

• Elle est plus rapide en exécution
• Pour les deux raisons précédentes : elle est mieux adaptée
• à un environnement de type Client/ Serveur
• à de grandes navigations dans une base de données ( plus de 10 tables)
INCONVENIENTS :
• On ne peut afficher que les attributs traités dans l a requête principale

• La gestion du système de parenthèses peut être source d’erreurs
{ Q96 Clients ayant acheté des produits à des vendeurs qui travaillent
pour le directeur de la succursale 2A }
{ Q97 Idem Q96 mais par jointure }

{ Q98 Noms des produits ayant un pourcentage de défauts supérieur aux Produits
ayant les pourcentages de défauts les plus élevés de tous ceux qui sont fabriqués à
Paris }
4.6.4. Sous-requêtes multiples
Une sous-requête peut être associée à une clause ordinaire de sélection à l’aide
d’un des opérateurs logiques (AND, OR, NOT)
{ Q99 Produits vendus par une succursale en Loire-Atlantique

où la quantité achetée est supérieure à 25 }
SELECT DISTINCT c_prod, quant

FROM ventes
WHERE c_succ IN
( SELECT code_succ
FROM succ
WHERE dept = '44')
AND quant > 25
Réponse:
On peut de la même façon associer deux (ou plus) sous-requêtes. Ici, il n’y a pas
d’emboîtement des sous-requêtes entre elles. Le système des parenthèses est donc
différent de celui des sous-requêtes emboîtées. Chaque sous requête « ouverte »
est aussitôt « fermée ».
{ Q100 Codes des produits vendus par une succursale de Vendée (85) ou achetés
par un client de Loire-Atlantique (44)}

FROM ventes
WHERE c_succ IN

(SELECT code_succ
FROM succ
WHERE dept = ’85’)
OR c_cli IN
(SELECT code_cli
FROM cli
WHERE dept = ‘44’)
Réponse:
{ Q101 Codes des produits vendus par une succursale de Vendée (85) et achetés
par un client de Loire-Atlantique (44)}
{ Q102 Codes des produits vendus par une succursale de Loire Atlantique et
achetés par un client de ce département}
4.7. Les sous-requêtes à références externes

4.7.1. Présentation d'un exemple
{ Q103 Sous-requêtes simples :Liste des ventes pour lesquelles la quantité est
supérieure à la moyenne des quantités vendues }
SELECT *
FROM ventes
WHERE quant >
(SELECT AVG(quant)
FROM ventes)
Réponse:

Dans cet exemple, nous sommes dans le cas d’une sous-requête classique.
La sous-requête calcule la moyenne des quantités vendues pour l’ensemble des
ventes. Ensuite, l’ensemble des valeurs de la colonne des quantités est comparé à
la valeur renvoyée par la sous-requête. Seules les valeurs supérieures à cette
moyenne seront retenues dans la requête principale.
Cependant, il existe des situations où la comparaison doit être effectuée, non pas
par rapport à la moyenne globale des ventes, mais par rapport à la moyenne des
ventes concernant chaque client. La question posée devient:
{ Liste des ventes pour lesquelles la quantité est supérieure à la moyenne des
quantités vendues pour chaque client }
Donc, pour chaque ligne de la table des ventes, il faut comparer la quantité vendue
au client considéré, à la moyenne des quantités de produits qui ont été vendues à
ce même client. Il est donc nécessaire, pour chaque ligne de la table des ventes
(donc pour chaque vente) de parcourir cette même table afin de pouvoir calculer la
moyenne des ventes pour le client considéré.
Pour cela, il faut mettre en œuvre une sous requête qui, pour chaque ligne traitée
dans la table des ventes, c'est à dire pour chaque client, va réaliser ce calcul de
moyenne. La quantité vendue sera comparée à la valeur renvoyée par cette sous-
requête.
Pour la ligne suivante, c'est à dire pour la vente suivante, le processus sera répété.
Il faut donc mettre en place un processus d'aller et retour entre requête principale et
sous-requête, autant de fois qu'il y a de lignes dans la tables des ventes. Ceci est
réalisé, par la présence, dans la sous-requête, d'une référence externe.
Les sous-requête simples étaient exécutées en une fois, leur résultat était transmis à
la principale qui s'exécutait à son tour et renvoyait le résultat définitif. A l'inverse, les
sous-requêtes à référence externe sont exécutées autant de fois qu'il y a de
valeurs de substitution de la référence externe dans la table traitée par la requête
principale. Dans ce cas, le bloc de qualification de la sous requête n'est pas
homogène. On cite dans le WHERE l'attribut d'une table qui n'est pas citée dans le
FROM.
{ Q104 Sous-requêtes à références externes : Liste des ventes pour lesquelles la

quantité est supérieure à la moyenne des quantités vendues pour chaque client }

SELECT *
FROM ventes ventes1 { table virtuelle }
WHERE quant >
(SELECT AVG(quant)
FROM ventes
WHERE ventes.c_cli = ventes1.c_cli) { référence externe }
Réponse:
4.7.2. Simulation de fonctionnement
1 - L'exécution de la requête principale provoque l'acquisition de la première ligne

de la table virtuelle ventes1
SELECT *
FROM ventes ventes1
WHERE quant >
…/…
DATE C_SUCC C_CLI NO_VEND C_PROD QUANT

-------- ------ ----- ------- ------ -----
04/01/87 1A ZZ 11 MW 23
2 - La référence externe de la sous-requête permet la transmission du code client de

la table ventes1 et l'exécution du calcul de la moyenne des quantités achetées pour
ce client. Ainsi, de façon interne, la sous-requête à référence externe devient une
sous-requête simple par substitution9 du code client à l'attribut ventes1.c_cli :
ventes.c_cli = ventes1.c_cli ⇒ ventes.c_cli = "ZZ"
Voici la représentation que l'on peut en faire:
SELECT *
FROM ventes ventes1
9
Dans toute cette simulation, nous représentons par du code SQL les processus de substitutions qui
sont exécutés de façon interne par le moteur SQL. Bien entendu le code de la requête n'est pas
changé!
WHERE quant >
(SELECT AVG(quant)
FROM ventes
WHERE ventes.c_cli = "ZZ")
3 - Calcul de la moyenne des quantités achetées pour le client ZZ
(SELECT AVG(quant)
FROM ventes
WHERE ventes.c_cli = "ZZ" ⇒ AVG(quant)
--------------
44
4 - Transmission du résultat de la sous requête à la requête principale
SELECT *
FROM ventes ventes1
WHERE quant > 44;
5 - Exécution de la requête principale
SELECT *
FROM ventes ventes1
WHERE 23 > 44 ⇒ FAUX
La ligne de la table ventes1

-------- ------ ----- ------- ------ -----
04/01/87 1A ZZ 11 MW 23
qui était traitée par la requête principale, n'est pas éditée, la ligne suivante est
acquise, et ainsi de suite jusqu'à la dernière ligne.
6 - Voici la suite de la simulation pour la ligne n° 6 de la table ventes1:
Exécution de la requête principale:
SELECT *
FROM ventes ventes1
WHERE quant >
…/…

-------- ------ ----- ------- ------ -----
04/12/87 1B BB 27 MW 41
Effacement de la référence externe:
SELECT *
FROM ventes ventes1
WHERE quant >
(SELECT AVG(quant)
FROM ventes
WHERE ventes.c_cli = "BB")
Exécution de la sous-requête:
(SELECT AVG(quant)
FROM ventes
WHERE ventes.c_cli = "BB") ⇒ AVG(quant)
--------------
26
Effacement de la sous-requête:
SELECT *
FROM ventes ventes1
WHERE quant > 26
Fin de l'exécution de la requête principale:
SELECT *
FROM ventes ventes1
WHERE 41 > 26 ⇒ VRAI
Edition de la ligne de la table ventes1:

-------- ------ ----- ------- ------ -----
04/12/87 1B BB 27 MW 41
4.7.3. Forme générique des requête à références externes
SELECT T1.At1, T1.At2,…..,T1.Atn

FROM T1
WHERE T1.Atx θ
(SELECT T2.Aty
FROM T2
WHERE T1.Atv = T2.Atw)

{ Q105 Sous-requêtes à références externes : Liste des fabrications pour lesquelles
les quantités fabriquées sont supérieures à la moyenne des quantités fabriquées
4.8. Les prédicats EXISTS et NOT EXISTS

SQL dispose d’un opérateur spécial qui permet de déterminer si un résultat est
renvoyé par une sous-requête. Si, au moins une valeur est retournée, la condition
située dans le WHERE renvoie VRAI, sinon FAUX.
4.8.1. Principe de fonctionnement
{ Q106 Sous-requêtes à références externes : Nom des produits dans la table des
VENTES }
SELECT libelle
FROM prod
WHERE EXISTS
(SELECT *
FROM ventes
WHERE c_prod = code_pr)
Réponse:
Simulation:
1 - Acquisition de la première ligne de la table des produits
SELECT libelle
FROM prod
../..
CODE_PR LIBELLE
------- ---------------
MW clavier

2 - Transmission de la valeur de code_pr à la sous-requête
SELECT libelle
FROM prod
WHERE EXISTS
(SELECT *
FROM ventes
WHERE c_prod = "MW")
3 - Recherche dans la table des VENTES du code produit MW
SELECT libelle
FROM prod
WHERE EXISTS
(SELECT *
FROM ventes
WHERE c_prod = "MW") ⇒ VRAI
4 - Transmission de la valeur VRAI à la principale
SELECT libelle
FROM prod
WHERE EXISTS ⇒ VRAI
5 - Edition du libellé de produit
SELECT libelle
LIBELLE
------------
clavier
6 - Ligne suivante de la table des PRODUITS ….
4.8.2. Le contrôle d'intégrité référentielle
On peut contrôler la cohérence d'une base de données relationnelle en vérifiant que

toutes les clés présentes dans une table issue d'une association sont bien présentes
dans les tables issues des entités avec lesquelles elle est reliée.
{ Q107 Sous-requêtes à références externes : Numéros des produits dans la table

des VENTES qui n'existent pas dans la table des PRODUITS ! }
SELECT c_prod
FROM ventes
WHERE NOT EXISTS
(SELECT *
FROM prod
WHERE c_prod = code_pr)
Réponse:
{ Q108 Sous-requêtes à références externes : Numéros des clients dans la table des
VENTES qui n'existent pas dans la table des CLIENTS }
{ Q109 Sous-requêtes à références externes : Numéros des vendeurs dans la table

des VENTES qui n'existent pas dans la table des employés }
{ Q110 Sous-requêtes à références externes : Contrôle de l'intégrité référentielle de

la table FABRIC }
{ Q111 Sous-requêtes à références externes : Contrôle de l'intégrité référentielle de

la table FABRIC (suite)}
4.9. Le Quantificateur Universel FORALL (Tous les)
4.9.1. Présentation
Avec SQL, il n'existe pas de moyen de vérifier que l'on a atteint TOUS les éléments
d'une table! Par exemple, SQL ne peut pas répondre de façon directe à la question
suivante:
Quels sont les clients qui ont acheté tous les produits ?
Si l'on rapporte cette question aux trois tables qui sont nécessaires à la mise en
œuvre de la réponse ( CLI, PROD, VENTES), on peut poser la même question de la
façon suivante:
Existe-t-il un CLIENT, qui par l'intermédiaire de la table des VENTES, est en relation
avec TOUS les éléments de la table des PRODUITS?
Cependant, si SQL ne peut pas mettre en évidence que:

par l'intermédiaire de la table VENTES, il existe un élément de la table CLI qui
permet d'atteindre TOUS les éléments de la table PROD,
il sait faire l'inverse!
C'est à dire mettre en évidence que l'on atteint AUCUN élément d'une table
(réponse = ensemble VIDE).
L'opérateur EXISTS ne sait pas détecter une totalité, car il renvoie toujours VRAI
dans l'intervalle {1,TOUT}. En revanche, l'opérateur NOT EXISTS, quand il renvoie
la valeur VRAI, met en évidence un ensemble vide!
Dès lors, l'astuce consiste à transformer l'affirmation en une double négation.
Un client qui a acheté TOUS les produits est :
un client pour lequel il n'existe pas de produits pour lesquels il n'existe pas de
ventes.
D'où la requête:
{ Q112 Clients qui ont acheté TOUS les produits }
SELECT code_cli, nom

FROM cli { clients pour lesquels }
WHERE NOT EXISTS { il n'existe pas... }
(SELECT *
FROM prod { de produits pour lesquels }
WHERE NOT EXISTS { il n'existe pas... }
(SELECT *
FROM ventes { de ventes }
WHERE c_cli = code_cli
AND c_prod = code_pr))
Réponse:
4.9.2. Modèle générique
Soient trois tables A, B et C:

A C B
A1 | A2 C1 | C2 B1 | B2
___|___ ___|___ ___|___
1 | Dudule 1 | A A | chose
2 | bidule 2 | B B | engin
3 | machin 3 | D C | exemplaire
4 | truc 4 | C D | échantillon
4 | B
1 | B
2 | A
3 | C
2 | C
4 | A
2 | D Remarque:
3 | C union compatibilité: A1 <--> C1
(mêmes domaines) C2 <--> B1
(1) Eléments de la table A par lesquels on atteint TOUS les éléments de la table B
par l'intermédiaire de la table C.) Réponse: 2
SELECT A1
FROM A
WHERE NOT EXISTS
(SELECT *
FROM B
WHERE NOT EXISTS
(SELECT *
FROM C
WHERE A.A1=C.C1
AND B.B1= C.C2))
4.9.3. Simulation de fonctionnement
Dans le tableau suivant nous avons représenté dans la partie gauche, les codes de
produits en colonnes et les codes de clients en lignes. Les croix indiquent qu'un
client a acheté un produit. Dans la partie centrale, la phrase exprime dans un
formalisme proche de la structure de la requête les rapports existant entre les
clients, les produits et l'action de vente. La dernière colonne à droite exprime le
résultat obtenu.
MW GC NM DD
AA x x x x Client pour lequel il n'existe pas de Produits pour lesquels il n'existe pas de Ventes TOUS
BB x x x Client pour lequel il existe des Produits pour lesquels il n'existe pas de Ventes De UN à TOUS exclu
ZZ x x x Client pour lequel il existe des Produits pour lesquels il n'existe pas de Ventes De UN à TOUS exclu
DD x Client pour lequel il existe des Produits pour lesquels il n'existe pas de Ventes De UN à TOUS exclu
EE x Client pour lequel il existe des Produits pour lesquels il n'existe pas de Ventes De UN à TOUS exclu

FF Client pour lequel il n'existe pas de Produits pour lesquels il existe des Ventes AUCUN
TT Client pour lequel il n'existe pas de Produits pour lesquels il existe des Ventes AUCUN
HH Client pour lequel il n'existe pas de Produits pour lesquels il existe des Ventes AUCUN
-- Clients qui ont acheté TOUS les produits

---------------------------------------------------------
Le début de la requête principale permet d'obtenir la première ligne de la table des

clients:

FROM cli
CODE_CLI NOM DEPT TAUX

-------- --------------- ---- ----
AA Picasso 33 20
Au niveau suivant, on obtient la première ligne de la table des produits:
(SELECT *
FROM prod
CODE_PR LIBELLE
------- ---------------
MW clavier
Avec ces informations on entre dans la sous-requête de deuxième niveau:
(SELECT *
FROM ventes
AND c_prod = code_pr));
Les références externes sont remplacées par les valeurs provenant des deux
niveaux au dessus:
(SELECT *
FROM ventes
WHERE c_cli = AA
AND c_prod = MW));
Cette requête recherche les ventes de produit MW au client AA. Comme on peut le
voir dans la table des ventes (annexe 1), ce produit a bien été acheté par ce client.
La requête va donc renvoyer VRAI au niveau du dessus. Le NOT EXISTS
transforme le VRAI en FAUX…

(SELECT *
FROM prod à FAUX ….
… produit suivant…toujours pour le même client
CODE_PR LIBELLE
------- ---------------
GC modem
(SELECT *
FROM ventes
WHERE c_cli = AA
AND c_prod = GC));
.. et ainsi de suite. Voici présentés dans un tableau, les différentes étapes pour le
client AA.
1 - Acquisition du premier client (code_cli = "AA"):

FROM cli AA
WHERE NOT EXISTS
(SELECT *
FROM prod
WHERE NOT EXISTS
(SELECT *
FROM ventes
WHERE
c_cli = code_cli
AND
2 - Aquisition du premier produit (code_pr = "MW"):

FROM cli AA
WHERE NOT EXISTS
(SELECT *
FROM prod MW
WHERE NOT EXISTS
(SELECT *
FROM ventes
WHERE
c_cli = code_cli
AND
3 - Chargement des références externes code_cli et code_pr

FROM cli AA
WHERE NOT EXISTS
(SELECT *
FROM prod MW
WHERE NOT EXISTS
(SELECT *
FROM ventes
WHERE
c_cli = code_cli AA
AND
AND c_prod = code_pr)) MW
4 - Le client AA a acheté un produit MW, le WHERE renvoie VRAI

FROM cli AA
WHERE NOT EXISTS
(SELECT *
FROM prod MW
WHERE NOT EXISTS
(SELECT *
FROM ventes
WHERE VRAI
c_cli = code_cli AA
AND
5 - Le NOT EXISTS le transforme en FAUX

FROM cli AA
WHERE NOT EXISTS
(SELECT *
FROM prod MW
WHERE NOT EXISTS FAUX
(SELECT *
FROM ventes
WHERE VRAI

c_cli = code_cli AA
AND
6 - Traitement du produit suivant:

FROM cli AA
WHERE NOT EXISTS
(SELECT *
FROM prod MW
WHERE NOT EXISTS FAUX FAUX
(SELECT *
FROM ventes
WHERE VRAI VRAI
c_cli = code_cli AA AA
AND
AND c_prod = code_pr)) MW GC
7 -Et ainsi de suite jusqu'à la fin de la table des produits:

FROM cli AA
WHERE NOT EXISTS
(SELECT *
FROM prod MW
WHERE NOT EXISTS FAUX FAUX FAUX FAUX
(SELECT *
FROM ventes
WHERE VRAI VRAI VRAI VRAI
c_cli = code_cli AA AA AA AA
AND
AND c_prod = code_pr)) MW GC NM DD
8 - La table des produits a été entièrement parcourue, la dernière valeur calculée

par la ligne :
va renvoyée FAUX au niveau de la requête principale dont la ligne:

WHERE NOT EXISTS VRAI
va transformer la valeur FAUX en VRAI.

FROM cli AA
(SELECT *
FROM prod MW
(SELECT *
FROM ventes
AND
AND c_prod = code_pr)); MW GC NM DD
9 - Le WHERE de la requête principale étant égal à VRAI, le code client et le nom

du client sont édités par le SELECT. Picasso a acheté TOUS les produits.
SELECT code_cli, nom AA Picasso

FROM cli AA
(SELECT *
FROM prod MW
(SELECT *
FROM ventes
AND
10 - Voici maintenant l'exemple d'un échec de la requête. Le Client suivant dans la

table des client est BB. Le parcours de la table des produits va se faire de la façon
suivante:

FROM cli BB
(SELECT *
FROM prod MW
WHERE NOT EXISTS FAUX FAUX FAUX VRAI
(SELECT *
FROM ventes
WHERE VRAI VRAI VRAI FAUX
c_cli = code_cli BB BB BB BB
AND
Le client BB n'ayant pas acheté de produit DD, le WHERE de la requête contenant

les références externes (ventes) renvoie la valeur FAUX. La ligne de commande:
WHERE NOT EXISTS FAUX FAUX FAUX VRAI
de la sous-requête sur les produits le transforme en VRAI. La ligne de commande:
de la requête principale le transformera en FAUX. Le client BB n'a pas acheté TOUS

les produits. Le SELECT de la requête principale n'édite rien.
Autre forme possible de la division
SELECT c_cli
FROM ventes
GROUP BY c_cli HAVING COUNT(DISTINCT c_prod)=
(SELECT COUNT(*) FROM prod)
Trouver les libellées des questions suivantes:
{ Q113 Clients qui ……. }

FROM cli
WHERE EXISTS
(SELECT *
FROM prod
WHERE NOT EXISTS
(SELECT *
FROM ventes

FROM cli

WHERE NOT EXISTS
(SELECT *
FROM prod
WHERE EXISTS
(SELECT *
FROM ventes

FROM cli
WHERE EXISTS
(SELECT *
FROM prod
WHERE EXISTS
(SELECT *
FROM ventes
{ Q116 Clients qui ont acheté des produits qui n'existent pas }
{ Q117 Clients qui ont acheté tous les produits fabriqués en Gironde }
5. SQL : Langage de Définition des Données

5.1. Création et destruction d’une base de données
Le langage SQL contient des commandes permettant de créer, maintenir et détruire

des base de données. Avec MicroSQL, la base de données doit être définie et
chargée avant les tables qui la constitueront.
5.1.1. Création d’une base de données
Avant de réaliser cette opération, il est nécessaire de créer un répertoire et de

fournir le chemin d'accès à MicroSQL grâce à la commande [File] [Set] [Path] (3.3.2)

Sélectionner la commande [Structure] [Create]
Puis cliquer sur [Database]
La fenêtre de création s'ouvre avec le début de la commande …..

…qu'il faut compléter par le nom de la base de données. A la suite de cette
opération, la base doit être chargée par les commandes:
[File] [Load] …..
…puis sélection de la base.
5.1.2. Destruction d’une base de données

Avec MicroSQL, pour qu'une base de données puisse être détruite, il est nécessaire
qu'elle ait été préalablement chargée. Ensuite, les commandes:
[Structure][Drop] font apparaître la fenêtre suivante:
…puis…
…permettant de choisir la base qui sera détruite.
5.2. Création et destruction de tables
5.2.1. Création de tables

La commande générique de création de table est la suivante10:
CREATE TABLE nom_de_table

( définition_de_colonne [,définition_de_colonne….]
[,[nom ] CHECK (condition de recherche ) ]
[,[PRIMARY KEY (nom_de_colonne [,nom_de_colonne …])]
[, UNIQUE (nom_de_colonne [,nom_de_colonne …])]
[,[FOREIGN KEY (nom_de_colonne [,nom_de_colonne …])]
REFERENCES nom_de_table])
Où définition_de_colonne a la forme suivante:
nom_de_colonne data_type11 [(largeur_de_colonne)] | domaine

[NOT NULL][PRIMARY KEY][UNIQUE][DEFAULT LITERAL]
[[nom ] CHECK (condition de recherche )] REFERENCES nom_de_table]
De plus MicroSQL autorise la création de table en utilisant la structure d'une autre:
CREATE TABLE un_nom_de_table LIKE un_autre_nom_de_table

[NOINTEGRITY12]
5.2.2. Création des tables de la base de données Ventes
La création s'effectue avec les commandes suivantes:
[Structure] [Create]
10
Les mots réservés SQL sont en caractères gras: CREATE TABLE; les noms à l'initiative de
l'utilisateur sont en italiques: nom_de_table ; une expression est entre […] est optionnelle; les
expressions en italiques gras font l'objet d'une redéfinition: définition_de_colonne.
11
Voir 5.3
12
Les contraintes définies pour un_nom_de_table ne seront pas transmises à
un_autre_nom_de_table
MicroSql propose une fenêtre avec le début de la commande de création ….
…que l'on complète de la façon suivante:

Pour la base de données Ventes, voici l'ensemble des commandes de création des
tables. L'ordre est important, car on ne peut créer une table dans laquelle on définit
une clé étrangère que si la table correspondante existe déjà dans la base.
5.2.2.1. Tables issues d’entités
Create table emp(

no_emp character(2) not null,
nom character(25) not null,
no_dir character(2),
primary key (no_emp))
Create table depart(

no_dept character(2) not null,
nom_dept character(25) not null,
primary key (no_dept))
Create table prod(

code_pr character(2) not null,
libelle character(20) not null,
primary key (code_pr))

5.2.2.2. Tables issues d’entités comportant des clés étrangères
Create table succ(

code_succ character(2) not null,
no_dir character(2) not null,
primary key (code_succ),
foreign key (dept) references depart,
foreign key (no_dir) references emp)
Create table cli(

code_cli character(2) not null,
taux numeric(2),
dept character(2),
primary key (code_cli),
foreign key (dept) references depart)
Create table anc_cli(

code_cli character(2) not null,
taux numeric(2),
dept character(2),
primary key (code_cli),
foreign key (dept) references depart)
5.2.2.3. Tables issues d’associations
Create table fabric(

date date not null,
defauts numeric(2)
quant integer,
primary key (date, c_prod, dept))
Create table ventes(

date date not null,
c_succ character(2) not null,
c_cli character(2) not null,
no_vend character(2) not null,
quant integer,
primary key (date, c_succ, c_cli, no_vend, c_prod))
5.2.3. Destruction de table
La destruction d'une table s'effectue à l'aide des commandes suivantes:
Appel de la commande de destruction: [Structure] [Drop]
Sélection de la destruction de Table
Choix de la table à détruire

5.3. Types des données
MicroSQL supporte les types de données suivants:
Character(n) ou Char(n)
Character Varying(n) ou Varchar(n)
Date
Decimal(n) ou Dec(n)
Double Precision ou Double
Float(n)
Integer ou Int
Numeric(n)
Real
Smallint
Quand n'est pas défini par l'utilisateur, MicroSql alloue les valeurs suivantes:
Character :1
Date :8
Decimal :6
Double :12
Float :8
Integer :6
Numeric :6
Real :8
Smallint :3
5.4. Insertion de données dans une table
{ Q118 Création d'une structure de table fabric2 }
CREATE TABLE fabric2 (

date date NOT NULL,
c_prod char(2) NOT NULL ,
dept char(2) NOT NULL,
defauts numeric(2),
quant numeric(2),
UNIQUE (date,c_prod, dept)
);
Autre formalisme concernant la contrainte d'unicité
CREATE TABLE fabric2 (

date date NOT NULL UNIQUE,
c_prod char(2) NOT NULL UNIQUE,
dept char(2) NOT NULL UNIQUE,
defauts numeric(2),
quant numeric(2)
)
{ Q119 Chargement des données à partir de la table fabric }
INSERT INTO fabric2

SELECT *
FROM fabric
{ Q120 Contrôle des données }
SELECT *
FROM fabric2
Réponse:
DATE C_PROD DEPT DEFAUTS QUANT

-------- ------ ---- ------- -----
02/07/87 GC 53 12 15
02/01/87 GC 53 0 55
02/02/87 NM 75 17 93
02/02/87 DD 53 25
02/03/87 DD 33 22 46
02/02/87 NM 33 15 25
02/04/87 DD 44 12 25
02/04/87 DD 75 15 25
02/06/87 GC 44 4 43
5.5. Mise à jour des données d’une table
5.5.1. Update
{ Q121 Mise à Jour :mettre le % de défauts des produits GC à 10 }
UPDATE fabric2
SET defauts = 10
WHERE c_prod = "GC"
{ Q122 Controle des données }
SELECT *
FROM fabric2
Réponse:
-------- ------ ---- ------- -----
02/07/87 GC 53 10 15
02/01/87 GC 53 10 55
02/02/87 NM 75 17 93
02/02/87 DD 53 25
02/03/87 DD 33 22 46
02/02/87 NM 33 15 25
02/04/87 DD 44 12 25
02/04/87 DD 75 15 25
02/06/87 GC 44 10 43
{ Q123 Mise à jour des défauts et des quantités pour les productions de la Mayenne
}
UPDATE fabric2
SET defauts = 99, quant= 99
WHERE dept = "53"
SELECT *
FROM fabric2
Réponse:
-------- ------ ---- ------- -----
02/07/87 GC 53 99 99
02/01/87 GC 53 99 99
02/02/87 NM 75 17 93
02/02/87 DD 53 99 99
02/03/87 DD 33 22 46
02/02/87 NM 33 15 25
02/04/87 DD 44 12 25
02/04/87 DD 75 15 25
02/06/87 GC 44 10 43
{ Q125 Mise à jour par calcul: diviser par 3 les quantités de la Mayenne }
UPDATE fabric2
SET quant = quant / 3
WHERE dept = "53"
SELECT *
FROM fabric2
Réponse:
-------- ------ ---- ------- -----
02/07/87 GC 53 99 33
02/01/87 GC 53 99 33
02/02/87 NM 75 17 93
02/02/87 DD 53 99 33
02/03/87 DD 33 22 46
02/02/87 NM 33 15 25
02/04/87 DD 44 12 25
02/04/87 DD 75 15 25
02/06/87 GC 44 10 43

5.5.2. Delete
{ Q127 Destruction de nuplet avec une expression de recherche }
DELETE FROM fabric2

WHERE dept = "53"
SELECT *
FROM fabric2
Reponse:

-------- ------ ---- ------- -----
02/02/87 NM 75 17 93
02/03/87 DD 33 22 46
02/02/87 NM 33 15 25
02/04/87 DD 44 12 25
02/04/87 DD 75 15 25
02/06/87 GC 44 10 43
{ Q129 Destruction de TOUS les nuplets de la table fabric2 }
DELETE FROM fabric2

Annexe 1 : Contenu des tables de la base de données Ventes
Table Emp (employés)
Table Prod (Produits)
Table Succ (Succursales)

Table Cli (Clients)
Table Anc_Cli (Anciens clients)
Table Fabric (Fabrications)

Table Ventes
Table Depart (départements - extrait)

6. Manuel de référence SQL 92
6.1. ALTER TABLE
Description
Cette commande permet de modifier la définition d'une table, les modifications

permises sont les suivantes :
• ajouter une colonne,
• ajouter une contrainte d'intégrité,
• redéfinir une colonne (type de donnée, taille, valeur par défaut)
• modifier les caractéristiques de stockage ou d'autres paramètres,
• activer, désactiver une contrainte d'intégrité ou un déclencheur,
• allouer explicitement une extension de plus.
•
Syntaxe
ALTER TABLE [schema.]table
[ADD column datatype [DEFAULT expr] [column_constraint] ...
| table_constraint
| ( column datatype [DEFAULT expr] [column_constraint] ...
| table_constraint
[, column datatype [DEFAULT expr] [column_constraint] ...
| table_constraint ] ... ) ]
[MODIFY column [datatype] [DEFAULT expr] [column_constraint] ...
| (column [datatype] [DEFAULT expr] [column_constraint] ...
[, column datatype [DEFAULT expr] [column_constraint] ...] ...) ]
[PCTFREE integer] [PCTUSED integer]
[INITRANS integer] [MAXTRANS integer]
[STORAGE storage_clause]
[DROP drop_clause] ...
[ALLOCATE EXTENT [( [SIZE integer [K|M] ]
[DATAFILE 'filename']

[INSTANCE integer] )]
[ ENABLE enable_clause
| DISABLE disable_clause ] ...
schema
est le nom du schéma contenant la table. Le schéma par défaut est celui de l'utilisateur qui
exécute la requête.
table
est le nom de la table qui sera modifiée.

ADD
ajoute une colonne ou une contrainte d'intégrité.

MODIFY
column
datatype
DEFAULT
column_constraint
table_constraint
PCTFREE, PCTUSED, INITRANS, MAXTRANS
STORAGE
DROP
ALLOCATE EXTENT
Alloue explicitement une nouvelle extension pour la table.
ENABLE
Active une contrainte d'intégrité ou tous les triggers associés à la table.

DISABLE
Désactive une contrainte d'intégrité ou tous les triggers associés à la table.
Les contraintes d'intégrité spécifiées dans ces clauses doivent avoir été définies
auparavant. On peut aussi activer ou désactiver des contraintes d'intégrité en
utilisant les paramètre ENABLE et DISABLE de la clause CONSTRAINT. Quand on définit
une contrainte d'intégrité elle est activée par défaut.
Prérequis
Pour pouvoir modifier la définition d'une il faut soit être propriétaire de cette table,
soit avoir le privilège ALTER TABLE sur cette table.

le privilège ALTER ANY TABLE permet de modifier la définition de n'importe quelle
table appartenant à n'importe quel utilisateur.
Références croisées
CONSTRAINT, CREATE TABLE, DROP TABLE
6.2. CONSTRAINT
Description
Cette clause permet de définir des contraintes d'intégrité. Une contrainte d'intégrité
est une règle restreignant les valeurs contenues dans une ou plusieurs colonnes
d'une table.
Syntaxe
Column constraint:
[CONSTRAINT constraint]
[NOT] NULL
| UNIQUE | PRIMARY KEY
| REFERENCES [schema.]table [(column)]
[ON DELETE CASCADE]
| CHECK (condition)
[ USING INDEX [PCTFREE integer]
[TABLESPACE tablespace]
[STORAGE storage_clause] ]
[ EXCEPTIONS INTO [schema.]table
| DISABLE
Table constraint:
[CONSTRAINT constraint]
UNIQUE | PRIMARY KEY (column [,column] ...)
| FOREIGN KEY (column [,column] ...)
REFERENCES [schema.]table [(column [,column] ...)]
[ON DELETE CASCADE]
| CHECK (condition)
[ USING INDEX [PCTFREE integer]
[STORAGE storage_clause] ]
[ EXCEPTIONS INTO [schema.]table
| DISABLE
CONSTRAINT
NULL
précise que la colonne peut contenir des valeurs NULL.
NOT NULL
précise que la colonne ne peut pas contenir des valeurs NULL.

UNIQUE
PRIMARY KEY
FOREIGN KEY
REFERENCES
ON DELETE CASCADE
CHECK
USING INDEX
EXCEPTIONS INTO
DISABLE
Prérequis
Les clauses CONSTRAINT peuvent apparaître dans les commandes CREATE TABLE ou
ALTER TABLE. Pour définir une contrainte d'intégrité il faut avoir les privilèges
nécessaires pour effectuer l'une ou l'autre de ces commandes. Définir des
contraintes d'intégrité peut nécessiter des privilèges en plus qui dépendent du type
de la contrainte.
ALTER TABLE , CREATE TABLE
6.3. CREATE CLUSTER
Description
Cette commande permet de créer un cluster. Un cluster est une structure de

stockage qui contient une ou plusieurs tables ayant une ou plusieurs colonnes en
commun.
Syntaxe
CREATE CLUSTER [schema.]cluster
(column datatype [,column datatype] ... )
[PCTUSED integer] [PCTFREE integer]
[SIZE integer [K|M] ]

[INDEX
| [HASH IS column] HASHKEYS integer]
where:
schema
est le nom du schéma contenant le cluster. Le schéma par défaut est celui de l'utilisateur qui
cluster
est le nom du cluster à créer.

column
est le nom d'une colonne de la clé du cluster.

datatype
PCTUSED
PCTFREE
précise le pourcentage de place laissée libre dans les blocs du clusters à la création du cluster
l'index.
INITRANS
MAXTRANS
SIZE
TABLESPACE
specifies the tablespace in which the cluster is created.
STORAGE
specifies how data blocks are allocated to the cluster.
INDEX
HASH IS
HASHKEYS
Prérequis
Pour pouvoir créer un cluster dans son propre schéma, il faut avoir le privilège
CREATE CLUSTER. Pour pouvoir créer un cluster dans n'importe quel schéma il faut
avoir le privilège CREATE ANY CLUSTER, de plus le propriétaire du schéma doit avoir
assez d'espace libre dans la tablespace devant contenir le cluster ou le privilège
UNLIMITED TABLESPACE.
CREATE TABLE

6.4. CREATE TABLE
Description
Cette commande permet de créer une table.
Syntaxe
CREATE TABLE [schema.]table
( column datatype [DEFAULT expr] [column_constraint] ...
| table_constraint
[, column datatype [DEFAULT expr] [column_constraint] ...
| table_constraint ]...)
[ [PCTFREE integer] [PCTUSED integer]
| [CLUSTER cluster (column [, column]...)] ]
[ ENABLE enable_clause
| DISABLE disable_clause ] ...
[AS subquery]
schema
est le nom du schéma qui contiendra la table. Le schéma par défaut est celui de l'utilisateur qui
table
est le nom de la table à créer.

column
est le nom d'une colonne de la table. Le nombre de colonnes possibles dans une table est
compris entre 1 et 254.
datatype
est le type de la colonne.

DEFAULT

spécifie une valeur qui sera affectée à cette colonne si, lors d'un INSERT, one ne lui en précise
pas.
column_constraint
est une contrainte d'intégrité qui fait partie de la définition de la colonne.

table_constraint
est une contrainte d'intégrité qui fait partie de la définition de la table.

TABLESPACE
précise la tablespace dans laquelle la table sera crée.

CLUSTER
précise que la table fera partie d'un cluster.

ENABLE
active une contrainte d'intégrité.

DISABLE
désactive une contrainte d'intégrité.
AS subquery
insère les lignes renvoyées par la sous requête dans la table, à sa création.
Prérequis
Pour pouvoir créer une table dans son propre schéma, il faut avoir le privilège
CREATE TABLE. Pour pouvoir créer une table dans le schéma d'un autre utilisateur, il
faut avoir le privilège CREATE ANY TABLE. De plus le propriétaire du schéma doit avoir
assez d'espace libre dans la tablespace devant contenir le cluster ou le privilège
UNLIMITED TABLESPACE.
6.5. CREATE VIEW

Description
Cette commande permet de définir une vue, table virtuelle, basée sur une ou
plusieurs tables ou vues.
Syntaxe
CREATE [OR REPLACE] [FORCE | NOFORCE] VIEW [schema.]view
[(alias [,alias]...)]
AS subquery
[WITH CHECK OPTION [CONSTRAINT constraint]]

OR REPLACE
recrée la vue si elle existe déjà.

FORCE
crée la vue sans s'inquiéter de l'existence de la table et des privilèges sur celle-ci.
NOFORCE
crée la vue uniquement si la table existe et si le propriétaire du schéma contenant la vue possède
les privilèges adéquats sur celle-ci. C'est la valeur par défaut.
schema
est le nom du schéma qui contiendra la vue. Le schéma par défaut est celui de l'utilisateur qui
view
est le nom de la vue crée.
alias
AS subquery
WITH CHECK OPTION
CONSTRAINT
Prérequis
Pour pouvoir créer une vue dans son propre schéma, il faut avoir le privilège CREATE
VIEW. Pour pouvoir créer une vue dans le schéma d'un autre utilisateur, il faut avoir
le privilège CREATE ANY VIEW.
Le propiétaire du schéma contenant la vue doit avoir les privilèges nécessaires pour
pouvoir utiliser les commandes SELECT, INSERT, UPDATE, DELETE sur les tables ou
vues sur lesquelles la vue est basée.
CREATE TABLE, CREATE SYNONYM
6.6. DELETE
Description
Cette commande permet de supprimer des données contenues dans une table ou
dans une vue.
syntaxe
DELETE [FROM] [schema.]table | view [alias]

[WHERE condition]
schema
est le nom du schéma contenant la table ou la vue à détruire. Le schéma par défaut est celui de
l'utilisateur qui exécute la requête.
table, view
est le nom de la table ou de la vue contenant les lignes qui seront détruites. Si c'est un nom de
vue, les lignes détruites appartiennent à la table sur laquelle la vue est basée.
alias
Est un alias assigné à la table. les alias sont généralement utilisés dans des DELETE contenant
des requêtes.
WHERE
Détruit seulement les lignes satisfaisant la condition. Cette condition peut référencer la table et
peut contenir des sous-requêtes. Si cette clause est omise détruit toutes les lignes.
Prérequis
Pour détruire des lignes appartenant à une table, il faut soit être propriétaire de la
table, soit avoir le privilège DELETE sur cette table.
Le privilège DELETE ANY TABLE permet à un utilisateur de détruire des lignes se
trouvant dans n'importe quelle table, ou n'importe quelle vue basée sur une table.
DROP TABLE, TRUNCATE
6.7. DROP CLUSTER
Description
Cette commande permet de détuire un cluster de la base de données.
Syntaxe
DROP CLUSTER [schema.]cluster
[INCLUDING TABLES [CASCADE CONSTRAINTS] ]
where:
schema
est le nom du schéma contenant le cluster à détruire. Le schéma par défaut est celui de
cluster

est le nom du cluster à détruire
INCLUDING TABLES
CASCADE CONSTRAINTS
Prérequis
Le cluster doit appartenir à l'utilisateur, ou celui-ci doit avoir le privilège DROP ANY
CLUSTER.
DROP TABLE
6.8. DROP TABLE

Description
Cette commande permet de détruire une table et toutes ses données.
Syntaxe
DROP TABLE [schema.]table
[CASCADE CONSTRAINTS]
schema
est le nom du schéma contenant la table ou la vue à détruire Le schéma par défaut est celui de
table
est le nom de la table à détruire.
CASCADE CONSTRAINTS
drops all referential integrity constraints that refer to primary and unique keys in the dropped
table. If you omit this option, and such referential integrity constraints exist, ORACLE returns an
error and does not drop the table.
Prérequis
Pour pouvoir détruire une table il faut soit être propriétaire de cette table, soit avoir
le privilège DROP ANY TABLE.
6.9. DROP VIEW

Description
Cette commande permet de détruire une vue.

Syntaxe
DROP VIEW [schema.]view
schema
est le nom du schéma contenant la vue à détruire. Le schéma par défaut est celui de l'utilisateur
qui exécute la requête.
view
est le nom de la vue à détruire.

Prérequis
Pour pouvoir détruire une vue il faut soit être propriétaire de cette vue, soit avoir le
privilège DROP ANY VIEW.
CREATE TABLE, CREATE VIEW, CREATE SYNONYM
6.10. INSERT
Description
Cette commande permet d'ajouter des lignes à une table ou à une vue basée sur
une table.
Syntaxe
INSERT INTO [schema.]table | view
[ (column [, column] ...) ]
VALUES (expr [, expr] ...) | subquery
Dans lequel :
schema
est le nom du schéma contenant la table ou la vue. Le schéma par défaut est celui de l'utilisateur
qui exécute la requête.
table
view
est le nom de la table dans laquelle les lignes seront insérés. Si c'est un nom de vue qui est
précisé, les données seront insérés dans la table basée sur la vue.
column
VALUES
subquery

Prérequis
Pour pouvoir insérer des lignes dans une table il faut soit être propriétaire de cet
objet, soit avoir le privilège INSERT sur cette table.
Le privilège INSERT ANY TABLE permet d'insérer des lignes dans n'importe quelle
table appartenant à n'importe quel utilisateur.
DELETE, UPDATE
6.11. ORDER BY
Description
L'optimiseur d'interrogation d'oracle décidera dans certains cas de passer par l'index
pour sélectionner les lignes d'une table selon un certain ordre. Pour cela il faut que :
• le critère de classement soit le contenu d'une colonne indexée
• cette colonne ait l'attribut not null (obligatoire)
• la sélection porte sur toute la table (pas de WHERE)
Exemple : Le SELECT suivant utilisera l'index sur la colonne salaire si cette colonne
ne contient pas de valeurs NULL.
SELECT nom, salaire

FROM emp
ORDER BY salaire ;
6.12. RENAME
Description
Cette commande permet de renommer une table, une vue, une séquence, ou un
synonyme privé.
Syntaxe
RENAME old TO new

old
est le nom actuel de l'objet.
new
est le nouveau nom de l'objet.

Prérequis

L'objet doit appartenir à l'utilisateur courant.
CREATE SEQUENCE, CREATE SYNONYM , CREATE TABLE , CREATE VIEW
6.13. SELECT
Description
Cette commande permet de récupérer des données contenues dans une ou

plusieurs tables, vues, ou clichés.
Syntaxe
SELECT [DISTINCT | ALL]

{ *
| { [schema.]{table | view | snapshot}.* | expr [c_alias]
[, { [schema.]{table | view | snapshot}.* | expr [c_alias] }
] ... }
FROM [schema.]{table | view | snapshot} [t_alias]
[, [schema.]{table | view | snapshot} [t_alias] ] ...
[WHERE condition ]
[ [START WITH condition] CONNECT BY condition]
[GROUP BY expr [, expr] ... [HAVING condition] ]
[{UNION | UNION ALL | INTERSECT | MINUS} SELECT command ]
[ORDER BY {expr|position} [ASC | DESC] [, {expr | position} [ASC |
DESC]] ...]
[FOR UPDATE [OF [[schema.]{table | view}.]column
[, [[schema.]{table | view}.]column] ...] [NOWAIT] ]
DISTINCT
renvoie toutes les lignes sélectionnées en enlevant les doublons.
ALL
renvoie toutes les lignes sélectionnées sans enlever les doublons. C'est la valeur par défaut.
renvoie toutes les colonnes de toutes les tables, les vues et les clichés précisés dans le FROM.
table.*, view.*, snapshot.*
sélectionne toutes les colonnes de la table, de la vue ou du cliché précisé.

expr
sélectionne une expression habituellement calculée sur les valeurs des colonnes appartenant à
l'une des tables, vues, ou clichés de la clause FROM.
c_alias
la chaîne de caractères qui sert d'en-tête à la colonne (par défaut expr)
schema
est le nom du schéma contenant les tables, vues ou clichés sélectionnés. Le schéma par défaut
est celui de l'utilisateur qui exécute la requête.
table, view, snapshot
est le nom de la table, de la vue ou du cliché contenant les données sélectionnées.

t_alias
synonyme pour la table dont le nom précède, à utiliser dans le reste de la requête.
WHERE
restreint les lignes sélectionnées à celles pour lesquelles la condition est vraie. Si cette clause est
omise, toutes les lignes des tables, vues ou clichés précisés derrière le FROM sont renvoyées.
START WITH, CONNECT BY
renvoie les lignes en parcourant une arborescence.

GROUP BY
groupe les lignes sélectionnées en se basant sur la valeur de expr pour chaque ligne et renvoie
une seule ligne par groupe.
HAVING
restreint les groupes de lignes renvoyés à ceux pour lesquels la condition spécifiée est vraie.
Sans cette clause, tous les groupes sont renvoyés.
UNION, UNION ALL, INTERSECT, MINUS
Combine les lignes retournées par deux SELECT en utilisant une opération ensembliste.
ORDER BY
ordonne les lignes sélectionnées :
expr
en utilisant la valeur de expr. Cette expression est basée sur des colonnes précisées derrière le
SELECT ou sur des colonnes appartenant à des tables, vues ou clichés présents derrière le FROM.
position
donne le numéro de la colonne dans l'ordre du SELECT.
ASC, DESC
mode ascendant ou descendant. La valeur par défaut ASC.
FOR UPDATE
"locke" les lignes sélectionnées.

NO WAIT
retourne le controle à l'utilisateur si la commande SELECT essaye de bloquer une table utilisée
par un autre utilisateur.
Prérequis

Pour pouvoir sélectionner des lignes d'un objet(table, vue, cliché) il faut soit être
propriétaire de cet objet, soit avoir le privilège SELECT sur cet objet.
Le privilège SELECT ANY TABLE permet de sélectionner des lignes de n'importe quel
objet appartenant à n'importe quel utilisateur.
DELETE, UPDATE
6.14. UPDATE
Description
Cette commande permet de modifier des données contenues dans une table ou
dans une vue.
Syntaxe
UPDATE [schema.]table | view [alias]

SET (column [, column] ...) = (subquery)
| column = expr | (subquery)
[, (column [, column] ...) = (subquery)
| column = expr | (subquery) ] ...
[WHERE condition]
schema
est le nom du schéma contenant la table ou la vue à modifier. Le schéma par défaut est celui de
table, view
est le nom de la table à mettre à jour. Si c'est un nom de vue, la table mise à jour est celle sur
laquelle la vue est définie.
alias
est un alias assigné à la table. les alias sont généralement utilisés dans des UPDATE contenant
des requêtes.
column
est le nom de la colonne qui sera modifiée.

expr
est la nouvelle valeur de la colonne.

subquery
est un SELECT qui renvoie les nouvelles valeurs affectées aux colonnes correspondantes.
WHERE
restreint les lignes modifiées à celles pour lesquelles la condition est vraie. Si on omet cette
clause toutes les lignes sont modifiées.

Prérequis
Pour pouvoir modifier des lignes appartenant à une table, il faut soit être propriétaire
de cet objet, soit avoir le privilège UPDATE sur cette table.
le privilège UPDATE ANY TABLE permet de sélectionner des lignes de n'importe quel
objet appartenant à n'importe quel utilisateur.
DELETE, INSERT

1. PRÉSENTATION GÉNÉRALE ................................................................................................... 1
1.1. INTRODUCTION ......................................................................................................................... 1

1.2. SQL DANS L'ARCHITECTURE EN COUCHES DES SGBD. ........................................................... 2
1.2.1. NIVEAU EXTERNE. ................................................................................................................ 2
1.2.2. NIVEAU LOGIQUE. ................................................................................................................. 3
1.2.3. NIVEAU INTERNE. ................................................................................................................. 3
1.2.4. NIVEAU PHYSIQUE. ............................................................................................................... 3
1.3. STRUCTURE GÉNÉRALE DU LANGAGE SQL .............................................................................. 3
1.4. PRINCIPES DE BASE D'UNE BASE DE DONNÉES RELATIONNELLE ............................................. 4
2. PRÉSENTATION DE MICROSQL (MICRORESEARCH) ........................................................ 5
2.1. PRÉAMBULE .............................................................................................................................. 5

2.1.1. LES VALEURS NULL............................................................................................................. 5
2.1.2. TYPES DE DONNÉES .............................................................................................................. 5
2.1.3. CLÉS DES TABLES ................................................................................................................. 6
2.1.4. IDENTIFICATEURS EN MICROSQL.......................................................................................... 6
2.1.5. LANGAGES DE REQUÊTES ...................................................................................................... 6
2.2. INTRODUCTION À MICROSQL .................................................................................................. 7
2.2.1. L'ÉCRAN DE TRAVAIL ............................................................................................................ 7
3. BASE DE DONNÉES RELATIONNELLE "VENTES" ............................................................ 17
3.1. MODÈLE CONCEPTUEL DES DONNÉES "VENTES" ............................................................... 17

3.2. SCHÉMA RELATIONNEL "VENTES" ( CONTENU DES TABLES EN ANNEXE 1)........................ 17
3.3. LA BASE DE DONNÉES VENTES DANS MICROSQL ............................................................... 18
3.3.1. OUVERTURE D'UNE SESSION ................................................................................................ 18
3.3.2. DESCRIPTION DE LA BASE.................................................................................................... 20
3.3.3. DESCRIPTION DES TABLES ................................................................................................... 20
3.3.4. LES TABLES DU SYSTÈME MICROSQL ................................................................................. 21
4. SQL : LANGAGE DE MANIPULATION DES DONNÉES ...................................................... 23
4.1. REQUÊTES SUR UNE TABLE: .................................................................................................... 23

4.1.1. REMARQUES PRÉALABLE .................................................................................................... 23
4.1.2. PROJECTION ........................................................................................................................ 23
4.1.3. ELIMINATION DES DOUBLONS.............................................................................................. 25
4.2. LES COMMANDES DE TRIS ....................................................................................................... 26
4.3. SÉLECTION AVEC UNE CONDITION DE RECHERCHE ............................................................... 29
4.3.1. LA CLAUSE WHERE ........................................................................................................... 29
4.3.2. COMPARAISON À UNE VALEUR ............................................................................................ 30
4.3.3. VALEURS INCONNUES OU INDÉTERMINÉES .......................................................................... 32
4.3.4. EXPRESSIONS DE RECHERCHE ET OPÉRATEURS AND, OR ET NOT...................................... 34
4.3.5. LES OPÉRATEURS SPÉCIALISÉS ............................................................................................ 37
4.3.6. EXPRESSIONS NUMÉRIQUES................................................................................................. 40
4.3.7. CALCUL DE DATES ET D’HEURES ........................................................................................ 41
4.3.8. LES FONCTIONS .................................................................................................................. 42
4.3.9. FONCTIONS DE CALCUL AVEC REGROUPEMENT DES RÉSULTATS .......................................... 48
4.3.10. FONCTIONS DE CALCUL AVEC REGROUPEMENT ET SÉLECTION ........................................... 49
4.4. REQUÊTES SUR PLUSIEURS TABLES ........................................................................................ 52
4.4.1. LA JOINTURE ...................................................................................................................... 52
4.4.2. LES TABLES VIRTUELLES OU ALIAS.................................................................................... 68
4.5. LES VUES (VIEWS)................................................................................................................. 71
4.5.1. CRÉATION DE VUES PAR RESTRICTIONS D'INFORMATIONS .................................................... 72
4.5.2. CRÉATION DE VUES PAR ADJONCTIONS D'INFORMATIONS..................................................... 73
4.6. LES SOUS-REQUÊTES............................................................................................................... 75
4.6.1. SOUS-REQUÊTES SIMPLES.................................................................................................... 76
4.6.2. SOUS-REQUÊTES ET OPÉRATEURS ENSEMBLISTES ................................................................ 79
4.6.3. SOUS-REQUÊTES EMBOÎTÉES............................................................................................... 82
4.6.4. SOUS-REQUÊTES MULTIPLES ............................................................................................... 84
4.7. LES SOUS-REQUÊTES À RÉFÉRENCES EXTERNES .................................................................... 85
4.7.1. PRÉSENTATION D'UN EXEMPLE ............................................................................................ 85
4.7.2. SIMULATION DE FONCTIONNEMENT ..................................................................................... 87
4.7.3. FORME GÉNÉRIQUE DES REQUÊTE À RÉFÉRENCES EXTERNES ............................................... 89
4.8. LES PRÉDICATS EXISTS ET NOT EXISTS............................................................................ 90
4.8.1. PRINCIPE DE FONCTIONNEMENT .......................................................................................... 90
4.8.2. LE CONTRÔLE D'INTÉGRITÉ RÉFÉRENTIELLE ........................................................................ 91
4.9. LE QUANTIFICATEUR UNIVERSEL FORALL (TOUS LES) ...................................................... 92
4.9.1. PRÉSENTATION ................................................................................................................... 92
4.9.2. MODÈLE GÉNÉRIQUE........................................................................................................... 93
4.9.3. SIMULATION DE FONCTIONNEMENT ..................................................................................... 94
5. SQL : LANGAGE DE DÉFINITION DES DONNÉES ............................................................ 101
5.1. CRÉATION ET DESTRUCTION D’UNE BASE DE DONNÉES ....................................................... 101

5.1.1. CRÉATION D’UNE BASE DE DONNÉES ................................................................................. 101
5.1.2. DESTRUCTION D’UNE BASE DE DONNÉES ........................................................................... 103
5.2. CRÉATION ET DESTRUCTION DE TABLES .............................................................................. 104
5.2.1. CRÉATION DE TABLES ....................................................................................................... 104
5.2.2. CRÉATION DES TABLES DE LA BASE DE DONNÉES VENTES ................................................. 105
5.2.3. DESTRUCTION DE TABLE ................................................................................................... 109
5.3. TYPES DES DONNÉES ............................................................................................................. 110
5.4. INSERTION DE DONNÉES DANS UNE TABLE............................................................................ 110
5.5. MISE À JOUR DES DONNÉES D’UNE TABLE ............................................................................ 111
5.5.1. UPDATE ............................................................................................................................ 111
5.5.2. DELETE............................................................................................................................. 113
6. MANUEL DE RÉFÉRENCE SQL 92........................................................................................ 117
6.1. ALTER TABLE .................................................................................................................. 117

6.2. CONSTRAINT..................................................................................................................... 119
6.3. CREATE CLUSTER ........................................................................................................... 120
6.4. CREATE TABLE................................................................................................................ 122
6.5. CREATE VIEW .................................................................................................................. 123
6.6. DELETE.............................................................................................................................. 124
6.7. DROP CLUSTER................................................................................................................ 125
6.8. DROP TABLE..................................................................................................................... 126

6.9. DROP VIEW....................................................................................................................... 126
6.10. INSERT............................................................................................................................ 127
6.11. ORDER BY ....................................................................................................................... 128
6.12. RENAME............................................................................................................................ 128
6.13. SELECT............................................................................................................................ 129
6.14. UPDATE............................................................................................................................ 131

Langue

Bienvenue sur Scribd !

2 MicroSql

Transféré par

Informations du document

Description :

Date du transfert

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

2 MicroSql

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Titres liés

Cours de langage SQL/921

SQL (Stuctured Query Language) est né à la suite des travaux mathématiques de

1 - La structuration et la manipulation des données sont devenues très complexes.

1.2. SQL dans l'architecture en couches des SGBD.

Dans la phase d'analyse des systèmes d'information, on considère différents

On peut donc considérer différents niveaux de perception d'une base de données

Pour plus de simplicité, on distingue trois types d'acteurs : les administrateurs de la

Le schéma logique est l'ensemble de toutes les données pertinentes, toutes

1.2.1. Niveau externe.

Au niveau externe, les utilisateurs et développeurs d'application ont une perception

1.2.2. Niveau logique.

Traduction dans le modèle relationnel du schéma conceptuel. On précise à ce

1.2.3. Niveau interne.

1.2.4. Niveau physique.

On y précise tout ce qui dépend du matériel et du système d'exploitation. Ce niveau

Cette découpe en niveaux présente les avantages suivants :

Les applications développées sont indépendantes du niveau interne. Tout

La distinction externe/logique assure (en partie) l'indépendance entre les

La distinction logique/interne permet de modifier les optimisations d'accès aux

1.3. Structure générale du langage SQL

Les instructions essentielles SQL se répartissent en trois familles fonctionnellement

Dans le SQL interactif, le LDD (Langage de Définition de données) permet la

1.4. Principes de base d'une Base de Données relationnelle

Le terme relationnel provient de la définition mathématique d'algèbre relationnelle

Introduction à SQL/92 - Université de Nantes - Claude Belleil 4

Une base de données est un ensemble de données organisées. Les bases de

1 - toutes les données apparaissent à l'utilisateur comme étant rangées dans

2.1.1. Les valeurs NULL

2.1.2. Types de données

SQL supporte de nombreux types de données, mais à ce stade, nous considérerons

Introduction à SQL/92 - Université de Nantes - Claude Belleil 5

2.1.3. Clés des tables

2.1.4. Identificateurs en MicroSQL

2.1.5. Langages de requêtes

- définition des structures de base de données

Introduction à SQL/92 - Université de Nantes - Claude Belleil 6

2.2. Introduction à MicroSQL

2.2.1. L'écran de travail

Quand le menu est actif:

en appuyant sur la touche rapide (raccourci)

Quand le menu n'est pas actif:

en appuyant sur la touche ALT et sur la touche rapide de la commande

2.2.1.1. FILE MENU ALT F

Ces commandes couvrent un ensemble d'opérations fondamentales telles que le

2.2.1.1.1. Load Ctrl+L

Introduction à SQL/92 - Université de Nantes - Claude Belleil 7

2.2.1.1.3. Save options

2.2.1.1.6. Form Ctrl+F

Le fichier de commande, requête ou procédure ainsi choisi est supprimé du disque.

Introduction à SQL/92 - Université de Nantes - Claude Belleil 8

2.2.1.1.10. Exit Alt+F4

2.2.1.2. EDIT MENU Alt+E

Les commandes de ce menu facilitent les opérations sur le presse-papier et

2.2.1.2.1. Undo Alt+Backspace

2.2.1.2.2. Cut Shift+Delete

Le texte sélectionné est supprimé du presse-papier

2.2.1.2.3. Copy Ctrl+Insert