Conseil 51: Dernières réflexions sur les dimensions Temps

Virtuellement chaque table de faits possède une ou plusieurs clés étrangères liées à la dimension Temps. Les mesures sont prises à un moment précis et la plupart d'entre elles sont répétées au cours du temps.

La dimension de temps la plus courante et utile est la dimension Calendrier (ou date) avec une granularité au jour. Cette dimension à beaucoup d'attributs. Mais seulement peu d'entre eux (comme le nom du mois ou l'année) peuvent être générées directement par une fonction SQL. Les vacances, les jours ouvrés, les périodes fiscales, les numéros de semaines, l'indicateur de dernier jour du mois, et d'autres attributs de navigation doivent être présents dans cette dimension Calendrier et toutes les dates nécessaires à la navigation devraient être implémentées dans les applications en utilisant les attributs de la dimension. La dimension Calendrier possède quelques propriétés inutiles. C'est l'une des seules dimensions qui est complètement créée au début du projet d'entrepôt de données. Elle n'a pas de source de données conventionnelle. La meilleure façon pour créer la dimension Calendrier est de passer une après midi avec un tableur et de la créer à la main. Dix ans représente moins de 4 000 lignes.

Conseil 50: Tables de faits sans faits?

Les tables de faits sans faits semblent être un oxymore, un peu comme des crevettes géantes. Comment pouvez vous avoir une table de faits qui n'ait pas de faits? Dans ce conseil, nous utilisons une table de faits sans faits pour compléter nos stratégies de dimensions à évolution lente.

Pour rappel, une table de faits sans faits capture les relations plusieurs-à- plusieurs entre des dimensions, mais ne contient aucun faits numérique ou textuel. Elles sont souvent utilisées pour enregistrer des événements ou couvrir une information. En voici quelques exemples:

• identifier les promotions sur les produits (pour voir les produits en promotion qui ne se vendent pas)
• suivre l'assiduité des étudiants ou les inscriptions
• suivre les accidents pour les assurances
• identifier les bâtiments, installations et équipements annexes pour un hôpital ou une université

Conseil 49: retour aux sources

Lorsque nous avons écrit "Data warehouse: le guide de conduite de projet", nous avons nommé notre approche le cycle de vie dimensionnel. Nous avons choisi ce nom pour renforcer nos principes à propos des entrepôts de données qui fonctionnent basés sur nos différentes expériences acquises depuis le milieu des années 80:

Conseil 48: Organiser à l'aide de dimensions fourre-tout

Lorsque nous développons un modèle dimensionnel, nous rencontrons souvent divers indicateurs et flags qui ne sont pas liés logiquement avec les principales dimensions. Ces attributs disparates sont généralement trop précieux pour les ignorer ou les exclure. Les concepteurs veulent parfois les traiter comme des faits ou déformer le schéma avec plusieurs dimensions de petites tailles. Une troisième solution, moins évidente mais préférable, est d'inclure une dimension fourre-tout pour stocker ces champs.

Conseil 47: Relations entre les initiatives stratégiques et les processus métiers

L'une des questions qui est fréquemment posée lors des ateliers analytiques est "quel est la relation entre l'initiative stratégique d'une entreprise (qui est la direction vers laquelle doit se concentrer le métier) et le processus métier (qui est la base sur laquelle je construis l'entrepôt de données)?"

Les initiatives stratégiques de l'entreprise sont des plans à grande échelle, défendus par la haute direction, pour fournir un avantage compétitif ou financier important, irrésistible et perceptible à l'organisation. Une initiative stratégique d'entreprise a généralement un objectif financier mesurable et un délai de livraison de 12 à 18 mois. Comprendre les initiatives stratégiques de l'organisation est le point de départ d'un projet d'applications analytiques car cela assure que le projet délivre quelque chose de valeur - ou de pertinent - aux utilisateurs.