ETL Testing

SQL Server 2000, Analysis Services et DTS
Cyril Gruau 4 mars 2004
R esum e Ce support de cours regroupe quelques notions concernant la limpl ementation et le d eveloppement de bases de donn ees avec le langage SQL, une pr esentation de la phase ETL, la construction et la consultation de cubes OLAP en langage MDX, ainsi quune introduction au data mining. Les logiciels retenus pour cette etude sont SQL Server 2000 (Microsoft), accompagn e des Analysis Services et des DTS. Les notions abord ees sont bien evidemment utilisables avec dautres syst` emes.
Mots-clef : base de donn ees, requ ete, SQL, transaction, OLTP, ETL, DTS entrep ot de donn ees, data warehouse, cube, MDX, OLAP, data mining
Compl ements apport es ` a l edition de f evrier 2003 : les illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 un nouveau paragraphe sur les requ etes multibases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 un nouveau chapitre sur les formulaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 un nouveau chapitre sur les etats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 une r e-organisation et une r e- ecriture du chapitre sur le stockage des cubes . . . . . . . . . . . . . . . . . . . 68 une r e- ecriture compl` ete du chapitre sur la phase ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 et quelques compl ements MDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Cyril.Gruau@ensmp.fr
` TABLE DES MATIERES
Table des mati` eres

Introduction 6
Le syst` eme transactionnel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10 10 11 11 11 12 12 12 13 14 14 14 14 14 15 15 15 16 17 17 18 18 20 20 21 22 22 22 24 24 24 25 25 25 26 26 27 27 27 28
1 Syntaxe du langage SQL 1.1 Commentaires . . . . . . . . . . . . 1.2 Noms . . . . . . . . . . . . . . . . 1.3 Op erateurs . . . . . . . . . . . . . 1.4 Variables . . . . . . . . . . . . . . 1.5 Structures . . . . . . . . . . . . . . 1.5.1 Blocs . . . . . . . . . . . . 1.5.2 Branchements conditionnels 1.5.3 Boucles conditionnelles . . . 2 Modes dex ecution du code 2.1 Ex ecution imm ediate . . . 2.2 Utilisation de script . . . 2.3 Ex ecution par lots . . . . 2.4 Transactions . . . . . . . 2.5 D ebogage . . . . . . . . . SQL . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
3 Mise en place dune base 3.1 Une base et son journal . . 3.2 Une table . . . . . . . . . . 3.3 Num erotation automatique 3.4 D enir les relations . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4 S electionner les donn ees 4.1 S election simple . . . . . . . . . . . . . . . . . . . . 4.2 Jointures internes . . . . . . . . . . . . . . . . . . . 4.3 Jointures externes . . . . . . . . . . . . . . . . . . 4.4 Union des s elections . . . . . . . . . . . . . . . . . 4.5 Sous-requ etes . . . . . . . . . . . . . . . . . . . . . 4.5.1 Sous-requ ete renvoyant une valeur . . . . . 4.5.2 Sous-requ ete renvoyant une liste de valeurs 4.5.3 Requ etes correl ees . . . . . . . . . . . . . . 4.5.4 Requ etes imbriqu ees vs. jointures . . . . . . 4.5.5 Sous-requ ete renvoyant plusieurs colonnes . 4.6 Requ etes multibases . . . . . . . . . . . . . . . . . 4.7 Quelques fonctions SQL . . . . . . . . . . . . . . . 4.7.1 Fonctions dagr egat . . . . . . . . . . . . . 4.7.2 Op erateurs . . . . . . . . . . . . . . . . . . 4.7.3 Fonctions sur les dates . . . . . . . . . . . . 4.7.4 Fonctions sur les cha nes de caract` eres . . . 4.7.5 Principales fonctions math ematiques . . . . 4.7.6 Fonctions utilisateur . . . . . . . . . . . . . 4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
` TABLE DES MATIERES 5 Modier les donn ees 5.1 Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Mise-` a-jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Contraintes 6.1 Syntaxe . . . . . 6.2 CHECK . . . . . . 6.2.1 Syntaxe . 6.2.2 R` egle . . 6.3 Valeur par d efaut 6.4 Cl e primaire . . . 6.5 UNIQUE . . . . . . 6.6 Cl e etrang` ere . . 6.7 Conclusion . . .
3 28 28 29 30 31 31 32 32 33 34 35 35 35 36 37 37 37 39 39 40 41 41 41 42 44 44 45 46 46 46 47 47 48 48 49 49 49 50 50 50 51 51 51 52 52 52 52
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
7 Programmation ev enementielle 7.1 Mise-` a-jour et suppression en cascade 7.2 D eclencheurs AFTER . . . . . . . . . . 7.3 D eclencheurs INSTEAD OF . . . . . . . 7.4 Compl ements . . . . . . . . . . . . . . 7.5 Conclusion . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
8 Vues 8.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Int er ets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Modication de donn ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Proc edures stock ees 9.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Cryptage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Verrous 10.1 Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Verrouillage de niveau table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Connexions 11.1 Cr eation . . . . . . . . . . . . . . 11.2 R ole . . . . . . . . . . . . . . . . 11.2.1 Sur le serveur . . . . . . . 11.2.2 Dans une base de donn ees 11.3 Droits . . . . . . . . . . . . . . . 11.3.1 Sur les instructions . . . . 11.3.2 Sur les objets . . . . . . . 11.3.3 Cha ne dautorisation . . 12 Formulaires 12.1 Historique . . . . . . . . . . . 12.2 Lien avec la base de donn ees 12.3 Validation des donn ees . . . . 12.3.1 Int egrit e de domaine . 12.3.2 Int egrit e des entit es .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
` TABLE DES MATIERES 12.3.3 Int egrit e r ef erentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.4 Int egrit e dentreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4 Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion sur la partie transactionnelle
4 53 53 54 55
II
Le syst` eme d ecisionnel
57
59 59 60 61 62 62 62 62 63 63 65 65 66 67 67 68 68 68 70 72 72 73 73 73 74 74 75 75 76 77 77 77 82 83 83 83 85 86 86 87 87
13 Agr eger les donn ees 13.1 Groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Compl ements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Edition d etats 14.1 Comparaison avec les formulaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2 Comparaison avec les requ etes GROUP BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Structurer les donn ees en cube 15.1 D enition dun cube . . . . . . 15.2 Hi erarchie . . . . . . . . . . . . 15.2.1 Niveaux . . . . . . . . . 15.2.2 Membres . . . . . . . . 15.2.3 Hi erarchies multiples . . 15.3 Normalisation dun cube . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
16 Stockage des donn ees 16.1 Sch ema relationnel de lentrep ot . . . . . . 16.1.1 Sch ema en etoile . . . . . . . . . . . 16.1.2 Sch ema en ocon . . . . . . . . . . . 16.1.3 Parent-enfant . . . . . . . . . . . . . 16.1.4 Base d ecisionnelle . . . . . . . . . . 16.2 Modes de stockage . . . . . . . . . . . . . . 16.2.1 Multidimensional OLAP (MOLAP) 16.2.2 Relational OLAP (ROLAP) . . . . . 16.2.3 Hybrid OLAP (HOLAP) . . . . . . 16.3 Niveau dagr egation . . . . . . . . . . . . . 17 Alimentation de lentrep ot 17.1 Data Transformation Services 17.2 Base tampon . . . . . . . . . 17.3 Etapes ETL . . . . . . . . . . 17.3.1 Extraction . . . . . . . 17.3.2 Transformation . . . . 17.3.3 Chargement . . . . . . 17.3.4 Traitement . . . . . . 18 Interroger un cube 18.1 Requ etes MDX . . . . 18.1.1 Clause SELECT 18.1.2 Mesures . . . . 18.1.3 Clause WHERE . 18.1.4 Description des 18.1.5 MDX vs. SQL .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
(DTS) . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . . . . axes . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
` TABLE DES MATIERES 18.2 Filtrage des donn ees . . . . . . 18.3 Disposition des r esultats . . . . 18.3.1 Ordonner les axes . . . 18.3.2 Axes pluridimensionnels 18.4 Clause WITH . . . . . . . . . . . 18.4.1 Membres calcul es . . . . 18.4.2 Jeux nomm es . . . . . . 18.4.3 Cellules calcul ees . . . . 18.4.4 Pr ecisions . . . . . . . . 18.5 Clause CELL PROPERTIES . . . 18.6 Fonctions MDX . . . . . . . . . 18.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 88 90 90 90 91 91 93 94 94 94 95 96 96 96 97 97 98 98 98 99 100 100 101 102 103 103 103 103 104 106
19 Objets virtuels 19.1 Propri et e de membre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.2 Dimension virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.3 Cube virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Exploration de donn ees 20.1 Mod` eles . . . . . . . . . . . . . 20.1.1 Clustering . . . . . . . . 20.1.2 Arbre de d ecision . . . . 20.2 Impl ementation . . . . . . . . . 20.2.1 Vocabulaire . . . . . . . 20.2.2 Pr eparation des donn ees 20.2.3 Objets suppl ementaires 20.3 Pr ediction . . . . . . . . . . . . 20.3.1 R eseau de d ependances 20.3.2 Donn ees pr evisionnelles 20.4 Conclusion . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
Conclusion sur la partie d ecisionnelle Table des gures
R ef erences 107 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Pages web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Newsgroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Index 109
INTRODUCTION
Introduction
Une base de donn ees est un objet particuli` erement dicile ` a d enir puisquil est abord e en pratique selon di erents points de vues : pour un utilisateur, une base de donn ees est un espace o` u il peut enregistrer des informations, les retrouver et les faire traiter automatiquement par un ordinateur (on retrouve l` a, l etymologie du mot informatique) ; pour un d eveloppeur, une base de donn ees est un ensemble de tables, de relations et de proc edures ecrites en SQL (Structured Query Language) ; pour un administrateur informatique, une base de donn ees est un ensemble de donn ees ` a sauvegarder et s ecuriser. Nous nous contentons ici du r ole de d eveloppeur, cela signie que nous occultons ladministration dune base de donn ees (puisquil sagit dun autre m etier) mais que nous gardons en t ete les pr eoccupations des utilisateurs (dont ce nest pas le m etier de d evelopper des bases de donn ees). Dans une base de donn ees personnelle (que lon manipule dans le logiciel Access de Microsoft par exemple), on retrouve essentiellement un sch ema o` u je suis lunique concepteur, d eveloppeur, fournisseur et analyste des donn ees (cf. gure 1).
Fig. 1 Base de donn ees personnelle
INTRODUCTION
Au contraire, dans un SGBD professionnel (de type SQL Server, Oracle, DB2 dIBM et bien dautres ) le sch ema est fondamentalement di erent : les donn ees sont fournies par plusieurs utilisateurs (parfois des milliers) ` a travers de multiples petites transactions SQL. Ces donn ees sont stock ees dans une ou plusieurs bases de production continuellement remises ` a jour par ces transactions. Cette partie amont du sch ema constitue le syst` eme transactionnel (cf. gure 2). Les donn ees sont en g en eral historis ees dans un entrep ot
quelques utilisateurs qui analysent les donnes requtes MDX
l'entrept de donnes (cubes) concepteurs, dveloppeurs, administrateurs grosses requtes SQL le systme dcisionel le systme transactionnel
les bases de donnes (tables) petites transactions SQL beaucoup d'utilisateurs qui fournissent les donnes
Fig. 2 Base de donn ees professionnelle de donn ees dont l el ement constitutif nest plus la table mais le cube. Ceci g en` ere de gros transferts entre les deux syst` emes mais les informations utiles sont plus proches des quelques utilisateurs qui ont besoin danalyser les donn ees. Cette partie aval du sch ema constitue le syst` eme d ecisionnel. Lensemble est g er e, dans lentreprise, par les concepteurs, les d eveloppeurs et les administrateurs du service informatique.
INTRODUCTION
Comme illustration nous pouvons prendre nimporte quelle entreprise qui fabrique et vend des produits (cf. gure 3). Les utilisateurs qui fournissent les donn ees sont : les vendeurs, les interlocuteurs
les managers du service commercial, du service marketing, du service logistique
cubes concernant : les ventes par vendeur et par trimestre, la production par produit et par anne l'quipe du service informatique
tables concernant : les articles, les fournisseurs, les clients, les ventes, les stocks
les vendeurs, les usines, les interlocuteurs auprs des fournisseurs
Fig. 3 Exemple de base de donn ees professionnelle aupr` es des fournisseurs et des usines. On voit bien quils peuvent etre nombreux. Les donn ees seront naturellement stock ees dans des tables concernant : les articles, les fournisseurs, les clients, les ventes et les stocks. Toutes ces informations seront regroup ees sous forme de cubes concernant notamment : les ventes par vendeur et par trimestre, la production par produit et par usine, etc. Dans cette entreprise, ces cubes sont susceptibles dint eresser les managers du service commercial, du service marketing et du service logistique. Le r ole du service informatique etant d echafauder ce syst` eme et de proposer des outils pour chaque m etier en relation avec les donn ees.
INTRODUCTION
Physiquement, le r eseau informatique concern e par le traitement des donn ees est organis e autour dun ordinateur (ou un cluster dordinateurs) equip e de SQL Server et accompagn e dune baie de disques qui ` ce serveur sont connect stockent les donn ees (cf. gure 4). A es autant de stations de travail clientes que
Fig. 4 Organisation physique du r eseau base de donn ees dutilisateurs, que ce soit les op erateurs en amont, les managers en aval ou le service informatique. De plus en plus, ces utilisateurs passent par Internet, ce qui implique un nombre grandissant dinformations qui circulent entre le serveur web de lentreprise et le serveur base de donn ees. Dautres remarques sont ` a noter concernant le logiciel pr esent e ici : comme SQL Server a toujours quelque chose ` a faire, il tourne en permanence sur le serveur ; cest ce que lon appelle un service : on ne le d emarre pas comme un simple ex ecutable et il continue de tourner quand on se d econnecte ; on ne trouvera dans le logiciel SQL Server ni de formulaires ni d etats ; linterfa cage graphique est laiss e aux ordinateurs clients, comme par exemple les applications Visual Basic (dont Access), les applications textes ou encore les pages web. Par ailleurs, l edition d etats est laiss ee ` a dautres logiciels, comme par exemple Crystal Seagate.
10
Premi` ere partie
Le syst` eme transactionnel

