Vous êtes sur la page 1sur 41

INFORMATIQUE

MME. DOMINIQUE TACHAT

1er Cours - le 5 février

Introduction

Programme: les bases de données


Les bases données relationnelles
Le langage standard SQL: apprendre à programmer
L’algèbre relationnelle
Mysql
Les dépendances et la normalisation
Le SGBD Access
Les bases de données: modèle entités-associations

- 1er contrôle: semaine du 12 mars (Excel et langage SQL)


- 2ème contrôle: semaine du 14 mai (algèbre relationnelle, Mysql, Access, dépendances et
normalisation et modèles entités-associations)

Définition de bases de données: un ensemble de données de l’entreprise mémorisé par un


ordinateur, qui est utilisé par de nombreuses personnes et dont l’organisation est régie par un
modèle de données.

Deux types de modèles de données: a) relationnel; et b) entité-associations.

Le modèle relationnel a comme concept de base une relation, représentée sous forme de
tables. Qui dit relation, dit table. Les en-têtes sont les attributs: numproduit, nomproduit et
stock.

Numproduit Nomproduit Stock


N101 Table 25
N202 Chaise 120
N251 Table 36
N541 Lit 120

Les occurrences sont les lignes de la table, sauf la ligne des attributs. Dans l’exemple, on en a
quatre.
Chaque relation contient un attribut particulier ou un ensemble de plusieurs attributs appelé
clé, dont la valeur va permettre de distinguer une occurrence de toutes autres occurrences.
On représente symboliquement une relation par un schéma de la forme: Nom_relation (clé,
attribut1, attribut2,...). Dans le dernier exemple: produit(numproduit, nomproduit, stock).

Un système de gestion de base de donnes (SGBD) représente un logiciel (ou un ensemble


coordonné de logiciels) qui permet de décrire, mémoriser, manipuler, traiter, interroger les
ensembles de données constituant la base. Il assure la sécurité et la confidentialité des données
dans un environnement où de nombreux utilisateurs ayant des besoins variés peuvent interagir
simultanément sur ces ensembles de données.

Un SGBD permet de récupérer une base de donnée après une pane de l’ordinateur, aussi elle
permet la sécurité et la confidentialité car il gère les accès multiples aux données (le RH a
plus d’accès aux données des employés d’une entreprise que les salariés).

Dans un SGBD relationnel, les structures de données sont représentées sous forme de table (le
modèle est relationnel). Un exemple, c’est l’ACCESS. Ces SGBD proposent des langages
permettant d’accéder aux donnés de manière assez naturelle, comme le SQL.

Exemple: la base de données relationnelle Vols a 3 relations:

1) vol, qui comporte:

vol(numvol,depart,arrivee,numav,numpil,jdep,hdep,jarr,harr)

On a le numéro de vol, la ville de départ, la ville d’arrivée, le code d’avion, le code du pilote,
le jour de départ (format JJ/MM/AAAA), l’heure de départ (format XX:XX), le jour d’arrivée
et l’heure d’arrivée. Les deux soulignés sont la clé de la relation: numvol et jdep.

2) pilote, qui comporte:

pilote(numpilote,nom,prenom)

3) avion, qui comporte:

avion(numavion,type,cap)

On peut voir que numpilote et numpil sont la même chose, ainsi que pour numav et
numavion. Cap représente le nombre de passagers.

Vol:
numvol depart arrivee numav numpil jdep hdep jarr harr

Pilote:
numpilote nom prenom

Avion:
Numavion type cap

Il faut mettre en évidence les liens entre les différentes tables. Avec ces liens, on peut
connaitre donc le prénom du pilote, par exemple. On peut avoir des informations aussi sur les
avions des vols référencés dans la table vol et sur les vols effectués par les avions. En mettant
en lien les trois tables et leurs deux liens, on peut savoir le nom des pilotes de chaque avion,
par exemple.

Chapitre 1 - Le langage SQL

I. Les requêtes

Le langage SQL (Structured Query Language) est le langage le plus utilisé pour les bases de
données relationnelles. Ça va permettre de déclarer les relations, créer les occurrences,
modifier les occurrences et interroger des bases de données relationnelles.

On va formuler des requêtes. La forme générale d’une requête SQL c’est:

SELECT liste d’attributs


FROM nom des relations
WHERE conditions

Dans le from on met le nom de la table que nous intéresse, where ce sont les conditions qui
doivent respecter les résultats et select ce sont les attributs qu’on veut voir affichés dans le
résultat. Le résultat d’une requête est toujours une table, on a réalisé une projection, car la
requête ne prend qu’un sous-ensemble des attributs de la relation pilote. On va écrire toujours
dans l’ordre select, from, where, mais on commence toujours par from.

Exemple 1: recherche des noms et prénoms des pilotes.

Select p.nom,p.prenom (p. représente que le nom vient de table p, on fait ça quand deux
tables ont des attributs identiques, ce n’est pas le cas ici mais ça se passera aux TDs)
From pilote p (le p représente l’alias)

Exemple 2: recherche des attributs des pilotes de prénom Georges.

Select * (l’étoile va nous donner tous les attributs)


From pilote p
Where p.prenom=’Georges’
La requête affiche tous les attributs de la relation pilote mais ne prend que les occurrences qui
vérifient la condition p.prenom=’Georges’. La sélection porte sur le where, et la projection sur
le select.

Exemple 3: recherche des attributs des vols décollant le 15/05/99.


Select *
From vol v
Where v.jdep={d’1999-05-15’}

Sous Easy PHP, on peut exprimer la date comme: v.jdep=”1999-05-15”. Sous ACCESS, on
note: v.jdep=#1999-05-15#

On fait une sélection, car la requête affiche tous les attributs de la relation vol mais ne prend
que les occurrences qui vérifient la condition v.jdep={d’1999-05-15’}

Exemple 4: attributs croisés de tous les pilotes et de tous les vols

Select *
From vol v, pilote p;

Le résultat sera une table avec les attributs de la table vol, mais pour chaque ligne de vol, un
collage de 6 lignes de la table pilotes:

On a fait un produit cartésien de la relation vol par la relation pilote: la requête combine toutes
les occurrences de vol avec toutes les occurrences de pilote.

Exemple 5: recherche sur les vols et sur les pilotes effectifs de ces vols

From vol v, pilote p


Where p.numpilote=v.numpil;
On a fait une jointure naturelle, c’est-à-dire, la requête sélectionne sur le produit cartésien de
vol par pilote les occurrences pour lesquelles les attributs p.numpilote et v.numpil sont égaux.

2ème Cours – le 12 février 2018

Exemple 6: numéro de vols et nom des pilotes

On va travailler avec la table vol et la table pilote, on doit faire la jointure des deux tables. On
utilise l’alias (v et p) pour parler des tables au lieu de dire leur nom. Comme occurrences on
aura les numéros de vol et le nom des pilotes. Le point virgule est toujours à la fin de la
requête, soit le from, le where, ou quelque chose d’autre. On a fait une projection à partir
d’une jointure naturelle.

SELECT v.numvol, p.nom


FROM vol v, pilote p
WHERE p.numpilote=v.numpil;

Exemple 7: numéro des vols sur l’avion « A0006 » et le nom des pilotes de ces vols.

On a réalisé une projection, une jointure naturelle et une sélection.

SELECT v.numvol, p.nom


FROM vol v, pilote p
WHERE p.numpilote=v.numpil
AND v.numav=’A0006’;

Exemple 8: numéro des vols, types d’avion, capacités et noms de pilotes de ces vols.

Il faudra montrer les liens entre les trois tables. On a fait une projection du résultat de 2
jointures naturelles entre 3 relations.

SELECT v.numvol, a.type, a.cap, p.nom


FROM vol v, pilote p, avion a (l’ordre n’importe pas)
WHERE p.numpilote=v.numpil
AND v.numav=a.numavion;

Exemple 9: numéro des vols, types d’avion, capacités et noms des pilotes des vols de capacité
supérieure à 250

C’est toujours important de regarder la base de données pour bien comprendre les jointures
avant de commencer.

SELECT v.numvol, a.type, a.cap, p.nom


