coursSGBD 2012-2013

École Nationale des Sciences Année Universitaire 2012/2013
Appliquées de Kenitra
Université Ibn Tofail
Le Système d’Information d’Entreprise
Habiba Chaoui
Filière Génie Informatique
Définitions
Système d'information:
 Ensemble de procédures et d'infrastructures

qui définissent et supportent le flux
d'informations à l'intérieur d'une structure
organisée
 Communément, basé sur une infrastructure

électronique
2
Définitions
Système d'information de l'entreprise:

 Application de l'informatique à l'organisation de
l'entreprise
 Il a comme objectif la distribution des informations à
des personnes qui opèrent à l'intérieur et à l'extérieur
de l'entreprise au moment où l'information est
nécessaire
Définit des procédures qui permettent

 La collecte des données dans des archives organisées
 L'extraction des informations à travers le traitement des
données
 La distribution des informations aux utilisateurs
3
Système d'information de
l'entreprise
l'ensemble des éléments qui orientent la
construction d'un système d'information d'entreprise
 Les phénomènes, internes ou externes, que
l'entreprise veut représenter
 La nature de l'information que l'entreprise s'attend à
obtenir
 Le mode par lequel l'entreprise veut représenter les
phénomènes
 lors de la reconnaissance de l'événement
 les détails de l'entreposage
 la précision avec laquelle nous suivons l'évolution du temps
4
l'entreprise
Les éléments qui composent le système d'information
sont:
 Données, structurées et maintenues de façon organisé
 De Configuration opérationnelles
 De Prise en charge
 De statut
 Les procédures et processus
 Acquisition
 Contrôle et traitement
 Planification
 Des moyens et des outils pour le traitement de l'information
 Les serveurs, postes de travail, les terminaux de collecte de
données, équipement de réseau, ...
5
l'entreprise
Système d'information d'entreprise (définition II)
 Ensemble de données, de procédures, de modèles
organisationnels et de moyens adoptés pour utiliser
l‘informatique dans l'entreprise
 Ensemble de données qualitatives et quantitatives

obtenues sur l'état passé, présent et future des
phénomènes de l'entreprise contrôlés et gérés
 La structure du système d'information définit et limite

le système d'information de l'entreprise
6
l'entreprise
Le système d'information d'entreprise est
intrinsèquement dynamique.
 Les facteurs qui causent des changements structurels
dans le système d'information
 Internes (amélioration de la performance, ...)
 Externes (contraintes imposées par l‘état ou par des clients
particuliers ou des fournisseurs, de la dynamique du marché,
..)
 L'évolution doit être en harmonie, en développant au

maximum la complémentarité et l'intégration entre les
différents composants
7
PLACE DU SYSTEME D ’INFORMATION DANS UNE ORGANISATION
L’approche Systémique permet de représenter une Organisation ou Entreprise ( Système )
en 3 Sous-systèmes interdépendants :
Il permet d ’assigner des
S/SYSTEME DE PILOTAGE objectifs à l’entreprise en
transmettant des ordres au S.I .
Les Membres de Direction Il analyse l ’environnement
interne et externe du Système
Information : pour produire des décisions .
Décision à mémoriser Information
mémorisée
S/SYSTEME D ’INFORMATION
 COLLECTE les données Il alimente le Système en
informations d ’origine interne
ENVIRONNEMENT  MEMORISE les données manipulées ou externe , les mémorise , les
traite puis les communique aux
EXTERIEUR
 TRAITE les données stockées autres sous-systèmes .
 TRANSMET les données vers l’extérieur et

l’intérieur du système
Information Information :
mémorisée Représentation à mémoriser
S/SYSTEME OPERANT Il assure la production des biens

et des services internes et
externes au système .
L’ensemble du Personnel exécutant
8
Exemple : SYSTEME D ’INFORMATION d’une Entreprise Commerciale
S/SYSTEME DE PILOTAGE = Direction

Commande au Fournisseur
Statistiques sur Décision : Nouveaux Produits
Règlement au fournisseur
les Ventes à commercialiser
S/SYSTEME D ’INFORMATION
Fournisseur  Employés du Service Commercial
 Employés du Service comptable
 Secrétaires
Bon de livraison
Marchandise
 Ordinateurs + imprimantes
Facture Fournisseur Bon de Commande Marchandise + Bon de livraison
Client + Facture Client
S/SYSTEME OPERANT
Représentants commerciaux
Commande Client Marchandise + Bon de livraison

Règlement + Facture Client
Client
9
Structure d’un Système d’Information
au Niveau des Ressources Humaines
Utilisateurs Rôle du Système d ’information
Cadres supérieurs S/S Production d’informations à la demande

pour assister des décisions complexes
Stratégie
- Décisions répétitives pour la conduite
Gestionnaires d’opérations
S/S des opérations courantes
( Cadres intermédiaires et - Traitement des données mémorisées et
Gestion et Contrôle
contrôleurs de gestion ) édition de documents de liaison
des Opérations - Communication interne et externe
des informations
Exécutants et Enregistrement des transactions

Opérateurs de Saisie S/S élémentaires ( saisie des faits
Transactionnel élémentaires et mémorisation )
10
Distinction entre SYSTEME D’INFORMATION et SYSTEME INFORMATIQUE
Organisation = SYSTEME
S/Système Décisions programmables (obtenues grâce au S/S d’information )

de Décision Décisions non programmables
S/Système Tâches de gestion manuelles

d’information Tâches de gestion automatisées Informatique de gestion
Aide à la prise de décision Informatique décisionnelle
S/Système Intervention de l’homme

Opératoire Intervention de la machine Informatique industrielle
Le Système informatique représente l’ensemble du matériel et du logiciel informatiques

utilisés dans l ’organisation ( Informatique décisionnelle + Informatique de gestion
+ Informatique industrielle )
11
Conduite d’un Projet de Système Automatisé d’Information ( S.A.I )
Plan - Etude d’opportunité : Le Projet répond-il aux objectifs du Système de Décision ?

- Etude de faisabilité
Stratégique
- Evaluation économique
Plan - Déterminer les besoins en équipement matériel et logiciel

Tactique - Désigner une Equipe de Développement (Chef de Projet + Analystes Programmeurs
ou SSII)
- Engagement financier
Plan - Spécification détaillée du Projet

d’Action - Etapes , Phases et Calendrier de réalisation
- Contraintes
Conception - Etude Conceptuelle ( Fonctionnelle )

- Etude Logique ( Organique )
et Mise en
- Etude Physique ( Opérationnelle )
oeuvre - Installation et Tests
Schéma Directeur de Projet = Plan Startégique + Plan Tactique + Plan d’Action )

12
Systèmes d’information ( S.I )
Mé
th
ode
s Ou
t
il
s
*
Ge
s
ti
ond
epr
oj
et
s(
év
al
ua
ti
o
n,C
on
du
it
e) L
o
gi
ci
el
deg
e
s
ti
ond
e
pr
oj
e
t
*
An
al
y
se,
Con
ce
pt
io
nd
esS
.I A
t
el
i
erd
eGé
n
ie
Log
i
c
ie
l
(M
er
is
e,
Axi
a
l,
OMTU
,ML,
et
c…)
*R
é
tr
o-
Con
ce
pt
i
ond
es
S.
I
Bases de données
Mét
ho
de
s Ou
ti
l
s
*
Te
c
hn
i
que
sde
Ge
s
ti
o
ndef
i
chi
e
rs *
S
ys
t
ème
s
deG
e
st
i
on
def
i
ch
i
er
s
*M
od
è
l
esde
b
as
es
de
do
nn
ée
s(hi
é
ra
rc
hi
qu
e, *
S
ys
t
ème
de
ge
s
t
io
nd
eba
se
de
do
n
né
es
r
é
s
ea
u,
re
la
t
i
on
ne
l
,o
bj
e…
t) (
Mod
e:
Se
rv
e
u
rde
fi
c
hi
er
*A
r
ch
i
te
ct
ur
e
s(
ce
n
tr
al
i
sé
e,
di
st
ri
bu
ée
,
ré
pa
rt
ie) Cl
i
en
t/
Se
rv
e
u
r,T
ra
ns
ac
t
io
n
ne
l
)
Systèmes logiciels
M é
t
ho
de
s O
ut
il
s
M
*a
que
t
ta
ge
d’a
p
pl
i
ca
ti
o
nsi
nf
or
mat
i
qu
es *
En
vi
ro
nn
e
me
nt
ded
év
el
op
pe
me
nt
*
Te
ch
ni
q
ues
dep
r
og
ra
mmat
i
ons
t
ruc
t
ur
ée (
éd
i
te
ur
,c
o
mp
il
a
te
ur
,dé
bo
gu
e
ur
,…
)
(l
a
nga
g
epr
oc
éd
u
ra
l,à
obj
e
ts
,é
vé
ne
men
t
i…
e
l) *Bi
bl
i
ot
hè
q
ue
de
fo
nc
ti
on
s
*A
s
sur
a
nc
e,
Qua
l
i
té
,T
es
tet
Mai
n
te
na
nc
ed
ul
og
il*
c
i
e Gé
né
ra
te
u
rd
’
éc
ran
et
d’
ét
at
13
La Gestion de projet informatique
Etape 1 : Identification des Objectifs de l ’Entreprise
Système de décision
Fo
nct
io
n d
e
ges
ti
on Nive
au N
i
vea
u Ni
vea
u
d
el
’en
t
repr
i
se S
t
rat
égi
que A
d
mi
nis
tr
at
i
f O
p
ér
at
io
nn
el
F
1 O
b
j. O
b
j. O
b
j.
F
2 O
b
j. O
b
j. O
b
j.
…
…. …
…. …
…. …
….
14
Exemple Entreprise « Les grands garages du Sud »
Etape 1: Activités : Vente & réparation de véhicules neufs et d ’occasion
Fonction Niveau Niveau Administratif Niveau Opérationnel

Stratégique
Direction Amélioration
des ventes (C.A)
Améliorer le contact client  * Calcul des coûts d’achat et
Commercial ( fichier des prix à jour )  de vente
* Facturation
Améliorer le contact client Support administratif de la
Réparation ( Suivi des réparations et de réparation ( Accueil, Suivi
l’activité des ouvriers ) Client, Facturation )
Améliorer :  Connaissance
Magasin  le contrôle des permanente du stock
mouvements de stock  Assistance au cours des
 la sécurité du stock réapprovisionnements
 Suivi trimestriel de la * Production d’états
Comptabilité comptabilité trimestriels
 Accélérer la paie du * Automatiser la paie du
personnel personnel
15
Exemple : Entreprise « Les Grands Garages du Sud » ( Suite )
On identifie dans chaque fonction de gestion , les domaines qui feront l’objet
d’une informatisation .
Gérer les Stocks
• Cas de la Fonction Magasin
Décomposition des Activités
Gérer les Entrées Gérer les Sorties
Commander Réceptionner Délivrer Mettre à jour

les Pièces le stock
On retiendra les domaines suivants : Contrôler Mettre à jour
DOMAINE Informations utilisées Informations créées
Commander les pièces Catalogue fournisseurs Bon de commande

Etat du Stock
Réceptionner Bon de commande Bon de livraison
Fiche de stock
Délivrer les pièces Bon de pièces Demande client
Bon de sortie Facture pièces
Mettre à jour le Stock Fiche de stock Bon de sortie
Bon de livraison
Fiche de stock à jour
16
Etape 2 : Analyse des Projets
Comité d’analyse = Gestionnaires
 Identifier les fonctions et domaines de gestion du S.I

 Développer les processus de traitement dans chaque
processus en tenant compte des objectifs tracés
 Définir les classes de données utilisées ou créées dans chaque
processus
 Identifier les projets comme un ensemble de processus
importants à informatiser et répondant aux objectifs
Portefeuille des projets à réaliser

17
Etape 3 : Evaluation des Projets
Comité d’évaluation = Gestionnaires + Analystes de systèmes
Etude d ’opportunité des projets

 Le projet répond-il aux objectifs du Système de décision
 Impact du projet sur le fonctionnement de l’entreprise
( analyse de la valeur ajoutée )
Rapport
Etude de faisabilité préliminaire
 Ressources humaines et matérielle

 Coût et durée de développement du projet Rapport de
faisabilité
( projets les
Spécification des projets plus adaptés )
 Définition des projets
 Détails de mise en œuvre (ordonnancement, étapes, durée
 documents de spécification
Cahier des charges informatique 18

Etape 4 : Planification des projets : Schéma directeur
Comité d’évaluation = Gestionnaires + Analystes de systèmes
Pla
n  P
orte
feu
illed
epr
oje
tsàr
éaliserc
lassé
spa
rpr
ior
ité
S
tra
tégiq
ue
 D
éterm in
erlesbe soinse
néquipem entsma
tériele
tlo
giciel
Plan  D
ésigneruneé quiped edév
eloppe me
n t(C
h e
fd epro
jet,
T
actiq
ue A
na ly
stesprogr
am m eur
souS SII)
 E
ng agementfin
an c
ierparprojet
 Ob
je ctifs
P
la
nd’action E
tap e
s,p hases
parpr
oje t  C
alend rierd eréa
lisa
tio
n
 C
on tra intes
19
Etape 5 : Conduite de projet = Conception & Réalisation
Equipe technique = ( Chef de projet + Analystes progr.) ou SSII
Le projet entre dans un cycle de vie permanent à son démarrage

Analysede But : Collectedesdocumentsdel’entrepriseenrelationavec
besoins leprojet
Etude But : Produiredesdocum entsdeconception( grapheset

Reengineering ( Rétro-conception )
Conceptuelle diagramm esdem odélisation desdonnéeset traitements)
But : Affiner l’étudeconceptuelleenprécisant :

 l’organisationdesressourcesinform atiques
Etude  lechoixdesoutilsdedéveloppem ent ( SGBD,Environnement
Logique deprogram m ation, etc…)
 A daptationdesm odèlesconceptuelsàcesoutils
But : Traduirelesm odèleslogiquesensolutioninform atique:

Etude  M odèlededonnées=>Basededonnées
Physique  M odèledetraitement => A pplicationinformatique
But : A daptationdumatérielet dulogiciel informatique

Maintenance suiteàuneévolutionduS.I 20
Base de données relationnelle
Système de gestion de base de
données SGBDR
19-09-2013
2séances
Concepts fondamentaux
1- bases de données, banques de données et fichiers de donnees

Base de données (BD):
une base de donnée représente l’ensemble (cohérent, intégré, partagé)
des informations nécessaires au fonctionnement d’une entreprise,
ensemble dont la gestion est assurée par un logiciel appelé système
de gestion de bases de données (SGBD).
Exemple de base de données:
Celle qui permet la gestion des personnels, étudiants, cours,
inscription,… d’une université.
Celle du système de réservation de place d’avion des compagnies
d’aviation.
Celle qui permet la gestion des comptes des clients des sociétés
bancaires.
22
Banque de données:
Une base de données est développée au sein d’une
entreprise, pour son propre fonctionnement. Inversement,
une banque de données est un ensemble de données,
propres à un domaine d’application, que des producteurs
réunissent pour ensuite en commercialiser l’usage vers le
public extérieur.
Exemple d’une banque de données:

Les banques de données juridiques, économiques,
médicales, des brevets, des propriétés des matériaux.
La constitution et l’exploitation des banques de données
font appel à des techniques spécifiques (ex: télématique)
différents des techniques de bases de données.
23
Fichier:
Dans une entreprise, il convient de faire appel à l’approche
base de données lorsque les données à gérer sont de
natures diverses et possèdent de nombreux liens entre
elles. A contrario, il existe des cas où les données à gérer,
bien que importantes en volume, sont homogènes dans
ces cas, on parle de fichier et on l’utilisera un système de
gestion de fichiers (SGF), moins complexe qu’un SGBD.
Tout système d’exploitation d’un ordinateur contient un
SGF spécifique dont l’usage est plus simple et offrant des
fonctionnalité plus élaborées.
Exemple:
Fichier des abonnés d’une revue.
Fichier du personnel d’une entreprise.
Fichier des produits vendus par un magasins.
24
2- Cycle de vie d’une base de données:
On appelle conception d’une bases de données la phase d’analyse

qui aboutit à déterminer le futur contenu de la base.
Lorsque’1 entreprise décide, pour son informatisation d’adopter une
approche BD, le 1 pb à résoudre peut être + difficile: est de déterminer
les informations qu’il conviendra de mettre ds la BD.
Il faut se mettre d’accord sur la nature et les caractéristiques des
informations qu’il faut garder pour assurer la gestion de l’entreprise.
Après il faut transmettre son contenu au logiciel SGBD choisi par
l’entreprise. Ceci sera fait au moye d’1 langage symbolique appelé
langage de description de données (LDD), ainsi viendra la phase
qui consiste à décrire la BD dans le langage du SGBD qu’on appelle
implantation de la base de données.
Une fois l’implantation terminée, peut commencer l’utilisation de la BD
qui se fait par le langage de manipulation de données (LMD), qui
permet d’exprimer aussi bien les requêtes d’interrogation que des
requêtes de mise à jours.
On appelle cycle de vie d’une bases de données la suite des phases
conception implantation et utilisation.
25
Processus de conception d’une base de données
26
3- Modèle de données:
On appelle modèle de données (MD) l’ensemble des
concepts qui permettent la description de données d’une
base et les règles d’utilisation de ces concepts.
On appelle schéma d’une BD l’expression de la
description de la BD d’une entreprise obtenue en
employant un modèle de données.
Les différents schémas établis pour décrire les divers
aspects d’une bases de données sont:
1- Schéma conceptuel des besoins: lors de la phase de
conception il est nécessaire que les utilisateurs puissent
discuter de leurs besoins et exprimer leur vision sous
forme d’une description de la future BD. Pas besoin de
faire appel à des concepts de l’informatique. Ds cette
phase le problème à traiter est de déterminer quelles sont
les informations nécessaire à la vie de l’entreprise
indépendamment de la solution informatique retenue.
Le modèle utilisé est dit conceptuel.
27
Un modèle conceptuel comporte deux parties:
Le modèle statique, concepts permettant de décrire la
structure de données.
Le modèle dynamique, concepts permettant de décrire les
opérations sur les données.
Avec le modèle conceptuel il n’est pas possible de décrire

toute la connaissance que l’on possède sur les données à
décrire et donc sur les règles de gestion de ces données.
Exemple:
l’expression de la règle « il ne doit pas y avoir plus de 20%
d’écart entre les salaires des employés d’un même
service et d’une même catégorie » il faut introduire une
description explicite des contraintes supplémentaires dites
contraintes d’intégrité.
28
2- Schéma logique:
Si le schéma conceptuel des besoins décrit la future base,
indépendamment des choix techniques d’implantation, la
phases d’implantation demande que la partie décrivant les
données de ce schéma soit traduite ds les concepts du
modèle utilisé par le SGBD choisi.
On appelle modèle logique (MLD) ou modèle machinale

le modèle sur lequel est construit un SGBD actuel. Il
existe plusieurs modèles logiques (relationnel,
hiérarchique, réseau,..).
Le schéma obtenu en traduisant dans un modèle logique,
le schéma conceptuel (MCD) des besoins est appelé aussi
schéma conceptuel d’une base de données.
29
3- schéma interne:
C’est la fonction des administrateurs système qui suivant leur analyse
des traitements qui vont être effectués sur la future BD, détermineront
les paramètres effectifs pour le chargement de la base de données
sous forme d’un ensemble de fichiers. Ces choix seront consignés
dans ce qu’on appelle le schéma interne (SI) de la base de données.
Où les concepts seront ceux de fichier, organisation, chemin d’accès,
clé,…
4- schéma externe:
À chaque utilisateur est associé un schéma dit son schéma externe qui
définit le sous ensemble de la BD auquel il a accès, structuré de façon
à répondre à ses besoins spécifiques.
Les avantages de cette approche:
simplicité: chaque utilisateur n’a dans son schéma externe que ce qui
l’intéresse.
Protection: il n’est pas possible que par une erreur un utilisateur
accède aux données d’autres utilisateurs non décrits dans son schéma
externe.
30
Un SGBD gère donc trois types de schémas pour une base de
données, qui sont organisés en cascade de la façon suivante:
31
Exemple:
Un exemple illustrant ces trois niveaux de schémas pour un SGBD relationnel
est le suivant: Entreprise: un institut de formation permanente.
1- Schéma logique ( SL)

Étudiant: nom, prénom, date de naissance N°étudiant.
Enseignant: nom, prénom, statut, N°compte_bancaire
Cours: nomC, Cycle, nom_enseignant
Inscription: n°étudiant, nom_cours, note1, note2
2-schéma externe (SE)

Schéma externe du professeur de la BD:
Étudiant_BD: nom, prénom, note1, note2, note_finale
Tel que étudiant_BD résulte de la combinaison de Étudiant et Inscription di SL,
tels qu’il existe une Inscription de cet étudiant pour le cours BD ( n°étudiant
dans Étudiant = n°étudiant dans Inscription et nom_cours dans Inscription )
BD) et tel que note_finale = (noe1+note2) 2.
32
schéma externe du service de gestion:
Professeur : nom, prénom, n°compte_bancaire, nombre _de_cours, liste
(nom_cours)
Tel que Professeur résulte de la combinaison de Enseignant et de cours du
SI, tels que liste (nom_cours) est la liste de nomC se trouvant dans Cours
tel que nom_enseignant dans Cours = nom dans Enseignant et tel que
nombre_cours = cardinalité liste (nom_cours)) .
3- schéma interne (SI)
Étudiant : fichier Fetud,
 contenu : nom, prénom, date de naissance, n°étudiant, indexé sur n°étudiant, index
