Module : I144 Parcours : MIP

Bases de donn

Polycopi cours

Mohammed Khalil

Annniversitaire : 2018 - 2019

 2

Table des matières

1 Généralités 5
1.1 Dénition d'une base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Modèles des bases de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Modèle hiérarchique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Modèle réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Modèle relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.4 Modèle objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Système de gestion de base de données (SGBD) . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Fichiers informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Fonctionnalités du SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Démarche de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Conception des bases de données 10

2.1 Éléments constitutifs du modèle entités-associations . . . . . . . . . . . . . . . . . . . 10
2.1.1 Entité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Identiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.5 Cardinalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Types d'associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
TABLE DES MATIÈRES 3

2.2.1 Association plurielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 Association réexive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3 Association n-aire (n > 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Évolution du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Modèle relationnel 22
3.1 Passage du modèle entités-associations au modèle relationnel . . . . . . . . . . . . . . 22
3.1.1 Représentation des entités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2 Représentation des associations . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2.1 Associations un-à-plusieurs . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2.2 Associations un-à-un . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2.3 Associations plusieurs-à-plusieurs . . . . . . . . . . . . . . . . . . . . . 24
3.1.2.4 Associations réexives . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Dépendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Graphe DF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3 Formes normales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.3.1 Première forme normale . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.3.2 Deuxième forme normale . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3.3 Troisième forme normale . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Le langage SQL 33
4.1 Langage de dénition de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Création d'une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Contraintes d'intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.3 Suppression d'une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.4 Modication une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Langage de manipulation de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
TABLE DES MATIÈRES 4

4.2.1 Insertion des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.2 Modication des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 Suppression des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Langage d'interrogation de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.1 Sélection dans une seule table (Requêtes simples) . . . . . . . . . . . . . . . . . 38
4.3.2 Requêtes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.3 Fonctions SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.4 Sélection utilisant plusieurs tables (Sous requêtes) . . . . . . . . . . . . . . . . 43
4.3.5 Extraction de données de plusieurs tables (Jointures) . . . . . . . . . . . . . . . 46
4.3.6 Extraction de données groupées (Regroupements) . . . . . . . . . . . . . . . . . 49
 5

Chapitre 1

Généralités
Au cours des dernières années, les bases de données ont connu un développement considérable, qui
jouent actuellement un rôle important dans chacune de nos opérations quotidiennes ; du simple achat
par carte bancaire jusqu'à nos déclarations de revenus. L'objectif de ce chapitre est de dénir la notion
de base de données ainsi que les principaux concepts qui s'y rattachent.

1.1 Dénition d'une base de données

Les bases de données reposent sur des théories solides et sont à l'origine d'une des plus importantes
disciplines de l'informatique : l'ingénierie des systèmes d'information. En eet, elles sont actuellement
au coeur du système d'information des entreprises.
Peu importe le support utilisé pour rassembler et stocker les données (papier, chiers, etc.), dès
lors que des données sont rassemblées et stockées d'une manière organisée dans un but spécique, on
parle de base de données. Ainsi, on dénit une base de données informatisée 1 comme un ensemble
de données
• structurées,
• organisées pour répondre rapidement à des questions précises,
• enregistrées sur des supports informatiques
La création d'une base de données a un but précis : elle doit permettre de retrouver de l'information
par son contenu en se fondant sur des critères de recherche. Ainsi, la qualité d'une base de données est
évaluée par deux critères :
• La cohérence de données.
• L'absence de redondances.
La gestion et l'accès à une base de données sont assurés par un ensemble de programmes qui
constituent le Système de Gestion de Base de Données (SGBD).
1. Par abus de langage, on utilisera le mot base de données au lieu de base de données informatisée.
1.2. Modèles des bases de données 6

La grande diérence avec un programme écrit dans un langage de programmation est qu'une base
de données doit pouvoir répondre à des questions pour lesquelles elle n'a pas forcément été prévue à
la conception.
Enn, il ne faut pas confondre les bases de données avec les systèmes d'information qui sont
composés par les bases de données, le SGBD utilisé et les programmes associés.

1.2 Modèles des bases de données

Les modèles de données correspondent à la manière de structurer l'information dans une base de
données. Ils reposent sur les principes et les théories issus du domaine de la recherche en informatique
et permettent de traduire la réalité de l'information vers une représentation utilisable en informatique.

1.2.1 Modèle hiérarchique

Le modèle hiérarchique propose une classication arborescente des données de façon à ce que
chaque enregistrement n'ait qu'un seul possesseur ; par exemple, une commande n'a qu'un seul client.
Cependant, à cause de ce type de limitations, ce modèle ne peut pas traduire toutes les réalités de
l'information dans les organisations.

1.2.2 Modèle réseau

Le modèle réseau est en mesure de lever de nombreuses dicultés du modèle hiérarchique grâce à
la possibilité d'établir plusieurs liaisons entre elles. Elle est basée sur une structuration de graphes.
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.

1.2.3 Modèle relationnel

Le père des bases de données relationnelles est Edgar Frank Codd. Chercheur chez IBM à la n
des année 1960, il étudiait alors de nouvelles méthodes pour gérer de grandes quantités de données car
les modèles et les logiciels de l'époque ne le satisfaisait pas. Il proposait le modèle relationnel qui permet
d'organiser des données sous forme de tables et de relations et les exploiter à l'aide d'un langage de
requêtes (ex : SQL 2 ). C'est dans ce type de modèle que se situe ce cours de base de données.
2. Structured Query Langage.
1.3. Système de gestion de base de données (SGBD) 7

1.2.4 Modèle objet

Après le développement des langages orientés objet (C++, Java...) dans les années 1980, le concept
objet a été adapté aux bases de données. Le modèle objet permet d'organiser les données sous forme
d'instances de classes hiérarchisées qui possèdent leur propres méthodes d'exploitation.

1.3 Système de gestion de base de données (SGBD)

La gestion et l'accès à une base de données sont assurés par un ensemble de programmes qui
constituent le système de gestion de base de données (SGBD). Un SGBD doit permettre l'ajout, la
modication et la recherche de données. Il héberge généralement plusieurs bases de données, qui sont
destinées à des logiciels ou des thématiques diérents.
La plupart des SGBD fonctionnent selon un mode client/serveur. Le serveur (la machine qui stocke
les données) reçoit des requêtes de plusieurs clients et ceci de manière concurrente. Le serveur analyse
la requête, la traite et retourne le résultat au client.

1.3.1 Fichiers informatiques

Lorsqu'on utilise un chier pour stocker de l'information, il est nécessaire de prévoir un découpage
de celui-ci par enregistrements, souvent de taille xe.
Dans le cas d'un accès séquentiel, la recherche d'un enregistrement en position k nécessite d'accéder
aux k − 1 enregistrements qui le précèdent.
Une alternative au parcours séquentiel est de construire des tables descriptives an d'accélérer
l'accès aux données. Une première table permet l'accès direct à un enregistrement par une clé associée
à l'adresse (pointeur) de l'enregistrement. Une seconde table contient l'ordre relatif des enregistrements
ordonnés suivant les valeurs d'un champ : on appelle cette table un index.
On constate que la simple recherche d'informations recourt déjà à des algorithmes assez sophisti-
qués et nécessite la construction et le maintien de structures annexes pour être ecace. De même, la
destruction d'enregistrements et l'évolution de la structure de la base sont également des opérations
lourdes à mettre en oeuvre ; elles requièrent souvent la recopie complète des informations dans un
nouveau chier.

1.3.2 Fonctionnalités du SGBD

Des objectifs principaux ont été xés aux SGBD an de résoudre les problèmes causés par la
démarche classique. Ces objectifs sont les suivants :
1.4. Démarche de conception 8

• Indépendance physique : La façon dont les données sont dénies doit être indépendante des
structures de stockage utilisées.
• Indépendance logique : Un même ensemble de données peut être vu diéremment par des
utilisateurs dié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 Mani-
pulation 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 manière 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 eet, des visions
diérentes des données se résolvent plus facilement si les données sont administrées de façon
centralisée.
• Non redondance des données : An 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énissent un état cohérent de la base. Elles doivent pouvoir être exprimées
simplement et vériées automatiquement à chaque insertion, modication ou suppression des
données.
• 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.
• Sécurité des données : Les données doivent pouvoir être protégées contre les accès non auto-
risé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 modication,
si certains chiers 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 modication deux
solutions sont possibles : soit récupérer les données dans l'état dans lequel elles étaient avant la
modication, soit terminer l'opération interrompue.

1.4 Démarche de conception

MERISE (Méthode d'Étude et de Réalisation Informatique pour les Systèmes d'Entreprise) est
certainement le langage de spécication 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 quantier les solutions
retenues, de mettre en oeuvre des techniques d'optimisation et enn de guider jusqu'à l'implémenta-
tion. Reconnu comme standard, Merise devient un outil de communication. En eet, Merise réussit le
compromis dicile entre le souci d'une modélisation précise et formelle, et la capacité d'orir un outil
et un moyen de communication accessible aux non-informaticiens.
Merise propose une démarche, dite par niveaux, dans laquelle il s'agit de hiérarchiser les préoc-
1.4. Démarche de conception 9

cupations de modélisation qui sont de trois ordres : la conception, l'organisation et la technique.

En eet, pour aborder la modélisation d'un système, il convient de l'analyser en premier lieu de fa-
çon globale et de se concentrer sur sa fonction : c'est-à-dire de s'interroger sur ce qu'il fait avant de
dénir comment il le fait. Ces niveaux de modélisation sont organisés dans une double approche don-
nées/traitements 3 . Les trois niveaux de représentation des données qui nous intéressent sont détaillés
ci-dessous.
 Niveau conceptuel : le modèle conceptuel de données (MCD) décrit les entités du monde réel,
en terme d'objets, de propriétés et de relations, indépendamment de toute technique d'organisa-
tion 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 de données (MLD) dérive 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 des techniques d'implémentation 4 ne seront eectuées
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).

