4 votes

Instantanés ponctuels dans l'entrepôt de données

J'essaie de recréer le statut d'un client à un moment précis. Par exemple, chaque client possède de nombreux attributs qui peuvent changer à tout moment (par exemple, le score de risque, la facturation à ce jour, la satisfaction du client).

Chaque fois qu'un client soumet une demande de crédit, j'aimerais voir la valeur de toutes ces caractéristiques au moment de la soumission. Par la suite, je souhaite utiliser ces valeurs pour développer un modèle prédictif.

Ma première idée a été de créer une dimension de type 2 à évolution lente avec des dates/horaires d'effet et d'expiration et d'utiliser une jointure semi-ouverte time_effective <= date_of_application < time_expired.

Cependant, la plupart de ces attributs sont des dimensions comportementales qui nécessitent des calculs compliqués à l'aide de données historiques provenant de tables de faits. En outre, les valeurs calculées ne peuvent pas être regroupées en utilisant des fourchettes (0-500 $, 500-750 $, etc.). Le suivi de tous ces attributs pour chaque dimension fait exploser le système. Remarque : certaines valeurs changent quotidiennement, d'autres changent à des moments arbitraires.

Mon extrait de données idéal serait le suivant :

  • Numéro d'identification pour la demande de crédit
  • Date de soumission
  • Valeur de l'attribut 1 au moment de la soumission
  • Valeur de l'attribut 2...
  • Valeur de l'attribut N

Outre les demandes de crédit, il existe d'autres tables de faits dans lesquelles je souhaite trouver les caractéristiques en vigueur au moment de l'événement.

Quelles sont les recommandations en la matière ? Je vois plusieurs approches :

  1. Permettre à la dimension d'exploser
  2. Créer des tables distinctes ayant un ou plusieurs attributs et interroger séparément les tables particulières ayant les attributs qui m'intéressent.
  3. Ajouter une colonne à la table des faits des demandes de crédit qui contient un "instantané" de tous les attributs qui m'intéressent.

Certaines de ces questions sont abordées dans le livre ETL Toolkit de Kimball (pp 190-192) et dans son livre Data Warehouse Toolkit (187-191). Aux pages 154-157, il y a une discussion sur "l'évolution rapide des dimensions des monstres" qui semble très pertinente. Pourtant, j'ai du mal à mettre en œuvre ces recommandations.

2voto

Tomas Greif Points 3919

Je créerais une table de faits d'application distincte avec des clés vers les tables et les enregistrements pertinents. Supposons que vous ayez les dimensions et les tables de faits suivantes :

  • (D) application
  • (D) demandeur (ou client)
  • (D) produit
  • (D) le temps
  • (D) monthly_scoring_fact (notation comportementale mensuelle)
  • (F) monthly_satisfaction_fact (enquête de satisfaction mensuelle)
  • (F) fait d'évaluation de la satisfaction (évaluations ad hoc de la satisfaction)

Vous pouvez ensuite créer la table de faits suivante : Application Fact :

  • application_key - pointe vers la dimension de l'application
  • applicant_key - renvoie à la dimension du candidat
  • product_key - indique la dimension du produit
  • time_key - indique la dimension temporelle
  • monthly_scoring_fact_key - points vers les derniers résultats de la notation mensuelle
  • monthly_satisfaction_fact_key - points vers les dernières données de satisfaction
  • satisfaction_evaluation_fact_key - point vers les dernières données d'évaluation ad hoc

Cette approche permet d'obtenir des données cohérentes dans le temps et de conserver la dimension de l'application dans le SCD0 (uniquement les corrections).

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X