Création de rapports en dimensionnel

Qu’est-ce que le dimensionnel ?

Bien que paraissant sorti tout droit d’un livre ésotérique ou de physique avancée, le développement en dimensionnel, aussi appelé développement multidimensionnel, désigne une fonctionnalité proposée par Cognos (et par d’autres outils) permettant de modéliser les données et de naviguer dans les dimensions grâce à des hiérarchies.

1. Le cube

L’ancêtre du modèle multidimensionnel actuel est le cube, aussi appelé cube OLAP. Il était modélisé grâce à l’outil Transformer, dans les anciennes versions de Cognos. Transformer a désormais disparu des versions les plus récentes de Cognos et la modélisation multidimensionnelle a été intégrée à l’outil Framework Manager, qui permet de modéliser les données sur lesquelles s’appuient les rapports.

Un cube peut être assimilé à un tableau multidimensionnel de deux dimensions ou plus, l’exemple de cube le plus basique étant le tableau croisé où les arêtes représentent les axes d’analyse (les dimensions), et le centre du tableau les mesures, c’est-à-dire les faits.

Historiquement, les cubes étaient précalculés, ce qui était à la fois leur point fort et leur point faible. Les cubes étaient généralement calculés pendant la nuit, car en fonction du volume de données, le calcul pouvait durer un certain temps, le logiciel calculant toutes les intersections entre les dimensions et les faits. De cette manière, le temps de réponse des rapports et autres requêtes était optimisé, car les calculs et les appels à la base de données étaient déjà faits. Un cube présentait également l’avantage d’être portable, c’est-à-dire qu’il n’avait pas besoin de connexion à la base de données pour fonctionner, car les calculs avaient déjà été effectués. Avec les logiciels adéquats, il était donc tout à fait possible d’aller chez un client avec le cube copié sur l’ordinateur et de lancer...

Quelques concepts en multidimensionnel

Avant d’entrer dans le vif du sujet, il est important de définir certains concepts propres au style dimensionnel et liés notamment à l’organisation des dimensions en hiérarchies. La compréhension de ces concepts rendra la prise en main du développement multidimensionnel plus fluide, et l’utilisateur abordera plus facilement ce « nouveau » style de développement qui, dans sa logique, diffère du requêtage classique de type SQL des modèles relationnels.

Mesure

Les mesures sont des données numériques pouvant être agrégées à l’aide de sommes, comptages, moyennes, minimum, etc. C’est ce que l’on appelle les faits en SQL.

Dimension

Une dimension représente un axe d’analyse des données, comme la couleur des yeux, le type de produit ou le calendrier. Elle permet donc de ventiler les mesures en fonction des valeurs de la dimension.

Hiérarchie

Une hiérarchie est un ensemble de champs organisés de façon hiérarchique de manière qu’un niveau soit le parent d’un autre niveau. Les valeurs du niveau parent peuvent être détaillées en passant au niveau inférieur. Typiquement, le calendrier est organisé en jours (niveau le plus bas), mois et années. Une dimension contient...

Création d’un rapport basé sur un modèle dimensionnel

Entrons à présent directement dans le vif du sujet. L’interface de développement des requêtes reste la même. La différence réside dans les fonctions appliquées sur les données élémentaires ainsi que dans l’utilisation de limiteurs à la place des filtres détaillés classiques.

1. Création d’un rapport simple

Comme il a été expliqué précédemment, une manière simple de créer un rapport basé sur un modèle dimensionnel est d’aller chercher les membres et les mesures requis dans l’arborescence, puis de les placer dans l’espace Données élémentaires de la requête.

Le fait de travailler directement avec des membres ou des ensembles de membres agit comme un filtre en soi. Il est donc très facile de récupérer les ventes sur deux mois afin de les comparer, et ce en quelques clics. Afin de créer un ratio pour comparer les résultats des deux mois et d’en faire ressortir une tendance, il suffit de créer une nouvelle donnée élémentaire et de calculer le ratio en divisant les résultats des deux membres (Janvier 2021 et Janvier 2022). Cette donnée élémentaire ne donne aucun résultat en soi si elle n’est pas associée à une ou plusieurs mesures dans la même requête. Elle crée un nouvel objet définissant l’opération à appliquer à la mesure. L’avantage essentiel est que cet objet n’est défini qu’une seule fois dans la requête et le ratio sera calculé pour toutes les mesures apparaissant dans le tableau croisé ou le graphique.

