Modification lente des dimensions - implémentation exacte de la requête SQL pour récupérer les données correctes

Question

Je suis un peu nouveau dans le développement BI/l'entreposage de données, mais je suis confronté à l'ancien dilemme lent des dimensions changeantes. J'ai beaucoup lu sur les types et la théorie, mais j'ai trouvé peu de choses en termes de ce que je considère comme les requêtes SELECT les plus courantes contre ces implémentations.

Je vais garder mon exemple simple. Supposons que vous ayez quatre raisons de vente: Est, Ouest, Nord et Sud. Vous avez un groupe de vendeurs qui effectuent des ventes quotidiennes et (peut-être une fois par an) sont réaffectés à une nouvelle région.

Vous aurez des données brutes comme les suivantes:

name; sales; revenue; date 
John Smith; 10; 5400; 2015-02-17 

Vous avez des données comme ça tous les jours.

Vous pouvez également avoir une table dimensions comme suit, d'abord:

name; region 
John Smith; East 
Nancy Ray; West 
Claire Faust; North 

Ainsi, le directeur des ventes veut connaître le chiffre d'affaires mensuel pour la région Est en mai 2015. Vous exécuterez une requête:

SELECT region, month(date), sum(revenue) 
from Fact_Table inner join Dim_Table on name = name 
where region = East and date between .... 
[group by region, month(date)] 

Vous avez l'idée. Ignorons que j'utilise des clés naturelles à la place des clés de substitution; J'utiliserais clairement des clés de substitution.

Maintenant, de toute évidence, les vendeurs peuvent déplacer des régions en milieu d'année. Ou au milieu du mois. Vous devez donc créer un type SCD afin d'exécuter cette requête. Pour moi, le type 2 est le plus logique. Donc disons que vous l'appliquez. Dites John Smith a changé de région de l'Est à la région de l'Ouest le 15 mai 2015. Vous implémentez le tableau suivant:

name; region; start_date; end_date 
John Smith; East; 2015-01-01; 2015-05-15 
John Smith; West; 2015-5-15; 9999-12-31 

Maintenant, le directeur des ventes pose la même question. Quel est le revenu total des ventes de l'Est pour mai 2015? Ou encore, montrez-moi les totaux par région par mois pour toute l'année. Comment structureriez-vous la requête?

SELECT region, month(date), sum(reveneue) 
from Fact_Table inner join Dim_Table 
on name = name 
and date between start_date and end_date 
group by region, month(date) 

Est-ce que cela donnerait les bons résultats? J'imagine que ça pourrait être ... ma question est peut-être plus du genre --- d'accord, supposons maintenant que vous avez 1 million d'enregistrements dans la table de faits ... cette jointure interne serait-elle vraiment inefficace, ou y at-il un moyen plus rapide ce résultat? Serait-il plus logique d'écrire la SCD (comme la région) directement dans une table de faits 'dénormalisée' --- et quand la dimension change, peut-être mettre à jour rétroactivement une semaine ou deux de régions Fact record '?

Answer 1

Votre concept est correct si les besoins de votre entreprise ont une hiérarchie Region-> Seller, comme indiqué dans votre exemple.

La performance de votre requête actuelle peut être difficile, mais elle sera améliorée par l'utilisation de clés de dimension et d'attributs appropriés.

Utilisez une hiérarchie de dimension de date incluant date-> Month et vous pourrez éviter la requête de plage.

Utilisez des nombres entiers, des clés de substitution dans les deux dimensions et votre performance d'indexation s'améliorera.

un million de lignes est minuscule, vous n'avez des problèmes de performance sur tous les SGBD compétentes :)