Conseil 57: Traiter les faits qui arrivent en avance

Les entrepôts de données sont généralement construits autour de l'hypothèse idéale que l'activité mesurée (les enregistrements des faits) arrive dans l'entrepôt de données en même temps que le contexte qui lui est associé (les enregistrements des dimensions). Lorsque nous avons à la fois les enregistrements des faits et ceux des dimensions corrects, nous avons le luxe de comptabiliser les clés de la dimension en premier, puis d'utiliser celles-ci dans les enregistrements de la table de faits qui l'accompagne.

Fondamentalement, trois choses peuvent se produire quand nous comptabilisons les enregistrements de la dimension.

1. Si l'entité de la dimension (par exemple Client) est un nouveau membre de la dimension, nous attribuons une nouvelle clé de substitution dans la dimension.
2. Si l'entité de la dimension est une version révisée d'un client, nous utilisons la technique de la dimension à évolution lente de type 2 pour attribuer une nouvelle clé de substitution et stocker la description du client qui a été mis à jour dans un nouvel enregistrement de la dimension.
3. Enfin, si le client est un élément familier et inchangé de la dimension, nous utilisons simplement la clé de la dimension que nous avons déjà pour ce client.

Conseil 55: Explorer des faits textuels

Dans cet article, nous revenons sur un concept fondamental qui déconcerte de nombreux modélisateurs décisionnels: les faits de type texte.

Certains d'entre vous observerons à juste titre que les faits de type texte sont un oxymore de la modélisation décisionnelle. Toutefois, nous avons souvent à répondre aux questions de clients et d'étudiants sur des champs indicateur, type ou commentaire qui semblent appartenir à la table de faits, mais dont les valeurs ne sont pas assimilées à des clés, des mesures ou des dimensions dégénérées.

Conseil 54: Fournir la vue courante et la vue historique d'une dimension

Comme la plupart des choses dans la vie, le changement est inévitable, même avec les attributs des dimensions. La plupart de nos lecteurs sont familiers avec les trois techniques de dimension à évolution lente (SCD):

• Type 1: Remplacement d'attribut 
• Type 2: Ajout d'une autre ligne dans la dimension 
• Type 3: Ajout d'un autre attribut dans la dimension

Quand des attributs de dimensions changent, nous sommes souvent sollicités pour conserver leurs valeurs précédentes, ainsi que pour fournir la possibilité de croiser les faits historiques avec les valeurs courantes des attributs. La demande pour cette aptitude augmente au fur et à mesure que les utilisateurs mûrissent leurs analyses. Il y a vingt ans, les analystes étaient satisfaits d'avoir des tables de dimensions qui étaient rafraîchies (écrasé) avec les valeurs d'attributs courantes à chaque chargement. Puis le mouvement c'est inversé pour capturer avec précision tous les changements en utilisant les dimensions à évolution lente de type 2. Maintenant, plus de gens veulent avoir le beurre et l'argent du beurre.

Conseil 53: Embellissement de dimension (mini-dimension et agrégation)

Lors du développement de modèles dimensionnels, nous nous efforçons de créer des tables de dimensions solides composées d'un ensemble d'attributs descriptifs. Plus les attributs que nous intégrons dans ces dimensions sont pertinents, plus les utilisateurs sont capables d'évaluer leurs activités par des voies nouvelles et créatives. Cela est particulièrement vrai lors de la construction d'une dimension centrée sur le client.

Nous vous encourageons à intégrer le capital intellectuel dans les modèles dimensionnels. Plutôt que d'appliquer des règles métiers aux données au niveau de l'analyse (souvent en utilisant Excel), les dérivations et les regroupements nécessaires par l'entreprise doivent être capturés dans les données pour qu'elles soient cohérentes et facilement partagées entre les analystes indépendamment de leurs outils. Bien sûr, cela nécessite de comprendre ce que l'entreprise fait avec les données avant et après leurs capture dans la source opérationnelle. Cependant, c'est grâce à cette compréhension et l'ajout d'attributs dérivés (et de mesures) que l'entrepôt de données apporte une valeur ajoutée.

Conseil 52: Améliorons nous procédures opérationnelles

Dans ma carrière, j'ai été en mesure d'examiner un grand nombre d'entrepôts de données, à différents stades de leur cycle de vie. J'ai observé que, de façon générale, nous n'avions pas la même rigueur dans le fonctionnement du système d'entrepôt de données que les personnes en charge du système transactionnel peuvent attendre de leurs systèmes. En toute équité, un entrepôt de données n'est pas un système transactionnel, et peu d'entreprises peuvent justifier un contrat de service 24x7 pour l'accès à l'entrepôt de données. Mais Allez les gars, faut-il ressembler à des chiens fous en cas d'urgence? Comme nous le savons tous, les problèmes arrivent - surtout lorsqu'un entrepôt de données est en aval de tout autre système dans votre entreprise.

Exploiter un entrepôt de données de manière professionnelle n'est pas si différent des autres systèmes: Suivre les bonnes pratiques, prévoir les catastrophes, et s'entraîner. Voici quelques suggestions simples, basées sur mes observations des déploiements actuels.

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.