Chapitre I SGBD

‫الجمهورية الجزائرية الديموقراطية الشعبية‬
‫وزارة التعلـــيم العــالي والبحث العـلمي‬

École Supérieure de comptabilité ‫المدرسة العليا للمحاسبة والمالية‬
‫بقسنطينة‬
et de Finances de Constantine
‫قسم الطور الثّاني‬
Département du Second Cycle
Spécialité : ///////////
Niveau : 2ème année du Second Cycle
Module : Base de Données Avancées
Notes de cours du module Base de Données Avancées
Auteur : Dr. Asma Djellal
Année universitaire : 2022/2023

Sommaire
Sommaire .......................................................................................................................................... iii
Liste des tableaux .............................................................................................................................. vi
Liste des figures .................................................................................................................................. v
Chapitre I : Système de Gestion de Bases de Données ......................................................................6

Cours1. Modèle Relationnel de Données .......................................................................................7
Cours 2. Système de Gestion de Bases de Données.........................................................................9
Chapitre II : Structered Query Language .......................................................................................... 16

Cours 1. Oracle, SQL Developer et SQL ......................................................................................... 18
Cours 2. SQL: Langage de Définition de Données .......................................................................... 20
Cours 3. SQL: Langage de Manipulation de Données..................................................................... 29
Cours 4. Interrogation d’une BD: la commande SELECT................................................................. 33
Cours 5. Fonctions d'agrégation, Alias et Organisation des résultats ............................................. 36
Chapitre III : Gestion des évenements ............................................................................................. 41

Cours 1. Déclencheurs ou Triggers ............................................................................................... 42
Cours 2. Trigger de table .............................................................................................................. 43
Cours 3. Trigger de ligne .............................................................................................................. 46
Cours 4. Manipulation des Triggers ............................................................................................. 49
Annexes: Séries des Travaux Pratique ............................................................................................. 55
ii
Liste des tableaux
Tableau I. 1. Classification de quelques SGBD populaires ................................................... 14
Tableau I. 2. Comparaison entre les trois SGBD leaders ...................................................... 15
Tableau II. 1. Différentes versions du SGBD Oracle ........................................................... 17
Tableau II. 2. Classification des principales commandes SQL. ............................................ 20
Tableau II. 3. Les types de données Caractère ..................................................................... 24
Tableau II. 4. Les types de données Numériques ................................................................. 24
Tableau II. 5. Types de données Temporels ......................................................................... 25
Tableau II. 6. Violation des contraintes ............................................................................... 31
Tableau III. 1. Valeur Old et New dans les différents événements ....................................... 47
iii
Liste des figures
Figure I. 1. Schéma de la relation « CLIENT » ......................................................................8

Figure I. 2. Niveaux d'abstraction de représentation des données ......................................... 10
Figure I. 3. Conceptualisation du concept "Client" ............................................................... 12
Figure I. 4. Implémentation du concept "Client" en utilisant un fichier d'enregistrements .... 12
Figure II. 1. Différentes versions d'Oracle (jusqu'à 19c)....................................................... 19
Figure II. 2. Définition des contraintes de domaine en mode en ligne .................................. 27
Figure II. 3. Contrainte Primary Key en mode en ligne ........................................................ 27
Figure II. 4. Contrainte References en mode en ligne ........................................................... 28
Figure II. 5. Contrainte Foreign key en mode en ligne ......................................................... 28
Figure II. 6. Contraintes de domaine / d'intégrité en mode hors ligne ................................... 28
Figure II. 7. Désactivation, Activation et Suppression d’une contrainte ............................... 29
Figure II. 8. Insertion d'enregistrement (1ere forme) ............................................................ 30
Figure II. 9. Insertion d'enregistrement (2ème forme)-A- ..................................................... 30
Figure II. 10. Insertion d'enregistrement (2ème forme)-B- ................................................... 31
Figure II. 11. Utilisation de la fonction Sysdate .................................................................. 31
Figure II. 12. Violation de la contrainte d'intégrité ............................................................... 33
Figure II. 13. Output d'une requête de sélection ................................................................... 34
Figure II. 14. La fonction statistique COUNT ......................................................................37
Figure II. 15. Utilisation des Alias ....................................................................................... 38
Figure II. 16. La clause Group by (A) .................................................................................. 39
Figure II. 17. La clause Group by (B) .................................................................................. 39
Figure II. 18. La clause Ordre by appliquée sur une seule colonne ....................................... 39
Figure II. 19. La clause Ordre by appliquée sur plusieurs colonnes ......................................40
Figure III. 1. Trigger de Table d'ordre insert ........................................................................ 44
Figure III. 2. Exécution d'un trigger de table (A) ................................................................. 44
Figure III. 3. Trigger de table d'ordre update (A) ................................................................. 45
Figure III. 4. Trigger de table d'ordre update (B) ................................................................. 45
Figure III. 5. Exécution d'un trigger de table (B) ................................................................. 46
Figure III. 6. Trigger de ligne d'ordre m à j..........................................................................46
Figure III. 7. Exécution d'un trigger de ligne ....................................................................... 47
Figure III. 8. Usage de Old et New dans un trigger de ligne d'ordre update .......................... 48
Figure III. 9. Effet de la clause When dans un trigger de ligne .............................................49
Figure III. 10. Informations sur les Triggers ........................................................................ 50
iv
Chapitre I :
Système de Gestion de Base de Données

Chapitre I : Système de Gestion de Bases de Données
1. Introduction
Le système d’information est conçu autour d’une masse très importante de données.
Cette masse de données fournis un ensemble d’informations décrivant les objets du monde
réel. Les données doivent être bien structurées et stockées sur un support physique pour servir
de support à une application informatique. On parle, ici, des Bases de Données(BD).Les BD
se caractérisent par le faite qu’elles contiennent des données bien structurées destinées à un
stockage permanant. Ainsi, un utilisateur doit pouvoir accéder, manipuler et interroger une
BD. Cependant, la gestion d’une masse très importante de diverses données n’est pas une
tache ci-simple. D’où le recours à un système capable de prendre en charge les fonctionnalités
d’accès, de modification et de protection des données. Ces systèmes, appelés Systèmes de
Gestion de Bases de Données (SGBD) permettent de fournir les différents types d’interface
nécessaires à l’accès aux données tout en masquant à l’utilisateur les détails complexes liés à
cette gestion. Au cours des quarante dernières années, des concepts, méthodes et algorithmes
ont été développés pour gérer les BD, d'où proviens leur importance pour la gestion des
entreprises.
2. Processus de développent de Bases de Données

La représentation informatique des données d’un problème du monde réel (appelée
aussi, la modélisation du problème) consiste en la définition d’une série d’étapes de
transformation de ces données jusqu’à l’obtention d’une BD cohérente représentant le
problème réel. Cette modélisation permet l’exploitation des données avec un SGBD (Oracle,
par exemple) et leur manipulation avec un langage de données (SQL, par exemple). La
conception des BD passe généralement par les quatre étapes suivantes :
1. Spécification des besoins : Analyser et étudier le problème posé en soulignant les besoins
demandés et les acteurs concernés.
2. Création du modèle conceptuel de données (MDC) : Ce modèle non-formel (graphique)
représente toutes les entités importantes du problème.
3. Traduction du MCD en un modèle logique de données (MLD) : Représenter formellement
(logique du premier ordre) les entités du problème via un modèle relationnel.
4. Implémentation : coder les entités du problème avec un langage de données dans un
SGBD sous forme d'une BD.
Après avoir bien étudier les deux premières étapes 1, à savoir : spécification des
besoins et conceptualisation des données, l'objectif de ce cours sera de bien détailler les deux
dernières étapes, à savoir: le modèle relationnel et le codage des données avec le langage SQL
sous le SGBD Oracle
3. Modèle Relationnel de Données

La modélisation logique des données est une représentation formelle des données
issues de leur modélisation conceptuelle. Dans cette modélisation, appelée modèle relationnel
1
En 2eme année préparatoire
Dr. A Djellal 6
de données, la notion de table constitue la structure logique de base. Le modèle relationnel a

été introduit par E.F. Codd en 19702, un mathématicien chercheur chez IBM, pour représenter
une BD comme un ensemble de tables. Cette représentation offre une totale indépendance
entre les représentations logique et physique. En effet, les tables sont représentées
indépendamment des techniques de stockage sur machine : au niveau physique, le système est
libre d’utiliser n’importe quelle technique de stockage : fichiers séquentiels, indexage,
adressage, pointeurs… Ainsi, les tables correspondent à la représentent abstraite de
l’enregistrement physique des données en mémoire. Cette modélisation permet la
manipulation des données par les opérateurs de l’algèbre relationnelle. Par conséquent, le
succès du modèle relationnel revient d’une part à la vision tabulaire des données utilisée et,
d’autre part, au fondement théorique mathématique solide notamment la théorie des
ensembles et la théorie des prédicats du premier ordre (la logique mathématique).
3.1. Eléments du modèle relationnel
Le principal avantage du modèle relationnel consiste en sa simplicité. En effet, il

n’existe qu’une seule structure à manipuler : la table, appelée aussi la relation. Une table se
compose d’un ensemble de colonnes correspondant à une liste d’attributs. Les valeurs de
chaque attribut appartiennent à un certain domaine. Ainsi, le modèle relationnel se base
essentiellement sur ces trois concepts : relation, attribut et domaine.
1. Relation : C’est une table à deux dimensions qui modélise une entité du modèle
conceptuel. Chaque colonne de la table correspond à un attribut de l’entité. Chaque ligne
représente une occurrence, appelée aussi : un enregistrement ou encore un tuple.
Exemple. CLIENT, ENSEIGNANT-CHERCHEUR, ETUDIANT, COURS…
2. Attribut : Un attribut est caractérisé par un nom, souvent porteur de sens, et représente une
caractéristique ou une propriété de la relation. Il prend ses valeurs dans un domaine de
données.
Exemple. nom et âge représentent deux attributs de la relation ETUDIANT.
3. Domaine : C’est un ensemble de valeurs significatives. Il peut être défini en extension ou

en intension, comme il peut être simple ou bien composé.
i. Un domaine est dit simple si toutes ses valeurs sont atomiques.

Exemple. Les valeurs de l’attribut grade de la relation ENSEIGNANT-CHERCHEUR
peuvent être définit en extension par : {MAB, MAA, MCB, MCA, Pr}
ii. Un domaine est dit composé si ses valeurs peuvent être décomposées.
Exemple. Le domaine constituant les dates est composé de jour, mois et année.
Définition 1. Le schéma (Cf. Figure I.1) d’une relation (une table) se compose du nom de la
relation suivi de la liste de ses attributs avec leurs domaines. Le nombre d’attributs dans un
schéma représente le degré de la relation.
2
E.F. CODD, A Relational Model QfDaia for Large Shared Data Banks, Communications of the ACM, Volume 13, Number
6, June 1970, pp. 317-387.
Dr. A Djellal 7
CLIENT (CodCli : Entier, Domaines des attributs

Nom : Chaine de caractère,
Prénom : Chaine de caractère,
Email : Chaine de caractère)
Nom de la relation
CLIENT
CodCli Nom Prénom Ville Email
100 Ben said Ahmed Constantine BenSaidAhmed@gmail.com
101 Hammad Imene Alger HammadImene@ gmail.com Tuples de la relation
102 Salhi Ali Constantine salhiAli@hotmail.com
... …. .. ……
Figure I. 1. Schéma de la relation « CLIENT »
Dans la suite de ces notes de cours, nous allons utiliser la BD relationnelle Cours pour les
illustrations des différents chapitres. Le schéma relationnel de cette base est le suivant :
CLIENT (CodCli, Nom, Prénom, Ville Email)
PRODUIT (CodPrd, Désignation, Prix)
COMMANDE (Num, CodCli, CodPrd, Qte)
3.2. Clé primaire
C’est une combinaison d’attributs dont la valeur peut identifier, de manière unique, un
enregistrement dans une relation. Dans une relation donnée, il n’existe pas deux
enregistrements ayant la même clé primaire. Ainsi, la clé primaire préserve l’unicité des
enregistrements dans une table
A retenir!! Pour des besoins d’organisation de ces notes de cours, les

attributs composant la clé primaire seront toujours soulignés.
Exemple. Considérons la BD Cours, les attributs CodCli, CodPrd et Num

correspondent,respectivement, aux clés primaires des tables CLIENT, PRODUIT et
COMMANDE.
3.3. Clé étrangère
Les clés primaires permettent l'unicité des enregistrements. De plus, ils servent à
établir des relations entre les tables garantissant, ainsi, la cohérence de la base. Il s'agit de la
clé étrangère : c’est une combinaison d’attributs qui représentent la clé primaire dans une
autre table.
Exemple. Dans la BD Cours, les attributs CodCli et CodPrd de la table COMMANDE

représentent des clés étrangères.
Dr. A Djellal 8
4. Système de Gestion de Bases de Données

Un Système de Gestion de Bases de Données (SGBD)3 est un ensemble de logiciels
permettant aux utilisateurs de manipuler efficacement leurs données stockées sous forme
d’une grande masse d’informations 4 (BD). Les données sont partagées par de multiples
utilisateurs, naturellement de différents types : administrateurs, programmeurs, non
informaticiens, .... Le SGBD doit assurer un partage aussi bien en interrogation qu’en mise à
jour. Un des rôles majeur d’un SGBD consiste à rendre ce partage transparent, en donnant
l’illusion à chaque utilisateur qu’il est le seul à travailler avec la BD.
Un SGBD est donc un outil informatique permettant la sauvegarde et l’interrogation

