Infocubes

Objectif : Optimisation de l'espace et des temps de chargement

Architecture technique d'un cube

Plus de tables des dimensions plus qu'une table

Donc la structure des dimensions n'a plus aucune importance technique c'est juste du fonctionnel et encore vu que normalement on reporte sur un MP ou plutôt maintenant un composite provider

 ATTENTION pour la table de faits il y a 4 partitions

Partition 4 = données non compressées

Partition 1 = données compressées

Partition 2 = données de référence (chgt initial de stock) = concerne uniquement les KF non cumulatives

Partition 3 = données historique (depuis le chgt initial de stock) = concerne uniquement les KF non cumulatives

Donc pour un cube sans KPI non cumulatif seuls les partitions 4 et 1 seront renseignés les 2 et 3 restent vides

La compression (suppression des id de chgt) peut être utilisée et donc on aura la partition 1 qui sera chargé

Donc finalement au max il y a 3 tables pour un cube

La D pour les dimensions

La F pour la table de faits

La L pour les non cumulatifs

Et 4 partitions

CAS Particulier pour gestion de stock

C'est au niveau du DTP que ça va se jouer puisqu'il n'y aura plus d'infopackage

Voir p.206 pour le détail

Outil de migration

Transaction RSMIGRHANADB pour convertir anciens cubes vers nouvelle structure