Analyse et planification de l'application Essbase

Pour vous assurer que votre application Essbase analyse efficacement les informations de votre entreprise, élaborez un plan détaillé qui présente les sources de données, les besoins des utilisateurs et les éléments de base de données potentiels. L'attention portée à cette phase de conception peut vous faire gagner du temps de développement et d'implémentation.

La phase de planification et d'analyse implique les tâches suivantes :

• Analyser les données source

• Identifier les exigences utilisateur

• Planification de la sécurité dans un environnement à plusieurs utilisateurs

• Créer des modèles de base de données

Lors de la conception d'une application multidimensionnelle, tenez compte des facteurs suivants :

• Comment les informations circulent au sein de l'entreprise, qui utilise quelles données à quelles fins

• Types de reporting effectués par l'entreprise : quels types de données doivent être inclus dans le profil pour répondre aux besoins de reporting des utilisateurs

  Remarques :

  La définition d'une seule base de données par application améliore l'utilisation de la mémoire et facilite l'administration de la base.

Analyser les données source

Evaluez les données à inclure dans la base de données Essbase. Considérez d'où il vient, ainsi que la fréquence et la taille requises des mises à jour. Vous devez charger dans Essbase uniquement ce qui est nécessaire pour la génération de rapports croisés dynamiques et l'exploration amont. Le reste peut rester dans une source relationnelle, accessible par partition ou exploration amont.

Déterminez la portée de la base de données. Si une organisation a de nombreuses familles de produits contenant un grand nombre de produits, vous pouvez stocker des valeurs de données uniquement pour les familles de produits. Interrogez les membres de chaque service utilisateur pour savoir quelles données ils traitent, comment ils calculent et déclarent les données aujourd'hui, et comment ils veulent les traiter à l'avenir.

Définissez soigneusement les besoins en matière de rapports et d'analyses.

• Comment les utilisateurs veulent-ils afficher et analyser les données ?

• Quelle quantité de détails la base de données doit-elle contenir ?

• Les données prennent-elles en charge les objectifs d'analyse et de reporting souhaités ?

• Dans le cas contraire, quelles données supplémentaires avez-vous besoin et où pouvez-vous les trouver ?

Déterminez l'emplacement des données actuelles.

• Où chaque département stocke-t-il actuellement les données ?

• Les données sont-elles sous une forme que Essbase peut utiliser ?

• Les services stockent-ils des données dans des bases de données relationnelles sur des serveurs Windows ou UNIX, ou dans des feuilles de calcul Excel ?

• Qui met à jour la base de données et à quelle fréquence ?

• Les personnes qui ont besoin de mettre à jour les données y ont-elles accès ?

Assurez-vous que les données sont prêtes à être chargées dans Essbase.

• Les données proviennent-elles d'une ou de plusieurs sources ?

• Les données sont-elles dans un format que Essbase peut utiliser ? Pour obtenir la liste des sources de données valides que vous pouvez charger dans Essbase, reportez-vous à Sources de données.

• Toutes les données que vous souhaitez utiliser sont-elles facilement disponibles ?

Identifier les exigences utilisateur

Lorsque vous planifiez la base de données Essbase, discutez des besoins en informations avec les utilisateurs actuels des données et demandez-leur des exemples de rapport. Vérifiez les informations qu'ils utilisent et les rapports qu'ils doivent générer pour vérification par d'autres.

Déterminez les exigences suivantes :

• Quels types d'analyse les utilisateurs ont-ils besoin ?

• Les utilisateurs ont-ils besoin de rapports ad hoc (de type pivot) et de rapports structurés ?

• De quels niveaux d'information résumés et détaillés les utilisateurs ont-ils besoin ?

• Certains utilisateurs ont-ils besoin d'accéder à des informations que d'autres utilisateurs ne devraient pas voir ?

Planification de la sécurité dans un environnement à plusieurs utilisateurs

Identifiez les différents niveaux d'informations utilisateur nécessaires dans le cadre de la planification de la configuration des autorisations de sécurité Essbase. A la fin de l'analyse, vous devez disposer d'une liste d'utilisateurs et des droits d'accès requis.

Utilisez cette checklist pour planifier la sécurité :

• Qui sont les utilisateurs et quels droits d'accès doivent-ils disposer pour lire ou écrire des données dans la base de données ?

• Qui doit disposer des autorisations de chargement de données ?

• Qui doit être autorisé à effectuer des calculs ?

• Quels utilisateurs peuvent être regroupés et auxquels des autorisations similaires peuvent être affectées ?

Reportez-vous également à la rubrique Gestion des utilisateurs et des rôles.

