2017-05-26 2 views
0

Je conçois un entrepôt de données qui utilise le modèle Data Vault. Il y a une entité dans mon entrepôt de données appelée spécialité. Il existe une table de consultation pour ces spécialités basée sur leurs codes qui a un mappage un-à-un de Specialty_CD à Description. Il y a un historique des entrées de données pour cette table de recherche (car les codes de spécialité peuvent changer de sens) et toutes les tables satellites de mon coffre-fort.Tables de modèles et de recherche de coffre-fort de données

Je suis tombé sur un cas curieux où je veux relier une autre entité dans le coffre de données appelée «Professionnel» à l'entité spécialisée, où un professionnel peut avoir plusieurs spécialités. Cependant, il n'y a pas de concentrateur pour l'entité spécialisée. Ma solution actuelle a simplement un centre professionnel qui contient des clés commerciales et des clés commerciales pour chaque professionnel, un tableau de liens qui mappe Professional HK Hashes aux codes spécialisés des spécialités que les professionnels pratiquent, et une table de consultation des codes spécialisés à la description. La capture ici est que la table de liaison connecte un concentrateur à une table de recherche, au lieu d'un autre concentrateur. Je ne peux m'empêcher de penser que cela brise le modèle Data Vault. Est-ce que cela brise les règles du modèle Data Vault? Est-ce que cela gâche la normalisation de tout mon modèle? J'ai l'impression que la création d'un Hub pour les spécialités entraînerait une jointure supplémentaire pour la récupération des données. Étant donné que les codes de spécialité sont déjà des identifiants uniques des descriptions de spécialité, je préférerais avoir une table de consultation unique pour cette entité spécialisée, plutôt qu'un concentrateur et des satellites supplémentaires pour l'entité spécialisée dont je n'ai pas besoin. Surtout parce que ce n'est que dans l'entrepôt de données pour servir à la définition et la description d'un code de spécialité.

Toutes les suggestions pour cette situation sont les bienvenues. Le coffre de données est-il ruiné dans ce scénario en liant un concentrateur à une table de recherche? Est-ce que cela vaut la peine d'avoir des frais supplémentaires et des jointures additionnelles lors de la récupération pour créer un concentrateur et des satellites pour cette entité spécialisée?

Merci!

Répondre

2

Vous avez répondu à votre propre question: « Codes spéciaux de les spécialités qui les pratiques professionnelles »

Spécialités est clairement un Concept de base et est une plaque tournante. Le fait qu'il n'a que 2 champs (Code et Description) est sans importance.

Le coffre-fort de données fonctionne sur les modèles. Ce n'est pas "seulement dans la base de données pour servir à la définition". Si elle était supprimée, la base de données fonctionnerait-elle encore? Par exemple, est-ce que j'ai enlevé le code postal d'une adresse que la base de données continuerait à fonctionner. Je suppose que si vous supprimiez Specialty, il pourrait y avoir des problèmes avec certains des rapports.

Vous devez vous habituer au fait que vous aurez BEAUCOUP plus de tables (environ 7 est la métrique générale) lorsque vous créez un coffre-fort de données brutes.

pcd

0

Je pense que votre modèle devrait ressembler à ceci

  • Specialty_HUB (HUB_ID (pk), Specialty_CD)
  • Specialty_SAT (SAT_ID (pk), HUB_ID (fk), LOAD_DATE, Description
  • Professional_HUB (HUB_ID (pk), Professional_PK)
  • Professional_SAT (SAT_ID (pk), (HUB_ID (fk), Détails du professionnel ...)
  • Profesional_X_Specialty_LNK (LNK_ID (pk), LOAD_DATE, date_fin, Professional_HUB_ID (fk), Specialty_HUB_ID (fk))

Notez que dans cette conception que vous avez une exigence pour un date_fin dans le tableau de lien que vous pouvez besoin de retirer une association unique indépendamment du statut du professionnel ou de la spécialité et vous devrez vous assurer que votre logique ETL ramasse les «suppressions». Si les codes liés à la spécialité peuvent également changer, vous aurez besoin d'une autre couche d'abstraction entre la table de liens et la spécialité SAT pour vous assurer que les liens restent stables.