Cours de Base de données Relationnelles

Filière SMI

Semestre V

Mohamed SABBANE

2022-2023

1
 Préambules

Les concepts envisagés dans ce cours nécessitent une révision continue.

Toutefois, ils peuvent servir de guide pour mieux comprendre les principes de
modélisation des bases de données relationnelles.

DESCRIPTION DU CONTENU DU MODULE

 Fournir une description détaillée des enseignements et/ou activités pour le

module (Cours, TD, TP, Activités Pratiques, ….).
 Pour le cas des Licences d’Etudes Fondamentales, se conformer au contenu
du tronc commun national.

Objectifs

L’objectif de ce module est de fournir aux étudiants un aperçu global sur le

concept des bases de données relationnelles. La démarche est la suivante :

 Analyser les besoins du client,

 Elaborer le cahier des charges,
 Concevoir une base de données qui répond aux contraintes d’un cahier des
charges,
 S’initier aux systèmes de gestion de base de données relationnelle,
 Créer une base de données (création des tables, clés primaires et
référentielles),
 Insérer des données dans une base de données,
 Interroger une base de données relationnelle (requêtes simples).

Plan du cours :

 Introduction aux systèmes d’information et de bases des données.

 Les Systèmes de Gestion des bases des données.
 Le modèle entité association.
 Le modèle relationnel.
 L’algèbre relationnelle.
 Le langage SQL.

2
 Chapitre I

Introduction aux systèmes d’information et bases des

données

I.I. Introduction
Le besoin en information et en
traitement d’information est devenu
l’élément clé du développement
humain. Dans ce sens, les systèmes
d’informations numériques sont
devenus indispensables à l’humanité.
I.2. Les constituants d’un système d’information
Le système d’information ne se limite pas
à la partie logicielle ou matérielle.
Comme le montre le schéma ci-coté, les
constituants d’un système d’information
forment une chaine dont les maillons
sont de différentes natures : du logiciel
au matériel aux canaux de
communications. Toutefois, la base de données reste le cœur du système et elle
est son élément indispensable.
I.3. Les fonctionnalités d’un Système d’Information
Les fonctionnalités d’un système d’information sont nombreuses et on peut les
présenter en trois fonctions majeures à savoir :
 Représentation : le système offre tous les outils de représentation des
informations décrivant une activité donnée. Il permet également le codage
de n’importe quel attribut par des valeurs numériques représentatives. (par
exemple : janvier est souvent représenté par le mois 1 …)
 Sauvegarde : le système permet le stockage et la restitution des données
mesurant les attributs de l’activité cible du système d’information. On

3
 utilise des supports (papier, magnétique, mémoire électronique) pour
stocker les données.
 Manipulation : Le système offre les outils de traitement et de manipulation
des données pour les façonner ou les mettre à disposition des utilisateurs.
(Opérateur de calcul, mise en forme, représentation graphique …)
I.4. Notions à identifier
Dans un environnement numérique, il est important d’identifier le vocabulaire
couramment utilisé. Bien que ce vocabulaire est très vaste, il est utile de focaliser
certain d’entre eux comme ci-après :
I.4.1. L’utilisateur
Il représente tout ce qui peut communiquer avec le système d’information. Il peut
être :
 Un être humain (employé, responsable, citoyen, professionnel … ),
 Des êtres vivants ou environnement (contrôle automatique, arrosage
automatique … )
 Un système d’information (lui-même ou autre) : un système qui se sert des
informations des autres systèmes pour construire ses propres informations
: exemple les fichiers journaux, les tendances des visiteurs, les pannes …)
 Une machine (industrie génération 4.0 ou 4G).
I.4.2. L’information
C’est l’ensemble des attributs mesurables qui peuvent décrire une partite ou
l’ensemble d’un sujet (un objet, un lieu …). Elle peut se concrétiser comme un
élément de connaissance. Par exemple :
 Le nom est une information
 La distance est une information
I.4.3. La donnée
Une donnée est une mesure de l’information et associée à un contexte
interprétatif pour qu’elle ait un sens.
 le nom est une information, « Mohamed » est une donnée,
 La longueur = 2 (dimension ?)
Une donnée numérique peut être :
 une chaîne de caractères,
4
  un nombre,
 une structure plus complexe telle qu’une date, un moment, une photo, une
vidéo ou un enregistrement sonore.
I.4.4. L’informatique
Le traitement automatique de l’information, avec toutes les fonctionnalités et
puissances qu’elle offre. Ce traitement devient indispensable lorsque le volume
ou la complexité des données deviennent grands. De même, la manipulation des
données numériques est plus facile alors que le support mémoire est d’autant
plus large en format numérique que dans d’autre format. Le lien entre
l’information/la donnée et le support mémoire peut être nettement différent
dans les cas suivants :
 Un texte sur papier (une forme solide),
 Un texte sur un fichier informatique (une forme fluide).
De même, le format représentatif conditionne l’usage :
 Un texte simple,
 Un document sous un logiciel sophistiqué,
 Un tableau sous un tableur…
La forme du fichier numérique condamne la façon d’usage (le tri, la recherche, le
calcul etc…). Cependant, il faut bien modéliser ses données pour profiter de la
puissance informatique.
I.4.5. La base de données
La base de données et la partie du système d’information où les informations sont
représentées et les données sont stockées. C’est un document informatique
spécial pour :
 Stocker, représenter les données,
 manipuler les données,
 fournir et publier l’information.
Historiquement, une base de données fait référence à un ensemble structuré de
données : cohérentes, durables, évolutives et indépendantes du matériel et
logiciels applicatifs. Par conséquent, les bases de données sont conçues avec le
maximum d’attention.

5
Le changement des outils (matériel et logiciel) ne doit pas affecter les données /
les informations du système d’information. Ces données devront servir pour
toujours.
I.4.6 Les Systèmes de Gestion de Base de données (SGBD)
Un Système de Gestion de Base de Données (SGBD) (Data Base Management
System : DBMS) est le logiciel spécialisé en la gestion complète des bases de
données.
Il offre toutes les fonctionnalités pour manipuler la base jusqu’à sa migration vers
d’autres systèmes différents. Ces fonctionnalités sont de la forme :
 Créer, Modifier, Sauvegarder, Restaurer, Entretenir et Mettre à jours la
base de données elle-même,
 Inscrire, Modifier, Supprimer, Trier, Transformer ou Publier les
données/les informations de la base de données,
 Protéger les données contre les utilisations illicites ou falsification…
Les SGBD sont des logiciels :
 libres ou propriétaires,
 simples ou très performants,
 dépendent des systèmes d’exploitations sur les quels sont installés,
 dépendent de type de communication utilisée (monoposte, client/serveur,
réparti, cloud …).
I.4.7. La communication
Le support de communication qui relie les éléments d’un système d’information
joue un rôle déterminant à la réussite de ce système. Dans les enivrements
classiques, généralement client-serveur, la communication n’avait pas
d’importance majeure. Actuellement dans un monde distribué (base de données
réparties, cloud-computing,…) la gestion de la communication devienne de plus
en plus importante.
Eventuellement, il existe d’autres termes relevant des systèmes d’information, ou
qui peuvent devenir important dans l’avenir. Il serait plutôt intéressant de les
identifier le moment venu.
I.5. Conclusion
Les systèmes d’informations sont devenus l’outil de travail et de communication
par excellence. En industrie, on parle actuellement de la génération 4.0.
6
L’évolution technologique des moyens de calcul et de communication ouvre de
nouveaux horizons pour les développeurs de solutions informatiques.
Les bases de données forment l’élément déterminant dans un système
d’information. Cependant, l’analyse, la modélisation et la conception des bases de
données restent pour toujours un sujet ouvert à l’innovation et à l’imagination.

7
 Chapitre II

Les Systèmes de Gestion des Bases des Données (SGBD)