FROM vol v, pilote p, avion a
WHERE p.numpilote=v.numpil
AND v.numav=a.numavion
AND a.cap>250;

II. Les fonctions ensemblistes

II.I. Fonction max

C’est une fonction qui va calculer la valeur maximale d’un attribut donné, sachant que cet
attribut pourra être un nombre ou une chaine de caractère. Pour les caractères, il y a un ordre
lexicographique à trouver.

Exemple: capacité maximale des avions allant à Madrid

On va travailler avec la table vols et la table avion, il faut donc écrire les liens entre elles. On
pourrait écrire tout en minuscule si on voulait.

SELECT MAX(a.cap)
FROM avion a, vol v
WHERE v.numav=a.numavion
AND v.arrivee=’Madrid’;

II.II. Fonction min

Comme pour max, min peut fournir un nombre ou une chaine de caractères pour trouver la
valeur minimale d’un attribut.

Exemple: heure de départ du 1er vol du 15/5/99

SELECT MIN(v.hdep)
FROM vol v
WHERE v.jdep={d’1999-05-15’};

II.III. Fonction count

Cette fonction va permettre de compter le nombre d’occurrences d’une table. On peut l’écrire
de deux façons.

Exemple: on souhait connaître le nombre d’avions au départ de Paris

SELECT COUNT(v.depart) OU SELECT COUNT(*)


FROM vol v
WHERE v.depart=’Paris’;
II.IV. Fonction sum

Ça va permettre d’additionner les valeurs d’un même attribut. Ici l’attribut ne pourra être que
numérique.

Exemple: capacité totale des avions au départ de Paris

SELECT SUM(a.cap)
FROM avion a, vol v
WHERE v.numav=a.numavion
AND v.depart=’Paris’;

II.V. Fonction AVG

Ça va permettre de calculer la moyenne des valeurs d’un même attribut.

Exemple: moyenne des capacités des avions à destination d’Amsterdam

SELECT AVG(a.cap)
FROM avion a, vol v
WHERE v.numav=a.numavion
AND v.arrivee=’Amsterdam’;

II.VI. Fonction DISTINCT

Ça va permettre de n’obtenir qu’une seule fois chaque occurrence, en annulant les


occurrences identiques selon tous les critères mis au select. Ici on a aussi deux syntaxes pour
exprimer DISTINCT.

Exemple: connaître les différents types d’avion

SELECT DISTINCT(a.type) OU SELECT DISTINCT a.type


FROM avion a;

II.VII. Fonction ORDER BY

Ça va permettre d’ordonner par ordre croissant ou décroissant (DESC, écrit après l’attribut et


pas après ORDER BY, pour chaque attribut concerné). Si deux lignes ont différentes
capacités, par exemple, elles ne seront pas identiques au sens du DISTINCT. Il faut faire
attention avec le DISTINCT, que ne sera pas toujours explicitement indiqué, comme dans
l’exemple suivant.

Exemple 1: type et capacité des avions par type croissant (ordre alphabétique)
SELECT DISTINCT a.type, a.cap
FROM avion a
ORDER BY a.type;

Exemple 2: pilotes par ordre alphabétique décroissant

SELECT p.nom
FROM pilote p
ORDER BY p.nom DESC;

Exemple 3: types et capacités des avions par types (ordre décroissant) et Cap (ordre croissant)

La 1ère clé de tri est l’attribut Type (ordre décroissant)


La 2ème clé de trie est Cap
Pour une même valeur de Type, les occurrences seront triées selon l’attribut Cap (ordre
croissant).

SELECT DISTINCT a.type, a.cap


FROM avion a
ORDER BY a.type DESC, a.cap;

II.VIII. Fonction GROUP BY

Ça va permettre de faire des regroupements.

Exemple 1: somme des capacités des avions, groupés par ville de départ

SELECT v.depart, SUM(a.cap)


FROM avion a, vol v
WHERE a.numavion=v.numav
GROUP BY v.depart;

GROUP BY est souvent utilisé avec la clause HAVING qui permet de spécifier des
caractéristiques du groupement.

Exemple 2: somme des capacités des avions, groupés par ville de départ telle que le 1 er vol
soit après 9:00

SELECT v.depart, SUM(a.cap)


FROM vol v, avion a
WHERE v.numav=a.numavion
GROUP BY v.depart
HAVING MIN(v.hdep)>’9:00’;
Il n’est pas obligatoire d’utiliser la clause HAVING quand la caractéristique du groupement
peut s’exprimer avec une condition simple, mais ce n’est pas interdit.

Exemple 3: somme des capacités des avions groupés par ville de départ différente de Paris

SELECT v.depart, SUM(a.cap)


FROM vol v, avion a
WHERE v.numav=a.numavion
AND v.depart<>’Paris’
GROUP BY v.depart

II.IX. Fonction BETWEEN

Ça permet de tester l’appartenance à un intervalle, ça s’écrit BETWEEN a AND b.

Exemple: départ et arrivée des vols partant entre 10h et 14h30 (bornes comprises)

SELECT DISTINCT v.depart, v.arrivee


FROM vol v
WHERE v.hdep BETWEEN ’10:00’ AND ’14:30’

3ème Cours – le 19 février 2018

II.X. Fonction LIKE

Ça permet d’utiliser des jokers dans des chaînes de caractères. Le joker _ représente un
unique caractère et le joker % représente une chaine de caractères de longueur quelconque.

Exemple 1: numéro des vols dont le nom du pilote a pour 2ème lettre la lettre « r ».

SELECT v.numvol
FROM vol v, pilote p
WHERE v.numpil=p.numpilote
AND p.nom LIKE ‘_r%’;

Exemple 2: le nom du pilote a pour 3ème lettre la lettre « r ».

AND p.nom LIKE ‘_ _r%’

Exemple 3: le nom du pilote a pour dernière lettre la lettre « r »

AND p.nom LIKE ‘%r’


Exemple 4: le nom du pilote a pour avant dernière lettre la lettre « r ».

AND p.nom LIKE ‘%r_’

Exemple 5: le nom du pilote contient des lettres a et b dans cet ordre

AND p.nom LIKE ‘%a%b%’

II.XI. Fonction IS NULL/IS NOT NULL

Ça permet de vérifier si l’attribut est renseigné ou pas, c’est-à-dire, si la case est vide ou pas.
Dire que la case est vide veut dire que la case est nulle.

Exemple: numéros des vols auxquels sont affectés des pilotes

SELECT v.numvol
FROM vol v
WHERE v.numpil IS NOT NULL

III. Techniques pour les requêtes

Requête 1: Code des pilotes pilotant un avion décollant le même jour que le pilote ‘P0006’.

Première méthode: on crée des sous-requêtes.

SELECT DISTINCT v.numpil


FROM vol v
WHERE v.jdep IN
(SELECT DISTINCT v.jdep
FROM vol v
WHERE v.numpil=’P0006’)
AND v.numpil<>’P0006’;

DISTINCT parce que ce qui m’intéresse c’est chaque jour où P0006 pilote. On met les
parenthèses parce que je veux un ensemble. On demande que v.jdep soit dans l’ensemble
renvoyé par la sous-requête. On recherche des vols qui décollent un jour inclus dans
l’ensemble renvoyé par la sous-requête. Le AND va exclure les occurrences du pilote P0006,
car on cherche les pilotes autres que le pilote P0006. Le DISTINCT pour num.pil c’est parce
qu’on veut connaître le nom de chaque pilote et un pilote peut avoir piloté avec P0006 dans
plusieurs jours différents.

Deuxième méthode: on crée des alias.


SELECT DISTINCT v.numpil
FROM vol v, vol v0006
WHERE v0006.numpil=’P0006’
AND v.jdep=v0006.jdep
AND v.numpil<>’P0006’

Dans v (la table vol) et dans v0006 aussi, deux tables identiques jusqu’au moment.

Requête 2: nom des pilotes pilotant le même type d’avion que le pilote Simon

1ère méthode:

SELECT DISTINCT p.nom


FROM avion a, pilote p, vol v
WHERE p.numpilote=v.numpil
AND v.numav=a.numavion
AND a.type IN
(SELECT DISTINCT a.type
FROM avion a, pilote p, vol v
WHERE p.numpilote=v.numpil
AND v.numav=a.numavion
AND p.nom=’Simon’)
AND p.nom<>’Simon’;

