Vous êtes sur la page 1sur 46

Facult de Sciences conomiques et de Gestion

Bases de donnes
Matrise de Sciences conomiques
Anne 2001-2002
Jrme Darmont
http://eric.univ-lyon2.fr/~jdarmont/

Plan du cours

I. Introduction
II. Le modle E/A
III. Le modle relationnel
IV. Le langage SQL

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 1


Plan du cours

! I. Introduction
II. Le modle E/A
III. Le modle relationnel
IV. Le langage SQL

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 2

I.1. Limites des systmes fichiers

Saisie Traitement Fichier

Utilisateur

Fichier

Utilisateur

Saisie Traitement tat de sortie

Utilisateur
Organisation en fichiers
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 3
I.1. Limites des systmes fichiers
Particularisation de la saisie et des traitements
en fonction des fichiers un ou plusieurs
programmes par fichier
Contrle en diffr des donnes
augmentation des dlais et du risque derreur
Particularisation des fichiers en fonction des
traitements grande redondance des donnes
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 4

I.2. Organisation base de donnes

Utilisateur
Saisie
Base de tats de sortie
+ Traitements
Donnes
Contrles
Utilisateur

Utilisateur
Organisation base de donnes
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 5
I.2. Organisation base de donnes

Uniformisation de la saisie et standardisation


des traitements (ex. tous les rsultats de
consultation sous forme de listes et de tableaux)
Contrle immdiat de la validit des donnes
Partage de donnes entre plusieurs traitements
limitation de la redondance des donnes

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 6

I.3. Dfinitions

Base de donnes (BD) : Collection de donnes


cohrentes et structures
Systme de Gestion de Bases de Donnes
(SGBD) : Logiciel(s) assurant structuration,
stockage, maintenance, mise jour et
consultation des donnes dune BD

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 7


I.4. Objectifs des SGBD
Indpendance physique : un remaniement de
lorganisation physique des donnes nentrane
pas de modification dans les programmes
dapplication (traitements)
Indpendance logique : un remaniement de
lorganisation logique des fichiers (ex. nouvelle
rubrique) nentrane pas de modification dans
les programmes dapplication non concerns
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 8

I.4. Objectifs des SGBD


Manipulation facile des donnes : un
utilisateur non-informaticien doit pouvoir
manipuler simplement les donnes
(interrogation et mise jour)
Administration facile des donnes : un SGBD
doit fournir des outils pour dcrire les donnes,
permettre le suivi de ces structures et autoriser
leur volution (tche de ladministrateur de BD)
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 9
I.4. Objectifs des SGBD
Efficacit des accs aux donnes : garantie
dun bon dbit (nombre de transactions
excutes par seconde) et dun bon temps de
rponse (temps dattente moyen pour une
transaction)
Redondance contrle des donnes :
diminution du volume de stockage, pas de mise
jour multiple ni dincohrence
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 10

I.4. Objectifs des SGBD


Cohrence des donnes : ex. Lge dune
personne doit tre un nombre entier positif. Le
SGBD doit veiller ce que les applications
respectent cette rgle (contrainte dintgrit).
Partage des donnes : utilisation simultane
des donnes par diffrentes applications
Scurit des donnes : les donnes doivent tre
protges contre les accs non-autoriss ou en
cas de panne
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 11
I.5. Fonctions des SGBD
Description des donnes : Langage de
Dfinition de Donnes (LDD)
Recherche des donnes
Mise jour des donnes
Transformation des donnes
Langage de
Manipulation de
Donnes (LMD)
}
Contrle de lintgrit des donnes
Gestion de transactions et scurit
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 12

I.6. Processus de conception dune base de donnes

Monde rel

Spcifications Indpendant d'un


de la BD SGBD
Analyse

Schma
conceptuel Spcifique un
Conception
SGBD
Schma
logique
Transformation en
modle logique
Schma
Conception interne
physique
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 13
Plan du cours

I. Introduction
! II. Le modle E/A
III. Le modle relationnel
IV. Le langage SQL

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 14

II.1. Gnralits

E/A signifie Entit-Association, traduction de


E/R (Entity-Relationship).
Le modle E/A est un modle conceptuel conu
dans les annes 1970.
Il utilise une reprsentation graphique.

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 15


