Cours TBD G2

1
Héritier Kangela, Ir. Institut Supérieur de Commerce
Technique de Banque de Données
Notes de cours
Année Académique 2020-2021

1
SOMMAIRE
Chapitre 1 : Introduction
Chapitre 2 : Modèle conceptuel
Chapitre 3 : Modèle relationnel
Chapitre 4 : Langages de requêtes / SQL
Chapitre 5 : Algèbre relationnelle
Chapitre 6 : Calcul relationnel
Chapitre 7 : SQL - Droits d’accès et vues
Chapitre 8 : Normalisation
Chapitre 9 : Stockage et indexation
Ir. Hériti er Kangela heritierkangela2013@gmail.com ISC-GOMA

2
1. INTRODUCTION
1.1. Objectifs
• Définition : base de données (BD) = ensemble de données accessibles et
exploitables au moyen d’un ensemble de programmes.
• Définition : système de gestion de bases de données (SGBD) = outil (logiciel)
permettant d’accéder à des BD.
• Exemples de SGBD :
- Professionnels relationnels : Oracle, Sybase, Informix, ...,
- Professionnels orientés-objets : Versant, Objectstore, O2, ...
- Personnels : Access, Paradox, 4D, ...,
• Exemples d’utilisations :
- consultation (en local ou à distance1) des données relatives aux produits d’une
entreprise,
- Consultation à distance des cours de la bourse,
- Facturation à partir des données relatives aux commandes-clients et aux
caractéristiques de produits, ...
• Notions de données vs. informations : donnée = information codée sur un support
(définition personnelle non officielle)
• Notion de système d’information : plus générale que celle de BD. Inclut la
description des flux de données, les aspects organisationnels, ...
• Objectifs des SGBD :
- Exploitation de gros volumes de données => structures de données et
méthodes d’accès efficaces,
1 2
Intro. Internet, Intranet
cf. cours Système
Ir. Héritier Kangela heritierkangela2013@gmail.com ISC-GOMA
3
- Exploitation par différents types d’utilisateurs => différents outils d’accès
ou interfaces-utilisateurs,
- Gestion de données sensibles => sécurité et fiabilité des outils, - aspect
multi-utilisateurs => mécanismes de protection2,
1.2. Justification historique

• Avant les SGBD : écriture de programmes par des programmeurs d’application
utilisant le système de gestion de fichiers2 pour gérer et exploiter les données
 Risques liés au manque de sécurité + multiplication des efforts
(programmes similaires écrits dans différents services pour des besoins
proches).
• Conséquences :
- Redondances : fichiers contenant les mêmes données, mais utilisées par des
personnes différentes,
- Risque d’incohérences : du fait des redondances et des MAJ non centralisées
(ex: adresse d’un fournisseur),
- Intégrité des données : respect de contraintes qui peuvent être
programmées (ex : contrôles sur date de naissance, sur code postal, numéro
de tél., ...),
- Problème liés à la sécurité : utilisateurs de différents niveaux d’expérience
et avec différents droits d’accès => mots de passe,
- Problème liés au partage des données : accès en lecture / écriture.
1.3. Indépendance données / programmes

L'objectif premier des SGBD est d'assurer cette indépendance, en libérant les
programmeurs et les utilisateurs en général de la connaissance précise de la façon
dont les données sont structurées.
2
Sous-ensemble du système d’exploitation
4
1.4. Niveaux d’abstraction

On a coutume de distinguer plusieurs niveaux de représentation ou d’abstraction pour
les bases de données et les systèmes d’information de manière plus générale :
• Le niveau externe (utilisateur) -> vues
• Le niveau conceptuel (concepteur, administrateur) -> modèles de données
• Le niveau interne (stockage) -> structures de données (fichiers, index)
1.5. Modèles de données

On distingue généralement deux catégories de modèles de données :
• Les modèles orientés information -> définition du schéma conceptuel
 Modèle entité-association et ses dérivés (MERISE, ...)
• Les modèles orientés données -> mise-en-œuvre du SGBD
 Modèle relationnel, modèle hiérarchique, modèle réseau/CODASYL
1.6. Langages
• 2 types de langages :
• Langages procéduraux
 Décrivent à la fois ce que l’utilisateur souhaite et l’algorithme de résolution
du problème : “quoi et comment”
• Langages déclaratifs (ou assertionnels)
 Se limitent à décrire la demande de l’utilisateur : “quoi”
• 2 types de fonctionnalités dans les BD
• Langage de définition (LDD)
 Définition du dictionnaire des données (méta-données)
• Langage de manipulation (LMD)
 Consultation + mise à jour (insertion, suppression, modification)

5
1.7. Fonctions liées à l’exploitation des SGBD

• Administrateur de bases de données
 Analyse fonctionnelle
 Définition du schéma conceptuel
 Choix des méthodes de stockage et d’accès
 Modification de l’organisation conceptuelle / physique
 Gestion des droits d’accès
 Spécification des contraintes d’intégrité
• Classes d’utilisateurs
 Utilisateurs occasionnels (programmes d’application)
 Utilisateurs experts (SQL)
 Programmeurs d’applications (SQL + langage de programmation “hôte”)
1.8. Fonctionnalités et organisation générale

6
Utilisateurs Programmeurs Utilisateurs Administrateur

occasionnels d’applications avancés base de données
Interfaces Programmes Requêtes Schéma de base

type web d’application (SQL) de données
Précompilateur Compilateur Interpréteur

SQL SQL SQL
Code prog.
d’applications
Noyau du SGBD
(éval. / trait. des
requêtes)
Interfaces type Gestionnaire

web de tampons
Gestionnaire
de fichiers
Index Statistiques
Dictionnaire
Données
des données

7
2. MODELISATION CONCEPTUELLE
2.1. Introduction
Objectif = représentation symbolique et réduite de la réalité
représentation logique (vs. Physique)
Les modèles conceptuels de type entité-association (E/A) tels que MERISE sont
progressivement remplacés par des modèles s’inspirant des méthodes de conception
de type orienté-objet. On qualifie aussi ces modèles de langages de modélisation (cf.
UML : Unified Modeling Language).
2.2. Entité
Définition : entité = représentation logique d’un individu (au sens large, c’est-à-dire
élément d’un ensemble) ou “objet”.
Une entité correspond également à une classe d'
Une entité est caractérisée par son unicité => identifiant unique (“clé”). Ex : no. SS,
no. client, no. produit.
Une entité peut être représentée par un ensemble d’attributs 3 . Ex : nom d’une
personne, âge, adresse, nom d’un produit, prix unitaire, quantité en stock, ... Chaque
attribut peut prendre un certain nombre de valeurs -> domaine de l’attribut4.
Une entité du monde réel est ainsi représentée par un ensemble d’attributs
instanciés à l’aide de valeurs.
Une entité peut être considérée comme dépendante si son existence est
conditionnée par l’existence d’une autre ou d’autres entités. Ex: si un produit n’est
livré que par un seul fournisseur et que ce fournisseur disparait, le produit va lui
aussi disparaitre. On parle aussi d’entités dominantes / dominées.
3
La clé en fait partie.
4
A rapprocher de la notion de type en programmation (types étendus)
8
2.3. Association
Une association relie des classes d’entités entre elles.
Ex: association reliant : (i) des commandes caractérisées par une date de commande,
le numéro d’identification du client, les numéros de produits commandés ainsi que les
quantités, avec (ii) des produits vendus par l’entreprise et caractérisées par un
numéro de produit, un libellé, un prix unitaire et une quantité en stock.
Une association relie en général deux classes d’entités (ass. binaire), mais elle peut
aussi relier plusieurs classes d’entités (ass. n-aires).
Une association peut avoir des propriétés particulières. Par exemple, la date
d’emprunt d’un livre
Adhérent Exemplaire
Emprunter
date d’emprunt
Les entités jouent des rôles différents dans une association. Ex: un client passe une
commande, la commande est passée5 par un client (autre classe d’entités), le produit
est référencé dans la commande, la commande référence certains produits, ...
Au sein d’une même classe, une ou plusieurs entités peuvent être mises en relation
avec une ou plusieurs entités d’une autre classe
-> Associations de type 1-1, 1-n ou n-m
-> Cardinalité d’une association
La cardinalité d’une association pour une entité constituante est constituée d’une
borne minimale et d’une borne maximale :
5
Remarquer la dualité présent / passé
9
Minimale : nombre minimum de fois qu’une occurrence de l’entité participe aux
occurrences de l’association, généralement 0 ou 1.
Maximale : nombre maximum de fois qu’une occurrence de l’entité participe aux
occurrences de l’association, généralement 1 ou n.
Exemple : une commande peut concerner plusieurs produits, mais un produit peut
aussi faire partie de plusieurs commandes -> assoc. n-m.
Attention aux interprétations de la réalité pouvant conduire à des représentations
différentes et parfois erronées -> importance de la phase d’enquête et d’analyse
auprès des utilisateurs.
2.4. Identificateurs et clés

Rappel : chaque entité est caractérisée par un identicateur (ou identifiant) unique,
qu’on appelle aussi clé (ou clé primaire) d’accès à l’entité. Lorsqu’une entité possède
plusieurs identifiants uniques, la clé peut être choisie parmi ces identifiants qui sont
considérés comme un ensemble de clés candidate.
Cet identifiant peut être constitué par un seul attribut de l’entité (ex. no. SS), mais
il peut être nécessaire de combiner plusieurs attributs afin de constituer la clé. On
parlera alors de clé composée. Ex: pour des personnes dont on ne connait pas le no.
SS, on peut combiner nom, prénom et code postal ou année de naissance afin de
réduire au maximum les risques de combinaisons équivalentes (ou “doublons”).
On pourra aussi affecter à une association un identifiant unique qui sera obtenu par
combinaison des identifiants des entités qui y participent.
Dans certains cas, il peut s’avérer impossible de constituer un identifiant unique.
Dans ce cas, on qualifiera l’entité d’entité faible (vs. entité forte). Cette notion est
à rapprocher de la notion précédente d’entité dépendante ou dominée : une entité
faible est une entité dominée.

10
2.5. Diagrammes entités-associations Classes
d’entités -> rectangles.
Atributs -> ellipses Associations
-> losanges.
Exemples : Produits / Fournisseurs / Clients, Comptes bancaires / Clients / Agences,
Etudiants / Cours / Profs.
2.6. Les Propriétés

