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.

Conseil 46: Un autre regard sur les dimensions dégénérées

Nous parlons souvent des dimensions dégénérées dans nos ateliers de modélisation. Les dimensions dégénérées sont sources de confusion à cause du fait qu'elles ne ressemblent pas à des dimensions normales. Cela peut aider de se souvenir que les dimensions dégénérées se réfèrent à quelque chose qui 1) vient de la norme standard, ou 2) est mathématiquement plus simple.

Une dimension dégénérée agit comme une clé de dimension dans la table de faits, cependant elle n'est liée à aucune dimension parce que tous ces attributs dignes d'intérêts sont déjà dans d'autres dimensions. Parfois, les gens font références aux dimensions dégénérées comme des faits textuels, mais ce ne sont pas des faits parce que la clé primaire de la table de faits comprend la dimension dégénérée ainsi qu'une ou plusieurs autres clés étrangères de dimensions.

Conseil 45: Techniques pour modéliser la connaissance

L'un des plus gros défis dans le déploiement d'analyses est que la connaissance reste cachée dans les outils qui sont utilisés pour construire les analyses. Une fois que la connaissance est emprisonnée dans l'un de ces outils, il devient difficile de partager cette logique de prise de décision avec les utilisateurs qui pourraient utiliser différents outils de requêtage et de reporting.

Je définis la connaissance comme les meilleures pratiques de l'entreprise pour une activité métier bien définie. Par exemple, quel est le meilleur moyen d'analyser l'introduction d'une nouvelle extension à une ligne de produit comme un nouveau gout pour un dentifrice, sur le marché des biens de consommation? Cela n'inclus pas seulement les données et les mesures, mais aussi ce qui constitue la performance normale pour chacun des métriques de support. Toute performance en dehors de 2 ou 3 déviations standard de la base pourrait être considéré comme exceptionnel. Je voudrais ensuite essayer de comprendre quel sont les mesures principales comme les écarts de prix par rapport à la concurrence, les ventes, la quantité et la qualité d'un support de vente, toute mesure de sortie de stock ou de distribution, d'inventaire, d'affichage, de coupons qui étaient en dehors des valeurs acceptables.

Conseil 44: Ne soyez pas trop dépendant des métadonnées de vos outils d'accès aux données

"Oh, nous verrons cela dans l'outil" est le refrain que nous entendons parfois des équipes de conception. A la place, à chaque fois que c'est possible, nous suggérons d'investir les efforts pour construire une information descriptive plus flexible et plus riche directement dans les schémas dimensionnels plutôt que de nous appuyer sur les fonctionnalités de l'outil de métadonnées.

Les outils de business intelligence d'aujourd'hui fournissent des métadonnées solides pour supporter un grand nombre de fonctionnalités, comme la substitution de libellés, les calculs prédéfinis, et la navigation agrégée. Cela est utile pour vos utilisateurs. Mais, nous avons besoin d'être judicieux dans l'utilisation des fonctionnalités que ces outils fournissent. Trop souvent les équipes de conceptions prennent des raccourcis et comptent sur les métadonnées des outils d'accès aux données pour résoudre les problèmes qui seraient mieux traités dans nos modèles dimensionnels. Au final, les règles métiers sont intégrées dans les métadonnées de l'outils plutôt que dans nos schémas. Nous avons également vu des équipes utiliser les métadonnées des outils pour fournir le code des vues et des descriptions des indicateurs afin de conserver leur schéma plus petit.

Conseil 43: Traiter les valeurs nulles dans le modèle dimensionnel

La plupart des bases de données relationnelles utilisent la valeur Null pour représenter une absence de données. Cette valeur peut perturber les développeurs d'entrepôts de données et les utilisateurs parce que la base de données traite les valeurs nulles différemment des valeurs à blanc ou des zéros, même si elles ressemblent à des blancs ou des zéros. Ce conseil explore trois exemples où nous trouvons des valeurs nulles dans notre source de données et faisons des recommandations sur la manière de faire face à chaque situation.

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.

Conseil 38: qu'est ce qu'une application analytique

Il y a de nombreuses discussions sur la nouvelle "coqueluche" de la communauté décisionnelle ... les applications analytiques. Les applications analytiques promettent de livrer une nouvelle valeur métier pour les organisations qui ont déjà fait d'importants investissements dans leur infrastructure et leurs compétences en matière d'entrepôt de données. Mais qu'entendons-nous quand nous disons "application analytique"? Et quelles sont les évolutions récentes dans l'industrie qui ont conduit à tout ce battage sur les applications analytiques?

Conseil 37: Modéliser le suivi d'un processus à l'aide d'une table de fait de type instantané cumulé

Rappelez-vous qu'une table de faits est un endroit où nous stockons des mesures émanant d'un processus métier particulier. Les tables de dimension entourent et décrivent ces mesures.

Rappelez-vous aussi que le grain d'une table de fait est la définition exacte de ce qu'un enregistrement d'un fait représente. Il est certainement vrai que la clé d'une table de fait définit le grain, mais souvent la déclaration la plus claire du grain est un concept métier plutôt qu'une liste technique de clés étrangères. Par exemple, le grain d'une table de fait représentant un processus de prise de commande peut être "la ligne d'un produit sur une commande", alors que la définition technique de la clé de cette table peut être "numéro de facture par produit par promotion".

Conseil 36: Etre ou ne pas être (centralisé)

Contrairement à William Shakespeare et certains experts de l'industrie des entrepôts de données, ce n'est pas la question.