secondaire sur nom+prénom.
Enseignant + cours: fichier FEnsCours,
 contenu: nom, prénom, statut, n°compte_bancaire, liste (nomC, cycle) tel que
nom_enseignant dans cours = nom dans enseignant, indexé sur nom.deux index
secondaire, l’1 sur le nomc et l’autre sur cycle
Inscription: fichier Finscrits,

Contenu : n°étudiant, indexé sur n°étudiant, index secondaire sur nom_cours.
33
Historique des SGBD
Approche classique (gestion de fichiers) et approche base

de données:
Un système d’information organisé autour d’une base de

données est centré sur les données alors qu’un système
d’information classique est conçu autour de fonctions de
traitements
Exemple: chaîne de traitements: commande, facturation,

comptabilité, paye, ect…
34
Approche gestion de fichiers:
Jusqu’aux années 60: organisation classique en fichiers:
Les structures de données sont décrites dans chaque
programme d’application afin d’accéder aux fichiers de
données
35
Caractéristiques:
Particularisation de la saisie en fonction des fichiers ( un

programme de mise à jour pour chaque fichier)
Contrôle en différé des données ce qui implique recyclages
pour les erreurs plus augmentation des délais et du risque
d’erreurs
Particularisation des fichiers en fonctions des traitements
Grande redondance des données
Peu de standardisation dans les traitements
Utilisation de nombreux supports intermédiaires
36
Approche base de données:
Fin des année 60: apparition des premiers SGBD. Séparation
de la description des données de leur manipulation par les
programmes d’application: Modèles réseau et hiérarchique.
Les structures de données sont décrites de façon unique à
l’aide du SGBD qui résout les requêtes des différents
programmes:
37
Caractéristiques:
Uniformisation de la saisie
Contrôle immédiat de la validité des données entre plusieurs
traitements
Limitation de la redondance des données
Standardisation des traitements généraux ( consultation,
restitution sous forme de listes ou tableaux)
Gestion rationnelle de supports
38
A partir de 1970: deuxième génération de SGBD à partir du modèle
relationnel. Enrichissement et simplification des SGBD afin de faciliter
l’accès aux données pour les utilisateurs. Commercialisation depuis
1982. Oracle, Ingres, Sybase,.
Début des années 80: troisième génération de SGBD basées sur le
modèle objet. ONTOS, ObjectStore, Versant, Orion, O2,..
Propriétés d’un SGBD:

 Usage multiple des données
 Accès facile, rapide, protégé, souple, puissant
 Coût réduit de stockage, de mise à jour et de saisie
 Disponibilité, exactitude, cohérence et protection des données, non
redondance
 Évolution aisée et protection de l’investissement de programmation
 Indépendance des données et des programmes
 Conception a priori.
39
Objectifs des SGBD:
 A) Indépendance physique
Une modification de l’organisation physique des données n’entraîne pas de
modification dans les programmes d’application
 B) Indépendance logique
Un remaniement de l’organisation logique des données (ajout d’une nouvelle
rubrique, ajout d’une nouvelle liaison…) n’entraîne pas de modifications
dans les programmes d’application dont la vision logique n’a pas évolué.
 C) Manipulation des données par des langages non procéduraux
Des utilisateurs non informaticiens doivent manipuler simplement les
données càd les interroger et les mettre à jour sans préciser d’algorithme
d’accès.
 D) Administration facilitée des données
Un SGBD doit fournir des outils pour décrire les données, permettre leur suivi
de ces structures et autoriser leur évolution. C’est la tâche des
administrateurs de données: conception, création, maintenance, arbitrage.
 E) Efficacité des accès aux données
Optimisation de l’utilisation globale de la base de données afin d’éviter
qu’une requête coutre d’un utilisateur attende la fin d’une requête longue
d’un autre utilisateur par exemple.
40
 F) Redondance contrôlée des données
Si redondance, volume de stockage plus important,
opérations de mise à jours multiples, incohérences
momentanées ou permanents.
 G) Cohérence des données
Un SGBD doit veiller à ce que les applications respectent
cette règle lors des modifications de données. Une telle
règle est appelée contrainte d’intégrité. Ex: l’age d’une
personne doit être un entier positif.
 H) Partage des données
Diverses applications doivent pouvoir partager les données
de la base dans le temps et simultanément.
 I) Sécurité des données
Les données doivent être protégées contre les accès non
autorisés ou mal intentionnés. La sécurité des données doit
aussi être assurée en cas de panne d’u programme ou du
système, voire de la machine.
41
Architecture d’un SGBD
Au niveau d’abstraction le plus élevé, un SGBD peut être
vu comme une boite noire, assurant la gestion de la BD
conformément aux requêtes de ses utilisateurs:
42
L’interface utilisateur permet aux utilisateurs d’exprimer des requêtes:
soit pour définir le contenu de la BD avec le (LDD), soit pour interroger
la BD (en extraire des informations), soit, enfin pour apporter des
modifications à ce qui a été enregistré avec (langage de manipulation de
données LMD).
L’interface d’accès physique permet au SGBD d’accéder aux données

sur les supports (disque,..)
Le lien entre ces deux interfaces doit répondre à un objectif

fondamental: assurer l’indépendance programme – données. A savoir:
 la possibilité pour un utilisateur de modifier sa vue de la base et ses
traitements sans avoir à se soucier des choix qui ont été opérés au niveau
interne des fichiers.
 La possibilité pour un administrateur système de modifier ces choix, pour
améliorer les performances, sans que cela ait un impact sur les utilisateurs.
43
Il convient donc d’avoir une vision plus fine de l’architecture
d’un SGBD. Celle ci conduit à distinguer trois couches:
 Couche externe appelée Niveau externe : prend en charge le

problème du dialogue avec les utilisateurs, càd, analyse des
demandes de l’utilisateur, le contrôle des doits d’accès de
l’utilisateurs, la présentation des résultas
 Couche interne appelée Niveau interne: s’occupe du stockage des
données dans les supports physiques et la gestion des structures de
mémorisation (fichier) et d’accès (gestion des index, des clés,.).
 Couche intermédiaire appelée Niveau logique: assure les fonctions de
contrôle global:
 Optimisation globale des requêtes
 Gestion des conflits d’accès simultanés de la part de plusieurs utilisateurs
 Contrôle général de la cohérence de l’ensemble ….
44
45
Architecture ANSI – SPARC à trois niveaux d’une base de
données:
46
Fonctionnement d’un SGBD:
 1- Le programme d’application A émet une demande de lecture à
l’intention du SGDB.
 2- Le SGBD consulte le sous-schéma relatif à A pour obtenir la
description logique de ses données.
 3- Consulte le schéma et détermine la structure à extraire.
 4- Examine la description physique de la base et détermine les
enregistrements physiques à lire.
 5- Lance une commande au système d’exploitation pour
provoquer la lecture de l’enregistrement physique.
 6- Le système d’exploitation provoque le transfert de
l’enregistrement entre la base physique et les buffers du SGBD.
 7- Le SGBD, à partir du sous-schéma A, extrait les données à
communiquer au programme d’application A.
 8- Le SGBD provoque le transfert des données dans la zone de
liaison de A.
 9- Le SGBD retourne au programme d’application les informations
d’état relatives à l’échange ( en particulier les codes des erreurs
éventuelles).
47
Modèles logiques de
données
48
Rappel
La conception d’une base de données commence après l’analyse du
monde réel.
 A) Analyse:
le monde réel est perçu comme un système abstrait. Ce système
abstrait se traduit par: des classes d’entités, des propriétés sur ces
classes, des liaisons entre ces classes. Le système abstrait est décrit
par un schéma conceptuel.
Modélisation conceptuelle:
Principes à respecter:
 Le schéma conceptuel doit être libre de toute considération non
significative du système abstrait ( organisation physique des données,..)
 Tout les aspects du système abstrait doivent être décrits dans le schéma
conceptuel, aucun d’eux ne doit intervenir ailleurs en particulier dans les
programmes d’application indépendants du schéma conceptuel.
49
Modélisation logique:
Traduit le modèle conceptuel dans le modèle du SGBD. Il existe
différents types de modèles logiques de SGBD:
hiérarchiques, réseau, relationnel, orientés objets. Certains
modèles peuvent être spécifiques à un SGBD.
Modélisation physique:
Structures de stockage internes.
50
Modèles conceptuels de données
Concepts de base
 Entité ( ex: voiture)
 Attribut: propriété de l’entité (ex: Numéro d’immatriculation, couleur)
 Valeur de l’attribut ( ex: 232 16 3, blanche).
 Association: liaison perçue entre entités
 Type ( ex: couleur = chaîne de caractères)
 Occurrence (deux voitures différentes sont deux occurrences de
l’entité voiture)
Caractéristiques des associations:
Association un à plusieurs ( en abrégé 1-N) entre deux types
d’entités A et B:
 Chaque occurrence du type A est associée à zéro, une ou plusieurs
occurrences du type B.
 Chaque occurrence du type B est associée à une occurrence du type
A.
51
Exemple: association 1-N entre le type Fournisseur et le
type d’entités Bon de commande.
Association 1-1: cas particulier de l’association 1-N.
Association plusieurs à plusieurs ( N-M) entre deux types

d’entités A et B:
 Chaque occurrence du type A est associée à zéro, une ou
plusieurs occurrences du type B.
 Chaque occurrence du type B est associée à zéro, une ou
plusieurs occurrences du type A
Exemple: association N-M entre le type d’entités Fournisseur

et le type d’entités Pièce.
52
Représentation graphique des associations 1-N et M-N
(formalisme E-A)
53
Représentation graphique des associations 1-N et N-M
(formalisme OMT)
54
Le Modèle Logique des Données ( MLD )
But : Représentation de la structure logique des données du S.I sous une forme
adaptée à l’utilisation d’un Système de Gestion de Base de Données
( SGBD ) ou d’un Système de Gestion de Fichiers ( SGF ) .
Différents types de modèles logiques ( machinables ) sont exploités dans le marché des SGF et SGBD :
* Le Modèle Hiérarchique ( années 60 )
Il permet de gérer des données dans un ensemble de fichiers sous forme d’un ensemble d’arbres ou de
hiérarchies . Seuls les liens 1 à N entre enregistrements sont permis ( liens père-fils ) .
Les liens multivaluées ( N à N ) doivent être transformés sous forme de liens 1 à N .
La recherche d’enregistrements se fait en parcourant l’arbre général par une gestion de pointeurs :
du père vers le 1er fils , puis de celui-ci vers le 2ème ou du père vers le grand-père , etc…
Les utilisateurs ne peuvent accéder aux données que par l’intermédiaire de programmes de gestion
de fichiers ( SGF ) écrits spécifiquement pour eux ( Niveau de réutilisation faible ) .
Exemples de SGF : IMS ( IBM )
55
* Le Modèle Réseau ou CODASYL ( 1971 )
Son but est de lever certaines des contraintes du modèle hiérarchique . Il fonctionne selon le même
principe navigationnel , c’est à dire par pointeurs . Il permet de représenter les liens N à N entre
enregistrements par liaison d’un enregistrement à un ou plusieurs pères et / ou à un ou plusieurs fils.
Il est basé sur les notions de RECORD ( enregistrement ) et de SET ( lien entre 2 enregistrements ) .
Les premiers SGF et SGBD supportant ce modèle sont apparus en 1978 :
Exemples : IDS2 ( Bull ), DBMS ( DEC ), IDMS (Culliname ), ADABAS ( Software AG ), etc...
56
* Le Modèle Relationnel ( Codd - 1970 )
C’est le modèle de plus répandu actuellement sur le marché des SGBD ( 85 % en 1995 ).
Il lève toutes les contraintes des modèles précédents ( hiérarchiques et réseau ).
Il a été crée par des mathématiciens . Il permet de gérer les données sous forme de tables
d’enregistrements . En reliant ces tables à l’aide d ’un système de clés , il est possible de
rechercher des données dans une table ou de collectionner des données à partir de plusieurs tables
( requêtes ) satisfaisant un critère fixé .
Exemples de SGBDR ( SGBD Relationnels ) :
INGRES et INFORMIX ( sur UNIX et DEC/VMS )
ORACLE ( sur tous les systèmes )
DB400 ( sur IBM/AS400 )
DB2 et SQL/DS ( sur gros systèmes IBM )
MS-SQL Server ( sur Windows NT/Server )
MS-ACCESS et Borland PARADOX ( sur MS-DOS et Windows )
57
* Le Modèle Objet ( Années 1990 )
C’est le successeur potentiel du modèle relationnel . Il repose sur la théorie des objets .
Dans cette théorie , le système d’informations peut être représenté comme un ensemble d’objets
possédant des propriétés et des méthodes et communiquant entre eux par échange de messages .
Il s’appuie en amont sur des méthodes de conception de S.I orientées objet comme O.M.T
( Object Modeling Technique ) ou U.M.L ( Unified Modeling Language ) ou O.O.M ( Orientations
objet dans Merise ) , etc…Ce modèle est encore peu utilisé dans le marché commercial mais est appelé
à remplacer le modèle relationnel dans quelques années pour sa puissance et sa sémantique intuitive .
Exemples de S.G.B.D.O ( SGBD Objets ) : O2 ( IBM )
58
Chapitre II:
Le modèle entité-association
E-A, abréviation du terme entité-Assoiciation (terminologie

anglo-saxonne: E-R: Entity-Relationship).
Résulte des travaux de Bachman, CHEN aux U.S.A ( 1976),
puis Tardieu en France ( 1979 ).
La méthode MERISE fait appel aux principes de base de
ce modèle.
Essentiellement utilisé pour la phase de conception
initiale. Mise en œuvre de la BD transformation du
schéma E-A en un schéma logique de SGBD.
59
Le Modèle Conceptuel de données ( MCD )
Formalisme = Modèle Entité-Association
Exemple :
1,N
COMMANDE
Commander
Qté commandée N° Commande
0,N Date Commande
1,1
PRODUIT Passer
Ref-Produit commande
Désignation
Prix-unitaire CLIENT
1,N
Code-Client
Nom-Client
60
Notion d’ENTITE
Entité = Représentation d’un objet concret ou abstrait

du S.I caractérisé par :
Nom Entité
* des propriétés ( attributs ) : P1, P2, P3, …..Pn P1
* un identifiant = Propriété ( P1 ) dont les valeurs P2
sont discriminantes Pn
* des occurrences ( instances ) multiples
( au moins 2 )
Etudiant
Exemple Etudiant
Etudiant 125
235
Etudiant 918 ALAMI
SEBASTIEN
N° Inscription DAOUDI ALBERT

DRISS
Nom MOUNIR FRANCAISE
MAROCAINE
Prénom MAROCAINE
Nationalité Une occurrence d ’entité = 1 jeu de valeurs prises par les
propriétés de l’entité
61
Notion d’ASSOCIATION
Une Association traduit les liens sémantiques existant entre 2 ou
plusieurs entités du S.I et de son environnement
Elle est caractérisée par : * Absence d ’existence intrinsèque
* des occurrences ( au moins une )
* des propriétés portées ( nombre M ) M = 0, 1, 2, 3, …
* une dimension N ( N = nombre d ’entités rattachées )
* un identifiant obtenu par concaténation des identifiants
des entités rattachées
Exemple Véhicule Client

Loué par N° Client
N° Immatr.
Date mise en service Nom
Association binaire non Adresse
Kilométrage
porteuse d’identifiant
(N°Immatr.+N° Client )
Service
Salarié N° Service
Matricule Affecté à
Désignation
Date affect.
Nom
Association binaire porteuse d ’1 propriété ( Date Affect ) et d’identifiant ( Matricule.+ N° Service )

62
Occurrences d’association
SALARIE
SERVICE
A01
IDRISSI 125
18/05/92 Comptabilité
SALARIE
SERVICE
A12 11/10/91
ALAMI 124
Commercial
SALARIE 04/03/93
SERVICE
A05
RAMI 106
Magasin
SALARIE
A09 * A01-125 , A12-125 et A05-106 sont des instances
DAOUDI de l ’association « Affecté à »
* Les instances A09 ( entité Salarié ) et 124 ( entité Service )

ne participent pas à l’association « Affecté à »
63
Cardinalités d ’une Association ( Interprétations )
E1 E2 E1 E1 E2
Assoc. E2 Assoc.
Assoc.
0,1 1,1 1,1 1,1 1,1

E1 E2 0,N
Assoc.
Cardinalités mini :
0 : Certaines occurrences de l’entité peuvent ne pas participer à l’assoc.
1 : Toute occurrence de l’entité participe obligatoirement à l’association
Cardinalités maxi :
1 : Toute occurrence de l’entité participe au plus une fois à l’association
N : Toute occurrence de l’entité peut participer plusieurs fois à l’assoc.
0,N 1,N
Conclusion
* La cardinalité mini traduit la capacité d ’une occurrence à exister
indépendamment ou non des occurrences de l’association .
* La cardinalité maxi traduit la capacité associative de l’association pour
l’entité considérée
64
Cardinalités d ’une ASSOCIATION
Cardinalités = Couple de valeurs représentant la fréquence
(mini et maxi ) de participation d’une occurrence d ’entité à une
association )
Entité 1 i1 , j1
Entité 2
Association
i2 , j2
i1 , i2 = cardinalités mini
j1 , j2 = cardinalités maxi
Exemple
Service
Salarié 1,N 1,8 N° Service
Matricule Affecté à
Date affect. Désignation
Nom
Règles de gestion : RG1 - Un salarié est affecté à un et ou pls services le long de sa carrière
RG2 - A un service , on peut affecter un à plusieurs salariés (maximum 8)
65
Identifiant d’une Association
Il est obtenu par concaténation des identifiants des entités reliées par l’association
Exemple : Employé Médecin

N° Employé 0,N 0,N N° Médecin
Visiter
Nom Employé Nom Médecin
Nom Employé Date Visite Spécialité
Adresse Client Téléphone
Identifiant = ( N° Employé , N° Médecin )

Occurrences de « Visiter »
N° Employé N° Médecin Date Visite
La dernière occurrence de l’association « Visiter » n’est
23 1 26/06/01 pas permise en raison de la discrimination de l’identifiant .
12 3 05/07/01
39 2 10/08/01
La duplication de l’occurrence ( 42 , 4 ) n’est pas possible !
42 1 15/08/01
42 4 22/08/01
42 4 05/09/01 !!
Question : Un employé peut-il effectuer plusieurs visites chez le même médecin à des dates différentes ?
Réponse : Ce modèle ne le permet pas même si la propriété « Date Visite » est portée par l’association « Visiter »
66
Identifiant d’une Association ( Suite )
Solution du Problème : Association ternaire