Données élémentaires relatives à une entité
Par exemple, un numéro d’employé, une date de début de projet
On ne considère que les propriétés qui intéressent un contexte particulier
Les propriétés d’une entité sont également appelées des attributs, ou des
caractéristiques de cette entité
2.7. Spécialisation / généralisation

Certaines classes d’entités peuvent se spécialiser en sous-classes, par ex. les
comptes bancaires se spécialisent en compte-chèques et en comptes d’épargne.
Inversement, les compte-chèques et comptes d’épargne sont des sous-ensembles
de la classe plus générale des comptes bancaires. -> assoc. “Is-a”
Notion d’héritage : une entité spécialisée hérite des attributs de l’entité généralisée.

11
3. MODELE RELATIONNEL
3.1. Introduction
• En 1970, CODD présente le modèle relationnel
• Premiers systèmes commercialisés à la fin des années 70, systèmes efficaces au
début des années 80
• Modèle fondé sur la théorie des ensembles et la notion de relation (bases
mathématiques)
3.2. LE DOMAINE
Ensemble de valeurs atomiques d'un certain type sémantique
Ex. :
NOM_VILLE = {Nice, Paris, Rome}
Les domaines sont les ensembles de valeurs possibles dans lesquels sont puisées les
données.
3.3. LA RELATION
Sous ensemble du produit cartésien de plusieurs domaines
 L'extension d'une relation correspond à l'ensemble de ses éléments (données)
 Le terme RELATION désigne une extension
 L'intention d'une relation correspond à sa signification
 Le terme SCHÉMA DE RELATION désigne l'intention d'une relation.
Exemple : PERSONNE (Nom : char(20), Prénom : char(20), Age : integer, Adresse :
varchar(50), CP : integer, Ville : char(20))
Ce qui est écrit ci-dessus constitue en fait le schéma de la table PERSONNE. La
table PERSONNE est représentée sous la forme d’une table :
Nom Prénom Age Adresse CP Ville
Dupont Pierre 50 7, rue du Port 17000 La Rochelle
Martin Alain 33 4, place de la Gare 87000 Limoges

12
• Une ligne de la table constitue un élément de la relation, ou données. Elle
représente aussi une personne, instance de la relation PERSONNE. D’un point de
vue logique (mathématique), il s’agit d’un prédicat qui met en relation les attributs
de la relation.
• Il n’y a pas d’ordre sur les lignes (ni sur les colonnes) dans une table / relation.
• Il n’y a pas non plus d’information sur l’organisation physique (stockage des
données) qui est de ce fait cachée à l’utilisateur.
3.4. Schéma d’une base de données relationnelle

Le schéma d'une base de données est défini par : - l'ensemble des schémas des
relations qui la composent.
Le schéma de la BDR qui dit comment les données sont organisées dans la base
Exemple : schéma entité-association « Cours / Etudiants / Profs »
Il se traduit par le schéma relationnel de BD (ensemble de schémas de relation)
suivant :
ETUDIANT (Num_Etudiant integer, Nom char(20), Adresse varchar(50))
COURS (Num_Cours integer, Nom char(20))
PROFS (Num_Prof integer, Nom char(20), Adresse varchar(50))
COURS_SUIVIS (Num_Etudiant integer, Num_Cours integer)
COURS_ENSEIGNES (Num_Prof integer, Num_Cours integer)
3.5. Langages de manipulation

Deux classes de langages s’appliquent au modèle relationnel :
• L’algèbre relationnelle, qui est un langage de type procédural,
• Les langages de calcul relationnel, qui sont des langages de type déclaratif (ou
assertionnel), avec d’une part le calcul relationnel à variables domaines et d’autre
part le calcul relationnel à variables données.
Le langage SQL ("Structured Query Language") est le langage d'interrogation de
référence pour les utilisateurs de SGBD relationnels (cf. chapitre suivant).

13
4. LANGAGES DE REQUETES / SQL

4.1. Introduction
• SQL = Structured Query Language
• Langage de requêtes standard pour l’interrogation de bases de données
relationnelles (SQL-1 en 1989, puis SQL-2 en 1992, SQL-3 ?)
• Développé à l’origine pour le prototype de SGBD recherche d’IBM SYSTEM/R,
qui a débouché sur les produits commerciaux SQL/DS et DB-2
• Mélange d’algèbre relationnelle et de calcul relationnel à variables données
4.2. Classification des ordres SQL
Ordres SQL Aspect du langage SQL comme
CREATE – ALTER – DROP - RENAME – Définition des Langage de définition des
TRUNCATE données Données
(LDD)
INSERT – UPDATE – DELETE - LOCK TABLE Manipulation des Langage de
données (LMD) Manipulation de
Données
SELECT Interrogation des Langage d'Interrogation
données (LID) des données
GRANT – REVOKE – COMMIT – ROLLBACK – Contrôle des données Langage de contrôle des
SAVEPOINT - SET TRANSACTION (LCD) données
4.3. Opération sur la base des données

 Création de la base de données
CREATE DATABASE Nom_base_de_données

14
 Modification nom de la base de données sous SQL Server
exec sp_renamedb ancienNomDB,nouveauNomdB

 Suppression de la base de données
DROP DATABASE Nom_de_la_base_de_données
4.4. Variables
Les principaux types disponibles sont :
• INT entier
• DECIMAL (9,2) montant à 9 chiffres (décimaux) dont 2 après la virgule
• REAL réel flottant codé sur 24 bits
• CHAR (64) chaîne de caractère de longueur fixe 64
• VARCHAR (64) chaîne de caractère de longueur variable mais inférieure ou
égale à 64
• DATETIME date et/ou heure avec une précision de 3.33 ms
4.5. Opérations sur tables

• Définition de schémas de relations (et création des tables correspondantes) :
CREATE TABLE nom_table (nom_attribut_1 type_attribut_1, …)
• Suppression de tables :
DROP TABLE nom_table
• Modification de tables (ajout de colonne) :
ALTER TABLE nom_table add nom_attribut
Renommer une table sous SQL Server
EXEC sp_rename ‘AncienNomTable’,’NouveauNomTable’ ou
ALTER TABLE ancienNOM rename to nouveauNom

15
4.6. Opérations de manipulation des données

• Insertion de données dans une table : insert into nom_table values
(valeur_attribut_1, …, valeur_attribut_n)
• Suppression de données dans une table : delete from nom_table [where
condition]
• Modification de données dans une table : update nom_table set
nom_attribut = valeur_attribut [where condition]
4.7. Opération de consultation select

nom_attribut_1, …, nom_attribut_n from
nom_table_1, …, nom_table_m where
condition_1, …, condition_p Quelques « trucs
» à savoir :
− Pour voir tous les attributs d’une relation : select * from nom_table
− Élimination des doubles : select distinct nom_attribut …
− Ordonnancement des résultats : order by nom_attribut (à la fin de la requête)
− Opérateurs arithmétiques : = != > >= < <=
− Opérateurs logiques : and, or, not
− Test entre valeurs : nom_attribut between val_attr_1 and val_attr_2
− Appartenance d’une valeur d’attribut à un ensemble : [not] in, any, all
− Fonctions agrégat : avg, sum, min, max, count
− Utilisation des fonctions agrégat avec groupage : group by, having
Attention : même si le langage SQL est normalisé, chaque SGBD a des particularités
syntaxiques => voir la documentation du système utilisé !

16
5. ALGEBRE RELATIONNELLE
6.1. Introduction
• Les requêtes SQL soumises par l’utilisateur sont traduites par le SGBD en
opérations de l’algèbre relationnelle. L’algèbre relationnelle est le langage de
manipulation qu’utilise le SGBD pour effectuer des opérations sur les relations
(tables).
Utilisateurs
Requêtes SQL
SGBD
Algèbre relationnelle
6.2. Opérateurs
• Deux types d’opérateurs, unaires (opérant sur une relation) et binaires (opérant
sur deux relations).
• Cinq opérateurs de base : sélection (σ), projection (π), union (∪), différence (-)
et produit cartésien (x).
• Autres opérateurs déduits (pour faciliter l’expression des requêtes) :
intersection (∩), jointure () et division (÷).
• Opérateurs déduits à partir des opérateurs de base :
r ∩ s = r - (r - s) r
 s = σ (r x s)
r ÷ s = πR-S (r) – πR-S ((πR -S (r) x s) – r)

17
6.3. Définition formelle des opérateurs

Union (r ∪ s) : l’union de 2 relations r et s (de même schéma) est une relation t (de
même schéma) contenant l’ensemble des données appartenant à r ou à s ou aux 2
relations
Différence (r - s) : la différence de 2 relations r et s (de même schéma) est une
relation t (de même schéma) contenant l’ensemble des données appartenant à r et
n’appartenant pas à s
Intersection (r ∩ s) : l’intersection de 2 relations r et s (de même schéma) est une
relation t (de même schéma) contenant l’ensemble des données appartenant à la fois
à r et à s
Projection (r π s) : la projection d’une relation r de schéma R (A 1, A2, …, An) sur les
attributs Ai1, Ai2, …, Aip est une relation r’ de schéma R’ (A i1, Ai2, …, Aip) dont les
données sont obtenus par élimination des valeurs des attributs de R n’appartenant
pas à R’ et par suppression des données en double
Sélection (r σ s) : la sélection sur la relation r par une qualification Q est une relation
r’ de même schéma dont les données sont ceux de r satisfaisant Q Produit
cartésien (r x s) : le produit cartésien de 2 relations r et s (de schéma quelconque)
est une relation t ayant pour attributs la concaténation de ceux de r et de s, et dont
les données sont toutes les concaténations d’un données de r à un données de s
Jointure (r  s) : la jointure de 2 relations r et s (de schéma quelconque) suivant une
qualification multi-attributs Q est une relation t contenant l’ensemble des données
des produits cartésiens r x s satisfaisant Q
Division (r ÷ s) : le quotient de la relation r de schéma R (A 1, A2, …, An) par la sous-
relation s de schéma S (A p+1, …, An) est la relation q de schéma Q (A 1, …, Ap) formée
de tous les données qui, concaténés à chacun des données de s, donnent toujours un
données de r.

18
Exemples :
Soit le schéma de la table FOURNISSEUR (Nom_Fournisseur, Adresse, Produit,
Prix).
6.4. 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 ". Il y a d’autres cas de jointures,
incluant des jointures sur la même table ou des jointures d’inégalité. Ces cas étant
assez particulier et pas si simple à comprendre, ils ne seront pas élaborés sur dans
ce cours.
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 vraie dans les 2 tables. C’est l’une des jointures les plus communes.

