Apple remporte une manche face à Samsung

C'est donc la deuxième fois qu'une décision de justice donne raison à Apple. Mardi dernier la justice américaine avait interdit la vente de la nouvelle tablette de Samsung estimant avoir « la preuve que Samsung a modifié la conception de son produit pour qu'il ressemble à celui d'Apple ». La juge Lucy Koh du tribunal du District nord de Californie a garanti une interdiction des ventes jusqu'à résolution du conflit sur les brevets entre les deux firmes informatiques.

 

Cette bataille juridique repose sur un logiciel d'exploitation de données sur Siri. Il s'agit d'une application d'assistant personnel qui repose sur le langage oral et qu'Apple a intégré dans son dernier iPhone. « Apple a montré que l'élément breveté était au cœur de la fonctionnalité Siri » a déclaré la juge dans sa décision. Par ailleurs Apple doit déposer une caution de 95,6 millions de dollars pour dédommager Samsung au cas où ce dernier soit déclaré innocent.

Depuis plusieurs mois Apple et Samsung se livrent une bataille sans merci dans de nombreux pays à travers le monde. Apple reproche au géant coréen de copier les iPhone et iPad tandis que Samsung reproche à l'entreprise de Steve Jobs de porter atteinte au droit de la propriété intellectuelle. La semaine dernière la justice hollandaise a condamné Apple à verser des dommages et intérêts à Samsung pour une violation de brevet.

La tablette Google Nexus 7 en images

Qu'est-ce que la modélisation multidimensionnelle ?

Une réponse à un besoin analytique
Les bases de données relationnelles modélisées selon les principes classiques de normalisation s’adaptent très mal à un contexte analytique (OLAP). En analyse, l’utilisateur doit disposer d’un modèle relativement intuitif et capable de stocker le résultat de nombreux calculs d’agrégation (ce qui, d’un strict point de vue relationnel, constitue une redondance), tandis que les problématiques classiques de contrôle de saisie et de cohérence sont inexistantes (on suppose que les données de base sont déjà saisies dans une BDD relationnelle cohérente) ou déplacées (on ne saisit plus des données mais des paramètres de calcul ou de simulation – voir plus bas).
Dimensions et indicateurs
La modélisation multidimensionnelle (formalisée notamment par Edgar F. Codd dans un article commandité par Arbor Software) propose donc d’analyser des indicateurs numériques (par exemple chiffre d’affaires, nombre d’individus, ratios, etc.) dans un contexte précisé par le croisement de plusieurs dimensions d’analyse (par exemple temps, géographie, organisation, produits, etc.), généralement présentées sous forme d’arbres hiérarchiques.
Par exemple, considérons les trois dimensions Temps, Marchés et Produits utilisées pour analyser les ventes d’un producteur de boissons :

[Suite:]

L’indicateur Chiffre d’Affaires sera calculable sur l’ensemble des combinaisons possibles entre ces trois axes. Si maintenant on présente chaque arbre à plat, sous forme d'un axe comprenant à la fois les positions de détail et les positions agrégées (en gras sur les schémas ci-dessous), l'ensemble des combinaisons possibles peut être représenté par un cube :
Au-delà de trois dimensions, cela devient mathématiquement un hypercube (qu’il est évidemment beaucoup plus difficile de représenter graphiquement). Une base de données multidimensionnelle typique peut donc s’envisager comme un hypercube d'une petite dizaine de dimensions comprenant plusieurs millions de cellules (on parle plus couramment de cube OLAP).
Représentation pour l’utilisateur
Classiquement, les requêtes formulées par les utilisateurs s’expriment et se représentent sous forme de tableaux croisés :

Cette représentation en tableau croisé (qui se traduit ensuite facilement en divers graphiques) présente de nombreux avantages pour l’utilisateur :

• elle est directement compréhensible
• elle est facilement manipulable par un analyste qui souhaite changer son point de vue sur les données (zoom, pivot, etc.)
• elle peut être directement comprise par un outil OLAP, libérant ainsi l’utilisateur non-informaticien du besoin d’apprendre un langage d’interrogation (SQL, MDX)

Implémentations : MOLAP, ROLAP, HOLAP

Une première façon d’implémenter un hypercube consiste à utiliser une base relationnelle dénormalisée (schémas en étoile ou en flocon), intégrant éventuellement certaines tables d’agrégats pré-calculés, sur laquelle on génère à la volée les requêtes SQL correspondant aux interrogations des utilisateurs. Ce système est désigné par l'oxymore de Relational OLAP, ou ROLAP. Il s’agit là essentiellement d’un mode de présentation : les utilisateurs voient un cube OLAP, tandis que les données sont en fait dans une base relationnelle.
A l’inverse, les SGBD MOLAP vont stocker les données sous une forme matricielle, véritablement multidimensionnelle. Le pléonasme « MOLAP » (multidimensional OLAP) entend souligner qu’au contraire du ROLAP, il ne s’agit pas d’un simple mode de présentation mais d’une technique nouvelle par rapport aux bases de données relationnelles (faisant donc appel à de nouvelles compétences), spécifiquement dédiée à l’analyse. De manière générale, les bases MOLAP permettent de stocker beaucoup plus de pré-calculs ; elles sont donc généralement plus volumineuses et plus longues à pré-calculer, ce qui permet d'offrir un temps de réponse quasi-immédiat à l’utilisateur.
Le plus souvent, les avantages du MOLAP s’estompent au fur et à mesure que l’on descend vers des niveaux plus détaillés ; un bon compromis est donc d’utiliser un mode hybride (dit HOLAP), MOLAP aux niveaux agrégés, ROLAP aux niveaux les plus fins.
La simulation
Parmi les différents aspects de l’analyse, la simulation est particulière parce qu’elle suppose de saisir un certain nombre de paramètres de calcul… toute la question est donc de savoir combien, autrement dit, quelle est la complexité du modèle de simulation.
Supposons que je veuille estimer mon chiffre d’affaires de l’année prochaine ; voici deux manières de m’y prendre :

• j’imagine que globalement, ma croissance va être entre 0% (hypothèse basse) et +5% (hypothèse haute) ;
• pour analyser les choses plus finement, je demande à chacun de mes 200 chefs de produits un taux de croissance pessimiste et un optimiste ; je fais ensuite ajuster ces taux globaux par mes 10 responsables régionaux…

Dans la première hypothèse, le résultat est alors très facile à calculer et ne nécessite pas de technique particulière. Néanmoins, cette simulation est assez grossière.
Penchons-nous plus en détails sur la seconde hypothèse : si l’on suppose que je vends en moyenne la moitié de mes produits dans chaque région, cela fait donc 1 000 taux optimistes et 1 000 pessimistes à enregistrer ! Il me faudra ensuite calculer la projection pour chaque croisement produit/région, et agréger le tout.
Disposer d’une technologie ad hoc n’est pas du luxe dans ce genre de situation : en relationnel (ROLAP compris), il me faudra développer une interface de saisie spécifique, les requêtes de calcul et les tables destinées à accueillir les résultats. A l’inverse, une base MOLAP permettra de saisir les paramètres à travers l’interface de reporting, de rédiger les calculs en quelques lignes, et de me contenter d’ajouter quelques branches spécifiques aux dimensions de mon cube.
Plus largement, on parle de technique de simulation dès qu’il y a nécessité de saisir des paramètres de calculs autrement qu’à la volée, ce qui s’applique à de nombreux cas qui sortent de ce qu'on appelle simulation en langage courant : conversion de devises, élaboration budgétaire, etc.

