Structure de l'entrept de donnes de pilotage

Les objectifs de l'entrept de donnes de pilotage des universits et leurs consquences sur sa structure et sa construction

1- Objectifs de l'entrept de donnes :

Le premier objectif de l'entrept de donnes est de mettre disposition des dcideurs de l'universit des informations synthtiques autour d'indicateurs choisis par eux. En premire approximation, cela consiste mettre disposition les donnes permettant de raliser des tableaux de bord. Ces tableaux de bord ont une double vocation, de constat, suivi d'oprations, et de prvision. Idalement, ils doivent permettre de mettre en vidence les causes de certains faits. Quelles informations contiennent un tableau de bord ? Des indicateurs qui sont des nombres caractriss par des entits prsentes en ligne ou en colonne. Les indicateurs sont gnralement placs au croisement d'une ligne et d'une colonne, reprsentant le croisement de deux entits. Par exemple un tableau de bord pourrait donner par composante (UFR) les catgories de personnel, orientes vers le suivi des enseignants, dcomposes selon les catgories enseignant du second degr, matre de confrence, professeur, non enseignant. Nous aurions alors quatre colonnes correspondant ces catgories, autant de lignes que d'UFR, et un nombre dans chaque case du tableau ainsi form, reprsentant le nombre de personnes de chaque catgorie dans chaque composante. Que signifie mettre disposition : cela doit intgrer clart et rapidit, en tout cas le plus possible. Il faut sortir du vieux schma, qui pour toute nouvelle information demande ncessite une nouvelle tude, et un travail d'laboration du service informatique, schma qui conduit forcment une raction lente. L'ide "d'entreposer" des donnes ne doit pas tre spare de

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 1

l'ide de les rendre visibles leurs utilisateurs potentiels. Bien sr, dans certains cas l'information n'aura pas t entrepose et il y aura alors besoin d'une intervention du service informatique, mais il faut avoir cette exigence de mise disposition l'esprit dans les choix de ralisation. L'objectif plus long terme d'une telle dmarche, est que les utilisateurs de ces donnes, puissent les interroger de faon aussi simple et intuitive que l'on utilise un tableur ou un traitement de textes.

2- Structure mise disposition des utilisateurs (Univers Business Objects) :

21- dfinitions :
Tous les outils d'interrogation ("requteurs", "browsers") servent extraire des donnes d'une base. Ils s'appuient sur le langage SQL (Structured Query Language, langage d'interrogation normalis), qui spontanment liste ou somme, la demande, toutes les valeurs d'une entit existant dans une table. On comprend assez intuitivement qu'ils peuvent facilement gnrer des tableaux en numrant toutes les valeurs de deux entits simultanment. Pour la suite, je ne vais m'intresser qu' un de ces outils d'interrogation, Business Objects, puisque c'est celui qui a t choisi par l'AMUE, et que c'est un bon logiciel dans le domaine, car riche en souplesse et en possibilits. Dans Business Objects (B.O.), on retrouve les deux "objets" dont nous avons besoin : indicateur et dimension. Un indicateur est un nombre, une somme, un minimum, ou un maximum, donc toujours un nombre. Cela correspond bien nos cases de tableau de bord. Une dimension, est l'entit dont le tableau va numrer les valeurs en ligne ou en colonne, elle est la base de l'analyse : par exemple dans le tableau voqu prcdemment, l'analyse se fait selon deux dimensions : la catgorisation de personnel, et la composante (ou UFR). Le terme de dimension convient : on a bien affaire un tableau deux dimensions. Dans Business Objects (B.O.), on peut grouper ces objets, indicateur ou dimension en "classes" ; les classes peuvent elles-mmes se regrouper en classes. On a donc tout loisir de

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 2