19
• CROSS JOIN : jointure croisée permettant de faire le produit cartésien de
2 tables. En d’autres mots, permet de joindre chaque ligne d’une table avec chaque
ligne 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ée 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ée 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.
a) SQL INNER JOIN
Dans le langage SQL la commande INNER JOIN, aussi appelée EQUIJOIN, est un
type de jointures très communes pour lier plusieurs tables entre-elles. Cette
commande retourne les enregistrements lorsqu’il y a au moins une ligne dans chaque
colonne qui correspond à la condition.
Syntaxe
Pour utiliser ce type de jointure il convient d’utiliser une requête SQL avec cette
syntaxe :
SELECT *
FROM table1
INNER JOIN table2 ON table1.id = table2.fk_id
Exemple
Imaginons une application qui possède une table utilisateur ainsi qu’une table
commande qui contient toutes les commandes effectuées par les utilisateurs.

20
Table utilisateur :
Table commande :
Pour afficher toutes les commandes associées aux utilisateurs, il est possible
d’utiliser la requête suivante :
SELECT id, prenom, nom, date_achat, num_facture, prix_total FROM utilisateur
INNER JOIN commande ON utilisateur.id = commande.utilisateur_id
Résultats :
b)
CROSS JOIN
Dans le langage SQL, la commande CROSS JOIN est un type de jointure sur 2 tables
SQL qui permet de retourner le produit cartésien. Autrement dit, cela permet de
retourner chaque ligne d’une table avec chaque ligne d’une autre table. Ainsi
effectuer le produit cartésien d’une table A qui contient 30 résultats avec une table
B de 40 résultats va produire 1200 résultats (30 x 40 = 1200). En général la
commande CROSS JOIN est combinée avec la commande WHERE pour filtrer les
résultats qui respectent certaines conditions.

21
Attention, le nombre de résultat peut facilement être très élevé. S’il est effectué
sur des tables avec beaucoup d’enregistrements, cela peut ralentir sensiblement le
serveur.
Syntaxe
Pour effectuer une jointure avec CROSS JOIN, il convient d’effectuer une requête
SQL respectant la syntaxe suivante :
SELECT *
FROM table1
CROSS JOIN table2
Méthode alternative pour retourner les mêmes résultats :
SELECT *
FROM table1, table2
L’une ou l’autre de ces syntaxes permettent d’associer tous les résultats de table1
avec chacun des résultats de table2.
Exemple
Imaginons une application de recettes de cuisines qui contient 2 tables d’ingrédients,
la table légume et la table fruit.
Pour une raison quelconque l’application doit associer tous les légumes avec tous les
fruits. Toutes les combinaisons doivent être affichées. Pour cela il convient
d’effectuer l’une ou l’autre des requêtes suivantes :

22
SELECT l_id, l_nom_fr_fr, f_id, f_nom_fr_fr FROM legume CROSS JOIN fruit
ou :
SELECT l_id, l_nom_fr_fr, f_id, f_nom_fr_fr FROM legume, fruit
c) SQL LEFT JOIN
Dans le langage SQL, la commande LEFT JOIN (aussi appelée LEFT OUTER JOIN)
est un type de jointure entre 2 tables.
Cela permet de lister tous les résultats de la table de gauche (left = gauche) même
s’il n’y a pas de correspondance dans la deuxième table.
Syntaxe
Pour lister les enregistrements de table1, même s’il n’y a pas de correspondance avec
table2, il convient d’effectuer une requête SQL utilisant la syntaxe suivante.
SELECT *
FROM table1
LEFT JOIN table2 ON table1.id = table2.fk_id
La requête peut aussi s’écrire de la façon suivante :
SELECT * FROM table1 LEFT OUTER JOIN table2 ON table1.id = table2.fk_id
Cette requête est particulièrement intéressante pour récupérer les informations de
table1 tout en récupérant les données associées, même s’il n’y a pas de
correspondance avec table2. A savoir, s’il n’y a pas de correspondance les colonnes
de table2 vaudront toutes NULL.

23
Exemple
Imaginons une application contenant des utilisateurs et des commandes pour chacun
de ces utilisateurs. La base de données de cette application contient une table pour
les utilisateurs et sauvegarde leurs achats dans une seconde table. Les 2 tables sont
reliées grâce à la colonne utilisateur_id de la table des commandes. Cela permet
d’associer une commande a un utilisateur.
Table utilisateur :
Table commande :
Pour lister tous les utilisateurs avec leurs commandes et afficher également les
utilisateurs qui n’ont pas effectuées d’achats, il est possible d’utiliser la requête
suivante :
SELECT * FROM utilisateur LEFT JOIN commande ON utilisateur.id =
commande.utilisateur_id
Résultats

24
d) SQL RIGHT JOIN
En SQL, la commande RIGHT JOIN (ou RIGHT OUTER JOIN) est un type de
jointure entre 2 tables qui permet de retourner tous les enregistrements de la table
de droite (right = droite) même s’il n’y a pas de correspondance avec la table de
gauche. S’il y a un enregistrement de la table de droite qui ne trouve pas de
correspondance dans la table de gauche, alors les colonnes de la table de gauche
auront NULL pour valeur.
Syntaxe
L’utilisation de cette commande SQL s’effectue de la façon suivante :
SELECT * FROM table1 RIGHT JOIN table2 ON table1.id = table2.fk_id
La syntaxe de cette requête SQL peut aussi s’écrire de la façon suivante :
SELECT * FROM table1 RIGHT OUTER JOIN table2 ON table1.id = table2.fk_id
Cette syntaxe stipule qu’il faut lister toutes les lignes du tableau table2 (tableau de
droite) et afficher les données associées du tableau table1 s’il y a une
correspondance entre ID de table1 et FK_ID de table2. S’il n’y a pas de
correspondance, l’enregistrement de table2 sera affiché et les colonnes de table1
vaudront toutes NULL.
Exemple
Prenons l’exemple d’une base de données qui contient des utilisateurs et un historique
d’achat de ces utilisateurs. Cette 2 tables sont reliées entre grâce à la colonne
utilisateur_id de la table des commandes. Cela permet de savoir à quel utilisateur est
associe un achat.
Table utilisateur :

25
Table commande :
Pour afficher toutes les commandes avec le nom de l’utilisateur correspondant il est
normalement d’habitude d’utiliser INNER JOIN en SQL. Malheureusement, si
l’utilisateur a été supprimé de la table, alors ça ne retourne pas l’achat. L’utilisation
de RIGHT JOIN permet de retourner tous les achats et d’afficher le nom de
l’utilisateur s’il existe. Pour cela il convient d’utiliser cette requête :
SELECT id, prenom, nom, utilisateur_id, date_achat, num_facture FROM utilisateur
RIGHT JOIN commande ON utilisateur.id = commande.utilisateur_id
Résultats :
e) SQL FULL JOIN
Dans le langage SQL, la commande FULL JOIN (ou FULL OUTER JOIN) permet de
faire une jointure entre 2 tables. L’utilisation de cette commande permet de
combiner les résultats des 2 tables, les associer entre eux grâce à une condition et
remplir avec des valeurs NULL si la condition n’est pas respectée.
Syntaxe
Pour retourner les enregistrements de table1 et table2, il convient d’utiliser une
requête SQL avec une syntaxe telle que celle-ci :
SELECT *
FROM table1

26
FULL JOIN table2 ON table1.id = table2.fk_id
Cette requête peut aussi être conçue de cette façon :
SELECT *
FROM table1
FULL OUTER JOIN table2 ON table1.id = table2.fk_id
La condition présentée ici consiste à lier les tables sur un identifiant, mais la
condition peut être définie sur d’autres champs.
Exemple
Prenons l’exemple d’une base de données qui contient une table utilisateur ainsi qu’une
table commande qui contient toutes les ventes. Table utilisateur :
Il est possible d’utiliser FULL JOIN pour lister tous les utilisateurs ayant effectué
ou non une vente, et de lister toutes les ventes qui sont associées ou non à un
utilisateur. La requête SQL est la suivante :
SELECT id, prenom, nom, utilisateur_id, date_achat, num_facture
FROM utilisateur
FULL JOIN commande ON utilisateur.id = commande.utilisateur_id

27
6. CALCUL RELATIONNEL
6.1. Introduction
Le calcul relationnel est langage déclaratif de niveau supérieur qui indique quel est
le résultat qu’on obtenir.
Comme l’algèbre relationnelle, le calcul relationnel ne spécifie pas la séquence
d’opérations dans laquelle la requête sera évaluée.
6.2. Vues
Une vue est une vision partielle ou particulière des données d'une ou plusieurs
tables de la base. La définition d'une vue est donnée par un SELECT qui indique
les données de la base qui seront vues. Les utilisateurs pourront consulter la
base, ou modifier la base (avec certaines restrictions) à travers la vue, c'est-à-
dire manipuler les données renvoyées par la vue comme si c'était des données
d'une table réelle.
Seule la définition de la vue est enregistrée dans la base, et pas
les données de la vue. On peut parler de table virtuelle.
a) CREATE VIEW
La commande CREATE VIEW permet de créer une vue en spécifiant
le SELECT constituant la définition de la vue :
CREATE VIEW nom_vue (col1, col2...) AS SELECT ...
ou
CREATE VIEW nom_vue AS SELECT ...
CREATE VIEW nom
AS requête
Nom
Nom d’objet, doit être unique dans la base.
Requête Instruction SELECT ne comportant pas de clause ORDER BY,
UNION, COMPUTE ou INTO.

28
CREATE VIEW EMP2 (MATR, NOM, DEPT)
AS SELECT MATR, NOM, DEPT FROM EMP
b) DROP VIEW
DROP VIEW vue_Name
Supprime la vue.
c) Utilisation des vues

Une vue peut être référencée dans un SELECT de la même façon qu'une table. Ainsi,
il est possible de consulter la vue EMP10. Tout se passe comme s'il existait une table
EMP10 des employés du département 10 :
SELECT * FROM EMP10
d) Utilité des vues