3. L'approche de traitements ne rentre pas dans le but de ce cours.

4. choix du SGBD
 10

Chapitre 2

Conception des bases de données

Le modèle conceptuel de données (MCD) appelé aussi modèle entités-associations permet une
description naturelle du monde réel à partir des concepts d'entité et d'association. Basé sur la théorie
des ensembles et des relations, ce modèle répond à l'objectif d'indépendance données-programmes. Ce
modèle, utilisé dans la phase de conception, s'inscrit dans le cadre d'une méthode plus générale et très
répandue : MERISE 1 .

2.1 Éléments constitutifs du modèle entités-associations

La représentation du modèle entités-associations s'appuie sur trois concepts de base :
• L'objet ou l'entité,
• L'association,
• La propriété ou l'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.

2.1.1 Entité
Le MCD permet de décrire les structures d'un domaine d'application. Le domaine d'application,
pourrait être une bibliothèque, un service hospitalier, le département de marketing d'une entreprise.
Le domaine d'application est perçu comme étant constitué d'entités concrètes ou abstraites. Ainsi,
dans le contexte de l'assurance automobile, on peut cerner un domaine d'application dans lequel on
repère des clients, des véhicules, des contrats et des accidents. On considère que chacun d'eux est une
1. Méthode d'Étude et de Réalisation Informatique pour les Systèmes d'Entreprises.
2.1. Éléments constitutifs du modèle entités-associations 11

entité du domaine et que chaque entité appartient à une classe ou type d'entités. On dénit naturel-
lement quatre types d'entités qu'on nommera CLIENT, VEHICULE, CONTRAT et ACCIDENT. On
représentera ces types d'entités d'une manière graphique comme indiqué dans la gure 9.1.
Ces quelques exemples montrent qu'un type d'entités peut correspondre à des :
 Objets concrets inanimés : véhicules
 Objets concrets animés : clients
 Conventions abstraites : contrats
 Événements : accidents

Dénitions
• Une entité est un objet, une chose concrète ou abstraite qui peut être reconnue distinctement et
qui est caractérisée par son unicité.
 Exemples d'entité : Mehdi Idrissi, le livre que je tiens entre les mains, la Mercedes qui se trouve
dans mon garage etc.
• Un type-entité désigne un ensemble d'entités qui possèdent une sémantique et des propriétés
communes.
 Exemples de types-entité : Les personnes, les livres et les voitures.

Exemple
Le domaine d'application est constitué d'entités concrètes ou abstraites. Ainsi, dans le contexte
de l'assurance automobile, on peut repérer dans un domaine d'application des clients, des véhicules,
des contrats et des accidents. On considère que chacun d'eux est une entité du domaine et que chaque
entité appartient à un type d'entités. On dénit naturellement quatre types d'entités qu'on nommera
CLIENT, VEHICULE, CONTRAT et ACCIDENT. On représentera ces types d'entités d'une
manière graphique comme indiqué dans la gure. 2.1.

Figure 2.1: Les quatre types d'entités du domaine d'application.

Ces quelques exemples montrent qu'un type d'entités peut correspondre à des objets concrets
inanimés (des véhicules), des objets concrets animés (des clients), des conventions abstraites (des
contrats) ou des événements (des accidents). Une entité est souvent nommée occurrence ou instance
de son type-entité.
2.1. Éléments constitutifs du modèle entités-associations 12

Par abus de langage, on utilise souvent le mot entité à la place du mot type d'entités, il faut
cependant prendre garde à ne pas confondre les deux concepts.

2.1.2 Attribut
Dénitions
• Un attribut (ou une propriété) est une caractéristique associée à un type-entité ou à un type-
association.
 Exemples d'attribut : le nom du client, la marque du véhicule, le type de contrat.

Exemple
Chaque client est caractérisé par un numéro, un nom et une adresse. On modélisera ces faits en
dotant l'entité CLIENT des attributs NumClient, Nom, Adresse (gure 2.2). De même, on donnera
à ACCIDENT les attributs NumAcc, DateAcc et Montant.

Figure 2.2: Les quatre entités et leurs attributs.

Règles
 Un attribut ne peut en aucun cas être partagé par plusieurs type-entités ou type-associations.
 Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou dérivées.
 Un type-entité et ses attributs doivent être cohérents entre eux (i.e. ne traiter que d'un seul
sujet).

2.1.3 Identiant
Dénitions
• Un identiant d'un type-entité ou d'un type-association est constitué par un ou plusieurs de ses
attributs qui doivent avoir une valeur unique pour chaque entité ou association de ce type.
 Exemples d'identiant : le numéro de sécurité sociale pour une personne, le numéro d'immatri-
culation pour une voiture, le code ISBN d'un livre pour un livre (mais pas pour un exemplaire).
2.1. Éléments constitutifs du modèle entités-associations 13

Exemple
En général, chaque entité est dotée d'un attribut qui l'identie. L'entité CLIENT, par exemple
possède un attribut NumClient tel qu'à tout instant les entités CLIENT ont des valeurs de NumClient
distinctes. En d'autres termes, étant donné une valeur quelconque de NumClient, on a la garantie
qu'il n'y aura, à aucun moment, pas plus d'une entité CLIENT possédant cette valeur. On dira que
NumClient est un identiant de CLIENT. Il en est de même de NumVeh pour VEHICULE et de
NumAcc pour ACCIDENT et NumCtr pour CONTRAT.
Dans la représentation graphique, les attributs qui constituent l'identiant sont soulignés et placés
en tête comme c'est illustré dans la gure 2.3.

Figure 2.3: Illustration de la notion d'identiant.

Règles
 Chaque type-entité possède au moins un identiant, éventuellement formé de plusieurs attributs.
 Il est impossible que les attributs constituant l'identiant d'un type-entité (respectivement type-
association) prennent la même valeur pour deux entités (respectivement deux associations) dis-
tinctes

Types d'identiants
 Une propriété naturelle, par exemple le nom d'un pays pour l'entité pays.
 Une propriété articielle, inventée par le concepteur pour identier l'entité qu'il vient de conce-
voir (tous les numéros, références, codes, etc).
 Une propriété composée en s'assurant que la règle de composition ne générera pas de doublons ;
on parle alors d'identiant composé ; par exemple nom + prénom + date et lieu de naissance.

2.1.4 Association
Dénitions
• Une association est un lien entre plusieurs entités.
2.1. Éléments constitutifs du modèle entités-associations 14

 Exemples d'association : l'emprunt par l'étudiant Adil du deuxième exemplaire du livre "Maî-
trisez SQL".
• Un type-association désigne un ensemble de relations qui possèdent les mêmes caractéristiques.
Le type-association décrit un lien entre plusieurs type-entités.
 Exemples de type-association : l'emprunt d'un livre à la bibliothèque.