II.2. Entits et attributs
Entit : objet de
lunivers du discours CLIENT
(ex. CLIENT)
Attribut : proprit de
lentit (ex. Nom et Nom Prnom
Prnom du client)
Attribut simple : non
divisible (ex. Nom)

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 16

II.2. Entits et attributs


Rue
Attribut compos :
Code Postal
subdivis en attributs
Adresse
simples (ex. Adresse) Ville

Pays

Attribut driv : dont la


valeur est calcule (ex. ge
ge daprs la date de
naissance)
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 17
II.2. Entits et attributs
Valeur nulle (NULL) pour un attribut : la valeur
nest pas connue
ex. Un client dont on ne connat pas la date de
naissance.
Domaine : ensemble des valeurs que peut
prendre un attribut
ex. Prix des produit de 1 10.000 F

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 18

II.2. Entits et attributs

Date de
Nom Prnom
naissance

CLIENT ge

Rue Code postal Ville

Exemple dentit avec ses attributs

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 19


II.3. Types et occurrences
Type dentit : ex. CLIENT
Occurrences du type CLIENT : les clients
Albert Dupont
James West
Marie Martin
Gaston Durand
...
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 20

II.3. Types et occurrences


Type dattribut
Nom et Prnom sont des chanes de caractres
Date de naissance est une date
ge est un nombre entier

Occurrences dattribut : valeur particulire


dun attribut
ex. Bleu, Rouge sont des occurrences dun
attribut Couleur.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 21
II.4. Identifiants
Liste des clients
Nom Prnom Date de Naissance Etc.
Dupont Albert 01/06/70 ...
West James 03/09/63 ...
Martin Marie 05/06/78 ...
Durand Gaston 15/11/80 ...
Titgoutte Justine 28/02/75 ...
Dupont Nomie 18/09/57 ...
Dupont Albert 23/05/33 ...

Problme : Comment distinguer les Dupont ?


Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 22

II.4. Identifiants
Solution : Ajouter un attribut Numro de client
Numro Nom Prnom Date de Naissance
1 Dupont Albert 01/06/70
2 West James 03/09/63
3 Martin Marie 05/06/78
4 Durand Gaston 05/11/80
5 Titgoutte Justine 28/02/75
6 Dupont Nomie 18/09/57
7 Dupont Albert 23/05/33

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 23


II.4. Identifiants

Le numro de client est un identifiant. Un


identifiant caractrise de faon unique les
occurrences dun type dentit.

Notation graphique : CLIENT Numro

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 24

II.4. Associations et cardinalits


Association : liaison perue entre des entits
ex. Les clients commandent des produits.

CLIENT COMMANDE PRODUIT

Les entits CLIENT et PRODUIT sont dites


participantes la relation COMMANDE.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 25
II.4. Associations et cardinalits
Association 1-1
ex. Un client donn ne commande quun seul
produit. Un produit donn nest command que
par un seul client.
CLIENT 1,1 COMMANDE 1,1 PRODUIT

X,Y - X : cardinalit mini - Y : cardinalit maxi


Lire : Un client commande X Y produits.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 26

II.4. Associations et cardinalits


Association 1-N
ex. Un client donn commande plusieurs produits.
Un produit donn nest command que par un
seul client.
CLIENT 1,N COMMANDE 1,1 PRODUIT

La cardinalit un plusieurs (1-N) peut aussi


tre zro plusieurs (0-N).
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 27
II.4. Associations et cardinalits
Association 0 ou 1-N
ex. Un client donn commande plusieurs produits.
Un produit donn est command au maximum par
un client, mais peut ne pas tre command.
CLIENT 1,N COMMANDE 0,1 PRODUIT

La cardinalit un plusieurs (1-N) peut aussi tre


zro plusieurs (0-N).
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 28

II.4. Associations et cardinalits


Association M-N
ex. Un client donn commande plusieurs produits.
Un produit donn est command par plusieurs
clients.
CLIENT 1,N COMMANDE 1,N PRODUIT

Les cardinalits un plusieurs (1-N) peuvent aussi