De façon générale, les vues permettent de dissocier la façon dont les utilisateurs
voient les données, du découpage en tables. On sépare l'aspect externe (ce que voit
un utilisateur particulier de la base) de l'aspect conceptuel (comment a été conçu
l'ensemble de la base). Ceci favorise l'indépendance entre les programmes et les
données. Si la structure des données est modifiée, les programmes ne seront pas à
modifier si l'on a pris la précaution d'utiliser des vues (ou si on peut se ramener à
travailler sur des vues).
6.2. Requêtes de contrôle des données
a. DISTINCT
L’utilisation de la commande SELECT en SQL permet de lire toutes les données
d’une ou plusieurs colonnes. Cette commande peut potentiellement afficher des
lignes en doubles. Pour éviter des redondances dans les résultats il faut
simplement ajouter DISTINCT après le mot SELECT.
L’utilisation basique de cette commande consiste alors à effectuer la requête
suivante :
SELECT DISTINCT ma_colonne FROM nom_du_tableau

29
Cette requête sélectionne le champ " ma_colonne " de la table " nom_du_tableau
" en évitant de retourner des doublons.
b. AS (alias) dans SQL

Alias sur une colonne
Permet de renommer le nom d’une colonne dans les résultats d’une requête SQL. C’est
pratique pour avoir un nom facilement identifiable dans une application qui doit
ensuite exploiter les résultats d’une recherche.
La syntaxe pour renommer une colonne de colonne1 a c1 est la suivante :
SELECT colonne1 AS c1, colonne2 FROM `table`
Cette syntaxe peut également s’afficher de la façon suivante :
SELECT colonne1 c1, colonne2 FROM `table`
Alias sur une table
La syntaxe pour renommer une table dans une requête est la suivante :
SELECT * FROM `nom_table` AS t1
Cette requête peut également s’écrire de la façon suivante :
SELECT * FROM `table`t1
c. WHERE
La commande WHERE dans une requête SQL permet d’extraire les lignes d’une
base de données qui respectent une condition. Cela permet d’obtenir uniquement
les informations désirées.
Syntaxe
La commande WHERE s’utilise en complément à une requête utilisant SELECT.
La façon la plus simple de l’utiliser est la suivante :
SELECT nom_colonnes FROM nom_table WHERE condition
Exemple: Pour obtenir seulement la liste des clients qui habitent à Paris, il faut
effectuer la requête suivante :
SELECT * FROM client WHERE ville = 'paris'
Exemple

30
Imaginons une base de données appelée " client " qui contient le nom des clients,
le nombre de commandes qu’ils ont effectués et leur ville :
Pour obtenir seulement la liste des clients qui habitent à Paris, il faut effectuer la
requête suivante :
SELECT * FROM client WHERE ville = 'paris'
Opérateurs de comparaisons
Il existe plusieurs opérateurs de comparaisons. La liste ci-jointe présente quelques-
uns des opérateurs les plus couramment utilises.
• SQL AND & OR
Une requête SQL peut être restreinte à l’aide de la condition WHERE. Les
opérateurs logiques AND et OR peuvent être utilisées au sein de la commande
WHERE pour combiner des conditions.
Syntaxe d’utilisation des opérateurs AND et OR
Les opérateurs sont à ajoutes dans la condition WHERE. Ils peuvent être combines
à l’ infini pour filtrer les données comme souhaites.
L’opérateur AND permet de s’assurer que la condition1 ET la condition2 sont vrai :
SELECT nom_colonnes FROM nom_table WHERE condition1 AND condition2
L’opérateur OR vérifie quant à lui que la condition1 OU la condition2 est vrai :
SELECT nom_colonnes FROM nom_table WHERE condition1 OR condition2

31
Ces opérateurs peuvent être combines à l’infini et mélanges. L’exemple ci-dessous
filtre les résultats de la table " nom_table " si condition1 ET condition2 OU
condition3 est vrai :
SELECT nom_colonnes FROM nom_table WHERE condition1 AND (condition2 OR
condition3)
Attention : il faut penser à utiliser des parenthèses lorsque c’est nécessaire.
Cela permet d’éviter les erreurs car et ça améliore la lecture d’une requête par
un humain.
d. IN
L’opérateur logique IN dans SQL s’utilise avec la commande WHERE pour
vérifier si une colonne est égale à une des valeurs comprise dans une liste des
valeurs déterminées. C’est une méthode simple pour vérifier si une colonne
est égale à une valeur OU une autre valeur OU une autre valeur et ainsi de
suite, sans avoir à utiliser de multiple fois l’operateur OR.
Syntaxe
Pour chercher toutes les lignes ou la colonne «nom_colonne " est égale a ‘valeur
1′ OU ‘valeur 2′ ou ‘valeur 3′, il est possible d’utiliser la syntaxe suivante :
SELECT nom_colonne FROM table WHERE nom_colonne IN (valeur1, valeur2,
valeur3,
...)
NB.
La syntaxe utilisée avec l’opérateur est plus simple que d’utiliser une succession
d’opérateur OR. Pour le montrer concrètement avec un exemple, voici 2 requêtes qui
retourneront les mêmes résultats, l’une utilise l’opérateur IN, tandis que l’autre
utilise plusieurs OR.
Requête avec plusieurs OR
SELECT prenom FROM utilisateur WHERE prenom = 'Maurice' OR prenom = 'Marie'
OR prenom = 'Thimote'

32
Requête équivalent avec l’opérateur IN
SELECT prenom FROM utilisateur WHERE prenom IN ( 'Maurice', 'Marie',
'Thimote' )
e. BETWEEN
L’opérateur BETWEEN est utilisé dans une requête SQL pour sélectionner un
intervalle de données dans une requête utilisant WHERE. L’intervalle peut
être constitué de chaines de caractères, de nombres ou de dates. L’exemple
le plus concret consiste par exemple à récupérer uniquement les
enregistrements entre 2 dates définies.
Syntaxe
L’utilisation de la commande BETWEEN s’effectue de la manière suivante :
SELECT * FROM table WHERE nom_colonne BETWEEN 'valeur1' AND 'valeur2'
La requête suivante retournera toutes les lignes dont la valeur de la colonne "
nom_colonne " sera comprise entre valeur1 et valeur2.
Exemple1:
Si l’on souhaite obtenir les membres qui se sont inscrit entre le 1 avril 2020 et
le 20 avril 2020 il est possible d’effectuer la requête suivante :
SELECT * FROM utilisateur WHERE date_inscription BETWEEN ’2020-04-01′
AND ’2020-04-20′
Exemple2:
Si l’on souhaite obtenir tous les résultats dont l’identifiant n’est pas situé entre
4 et 10, il faudra alors utiliser la requête suivante :
SELECT * FROM utilisateur WHERE id NOT BETWEEN 4 AND 10

f. LIKE
L’opérateur LIKE est utilisé dans la clause WHERE des requêtes SQL. Ce mot-
clé permet d’effectuer une recherche sur un modèle particulier. Il est par
exemple possible de rechercher les enregistrements dont la valeur d’une
colonne commence par telle ou telle lettre. Les modèles de recherches sont
multiples.
33
Syntaxe
La syntaxe à utiliser pour utiliser l’opérateur LIKE est la suivante :
SELECT * FROM table WHERE colonne LIKE modele
Exemples:
• LIKE ‘%a’ : le caractère " % " est un caractère joker qui remplace tous
les autres caractères.
Ainsi, ce modèle permet de rechercher toutes les chaines de caractère qui se
termine par un " a ".
• LIKE ‘a%’ : ce modèle permet de rechercher toutes les lignes de "
colonne " qui commence par un " a ".
• LIKE ‘%a%’ : ce modèle est utilisé pour rechercher tous les
enregistrements qui utilisent le caractère " a ".
• LIKE ‘pa%on’ : ce modèle permet de rechercher les chaines qui
commence par " pa " et qui se terminent par " on ", comme " pantalon " ou "
pardon ".
g. SQL IS NULL / IS NOT NULL

Dans le langage SQL, l’opérateur IS permet de filtrer les colonnes qui
contiennent la valeur NULL. Cet opérateur est indispensable car la valeur NULL
est une valeur inconnue et ne peut par conséquent pas être filtrée par les
opérateurs de comparaison (cf. égal, inferieur, supérieur ou différent).
Syntaxe
Pour filtrer les résultats ou les champs d’une colonne sont a NULL il convient
d’utiliser la syntaxe suivante :
SELECT * FROM `table` WHERE nom_colonne IS NULL
A l’inverse, pour filtrer les résultats et obtenir uniquement les enregistrements
qui ne sont pas null, il convient d’utiliser la syntaxe suivante :
SELECT * FROM `table` WHERE nom_colonne IS NOT NULL
NB :

34
L’opérateur IS retourne en réalité un booléen, c’est à dire une valeur TRUE si la
condition est vrai ou FALSE si la condition n’est pas respectée. Cet opérateur est
souvent utilisé avec la condition WHERE mais peut aussi trouve son utilité lorsqu’une
sous-requête est utilisée.
6.4. LES PROCEDURES STOCKEES
Procédures stockées
Pour SQL Server une procédure stockée peut être définie comme une suite
d’instructions Transact SQL, stockée dans la base de données et parfaitement
identifiée par son nom. Les procédures stockées (Stored Procedures) sont des
objets correspondant à un ensemble d’instructions du LMD, pouvant être exécutées
par simple appel de leur nom ou par l’instruction EXECUTE. Ce sont de véritables
programmes pouvant recevoir des paramètres, renvoyer des valeurs, être exécutés
à distance, ayant leurs propres droits d’accès (privilège EXECUTE). De plus, les
procédures stockées sont stockées dans le cache mémoire sous forme compilée lors
de leur première exécution, ce qui accroît les performances (pour les exécutions
suivantes !).
Syntaxe
a) Création d'une procédure
Le langage Transact-SQL permet de programmer ces procédures selon la syntaxe
suivante : a.1) syntaxe:
CREATE PROC[EDURE] nom[;numero][(param1[,...])][{FOR REPLICATION|WITH
RECOMPILE}][WITH ENCRYPTION]AS instructions.
Nom
Nom d’objet unique dans la base. Précédé d’un signe #, la procédure sera temporaire
locale, avec deux # elle sera temporaire globale.
Numéro
Numéro d’ordre pour des procédures ayant le même nom.
param1,... [ OUTPUT ], pouvant être passé à la procédure. OUTPUT permet de
spécifier un paramètre retourné par la procédure.