Il est donc possible d’imaginer un tableau croisé formé d’une ligne pour chaque mois et d’une troisième ligne pour le ratio. Chaque colonne du tableau croisé représente une mesure, comme les ventes, les quantités et la marge. Sur la ligne de chaque mois apparaîtront les résultats, et sur la ligne...

Introduction aux fonctions dimensionnelles

L’un des principaux avantages du modèle dimensionnel est la possibilité de naviguer dans les hiérarchies, et donc d’explorer les données de manière intuitive et dynamique. Cela ne se limite pas à cliquer sur un membre dans un tableau croisé afin de descendre de niveau et d’afficher le détail des données. Il existe en fait une multitude de fonctions dimensionnelles permettant au développeur ou à l’utilisateur de gérer l’information affichée en se positionnant à l’endroit voulu d’une hiérarchie.

Prenons l’exemple d’un rapport de ventes dans lequel le pays est choisi dans la page d’invite. Il est demandé d’afficher, non pas les informations des ventes du pays en tant qu’entité, mais le détail des ventes des établissements du pays. Les établissements font partie de la même hiérarchie que le pays et sont situés au niveau inférieur. Il existe des fonctions permettant, à partir d’un membre donné (statique ou encore provenant d’un paramètre), d’accéder à ses descendants, c’est-à-dire à ses enfants directs ou encore à ses descendants situés à des niveaux inférieurs. Dans cet exemple, la fonction children() est parfaitement adaptée au besoin et renvoie les enfants directs du pays en entrée de la fonction.

Cet exemple très simple permet d’illustrer la syntaxe et l’utilisation de ce type de fonctions. Bien entendu, pour des besoins plus complexes, il est possible d’imbriquer des fonctions afin de pouvoir se positionner à l’endroit voulu de la hiérarchie.

Prenons un autre exemple. Il s’agit cette fois de comparer, dans un tableau, les ventes d’un mois, sélectionné au moyen d’une invite, avec les ventes du même mois de l’année précédente. Toujours avec les fonctions dimensionnelles, il est possible, à partir du membre correspondant au mois sélectionné, de parcourir la hiérarchie pour se positionner au niveau du membre correspondant au même mois de l’année précédente. Une fois ce membre identifié...

Quelques conseils de conception (Framework Manager et rapports)

Cette section a pour but de donner quelques conseils de développement afin d’éviter certains écueils de conception tant avec Framework Manager qu’avec Report Studio. L’objet de cet ouvrage est le développement avec Report Studio de Cognos, et non Framework Manager, qui peut faire l’objet d’un autre ouvrage, voire de plusieurs ! Ce sont quelques recommandations ou concepts à prendre en compte et qui peuvent permettre une meilleure compréhension de la modélisation en dimensionnel.

1. La modélisation sous Framework Manager

a. Modèle en étoile ou en flocon

Les modèles de base de données en étoile et en flocon (et en constellation) sont très bien adaptés au monde du décisionnel en général, et plus particulièrement à la modélisation dimensionnelle. Les différents membres d’une hiérarchie sont directement mis à disposition par Cognos lors du développement du rapport, ce qui signifie que les requêtes sources de toutes les hiérarchies ont été envoyées au serveur de base de données afin de récupérer les résultats. Il paraît donc logique que les dimensions et les hiérarchies soient basées sur des tables les plus petites possible et que les requêtes soient les plus simples possible. Pour cela, les modèles en étoile ou en flocon sont parfaitement adaptés puisque chaque dimension (ou chaque niveau dans le cas d’un modèle en flocon) provient d’une seule table, la table de faits ne contenant que des clés étrangères et des mesures, ainsi que sa propre clé primaire, bien sûr.

Ci-après un exemple de modèle en étoile.

Ci-après un modèle en flocon dont les dimensions sont normalisées, c’est-à-dire que la redondance de données est éliminée. Par exemple, dans le cas de la dimension Produit, il est clair que l’information concernant la Ligne produit et le Type produit se répète pour chaque produit. Une dimension normalisée est donc composée d’autant de tables que de niveaux, mais requiert plus de jointures que la modélisation...