Discussion :

[bbo1991]

Je me pose une question sur la construction de mon entrepôt.

Supposons que je fasse une analyse de mes ventes sur ma dimension client.
Si j'ai des clients qui sont enregistrés en base mais qui n'ont encore aucun achat à leur compte:
- dois-je enregistrer les références de ces clients dans ma table de faits "ventes" pour chaque date et mettre le montant des ventes à zéro ???
- ou dois-je les ignorer et faire une jointure externe au niveau de mes requêtes de restitution ???

L'objectif étant d'avoir un rapport avec la liste complète des clients en base (qu'ils aient acheté ou pas) et le montant des ventes qui leur sont rattachées (un montant positif ou nul).

Le fait d'ignorer les clients qui n'ont effectué aucun achat lors de l'alimentation limite les enregistrements dans l'entrepôt mais il parait qu'effectuer des jointures externes par la suite est coûteux en terme de performance.

Alors concrètement je choisis quelle solution?

[uraxyd]

Je me pose une question sur la construction de mon entrepôt.

Supposons que je fasse une analyse de mes ventes sur ma dimension client.
Si j'ai des clients qui sont enregistrés en base mais qui n'ont encore aucun achat à leur compte:
- dois-je enregistrer les références de ces clients dans ma table de faits "ventes" pour chaque date et mettre le montant des ventes à zéro ???
- ou dois-je les ignorer et faire une jointure externe au niveau de mes requêtes de restitution ???

L'objectif étant d'avoir un rapport avec la liste complète des clients en base (qu'ils aient acheté ou pas) et le montant des ventes qui leur sont rattachées (un montant positif ou nul).

Le fait d'ignorer les clients qui n'ont effectué aucun achat lors de l'alimentation limite les enregistrements dans l'entrepôt mais il parait qu'effectuer des jointures externes par la suite est coûteux en terme de performance.

Alors concrètement je choisis quelle solution?

si tes clients n'ont fait aucun achat, ce ne sont pas des clients mais des prospects

Pour la jointure en elle meme elle n'est pas couteuse en perf mais c'est le trie qui la precede qui l'est.

[bbo1991]

si tes clients n'ont fait aucun achat, ce ne sont pas des clients mais des
prospects

Ok, gageons que j'ai pris un mauvais exemle pour mes clients.
Supposons qu'au lieu des clients on ait la liste des magasins de l'entreprise.
Sur cette liste de magasins on veut la liste des ventes d'un produit donné.
Or, sur un produit P particulier certains magasins n'ont effectué aucune vente. Et cette réalité on a besoin de le voir dans les rapports ...

Pour la jointure en elle meme elle n'est pas couteuse en perf mais c'est le trie qui la precede qui l'est

Mais je ne suis pas obligé de faire un tri dans ma requête, ça l'utilisateur peut le faire au niveau des rapports non?

Un autre problème sur les jointures externes, supposons que sur la dimension Magasin de mon second exemple j'ai un schéma en flocon avec comme suite de la branche Magasin, la dimension "Région" où se trouve le magasin suivi de la dimension "Pays".
Si on effectue une jointure externe sur la relation "Ventes-Magasin" on sera obligé de mettre également une jointure externe sur "Magasin-Region" et "Region-Pays", non?
Or si ces dimensions sont liés à d'autres faits et à d'autres contextes pour lesquelles cette jointure externe n'est pas pertinente on s'emmêle les pinceaux...

[ygrim]

Salut !
L'entrepôt de données est la stricte (rien d'ajouté) vérité sur ce qui s'est passé en entreprise. Cela veut dire que ta table de faits de ventes (qui contient les ventes) ne doit comporter que les lignes extraites depuis ton système source... Donc pas d'ajout de ventes à zéro. Le fait d'afficher tous les clients (mêmes ceux qui n'ont pas fait d'achats) est géré par ton système de reporting.

[bbo1991]

Le fait d'afficher tous les clients (mêmes ceux qui n'ont pas fait d'achats) est géré par ton système de reporting.

Ce qui revient à ajouter des jointures externes dans mes univers BO par exemple...

En tout cas je suis d'accord avec le fait que l'entrepôt doit refléter la stricte vérité sur la base opérationnelle.
Mais le fait qu'un magasin ait un total des ventes égal à zéro pour le produit X n'est-il pas une vérité ????

[yphilogene]

L'affichage de lignes vides pour des clients qui n'ont pas (encore) de données est un besoin récurrent dans le reporting financier.

Avec des cubes, on répond à ce besoin facilement car l'ensemble des croisements possibles est généré, même ceux sans valeur.

Avec des tables, opérer par jointures externes n'est pas une solution complète (il suffit d'appliquer un filtre pour que cela referme les jointures...). Pour émuler le cube, il faudrait générer des faits à zéro dans la table de faits, ce que je ne conseillerais pas.

Bref, soit on utilise les cubes, soit on travaille avec un outil de reporting qui parvient à gérer ce genre de reporting au niveau de la couche application.

[bbo1991]

...soit on utilise les cubes, soit on travaille avec un outil de reporting qui parvient à gérer ce genre de reporting au niveau de la couche application

