Base de Données

Support de cours : BASE DE DONNEES ET SQL
Spécialités : TRONC COMMUN (GL 1, GSI 1)
Enseignant : M. KEUMFACK
Master 2 en Management des Systèmes d’Information et d’Infrastructure (MS2I)

Base de données et SQL
Programme de cours :
1 Objectifs fondamentaux d’une Base de données
2 Modélisation des données
3 Le Modèle relationnel
4 La Normalisation
5 Le Langage SQL
Présentation globale :
Ce support de cours s’adresse à tous ceux qui veulent concevoir, implanter, alimenter et
interroger une base de données (BD), et intégrer cette BD à une application. Dans un contexte
académique, il s’adresse aux étudiants en deuxième année. Dans un contexte professionnel, le
contenu du cours présente tout ce qu’il est nécessaire de maîtriser quand on conçoit une BD ou
que l’on développe des applications qui s’appuient sur une BD. Au-delà de ce public principal,
toute personne désirant comprendre les principes, méthodes et outils des systèmes de gestion
de données trouvera un intérêt à lire les chapitres consacrés à la conception, à l’interrogation et
à la programmation SQL, pour ne citer que les principaux.
Objectifs généraux :
L’objectif du cours de base de données est de permettre à l’étudiant de comprendre le

rôle et l’apport des bases de données dans le développement des applications.
Objectifs spécifiques:
Ce cours présente de façon claire et didactique toutes les données qui président à la
conception d’une base de données, à la mise en pratique et à la programmation BD. Ensuite
après une présentation générale des BD et de ces différents langages, il propose pour les
différents constituants un mode de fonctionnement et un moyen de gestion des ressources
associées ainsi que leurs caractéristiques.
par M. KEUMFACK P a g e 1 | 51
Chapitre 1
Objectifs fondamentaux d’une Base de données
Objectif général : À la fin de ce chapitre, l’étudiant doit être capable de définir une base de
données et d’énumérer les rôles d'un SGBD, ainsi que les différents types qui existent
actuellement.
Dès les débuts de l’informatique, l’un des soucis majeurs de l’utilisateur fut de pouvoir
stocker massivement des données et de pouvoir en disposer régulièrement afin d’en extraire de
nouvelles informations, de les consulter et de les modifier. De 1950 à 1960, seul existait le
fichier pour satisfaire à cette demande. Les applications devaient donc être complétées par une
programmation qui se faisait souvent en langage machine (assembleur). Les SGFs ont montré
une insuffisance et des inconvénients ce qui a mené à l’apparition des bases de données dès
1960.
1. Qu'est-ce qu'une base de données ?

Une base de données informatisée est un ensemble structuré de données enregistrées
sur des supports accessibles par l’ordinateur, représentant des informations du monde réel et
pouvant être interrogées et mises à jour par une communauté d’utilisateurs. C’est aussi un
ensemble de données structurés et organisationnel relie entre eux par l’intermédiaire des clés
secondaires.
2. enjeux
Les bases de données ont pris une place importante en informatique, et particulièrement
dans le domaine de la gestion. L'étude des bases de données a conduit au développement de
concepts, méthodes et algorithmes spécifiques, notamment pour gérer les données en mémoire
secondaire (i.e. disques durs). En effet, dès l'origine de la discipline, les informaticiens ont
observé que la taille de la RAM ne permettait pas de charger l'ensemble d'une base de données
en mémoire. Car le volume des données ne cesse de s'accroître sous la poussée des nouvelles
technologies du WEB.
3. SGBD (Système de Gestion des Bases de Données)
Il s’agit ici du Système qui permettant de gérer une BD partagée par plusieurs utilisateurs
simultanément.
3.1 Objectifs
Des objectifs principaux ont été fixés aux SGBD dès l'origine de ceux-ci, et ce, afin de
résoudre les problèmes causés par la démarche classique. Ces objectifs sont les suivants :
 Indépendance physique : La façon dont les données sont définies doit être
indépendante des structures de stockage utilisées.
 Indépendance logique : Un même ensemble de données peut être vu différemment
par des utilisateurs différents. Toutes ces visions personnelles des données doivent
être intégrées dans une vision globale.
 Accès aux données : L’accès aux données se fait par l'intermédiaire d'un Langage
de Manipulation de Données (LMD). Il est crucial que ce langage permette d'obtenir
des réponses aux requêtes en un temps « raisonnable ». Le LMD doit donc être
optimisé, minimiser le nombre d'accès disques, et tout cela de façon totalement
transparente pour l'utilisateur.
 Administration centralisée des données (intégration) : Toutes les données
doivent être centralisées dans un réservoir unique commun à toutes les applications.
En effet, des visions différentes des données (entre autres) se résolvent plus
facilement si les données sont administrées de façon centralisée.
 Non-redondance des données : Afin d'éviter les problèmes lors des mises à jour,
chaque donnée ne doit être présente qu'une seule fois dans la base.
 Cohérence des données : Les données sont soumises à un certain nombre de
contraintes d'intégrité qui définissent un état cohérent de la base. Elles doivent
pouvoir être exprimées simplement et vérifiées automatiquement à chaque insertion,
modification ou suppression des données. Les contraintes d'intégrité sont décrites
dans le Langage de Description de Données (LDD).
 Partage des données : Il s'agit de permettre à plusieurs utilisateurs d'accéder aux
mêmes données au même moment de manière transparente. Si ce problème est
simple à résoudre quand il s'agit uniquement d'interrogations, cela ne l'est plus quand
il s'agit de modifications dans un contexte multiutilisateur, car il faut : permettre à
deux (ou plus) utilisateurs de modifier la même donnée « en même temps » et assurer
un résultat d'interrogation cohérent pour un utilisateur consultant une table pendant

qu'un autre la modifie.
 Sécurité des données : Les données doivent pouvoir être protégées contre les accès
non autorisés. Pour cela, il faut pouvoir associer à chaque utilisateur des droits
d'accès aux données.
 Résistance aux pannes : Que se passe-t-il si une panne survient au milieu d'une
modification, si certains fichiers contenant les données deviennent illisibles ? Il faut
pouvoir récupérer une base dans un état « sain ». Ainsi, après une panne intervenant
au milieu d'une modification deux solutions sont possibles : soit récupérer les
données dans l'état dans lequel elles étaient avant la modification, soit terminé
l'opération interrompue.
3.2 Quelques SGBD connus et utilisés

Il existe de nombreux systèmes de gestion de bases de données, en voici une liste non exhaustive
: PostgreSQL, MySQL, Oracle, IBM DB2, Microsoft SQL, Sybase, MS Access, Informix.
4. Types d’utilisateurs des bases de données

On distingue essentiellement 3 types d’utilisateurs à savoir :
- Administrateurs de Bases de données (DBA : Data Base Administrator) : Ils gèrent la
BD (Les accès, les droits d’utilisateurs, les sauvegardes, les restaurations,…) ;
- Concepteurs de BD et développeurs d’applications : Ils définissent, décrivent et créent
la BD ; - Utilisateurs finaux : Manipulent la BD. Il est possible de distinguer des familles
d’utilisateurs avec des droits différents vis-à-vis de l’accès à la BD. On suppose qu’ils n’ont
aucune connaissance sur les BD.
5. Les Fichiers
Un fichier est un ensemble d’information de même nature regroupé sur un même nom
ayant une extension (il faut noter ici l’extension permet d’identifier la nature du fichier)
exemple Doc pour Word 2003, docx pour Word 2007, txt pour les fichiers tests…..
6. Modèle de base de données
a. Modèle hiérarchique
Une base de données hiérarchique est une forme de système de gestion de base de
données qui lie des enregistrements dans une structure arborescente de façon à ce que chaque
enregistrement n'ait qu'un seul possesseur (par exemple, une paire de chaussures n'appartient
qu'à une seule personne).
Modèle hiérarchique.
Limites
Comme on le voit dans l'exemple cité plus haut, l'organisation hiérarchique des bases de
données est particulièrement adaptée à la modélisation de nomenclatures, mais si le principe
de relation « 1 vers N » n'est pas respecté (le canard n'appartient bien qu'à une seule famille
mais, par exemple, un malade peut avoir plusieurs médecins et un médecin a, a priori, plusieurs
patients), alors la hiérarchie doit être transformée en un réseau.
Cette évolution nécessaire donnera naissance aux bases de données relationnelles.
b. Modèle réseau
Le modèle réseau est en mesure de lever de nombreuses difficultés du modèle
hiérarchique grâce à la possibilité d'établir des liaisons de type n-n, les liens entre objets pouvant
exister sans restriction. Pour retrouver une donnée dans une telle modélisation, il faut connaître
le chemin d'accès (les liens) ce qui rend les programmes dépendants de la structure de données
Modèle réseau
c. Modèle relationnel
En informatique, une base de données relationnelle est une base de données où l'information
est organisée dans des tableaux à deux dimensions appelés des relations ou tables1, selon le
modèle introduit par Edgar F. Codd en 1970. Selon ce modèle relationnel, une base de données
consiste en une ou plusieurs relations. Les lignes de ces relations sont appelées des n-uplets ou
enregistrements. Les noms des colonnes sont appelés des attributs.
Les logiciels qui permettent de créer, utiliser et maintenir des bases de données
relationnelles sont des systèmes de gestion de base de données relationnels.
Pratiquement tous les systèmes relationnels utilisent le langage SQL pour interroger les
bases de données. Ce langage permet de demander des opérations d'algèbre Relationnelle telles
que l'intersection, la sélection, la jointure …
d. Modèle objet
La notion de bases de données objet ou relationnel-objet est plus récente et encore en phase
de recherche et de développement. Elle sera très probablement ajoutée au modèle relationnel.
Exercice 1 : Établissez le lien qui existe entre une base de données et un SGBD.
Exercice 2 : Quelles différences faites-vous entre un fichier et une base de données.
Chapitre 2
Modélisation des données
Objectif général : À la fin de ce chapitre, l’étudiant doit être capable de :
 Maîtriser les concepts de base du modèle entité association (entité, association,

attribut, etc.)
 Elaborer, à partir d’une description textuelle, un diagramme entité/association.

 concevoir une base de données à partir d’un système d’information