On met distinct sur la sous-requête car Simon peut avoir piloté plusieurs fois le même type
d’avion.

2ème méthode:

SELECT DISTINCT p.nom


FROM avion a, avion aSimon, pilote p, pilote pSimon, vol v, vol vSimon
WHERE p.numpilote=v.numpil
AND v.numav=a.numavion
AND pSimon.numpilote=vSimon.numpil
AND vSimon.numav=aSimon.numavion
AND p.Simon.nom=’Simon’
AND a.type=aSimon.type
AND p.nom<>’Simon’

Requête 3: code, destination des avions décollant le plus tôt et heure de décollage

SELECT v.numav, v.arrivee, v.hdep


FROM vol v
WHERE v.hdep=
(SELECT MIN(v.hdep)
FROM vol v);

Le IN c’est pour quand on se sait pas combien d’éléments seront renvoyés par la sous-requête.

Requête 4: nombre de pilotes volant sur Boeing

SELECT COUNT(v.numpil)
FROM avion a, vol v
WHERE v.numav=a.numavion
AND a.type LIKE ‘Boeing%’

Attention, un même pilote est compté plusieurs fois s’il effectue plusieurs vols sur Boeing.

1ère étape: recherche des codes différents des pilotes qui pilotent des Boeing

SELECT COUNT(p.numpilote)
FROM pilote p
WHERE p.numpilote IN
(SELECT DISTINCT v.numpil
FROM avion a, vol v
WHERE v.numav=a.numavion
AND a.type LIKE ‘Boeing%’);

Distinct permet d’enlever les doublons des codes des pilotes qui ont piloté plusieurs fois des
Boeing.

4ème Cours – le 26 février 2018

Chapitre 2 – Algèbre relationnelle

Formellement, une relation est un sous-ensemble du produit cartésien de N champs


d’application (ou rubriques): D1xD2x…xDN. Pratiquement, une relation est représentée par
un tableau. On parlera ici aussi d’occurrences de la relation (nuplets), des attributs, et du
schéma de la relation: R(Attribut1,…,AttributN), sans besoin de mettre en évidence la clé de
la relation.

Sur ces relations existent des opérateurs, qui vont définir ce qu’on appelle l’algèbre
relationnelle (comme les jointures, projection, etc.). Ces opérateurs opèrent sur des relations
et produisent de nouvelles relations: construction de nouvelles informations à partir des
relations de départ et d’une composition séquentielle d’opérateurs.
On a trois catégories d’opérateurs relationnels: a) unaires, qui s’appliquent à une et une seule
opération, comme l’affectation, la sélection et la projection; b) binaires travaillant sur deux
relations de même schéma, comme l’union, l’intersection et la différence; et c) binaires
travaillant sur deux relations de schémas différents, comme la jointure, le produit cartésien
et la division. Nous allons apprendre tous ces opérateurs.

I. Opérateurs unaires

a) Affectation

Ils vont permettre de sauvegarder le résultat d’une expression de recherche ou encore de


renommer une relation et ses attributs. Trois types de syntaxe:

R(A1,…,An)  expression de sélection


R(A1,…,An)=expression de sélection
R=expression de sélection

b) Sélection

Ils vont permettre de supprimer les occurrences de la relation qui ne satisfont pas une
condition donnée. Syntaxes:

SELECTION(R, condition-de-sélection)
σcond(R)

Le résultat sera une nouvelle relation avec les mêmes attributs, mais les occurrences/nupplets
devront respecter la condition de sélection.

En entrée: une relation R définie sur un schéma SR;


En sortie: une nouvelle relation de même schéma SR, les nuplets satisfont la condition de
sélection.

La condition de sélection est une condition booléenne construite à partir: a) des connecteurs
logiques (et, ou, non); ou b) de conditions simples: b1) attribut de R – opérateur de
comparaison – constante; et b2) attribut de R – opérateur de comparaison – attribut de R.

C’est le WHERE dans SQL, pas le SELECT.

Exemple: considérons la relation Etudiant définie par le schéma Etudiant(Nº étudiant, Nom-
étudiant, Année-étude), ci-dessous:

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1

Je souhaite connaître toutes les informations des étudiants en première année. Pour exprimer
ça, je vais faire une sélection: R1=SELECTION(Etudiant, Année-étude=1). Le résultat sera:

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
864 Paulo 1

c) Projection

Ils vont permettre de supprimer des attributs d’une relation. On y met que les attributs qu’on
va conserver. Les syntaxes:

PROJECTION(R,A1,…,An).
∏A1,…,An (R)

En entrée: une relation R définie sur un schéma SR.


En sortie: une nouvelle relation de schéma A1,…,An (inclus dans SR) ayant comme nuplets
ceux de R restreints au sous-schéma A1,…,An.

On a aussi la suppression des doublons produits par la restriction au sous-schéma, donc ça


correspond au SELECT DISTINCT. Le nombre d’occurrences de la nouvelle relation est ≤ à
celui de R.

Exemple 1: considérons la relation Etudiant définie par le schéma Etudiant(Nº étudiant, Nom-
étudiant, Année-étude).

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1

R2=PROJECTION(Etudiant, Nº Etudiant, Nom-étudiant)

Nº Étudiant Nom-étudiant
843 Carole
521 Peter
864 Paulo

Exemple 2: toujours la relation Etudiant, R3=PROJECTION(Etudiant, Année-étude)

Année-étude
1
3
Ici on voit clairement la suppression des occurrences qui doublent (Année-étude=1).

Exercice: une maîtresse de maison s’est constituée une base de données sur les personnes
qu’elle invite et les plats qu’elle leur sert. Cette base est composée de 3 relations:

Repas(Date, Invité): donne la liste des invités déjà reçus et à quelle date
Menu(Date, Plat): donne le menu servi à chaque date
Préférence(Invité, Plat): donne pour chaque personne ses plats préférés et aussi ça va
permettre de connaître les personnes susceptibles d’être invitées.

Q: Quels sont les invités du repas du 01/05/2014?

R1=SELECTION(Repas, date=01/05/2014)
Rés=PROJECTION(R1, Invité) ou
Rés=PROJECTION(SELECTION(Repas, Date=01/05/2014), Invité)

On a écrit Rés pour dire qu’on a fini la requête, mais on pourrait aussi la nommer R2.

En SQL, ça serait:

SELECT r.Invité
FROM Repas r
WHERE r.Date=’’2014-05-01’’

II. Opérateurs binaires sur deux relations de même schéma

a) Union

Ça va permettre de fusionner deux relations ayant les mêmes attributs en une seule relation.
Les syntaxes sont:

UNION(R, S)
R∪ S

En sortie: une nouvelle relation de schéma SRS, ayant les nuplets de R et ceux de S. Les
doublons sont supprimés.

Exemple: soient les tables suivantes appelées Etudiant et Etudiant 1.

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1
Nº Étudiant Nom-étudiant Année-étude
324 Catherine 2
521 Peter 3
201 Didier 1

R4=UNION(Etudiant, Etudiant 1):

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1
324 Catherine 2
201 Didier 1

b) Intersection

Ça va fournir les occurrences présentes dans les deux relations à la fois. Syntaxes:

INTERSECTION(R, S)
R∩S

En sortie: une nouvelle relation de schéma SRS, ayant les nuplets présents dans R et dans S.

Exemple: soient les tables suivantes appelées Etudiant et Etudiant 1.

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1
Nº Étudiant Nom-étudiant Année-étude
324 Catherine 2
521 Peter 3
201 Didier 1

R5=INTERSECTION(Etudiant, Etudiant1):

Nº Étudiant Nom-étudiant Année-étude


521 Peter 3

c) Différence

On va obtenir des occurrences d’une relation qui n’appartiennent pas à une autre relation. Les
syntaxes:

DIFFERENCE(R, S)
R-S

En sortie: une nouvelle relation de schéma SRS, ayant les nuplets de R qui ne sont pas dans S.
La différence n’est pas commutative!

