Académique Documents
Professionnel Documents
Culture Documents
Introduction
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.
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 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.
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.
pilote(numpilote,nom,prenom)
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.
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.
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.
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)
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’}
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
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.
Exemple 7: numéro des vols sur l’avion « A0006 » et le nom des pilotes de ces vols.
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.
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.
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.
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’;
Comme pour max, min peut fournir un nombre ou une chaine de caractères pour trouver la
valeur minimale d’un attribut.
SELECT MIN(v.hdep)
FROM vol v
WHERE v.jdep={d’1999-05-15’};
Cette fonction va permettre de compter le nombre d’occurrences d’une table. On peut l’écrire
de deux façons.
Ça va permettre d’additionner les valeurs d’un même attribut. Ici l’attribut ne pourra être que
numérique.
SELECT SUM(a.cap)
FROM avion a, vol v
WHERE v.numav=a.numavion
AND v.depart=’Paris’;
SELECT AVG(a.cap)
FROM avion a, vol v
WHERE v.numav=a.numavion
AND v.arrivee=’Amsterdam’;
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;
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)
Exemple 1: somme des capacités des avions, groupés par ville de départ
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
Exemple 3: somme des capacités des avions groupés par ville de départ différente de Paris
Exemple: départ et arrivée des vols partant entre 10h et 14h30 (bornes comprises)
Ç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%’;
Ç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.
SELECT v.numvol
FROM vol v
WHERE v.numpil IS NOT NULL
Requête 1: Code des pilotes pilotant un avion décollant le même jour que le pilote ‘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.
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:
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:
Requête 3: code, destination des avions décollant le plus tôt et heure de décollage
Le IN c’est pour quand on se sait pas combien d’éléments seront renvoyés par la sous-requête.
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.
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
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.
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.
Exemple: considérons la relation Etudiant définie par le schéma Etudiant(Nº étudiant, Nom-
étudiant, Année-étude), ci-dessous:
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:
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)
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
843 Carole
521 Peter
864 Paulo
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.
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’’
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.
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.
R5=INTERSECTION(Etudiant, Etudiant1):
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!
R6=DIFFERENCE(Etudiant, Doublant):
Exercice: Quelles sont les personnes qui n’ont jamais été invitées pour les repas?
R1=PROJECTION(Préférence, Invité)
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:
ou
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.
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:
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.
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)
R1=SELECTION(Repas, Invité=’Alice’)
R2=JOINTURE(Menu, R1, Menu.Date=R1.Date)
Rés=PROJECTION(R2, RS.Plat)
En SQL:
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.
1ère méthode:
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:
Exercice:
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.
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)
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
Q2=JOINTURE(Q1,joue,Q1.référence=joue.référence)
Dans Q2: attributs de films + attributs de joue
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
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
Rés=PROJECTION(Q2, titre)
Dans Rés: attribut titre
Exercice 4: Nom des acteurs qui n’ont jamais joué dans un filme 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)
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
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)
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)
Q9=INTERSECTION(Q4,Q8)
Dans Q9: code, nom et prénom
Q1=SELECTION(réalisateurs, nom=’Spielberg’)
Dans Q1: attributs de réalisateurs
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.
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)
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)
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.
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 ***@***.
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.
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:
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:
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.
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:
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.
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 = …;
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.
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.
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.
Commande Article
Num_commande 1, n Concerne 0, n Num_article
Date quantité Désignation
Prix
1, 1
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.
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.
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)
Commande Article
Num_commande 1, n Concerne 0, n Num_article
Date quantité Désignation
Prix
1, 1
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.
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:
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:
Types d’association:
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.
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.
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).
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.
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.
À 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.
Un attribut appelé attribut clé s’il appartient à une clé de R et non clé s’il n’appartient pas à
aucune clé de R.
[PERDI]
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.
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
Introduction, sans possibilité de détection d’anomalies, des occurrences (23, A10, Durand, lit)
(23, A15, Laurent, table) et (35, A10, Michel, table)
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).
Des DF: (num-client, num-article) => nom-client et (num-client, num-article) => nom-article.
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.
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:
Plus précisément, cette relation signifie que tel jour, tel conducteur est affecté à telle ligne de
bus.