II.1. Généralités
En principe, nous pouvons considérer tout logiciel qui offre les fonctionnalités de
base (écrire, sauvegarder, restaurer) comme un Système de Gestion de Base de
Données (SGBD).
Toutefois, l’usage des données et les contraintes liées à la cohérence, l’intégrité,
l’accès… définissent la nature et le type d’un SGBD. Par exemple, un texte simple
n’est rien d’autre qu’une succession de caractères dont l’ordre d’écriture et de
lecture est séquentiel.
Outre les fonctionnalités de base, d’autres opérations avancées ne sont pas
assurées par n’importe quel SGBD. Par exemple, la recherche d’un mot particulier
à travers des documents de grande taille ou le calcul du total d’une colonne
nécessitent des SGBD plus performant qu’un traitement de texte ordinaire. Il en
est de même pour les fonctions telles que le tri, le calcul, la sélection à travers
plusieurs documents …. A cet égard, les SGBD sont développés pour répondre aux
traitements spéciaux.
II.2. Historique
Historiquement, les SGBD ont beaucoup évolué depuis leurs premières versions
apparues au début des années 60. Il ne serait pas intéressant de citer les
différents SGBD qui ont apparu jusqu’à présent. Il est plutôt utile de focaliser
leurs types face aux nouveautés technologiques et aux différentes sortes d’usage
de l’information.
II.3. Types de Système (SGBD)
Le présent cours concerne les systèmes de gestion de base de données
compatible au langage SQL seulement. La présentation des autres systèmes ici,
les NoSQL, n’est introduite qu’à titre d’information.

8
En général, nous pouvons distinguer deux grandes familles des SGBD : SGBD- SQL
et SGBD-NoSQL. Les SGBD classiques utilisent le langage SQL (Structured Query
Language) pour manipuler les données. Ils font souvent référence aux bases de
données relationnelles (SGBDR).
Les SGBD NoSQL sont généralement récents par rapport à l’autre famille. Le
terme NoSQL se traduit simplement par « Not Only SQL » qui signifie qu’il s’agit là
des bases de données au-delà du type relationnel conforme à SQL.
II.3.1. Les SGBD de type « Not Only SQL »
La technologie multimédia et de l’internet fait exploser le volume de l’information
et le besoin humain d’un temps de réponse négligeable. A ce fait, le concept de
bases de données NoSQL s’est imposé par les systèmes d’information des
moteurs de recherche ou ceux des géants des réseaux sociaux. Pour ces derniers,
le temps de réponse du système devient lent quand on utilise les SGBDR.
La définition exacte de la famille des SGBD NoSQL est sujette de larges débat.
C’est que l’utilisation des systèmes d’informations en dehors des sujets classiques
de gestion nécessite des améliorations techniques même en dehors des normes
bien cadrées. Les bases de données NoSQL ne nécessitent pas de schéma fixe,
elles sont utilisées pour le Big data et les applications Web en temps réel…
Concept NoSQL
Les bases de données NoSQL n’ont pas toutes les mêmes concepts. On distingue
plusieurs approches de conception pour des finalités précises telles que :
 Bases de données orientées documents : Ces bases de données associent
généralement chaque clé à une structure de données complexe appelée
9
 document. Ce dernier peut contenir des paires de tableaux de clés ou des
paires clé-valeur ou même des documents imbriqués.
 Magasins de valeurs clés : Chaque élément est stocké sous la forme d’une
paire de valeurs clés et de données. Les magasins de valeur clé sont les plus
simples parmi les bases de données NoSQL.
 Mémoires à colonnes larges : Ces bases de données sont optimisées pour
les requêtes sur de grands ensembles de données. Au lieu de lignes, ils
stockent des colonnes de données ensemble.
 Base de donnée orientée graph : Ces bases de données stockent des
informations sur les structures de type graphe. Ce mode de représentation
est convenable aux réseaux sociaux.
Quelques SGBD NoSQL
 MONGODB : C’est un logiciel open source orientée document. Il utilise des
documents JavaScript Object Notation (JSON).
 CASSANDRA : Il a été développé pour le traitement de très grandes
quantités de données structurées.
 REDIS : Redis est le plus célèbre système de gestion de bases de type clé-
valeur.
 HBASE : Il s’agit d’une base de données distribuée conçue pour la base de
données BigTable par Google.
 NEO4J : une base de données de type graphe.
Les SGBD NoSQL ne font pas partie du présent cours, ils sont énoncés ici à titre
indicatif.
II.3.2. Les SGBD de type SQL
Les SGBD de norme SQL se limitent au langage SQL pour l’interrogation. Ils sont
aussi répartis en catégorie. En littérature, il existe plusieurs types tels que :
 Hiérarchique : les données sont enregistrées dans une structure
arborescente.
 Orienté objet et objet-relationnel : Ils sont destinés à offrir les
fonctionnalités des SGBD à des langages orientés objet.
 A base de XML ou RDF : s’appuient sur le modèle de données fourni par
XML.
 Mixte : de tels SGBD utilisent les différents paradigmes présentés
précédemment.
10
  Relationnel : les données sont placées dans des tables avec des lignes et
des colonnes. Cette catégorie est plus très populaire en littérature et celle
qui nous intéresse dans le présent cours.
II.4. Les SGBD Relationnels
Ce sont les systèmes de gestion de base de données qui utilisent :
 le langage SQL (Structured Query Language)
 les bases de données relationnelles.
Ils sont connus en littérature sous le nom (SGBDR).
Les bases de données relationnelles se constituent de tables liées par des
relations et soumises à des contraintes d’intégrité.
II.4.1. Architecture des SGBDR
L’architecture des bases de données dépond du SGBDR, elle peut être :

 Centralisée : plusieurs clients/ un seul serveur,

 Distribuée : plusieurs clients / plusieurs serveurs,
 Embarquée : un seul client / un seul serveur,
 Spatiale : (Centralisée, Distribuée, Embarquée) + le géo-référencement, c-à-
d, la localisation géographique les données (GPS par exemple).

II.4.2. Les fonctionnalités du SGBDR

Les fonctionnalités offertes par le SGBDR

font la différence entre les différents
systèmes existants. Certains sont très
performants et donc offrent des
fonctionnalités avancées, alors que
certains d’autre sont limités.

Par exemple, certain sont capable de gérer de grosse base de données. De même,
ils permettent de gérer en même temps plusieurs bases de données…

II.4.3.Architecture Fonctionnelle d’un SGBDR

Les SGBDR modernes offrent des fonctionnalités variées et ciblées.

11
Outre les données, une base de données
et dans sa globalité un ensemble de
volets complémentaires.

Comme le montre le schéma ci-coté, les

données utilisateurs, partie explicite, ne
sont qu’une partie de la base. D’autres
parties sont implicitement présentes
dans la structure de la base :
dictionnaire, statistiques, indexes,
journaux …

II.4.3.1. Les déclencheurs (Triggers)

Les bases de données intègrent des procédures ou des programmes écrits en un

langage spécifique au SGBD (PL/SQL pour oracle). Comme elles peuvent intégrer
juste des contraintes, liées aux propriétés des champs et des tables, ajoutées par
le concepteur de la base de données.

Les procédures ou les contraintes sont conçu pour répondre à un traitement

donné lorsqu’un événement se produit à la base. Par exemple, si on tente de
saisir une date incorrecte ou lorsqu’un problème arrive à une transaction.

A cet objectif, les déclencheurs ou triggers sont des opérateurs enregistrés dans
la structure de la base de données utiles pour lancer le traitement approprié en
réponse à un événement précis.

Par ailleurs, les SGBDR professionnels permettent de stocker du code avec la

structure de la base de données. Les procédures stockées sont habituellement
exécutées sur demande d’un poste client. Elles simplifient et rationalisent la
programmation en centralisant les traitements communs.

II.4.3.2. Gestion de la cohérence de la base de données

La cohérence de la base de données est la condition nécessaire pour son bon

fonctionnement et sa stabilité. De même, le maintien de la cohérence de la base
est un impératif pour la survie d’un système d’information. C’est qu’une base de
données ne doit jamais se trouver dans un état d’instabilité ou de lacunes de
données.

