Traitement de l'adresse Dimension et rôle jouant dans plusieurs faits

Question

Une question concernant la modélisation dimensionnelle et le jeu de rôle. Nous avons une dimension d'adresse qui est 'jeu de rôle'. Nous recevons des adresses de différentes sources, y compris des systèmes CRM. Les adresses peuvent également être de différents types, tels que l'adresse d'une société, un individu, etc. Ainsi, à partir de la dimension Adresse de jeu de rôle, une seule adresse peut être identifiée comme adresse d'une société et Adresse pour facturer différents faits.

Il existe différentes tables de faits et elles ont différentes clés qui pourraient contenir des données d'adresse. Fact_Sales possède des clés telles que Customer_Address_Key, Company_Head_Office_Address_Key. Donc je crois que nous sommes un peu en train de jouer les adresses dans ces faits.

Question:

Notre Data Architect principal a une préoccupation autour de cela. • Nous capturons beaucoup d'adresses d'un certain nombre de systèmes. Comment pourrions-nous identifier d'où viennent ces adresses, et de quel type d'adresses s'agit-il sans aller aux tables de faits?

Je suggère toujours de passer par les faits, mais j'aimerais consulter la communauté plus large là-bas avant de mettre les pieds sur terre.

Existe-t-il une meilleure façon de faire cela, peut-être une table distincte qui définit la combinaison de Address_Key, Address_Type_Key et Source_Key.

S'il vous plaît laissez-moi savoir si vous avez besoin d'éclaircissements ou des photos etc.

Vive Nithin

Answer 1

On dirait que dans la situation que vous avez que vous devez simplement inclure des colonnes pour le type d'adresse et source de l'adresse dans la dimension de l'adresse elle-même, de sorte qu'il se tient seul et vous n'avez pas à passer par un fait pour savoir ce genre de chose. Vous n'avez pas besoin d'une table séparée avec des clés comme vous l'avez mentionné - les données peuvent être dénormalisées en toute sécurité dans la dimension.

En aparté:

Bien que beaucoup de gens ont une table d'adresses qui est séparée, l'approche du groupe Kimball ne serait pas d'avoir ont « adresse » ou dimension de l'emplacement comme une dimension multi-usage qui est le seul - il fournit une partie de ce qui décrit autre chose (comme une entreprise, ou un client, ou même un «lieu de livraison»). Au lieu de cela, vous auriez la dimension (par exemple, Client) et dans cette dimension, vous auriez un certain nombre de champs Adresse, nommés de manière appropriée (CustomerAddress1, CustomerAddress2, CustomerCity). Vous pouvez choisir d'administrer l'adresse de manière centralisée pour plus de commodité dans les coulisses, avec les autres dimensions formées au moyen de vues ou d'autres ETL, mais dans la présentation du schéma en étoile, la table d'adresses ne sera pas vue séparément. Les adresses sont toujours conformes en ce qu'ils s'appellent la même chose et signifient la même chose.

Cependant beaucoup de gens aller avec une table d'adresses séparée que vous avez fait

Answer 2

Il est très raisonnable d'inclure la source comme un attribut de la dimension. La question la plus importante est de savoir comment sélectionner l'adresse "actuelle" pour un client si vous avez plusieurs sources. C'est là que les choses deviendront difficiles.

Vous avez besoin de l'adresse du client actuel pour signifier la même chose dans l'ensemble de votre entreprise, quelle que soit la source à partir de laquelle il a été capturé. Je dirais que c'est une dimension conforme.Vous devez «conformer» toutes les sources de vos adresses à la même structure afin de pouvoir les utiliser comme une seule dimension.

Dans la grande majorité des cas, la source de l'adresse n'est pas pertinente. Vous avez seulement besoin de savoir que c'est l'adresse actuelle. Vous pouvez avoir un modèle plus petit qui peut fournir une analyse sur la source de l'adresse du client. La partie la plus difficile est de décider quelle source est la plus fiable lorsque l'adresse est dans plusieurs sources. Vous devez prendre en compte la source et la date de la dernière mise à jour. En d'autres termes, la source principale est-elle toujours préférée lorsqu'une source moins fiable a une mise à jour plus récente?

Le type est généralement juste un attribut de l'adresse. Cependant, si votre adresse peut être utilisée pour plusieurs éléments (physique, expédition, facturation, etc.), il peut être nécessaire de définir la relation de jeu de rôles. Pour d'autres analyses sur l'adresse, vous pouvez diviser la ville/état & zip en dimensions distinctes si vous avez besoin de décomposer les choses par emplacement géographique. Je recommande City & Etat être utilisé comme une seule entité. Si vous traitez la ville comme étant distincte de l'État, vous obtiendrez des résultats amusants en découpant les villes qui existent dans plus d'un État.