Google Docs fait son apparition en mode hors ligne

Google Docs se dote (enfin) d’un mode offline. Les utilisateurs de la suite bureautique en ligne de la firme de Mountain View vont désormais pouvoir créer, éditer et commenter des documents hors connexion, a annoncé Google lors de sa conférence Google I/O.
Petit bémol : cette nouvelle fonctionnalité n’est pour le moment valable que pour les documents de traitement de texte. Le tableur et les présentations ne sont pas encore concernés par ce mode offline.
Ce mode hors ligne avait déjà fait une petite apparition, mais ne permettait jusqu’alors que la consultation de ses fichiers.
Les changements effectués offline sur les documents de Google Docs seront automatiquement synchroniser sur la version en ligne lors de la connexion avec le service.
Le passage au mode hors ligne pourrait ainsi avoir un certain impact : populariser l’utilisation de Google Docs dans les entreprises, à l’instar de son concurrent, la suite bureautique dans le cloud Office 365 de Microsoft, qui vient de fêter son premier anniversaire.

Larry Ellison, PDG d’Oracle, s’offre une île à Hawaï

Sixième du palmarès Forbes des hommes les plus riches du monde, Larry Ellison, PDG et fondateur d’Oracle, s’est offert un cadeau : une des îles d’Hawaï.
C’est pour l’île de Lanai, ou en tout cas pour 98% de sa surface, que Larry Ellison a craqué, et où il possède déjà une maison. Superficie totale, plus de 200 km2.
Cette acquisition de luxe est confirmée par le gouvernement d’Hawaï, qui se réjouit ainsi d’accueillir prochainement le milliardaire, dont la fortune est estimée à 36 milliards de dollars.
L’achat s’est effectué auprès d’un autre milliardaire, David Murdock, qui possédait 98% de l’île depuis 1985. Les 2% restants sont détenus par l’Etat d’Hawaï. Quant au prix de ce bien, il est estimé par le Maui News entre 500 et 600 millions de dollars.
Pour l’acquisition de l’île de Lanai, Larry Ellison aurait été en concurrence avec une autre des plus importantes fortunes au monde, à savoir Bill Gates, et son épouse Melinda Gates. Ces derniers avaient loué l’île pour leur mariage en 1994.

Le père de l’iPad quitte Apple

Apple perd un de ses piliers. Bob Mansfield, qui occupe actuellement le poste de vice-président pour le Mac et l’ingénierie matérielle, part à la retraite après 13 ans passés à travailler pour la pomme. Il était entré dans la société de Steve Jobs en 1999 lors du rachat de Raycer Graphics par Apple.
Dès 2005 il prendra la vice-présidence du développement des Mac, puis celle des iPod et iPhone en 2010. Mais on doit surtout à Mansfield la conception de l’iPad qu’il a dirigé depuis les premiers jours.
A la presse, Tim Cook a déclaré : « Bob a joué un rôle décisif dans notre équipe de direction, supervisant l'ingénierie matérielle et l'équipe qui a sorti des dizaines de produits novateurs au fil des années. Nous sommes très tristes de devoir le quitter et nous espérons qu'il profitera de chaque jour de sa retraite ».
Remplacement
Certains, comme nos confrères de chez macgeneration.com voient dans ce départ une suite, sinon une conséquence, au décès de  Steve Jobs en octobre 2011. En effet, dès novembre, Mansfield avait revendu une grande partie de son portefeuille d’action.
Enfin, précisons que Bob Mansfield ne laisse pas son poste vacant. La relève est déjà assurée par Dan Riccio. Depuis plusieurs mois déjà, une période de transition avait été entamée durant laquelle Riccio assurait le poste de vice président chargé du développement de l’iPad. La transition devrait encore duré quelques mois avant le départ à la retraite effectif de Mansfield.

Conception d'un Data Warehouse

I. Introduction

Nous avons vu dans mes articles précédents ce qu'était le BI, ce que comprenait un environnement décisionnel et qu'il avait comme concept central l'entrepôt de données ou le Data Warehouse.
Intéressons nous maintenant à comment concevoir un entrepôt de données.

• Quelle structure permet-elle d'avoir les fonctionnalités requises pour un entrepôt de données ?
• Quelles sont les techniques utilisées pour bien concevoir ?
• Quels sont les indicateurs d'une bonne conception ?

Ce mini cours commencera par introduire (ou réintroduire) les concepts fondamentaux de l'informatique décisionnelle (nécessaires pour la compréhension de cet article), continuera par l'explication des méthodes de conception d'entrepôt de données via une étude de cas, et terminera par une critique de ces techniques et une conclusion mentionnant les indicateurs d'une bonne conception d'entrepôt.

II. Concepts fondamentaux

II-A. Entrepôt de données (Data Warehouse)

J'estime en avoir assez parlé ici et ici : mais un peu de répétition ne fait pas de mal !!!
Un entrepôt de données, ou data Warehouse, est une vision centralisée et universelle de toutes les informations de l'entreprise. C'est une structure (comme une base de données) qui à pour but, contrairement aux bases de données, de regrouper les données de l'entreprise pour des fins analytiques et pour aider à la décision stratégique. La décision stratégique étant une action entreprise par les décideurs de l'entreprise et qui vise à améliorer, quantitativement ou qualitativement, la performance de l'entreprise. En gros, c'est un gigantesque tas d'informations épurées, organisées, historisées et provenant de plusieurs sources de données, servant aux analyses et à l'aide à la décision. L'entrepôt de données est l'élément central de l'informatique décisionnelle à l'heure où j'écris ce tutorial. En effet, l'entrepôt de données est le meilleur moyen que les professionnels ont trouvé pour modéliser de l'information pour des fins d'analyse, et il ne serait pas étonnant que d'ici quelques années un nouveau concept apparaisse pour révolutionner l'informatique décisionnelle… Mais intéressons nous à ce qui existe pour l'instant…

II-B. Data Mart, ou magasin de données

Les Data Warehouses étant, en général, très volumineux et très complexes à concevoir, on a décidé de les diviser en bouchées plus faciles à créer et entretenir. Ce sont les Data Marts. On peut faire des divisions par fonction (un data mart pour les ventes, pour les commandes, pour les ressources humaines) ou par sous-ensemble organisationnel (un data mart par succursale). Nous verrons plus tard comment organiser les data marts pour créer un entrepôt proprement dit.

II-C. Dimension

Lorsqu'on fait un schéma de BD pour un système d'information classique, on parle en termes de tables et de relations, une table étant une représentation d'une entité et une relation une technique pour lier ces entités. Et bien en BI, on parle en termes de Dimension et de Faits. C'est une autre approche des données, on entend par dimensions les axes avec lesquels on veut faire l'analyse. Il peut y avoir une dimension client, une dimension produit, une dimension géographie (pour faire des analyses par secteur géographique), etc.

Une dimension est tout ce qu'on utilisera pour faire nos analyses.

II-D. Fait

Les faits, en complément aux dimensions, sont ce sur quoi va porter l'analyse. Ce sont des tables qui contiennent des informations opérationnelles et qui relatent la vie de l'entreprise. On aura des tables de faits pour les ventes (chiffre d'affaire net, quantités et montants commandés, quantités facturées, quantités retournées, volumes des ventes, etc.) par exemple ou sur les stocks (nombre d'exemplaires d'un produit en stock, niveau de remplissage du stock, taux de roulement d'une zone, etc.), ou peut être sur les ressources humaines (performances des employés, nombre de demandes de congés, nombre de démissions, taux de roulement des employés, etc.).

Un fait est tout ce qu'on voudra analyser.