35
FOR REPLICATION
Permet de préciser que la procédure sera utilisée lors de la réplication.
WITH RECOMPILE
La procédure sera recompilée à chaque exécution.
WITH ENCRYPTION
Permet de crypter le code dans les tables système.
Autres syntaxes.
CREATE PROC ... le nom de la procédure
(...) les paramètres d’entrée et de sortie séparés par des virgules
AS
DECLARE ... les variables locales
BEGIN
... les instructions, les transactions
END
Remarque :
– On peut utiliser jusqu’à 1024 paramètres ;
– La syntaxe d’une procédure stockée est limitée à 128 Mo.
b) Exemples
b.1) Une requête paramétrée
CREATE PROC InfoDuClient
(@numero INT) -- ne pas oublier de préciser le type
AS
SELECT *
FROM clients
WHERE clt_num = @numero
PROCÉDURES STOCKÉES 45
b.2) Autre exemple avec un paramètre de sortie :
CREATE PROC NbClients

(@resultat INT OUTPUT) AS

36
SET @resultat = (SELECT COUNT(*) FROM clients)
Utilisation de la Procédure avec paramètre en sortie.
DECLARE @NombreTotalDeClients INT
EXEC NbClients @NombreTotalDeClients OUTPUT
Et après, on peut utiliser le contenu de la variable @NombreTotalDeClients
b.3) Dernier exemple avec un paramètre d’entrée muni d’une valeur par défaut :
CREATE PROC FiltrerClients
(@filtre VARCHAR(255) = "%")
AS
SELECT *
FROM clients
WHERE clt_nom LIKE @filtre
-- en l’absence de paramètre tous les clients seront affiches
c Modification d'une procédure stockée
Pour modifier une procédure stockée :
1 ALTER PROC InfoDuClient
2 (...) -- les paramètres
3 AS
4 ... -- nouveau corps
d Suppression d'une procédure stockée
Pour supprimer une procédure stockée :
1 DROP PROCEDURE InfoDuClient
e Utilisation
On peut ensuite utiliser ces procédures stockées dans du code SQL avec l’instruction
EXEC.
Exemple : pour avoir les informations relatives au client 12
EXEC InfoDuClient 12
-- 12 est la valeur du paramètre

37
Remarque :
– On peut aussi utiliser des variables comme valeurs de paramètre (et pas
seulement des constantes comme dans l’exemple) ;
– Si la procédure a besoin d’une liste de paramètres, il faut les séparer par des
virgules ;
– S’il y a un paramètre de sortie, il faut en stocker la valeur de retour dans une
variable.

38
7. SQL - DROITS D’ACCES ET VUES

7.1. Introduction
• Nécessité de mécanismes de protection et de sécurité dans les SGBD à
différents niveaux :
a) contrôle des utilisateurs souhaitant accéder à une BD
b) contrôle de l’accès aux données (lecture, écriture)
c) contrôle de l’intégrité des données, et de la validité des opérations de MAJ
• Deux classes de droits d’accès aux données :
a) consultation
b) MAJ -> insertion, suppression, modification
• Exemples de droits d’accès sur une BD :
Relation PERSONNEL (Id, Nom, Adresse, Service, Salaire)
a) Dupont possède tous les droits d’accès (consultation, MAJ) sur la relation
PERSONNEL
b) Dupont ne possède aucun droit
c) Dupont ne peut que lire que l’information le concernant, et il ne peut pas la
modifier
d) Dupont ne peut que lire que l’information le concernant, et il peut modifier son
adresse
e) Dupont ne peut que lire que l’information le concernant, et il peut modifier son
salaire s’il est > 75 000 F
f) Dupont ne peut que lire que l’information le concernant, et il peut modifier son
salaire s’il est responsable du service (information présente dans une autre
table)
• Pb : le schéma de la BD peut évoluer au fil du temps (MAJ des schémas de
relation)
=> le mécanisme de contrôle des droits d’accès doit en tenir compte

39
7.2. Création Utilisateur
C’est par l’intermédiaire de l’instruction CREATE USER qu’il est possible de
définir des comptes utilisateurs au niveau de la base de données.
Syntaxe
CREATE USER nomUtilisateur
Attention : Il y a d'autres options à ajouter à cette requête SQL selon qu'on
utilise un ou un autre SGBD.
• Pour SQL SERVER Syntaxe1
CREATE USER nom_User
FOR LOGIN nom_login
WITH DEFAULT_SCHEMA=schemaParDefaut
a) Modification d'un Utilisateur
• SQL server
Syntaxe pour changer le nom d'un utilisateur en SQL Server :
ALTER USER
nomUtilisateur
WITH
NAME=nouveauNomUtilisateur,
DEFAULT_SCHEMA =
nomNouveauSchema
b) Suppressions
La syntaxe SQL est la suivante pour supprimer un utilisateur est :
DROP USER utilisateur
NB : Lors de l’installation, vous avez dû noter la présence de l’utilisateur SA (mot de
passe saisi à l’installation). Cet utilisateur est le DBA que SQL SERVER vous offre.
Il vous permettra d’effectuer vos tâches administratives en ligne de commande ou
par une console graphique (créer des utilisateurs par exemple).

40
c) Rôles de base de données
Les rôles de bases de données permettent toujours de regrouper les différentes
autorisations ou refus d’instructions ou d’objets et ainsi de faciliter la gestion des
droits.
Il existe des rôles prédéfinis et il est possible de définir ses propres rôles. Les
modifications sur les rôles sont dynamiques et les utilisateurs n’ont pas besoin de se
déconnecter/reconnecter de la base pour bénéficier des changements.
db_owner
Ensemble de droits équivalents au propriétaire de la base. Ce rôle contient toutes les
activités possibles dans les autres rôles de la base de données, ainsi que la possibilité
d’exécuter certaines tâches de maintenance et de configuration de la base. Tous les
membres de ce groupe vont créer des objets dont le propriétaire est dbo. Il s’agit
du propriétaire par défaut de tous les objets et il n’est pas nécessaire de le préciser
pour manipuler ses objets.
db_accessadmin
Permet d’ajouter ou de supprimer des utilisateurs dans la base de données. Ces
utilisateurs correspondent à des connexions SQL Server ou bien à des groupes ou
utilisateurs Windows.
db_datareader
Permet de consulter (SELECT) le contenu de toutes les tables de la base de données.
db_datawriter
Permet d’ajouter (INSERT), modifier (UPDATE) ou supprimer (DELETE) des données
dans toutes les tables utilisateur de la base de données.
db_ddladmin
Permet d’ajouter (CREATE), modifier (ALTER) ou supprimer (DELETE) des objets de
la base de données.
db_securityadmin
Permet de gérer les rôles, les membres des rôles, et les autorisations sur les
instructions et les objets de la base de données.

41
db_backupoperator
Permet d’effectuer une sauvegarde de la base de données.
db_denydatareader
Interdit la visualisation des données de la base.
db_denydatawriter
Interdit la modification des données contenues dans la base.
Pour attribuer rôle de base de données à un user on exécute la requête SQL suivante
exec sp_addrolemember 'db_accessadmin','REALM'
7.3. GRANT
a. Droits d’utilisation d’instructions
Les droits d’utilisation des instructions SQL pour créer de nouveaux objets au
sein de la base sont des autorisations pour réaliser l’exécution de certains
ordres SQL. Un utilisateur qui dispose de tels droits est capable par exemple
de créer ses propres tables, ses procédures... L’accord de ces droits peut être
dangereux et comme pour tous les droits, doivent être accordés uniquement
lorsque cela est nécessaire.
Les droits principaux d’instructions disponibles sont :
• CREATE DATABASE
• CREATE PROCEDURE
• CREATE FUNCTION
• CREATE TABLE
• BACKUP DATABASE
• CREATE VIEW
• BACKUP LOG
L’accord de privilèges s’effectue en utilisant l’instruction GRANT dont la
syntaxe est détaillée ci-dessous.

42
GRANT permission [,...]
TO utilisateur[,...]
[ WITH GRANT OPTION ] permission
Permission
Nom de la ou des permissions concernées par cette autorisation. Il est
également possible d’utiliser le mot clé ALL à la place de citer explicitement la
ou les permissions accordées. Toutefois ce terme ALL ne permet pas d’accorder
des privilèges d’exécution de toutes les instructions mais simplement sur les
instructions pour créer des bases de données, des tables, des procédures, des
fonctions, des tables vues ainsi que d’effectuer des sauvegardes de la base et
du journal.
Utilisateur
Nom de l’utilisateur ou des utilisateurs de base de données qui reçoivent les
permissions.
WITH GRANT OPTION
Si la permission est reçue avec ce privilège, alors l’utilisateur peut accorder la
permission à d’autres utilisateurs de base de données.
Exemple1
GRANT CREATE TABLE TO Paul, Henri
Remarque : Paul et Henri doivent déjà posséder un compte utilisateur sur SQL
Server.
b. Droits d’utilisation des objets
Ces droits permettent de fixer quelles opérations (lecture, modification, ajout
ou suppression) l’utilisateur peut réaliser sur des données contenues dans une
table, ou bien donner le droit d’exécution d’une procédure stockée. Ces droits
sont en général gérés par le propriétaire de l’objet. En ce qui concerne le droit
de lecture des données contenues dans une table (Utilisation de l’instruction
SELECT), il est possible de préciser quelles colonnes l’utilisateur peut visualiser.

43
Par défaut, il s’agit de toutes les colonnes. Les principaux droits d’utilisation des
objets concernant les tables, vues, procédures stockées correspondent aux
ordres :
• INSERT
• UPDATE
• DELETE
• SELECT
• EXECUTE : qui ne s’utilise que pour les procédures stockées.
Les droits sont accordés par la commande GRANT dont voici la syntaxe :
GRANT {ALL [PRIVILEGES]|permission[(colonne,[,...])]
[,...]}
ON
objet[,...]
TO utilisateur
[,...]
[WITH GRANT
OPTION ]
NB : Les instructions SELECT et UPDATE peuvent être limitées à certaines colonnes
de la table ou de la vue. Il est cependant préférable de ne pas trop explorer cette
possibilité car il en résulte un plus grand travail administratif au niveau de la gestion
des droits. Il est préférable de passer par une vue ou bien une procédure stockée
pour limiter l’usage de la table.
Exemple :
GRANT INSERT, SELECT, DELETE, UPDATE(ISBN) ON LivreTO Paul ;
Privilège objet table level :
Paul peut insérer, extraire, supprimer et modifier la colonne ISBN de la table
Livre
7.4 Revoke
Permet de retirer des droits à un utilisateur (ou plusieurs sur certains SGBD)