Dans cet article, nous discutons d'un problème rencontré dans les environnements d'entrepôts de données et de data-marts matures. Alors que certaines organisations sont des nouveaux venus dans cet univers, d'autres sont là depuis un certain temps. Et bien que le marché arrive à maturité, la cause de souffrances que provoque les entrepôt des données au sein des organisations IT est liée à son évolution. Récemment, la centralisation a été promue comme le dernier élixir miracle. La centralisation est revendiquée pour transformer les data-marts indépendants et hétérogènes en "or", en réduisant les coûts d'administration et en améliorant la performance. Alors que la centralisation "peut" offrir une certaine efficacité opérationnelle, elle ne traite pas en soi les grandes questions d'intégration et de cohérence.

Conseil 35: Modéliser les intervalles de temps

Au cours des deux dernières années, j'ai vu une augmentation de la demande pour les applications qui ont besoin de poser des questions sur des intervalles de temps. Une personne a le fait quand il dit: "chaque enregistrement dans ma table de fait est un épisode de valeur constante dans un laps de temps". Un intervalle de temps peut démarrer et s'arrêter à des points arbitraires dans le temps. Dans certains cas, des intervalles de temps peuvent être liés pour former une chaîne ininterrompue, dans d'autres cas, ils sont isolés, et dans le pire des cas, ils se chevauchent arbitrairement. Mais chaque intervalle de temps est représenté dans la base de données par un seul enregistrement. Pour faciliter la visualisation de ces variations, imaginons que nous avons une base de données remplie de transactions atomiques, comme les dépôts et les retraits de comptes bancaires. Nous incluons également les transactions d'ouverture et de fermeture de compte. Chaque transaction définit implicitement un épisode de valeur constante dans un intervalle dans le temps. Un dépôt ou un retrait définit une nouvelle valeur pour le solde du compte qui est valable jusqu'à la prochaine transaction. Ce laps de temps pourrait être une seconde ou plusieurs mois. La transaction d'ouverture de compte définit le statut du compte comme actif en permanence sur un laps de temps jusqu'à ce qu'une transaction de fermeture de compte apparaisse.

Conseil 34: Vous n'avez pas besoin d'entrepôt de données d'entreprise

Un "entrepôt de données d'entreprise" (EDW pour Enterprise Data Warehouse) est le nom d'une approche de conception. L'architecture EDW diffère sensiblement de celle du bus décisionnel. L'EDW incarne un certain nombre de thèmes connexes qui doivent être mis en comparaison avec l'approche du bus décisionnel. Il peut être utile de séparer les questions logiques des questions physiques pour le moment.

Logiquement, les deux approches préconisent un ensemble cohérent de définitions qui rationalisent les différentes sources de données dispersées dans l'organisation. Dans le cas du bus, les définitions importantes concernent principalement les dimensions conformes et les faits conformes. Avec l'approche EDW, la cohérence semble beaucoup plus amorphe. Cela repose sur le fait que si vous avez un modèle Entité/Relation hautement normalisé unique de toutes les informations de l'entreprise, vous savez alors comment administrer des centaines ou des milliers de tables de manière cohérente. Mais, dépassant ce manque de précision, on pourrait soutenir que les deux approches sont du même avis jusqu'ici. Les deux approches visent à appliquer des règles cohérences pour unifier toutes les sources de données distribuées.

Conseil 33: Transformer les mesures du CRM en étiquette de comportement

Nous allons décrire un exemple simple et classique d'attribution d'étiquette de comportement à des modèles complexes de micro-transactions découlant de processus qui interagissent avec  les clients, tels que les centres d'appels, les visites de sites web, les systèmes de livraison, et les systèmes de réconciliation de paiement. Nous allons utiliser nos techniques de reporting d'entrepôt de données standard pour synthétiser trois indicateurs de comportement des clients: récence, fréquence et intensité. La récence mesure la façon dont nous avons récemment collaboré avec le client. Prenons un point de vue large et analysons toute transaction issue des processus que nous avons mentionné ci-dessus. La mesure réelle de récence est le nombre de jours écoulés depuis le dernier contact avec le client.

De même, la fréquence mesure combien de fois nous avons interagi avec le client, reprenant la même perspective que ci-dessus. Et enfin, l'intensité mesure la productivité des interactions qui ont eu lieu. La mesure la plus évidente de l'intensité est le montant total des achats, mais peut-être que le nombre total de pages Web visités est une bonne mesure de l'intensité également.

Conseil 32: Faire le travail lors de la phase d'extraction

Notre mission en tant que concepteurs d'entrepôt de données est de publier des données le plus efficacement. Cela signifie placer les données dans le format et le cadre qui est le plus facile à utiliser pour les utilisateurs finaux et les développeurs d'applications.

Dans l'arrière-salle de notre entrepôt de données, nous devons lutter contre nos tendances minimalistes naturelles lorsque nous préparons les données relatives à la consommation finale par les utilisateurs finaux et les développeurs d'applications. Dans de nombreux cas importants, nous devrions accepter:

• l'augmentation des processus d'alimentation
• l'augmentation des besoins de stockage

en échange de:

• schémas symétriques et prévisible que les utilisateurs comprennent
• la réduction de la complexité de l'application
• l'amélioration des performances des requêtes et des rapports

La réalisation de ces compromis devrait être un objectif évident pour l'architecte d'entrepôt de données. Un bon architecte d'entrepôt de données résistera à l'envie de déléguer les analyses supplémentaires et la manipulation de tables aux utilisateurs finaux et aux concepteurs d'applications. Méfiez-vous des vendeurs qui militent en faveur de schémas complexes! Mais bien sûr, ces compromis doivent être choisis judicieusement. Regardons une demi-douzaine de situations où nous faisons juste assez de travail au moment de l'extraction pour vraiment faire une différence. Nous allons aussi essayer de définir quelques limites, afin de savoir quand il ne faut pas trop en faire pour éviter de gâcher le résultat final. Nous allons commencer par quelques petits exemples puis nous étendrons progressivement notre périmètre.

Conseil 31: Conception d'une partition en temps réel