faire des regroupements en classes et en sous-classes (tous les outils d'interrogation ne sont pas aussi souples ce niveau, et il faut s'en mfier). Un ensemble de classes bas sur la connexion une base de donne est un "univers", toujours dans la terminologie de B.O. L'laboration de tableaux fonde sur le SQL est intrinsque B.O., comme d'autres outils de ce type. Il suffit de faire glisser deux dimensions et un indicateur de la fentre de dfinition de l'univers (fourni l'utilisateur par le "designer"), vers la fentre de cration d'un rapport (cr par l'utilisateur), pour obtenir un tableau deux dimensions. Une proprit d'une dimension est qu'elle appartient souvent une hirarchie. C'est un point trs important, car ces hirarchies ordonnent les dimensions et permettent de changer de niveau d'analyse. Par exemple, dans les inscriptions administratives des tudiants, il existe une hirarchie qui vient de l'organisation administrative de la scolarit : composante (UFR), cycle, diplme, tape du diplme : ces quatre dimensions appartiennent la mme hirarchie. Si on fait un tableau qui donne le nombre d'inscriptions par composante (UFR) et par anne universitaire, on aura un tableau deux dimensions (composante et temps). Changer de niveau d'analyse consistera passer un tableau par cycle et par anne, voire par diplme et par anne, puis remonter au niveau cycle ou composante, etc Quel intrt ? ventuellement de mettre en vidence la cause de certains faits, voque dans les objectifs : en effet, si un nombre parat aberrant, ou au moins surprenant, pour une composante, il sera intressant de voir si cela vient d'un cycle en particulier, et si oui, peut-tre d'un diplme en particulier. C'est ce que recouvre le terme "analyse dimensionnelle". Il va de soit qu'elle n'est possible que si les dimensions de l'univers mis disposition sont hirarchises, et nous verrons que cela a des consquences sur la construction des tables de l'entrept de donnes. C'est donc un point trs important.

22- Consquences des objectifs sur les univers Business Objects :

221- Structure de l'univers : La structure de l'univers doit tre claire et logique : le regroupement en classes des objets doit tre fait selon la logique des utilisateurs et le bon sens, et non pas dans la logique de la structure des tables sous-jacentes. Il y a l un premier travail du "designer" d'univers B.O. qui ne doit pas se contenter de la cration d'univers par l'assistant automatique.

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 3

Chaque donne ne doit pouvoir tre atteinte que d'une faon dans l'univers : avoir les mmes informations accessibles par deux chemins ne peut qu'embrouiller le schma et l'alourdir. De plus, comme toute redondance, cela augmente les risques d'erreurs au dpart et surtout dans les volutions ultrieures. L'utilisation des donnes doit tre scurise : autant il faut profiter de la puissance de SQL, autant il faut se mfier de ses effets de bords ; quand on utilise beaucoup de tables lies par des jointures, certaines de ces jointures peuvent multiplier les rsultats par le nombre de lignes d'une de ces tables. C'est de la responsabilit du "designer" Business Object de parer tous ces effets de bord possibles. Dans un univers correctement construit, toute utilisation de deux objets incompatibles doit tre interdite ; il y a plusieurs moyens techniques de s'affranchir de ces inconvnients, il faut toujours choisir le plus simple rendant le service attendu. Toutes les dimensions qui le peuvent doivent tre dfinies dans des hirarchies. 222- Objets de l'univers : Toujours dans le double but de mettre disposition les donnes, et de faire long terme de B.O. un outil aussi utilis qu'un tableur, les objets de l'univers doivent tre dcrits avec le plus grand soin. Les noms des objets (et des classes) doivent tre pris dans le langage des dcideurs, et dans le langage courant, en fuyant autant que possible le jargon de chaque domaine applicatif qui n'a pas de ncessit absolue. Par exemple une composante (UFR) ne doit pas s'appeler "structure de niveau 2", et encore moins "niveau 2". Les noms des objets doivent tre normaliss, tous les codes nots d'une certaine faon, tous les libells d'une autre ; on aura par exemple "Nationalit - Code" pour le code de la nationalit, "Nationalit - Lib" pour son libell ; en cas de libells court et long, on utilisera Libc et Lib, les nombres ne seront pas suffixs, mais commenceront aussi par une majuscule, etc Chaque dimension doit avoir une liste de valeurs associe : une liste de valeurs permet, par une liste droulante, de choisir une valeur par le libell associ un code. Elle est l'arme d'un choix clair d'une condition : grce une liste de valeurs, un utilisateur peut choisir une catgorie comme "les enseignants du second degr" sans connatre la codification correspondante. C'est la liste de valeur qui fera l'association entre le code et le libell choisi.

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 4