44
a. Revoke sur les Instructions

Exemple1 : pour lever les autorisations et les empêchements de Paul
REVOKE CREATE TABLE TO Paul
Exemple 2 pour empêcher Paul de créer des vues
DENY CREATE VIEW TO Paul
b. Revoke sur les Objets
Syntaxe avec SQL SERVER

REVOKE [GRANT OPTION FOR ]
{ALL [PRIVILEGES]|permission[(colonne,[,...])] [,...]}
ON object [(colonne [,...])]
{FROM | TO} utilisateur [,...]
[CASCADE ]
GRANT OPTION FOR
Exemples avec SQL server :
1. Retirer le droit de sélection à l’utilisateur ‘Jean' à la table personne
revoke select on personne to Jean
2. Retirer le droit d'insertion, de sélection, de suppression et de Mis à jour de
la colonne code à l’utilisateur ‘Jean' à la table personne
revoke INSERT, SELECT, DELETE, UPDATE(CODE) ON personne from jean
ou
revoke INSERT, SELECT, DELETE, UPDATE(CODE) ON personne To jean

45
8. NORMALISATION
8.1. Introduction
L'objectif de la normalisation est de construire un schéma de base de données
cohérent et possédant certaines propriétés vérifiées par la satisfaction de formes
normales.
Pour une application spécifique, il est en effet possible de proposer plusieurs
schémas. Les questions qui se posent alors sont les suivantes :
a) qu'est-ce qu'un bon schéma ?
b) quel schéma choisir ?
Un mauvais schéma défini lors de la phase de conception peut conduire à un certain
nombre d'anomalies pendant la phase d'exploitation de la base :
− Des redondances d'information,
− Des anomalies lors des opérations de mise à jour (insertions, suppressions,
modifications). Exemple :
Soit le schéma de relation FOURNISSEUR (Nom_Fournisseur, Adresse, Produit,
Prix).
Une relation (table) correspondant à ce schéma pourra éventuellement contenir
plusieurs produits pour un même fournisseur. Dans ce cas, l'adresse du fournisseur
sera dupliquée dans chaque donnée (redondance).
Si on souhaite modifier l'adresse d'un fournisseur, il faudra rechercher et mettre à
jour tous les données correspondant à ce fournisseur.
Si on insère un nouveau produit pour un fournisseur déjà référencé, il faudra vérifier
que l'adresse est identique.
Si on veut supprimer un fournisseur, il faudra retrouver et supprimer tous l es
données correspondant à ce fournisseur (pour différents produits) dans la table.
Ces anomalies n'apparaitront pas si on décompose le schéma initial de base de
données.

46
Par contre, la décomposition d'un schéma relationnel au cours de la normalisation
risque d'entrainer une dégradation des performances, du fait des opérations de
jointure nécessaires.
Les 3 premières formes normales ont été proposées par E.F. Codd ("inventeur" du
modèle relationnel) en 1972. La forme normale dite de Boyce-Codd a été proposée en
1974. Les 4ème (1977) et 5ème (1979) formes normales ont été proposées ensuite par
Fagin, mais elles ne concernent que des cas rares et très spécifiques.
Les formes normales s'appuient sur les dépendances fonctionnelles entre attributs
d'un schéma de base de données.
8.2. Dépendances fonctionnelles

Définition : un attribut (ou un groupe d'attributs) B est dit "fonctionnellement
dépendant" d'un attribut (ou d'un groupe d'attributs) A si : a1 = a2 => b1 = b2,
a1, a2, b1, b2 étant des réalisations (valeurs) des attributs A et B dans des données
de la base de données.
On dit alors que A "détermine" B, et on note A -> B.
Exemple :
Soit le schéma de relation PERSONNE (No_SS, Nom, Adresse, Age, Profession). Les
dépendances fonctionnelles qui s'appliquent sur ce schéma de relation sont les
suivantes :
No_SS -> Nom, No_SS -> Adresse, No_SS -> Age, No_SS -> Profession.
On pourra aussi écrire :
No_SS -> Nom Adresse Age Profession.
L'attribut No_SS détermine tous les attributs du schéma de relation. Il s'agit d'une
propriété de la clé d’un schéma de relation.

47
Exercice :
Soit la relation suivante r de schéma R (A, B, C, D, E).
A B C D E
a1 b1 c1 d1 e1
a1 b2 c2 d2 e1
a2 b1 c3 d3 e1
a2 b1 c4 d3 e1
a3 b2 c5 d1 e1
Les dépendances fonctionnelles satisfaites par R sont les suivantes :
A -> E ; B -> E ; C -> ABDE ; D -> E ; AB -> D ; AD -> B ; BD -> A.
8.3. 1ère forme normale (FN1)
Définition : une relation est en 1ère forme normale si elle ne contient que des " valeurs
atomiques", c'est-à-dire pas de "groupes répétitifs".
Exemple : la valeur "Jacques" affectée à l'attribut Prénom
Contre-exemple : la valeur "Jacques, Paul" affectée à l'attribut Prénom, à moins qu'il
ne s'agisse d'un prénom composé.
De la même façon, on ne pourra pas mettre dans un même attribut Parent tous les
enfants d'une personne. Il faudra, soit prévoir autant de colonnes que de nombre
d'enfants possibles, soit insérer dans la base autant de données que d'enfants en
répétant à chaque fois le nom du parent.
Remarque : cette restriction est très contraignante pour certaines classes
d'applications telles que la conception assistée par ordinateur (CAO) ou les systèmes
d'information géographique (SIG).

48
8.4. 2ème forme normale (FN2)
La 2ème forme normale s'appuie sur la notion de DF " complète" (ou "pleine"). Une DF
X -> Y est complète si, X et Y étant attributs d'une même relation, Y n'est pas
fonctionnellement dépendant d'un sous-ensemble de X.
Exemple : si AB -> C sur R (A, B, C), on ne peut avoir ni A -> C ni B -> C.
Dans le cas contraire, c'est-à-dire si on peut enlever un attribut de X, et que la DF
est toujours applicable, on dit qu'elle est " partielle".
Définition : une relation est en 2 ème forme normale si elle est déjà en 1ère forme
normale, et si tout attribut n’appartenant pas à la clé (primaire) dépend
complètement de cette clé, c’est-à-dire si toutes les DF s’appliquant sur R sont
complètes.
Remarque : si toutes les DF sont des DF "simples", avec un seul attribut en partie
gauche, ou si les clés sont atomiques, alors la relation est FN2.
8.5. 3ème forme normale (FN3)
En décomposant R en R 1 et R 2, on élimine des risques d'erreurs, mais on peut avoir
d'autres types d'erreurs, lors d'opérations de mise à jour, du fait des DF
"transitives".
Définition : une DF X -> Z est transitive lorsqu'on a X -> Y et Y-> Z (application de la
transitivité avec les axiomes d'Armstrong).
Définition : une relation est en troisième forme normale si elle satisfait FN1 et
FN2, et si aucun attribut n'appartenant pas à la clé (primaire) ne dépend de la clé
par des DF transitives, c'est-à-dire si aucune DF transitive ne s'applique sur cette
relation.
Pour rendre la relation FN3, il faut donc éliminer les DF transitives en plaçant
certains attributs dans une autre relation.
Autre définition : Une relation est FN3 si, pour toute DF X -> A s'appliquant sur R
avec A non inclus dans X, soit X est clé de R, soit A fait partie d'une clé de R.

49
Exemple : Soit le schéma de relation R (Nom_F, Adresse_F, Produit, Prix), avec
comme ensemble de DF F = {Nom_F -> Adresse_F ; Nom_F Produit -> Prix}. La clé
de R est [Nom_F Produit]. Pour Nom_F -> Adresse_F, Nom_F n'est pas clé, et
Adresse_F ne fait pas partie de la clé. La relation n'est donc pas FN3.
8.6. Forme normale de Boyce-Codd (FNBC)
Avec FN3, les DF partielles et transitives ont été éliminées pour les clés primaires,
mais il faut également considérer les autres clés possibles (clés "candidates") si elles
existent.
Remarque : si la relation ne contient qu'une clé et qu'elle est FN3, alors elle est aussi
FNBC.
Définition : une relation est FNBC si elle est FN1, FN2 et FN3, et si toutes les parties
gauches des DF sont clés candidates pour la relation.
Autre définition : une relation est FNBC si, pour toute DF X -> A s'appliquant sur R
avec A non inclus dans X, X est clé (primaire ou candidate) de R.
Exemple : Soit le schéma de relation R (Nom_F, Adresse_F, Produit, Prix), avec
comme ensemble de DF F = {Nom_F -> Adresse_F ; Nom_F Produit -> Prix}. La clé
de R est [Nom_F Produit]. Pour Nom_F -> Adresse_F, Nom_F n'est pas clé, et la
relation n'est donc pas FNBC.

50
9. ORGANISATION ET STOCKAGE DES DONNEES
9.1. Introduction
9.1.1. Organisation physique des données sur disque
Un disque (parfois désigné comme un volume) est organisé en pistes qui sont-elles
mêmes découpées en secteurs. Si le disque comporte plusieurs plateaux, les pistes
de même position sur les différents plateaux constituent un cylindre.
L'unité élémentaire d'information qui peut être lue ou écrite sur un disque est le
secteur (en général un multiple de 512 octets).
Une opération de lecture ou écriture sur disque se fait en trois temps :
• initialisation de l'opération : sélection de l'unité (ou volume), positionnement des
têtes de lecture (piste et secteur),
• opération de transfert proprement dite : lecture ou écriture des données sur
disque à une adresse donnée (no. piste / no. cylindre + no. secteur),
• terminaison de l'opération : vérification du bon déroulement de l'opération, signal
au système d'exploitation.
Pour diminuer les phases d'initialisation et de terminaison, les données sont lues /
écrites de manière temporaire et transparente à l'utilisateur dans des zones
mémoire appelées tampons ("buffers") qui contiennent plusieurs secteurs. Lorsqu'un
tampon est plein / vide, une opération d'écriture / lecture est réalisée.
Schéma Disque
9.1.2. Notions de base de l'organisation physique / logique des données
Un fichier est un ensemble d'informations organisées dans des enregistrements
logiques / physiques et de longueur fixe ou variable.
Un enregistrement est un ensemble d'informations correspondant à une entité
logique (par exemple personne) ou physique (bloc ou secteur physique d'un disque).
On aura donc des enregistrements logiques (ou articles) en correspondance avec des
enregistrements physiques (blocs ou secteurs).

51
Un enregistrement logique pourra être stocké dans un ou plusieurs enregistrements
physiques en fonction de sa taille. L'enregistrement logique est l'unité de travail
pour l'utilisateur, et l'enregistrement physique est l'unité de stockage sur disque.
Un champ est un sous-ensemble d'un enregistrement qui représente un attribut
d'une entité logique (par exemple nom ou adresse d'une personne).
La clé est l'identifiant unique d'un enregistrement logique (par exemple no. de
sécurité sociale pour une personne).
Schéma Fichier
9.1.3. Types d'organisation physique des données sur disque
On distingue deux types d'organisation des données sur disque
• l'organisation séquentielle consiste à placer les enregistrements logiques à la
suite les uns des autres dans des enregistrements physiques, indépendamment de
leur contenu.
• l'organisation calculée elle consiste à placer les enregistrements logiques sur
disque en fonction de leur contenu.
L'organisation des données sur disque est fixée lors de la création du fichier. Le
placement des données sur disque lors des opérations d'écriture / insertion dépend
de ce choix d'organisation.
Cette question sera revue en détail un peu plus loin.
Schéma Organisations
9.1.4. Système de gestion de fichiers (SGF)
Il s'agit d'un des composants du système d'exploitation, dont la tâche est
précisément de gérer les fichiers sur disque (création, suppression, ouverture,
fermeture) et de prendre en charge les opérations d'accès physique aux fichiers
(lecture / écriture) pour des opérations logiques de consultation / insertion /
modification / suppression.

52
Il gère aussi le système de stockage intermédiaire à l'aide de tampons.
Schéma SGF dans SE
9.2. Aspects caractéristiques

9.2.1. Indépendance logique / physique
On a vu au chapitre 1 qu'on distinguait trois niveaux de représentation dans un
système d'information : le niveau externe (utilisateurs), le niveau conceptuel
(administrateur) et le niveau interne (système de stockage).
L'indépendance logique / physique consiste à libérer l'utilisateur des contraintes
d'organisation et d'implantation physiques (structures de données, méthodes
d'accès), en ne lui laissant voir (si possible) que l'organisation logique qu'il a lui-même
définie.
9.2.2. Performances
L'aspect performances est essentiel pour de nombreuses classes d'applications, et
plus particulièrement les applications transactionnelles (par exemple systèmes
bancaires ou systèmes de réservation, plus généralement tous les systèmes temps
réel).
Quoiqu'il en soit, le temps de réponse est toujours important pour l'utilisateur, et
l'efficacité en ce domaine passe par une organisation physique des données efficace.
Fichiers et structures de données nécessaires au fonctionnement d'un SGBD
Une base de données contient :
a) des fichiers contenant les données entrées par les utilisateurs,
b) un fichier créé par le SGBD, le dictionnaire des données, qui contiennent des
informations relatives aux données stockées par les utilisateurs (méta-données),
c) des fichiers créés par le SGBD, les index, qui permettent d'accélérer les
recherches d'informations dans les BD,
d) des données statistiques relatives aux données elles-mêmes (taille des
fichiers, nombre de valeurs différentes par attribut, …), mais aussi aux opérations