Même si l'écart de temps entre les systèmes OLTP de production et l'entrepôt de données a diminué dans la plupart des cas, à 24 heures, les besoins avides de nos utilisateurs du marketing nécessitent que l'entrepôt de données comble cette lacune avec des données en temps réel.

La plupart des concepteurs d'entrepôts de données sont sceptiques quant à exécuter les taches d'alimentation existantes de l'ETL (extract-transform-load) toutes les 15 minutes au lieu de toutes les 24 heures. Les concepteurs d'entrepôt de données répondent à ce problème en construisant une partition en temps réel en face de l'entrepôt de données.

Conseil 30: Mettez vos tables de faits au régime

Au milieu des années 1990, avant internet, il semblait que l'explosion des données pourrait finalement décroître  A cette époque, nous étions en train d'apprendre à capturer chaque appel téléphonique, chaque article vendu à une caisse enregistreuse, chaque transaction d'actions à Wall Street, et toutes les transactions de polices par d'énormes compagnies d'assurance. Il est vrai que nous n'avons pas souvent conservé une très longue période de certaines de ces sources de données dans nos entrepôts de données, mais il y avait un sentiment que peut-être nous avions atteint une sorte de limite physique à la granularité des données. Peut-être que nous avions enfin rencontré les vrais "atomes" des données.

Eh bien, ce point de vue était évidemment faux. Nous savons maintenant qu'il n'y a pas de limite à la quantité de données que nous pouvons recueillir. Chaque mesure peut être remplacée par toute une série de sous-mesures plus fines. Sur le web, dans les Weblogs nous voyons chaque geste effectué par un visiteur avant qu'il regarde et achète un produit. Nous avons remplacé l'enregistrement unique d'achat de produit par une douzaine ou une centaine d'enregistrements de suivi du comportement. Le pire, c'est que les gens du marketing adorent ces enregistrements de suivi du comportement, et ils veulent en faire toutes sortes d'analyses.

Conseil 29: Modifier des dimensions ou des tables de faits existantes

Malgré les meilleurs plans et les meilleures intentions, le concepteur de l'entrepôt de données doit souvent ajouter de nouveaux types de données ou modifier les relations entre les données alors que l'entrepôt de données est en marche. Dans un monde idéal, nous aimerions que ces changements soient "propres" de sorte que les outils de requêtage et de reporting existants continuent de fonctionner sans être modifiés, et que les interfaces utilisateurs existantes affichent les nouvelles données et permettent aux données d'être ajoutés aux requêtes et rapports.

Évidemment, il y a certains changements qui ne peuvent jamais être effectués avec élégance. Si une source de données cesse d'être disponible et qu'il n'existe pas d'autre source compatible pour la remplacer, alors les applications dépendantes de cette source cesseront de fonctionner.

Mais peut-on décrire un ensemble de situations où l'on pourrait effectuer des changements dans notre environnement de données avec élégance?

La symétrie prévisible de nos modèles dimensionnels vient à notre secours. Les modèles dimensionnels sont capables d'absorber d'importants changements dans les données de base et dans nos hypothèses de modélisation sans invalider les applications existantes. Listons autant de changements que nous le pouvons, en commençant par le plus simple.

1. De nouveaux attributs dans une dimension. Si, par exemple, nous découvrons de nouveaux descripteurs textuels pour un produit ou un client, nous ajoutons ces attributs dans la dimension en tant que nouveaux champs. Les applications existantes ne seront pas conscientes des nouveaux attributs et continueront à fonctionner normalement. La plupart des interfaces utilisateurs ne devraient pas remarquer les nouveaux attributs lors de leur exécution. Conceptuellement, la liste des attributs disponibles pour filtrer et faire des regroupements doit être affiché dans un outil de requêtage ou un outil de reporting via une requête sous-jacente du type SELECT NOM_COLONNE FROM SYS_TABLES WHERE NOM_TABLE = "Produit". Ce genre d'interface utilisateur sera continuellement "ajusté" lorsque de nouveaux attributs de dimension seront ajoutés au schéma. Dans une dimension à évolution lente, où les petits changements de versions de la dimension sont maintenus, il faudra prendre soin d'attribuer correctement les valeurs des nouveaux attributs aux différentes versions des enregistrements. Si les nouveaux attributs ne sont disponibles qu'après un point spécifique dans le temps, alors la valeur "NA" (non disponible) ou son équivalent doit être attribuée aux anciens enregistrements de la dimension.

2. De nouvelles mesures dans une table de faits. De même, si de nouvelles mesures sont disponibles, nous pouvons les ajouter à la table de faits avec élégance. Le cas le plus simple, c'est quand les nouveaux faits sont disponibles pour le même évènement et dans le même grain que les faits existants. Dans ce cas, la table de faits est modifiée pour ajouter les nouveaux champs, et les valeurs sont remplies dans la table directement. Dans un monde idéal, une instruction ALTER TABLE peut être utilisée sur la table de faits existante pour y ajouter les nouveaux champs. Si cela n'est pas possible, alors une deuxième table de fait doit être créée avec les nouveaux champs et les enregistrements issus de la première table. Pour les très grosses tables de faits, de grands blocs d'enregistrements peuvent être déplacés d'une table à l'autre pour éviter de stocker la table géante dans son intégralité une deuxième fois. Si les nouveaux faits sont disponibles uniquement à partir d'un point dans le temps, alors la valeur nulle doit être placée dans les enregistrements précédents. Si nous faisons cela correctement, alors les anciennes applications continueront à fonctionner tranquillement. Et de nouvelles applications utilisant les nouveaux faits devraient se comporter correctement même si elles rencontrent des valeurs nulles. Les utilisateurs pourront être informés que les nouveaux faits ne sont disponibles qu'à partir d'un point précis dans le temps.