II-E. ETL, ou ETC pour les francophiles

L'ETL, dont j'ai expliqué les fondements dans cet article, sert à transposer le modèle entité-relation des bases de données de production ainsi que les autres modèles utilisés dans les opérations de l'entreprise, en modèle à base de dimensions et de faits (nous verrons ces modèles dans les deux prochaines définitions).

II-F. Étoile

Une étoile est une façon de mettre en relation les dimensions et les faits dans un entrepôt de données. Nous le verrons plus tard, mais le principe est que les dimensions sont directement reliées à un fait (schématiquement, ça fait comme une étoile).

II-G. Flocon

Un autre modèle de mise en relation des dimensions et des faits dans un entrepôt de données. Le principe étant qu'il peut exister des hiérarchies de dimensions et qu'elles sont reliées au faits, ça fait comme un flocon :)

Note : les flocons et les étoiles peuvent être vus comme une manière de diviser les entrepôts de données et les magasins de données. On peut les voir comme l'atome de l'informatique décisionnelle : le plus petit élément avec lequel ont peut faire des analyses et avec lequel ont peut faire des magasins de données qui, mis ensemble, forment un entrepôt de données.

III. Modélisation en étoile, un cas

Nous allons utiliser un exemple pour expliquer la modélisation en étoile. L'important en BI est de toujours garder à l'esprit que ce que nous faisons est différent des bases de données traditionnelles. Le schéma créé sera accessible par les utilisateurs et doit donc être le plus simple et explicite possible !

III-A. Le cas

On vous demande de créer un data Mart (une étoile) pour l'analyse de l'activité des représentants d'une entreprise de vente d'imprimantes. Le chef d'entreprise veut savoir ce qui se passe pour ses vendeurs. Les employés font ils leur travail, quelle est la zone de couverture des vendeurs, ou sont les endroits où les vendeurs sont le moins efficaces, quelle est la moyenne de ventes des représentants, etc., etc. L'entreprise possède un système de gestion de ressources humaines, un système de gestion des ventes et des feuilles de routes avec des informations concernant les vendeurs : kilomètres parcourus, litres d'essence utilisée, frais de voyage, ventes, promesses de ventes, etc.

III-B. L'analyse

Note : cette méthode m'a été apprise à l'université Sherbrooke par Monsieur R. Laurin.

Notre objectif est d'analyser l'activité des représentants. Il semble que nous ayons toutes les informations pour ce faire... Mais dans différents systèmes.

Commençons l'analyse :

Le but du jeu est de déceler les axes d'analyses (les dimensions) avec leurs attributs ainsi que les éléments à analyser (les faits). La meilleur façon de ce faire, selon moi, est l'étude approfondie de ce qui se passe dans l'entreprise : documents échangés, rapports périodiques, interviews des personnes clés, étude des besoins. Il faut vraiment faire un travail d'acteur, et rentrer dans la peau de chaque utilisateur, savoir comment les analystes organisent leurs raisonnements, savoir ce que voient les décideurs avant de décider, connaître les indicateurs de bonne santé de l'entreprise et de la concurrence. Un vrai travail de fourmi et des heures de plaisir :)

Les techniques d'acquisition d'information et d'analyse des besoins étant un sujet à eux seuls, je passerais la main pour ce point … Nous supposeront que tout a été fait selon les règles de l'art et nous nous contenterons de compiler :)

Une manière très pratique de modéliser un cas en BI se fait comme suit :

	Date	Vendeur	Produit	Zone géographique	Client
	Années	Nom	Catégorie	Pays	Nom
	Mois	Prénom	Type	Province	Adresse
	Jours	Salaire	Groupe	Ville	Pays
	Heures
Analyse : consommation d'essence, Qte commandée, Qte précommandée, kilométrage, nombre de visites, etc.

Explications : le tableau suivant a été rempli pendant la phase d'analyse, en posant des questions aux décideurs du type :

• Que voulez vous analyser (la dernière ligne du tableau) ?
• Quels sont vos critères d'analyse (la première ligne du tableau) ?
• Jusqu'à quel niveau de détail voulez vous aller (les cellules è l'intérieur) ?

Remarque : L'axe du temps (dimension Temps) est toujours présent dans un entrepôt de données, c'est le type d'analyse le plus commun et le plus fréquent en entreprise.

La structure d'un entrepôt étant plus rigide que les systèmes conventionnels (se basent sur des ETL, des validations créées par l'homme, etc.), il est capital d'avoir une analyse des besoins exhaustive et conforme aux attentes des décideurs.

Il faut savoir :

• D'où provient chaque champ ?
• Comment transite l'information ?
• Où trouver l'information voulue?

Se poser des questions du type :

• Ai-je assez de données pour répondre aux besoins ?
• Si non, qu'est ce que cela impliquerait de les créer ?
• Comment alimenter mes dimensions ?
• Comment alimenter mes faits ?
• Comment valider mes chargements ?
• Etc., etc., etc.

Vous pouvez penser que c'est de la paranoïa (comme certains clients) et croire que tous ces problèmes n'apparaîtront pas forcément. Mais rappelez vous qu'un entrepôt ça coûte très cher, et qu'un entrepôt avec des données incomplètes, invalides ou non-conformes à la demande est tout simplement à mettre à la poubelle…

III-C. La solution

La modélisation en étoile découle naturellement du tableau ci-dessus, il en résulte le schéma suivant :

Schéma en étoile

Vous comprenez maintenant pourquoi on appelle ce schéma " modèle en étoile ".
Toutes les dimensions sont directement reliées à la table de faits, qui contient les données à analyser. Plusieurs remarques sont à faire pour ce schéma :

• La table de fait contient se qu'on appelle des " mesures ", des champs (numériques pour la plupart) sur lesquels on va faire nos analyses, on peut y trouver le montant des ventes nettes, les quantités vendues, les kilomètres parcourus, les quantités en pré commande, etc. La table de faits est reliée aux dimensions par des relation (1, n). Pour analyser une ligne de fait par client par exemple, il faut qu'il y ait une relation entre cette ligne et la dimension client.
• Les tables de dimension contiennent les éléments qu'utiliseront les décideurs pour voir la table de faits. Les utilisateurs pourront ainsi apprécier les montant des ventes par vendeur, par client, ou le kilométrage pour un vendeur pour un client donnée (pour voir si ce client est rentable), calculer le coût de revient d'un produit par rapport aux activités des vendeurs, etc.
• On n'utilise JAMAIS la clé d'un système de production comme clé de dimension : pour préserver l'historique des modifications dans l'entrepôt de données (voir l'article sur la gestion de l'historique dans un entrepôt de données).
• La granularité des tables de dimensions et de faits doit être la même : imaginez que la table de faits regroupe les informations par heures et que la table de dimension du temps gère les minutes, il ne sera pas possible de lier la dimension temps et la table de faits (multi détermination).
• Chaque ligne de la table de faits doit avoir une relation avec chacune des tables de dimensions : dans le cas contraire, on aurait perte d'information ou analyse erronée.
• Il n'existe de relations qu'entre les dimensions et les tables de faits. Il sera beaucoup trop compliqué de gérer et d'utiliser des dimensions liées entre elles. N'oubliez pas que le schéma doit être assimilable par des non informaticiens pour pouvoir l'exploiter. N'ayons pas peur de créer des doublons !

IV. Modélisation en flocon, un cas