Les aspects importants de la réalité à représenter, ou domaines d’application, doivent

être décrits d’une manière abstraite, indépendante de toute technologie. Le modèle entité-
association est un ensemble de concepts pour modéliser les données d'une application. Il
permet de décrire un domaine d’application sous la forme d’ensembles d’entités, dotées de
propriétés et en association les unes avec les autres.
Le modèle entité/association a été proposé au milieu des années 1970 par le chercheur
Chen. Il se base sur un ensemble de symboles graphiques.
I- MERISE
MERISE (Méthode d'Étude et de Réalisation Informatique pour les Systèmes
d'Entreprise) est certainement le langage de spécification le plus répandu dans la communauté
de l'informatique des systèmes d'information, et plus particulièrement dans le domaine des
bases de données. Une représentation Merise permet de valider des choix par rapport aux
objectifs, de quantifier les solutions retenues, de mettre en œuvre des techniques d'optimisation
et enfin de guider jusqu'à l'implémentation. Reconnu comme standard, Merise devient un outil
de communication. En effet, Merise réussit le compromis difficile entre le souci d'une
modélisation précise et formelle, et la capacité d'offrir un outil et un moyen de communication
accessible aux non-informaticiens.
Un des concepts clés de la méthode Merise est la séparation des données et des traitements.
Cette méthode est donc parfaitement adaptée à la modélisation des problèmes abordés d'un
point de vue fonctionnel. Les données représentent la statique du système d'information et les
traitements sa dynamique. L'expression conceptuelle des données conduit à une modélisation
des données en entités et en associations. Dans ce cours, nous écartons volontairement la

modélisation des traitements puisque nous ne nous intéressons à la méthode Merise que dans la
perspective de la modélisation de bases de données.
Merise propose une démarche, dite par niveaux, Ces niveaux de modélisation sont
organisés dans une double approche données/traitements. Les trois niveaux de représentation
des données, puisque ce sont eux qui nous intéressent, sont détaillés ci-dessous.
Niveau conceptuel : le modèle conceptuel des données (MCD) décrit les entités du monde réel,
en termes d'objets, de propriétés et de relations, indépendamment de toute technique
d'organisation et d'implantation des données. Ce modèle se concrétise par un schéma entités-
associations représentant la structure du système d'information, du point de vue des données.
Niveau logique : le modèle logique des données (MLD) précise le modèle conceptuel par des
choix organisationnels. Il s'agit d'une transcription (également appelée dérivation) du MCD
dans un formalisme adapté à une implémentation ultérieure, au niveau physique, sous forme de
base de données relationnelle ou réseau, ou autres. Les choix techniques d'implémentation
(choix d'un SGBD) ne seront effectués qu'au niveau suivant.
Niveau physique : le modèle physique des données (MPD) permet d'établir la manière concrète
dont le système sera mis en place (SGBD retenu).
II- Concepts de base
La représentation du modèle entités-associations s’appuie sur trois concepts de base :
– l’objet ou entité,
– l’association ou relation,
– la propriété (attribut).
L’objet est une entité ayant une existence propre. L’association est un lien ou relation entre
objets sans existence propre. La propriété est la plus petite donnée d’information décrivant un
objet ou une association.
1- Entité
On appelle entité un objet concret ou abstrait ayant une existence propre présentant un
intérêt particulier pour les informations à modéliser.
Le domaine d’application est perçu comme étant constitué d’entités concrètes ou abstraites.
Ainsi, dans le contexte du commerce, on peut cerner un domaine d’application dans lequel on
repère des clients, des commandes et des produits. On considère que chacun d’eux est une
entité du domaine. On pourra donc représenter graphiquement les entités Client, Commande
et Produit comme suit :
Client Commande Produit
NumCl NumC Ref
NomCl DateC Designation
Une occurrence d’une entité est un élément individualisé appartenant à cette entité.
2- Association
Une association (ou une relation) est un lien entre deux ou plusieurs entités. Une
association est dépourvue d’existence propre.
Une association n’a d’existence qu’à travers les entités qu’elle relie. Elle peut relier deux entités
(association binaire) ou trois entités (association ternaire) ou plus (association n-aires).
On représentera une association d’une manière graphique, comme indiqué ci-dessous.
Client Commande
NumCl Passer NumC
NomCl DateC
Exemple d'association : Passer.
Propriétés d’une association :
a) Classe fonctionnelle d’une association : Cette propriété décrit le nombre maximum

d’occurrences de l’entité B pour chaque occurrence de l’entité A et inversement. On est
ainsi amené à définir trois classes fonctionnelles d’associations : un à plusieurs, un à un et

plusieurs à plusieurs.
- association de type 1:1 (ou un-à-un) si à une occurrence de l’entité E peut

correspondre par l'association A au plus une occurrence de l’entité F et que,
réciproquement à une occurrence de l’entité F ne peut correspondre au plus qu'une
occurrence de l’entité E.
- association de type 1:n (ou un-à-plusieurs) : si à une occurrence de l’entité E peut

correspondre par l'association A plusieurs occurrences de l’entité F mais à une occurrence
de l’entité au plus une occurrence de l’entité E.
- association de type n:n (ou plusieurs-à-plusieurs) : si à une occurrence de l’entité E

peuvent correspondre plusieurs occurrences de l’entité F et réciproquement.
b) Cardinalités d’une association : Chaque entité participant à une association y est

caractérisée par un couple de valeurs min- max appelé cardinalités.
c) Dimension d’une association : C’est le nombre d’entités participant à l’association. Une

association entre deux entités est appelée association binaire. Une association entre trois
entités est appelée association ternaire. Une association entre n entités est appelée
association n-aire.
d) Association réflexive : C’est une association d’une entité sur elle-même. En effet, il
est parfaitement possible d’établir une association entre une entité et elle-même,
définissant par là une association cyclique.
Exemple : pour traduire le fait que Malèk est la fille de Asma, on pourra utiliser une
association A-POUR-MERE entre les deux entités représentant ces personnes.
Personne
NumP A pour mère

NomP
AdrP
3- Attribut
Un attribut ou une propriété est une donnée élémentaire que l’on perçoit sur une entité ou
sur une association entre objets.
Chaque client est caractérisé par un numéro et un nom. On modélisera ces faits en dotant
l’entité CLIENT des attributs NumCl, NomCl.
On spécifiera le type de chaque attribut : numérique, caractère, date… ainsi que sa longueur.
Un attribut d’une association est une propriété qui dépend de toutes les entités intervenant
dans l’association. Dans ce cas, l’association est dite porteuse de données.
4- Identifiant
Un identifiant, dit parfois clé, d’une entité est constitué par un ou plusieurs de ses attributs
dont les valeurs doivent identifier de manière unique cette entité : l’identifiant d’une entité est
un attribut particulier de l’entité tel qu’à chaque valeur de la propriété corresponde une et
une seule occurrence de l’entité.
Dans le diagramme E/A, les clés sont soulignées.
Exemples d'identifiant d’entités: Le numéro d'immatriculation d'une voiture, le code à barre