Créer des modèles de base de données

Créez un modèle de base de données Essbase. Pour créer le modèle, vous devez identifier les perspectives et les vues qui sont importantes pour votre entreprise. Ces vues se traduisent par les dimensions du modèle de base de données.

De nombreuses entreprises analysent les points de vue suivants :

• Périodes

• Mesures

• Scénarios

• Produits

• Customers

• Régions géographiques

• Unités opérationnelles

Ensuite, pour vous aider à collecter des informations et à prendre des décisions, vous devrez identifier les objectifs d'analyse des données, déterminer les dimensions et les membres de la base de données et analyser la conception de la base de données.

Identifier les objectifs d'analyse

Une fois que vous avez identifié les principales vues d'informations d'une entreprise, l'étape suivante de la conception d'une base de données Essbase consiste à décider comment la base de données permet l'analyse des données. Par exemple, vous pouvez avoir besoin d'afficher les données par période, par zone géographique ou par type de produit.

• En cas d'analyse par temps, quelles périodes sont nécessaires ? L'analyse doit-elle inclure uniquement l'année en cours ou plusieurs années ? L'analyse doit-elle inclure des données trimestrielles et mensuelles ? Doit-elle inclure des données par saison ?

• Si vous effectuez une analyse par région géographique, comment définissez-vous les régions ? Définissez-vous des régions par territoire de vente ? Définissez-vous les régions par limites géographiques, telles que les États et les villes ?

• Si vous effectuez une analyse par ligne de produits, devez-vous vérifier les données de chaque produit ? Pouvez-vous résumer les données en classes de produits ?

Quelles que soient les vues métier, vous devez déterminer la perspective et les détails nécessaires à l'analyse. Chaque domaine fonctionnel que vous analysez fournit une vue différente des données.

Déterminer les dimensions et les membres

Les dimensions Essbase que vous choisissez déterminent les types d'analyse que vous pouvez effectuer. Dans chaque dimension, les hiérarchies des membres représentent des aspects de l'activité. Par exemple, une hiérarchie de temps peut inclure des trimestres et des mois. Une hiérarchie de produits classe les produits. Une hiérarchie régionale est basée sur les marchés géographiques.

Vous pouvez représenter chaque vue métier en tant que dimension standard distincte dans la base de données. Vous pouvez entendre des analystes d'entreprise se référer aux "bys" de leur entreprise, tels que par produit, par géographie et par période. Si vous devez analyser une vue métier par classification ou attribut, par exemple en fonction de la taille ou de la couleur des produits, vous pouvez utiliser des dimensions ou des propriétés d'attribut pour représenter les vues de classification.

Vous pouvez utiliser autant de dimensions que nécessaire pour l'analyse. Lorsque vous savez approximativement quelles dimensions et quels membres vous avez besoin, développez une conception de base de données provisoire.

Une fois que vous avez déterminé les dimensions du modèle de base de données, choisissez les éléments de chaque dimension. Ces éléments deviennent les hiérarchies et les membres de leurs dimensions respectives. Par exemple, une hiérarchie de temps peut inclure les périodes que vous souhaitez analyser, telles que les trimestres, et au sein des trimestres, les mois. Chaque trimestre et chaque mois devient membre de la dimension que vous créez pour le temps. Les trimestres et les mois représentent une hiérarchie à deux niveaux entre les membres et leurs enfants. Les mois d'un trimestre peuvent être consolidés en un total pour chaque trimestre.

Relations entre les dimensions

Examinez les relations entre les dimensions. La structure d'une base de données Essbase permet aux utilisateurs d'analyser facilement les informations sous de nombreux angles. Un analyste financier, par exemple, peut poser les questions suivantes :

• Qu'est-ce que les ventes pour un mois donné ? Comment ce chiffre se compare-t-il aux ventes du même mois au cours des cinq dernières années ?

• De quel pourcentage la marge bénéficiaire augmente-t-elle ?

• Dans quelle mesure les valeurs réelles sont-elles proches des valeurs budgétées ?

En d'autres termes, l'analyste peut vouloir examiner les informations de trois dimensions (temps, compte et scénario). La base de données illustrée ci-dessous représente ces trois dimensions, une dimension étant représentée le long de chacun des trois axes :

• Une dimension Temps, qui comprend Jan, Feb, Mar et le total pour Qtr1, est affichée le long de l'axe des X.

• Une dimension Comptes, qui se compose de chiffres comptables tels que Sales, COGS, Margin et Margin%, est affichée sur l'axe des Y.