tre zro plusieurs (0-N).
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 29
II.4. Associations et cardinalits
Attribut dassociation : Dans une association
M-N, il est possible de caractriser lassociation
par des attributs.
ex. Une commande est passe une Date donne
et concerne une Quantit de produit fixe.
CLIENT 1,N COMMANDE 1,N PRODUIT

Date Quantit

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 30

II.5. Exemple VPC complet

Spcifications
Les clients sont caractriss par un numro de
client, leur nom, prnom, date de naissance, rue,
code postal et ville.
Ils commandent des produits une date donne
et dans une quantit donne.

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 31


II.5. Exemple VPC complet
Spcifications (suite)
Les produits sont caractriss par un numro de
produit, leur dsignation et leur prix unitaire.
Chaque produit est fourni par un fournisseur
unique (mais un fournisseur peut fournir
plusieurs produits).
Les fournisseurs sont caractriss par un
numro de fournisseur et leur raison sociale.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 32

II.5. Exemple VPC complet

Marche suivre pour produire un schma E/A


1) Identifier les entits.
2) Identifier les associations entre les entits.
3) Identifier les attributs de chaque entit et de
chaque association.
4) Evaluer les cardinalits des associations.

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 33


II.5. Exemple VPC complet
Nom NumCli Date Quantit NumProd
Dsi
Prnom
CLIENT 1,N COMMANDE 1,N PRODUIT PrixUni
DateNaiss
1,1
Rue Ville
FOURNIT
CP
1,N
NumFour
FOUR-
NISSEUR
RaisonSoc

Schma E/A de lexemple VPC


Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 34

Plan du cours

I. Introduction
II. Le modle E/A
! III. Le modle relationnel
IV. Le langage SQL

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 35


III.1. Gnralits
Le modle relationnel est un modle logique
associ aux SGBD relationnels (ex. Oracle,
DB2, SQLServer, Access, Paradox, dBase).
Objectifs du modle relationnel :
indpendance physique
traitement du problme de redondance des donnes
LMD non procduraux (faciles utiliser)
devenir un standard
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 36

III.2. Relations, attributs et tuples


Une relation R est un ensemble dattributs
{A1, A2, , An}.
ex. La relation PRODUIT est lensemble des
attributs {NumProd, Dsi, PrixUni}
Chaque attribut Ai prend ses valeurs dans un
domaine dom(Ai).
ex. PrixUni ]0, 10.000]

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 37


III.2. Relations, attributs et tuples
Un tuple t est un ensemble de valeurs
t = <V1, V2, , Vn> o Vi dom(Ai) ou Vi est
la valeur nulle (NULL).
ex. <112, Raquette de tennis, 300> est un
tuple de la relation PRODUIT.
Notation : R (A1, A2, , An)
ex. PRODUIT (NumProd, Dsi, PrixUni)

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 38

III.3. Contraintes dintgrit


Cl primaire : Ensemble dattributs dont les
valeurs permettent de distinguer les tuples les
uns des autres (identifiant).
ex. NumProd cl primaire de la relation PRODUIT
Cl trangre : Attribut qui est cl primaire
dune autre relation.
ex. Connatre le fournisseur de chaque produit
ajout de lattribut NumFour la relation PRODUIT
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 39
III.3. Contraintes dintgrit

Notations : cls primaires soulignes, cls


trangres en italiques
ex. PRODUIT (NumProd, Dsi, PrixUni, NumFour)

Contraintes de domaine : les attributs doivent


respecter une condition logique
ex. PrixUni > 0 ET PrixUni 10000

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 40

III.4. Traduction E/A-Relationnel


1) Chaque entit devient une relation. Les
attributs de lentit deviennent attributs de la
relation. Seuls les attributs simples des attributs
composs sont inclus. Lidentifiant de lentit
devient cl primaire de la relation.

ex. CLIENT (NumCli, Nom, Prnom, DateNaiss,


Rue, CP, Ville)
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 41
III.4. Traduction E/A-Relationnel

2) Chaque association 1-1 est prise en compte en


incluant la cl primaire dune des relations
comme cl trangre dans lautre relation.
ex. Si un client peut possder un compte, on aura :
COMPTE (NumCom, Solde)
CLIENT (NumCli, Nom, Prnom, DateNaiss,
Rue, CP, Ville, NumCom)
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 42