12
Il est préférable d’utiliser un ensemble de données qui n’est pas à jour, mais
cohérentes, plutôt que mises à jour et illogiques. Il arrive que la cohérence de la
base ne soit pas maintenue rien que par des transactions incomplètes ou
l’alimentation par des données non contrôlées.

II.4.3.3.Le Verrouillage de la base

Un système d’information ouvert à de nombreux usagés se sert d’une base de

données ouverte et accessible tout le temps en lecture et écriture. Ceci pourrait
provoquer des conflits entre les diverses opérations de lecture et d’écriture. Par
exemple, Imaginons la consultation d’une information en cours de modification
quelle version servirait-elle de réponse ?

Pour éviter les conflits d’accès sur une même ressource, les systèmes de SGBD
intègrent des fonctions de verrouillage. Dans tous les cas, les événements de
l’exemple suivant illustrent des cas de problèmes que peut avoir une base :

 Une tâche commence à écrire une liste de données,

 A tout moment, elle peut être interrompue par une autre tâche plus
prioritaire,
 La liste partiellement modifiée est alors incohérente,
 Elle est pourtant accessible et utilisable par des tâches plus prioritaires,
 Ou quelqu’un tente de supprimer un enregistrement quand quelqu’un
d’autre consulte…

En évitant les différents cas d’incohérence, les SGBDR optent par des
verrouillages comme première tâche. Ainsi, les données seront inaccessibles, tant
que la même tâche n’aura pas levé le verrou. De cette manière, la cohérence de la
base ne sera pas altérée par des accès portant sur les données en cours de
modification. Toutefois, le principe sécurisant du verrouillage peut conduire à des
situations de blocage tel que "verrou de la mort".

II.4.3.4. Le verrouillage de blocage/déblocage

Le système est dit inter-bloqué ou verrou mortel lorsque des tâches s’attendant
mutuellement. Il est en situation de verrou mortel (deadlock).

Dans un tel cas, la seule solution est de détruire une des deux tâches bloquante.
(Les systèmes professionnels prennent en charge cette gestion).

C’est une situation typique d’un traitement multitâche :

13
  Une tâche T1 a verrouillé pour son usage une ressource A, et attend le
déblocage d’une ressource B avant de poursuivre son exécution.
 Cette ressource B est elle-même bloquée par une tâche T2 qui attend
justement la libération de A avant de poursuivre son exécution.

Les SGBD modernes proposent des solutions préventives à la situation de blocage.

II.4.3.5. La gestion des Transactions

Une transaction est l’exécution d’une requête sur la base de données. Ainsi,
l’évolution de la transaction affecte significativement l’état de la base.
Evidemment si tout se passe bien, la base devrait passer d’un état stable à un
autre état stable. Si par contre, un évènement surgisse et perturbe la transaction,
la base pourrait se trouver dans un état instable et éventuellement l’incohérence
des données est forte probable.

Le SGBD doit garantir l’exécution de la transaction complète. Toutefois, des

évènements inattendus sont toujours possibles. Heureusement, la solution
prévue par le système est la suivante : S’il ne peut traiter en totalité la requête, il
reviendra à l’état stable antérieur. Il n’y aura pas d’exécution partielle non
maitrisée.

Même si une transaction consiste à l’exécution de plusieurs requêtes successives,

le système garantie l’exécution commune des requêtes et en cas de défaillance du
système, aucune requête ne sera exécutée. La base reste sur l’état cohérent
avant la transaction.

Les SGBD modernes proposent de regrouper l’ensemble des requêtes d’un même
lot en une unité insécable. Ainsi, la transaction complète sera garantie.

Le modèle ACID définit les règles des transactions pour garantir la cohérence des
bases de données :

 Atomicité : toutes les actions sont exécutées ou aucune (tous ou rien).

 Cohérence : la transaction doit placer le système en un état cohérent. Si ce
n’est pas possible, elle revient à l’état stable précédent.
 Isolation : les changements intermédiaires, apportés à la base par la
transaction en cours, ne sont pas vus par les autres transactions exécutées
en parallèle depuis d’autres tâches avant la validation (la consultation
n’atteint que l’état final).

14
  Durabilité : une fois validés, les changements apportés par la transaction
sont durables.

Prenons le cas d’une opération bancaire de débit/crédit :

 Pour conserver la cohérence de la base, la requête créditant le compte du

client A et la requête débitant le compte du client B doivent toutes les deux
s’exécuter complètement,
 Si jamais le système rencontre une défaillance entre les deux requêtes, et si
l’une ou les deux opérations (débit ou crédit) ne soient pas exécutées, la
base de données deviendra incohérente.

II.4.3.6. Quelques SGBDR

Plusieurs SGBDR sont disponibles soit en licence libre ou propriétaire. La

différence entre ses systèmes se mesure par leur portabilité et leur capacité à
gérer des données de petite/grande taille. Ci-après quelques SGBDR couramment
trouvés sur internet :

 MySQL, une référence des logiciels "libres" et open source,

 Oracle, la référence des SGBR Objet depuis la version 8,
 SQL Server, un produit phare de la gamme Microsoft entreprise,
 PostgreSQL, une solution libre de SGBDR Objet,
 Access, le produit SGBDR Microsoft de la gamme Office,
 IBM DB2, le produit de référence d'IBM en matière de SGBDR.

II.5.Conclusion

Les SGBDR évoluent dans le temps et leur technologie se développe

conjointement avec l’évolution de la demande et des moyens de calcul et de
communication. Actuellement, les SGBDR ont tendance à adopter la compatibilité
du cloud computing ou même du NoSQL. Dans tous les cas, la compréhension des
systèmes relationnels facilite grandement la migration vers les nouveaux
systèmes.

15
Sujets de réflexion :

Quelle serait la meilleure façon de conception des systèmes d’informations :

1. d’archivage multimédia : des photos, audio, vidéo ?

2. de discutions instantanées ?
3. de gestion d’une foire ouverte ?

N.B : les propositions doivent prendre en compte des critères tels que :

 les performances (temps de réponse, la quantité d’information, la facilité

d’usage, la fiabilité et l’originalité de l’information),
 la durabilité (peut servir des générations),
 la robustesse (connait peu de pannes)
 la disponibilité de l’information,
 la tolérance au pane externe (coupure d’électricité, manque d’espace de
stockage …)

16
 Chapitre III

La modélisation d’une base de données

Schéma 3.1 : les phases de modélisation d’une base de données

III.1. Généralités
L’importance de la base des données dans la structure globale d’un système
d’information est inestimable. Par conséquent, la conception de la base n’est pas
une tâche facile. Outre sa structure, la base doit répondre à une multitude
d’exigences professionnelles et techniques.
Parmi ces exigences, les données abritées dans la base doivent durer et persister
même si les technologies changent. De même, au cours du temps, le volume des
données augment en permanence. Ceci pourrait en principe dépasser les
capacités techniques disponibles.
Malgré tout, la base de données devrait fonctionner comme si aucune contrainte
n’est survenue !
La meilleurs façon pour garantir l’évolutivité seine de la base serait la mise en
place d’une structure optimale pour :
 Minimiser au maximum l’usage des ressources,
17
  Assurer la cohérence des données,
 Assurer la portabilité et la migration des données d’une génération
technologique à l’autre.
III.2. Modéliser une base de données
Avant de commencer, il faut se rappeler qu'il existe aujourd'hui deux grandes
catégories de bases de données :

 les bases de données compatibles SQL (anciennes mais toujours utiles),

 Les bases de données dites Non Seulement SQL (Not Only SQL). Cette
technologie, relativement récentes, conçoit des bases non relationnelles
comme celle du Big Data. Réellement, il n’existe pas de méthode standard
pour les modéliser. L’approche de modélisation diffère d’une catégorie à
l’autre.

A présent nous sommes intéressés par les modèles traditionnels compatibles avec
SQL. Dans la littérature, deux méthodes majeures sont utilisées en modélisation:

 La Méthode d'Etude et de Réalisation Informatique pour les Systèmes