• Une autre dimension, qui fournit un point de vue différent, comme Budget pour les valeurs budgétaires et Réel pour les valeurs réelles, est affichée sur l'axe des Z.

Figure 1-1 Cube représentant trois dimensions de base de données

Les cellules du cube, où les membres se croisent, contiennent les données relatives aux trois membres qui se croisent, par exemple les ventes réelles en janvier.

Exemple de structure dimension-membre

Le tableau ci-dessous présente un récapitulatif des dimensions à confirmer. Le concepteur d'applications a créé trois colonnes, les dimensions figurant dans la colonne de gauche et les membres dans les deux colonnes de droite. Les membres de la colonne 3 sont des sous-catégories des membres de la colonne 2. Dans certains cas, les membres de la colonne 3 sont divisés en un autre niveau de sous-catégories ; par exemple, la dimension Marge de la dimension Mesures est divisée en ventes et CMV.

Tableau 1-1 Dimensions de l'échantillon à confirmer

Dimensions	Membres	Membres enfant
Year	Qtr1	Jan, Feb, Mar
Year	Trim 2	avr, mai, juin
Year	Trimestre3	Jul, Aug, Sep
Year	Trim4	Oct, Nov, Déc
Mesures	Profit	Marge : Ventes, CMV Total des dépenses : Marketing, Paie, Divers
Mesures	Inventaire	Inventaire d'ouverture, Acquisitions, Fin de stock
Mesures	Ratios	% de marge, % de profit, bénéfice par once
Product	Cola (100)	Cola (100‑10), Cola diététique (100‑20), Cola sans caféine (100‑30)
Product	Bière racine (200)	Old Fashioned (200-10), Diet Root Beer (200-20), Sarsaparilla (200-30), Birch Beer (200-40)
Product	Soda à la crème (300)	Crème noire (300‑10), crème à la vanille (300‑20), soude à la crème diététique (300‑30)
Product	Soda aux fruits (400)	Cépage (400‑10), Orange (400‑20), Fraise (400‑30)
Market	East	Connecticut, Floride, Massachusetts, New Hampshire, New York
Market	Région de l'Ouest	Californie, Nevada, Oregon, Utah, Washington
Market	Sud	Louisiane, Nouveau Mexique, Oklahoma, Texas
Market	Centre	Colorado, Illinois, Iowa, Missouri, Ohio, Wisconsin
Scenario	Réel	S/O
Scenario	Budget	S/O
Scenario	Variance	S/O
Scenario	Variance (%)	S/O

En outre, le concepteur d'applications a ajouté les dimensions d'attribut suivantes pour permettre l'analyse des produits en fonction de la taille et de l'emballage :

Tableau 1-2 Dimensions d'attribut d'exemple à confirmer

Dimensions	Membres	Membres enfant
Onces	Grande Petite	64, 32, 20 16, 12
Type de conditionnement	Bouteille Permet	S/O

Liste de contrôle pour la détermination des dimensions et des membres

Utilisez la liste de contrôle suivante pour déterminer les dimensions et les membres de la base de données de modèle :

• Quels sont les candidats pour les dimensions ?

• Est-ce que l'une des dimensions classe ou décrit d'autres dimensions ? Ces dimensions sont candidates pour les dimensions d'attribut.

• Les utilisateurs veulent-ils qualifier leur vue d'une dimension ? Les catégories par lesquelles elles qualifient une dimension sont candidates pour les dimensions d'attribut.

• Quels sont les candidats pour les membres ?

• Combien de niveaux les données nécessitent-elles ?

• Comment les données sont-elles consolidées ?

Analyser la conception de base de données

Passez en revue la conception dimensionnelle Essbase initiale conformément à ces directives concernant le nombre de dimensions, leur valeur analytique combinée et la prévention de la répétition. L'exécution de cette analyse préalable vous aidera à concevoir une base de données efficace qui réponde à vos objectifs de consolidation et de calcul des données.

Le nombre de membres nécessaires pour décrire un point de données potentiel doit déterminer le nombre de dimensions. Si vous n'êtes pas sûr de devoir supprimer une dimension, conservez-la et appliquez d'autres règles d'analyse jusqu'à ce que vous ayez confiance en sa suppression ou sa conservation.

Dimensions denses et dispersées

Les dimensions dispersées et denses ont une incidence sur les performances. Reportez-vous aux sections suivantes :

• Dimensions dispersées et denses

• Concevoir un plan pour optimiser les performances

Dimensions standard et d'attribut

Pour plus de simplicité, les exemples de cette rubrique présentent des dispositions alternatives pour ce qui a été initialement conçu en deux dimensions. Vous pouvez appliquer la même logique à toutes les combinaisons de dimensions.

