Bases de données et SQL

Semestre 1 B103 : UE3 DEVELEOPPEMENT & TECHNOLOGIE

B1031 : Base de données et langage SQL

Objectifs du cours :

A la fin de ce cours l’apprenant doit être capable

1. Comprendre les concepts fondamentaux des SGBD.
2. Concevoir et créer une base de données en utilisant le modèle relationnel.
3. Écrire des requêtes SQL pour extraire des informations d’une base de données.
4. Comprendre et appliquer les concepts d’intégrité des données et de transactions.

CONTENU DU COURS

• Introduction aux bases de données : Définition d’une base de données,

avantages des SGBD, introduction aux modèles de données.
• Modèle relationnel : Concepts clés tels que les relations, les attributs, les clés
primaires et étrangères.
• Langage SQL : Introduction au langage SQL, écriture de requêtes SELECT,
utilisation des clauses WHERE, GROUP BY, HAVING et ORDER BY.
• Création et modification des structures de bases de données : Utilisation des
instructions CREATE, ALTER et DROP.

• Intégrité des données : Contraintes d’intégrité, déclencheurs (triggers). •

Transactions : Concepts de transactions, propriétés ACID

INTRODUCTION
Une base de données est un système organisé de collecte de stockage et de gestion de
données. Elle est utilisée pour stocker et organiser de grandes quantités d’informations,
de manière structurée et efficace. Les bases de données sont couramment utilisées dans
de nombreux domaines tels que les entreprises, la recherche scientifique les sites web
les applications mobiles les organisations gouvernementales Etc. Elles permettent de
stocker les données de différentes natures telles que des informations clients, des stocks
des données financières des informations de recherche etc. Les bases de données offrent
également des fonctionnalités de recherche, d’analyse et de gestion de données ,
permettant aux utilisateurs de récupérer et de manipuler les informations de manière
rapide et précise. Elles sont essentielles pour l’organisation et l’exploitation des données
à grandes échelle.

CHAPITRE I
Introduction Aux Bases De Données
I. Pourquoi utiliser les bases données
Les méthodes classiques utilisant des systèmes de fichiers décentralisés ont révélé
plusieurs insuffisances. Les principaux problèmes de ces systèmes sont :

 La redondance des données ;

 La lenteur dans le traitement de l’information
 La Cohérence des données ;
 La Sécurité ;
 La Complexité lors des mises à jour des informations ;
 Le Stockage des données ;
 La Difficulté d’accès aux données ;
 La fiabilité ;
 La Difficulté d’imposer les contraintes

Les bases de données ont donc été développées pour résoudre ces problèmes en offrant
une structure organisée pour stocker et récupérer les données de manière efficace.
Les bases de données permettent de centraliser les données et de les organiser en tables
avec des relations entre ces tables. Cela facilite la manipulation et la recherche des
données ainsi que la gestion de leur intégrité et de leur sécurité via un système de gestion
de base de données (SGBD).

II. LES SYSTEMES DE GESTION DES BASES DE

DONNEES (SGBD)

• DEFINITION ET HISTORIQUE
Un système de gestion des bases de données (SGBD) est un logiciel qui permet de
stocker, gérer et manipuler les données de manière efficace et sécurisée. Il assure
 également la gestion des accès concurrents, la récupération des erreurs et la garantie
de l’intégrité des données.

L’histoire des SGBD remonte aux années 1960, lorsque les premiers modèles de
données ont été développés. L’un des premiers SGBD , appelé Integrated data store
(IDS), a été créé par Charles Bachman en 1963. Les années 1970 ont vu l’émergence
des modèles relationnels et langage de requête associés qui sont toujours largement
utilisés aujourd’hui.
Au fil des décennies, les SGBD ont connu de nombreuses évolutions et améliorations.
Dans les années 1980 , les SGBDR ont commencé à intégrer des fonctionnalités
avancées telles que la gestion des transactions , les contraintes d’intégrité et la
sécurité des données. Dans les années 1990, les
SGBD ont connu une évolution significative avec l’émergence des bases de données
orientées objet qui pouvaient gérer des types de données complexes.
Depuis les années 2000, avec l’explosion des données numériques, les SGBD se sont
adaptés pour gérer des volumes de données massifs et ont intégré des fonctionnalités
avancées telles que le traitement parallèle et distribué, le stockage en colonnes, le
traitement en mémoire et le support du Cloud.
Aujourd’hui les SGBD sont au cœur des systèmes d’informations et de nombreuses
organisations.

• Les types de SGBD

Il existe plusieurs types de SGBD qui sont utilisés dans le domaine de l’informatique :

⎯ Le SGBD Relationnel basé sur le modèle relationnel, où les données sont

organisées en tables avec des relations entre elles.
⎯ Le SGBD orienté objet, qui permet de stocker des objets complexes avec attributs
et des comportements. Cette approche est utile pour la programmation orientée
objet et est utilisée dans les SGBD tels que MongoDB.
⎯ Le SGBD hiérarchique qui organise les données dans une structure arborescente.
Ce modèle est principalement utilisé dans les systèmes d’information géographique
et les systèmes de gestion des fichiers.

⎯ Le SGBD réseau où les données sont connectées par des liens de réseau. Ce modèle
a été utilisé dans les premiers SGBD mais est maintenant moins courant.
⎯ Le SGBD objets-relationnel, qui combine les caractéristiques des SGBD
relationnels et orientés objets, permettant de manipuler à la fois des tables de
données relationnelles et des objets complexes.
Chaque type de SGBD a ses avantages et ses domaines d’application spécifiques, et
le choix du type de SGBD dépend des besoins et des contraintes du projet.

• Les avantages du SGBD

