Ma compréhension de la granularité de la table de faits est-elle correcte?

Moi-même et un autre DBA de notre entreprise sont chargés d'examiner une conception de base de données qu'un fournisseur a développée pour nous. Le vendeur a déclaré qu'ils utilisaient Kimball comme base pour leur conception. (REMARQUE: je ne cherche pas d'arguments de Kimball vs Inmon, etc.) Ils ont conçu un magasin avec plusieurs faits et dimensions.

Maintenant, en toute équité, notre entreprise n'a jamais conçu un seul marché. Nous avons toujours demandé aux consultants de le faire. Et nous n'avons jamais été envoyés en cours ou quoi que ce soit. Donc, notre connaissance de l'entreposage / marts / modélisation dimensionnelle, etc. est basée sur le peu d'expérience que nous avons, ce que nous pouvons trouver sur Internet et la lecture personnelle (nous avons les livres d'Inmon et de Kimball et essayons de nous frayer un chemin à travers eux) .

Maintenant que la scène est prête pour mon niveau de connaissances, nous arrivons au défi du design.

Il existe un tableau de faits intitulé «Statistiques sur les sinistres» (il s'agit de l'assurance). Et ils essaient de capturer à la fois les paiements pour les réclamations (cumulés à un niveau mensuel), puis l'argent dans les réserves (un peu comme un compte bancaire pour les réclamations). Ils souhaitent voir les montants mensuels des paiements (pas de biggie). Mais ils souhaitent voir le solde courant des réserves.

Je vais donner un exemple pictural.

Supposons que nous ayons mis en place 1 000 USD de réserves pour une réclamation. Cela est mis de côté (donc à certains égards, il fonctionne un peu comme un compte bancaire).

En octobre 2014, nous ne payons encore rien. L'entreprise veut donc voir les paiements et le solde des réserves fin octobre.

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------

Puis novembre arrive. Nous effectuons des paiements de 100 $, 150 $ et 75 $. Ils souhaitent voir ces montants agrégés et la réserve au solde comme suit:

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------

Et dire ensuite que nous n'avons aucun paiement en décembre et 200 $ de plus en janvier de l'année prochaine.

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------
-      122014  -      0.00 -           675.00 -
-----------------------------------------------
-       12015  -    200.00 -           475.00 -
-----------------------------------------------

Voici où je lutte. Je crois comprendre que la partie des paiements est correcte. Ils sont tous regroupés au niveau mensuel dans chaque enregistrement. Vous pouvez donc continuer à faire des rollups si vous le souhaitez pour l'année, le trimestre, etc.

Mais le montant des réserves est différent. C'est un équilibre. Et l'entreprise veut voir combien il en reste à chaque mois. Mais vous ne pouvez pas agréger sur ce champ. Si vous le faisiez, vous obtiendriez des résultats bancaux.

D'une certaine manière, cela me semble faux. Mais je ne peux pas dire en vérité que j'ai assez modélisé ou que j'en sais assez. Tout ce que je peux dire, c'est ce que je sais. Et d'après ce que je sais, toutes les valeurs d'un fait devraient être à la même granularité.

Les deux nombres sont à la même granularité d'un "mois", mais ils ne sont pas du point de vue de ce qu'ils représentent. La première consiste à cumuler des dollars dans un mois. L'autre n'est que l'équilibre.

Est-ce correct? J'ai repoussé cette conception. Ai-je tort de le faire? Est-ce correct de le faire dans un fait? Ou mon sens de "l'odeur de code" d'une mauvaise conception est-il précis?

Toute aide serait appréciée. REMARQUE: s'il vous plaît, ne dites pas simplement "cela devrait être le chemin X", veuillez expliquer pourquoi cela devrait être ainsi afin que je puisse en tirer des leçons.

EDIT : Eh bien, j'ai appris que ma compréhension initiale du fait est fausse. La granularité n'est PAS mensuelle. La granularité est au niveau de la transaction. Cela signifie donc qu'au cours de MONTH_YEAR (c'est-à-dire qu'il s'agit vraiment de la période de reporting financier), il y aura plusieurs transactions de paiement et de recouvrement. Ceux-ci seront affichés par date ou date de transaction. Mais à cause d'un rapport antérieur que l'entreprise voit, et aussi à cause de la façon dont les données sont stockées dans le système hérité dont elles proviennent, elles voulaient mettre à la fois les données transactionnelles (une ligne par) et le solde mensuel de réserve (une ligne par mois) ).