53
effectuées sur ces données (nombres d'insertions, suppressions et modifications ;
fréquences de recherche sur les attributs).
9.2.3. Hiérarchie de mémoires
Un SGBD s'appuie sur différents niveaux de mémoire pour "optimiser" la gestion
des données et les opérations relatives aux données :
a) la mémoire principale de l'ordinateur (RAM),
b) la mémoire "cache",
c) les disques de stockage,
d) des unités d’archivage tel que des bandes magnétiques ou disques optiques.

54
EXERCICES D'APPLICATION
1. On considère la base de données
BD AIRBASE suivante :
 PILOT (NumP, NameP, Address, Salary)
 AIRPLANE (NumAP, NameAP, Capacity, Localisation)
 FLIGHT(NumF,#NumP,#NumAP, Dep_T, Arr_T, Dep_H,Arr_H)
Convention :
Les clés primaires sont soulignées et les clés étrangères sont précédés du
caractère "#"
Q0. Créer les 3 tables en respectant les différentes contraintes
Q1 : Donnez la liste des avions dont la capacité est supérieure à 350 passagers.
Q2 : Quels sont les numéros et noms des avions localisés à Nice ?
Q3 : Quels sont les numéros des pilotes en service et les villes de départ de
leurs vols ?
Q4 : Donnez toutes les informations sur les pilotes de la compagnie.
Q5 : Quel est le nom des pilotes domiciliés à Paris dont le salaire est supérieur
à 15000 ? Q6 : Quels sont les avions (numéro et nom) localisés à Nice ou dont
la capacité est inférieure à 350 passagers ?
Q7 : Liste des vols au départ de Nice allant à Paris après 18 heures ?
Q8 : Quels sont les numéros des pilotes qui ne sont pas en service ?
Q9 : Quels sont les vols (numéro, ville de départ) effectués par les pilotes de
numéro 100 et 204 ?
EXERCICE 2
Soit le modèle Logique des données suivant.
• Clients (NumCli, Nom, Prénom, Adresse, Cp, Ville, Téléphone)
• Achats (numAchat,#NumCli, #NumArt, Date, Qté)
• Articles (NumArt, Désignation, Catégorie, Prix)
En utilisant le langage SQL

55
1. Créer les 3 tables Clients, Articles et Achats
Sachant que les champs soulignés dans le modèle Logique des données
sont des clés Primaires et les champs précédés par ”#” sont des clés
étrangères.
NB: La désignation des articles ne doit pas accepter des valeurs nulles
2. Créer la requête SQL qui permet de supprimer la table “client”
3.Ajouter la colonne “dateNaiss” dans la table client
4.Modifié la taille du champs “nom” de 50 à 100 de la table client
5.Supprimer la clé primaire de la table Client
6.Récréer la clé primaire de la table Client en l’attribuant le nom la clé “
PK_client”. 7. Le prix et la Quantité ne doivent que recevoir des valeurs
supérieur ou égal à
ZERO.
8. La désignation des articles doit être unique
9. Insérer les enregistrements dans les 3 tables selon les tables ci-
dessus.
10. Ajouter le numéro de téléphone pour les clients qui n’en possèdent
pas.
11. Supprimer tous les articles dont le prix est entre 12 et 20.
EXERCICE 4
–Syntaxe des types de données
Quelles sont les spécifications de valeurs syntaxiquement incorrectes ?
a) DATE '18/11/2004'
b) DATE '2002-11-18'
c)TIME '11 :16'
d) DATE '2004-11-18 20:20:30 000'
e)123,55
f)1E-10
56
g)3.145 E-1
h)'456,78'
EXERCICE 5
Schéma de la base Chantiers
Une société désire informatiser les visites des chantiers de ses employés. Pour
définir cette base de données, une première étude fait apparaître les
informations suivantes :
• Chaque employé est modélisé par un numéro, un nom et une qualification.
• Un chantier est caractérisé par un numéro, un nom et une adresse.
• L’entreprise dispose de véhicules pour lesquels est important de stocker pour
le numéro d’immatriculation, le type (un code valant par exemple 0 pour une
camionnette, 1 pour une moto et 2 pour une voiture) ainsi que le kilométrage en
fin d’année.
• Le gestionnaire a besoin de connaître les distances parcourues par un véhicule
pour chaque visite d’un chantier.
• Chaque jour, un seul employé sera désigné conducteur des visites d’un véhicule.
• Pour chaque visite, il est important de pouvoir connaître les employés
transportés.
Exercice 6 :
Soit le modèle relationnel suivant relatif à la gestion simplifiée des étapes du
Tour de France 97, dont une des étapes de type "contre la montre individuel"
se déroula à Saint-Etienne :
EQUIPE(CodeEquipe, NomEquipe, DirecteurSportif)
COUREUR(NuméroCoureur, NomCoureur, CodeEquipe*, CodePays*)
PAYS(CodePays, NomPays) TYPE_ETAPE(CodeType, LibelléType)
ETAPE(NuméroEtape, DateEtape, VilleDép, VilleArr, NbKm, CodeType*)
PARTICIPER(NuméroCoureur*, NuméroEtape*, TempsRéalisé)

57
ATTRIBUER_BONIFICATION(NuméroEtape*, km, Rang, NbSecondes,
NuméroCoureur*)
Remarque : les clés primaires sont soulignées et les clés étrangères sont
marquées par *
Questions :
1 - Quelle est la composition de l'équipe Festina (Numéro, nom et pays des
coureurs) ?
2 - Quel est le nombre de kilomètres total du Tour de France 97 ?
3 - Quel est le nombre de kilomètres total des étapes de type "Haute
Montagne"?
4 - Quels sont les noms des coureurs qui n'ont pas obtenu de bonifications ?
5 - Quels sont les noms des coureurs qui ont participé à toutes les étapes ?
6 - Quel est le classement général des coureurs (nom, code équipe, code pays et
temps des coureurs) à l'issue des 13 premières étapes sachant que les
bonifications ont été intégrées dans les temps réalisés à chaque étape ?
7 - Quel est le classement par équipe à l'issue des 13 premières étapes (nom et
temps des équipes) ?
EXERCICE 7
Soit le modèle relationnel suivant relatif à la gestion des notes annuelles d'une
promotion d'étudiants :
ETUDIANT(N°Etudiant, Nom, Prénom)
MATIERE(CodeMat, LibelléMat, CoeffMat)
EVALUER(N°Etudiant*, CodeMat*, Date, Note)
Remarque : les clés primaires sont soulignées et les clés étrangères sont
marquées par * Questions :
Requête 1 - Quel est le nombre total d'étudiants ?
Requête 2 - Quelles sont, parmi l'ensemble des notes, la note la plus haute et la
note la plus basse ?