des données. Ces fonctions sont complétées par d’autres souvent plus complexes.
Evidemment, il est indispensable d’avoir des fonctions destinées, par exemple, à assurer le
partage des données et aussi à protéger les données contre les risques de ce partage. En
résumé, un SGBD prend en charge la structuration, le stockage, la mise à jour, le contrôle et la
maintenance d'une BD. Il est l'unique interface entre les applications et les données.
4.1. SGBD : historique
Les premiers SGBD sont apparus dans les années 60. Les systèmes IDS.I et IMS.I ont
été développés respectivement à Honeywell et à IBM pour le programme APOLLO, qui a
permis d’envoyer l'homme sur la lune. Ce sont les précurseurs des SGBD modernes. Depuis,
l’évolution des SGBD à passé par quatre générations :
3. La première génération, marquée par la séparation de la description des données et de leur
manipulation par les programmes. Elle a été dominée par les SGBD TOTAL, IDMS, IDS 2
et IMS 2.
4. La deuxième génération, marquée par le nouveau Modèle Logique de Données proposé
dans les années 70, à savoir, le modèle relationnel. L’objectif de cette génération été
d’enrichir mais surtout de simplifier le SGBD externe afin de faciliter l’accès aux données.
Ceci est fait par la représentation des données sous forme de relations (table) entre
domaines de valeurs.
La manipulation des tables est effectuées à l’aide d’un langage non procédural standardisé
appelé SQL (Structured Query Language). Celui-ci permet d’exprimer des requêtes
traduisant directement des phrases simples du langage naturel et de spécifier les données
que l’on souhaite obtenir sans dire comment les accéder. Les principaux systèmes de cette
génération sont Oracle, Ingres, Sybase, Informix, DB2 et SQL Server. Ils ont été
commercialisés depuis 1980 et représentent aujourd’hui l’essentiel du marché des SGBD.
Ils supportent en général une architecture Client / Serveur.
5. La troisième génération, née depuis le début des années 80 influencée par l’apparition du
nouvel aspect de programmation, à savoir, la programmation orienté objet. Les systèmes
de cette génération supportent des modèles de données extensibles intégrant le relationnel
3
En anglais : Data Base Management System (DBMS)
4
Pouvant atteindre quelques milliards d’octets
Dr. A Djellal 9
et l’objet, ainsi que des architectures réparties (distribuées), permettant une meilleure
collaboration entre des utilisateurs concurrents.
Les systèmes objet relationnels tels Oracle 8, DB2 Universal Database ou Informix sont les
premiers représentants de la troisième génération. Tous ces systèmes tentent de répondre
aux besoins des nouvelles applications multimédia, Web, télécommunications, etc.
6. La quatrième génération envisage à mieux supporter les applications Web, les
informations mal structurées, les objets multimédias, l’aide à la prise de décisions et
l’extraction de connaissances à partir des données. La révolution conduite par l’objet a, en
quelque sorte, échouée du faite qu’elle n’a pas réussi à renverser le modèle relationnel.
Certes, ce modèle a été bousculé et adapté à l’objet, mais surtout pas remplacé.
4.2. Architecture ANSI/SPARC
Afin de simplifier la vision des utilisateurs, un SGBD doit impérativement assurer un

certain niveau d’abstraction des données. Pour cela, trois niveaux d’abstraction ont été
proposés pour la description des données, cette architecture a été normalisée et standardisée
en 1975 par le comité SPARC5 de l'ANSI 6 (Cf. Figure I. 2)
Figure I. 2. Niveaux d'abstraction de représentation des données

4.2.1. Niveau externe
C'est le niveau consulté par les utilisateurs. Il serait important que chaque groupe de travail
perçoive sa propre description des données (son schéma externe). Cette description est
effectuée selon la manière dont le groupe voit la BD dans ses programmes d’application.
Donc, ce niveau décrit la partie des données présentant un intérêt pour un groupe
d’utilisateurs sous forme de vue externe. L’utilisation des vues externes permet d’assurer un
certain niveau de sécurité : un groupe de travail ne peut accéder qu’aux données décrites dans
sa vue externe, les autres données sont protégées contre les accès non autorisés.
5
Standard Planning And Requirement Comitte
6
American National Standards Institute
Dr. A Djellal 10
4.2.2. Niveau conceptuel
C’est le niveau central, il correspond à la structure sémantique des données sans souci
d’implémentation. Ce niveau regroupe la vue intégrée de tous les utilisateurs, à savoir, le
dictionnaire de données. Ce dictionnaire comporte la description des données et des
contraintes :
- Les types de données élémentaires pour définir les domaines des attributs,
- Les types de données composés pour décrire les tables : une personne, un malade, une
maladie…
- Les règles (contraintes) à appliquer sur les données au cours de leur vie dans l’entreprise :
l’âge d’un employé est compris entre 0 et 65, son salaire est compris entre 46 000.00 DA
et 180 000.00 DA, le stock des produits doit être positif...
4.2.3. Niveau interne
Le niveau interne correspond à la représentation physique des données. Il consiste en la

spécification des structures de mémorisation et des méthodes de stockage et de recherche
utilisées. C’est la description des données telles qu’elles sont stockées sur les mémoires
secondaires:
- Les fichiers contenant les données (taille, localisation…),
- Les articles de ces fichiers (longueur, champs composants, modes de placement…),
- Les chemins d’accès à ces articles (indexage, chaînages,…).
Exemple. Ci-dessous une description du concept "Client" de la base Cours sur les trois
niveaux d’abstraction. La déclaration du concept est la suivante :
Client (Nom : VarChar (25),
Prénom : VarChar (50),
Age : number (2),
Ville : VarChar (20)) ;
Ce concept sera représenté dans les trois niveaux d'abstraction comme suis:
1. Niveau externe :
Les enregistrements sont décrits en vues :
- Vue # 1 : tous les clients habitant à la ville X.
- Vue # 2 : tous les clients ayant le même nom de famille.
- Vue # 3 : tous les clients majeurs.
2. Niveau conceptuel :
Le concept est décrit avec ses attributs et ses relations avec les autres concepts (Cf. Figure
I.3). Chaque attribut est défini par un domaine avec possibilité d'ajouter des contraintes sur ce
domaine, l'âge > 18 par exemple.
Dr. A Djellal 11
Client
Nom : chaine de caractères
Prénom : chaine de caractères
Age : entier
Ville : chaine de caractères
Ville : VarChar (20)) ;
Figure I. 3. Conceptualisation du concept "Client"
3. Niveau interne :
Les enregistrements du concept sont décrits comme une suite d’emplacements mémoires.
Nom Prénom Age Ville Pointeur
BenSaid Ahmed 35 Constantine
Hammad Imene 28 Alger
Salhi Ali 35 Constantine
Figure I. 4. Implémentation du concept "Client" en utilisant un fichier d'enregistrements

4.3. Fonctionnalités des SGBD
Dans la vie d’une entreprise, on a toujours besoin d’un SGBD pour gérer une BD
partagée entre plusieurs utilisateurs. Ceci est le principal objectif qui résume, intuitivement,
plusieurs autres objectifs assurés par les fonctionnalités suivantes:
4.3.1. Description des données

Avant de pouvoir manipuler les données, il est évident, qu’il faut les définir au préalable. Un
SGBD permet la description des données (type, longueur, nature…), des relations entre les
données, les domaines de valeurs, les contraintes …. Ceci nécessite l’utilisation d’un Langage
de Définition de Données (LDD)
4.3.2. Indépendance physique des données
Dans une entreprise, les données sont assemblées pour décrire les objets du monde réel. Ceci
correspond au schéma (modèle) conceptuel de données. Par opposition, la structure de
stockage des données appartient au monde des informaticiens et correspond au schéma interne
qui décrit l’assemblage physique des données sous forme d’articles, fichiers et chemins
d’accès. Le choix du schéma interne (méthode d’accès aux fichiers, modes de placement des
articles dans les fichiers …) est basé sur des considérations de performances et de souplesse
d’accès. Evidemment, ces deux schémas décrivent les mêmes objets, mais à deux niveaux
d’abstraction différents.
L’indépendance physique des données consiste en le pouvoir de modifier le schéma interne,
afin d’améliorer les performances ou la flexibilité d’accès, sans avoir à modifier le schéma
conceptuel. Il sera possible, par exemple, de regrouper deux fichiers ou changer le codage des
données dans un article, sans mettre en cause les entités et les associations définies au niveau
Dr. A Djellal 12
conceptuel. Dans le cas contraire, pour permettre de conserver les possibilités d’optimisation
de performances, tout changement informatique apparaîtra directement sur le monde réel et
impliquera une reconstruction des applications.
4.3.3. Indépendance logique des données
En plus des schémas interne et conceptuel des données, le schéma externe de la BD offre une
vue particulière des données pour chaque groupe de travail. Ainsi, il serait préférable de
permettre une indépendance, d’une part entre les différents schémas externes, et d’autre part
entre le schéma conceptuel et les schémas externes. L’indépendance logique des données
assure pour chaque groupe de travail:
- De faire évoluer sa vue externe sans remettre en cause les autres vues.
- De faire évoluer sa vue externe sans remettre en cause (dans une certaine mesure) le
modèle conceptuel.
4.3.4. Manipulation des données
Les SGBD offrent des capacités d’exécution des opérations d’ajout, de suppression et de
modification des données. Ils permettent également la recherche et l’interrogation des
données. Ceci est assuré par le biais d’un Langage de Manipulation des Données (DML). De
plus, l’interrogation et la mise à jour des données est faite sans préciser les algorithmes
d'accès (Dire QUOI sans dire COMMENT). En outre, ce langage permet d’exprimer et de
répondre à des requêtes en langage naturel.
4.3.5. Contrôle des données
Les SGBD doivent assurer le maintien de la cohérence des données par rapport aux schémas
décrits. Ceci est fait en respectant les contraints d’intégrité de la BD. Par exemple, si un client
n’existe pas, on ne peut pas lui associer une commande. Le SGBD vérifie que les mises à jour
effectuées sur les données respectent les contraintes, une fois décrites. Ainsi, il ne crée la
commande que si le client a été créé.
En plus du contrôle d’intégrité, les SGBD assure un contrôle de confidentialité. Ainsi, ils
permettent de définir des utilisateurs avec des droits d’accès précis (Qui peut faire Quoi).
Plusieurs droits peuvent être décrits : droit de lecture, de modification, d’ajout, de suppression
et également droit à la description des données. Il existe toujours un utilisateur particulier qui
possède tous les droits : le Data Base Administrator (DBA), celui-ci possède le droit de
définir et de modifier les droits des autres utilisateurs. Assurer les contrôles d’intégrité et de
confidentialité nécessite l’utilisation d’un Langage de Contrôle des Données (DCL)
4.3.6. Partage des données
Rappelons qu’une BD est toujours partagée aussi bien en interrogation qu’en mise à jour.
Ainsi, une application doit pouvoir mettre à jour les données comme si elle était seule à les
utiliser. Une telle mise à jours correspond, par exemple, à une réservation de place sur un
avion ou à un transfère bancaire à partir d’un compte à un autre. Il est impératif que deux
mises à jour concurrentes ne s’emmêlent pas dans leurs accès (risque de réserver le même
siège pour deux passagers différents). De la sorte, et pour gérer les accès concurrents, les
SGBD utilisent les transactions pour assurer qu’un groupe de mises à jour est totalement
exécuté ou pas du tout. Une transaction est vue comme un bloc d’instructions délimités par
Dr. A Djellal 13
un: BEGIN_TRANSACTION et END_TRANSACTION. Ceci nécessite l’utilisation d’un

Langage de Contrôle de Transaction (TCL)
4.4. SGBD leaders
Plusieurs SGBD ont été développés pour exploiter différents types de BD. Nous
pouvons trouver sur le marché des SGBD relationnel, objet, NoSQL, temporel... Nous
trouvons aussi des SGBD commerciaux et d’autres libres… Parmi les SGBD les plus
populaires, nous pouvons citer :
- Oracle, un SGBD relationnel et relationnel-objet très utilisé pour les applications
professionnelles.
- PostgreSQL, un SGBD relationnel puissant qui offre une alternative libre (licence
BSD) aux solutions commerciales.
- Access, un SGBD relationnel de Microsoft, qui offre une interface graphique permettant
de concevoir rapidement des prototypes.
- MongoDb, un SGBD non-relationnel libre (licence Apache) orienté document.
- MySQL, un SGBD relationnel libre (licence GPL et commerciale), très utilisé pour la
réalisation des sites web dynamiques.
La table suivante représente une classification des SGBD populaires :

