Type 2 Changements de dimension relatifs à une autre dimension

Question

J'essaie de modéliser un entrepôt de données de recrutement avec une variété de dimensions de type 2, mais je ne suis pas sûr de modéliser correctement ce scénario particulier. Voici ce que je fais jusqu'à présent:

J'ai 2 dimensions: Dim_Person et Dim_Client

Ces deux dimensions sont reliées par une table factless de fait Fact_PersonEmployer, qui contient FKs à deux dimensions, ainsi qu'une date de validité et à partir de maintenant. Si une personne déménage dans une autre entreprise, je ferme la date de validité sur la ligne de faits qui la relie à son ancien employeur et j'insère un nouvel enregistrement dans la table de faits avec la nouvelle société. Cela semble assez simple, mais comme cette personne a maintenant déménagé à un nouvel employeur, je pense qu'il mérite un changement de type 2 dans la dimension de la personne que la personne est maintenant fondamentalement différente de l'utilisateur (un gestionnaire recruteur/recruteur) . De mon point de vue, il semble presque que le client soit un attribut de type 2 de la dimension de la personne, donc j'ai envisagé de le modéliser de cette façon. Je ne suis pas sûr qu'il soit acceptable de joindre des dimensions sans utiliser une table de faits sans faits (j'essaie de m'en tenir à la méthodologie de Kimball autant que possible).

Dois-je:

a) Gardez l'ID de l'entreprise où ils travaillent comme un attribut dans la dimension de la personne afin qu'elle puisse générer le type 2 change

ou

b) Continuer à utiliser la table de faits pour associer les deux dimensions entre elles?

Espérons que cela a du sens ...

Merci d'avance!

Answer 1

Couple de points:

1. Magasin De et à des dates dans la dimension tableau lui-même, il n'y a pas besoin de le stocker dans Factless table de faits. Lorsqu'une personne passe à une activité différente, seule la table de dimensions doit être modifiée, c'est-à-dire la fermeture de l'enregistrement et l'insertion d'un nouveau.

2. Quand une personne se déplace à une autre société, il y a peu de choses que vous devez être clair de

   1. Voulez-vous suivre cette personne après avoir quitté le organisaton?
   2. L'enregistrement doit-il être complètement fermé?

Si vous voulez conserver l'historique et l'enregistrement de la personne, puis en conservant l'ID serait approprié.

Answer 2

Si votre fait montre la relation d'embauche entre DimPerson & DimClient, vous ne devriez avoir aucune information sur le client dans DimPerson. L'enregistrement DimPerson n'aurait pas besoin de changer parce que la relation est contenue dans le fait (et il devrait avoir la date/heure de l'événement).

Toutefois, si vous considérez que l'employeur est un attribut de l'employé, vous n'avez pas besoin de la table de faits, car la relation est contenue dans la variable. Dans ce cas, vous devez dénormaliser vos informations client dans DimPerson. Le datetime sera utilisé comme date effective de l'enregistrement de dimension et la date d'expiration de l'enregistrement de dimension précédemment actif.

Sur une note distincte, les meilleures pratiques indiquent que votre table de faits décrit l'événement. Je trouve le nom Fact_PersonEmployer déroutant. Quel est l'événement qu'il capture? Est-ce l'événement de l'emploi?