Bases de Données 3 LMD Informatique

Module BDD : Introduction aux BDD Mme H.
CHELLAKH
Introduction aux bases de données

I. Introduction :
De nos jours les entreprises manipulent un volume important d’informations. Poussées
par un souci d’amélioration continuelle de leurs performances, ces entreprises doivent penser
à une manière efficace de sauvegarder, rechercher et mettre à jour l’information qu’elles
manipulent.
Les systèmes classiques de gestion de fichiers (SGF) s’avèrent limités lorsqu’il s’agit
de manipuler une masse importante de données comportant des liens entre elles. Ces données
souvent réparties entre différents fichiers avec énormément de redondances dans leur
représentation.
En effet, chaque application dispose de ses propres fichiers et de ses propres
programmes qui doivent maintenir la cohérence des données manipulées.
En plus, les organisations des données sur disque, offerts par les SGF n’autorisent
souvent l’accès que par le biais de la clé des enregistrements. Une recherche basée sur un
autre critère nécessite un effort supplémentaire de programmation.
Pour pallier ces insuffisances, la notion de base de données (BD) est apparue. Celle-ci
est une collection de données cohérentes, non redondantes (ou peu redondante), structurées
indépendamment de l’application qui les manipule. Le système qui doit gérer une DB est
appelé Système de Gestion de Base de Données (SGBD), c’est un logiciel qui permet aux
utilisateurs de définir, créer et maintenir une BD et qui fournit un accès contrôlé au données.
2. Système d’information et gestion des données :

Afin de bien fixer les idées, prenons l’exemple de la gestion d’une scolarité. Les
données disponibles dans tel environnement, concernent les enseignants, les étudiants, les
modules enseignés, les notes obtenues, …etc.
La direction de la scolarité envisage, l’exploitation de l’outil informatique, pour une
gestion efficace de ces données. Pour cela les données doivent être stockées sur un support
informatique (mémoire secondaire), pour être ensuite sujettes à des traitements automatisés
(calcul des moyennes, édition de la liste des étudiants admis, calculs statistiques…etc.)
La tâche est confiée à un jeune programmeur, qui fait le raisonnement suivant :
1- les données doivent être stockées dans un ou plusieurs fichiers d’enregistrements.
2- La structure des enregistrements doit permettre de représenter les informations à
stocker : par exemple on pourrait avoir un fichier pour les notes des étudiants où les
enregistrements seraient structurés plus ou moins comme suit :
Record of
Matricule : string [8] ;
Nom, Prénom : string [30] ;
Note1, Note2, Note3 : real ;
End ;
Il serait alors possible d’alimenter le fichier décrit, par des données respectant cette structure:
0211 Belhocine Samir 10 12 14 12 0512 Ameur Fateh 9 7 7 8.33
Notre programmeur devra par la suite écrire des programmes, qui exploitent les
fichiers, (dont il connaît la structure), pour automatiser les traitements voulus.
Bien que cette réflexion ait des chances d’aboutir à une solution provisoire, elle ne risque pas
de donner lieu à une automatisation durable, et efficace.
Les reproches qui pourraient être faits :
www.etudpdf.com
Module BDD : Introduction aux BDD Mme H.CHELLAKH
1- Comment définir de façon claire et efficace, les structures des fichiers, en évitant les
redondances, et les incohérences.
2- La solution proposée, ne peut résister, ou s’adapter facilement à un changement, par
exemple rajouter une quatrième note.
3- L’ajout, la suppression, et la modification d’enregistrements, ainsi que les contrôles de
saisie, devront être programmés explicitement, et influeront sur le temps d’accès, aux
données.
4- En cas de démission de notre jeune programmeur, il sera difficile à son remplaçant de
maintenir l’application, sans avoir une connaissance complète des détails
d’implémentation.
En résumé, une application solide de gestion, ne peut être le résultat d’un bricolage, même
si elle est l’œuvre d’un programmeur de génie. En fait il faut remarquer, que certains des
inconvénients, que nous reprochons à la solution précédente, sont dus à l’absence d’une
démarche de conception claire, et décidable. Alors que d’autres sont liés aux limites du
système de gestion de fichiers (SGF), qui n’offre pas des techniques spécifiques à une telle
application.
2.1 Pourquoi une démarche de conception ?

La complexité des systèmes d’information, ne peut être dépassée, qu’à travers une
démarche, claire, efficace, qu’un concepteur devrait suivre pour aboutir à une solution
standard et cohérente.
La conception est une étape préalable à la programmation. Elle consiste à définir
l’ensemble des éléments, et des liens qui les relient. Dans notre exemple précédent, il s’agit de
proposer une représentation, des intervenants dans la scolarité : les étudiants, les enseignants,
les modules, les salles d’enseignement,…etc. ainsi que des liens entre eux : quel enseignant
assure quel module ? …etc.
Pour représenter cette réalité un concepteur doit s’appuyer sur une démarche, et un
modèle conceptuel, qui en résulte.
Plusieurs modèles ont été proposés, dans le cas des systèmes d’information. Parmi
lesquels nous citons : le modèle hiérarchique, le modèle réseau, le modèle relationnel et plus
récemment le modèle orienté objet.
Parmi ces modèles, le modèle relationnel, est celui qui a eu le plus de succès,
notamment sur le plan commercial. Alliant à la fois, simplicité et richesse d’expression, et se
basant sur des fondements mathématiques solides, il est à la base de la majorité des systèmes
d’information.
2. 2 Limites des SGF :

Les systèmes de fichiers informatisés ont un certain nombre de problèmes :
1. Redondance des données :
La répétition en différents endroits de données identiques pose de difficiles problèmes lors
des mises à jour ; chaque modification doit être répercutée sur toutes les occurrences de
l’objet concerné. Par exemple, le changement de nom d’un employé doit être effectué aussi
bien au service du personnel qu’à la comptabilité, etc.
Les effets de la redondance :
 Les coûts de stockage sont augmentés.
 De multiples mises à jour doivent être effectuées pour actualiser les différents
fichiers.
 Peut mener à une incohérence de données.
 Rend les normes difficiles à appliquer.
www.etudpdf.com
2. Incohérence des données :

Des liens sémantiques existent très souvent entre les données : le poste d’un employé,
figurant dans le fichier du service du personnel, n’est pas sans rapport avec le salaire qui lui
est versé par la comptabilité. Pourtant la modification de l’un n’entraîne pas automatiquement
celle de l’autre. Des incohérences apparaissent trop fréquemment du fait de la difficulté et du
coût qu’implique le contrôle de « contraintes d’intégrité » liant les données entre elles.
3. Manque de normalisation :
Que se passent t-il lorsque l’on change de système d’exploitation ou de support de
stockage ? Dans la plupart des cas, les applications développées sont si fortement liées aux
possibilités propres du système et du gestionnaire de fichiers qu’il est parfois aussi difficile de
les actualiser que de les réécrire entièrement. Si la normalisation des langages de
programmation est de plus en plus fréquente, les accès aux fichiers dépendent la plupart du
temps de la machine ; le manque de séparation entre le code de l’interface et celui du
traitement des données interdit de faire une simple modification du code.
4. Problème de sécurité :
Garantir de la sécurité physique de l’information est une des tâches de base d’un système
informatique. Qu’arrive t-il si une panne interrompt un programme augmentant tous les
salaires de 3% ? Combien de modifications ont été prises en compte : où reprendre le travail ?
La présence de la même information en plusieurs exemplaires n’est évidemment pas de nature
à faciliter la tâche du SGBD et des programmes de reprise après panne. De même, la
confidentialité de l’information est plus facile à assurer avec une seule occurrence de
l’information à protéger.
5. Dépendance des données :
Dans un système de fichiers, les données dépendent des applications qui les utilisent.
6. Partage limité des données :
Dans un système de fichier, chaque application possède ses propres données enregistrées
dans les fichiers séparés, ce qui rend le partage de données difficiles.
3. Notions préliminaires : BD et SGBD

3.1 Base de données :
Une base de données peut être vue comme une collection de données persistantes,
opérationnelles, enregistrées en mémoire secondaire (disque dur par exemple). Ces données
doivent être cohérentes, non redondantes (ou de redondance minimale) accessibles
simultanément par plusieurs programmes (ou utilisateurs). Il faut noter q’une base de données
est indépendante des programmes d’application qui l’utilisent.
Exemple :
Cet exemple présente une collection de données représentant une partie d’un emploi du
temps dans un établissement scolaire :
Jour Heure Local Cod-mod Num-ens An_étude Section
Samedi 8h 00 L1 Algo E1 2 A
h
Samedi 13 00 L2 Archi E2 2 A
Lundi 9h 00 L1 Algo E4 2 B
h
Mardi 11 00 L3 Log E3 2 B
h
Samedi 13 00 L3 Sys E4 2 A
www.etudpdf.com
3.2 Système de gestion de base de données (SGBD) :

C’est un ensemble d’outils logiciels permettant la création et la manipulation des bases de
données, ses principales fonctionnalités sont résumées dans les points suivants :
 La définition des données :
Un SGBD doit fournir à l’utilisateur des outils (primitives) pour décrire les entités de la
base de données (exemple : Etudiant, module, enseignant,…), les attributs de chaque entité
(matricule, nom, prénom, code module,…), ainsi que les liens entre eux et les contraintes
éventuelles qui les concernent. La définition des données se fait au moyen d’un langage de
définition de données (LDD)
 La manipulation de données :
Un SGBD doit offrir aux utilisateurs des moyens pour la manipulation des données de la
base, il s’agit des primitives permettant la recherche, la modification, l’ajout et la suppression
de données. Ces primitives constituent le langage de manipulation de données (LMD).
 L’intégrité des données :
Un SGBD doit garantir la qualité (fiabilité) de l’information enregistrée, il s’agit par
exemple, de propriétés que doivent vérifier certains attributs (plage de valeurs permises) et
spécifiées lors de la définition des données par LDD. D’autres contraintes peuvent être plus
complexes et doivent être programmées.
 Les accès concurrents :
Un SGBD doit offrir des mécanismes de gestion des accès simultanés à une base de
données, ceci est nécessaire lorsque plusieurs utilisateurs dans un réseau veulent accéder aux
données de la même base.
 La confidentialité :
Lorsque la base de données est accédée par plusieurs utilisateurs, l’utilisation de sous-
schémas est nécessaire pour garantir la confidentialité des données. Ainsi chaque utilisateur
n’accède qu’à une partie de la base de données. La confidentialité est assurée au moyen de
mots de passe et de privilèges attribués aux utilisateurs.
 La sécurité de fonctionnement :
Doit être assurée en cas d’incident matériel et/ou logiciel. Tout SGBD doit disposer de
moyens (exemple : la journalisation) lui permettant la reprise après panne.
SGBD Utilisateur 1
Application 1
Utilisateur 2
Application 2
BD
Application 3 Utilisateur 3
Représentation simplifiée d’un système de bases de données Utilisateur 4
www.etudpdf.com
3.3 Les niveaux d’une architecture de BD :

Dans une architecture de base de données, on distingue généralement trois niveaux qui sont :
 Le niveau externe :
C’est le niveau où les utilisateurs voient les données, il est appelé aussi niveau utilisateur.
 Le niveau physique :
Ce niveau est relatif à la mémoire physique (disque dur par exemple), il s’agit du niveau où
les données sont stockées, appelé aussi niveau interne.
 Le niveau conceptuel :
C’est le niveau intermédiaire entre les deux précédents, appelé aussi niveau logique.
Il existe plusieurs vues externes, chacune spécifique à un utilisateur particulier. Par
contre, il existe une seule vue conceptuelle qui donne la représentation abstraite de la totalité
de la base de données et une seule vue interne représentant la totalité de la base de données
telle qu’elle est enregistrée en mémoire.
Niveau
Vue Vue Vue
Externe
externe 1 externe 2 externe n
.....
Niveau
Logique Vue conceptuelle
Niveau Vue physique

Physique
Les trois niveaux d’une architecture de Base de données

3.4 Modèles de représentation de données :
La classification des SGBD est faite selon le type de modèle de représentation de
données qu’ils supportent. Celui des systèmes de type CODASYL comporte les concepts de :
 Attribut (data item)

 Type d’enregistrement (record type)
 Lien fonctionnel (set type) entre deux types d’enregistrements différents. Un des