Une situation plus complexe se pose lorsque de nouveaux faits ne sont pas disponibles pour le même évènement que les anciens faits, ou s'ils sont à un grain différent. Si les nouveaux faits ne peuvent pas être alloués ou attribués au même grain que la table de faits d'origine, il est très probable qu'ils doivent appartenir à leur propre table de faits. C'est presque toujours une erreur de mélanger des granularités ou des types de mesures différentes dans une même table de faits. Si vous avez cette situation, vous devez serrer les dents et trouver un outil de requêtage ou de reporting qui soit capable d'exécuter plusieurs requêtes SQL afin qu'il puisse accéder à plusieurs tables de fait dans la même demande de l'utilisateur. Des outils tels que Cognos, Business Objects, et Microstrategy sont tout à fait capable de gérer ce type de traitement.

3. De nouvelles dimensions. Une dimension peut être ajoutée à une table de fait existante en ajoutant un nouveau champ de clé étrangère et en le remplissant correctement avec les valeurs de la clé primaire de la nouvelle dimension. Par exemple, une dimension Météo peut être ajoutée à une table de faits retraçant les ventes de détail si une source décrivant la météo est disponible, par exemple, à chaque point de vente chaque jour. Notez que nous ne changeons pas le grain de la table de faits. Si l'information météorologique est disponible uniquement à partir d'un point dans le temps, alors la valeur de clé étrangère pour la dimension Météo doit pointer vers un enregistrement dont la description est "Météo indisponible".

4. Une dimension devenant plus fine. Parfois, il est souhaitable d'augmenter la granularité d'une dimension. Par exemple, une table de faits des ventes de détail avec une dimension Magasin pourrait être modifiée pour remplacer la dimension Magasin par une  dimension Caisse Enregistreuse. Si nous avions 100 magasins, chacun avec une moyenne de 10 caisses enregistreuses, la nouvelle dimension aurait 1000 enregistrements. Tous les attributs des magasins d'origines seraient inclus dans la dimension Caisse Enregistreuse parce que les caisses enregistreuses ont une relation de type 1-à-plusieurs avec les magasins. Les attributs des magasins peuvent également être modélisés physiquement comme une dimension en flocons reliée à la dimension Caisse Enregistreuse. Remarquez que quand on augmente la granularité du magasin ==> dimension Caisse Enregistreuse, il faut augmenter la granularité de la table de faits. La table de faits sera alors 10 fois plus grande, dans notre exemple. Il n'y a probablement pas d'autre choix que de supprimer la table de faits existante et de la reconstruire. Bien que ce changement soit un changement complexe, il est propre et toutes les applications initiales ne seront pas affectées. Les totaux au magasin resteront identiques et toutes les requêtes retourneront les mêmes résultats. Toutefois, elles pourraient s'exécuter plus lentement puisqu'il y a dix fois plus d'enregistrements dans la table de faits, mais nous aurions probablement envie de construire une table de faits agrégée aux magasins de toute façon! Cela correspondrait à la table de faits d'origine, qui jouerait désormais le rôle de table de faits agrégée.

5. Ajout d'une hiérarchie en rapport avec deux dimensions. Nous pouvons avoir une situation où deux dimensions se révèlent avoir une structure hiérarchique de type 1-à-plusieurs, mais pour diverses raisons, nous préférons les garder séparées. Normalement, nous devrions combiner des entités hiérarchiquement liées dans une même dimension, mais si l'une ou l'autre des dimensions existe dans son bon droit comme une dimension indépendante "conforme", on peut vouloir les garder séparées. Par exemple, dans l'assurance, nous pouvons avoir une dimension Police et une dimension Client. Si chaque police a exactement un client, alors la police pourrait être fusionnée avec le client. Cependant, nous ne souhaiterions probablement pas inclure les informations du client dans la dimension Police parce que la dimension Client sera certainement une dimension importante dans notre architecture de l'entrepôt de données global. La dimension Client pourra se connecter à de nombreuses autres tables de faits, où dans de nombreux cas la dimension Police n'a aucun sens. En dépit de cette nécessité de conserver les dimensions séparées, certains concepteurs ajoutent une clé ClientPolice très utile pour certaines de leurs tables de faits où la nouvelle dimension ClientPolice est le mariage exact entre le Client et la Police. Cette dimension contient la combinaison des clients et des polices et peut être interrogé de manière fiable pour explorer cette relation, indépendamment de toute table de faits. L'ajout de cette nouvelle clé de dimension combinée pose les mêmes questions d'administration que l'ajout d'une nouvelle dimension, décrite au paragraphe 3 ci-dessus. 

6. Ajout d'une nouvelle source de données impliquant les dimensions existantes ainsi que de nouvelles dimensions. Presque toujours, une nouvelle source de données a sa propre granularité et ses propres dimensions. Tous les concepteurs d'entrepôts de données connaissent la réponse à celle-ci. Nous créons une nouvelle table de faits. Puisque les tables de faits et les dimensions existantes sont inchangées, par définition, toutes les applications existantes continuent cahin-caha. Bien que ce cas semble presque banal, le point ici est d'éviter d'insérer les nouvelles mesures dans les tables de faits existantes. Une table de faits possède toujours un seul type de mesure exprimé dans un grain uniforme.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #29: Graceful modifications to existing fact and dimension tables", publié le 15 octobre 2001.

Conseil 28: Eviter les catastrophes à votre entrepôt de données

Les tragiques événements du 11 septembre nous font revoir nos hypothèses et nos priorités. Nous sommes obligés de remettre en question notre sécurité et la sécurité d'une manière qui aurait été impensable il y a quelques semaines.

Nous avons été habitués à penser que nos buildings et ordinateurs sont intrinsèquement sûr, juste parce qu'ils sont gros, importants et visibles. Ce mythe a été brisé. Si quoi que ce soit survient, ces types de bâtiments et d'ordinateurs sont les plus vulnérables.