d'Entreprise (MERISE).
 La méthode Unified Modeling Language, ou langage de modélisation unifié
(UML)

A présent, c’est MERISE qui nous intéresse.

III.3. Les étapes à suivre

La conception d’une base de données passe par plusieurs étapes. Dans aucun cas,
il n’est possible de sauter une étape. L’étape zéro du projet commence par
spécifier le métier ou la nature du système d’information. Naturellement, une
base est conçue pour servir une activité donnée.

L’équipe technique chargée de la mise en place de la base regroupe plusieurs

spécialités : des professionnels du métier, des analystes, des administrateurs
systèmes, des développeurs d’applications, des sociologues, des designers …
Comme le montre le schéma ci-dessous, les étapes de modélisation de la base
sont au fait des phases du projet et peuvent prendre plus au moins du temps,
tout dépond de la réactivité et la disponibilité des intervenants.

18
 Schéma 3.2 : étape de modélisation de la base de données

III.4. La collecte des données

La première étape de la modélisation d’une base de données commence par
collecter les données descriptives du système d’information à mettre en place.
Pour se faire, différentes approches sont nécessaires telles que les enquêtes de
terrain, les réunions de travail avec les intéressés… En revanche, les données
couvrent les volets suivants:
 Les objectifs à atteindre, les intervenants concernés, les différentes
relations, actions …
 La base de données elle-même,
 Les pratiques et savoir-faire métier,
 Les textes réglementaires,
 Les attentes des utilisateurs finaux.
Naturellement, les volets ci-dessus ne sont pas exhaustifs, ça se peut que d’autres
sources d’information soient nécessaires.
III.5. L’analyse des données collectées
Une fois collectées, les données doivent être analysées par les spécialistes pour
les classer en classe cohérentes. L’analyse se base sur des principes :
 Grouper les données selon leurs cohérences,
 Identifier les classes de données :
o Statiques,
o Dynamiques,
 Chercher la dépendance entres les classes,
 Définir les fréquences de variations entres les classes dépendantes,
 Identifier les différents traitements que les données subissent durant la
durée de vie du système d’information.
 …
19
III.6. La modélisation MERISE
La modélisation des données selon MERISE transforme les données en des
modèles de représentation abstraite des objets. Cette méthode propose plusieurs
types de modèle de données :
 Modèle conceptuel (MCD),
 Modèle logique (MLD),
 Modèle organisationnel ou traitement (MOD),
 Modèle physique (MPD).
La représentation des données peut être :
 hiérarchique,
 relationnelle,
 Entité-association,
 objet, ensembliste, etc.
Les deux modèles les plus utilisés actuellement sont :
 Le modèle entité-association : MEA (indépendant du type de SGBD
utilisé),
 Le modèle relationnel:MRD du niveau MLD(correspond aux SGBD-
R).
Ces deux modèles correspondent à 2 langages différents. Les schémas entité-
relation et les diagrammes de classe UML peuvent être utilisés comme autres
langages à peu près équivalents au MEA.
La méthode MERISE, utilisée quasi-exclusivement en BDR, distingue entre 3 types
de modèles selon des critères méthodologiques :
 le modèle conceptuel des données : MCD,
 le modèle logique des données : MLD
 le modèle physique des données : MPD.
L’usage tend à rendre équivalents les modèles par paire :
MCD <-> MEA, MLD <-> MRD, MPD <-> SQL.

Le MCD est du niveau de l’analyse fonctionnelle. Il est adapté à la maîtrise

d’ouvrage du niveau fonctionnel.

Le MLD est du niveau de l’analyse organique, il est adapté à la maîtrise d’œuvre

technique.
20
Le MPD est du niveau technologique, il est adapté au SGBD choisi.

III.7. Le Modèle Entité-Association (MEA)

L’analyse des données collectées abouti au premier modèle dit : Modèle Entités –
Associations (MEA). Il sert à la modélisation au niveau plus bas en se basant sur 3
concepts principaux:

 L'Entité : similaire à la notion d'objet, il décrit un objet, un concept. Par

exemple: un ordinateur, un client, un magasin ...
 Les propriétés: les éléments d’une entité décrivant un objet. Par exemple
pour l’ordinateur : le processeur, la mémoire, le type...
 L'association : est le lien logique ou fonctionnel qui relie les différentes
entités. (un ordinateur est acheté par un client).

Le modèle entité-association est équivalent à la représentation du dictionnaire de

données en une collection de
phrase « sujet verbe complément ».

Par exemple, dans le schéma ci-

coté :

 Un client habit à une ville

donnée.
 Un ordinateur est acheté par
un client.
 Un ordinateur est fabriqué par une Schéma 3.2 : Modèle Entité-Association (MEA)
société.

Le schéma ci-coté ne présente pas les cardinalités des associations.

Le modèle MEA est convertit par la suite en modèle relationnel (MRD). Le MRD
est normalisé selon les règles de MERISE pour donner le modèle conceptuel de
données (MCD).

III.8. le Modèle Conceptuel de Données (MCD)

A vrai dire, le modèle MEA n’est pas suffisant. Il offre le concept global de la base,
mais il lui manque certains détails. Par exemple, l’association {acheté par} lui
manque certaines informations telles que : la date d’achat, l’agent qui effectué la
vente, le prix de vente, la livraison …
21
Concrètement, le modèle MEA est complété par l’ajout des entités
complémentaires afin de combler le manque. Par exemple, l’association
{acheté par} est remplacée par une entité intermédiaire pour contenir les
propriétés de l’opération vente ou achat.

Ensuite, les différentes entités sont transformées en relations ou tables dont les
colonnes représentent les propriétés et les lignes représentent les objets. Quant
aux associations, elles sont remplacées par des relations de dépendances.

Le schéma à droite illustre un

exemple de la transformation du
modèle MEA du schéma 3.2 en un
modèle MCD. Ce qu’il faut retenir
c’est l’ajout de l’entité vente qui ne
figurait pas avant et le couple
(0..N) qui désigne la cardinalité des
relations de dépendance. En
général elle est de la forme (min,
max) telle que (0,1), (1,1), (0,N),
(1,N)… Schéma 3.3 : Modèle Conceptuel de données (MCD)

Avant d’expliquer davantage la cardinalité, examinons d’abord comment les

données seront stockées dans les tables par l’exemple suivant :

Schéma 3.4 : exemple de tables contenant des enregistrements

22
Les flèches illustrent la dépendance des données d’une table à l’autre. Cette
dépendance est réalisée par l’équivalence des identifiants des lignes dont le nom
de la colonne commence par « ID… ». La cardinalité représente l’occurrence de
part et d’autre de chaque flèche. Ainsi, on peut facilement comprendre qu’une
société peut fabriquer zéro ou plusieurs ordinateurs (0..N) etc…

III.8. Le Modèle Logique et le Modèle Relationnel de Données (MLD et MRD)

Comme indiqué dans le schéma 3.1, le MCD est le modèle abstrait indépendant
du modèle choisi pour les données non plus du SGBD. En revanche, le MLD
intègre les contraintes organisationnelles et logiques définies par Merise. Parmi
ces modèles nous utilisons le Modèle Relationnel des Données (MRD).

Sujet de réflexion : Elaborer les modèles MEA et MCD de la gestion d’une

bibliothèque publique.

23
 Chapitre IV
Le Modèle Relationnel des Données

IV.1. Généralités

Le modèle relationnel permet d’associer les outils mathématiques au modèle

précèdent pour modéliser les relations existantes entre les entités. Il repose
principalement sur les règles de Codd et les mathématiques des ensembles.

IV.2. Concepts de base

Le succès du modèle relationnel auprès des chercheurs, concepteurs et

utilisateurs, est dû à la puissance et à la simplicité de ses concepts. Il représente
les données par des tables, sans tenir en compte la façon dont le système SGBD
s’occupe de ces données. Les tables constituent donc la structure logique du
modèle relationnel.

