Fusionner les faits de différentes sources? Ou charger séparément?

Question

Nous avons des données de deux origines différentes: certaines proviennent d'un client, d'autres de fournisseurs différents. Actuellement, nous fusionnons et fusionnons physiquement. ces données dans une table massive avec presque cent colonnes, des dizaines de milliers de lignes et aucune séparation formelle des deux dimensions. Par conséquent, nous ne pouvons pas vraiment utiliser cette table pour beaucoup.

Je vais réorganiser ce gâchis en un schéma en étoile correct, mais petit.

Les deux dimensions sont évidentes. L'un d'eux, par exemple, est le temps.

Les données fournies par le client fournissent un certain nombre de valeurs factuelles. Chaque fournisseur peut (ou non) fournir des valeurs de faits supplémentaires correspondant aux mêmes dimensions.

Ces données de fait ont toutes la même granularité. On peut l'appeler "dépareillé". parce que nous ne recevons pas souvent des informations de tous les fournisseurs.

Voici mon dilemme.

S'agit-il d'un tableau de faits - avec quelques valeurs NULL - renseigné à partir de sources différentes?

Ou s'agit-il de n +1 tables de faits - l'une remplie par le client, les autres par chaque fournisseur?

Chaque design a ses avantages et ses inconvénients. J'ai besoin d'un deuxième avis sur le choix entre & fusion; & fusionner " ou "charger séparément".

Les clients fournissent les revenus, les coûts, les décomptes, les poids et les autres informations dont ils disposent sur la fin d'une transaction.

Le fournisseur 1 fournit des détails supplémentaires sur certaines des transactions - pondérations, coûts, durées. Les autres transactions n'auront aucune valeur pour le fournisseur un.

Le fournisseur n ° 2 fournit des informations supplémentaires sur certaines des transactions: volumes, durées, durées, taux de change. Les autres transactions n'auront aucune valeur pour le fournisseur deux.

Certaines transactions auront les deux fournisseurs. Quelques transactions n'auront aucun fournisseur.

Une table avec des valeurs nulles? Trois tables?

Answer 1

Je choisirais la seule table de faits. Le point fort de cette approche est qu’elle laisse tout le travail difficile au moment du chargement plutôt qu’au moment des requêtes.

Answer 2

D'après ce que vous décrivez, cela ressemble à une table de faits unique.

On dirait que la table de faits aura un grain de temps x transaction x client (?).

Ma question précédente visait réellement à déterminer si certaines des données relatives aux fournisseurs pouvaient être candidates à leur propre dimension. Je vous laisse le soin de le déterminer. mais ça ne sonne pas vraiment comme ça.

Des faits nuls peuvent émettre des avertissements lors des agrégations (en fonction de la plate-forme), mais l'alternative consistant à les renseigner avec des zéros éventuellement trompeurs est pire.

Answer 3

Je pense que puisque les deux sources partagent le même grain, la réponse est que vous devriez avoir un tableau de faits. Réfléchissez à la manière dont vous souhaitez que vos utilisateurs finaux interagissent avec les informations. Si cela a du sens et que les rapports d’entreprise tireront profit de la co-localisation de ces données, c’est votre réponse. Essayez cependant d'éviter les valeurs NULL dans vos tables de faits. Si vous pouvez entrer un zéro (et que le zéro ait un sens pour les données, par exemple, pensez à la température), faites-le. Cela évitera une certaine confusion à vos utilisateurs et, comme TrickyNixon l'a fait remarquer, entraînera des problèmes d'agrégation.

En fait, vous êtes à un bon point ici avec l'application "brownfield". Vous pouvez regarder ce qui existe aujourd'hui et tirer parti de l'expérience pour créer un meilleur design. C’est le moment le plus important pour sélectionner le meilleur grain qui, espérons-le, ne changera pas pendant la durée de vie du DW.