types d’enregistrement est dit owner (propriétaire) du set et l’autre est dit member
(membre)
www.etudpdf.com
- Matricule
Etudiant - Nom
- Prénom
- Adresse
Est inscrit
- Cod-mod
Module - Libellé-mod
- Coeff
Exemple de structure CODASYL
Un type de set exprime une liaison père-fils entre deux types record
Les SGBD CODASYL supportent deux types de modèles : le modèle hiérarchique et
le modèle réseau.
 Le modèle hiérarchique :
Les SGBD hiérarchique gèrent des schémas dans lesquels un type de record peut être
propriétaire de plusieurs types de sets mais il ne peut être membre que d’un seul type de set. Il
permet de représenter les entités (classes) et des relations de type « père-fils » entre ces
classes, ce qui génère une représentation sous forme arborescence de ces entités. Les SGBD
de type hiérarchique gèrent les liens « père-fils », ils offrent des primitives pour naviguer dans
de telles structures
- Matricule
- Nom
Etudiant - Prénom
- Adresse
Est inscrit
- Cod-filière
Filière - Libellé-filière
Comporte
- Cod-mod
Module
- Libellé-mod
 Le modèle réseau :
Dans un schéma réseau, un type record peut être propriétaire de plusieurs types de
sets, et peut être membre de plusieurs types de sets.
Il permet aussi la représentation de classe et de liens de type « père-fils » entre ces

classes. En plus, il autorise à une classe « fille » d’avoir plusieurs classes « mères ». Comme
le modèle hiérarchique, les SGBD réseau sont aussi de type navigationnel.
www.etudpdf.com
Exemple :
- Num-ens - Cod-mod
- - Nom-ens - Libellé-mod
Enseignant Module
- Prénom-ens - Coeff
- Jour
- Heure
Emploi du
- Local
temps
Au-delà des SGBD CODASYL, existent les SGBD relationnels et les SGBD objets.
 Le modèle relationnel :
Il permet de voir une base de données comme un ensemble de tables, il est doté d’une
algèbre relationnelle. Les langages relationnels de manipulation de données se caractérisent
par leur nature déclarative.
Contrairement aux SGBD réseau ou hiérarchique, les SGBD relationnels (SGBDR)
offrent un langage de manipulation de données standard (SQL fondé sur l’algèbre
relationnelle).
 Le modèle orienté objet :
Permet de voir une base de données comme un ensemble de classes d’objets, ayant des
liens d’héritage, d’agrégation, de composition ou de simple association entre elles.
Moyen de transport
Représentation de l’héritage
Voiture Avion Bus Train
Représente le lien d’agrégation
1 4
Moteur Roue
Dans chacune des classes représentées, il faudra spécifier les attributs et les méthodes
correspondantes.
www.etudpdf.com
3.5 Objectifs des SGBD

1. Indépendance physique :
Un des objectifs essentiels des SGBD est de permettre de réaliser l’indépendance des
structures de stockage aux structures de données du monde réel, c.a.d entre le schéma interne
et le schéma conceptuel. Ces deux schémas décrivent les mêmes données, mais à des niveaux
différents. Il s’agit donc de pouvoir modifier le schéma interne sans avoir à modifier le
schéma conceptuel, en tenant compte seulement des critères de performance et de flexibilité
d’accès. On pourra par exemple ajouter un index, regrouper deux fichiers en un, changer
l’ordre ou le codage des données dans un article, sans mettre en cause les entités et
associations définies au niveau conceptuel.
2. Indépendance logique :
L’indépendance logique est la possibilité de modifier un schéma externe sans modifier le
schéma conceptuel. Elle assure aussi l’indépendance entre les différents utilisateurs, chacun
percevant une partie de la base via son schéma externe, selon une structuration voire un
modèle particulier. Les avantages de l’indépendance logique sont les suivants :
 Permettre à chaque groupe de travail de voir les données comme il le souhaite ;
 Permettre l’évolution de la vue d’un groupe de travail (d’un schéma externe) sans
remettre en cause, le schéma conceptuel de l’entreprise ;
 Permettre l’évolution d’un schéma externe sans remettre en cause les autres schémas
externes.
En résumé, il doit être possible d’ajouter des attributs, d’en supprimer d’autres, d’ajouter
ou de supprimer des associations, d’ajouter ou de supprimer des entités, etc., dans des
schémas externes mais aussi dans le schéma conceptuel sans modifier la plus grande partie
des applications.
3. Manipulation des données par des langages non procéduraux :
Les utilisateurs, parfois non professionnels de l’informatique, doivent pouvoir
manipuler simplement les données, c.a.d les interroger et les mettre à jour sans préciser les
algorithmes d’accès. Plus généralement, si les objectifs d’indépendance sont atteints, les
utilisateurs voient les données indépendamment de leur implantation en machine. De ce fait,
ils doivent pouvoir manipuler les données au moyen de langages non procéduraux, c.a.d en
décrivant les données qu’ils souhaitent retrouver (ou les mettre à jour) qui est propre à la
machine.
4. Administration facilitée des données :
Un SGBD doit fournir des outils pour décrire les données, à la fois leurs structures de
stockage et leurs présentations externes. Il doit permettre le suivi de l’adéquation de ces
structures aux besoins des applications et autoriser leur évolution aisée.
L’évolution des SGBD modernes tend à fournir des outils permettant de décentraliser
la description de données, tout en assurant une cohérence entre les diverses descriptions
partielles. Ces descriptions de données devront être faciles à consulter et à modifier.
L’évolution va donc vers le développement d’outils intégrés capables de faciliter
l’administration des données et d’assurer la cohérence des descriptions.
5. Efficacité des accès aux données :
Les performances en termes de débit (nombre de transactions types exécutées par seconde) et
de temps de réponse (temps d’attente moyen pour une requête type) sont un problème clé des
www.etudpdf.com
SGBD. L’objectif de débit élevé nécessite un overhead minimal dans la gestion des tâches
accomplie par le système. L’objectif de bon temps de réponse implique qu’une requête courte
d’un utilisateur n’attende pas une requête longue d’un autre utilisateur. Il faut donc partager
les ressources (unités centrales, unités d’entrées-sorties) entre les utilisateurs en optimisant
l’utilisation globale et en évitant les pertes en communication de contextes.
6. Redondance contrôlée des données :
Dans les systèmes classiques à fichiers non intégrés, chaque application possède ses
données propres. Cela conduit généralement à de nombreuses duplications de données avec,
outre la perte en mémoire secondaire associée, un gâchis important en moyens humains pour
saisir et maintenir à jour plusieurs fois les mêmes données. Avec une approche base de
données, les fichiers plus ou moins redondants seront intégrés en un seul fichier partagé par
les diverses applications. L’administration centralisée des données conduisait donc
naturellement à la non duplication physique des données afin d’éviter les mises à jour
multiples.
En fait, avec les bases de données réparties sur plusieurs calculateurs interconnectés, il
est apparu souhaitable de faire gérer par le système des copies multiples de données. Cela
optimise les performances en interrogation, en évitant les transferts sur le réseau et en
permettant le parallélisme des accès. Il s’agit donc de bien contrôler la redondance, qui
permet d’optimiser les performances, en la gérant de manière invisible pour les utilisateurs.
7. Cohérence des données :
Bien que les redondances anarchiques entre données soient évitées, les données vues
par l’utilisateur ne sont pas indépendantes. Au niveau d’ensemble de données, il peut exister
certaines dépendances entre données. Par exemple une donnée représentant le nombre de
commandes d’un client doit correspondre au nombre de commandes dans la base. Plus
simplement, une données élémentaire doit respecter un format et ne peut souvent prendre une
valeur quelconque. Par exemple, un salaire mensuel doit être supérieur au SMIG et doit
raisonnablement rester inférieur à un seuil. Un SGBD doit veiller à ce que les applications
respectent ces règles lors des modifications des données et ainsi assurer la cohérence des
données. Les règles que doivent explicitement ou implicitement suivre les données au cours
de leur évolution sont appelées contraintes d’intégrité.
8. partage des données :
L’objectif est de permettre aux applications de partager les données de la base dans le
temps mais aussi simultanément. Une application doit pouvoir accéder aux données comme si
elle était seule à les utiliser, sans attendre mais aussi sans savoir qu’une autre application peut
les modifier concurremment.
En pratique, un utilisateur exécute des programmes généralement cours qui mettent à
jour et consultent la base de données. Un tel programme interactif appelé transaction,
correspond par exemple à l’entrée d’un produit en stock ou à une réservation de place
d’avion. Il est important que deux transactions concurrentes (par exemple, deux réservations
sur le même avion) ne s’emmêlent pas dans leurs accès à la base de données (par exemple
réservent le même siège pour deux passagers différents). On cherchera donc à assurer que le
résultat d’une exécution simultanée de transactions reste le même que celui d’une exécution
séquentielle dans un ordre quelconque de transactions.
9. Sécurité des données :
Cet objectif a deux aspects. Tout d’abord, les données doivent être protégées contre
les accès non autorisés ou mal intentionnés. Il doit exister des mécanismes adéquats pour
www.etudpdf.com
autoriser, contrôler ou enlever les droits d’accès de n’importe quel usager à tout ensemble de
données. D’un autre côté, la sécurité des données doit aussi être assurée en cas de panne d’un
programme ou d’un système, voire de la machine. Un bon SGBD doit être capable de
restaurer des données cohérentes après une panne disque, à partir de sauvegardes précédentes.
Aussi, si une transaction commence une mise à jour (par exemple un transfert depuis votre
compte en banque sur celui de l’auteur) et est interrompue par une panne en cours de mise à
jour, le SGBD doit assurer l’intégrité de la base et par suite défaire la transaction qui a
échoué. Une transaction doit être totalement exécutée, ou pas du tout : il faut assurer
l’atomicité des transactions, et ainsi garantir l’intégrité physique de la base de données.
10
www.etudpdf.com
Module BDD : Le modèle relationnel Mme H.CHELLAKH
Le modèle relationnel
1. Introduction :
Le modèle relationnel a été proposé en 1970, par Ted Codd, chercheur chez IBM, dans un
exposé désormais célèbre qui attira immédiatement l’attention grâce à la simplicité de son
fondement mathématique. Le modèle exploite la notion de relation mathématique, bloc de
construction qui se fonde sur la théorie des ensembles et la logique des prédicats de premier ordre.
Le modèle relationnel est aujourd’hui la base de nombreux systèmes, et les architectures
permettant d’accéder depuis une station de travail à des serveurs de données s’appuient en général
sur lui. Le relationnel a donc atteint ses objectifs au-delà de toute espérance.
Les objectifs du modèle relationnel ont été formulés par Codd comme suit :
1- Permettre un haut degré d’indépendance des programmes d’application et des activités
interactives à la représentation interne des données.
2- Fournir une base solide pour traiter les problèmes de cohérence et de redondance des
données.
3- Permettre le développement de langage de manipulation de données non procéduraux basés
sur les théories solides.
4- Etre un modèle extensible permettent de modéliser et de manipuler simplement des données
tabulaires, mais pouvant être étendu pour modéliser et manipuler des données complexes.
5- Devenir un standard pour la description et la manipulation des bases de données.
2. Les concepts du modèle relationnel :

Le modèle relationnel représente la base de données comme un ensemble de relations.
Chaque relation est une table de valeurs ou fichier d’enregistrements. Lorsqu’une relation est
conçue comme une table de valeurs, chaque ligne de la table représente un ensemble de valeurs
reliées.
Dans la terminologie du modèle relationnel, une ligne est appelée tuple, les entêtes de
colonnes sont appelés attributs et les tables sont appelées relations. Le type des données
introduites dans chaque colonne est représenté par un domaine de valeurs possibles.
2.1 Domaine, attribut et relation :

 Un domaine D est un ensemble de valeurs atomiques. Par valeur atomique, nous entendons
toute valeur incluse dans le domaine et indivisible dans le cas du modèle relationnel. Une
méthode courante de définition de domaine consiste à spécifier le nom du domaine suivi par le
type des données qui composent le domaine.
Exemple :
N° de téléphone national. Ensemble de 9 chiffre.
Nom. Chaîne de caractères identifiant la personne.
Age employé. La valeur doit être comprise entre 16 ans et 60 ans.
La liste qui précède est un ensemble de définitions logiques de domaine, un type de données (ou
format) est également nécessaire pour chaque domaine. Ainsi, le type de données du domaine
N°_de_téléphone_national peut être déclaré sous la forme suivante : n_nn_nn_nn_nn où chaque n
est un nombre de 0 à 9.
Un nom, un type de données et un format sont attribués à chaque domaine.
 Le schéma relationnel R, noté R (A1, A2,…, An) est constitué d’une relation nominale R et d’une