Exemple
Un contrat est lié au client qui l'a signé ; il existe donc une association entre ce contrat et ce
client. On dira que toutes les associations de cette nature appartiennent au type d'associations signe
entre les types d'entités CLIENT et CONTRAT. On dénira également un type d'associations
Appartient entre CLIENT et VEHICULE, indiquant qu'un véhicule appartient à un client, ainsi
qu'un type d'associations Couvre entre CONTRAT et VEHICULE, indiquant qu'un contrat couvre
les risques d'un véhicule. De même, en admettant qu'un accident implique un nombre quelconque de
véhicules, on dénira un type d'associations Implique entre ACCIDENT et VEHICULE. Ces types
d'associations sont représentés graphiquement dans la gure 2.4.

Figure 2.4: Types d'entités, attributs et types d'associations.

Règles
 Un attribut peut être placé dans un type-association uniquement lorsqu'il dépend de toutes les
entités liées par le type-association.
2.1. Éléments constitutifs du modèle entités-associations 15

2.1.5 Cardinalité
Dénitions
• La cardinalité précise le nombre de fois minimal et maximal d'interventions d'une entité du
type-entité dans une association du type-association.
 Exemple de cardinalité : une personne peut être l'auteur de 0 à n (plusieurs) livre.

Types de cardinalités
Si une cardinalité maximale est connue et vaut 2 , 3 ou plus, alors nous considérons qu'elle est
indéterminée et vaut n . En eet, si nous connaissons n au moment de la conception, il se peut que
cette valeur évolue au cours du temps. Il vaut donc mieux considérer n comme inconnue dès le départ.
De la même manière, on ne modélise pas des cardinalités minimales qui valent plus de 1 car ces valeurs
sont également susce ptibles d'évoluer. Enn, une cardinalité maximale de 0 n'a pas de sens car elle
rendrait le type-association inutile.
Les seuls cardinalités admises sont donc :
0,1 : une occurrence du type-entité peut exister tout en étant impliquée dans aucune association et
peut être impliquée dans au maximum une association. Par exemple : un contrat peut couvrir
un véhicule.
0,n : c'est la cardinalité la plus ouverte ; une occurrence du type-entité peut exister tout en étant
impliquée dans aucune association et peut être impliquée, sans limitation, dans plusieurs asso-
ciations. Par exemple : un département occupe des employés.
1,1 : une occurrence du type-entité ne peut exister que si elle est impliquée dans exactement
(au moins et au plus) une association. Par exemple : tout employé est occupé par un
département.
1,n : une occurrence du type-entité ne peut exister que si elle est impliquée dans au moins une
association. Par exemple : un accident implique des véhicules.
Une cardinalité minimale de 1 doit se justier par le fait que les entités du type-entité en questions
ont besoin de l'association pour exister. Dans tous les autres cas, la cardinalité minimale vaut 0 .
Ceci dit, la discussion autour d'une cardinalité minimale de 0 ou de 1 n'est intéressante que lorsque la
cardinalité maximale est 1 . En eet, nous verrons que, lors de la traduction vers un schéma relationnel,
lorsque la cardinalité maximale est n , nous ne ferons pas la diérence entre une cardinalité minimale
de 0 ou de 1 .

Exemple
La gure 2.5 complète le schéma de la gure 2.4 en y précisant les cardinalités.
2.2. Types d'associations 16

Figure 2.5: Caractérisation des cardinalités.

Règles
 L'expression de la cardinalité est obligatoire pour chaque patte d'un type-association.
 Une cardinalité minimal est toujours 0 ou 1 et une cardinalité maximale est toujours 1 ou n.
 La cardinalité minimale doit être inférieure ou égale à la cardinalité maximale.
 Si une cardinalité maximale est connue et vaut 2, 3 ou plus, alors nous considérons qu'elle est
indéterminée et vaut n.

2.2 Types d'associations

2.2.1 Association plurielle
Deux mêmes entités peuvent être plusieurs fois en association. La gure 2.6 illustre un exemple
d'associations plurielles entre un type-entité Personne et un type-entité Livre. Sur ce schéma, un type-
association permet de modéliser que des personnes écrivant des livres et un autre que des personnes
critiquant (au sens de critique littéraire) des livres.
2.2. Types d'associations 17

Figure 2.6: Exemple d'association plurielle

2.2.2 Association réexive

La gure 2.7 présente un exemple d'associations reexives sur le type-entité Personne. Le pre-
mier type-association permet de modéliser la relation parent/enfant et le deuxième type-association la
relation de fraternité.

Figure 2.7: Exemple d'association réexive

2.2.3 Association n-aire (n > 2)

Ce type-association met en relation n type-entités. Même s'il n'y a, en principe, pas de limite sur
l'arité d'un type-association, dans la pratique on ne va rarement au-delà de trois. Les associations
de degré supérieur à deux sont plus diciles à manipuler et à interpréter, notamment au niveau des
cardinalités.
Pour connaître la quantité de chacune des pièces fabriquée par chaque ouvrier à une date donnée,
on utilise une association ternaire entre OUVRIER, PIECE et DATE. La quantité est une donnée
portée par cette association.
2.3. Évolution du modèle 18

Figure 2.8: Exemple de type-association ternaire.

L'association ternaire implique aussi que :

• Pour un ouvrier, on peut avoir plusieurs pièces diérentes à la même date (il peut fabriquer
plusieurs types de pièces le même jour).
• Une pièce peut être fabriquée par plusieurs ouvriers diérents le même jour.
• A des dates diérentes, un même ouvrier peut fabriquer les mêmes pièces.

2.3 Évolution du modèle

On considère l'exemple de la bibliothèque de prêt. La phrase caractéristique décrivant l'activité de
la bibliothèque est la suivante : "Un lecteur emprunte un livre." On en déduit les deux entités lecteur
et livre liées par l'association emprunte :
• Un lecteur est caractérisé classiquement par son nom, son prénom et son adresse. Comme il n'y
a pas d'attribut possédant les caractéristiques d'un identiant pour l'entité lecteur, on ajoute
un attribut identiant. Cet attribut supplémentaire est le numéro de lecteur. À noter que dans
le monde réel, ce numéro pourrait correspondre par exemple à un numéro de carte de lecteur.
• Un livre est caractérisé par son titre, son auteur, son numéro ISBN, son éditeur. Le numéro ISBN
est ici un identiant pour l'entité puisqu'il est unique.
• L'association emprunte a pour attribut la date d'emprunt.
2.3. Évolution du modèle 19

Figure 2.9: Entités livre et lecteur liées par l'association emprunte (sans cardinalités).

Cet exemple simple permet de se poser quelques questions qui vont conduire à une réorganisation
du modèle.

Que se passe-t-il si l'on possède plusieurs exemplaires du même ouvrage ?

Le numéro ISBN n'est plus identiant puisqu'il est le même pour chacun des exemplaires. Une
solution consiste à ajouter un numéro supplémentaire unique pour chaque livre, qui correspond à la
notion de cote dans une bibliothèque. Ainsi, même si l'on a dix exemplaires d'un ouvrage, il est possible
de les diérencier. L'inconvénient de cette solution est que l'on répète les informations communes aux
diérents ouvrages (titre, auteur...) à chaque exemplaire. L'un des risques est de répéter incorrectement
ces informations et d'aboutir ainsi à des incohérences. La solution correcte dans ce cas est de séparer
l'entité Livre en deux entités Livre et Ouvrage. L'activité de la bibliothèque est alors décrite par
deux phrases :
• Un lecteur emprunte un exemplaire.
• Un livre représente un exemplaire d'un ouvrage.
Un ouvrage est caractérisé par un numéro (cote). Un livre est caractérisé par un ISBN, qui est bien
dans ce cas un identiant, un titre, un auteur et un éditeur.
2.3. Évolution du modèle 20

Figure 2.10: Entités livre, ouvrage et lecteur liées par les associations emprunte et est un exemplaire
(sans cardinalités).

Que se passe-t-il si l'ouvrage possède plusieurs auteurs ?

La solution correcte dans ce cas est de créer une entité supplémentaire pour ces attributs qui sont
sémantiquement de même type. On créera ici une entité auteur qui contiendra un numéro d'auteur
(identiant), son nom et son prénom. Cette entité est reliée à l'entité ouvrage par l'association A écrit.

Figure 2.11: Entités livre, ouvrage, auteur et lecteur liées par les associations emprunte, a_écrit et
est un exemplaire (sans cardinalités).
2.3. Évolution du modèle 21

Que se passe-t-il si un auteur emprunte un livre ?