La modélisation en flocon étant une variante de la modélisation en étoile, nous prendrons le même cas avec la même analyse.
Il faut savoir que la modélisation en flocon existe pour des raisons de performances. En effet, des dimensions de plusieurs millions de lignes peuvent poser des problèmes de lenteur lors de l'exploitation des données.
Le principe de la modélisation en flocon est de créer des hiérarchies de dimensions, de telle manière à avoir moins de lignes par dimensions. Vous me direz que cela va en contradiction avec la dernière remarque de la modélisation en étoile, et je vous dirai que vous avez raison, à la seule chose prés que la performance prime sur la structure. C'est la seule façon que les gens ont trouvée pour avoir des résultats clairs et rapides.
Le schéma d'une modélisation en flocon pourrait être comme suit :

Modélisation en flocon

Conseil : ne " floconisez " pas à tort et à travers. En effet, pour garder une structure simple, gérable et compréhensible, utilisez le plus possible la modélisation en étoile. La modélisation en flocon n'intervenant que lorsque des problèmes de performances apparaissent ou sont facilement prédictibles.
Une règle informelle en BI préconise de floconner que si l'on a la relation (1-1000). C'est-à-dire que si l'on réussit à créer une hiérarchie de deux dimensions avec une ligne de la dimension père (groupe produit par exemple) faisant référence à plus de 1000 lignes de la dimension fille (produit par exemple). Dans ce cas, il est peut être temps de penser aux flocons.

Note : cette règle fût émise en prenant en considération les technologies logicielles et matérielles actuelles. Il ne serait pas étonnant, à mon sens, de voir disparaître la modélisation en flocon avec les avancées technologiques (rapidité des disques durs, technologies OLAP, etc.)

V. Conception d'entrepôts de données

Je sais ce que vous vous dites : mais c'est pas ce qu'on vient de faire la !! Relisez les titres et voyez si je parle d'entrepôts :)
Plus sérieusement, un entrepôt de données, un vrai, selon la définition officielle et pas celle des commerciaux, est une vue complète et centralisée des données de l'entreprise. La modélisation en étoile ou en flocon, elle, ne s'intéresse qu'à la conception d'un sous ensemble d'entrepôt, une seule table de fait. On ne peut même pas dire qu'une étoile ou un flocon représente un data Mart, car une fonction de l'entreprise peut comporter plusieurs tables de faits. La fonction commerciale d'une entreprise peut comporter une étoile pour les ventes, un flocon pour les commandes, une autre étoile pour les retours, etc.
Ce qui est juste, c'est qu'un entrepôt de données est l'ensemble de ces étoiles et/ou flocons. Mais comment organiser tout ça ?

V-A. Constellation

Vous remarquez que tous ces termes sont empruntés à l'astronomie et à la météo : étoile, flocon, constellation. Hubert Reeves n'a qu'à bien se tenir :)
Une constellation est une série d'étoiles (tu m'étonnes !) ou de flocons reliées entre eux par des dimensions. Il s'agit donc d'étoiles avec des dimensions en commun. Un environnement décisionnel idéal serait une place ou il serait possible de naviguer d'étoile en étoile, de constellation en constellation et de Data Mart en DataMart à la recherche de l'information si précieuse.
Un des indicateurs clés d'une bonne conception d'entrepôt est la grosseur des constellations. En effet, plus la constellation est grosse, plus cela veut dire que vous avez réutilisé vos dimensions, et qui dit réutilisation de dimension, dit dimensions complètes, centralisées et avec une vue orientée entreprise.
Je m'explique :

En conception d'entrepôt, il ne faut pas se casser la tête, dès qu'une dimension existante ne correspond pas parfaitement aux besoins d'une nouvelle étoile, on en crée une autre, même si elle est " presque " comme la dimension que nous allions utiliser. C'est pour cela qu'il faut créer, autant que possible, des dimensions génériques et qui soient vraies tout le temps, pour toutes les fonctions de l'entreprise. Ces dimensions pourront être réutilisées et assurer une pérennité des données. Et si de telles dimensions ne peuvent pas être crées, il ne faut pas avoir de remords à créer des dimensions similaires mais adaptées aux besoins de la nouvelle étoile. Mais si vous voyez que dans chaque étoile vous êtes obligés de créer une nouvelle dimension " client " par exemple, posez vous des questions sur votre conception.

V-B. Construire un entrepôt de données, un vrai !

Récapitulons, nous avons vu comment créer une étoile ou un flocon, nous avons vu que les data marts sont des étoiles regroupées par fonction ou par utilité dans l'entreprise et nous savons qu'un entrepôt est l'ensemble de tous les data marts de l'entreprise. Nous savons faire une étoile, mais comment les regrouper pour mettre en œuvre un entrepôt de données ? Et bien trois méthodes s'offrent à nous :

• Top-Down : c'est la méthode la plus lourde, la plus contraignante et la plus complète en même temps. Elle consiste en la conception de tout l'entrepôt (ie : toutes les étoiles), puis en la réalisation de ce dernier. Imaginez le travail qu'une telle méthode implique : savoir à l'avance toutes les dimension et tous les faits de l'entreprise, puis réaliser tout ça… Le seul avantage que cette méthode comporte est qu'elle offre une vision très claire et très conceptuelle des données de l'entreprise ainsi que du travail à faire.
• Bottom-Up : c'est l'approche inverse, elle consiste à créer les étoiles une par une, puis les regrouper par des niveaux intermédiaires jusqu'à obtention d'un véritable entrepôt pyramidal avec une vision d'entreprise. L'avantage de cette méthode est qu'elle est simple à réaliser (une étoile à la fois), l'inconvénient est le volume de travail d'intégration pour obtenir un entrepôt de données ainsi que la possibilité de redondances entre les étoiles (car elles sont faites indépendamment les unes des autres).
• Middle-Out : c'est l'approche hybride, et conseillée par les professionnels du BI. Elle consiste en la conception totale de l'entrepôt de données (ie : concevoir toutes dimensions, tous les faits, toutes les relations), puis créer des divisions plus petites et plus gérables et les mettre en œuvre. Cela équivaut à découper notre conception par éléments en commun et réaliser les découpages un par un. Cette méthode tire le meilleur des deux précédentes sans avoir les contraintes. Il faut juste noter que cette méthode implique, parfois, des compromis de découpage (dupliquer des dimensions identiques pour des besoins pratiques).

VI. Critique des méthodes de conception d'entrepôts

C'est très humblement que j'ajoute cette section car je ne suis pas un chef de file dans le domaine. Le BI me passionne, je lis énormément sur le sujet, mais je n'ai pas encore proposé de méthode de conception :)