Employé Médecin
N° Employé 0,N 0,N N° Médecin
Visiter
Identifiant de l’association Nom Employé Nom Médecin
Nom Employé Spécialité
« Visiter » : Adresse Client 0,N Téléphone
Calendrier
( N° Employé , N° Médecin , Date )
Date
Les triplets ( 42 , 4 , 22/08/01 ) et ( 42 , 4 , 05/09/01 ) sont maintenant des occurrences possibles de

l’association « Visiter » car elles représentent des valeurs distinctes de son identifiant .
Ce modèle permet , à l’inverse du précédent , de représenter le fait qu’un employé peut visiter le même
médecin plusieurs fois à des dates différentes .
Généralisation : Une association N-aire ( de dimension N ) possède un identifiant sous forme de

N-uplet dont les valeurs sont distinctes .
67
Comment doit-on interpréter les cardinalités d’une association ternaire ?
Exemple : Association ternaire ( i2 , j2 )
Médecin
( i1 , j1 )
Employé Visiter
( i3 , j3 ) Calendrier
• Identification de ( i1 , j1 )
Pour un employé fixé ( occurrence E ) , le couple de N° Employé ( N° Médecin , Date Visite )
cardinalités ( i1 , j1 ) traduit le nombre minimal 1 ( 12 , 08/05/01 )
et maximal d’occurrences du couple d’entités 1 ( 10 , 15/06/01 ) Occurrences
( Médecin , Calendrier ) qui sont associées à 1 ( 6 , 09/06/01 ) de « Visiter »
l’occurrence E . 3 ( 10 , 02/06/01 )
Ici : ( i1 , j1 ) = ( 0 , 3 ) 4 ( 12 , 14/06/01 )
4 ( 10 , 14/06/01 )
5 ( 10 , 02/06/01 )
N° Médecin ( N° Employé , Date Visite )
Pour un médecin fixé ( occurrence M ) , le couple de
cardinalités ( i2 , j2 ) traduit le nombre minimal 12 ( 1 , 08/05/01 )
et maximal d’occurrences du couple d’entités 10 ( 1 , 15/06/01 )
6 ( 1 , 09/06/01 )
( Employé , Calendrier ) qui sont associées à
10 ( 3 , 02/06/01 )
l’occurrence M . 12 ( 4 , 14/06/01 )
Ici : ( i2 , j2 ) = ( 0 , 4 ) 10 ( 4 , 14/06/01 )
10 ( 5 , 02/06/01 )
En raisonnant de même pour ( i3 , j3 ) on trouve : ( i3 , j3 ) = ( 0 , 2 )
68
Rôles dans une Association
Rôle = Notion précisant le rôle particulier joué par un ensemble
d’occurrences relatives à une entité dans une association .
Les rôles sont portés sur le schéma Entité-Association .
Exemple 1 Livrer Dépôt expéditeur
Nbre colis livrés DEPOT
0,N 0,N
Code dépôt
CLIENT Recevoir Dépôt destinataire
Adresse dépôt
Code Client Nbre colis reçus 0,N
Nom client
0,N
Adresse client
Dépôt Client Nbre colis livrés Nbre colis reçus

D1 C6 1 - Occurrences de l’association
Dépôt
« Livrer »
expéditeur D3 C2 2 -
D1 C9 - 2
Occurrences de l’association
Dépôt D2 C2 - 5 « Recevoir »
destinataire D4 C6 - 4
69
Rôles dans une Association ( suite )
Exemple 2 : Cas d ’une entité réflexive
A pour chef
0,1
SALARIE Encadrer
N° Salarié
Nom Est chef de
Prénom 0,N
Fonction
Salarié
N° Subalterne N° Chef
1 2 Occurrences de
1
5 2 l’association
2 2 4
6 1
3
* Les salariés N° 1 et 2 participent aux 2 rôles de l’association .
4
* Le salarié N° 3 ne participe à aucun des rôles de l ’association .
5
6 * Les salariés N° 4 et 5 participent à un seul des rôles de l ’association.
70
Notion d’entité faible et d’identification relative
Une entité faible possède un identifiant relatif qui se rapporte toujours à
celui d’une entité classique . L’identifiant absolu de l’entité faible est
obtenu en concaténant les identifiants des 2 entités.
Formalisme MERISE 2: E1 (1,1)

 -,N E2
Exemple :
ETAGE
1,N

CHAMBRE  N° Etage HOTEL
( 1,1 )
N° Chambre Nbre de toilettes 1,N Code Hotel
( 1,1 )
Surface Adresse Hotel
Nom Hotel
Entité Identifiant relatif Identifiant absolu

HOTEL - Code Hotel -
ETAGE N° Etage Code Hotel + N° Etage
CHAMBRE N° Chambre Code Hotel + N° Etage + N° Chambre
71
Notion de Dépendance Fonctionnelle
Définition : 2 propriétés A et B sont en DF si la connaissance d’une
valeur de A détermine une et une seule valeur de B . On dit que A
détermine fonctionnellement B .
Formalisme : A B : 1 source , 1 but

( A, B, …) X : plusieurs sources , 1 but
A ( X, Y, …) : 1 source , plusieurs buts
Exemples : N° Client Nom Client
Nom Client N° Client ( pas de DF )
Prénom Client N° Client ( pas de DF )

( Réf-prod , N° Commande ) Qté prod. commandée
Réf-prod ( Libellé prod. , Prix unit. Prod. )

72
AXIOMES ET PROPRIETES DES
DEPENDANCES FONCTIONNELLES
AXIOMES
1 - Réflexivité : X X
2 - Augmentation : X Y => X , Z Y
3 - Additivité : {X Y et X Z } => X Y,Z
4 - Projectivité : X Y,Z => { X Y et X Z }
5 - Transitivité : {X Y et Y Z } => X Z
6 - Pseudo-transitivité : {X Y et Y, Z W } => X, Z W
PROPRIETES
* DF élémentaire : X Y élémentaire si il  Z  X tel que Z Y
* DF directe : X Y directe si il  Z tel que X Z et Z Y
73
1 - Cas d’une Entité
Code Client Nom

CLIENT
Prénom
Code Client Adresse
Nom
Téléphone
Prénom
Adresse Code Client ( Nom , Prénom , Adresse , Téléphone )
Téléphone
Toutes les Propriétés d’une Entité sont en dépendance fonctionnelle directe

avec la propriété identifiante de cette Entité
74
2 - Cas d’une Association hiérarchique ( monovaluée )
COMMANDE CLIENT
1,1 PASSER 0,N Code Client
N° Commande
Nom
Date Commande
Adresse
Montant
DF représentant l’assoc.
N° Commande Code Client Nom
Adresse
Date Commande Montant Téléphone
Occurrences de « PASSER » Une Association Hiérarchique est une association binaire (dimension = 2)
N° Commande Code Client dont l’une des pattes possède une Cardinalité Maxi égale à 1 .
1 4 Ce type d’association est toujours orienté suivant le sens de la
2 9 dépendance fonctionnelle qui relie les identifiants de ses Entités .
3 4
4 6 Remarque : La dépendance fonctionnelle Code Client ---> N°Commande
5 2 n’existe pas car un Client peut passer plusieurs commandes
( exemple du Client N° 4 )
6 4 75
3 - Cas d’une Association N-aire multivaluée non porteuse de propriétés
* Exemple 1 : Association binaire non porteuse
Une Association multivaluée
ACTEUR FILM est une association dont toutes les
0,N JOUER
1,N pattes possèdent une Cardinalité
N° Acteur N° Film
Maxi égale à N ( N >= 2 ) .
Nom Titre
Prénom Date N° Auteur ( Nom , Prénom )
Production
N° Film (Titre , Date Product. )
DF représentant l’assoc. ( sans but )
( N°Acteur , N° Film ) -
Calendrier
* Exemple 2 : Association ternaire non porteuse
0,N Date
Employé 0,N VISITER

N°Employé ( Nom , Prénom ) N° Employé Médecin
N°Médecin ( Nom Médecin , Spéc. ) Nom
N° Médecin
Prénom 0,N Nom Médecin
DF représentant l’assoc. (sans but) Spécialité
( N° Employé , N° Médecin , Date ) -
76
4 - Cas d’une Association N-aire multivaluée porteuse de propriétés
* Exemple 1 : Association binaire porteuse
PRODUIT
FACTURE 0,N COMPORTER 1,N
N° Facture Réf. Produit
Quantité Produit Désignation
Date Facture
Montant Prix Unitaire
( N° Facture , Réf. Produit ) Quantité Produitc
* Exemple 2 : Association ternaire porteuse
VILLE 0,N Route

TRAJET 1,N
N° Ville
Ville départ N° Route
Nom Ville 0,N Distance Type Route
Nbre Habitants Ville arrivée Etat route
( N° Ville Départ , N° Ville Arrivée , N° Route ) Distance
77
5 - Cas d’une Association Hiérarchique Réflexive

1,1
EMPLOYE N° Employé ( Nom , Prénom , Date Emb. )
Subalterne
N° Employé A pour Chef
Nom
1,N DF représentant l’association
Prénom
Date Embauche Chef
6 - Cas d’une Association Multivaluée Réflexive
PERSONNE 0,N
Parent PARENTE
N° CIN ( Nom , Prénom )
N° CIN
Enfant
Nom
Prénom 0,2
( N° CIN Parent , N° CIN Enfant ) -
78
7 - Cas d’une Association de Cardinalités Maxi égales à 1
Exemple :
FACTURE REGLEMENT
0,1 PAYER 1,1
N° Règlement
N° Facture
Date Règlement
Date Facture
Montant Règlement
Montant Facture
Règles de gestion:
Ce type d’association est orienté
RG1 - Une facture fait l’objet d ’un seul règlement dans les 2 sens pour indiquer
l’existence de 2 dépendances
RG2 - Un règlement compense toujours une seule facture
fonctionnelles entre les identifiants
RG3 - A un instant donné , certaines factures peuvent être impayées . des entités de l’association .
N° Facture N° Règlement
Date Montant
Date Montant Règlement Règlement
Facture Facture 79
8 - Cas des entités faibles
Exemple :
ETAGE
1,N

CHAMBRE  N° Etage HOTEL
( 1,1 )
N° Chambre Nbre de toilettes 1,N N° Hotel
( 1,1 )
Surface Adresse Hotel
 1,N
1,1
0,N RESERVATION Code Hotel + N° Etage + N° Chambre

Réserver 1,N N° Réservation
Durée Date Réservation Durée

N° Réservation
Avance en DH + Code Hotel
Règles de gestion:
RG1 - Une réservation est effectuée sur une ou plusieurs chambres
RG2 - Une réservation de client à l’hôtel précise le nombre de nuits relatif à chaque chambre ( durée )
RG3 - Une chambre est identifiée relativement à un étage et à un hôtel particuliers
80
Graphe de Dépendances Fonctionnelles
GDF = Représentation graphique de l’ensemble des DF unissant les

propriétés dans un domaine d’activité du système d’information . Ces
propriétés sont obtenues à partir du dictionnaire de données du domaine .
Exemple : GDF du domaine « Gestion commerciale » dans une entreprise

Date
N° Produit Libellé
N° Client
produit
N° Catégorie
Nom Adresse Tél.
Libellé
Client Client Client Qté prod.commandée, catégorie
Mont. ligne commande
N° fournisseur
Nom Adresse Prix achat

fournisseur fournisseur produit
81
Le modèle relationnel
le modèle relationnel a été inventé en 1960 et a fait l’objet

de très nombreuses recherches qui ont débouché sur la
réalisation et commercialisation de SGBDs relationnels.
C’est le modèle le plus utilisé par les SGBDs actuellement
disponible sur le marché.
Un modèle de données plus simple que celui de l’entité
association tant sur le plan théorique (normalisation
définition de langages de manipulation de données) que
sur celui des réalisations.
les objets et associations du monde réel sont présentés
unique
82
Le Modèle Logique de Données Relationnel ( MLDR )
Ce modèle permet de constituer une base de données au sens logique au moyen de
tables désignées aussi sous le terme de relations .
Les Concepts du MLDR

1 ) L’attribut : C’est le plus petit élément d’information enregistré dans une base de données .
Il possède un nom et prend des valeurs dans un domaine de valeurs bien déterminé .
Exemples :
Attribut Domaine de valeurs
N° Client Entier naturel
Adresse Client Alphanumérique
Mode de paiement Liste alphabétique (Espèces,Chèque ,Traite)
2 ) La Relation : Une relation ( appelée aussi table ) est un ensemble d’attributs significativement
associés ( dont l’association a un sens au niveau du S.I ) .
Représentation d’une relation : R ( A1, A2 , A3, …….., An ) Représentation en intention

ou Schéma de la relation
R A1 A2 A3 ….. An Représentation en extension
tuple 1 ……… …….. …….. ….. ……… ( montrant les tuples de la relation )
tuple 2 valeur valeur valeur ….. Valeur
……. …….. …….. …….. ….. …….. R : Nom de la relation
tuple n …….. ……… …….. ….. …….. A1, A2 , …., An : Attributs de la relation
83
Le Modèle Logique de Données Relationnel ( suite 1 )
Une relation est un sous-ensemble du produit cartésien des domaines de valeurs associés à ses
attributs.
Exemple : Soient 2 attributs dont les domaines de valeurs sont :

D1 = ( Ahmed , Brahim , Ali ) et D2 = ( Mineur , Majeur )
D1 x D2 Nom Statut R Nom Statut

Ahmed Mineur Ahmed Mineur
Brahim Mineur Brahim Majeur
Ali Mineur Ali Mineur
Ahmed Majeur Ahmed Majeur
Brahim Majeur
Ali Majeur R est un exemple de relation incluse dans D1 x D2 .
( Toutes les relations qu’il est possible de créer à partir
Le produit cartésien D1 x D2 représente la des attributs ‘Nom’ et ‘Statut‘ sont incluses dans D1 x D2 )
relation dont le nombre de tuples est le plus grand
3 ) Les clés d’une relation : soient 3 relations comportant certains attributs communs :
R1 ( A1# , A2 , A3, …….., An )
R2 ( B1# , B2 , B3 , …….., Bn , A1# )
R3 ( A1# , B1# , C1, C2 , C3 , ….., Cn )
Les attributs suivants jouent un rôle particulier :
- A1# dans R1 et B1# dans R2 sont appelés clés primaires : Chacun de ces attributs a été choisi pour
identifier de manière discriminante 84
- A2 est une clé candidate pour R1 à condition que A2 soit un attribut discriminant pour les tuples
de R1 comme c’est le cas de A1#. Une clé candidate est un
attribut ou un groupe d’attributs qui aurait pu servir de clé
primaire mais qui n’a pas été retenu .
- A1# dans R2 est une clé étrangère : c’est un attribut défini sur un domaine primaire ( celui de R1 )
mais qui est présent dans une autre relation ( R2 ) dans le but
de créer un lien entre les relations R1 et R2 .
- A1# et B1# dans R3 représentent une clé primaire composée :

C’est un groupe d’attributs définis chacun sur un domaine
primaire . Les occurrences de ce groupe ( couples de valeurs
de A1# et B1# ) sont utilisées pour identifier de manière
discriminante les tuples de la relation R3 .
- Remarques: * une clé primaire ( simple ou composée ) est toujours soulignée dans une relation .
* une clé étrangère ( ou externe ) peut être composée comme dans le cas d’une clé primaire
* l’attribut ou les attributs constituant une clé primaire ou étrangère possèdent un nom
qui se termine par le symbole #
* une relation est toujours identifiée par une clé primaire
* une relation peut présenter une ou plusieurs clés candidates (clés primaires de substitution)
4 ) Schéma relationnel : C’est un ensemble de relations logiques présentant des liens sémantiques .
Cet ensemble est destiné à la création d’une base de données physique .
85
5 ) Les Contraintes d’Intégrité :
Elles représentent un ensemble de règles fondamentales dont l’application permet de garantir

la cohérence du schéma relationnel d’une base de données .
Ces règles contrôlent la cohérence des valeurs prises par :
* les attributs par rapport à leur domaine de valeurs (contrainte d’intégrité de domaine)
Exemple : Si l’attribut ‘ N° Client ’ est défini sur un domaine de valeurs numériques , il ne
peut pas contenir de lettres .
* les clés primaires des relations ( contraintes d’intégrité de relations )

L’intégrité de relation concerne les valeurs d ’une clé primaire qui doivent être uniques
( pas de doublons ) et non nulles ( toujours spécifiées ) .
* les clés étrangères des relations ( contraintes d’intégrité référentielles )

L’intégrité référentielle stipule qu’une clé étrangère ne peut prendre que les valeurs définies dans
le domaine primaire de la clé primaire à laquelle elle est associée .
86
Construction du Modèle Logique de Données Relationnel
Le MLDR est construit à partir du MCD en appliquant des règles de transformation simples
aux entités et aux associations .
Les entités donnent toujours lieu à des relations dans le MLDR .
Les associations , selon leur cardinalités , peuvent ou non donner lieu à des relations .
1 ) Transformation des Entités

Relation A
ENTITE A Ao A1 A2 A3
Clé
Identifiant Ao
Propriété A1
Propriété A2
Propriété A3
Une entité A du MCD devient la relation ( ou table ) : A ( Ao# , A1 , A2 , A3 )
L’identifiant Ao de l’entité A devient la clé primaire Ao# de la relation A .

Les autres propriétés deviennent les attributs de la relation A .
Les occurrences de l’entité deviennent les tuples de la relation A .
Le degré de la relation A est le nombre d’attributs de cette relation ( ici deg (A) = 4 )
La cardinalité de la relation A désigne le nombre de tuples de cette relation
87
Construction du Modèle Logique de Données Relationnel ( suite 1 )
2 ) Transformation des Associations

2.1 ) Association multivaluée plusieurs [ 0, N ou 1, N ] à plusieurs [ 0, N ou 1, N ]
ENTITE A ENTITE B
*,N *,N Identifiant Bo

Identifiant Ao Association Propriété B1
Propriété A1 Propriété B2
Propriété A2
Propriété A3
Représentation graphique du MLDR