Les Systèmes de Gestion de Base de Données (SGBD) offrent de nombreux
avantages dans le domaine de l’informatique. Tout d’abord, ils permettent de
centraliser les données d’une entreprise, ce qui facilite leur gestion et leur
organisation. Les SGBD offrent également une sécurisation des données en
permettant de définir des droits d’accès et en réalisant des sauvegardes régulières.
Grâce à leur capacité à gérer de grandes quantités de données, les SGBD permettent
une meilleure performance et une optimisation des traitements. De plus, ils offrent
une souplesse et une flexibilité dans la manipulation des données, permettant ainsi
une évolutivité du système. Enfin, les SGBD permettent une meilleure collaboration
et une meilleure productivité en facilitant le partage des données entre différents
utilisateurs et applications. En résumé, les SGBD offrent une gestion efficace,
sécurisée et performante des données, ce qui en fait un outil essentiel dans le domaine
de l’informatique.
CHAPITRE II : RAPPEL SUR LA MODELISATION DES DONNEES
INTRODUCTION

Un modèle est une représentation abstraite du monde réel.

La création d’une base de données est conditionnée par une modélisation de la situation
existante ; ainsi il est primordial d’effectuer bonne une modélisation des données si l’on
veut réussir sa base de données.
La modélisation des données a pour objectif de décrire de façon détaillée la structuration
des données et de présenter de façon simple les concepts du futur système. Tout au long
de ce chapitre nous présenterons les différents modèles de données.

COMMENT EFFECTUER UNE MODELISATION DE DONNEES

La modélisation des données passe par les étapes suivantes :

• L’Identification des éléments (« entités ») du domaine d'application exemples : un client, un
produit, un fournisseur, un lot, une vente ;
• La Description de la structure de chaque entité et de la liste des données élémentaires rattachées
(« attributs »)
Exemple : produit avec numéro, nom, type (légume ou fruit), prix ;
• La représentation de chaque information (« format ») qui renvoie à l’utilisation de types de
données élémentaires (texte, nombre, etc.)
Exemple : le nom d'un produit est un texte ;
• L’identification de dépendances entre des entités (« associations ») exemple : une vente
s'applique à un seul produit et un seul client, avec une date et un prix associés description de la
nature de chaque association
LES NIVEAUX D’ABSTRACTION DE DONNEES
Un des objectifs de la modélisation des données est d’assurer une abstraction des données stockées
pour assurer la vision utilisateur ; une architecture à trois niveaux a été proposée en 1975.
Le schéma suivant illustre les différents niveaux d’abstraction des données.

1. Le niveau externe
 Présente les données sous plusieurs vues utilisateurs.
 Décrit des contenus spécifiques de la BD qui peuvent être des structures Complexes.

2. Niveau logique (conceptuel)

Le niveau conceptuel représente la globalité des données ; c’est le niveau qui permet de décrire de
façon sémantique les données dans la base c’est-à-dire les contenus effectifs et les relations qui les
lient.
Le niveau logique permet également de décrire toute la BD :
Les entités, les types de données, les relations, les opérations des usagers, les contraintes.

3. Niveau physique (interne)

Le niveau interne est une représentation concrète du contenu de la base gérée par le SGBD. Il décrit :
  Mode d'inscription sur le support physique (disque) ; 
Structuration décrite de façon très détaillée ;

 Chemins d’accès pour la BD.

En théorie ces trois niveaux sont indépendants les uns des autres.
Exemple : gestion d’une bibliothèque

Le MODELE RELATIONNEL
Présentation

Dans ce modèle, les données sont représentées par des tables, sans préjuger de la façon dont les
informations sont stockées dans la machine. Les tables constituent donc la structure logique1 du modèle
relationnel. Au niveau physique, le système est libre d’utiliser n’importe quelle technique de stockage
(fichiers séquentiels, indexage, adressage dispersé, séries de pointeurs, compression, . . .) dès lors qu’il
est possible de relier ces structures à des tables au niveau logique. Les tables ne représentent donc
qu’une abstraction de l’enregistrement physique des données en mémoire.
Le succès du modèle relationnel auprès des chercheurs, concepteurs et utilisateurs est dû à la puissance
et à la simplicité de ses concepts. En outre, contrairement à certains autres modèles, il repose sur des
bases théoriques solides, notamment la théorie des ensembles et la logique des prédicats du premier
ordre.
Les objectifs du modèle relationnel sont :
– proposer des schémas de données faciles à utiliser ;
– améliorer l’indépendance logique et physique ;
– mettre à la disposition des utilisateurs des langages de haut niveau ;
– optimiser les accès à la base de données ;
– améliorer l’intégrité et la confidentialité ;
– fournir une approche méthodologique dans la construction des schémas.
De façon informelle, on peut définir le modèle relationnel de la manière suivante :
– les données sont organisées sous forme de tables à deux dimensions, encore appelées relations, dont
les lignes sont appelées n-uplet ou tuple en anglais ;
– les données sont manipulées par des opérateurs de l’algèbre relationnelle ;
– l’état cohérent de la base est défini par un ensemble de contraintes d’intégrité.
Au modèle relationnel est associée a la théorie de la normalisation des relations qui permet de se
débarrasser des incohérences au moment de la conception d’une base de données relationnelle

Éléments du modèle relationnel

