Conseil 42: Combiner instantanés périodiques et cumulés

Normalement, nous pensons que les instantanés cumulés et les instantanés périodiques sont deux style différents de tables de faits entre lesquelles vous devez choisir pour construire une table de faits autour d'une source de données. Souvenez-vous qu'un instantané périodique (comme le résumé mensuel d'un compte en banque) est une table de fait qui enregistre l'activité durant une période de temps répétée et à intervalle régulier. Les enregistrements d'instantanés périodiques sont généralement créés à chaque nouvelle période durant le cycle de vie d'une chose. Les instantanés périodiques sont appropriés pour les processus qui durent longtemps et se déroulent sur plusieurs périodes.

D'un autre coté, Les instantanés cumulés, sont utilisés pour des processus courts, qui ont une début et une fin bien définit, comme une commande qui vient d'être remplie. Pour une commande, nous ferions habituellement un enregistrement pour chaque ligne de la commande, et nous revisiterions l'enregistrement pour le mettre à jour au fur et à mesure de l'avancée de la commande dans le processus. L'instantané cumulé est par définition un instantané de l'état le plus récent de quelque chose et par conséquent les clés étrangères des dimensions et les faits sont, en général, écrasées au fur et à mesure de la progression.

La mise en oeuvre la plus simple d'un instantané cumulé ne donne pas de points intermédiaire dans le cycle de vie d'une commande, par exemple.

Il y a au moins trois moyens de capturer cet état intermédiaire:

1. Geler l'instantané cumulé à intervalle régulier, comme chaque fin de mois par exemple. Ces instantanés périodiques peuvent probablement être dans une table de faits séparée pour éviter de rendre les applications trop compliquées. Ironiquement, cette approche vient de l'arrière pour simuler une interprétation en temps réel d'un instantané périodique (où vous créez un mois roulant à chaud), mais c'est une autre histoire. Les instantanés gelés des commandes peuvent maintenant refléter l'utilisation de dimensions à évolution lente de type 2. Comme dans tout instantané périodique, la bonne nouvelle est que vous savez que vous avez un enregistrement pour la commande chaque mois où la commande est active. La mauvaise nouvelle est que vous pouvez voir les instantanés de la commande à la fin du mois seulement.
2. Geler l'instantané cumulé et le conserver dans une seconde table de faits si et seulement si un changement a eu lieu dans la commande. Cela donne un historique complet d'une commande. Il a le même nombre d'enregistrement que dans l'option suivante.
3. Maintenir une table de faits à la transaction sur les lignes de commandes. Ajouter une dimension Transaction pour cette table de faits pour expliquer chaque changement. C'est très général comme cela vous pouvez voir chaque action qui a eu lieu sur une commande, mais soyez prudent. Certaines de ces transactions ne sont pas additives au cours du temps. Par exemple, si une ligne produit d'une commande est supprimée et deux autres lignes la remplace, c'est une calcul complexe de reconstruire correctement la commande à un moment donnée dans le temps après ces transactions. C'est pourquoi l'option 2 semble être la meilleure si vous avez besoin de voir l'état intermédiaire d'une commande complète.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #42: Combining periodic and accumulating snapshots", publié le 7 janvier 2003.

Conseil 41: Creuser dans une matrice de bus plus détaillée

Beaucoup d'entre vous sont déjà familiers avec l'architecture de bus décisionnel et la matrice correspondante fournissant un rôle central dans la construction de data-marts architecturés. La matrice de bus identifie les processus métiers clés d'une organisation, ainsi que leurs dimensions associées. Les processus métiers (correspondant généralement aux principales sources de données) sont listés en lignes dans la matrice, alors que les dimensions apparaissent en colonne. Les cellules de la matrice sont ensuite cochées pour indiquer quelles dimensions sont utilisées par quels processus.

Conseil 40: Structure d'une application analytique

Un environnement d'application analytique compréhensible à besoin de fournir un cadre qui transporte les utilisateurs au delà des simples rapports standards. Cet environnement doit les guider de manière proactive à travers l'analyse d'une situation métier, pour les aider à prendre une décision pertinente et réfléchie. Les buts du cycle de vie de cette application analytique sont:

• La proactivité guide les utilisateurs au delà des rapports basiques
• Identifier et comprendre les situations où la performance est exceptionnelle
• Capturer les meilleures pratiques de prise de décision pour chaque situation où la performance est exceptionnelle
• Partager le résultat des meilleures pratiques ou le connaissance à travers l'organisation

Conseil 39: l'architecture de bus décisionnel pour les applications analytiques

Dans notre conseil précédent, nous avons exploré les leviers industriels qui existent derrière le battage actuel sur les applications analytiques. L'un de ces leviers est la large acceptation de la modélisation dimensionnelle comme discipline mature liée aux entrepôts de données centrés sur l'entreprise. Les modèles dimensionnels facilitent l'exploration analytique en fournissant une haute performance et un environnement simple à utiliser pour identifier les pertes de performance ainsi que leurs causes.

Il existe deux exigences supplémentaires imposées à l'architecture d'entrepôt de données pour soutenir efficacement les applications analytiques.