Ma compréhension de fait la granularité de la table est-elle correcte?
Moi-même et un autre DBA chez notre société sont chargés d'examiner une conception de base de données qu'un fournisseur s'est développé pour nous. Le vendeur a déclaré qu'ils utilisaient Kimball comme base de leur conception. (Remarque: je ne cherche pas d'arguments de Kimball vs Inmon, etc.) Ils ont conçu un marché avec plusieurs faits et dimensions.
Maintenant, dans toute l'équité, notre société n'a jamais conçu un marché unique. Nous avons toujours eu les consultants le faire. Et nous n'avons jamais été envoyés à des cours ou quoi que ce soit. Nous connaissons donc notre connaissance de l'entreposage/de la modélisation des marchés/dimensionnels, etc. est basée sur la petite expérience que nous avons, ce que nous pouvons trouver sur Internet et la lecture libre (nous avons des livres d'Inmon et de Kimball et essayons de passer à travers eux) .
Maintenant que la scène est fixée à mon niveau de connaissances, nous arrivons au défi de la conception.
Il existe une table de fait appelée "Statistiques de perte de réclamation" (ceci est pour l'assurance). Et ils essaient de capturer les deux paiements pour les revendications (roulés jusqu'à un niveau mensuel), puis de l'argent dans les réserves (type de compte bancaire pour les revendications). Ils souhaitent voir les montants mensuels pour les paiements (pas de biggie). Mais ils souhaitent voir le compte courant de la réserve des réserves.
Je vais donner un exemple pictural.
Disons que nous avons configuré 1000 USD dans des réserves pour une réclamation. Cela devient réservé (donc à certains égards, cela fonctionne comme un compte bancaire).
En octobre 2014, nous ne payons rien encore. Donc, l'entreprise veut voir les paiements et le solde de la réserve à la fin du mois d'octobre.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
Puis novembre vient. Nous distinguons des paiements de 100 $, 150 $ et 75 dollars. 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 puis dire que nous avons des paiements nuls en décembre puis 200 $ de plus en janvier 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 lutterai. Je crois comprendre que la partie des paiements est correcte. Ils sont tous rougés à un niveau mensuel au sein de chaque enregistrement. Donc, vous pouvez vous déplacer plus loin 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 à quel point est dans la balance chaque mois. Mais vous ne pouvez pas regrouper sur ce champ. Si vous l'avez fait, vous obtiendrez des résultats de Wonky.
D'une manière ou d'une autre, cela me frappe comme mal. Mais je ne peux pas dire honnêtement que j'ai assez modélisé ou je 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 devraient être à la même granularité.
Les deux chiffres sont à la même granularité d'un "mois", mais ils ne sont pas du point de vue de ce qu'ils représentent. L'un est des dollars globaux dans un délai d'un mois. L'autre n'est que l'équilibre.
Est-ce correct? Je repoussai ce design. Ai-je tort de le faire? Est-ce que ça va de faire cela en fait? Ou est mon sentiment de "odeur de code" d'une mauvaise conception exacte?
Toute aide serait appréciée. Remarque: s'il vous plaît ne dites pas simplement "ça devrait être de façon de voir x", veuillez expliquer pourquoi cela devrait être comme ça afin que je puisse apprendre de cela.
ÉDITER : Eh bien, j'ai appris que ma compréhension initiale du fait est fausse. La granularité est [~ # ~] non [~ # ~] Mensuel. La granularité est le niveau de transaction. Cela signifie donc dans le mois_year (c'est-à-dire qu'il s'agit vraiment de la période de rapport financier), il y aura plusieurs transactions de paiement et de récupération. Ceux-ci seront postés par date ou date de transaction. Mais à cause d'un rapport préalable, l'entreprise voit, et également en raison de la manière dont les données sont stockées dans le système héritée que cela vient de vouloir 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 que, je me rends compte que le problème n'était pas tant d'additif vs non additif, voire semi-additif, car il s'agissait de grain, ce que je soupçonnais du début. Notre équipe DBA a examiné cela avec l'équipe de projet et a déclaré qu'ils tentaient de mettre deux grains différents dans le même fait, ce qui n'était pas correct. Qu'ils devraient jouer sur les transactions à un niveau mensuel, leur permettant ensuite de disposer des paiements, des recouvrements et du solde de la réserve mensuel (c'est-à-dire un fait semi-additif), car tout serait à un grain mensuel. Ou ils doivent trouver un moyen de décomposer le solde de la réserve dans les transactions pour préserver le grain de niveau de transaction. Ou ils ont besoin de briser le fait en deux faits. On peut être le niveau mensuel pour le 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 mettre les paiements et les recouvrements à un niveau mensuel au niveau mensuel. Cela dépend simplement des besoins de l'entreprise.)
Compte tenu de ce que j'ai appris, je vais marquer la réponse de Thomas comme le correct. Cependant, je ressens la discussion que j'ai commencé avec la question initiale est toujours bonne pour que d'autres d'apprendre. Je quitterai donc 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é beaucoup Des malentendus que j'avais sur la modélisation dimensionnelle.
Votre intuition de l'odeur de code est bien perçue.
Ce que vous traitez sur reserves est ce que Kimball appelle un "fait semi-additif". Il ne roule pas bien au quart ou à l'année.
La solution typique à cela consiste à avoir deux tables de fait, une pour le fait additif (payments dans votre cas) et un pour le fait non additif. Le fait non additif n'a pas réellement besoin d'avoir un grain au niveau du mois, vous pourriez les stocker tout au long de la journée et que les choses fonctionnent encore.
Le fait non-additif, reserve, est interrogé différemment que l'autre fait. Il y a une décision d'affaires que vous devez faire: qu'est-ce que reserve au niveau de l'année signifie? Est-ce le dernier mois de l'année, ou peut-être la moyenne des mois de l'année? Quel que soit le choix que vous faites, vous pouvez trouver la solution pour la modéliser dans les livres de kimball sous les chapitres des faits non additifs.
Veuillez noter que si vous utilisez un produit CUBE comme des services d'analyse, il est possible d'avoir les agrégats "Work" même si vous stockez tout dans une table. Cependant, je préfère garder les choses séparées afin que les requêtes relationnelles sont 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 fait ".
Mais le solde de la réserve à la fin du mois et la somme des paiements à la fin du mois sont au même grain. Ce n'est que l'un des faits est semi-additif . Type de fait (additif ou non) ne définit pas le grain de la table.
De ce que vous décrivez, je vois votre grain comme "instantané de réclamation mensuel", qui fait votre table de fait " tableau de fait instantané périodique ".
Dans cet article kimball a un exemple de faits additifs et semi-additifs dans la même table de fait.
Voici un exemple d'instantané périodique avec des faits semi-additifs de Toolkit de données de données (page 116):
La meilleure pratique consiste à avoir une table de fait transactionnelle qui reflétera chaque changement de réserve (paiements et ajustements) au niveau atomique le plus bas. Lorsque vous traitez avec des réclamations, le niveau atomique n'est souvent pas réclamé, mais une sous-revendication (votre compagnie d'assurance peut avoir son propre mandat). Généralement, chaque sous-revendication représentera une partie différente de la réclamation et des paiements/réserves de chaque partie. Par exemple, il peut ne pas y avoir de paiements à l'assuré, mais des paiements à non assurés par votre entreprise blessé et des paiements à l'hôpital et à l'avocat.
En fonction des performances de votre outil BI, vous pouvez utiliser une table de fait transactionnelle directement pour obtenir des paiements et des soldes mensuels. Ou vous pouvez mettre à jour la table de fait instantanée périodique du quotidien transactionnel ou à la fin du mois.
La capacité de traitement des faits semi-additifs dépendra de la couche BI que vous utilisez. Certains outils capables de traiter facilement avec des faits semi-additifs et certains non.
Le livre principal de Kimball ( la boîte à outils de données Warehouse ) a le chapitre complet (16) sur l'assurance.