En notant que vous voulez obtenir la somme du salaire, dans Tutorial D :
SUMMARIZE emp BY { job } ADD ( SUM ( sal ) AS total_sal )
L'agrégation de notes n'est pas un opérateur relationnel et ne fera donc pas partie d'une algèbre relationnelle.
Quant à HAVING , est-ce une anomalie historique. Avant la norme SQL-92, il n'était pas possible d'écrire SELECT expressions dans le FROM clause (aka tables dérivées) c'est-à-dire que vous deviez faire tout le travail dans un SELECT expression. En raison de l'ordre d'évaluation rigide de SQL, la valeur agrégée n'existe pas après le WHERE clause a été évaluée, c'est-à-dire qu'il était impossible d'appliquer une restriction basée sur des valeurs agrégées. HAVING a été introduit pour résoudre ce problème.
Mais même avec HAVING , SQL est resté relationnellement incomplet en ce qui concerne Codd jusqu'à ce que les tables dérivées aient été introduites. Tables dérivées rendues HAVING redondant mais utilisant HAVING est toujours populaire (si l'on se fie à Stackoverflow) :les gens semblent toujours aimer utiliser un seul SELECT dans la mesure du possible et la rigidité susmentionnée de SQL en ce qui concerne l'ordre des évaluations (la projection est effectuée en dernier dans un SELECT expression) rend l'utilisation de la table dérivée assez détaillée par rapport à HAVING .