En outre, contrairement à certains autres modèles, il repose sur des bases

théoriques solides, notamment :

 la théorie des ensembles,

 la logique des prédicats du premier ordre,
 la conception de base de données relationnelle,
 la théorie de normalisation des relations pour assurer la cohérence des
données.

IV.3. Les éléments du modèle relationnel

 Le modèle relationnel définie les différents éléments formant la structure
de la base de données comme suit :
 Attribut: Un attribut est un identificateur (un nom) décrivant une
information stockée dans une base. Exemples : le nom d'une personne, la
date de naissance. L’attribut est souvent appelé champ de la table.
 Domaine : Le domaine d'un attribut est l'ensemble, fini ou infini, de ses
valeurs possibles. Exemple : une valeur logique (0, 1); un pourcentage
(0..100) une probabilité (0..1).
 Relation (table): une relation est un sous-ensemble du produit cartésien de
n domaines d‘attributs (n > 0). Une relation est représentée sous la forme
d'un tableau à deux dimensions dans lequel les n attributs correspondent
aux titres des n colonnes. En pratique on parle de table au lieu de relation.
24
  Schéma de relation: un schéma de relation précise le nom de la relation
ainsi que la liste des attributs avec leurs domaines. (la description de la
table)
 Degré : Le degré d'une relation est son nombre d'attributs (le nombre de
champs ou de colonnes).
 Occurrence ou n-uplets ou tuples : Une occurrence est une ligne du
tableau qui représente la relation. Il est souvent appelé enregistrement.
 Cardinalité : La cardinalité d'une relation est son nombre d'occurrences ou
le nombre d’enregistrement.
 Clé candidate : Une clé candidate d'une relation est un ensemble minimal
des attributs de la relation dont les valeurs identifient exactement une
occurrence, couramment appelé « Identifiant ». La valeur d'une clé
candidate est donc distincte pour tous les tuples de la relation. La notion de
clé candidate est essentielle dans le modèle relationnel. Toute relation a au
moins une clé candidate et peut en avoir plusieurs.
 Clé primaire : La clé primaire d'une relation est une de ses clés candidates.
Pour signaler la clé primaire, ses attributs sont généralement soulignés.
 Clé étrangère : Une clé étrangère dans une relation est formée d'un ou
plusieurs attributs qui constituent une clé primaire dans d’autre relation.
 Schéma relationnel : Un schéma relationnel est constitué par l'ensemble
des schémas de relations.
 Base de données relationnelle : Une BDR est constituée par l'ensemble
des n-uplets des différentes relations du schéma relationnel.

IV.4. Le passage du modèle MCD au modèle relationnel

Bien que le passage du MCD en MLD/MRD reste plus au moins standard, il
nécessaire d’adapter certaine règle dont celle de la normalisation. La
normalisation devrait précéder le passage au modèle relationnel. Dans le cas où la
normalisation est à posteriori, elle devienne une surcharge importante de travail.

IV.4.1 Règles de passage : Entité -> Table (Relation)

Chaque entité devienne une table.

Chaque attribut de l’entité devient un champs (attribut) de la table (relation).

L'identifiant est conservé en tant que clé de la table.

25
IV.4.2 Règles de passage : Associations
Chaque association est transformée
en une jointure (relation) :

 de la clé de chacune des tables

participantes à l'association,
 des champs propres à
l'association, (dans le cas où
l’association se traduit par une
table : exemple stock pour les produit).

La clé de la jointure (relation) obtenue se déduit de l'analyse des cardinalités de

l''association.

IV.5. La Normalisation
L'objectif de la normalisation est de construire un schéma de base de données
cohérent. Un mauvais schéma logique conduire certainement à un certain
nombre d'anomalies pendant la phase d'exploitation de la base de données.

Pour qu’un modèle relationnel soit normalisé, il faut qu’il respecte certaines
contraintes appelées les formes normales. Ces formes s’appuient sur les
dépendances fonctionnelles entre les attributs.

Les anomalies de fonctionnement de la base de données liées à la normalisation

sont nombreuses, on peut citer :

 L’incohérence de données : le système d’information fourni parfois des

données non cohérentes ou illogiques, (problème de format ; numérique;
date …) et éventuellement des références incorrectes (par exemple affecter
une note à un autre étudiant, affecter un étudiant à une filière qui n’est pas
la sienne …),
 Perte d’information : le système d’information se trouve dans l’incapacité
de conserver certaines données, (résultat calculé par exemple),
 Stagnation de la base de données : la base ne peut pas évoluer ; apparition
de nouvelles gammes de données … par exemple changement des modules
d’une filière)

26
IV.5.2 Le processus de normalisation
Le processus de normalisation consiste à remplacer une relation donnée (une
table) par certaines projections afin que la jointure de ces projections permette
de retrouver la relation initiale.

En d'autres termes, le processus est réversible (sans perte d'information).

L’exemple à coté illustre la différence claire entre une relation (table cursus de
l’étudiant) non normalisée et les deux autres (Etudiants et Cursus de l’étudiant)
qui sont normalisée.

IV.5.3. Hiérarchie de normalisation

La normalisation a plusieurs formes (1.. 5) classées par ordre hiérarchique :

Schéma 4.1 Hiérarchie de la normalisation

La 1ère forme de normalisation est la base de toutes les autres formes d’ordre
supérieur. Dans ce sens, la 2ème est forcément d’ordre 1, la 3ème est forcément
d’ordre 1 et 2 … alors que la 1ère n’est pas forcément d’ordre 2…

Il existe des méthodes systématiques pour normaliser une relation à chaque

niveau des formes normales.

IV.5.4 Les pratiques de normalisation

Il est préférable d’aborder la normalisation au moment de la conception du
modèle entités-associations. Dans ce cas, il n'est pas nécessaire de la
recommencer sur le modèle relationnel. Il serait suffisant de vérifier l’état de
normalisation du modèle relationnel. En pratique, la normalisation se base sur les
notions :

 dépendance fonctionnelle,
 dépendance multivaluée (exemple adresse = {numero, rue, av. , ville …} )
 dépendance de jointure.

27
Les notions : dépendance fonctionnelle, dépendance multivaluée et
dépendance de jointure sont des notions sémantiques (significations). Elles
acquirent leurs origines des contraintes du monde réel. Comme ces contraintes
participent à la sémantique de la situation, elles doivent avoir une manifestation
dans la base de données.

Les dépendances doivent donc être spécifiées dans la définition de la base de

données afin que le SGBD puisse les appliquer. Les concepts de normalisation
fournissent en fait un moyen indirect pour déclarer ces dépendances.

La dépendance fonctionnelle permet de définir les premières formes normales

jusqu'à la forme normale de Boyce-Codd (1FN, 2FN, 3FN et BCNF).

La dépendance multivaluée permet de définir la quatrième forme normale (4FN)

et la dépendance de jointure la cinquième forme normale (5FN).

Le but des dépendances fonctionnelles et de la théorie de la normalisation est de

s'assurer que le schéma relationnel défini pour une base de données est
correctement construit. Analysons la table suivante :

Table 4.1 : Information redondante

Les informations concernant la filière et le module sont redondantes. De même,

s'il faut changer la filière il faut s’assurer des modules qui la constituent.

IV.5.4.1 Première forme normale (1FN)

Une relation est en 1ère forme normale si tous ses attributs ont une valeur
atomique c’est-à-dire sur leur forme la plus réduite. Par exemple, l’adresse d’une
personne : Adresse=« N° 3, rue 24 avenue la renaissance, rabat ». Cette information est
correcte mais elle n’est plus atomique. Car, c’est un assemblage d’autre
information : indépendantes. Adresse = {Numéro, rue, avenue, ville }. Chaque élément
de cet ensemble est une information atomique.

Dans le modèle relationnel, les domaines sont atomiques par principe. Ceci
implique que toutes les relations sont nécessairement en 1ère forme normale. La
table suivante ne respecte pas la 1ère forme Normale.