L'assaut dévastateur sur notre infrastructure est également venu à un moment où l'entrepôt de données a évolué vers un état ​​proche de la production dans beaucoup de nos sociétés. L'entrepôt de données est aujourd'hui le moteur de la gestion de la relation client, et fournit presque en temps réel le suivi des commandes, des livraisons et des paiements. L'entrepôt de données est souvent le seul endroit où une vue des clients et de la rentabilité des produits peut être assemblé. L'entrepôt de données est devenu un outil indispensable pour la bonne marche de nombreuses entreprises.

Est-il possible de mieux protéger nos entrepôts de données? Existe-t-il une sorte d'entrepôt de données qui est sûr et moins vulnérables aux catastrophes?

Conseil 27: Soyez déconnecté le moins souvent possible

Si vous mettez à jour votre entrepôt de données chaque jour, vous avez un état particulier lorsque vous remplacez les données d'hier par les données d'aujourd'hui. Au cours de cette étape, votre entrepôt de données est probablement indisponible. Si tous vos utilisateurs sont dans le même fuseau horaire, vous ne ressentez aucune pression, aussi longtemps que vous pouvez lancer la mise à jour entre 3 et 5 heures du matin. Mais si vos utilisateurs sont dispersés à travers le monde, vous voulez être déconnecté le moins longtemps possible, parce que dans ce cas, le soleil ne se couche jamais sur l'entrepôt de données. Alors, comment pouvez-vous réduire ce temps d'arrêt au strict minimum?

Dans cet article, nous allons décrire un ensemble de techniques qui fonctionnent pour tous les principaux SGBD relationnels qui prennent en charge le partitionnement. Les détails exacts d'administration des partitions varient un peu d'un SGBD à un autre, mais vous saurez quelles questions poser.

Conseil 26: Ajouter une dimension Audit pour suivre la traçabilité et la confiance des données

Chaque fois que nous construisons une table de faits contenant des mesures de notre entreprise, nous entourons la table de faits avec "tout ce que nous savons être vrai". Dans un modèle dimensionnel, ce "tout-ce-que-nous-savons" est emballé dans un ensemble de dimensions. Concrètement, nous insérons les clés étrangères, une par dimension, dans notre table de faits, et relions ces clés étrangères aux clés primaires correspondantes de chaque dimension. Chaque dimension (comme produit ou client) contient un ensemble détaillé d'attributs textuels fortement corrélés représentant des membres individuels de la dimension (comme des produits individuels ou des clients).

Nous pouvons étendre cette approche "tout-ce-que-nous-savons" à la conception de la table de faits en incluant des éléments clés de métadonnées qui sont connus pour être vrai quand un fait relevé individuel est créé. Par exemple, lorsque nous créons un enregistrement de la table de fait, nous devrions connaître des choses telles que

1. quel système source a fourni les données de faits (plusieurs attributs si plusieurs systèmes sources).
2. quelle version du logiciel d'extraction à créé l'enregistrement.
3. quelle logique d'allocation (le cas échéant) a été utilisé pour créer l'enregistrement.
4. si un champ de la table de fait comportant la valeur "code NA" est effectivement inconnu, impossible, corrompu, ou non-disponible pour le moment.
5. si un fait précis a été modifié après le chargement initial, et si oui, pourquoi.
6. si l'enregistrement contient des faits de plus de 2, 3 ou 4 fois l'écart-type de la moyenne, ou de manière équivalente, en dehors de diverses limites de confiance provenant d'une autre analyse statistique.

Conseil 25: Concevoir des modèles dimensionnels pour les applications parent-enfant

La relation de données parent-enfant est l'une des structures fondamentales de base dans le monde des affaires. Une facture (le parent) a beaucoup de lignes d'articles (les enfants). D'autres exemples évidents en dehors des factures comprennent les commandes, les ordres de livraison, les polices d'assurance, et les tickets de caisses. Fondamentalement, tout document professionnel possédant des éléments qui se répètent est considéré comme une application parent-enfant, surtout quand ces éléments comportent des mesures numériques intéressantes comme des montants ou des unités physiques.

Les applications parent-enfant sont d'une extrême importance pour les entrepôts de données, car la plupart des documents de contrôle qui transfèrent de l'argent et des biens (ou des services) d'un endroit à un autre prend la forme parent-enfant.

Mais une source de données parent-enfant, comme les factures, pose un dilemme de conception. Certaines de ces données sont seulement disponibles au niveau de la société mère et certains ne sont disponibles qu'au niveau de l'enfant. Avons-nous besoin de deux tables de fait dans notre modèle dimensionnel ou pouvons-nous tout faire avec une seule? Et que faisons-nous avec les données qui sont disponibles uniquement au niveau de la société mère quand nous voulons descendre au niveau de l'enfant?

Conseil 24: Conception dimensionnelle dans un entrepôt de données multinational

Si vous gérez un entrepôt de données multinational, vous pourriez avoir à faire face au problème de la présentation du contenu de l'entrepôt de données dans un certain nombre de langues différentes. Quelles parties de l'entrepôt ont besoin d'être traduites? Où stockez-vous les différentes traductions? Comment faites-vous pour intégrer de plus en plus de langues?

Conseil 22: Dimensions Client de profondeur variable

La dimension Client est probablement la dimension la plus compliquée d'un entrepôt de données. Dans une grande entreprise, la dimension Client peut être:

• profonde, avec des millions d'enregistrements
• large, avec des douzaines d'attributs
• avec des évolutions lentes, mais parfois des changements rapides

Pour aggraver les choses, dans les très grandes dimensions Clients nous avons souvent deux catégories de clients que j'appellerais Visiteurs et Clients.

Conseil 21: Définir la granularité

L'étape la plus importante de la conception dimensionnelle est de déclarer le grain de la table de faits. Définir la granularité veut dire exactement ce qu'un enregistrement de la table de faits représente. Souvenez-vous qu'un enregistrement d'une table de fait capture une mesure. Voici quelques exemples:

• un produit par ligne sur un ticket de caisse d'un client mesuré par un scanner
• un virement sur une police d'assurance
• une facture d'un médecin
• un billet d'avion individuel de quelqu'un prenant un vol

Conseil 20: Faits éparses et faits ayant une courte durée de vie

Les tables de faits sont construites autour de mesures numériques. Quand une mesure est prise, un enregistrement dans la table de fait est ajouté. La mesure peut être le montant d'une vente, la valeur d'une transaction, une balance en fin de mois, le rendement d'un processus de fabrication, ou encore une mesure classique de laboratoire. Si nous enregistrons plusieurs nombres au même moment, nous pouvons souvent les ajouter au même enregistrement.

Nous complétons la mesure avec toutes les chose que nous savons être vraies au moment précis où elle est prise. A coté de la date et de l'heure, nous connaissons souvent des choses comme les clients, les produits, les conditions du marché, les employés, les statuts, les fournisseurs, et bien d'autres entités qui dépendent du processus que nous mesurons.

Conseil 19: Répliquer des dimensions correctement

Le secret pour construire un entrepôt de données distribué est d'utiliser des dimensions conformes. Dans un entrepôt distribué plusieurs sources de mesures différentes sont maintenues par différentes directions. Ces mesures sont habituellement présentées dans des tables de faits. Une direction peut suivre le nombre de produits fabriqués, une autre le nombre de produits dans le stock. Une troisième peut vouloir le nombre de produits vendus, et une quatrième le nombre de commentaires et plaintes liés à un produit. Clairement, toutes ces équipes ont un intérêt commun pour "le produit". Ainsi, nous pouvons construire un entrepôt de données distribué si nous parvenons à une définition unique du produit partagée par toutes les directions.

Conseil 18: La métaphore de l'édition

Dans cet article, je veux partager avec vous un point de vue que je prends très au sérieux, et qui est, d'une certaine façon, la base de tout mon travail sur les entrepôts de données. C'est la métaphore de l'édition. 

Imaginez le scénario suivant: imaginez que vous avez été invité à prendre la tête d'un magazine de grande qualité. Vous avez été nommé rédacteur en chef et vous disposez d'une grande liberté pour gérer le contenu, le style et la distribution de ce magazine.

Conseil 17: Tables d'aides pour les hiérarchies

Cet article fait suite à l’article "Help for Hierarchies" de Ralph Kimball, publié en septembre 1998, qui traite des structures hiérarchiques de profondeur variable. Ces structures sont le plus souvent représentées dans les bases de données relationnelles comme des relations récursives.

Ci-dessous, la définition d’une dimension Entreprise simple qui contient ce type de relation récursive entre la clé étrangère PARENT_CLE et la clé primaire ENTREPRISE_CLE :

Create table ENTREPRISE(

ENTREPRISE_CLE       INTEGER NOT NULL,

ENTREPRISE                 VARCHAR2(50),

PARENT_CLE                INTEGER);

Bien que cela soit efficace pour stocker des informations sur les structures organisationnelles, il n'est pas possible de naviguer ou de cumuler des faits au sein de ces hiérarchies en utilisant le SQL généré par les outils d'interrogation du commerce. Pour résoudre ce problème, l’article original de Ralph décrit une table d'aide semblable à celle ci-dessous qui contient un enregistrement pour chaque chemin et pour chaque entreprise dans l'arbre de l'organisation elle-même et pour chaque filiale en dessous d’elle.

Conseil 16: Dimensions interchangeables

Le dix-huitième critère de la liste des critères dimensionnels sympas, définit une "dimension remplaçable à chaud" comme étant une dimension avec deux ou plusieurs versions alternatives. Si la dimension est interchangeable, alors n’importe laquelle des versions peut être choisie au moment de la requête.

Il existe un certain nombre de situations où l'usage des versions alternatives d’une même dimension peuvent être très utiles. En voici 3 :

Conseil 15: Combiner les différents types de dimensions à évolution lente

Il existe plusieurs techniques bien documentées pour traiter les attributs des dimensions à évolution lente.
En bref, avec les dimensions à évolution lente de type 1, la valeur de l'attribut est remplacée par la nouvelle valeur, effaçant l’historique des valeurs. Par exemple, lorsque l’emballage d’un produit change, l'attribut "Emballage" est simplement mis à jour avec la valeur actuelle.
Avec une dimension à évolution lente de type 2, un nouvel enregistrement avec les nouveaux attributs sont ajoutés à la dimension. Les enregistrements de la table de faits continuent de pointer vers l’ancienne clé de la dimension Produit avec l’ancienne valeur d’emballage, alors que les nouveaux enregistrements pointeront vers la nouvelle clé Produit, faisant référence au nouvel emballage. Ainsi l’historique est parfaitement partitionné.
Enfin, avec les dimensions à évolutions lentes de type 3, les attributs sont ajoutés à la dimension pour obtenir deux emballages simultanés - on peut imaginer avoir un champs "Emballage actuel" et un champ "Emballage précédent", ou bien "Emballage d'origine".

D'après mon expérience, les équipes en charge de l'entrepôt de données sont souvent appelés à conserver l'historique des attributs tout en maintenant la possibilité de croiser les données historiques avec les valeurs actuelles des attributs. Aucune des techniques d’évolution lente présentées ci-dessus ne répond, à elle seule, à cette exigence. Toutefois, en combinant ces techniques, vous pouvez élégamment répondre à ce besoin dans vos modèles dimensionnels.

