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 :

1. Une banque d'investissement met à la disposition de ses clients une grande table de faits qui suit les actions et obligations quotidiennement sur une période de plusieurs années. La dimension "Investissement" dans cette table de faits donne des renseignements sur chaque action et obligation.Mais cette dimension Investissement est personnalisée pour chaque client accédant à la table de faits afin que chacun puisse décrire et regrouper les investissements de manière intéressante et individuelle. Les différentes versions de la dimension Investissement peuvent être complètement différentes, incluant des noms d’attributs incompatibles et des hiérarchies différentes. Tous les clients utilisent la même table de faits (par conséquent elle ne doit être stockée qu’à un seul endroit), mais chaque client utilise sa propre dimension Investissement comme base pour analyser les mouvements des valeurs des actions et des obligations. Vu du serveur de base de données, les clients changent à chaud la dimension Investissement à chaque requête.
2. Une banque de détail crée une grande table de faits qui enregistre les soldes de fin de mois de tous les types de comptes de la banque, incluant les comptes courant, les comptes épargne, les hypothèques, les cartes de crédit, les prêts personnels, les prêts aux petites entreprises, les certificats de dépôt, les prêts étudiants, etc. Il s'agit d'un cas classique de "produits hétérogènes" parce que les descriptions détaillées de ces différents types de compte sont très différentes. Il n'existe pas de modèle unique des descriptions capable de reprendre la complexité de tous ces types de compte. Par conséquent, nous construisons une dimension Compte simplifiée qui est destiné à se joindre à tous les comptes de manière uniforme. Nous utilisons cette dimension simplifiée lorsque nous faisons des analyses sur les ventes croisées ou incitatives et que nous regardons l'ensemble du portefeuille d'un client. Mais lorsque nous limitons notre attention sur un type de compte en particulier (par exemple, les prêts hypothécaires), on échange notre dimension simplifiée pour une autre beaucoup plus large et qui contient uniquement les attributs concernant les prêts hypothécaires. Nous pouvons le faire lorsque nous sommes convaincus que nous avons restreint l'analyse à un seul type de compte. Si nous avons 20 secteurs d'activité, nous avons alors 21 dimensions Compte : 1 dimension simplifiée décrivant l'ensemble des comptes et 20 dimensions étendues décrivant des ensembles disjoints de comptes similaires.
3. Un fabricant tient à mettre sa table de faits des expéditions à la disposition de ses partenaires commerciaux, mais doit protéger les commandes des partenaires afin que celles-ci ne soient pas visibles par tous. Dans ce cas, chaque partenaire à sa propre version de la dimension Partenaire avec uniquement leur nom. Tous les autres partenaires sont marqués comme "Autres". En outre, dans la dimension, un champ obligatoire représentant le facteur de pondération est fixé à 1 pour le partenaire concerné et est mis à 0 pour tous les autres. Ce facteur de pondération est multiplié par tous les faits de la table de faits. De cette façon, une simple table de faits des expéditions peut être utilisée pour favoriser la compétitivité des partenaires commerciaux de manière sécurisée.

Le changement de dimensions à chaud est simple dans une base de données relationnelle standard depuis que les jointures entre les tables peuvent être spécifiées lors de la requête. Mais si l'intégrité référentielle est nécessaire entre les dimensions et la table de faits, alors toutes les versions de la dimension doivent contenir l’ensemble des clés et donc l'ensemble des enregistrements de la dimension. Dans ce cas, si la dimension permutable est utilisée pour restreindre l'accès à la table de faits (comme dans les exemples 2 et 3), les enregistrements restreints de la dimension doivent contenir des valeurs fictives ou nulle.

Le changement à chaud de dimensions est plus un défi pour les systèmes OLAP lorsque l'identité de la dimension est construit dans la structure du cube de données OLAP. Pour voir comment Cognos (PowerPlay) et Microsoft (Analysis Services) manipulent ce type de dimension dans leurs produits OLAP, lisez cet article.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #16: Hot swappable dimensions", publié le 8 décembre 2000.