-attribut-
. Un attribut est un identificateur (un nom) décrivant une information stockée dans une base.
Exemples d’attribut : l’âge d’une personne, le nom d’une personne, le numéro de sécurité sociale
Domaine
Par exemple, l’attribut numéro de sécurité sociale a pour domaine l’ensemble des combinaisons de
quinze chiffres et nom a pour domaine l’ensemble des combinaisons de lettres (une combinaison
comme cette dernière est généralement appelée chaîne de caractères ou, plus simplement, chaîne)
- Le domaine d’un attribut est l’ensemble, fini ou infini, de ses valeurs possibles
Par exemple, l’attribut numéro de sécurité sociale a pour domaine l’ensemble des combinaisons de
quinze chiffres et nom a pour domaine l’ensemble des combinaisons de lettres (une combinaison
comme cette dernière est généralement appelée chaîne de caractères ou, plus simplement, chaîne).
- Une relation est un sous-ensemble du produit cartésien de n domaines d’attributs (n > 0). Une relation
est représentée sous la forme d’un tableau à deux dimensions dans lequel les n attributs correspondent
aux titres des n colonnes.
- Un schéma de relation précise le nom de la relation ainsi que la liste des attributs avec leurs domaines
Le tableau ci-dessus montre un exemple de relation et précise son schéma.
- Le degré d’une relation est son nombre d’attributs.
- -occurrence ou n-uplets ou tuples
Une occurrence, ou n-uplets, ou tuples, est un élément de l’ensemble figuré par une relation. Autrement
dit, une occurrence est une ligne du tableau qui représente la relation
- La cardinalité d’une relation est son nombre d’occurrences.
- Une clé candidate d’une relation est un ensemble minimal des attributs de la relation dont les valeurs
identifient à coup sûr une occurrence
La valeur d’une clé candidate est donc distincte pour toutes les tuples de la relation. La notion de clé
candidate est essentielle dans le modèle relationnel.
Toute relation a au moins une clé candidate et peut en avoir plusieurs. Ainsi, il ne peut jamais y avoir
deux tuples identiques au sein d’une relation. Les clés candidates d’une relation n’ont pas forcément
le même nombre d’attributs. Une clé candidate peut être formée d’un attribut arbitraire, utilisé à cette
seule fin.
- La clé primaire d’une relation est une de ses clés candidates.
- Une clé étrangère dans une relation est formée d’un ou plusieurs attributs qui constituent une clé
primaire dans une autre relation.
- -schéma relationnel
Un schéma relationnel est constitué par l’ensemble des schémas de relation
-base de données relationnelle
Une base de données relationnelle est constituée par l’ensemble des n-uplets des différentes relations
du schéma relationnel

Passage du modèle entités-associations au modèle relationnel

. Chaque type-entité donne naissance à une relation. Chaque attribut de ce type-entité devient un attribut
de la relation. L’identifiant est conservé en tant que clé de la relation.
. Chaque type-association dont aucune patte n’a pour cardinalité maximale 1 donne naissance à une
relation. Chaque attribut de ce type-association devient un attribut de la relation. L’identifiant, s’il est
précisé, est conservé en tant que clé de la relation, sinon cette clé est formée par la concaténation des
identifiants des type-entités qui interviennent dans le type association
n type-association dont au moins une patte a une cardinalité maximale à 1 (ce type-association devrait
être binaire et n’a généralement pas d’attribut) ne devient pas une relation. Il décrit en effet une
dépendance fonctionnelle . La relation correspondant au type-entité dont la patte vers le type-
association a une cardinalité maximale valant 1, se voit simplement ajouter comme attribut (et donc
comme clé étrangère) l’identifiant de l’autre type-entité. Cas particulier d’un type-association du
type 1 vers 1

Dans cet exemple toutes les cardinalités maximales du type-association Etre sont de 1. L’application
des règles de passage du modèle entités-associations au modèle relationnel énoncées cidessus nous
donnerait :
– Citoyen(Num-Citoyen, Num-Candidat, Nom, Prénom, Adresse)
– Candidat(Num-Candidat), Num-Citoyen, Parti)
L’attribut Num-Candidat dans la relation Citoyen est une clé étrangère de la relation Candidat.
L’attribut Num-Citoyen dans la relation Candidat est une clé étrangère de la relation Citoyen. Le type-
association Etre étant du type 1 vers 1, il est entièrement matérialisé dans la relation Candidat par
l’attribut Num-Citoyen. Il est donc inutile de la rematérialiser dans la relation Citoyen. L’attribut Num-
Candidat dans la relation Citoyen doit donc être supprimé. D’autre part, dans la relation Candidat,
l’attribut Num-Citoyen, en plus d’être une clé étrangère, constitue une clé candidate. On peut donc se
passer de la clé Num-Candidat. Le schéma relationnel adéquat correspondant au modèle entités
associations de la figure 3. devient donc : – Citoyen(Num-Citoyen, Nom, Prénom, Adresse)
– Candidat(Num-Citoyen, Parti) où Num-Citoyen, en plus d’être la clé de la relation Candidat, est une
clé étrangère de la relation Citoyen.

Cas particulier d’un type-entité sans attribut autre que sa clé Lorsqu’un type-entité ne possède pas
d’attribut en dehors de sa clé, il ne faut pas nécessairement en faire une relation.
Ici, le type-entité Date ne doit pas se matérialiser par une relation. Par exemple, le type-entité Date de
la figure 3.2 ne doit pas se traduire par une relation. Le schéma relationnel adéquat correspondant au
modèle entités-associations de la figure 3.2 est donc :
– Exemplaire(NumExemplaire, date-achat)
– Personne(Num-Personne, nom, prénom, adresse)
– Emprunter(NumExemplaire, Num-Personne, Date, date-retour)
Exemple complet

exemple très simplifié de modélisation entités-associations

Comme exemple d’application, voici les relations déduites du schéma entités-associations de la figure
3.3 :
– Patient(Num-Patient, Nom-Patient, Num-Mutuelle)
– Mutuelle(Num-Mutuelle, Nom-Mutuelle)
– Médecin(Num-Médecin, Nom-Médecin, Prénom-Médecin)
– Affection(Num-Affection, Nom-Affection)
– Hospitaliser(Num-Patient, Num-Affection, Num-Médecin, Date-Entrée, Chambre,
DuréeHospitalisation)
Langage SQL
Introduction
Le langage SQL (Structured Query Language) peut être considéré comme le langage d’accès
normalisé aux bases de données. Il est aujourd’hui supporté par la plupart des produits commerciaux
que ce soit par les systèmes de gestion de bases de données micro tel que Access ou par les produits
plus professionnels tels que Oracle. Il a fait l’objet de plusieurs normes ANSI/ISO dont la plus
répandue aujourd’hui est la norme SQL2 qui a été définie en 1992. Le succès du langage SQL est dû
essentiellement à sa simplicité et au fait qu’il s’appuie sur le schéma conceptuel pour énoncer des
requêtes en laissant le SGBD responsable de la stratégie d’exécution. Le langage SQL propose un
langage de requêtes ensembliste et assertionnel. Néanmoins, le langage SQL ne possède pas la
puissance d’un langage de programmation : entrées/sorties, instructions conditionnelles, boucles et
affectations. Pour certains traitements il est donc nécessaire de coupler le langage SQL avec un langage
de programmation plus complet.
De manière synthétique, on peut dire que SQL est un langage relationnel, il manipule donc des tables
(i.e. des relations, c’est-à-dire des ensembles) par l’intermédiaire de requêtes qui produisent également
des tables.