Considérez la conception d'une entreprise qui vend des produits à plusieurs clients sur plusieurs marchés ; les marchés sont uniques à chaque client :

             Cust A  Cust B  Cust C
New York     100     N/A     N/A
Illinois     N/A     150     N/A
California   N/A     N/A     30

Cust A est seulement à New York, Cust B est seulement dans l'Illinois, et Cust C est seulement en Californie. La société peut définir les données dans une dimension standard :

Market
  New York
    Cust A
  Illinois
    Cust B
  California
    Cust C

Cependant, si vous examinez un échantillon plus large de données, vous constaterez peut-être que de nombreux clients peuvent se trouver sur chaque marché. Cust A et Cust E sont à New York ; Cust B, Cust M et Cust P sont dans l'Illinois ; Cust C et Cust F sont en Californie. Dans ce cas, la société définit généralement la dimension de grande taille, Customer, en tant que dimension standard et Market, en tant que dimension d'attribut. La société associe les membres de la dimension Marché en tant qu'attributs des membres de la dimension Client. Les membres de la dimension Marché décrivent les emplacements des clients. Chaque client dispose d'un seul marché.

Customer (Standard dimension)
  Cust A (Attribute:New York)
  Cust B (Attribute:Illinois)
  Cust C (Attribute:California)
  Cust E (Attribute:New York)
  Cust F (Attribute:California)
  Cust M (Attribute:Illinois)
  Cust P (Attribute:Illinois)
Market (Attribute dimension)
  New York
  Illinois
  California

Considérez une autre situation. Encore une fois, l'entreprise vend des produits à plusieurs clients sur plusieurs marchés, mais elle peut les vendre à un client qui a des emplacements sur différents marchés :

             Cust A  Cust B  Cust C
New York     100      75     N/A
Illinois     N/A     150     N/A
California   150     N/A      30

Cust A est à New York et en Californie. Cust B est à New York et en Illinois. Cust C n'est qu'en Californie. L'utilisation d'une dimension d'attribut ne fonctionne pas dans ce cas ; un membre client ne peut pas avoir plusieurs membres d'attribut. Par conséquent, l'entreprise conçoit les données en deux dimensions standard :

Customer
  Cust A
  Cust B
  Cust C
Market
  New York
  Illinois
  California

Combinaisons de dimensions

Divisez chaque combinaison de deux dimensions en une matrice bidimensionnelle. Par exemple, les dimensions proposées à confirmer comprennent les combinaisons suivantes :

• Année sur toutes les mesures

• Année sur produit

• Année sur le marché

• Année sur scénario

• Mesures sur produit

• Mesures sur le marché

• Mesures sur un scénario

• Marché sur l'ensemble du produit

• Marché sur scénario

• Scénario sur l'ensemble du produit

• Onces sur le type de conditionnement

Les unités et le type de conditionnement, en tant que dimensions d'attribut associées à la dimension Produit, peuvent être pris en compte dans la dimension Produit.

Pour faciliter la visualisation de chaque dimension, dessinez une matrice et incluez quelques membres de première génération. L'image suivante présente un ensemble simplifié de matrices pour trois dimensions.

Figure 1-2 Analyse des relations dimensionnelles

Pour chaque combinaison de dimensions, posez trois questions :

• Y a-t-il une valeur analytique ajoutée ?

• Existe-t-il un utilitaire pour le reporting ?

• Evite-t-il un excès de combinaisons inutilisées ?

Pour chaque combinaison, les réponses aux questions permettent de déterminer si la combinaison est valide pour la base de données. Dans l'idéal, la réponse à chaque question est Oui. Sinon, envisagez de réorganiser les données en dimensions plus significatives. Au cours de ce processus, discutez des besoins en informations avec les utilisateurs.

Répétition dans les outlines

La répétition d'éléments dans une outline indique souvent la nécessité de fractionner les dimensions. Les exemples suivants vous montrent comment éviter la répétition.

Dans cet exemple, la colonne de gauche, intitulée "Répétition", affiche Profit, Margin, Sales, COGS et Expenses répétés sous Budget et Actual dans la dimension Accounts. La colonne de droite, intitulée "No Repetition", sépare Budget et Actual en une autre dimension (Scenario), laissant un seul ensemble de membres Profit, Margin, Sales, COGS et Expenses dans la dimension Accounts. Cette approche simplifie l'outline et offre une vue plus simple du budget et des chiffres réels des autres dimensions de la base de données.