58
Requête 3 - Quelles sont les moyennes de chaque étudiant dans chacune des
matières ?
Requête 4 - Quelles sont les moyennes par matière ? On utilisera la requête de
la question 3 comme table source
Requête 5 - Quelle est la moyenne générale de chaque étudiant ?
On utilisera la requête de la question 3 comme table source
Requête 6 - Quelle est la moyenne générale de la promotion ?
Requête 7 - Quels sont les étudiants qui ont une moyenne générale supérieure
ou égale à la moyenne générale de la promotion ?
EXERCICE 8
Soit le modèle relationnel suivant relatif à la gestion simplifiée des étapes du
Tour de France 97, dont une des étapes de type "contre la montre individuel"
se déroula à Saint-Etienne :
EQUIPE(CodeEquipe, NomEquipe, DirecteurSportif)
COUREUR(NuméroCoureur, NomCoureur, CodeEquipe*, CodePays*)
PAYS(CodePays, NomPays)
TYPE_ETAPE(CodeType, LibelléType)
ETAPE(NuméroEtape, DateEtape, VilleDép, VilleArr, NbKm, CodeType*)
PARTICIPER(NuméroCoureur*, NuméroEtape*, TempsRéalisé)
ATTRIBUER_BONIFICATION(NuméroEtape*,km, Rang, NbSecondes,
NuméroCoureur*) Remarque : les clés primaires sont soulignées et les clés
étrangères sont marquées par *
Questions :
Requête 1 - Quelle est la composition de l'équipe Festina (Numéro, nom et pays
des coureurs) ?
Requête 2 - Quel est le nombre de kilomètres total du Tour de France 97 ?

59
Requête 3 - Quel est le nombre de kilomètres total des étapes de type "Haute
Montagne"?
Requête 4 - Quels sont les noms des coureurs qui n'ont pas obtenu de
bonifications ?
Requête 5 - Quels sont les noms des coureurs qui ont participé à toutes les
étapes ?
Requête 6 - Quel est le classement général des coureurs (nom, code équipe,
code pays et temps des coureurs) à l'issue des 13 premières étapes sachant que
les bonifications ont été intégrées dans les temps réalisés à chaque étape ?
Requête 7 - Quel est le classement par équipe à l'issue des 13 premières étapes
(nom et temps des équipes) ?
EXERCICE 9
Soit la base de donnée suivante :
1. Soulignez les clés primaires, rajoutez un # derrière les clés étrangères.
2. Donnez la liste (Nom) des restaurants de plus de 2 étoiles par ordre
alphabétique.
3. Nom et adresse des restaurants qui ne proposent pas le menu 10.
4. Donnez la liste (Nom, Adresse) des restaurants qui ne vendent pas de
boissons alcoolisées.
5. Nombre de menus par restaurant par ordre croissant du nombre de menu.

60
6. Nom du restaurant, nom du chef, nombre d‘étoiles, prix mini, moyen et maxi
d‘un menu dans chaque restaurant.
7. Nom du restaurant qui propose le menu le plus cher.
8. Liste des boissons en 'demi-bouteille proposées par le restaurant 1.
9. Nom des restaurants qui proposent ”foie gras poêlé‘ en entrée.
10. Donnez la liste des restaurants (nom, adresse, téléphone) qui proposent
un plat à base de ”canard‘.
11. Donnez la liste (idem) des restaurants ayant le même nombre d’étoiles
que le restaurant dont le chef s'appelle 'Dugros'

61
Table des matières

SOMMAIRE .................................................................................................................................. 1
1. INTRODUCTION ................................................................................................................... 2
1.1. Objectifs ........................................................................................................................... 2
1.2. Justification historique ................................................................................................. 3
1.3. Indépendance données / programmes........................................................................ 3
1.4. Niveaux d’abstraction .................................................................................................... 4
1.5. Modèles de données........................................................................................................ 4
1.6. Langages ............................................................................................................................ 4
1.7. Fonctions liées à l’exploitation des SGBD ................................................................. 5
1.8. Fonctionnalités et organisation générale................................................................... 5
2. MODELISATION CONCEPTUELLE .................................................................................. 7
2.1. Introduction ..................................................................................................................... 7
2.2. Entité................................................................................................................................. 7
2.3. Association ....................................................................................................................... 8
2.4. Identificateurs et clés ................................................................................................. 9
2.6. Les Propriétés ............................................................................................................... 10
2.7. Spécialisation / généralisation .................................................................................. 10
3. MODELE RELATIONNEL ................................................................................................... 11
3.1. Introduction .................................................................................................................... 11
3.2. LE DOMAINE................................................................................................................. 11
3.3. LA RELATION................................................................................................................ 11
3.4. Schéma d’une base de données relationnelle ......................................................... 12
3.5. Langages de manipulation............................................................................................ 12
4. LANGAGES DE REQUETES / SQL ................................................................................. 13
4.1. Introduction ................................................................................................................... 13
4.2. Classification des ordres SQL .................................................................................. 13
4.3. Opération sur la base des données .......................................................................... 13
4.4. Variables ......................................................................................................................... 14
4.5. Opérations sur tables .................................................................................................. 14
4.6. Opérations de manipulation des données ................................................................ 15
5. ALGEBRE RELATIONNELLE............................................................................................. 16

62
6.1. Introduction ................................................................................................................... 16

6.2. Opérateurs ..................................................................................................................... 16
6.3. Définition formelle des opérateurs ......................................................................... 17
6.4. Jointure SQL................................................................................................................. 18
6. CALCUL RELATIONNEL ....................................................................................................27
6.1. Introduction ...................................................................................................................27
6.2. Vues .................................................................................................................................27
6.2. Requêtes de contrôle des données ...........................................................................28
a. DISTINCT .....................................................................................................................28
b. AS (alias) dans SQL ......................................................................................................29
c. WHERE .........................................................................................................................29
d. IN ................................................................................................................................... 31
e. BETWEEN ....................................................................................................................32
f. LIKE ..............................................................................................................................32
g. SQL IS NULL / IS NOT NULL ....................................................................................33
6.4. LES PROCEDURES STOCKEES .................................................................................34
7. SQL - DROITS D’ACCES ET VUES.................................................................................38
7.1. Introduction ...................................................................................................................38
7.2. Création Utilisateur .....................................................................................................39
7.3. GRANT ............................................................................................................................ 41
7.4 Revoke ..............................................................................................................................43
8. NORMALISATION .............................................................................................................45
8.1. Introduction ...................................................................................................................45
8.2. Dépendances fonctionnelles .......................................................................................46
8.3. 1ère forme normale (FN1) ............................................................................................47
8.4. 2ème forme normale (FN2) ..........................................................................................48
8.5. 3ème forme normale (FN3) ........................................................................................48
8.6. Forme normale de Boyce-Codd (FNBC) ...................................................................49
9. ORGANISATION ET STOCKAGE DES DONNEES ....................................................50
9.1. Introduction ...................................................................................................................50
9.1.1. Organisation physique des données sur disque ...............................................50
9.1.2. Notions de base de l'organisation physique / logique des données ...........50

63
9.1.3. Types d'organisation physique des données sur disque................................ 51

9.1.4. Système de gestion de fichiers (SGF) ............................................................. 51
9.2. Aspects caractéristiques ...........................................................................................52
9.2.1. Indépendance logique / physique .......................................................................52
9.2.2. Performances .........................................................................................................52
9.2.3. Hiérarchie de mémoires ......................................................................................53
EXERCICES D'APPLICATION ..............................................................................................54

Cours TBD G2

Transféré par

Droits d'auteur :

Formats disponibles

Cours TBD G2

Transféré par

Informations du document

Description originale:

Titre original

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

Cours TBD G2

Transféré par

Droits d'auteur :

Formats disponibles

1

Héritier Kangela, Ir. Institut Supérieur de Commerce

Technique de Banque de Données

Année Académique 2020-2021

Chapitre 2 : Modèle conceptuel

Chapitre 3 : Modèle relationnel

Chapitre 4 : Langages de requêtes / SQL

Chapitre 5 : Algèbre relationnelle

Chapitre 6 : Calcul relationnel

Chapitre 7 : SQL - Droits d’accès et vues

Chapitre 9 : Stockage et indexation

Ir. Hériti er Kangela heritierkangela2013@gmail.com ISC-GOMA

exploitables au moyen d’un ensemble de programmes.

• Définition : système de gestion de bases de données (SGBD) = outil (logiciel)

permettant d’accéder à des BD.

- Professionnels relationnels : Oracle, Sybase, Informix, ...,

- Professionnels orientés-objets : Versant, Objectstore, O2, ...

- Personnels : Access, Paradox, 4D, ...,

- Consultation à distance des cours de la bourse,

- Facturation à partir des données relatives aux commandes-clients et aux

caractéristiques de produits, ...

• Notions de données vs. informations : donnée = information codée sur un support

(définition personnelle non officielle)

• Notion de système d’information : plus générale que celle de BD. Inclut la

description des flux de données, les aspects organisationnels, ...

• Objectifs des SGBD :

- Exploitation de gros volumes de données => structures de données et

méthodes d’accès efficaces,

- Exploitation par différents types d’utilisateurs => différents outils d’accès

- Gestion de données sensibles => sécurité et fiabilité des outils, - aspect

multi-utilisateurs => mécanismes de protection2,

1.2. Justification historique

utilisant le système de gestion de fichiers2 pour gérer et exploiter les données

 Risques liés au manque de sécurité + multiplication des efforts

(programmes similaires écrits dans différents services pour des besoins

- Risque d’incohérences : du fait des redondances et des MAJ non centralisées

(ex: adresse d’un fournisseur),

- Intégrité des données : respect de contraintes qui peuvent être

- Problème liés à la sécurité : utilisateurs de différents niveaux d’expérience

et avec différents droits d’accès => mots de passe,

- Problème liés au partage des données : accès en lecture / écriture.

1.3. Indépendance données / programmes

programmeurs et les utilisateurs en général de la connaissance précise de la façon

dont les données sont structurées.

1.4. Niveaux d’abstraction

les bases de données et les systèmes d’information de manière plus générale :

• Le niveau externe (utilisateur) -> vues

• Le niveau conceptuel (concepteur, administrateur) -> modèles de données

• Le niveau interne (stockage) -> structures de données (fichiers, index)

1.5. Modèles de données

• Les modèles orientés information -> définition du schéma conceptuel

 Modèle entité-association et ses dérivés (MERISE, ...)

• Les modèles orientés données -> mise-en-œuvre du SGBD

 Modèle relationnel, modèle hiérarchique, modèle réseau/CODASYL

 Décrivent à la fois ce que l’utilisateur souhaite et l’algorithme de résolution

du problème : “quoi et comment”

• Langages déclaratifs (ou assertionnels)

 Se limitent à décrire la demande de l’utilisateur : “quoi”