Table 4.2 : Semestres est une information qui n’est pas atomique
28
Dans la table ci-dessus, on ne peut pas sélectionner les semestres
indépendamment l’un de l’autre. Pour satisfaire ce critère, on peut représenter la
table 4.2 comme suit :

Table 4.2 : Information atomique d’où 1FN

De cette manière on peut sélectionner les semestres indépendamment l’un de

l’autre. Ainsi, la table 4.2 respecte bien la norme 1FN.

IV.5.4.2. 2ème forme normale (2FN)

Une relation est en 2ème forme normale si elle est en 1ère forme normale et si
chaque attribut non-clé dépend totalement et non partiellement de la clé
primaire. Par exemple, à partir de l’identité d’un étudiant définie par {CNE/MASAR,
NOM, PRENOM, DATE NAISSANCE, BAC …. } , le nom, le prénom et la date de naissance
dépendent complètement du CNE/MASAR, alors le bac non. Car plusieurs
étudiants peuvent avoir le même bac.

Table 4.3 : Table qui est de la forme 1FN mais elle ne respecte pas (2FN)

La table ci-dessus ne respecte pas 2FN car, les attributs BAC, LN, INSCRIPTION ne sont
pas des clés mais ils ne dépendent pas uniquement du CNE/MASAR de l’étudiant.
Pour rendre la table 4.3 compatible 2FN, procède par la scinder comme suit :

Table 4.4 : Tables qui sont de la forme 1FN et respectent pas (2FN)

29
IV.5.4.3. 3ème forme normale (3FN)

Définition :

Une relation est en troisième forme normale si, et seulement si :

 elle est en deuxième forme normale (2FN),

 tout attribut n'appartenant pas à une clé candidate n'est pas en
dépendance fonctionnelle directe avec d’autres attributs non-clé.

Prenons le cas suivant :

Table 4.3 : Table compatible (3FN)

Nous pouvons dire facilement que les deux attributs NOM et PRENOM ne sont
pas des clés et par conséquent : le NOM ne dépend pas du PRENOM et le
PRENOM ne dépend pas du NOM. Dans cette table nous pouvons rencontrer
plusieurs noms mais de prénoms différents. Inversement, il est facile d’admettre
que pour le même prénom on peut rencontrer plusieurs noms. Par contre, les
noms et les prénoms dépendent vivement des valeurs de chacune des clés. De
même, les deux attributs de la clé candidate dépend l’un de l’autre. On ne peut
pas trouver un CNE pour un autre CIN, l’inverse est aussi vrai.

Table 4.4 : Table non compatible (3FN)

Les attributs de la table (Nom, Prénom, Note, Résultat) sont dépendants l’un de l’autres
même-si ils ne font pas partie de la clé candidate. Il est pratiquement rare de
rencontrer une telle combinaison répétée. De même, si nous espérons
représenter le cursus complet de l’étudiant, surtout pour celui doit passer un
rattrapage, on doit écraser la note 5 pour la remplacer par la nouvelle note de
rattrapage. Pour résoudre ce problème, la table ci-dessus doit être scindée en
deux autres comme suit :

30
 Table 4.5 : Tables compatibles (3FN)

IV.5.4.4. Forme normale de BOYCE-CODD

Définition :

Une relation est en forme normale de Boyce-Codd (BCNF) si, et seulement si, les
seules dépendances fonctionnelles élémentaires sont celles dans lesquelles une
clé détermine un attribut non-clé.

Cette forme normale permet de renforcer certaines lacunes de la troisième forme

normale. Dans la pratique, la plupart des problèmes de conception peuvent être
résolus en appliquant les concepts de troisième forme normale et de forme
normale de BOYCE-CODD. Les quatrième, cinquième et sixième formes normales
traitent encore d'autres cas de redondance, mais qui ne sont pas expliqués par
des dépendances fonctionnelles. Le problème de conception d’analyse se
complique davantage quand on introduit les contraintes fonctionnelles liées au
métier et dans ce cas, il faut appliquer dans la nécessité les formes de
normalisation d’ordre supérieur.

Sujet de réflexion : Développez le modèle relationnel de la base de données

d’une bibliothèque publique.

31
 Chapitre V

L’Algèbre Relationnelle

V.1. Généralités

L'algèbre relationnelle est un support mathématique cohérent sur lequel repose

le modèle relationnel. Elle fournit le langage abstrait, avec des opérations sur une
(ou plusieurs) relation(s) et produisent de nouvelle relation sans changer les
originales. Le résultat de toute opération est une relation (propriété de
fermeture). L'approche suivie est donc plus opérationnelle que mathématique.

Ri

Opérateur Rk

Rj
Relation de fermeture

L’algèbre relationnelle se compose d’un ensemble d’opérateurs, parmi lesquels 6

sont nécessaires et suffisants, les autres sont obtenues par composition. Un
opérateur prend une ou deux relations en entrée, et produit une relation en
sortie. Ces opérateurs sont :

 La sélection, dénotée : 
 La projection, dénotée : 
 Le renommage, dénoté : 
 Le produit cartésien, dénoté : 
 L’union : 
 La différence : 

A partir des opérateurs élémentaire, on peut construire des expressions

algébriques très complexes, capable d’effectuer toutes les requêtes nécessaires à
l’aide d’un petit nombre d’opérations de base.

V.1. Familles d’opérateurs relationnels

Les opérateurs sont groupés par famille. Ainsi, ils sont présentés comme suit :

 Les opérateurs unaires (Sélection, Projection) : ce sont les opérateurs les

plus simples, ils permettent la production de nouvelle table à partir d'une
autre table.

32
  Les opérateurs binaires ensemblistes (Union, Intersection Différence) : ces
opérateurs permettent de produire une nouvelle relation à partir de deux
relations de même degré et de même domaine.
 Les opérateurs binaires ou n-aires (Produit cartésien, Jointure, Division) :
ils permettent de produire une nouvelle table à partir de deux ou plusieurs
autres tables.

V.2. La sélection : σ

La sélection ou la restriction génère une nouvelle relation regroupant les

occurrences d’une relation existante R qui satisfont l'expression logique E. On la
note σ(E)R équivalente à σ(A  a)R.

Dans la pratique la sélection se fait soit par la comparaison entre un attribut A

de la relation et une constante a, où  est l’un des opérateurs de ,,,,.

La comparaison peut être également entre deux attributs A1 et A2, qui s’écrit A1
 A2 avec les mêmes opérateurs de comparaison que précédemment.

Exemple: σ(note≥10)Etudiant signifie la sélection des étudiants dont la note est

≥10

V.3. La projection : 

La projection 1,A2,…,Ak)(R) s’applique à une relation R, et construit une

relation contenant tous le contenu de R restreint aux attributs 1,A2,…,Ak.

La projection suivante construit une

relation avec le nom, la note de la
table exemple « Etudiants »:
Nom, Note)(R)

33
V.4. Le produit cartésien : 

Le premier opérateur binaire, et le plus utilisé, est le produit cartésien noté  . Le

produit cartésien entre deux relations R1 et R2 se note R1  R2 . Le résultat de
ce produit est une nouvelle relation R3 où chaque nuplet de R1 est associé à
chaque nuplet de R2 .