III.4. Traduction E/A-Relationnel


3) Chaque association 1-N est prise en compte en
incluant la cl primaire de la relation dont la
cardinalit maximale est N comme cl trangre
dans lautre relation.
ex.
PRODUIT (NumProd, Dsi, PrixUni, NumFour)
FOURNISSEUR (NumFour, RaisonSoc)

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 43


III.4. Traduction E/A-Relationnel
4) Chaque association M-N est prise en compte en
crant une nouvelle relation dont la cl primaire et
la concatnation des cls primaires des relations
participantes. Les attributs de lassociation sont
insrs dans cette nouvelle relation.

ex. COMMANDE (NumCli, NumProd, Date,


Quantit)
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 44

III.4. Traduction E/A-Relationnel

Schma relationnel complet de lexemple VPC

CLIENT (NumCli, Nom, Prnom, DateNaiss, Rue, CP, Ville)


PRODUIT (NumProd, Dsi, PrixUni, NumFour)
FOURNISSEUR (NumFour, RaisonSoc)

COMMANDE (NumCli, NumProd, Date, Quantit)

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 45


III.5. Problme de la redondance
[En dehors des cls trangres]
ex. Soit la relation COMMANDE_PRODUIT.
NumProd Quantit NumFour Adresse
101 300 901 Quai des brumes
104 1000 902 Quai Claude Bernard
112 78 904 Quai des Marans
103 250 901 Quai des brumes

Cette relation prsente diffrentes anomalies.


Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 46

III.5. Problme de la redondance


Anomalies de modification : Si lon souhaite
mettre jour ladresse dun fournisseur, il faut
le faire pour tous les tuples concerns.
Anomalies dinsertion : Pour ajouter un
fournisseur nouveau, il faut obligatoirement
fournir des valeurs pour NumProd et Quantit.
Anomalies de suppression : ex. La suppression
du produit 104 fait perdre toutes les
informations concernant le fournisseur 902.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 47
III.6. Normalisation

Objectifs de la normalisation :

Suppression des problmes de mise jour


Minimisation de lespace de stockage
(limination des redondances)

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 48

III.6. Normalisation
Les dpendances fonctionnelles (DF)
Soit R (X, Y, Z) une relation o X, Y, et Z sont
des ensembles dattributs. Z peut tre vide.
Dfinition : Y dpend fonctionnellement de X
(X Y) si cest toujours la mme valeur de Y
qui est associe X dans la relation R.
ex. PRODUIT (NumProd, Dsi, PrixUni)
NumProd Dsi, Dsi PrixUni
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 49
III.6. Normalisation

Proprits des dpendances fonctionnelles


Rflexivit : Si Y X alors X Y.
Augmentation : Si W Z et X Y alors
X, Z Y, W.
Transitivit : Si X Y et Y Z alors X Z.
(Rgles dinfrence dArmstrong)

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 50

III.6. Normalisation
Proprits des dpendances fonctionnelles
Pseudo-transitivit : Si X Y et Y, Z T
alors X, Z T.
Union : Si X Y et X Z alors X Y, Z.
Dcomposition : Si Z Y et X Y alors
X Z.
NB : La notation X, Y signifie X Y.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 51
III.6. Normalisation
Premire forme normale (1FN)
Une relation est en 1FN si tout attribut nest pas
dcomposable.
ex. Les relations PERSONNE (Nom, Prnoms,
Age) et DEPARTEMENT (Nom, Adresse, Tel)
ne sont pas en 1FN si les attributs Prnoms et
Adresse peuvent tre du type [Jean, Paul] ou [Rue
de Marseille, Lyon].
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 52

III.6. Normalisation
Deuxime forme normale (2FN)
Une relation est en 2FN si :
- elle est en 1FN ;
- tout attribut non cl primaire est dpendant de
la cl primaire entire.