Pour info je travaille essentiellement avec BO. Dans le cas de cet outil je ne vois pas d'autre solution que de mettre des jointures externes dans la définition de mon univers.
Tu peux me donner un exemple précis de ce que tu proposes?

[Paul_S]

Il me semble qu'Yphilogène pense à cognos qui génère des cubes dans un format propriétaire. Il offre la possibilité de générer des lignes comportant des métriques à zéro, si non existant.
Une jointure externe au sein d'un outil de reporting produit le même résultat.

[yphilogene]

Pardon pour le manque de réactivité.

Une jointure externe ne produit pas exactement le même résultat qu'une ligne de fait vide, pour la raison que j'explicite dans mon post précédent.

Avec B.O., comme avec Cognos Framework Manager, tu ne parviendras pas à obtenir le même résultat qu'un cube avec des jointures externes, pour la bonne et simple raison que le cube, au moment de sa génération, fabrique tous les croisements possibles compte tenu du contenu des dimensions. Pour obtenir un résultat similaire avec des tables, il faudrait générer tous les croisements possibles dans ta table de faits, ce que je te déconseille fortement.

Pour répondre à ta question: fait des jointures externes au niveau de tes requêtes de restitution.

[bbo1991]

Comme quoi la simulation de cube avec les univers a ses limites...

Je suis vos conseils en écartant l'hypothèse des lignes de fait vides, ce qui je pense clôt cette discussion.

Merci

[doc malkovich]

oups, désolé, je suis nouveau venu, et je commencais par cette discussion très intéressante, et je me permettrais d'apporter une précision sur les méthodes de rajout de lignes à 0 dans BO ...

Il n'y a pas que les jointures externes dans l'univers pour avoir des "lignes à 0", moi je rajoute des fournisseurs de données qui donnent l'exhaustivité des tables de dimension ( un par dim ), qui sont synchronisés avec les requêtes principales, ensuite en prenant la nouvelle dimension, des lignes vides apparaissent, il suffit de jouer avec le format d'affichage ( partie nul ) ou de rajouter 0 à l'indicateur pour avoir des lignes à 0.
Pour moi c'est d'ailleurs la meilleure méthode, car les jointures externes posent généralement problème dans un modèle en étoile sous oracle.
On peut aussi générer des lignes à 0 avec des requetes combinées et indicateurs à 0, c'est plus sûr pour les migrations mais plus lourd au niveau des fournisseurs de données.

[bbo1991]

Il n'y a pas que les jointures externes dans l'univers pour avoir des "lignes à 0", moi je rajoute des fournisseurs de données qui donnent l'exhaustivité des tables de dimension ( un par dim ), qui sont synchronisés avec les requêtes principales, ensuite en prenant la nouvelle dimension, des lignes vides apparaissent, il suffit de jouer avec le format d'affichage ( partie nul ) ou de rajouter 0 à l'indicateur pour avoir des lignes à 0.
Pour moi c'est d'ailleurs la meilleure méthode, car les jointures externes posent généralement problème dans un modèle en étoile sous oracle.
On peut aussi générer des lignes à 0 avec des requetes combinées et indicateurs à 0, c'est plus sûr pour les migrations mais plus lourd au niveau des fournisseurs de données.

Ta solution m'intéresse énormément car la gestion des jointures externes est sujet à problème Oracle ou pas.
Mais là j'avoue n'avoir vraiment pas compris ta méthode.
Tu pourrais ré expliquer avec un cas concret stp?

[Jean_Paul_XX]

Dans le cadre d'une analyse multidimensionnelle, nous distinguons deux types de données :
- Des Axes d'analyse (hiérarchisés ou non)
- Des données métriques (des faits)
Un axe d'analyse est Référent. C'est à dire qu'il contient toutes les valeurs possible et envisageables de l'axe. A l'inverse, il peut ne pas exister de données métriques pour une valeur donnée de cet axe.
Exemple : Axe Géographique, niveau Département. Il peut ne pas exister de CA pour un département donné (il n'y a pas eu de ventes).
Dans la restitution mise en oeuvre, cela se traduit par une absence de ligne concernant le département ou il n'y a pas eu de ventes; donc un 'trou', qui pose des problèmes :
- Quand on compare visuellement les graphes de A et A-1,
- Quand on met en oeuvre un indicateur d'évolution d'une ligne par rapport à la précédente ...

Pour palier à ce problème, on peut forcer une Complétude sur l'axe d'analyse considéré. Dans ce cas, la restitution comportera autant de lignes qu'il existe de départements dans l'axe d'analyse, sans remplir les données métriques correspondantes (le CA est à Null). Il est ensuite possible avec un masque d'affichage d'interpréter fonctionnellement cette valeur nulle en fonction de la donnée, du contexte ...
L'exécution de ce processus s'effectue bien entendu dans le Dataset restitué, sans intervention sur la/les bases de données pointées.

Cette fonctionnalité diffère donc de la jointure externe, dans la mesure ou l'on traite ici une complétude totalement exhaustive, par rapport à un axe de référence.

[bbo1991]

J'aimerai remettre cette discussion sur le tapis car je suis retombé sur un cas qui relève de la question.

Mon contexte:
- une table de fait "vente"
- une table de dimension "produit"
- une table de dimension "responsableMarketing"
- une table de dimension "année"


Petite subtilité :
chaque produit se trouve sous la responsabilité d'un responsable, un responsable peut s'occuper de plusieurs produits, et l'affectation d'un produit à un responsable marketing change d'une année à une autre.

On doit mettre en place une hiérarchie: Responsable >> Produit, de manière à ce que l'on puisse faire un drill down/up et retrouver facilement les produits sous la responsabilité de Monsieur x (ou l'inverse).