En anglais on parle de syst` eme OLTP (On Line Transaction Processing). Il sagit pour nous de concevoir et d evelopper la base de donn ees relationnelle et les transactions qui permettent de modier les donn ees. On propose de d ecouvrir ici le langage Transact SQL qui est une version propre ` a SQL Server du langage SQL. Le langage SQL a et e initialement con cu dans les ann ees 1970 par la rme IBM. Il a et e ensuite normalis e (la norme actuelle, SQL-2, date de 1992) et est devenu le standard de tous les SGBDR. Ce langage permet de masquer aux programmeurs les algorithmes de recherche des donn ees dans des chiers physiques eux-m eme structur es de mani` ere tr` es complexe et di eremment selon les SGBDR. Transact SQL prend certaines libert es par rapport ` a la norme, mais la majeure partie de ce quon aborde ici est r eutilisable avec un autre syst` eme de gestion. Il se d ecompose en quatre sous-langages qui soccupent de : la d enition des donn ees : cr eation des tables, des contraintes, etc. ; la manipulation des donn ees : s electionner, ins erer, supprimer et modier ; le contr ole des donn ees : int egrit e, droits dacc` es, verrous et cryptage ; la programmation : proc edures stock ees, fonctions, d eclencheurs.
Le lecteur ne trouvera rien ici concernant ladministration (sauvegarde, maintenance, ...), loptimisation (index, compilation, ...) ou linterfa cage (ADO, SQL-DMO, ...) des bases de donn ees. Pour cela il sera libre de consulter [7] ou [9]. Le lecteur est egalement invit e` a se rappeler les m ethode de conception dun bon sch ema relationnel (cf. [?] et les r ef erences cit ee ` a lint erieur) et ` a se souvenir quil est essentiel de conna tre le m etier des utilisateurs dune base de donn ees avant de travailler dans celle-ci.
Syntaxe du langage SQL

Comme tout nouveau langage commen cons par apprendre la syntaxe de base.
Tout dabord on peut mettre autant despaces 1 et de sauts de ligne que lon veut entre les mots du langage. Cependant, on respectera les r` egles suivantes : une seule instruction par ligne ; la m eme indentation 2 que dans le pr esent document ; et des lignes pas trop longues (visibles enti` erement ` a l ecran).
1.1
Commentaires
On peut ins erer des commentaires de deux fa cons : sur une ligne, ` a partir de deux tirets -- ; dans un bloc d elimit e par /* et par */.
1. dans ce cas espace est un nom f eminin 2. cest-` a-dire quon respectera le m eme alignement vertical ` a laide de tabulations
1 SYNTAXE DU LANGAGE SQL Exemple :

1 2 3 4 5 6
11
/* cette requete selectionne toutes les donnees de la table Exemple */ SELECT * FROM Exemple -- le * designe toutes les colonnes
Remarque : ne pas employer les caract` eres accentu es (y compris dans les commentaires)
1.2
Noms
Tous les noms dobjets (table, colonne, variable, etc.) doivent respecter les r` egles suivantes : ne pas d epasser 128 caract` eres parmi : les lettres (non accentu ees), les chires, @, $, #, - ; commencer par une lettre ; ne pas contenir despace . Si un nom ne v erie pas les deux derni` eres r` egles, il faut le d elimiter par des crochets [ et ] (si le nom utilise un crochet fermant, le doubler : [Bill [William]] Clinton]). Par ailleurs, on est pas oblig e de respecter la casse (i.e. il ny a aucune di erence entre les majuscules et les minuscules). Mais on prendra lhabitude de laisser en majuscule les mots-cl es du langage et seulement les mots-cl es du langage.
1.3

Op erateurs
Les op erateurs arithm etiques disponibles sont : +, -, *, / et % le reste par division enti` ere ; les op erateurs de comparaison logique sont : <, <=, =, >=, > et <> (di erent) ; les autres op erateurs logique sont : AND, OR et NOT ; et pour la concat enation des cha nes de caract` eres on utilise +.
Les niveaux de priorit e entre ces op erateurs sont usuels, il sut donc de parenth eser quand on a un doute.
1.4
Variables
Les principaux types disponibles sont : INT DECIMAL(9,2) REAL CHAR(64) VARCHAR(64) DATETIME entier montant ` a 9 chires (d ecimaux) dont 2 apr` es la virgule r eel ottant cod e sur 24 bits cha ne de caract` ere de longueur xe 64 cha ne de caract` ere de longueur variable mais inf erieure ou egale ` a 64 date et/ou heure avec une pr ecision de 3.33 ms
Remarques : dans un soucis d economie despace, on peut utiliser pour les entiers les types SMALLINT, TINYINT et m eme BIT ; les entiers de type INT peuvent aller jusqu` a un peu plus de 2 milliards, au del` a il faut utiliser le type BIGINT qui autorise des entiers jusqu` a plus de 9000 milliards ; le nombre maximal de d ecimales est 28 ;
1 SYNTAXE DU LANGAGE SQL
12
on peut choisir de stocker les r eels ottants sur n bits avec le type FLOAT(n) (n inf erieur ou egale a 53) ; ` les cha nes de caract` eres ne peuvent pas d epasser 8000 caract` eres, au del` a, il faut utiliser le type TEXT qui autorise plus de 2 milliards de caract` eres ; on peut d enir son propre type, exemple 3 4 :
1
sp_addtype CodePostal, CHAR(5)
pour les conversions entre di erents type, il faut parfois employer linstruction CAST 5 (cf. laide en ligne). Lorsque lon d eni une variable, on adopte la convention de faire commencer son nom par @.D eclaration, aectation et achage :
1 2 3
DECLARE @tva DECIMAL(3,3) SET @tva = 0.186 PRINT @tva
1.5
Structures
SQL ore les structures usuelles de tout langage. 1.5.1 Blocs
On peut d elimiter un bloc de plusieurs instructions par BEGIN et par END. Cest la structure la plus importante du langage, elle est utilis ee par toutes les autres structures, les transactions, les d eclencheurs, les proc edures stock ees et les fonctions. 1.5.2 Branchements conditionnels
On peut parfois avoir besoin deectuer un branchement conditionnel, pour cela on dispose de la structure conditionnelle suivante : IF expression bool eenne ... ELSE ...
une instruction ou un bloc faculatif une instruction ou un bloc
Exemple tir e de la base de donn ees Northwind : on veut supprimer le client Frank
1 2 3 4 5 6 7 8
IF EXISTS(SELECT OrderID FROM Orders WHERE CustomerID = Frank) -- bref, sil existe des commandes pour le client Frank PRINT Impossible de supprimer le client Frank, car il fait lobjet de commandes ELSE BEGIN DELETE Customers WHERE CustomerID = Frank PRINT Client Frank supprime END
3. sp addtype est une proc edure stock ee, cf. 9 page 44 4. on a aussi sp droptype pour supprimer un type cr e e par lutilisateur 5. ou CONVERT
1 SYNTAXE DU LANGAGE SQL
13
Remarque : les cha nes de caract` eres sont d elimit ees par une quote et si la cha ne contient elle-m eme une apostrophe , il sut de doubler la quote . Une erreur tr` es fr equente consister ` a utiliser plusieurs instructions sans les d elimiter par un bloc :
1 2 3 4 5
IF(@b <> 0) PRINT On peut diviser car b est non nul @a = @a / @b ELSE PRINT On ne peut pas diviser car b est nul
On dispose egalement de la structure plus g en erale suivante : CASE WHEN expression bool eenne THEN ... WHEN expression bool eenne THEN ... ... ELSE ... END
une instruction ou un bloc une instruction ou un bloc dautres WHEN ... THEN une instruction ou un bloc
Dans laquelle, les di erents cas sont evalu es successivement. Exemple tir e de la base de donn ees Northwind : on veut savoir quel produit il faut r eapprovisionner
1 2 3 4 5 6 7 8 9 10 11 12
SELECT ProduitID, Etat du stock = CASE WHEN(Discontinued = 1) THEN Ne se fait plus WHEN((UnitsInStock - UnitsOnOrder) < ReOrderLevel) THEN Seuil de reapprivionnement atteint : passer commande WHEN(UnitsInStock < UnitsOnOrder) THEN Stock potentiellement negatif : passer commande ELSE En stock END FROM products
Exercice : une erreur sest gliss ee dans lexemple pr ec edent. 1.5.3 Boucles conditionnelles
La seule fa con deectuer une boucle est dutiliser la structure suivante : WHILE expression bool eenne ...
une instruction ou un bloc
2 MODES DEXECUTION DU CODE SQL On ne dispose pas de boucle FOR pour la simple raison que les boucles WHILE susent :
1 2 3 4 5 6 7 8
14
DECLARE @i SET @i = 0 WHILE(@i < @n) BEGIN ... @i = @i + 1 END
Par ailleurs, pour parcourir toutes les lignes dune table, il sut bien souvent dutiliser linstruction SELECT. Les boucles sont donc inutiles en g en eral.
Modes dex ecution du code SQL
Une fois quon a ecrit (sans erreur) son code, SQL etant un langage interpr et e, on peut d ecider quand et comment lex ecuter. La premi` ere etape consiste bien souvent ` a pr eciser sur quelle base de donn ees on compte travailler. Pour cela on dispose de linstruction USE. Exemple :
1
USE northwind
2.1
Ex ecution imm ediate
Dans lAnalyseur de requ ete, s electionner la partie du code ` a ex ecuter et taper sur F5, CTRL+E, ALT+X ou cliquer sur le bouton lecture.
2.2
Utilisation de script
On peut enregistrer le code SQL dans des chiers textes dextension .sql (il sagit-l` a dune convention que lon adopte) pour les ex ecuter plus tard. Sous MS-DOS, on peut ex ecuter un script truc.sql avec lutilitaire osql en tapant : osql -i truc.sql
2.3
Ex ecution par lots
Dans lutilitaire osql on peut egalement taper les lignes une par une et taper GO pour lancer lex ecution. Les instructions entre deux GO successifs forment un lot. Si une erreur existe dans un lot, aucune instruction ne sera r eellement ex ecut ee. Le lot passe donc soit en totalit e, soit pas du tout. On peut ecrire les GO dans un script, mais on pr ef erera utiliser les transactions.
2.4
Transactions
Une transaction est une suite dinstructions qui r eussissent ou qui echouent en totalit e (pas de r eussite partielle). Si elle r eussit, les modications apport ees ` a la base sont permanentes, et la transaction est inscrite au journal. Si une instruction echoue, toute la transaction est annul ee et la base retrouve l etat dans lequel elle etait avant la transaction. Toutes les transactions gurent dans un chier que lon appelle le journal des transactions. Ce journal permet de restaurer la base de donn ees en cas de panne sur le ou les chiers de donn ees. Ces chiers de donn ees sont evidemment sauvegard es r eguli` erement, mais pour pouvoir restaurer compl` etement la base (en cas de plantage) il faut pouvoir refaire toutes les modications depuis la derni` ere sauvegarde. Cest
3 MISE EN PLACE DUNE BASE
15
le r ole du journal des transactions de contenir toutes ces informations. Il est donc g en eralement stock e sur un autre disque. On dit quune transaction est ACID : Atomique, au sens o` u on ne peut pas la diviser en une partie qui echoue et une partie qui r eussit ; Consistante, au sens o` u une fois la transaction termin ee, la base est de nouveau dans un etat coh erent ; Isol ee, au sens o` u une transaction consid` ere que, pendant son ex ecution, les donn ees quelle manipule ne sont pas modi ees par une autre transaction ; et Durable, au sens o` u les modications op er ees par la transaction sont enregistr ees de fa con permanente (et recouvrables en cas de reconstruction de la base). La syntaxe pour d elimiter une transaction est la suivante : BEGIN TRAN ... COMMIT TRAN
une suite dinstructions
Cest une notion importante : si le transfert dune somme dargent est encapsul e dans une transaction qui regroupe le d ebit du compte source et le cr edit du compte destination, alors il ny aura pas de fuite dargent m eme en cas derreur.
2.5
D ebogage
Il ny a pas dans SQL Server de d ebogage ` a proprement parler. Tout juste dispose-t-on dune v erication de la syntaxe des requ etes SQL. Il faut donc se d ebrouiller avec lachage des r esultats a l ` ecran.
Mise en place dune base
Toutes les op erations qui permettent de cr eer une base de donn ees sont disponibles dans Enterprise Manager sous forme de bo tes de dialogue et de boutons. Mais on peut egalement les organiser dans un code SQL.
3.1
Une base et son journal
Une base de donn ees SQL Server contient au minimum : un chier de donn ees principal (dextension .mdf) o` u sont stock ees les donn ees ; un journal des transactions (dextension .ldf) o` u sont r epertori ees toutes les transactions. Lorsque lon cr e e une base, il faut donc pr eciser le nom, lemplacement et la taille de ces deux chiers.
3 MISE EN PLACE DUNE BASE Exemple : cr eons une base de donn ees papeterie
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
16
CREATE DATABASE papeterie ON PRIMARY ( NAME = papeterie_data, FILENAME = C:\Data\papeterie.mdf, SIZE = 60MB, MAXSIZE = 70MB, FILEGROWTH = 1MB ) LOG ON ( NAME = papeterie_log, FILENAME = D:\Log\papeterie.ldf, SIZE = 15MB, MAXSIZE = 20MB, FILEGROWTH = 1MB )
-- le nom de la base -- le fichier de donnees principal -----nom logique emplacement et nom du fichier taille de depart taille maximale increment
-- le journal
Pour modier une base de donn ees existante, on utilise linstruction ALTER DATABASE. Par exemple :
1 2
ALTER DATABASE papeterie MODIFY NAME cartoleria
Remarque : dautres modications sont possibles. Pour supprimer une base de donn ees existante, il sut de taper :
1
DROP DATABASE papeterie
3.2
Une table
Lors de la cr eation dune table dans une base de donn ees existante, il faut pr eciser : pour chaque colonne : son nom et son type de donn ees ; une cl e primaire (qui permet didentier chaque ligne de fa con unique). On peut eventuellement pr eciser pour chaque colonne si vide 6 est interdit et/ou une valeur par d efaut. Exemple de cr eation dune table :
1 2 3 4 5 6
CREATE TABLE clients ( clt_num CHAR(8) PRIMARY KEY, clt_nom VARCHAR(64) NOT NULL, clt_ca INT DEFAULT 0 )
-- cle primaire -- vide interdit -- valeur par defaut
6. NULL repr esente une absence dinformation
3 MISE EN PLACE DUNE BASE Pour modier une table existante, on utilise linstruction ALTER TABLE. Exemples :
1 2 3 4 5 6 7 8
17
ALTER TABLE clients ADD clt_adr VARCHAR(255) ALTER TABLE clients DROP COLUMN clt_adr ALTER TABLE clients ALTER COLUMN clt_num INT
-- pour ajouter la colonne adresse
-- pour retirer la colonne adresse
-- pour reconvertir le type de donnees
Pour supprimer une table existante, il sut de taper :

1
DROP TABLE clients
3.3
Num erotation automatique
Pour la cl e primaire dune table, il est souvent pr ef erable de laisser SQL Server g en erer des valeurs distinctes. On dispose pour cela de deux possibilit es : une valeur enti` ere qui sincr emente automatiquement ; un identicateur unique universel (GUID), cest-` a-dire un nombre cod e sur 16 octets en logique polonaise inverse. Nous nous contentons de la premi` ere alternative :
1 2 3 4 5 6
CREATE TABLE clients ( clt_num INT PRIMARY KEY IDENTITY(4,2), -- les numeros des clients successifs seront 4, 6, 8, ... ... )
Remarque : lavantage davoir un incr ement > 1 est de pouvoir ensuite ins erer des num eros parmi les num eros automatiques (ce qui repr esente un int er et limit e, nous nous contentons donc bien souvent de IDENTITY(1,1)). ` titre dinformation, la seconde alternative semploie ainsi : A
1 2
ALTER TABLE clients ALTER COLUMN clt_num UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWID()
3.4
D enir les relations
La commande dun produit est forc ement pass ee par un client. Donc la table commandes devra contenir une colonne pour savoir quel client est concern e. Cette colonne cmd clt contiendra en fait la cl e primaire du client concern e. Il y a donc une relation entre cmd clt et la colonne clt num de la table clients (cf. gure 5). Comme cmd clt va chercher ses valeurs dans une autre colonne, elle constitue ce que lon appelle une cl e etrang` ere.
4 SELECTIONNER LES DONNEES
18
Fig. 5 Relation entre deux tables La syntaxe pour cr eer la table commandes est alors :
1 2 3 4 5 6 7
CREATE TABLE commandes ( cmd_num INT PRIMARY KEY IDENTITY(1,1), cmd_date DATETIME DEFAULT GETDATE(), -- GETDATE() retourne la date daujourdhui et lheure courante cmd_clt INT NOT NULL FOREIGN KEY REFERENCES clients(clt_num) )
Remarques : cmd clt et clt num doivent etre du m eme type ; on pourrait se contenter de REFERENCES clients car clt num est cl e primaire ; cette relation introduit deux contraintes : lors dune nouvelle commande, le client devra d ej` a exister ; lors de la suppression dun client, il ne devra plus faire lobjet de commande.
S electionner les donn ees
On entre ici au cur du langage SQL puisque ce sont les requ etes de s election qui r eclament le plus de conception de part du programmeur.
4.1
S election simple
Rappelons que la syntaxe pour eectuer une requ ete de s election est : SELECT colonnes FROM tables WHERE condition1 AND condition2 OR
Exemple : si on veut toutes les commandes du client Razibus

1 2 3 4
SELECT cmd_num, cmd_date FROM commandes, clients WHERE clt_nom = Razibus AND cmd_clt = clt_num
-- il faut rappeler la relation
19
Remarques : lordre na pas dimportance pour la relation (on aurait pu ecrire clt num = cmd clt ; lordre na pas non plus dimportance entre les deux conditions de WHERE (on aurait pu mettre clt num = Razibus apr` es). Dans les conditions WHERE (reli ees entre elles par OR ou AND) on peut utiliser =, <> et tous les op erateurs de comparaison : WHERE clt nom <> Razibus une plage de valeurs (bornes incluses) : WHERE clt ca BETWEEN 10000 AND 100000 une liste de valeurs : WHERE clt nom IN (Razibus, Fricotin, Mironton) un ltre : WHERE clt nom
LIKE R%
LIKE R zibus LIKE %[M-R] LIKE %[^FMR]% Remarque : on dispose evidemment de
-------
commen cant par R % remplace toute s erie de caract` eres (y compris vide) remplace un caract` ere finissant par M, N, O, P, Q ou R ne contenant ni F ni M ni R
NOT BETWEEN ... AND ... NOT IN ... NOT LIKE ...
Par ailleurs, on peut intituler les colonnes (si lintitul e contient des espaces ou des accents, le d elimiter avec des crochets [ ]) : SELECT cmd num AS [num ero de commande], cmd date AS date trier les r esultats : SELECT ... FROM ... WHERE ... ORDER BY cmd date DESC, cmd num ASC cest-` a-dire par dates d ecroissantes, puis (pour les commandes de la m eme date) par num ero croissant nacher que des r esultats distincts : SELECT DISTINCT ... nacher que les premiers r esultats : SELECT TOP 50 ... Mais malheureusement, on ne peut pas utiliser les alias d enis dans la clause SELECT dans les autres clauses (WHERE et ORDER BY notamment).
20
4.2
Jointures internes
Quand on utilise deux tables ou plus, on eectue en r ealit e des jointures entre ces tables. Donc d esormais on ecrira plut ot :
1 2 3 4
SELECT cmd_num, cmd_date FROM commandes JOIN clients ON cmd_clt = clt_num WHERE clt_nom = Razibus
-- condition de jointure -- condition de selection
Remarques : ceci permet de bien s eparer les conditions de jointure des conditions de s election ; une jointure est en quelque sorte un produit cart esien temporaire : la table (cmd num, cmd date, clt nom) est provisoirement cr e ee pour eectuer la s election ; le moteur du SGBD se charge de trouver le moyen deectuer le moins dop erations possible ; une jointure nest pas seulement le rappel des relations entre deux tables, cest une vraie condition (qui peut utiliser <> et les autres op erateur de comparaison ` a la place de = par exemple) et pas forc ement entre une cl e etrang` ere et sa r ef erence ; on peut eectuer plusieurs jointures successives : FROM commandes JOIN clients ON cmd clt = clt num JOIN articles ON cmd art = art num pour une m eme jointure, on peut utiliser plusieurs conditions de jointures (reli ees entre elles par AND ou OR). Pour etre tout ` a fait rigoureux, il faut toujours pr eciser la table ` a laquelle appartiennent les colonnes utilis ees (en utilisant des alias). On ecrira donc d esormais :
1 2 3 4
SELECT a.cmd_num, FROM commandes AS JOIN clients AS b WHERE b.clt_nom =
a.cmd_date a ON a.cmd_clt = b.clt_num Razibus
Exercice : s electionner les clients ayant command e le m eme jour (le r esultat devra se pr esenter sous forme de deux colonnes : un client et un autre qui a command e le m eme jour). Solution : avec les alias, lauto-jointure devient possible
1 2 3 4 5 6
SELECT DISTINCT a.cmd_clt, b.cmd_clt FROM commandes AS a JOIN commandes AS b ON a.cmd_clt <> b.cmd_clt -- la condition de jointure est que les deux clients ne sont pas les memes WHERE a.cmd_date = b.cmd_date -- parmi tous les couples de clients distincts on ne garde que ceux-la
4.3
Jointures externes
Imaginons maintenant que lon dispose de la table clients plus qui contient les colonnes clt num, clt adresse, clt email, clt telephone et que lon veuille acher la liste compl` ete des clients ainsi que leur renseignements compl ementaires sils existent.
4 SELECTIONNER LES DONNEES La premi` ere id ee consiste ` a eectuer la requ ete suivante :
1 2 3
21
SELECT a.clt_nom, b.clt_adresse, b.clt_email, b.clt_telephone FROM clients AS a JOIN clients_plus AS b ON a.clt_num = b.clt_num
Probl` eme : ne sachent que les clients ayant des informations compl ementaires. La solution consiste a rendre facultative la jointure avec la table de droite. `
1 2 3 4
SELECT a.clt_nom, b.clt_adresse, b.clt_email, b.clt_telephone FROM clients AS a LEFT JOIN clients_plus AS b ON a.clt_num = b.clt_num -- jointure facultative gauche
Attention : si cest la table de droite qui est facultative, alors il sagit dune jointure externe gauche. Autre cas : on veut la liste des adresses electroniques de la table clients plus mais parfois il ny a aucun client de rattach e.
1 2 3 4
SELECT b.clt_email, a.clt_nom FROM clients AS a RIGHT JOIN clients_plus AS b ON a.clt_num = b.clt_num -- jointure facultative droite
Dernier cas : on veut la liste des clients dont on a soit le nom, soit le-mail.
1 2 3 4
SELECT a.clt_nom, b.clt_email FROM clients AS a FULL OUTER JOIN clients_plus AS b ON a.clt_num = b.clt_num -- jointure facultative dans les deux sens
4.4
Union des s elections
On peut regrouper les r esultats de plusieurs requ etes de s election. Exemple : ` a supposer que les tables commandes2000 et comandes2001 existent, on peut visualiser les commandes dun client au cours de ces deux ann ees ainsi :
1 2 3 4 5 6 7 8 9 10 11
SELECT a.cmd_num, a.cmd_date FROM commandes2000 AS a JOIN clients AS b ON a.cmd_clt = b.clt_num WHERE b.clt_nom = Razibus UNION SELECT a.cmd_num, a.cmd_date FROM commandes2001 AS a JOIN clients AS b ON a.cmd_clt = b.clt_num WHERE b.clt_nom = Razibus
22
Remarques : lutilisation de lop erateur UNION suppose que les colonnes s electionn ees des les deux requ etes sont du m eme nombre, du m eme type et dans le m eme ordre (mais pas forc ement les m emes) ; les doublons sont supprim es automatiquement (i.e. on ne retrouve pas deux fois la m eme ligne) ` a moins dutiliser UNION ALL ; pour sp ecier les intitul es de colonnes, pr eciser les alias AS dans la premi` ere clause SELECT. Il est parfois possible de substituer un UNION par une jointure suppl ementaire et plusieurs conditions WHERE, mais cest plus facile dutiliser UNION. De plus, on peut parfois obtenir de meilleures performances en d ecomposant une requ ete complexe en une s erie de SELECT combin es avec lop erateur UNION.
4.5
Sous-requ etes
Les conditions de s election de la clause WHERE peuvent utiliser le r esultat dune autre requ ete. 4.5.1 Sous-requ ete renvoyant une valeur
Lors que cette autre requ ete ne revoie quune valeur, on peut utiliser = et tous les autres op erateurs de comparaison logique 7 . Exemple : pour acher les commandes dun client on peut utiliser une sous-requ ete.
1 2 3 4 5
SELECT cmd_num, cmd_date FROM commandes WHERE cmd_clt = ( SELECT clt_num FROM clients WHERE clt_nom = Razibus ) Sous-requ ete renvoyant une liste de valeurs
4.5.2
Les sous-requ etes qui renvoie une liste de valeurs peuvent etre naturellement utilis e par lop erateur IN. Exemple : on veut les commandes de tous les clients dont le nom commence par P.
1 2 3 4 5
SELECT cmd_num, cmd_date FROM commandes WHERE cmd_clt IN ( SELECT clt_num FROM clients WHERE clt_nom LIKE P% )
Le langage SQL ore dautres mot-cl e pour ce type de sous-requ ete, d ecouvrons-les par lexemple.Avec la table articles qui comporte les colonnes art num, art nom, art prix et art couleur on veut successivement : les articles dont le prix est sup erieur ` a tous les articles blancs :
1 2 3 4 5
SELECT art_nom FROM articles WHERE art_prix > ALL ( SELECT art_prix FROM articles WHERE art_couleur = blanc )
7. mais aussi BETWEEN ... AND ...
4 SELECTIONNER LES DONNEES ceci est equivalent ` a

1 2 3 4 5
23
SELECT art_nom FROM articles WHERE art_prix > ( SELECT MAX(art_prix) FROM articles WHERE art_couleur = blanc )
les articles dont le prix est sup erieur ` a lun des articles blancs :
1 2 3 4 5
SELECT art_nom FROM articles WHERE art_prix > ANY ( SELECT art_prix FROM articles WHERE art_couleur = blanc )
ceci est equivalent ` a

1 2 3 4 5
SELECT art_nom FROM articles WHERE art_prix > ( SELECT MIN(prix) FROM articles WHERE art_couleur = blanc )
tous les articles mais seulement sil en existe un de blanc (pourquoi pas ?) :
1 2 3 4 5
SELECT art_nom FROM articles WHERE EXISTS ( SELECT art_num FROM articles WHERE art_couleur = blanc )
tous les articles mais seulement sil nen existe pas de blanc (pourquoi pas non plus ?) :
1 2 3 4 5
SELECT art_nom FROM articles WHERE NOT EXISTS ( SELECT art_num FROM articles WHERE art_couleur = blanc )
4 SELECTIONNER LES DONNEES 4.5.3 Requ etes correl ees
24
Lorsquune sous-requ ete a besoin dinformation de la requ ete parent, on dit quelle est corr el ee. Il sut dutiliser des alias AS pour lui passer les informations. Exemple : quels sont les clients qui ont pass e une commande dun montant sup erieur ` a 1 % de leur chire daaire ?
1 2 3 4 5
SELECT clt_nom FROM clients AS a WHERE (clt_ca / 100) < ANY ( SELECT cmd_montant FROM commandes AS b WHERE b.cmd_clt = a.clt_num )
Remarques : lalias a est d eni dans la requ ete appelante et est utilisable dans la sous-requ ete ; La sous-requ ete sera ex ecut ee autant de fois quil y a de clients.
4.5.4
Requ etes imbriqu ees vs. jointures
Souvent une sous-requ ete peut etre remplac ee par une jointure :
1 2 3 4
SELECT DISTINCT a.clt_nom FROM clients AS a JOIN commandes AS b ON b.cmd_clt = a.clt_num WHERE (a.clt_ca / 100) < b.cmd_montant
Lorsquon emploie les requ etes imbriqu ees, on pr ecise ` a SQL Server comment eectuer la requ ete ; cest une fa con proc edurale de voir les choses. Tandis que quand on utilise des jointures cest une forme relationnelle et SQL Server se charge de faire pour le mieux. Par contre, il ny a parfois pas d equivalence jointures ` a une ecriture en sous-requ etes. Mais quand on a un equivalent, il vaut mieux utiliser les jointures car la requ ete sera optimis ee par linterpr` ete SQL. Ceci dit, lutilisation de sous-requ ete est plus lisible ... 4.5.5 Sous-requ ete renvoyant plusieurs colonnes
Une sous-requ ete renvoyant une ou plusieurs colonnes peut etre utilis ee comme table dans la clause FROM. Cela peut servir par exemple ` a ne s electionner que les plus gros clients :
1 2 3 4 5 6
SELECT a.clt_nom FROM ( SELECT TOP 10 * FROM clients ORDER BY clt_ca DESC ) AS a JOIN commandes AS b ON b.cmd_clt = a.clt_num WHERE (a.clt_ca / 100) < b.cmd_montant
Par contre, on ne peut pas utiliser ce type de sous-requ ete dans une clause WHERE (sauf avec EXISTS), contrairement ` a Oracle.
25
4.6
Requ etes multibases
` lorigine, SQL ne permet pas de faire de requ A etes qui portent sur les tables de plusieurs bases de donn ees et encore moins g er ees par di erents SGBDR. Transact-SQL ore un m ecanisme de d enomination qui permet deectuer des jointures entre des tables issus de syst` emes h et erog` enes. La syntaxe compl` ete du nom dune table est : [nom du serveur] . [nom de la base] . [nom du propri etaire] . [nom de la table] Le propri etaire est g en eralement dbo le database owner. Cette syntaxe permet d ecrire une jointure portant sur les tables des deux bases de donn ees di erentes (sur le m eme serveur) :
1 2 3
SELECT a.cmd_num, b.art_nom FROM GestionCommerciale.dbo.commandes AS a JOIN GestionProductique.dbo.articles AS b ON a.cmd_art = b.art_num
Ou une jointure portant sur deux bases de donn ees g er ees par des serveurs di erents :
1 2 3
SELECT a.clt_nom AS [clients communs] FROM ENTREPRISE1.GestionCommerciale.dbo.clients AS a JOIN ENTREPRISE2.GestionCommerciale.dbo.clients AS b ON a.clt_nom = b.clt_nom
Cependant, la requ ete etant eectu ee sur un serveur SQL Server (ENTREPRISE1 par exemple), il faut que les autres serveurs utilis es (ENTREPRISE2 en loccurrence) soient d eclar es comme serveurs li es dans le serveur SQL Server. Remarque : ENTREPRISE2 nest pas forc ement un serveur SQL Server, mais peut etre nimporte quel SGBD reconnu par DTS (cf. 17 page 75), ce qui permet d ecrire des requ etes sur des donn ees h et erog` enes (cf. [1]).
4.7
Quelques fonctions SQL
` tout moment dans une requ A ete SELECT on peut utiliser de nombreuses fonctions, ` a commencer par la fonction suivante qui sav` ere souvent tr` es utile : ISNULL qui permet de remplacer NULL par une autre valeur. Par exemple, pour remplacer une absence de chire daaire par un chire daaire nul :
1 2
SELECT clt_nom, ISNULL(clt_ca, 0) FROM clients Fonctions dagr egat COUNT SUM AVG VAR STDEV MIN MAX d enombrement moyenne variance ecart-type
4.7.1
4 SELECTIONNER LES DONNEES Exemple :

1 2 3 4 5 6 7
26
-- pour compter le nombre de client SELECT COUNT(clt_num) FROM clients -- pour connaitre le chiffre daffaire moyen des clients SELECT AVG(clt_ca) FROM clients
Remarque : toutes ces fonctions ignorent les valeurs NULL (surtout COUNT). 4.7.2 Op erateurs
Cest-` a-dire : +, -, *, /, % et le + de concat enation. Exemple :

1 2 3 4 5 6 7
-- pour afficher le chiffre daffaire mensuel moyen de chaque client SELECT clt_nom, clt_ca / 12 AS [ca mensuel] FROM clients -- pour concatener le nom et le prenom SELECT clt_nom + + clt_prenom AS [Identit e] FROM clients Fonctions sur les dates
4.7.3
Avec date de type DATETIME : DATEADD(year, 4, date) DATEADD(month, 4, date) DATEADD(week, 4, date) DATEADD(day, 4, date) DATEADD(hour, 4, date) DATEDIFF(minute, date debut, date fin) DATEDIFF(second, date debut, date fin) DATEPART(month, date) ajoute 4 ans ` a date
donne la di erence en minutes entre date fin et date debut renvoie le num ero du mois de date
Remarque : DATEDIFF et DATEPART renvoient un entier. Reprenons lexemple de lauto-jointure. Si on veut vraiment s electionner les clients qui ont command e le m eme jour, il faut remplacer le test d egalit e entre les dates par :
1 2 3 4 5
SELECT DISTINCT a.cmd_clt, b.cmd_clt FROM commandes AS a JOIN commandes AS b ON a.cmd_clt <> b.cmd_clt WHERE DATEDIFF(day, a.cmd_date, b.cmd_date) = 0 -- sinon il sagit dune egalite a 3.33 ms pres
Remarque : la requ ete pr ec edente nest pas equivalente ` a la suivante.
4 SELECTIONNER LES DONNEES SELECT DISTINCT a.cmd_clt, b.cmd_clt FROM commandes AS a JOIN commandes AS b ON a.cmd_clt <> b.cmd_clt WHERE DATEDIFF(hour, a.cmd_date, b.cmd_date) BETWEEN -24 AND 24 /* dans ce cas les clients ont commande a moins de 24h dintervalle mais pas forcement le meme jour */ Fonctions sur les cha nes de caract` eres
27
1 2 3 4 5 6
4.7.4
Notamment : LEN (longueur), LOWER (convertit tout en minuscule), REPLACE, SUBSTRING et UPPER (tout en majuscule). 4.7.5 Principales fonctions math ematiques
` savoir : ABS (valeur absolue), CEILING (partie enti` A ere +1), COS, EXP, FLOOR (partie enti` ere), LOG (logarithme neperien), LOG10, PI, POWER, SIGN, SIN, SQRT, SQUARE et TAN. Par exemple, on peut ecrire la derni` ere requ ete ainsi :
1 2 3 4
SELECT DISTINCT a.cmd_clt, b.cmd_clt FROM commandes AS a JOIN commandes AS b ON a.cmd_clt <> b.cmd_clt WHERE ABS(DATEDIFF(hour, a.cmd_date, b.cmd_date)) <= 24 Fonctions utilisateur
4.7.6
On peut aussi d enir ses propres fonctions. Syntaxe : CREATE FUNCTION ... (...) RETURNS ... AS BEGIN ... RETURN ... END (son nom) (ses param` etres) (le type de la valeur de retour)
(la valeur de retour)
La r edaction de ces fonctions est la m eme que celle des proc edures stock ees (cf. 9 page 44) :
1 2 3 4 5 6 7 8 9 10
CREATE FUNCTION EcartEnHeure ( @date1 DATETIME, @date2 DATETIME ) RETURNS INT AS BEGIN RETURN ABS(DATEDIFF(hour, @date1, @date2)) END
5 MODIFIER LES DONNEES Puis on peut lutiliser dans une requ ete :
1 2 3 4 5 6
28
SELECT DISTINCT a.cmd_clt, b.cmd_clt FROM commandes AS a JOIN commandes AS b ON a.cmd_clt <> b.cmd_clt WHERE dbo.EcartEnHeure(a.cmd_date, b.cmd_date) <= 24 /* dans le cas dune fonction utilisateur il ne faut pas oublier le proprietaire */
Remarques : on peut mettre jusqu` a 1024 param` etres ; on dispose de ALTER FUNCTION et de DROP FUNCTION.
4.8
Conclusion
On aboutit nalement ` a la strat egie suivante pour elaborer une requ ete de s election : 1. d ecomposer au maximum en plusieurs s election que lon pourra r eunir avec UNION ; 2. d ecomposer chaque s election complexe en requ ete et sous-requ etes simples ; 3. et pour chaque requ ete et chaque sous-requ ete : (a) d eterminer les tables en jeu pour remplir la clause FROM et les JOIN n ecessaires ; (b) d eterminer les colonnes ` a acher pour remplir la clause SELECT ; (c) d eterminer les conditions de s election pour remplir la clause WHERE ; (d) ajouter les eventuels ORDER BY, DISTINCT et TOP en dernier.
Modier les donn ees
Certes, avant de s electionner les donn ees il faut pouvoir en ajouter dans une base a priori vide. Mais avant dapprendre ` a modier les donn ees en SQL il faut savoir les s electionner. Cest pourquoi nous nabordons que maintenant les requ etes dinsertion, de suppression et de mise-` a-jour. Il est sous-entendu ici que lon a les droits de modication n ecessaires sur les tables concern ees. Par ailleurs, il est conseill e dinclure toutes les op erations de modications des donn ees dans une transaction, non seulement parce que ces op erations peuvent echouer partiellement, mais aussi an quelles gurent au journal.
5.1
Insertion
En SQL on ne peut ins erer des lignes que dans une table ` a la fois. On peut ajouter : des donn ees compl` etes (on pr ecise alors toutes les colonnes) Exemple :
1 2 3 4
BEGIN TRAN INSERT clients -- LA table VALUES (16, Razibus, 3000000) -- toutes les colonnes et dans lordre COMMIT TRAN
Remarque : on ne peut mettre quun VALUES par INSERT, mais plusieurs INSERT par transaction
5 MODIFIER LES DONNEES des donn ees partielles (on ne pr ecise que certaines colonnes) Exemple :
1 2 3 4
29
BEGIN TRAN INSERT clients(clt_nom, clt_num) -- lordre na pas dimportance VALUES (Fricotin, 18) -- tant quil est le meme ici COMMIT TRAN
Remarques : il est obligatoire dins erer des valeurs compatibles avec le type de la colonne dans toutes les colonnes d eclar ees NOT NULL et qui nont pas de valeur par d efaut des donn ees issues dune s election (on introduit plusieurs lignes ` a la fois) Exemple : supposons que lon dispose dune table clients importants qui nai que la colonne clt num
1 2 3 4 5 6
BEGIN TRAN INSERT clients_importants(clt_num) SELECT TOP 100 clt_num FROM clients ORDER BY clt_ca DESC COMMIT TRAN
dans une table temporaire (aucune cl e primaire ni etrang` ere, donc aucune relation avec le sch ema relationnel) Exemple : si la table clients importants nexiste pas encore
1 2 3 4
SELECT TOP 100 clt_num INTO clients_importants FROM clients ORDER BY clt_ca DESC
Remarques : la table temporaire contient alors les m emes colonnes que le r esultat de la requ ete SELECT ; on ne peut pas utiliser SELECT ... INTO dans une transaction ; ne pas oublier le DROP TABLE une fois quon a plus besoin de la table temporaire.
5.2
Suppression
` nouveau, on ne peut supprimer des lignes que dans une table ` A a la fois. La syntaxe pour eectuer une requ ete de suppression est : DELETE table FROM tables WHERE conditions (la table dans laquelle on supprime) (les tables utilis ees dans la clause WHERE) (les lignes ` a supprimer)
5 MODIFIER LES DONNEES Exemple : supprimer les petits clients

1 2 3 4 5
30
BEGIN TRAN DELETE clients FROM clients WHERE clt_ca < 1000 COMMIT TRAN
Autre exemple : supprimer tous les clients (vider la table, et non pas, supprimer la table)
1 2 3
BEGIN TRAN DELETE clients COMMIT TRAN
Remarques : il est tr` es dangereux doublier la clause WHERE dans un DELETE ; ` a cause de la cl e etrang` ere dans la table commandes, on ne peut pas supprimer les clients qui ont des commandes.
5.3
Mise-` a-jour
Encore une fois, on ne peut changer les lignes que dune table ` a la fois. La syntaxe pour eectuer une requ ete de mise-` a-jour est : UPDATE table SET colonne1 = ..., colonne2 = ... FROM tables WHERE conditions (la table dans laquelle met ` a jour) (les colonnes que lon met ` a jour) (les tables de la clause WHERE) (les lignes ` a mettre ` a jour)
Exemple : pour convertir tous les prix en euros

1 2 3 4
BEGIN TRAN UPDATE articles SET art_prix = art_prix / 6.55957 COMMIT TRAN
Remarques : on ne peut pas mettre ` a jour une colonne IDENTITY ; comme une division est moins co uteuse quune multiplication, il est pr ef erable dinverser une bonne fois pour toute le taux de conversion et de ne plus eectuer que des multiplications :
1 2 3 4 5 6
DECLARE @taux REAL SET @taux = 1.0 / 6.55957 BEGIN TRAN UPDATE articles SET art_prix = art_prix * taux COMMIT TRAN
6 CONTRAINTES
31
il faut se m eer des mises-` a-jour corr el ees, puisque la requ ete suivante ne fait pas se que lon pense :
1 2 3 4 5 6
BEGIN TRAN UPDATE articles SET art_prix = art_prix * taux, art_prixTTC = art_prix * 1.196 /* malheureusement le art_prix utilise pour art_prixTTC nest pas celui qui vient detre mis-a-jour */ COMMIT TRAN
il faut la remplacer par :

1 2 3 4 5 6 7
BEGIN TRAN UPDATE articles SET art_prix = art_prix * taux UPDATE articles SET art_prixTTC = art_prix * 1.196 COMMIT TRAN
Contraintes
Les contraintes permettent de s ecuriser les donn ees dune table. On en conna t d ej` a : les cl es primaire et etrang` ere, les valeurs par d efaut. Lobjet de cette section est dapprendre ` a cr eer ces contraintes.
6.1
Syntaxe
Pour d enir une contrainte sur une colonne dune table, on dispose de deux syntaxe : au moment de la cr eation de la table Exemple : positionnons-nous dans le cas dune mutuelle
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
CREATE TABLE assures ( num INT PRIMARY KEY IDENTITY(1,1), numSS CHAR(15), titre VARCHAR(5), age INT, date_entree DATETIME, num_rue INT, rue VARCHAR(255), -- 256 est un multiple de 8 code_postal CHAR(5), ville VARCHAR(63) CONSTRAINT cst_num_rue -- nom de la contrainte CHECK(num_rue > 0) -- corps de la contrainte CONSTRAINT cst_code_postal CHECK(code_postal LIKE ([0-9][0-9][0-9][0-9][0-9])) )
6 CONTRAINTES apr` es la cr eation de la table :

1 2 3
32
ALTER TABLE assures ADD CONSTRAINT cst_numSS CHECK (numSS LIKE ([0-2][0-9]...))
Remarques : pour pouvoir ajouter une contrainte, les donn ees existantes doivent v erier cette contrainte ; sur insertion ou mise-` a-jour, les nouvelles donn ees sont contr ol ees (si une donn ee ne v erie pas une contrainte alors toute la transaction est annul ee) ; on peut manipuler plusieurs contraintes dans un seul ALTER TABLE, il sut de les s eparer par des virgules ; on peut imposer plusieurs contraintes sur une m eme colonne. Pour retirer une contrainte :
1 2
ALTER TABLE assures DROP CONSTRAINT cst_code_postal
Pour modier une contrainte, il faut dabord la supprimer puis la cr eer de nouveau.
6.2
6.2.1
CHECK
Syntaxe
La syntaxe dune contrainte de type v erication est : CHECK(clause WHERE sans le WHERE). Exemples : on peut donc mettre plusieurs conditions
1 2 3
ALTER TABLE assures ADD CONSTRAINT cst_age CHECK(age >= 0 AND age < 150)
pr eciser une liste de choix desquels on ne peut pas sortir

1 2 3
ALTER TABLE assures ADD CONSTRAINT cst_titre CHECK(titre IN (M., Mme, Melle, Dr., Pr., SAS, Me))
utiliser plusieurs colonnes

1 2 3
ALTER TABLE articles ADD CONSTRAINT cst_TTCsupHT CHECK(art_prixTTC > art_prix)
Remarques : par contre la clause CHECK ne peut pas contenir de sous-requ ete ; la clause CHECK ne peut pas porter sur une colonne UNIQUEIDENTIFIER ou utilisant IDENTITY (cf. 3.3 page 17).
6 CONTRAINTES 6.2.2 R` egle
33
Si plusieurs colonnes ( eventuellement dans des tables di erentes) utilisent la m eme contrainte CHECK, alors il est int eressant de d enir une r` egle commune ` a toutes ces colonnes. Exemple :
1 2
CREATE RULE AgeRule AS @age >= 0 AND @age < 150
Remarques : @age est une variable locale, son nom na pas dimportance ; apr` es AS on peut mettre la m eme chose quapr` es CHECK. On peut ensuite attacher une r` egle ` a une colonne en utilisant la proc edure stock ee sp bindrule. Exemple :
1
sp_bindrule AgeRule, [assures.age]
Remarques : une colonne peut cumuler une r` egle et une contrainte CHECK ; mais cest la contrainte CHECK qui est v eri ee en premier ; on dispose de la proc edure sp unbindrule [assures.age], AgeRule et de DROP RULE AgeRule 8 . Il est egalement possible dattacher une r` egle ` a un type de donn ees, ce qui permet d eviter de les attacher ` a toutes les colonnes de ce type. Exemple :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
sp_addtype CodePostalType, CHAR(5) CREATE RULE CodePostalRule AS @cp LIKE([0-9][0-9][0-9][0-9][0-9]) sp_bindrule CodePostalRule, CodePostalType -- puis CREATE TABLE assures ( ... code_postal CodePostalType, ... )
8. qui ne fonctionne que si tous les sp unbindrule ont et e eectu es
6 CONTRAINTES
34
6.3
Valeur par d efaut
Pour pr eciser une valeur par d efaut on peut le faire simplement ` a la cr eation de la table (cf. 3.2 page 16), ou les ajouter a posteriori en tant que contrainte. Exemple :
1 2 3
ALTER TABLE assures ADD CONSTRAINT def_date_entree DEFAULT GETDATE() FOR date_entree
On peut mettre apr` es DEFAULT : une fonction niladique (i.e. sans argument) ; une constante ; ou NULL. On peut aussi cr eer des valeurs par d efaut partageables et lattacher ` a une colonne ou ` a un type de donn ees. Exemple :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CREATE DEFAULT Hier AS DATEADD(day, -1, GETDATE()) sp_bindefault Hier, [assures.date_entree] -- ou sp_addtype DateEntree, DATETIME sp_bindefault Hier, DateEntree -- puis ALTER TABLE assures ALTER COLUMN date_entree DateEntree
Remarques : si la contrainte DEFAULT est d enie, alors une eventuelle valeur par d efaut partageable serait ignor ee ; on dispose de la proc edure sp unbindefault et de DROP DEFAULT 9 . Astuce : pour utiliser les valeurs par d efaut, les r` egles et les type de donn ees personnels dans plusieurs bases de donn ees, il sut de les cr eer dans la base model car alors toute nouvelle base de donn ees en h eritera.
9. qui ne fonctionne que si tous les sp unbindefault ont et e eectu es
6 CONTRAINTES
35
6.4
Cl e primaire
Les cl es primaires sont aussi des contraintes et pour les ajouter a posteriori on peut utiliser la syntaxe : CONSTRAINT nom de la contrainte PRIMARY KEY (colonne(s) concern ee(s) par la cl e primaire) Cette syntaxe est la indispensable pour d eclarer une cl e primaire composite (cest-` a-dire portant sur 10 plusieurs colonnes ). Exemple : dans une base de donn ee biblioth` eque, un exemplaire dun livre est identi e par son num ero ISBN et son num ero de copie.
1 2 3
ALTER TABLE ouvrages ADD CONSTRAINT pk_ouvrages PRIMARY KEY (isbn, no_copie)
6.5
UNIQUE
On peut imposer ` a une colonne (ou plusieurs colonnes) de prendre des valeurs uniques (cest-` a-dire sans doublons) m eme si ce nest pas une cl e primaire. Exemples :
1 2 3
ALTER TABLE assures ADD CONSTRAINT un_numSS UNIQUE (numSS)
1 2 3
ALTER TABLE clients ADD CONSTRAINT un_nom_prenom UNIQUE (clt_nom, clt_prenom)
Remarque : la valeur NULL nest autoris ee quune seule fois dans une colonne UNIQUE.
6.6
Cl e etrang` ere
Les cl es etrang` eres sont aussi des contraintes, et ` a nouveau, si on a oubli e de les pr eciser d` es la cr eation de la table, on peut les ajouter apr` es. Attention : on ne peut faire de cl e etrang` ere que vers une cl e primaire ou vers une colonne UNIQUE. Exemple : avec la table feuilles soin qui poss` ede la colonne num assure qui doit prendre ses valeurs dans la colonne num de la table assures
1 2 3
ALTER TABLE feuille_soin ADD CONSTRAINT fk_num_assure FOREIGN KEY (num_assure) REFERENCES Assures(num)
Cette syntaxe est n ecessaire si la cl e etrang` ere est composite.

10. il est conseill e d eviter les cl es primaires composites ` a chaque fois que cela est possible
6 CONTRAINTES
36
Exemple : dans une base biblioth` eque un emprunt concerne un exemplaire dun livre, les num eros ISBN et de copie doivent donc etre les m emes.
1 2 3
ALTER TABLE emprunts ADD CONSTRAINT fk_emprunts FOREIGN KEY (isbn, no_copie) REFERENCES ouvrages(isbn, no_copie)
6.7
Conclusion
On vient de rencontrer quelques outils qui nous permette de rendre les donn ees plus coh erentes : les colonnes nacceptent quun ensemble de valeurs correctes, cest lint egrit e de domaine (on sp ecie pour ca le type de donn ees, les contraintes CHECK, les valeurs par d efaut et aussi NOT NULL) ; les lignes doivent etre identiables de mani` ere unique, cest lint egrit e des entit es (on utilise pour ca les cl es primaires et les contraintes UNIQUE) ; on doit maintenir de bonnes relations entre les tables, cest lint egrit e r ef erentielle (cest tout le travail des cl es etrang` eres).
Fig. 6 Di erents types dint egrit e Exemples dint egrit e r ef erentielle : il est impossible de cr eer des factures qui ne sont reli ees ` a aucun client ; et ` a linverse, il est impossible de supprimer un client ` a qui il reste des factures (impay ees). Il reste malgr e tout un quatri` eme type dint egrit e qui regroupe toutes les r` egles (parfois complexes) propre ` a la politique interne de lentreprise, cest lint egrit e dentreprise. Exemples de r` egle sp eciques ` a une entreprise : un client ne peut pas commander lorsquil doit d ej` a trop dargent ; un client qui commande r eguli` erement b en ecie de r eductions. Pour impl ementer ce genre de r` egle, on a besoin dune programmation plus elabor ee que les contraintes. Cest lobjet de la section suivante.
ENEMENTIELLE 7 PROGRAMMATION EV
37
Programmation ev enementielle
La premi` ere chose ` a savoir est que pour chaque table il existe en SQL trois ev enements (ni plus ni moins). Ils sont soulev es respectivement par les instructions INSERT, DELETE et UPDATE (cf. 5 page 28). Lobjet de cette section est dapprendre ` a les utiliser.
7.1
Mise-` a-jour et suppression en cascade
Exemple : si on veut d esormais que la suppression dun client entra ne automatiquement celle de ses commandes, 11 il sut pour cela de pr eciser une option lors de la d enition de la contrainte cl e etrang` ere dans la table commandes.
1 2 3 4 5
ALTER TABLE commandes ADD CONSTRAINT fk_cmd_clt FOREIGN KEY (cmd_clt) REFERENCES clients ON DELETE CASCADE ON UPDATE CASCADE
Remarques : de cette fa con, la relation entre les deux tables devient non bloquante en suppression et en mise-` ajour ; il ny a pas ON INSERT CASCADE. Exercice : pourquoi ny a-t-il pas dinsertion en cascade ?
7.2
D eclencheurs AFTER
Un d eclencheur est une proc edure attach ee ` a un ev enement, en anglais on dit TRIGGER. Ces proc edures se d eclenchent automatiquement apr` es que l ev enement concern ea et e soulev e (donc bien souvent ` a linsu de lutilisateur) et ne peuvent etre appel ees directement 12 . Exemple : la table articles contient une colonne qui pr ecise le nombre darticles en commande ; pour mettre ` a jour cette colonne lors dinsertion de nouvelles commandes on cr ee un d eclencheur.
1 2 3 4 5 6 7 8
CREATE TRIGGER commandes_insert -- le nom du declencheur ON commandes AFTER INSERT -- la table et levenement concernes AS -- la programmation du declencheur UPDATE articles SET nb_commande = nb_commande + cmd_qte FROM articles AS a JOIN inserted AS b ON (a.art_num = b.cmd_art) -- (si plusieurs instructions : utiliser un bloc BEGIN ... END)
Quelques mots sur les tables inserted et deleted : il sagit de tables temporaires cr e ees et disponibles pendant l ev enement ; leurs colonnes sont identiques ` a celles de la table sur laquelle l ev enement a et e lev e; le d eclencheur AFTER INSERT peut utiliser la table inserted qui contient toutes les lignes ins er ees ; le d eclencheur AFTER DELETE peut utiliser la table deleted qui contient toutes les lignes supprim ees ;
11. ce nest pas tr` es conseill e 12. en cons equence de quoi la seule fa con de les tester est de soulever l ev enement par une requ ete appropri ee
38
le d eclencheur AFTER UPDATE peut utiliser les deux tables (ce qui est logique puisquune mise-` a-jour consiste en une insertion et une suppression). Autre exemple avec cette fois-ci la table deleted :
1 2 3 4 5 6
CREATE TRIGGER commandes_delete ON commandes AFTER DELETE AS UPDATE articles SET nb_commande = nb_commande - cmd_qte FROM articles AS a JOIN deleted AS b ON (a.art_num = b.cmd_art)
Troisi` eme exemple, sur mise-` a-jour cette fois-ci : pour etre tout ` a fait complet, il faut egalement un d eclencheur qui r eagisse si la colonne cmd qte est touch ee par une mise-` a-jour.
1 2 3 4 5 6 7 8 9 10
CREATE TRIGGER commandes_update ON commandes AFTER UPDATE AS IF UPDATE(cmd_qte) -- si la colonne cmd_qte est touchee par la modification BEGIN UPDATE articles SET nb_commande = nb_commande - b.cmd_qte + c.cmd_qte FROM articles AS a JOIN deleted AS b ON (a.art_num = b.cmd_art) JOIN inserted AS c ON (a.art_num = c.cmd_art) END
Dernier exemple : on veut emp echer la modication du num ero ISBN dun ouvrage.
1 2 3 4 5 6 7 8 9 10
CREATE TRIGGER ouvrages_update ON ouvrages AFTER UPDATE AS IF UPDATE(isbn) BEGIN RAISERROR (Le numero ISBN ne peut pas etre modifie, 0, 1) -- 0 indique la gravite de lerreur et 1 letat (a oublier) ROLLBACK TRANSACTION -- on annulle la transaction qui a declenche levenement END
Remarques : les d eclencheurs sont des transactions ; il faut que lutilisateur qui tente dins erer un emprunt, dispose des droits sur toutes les tables impliqu ees dans la programmation du d eclencheur ; comme on vient de le voir, les d eclencheurs sont notamment utiles pour : impl ementer des r` egles trop complexes pour les contraintes (ne serait que parce quune contrainte ne peut porter que sur une table) ; acher un message derreur personnalis e et annuler la transaction appelante. comme leur nom lindique, un d eclencheur AFTER se produisent apr` es un ev enement ; du coup, les contraintes sont v eri ees avant le lancement des d eclencheurs AFTER, ce qui a pour une cons equence f acheuse : les mises-` a-jour en cascade eventuellement soulev ees par ces d eclencheurs ne se font quapr` es v erication des contraintes ; avec SQL Server il ny a pas de d eclencheurs BEFORE ;
39
par contre les d eclencheurs INSTEAD OF (au lieu de) existent ; cest lobjet du paragraphe suivant. Exercice : en quoi le cinqui` eme point est-il f acheux ?
7.3
D eclencheurs INSTEAD OF
On les utilise si on veut que leurs instructions se lancent ` a la place de linsertion, de la suppression ou de la mise-` a-jour qui a soulev e l ev enement. Avec un d eclencheur AFTER la modication des donn ees a lieu puis le d eclencheur est ex ecut e, tandis quavec un d eclencheur INSTEAD OF le corps du d eclencheur se substitue ` a la modication des donn ees. Dun point de vue syntaxique, il sut de remplacer AFTER par INSTEAD OF. Exemple : on historise automatiquement les commandes ins er ees dans une table historique commmandes.
1 2 3 4 5 6 7 8 9 10 11
CREATE TRIGGER commandes_insert2 ON commandes INSTEAD OF INSERT AS BEGIN INSERT commandes SELECT * FROM inserted -- cette ligne fais linsertion prevue INSERT historique_commmandes SELECT * FROM inserted END -- on aurait donc pu se contenter dun declencher AFTER -- avec seulement le 2e INSERT
Remarques : les tables provisoires inserted et deleted existent et sont remplies pour les d eclencheurs INSTEAD OF (heureusement) ; les d eclencheurs INSTEAD OF ne se d eclenchent pas eux-m emes (heureusement) ; il ne peut y avoir quun d eclencheur INSTEAD OF par ev enement et par table (alors quil peut y avoir plusieurs d eclencheurs AFTER) ; sil existe une cl e etrang` ere avec une action en cascade (DELETE ou UPDATE) dans la table, alors on ne peut pas ecrire le d eclencheur INSTEAD OF correspondant, et inversement. Exercice : pourquoi ces trois derni` eres r` egles existent-elles ?
7.4
Compl ements
Toutes les instructions SQL ne sont pas autoris ees dans le code dun d eclencheur ; on se limitera g en eralement ` a : INSERT, DELETE, UPDATE, RAISERROR et ROLLBACK TRANSACTION. Pour modier un d eclencheur on a :
1 2
ALTER TRIGGER commandes_insert ... -- son nouveau code
Pour supprimer un d eclencheur on a :

1
DROP TRIGGER commandes_insert
ENEMENTIELLE 7 PROGRAMMATION EV Pour suspendre provisoirement un d eclencheur (sans le supprimer) on a :

1 2 3 4 5 6
40
ALTER TABLE commandes DISABLE TRIGGER commandes_insert ... -- dautres instruction puis ALTER TABLE commandes ENABLE TRIGGER commandes_insert
Remarque : on peut remplacer commandes insert par ALL ou commandes insert, commandes insert2. On peut cr eer un d eclencheur pour deux ou trois ev enements ` a la fois. Exemple :
1 2 3 4
CREATE TRIGGER ... ON ... AFTER INSERT, UPDATE AS ...
7.5
Conclusion
Faisons une synth` ese sur le d eroulement dune transaction. Pour chaque instruction de la transaction on a : v erication des autorisations de lutilisateur puis transfert des donn ees n ecessaires du disque dans la m emoire puis remplissage des tables inserted et/ou deleted puis modications (pr evues ou INSTEAD OF et/ou en cascade) des donn ees dans la m emoire puis v erication des contraintes puis d eclencheurs AFTER (*)
(*) (*) (*)
(*) signie qu` a ce stade la transaction peut- etre annul ee. L ecriture des donn ees sur le disque nintervient qu` a la n de la transaction lorsque toutes ses instructions ont et e valid ees.
8 VUES
41
Vues
Une vue est une requ ete SELECT ` a laquelle on donne un nom et dont on peut se servir comme sil sagissait dune table. C a nest pas si surprenant puisque lon peut voir une requ ete SELECT comme une fonction (au sens informatique du terme) qui retourne une table. Contrairement ` a ce que lon pourrait croire, les vues ne conservent pas une copie s epar ee des donn ees.
8.1
Syntaxe
Exemple de d eclaration dune vue : on d esire ne garder quune sous table de la table commandes tout en achant le nom du client et de larticle au lieu de leur num ero.
1 2 3 4 5 6 7
CREATE VIEW VueCommandes -- nom de la vue ([Nom du client], [Article command e]) -- nom des colonnes (plus parlants) AS SELECT b.clt_nom, c.art_nom FROM commandes AS a JOIN clients AS b ON a.cmd_clt = b.clt_num JOIN articles AS c ON a.cmd_art = c.art_num
Puis on peut lutiliser comme une table :

1 2 3
SELECT [Nom du client] FROM VueCommandes WHERE [Article command e] = pinceau
Remarques sur la cr eation des vues : la requ ete SELECT de la vue ne doit ni contenir de clause ORDER BY ni faire r ef erence ` a un table temporaire (cf. 5.1 page 29) ni utiliser de sous-requ ete ; il est conseill e de tester au pr ealable la requ ete SELECT seule ; on peut cr eer une vue ` a partir dautres vues, mais pour des questions de performances il vaut mieux eviter et en revenir aux tables sous-jacentes. Pour modier une vue :
1 2 3 4
ALTER VIEW VueCommandes ( ... ) -- les colonnes AS ... -- nouvelle requete SELECT
Pour supprimer une vue :

1
DROP VIEW VueCommandes
8.2
Int er ets
D esormais les utilisateurs nacc ederont aux donn ees quau travers des vues, seuls les d eveloppeurs manipuleront directement les tables. Cest particuli` erement avantageux car : on peut traduire les intitul es des colonnes en di erentes langues et de mani` ere plus explicite que la nomenclature adopt ee pour la base ; cela simplie les requ etes que les d eveloppeurs vont ecrire pour les utilisateurs (le travail de jointure est d ej` a fait dans la vue, les noms sont plus parlants et les colonnes utiles uniquement aux
8 VUES
42
d eveloppeurs (clt num et art num par exemple) sont cach ees) ; cela simplie la s ecurisation des donn ees (les donn ees sensibles responsables de lint egrit e de la base sont masqu ees et il sura de g erer les autorisations dacc` es aux vues et non pas aux tables) ; et surtout on peut changer la structure de la base (les tables) sans avoir ` a modier la programmation pour les utilisateurs (on changera eventuellement la programmation des vues mais pas celle des requ etes qui utilisent ces vues). Illustration du dernier point : admettons que la table commandes soit scind ee en deux tables commandes2001 et commandes2002. Seules les requ etes qui utilisent la table commandes doivent etre re-programm ees.
1 2 3 4 5 6 7 8 9 10 11 12
ALTER VIEW VueCommandes ([Nom du client], [Article command e]) AS SELECT b.clt_nom, c.art_nom FROM commandes2001 AS a JOIN clients AS b ON a.cmd_clt = b.clt_num JOIN article AS c ON a.cmd_art = c.art_num UNION SELECT b.clt_nom, c.art_nom FROM commandes2002 AS a JOIN clients AS b ON a.cmd_clt = b.clt_num JOIN article AS c ON a.cmd_art = c.art_num
Toutes les requ etes qui utilisent les vues restent inchang ees.
1 2 3
SELECT [Nom du client] FROM VueCommandes WHERE [Articles command e] = pinceau
Lorsquune base de donn ees est d eploy ee ` a l echelle dune entreprise, le m ecanisme des vues ore une interface entre limpl ementation (les tables) et les utilisateurs qui permet au code SQL une plus grande facilit e de maintenance
8.3
Modication de donn ees
Comme on vient de voir, la consultation des donn ees ` a travers une vue ne pose pas de probl` eme. Le probl` eme essentiel avec les vues est la grande dicult e de modier les donn ees. En eet, plusieurs cas pathologiques peuvent en eet se pr esenter : il se peut quune colonne d eclar ee NOT NULL ne soit pas visible ` a travers la vue exemple : comment ajouter une commande avec la vue VueCommandes alors que : la colonne cmd num est cl e primaire donc NOT NULL les colonnes cmd clt et cmd art sont cl es etrang` eres et NOT NULL et ne gurent pas dans la vue ? et comment ajouter des donn ees dans une vue mutli-tables ? exemple : on voudrait par exemple ajouter automatiquement un nouveau client ` a sa premi` ere commande.
8 VUES Malheureusement, la requ ete suivante nest pas autoris ee :

1 2 3 4
43
BEGIN TRAN INSERT VueCommandes VALUES(Fricotin, Stylo) COMMIT TRAN
La solution consiste ` a employer un d eclencheur INSTEAD OF. Exemple :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
CREATE TRIGGER VueCommandes_insert ON VueCommandes INSTEAD OF INSERT AS BEGIN -- jinsere dabord les nouveaux clients dans la table clients INSERT clients(clt_nom) SELECT [Nom du client] FROM inserted WHERE [Nom du client] NOT IN (SELECT clt_nom FROM clients) -- jinsere ensuite les commandes elles-memes -- avec tous les renseignements necessaires INSERT commandes(cmd_date, cmd_clt, cmd_art) SELECT GETDATE(), b.clt_num, c.art_num FROM inserted AS a JOIN clients AS b ON a.[Nom du client] = b.clt_nom JOIN articles AS c ON a.[Article command e] = c.art_nom END
Avec ce d eclencheur, la requ ete dinsertion pr ec edente fonctionne. Exercice : pourquoi na-t-on pas eu besoin de pr eciser ni clt num dans le premier INSERT ni cmd num dans le deuxi` eme ? Remarques : GETDATE() renvoie la date daujourdhui ; on a fortement suppos e dans ce d eclencheur que les clients portaient un nom unique et que les articles aussi, cest pourquoi il vaut mieux respecter les conseils suivant lors de la cr eation dune vue : sarranger pour ne jamais avoir de doublons dans la vue ( ca peut vouloir dire par exemple ajouter une contrainte UNIQUE ` a la colonne clt nom dans la table client ou inclure la cl e primaire) ; toutes les colonnes NOT NULL que lon ecarte doivent pouvoir recevoir une valeur calcul ee (cest le cas de cmd date, cmd clt et cmd art) ou une valeur par d efaut (cest le cas de cmd num) 13 ; le seul d eclencheur disponible pour les vues est INSTEAD OF (et pas AFTER contrairement aux tables) ; quand on ins` ere dans une vue avec SQL Server, il faut malheureusement remplir toutes les colonnes et on ne peut pas faire appel ` a la valeur NULL.
13. bref, cest dicile de cacher les cl es primaires, les cl es etrang` eres et plus g en eralement toutes les colonnes NOT NULL car une vue d enormalise les donn ees, ce qui repr esente un danger
9 PROCEDURES STOCKEES Illustration de ce dernier point : on modie la pr ec edente vue, en lui ajoutant deux colonnes
1 2 3 4 5 6 7
44
ALTER VIEW VueCommandes ([Num ero de commande], [Nom du client], [Article command e], Date) AS SELECT a.cmd_num, b.clt_nom, c.art_nom, a.cmd_date FROM commandes AS a JOIN clients AS b ON a.cmd_clt = b.clt_num JOIN articles AS c ON a.cmd_art = c.art_num
on veut ins erer dans cette vue (en utilisant le m eme d eclencheur) mais en laissant SQL Server calculer le num ero de commande et la date de commande :
1 2 3 4 5
BEGIN TRAN INSERT VueCommandes VALUES(, Fricotin, Stylo, ) -- on est oblige demployer des valeurs bidons COMMIT TRAN
Proc edures stock ees
En pratique, les programmes qui utilisent les donn ees dune base ne font pas directement appel aux transactions, mais plut ot ` a des proc edures auxquelles ils peuvent passer des arguments.
9.1
Syntaxe
Le langage Transact-SQL permet de programmer ces proc edures selon la syntaxe suivante : CREATE PROC ... (...) AS DECLARE ... BEGIN ... END le nom de la proc edure les param` etres dentr ee et de sortie s epar es par des virgules les variables locales les instructions, les transactions
Remarques : on peut utiliser jusqu` a 1024 param` etres ; la syntaxe dune proc edure stock ee est limit ee ` a 128 Mo. Exemple : une requ ete param etr ee
1 2 3 4 5 6
CREATE PROC InfoDuClient (@numero INT) AS SELECT * FROM clients WHERE clt_num = @numero
-- ne pas oublier de preciser le type
9 PROCEDURES STOCKEES Autre exemple avec un param` etre de sortie :

1 2 3 4 5
45
CREATE PROC NbClients (@resultat INT OUTPUT) AS SET @resultat = (SELECT COUNT(*) FROM clients) -- il sagit-la dune sous-requete
Dernier exemple avec un param` etre dentr ee muni dune valeur par d efaut :
1 2 3 4 5 6 7
CREATE PROC FiltrerClients (@filtre VARCHAR(255) = %) AS SELECT * FROM clients WHERE clt_nom LIKE @filtre -- en labsence de parametre tous les clients seront affiches
Pour modier une proc edure stock ee :

1 2 3 4
ALTER PROC InfoDuClient (...) -- les parametres AS ... -- nouveau corps
Pour supprimer une proc edure stock ee :

1
DROP PROCEDURE InfoDuClient
9.2
Utilisation
On peut ensuite utiliser ces proc edures stock ees dans du code SQL avec linstruction EXEC. Exemple : pour avoir les informations relatives au client 12
1 2
EXEC InfoDuClient 12 -- 12 est la valeur du param` etre
Remarques : on peut aussi utiliser des variables comme valeurs de param` etre (et pas seulement des constantes comme dans lexemple) ; si la proc edure a besoin dune liste de param` etres, il faut les s eparer par des virgules ; sil y a un param` etre de sortie, il faut en stocker la valeur de retour dans une variable. Exemple :
1 2 3 4
DECLARE @NombreTotalDeClients INT EXEC NbClients @NombreTotalDeClients OUTPUT -- et apres, on peut utiliser le contenu de la variable @NombreTotalDeClients
10
VERROUS
46
9.3
Cryptage
Lorsque de la cr eation ou de la modication dun d eclencheur, une vue, une fonction ou une proc edure stock ee (bref, tout ce qui contient le code SQL destin e aux utilisateurs), on peut pr eciser la clause WITH ENCRYPTION qui permet de crypter le code de ces objets. Cela permet de prot eger la propri et e intellectuelle des d eveloppeurs sous SQL Server. Exemples :
1 2 3 4
CREATE VIEW VueCommandes(Client, Article) WITH ENCRYPTION AS ...
1 2 3 4 5
ALTER PROC InfoDuClient (@numero INT) WITH ENCRYPTION AS ...
10
Verrous
Comme les transactions sont trait ees en ligne sur un serveur multi-utilisateur, les acc` es concurrentiels aux donn ees doivent etre g er es. Pour emp echer les autres utilisateurs de modier ou de lire des donn ees faisant lobjet dune transaction qui nest pas encore termin ee, il faut verrouiller ces donn ees. Rappelons que lors dune transaction : les donn ees n ecessaires sont lues sur le disque puis charg ees en m emoire centrale ; les op erations ont lieu dans la m emoire centrale ;
Fig. 7 Traitement des donn ees dune transaction en m emoire une fois toutes les instructions valid ees, les nouvelles donn ees sont ecrites sur le disque. Si les donn ees sur le disque sont modi ees pendant la transaction, celle-ci travaille avec des donn ees fausses. On a alors un probl` eme de coh erence.
10.1
Isolation
Par d efaut, SQL Server ne garantit pas que les donn ees utilis ees seront les m emes pendant toute la transaction. Pour lobliger ` a rendre maximal le verrouillage des donn ees il faut lui imposer de mettre en s erie les transactions concurrentes. Pour cela on dipose de linstruction :
1
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
10
VERROUS
47
Le probl` eme majeur de la mise en s erie des transactions est quune transaction interminable bloque toutes les suivantes. Il est possible de pr eciser un d elai dattente maximal pour cause de verrouillage (par d efaut il ny en a pas). Pour cela on utilise linstruction :
1 2 3
SET LOCK_TIMEOUT 180000 -- definit un delai dexpiration de 3 minutes (en millisecondes) -- au dela de ce delai, la transaction en attente est annulee
Remarques : ces instructions sont attach ees ` a la connexion qui les ex ecute ; ces instructions restent valables pour toutes les transactions qui suivent, jusqu` a la d econnexion ou jusqu` a nouvel ordre. Le niveau disolation par d efaut est READ COMMITTED, il garantit seulement que les donn ees sont coh erentes au moment de leur lecture (et pas pendant le reste de la transaction). Pour y revenir il sut d ecrire :
1
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
10.2
Verrouillage de niveau table
Dans ce paragraphe on suppose que lon se trouve au niveau disolation READ COMMITTED. ` chaque transaction on peut indiquer le type de verrouillage pour chaque table utilis A ee par les instructions SELECT, INSERT, DELETE et UPDATE. Par d efaut, SQL Server verrouille les tables concern ees. On peut obliger SQL Server ` a laisser le verrou jusqu` a la n de la transaction :
1 2 3 4
BEGIN TRAN UPDATE clients WITH(HOLDLOCK) SET ... COMMIT TRAN
On peut se contenter de verrouiller seulement les lignes concern ees par la transaction :
1 2 3 4
BEGIN TRAN UPDATE clients WITH(ROWLOCK) SET ... COMMIT TRAN
Lorsquune premi` ere requ ete utilise WITH(ROWLOCK), on peut indiquer ` a une deuxi` eme dignorer les lignes verrouill ees (an de ne pas bloquer la transaction) :
1 2
SELECT AVG(clt_ca) FROM clients WITH(READPAST)
10.3
Conclusion
On veillera ` a respecter les consignes suivantes pour les transactions : elles doivent etre aussi courtes que possible an d eviter les les dattente trop longues ; il ne faut pas les imbriquer (m eme si cest possible, ca ne sert ` a rien) ; ne surtout pas interagir avec lutilisateur pendant la transaction (mais avant).
11
CONNEXIONS
48
Il est souvent bon de suivre ces quelques conseils concernant les verrous : mettre en s erie les transactions de toutes les connexions utilisateurs ; laisser SQL Server g erer la granularit e des verrous : le laisser d ecider sil faut verrouiller les lignes dune table ou la table enti` ere, cest-` a-dire nutiliser ni WITH(ROWLOCK) ni WITH(PAGLOCK) ni WITH(TABLOCK) (dont on a pas parl e ici dailleurs).
11
Connexions
On a d ej` a plusieurs fois mentionn e la n ecessit e dattribuer les bons droits aux utilisateurs de notre a g erer ces utilisateurs, leurs base de donn ees (cf. 5 page 28). Lobjectif de cette section est dapprendre ` droits et de prot eger les d eveloppeurs.
11.1
Cr eation
IL existe deux fa con dajouter un nouveau compte de connexion : on peut le cr eer de toute pi` ece
1 2 3 4
sp_addlogin Paul, luaP, Northwind
-- le login -- le mot de passe -- la base par defaut
ou bien h eriter dune connexion Windows

1 2 3 4
sp_grantlogin STID/Henri -- STID etant le nom du domaine sp_defaultdb STID/Henri, Northwind
Il reste ensuite ` a lui donner acc` es au serveur :

1
sp_grantdbaccess Paul
On dispose evidemment des proc edures :

1 2 3
sp_revokedbaccess Paul sp_droplogin Paul
11
CONNEXIONS
49
11.2
R ole
Il est possible (et conseill e) de regrouper les utilisateurs selon les autorisations quils ont, cest-` a-dire de d enir des r oles. 11.2.1 Sur le serveur
Il existe 8 r oles sur serveur dans SQL Server dont : nom du r ole sysadmin securityadmin dbcreator droits de ses membres tous les droits sur le syst` eme et toutes les base gestion des acc` es ` a SQL Server cr eation de bases de donn ees
Pour ajouter et radier un utilisateur ` a lun de ces r oles :

1 2 3
sp_addsrvrolemember Paul, dbcreator sp_dropsrvrolemember Paul, dbcreator
Un m eme utilisateur peut cumuler plusieurs r oles. 11.2.2 Dans une base de donn ees
Dans chaque base on dispose des r oles suivants : nom du r ole db owner db accessadmin db datareader db datawriter db ddladmin db securityadmin db public droits de ses membres tous les droits sur les objets de la base ajout dutilisateurs et de r oles lire le contenu des tables insertion, suppression et modication sur toutes les tables cr eation, modication, suppression dobjet gestion des r oles et des autorisations a d ` enir
Tous les utilisateurs appartiennent au r ole public et peuvent appartenir ` a dautres r oles. Pour ajouter un r ole et un utilisateur ` a ce r ole :
1 2 3
sp_addrole ServiceInformatique sp_addrolemember ServiceInformatique, Henri
On a aussi :
1 2 3 4
sp_droprolemember ServiceMarketing, Paul sp_droprole ServiceMarketing -- possible uniquement sil ne reste plus aucun membre dans ce role
11
CONNEXIONS
50
11.3
Droits
Dans ce paragraphe, on se place dans une base. 11.3.1 Sur les instructions
Exemple : pour autoriser les utilisateurs Paul et Henri ` a cr eer des tables et des d eclencheurs
1 2
GRANT CREATE TABLE, CREATE TRIGGER TO Paul, Henri
Remarque : Paul et Henri doivent d ej` a poss eder un compte utilisateur sur SQL Server. Autre exemple : pour emp echer Paul de cr eer des vues
1 2
DENY CREATE VIEW TO Paul
Dernier exemple : pour lever les autorisations et les emp echements de Paul
1 2
REVOKE CREATE VIEW, CREATE TABLE TO Paul
Remarques : REVOKE annule le dernier GRANT ou DENY correspondant ; apr` es un REVOKE, SQL Server sen remet aux autorisations par d efaut du r ole dont Paul est membre ; on peut utiliser le mot-cl e ALL pour d esigner toutes les instructions. 11.3.2 Sur les objets
Dans une base de donn ees, pour chaque table, chaque colonne et chaque instruction on peut pr eciser les autorisations. Exemple : pour autoriser la s election sur la table clients
1 2
GRANT SELECT ON clients TO Paul
Autre exemple : pour emp echer les autres instructions

1 2
DENY INSERT, UPDATE, DELETE ON clients TO Paul
Dernier exemple : pour autoriser la modication mais seulement du nom de client

1 2
GRANT UPDATE(clt_nom) ON clients TO Paul
Remarques : en g en eral on a pas besoin de descendre jusqu` a la colonne, il est pr ef erable de cr eer une vue et de donner les droits sur cette vue ;
12
FORMULAIRES
51
(important) il vaut mieux utiliser ALTER ... car les autorisations sur lobjet concern e sont conserv ees, contrairement ` a DROP ... suivi de CREATE ... 11.3.3 Cha ne dautorisation
Sont habilit es ` a d elivrer des autorisations GRANT, DENY et REVOKE : les membres du r ole sysadmin dans toutes les bases ; les membres du r ole db owner sur les instructions et le objets de leur base ; 14 les propri etaires dobjet(s) sur leur(s) objet(s). Pour habiliter un utilisateur ` a d elivrer les autorisations dont il b en ecie, il sut dajouter la clause WITH GRANT OPTION. Exemple :
1 2 3 4 5 6 7 8
-- avec GRANT SELECT ON clients TO Paul WITH GRANT OPTION -- Paul peut desormais ecrire GRANT SELECT ON clients TO Henri
Conseil : pour eviter tout probl` eme de rupture de cha ne dautorisation avec les vues, il faut que le 15 dbo soit propri etaire des vues.
12
Formulaires
Un formulaire (informatique) est un outil de saisie dinformations (en petites quantit es) ` a lordinateur. Il sagit dune interface entre la base de donn ees et les utilisateurs non sp ecialistes et/ou nayant pas dacc` es direct ` a la base.
12.1
Historique
L equivalent papier dun formulaire est, par exemple : une che de renseignements ou une facture. Pendant longtemps, les formulaires informatiques etaient en mode texte (cest-` a-dire occupant l ecran dun terminal nachant que des caract` eres). Il en reste encore beaucoup (en partie ` a cause de leur robustesse). Aujourdhui, les formulaires sont programm es en langage objet (Java ou Visual Basic par exemple), ce qui leur permet dorir une interface graphique (compos ee de boutons, fen etres et contr oles). Les formulaires graphiques reprennent lergonomie des formulaires textes, mais orent une plus grande libert e dans la disposition des champs ` a renseigner.
14. le propri etaire est celui qui a cr e e lobjet 15. le propri etaire de la base
12
FORMULAIRES
52
12.2
Lien avec la base de donn ees
Un formulaire qui permet de modier les donn ees dune base est compos e de : contr oles ind ependants (essentiellement, les etiquettes et les el ements de d ecoration) ; contr oles d ependants (cest-` a-dire li es aux colonnes de la base) ; contr oles calcul es (un montant total par exemple) qui informent lutilisateur et qui r esultent dop erations entre plusieurs donn ees. Ce sont les contr oles d ependants qui nous int eressent ici. Si le syst` eme transactionnel est bien con cu, les contr oles d ependants nacc` edent aux donn ees qu` a travers des vues et le formulaire ne peut modier les donn ees de la base quen invoquant des proc edures stock ees. Le lien tr` es fort qui uni un formulaire ` a sa base de donn ees, pose de gros probl` emes de maintenance (en cas de changement de SGBD, de sch ema relationnel ou de type de donn ees par exemple) et de r eutilisabilit e. Les vues et les mod` eles orient es objets traduit du m eme mod` ele conceptuel que le sch ema relationnel sont des solutions. Mais, il faut souvent faire appel ` a une couche sup erieure pour faire le lien entre ces composants (cest le r ole des environnements de d eveloppement comme .NET et J2EE (Struts notamment)).
12.3
Validation des donn ees
Les formulaires doivent, au moins, ob eir aux m emes r` egles dint egrit e que la base de donn ees sousjacente (an, notamment, de g erer les erreurs de validation au niveau du formulaire). Le concepteur dun formulaire ne doit donc pas se contenter dune zone de texte (qui permet la saisie au clavier dune cha ne de caract` eres, dun entier, dun r eel ou dune date et heure) pour chaque champ ` a remplir. 12.3.1 Int egrit e de domaine
Le type de donn ees dun contr ole doit correspondre au type de donn ees de la colonne sous-jacente. Pour les donn ees num eriques (entier ou r eel), le contr ole potentiom` etre et toupie permettent leur saisie a la souris (toutefois, il est bon de les accompagner dune zone de texte dans laquelle on peut saisir la ` valeur souhait ee directement au clavier). Pour les donn ees binaires (oui ou non), le contr ole case ` a cocher est tout indiqu e. Pour les dates, les outils de cr eation de formulaire ore souvent un contr ole calendrier . En tout cas, le r esultat pour une date ou pour une heure est une zone de texte avec un format de contr ole strict. Les contr oles orent bien souvent des formats de contr ole et des r` egles de validation qui permettent de reproduire certaines contraintes CHECK. De plus, pour les contraintes CHECK IN, on dispose du contr ole bouton radio (ou groupe doptions ) qui est utilisable lorsque la liste des choix disponibles est connue et restera inchang ee (ce qui est rare ; en g en eral, les choix sont list es dans une colonne dune autre table). Un contr ole peut egalement recevoir une valeur par d efaut (coh erente avec la base) et la notion de champ obligatoire permet de traduire le caract` ere vide autoris e ou non. 12.3.2 Int egrit e des entit es
G en eralement, il nest pas n ecessaire de sen soucier dans les formulaires, car elle est assur ee par la num erotation automatique (et lint egrit e r ef erentielle lorsque la cl e primaire est compos ee de cl e(s) etrang` ere(s)). La seule op eration ` a mener dans le formulaire est de rendre le champ correspondant ` a la cl e, insaisissable an que lutilisateur ne puisse le modier. Cependant, les contraintes UNIQUE sont plus diciles ` a traduire dans les formulaires.
12
FORMULAIRES Int egrit e r ef erentielle
53
12.3.3
Le contr ole liste d eroulante permet de choisir une valeur parmi une liste de valeurs contenues dans une autre colonne, ce qui convient parfaitement pour remplir une cl e etrang` ere (issue dune association de type 1 : n, le client dune facture par exemple). Il faut cependant sp ecier au contr ole dinterdire ` a lutilisateur de sortir de la liste propos ee. Il est egalement conseill e de rendre les listes ergonomes, en faisant d erouler plusieurs colonnes si n ecessaire (le num ero du client car on en a besoin, accompagn e de son nom pour le retrouver facilement, par exemple) et en triant la colonne la plus pertinente (le nom du client, en loccurrence). Pour les associations de type n : m, on peut utiliser les listes ` a choix multiples (cela permet par exemple, pour un lm, de s electionner les acteurs qui y participent parmi une liste dacteurs pr ed enie). Avec la liste d eroulante, il faut que la ligne r ef erenc ee (le client, par exemple) par la cl e etrang` ere (dans la commande en cours de saisie) existe d ej` a. Malheureusement, un formulaire est souvent charg e de saisir ` a la fois la ligne r ef erenc ee et les lignes qui la r ef erence (la commande et ses lignes de commandes, par exemple). Pour cela, nous disposons du contr ole sous-formulaire qui permet de saisir les lignes de commandes une par une dans le m eme formulaire qui permet la saisie dune commande. Le sous-formulaire doit etre con cu sous la forme dune ligne de contr oles sans intitul es dans la zone D etail (les intitul es sont plac es en en-t ete, tandis que les totaux sont plac es en pied de sous-formulaire). Il appara tra alors sous la forme dun tableau dans le formulaire et dans lequel il y aura autant de lignes que n ecessaire. Cette notion de sous-formulaire est tr` es utile dans un formulaire d edi e` a la consultation des donn ees. On peut par exemple, acher synth etiquement toutes les commandes dun client en particulier. Mais l` a, nous sortons du cadre des syst` emes transactionnels et entrons dans le d ecisionnel (cf. le chapitre sur les etats page 62). 12.3.4 Int egrit e dentreprise
Elle est normalement assur ee par les d eclencheurs dans la base de donn ees. Cependant, il est parfois n ecessaire de la reproduire dans un formulaire (an de tenir compte de ces r` egles et de g erer leurs violations au niveau du formulaire). Pour cela, nous disposons : des r` egles de validation au niveau des contr oles (qui permettent dimpl ementer des r` egles plus g en erales que les contraintes CHECK) ; de la programmation ev enementielle (qui permet, par exemple, de d esactiver le sous-formulaire concernant les enfants, si le nombre denfants saisi est 0) ; des contr oles calcul es (qui permettent dacher le montant dune facture en tenant compte de la remise oerte aux bons clients, par exemple).
12
FORMULAIRES
54
12.4
Ergonomie
Un formulaire ne doit pas d epasser la taille de l ecran et la taille dune feuille sil est destin e` a etre ` partir de l` imprim e. A a, on peut disposer les champs ` a renseigner dans un ordre logique, retirer les champs insaisissables des arr ets de tabulation et sarranger pour que les tabulations entre les champs saisissables suivent la m eme logique. Les contr oles doivent etre susamment larges pour que lutilisateur puisse en lire le contenu. Il est egalement bon de trier les listes d eroulantes et les listes ` a choix multiples et ne pas h esiter ` a lister plusieurs colonnes en m eme temps. Les contr oles sont des objets qui r eagissent ` a des ev enements dont les principaux sont : lentr ee dans le contr ole (par le clavier ou la souris) ; la sortie du contr ole ; ou le changement de valeur du contr ole. ` ces A ev enements, on peut associer les actions suivantes : recalculer un autre contr ole (mettre ` a jour une liste d eroulante par exemple) ; activer ou d esactiver un autre contr ole ; ou encore, acher un message derreur intelligible en cas de violation dune r` egle de validation des donn ees. Les boutons sont des objets qui r eagissent principalement ` a l ev enement clic et qui permettent, par exemple, denregistrer la saisie (en appelant les proc edures stock ees), dimprimer la che ou douvrir un autre formulaire (pour saisir un nouveau client, pendant quon etablit sa premi` ere facture, par exemple). ` ce propos, il ne faut pas exag A erer la d ecomposition de la saisie dune che en plusieurs formulaires simples (certains vont jusqu` a une question par formulaire), car le passage des informations dun formulaire ` a un autre est ardu. Il vaut mieux activer les contr oles les uns apr` es les autres (au fur et ` a mesure de la saisie). Finalement, lessentiel de la programmation en langage objet dans un formulaire, porte sur la gestion des ev enements et la r ecup eration des donn ees saisies dans les contr oles an de les envoyer au SGBD.
CONCLUSION
55
Conclusion sur la partie transactionnelle

Nous venons de voir comment d evelopper des bases de donn ees de production (cest-` a-dire mise-` a-jour continuellement par les utilisateurs). Ces bases de production constituent un syst` eme client-serveur, o` u le client eectue ses mise-` a-jour ` a travers des ecrans xes et o` u le serveur g` ere ces modications sous forme de transactions programm ees ` a lavance. On retrouve toujours le m eme sch ema (cf. gure 8) dans lequel : les utilisateurs munis de leurs connexions et de leurs autorisations utilisent des interfaces graphiques ; ces formulaires font appel ` a des proc edures stock ees ; qui mettent en jeu des transactions (et leurs verrous) ; ces transactions sappuient sur des vues (et leurs d eclencheurs) ; qui sont les seules ` a acc eder v eritablement aux tables (et leurs contraintes).
Fig. 8 Sch ema du syst` eme transactionnel
CONCLUSION
56
On peut facilement prendre comme illustration une op eration bancaire ` a un guichet automatique (cf. gure 9) : le client de la banque muni de sa carte et de son code utilise linterface graphique du distributeur de billets ; cette application d eclenche sur le serveur de la banque la proc edure de retrait dargent ; cette proc edure fait au moins appel ` a une transaction qui se charge de d ebiter le compte (avec un verrouillage du compte pendant lop eration) ; ajouter une ligne au relev e de compte ; on imagine que derri` ere cette transaction se trouve une vue regroupant les donn ees n ecessaires ` a lop eration et un d eclencheur permettant la modication des donn ees ` a travers cette vue ; donn ees qui sont organis ees de mani` ere sophistiqu ee dans la base de donn ees de la banque qui respecte avec la plus grande rigueur les di erents type dint egrit e.
un client muni de sa carte et de son code
l'interface graphique du distributeur
la procdure de retrait d'argent
la transaction pour dbiter et verrou sur le compte
donnes ncessaires l'opration
base de donnes de la banque
Fig. 9 Exemple de transaction
57
Deuxi` eme partie
Le syst` eme d ecisionnel

En anglais on parle de syst` eme OLAP (On Line Analytical Processing). Il sagit ici de sint eresser aux besoins des d ecideurs, ` a savoir, transformer les donn ees en connaissances voire en pr evisions, cest-` a-dire eque : lhistorique des emprunts repr esente les donn ees, en information.Prenons lexemple dune biblioth` le nombre moyen demprunts dun membre au cours dune ann ee est de lordre de la connaissance, tandis que la tendance ` a la baisse ou ` a laugmentation des inscriptions est une pr evision. Exemple de questions d ecisionnelles : quels sont les clients les plus protables ? quels sont les produits en perte de vitesse ? ` a quel chire daaire sattendre pour lann ee prochaine ?
Di erences avec le syst` eme transactionnel

Contrairement au syst` eme OLTP, ici, on a besoin deectuer des requ etes purement consultatives et sur un grand nombre de donn ees que lon doit regrouper. Dune part, ces requ etes risquent de fortement perturber le syst` eme transactionnel (souvent d ej` a satur e), dautre part, si elles sappuient sur le sch ema relationnel de la base de donn ees, alors elles seront trop longues ` a r epondre (` a cause des jointures). Par ailleurs, on ne stocke pas lhistorique des donn ees dans une base de production : g en eralement, la tables clients contient les clients quon a et ne sencombre pas des clients quon a eu. Les informations contenues dans une base de production sont les plus ` a jour possible (et cest normal). Enn, les donn ees n ecessaires ` a un processus d ecisionnel peuvent se trouver r eparties sur plusieurs syst` emes OLTP, eux-m emes parfois g er es par di erents SGBD (en raison dun manque de centralisation des d eveloppements dans lentreprise, ou ` a la suite dune fusion de plusieurs services informatiques). Toutes ces raisons rendent inutilisables les tableaux de bord que lon peut mettre en place dans les bases de production et ont conduit ` a l elaboration du syst` eme OLAP, plus sophistiqu e. ` noter que le march A e mondial de lOLAP est tr` es di erent du march e OLTP. En eet, le march e OLAP en 2002 (comme en 2001) a et e domin e par Microsoft (Analysis Services) et Hyperion (Essbase), avec Cognos (PowerPlay) et Business Objects derri` ere. Oracle et IBM sont loin derri` ere et en recul (source : [15]).
Entrep ots et cubes