ex. La relation CLIENT (NumCli, Nom, Prnom,


DateNaiss, Rue, CP, Ville) est en 2FN.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 53
III.6. Normalisation
Deuxime forme normale (2FN)
ex. La relation COMMANDE_PRODUIT
(NumProd, Quantit, NumFour, Ville) nest pas
en 2FN car on a NumProd, NumFour Quantit
et NumFour Ville.
La dcomposition suivante donne deux relations
en 2FN : COMMANDE (NumProd, NumFour,
Quantit) ; FOURNISSEUR (NumFour, Ville).
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 54

III.6. Normalisation
Troisime forme normale (3FN)
Une relation est en 3FN si :
- elle est en 2FN ;
- il nexiste aucune DF entre deux attributs non
cl primaire.
ex. La relation COMPAGNIE (Vol, Avion,
Pilote) avec les DF Vol Avion, Avion Pilote
et Vol Pilote est en 2FN, mais pas en 3FN.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 55
III.6. Normalisation
Troisime forme normale (3FN)
Anomalies de mise jour sur la relation
COMPAGNIE : il nest pas possible dintroduire
un nouvel avion sur un nouveau vol sans prciser
le pilote correspondant.
La dcomposition suivante donne deux relations
en 3FN qui permettent de retrouver (par
transitivit) toutes les DF : R1 (Vol, Avion) ;
R2 (Avion, Pilote).
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 56

III.7. Algbre relationnelle


Ensemble doprateurs qui sappliquent aux
relations
Rsultat : nouvelle relation qui peut son tour
tre manipule

Lalgbre relationnelle permet deffectuer des


recherches dans les relations.

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 57


III.7. Algbre relationnelle
Oprateurs ensemblistes
Union : T = R S ou T = UNION (R, S)
R et S doivent avoir mme schma.
ex. R et S sont les relations PRODUIT de deux
socits qui fusionnent et veulent unifier leur
catalogue. T

Notation graphique :
R S
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 58

III.7. Algbre relationnelle


Oprateurs ensemblistes
Intersection : T = R S ou
T = INTERSECT (R, S)
R et S doivent avoir mme schma.
ex. Permet de trouver les produits communs aux
catalogues de deux socits. T

Notation graphique : R S

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 59


III.7. Algbre relationnelle

Oprateurs ensemblistes
Diffrence : T = R - S ou T = MINUS (R, S)
R et S doivent avoir mme schma.
ex. Permet de retirer les produits de la relation S
existant dans la relation R. T

Notation graphique : R S

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 60

III.7. Algbre relationnelle

Oprateurs ensemblistes
Produit cartsien : T = R x S
ou T = PRODUCT (R, S)
Associe chaque tuple de R chaque tuple de S.
T
Notation graphique : x
R S

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 61


III.7. Algbre relationnelle
NumProd Dsi NumFour RaisonSoc
ex. 0 P1 X 10 F1
1 P2 20 F2
30 F3
NumProd Dsi NumFour RaisonSoc
0 P1 10 F1
1 P2 10 F1
= 0 P1 20 F2
1 P2 20 F2
0 P1 30 F3
1 P2 30 F3
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 62

III.7. Algbre relationnelle


Oprateurs spcifiques
Projection : T = <A, B, C> (R)
ou T = PROJECT (R / A, B, C)
T ne contient que les attributs A, B et C de R.
ex. Noms et prnoms des clients.
T
Notation graphique : A, B, C
R

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 63


III.7. Algbre relationnelle
Oprateurs spcifiques
Restriction : T = <C> (R)
ou T = RESTRICT (R / C)
T ne contient que les attributs de R qui satisfont
la condition C.
ex. C = Clients qui habitent Lyon. T
C
Notation graphique : R

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 64

III.7. Algbre relationnelle


Oprateurs spcifiques
Jointure naturelle : T = R >< S
ou T = JOIN (R, S)
Produit cartsien R x S et restriction A = B sur
les attributs A R et B S.
T
Notation graphique : A B
=
R S

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 65


III.7. Algbre relationnelle
ex. Commandes avec le nom du client et pas
seulement son numro
Nom, Date,
Quantite

NumCli NumCli
=
CLIENT COMMANDE

NB : Requte = enchanement doprations


Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 66

III.7. Algbre relationnelle

Dcomposition des oprations

CL CO
NumCli Nom NumCli Date Quantit
1 C1 1 22/09/99 1
2 C2 X 3 22/09/99 5
3 C3 3 22/09/99 2

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 67


