Dans cet article, nous revenons sur un concept fondamental qui déconcerte de nombreux modélisateurs décisionnels: les faits de type texte.
Certains d'entre vous observerons à juste titre que les faits de type texte sont un oxymore de la modélisation décisionnelle. Toutefois, nous avons souvent à répondre aux questions de clients et d'étudiants sur des champs indicateur, type ou commentaire qui semblent appartenir à la table de faits, mais dont les valeurs ne sont pas assimilées à des clés, des mesures ou des dimensions dégénérées.
En règle générale, nous recommandons de ne pas modéliser ces soi-disant faits de type texte dans la table de faits, mais plutôt de tenter de trouver une place qui leur convient dans une table de dimension. Vous ne voulez pas encombrer la table de faits avec plusieurs champs descriptifs de taille moyenne (20 à 40 octets). Egalement, vous ne devriez pas simplement stocker des codes dans la table de faits (sans dimension associée pour les décoder), même si nous sommes tout à fait certain que tout le monde en connait déjà la signification.
Lorsqu'on est confronté à des faits de type texte, la première question à se poser est de savoir s'ils appartiennent à une autre table de dimension? Par exemple, le type de client a probablement une valeur unique par client et doit être traité comme un attribut de la dimension Client.
S'ils ne correspondent pas parfaitement à une dimension existante, alors ils devraient être traités comme étant des dimensions distinctes ou des attributs distincts dans une dimension fourre-tout. Il serait facile de construire de petites tables de dimension qui affectent des clés à tous les types de paiement ou de transaction, et ensuite de référencer ces clés dans la table de faits. Si nous obtenons un trop grand nombre de ces petites tables de dimension, vous devriez envisager la création d'une dimension fourre-tout. Il y a plusieurs facteurs à prendre en compte pour savoir s'il convient de maintenir des dimensions distinctes ou s'il est préférable de regrouper les indicateurs dans une dimension fourre-tout.
- Le nombre de clés étrangères dans la table de faits pointant vers des dimensions existantes. Si vous approchez d'une vingtaine de clés étrangères, alors vous aurez probablement envie d'en regrouper certaines.
- Le nombre de lignes potentielles créées par les combinaisons de champs d'une dimension fourre-tout. Comprenez que le nombre de combinaisons théoriques sont susceptibles de dépasser largement les combinaisons rencontrées réellement. Idéalement, nous aimerions avoir une taille inférieure à 100 000 lignes pour la dimension fourre-tout.
- La pertinence métier ou la compréhension des combinaisons d'attributs. Est ce que les attributs ont si peu à voir les uns avec les autres que les utilisateurs sont désorientés par l'association faite dans la dimension fourre-tout?
Enfin, que devez-vous faire quand le "fait" supposé est un champ de texte libre qui prend des valeurs illimitées, comme un champ de commentaire de 255 octets? Profiler le champ, puis l'analyser et le codifier, le rendrait plus utile analytiquement, mais c'est presque toujours plus facile à dire qu'à faire.
Par expérience, si le champ est vraiment un texte libre, il est rarement accessible analytiquement. Habituellement, ces zones de commentaires sont seulement utilisées de manière occasionnelle pour appuyer des analyses détaillées de transactions douteuses. Dans ce cas, vous aurez envie de mettre le texte dans une dimension distincte plutôt que d'ajouter ce volume supplémentaire à chaque enregistrement de la table de faits.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #55: Exploring text facts", publié le 9 juin 2004.
Aucun commentaire:
Enregistrer un commentaire