Nous allons commencer par utiliser la technique de type 2 pour enregistrer les changements d'attribut. Lorsque l’emballage change, nous ajoutons un nouvel enregistrement dans la dimension avec une nouvelle clé de substitution.
Nous allons ensuite enrichir la dimension avec un attribut supplémentaire décrivant l'emballage actuel. Dans les enregistrements courants de la dimension Produit, la valeur de l'attribut "Emballage" sera identique à la valeur du nouvel attribut "Emballage actuel". Mais, pour tous les enregistrements précédents d’un produit donné, l'attribut "Emballage actuel" sera mis à jour pour refléter l'état actuel du produit; l'attribut "Emballage" ne changeant pas.
Si nous voulons voir des faits historiques basées sur l'emballage actuel, nous allons faire un filtre ou une agrégation sur le champs "Emballage actuel". Mais si nous voulons conserver la vue historique des emballages, nous utiliserons le champs "Emballage".

Nous avons décrit une approche hybride qui combine les 3 techniques de dimension à évolution lente. Nous avons créé de nouveaux enregistrements pour capturer les changements (type 2), puis ajouté un attribut pour refléter un point de vue différent (type 3), qui est ensuite mis à jour pour tous les enregistrements précédents d'un produit donné (type 1). Comme un étudiant l’a récemment suggéré, peut être que nous pouvons appeler cela le type 6 (2 + 3 + 1).

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #15: Combining SCD techniques", publié le 29 octobre 2000.

Conseil 14: Calculer le solde à une date donnée sur une table de faits de type transactionnelle

L’article précédent a montré comment joindre une dimension à évolution lente (la table des comptes clients dans une banque) avec une table de faits dont le volume augmente rapidement (les transactions des comptes clients). Nous avons vu comment la dimension à évolution lente était elle même une sorte de table de faits, puisqu'elle était également la cible d'un ensemble d'opérations qui modifiait les profils des comptes.

Dans cet article, nous allons nous concentrer sur la table de faits qui enregistre tout les mouvements qui ont lieu sur les comptes bancaires. 

Conseil 13: Lorsqu'une table de faits est utilisée comme dimension

Les tables de faits sont principalement de trois types:

• le grain d'une table de faits peut être une transaction individuelle où un enregistrement représente un instant dans le temps 
• le grain peut être une période, représentant une durée de temps comme une semaine ou un mois. 
• le grain peut être une agrégation, représentant toute l'histoire de quelque chose 

J'ai discuté de ces trois types en détail dans un article que vous pouvez trouver ici.

Conseil 12: Compter correctement avec une dimension enrichie

Dans l’article précédent, nous avons abordé le sujet des calculs basés sur une dimension. Nous pouvons ajouter encore plus de valeur à ces résultats lorsque nous introduisons une table séparée, contenant des attributs supplémentaires et qui croise la table de dimension.

Nous avons récemment eu un exemple simple de ce genre de table complémentaire qui lie les codes postaux à une zone commerciale. Les personnes du marketing voulaient connaitre la répartition des clients par zone commerciale par rapport à l’ensemble de la population. En d'autres termes, nous voulions savoir où avions-nous une forte pénétration géographique, et où celle-ci était moins bonne. Si cette information supplémentaire s'avère précieuse pour l'organisation, nous devrions l'ajouter dans la dimension Client sous la forme d’un nouvel attribut. Mais auparavant, nous avons besoin de faire quelques requêtes pour nous assurer que cela en vaille la peine.

Conseil 11: Compter correctement dans une dimension

Les tables de dimension qui possèdent de nombreux attributs descriptifs deviennent souvent la cible de requêtes directes indépendantes de toute table de faits. Par exemple, nous faisons quotidiennement différents calculs sur notre dimension Client pour répondre à des questions telles que le nombre de clients par type de paiement, par région, ou par sexe, etc. Ces calculs sur une dimension statique sont faciles, mais cela devient plus intéressant lorsque nous essayons d’effectuer ces calculs sur une dimension à évolution lente.

Conseil 10: Vos données sont-elles correctes?

Un problème courant lié à la maintenance de l’entrepôt de données est de vérifier que les données qu'il contient soient correctes. L'entrepôt est-il une image exacte du système source? Le chargement de ce matin c'est-il correctement terminé? Des identifiants sont-ils erronés?

Il n'existe pas de technique unique pour valider un chargement de données, car les sources des données sont bien trop variées. Si vous chargez une image d'une source de production, tout en préservant sa granularité d'origine, alors vous pouvez probablement créer un rapport simple sur le système de production avec des totaux jusqu’à la minute, et vous pouvez utilisez ce même rapport avec l'entrepôt de données. Dans ce cas, vous connaissez la réponse à l'avance et les deux résultats doivent correspondre jusqu’à la dernière décimale.

Mais il est plus habituel de ne pas avoir de point de comparaison connu. Peut-être recevez-vous le détail des ventes de 600 magasins chaque nuit. Dans ce cas, vous pouvez certainement compter le nombre de magasins qui vont ont envoyé des données, mais comment pouvez-vous obtenir un meilleur avis et dire si les données sont "probablement correctes"?

Conseil 9: Traiter les dimensions à évolution lente durant un chargement initial de données

L’article précédent a clairement défini la technique des dimensions à évolution lente de type 2 et la bonne utilisation des clés de substitution. Ce mois-ci nous abordons la question épineuse du traitement des dimensions à évolution lente lors du chargement initial d'un nouveau domaine au sein d'un entrepôt de données. Cela peut se produire lorsque vous introduisez une nouvelle mesure (fait) dans un entrepôt de données existant par exemple. Des dimensions tels que Produit, Client, et Temps sont probablement déjà définies et possèdent un riche historique reflétant de nombreuses évolutions lentes.

Conseil 8: Partitionner un historique avec une dimension à évolution lente de type 2