III.7. Algbre relationnelle
CL.NumCli Nom CO.NumCli Date Quantit
1 C1 1 22/09/99 1
2 C2 1 22/09/99 1
3 C3 1 22/09/99 1
1 C1 3 22/09/99 5
= 2 C2 3 22/09/99 5
3 C3 3 22/09/99 5
1 C1 3 22/09/99 2
2 C2 3 22/09/99 2
3 C3 3 22/09/99 2

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 68

III.7. Algbre relationnelle


CL >< CO
CL.NumCli Nom CO.NumCli Date Quantit
1 C1 1 22/09/99 1
3 C3 3 22/09/99 5
3 C3 3 22/09/99 2

Nom Date Quantit <Nom, Date, Quantit> (CL >< CO)


C1 22/09/99 1
C3 22/09/99 5 (Projection sur les attributs Nom,
C3 22/09/99 2 Date, Quantit)

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 69


Plan du cours

I. Introduction
II. Le modle E/A
III. Le modle relationnel
! IV. Le langage SQL

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 70

IV.1. Gnralits
SQL = Structured Query Language
SQL permet la dfinition, la manipulation et le
contrle dune base de donnes relationnelle. Il
se base sur lalgbre relationnelle.
SQL est un standard depuis 1986.
Nous adoptons dans ce chapitre la syntaxe de
SQL*Plus (Oracle).
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 71
IV.2. Dfinition des donnes
ex. CREATE TABLE CLIENT ( NumCli NUMBER(3),
Nom CHAR(30),
DateNaiss DATE,
Salaire NUMBER(8,2),
NumEmp NUMBER(3),
CONSTRAINT cle_pri PRIMARY KEY (NumCli),
CONSTRAINT cle_etr FOREIGN KEY (NumEmp)
REFERENCES EMPLOYEUR(NumEmp),
CONSTRAINT date_ok CHECK (DateNaiss < SYSDATE));
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 72

IV.2. Dfinition des donnes


Types de donnes
NUMBER(n) : nombre entier n chiffres
NUMBER(n, m) : nombre rel n chiffres au
total (virgule comprise) et m chiffres aprs la
virgule
CHAR(n) : chane de caractres de taille n
DATE : date au format JJ-MM-AAAA
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 73
IV.2. Dfinition des donnes
Contraintes dintgrit
Mot cl CONSTRAINT
Identification par un nom de contrainte
Cl primaire PRIMARY KEY (cl)
Cl trangre (cl) REFERENCES table(attribut)
Contrainte de domaine CHECK (condition)

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 74

IV.3. Mise jour des donnes


Ajout dun tuple
ex. INSERT INTO PRODUIT
VALUES (400, Nouveau produit, 78.90);
Mise jour dun attribut
ex. UPDATE CLIENT SET Nom=Dudule
WHERE NumCli = 3;
Suppression de tuples
ex. DELETE FROM CLIENT WHERE Ville = Lyon;
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 75
IV.4. Interrogation des donnes
Tous les tuples dune table
ex. SELECT * FROM CLIENT;
Tri du rsultat
ex. Par ordre alphabtique [inverse] de nom
SELECT * FROM CLIENT
ORDER BY Nom [DESC];
Calculs ex. Calcul de prix TTC
SELECT PrixUni+PrixUni*0.206 FROM PRODUIT;
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 76

IV.4. Interrogation des donnes

Projection
ex. Noms et Prnoms des clients, uniquement
SELECT Nom, Prenom FROM CLIENT;
Restriction
ex. Clients qui habitent Lyon
SELECT * FROM CLIENT
WHERE Ville = Lyon;
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 77
IV.4. Interrogation des donnes
ex. Commandes en quantit au moins gale 3
SELECT * FROM COMMANDE
WHERE Quantite >= 3;
ex. Produits dont le prix est compris entre 50 et 100 F
SELECT * FROM PRODUIT
WHERE PrixUni BETWEEN 50 AND 100;
ex. Commandes en quantit indtermine
SELECT * FROM Commande
WHERE Quantite IS NULL;
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 78

IV.4. Interrogation des donnes