liste d’attributs A1, A2,…,An. Chaque attribut A est le mon du rôle joué par un domaine D dans le
schéma relationnel R. D est réputé domaine de A et est noté dom (A). les relations sont décrites
www.etudpdf.com
à l’aide d’un schéma relationnel ; R est le nom de cette relation. Le degré d’une relation est le
nombre d’attributs n de son schéma relationnel.
Exemple de schéma relationnel de degré sept décrivant les étudiants de l’université :
ETUDIANT (Nom, N°SS, Tel_dom, Adresse, Tel_bureau, Age, Moy_notes).

Si l’on utilise les types de données de chaque attribut, on aboutit à la définition suivante :
ETUDIANT (Nom : chaîne, N°SS : chaîne, Tel_dom : chaîne, Adresse : chaîne,
Tel_bureau : chaîne, Age : entier, Moy_notes : réel).
Figure 1 : Schéma de relation ETUDIANT
 Une relation r (ou état relationnel) ou encore schéma relationnel R (A1, A2,…,An), également
noté r(R), est un ensemble de n-tuples r=(t1, t2,…, tm ). Chaque n-tuple (ou n-uplet) est une liste
ordonnée de valeurs t=< v1, v2,…, vn > où chaque valeur v est un élément de dom (A) ou une
valeur spéciale nulle. La ie valeur du tuple t, qui correspond à l’attribut A, est réputée t(A) ( ou
t(i) si l’on utilise la notation positionnelle)
Nom de la Attributs
relation
Etudiant Nom N°SS Tel_dom Adresse Tel_Bureau Age Moy_notes
Arridj 820345666 035 68 12 48 25 rue 17 oct 035 68 12 12 19 12.5

Tuples Mehenni 812456778 035 68 10 90 Fg des jardins 035 68 15 14 18 15
Mebarkia 805677788 035 68 20 80 Lotis 12 hectars null 20 10.5
Figure 2 : Attributs et tuples de la relation Etudiant

Les précédentes définitions peuvent être reformulées plus formellement comme suit : une relation
(ou état relationnel) r(R) est une relation mathématique de degré n sur les domaines dom(A1 ),
dom(A2 ),…, dom(An), qui sont un sous ensemble du produit cartésien des domaines définissant R :
r ( R)  (dom( A1 )  dom( A2 )  ...  dom( An ))

Le produit cartésien spécifie toutes les combinaisons de valeurs possibles des domaines sous-
jacents.
Plusieurs attributs peuvent avoir le même domaine, dans ce cas ils référencent différents rôles ou
interprétations.
2.2 Extensions et intensions

Comme tous les modèles de données, le modèle relationnel permet de décrire des données
dont les valeurs varient en fonction du temps. En ce sens que les tuples sont ajoutés, supprimés et
modifiés dans une relation au cours de sa vie. Cependant, la structure d’une relation caractérisée par
les trois concepts de domaine, relation et attribut est un invariant pour la relation (elle ne change pas
en fonction du temps). Cette structure est capturée dans le schéma de la relation.
Le schéma d’une relation représente son intension, c'est-à-dire les propriétés (au moins
certaines) communes et invariantes des tuples qu’elle va contenir dans le temps (voir Figure 1 par
exemple). Au contraire, une table représente une extension d’une relation (voir Figure 2 par
exemple), c'est-à-dire une vue des tuples qu’elle contient à un instant donné. Une extension d’une
relation R est aussi appelée instance de R. L’intension est le résultat de la description des données,
alors qu’une extension (ou instance) fait suite à des manipulations et représente un état de la base.
www.etudpdf.com
3. Les règles d’intégrité structurelle :

Les règles d’intégrité sont les assertions qui doivent être vérifiées par les données contenues
dans une base. Il est possible de distinguer les règles structurelles qui sont inhérentes au modèle de
données, c'est-à-dire nécessaires à sa mise en œuvre, et les règles de comportement propres au
schéma particulier d’une application. Le modèle relationnel impose a priori une règle minimale qui
est l’unicité des clés. Il est commode et courant d’ajouter trois types de règles d’intégrités
supplémentaires afin d’obtenir les règles d’intégrité structurelle supportées par le modèle
relationnel : les contraintes de références, les contraintes d’entité et les contraintes de domaine.
3.1 Unicité de clé :

Par définition, une relation est un ensemble de tuples. Un ensemble n’ayant pas d’élément
en double, il ne peut exister deux fois le même tuple dans une relation. Afin d’identifier les tuples
d’une relation sans donner toutes les valeurs et d’assurer simplement l’unicité des tuples, la notion
de clé est utilisée.
De manière plus formelle, une clé d’une relation R est un ensemble d’attributs K tel que,
quels que soient les tuples t1 et t2 d’une instance de R, t1(K)  t2(K), c'est-à-dire que t1 et t2 ont
des valeurs de K différentes. Un ensemble d’attributs contenant une clé est appelé super-clé.
Généralement, toute relation (ou schéma relationnel) peut posséder plusieurs clés, auquel cas
chaque clé est appelée clé candidate. On désigne l’une des clés comme clé primaire. Il s’agit de la
clé dont les valeurs identifient les tuples de la relation.
Exemple :
VOITURE N°immatriculation N°sériemoteur Marque Modèle Année
739 AB 12 A69352 Fiat Tipo 96

3470 FL 14 B43698 Citroën XZ 99
2214 NY 22 X87654 Citroën XM 05
4328 TF 41 C35679 Mercedes 190-D 08
6294 FI 75 YB0987 Peugeot 407-HDI 98
9296 RS 95 UO23865 Jaguar XJS 98
Figure 3 : Attributs et tuples de la relation Voiture
N°immatriculation et N°sériemoteur sont deux clés candidates de la relation VOITURE
Comme le montre l’exemple les attributs formant la clé primaire sont soulignés. Lorsqu’une
relation possède plusieurs clés, le choix de la clé primaire est arbitraire, mais il est préférable de
sélectionner des clés primaires possédant un seul attribut ou un petit nombre d’attributs.
3.2 Contrainte de référence :

La contrainte d’intégrité référentielle est spécifiée entre deux relations et sert à assurer la
cohérence de leurs tuples. Elle précise que tout tuple qui référence une autre relation doit référencer
un tuple existant de cette relation. Par exemple dans la figure 4, l’attribut N°sce de la relation
employé indique le N° de service où travaille chaque employé. Par conséquent, sa valeur dans
chaque tuple employé doit correspondre à la valeur N°sce d’un tuple de la relation service.
www.etudpdf.com
R1 : EMPLOYE N°ss Prénom Nom Date nais Adresse Salaire N°sce
7123454 Mohammed Gharbi 23/07/71 Fg des jardins 30000 5

6967889 Mourad Mehanni 12/12/69 Rue 17 oct 25000 5
6278990 Fatima Chaâbane 11/05/62 Cité750 Logts 28000 4
R2 : SERVICE N°sce Libellé sce
Clé 1 Recherche
primaire 4 Administration Clé
5 Comptabilité étrangère
Figure 4 : Attributs et tuples des relations Employé et Service
Le concept d’intégrité référentielle est lié au concept de clé étrangère. Les conditions
d’existence d’une clé étrangère imposent l’existence d’une contrainte d’intégrité référentielle entre
les schémas R1 et R2.
L’ensemble d’attributs FK du schéma relationnel R1 est une clé étrangère de R1 qui
référence la relation R2 si les deux règles suivantes sont respectées :
1- Les attributs de FK doivent avoir le ou les mêmes domaines que les attributs de clé
primaire PK de R2 ; on dit alors que les attributs FK référencent la relation R2.
2- La valeur en FK d’un tuple t1 de l’état courant r1(R1) doit avoir la valeur en PK d’un
tuple t2 de l’état courant r2(R2), faute de quoi elle est NULL. Dans le premier cas, nous
avons t1(FK)=t2(PK). On dit alors que le tuple t1 référence le tuple t2.
Selon cette définition, R1 est appelée relation référençante et R2 relation référencée.
3.3 Valeurs nulles et clés :

Lors de l’insertion de tuples dans une relation, il arrive fréquemment qu’un attribut soit
inconnu ou non applicable ; exemple le salaire d’un employé peut être non fixé au départ, on est
alors amené à introduire dans la relation une valeur conventionnelle, appelée valeur nulle.
 Contrainte d’intégrité imposant que toute relation possède une clé primaire et que tout
attribut participant à cette clé primaire soit non nul.
 Le modèle relationnel n’impose pas que les clés étrangères qui n’appartiennent pas à une clé
primaire soient non nulles. Cela peut permettre une certaine souplesse, par exemple
d’enregistrer des employés qui ne sont attachés à aucun service.
3.4 Contraintes de domaines :

En théorie, une relation est construite à partir d’un ensemble de domaines. En pratique les
domaines gérés par les systèmes sont souvent limités aux types de base entier, réel, chaîne de
caractères parfois monnaie et date. Afin de spécialiser un type de données pour composer un
domaine plus fin (par exemple les moyennes des étudiants sont des réels compris entre 0 et 20), la
notion de contrainte de domaine est souvent ajoutée aux règles d’intégrité structurelle du
relationnel. Cette notion peut être introduite comme suit :
 Contrainte d’intégrité imposant qu’une colonne d’une relation doit comporter des valeurs
vérifiant une assertion logique.
 L’assertion logique est l’appartenance à une plage de valeurs ou à une liste de valeurs ; par
exemple moyenne >= 0 et <= 20.
www.etudpdf.com
4. Règles de passage du modèle Entité/Association au modèle

relationnel :
Le passage du modèle E/A au modèle relationnel est direct et peut se faire en suivant les
principes suivants :
Modèle E/A Modèle relationnel

Identifiant Clé primaire
Propriété Attribut
Entité Relation
Relation Relation
Remarque : pour éviter toute confusion avec la relation du modèle E/A, la relation au sens
relationnel sera toujours appelée Table relationnelle.
Règle 1 : Chacune des entités du modèle E/A devient une table relationnelle.
Règle 2 : L’identifiant des entités du Modèle E/A devient la clé primaire des tables relationnelles.
Règle 3 : Les propriétés portées par les entités du modèle E/A deviennent des attributs des tables
relationnelles.
Règle 4 : Une relation R du modèle E/A de type :
O,1
A O,N R B
ou 1 ,1
ou 1,N
a. R n’est pas porteuse de propriétés : elle disparaît dans le modèle relationnel, l’identifiant de
A devient une clé étrangère dans la relation B
b. R est porteuse de propriétés : celles-ci migrent vers B (c'est-à-dire deviennent des attributs
de B).
Règle 5 : Une relation R du modèle E/A de type
O, N O, N
A R B
ou 1,N ou 1 ,N
La relation R devient une table relationnelle, sa clé primaire étant obtenue par la
concaténation des identifiants des entités qui participent à la relation, si elle est porteuse de
propriétés celles-ci deviendront des attributs.
Règle 6 : Si la relation est de dimension supérieure à 2, elle devient une table relationnelle avec
comme clé primaire la concaténation des identifiants des entités qui participent à la relation.
www.etudpdf.com
Module BDD : Conception de BDD relationnelles Mme H.CHELLAKH
Dépendances fonctionnelles et normalisation des BDD

1. introduction :
Etant donné un ensemble d’attributs (dictionnaire de données) relatif à un domaine d’étude
particulier, comment trouver une bonne structuration de ces attributs en un ensemble de relations
s’adaptant aux données à représenter ? En d’autres termes, il s’agit de décider d’une structure
logique adéquate (cohérente et sans redondance) pour les données à représenter.
Pour cela, plusieurs méthodes existent dont l’algorithme de synthèse, qui est basé sur deux
concepts clés : les dépendances fonctionnelles et la normalisation.
2. les dépendances fonctionnelles (DF) :

2.1. Notion de DF :
Domaine Ensemble Ensemble de

d’étude Collecter les d’attributs Déterminer les DFs
attributs du dépendances entre
domaine les attributs
Soit le sous ensemble d’attributs tirés du dictionnaire de données relatif à la gestion d’une scolarité :
Nom d’attribut Signification

