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 Utilisateur Fichier Utilisateur Saisie Utilisateur Traitement tat de sortie Traitement Fichier

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 + Contrles Utilisateur Base de Donnes Traitements tats de sortie

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 Langage de Mise jour des donnes Manipulation de Donnes (LMD) Transformation des donnes 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 de la BD Schma conceptuel Schma logique Schma interne
13

Indpendant d'un SGBD

Analyse

Conception

Spcifique un SGBD

Transformation en modle logique

Conception physique
Bases de donnes 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/ 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 (ex. CLIENT) Attribut : proprit de lentit (ex. Nom et Prnom du client)
Attribut simple : non divisible (ex. Nom)
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/ 16

CLIENT

Nom

Prnom

II.2. Entits et attributs


Rue

Attribut compos : subdivis en attributs simples (ex. Adresse)

Code Postal Adresse Ville Pays

Attribut driv : dont la valeur est calcule (ex. ge daprs la date de naissance)
Bases de donnes http://eric.univ-lyon2.fr/~jdarmont/

ge

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


Nom Prnom Date de 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 Dupont West Martin Durand Titgoutte Dupont Dupont Prnom Albert James Marie Gaston Justine Nomie Albert Date de Naissance 01/06/70 03/09/63 05/06/78 15/11/80 28/02/75 18/09/57 23/05/33 Etc. ... ... ... ... ... ... ...

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 1 2 3 4 5 6 7
Bases de donnes

Nom Dupont West Martin Durand Titgoutte Dupont Dupont

Prnom Albert James Marie Gaston Justine Nomie Albert

Date de Naissance 01/06/70 03/09/63 05/06/78 05/11/80 28/02/75 18/09/57 23/05/33


23

http://eric.univ-lyon2.fr/~jdarmont/

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
Bases de donnes

Quantit
30

http://eric.univ-lyon2.fr/~jdarmont/

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 Prnom CLIENT DateNaiss
1,1 1,N COMMANDE 1,N

NumCli

Date

Quantit

NumProd

Dsi PrixUni

PRODUIT

Rue CP

Ville FOURNIT
1,N

NumFour RaisonSoc

FOURNISSEUR

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
http://eric.univ-lyon2.fr/~jdarmont/ 36

Bases de donnes

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
http://eric.univ-lyon2.fr/~jdarmont/ 39

Bases de donnes

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 101 104 112 103 Quantit 300 1000 78 250 NumFour 901 902 904 901 Adresse Quai des brumes Quai Claude Bernard Quai des Marans 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 T catalogues de deux socits. 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 T existant dans la relation R. 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. Notation graphique :
R
Bases de donnes

T x S
61

http://eric.univ-lyon2.fr/~jdarmont/

III.7. Algbre relationnelle


ex.
NumProd 0 1 Dsi P1 P2

X
Dsi P1 P2 P1 P2 P1 P2

NumFour 10 20 30 NumFour 10 10 20 20 30 30

RaisonSoc F1 F2 F3 RaisonSoc F1 F1 F2 F2 F3 F3
62

NumProd 0 1 0 1 0 1

Bases de donnes

http://eric.univ-lyon2.fr/~jdarmont/

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. T ex. C = Clients qui habitent Lyon. 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
Bases de donnes

S
65

http://eric.univ-lyon2.fr/~jdarmont/

III.7. Algbre relationnelle


ex. Commandes avec le nom du client et pas seulement son numro
Nom, Date, Quantite NumCli = CLIENT COMMANDE NumCli

NB : Requte = enchanement doprations


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

III.7. Algbre relationnelle


Dcomposition des oprations
CL NumCli 1 2 3 Nom C1 C2 C3 CO

NumCli 1 3 3

Date Quantit 22/09/99 1 22/09/99 5 22/09/99 2

Bases de donnes

http://eric.univ-lyon2.fr/~jdarmont/

67

III.7. Algbre relationnelle


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

Bases de donnes

http://eric.univ-lyon2.fr/~jdarmont/

III.7. Algbre relationnelle


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

Date Quantit 22/09/99 1 22/09/99 5 22/09/99 2

<Nom, Date, Quantit> (CL >< CO) (Projection sur les attributs Nom, Date, Quantit)
69

Bases de donnes

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/ 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 contient le mot sur %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 1 3 3 Date Quantite 22/09/99 1 22/09/99 5 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