Exemple: Etudiant(Nº Etudiant, Nom-étudiant, Année-étude) et Doublant (Nº Etudiant, Nom-


étudiant, Année-étude), respectivement:

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1

R6=DIFFERENCE(Etudiant, Doublant):

Nº Étudiant Nom-étudiant Année-étude


521 Peter 3
864 Paulo 1

Exercice: Quelles sont les personnes qui n’ont jamais été invitées pour les repas?

1er pas: on recherche les personnes susceptibles d’être invitées:

R1=PROJECTION(Préférence, Invité)

2ème pas: on recherche les personnes déjà invitées:

R2=PROJECTION(Repas, Invité)

Rés=R1-R2 ou Rés=DIFFERENCE(R1,R2) ou
Rés=PROJECTION(Préférence, Invité)-PROJECTION(Repas, Invité)

En SQL, ça serait:

(SELECT DISTINCT p.Invité FROM Préférence p)


MINUS
(SELECT DISTINCT r.Invité FROM Repas r);

ou

SELECT DISTINCT p.Invité


FROM Préférence p
WHERE p.Invité NOT IN
(SELECT DISTINCT r.Invité
FROM Repas r);

5ème Cours – le 5 mars 2018

III. Opérateurs binaires sur deux relations de schémas différents

a) Produit cartésien

Soient R et S, deux relations définies sur les schémas SR et SS (SR et SS disjoints). Les
syntaxes:

PRODUIT (R, S)
RxS

En sortie, une nouvelle relation de schéma SRS (union des schémas SR et SS) dont les nuplets
sont la concaténation des nuplets de R avec ceux de S. Le nombre d’occurrences de la relation
R par le nombre d’occurrences de la relation S.

Exemple 1: Etudiant(Nº Etudiant, Nom-étudiant, Année-étude)

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1

Père (Code, Age, Prof)

Code Age Prof


843 40 Maçon
521 50 Dentiste
864 42 Maçon

PRODUIT (Etudiant, Père) concatène pour chacune des occurrences de la relation Etudiant,
chaque occurrence de la relation Père.

R7 = PRODUIT(Etudiant, Père)

Nom-
Nº Etudiant Année-étude Code Age Prof
Étudiant
843 Carole 1 843 40 Maçon
843 Carole 1 521 50 Dentiste
843 Carole 1 864 42 Maçon
521 Peter 3 843 40 Maçon
521 Peter 3 521 50 Dentiste
521 Peter 3 864 42 Maçon
864 Paulo 1 843 40 Maçon
864 Paulo 1 521 50 Dentiste
864 Paulo 1 864 42 Maçon

b) Jointure

Soient R et S, deux relations définies sur les schémas SR et SS (SR et SS ayant des attributs
de même domaine). Syntaxes:

JOINTURE (R, S, condition)


R |X| S
Condition

En sortie: une nouvelle relation de schéma SRS (union des schémas SR et SS) dont les nuplets
sont la concaténation des nuplets de R avec ceux de S s’ils ont la même valeur pour les
attributs communs (de même domaine). On parle aussi de jointure naturelle ou équi-jointure.

Exemple 1: Etudiant(Nº Etudiant, Nom-étudiant, Année-étude) et Père (Code, Age, Prof):

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1

Code Age Prof


843 40 Maçon
521 50 Dentiste
864 42 Maçon

R8 = JOINTURE (Etudiant, Père, Nº étudiant=Code)

Année
Nº Étudiant Nom-étudiant Code Age Prof
-étude
843 Carole 1 843 40 Maçon
521 Peter 3 521 50 Dentiste
864 Paulo 1 864 42 Maçon

Exercice: Repas (Date, Invité), Menu (Date, Plat), Préférence (Invité, Plat)

Quels sont les plats qui ont été servis à Alice?

R1=SELECTION(Repas, Invité=’Alice’)
R2=JOINTURE(Menu, R1, Menu.Date=R1.Date)
Rés=PROJECTION(R2, RS.Plat)

En SQL:

SELECTION DISTINCT m.Plat


FROM Menu m, Repas r
WHERE r.date=m.Date
AND r.Invité=’Alice’

c) Auto-jointure

L’auto-jointure est une jointure (réalisée par une condition logique) dans laquelle la même
table est utilisée deux fois. On utilise des variables différentes pour distinguer les deux
entrées.

Étudiant(Nº Etudiant, Nom-étudiant, Année-étude)

Nº Étudiant Nom-étudiant Année-étude


843 Carole 1
521 Peter 3
864 Paulo 1

Père (Code, Age, Prof)

Code Age Prof


843 40 Maçon
521 50 Dentiste
864 42 Maçon

Etudiant dont le père est le plus âgé:

1ère méthode:

R1=AUTO-JOINTURE(Père AS Père, Père AS Père 1, Père.Age=MAX(Père1.Age))


R2=JOINTURE(R1, Etudiant, Code=Nº Etudiant)
Rés=PROJECTION(R2, Nom-étudiant)

2ème méthode:

V1=CALCULE(Père, MAX(Age))
R1=SELECTION(Père, Age=V1)
R2=JOINTURE(R1, Etudiant, Code=Nº Etudiant)
Res=PROJECTION(R2, Nom-étudiant)

d) Division
R est définie sur un schéma SR composé des ensembles d’attributs X et Y (SR=X U Y). S est
définie sur un schéma SS composé de l’ensemble d’attributs Y (SS=Y). Syntaxe:

DIVISION (R, S)
R/S

En sortie: une nouvelle relation de schéma Sres (Sres=SR-SS) qui comprend tous les nuplets
dont la concaténation avec tous les nuplets de S appartient à R. S de Sres veut dire schéma.

Que se passe-t-il pour les attributs? Supposons que les schémas de R et S soient disjoints et
qu’ils contiennent les attributs suivants:

R: Attribut 1, attribut 2, attribut 3


S: Attribut 1, attribut 2

La relation résultat de DIVISION (R, S) aura pour attribut: Attribut 3.

Exercice:

Repas(Date, Invité), Menu(Date, Plat), Préférence(Invité, Plat)

Quels sont les invités qui sont venus à tous les repas?

L’idée est connaître la date des différents repas puis de diviser la table Repas par la table
contenant ces différentes dates.

(Date, Invité) / Date = Invité


R1=PROJECTION(Repas, Date)
Rés=Division(Repas, R1)

6ème Cours – le 12 mars 2018

Base de données cinéma:

catégories(code, intitulé)
réalisateurs(code, nom, prénom, nationalité)
films(référence, titre, durée, catégorie, réalisateur)
joue(référence, code_acteur)
acteurs(code, nom, prénom)

Exercice 1: Films où joue Cruise


Q1=SELECTION(acteurs, nom=’Cruise’)
Dans Q1: attributs de acteurs

Q2=JOINTURE(Q1,joue, code=code_acteur)
Dans Q2: attributs de acteurs + attributs de joue

Q3=JOINTURE(films,Q2,films.référence=Q2.référence)
Dans Q3 : attributs de acteurs + attributs de joue + attributs de films

Rés=PROJECTION(Q3,titre)
Dans Rés: attribut titre

Exercice 2: Acteurs du film Mission impossible

Q1=SELECTION(films, titre=’Mission impossible’)


Dans Q1: attributs de films

Q2=JOINTURE(Q1,joue,Q1.référence=joue.référence)
Dans Q2: attributs de films + attributs de joue

Q3=JOINTURE(Q2, acteurs, code_acteur=code)


Dans Q3: attributs de films + attributs de joue + attributs de acteurs

Rés=PROJECTION(Q3, nom, prénom)


Dans Rés: attributs de nom et prénom

Exercice 3: Films de plus de 120 minutes réalisé par un réalisateur américain

1ère méthode:

Q1=SELECTION(films, durée>120)
Dans Q1: attributs de films

Q2=SELECTION(réalisateurs, nationalité=’USA’)
Dans Q2: attributs réalisateurs

Q3=JOINTURE(Q1, Q2, réalisateur=code)


Dans Q3: attributs de films + attributs de réalisateurs

Rés=PROJECTION(Q3, titre)
Dans Rés: attribut titre

2ème méthode:
Q1=JOINTURE(films, réalisateurs, réalisateur=code)
Dans Q1: attributs de films + attributs de réalisateurs

