Framework manager - spécification

[Fractal Blue]

Bonjour,

Je tente de faire un document de spécification détaillé d'un framework. J'avoue que ne connaissant que peu la méthodologie de dév d'un framework, l'exercice m'est assez compliqué, c'est pourquoi j'ai commencé par la réalisation avant la spécification.

Ma question est la suivante : j'ai fait une vue physique et une vue métier mais je souhaiterai définir clairement ce qu'est une vue physique et ce qu'est une vue métier. Pouvez-vous m'aider ? (J'ai même entendu parler d'une vue logique ?)

Pour la vue physique je me suis contenter d'importer les tables sans ajouter les jointures et je n'ai rien renommé. J'ai créé un namespace par connexion différente.
Pour la vue métier j'ai un peu plus bossé... Nom des éléments, alias, jointure, déterminant pour les hierarchies ...
est-ce que je suis dans la bonne direction où est-ce que j'oublie de traiter qq chose dans la vue physique ? Quel est l'objectif de dissocier la vue physique de la vue métier ? Y-a-t-il un gain de performance en créant des query subject dont chaque query item est calculer en fonction de la vue physique ?

En gros je pense avoir compris la technique mais il me manque de la théorie et de la pratique. Quelques clefs de compréhension seraient les bien venues.

Merci,

Fractal Blue

[yphilogene]

Ca me semble pas mal du tout.

L'intérêt de l'organisation en couches superposées est simplement celui de la maintenance.

Ta couche logique est construite à partir de Query Subjects Model utilisant les éléments des Query Subjects Datasource de la couche physique. La couche logique est utilisée pour construire les rapports. Il ne faut donc pas qu'elle change souvent. En revanche, au niveau de la couche physique, tu fais ce que tu veux comme changement, tant que tu t'arranges pour remapper correctement avec la couche logique.

Il n'y a pas de perte de performance à organiser un modèle ainsi. Le moteur prendra peut-être quelque millièmes de seconde de plus pour générer la requête finale, mais ce n'est sûrement pas à ce niveau qu'on perd en performance sur un système B.I.

As-tu compris le principe des stitch query?

[Fractal Blue]

As-tu compris le principe des stitch query?

Je ne sais pas de quoi tu parles. Peux-tu m'expliquer ce qu'est les stitch query ?

[yphilogene]

Une stitch query est une requête avec jointure externe qui est générée lorsque deux tables de faits sont liées par une dimension commune (conforme).

Je t'invite à consulter la documentation Framework Manager à ce sujet. Il y a une version courte de cette documentation: "Guidelines for modeling metadata", qui reprend les chapitres essentiels du guide utilisateur de Framework Manager.

Il peut paraitre surprenant au premier abord que Cognos génère des jointures externes, même lorsque seules des jointures internes sont définis dans le modèle. La cardinalité des jointures a beaucoup d'impact sur la requête générée.

[xoninkara]

Si c'est un projet important, je vous conseille de passer beaucoup de temps à comprendre le schimilblick de Framework Manager et ne pas se précipiter à développer le modèle sachant qu'on ne maîtrise pas parfaitement.

Car sinon, vous risquez d'avoir des surprises lors de l'exécution des rapports et devoir tout recommencer à zéro, ou en tout cas, devoir apporter des modifications importantes.