ex. Clients habitant une ville dont le nom se
termine par sur-Sane
SELECT * FROM CLIENT
WHERE Ville LIKE %sur-Sane;
sur-Sane% commence par sur-Sane
%sur% contient le mot sur

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 79


IV.4. Interrogation des donnes
ex. Prnoms des clients dont le nom est Dupont,
Durand ou Martin
SELECT Prenom FROM CLIENT
WHERE Nom IN (Dupont, Durand, Martin);

NB : Possibilit dutiliser la ngation pour tous


ces prdicats : NOT BETWEEN, NOT NULL,
NOT LIKE, NOT IN.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 80

IV.4. Interrogation des donnes


Fonctions dagrgat
Elles oprent sur un ensemble de valeurs.
AVG() : moyenne des valeurs
SUM() : somme des valeurs
MIN(), MAX() : valeur minimum, valeur maximum
COUNT() : nombre de valeurs
ex. Moyenne des prix des produits
SELECT AVG(PrixUni) FROM PRODUIT;
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 81
IV.4. Interrogation des donnes
Oprateur DISTINCT
ex. Nombre total de commandes
SELECT COUNT(*) FROM COMMANDE;
SELECT COUNT(NumCli) FROM COMMANDE;
ex. Nombre de clients ayant pass commande
SELECT COUNT( DISTINCT NumCli)
FROM COMMANDE;
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 82

IV.4. Interrogation des donnes

Table COMMANDE (simplifie)

NumCli Date Quantite


1 22/09/99 1
3 22/09/99 5
3 22/09/99 2

COUNT(NumCli) Rsultat = 3
COUNT(DISTINCT NumCli) Rsultat = 2
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 83
IV.4. Interrogation des donnes
Jointure
ex. Liste des commandes avec le nom des clients

SELECT Nom, Date, Quantite


FROM CLIENT, COMMANDE
WHERE CLIENT.NumCli =
COMMANDE.NumCli;

Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 84

IV.4. Interrogation des donnes


ex. Idem avec le numro de client en plus
SELECT C1.NumCli, Nom, Date, Quantite
FROM CLIENT C1, COMMANDE C2
WHERE C1.NumCli = C2.NumCli
ORDER BY Nom;
NB : Utilisation dalias (C1 et C2) pour allger
lcriture + tri par nom.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 85
IV.4. Interrogation des donnes
Jointure exprime avec le prdicat IN
ex. Nom des clients qui ont command le 23/09
SELECT Nom FROM CLIENT
WHERE NumCli IN (
SELECT NumCli FROM COMMANDE
WHERE Date = 23-09-1999 );
NB : Il est possible dimbriquer des requtes.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 86

IV.4. Interrogation des donnes


Prdicats EXISTS / NOT EXISTS
ex. Clients qui ont pass au moins une commande
[nont pass aucune commande]
SELECT * FROM CLIENT C1
WHERE [NOT] EXISTS (
SELECT * FROM COMMANDE C2
WHERE C1.NumCli = C2.NumCli );
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 87
IV.4. Interrogation des donnes
Prdicats ALL / ANY
ex. Numros des clients qui ont command au
moins un produit en quantit suprieure
chacune [ au moins une] des quantits
commandes par le client n 1.
SELECT DISTINCT NumCli FROM COMMANDE
WHERE QUANTITE > ALL [ANY] (
SELECT QUANTITE FROM COMMANDE
WHERE NumCli = 1 );
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 88

IV.4. Interrogation des donnes


Groupement
ex. Quantit totale commande par chaque client
SELECT NumCli, SUM(Quantite)
FROM COMMANDE
GROUP BY NumCli;
ex. Nombre de produits diffrents commands...
SELECT NumCli, COUNT(DISTINCT NumProd)
FROM COMMANDE
GROUP BY NumCli;
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 89
IV.4. Interrogation des donnes
ex. Quantit moyenne commande pour les
produits faisant lobjet de plus de 3
commandes
SELECT NumProd, AVG(Quantite)
FROM Commande
GROUP BY NumProd
HAVING COUNT(*)>3;
Attention : La clause HAVING ne sutilise quavec
GROUP BY.
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 90