Historique rapide
– En 1970, E.F. CODD, directeur de recherche du centre IBM de San José, invente le modèle
relationnelqui repose sur une algèbre relationnelle. Ce modèle provoque une révolution dans
l’approche des bases des données.
 – En 1977, création du langage SEQUEL (Structured English Query Language) et mise en place
duSystème R, prototype de base de données reposant sur la théorie de CODD. SEQUEL continue
de s’enrichir pour devenir SQL (Structured Query Language).
– En 1981, la société ORACLE CORP lance la première version de son système de gestion de base
dedonnées relationnelle (SGBDR), IBM sort SQL/DS et RTI lance INGRES.
– En 1982, IBM sort SQL/DS pour son environnement VM/CMS et l’ANSI (American National
Standard Institute) lance un projet de normalisation d’un langage relationnel. – En 1983, IBM
lance DB2 pour l’environnement MVS.
– En 1986, la sociéte SYBASE lance son SGBDR conçu selon le modèle Client-Serveur. – La
première norme SQL (SQL-1) de l’ISO (International Standard Organisation) apparaît. Il existe
désormais plusieurs dizaines de produits proposant le langage SQL et tournant sur des machines
allant des micros aux gros systèmes.
– Depuis, les différents produits phares ont évolué, la norme SQL est passée à SQL-2, puis SQL-3.
SQL est désormais un langage incontournable pour tout SGBD moderne.
on assiste de nos jours à une prolifération de dialectes propres à chaque produit : soit des sous
ensembles de la norme (certaines fonctionnalités n’étant pas implantées), soit des sur ensembles (ajout
de certaines fonctionnalités, propres à chaque produit).
Oracle et Informix dominent le marché actuel, SQL-Server (de Microsoft) tente de s’imposer dans
le monde des PC sous NT. À côté des ces produits, très chers, existent heureusement des systèmes
libres et gratuits : MySQL et PostgreSQL sont les plus connus.
Bien que ces SGBDR n’aient pas la puissance des produits commerciaux, certains s’en approchent
de plus en plus. Les différences notables concernent principalement les environnements de
développement qui sont de véritables ateliers logiciels sous Oracle et qui sont réduits à des interfaces
de programmation C, Python, Perl sous PostgreSQL. Il en va de même pour les interfaces utilisateurs
: il en existe pour PostgreSQL, mais ils n’ont certainement pas la puissance de leurs équivalents
commerciaux.
Terminologie
Modèle relationnel
Standard
Français Anglais SQL
Relation Relation Table

Domaine Domain Domaine

Attribut Attribute Colonne

n-uplet tuple Ligne

Clé Primary Primary key

primaire key

Catégories d’instructions

Les instructions SQLsont regroupées en catégories en fonction de leur utilité et des entités
manipulées.
Nous pouvons distinguer cinq catégories, qui permettent :
1. la définition des éléments d’une base de données (tables, colonnes, clefs, index, contraintes, . . .),
2. la manipulation des données (insertion, suppression, modification, extraction, . . .),

3. la gestion des droits d’accès aux données (acquisition et révocation des droits), 4. la gestion des
transactions,
5. et enfin le SQL intégré.

Langage de définition de données

Le langage de définition de données (LDD, ou Data Definition Language, soit DDL en anglais)
est un langage orienté au niveau de la structure de la base de données. Le LDD permet de créer,
modifier, supprimer des objets. Il permet également de définir le domaine des données (nombre,
chaîne de caractères, date, booléen, . . .) et d’ajouter des contraintes de valeur sur les données. Il
permet enfin d’autoriser ou d’interdire l’accès aux données et d’activer ou de désactiver l’audit pour
un utilisateur donné.
Les instructions du LDD sont : CREATE, ALTER, DROP, AUDIT, NOAUDIT, ANALYZE,
RENAME, TRUNCATE.
Langage de manipulation de données
Le langage de manipulation de données (LMD, ou Data Manipulation Language, soit DML en
anglais) est l’ensemble des commandes concernant la manipulation des données dans une base de
données. Le LMD permet l’ajout, la suppression et la modification de lignes, la visualisation du
contenu des tables et leur verrouillage.
Les instructions du LMD sont : INSERT, UPDATE, DELETE, SELECT, EXPLAIN, PLAN,
LOCK TABLE.
Ces éléments doivent être validés par une transaction pour qu’ils soient pris en compte.

Langage de protections d’accès

Le langage de protections d’accès (ou Data Control Language, soit DCL en anglais) s’occupe de
gérer les droits d’accès aux tables. Les instructions du DCL sont : GRANT, REVOKE.

Langage de contrôle de transaction

Le langage de contrôle de transaction (ou Transaction Control Language, soit TCL en anglais)
gère les modifications faites par le LMD, c’est-à-dire les caractéristiques des transactions et la
validation et l’annulation des modifications.
Les instructions du TCL sont : COMMIT, SAVEPOINT, ROLLBACK, SET TRANSACTION

SQL intégré
Le SQL intégré (Embedded SQL) permet d’utiliser SQL dans un langage de troisième génération
(C, Java, Cobol, etc.) :
– déclaration d’objets ou d’instructions ;
– exécution d’instructions ;
– gestion des variables et des curseurs ;
– traitement des erreurs.
Les instructions du SQL intégré sont : DECLARE, TYPE, DESCRIBE, VAR, CONNECT,
PREPARE, EXECUTE, OPEN, FETCH, CLOSE, WHENEVER.
 PostgreSQL