Cod_mod Code du module
Num-ens Numéro d’enseignant
Jour Jour de semaine
Heure Horaire d’une séance
Section Numéro de la section
Local Numéro de la salle de cours
An-étude Année d’étude
Sur la base de cet ensemble d’attributs, nous construisons une relation qui nous renseigne
sur l’emploi du temps, d’une filière donnée (informatique par exemple, toutes années confondues.
Emploi du temps :
Jour Heure local Cod-mod Num-ens An-étude Section
Dimanche 8h 00 L1 Algo E1 2 A
Dimanche 13h 00 L2 Archi E2 2 A
Lundi 9h 30 L1 Algo E4 2 B
Mardi 11h 30 L3 Log E3 2 B
Dimanche 13h 00 L3 Sys E4 3 A
…
De là, nous constatons ce qui suit :

Connaissant le jour de semaine, l’heure et le local, nous pouvons déterminer de façon unique les
valeurs de Cod-mod, Num-ens, An-étude et Section.
On dira que {Jour, Heure, Local} déterminent cod-mod, Num-ens, An-étude et section.
On dira aussi que Cod-mod, Num-ens, An-etude et section dépendent fonctionnellement de
{Jour, Heure, Local}.
On écrira : Jour, Heure, Local Cod-mod, Num-ens, An-étude, Section
L’ensemble des attributs de la partie gauche détermine les attributs de la partie droite.
www.etudpdf.com
Ou encore :
Jour , Heure, Local  Cod  mod
Jour , Heure, Local  num  ens
Jour , Heure, Local  An  étude
Jour , Heure, Local  Section
Nous constatons aussi que Cod-mod ne détermine pas Num-ens. En effet, pour le module
Algo, nous avons deux enseignants différents E1 et E4.
Connaissant le module, nous ne pouvons pas déterminer l’enseignant.
De même, Num-ens ne détermine pas Cod-mod, du fait que l’enseignant E4 assure deux module
différents Algo et Sys.
Remarques :
 Une DF est une assertion qui est définie sur toutes les réalisations (tuples) d’une réalisation
et pas sur un tuple particulier.
 Une DF traduit une certaine perception de la réalité, elle correspond à une contrainte sur les
données, qui doit être vérifiée en permanence.
Définition (Dépendance Fonctionnelle) :
Soit R a1 , a 2 ,..., a n  ( n  2) un schéma de relation, soit X, Y, Z trois sous-ensembles
d’attributs de A= a1 , a 2 ,..., a n  tels que : X  Y  Z   et X  Y  Z  A (Z peut être vide)
On dira que X détermine Y, ou Y dépend fonctionnellement de X et on notera X  Y si quels que
soient les tuples (x,y,z) et ( x , y , z  ) de R, x  x   y  y 
Autrement dit : une valeur de x détermine une et une seule valeur de y, ou bien connaissant la
valeur de x, nous pouvons déterminer la valeur de y sans ambiguïté.
Exemples :
 Dans une relation qui décrit les modules enseignés R(Code-mod, Libellé-mod, coef), nous
avons les DFs suivantes :
Code  mod  Libellé  mod
Code  mod  Coef
Connaissant Cod-mod, nous pouvons déterminer son libellé et son Coefficient.
 Dans une relation qui décrit les enseignants, nous avons les DFs suivantes :
Num  ens  Grade
Num  ens  Nom  ens
Num  ens  Pr énom  ens
On pourra les écrire aussi comme suit :
Num  ens  Grade, Nom  ens, Pr énom  ens
 Dans une relation qui décrit les sections, nous avons :
Section, An  étude  Nbre  étudiants
2.2. Propriétés des DF :

Dans cette partie, X et Y représentent deux sous-ensembles d’attributs d’une relation R.
 Réflexivité :
Pour tout Y  X , on a X  Y , en particulier X  X
 Augmentation :
Si X  Y alors X  Z  Y  Z
Exemple :
Cod  mod  Libellé  mod  Cod  mod, Coef  Libellé  mod, Coef
www.etudpdf.com
 Transitivité :
Si X  Y et Y  Z alors X  Z
Exemple :
Num  ens  grade et grade  salaire de base  Num  ens  salaire de base
Les trois règles précédentes ci-dessus sont connues sous le nom d’axiomes
d’ARMSTRONG, d’autres règles peuvent en être déduites : il s’agit de l’union, la pseudo
transitivité et la décomposition.
 Union :
Si X  Y et X  Z alors X  Y  Z
Exemple :
Jour , Heure, Local  Cod  mod et Jour , Heure, Local  num  ens
 Jour , Heure, Local  Cod  mod, Num  ens
 Pseudo-transitivité :
Si X  Y et Y  W  Z  X  W  Z
Exemple :
Num  ens  grade
Grade, Nom  ens  salaire
 Num  ens, Nom  ens  salaire
 Décomposition :
Si X  Y et Z  Y alors X  Z
Exemple :
Code  mod  Libellé  mod, Coef Coef   Libellé  mod, Coef 
 Cod  mod  Coef
2.3. Typologie des DF :

 DF triviale :
X  Y est triviale si Y  X . (Réflexivité).
 DF élémentaire :
Une DF X  Y est dite élémentaire si X   X , X   Y .
Autrement dit : Y ne dépend pas d’une partie de X
Exemple :
Jour , Heure, Local  Cod  mod est élémentaire.
Cod  mod, libellé  mod  Coef n’est pas élémentaire car Cod-mod suffit pour déterminer
Coef.
Cette DF élémentaire sert à conserver les seules DF utiles.
 DF canonique :
Une DF X  Y est dite canonique si son membre droit est réduit à un singleton (c.a.d un seul
attribut).
Notons que toute DF qui n’est pas canonique peut être transformée en un ensemble de DFs
canonique par décomposition.
Exemple :
La DF Num  ens  Grade, Nom  ens, Pr énom  ens n’est pas canonique, elle donne lieu à
trois DF canoniques.
www.etudpdf.com
Num  ens  Grade

Num  ens  Nom  ens
Num  ens  Pr énom  ens
 DF directe :
X  Y est directe si :
 Elle est élémentaire.
 Y ne dépend pas transitivement de X
( ( Z / X  Z et Z  Y )
2.4. Couverture minimale (irréductible)

Définition :
La couverture minimale d’un ensemble de DF est un sous ensemble minimum de DF
élémentaires permettant de générer toutes les autres.
Théorème :
Tout ensemble de DF admet une couverture minimale, en général non unique.
Exemple :
1- Cod  mod  Cod  filière
2- Cod  filière  libellé filière
3- Cod  mod  Libellé  filière
4- Jour , Heure, Local  num  ens
5- Jour , Heure, Local  Cod  filière
6- Jour , Heure, Local  Section
7- Jour , Heure, Local  Groupe
8- Jour , Heure, Local  An  étude
9- Jour , Heure, Local  Cod  mod
10- Jour , Heure, Local , Num  ens  Cod  filière
La couverture minimale de cet ensemble de DF consiste à éliminer les DF N°3 (obtenu par
transitivité de 1 et 2), N° 10 obtenue par augmentation de la DF N°5, et la DF N° 5 obtenu par
transitivité de 1 et 9.
2.5. Fermeture transitive :

Définition :
On appelle fermeture transitive d’un ensemble de F de DF, l’ensemble F+ constitué de F lui-
même et de l’ensemble des DF déduites par transitivité.
Exemple :
Soit l’ensemble de DF,
F= Num  ens  Grade, Grade  Salaire, Grade  Nbre  heures
La fermeture transitive de F sera :
F+= F  Num  ens  salaire, Num  ens  Nbre  heures
 Num  ens  Grade, Grade  Salaire, Grade  Nbre  heures, Num  ens  Salaire
=
Num  ens  Nbre  heures 
Dans ce cas la couverture minimale de F+ est F.
www.etudpdf.com
Remarque :
La recherche de la couverture minimale d’un ensemble de DF est un élément essentiel dans
le processus de normalisation, afin de décomposer une relation en plus petites relations.
2.6. Notion de clé de relation :

De façon informelle, la clé d’une relation R est un ensemble d’attributs (un ou plusieurs) de R,
qui détermine tous les attributs de R.
 Définition (clé de relation) :
Soit A l’ensemble des attributs d’une relation R et soit X un sous ensemble de A. X est une clé
de R si a  A, X  a .
Exemple :
Jour , Heure, Local  Cod  mod
Jour , Heure, Local  num  ens
Jour , Heure, Local  An  étude
Jour , Heure, Local  Section
Donc {Jour, Heure, Local} est une clé de la relation Emploi du temps, elle sera écrite juste
après le nom de la relation et soulignée pour la distinguer des autres attributs qui ne sont pas clés.
On aura la relation : Emploi du temps (Jour, Heure, Local, Num-ens, Cod-mod, section, An-étude)
De même dans la relation Module, Cod-mod est une clé.
On écrira Module (Cod-mod, libellé-mod,Coef)
 Clé minimale :
Soit X un sous ensemble d’attributs d’une relation R. X est dite clé minimale, si X est une clé de
R et si toute DF X  a de R est élémentaire.
Exemple :
 Dans une relation décrivant les étudiants :
Etudiant (Matricule, Nom_etud, Prénom-etud, Date-nais-etud, Adresse-etud)
Matricule, Nom  Pr énom  etud
Matricule, Nom  Date  nais  etud
Matricule, Nom  Adresse  etud
Matricule  Nom  etud
Matricule, Nom-etud est une clé de la relation Etudiant, mais elle n’est pas minimale car il suffit
d’avoir le matricule de l’étudiant, pour déterminer tous les attributs, y compris le nom.
Matricule est alors une clé minimale de la relation Etudiant. Le schéma de relation est :
Etudiant (Matricule, Nom-etud, Prénom_etud, Date-nais-etud, Adresse-etud)
 Dans une relation décrivant les résultats obtenus par les étudiants dans les différents modules,
nous aurons :
Résultats (Matricule, Code-mod, Moyenne)
{Matricule, cod-mod}est une clé de la relation Résultats. De plus elle est minimale.
 Clés candidates/ Clé primaire :
Une relation peut avoir plusieurs clés possibles, on parle alors de clés candidates, on en choisit
une qu’on appelle clé primaire.
Dans l’exemple de la relation Emploi du temps, on peut vérifier que {Jour, Heure, Local} et {Jour,
Heure, Num-ens} sont deux clés candidates de la relation.
 Clé étrangère (exterieure) :
La notion de clé étrangère sert à faire le lien entre deux relations d’une même BD, et permet au
SGBD de maintenir la cohérence des lignes (tuples) de deux relations ou d’une même relation.
www.etudpdf.com
Définition :
Soit A un ensemble d’attributs qui constitue la clé primaire d’une relation R1. A est dite
étrangère de R2, si :
1- A apparaît dans R2.
2- Une valeur de clé extérieure d’un tuple quelconque de R2 est soit « NULL », soit apparaît
comme valeur de clé primaire d’un tuple de R1.
Exemple :
Module (Cod-mod, Libellé-mod, Coef, An-étude, Code-filière)
Filière (Cod-filière, Libellé-filière)
Code-filière est une clé primaire dans la relation Filière et elle est étrangère dans la relation module.
www.etudpdf.com
3. Les formes normales :

La théorie de normalisation est destinée à concevoir correctement le schéma d’une base de
données relationnelle, c'est-à-dire :
 Sans redondance d’informations
 Sans anomalies de mise à jour
Exemple :
Considérons la relation Etud-mod suivante :
Etud-mod (Matricule, Cod-mod, Nom-etud, Prénom-etud, moyenne) pour laquelle nous présentons
une partie en extension (l’attribut Moyenne désigne la moyenne d’un étudiant dans un module).
Matricule Nom-etud Prénom-etud Cod-mod Moyenne

52001 ABADI Mohammed Algo 10
52001 ABADI Mohammed Archi 01 12.5
52001 ABADI Mohammed Logique 11
52002 BADAOUI Karim Algo 8.5
52002 BADAOUI Karim Archi 01 15
52002 BADAOUI Karim Logique 11
.
.
.
Nous remarquons tout de suite une redondance dans ce tableau, en effet chaque tuple pour
l’étudiant ‘ ABADI’» nous indique son matricule, son nom et son prénom. Idem pour le tuple de
‘BADAOUI’. D’une manière générale, le nom et le prénom sont répétés autant de fois que le
nombre de modules auxquels il est inscrit.
Dans le modèle relationnel, on doit éviter ce type de situations (redondance d’informations),
pour cela on effectue ce qu’on appelle une normalisation sur les relations, on obtient alors des
relations normalisées. On parle plus précisément de formes normales.
3.1 Première forme normale : (1FN)

Définition (1FN) :
Une relation R est en 1FN, si chacun de ses attributs a un domaine atomique mono-valué.
Autrement dit : pour chaque tuple de la relation, tout attribut possède une seule valeur.
Cette définition exclut les relations ayant des attributs dont les valeurs seraient des ensembles ou
des listes de valeurs.
Exemple :
La relation Résultats qui stocke les résultats des étudiants dans les modules, supposons que
l’on veuille sauvegarder pour chaque module et pour chaque étudiant, les différentes notes obtenues
pendant l’année (pas uniquement la moyenne). Nous aurons à sauvegarder la note de l’EMD1, celle
de l’EMD2, éventuellement celles de la synthèse et du rattrapage.
Soit le schéma de relation suivant :
Résultats (Matricule, Cod-mod, Nom-etud, Prénom-etud, Notes)
Pour l’étudiant « ABADI Mohammed », nous aurons par exemple 4 notes à sauvegarder, pour le
module Algo : 52001 ABADI Mohammed Algo {8 9.5 6.5 11}
Nous remarquons que cette relation n’est pas en 1FN du fait que l’attribut notes possède 4
valeurs différentes, il n’est donc pas atomique.
Pour transformer cette relation en première forme normale (1FN), il faut décomposer l’attribut
Notes en quatre autres attributs : note1, note2, synt, ratt qui soient atomiques.
Nous aurons le schéma de relation suivant :
www.etudpdf.com
Résultats ( Matricule-Cod-mod, Nom-etud, Prénom-etud, Note1, Note2, Synt, Ratt)

Chacun des attributs Note1, Note2, Synt, Ratt aura une valeur atomique, la relation ainsi obtenue
est en 1FN.
Remarque : La première forme normale a pour objectif de mettre à plat les hiérarchies, dans un
souci de simplicité.
3.2 Deuxième forme normale : (2FN)

Une relation R est en 2FN si et seulement si :
 Elle est en 1FN.
 Tout attribut n’appartenant pas à la clé ne dépend pas d’une partie de la clé. Autrement dit il
est en dépendance fonctionnelle élémentaire de la clé (c.a.d. dépend de toute la clé)
Exemple :
La relation Résultats (Matricule, Cod-mod, Nom-etud, Prénom-etud, Note1, Note2, Synt, Ratt)
n’est pas en 2FN
Car : Matricule  Nom  etud
Matricule  Pr énom  etud
Nom-etud et Prénom-etud sont deux attributs qui dépendent d’une partie de la clé.
Il faut décomposer la relation résultats en deux autres relations :
Résultats (Matricule, Cod-mod, Note1, Note2, Synt, Ratt) et
Etudiant (Matricule, Nom-etud, Prénom-etud)
Ces deux dernières relations sont en 2FN.
Remarque :
La 2FN n’est pas suffisante pour éviter toutes les redondances, nous pouvons voir ceci sur
l’exemple suivant :
Considérons la relation Enseignant :
Enseignant (Num-ens, Nom-ens, prénom-ens, Date-nais-ens, Adresse-ens, Grade, Nbr-heures)
Num-ens Nom-ens Prénom-ens Date-nais-ens Adresse-ens Grade Nbr-

heures
E1 SALAH Mohammed 10/06/65 Alger C .C 9h
E2 EL-ALLAMI Ryad 25/02/59 Alger M.C 7h ½
E3 NOUALI Nora 13/05/75 BBA C.C 9h
On remarque que le nombre d’heures d’enseignement dépend uniquement du grade de

l’enseignant, en fait la même valeur sera répétée à chaque fois que l’on répète le même grade.
Nous avons un attribut (Nbr-heures) qui dépend d’un autre attribut non clé (Grade), ceci crée une
autre forme de redondance. Pour l’éliminer, il faut mettre les relations en 3FN.
3.3 Troisième forme normale : (3FN)

Une relation est en 3FN si :
 Elle est en 2FN.
 Tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut non clé. Autrement dit
tout attribut doit dépendre de la clé par du DF élémentaire directe.
Sur l’exemple précédent, il faudra supprimer l’attribut Nbr-heures de la relation Enseignant et
créer une nouvelle relation Charge qui détermine le nombre d’heures d’enseignement, en fonction
du grade de l’enseignant. On éclate la relation précédente en deux autres relations comme suit :
Enseignant (Num-ens,Nom-ens, Prénom-ens, date-nais-ens, Adresse-ens, Grade)
Charge (Grade, Nbr-heures)
Ainsi ces deux relations sont en 3FN.
www.etudpdf.com
Remarque :
La troisième forme normale a pour objectif d’éliminer les redondances dues aux DF
transitives.
3.4 Forme normale de Boyce Codd : (BCFN)

Dans le cas où une relation admet plusieurs clés candidates, des anomalies peuvent subsister
en 3FN. La forme normale de Boyce Codd, permet d’éviter ces anomalies.
Définition :
Une relation est en forme normale de Boyce-Codd (BCFN), si quelle que soit la dépendance
fonctionnelle, le membre gauche est une clé. Autrement dit un des éléments composant la clé ne
doit pas dépendre d’un autre attribut.
Remarque :
Toute relation qui est en BCFN est forcément en 3FN.
Exemple :
Soit la relation R (Matière, N°classe, Code-ens) vérifiant l’ensemble de DF suivant :
Matière, N classe  code  ens code  ens  matière
Avec la règle de gestion suivante :
Tout enseignant enseigne une et une seule matière.
Cette relation est en 3FN mais n’est pas en BCFN : le membre gauche de la DF
code  ens  matière n’est pas une clé.
Matière Classe Code-ens

Algo INF1 E1
Algo INF2 E1
On remarque qu’il y a une redondance entre Matière et Code-ens.

Cependant, il n’est pas toujours possible de trouver une décomposition sans perte d’informations, et
qui préserve les DF.
La décomposition de R en :
R1 (Code-ens, matière) et R2 (N°classe, Code-ens) évite la redondance, elle est sans perte
d’informations, mais elle ne préserve pas la DF : Matière, N classe  code  ens
4. Algorithme de synthèse :
En appliquant les étapes de cet algorithme, vous pourrez déduire un schéma de relation en
3FN. Vous devez démarrer de la relation universelle et de ses dépendances fonctionnelles. La
relation universelle est une relation qui contient tous les attributs du domaine d’étude.
Relation Ensemble
universelle de DF
Algorithme de
synthèse
Relations
En 3FN
www.etudpdf.com
Soit F, l’ensemble de toutes les dépendances fonctionnelles définies sur les attributs de la relation
universelle. Les étapes de l’algorithme de synthèse sont les suivantes :
1. Trouver l’ensemble IRR(F) contenant la couverture irréductible (couverture minimale) de F
2. Partitionner l’ensemble IRR(F) en sous ensembles Fi, tels que toutes les DFs d’un ensemble
Fi aient la même partie gauche.
3. pour chaque ensemble Fi de DFs, construire une relation composée de tous les attributs
formant les DFs de Fi, la clé de la relation sera la partie gauche commune à toutes ces DFs.
4. traiter les attributs isolés.
Exemple :
Soient les DFS suivantes relatives à la gestion de la scolarité :
1. Code  mod  Libellé  mod
2. Code  mod  An  etude
3. Code  mod  Libellé  filière
4. Code  filière  Libellé  filière
5. Matricule  Nom  etud
6. Matricule  Adresse  etud
7. Matricule  Date  naiss  etud
8. Num  ens  Nom  ens
9. Num  ens  Date  naiss  ens
10. Num  ens  Grade
11. Num  ens  Situation familiale
12. Num  ens  salaire
13. Grade  Nbre  heures
14. Grade  Salaire
15. Code  mod  Coef
16. Code  mod  Code  filière
17. Matricule  Pr énom  etud
18. Num  ens  Pr énom  ens
19. Num  ens  Adresse  ens
20. Num  ens, Grade  Nbre  heures
21. Num  ens, Grade  salaire
22. Num  ens  Nbre  heures
23. Matricule  Section
24. Matricule  Groupe
25. Code  mod, Matricule  Code  filière
Question :
Concevoir un schéma de relations en 3FN, à partir de cet ensemble de DFs en appliquant
l’algorithme de synthèse.
10
www.etudpdf.com
Module BDD : L’algèbre relationnelle Mme H.CHELLAKH
L’algèbre relationnelle
1. Introduction :
L’algèbre relationnelle a été inventée par E.Codd comme une collection d’opérations
formelles qui agissent sur des relations et produisent les relations en résultats. On peut considérer
que l’algèbre relationnelle est aux relations ce qu’est l’arithmétique aux entiers. Dans le modèle
relationnel, c’est l’algèbre relationnelle qui fournit cet ensemble d’opérations, permettant de
formuler des requêtes qui extrairont des données de la base. Une suite d’opérations forme une
expression algébrique relationnelle dont le résultat sera également une relation représentant le
résultat d’une requête.
L’algèbre relationnelle est importante à plusieurs titres. D’une part, elle fournit une
fondation formelle pour les opérations du modèle relationnel. D’autres part, elle sert de base pour
l’implémentation et l’optimisation des requêtes dans les systèmes de gestion de bases de données
relationnelles (SGBDR), enfin plusieurs de ses concepts sont intégrés à SQL (Standard Query
Language) , le langage de requête des SGBDR.
L’algèbre relationnelle est souvent considérée comme faisant partie du modèle relationnel.
Ses opérations peuvent être divisées en deux groupes. Un groupe comprend les opérations
ensemblistes et est issue de la théorie mathématique des ensembles. Parmi ces opérations figurent
l’union, l’intersection, la différence et le produit cartésien. L’autre groupe comprend des
opérations développées spécifiquement pour les bases de données, notamment la sélection, la
projection et la jointure.
Comme il n’est pas possible de réaliser certaines requêtes de base à l’aide des seules
opérations de l’algèbre relationnelle d’origine, des opérations supplémentaires ont été ajoutées en
raison de leur importance dans de nombreuses applications de bases de données. Parmi celles-ci
figurent les fonctions agrégats, qui permettent d’agréger des données de différentes tables, ainsi
que d’autres types de jointures et d’unions.
2. Les opérations ensemblistes (binaires) :

2.1 L’union :
Opération portant sur deux relations de même schéma Relation1 et Relation2 consistant à
construire une relation de même schéma Relation3 ayant pour tuples ceux appartenant à Relation1
ou Relation2 ou aux deux relations (les tuples en doubles sont éliminés).
Plusieurs notations ont été introduites pour cette opération, selon les auteurs :
 Re lation1  Re lation 2
 Union (Relation1, Relation2)
 Append (Relation1, Relation2)
2.2 L’intersection :
et Relation2.
Plusieurs notations ont été introduites pour cette opération, selon les auteurs :
 Re lation1  Re lation 2
 Intersect (Relation1, Relation2)
 And (Relation1, Relation2)
www.etudpdf.com
2.3 La différence :
et n’appartenant pas à Relation2.
La différence est un opérateur non commutatif : l’ordre des relations opérandes est donc
important. Plusieurs notations ont été introduites, selon les auteurs :
 Relation1 - Relation2
 Différence (Relation1, Relation2)
 Remove (Relation1, Relation2)
 Minus (Relation1, Relation2)
2.4 Le produit cartésien : (les deux relations n’ont pas nécessité d’avoir le même schéma de
relation).
Opération portant sur deux relations Relation1 et Relation2 consistant à construire une
relation Relation3 ayant pour schéma la concaténation de ceux des relations opérandes et pour
tuples toutes les combinaisons des tuples des relations opérandes.
Des notations possibles pour cette opération sont :
 Relation1 x Relation2
 Product (Relation1, Relation2)
 Times (Relation1, Relation2)
Exemple : Etudiant1 Nom Prénom Date-nais Moyenne
Ammari Mohammed 23/11 /1988 12
Mohammadi Ayoub 07/03/1985 10.5
Barket Hocine 12/12/1982 8
Etudiant2 Nom Prénom Date-nais Moyenne
Allouche Fatima 01/02/1987 13
Etudiant1  Etudiant2
Etudiant1  Etudiant2
Etudiant1 - Etudiant2
Etudiant2 - Etudiant1
Module Libellé-mod
Algo
Structure
www.etudpdf.com
Etudiant1 x Module
Etudiant3 Nom Prénom Date-nais Moyenne Libellé-mod
Ammari Mohammed 23/11 /1988 12 Algo
Ammari Mohammed 23/11 /1988 12 Structure
Mohammadi Ayoub 07/03/1985 10.5 Algo
Mohammadi Ayoub 07/03/1985 10.5 Structure
Barket Hocine 12/12/1982 8 Algo
Barket Hocine 12/12/1982 8 Structure
3. Les opérations spécifiques :

3.1 La projection :
La projection est une opération spécifique aux relations qui permet de supprimer des
attributs d’une relation. Son nom provient du fait qu’elle permet de passer d’une relation n-aire à
une relation p-aire avec p < n, donc d’un espace à n dimensions à un espace à moins de dimensions.
La projection sur une Relation1 consistant à composer une Relation2 en enlevant à la
relation initiale tous les attributs non mentionnés en opérandes (aussi bien au niveau du schéma que
des tuples) et en éliminant les tuples en double qui sont conservés une seule fois).
Les notations suivantes sont utilisées pour cette opération, en désignant par Attributi,
Attributj… Attributm les attributs de projection :
  Attributi, Attributj... Attributm (Re lation1)
 Re lation1 [ Attributi , Attributj... Attributm ]
 Pr oject (Re lation1, Attributi, Attributj... Attributm)
Exemple :
Etudiant Nom Prénom Date-nais Moyenne Libellé-mod
Ammari Mohammed 23/11 /1988 12 Algo
Ammari Mohammed 23/11 /1988 12 Structure
Mohammadi Ayoub 07/03/1985 10.5 Algo
Mohammadi Ayoub 07/03/1985 10.5 Structure
Barket Hocine 12/12/1982 8 Algo
Barket Hocine 12/12/1982 8 Structure
 Nom, Pr énom ( Etudiant )

Etudiant Nom Prénom
Ammari Mohammed
Mohammadi Ayoub
Barket Hocine
3.2 La restriction (la sélection) :

La restriction est aussi une opération spécifique unaire, qui produit une nouvelle relation en
enlevant les tuples à la relation opérande selon un critère.
La restriction est une opération sur une relation Relation1 produisant une Relation2 de
même schéma, mais comportant les seuls tuples qui vérifient la condition précisée en argument.
Les conditions possibles sont du type : <Attribut> <Opérateur> <Valeur>
Où l’opérateur est un opérateur de comparaison choisi parmi , , , , , .
L’attribut doit appartenir à la relation sur laquelle s’applique le critère.
Les notations suivantes sont utilisées pour la restriction :
www.etudpdf.com
  condition (Relation1)
 Relation1 [Condition]
 Restrict (Relation1, condition)
Exemple :
Etudiant1 [moyenne < 10]

3.3 La jointure :
L’opération de jointure sert à former des tuples uniques à partir de tuples liés provenant de
deux relations. Elle est très importante pour toute base de données comportant plusieurs relations
parce qu’elle permet de traiter des liaisons au sein de relations. On peut la définir comme suit :
La jointure est une opération consistant à rapprocher selon une condition les tuples de deux
relations Relation1 et Relation2 afin de former une troisième relation Relation3 qui contient
l’ensemble de tous les tuples obtenus en concaténant un tuple de Relation1 et un tuple de Relation2
vérifiant la condition de rapprochement.
La condition doit être du type <Attribut1> <opérateur> <Attribut2>
Où Attribut1 appartient à Relation1 et Attribut2 appartient à Relation2.
Selon le type d’opérateur on distingue :
 L’équi-jointure dans le cas où l’opérateur est « = », qui est une véritable composition de
relations au sens mathématique du terme.
 L’inéqui-jointure dans les autres cas, c'est-à-dire avec des opérateurs , , , ,  .
Dans le cas d’équi-jointure, les deux attributs égaux apparaissent chacun dans le résultat : il y a
donc duplication d’une même valeur dans chaque tuple. Afin d’éliminer cette redondance, on
définit la jointure naturelle comme suit :
La jointure naturelle est une opération consistant à rapprocher les tuples de deux relations
Relation1 et Relation2 afin de former une troisième relation Relation3 dont les attributs sont l’union
des attributs de Relation1 et Relation2, et dont les tuples sont obtenus en composant un tuple de
Relation1 et un tuple de Relation2 ayant même valeurs pour les attributs de même nom.
L’opération de jointure est représentée par l’une des notations suivantes, la condition étant
simplement omise dans le cas de jointure naturelle (c’est alors l’égalité des attributs de même
nom) :
 Relation1 Relation2
Condition
 Join (Relation1, Relation2, Condition)
Exemple :
Employé N°SS Nom Prénom Date- Adresse Sexe N°Sce
nais
80100 Kadri Mourad 12/02/80 Sétif M 5
72123 Mehani Ali 04/05/72 Alger M 4
59600 Mokrani Rabah 01/05/59 BBA M 5
70560 Chaib Zahia 23/12/70 BBA F 2
www.etudpdf.com
Service Code Sce Libellé service
1 Recherche
2 Administration
3 Finance
4 Comptabilité
5 Technique
1. Equi-jointure
Employé Service
N°Sce=CodeSce
Employé N°SS Nom Prénom Date- Adresse Sexe N°Sce Code Libellé service
nais Sce
80100 Kadri Mourad 12/02/80 Sétif M 5 5 Technique
72123 Mehani Ali 04/05/72 Alger M 4 4 Comptabilité
59600 Mokrani Rabah 01/05/59 BBA M 5 5 Technique
70560 Chaib Zahia 23/12/70 BBA F 2 2 Administration
On remarque que les attributs NSce et CodeSce sont identiques dans tous les tuples, l’un des deux
attributs est superflu.
2. Jointure naturelle :
Employé Service
Employé N°SS Nom Prénom Date- Adresse Sexe N°Sce Libellé service
nais
80100 Kadri Mourad 12/02/80 Sétif M 5 Technique
72123 Mehani Ali 04/05/72 Alger M 4 Comptabilité
59600 Mokrani Rabah 01/05/59 BBA M 5 Technique
70560 Chaib Zahia 23/12/70 BBA F 2 Administration
Une jointure naturelle équivaut à une équi-jointure suivie de la suppression des attributs superflus.
www.etudpdf.com
4. Les opérations dérivées :
Les opérations dérivées peuvent être obtenues par combinaison des opérations précédentes.
4.1 La division : notée 

C’est un opérateur binaire, il s’applique entre deux relations R1 et R2 pour donner une
relation R=R1  R2. Le schéma de la relation R2 doit être une partie du schéma de R1. La relation R
obtenue aura le schéma de R1 moins les attributs de R2. Tout tuple de R sera tel que : Quelque soit
le tuple de R2 qui lui sera concaténé, il donnera un tuple de la relation initiale R1.
Exemple :
Soit la relation Module décrite dans la table suivante :
Cod-Mod Libellé-Mod Coef
MATHS01 Mathématiques 2
TM06 Logique 3
ALGO Algorithmique 5
ARCHI01 Architecture 5
Et soit la relation Ens-Mod décrite comme suit :
Cod-Mod Num-Ens
ALGO E1
MATHS01 E2
ARCHI01 E1
TM06 E3
ALGO E2
MATHS01 E1
TM06 E1
TM06 E4
On voudrait répondre à la question suivante : quels sont les numéros d’enseignants qui
enseignent tous les modules (i.e les 4 modules décrit dans la relation module) ?
On effectue d’abord une projection de la relation Module sur l’attribut Cod-Mod, dans une nouvelle
relation R1=Ens-Mod sur la relation R2.
R 2   Code  Mod ( Module)
R3  R1  R 2 et sera constitué d’un seul attribut Num-Ens avec une seule valeur E1.
www.etudpdf.com
Module BDD : Le Langage SQL Mme H.CHELLAKH
Le langage SQL
1. Introduction :
Le passage au modèle physique, nous pose à priori, deux problèmes de taille :
1. Définir l’environnement matériel : spécifications de la machine, type de mémoire de
stockage…
2. Définir l’environnement logiciel : Quel SGBD relationnel doit-on utiliser ?
Cependant, l’utilisation d’un SGBD, nous dispense de toute préoccupation de l’aspect matériel.
En effet l’un des objectifs d’un SGBD est l’indépendance physique : le SGBD prend en charge les
détails techniques de stockage de données.
Cependant le choix d’un SGBD relationnel, parmi ceux disponibles sur le marché (ACCESS,
ORACLE, MICROSOFT SQL SERVER…etc.), il est vrai que le langage de définition de données,
pourrait être différent d’un SGBD à un autre.
Fort heureusement ce n’est pas le cas, la majorité des SGBD relationnels, utilisent le même
langage de définition de données. Structered Query Language : SQL est considéré comme le
standard incontournable de définition et d’interrogation de données.
Niveau Conceptuel Niveau Logique
(Modèle E/A) MLD

Réel Perçu
Conception de BDD Modèle relationnel
Niveau Physique
S
B G
D B
D D
SQL est un langage informatique standard pour la communication avec les SGBDR. Il a été
défini par l’ANSI (Américan National Standar Institute) et l’ISO (International Standards
Organization).
Une caractéristique principale de SQL est qu’il est déclaratif et non procédural. Le
programmeur n’a pas à spécifier les étapes à suivre pour obtenir un résultat, il indique au SGBD ce
qui doit être accompli et il laisse alors le système décider par lui-même comment obtenir le résultat
souhaité.
Les instructions du langage SQL se divisent en deux catégories DDL et DML
 DDL (Data Définition Langage) : Permet de créer les tables de la BD, de spécifier les
attributs, les vues, modifier la structure d’une table ou même supprimer des tables.
 DML (Data Manipulation Langage) : permet de créer, modifier ou supprimer les
enregistrements (tuples) de tables déjà créer par le DDL.
SQL peut s’employer de deux manières différentes :
 Interactive : Permet à l’utilisateur d’exécuter des commandes directement sur le
SGBDR et de visualiser directement les résultats.
 Intégrée : Les instructions SQL font partie d’un programme écrit en langage C, C++,…
www.etudpdf.com
2. Langage de définition de données (DDL) :

2.1 Création de tables :
Les tables correspondent à un schéma relationnel, peuvent être créées par le SGBD, en utilisant
une commande de création CREATE TABLE, qui doit spécifier :
 Le nom de la table
 Le nom de chaque attribut de la table, ainsi que son type et sa longueur
Syntaxe :
CREATE TABLE <Nom de table> (attribut1 type1, attribut2 type2,…) ;
Type Signification
Chaîne de caractère de longueur fixe. Si la longueur n’est

CHAR (longueur) pas précisée, elle est égale à 1. la longueur maximale est
définie par le SGBD.
NUMBER (p,s) Nombre avec p chiffres significatifs, et s décimales
DATE Valeurs de date et d’heure
Exemple :
 Création de la table étudiant :
CREATE TABLE Etudiant (Matricule char (9), Nom-Etud char (20), Prénom-Etud char (20),
Adresse-Etud char (250)) ;
 Création de la table Etud-Mod :
CREATE TABLE Etud-Mod (Matricule char (9), Cod-Mod char(6), Moyenne Number (4,2)) ;
2.2 Modification de la structure d’une table :

Il est possible, qu’on veuille modifier la structure d’une table (ajouter, modifier ou
supprimer un attribut du schéma de la relation), après sa création. Ceci peut être dû à une erreur de
conception détectée après le début de l’implémentation.
 Ajouter un ou plusieurs attributs :
Se fait à l’aide de la commande ALTER TABLE……….ADD…..
ALTER TABLE <Nom de la table> ADD (attribut1 type1, attribut2 type2,…)
Exemple :
ALTER TABLE Etudiant ADD (Date-Nais date),
 Modifier un ou plusieurs attributs :
Se fait à l’aide de la commande ALTER TABLE……….MODIFY….
ALTER TABLE <Nom de la table> MODIFY (attribut1 type1, attribut2 type2,…) ;
Exemple :
ALTER TABLE Etudiant MODIFY (Nom-Etud char (25)) ;
Cette commande modifie la taille de l’attribut Nom-Etud de la table Etudiant.
2.3 Suppression d’une table :

Si une table a été créée par erreur, il est possible de la supprimer. Si cette table contient des
enregistrements, ils seront entièrement supprimés. La commande SQL utilisée est DROP TABLE
Syntaxe :
DROP TABLE <Nom de la table> ;
Exemple :
DROP TABLE Etudiant ;
Cette commande supprime la table Etudiant précédemment créée.
www.etudpdf.com
3. Langage de Manipulation de données (DML) :

Un langage de manipulation de données, permet d’accéder au contenu d’une base de
données, soit dans le but de faire des mises à jour (ajouter, supprimer, modifier), soit afin
d’effectuer des recherche, ou soumettre des interrogations.
3.1 Mise à jour des données d’une BD :

3.1.1 Ajout d’enregistrement : La commande INSERT INTO TABLE
Syntaxe :
INSERT INTO TABLE <Nom de la table> VALUES (val1, val2,…) ;
Chaque valeur (val1, val2,…) correspond dans l’ordre à un attribut de la table spécifiée.
Exemple :
INSERT INTO TABLE Etudiant VALUES (‘52006’, ‘Ameur’, ‘Yacine’, ’10 /05/1980’) ;
3.1.2 Modification d’enregistrement : La commande UPDATE TABLE
Syntaxe :
UPDATE TABLE <Nom de la table>
SET <Nom-Attribut> = <val>
WHERE <condition>
Après la commande UPDATE TABLE, on spécifie le nom de la table. Après la clause SET, on
spécifie la modification à effectuer sur les enregistrements et après la clause WHERE, on écrit la
condition qui désigne les enregistrements concernés par la modification.
Exemple :
UPDATE TABLE Etudiant
SET Date-Nais = ‘10/10/1986’
WHERE Matricule = ‘52004’ ;
3.1.3 Suppression d’enregistrements : DELETE FROM TABLE
Syntaxe :
DELETE FROM TABLE <Nom de la table>
WHERE <condition> ;
Après la commande DELETE FROM TABLE on spécifie le nom de la table. Après la clause
WHERE, on écrit la condition qui désigne les enregistrements concernés par la suppression.
Exemple :
DELETE FROM TABLE Etudiant
WHERE Nom = ‘Ameur’;
Cette commande supprime l’enregistrement correspondent à l’étudiant ‘Ameur’
Remarque :
La commande DELETE TABLE < Nom de la table> ; a pour effet de supprimer tous les
enregistrements de la table ; mais sans supprimer la structure.
www.etudpdf.com
2. Interrogation d’une base de données :

2.1 La Projection :
La projection consiste à se focaliser sur un sous ensemble des colonnes d’une table, et de faire
abstraction des autres. Il suffit donc de spécifier la table, et les colonnes sur lesquelles on veut se
projeter en respectant la syntaxe suivante :
 Syntaxe :
SELECT <attribut1>,<attribut2>,…<attributn>
FROM <Nom-table> ;
Exemple :
Matricule Nom Prénom Adresse
52003502 Abed Karim El annasser
52003305 Benali Samir Bordj ghedir
SELECT Matricule, Nom, Prénom

FROM Etudiant ;
Résultat obtenu
Matricule Nom Prénom
52003502 Abed Karim
52003305 Benali Samir
Remarque :
Si l’on veut afficher la table sans projection, il est possible de spécifier l’ensemble des
attributs, ou plus simplement d’utiliser le caractère générique *, on écrira par exemple :
SELECT *
FROM Etudiant ;
2.2 La Sélection ou Restriction :

Il est également possible d’éliminer les lignes (tuples), ne vérifiant pas une condition précise.
On spécifie alors une contrainte sous forme de condition booléenne, et seules les lignes respectant
cette contrainte sont sélectionnées.
 Syntaxe :
SELECT <attribut1>,<attribut2>,…<attributn>
FROM <Nom-table>
WHERE <Condition>;
Exemple : On veut avoir la liste des étudiant admis dans un module donné.
SELECT *
FROM Etud-mod
WHERE (cod-mod=’SYS01’) and (note>=10);
Si on s’intéresse uniquement aux matricules de ces étudiants, il est également possible de
combiner la projection et la restriction dans une même requête.
SELECT Matricule
FROM Etud-mod
WHERE (cod-mod=’SYS01’) and (note>=10);
4
www.etudpdf.com
Les conditions exprimées dans une restriction, sont basées sur la logique des propositions, elles
peuvent contenir des conjonctions (and), des disjonctions (or) ou des négations (not).
Chaque élément de la condition est une comparaison (=, < > ,<, >, <=, >=) entre deux attributs
de même type, ou entre un attribut et une valeur de même type.
Remarque :
Dans les comparaisons des chaînes de caractères, il est possible d’utiliser l’opérateur like, et les
caractères génériques ‘%’ et ‘ ?’, pour exprimer les requêtes du genre les noms des étudiants qui
commencent par ‘BEN’, ou dont le deuxième caractère est ‘A’.
‘%’ remplace une chaîne de caractère de taille quelconque (supérieure ou égale à 0).
‘ ?’ remplace un seul caractère
Exemple :
SELECT Matricule, Nom, Prénom SELECT Matricule, Nom, Prénom
FROM Etudiant FROM Etudiant
WHERE Nom like ‘BEN%’ ; WHERE Nom like ‘?A%’ ;
2.3. La jointure:
Supposons que l’on veuille avoir les noms des étudiants admis au module de code ‘SYS01’.
La table Etud-Mod, ne contient pas les noms des étudiants, il faudrait la mettre en lien avec la table
Etudiant, pour obtenir cette information. Il s’agit d’une opération de jointure entre ces deux tables :
Matricule Nom Prénom Adresse

52003502 Abed Karim El annasser
52003305 Benali Samir Bordj ghedir
Matricule Cod-Mod Note

52003502 BD 14
52003305 BD 6 .5
1°) la jointure entre ces deux tables :
SELECT Matricule, Nom, Prénom, Cod-Mod, Note
FROM Etud-mod, Etudiant (1)
WHERE Etud-mod.Matricule= Etudiant.Matricule (2)
Remarque :
(1) exprime le produit cartésien entre les tables Etud-Mod et Etudiant.
(2) Exprime la condition de jointure.
Matricule Nom Prénom Cod-Mod Note