Mon avis est que les méthodes décrites plus haut sont une très bonne façon de faire du BI avec les moyens techniques d'aujourd'hui. Bien que nous appliquions des compromis entre conception logique et réelle (étoile et flocon) et bien que la réalisation ne ressemble pas toujours à la conception (création de tables d'agrégats, division de tables pour des questions de performance, recréation de dimensions identiques pour des questions de performance, etc.), la représentation des données à base de dimensions et de faits offre un regard très analytique sur le data de l'entreprise et permet de sublimer les limitations du modèle relationnel en troisième forme normale en matière de manipulation de gros volumes des données.

Il reste que, en utilisant ces méthodes régulièrement, l'on se rend compte qu'il y a beaucoup de bidouillage et beaucoup de gestion d'intégrité manuelle (grâce aux ETL), à un point tel que si l'on n'est pas extrêmement rigoureux dans sa gestion de projet, l'environnement décisionnel peut facilement se transformer en une vrai usine à gaz.

En résumé, étant la meilleure manière de faire du décisionnel pour l'instant, la modélisation en étoile reste une façon très efficace d'organiser les données pour des fins d'analyse. Mais le temps, et la veille technologique, nous diront s'il existera une meilleure manière de faire du décisionnel avec les nouvelles technologies logicielles et matérielles.

VI. Conclusion

Je citerais, en conclusion, les éléments qui vous feront déduire que votre conception est bonne :

• Que votre entrepôt de données permettra de faire toutes les opérations analytiques et donnera aux décideurs des moyens chiffrés pour évaluer les faits voulus.
• Que vos dimensions seront orientées entreprise et pas fonction, avoir le plus possible des dimensions génériques et réutilisables.
• Pas trop de flocons dans votre entrepôt, si c'est le cas, pensez plutôt à changer de serveur ou de moteur de stockage. C'est plus une technique d'optimisation que de conception.
• Avoir des noms d'attributs et de tables compréhensibles par les utilisateurs.
• Documenter, documenter, documenter. N'oubliez pas qu'un entrepôt non documenté est un entrepôt qu'on ne peut pas faire évoluer, comprendre ou modifier. Gare à la rétention d'information !!
• N'oubliez pas, pendant votre phase d'analyse, de lister les outputs et les questionnements des analystes et décideurs de votre entreprise. Ceux-ci serviront de fil conducteur tout au long de votre projet.

Initiation au décisionnel

I. Introduction

Vous avez certainement dû entendre parler d'au moins un de ces trois termes qui sont intimement liés : Business intelligence, Datawarehouse et Analyse OLAP. En effet, depuis les années 2000-2001, le marché du décisionnel ne cesse d'exploser en France (et partout d'ailleurs) surtout avec l'investissement de plusieurs grandes sociétés qui souhaitent instaurer un système de Business Intelligence (B.I.) dans leur organisation. Ce système difficile à mettre en œuvre, demandant une expertise et nécessitant une maîtrise d'ouvrage de la part des informaticiens concepteurs du système rend souvent difficile le recrutement de ces profils. Mais c'est quoi le décisionnel ? Comment y débuter ? Eh bien je vais tenter dans cet article de donner un aperçu de tout ce jargon souvent méconnu et n'ayant souvent pas d'équivalents français et j'essaierai après un bref aspect théorique, de passer à un aspect pratique traitant l'analyse OLAP avec Analysis Services de Microsoft.

N.B. : la deuxième partie de cet article a été réalisée avec la version 7.0 de SQL Server. Étant encore nouveau dans la version 2005, j'attends encore un moment pour réaliser une nouvelle version de cette partie pratique avec SQL Server 2005.

II. Aspect théorique

Dans cet aspect théorique nous allons un peu expliquer l'utilité du décisionnel, des acteurs du décisionnel et des architectures usuelles.

II-A. Pourquoi le décisionnel ?

Tout d'abord, rappelons-le, le décisionnel ne concerne souvent que les entreprises qui gèrent un historique de leurs événements passés (faits, transactions etc.). Les entreprises qui viennent de naître n'ont souvent pas besoin de faire du décisionnel car elles n'ont pas encore besoin de catégoriser ou de fidéliser leurs clients. Le souci majeur pour elles serait plutôt d'avoir le maximum de clients et c'est après en avoir récupéré un grand nombre qu'elles penseront certainement à les fidéliser et leur proposer d'autres produits susceptibles de les intéresser. C'est ce que l'on appelle Customer RelationShip Management (CRM ou gestion des relations clients).

II-B. Qui a besoin du décisionnel ?

Comme cela peut se deviner, les décideurs sont les principaux utilisateurs des systèmes décisionnels. Les décideurs sont généralement des « marketeurs » ou analystes en général. Ces derniers établissent généralement des plans marketing qui leur permettent de mieux cibler leurs clients, de les fidéliser etc. Et pour cela, ils ont besoin d'indicateurs et des données résumées de leurs activités (ils n'ont souvent besoin de détail que pour des cas spécifiques). Par exemple, contrairement aux systèmes relationnels (ou base gestion) où les utilisateurs chercheront à connaître leurs transactions pour faire un bilan, les systèmes décisionnels quant à eux cherchent plutôt à donner un aperçu global pour connaître les tendances des clients (d'où l'opposition des deux modes [quantitatif contre qualitatif]).

II-C. Architecture des systèmes décisionnels

Exemple d'architecture décisionnelle.

Voici une architecture de système décisionnel très utilisée. Dans cette architecture, on dispose d'un entrepôt de données ou DataWarehouse (généralement, il s'agit plutôt d' un datamart qui est plus petit que le DW et qui concerne un domaine bien particulier [finance, ressources humaines etc.]). L'entrepôt (ou encore info-centre !) centralise les données issues de plusieurs sources (bases de production de l'entreprise, fichiers textes, documents web [html, xml, sgml etc.] etc.). Ces données sont fusionnées dans l'entrepôt qui est généralement une grosse base de données (SQL Server, Oracle etc.). Ensuite, une fois l'entrepôt confectionné, des données sont extraites dans des serveurs d'analyse ou serveurs OLAP sous forme de cubes de données (Analysis Server, EssBase etc.) afin d'être analysées. Enfin, des générateurs d'états (Business Objects, Crystal Report etc.) sont utilisés afin de présenter l'étude aux utilisateurs finaux ou décideurs (ex: analystes marketing).

II-C-1. Les sources de données

Les sources de données sont souvent diverses et variées et le but est de trouver des outils ETL (Extraction / Transformation / Loading) afin de les extraire, de les nettoyer, de les transformer et de les mettre dans l'entrepôt de données (DTS de SQL Server est un exemple d'outil ETL). Des outils comme Datastage ou Talend (monde open source) sont spécialisés en la matière.

II-C-2. L'entrepôt de données

Il est le cœur du système décisionnel et demande une analyse profonde de la part de la maîtrise d'ouvrage. La conception d'un DataWarehouse diffère de la conception d'une base de données relationnelle. En effet, alors que les bases de données relationnelles tendent le plus souvent à être normalisées, les bases de données multidimensionnelles, elles, sont plutôt dénormalisées, respectant le modèle en étoile ou le modèle en flocon. Voici ci-dessous un exemple de schéma d'un entrepôt de données:

Modèle physique d'un schéma en étoile.

Le modèle physique ci-dessus contient une table centrale à laquelle toutes les autres tables sont liées (modèle en étoile). La table centrale (ici table VENTE) est appelée la table des faits et contient toutes les autres clés des autres tables. Cette table de faits contient aussi une ou plusieurs valeurs numériques particulières (ici prix et nb_articles) appelées mesures. Généralement un niveau de granularité est aussi défini pour la table des faits (regroupe-t-on par exemple un ensemble de ventes de même type pour en faire un enregistrement ? Les enregistrements sont-ils unitaires (un enregistrement par transaction ?). Les autres tables du modèle sont appelées tables de dimensions. Ici par exemple, on dispose des dimensions CLIENTS, PRODUITS et TEMPS. Une dimension Temps est presque toujours présente dans les bases multidimensionnelles tout simplement parce qu'on analyse les données dans le temps.

II-C-3. Le serveur OLAP ou serveur d'analyse

OLAP (On-Line Analytical Processing) est opposé à OLTP (On-Line Transactional Processing) et a pour but d'organiser les données à analyser par domaine/thème et d'en ressortir des résultats pertinents pour le décideur. Les résultats sont donc des résumés et peuvent être obtenus par différents algorithmes de datamining (fouille de données) du serveur d'analyse. On peut par exemple établir le résultat suivant : « Les clients qui achètent généralement du beurre et du pain achètent aussi du lait ». Ces résultats pourraient amener l'organisation (ici en l'occurrence une grande distribution) à disposer ses rayons de telle façon qu'à côté de l'emplacement du beurre, elle mettra le pain et le lait.

II-C-4. Le générateur d'états

Le générateur d'état permet seulement de mieux appréhender le résultat de l'analyse. L'utilisateur final n'étant pas forcément un informaticien, il aura plus de facilité dans des états Business Objects (ou même dans des feuilles de données Excel) avec des diagrammes et courbes statistiques que d'aller directement requêter dans le serveur d'analyse. Au passage, je rappelle que travaillant généralement avec SQL Server et Analysis Services, le langage de requêtage multidimensionnel a pour nom MDX (qui ressemble au SQL mais n'est pas du SQL). Les états permettent également de faire de l'exploration (navigation) de données (notamment du Rollup / Drill-Down).

II-C-5. Quelques termes usuels du décisionnel

Datawarehouse : entrepôt de données

Datamart : petit entrepôt de données à l'échelle d'un département ou succursale d'une grande société. Généralement un datamart déverse ses données chez sa mère qui est le datawarehouse

OLTP : OnLine Transactonal Processing. Il s'agit des traitements transactionnels. Par exemple, les logiciels des caisses enregistreuses des chaînes de magasins font du OLTP.

OLAP : OnLine Analytical Processing. Opposé à l'OLTP, faire de l'OLAP signifie faire de l'analyse de données. Analyser les ventes, détecter les fraudes, prospecter des clients font partie du processus OLAP.

ETL : un outil ETL (Extraction / Transformation / Loading) permet à partir de diverses sources de données, d'extraire de l'information, de faire des transformations afin de nettoyer les données et de charger des données utiles dans l'entrepôt de données. Les sources de données peuvent être diverses (HTML, XML, base de données, fichiers texte, tableurs, ERP etc.).

Serveur d'analyse : un serveur d'analyse ou serveur OLAP est un serveur de base de données multidimensionnelle. Exemple : Analysis Server est un serveur de bases multidimensionnelles.

Base de données multidimensionnelle : une base de données multidimensionnelle par opposition à une base de données relationnelle est une base dénormalisée où il existe une table centrale (table de faits) liée à toutes les autres tables (tables de dimensions).

Table de faits : comme son nom l'indique, une table de faits est une table contenant tous les faits du SI et dont dépendent toutes les autres tables. Cette table ne contient que des clés étrangères venant des tables de dimensions et des valeurs numériques appelées mesures. Exemple de table de faits : table des ventes.

Tables de dimensions : les tables de dimensions sont des tables servant d'axes d'analyse. On peut par exemple analyser les ventes (table de faits) suivant l'axe des temps (table de dimensions) pour indiquer par exemple pendant quel trimestre de l'année les ventes ont explosé.

Mesure : une mesure est une quantité présente dans la table de faits qui permet de mesurer les faits. Par exemple, nombre de ventes ou prix unitaire sont des exemples de mesures.

Cube : un cube de données est une structure dimensionnelle comme une table est une structure relationnelle. Un cube est constitué d'une ou plusieurs tables de faits avec leurs tables de dimensions. On peut par exemple considérer un cube vente contenant sa table de faits « vente » et ses tables de dimensions « clients », « régions » et « temps ».

Niveau de hiérarchie : un niveau de hiérarchie se définit au niveau des tables de dimensions. Cela permet d'agréger les données. Par exemple, supposons qu'on ait la dimension région contenant la liste des villes, on pourrait faire un niveau de hiérarchie (niveau 1) classant les villes en régions, ensuite un niveau plus bas qui les classerait en départements (niveau 2).

Drill-down: faire un drill-down, c'est avoir un niveau de détails sur les données. Par exemple Supposons qu'on veuille voir le détail des ventes pour le premier trimestre de l'année 1997. On dit qu'on fait un drill-down sur l'axe (ou dimension) temps. C'est-à -dire qu'on ne veut pas voir seulement les données de l'année 1997 mais descendre à un niveau de détail plus bas.

Roll-up: rollup est le contraire de drill-down. C'est donc faire de l'agrégation (ou résumé) des données.

III. Aspect pratique

Pour l'aspect pratique, nous allons supposer que notre datawarehouse est déjà mis en place. Tout ce que nous allons faire , c'est faire de l'analyse OLAP sur notre datawarehouse.

III-A. Pré-requis

Avant de commencer ce tutorial, vous devez posséder la base Access FoodMart.mdb qui est notre datawarehouse. Cette base est une base d'exemple fournit par Microsoft. Une remarque assez importante sur cette base est qu'ici on voit que la base Access est déjà sous format d'un datawarehouse avec des tables de faits (sales_fact_1997 ou sales_fact_1998) et tables de dimensions (product ou region ou store).

Ci-dessous on voit bien que la table sales_fact_1997 est une table de fait qui référence les autres tables. Cette table ne contient que des valeurs numériques (les identifiants des tables de dimension ainsi que les mesures).

NB : Cette base de données exemple se situe sur C:\Program Files\OLAP Services\Samples\FoodMart.mdb (bien sur pour la version 7 de SQL Server).

III-B. Créer une Source de données ODBC

Avant de commencer à travailler avec OLAP Manager, vous devez créer un lien ODBC sur vos données ici en l'occurrence sur la base Access FoodMart.mdb. Pour cela faire :

• A partir du menu démarrer, aller dans panneau de configuration, choisir Source de données ODBC.
• Dans l'onglet source de données system, cliquer sur ajouter.
• Choisir Microsoft Access Driver (*.mdb) et cliquer sur terminer.
• Entrer ventes pour le nom de la source de données.

• Cliquer le bouton sélectionner et choisir dans la boite de dialogue qui apparaît la base FoodMart.mdb qui se trouve dans C:\Program Files\OLAP.Cliquer ensuite sur OK.
• Cliquer sur OK pour fermer la boite de dialogue de lien ODBC Access.
• Cliquer sur OK pour fermer la boite de source de données ODBC.

III-C. Démarrer OLAP Manager

OLAP manager est un snap-in qui se situe sur la console MMC Microsoft Management Console. Pour démarrer OLAP manager faire :

• A partir du menu démarrer, dans programmes, choisir Microsoft SQL Server 7.0, ensuite OLAP Services et choisir OLAP Manager.

III-D. Créer votre base de données d'analyse

Maintenant vous pouvez travailler avec OLAP manager. Avant d'ouvrir votre cube en mode design, vous devez d'abords mettre en place une structure de données et vous connecter à la source de données créées plus haut. Pour mettre en place cette source de données faire :

• Dans l'OLAP manager, défiler le noeud OLAP Servers
• Choisir le nom de votre serveur OLAP (ici PC-MSYLLA1).

• Faire un Click droit sur le serveur et choisir " Nouvelle base de donnée "

• Choisir un nom à donner à votre base OLAP et faire OK. Dans mon cas je l'appelle " ventes "
• Vous venez donc de créer votre base de données OLAP.Vous pouvez vous amuser à regarder ce que contient l'arborescence de votre base d'analyse. On peut donc y remarquer les snap-in : " Cubes ", "Virtual Cubes " et " Library ".

Maintenant que la base de données est créée, il va falloir se connecter à notre datawarehouse et pour cela il faudra créer une source de donnée sous OLAP manager et choisir notre source de données ODBC créées précédemment.

III-E. Créer une source de données OLAP

Pour cela faire :

• Dans l'arborescence du OLAP manager, défiler " Library " et faire un click droit sur " Source de données " et choisir Nouvelle source de données
• Choisir alors la source de données ODBC " ventes " que nous avions créées dans la section " créer une source ODBC ".

Maintenant que nous avons tout configuré, il est temps de construire notre cube de données. Pour cela nous allons considérer le scénario suivant :

Scénario : Vous êtes un DBA travaillant pour la société Food Mart. Food Mart est une large chaîne alimentaire avec des ventes enregistrées dans les 50 états des Etats-Unis. Le département de marketing voudrait alors analyser ses ventes réalisées pour la seule année 1997. Avec les données stockées dans le " datawarehouse ", vous êtes chargé de construire une structure multidimensionnelle (un cube) pour avoir des temps de réponse plus rapide lorsque les analystes marketing interrogent la base de données.

Rappel : Un cube de données contient des mesures (ou données qualitatifs comme les coûts ou le nombre de vente etc..) et des dimensions (ou données métiers descriptives comme les régions géographiques, le temps ou encore clients etc.).

III-F. Ouvrir l'assistant création de Cube

Dans l'arborescence du OLAP manager, dans la base vente ", faire un click droit sur " Cube " et choisir " Nouveau cube " puis choisir le sous-menu " Assistant ".

III-G. Ajouter une mesure au cube

• Dans l'écran de l'assistant de création du cube, faire suivant

• Dans l'écran " Choisir une table de fait pour votre cube ",dérouler le data source " ventes "

• Choisir " sales_fact_1997 ", représentant les ventes de 1997.Vous pouvez aussi visulaiser les données contenues dans cette table.
• Cliquez sur " suivant "

• Pour définir les mesures pour votre cube, sous " Colonnes numériques de la table de fait ", double-cliquez sur store_sales. Faire de même pour les colonnes store_cost et unit_sales représentant respectivement le nombre de vente, le coût de la vente et le prix unitaire.Cliquez ensuite sur " suivant ".

III-H. Construire la dimension Temps

Dans les bases multidimensionnelles la dimension Temps est généralement utilisé. D'ailleurs dans des SGBD comme DB2, elle est même imposée. Pour construire cette dimension faire :

• Dans la boite de dialogue " Sélectionnez les dimensions pour votre cube ", cliquez sur " Nouvelle Dimension ".

• Dans l'assistant de création de dimension, selectionner " Une table de dimension simple" et cliquer sur " suivant ".

• Sur l'écran " sélectionner la table de dimension ",dérouler " ventes " et cliquer sur " time_by_day ".Vous pouvez voir le contenu de cette table en cliquant sur " parcourir les données ".On voit qu'une date fait partie d'une semaine, d'un mois d'un trimestre etc…
• Cliquer sur " suivant ".

• Dans l'écran " sélectionner le type de dimension ", choisir " Dimension temps " puis cliquer sur " suivant ".

• Pour définir les niveaux de hiérarchie de votre dimension, cliquez sur " Choisir les hiérarchies du temps " et choisir Année,Trimestre,Mois comme niveau de hirarchie et cliquer sur " suivant ".

• Donnez un nom à votre dimension. Ici je lui donne le nom " Time ".Ensuite cliquer sur " Terminer " pour retourner à l'assistant " création de cube ".Ici on voit bien que l'année 1997 a été décomposé en 4 trimestre et que le premier trimestre contient les mois de janvier, février et mars.

• Vous pouvez ainsi voir votre nouvelle dimension " Time " dans la liste des dimension de votre cube.

III-I. Construire la dimension Produit

Pour construire la dimension Produit :

• Cliquer sur " Nouvelle dimension "

• Dans l'assistant de création de dimension, cliquer sur " tables de dimension multiples " et ensuite cliquer sur " suivant ".

• Sur l'écran " Selectionner les tables de dimensions ", dérouler " ventes " et double-cliquer sur product et product_class pour les ajouter dans " tables sélectionnées ".Cliquez ensuite sur " suivant ".

• Vous pouvez voir les deux tables sélectionnées et la jointure qui les lie. Ensuite cliquer sur " suivant ".

• Pour définir des niveaux de hiérarchie pour votre dimension, sous colonnes disponibles, double-cliquer dans cet ordre sur product_category, product_subcategorie et brand_name (représentant respectivement la catégorie de produit, la sous-catégorie de produit et le nom de marque du produit).On voit ainsi le nom des niveau de hiérarchie apparaître.Cliquez sur suivant.

• Donner le nom " Product " à la nouvelle dimension ainsi créée et laissez la case " Partagez cette dimension avec le autres cubes " cochée. Cliquez sur " Terminer ".

• vous pouvez alors voir la dimension " Product " dans la liste des dimensions du cube.

III-J. Construire la dimension Magasin

Pour construire la dimension Magasin :

• Cliquer sur " Nouvelle dimension "
• Dans l'assistant de création de dimension, cliquer sur " table de dimension simple " et ensuite cliquer sur " suivant ".
• Sur l'écran " Selectionner la table de dimension ", dérouler " ventes " et cliquer sur store. Cliquez ensuite sur " suivant ".
• Sur l'écran " selectionnez le type de dimension ", cliquez sur " suivant ".

• Pour définir des niveaux de hiérarchie pour votre dimension, sous colonnes disponibles, double-cliquer dans cet ordre sur store_country, store_state, store_city et store_name (représentant respectivement le pays du magasin, l'état du magasin, la ville du magasin et le nom du magasin).On voit ainsi le nom des niveau de hiérarchie apparaître.Cliquez sur suivant.

• Donner le nom " Store " à la nouvelle dimension ainsi créée et laissez la case " Partagez cette dimension avec les autres cubes " cochée. Cliquez sur " Terminer ".

• Vous pouvez alors voir la dimension " Store " dans la liste des dimensions du cube.

III-K. Construire la dimension Promotion

Pour construire la dimension promotion :

• Cliquer sur " Nouvelle dimension "
• Dans l'assistant de création de dimension, cliquer sur " table de dimension simple " et ensuite cliquer sur " suivant ".
• Sur l'écran " Selectionner la table de dimension ", dérouler " ventes " et cliquer sur promotion. Cliquez ensuite sur " suivant ".
• Sur l'écran " selectionnez le type de dimension ", cliquez sur " suivant ".

• Pour définir des niveaux de hiérarchie pour votre dimension, sous colonnes disponibles, double-cliquer dans cet ordre sur media_type, promotion_name (représentant respectivement le type de média et le nom de la promotion).On voit ainsi le nom des niveau de hiérarchie apparaître.Cliquez sur suivant.
• Donner le nom " Promotion " à la nouvelle dimension ainsi créée et laissez la case " Partagez cette dimension avec le autres cubes " cochée. Cliquez sur " Terminer ".

• Vous pouvez alors voir la dimension " Promotion " dans la liste des dimensions du cube.

III-L. Terminer la création du cube

Pour terminer la création du cube faire :

• Cliquer sur " suivant "

• Donner un nom à votre cube (ici " sales ") et cliquer sur " terminer ".

III-M. Editer le cube dans l'éditeur de cube

Dans le panneau schéma de l'éditeur de cube, vous pouvez voir la table de fait (avec sa barre de titre jaune) et les tables de dimension (avec leur barre de titre bleue).De plus, dans le panneau de gauche, vous pouvez voir la structure du cube. Vous pouvez éditer les propriétés du cube en cliquant sur le bouton " propriété ".

Supposons que maintenant vous ayez besoin d'une autre dimension qui vous donne des informations sur les clients. Vous pouvez facilement créer cette dimension .Cependant, les dimensions créées dans l'éditeur de cube sont privées c'est à dire qu'elles ne peuvent être utilisées qu'avec le cube avec lequel vous travaillez. Elles ne peuvent donc être partagées avec d'autres cubes.

• Dans le menu " insertion " de l'éditeur de cube, choisir " tables ".

• Dans la boite de dialogue " Sélectionner une table ", dérouler la source de donnée " ventes ", double-cliquer sur la table " customer " représentant les clients ensuite cliquer sur " fermer ".
• Pour définir la nouvelle dimension, double-cliquer sur la colonne " state_province " de la table " customer ".

• Dans la boite de dialogue Mapper la colonne, choisir " Dimension " puis cliquer sur " OK "
• Selectionner la dimension " State Province " de l'arborescence.
• Choisir l'item " Rename " du menu " Edit "

• Donner le nom " Customer " puis appuyer sur " Entrée ".

• Faire un drag and drop de la colonne " city " de la table " customer " du panneau de schéma vers la nouvelle dimension renommée en " Customer " dans le menu gauche de l'éditeur de cube.
• Dérouler " Customer " pour voir les deux niveaux de hiérarchie créés pour la dimension.

III-N. Ajouter un rôle au cube

Les rôles de cube définissent quels utilisateurs ou groupe d'utilisateurs ont accès au cube et peuvent y requêter. Maintenant que votre cube est totalement construit, vous allons ajouter un rôle au cube. Dans cet exemple, nous ajouterons le rôle " marketing ".

NB : Le DBA lui n'a pas besoin d'avoir des droits pour requêter sur le cube via OLAP manager. Seuls les utilisateurs qui utilisent un outil client (Excel, Business Objects etc.) sont concernés par les rôles définis.

Pour créer un nouveau rôle pour le cube faire :

• Dans l'éditeur de cube, choisir " Gérer les rôles " du menu " Outils "

• dans la boite de dialogue " Rôle de cube ", cliquez sur " Nouveau rôle ".
• Dans la boîte de dialogue " Créer un rôle de base de données ", taper " marketing " dans " Nom du rôle " (c'est le nom que nous donnerons à notre rôle pour permettre aux analystes marketing de pouvoir interroger les données).

• Dans la partie " Utilisateurs et groupes ", mettre les utilisateurs ou groupes d'utilisateurs du réseau qui auront accès.
• Dans la boite de dialogue " Rôles du cube ", le rôle " Marketing " apparaît dans la liste " Accès au cube ".Cliquez sur Ok.
• Dans l'éditeur de cube, choisir " enregistrer " à partir du menu " Fichier ".

III-O. Concevoir le type de stockage et traiter le cube

Les services OLAP permettent de choisir un type d' agrégations adéquat. Le choix du type d'agrégation est important car il influe beaucoup sur les temps de réponse des requêtes.Pour optimiser les performances de traitement des requêtes de votre cube, il faut utiliser " l'assistant design du stockage ".

Pour démarrer " l'assistant design du stockage " faire :

• A partir du menu " outils " de l'éditeur de cube, choisir " Design du stockage ".

• Sur l'écran " Design du stockage ", cliquez sur suivant.

• Sélectionner le type de stockage MOLAP puis cliquez sur " suivant ".MOLAP est le type de stockage multidimensionnel qui permet de stocker les agrégations dans le moteur Analysis Service contrairement au ROLAP (Relational OLAP) ou les données sont agrégées dans le moteur relationnel même. Pour un stockage de type MOLAP l'interrogation des données est rapide mais perd de son efficacité lorsque le volume de stockage devient très important.

• Sous " options d'agrégation ", sélectionner " gain de performance atteint ".Choisir alors un gain de performance de 40%.

• Ainsi donc on dit au moteur OLAP d'atteindre une performance de 40% même si on sait pas combien d'espace disque cela nécessiterait. Un DBA analyserait donc l'écran suivant pour voir l'impact que cela aurait sur l'espace disque requis.Cliquez donc sur " Démarrer ".
• Vous pouvez donc voir dans l'écran le rapport performance/espace.Ainsi on voit bien que plus on veut de la performance, plus on prend de la place.A la fin du traitement, faire " suivant ".

• Dans " que voulez-vous faire ? ", choisir " traiter maintenant ".
• Lorsque le traitement est terminé, un message apparaît signalant que " Le traitement s'est terminé avec succès ".Ensuite cliquer sur " fermer " pour retourner à l'éditeur de cube.
• A partir du menu fichier, choisir " quitter " pour fermer l'éditeur de cube et retourner à l'arborescence de l'OLAP manager.

NB : Traiter les agrégations risque de prendre du temps.

III-P. Visualiser les métadonnées du cube

Les services OLAP permettent de voir les métadonnées du cube c'est à dire les information détaillées de la configuration du cube de données. Ces informations apparaissent dans le panneau droit du OLAP manager.

Pour visualiser les métadonnées du cube " sales " faire :

• Dans l'arborescence de gauche du OLAP manager, dérouler " Cubes "
• Choisir le cube " Sales "
• Dans le panneau de droit du OLAP manager, cliquer sur " Metadata ".

III-Q. Naviguer sur les données du cube

Maintenant, vous êtes prêt à naviguer sur les données de votre cube " Sales ". En utilisant le browser de cube, vous pouvez voir les données suivant différents axes, vous pouvez aussi filtrer la quantité de données visible des dimensions et vous pouvez aussi faire des " drill-down " pour voir les données à un niveau de détail plus fin (ou faire un " roll-up " pour voir les données agrégées).Pour naviguer faire :

• Dans l'arborescence du OLAP manager, faire un click-droit sur le cube " Sales " et choisir " Naviguer sur les données ".

Ainsi le navigateur de cube apparaît faisant apparaître une partie supérieure contenant des dimensions et une partie inférieure contenant une grille avec les mesures et une dimension. Dans notre cas comme illustré dans la capture d'écran ci-dessous, on voit les quatre dimensions dans la partie de haut et une dimension et les mesures dans la partie basse. Pour remplacer une dimension par une autre, il suffit de faire un drag de la dimension à partir de la partie haute et faire le drop sur la partie basse.

Selectionnez donc la dimension Product faite un drag and drop sur la grille (partie basse) en faisant le drop sur là ou se trouve les mesures (MesuresLevel).Vous pouvez voir alors que product et MeasuresLevel sont intervertis comme sur l'écran suivant :

Maintenant, essayons de filtrer les données par date. Vous pouvez alors Cliquer sur la combo box de la dimension Time et vous avez la possibilité de voir toutes les données de l 'année 1997 ou de voir par exemple les données du deuxième trimestre seulement de cette même année.

Vous pouvez aussi faire un " drill-down " des données, c'est à dire avoir un niveau de détail des données. Par exemple, pour la dimension Product, dérouler le produit " Baking Goods " (patisserie) de la grille, vous pouvez donc voir pour cette catégorie de produit, ses sous-catégories et voir les ventes pour voir les sous-catégories.

IV. Conclusion

Dans cet article, j'ai juste donné un aspect global d'un système décisionnel qui est à la base du Business intelligence (B.I).Car avant de se lancer dans la panoplie d'outils qui font du décisionnel, sans doute faudrait-il d'abords connaître son mode de fonctionnement et avoir un aperçu pratique avec Analysis Services. Cependant, il serait intéressant de traiter les outils ETL, les états Business Objects ou encore les APIs de programmation multidimensionnelles (ADOMD, javax.jolap etc). 

 

source: http://taslimanka.developpez.com/tutoriels/bi/