Dimension temporelle externalisée dans les cubes OLAP MySQL?

Question

Il semble être une pratique courante de laisser la dimension temps des cubes OLAP dans une table qui lui est propre, comme les autres dimensions.

Ma question est: pourquoi?

je ne vois pas simplement ce que l'avantage serait d'avoir une table time_dimension de (int, timestamp) qui est jointe avec le cube sur une time_id clé étrangère, au lieu d'avoir une colonne timestamp dans le cube lui-même. Principalement, les points dans le temps sont immuables et constants, et ils sont leur propre valeur. Je ne trouve pas très probable que l'on veuille changer la valeur associée pour un time_id donné.

En outre, le type de colonne timestamp est de 4 octets de large (en MySQL), tout comme le type int qui serait normalement la clé, donc ne peut pas non plus économiser de l'espace. En discutant de cela avec mes collègues, le seul argument quelque peu raisonnable que j'ai pu trouver est la conformité avec les autres dimensions. Mais je trouve cet argument plutôt faible.

Answer 1

Je crois que c'est souvent parce que la table de dimension temporelle contient un certain nombre de colonnes telles que semaine/mois/année/trimestre, ce qui permet des requêtes plus rapides pour obtenir tout X pour un trimestre particulier. Étant donné que la majorité des cubes OLAP sont écrits pour obtenir des requêtes au fil du temps, cela a du sens pour moi.

Answer 2

Paddy est correct, la dimension temporelle contient des "alias" utiles pour les primitives temporelles. Vous pouvez capturer des informations utiles sur les dates elles-mêmes telles que le trimestre, les jours fériés, etc. Vous pouvez écrire des requêtes beaucoup plus rapides de cette façon car il n'est pas nécessaire de coder chaque vacances dans votre requête.