52003502 Abed Karim BD 14
52003305 Benali Samir BD 6 .5
2°) pour avoir la liste des étudiants admis au module ‘SYS01’

FROM Etud-mod, Etudiant
WHERE (Cod-Mod= ‘SYS01’) and (note>= 10)
And (Etud-mod.Matricule= Etudiant.Matricule) ;
www.etudpdf.com
Remarque :
L’attribut Matricule existe dans les deux tables, pour lever l’ambiguïté dans ce cas nous
devons préciser les noms des tables à chaque fois que l’attribut apparaît dans la requête. Une autre
solution est d’utiliser des nom de variables associés à chaque table comme suit :
FROM Etud-mod EM, Etudiant E
WHERE (Cod-Mod= ‘SYS01’) and (note>= 10) and (EM.Matricule= E.Matricule) ;
La variable E est associée à la table Etudiant et la variable EM est associée à la table Etud-Mod.
 Jointure par imbrication de requêtes :
Il existe d’autres façons d’exprimer la jointure, en raisonnant de façon incrémentale sur les
différentes relations induites par la jointure.
Pour obtenir le même résultat que l’exemple précédent, on pourrait exprimer la requête en langage
naturel, de la façon suivante :
Les matricules, noms, prénoms de la relation Etudiant, pour lesquels, le matricule se trouve dans la
relation Etud-Mod, avec les conditions Cod-Mod=’SYS01’ et note>= 10.
En SQL on obtiendra :