V.5. La Différence : 
La différence porte sur deux relations R1 et
R2 ayant le même schéma et construisant
une troisième relation R3 dont les nuplets
sont constitués de ceux qui se trouvent dans
R1 et pas dans R2. On la note R − R . C’est
une opération binaire ensembliste non commutative dont la signature est :
relation - relation → relation
V.6. L’union : 
Il existe deux autres opérateurs binaires, qui
sont à la fois plus simples et moins
fréquemment utilisés.
Le premier est l’union. L’expression R1  R2
crée une relation comprenant tous les nuplets existant dans l’une ou l’autre des
relations R1 et R2. Il existe une condition impérative : les deux relations doivent
avoir le même schéma, c’est-à-dire même nombre d’attributs, mêmes noms et
mêmes types.
V.7 L’Intersection : 
L'intersection est une opération portant
sur deux relations R1 et R2 ayant le même
schéma et construit une troisième relation
dont les nuplets sont constitués de ceux
appartenant en même temps aux deux
34
relations, on la note R1 ∩ R2 .
Il s'agit une opération binaire ensembliste commutative dont la signature est :
relation1 ∩ relation2 → relation3
R1 et R2 et le résultat de l'intersection R3 ont les mêmes attributs.
V.8. Les opérateurs de jointure ▷◁
Toutes les requêtes exprimables avec l’algèbre relationnelle peuvent se
construire avec les 6 opérateurs présentés ci-dessus. En pratique, les requêtes les
plus complexes s’obtiennent la composition des opérations de base. Par exemple,
la jointure consiste à faire une sélection sur un produit cartésien entre deux
relations.
La jointure porte sur deux relations R1 et R2
dont le résultat est une relation R3 dont les
occurrences sont ceux qui satisfont
l'expression logique E. Elle se note R1 ▷◁E
R2
 Si R1 ou R2 ou les deux sont vides, la
relation qui résulte de la jointure est vide.
 La jointure peut être le produit cartésien des deux relations suivies d'une
sélection conditionné : R1 ▷◁E R2 = σE (R1 × R2 )
V.8. 1. La jointure dite « naturelle »
Elle s’applique uniquement quand les attributs de jointure ont des noms
identiques dans les deux tables. La jointure naturelle s’effectue alors
automatiquement sur l’attribut commun. Alors elle ne conserve que l’un des
attributs dans le résultat, ce qui élimine l’ambiguïté. La syntaxe est très simple.
V.8.2. Thêta-jointure ou Équijointure
Une équijointure est une thêta-jointure dans laquelle l'expression logique E est un
test d'égalité entre un attribut A1 de la relation R1 et un attribut A2 de la relation
R2. Elle se note R1 ▷◁A1 ,A2 R2
Dans la pratique, il vaut mieux écrire R1 ▷◁A1 =A2 R2 au lieu R1 ▷◁A1 ,A2 R2.
Ceci permet de comprendre que l’Attribut A2 de R2 peut être différent de A1 et
élimine toute confusion avec une jointure naturelle explicite.
V.9. Les Opérateurs logiques « ET /OU» « AND /OR»
35
Les conditions de jointures peuvent êtres multiples. Cependant, on peut
construire une seule expression de sélection par combinaison de plusieurs
jointures à l’aide des opérateurs logiques ET/OU.

Sujet de réflexion :

Reprenons la base de données de la gestion d’une bibliothèque publique, donnez

l’expression des opérations logiques pour :

1. Lister l’ensemble le contenus de la relation des ouvrages,

2. Lister les différents ouvrages avec leur code isbn,
3. Lister les ouvrages avec leurs auteurs et éditeurs…

36
 Chapitre VI

Le langage SQL

VI.1. Généralités

L’invention du premier langage de communication avec les bases de données

relationnelles date de 1977. Ce langage s’appelé SEQUEL (Structured English
Query Language).

Par la suite, le langage SQL (Structured Query Language) remplace son ancêtre est
devient le langage standard d'accès aux bases de données relationnelles. Depuis
son apparition en 1986, le langage SQL a fait l'objet de plusieurs versions de
normalisation : ANSI/ISO.

SQL propose des instructions de requêtes ensemblistes et n’est pas un langage

de programmation : entrées/sorties, instructions conditionnelles, boucles et
affectations. Il offre en revanche des fonctions pour traiter différentes sortes de
données (date, chaine de caractère, …). Ses instructions opèrent sur des tables
des bases de données par des requêtes dont le résultat peut produire de
nouvelles tables.

VI.2. Historique de SQL

 SQL-86 ou SQL-87 : ANSI / ISO en 1987.

 SQL-92 / SQL2 : 1992, Révision majeure.
 SQL-99 / SQL3 : 1999,
o Expressions rationnelles,
o Requêtes récursives,
o Déclencheurs,
o Types non-scalaires et quelques fonctions orientées objet.
 SQL:2003 :
o Introduction des fonctions pour la manipulation XML,
o « window functions »,
o ordres standardisés et colonnes avec valeurs auto-produites.
 SQL: 2008 :
o Ajout de quelques fonctions de fenêtrage (ntile, lead, lag, first value, last
value, nth value),
o Limitation du nombre de lignes (OFFSET / FETCH),

37
 o Amélioration mineure sur les types distincts, curseurs et mécanismes
d'auto-incrémentation.
 SQL:2011 :
o Ajout du support des tables temporelles (historisation automatique).
o Le langage SQL est simple à utiliser, il s’apuit sur le schéma conceptuel
pour construire les requêtes indépendamment des SGBD.
o Il est toujours adopté par la plupart des SGBD.

VI.3. Les instructions du langage SQL

Les instructions SQL sont regroupées en catégories selon leurs fonctionnalités. En

standard, on distingue cinq :

1. Langage de Définition des Données (LDD): la définition des éléments d'une

base de données (tables, colonnes, clés, index, contraintes…),
2. Langage de Manipulation de Données (LMD): la manipulation des données
(insertion, suppression, modification, extraction…),
3. Langage de Contrôle de Données (LCD) : la gestion des droits d'accès aux
données (acquisition et révocation des droits),
4. Langage de Contrôle des Transactions (LCT) : la gestion des transactions,
5. le SQL intégré.

VI.3.1. Langage de définition de données (LDD)

Le langage de définition de données (LDD), est utilisé pour manipuler la structure

de la base de données. Il offre toutes les instructions pour :

o créer, modifier, supprimer des objets et définir leur domaine des données,
o ajouter des contraintes de valeur sur les données.
o autorise ou interdit l'accès aux données,
o activer ou désactiver l'audit pour un utilisateur.

Les instructions du LDD sont :

CREATE, ALTER, DROP, AUDIT, NOAUDIT, ANALYZE, RENAME, TRUNCATE.

VI.3.2.Langage de manipulation de données (LMD)

Le langage de manipulation de données (LMD) est l'ensemble des commandes

destinées à la manipulation des données. Il agit sur le contenu des tables et
permet :

38
  L'ajout, la suppression et la modification des données,
 L’extraction et la visualisation des données,
 Le verrouillage/deverrouillage des tables.

Ces opérations nécessitent la validation par transaction pour qu'ils soient pris en
compte. Les instructions du LMD sont :

INSERT, UPDATE, DELETE, SELECT, EXPLAIN, PLAN, LOCK TABLE.

VI.3.3. Langage de contrôle de données (LCD/DCL)

Le langage de contrôle d'accès LCD gère les droits d'accès aux données. Ses
instructions sont :

GRANT, REVOKE.

Il comprend la gestion des utilisateurs, les droits d'utilisation des tables et la

gestion des transactions. Un créateur possède tous les droits sur son élément
crée. Il peut également déléguer ses droits à d'autres utilisateurs. La syntaxe
globale de l’instruction :

GRANT <privilège> ON <table> TO <utilisateur> [WITH GRANT OPTION];

Exemple : GRANT SELECT ON Table TO utilisateur

VI.3.4. Langage de contrôle de transaction LCT/TCL

Le langage de contrôle de transaction ou TCL (Transaction Control Language) gère

les modifications faites par le LMD, c'est-à-dire les caractéristiques des
transactions et la validation et l'annulation des modifications. Les instructions du
TCL sont :

COMMIT, SAVEPOINT, ROLLBACK, SET TRANSACTION

VI.3.5. SQL intégré

Le SQL intégré (Embedded SQL) permet d'utiliser SQL dans un langage de

troisième génération (C, Java, Cobol, etc.). Il permet :

 La déclaration d'objets ou d'instructions ;

 L’exécution d'instructions ;
 La gestion des variables et des curseurs ;
 Le traitement des erreurs.

39
Les instructions du SQL intégré sont :

DECLARE, TYPE, DESCRIBE, VAR, CONNECT, PREPARE, EXECUTE, OPEN,

