Une difficulté majeure des bases de données, c’est qu’on y parle de tables et de lignes, qui sont des notions abstraites, qui ne sont pas en contact immédiat avec la réalité, pour nous.
Quand on nous parle de lignes de la table client, par exemple, on a du mal à se représenter facilement de quoi on parle.
Les concepts de la programmation objet peuvent nous aider à mieux se rapprocher de la réalité. En réalité, une table est une collection d’objets. Et une ligne est un objet. Par exemple, une table client est un ensemble d’objets clients. Et une ligne de la table client est un objet client ! Une table est donc un ensemble d’objet, plutôt une collection d’objet, car la notion d’ordre est tout de même présente étant donné que les enregistrements sont rangés dans leur ordre de création.
Pour créer une table, on doit indiquer à la base de données le modèle d’un des objets qui sera contenu dans cet table. Donc on fournit à la base de données la classe de l’objet, si on parle en terme de programmation objet.
De même, pour se simplifier la compréhension, on peut dire qu’un SELECT est une recherche. Par conséquent, dire « je vais effectuer un SELECT sur la table client » peut être dit d’une autre façon : je vais effectuer une recherche de clients dans la table clients. Un « INSERT » est un ajout d’un objet dans la table. « Je vais faire un INSERT sur la table clients » revient à dire « je vais rajouter un objet client dans mon ensemble d’objets clients ». Un « UPDATE » est une modification d’un des objets de notre collection d’objets : je modifie un objet client parmi notre ensemble d’objets client. Un « DELETE » est la suppression d’un certain nombre d’objets( on définit le critère de suppression) de notre collection d’objets. On supprime, par exemple, plusieurs objets clients de notre ensemble de clients. Et le critère de suppression est que les clients n’ont rien commandé depuis 1 an.
Je pense que ce parallèle avec la programmation objet peut nous aider à réaliser de quoi on parle, quand le besoin s’en fait sentir. Par exemple, quand on nous dit « ce select nous renvoie 15 lignes de la table clients », cela n’évoque pas grand chose en nous. Alors qu’en se disant « ce select renvoie 15 objets clients qui ont répondu aux critères de recherche », cela devient très clair.
Pour éviter de réécrire une même requête systématiquement, on utilise les vues. Une vue est une table virtuelle. Une vue vous permet de créer un objet qui aura la structure que vous souhaitez, et qui implémentera ce que vous voulez. Une vue est donc une interface, qui peut rester fixe, alors que l’implémentation peut changer( si les tables auxquelles a accès la vue ont changé). On a donc une encapsulation des tables, ce qui comporte également des avantages en terme de sécurité. Une vue nous permet donc de modéliser les objets qu’on souhaite, en se libérant des contraintes matérielles imposées par les tables.
En outre, il est tout-à-fait possible de faire des vues de vues.
On peut dire également qu’une vue est, en fait, une requête qu’on nomme !
CREATE VIEW nom_vue AS SELECT champ1, champ2 FROM table1,table2 WHERE champx = champy ;
SELECT * FROM nom_vue;
On peut faire autre chose que selectionner toutes les lignes, sur une vue : on peut utiliser une vue, comme on utilise une table. Simplement, la requête sous-jacente de la vue(celle qu’on ne voit plus et que vous avez écrite au début), sera complétée( c’est comme ça que la base s’y prendra).
CREATE TABLE ma_table( ch1 type_ch1,
ch2 type_ch2,
ch3 type_ch3,
PRIMARY KEY(ch1, ch2) ) ;
Cas d’une clé composite ici.
ALTER TABLE ma_table ADD PRIMARY KEY( ch_cle) ;
Ou encore
ALTER TABLE ma_table ADD CONSTRAINT ma_contrainte PRIMARY KEY (ch_cle); Permet de donner un nom à la contrainte.
Remarques :
. On ne peut pas faire cette dernière ligne sans donner de nom à la contrainte ( logique car le mot clé contrainte sert à indiquer le nom d’une contrainte !).
. Si une contrainte n’est pas nommée, la base va attribuer un nom d’elle-même à cette contrainte.
ALTER TABLE ma_table DROP CONSTRAINT ma_contrainte.
ma_contrainte est le nom qu’on a donné à la contrainte.
FOREIGN KEY(ch2, ch3) REFERENCES table_orig(chA, chB) -- le chA, chB est sûrement facultatif
) ;
Cas d’une clé étrangère composite ici.
ALTER TABLE ma_table ADD FOREIGN KEY( num_client) REFERENCES table_client;
Pas besoin de préciser quel champ de table_client est référencé, car c’est forcément la clé primaire de cette table!
Ou, en nommant la contrainte :
ALTER TABLE ma_table ADD CONSTRAINT ma_contrainte FOREIGN KEY( num_client) REFERENCES table_client;
Tri sur deux critères : SELECT * FROM ma_table ORDER BY nom_groupe, nom_eleve ;
Groupe A Eleve a
Groupe A Eleve c
Groupe A Eleve e
Groupe A Eleve g
Groupe A Eleve i
Groupe B Eleve bb
Groupe B Eleve cc
Groupe B Eleve dd
Groupe C Eleve b
Groupe C Eleve d
Groupe C Eleve f
Le GROUP BY permet d’appliquer les fonctions d’aggrégat( par exemple sum, etc) en appliquant ces fonctions par groupe. Seul le group by permet de faire cela ! Par exemple, on veut afficher la somme des montants des commandes de chaque client.
SELECT nom_client, sum( montant ) FROM commande GROUP BY nom_client
Résultat:
DUPONT 1000
DURAND 3500
MARTIN 1500
Alors qu’on avait pour Dupont 3 commandes: 200, 700, et 100( somme=1000). Pour Durand, 1 commande de 3500. Et pour Martin 2 commandes( 900 et 600).
Le GROUP BY permet d’obtenir des groupes.
Remarque lorsque un where est présent, le filtre du where est d’abord appliqué. Le group by a lieu ensuite, sur le résultat du where.
Exemple : SELECT nom_client, sum( montant ) FROM commande WHERE age>=25 GROUP BY nom_client
Ici on ne veut la somme des montants que pour les clients de plus de 25 ans.
Remarque: le group by utilisé sans aggrégat peut permettre d’éliminer des lignes identiques dans une requête. Il permet alors d’obtenir les lignes distinctes, sur une ou plusieurs colonnes, ce qui est l’équivalent du SELECT DISTINCT. La notion de groupe est tout-de-même gardée : chaque groupe est l’ensemble de lignes ayant la ou les colonnes communes !
Par exemple :
SELECT nom_client FROM client GROUP BY nom_client : cette requête retourne tous les noms de client différents. Ce qui est bien l’équivalent de :
SELECT DISTINCT nom_client FROM client.
Autre remarque : après le GROUP BY, on met un ou plusieurs noms de champs, et c’est tout( on ne met pas de conditions) .
Autre remarque sur le GROUP BY : On remarque qu’un groupe est toujours une seule ligne retournée par le GROUP BY. Cette ligne représente le groupe.