3- Structure gnrale de la base de l'entrept de donnes :

Toutes les caractristiques des tables d'un entrept de donnes sont lies ce que l'on veut en faire : produire des indicateurs au carrefour de dimensions.

31- Table de "fait" :

Une table de base de l'entrept va comprendre au moins un indicateur lmentaire et des dimensions. Cet indicateur lmentaire peut tre un nombre entier compris entre 0 et 1, permettant de compter un lment, ou un nombre entier ou dcimal reprsentant une quantit. Par exemple, dans les inscriptions administratives des tudiants, un indicateur d'inscription administrative sera 1 pour une composante (UFR), un cycle, un diplme, une tape, et un code tudiant si et seulement si l'tudiant qui a ce code est inscrit cette tape de ce diplme, de ce cycle, de cette composante. Si c'est la composante 924, le cycle 3, le diplme 580, l'tape 2, l'tudiant 19930003 la table contiendra 924,3,580,2,19930003,1. Pour prendre un autre exemple, dans les postes affects, la quotit de travail sera 0,6 pour une composante, une structure d'affectation, une occupation, un numro d'affectation correspondant un contrat de travail ou un lment de carrire, et un code personnel, si et seulement si la personne qui a ce code travaille 60% pour ce numro d'affectation, ce poste, cette structure d'affectation, cette composante. Une table de ce type est appele "table de fait". Un "fait" est reprsent par la valeur d'un indicateur lmentaire associ une srie de dimensions : il est numris pour pouvoir tre utilis. Il est la base de l'indicateur de tableau de bord que nous visons, qui sera une somme, une moyenne, un maximum ou un minimum des indicateurs lmentaires. Dans notre exemple prcdent, le "fait" est l'inscription administrative une composante (UFR), un cycle, un diplme, une tape. Ces entits, qui caractrisent le fait, sont des "dimensions".

32- Table de "dimension" :

Une table de dimension contient pour chaque dimension, au moins un libell. Par exemple la table des composantes (ou UFR), contiendra, pour chaque code, le libell associ : 901,Services Gnraux ; 924,UFR de Mathmatiques, etc

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 5

C'est ainsi que l'on obtient un modle en "toile" typique des entrepts de donnes, avec une table de fait au centre, et les tables de dimensions lies chaque dimension de la table de fait.

4- Construction et mise disposition de l'entrept de donnes :

Le couple indicateur-dimension est le pivot central de la construction de l'entrept. Il traverse tout le processus depuis le document recherch par l'utilisateur-dcideur jusqu' la structure de la base, en passant par l'univers Business Objects. C'est le point essentiel. Si nous n'en tenons pas compte, nous restons dans le vocabulaire des entrepts de donnes mais pas dans leur ralit. Une fois dtermins les indicateurs recherchs, et les dimensions qui les caractrisent, ainsi que leurs hirarchies, et donc le schma des tables de la base, il reste dfinir la dimension historique de leur alimentation et rpartir les travaux ncessaires la construction de l'entrept et sa mise disposition entre les outils dont nous disposons, et entre les diffrents intervenants.

41- Dimensions historiques :

L'entrept de donnes est par essence destin durer, toutes les tables de fait doivent donc avoir une dimension historique. Les faits eux-mmes sont historiques : un tudiant s'inscrit pour une anne universitaire, quand on parle d'un budget, on s'intresse un exercice comptable. Il y a donc une dimension historique incluse dans les faits (anne, trimestre, date, selon les faits mesurs). D'autre part l'entrept se prsente comme une succession de photographies des faits, prises diffrents moments. Il faut donc inclure dans chaque table, la date de "prise de vue", et on en tiendra compte pour toute interrogation. Il y a donc deux dimensions historiques : une inhrente aux faits eux-mmes, l'autre provenant du processus d'alimentation de la base de l'entrept.

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 6

