La performance est une problématique récurrente dans les Systèmes d’Information mais elle l’est encore plus dans les Systèmes Décisionnels.
Pourquoi ? Les utilisateurs d’un système décisionnel (très souvent des décideurs) souhaitent obtenir leurs tableaux de bord ou rapports le plus rapidement possible pour prendre les bonnes décisions. Il est hors de question pour un décideur de lancer un tableau de bord et d’avoir le temps de « prendre un café » avant d’obtenir les informations souhaitées.
Si votre système est dans cet état : danger !
Pourquoi un système décisionnel aurait-il plus de risque qu’un autre projet, d’avoir des problèmes de performance ? Parce qu’un système décisionnel manipule un ensemble de données volumineux, en général avec un historique d’au moins 5 ans, voire plus, afin d’offrir une profondeur d’analyse de l’information.
Pour éviter que votre système ne coure à l’échec, à cause de performance déplorable, il est primordial que cette problématique soit considérée dans la globalité du projet et pas uniquement lors de l’affichage des tableaux de bord.
Voici la démarche proposée.

Pendant la conception

Sans entrer dans les détails concernant l’architecture de référence d’un système décisionnel, la modélisation dimensionnelle de la Base du Système de Diffusion et de Présentation (SDP) doit être utilisée. On parle ici de dimensions et de faits.
Les objectifs à considérer lors de cette phase de modélisation, sont :

• la structuration optimisée des données par rapport aux besoins exprimés par les utilisateurs. Cette partie s’effectue essentiellement lors de la modélisation conceptuelle (MCD). Le modèle ressemble à une étoile ou flocon (je suis sûre que vous savez de quoi je parle !),
• de faire des choix judicieux lors de l’élaboration du modèle physique de votre modèle :
  • analyser l’utilisation du modèle, se fier à son expérience et faire les bons choix d’implémentation des données (ex : utiliser des clés techniques et non fonctionnelles pour faire les jointures entre les tables),
  • bien choisir ses types d’agrégation de données (ex : je stocke ou pas mes calculs),
  • uniformiser (dénormaliser) ou non les dimensions (ex : au lieu d’avoir plusieurs tables dans une même hiérarchie et faire beaucoup de jointures, créer un seule table rassemblant  toutes les tables de la hiérarchie),
  • dénormaliser les tables de faits (ex : on peut se permettre de fusionner une table commande et ligne de commande),
  • créer des vues matérialisées. J’en parle car cela se fait mais à mon avis, quand on arrive à utiliser ces vues, c’est que le modèle utilisé est « malade » et la modélisation effectuée ne répond pas aux besoins,
  • définir les index sur les colonnes de jointures et de sélection. Pensez évidemment à reconstruire de temps en temps les index et mettre à jour les statistiques,
  • partitionner les données (ex : par période de temps, par agence),
  • définir et affecter des tables dans des espaces physiques de stockage adéquats (tablespace des données référentielles, tablespace des données en mouvement selon la volumétrie),
• d’effectuer le dimensionnement de l’architecture matérielle (disque dur, mémoire, CPU, réseaux,…), et plus spécifiquement l’estimation de l’espace disque réservé au cache et à son activation.

Je préconise à tous d’étudier les points les plus techniques avec un expert de la base de données (DBA) ayant (de préférence), une expérience dans les projets décisionnels.

Pendant le développement

Quand vous en arrivez là, c’est que votre modélisation est achevée et que vous avez rédigé vos spécifications détaillées des alimentations de vos tables et des restitutions désirées par les utilisateurs.
Pensée de l’auteur : la rédaction de ces spécifications vous permet aussi, de valider vos modèles.
Alimentation
Vos bases sont vides et doivent être alimentées à partir de données sources gérées très souvent par des applications hétérogènes.
Ces flux d’alimentation sont souvent des processus automatiques, mis en place à l’aide d’ETL comme Oracle Data Integrator (ODI).
Revenons à nos performances.
Le temps imparti pour l’alimentation de vote système décisionnel est souvent très court, c’est pourquoi l’exécution doit être la plus rapide possible. Il faut penser :

• à désactiver les contraintes d’intégrité référentielle dans la base, les contrôles étant transférés à l’ETL; ne pas oublier de réactiver les contraintes à la fin des alimentations,
• à utiliser un espace de travail (souvent appelée ODS) ou d’une base de réplication pour le stockage des données temporaires utilisées par l’ETL.

Restitution
Pensée de l’auteur : c’est la cerise sur le gâteau. Ce que le monde voit de votre système….
Les tableaux de bord qui vont être utilisés par l’utilisateur sont très souvent créés à l’aide d’outils de restitution, comme Oracle Business Intelligence Enterprise Edition  (OBIEE).
La création des tableaux de bord nécessite la mise en œuvre de « bests practices » concernant l’utilisation de l’outil de développement du référentiel analytique.
Spécifiquement pour OBIEE, les éléments structurants sont :

• respecter le formalisme entités/relations au niveau de la couche physique,
• respecter le formalisme dimensionnel (étoile ou flocon) au niveau de la couche métier,
• mettre en place des tables d’agrégation (si besoin),
• gérer l’utilisation du cache
• filtrer les données par profil utilisateur
• …

Conseils de l’auteur : Lorsque vous initialisez votre référentiel avec des libellés, veillez à ce qu’ils soient explicites et bien orthographiés : c’est ce que l’utilisateur voit en premier et surtout, vous évitera de « coder » les libellés dans vos tableaux de bord.

Pendant l’exploitation

Votre système décisionnel est en production et les utilisateurs sont ravis.
MAIS….
Une bonne performance n’est jamais acquise. Elle se soigne et c’est un travail de tous les jours. Je vois mes collègues DBA opiner de la tête !!
Il faut effectuer des opérations spécifiques comme :

• le tuning des requêtes,
• le calcul les statistiques sur des échantillons évoluant dans le temps,
• …

Et bien, j’espère que cet article vous servira à ne pas oublier que la problématique de performance doit être prise en compte dans toutes les étapes du cycle de vie du projet.