3. Les revenus moyens générés par la vente d'un individu de l'espèce
Code : SQL
SELECT Espece.nom_courant AS espece, SUM(somme)/SUM(nb) AS moyenne
FROM V_Revenus_annee_espece
INNER JOIN Espece ON V_Revenus_annee_espece.espece_id = Espece.id
GROUP BY espece;
espece
moyenne
Chat
720.000000
Chien
342.857143
Perroquet amazone 700.000000
Rat brun
10.000000
Tortue d'Hermann 140.000000
Création d'une interface entre l'application et la base de données
Lorsque l'on a une base de données exploitée par une application (écrite dans un langage de programmation comme Java, ou
PHP par exemple), c'est souvent dans cette application que sont construites les requêtes qui vont insérer, modifier, et
sélectionner les données de la base.
Si pour une raison ou une autre (mauvaise conception de la base de données au départ, modèle de données qui s’étend
fortement,…) la structure des tables de la base change, il faut réécrire également l'application pour prendre en compte les
modifications nécessaires pour les requêtes.
Cependant, si l'on a utilisé des vues, on peut éviter de réécrire toutes ces requêtes, ou du moins limiter le nombre de requêtes à
réécrire. Si les requêtes sont faites sur des vues, il suffit en effet de modifier la définition de ces vues pour qu'elles fonctionnent
avec la nouvelle structure.
Exemple
On a créé une vue V_Client, qui permet de voir le contenu de notre table Client (sauf la date de naissance, ajoutée après la
définition de la vue).
Si un beau jour on décidait de stocker les adresses postales dans une table à part, il faudrait modifier la structure de notre base.
Au lieu d'une seule table Client, on en aurait deux : Client(id, nom, prenom, date_naissance, email, adresse_id ) et Adresse(id,
rue_numero, code_postal, ville, pays).
Pour que l'application puisse continuer à sélectionner les personnes et leur adresse sans qu'on doive la modifier, il suffirait de
changer la requête définissant la vue :
Code : SQL
CREATE OR REPLACE VIEW V_Client
-- le OR REPLACE indispensable
(ou on utilise ALTER VIEW)
AS SELECT Client.id, nom, prenom, rue_numero AS adresse,
code_postal, ville, pays, email, date_naissance
FROM Client
LEFT JOIN Adresse ON Client.adresse_id = Adresse.id -- LEFT JOIN au
cas où certains clients n'auraient pas d'adresse définie
Le changement de structure de la base de données serait ainsi transparent pour l'application (du moins en ce qui concerne la
sélection des clients) !
Restriction des données visibles par les utilisateurs
Partie 6 : Au-delà des tables classiques : vues, tables temporaires et vues matérialisées
341/414
www.openclassrooms.com
Code : SQL
SELECT Espece.nom_courant AS espece, SUM(somme)/SUM(nb) AS moyenne
FROM V_Revenus_annee_espece
INNER JOIN Espece ON V_Revenus_annee_espece.espece_id = Espece.id
GROUP BY espece;
espece
moyenne
Chat
720.000000
Chien
342.857143
Perroquet amazone 700.000000
Rat brun
10.000000
Tortue d'Hermann 140.000000
Création d'une interface entre l'application et la base de données
Lorsque l'on a une base de données exploitée par une application (écrite dans un langage de programmation comme Java, ou
PHP par exemple), c'est souvent dans cette application que sont construites les requêtes qui vont insérer, modifier, et
sélectionner les données de la base.
Si pour une raison ou une autre (mauvaise conception de la base de données au départ, modèle de données qui s’étend
fortement,…) la structure des tables de la base change, il faut réécrire également l'application pour prendre en compte les
modifications nécessaires pour les requêtes.
Cependant, si l'on a utilisé des vues, on peut éviter de réécrire toutes ces requêtes, ou du moins limiter le nombre de requêtes à
réécrire. Si les requêtes sont faites sur des vues, il suffit en effet de modifier la définition de ces vues pour qu'elles fonctionnent
avec la nouvelle structure.
Exemple
On a créé une vue V_Client, qui permet de voir le contenu de notre table Client (sauf la date de naissance, ajoutée après la
définition de la vue).
Si un beau jour on décidait de stocker les adresses postales dans une table à part, il faudrait modifier la structure de notre base.
Au lieu d'une seule table Client, on en aurait deux : Client(id, nom, prenom, date_naissance, email, adresse_id ) et Adresse(id,
rue_numero, code_postal, ville, pays).
Pour que l'application puisse continuer à sélectionner les personnes et leur adresse sans qu'on doive la modifier, il suffirait de
changer la requête définissant la vue :
Code : SQL
CREATE OR REPLACE VIEW V_Client
-- le OR REPLACE indispensable
(ou on utilise ALTER VIEW)
AS SELECT Client.id, nom, prenom, rue_numero AS adresse,
code_postal, ville, pays, email, date_naissance
FROM Client
LEFT JOIN Adresse ON Client.adresse_id = Adresse.id -- LEFT JOIN au
cas où certains clients n'auraient pas d'adresse définie
Le changement de structure de la base de données serait ainsi transparent pour l'application (du moins en ce qui concerne la
sélection des clients) !
Restriction des données visibles par les utilisateurs
Partie 6 : Au-delà des tables classiques : vues, tables temporaires et vues matérialisées
341/414
www.openclassrooms.com