42- Rpartition des tches entre les outils :

Un premier travail consiste extraire des donnes des bases des diffrents domaines d'activit (personnel, scolarit, financier, ), pour alimenter la base de l'entrept de donnes. L'outil pour ce travail est un "ETL", langage d'extractions de donnes. Certaines donnes sont transfres d'une base l'autre, sans transformation, et ne posent pas de problme. D'autres, par contre, sont labores par des rgles partir des donnes prexistantes. Il est important que tout le travail de transformation ne soit fait qu'une fois, et au niveau du travail d'alimentation, et ne soit pas dport au niveau de l'univers Business Objects. D'autant que les donnes sont historises et archives : il est important que cet archivage inclue leur dfinition. Le schma gnral de construction et de mise disposition de l'entrept est donc : 1- Dfinition des faits mesurer : quels sont les indicateurs et les dimensions. 2- Cration des tables ncessaires en respectant indicateurs et dimensions, en hirarchisant les dimensions : l'outil ici est le langage de dfinition de la base de donnes (Data Definition Language de SQL), qui peut tre gnr par un outil de modlisation comme Power AMC, avec l'avantage de pouvoir alors documenter chaque colonne (d'y noter sa rgle d'obtention, si complexe soit-elle). 3- Extraction de donnes des bases de gestion, hirarchisation de ces donnes, combinaison ventuelle de ces donnes par des rgles prcises : l'outil peut tre SQL, mais un outil d'extraction de donnes (ETL) est prfrable pour la rapidit de mise en uvre, la maintenance et l'volution des scripts. Data Stage d'Informix, et Genio de Hummingbird sont des produits ce type. 4- Cration d'un environnement d'exploration (univers Business Objects) : rangement des donnes selon la logique des utilisateurs et le bon sens, scurisation (viter les effets de bords du SQL), utilisation des hirarchies, codifications des noms des objets et classes, mise en place de listes de valeurs pour toutes les dimensions : l'outil est ici Business Objects Designer. 5- Cration de rapports priodiques prdfinis : l'outil est ici Business Objects (user). 6- Exploration des donnes, cration de rapports la demande : l'outil est ici Business Objects (user).

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 7

43- Rpartition des tches entre les diffrents acteurs :

Le premier point (dfinition des faits mesurer) est la charge des utilisateurs-dcideurs : ce sont eux qui dfinissent de quels tableaux de bord ils ont besoin. Le deuxime point (structure de la base) est la charge des informaticiens. Le troisime point (alimentation de la base) est la charge des informaticiens, mais le choix des donnes et la dfinition des rgles d'laboration des donnes complexes se fait en troite collaboration avec les utilisateurs des bases de gestion. Le quatrime point (dfinition de l'univers B.O.) est la charge des informaticiens. Quoiqu'on puisse en dire, et mme chez B.O., toute autre approche me parat dmagogique, car, comme nous l'avons vu prcdemment, le travail de "designer B.O." demande une bonne connaissance de l'informatique. Le cinquime point (cration de rapports prdfinis) peut tre la charge des informaticiens, si les tableaux ont fait partie du "cahier des charges", mais ils peuvent aussi tre faits par des utilisateurs expriments. Le sixime point (exploration, ..) est bien sr loutil des utilisateurs.

5- Comment construire l'entrept de donnes :

Ce chapitre reprend et dveloppe ce qui a t abord au chapitre 3 "Structure gnrale de l'entrept de donnes". Son objet est de rpondre la question "comment faire ?", "comment sparer et organiser les donnes de l'entrept ?". Ncessairement plus technique, ce chapitre est donc destin principalement aux informaticiens. Les paragraphes 51 et 52 sont les complments respectifs des paragraphes 31 et 32.