Comme les entités lecteur et auteur ont la même structure (c'est-à-dire des mêmes attributs),
la solution consiste à les fusionner en une entité unique personne. Cette opération conduit à une
association entre les entités personne et livre (emprunte) et les entités personne et ouvrage (A écrit).

Figure 2.12: Entités livre, ouvrage, personne liées par les associations emprunte, a_écrit et
est_un_exemplaire (sans cardinalités).

Résumé
On a identié dans cette sous-section plusieurs cas qui nécessitent de réorganiser les entités obtenues
lors d'une première analyse :
• Si l'on repère à l'intérieur d'une entité des attributs qui représentent un ensemble logique (mis
en valeur dans l'exemple par un défaut d'identiant pour un livre), on sépare ces attributs dans
une entité supplémentaire.
• Si des attributs dans une même entité possèdent une sémantique identique (auteurs, numéros de
téléphone multiples), on crée une entité supplémentaire pour séparer ces attributs. Cette entité
sera associée à celle dont proviennent les attributs à l'origine.
• Si des entités ont la même structure (et représentent le même type d'objet), on les fusionne et
l'on conserve les associations qui existaient avant la fusion.
 22

Chapitre 3

Modèle relationnel
Le modèle conceptuel exprime clairement les structures d'information à représenter, mais il n'est pas
accepté tel quel par l'ordinateur. Il est donc nécessaire de traduire ce modèle en structures techniques
de tables et de colonnes, c'est-à-dire en concepts compréhensibles et gérables par des outils disponibles :
les SGBD relationnels.
De façon informelle, on peut dénir le modèle relationnel de la manière suivante :
 les données sont organisées sous forme de tables à deux dimensions, encore appelées relations,
dont les lignes sont appelées n-uplet ou tuple en anglais ;
 les données sont manipulées par des opérateurs de l'algèbre relationnelle ;
 l'état cohérent de la base est déni par un ensemble de contraintes d'intégrité.

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

Le modèle relationnel est un modèle logique de données qui correspond à l'organisation des données
dans les bases de données relationnelles.
Un modèle relationnel est composé de relations, encore appelées tables. Ces tables sont décrites
par des attributs ou champs (noms de colonnes). Pour décrire une relation, on indique tout simple-
ment son nom, suivi du nom de ses attributs entre parenthèses. L'identiant d'une relation est composé
d'un ou plusieurs attributs qui forment la clé primaire. Une relation peut faire référence à une autre
en utilisant une clé étrangère, qui correspond à la clé primaire de la relation référencée.
Il n'y a pas de notation ocielle pour repérer les clés primaires et étrangères. Dans ce cours, nous
utiliserons la notation suivante :
 On souligne la clé primaire d'un seul trait.
 On fait précéder les clés étrangères du symbole #.
 Exemple : TABLE(cle_primaire, colonne1, colonne2, #cle_étrangère)
3.1. Passage du modèle entités-associations au modèle relationnel 23

3.1.1 Représentation des entités

Chaque type-entité donne naissance à une relation. Chaque attribut de ce type-entité devient un
attribut de la relation. L'identiant est conservé en tant que clé de la relation.

Figure 3.1: Transformation d'une entité en une relation.

3.1.2 Représentation des associations

Nous devons distinguer les trois classes fonctionnelles de types d'associations : un-à-plusieurs, un-
à-un et plusieurs-à-plusieurs.

3.1.2.1 Associations un-à-plusieurs

Toute association hiérarchique (de type [1, n ]) se traduit par une clé étrangère. La clé primaire
correspondante à l'entité mère (côté n ) migre comme clé étrangère dans la relation correspondant à
l'entité ls (côté 1 ).

Figure 3.2: Représentation d'un type d'associations un-à-plusieurs

Le modèle relationnel adéquat correspondant au modèle entités-associations de la gure 3.2 devient

donc :
 CLIENT(code_client, Nom, Prénom, Adresse, code_postal, telephone)
 COMMANDE(numero_commande, date, etat, montant_total, #code_client)
3.1. Passage du modèle entités-associations au modèle relationnel 24

où code_client joue le rôle de la clé primaire dans la relation CLIENT et joue le rôle de la clé étrangère
dans la relation COMMANDE.

3.1.2.2 Associations un-à-un

Dans l'exemple de la gure 3.3 toutes les cardinalités maximales du type-association Etre sont de
1.

Dans ce cas, la clé primaire de la table issue de l'entité côté cardinalités (0,1) est dupliquée dans
la table issue de l'entité côté cardinalités (1,1) où elle devient clé externe.

Figure 3.3: Représentation d'un type d'associations un-à-un.

Le modèle relationnel adéquat correspondant au modèle entités-associations de la gure 3.3 devient

donc :
 CITOYEN(Num_Citoyen, Nom, Prénom, Adresse)
 CANDIDAT(Num_Candidat, Parti, #Num_Citoyen)
où Num_Citoyen, en plus d'être la clé primaire de la relation CITOYEN, est une clé étrangère de la
relation CANDIDAT.

3.1.2.3 Associations plusieurs-à-plusieurs

Toute association non hiérarchique (de type [n, n ] ou de dimension > 2) devient une relation. La
clé primaire est formée par la concaténation de l'ensemble des identiants des entités reliées. Toutes
les propriétés éventuelles deviennent des attributs qui ne peuvent pas faire partie de la clé.

Figure 3.4: Représentation d'un type d'associations plusieurs-à-plusieurs

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

Cette règle est valable pour toutes les associations ternaires (ou quaternaires) qui sont forcément
non hiérarchiques (cardinalités maximales toutes égales à n ).
Le modèle relationnel adéquat correspondant au modèle entités-associations de la gure 3.4 devient
donc :
 COMMANDE(Num_Commande, date, etat, montant_total)
 ARTICLE(Ref_article, designation, prix)
 CONCERNER (#Num_Commande,#Ref_article, quantite)
où Num_Commande représente la clé primaire de la relation COMMANDE et Ref_article représente
la clé primaire de la relation ARTICLE. La concaténation de ces deux clés primaires représentent la
clé primaire de la relation CONCERNER nouvellement créée, et chacune de ces clés représente des
clés étrangères.

3.1.2.4 Associations réexives

Les associations réexives (ou cycliques) suivent les règles précédemment citées selon les cardinalités
mais posent un problème particulier : une même propriété va se retrouver deux fois en attribut dans la
même relation. Il faut alors donner un nom diérent et signicatif aux deux attributs correspondants.
A titre d'exemple, on considérera la traduction du type d'associations un-à-plusieurs dirige (ou
encadre) de la gure 3.5.

Figure 3.5: La représentation d'un type d'association un-à-plusieurs cyclique obéit aux mêmes règles
que celle des autres types d'associations.

Un salarié a pour chef 0 ou un seul autre salarié. Un salarié est chef de 0 à n autre(s) salarié.
 L'identiant de l'entité SALARIE va devenir clé primaire et les autres propriétés des attributs.
 L'identiant de l'entité SALARIE devient clé étrangère. Ainsi, l'identiant de SALARIE (ma-
tricule) se retrouve deux fois dans la relation : comme clé primaire et comme clé étrangère. On
va donc donner un nom diérent et signicatif à ces deux matricules.
Le modèle relationnel résultant est le suivant :
 SALARIE(matricule, nom, prénom, fonction,. . . , #matricule_chef)
Soit l'exemple présenté dans la gure 3.6. Une pièce entre dans la composition de 0 à plusieurs autres
pièces. Une pièce peut être composée de plusieurs autres pièces. Une pièce entre dans la composition
d'une autre un certain nombre de fois. Par exemple, La pièce voiture est composée de 4 pièces roue.
3.2. Normalisation 26

La pièce roue est elle-même composée d'une pièce pneu et d'une pièce jante.

Figure 3.6: La représentation d'un type d'associations cyclique plusieurs-à-plusieurs demande la dé-
nition d'une table associative.

Une pièce entrant dans la composition d'une autre est appelée composant. Une pièce composée
d'autres pièces est appelée composé. Une roue est à la fois un composant (de voiture) et un composé
(de pneu et jante). La traduction en modèle relationnel est la suivante :
 PIECE(référence, libellé)
 COMPOSITION(#référence_composé, #référence_composant, nombre)

3.2 Normalisation
La normalisation permet d'éviter la redondance dans les bases de données relationnelles an d'éviter
ou de limiter :
 Les pertes de données.
 Les incohérences au sein des données.
 L'eondrement des performances des traitements.

3.2.1 Dépendances fonctionnelles

Soit R(A1 ;A2 ; : : :An) un schéma de relation, et X et Y des sous-ensembles de A1 ;A2 ; : : :An. On
dit que X détermine Y ou que Y dépend fonctionnellement de X si, et seulement si, des valeurs
identiques de X impliquent des valeurs identiques de Y. On le note :X → Y .
Autrement dit, il existe une dépendance fonctionnelle entre un ensemble d'attributs X et un en-
semble d'attributs Y, que l'on note X → Y , si connaissant une occurrence de X on ne peut lui associer
qu'une seule occurrence de Y.

Exemple
La relation : Voiture (NV, Couleur, Modèle, Marque, Conducteur, Infraction)
3.2. Normalisation 27

contient les dépendances fonctionnelles suivantes :

 NV -> Couleur
 NV -> Modèle
 Modèle -> Marque
 NV-> Marque
 NV, Conducteur -> Infraction

3.2.2 Graphe DF
Le graphe DF est une représentation graphique des dépendances fonctionnelles entre les données.
Pour qu'un graphe DF soit minimum, il faut s'assurer que toutes ses DF sont élémentaires et
non déduites.
 DF déduite
 X -> D est déduite s'il existe un autre chemin X -> A1 . . . à . . . An -> D
 DF non élémentaire
 X -> D est non élémentaire s'il existe une DF Y -> D telle que Y est un sous-ensemble des
attributs de X
 (A,B,C) -> D est non élémentaire

Figure 3.7: Exemples de DF déduite et DF non élémentaire.

Exemple d'un graphe minimum

Le graphe minimum de la relation R (A, B, C, D, E) :
 E -> A
 E -> B
 E -> C
 C-> D
3.2. Normalisation 28

Figure 3.8: Graphe minimum.

Exemple d'un graphe non minimum

E -> D est déduite de E -> C et C -> D. Il faut supprimer E -> D du graphe.

Figure 3.9: Graphe non minimum.

DFs et identiants
L'identiant d'une relation est l'ensemble (minimal) des noeuds du graphe minimum à partir des-
quels on peut atteindre tous les autres noeuds (via les DF).
Par exemple, l'identiant de la relation R (A, B, C, D, E, F, G)
3.2. Normalisation 29

Figure 3.10: DFs et identiants.

est (F, G).

3.2.3 Formes normales

3.2.3.1 Première forme normale
La première forme normale s'intéresse au contenu des champs. Elle interdit la présence de plusieurs
valeurs dans un même champ d'une relation. Elle s'exprime de la manière suivante :
• Tout champ contient une valeur atomique.
La relation suivante n'est pas en première forme normale ; le champ Auteurs contient plusieurs
valeurs (voir Tableau 3.1).
 PUBLICATION(NumPubli, Titre, Auteurs)

NumPubli Titre Auteurs

1235 L'avenir lumineux Karim Mokhtari, Yassine Benjeloune,
Meriem Afdel
4587 Evolution technologique Saad Issad, Zakaria Hannad
9854 Développement rapide Zineb Louraoui, Ahmed Fakhar

Table 3.1: Relation PUBLICATION avec un champ à plusieurs valeurs.

Comment passer en première forme normale ?

Une solution pour résoudre ce problème est de décomposer le champ Auteurs en Auteur_1, Au-
teur_2, Auteur_3, Auteur_4, etc. Ainsi, la relation est bien en première forme normale. L'ennui est
que l'on ne sait pas à l'avance le nombre d'auteurs que peut posséder une publication, et le problème
consiste donc à savoir combien de champs ajouter.
3.2. Normalisation 30

La solution la plus correcte, mais également la plus lourde à mettre en oeuvre, est de décomposer
cette relation en trois relations :
 PUBLICATION(NumPubli, Titre)
 AUTEUR(NumAuteur, Nom, Prenom)
 EstEcrite(NumPubli, NumAuteur)
Ces trois relations sont la représentation de la réalité une publication est écrite par des auteurs.
Elle se modélise par deux entités PUBLICATION et AUTEUR reliées par l'association EstEcrite.

3.2.3.2 Deuxième forme normale

Une relation doit déjà se trouver en première forme normale pour être en deuxième forme normale.
Cette dernière recherche la redondance d'information dans une relation. Elle interdit les dépendances
possibles entre les champs qui composent la clé et les autres champs. On peut l'exprimer de la manière
suivante :
• La relation est en première forme normale.
• Tout champ qui n'appartient pas à la clé ne dépend pas d'une partie de la clé.
On considère la relation PRODUIT suivante (voir Tableau 3.2).
 PRODUIT(NomArticle, NomFournisseur, Ville, Prix)

NomArticle NomFournisseur Ville Prix

Clavier Microchoix Rabat 125
Souris Surcout Casablanca 80
Souris Microchoix Rabat 65
USB Electroplanet Rabat 150
Ecran Surcout Casablanca 1000

Table 3.2: Relation PRODUIT

Comment passer en deuxième forme normale ?

La solution consiste à décomposer la relation en deux relations. La nouvelle relation créée a pour
clé la partie de la clé dont dépendent les autres champs qui constituent ses champs.
3.2. Normalisation 31

La clé est constituée des champs nomArticle et nomFournisseur. Or, il y a une relation de dépen-
dance entre le champ nomFournisseur, qui est une partie de la clé, et le champ Ville. On décompose
alors la relation pour éliminer la redondance ainsi créée. La nouvelle relation aura pour clé la partie de
la clé de la relation d'origine dont dépendent fonctionnellement les autres champs. Dans cet exemple,
il s'agit du champ nomFournisseur. Les autres champs dépendants constituent le reste de la relation.
Il s'agit ici du champ Adresse.
On obtient alors le résultat suivant :
 PRODUIT(NomArticle, NomFournisseur, Prix)
 FOURNISSEUR(NomFournisseur, Ville)

3.2.3.3 Troisième forme normale

La troisième forme normale recherche également la redondance d'information dans une relation.
On cherche s'il existe une dépendance entre deux champs qui ne font pas partie d'une clé. Si c'est le
cas, on se trouve dans la situation où un champ dépend d'un autre champ qui dépend lui même d'une
clé. La clé considérée peut être primaire ou secondaire. La troisième forme normale interdit donc les
dépendances dites transitives entre les champs. Elle s'exprime de la manière suivante :
• La relation est en deuxième forme normale (donc en première forme normale).
• Tout champ n'appartenant pas à une clé ne dépend pas d'un autre champ non clé.
On considère la relation suivante (voir Tableau 3.3) :
 BALADEUR (Numbal, Marque, Type, Couleur)

NumBal Marque Type Couleur

12 Apple Ipod Blanc
43 Creative Zen Noir
23 Apple Ipod Noir
29 Creative Zen Gris
34 Sony MZ Rouge

Table 3.3: Relation BALADEUR

Comment passer en troisième forme normale ?

La solution est également de décomposer la relation de départ en deux relations. La nouvelle
relation créée a pour clé le champ dont dépendent les autres champs qui constituent ainsi la dépendance
transitive.
La clé de cette relation est un numéro, NumBal, car il peut y avoir dans notre stock plusieurs
baladeurs de même marque, de même type et de même couleur. Les marques déposent les noms des
3.2. Normalisation 32

objets qu'elles fabriquent de façon à les identier sur le marché. Il existe donc une dépendance entre
le champ Type (qui n'appartient pas à la clé) et le champ Marque (qui n'appartient pas à la clé).
On décompose la relation en créant une nouvelle qui a pour clé le champ dont dépendent les autres
champs constituant la dépendance transitive. Il s'agit dans ce cas du champ Type. Les autres champs
de la nouvelle relation sont composés des champs qui en dépendent fonctionnellement : ici, le champ
Marque.
On obtient alors le résultat suivant :
• BALADEUR(NumBal, Type, Couleur)
• BALADEUR_TYPE(Type, Marque)
 33

Chapitre 4

Le langage SQL
Un SGBD doit permettre la manipulation de la structure de la base de données, comme l'ajout et la
modication de champs, de manière transparente. Il conserve à cet eet une description de la structure
de la base de données que l'on appelle le dictionnaire de données. Pour réaliser ces opérations avec
l'indépendance souhaitée par rapport à la représentation, le SGBD ore trois langages de haut niveau :
• Langage de Dénition de Données (LDD) qui permet d'agir sur la structure de la base de
données (ajout, suppression et modication des tables).
• Langage de Manipulation de Données (LMD) qui permet de mettre à jour le contenu de
la base de données.
• Langage d'interrogation de Données (LID) qui permet d'interroger le contenu de la base
de données.
Il existe de nombreux systèmes de gestion de bases de données, en voici une liste non exhaustive :
• MySQL
• Oracle
• Microsoft SQL
• Access
SQL est un langage relationnel, il manipule donc des tables (i.e. des relations, c'est-à-dire des
ensembles) par l'intermédiaire de requêtes qui produisent également des tables.
Avant de présenter les trois langages du SGBD, voici quelques commandes SQL importantes :
 Create database nombase : Pour créer une base de données de nom nombase.
 Use nombase : Pour utiliser la base de données nombase.
 Show tables : Pour acher les tables de la base de données utilisée.
 Describe nom_table : Pour acher le détail des colonnes de la table nom_table.
Dans la suite de ce document, on considérera la base de données dénie par le modèle relationnel
suivant :

 CLIENT (numcli, nomcli, ville, categorie, compte)

4. Le langage SQL 34

 COMMANDE (numcom, numcli, datecom)

 PRODUIT (numpro, nompro, prix, qstock)
 DETAIL (numcom, numpro, qcom)
Cette base de données est remplie par les informations présentées dans la gure suivante :

(a) Table CLIENT. (b) Table COMMANDE.

(c) Table PRODUIT. (d) Table DETAIL.

Figure 4.1: Informations contenues dans la base de données considérée.

4.1. Langage de définition de données 35

4.1 Langage de dénition de données

4.1.1 Création d'une table
Une table est un ensemble de lignes et de colonnes. La création consiste à dénir (en fonction de
l'analyse) le nom de ces colonnes, leur type, la valeur par défaut à la création de la ligne (default) et
les règles de gestion s'appliquant à la colonne (constraint).

Création simple
La commande de création de table la plus simple ne comportera que le nom et le type de chaque
colonne de la table. A la création, la table sera vide, mais un certain espace lui sera alloué. La syntaxe
est la suivante :
CREATE TABLE nom_table (nom_col1 type1, nom_col2 type2, ...) ;

Les types de données

Les types de données peuvent être :
 int : Ce type permet de stocker des entiers signés codés sur 4 octets.
 bigint : Ce type permet de stocker des entiers signés codés sur 8 octets.
 oat : Ce type permet de stocker des réels codés sur 4 octets.
 decimal(longueur, précision)] : Ce type de données permet de stocker des données numériques
à la fois entières et réelles avec une précision de 1000 chires signicatifs. La longueur précise le
nombre maximum de chires signicatifs stockés et la précision donne le nombre maximum de
chires après la virgule.
 char(longueur) : Ce type de données permet de stocker des chaînes de caractères de longueur
xe. longueur doit être inférieur à 255, sa valeur par défaut est 1.
 varchar(longueur) : Ce type de données permet de stocker des chaînes de caractères de longueur
variable. Il n'y a pas de valeur par défaut.
 time : Ce type de données permet de stocker des données constituées d'une heure.
 date : Ce type de données permet de stocker des données constituées d'une date.
 datetime : Ce type de données permet de stocker des données constituées d'une date et d'une
heure.
 text : Ce type de données permet des stocker des chaînes de caractères de longueur variable.

4.1.2 Contraintes d'intégrité

Les diérentes contraintes de colonne que l'on peut déclarer sont les suivantes :
4.1. Langage de définition de données 36

not NULL ou NULL : Interdit (not NULL) ou autorise (NULL) l'insertion de valeur NULL
pour cet attribut.
unique : Désigne l'attribut comme clé secondaire de la table. Deux n-uplets ne peuvent recevoir
des valeurs identiques pour cet attribut, mais l'insertion de valeur NULL est toutefois autorisée.
Cette contrainte peut apparaître plusieurs fois dans l'instruction.
primary key : Désigne l'attribut comme clé primaire de la table. La clé primaire étant unique,
cette contrainte ne peut apparaître qu'une seule fois dans l'instruction. La dénition d'une clé
primaire composée se fait par l'intermédiaire d'une contrainte de table. En fait, la contrainte
PRIMARY KEY est totalement équivalente à la contraite UNIQUE NOT NULL.
foreign key (colonne) references table [(colonne)] : Contrainte d'intégrité référentielle (Clé
étrangère) pour un attribut de la table en cours de dénition. Les valeurs prises par cet attributs
doivent exister dans l'attribut spécié et posséder une contrainte PRIMARY KEY ou UNIQUE
dans la table nom_table.
check (condition) : Vérie lors de l'insertion des données que l'attribut vérie la condition.
default valeur : Permet de spécier la valeur par défaut de l'attribut.
La suppression d'un n-uplet dans la table maître pourra être impossible s'il existe des n-uplets dans
d'autres tables référençant cette valeur de clé primaire et ne spéciant pas l'une de ces deux options.

4.1.3 Suppression d'une table

Supprimer une table revient à éliminer sa structure et toutes les données qu'elle contient. Les index
associés sont également supprimés. La syntaxe est la suivante :
DROP TABLE nom_table ;

4.1.4 Modication une table

Ajout, modication ou suppresion de colonne
ALTER TABLE nom_table add/modify/drop ([nom_colonne type [contrainte], ...]) ;

Ajout d'une contrainte de table

ALTER TABLE nom_table add [constraint nom_contrainte] contrainte ;

Renommer une colonne

ALTER TABLE nom_table rename column ancien_nom To nouveau_nom ;
4.2. Langage de manipulation de données 37

Renommer une table

ALTER TABLE nom_table rename To nouveau_nom ;

4.2 Langage de manipulation de données

4.2.1 Insertion des données
La commande INSERT permet d'insérer une ligne dans une table en spéciant les valeurs à insérer.
La syntaxe est la suivante :
INSERT into nom_table(nom_col_1, nom_col_2, ...) values (val_1, val_2, ...) ;
La liste des noms de colonne est optionnelle. Si elle est omise, la liste des colonnes sera par défaut
la liste de l'ensemble des colonnes de la table dans l'ordre de la création de la table. Si une liste de
colonnes est spéciée, les colonnes ne gurant pas dans la liste auront la valeur NULL.

4.2.2 Modication des données

La commande UPDATE permet de modier les valeurs d'une ou plusieurs colonnes, dans une ou
plusieurs lignes existantes d'une table. La syntaxe est la suivante :

UPDATE nom_table
set
nom_col_1 = expression_1 ,
nom_col_2 = expression_2 ,
...
nom_col_n = expression_n
WHERE predicat ;

4.2.3 Suppression des données

La commande DELETE permet de supprimer des lignes d'une table. La syntaxe est la suivante :

DELETE FROM nom_table

WHERE predicat ;
Toutes les lignes pour lesquelles predicat est évalué à vrai sont supprimées. En l'absence de clause
WHERE, toutes les lignes de la table sont supprimées.
4.3. Langage d'interrogation de données 38

4.3 Langage d'interrogation de données

Voici la syntaxe générale d'une commande SELECT :

SELECT [ ALL | DISTINCT ] * | expression [ AS nom_aché ] [, ...]

FROM nom_table [ [ AS ] alias ] [, ...]
[ WHERE prédicat ]
[ GROUP BY expression [, ...] ]
[ HAVING condition [, ...] ]
[ ORDER BY expression [ ASC | DESC ] [, ...] ]

En fait l'ordre SQL SELECT est composé de 7 clauses dont 5 sont optionnelles :
Select : Cette clause permet de spécier les attributs que l'on désire voir apparaître dans le résultat
de la requête.
From : Cette clause spécie les tables sur lesquelles porte la requête.
Where : Cette clause permet de ltrer les n-uplets en imposant une condition à remplir pour qu'ils
soient présents dans le résultat de la requête.
Group by : Cette clause permet de dénir des groupes (i.e. sous-ensemble).
Having : Cette clause permet de spécier un ltre (condition de regroupement des n-uplets) por-
tant sur les résultats
Order by : Cette clause permet de trier les n-uplets du résultat.

4.3.1 Sélection dans une seule table (Requêtes simples)

D'une manière générale, une requête simple contient trois parties principales :
 La clause select précise les valeurs (nom des colonnes, valeurs dérivées) qui constituent chaque
ligne du résultat,
 La clause from indique les tables desquelles le résultat tire ses valeurs,
 La clause where donne la condition de sélection que doivent satisfaire les lignes qui fournissent
le résultat.

Extraction simple
La requête la plus simple consiste à demander d'acher les valeurs de certaines colonnes de lignes
d'une table. La requête suivante demande les valeurs de numcli, nomcli et ville des lignes de la table
CLIENT.

select numcli, nomcli, ville

from CLIENT
Si on demande les valeurs de toutes les colonnes, la clause select peut se simplier comme suit :
4.3. Langage d'interrogation de données 39

select *
from CLIENT

Extraction de lignes sélectionnées

Extrayons à présent les informations numcli et nomcli des lignes de la table CLIENT qui concernent
les clients de Casablanca.

select numcli, nomcli

from CLIENT
where ville = 'Casablanca'

Lignes dupliquées
En principe, le résultat d'une requête monotable contient autant de lignes qu'il y a, dans la table
de départ, de lignes vériant la condition de sélection.
La requête suivante ache les villes où habitent des clients de catégorie B :

select ville
from CLIENT
where categorie = 'B'
La réponse contient autant de lignes que la table originale CLIENT en contient qui satisfont la sélection.
On pourra éliminer les lignes en double par la clause distinct comme suit :

select distinct ville

from CLIENT
where categorie = 'B'

Données extraites et données dérivées

Les données extraites jusqu'à présent proviennent directement de la base de données. La clause
select peut cependant spécier des données dérivées, ou même des constantes :

select 'TVA de ', numpro, ' = ',0.21*prix*Qstock

from PRODUIT
where qstock > 500
4.3. Langage d'interrogation de données 40

Cette requête produit un tableau des montants TVA des articles en stock dont la quantité restante est
supérieure à 500 unités.
Lors de l'achage du résultat, les colonnes reçoivent un nom qui est celui du composant de la
clause select. Dans le cas de données dérivées, le nom peut apparaître encombrant et peu signicatif.
On pourra alors dénir le nom qui apparaît en début de colonne, ce qu'on appelle un alias de colonne.
La formulation ci-dessous illustre ce principe :

select numpro as Produit, 0.21*prix*Qstock as Valeur_TVA

from PRODUIT
where Qstock > 500

Conditions élémentaires
Une condition élémentaire peut porter sur la présence de la valeur null :
 categorie is null
 categorie is not null
Une condition peut aussi porter sur l'appartenance à une liste :
 categorie in ('A','B','C')
 ville not in ('Tanger','Rabat','Casablanca')
ou à un intervalle :
 compte between 1000 and 4000
 categorie not between 'A' and 'C'
ou encore sur la présence de certains caractères dans une valeur :
 nomcli like '_assine'
 ville like '%blanc%'
Le signe '_' désigne un caractère quelconque et '%' désigne toute suite de caractères, éventuellement
vide.

Ordre des lignes d'un résultat

Par construction, l'ordre des lignes d'une table est arbitraire. Il est cependant possible d'imposer
un ordre de présentation spécique par la clause order by.
Les lignes de la table résultants de la requête suivante vont apparaître triées par valeurs croissantes
de ville.

select numcli, nomcli, ville

from CLIENT
where categorie in ('A','C')
order by ville
4.3. Langage d'interrogation de données 41

Par défaut, le classement se fait par ordre ascendant des valeurs. On peut également spécier explici-
tement un ordre ascendant (asc) ou descendant (desc) :

select *
from PRODUIT
where nompro like '%casques%'
order by Qstock desc

4.3.2 Requêtes logiques

La condition de sélection introduite par la clause where peut être constituée d'une expression
booléenne de conditions élémentaires (opérateurs and, or, not et parenthèses). La requête suivante
retient les lignes pour lesquelles, ville a pour valeur 'Rabat' et compte a une valeur négative

select nomcli, ville, compte

from CLIENT
where ville = 'Rabat' and COMPTE < 0
Étant donné les conditions P et Q relatives aux lignes de la table T, la clause

 where P and Q sélectionne les lignes de T qui vérient simultanément P et Q ;

 where P or Q sélectionne les lignes de T qui vérient P ou Q ou les deux ;
 where not P sélectionne les lignes de T qui ne vérient pas P.
Lors de l'évaluation d'une expression complexe, la négation (not) a priorité sur la conjonction (and),
qui elle-même a priorité sur la disjonction (or). On peut imposer un ordre d'évaluation diérent à l'aide
de parenthèses. Soit, par exemple, l'expression :

ville = 'Rabat' and compte < 0 or categorie = 'B'

Elle indique qu'une ligne de CLIENT est sélectionnée si (ville = 'Rabat' et compte < 0) ou si
(categorie = 'B') ou si les deux conditions sont vériées. On aurait pu écrire, de manière équivalente :

(ville = 'Rabat' and compte < 0) or categorie = 'B'

En revanche, l'expression :

ville = 'Rabat' and (compte < 0 or categorie = 'B')

a une toute autre interprétation. Une ligne de CLIENT est sélectionnée si elle vérie simultanément
deux conditions : d'une part, (ville = 'Rabat'), et d'autre part, (compte < 0, ou bien categorie = 'B',
ou encore les deux conditions simultanément).
4.3. Langage d'interrogation de données 42

A l'occasion, trois autres opérateurs pourront être utiles :

 la disjonction exclusive, notée P ⊕ Q (ou exclusif en français, absent d'SQL) ; cette expression
est vraie si un et un seul des arguments est vrai ;
 l'implication, notée P ⇒ Q (implique en français, absent d'SQL) ; cette expression est vraie
sauf si P est vrai et Q est faux ;
 l'équivalence, notée P ⇔ Q (équivaut à en français, absent d'SQL) ; cette expression est vraie
lorsque P et Q ont la même valeur.

4.3.3 Fonctions SQL

SQL ore un ensemble de fonctions permettant de dériver des valeurs à partir, entre autres, des
valeurs des colonnes des lignes extraites. Nous citerons les principales.

Fonctions du système
 current_date : la date courante ;
 current_time : l'instant courant ;
 current_timestamp : date + instant courant.

Fonctions agrégatives
 count(*) donne le nombre de lignes trouvées,
 count(nom-colonne) donne le nombre de valeurs de la colonne,
 avg(nom-colonne) donne la moyenne des valeurs de la colonne,
 sum(nom-colonne) donne la somme des valeurs de la colonne,
 min(nom-colonne) donne le minimum des valeurs de la colonne,
 max(nom-colonne) donne le maximum des valeurs de la colonne.
La requête ci-dessous fournit une table d'une ligne décrivant la répartition (moyenne, écart maxi-
mum, nombre) des montants des comptes des clients de Casablanca :

select 'Casablanca', avg(compte) as Moyenne,

max(compte)-min(compte) as Ecart_max,
count(*) as Nombre
from CLIENT
where ville = 'Casablanca'
4.3. Langage d'interrogation de données 43

4.3.4 Sélection utilisant plusieurs tables (Sous requêtes)

Les requêtes que nous allons étudier extraient encore des données d'une seule table, mais cette fois,
les lignes sources sont sélectionnées en fonction de leur liaison à des lignes déterminées appartenant à
d'autre tables.

Les sous-requêtes
Considérons les clients qui habitent dans une ville donnée. Il est possible d'en retrouver les numéros
en posant la requête suivante :

select numcli
from CLIENT
where ville = 'Casablanca'
dont l'exécution nous donnerait :

NCLI
2
5
10

Il est alors aisé de retrouver les commandes de ces clients de Casablanca :

select numcom, datecom

from COMMANDE
where numcli in (2,5,10)
Cette procédure n'est évidement pas très pratique. Il serait plus judicieux de remplacer cette liste de
valeurs par l'expression qui a permis de les extraire de la table CLIENT. On peut en eet écrire :

select numcom, datecom

from COMMANDE
where numcli in ( select numcli
from CLIENT
where ville = 'Casablanca')
Cette structure emboîtée correspond à l'association des tables COMMANDE et CLIENT sur la base
de valeurs identiques de numcli. Une structure select-from qui intervient dans une forme where est
appelée une sous-requête.
4.3. Langage d'interrogation de données 44

Une sous-requête peut elle-même contenir une sous-requête. La requête suivante donne les produits
qui ont été commandés par au moins un client de Casablanca.

select *
from PRODUIT
where numpro in ( select numpro
from DETAIL
where numcom in ( select numcom
from COMMANDE
where numcli in ( select numcli
from CLIENT
where ville='Casablanca')))

Conditions d'association négatives

La requête suivante désigne les commandes (c'est-à-dire les lignes de la table COMMANDE) qui
ne spécient pas le produit 2, autrement dit, celles pour lesquelles il n'existe aucun détail spéciant 2.

select numcom, datecom, numcli

from COMMANDE
where numcom not in ( select numcom
from DETAIL
where numpro = 2)

Références multiples à une même table

Une sous-requête peut être dénie sur la même table que la requête qui la contient. La requête
suivante répond à la question : Quels sont les clients qui habitent dans la même ville que le client 3 ?

select *
from CLIENT
where ville in ( select ville
from CLIENT
where numcli = 3)

Alias de table
Si deux tables ont deux colonnes de même nom, on pourra préxer le nom de la colonne du nom de
la table. On écrira par exemple COMMANDE.numcli et CLIENT.numcli an de distinguer les deux
4.3. Langage d'interrogation de données 45

colonnes de nom numcli dans le schéma.

On peut également attribuer un synonyme, dit alias de table, à un nom de table apparaissant
dans une clause from. Si nécessaire, on qualiera le nom de colonne de ce synonyme. Le terme as est
facultatif, et sera omis à l'occasion.

select *
from PRODUIT as P1
where P1.prix > 123

Les quanticateurs ensemblistes

Les quanticateurs any et all permettent, quant à eux, de comparer une valeur à celles d'un
ensemble déni par une sous-requête. any signie qu'au moins un élément de l'ensemble satisfait la
comparaison et all signie que tous les éléments la satisfont.
La requête suivante désigne les détails de commande spéciant la quantité minimum du produit 6,
c'est-à-dire tels qu'il n'existe pas de détails spéciant une quantité inférieure :

select *
from DETAIL
where Qcom <= all (select Qcom
from DETAIL
where numpro = 6)
and numpro = 6
La condition Qcom <= all (select Qcom from DETAIL where numpro = 6) s'interprète ainsi : la
valeur de Qcom (de la ligne de DETAIL courante) est inférieure ou égale à chacun des éléments de
(select Qcom from DETAIL where numpro = 6).
4.3. Langage d'interrogation de données 46

Quant à la requête ci-dessous, elle désigne les détails de commande 1 dont la quantité commandée
n'est pas minimale :

select *
from DETAIL
where Qcom >any (select Qcom
from DETAIL
where numpro = 1)
and numpro = 1
La condition Qcom > any (select Qcom from DETAIL where numpro = 6) s'interprète comme
suit : la valeur de Qcom est supérieure à au moins un des éléments de (select Qcom from DETAIL
where numpro = 6).

4.3.5 Extraction de données de plusieurs tables (Jointures)

Pour coupler deux tables, il faut d'abord préciser ces tables (clause from), ainsi que la règle d'as-
sociation des lignes de ces deux tables (clause where) dont les valeurs sont extraites (clause select).
Cette règle se présente généralement sous la forme de l'égalité des valeurs de deux colonnes. Une telle
opération d'association de tables porte le nom de jointure (en anglais join).
La requête ci-dessous extrait les informations sur les commandes, complétées pour chacune d'elles
de renseignements sur le client qui l'a émise.

select numcom, CLIENT.numcli, datecom, nomcli, ville

from COMMANDE, CLIENT
where COMMANDE.numcli = CLIENT.numcli
Son évaluation donnerait la table suivante.
4.3. Langage d'interrogation de données 47

Figure 4.2: Table résultante après l'opération de jointure.

Conditions de jointure et conditions de sélection

Les conditions telles que COMMANDE.numcli = CLIENT.numcli apparaissant dans les requêtes
de jointure sont appelée conditions de jointure, car elles régissent les associations entre les lignes de
COMMANDE et de CLIENT. On observera d'ailleurs que dans cette condition de jointure, COM-
MANDE.numcli correspond à une clé étrangère et CLIENT.numcli à un identiant primaire.
Techniquement, cependant, il s'agit d'une condition ordinaire appliquée aux colonnes de chaque
couple de lignes, et qui peut apparaître au milieu d'autres conditions de sélection, comme dans la
requête suivante, qui limite le résultat aux clients de catégorie B et aux commandes antérieures au 27
novembre 2015.

select numcom, CLIENT.numcli, datecom, nomcli, ville

from COMMANDE, CLIENT
where COMMANDE.numcli = CLIENT.numcli
and categorie = 'B'
and datecom < '2015-10-27'
4.3. Langage d'interrogation de données 48

Jointures avec Join on et Natural join

La requête ci-dessus peut également s'écrire sous le forme suivante :

select numcom, CLIENT.numcli, datecom, nomcli, ville

from COMMANDE join CLIENT
on COMMANDE.numcli = CLIENT.numcli
where categorie = 'B'
and datecom < '2015-10-27'
ou également comme suit :

select numcom, CLIENT.numcli, datecom, nomcli, ville

from COMMANDE natural join CLIENT
where categorie = 'B'
and datecom < '2015-10-27'

Sous-requête ou jointure ?
On peut faire observer que certaines conditions utilisant une sous-requête (select emboîté) peuvent
s'exprimer à l'aide d'une jointure. Par exemple, la requête :

select numcom, datecom

from COMMANDE
where numcli in (select numcli
from CLIENT
where ville = 'Rabat')
peut s'écrire également sous la forme d'une jointure :

select numcom, datecom

from COMMANDE, CLIENT
where COMMANDE.numcli = CLIENT.numcli
and ville = 'Rabat'
4.3. Langage d'interrogation de données 49

En revanche, certaines structures de select emboités ne peuvent pas s'exprimer par une jointure.
Tel serait le cas de la recherche des commandes qui ne spécient pas le produit 6, vue auparavant et
qu'on rappelle

select numcom, datecom, numcli

from COMMANDE
where NumCOM not in ( select numcom
from DETAIL
where numpro = 6)
Cette requête n'est en eet absolument pas équivalente à :

select distinct COMMANDE.numcom, datecom, numcli

from COMMANDE, DETAIL
where COMMANDE.numcom = DETAIL.numcom
and numpro <> 6
ni d'ailleurs à :

select distinct COMMANDE.numcom, datecom, numcli

from COMMANDE, DETAIL
where COMMANDE.numcom <> DETAIL.numcom
and numpro = 6
Il faut se souvenir qu'une jointure basée sur le couple identiant primaire/clé étrangère permet de
matérialiser des associations entre lignes. Elle ne permet pas de spécier l'inexistence d'associations.

4.3.6 Extraction de données groupées (Regroupements)

Considérons la table CLIENT. Il est permis d'y percevoir, des groupes de clients selon leur ville,
ou selon leur catégorie, ou encore selon leur nom. La requête suivante donne, pour chaque groupe
de clients classés ou regroupés par ville, le nom de celle-ci, le nombre de clients dans le groupe et le
montant moyen des comptes des clients du groupe.
4.3. Langage d'interrogation de données 50

select ville,
count(*) as NOMBRE_CLIENTS,
avg(compte) as MOYENNE_COMPTE
from CLIENT
group by ville

Le résultat compte autant de lignes qu'il y a de groupes ainsi constitués, et donc autant qu'il y a de
villes distinctes dans CLIENT :

Sélection de groupes et sélection de lignes

Des conditions de sélection peuvent être imposées aux groupes à sélectionner. Elles seront expri-
mées dans une clause having, ce qui évite toute confusion avec la clause where qui, elle, s'applique aux
lignes. Dans la requête ci-dessous, on ne retient par exemple que les groupes d'au moins trois clients :

select ville, count(*), avg(compte)

from CLIENT
group by ville
having count (*) >= 3
La requête suivante traite les lignes de COMMANDE en les regroupant par client :

select numcli, count(*)

from COMMANDE
group by numcli

Une fois les clients sont reconstitués à partir des commandes. On ne retient que les groupes d'au
moins deux commandes :

select numcli, count(*)

from COMMANDE
group by numcli
having count(*) >= 2
Dans le résultat on ne considère ensuite, avant groupement, que les commandes spéciant le produit
1. En clair, on s'intéresse aux clients qui ont commandé au moins deux fois le produit 1.

select numcli, count(*)

from COMMANDE
where NumCOM in ( select NumCOM
4.3. Langage d'interrogation de données 51

from DETAIL
where NumPRO = 1)
group by numcli
having count(*) >= 2

Groupes et jointures
Il est aussi possible d'obtenir la quantité totale de ce produit 1 que chaque client a commandée.
Les données à acher appartenant à plusieurs tables (NumCLI et somme des QCOM), il nous faut
opérer un groupement sur le résultat de la jointure de COMMANDE et DETAIL.

select M.NumCLI, count(*), sum(QCOM)

from COMMANDE M, DETAIL D
where M.NumCOM = D.NumCOM
and NumPRO = 1
group by M.NumCLI
having count(*) >= 2