d'un produit, le numéro de CIN d’une personne, le matricule pour un étudiant.
Chaque entité possède au moins un identifiant, éventuellement formé de plusieurs attributs.
Ainsi, chaque entité possède au moins un attribut qui, s'il est seul, est donc forcément
l'identifiant.
NB : Dans la représentation graphique, les attributs qui constituent l'identifiant sont
soulignés et placés en tête.
5- Cardinalité
La cardinalité d’une entité par rapport à une association s’exprime par deux nombres
appelés cardinalité minimale et cardinalité maximale. La cardinalité d'une relation est le
nombre de fois qu’une entité est en relation avec une autre.
La cardinalité minimale est le nombre de fois minimum qu’une occurrence d’une entité
participe aux occurrences de l’association.
Si la cardinalité minimale est égale à 0, c’est qu’il existe parmi toutes les occurrences de
l’entité au moins une occurrence ne participant pas aux occurrences de l’association.
La cardinalité maximale indique le nombre de fois maximum qu’une occurrence de l’entité

participe aux occurrences de la relation.
Remarques: Le minimum m peut valoir 0, 1 ou un entier strictement plus grand que 1.

Le maximum M peut valoir 1 ou une valeur n>1, n n’étant souvent pas précisé de manière
numérique, faute de connaissance suffisante.
Exemple : Reprenons l’exemple précédent et essayons de déterminer les cardinalités.
Un client passe au minimum une commande donc la cardinalité est égale à 1.N. Par contre,
une commande n’est passée que par un seul client d’où la cardinalité 1.1.
Client Commande
1.N 1.1
NumCl P asser NumC
NomCl DateC
AdrCl
6- Contrainte d’intégrité fonctionnelle CIF

Quand on détermine, entre une association et une entité, une cardinalité présentant les valeurs
0.1 ou 1.1, l’association est particulière. On l'appellera alors Contrainte d’identité
fonctionnelle (CIF) Cette association particulière n’est en général pas nommée. Elle indique
que l’une des entités est totalement déterminée par la connaissance de l’autre ; par exemple si
on connaît une commande bien précise, on connaît un client bien précis...
7- Généralisation et hiérarchie
Un ensemble d’entités E1 est un sous-ensemble de E2 si toute occurrence de E1 est aussi une
occurrence de E2. L’ensemble d’entités E1 hérite des attributs de E2.
Un ensemble d’entités E est une généralisation de E1, E2,… En si chaque occurrence de E est
aussi une occurrence d’une et une seule entité E1, E2,… En. Les ensembles E1, E2,… En sont
des spécialisations de l’ensemble d’entités E. Les ensembles d’entité E1, E2,… En héritent des
attributs de E et possèdent en outre des attributs spécifiques qui expriment leur spécialisation.
Exemple1 : l’entité EMPLOYE est une généralisation des entités INGENIEUR, PILOTE,
TECHNICIEN.
Exemple2: L’ensemble des VEHICULES est une généralisation de l’ensemble des

AUTOMOBILES et des CYCLES.
8- Diagramme Entité/Association
Après l’analyse et l’étude du cas, le concepteur est capable de tracer le modèle E/A, et ce en
représentant les entités rencontrées par des rectangles contenant les attributs et l’identifiant,
les associations qui les relient par des ellipses, en spécifiant les cardinalités.
Pour ce faire, il faut préparer le dictionnaire des données. Le dictionnaire des données est la
liste les entités et leurs attributs, en spécifiant le domaine de chacun ainsi que leur catégorie :
- données élémentaires (information stockée)
- données d’information déduite ou calculée d’utilisation fréquente (ce qui évite de refaire
le calcul plusieurs fois) ainsi que les règles de calcul
- données calculées de type situation ou historique (total HT des commandes par
mois...)
- paramètres utilisés dans des cas particuliers (TVA) ...
Et pour avoir un modèle E/A cohérent, il faut respecter des règles de validation (vérification/
normalisation)
Règle 1 : Existence d’un identifiant pour chaque entité.
Règle 2 : Toutes les propriétés d’une entité, autres que l’identifiant, doivent être en
dépendance fonctionnelle complète et directe de l’identifiant.
Règle 3 : Toutes les propriétés d’une association doivent dépendre complètement de

l’identifiant de l’association ; chaque attribut doit dépendre de tout l’identifiant et non
d’une partie de cet identifiant.
Règle 4 : Un attribut ne peut apparaître qu’une seule fois dans un même modèle E/A,
c’est ainsi qu’il ne peut qualifier qu’une seule entité ou une association.
Règle 5 : Les attributs qui sont le résultat d’un calcul ne doivent pas, en principe,
figurer dans un modèle E/A sauf s’ils sont indispensables à la compréhension de celui-ci.
Exemple de diagrammes E/A
Ce diagramme met en œuvre trois entités : étudiant, module et enseignant. Chaque entité
possède des attributs y compris un identifiant. Nous avons aussi deux associations binaires entre
les entités. L’association Inscrit est une association porteuse de données, qui contient un attribut
année-inscr dépendant des deux entités étudiant et module.
9- Application
Le propriétaire d’un garage de voitures souhaite utiliser une base de données pour traiter les
informations concernant les clients, leurs voitures et les réparations effectuées sur ces voitures.
On connaît :
• des voitures : le n° d'immatriculation, la marque, le type, l'année.
• des clients : le nom, le prénom, le n° de téléphone.
• des réparations : le n° de réparation, la date, le montant total.
Elaborer le modèle entité/association relatif à cette base de données.
Chapitre 3
Le Modèle relationnel
 Comprendre les concepts de base du modèle relationnel (domaine, relation, schéma, clé
primaire, clé étrangère...)
 Maîtriser les règles de passage du modèle E/A au modèle relationnel
 Etablir, à partir du modèle E/A, le modèle relationnel correspondant
Le modèle relationnel a été proposé par Codd au début des années 70, avec comme objectif
essentiel l’accroissement de l’indépendance des programmes vis-à-vis de la représentation des
données.
I- Concepts de base
1- Domaine
Un domaine c’est un ensemble de valeurs atomiques (indivisibles) caractérisées par un nom.
Un domaine peut être défini en extension, en donnant la liste des valeurs composantes, ou en
intention en définissant une propriété caractéristique des valeurs du domaine.
Exemple : D1= {chaîne de caractères}
D2= {lundi, mardi, mercredi, jeudi, vendredi, samedi, dimanche}
2- Attribut
Un attribut est une variable prenant ses valeurs dans un domaine.
Exemple :
Domaine (Nom)= {chaîne de caractères}
Domaine (jour)= {lundi, mardi, mercredi, jeudi, vendredi, samedi, dimanche}
3- Relation
Une relation n-aire sur les attributs A1, A2,..., An, de domaines respectifs D1, D2,..., Dn, est un
sous-ensemble du produit cartésien des domaines D1, D2,..., Dn.
Un élément appartenant à une telle relation sera appelé n-uplet ou tuple.
Il sera noté (d1,d2,….dn) où di ∈ Di, ∀ 1≤ i ≤n.
L’ensemble des n-uplets d’une relation sera appelé extension de la relation.
4- Représentation d’une relation

Chaque tuple (n-uplet) de la relation (appelée aussi Table) est écrit dans une ligne d’un tableau,
dont les noms de colonnes sont les attributs de la relation.
Chaque tuple est unique. Les duplications ne sont pas autorisées. L’ordre des tuples est
indifférent.
Exemple:
Relation Client
NumCl NomCl AdrCl

Cl1 Ali Tunis
Cl2 Mohamed Mahdia

Cl3 Salah Sousse
5- Schéma de relation /Contraintes d’intégrité

Le schéma R d´une relation r est la liste des attributs de r.
Exemple:
Le schéma de Client (voir exemple paragraphe précédent) est R = (NumCl, NomCl, AdrCl).
On pourra parfois attacher à une relation un ensemble P de propriétés que doit vérifier chacun
de ses tuples. Ces propriétés sont appelées Contraintes d’intégrité. A un schéma de relation sont
donc rattachées des contraintes d’intégrité.
Exemples :
• CLIENT (NumCl, NomCl, AdrCl, DateNaissance)
Pour ce schéma de relation, la date de naissance du client doit être inférieure à la date du jour.
• COMMANDE (NCmd, DateCmd, DateLivr)

Pour ce schéma de relation, la date de la livraison (DateLivr) doit être supérieure à la date de la
commande (DateCmd).
6- Clé d’une relation

Une des contraintes d’intégrité d’un schéma est l’unicité d’identification des n-uplets d’une
relation.
Cette identification unique est assurée par la notion de clé de relation.
Une clé peut être composée d’un seul attribut ou d’une liste d’attributs qui caractérise un tuple
(nuplet) de la relation de manière unique.
Une relation peut avoir plusieurs clés. Une clé comportant un minimum d’attributs sera choisie
comme étant clé primaire, les autres clés possibles sont appelées clés candidates. Par
convention, la clé primaire d’une relation est soulignée dans un schéma de relation.
Exemple: Client (NCl, NomCl, PrenomCl, AdrCl)
• (NCl), (NomCl, PrenomCl) sont des clés.