Les systèmes traditionnels de gestion de bases de données relationnelles (SGBDR) offrent un
modèle de données composé d’une collection de relations contenant des attributs relevant chacun d’un
type spécifique. Les systèmes commerciaux gèrent par exemple les nombres décimaux, les entiers,
les chaînes de caractères, les monnaies et les dates. Il est communément admis que ce modèle est
inadéquat pour les applications de traitement de données de l’avenir car, si le modèle relationnel a
remplacé avec succès les modèles précédents en partie grâce à sa « simplicité spartiate », cette dernière
complique cependant l’implémentation de certaines applications. PostgreSQL apporte une puissance
additionnelle substantielle en incorporant les quatre concepts de base suivants afin que les utilisateurs
puissent facilement étendre le système : classes, héritage, types, fonctions. D’autres fonctionnalités
accroissent la puissance et la souplesse : contraintes, déclencheurs, règles, intégrité des transactions.
Ces fonctionnalités placent PostgreSQL dans la catégorie des bases de données relationnel-objet.
Ne confondez pas cette catégorie avec celle des serveurs d’objets qui ne tolère pas aussi bien les
langages traditionnels d’accès aux SGBDR. Ainsi, bien que PostgreSQL possède certaines
fonctionnalités orientées objet, il appartient avant tout au monde des SGBDR. C’est essentiellement
l’aspect SGBDR de PostgreSQL que nous aborderons dans ce cours.
L’une des principales qualités de PostgreSQL est d’être un logiciel libre, c’est-à-dire gratuit et
dont les sources sont disponibles. Il est possible de l’installer sur les systèmes Unix/Linux et Win32.
PostgreSQL fonctionne selon une architecture client/serveur, il est ainsi constitué :
– d’une partie serveur, c’est-à-dire une application fonctionnant sur la machine hébergeant la basede
données (le serveur de bases de données) capable de traiter les requêtes des clients ; il s’agit dans
le cas de PostgreSQL d’un programme résident en mémoire appelé postmaster ;
– d’une partie client (psql) devant être installée sur toutes les machines nécessitant d’accéder au
serveur de base de données (un client peut éventuellement fonctionner sur le serveur lui-même).
Les clients (les machines sur lesquelles le client PostgreSQL est installé) peuvent interroger le –

Introduction aux contraintes d’intégrité

Soit le schéma relationnel minimaliste suivant :
– Acteur(Num-Act, Nom, Prénom)
– Jouer(Num-Act, Num-Film)
– Film(Num-Film, Titre, Année)
Contrainte d’intégrité de domaine
Toute comparaison d’attributs n’est acceptée que si ces attributs sont définis sur le même domaine.
Le SGBD doit donc constamment s’assurer de la validité des valeurs d’un attribut. C’est pourquoi la
commande de création de table doit préciser, en plus du nom, le type de chaque colonne.
Par exemple, pour la table Film, on précisera que le Titre est une chaîne de caractères et l’Année
une date. Lors de l’insertion de n-uplets dans cette table, le système s’assurera que les différents
champs du n-uplet satisfont les contraintes d’intégrité de domaine des attributs précisées lors de la
création de la base. Si les contraintes ne sont pas satisfaites, le n-uplet n’est, tout simplement, pas
inséré dans la table.

Contrainte d’intégrité de relation (ou d’entité)

Lors de l’insertion de n-uplets dans une table (i.e. une relation), il arrive qu’un attribut soit inconnu
ou non défini. On introduit alors une valeur conventionnelle notée NULL et appelée valeur nulle.
Cependant, une clé primaire ne peut avoir une valeur nulle. De la même manière, une clé primaire
doit toujours être unique dans une table. Cette contrainte forte qui porte sur la clé primaire est appelée
contrainte d’intégrité de relation.
Tout SGBD relationnel doit vérifier l’unicité et le caractère défini (NOT NULL) des valeurs
de la clé primaire.

Contrainte d’intégrité de référence

Dans tout schéma relationnel, il existe deux types de relation :
– les relations qui représentent des entités de l’univers modélisé ; elles sont qualifiées de
statiques,ou d’indépendantes ; les relations Acteur et Film en sont des exemples ;
– les relations dont l’existence des n-uplets dépend des valeurs d’attributs situées dans d’autres
relations ; il s’agit de relations dynamiques ou dépendantes ; la relation Jouer en est un exemple.
Lors de l’insertion d’un n-uplet dans la relation Jouer, le SGBD doit vérifier que les valeurs
NumAct et Num-Film correspondent bien, respectivement, à une valeur de Num-Act existant dans la
relation Acteur et une valeur Num-Film existant dans la relation Film.
Lors de la suppression d’un n-uplet dans la relation Acteur, le SGBD doit vérifier qu’aucun n-uplet
de la relation Jouer ne fait référence, par l’intermédiaire de l’attribut Num-Act, au n-uplet que l’on
cherche à supprimer. Le cas échéant, c’est-à-dire si une, ou plusieurs, valeur correspondante de
NumAct existe dans Jouer, quatre possibilités sont envisageables :
– interdire la suppression ;
– supprimer également les n-uplets concernés dans Jouer ;
 – avertir l’utilisateur d’une incohérence ;
– mettre les valeurs des attributs concernés à une valeur nulle dans la table Jouer, si l’opération est
possible (ce qui n’est pas le cas si ces valeurs interviennent dans une clé primaire) ;

INITIATION AU DDL
Les commandes SQL de définition de données permettent décrire les données selon le niveau
d’abstraction approprié (niveau conceptuel, niveau logique, niveau physique, par exemple). Les
commandes du DDL sont :
CREATE, DROP, ALTER

CREATE

Permet de créer les objets (bases de données et tables) sa syntaxe est la suivante :

Pour la création de la base de données : CREATE database nom_de la base ;

La commande CREATE TABLE permet de créer une table en SQL. Un tableau est une entité qui est
contenu dans une base de données pour stocker des données ordonnées dans des colonnes. La création
d’une table sert à définir les colonnes et le type de données qui seront contenus dans chacun des
colonne (entier, chaîne de caractères, date, valeur binaire …). La syntaxe générale pour créer une table
est la suivante :
CREATE TABLE nom_de_la_table
(
colonne1 type_donnees, colonne2
type_donnees, colonne3 type_donnees,
colonne4 type_donnees
)
Dans cette requête, 4 colonnes ont été définies. Le mot-clé “type_donnees” sera à remplacer par un
mot-clé pour définir le type de données (INT, DATE, TEXT …). Pour chaque colonne, il est également
possible de définir des options telles que (liste non-exhaustive):
NOT NULL : empêche d’enregistrer une valeur nulle pour une colonne.
DEFAULT : attribuer une valeur par défaut si aucune données n’est indiquée pour cette colonne lors