51- Conditions de cration d'une table de fait :

Le mme "fait" apparent, comme l'inscription d'un tudiant, peut tre li des dimensions sans rapport entre elles : l'inscription d'un tudiant un lment pdagogique, un module d'enseignement, est une consquence de son inscription administrative une tape d'un diplme. Mais la rciproque est fausse : un mme lment pdagogique peut tre suivi dans le cadre de diplmes diffrents. Si l'on utilise une seule table de fait pour reprsenter les

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 8

inscriptions pdagogiques et administratives, le domaine de dfinition d'un indicateur pose problme : en effet, si notre table de fait inclus tous les lments pdagogiques suivis par un tudiant, l'indicateur d'inscription administrative ne devra tre mis 1 qu'une fois par tape de diplme, donc pour un seul lment pdagogique. Nous avons alors tout intrt avoir deux tables de fait. En gnralisant, si des dimensions sont dans des hirarchies diffrentes, on a intrt faire des tables de fait spares. Un fait peut donc tre reprsent comme un indicateur lmentaire associ une hirarchie de dimensions. Cela n'empche pas que d'autres dimensions hirarchises complmentaires soient lies ce fait. C'est le cas de dimensions compltement indpendantes du fait lui-mme : par exemple la nationalit de l'tudiant peut dsigner un pays qui appartient une communaut (Europe ou non), c'est une dimension hirarchise, cela ne change rien son inscription administrative ou pdagogique. Par contre, nous l'avons vu, une dimension lie au mme fait mais n'appartenant pas une mme hirarchie pose problme. Nous disposons donc maintenant d'un critre de dcision pour crer une table de fait : nous crerons une table de fait pour chaque hirarchie de dimension intrinsque au domaine mesur (lie un indicateur au moins).

52-Structure des tables de dimension :

Si une dimension est hirarchise, sa table contiendra non seulement un libell, mais en plus un renvoi vers la dimension de niveau suprieur. Par exemple la nationalit de code 100, aura pour libell "France", et un code de communaut "UE", code de l'Union Europenne dans la table des communauts, dimension de niveau suprieur. On obtient alors un schma "en flocon". Dans la pratique, pour viter de multiplier les jointures, pour des raisons de performance, on se ramne souvent au schma en toile en "dnormalisant" les tables de dimension hirarchises (le terme vient de la ngation de la forme "normale" du modle relationnel). Il y a des informations rptes dans plusieurs lignes, la place d'une table distincte. Dans notre exemple, on aura une table de dimension unique contenant la hirarchie. En face du code nationalit 100, on aura le libell "France", le code communaut "UE", et le libell "Union Europenne" ; ce code "UE" et son libell seront rpts pour tous les pays de l'union europenne, et tous les autres pays auront un autre code, par exemple "ET", avec comme libell "Etranger".

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 9

53- Bien sparer indicateur et dimension :

Il faut prendre garde ne pas faire glisser une dimension en un fait, ne pas multiplier des indicateurs qui suivent les valeurs d'une dimension, car on se prive alors de la puissance du langage SQL. Par exemple, si je cre un indicateur "europen" et un indicateur "tranger" dans la table des inscriptions administratives, tout nouveau pays europen m'oblige revoir l'alimentation de ma table, alors que si je passe par la nationalit et la dimension communaut, je n'ai qu'une ligne de la table des nationalits modifier. Je peux aussi m'adapter tout regroupement de pays diffrent, par simple action sur cette table. De la mme manire, dans les postes affects, si je cre des indicateurs "enseignant du second degr", "professeur", au lieu d'utiliser un tmoin valeur multiple ct de l'indicateur quotit de travail, le jour o il faut tenir compte d'une nouvelle catgorie d'enseignant, je suis bloqu, alors que dans l'autre cas, je n'ai qu'une ligne ajouter dans la table des catgories d'enseignants. En rsum, il faut bien un indicateur au moins qui mesure le fait tudi (inscription administrative, ou quotit de travail, par exemple), mais il ne faut pas projeter une dimension dans la table de fait sous formes d'indicateurs qui ne mesurent plus alors le fait brut, mais la combinaison de ce fait avec une de ses dimensions.