FROM Etudiant
WHERE Matricule IN (SELECT Matricule
FROM Etud-Mod
WHERE (Cod-Mod= ‘SYS01’) and (note>= 10));
L’opérateur IN exprime l’inclusion ensembliste. Les deux ensembles comparés par cet opérateur
doivent être du même type. On ne peut pas avoir des comparaisons comme :
… WHERE Matricule IN SELECT Nom…
Ou encore :
… WHERE Matricule In SELECT *…
Une troisième solution pour exprimer la même requête, consiste à utiliser l’opérateur existentiel :

FROM Etudiant E
WHERE EXISTS SELECT Matricule
FROM Etud-Mod EM
WHERE (Cod-Mod= ‘SYS01’) and (note>= 10) and
(EM.Matricule=E.Matricule);
La condition associée au WHERE est vraie lorsque l’ensemble retourné par la clause
SELECT, n’est pas vide. C'est-à-dire, lorsqu’il y a au moins un matricule dans Etud-Mod qui vérifie
à la fois les conditions Cod-Mod= ‘SYS01’) and (note>= 10), et qu’il soit le même que celui de la
table Etudiant.
www.etudpdf.com
2.4 L’intersection :
Il est possible d’exprimer l’intersection entre deux ensembles, à condition qu’ils aient la
même structure. Par exemple pour connaître les matricules des étudiants ayant obtenu la moyenne
en même temps dans les modules de code ‘SYS01’ et ‘BD’, on peut écrire :
SELECT Matricule
FROM Etud-Mod
WHERE (Cod-Mod=’SYS’) and (note>=10)
INTERSECT
SELECT Matricule
FROM Etud-Mod
WHERE (Cod-Mod=’BD’) and (note>=10)
Pour obtenir leurs noms, il est possible de joindre le résultat de cette jointure à la table Etudiant
comme suit :
SELECT Nom
FROM Etudiant
WHERE Matricule IN (
SELECT Matricule
FROM Etud-Mod
WHERE (Cod-Mod=’SYS’) and (note>=10)
INTERSECT
SELECT Matricule
FROM Etud-Mod
);
Il est possible d’exprimer la même requête sans utiliser l’opérateur INTERSECT, en exploitant la
conjonction. La solution serait:
SELECT Nom
FROM Etudiant
SELECT Matricule
FROM Etud-Mod
WHERE (Cod-Mod=’SYS’) and (note>=10))
AND Matricule IN (
SELECT Matricule
FROM Etud-Mod
WHERE (Cod-Mod=’BD’) and (note>=10));
2.5 La différence :
La différence entre deux ensembles de même structure, peut être exprimée de la même façon
que dans les langages algébriques. Par opposé à l’exemple précédent, si l’on veut avoir les
matricules et les noms des étudiants ayant obtenu la moyenne dans le premier module, et échoué
dans le deuxième module, on peut écrire :
www.etudpdf.com
SELECT Matricule, Nom