de l’ajout d’une ligne dans la table.

PRIMARY KEY : indiquer si cette colonne est considérée comme clé primaire pour un index.
Imaginons que l’ont souhaite créer une table utilisateur, dans laquelle chaque ligne correspond à un
utilisateur inscrit sur un site web. La requête pour créer cette table peut ressembler à ceci:
CREATE TABLE utilisateur

id INT PRIMARY KEY NOT NULL,

nom VARCHAR(100),

prenom VARCHAR(100),

email VARCHAR(255),

date_naissance DATE,

pays VARCHAR(255),

ville VARCHAR(255),

code_postal VARCHAR(5),

nombre_achat IN

• DROP

Cette commande permet de supprimer les objets d’une base de données ;

Sa syntaxe est la suivante : DROP database nom_de la base ; supprime une base de données ;
DROP Table nom_table ; permet de supprimer les tables ;

• ALTER TABLE
La commande ALTER TABLE permet la modification d’une table

Ajouter une colonne à une tàble

Cette commande permet d'ajouter une colonne à une table.

ALTER TABLE nom_table ADD nom_colonne type (taille) ;

Supprimer une colonne à une tàble

Cette commande permet de supprimer une colonne d'une table.

ALTER TABLE nom_table DROP nom_colonne ; Renommer

une table

alter TABLE nom_table rename TO nouveau;

Alter table nom_colonne add foreign key

nom_colonne REFERENCES nom_table id

Atelier n°

Soit le schéma relationnel suivant :

CLIENT (IdCli, nom, ville) ;

PRODUIT (IdPro, nom, prix, qstock) ;
VENTE (IdCli, IdPro, dàte, qte) ;
1. Représentez les données sous forme de tables.

2. Identifiez les différentes clés de cette relation ;

3. Créer une base de donnée sous postgres ;

4. Créer la table CLIENT

5. Créer la table Produit ;

6. Ajouter la colonne adresse sur la table CLIENT ;

7. Définissez les clés primaires des tables CLIENT et VENTE ;

8. Créer la table VENTE et définissez les clés étrangères ;

9. Supprimer la table vente que remarquez-vous.

MANIPULATION DES DONNEE

Insertion des donnees

L'instruction INSERT INTO est utilisée pour insérer un ou plusieurs enregistrements dans une table
de la base de données r. Sa syntaxe est la suivante :

INSERT INTO nom_table(column_name1, column_name2...)

VALUES(column1_value, column2_value...);
.
Inserer des vàleurs dàns toutes les colonnes

Pour insérer des valeurs dans toutes les colonnes d'une table, vous n'avez pas besoin de spécifier les
noms de colonne avec le nom de la table. Spécifiez les valeurs de chaque colonne dans une séquence,
comme indiqué ci-dessous
Noter que toute modification de la séquence, du nombre de valeurs ou de son type de données peut
entraîner une erreur ou des données incorrectes.

Inserer des vàleurs dàns des colonnes specifiques

Pour insérer des données dans des colonnes spécifiques, spécifiez les noms de colonne entre
parenthèses. Assurez-vous que les autres colonnes autorisent les valeurs nulles; sinon, une erreur sera
générée.

Syntaxe :

INSERT INTO nom_table ( ‘colonne1’, ‘colonne2’) VALUES

( ‘colonne1val1’, ‘colonne2val2’) ;

Inserer plusieurs enregistrements

Insérez plusieurs enregistrements dans une seule instruction INSERT INTO en mettant plusieurs
enregistrements entre parenthèses après VALUES.
Pour insérer plusieurs enregistrements dans des colonnes spécifiques, spécifiez les noms de colonne
entre parenthèses.
INSERT INTO nom_table ( ‘colonne1’, ‘colonne2’) VALUES
( ‘colonne1val1’, ‘colonne2val2’), VALUES ( ‘colonne1val1’,
‘colonne2val2’) ;

- Instruction SELECT

Dans SQL Server, l'instruction SELECT est utilisée pour récupérer les données des lignes/colonnes
d'une ou plusieurs tables existantes. .

Syntaxe: SELECT column1, column2,...columnN

FROM table_name

Selectionner toutes les colonnes

L’opérateur * représente toutes les colonnes d'une table. Ainsi, vous n'avez pas besoin de spécifier
chaque nom de colonne dans la requête SELECT pour obtenir des données de toutes les colonnes.

Syntaxe : SELECT * FROM Employee;

Sélection de tous les enregistrements
Selectionner des donnees de colonnes specifiques

Spécifiez les noms de colonne dans l'instruction SELECT pour obtenir les données uniquement à
partir de ces colonnes, comme indiqué ci-dessous.
Script SQL : sélectionner une requête
Copie
SELECT colonne1, colonne2, colonne3 FROM nom_tabl
NB :

L'instruction SELECT doit contenir la clause FROM. La clause FROM est utilisée pour répertorier
les noms de table à partir desquels nous voulons sélectionner des données et spécifier des jointures
entre ces tables.
Vous pouvez spécifier plusieurs tables dans la clause FROM pour sélectionner des données.
Cependant, si les tables ont les mêmes colonnes, vous devez spécifier les noms de colonne complets
comme table_name.column_namedans la requête SELECT.
Ce qui suit sélectionne les colonnes de deux tables.
Script SQL : sélectionner des données dans plusieurs tables
SELECT * FROM Employee, Deparatment;

SELECT Employee.*, Department.* FROM Employee, Deparatment;

SELECT emp.*, dept.* FROM Employee emp, Deparatment dept;

SELECT emp.FirstName, dept.DipartmentName FROM Employee
emp, Dep

ELECT emp.FirstName, dept.DipartmentName FROM Employee emp,

Deparatment dept

Conditions multiples dàns là clàuse WHERE

La clause WHERE peut contenir plusieurs conditions utilisant les opérateurs AND et OR. La requête
suivante utilise l'opérateur logique AND pour spécifier deux conditions pour filtrer les données.
conditions dans la clause WHERE