Une dimension à évolution lente de type 2 fournit un autre type de partitionnement. On pourrait appeler cela une partition logique de l'historique. Dans l'approche de type 2, chaque fois que nous rencontrons un changement dans un enregistrement de la dimension, nous publions un nouvel enregistrement, et l'ajoutons à la table de dimension existante. Un exemple simple peut être est la description d'un produit, ou une autre caractéristique du produit tels que le type d'emballage, qui change mais que le numéro d'identification de celui-ci (par exemple, le code à barres) ne change pas. En tant que gardiens de l'entrepôt de données, nous avons pris l'engagement de suivre parfaitement les évolutions et nous devons donc suivre à la fois la nouvelle description du produit ainsi que l'ancienne.

Conseil 7: Remettre son entrepôt de données sur de bons rails

Durant l'année écoulée, nous avons observé à plusieurs reprises un problème avec les entrepôts de données matures: malgré des effort et des investissements considérables, des entrepôts de données se détériorent avec le temps. Les équipes techniques (ou leurs utilisateurs) ne sont pas satisfaits avec les livrables de l’entrepôt: les données sont trop confuses, il n'est pas conforme, les requêtes sont trop lentes, etc. Les équipes ont lus tous les best-sellers et les articles sur les entrepôts de données, mais ne savent toujours pas comment améliorer la situation (certains quittent même le navire et vont chercher un nouvel emploi).

Si cette situation vous semble familière, considérez attentivement chacune des questions suivantes pour déterminer si l'un - ou plusieurs - de ces facteurs fragilise votre entrepôt de données. En termes de mesures correctives, nous vous recommandons de faire face à ces préoccupations fondamentales dans l'ordre, si possible.

Conseil 6: Montrer les corrélations entre les dimensions

Voici une question que l'on me pose souvent: "comment puis-je représenter la corrélation entre deux dimensions sans passer par la table de faits?" Souvent, le concepteur poursuit avec la question "puis-je créer une petite table de jointure avec seulement les clés des deux dimensions et puis connectez cette table à la table de faits?"

Conseil 5: Clé de substitution dans une dimension Temps

Voici la modélisation d'une dimension Temps qu'un consultant nous a récemment proposé. Celle-ci semble assez différente de celles que nous concevons habituellement.

La structure de cette dimension Temps est la suivante :

Date_Clé           varchar2 (8)

Date_Début      date ou datetime

Date_Fin           date ou datetime

Et voici un exemple de son contenu :

Date_Clé         Date_Début               Date_Fin

xmas99            25Nov99                     06Jan00

1qtr99               01Jan99                     31Mar99

newyrsdy          01Jan00                     01Jan00

01Jan00           01Jan00                     01Jan00

Quel est votre point de vue sur cette structure? Pour quel type de scénario l'envisageriez vous comme une bonne solution et une alternative viable?

Conseil 4: Mettre à jour rapidement une dimension Client complexe

Beaucoup de concepteurs d'entrepôt de données ont à traiter avec une dimension Client compliquée, qui est à la fois large et profonde. Une dimension Client peut avoir 100 ou plus attributs descriptifs, et peut avoir des millions de lignes. Parfois, les «Clients» sont des demandeurs d'assurance-maladie, et d'autres fois ce sont des propriétaires de véhicules automobiles.Mais les questions de conception sont les mêmes.

Souvent, dans ces situations, l'entrepôt de données reçoit quotidiennement une copie complète mise à jour de la dimension Client. Bien sûr, ce serait merveilleux si seulement les delta (les enregistrements modifiés) étaient délivrés à l'entrepôt de données, mais le plus souvent c’est à l'entrepôt de données de trouver les enregistrements modifiés en recherchant méthodiquement dans l'ensemble de la table. Cette étape de comparaison enregistrement par enregistrement et champ par champ sur l'ensemble de la table entre la version d'hier et celle d'aujourd'hui est lente et inadéquat.

Conseil 3: Concentrez-vous sur les processus

Une des erreurs les plus répandues dans notre métier est que les datamarts sont souvent définis par service. Nous avons vu d'innombrables schémas d’entrepôts de données  étiquetés "Datamart marketing", "Datamart vente", et "Datamart finance". Après avoir examiné les exigences opérationnelles de ces services, vous découvrirez inévitablement que ces trois services souhaitent les mêmes informations de base, telles que les données des commandes. Plutôt que de construire un datamart "Marketing" qui comprend les commandes, puis un datamart "Vente" avec ces mêmes commandes, etc, vous devez construire un seul datamart "Commandes", détaillé, avec un accès pour les différents services.

Conseil 2: Représenter plusieurs dates à partir d'une seule dimension

La question la plus fréquente dans mes cours et e-mails est de savoir comment gérer plusieurs timestamp sur un enregistrement d'une table de faits. Bien que la réponse correcte et immédiate est « faites de chaque timestamp, une dimension Temps », il est utile de décrire cette approche avec précaution car elle illustre bien tout un ensemble de techniques modernes de conception d'entrepôt, sur lesquels je mettrais l'accent en MAJUSCULES.

Conseil 1: Recommendation pour la modélisation du datamart de suivi d'une session d'un visiteur sur un site internet

Le clickstream (que l’on pourrait traduire par « flot de clics » ou « parcours de navigation ») désigne le chemin parcouru par un visiteur, de clics en clics, de son entrée à sa sortie d’un site Internet. En termes de données brutes, cela veut dire qu’il y a un enregistrement pour chaque clic effectué par le visiteur. Le parcours de navigation contient donc de nombreuses informations sur le comportement d‘un visiteur sur le site. (Source definition clickstream : http://www.definition-marketing.net/clickstream/)

La quantité de donnée recueillit est énorme. Même modérément occupé, un site e-commerce peut générer 100 millions d’enregistrement chaque jour. Nous devons donc réduire le volume de données à des proportions gérables pour nos analyses les plus importantes. Dans cet article nous chercherons un moyen d’éviter d’explorer les 100 millions d’enregistrement, tout en gardant un niveau de détail utile pour analyser le comportement des visiteurs.