FROM Etudiant
SELECT Matricule
FROM Etud-Mod
MINUS
SELECT Matricule
FROM Etud-Mod
);
Ou bien :
FROM Etudiant
SELECT Matricule
FROM Etud-Mod
AND Matricule NOT IN (
SELECT Matricule
FROM Etud-Mod
);
Ou encore:
FROM Etudiant E
SELECT Matricule
FROM Etud-Mod
AND NOT EXISTS (
SELECT Matricule
FROM Etud-Mod EM
And (E.Matricule= EM.Matricule)
);
2.6 La division:
SQL ne comporte pas d’opérateur spécifique à la division. Cependant il est possible
d’exprimer la sémantique de cet opérateur algébrique, en se basant sur les opérateurs logiques.
Prenant par exemple, la requête suivante :
« Quels sont les étudiants (Matricules, Noms), qui ont obtenu une note supérieure à 10 dans
tous les modules ? »
Avant de donner la solution, nous proposons de reformuler la requête de façon plus
intuitive, par rapport aux opérateurs logiques.
Ce sont les étudiants pour lesquels, il n’y a pas de module, dans lequel ils n’ont pas une
note supérieure ou égale à 10.
8
www.etudpdf.com
Il suffit maintenant de reproduire ce raisonnement en respectant la syntaxe de SQL :