SELECT * FROM Employee

WHERE DeptId = 1 AND Salary > 20000;

Dans la requête ci-dessus, la condition WHERE DeptId = 1 AND Salary > 20000 spécifie deux
conditions séparées par l'opérateur AND. Cela renverra les lignes de la Employeetable où la valeur de
DeptIdest 1 et Salaryest supérieure à 20000.

Sous-requête dans la clause WHERE

La condition WHERE peut également utiliser la valeur résultante d'une sous-requête, comme indiqué
ci-dessous.
sous-requête dans la clause WHERE

SELECT * FROM Employee

WHERE DeptId = (SELECT DeptId FROM Department WHERE
DeptName = 'HR');

Dans la requête ci-dessus, la condition WHERE est WHERE DeptId = (SELECT DeptId FROM
 Department WHERE DeptName = 'HR'). Ainsi, d'abord, la sous-requête SELECT DeptId FROM Department

WHERE DeptName = 'HR'sera exécutée et la DeptIdvaleur résultante sera utilisée pour filtrer les lignes.

Clàuse WHERE

l'instruction SELECT peut avoir une clause WHERE facultative pour filtrer les données. La clause
WHERE peut inclure une ou plusieurs conditions booléennes pour filtrer les données des tables.

La clause WHERE vient toujours après la clause FROM.

Syntaxe:
SELECT column1, column2,...columnN
FROM table_name
WHERE boolean_expression;

La clause WHERE peut contenir une ou plusieurs conditions qui peuvent utiliser des opérateurs
conditionnels pour filtrer les données de résultat. Considérez la requête suivante.

: requête SELECT avec la clause WHERE

SELECT * FROM Employee
WHERE Salary > 25000;

Dans la requête ci-dessus, la condition Salary > 25000renvoie les lignes où la valeur de la colonne
Salary est supérieure à 25 000.

La requête suivante utilise l'opérateur BETWEEN dans la clause WHERE.

opérateur BETWEEN dans la clause WHERE

SELECT * FROM Employee

WHERE Salary BETWEEN 17000 AND 25000;

Dans la requête ci-dessus, la condition Salary BETWEEN 17000 AND 25000 renvoie les lignes où la
valeur de la colonne Salary est comprise entre 17 000 et 25 000 (y compris les deux valeurs).

Opérateurs conditionnels

Les opérateurs suivants peuvent être utilisés dans les conditions WHERE.
 Opérateur description

= Égal

> Supérieur

< Inférieur

>= Supérieur ou égal

<= Inférieur ou égal

<> ou != Différent de. Dans certaines bases de données, le est utilisé pour
comparer des valeurs qui ne sont pas égales. !=

BETWEEN Entre une certaine plage

LIKE Rechercher un motif

ON Pour spécifier plusieurs valeurs possibles pour une colonne

Clause GROUP BY

la clause GROUP BY est utilisée pour obtenir les données récapitulatives basées sur un ou plusieurs
groupes. Les groupes peuvent être formés sur une ou plusieurs colonnes. Par exemple, la requête
GROUP BY sera utilisée pour compter le nombre d'employés dans chaque département, ou pour obtenir
les salaires totaux par département.

Vous devez utiliser les fonctions d'agrégation telles que

COUNT(), MAX(), MIN(), SUM(), AVG(), etc., dans la requête SELECT. Le résultat de la clause
GROUP BY renvoie une seule ligne pour chaque valeur de la colonne GROUP BY.

Syntaxe:
SELECT column1, column2,...columnN FROM table_name

[WHERE]

[GROUP BY column1, column2...columnN]

[HAVING]

[ORDER BY]

La clause SELECT peut inclure des colonnes utilisées avec la clause GROUP BY. Ainsi, pour inclure
d'autres colonnes dans la clause SELECT, utilisez les fonctions d'agrégation comme COUNT(), MAX(),
MIN(), SUM(), AVG()avec ces colonnes.

GROUP BY

• La clause GROUP BY est utilisée pour former les groupes d'enregistrements.

• La clause GROUP BY doit venir après la clause WHERE si elle est présente et avant la clause
HAVING.
• La clause GROUP BY peut inclure une ou plusieurs colonnes pour former un ou plusieurs
groupes basés sur ces colonnes.
• Seules les colonnes GROUP BY peuvent être incluses dans la clause SELECT. Pour utiliser
d'autres colonnes dans la clause SELECT, utilisez les fonctions d'agrégation avec elles.
À des fins de démonstration, nous utiliserons les tableaux suivants Employee dans Department tous
les exemples.

Considérez la requête GROUP BY suivante

Script SQL : GROUP BY
SELECT DeptId, COUNT(EmpId) as 'Number of Employees'
FROM Employee
GROUP BY DeptId;
SELECT DeptId, COUNT(*) as 'No of Employees'
FROM Employee
GROUP BY DeptId;
La requête ci-dessus inclut la clause GROUP BY DeptId, vous ne pouvez donc l'inclure que
DeptIddans la clause SELECT. Vous devez utiliser des fonctions d'agrégation pour inclure d'autres
colonnes dans la clause SELECT. Elle COUNT(EmpId)est donc incluse car nous voulons compter le
nombre d'employés dans le même fichier DeptId. 'No of Employees'est un alias de la colonne
COUNT(EmpId). La requête affichera le résultat suivant.

La requête suivante obtient le nom du département au lieu du DeptIdrésultat.

Script SQL : GROUPER BY

SELECT dept.DeptName as 'Department', count(emp.empid) as

'No of Employees'
FROM Employee emp, Department dept
WHERE emp.deptid = dept.DeptId
GROUP by dept.DeptName
De la même manière, la requête suivante obtient les salaires totaux par département.

Script SQL : GROUPE BY

SELECT dept.DeptName, sum(emp.salary) as 'Total Salaries'

FROM Employee emp, Department dept
WHERE emp.deptid = dept.DeptId
GROUP by dept.DeptName