Mes tables de dimensions n'ont aucune liaison entre elles, j'ai un schéma en étoile tout ce qu'il y a de plus classique avec le fait vente au milieu et les dimensions tout autour qui lui sont liées.

Maintenant abordons la phase d'alimentation

Supposons que je n'insère dans ma table de fait que les ventes qui ont réellement eu lieu sur mes quatres produits en 2007:
- le produits A sous la responsabilité de Mr X s'est vendu à 3 exemplaires
- le produits B sous la responsabilité de Mr X s'est vendu à 2 exemplaires
- le produits C sous la responsabilité de Mr Y s'est vendu à 10 exemplaires
- le produits D sous la responsabilité de Mr Y ne s'est vraiment pas vendu (donc aucune ligne insérée dans la table de fait "vente").

Maintenant :
- si je veux voir le montant des ventes pour chaque produit: je pourrais toujours faire une jointure externe entre la dimension produit et la table de fait vente, ce qui me ramènera tous mes produits avec NULL comme montant des ventes du produit D

- mais si je veux lister les produits sous la responsabilité de Mr Y ???
Si je fais une jointure entre les tables "ResponsableMarketing - Vente - Produit" et ça me ramènera le produit C seulement.
Si je remets en jeu le coup des jointures externes entre la table de fait et la dimension produit ça va me ramener tous les produits.

Le plus simple serait d'alimenter la table de fait avec une ligne où vente = NULL pour le produit D et le responsable Monsieur Y non?

[ygrim]

Salut,
Exuses ma remarque... Tu n'essayerais pas de recréer le fonctionnement d'un cube avec tes requêtes ?
Pourquoi ne créé tu pas un cube avec Mondrian ou SSAS (si vous avez l'argent pour). Tout serais tellement plus facile

[Jester]

Tu as une table de faits vente et tu essaie d'en sortir la relation de responsabilité entre un produit et un responsable. Forcément, toute l'information n'y est pas.

A mon avis, cette relation devrait être une nouvelle table de faits liant la dimension responsable, année et produit. Tu peux la dériver partiellement de la table de faits vente, mais tu n'aura pas toutes les infos. Il faut donc trouver une source de données qui te dise quel produit va à quel responsable et quelle année. SI ça n'existe pas il y aura un responsable 'inconnu'.

De plus cette table de fait responsabiliteProduit pourra permettre de vérifier s'il n'y a pas d'erreur dans la table de fait vente.

[bbo1991]

Pourquoi ne créé tu pas un cube avec Mondrian ou SSAS (si vous avez l'argent pour).

Hélas les aléas du marketing étant ce qu'ils sont le client a acheté des licences Business Objects qu'il faut bien rentabiliser .
Mais l'objectif est bien de recréer le fonctionnement d'un cube OLAP avec un univers BO.

A mon avis, cette relation devrait être une nouvelle table de faits liant la dimension responsable, année et produit. Tu peux la dériver partiellement de la table de faits vente, mais tu n'aura pas toutes les infos. Il faut donc trouver une source de données qui te dise quel produit va à quel responsable et quelle année. SI ça n'existe pas il y aura un responsable 'inconnu'.

J'aime bien cette solution mais dans ce cas ce ne serait pas vraiment une table de fait puisqu'il n'y aurait aucun fait mesurable dans cette table !!!
Ce serait plutôt une table de correspondance qui ferait la liaison entre Produit-Responsable Marketing-Année.
Ce qui me dérange un peu en fait c'est que ça me fait penser à un principe utilisé dans un schéma normalisé, je m'explique: dans la base de données de production du client il existe une telle table table dont la fonction est justement de faire la liaison Produit-Responsable Marketing-Année.
Donc à mon avis ça revient à reproduire dans mon schéma en étoile une partie du schéma normalisé source!!!

[brunolf]

Une table de faits sans faits n'a rien de choquant dans un modèle dimensionnel.

[Jester]

Oui, ce n'est pas une table de fait, j'utilise le terme même si c'est des "faits" où on fait un count (car c'est équivalent à une somme de constantes 1). L'idée n'étant pas uniquement de faire des relations, mais aussi d'en extraire des statistiques.

L'idée n'est pas de l'utiliser pour faire des requêtes sur la table ventes. Tout est aussi dans vente si besoin. C'est en cela que ce n'est plus normalisé.

[bbo1991]

OK ça m'a l'air d'être un solution raisonnable.
Topic re-résolu