Une fois que j'ai appris cela, je me rends compte que le problème n'était pas tant additif vs non additif, ou même semi-additif que c'était du grain, ce que je soupçonnais depuis le début. Notre équipe DBA en a discuté avec l'équipe du projet et a indiqué qu'elle tentait de mettre deux grains différents dans le même fait, et ce n'était pas correct. Qu'ils devraient soit classer les transactions à un niveau mensuel, leur permettant alors d'avoir les paiements, les recouvrements et le solde de réserve mensuel (c'est-à-dire un fait semi-additif) parce que tout serait à un grain mensuel. Ou ils doivent trouver un moyen de décomposer le solde des réserves en transactions pour préserver le grain au niveau des transactions. Ou ils doivent diviser le fait en deux faits. L'un peut être le niveau mensuel du solde de la réserve. L'autre peut être au niveau de la transaction pour les paiements et les recouvrements. (Il n'y a aucune raison pour laquelle ils ne pouvaient pas non plus placer les paiements et les recouvrements à un niveau mensuel dans le fait du niveau mensuel. Cela dépend simplement des besoins de l'entreprise.)

Compte tenu de ce que j'ai appris, je noterai la réponse de Thomas comme la bonne. Cependant, je pense que la discussion que j'ai commencée avec la question d'origine est toujours une bonne chose pour les autres, donc je vais laisser la partie originale de ma question intacte. J'ai également l'intention d'attribuer une prime à la réponse de nikadam, car cela m'a beaucoup appris sur les faits additifs, non additifs et semi-additifs, et corrigé de nombreux malentendus que j'avais sur la modélisation dimensionnelle.

Votre intuition de l'odeur de code est bien affûtée.

Il reserves s'agit de ce que Kimball appelle un «fait semi-additif». Il ne se déroule pas bien au trimestre ou à l'année.

La solution typique à cela est d'avoir deux tables de faits, une pour le fait additif ( paymentsdans votre cas) et une pour le fait non additif. Le fait non additif n'a pas vraiment besoin d'avoir un grain au niveau du mois, vous pouvez les stocker jusqu'au jour et les choses fonctionnent toujours.

Le fait non additif reserve,, est interrogé différemment de l'autre fait. Vous devez prendre une décision commerciale: que signifie reserveau niveau de l'année? Est-ce le dernier mois de l'année, ou peut-être la moyenne des mois de l'année? Quel que soit votre choix, vous pouvez trouver la solution pour le modéliser dans les livres de Kimball sous les chapitres sur les faits non additifs.

Veuillez noter que si vous utilisez un produit de cube comme Analysis Services, il est possible que les agrégats "fonctionnent" même si vous les stockez tous dans une seule table. Cependant, je préfère garder les choses séparées pour que les requêtes relationnelles soient plus faciles à écrire (et les faits sont plus faciles à charger aussi).

Vous avez raison: " différents grains ne doivent pas être mélangés dans la même table de faits ".

Mais le solde des réserves à la fin du mois et la somme des paiements à la fin du mois sont au même grain. Ce n'est qu'un des faits est semi-additif . Le type de fait (additif ou non) ne définit pas le grain de la table.

D'après ce que vous décrivez, je vois votre grain comme un «instantané mensuel des réclamations», ce qui fait de votre tableau de faits un «tableau récapitulatif périodique des faits ».

Dans cet article, Kimball présente un exemple de faits additifs et semi-additifs dans la même table de faits.

Voici un exemple d'instantané périodique avec des faits semi-additifs de The Data Warehouse Toolkit (page 116):

La meilleure pratique consiste à disposer d'un tableau des faits transactionnels qui reflétera chaque changement de réserve (paiements et ajustements) au niveau atomique le plus bas. Lorsque vous traitez des réclamations, le niveau atomique n'est souvent pas une réclamation mais une sous-réclamation (votre compagnie d'assurance peut avoir son propre terme pour cela). Généralement, chaque sous-réclamation représentera une partie différente de la réclamation et des paiements / réserves pour chaque partie. Par exemple, il peut n'y avoir aucun paiement aux assurés, mais des paiements aux non-assurés par la personne blessée de votre entreprise et des paiements à l'hôpital et au procureur.

Selon les performances de votre outil de BI, vous pouvez utiliser directement la table de faits transactionnels pour obtenir les paiements et les soldes mensuels. Ou vous pouvez mettre à jour le tableau récapitulatif périodique des faits à partir des transactions quotidiennes ou à la fin du mois.

La capacité de gérer des faits semi-additifs dépendra de la couche BI que vous utilisez. Certains outils sont capables de traiter facilement des faits semi-additifs et d'autres non.

Le livre principal de Kimball ( The Data Warehouse Toolkit ) contient un chapitre complet (16) sur l'assurance.