FROM Etudiant E
WHERE NOT EXISTS (
SELECT Cod-Mod
FROM Module M
WHERE NOT EXISTS (
SELECT Matricule
FROM Etud-Mod EM
WHERE (EM.Cod-Mod=M.Cod-Mod)
And (EM.Matricule=E.Matricule) and
(Note>=10)
);
2.7 Les fonctions mono lignes :

SQL dispose d’un jeu de fonctions dites mono lignes, permettant d’effectuer des calculs,
ainsi que des conversions de types ou de formats.
 Manipulation de caractères :
Fonction Résultat
Conversion d’une chaîne de
LOWER (char)
caractères vers la minuscule
Conversion d’une chaîne de
UPPER (char)
caractères vers la majuscule
Concaténation de deux chaînes de
CONCAT (char, char)
caractères
LENGTH (char) Longueur d’une chaîne de caractères
Exemples :
Pour afficher les noms des étudiants en majuscule, quelque soient leurs formats de saisie, on
peut écrire :
SELECT UPPER (Nom)
FROM Etudiant;
Il est également possible d’exploiter ces fonctions dans les conditions de restrictions.
SELECT adresse
FROM Etudiant
WHERE LOWER (Nom) = ‘ameur’ and LOWER (Prénom) = ‘yacine’ ;
 Fonctions numériques :
Fonction Résultat
Arrondit un nombre à la précision
ROUND (number, précision)
spécifiée
Tronque le nombre à la précision
TRUNC (number, précision)
spécifiée
MOD (int, int) Reste de la division entière
Remarque : ROUND (2.698,2) retourne la valeur 2.70

TRUNC (2.698,2) retourne la valeur 2.69
www.etudpdf.com
Exemple :
SELECT Matricule, Cod-Mod, ROUND (note, 2)
FROM Etud-Mod ;
 Opérations sur les dates :
Fonction Résultat
Retourne la date après ajout du nombre de jours
Date+ nombre de jours
spécifié.
Retourne la date après suppression du nombre de jours
Date – nombre de jours
spécifié.
Date – Date Retourne le nombre de jours entre deux dates.
Exemples : ‘12-28-2006’ + 4 retourne ’01-01-2007’

‘12-28-2006’ - ’01-01-2007’ retourne -4
2.8 Les fonctions de synthèse :

Par opposition aux fonctions mono lignes, les fonctions de synthèse effectuent des calculs
sur un groupe de lignes, pour les synthétiser en une seule valeur. Par exemple la moyenne des notes
d’un étudiant, est calculée par rapport à toutes les lignes le concernant dans la table Etud-Mod.
Fonction Résultat
Retourne la moyenne des valeurs de la colonne
AVG (colonne)
spécifiée.
Retourne la somme des valeurs de la colonne
SUM (colonne)
spécifiée.
Retourne le nombre d’occurrences des valeurs de
COUNT (colonne)
la colonne spécifiée dans la table.
Retourne la valeur minimale de la colonne
MIN (colonne)
spécifiée.
Retourne la valeur maximale de la colonne
MAX (colonne)
spécifiée.
Exemples :
Pour calculer la moyenne des notes de l’étudiant de matricule 52004, il suffit d’écrire :
SELECT AVG (note)

FROM Etud-Mod
WHERE Matricule = ‘52004’;
Pour obtenir les étudiants dont la note au module BD est maximale :

SELECT Nom
FROM Etudiant
WHERE Matricule IN SELECT Matricule
FROM Etud-Mod
WHERE Cod-Mod = ‘BD’ and
Note = SELECT MAX (Note)
FROM Etud-Mod
WHERE Cod-Mod = ‘BD’;
10
www.etudpdf.com
Pour calculer le nombre d’étudiants ayant une note supérieure à 10, dans le module SYS01, on
écrit :
SELECT COUNT (*)
FROM Etud-Mod
WHERE (Cod-Mod = ‘SYS01’) and (Note >=10);
Remarque :
Les fonctions de synthèse ne peuvent pas apparaître dans une clause WHERE, car celle-ci,
est évaluée pour chaque ligne, alors que la fonction concerne un groupe de lignes.
2.9 Création de groupe de données :

SQL permet de partitionner un ensemble de données en groupes, sur la base d’un critère de
groupage. Par exemple, on peut s’intéresser aux données de la table Etud-Mod pour analyser les
résultats de chaque étudiant, et dans ce cas les lignes concernant un même étudiant doivent être
représentées de façon contiguë. Dans ce cas le critère de groupage serait l’attribut Matricule.
SELECT Matricule, Cod-Mod, Note Matricule Cod-Mod Note

FROM Etud-Mod 520001 BD 12
GROUP BY Matricule, Cod-Mod, Note; 520001 SYS01 8
520001 ROP 6
Remarque : Il n’est pas possible, de sélectionner un attribut 520004 BD 10
qui n’appartient pas aux critères de groupage, ce qui nous 520004 SYS01 14
oblige à rajouter Cod-Mod et Note dans ces critères. Mais
l’ordre de ces critères est important. 520004 ROP 12
Si on s’intéresse plutôt à analyser les résultats obtenus dans Cod-Mod Matricule Note
chaque module, on pourrait écrire : BD 520001 12
BD 520004 10
SELECT Cod-Mod, Matricule, Note SYS01 520001 8
FROM Etud-Mod
SYS01 520004 14
GOUP BY Cod-Mod, Matricule, Note;
ROP 520001 6
ROP 520004 12
Cependant, quand on veut faire des analyses par rapport à des groupes de données, il est
souvent plus utile de faire abstraction de certaines colonnes, ou de les remplacer par un calcul de
synthèse.
Plus concrètement, si on veut analyser les résultats de chaque module, on pourrait
s’intéresser à la moyenne du module, et faire abstraction des matricules des étudiants.
Cod-Mod AVG (Note)

SELECT Cod-Mod, AVG (Note)
DB 11
FROM Etud-Mod
GOUP BY Cod-Mod; SYS01 11
ROP 9
Remarque : Une fonction de synthèse ne peut être utilisée comme facteur de groupage.
11
www.etudpdf.com
2.10 Conditions sur les groupes :

La clause HAVING permet d’introduire des conditions sur les groupes, afin d’éliminer du
résultat les groupes n’obéissant pas à certains critères.
Cette clause est associée au GROUP BY, et ne peut être utilisée indépendamment de celui-ci.
Reprenons l’exemple précédent, en ne retenant que les modules dont la moyenne des notes est
supérieure ou égale à 10.
SELECT Cod-Mod, AVG (Note) On obtient alors le résultat suivant:

FROM Etud-Mod Cod-Mod AVG (Note)
GOUP BY Cod-Mod; DB 11
HAVING AVG (Note) >= 10 SYS01 11
La fonction AVG dans HAVING a la même interprétation que dans l’exemple précédent,
elle est évaluée à l’intérieur de chaque groupe.
2.11 Utilisation des vues dans SQL :

Le mécanisme des vues dans SQL permet de définir des tables virtuelles (n’ont pas
d’existence physique), dont l’un des objectifs est de permettre de façon simple et graduelle,
l’expression de certaines requêtes complexes.
Une vue correspond à la définition d’une table virtuelle, construite à partir de tables du
schéma relationnel à travers une requête.
Exemple 1 : On s’intéresse aux notes des étudiants dans les modules à coefficients 5, on peut
concevoir une vue comme suit :
DEFINE VIEW Etud-Mod5 (Matricule, Cod-Mod, Note)

AS SELECT Matricule, Cod-Mod, Note
FROM Etud-Mod, Module
WHERE (Etud-Mod.Cod-Mod=Module.Cod-mod) and (coef=5);
Etud-Mod5 est le nom de la vue, qui peut être considérée par la suite comme une table, et interrogée
dans les requêtes. On peut par exemple obtenir les matricules des étudiants ayant obtenu une note
supérieure ou égale à 10 dans ces modules en écrivant :
SELECT matricule
FROM Etud-Mod5 (*)
WHERE Note >=10;
Commentaire (*) : On spécifie le nom de la vue comme un nom de table.

On aurait pu obtenir le même résultat sans passer par la définition d’une vue, cependant si cette vue
doit être interrogée régulièrement, l’écriture des requêtes se trouve nettement allégée et simplifiée.
Exemple 2 :
On veut connaître les modules qui ont un nombre d’étudiants admis supérieur à la moyenne du
nombre d’étudiants admis. Il faudrait alors calculer le nombre d’étudiants admis dans chaque
module, ensuite la moyenne de ces nombres, et enfin sélectionner les modules dépassant cette
moyenne.
1°) Définition d’une vue dans laquelle nous aurons le nombre d’admis de chaque module :
DEFINE VIEW Mod-Admis (Cod-Mod, NB-Admis)
AS SELECT Cod-Mod, Count (Matricule)
FROM Etud-Mod
12
www.etudpdf.com
WHERE Note >= 10

GROUP BY Cod-Mod;
2°) On peut interroger cette vue comme suit:
SELECT Cod-Mod
FROM Mod-Admis
WHERE NB-Admis > (SELECT AVG (NB-Admis) (**)
FROM Mod-Admis );
Commentaire (**):
Cette clause SELECT calcule le nombre moyen d’admis dans les différents modules.
2.12 Tri du résultat d’une requête :

Le résultat d’une requête peut être organisé selon un ordre de tri (alphabétique ou
numérique) ascendant ou descendant, en rajoutant la clause ORDER BY à la fin de la requête.
Ainsi pour obtenir la liste des étudiants ayant réussi au module SYS01, affichée dans l’ordre
alphabétique des noms on peut écrire :
SELECT E.Matricule, E.Nom, E.Prénom Le résultat est trié par nom, alors que le
FROM Etud-Mod EM, Etudiant E prénom est utilise pour départager des
WHERE (Cod-Mod = ‘SYS01’) and (Note >= 10) étudiants ayant le même nom.
And (EM.Matricule = E.Matricule) L’ordre d’affichage du tri est ascendant par
ORDER BY E.Nom, E.Prénom ; défaut (A..Z), si l’on veut obtenir l’ordre
inverse, il suffit de rajouter le mot réservé
DESC Comme suit :
SELECT E.Matricule, E.Nom, E.Prénom

FROM Etud-Mod EM, Etudiant E
WHERE (Cod-Mod = ‘SYS01’) and (Note >= 10)
And (EM.Matricule = E.Matricule)
ORDER BY E.Nom DESC, E.Prénom DESC;
13
www.etudpdf.com

Bases de Données 3 LMD Informatique

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bases de Données 3 LMD Informatique

Uploaded by

Copyright:

Available Formats

Module BDD : Introduction aux BDD Mme H.

Introduction aux bases de données

2. Système d’information et gestion des données :

2.1 Pourquoi une démarche de conception ?

2. 2 Limites des SGF :

2. Incohérence des données :

3. Notions préliminaires : BD et SGBD

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

Représentation simplifiée d’un système de bases de données Utilisateur 4

3.3 Les niveaux d’une architecture de BD :

Niveau Vue physique

Les trois niveaux d’une architecture de Base de données

 Attribut (data item)

Exemple de structure CODASYL

Il permet aussi la représentation de classe et de liens de type « père-fils » entre ces

Voiture Avion Bus Train

Représente le lien d’agrégation

3.5 Objectifs des SGBD

2. Les concepts du modèle relationnel :

2.1 Domaine, attribut et relation :

ETUDIANT (Nom, N°SS, Tel_dom, Adresse, Tel_bureau, Age, Moy_notes).

Etudiant Nom N°SS Tel_dom Adresse Tel_Bureau Age Moy_notes

Arridj 820345666 035 68 12 48 25 rue 17 oct 035 68 12 12 19 12.5

Figure 2 : Attributs et tuples de la relation Etudiant

r ( R)  (dom( A1 )  dom( A2 )  ...  dom( An ))

2.2 Extensions et intensions

3. Les règles d’intégrité structurelle :

3.1 Unicité de clé :

VOITURE N°immatriculation N°sériemoteur Marque Modèle Année

739 AB 12 A69352 Fiat Tipo 96

3.2 Contrainte de référence :

R1 : EMPLOYE N°ss Prénom Nom Date nais Adresse Salaire N°sce

7123454 Mohammed Gharbi 23/07/71 Fg des jardins 30000 5

R2 : SERVICE N°sce Libellé sce

Figure 4 : Attributs et tuples des relations Employé et Service

3.3 Valeurs nulles et clés :

3.4 Contraintes de domaines :

4. Règles de passage du modèle Entité/Association au modèle

Modèle E/A Modèle relationnel

Règle 5 : Une relation R du modèle E/A de type

Dépendances fonctionnelles et normalisation des BDD

2. les dépendances fonctionnelles (DF) :

Domaine Ensemble Ensemble de

Nom d’attribut Signification

De là, nous constatons ce qui suit :

2.2. Propriétés des DF :

2.3. Typologie des DF :

Num  ens  Grade

2.4. Couverture minimale (irréductible)

2.5. Fermeture transitive :

2.6. Notion de clé de relation :

3. Les formes normales :

Matricule Nom-etud Prénom-etud Cod-mod Moyenne

3.1 Première forme normale : (1FN)

Résultats ( Matricule-Cod-mod, Nom-etud, Prénom-etud, Note1, Note2, Synt, Ratt)

3.2 Deuxième forme normale : (2FN)

Num-ens Nom-ens Prénom-ens Date-nais-ens Adresse-ens Grade Nbr-

On remarque que le nombre d’heures d’enseignement dépend uniquement du grade de

3.3 Troisième forme normale : (3FN)

3.4 Forme normale de Boyce Codd : (BCFN)

Matière Classe Code-ens

On remarque qu’il y a une redondance entre Matière et Code-ens.

2. Les opérations ensemblistes (binaires) :