FETCH, CLOSE, WHENEVER.

VI.4. SQL Pratique

Dans la pratique, il est tout à fait normal de suivre une démarche logique de la
manipulation des données dans une base. La première étape consiste à créer les
tables de la base. Eventuellement, les fonctions et les procédures stockées ainsi
que la configuration des trigger. Bien que ceci relève d’une phase avancée
d’utilisation des SGBD, la création des tables, y compris les différentes contraintes
d’intégrités, peut se faire en un seul scripte.

VI.4.1. Créer une table : CREATE TABLE

La création la plus simple d’une table est définie selon la syntaxe suivante :

CREATE TABLE nom_table (nom_col1 TYPE1, nom_col2 TYPE2, ...)

Ensuite, il faut définir les contraintes liées à la table comme celle de l’intégrité
révérencielle ou les trigger. On peut également créer une table et la remplir avec
des données provenant du résultat d'une sélection avec SELECT : CREATE TABLE
nom_table [(nom_col1, nom_col2, ...)] AS SELECT ...

Les colonnes des tables peuvent subir différentes contraintes que l'on peut
déclarer dans la structure de la table. Ces contraintes sont les suivantes :

 NOT NULL ou NULL.

 UNIQUE ,
 PRIMARY KEY (== UNIQUE NOT NULL),
 REFERENCES table [(colonne)] [ON DELETE CASCADE],
 CHECK (condition à vérifier lors de l’insertion) :
 DEFAULT valeur .

De même, les tables elles même peuvent avoir des contraintes qu’on peut
déclarer comme suit :

 PRIMARY KEY (colonne…),

 UNIQUE (colonne…),
 FOREIGN KEY (colonne…) REFERENCES table *(colonne…)+ *ON DELETE
CASCADE | SET NULL],
40
  CHECK (condition consternant la vérification des attributs pour la ligne ).

Les contraintes sont créer au moment de la création de la table. Mai il est possible
d’en ajouter, supprimer ou modifier par la suite. L’ajout d’une contrainte de
colonne est :

ALTER TABLE nom_table {ADD/MODIFY} ([nom_colonne type [contrainte], ...])

L’ajout d'une contrainte de table :

ALTER TABLE nom_table ADD [CONSTRAINT nom_contrainte] contrainte

VI.4.2. Ajout de nouvelles données à une table (INSERT)

La commande INSERT permet d'insérer une ligne dans une table en spécifiant les
valeurs à insérer. La syntaxe est la suivante :

INSERT INTO nom_table(nom_col_1, nom_col_2, ...) VALUES (val_1, val_2, ...)

Les colonnes de la table qui ne figurant pas dans la liste auront la valeur NULL. La
liste des colonnes par défaut est l'ensemble des colonnes de la table. Il est
possible d'insérer dans une table des lignes provenant d'une autre table grâce à
l’instruction SELECT.

INSERT INTO nom_table(nom_col1, nom_col2, ...) SELECT ...

VI.4.3. Modification des données existantes d’une table (UPDATE)

La commande UPDATE permet de modifier les valeurs des colonnes d’une table
dans plusieurs colonnes en une ou plusieurs lignes. La syntaxe est la suivante :

UPDATE nom_table
SET nom_col_1 = {expression_1 | ( SELECT ...) },
nom_col_2 = {expression_2 | ( SELECT ...) },
...
nom_col_n = {expression_n | ( SELECT ...) }
WHERE condition
Les valeurs sont modifiées dans toutes les lignes qui satisfont la condition. S’il y a
pas de condition alors toutes les lignes seront modifiées.

VI.4.4. Suppression des lignes d’une table ( DELETE)

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

DELETE FROM nom_table WHERE condition

Les lignes supprimées correspondent à celles dont la condition est vérifiée. En

l'absence de clause WHERE, toutes les lignes de la table sont supprimées.

VI.4.5 Lecture des données d’une table (SELECT)

L’instruction la plus courante de SQL consiste à lire des données depuis la base de
données. L’instruction SELECT retourne des enregistrements depuis une ou
plusieurs tables et les renvois sous forme d’une nouvelle table. L’instruction peut
également sélectionner une ou plusieurs colonnes d’une ou de plusieurs tables.

 SELECT * FROM table,

 SELECT champ1, champ2, … FROM table,
 SELECT champ1, champ2, … FROM table WHERE condition

Globalement, l’instruction SELECT dispose de plusieurs options comme le montre

la structure de la requête suivante :

SELECT * FROM table

WHERE condition
GROUP BY expression
HAVING condition
{ UNION | INTERSECT | EXCEPT }
ORDER BY expression
LIMIT count
OFFSET start

WHERE condition:
La condition de la clause SELECT peut être simple ou complexe selon la portée des
données recherchées en utilisant des opérateurs logiques (AND & OR) :

 condition
 condition 1 AND condition 2
 condition 1 AND (condition 2 OR condition 3)
 IN : nom_colonne IN ( valeur1, valeur2, valeur3, ... )
 BETWEEN : nom_colonne BETWEEN ‘min' AND ‘max'
42
  LIKE : colonne LIKE modèle

Où modèle désigne une chaine de caractère pour spécifié le mode de recherche

comme “a%” pour chercher toutes les données qui commences par “a”,

GROUP BY expression :
La commande GROUP BY est utilisée en SQL pour grouper plusieurs résultats et
utiliser une fonction de calcul de total sur un groupe de résultat. Par exemple, sur
la table qui contient toutes les notes d’un semestre d’un étudiant, il est par
exemple possible de calculer le total des notes du semestre d’un étudiant comme
suit :

SELECT semestre, SUM(note_module) FROM tableNotes GROUP BY semestre

De même, la moyenne du semestre par étudiant est :

SELECT semestre, AVG(note_module) FROM tableNotes GROUP BY semestre

HAVING condition:

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()

{ UNION | INTERSECT | EXCEPT }

La commande UNION de SQL permet de concaténer les résultats de 2 requêtes ou

plus. Il est nécessaire que chacune des requêtes à concaténer retournes :

 le même nombre de colonnes,

 les mêmes types de données
 le même ordre.

SELECT * FROM table1 UNION SELECT * FROM table2

La commande SQL INTERSECT permet d’obtenir l’intersection des résultats de 2

requêtes. Elle récupère les enregistrements communs à 2 requêtes. Ceci élimine
les données similaires sur les deux tables distinctes. Il faut également que les 2
requêtes retournent le même nombre de colonnes, avec les mêmes types et dans
le même ordre.

43
 SELECT * FROM table1 INTERSECT SELECT * FROM table2

La clause EXCEPT ou MINUS s’utilise entre 2 requêtes pour récupérer les

enregistrements de la première qui ne figurent pas dans les résultats de la
seconde. Si un même enregistrement appartient aux résultats des 2 requêtes, il
sera éliminé. Cette clause s’appelle différemment selon les SGBD :

 EXCEPT : PostgreSQL
 MINUS : MySQL et Oracle

ORDER BY expression:
La clause ORDER BY permet de trier les enregistrements du résultat d’une
requête. Il est possible de trier les données sur une ou plusieurs colonnes, par
ordre ascendant ou descendant.

SELECT colonne1, colonne2, colonne3 …

FROM table
ORDER BY colonne1 DESC, colonne2 ASC

LIMIT count
La clause LIMIT limite le nombre maximum de résultats que l’on souhaite obtenir.
Ceci permet d’effectuer la pagination des résultats. La syntaxe dépend des SGBD.
Par exemple, cette requête sélectionne au plus 25 lignes.

SELECT * FROM table LIMIT 25

OFFSET start
L’offset est une clause pour délimiter les lignes à obtenir. Il définit le décalage à
partir du début, qui est l’offset par défaut. La syntaxe pour utiliser une limite et
un offset est la suivante :

SELECT * FROM table LIMIT n OFFSET m

Cette requête permet de récupérer les n enregistrements à partir de la position

m+1.

44