lundi 10 juin 2013

Conseil 21: Définir la granularité

L'étape la plus importante de la conception dimensionnelle est de déclarer le grain de la table de faits. Définir la granularité veut dire exactement ce qu'un enregistrement de la table de faits représente. Souvenez-vous qu'un enregistrement d'une table de fait capture une mesure. Voici quelques exemples:
  • un produit par ligne sur un ticket de caisse d'un client mesuré par un scanner
  • un virement sur une police d'assurance
  • une facture d'un médecin
  • un billet d'avion individuel de quelqu'un prenant un vol



Lorsque vous faites ce genre de déclaration, vous pouvez avoir une vision très précise des dimensions qui sont possibles ou non. Par exemple, si nous reprenons la facture d'un médecin, nous pourrions trouver les dimensions suivantes:
  • Date (du traitement)
  • Médecin
  • Patient
  • Procédure
  • Premier Diagnostic
  • Lieu (probablement le cabinet du médecin)
  • Partie responsable (soit le patient, soit le représentant légal du patient)
  • Premier payeur (souvent une assurance)
  • Second payeur (peut être le patient ou l'assurance d'une tierce personne)

Si vous avez suivi cet exemple, j'espère que vous avez remarqué les effets puissants issus de la déclaration du grain. Premièrement, nous pouvons visualiser la dimensionnalité d'une ligne de facture très précisément et nous pouvons avoir une vision relative des sources de données qui peuvent être attachées à  ces données. Par exemple, nous exclurons probablement "les résultats du  traitement" de cet exemple puisque les factures ne contiennent pas ce type d'information.

Mais, un modèle Entité/Relation reprenant les visites d'un médecin peut très bien contenir le résultat du traitement. Après tout, est ce que tous les traitements ne devraient pas avoir de résultats?

L'insistance sur la déclaration de la granularité en début de conception, vous permet d'éviter ce type d'erreur. Un modèle des visites facturées d'un médecin qui inclut les résultats des traitements peut ressembler à un modèle dimensionnel mais il ne sera pas réalisable.  
c'est mon principal problème avec les nombreuses offres de schémas standardisés. Comme ils n'accordent pas une grande attention à la granularité, ils combinent souvent des entités qui n'existent pas ensemble dans les vraies sources de données.

Le second avantage de la granularité à la ligne de facture d'un médecin est que le grain est très fin donnant ainsi accès à de nombreuses dimensions. Nous en avons listés 10 précédemment, et ceux d'entre vous qui êtes expert en facture de santé savent probablement qu'il en existe d'avantage. Il est intéressant de réaliser que plus la mesure est fine et atomique, et plus vous pouvez savoir de choses. Et bien sur, il y a plus de dimensions. C'est un autre moyen d'expliquer pourquoi les données atomiques conviennent aux requêtes ad-hoc des utilisateurs. Une donnée atomique possède plus de dimensions et donc elle peut être analysée de toutes les façons possible pour la source de données. Les données atomiques conviennent parfaitement à l'approche dimensionnelle.

Toutes les déclarations de granularité listées au début de cet article représentent la granularité la plus fine de chacune de ces sources de données. Ces mesures sont atomiques et ne peuvent plus être divisées. Mais il  est possible de déclarer une granularité supérieure en agrégeant ces données atomiques:
  • toutes les ventes d'un produit dans un magasin  dans une journée
  • le total des transactions de police d'assurance par mois et par métier
  • montant total par traitement par diagnostic et par mois
  • le nombre de passagers et plaintes  des passagers des autres vols  par route et par mois

Ces niveaux supérieurs d'agrégation ont souvent moins de dimensions. Notre médecin, par exemple, se retrouve avec les dimensions suivantes:
  • Mois
  • Médecin
  • Procédure
  • Diagnostic

Il pourrait être inconvenant dans une table de faits agrégés d'inclure toutes les dimensions du grain le plus fin car cela limiterait les agrégations  possibles.

Puisque les agrégations réduisent et suppriment des dimensions, il convient de réaliser que les données agrégées ont toujours besoin d'être utilisées en conjonction avec leurs données atomiques de base, parce que les données agrégées ont moins de détails.

Le résultat le plus important lorsqu'on définit la granularité d'une table de faits et d'aborder la discussion des dimensions. Cela permet également d'être clair à propos des mesures. Les mesures doivent être vraies pour le grain définit dans la table de faits. Dans l'exemple de notre médecin, le fait le plus évident est le montant de la facture. D'autres faits relatifs au traitement reçu par le patient peuvent être également possibles. Mais des mesures complémentaires comme le montant des soins du patient depuis le début de l'année pour ce patient n'est pas vrai pour cette granularité. Lorsque des faits sont combinés dans un rapport, les mesures qui  ne sont pas vraies au grain produisent des résultats qui n'ont pas de sens. Ils faut les retirer de la modélisation et calculer ces mesures agrégées dans votre application.

En résumé, essayez de faire vos modélisations dimensionnelles en suivant ces quatre étapes dans l'ordre suivant:
  1. décider quelles sont vos sources de données
  2. définir la granularité de la table de faits (de préférence au niveau le plus fin)
  3. ajouter toutes les dimensions associées à cette granularité
  4. ajouter les mesures qui sont vraies pour ce niveau de granularité




Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #21: Declaring the grain", publié le 21 mars 2001.

Aucun commentaire:

Enregistrer un commentaire