Existe-t-il un modèle de conception de dimension pour les dimensions à valeurs multiples?

Question

Je travaille sur un entrepôt de données qui vise à saisir les visites et les achats sur le site Web. Nous avons une hypothèse qu'en identifiant les modèles de visites précédentes, vous pouvez obtenir des informations sur le comportement des visiteurs pour la visite actuelle du site.

Le grain de ma table de faits est des visites de sites Web individuels et nous attribuons un 1 si le client fait un achat et un 0 si elle ne le fait pas. Notre fait est additif. Nous aimerions pouvoir explorer et comprendre comment les actions des visites précédentes influencent l'action de la visite actuelle, alors j'essaie de comprendre comment vous modéliseriez cela. Sur un site particulier, un visiteur peut avoir 1, 2 ou 12 visites de site antérieures. Donc, ma question est comment est-ce que je modéliserais une dimension de visite passée qui inclut la date de visite passée, l'activité passée de visite (achat ou pas d'achat, temps sur le site, etc.). Est-ce un exemple d'utilisation pour une table de bridge?

Answer 1

Une table de transition dans un entrepôt de données est principalement (exclusivement?) Pour traiter de nombreuses relations, que vous ne semblez pas avoir.

Si le tableau de votre table de faits correspond à des visites de site Web, vous n'avez pas besoin d'une dimension de «visite antérieure», puisque votre table de faits contient déjà l'historique des visites.

Vous avez deux dimensions ici: clients Date de

temps sur place est sans doute un certain nombre, et ce sont les deux mesures puisque vous traitez l'achat/aucun achat comme un score booléenne (1,0) et appartiennent dans la table de faits.

La dimension Client correspond aux attributs de votre client. Ne mettez pas de mesures ici (par exemple les scores antérieurs). Vous devriez également considérer comment gérer les changements (probablement SCD type 2).

Vous pouvez mettre votre champ de date directement dans le tableau de fait, mais il est plus puissant comme une dimension distincte, puisque vous pouvez analyser beaucoup plus facilement par quartiers, exercices, les jours fériés, etc.

Ainsi,

Exemple de table Fact_Website_Visit:

Fact_Website_Visit_Key | Dim_Customer_Key | Dim_Date_Key | Achat (1,0) | Time_On_Site

Exemple Dim_Customer Dimension:

Dim_Customer_Key | Customer_ID | Customer_Demographic

Exemple Dim_Date Dimension:

Dim_Date_Key | Full_Date | IsWeekend

Pour montrer comment cela fonctionne, j'ai écrit un rapport d'exemple pour voir la vente succès et le temps moyen passé en ligne le week-end regroupés selon les caractéristiques démographiques des clients:

SELECT 
Dim_Customer.demographic, 
COUNT(fact.Fact_Website_Visit_Key) AS [# of Visits], 
SUM (fact.Purchase) AS [Total Purchases], 
AVG (fact.Time_On_Site) AS [Average Minutes Online], 
SUM (fact.Purchase)/COUNT(fact.Fact_Website_Visit_Key)*100 AS [% sale success] 
FROM 
Fact_Website_Visit fact 
INNER JOIN Dim_Customer ON fact.Dim_Customer_Key=Dim_Customer.Dim_Customer_Key 
INNER JOIN Dim_Date ON fact.Dim_Date_Key=Dim_Date.Dim_Date_Key 
WHERE 
Dim_Date.IsWeekend='Y' 
GROUP BY 
Dim_Customer.Demographic