Dois-je aplatir plusieurs clients en une seule rangée de dimension ou en utilisant une table de pont

Question

Je suis nouveau dans le datawarehousing et j'ai un schéma en étoile avec une table de faits contractuels. Il contient des informations de base sur le contrat, telles que la date de début, la date de fin, le montant, etc.

Je dois lier ces faits à une dimension client. Il y a un maximum de 4 clients par contrat. Je pense donc que j'ai deux options, soit j'aplatis les 4 clients en une ligne pour ex:

DimCutomers 

name1, lastName1, birthDate1, ... , name4, lastName4, birthDate4 

l'autre option de ce que j'ai entendu est de créer une table de pont entre les faits et la dimension client. Ainsi, complexifier le modèle.

Que croyez-vous que je devrais faire? Quels sont les avantages/inconvénients de chaque solution et existe-t-il une meilleure solution?

Answer 1

Je commencerais par créer une dimension client avec tous les clients et avec un seul client par ligne. Une dimension client peut être un outil utile par elle-même pour la gestion de la relation client et d'autres objectifs, ce qui signifie que vous aurez une liste de clients unique et fiable, ce qui facilitera grandement la conception de votre site. Ensuite, cela dépend de la relation entre le (s) client (s) et le contrat. Les principaux scénarios auxquels je peux penser sont les suivants: a) un contrat a 4 rôles de client, b) un contrat a 1-4 clients, tous avec le même rôle, et c) un contrat a des clients 1-n, tous avec le même rôle.

Le scénario A serait que chaque contrat comporte 4 rôles de client, par ex. un client qui a demandé le contrat, un second qui le signe, un troisième qui le reçoit et un quatrième qui le paie. Dans ce cas, votre table de fait aura une ligne par contrat et 4 client colonnes d'identité, dont chacune fait référence à la dimension client:

... 
RequesterCustomerID int, 
SignatoryCustomerID int, 
WitnessCustomerID int, 
BillableCustomerID int, 
... 

Bien sûr, si un client est à la fois un demandeur et un témoin alors vous avoir le même ID dans RequesterCustomerID et WitnessCustomerID parce que vous avez seulement une ligne pour lui dans votre dimension client. C'est complètement normal. Le scénario B est que tous les clients ont le même rôle, par ex. chaque contrat compte de 1 à 4 signataires. Si le nombre de signataires ne peut jamais être supérieur à 4, et si vous êtes sûr que cela sera toujours le cas, alors la solution simple est également d'avoir une ligne par contrat dans la table de faits avec 4 colonnes qui font référence au dimension client:

... 
SignatoryCustomer1 int, 
SignatoryCustomer2 int, 
SignatoryCustomer3 int, 
SignatoryCustomer4 int, 
... 

Même si la plupart des contrats ont seulement 1 ou 2 signataires, il ne fait beaucoup de mal à avoir 2 colonnes moins fréquemment utilisées dans le tableau.

Le scénario C est celui où un contrat a des clients 1-n, où n est un nombre qui varie considérablement et peut même être très important (recours collectif). Si vous avez 50 clients sur un contrat, l'ajout de 50 colonnes à la table des faits devient difficile à gérer. Dans ce cas, je voudrais ajouter une table de pont appelée ContractCustomers ou tout ce qui relie la table de faits avec la dimension client. Ce n'est pas aussi «soigné» que les autres solutions, mais un schéma en étoile pur n'est pas très bon pour gérer des relations n: m comme ça de toute façon.

Il peut également y avoir des cas plus complexes, où vous mélangez les scénarios A et C: un contrat a 3 demandeurs, 5 signataires, 2 témoins et la facture est répartie 3 fois entre les demandeurs. Dans ce cas, vous n'aurez pas d'autre choix que de créer une sorte de table de transition contenant la composition spécifique du client pour chaque contrat, car elle ne peut simplement pas être représentée correctement avec un seul fait et une seule table de dimension.

Answer 2

L'une ou l'autre manière peut fonctionner mais chaque solution a des implications différentes. Certes, vous avez besoin de tables client et contrat. Une question clé est la suivante: est-ce toujours un maximum de quatre ou peut-il éventuellement augmenter au-delà de cela? S'il reste à 4, vous pouvez avoir un groupe de 4 ID client récurrents dans le contrat. L'inconvénient de ceci est qu'il est fixe. Si un contrat n'en a pas quatre, il y a des espaces vides. Si, toutefois, il peut y en avoir plus de 4, la seule solution viable consiste à utiliser une table de transition, car dans une table de pont, vous ajoutez plus de clients en insérant de nouvelles lignes (sans modifier la structure de la table). Dans la solution fixe, dans ce cas, vous ajoutez plus de 4 clients en modifiant la table. Une table de bridge est un exemple de ce que, depuis de nombreuses décennies, la modélisation ER a appelé une entité associative. C'est la plus souple des deux solutions. Cependant, j'ai travaillé sur un système de marge une fois où les montants de marge importants nécessitaient cinq niveaux d'approbation du gestionnaire. Il a été cinq et sera toujours cinq, ils me l'ont dit. Chaque gestionnaire approbateur représentait un niveau organisationnel différent. Dans ce cas, nous avons utilisé un groupe répétitif de cinq identifiants de gestionnaire, un pour chaque niveau, et les avons inclus dans le commerce. Il est donc important de comprendre les règles commerciales actuelles et les perspectives d'avenir.