Forum du club des d�veloppeurs et IT Pro - Blogs - Blog de Lyche par Lyche

Les jointures en SQL

Lyche — Tue, 27 Sep 2016 21:10:16 GMT

Pr�sentation

Une base de donn�es relationnelle, c�est la mise en place d�une organisation claire et efficace des donn�es d�une entreprise bas�e sur la th�orie des ensembles.
Chaque �l�ment constitutif d�un mod�le poss�de un ou plusieurs liens avec un ou plusieurs autres objets. Ce lien est traduit en mod�lisation par l�exportation d�un �l�ment � la cl� � d�une table vers une autre table � laquelle elle est li�e. Ceci est vu par la mod�lisation UML/MERISE. Nous allons parler ici de l�application technique de ces liens par le SQL. � savoir, les jointures.

Dans cet article, nous allons travailler les jointures sur le c�t� � naturel � des relations via l�utilisation de cl� primaires et de cl� secondaires. Il est tout � fait possible de joindre 2 tables par des colonnes qui ne sont pas n�cessairement la cl� primaire. Cela arrive beaucoup lors d�utilisation d�ETL afin de v�rifier si une donn�e existe ou non dans une table, mais ceci est un autre sujet que nous n�aborderons pas aujourd�hui.

Mod�lisation

Beaucoup de sites et tutoriaux abordent le sujet de la mod�lisation (Notamment l�excellent blog de SQLPro aussi, je ne m�y attarderais pas. Non pas que je ne souhaite pas le faire, mais je pense sinc�rement que s�attarder sur ce point n�a plus d�int�r�t tant le sujet a �t� d�battu et trait� par des confr�res et que je n�ai rien � apporter � ce qui a d�j� �t� dit pour le moment.

Les Jointures

Ce que l�on nomme � jointure �, mot un peu �trange mais parfaitement repr�sentatif de ce qu�il se passe derri�re la ligne de code que vous tapez.
Concr�tement, la jointure est-ce qui permet au SGBD de faire le lien entre les donn�es des tables que vous voulez exploiter.
Pour nous aider � nous repr�senter ce � lien �, nous allons g�n�rer un mod�le, simple pour commencer, que nous �tofferons au fur et � mesure de notre �tude.
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
CREATE DATABASE JointuresSQL;
GO
 
CREATE TABLE dbo.T_SERVICES
( SER_ID         INT IDENTITY(1, 1)
, SER_NOM         VARCHAR(  50 )
, PRIMARY KEY (SER_ID )
);
GO
 
CREATE TABLE dbo.T_PERSONNEL
( PER_ID     INT IDENTITY( 1, 1)
, PER_NOM    VARCHAR( 80 )
, PER_PRENOM VARCHAR( 80 )
, PER_SER_ID INT
PRIMARY KEY (PER_ID),
FOREIGN KEY (PER_SER_ID) REFERENCES dbo.SERVICES( SER_ID )
);
GO
 
INSERT INTO dbo.SERVICES( SER_NOM ) VALUES( 'Direction' );
INSERT INTO dbo.SERVICES( SER_NOM ) VALUES( 'Service Comptable' );
INSERT INTO dbo.SERVICES( SER_NOM ) VALUES( 'Pôle BI' );
INSERT INTO dbo.SERVICES( SER_NOM ) VALUES( 'Pôle CRM' );
INSERT INTO dbo.SERVICES( SER_NOM ) VALUES( 'Pôle Data Quality' );
 
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'BERNARD'    , 'Jacques'    , 1 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'DUPONT'     , 'Mathilda'   , 2 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'ROMERO'     , 'George'     , 2 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'CALBERA'    , 'Deborah'    , 4 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'TONETTY'    , 'Aldo'       , 3 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'ALDERAN'    , 'Célyna'     , 3 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'ZATAN'      , 'Zlatan'     , 4 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'DUMONT'     , 'François'   , 5 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'LEPRÉ'      , 'Jean'       , 5 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'JENLAIN'    , 'Jean-Michel', 5 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'DELCROIX'   , 'Florent'    , 4 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'DELVALLÉE'  , 'Amandine'   , 3 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'LEGRAND'    , 'Nicolas'    , 3 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'LEBON'      , 'Francis'    , 4 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'DUPONT'     , 'LAURA'      , 3 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'DELARUE'    , 'DELPHINE'   , 4 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'DELABELIERE', 'ROBIN'      , 3 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'SOUSLARUE'  , 'YANN'       , 3 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'ROSAY'      , 'ANTHONY'    , 5 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'DECAUX'     , 'MATHIEU'    , 5 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'BENALAI'    , 'CORINNE'    , 4 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'SURBLE'     , 'ROSE'       , 4 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'SARGI'      , 'SEBASTIEN'  , 3 );
INSERT INTO dbo.T_PERSONNEL ( PER_NOM, PER_PRENOM, PER_SER_ID ) VALUES( 'BENISEAU'   , 'MATHIS'     , 3 );
Nous allons repr�senter les diff�rents services d�une entreprise ainsi que les personnes qui la composent. Ce lien est physiquement repr�sent� par la pr�sence du champ PER_SER_ID dans la table T_PERSONNEL.

Ce champ doit nous servir pour ressortir les diff�rentes informations recherches.

Ex : nous souhaitons r�cup�rer la liste du personnel du P�le CRM.
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
SELECT P.PER_NOM   
     , P.PER_PRENOM
  FROM T_PERSONNEL P
       INNER JOIN T_SERVICES S ON P.PER_SER_ID = T.SER_ID
 WHERE S.SER_NOM = 'Pôle CRM';
La requ�te, simple, nous permet de joindre les lignes de la table PERSONNEL aux lignes de la table SERVICES par l�identifiant commun qu�il y a dans les 2. Ainsi, le code nous ressortira l�ensemble des donn�es contenues dans la table PERSONNEL faisant partie du d�partement � P�le CRM �

Ceci est la relation la plus simple que l�on puisse avoir entre deux tables. Une relation (1,n) traduite par une jointure interne et qui ne ressortira que les informations dont la condition est vraie dans les 2 sens. (Dans notre cas, l�identifiant 4 pour le p�le CRM)

Les types de jointures

Comme vous avez pu le constater lors de vos �tudes en mod�lisation, il n�existe pas qu�un seul type de relations entre les �l�ments d�une base. Voici les diff�rents types de jointures que vous pourrez retrouver ainsi que quelques subtilit�s qui les caract�risent.

INNER JOIN

Vu plus au-dessus, elle permet de ressortir les lignes quand les conditions sont remplies dans les 2 tables li�es par la jointure. C�est la plus simple des jointures.

Le sch�ma ci-dessous repr�sente le r�sultat d�une requ�te INNER JOIN. Seule la partie commune aux deux tables est extraite.

Sch�ma INNER JOIN

CROSS JOIN

Une jointure � crois�e �, c�est ce qu�on appelle un produit cart�sien. Le SGBD va croiser chaque ligne de la premi�re table, avec chaque ligne de la deuxi�me table.
Ex :
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
SELECT *
  FROM T_PERSONNEL
       CROSS JOIN T_SERVICES
Que constatez-vous ?

Que chaque �l�ment de la table T_SERVICES se retrouve � accol� � � chaque �l�ment de la table T_PERSONNEL.

Pour faciliter la � lecture � vous pouvez rajouter un filtre sur un service, vous verrez alors votre jeu de donn�es limiter � x*1 (X �tant le nombre d��l�ments de la table T_PERSONNEL)
Le CROSS JOIN peut s�av�rer � dangereux �, si vous faites le produit cart�sien d�une table contenant de gros volumes de donn�es (plusieurs millions de lignes) sur une autre table, vous pouvez vous retrouver avec un nombre de lignes g�n�r� parfois hors norme. (1 Million * 1 Million = 1 000 000 000 000) �a laisse songeur !!

LEFT [OUTER] JOIN

Le sch�ma ci-dessous repr�sente le r�sultat d�une requ�te LEFT JOIN. Toutes les donn�es de la table de gauche ressortiront. En � bonus � les informations communes de la table de droite apparaitront aussi.

Sch�ma LEFT JOIN

La jointure Externe gauche permet d�obtenir un r�sultat sur des lignes m�mes si elles ne sont pas pr�sentes dans les 2 tables. Le choix du terme LEFT est assez simple, mettez votre requ�te sur une seule ligne (c�est moche, mais facile � comprendre ainsi !) et bien, la table � gauche des mot cl�s � LEFT JOIN � (la jointure) et qui est appel�e dans les �l�ments de jointures sera la table � maitresse � de la requ�te.
OUTER �tant optionnel, je le place entre []

Tous les �l�ments non filtr�s de la table apparaitront, et ce, m�me s�il n�y a pas de liens dans la deuxi�me table.

