J'ai un ensemble de cubes OLAP, sous la forme d'un schéma de flocon de neige, chacun représentant une usine.Est-il possible d'avoir des agrégateurs de dimension OLAP conditionnels?
J'ai trois concepts qui, pour certaines usines, se comportent clairement comme 3 dimensions, et pour d'autres usines se comportent clairement comme 2 dimensions.
Les concepts sont toujours les mêmes: "produits", "agents de vente" et "clients".
Mais pour certains cas, je doute que je devrais le modéliser comme un cube purement tridimensionnel ou je devrais jouer avec un tweak ou un truc avec un cube bidimensionnel.
Les cas A et B sont ceux qui sont clairs pour moi, et Cas C est celui qui génère mes merveilles.
CASE A: Il est clair qu'un cube 3 dimensions
Tout agent peut vendre un produit à toute entreprise. Plusieurs agents sont resposables ensemble pour le même ensemble de clients.
I modèle ce cas comme ceci:
CASE B: Il est clair qu'un 2 cube dimensions
Chaque agent est 'responsable' d'un portefeuille de clients, et il peut vendre n'importe quel produit mais seulement à ses clients. L'analyse porte sur la «responsabilité actuelle du portefeuille». Ainsi, si un agent quitte l'entreprise, tous ses clients sont réaffectés à un nouvel agent et le client appartient uniquement au nouvel agent.
I modèle ce cas comme ceci:
AFFAIRE C: Mes doutes
Un client peut avoir été attribué un seul agent ou un ensemble de plusieurs agents chacun être responsable d'une catégorie de produits.
Par exemple:
AlicegèreTablesAndWoods ltdetGreenForest ltd.BobgèreChairs ltdetFastWheels ltd.CarolgèreForniture ltdSEULEMENT pourProductType = 'machinery'et gère égalementFrozenBottles ltdpour tout type de produit.Davegère égalementForniture ltdmais seulement pourProductType = 'consumables'et gère égalementHighCeilings ltdpour tout type de produit.
QUESTION:
Dans cet exemple "l'affaire C":
Sont customer et agent dimensions indépendantes parce que Forniture ltd a une relation à la fois à Carol et Dave, il est donc un cube en 3D?
Ou est-ce un cube 2D, où agent n'est pas une dimension indépendante, mais est un agrégateur de customer "conditionné" en quelque sorte par l'agrégateur ProductCategory?
Je voudrais voir comment modéliseriez-vous ceci. Merci d'avance.
Je n'ai pas besoin de préserver l'historique, et même pour l'exemple Date n'apparaît pas là. Donc, même Type1 est okey. Je peux envisager de "s'effondrer". Le problème est que je ne sais pas comment modéliser cette «table de bridge» que vous mentionnez dans un concept OLAP-Cube. J'utilise des tables de bridge pour des many-to-many dans des bases de données relationnelles normales, mais je ne sais pas comment les utiliser dans les "bras" de l'étoile ou du flocon de neige afin qu'elles soient utiles pour une approche OLAP. –
La meilleure ressource sur les techniques de modélisation dimensionnelle est le forum Kimball. Plutôt que de résumer le travail de quelqu'un d'autre, voici un lien qui vous mènera à l'information dont vous avez besoin. [link] http://forum.kimballgroup.com/search?search_keywords=bridge+two+dimensions –
Aussi, vous pourriez vouloir repenser votre besoin de dates. C'est ainsi que vous allez gérer le changement de relation entre l'agent et le client. Il est presque inconcevable qu'un modèle dimensionnel ne contienne pas de table de dates, et vos dimensions semblent avoir des attributs qui pourraient changer avec le temps, modifiant le cumul des données. Les exemples sont les clients qui peuvent changer d'emplacement, les produits susceptibles de changer de catégorie et les agents susceptibles de changer de gestionnaire. Bien sûr, vous connaissez mieux vos besoins que moi, mais je serais étonné si vos utilisateurs ne vous frappent pas avec des questions comme celle-ci une fois le cube construit. –