Figure 1-3 Exemple d'élimination de la répétition en créant une dimension Scénario

Dans cet exemple, la colonne de gauche, intitulée "Répétition", utilise des membres partagés dans la dimension Régime pour analyser les boissons diététiques. Les membres 100-20, 200-20 et 300-20 sont répétés : une fois sous Diet, et une fois sous leurs parents respectifs. La colonne de droite, intitulée "Pas de répétition", simplifie l'outline en créant une dimension d'attribut Diet de type Booléen (Vrai ou Faux). Tous les membres ne sont affichés qu'une seule fois, sous leurs parents respectifs, et sont marqués avec l'attribut approprié ("Diet : True" ou "Diet : False").

Figure 1-4 Exemple d'élimination de la répétition en créant une dimension d'attribut

Les dimensions d'attribut fournissent également des fonctionnalités d'analyse supplémentaires. Reportez-vous à la section Avantages des attributs Essbase.

Pertinence interdimensionnelle

L'absence de pertinence interdimensionnelle se produit lorsque de nombreux membres d'une dimension ne sont pas pertinents pour d'autres dimensions. Essbase définit les données non pertinentes comme des données qu'Essbase stocke uniquement au niveau de la synthèse (dimension). Dans ce cas, vous pouvez supprimer une dimension de la base de données et ajouter ses membres à une autre dimension ou fractionner le modèle en bases de données distinctes.

Par exemple, TBC a envisagé d'analyser les salaires en tant que membre de la dimension Mesures. Mais les informations salariales ne sont souvent pas pertinentes dans le contexte d'une base de données d'entreprise. La plupart des salaires sont confidentiels et s'appliquent aux particuliers. L'individu et le salaire représentent généralement une cellule, sans raison de se croiser avec une autre dimension.

TBC a envisagé de séparer les employés en une dimension distincte. Le tableau suivant montre un exemple de la façon dont TBC a analysé la dimension Employé proposée en vue d'une absence de pertinence interdimensionnelle. Les membres de la dimension Employee proposée (représentés dans la ligne d'en-tête du tableau) sont comparés aux membres de la dimension Measures (représentés dans la colonne la plus à gauche). Les membres de la dimension Measures (tels que Revenue) s'appliquent à All Employees ; seule la mesure Salary est pertinente pour les employés individuels.

Tableau 1-3 Exemple de pertinence interdimensionnelle

	Joe Smith	Mary Jones	Mike Garcia	Tous les salariés
Revenue	Pertinence	Pertinence	Pertinence	Pertinence
Coûts variables	Pertinence	Pertinence	Pertinence	Pertinence
COGS	Pertinence	Pertinence	Pertinence	Pertinence
Publication	Pertinence	Pertinence	Pertinence	Pertinence
Salaires	Pertinence	Pertinence	Pertinence	Pertinence
Coûts fixes	Pertinence	Pertinence	Pertinence	Pertinence
Expenses	Pertinence	Pertinence	Pertinence	Pertinence
Profit	Pertinence	Pertinence	Pertinence	Pertinence

Raisons de scinder les bases de données

Etant donné que les informations individuelles sur les employés ne sont pas pertinentes pour les autres informations de la base de données et que l'ajout d'une dimension Employé augmenterait considérablement les besoins de stockage de la base de données, TBC a créé une base de données RH distincte. La nouvelle base de données RH contient un groupe de dimensions associées et inclut les salaires, les avantages sociaux, l'assurance et les plans 401(k).

Il existe de nombreuses raisons de fractionner une base de données. Par exemple, supposons qu'une société gère une base de données organisationnelle qui contient plusieurs filiales internationales dans plusieurs fuseaux horaires. Chaque filiale s'appuie sur des calculs financiers chronologiques. Vous pouvez fractionner la base de données pour des groupes de filiales dans le même fuseau horaire afin de vous assurer que les calculs financiers sont opportuns. Vous pouvez également utiliser une application partitionnée pour séparer les informations par filiale.

Liste de contrôle pour analyser la conception de base de données

Utilisez la liste de contrôle suivante pour analyser la conception de la base de données :

• Avez-vous réduit le nombre de dimensions ?

• Pour chaque combinaison dimensionnelle, avez-vous demandé :

  • Y a-t-il une valeur analytique ajoutée ?

  • Existe-t-il un utilitaire pour le reporting ?

  • Evite-t-il un excès de combinaisons inutilisées ?

• Avez-vous évité la répétition dans le contour ?

• Avez-vous évité l'absence de pertinence interdimensionnelle ?

• Avez-vous scindé les bases de données si nécessaire ?