Regrouper et analyser les données

Nous utilisons CLIENT(id_client, nom, ville) et COMMANDE(id_commande, id_client, montant). Les clients sont Aube, identifiant 1, à Lyon ; Borel, identifiant 2, à Paris ; Cime, identifiant 3, à Lyon ; Dune, identifiant 4, à Lille. Les commandes sont respectivement (101, 1, 80), (102, 1, 120), (103, 2, 40) et (104, 3, 20). Les montants sont exprimés en euros. Dune n’a aucune commande dans cet extrait fictif. Toutes les valeurs du jeu principal sont renseignées.

La première question porte sur l’ensemble des commandes. La deuxième porte sur chaque client. Ce changement de niveau d’analyse change le nombre de lignes du résultat. Sans regroupement, un calcul global renvoie un indicateur sur l’ensemble retenu. Avec GROUP BY id_client, chaque valeur distincte de l’identifiant constitue un groupe. Une ligne représente alors un groupe de commandes appartenant au même client, et non une commande particulière.

Avant de calculer, on précise la population, la période, l’unité et le sens de l’indicateur. Ici, aucune date ni information sur le paiement n’est disponible. Le cumul des montants ne peut donc pas être présenté comme le chiffre d’affaires encaissé du mois. Il représente seulement les montants des quatre commandes de l’extrait. Un intitulé prudent évite de transformer un calcul exact en conclusion trompeuse.

COUNT(*) compte les lignes retenues. COUNT(montant) compte les valeurs renseignées du montant. SUM(montant) additionne les valeurs renseignées ; AVG(montant) en calcule la moyenne. MIN et MAX donnent les valeurs extrêmes renseignées. Le choix dépend de la question : un nombre de commandes n’a pas la même unité qu’un montant total. Les alias rendent les titres du résultat compréhensibles, sans changer le calcul.

Une donnée manquante doit rester visible dans l’interprétation. Dans une variante séparée, on ajoute une cinquième commande dont le montant est NULL. COUNT(*) vaut alors 5, COUNT(montant) vaut 4 et AVG(montant) reste 65. La moyenne porte sur les quatre montants connus. Remplacer automatiquement l’inconnu par zéro ferait baisser la moyenne à 52 et affirmerait à tort que la commande vaut zéro.

GROUP BY id_client rassemble les commandes par identifiant. On sélectionne cet identifiant et les agrégats voulus. Une colonne détaillée, comme id_commande, ne doit pas être ajoutée arbitrairement à cette synthèse : plusieurs commandes correspondent au même groupe. Pour une requête claire et portable, les colonnes sélectionnées hors agrégats doivent correspondre au regroupement. L’ordre des groupes nécessite ORDER BY ; il n’est pas garanti par GROUP BY.

WHERE filtre des lignes avant le regroupement. HAVING filtre les groupes après le calcul des agrégats. Pour étudier uniquement les commandes d’un intervalle de dates, on placerait le critère de date dans WHERE. Pour conserver ensuite les clients dépassant un cumul, on utiliserait HAVING. Ces deux filtres peuvent coexister, car ils répondent à deux questions différentes sur deux niveaux de données.

Une jointure interne entre CLIENT et COMMANDE conserve les correspondances présentes. Pour afficher tous les clients, même ceux sans commande, on part de CLIENT et on utilise LEFT JOIN. Le client sans correspondance demeure dans le résultat, avec des attributs de commande à NULL. Cette ligne permet d’identifier son absence d’activité, mais elle n’est pas une commande réelle.

Une jointure peut aussi multiplier des lignes si plusieurs enregistrements correspondent à une même clé. Avant une somme, il faut vérifier le niveau de détail obtenu. Joindre chaque commande à ses lignes d’articles puis additionner le montant total de commande répéterait ce montant autant de fois qu’il y a de lignes. Le contrôle consiste à suivre une commande témoin et à compter ses apparitions après chaque jointure.

Une moyenne de moyennes n’est pas forcément la moyenne générale. Les clients du jeu principal ont des nombres de commandes différents. Aube a une moyenne de 100 € sur deux commandes ; Borel 40 € sur une ; Cime 20 € sur une. Donner le même poids à ces trois moyennes décrit un client moyen parmi les clients actifs, et non une commande moyenne. Le dénominateur détermine donc le sens de l’indicateur.

Pour compter les clients actifs, COUNT(DISTINCT id_client) appliqué à COMMANDE vaut 3 dans le jeu principal. COUNT(*) vaut 4. Le premier mesure des identifiants distincts de clients associés à une commande ; le second mesure des commandes. Aucun des deux ne donne le nombre total de clients enregistrés, qui vaut 4 dans CLIENT. Des nombres égaux peuvent ainsi représenter des réalités différentes.

Dans une analyse de gestion, la réponse utile relie la demande, la requête et la décision. On nomme l’indicateur, on explique les filtres et on interprète le résultat avec son unité. Si les données ne précisent pas la période ou le paiement, on le signale. Cette démarche développe l’analyse des documents ; elle ne crée pas une épreuve écrite autonome de spécialité SIG. Pour la session 2027, l’écrit de management, sciences de gestion et numérique porte sur l’enseignement commun.

Pour s’entraîner davantage, poursuivre avec la rubrique Exercices. Une bonne vérification consiste à prévoir le résultat avant d’exécuter la requête, puis à expliquer tout écart constaté. Un résultat inattendu peut révéler une mauvaise jointure, un filtre placé au mauvais niveau ou une hypothèse fausse sur les données.