Pour notre exemple, nous allons rajouter un service dans la table T_SERVICES et tester la jointure.
Vous pourrez constater (et voir la diff�rence en ex�cutant la pr�c�dente requ�te en INNER JOIN)
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
INSERT INTO dbo.T_SERVICES( SER_NOM ) VALUES ( 'Service Commercial' );
GO
 
 
SELECT *
  FROM dbo.T_SERVICES S
       LEFT JOIN dbo.T_PERSONNEL P ON P.PER_SER_ID = S.SER_ID
Ici, nous pouvons constater que le Service Commercial n�a pas de personnes qui lui sont affect�es, et que donc, le SGBD ressort 1 ligne, avec les �l�ments de la table T_PERSONNEL � NULL.

RIGHT [OUTER] JOIN

Le Sch�ma ci-dessous repr�sente le r�sultat d�une requ�te RIGHT JOIN. Toutes les donn�es de la table de droite ressortiront. En � bonus � les informations communes de la table de droite apparaitront aussi.

Sch�ma RIGHT JOIN

La jointure externe droite est, intrins�quement, la m�me chose que la jointure gauche, avec la seule diff�rence que la table � maitresse � se situe � droite de la commande RIGHT JOIN
Essayez d�ex�cuter la requ�te en ne changeant que LEFT par RIGHT. Vous pourrez constater un petit changement dans le r�sultat !
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
SELECT *
  FROM dbo.T_SERVICES S
       RIGHT JOIN dbo.T_PERSONNE L P ON P.PER_SER_ID = S.SER_ID
la ligne 25, repr�sentant une donn�e non-existante dans la table T_PERSONNEL ne s�affiche plus. En effet, la table maitresse �tant celle ou les donn�es sont manquantes, la ligne ne peut apparaitre.
L�ordre des donn�es a chang�. Dans la premi�re requ�te, l�ordre est bas� sur les donn�es d�insertion de la table T_SERVICES. Ici, sur les donn�es d�insertion de la table T_PERSONNEL.

FULL JOIN

Le Sch�ma ci-dessous repr�sente le r�sultat d�une requ�te FULL JOIN. L�ensemble des donn�es de deux tables sera s�lectionn� dans le r�sultat de la requ�te. Les parties non communes seront marqu�es d�un NULL pour tous les champs sans correspondances.

Sch�ma FULL JOIN

Le FULL JOIN est une jointure peu utilis�e, car parfois tr�s consommatrice en performances. Un FULL JOIN porte litt�ralement son nom, il va faire une jointure totale entre les 2 tables et fournir un jeu de donn�es � partir du moment o� une ligne est pr�sente dans l�une des deux tables.
C�est comme si vous faisiez un RIGHT et un LEFT JOIN en m�me temps. Les Colonnes sans correspondance d�une table apparaitront � NULL. Vous l�aurez compris, si votre mod�le de donn�es est norm�, vous ne devriez pas avoir de cas de donn�es orphelines dans les 2 tables. La table fille ne peut avoir de r�f�rence NULL.

SELF JOIN ou AUTO-JOINTURE

Il est � noter que � SELF � n�est pas � proprement parler un mot-cl�, il s�agit plut�t d�une information nous indiquant qu�une table s�auto-r�f�rence.
Ce cas est le moyen le plus simple de calculer une hi�rarchie. Il s�agit, pour une table utilis�e dans une jointure, d��tre jointe � elle-m�me. Comme la th�orie pour ce genre de cas peut �tre particuli�rement abstraite et peut paraitre illogique, nous allons adapter notre mod�le de donn�es, pour lui faire correspondre � notre besoin.

Ajoutons un �l�ment permettant de g�rer la hi�rarchie. (a. De fa�on logique, une hi�rarchie est un lien entre 2 �l�ments d�une table.)

Ex : BERNARD Jacques, est dans notre mod�le � la direction. Comme il est seul, nous supposons qu�il est le Directeur de l�entreprise.
Nous allons choisir 1 personne dans chaque service, elle va devenir arbitrairement � chef du service � et nous allons leur assigner, BERNARD Jacques comme chef. Puis, nous mettrons les personnes de chaque service sous la responsabilit� du chef de service.

Comment cela va se traduire ?

Par l�ajout d�une colonne � RESP_ID � dans la table du personnel.
Par la cr�ation d�un lien entre responsable et collaborateur
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
USE JointuresSQL;
GO
 
ALTER TABLE dbo.T_PERSONNEL ADD PER_RESP_ID INT NULL;
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 1
 WHERE PER_NOM    = 'DUPONT'
   AND PER_PRENOM = 'Mathilda';
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 1
 WHERE PER_NOM    = 'CALBERA'
   AND PER_PRENOM = 'Deborah';
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 1
 WHERE PER_NOM    = 'TONETTY'
   AND PER_PRENOM = 'Aldo';
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 1
 WHERE PER_NOM    = 'TONETTY'
   AND PER_PRENOM = 'Aldo';
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 1
 WHERE PER_NOM    = 'DUMONT'
   AND PER_PRENOM = 'François';	
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 2
 WHERE PER_SER_ID = 2
   AND PER_ID != 2;
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 5
 WHERE PER_SER_ID = 3
   AND PER_ID != 5;
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 4
 WHERE PER_SER_ID = 4
   AND PER_ID != 4;
 
UPDATE dbo.T_PERSONNEL
   SET PER_RESP_ID = 8
 WHERE PER_SER_ID = 5
   AND PER_ID != 8;
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
SELECT PER.PER_SER_ID AS ID_SERVICE
     , RES.PER_NOM    AS RESP_NOM
     , RES.PER_PRENOM AS RESP_PRENOM
     , PER.PER_NOM    AS PER_NOM
     , PER.PER_PRENOM AS PER_PRENOM
  FROM dbo.T_PERSONNEL AS PER
       RIGHT JOIN dbo.T_PERSONNEL AS RES ON PER.PER_RESP_ID = RES.PER_ID
 WHERE PER.PER_NOM IS NOT NULL
 ORDER BY PER.PER_SER_ID, RES.PER_NOM, RES.PER_PRENOM
