Dimension et fait pour les mêmes entités?

Je suis plutôt nouveau dans la conception DW et je travaille sur un DW pour modéliser une infrastructure informatique.

Le problème / question majeur à ce stade est de savoir comment modéliser les informations de lecteur.

Nous collecterons des données agrégées sur les fichiers et dossiers et des données distinctes sur les disques physiques. Les informations sur le lecteur incluront au minimum l'espace total et libre et seront mises à jour plusieurs fois par semaine.

L'une des questions commerciales auxquelles il faudra répondre est de savoir comment l'utilisation du lecteur évolue au fil du temps. Les informations sur le lecteur seront également utilisées dans une hiérarchie menant au niveau fichier / dossier.

Les options que je peux voir maintenant sont:

1. Implémenter en DRIVEtant que dimension

   • Simplifie la conception de la hiérarchie
   • Cela entraînera-t-il des problèmes avec les rapports? Il me semble contre-intuitif de rapporter des données limitées dans le temps sur une dimension uniquement
   • Il semble également problématique d'avoir une dimension que vous SAVEZ changer à chaque fois que vous actualisez vos données

2. Mettre DRIVEen œuvre en tant que table de faits

   • Simplifie les rapports
   • Hiérarchie compliquée (?) - Je vais également utiliser Drivepour mapper les données sur un serveur ou un ordinateur spécifique. Peut-on utiliser une table de faits comme niveau intermédiaire dans une hiérarchie? Je ne pense pas.

3. Mettre DRIVEen œuvre en tant que fait et dimension

   • Le fait ne contiendra que la clé, la date et les faits sur l'espace
   • Dimension inclura d'autres données non additives telles que l'ordinateur sur lequel il se trouve, etc.
   • Semble résoudre les deux problèmes, mais est-ce un anti-modèle?

Je suppose que j'aurais une table de faits drive_usage avec un lien vers une dimension de temps d'instantané, une dimension de lecteur, une dimension d'ordinateur et les divers faits numériques sur le lecteur à cet instant dans le temps.

Il ne devrait probablement pas y avoir de changement régulier dans la dimension du lecteur - je suppose que cela dépend de votre définition du lecteur - que ce soit un lecteur physique ou une unité logique ou quoi. Peut-être que votre lecteur "C" a un numéro de série, et il est remplacé - alors la dimension expirera et une nouvelle dimension sera ajoutée. Ces choses sur une dimension ne sont pas vraiment des "faits", ce sont des attributs. Cela n'affecterait pas la génération de rapports car les données de l'ordinateur X, le lecteur C ont une continuité. De même, si l'ordinateur X est mis à niveau de dual core à quad core et qu'il y a donc un changement de dimension (en supposant que quelque chose au-delà du nombre de cœurs ne soit pas suivi dans une table de faits, comme une révision de la carte mère). La capacité d'un lecteur serait dans la table de faits, donc les changements dans le temps ne sont que de nouveaux faits avec de nouvelles dates. Parfois, vous pouvez même modéliser les changements d'adhésion comme des faits. c'est-à-dire si les lecteurs physiques 1-5 sont dans le lecteur logique C un jour et que les lecteurs physiques 1-6 sont dans le lecteur logique C le lendemain, cela pourrait juste être un changement de fait dans la table de faits sur l'adhésion au lecteur physique. C'est ce que certaines personnes appellent des tables de faits infondées, car le seul fait est que la ligne montre l'appartenance - il n'y a pas grand-chose à faire à part totaliser ou compter.

Lorsque vous accédez à des dossiers, la modélisation de la hiérarchie peut être beaucoup plus délicate en fonction de ce que vous essayez de réaliser avec les cumuls.

Il y a beaucoup d'art dans la modélisation DW dans des domaines qui ne sont pas des scénarios courants.