La requête suivante renverrait une erreur, car dept.DeptName n'est pas incluse dans la clause GROUP
BY, ou aucune fonction d'agrégation n'est utilisée.
Script SQL : GROUPE BY
SELECT dept.DeptName, sum(emp.salary) as 'Total Salaries'
FROM Employee emp, Department dept
WHERE emp.deptid = dept.DeptId
GROUP by dept.DeptId

Clàuse HAVING la clause HAVING inclut une ou plusieurs conditions

qui doivent être

TRUE pour les groupes d'enregistrements. C'est comme la clause WHERE de la clause GROUP BY.

La seule différence est que la clause WHERE ne peut pas être utilisée avec des fonctions d'agrégation,

tandis que la clause HAVING peut utiliser des fonctions d'agrégation. La clause HAVING vient

toujours après la clause GROUP BY et avant la clause ORDER BY.

Syntaxe:
SELECT column1, column2,...columnN

FROM table_name

[WHERE]

[GROUP BY column1, column2...columnN]

[HAVING conditions]

[ORDER BY]

Caractéristiques HAVING :

• La clause HAVING est utilisée pour filtrer les enregistrements de regroupement.

• La clause HAVING doit venir après la clause GROUP BY et avant la clause ORDER BY.
• La clause HAVING peut inclure une ou plusieurs conditions.
 • La condition HAVING ne peut inclure que des colonnes utilisées avec la clause GROUP BY.
Pour utiliser d'autres colonnes dans la condition HAVING, utilisez les fonctions d'agrégation
avec elles.
À des fins de démonstration, nous utiliserons les tableaux suivants Employee dans Department
tous les exemples ..

Dans la section GROUP BY , nous avons utilisé la requête suivante pour récupérer le nombre
d'employés dans chaque département, comme indiqué ci-dessous.

SQL Server : GROUP BY

SELECT DeptId, COUNT(EmpId) as 'Number of Employees'

FROM Employee GROUP
BY DeptId;
Maintenant, pour filtrer le résultat de la requête GROUP BY ci-dessus, utilisez la clause HAVING
avec la fonction d'agrégation, comme indiqué ci-dessous.
 SQL Server : GROUP BY

SELECT DeptId, COUNT(EmpId) as 'Number of Employees'

FROM Employee
GROUP BY DeptId
HAVING COUNT(EmpId) > 2

Notez que nous avons utilisé une fonction d'agrégation COUNT()dans la clause HAVING car elle
EmpId n'est pas incluse dans la clause GROUP BY. La requête ci-dessus affichera le résultat suivant.

Clause ORDER BY la clause ORDER BY est utilisée dans la requête SELECT pour trier le résultat

dans l'ordre croissant ou décroissant d'une ou plusieurs colonnes.

Syntaxe:
SELECT column1, column2,...columnN

FROM table_name

[WHERE]

[GROUP BY]

[HAVING]

[ORDER BY column(s) [ASC|DESC]]

Caractéristiques ODER BY :

• La clause ORDER BY est utilisée pour obtenir les enregistrements triés sur une ou
plusieurs colonnes dans l'ordre croissant ou décroissant.
• La clause ORDER BY doit venir après les clauses WHERE, GROUP BY et HAVING
si elles sont présentes dans la requête.
• Utilisez ASC ou DESC pour spécifier l'ordre de tri après le nom de la colonne. Utilisez
ASC pour trier les enregistrements dans l'ordre croissant ou utilisez DESC pour l'ordre
décroissant. Par défaut, la clause ORDER BY trie les enregistrements par ordre
croissant si l'ordre n'est pas spécifié.

Trier par ordre décroissant la clause ODER BY DESC

SELECT EmpId, FirstName, LastName FROM Employee

ORDER BY FirstName DESC;
jointure SQL
Les jointures en SQL permettent d’associer plusieurs tables dans une même requête. Cela permet
d’exploiter la puissance des bases de données relationnelles pour obtenir des résultats qui
combinent les données de plusieurs tables de manière efficace.
Exemple
En général, les jointures consistent à associer des lignes de 2 tables en associant l’égalité des
valeurs d’une colonne d’une première table par rapport à la valeur d’une colonne d’une seconde
table. Imaginons qu’une base de 2 données possède une table « utilisateur » et une autre table «
adresse » qui contient les adresses de ces utilisateurs. Avec une jointure, il est possible d’obtenir les
données de l’utilisateur et de son adresse en une seule requête.
On peut aussi imaginer qu’un site web possède une table pour les articles (titre, contenu, date de
publication …) et une autre pour les rédacteurs (nom, date d’inscription, date de naissance …). Avec
une jointure il est possible d’effectuer une seule recherche pour afficher un article et le nom du
rédacteur. Cela évite d’avoir à afficher le nom du rédacteur dans la table « article ».

Types de jointures
Il y a plusieurs méthodes pour associer 2 tables ensemble. Voici la liste des différentes techniques
qui sont utilisées :
• INNER JOIN : jointure interne pour retourner les enregistrements quand la condition est vrai
dans les 2 tables. C’est l’une des jointures les plus communes.
• CROSS JOIN : jointure croisée permettant de faire le produit cartésien de 2 tables. En
d’autres mots, permet de joindre chaque lignes d’une table avec chaque lignes d’une seconde
table. Attention, le nombre de résultats est en général très élevé.
• LEFT JOIN (ou LEFT OUTER JOIN) : jointure externe pour retourner tous les
enregistrements de la table de gauche (LEFT = gauche) même si la condition n’est pas vérifié
dans l’autre table.
• RIGHT JOIN (ou RIGHT OUTER JOIN) : jointure externe pour retourner tous les
enregistrements de la table de droite (RIGHT = droite) même si la condition n’est pas vérifié
dans l’autre table.
• FULL JOIN (ou FULL OUTER JOIN) : jointure externe pour retourner les résultats quand la
condition est vrai dans au moins une des 2 tables.
• SELF JOIN : permet d’effectuer une jointure d’une table avec elle-même comme si c’était une
autre table.
• NATURAL JOIN : jointure naturelle entre 2 tables s’il y a au moins une colonne qui porte le
même nom entre les 2 tables SQL
• UNION JOIN : jointure d’union