;
Vous pourrez constater qu�il va manquer quelques pr�cisions dans le classement des personnes (� savoir qui est le directeur de l�entreprise et qu'il devrait se situer en haut).
Il est � noter que les normes SQL ont �norm�ment �volu� et que des m�thodes ont �t� mises en place pour permettre de g�rer au mieux une hi�rarchie. (Voir Mon cours sur les CTE et requ�tes r�cursives). Nous n�aborderons pas le sujet ici, car il n�cessite une assez bonne connaissance de SQL pour l�appr�hender.

NATURAL JOIN

Le NATURAL JOIN est une norme permettant la � simplification � de l��criture de requ�tes. Elle utilise l�intelligence du moteur de donn�es, � partir du moment o� on lui m�che un peu le travail, en nommant les FK des tables filles comme le nom de la colonne d�origine.
Dans notre cas, il nous faudrait remplacer le nom de la colonne T_PERSONNEL.PER_SER_ID en T_PERSONNEL.SER_ID
Et la requ�te s��crirait ainsi
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
SELECT *
  FROM T_PERSONNEL
       NATURAL JOIN T_SERVICES
C�est imm�diatement plus lisible, mais aussi plus � gourmand � et demande au SGBD un peu plus d�efforts pour appliquer les jointures et calculer son plan d�ex�cution.
Personnellement, je ne m�en sers jamais. Simplement parce que toutes les autres jointures comportent la clause ON qui permettent de voir en un coup d��il quelles sont les colonnes de jointures entre les tables et qu�avoir des �critures diff�rentes dans une m�me requ�te peut brouiller la lecture. De plus, les performances de vos requ�tes se trouvent affect�es par le fait que le SGBD doit fournir un effort suppl�mentaire d�identification des liaisons entre tables. Sur de petites volum�tries, cela ne g�ne pas, mais il ne faut jamais oublier qu�une base de donn�es est destin�e � vivre longtemps, et qu�� forte volum�trie comme sur lesquelles j�ai pu travailler (entre 1 et 5 milliards de lignes), cela s�av�re �tre source de ralentissement.

CAS PARTICULIERS :

EXISTS

EXISTS n�est pas, � proprement parler une jointure. En effet, sa forme premi�re d�utilisation est de d�clencher ou non une requ�te si une donn�e existe en tant que r�sultat d�une sous-requ�te. C�est-�-dire qu�� partir du moment, o� il y aura au moins 1 ligne retourn�e dans la sous-requ�te, alors l�ensemble de la requ�te sera ex�cut�, sinon, il ne se passera rien. (C�est une sorte de � IF � plus � classe �)

Mais il existe une autre forme de � EXISTS �. Elle consiste � lier le r�sultat de la sous-requ�te aux lignes de la requ�te principale. Le principe d�une jointure �tant de relier les tables par une �galit� sur un � n champs.
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
-- Forme première du EXISTS
SELECT *
  FROM T_SERVICES
 WHERE EXISTS ( SELECT 1
                  FROM T_PERSONNEL );
 
-- 2ème forme du EXISTS
SELECT *
  FROM T_SERVICES
 WHERE EXISTS ( SELECT 1
                  FROM T_PERSONNEL
                 WHERE T_SERVICES.SER_ID = T_PERSONNEL.PER_SER_ID );
On peut constater que la premi�re version n�applique pas de filtre. Si l�on remplace le � EXISTS � par un � NOT EXISTS �, il n�y aura plus de donn�es du tout. La requ�te principale ne ressortira pas de donn�es, car il y a des donn�es alors que nous n�en voulons pas.
La deuxi�me forme de EXISTS, va reproduire pratiquement le m�me effet qu�un INNER JOIN et permettra de lister les services dans lesquels il y a au moins une personne.
Le gros avantage, et c�est pour cette raison que je place la clause EXISTS dans les � pseudo jointures � c�est qu�on peut reproduire l�effet d�un INNER JOIN, sans avoir les contraintes de doublons g�n�r�s par une relation 1,n. Mais il devient impossible de remonter les donn�es de la table dans le EXISTS sous la forme de colonnes.
N.B : Vous aurez probablement constat� le � SELECT 1 � de la sous requ�te. Il est important de savoir et comprendre que l�important c�est pas le r�sultat du SELECT, mais, dans la premi�re forme qu�il y ait une valeur quelle qu�elle soit, et dans la 2�me forme, que l��galit� existe ou non. Le SELECT dans la 2�me forme n�est m�me pas lu par la requ�te principale.

FILTRES ET PRE FILTRES

La plupart des personnes pratiquantes du SQL savent faire des requ�tes avec des jointures simples et des filtres. Moins nombreux sont ceux qui savent faire la diff�rence entre un filtre (clause WHERE) et un pr�filtre.
Un filtre, �a sert � limiter le nombre de lignes que l�on souhaite faire apparaitre en r�sultat d�un select. C�est ce qu�on appelle commun�ment les r�gles de gestion (RG). Mais, il est possible, lorsque l�on travaille avec du LEFT/RIGHT JOIN d�appliquer un premier filtre � une table afin de ne pas nous perturber avec des donn�es qui ne nous int�ressent pas en provenance d�une table jointe.
Exemple :
Je souhaite connaitre les personnes de la direction. Un filtre normal s�applique et nous aurons 1 ligne.
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
-- 1 - Filtre sur les personnes du service Direction
 
SELECT *
  FROM dbo.T_PERSONNEL P
       LEFT JOIN dbo.T_SERVICES S ON P.PER_SER_ID = S.SER_ID
 WHERE S.SER_ID = 1;
Comme attendu, notre filtre nous remonte l�ensemble des lignes dont les personnes sont affili�es au service � Direction �.
Cependant, il est parfois n�cessaire de conserver l�ensemble des donn�es d�une table, mais de n�afficher que certaines donn�es, et ce, pour mettre en exergue certains faits.
Dans la requ�te suivante, on pourrait croire que cette personne est seule dans son entreprise, hors, il n�en est rien. Appliquons le m�me filtre, mais en � pr�filtre �.
Code sql : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
--2 - Pré-Filtre sur le service Direction
SELECT *
  FROM dbo.T_PERSONNEL P
       LEFT JOIN dbo.T_SERVICES S ON P.PER_SER_ID = S.SER_ID
                                 AND S.SER_ID = 1;
Vous pouvez constater que la requ�te ne remonte les informations de la table T_SERVICES que pour la direction, mais que les autres personnes sont quand m�me pr�sentes dans le r�sultat.
Il devient, ainsi, facile d�identifier telle ou telle personne dans une liste de nombreuses autres.
Ce cas est plus courant qu�on ne le croit et bons nombres de r�sultats attendus peuvent se trouver faux � la suite d�une mauvaise application de RG entre le filtre et le pr� filtre.

Conclusion :

Les normes SQL pr�voient bon nombre de cas de lecture de donn�es entre les tables. Les diff�rentes jointures que nous avons �tudi�es dans ce document prennent en compte les diff�rentes possibilit�s de liaisons de vos tables lorsque vous r�alisez votre mod�le. Si vous d�sirez progresser dans votre qualit� de code SQL, il vous sera imp�ratif de parfaitement ma�triser les jointures, qui en sont la base.

Remerciements
Je remercie Sylvain Del TATTO (minot83), Jean-Marie BAGNIS(jimbolion), C�lia POTOT (Erielle) ainsi Fr�d�rique Brossard (Directeur Adjoint au p�le BI chez MCNext) et S�verine CAPON (GeekMokona) pour leur relecture, conseil et correction qui m�ont permis de publier cet article.

Les CTE

Lyche — Tue, 07 Jun 2016 14:46:46 GMT

Les sous-requ�tes et leurs utilisations

Il est assez difficile de traiter d�un sujet comme les tables d�riv�es et les CTE (Common Table Expression) sans cas concrets. Les requ�tes exemples ne sont pas toujours pertinentes et l�utilit� des techniques comme les Tables D�riv�es (que je nommerai TD dans la suite de l�article) n�est pas intuitive. N�h�sitez pas � apporter des remarques dans les commentaires, je ferai en sorte d�y r�pondre rapidement.

Pr�sentation

Suite � la r�daction de mon premier billet sur les agr�gats, il m�a �t� demand� d�expliquer ce qu��taient les CTE (Common Table Expression ou Expression de Tables Communes).
Je vais profiter de ce billet pour donner une petite explication du terme ainsi que les comparer en termes d�utilit� et de lisibilit� � leurs anc�tres que sont les Tables d�riv�es.
C�t� performance, il n�y a pas d��cart � code �gal. Je ne m��tendrai pas sur ce sujet, d�autant que mon but est surtout la d�couverte de cette technique m�connue.

D�finition

Les tables d�riv�es sont des requ�tes permettant d�extraire un jeu de donn�es exploitable dans une requ�te de niveau sup�rieur.
Structure de donn�es :

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
CREATE DATABASE DBTrainningCTE;
GO
CREATE TABLE dbo.TB_DEPARTEMENTS (
  ID_DEPARTEMENT  INT PRIMARY KEY
, NOM_DEPARTEMENT VARCHAR( 50 ) );
GO
 
CREATE TABLE dbo.TB_EMPLOYES (
  ID_EMPLOYE      INT PRIMARY KEY
, NOM_EMPLOYE     VARCHAR( 50 ) NOT NULL
, AGE_EMPLOYE     INT
, DEPARTEMENT_ID  INT
, SALAIRE_EMPLOYE MONEY );
GO
 
INSERT INTO dbo.TB_DEPARTEMENTS
VALUES( 1, 'Administration'       );
INSERT INTO dbo.TB_DEPARTEMENTS
VALUES( 2, 'Ressources Humaines'  );
INSERT INTO dbo.TB_DEPARTEMENTS
VALUES( 3, 'Service Informatique' );
INSERT INTO dbo.TB_DEPARTEMENTS
VALUES( 4, 'Comptabilité'         );
 
INSERT INTO dbo.TB_EMPLOYES
VALUES( 1, 'Georges', 74, 4, 2480.3 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 2, 'Pierre' , 17, 3, 1387.2 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 3, 'Bernard', 63, 1, 3499.8 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 4, 'John'   , 23, 3, 1876.9 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 5, 'Jérome' , 45, 2, 2286.6 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 6, 'Lina', 30, 3, 2230.4 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 7, 'Marie', 26, 3, 1980.4 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 8, 'Virginie', 37, 3, 2730.4 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 9, 'Hélène', 33, 3, 2430.4 );
INSERT INTO dbo.TB_EMPLOYES
VALUES ( 10, 'Yuva', 28, 3, 2200.2 );

Exemple

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
SELECT *
  FROM ( SELECT Nom, Prenom
           FROM dbo.TB_EMPLOYES ) AS TD --TD Pour Table dérivée, mais je recommande un nom explicite pour les futurs lecteurs de votre code ;)
 WHERE Nom = 'toto';

Ceci est un exemple simple de table d�riv�e.

Cas pratique

Notre exemple simplifi� doit nous permettre d�envisager l��laboration d�une requ�te qui va lister un nombre de personnes.
Listons, pour commencer nos employ�s dont l��ge est compris entre 20 et 40 ans.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
 