Q2=SELECTION(Q1, nationalité=’USA’ ET durée>120)


Dans Q2: attributs de films + attributs de réalisateurs

Rés=PROJECTION(Q2, titre)
Dans Rés: attribut titre

Exercice 4: Nom des acteurs qui n’ont jamais joué dans un filme policier

Acteurs qui ont joué dans un film policier

Q1=SELECTION(catégories, intitulé=’Policier’)
Q2=JOINTURE(Q1, films, code=catégorie)
Q3=JOINTURE(Q2, joue, Q2.référence=joue.référence)
Q4=JOINTURE(Q3, acteurs, code_acteur=acteurs.code)
Q5=PROJECTION(Q4, acteurs.code, nom, prénom)

Dans Q5 : attributs code, nom et prénom des acteurs

Q6=acteurs-Q5 ou DIFFERENCE(acteurs, Q5)


Dans Q6: attributs code, nom et prénom des acteurs qui n’ont jamais joué dans un film
policier

Rés=PROJECTION(Q6, nom)
Dans Rés: attribut nom

Exercice 5: nom et prénom des réalisateurs qui ont réalisé des films policiers et d’horreur

Réalisateurs ayant réalisé des films policiers

Q1=SELECTION(catégories, intitulé=’Policier)
Q2=JOINTURE(Q1, films, code=catégorie)
Q3=JOINTURE(Q2, réalisateurs, réalisateur=réalisateurs.code)
Q4=PROJECTION(Q3, réalisateurs.code, nom, prénom)

Dans Q4: attributs code, nom et prénom des réalisateurs

Réalisateurs ayant réalisé des films d’horreur

Q5=SELECTION(catégories, intitulé=’Horreur’)
Q6=JOINTURE(Q5, films, code=catégorie)
Q7=JOINTURE(Q6, réalisateurs, réalisateur=réalisateurs.code)
Q8=PROJECTION(Q7, réalisateurs.code, nom, prénom)

Dans Q8: attributs code, nom et prénom des réalisateurs

Q9=INTERSECTION(Q4,Q8)
Dans Q9: code, nom et prénom

Rés=PROJECTION(Q9, nom, prénom)


Dans Rés: nom, prénom

L’intersection est nécessaire, on ne peut pas faire « SELECTION (intitulé=’Policier’ ET


intitulé=’Horreur’) » car c’est impossible d’avoir les deux au même temps.

Exercice 6: Dans quelles catégories Spielberg n’a-t-il pas réalisé de films?

Catégorie des films réalisés par Spielberg

Q1=SELECTION(réalisateurs, nom=’Spielberg’)
Dans Q1: attributs de réalisateurs

Q2=JOINTURE(Q1, films, code=réalisateur)


Dans Q2: attributs de réalisateurs + films

Q3=JOINTURE(Q2, catégories, catégorie=catégories.code)


Dans Q3: attributs de réalisateurs + films + catégories

Q4=PROJECTION(Q3, catégories.code, intitulé)


Dans Q4: attributs code (catégories) + intitulé
Q5=catégories-Q4 ou DIFFERENCE(catégories, Q4)
Rés=PROJECTION(Q5, intitulé)

Exercice 7: Acteurs qui jouent dans tous les films de Spielberg

L’idée est de rechercher la référence des films de Spielberg

Compte tenu que dans la table joue, il a les 2 attributs (référence et code_acteur), diviser la
table joue par la relation contenant le seul attribut référence des films de Spielberg donnera le
résultat code_acteur des acteurs ayant joué dans tous les films de Spielberg.

Références des films de Spielberg:

Q1=SELECTION(réalisateurs, nom=’Spielberg’)
Q2=JOINTURE(Q1, films, code=réalisateur)
Q3=PROJECTION(Q2, référence)
Code des acteurs jouant dans tous les films de Spielberg:

Q4=DIVISION(joue, Q3)
Q5=JOINTURE(acteurs, Q4, code=code_acteur)
Rés=PROJECTION(Q5, nom, prénom)

Exercice 8: réalisateur et titre du film ayant la durée la plus élevée

Q1=AUTO-JOINTURE(films films, films films 1, films.durée=MAX(films1.durée))


Q2=JOINTURE(Q1, réalisateurs, réalisateur=code)
Rés=PROJECTION(Q2, nom, titre)

OU

V1=CALCULE(films, max(durée))
Q1=SELECTION(films, durée=V1)
Q2=JOINTURE(Q1, réalisateurs, réalisateur=code)
Rés=PROJECTION(Q2, Nom, titre)

7ème Cours – le 19 mars 2018

Chapitre 3 – SGBD

Un SGBD est un Système de Gestion de Base de Données qui est dit relationnel s’il respecte
une norme composée de trois conditions: a) toutes les informations sont représentées par des
valeurs contenues dans des relations (tables); b) l’utilisateur n’a pas à établir des pointeurs
entre les relations (les jointures établissent ces liens); et c) le SGBD permet la sélection
d’occurrences (SELECTION), la sélection d’attributs (PROJECTION) et l’opération de
JOINTURE.

Un SGBD est dit totalement relationnel s’il respecte aussi les deux conditions suivantes: a) il
permet d’utiliser les (autres) opérateurs de l’algèbre relationnelle (excepté la division); et b) il
permet de prendre en compte la contrainte d’unicité des clés et l’intégrité référentielle.
Exemples de totalement relationnels sont ACCESS et mySQL.

Une base de données comporte des relations, dont les descriptions sont elles-mêmes
mémorisées dans une base de données appelée métabase. Si on crée une nouvelle relation, on
agit sur la métabase et si on crée une occurrence d’une relation, on agit sur la base. Le langage
SQL permet non seulement d’interroger les bases de données, mais aussi, par d’autres
instructions, d’agir sur la métabase et sur la base.
La plupart des SGBDs permettent de créer les relations de manière interactive à l’aide de
fenêtres de dialogue et d’assistants (Acess, mySQL). La création d’une relation peut
cependant se faire directement en SQL via l’instruction CREATE TABLE, qui lorsqu’elle
crée une relation, agit sur la métabase.

Une contrainte d’intégrité est une clause permettant de contraindre la modification de tables
par des utilisateurs, afin que les données saisies dans la base soient conformes aux données
attendues. En SQL, ces contraintes s’expriment dès la création de la table grâce à des mots-
clés tels que: DEFAULT, NOT NULL, UNIQUE, CHECK, AUTO_INCREMENT.

La clause DEFAULT permet de définir une valeur par défaut lorsqu’un attribut de la relation
n’est pas renseigné. Doit être suivie de la valeur à affecter.

La clause NOT NULL permet de spécifier qu’un attribut doit être saisi. Le SGBD refusera
d’insérer une occurrence dont un attribut comportant la clause NOT NULL n’est pas
renseigné.

La clause CHECK comporte une condition logique devant être respectée. Elle permet de
faire un test sur un attribut.

La clause UNIQUE permet de vérifier que la valeur saisie pour un attribut n’existe pas déjà
dans la table. Cela garantit que toutes les valeurs d’un attribut dans une table seront
différentes.

La clause AUTO_INCREMENT permet que la valeur de l’attribut soit automatiquement


incrémentée d’une unité à chaque ajout d’une occurrence. Lors de la saisie d’une occurrence,
saisir pour cet attribut la valeur 0.

1) Exemple de création de table avec contrainte:

CREATE TABLE clients(


Nom CHAR(30) NOT NULL,
Prenom CHAR(30) NOT NULL,
Age INTEGER, CHECK(age < 100),
Email CHAR(50) NOT NULL,
CHECK(Email LIKE ‘%@%’) );

CHAR(30) veut dire que la chaine de caractères ne peut pas être plus grande que 30
caractères, INTEGER veut dire que les chiffres sont entiers (pas de décimal). Là, NOT NULL
indique les champs obligatoires et CHECK les conditions à être suivies. Dans la saisie de
chaque occurrence de la table, les attributs Nom, Prénom et Email doivent être renseignés,
l’attribut Age doit être <100 et l’attribut Email sera de la forme ***@***.

2) Exemple de création de table avec la clause DEFAULT:


CREATE TABLE CLIENTS(
NumClient INTEGER NOT NULL,
Nom CHAR(20) NOT NULL,
Age INTEGER NOT NULL,
Adresse CHAR(25),
Salaire DECIMAL (8, 2) DEFAULT 5000.00,
PRIMARY KEY (NumClient) );

Dans la saisie de chaque occurrence de la table, si aucune valeur n’est saisie pour l’attribut
Salaire, l’attribut aura la valeur 5.000,00. Le (8, 2) indiquent qu’on ne veut que deux
caractères après la virgule et 8 avant.

3) Exemple de création de table avec la clause AUTO_INCREMENT:

CREATE TABLE fournisseurs (num int(4)


AUTO_INCREMENT, nom char(30), adresse char(100), PRIMARY KEY(num));

Si l‘on saisit dans la table:

0, Dupont, 31 allée des Châtaigniers


0, Martin, 22 rue d’Assas
0, Charpentier, 15 rue Blanche

Les occurrences seront de la forme:

1, Dupont, 31 allée des Châtaigniers


2, Martin, 22 rue d’Assas
3, Charpentier, 15 rue Blanche

Lors de la création d’une relation, de nombreux SGBD imposent de préciser le (les) attribut
(s) clé (Access, mySQL). Une relation peut avoir une clé principale (un ou plusieurs
attributs), et d’autres clés secondaires (attribut qu’on désigne comme un moyen alternatif
d’accéder (rapidement) aux données. La clé principale va assurer qu’il est impossible de
donner la même clé à deux occurrences différentes de la même relation.

En SQL, la clé principale est signalée PRIMARY KEY et les éventuelles clés secondaires par
UNIQUE:

CREATE TABLE Etudiant(


num_etudiant NUMBER (6), PRIMARY KEY,
nom CHAR(20),
adresse CHAR(30),
date_naissance DATE,
code_diplôme NUMBER(3),
num_ss NUMBER(13) UNIQUE);

Ici le NUMBER indique la quantité maximale de chiffres à être mis, tandis que DATE
indique qu’il s’agit d’une date.

Les clés primaires nécessitent parfois plusieurs attributs pour satisfaire au principe d’unicité.
Si dans un système de facturation les numéros de facture recommencent à 000001 en début
d’année, une identification unique de la facture devra comprendre l’année et le numéro de la
facture!

Si la clé principale est composée de plusieurs attributs, elle est définie à la fin de l’instruction:

CREATE TABLE Etudiant(


num_etudiant NUMBER (6), PRIMARY KEY,
nom CHAR(20),
adresse CHAR(30),
date_naissance DATE,
code_diplôme NUMBER(3),
num_ss NUMBER(13) NOT NULL,
PRIMARY KEY (num_etudiant, num_ss));

La clé étrangère: il s’agit dans une table d’une référence à la clé primaire d’une autre table.
Cette référence n’est pas nécessairement unique.

Exemple de clé primaire, en bleu, et clé étrangère, en rouge:

Membres
Num_membre
Nom
Prénom
Date_naissance

Livres
ISBN
Titre
Auteur
Annee_parution

Emprunts
No_emprunt
Num_membre
ISBN
Date_emprunt
Échéance

Lorsque les relations sont créées, les jointures naturelles entre ces relations doivent être
déclarées avant d’effectuer une requête (Access) et dans la requête (MySQL).

L’intégrité référentielle est respectée si, lors de la création d’une occurrence d’une relation
dont un attribut fait référence à un attribut clé d’une autre relation, la valeur correspondante
de ce dernier attribut est déjà définie.

Une occurrence de la table VOL comporte les attributs numav et numpil, elle ne peut être
créée que si les occurrences des tables PILOTE et AVION auxquelles elle fait référence
existent déjà. Il faut donc que l’occurrence de PILOTE et que l’occurrence de AVION
existent avant que l’on puisse créer l’occurrence de VOL.

Vol:
numvo depart arrivee numav numpil jdep hdep jarr harr
l

Pilote:
numpilote nom prenom

Avion:
Numavion typ cap
e

On peut généralement modifier une relation par des fenêtres de dialogue. Mais SQL permet de
modifier une relation par l’instruction ALTER, suivie d’une spécification de l’opération à
effectuer. L’ajout d’un attribut est déclaré par le mot-clé ADD, la modification d’un attribut
par MODIFY, la suppression d’un attribut par DROP. La suppression d’une relation se fait
par DROP TABLE.
Exemple:

CREATE TABLE Etudiant(


num_etudiant NUMBER (6), PRIMARY KEY,
nom CHAR(20),
adresse CHAR(30),
date_naissance DATE,
code_diplôme NUMBER(3),
num_ss NUMBER(13) UNIQUE);

ALTER TABLE Etudiant ADD moyenne NUMBER(2); => ajoute l’attribut moyenne
(nombre de 2 digits) dans la relation Etudiant.
ALTER TABLE Etudiant MODIFY adresse CHAR(100); => modifie le format de l’attribut
adresse (désormais chaîne d’au plus 100 caractères) de la relation Etudiant.

ALTER TABLE Etudiant DROP adresse; => supprime l’attribut adresse dans la relation
Etudiant.

DROP TABLE Etudiant; => supprime la relation Etudiant.

L’insertion d’une occurrence par SQL se fait grâce à INSERT: INSERT INTO Etudiant
VALUES (.., …, …);

La suppression d’une occurrence se fait par DELETE: DELETE FROM Etudiant WHERE
num_etudiant=…;

La modification d’une occurrence se fait par UPDATE: UPDATE Etudiant SET adresse = …
WHERE num_etudiant = …;

8ème Cours – le 26 mars 2018

Pour créer une base de données relationnelle, il faut récolter les informations auprès de
l’entreprise. On fait une interview pour avoir les informations de l’organisation du travail, les
acteurs-objets, liens entre les acteurs et liens entre les objets.

On va définir les objets de l’entreprise à représenter dans la base de données (clients, produits,
commandes), des liens qui existent entre ces objets (un client passe une commande, une
commande concerne un produit) et des contraintes d’organisation.

On va faire la représentation de ces informations dans un modèle dans un modèle entités-


associations. Un modèle de représentation et de structuration de l’information (schéma) qui va
permettre de comprendre l’organisation des données et visualiser l’organisation de ces
données.

Ce modèle n’est pas possible d’implémenter tel que dans un SGBD, du coup il faut
transformer ce modèle entités-associations en un modèle relationnel directement possible
d’implémenter dans un SGBD. Les étapes sont donc: faire le modèle entités-associations,
transformer en relationnel et après implémenter en SGBD.

L’entité c’est un objet ayant une existence propre présentant un intérêt pour l’entreprise : le
client Dupuis, le fournisseur Durand. Les types d’entité sont une classe d’entité ayant en
commun un ensemble de propriétés : client et fournisseur. Type d’entité client: Num_client,
Nom_client, Adresse.
Les liens entre les entités s’appellent les associations. Une association est un lien entre entités,
présentant un intérêt pour la représentation de l’entreprise. Le lien est représenté par un verbe
matérialisant une relation entre entités. Le client Dupuis achète des produits du fournisseur
Durand.

C0102 F011
Dupus Achète Durand
42, Champs Élysées, Paris 11, rué Kléber, Strasbourg

Un type d’association est un lien entre types d’entités. Achète est un type d’association entre
le type d’entité client et le type d’entité fournisseur.

Num_client Num_fournisseur
Nom_client Achète Nom_fournisseur
Adresse Adresse

Une propriété est une caractéristique d’une entité ou d’une association d’entités. L’adresse est
une propriété des types d’entités client et des types d’entités fournisseur. Un identifiant est
une propriété particulière d’un type d’entité ou d’un type d’association permettant de
distinguer entre elles les occurrences de ce type d’entité ou de ce type d’association. C’est le
code du client/fournisseur, qui est unique.

Pour chaque type d’entité il va falloir leur donner un nom, un identifiant et ses propriétés.
L’identifiant d’un type d’association est obtenu en concaténant les identifiants des types
d’entités concernés.

Achète
Identifiant: num_client, num_fournisseur

La cardinalité d’une entité dans une association est le nombre de fois minimum et le nombre
de fois maximum qu’une même occurrence de l’entité peut intervenir dans les occurrences de
l’association.

Exemple 1: type d’association propriétaire

Personne Appartement
Num-personne Num-appartement
Nom 0, n est propriétaire 1, n Adresse
Prénom

Une personne est propriétaire de combien d’appartements? Une personne peut ne pas avoir
d’appartement. Ça veut dire que la cardinalité min est zéro. Elle peut avoir plusieurs
appartements, donc la cardinalité est n. Sur l’autre axe, on se pose de la question suivante: cet
appartement appartient à combien de personnes au min et au max? Au moins à quelqu’un,
donc cardinalité min 1 et au max c’est n. Le type d’association propriétaire a 2 pattes de
cardinalité maximale égale à n.

Exemple 2: type d’association commande

Commande Article
Num_commande 1, n Concerne 0, n Num_article
Date quantité Désignation
Prix
1, 1

Est passé par

0, n

Client
Num_client
Nom_client
Adresse

Le type d’association «Est passé par» a une patte de cardinalité maximale égale à 1. Cela
traduit le fait qu’une commande ne peut être passée que par un et un seul client. Tout type
d’association ayant une patte de cardinalité maximale égale à 1 est une dépendance
fonctionnelle (DF). On va la représenter: Commande => Client, soit la commande la source
de la DF et le client le but de la DF et quand on connaît la commande, on peut en déduire le
client. À une valeur de source correspond une et une seule valeur de but.

Pour passer du modèle entités-associations au modèle relationnel, on a trois règles.

1) Règle a: types d’entités