Tableau I. 1. Classification de quelques SGBD populaires
SGBD
Relationnel Propriétaire  4D, DB2, dBase, Informix, InterBase, MaxDB,
Oracle Database, SQL Server, Sybase
Libre Derby, Firebird, HSQLDB, Ingres, MariaDB,
MySQL, PostgreSQL
Objet ZODB, db4o
Embarqué  Berkeley DB, SQLite
NoSQL  BigTable, Hypertable, CouchDB, Cassandra, HBase, LevelDB, MongoDB,
Redis, RethinkDB, SimpleDB, Riak
Intégré  Access, FileMaker, HFSQL, OpenOffice.org Base, Paradox, Neo4j, SAS, 4D
Temporel  OpenTSDB, KairosDB
L'étude du marché montre que Oracle, DB2 et SQL Server figurent parmi les tops des
SGBD relationnel depuis longtemps. Le choix d’un SGBDR n’est pas une tache facile. En
effet, plusieurs facteurs entrent en jeu : s’il sera installé sur un mainframe (serveur) d’une
grande entreprise, le choix logique sera DB2. Dans les installations Unix et Linux, les choix
se porteront sur Oracle et DB2. Pour ces deux plateformes, Oracle arrive en tête même si la
présence de DB2 est forte. Cependant, sur dans une installation Windows, Microsoft avec son
SGBD SQL Server, qui possédant son propre système d’exploitation, est le maître
incontestable.
Ces trois SGBD leaders affichent d’excellents résultats en termes de performances, de

fonctionnalités, de développement d’applications, d’assistance, de facilité d’utilisation et de
Dr. A Djellal 14
fonctions, mais ils ont aussi leurs différences. Le tableau suivant représente une comparaison
entre ces trois SGBD7.
Tableau I. 2. Comparaison entre les trois SGBD leaders
IBM DB2 Ms SQL Server Oracle

Modèle de BD Relationnel Relationnel Relationnel
Magasin de documents Magasin de documents Magasin de documents
Magasin RDF Données graphiques Magasin RDF
Prise en charge
Données spatiales Données spatiales Données graphiques
Données spatiales
DB-Engines 8 score = 149,66 score = 924,68 score = 1236.37
9
Tableau de bord 8 3 1
1ere version en 1983 1989 1980
Dernière version 12.1, 10/16 SQL Server 2019, 11/19 21c, 01/21
Développeur IBM Microsoft Oracle
HP-UX, Linux, Linux, Windows AIX, HP-UX, Linux,
SE10 pris en
Windows, Z/OS, AIX, OS X, Solaris, z/OS,
charge
Solaris, Windows
C, C#, C++, Perl, php, C#, C++, java,R, Delphi C, C#, C++, Cobol,
Cobol, Delphi, Fortran Aller, php, JavaScript Delphi, PHP, Fortran,
Langages de
Java, Python, Ruby, (Node.js), Python, Ruby Groovy, Java, R, Lisp,
programmation
Visual Basic Visual Basic JavaScript, Python,
pris en charge
objective C, Visual
Basic ...........
www.ibm.com/analyti www.microsoft.com/en- www.oracle.com/data
Site Web
cs/db2 us/sql-server base
7
Les données de la comparaison datent d'Octobre 2022
8
Classement des SGBD selon un score calculé en fonction de leur popularité sur les moteurs de
recherche, mis à jour mensuelle.
9
Mesure de la popularité des SGBD, mis à jour mensuelle.
10
Système d'exploitation
Dr. A Djellal 15
Chapitre II :
Structured Query Language (SQL)
Important. Les scripts figurants dans la suite de ces notes de cours ont été codés avec SQL3
(quelques exemples en PL/SQL) sous le SGBD ORACLE dans sa version 12c (valide aussi
pour Oracle 11g) via l'outil SQL developer dans sa version 17.3.1
Chapitre II : Structured Query Language (SQL)
1. Introduction
Une BD est conçu pour servir de support à une application informatique. Ainsi,
l’interrogation de telles sources de données avec un langage de données constitue l’objectif de
sa construction. Un langage de données est un langage informatique permettant de décrire et
de manipuler les schémas et les données d'une base. SQL (Structured Query Language) est le
langage de données le plus utilisé pour l’exploitation des BD, ce langage normalisé (ISO89)11,
(ISO92)12 constitue le standard d’accès aux BD relationnelles. Ainsi, il représente le point
d’entrée obligatoire des SGBD relationnels. Il permet de définir, interroger, manipuler,
contrôler et communiquer avec une BD. Pour cela, il utilise des critères de recherche
(qualifications) construits à partir du langage algébrique.
SQL fournit plusieurs niveaux de normalisation
- SQL1 : représente la norme de base
- SQL2 : extension de SQL1 qui offre :
o Un meilleur support des règles du langage algébrique
o Un ensemble plus variés des types de données
- SQL3 : extension de SQL2 qui offre :
o Une prise en charge du modèle objet,
o Utilisation des trigger pour la gestion des événements,
o Utilisation des rôles pour la gestion de la sécurité
o ...
- PL/SQL : un langage fondé sur l'intégration du paradigmes de programmation
procédurale avec la gestion des données.
2. Oracle
En 1977, Larry Ellison, Bob Miner et Ed Oates fondent la société Software
Development Laboratories (SDL). Les associés de SDL avec le mathématicien Edgar Frank
Codd 13 se lancent dans le développement de leur logiciel Oracle. En 1979, SDL devient
Relational Software Inc. (RSI) qui donnera naissance à la société Oracle Corp. En 1983 la
première version du SGBD s’appelle RSI-1 et utilise SQL comme langage de données. Le
tableau suivant résume la chronologie des différentes versions du SGBD Oracle.
Tableau II. 1. Différentes versions du SGBD Oracle
Année Version Description
1979 Oracle 2 - Première version commerciale
- Ecrite en C/assembleur pour Digital
1983 Oracle 3 - Réécrite en C – verrous.
1984 Oracle 4 - Portage sur IBM/VM, MVS, PC
- Intégration du mode transactionnel.
1985 Oracle 5 - Architecture client-serveur avec SQL*Net
- Portage sur Apple.
11
[ISO89] International Organization for Standardization, « Information Processing Systems – Database
Language SQL with Integrity Enhancement », International Standard ISO/IEC JTC1 9075 : 1989(E), 2e
édition, avril 1989.
12
[ISO92] International Organization for Standardization, « Database Language SQL », International Standard
ISO/IEC JTC1/SC21 Doc. 9075 N5739, 1992.
13
Apres avoir proposé le Modèle Relationnel.
Dr. Djellal. A 17
1988 Oracle 6 - Verrouillage niveau ligne

- Avec sauvegarde/restauration
- Intégration de PL/SQL
1992 Oracle 7 - Contraintes référentielles
- Procédures cataloguées
- Déclencheurs
- Portage sur Windows en 1995.
- Serveur de données vidéo
- Connexions sur le Web.
1997 Oracle 8 - Objet-relationnel
- Partitionnement
- LOB
- Support de Java
1999 Oracle 8i - i comme Internet
- SQLJ
- Portage sur Linux
- Support XML
2001 Oracle 9 i - Services Web
- Serveur d’applications
- Architectures sans fil
2004 Oracle 10g - g comme Grid computing (ressources en clusters)
2007 Oracle 11g - Auto-configuration
2013 Oracle 12c R1 - Architecture multitenant
- Cloud et Big Data.
2017 Oracle 12c R2 - Data Recovery
- Cloud Service
2018 Oracle 18c - BD autonome
- Redo Apply
- Data Guard
2019 Oracle 19c - Indexation Automatique
- Statistique en temps réel.
2021 Oracle 21c - Support des fichiers JSON dans les tables
- Nouveau type de tables : « Blockchain Tables »
- SQL Macros
- Utilisation des algorithmes de « Machine Learning »
- In-Database JavaScript
À partir de 2018, la société Oracle a proposé un rythme annuel pour ces nouvelles
versions. Avec ce nouveau rythme, le numéro de version rappellera l'année de son lancement,
comme le montre la figure suivante. Ainsi, en juillet 2018 la version Oracle 18c a vu le jour.
Elle ajoute quelques nouvelles fonctionnalités et améliore d’autres précédemment introduites
dans Oracle 12c. La dernière version consiste en Oracle 21c lancée en 2021.
Dr. Djellal. A 18
Figure II. 1. Différentes versions d'Oracle (jusqu'à 19c)14
3. Oracle SQL Developer

Oracle SQL Developer est un IDE (Integrated Development Environment)
multiplateforme, fourni gratuitement par Oracle Corp. C'est un outil graphique utilisant la
technologie JDK (Java Development Kit). Il est disponible sur le site d’Oracle15 sous
différentes versions : Windows 32 et 64 bits, Mac, Linux et autres. Sa première version 1.0 est
lancée en Mars 2006. Il a ensuite considérablement évoluer pour prendre en charge PL/SQL,
de nouveaux constructeurs de requêtes, des fonctionnalités DBA (Data Base Administration)
plus avancées ainsi que des outils de reporting 16. Sa dernière version 21.4.3 est lancée en
Mars 2022
Oracle SQL Developer permet de créer, mettre à jours, gérer et interroger

différentes BD via le langage SQL. Il supporte les produits Oracle ainsi que des plugins qui
permettent de se connecter à des BD non Oracle. En effet, il fonctionne avec IBM DB2, Ms
Access, Ms SQL Server, MySQL, Sybase Adaptive Server et les bases de données Teradata.
4. Différentes familles du langage SQL

SQL représente le point d’entrée obligatoire des SGBD relationnels. Avec les
instructions SQL, appelées requêtes, il est possible de créer et de gérer les BD. Les requêtes
du langage SQL se répartissent en quatre familles fonctionnellement distinctes. Le tableau II.2
représente une classification des principales commandes SQL.
14
Source : https://www.claremont.co.uk/insights/upgrade-oracle-database-19c
15
www.oracle.com/technetwork/developer-tools/sql-developer
16
Oracle Forms and Reports
Dr. Djellal. A 19
i. Langage de Définition de Données (LDD) : les commandes de cette famille permettent

de décrire la structure de la BD (tables, vues, index, attributs, ...).
ii. Langage de Manipulation de Données (LMD) : les commandes de cette famille

permettent de manipuler et d'interroger les tables et les vues.
iii. Langage de Contrôle des Données (LCD) : les commandes de cette famille contiennent
les primitives de gestion des utilisateurs et des privilèges d'accès aux données.
iv. Langage de Contrôle de Transaction (LCT) : les commandes de cette famille permettent
la gestion des transactions (validation/annulation des m à j des données de la base)
Dans ce qui suit, nous allons présenter en détails les commandes des deux premières familles,
à savoir : LDD et LMD
Tableau II. 2. Classification des principales commandes SQL.
SQL
LDD LMD LCD LCT
CREATE SELECT GRANT COMMIT
DROP INSERT REVOKE ROLLBACK
ALTER DELETE
RENAME UPDATE
5. Langage de Définition de Données

Le LDD correspond à la partie SQL qui permet de décrire le schéma d’une BD
relationnelle qui sera manipulée par un SGBD. Dans ce cours, le schéma d'une BD est définit
par :
i. La description des tables et
ii. La définition des contraintes portant sur les données des tables.
5.1. Description des données
La description des données (Tables ou autres objets SQL) se fait à l'aide des
commandes suivantes : CREATE, ALTER, RENAME et DROP.
A retenir !! Une table est créée en SQL avec la commande CREATE TABLE,
renommée avec RENAME, sa structure est modifiée avec ALTER TABLE et
elle sera supprimée avec DROP TABLE.
5.1.1. Création de tables
Avec la commande Create, on peut créer un objet SQL (BD, table, type, utilisateur…). La
commande CREAETE TABLE permet de créer des relations sous forme de tables. Ceci est
fait en définissant la liste de ses colonnes avec leurs types selon la syntaxe suivante :
Dr. Djellal. A 20
CREATE TABLE <Nom_Table> (Nom_Col1 type,

Nom_Col2 type,
… … ) ;
Exemple 1. L'exécution de la requête suivante permet de créer la table Client de la BD Cours

(Cf. Chapitre I). Ceci est une capture d’écran de l’outil Oracle SQL Developer.
5.1.2. Renommer une table
La commande RENAME permet de renommer une table déjà crée. Pour cela, il faut respecter
la syntaxe suivante :
RENAME nom_table TO nouv_nom_table;
Exemple 2. La requête suivante permet de modifier le nom de la table CLIENT en

VANTE_CLIENT
5.1.3. Destruction d'une table
Pour supprimer un objet SQL, il faut utiliser la commande DROP. Cette commande est à
utiliser avec beaucoup d’attention car l’objet en question sera détruit définitivement
(suppression physique). Pour supprimer une Table avec ses enregistrements, il faut utiliser la
commande DROP TABLE, selon la syntaxe suivante :
DROP TABLE <nom_Table> ;
Exemple 3. La requête suivante permet de supprimer la table Client précédemment créée.
5.1.4. Modification du schéma d'une table
La commande ALTER permet de modifier la définition d'une table en ajoutant, en changeant

ou bien en supprimant des colonnes (attributs), selon la syntaxe suivante :
ALTER TABLE <nom_Table> CLAUSE description_CLAUSE ;
Dr. Djellal. A 21
Où CLAUSE peut être ADD, MODIFY ou DROP column et description_CLAUSE est la

description de modification associée à la CLAUSE choisie.
A retenir!! Il est possible de modifier d'autres éléments de la table

(contraintes, trigger, par exemple), ceci sera abordé dans les prochaines
sections.
i. Ajout d’une colonne:

La syntaxe suivante permet d’ajouter une colonne à la structure d’une table :
ALTER TABLE <nom_Table> ADD <new_COLUMN> <Type>;
Exemple 4. On peut ajouter la colonne Email à la table CLIENT, via la requête suivante :
ii. Modification d’une colonne:

Pour cela, il faut associer la commande ALTER avec la clause MODIFY. Cela permet de
modifier le type de données d'une colonne existante.
ALTER TABLE <nom_Table> MODIFY <COLUMN> <Type>;
Exemple 5. La requête suivante permet d’agrandir la taille de la colonne Email à 50

caractères :
A retenir !! La modification du type de données d’une colonne peut poser des

problèmes si le nouveau type est incompatible avec le contenu existant, par
exemple le passage de VARCHAR à INTEGER. Le résultat sera, ainsi,
imprévisible. De plus, la diminution de la taille d’une colonne provoque le
risque de perte d’information.
iii. Suppression d’une colonne:

La possibilité de supprimer des colonnes d'une table est apparue avec Oracle 8.1. Pour ce
faire, il faut associer la commande ALTER avec la clause DROP COLUMN selon la syntaxe
suivante:
ALTER TABLE <nom_Table> DROP COLUMN <COLUMN>;
Exemple 6. La requête suivante permet de supprimer la colonne Email de la table Client :
Dr. Djellal. A 22
Activité. Utiliser la connexion Cour BDA avec l'utilisateur myUser (crées durant la séance
de TP) et exécuter le script SQL suivant. Examiner le script output pour voir le résultat.
5.2. Nommage et types de données SQL
Comme tout langage informatique, le nommage des objets SQL (tables, colonnes...)
est soumis à un certain nombre de règles. Ainsi, le nom d’un objet SQL:
- Se compose des lettres {A…Z, a…z}, des chiffres {0…9} et le symbole {_}.
- Commence obligatoirement par une lettre.
- Sa taille ne dépasse pas 128 caractères.
- Différent des mots réservés de SQL (table, int, date...).
- Insensible à la casse.
- Unique au sein de l’objet qui le contient (exemple : le nom d’une table au sein de la
base ou bien le nom d’une colonne au sein d’une table).
Pour décrire les colonnes d’une table, la norme SQL fournit un ensemble très important de
types de données prédéfinis. Dans ce qui suit, une présentation des types de données les plus
utilisés, à savoir : les types caractères, numériques et temporels.
5.2.1. Types de données Caractères
Les deux principaux types caractères, disponibles dans la plupart des SGBD relationnels, sont
CHAR(M) et VARCHAR(M). Ils permettent de stocker des chaînes de caractères d’une taille
maximale fixée par un paramètre M. VARCHAR2(M) est un type de données utilisé depuis
Oracle 9. Il permet de stocker des chaines de caractères de tailles variables. La différence
essentielle entre celui-ci et les deux premiers types est qu’une valeur CHAR/VARCHAR a
une taille fixée, et se trouve donc complétée avec des blancs (nul) si sa taille est inférieure au
paramètre M. En revanche, une valeur VARCHAR2 a une taille variable et est donc tronquée
après le dernier caractère non blanc.
Ces trois types de données ne sont pas suffisants en cas de stockage des chaînes de caractères
très longues (des livres par exemple). Par conséquent, la norme SQL propose d’autres types
qui correspondent à de très longues chaînes de caractères, par exemple le type CLOB.
Dr. Djellal. A 23
Tableau II. 3. Les types de données Caractère
Type Description Taille

CHAR(M) Chaine fixe de M caractères 1-2000 caractères
VARCHAR(M) Chaine fixe de M caractères 1-4000 caractères
VARCHAR2(M) Chaine de longueur variable 1-4000 caractères
CLOB Chaine de longueur très grande Jusqu’à 4 G octet
5.2.2. Types de données numériques
Les principaux types numériques proposés par la norme SQL tournent autours les nombres
entiers et décimaux. Les types qui acceptent des nombres entiers comme valeur sont désignés
par le mot-clé INT (TINYINT, SMALLINT, MEDIUMINT, BIGINT). La différence entre
eux revient à la taille mémoire réservées au champ. Le type NUMBER (t, d) sert à stocker des
nombres décimaux. Les deux paramètres précisent la taille (t) du nombre et le nombre de
décimales (d). Dans un champ NUMBER (5,3), on peut stocker des nombres de 5 chiffres
significatifs maximum, dont 3 chiffres sont après la virgule. Par exemple : 22.435, -14.861.
NUMBER (4) équivaut à écrire NUMBER (4, 0). Ce type est surtout utile pour manipuler des
valeurs dont la précision est connue, comme les valeurs monétaires.
Tableau II. 4. Les types de données Numériques

TINYINT Nombre entier appartenant à [-128, 127] 1 octet
SMALLINT Nombre entier appartenant à [-32768, 32767] 2 octets
MEDIUMINT Nombre entier appartenant à [-8388608, 8388607] 3 octets
INT Nombre entier appartenant à 4 octets
[-2147483648, 2147483647]
BIGINT Nombre entier appartenant à 8 octets
[- 9223372036854775808, 9223372036854775807]
NUMBER(t, d) Nombre de t chiffres dont d décimales. 21 octets
t : 1- 38. d : [–84, +127].
5.2.3. Types de données temporels
La norme SQL fournis un ensemble de types temporel pour stocker des valeurs représentants
des moments. Le type DATE permet de stocker des moments avec une précision de siècle,
année, mois, jour, heure, minutes et secondes. Le type TIMESTAMP est plus précis dans la
définition d’un moment (fraction de seconde). Le type INTERVAL YEAR TO MONTH
permet d’acquérir une différence entre deux valeurs temporelles avec une précision
mois/année. Le type INTERVAL DAY TO SECOND permet d’acquérir cette différence avec
plus de précision (de l’ordre de la fraction de seconde)
Dr. Djellal. A 24
Tableau II. 5. Types de données Temporels

DATE du 1er janvier 4712 avant J.-C. 7 octets
au 31 décembre 4712 après J.-C.
TIMESTAMP Date et heure incluant des fractions de 7 à 11 octets
secondes
INTERVAL YEAR (a) TO Période représentée en années et mois. 5 octets
MONTH La précision de a est de 0 à 9.
INTERVAL DAY (a) TO Période représentée en j/h/m/s. 11 octets
SECOND (s) Les précisions a et s est de 0 à 9
5.3. Description des contraintes
La création d’une table, telle qu’on l’a vue précédemment dans la section 5.1 sous
forme d'un ensemble de colonnes, décrit le contenu de la BD. Cependant, ce contenu doit
respecter quelques règles de gestion. Pour cela, il faut inclure des contraintes dans le schéma
de la table pour assurer l’intégrité et la cohérence de la BD. Par exemple, on peut demander
au SGBD de garantir que :
- Une colonne doit toujours avoir une valeur concrète (différente de nulle).
- Une ou plusieurs colonnes constituent la clé primaire de la table.
- Une colonne dans une table peut référencer la clé primaire d’une autre table.
- La valeur d’une colonne doit être unique au sein de la table.
- La valeur d'une colonne doit être supérieure à 18, par exemple
Pour garantir ce genre de contrôle, des règles de gestion doivent être définies au sein des
schémas des tables de la BD, il s'agit des contraintes. L’intégration de ces contraintes peut
alléger les applications du côté client. En effet, si on définie que la valeur du stock des
produits doit obligatoirement être un nombre strictement positif (stock > 0), les applications
de saisie n’ont plus à tester les valeurs en entrée, ça sera le rôle des contraintes portant sur les
colonnes en question.
Deux types de contraintes peuvent être utilisés: des contraintes de domaines et des contraintes
d'intégrité. Les deux types peuvent être définis selon deux manières :
i. En ligne (Inline constraints) : avec cette première manière, la déclaration des contraintes
est faite au sein de la commande create (en même temps que la description de la
colonne ou bien après mais toujours dans Create), comme suit:
Create table <nom_table> (

<nom_col> type <description de la contrainte>,
<nom_col> type ,
....
<description de la contrainte> );
Dr. Djellal. A 25
ii. Hors ligne (Out-of-line constraints): avec cette deuxième manière, la définition des
contraintes est faite après la création de la table. Ceci est fait via la commande de
modification ALTER, selon la syntaxe suivante:
Alter table <nom_table> ADD Constraint <description de la

contrainte>
A retenir !! La définition des contraintes hors ligne représente une

modification du schéma de la table, ainsi, il faut utiliser ALTER.
5.3.1. Contraintes de domaine
Il s’agit d’un ensemble de règles appliquées sur quelques colonnes à fin de restreindre leurs
domaines de définition. Les contraintes de domaine les plus utilisées sont:
- NOT NULL : Cette contrainte précise que pour toute occurrence, la colonne
correspondante doit avoir une valeur concrète. Ainsi, la saisie de ce champ est obligatoire.
- DEFAULT : Cette contrainte précise que la saisie de la colonne correspondante n’est pas
obligatoire, le SGBD s'en charge de la remplir par une valeur par défaut. Il est à noter que,
la valeur par défaut doit avoir le même type que la colonne en question.
- UNIQUE : Cette contrainte précise que les valeurs de la colonne correspondante sont
distinctes, à l’exception de la valeur NULL. Donc, une valeur ne doit pas être dupliquée
dans deux (ou plus) occurrences (pas de doublon).
- CHECK (condition): Cette contrainte spécifie une condition (simple ou composée)
portant sur une colonne. Cette condition est vérifiée au moment de l’insertion / la
modification d’une valeur de la colonne en question par le SGBD. Un message d'erreur est
généré en cas de condition non vérifiée.
La figure II.2 représente la requête SQL permettant la création de la table Client. La requête
spécifie cinq contraintes de domaine définies en mode en ligne :
1- L’attribut CodCli doit être saisi,

2- Le client doit être majeur (Age > 18),
3- Le numéro de registre doit être unique (chaque client possède un numéro de registre
distinct),
4- Une valeur par défaut "Particulier" est attribuée à la colonne TypeCli, si elle n’est
pas renseignée par l'utilisateur
5- En fin, le mode de payement du client doit être soit par espèce ou bien par cheque.
Il est possible de définir toutes ces contraintes après la création de la table (le mode hors
ligne) via la commande ALTER (Cf. Figure II.6)
Dr. Djellal. A 26
Figure II. 2. Définition des contraintes de domaine en mode en ligne
5.3.2. Contraintes d’intégrité

Il s’agit de quelques règles définissant les règles d’intégrités de la BD, comme par exemple la
définition de la clé primaire et la clé étrangère. Ces contraintes garantissent la cohérence de la
BD.
- PRIMARY KEY : Cette contrainte défini la clé primaire de la table. L’ajout de cette
contrainte pour une ou plusieurs colonnes impose des valeurs concrètes (NOT NULL) et
distinctes (UNIQUE).
La contrainte PRIMARY KEY peut être définie en mode en ligne selon deux manières:
avec la définition de la colonne ou bien après (Cf. Figure II. 3). Elle peut être, aussi,
définie en mode hors ligne (Cf. Figure II. 6).
A retenir !! Quand la clé primaire est constituée de plusieurs colonnes, la

contrainte PRIMARY KEY utilisée en mode en ligne doit être ajoutée après
la définition de toutes les colonnes en question.
Figure II. 3. Contrainte Primary Key en mode en ligne

- REFERENCES : C’est une contrainte utilisée en mode en ligne, elle déclare une colonne
comme clé étrangère et référence la table correspondante (cf. Figure II. 4).
- FOREIGN KEY : On peut utiliser cette contrainte pour le même objectif, à savoir la
définition de la clé étrangère en mode en lige (cf. Figure II.5) ou bien en mode hors ligne
(Cf. Figure II.6).
Dr. Djellal. A 27
Figure II. 4. Contrainte References en mode en ligne
Figure II. 5. Contrainte Foreign key en mode en ligne
Le scripte de la figure suivante représente la création de la table Client ensuite une

modification de son schéma en lui ajoutant des contraintes d'intégrité et de domaine en mode
hors ligne.
Figure II. 6. Contraintes de domaine / d'intégrité en mode hors ligne
A retenir !! La définition des contraintes impose un ordre de création des

tables. Evidemment, la contrainte de la clé étrangère impose la création des
tables référentes, puis les tables qui en dépendent (la suppression des tables
sera dans l’ordre inverse).
Avec la commande ALTER, il est possible de modifier le schéma d'une table en lui :
- Ajoutant une contrainte via la clause ADD Constraint (Cf. Figure II.6),
- Activant une contrainte via la clause DISABLE constraint (Cf. Figure II.7),
Dr. Djellal. A 28
- Réactivant une contrainte via la clause ENABLE constraint (Cf. Figure II.7) et
- Supprimant une contrainte via la clause DROP constraint (Cf. Figure II.6, II.7).
Figure II. 7. Désactivation, Activation et Suppression d’une contrainte
6. Langage de Manipulation de Données

