Structure de base de données optimale pour MicroStrategy

Question

J'ai passé la majeure partie de ma carrière en développant les marts des entrepôts de données comme Star Schemas parce qu'ils étaient généralement utilisés conjointement avec les services d'analyse de Microsoft. Cependant, nous commençons à tirer parti de MicroStrategy 9.0.1, et on m'a dit que Star Schemas ne sont pas optimales pour cette plate-forme. MicroStrategy n'a pas de position officielle sur ce sujet donc je pensais que je demanderais à cette communauté. Dois-je continuer à utiliser les structures dénormalisées, ou devrais-je envisager une approche plus normalisée reagards à cette plate-forme?

Mon intention est de ne pas commencer un contre Inmon vs Kimball guerre etc, toute expérience du monde réel serait apprécié

Answer 1

Son fait pas un gros problème en utilisant des schémas en étoile avec MicroStrategy. Il faut juste un peu pour s'y habituer, et il génère des requêtes fines avec ce format.

D'un consultant MSTR très aguerri, je l'ai entendu la forme de données MSTR aime vraiment est une sorte de flocon de neige modifié. Lorsque les dimensions de données sont modélisés comme un flocon de neige, mais chaque niveau contient les données des tables dans la hiérarchie au-dessus.

Je pense que vous pouvez voir le modèle dans le projet JumpStart. Situé ici: http://www.microstrategy.com/BI-application-jumpstart/

En fin de compte, je pense que vous devriez continuer avec les techniques qui fonctionnent le mieux pour vous. La configuration du modèle de données logique ne devrait pas être trop de problèmes, et MSTR a une tonne de techniques d'optimisation des performances (mise en cache, cubes en mémoire, ...) que vous pouvez appliquer postfaces aux choses de Boostez.

Answer 2

Je travaille pour une banque en Turquie, et nous avons travaillé avec MicroStrategy depuis plus de 3 ans. Nous n'avons plus de 20 différents projets en cours d'exécution sur différentes bases de données, et les différents types de schéma. Lorsqu'ils sont conçus (et mis en œuvre) correctement, MSTR est tout à fait capable de gérer les schémas en étoile, et ne génèrent modérément belles instructions SQL. Se habituer à parent-enfant et la manipulation MSTR recherche / table fait lors de la conception du arcitecture peut être un problème, je dois dire que. Mais une fois que vous obtenez plus, il est très pratique.

Answer 3

J'ai eu le plaisir (ou autre) de travailler avec MicroStrategy pour les huit dernières années. Je pense qu'il serait juste de dire que le produit a été conçu pour être utilisé avec un schéma dans la troisième forme normale. C'est-à-dire, il sera plus facile de modéliser vos objets dans l'outil avec le schéma conçu de cette manière.

Comme Ugur dit, MSTR est tout à fait capable de travailler avec un schéma en étoile et en fonction de vos données, il peut être préférable d'utiliser un schéma en étoile (à des fins de performance), même si la modélisation est un peu (ou beaucoup) plus difficile dans le projet MicroStrategy.

Answer 4

Quand nous avons commencé sur le chemin MicroStrategy en 2007, les consultants MicroStrategy qui nous avons travaillé avec nous a dit qu'un schéma en étoile était ok, mais leur technologie fonctionne le mieux avec un schéma de flocon de neige. La différence est que les dimensions sont normalisées, à savoir au lieu d'une table de dimension du temps, vous avez jour, semaine, mois, tables de dimension trimestre et l'exercice. Parce que nous opérions dans les industries du transport et de la logistique, notre entrepôt de données a eu de nombreuses relations complexes, mais pas un énorme volume de données; un haut « table de téraoctets rapport ». Dans la forme orthodoxe, les deux modèles étoiles et flocons de neige se joindre à des tables de fait que par des dimensions conformes, et pendant un certain temps nous avons considéré un schéma « hybride » avec jointures entre tables de faits. En fin de compte, nous avons choisi une structure d'entrepôt de données normalisées, comme la meilleure solution pour l'entreprise.

Nous avons passé plusieurs mois en développement, et d'affiner nos normes pour les objets de schéma MicroStrategy au-dessus de nos tables d'entrepôt, et a fini par développer des modèles très robustes. Ces modèles ne sont pas bien reconnus, et à ma connaissance pas largement utilisé avec d'autres clients de MicroStrategy. Ils ont généré sql très complexe, et nous avons reçu un excellent temps de réponse, même pour les rapports ad hoc, comme nous l'avons utilisé Netezza comme notre entrepôt de données. Le côté bas était le nombre d'application des objets nécessaires pour suivre le modèle était beaucoup plus élevé que pour les autres modèles, et le niveau d'expertise pour développer de nouvelles mesures a été élevé. Nous avons formé avec succès tous nos utilisateurs de BI à utiliser les mesures existantes (mis au point par l'équipe de spécialistes BI). Cette solution BI / DW est en utilisation active aujourd'hui.

Par conséquent, je soutiens que MicroStrategy n'a pas été construit pour un schéma d'entrepôt de données normalisées, bien que leur technologie est très solide et suffisamment robuste pour fonctionner sur la base de données telle. Leur modèle préféré est flocon de neige, avec des tables de dimensions normalisées et des tableaux standard de fait.