Conception d'un entrepôt de données avec plusieurs tables de faits

Question

Je suis novice dans le domaine de l'entreposage de données. Tout d'abord, je ne veux pas préciser que ma copie de The Datawarehouse Toolkit est sur le chemin de ma boîte aux lettres (snail mail: P). Mais j'étudie déjà toutes ces choses avec ce que je trouve sur le net. Ce que je ne trouve pas sur le net, cependant, est ce qu'il faut faire quand vous semblez avoir plus d'un fait dans un document. Dans mon cas (assurance), j'ai des remboursements qui se produisent sur une base non régulière. Un client ne peut en avoir aucun pendant 3 mois et ensuite 10 dans les mêmes mois. D'autre part, j'ai "frais d'abonnement" (je ne sais pas quel est le terme anglais correct, mais vous obtenez le point), qui se produisent tous les mois ou tous les trois mois. Cela semble cleraly comme deux faits distincts à moi.

Celles-ci sont également faiblement couplées par certaines dimensions, comme le client ou le «produit d'assurance». Maintenant, est-ce que ces deux différents entrepôts, sur lesquels je dois produire deux rapports différents, puis connecter les rapports en dehors du DW? Ou existe-t-il un moyen de concevoir cela pour s'adapter à une seule descente DW. Ou devrais-je combiner ces deux faits en un? Je perdrais probablement la granularité sur les remboursements alors.

Un blog que j'ai lu dit qu'un DW a toujours une table de faits. D'autres mentionnent l'étape de la conception de ce que sont les tables de faits avec un S, mais il n'y a pas d'instructions claires s'il existe un lien entre elles ou si elles ne sont que des composants distincts d'un même projet DW.

Est-ce que quelqu'un connaît quelques références sur cette partie précise de la conception de DW?

Answer 1

Prendre vos questions à l'envers.

Un entrepôt de données peut avoir plusieurs tables de faits. Cependant, vous voulez minimiser les jointures entre les tables de faits. Il est possible de dupliquer des informations factuelles dans différentes tables de faits.

des objets, vous avez mentionné:

remboursement est un fait. L'horodatage est la dimension du fait de remboursement.

Les frais d'abonnement sont un fait. L'horodatage est la dimension du fait de l'abonnement.

Un remboursement peut avoir lieu plus d'une fois. Je suppose que chaque client a un abonnement. Donc, il semble que nous ayons deux tables de faits à ce jour, le client et le remboursement des clients. Si vous saviez qu'il ne peut y avoir qu'un maximum de 3 remboursements (à titre d'exemple), alors vous éliminez la table des faits de remboursement du client et vous placez 3 colonnes de remboursement dans la table client.

Vous mentionnez également l'assurance. Un client peut avoir plus d'une politique. Nous avons donc une troisième table de faits.

Un entrepôt de données est généralement conçu en utilisant un star schema. Le schéma en étoile est essentiellement une table de faits connectée à une ou plusieurs tables de dimension. Vous aurez probablement plus d'une étoile dans un entrepôt de données, puisque nous avons déjà défini 3 tables de faits.

Answer 2

Vous pouvez avoir autant de tables de faits que vous le souhaitez. Dans votre exemple, vous pouvez avoir quelque chose comme:

DimProduct énumère plusieurs produits - abonnement étant l'un d'entre eux. dimTransactionType énumérerait opérations possibles (achat, remboursement, frais d'abonnement récurrents ...)

Supposons maintenant que vous êtes intéressé par les rapports d'abonnement simplifié, vous pouvez ajouter un factSubscription comme ceci:

Answer 3

Je me rends compte que je réponds à un ancien message, mais je ne suis pas satisfait de l'une ou l'autre des réponses fournies. Je pense que ni répondu à la question. Un schéma peut avoir un ou plusieurs faits, mais ces faits ne sont liés par aucune relation clé. Il est recommandé de ne pas joindre les tables de faits dans une seule requête, comme vous le feriez pour une base de données normalisée/transactionnelle. En raison de la nature de plusieurs à plusieurs jointures, etc - les résultats seraient incorrects si tenté.

La réponse que vous recherchez est que vous devez "explorer", ce qui signifie que vous interrogez séparément chaque table de faits (schéma) et fusionnez les résultats. Cela peut se produire en utilisant SQl ou de préférence via un outil de reporting/analytique que vous pouvez avoir qui référencé l'entrepôt de données. Au lieu de dupliquer les réponses sur la façon de ce faire, je vais diriger tout le monde à deux très bons articles:

Three ways to drill across by Chris Adamson

et

Should of the Warehouse - Drilling Across by Ralph Kimball