54- Indicateurs dfinis dans Business Objects :

Certains indicateurs lmentaires peuvent ne pas exister dans la table de fait et tre dfinis dans l'univers Business Objects. Ce n'est possible que s'ils peuvent s'obtenir par un ordre SQL simple, utilisant une "fonction de regroupement" sans clause restrictive ("where") : s'ils sont obtenus par un "select count()", "select count (distinct )", "select sum()", ... Ainsi, si l'on s'intresse au nombre d'tudiants physiques, dans le domaine des inscriptions administratives des tudiants, on pourra dfinir un indicateur dans B.O. comme un "count distinct" des numros d'tudiants, qui permet de ne compter que les numros d'tudiants distincts, donc de ne compter qu'une fois un tudiant qui a plusieurs inscriptions administratives. Par contre tout indicateur qui s'obtiendrait par une clause restrictive est proscrire ; en effet, il n'est pas combinable dans des calculs (de type ratio par exemple), avec d'autres indicateurs issus de la mme table car la clause restrictive joue sur les deux nombres et fausse le rsultat.

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 10

55- Et les agrgats ?

Les tables d'agrgats sont des tables dans lesquelles une partie des additions, moyennes, maxima ou minima est calcule par avance. Il ne s'agit que d'une optimisation ventuelle de performance au cas o une table de fait contiendrait normment de lignes. On va alors "regrouper" des lignes, par des ordres SQL simples, bass sur les fonctions somme, moyenne, maximum, minimum, ... Avec la fonction "aggregate aware" de Business Objects, ces agrgats peuvent et doivent rester invisibles l'utilisateur. Selon les objets demands dans un rapport, B.O. va effectuer sa requte la base de donnes en utilisant la table de fait, ou un agrgat dclar par "aggregate aware" de faon extraire de la base le moins de lignes possibles. Cela ncessite simplement que les agrgats sur une table de fait soient crs en respectant la hirarchie de la table de fait.

6- Conclusion :
J'espre que cet expos permettra de clarifier et de concrtiser la notion d'entrept de donne des universits, et aidera comprendre ce qui est amorc et le dvelopper. J'ai essay en mme temps de prendre des exemples du monde universitaire, et de gnraliser, essay d'en extraire une mthode pour rpondre la question : "comment faire, comment choisir les tables de l'entrept ?". J'ai essay de montrer comment le couple indicateur-dimension est la base de tout l'difice, ce qui n'est d'ailleurs pas une nouveaut. Mais, comme toujours, la thorie sert surtout ceux qui l'laborent, car elle leur permet de clarifier leur pratique, et il est bien difficile de faire siennes les ides des autres quand on n'a pas leur pratique. Ce n'est que la confrontation pratique notre propre exprience (locale Paris 6), puis la confrontation avec l'exprience de l'quipe de Grenoble dans le cadre du projet de l'AMUE, qui m'a permis de, et parfois oblig , clarifier certaines notions intuitives ou empruntes des ouvrages en la matire. Par contre, en retour, la clarification permet de faire consciemment certains choix concrets, et c'est en cela qu'elle est utile. Pour ce qui est du processus en cours, je suis bien conscient, que mme si je me suis trouv dans la situation qui m'a permis d'effectuer cette clarification, la source en est cette exprience dans laquelle nous sommes nombreux tre engags collectivement. Je suis bien conscient aussi, que dans tout ce que j'affirme ici, la pratique ultrieure montrera probablement des

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 11

erreurs. La pratique se dveloppant, il est souhaiter que d'autres pages "thoriques" soient crites, en cho la solution de problmes probablement de plus en plus complexes.

Paris, le 9 Avril 2001,

Jean-Baptiste Nataf

Structure de l'entrept de donnes de pilotage

Jean-Baptiste Nataf - Avril 2001 - page 12