• (NCl) est clé primaire.
• (NomCl, PrenomCl) est une clé candidate. Par contre (NomCl) n’est pas une clé à elle
seule.
Remarque : si on choisit pour clé (NomCl, AdrCl), la modélisation ne permet pas des
homonymes habitant la même ville.
7- Clé étrangère
Une clé étrangère est un ensemble d’une ou de plusieurs colonnes d’une table qui fait
référence à une clé primaire d’une autre table. Toutes les valeurs des clés étrangères
apparaissent dans une autre relation comme valeurs d’une clé. C’est une contrainte d’intégrité
référentielle.
Par convention, la clé étrangère d’une relation est précédée (ou suivie) par le symbole # dans
un schéma de relation.
Exemple : Soient les schémas de relations suivants
Client (NumCl, NomCl, AdrCl) - Désigne l’ensemble des clients.
Commande (NCmd, DateCmd, NumCl#) - Désigne l’ensemble des commandes.
L’attribut NumCl dans la table Commande est une clé étrangère. Il prend ses valeurs dans le
domaine de valeurs de l'attribut NumCl qui se trouve, dans le schéma de relation Client. Une
commande est toujours passée par un Client existant dans la base de données.
8- Schéma de base de données relationnelle

Une base de données relationnelle est une collection de relations. L’ensemble des schémas
des relations de la collection est appelé schéma relationnel de la base.
Formellement, un schéma de base de données relationnelle B est un ensemble de schémas de

Relations R1, R2,..., Rp.
II- Passage du modèle E/A au modèle relationnel

Une fois le schéma Entité/Association est établi (comme indiqué dans le chapitre
précédent), il est nécessaire de le traduire en modèle relationnel afin de créer la base de données
sur ordinateur (sous forme de tables, relations, etc.).
Dans cette section, nous allons présenter les règles qui permettent de transformer un schéma
E/A en un modèle relationnel.
Règles de passage du modèle E/A au modèle relationnel
Règle 1
Chaque entité qui figure dans le diagramme E/A est traduite par une relation de
même nom dans laquelle es attributs traduisent les propriétés de l'entité, et la clé
primaire traduit l'identifiant de l'entité
Exemple :
Client
NumCl Client (NumCl, NomCl, AdrCl)

NomCl
AdrCl Transformation
Règle 2 :
Pour les associations de type 1 : N, l’association disparaît et l’identifiant de l’entité

côté 1 sera dupliqué dans la relation correspondante à l’entité côté N. Ce dernier sera
pris comme clé étrangère dans la relation côté N.
Exemple :
Client Commande
1.N P asser 1.1
NumCl NumC
NomCl DateC
MontantC
AdrCl
Client (NumCl, NomCl, AdrCl)

Commande (NumC, MontantC, NumCl#, DateC)
Règle 3 :
Pour les associations de type N : N, il faut créer une nouvelle relation qui contiendra :
- L’identifiant de la 1ère entité
- L’identifiant de la 2ème entité
- Les données supplémentaires La clé de cette nouvelle relation est formée par la
concaténation de deux identifiants.
Exemple: :
Client Produit
NumC (1,N ) (0,N ) NumP

Commande
Nom Cl DésignP
AdrCl Quantité PrixUnitaire
Client ( NumCl , Nom Cl , Adr Cl ) Produit ( NumP , DésignP , PrixUnitaire)
Commande (NumCl#, NumP#, Quantité)
Règle 4 : Traduction de la généralisation/spécialisation

La traduction du lien ‘est un’ peut se faire selon plusieurs règles. Dans ce qui suit, nous
considérerons une entité mère R avec n entités filles S1, S2, ….Sn.
La traduction d’un lien ‘est un’ se fait selon l’une des trois règles suivantes :
R4.1 : Représentation de l’entité mère et de ses entités filles
L’entité mère sera transformée en une nouvelle relation avec ses attributs.
Chaque entité fille Si sera transformée en une relation comportant comme clé primaire
l’identifiant de l’entité mère et comme attributs les attributs de Si.
Exemple :
EMPLOYE (Id, Nom, Prénom, Fonction)

SECRETAIRE (Id#, Vitesse-frappe)
TECHNICIEN (Id#, Grade)
INGENIEUR (Id#, Spécialité)
R4.2 Pas de représentation de l’entité mère
Chaque entité fille Si sera transformée en une relation comportant comme clé primaire
l’identifiant de l’entité mère et comme attributs les attributs de Si et les attributs de l’entité
mère. Cette règle pose un problème lorsque les sous-entités ne sont pas disjointes. Dans ce cas,
il peut y avoir duplication de certaines données. Certains problèmes d'incohérence peuvent alors
avoir lieu.
Exemple :
VOITURE (Immat, Carte_grise, Prix, Nbre_place, Vitesse_max)

CAMION (Immat, Carte_grise, Prix, Tonnage, Nbre_essieux)
R4.3 : Fusion des entités filles et de l’entité mère

L’entité mère et ses entités filles seront transformées toutes en une seule relation ayant comme
clé primaire l’identifiant de l’entité mère et comme attributs les attributs de toutes les entités
(mère et filles).
Le problème posé par cette règle est que certains attributs risquent d'avoir une valeur nulle.
Exemple :
EMPLOYE (Id, Nom, Prénom, Fonction, Vitesse-frappe, Grade, Spécialité)
Chapitre 4
La Normalisation
 Connaître la notion de dépendance fonctionnelle
 Comprendre les différentes formes normales
 Concevoir une base de données en respectant les règles et les normes.
Un schéma de relation est décrit par la liste de ses attributs et de leurs contraintes
d’intégrité éventuelles. La constitution de la liste d’attributs du schéma ne peut pas se faire
n’importe comment pour ne pas occasionner de redondance, avec toutes ses implications (perte
de place, risques d’incohérence et de perte d’informations). Les formes normales des relations
et les mécanismes pour les construire permettent d’obtenir des relations non redondantes. Ces
mécanismes sont fondés sur les notions de clés de relations et de dépendances entre données.
Ces dernières fournissent les conditions d’application d’un processus dit de normalisation qui
mène à des formes « correctes » de relations qui sont les formes normales.
Considérons la relation suivante :
PRODUIT (Refproduit, LibelleProduit, PU, Quantité, NumService, Adresse, Capacité) qui est
visiblement redondante.
RefProduit LibelleProduit PU Quantité NumService Adresse Capacité
P1 CH7 23.510 300 S1 Sousse 9000
P1 CH7 23.510 500 S2 Tunis 6000
P3 VIS12 0.150 900 S4 Sousse 2000
Cette relation présente certaines anomalies :
• Redondance : un produit apparaît autant de fois qu’il sera livré par un service
• Mise à jour : faute de redondance, les mises à jour conduiront à des risques
d’incohérence et de non intégrité.
• Insertion et suppression : l’insertion, la suppression ou le transfert d’attributs pourra

faire apparaître des valeurs nulles
On peut dire qu’une Base de Données relationnelle est ‘correcte’ ou normalisée si :
• Chaque relation décrit une information élémentaire avec les seuls attributs qui lui sont
directement liés
• Il n'y a pas de redondance d’information qui peuvent produire des problèmes de mise à
jour
I- Dépendance fonctionnelle
1- Définition
Un attribut ou une liste d’attributs Y dépend fonctionnellement d’un attribut ou d’une
liste d’attributs X dans une relation R, si étant donnée une valeur de X, il ne lui est associé
qu’une seule valeur de Y dans tout tuple de R.
On notera une telle dépendance fonctionnelle X→Y (X détermine Y ou Y dépend

fonctionnellement de X).
Exemple
PRODUIT (Refproduit, LibelleProduit, PU, Quantité, NumService, Adresse, Capacité)
Pour cette relation, les dépendances fonctionnelles suivantes sont vérifiées :
RefProduit → LibelleProduit NumService → Adresse, Capacité
RefProduit → PU RefProduit, NumService → Quantité
2- Propriétés des dépendances fonctionnelles

Des axiomes et des règles d’inférence permettent de découvrir de nouvelles
dépendances à partir d’un ensemble initial. Dans ce que suit nous considérons R une relation.
Les trois premières propriétés sont connues sous le nom « Axiomes d’Armstrong »
Propriété 1 : Réflexivité
Y⊆X ⇒ X→ Y
Tout ensemble d’attributs détermine lui-même ou une partie de lui-même.
Propriété 2 : Augmentation
X→ Y ⇒ X,Z→ Y,Z
Si X détermine Y, les deux ensembles d’attributs peuvent être enrichis par un même troisième.
Propriété 3 : Transitivité
X → Y et Y → Z ⇒ X → Z.
Propriété 4 : Union
X → Y et X → Z ⇒ X → Y, Z
Propriété 5 : Pseudo-transitivité
X → Y et W, Y → Z ⇒ W,X → Z
Propriété 6 : Décomposition
X → Y et Z ⊆ Y ⇒ X→ Z
3- Dépendance fonctionnelle élémentaire

Une Dépendance fonctionnelle X → Y est élémentaire si pour tout X’ X la
dépendance fonctionnelle X’ → Y n’est pas vraie. En d’autres termes, Y ne dépend pas
fonctionnellement d’une partie de X (X est la plus petite quantité d’information donnant Y).
Exemple : RefProduit, LibelleProduit → PU n’est pas élémentaire car il suffit d’avoir la

référence du produit pour déterminer son prix unitaire.
4- Dépendance fonctionnelle transitive

Soient X, Y deux attributs.
X→Y est une dépendance fonctionnelle transitive s’il existe un attribut Z tel que X→Z et Z→Y
5- Clé d’une relation

La clé d’une relation est l’ensemble d’attributs dont les valeurs permettent de
caractériser les n-uplets de la relation de manière unique.
Formellement :
Un attribut ou une liste d’attributs X est une clé pour la relation R(X,Y,Z) si
• Y et Z dépendent fonctionnellement de X dans R : X→ Y, Z.
• et X → Y, Z est élémentaire.
Une relation peut avoir plusieurs clés. Une clé sera choisie et désignée comme clé primaire.
Les autres seront appelées clés candidates.
Un attribut d’une relation R est appelé attribut clé s’il appartient au moins à une clé de R.
Un attribut est dit attribut non clé s’il n’appartient pas à une clé de R.
II- Les formes normales

Les formes normales ont été définies pour permettre la décomposition des relations sans
perte d’informations en utilisant la notion de dépendance fonctionnelle. Dans ce cours nous
présenterons les trois premières formes normales et celle dite de Boyce Codd.
1- Première Forme Normale (1FN)

Définition
Une relation R est en première forme normale et notée 1FN si :
- Tous les attributs ne contiennent qu’une seule valeur atomique (non divisible).
- Les attributs ne contiennent pas de valeurs répétitives.
Exemple :
Clients (NumCli, Nom, Prénom, Adresse, Téléphone)
Cette relation n’est pas en première forme normale, car Adresse n’est pas atomique. En effet
voici une représentation d’un fichier ainsi décrit :
NumCli Nom Prénom Adresse Téléphone
1 KEUMFACK Christ 2 rues évêché, BP142 6553052105

Bafoussam
2 KENGNE Nembot 2 Carrefour saints thomas , 6763115263

BP 400 Douala
3 SUGUEM Glory 2 rues Madelon, BP 120 6778805522

Bafoussam
Cette représentation si elle était mise en pratique générerait un accès aux données plus lent.
Le simple fait de vouloir extraire les habitants d’une ville précise devra mettre en œuvre des
procédures d’extraction de souschaînes sans fournir de garantie quant au résultat retourné.
Voici une représentation 1FN correcte :
Clients (NumCli, Nom, Prénom, Adresse, CodeP, Ville, Téléphone)
NumCli Nom Prénom Adresse Code Ville Téléphone

Postal
1 KEUMFACK Christ 2 rues 140 Bafoussam 6553052105

évêché
2 KENGNE Nembot 2 Carrefour 400 Douala 6763115263

saints thomas
3 SUGUEM Glory 2 rues 120 Bafoussam 6778805522

Madelon
Maintenant, récupérer les habitants d’une ville précise ne pose plus aucun problème, une simple
requête SQL y parviendra de façon rapide et fiable.
2- Deuxième Forme Normale (2FN)

Définition
Une relation R est en deuxième forme normale (2FN) si et seulement si
- Elle est en première forme normale.

- Tous les attributs non-clés ne dépendent pas d’une partie de la clé primaire.
Autrement dit, toute propriété de la relation doit dépendre intégralement de toute la clé.
Exemple :
Commande (Numcli, CodeArticle, Date, Qté commandée, Désignation)
Cette relation est-elle en première forme normale ? Oui.
Est-elle en deuxième forme normale ? Non, car la propriété Désignation ne dépend pas
intégralement de la clé (Numcli, CodeArticle, Date).
Commandes :
NumCli CodeArticle Date Qté commandée Désignation
1 Art1 28/02/2009 5 Un kilo de clou
3 Art2 28/02/2009 9 Gel
5 Art3 28/02/2009 10 pioche
6 Art41 28/02/2009 15 Bouteille d’acide
Connaissant {1,Art1,28/02/2009} pouvons-nous connaître de façon sûre et unique «Un kilo de

clou » ? La réponse est évidemment non ! «Un kilo de clou» ne dépend pas intégralement de
la clé {1,Art1,28/02/2009}.
Voici comment corriger :
Commandes (Numcli, CodeArticle, date, Qté commandée)

Articles (CodeArticle, Désignation)
NumCli CodeArticle Date Qté commandée
1 Art1 28/02/2009 5
3 Art2 28/02/2009 9
5 Art3 28/02/2009 10
6 Art41 28/02/2009 15
Articles :
CodeArticle Désignation
Art1 Un kilo de clou

Art2 Gel
Art3 pioche
Art41 Bouteille
d’acide
3- Troisième Forme Normale (3FN)

Définition
Une relation est en troisième forme normale (3FN) si et seulement si :

- Elle est en deuxième forme normale.
- Si toutes les dépendances fonctionnelles par rapport à la clé sont directes (s’il n’y a pas
de DF transitives entre les attributs non clé).
La troisième forme normale permettra d’éliminer les redondances dues aux dépendances
transitives.
Autrement dit, tous les attributs n’appartenant pas à la clé ne dépendent pas d’un attribut non-
clé. Exemple :
La relation Commande (NuméroCommande, #CodeClient, Nom client, #RefArticle) est-elle en

troisième forme normale ?
Est-elle en première forme normale ? Oui

Est-elle en deuxième forme normale ? Oui
Est-elle en troisième forme normale ? Non !
En effet Nom client dépend d’une propriété non clé : CodeClient

Commandes :
NuméroCommande CodeClient Nom client RefArticle
1 C1 Baptiste Art25
3 C5 Savary Art20
5 C2 Martinez Art10
6 C1 Baptiste Art15
Voici comment corriger :
Commande (NuméroCommande, #CodeClient, #RefArticle)

Clients (CodeClient, Nom client) Commandes :
NuméroCommande CodeClient RefArticle
1 C1 Art25
3 C5 Art20
5 C2 Art10
6 C1 Art15
Clients :
CodeClient Nom client
C1 Baptiste
C2 Martinez
C5 Savary
4- Forme Normale de Boyce-Codd (BCNF)

Une relation R est en BCNF si et seulement si les seules dépendances fonctionnelles
élémentaires qu’elle comporte sont celles dans lesquelles une clé détermine un attribut.
En d’autres termes une relation est en BCNF, si elle est en 3FN et qu’aucun attribut membre de
la clé ne dépend fonctionnellement d’un attribut non membre de la clé.
Exemple 1:
ADRESSE (Ville, Rue, CodePostal)
Cette relation présente les DFs suivantes :
Ville, Rue → CodePostal
CodePostal → Ville
Elle est en 3FN (car elle est en deuxième forme normale, et tout attribut n’appartenant pas à
une clé ne dépendra pas d’un attribut non clé).
Cette relation n’est pas en BCNF car l’attribut ‘’Ville’’ (qui fait partie de la clé) dépend
fonctionnellement de CodePostal (qui est un attribut non membre de la clé).
Exemple 2:
Si on reprend l’exemple de la section précédente :
Client (NumCl, NomCl)
Appartement (NumApp, AdrApp, Montant, NumProp#)
Propriétaire (NumProp, NomProp)
Location (NumCl#, NumApp#, DateDLoc, DateFLoc)
Dans ces relations, nous n’avons aucun attribut clé qui dépend d’un attribut non clé. Donc elles
sont en BCNF.
Conclusion
Ce chapitre a été consacré à l’étude du processus de normalisation et à la présentation
des différents types de dépendances fonctionnelles et de leurs types. Ces dépendances
fonctionnelles sont vues comme des contraintes d’intégrité. Elles servent à réduire la
redondance des données et à éviter des risques d’anomalies à travers des schémas relationnels
« corrects ».
Généralement, la démarche de la mise en place d’une base de données relationnelle est la

suivante:
• Concevoir un schéma de données exprimé à l’aide d’un modèle de représentation « plus

abstrait» que le modèle relationnel, tel que le modèle entité association
• Transformer ce schéma en un schéma relationnel
• S’assurer que chaque relation est au moins en troisième forme normale
• Normaliser les relations qui ne le seraient pas.
Dans le chapitre suivant nous allons étudier les possibilités d’interrogation et de création de
schémas relationnels normalisés à travers le langage SQL.
Chapitre 5
Le Langage SQL
 Créer la structure de la base de données et de ses tables
 Exécuter les tâches de base de la gestion des données, telle que l’insertion, la
modiﬁcation et la suppression de données des tables
 Effectuer des requêtes simples ou complexes
Il est courant en informatique de disposer de plusieurs langages pour résoudre un même

problème. Ces langages ont leur propre syntaxe, mais surtout ils peuvent s’appuyer sur des
approches de programmation très différentes. Vous avez peut-être rencontré des langages
impératifs (le C), orientés-objet (Java, Python) ou fonctionnels (Camel, Erlang). Certains
langages sont plus appropriés à certaines tâches que d’autres. Il est plus facile de vérifier les
propriétés d’un programme écrit en langage fonctionnel par exemple que d’un programme C.
Si l’on s’en tient aux bases de données (et particulièrement pour les bases relationnelles), deux
approches sont possibles : la première est déclarative et la seconde procédurale.
L’approche procédurale est assez familière : on dispose d’un ensemble d’opérations, et on

décrit le calcul à effectuer par une séquence de ces opérations. Chaque opération élémentaire
peut être très simple, mais la séquence à construire pour régler des problèmes complexes peut
être longue et peu claire.
L’approche déclarative est beaucoup plus simple conceptuellement : elle consiste à décrire
les propriétés du point d’arrivée (le résultat) en fonction de celles du point de départ (les
données de la base, dans notre cas). La description de ces propriétés se fait classiquement par
des formules logiques qui indiquent commet l’existence d’un fait f1 au départ implique
l’existence d’un fait f2 à l’arrivée.
Le langage SQL (Structured Query Langage : langage de requêtes structurées) est un

langage non procédural, conçu par IBM dans les années 70. SQL est basée sur l’algèbre
relationnelle (opérations ensemblistes et relationnelles). Normalisé dès 1986, SQL constitue le
standard aux bases de données relationnelles. Ce langage permet l’accès aux données et se
compose de quatre sous-ensembles :
• Le Langage de Définition de Données : LDD (Data Définition Language DDL) : Ce

langage permet la définition et la mise à jour de la structure de la base de données
(tables, attributs, vues, index, ...).
• Le Langage d’Interrogation de Données : LID : Ce langage permet de rechercher des

informations utiles en interrogeant la base de données. Certains considèrent ce langage
comme étant une partie du LMD.
• Le Langage de Manipulation de Données : LMD (Data Manipulation Language DML)

: Ce langage permet de manipuler les données de la base et de les mettre à jour.
• Le Langage de Contrôle de Données : LCD (Data Control Language DCL) : Ce langage

permet de définir les droits d’accès pour les différents utilisateurs de la base de données,
donc il permet de gérer la sécurité de la base et de confirmer et d’annuler les
transactions.
I- Principales Instructions
- Définitions (LDD)
CREATE, DROP, ALTER
- Mises à jour (LMD)
INSERT, UPDATE, DELETE
- INTERROGATIONS (LMD)
SELECT
- Contrôle d’accès aux données
GRANT, REVOKE
- Gestion de transactions
COMMIT, ROLLBACK
II- Le Langage de Définition des Données : LDD

SQL permet de définir des schémas de bases de données composées de tables et de vues.
1- Création d’une table

SQL permet de créer des relations sous forme de tables et de définir lors de la création des
contraintes d’intégrité variées sur les attributs. Une commande de création permet donc de
préciser le nom de la table et de définir les éléments de la table correspondant aux colonnes
ou aux contraintes.
Syntaxe :
CREATE TABLE<nom de la table> (nom_colonne_1 type_colonne_1,

nom_colonne_2type_colonne_2,...,
nom_colonne_ntype_colonne_n) ;
Exemple :
• AGENCE (NumAg, NomAg, VilleAg)

CREATE TABLE Agence (NumAg number(4) PRIMARY KEY, NomAg varchar(10),
VilleAg varchar(20));
• CLIENT (NumCl, NomCl, VilleCl)

CREATE TABLE Client (NumCl number (8) PRIMARY KEY, NomCl varchar (20),
VilleCl varchar(20));
• COMPTE (NumC, NumAg#, NumCl#, Solde)

CREATE TABLECompte (NumC number (20), NumAg number (4), NumCl number (8),
solde number (10), PRIMARY KEY (NumC, NumAg, NumCl), CONSTRAINT fk-ag
FOREIGN KEY (NumAg) REFERENCES Agence, CONSTRAINT
FOREIGN KEY (NumCl) REFERENCES Client) ;
A savoir :
• NOT NULL : empêche d’enregistrer une valeur nulle pour une colonne.
• DEFAULT : attribuer une valeur par défaut si aucune donnée 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.
• FOREIGN KEY : indique si cette colonne est considérée comme une clé
étrangère.
• UNIQUE : les valeurs de la colonne doivent être unique ou NULL, c'est

à dire qu'à l'exception du marqueur NULL, il ne doit jamais y avoir plus
d'une fois la même valeur (pas de doublon)
• CHECK : permet de préciser un prédicat qui acceptera la valeur s'il est
évalué à vrai
2- Création d’une vue
Une vue est une table calculée (crée) à partir des tables de base grâce à une requête.
Exemple :
CREATE VIEW Agence1 AS SELECT NumAg, villeAg FROM Agence ;

Pour la supprimer :
DROP VIEW nom-
vue ;
3- Création d’index
La création d’un index permet d’accélérer les recherches d’informations dans la base. La
ligne est retrouvée instantanément si la recherche peut utiliser un index, sinon la recherche se
fait séquentiellement. Une autre utilité de la création d’index est de garantir l’unicité de la clé
en utilisant l’option UNIQUE.
Syntaxe :
CREATE [UNIQUE] INDEX nom_index

ON nom_table (Attr1[ASC/DESC], Attr2[ASC/DESC], …);
• L'option UNIQUE permet de définir la présence ou non de doublons pour les valeurs de
l’attribut.
• Les options ASC/DESC permettent de définir un ordre de classement des valeurs

présentes dans l’attribut.
4- Modification d’une table

La définition d’une table ou d’autres éléments du schéma dotés d’un nom peut être modifiée à
l’aide de la commande ALTER.
a. Ajouter une ou plusieurs colonnes
Syntaxe :
ALTER TABLE<nom_de_la_table>ADD (nom_colonne1 type_colonne1,

nom_colonne2.type_colonne2,…,
nom_colonne n type_colonne n) ;
Exemple
ALTER TABLE Agence ADD (actif number (10)) ;
b. Modifier le type ou une autre propriété d’une colonne :

Syntaxe
ALTER TABLE nom_table
MODIFY (nom_colonne nouveau_type et/ou nouvelle_propriété) ;
Exemple
ALTER TABLE Agence MODIFY (NomAg varchar(20));
5- Renommer une table

Syntaxe
RENAME nom_table TO nouveau_nom_table ;

Exemple
RENAME Professeur TO Enseignant ;
6- Suppression d’une table

Syntaxe
DROP nom_table ;
III- Le langage d’interrogation de données : LID
1- Syntaxe générale
La recherche d’information dans une base de données s’effectue à l’aide de la commande
SQL SELECT.
Dans ce cours, nous présenterons une syntaxe simplifiée de l’instruction SELECT ainsi
que d’autres.
SQL SELECT
L’utilisation la plus courante de SQL consiste à lire des données issues de la base de données.
Cela s’effectue grâce à la commande SELECT, qui retourne des enregistrements dans un tableau de
résultat. Cette commande peut sélectionner une ou plusieurs colonnes d’une table.
Commande basique
L’utilisation basique de cette commande s’effectue de la manière suivante :
SELECT nom_du_champ
FROM nom_du_tableau
Cette requête va sélectionner (SELECT) le champ « nom_du_champ » provenant (FROM) du tableau

appelé « nom_du_tableau ».
Exemple
Imaginons une base de données appelée « client » qui contient des informations sur les clients d’une
entreprise.
Table « client » :
identifiant prénoms nom ville
1 Pierre Kamdem Kribi
2 Sabrina Eloa Douala
3 Julien Martin Yaoundé
4 David Bekono Baham
5 Marie Lenoc Edea
Si l’on veut avoir la liste de toutes les villes des clients, il suffit d’effectuer la requête suivante
:
SELECT ville
FROM client
Résultat :
ville
Kribi
Douala
Yaoundé
Baham
Edéa
Obtenir plusieurs colonnes

Avec la même table client il est possible de lire plusieurs colonnes à la fois. Il suffit tout simplement de
séparer les noms des champs souhaités par une virgule. Pour obtenir les prénoms et les noms des clients
il faut alors faire la requête suivante :
SELECT prénom, nom
FROM client
Résultat :
prénom nom
Pierre Kamdem
Sabrina Eloa
Julien Martin
David Bekono
Marie Lenoc
Obtenir toutes les colonnes d’un tableau

Il est possible de retourner automatiquement toutes les colonnes d’un tableau sans avoir à
connaître le nom de toutes les colonnes. Au lieu de lister toutes les colonnes, il faut simplement utiliser
le caractère « * » (étoile). C’est un joker qui permet de sélectionner toutes les colonnes. Il s’utilise de la
manière suivante :
SELECT * FROM client
Cette requête retourne exactement les mêmes colonnes qu’il y a dans la base de données. Dans notre
cas, le résultat sera donc :
identifiant prénom nom ville
1 Pierre Kamdem Kribi
2 Sabrina Eloa Douala
3 Julien Martin Yaoundé
4 David Bekono Baham
5 Marie Lenoc Edéa
NB : Il y a des avantages et des inconvénients à l’utiliser. Pour en savoir plus sur le sujet il est
recommandé de lire l’article avantage et inconvénient du sélecteur étoile.
Ordre des commandes du SELECT

Cette commande SQL est relativement commune car il est très fréquent de devoir lire les
données issues d’une base de données. Il existe plusieurs commandes qui permettent de mieux gérer les
données que l’on souhaite lire.
Un requête SELECT peut devenir assez longue. Juste à titre informatif, voici une requête
SELECT qui possède presque toutes les commandes possibles :
SELECT *
FROM table
WHERE condition
GROUP BY expression
HAVING condition
{UNION | INTERSECT | EXCEPT}
ORDER BY expression
LIMIT count
OFFSET start
A noter : cette requête imaginaire sert principale d’aide-mémoire pour savoir dans quel ordre sont utilisé
chacun des commandes au sein d’une requête SELECT.
SQL 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.
Commande basique
L’utilisation basique de cette commande consiste alors à effectuer la requête suivante :
SELECT DISTINCT ma_colonne
FROM nom_du_tableau
Cette requête sélectionne le champ « ma_colonne » de la table « nom_du_tableau » en évitant de

retourner des doublons.
Requête pour Oracle

Pour le Système de Gestion de Bases de Données (SGBD) Oracle, cette requête est remplacée par
la commande « UNIQUE » :
SELECT UNIQUE ma_colonne
FROM nom_du_tableau
Exemple
Prenons le cas concret d’une table « client » qui contient des noms et prénoms :
identifiant prénom nom
1 Pierre Kamdem
2 Sabrina Eloa
3 David Durand
4 Pierre Lenoc
5 Marie Lenoc
En utilisant seulement SELECT tous les noms sont retournés, or la table contient plusieurs fois le
même prénom (cf. Pierre). Pour sélectionner uniquement les prénoms uniques il faut utiliser la
requête suivante :
SELECT DISTINCT prénom
FROM client
Résultat :
prénom
Pierre
Sabrina
David
Marie
Ce résultat affiche volontairement qu’une seule fois le prénom « Pierre » grâce à l’utilisation de la
commande DISTINCT qui n’affiche que les résultats distincts.
Intérêt
L’utilisation de la commande DISTINCT est très pratique pour éviter les résultats en doubles.
Cependant, pour optimiser les performances il est préférable d’utiliser la commande SQL GROUP BY
lorsque c’est possible.
SQL 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
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 id nom nbr_commande ville obtenir seulement la liste des clients

qui 1 Paul 3 paris habitent à Paris, il faut effectuer la
2 Maurice 0 rennes requête suivante :
3 Joséphine 1 toulouse
SELECT *
4 Gérard 7 paris
FROM client
WHERE ville = 'paris'
Résultat :
Attention : dans notre cas tout est en minuscule donc il n’y a pas eu de problème. Cependant,
si id nom nbr_commande nbr_commande une table est sensible à la casse, il
faut faire attention aux majuscules
1 Paul 3 paris
et minuscules.
4 Gérard 7 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 utilisés.
Opérateur Description
= Égale
<> Pas égale
!= Pas égale
> Supérieur à
< Inférieur à
>= Supérieur ou égale à
<= Inférieur ou égale à
IN Liste de plusieurs valeurs possibles
BETWEEN Valeur comprise dans un intervalle donnée (utile pour les nombres ou dates)
LIKE Recherche en spécifiant le début, milieu ou fin d'un mot.
IS NULL Valeur est nulle
IS NOT NULL Valeur n'est pas nulle
Attention : il y a quelques opérateurs qui n’existe pas dans des vieilles versions de système de
gestion de bases de données (SGBD). De plus, il y a de nouveaux opérateurs non indiqués ici
qui sont disponibles avec certains SGBD. N’hésitez pas à consulter la documentation de
MySQL, PostgreSQL ou autre pour voir ce qu’il vous est possible de faire.
SQL 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 chaînes 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.
Exemple : filtrer entre 2 dates
Imaginons une table « utilisateur » qui contient les membres d’une application en ligne.
id nom date_inscription
1 Maurice 2012-03-02
2 Simon 2012-03-05
3 Chloé 2012-04-14
4 Marie 2012-04-15
5 Clémentine 2012-04-26
Si l’on souhaite obtenir les membres qui se sont inscrit entre le 1 avril 2012 et le 20 avril 2012
il est possible d’effectuer la requête suivante :
SELECT *
FROM utilisateur
WHERE date_inscription BETWEEN ’2012-04-01′ AND ’2012-04-20′
Résultat :
3 Chloé 2012-04-14
4 Marie 2012-04-15
Exemple : filtrer entre 2 entiers

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
Résultat :
1 Maurice 2012-03-02 Bon à savoir
2 Simon 2012-03-05 Certaines vieilles versions de systèmes de gestion de bases
3 Chloé 2012-04-14 de données ne prennent pas en compte la commande

BETWEEN. Mais si vous utilisez une version récente de
MySQL ou PostgreSQL, cela ne cause aucun problème.
L’autre élément important à savoir c’est que toutes les bases de données ne gèrent pas
l’opérateur BETWEEN de la même manière. Certains systèmes vont inclurent les valeurs qui
définissent l’intervalle tandis que d’autres systèmes considèrent ces valeurs sont exclues. Il est
important de consulter la documentation officielle de la base de données que vous utilisez pour
avoir une réponse exacte à ce sujet.
SQL GROUP BY
La commande GROUP BY est utilisée en SQL pour grouper plusieurs résultats et
utiliser une fonction de totaux sur un groupe de résultat. Sur une table qui contient toutes les
ventes d’un magasin, il est par exemple possible de lister, regrouper les ventes par clients
identiques et d’obtenir le coût total des achats pour chaque client.
Syntaxe d’utilisation de GROUP BY
De façon générale, la commande GROUP BY s’utilise de la façon suivante :
SELECT colonne1, fonction(colonne2)
FROM table
GROUP BY colonne1
A noter : cette commande doit toujours s’utiliser après la commande WHERE et avant la
commande HAVING.
Exemple d’utilisation
Prenons en considération une table « achat » qui résume les ventes d’une boutique :
id client tarif date
1 Pierre 102 2012-10-23
2 Simon 47 2012-10-27
3 Marie 18 2012-11-05
4 Marie 20 2012-11-14
Ce tableau contient une colonne qui sert d’identifiant
5 Pierre 160 2012-12-03
pour chaque ligne, une autre qui contient le nom du
client, le coût de la vente et la date d’achat.
Pour obtenir le coût total de chaque client en regroupant les commandes des mêmes clients, il
faut utiliser la requête suivante :
SELECT client, SUM(tarif)
FROM achat
GROUP BY client
La fonction SUM () permet d’additionner la valeur de chaque tarif pour un même client. Le
résultat sera donc le suivant :
client SUM(tarif)
Pierre 262
Simon 47
Marie 38
La manière simple de comprendre le GROUP BY c’est tout simplement d’assimiler qu’il va

éviter de présenter plusieurs fois les mêmes lignes. C’est une méthode pour éviter les doublons.
Juste à titre informatif, voici ce qu’on obtient de la requête sans utiliser GROUP BY.
Requête :
FROM achat
Résultat :
client SUM(tarif)
Pierre 262
Simon 47
Marie 38
Marie 38
Pierre 262
Utilisation d’autres fonctions de statistiques

Il existe plusieurs fonctions qui peuvent être utilisées pour manipuler plusieurs enregistrements,
il s’agit des fonctions d’agrégations statistiques, les principales sont les suivantes :
• AVG() pour calculer la moyenne d’un set de valeur. Permet de connaître le prix du
panier moyen pour de chaque client
• COUNT() pour compter le nombre de lignes concernées. Permet de savoir combien
d’achats a été effectué par chaque client
• MAX() pour récupérer la plus haute valeur. Pratique pour savoir l’achat le plus cher
• MIN() pour récupérer la plus petite valeur. Utile par exemple pour connaître la date du
premier achat d’un client
• SUM() pour calculer la somme de plusieurs lignes. Permet par exemple de connaître le
total de tous les achats d’un client
Ces petites fonctions se révèlent rapidement indispensable pour travailler sur des données.
SQL HAVING
La condition HAVING en SQL est presque similaire à WHERE à la seule différence
que HAVING permet de filtrer en utilisant des fonctions telles que SUM(), COUNT(), AVG(),
MIN() ou MAX().
Syntaxe
HAVING s’utilise de la manière suivante :
SELECT colonne1, SUM(colonne2)
FROM nom_table
GROUP BY colonne1
HAVING fonction(colonne2) operateur valeur
Cela permet donc de SÉLECTIONNER les colonnes DE la table « nom_table » en

GROUPANT les lignes qui ont des valeurs identiques sur la colonne « colonne1″ et que la
condition de HAVING soit respectée.
Important : HAVING est très souvent utilisé en même temps que GROUP BY bien que ce ne
soit pas obligatoire.
Exemple
Pour utiliser un exemple concret, imaginons une table « achat » qui contient les achats de
différents clients avec le coût du panier pour chaque achat.
id client tarif date_achat

1 Pierre 102 2012-10-23
2 Simon 47 2012-10-27
3 Marie 18 2012-11-05
4 Marie 20 2012-11-14
5 Pierre 160 2012-12-03
Si dans cette table on souhaite récupérer la liste des clients qui ont commandé plus de 40f, toute
commandes confondu alors il est possible d’utiliser la requête suivante :
FROM achat
GROUP BY client
HAVING SUM(tarif) > 40
Résultat :
client SUM(tarif)
Pierre 262
Simon 47
La cliente « Marie » a cumulée 38f d’achat (un achat de 18f et un autre de 20f) ce qui est
inférieur à la limite de 40f imposée par HAVING. En conséquent cette ligne n’est pas affichée
dans le résultat.
SQL ORDER BY
La commande ORDER BY permet de trier les lignes dans un résultat d’une requête SQL. Il est
possible de trier les données sur une ou plusieurs colonnes, par ordre ascendant ou descendant.
Syntaxe
Une requête où l’on souhaite filtrer l’ordre des résultats utilise la commande ORDER BY de la
sorte :
SELECT colonne1, colonne2
FROM table
ORDER BY colonne1
Par défaut les résultats sont classés par ordre ascendant, toutefois il est possible d’inverser
l’ordre en utilisant le suffixe DESC après le nom de la colonne. Par ailleurs, il est possible de
trier sur plusieurs colonnes en les séparant par une virgule. Une requête plus élaboré
ressemblerais alors cela :
SELECT colonne1, colonne2, colonne3
FROM table
ORDER BY colonne1 DESC, colonne2 ASC
A noter : il n’est pas obligé d’utiliser le suffixe « ASC » sachant que les résultats sont toujours
classés par ordre ascendant par défaut. Toutefois, c’est plus pratique pour mieux s’y retrouver,
surtout si on a oublié l’ordre par défaut.
Exemple
Pour l’ensemble de nos exemples, nous allons prendre un base « utilisateur » de test, qui
contient les données suivantes :
id nom prenom date_inscription tarif_total

Pour 4 Dubois Chloé 2012-02-16 98 récupérer la liste de ces
utilisateurs par ordre alphabétique
5 Dubois Simon 2012-02-23 27
du nom de famille, il est possible
2 Dupond Fabrice 2012-02-07 65
d’utiliser la requête suivante :
1 Durand Maurice 2012-02-05 145
3 Durand Fabienne 2012-02-13 90 SELECT *
FROM utilisateur
ORDER BY nom
Résultat :

3 Durand Fabienne 2012-02-13 90
En utilisant deux
4 Dubois Chloé 2012-02-16 98 méthodes de tri, il
est 5 Dubois Simon 2012-02-23 27 possible de
retourner les utilisateurs par ordre alphabétique ET pour ceux qui ont le même nom de famille,
les trier par ordre décroissant d’inscription. La requête serait alors la suivante :
SELECT *
FROM utilisateur
ORDER BY nom, date_inscription DESC
Résultat :

5 Dubois Simon 2012-02-23 27
4 Dubois Chloé 2012-02-16 98
3 Durand Fabienne 2012-02-13 90

Base de Données

Transféré par

Informations du document

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

Base de Données

Transféré par

Droits d'auteur :

Formats disponibles

Support de cours : BASE DE DONNEES ET SQL

Spécialités : TRONC COMMUN (GL 1, GSI 1)

Master 2 en Management des Systèmes d’Information et d’Infrastructure (MS2I)

L’objectif du cours de base de données est de permettre à l’étudiant de comprendre le

1. Qu'est-ce qu'une base de données ?

3. SGBD (Système de Gestion des Bases de Données)

un résultat d'interrogation cohérent pour un utilisateur consultant une table pendant

3.2 Quelques SGBD connus et utilisés

4. Types d’utilisateurs des bases de données

6. Modèle de base de données

Cette évolution nécessaire donnera naissance aux bases de données relationnelles.

Objectif général : À la fin de ce chapitre, l’étudiant doit être capable de :

 Maîtriser les concepts de base du modèle entité association (entité, association,

 Elaborer, à partir d’une description textuelle, un diagramme entité/association.

Les aspects importants de la réalité à représenter, ou domaines d’application, doivent

des données en entités et en associations. Dans ce cours, nous écartons volontairement la

II- Concepts de base

La représentation du modèle entités-associations s’appuie sur trois concepts de base :

Client Commande Produit

NumCl NumC Ref

NomCl DateC Designation

On représentera une association d’une manière graphique, comme indiqué ci-dessous.

NumCl Passer NumC

Exemple d'association : Passer.

Propriétés d’une association :

a) Classe fonctionnelle d’une association : Cette propriété décrit le nombre maximum

ainsi amené à définir trois classes fonctionnelles d’associations : un à plusieurs, un à un et

- association de type 1:1 (ou un-à-un) si à une occurrence de l’entité E peut

- association de type 1:n (ou un-à-plusieurs) : si à une occurrence de l’entité E peut

- association de type n:n (ou plusieurs-à-plusieurs) : si à une occurrence de l’entité E

b) Cardinalités d’une association : Chaque entité participant à une association y est

c) Dimension d’une association : C’est le nombre d’entités participant à l’association. Une

NumP A pour mère

Dans le diagramme E/A, les clés sont soulignées.

Exemples d'identifiant d’entités: Le numéro d'immatriculation d'une voiture, le code à barre

La cardinalité maximale indique le nombre de fois maximum qu’une occurrence de l’entité

Remarques: Le minimum m peut valoir 0, 1 ou un entier strictement plus grand que 1.

Exemple : Reprenons l’exemple précédent et essayons de déterminer les cardinalités.

6- Contrainte d’intégrité fonctionnelle CIF

Exemple2: L’ensemble des VEHICULES est une généralisation de l’ensemble des

Règle 1 : Existence d’un identifiant pour chaque entité.

Règle 3 : Toutes les propriétés d’une association doivent dépendre complètement de

Exemple de diagrammes E/A

• des voitures : le n° d'immatriculation, la marque, le type, l'année.

• des clients : le nom, le prénom, le n° de téléphone.

• des réparations : le n° de réparation, la date, le montant total.

Elaborer le modèle entité/association relatif à cette base de données.

Objectif général : À la fin de ce chapitre, l’étudiant doit être capable de :

 Maîtriser les règles de passage du modèle E/A au modèle relationnel

 Etablir, à partir du modèle E/A, le modèle relationnel correspondant

Un élément appartenant à une telle relation sera appelé n-uplet ou tuple.

Il sera noté (d1,d2,….dn) où di ∈ Di, ∀ 1≤ i ≤n.

L’ensemble des n-uplets d’une relation sera appelé extension de la relation.

4- Représentation d’une relation

NumCl NomCl AdrCl

Cl2 Mohamed Mahdia

5- Schéma de relation /Contraintes d’intégrité

• COMMANDE (NCmd, DateCmd, DateLivr)

6- Clé d’une relation

Cette identification unique est assurée par la notion de clé de relation.

Exemple: Client (NCl, NomCl, PrenomCl, AdrCl)

• (NCl), (NomCl, PrenomCl) sont des clés.

Exemple : Soient les schémas de relations suivants