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 :
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 :
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 :
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.
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 :
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 :
|
|
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 :
- 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)
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…
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.
Aucun commentaire:
Enregistrer un commentaire