Dans ce qui suit, une description d’une partie de l’aspect DML (Data Manipulation
Language) du langage SQL sous la syntaxe d’Oracle. SQL propose quatre instructions de base
pour manipuler les données :
i. INSERT : pour l’insertion d’enregistrements
ii. UPDATE : pour la modification de données
iii. DELETE : pour la suppression d’enregistrements
iv. SELECT : pour la recherche de données
6.1. Insertion d’enregistrements
A l’aide de la commande INSERT INTO, on peut insérer un nouvel enregistrement dans une
table. Cette commande est utilisée selon deux formes:
- Première forme : Avec cette première forme, il faut indiquer explicitement les noms des
colonnes à remplir et fournir les valeurs dans le même ordre, selon la syntaxe suivante:
INSERT INTO <nom_Table> (colonne1, colnne2…)
VALUES (valeur1, valeur2…);
Avec cette forme d’insertion, il est possible de ne pas indiquer toutes les colonnes. Comme
conséquence, les colonnes manquantes prendront la valeur NULL (cf. les colonnes ville et
email, dans la figure II.8) ou bien la valeur par défaut (en cas de présence de la contrainte
Default) (cf. la colonne TypeCli).
Exemple 1. La requête suivante est une insertion du client num 512, le résultat est représenté
dans la figure II.817
17
Le contenu de chaque table est accessible depuis l'onglet Données de la table correspondante
Dr. Djellal. A 29
Figure II. 8. Insertion d'enregistrement (1ere forme)
Il est à noter qu'avec cette première forme, l’ordre de colonnes à remplir n’est pas important,
mais il est à respecter avec les valeurs à indiquer.
Exemple 2. La requête suivante est une insertion dont l'ordre de création n'est pas respecté:
- Deuxième forme : Avec cette deuxième forme, il ne faut pas indiquer les noms des
colonnes à remplir. Cependant, il faut, absolument, respecter l’ordre de la création des
colonnes, selon la syntaxe suivante:
INSERT INTO <nom_Table> VALUES (valeur1, valeur2…);
Exemple 3. La requête suivante est une insertion dont les valeurs sont toutes connues, le
résultat est représenté sur la figure II.9 –A-
Figure II. 9. Insertion d'enregistrement (2ème forme)-A-
Avec cette deuxième forme, il faut donner une valeur pour chacune des colonnes de la table.
Ainsi, en cas de manque d’information, il faut fournir la valeur nulle pour la colonne
correspondante
Exemple 4. La requête suivante est une insertion avec des valeurs manquantes, le résultat est
représenté sur la figure II.10 -B-
Dr. Djellal. A 30
Figure II. 10. Insertion d'enregistrement (2ème forme)-B-
A retenir !! Pour insérer la date courante (date du système), SQL offre la

fonction SYSDATE, elle renvoie la date du système sur lequel la BD est
installée, comme le montre la requête suivante dont le résultat est représenté
dans la figure II.11
Figure II. 11. Utilisation de la fonction Sysdate
Vérification des contraintes:

Avant l’insertion des valeurs dans les différentes colonnes, le SGBD vérifie les contraintes
(de domaine et d'intégrité) définies sur les colonnes concernées. En cas de violation de ces
contraintes, un message d’erreur apparaîtra. Le tableau suivant représente une description de
quelques exemples de violation de contraintes.
Tableau II. 6. Violation des contraintes
Requête Message d’erreur Description

insert into Commande unique constraint violated La table contient déjà un
enregistrement dont la clé
values (1, 300, 1, 20); primaire est égale à 1
insert into Commande integrity constraint L’enregistrement

values (2, 300, 1, 20); violated - parent key not référence un client
found introuvable (300)
Dr. Djellal. A 31
insert into Commande Cannot insert NULL into La clé primaire de la table
values (null, 512, 1, ("sys"."commande"."num) ne peut pas être nulle
20);
insert into Commande check constraint violated La colonne Qte est définie
values (3, 512, 1, 0); comme > 0 avec une
contrainte CHECK
6.2. Mise à jour d’enregistrements
A l’aide de la commande UPDATE, on peut modifier le contenu d’une ou plusieurs

colonnes d'une ou plusieurs lignes dans une table. La syntaxe de cette commande est la
suivante :
UPDATE <nom_table> SET <nom_colonne> = valeur
WHERE condition;
A retenir !! La requête ne modifie que la (les) ligne(s) qui vérifie(nt) la

condition indiquée après la clause Where.
Exemple 1. La requête suivante augmente le prix du produit « rame papier » de 1%.
Pour mettre à jour les valeurs d’une colonne pour toutes les lignes, il suffit de ne pas indiquer
une condition.
Exemple 2. La requête suivante augmente les prix de touts les produits de la BD
Vérification des contraintes :
Comme pour les insertions, il faut respecter les contraintes définies au niveau des colonnes.
Dans le cas contraire, une erreur est renvoyée en signalant le nom de la contrainte violée ainsi
la mise à jour ne sera pas effectuée. Par exemple, la modification de la quantité commandée
avec une valeur épuisant le stock.
6.3. Destruction d’enregistrements
La destruction d’un ou plusieurs enregistrements s’effectue avec la clause DELETE

dont la syntaxe est la suivante :
DELETE FROM <nom_table> WHERE condition;
La condition sélectionne les lignes à supprimer. Si aucune condition n’est précisée, toutes les
lignes de la table seront supprimées. Si l’expression ne sélectionne aucune ligne, rien ne sera
supprimé et aucune erreur n’est renvoyée.
Dr. Djellal. A 32
Exemple 1. La requête suivante supprime tout employé dont le nom est Salhi Ahmed
Vérification des contraintes :
La suppression d’un enregistrement peut provoquer une violation d'une contrainte d'intégrité.
En effet, la suppression d'une ligne dont la clé primaire est utilisée dans une autre table en tant
que clé étrangère engendre une incohérence dans la BD.
Exemple 2. Dans cet exemple, une requête de suppression du client num 512 sachant qu’il a
effectué au moins une commande (il figure dans la table commande)
Le résultat sera une erreur renvoyée par le SGBD (CF. Figure II.12) indiquant la violation de
la contrainte et le client ne sera pas supprimé tant qu’il est utilisé (comme référent) dans une
autre table.
Figure II. 12. Violation de la contrainte d'intégrité
7. Interrogation d’une BD
Cette section représente une partie très importante du LMD de SQL. En effet,
interroger une BD est un des grands objectifs de sa création. Interroger une BD revient à
chercher et retrouver des données stockées. Cette opération se résume dans la commande
SELECT. En effet, avec cette commande on peut exécuter plusieurs types de sélection:
- Sélectionner quelques colonnes d'une table

- Sélectionner quelques lignes d'une table en fonction de leur contenu
- Sélectionner des données (ligne(s) et colonne(s)) provenant de plusieurs tables
7.1. Sélection de colonnes
L'objectif de cette commande consiste à retourner le contenu d'une ou plusieurs

colonnes d'une certaine table. Ceci se fait via la commande Select selon la syntaxe
suivante :
Select <column1>, < column2>… from <nom_table>;
Exemple 1. La requête suivante retourne la liste des "nom et prénom" des clients. Le output
de la requête est représenté dans la figure II.13
Dr. Djellal. A 33
Select nom, prénom from Client;
Figure II. 13. Output d'une requête de sélection
A retenir!! Si on veut retourner toutes les colonnes de la table, il faut utiliser

le symbole "*" comme suit : Select * from Client;
La clause DISTINCT ajoutée après SELECT permet d’éliminer les dupliquant dans le résultat
de la requête :
Select distinct typeCli from Client;
7.2. Sélection de lignes
La clause Where ajoutée à la commande Select permet de spécifier quelles sont les
lignes à sélectionner. Cette clause est suivie d'une condition qui sera testée pour chaque ligne.
La syntaxe est la suivante:
SELECT columns FROM <nom_table> WHERE condition;
La condition peut être simple (Cf. exemple 1) ou bien composée (Cf. exemple 2). Les lignes
pour lesquelles la condition est vérifiée seront sélectionnées.
Exemple 1. La requête suivante retourne la liste (toutes les colonnes) des clients habitant à la
ville de Constantine
SELECT * FROM Client WHERE Ville =’Constantine’;
Exemple 2. La requête suivante retourne la liste des produits dont le prix est compris entre
1000 et 5000 DA
SELECT * FROM produit WHERE prix <= 5000 and prix >= 1000;
7.3. Requêtes avancées
Dans la plus part des cas, les données à rechercher sont le résultat d'une jointure de
deux ou plusieurs tables. Avec une opération de jointure (requête SELECT avancée), on peut
combiner plusieurs tables puis sélectionner les données demandées. Afin d’éviter l’ambigüité,
Dr. Djellal. A 34
il faut préciser le nom de la table avec le nom de la colonne, comme le montre la syntaxe
suivante :
Select <tab1.col1>, <tab1.col2>, <tab2.col1> …
from table1, table2 … Where condition;
Exemple 1. La requête suivante retourne la liste des clients (nom, prénom) qui ont
commandés plus de 50 unités de nos produits pendant les mois de janvier et février.
Select Client.nom, client.Prénom from client, commande
Where commande.codcli = client.codcli
And Commande.qte >50
And commande.datecomm BETWEEN '01/02/2018' and '31/03/2018';
A retenir!! Pour simplifier l'écriture des requêtes, il est possible de renommer

les tables et procéder comme suit:
Select <A.col1>, <A.col2>, <B.col1> …
from table1 A, table2 B … Where condition;
La requête de l'exemple 1 devient:

Select C.nom, C.Prénom from client C, commande M
Where M.codcli = c.codcli
And M.qte >50
And M.datecomm BETWEEN '01/02/2018' and '31/03/2018';
7.4. Requêtes en cascade
Une requête en cascade consiste à effectuer une requête à l'intérieur d'une autre (sous
requêtes). La sous requête doit être placée à la suite d'une clause WHERE. Comme le montre
la syntaxe suivante:
Select columns from tables
where <column> op (select columns from tables
where <column> op (select ... ));
La condition de la requête est exprimée à l'aide d'un opérateur "op" qui peut être un opérateur
booléen (<, >, =..) ou bien un opérateur ensembliste (in, not in...). Selon le type de l'opérateur
de la condition, deux cas sont envisagés:
i. La sous requête renvoie obligatoirement une constante (une et une seule valeur). Cette
dernière sera comparée avec la valeur d'une colonne via un opérateur booléen (Cf.
exemple 1)
ii. La sous requête renvoie une table (une ou plusieurs lignes). Ainsi, la valeur de la colonne
utilisée dans la condition sera comparée avec l'ensemble de lignes retourné à l'aide d'un
opérateur ensembliste (Cf. exemple 2)
Dr. Djellal. A 35
Exemple 1. La requête suivante retourne la liste des produits (désignation) dont le prix est
supérieur à celui du produit numéro 2. Pour cela, une sous requête, retournant le prix du
produit num 2, à été utilisée.
Select désignation from produit
Where prix > (select prix from produit
Where CodPro =2);
Exemple 2. La requête suivante retourne la liste des clients (nom, prénom) qui ont effectués
au moins une commande. Pour cela, une sous requête, retournant la liste des clients figurant
dans la table commande, à été utilisée.
Select nom, prénom from Client

Where codCli in (Select distinct codCli from Commande);
Activité. Formuler une autre requête équivalente à celle de l'exemple 2.
8. Fonctions d'agrégation
Les fonctions d’agrégation utilisées dans les requêtes SQL permettent d’effectuer des
opérations statistiques sur une table ou bien une sélection d’enregistrements et retournent
toujours une seule valeur. On peut, par exemple, demander de retourner le nombre de ligne
dans une table ou bien le max/min/moyenne des valeurs d'une certaine colonne. La syntaxe
générale des requêtes utilisant ces fonctions est la suivante:
Select function (colonne) from table;
8.1. La fonction COUNT ( )
COUNT ( ) est une fonction qui sert à compter le nombre de lignes d’une table ou d'une
sélection. Pour compter le nombre total de ligne d’une table, il convient d’utiliser le symbole
étoile "*" selon la syntaxe serait alors la suivante :
SELECT COUNT(*) FROM table
Le résultat de cette requête sera un entier indiquant le nombre des enregistrements de la table
(0, si la table est vide)
Exemple 1. La requête suivante retourne le nombre de produits insérés dans la table Produit:
SELECT COUNT(*) FROM Produit;
Nous pouvons aussi utiliser la fonction COUNT pour compter le nombre d’enregistrement
non vide dans une colonne. Pour cela, il faut appliquer la fonction Count sur une colonne.
Exemple 2. La requête suivante retourne le nombre total des produits ainsi que le nombre de
produits dont le prix a été renseigné dans la table Produit. Le résultat de la requête s'affiche
dans la partie Query Result comme le montre la figure suivante:
Dr. Djellal. A 36
Figure II. 14. La fonction statistique COUNT
8.2. Les fonctions Min ( )/Max ( )
Les fonctions Min ( )/MAX ( ) retournent la valeur la plus grande / la valeur la plus petite
d’une colonne d’une table ou d’une sélection
Exemple 3. La requête suivante retourne le prix le plus élevé de nos produits:
SELECT Max(Prix) FROM Produit ;
A retenir!! Les colonnes nulles sont ignorées dans ces fonctions. De plus, si
elles sont appliquées sur une colonne dont toutes les valeurs sont nulles alors
le résultat sera aussi nul
8.3. La fonction SUM ( )
Cette fonction Retourne la somme des valeurs d’une colonne d’une table ou d’une sélection.
Exemple 4. La requête suivante retourne la somme des quantités commandées par le client
numéro 512.
Select sum (Qte) from Commande
Where CodCli=512;
A retenir!! Cette fonction ne peut être appliquée qu’avec des colonnes

numériques
8.4. La fonction AVG ( )
La fonction AVG renvoie la moyenne des valeurs d’une colonne.
Exemple 5. La requête suivante retourne la moyenne des prix des différents produits:
Select AVG (prix) from Produit;
A retenir!! Tout comme SUM, La fonction AVG ne peut être appliquée

qu’avec des champs numériques
Dr. Djellal. A 37
8.5. Les Alias
Utiliser une fonction statistique résulte à une colonne dont le nom peut-être un peu complexe
(Cf. Figure II.14). SQL offre la possibilité d'utiliser un Alias pour renommer temporairement
la colonne sur laquelle il y a une fonction SQL ce qui facilite la lecture du résultat. Les Alias
de SQL peuvent être utilisés comme le montre la syntaxe suivante:
SELECT fonction (column) AS nom_colonne FROM table
Exemple 1. La requête suivante retourne le nombre de produits ayant un prix qui dépasse
10000 DA, le résultat a été renommé en "Procduits_chers"
Figure II. 15. Utilisation des Alias
9. Organisation du résultat d'une requête

9.1. La clause group by
Dans une requête de sélection, la clause GROUP BY est utilisée pour regrouper plusieurs
lignes ayant une colonne identique à l'aide d'une fonction statistique. C'est-à-dire si une
colonne particulière a les mêmes valeurs dans différentes lignes, la clause Group by
organisera ces lignes dans un seul groupe. Cette clause peut être utilisée selon la syntaxe
suivante:
SELECT column1, column2,...
Function (column i)
FROM tables
[WHERE conditions]
GROUP BY column i;
A retenir!! Group by c'écrit toujours après la clause Where (si elle existe)
Exemple1. La requête suivante retourne, pour chaque client, la somme des quantités
commandées.
Dr. Djellal. A 38
Figure II. 16. La clause Group by (A)
La même requête, sans la clause group by, donne le résultat suivant:
Figure II. 17. La clause Group by (B)
9.2. La clause ordre by
La clause ORDER BY permet de trier le résultat d'une requête. L’ordre de

tri est par défaut croissant. Le tri peut se faire selon une ou plusieurs colonnes séparer par des
virgules. Ordre by peut être utilisé selon la syntaxe suivante:
SELECT column1, column 2...
FROM table1, table 2...
[Where condition]
[Group by column i]
ORDER BY column1, column2...;
Exemple 1. La requête suivante retourne la liste des clients ordonnés selon l'Age
Figure II. 18. La clause Ordre by appliquée sur une seule colonne
Dr. Djellal. A 39
Exemple 2. La requête suivante retourne la liste des clients ordonnés selon l'Age et le Nom
Figure II. 19. La clause Ordre by appliquée sur plusieurs colonnes
A retenir!! Il est possible de définir l'ordre décroissant avec la clause ordre

by en ajoutant d'option DESC.
SELECT column FROM table
ORDER BY column Desc;
Dr. Djellal. A 40
Chapitre III :
Gestion des événements

Chapitre III : Gestion des événements
1. Déclencheurs ou Triggers
Les triggers sont des procédures stockées qui s’exécutent implicitement

(automatiquement) suite au déclenchement d'un événement. Pour maintenir la cohérence de la
BD, généralement une m à j provoque automatiquement d'autres m à j, lance une alerte ou
nécessite une vérification, etc.
Exemples.
- L’incrémentation de 1 de l'effectif des employés suite à une nouvelle insertion.
- La propagation de m à j des clés primaires pour assurer l'intégrité référentielle.
- Lancement du réapprovisionnement suite à une commande qui a, considérablement, fait
diminuer le stock.
Différents type de triggers peuvent être crées: la différence réside dans (i) le type de
l'événement déclenché, (ii) le mode du trigger ou (iii) le moment de son exécution par rapport
à l'évènement. En considérant ces trois cas, 12 types de trigger peuvent être définis selon :
- L'évènement : pour une certaine table de la BD, trois types d'évènements peuvent surgir:
o Insertion d'un nouvel enregistrement (INSERT);
o Mise à jour des données d'un ou plusieurs enregistrements (UPDATE);
o Suppression d'un ou plusieurs enregistrements (DELETE);
- Le mode : il existe deux modes de trigger
o Trigger de table: qui s'exécute une seul fois suite à un événement déclenché sur une
table;
o Trigger de linge: qui s'exécute sur chaque ligne de la table (FOR EACH ROW). Il est
possible de préciser quelques lignes avec une condition (WHEN);
- Le moment : le trigger s'exécute selon deux moments
o Avant l'exécution de l'action de l'événement (BEFORE) ;
o Apres l'exécution de l'action de l'événement (AFTER).
1.1. Triggers Before
Avec l'option BEFOR, un trigger de table effectue un traitement avant l'exécution de l'action
de l'évènement. Ceci signifie que le trigger sert à soumettre l’action de l'évènement à une
condition. On peut, par exemple, vérifier certaines conditions avant la m à j d'une table avec
émission d’un message d’erreur si les conditions ne sont pas vérifiées
1.2. Triggers After
Avec l'option AFTER, un trigger de table effectue un traitement après l'exécution d'e l'action
de l'évènement. Ainsi, il peut servir à faire des validations a posteriori afin de vérifier que les
modifications se sont bien déroulées. Il peut aussi permettre de propager les m à j dans
d'autres tables
1.3. Priorités des triggers
Il est possible d’associer plusieurs triggers à une même table. Dans ce cas, l’ordre de leurs
exécutions est le suivant :
Dr. Djellal. A 42
1. Trigger de table de type BEFORE

2. Trigger de ligne (FOR EACH ROW)
1. Ligne de type BEFORE
2. Ligne de type AFTER
3. Trigger de table de type AFTER
A retenir !! Un et un seul trigger de chaque type peut être associé à une table.
3. Création d’un trigger
La création d'un trigger nécessite la spécification de (i) l'événement qui le déclenche:

il est possible de spécifier un événement, deux ou bien trois via les commandes SQL:
Insert, Update ou bien Delete. Il faut aussi préciser (ii) le nom de la table associée. De
plus, (iii) il faut déterminer le type du trigger. Ceci indique à Oracle quand déclencher le
trigger par rapport à l'évènement spécifié et combien de fois il faut l'exécuter. Le type de
trigger est déterminé par les options Befor, After et For each row. Après avoir
précisé l'événement, le type, le mode et la table, il est maintenant nécessaire (iv) de définir le
corps du trigger. Celui-ci contient des commandes SQL qui s'exécutent une fois le trigger est
déclenché.
A retenir!! Pour chaque trigger, on peut associer une et une seule table.
Seulement les instructions LMD sont autorisées. Les instructions LDD et LCT
ne sont pas autorisées.
La syntaxe générale de la création du trigger est la suivante :

CREATE [OR REPLACE] TRIGGER <nom-trigger>
Before | after Evénement [OR événement] [OR événement]
ON <nom-table>
[For each row] [When (condition)]
Begin
Commandes SQL;
End;
3.1. Trigger de table
Un trigger de table est déclenché une seule fois si l’événement se produit. La syntaxe suivante
permet de créer un trigger de table:
CREATE [OR REPLACE] TRIGGER <nom-déclencheur>
before | after Evénement [OR événement] [OR événement]
ON <nom-table>
Begin
Commandes SQL;
End;
Dr. Djellal. A 43
Remarque. Pour des besoins d'archivage, une nouvelle table à été ajouté à notre BD Cours. Il
s'agit de la table Archive. Cette table sera utilisée pour garder la trace des différentes
opérations (insertion, m à j, suppression) effectuées sur les tables Client, Produit et
Commande. Ainsi, chaque opération (événement) provoque l'insertion d'une nouvelle ligne
dans la table Archive indiquant le type de l'opération, la table affectée et la date de l'opération.
Le schéma de la table Archive est le suivant:
Archive (tab varchar (10),
typeOperation varchar2 (20),
dateOp date)
Les exemples de ce chapitre vont manipuler la table Archive.
Exemple 1. Le script suivant représente la création d'un trigger de table d'ordre insert, il sera
déclenché après (After) chaque insertion (insert) sur la table Client (on Client)
Figure III. 1. Trigger de Table d'ordre insert
L'exécution de ce script engendre la création du trigger Archivage, sur l'onglet script output le
message "Trigger ARCHIVAGE compiled" sera affiché. La création du trigger
n'implique pas son exécution, il se déclenchera automatiquement suite à une nouvelle
insertion sur la table Client (l'événement déclencheur). Ainsi, l'insertion dans la table Client
(sur l'onglet script output le message "1 row inserted." Sera affiché) va, automatiquement,
engendrée une insertion dans la table Archive, on peut afficher le contenu de la table via une
sélection, le résultat sera affiché sur l'onglet Query Result, comme le montre la figure
suivante:
Figure III. 2. Exécution d'un trigger de table (A)

Exemple 2. Le script suivant est un trigger de table d'ordre update, il se déclenche suite à une
m à j de la table produit (n'importe qu'elle mise à jour)
Dr. Djellal. A 44
Figure III. 3. Trigger de table d'ordre update (A)
Avec un trigger d'ordre update, il est possible de préciser il s'agit de quelle m à j (préciser la
colonne(s) concernée(s) par la m à j). Ainsi, le trigger ne sera pas déclenché sauf si les
colonnes précisées ont été touchées par la m à j. Ceci est fait en ajoutant la clause Update
Of comme le montre la syntaxe suivante:
CREATE [OR REPLACE] TRIGGER <nom-déclencheur>
Before | after update of <nom_colonnes>
ON <nom-table>
Begin
Commandes SQL;
End;
Exemple 3. Archivage3 (Cf. Figure III.4) est un trigger de table d'ordre update sur la colonne
Qte de la table Commande. Il ne sera déclenché qu'après m à j de la colonne Qte.
Figure III. 4. Trigger de table d'ordre update (B)
La m à j de n'importe quelle colonne de la table Produit (Cf. Figure III.5) lance le trigger
Archivage2. Cependant, Archivvage3 est lancé seulement si la m à j de la table Commande
touche la colonne Qte
Dr. Djellal. A 45
Figure III. 5. Exécution d'un trigger de table (B)
3.2. Trigger de ligne
Un trigger de ligne se défini avec l'option FOR EACH ROW comme le montre la syntaxe ci de
sous. Il se déclenche pour chaque ligne affectée par l'événement déclencheur du trigger. Ce
genre de trigger peut être utilisé, par exemple, pour consulter les valeurs des attributs touchés
par une m à j.
CREATE [OR REPLACE] TRIGGER <nom-trigger>
Before | after Evénement [OR événement] [OR événement]
ON <nom-table>
For each row [when (condition)]
Begin
Commandes SQL;
End;
Exemple 4. Archivage2 (Cf. Exemple 2) a été supprimé et remplacé par Archivage4 (Cf.
Figure III.6), c'est un trigger de ligne d'ordre update, il s'exécute suite à une m à j sur la table
Produit
Figure III. 6. Trigger de ligne d'ordre m à j
Dr. Djellal. A 46
Une m à j qui touche 4 lignes de la table Produit déclenche 4 fois l'exécution de Archivage4
comme le montre la sélection sur la table Archive (Cf. Figure III.7)
Figure III. 7. Exécution d'un trigger de ligne
A retenir !! Un trigger de ligne s’exécute pour chaque ligne affectée par

l’événement. Donc, si aucune ligne n’est affectée, le trigger ne s’exécutera
pas, à l’inverse de celui de table qui s’exécute une seule fois quelque soit le
nombre de lignes affectées par l’événement.
3.2.1. Usage de OLD et NEW

Avec un trigger de lignes, il est possible d’avoir accès à l’ancienne valeur et à la nouvelle
valeur d’une colonne grâce aux mots clés OLD et NEW. La nouvelle valeur est accessible via
l'annotation :new.column. Quand à l'ancienne valeur, elle est accessible via l'annotation
:old.column. Par exemple, on peut avoir accès à la nouvelle/ancienne valeur de la colonne
Prix après modification avec :new.Prix/:old.prix. Comme le montre le tableau
suivant, old et new n'ont pas tout le temps des valeurs significatives.
Tableau III. 1. Valeur Old et New dans les différents événements
Evénement :old :new

Insert Null Valeur crée
Delete Valeur avant suppression Null
Update Valeur avant m à j Valeur après m à j
Dr. Djellal. A 47
Exemple 5. Pour mieux archiver les opérations effectuées sur la BD, deux colonnes ont été
ajoutées au schéma de la table Archive. Il s'agit de Ancienne_Qte et Nouvelle_Qte. De plus,
Archivage3 (Cf. Exemple 3) a été supprimé et remplacé par Archivage5 (Cf. Figure III.8).
C'est un trigger de ligne d'ordre update, il s'exécute suite à une m à j sur la table Commande
pour inclure l'ancienne et la nouvelle valeur de la colonne Qte affectée par la m à j. Ainsi, une
m à j de la Qte de la commande num 4 engendre l'insertion d'une nouvelle linge dans la table
Archive indiquant l'ancienne et la nouvelle valeur de la colonne Qte (115/125) comme le
montre la dernière ligne de la table Archive (Cf. Figure III.8).
Figure III. 8. Usage de Old et New dans un trigger de ligne d'ordre update
A retenir !! New et old ne sont accessible que via un trigger de ligne (For
each row).
3.2.2. Usage de la clause When

Avec un trigger de ligne, il est possible de filtrer les lignes sur les quelles il sera exécuté en
ajoutant une condition via la clause WHEN. Ainsi, le trigger s'exécutera seulement sur les
lignes (i) concernées par l'événement et (ii) qui vérifient la condition de When.
Exemple 6. Archivage5 (Cf. Exemple 5) a été modifié et recompilé en luis ajoutant la clause
When avec la condition (Old.Qte >130). C'est un trigger d'ordre update, il s'exécutera
ainsi sur toutes les lignes affectées par la m à j (deux lignes, dans l'exemple). Cependant, la
clause When filtre une seule ligne dont la Qte est supérieur à130, ce qui explique l'ajout d'une
seule ligne dans la table Archive.
Dr. Djellal. A 48
Figure III. 9. Effet de la clause When dans un trigger de ligne
A retenir !! La syntaxe de old / new dans la condition de la clause when est

sans les deux points (:)
4. Manipulation des Triggers
4.1. Modification d'un trigger
La clause OR REPLACE ajoutée après CREATE autorise la modification du trigger crée.

Toutefois, après avoir ajouté les modifications nécessaires, il faut ré-exécuter (recompiler) la
commande Create pour remplacer le trigger an question avec celui modifié. Dans le cas où
la clause n'a pas été ajoutée, il faut supprimer le trigger ensuite le recréer après l'ajout des
modifications nécessaires.
A retenir !! Il est fortement conseillé d'utiliser la clause "or Replace"
4.2. Activation / Désactivation d'un trigger
Un trigger est activé dès sa création. Cependant, il est possible de le désactiver

momentanément pour effectuer une certaine tâche, un test par exemple, sans le déclencher.
Pour ce faire, il faut modifier le trigger en question via la commande ALTER avec les options
DISABLE, pour désactiver le trigger, et ENABLE, pour le réactiver, selon la syntaxe suivante:
Alter trigger <nom_trigger> disable|enable;
Exemple 7. La commande suivante permet de désactiver le trigger màjStock.

Alter trigger majStock disable;
Dr. Djellal. A 49
Il est aussi possible de désactiver / réactiver tout les triggers associés à une table avec la
commande ALTER comme suit:
Alter table <nom_table> DISABLE|ENABLE all triggers;
Exemple 8. La commande suivante permet de désactiver tout les triggers associés à la table
Produit:
Alter table Produit DISABLE all triggers;
4.3. Destruction d'un trigger
Dans le cas où nous ne voulons plus utiliser le trigger, il faut le supprimer avec la commande
Drop selon la syntaxe suivante:
Drop trigger <nom_trigger>;
Exemple 9. La commande suivante permet de supprimer le trigger majStock:
Drop trigger majStock;
4.4. Informations sur les triggers
Pour connaître la liste des triggers créés, il est possible de consulter la table Oracle
USER_TRIGGERS. Cette table (Cf. Figure III.10) contient toutes les informations des triggers
crées par les utilisateurs de la BD : nom, type, événement déclencheur, état ....
A retenir !! Pour afficher les colonnes de la table User_Trrigers, il est

possible d'utiliser la commande DESC.
Figure III. 10. Informations sur les Triggers
Dr. Djellal. A 50
Liste des Références
CROZAT, S. Conception des bases de données IV Bases de données non-relationnelles.
Gardarin, G. (2003). Bases de données. Editions Eyrolles.
Gruau, C. (2005). Rudiments SQL pour Oracle.
Rigaux, P. (2001). Cours de bases de données.. CNAM/Médias.
Soutou, C. (2013). SQL pour Oracle. Editions Eyrolles.
Soutou, C. (2013). SQL pour Oracle. Editions Eyrolles.
https://db-engines.com
https://db-engines.com
https://www.developpez.com
https://www.statista.com
Dr. Djellal. A
Table des matières
Sommaire ........................................................................................................................................... ii
Liste des tableaux .............................................................................................................................. iii
Liste des figures ................................................................................................................................. iv
Chapitre I : Systèmes de Gestion des Bases de Données ......................................................................5
1. Introduction ................................................................................................................................6
2. Processus de développent de Bases de Données .........................................................................6
3. Modèle Relationnel de Données..................................................................................................6
3.1. Eléments du modèle relationnel ..............................................................................................7
3.2. Clé primaire ............................................................................................................................8
3.3. Clé étrangère ...........................................................................................................................8
4. Système de Gestion de Bases de Données ...................................................................................9
4.1. SGBD : historique ....................................................................................................................9
4.2. Architecture ANSI/SPARC ...................................................................................................... 10
4.2.1. Niveau externe ........................................................................................................... 10
4.2.2. Niveau conceptuel ...................................................................................................... 11
4.2.3. Niveau interne ........................................................................................................... 11
4.3. Fonctionnalités des SGBD ...................................................................................................... 12
4.3.1. Description des données ............................................................................................ 12
4.3.2. Indépendance physique des données........................................................................... 12
4.3.3. Indépendance logique des données ............................................................................. 13
4.3.4. Manipulation des données .......................................................................................... 13
4.3.5. Contrôle des données ................................................................................................. 13
4.3.6. Partage des données .................................................................................................. 13
4.4. SGBD leaders......................................................................................................................... 14
Chapitre II : Structured Query Language ........................................................................................... 16
1. Introduction .............................................................................................................................. 17
2. Oracle ....................................................................................................................................... 17
3. Oracle SQL Developer................................................................................................................ 19
4. Différentes familles du langage SQL .......................................................................................... 19
5. Langage de Définition de Données ............................................................................................ 20
5.1. Description des données ....................................................................................................... 20
5.1.1. Création de tables ...................................................................................................... 20
5.1.2. Renommer une table .................................................................................................. 21
Dr. Djellal. A
5.1.3. Destruction d'une table .............................................................................................. 21
5.1.4. Modification du schéma d'une table ........................................................................... 21
5.2. Nommage et types de données SQL ...................................................................................... 23
5.2.1. Types de données Caractères ..................................................................................... 23
5.2.2. Types de données numériques.................................................................................... 24
5.2.3. Types de données temporels ..................................................................................... 24
5.3. Description des contraintes ................................................................................................... 25
5.3.1. Contraintes de domaine ............................................................................................. 26
5.3.2. Contraintes d’intégrité ............................................................................................... 27
6. Langage de Manipulation de Données ....................................................................................... 29
6.1. Insertion d’enregistrements .................................................................................................. 29
6.2. Mise à jour d’enregistrements ............................................................................................... 32
6.3. Destruction d’enregistrements .............................................................................................. 32
7. Interrogation d’une BD .............................................................................................................. 33
7.1. Sélection de colonnes ............................................................................................................ 33
7.2. Sélection de lignes................................................................................................................. 34
7.3. Requêtes avancées ................................................................................................................ 34
7.4. Requêtes en cascade ............................................................................................................. 35
8. Fonctions d'agrégation .............................................................................................................. 36
8.1. La fonction COUNT ( ) ............................................................................................................ 36
8.2. Les fonctions Min ( )/Max ( ) .................................................................................................. 37
8.3. La fonction SUM ( ) ................................................................................................................ 37
8.4. La fonction AVG ( ) ................................................................................................................ 37
8.5. Les Alias ................................................................................................................................ 38
9. Organisation du résultat d'une requête ..................................................................................... 38
9.1. La clause group by ................................................................................................................. 38
9.2. La clause ordre by ................................................................................................................. 39
Chapitre III : Gestion des évenements .............................................................................................. 41
1. Déclencheurs ou Triggers .......................................................................................................... 42
1.1. Triggers Before ..................................................................................................................... 42
1.2. Triggers After........................................................................................................................ 42
1.3. Priorités des triggers .............................................................................................................. 42
3. Création d’un trigger ................................................................................................................. 43
3.1. Trigger de table ..................................................................................................................... 43
3.2. Trigger de ligne ..................................................................................................................... 46
3.2.1. Usage de OLD et NEW .............................................................................................. 47
Dr. Djellal. A
3.2.2. Usage de la clause When ........................................................................................... 48
4. Manipulation des Triggers ......................................................................................................... 49
4.1. Modification d'un trigger ....................................................................................................... 49
4.2. Activation / Désactivation d'un trigger................................................................................... 49
4.3. Destruction d'un trigger ........................................................................................................ 50
4.4. Informations sur les triggers .................................................................................................. 50
Liste des Références ......................................................................................................................... 51
Table des matières............................................................................................................................ 52
Annexes ............................................................................................................................................ 55
Série de TP n° 01: instalation et découverte ........................................................................................ I
Série de TP n° 02: SQL: Langage de Définition des Données ..............................................................II
TP 01. La BD Formation .......................................................................................................................II
TP 02. La BD Projet ..............................................................................................................................II
TP 03. La BD Vente .............................................................................................................................III
Série de TP n° 03: LDD et LMD ....................................................................................................... IV
TP 01. La BD Formation ..................................................................................................................... IV
TP 02. La BD Projet ............................................................................................................................. V
Série de TP n° 04 : LMD ................................................................................................................. VI
TP 01. La BD Projet ............................................................................................................................ VI
TP 02. La BD Vente ............................................................................................................................ VI
Série de TP n° 05 : Les Triggers ..................................................................................................... VIII
TP 01. La BD Cours .......................................................................................................................... VIII
Dr. Djellal. A
Annexes
Annexes
Série de TP n° 01
Installation & découverte
I. Installation
1. Vérifier le type du système d'exploitation installé sur vos machines
o Clic droit sur Ordinateur / Propriétés
o Dans la partie Système cherchez l'information Type du système.
2. Accéder au répertoire D:/ Oracle/outils
Pour chacun des outils à installer, choisissez la version adéquate à votre système (32/64 bits)
3. Installez la plateforme Java (JDK)
o Gardez soigneusement le path (chemin) de l'installation
4. Installez Oracle Database 12c Release2 V12.2.0.1.0
o Gardez soigneusement les informations introduites durant l'installation (mot de
passe, nom de la BD ...)
5. Lancez l’interface Client SQL Developer
o Introduisez le path du JDK (action requise seulement au premier lancement de
SQL Developer)
II. Préparation de la connexion
1. Créez l'utilisateur myUser
o Mot de passe userbda

o Attribuez à myUser tout les rôles/privilèges.
2. Créez une connexion avec les informations suivantes
o Connection name: cours BDA

o Username: myUser
o Password : uersbda
o Connection type : basic
o Role : default
o SID: orcl
3. Testez puis confirmez la connexion
Vous pouvez maintenant commencer à créer des tables et à insérer des données...
Dr. Djellal. A I
Annexes
Série de TP n° 02
SQL: Langage de Définition de Données (LDD)
TP 01. La BD Formation
Soit la BD Formation dont le schéma relationnel est le suivant:

COURS (IdCours, Jour, Heure)
LIEU (IdCours, IdSalle)
ETUDIANT (IdEtudiant, Nom, Adresse)
RELEVE (IdCours, IdEtudiant, Note)
Ecrivez le script SQL qui permet de créer cette BD. En se référant au schéma relationnel,
choisissez les types de données qui vous semblent logique et appliquez les contraintes
nécessaires en utilisant le mode on ligne, sachiez que :
- Le centre de formation contient deux salles (S1 et S2).

- Le nom de l'étudiant de doit pas être nul.
- Le centre de formation ferme ses portes le weekend (vendredi et samedi)
- La majorité des étudiants sont des constantinois
- Le mode d'évaluation utilisé est celui d'une note /20
TP 02. La BD Projet
Soit la BD Projet dont le schéma relationnel est le suivant:

Département (IdD, NomD)
Employés (IdE, Nom, Prénom, Salaire, Fonction, IdD)
Projet (IdP, Intitulé, Cout, DateRéalisation)
Participation (IdE, IdP, Fonction)
1. Créez la base Projet en se référant au schéma ci-dessus, choisissez les types de données
qui vous semblent logique et appliquez les contraintes nécessaires, sachiez que :
- Les fonctions possibles pour la réalisation d’un projet sont : Développeur, Testeur et
Chef.
- L'intitulé de chaque projet ne doit pas être nul
- Le cout d'un projet doit être strictement positif.
- Les projets sont par défaut finalisés (date de réalisation) une année après leur
lancement.
o Indication: l'expression 24/01/2022 + interval '1' year est égale à 24/01/2023
2. Ecrivez le script SQL qui permet d’ajouter à la table Employer la colonne Ville qui
indique la ville de résidence des employés. Cette dernière aura la valeur ‘Constantine’ par
défaut.
3. Les salaires des employés sont compris entre 65000.00 et 100000.00. Ecrivez la requête
SQL pour appliquer cette règle.
4. Ecrivez le scripte SQL qui permet de supprimer les tables de cette BD.
Dr. Djellal. A II
Annexes
TP 03. La BD Vente
Soit la BD Vente dont le schéma relationnel est le suivant:

Client (NoCli, NomCli, NoTel)
Article (NoArt, description, PrixU, stock)
Commande (NoCom, DateCom, NoCli)
LigneCommande (NoCom, NoArt, Qte)
Livraison (Noliv, DateLiv)
detailLivraison (Noliv, NoCom, NoArt,QteLiv)
1. Ecrivez le script SQL qui permet de créer cette BD. En se référant au schéma relationnel,
choisissez les types de données qui vous semblent logique et appliquez les contraintes
nécessaires en utilisant le mode on ligne, sachiez que :
- Les Prix, stock et quantité commandée sont strictement positives.
- Les dates de commande et de livraison ne doivent pas être nulles.
- Indication : pour définir la clé étrangère (Noliv, NoCom) de la table
detailLivraison, utilisez la contrainte en ligne:
FOREIGN KEY(noCommande,noArticle)REFERENCES LigneCommande
2. La quantité livrée doit être strictement positive. Ecrivez la requête SQL pour appliquer
cette règle.
3. Désactivez cette contrainte puis réactivez-la
4. Le stock de chaque produit est initialement par défaut égal à zéro. Ecrivez la requête SQL
pour appliquer cette règle.
5. Supprimez cette contrainte
Dr. Djellal. A III

Annexes
Série de TP n° 03
SQL: LDD & LMD
TP 01. La BD Formation
Soit le schéma en extension de la BD Formation (cf. Série de TP n°02) suivant:

COURS LIEU
IdCours Jour Heure IdCours IdSalle
Excel Lundi 9 Excel S1
BDA Mardi 9 BDA S2
RO Jeudi 9 ERP S1
ERP Mardi 14
ETUDIANT RELEVE
IdEtudiant Nom Adresse IdCours IdEtudiant Note
100 Salhi Constantine Excel 100 18
200 Ben Ali Constantine Excel 300 18
300 Moussa Annaba ERP 100 16
ERP 200 18
ERP 300 16
BDA 100 13
BDA 200 18
1. Exécuter le script SQL Formation.SQL se trouvant dans le répertoire D:\ en exécutant la

commande: @D\Formation.SQL;
2. Ecrivez le script SQL permettant de remplir les tables de la base
3. Ajouter la colonne Age à la table Etudiant, sachant que l'âge d'un étudiant est compris
entre 18 et 35 ans
4. Les cours dispensés (IdCours) sont Excel, BDA et ERP. Ecrivez la requête SQL pour
appliquer cette règle.
5. Il y a eu une erreur dans l'évaluation de l'étudiant 100 dans le module ERP, sa note après
rectification est 16.5. Ecrivez la requête SQL permettant de faire cette m à j.
6. Un nouvel étudiant veut s'inscrire, il s'agit de Miloud, 36 ans, habitant à Alger. Ecrivez la
requête SQL permettant son inscription. Que remarquez-vous?
7. Désactivez la contrainte portant sur l'âge et continuer l'inscription
8. Le nouvel étudiant (Ben Amer) à été inscrit, il a passé l'évaluation du module DBA et il a
eu un 14.5. Ecrivez le script SQL permettant de faire cette m à j.
Dr. Djellal. A IV
Annexes
TP 02. La BD Projet
Soit le schéma en extension de la BD Projet (cf. Série de TP n°02) suivant:
Département Projet
IdD Nom IdP Intitulé Cout DateRéalisation
01 Informatique 01 SIG Constantine 200000.00 15/02/2024
02 Ressources Humaines 02 SI Vente 170000.00 30/06/2023
03 Vente 03 Supervision ERP 230000.00 10/09/2023
04 Gestion RH 150000.00 31/03/2024
Employés
IdE Nom Prénom Salaire Fonction IdD
01 Ben Saleh Ahmed 70000.00 Assistant 02
02 Saidi Ali 70000.00 Assistant 03
03 Hacini Rima 80000.00 Ingénieur 01
04 Ben abid Wafa 90000.00 Chef de département 01
Participation
IdE IdP Fonction
04 01 Développeur
03 01 Développeur
02 03 Chef
02 02 Testeur
04 02 Développeur
03 03 Testeur
1. Exécuter le script SQL Projet.SQL se trouvant dans le répertoire D:\ en exécutant la

commande: @D\Projet.SQL;
2. Ecrivez le script SQL permettant de remplir les tables de la base
3. Les employés des départements 01 et 03 méritent une augmentation de 3% de leurs
salaires. Ecrivez la requête SQL qui permet d’appliquer cette augmentation.
4. La participation de l’employer numéro 04 au projet numéro 01 a été annulée. Ecrivez une
requête SQL qui permet d’appliquer cette réalité.
5. Un nouveau projet « SIG Alger » a été lancé avec un cout de réalisation estimé de
300000.00 DA. Trois employés s’en chargent : l’employer numéro 03 comme ingénieur,
numéro 04 comme chef et numéro 05 comme testeur. Ecrivez le script SQL qui permet
d’appliquer cette mise à jour.
6. L'employé numéro 01 a démissionné, appliquez cette m à j.
7. Virez les employés qui ne participent à la réalisation d'aucun projet
Dr. Djellal. A V
Annexes
Série de TP n° 04
SQL: LMD
TP 01. La BD Projet
Considérons la BD Projet (cf. Série de TP n°02)
Exécuter le script SQL Projet2.SQL se trouvant dans le répertoire D:\ en exécutant la

commande: @D\Projet2.SQL;
Exprimer en SQL les requêtes suivantes:
1. Afficher la liste des projets

2. Afficher la liste des projets par ordre décroissant sur l'intitulé
3. Afficher la liste des projets par ordre croissant sur la date de réalisation
4. Afficher la liste des fonctions des employés sans redondance
5. Afficher le nombre d'employés
6. Afficher le nombre d'employé dans chaque département
7. Afficher la liste des employés concernés par la réalisation des projets
8. Afficher, pour chaque projet, la liste des employés concerné par sa réalisation
9. Afficher la liste des employés dont le salaire dépasse 70000.00 DA
10. Afficher la liste des employés dont le salaire dépasse la moyenne des salaires de la
compagnie.
11. Qui est le chef du projet "Supervision ERP"
12. Afficher le projet dont le cout est le plus élevé
13. Afficher la liste des départements qui sont concerné par la réalisation des projets
14. Afficher la liste des départements qui ne sont pas concerné par la réalisation des projets
TP 02. La BD Vente
Considérons la BD Vente (cf. Série de TP n°02)
Exécuter le script SQL Projet2.SQL se trouvant dans le répertoire D:\ en exécutant la

commande: @D\Projet2.SQL;
Exprimer en SQL les requêtes suivantes:
1. Afficher les numéros et les dates des Commandes du Client num10 dont le numéro est
supérieur à 5
2. Afficher les numéros et les descriptions des Articles dont le prix unitaire est compris entre
1000 DA et 2500 DA.
 Indication: Utiliser la clause Between
3. Afficher les numéros et les noms des clients ainsi que leurs numéros des commandes
faites le 4/04/2022.
4. Afficher l'article dont le prix unitaire est le minimum
Dr. Djellal. A VI
Annexes
5. Afficher les numéros des articles commandés au moins une fois par le Client numéro 10
après le 01/04/2022.
6. Afficher les numéros des livraisons correspondants aux Commandes faites par le Client
numéro 10
7. Afficher les numéros des Commandes qui ont été placées à la même date que la
Commande numéro 2
8. Afficher les numéros et les noms des Clients qui n'ont pas effectués de commandes au
mois de mars de l'année 2022.
9. Afficher les numéros des Commandes qui ne contiennent pas l'Article numéro 10.
10. Afficher les numéros des articles qui apparaissent dans toutes les Commandes.
11. Afficher les numéros des Articles qui apparaissent dans toutes les Commandes du Client
numéro 10.
12. Afficher les numéros les Articles dont la description débute par la lettre « C ».
 Indication : Utilisez la clause like 'C%'
13. Afficher les numéros des Clients dont le numéro de Téléphone n'est pas NULL.
14. Afficher le montant total de la Commande numéro 1 avant et après la taxe de 15%.
 Utilisez les alias AS pour renommer les colonnes avant et âpres
Voire exercice SELECT.pdf
Dr. Djellal. A VII

Annexes
Série de TP n° 05
Les Triggers
TP 01. La BD Cours
Considérons la BD Cours (cf. Chapitre I)
Exécuter le script SQL Cours.SQL se trouvant dans le répertoire D:\ en exécutant la

commande: @D\Cours.SQL;
Gestion de la suppression
1- Créer un trigger (Suppression) qui archive les clients qui ont été supprimés de la BD.
 Créer une table archive avec les colonnes nécessaires
 Créer le trigger avec l'événement, le moment et la table correspondantes
2- Nous voulons supprimer de la table client, les clients n'ayant pas effectué des
commandes. Ecrire et exécuter la requête SQL équivalente
3- Vérifier les résultats obtenus dans les tables Client et Archive
4- Modifier le trigger Suppression pour archiver seulement les clients habitants à
Constantine.
5- Nous voulons supprimer de la table client, les clients habitant dans une ville dont le
nom commence par "C". Ecrire et exécuter la requête SQL équivalente
6- Vérifier les résultats obtenus dans les tables Client et Archive
7- Effectuer un Rollback
8- Désactiver le trigger Suppression
9- Supprimer les clients habitant à Constantine et vérifier l'archive.
Gestion de la m à j
1- Créer un trigger (màj) qui calcule et insert dans une table archive la nouvelle moyenne
des âges après chaque changement de l'âge d'un employé. Pour cela :
 Créer une table archiveMoy avec les colonnes nécessaires
 Créer le trigger avec les événements, le moment et la table correspondantes
 Ecrire la requête SQL qui retourne les âges des clients
 Utiliser cette moyenne comme valeur à inclure dans la table archiveMoy
 Utiliser la commande adéquate à ce traitement dans le corps du trigger à crée
Dr. Djellal. A VIII

Dr. Djellal. A 9

Chapitre I SGBD

Transféré par

Informations du document

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é ?

Droits d'auteur :

Formats disponibles

Chapitre I SGBD

Transféré par

Droits d'auteur :

Formats disponibles

‫الجمهورية الجزائرية الديموقراطية الشعبية‬

‫وزارة التعلـــيم العــالي والبحث العـلمي‬

Niveau : 2ème année du Second Cycle

Module : Base de Données Avancées

Notes de cours du module Base de Données Avancées

Auteur : Dr. Asma Djellal

Année universitaire : 2022/2023

Chapitre I : Système de Gestion de Bases de Données ......................................................................6

Chapitre II : Structered Query Language .......................................................................................... 16

Chapitre III : Gestion des évenements ............................................................................................. 41

Annexes: Séries des Travaux Pratique ............................................................................................. 55

Tableau I. 1. Classification de quelques SGBD populaires ................................................... 14

Tableau I. 2. Comparaison entre les trois SGBD leaders ...................................................... 15

Tableau II. 1. Différentes versions du SGBD Oracle ........................................................... 17

Tableau II. 2. Classification des principales commandes SQL. ............................................ 20

Tableau II. 3. Les types de données Caractère ..................................................................... 24

Tableau II. 4. Les types de données Numériques ................................................................. 24

Tableau II. 5. Types de données Temporels ......................................................................... 25

Tableau II. 6. Violation des contraintes ............................................................................... 31

Figure I. 1. Schéma de la relation « CLIENT » ......................................................................8

Système de Gestion de Base de Données

2. Processus de développent de Bases de Données

3. Modèle Relationnel de Données

de données, la notion de table constitue la structure logique de base. Le modèle relationnel a

3.1. Eléments du modèle relationnel

Le principal avantage du modèle relationnel consiste en sa simplicité. En effet, il

3. Domaine : C’est un ensemble de valeurs significatives. Il peut être défini en extension ou

i. Un domaine est dit simple si toutes ses valeurs sont atomiques.

CLIENT (CodCli : Entier, Domaines des attributs

Figure I. 1. Schéma de la relation « CLIENT »

3.2. Clé primaire

A retenir!! Pour des besoins d’organisation de ces notes de cours, les

Exemple. Considérons la BD Cours, les attributs CodCli, CodPrd et Num

3.3. Clé étrangère

Exemple. Dans la BD Cours, les attributs CodCli et CodPrd de la table COMMANDE

4. Système de Gestion de Bases de Données

Un SGBD est donc un outil informatique permettant la sauvegarde et l’interrogation

4.1. SGBD : historique

4.2. Architecture ANSI/SPARC

Afin de simplifier la vision des utilisateurs, un SGBD doit impérativement assurer un

Figure I. 2. Niveaux d'abstraction de représentation des données

4.2.2. Niveau conceptuel

Le niveau interne correspond à la représentation physique des données. Il consiste en la

Figure I. 3. Conceptualisation du concept "Client"

Hammad Imene 28 Alger

Salhi Ali 35 Constantine

Figure I. 4. Implémentation du concept "Client" en utilisant un fichier d'enregistrements

4.3.1. Description des données

un: BEGIN_TRANSACTION et END_TRANSACTION. Ceci nécessite l’utilisation d’un

La table suivante représente une classification des SGBD populaires :

Ces trois SGBD leaders affichent d’excellents résultats en termes de performances, de

Tableau I. 2. Comparaison entre les trois SGBD leaders

IBM DB2 Ms SQL Server Oracle

Structured Query Language (SQL)

1988 Oracle 6 - Verrouillage niveau ligne

Figure II. 1. Différentes versions d'Oracle (jusqu'à 19c)14

3. Oracle SQL Developer

Oracle SQL Developer permet de créer, mettre à jours, gérer et interroger

4. Différentes familles du langage SQL

i. Langage de Définition de Données (LDD) : les commandes de cette famille permettent

ii. Langage de Manipulation de Données (LMD) : les commandes de cette famille

Tableau II. 2. Classification des principales commandes SQL.

5. Langage de Définition de Données

5.1. Description des données