Pour toutes ces raisons, la demarche OLAP consiste ` a copier et historiser les donn ees dans un entrep ot de donn ees (data warehouse) 16 . Pour des raisons qui s eclairciront plus tard dans lexpos e, ces donn ees sont stock ees sous forme de cubes plut ot que dans des tables reli ees entre elles 17 . Le premier exemple de cube que lon peut donner est le suivant (cf. gure 10) : un cube tridimensionnel o` u horizontalement sont d etaill ees les ann ees, verticalement les produits et, dans la profondeur, ` lintersection dune ann les pays. A ee (2003), dun produit A et dun pays (France) on trouve une cellule contenant le montant des ventes et le prix unitaire du produit A en 2003 en France.
16. un magasin de donn ees (data mart) ne sint eresse qu` a un secteur de lentreprise, tandis que lentrep ot de donn ees se situe au niveau de lentreprise 17. cest l` a toute la di erence entre les entrep ot de donn ees et les infocentres avec lesquels les donn ees sont eectivement extraire des bases de production et consolid ees sur un autre serveur, mais pas organis ees en cubes
58
Fig. 10 Exemple de cube : le cube ventes Lentrep ot de donn ees contient donc des informations dat ees et non volatiles. Il est aliment e par des extractions p eriodiques portant eventuellement sur plusieurs sources de donn ees pendant les plages horaires peu occup ees (la nuit). Ces donn ees sont egalement pr e-agr eg ees et structur ees de mani` ere multidimensionnelle, ce qui permet de simplier et dacc el erer consid erablement les requ etes. Les utilisateurs (d ecideurs) et la machine peuvent alors v eritablement interagir. Il faut tout de suite prendre conscience que pour bien construire un entrep ot de donn ees dans une entreprise, il faut bien conna tre les m etiers utilisateurs (cest-` a-dire le metier danalyste marketing sil sagit des donn ees sur les ventes de produits par exemple).
Plan de lexpos e
Il sagit pour nous de concevoir et de consulter les cubes avec Analysis Services et le langage MDX (MultiDimensional eXpression) qui est aux cubes ce que SQL est aux tables ... Mais avant, nous evoquons deux el ements d ecisionnels compl ementaires des cubes OLAP : les groupes de donn ees et les etats. On aborde egalement la phase dextraction de donn ees, les objets virtuels ainsi que deux algorithmes de data mining : la clusterisation ; et les arbres de d ecisions. De nouveau, nous laisserons de c ot e la construction dinterfaces graphiques de consultation et ladministration (sauvegarde, optimisation, etc.) des entrep ots. Le lecteur sera libre de consulter [8] sur ces sujets.
13
AGREGER LES DONNEES
59
13
Agr eger les donn ees
Revenons un instant sur les requ etes de s election dont nous navons pas totalement fait le tour au cours de la premi` ere partie.
13.1
Groupes
On peut grouper les lignes r esultant dune requ ete SQL et en proter pour eectuer des mesures sur ces groupes. Comptons par exemple le nombre de commandes et calculons le montant total par client :
1 2 3 4
SELECT cmd_clt, COUNT(cmd_num) AS NbCommandes, SUM(cmd_montant) AS [Montant total] FROM commandes GROUP BY cmd_clt
Dans le r esultat de cette requ ete, chaque ligne est un groupe : cmd clt 0001 0007 1122 3344 NbCommandes 3 8 1 12 Montant total 500.00 1234.56 32.60 788.54
Rappel : COUNT, SUM, AVG, VAR, STDEV, MIN et MAX sont des fonctions dagr egat. Elles retournent une information par groupe (un agr egat). Elles ignorent la valeur NULL (donc COUNT(18 lignes dont 2 NULL) renvoie 16) sauf COUNT(*). Si on veut que la valeur NULL joue un r ole dans lagr egation, alors on peut toujours utiliser la fonction ISNULL (cf. 4.7 page 25). Pour exclure certaines lignes de la table avant groupement, on utilise la clause WHERE. Exemple, pour ne garder que les commandes des 6 derniers mois :
1 2 3 4 5
SELECT cmd_clt, COUNT(cmd_num) AS NbCommandes, SUM(cmd_montant) AS [Montant total] FROM commandes WHERE cmd_date >= DATEADD(MONTH, -6, GETDATE()) GROUP BY cmd_clt
Pour exclure certains groupes (donc apr` es groupement) on ne peut pas utiliser la clause WHERE mais la clause HAVING. Exemple, pour nacher que les clients qui ont strictement plus de 5 commandes :
1 2 3 4 5
SELECT cmd_clt, COUNT(cmd_num) AS NbCommandes, SUM(cmd_montant) AS [Montant total] FROM Commandes GROUP BY cmd_clt HAVING COUNT(cmd_num) > 5
Le r esultat de cette requ ete est : cmd clt 0007 3344 NbCommandes 8 12 Montant total 1234.56 788.54
13
AGREGER LES DONNEES
60
Remarque : la r edaction une clause HAVING admet les m emes conditions que celle dune clause WHERE (cf. 4.1 page 19) et tout comme les clauses WHERE on ne peut malheureusement pas utiliser les alias d enis dans la clause SELECT.
13.2
Compl ements
On peut grouper selon plusieurs colonnes, et ` a partir de plusieurs tables. Exemple, ajoutons un sousgroupe selon le pays dachat :
1 2 3 4 5
SELECT a.cmd_clt, b.btq_pays, COUNT(cmd_num) AS NbCommandes, SUM(cmd_montant) AS [Montant total] FROM commandes AS a JOIN boutiques AS b ON a.cmd_btq = b.btq_num GROUP BY a.cmd_clt, b.btq_pays
Dans le r esultat de cette requ ete on a une ligne par sous groupe : cmd clt 0001 0007 0007 1122 3344 3344 btq pays France France Italie Italie Italie France NbCommandes 3 4 4 1 6 6 Montant total 500.00 1000.00 234.56 32.60 394.27 394.27
Remarques : lordre des colonnes dans la clause GROUP BY na pas dimportance ; toutes les colonnes de la clause SELECT ne faisant pas lobjet dune fonction dagr egat doivent gurer dans la clause GROUP BY et inversement ; la clause WHERE ne peut porter que sur des colonnes non agr eg ees (dont celle de la clause GROUP BY), alors que la clause HAVING peut porter sur toutes les colonnes de la clause SELECT ; par contre, la clause WHERE peut acc eder aux colonnes non ach ees, tandis que la clause HAVING ne le peut pas. Pour ordonner les groupes et les sous-groupes (ce qui nest pas le cas par d efaut) il sut dutiliser la clause ORDER BY :
1 2 3 4 5 6
SELECT a.cmd_clt, b.btq_pays, COUNT(cmd_num) AS NbCommandes, SUM(cmd_montant) AS [Montant total] FROM commandes AS a JOIN boutiques AS b ON a.cmd_btq = b.btq_num GROUP BY a.cmd_clt, b.btq_pays ORDER BY b.btq_pays, [Montant total]
Remarque : la clause ORDER BY sapplique apr` es groupement et peut sappuyer sur toutes les colonnes de la clause SELECT. ` noter enn qu` A a ce stade, une requ ete GROUP BY ne peut acher que les agr egats des sous-groupes du niveau le plus bas. Si lon d esire acher les agr egats des sous-groupes des autres niveaux (sous-total et total, par exemple), on peut ajouter ` a la clause GROUP BY, soit WITH ROLLUP soit WITH CUBE (cf. laide en ligne pour une description de ces deux instructions).
13
AGREGER LES DONNEES
61
Exemple :
1 2 3 4 5
SELECT a.cmd_clt, b.btq_pays, COUNT(cmd_num) AS NbCommandes, SUM(cmd_montant) AS [Montant total] FROM commandes AS a JOIN boutiques AS b ON a.cmd_btq = b.btq_num GROUP BY a.cmd_clt, b.btq_pays WITH ROLLUP
Dans le r esultat de cette requ ete on a, non seulement une ligne par sous groupe (niveau 2), mais aussi une ligne par groupe (niveau 1) et une ligne de niveau 0 : cmd clt NULL 0001 0001 0007 0007 0007 1122 1122 3344 3344 3344 btq pays NULL NULL France NULL France Italie NULL Italie NULL Italie France NbCommandes 24 3 3 8 4 4 1 1 12 6 6 Montant total 2555.70 500.00 500.00 1234.56 1000.00 234.56 32.60 32.60 788.54 394.27 394.27
Remarque : avec WITH ROLLUP, lordre des colonnes dans la clause GROUP BY a de limportance.
13.3
Conclusion
On sait d esormais r ediger une requ ete de s election compl` ete : SELECT les colonnes ` a acher (dans lordre) FROM les tables et leurs conditions de jointure WHERE les conditions de s election avant groupement GROUP BY les colonnes de groupement HAVING les conditions de s election sur les groupes ORDER BY les colonnes ` a trier (dans lordre) Il est donc temps de compl eter la strat egie pour elaborer une requ ete de s election : 1. d ecomposer au maximum en plusieurs s election que lon pourra r eunir avec UNION ; 2. d ecomposer chaque s election complexe en requ ete et sous-requ etes simples ; 3. et pour chaque requ ete et chaque sous-requ ete : (a) d eterminer les tables en jeu pour remplir la clause FROM et les JOIN n ecessaires ; (b) d eterminer les colonnes de groupement pour remplir la clause GROUP BY ; (c) d eterminer les colonnes ` a acher pour remplir la clause SELECT ; (d) d eterminer les conditions de s election avant groupement pour remplir la clause WHERE ; (e) d eterminer les conditions de s election sur les groupes pour remplir la clause HAVING ; (f) ajouter les eventuels ORDER BY, DISTINCT et TOP en dernier.
14 EDITION DETATS
62
14
Edition d etats
Un etat est un document de synth` ese, etabli automatiquement ` a partir des donn ees. Il peut etre soit purement informatif (un annuaire, par exemple) soit ` a caract` ere d ecisionnel (les ventes de la veille ventil ees selon les secteurs et en comparaison avec la m eme date lann ee pr ec edente, par exemple). En anglais, on parle de reporting. Les etats qui nous int eressent ici sont ceux qui permettent danalyser les donn ees (donc les etats ` a caract` ere d ecisionnel). Ils se pr esentent g en eralement sous la forme dun long tableau dagr egats d etaill es en groupes et sous-groupes, mais on peut consid erer que les graphiques d ecisionnels sont aussi des etats (on ne les aborde pas ici). Certains outils d edition d etats sont fournis avec un SGBD (Microsoft Access, par exemple) ou avec une plate-forme OLAP (cest le cas de Crystal Reports qui est ` a la base de Crystal Decisions, rachet e par Business Objects).
14.1
Comparaison avec les formulaires
Comme les formulaires, les etats sont compos es de champs et autres contr oles (essentiellement des zones de texte). Ils sont egalement destin es soit ` a etre imprim es soit ` a etre consult es ` a l ecran (sous la forme dune page web, par exemple). Il faut donc veiller tout particuli` erement : ` a ce que l etat ne d epasse pas la largeur de l ecran et/ou de la feuille ; ` a ce que les champs soient susamment larges pour acher leur contenu ; et ` a ce que les interactions avec lutilisateur soient ergonomiques (sil y en a). Un etat se pr esente comme un formulaire muni dun sous-formulaire, lui-m eme muni dun sous-sousformulaire, etc. Cependant, contrairement aux formulaires, les etats ne permettent pas ` a lutilisateur de modier les donn ees, mais ont simplement une fonction de consultation des informations.
14.2
Comparaison avec les requ etes GROUP BY
Un etat eectue essentiellement le m eme travail quune requ ete GROUP BY WITH ROLLUP, mais un etat est plus lisible car mieux organis e et mieux pr esent e quun vulgaire r esultat de requ ete. Les probl` emes des requ etes GROUP BY WITH ROLLUP qui sont r esolus par les etats sont les suivants : les intitul es des colonnes ne sont ach es quune fois, m eme si le r esultat s etale sur plusieurs pages ; on ne peut pas acher de renseignement compl ementaire (non agr eg e) concernant les groupes (le nom du client, par exemple), ` a cause de la contrainte entre les clauses SELECT et GROUP BY ; les agr egats des niveaux sup erieurs ne sont pas mis en valeur ; les conditions de s election ne sont pas ach ees (on ne peut donc pas diuser le r esultat).
14.3
Composition
Chaque sous-groupe de plus bas niveau occupe une ligne dans le document nal. Cest cette ligne qui est d ecrite dans la zone D etail. Les intitul es des colonnes du D etail sont pr ecis ees dans len-t ete de page (an d etre r ep et es automatiquement ` a chaque changement de page). Au dessus du D etail viennent les en-t etes des niveaux de groupement successifs dans lesquels on place les informations relatives ` a ces niveaux. En dessous du D etail viennent les pieds des niveaux de groupement successifs dans lesquels on place g en eralement les r esultats dagr egation voulus.
15
STRUCTURER LES DONNEES EN CUBE
63
Il reste : len-t ete d etat pour son titre et ses conditions de s election (notamment la ou les dates, les clients retenus, les articles concern es, etc.), il ne faut surtout pas oublier de les pr eciser, sans quoi le document na aucune valeur ; le pied de page pour la num erotation des pages (ce qui est important si le document est imprim e et malencontreusement m elang e) ; et le pied d etat pour les agr egats du niveau 0 (un total g en eral par exemple). Exemple : Exemple d etat le titre
pour les clients ayant plus de 5 commandes pour toutes les dates
les conditions de s election (dans len-t ete d etat)
Pays client n 0007 (Razibus) France Italie Total client n 3344 (Fricotin) France Italie Total Total g en eral
NbCommandes
Montant
les intitul es (en-t ete de page) un en-t ete de groupe
4 4 8
1000.00 234.56 1234.56
une ligne par sous-groupe un pied de groupe
6 6 12 20 page 1
394.27 394.27 788.54 1923.10 le pied d etat un pied de page
15
Structurer les donn ees en cube
On sent bien que la table est un objet bidimensionnel mal adapt e` a lagr egation de donn ees d` es que le groupement porte sur deux colonnes ou plus. L etat ore une premi` ere solution, mais la feuille A4 (m eme orient ee en paysage) est rapidement satur ee quand le nombre de niveau de groupement augmente et la navigation dans un etat de 200 pages est fastidieuse.
15.1
D enition dun cube
On pr ef ererait donc un objet : qui aurait autant de dimensions quil y a de colonnes de groupement (clients et pays dans notre exemple pr ec edent) ; dont chaque dimension d etaillerait les valeurs possibles (France et Italie pour la dimension pays) ; dans lequel, ` a lintersection dune valeur dans chaque dimension (France et 0001 par exemple) on trouverait une unique cellule ; une cellule qui contiendrait toutes les valeurs agr eg ees pour ce sous-groupe (cest-` a-dire les mesures tel que le nombre de commandes et le montant total) ; et aussi les agr egats des ces valeurs pour les sous-groupes sup erieurs.
15
STRUCTURER LES DONNEES EN CUBE
64
Cest cet objet que lon appelle cube. Par exemple, organisons, en cube, les donn ees de la requ ete suivante :
1 2 3 4
SELECT a.cmd_clt, b.btq_pays, COUNT(cmd_num), SUM(cmd_montant) FROM commandes AS a JOIN boutiques AS b ON a.cmd_btq = b.btq_num GROUP BY a.cmd_clt, b.btq_pays WITH CUBE
R esultat :
Fig. 11 Cube bidimensionnel Remarque : le terme de cube ne pr esupposant ni du nombre de dimensions ni de l egalit e des longueurs des dimensions (cf. gure 11). En MDX, pour cr eer ce cube il sut d ecrire :
1 2 3 4 5 6 7
CREATE CUBE ClientsPays ( DIMENSION clients DIMENSION pays MEASURE NbCommandes FUNCTION COUNT MEASURE [Montant total] FUNCTION SUM )
Remarque : on dispose bien evidemment de DROP CUBE et de ALTER CUBE 18 . Mesures Les mesures sont g en eralement additives (soit une somme, soit un d enombrement). Il ne faut stocker dans le cube que les mesures primitives : le prix TTC peut etre calcul e` a partir du prix hors taxe, ce nest donc pas la peine de le stocker ; il en va de m eme pour les prix en dollars ` a partir des prix en euros ;
18. on laisse au lecteur le soin de se renseigner aupr` es de laide en ligne pour conna tre les possibilit es de ALTER CUBE
15
STRUCTURER LES DONNEES EN CUBE dun montant ` a partir dun prix unitaire et dune quantit e; etc.
65
Dans Analysis Services, les mesures non primitives peuvent etre calcul ees avec les membres calcul es (cf. 18.4.1 page 91). Ceci dit, si les r` egles de calcul des mesures non primitives sont compliqu ees ou si elles changent souvent (cest le cas des conversions euro/dollar, par exemple), alors il vaut mieux stocker une mesure de plus.
15.2
Hi erarchie
Complexions progressivement la d enition dun cube. 15.2.1 Niveaux
Avec la structure de cube, on peut d etailler chaque dimension en plusieurs niveaux. Par exemple, une dimension g en erale geographie peut permettre des groupements selon un pays, une region ou une ville. On voit alors appara tre une hi erarchie dans les dimensions que lon d epliera et pliera ` a volont e, selon nos besoins dagr egation. On peut prendre comme illustration un cube ventes ` a trois dimensions (cf. gure 12) : une dimension geographie comprenant plusieurs pays qui se d ecomposent chacun en plusieurs r egions qui regroupent elles-m emes plusieurs villes dans lesquelles se situent les boutiques ; une dimension produits dans laquelle les articles sont regroup es en gammes puis en marques ; et une dimension temporelle d etaill ee en ann ees, mois et jours.
Fig. 12 Cube ventes hi erarchis e
15
STRUCTURER LES DONNEES EN CUBE La syntaxe MDX pour d eclarer ces dimensions hi erarchis ees est pour les dimensions standards :
1 2 3 4 5 6 7 8 9 10 11 12 13
66
DIMENSION geographie LEVEL tout TYPE ALL, LEVEL pays, LEVEL region, LEVEL ville
-- mettre ce niveau a chaque fois
-- on separe les niveaux par des virgules mais pas les dimensions DIMENSION produits LEVEL tout TYPE ALL, LEVEL marque, LEVEL gamme, LEVEL article
-- du plus agrege
-- au plus detaille
et pour la dimension temporelle :

1 2 3 4 5
DIMENSION temps LEVEL tout TYPE ALL, LEVEL annee TYPE YEAR, LEVEL mois TYPE MONTH, LEVEL jour TYPE DAY
Remarques : le niveau ALL un niveau formel qui regroupe tous les autres ; sil y a ambigu t e sur le nom des niveaux, il sut de pr eciser la dimension concern ee selon la syntaxe : dimension.niveau (exemple : produits.articles) ; dans une dimension hi erarchis ee, les donn ees du niveau le plus bas sont issues des bases de production ; mais le cube peut aussi stocker des donn ees aux niveaux sup erieurs (il sagit le plus souvent de donn ees agr eg ees, mais pas toujours). Le niveau le plus bas dune dimension sappelle le grain de la dimension (le grain de la dimension geographie cest la ville). Toutes les dimensions et leur grain doivent etre choisis d` es le d ebut et doit rester inchang es pendant toute la dur ee de vie du cube. 15.2.2 Membres
Les di erentes valeurs dun niveau sont appel ees membres. Par exemple, les membres du niveau pays sont France, Italie, Allemagne et Espagne. Un membre de niveau sup erieur regroupe des membres du niveau imm ediatement inf erieur, ce sont ses enfants. Par exemple, les enfants du membre France sont PACA, Rhones-Alpes et Corse. Remarque : un membre dun niveau sup erieur (une r egion) peut poss eder des donn ees (son ensoleillement, par exemple) et pas seulement des agr egats (montant total des ventes dans cette r egion).
15
STRUCTURER LES DONNEES EN CUBE Hi erarchies multiples
67
15.2.3
Certaines dimensions peuvent etre organis ees selon plusieurs hi erarchies. Cest classiquement le cas de la dimension temporelle qui peut non seulement etre organis ee en : jours, mois, trimestres et ann ees ; mais aussi en jours et semaines ; ou encore en jours et saisons. Cela peut egalement se produire pour nimporte quelle dimension (cf. la dimension produits sur la gure 16). Analysis Services ne permet malheureusement pas ` a une dimension de poss eder plusieurs hi erarchies. La technique pour les repr esenter malgr e tout consiste alors simplement : soit ` a introduire plusieurs dimensions (avec une hi erarchie chacune), ce qui nest pas recommand e; soit ` a utiliser les propri et es de membre (cf. 19.1 page 96) et les dimensions virtuelles.
15.3
Normalisation dun cube
Le sch ema relationnel dun cube (cf. section suivante) na pas besoin de respecter la troisi` eme forme normale (cf. [?]), ce qui permet dutiliser des sch emas en etoile. Par contre, quelques r` egles (tir ees de [4]) doivent etre respect ees lors de la construction de chaque cube : R` egle 1 : dans un cube, deux membres appartenant ` a deux dimensions di erentes doivent etre ind ependants . Autrement dit, sil ny a quun vendeur par produit, il faut fusionner les dimensions produits et vendeurs. R` egle 2 : dans un cube, tous les faits doivent d ependent de toutes les dimensions. Autrement dit, les ventes (qui d ependent du produit, du jour, du client et de la ville) et les co uts de d eveloppement (qui ne d ependent que du produit) d enissent deux types de faits distincts (et conduisent donc ` a deux cubes distincts). R` egle 3 : dans un cube, toutes les mesures doivent respecter le grain du cube. Si la marge nest d enie que par r egion et par mois, tandis que le montant des ventes le sont par ville et par jour, alors il ne faut pas chercher ` a les faire cohabiter par une division arithm etique mais les s eparer dans deux cubes distincts. R` egle 4 : la hi erarchie dune dimension doit etre strictement arborescente. Ce nest pas le cas dune dimension organisation dans laquelle : les agences sont regroup ees administrativement en divisions ; les agences sont regroup ees g eographiquement en etablissements, m eme si elles appartiennent ` a des divisions di erentes ; les divisions sont regroup ees en directions r egionales ; les etablissement sont egalement regroup es en directions r egionales. Il faut alors utiliser deux hi erarchies pour cette dimension : une dont les niveaux sont : agences, divisions et directions r egionales ; et une autre dont les niveaux sont : agences, etablissement et directions r egionales . Lorsquun cube v erie ces quatres r` egles, on dit quil est en forme dimensionnelle normale.
16
STOCKAGE DES DONNEES
68
16
Stockage des donn ees
On sait que les donn ees des syst` emes transactionnels sont stock ees sous une forme purement relationnelle. Cest dailleurs cette vision relationnelle que lon a remplac ee par une vision multidimensionnelle dans cette partie. La question qui se pose maintenant est : comment stocker des cubes ayant de nombreuses dimensions, elles-m eme ` a plusieurs niveaux ?
16.1
Sch ema relationnel de lentrep ot
La premi` ere id ee est de stocker physiquement un objet multidimensionnel, cest-` a-dire une hypermatrice avec plusieurs mesures par cellule et de stocker aussi les agr egats au bout de chaque ligne, chaque colonne, etc. et pour tous les niveaux. Cest la meilleure approche du point de vue des performances de consultation (puisque tous les r esultats sont pr esents), mais ce stockage est bien souvent trop gourmand en place m emoire. Notre soucis est donc maintenant d economiser de lespace. Or on conna t d ej` a la fa con la plus economique de stocker des donn ees, cest lapproche relationnelle (dans laquelle on evite toute redondance). Il se trouve justement que lon peut voir un cube sous forme de tables et de relations. 16.1.1 Sch ema en etoile
Si au sein de lentrep ot, nous nous concentrons sur un cube, alors on peut mod eliser ses dimensions, leurs niveaux, leurs membres et les cellules sous la forme dun sch ema relationnel etoil e. Table de dimension ` chaque dimension on associe une table avec : A une cl e primaire non composite ; et une colonne par niveau (pour y stocker les membres).
(a)
(b)
Fig. 13 Tables de dimension Par exemple, ` a la dimension geographie on associe une table (cf. gure 13(a)) ayant pour cl e primaire code geographie et comme autres colonnes : pays, region et ville.
16
69
Etant donn e que les donn ees sont issues de plusieurs bases de donn ees ayant chacune leur cl es primaires, les cl es primaires des tables de dimensions sont di erentes car elles doivent assurer une unicit e plus g en erale. Ces cl es de substitution (surrogate keys, par opposition aux cl es naturelles utilis ees dans les bases de production) servent ` a identier un membre pendant tout sa dur ee de vie au sein de lentrep ot. Dimension temporelle Les dimensions temporelles ne rentrent pas dans ce cadre puisque quon ne samuse pas ` a d etailler les ann ees, les mois et les jours dans trois colonnes di erentes, mais quon regroupe cette information dans une seule colonne de type DATETIME. Remarque : la dimension temporelle pose toujours un probl` eme de conception notamment parce que tous les acteurs dune entreprise ne fonctionnent ni avec le m eme calendrier (civil, scal, scolaire, etc.) ni avec la m eme horloge (surtout si lentreprise est multinationale). Table des faits Ensuite, chaque cellule du cube : est identi ee par ses coordonn ees (i.e. son code geographie, son code produits et sa date) ; et contient ses mesures. Lensemble de ces informations (coordonn ees et mesures relatives ` a une cellule) constitue ce que lon appelle un fait. Si maintenant on stocke chaque fait sous la forme dune ligne dans une table, alors on obtient un sch ema relationnel etoil e par rapport ` a cette table (autrement dit toutes les relations partent de cette table, cf. gure 14).
Fig. 14 Sch ema en etoile dun cube ` a 5 dimensions et 2 mesures Dans lexemple du cube ventes, la table des faits naurait poss eder que deux cl es etrang` eres : code
16
70
geographie et code produit, une colonne pour la date ainsi que deux autres colonnes pour les mesures : NbCommandes et [Montant total]. Pour mettre en evidence le caract` ere etoil e du sch ema relationnel, nous ajoutons deux dimensions au cube ventes : une relative aux clients et une relative aux vendeurs. Remarque : la table des faits peut compter plusieurs millions de lignes et la taille des autres tables est n egligeable devant celle de la table des faits. 16.1.2 Sch ema en ocon
Dans le sch ema en etoile (star scheme), il peut encore y avoir des redondances, pour deux types de raisons : nutiliser quune seule table pour d enir une dimension qui poss` ede plusieurs niveaux est presque toujours en contradiction avec la troisi` eme forme normale [?] (cf. gure 13(b)) ; on peut donc pousser plus loin la d ecomposition relationnelle (cf. gure 15)
Fig. 15 D ecomposition de la table produits par ailleurs, on peut parfois factoriser certaines donn ees (une seule table geographie pour la g eographie des ventes et des clients, par exemple).
16
71
Comme la table des faits nest plus la seule ` a etoiler les relations autour delle, d` es lors quune dimension est bas ee sur deux tables ou plus (cf. gure 16), on dit que le sch ema est en ocon (snowake scheme).
Fig. 16 Sch ema en ocon Remarque : dans cet exemple, la dimension produits pr esente trois hi erarchies (une selon les types, une selon les paquetages et une selon les cat egories). Ce quil faut retenir de tout cela, cest que : une dimension sinscrit dans un sch ema en etoile si elle nest d enie que sur une table du sch ema relationnel du cube (cest le cas de la dimension geographie) ; d` es quelle utilise plusieurs tables du sch ema relationnel, la dimension sinscrit dans un sch ema en ocon (cest le cas des dimensions produits et clients). Quand certaines dimensions sont en etoile et dautre en ocon, on dit que le sch ema du cube est en starake. Dans Analysis Services, on est donc amen e` a sp ecier pour chaque dimension (non temporelle) : si elle sinscrit dans un sch ema en etoile ou en ocon ; la ou les tables concern ees (elles doivent exister avant la cr eation du cube). Que choisir ? Le sch ema en etoile est, certes, plus redondant que le sch ema en ocon mais : la redondance nest pas un probl` eme pour le d ecisionnel, puisquil ny a que des requ etes de s election ; lespace occup e par les tables de dimension est n egligeable devant celui de la table des faits ; les requ etes sont plus rapides sur un sch ema en etoile ;
16
STOCKAGE DES DONNEES lETL est plus simple avec un sch ema en etoile.
72
Pour toutes ces raisons, le sch ema en ocon est peu recommand e et doit se limiter ` a: la factorisation, comme celle de la table geographie ; la repr esentation de hi erarchie multiple, comme celle de la dimension produits. Ce qui exclut la d ecomposition ` a outrance comme celle des cat egories et sous-cat egories. 16.1.3 Parent-enfant
Dhabitude, les niveaux dune relation sont de type ensembliste : dans la dimension geographie, un pays est un ensemble de r egions. Prenons maintenant une hi erarchie de dimension qui ait une signication familiale (cf. gure 17). Par exemple une dimension personnes avec un niveau GrandsParents, un niveau parents et un niveau
Fig. 17 Hi erarchie parent-enfant enfants. Le sch ema relationnel du cube nest alors plus le m eme, puisquil fait intervenir une autojointure sur la table personnes (cf. gure 18).
Fig. 18 Auto-jointure dune table de dimension parent-enfant Cest ce que lon appelle une hi erarchie parent-enfant. Elle est valable egalement quand il y a une relation employ e-employeur. Remarque : dans le cas dune hi erarchie parent-enfant, les niveaux sup erieurs poss` edent des donn ees propres (non agr eg ees). Par exemple, le nom du directeur commercial nest pas issus de lagr egation des noms de ses vendeurs... 16.1.4 Base d ecisionnelle
Un entrep ot de donn ees peut contenir plusieurs cubes (le cube ventes que lon vient de voir, et le cube production, par exemple). Le sch ema relationnel de lentrep ot regroupe les sch emas relationnels de ses cubes. La base de donn ees qui correspond ` a ce sch ema relationnel global,sappelle la base d ecisionnelle (par opposition aux bases de production). Elle doit etre construite avant lentrep ot lui-m eme. Elle r esulte dun travail important de r etroconception des bases de production et de normalisation ` a l echelle de lentreprise. Certaines dimensions sont communes ` a plusieurs cubes (la dimension produits est commune aux cubes ventes et production, par exemple). Leurs tables ne sont evidemment pas r ep et ees dans le sch ema
16
73
relationnel de lentrep ot, mais utilis ees par plusieurs tables des faits. Cest pourquoi Analysis Services emploie le terme de dimensions partag ees. Il en va de m eme pour les mesures et toutes les autres colonnes utilis ees pour d enir le cube : elle sont pr esentes une bonne fois pour toutes dans ce sch ema relationnel global, puis utilis ees dans le sch ema relationnel de chaque cube. ` linstar des bases de production, le sch A ema relationnel de la base d ecisionnelle doit etre con cu dans une phase mod elisation et doit coller aux besoins des utilisateurs. Par contre, cette mod elisation OLAP di` ere sensiblement des mod elisations relationnelles classiques pour les syst` emes OLTP. Le sch ema relaes le d epart, car cest encore plus probl ematique de modier tionnel doit etre susamment bien con cu d` la base d ecisionnelle quune base de production. Rappelons que cette base d ecisionnelle a pour but dhistoriser les donn ees et est mise-` a-jour, non pas par de nombreuses transactions ACID (cf. 2.4 page 15), mais par des extractions p eriodiques des syst` emes OLTP sous-jacents (avant quils ne soient purg es). Dans Analysis Services, cest cette base qui est la source de donn ees ` a connecter a ` lentrep ot. Notons quAnalysis Services autorise plusieurs sources de donn ees (et donc plusieurs bases d ecisionnelles) pour un m eme entrep ot.
16.2
Modes de stockage
Classiquement, il existe trois modes de stockage pour chaque partition dun cube. Sans entrer dans le d etail, les donn ees dun cube peuvent etre partitionn ees (selon les ann ees, g en eralement). G en eralement un cube pr esente : une partition pour lann ee en cours ; une partition pour lann ee pr ec edente (ou les deux ann ees pr ec edentes) ; et une derni` ere partition pour les autres ann ees. Remarque : les partitions correspondent ` a un eclatement de la table des faits. 16.2.1 Multidimensional OLAP (MOLAP)
En mode MOLAP, les donn ees de la base d ecisionnelle sont copi ees dans une structure (hyper)matricielle qui contient egalement les agr egats. Analysis Services compresse alors les donn ees et nalloue 19 aucun espace aux cellules vides , ce qui limite la taille de stockage. Pourtant, ce type de stockage doit se limiter aux donn ees les plus utilis ees (celle de lann ee en cours, par exemple) an que les r eponses soient instantan ees et que le volume de donn ees MOLAP reste raisonnable. 16.2.2 Relational OLAP (ROLAP)
En mode ROLAP, la partition est vide. Toutes les donn ees restent dans la base d ecisionnelle. Les requ etes MDX sur ce cube font donc appel ` a des requ etes SQL impliquant des jointures. Cest le type de stockage qui ore les temps de r eponse les plus lents. Mais cest aussi le plus econome. G en eralement, les donn ees qui remontent ` a deux ans et plus (elles sont nombreuses et peu consult ees) sont stock ees en ROLAP. Remarque : les requ etes sont plus rapides sur un sch ema en etoile (m eme redondant) que sur un sch ema en ocon (qui met en jeu davantage de jointures).
19. cela est heureux car, g en eralement, un cube OLAP est creux, cest-` a-dire essentiellement constitu e de cellules vides
16
STOCKAGE DES DONNEES Hybrid OLAP (HOLAP)
74
16.2.3
En mode HOLAP, seuls les agr egats des niveaux sup erieurs sont stock es sous forme matricielle (cf. ees bas niveaux restent dans la base d ecisionnelle. Il sagit dune combinaison entre gure 19) et les donn lapproche MOLAP et lapproche ROLAP. Seule les requ etes MDX qui utilisent directement les donn ees bas niveaux sont ralenties (drillthrough, par exemple).
Fig. 19 Cube r eduit pour les agr egats des niveaux sup erieurs Ce type de stockage convient bien aux donn ees de lann ee pr ec edente (ou des deux ann ees pr ec edentes).
16.3
Niveau dagr egation
Quelque soit le mode de stockage choisi, les agr egats ne sont pas forc ement tous calcul es et stock es. Analysis Services peut d eterminer quels agr egats stocker (en commen cant par les niveaux les plus bas) en fonction de deux crit` eres : la taille maximale allou ee au cube (si on la conna t, autant la pr eciser) ; ou le gain de performance souhait e: gain en pourcentage = 100 Tmax T Tmax Tmin
o` u Tmax est le temps dex ecution dune requ ete si aucun agr egat nest stock e, Tmin est le temps dex ecution de cette requ ete si tous les agr egats sont stock ees et T est le temps dex ecution avec le gain souhait e.
17
ALIMENTATION DE LENTREPOT
75
17
Alimentation de lentrep ot
Pour remplir un entrep ot de donn ees, il faut : une etape dextraction (des donn ees pertinentes des les bases de production) ; une etape de transformation (nettoyage, formattage, premi` eres agr egations et reconnaissance des membres) ; et une etape de chargement (des donn ees propres dans la base d ecisionnelle). En anglais on parle de phase ETL pour Extraction, Transformation and Loading 20 . La fr equence ` a laquelle les phases ETL sont op er ees doit etre coh erente avec le grain de la dimension temporelle et doit permettre dhistoriser les donn ees avant quelles ne soient purg ees des bases de production. Le remplissage initial des donn ees ` a la cr eation de lentrep ot est g en eralement facile. Cest historiser p eriodiquement et automatiquement les donn ees qui pose probl` eme. En eet, les sources de donn ees sont g en eralement multiples et g er ees par di erents syst` emes (g eographiquement r epartis dans di erents sites), ce qui rend la phase ETL bien souvent tr` es probl ematique. Chaque situation rencontr ee est tr` es sp ecique et larchitecture ETL mise en place est souvent d edi ee ` a lentreprise. Dailleurs le march e des outils ETL (qui sont tr` es nombreux), est particuli` erement morcel e. Il est malgr e tout domin e par Informatica (PowerMart/Center), Ascential (DataStage) et SAS (Warehouse Administrator). Suivent les fournisseurs de SGBD : Oracle (Warehouse Builder), IBM (DataWarehouse Manager) et Microsoft (DTS), au coude-` a-coude avec Cognos et Hummingbird (parmi tant dautres).
17.1
Data Transformation Services (DTS)
DTS est un outil fourni avec SQL Server. Il peut se connecter en lecture et en ecriture : aux logiciels Microsoft, evidemment : SQL Server, Access, Excel et Visual FoxPro ; ` a dautres SGBD : Corel Paradox, dBase, Oracle et m eme IBM DB2 ; ` a des chiers textes ou des chiers HTML. DTS peut donc transf erer les donn ees non seulement dune base SQL Server vers une base SQL Server, mais aussi dune base DB2 vers une base Oracle, par exemple. Cet outil permet non seulement de transf erer les donn ees, les nettoyer, les transformer, les fusionner et/ou les s eparer. On entend par transformation tout calcul num erique ou toute op eration sur cha nes de caract` eres par exemple. Ces transformations peuvent etre programm ees dans des scripts SQL, Visual Basic, Java ou Perl et donc etre extr emement complexes. Une action DTS sappelle un lot. Un lot DTS peut etre ex ecut e r eguli` erement et automatiquement (en collaboration avec un autre service, SQL Server Agent, qui permet de planier les op erations sur SQL Server). Un lot peut comporter plusieurs t aches que lon peut encha ner (sur succ` es ou sur echec de la t ache pr ec edente) et dont on peut d etecter et g erer les erreurs. Pour nous, il sagit dutiliser DTS comme outil dextraction p eriodique de donn ees depuis les bases de production vers la base d ecisionnelle. Parmi les t aches disponibles, nous int eressent plus particuli` erement : les connexions aux donn ees en lecture et en ecriture ;
20. lETL fait partie des logiciels qui permettent aux applications h et erog` enes de communiquer entre elle (middleware) au m eme titre que lEAI (Enterprise Application Integration) qui permet de maintenir ` a jour les donn ees entre les applications en temps r eel
17
76
lex ecution de scripts param etr es (essentiellement en SQL) ; lex ecution de sous-lots (ce qui permet de d ecomposer le lot ETL tr` es complexe en lots extraction, transformation, chargement et traitement, plus simples) ; le traitement des cubes. DTS ore egalement la possibilit e dutiliser des variables globales visibles par toutes les t aches. Pour lETL, deux variables globales sont indispensables : la date de d ebut et la date de n qui d elimite la p eriode de temps ` a laquelle lETL sapplique. Typiquement, la date de d ebut est la date de n de la pr ec edente ex ecution du lot et la date de n est la date courante. Pour un approfondissement de cet outil, le lecteur est invit e` a consulter [1] et [16].
17.2
Base tampon
Etant donn e quelles ont lieu pendant les plages horaires peu occup ees (la nuit), lETL des donn ees OLTP pour le syst` eme OLAP entre en concurrence avec les sauvegardes des bases de production. Il faut donc que cette phase perturbe le moins longtemps possible les syst` emes OLTP. Pour cela, il faut que : lextraction prenne le moins de temps possible ; les transformations naient pas lieu en m eme temps que lextraction et pas sur le m eme serveur que les syst` emes OLTP ; Bref, les donn ees extraites doivent atterrir sur une autre base, appel ee base tampon (staging area). Une fois l etape dextraction termin ee, les transformations n ecessaires. peuvent etre eectu ees tranquillement dans la base tampon. Il ne faut pas non plus que le syst` eme OLAP ne soit perturb e par la phase ETL (en particulier, par l etape de transformation). Autrement dit, cette base tampon ne doit pas etre la base d ecisionnelle et doit etre g er ee par un serveur d edi e` a lETL (cf. gure 20).
Fig. 20 Les etapes du processus ETL
17
77
17.3
Etapes ETL
D etaillons maintenant les etapes de la gure 20. 17.3.1 Extraction
Pour que l etape dextraction dure le moins longtemps possible, il faut que : la requ ete de s election ne comporte aucune jointure (il faut donc extraire les tables une par une) ; les donn ees soient ins er ees dans des tables temporaires (elles nont aucune contrainte, aucun d eclencheur et aucun index). Par ailleurs, il est bon que dans les syst` emes OLTP, chaque table concern ee par lextraction (clients, produits, etc.) soit munie dune colonne pour la date de cr eation et une autre pour la date de derni` ere modication. Sans ces colonnes, on serait oblig e dextraire toutes les lignes et il serait compliqu e de d eterminer (dans la base tampon) les lignes r eellement modi ees depuis la derni` ere extraction. Avec ces 21 colonnes, lextraction peut etre incr ementale . Dans tous les cas, le volume de donn ees ` a extraire est important. Il y a toujours un choix ` a faire entre extraire toutes les lignes dun coup (la m ethode la plus rapide, mais comme cette transaction est non atomique, la moindre erreur est fatale ` a tout le processus) ou les extraire une par une (ce qui prend plus de temps, mais permet de limiter leet dune erreur ponctuelle). Exemple dextraction :
1 2 3 4 5 6 7 8 9 10 11 12 13 14
SELECT * INTO clients_temporaire1 FROM SERVEROLTP1.BaseProduction1.dbo.clients AS a WHERE a.derniere_modification BETWEEN @debut AND @fin SELECT * INTO clients_temporaire2 FROM SERVEROLTP2.BaseProduction2.dbo.clients AS a WHERE a.last_modification_date BETWEEN @debut AND @fin SELECT * INTO commandes_temporaire1 FROM SERVEROLTP1.BaseProduction1.dbo.commandes AS a WHERE a.date BETWEEN @debut AND @fin Transformation
17.3.2
Ce nest pas parce que les donn ees proviennent de bases de production qui fonctionnent rigoureusement bien, que ces donn ees sont valides pour le syst` eme d ecisionnel. Il faut presque toujours les transformer. Les transformations se font en deux temps : dabord, pendant le passage des donn ees des tables temporaires aux tables tampon ; ensuite, des modications sont apport ees au sein des tables tampon en vue du chargement.
21. notons que lextraction peut egalement etre incr ementale si lon utilise les informations contenues dans le journal des transactions
17
ALIMENTATION DE LENTREPOT Tables tampon
78
` ce stade, la base tampon ne contient que des tables temporaires identiques aux tables source. A L etape de transformation consiste ` a consolider ces donn ees dans les v eritables tables de la base tampon (cf. gure 21). ` chaque table de la base d A ecisionnelle correspond une table tampon qui contient : les colonnes de la table de dimension ou de faits correspondante ; les cl es naturelles et les cl es de substitution ; une colonne exists de type oui ou non qui dira si le membre existe d ej` a ou non ; Ces tables tampon sont d epourvues de contraintes, notamment toutes ces colonnes autorisent la valeur vide.
Fig. 21 Tables temporaires et tables tampon Remarques : pour faciliter le passage des tables temporaires aux tables tampon, il convient de supprimer, au pr ealable, les index sur les tables tampon ; comme les bases de production sont multiples, il peut y avoir plusieurs tables temporaires qui concerne les produits, par exemple ; donc linsertion dans la table tampon qui concerne les produits se fait en plusieurs fois ; la base tampon est totalement d epourvue de relation car on ne peut assurer ni lint egrit e des entit es ni lint egrit e r ef erentielle, puisque les donn ees source ne sont pas encore consolid ees ; notons quil y a souvent un travail de jointure ` a faire sur les tables temporaires pour ins erer les donn ees dans les tables tampon ;
17
79
notons enn que si le grain des bases de production est plus n que celui de la base d ecisionnelle, les premi` eres agr egations n ecessaires peuvent etre eectu ees ` a ce moment-l` a. R eparation, compl etion, synchronisation et formattage Pendant que les donn ees sont ins er ees dans les tables tampon, on peut les uniformiser, cest-` a-dire les r eparer, les compl eter, les synchroniser et les formatter. Exemple de r eparation des donn ees : les codes postaux invalides peuvent etre corrig es en utilisant un annuaire des codes postaux. Exemple de compl etion des donn ees : d eduire la r egion o` u est domicili e un propri etaire ` a partir du num ero dimmatriculation de son v ehicule. Rappelons que les bases de production nutilisent pas forc ement la m eme horloge. Il faut donc synchroniser toutes les dates contenues dans les tables temporaires pendant leur transfert dans les tables tampon. Par ailleurs, quand les donn ees arrivent dans la base tampon, elles ne sont pas toutes au m eme format et ne respectent pas forc ement le format de la base d ecisionnelle (g en eralement, les contraintes sur les cha nes de caract` eres ne sont pas les m emes dans toutes les bases et les codages de date sont h et erog` enes). Il faut donc uniformiser les formats avant le chargement, cest le formattage. Exemple dh et erog en eit e : selon leur provenance, les noms de clients peuvent arriver sous la forme de deux colonnes (nom et prenom) ou sous la forme dune colonne (nom + prenom, nom + initiale + prenom). Un autre exemple classique concerne les adresses : il y a quasiment autant de formats que de bases. Exemple dinsertion dans une table tampon ` a partir dune table temporaire :
1 2 3 4 5 6 7 8
INSERT clients_tampon (cle_naturelle, source, NomPrenom, ville, region, pays, date_creation) SELECT a.clt_num, SERVEROLTP1.BaseProduction1, -- pour la substitution a.nom + + a.prenom, -- formattage b.ville, b.region, a.pays, -- completion DATEADD(hour, -3, a.date_creation) -- synchronisation FROM clients_temporaire1 AS a JOIN CodesPostaux AS b ON (a.CodePostal = b.CodePostal)
Notons quun client peut etre ins er e en double dans sa table tampon, sil gure dans deux bases de production. Les doublons sont g er es par le paragraphe suivant. De plus, deux clients di erents mais qui portent la m eme cl e naturelle, sont distinguables par leur source (et leurs attributs). Substitution des cl es primaires Une fois que les tables tampons sont remplies, on peut supprimer les tables temporaires et soccuper de lint egrit e des donn ees qui vont etre charg ees dans la base d ecisionnelle. Pour rendre la substitution, la validation et le chargement le plus rapide possible, il convient de re-cr eer les index sur les tables tampons. Rappelons que la base d ecisionnelle nutilise pas les cl es naturelles des bases de production car : un produit peut etre identi e dans deux bases de production di erentes avec des cl es distinctes ; un num ero de produit peut correspondre ` a deux produits distincts dans deux bases de production di erentes.
17
80
Au contraire, pour identier les membres de mani` ere unique, la base d ecisionnelle utilise des cl es de substitution (surrogate keys). Au cours de l etape de transformation, il faut donc traduire (lookup) les cl es naturelles en cl es de substitution et remplir la colonne exists. Si les bases de production ne sont pas pourvues dune colonne pour la date de cr eation et une colonne pour la date de derni` ere modication, alors cette traduction implique la recherche du membre correspondant (en fonction de leurs attributs dans la base d ecisionnelle) pour chaque ligne extraite. Non seulement cest tr` es co uteux mais en plus, cela perturbe le syst` eme OLAP. Exemple de lookup pour les cl es primaires de substitution :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
-- recherche des membres deja presents UPDATE clients_tampon SET exists = 1, cle_substitution = b.cle FROM clients_tampon AS a JOIN SERVEROLAP.BaseDecisionnelle.dbo.clients_dimension AS b ON ( ISNULL(a.NomPrenom, ) = ISNULL(b.NomPrenom, ) AND ISNULL(a.pays, ) = ISNULL(b.pays, ) AND ISNULL(a.region, ) = ISNULL(b.region, ) AND ISNULL(a.ville, ) = ISNULL(b.ville, ) ) -- pays et region sont utiles pour distinguer les villes homonymes -- nouvelle cle pour les nouveaux membres UPDATE clients_tampon SET cle_substitution = NEWID() WHERE exists IS NULL
Notons que les clients ins er es en double dans la table clients tampon, poss` edent d esormais une cl e de substitution unique (sauf les nouveaux membres) et que les clients distincts mais avec la m eme cl e primaire, poss` edent d esormais deux cl es de substitution distinctes. D erive dimensionnelle Notons aussi, que si un client change de ville, il faut faire un choix entre : changer la ville de ce membre (et donc changer les agr egats de cette ville), ce qui nest pas recommand e; ou ins erer un nouveau membre pour ce client et sa nouvelle ville (cest le cas dans lexemple pr ec edent). On peut en venir ` a introduire un num ero de version ` a chaque membre et une date de cr eation pour chaque version. La cl e primaire de la table de dimension est alors compos ee de deux colonnes : la cl e de substitution et le num ero de version. C a nest pas la solution que nous avons retenue ici. Substitution des cl es etrang` eres Il reste encore ` a traiter lint egrit e r ef erentielle des donn ees qui vont etre charg ees dans la base d ecisionnelle. Pour cela, il faut recalculer les cl es etrang` eres avec les cl es de substitution an que les relations de la base d ecisionnelle soient v eri ees lors du chargement (cf. gure 22).
17
81
Fig. 22 Evolution des tables clients et commandes au cours du processus ETL Malheureusement, certaines cl es etrang` eres peuvent etre introuvables. Dans toutes les tables de dimension, il faut donc pr evoir un membre 0 qui permet de traiter ces relations invalides 22 . Ce membre 0 est cr e e une bonne fois pour toutes dans chaque table de dimension de la base d ecisionnelle :
1 2 3
-- sur le server OLAP et dans la base decisionnelle INSERT clients_dimension (cle, NomPrenom, pays, region, ville) VALUES (0, autre, autre, autre, autre)
22. la num erotation des membres valides doit donc commencer ` a1
17
ALIMENTATION DE LENTREPOT Exemple de lookup pour les cl es etrang` eres de substitution (dans la base tampon) :
1 2 3 4 5 6 7 8 9 10 11 12 13 14
82
-- traitement des relations valides UPDATE commandes_tampon SET client_cle_substitution = b.cle_substitution FROM commandes_tampon AS a JOIN clients_tampon AS b ON ( a.cmd_clt = b.clt_num AND a.source = b.source ) -- traitement des relations invalides UPDATE commandes_tampon SET client_cle_substitution = 0 WHERE client_cle_substitution IS NULL
Remarque : la phase de substitution est plus simple pour un sch ema en etoile que pour un sch ema en ocon. Il faut en tenir compte lors de la conception de la base d ecisionnelle. 17.3.3 Chargement
Comme les donn ees sont charg ees dans la base d ecisionnelle qui est muni dun sch ema relationnel, il faut charger ses tables dans cet ordre : dabord les tables qui ne contiennent aucune cl e etrang` ere ; ensuite les tables qui ne contiennent que des cl es etrang` eres vers des tables d ej` a charg ees ; etc. Ensuite, pour chaque table, le chargement de d ecompose en deux requ etes : une pour les nouveaux membres ou faits ; et une pour les membres ou faits modi es. Exemple de chargement dans une table de dimension :
1 2 3 4 5 6 7 8 9 10 11 12 13 14
-- chargement des nouveaux membres INSERT SERVEROLAP.BaseDecisionnelle.dbo.clients_dimension SELECT cle_substitution, NomPrenom, ville, region, pays, age, profession FROM clients_tampon WHERE exists IS NULL -- modification des anciens membres UPDATE SERVEROLAP.BaseDecisionnelle.dbo.clients_dimension SET age = a.age, profession = a.profession FROM clients_tampon AS a JOIN SERVEROLAP.BaseDecisionnelle.dbo.clients_dimension AS b ON (a.cle_substitution = b.cle) WHERE a.exists = 1
18
INTERROGER UN CUBE Exemple de chargement dans une table des faits :

1 2 3 4 5 6 7 8 9 10 11 12 13 14
83
-- chargement des nouveaux faits INSERT SERVEROLAP.BaseDecisionnelle.dbo.commandes_faits SELECT cle_substitution, client_cle_substitution, date FROM commandes_tampon WHERE exists IS NULL -- modification des anciens membres UPDATE SERVEROLAP.BaseDecisionnelle.dbo.commandes_faits SET client_cle_substitution = a.client_cle_substitution date = a.date FROM commandes_tampon AS a JOIN SERVEROLAP.BaseDecisionnelle.dbo.commandes_faits AS b ON (a.cle_substitution = b.cle) WHERE a.exists = 1 Traitement
17.3.4
Le traitement des cubes intervient juste derri` ere la phase ETL proprement dite. Il dagit dune op eration enti` erement r ealis ee par Analysis Services, mais il sagit dune t ache que lon peut inclure dans le m eme lot DTS que lETL. Hormis pour le remplissage initial de lentrep ot, le traitement des cubes doit etre incr emental. Pour cela, il est conseill e de partitionner le cube avec notamment une partition s epar ee pour lann ee en cours, an de ne pas traiter les autres ann ees (qui, normalement, ne sont pas touch ees par les modications).
18
Interroger un cube
Avant de d ecouvrir comment consulter un cube, d enissons quelques op eration de navigation dans un cube : le d epliage (drilldown) qui consiste ` a passer ` a un niveau inf erieur dans une dimension ; le pliage (drillup ou rollup) qui consiste ` a passer ` a un niveau sup erieur dans une dimension ; le tranchage ou d ecoupage (slice) qui consiste ` a ne garder quune tranche du cube (une tranche etant une coupe du cube selon un membre) ; le cubage (dice) qui sint eresse ` a plusieurs tranches ` a la fois ; et la rotation qui consiste ` a choisir les dimensions que lon veut en colonnes et en lignes. Avec ces cinq op erations, on peut naviguer dans les donn ees (i.e. pratiquer le data surng). Il faut y ajouter une sixi` eme op eration : le drillthrough (traduit maladroitement par extraction dans Analysis Services, le terme de d esagr egration etant pr ef erable) qui permet de retrouver les donn ees qui ont permis de calculer un agr egat.
18.1
Requ etes MDX
La syntaxe pour r ediger une requ ete MDX est la suivante : WITH certaines notations SELECT les colonnes, les lignes et les autres axes FROM le cube WHERE les dimensions tranch ees et leur tranche (au singulier) CELL PROPERTIES les informations contextuelles voulues pour les cellules
18
INTERROGER UN CUBE
84
Le r esultat dune telle requ ete est un tableau multidimensionnel dont les cellules ne contiennent quune valeur (contrairement aux cubes) et dans lequel on peut naviguer avec les op erations d ecrites pr ec edemment. Parmi les dimensions du cube initial, certaines servent daxes (un axe contient les membres issus dun d epliage et/ou dun cubage) pour le r esultat (clause SELECT) et dautres de tranchage (clause WHERE) mais pas les deux ` a la fois. Pour MDX, les mesures constituent une dimension, et peuvent donc faire lobjet dun axe ou dun tranchage. Achons par exemple, le montant des ventes, avec en colonne lann ee 2002 et en ligne la r egion PACA :
1 2 3 4
SELECT {temps.annee.[2002]} ON COLUMNS, {geographie.region.PACA} ON ROWS FROM ventes WHERE (measures.montant)
Le r esultat de cette requ ete est le suivant : 2002 56986.12
PACA
Remarques : noublier ni les accolades dans la clause SELECT ni les parenth` eses dans la clause WHERE ; rappel : d` es quun intitul e contient une espace, un accent ou commence par un chire, il faut le d elimiter par des crochets ; si lintitul e utilise un crochet fermant ], employer les doubles crochets fermants : [Bill [William]] Clinton] pour des raisons qui deviendront claires au 18.4.2 page 93, si lintitul e contient une quote , alors il faut la doubler : [ks Choice] la syntaxe compl` ete des noms de membres dans un cube est : dimension . niveau . membre sil ny a pas de confusion possible on peut omettre la dimension et/ou le niveau ; si dans un m eme niveau plusieurs membres ont le m eme nom, pr eciser autant de parents que n ecessaire pour les distinguer : dimension . [anc etre le plus ancien] ... [grand-p` ere] . [p` ere] . membre
18
INTERROGER UN CUBE Clause SELECT
85
18.1.1
La clause SELECT ore plusieurs possibilit es. On peut acher : plusieurs colonnes et plusieurs lignes :
1 2 3 4
SELECT {temps.annee.[1998], temps.annee.[2002]} ON COLUMNS, {geographie.region.PACA, geographie.pays.France} ON ROWS FROM ventes WHERE (measures.montant)
R esultat : 2 colonnes et 2 lignes 1998 133419.96 1458311.45 2002 56986.12 248996.54
PACA France
tous les enfants dun membre :

1 2 3 4
SELECT temps.annee.[1998].CHILDREN ON COLUMNS, {geographie.region.PACA} ON ROWS FROM ventes WHERE (measures.montant)
R esultat : autant de colonnes quil y a denfants Janvier 19856.45 F evrier 11458.58 Mars 7589.47 Avril 8799.15 ... ... Octobre 11589.45 Novembre 10569.65 D ecembre 38360.35
PACA
tous les membres dun niveau :

1 2 3 4
SELECT temps.annee.MEMBERS ON COLUMNS, {geographie.region.PACA} ON ROWS FROM ventes WHERE (measures.montant)
R esultat : autant de colonnes quil y a de membres 1998 133419.96 1999 121598.45 2000 104789.56 2001 89634.25 2002 56986.12
PACA
une plage de membres :

1 2 3 4
SELECT {temps.annee.[1998] : temps.annee.[2001]} ON COLUMNS, {geographie.region.PACA} ON ROWS FROM ventes WHERE (measures.montant)
R esultat : autant de colonnes que dann ees entre 1998 et 2001 (inclus) 1998 133419.96 1999 121598.45 2000 104789.56 2001 89634.25
PACA
18
INTERROGER UN CUBE
86
Remarques : il ny a pas de confusion possible entre MEMBERS et CHILDREN puisque lun sapplique ` a un niveau, lautre ` a un membre : dimension . niveau . MEMBERS dimension . niveau . membre . CHILDREN on peut aussi utiliser : dimension . MEMBERS (les membres de tous les niveaux de la dimension) dimension . CHILDREN (les membres du niveau le plus elev e) avant dutiliser lop erateur :, sassurer de lordre dans lequel sont stock es les membres. 18.1.2 Mesures
On peut acher plusieurs mesures ` a la fois. Mais comme le r esultat dune requ ete nautorise quune valeur par cellule, il faut aligner les mesures selon un axe :
1 2 3
SELECT temps.annee.MEMBERS ON COLUMNS, {measures.montant, measures.NbCommandes} ON ROWS FROM ventes
R esultat : sur tous les articles et dans tous les pays 1998 1133419.96 2569 1999 1121598.45 2107 2000 1104789.56 1568 2001 189634.25 1474 2002 156986.12 978
montant nb
Les mesures forment donc naturellement une dimension nomm ee measures dans chaque cube. On pr ecise quelle mesure acher dans la clause WHERE quand on en veut quune (cest une tranche du cube). Et on est oblig e den pr eciser au moins une, sans quoi une mesure est choisie par d efaut. 18.1.3 Clause WHERE
On peut eectuer plusieurs d ecoupes sur le cube. Reprenons par exemple la requ ete pr ec edente :
1 2 3 4
SELECT temps.annee.MEMBERS ON COLUMNS, {measures.montant, measures.NbCommandes} ON ROWS FROM ventes WHERE (produits.marque.Channel, geographie.pays.Italie)
R esultat : sur tous les articles de la marque Channel et pour lItalie seulement 1998 419.96 69 1999 598.45 107 2000 789.56 68 2001 634.25 74 2002 986.12 78
montant nb
Remarques : une dimension ne peut appara tre quune fois dans la clause WHERE ; si on veut plusieurs tranches dans une dimension, il faut en faire un axe ; on ne peut utiliser dans la clause WHERE ni MEMBERS ni CHILDREN. Le grand danger relatif aux d ecoupes de cube, est que certaines applications MDX nachent pas les tranches alors que cest une information indispensable pour comprendre les valeurs des mesures.
18
INTERROGER UN CUBE Description des axes
87
18.1.4
Une requ ete MDX autorise jusqu` a 127 axes, mais evidemment on ne peut pas d epasser le nombre de dimensions du cube +1 (avec la dimension measures). Les cinq premiers axes sont : COLUMNS, ROWS, PAGES, SECTIONS et CHAPTERS. Au-del` a il faut utiliser : AXIS(5), ..., AXIS(126). Exemple a ` quatre dimensions :
1 2 3 4 5
SELECT temps.annee.MEMBERS ON COLUMNS, geographie.pays.MEMBERS ON ROWS, produits.article.MEMBERS ON PAGES, {measures.montant, measures.NbCommandes} ON SECTIONS FROM ventes
On peut aussi cr eer un r esultat ayant un seul axe :

1 2 3
SELECT temps.annee.MEMBERS ON COLUMNS FROM ventes WHERE (measures.montant)
R esultat : les intitul es de colonne et une seule ligne de r esultats (pas dintitul e de ligne) 1998 1133419.96 1999 1121598.45 2000 1104789.56 2001 189634.25 2002 156986.12
Ou m eme nayant aucun axe :

1 2 3
SELECT FROM ventes WHERE (measures.montant)
R esultat : une cellule contenant le montant total des ventes de toutes les ann ees pour tous les produits et partout (cest un mauvais exemple) 3706428.34 18.1.5 MDX vs. SQL
Comme on vient de le voir, les requ etes MDX ressemblent beaucoup aux requ etes SQL de s election. Ceci dit, notons quand m eme des di erences fondamentales : la syntaxe des clauses SELECT et WHERE na rien ` a voir ; la clause FROM nadmet quun seul cube, en MDX ; les clauses SQL GROUP BY, HAVING et ORDER BY nexistent pas en MDX ; et il existe dautres clauses sp eciques ` a MDX (WITH et CELL PROPERTIES).
18
INTERROGER UN CUBE
88
18.2
Filtrage des donn ees
Jusqu` a maintenant, la clause SELECT na servi qu` a s electionner les membres que lon peut d esigner. Si on veut faire intervenir un crit` ere plus complexe, comme : ne garder que les membres dont une mesure est dans une certaine plage, alors il faut utiliser la fonction MDX : FILTER(les membres ` a lter, (le crit` ere))
Par exemple, pour nacher que les ann ees pour lesquelles on a vendu pour plus de 100000 :
1 2 3
SELECT FILTER(temps.annee.MEMBERS, (measures.montant > 113000)) ON COLUMNS FROM ventes WHERE (measures.montant)
R esultat : il ne reste que les ann ees concern ees par le crit` ere 1998 1133419.96 2001 189634.25 2002 156986.12
Remarques : la mesure dans la clause WHERE nest pas obligatoirement la m eme que celle utilis ee dans le ltre ; le crit` ere peut faire appel aux fonctions MDX (cf. aide en ligne). Exemple : pour ne garder que les pays qui ont vendu plus que la France, lItalie et lAllemagne
1 2 3 4 5
SELECT FILTER(geographie.pays.MEMBERS, (measures.montant > MAX({France, Italie, Allemagne}, measures.montant) )) ON COLUMNS FROM ventes WHERE (measures.montant)
-- ici
Remarque : MDX ore toutes les fonctions dagr egat (mais avec deux arguments) ainsi que MEDIAN. Si le crit` ere ne porte pas directement sur les agr egats des membres ` a ltrer mais sur des valeurs plus nes, alors il faut faire appel ` a la notion de tuple pour d ecrire ces valeurs. Le tuple est la g en eralisation de la notion de couple et de triplet, il correspond aux coordonn ees des valeurs voulues dans le cube. Exemple de tuple : le montant des ventes pour le mois de janvier 2002 se note par le couple : ([2002].janvier, measures.montant)
Autre exemple : le nombre de commandes du client Razibus en France et en 1999 se note par le quadruplet : (clients.Razibus, geographie.France, temps.[1999], measures.NbCommandes) Remarques : lordre a parfois de limportance dans un tuple ; les composantes dun tuple doivent etre issues de dimensions di erentes.
18
INTERROGER UN CUBE
89
Avec cette notation, on peut par exemple ltrer les articles pour lesquels les ventes ont augment e entre janvier 2001 et janvier 2002 :
1 2 3 4 5
SELECT FILTER(produits.article.MEMBERS, (([2001].janvier, measures.montant) < ([2002].janvier, measures.montant)) ) ON COLUMNS FROM ventes WHERE (measures.NbCommandes) -- on nest pas oblige dafficher le montant
Remarque : les membres ` a ltrer peuvent etre d enis en plusieurs fois. Par exemple, pour ltrer les mois de 2001 et de 2002 pendant lesquels il a et e vendu pour un montant sup erieur ` a 10 000 :
1 2 3
SELECT FILTER({[2001].CHILDREN, [2002].CHILDREN}, (measures.montant > 10000)) ON COLUMNS ...
Remarque : on peut acher les deux montants utilis es dans le ltre

1 2 3 4 5 6
SELECT FILTER(produits.article.MEMBERS, (([2001].janvier, measures.montant) < ([2002].janvier, measures.montant)) ) ON COLUMNS, {([2001].janvier, measures.montant), ([2002].janvier, measures.montant)} ON ROWS FROM ventes
Compl ements Sans utiliser la fonction FILTER, on peut eliminer simplement les membres qui ne contiennent pas de donn ees : SELECT NON EMPTY {...} ON COLUMNS Par ailleurs, on peut ne garder que les membres extremaux avec la fonction : TOPCOUNT(les membres ` a ltrer, le nombre voulu, (la mesure pour etablir le classement)) Filtrons par exemple les 10 articles les plus vendus :
1 2 3
SELECT TOPCOUNT(article.MEMBERS, 10, (measures.NbCommandes)) ON COLUMNS ...
Remarques : l` a aussi, on peut d ecrire les membres ` a ltrer en plusieurs fois (en utilisant des accolades) ; l` a aussi, on peut employer un tuple en troisi` eme argument ; exemple : les 10 articles les plus vendus en 1998 :
1 2 3
SELECT TOPCOUNT(article.MEMBERS, 10, (measures.NbCommandes, [1998])) ON COLUMNS ...
on a evidemment la fonction BOTTOMCOUNT (m eme syntaxe) ; il existe aussi TOPSUM et TOPPERCENT (cf. laide en ligne).
18
INTERROGER UN CUBE
90
18.3
Disposition des r esultats
On peut encore rendre les requ etes MDX plus complexe lorsque lon chercher ` a r eorganiser les r esultats. 18.3.1 Ordonner les axes
Pour ordonner les membres dans un axe et selon une mesure (et non pas par ordre alphab etique), on utilise dans la clause SELECT la fonction : ORDER(les membres ` a trier, (la mesure selon laquelle trier), ASC ou DESC)
Exemple, pour ordonner les ann ees de la plus lucrative ` a la moins lucrative :
1 2
SELECT ORDER(annee.MEMBERS, (measures.montant), DESC) ON COLUMNS ...
Remarques : on peut faire appel aux tuples pour d esigner le crit` ere de tri ; exemple, les ann ees de la plus lucrative a la moins lucrative en France : `
1 2
SELECT ORDER(annee.MEMBERS, (measures.montant, pays.France), DESC) ON COLUMNS ...
a ` nouveau, on peut d ecrire les membres ` a trier en plusieurs fois (en utilisant des accolades). Par exemple, trions les mois de 2000 et de 2001 selon le montant des ventes de pinceaux :
1 2 3
SELECT ORDER({[2000].CHILDREN, [2001].CHILDREN}, (produits.pinceau, measures.montant), ASC) ON COLUMNS ...
Mais le probl` eme avec ASC et DESC est que la hi erarchie est respect ee (dans notre exemple, les mois de 2000 seront tri es s eparemment des mois de 2001). Pour ne pas tenir compte de la hi erarchie, il sut dutiliser BASC et BDESC. 18.3.2 Axes pluridimensionnels
On a parfois besoin que le r esultat ne comporte que deux axes (ne serait-ce que pour limprimer), sans pour autant perdre la possibilit e dutiliser 3 dimensions ou plus dans la clause SELECT. La solution consiste ` a repr esenter plusieurs dimensions par axe. Pour cela, on utilise les tuples. Exemple, pr esentons ` a la fois les ann ees et les pays en colonne :
1 2 3
SELECT {(France,[2000]), (France,[2001]), (Italie,[2000]), (Italie,[2001])} ON COLUMNS ...
R esultat : certains intitul es sont multicolonnes France 2000 2001 Italie 2000 2001
18
INTERROGER UN CUBE
91
Remarques : dans ce cas, lordre ` a lint erieur de chaque tuple a de limportance ; les tuples doivent etre homog` enes (cest-` a-dire pr esenter les m emes dimensions et dans le m eme ordre). Si on veut ensuite d etaill e chaque ann ee selon les produits A, B et C, on voit tout de suite que la clause SELECT serait longue ` a ecrire (12 triplets). Heureusement, on peut g en erer les tuples par produit cart esien :
1 2 3 4 5 6 7
SELECT CROSSJOIN({France, Italie}, {[2000], [2001]}) ON COLUMNS ... -- donne la meme chose que precedemment SELECT CROSSJOIN(CROSSJOIN({France, Italie}, {[2000], [2001]}), {A, B, C}) ON COLUMNS ...
R esultat : trois dimensions sur laxe des colonnes France 2000 A B C A 2001 B C A 2000 B C A Italie 2001 B C
18.4
Clause WITH
Comme on la d ej` a vu, les requ etes MDX pr esentent une derni` ere clause, la clause WITH qui ore la possibilit e de d enir certains objets avant le d ebut du SELECT. Les objets d enis dans une clause WITH ne sont visibles que dans la clause SELECT qui suit. Cest pourquoi Analysis Services propose egalement de les d enir dans l editeur de cube an quils soient utilisables par toutes les requ etes. Comme la syntaxe est la m eme, nous nous contentons ici dutiliser la clause WITH. 18.4.1 Membres calcul es
Un membre calcul e est un membre suppl ementaire dont la d enition repose sur les membres d ej` a pr esents dans le cube. Il sagit dun calcul entre membres dont le r esultat peut etre utilis e comme un membre ` a part enti` ere. Exemple : ` a partir des membres juillet 2001 et juillet 2002, on peut d enir un membre calcul e qui repr esente la progression entre juillet 2001 et juillet 2002 ainsi :
1 2 3 4 5 6
WITH MEMBER temps.[de juillet 2001 a juillet 2002] -- le nom complet AS temps.[2002].juillet - temps.[2001].juillet -- lexpression du calcul SELECT {temps.[2001].juillet, temps.[2002].juillet temps.[de juillet 2001 a juillet 2002]} ON COLUMNS FROM ventes WHERE (measures.montant)
18
INTERROGER UN CUBE
92
R esultat : la troisi` eme colonne pr esente la progression du chire daaire entre juillet 2001 et juillet 2002 juillet 2001 10186.12 juillet 2002 9486.78 de juillet 2001 a juillet 2002 -699.35
Jusquici on sest content e dutiliser les mesures brutes (tel quelles sont stock ees dans le cube). Si on veut acher des mesures plus complexes, il sut de d enir un membre calcul e en fonction dautres mesures. Si, par exemple, on dispose des mesures montant et quantite alors on peut d enir le membre calcul e prix unitaire :
1 2 3 4 5
WITH MEMBER measures.prix_unitaire -- le nom complet AS measures.montant / measures.quantite -- lexpression du calcul SELECT article.MEMBERS ON COLUMNS FROM ventes WHERE (measures.prix_unitaire)
Les membres calcul es ne sont pas retourn es par d efaut par la fonction MEMBERS, il faut utiliser la fonction ADDCALCULATEDMEMBERS. Si on veut voir appara tre le nouvelle mesure prix unitaire par exemple :
1 2 3 4 5
WITH MEMBER measures.prix_unitaire AS measures.montant / measures.nb SELECT ADDCALCULATEDMEMBERS(measures.MEMBERS) ON COLUMNS FROM ventes WHERE (temps.[2001])
Remarques : les valeurs des membres calcul es ne sont pas stock ees dans le cube, mais calcul ees ` a la vol ee (ce qui ralentit raisonnablement les requ etes) ; le membres calcul es peuvent etre utilis es dans la clause WHERE (cest dailleurs la seule fa con deffectuer une tranche qui concerne plusieurs membres de base du cube). Ordre de r esolution Il est parfois n ecessaire de pr eciser dans quel ordre les membres calcul es doivent etre calcul es. Cest le cas notamment lorsque lon combine pourcentage et di erence. Consid erons lexemple suivant :
1 2 3 4 5 6 7 8
WITH MEMBER temps.[de juillet 2001 a juillet 2002] AS temps.[2002].juillet - temps.[2001].juillet MEMBER measures.[profit (en pourcentage)] AS 100 * (measures.montant - measures.cout) / measures.cout SELECT {measures.montant, measures.cout, measures[profit (\%)]} ON COLUMNS, {temps.[2001].juillet, temps.[2002].juillet temps.[de juillet 2001 a juillet 2002]} ON ROWS FROM ventes
18
INTERROGER UN CUBE
93
Cette requ ete produit le r esultat suivant : la derni` ere cellule ne contient pas forc ement ce que lon veut montant 10186.12 9486.78 -699.35 cout 8451.00 7569.50 -881.5 prot (%) 20 25 -20
juillet 2001 juillet 2002 de juillet 2001 a juillet 2002
Pour obtenir la progression du prot en pourcentage il sut de pr eciser que le membre calcul e [de juillet 2001 a juillet 2002] doit etre calcul e apr` es le membre calcul e [profit (%)] :
1 2 3 4 5 6 7 8 9 10
WITH MEMBER temps.[de juillet 2001 a juillet 2002] AS temps.[2002].juillet - temps.[2001].juillet, SOLVE_ORDER = 2 MEMBER measures.[profit (en pourcentage)] AS 100 * (measures.montant - measures.cout) / measures.cout, SOLVE_ORDER = 1 SELECT {measures.montant, measures.cout, measures[profit (\%)]} ON COLUMNS, {temps.[2001].juillet, temps.[2002].juillet temps.[de juillet 2001 a juillet 2002]} ON ROWS FROM ventes
Auquel cas nous obtenons bien le pourcentage recherch e: montant 10186.12 9486.78 -699.35 cout 8451.00 7569.50 -881.5 prot (%) 20 25 5
juillet 2001 juillet 2002 de juillet 2001 a juillet 2002
Mise en forme des membres calcul es Dautres options sont disponibles dans la clause MEMBER (cf. laide en ligne). Comme par exemple, une description du format num erique ` a employer :
1 2 3 4
WITH MEMBER measures.prix_unitaire AS measures.montant / measures.quantite, FORMAT_STRING = #.## euros SELECT ... Jeux nomm es
18.4.2
Si un ensemble de membres est souvent utilis es dans des requ etes MDX, il est int eressant de le d enir une bonne fois pour toutes et de lui donner un nom. Cest ce que lon appelle un jeu (sous-entendu de membres) nomm e. Si, par exemple, les 10 articles les plus vendus reviennent souvent alors on peut d enir un jeu nomm e ainsi :
1 2 3 4 5
WITH SET MeilleursArticles -- le nom AS TOPCOUNT(article.MEMBERS, 10, measures.quantite) -- lexpression SELECT MeilleursArticles ON COLUMNS FROM ventes WHERE (measures.nb)
18
INTERROGER UN CUBE
94
Dans la d enition dun jeu nomm e, on peut utiliser les fonctions ensemblistes UNION, EXCEPT et INTERSECT. Exemple :
1 2 3 4 5 6 7 8 9 10 11
WITH SET MeilleursArticles AS TOPCOUNT(article.MEMBERS, 10, (measures.quantite)) SET ArticlesLesPlusCher AS TOPCOUNT(article.MEMBERS, 10, (measures.prix_unitaire)) SET MeilleursArticlesEtArticlesLesPlusCher AS UNION(MeilleursArticles, ArticlesLesPlusCher) SET MeilleursArticlesSaufLesPlusCher AS EXCEPT(MeilleursArticles, ArticlesLesPlusCher) SET MeilleursArticlesQuiSoientParmisLesPlusCher AS INTERSECT(MeilleursArticles, ArticlesLesPlusCher) SELECT ... Cellules calcul ees
18.4.3
Il existe un troisi` eme objet que lon peut d enir dans la clause WITH, il sagit des cellules calcul ees (CELL CALCULATION). Mais cet objet est trop complexe pour entrer dans le cadre de ce document. Le lecteur est donc dirig e vers laide en ligne et [12] pour d ecouvrir cette notion. 18.4.4 Pr ecisions
Si un intitul e comporte une quote , alors elle doit etre doubl ee an de ne par interf erer avec la d elimitation de lexpression :
1 2
WITH MEMBER article.[Tous les albums de ks Choice] AS SUM({[ks Choice - Cocoon Crash], [ks Choice - Paradise in me]})
Si on d esire introduire plusieurs notations dans la clause WITH, il sut de les juxtaposer (les virgules sont r eserv ees aux propri et es des membres calcul es) :
1 2 3 4
WITH MEMBER ... AS ... MEMBER ... AS ... SET ... AS ... SELECT ...
18.5
Clause CELL PROPERTIES
Par ailleurs, on peut contr oler les propri et es de cellule que lon veut acher dans la fen etre contextuelle (qui appara t au clic droit sur une cellule) ` a laide la derni` ere clause des requ etes MDX. Par exemple, pour nacher que lordinal et la valeur formatt ee :
1 2 3 4
SELECT ... FROM ... WHERE ... CELL PROPERTIES CELL_ORDINAL, FORMATTED_VALUE
18
INTERROGER UN CUBE
95
18.6
Fonctions MDX
Dans ces requ etes on peut ` a tout moment utiliser une multitude dautres fonctions oertes par MDX ` commencer par la fonction : (cf. laide en ligne et [12]). A IIF(condition, si vrai, si faux ) Exemple : achons oui ou non en deuxi` eme colonne selon que les articles se sont vendus moins de 200 fois ou non :
1 2 3 4 5 6
WITH MEMBER measures.MauvaisArticle AS IIF(measures.quantite < 200, "oui", "non") SELECT {measures.quantite, measures.MauvaisArticle} ON COLUMNS, article.MEMBERS ON ROWS FROM ventes WHERE (temps.[2001])
MDX ore aussi la fonction ISEMPTY et qui permet de remplacer la valeur NULL par 0 (par exemple) :
1 2 3 4 5
WITH MEMBER measures.[quantite corrigee] AS IIF(ISEMPTY(measures.quantite), 0, measures.quantite) SELECT temps.[2003].CHILDREN ON COLUMNS, article.MEMBERS ON ROWS FROM ventes WHERE (measure.[quantite corrigee])
Remarque : dans la condition de la fonction IIF, on peut utiliser le mot-cl e NOT. Autre exemple, pour retrouver un anc etre : s electionner la r egion dans laquelle se trouve la ville de Nice
1 2
SELECT {ANCESTOR(Nice,region)} ON COLUMNS ...
Remarques : le premier argument doit etre un membre unique ; le deuxi` eme argument est soit le niveau auquel on monte, soit le nombre de niveaux ` a monter. Exemple pour retrouver les descendants : s electionner les articles de la marque Channel
1 2
SELECT DESCENDANTS(Channel, article) ON COLUMNS ...
Remarques : le premier argument doit etre un membre unique ; le deuxi` eme argument est soit le niveau auquel on descend, soit le nombre de niveaux ` a descendre. Dernier exemple : pour d enir une colonne dagr egat qui comprend la France et lItalie par exemple
1 2 3 4 5
WITH MEMBER geographie.[France et Italie] AS AGGREGATE({France, Italie}) SELECT {France, Italie, [France et Italie]} ON COLUMNS, Measures.MEMBERS ON ROWS FROM ventes
La fonction AGGREGATE utilise alors la fonction dagr egation appropri ee ` a chaque mesure.
19
OBJETS VIRTUELS
96
18.7
Conclusion
On aboutit ` a la strat egie suivante pour l elaboration dune requ ete MDX : 1. remplir la clause FROM avec le cube sur lequel on travaille ; 2. d enir dans la clause WITH les membres calcul es, les jeux nomm es et les cellules calcul ees locaux ; 3. d eterminer les tranches voulues pour remplir le tuple de la clause WHERE ; 4. pour chaque axe de la clause SELECT (et dans lordre) : (a) d eterminer les dimensions et les membres concern es ; (b) ltrer eventuellement ces membres avec FILTER, NON EMPTY et/ou TOPCOUNT ; (c) ordonner eventuellement les membres restants avec ORDER : (d) lister apr` es le mot-cl e PROPERTIES les propri et es de membres (cf. 19.1 page 96) que lon veut ajouter aux propri et es de cellule. 5. lister dans la clause CELL PROPERTIES les propri et es de cellule (cf. 18.5 page 94) que lon souhaite avoir ` a disposition.
19
Objets virtuels
Sont regroup ees ici quelques notions importantes qui permettent une plus grande souplesse dans la gestion des informations.
19.1
Propri et e de membre
Une propri et e de membre est une information relative ` a un niveau, stock ee dans la table de dimension concern ee, mais qui ne participe pas ` a la hi erarchie. Dans la dimension temps par exemple, linformation lundi, mardi, ..., dimanche relative au niveau jour est une propri et e des membres 1, 2, ..., 31. Dans la table de dimension temps, cette donn ees que lon peut appeler JourDeLaSemaine est stock ee dans une colonne suppl ementaire contenant les valeurs 1, 2, ..., 7 (se m eer car 1 ne correspond pas forc ement au lundi). Autres exemples de propri et es de membres : le coloris dun article ; la population dune ville. Il va sans dire que pour etre utilisables, ces propri et es de membres doivent etre pr esentes dans la base d ecisionnelle (et donc pr evues ` a lavance an que lETL puisse les alimenter). An dacher une propri et e de membre dans un requ ete MDX, il sut de la pr eciser dans la zone PROPERTIES de la clause SELECT. Exemple : on d esire acher la couleur et la taille des articles ainsi que le genre des clients :
1 2 3 4 5 6 7
SELECT produits.article.MEMBERS PROPERTIES produits.article.couleur, produits.article.taille ON COLUMNS, clients.MEMBERS PROPERTIES clients.genre ON ROWS FROM ventes WHERE (measures.montant)
19
OBJETS VIRTUELS
97
Dans certaines applications MDX, ces informations ne sont pas disponibles directement sur le r esultat de la requ ete. Il faut alors cliquer droit sur la cellule d esir ee an dobtenir les propri et es de la cellule. Mais par ailleurs, les propri et es de membres permettent de r epartir les donn ees en cat egories au m eme titre que les niveaux. Mais pour quelles soient utilis ees comme les niveaux il faut introduire la notion de dimension virtuelle.
19.2
Dimension virtuelle
Jusqu` a maintenant nous navons abord e que les dimensions physiques dun cube. Une dimension virtuelle est une dimension purement logique, fond ee sur une dimension physique, et dont les niveaux sont choisis parmi toutes les colonnes ce cette dimension, y compris les colonnes propri et es de membre. Lintroduction dune colonne virtuelle ne modie pas le stockage du cube. Cest simplement une nouvelle fa con dorganiser les donn ees. Par exemple, avec une dimension virtuelle semaine dont le seul niveau est JourDeLaSemaine, on peut comparer les ventes des lundis aux ventes des mardis (ce que lon ne pouvait pas faire avec la dimension physique temps sous-jacente). Remarques : on peut utiliser les dimensions virtuelles dans les requ etes MDX (en tant quaxe ou d ecoupage) ; les agr egats relatifs aux dimensions virtuelles ne sont pas stock es dans le cube mais calcul es ` a la vol ee ce qui induit un ralentissement des requ etes y faisant appel. Exemple :
1 2 3
SELECT semaine.JourDeLaSemaine.MEMBERS ON COLUMNS FROM ventes WHERE (measures.montant)
19.3
Cube virtuel
Le cube virtuel est aux cubes, ce que la vue est aux tables, cest-` a-dire : soit un sous-cube ; soit une combinaison de plusieurs cubes (qui ont des dimensions communes) en un cube logique. Exemples de cubes virtuels : le cube MiniVentes qui ne garde que les dimensions temps et geographie et uniquement la mesure montant du cube physique ventes ; si on a les cubes physiques VentesEntreprise1 et VentesEntreprise2, on peut utiliser un cube virtuel pour les regrouper en un seul (mauvais exemple, car on on aurait plut ot tendance ` a fusionner les bases d ecisionnelles et les cubes physiques dans ce cas) ; les cubes sur les ventes, sur la production et sur lapprovisionnement peuvent etre physiquement s epar es et rassembl es dans un cube virtuel gr ace ` a leurs dimensions communes (le temps et les produits, par exemple). Remarques : les cubes virtuels ne contiennent que des d enitions, pas de donn ees ; il faut pourtant les traiter, ce traitement consiste uniquement ` a etablir les liens internes vers les dimensions et les mesures concern ees et eventuellement ` a d eclencher le traitement des cubes sousjacents ; de m eme que la vue, le cube virtuel est un el ement : de s ecurit e car il peut masquer aux utilisateurs les donn ees qui ne le concernent pas ;
20
EXPLORATION DE DONNEES
98
et de simplicit e car il permet de masquer les donn ees inutiles et de regrouper les donn ees utiles selon les utilisateurs ; une requ ete MDX peut porter sur un cube virtuel (clause FROM), cest dailleurs la seule fa con dutiliser plusieurs cubes. Exemple : le cube utilis e dans la requ ete donn ee en exemple pour introduire lordre de r esolution (cf. page) est vraisemblablement virtuel car les deux mesures montant et cout nont pas le m eme grain (le co ut dun produit ne d epend pas du client qui lach` ete). Elles appartiennent donc ` a deux cubes physiques distincts (si lentrep ot est bien con cu) qui ont pour dimensions communes temps et produits.
20
Exploration de donn ees
En anglais on parle de data mining. Cest lensemble des techniques qui permettent de construire des mod` eles dun entrep ot de donn ees historis ees (i.e. avec une dimension temps) an de d ecrire et/ou de pr edire des tendances et les r` egles qui les r egissent. Le march e mondial du data mining est fortement domin e par Enterprise Miner (SAS). Les autres produits disponibles sont : Clementine de SPSS, Knowledge Seeker de Angoss et Intelligent Miner de IBM. Oracle propose aussi des fonctionnalit es de data mining depuis le rachat de Thinking Machines. Il sagit simplement ici de d ecouvrir les quelques fonctionnalit es oertes par Analysis Services.
20.1
Mod` eles
Il existent de nombreux algorithmes de data mining (cf. [11]), Analysis Services en ore deux : lorganisation en clusters (groupage) ; et larborescence de d ecision.
20.1.1
Clustering
Avant toute chose, on appelle classication toute technique visant ` a composer des classes dobjets homog` enes (autrement dit pour nous : former des ensembles de donn ees ayant des caract eristiques communes). Par exemple si on note sur un graphe les boissons favorites de di erentes personnes class ees selon leur age en abscisse et selon la boisson propos ee en ordonn ee, alors on pourra vraisemblablement regrouper les jeunes autour des sodas, les plus ag es autour des vins et les autres autour des bi` eres (cf. gure 23).
Fig. 23 Exemple de classication
20
99
Le clustering est une technique de classication utilisant une fonction distance pour s eparer les groupes. Exemple de distance : la distance euclidienne dans RM , avec M le nombre de caract eristiques (ou variables explicatives) m (pour nous, ces caract eristiques sont des mesures ou propri et es de membre) utilis ees pour distinguer les groupes. La distance s eparant deux objets i et j etant alors :
1/2
d(i, j ) =
m
m(j ) m(i)
Exemple de groupage sappuyant sur une distance : la m ethode des k -moyennes (ou m ethode des centres mobiles). On veut classer N objets en K groupes (avec K N ), pour cela : choisir K objets initiaux appel es centres des K -groupes (au hasard) ; placer chacun des N objets dans le groupe dont le centre est le plus proche (utilisation de la distance d) ; recalculer le centre de chaque groupe (barycentrage) ; et it erer les deux etapes pr ec edentes jusqu` a ce que plus aucun objet ne change de groupe. Une fois que les groupes ont et e etablis sur un echantillon repr esentatif, on est en mesure de mieux conna tre tout nouvel objet, gr ace ` a son appartenance ` a une classe homog` ene (dont on conna t le comportement), simplement en examinant ses caract eristiques. Exemple dutilisation : (commercial) grouper les clients an de cibler lenvoi dores promotionnelles ; (assurances) grouper les soci etaires an de d eterminer si un nouveau client est able. Remarques : un cluster solide est constitu e dune population signicative (i.e. dont la tendance centrale est fonci` erement di erente des autres, et dune dispersion faible) ; si la population dun cluster est trop faible, il est pr ef erable de le grouper avec un autre ; si le cluster est trop dispers e, il est pr ef erable de le scinder et de relancer le processus sur les sous-groupes ; certains cluster peuvent etre diciles ` a expliquer. 20.1.2 Arbre de d ecision
Pour aller plus loin dans lexploration des donn ees, on peut essayer de d eterminer des r` egles de comportement. Exemple de r` egle : un client qui a achet e un monospace est g en eralement mari e avec au moins deux enfants. Le principe de fonctionnement dun arbre de d ecision est le suivant : pour expliquer une variable, le syst` eme recherche le crit` ere le plus pertinent et d ecoupe la population en sous-populations poss edant la m eme valeur pour ce crit` ere (phase dexpansion) ; un nud dans larbre est terminal (cest-` a-dire une feuille) si sa population ne contient plus assez dindividus pour etre subdivis ee ; les branches non pertinentes sont elimin ees (phase d elagage) ; le processus reprend avec les autres nuds jusqu` a ce quil ne reste que des feuilles ou jusqu` a epuisement des crit` eres. Exemple darbre : la variable ` a expliquer est le fait dacheter un monospace. Le premier crit` ere trouv e par le syst` eme est le nombre denfants. Les branches ` a 2 enfants et 3 enfant ou plus peuvent etre d etaill ees selon un deuxi` eme crit` ere, ` a savoir le fait d etre mari e ou non. Les branches les plus pesantes sont alors
20
100
Fig. 24 Exemple darbre de d ecision pour les personnes mari ees. On peut alors conclure ` a la r` egle ci-dessus. Remarques : la construction dun arbre fait appel ` a plusieurs notions statistiques : 2 au test du : ` a lindice de puret e de Gini ; ` a un fonction dentropie ; les arbres sont g en eralement bien appr eci es car les r` egles trouv ees sont tr` es explicites et la visualisation est intuitive ; mais lalgorithme est tr` es co uteux.
20.2
Impl ementation
Int eressons-nous maintenant ` a limpl ementation des ces algorithmes. Dune mani` ere g en erale, il est tr` es dicile de savoir comment sont impl ement ees les choses dans SQL Server. Cette section se fonde sur deux articles publi es par le centre de recherche de Microsoft (cf. [2] et [5]). 20.2.1 Vocabulaire
Les donn ees n ecessaires au data mining se pr esentent sous la forme dune table ayant N lignes, M colonnes explicatives A1 , . . . , AM (crit` eres, caract eristiques) et une colonne ` a expliquer B . B est forc ement qualitative 23 , sinon il sagit dun probl` eme de r egression. Analysis Services emploie le vocabulaire suivant : un cas est une des N lignes ; lentit e pr evue est la variable ` a expliquer B ; les attributs sont les variables explicatives A1 , . . . , AM ; et la table des cas est : A1 a1 a1 . . . A2 a2 a2 . . . ... B b1 b2 . . .
23. si B est continue, elle est discr etis ee en plusieurs intervalles
20
101
En pratique pour nous, les colonnes A1 , . . . , AM sont soit des mesures, soit des propri et es de membres contenues dans un cube ( eventuellement virtuel). La table des cas est donc construite ` a partir de la table des faits en jointure avec les tables de dimension concern ees par les propri et es de membres. 20.2.2 Pr eparation des donn ees
Les donn ees de la table des cas sont trop volumineuses pour entrer en m emoire centrale. En r ealit e, un ensemble r eduit de statistiques sur ces cas sut pour mener les algorithmes pr ec edents. Il sagit de la table de comptage des co-occurrences (not ee CC) constitu ee de quatre colonnes : colonne A1 A1 A2 A2 . . . valeur a1 a1 a2 a2 . . . classe b1 b2 b1 b2 . . . nombre 20 38 44 12 . . .
Remarques : la table CC est beaucoup moins volumineuse ; les calculs seectuent ensuite uniquement ` a partir de la table CC ; il est possible de construire la table CC en ne lisant les donn ees quune seule fois. Pour calculer larbre de d ecision, lorsque lattribut le plus pertinent est A2 , le calcul du poids de la branche a2 utilisera les lignes de CC o` u A2 = a2 . Ensuite, si lattribut suivant est A1 le poids de la branche a1 dans la branche a2 utilisera les lignes de CC o` u A2 = a2 et A1 = a1 . Table des cas non pivot ee Pour remplir la table CC, il est pr ef erable de ne pas partir directement de la table des cas, mais de mettre la table des cas sous la forme suivante (appel ee UnpivotedCases) : ligne 1 1 2 2 . . . classe b1 b1 b2 b2 . . . colonne A1 A2 A1 A2 . . . valeur a1 a2 a1 a2 . . .
En eet, la table CC est alors le r esultat de la requ ete simple suivante :

1 2 3
SELECT colonne, valeur, classe, COUNT(*) FROM UnpivotedCases GROUP BY colonne, valeur, classe
20
EXPLORATION DE DONNEES Remarques : UnpivotedCases est calcul ee ` a partir de la table des cas gr ace ` a un nouvel op erateur :
1
102
UnpivotedCases = Cases.UNPIVOT(valeur FOR colonne IN(A1, A2, ...))
la force de cet op erateur est que la cr eation de CC fait appel ` a une seule lecture des donn ees. Bref (cf. gure 25) : les calculs se font sur la table CC ; la table CC est calcul ee ` a partir de la table des cas non pivot ee par une requ ete de d enombrement simple ; la table des cas non pivot ee est issue de la table des cas gr ace ` a lop erateur UNPIVOT ; la table des cas est obtenue par jointure entre la table des faits et les tables de dimension.
Fig. 25 Pr eparation des donn ees pour le data mining
20.2.3
Objets suppl ementaires
Le r esultat dun mod` ele de mining dans un cube, constitue une nouvelle dimension de ce cube. Cette dimension est cr e ee automatiquement et : pour le clustering, chaque cluster constitue un membre (un seul niveau) ; pour les decision trees, larbre correspond ` a la hi erarchie de cette dimension. Cette dimension est virtuelle. Les donn ees relatives ` a un mod` ele de mining sont alors consultables ` a travers un cube virtuel (cr e e automatiquement) regroupant le cube de d epart et cette nouvelle dimension. Exemple :
1 2 3 4
SELECT produits.monospace.MEMBERS ON COLUMNS, mining_clients.[mari e].CHILDREN ON ROWS FROM ventes WHERE (measures.NbCommandes)
20
103
20.3
Pr ediction
Les mod` eles de mining pr ec edents permettent dextraire des tendances et des r` egles de nos donn ees. Il est int eressant maintenant de se servir de ces connaissances pour pr evoir les futures donn ees. 20.3.1 R eseau de d ependances
Cest un r eseau dont les nuds sont les variables (explicatives ou ` a expliquer) et dont les liens sont dirig es de la variable qui pr edit vers celle qui est pr edite. Les liens sont dautant plus forts que la pr ediction est able. Ce r eseau permet de voir pr ecis ement quels facteurs sont utiles ` a la pr ediction de tel facteur (en se basant sur les donn ees du mod` ele). 20.3.2 Donn ees pr evisionnelles
Apr` es avoir cr e e un mod` ele de mining, il est possible avec lutilitaire DTS (cf. 17 page 75) de remplir une nouvelle colonne B avec de nouvelles valeurs pour les colonnes A1 , . . . , AM (cf. gure 26). Il sagit
Fig. 26 M ecanisme de pr ediction simplement dune t ache que lon peut ins erer dans un lot.
20.4
Conclusion
Le data mining fait appel ` a de nombreux calculs de statistiques et permet denrichir la valeur des donn ees contenues dans lentrep ot. Dautres techniques (comme les r eseaux neuronaux ou lanalyse de panier) seront sans doutes fournies dans les prochaines versions du logiciel.
CONCLUSION
104
Conclusion sur la partie d ecisionnelle

On peut r esumer le syst` eme d ecisionnel ainsi (cf. gure 27) : les bases de production g er ees en OLTP fournissent les donn ees ; lutilitaire DTS traite ces donn ees pour alimenter les cubes OLAP (phase dextraction) ; ces cubes sont l` a pour organiser et agr eger les donn ees pour les requ etes MDX et les mod` eles de mining (phase de stockage) ; des interfaces graphiques (que ce soit des requ eteurs comme Business Objects, des tableurs comme Excel ou des SIAD pour Syst` eme Interactif dAide ` a la D ecision, ou en anglais, EIS pour Executive Information System) permettent gr ace ` a cela de s electionner et dexplorer les donn ees (phase de consultation) ; les informations et les connaissances sont alors exploitables (phase de pr esentation).
Fig. 27 Sch ema du syst` eme d ecisionnel Dans lentreprise les r oles concernant le syst` eme d ecisionnel se r epartissent ainsi : les concepteurs de lentrep ot de donn ees se charge de mettre en place le sch ema relationnel de la base d ecisionnelle, la structure des cubes et les mod` eles de mining ; les d eveloppeurs ont pour t ache, la mise en place de la phase ETL (environ 50% du temps), la programmation des requ etes MDX et des interfaces graphiques ; enn, il reste aux d ecideurs de sappuyer sur les r esultats pour prendre les bonnes d ecisions.
CONCLUSION
105
Sch ematiquement, dans des entreprises comme Air France ou la SNCF (cf. gure 28) : le syst` eme (gigantesque) de billetterie constitue le syst` eme transactionnel de production ; ces donn ees alimentent le cube des r eservations ; des consultations MDX permettent de conna tre la fr equentation des lignes ; tandis que des mod` eles de mining permettent d etablir la tendance de cette fr equentation ; nalement le responsable commercial pourra d ecider de la tarication optimale sur telle ligne ` a tel moment et le responsable logistique pourra augmenter ou r eduire le nombre de train ou davion, etc.
Fig. 28 Exemple de probl ematique d ecisionnelle Notons que dautres utilisations du syst` eme d ecisionnel sont possibles : la simulation (qui permet de r epondre aux questions du type (( que se passerait-il si ... ? ))) ; lemission dalertes automatiques (quand certains secteurs sont en perte de vitesse, par exemple) ; le contr ole des bases de production (le syst` eme d ecisionnel peut d etecter certaines anomalies).
TABLE DES FIGURES
106
Table des gures

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 Base de donn ees personnelle . . . . . . . . . . . . . . . . Base de donn ees professionnelle . . . . . . . . . . . . . . Exemple de base de donn ees professionnelle . . . . . . . Organisation physique du r eseau base de donn ees . . . . Relation entre deux tables . . . . . . . . . . . . . . . . . Di erents types dint egrit e. . . . . . . . . . . . . . . . . Traitement des donn ees dune transaction en m emoire . Sch ema du syst` eme transactionnel . . . . . . . . . . . . Exemple de transaction . . . . . . . . . . . . . . . . . . Exemple de cube : le cube ventes . . . . . . . . . . . . Cube bidimensionnel . . . . . . . . . . . . . . . . . . . . Cube ventes hi erarchis e. . . . . . . . . . . . . . . . . . Tables de dimension . . . . . . . . . . . . . . . . . . . . Sch ema en etoile dun cube ` a 5 dimensions et 2 mesures D ecomposition de la table produits . . . . . . . . . . . Sch ema en ocon . . . . . . . . . . . . . . . . . . . . . . Hi erarchie parent-enfant . . . . . . . . . . . . . . . . . . Auto-jointure dune table de dimension parent-enfant . . Cube r eduit pour les agr egats des niveaux sup erieurs . . Les etapes du processus ETL . . . . . . . . . . . . . . . Tables temporaires et tables tampon . . . . . . . . . . . Evolution des tables clients et commandes au cours du Exemple de classication . . . . . . . . . . . . . . . . . . Exemple darbre de d ecision . . . . . . . . . . . . . . . . Pr eparation des donn ees pour le data mining . . . . . . M ecanisme de pr ediction . . . . . . . . . . . . . . . . . . Sch ema du syst` eme d ecisionnel . . . . . . . . . . . . . . Exemple de probl ematique d ecisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . processus ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 8 9 18 36 46 55 56 58 64 65 68 69 70 71 72 72 74 76 78 81 98 100 102 103 104 105
ERENCES REF
107
R ef erences
Bibliographie
[1] Chaffin, Mark, Knight, Brian et Robinson, Todd. Professional SQL Server 2000 DTS. Wrox, 2000. Cet ouvrage volumineux ore de nombreuses solutions pour g erer les transformations de donn ees avec SQL Server. [2] Chaudhuri, Surajit, Fayyad, Usama et Bernhardt, Je. Scalable Classication over SQL Databases. Microsoft Research, Redmond, USA, 1998 Cet article d emontre la scalabilit e de lalgorithme de classication de SQL Server. [3] Gardarin, Georges. Internet/Intranet et Bases de Donn ees. Eyrolles, 1999 Cet ouvrage th eorique d enit proprement les notions relatives au syst` eme d ecisionnel et les di erences avec le syst` eme transactionnel. , Jean-Marie. Le projet d [4] Gouarne ecisionnel. Eyrolles, 1998 Cet ouvrage d etaille la d emarche de conception dun syst` eme d ecisionnel. [5] Graefe, Goetz, Fayyad, Usama et Chaudhuri, Surajit. On the Ecient Gathering of Sucient Statistics for Classication from Large SQL Databases. Microsoft Corporation, Redmond, USA, 1998 Cet article pr esente les statistiques cach ees derri` ere le Data Mining de SQL Server ainsi que lop erateur UNPIVOT. [6] Grin, Richard. Langage SQL. Universit e de Nice Sophia-Antipolis, 1998 Ce support de cours pr esente la programmation SQL pour Oracle. [7] Gunderloy, Mike et Jorden, Joseph L. Mastering SQL Server 2000. Sybex, 2000 Cet ouvrage volumineux constitue une r ef erence sur lapprentissage de SQL Server 2000. [8] Gunderloy, Mike et Sneath, Tim. SQL Server Developers Guide to OLAP With Analysis Services. Sybex, 2001 Cet ouvrage constitue une r ef erence sur la programmation OLAP avec SQL Server 2000. [9] Israel, Marc. SQL Server 2000. Eyrolles, 2001 Cet ouvrage volumineux et en fran cais permet dapprendre facilement ` a utiliser SQL Server 2000. e, Christian et Ledant, Guy. SQL 2 : initiation, programmation. Dunod, 1999 [10] Mare Cet ouvrage permet de d ecouvrir la norme 92 du langage SQL. [11] Nakache, Didier, Caulier Donneger, Anne, Rivelois Dugresson, Pascale, Dassonville, Philippe et Delebecq, Jean-Louis. Data warehouse et data mining. C.N.A.M. de Lille, 1998 Ce support de cours d etaille le monde du d ecisionnel, y compris du data mining. [12] Spofford George. MDX Solutions. Wiley, 2001 Ce livre en anglais constitue une r ef erence du langage MDX et ore de nombreuses solutions pratiques.
ERENCES REF
108
Pages web
[13] www.gartner.com/reprints/informatica/106602.html Sur ce site en anglais, les outils ETL sont class es selon l etendue de leurs services et leur facilit e dutilisation. [14] www.informatica.com/news/awards/giga etl.pdf Dans ce document en anglais, on trouvera notamment la repartition du march e ETL et une br` eve etude des di erents outils ETL. [15] www.olapreport.com Les principales informations sur les produits qui se partagent le march e de lOLAP actuellement sont regroup ees sur ce site en anglais. [16] sqldts.com Ce site en anglais propose des tutoriels, une FAQ et des liens pertinents concernant les DTS. [17] www.swynk.com/faq/sql/sqlserverfaq.asp On trouvera sur cette page en anglais une FAQ correcte concernant SQL Server.
Newsgroups
[18] comp.databases.ms-sqlserver Ce newsgroup anglophone r epond ecacement aux probl` emes pos es par les utilisateurs de SQL Server. [19] microsoft.public[.fr].sqlserver et microsoft.public.sqlserver.olap ` noter enn lexistance de ces newsgroups maintenus par Microsoft. A
INDEX
109
Index
Symboles
et . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 84, 94 +, -, *, /, % . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 -- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 /* ... */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 <, <=, =, >=, >, <> . . . . . . . . . . . . . . . . . . . . . . . 11 ABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 ADDCALCULATEDMEMBERS . . . . . . . . . . . . . . . . . . . . . 92 ADD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 CONSTRAINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 AFTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 AGGREGATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 ALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 ALTER COLUMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 DATABASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 FUNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 PROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 TRIGGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 int er et . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 ANCESTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 AND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 ANY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ASC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 90 AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19, 20, 24 AVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 AXIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 BASC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 BDESC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 BEGIN ... END . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 BEGIN TRAN ... COMMIT TRAN . . . . . . . . . . . . . . 15 BETWEEN ... AND . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 BIGINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 BIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 BOTTOMCOUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 CASCADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 CASE WHEN ... ELSE ... END . . . . . . . . . . . . . . 13 CEILING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 CELL ORDINAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 CELL CALCULATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 PROPERTIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 CHAPTERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 CHAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 CHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 CHILDREN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 COLUMNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 CONSTRAINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 COS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 COUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 CREATE CUBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 DATABASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 DEFAULT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 FUNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 PROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 TRIGGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 CROSSJOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 DATEADD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 DATEDIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 DATEPART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 DATETIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 DECIMAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 DECLARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 DEFAULT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 34 DELETE ... FROM ... WHERE . . . . . . . . . . . . . . . 29 DENY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 DESCENDANTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 DESC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 90 DIMENSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 DISABLE TRIGGER . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 DISTINCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 DROP COLUMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 CONSTRAINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 DATABASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 DEFAULT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 FUNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 PROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 TRIGGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 ENABLE TRIGGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 EXCEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 EXEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 EXISTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 EXP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 FILEGROWTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 FILENAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 FILTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 FLOOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 FOREIGN KEY ... REFERENCES . . . . . . . . . . .18, 35
INDEX FORMATTED VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 FORMAT STRING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 FULL OUTER JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 GETDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 GO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 GRANT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 GROUP BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 HAVING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 IDENTITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 IF ... ELSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 IIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 INSERT ... SELECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 VALUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 INSTEAD OF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 INTERSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 INT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 ISEMPTY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 ISNULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 JOIN ... ON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 LEFT JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 LEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 LIKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 LOG10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 ON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 LOWER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 MAXSIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 MAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 88 MEASURE ... FUNCTION . . . . . . . . . . . . . . . . . . . . . 64 MEDIAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 MEMBERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 MIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 MODIFY NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 NON EMPTY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 NOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 95 NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ON COLUMNS, ROWS, etc. . . . . . . . . . . . . . . . . . . 87 DELETE, UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 37 PRIMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ORDER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 60 OR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 OUTPUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 PAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 PI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 POWER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 PRIMARY KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 35
110 PRINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 PROPERTIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 RAISERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 READ COMMITTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 REAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 REPLACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 RETURNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 RETURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 REVOKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 RIGHT JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ROLLBACK TRANSACTION . . . . . . . . . . . . . . . . . . . . . 38 ROWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 SECTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 SELECT ... FROM ... WHERE . . . . . . . . . . . . . . . . . . . . . 18, 83 INTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 SERIALIZABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 LOCK TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 TRANSACTION ISOLATION LEVEL . . . . . . . . . 46 SIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 SIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 SMALLINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 SOLVE ORDER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 SQRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 SQUARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 STDEV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 SUBSTRING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 SUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 TAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 TINYINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 TOPCOUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 TOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 PERCENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 SUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 TYPE ALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 DAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 MONTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 YEAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 UNION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 94 ALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 UNIQUEIDENTIFIER . . . . . . . . . . . . . . . . . . . . . . . . . . 17 UNIQUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 UNPIVOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 UPDATE ... SET ... FROM ... WHERE . . . . . . 30 UPPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 VARCHAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 VAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 WHERE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
INDEX WHILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 WITH CELL CALCULATION . . . . . . . . . . . . . . . . . . . . . . 94 CUBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 ENCRYPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 GRANT OPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 HOLDLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 MEMBER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 PAGLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 READPAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 ROLLUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 ROWLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 TABLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 [] et ]] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 84 %, , ^ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
111
C
calendrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52, 69 cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 case ` a cocher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 casse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 cellule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57, 63 calcul ee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 champ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52, 62 insaisissable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 obligatoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 chargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75, 82 cl e etrang` ere. . . . . . . . . . . . . . . . . . . . . . . . .17, 35, 80 composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 de substitution . . . . . . . . . . . . . . . . . . . . . . . . . . 69 naturelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69, 79 primaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 35 classication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 99 clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 coh erence faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 grain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 commentaire SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 compl etion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 concat enation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 condition de jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 de s election . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 59 s election . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 consistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 contr ole . . . . . . . . . . . . . . . . . . . . . . . . . 52, 54, 62, 105 contrainte syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 v erication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 coordonn ee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 crochet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 84 fermant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 cryptage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 cubage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57, 64 creux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
A
ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 administration . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 58 ADO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 agr egat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59, 62 agr egation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 premi` eres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 alerte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 20 Analyseur de requ ete . . . . . . . . . . . . . . . . . . . . . . . . 14 anc etre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 apostrophe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 arbre de d ecision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 atomicit e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15, 77 attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 auto-jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20, 72 autorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 axe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84, 87 pluridimensionnel. . . . . . . . . . . . . . . . . . . . . . . .90
B
base model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 d ecisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 de donn ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 personnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 professionelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 de production . . . . . . . . . . . . . . . . . . . . . . . . . 7, 55 tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 boucle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 bouton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 bouton radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 branchement conditionnel . . . . . . . . . . . . . . . . . . . . 12
D
d ebogage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
INDEX d eclencheur AFTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 INSTEAD OF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 d ecoupage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 d ecoupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 d ependance dimensionnelle . . . . . . . . . . . . . . . . . . 67 d epliage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 d erive dimensionnelle . . . . . . . . . . . . . . . . . . . . . . . . 80 d esagr egation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 d etail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53, 62 data mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 surng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 dbo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 51 dice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 d ependance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 d erive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 parent-enfant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 partag ee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 dot NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 doublons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22, 35 drilldown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 drillthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 drillup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 droit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28, 50 DTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 durabilit e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
112 ev enement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37, 54 expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 exploration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58, 75, 77
F
fait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 coh erence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 chier de donn ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ltre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 fonction dagr egat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 59 d enie par lutilisateur . . . . . . . . . . . . . . . . . . 27 math ematiques . . . . . . . . . . . . . . . . . . . . . . . . . . 27 MDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 sur cha nes de caract` eres. . . . . . . . . . . . . . . . .27 sur date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 formattage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 forme dimensionnelle normale . . . . . . . . . . . . . . . . 67 formulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 fr equence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
G
grain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 coh erence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 grappe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 groupage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 groupe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 doptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
H
hi erarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65, 90 acyclique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 parent-enfant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 HOLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 horloge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
E
EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 EIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 elagage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 en-t ete d etat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 de groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 de page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 de sous-formulaire . . . . . . . . . . . . . . . . . . . . . . . 53 enfant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66, 85 entit e pr evue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 entrep ot de donn ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7, 57 sch ema relationnel . . . . . . . . . . . . . . . . . . . . . . . 72 ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 espace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 etat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
I
identicateur unique universel . . . . . . . . . . . . . . . 17 incr emental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 83 indentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 infocentre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 int egrit e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 dentreprise . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 53 de domaine . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 52 des entit es . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 52 r ef erentielle . . . . . . . . . . . . . . . . . . . . . . 36, 53, 80 interface graphique . . . . . . . . . . . . . . . . 9, 10, 51, 58 intitul e . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 53, 62, 84
INDEX isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15, 46
113
O
OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 OLTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 57 op erateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 arihtm etiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 ordonner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60, 90 osql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
J
J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 jeu nomm e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 jointure externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 successives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 journal des transactions . . . . . . . . . . . . . . . . . . 14, 15
L
liste ` choix multiples . . . . . . . . . . . . . . . . . . . . . . . . 53 a d eroulante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 lookup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 75
P
p eriode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 param` etre de sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 par d efaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73, 83 pied d etat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 de groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 de page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 de sous-formulaire . . . . . . . . . . . . . . . . . . . . . . . 53 plage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 planication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 pliage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 potentiom` etre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 pr ediction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 pr evision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 priorit e des op erateurs . . . . . . . . . . . . . . . . . . . . . . . 11 proc edure stock ee . . . . . . . . . . . . . . . . . . . . . . . . 12, 44 sp addlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 sp addrolemember . . . . . . . . . . . . . . . . . . . . . . 49 sp addrole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 sp addsrvrolemember . . . . . . . . . . . . . . . . . . . 49 sp addtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 sp bindefault . . . . . . . . . . . . . . . . . . . . . . . . . . 34 sp bindrule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 sp defaultdb . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 sp droplogin . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 sp droprolemember . . . . . . . . . . . . . . . . . . . . . 49 sp droprole . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 sp dropsrvrolemember . . . . . . . . . . . . . . . . . . 49 sp grantdbaccess . . . . . . . . . . . . . . . . . . . . . . 48 sp grantlogin . . . . . . . . . . . . . . . . . . . . . . . . . . 48 sp revokedbaccess . . . . . . . . . . . . . . . . . . . . . 48 sp unbindefault . . . . . . . . . . . . . . . . . . . . . . . .34 sp unbindrule . . . . . . . . . . . . . . . . . . . . . . . . . . 33 produit cart esien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 propri et e de cellule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 de membre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 propri etaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
M
m ethode des k -moyennes . . . . . . . . . . . . . . . . . . . . . . . . . . 99 des centres mobiles . . . . . . . . . . . . . . . . . . . . . . 99 magasin de donn ees. . . . . . . . . . . . . . . . . . . . . . . . . .57 maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 march e data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 ETL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 OLTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 MDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 membre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66, 85 calcul e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 extremal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 vide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63, 64, 86 dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 mise-` a-jour corr el ee . . . . . . . . . . . . . . . . . . . . . . . . . . 31 mode texte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 MOLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 multicolonne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
N
niladique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 ALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 nom membre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67, 72 num erotation automatique . . . . . . . . . . . . . . . . . . . 17
INDEX
114 surrogate key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69, 80 synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 syntaxe MDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 syst` eme d ecisionnel . . . . . . . . . . . . . . . . . . . . . . . 7, 57, 104 transactionnel . . . . . . . . . . . . . . . . . . . . . 7, 55, 57
Q
quote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 84
R
r eparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 r eseau de d ependances. . . . . . . . . . . . . . . . . . . . . . . . .103 informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 r etro-conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 r ole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 r` egle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 redondance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 requ ete insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 mise-` a-jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 multibase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 multiserveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 s election . . . . . . . . . . . . . . . . . . . . . . . . . 18, 28, 61 strat egie . . . . . . . . . . . . . . . . . . . . . . . 28, 61, 96 suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 requ eteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 ROLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 rollup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
T
table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 63 de comptage des co-occurrences . . . . . . . . 101 de dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 des cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 non pivot ee . . . . . . . . . . . . . . . . . . . . . . . . . . 101 des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 inserted et deleted . . . . . . . . . . . . . . . . . . . . . . . 37 tampon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 temporaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 tableau de bord. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 tableur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 toupie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 tranchage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 tranche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Transact SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 transaction . . . . . . . . . . . . . . . . . . . . . . . 14, 28, 40, 47 transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 75, 77 tri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 tuple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 type d eni par lutilisateur . . . . . . . . . . . . . . . . 12, 33 de variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
S
sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 sch ema en etoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 en ocon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 serveur li e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 SGBD professionnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 SIAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 slice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 snowake scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 sous-formulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 sous-groupe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 sous-requ ete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 correl ee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 SQL-DMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 star scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 starake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 stating area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 structure SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 80
U
union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
V
valeur par d efaut . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 34 variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 verrouillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 vide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 visibilit e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 vue d eclencheur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 int er ets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Z
zone de texte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

ETL Testing

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ETL Testing

Transféré par

Droits d'auteur :

Formats disponibles

SQL Server 2000, Analysis Services et DTS

Cyril Gruau 4 mars 2004

` TABLE DES MATIERES

Table des mati` eres

Le syst` eme transactionnel

Le syst` eme d ecisionnel

Conclusion sur la partie d ecisionnelle Table des gures

Fig. 1 Base de donn ees personnelle

quelques utilisateurs qui analysent les donnes requtes MDX

les managers du service commercial, du service marketing, du service logistique

les vendeurs, les usines, les interlocuteurs auprs des fournisseurs

Premi` ere partie

Le syst` eme transactionnel

Syntaxe du langage SQL

1 SYNTAXE DU LANGAGE SQL Exemple :

1 SYNTAXE DU LANGAGE SQL

sp_addtype CodePostal, CHAR(5)

DECLARE @tva DECIMAL(3,3) SET @tva = 0.186 PRINT @tva

SQL ore les structures usuelles de tout langage. 1.5.1 Blocs

une instruction ou un bloc faculatif une instruction ou un bloc

1 SYNTAXE DU LANGAGE SQL

une instruction ou un bloc

DECLARE @i SET @i = 0 WHILE(@i < @n) BEGIN ... @i = @i + 1 END

Modes dex ecution du code SQL

Ex ecution imm ediate

Ex ecution par lots

3 MISE EN PLACE DUNE BASE

une suite dinstructions

Mise en place dune base

Une base et son journal

ALTER DATABASE papeterie MODIFY NAME cartoleria

DROP DATABASE papeterie

-- cle primaire -- vide interdit -- valeur par defaut

6. NULL repr esente une absence dinformation

-- pour ajouter la colonne adresse

-- pour retirer la colonne adresse

-- pour reconvertir le type de donnees

Pour supprimer une table existante, il sut de taper :

DROP TABLE clients

Num erotation automatique

D enir les relations

4 SELECTIONNER LES DONNEES

S electionner les donn ees

Exemple : si on veut toutes les commandes du client Razibus

-- il faut rappeler la relation

4 SELECTIONNER LES DONNEES

LIKE R zibus LIKE %[M-R] LIKE %[^FMR]% Remarque : on dispose evidemment de

4 SELECTIONNER LES DONNEES

-- condition de jointure -- condition de selection

SELECT a.cmd_num, FROM commandes AS JOIN clients AS b WHERE b.clt_nom =

a.cmd_date a ON a.cmd_clt = b.clt_num Razibus

Union des s elections

4 SELECTIONNER LES DONNEES

7. mais aussi BETWEEN ... AND ...

4 SELECTIONNER LES DONNEES ceci est equivalent ` a

ceci est equivalent ` a

4 SELECTIONNER LES DONNEES 4.5.3 Requ etes correl ees

Requ etes imbriqu ees vs. jointures

4 SELECTIONNER LES DONNEES

Requ etes multibases

SELECT a.cmd_num, b.art_nom FROM GestionCommerciale.dbo.commandes AS a JOIN GestionProductique.dbo.articles AS b ON a.cmd_art = b.art_num

Quelques fonctions SQL

4 SELECTIONNER LES DONNEES Exemple :

() () (*)