Conseil 71: le nommage des champs

La question de la dénomination des champs se pose lorsque vous créez le modèle de données dimensionnel. Le nommage est complexe parce que les gens ont des significations différentes pour un même nom, comme "chiffre d'affaire", et des noms différents avec le même sens, comme "ventes". La difficulté vient de la nature humaine: la plupart d'entre nous ne voulont pas renoncer à ce que nous savons pour apprendre une nouvelle façon. La tâche peu enviable de déterminer les noms tombe généralement sur le gestionnaire des données. Si vous êtes responsable de cette tâche, vous trouverez l'approche suivante en trois étapes utile. Les étapes 1 et 2 se produisent généralement avant que le modèle soit présenté aux utilisateurs métiers. L'étape 3 arrive généralement après que les utilisateurs métiers aient vu et compris le modèle.

Conseil 69: Identifier les processus métiers

Les lecteurs qui suivent l'approche de Kimball peuvent souvent réciter les quatre décisions clés de la conception d'un modèle dimensionnel: identifier le processus métier, la granularité, les dimensions et les faits. Bien que cela semble simple, les équipes butent souvent sur ​​la première étape. Ils peinent à définir le processus métier, car c'est un terme qui semble prendre un sens différent selon le contexte. Puisque l'identification du processus métier est le premier point de la conception d'un modèle dimensionnel, nous voulons éliminer la confusion dans notre contexte.

Tout d'abord, nous allons commencer par discuter de qu'un processus métier n'est pas. Lors de la conception d'un modèle dimensionnel, le processus métier ne se réfère pas à une direction de l'organisation ou à une fonction. De même, il ne doit pas faire référence à un seul rapport ou à une analyse spécifique.

Pour un concepteur décisionnel, le processus métier est un événement ou une activité qui génère ou recueille des métriques. Ces mesures sont des mesures de performance pour l'organisation. Les analystes d'affaires veulent les examiner et les évaluer selon une combinaison illimitée de filtres et de contraintes. En tant que concepteur, il est de notre devoir de présenter ces mesures dans une structure facile à comprendre qui répond rapidement aux demandes imprévisibles.

Lors de l'identification du processus métier pour la modélisation dimensionnelle, des caractéristiques et des tendances communes émergent souvent.

1. Les processus métiers sont généralement pris en charge par un système opérationnel. Par exemple, le processus de facturation de l'entreprise est soutenue par un système de facturation; de même pour les processus achats, commandes, ou reception.
2. Les processus métiers génèrent ou recueillent des mesures uniques avec une granularité et une dimensionnalité unique utilisées pour évaluer la performance de l'organisation. Parfois, les mesures sont le résultat direct du processus métier. D'autres fois, les mesures en sont dérivées. Peu importe, les processus métiers fournissent des indicateurs de performance utilisés par divers procédés analytiques. Par exemple, le processus de gestion des commandes de vente entraine de nombreux rapports et analyses, telles que l'analyse de la clientèle, la performance des commerciaux, et ainsi de suite.
3. Les processus métiers sont souvent exprimés comme des verbes d'action avec les dimensions associées comme des noms décrivant le qui, quoi, où, quand, pourquoi et comment liées au processus. Par exemple, les résultats du processus de facturation de l'entreprise seront découpés et analysés par date, client, service/produit, et ainsi de suite.
4. Les processus métiers sont généralement déclenchés par une entrée et produisent un résultat en sortie qui doit être surveillé. Par exemple, une proposition acceptée est entrée dans le processus de commande qui se traduit par un bon de commande et ses paramètres associés. Dans ce scénario, le processus métier est la commande de vente. Vous aurez donc une table de faits des commandes avec la commande client comme dimension - potentiellement dégénérée - et les montants et le nombre de commande comme faits. Essayez d'imaginer le flux général d'entrée d'un processus métier, et créant des métriques en sortie. Dans la plupart des organisations, il existe un ensemble de processus métiers où les résultats de l'un deviennent les entrées d'un autre. Dans le langage d'un concepteur décisionnel, ces processus métiers se traduiront par une série de tables de faits.
5. Les analystes veulent parfois croiser les processus métiers, comparant ainsi le résultat d'un processus à celui d'un autre. Croiser les processus est certainement réalisable si les dimensions communes aux deux processus sont conformes .

Déterminer les processus métiers de base de votre organisation est essentielle pour établir le cadre global de vos modèles dimensionnels. La meilleure façon de déterminer ces processus est d'être à l'écoute des utilisateurs. Quels sont les processus qui génèrent les indicateurs de performance les plus intéressants pour suivre l'activité? Dans le même temps, l'équipe de l'entrepôt de données doit évaluer les réalités de l'environnement source pour fournir les données convoitées par l'entreprise.

Un dernier commentaire ... Il va sans dire qu'un tableau de bord n'est pas un processus métier, il présente seulement les résultats de la performance de nombreux processus métiers différents.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #69: Identifying business processes", publié le 5 juillet 2005.

Conseil 68: Forer latéralement dans les données avec SQL

Le forage latéral fait réfèrence au processus qui interroge plusieurs tables de faits et en combine les résultats dans un ensemble de données unique. Un exemple courant consiste à combiner les données prévisionnelles avec des données réelles. Les données prévisionnelles sont généralement conservées dans une table séparée, capturé à un niveau de détail différent de celui des données réelles. Quand un utilisateur veut un rapport qui compare le réel et le prévisionnel par client, la requête doit mixer deux tables de faits. (Note: les données des deux tables de faits peuvent être combinées uniquement si elles sont construites en utilisant des dimensions conformes. Le client, la date et toutes autres dimensions partagées doivent être exactement les mêmes dans les deux schémas en étoile).

Le moyen le plus efficace de combiner les données des deux tables de fait est d'exécuter des requêtes distinctes sur chaque table, puis de combiner les deux ensembles de résultats en faisant correspondre leurs attributs communs. Cette solution focntionne bien car la plupart des optimiseurs de base de données reconnaissent chaque requête unique et retournent rapidement les deux ensembles de résultats.

Conseil 67: Maintenir des références vers les sources opérationnelles

Nos entrepôts de données sont de plus en plus orientés vers le suivi des opérations détaillées des clients en quasi temps réel. Et comme Patricia Seybold souligne dans son livre, Customers.com (Times Business, 1998), la gestion des relations client, c'est avoir accès aux données de tous les processus d'une organisation en relation avec les clients.

Garder les informations détaillées issues de tous les processus faisant face aux clients, et en même temps fournir une vision intégrée, présente un défi intéressant pour l'architecte ETL. Supposons que nous ayons une entreprise orientée client avec une quinzaine de systèmes en relation avec celui-ci comme la gestion des ventes des magasins, des ventes en ligne, des livraisons, des paiements, des crédits, des contrats de maintenance, des centres d'appels et diverses formes de communications commerciales. Beaucoup de ces systèmes créent leur propre clé naturelle pour chaque client, et certains d'entre eux ne traitent pas les doublons se référant à un même client. Au final, Il se peut que nous n'ayons aucun identifiant client unique et fiable à travers tous ces systèmes.