SELECT NOM_EMPLOYE   , AGE_EMPLOYE    ,
       DEPARTEMENT_ID, SALAIRE_EMPLOYE
  FROM dbo.TB_EMPLOYES
 WHERE AGE_EMPLOYE BETWEEN 20 AND 40;

Le r�sultat sera le suivant :

Ce r�sultat, peut �tre plac� dans un � FROM �, comme nous l�avons vu plus haut.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 SELECT *
  FROM (
         SELECT NOM_EMPLOYE   , AGE_EMPLOYE    ,
                DEPARTEMENT_ID, SALAIRE_EMPLOYE
           FROM dbo.TB_EMPLOYES
          WHERE AGE_EMPLOYE BETWEEN 20 AND 40 ) TD
 WHERE SALAIRE_EMPLOYE > 2000

Si nous appliquons un filtre, on peut constater que certaines lignes vont �tre ignor�es par l�application de la condition sur le salaire.

De fa�on simplifi�e, voici comment on exploite une Table D�riv�e. Nous pouvons aussi rajouter des jointures sur ces tables, puisque, le principe est de pouvoir les exploiter exactement comme s'il s�agissait d�un �l�ment physique de votre base. (Vue, table).

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
SELECT NOM_EMPLOYE, NOM_DEPARTEMENT, AGE_EMPLOYE
  FROM (
         SELECT NOM_EMPLOYE   , AGE_EMPLOYE    ,
                DEPARTEMENT_ID, SALAIRE_EMPLOYE
           FROM dbo.TB_EMPLOYES
          WHERE AGE_EMPLOYE BETWEEN 20 AND 40 ) TD
        INNER JOIN dbo.TB_DEPARTEMENTS D ON TD.DEPARTEMENT_ID = D.ID_DEPARTEMENT --Ici, la jointure se fait sur le résultat de la TD et sur l'ID_DEPARTEMENT de la table TB_DEPARTEMENT

Le r�sultat montre bien que la jointure se fait exactement de la m�me fa�on que sur une requ�te � classique �.
Maintenant, refaisons le m�me exercice, avec les CTE

D�finition

Une CTE (ou Table d�Expression Commune) est une requ�te utilis�e en tant que table � � usage unique �. C�est-�-dire qu�une fois d�clar�e, la CTE ne pourra �tre exploit�e qu�imm�diatement apr�s.
Ex. :

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
;WITH maCTE AS (
SELECT *
  FROM maTable )
 
SELECT *
  FROM maCTE;

Si la moindre instruction SQL se glisse entre votre CTE et votre requ�te l�exploitant, une erreur de syntaxe sera renvoy�e.

Il est cependant possible d�encha�ner plusieurs CTE en les s�parant par une virgule et d�exploiter toutes ces CTE depuis une m�me requ�te situ�e imm�diatement sous votre code.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
;WITH maCTE AS (
SELECT *
  FROM maTable )
, maCTE2 AS (
SELECT *
  FROM maTable )
 
SELECT *
  FROM maCTE
       INNER JOIN maCTE2 ON maCTE.Clé = maCTE2.Clé2;

N. B. Une CTE peut aussi en appeler une autre situ�e au-dessus dans le code.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
;WITH maCTE AS (
SELECT *
  FROM maTable )
, maCTE2 AS (
SELECT *
  FROM maCTE
       INNER JOIN maTable2 ON maCTE.Clé = maTable2.Clé2 )
 
SELECT *
  FROM maCTE2

L�utilit� des CTE r�side � mon humble avis, dans cette capacit� de pouvoir organiser votre code en blocs sans surco�t au niveau des plans d�ex�cution. Une �criture claire avec des petits blocs sp�cifiques vous permet d�intervenir ais�ment sur une portion pr�cise sans avoir � revisiter tout votre code.

Attention, l�effet pervers de la multiplicit� des petites requ�tes peut finalement rendre illisible votre code, � chacun de trouver le bon compromis.
Bien entendu, leur utilit� ne s�arr�te pas l�. Nous d�taillerons dans un prochain billet une utilisation avanc�e des CTE avec la r�cursion et les calculs hi�rarchiques.

Cas Pratique

Comme pour les tables d�riv�es, nous allons voir comment nous pouvons l�utiliser de fa�on rudimentaire.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
;WITH maCTE AS ( --maCTE pour l'exemple, mais comme pour les TD, je recommande un nom explicite.
SELECT FirstName, LastName
  FROM dbo.TB_EMPLOYES
)
SELECT *
  FROM maCTE --Appel à la CTE de la même façon que si c'était une table
 WHERE Nom = 'toto';

N. B. Il n�y a aucune diff�rence en termes de performance entre ces deux proc�d�s.
N.B. Une CTE ne peut fonctionner que si la pr�c�dente instruction se termine par un � ; � Personnellement, je le colle toujours devant la balise WITH.

Cas Pratique

Reprenons notre code pr�c�dent et utilisons une CTE.
Nous obtenons donc ceci :

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
;WITH maCTE AS (
SELECT NOM_EMPLOYE   , AGE_EMPLOYE    ,
       DEPARTEMENT_ID, SALAIRE_EMPLOYE
  FROM dbo.TB_EMPLOYES
 WHERE AGE_EMPLOYE BETWEEN 20 AND 40 )
 
SELECT *
  FROM maCTE
 WHERE SALAIRE_EMPLOYE > 2000;

Le r�sultat, comme pr�vu est exactement le m�me qu�avec une TD :

De m�me, les jointures s��tablissent de fa�on naturelle.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
;WITH maCTE AS (
SELECT NOM_EMPLOYE   , AGE_EMPLOYE    ,
       DEPARTEMENT_ID, SALAIRE_EMPLOYE
  FROM dbo.TB_EMPLOYES
 WHERE AGE_EMPLOYE BETWEEN 20 AND 40 )
 
SELECT *
  FROM maCTE
       INNER JOIN dbo.TB_DEPARTEMENTS D ON maCTE.DEPARTEMENT_ID = D.ID_DEPARTEMENT

Nous voyons donc que notre requ�te finale se simplifie et que notre code peut �tre facilement identifiable.

Un nom de CTE Explicite
Quelques commentaires pour faciliter la lecture
Un nombre raisonnable de niveaux de CTE

Et vous aurez toutes les cl�s pour r�ussir une proc�dure stock�e performante et maintenable ! (Par vous, comme par d�autres personnes.)

L'historisation de donn�es via la fonction MERGE

Lyche — Tue, 03 May 2016 07:47:25 GMT

Pr�sentation

Ce document pr�sente une technique de gestion des historiques de donn�es assez particuli�re : le MERGE combin� � la clause OUTPUT. Microsoft a impl�ment� le MERGE, pr�sente dans les normes SQL depuis 2003 et revue en 2008, � partir de SQL Server 2008.
Cette fonctionnalit� regroupe 3 fonctions SQL de base : INSERT, UPDATE, DELETE.

Le MERGE

Cette fonctionnalit� permet de manager en une seule instruction SQL l�ensemble des mouvements possibles sur une table, souvent nomm�e � TARGET � ou � T �. La source de la modification peut �tre une requ�te, une vue ou un CTE (Common Table Expression). En fonction des jointures d�finies entre la TARGET et la SOURCE, le MERGE permet de d�finir les lignes � ins�rer, mettre � jour ou supprimer.

Il est � noter qu�il est possible de compl�ter le crit�re de jointure de base, (d�finissant la relation entre la TARGET et la SOURCE) dans la clause (NOT) MATCH d�un filtre, ce qui offre l'avantage d��tre tr�s pr�cis sur les actions � entreprendre. Il sera, par exemple, possible de choisir un crit�re pour mettre � jour une ligne et pas une autre.
Il est aussi envisageable de filtrer les lignes � supprimer ; les autres donn�es, pourront �tre ins�r�es ou ignor�es, au choix (bien qu'ignorer des donn�es rel�ve d'une mauvaise application des r�gles dans la source).

La syntaxe du MERGE est :

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
MERGE INTO [base].[schema].[table] AS TARGET
USING ( SELECT *
          FROM maSource ) AS SOURCE ON TARGET.Clé = SOURCE.Clé
 WHEN MATCHED THEN UPDATE
  SET Champ1 = SOURCE.Champ1
    , Champ2 = SOURCE.Champ2
 WHEN NOT MATCHED THEN
INSERT (        Champ1,        Champ2,        Champ3 )
VALUES ( SOURCE.Champ1, SOURCE.Champ2, SOURCE.Champ3 );

Cette forme est la construction la plus simple du MERGE. Il est � noter qu�un MATCHED ne fonctionne qu�une seule fois par action effectu�e. (UPDATE ou DELETE)

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
WHEN MATCHED AND Champ3 = 'OK' THEN UPDATE
 SET Champ1 = SOURCE.Champ1
   , Champ2 = SOURCE.Champ2