Modèle entités-associations Modèle relationnel


Chaque type d’entité => Une relation de même nom
Chaque propriété du type d’entité => Un attribut de la relation
L’identifiant du type d’entité => La clé de la relation

2) Règle b: types d’associations de dimension 2 qui ont de part et d’autre une patte de
cardinalité maximale strictement supérieure à 1.

Modèle entités-associations Modèle relationnel


Le type d’association de dim 2 a de part
et d’autre une patte de cardinalité maximale => Une relation
strictement supérieure à 1
Chaque propriété du type d’association => Un attribut de la relation

Le couple constitué des identifiants des 2 => La clé de la relation


types d’entités concernés

3) Règle c: le type d’association de dim 2 a une patte de cardinalité maximale égale à 1, il


s’agit d’une dépendance fonctionnelle. On ne crée pas de relation, mais l’identifiant du type
d’entité but de la DF est ajouté dans la liste d’attributs de la relation source de la DF.

Exemple 1: type d’association propriétaire

Personne Appartement
Num-personne Num-appartement
Nom 0, n est propriétaire 1, n Adresse
Prénom

Le modèle relationnel:
Personne (Num-personne, Nom, prénom)
Appartement (Num-appartement, adresse)
Propriétaire (Num-personne, Num-appartement)

Exemple 2: type d’association commande

Commande Article
Num_commande 1, n Concerne 0, n Num_article
Date quantité Désignation
Prix
1, 1

Est passé par

0, n

Client
Num_client
Nom_client
Adresse

Le modèle relationnel:
Commande (Num_commande, Date, #Num_client)
Client (Num_client, Nom_client, Adresse)
Article (Num_article, Désignation, Prix)
Détail_commande (Num_commande, Num_article, Quantité)
La troisième règle (il s’agit d’une DF, donc pas de relation) dit qu’il faut ajouter l’identifiant
du type d’entité but (Num_client) dans la liste d’attributs de la relation source Commande.
Num_client sera une clé étrangère dans commande.

9ème Cours – le 9 avril 2018

On va faire des exercices avec le modèle suivant:

1) Une réservation est-elle toujours accompagnée d’une assurance?


Non, car la cardinalité min du type d’association « liée » entre RESERVATION et
ASSURANCE est 0 du côté de la réservation.

2) Une réservation peut-elle être payé avec plusieurs types de paiement?


Non, car la cardinalité max du type d’association « confirme » entre une RESERVATION et
un PAIEMENT est 1 du côté de la réservation.

3) Un client peut-il effectuer plusieurs réservations?


Oui, car la cardinalité max du type d’association « effectue » entre une RESERVATION et un
CLIENT est n du côté du client.

4) Une réservation peut-elle concerner plusieurs voyages?


Non, car le type d’association « concerne » entre une RESERVATION et un voyage a pour
cardinalité max 1 du côté de la réservation.
Pour construire un modèle relationnel avec ces entités, il faut prendre les identifiants comme
clé et les autres comme attribut, par exemple:

ASSURANCE(Num-assurance, Type-assurance)
CLIENT(Num-client, Nom, Prénom, Adresse, Téléphone)
PAIEMENT(Type-Paiement)
VOYAGE(Num-Voyage, Pays, Date-départ, Vol-départ, Date-retour, Vol-retour, Prix)
RESERVATION(Num-réservation, Date_resa, Nb-Personnes, #Num-Assurance, #Num-
Client, #Num-Voyage, #Type-Paiement, Date_Paiement, compte)

Tous les types d’association sont des dépendances fonctionnelles (DF) de même source
RESERVATION:

Réservation -> Assurance


Réservation -> Paiement
Réservation -> Client
Réservation -> Voyage

Ils sont donc tous matérialisés par l’ajout de la clé de leur but dans la source de la DF, donc
dans RESERVATION. On observe, en vert, les clés étrangères dans la transcription au
modèle relationnel

Un autre exercice c’est de lire un texte et en prendre les informations pour construire un
modèle:

« Une bibliothèque enregistre chaque lecteur à qui elle donne un numéro de lecteur. Elle note
son nom et son adresse. Le lecteur peut éventuellement être membre d’une société adhérente:
on enregistre alors l’identification de cette société.
Un lecteur peut emprunter plusieurs livres par jour. A chaque prêt, on enregistre une date de
retour. Un lecteur appartient à un type de lecteur, qui lui permet ou non d’avoir accès à
certaines catégories de livres.
La durée du prêt dépend de la catégorie du livre et du type de lecteur. Elle est la même pour
tous les livres d’une catégorie donnée, empruntés par un lecteur quelconque d’un type donné.
Un livre est caractérisé par un numéro d’inventaire. Il est nécessaire de connaître sa catégorie,
le nom de son auteur, de son éditeur, ainsi que le nombre d’exemplaires disponibles. La
catégorie d’un livre se repère par un numéro et possède un libellé. Il en est de même pour le
type de lecteur. Une société adhérente possède un nom et une adresse ; elle s’engage à
envoyer un minimum de 500 lecteurs.

Après avoir fait ça, il faut créer un dictionnaire des données, une liste des propriétés:

Numéro de lecteur Numéro de la société adhérente


Nom du lecteur Date de retour du prêt
Adresse du lecteur Durée du prêt
Numéro d’inventaire du livre Numéro de catégorie
Nom de l’auteur du livre Numéro du type de lecteur
Libellé du type de lecteur
Nom de l’éditeur Nom de la société adhérente
Nombre d’exemplaires disponibles Adresse de la société adhérente

Lecteur Identifiant : Num_lecteur


Propriétés : Nom, Adresse

Société adhérente Identification : Num_société


Propriétés : Nom_société, Adresse_société

Livre Identifiant: Num_inventaire


Propriétés: Nom_auteur, Nom_éditeur, Nbre_exemp_dispo

Catégorie Identifiant : Num_catégorie


Propriété : Libellé_catégorie

Type_lecteur Identifiant : Num_type


Propriétés : libellé_type

Types d’association:

Appartient à reliant Livre et Catégorie


Est membre reliant Lecteur et Société_adhérente
Appartient à reliant Lecteur et Type_lecteur
A accès reliant Type_lecteur et Catégorie
Propriété : Durée_prêt
Emprunte reliant Lecteur et Livre
Propriété : Date_retour
10ème Cours – le 30 avril 2018

Les relations de ce modèle entité-associations seront:

Société_adhérente(Num_société, Nom_société, Adresse_société)


Catégorie(Num_catégorie, Libellé_catégorie)
Type_lecteur(Num_type, Libellé_type)
Lecteur(Num_lecteur, Nom, Adresse,
Livre(Num_inventaire, nom_auteur, Nom_éditeur, Nbre_exemp_dispo,

Là on vient de prendre les entités du modèle et transformé en relations, en soulignant en rouge


les clés primaires.

Maintenant, on regarde les cardinalités max et on crée des relations pour les associations dont
les deux soient strictement plus grandes que 1. Cette relation aura un nom proche de
l’association, un substantif par exemple, et les clés seront les identifiants des entités associées.
S’il y a des propriétés, elles vont devenir aussi des attributs.

Prêt (Num_lecteur, Num_inventaire, Date_retour)


Accès(Num_type, Num_catégorie, Durée_prêt)

Finalement, on voit les associations dont au moins une des cardinalités max est 1. Le 1
entre Lecteur et Société veut dire que lecteur est la source et société le but, du coup on prend
l’identifiant du but et met comme clé étrangère dans la relation de la source avec un #. Encore
une fois, la cardinalité max 1 entre Livre et Catégorie, du coté du livre, montre que Livre est
la source et Catégorie le but, du coup l’identifiant de Catégorie deviendra la clé étrangère de
Livre.

Lecteur(Num_lecteur, Nom, Adresse, #Num_société, #Num_type)


Livre(Num_inventaire, nom_auteur, Nom_éditeur, Nbre_exemp_dispo, #Num_catégorie)

Chapitre 5 – Dépendances et normalisations

Pourquoi a-t-on besoin de normalisation? Par exemple, on a une base de données dont la
relation R contient toutes les informations possibles: relation R(produit, client, adresse,
quantité_com,prix_unit,montant).

On va trouver plusieurs anomalies: si un client fait plusieurs commandes, il y a redondance du


couple (client, adresse). Si le client change d’adresse, il faut changer plusieurs lignes. Du
coup ça va augmenter le temps de mise à jour. Aussi, ça engendre une augmentation des
risques d’incohérence, c’est une anomalie de modification.

Si un produit n’a pas été commandé, on ne connaît pas son prix, du coup on a une
anomalie d’insertion. Si Martin annule sa commande, on perd son nom et son adresse. Si un
produit ne figure que dans une seule ligne et qu’on supprime la ligne, on a perte
d’informations, du coup une anomalie de suppression.

Si on insère la ligne Shampooing, Dubois, Dijon, 5, 5, 25, le système ne détectera pas


que Dubois a 2 adresses différentes. Pour éviter ces anomalies, on va distinguer plusieurs
relations en les reliant par des jointures:

R1(code_client, client, adresse)


R2(code_produit, produit, prix_unit)
R3(code_commande, code_client, code_produit, quantité_com)

La normalisation a pour but fixer des règles permettant de passer de la 1 ère représentation à la
2ème. Normaliser une relation c’est représenter la relation sous une forme qui respecte des
critères assurant l’intégrité des données (évitant ainsi au concepteur de la base un certain
nombre d’erreurs graves)

La dépendance c’est la contrainte exprimée par une règle que doivent vérifier les données
pour que la base de données soit dans un état cohérent.

La théorie de la normalisation repose sur l’analyse des dépendances entre attributs. Elle
propose des méthodes systématiques visant à décomposer les relations afin qu’il soit toujours
possible de reconstituer la relation originale par l’opération de jointure.

Il y a trois types de dépendances: fonctionnelles, multivaluées et jonctionnelles.


a) Dépendances fonctionnelles

Définition 1: soit R une relation, A l’ensemble des attributs et X, Y des sous-ensembles de A.


Par définition, il existe une dépendance fonctionnelle entre X et Y (notée X => Y) si dans la
relation R, chaque valeur X détermine une et une seule valeur de Y.

Exemples: client => adresse


(prix_unit, quantité_com) => montant

La relation vol du début du cours: numvol, jdep => numpil

À gauche, on a la source et à droite le but. Cela veut dire que si on met numvol=V0010 et
jdep=15/05/99, on ne peut pas mettre numpil=P0005 et après une autre ligne avec
numpil=P0001. Une dépendance fonctionnelle veut dire forcement que pour de mêmes
valeurs de source, on a les mêmes valeurs de but.

Définition 2: clé d’une relation. Quand dans une relation, un attribut ou un groupe d’attributs
est source de dépendances fonctionnelles ayant respectivement pour buts chacun des autres
attributs de la relation, cet attribut ou groupe d’attributs est appelé Clé de la relation.

Exemple: pour la relation vol, on a 7 dépendances fonctionnelles dérivant de numvol, jdep:


depart, arrivee, numav, numpil, hdep, jarr et harr. Ça veut dire que le couple est une clé de la
relation vol.

Un attribut appelé attribut clé s’il appartient à une clé de R et non clé s’il n’appartient pas à
aucune clé de R.

Définition 3: dépendance fonctionnelle élémentaire. Soit X un groupe d’attributs et Y un


attribut unique n’appartenant pas à X. La dépendance fonctionnelle X -> Y est dite
élémentaire si Y ne dépend pas aussi d’un sous-ensemble de X. X est la plus petite quantité
d’information permettant de déduire Y. Si une clé est composée de plusieurs attributs, les DF
dont la clé est la source sont dites élémentaires si aucun sous-ensemble de la clé ne suffit pour
être source de la DF.

[PERDI]

11ème Cours – le 7 mai 2018


Définition 6: relation en 1ère forme normale

Une relation est normalisée si un même attribut n’est pas représenté plusieurs fois (même
avec des valeurs différentes) et si un même attribut n’est pas décomposable en d’autres
attributs. Toute relation normalisée est dite en 1re forme normale
Exemple: relation non normalisée

Enfants
Nom Diplôme
Prenom Date naissance
Dupuis Bac Luc 1986
Licence André 1989
Dupont Bac Jeanne 1991
Ingénieur Lucie 1995

La relation n’est pas normalisée parce que l’attribut enfants est décomposable en deux
attributs et l’attribut diplôme est représenté plusieurs fois pour une même personne.

Exemple: relation 1ère forme normale

La relation vente(num-client, num-article, nom-client, nom-article)

Le couple (num-client, num-article) est la clé, la relation est normalisée donc en 1 ère forme
normale. Les dépendances fonctionnelles sont (num-client, num-article) => nom-client et
(num-client, num-article) => nom-article

Inconvénients de la 1ère forme normale :

Introduction, sans possibilité de détection d’anomalies, des occurrences (23, A10, Durand, lit)
(23, A15, Laurent, table) et (35, A10, Michel, table)

Définition 7: relation en 2ème forme normale

Une relation est en 2ème forme normale si et seulement si elle est en 1FN et si tous les attributs
non clés sont pleinement dépendants des clés (toutes les dépendances entre une clé et un
attribut non clé sont élémentaires). Ou encore une relation est en 2ème forme normale si toutes
les dépendances fonctionnelles issues de la clé sont élémentaires (aucun sous-ensemble de la
clé ne suffit pour être source de la DF).

Exemple: la relation vente(num-client, num-article, nom-client, nom-article) est en 1 ère forme


normale mais pas en 2ème forme normale

Des DF: (num-client, num-article) => nom-client et (num-client, num-article) => nom-article.

Exemple: la relation représentant (num-client, nom-client, num-représentant, nom-


représentant). Les DFs qui en découlent sont num-client => nom-client, num-client => nom-
représentant et num-client => nom-représentant sont élémentaires donc la relation est en 2 ème
forme normale.
Inconvénients de la 2ème forme normale

Introduction, sans possibilité de détection d’anomalies, des occurrences (10, Berger, R10,
Dupuis) et (11, Dupont, R10, Durand).

La DF num-client -> nom-représentant n’est pas directe puisqu’on a num-client -> num-
représentant et qu’il existe une DF naturelle num-représentant-> nom représentant.

Une relation est en 3eme forme normale si et seulement si elle est en

Perdi aqui

Exercice 1:

Dans la base de données d’une société de transport, la relation affectation décrit pour les jours
du mois en cours les affectations des conducteurs de bus aux lignes:

Affectation(Nº ligne, Nº Conducteur, Jour)

Plus précisément, cette relation signifie que tel jour, tel conducteur est affecté à telle ligne de
bus.