Relations obtenues : A , B et C
A ( Ao# , A1 , A2 , A3 )
A C
B ( Bo# , B1 , B2 )
Cas d’une association non porteuse : C ( Ao# , Bo# ) Ao # Ao # B
Cas d’une association porteuse des propriétés : C1, C2,... A1 Bo # Bo #
C ( Ao# , Bo# , C1 , C2 , …) A2 B1
A3 B2
Exemple :
Relations obtenues :
DEPOT ARTICLE
1,N 0,N
N° Dépôt Code Article DEPOT ( N° Dépôt # , Adresse, Ville )
Stocker
Adresse Libellé ARTICLE ( Code Article # , Libellé , Qté Stock )
Ville Qté stock STOCKER ( N° Dépôt # , Code Article # )
88
2.2 ) Association hiérarchique Un [ 0, 1 ou 1, 1 ] à Plusieurs [ 0, N ou 1, N ]
ENTITE A ENTITE B
Identifiant Ao *,1 *,N Identifiant Bo

Association Propriété B1
Propriété A1
Cette association traduit la dépendance fonctionnelle inter-entités : Ao Bo

L’entité A qui émet la dépendance fonctionnelle reçoit au niveau logique l’identifiant de l’autre entité B .
La clé primaire Bo # migre dans la relation A comme attribut clé étrangère ou externe .
Relations obtenues : A,B Représentation graphique du MLDR
A ( Ao# , A1 , A2, Bo# ... ) A B

B ( Bo# , B1 , B2 , ...) Ao # Bo #
A1 B1
Exemple : A2 B2
Bo #
Employé Relations obtenues :
Matricule 1, 1 1, N SERVICE
EMPLOYE ( Matr. # , Nom , Prénom ,
Nom CIF N° Service Fonction , N° Service # )
Prénom Libellé Service SERVICE ( N° Service # , Libellé Service )
Fonction
89
2.3 ) Association hiérarchique Un [ 0, 1 ou 1, 1 ] à Un [ 0, 1 ou 1, 1 ]
ENTITE A ENTITE B
Identifiant Ao *,1 Association *,1 Identifiant Bo
Cette association traduit l’existence de 2 dépendances fonctionnelles inter-entités : Ao Bo et Bo Ao

La migration de clé peut se faire dans un sens ou l’autre selon les besoins du système d’information .
Si la cardinalité d’un côté de l’association est 1, 1 ( exemple côté Entité A ) , il est conseillé de choisir
la migration de la clé primaire Bo # dans la relation A comme clé étrangère ( règle équivalente au cas
d’une association hiérarchique )
A ( Ao# , A1 , A2, Bo# ... ) A B

B ( Bo# , B1 , B2 , ...) Ao # Bo #
A1 B1
A2 B2
Exemple : Bo #
FACTURE Relations obtenues :

REGLEMENT
0, 1 1, 1
N° Facture N° Règlement FACTURE ( N° Facture # , Date Facture ,
Date Facture Payer
Date Règlement Montant TTC )
Montant TTC Montant Règl. REGLEMENT ( N° Règl. # , Date Règl. ,
Montant Règl. , N° Facture
90 # )
2.4 ) Association réflexive multivaluée Plusieurs [ 0, N ou 1, N ] à Plusieurs [ 0, N ou 1, N ]
*,N
ENTITE A
Représentation graphique
Identifiant Ao Association du MLDR
Propriété A1
Propriété A2
A
*,N
Ao #
Relations obtenues : A,B A1
A2 B
A ( Ao# , A1 , A2 , ... )
Ao1 #
B ( Ao1# , Ao2# ) : Cas d’une assoc. non porteuse Ao2 #
B ( Ao1# , Ao2# , B1 , B2 , ...) : Cas d’une assoc. porteuse B1
B2
Exemple :
Est parent de Relations obtenues :
PERSONNE 0, N
PERSONNE ( N° CIN # , Nom , Prénom )
N° CIN Parenté
Nom
Prénom 0, 2 PARENTE ( N° CIN_Parent # , N° CIN_Enfant # )
Est enfant de
91
2.5 ) Association réflexive hiérarchique Un [ 0, 1 ou 1, 1 ] à Plusieurs [ 0, N ou 1, N ]
*,N
ENTITE A
Représentation graphique
Identifiant Ao Association du MLDR
Propriété A1
Propriété A2
A
*,1
Ao #
A1
Relation obtenue : A A2
Ao‘ #
A ( Ao# , A1 , A2 , ... , Ao’ # )
Exemple :
Est Chef de Relation obtenue :

SALARIE
0, N
Matricule SALARIE ( Matricule # , Nom , Prénom ,
Nom
Encadrement Fonction , Matricule_Chef # )
Prénom 0, 1
Fonction A pour Chef
92
2.6 ) Association relative incluant une entité faible
ENTITE A ENTITE B
(1,1) *,N Identifiant Bo

Ident. Relatif Ao
Propriété A1  Propriété B1
Cette association traduit le rattachement d’une entité faible ( A ) à une entité classique ( B ) .
L’identifiant absolu de l’entité A est : Ao + Bo .
A ( Ao# , Bo# , A1 , A2, ... ) A B

L ’attribut Bo # dans A est
B ( Bo# , B1 , B2 , ...) Ao # Bo # une clé étrangère qui forme
Bo # B1 avec Ao # une clé primaire
A1 B2 composée .
Exemple : A2
PROJET
PHASE Relations obtenues :
( 1, 1 ) 1, N N° Projet
PROJET ( N° Projet # , Nom Projet , Date début )

N° Phase
Nom Projet
Désignation PHASE ( N° Projet # , N° Phase # ,
Date début
Durée Désignation , Durée )
93
4 ) Application : Schéma relationnel d’un service clientèle dans un café
SERVEUR MLDR
1# 1,N 0,N CALENDRIER
AFFECTER
2
9# SERVEUR ( 1 # , 2 )
1,N 1,N CALENDRIER ( 9 # )

0,N
SUIVRE 1,N TABLE AFFECTER ( 1 #, 9 # , 3 # )
3#
CONCERNER TABLE ( 3 # )
1,1 TRAITER
1,1 COMMANDE ( 11 #, 12, 10 ,
1,1
COMMANDE 1 #, 3 #, 9 # )
11 # CONSOMMATION
12 FIGURER 1,N 4 # FIGURER ( 11 # , 4 # , 7 , 8 )
1,N
10 5
7 CONSOMMATION ( 4#, 5 , 6 )
8 6
Dictionnaire de données
1 - N° de serveur 7 - Quantité d ’une consommation commandée

2 - Nom de serveur 8 - Montant d ’une ligne de commande
3 - N° de table 9 - Date de commande
4 - N° de consommation 10 - Heure de la commande
5 - Libellé consommation 11 - N° de la commande
6 - Prix unitaire consommation 12 - Montant total de la commande
94
Exemple de base de données relationnelle :
PIECE (NOP, DESIGNATION, COULEUR, POIDS)
SERVICE (NOS, INTITULE, LOCALISATION)
ORDRE (NOP, NOS, QUANTITE)
NOMENCLATURE (NOPA, NOPC, QUANTITE)
95
Règles de normalisation
Une forme normale est une propriété d’une base
de données relationnelle qui garantie la qualité,
càd l’abscence de certains défauts.
Quand une relation n’est pas normalisée ceci
presente des anomalies :
 Presence de redondance,
 Se preste à des comportements indésirales

durant les mises à jour.
Les formes normales sont souvent définies sur le
modéle relationnel, mais ont une signification
dans d’atres concepts, exemple le modéle E-R
96
Normalisation
C’est une procédure qui permet de
transformer les schemas non normalisés en
des schémas satisfaisant une forme normale.
La normalisation est utilisée comme
technique de verification des résultats de la
conception d’une BD.
Ne constitue pas une méthodologie de
concecption.
97
Une relation avec anomalies
Employé Salaire Projet Bilan Fonction

Rouge 20 Marte 2 tecnicien
Verd 35 Giove 15 concepteur
Verd 35 Venere 15 concepteur
Noir 55 Venere 15 directeur
Noir 55 Giove 15 consultent
Noir 55 Marte 2 consultent
Maron 48 Marte 2 directeur
Maron 48 Venere 15 concepteur
Blanc 48 Venere 15 concepeteur
Blacn 48 Giove 15 directeur
98
Anomalies
Le salaire de chaque employé est répété dans toutes les t-
uples relatives.
 redondance
Si le salaire d’un employé varie, il faut aller modifier la valeur

dans les différentes tuples
 Anomalie de mise à jour
Si un employé interrompe la participation dans tous les

projets, il faut le supprimer.
 Anomalie de suppression
Un nouveau employé sans projet ne peut pas être inséré.

 Anomalie d’insertion
99
Pourquoi ces phénomes
indésirables ?
Nous avons utilisé une seule relation pour
representer des informations hétérogénes.
 Des employés avec le salaire correspondant

 Les projets avec les bilans
 les participations des employés aux projets

avec leurs fonctions.
100
Les formes normales
o Les formes normales représentent les différents stades de qualité qui permettent
d’éviter des anomalies dans les bases de données relationnelles.
o elles représentent l’état des tables relationnelles en fonction de leurs dépendances
fonctionnelles.
o Il existe 5 formes normales principales et deux extensions

1. Première forme normale (1FN)
2. Deuxième forme normale (2FN)
3. Troisième forme normale (3FN)
4. Forme normale de Boyce-Codd
5. Quatrième forme normale (4FN)
6. Cinquième forme normale (5FN)
7. Forme Normale Domaine-Clé
o Plus le niveau de normalisation est élevé, plus la table sera exemptée d’anomalies
o Une table en forme normale de niveau x est automatiquement en forme normale de
niveau x-1
o À la suite d’une modélisation, la plupart des modèles seront déjà en forme normale de
Boyce-Codd (ou presque)
101
Première Forme Normale (1FN)
o Dans une entité, toutes les propriétés sont élémentaires et il existe au mois
un identifiant caractérisant chaque occurrence de l’entité autrement dit: Une
table est en forme normale si tous ses attributs sont simples et non
décomposables.
o Si une table n’est pas en 1FN, alors elle est FNN (Forme Non Normalisée)
o Si les tables relationnelles résultant de la modélisation ne sont pas déjà en
1FN, il serait approprié de retourner à l’étape de modélisation. Une
modélisation de qualité minimale devrait toujours être en 1FN.
Client
Nom_client
Adresse_client
o Ici, pas de clé primaire et la propriété « adresse » est la concaténation de
rue ville et pays, ce qui donne des tables résultantes en 1FN.
Rq: donc toute table doit avoir une clé primaire et les champs non
décomposables.
102
Deuxième Forme Normale (2FN)
o Une table est en deuxième forme normale si elle est en 1FN et que l’une de ces
trois conditions est respectée:
1.La clé primaire n’est formée que d’un seul attribut

2.La clé primaire contient tous les attributs de la table
3.Si la clé a plus d’un attribut, une dépendance fonctionnelle ne doit jamais exister
entre une partie seulement de la clé et un autre attribut de la table. Tout attribut ne
faisant pas partie de la clé doit dépendre de toute la clé (dépendance fonctionnelle
totale)
o Pour passer de la première forme normale à la deuxième, il faut décomposer

chaque table ne satisfaisant pas les critères en deux autres tables distinctes
o Pour diviser une table en deux, il faut

o Créer une nouvelle table ayant pour clé la partie de la clé primaire dont dépend
le ou les attributs, ainsi que ces attributs eux-mêmes.
o Éliminer ces attributs (ceux qui ne font pas partie de la clé) de la table
originale.
103
Deuxième Forme Normale (2FN)
Exemple 1:
Ligne de commande
N°Cde, Ref
Libellé
quantité
N’est pas en 2FN car: la clé est la concaténation de N°Cde+ Ref mais la
DF N°Cde +Ref et libellé n’est pas élémentaire. La table
Lignedecommande doit être décomposable comme suit:
Commande (0,n) Produit

(1,n) Concerne Ref
N°Cde qté Libellé
104
Exemple 2 :
Supposons mnt la table suivante représentant des modèles génériques
de télévisions construites par différents fabricants. La marque et le
modèle permettent d’identifier de façon unique chaque sorte de
télévision. Le mode sonore ainsi que la résolution sont spécifiques au
modèle et non à la marque.
TÉLÉVISION (Marque, Modèle, ModeSon, Résolution)
Il y a donc une DF entre "Modèle" et "ModeSon", ainsi qu’entre

"Modèle" et "Résolution " Il faudra donc diviser cette table en deux de
la façon suivante :
TÉLÉVISION (Marque#, Modèle#)
MODÈLETV (Modèle#, ModeSon, Résolution)
105
Troisième Forme Normale (3FN)
Une table est en 3FN si elle est déjà en 2FN et qu’aucun attribut ne faisant pas
partie de la clé ne dépend d’un autre attribut ne faisant pas partie lui non plus
de la clé; AUTREMENT DIT: dans une relation toute propriété doit dépendre
de la clé primaire par une dépendance fonctionnelle élémentaire directe.
En 3FN, les dépendances fonctionnelles entre deux attributs ordinaires (ne

faisant par partie de la clé) ne sont pas autorisées.
Pour passer de 2FN à 3FN, il faut:
1. Diviser chaque table ne satisfaisant pas ce critère en deux tables. La

nouvelle table aura comme clé l’attribut dont provient la dépendance et
comme attributs, ceux qui en dépendent.
2. Éliminer les attributs dépendants de la table originale. La clé de la
nouvelle table demeure dans l’ancienne en tant que clé étrangère.
106
Exemple 1:
Dans le cas des voitures usagées, toutes les voitures de la même année sont vendues au
même prix.
VOITURE (NoStock, Marque, Modèle, Année, Couleur, Prix, TélFabricant)
Il y a donc une DF entre "Année" et "Prix", ce qui signifie que cette table n’est pas en
3FN. Il faut donc décomposer cette table en deux.
VOITURE (NoStock, Marque, Modèle, Année, Couleur, TélFabricant)

PRIXVENTE (Année, Prix)
Exemple 2:
Catégorie
Client Client (1,1)
CodeClient codeCatégorie
Nomclient CodeClient
codeCatégorie Nomclient nomCatégorie
nomCatégorie (0,n)
Appartient
107
Forme Normale de Boyce-Codd (FNBC)
il s’agit d’une extension de la 3FN, plus rigide que celle-ci, faite par R.F. Boyce et E.F.
Codd, qui ont constaté que la 3FN pouvait comporter certaines anomalies.
Un modèle relationnel en FNBC est considéré comme étant de qualité suffisante pour
l’implantation d’une BD.
Une table est en FNBC si elle est déjà en 3FN et qu’aucun attribut faisant partie de la
clé ne dépend d’un attribut ne faisant pas partie de la clé primaire.
Les cas de tables modélisées et transformées en 3FN qui ne sont pas déjà en FNBC
sont très rares.
Pour passer de la 3FN à la FNBC, il faut

1. Diviser chaque table ne satisfaisant pas au critère ci-haut en deux tables. La
nouvelle table aura comme clé l’attribut ordinaire dont provient la dépendance et
comme attributs la partie de la clé qui en dépend.
2. Remplacer la partie de la clé concernée par l’attribut ordinaire (qui est devenu la
clé de l’autre table)
108
Exemple 1:
Soit la règle de gestion suivante: tout professeur enseigne une matière et une seule. Toute
classe n’a qu’un seul professeur par matière.
Cours
Matière, N°Classe
CodeProfesseur
N’est pas en BCNF car matière dépend de l’attribut codeProfesseur alors

qu’elle fait partie de la clé primaire concaténé. Le schema devient :
Prof( codeprof#, matiére)
Classe (N°class#)
Faitcours (codeprof#,N°class#)
109
Une strategie plus pratique
Si la relation n’est pas normalisée il faut la

décomposer en 3éme forme normale. Puis, il
faut verifier si le schéma obtenu n’est pas
aussi en BCNF
Si une relation a une seule clé primaire alors
les deux formes normales coincident.
110
Conception et normalisation
la théorie de la normalisation peut être utilisée

dans la conception logique pour verifier le
schema relationnel final. Mais peut être utilisée
aussi durant la modélisation conceptuelle pour
vérifier la qualité du schéma conceptuel.
111
Nom Code
fornissuer
Nom
produit
Adresse
Produit
TVA Prix
TVA  NomFornisseur , Adresse
112
Analyse de l’entité
 L’entité
viole la 3FN à cause de la
dépendance:
TVA  NomFornisseur Adresse
 On peut décomposer l’entité selon cette

dépendance.
113
Nom TVA Nom
produit Code fornisseur
(1,1) (0,N)
Produit Fournir Fornisseur
Prix Adresse
114
Depratement
(0,N)
(0,N) (0,1)
Professeur Theses Etudiant
(0,N)
Cours de master
Etudiant  Cous de master

Etudiant  Professeur
Professeur  Departement
115
Analyse de l’association
La relationship viole la 3FN à cause de la

dépendance:
Professeur  Departement
On peut faire ladécomposition suivante:
116
(0,N)
Departement
Affecter
(1,1)
(0,N) (0,1)
Professeur Theses Etudiant
(0,N)
Cours de master
117
Analyses sur les dépendances
La relationship Theses est en BCNF selon les

dépendances suivantes:
Etudiant  Cours de master
Etudiant  Professeur
les deux propriétés sont indépendantes ceci
suggére une autre décomposition.
118
(1,1)
Inscription
(0,N)
Cours de master
119
Exercice: Normalisation du cas de l’aéroport
Soit le modèle relationnel résultant de la modélisation pour la gestion
de l’aéroport:
AÉROPORT (CodeAéroport, Nom, Ville, Prov-État, Pays, Altitude, LongueurPiste)
VOL (NoVol, Code AéroportDép, CodeAéroportArr, HeureDécollage, HeureAtterrissage)
JOURNÉES-VOL (NoVol, Jour)
RÉSERVATION (NoRéservation, NoClient, NoEnvolée, Prix, Classe)
ENVOLÉE (NoEnvolée, NoVol, CodeAvion, Date)
PASSAGER (NoClient, Nom, NoTél)
PILOTE (NoPilote, Nom, AnnéesExp)
AVION (CodeAvion, Modèle, TypeMoteur, LongueurPisteReq, NbSiègesPrem, NbSiègesDeux,

NbSiègesAff)
HABILITATION (NoPilote, CodeAvion)

120
Tous les attributs sont simples et non décomposables, donc ce modèle est en 1FN.
Pour respecter les contraintes du modèle relationnel, il faut décomposer VOL (exception "2 à plusieurs"
du dernier cours) en deux tables :
VOL (NoVol, Code Aéroport, HeureDécollage, HeureAtterrissage)
AEROPORT-DE-VOL (NoVol, CodeAéroport, Direction)
Les tables AÉROPORT, VOL, RÉSERVATION, ENVOLÉE, PASSAGER, PILOTE et AVION ont des
clés formées d’un seul attribut (condition 1 de la 2FN) et les tables JOURNÉES-VOL et HABILITATION
ont des clés constituées de tous les attributs de la table (condition 2 de la 2FN), donc le modèle est en
2FN.
Dans la table AÉROPORT, il existe une DF qui a pour origine les attributs "Ville" et "Prov-État" et dont
dépend "Pays" (Avec une ville et une province (ou état) donnés, il ne correspond qu’un seul pays). On
divise donc cette table en deux de la façon suivante :
AÉROPORT (CodeAéroport, Nom, Ville, Prov-État, Altitude, LongueurPiste)

VILLE (Ville, Prov-État, Pays)
Il n’existe pas d’autres DF entre attributs ne faisant pas partie de la clé, donc ce modèle est en 3FN.
Il n’existe pas de DF entre des attributs ordinaires et des parties de clé, donc le modèle est en FNBC.
121
Apres décomposition le modèle final en FNBC est donc le suivant :
AÉROPORT (CodeAéroport, Nom, Ville, Prov-État, Altitude, LongueurPiste)
VILLE (Ville, Prov-État, Pays)
VOL (NoVol, Code Aéroport, HeureDécollage, HeureAtterrissage)
AEROPORT-DE-VOL (NoVol, CodeAéroport, Direction)
JOURNÉES-VOL (NoVol, Jour)
RÉSERVATION (NoRéservation, NoClient, NoEnvolée, Prix, Classe)
ENVOLÉE (NoEnvolée, NoVol, CodeAvion, Date)
PASSAGER (NoClient, Nom, NoTél)
PILOTE (NoPilote, Nom, AnnéesExp)
AVION (CodeAvion, Modèle, TypeMoteur, LongueurPisteReq, NbSiègesPrem, NbSiègesDeux,

NbSiègesAff)
HABILITATION (NoPilote, CodeAvion)

122
Résumé des Formes Normales
123
Algèbre Relationnelle
1- Notion d’algèbre Relationnelle:
L’algèbre relationnelle représente une collection d’opérations formelles
pouvant être exécutées sur les relations d’un modèle de données logique
relationnel (MLDR).
On distingue:
 Les opérations ensemblistes:
Elles découlent de la théorie des ensembles. Elles permettent d’obtenir
une nouvelle relation comme le résultat d’une opération d’ensemble sur 2
ou plusieurs relations.
Exemple: union, intersection, différence, produit cartésien, etc…
 Les opérations relationnelles:
Elles sont propres à l’algèbre relationnelle. Elles peuvent utiliser:
 Des opérateurs unaires ( sélection, projection)
 Des opérateurs binaires: (jointure, division).
 Les opérations complémentaires.

Elles permettent de mettre en forme les résultats ou de faire une synthèse
sur les données.
Exemple: opérations de calcul, regroupement, comptage, tri, ect…
124
Exploitation du modèle logique de données
relationnel (suite1)
1.1) les opérateurs ensemblistes:
Opérateur UNION Formalisme: R = UNION ( R1, R2)

Exemple: E1 = Enseignants affectés aux relations extérieures.
E2 = Enseignants représentants syndicaux
E1 N°Enseignant Nom_Enseignant E2 N°Enseignant Nom_enseignant
1 Idrissi 1 Idrissi
3 Chaoui 4 Amrani
4 Amrani 6 Raissi
5 Benzakour
On désire obtenir l’ensemble des enseignants affectés aux relations extérieures et représentants
syndicaux.
R = UNION (E1, E2). R N°Enseignant Nom_Enseignant
L’opérateur UNION porte sur 2 relations uni-compatibles, 1 Idrissi
c’est à dire vérifiant les conditions suivantes: 3 Chaoui
 Le même nombre d’attributs (relations de même degré) 4 Amrani
 Les attributs sont définis dans le même domaine sémantique. 5 Benzakour
La relation résultat R possède les mêmes attributs que E1 et E2 6 Raissi
et la réunion des tuples de E1 et E2 avec élimination des doublons éventuels.
125
Opérateur INTERSECTION Formalisme: R = INTERSECTION ( R1, R2)
Exemple: E1 = Enseignants affectés aux relations extérieures. E2 = Enseignants
représentants syndicaux .
On désire connaître les enseignants affectés aux relations extérieures qui sont des
représentants syndicaux.
R = INTERSECTION (E1, E2).
R N°Enseignant Nom_Enseignant
1 Idrissi
4 Amrani
L’opérateur INTERSECTION porte sur 2 relations uni-compatibles comme l’opérateur

UNION.
Les relations doivent avoir le même schéma
La relation résultat R possède les attributs des relations d’origine et les tuples
communs à chacune.
126
Opérateur DIFFERENCE Formalisme: R = DIFFERENCE ( R1, R2)
Exemple: E1 = Enseignants affectés aux relations extérieures.
E2 = Enseignants représentants syndicaux
On désire connaître les enseignants affectés aux relations extérieures qui ne sont
pas des représentants syndicaux.
R = DIFFERENCe (E1, E2).
R N°Enseignant Nom_Enseignant
3 Chaoui
5 Benzakour
L’opérateur DIFFERENCE porte sur 2 relations uni-compatibles comme l’opérateur

UNION.
La relation résultat R possède les attributs des relations d’origine et les tuples de la
1ère relation qui n’appartiennent pas à la 2ème relation.
127
Opérateur PRODUIT CARTESIEN Formalisme: R = PRODUIT (R1, R2)
Exemple: R1 = Étudiant R2 =Épreuve
R1 N°Étudiant Nom R2 LibelléEpreuve Coefficient
101 X Informatique 5
102 Y Mathématiques 3
Gestion Financière 2
Examen = PRODUIT ( Étudiant, Épreuve).
R N°Étudiant Nom LibelléEpreuve Coefficient
101 X Informatique 5
101 X Mathématiques 3
101 X Gestion Financière 2
102 Y Informatique 5
102 Y Mathématiques 3
102 Y Gestion Financière 2
Cet opérateur porte sur 2 relations de degré quelconque.

La relation résultat possède les attributs de chacune des relations d’origine et des tuples sont
formés par la concaténation de chaque tuple de la 1ère relation avec l’ensemble des tuples de la
deuxième.
128
1-2) les opérateurs relationnels
Opérateur PROJECTION Formalisme: R = PROJECTION ( R1, Liste des attributs)
Exemple: R1 = Joueur Joueur N°Licence Catégorie Année naissance
101 Cadet 1983

212 Cadet 1982
375 Cadet 1983
427 Junior 1981
432 Junior 1981
512 Junior 1980
603 Junior 1979
R= PROJECTION (Joueur, N°Licence, Année naissance)
R N°Licence Année naissance

101 1983
212 1982
375 1983
427 1981
432 1981
512 1980
603 1979
Cet opérateur ne porte que sur ne relation.

Il permet de ne retenir que certains attributs spécifiés d’une relation.
La relation résultat comporte tous les tuples de la relation d’origine à l’exception des
doublons. 129
Opérateur SELECTION Formalisme: R = SELECTION (R1, Condition)
R = SELECTION ( Joueur, Catégorie = ‘Cadet’ ET Année naissance > 1981)
R N°Licence Catégorie Année naissance

101 CADET 1983
375 CADET 1983
L’opérateur SELECTION (ou restriction) ne porte que sur une relation.

Il permet de ne retenir que les tuples répondant à une condition exprimée à l’aide des
opérateurs arithmétiques ( =, >, <, <=, >=, <>) ou logiques de base ( ET, OU, NON).
La relation résultat conserve tous les attributs de la relation d’origine.
130
Opérateur JOINTURE ( Equijointure)
Formalisme: R = JOINTURE ( R1, R2, Condition d’égalité entre attributs)
Exemple:
R1= Produit R2 = Détail_Commande
R1 Code Prod Libellé Prix unitaire R2 N°Cde Code Prod Quantité
590A Hd 1.6Go 1615 97001 590A 2
588J ScanerHP 1700 97002 515P 1
515P PrinterOKI 1820 97003 515P 3
Cet opérateur porte sur 2 relations qui doivent avoir au moins un attribut défini dans le
même domaine sémantique.
La condition de jointure peut porter sur l’égalité d’un ou plusieurs attributs définis dans le
même domaine ( mais n’ayant pas forcement le même nom).
Les tuples de la relation résultat sont formés par la concaténation des tuples des relations
d’origine qui vérifient la condition de jointure. Les tuples doublons sont éliminés.
Remarque: des jointures plus complexes que l’équijointure peuvent être réalisées en
généralisant l’usage de la condition de jointure à d’autre critères de comparaison que
l’égalité( <, >, <=, >=, <>)
131
Opérateur DIVISION Formalisme: R= DIVISION ( R1, R2)
Exemple:
R1 = Participer R2 = Épreuve R= DIVISION(Participer, Épreuve)
Athlète Épreuve Épreuve Athlète
Driss 200m 200m Driss
Manu 400m 400m
Driss 400m 110mh
Khalid 110mH
Driss 110mH
Manu 200m
Cet opérateur porte sur 2 relations qui doivent avoir au moins un attribut défini dans le même
domaine sémantique.
Tous les attributs du diviseur (ici Épreuve) doivent être des attributs du dividende (ici
Participer)
La relation dividende doit avoir au moins une colonne de plus que la relation diviseur.
La relation résultat, le quotient, possède les attributs non communs aux deus relations
initiales.
La relation quotient est formée de tous les tuples qui, concaténés à chacun des tuples du
diviseur (ici Épreuve) donnent tjs un tuple du dividende (ici Participer).
132
1-3) les opérateurs complémentaires
Opérateur de TRI Formalisme: R= TRI( R1, Liste des attributs et options de tri)
Exemple: R1 = Livraison
R1 N°Client Date livraisonArticle Qté Prix unit -A: Tri ascendant
006 10-10-00 Filtre écran 10 250.00 -D: Tri descendant
015 08-05-01 printerHPLaserJet6L 2 3500.00
004 12-05-02 Calvier 102T 5 500.00
015 11-09-02 SourisPS-2 10 100.00
006 28-02-03 PrinterHP LaserJet6L 1 3500.00
002 03-11-03 HP Brio 64Mo-350Mhs 2 13000.00
R= TRI ( Livraison, N°Client-A, Date livraison-D, Article-A)

R1 N°Client Date livraisonArticle Qté Prix unit
002 03-11-03 HP Brio 64Mo-350Mhs 2 13000.00
004 12-05-02 Calvier 102T 5 500.00
006 10-10-00 Filtre écran 10 250.00
006 28-02-03 PrinterHP LaserJet6L 1 3500.00
015 08-05-01 printerHPLaserJet6L 2 3500.00
015 11-09-02 SourisPS-2 10 100.00
Le tri s’effectue sur un ou plusieurs attributs, dans l’ordre croissant ou décroissant.

La relation résultat a la même structure et le même contenu que la relation d’origine.
133
Attributs calculés et renommés
Attributs calculés:
un attribut calculé est un attribut dont les valeurs sont obtenues par des opérations
arithmétiques portant sur des attributs de la même relation. Le calcul est spécifié lors
d’une projection ou lors de l’utilisation d’une fonction.
Exemple: R= PROJECTION( R0, att1, att2, att3, att4, att1*att2, att3+att2)
Attributs renommés:
il est possible de renommer n’importe quel attribut en faisant précéder de son
nouveau nom (ALIAS) suivi de  :  .
Exemple: R = PROJECTION ( R0, att1, att2, att3, att4, Alias: att1*att2, Alias: att3+att2).
Exemple:
R0 N°Client Datelivraison Article Qté Prix Unit
006 10-10-02 Filtre écran 10 250.00
015 16-11-02 PrinterHP LaserJet 6L 2 3500.00
004 03-11-02 Clavier 102T 5 500.00
R= PROJECTION (R0, Datelivraison, Article, Montant : Qté * Prix unit)

R Datelivraison Article Montant
10-10-02 Filtre écran 2500.00
16-11-02 PrinterHP LaserJet 6L 7000.00
03-11-02 Calvier 102T 2500.00
134
Opérateur CALCULER Formalisme: R= CALCULER( R0, Fonction1, Fonction2,…)
Exemple:
R0 = Ligne_Commande R0 N°BonCommande CodeProd Qté PrixU. HT
96008 A10 10 83
96008 B20 35 32
96009 A10 20 83
96010 A15 4 110
96010 B20 55 32
On désire obtenir le chiffre d’affaire total HT, ainsi que le nombre total de produits
commandés:
R = CALCULER ( Ligne_Commande, Somme( qté), somme( Qté *PrixU. HT)
R Somme(Qté) Somme (Qté*Prix.U.HT)

124 5810
Les calculs portent sur la relation R0.
La relation résultat R ne comporte qu’une ligne avec autant de colonnes que de résultats
demandés.
La relation R peut utiliser des attributs nommés ( Alias):
R Nbre_Produits_commndés Chiffre_Affaire_HT
124 5810
135
Opérateur REGROUPER et CALCULER
Formalisme: R = REGROUPER_ET_CALCULER ( R0, att1, att2,.., Foncton1, Fonction2,…)
Exemple:
R0 = Ligne_Commande R0 N°BonCommande CodeProd Qté PrixU. HT
96008 A10 10 83
96008 B20 35 32
96009 A10 20 83
96010 A15 4 110
96010 B20 55 32
On désire obtenir le montant total de chaque bon de commande:
R = REGROUPER_ET_CALCULER ( Ligne_Commande, N°BonCommande,
Mont_HT:Somme(Qté*Prix.U.HT)
Le regroupement s’effectue sur un sous ensemble R N°BonCommade MontantHT
des attributs de la relation R0. 96008 1950
La relation résultat R comporte autant de ligne 96009 1660
que de groupes de tuples, les fonctions 96010 2200
s’appliquent à chacun des groupes séparément.
136
Les opérateurs de base
Représentation Graphique des
opérateurs
137
Représentation graphique des opérateurs projection, restriction,
jointure
138
139
MODULE 2
CREATION D’UNE BASE DE DONNEES
140
Qu’est-ce qu’une base de données ? ( BD )
Une base de données ( BD ) est un ensemble structuré de données enregistrées avec le minimum
de redondance sur un support de stockage informatique et accessibles à plusieurs utilisateurs de
manière sélective et simultanée au moyen d’un système de gestion de base de données ( SGBD ) .
Un SGBD permet de répondre simultanément aux interrogations ( requêtes ) de plusieurs

utilisateurs exprimées sur une même base de données déployée sur un réseau informatique .
Exemple : Base de données d’une compagnie aérienne

Les requêtes sont très variées , par exemple :
- Une réservation : « Liste des passagers qui ont réservé un vol déterminé ? »
- Un équipage : « Quel est le pilote du vol Royal Air Maroc Casablanca – Londres du 15 Octobre
Départ 15 H 30 ? »
- Un appareil : « Quelle est la date de la dernière révision de l’avion N ° 97 ? »
141
Un Système de Gestion de Bases de Données
offre la possibilité à l’utilisateur de manipuler les représentations abstraites des données

( métadonnées ) indépendamment de leur organisation et de leur implantation sur les
supports physiques .
Fonctions principales d’un SGBD
- Décrire et organiser les données sur les mémoires secondaires

( disques, bandes magnétiques , etc… )
- Rechercher, sélectionner et modifier les données
Fonctions complémentaires d’un SGBD
- Sécurité : vérifier les droits d’accès des utilisateurs sur les données
- Intégrité : définir des règles qui maintiennent une cohérence entre les données compte tenu
de leur structure ( contraintes d’intégrité )
- Concurrence d’accès : détecter et traiter les cas où il y a conflit d’accès entre plusieurs
utilisateurs et les traiter correctement .
142
 Créer, ouvrir et fermer une base de données
Pour créer une nouvelle base de données, Fichier / Nouvelle base de
données... et entrer un nom de fichier (Access ajoutera l'extension .MDB).
Pour ouvrir une base de données, Fichier / Ouvrir une base de données...
Pour fermer une base de données, Fichier / Fermer la base de données.
La fenêtre Base de données, en cours de travail , comporte 6 onglets que
nous allons découvrir au fur et à mesure :
143
Tables : Structure générale
Une table est un groupe d'informations sur un domaine précis. Par
exemple tout
ce qui concerne les clients peut être enregistré dans une table, et tout
ce qui
concerne les produits dans une autre.
 Conception d’une table
* Définissez la nature des champs et le type de données stockées
dans chaque champ.
* Déterminez ainsi la structure de base de la table.
* après avoir nommé et sauvegardé la table, vous pouvez lui
ajouter des données.
 Clé primaire: i.e. un ou plusieurs champs qui assurent l ’unicité de
chacun des enregistrements. il Sert à identifier chaque
enregistrement, et, accessoirement, ordonner une table.
144
Tables : Définition des index
 Un index permet à Microsoft Access de retrouver rapidement des

valeurs fréquemment recherchées ou triées. Il permet d ’effectuer un
traitement séquentiel sur une seule colonne ( la colonne indexée ) au
lieu de l’effectuer sur tous les enregistrements de la table .
 Toutes les clés primaires sont par défaut des indexes
 Chaque index est caractérisé par un nom et des propriétés
particulières :
Propriété Signification
Spécifie que l’index est une clé primaire ou non
Primaire
Unique Permet de tolérer ou non des doublons dans les valeurs de la colonne indexée
Ignorer les nuls Permet d’ignorer ou non les valeurs nulles
145
Tables : Opérations de traitement diverses
But: - Attacher une table externe
- Exploiter les données d ’une table
- Importer une table
- Modifier les propriétés des champs et définir la clé
primaire
d’une table importé
- Exporter une table sous la forme d’un fichier Excel
Exemple : Effectuer différents traitements sur les données du tableau suivant
provenant
d ’une feuille de calcul Microsoft EXCEL : « STOCK.XLS » :
Référence Article désignation Quantité Commandée Prix Unitaire Montant
100 Télévision 10 5000
200 Radio 20 500
300 Vidéo 15 3500
146
Tables : Opérations de traitement diverses ( Suite )
1 - Attacher une table externe

Pour attacher une table externe choisissez dans le menu « Fichier », »Données
Externes / Lier les tables… »
Dans la zone « Type de fichier » choisissez le logiciel « Microsoft Excel »

Sélectionner le nom du fichier « STOCK ».
Un assistant est déclenché, suivre les étapes, le fichier apparaît maintenant dans la
fenêtre « Base de données » sous le nom « STOCK » .
147
2 - Exploiter les données d’une table attachée

 Afficher et Modifier les données d’une table
Sur une table attachée , il est possible d ’éditer et de modifier les données des colonnes
mais pas leur structure .
 Modifier la présentation d ’un champ
vous souhaitez voir les données d ’un champ sous une forme particulière
Exemple : Afficher un champ intitulé Montant crée sous Excel dans un format
monétaire.
Marche à suivre :
Cliquez sur le bouton « Mode Création » de la barre d ’outils.
Cliquez sur le bouton « oui », Access affiche la table en mode « création ».
Cliquez sur « Type de données » du champ Montant
148
2 - Exploiter les données d’une table attachée (
Suite )
 Cliquez dans la zone « Format » dans la partie inférieure de la fenêtre
 Sélectionner le format « monétaire ».
 Cliquez sur le bouton « Mode feuille de données » de la barre d ’outils, Access vous
demande alors de sauvegarder les modifications apportées à cette table, cliquez sur le
bouton « OK »
149
3- Importer une table
Si vous voulez exploiter d ’une manière définitive les données avec Access au lieu du tableur (par ex:
Excel), cela
signifie qu ’il n ’est plus nécessaire de faire appel à une table attachée. Vous pouvez maintenant importer
directement cette table dans Access ( Attention : la table , n’est plus disponible dans Excel )
Exemple:
 Sélectionnez dans le menu « Fichier », « Données Externes / Importer »
 Un assistant est déclenché, suivre les étapes, le fichier apparaît dans la

fenêtre
« Base de données » sous le nom « Stock ». 150
4- Modifier les propriétés des champs et définir la clé
primaire d’une table importé:
Renommer la table « Stock » en « Dépôt »

maintenant la table « Dépôt » fait partie intégrante de la base Access. Vous pouvez
donc personnaliser l’apparence de la table. Ouvrez la table « Dépôt » en mode
« création » et effectuez les modifications suivantes:
Exemple :
Modifiez la propriété « Taille de champ » du champ « Réf_article » de « Réel double »
à « Entier long », de cette manière seuls les nombres entiers seront acceptés.
Modifiez le type de données du champ « Montant » du format « Numérique » au
format « Monétaire »
Définissez le champ « Référence » comme clé primaire
Sauvegardez vos modifications
151
5 - Exporter une table sous la forme d ’un fichier Excel
Supposons que vous désirez employer Excel pour analyser les données de la table
« Dépôt » sous forme de graphe.
Exemple:
Sélectionner dans le menu « Fichier », « Enregistrement sous / Exporter.. » pour exporter la table
« Dépôt » dans un fichier Excel.
Une boite de dialogue s ’affiche:
valider le premier choix
Complétez la deuxième boite de

dialogue de la manière suivante: 152
6 - Relations entre les tables
Avec Access , vous pouvez créer au niveau logique deux types de relations: un_à_plusieurs et un_à_un.
La première est la plus fréquente, il s ’agit d ’une relation entre des tables selon laquelle chaque
enregistrement de la table source peut être associé à plusieurs enregistrements de la table liée.
Exemple: Cliquez sur le bouton pour afficher la fenêtre Relations. Elle s'affiche vide.
L’intégrité référentielle garantit une cohérence des données entre chaque couples de tables jointes
( table mère et table fille ) :
- Une table fille doit présenter des valeurs non nulles au niveau d ’un attribut de type clé étrangère .
Ces valeurs doivent appartenir au domaine de valeurs de l’attribut clé primaire correspondant
figurant dans la table mère . Cette vérification est effectuée automatiquement par le système
lorsque la 1ère case sur la figure est cochée
- Lorsque la valeur d’une clé primaire est modifiée dans une table mère , il est possible de répercuter
cette modification sur les valeurs des clés étrangères correspondantes dans toutes les tables filles
qui lui sont jointes en activant la 2ème case à cocher . Même raisonnement pour déclencher des
suppressions d ’enregistrements en cascade à partir d ’une table mère à l’aide de la 3ème case à
cocher
153
MODULE 4
Requêtes en Langage SQL
154
Interrogation simples
 Les interrogations expriment quoi chercher et pas
comment chercher.
 Le comment est produit par l’interpreteur SQL du SGBD
qui traduit la requête SQL avec des opérations interenes
sur les données qui produisent la réponse.
 L’utilisateur ne doit donc pas se préocuper à comment
trouver le résultat.
 Les operations d’interrogration vont être spécifiées avec
l’instruction select
155
LE LANGAGE DE REQUETES SQL
1 – Origines et évolutions
- SQL est dérivé de l’algèbre relationnelle et du langage SEQUEL ( Structured English Query Language ).
- Premiére proposition : SEQUEL, IBM Research 1974
- Premiére implémentation sur les plateformes SQL/DS (IBM) , DB2, puis Oracle (1981) , INGRES ,
INFORMIX , etc…
- Il existe 3 versions normalisées , du plus simple au plus complexe :

* SQL 1 ( 1986 ) : le langage de base
* SQL 1 ( 1989 ) : revue en 1989 (SQL-89) pour ajouter ( contraintes d’intégrité sur les données )
* SQL 2 ( 1992 ) : Deuxiéme version en 1992 , langage complet à 3 niveaux
* SQL 3 ( 1998 ) : Les évolutions orientées objet ( SQL 3 n’est pas encore le nouveau standard )
2 – Les 3 niveaux du langage SQL

* Langage de définition de données ( LDD ) : Il permet de spécifier un schéma conceptuel de BD
CREATE , ALTER et DROP ( tables , indexes et vues )
* Langage de manipulation de données ( LMD ) : Il permet d’interroger et de manipuler les données

SELECT , INSERT , UPDATE , DELETE , OPEN , FETCH , CLOSE , etc…
* Langage de contrôle de données ( LCD ) : Il permet de gérer la sécurité des données, les transactions
et les accès concurrents GRANT et REVOKE , BEGIN et END TRANSACTION , COMMIT et
ROLLBACK, etc…
156
Implementation
Certains DBMS commerciaux
• ORACLE Un DBMS
• DB2 (IBM) tipico
• Access (Microsoft)
• MSSQL server (Microsoft)
SQL-3
• Informix
SQL-2
• Mysql
• …..
SQL-89
SQL-1
157
Definition des données
 On peut utiliser 6 domaines (types de données ) predefinis
 Les types des données sont utiliser pour les attributs (colones) des
relations lors de l’établissement du dictionnaire de données.
Sequence de caractéres alphabétiques (string)
nombre nombre nombre

Matricule Nom Age Salaire
103 Hiba Chaoui 34 20.380
110 Otmane 36 20.500
Boudrika
134 Ghita Kouhen 27 20.500
149 Nino Leonti 33 10.800 Employes
155 Omar Sbai 30 20.500
158
Ie type caractere
Representé par des simples caractéres aphanumérique ou bien chaines
de caractéres de longuer fixe ou variable.
char
char(longueur)
varchar(longueur)
char varying (longueur)
On définit l’attribut Nom de la relation Employes avec une séquence de
caractéres de longueurs maximale 20
Nom char(20) Hiba_Chaoui_______

Nom varchar(20) Hiba_Chaoui
159
Ie type bit
 Correspond aux attributs qui ne peuvent prendre que deux valeurs (0,1)
 Les attributs de ce type (flag) indiquent si l’objet representé possede ou
non une certaine propriété.
bit
bit(longueur)
bit varying (longueur)
On définit l’attribut Travailleur dans la relation Etudiant pour indiquer

si l’étudiant participe ou non en TP.
Tavailleur bit
160
Types numériques exacts
Representent les nombres entiérs ou décimaux avec vigule fixe
numeric numeric(precision) numeric(precision,echelle)

decimal decimal(precision) decimal(precision,echelle)
integer
smallint
On définit l’attribut Age dans la relation Employes

Age decimal(2) Repesente tous les nombres entre -99 e +99
On définit l’attribut Cambio dans la relation Payement la valeur

d’échange du Dirham precis au centime en Euro.
Cambio numeric(8,2) Represente tous les nombres entre -9999,99 et +9999,99

161
Types numériques approximatifs
Ils sont utils pour representer par exemple des grandeurs physiques (à
virgule flotante)
Le paramètre de précision définit la longueur de la mantisse
float float(precision)
double precision
real
On définit l’attribut Masse dans la relation Astéroïdes.
Masse real
0,17E16 = 1,7 1015

162
Date
Permetent de representer des instances de temps
date
time time(precision)
timestamp timestamp(precision)
Chacun de ces domaines est décomposable en un ensemble de champs (année, mois,
jour, heure, minutes, secondes)
DateDeNaissance date 06/03/06

HeurDeLivraison time 19.24.16
Arrivée timestamp 26/03/09 21.15.20
year(Arrivee) = 2000 minute(Arrivee) = 15

163
Intervalles temporels
Il permet de representer des intervalles de temps comme durée des
évenements.
interval PremiereUnitéDeTemps
interval PremiereUnitéDeTemps to DerniéreUnitéDetemps
Exemples
Durée du service en années et en mois (ancienneté)
AncienntéService interval year to month
Temps de livraison en jours et heures
TempsLivraison interval day to hour

164
Observations
Il n'est pas possible de construire des intervalles qui comprennent des
mois et des jours
Vous pouvez spécifier une précision pour la première et seconde unités
de temps
Exemples
Intervalles jusqu’à 999 années et 11 mois
Interval year(3) to month
Des intervalles allant jusqu'à 9 secondes, arrondi à un millième de seconde
Interval second(1) to second(9)
165
BLOB e CLOB
 Binary Large Object (BLOB) et Character Large Object (CLOB) permetent
d’inclure directement dans la database des ficihiers trés grands.
 BLOB et CLOB sont des types définis seulement dans SQL-3, mais
réalisés dans différents DBMS commerciaux.
Une tabele avec images et documents
create table quadres {

nom varchar(50),
nomAuthore varchar(30),
photo BLOB(10M),
description CLOB(100k)
}
166
LE LANGAGE DE MANIPULATION DE DONNEES ( LMD )
Les ordres LMD sont des instructions SQL créées à partir des commandes suivantes :
Commande Rôle
SELECT Interroger une base de données en vue d’extraire les enregistrements qui répondent à
des critères particuliers
INSERT Insérer ( charger ) des lots de données dans la base de données en une seule opération
UPDATE Modifier ( mettre à jour ) des valeurs d’attributs dans une table ou bien des valeurs
d’enregistrements entiers répondant à des critères particuliers
DELETE Supprimer des enregistrements dans une table de base de données sélectionnés d’après
un critère donné .
Chaque commande peut utiliser une ou plusieurs clauses obligatoires et des clauses optionnelles .
Les clauses permettent de définir l’origine et la nature des données qu’il faut sélectionner ou manipuler .
Clause Rôle
FROM Nommer une ou plusieurs tables ou vues à partir desquelles les enregistrements doivent
être sélectionnés
WHERE Spécifier des conditions de jointure et / ou de sélection sur les enregistrements
GROUP BY Spécifier les attributs de regroupement lors d’une opération de calcul et / ou
regroupement
HAVING Spécifier des conditions de sélection sur les enregistrements obtenus après une
opération de regroupement
ORDER BY Trier les enregistrements sélectionnés pour être projetés dans un ordre particulier
167
COMMANDE SELECT : Forme générale
SELECT [DISTINCT] < liste d’attributs de projection simples , calculés ou renommés >
FROM < liste de tables ou vues >
[WHERE < critère de jointure naturelle, théta-jointure, jointure externe > ]
[ AND < critère de sélection simple > ]
[ AND < critère de sélection complexe appelant une sous-requête > ]
[GROUP BY < liste d’attributs de regroupement > ]
[HAVING < critère de sélection sur des attributs calculés ou regroupés > ]
[UNION / INTERSECT / EXCEPT ( autre requête SELECT ) ]
[ORDER BY < liste d’attributs de tri avec ordre de tri > ]
Critère de sélection simple

* arithmétique ( = , < , > , <= , >= , <> )
* textuel ( LIKE )
* sur intervalle ( BETWEEN )
Critère de sélection complexe ( imbrication d’ordres SELECT )
* clause IN ou NOT IN , EXISTS ou NOT EXISTS
* clauses ALL , ANY , SOME , etc…
* sous-requêtes dépendantes ou corrélées 168
COMMANDE SELECT : Les sélections ( restrictions ) simples
Relation utilisée : PRODUIT ( N_Produit , Libellé_Produit , Prix_U , Poids , Couleur )
* Liste des données sur les produits dont le poids est supérieur à 15 Kg
SELECT * FROM Produit WHERE Poids > 15 ;
* Liste des libellés de produits différents dont le poids est compris entre 15 et 40 Kg
SELECT DISTINCT Libellé _Produit FROM Produit WHERE Poids BETWEEN 15 AND 40 ;
* Liste des produits dont le poids n’est pas compris entre 15 et 40 Kg et dont la couleur est
verte , rouge ou bleue
SELECT * FROM Produit
WHERE Poids NOT BETWEEN 15 AND 40
AND Couleur IN ( ‘Vert’, ‘Rouge’, ‘Bleu’ ) ;
* Liste des produits dont le libellé ne commence pas par la lettre D

SELECT * FROM Produit WHERE Libellé _Produit NOT LIKE ‘D%’
* Liste des produits dont la couleur est renseignée

SELECT * FROM Produit WHERE Couleur IS NOT NULL ;
* Liste des produits dont la couleur est n’est pas renseignée

SELECT * FROM Produit WHERE Couleur IS NULL ;
169
COMMANDE SELECT : Les Sélections ( restrictions ) avec sous-requête
Schéma relationnel : DEPOT ( N_Dépôt, Nom_Dépôt, Ville )
STOCKER ( N_Dépôt # , N_Produit # , Qté_Stockée )
PRODUIT ( N_Produit , Libellé_Produit , Prix_U, Poids, Couleur )
•Sous-requête renvoyant une seule valeur ( relation à une seule ligne et une seule colonne ) :
Liste des dépôts situés dans la même ville que le dépôt N° 12

SELECT Nom_Dépôt FROM Dépôt
WHERE Ville = ( SELECT Ville FROM Dépôt WHERE N_Dépôt = 12 )
Liste des produits dont le prix unitaire est supérieur à celui du produit N° 36
SELECT Libellé_Produit FROM Produit
WHERE Prix_U > ( SELECT Prix_U FROM Produit WHERE N_Produit = 36 )
•Sous-requête renvoyant plusieurs valeurs ( relation à une seule colonne et plusieurs lignes ) :
L’opérateur : IN
Liste des produits dont la couleur est la même que celle de l’une des tables
WHERE Couleur IN ( SELECT Couleur FROM Produit WHERE Libellé_Produit = ‘Table’ )
Liste des produits dont le prix unitaire est différent de celui de toutes les armoires
WHERE Prix_U NOT IN ( SELECT Prix_U FROM Produit WHERE Libellé_Produit = ‘Armoire’ )
170
COMMANDE SELECT : Les Sélections ( restrictions ) avec sous-requête ( suite 1 )
* Sous-requête renvoyant plusieurs valeurs ( relation à une seule colonne et plusieurs lignes ) :
Les opérateurs : ANY et ALL

ANY : la comparaison est vraie si elle est vraie pour au moins un des éléments de l'ensemble.
ALL : la comparaison sera vraie si elle est vraie pour tous les éléments de l'ensemble.
La forme ( = ANY ) est équivalente à la forme ( IN )
Les formes ( <> ANY ) et ( <> ALL ) sont équivalentes à la forme ( NOT IN )
=> Liste des produits dont le prix unitaire est inférieure à celui de l’armoire la plus chère
WHERE Prix_U < ANY ( SELECT Prix_U FROM Produit WHERE Libellé_Produit = ‘Armoire’ )
=> Liste des produits dont le prix unitaire est inférieure à celui de l’armoire la moins chère
WHERE Prix_U < ALL ( SELECT Prix_U FROM Produit WHERE Libellé_Produit = ‘Armoire’ )
* Sous-requête renvoyant plusieurs colonnes ( relation à une plusieurs colonnes ) :
=> Liste des produits dont le poids et la couleur sont identiques à ceux de l’article N° 125
WHERE ( Poids , Couleur ) = ( SELECT Poids , Couleur FROM Produit WHERE N_Produit = 125 )
171
* Sous-requête renvoyant au moins 1 ligne ( relation à 1 ou plusieurs colonnes comportant au moins 1 ligne ) :
L’opérateur : EXISTS
=> Liste des produits stockés dans au moins un dépôt avec une quantité supérieure à 1000 unités ?
SELECT Libellé_Produit FROM Produit AS P
WHERE EXISTS ( SELECT * FROM STOCKER WHERE [N_Produit#] = P. N_Produit
AND Qté_Stockée > 1000 )
=> Liste des produits qui ne sont stockés dans aucun dépôt ?
SELECT Libellé_Produit FROM Produit AS P
WHERE NOT EXISTS ( SELECT * FROM STOCKER WHERE [N_Produit#] = P. N_Produit )
* Sous-requêtes multiples
Lorsque les attributs de projection appartiennent tous à la requête principale , on peut utiliser plusieurs
sous-requêtes imbriquées au lieu d’utiliser des jointures
=> Liste des produits ( Libellé, Prix_U et Poids ) stockés à Tanger dans le dépôt ‘Grossisterie Znibar‘ ?
SELECT Libellé_Produit, Prix_U, Poids FROM Produit
WHERE N_Produit IN ( SELECT [ N_Produit# ] FROM STOCKER
WHERE [ N_Dépôt# ] IN ( SELECT N_Dépôt FROM Dépôt
WHERE Ville = ‘Tanger’
AND Nom_Dépôt = ‘Grossisterie Znibar’ )
172
•Les sous-requêtes dépendantes ou corrélées
C’est une forme très puissante des sous-requêtes .

La requête principale fournit plusieurs groupes de valeurs à la sous-requête . Pour chaque groupe de valeurs ,
la sous-requête est évaluée pour donner un résultat .
=> Liste des produits disponibles dans plusieurs couleurs ( au moins 2 )
SELECT Libellé_Produit FROM Produit AS P1
WHERE Libellé_Produit IN ( SELECT Libellé_Produit FROM Produit As P2
WHERE P2.Couleur <> P1.Couleur )
=> Liste des prix unitaires les plus élevés de chaque type de produit
SELECT Libellé_Produit, Prix_U FROM Produit AS P1
WHERE Prix = ( SELECT MAX ( Prix_U ) FROM PRODUIT P2
WHERE P2. Libellé_Produit = P1. Libellé_Produit )
=> Liste des dépôts stockant tous les produits ( simulation de l’opérateur relationnel ‘Division‘ )
SELECT Nom_Dépôt , Ville FROM Dépôt AS D
WHERE NOT EXISTS ( SELECT * FROM Produit AS P
WHERE NOT EXISTS ( SELECT * FROM STOCKER S
WHERE S. [N_Produit#] = P. N_Produit
AND S. [N_Dépôt#] = D. N_Dépôt )
173
COMMANDE SELECT : Les Fonctions Statistiques
Le langage SQL offre la possibilité de récupérer des données chiffrées sur des tables ou des vues .
On peut par exemple obtenir le nombre de tuples répondant à un critère de sélection avec la fonction
COUNT , la valeur moyenne d’une colonne avec la fonction AVG , la valeur maximale ou minimale
et la somme d’une colonne avec les fonctions MAX , MIN et SUM .
=> Compter le nombre de dépôts où le produit N° 122 est stocké
SELECT COUNT(*) AS Compte FROM STOCKER WHERE [ N_Produit# ] = 122
=> Calculer la somme globale , la moyenne , le maximum et le minimum des quantités stockées du produit
N° 122
SELECT SUM ( Qté_Stockée ) , AVG ( Qté_Stockée ) , MAX ( Qté_Stockée ) , MIN ( Qté_Stockée )

FROM STOCKER WHERE [ N_Produit# ] = 122
=> Compter les noms de produits différents
SELECT COUNT ( DISTINCT Libellé_Produit ) AS Compte FROM Produit
174
COMMANDE SELECT : Les Regroupements
On appelle « Groupe » un ensemble de lignes ( tuples ) dans une relation qui possèdent une valeur identique dans
une ou plusieurs colonnes . Cette colonne ( ou ensemble de colonnes ) peut être définie comme un
« facteur de regroupement » à l’aide de la clause « GROUP BY » de la commande SELECT .
SQL permet alors d’effectuer des calculs sur les autres colonnes ( qui ne sont pas des facteurs de regroupement )
en utilisant les fonctions statistiques ( fonctions d’agrégation ) : COUNT , SUM , AVG, MAX et MIN .
La clause « HAVING » permet d’appliquer une condition de sélection ( restriction ) à chaque groupe dans la
relation résultat de la requête au niveau des colonnes de regroupements et / ou de calcul .
Remarque : Dans la commande SELECT , les colonnes de calcul sont toujours spécifiées dans la liste des
attributs de projection . Toutes les autres colonnes ( non calculées ) figurant dans cette liste sont alors
considérées comme des facteurs de regroupement et doivent figurer dans la clause « GROUP BY » .
=> Liste du nombre de produits par type de produit

SELECT Libellé_Produit , COUNT(*) AS [Nombre articles ] FROM PRODUIT
GROUP BY Libellé_Produit ORDER BY 1 ;
=> Liste des N° de produits stockés dans plus de 2 dépôts
SELECT [ N_Produit# ] , COUNT(*) AS [Nombre dépôts] FROM STOCKER
GROUP BY [ N_Produit# ]
HAVING COUNT(*) > 2 ORDER BY 1 ;
=> Lister les dépôts de la ville de Rabat dont la valeur marchande est supérieure à 100 000 DH
SELECT Nom_Dépôt , SUM ( Prix_U*Qté_Stockée ) As [ Valeur en DH ]
FROM Dépôt As D , Stocker As S , Produit As P
WHERE D.N_Dépôt = S.[N_Dépôt#] AND S.[N_Produit#] = P.N_Produit AND Ville = ‘ Rabat ’
GROUP BY Nom_Dépôt
HAVING SUM ( Prix_U*Qté_Stockée ) > 100 000 ORDER BY 2 DESC 175
COMMANDE INSERT : Forme générale
1ère Forme
INSERT [INTO] < Nom de Table >
[ < Liste d’attributs entre parenthèses > ]
VALUES < Liste de valeurs correspondant aux attributs entre parenthèses >
2ème Forme
INSERT [INTO] < Nom de Table >
[ < Liste n° 1 d’attributs entre parenthèses > ]
SELECT < Liste n°2 d’attributs correspondant en type à ceux de la Liste n°1 >
[WHERE < critère de jointure naturelle, théta-jointure, jointure externe > ]
[etc… ]
Remarques :
- Les attributs non spécifiés dans la liste n°1 restent à NULL ou à leur valeur par défaut après l’insertion de tuples
- On doit toujours fournir une valeur dans l’ordre INSERT pour les attributs déclarés NOT NULL
( déclaration effectuée lors de la création de la table )
176
COMMANDE INSERT : Exemples
Schéma relationnel : PRODUIT ( N_Produit , Libellé_Produit , Prix_U , Poids , Couleur )
ARTICLE ( N_Article , Désignation , Prix_U )
* Insertion d’une ligne ( un tuple ) dans la table PRODUIT

INSERT INTO PRODUIT VALUES ( 20 , ‘VASE DE CHINE’ , 250 , 15 , ‘BLEU’ )
* Insertion de 2 lignes ( 2 tuples ) dans la table PRODUIT avec certaines valeurs nulles
INSERT INTO PRODUIT VALUES ( 21 , ‘VERRE CRISTAL’ , 50 , 0.25 , NULL ) ,
( 22 , ‘FOURCHETTE INOX’, 10 , NULL , NULL )
* Insertion de 2 lignes dans la table PRODUIT avec spécification des attributs d’insertion
INSERT INTO PRODUIT ( N_Produit , Libellé_Produit )
VALUES ( 23 , ‘CUILLERE INOX’ ) , ( 24 , ‘COUTEAU INOX’ )
* Insertion de tous les tuples de la table PRODUIT dont le prix est supérieur à 200 DH dans la Table ARTICLE :
( la structure des colonnes dans la table cible doit être la même que celle des colonnes dans la table source )
INSERT INTO ARTICLE
SELECT N_Produit , Libellé_Produit , Prix_U FROM PRODUIT
WHERE Prix_U > 200 ;
* Requête interdite : la duplication des tuples d’une table par un INSERT avec une sous-requête sur la même table
INSERT INTO PRODUIT
SELECT * FROM PRODUIT ;
177
COMMANDE UPDATE : Forme générale
1ème Forme
UPDATE < Nom de Table >
SET < Attribut1 = Valeur1 > ,
< Attribut2 = Valeur2 > , etc …
[WHERE < critère de sélection simple
ou critère de sélection complexe appelant une sous-requête > ]
2ème Forme
UPDATE < Nom de Table >
SET < Attribut1 = Valeur1 > ,
< Attribut2 = Valeur2 > , etc …
WHERE < critère de jointure naturelle, théta-jointure, jointure externe >
178
COMMANDE UPDATE : Exemples
Schéma relationnel : PRODUIT ( N_Produit , Libellé_Produit , Prix_U , Qté_Stock )
ACHETER ( N_Produit , N_Client , Qté_Achetée , Date_Achat )
CLIENT ( N_Client , Nom , Adresse , Tél , Chiffre_Affaire )
* Mise à jour du prix de tous les produits pour tenir compte d’une augmentation de 10 DH
UPDATE PRODUIT SET Prix_U = Prix_U + 10 ;
* Mise à jour des produits de luxe dont le prix est supérieur à 1000 DH seulement ( augmentation de 15 % )
UPDATE PRODUIT SET Prix_U = Prix_U * 1.15
WHERE Prix_U > 1000 ;
* Mise à la valeur nulle des adresses et téléphones et initialisation du chiffre d’affaires réalisé avec tous les clients
dont le nom commence par la lettre B ( dans le but de recommencer leur saisie )
UPDATE CLIENT SET Adresse = Null , Tél = Null , Chiffre_Affaire = 0
WHERE Nom LIKE ‘ B% ’ ;
* Mise à jour de la Qté en stock de tous les produits ayant fait l’objet de ventes durant la journée
du 10/01/2001 ( seule une vente par produit sera prise en compte à cette date )
UPDATE PRODUIT SET Qté_Stock = Qté_Stock - A.Qté_Achetée
FROM PRODUIT P , ACHETER A
WHERE P.N_Produit = A.N_Produit
AND A.Date_Achat = ‘ 10/01/01’
179
COMMANDE UPDATE : Exemples ( suite )
Attention !
Une instruction UPDATE ne met jamais à jour une même ligne à deux reprises.
Le schéma relationnel considéré suppose qu'un produit peut être vendu à plusieurs reprises
( acheté par plusieurs clients ) le même jour .
Avec l’ordre UPDATE précédent , il y aura exécution sans erreur, mais chaque produit ne sera mis à jour
qu'avec une seule vente, en dépit du nombre de ventes ayant réellement eu lieu à la date spécifiée .
Solution du problème :
Au cas où plusieurs ventes ont lieu le même jour pour un produit donné, toutes les ventes de chaque
produit doivent être additionnées dans l’ordre UPDATE et le stock mis à jour à l’aide de la somme obtenue ,
comme le montre l’ordre SQL suivant :
UPDATE PRODUIT P
SET Qté_Stock = Qté_Stock -
( SELECT SUM ( Qté_Achetée )
FROM ACHETER A
WHERE P.N_Produit = A.N_Produit
AND Date_Achat = ‘ 10/01/01’ ) ;
Autre requête à exprimer :

Mettre à jour le chiffre d’affaires réalisé avec tous les clients pour tenir compte des ventes
effectuées le dernier jour d’ouverture du magasin ? 180
COMMANDE DELETE : Forme générale et Exemples
DELETE FROM < Nom de Table >

[WHERE < critère de sélection simple
ou critère de sélection complexe appelant une sous-requête > ]
Exemple : PILOTE ( N_Pilote , Nom , Prénom , Adresse , Salaire )

AVION ( N_Avion , Type , Capacité )
VOL ( N_Pilote , N_Avion , Date_Vol , Heure_Dép , Heure_Arr , Ville_Dép , Ville_Arr )
* Suppression de tous les vols ( tous les tuples de la table VOL )

DELETE FROM VOL ;
* Suppression de tous les vols qui datent d’avant le 28 Février 2000
DELETE FROM VOL WHERE Date_Vol < ‘ 28/02/01’ ;
* Suppression de tous les vols assurés par le pilote ‘ DRISSI ’
DELETE FROM VOL WHERE N_Pilote IN
( SELECT N_Pilote FROM PILOTE WHERE Nom = ‘ DRISSI’ )
* Suppression de tous les pilotes qui n’ont effectué aucun vol
DELETE FROM PILOTE P WHERE NOT EXISTS
( SELECT * FROM VOL WHERE N_Pilote = P.N_Pilote )
181
LE LANGAGE DE DEFINITION DE DONNEES ( LDD )
Les ordres LDD sont des instructions SQL créées à partir des commandes suivantes :
Commande Rôle
CREATE Création de la structure d’une table , d’un index ou d’une vue de

données en spécifiant des contraintes structurelles ou d’intégrité
référentielle à respecter sur les données
DROP Supprimer une table , un index ou une vue ( structure et données )
ALTER Modifier la structure d’une table ( ajout , suppression ou mise à jour

d’un ou plusieurs attributs )
Chaque commande peut utiliser une ou plusieurs clauses obligatoires et des clauses optionnelles
182
COMMANDE CREATE TABLE : Forme générale
CREATE TABLE < Nom de Table >

[ < Nom attr. > < Type > ] , …
ou [ < Nom attr. > < Type > < Contrainte d’attr. > ] , …
ou [ < Nom attr. > < Type > CONSTRAINT <Nom contrainte> <Contrainte d’attr.> ] ,
ou [ CONSTRAINT < Nom contrainte > < Contrainte de Table > ] , etc ...
Les contraintes constituent une méthode normalisée par l’ANSI pour assurer l’intégrité des
données .
Chaque type d’intégrité ( de domaine , d’entité ou référentielle ) est mis en œuvre à l’aide de types
de contraintes spécifiques ( voir tableau ).
Les contraintes garantissent la validité des valeurs saisies dans les colonnes et le maintien des
relations entre les tables .
Les principales contraintes sont DEFAULT , CHECK , PRIMARY KEY , UNIQUE

et FOREIGN KEY .
L’écriture d’un ordre CREATE TABLE utilisant ces contraintes peut différer légèrement suivant
le SGBD utilisé ( ACCESS , SQL Server , ORACLE , SYBASE , INFORMIX , etc… )
183
COMMANDE CREATE TABLE : Les Contraintes d’intégrité
Type d’intégrité Type de Contrainte Description

-----------------------------------------------------------------------------------------------------------------------
Domaine DEFAULT Spécifie la valeur qui sera placée dans la colonne si aucune
valeur n’est spécifiée explicitement dans l’instruction
INSERT au moment de la saisie
CHECK Spécifie une règle de validité s’appliquant aux valeurs
d’une colonne .
FOREIGN KEY Les valeurs de colonne de clé étrangère doivent
correspondre aux valeurs des colonnes de clé primaire de la
table référencée .
Entité PRIMARY KEY Identifie chaque ligne de façon unique , interdit l’entrée de
valeurs en double et garantit la création d’un index pour
améliorer les performances . Les valeurs NULL ne sont pas
acceptées .
UNIQUE Empêche la création des doublons dans les colonnes qui ne
constituent pas une clé primaire et garantit la création d ’un
index pour améliorer les performances . Les valeurs NULL
sont acceptées .
Référentielle FOREIGN KEY Définit une colonne ou un ensemble de colonnes dont les
valeurs sont égales à la clé primaire de leur table ou d ’une
autre table .
Définie par CHECK Spécifie une règle de validité s’appliquant aux valeurs de
l’utilisateur colonnes .
-----------------------------------------------------------------------------------------------------------------------
184
COMMANDE CREATE TABLE : Exemples
* Spécification de contraintes d’attributs
CREATE TABLE Etudiant
( Matricule INT NOT NULL CONSTRAINT Clé_Primaire PRIMARY KEY ,
Nom CHAR(25) NOT NULL ,
Prénom CHAR(25) NOT NULL ,
Sexe CHAR(1) NOT NULL CHECK ( Sexe IN ( ’M', ’F ’ ) ) ) ;
CREATE TABLE Employé

( Code CHAR(9) NOT NULL CONSTRAINT Clé_Primaire PRIMARY KEY NONCLUSTERED
CHECK ( Code LIKE
'[A-Z][A-Z][A-Z][1-9][0-9][0-9][0-9][0-9][MF]' OR
Code LIKE '[A-Z]-[A-Z][1-9][0-9][0-9][0-9][0-9] [0-9][MF]’ ) ,
Nom VARCHAR(30) NOT NULL,
Prénom VARCHAR(30) NOT NULL,
N_Fonction SMALLINT NOT NULL DEFAULT 1 REFERENCES Fonction ( N_Fonction ) ,
Date_Embauche DATETIME NOT NULL DEFAULT ( GETDATE() ) ) ;
CREATE TABLE Fonction

( N_Fonction SMALLINT IDENTITY( 1 , 1) PRIMARY KEY CLUSTERED ,
Libellé_Fonction VARCHAR(50) NOT NULL DEFAULT ’ Fonction ? ',
Echelle TINYINT NOT NULL CHECK ( Echelle <= 11 ) ) ;
Remarque : L’utilisation du qualificatif IDENTITY(Valeur_initiale , Incrément ) permet de spécifier

un attribut qui doit faire l’objet d’une incrémentation automatique par le système à chaque ajout de
185
tuple
COMMANDE CREATE TABLE : Exemples ( Suite )
* Spécification de contraintes de table
- Contrainte d’unicité : Il ne peut y avoir 2 dépôts de même nom dans la même ville :
CREATE TABLE DEPOT
( N_Dépôt INT NOT NULL CONSTRAINT Clé_Primaire PRIMARY KEY ,
Nom_Dépôt CHAR(25) NOT NULL ,
Ville VARCHAR(25) NOT NULL ,
CONSTRAINT C_Dépôt UNIQUE ( Nom_Dépôt , Ville ) ) ;
- Contrainte sur les domaines de valeurs de plusieurs attributs

CREATE TABLE Produit
( N_Produit INT NOT NULL CONSTRAINT Clé_Primaire PRIMARY KEY ,
Désignation CHAR(25) NOT NULL ,
Poids DECIMAL(8,2) NULL ,
Prix_U DECIMAL(10,2) NULL ,
CONSTRAINT C_Produit CHECK ( Poids > 0 AND Prix_U > 0 AND Prix_U <= 10000 ) ) ;
- Contrainte de type Clé primaire composée

CREATE TABLE STOCKER
( N_Produit INT NOT NULL REFERENCES Produit ( N_Produit ) ,
N_Dépôt INT NOT NULL REFERENCES Dépôt ( N_Dépôt ) ,
CONSTRAINT C_Stocker PRIMARY KEY (N_Produit , N_Dépôt ) ) ;
186
COMMANDE ALTER TABLE : Forme générale
But : Modifier la définition d'une table en changeant, en ajoutant ou en supprimant des colonnes ou des contraintes
1ère Forme :
ALTER TABLE < Nom de Table >
[ ADD < Nom attr. > < Type > [ < Contrainte d’attr. > ] ] , …
ou [ ADD CONSTRAINT < Nom contrainte > < Contrainte > ] , …
2ème Forme :
[ DROP COLUMN < Nom attr. > ] , ...
ou [ DROP CONSTRAINT < Nom contrainte > ] , …
3ème Forme :
[ ALTER COLUMN < Nom attr. > < Nouveau Type > [ < Contrainte d’attr. > ] ] , .
187
COMMANDE ALTER TABLE : Exemples ( Suite )
- Ajout d’une colonne simple à la structure d’une table
ALTER TABLE Vente ADD Commission MONEY NULL ;
- Ajout d’une colonne ou de plusieurs colonnes avec contraintes

ALTER TABLE Client ADD Code_Client INT IDENTITY ( 1,1 )
CONSTRAINT PK_Client PRIMARY KEY ;
ALTER TABLE Employé ADD

N_Dép INT NOT NULL CONSTRAINT C_Dép REFERENCES Département ( N_Dép ) ,
Tél VARCHAR ( 10 ) NULL CONSTRAINT C_Tél CHECK ( Tél IS NULL OR
Tél LIKE "[0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]" OR
Tél LIKE " [0-9][0-9][0-9]) [0-9][0-9][0-9]-[0-9][0-9][0-9][0-9] " ) ,
Salaire DECIMAL ( 8, 2 ) CONSTRAINT C_Salaire DEFAULT 5000 ;
- Ajout d’une contrainte

ALTER TABLE Employé ADD CONSTRAINT C_Employé CHECK ( Date_Embauche > ‘ 01/01/98 ’ ) ;
- Suppression d’une colonne ou d’une contrainte

ALTER TABLE Personne DROP Age ;
ALTER TABLE Employé DROP CONSTRAINT C_Employé ;

188
COMMANDE DROP : Forme générale et Exemples
DROP TABLE < Nom de table >

ou DROP INDEX < Nom d’indexe >
ou DROP VIEW < Nom de Vue >
But : Supprimer un objet table , index ou vue de la base de données en éliminant les
informations de structure liées à cet objet et les données qui lui sont attachées .
Exemples :
DROP TABLE Client ;
DROP INDEX Clé_Primaire_Client ;
DROP VIEW Commande_Client ;
189
COMMANDE CREATE INDEX : Forme générale et Exemples
CREATE [UNIQUE ] INDEX < Nom de l’indexe >

ON < Nom de Table >
( < Nom Attr. > , < Nom attr. > , ….. )
On utilise un index sur un attribut ou un groupe d’attributs de table dans les situations suivantes :
* Pour implémenter l’intégrité de relation ( de table ) permettant de garantir l’unicité des valeurs
de la clé primaire ( Commande CREATE INDEX avec le qualificatif UNIQUE )
* Pour définir une ou plusieurs clés candidates ( attributs à valeurs distinctes ) dans une table
* Pour accélérer le temps de réponse de certaines opérations de traitement sur la base de données
lorsque le nombre d’enregistrements des tables est très important :
- Recherche ou Tri croissant / décroissant sur une ou plusieurs colonnes
- Requête de sélection utilisant un filtre sur une ou plusieurs colonnes avec une clause WHERE
- Requête utilisant des jointures sur certains attributs communs à 2 ou plusieurs tables
On définit alors un indexe sur la ou les colonnes en question ( colonnes de recherche , de tri ,
de sélection , de jointure , etc… )
Exemples :
CREATE UNIQUE INDEX PK_Pilote ON Pilote ( N_Pilote ) ; // Clé primaire simple
CREATE UNIQUE INDEX PK_Stocker ON Stocker ( N_Produit , N_Dépôt ) ; // Clé primaire composée
CREATE INDEX IX_Vente ON Vente ( Date_V DESC , Réf_Produit ) ; // Index sur un couple
d’attributs de190
tri
COMMANDE CREATE VIEW : Forme générale et Exemples
CREATE VIEW < Nom de Vue > ( < Nom Attr. > , < Nom attr. > , … )
AS < Instruction SELECT > ;
1 - Notion de Vue : Une vue est une table virtuelle déterminée à partir d’autres tables à l’aide d’une requête de
sélection . Les données affichées par une vue ne sont pas physiquement stockées dans la base de données mais
correspondent au résultat de l’exécution d’une requête d’interrogation sur les données stockées dans d’autres
tables .
2 - Avantages de l’utilisation des vues :

* Sauvegarde de requêtes complexes et simplification de l’accès aux données en masquant les opérations de
jointures et d’agrégation :
Création d’une vue : CREATE VIEW Commande_Produit AS
SELECT P.N_Produit , Désignation , Prix_U , Date_Commande , Qté_Stock
FROM Produit P , Commande C
WHERE P.N_Produit = C.N_Produit ;
Utilisation de la Vue : SELECT N_Produit , Désignation FROM Commande_Produit
WHERE Qté_Stock > 10 ;
* Support de l’indépendance logique :
Si la structure de la table Produit est mise à jour , la vue Commande_Produit doit être reconstituée mais les
requêtes qui utilisent cette vue n’ont pas à être remaniées .
191
COMMANDE CREATE VIEW : Exemples ( Suite )
* Renforcement de la sécurité des données par masquage des attributs et des tuples dans les tables à certains
utilisateurs :
L’exemple suivant montre 2 vues définies pour 2 catégories de représentants commerciaux dans une entreprise :
ceux affectés à la région d’Agadir et ceux affectés à celle de Casa .
Chacune de ces vues permet d’obtenir les informations sur les clients d’une région mais ne donnent pas accès
aux données des autres régions ni à celles des autres attributs des tables Client et Commande .
CREATE VIEW Commande_Client_Agadir AS
SELECT A.N_Client , A.Nom_Client , B.N_Produit , B.Désignation , B.Qté_Commandée
FROM Client A , Commande B
WHERE A.N_Client = B.N_Client
AND A.Ville = ‘’Agadir ‘’ ORDER BY 2 , 3 ;
CREATE VIEW Commande_Client_Casa AS

SELECT A.N_Client , A.Nom_Client , B.N_Produit , B.Désignation , B.Qté_Commandée
FROM Client A , Commande B
WHERE A.N_Client = B.N_Client
AND A.Ville = ‘’Casa ‘’ ORDER BY 2 , 3 ;
3 - Problème de mise à jour des données à l’aide d’une vue :

La mise à jour des données via une vue pose des problèmes pour la plupart des SGBD relationnels .
Les conditions nécessaires pour que les données d’une vue soient accessibles en mise à jour et que cette mise à jour
se répercute sur les tables d’origine sont :
> Le mot clé DISTINCT doit être absent dans l’ordre SELECT et la clause FROM doit faire référence à une seule table
> Les attributs de projection de l’ordre SELECT doivent être de type simple ( pas d’agrégat ou d’attribut calculé )
> Les clauses de regroupement GROUP BY et de sélection de groupe HAVING doivent être absentes .
192
Check option
Check option specifie que aprés les opérations de modification les lignes
doievent continuer à être dans la vue.
 Avec l’option cascaded le controle doit être etendu aux vues liées.
 Avec l’option local le controle doit être effectué juste sur cette vue.
create view EtudiantMeritenote (Matricule,Nom,Prenom)

as select Matricule,Nom,Prenom from Etudiants
where Matricule in (select etudiant from examen
group by etudiant having avg(Voto)>=28)
with local check option
Update EtudiantMeritenote set note=25 La commande

where matricule=‘1231323’ sera refusée
193
Vue et interrogations
Les vues permettent d’etendre les capacités des

interrogations.
Pour calculer le maximun des moyenes des notes des cours il

faut créer une vue. Il n’est pas possible de faire la même
chose en utilisant seuelemnt des requetes.
create view moyenParCours (cours,moyenne)

as select cours, AVG(note)
group by cours
select max(moyenne) from moyenneParCours
194
Controle des accées
 SQL présuppose que l’utilisateur soit identifié de façon

univoque par système.
 Pour l’identification le SGBD peut exploiter le système
d'exploitation sous-jacent ou de fournir son propre
mécanisme di’identification.
 Le SGBD permet de concevoir toutes les ressources :
tables, colonne, vues, procedure
 A chaque resssource est associée une liste de privileges
 Le créateur de la ressource possede tous les priviléges.
195
Ressources et priviléges
 Les priviléges dispinibles sont:

 insert
insertion des données (tables et attributs)
 update
modifier les données (tabbles et attributs)
 select
lire la ressource (seules les tables)
 references
faire reference à une ressource
 usage
utiliser une ressource (domaines)
196
La commande grant
 La commande grant permet d’accorder des priviléges
Donner le privilége d’insérer dans la table Etudiants à NINO
grant insert on etudiants to NINO
Accorder à NINO et otman tous les priviléges sur la table

etudiants.
grant all privileges on etudiants to NINO, Otman
197
grant option
 Avec with grant option accorde aussile droit

d’administration du privilége.
Donner à NINO la possibilité de décider qui peut inserer des

données dans la table etudiants.
Grant insert on etudiants to NINO with grant option
198
La commande revoke
 Les priviléges peuvent être révoqués seulement par qui il les a accordés.
 On peut provoquer une cascade de revocation.
 Il n’est pas necessaire de revoquer tous les priviléges accordés.
Enlever à NINO le privilége d’insertion et tous les priviléges accordés.
revoke select on etudiants from NINO cascade
Accorder à NINO et Otman tous les ptriviléges sur la table etudiants.
Grant all priviles on etudiants to NINO, Otman
revoke insert on etudiants from Otman
199
Un exemple récapitulatif traité d’un cas réel
Informatisation de la géstion des données d’une association de

personnes à mobilité restrintes (handicapés):
• analyses et définition des besoins
• conception de l’architecture du système et déscription des
outils utilisés.
• Modele conceptuel des données
• modele logique des données
• Exemple de problemes specifiques liés à la conception
et leurs solutions.
200
Descrizione del problema
L’associazione si occupa di disabili ed è in grado fornire numerosi
servizi medici e sociali (visite mediche, terapie riabilitative,
laboratori in cui si insegna informatica, comunicazione, ...)
I servizi vengono rimborsati all’associazione dalle ASL nel caso si tratti di
servizi coperti dal servizio sanitario
Le informazioni da gestire sono
 dati medici relativi agli utenti
 dati sui servizi erogati necessari per motivi contabili
 dati anagrafici degli utenti
 dati del personale dell’associazione
201
L’obbiettivo
dell’informazione
Creare un sistema informativo centralizzato
 evita duplicazioni dell’informazione
 premette agli operatori dell’associazione un semplice e immediato
accesso a tutte le informazioni disponibili
 garantisce segretezza e sicurezza dei dati
Permettere statistiche in tempo (quasi) reale sui dati

 misurare la qualità dei servizi offerti
 valutare l’operato di medici e terapisti
 individuare i possibili sprechi
 prevedere l’andamento economico dell’associazione in tempo per
prendere i necessari provvedimenti
202
Analisi del problema: i
requisiti generali
L’associazione possiede più di una sede:
 i dati aggiornati devono essere disponibili in tutte le sedi
 ove possibile, i dati devono essere modificabili da ogni sede
Il sistema informativo deve essere accessibile dall’esterno

 prevedere l’accesso da piattaforme eterogenee
Un sistema informativo centralizzato

 se si perde un dato, non esiste altrove (occhio alla sicurezza)
 se si blocca il sistema, nessuno lavora (occhio alla robustezza)
203
requisisti
La politica di sicurezza:
generali II
 esistono quattro figure professionali con diritti di accesso
chiaramente distinti (medici, terapisti, segretari, amministratori)
 con dati sensibili ci sono problemi di privacy
 i diritti di accesso cambiano nel tempo e devono essere flessibili
Esempi paradossali:
 i segretari devono avere accesso ai dati medici ?
sì, …. se i medici non imparano a scriversi le anamnesi!!
 L’amministrazione modifica le anagrafiche pazienti ?
sì, … perché i pazienti forniscono nomi errati alle segreterie!!
204
requisisti generali
L’informatizzazione cambia il modo di lavorare
III
 ridefinire i compiti del personale e i modi di interazione
 vincoli troppo stretti bloccano il lavoro, troppo deboli permettono di fare
errori
 il cambiamento sarà graduale e il sistema deve essere molto flessibile in
modo da affrontare gli inevitabili aggiustamenti
Esempi
 Chi inserisce i dati anagrafici del paziente, i segretari alla prenotazione o i
medici alla prima visita ?
 Le segreterie prenotano le visite, i medici segnalano le assenze dei
pazienti, gli amministratori controllano le autorizzazioni dell’ASL … come
essere sicuri di non perdere niente?
205
La struttura del sistema
Un DBMS per sede contiene una copia dei dati
 garantisce la segretezza
 fornisce strumenti per la sicurezza
 fornisce strumenti per la replicazione fra le sedi
L’applicazione scritta in Java

 garantisce la portabilità su piattaforme diverse
 facilità di scrittura del codice
Accesso ai dati attraverso JDBC

 garantisce una certa indipendenza dal DBMS usato
206
La struttura del sistema
Driver Applicazione
JDBC java Client 1
Server sede1
DBMS : : :
Driver Applicazione
JDBC java Client n
replicazione Driver Applicazione Client 1

JDBC java
DBMS : : :
Server sede2 Driver Applicazione
JDBC java Client m
207
Analisi: pazienti e
personale
I pazienti sono caratterizzati da
nome, cognome, codice fiscale, data di nascita, recapito, residenza
asl e codice sanitario attuali
sede presso cui il paziente si reca di solito
invalidità se presente
….
Personale operante nel centro
nome, cognome, indirizzo, ...
ruolo svolto nel centro
(medico, terapista,segretario,amministratore)
sede presso la quale il terapista opera
…
208
Schema concettuale:
pazienti e operatori
residenza recapito
codice fisc. Nome

residenza
invalidità Anagrafic Cognome recapito
data nascita
deceduto a citta nascita
Nome
sede
Pazienti ASL
Anagrafic Cognome
data nascita
note codice sanitario a citta nascita
Operatori sede
codice fisc.
amministratori segretari terapisti Medici
209
Analisi: registrare le
prestazioni erogate
Un piano è un atto con cui l’ASL autorizza un paziente a effettuare un
certo numero di terapie presso il centro
paziente
numero di sedute autorizzate, tipologia della prestazione
medico autore della richiesta
stato del piano (previsto, scritto dal medico, autorizzato,…)
….
Una seduta è una prestazione erogata dall’associazione
 piano cui la seduta si riferisce
medico/terapista che la eroga
orario di inizio e di fine
stato della seduta (prenotata, erogata, paziente assente, operatore
assente, contabilizzata ….)
210
Schema concettuale: piani
e sedute
Dati aut. ASL. terapis
tipo trattamento medici ti
stato
(0,N)
numero sedute (0,N) (0,N)
diagnosi Piani (1,1)
stesura
codice sanitario
sede
visita
(0,N)
terapia
(1,1)
(1,1)
ora inizio
(1,1) ora fine
afferenza Sedute data
tipo seduta
stato
211
Schema concettuale:
riassunto
Anagrafica Anagrafica
Pazienti Operatori
(0,N)
autorizzazione
amministrat
medici segretari terapisti
ori
(0,N) (0,N)
(0,N)
(1,1)
(1,1) terapia
Piani stesura visita
(0,N)
(1,1) (1,1)
(1,1)
afferenza
Sedute
212
La tabella operatori
Create table operatori (
id int not null primary key, Numero
cognome varchar (30) not null , crescente
nome varchar (30) not null ,
data_nas smalldatetime,
cit_nas varchar (30), Codici delle
pro_nas char (2), tre sedi
sede char (1) check(sede in (‘A’,’B’,’C’)),,
ruolo char (1) check(ruolo in (‘A’,’B’,’C’,’D’)),
ind_res varchar (50),
Codici dei
cit_res varchar (30),
ruoli
. . . .)
Realizza le
sottoclassi
213
La tabella pazienti
Create table pazienti ( Numero
id int not null primary key, crescente
cognome varchar (30) not null ,
nome varchar (30) not null ,
data_nas date,
cod_san char (12),
Codici delle
cod_fis char (16),
invalidita char (4),
deceduto bit, tre sedi
nota varchar (1000),
sede char (1) check(sede in (‘A’,’B’,’C’)),
.....
)
214
La tabella piani
Create table piani (
id int not null primary key, Riferimento
paziente int not null references pazienti(id), ai pazienti
operatore int refences operatori(id) ,
data_cre smalldatetime,
Riferimento
stato char (1) check(stato in (‘A’,’B’,’C’,’D’,’E’)),
num_sed int,
agli operatori
num_imp char (10),
usl char (5),
cod_usl char (5),
cod_san char (12),
....
)
215
La tabella sedute
Create table sedute (
id int not null,
Riferimento
piano int not null references piani(id),
ai piani
operatore int not null refernces operatori(id),
dalle datetime not null , Riferimento
alle datetime not null , ai medici o
stato char (1) check(stato in (‘A’,’B’,’C’,’D’,...)), terapisti
tipo char (1) check(stato in (‘A’,’B’,’C’,’D’,...)),
data datetime
.....
)
216
Pratica di programmazione:
i codici
Stato di un piano, di una seduta, trattamenti erogabili, … sono oggetti che
devono essere codificati
 Si introduce un’entità astratta codici a cui tutti questi oggetti
appartengono
 L’entità è realizzata con una tabella e gli oggetti con viste
 Così quando si vuol modificare un codice si sa dove trovarlo
Codici
Stati Tipi :::

Stati piani Sedi
sedute terapie
217
La tabella codici
Create table codici ( Indica la
tipo char (1) not null , sottoentità
codice char (1) not null ,
descrizione varchar (60) not null)
Una vista
create view stati_piani as per ogni
select codice, descrizione as stato sottoentità
from codici
where (tipo = 'S')
create view tipi_prestazioni as

select codice, descrizione as prestazione
from codici
where (tipo = ’p')
218
Estrarre la lista dei piani e
dei pazienti
La seguente vista mostra i dati dei piani e dei pazienti, includendo anche i
pazienti che non hanno piani
Create view lista_piani as

select pazienti.cognome+’ ‘+pazienti.nome as paziente,
operatori.cognome+’ ‘+operatori.nome as medico,
num_sed as numero_sedute,
stati_piani.stato, Concatenazione
tipi_prestazioni.prestazione,
piani.id as piano
from pazienti left join piani on pazienti.id = piani.paziente
left join operatori on operatori.id=piani.id
left join stati_piani on stati_piani.codice=piani.stato
left join tipi_prestazioni
on tipi_prestazioni.codice=piani.prestazione
219
Analisi: informazioni da
estrarre
Per semplificare le interrogazioni si creano viste in modo che
 le interrogazioni dei client siano semplici, quasi tutte del tipo
SELECT attr1, attr2, …. FROM vista
 le viste racchiudono il codice comune delle interrogazioni più
frequenti
 le viste realizzano le interrogazioni più complesse
Alcune viste essenziali

 lista dei piani con nome paziente, nome medico, tipo prestazione
 lista dei piani con contabilità delle visite erogate, rinviante, prenotate, …
 orario del lavoro per ogni terapista/medico
220
Contare le sedute:
la funzione CASE
Una vista su sedute che trasforma lo stato in un attributo:
permette di contare le sedute secondo criteri diversi
CREATE VIEW sedute_espanse AS
SELECT id, data, piano, operatore,
CASE WHEN stato='A' THEN 1 ELSE 0 END AS Prenotata,
CASE WHEN stato=’B' THEN 1 ELSE 0 END AS Rinviata,
CASE WHEN stato=’C' THEN 1 ELSE 0 END AS Erogata,
CASE WHEN stato=’C' THEN 1 ELSE 0 END AS Erogata
FROM orario_ambulatoriale
id data piano prenotata rinviata erogata Contabil.

1 2/2/01 121 0 1 0 0
2 3/2/01 121 1 0 0 0
3 2/2/01 2332 0 1 0 0
4 3/2/01 3224 0 0 0 1
221
Contare le sedute:
raggruppare per piano
Usando la vista sedute_espanse è ora possibile contare le visite di ogni
piano
Create view sedute_x_piano as

select sum(prenotata) as prenotate,
sum(erogata) as erogate,
sum(rinviata) as rinviate,
piani.num_sed -sum(erogata)- sum(prenotata) as rimanenti,
min(data) as prima, max(data) as ultima,
piani.id as piano
Numero
from sedute_espanse right join piani sedute
on sedute_espanse.piano = piani.id
rimanenti fra
group by piani.id, piani.num_sed
quelle
previste dal
piano 222
Contare le sedute:
piano prenotate
il risultato
rinviate erogate rimanenti prima ultima
121 3 1 null 12 2/1/01 15/1/01
2332 2 1 10 21 4/1/01 7/5/01
3224 null null 4 6 14/1/01 14/4/01
I campi nulli sono presenti quando un piano non ha sedute di un certo tipo
Per trasformare i campi nulli si poteva usare la funzione coalesce
coalesce(expr1,expr2)
E’ equivalente a
case when expr1 is not null then expr1 else expr2 end
223
Estrarre la lista delle
sedute
Una vista che mostra le sedute, i nomi dei pazienti, i nomi degli operatori, il
numero delle sedute rimanenti
Create view lista_sedute as

select lista_piani.paziente,
sedute.data, sedute.dalle, sedute.alle,
operatori.cognome+operatori.nome as operatore,
sedute_X_piano.rimanenti
from sedute inner join lista_piani

on lista_piani.id = sedute.piano
inner join operatori on operatori.id=sedute.operatore
inner join sedute_X_piano on sedute_X_piano.piano=sedute.piano
224
Estrarre la lista delle
sedute
paziente data dalle alle operatore rimanenti
Rossi paolo 2/2/01 8:30 9:00 trapattoni 10
Paperino paolino 3/2/01 12:00 13:00 disney 1
Benigni roberto 2/2/01 14:00 16:00 pinocchio 0
La vista lista_sedute calcola il numero delle sedute per ogni piano tutte le
volte che viene acceduta
 computazionalmente costoso
 permette di usare dei dati normalizzati evitando la duplicazione

dell’informazione
 si è scelta questa soluzione perché in pratica con decine di migliaia di
sedute le prestazioni sono ancora accettabili
225
L’attributo id e i trigger
Nelle maggior parte delle tabelle è presente un attributo id, che deve identificare
univocamente le righe
 evitare di generare id uguali lavorando in sedi diverse
 incrementare automaticamente id con i trigger

(si adotta questa soluzione solo se il DBMS non mette a disposizione
strumenti ad hoc)
I trigger sono comandi che possono venire attivati in seguito ad un

inserimento, una modifica o una rimozione
 facilitano la manutenzione del DBMS
 permettono di automatizzare alcuni processi
226
L’attributo id e i trigger II
Una possibile soluzione
 ogni sede ha a disposizione una sequenza di indici: ad esempio 1, 11, 21,
31, 41 ...
 un trigger si attiva ad ogni inserimento, legge in una tabella la sequenza
assegnata e inserisce il prossimo indice disponibile
Quando si
Create trigger mytrigger
attiva il
after insert on pazienti
update pazienti
trigger
set id=(select max(id)+10 from prova azion
where id%10=(select sequenza from servers
e
where name= “current server”) )
where id is null
227
Tenere traccia di chi fa
cosa
Memorizzare le modifiche fatte ai dati
 attraverso il log del DBMS (troppo complicato)
 usando dei trigger
Inserire in una tabella i pazienti cancellati

Una tabella
Create trigger mytrigger con
after delete on pazienti tutte le righe
referencing new_table as righeNuove
nuove
insert into pazientiCancellati(nome,cognome,data,utente)
select nome, cognome,”current time”, user
from righeNuove
228
L’attributo “ultima
modifica”
Le tabelle new_table, old_table
 contengono le righe prima della modifica e dopo la modifica
 sono in sola lettura
 per modificare le righe già modificate deve esistere una chiave
 MS SQL server permette il vincolo identity con cui si genera
automaticamente gli identificatori
Create table pazienti( Genera automaticamente
id int identity(1,10), . . .) id a partire da 1, a passi
create trigger mytrigger on pazienti for update as
di 10
update pazienti set data_modifica=getdate(),
utente_modifica=user_name()
where id in (select id from inserted) In MS SQL server,
inserted=new_tabl
e 229
Gestione dei dati
distribuiti
Cosa succede se i dati sono distribuiti su più server ?
 Server collegati da una rete
 I DMBS più sofisticati forniscono strumenti che gestiscono le

transazioni distribuite in modo (più o meno) trasparente
 Server connessi da rete commutata (o lenta)

 I dati sono copiati ad intervalli regolari con un meccanismo detto
replicazione
 Si deve evitare che la base di dati divenga inconsistente
 Una soluzione è assegnare il possesso di un record ad una
sede e permettere la modifica solo a quest’ultima
230
Gestione dei dati

distribuiti II
La sede che possiede il record è indicata da un attributo presente
ogni tabella
 Un trigger assicura che il vincolo sia rispettato
 Per poter cambiare il proprietario di un record, il vincolo non si applica per
utenti con diritti speciali
Create table pazienti( Esiste una riga

... modificata
server_owner varchar(10) default “current server” ) che non è di questo
create trigger mytrigger on pazienti for update, insert as
server ?
if (user <> ‘supervisore’ and
exists(select * from deleted
where deleted.server_owner<>server) )
begin rollback end Si eliminano le
modifiche 231
Fin du cours bases de
données relationnelles
A suivre…..
232

coursSGBD 2012-2013

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

coursSGBD 2012-2013

Transféré par

Droits d'auteur :

Formats disponibles

École Nationale des Sciences Année Universitaire 2012/2013

Le Système d’Information d’Entreprise

 Ensemble de procédures et d'infrastructures

 Communément, basé sur une infrastructure

Système d'information de l'entreprise:

Définit des procédures qui permettent

 Ensemble de données qualitatives et quantitatives

 La structure du système d'information définit et limite

 L'évolution doit être en harmonie, en développant au

 TRANSMET les données vers l’extérieur et

S/SYSTEME OPERANT Il assure la production des biens

S/SYSTEME DE PILOTAGE = Direction

Commande Client Marchandise + Bon de livraison

Utilisateurs Rôle du Système d ’information

Cadres supérieurs S/S Production d’informations à la demande

Exécutants et Enregistrement des transactions

S/Système Décisions programmables (obtenues grâce au S/S d’information )

S/Système Tâches de gestion manuelles

S/Système Intervention de l’homme

Le Système informatique représente l’ensemble du matériel et du logiciel informatiques

Plan - Etude d’opportunité : Le Projet répond-il aux objectifs du Système de Décision ?

Plan - Déterminer les besoins en équipement matériel et logiciel

Plan - Spécification détaillée du Projet

Conception - Etude Conceptuelle ( Fonctionnelle )

Schéma Directeur de Projet = Plan Startégique + Plan Tactique + Plan d’Action )

Fonction Niveau Niveau Administratif Niveau Opérationnel

Commander Réceptionner Délivrer Mettre à jour

On retiendra les domaines suivants : Contrôler Mettre à jour

DOMAINE Informations utilisées Informations créées

Commander les pièces Catalogue fournisseurs Bon de commande

Comité d’analyse = Gestionnaires

 Identifier les fonctions et domaines de gestion du S.I

Portefeuille des projets à réaliser

Etude d ’opportunité des projets

 Ressources humaines et matérielle

Cahier des charges informatique 18

Le projet entre dans un cycle de vie permanent à son démarrage

Etude But : Produiredesdocum entsdeconception( grapheset

Conceptuelle diagramm esdem odélisation desdonnéeset traitements)

But : Affiner l’étudeconceptuelleenprécisant :

But : Traduirelesm odèleslogiquesensolutioninform atique:

But : A daptationdumatérielet dulogiciel informatique

Système de gestion de base de

1- bases de données, banques de données et fichiers de donnees

Exemple d’une banque de données:

On appelle conception d’une bases de données la phase d’analyse

Avec le modèle conceptuel il n’est pas possible de décrire

On appelle modèle logique (MLD) ou modèle machinale

1- Schéma logique ( SL)

2-schéma externe (SE)

Inscription: fichier Finscrits,

Approche classique (gestion de fichiers) et approche base

Un système d’information organisé autour d’une base de

Exemple: chaîne de traitements: commande, facturation,

Particularisation de la saisie en fonction des fichiers ( un

Propriétés d’un SGBD:

L’interface d’accès physique permet au SGBD d’accéder aux données

Le lien entre ces deux interfaces doit répondre à un objectif

 Couche externe appelée Niveau externe : prend en charge le

Association 1-1: cas particulier de l’association 1-N.

Association plusieurs à plusieurs ( N-M) entre deux types

Exemple: association N-M entre le type d’entités Fournisseur

E-A, abréviation du terme entité-Assoiciation (terminologie

,N ,N Identifiant Bo

Identifiant Ao ,1 ,N Identifiant Bo