Ainsi, il est permis de g�rer plusieurs r�gles en une seule fois. Ce gain de temps d'�criture de code ainsi qu�une optimisation du processus maintiennent le principe ensembliste des SGBDR comme SQL Server.

Ce principe de clauses particuli�res permet aussi de cibler certaines lignes afin de les supprimer.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 WHEN MATCHED AND Champ3 = 'DEL' THEN
 DELETE

Avantages du MERGE
Cette fonctionnalit� peut rapidement devenir essentielle lors de traitements de grosses volum�tries. Les processus respectant les normes SQL sont optimis�s et exploitent pleinement les possibilit�s des moteurs SGBD. Un MERGE bien maitris� vous ouvrira les portes de proc�dures multi-t�ches et efficaces !

Cas Pratique
Observons comment se d�roule une requ�te MERGE. Commen�ons par une structure de base :

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE DATABASE TrainningMERGE;
GO
USE TrainningMERGE;
GO
 
CREATE TABLE dbo.TableMERGE(
  Id Int IDENTITY( 1, 1 )
, Nom VarChar( 50 )
, Prenom VarChar( 50 )
, TypeAction CHAR( 3 ) );
GO
 
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('jean'    , 'valjean', 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('pierre'  , 'dupont' , 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('capitain', 'haddock', 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('hamza'   , 'hamzawi', 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('sarra'   , 'alfane' , 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('jean'    , 'valjean', 'DEL' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('pierre'  , 'dupont' , 'DEL' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('capitain', 'haddock', 'DEL' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('hamza'   , 'hamzawi', 'DEL' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('sarra'   , 'alfane' , 'DEL' );
GO

Ensuite, le MERGE.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
--La requête de la source met la première lettre du Nom et du Prénom en capitale.
MERGE INTO dbo.Table MERGE AS Target
USING ( SELECT Id,
               UPPER( LEFT( Nom, 1 ) ) + RIGHT( Nom, LEN( Nom ) -1 )          AS Nom   ,
               UPPER( LEFT( Prenom, 1 ) ) + RIGHT( Prenom, LEN( Prenom ) -1 ) AS Prenom
          FROM dbo.TableMERGE
         UNION
        SELECT NULL, 'Isabelle', 'Hupert' UNION
        SELECT NULL, 'Hind'    , 'Affane' UNION
        SELECT NULL, 'Baptiste', 'Durand' UNION
        SELECT NULL, 'Joseph'  , 'Bardin' UNION
        SELECT NULL, 'Clément' , 'Grenier') AS Source
 ON Target.Id = Source.ID
 WHEN MATCHED AND Target.TypeAction = 'MAJ' THEN UPDATE
 SET Nom        = Source.Nom
   , Prenom     = Source.Prenom
   , TypeAction = 'TER' --Comme Terminé
 WHEN MATCHED AND Target.TypeAction = 'DEL' THEN
 DELETE
 WHEN NOT MATCHED THEN
 INSERT (        Nom,        Prenom, TypeAction )
 VALUES ( Source.Nom, Source.Prenom,      'INS' )
 ;

Nb : Un MERGE doit imp�rativement se terminer par un ";" sinon SQL Server d�clare une erreur.

Ici, notre but est de mettre la premi�re lettre des Noms/Pr�nom en Majuscule, de supprimer les lignes en double et d�ins�rer de nouvelles personnes dans la table !
Pour faciliter la lecture, les marqueurs sont volontairement simples. �DEL� pour des donn�es � supprimer �MAJ� pour les donn�es � mettre � jour, les UNION dans la requ�te source ajoutent les donn�es non-existantes dans la table.
Vous pouvez constater avec un SELECT de la table qu�il y a bien 10 lignes, les 5 premi�res avec des majuscules en premi�re lettre, une action = �TER� et de nouvelles lignes avec une action � �INS�.
Les autres lignes, celles avec l�action �DEL�, ont �t� supprim�es !

La Clause OUTPUT

Nous venons de voir les fonctionnalit�s de base du MERGE, � savoir repr�senter en une seule grande fonction, le principe de base des SGBDR : manager les donn�es dans les tables. Cependant, certains projets n�cessitent un peu plus que de simples INSERT, DELETE et UPDATE. Il faut parfois faire des historisations des donn�es en conservant toutes les traces d��volution de celles-ci. Chaque modification ou suppression doit �tre enregistr�e, dat�e et caract�ris�e. Afin de simplifier ce genre de processus, les triggers, bien que consommateurs de ressources, sont utiles. Ils permettent de travailler via des tables de session (INSERTED, DELETED). Cependant, SQL Server a implant� une fonctionnalit� tr�s pratique, la clause OUTPUT. Elle permet d�extraire d�une requ�te les donn�es qui ont �t� calcul�es ou mises en forme. Qu�est-ce que �a signifie ? Simplement qu�une requ�te, � laquelle on ajoute cette clause, pr�sente les donn�es qu�elle vient de traiter pour les envoyer dans une autre table.

Voici l�exemple d�un SELECT INSERT qui d�verse les donn�es trait�es dans une table clone qui permet, par exemple, de traiter en arri�re-plan de grosses volum�tries, tout en laissant la table courante libre de tout verrouillage.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
INSERT INTO [schema].[maTable]
SELECT *
OUTPUT INSERTED.*
  INTO [schema].[maTable3]
  FROM [schema].[maTable2];

Cette clause peut aussi �tre plac�e dans un UPDATE.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
UPDATE [schema].[maTable]
   SET Champ1 = [s].[Champ1]
     , Champ2 = [s].[Champ2]
OUTPUT DELETED.*, GETDATE
  INTO [schema].[maTable_HST]
  FROM [schema].[maTable2] AS [s]
 WHERE [schema].[maTable].Clé = [s].Clé;

Ici, la clause OUTPUT extrait les donn�es de [schema].[maTable] avant modification et les exporte dans une table d�historique, clone de la table mise � jour et poss�dant une colonne de date d�historisation. Cette fa�on d�historiser permet de manager de fa�on efficace, l�ensemble des donn�es impact�es par un traitement. �videmment tout ceci a un co�t, mais reste moindre par rapport � l'utilisation de 2 requ�tes 1 premi�re qui va sauvegarder les donn�es et une 2�me pour traiter les nouvelles.

Ceci peut aussi s�appliquer � une clause DELETE.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
DELETE
OUTPUT DELETED.*, GETDATE()
  INTO [schema].[maTable_HST]
  FROM [schema].[maTable];

Dans ce cas, les donn�es supprim�es de la table sont aussi historis�es.

Clause OUTPUT et MERGE

Cette fonctionnalit�, tr�s utile, a aussi �t� impl�ment�e avec un MERGE. L�avantage r�side dans le fait de pouvoir manager chacune des actions entreprises sur la table en pr�cisant l'action appliqu�e.
Cependant, la forme diff�re un peu. La structure d�un MERGE �tant totalement diff�rente des 3 exemples ci-dessus, il est important de noter, qu�une clause OUTPUT dans un MERGE, n�est pas simplement compos�e de 2 lignes, mais permet cependant plus de souplesse quant aux donn�es historis�es.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
INSERT INTO [schema].[table_HST]
SELECT *
  FROM (
 
MERGE INTO [schema].[table] AS TARGET
USING ( SELECT *
          FROM maSource ) AS SOURCE ON TARGET.Clé = SOURCE.Clé
WHEN MATCHED THEN UPDATE
  SET Champ1 = SOURCE.Champ1
    , Champ2 = SOURCE.Champ2
 WHEN NOT MATCHED THEN
INSERT (        Champ1,        Champ2,        Champ3 )
VALUES ( SOURCE.Champ1, SOURCE.Champ2, SOURCE.Champ3 )
OUTPUT DELETED.*, GETDATE(), $Action
 
) MERGE_Out(Champ1, Champ2, Champ3, Date_Traitement, Actions);

Comme vous pouvez le constater, l�OUTPUT du MERGE est en fait une encapsulation de ce dernier dans un INSERT SELECT. On va consid�rer le jeu de donn�es ressorties par le MERGE comme une requ�te source (ou table d�riv�e) et s�en servir dans un SELECT. Il est alors possible d�effectuer divers traitements, comme des filtres sur les actions effectu�es.
Nb : La fonction $Action li�e � une clause OUTPUT indique l'action effectu�e par le MERGE sur la ligne en question.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

WHERE Actions IN ( 'UPDATE', 'DELETE' )

Dans ce cas, seules les donn�es mises � jour et supprim�es sont histori�es. Cependant, il serait tout aussi possible d�utiliser la table INSERTED, ou SOURCE dans le OUTPUT pour ressortir les nouvelles donn�es et les historiser. Tout d�pend de votre projet.

Cas Pratique

Nous avons vu un peu plus haut un MERGE classique. Maintenant, mettons en application ce que nous venons d�aborder.
Avant tout, cr�ons une structure capable de recevoir nos donn�es ! Puis, supprimons les donn�es de notre table d�origine et r�ins�rons-les.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE TABLE dbo.TableMERGE_HISTO(
  Id Int
, Nom VarChar( 50 )
, Prenom VarChar( 50 )
, TypeAction CHAR( 3 )
, DateHisto DateTimeOffset( 5 )
, ActionHisto VarChar( 10 ) );
--La requête de la source met la première lettre du Nom et du Prenom en capital.
 
TRUNCATE TABLE dbo.TableMERGE; --Pour repartir sur un jeu de données vierge, un truncate de la table puis une insertion des données est a faire
GO
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('jean'    , 'valjean', 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('pierre'  , 'dupont' , 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('capitain', 'haddock', 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('hamza'   , 'hamzawi', 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('sarra'   , 'alfane' , 'MAJ' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('jean'    , 'valjean', 'DEL' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('pierre'  , 'dupont' , 'DEL' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('capitain', 'haddock', 'DEL' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('hamza'   , 'hamzawi', 'DEL' );
INSERT INTO dbo.TableMERGE( Nom, Prenom, TypeAction )VALUES ('sarra'   , 'alfane' , 'DEL' );
GO

Maintenant, voyons comment, � partir de la requ�te MERGE du dessus, nous pouvons supprimer, et mettre � jour, tout en conservant l�information des donn�es que nous avons touch�es dans une table. Le tout, en une seule et unique requ�te ! (apr�s tout, nous sommes l� pour �a !)

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
INSERT INTO dbo.TableMERGE_HISTO( Id, Nom, Prenom, TypeAction, DateHisto, ActionHisto )
SELECT *
  FROM (
MERGE INTO dbo.TableMERGE AS Target
USING ( SELECT Id,
               UPPER( LEFT( Nom, 1 ) ) + RIGHT( Nom, LEN( Nom ) -1 )          AS Nom   ,
               UPPER( LEFT( Prenom, 1 ) ) + RIGHT( Prenom, LEN( Prenom ) -1 ) AS Prenom
          FROM dbo.TableMERGE
         UNION
        SELECT NULL, 'Isabelle', 'Hupert' UNION
        SELECT NULL, 'Hind'    , 'Affane' UNION
        SELECT NULL, 'Baptiste', 'Durand' UNION
        SELECT NULL, 'Joseph'  , 'Bardin' UNION
        SELECT NULL, 'Clément' , 'Grenier') AS Source
 ON Target.Id = Source.ID
 WHEN MATCHED AND Target.TypeAction = 'MAJ' THEN UPDATE
 SET Nom        = Source.Nom
   , Prenom     = Source.Prenom
   , TypeAction = 'TER' --Comme Terminé
 WHEN MATCHED AND Target.TypeAction = 'DEL' THEN
 DELETE
 WHEN NOT MATCHED THEN
 INSERT (        Nom,        Prenom, TypeAction )
 VALUES ( Source.Nom, Source.Prenom,      'INS' )
 OUTPUT DELETED.*, GETUTCDATE(), $Action
 ) AS Output_MERGE ( Id, Nom, Prenom, TypeAction, DateHisto, Actions )
 WHERE Actions IN ( 'DELETE', 'UPDATE' )
 ;

Faites maintenant, un SELECT sur votre table d�historique ainsi que sur votre table mise � jour. Le r�sultat est le m�me pour la table d�origine, mais vous pourrez constater dans la table d�historique que les lignes supprim�es sont l�, et que les lignes mises � jour sont l� avec la valeur pr�sente dans la table AVANT la mise � jour.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
SELECT *
   FROM dbo.TableMERGE_HISTO

Ainsi, voici comment g�rer une table tout en conservant les donn�es que nous avons modifi�es.

Conclusion
SQL est un moyen de traiter de fa�on efficace de grosses volum�tries de donn�es sans syst�matiquement n�cessiter d'�normes capacit�s de calcul.

Toutefois, l�utilisation d�un OUTPUT n�cessite une v�rification des volum�tries des bases. En effet, g�rer un historique complet des mouvements d�une table peut poser des probl�mes de stockage, pouvant entra�ner des co�ts consid�rables.
Dans un projet BI, cette probl�matique est r�currente et il est essentiel de bien r�fl�chir � la fa�on dont l�historisation des tables sera g�r�e : TRIGGER, ETL ou fonction MERGE.
Bons projets � vous.

L�agr�gation de donn�es

Lyche — Tue, 26 Apr 2016 12:59:34 GMT

Fonction de totaux et sous-totaux

Pr�sentation

Les bases de donn�es de Business Intelligence sont confront�es � des probl�matiques r�currentes de calculs, de statistiques, ou de diverses agr�gations de donn�es. Beaucoup s�imaginent que faire des sommes et autres moyennes de notes n�est qu�appliquer de simples formules math�matiques. Or, lorsqu�il s�agit de bases de donn�es, ces calculs prennent une autre dimension, dont la complexit� d�pend des r�gles de gestion et du besoin client.

Les Agr�gations

Les agr�gations, malgr� ce nom un peu effrayant, sont de simples calculs math�matiques. Le tableau, ci-dessous, pr�sente les fonctions d�agr�gation les plus communes.

Fonction	Sert �
AVG()	Calculer la moyenne des valeurs agr�g�es
COUNT()	Calculer le nombre de lignes
MAX()	R�cup�rer la valeur maximum d'une colonne
MIN()	R�cup�rer la valeur minimum d'une colonne
SUM()	Calculer la somme des valeurs de la colonne

Cas pratique

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
;WITH ListUsers AS (
SELECT *
  FROM ( VALUES( 1, 'Georges', 74 ),
               ( 2, 'Pierre' , 17 ),
               ( 3, 'Bernard', 63 ),
               ( 4, 'John'   , 23 ) ) AS Users( Id, Nom, Age ) )
 
SELECT SUM( Age ) AS [Somme_Age]
     , AVG( Age ) AS [Moyenne_Age]
     , MIN( Age ) AS [Age_Minimum]
     , MAX( Age ) AS [Age_Maximum]
     , COUNT( * ) AS [Nombre_Users]
  FROM ListUsers

Cet exemple utilise un jeu de donn�es assez simple : une liste de personnes avec leur �ge, sur lequel sont faits les diff�rents calculs requis. En premier, la somme des �ges, ensuite la moyenne d��ge, puis le plus jeune, le plus vieux et enfin le nombre de lignes dans notre jeu de donn�es.
GROUP BY

Ces fonctionnalit�s ne sont pas difficiles � comprendre. Ce qui peut compliquer la t�che, c�est la difficult� d�associer un certain nombre de colonnes � des calculs sp�cifiques. Ce que l�on nommera le groupement de donn�es, (GROUP BY en langage SQL)
Cette fonctionnalit� de la norme SQL permet de d�finir des �l�ments communs de regroupement de l�information.
Avant de rentrer dans le texte un peu th�orique, pas toujours clair et parfois difficile � comprendre, un petit cas pratique.
Cas pratique

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
CREATE TABLE dbo.TB_DEPARTEMENTS (
  ID_DEPARTEMENT  INT PRIMARY KEY
, NOM_DEPARTEMENT VARCHAR( 50 ) );
GO
 
CREATE TABLE dbo.TB_EMPLOYES (
  ID_EMPLOYE      INT PRIMARY KEY
, NOM_EMPLOYE     VARCHAR( 50 ) NOT NULL
, AGE_EMPLOYE     INT
, DEPARTEMENT_ID  INT
, SALAIRE_EMPLOYE MONEY );
GO
 
INSERT INTO dbo.TB_DEPARTEMENTS
VALUES( 1, 'Administration'       );
INSERT INTO dbo.TB_DEPARTEMENTS
VALUES( 2, 'Ressources Humaines'  );
INSERT INTO dbo.TB_DEPARTEMENTS
VALUES( 3, 'Service Informatique' );
INSERT INTO dbo.TB_DEPARTEMENTS
VALUES( 4, 'Comptabilité'         );
 
INSERT INTO dbo.TB_EMPLOYES
VALUES( 1, 'Georges', 74, 4, 2480.3 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 2, 'Pierre' , 17, 3, 1387.2 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 3, 'Bernard', 63, 1, 3499.8 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 4, 'John'   , 23, 3, 1876.9 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 5, 'Jérome' , 45, 2, 2286.6 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 6, 'Lina', 30, 3, 2230.4 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 7, 'Marie', 26, 3, 1980.4 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 8, 'Virginie', 37, 3, 2730.4 );
INSERT INTO dbo.TB_EMPLOYES
VALUES( 9, 'Hélène', 33, 3, 2430.4 );

Les commandes ci-dessus cr�ent 2 tables employ�s/d�partements li�es par l�id_departement.
Nous sommes ici dans le cadre d�une entreprise qui va vouloir faire quelques statistiques sur ses employ�s.
1 � Faire la somme des salaires par d�partement.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
SELECT NOM_DEPARTEMENT
     , SUM( SALAIRE_EMPLOYE ) AS TOTAL_SALAIRE
  FROM dbo.TB_EMPLOYES E
       INNER JOIN dbo.TB_DEPARTEMENTS D ON E.DEPARTEMENT_ID = D.ID_DEPARTEMENT
 GROUP BY NOM_DEPARTEMENT

Vous pourrez remarquer l�emploi de la fonction GROUP BY, associ�e � la colonne NOM_DEPARTEMENT.
Vous constaterez que la valeur de la colonne TOTAL_SALAIRE est �gale � la somme totale des salaires saisis pour la liste des employ�s.
Explication

Au niveau du SGBD, la commande lui ordonne de sommer la colonne salaire et de faire ce calcul par nom de d�partement (donc, de regrouper les informations identiques en une seule ligne).
Nous nous retrouvons donc avec nos 4 d�partements et leur budget mensuel respectifs.
Nous pourrions faire exactement les m�mes calculs que dans la premi�re partie de notre billet.
2 � Calculer la moyenne des salaires, le salaire minimum et maximum, ainsi que le nombre d�employ�s par d�partement

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
SELECT NOM_DEPARTEMENT
     , SUM( SALAIRE_EMPLOYE ) AS TOTAL_SALAIRE
     , AVG( SALAIRE_EMPLOYE ) AS MOYENNE_SALAIRE
     , MAX( SALAIRE_EMPLOYE ) AS SALAIRE_MAXIMUM
     , MIN( SALAIRE_EMPLOYE ) AS SALAIRE_MINIMUM
     , COUNT( * )             AS TOTAL_EMPLOYE
  FROM dbo.TB_EMPLOYES E
       INNER JOIN dbo.TB_DEPARTEMENTS D ON E.DEPARTEMENT_ID = D.ID_DEPARTEMENT
 GROUP BY NOM_DEPARTEMENT

Ici, en �tudiant, on constate certains �carts, notamment au niveau du service informatique l� o� il y a plusieurs employ�s.

La requ�te permet ici de calculer plusieurs types d�informations bas�es sur le NOM_DEPARTEMENT comme crit�re commun.

Important :
Il m�est souvent arriv� d�avoir des demandes concernant des requ�tes � fausses � � cause d�une mauvaise gestion du GROUP BY. Pour faire au plus simple quant � sa pratique, il faut savoir que toute colonne se trouvant dans un select et n�appartenant pas � une fonction d�agr�gation, doit se retrouver dans la clause du GROUP BY.
Ce qui est le plus difficile, c�est l�identification des champs du select hors agr�gat. Il est parfois n�cessaire de retourner la question pos�e (ou la RG) afin d��tre le plus pr�cis possible sur les champs.

� noter qu�il est possible d�agr�ger des donn�es sur le r�sultat d�une fonction.

Exemple

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
 
CREATE TABLE dbo.INTERVENTION_CLIENT (
  ID_INTERVENTION   INT PRIMARY KEY
, DATE_INTERVENTION Date
, NOM_CLIENT        VARCHAR( 50 )
, EMPLOYE_ID        INT
, FACTURATION       Money )
 
 
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  1, '2014-01-02', 'Client 1', 2, 500 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  2, '2014-01-03', 'Client 1', 2, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  3, '2014-01-06', 'Client 1', 2, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  4, '2014-01-07', 'Client 1', 2, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  5, '2014-01-08', 'Client 1', 2, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  6, '2014-01-09', 'Client 1', 2, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  7, '2014-01-10', 'Client 1', 2, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  8, '2014-01-03', 'Client 1', 4, 400 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES(  9, '2014-01-04', 'Client 1', 4, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 10, '2014-01-06', 'Client 1', 4, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 11, '2014-01-07', 'Client 1', 4, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 12, '2014-01-08', 'Client 1', 4, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 13, '2014-01-03', 'Client 2', 6, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 14, '2014-01-04', 'Client 2', 6, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 15, '2014-01-06', 'Client 2', 6, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 16, '2014-01-07', 'Client 2', 6, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 17, '2014-01-08', 'Client 2', 6, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 18, '2014-01-09', 'Client 2', 6, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 19, '2014-01-10', 'Client 2', 6, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 20, '2014-01-06', 'Client 3', 7, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 21, '2014-01-07', 'Client 3', 7, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 22, '2014-01-08', 'Client 3', 7, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 23, '2014-01-09', 'Client 3', 7, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 24, '2014-01-10', 'Client 3', 7, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 25, '2014-01-06', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 26, '2014-01-07', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 27, '2014-01-08', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 28, '2014-01-09', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 29, '2014-01-10', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 30, '2014-01-03', 'Client 4', 9, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 31, '2014-01-06', 'Client 4', 9, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 32, '2014-01-07', 'Client 4', 9, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 33, '2014-01-08', 'Client 4', 9, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 34, '2014-01-09', 'Client 4', 9, 650 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 35, '2014-01-10', 'Client 4', 9, 650 );

Nous cr�ons ici un ensemble de lignes d�intervention de nos collaborateurs chez les clients. Nous souhaitons avoir des informations sur les mois de travail.

Quelle est la somme des facturations de nos collaborateurs pour les mois �coul�s, sans tenir compte du lieu de l�intervention ?

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
SELECT NOM_EMPLOYE
     , MONTH( DATE_INTERVENTION ) AS [MOIS_INTERVENTION]
     , SUM( FACTURATION )         AS [SOMME_FACTUREE]
  FROM dbo.TB_EMPLOYES E
       INNER JOIN dbo.INTERVENTION_CLIENT I ON E.ID_EMPLOYE = I.EMPLOYE_ID
 GROUP BY NOM_EMPLOYE, MONTH( DATE_INTERVENTION );

Nous avons pris en compte 3 �l�ments de la demande.

Mois d�Intervention
Collaborateur
Somme des facturations.

Ces 3 informations permettent d�identifier le groupement n�cessaire ainsi que l�agr�gation souhait�e.

Nous nous retrouvons avec la fonction MONTH(), qui permet de ressortir le mois d�une date, dans le select. Contrairement au ORDER BY qui peut fonctionner avec la position du champ dans le select, GROUP BY n�cessite de reproduire exactement les m�mes commandes que lors du SELECT.

Pour faciliter l��criture d�un GROUP BY, une CTE, une table D�riv�e ou une l�utilisation d�une vue, sont de bonnes solutions.

La clause HAVING

Maintenant que nous savons faire un groupement de donn�es afin de l�agr�ger, nous allons voir comment exploiter le r�sultat de notre groupement et comment limiter les r�sultats � nos attentes.
Nous l�avons vu plus haut, il est possible de calculer des sommes d�interventions d�une personne, maintenant, imaginons que les consultants envoy�s en missions ont un co�t pour l�entreprise. Ce co�t, c�est le salaire.
A partir de ces deux informations que sont le salaire et les interventions, nous pouvons en d�duire quel consultant est � rentable � ou non, et pour ce faire, il nous est possible de faire des comparaisons entre la valeur d�un champ (ou le r�sultat d�une requ�te)

A partir de notre jeu de donn�es, nous allons faire un test.

Nous savons que nous avons pu facturer nos prestataires � diff�rents clients au cours du mois. Cependant, est-ce que ces personnes nous rapportent suffisamment par rapport � leur salaire, ou serait-il n�cessaire de leur trouver plus de mission. Ou bien faut-il facturer plus les clients ?

Nous connaissons le salaire des employ�s, et nous venons de calculer la valeur de leurs diff�rentes interventions.
Cependant, qu�en est-il de ce qu�ils rapportent � l�entreprise ?

Nous allons utiliser la fonction HAVING. Elle doit nous permettre de comparer le r�sultat d�un groupement � une valeur fixe.

Pour ce faire, reprenons notre pr�c�dente requ�te et ajoutons la clause.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
SELECT NOM_EMPLOYE
     , MONTH( DATE_INTERVENTION ) AS [MOIS_INTERVENTION]
     , SUM( FACTURATION )         AS [SOMME_FACTUREE]
  FROM dbo.TB_EMPLOYES E
       INNER JOIN dbo.INTERVENTION_CLIENT I ON E.ID_EMPLOYE = I.EMPLOYE_ID
 GROUP BY NOM_EMPLOYE, SALAIRE_EMPLOYE, MONTH( DATE_INTERVENTION )
 HAVING SUM( FACTURATION ) > SALAIRE_EMPLOYE;

Vous pourrez constater que le groupement devient quelque peu diff�rent. En effet, l�ajout du SALAIRE_EMPLOYE dans le groupement devient obligatoire si l�on souhaite le comparer. Pourquoi ?
Comme expliqu� plus haut, toute colonne utilis�e dans la requ�te et n��tant pas soumise � un agr�gat doit obligatoirement se trouver dans le groupement.
J�ai besoin de comparer le SALAIRE � la somme des facturations. Il me faut donc d�finir le SALAIRE comme une donn�e non agr�g�e.

Le r�sultat est sans appel ! Il manque John � l�appel des personnes � rentables �. Qu�� cela ne tienne, on facturera de la m�me fa�on que les autres ;)

Maintenant que l�on a vu les fonctionnalit�s de base des groupements, nous allons voir quelques fonctionnalit�s avanc�es qui devraient vous faciliter la vie pour les rapports.

GROUP BY ROLLUP

Nous l�avons vu, GROUP BY est une fonction assez simple qui agr�ge les donn�es sur des crit�res sp�cifiques mais ne donne pas de d�tails ni ne fait de sommes particuli�res.

Nous allons compl�ter notre jeu de donn�es avec des interventions sur un nouveau mois.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 36, '2014-02-03', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 37, '2014-02-04', 'Client 1', 2, 500 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 38, '2014-02-05', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 39, '2014-02-06', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 40, '2014-02-07', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 41, '2014-02-10', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 42, '2014-02-11', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 43, '2014-02-12', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 44, '2014-02-13', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 45, '2014-02-14', 'Client 1', 2, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 46, '2014-02-03', 'Client 1', 4, 400 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 47, '2014-02-04', 'Client 1', 4, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 48, '2014-02-05', 'Client 1', 4, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 49, '2014-02-06', 'Client 1', 4, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 50, '2014-02-07', 'Client 1', 4, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 51, '2014-02-03', 'Client 2', 6, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 52, '2014-02-04', 'Client 2', 6, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 53, '2014-02-05', 'Client 2', 6, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 54, '2014-02-06', 'Client 2', 6, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 55, '2014-02-07', 'Client 2', 6, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 56, '2014-02-10', 'Client 2', 6, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 57, '2014-02-19', 'Client 2', 6, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 58, '2014-02-06', 'Client 3', 7, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 59, '2014-02-07', 'Client 3', 7, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 60, '2014-02-10', 'Client 3', 7, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 61, '2014-02-11', 'Client 3', 7, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 62, '2014-02-12', 'Client 3', 7, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 63, '2014-02-06', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 64, '2014-02-07', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 65, '2014-02-10', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 66, '2014-02-11', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 67, '2014-02-12', 'Client 3', 8, 700 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 68, '2014-02-03', 'Client 4', 9, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 69, '2014-02-06', 'Client 4', 9, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 70, '2014-02-07', 'Client 4', 9, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 71, '2014-02-10', 'Client 4', 9, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 72, '2014-02-11', 'Client 4', 9, 750 );
INSERT INTO dbo.INTERVENTION_CLIENT
VALUES( 73, '2014-02-12', 'Client 4', 9, 750 );

Nous voici donc avec un jeu de donn�es pour janvier et f�vrier. Si l�on refait la requ�te pr�c�dente, nous aurons de nouvelles lignes dans le tableau.

Nous observons bien les 2 mois et les noms des employ�s associ�s � chaque mois d�intervention.

Ce total n�est pas assez pr�cis ! Il me faut le calcul annuel par employ� ET un total annuel de l�entreprise !

Le GROUP BY est, sans conteste, quelque chose de courant dans les bases de donn�es. Mais il a ses limites. La question, au-dessus, va nous poser un probl�me.
Comment pouvons nous agr�ger � diff�rents niveau dans une m�me requ�te ?

La r�ponse est � Impossible en une requ�te avec un simple GROUP BY. Pour r�aliser la demande, il nous faut 3 requ�tes que l�on va unir avec la clause UNION.

La premi�re, on l�a vu au-dessus, calcule au mois. La seconde (ci-dessous) calcule � l�employ�.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
SELECT NOM_EMPLOYE
     , 'Total'            AS [MOIS_INTERVENTION]
     , SUM( FACTURATION ) AS [SOMME_FACTUREE]
  FROM dbo.TB_EMPLOYES E
       INNER JOIN dbo.INTERVENTION_CLIENT I ON E.ID_EMPLOYE = I.EMPLOYE_ID
 GROUP BY NOM_EMPLOYE;

Cette requ�te calcul le total des interventions par utilisateur et devrait �tre unie � la pr�c�dente afin de restituer en un seul jeu de donn�es le total par utilisateur.
Enfin, une troisi�me requ�te est n�cessaire pour calculer le total global des interventions.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
SELECT 'Total'            AS NOM_EMPLOYE
     , NULL               AS [MOIS_INTERVENTION]
     , SUM( FACTURATION ) AS [SOMME_FACTUREE]
  FROM dbo.TB_EMPLOYES E
       INNER JOIN dbo.INTERVENTION_CLIENT I ON E.ID_EMPLOYE = I.EMPLOYE_ID;

Ce tableau, repr�sente l�union des 3 requ�tes

En faisant un tri sur le nom puis le mois d�intervention, il est possible d�obtenir un tableau plus coh�rent. Cependant, nous pouvons le constater, Virginie est dans l�ordre alphab�tique et se retrouve apr�s le total. Pour contourner ce probl�me, il nous faudrait rajouter une colonne avec un chiffre d�finis ce qui rajouterais encore du code !

Maintenant Le ROLLUP !

Comment cela fonctionne ? Et bien comme un GROUP BY nous citons une s�rie de colonnes � regrouper.
Dans notre cas, toujours le mois et le consultant.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
SELECT NOM_EMPLOYE
     , MONTH( DATE_INTERVENTION ) AS [MOIS_INTERVENTION]
     , SUM( FACTURATION )         AS [SOMME_FACTUREE]
  FROM dbo.TB_EMPLOYES E
       INNER JOIN dbo.INTERVENTION_CLIENT I ON E.ID_EMPLOYE = I.EMPLOYE_ID
 GROUP BY ROLLUP (NOM_EMPLOYE, MONTH( DATE_INTERVENTION ));

Vous constaterez la forme de l��criture. Nous sommes toujours dans un GROUP BY � ceci pr�s que nous pr�cisons la fonctionnalit� ROLLUP et que nous pla�ons entre () les colonnes du groupement. Pourquoi ? Simplement parce que cette fonction nous permet, en une requ�te, d�afficher plusieurs groupements diff�rents, tous s�par�s par une � , �. D�o� le besoin des parenth�ses pour permettre au SGBD de ne pas s�emm�ler les pinceaux.

Le r�sultat est imm�diat (ou presque tout d�pend des volumes et de l'optimisation de votre base!)

Le SGBD a d�j� calcul� les sous-niveaux. Un total mensuel, un total par employ� et un total !

Que fait concr�tement ROLLUP ?

Et bien, pour chaque colonne du groupement en partant de la droite il va calculer les regroupements � tous les niveaux. Dans notre cas, il calcule le groupement par PERSONNE/ANNEE puis, simplement par PERSONNE et pour finir sans groupement.
Il rassemble nos 3 requ�tes pr�c�dentes pour lesquelles j�ai d� faire une manipulation pour supprimer les colonnes en trop dans les groupements.

Comme vous pouvez le constater, les regroupements sup�rieurs n�ont pas de valeur. Il nous suffira simplement de mettre des fonctions ISNULL afin de placer les valeurs que l�on souhaite.

Code sql :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
SELECT ISNULL( NOM_EMPLOYE, 'Total Annuel' ) AS NOM_EMPLOYE
     , CASE WHEN NOM_EMPLOYE IS NULL AND MONTH( DATE_INTERVENTION ) IS NULL
            THEN NULL
            ELSE ISNULL( CAST( MONTH( DATE_INTERVENTION ) AS VARCHAR ), 'Total Mensuel' ) END AS [MOIS_INTERVENTION]
     , SUM( FACTURATION )         AS [SOMME_FACTUREE]
  FROM dbo.TB_EMPLOYES E
       INNER JOIN dbo.INTERVENTION_CLIENT I ON E.ID_EMPLOYE = I.EMPLOYE_ID
 GROUP BY ROLLUP (NOM_EMPLOYE, MONTH( DATE_INTERVENTION ));

Et voil�, comment en une requ�te on peut ressortir un tableau complet et juste !