Gestion de ressources humaines.

Les questions que l’on peut se poser concernant les employés d’une entreprise peuvent être très complexes. Pour pouvoir y répondre, il faut construire une table de faits au grain de la transaction employé. Cette table peut ne pas avoir de faits (i.e. pas de valeur numérique).
La dimension Date et Heure est supposée suffisamment fine pour qu’une ligne de transaction soit identifiée par ses dimensions (employé, type de transaction, date, heure).
Suite à une transaction employé, son profil change et le changement doit être répercuté dans la dimension Employé. Comme chaque ligne de transaction ajoutera une ligne dans la dimension, il est plus judicieux de mettre les transactions dans la dimension et d’oublier la table de faits.
Pour chaque ligne, il faut indiquer une date de fin de transaction qui permet de connaître facilement la période de validité d’un profil. Il faut éviter de mettre null, il vaut mieux mettre une date dans le futur pour la dernière transaction et une colonne supplémentaire avec un indicateur de validité actuelle permettant de trouver immédiatement le profil actuel.
Pour les dimensions à évolution lentes de type 2, il est conseillé d’horodater la prise d’effet et l’expiration et d’avoir un indicateur de « ligne courante ».
La table de faits sera un instantané périodique mensuel dans lequel on peut cumuler le nombre de jours de congés acquis, utilisés, le nombre de promotions…
A cette table de faits, on peut ajouter une dimension Audit qui nous dira pour chaque ligne la provenance des données, la confiance dans les données. Cette dimension contient en fait des méta-données.

Pour grouper les employés selon leur compétence, on peut utiliser une table de dimension déportée stockant des mots-clés représentant leur compétence.
Pour les employés à compétence multiple, le langage SQL ne permet pas simplement de gérer des contraintes sur plusieurs lignes. Il faut donc utiliser UNION et INTERSECTION. UNION permet d’avoir les employés ayant l’une OU l’autre des compétences. INTERSECTION donne ceux qui ont l’une ET l’autre des compétences.
Une autre façon d’obtenir ce résultat est de définir une seule ligne pour chaque groupe de compétences avec une colonne contenant une liste des mots-clés concaténés séparés par \. Le SQL serait alors simplement

SELECT … WHERE liste_aptitudes LIKE ‘%unix%’
| OR |
| AND | liste_aptitudes LIKE ‘%linux%’
La recherche avec % en début de chaîne étant coûteuse, il faut éviter cette méthode sur de trop grandes tables.

Un questionnaire d’enquête a une table de faits contenant les réponses pour chaque (dimension) « date d’envoi du questionnaire », « date de réception du questionnaire », employé évalué, employé répondant au questionnaire, type de réponse.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.

Ce chapitre porte sur la comptabilité générale.
En général, il faut deux tables de faits pour les transactions et les instantanés périodiques de clôture de période.

Instantané périodique.
Bien que semi-additif, le solde de fin de période doit figurer dans la table de faits pour éviter d’avoir à le recalculer en remontant à l’origine des temps.
Par contre, les totaux sur une période à la date du jour doivent être calculés et non pas stockés dans la table de faits.

Si différentes devises sont utilisées, il faut ajouter la dimension Monnaie et mettre dans la table de faits les montants dans la monnaie locale et dans la monnaie officielle de l’entreprise.

Transactions de journaux de comptabilité générale.
Les faits sont les crédits et débits. Cette table peut avoir besoin de plusieurs calendriers comptables, si les filiales ne se basent pas sur les mêmes périodes comptables par exemple.

Budget.
Pour gérer le budget et pouvoir le comparer avec les dépenses, on créé une table de faits (additifs) donnant le montant budgété net et ses changements (relatifs pour rester additifs) éventuels en cours d’année. Les dimensions peuvent être la Date d’effet, le compte de comptabilité générale, la ligne d’articles de buget, la hiérarchie de l’entreprise…
Le livre « Data Warehouse Design Solutions » (Wiley, 1998) de Chris Adamson et Mike Venerable est recommandé pour son étude complète sur la chaîne budgétaire.

Table de faits consolidés (ou tables de faits de second niveau).
Ces tables de faits permettent de rapprocher des faits différents dans une même table. La contrainte est que la granularité est définie par le plus petit grain commun aux différents faits. De même les dimensions d’une table de faits consolidés doivent être les dimensions communes aux différents faits.
Il ne faut pas chercher à rendre des faits plus fins que prévus, ni à ajouter des dimensions artificielles pour forcer à garder un grain fin. Il peut s’avérer nécessaire d’agréger des données en supprimant des dimensions ou en passant à un grain plus gros.

Pour l’analyse financière, il existe des produits OLAP bien adaptés, mais leur intégration dans un entrepôt de données global nécessite toujours une mise en conformité des dimensions.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.

Le chapitre 6 traite de la relation client qui est devenue centrale pour l’entreprise ces dernières années. La GRC (Gestion des Relations Client) ou CRM (Customer Relationship Management) nécessite de définir précisément une dimension client conforme. Il existe des solutions GRC clés en main, mais celles-ci doivent s’intégrer à l’informatique de l’entreprise si on ne veut pas qu’elle devienne simplement une source supplémentaire d’informations incohérentes.

La dimension client est généralement très complexe. Elle peut être énorme : plusieurs centaines de milliers de lignes et plusieurs milliers d’attributs.

Concernant les noms et adresses, ceux-ci doivent être stockés à l’aide des « briques » les plus élémentaires possibles (par ex. : n° de rue, nom de rue, type de voie, boite postale, bâtiment…). La gestion de l’internationalisation est très complexe. Elle est traitée par Toby Atkinson dans « Merriam Webster’s Guide to International Business Communications » (Merriam-Webster, 1999).

Les clients ont également beaucoup d’attributs date (date de 1er achat, date de dernier achat, date de naissance…) qui doivent utiliser la dimension Date déjà vue, à l’aide de copies. La dimension Date jointe à la dimension Client est une dimension dite déportée, qui se justifie du fait de la taille de la dimension Client.

Parmi les attributs des clients, on trouve les attributs de segmentation (sexe, âge, score indiquant le comportement,…), les attributs représentant des faits agrégés (total des dépenses…).

Une autre dimension déportée comme la géographie peut aussi être justifiée par la relative indépendance par rapport au client. On obtient alors un modèle en flocons de neige.

Les dimensions Client sont souvent des « grandes dimensions à changement rapide ». Pour gérer ce type de dimension, on crée une ou plusieurs minidimensions, chargées de stocker les attributs variant souvent ou fréquemment analysés, comme l’âge, le salaire… Concernant les attributs variant de façon continue, comme le salaire, il faut stocker dans la minidimension des tranches de salaire seulement, quitte à laisser le salaire exact dans la table de faits. La table de faits se voit ajouter une clé étrangère pointant sur la minidimension. S’il y a besoin d’analyser les clients en fonction d’attributs de la minidimension, alors on peut faire une dimension déportée (en faisant une jointure avec la table client) en plus d’une minidimension (jointe sur la table de faits). Cependant la clé externe dans la dimension Client doit être de type 1 (i.e. écrasée à chaque changement).
Les minidimensions doivent éviter de dépasser les 100.000 lignes.
Dans le cas où les clients ont une structure hiérarchique récursive de profondeur variable, il est possible d’utiliser une table passerelle gérant les liens entre les clients.

Cette approche permet d’utiliser le SQL standard pour les groupements et cumuls, mais il est souhaitable d’utiliser des outils OLAP non relationnels pour simplifier les requêtes. « Cette approche tente de rapprocher deux structures intrinsèquement différentes, [... cela] revient à mélanger de l’huile et de l’eau. »

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.

Notion de jeux de rôles : si la date apparaît plusieurs fois dans une ligne de la table de faits, il faut créer des vues différentes de la table Date, en prenant soin de nommer différemment à la fois la table et les colonnes (par ex. « jour de commande » et « jour de livraison »…).

Concernant la dimension Produit qui est très courante, ses caractéristiques sont :

• un grand nombre de colonnes de texte descriptives.
• une ou plusieurs hiérarchies en plus d’un grand nombre d’attributs non hiérarchisés.

Cette dimension peut posséder plusieurs milliers de lignes et quelques précautions doivent être prises lors de la création de cette table à partir d’un fichier maître.

• Faire correspondre à la clé Produit opérationnelle une clé Produit artificielle.
• Insérer des séquences de texte lisibles remplaçant ou complétant les codes numériques du fichier maître Produit opérationnel.
• Contrôler tous les champs de texte pour éviter les erreurs d’orthographe, de valeurs impossibles ou des versions différentes du même attribut.
• Documenter les définitions, les interprétations et les sources des attributs des produits dans les métadonnées de l’entrepôt.

La dimension adresse de livraison.

Il est normal d’avoir plusieurs hiérarchies indépendantes dans cette table. Une hiérarchie naturelle est la hiérarchie géographique avec le pays, la région, le département, la ville, le lieu. Une autre hiérarchie possible est une hiérarchie par entreprise (une adresse de facturation peut regrouper plusieurs adresses de livraison). Les différentes hiérarchies peuvent avoir différents niveaux. Il peut arriver que la relation entre adresse de facturation et de livraison ne soit pas strictement hiérarchique (i.e. plusieurs factures pour une livraison). Dans ce cas, le grain de la table de dimension peut être affiné au niveau de la combinaison adresse de facturation/adresse de livraison, si cette relation non strictement hiérarchique reste exceptionnelle.

Sinon, il est préférable de définir une dimension supplémentaire « Adresse de facturation ». Il est inutile de créer une table portant les relations entre les deux dimensions, la table de faits porte déjà cette relation et répond efficacement à la question des corrélations entre dimensions.

La dimension dégénérée du numéro de commande n’est reliée à aucune table de dimension (c’est le propre d’une dimension dégénérée) car toutes les informations de la commande sont conservées dans les autres dimensions. Par contre, elle peut servir à regrouper les articles commandés ensembles. D’une façon générale, les dimensions dégénérées sont réservées à l’identification des transactions. Elles ne doivent surtout pas servir à stocker un code sans que sa réelle signification soit décrite dans une autre table.

La dimension fourre-tout (junk dimension) sert à stocker les différents indicateurs et drapeaux (flags) trouvés dans les données opérationnelles. Eventuellement, si le nombre de lignes est conséquent, on pourra créer plusieurs dimensions fourre-tout. Cette dimension soulage la table de faits et évite aussi la création d’un trop grand nombre de dimensions pour gérer ces indicateurs. On peut aussi créer une dimension fourre-tout pour stocker les commentaires trouvés dans les données.

Les devises multiples peuvent être gérées facilement à l’aide d’une table de conversion stockant les changes chaque jour et en ajoutant une dimension Monnaie (par pays).

Les faits de granularité différente ne doivent jamais être mélangés dans une même table de faits. Ou bien il faut répartir les faits de plus haut niveau au niveau le plus fin, ou bien il faut les mettre dans des tables de faits séparées. La première solution est la meilleure car elle permet la navigation entre les niveaux ; mais elle nécessite de définir les modalités d’allocation (activity based costing). Cette allocation sur le niveau de détail devrait être faite par une équipe dédiée plus fonctionnelle et non par les développeurs de l’entrepôt.

La facturation est le processus idéal pour commencer un entrepôt de données dans les sociétés qui expédient des produits ou vendent des services. Une table de faits de transactions de facturation est une des tables les plus puissantes de l’entreprise. Elle combine les clients, les produits et les composantes de la rentabilité.

Une table de faits des instantanés récapitulatifs voit ses lignes régulièrement mises à jour, contrairement aux autres tables de faits. Ce type de table de faits est mieux adapté aux processus de courte durée de vie ayant un identifiant du début à la fin.

Gestion des unités de mesure : s’il existe différentes unités de mesure comme par exemple le nombre de produits, le nombre de cartons, le nombre de palettes, etc. alors il est conseillé de stocker les différents facteurs de conversion dans la table de faits directement et non dans une dimension. La gestion des changements de facteur s’en trouve simplifiée.

Il me semble qu’il est aussi possible de stocker directement les quantités (dans les différentes unités de mesure) plutôt que les facteurs. Mais alors l’étude des changements de facteurs (qui représentent des changements de conteneurs) est plus difficile. Le facteur de conversion apparaît donc plus fondamental ici.

Comparaison des 3 types de table de faits.

Les tables de transactions seules ne peuvent pas offrir des modèles dimensionnels efficaces. Elles stockent toutes les transactions.

Les tables de faits instantanés périodiques résument les faits à la fin d’une période (la journée souvent). Elles facilitent le suivi de l’évolution de l’activité.

Les tables de faits instantanés récapitulatifs couvrent un laps de temps indéterminé, correspondant à la durée de vie de la transaction de produit. Cette table possède souvent une colonne « date de mise à jour de la ligne ».

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.

Le chapitre 4 aborde les questions à se poser pour modéliser la ou les tables de faits et présente différentes façons de gérer les changements dans les dimensions.

Comment choisir s’il est utile ou non de créer plusieurs tables de faits ? Les questions suivantes peuvent orienter le choix :

• Quels sont les besoins d’analyse de l’utilisateur ?
• Les processus sont-ils distincts ou n’y a-t-il qu’un processus ?
• Les données proviennent-elles de plusieurs applications ?
• Les dimensions sont-elles différentes selon les types de fait ?

Prise en considération de l’évolution lente des dimensions
Il y a 3 techniques et 2 approches hybrides :

1. Ecraser la valeur de l’attribut ayant été modifié. Cette solution est valable pour des modifications de type correction. Elle ne conserve aucune trace du changement. Attention, elle nécessite un recalcul des agrégats éventuels.
2. Ajouter une ligne dans la table dimension avec une clé artificielle différente (mais conservant le code identifiant la dimension, par ex. le code produit dans le cas d’une dimension produit). C’est la principale technique permettant de suivre correctement les attributs des dimensions à évolution lente. Il est possible d’ajouter une date d’effet et/ou une date d’expiration de la ligne, mais elles ne sont pas nécessaires. Grâce à un calcul de CRC, il est possible d’enregistrer automatiquement les changements d’une ligne sans avoir à comparer dans le détail chaque champ. Cette technique est cependant difficilement applicable si la table de dimension a déjà plus d’un million de lignes.
3. Ajouter une colonne de dimension contenant l’état antérieur à la modification. Cette solution est intéressante si on veut pouvoir coparer l’effet du changement avec l’ancien état (cas d’un changement de secteur vendeur par ex.). Mais elle n’est pas adaptée s’il y a beaucoup de changements.

Outre ces 3 techniques, il y a 2 autres techniques hybrides utilisables lors de

1. changements prévisibles. Dans ce cas et si l’on souhaite calculer les états selon les différents changements mais sans la segmentation temporelle (par ex. étudier les effets des différentes définitions des secteurs vendeurs), alors il faut ajouter une colonne selon la technique 3 pour chaque changement.
2. changements imprévisibles avec application aux données antérieures de la version actuelle de l’attribut modifié. L’intérêt est de préserver la vision exacte du passé en gardant la possibilité de présenter les données antérieures selon les valeurs actuelles de l’attribut modifié. Cette approche mélange les techniques 1, 2 et 3.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.

On s’intéresse ici à la chaîne de valeur, aux différents modèles de stocks et à l’architecture de bus entre autres choses.

La chaîne de valeur décrit le flux logique des activités principales d’une organisation. Par exemple, pour un ditributeur, on peut avoir la chaîne de valeur suivante :

Commande émise par le détaillant -> livraison à l’entrepôt du détaillant -> stock de l’entrepôt du détaillant -> livraisons aux mag. de détail -> stock du mag. de détail -> ventes mag. de détail.

Alors que le chapitre 2 du livre traitait des ventes de produits (à l’aide de faits additifs), le présent chapitre traite de la gestion de stocks. Dans ce processus, les stocks d’hier ne sont pas nécessairement complètement différents des stocks d’aujourd’hui. Dans un instantané de stocks, les faits de stock (par ex. valeur au coût en euros) sont dits semi-additifs, car ils ne sont pas additifs selon toutes les dimensions.

Toutes les mesures enregistrant un niveau à un moment donné (niveaux de stock, solde de compte et mesures d’intensité telles que des températures) sont intrinsèquement non additives sur les dimensions date et éventuellement sur d’autres dimensions. De telles mesures peuvent être agrégées utilement dans le temps, par exemple, en faisant la moyenne des différentes périodes.

Des quantités non additives ne sont pas stockées dans la table de faits. Par exemple le retour de marge brute sur stock (RMBSS) qui mesure la qualité de l’investissement de l’entreprise dans ses stocks n’est pas stocké dans la table de faits, mais les informations permettant de le calculer sont stockées.

Une autre façon de modéliser les stocks est via une table de transactions de stock. Seule une table de faits au grain de la transaction permet de répondre à des questions très fines comme celles portant sur le nombre de produits mis dans un casier puis prélevés le même jour ou encore les produits renvoyés au fournisseur…
Cependant, ce type de table ne suffit pas pour toutes les analyses même si en théorie, il est possible de retrouver les cumuls des stocks.

Un 3ième type de table de faits de stock est l’instantané récapitulatif. La table de faits a de multiples clés externes basées sur des dates dans une ligne qui récapitule la vie du produit.

Un bus d’entreprise est indispensable à la construction d’un entrepôt de données. Il permet de réaliser les différents marchés d’infos à différents moments par différentes équipes de développement.
La matrice de bus est le document le plus important de la phase amont de la réalisation d’un entrepôt. Les lignes de cette matrice sont les processus de l’entreprise, les colonnes sont les dimensions. En lisant une ligne, on a toutes les dimensions d’un processus. En lisant une colonne, on a les dimensions partagées entre les processus et donc les interactions entre processus. Ce document peut servir en fait à la conception de l’ensemble de l’entrepôt, à la gestion du projet et à la communication.
Sans ce document pour assurer une cohérence globale, il est fort probable que chaque marché d’infos devienne incompatible avec les autres.

Le forage transverse (drill accross) devient possible lorsque plusieurs tables de faits partagent des dimensions.
Pour être partagée entre différents marchés d’infos, une dimension doit être conformes, i.e. « identique à la dimension la plus granulaire et la plus détaillée » (ou un sous-ensemble strict de cette dernière) avec les mêmes clés de dimension et les mêmes noms de colonnes d’attributs. Pour partager des dimensions, l’organisation doit définir un groupe de personnes (une autorité de dimension) pour gérer et diffuser les dimensions conformes (à l’aide d’une publication de type push pour garantir la cohérence au sein de l’entreprise).

Outre cette mise en conformité des dimensions (qui représente 90% du travail), il y a aussi la mise en conformité des faits. En particulier, il est crucial que des faits conformes aient le nom si et seulement s’ils ont la même interprétation.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.

Nous allons voir maintenant le processus de modélisation dimensionnelle en 4 étapes.

1. Sélectionner le processus d’entreprise à modéliser. Le but étant de servir l’utilisateur et que celui-ci utilise l’entrepôt de données pour ses questions, le premier modèle dimensionnel à construire doit répondre aux questions les plus pressantes de l’utilisateur et les données doivent être les plus faciles à extraire.
2. Déclaration du grain. Il faut utiliser les données les plus atomiques à notre disposition. Ne pas agréger les données en faisant des sommes et en perdant de la finesse et de l’information. Le but n’est pas de présenter à l’utilisateur tous les détails du processus, mais de lui offrir la possibilité d’analyser aussi facilement que possible selon diverses manières, à l’aide de coupes en tranches et en dés du cube de données.
3. Identification des dimensions. « L’énoncé précis du grain détermine les dimensions principales de la table de faits. » D’autres dimensions peuvent être ajoutées si elles ne prennent qu’une seule valeur pour chaque combinaison des dimensions élémentaires.
4. Identifications des faits. Les faits sont des quantités numériques généralement additives. Les pourcentages, les ratios sont des données non additives.et doivent être stockées dans la table de faits en séparant numérateur et dénominateur pour n’avoir que des quantités additives.

La dimension date apparaît dans quasiment tous les entrepôts de données. Si la table contient les jours des 10 ans à venir, son nombre de lignes est de 3650 seulement. C’est donc une dimension relativement petite. Ses attributs peuvent être : une clé primaire entière, la date, la description textuelle de la date, le jour de la semaine, les n° de jour, de semaine et de mois dans l’époque, les n° de jour dans le mois calendrier, dans l’année calendrier, le nom du mois, le n° du mois dans l’année, le trimestre, l’année, des indicateurs de jour férié, de jour de semaine, une saison particulière pour l’entreprise, un événement majeur…

Pour gérer l’heure de la journée, il est préférable d’ajouter une table de dimension supplémentaire, et de ne pas les mettre dans la table date qui aurait alors 5 256 000 lignes !

Il y a plusieurs intérêts à prendre une clé primaire entière : étant utilisée dans la jointure avec la table de faits, plus la clé est petite, plus on économise de la place dans la table de faits (4 octets économisés sur 1 milliard de lignes fait 4Go d’économie !). Cela permet aussi de traiter l’absence de date avec une clé particulière plutôt qu’une valeur nulle. D’une façon générale, il faut éviter les clés null dans la table de faits. Pour indiquer qu’une dimension ne s’applique pas à un fait, il est conseillé d’ajouter une ligne particulière dans la table dimension (ex. : ajouter une ligne pas de promotion dans la dimension promotion).
Les tables dimensions étant de petites tailles, leurs attributs doivent être autant que possible des champs en texte clair et non des codes (qu’il faut ensuite décodés ou que l’utilisateur doit connaître et se souvenir). Il n’y a aucun besoin d’économie de place dans les tables dimensions.

Pour analyser ses données, l’utilisateur pratique le forage (datamining). Un forage vers le bas dans un marché d’informations consiste à ajouter des intitulés (valeurs de champ) de la table de dimension dans la requête. Le forage vers le haut est l’inverse : retirer des intitulés. Le forage permet une navigation dans une hiérarchie.

« Il est courant de représenter de multiples hiérarchies dans une table de dimension. »

Dimension dégénérée : cette notion apparaît lorsqu’un champ de la table de faits permettant d’identifier de façon unique une ligne (ex. n° de facture ou de commande). Ces numéros d’identification opérationnels sont les clés de dimensions vides, c-à-d ne pointant pas sur une table de dimension. La dimension engendrée par ces clés est dite dégénérée.

Voici différents cas d’extension du modèle dimensionnel :

1. Ajout de nouveaux attributs de dimension (nouvelles colonnes dans la table dimension). Les applications existantes requêtant sur l’entrepôt de données ne sont pas impactées. Si ces nouveaux attributs ne sont disponibles qu’à partir d’une date donnée, il convient de mettre un libellé particulier (par ex . « non disponible ») pour les anciens enregistrements.
2. Ajout de nouvelles dimensions. Cela implique d’ajouter une nouvelle clé étrangère dans la table de faits.
3. Ajout de nouveaux faits. Si ces faits sont au même grain que les faits existants, il suffit d’ajouter autant de colonnes dans la table de faits. S’ils n’apparaissent qu’à partir d’une certaine date, il suffit de mettre la valeur null dans les lignes de faits antérieurs. S’ils ne sont pas au même grain, il est fortement conseillé de les mettre dans une table de faits à part.
4. Si une dimension devient plus granulaire, la table de faits devient probablement aussi plus granulaire et elle doit être reconstruite. Les applications existantes ne seront cependant pas impactées.
5. Ajout d’une nouvelles source de données avec les dimensions existantes et de nouvelles dimensions imprévues. Dans ce cas, il faut créer une nouvelle table de faits et conserver l’ancienne.

Modèle dimensionnel en flocons de neige. Ce modèle résulte de la normalisation en 3ième forme normale des dimensions. Il est déconseillé de normaliser les tables de dimension pour plusieurs raisons :

1. La multiplication des tables de dimension peut perturber les utilisateurs.
2. Les SGDB auront un traitement moins optimisé.
3. L’économie d’espace réalisée est négligeable comparée à la taille de la table de faits.
4. La navigation à l’intérieur d’une dimension est plus difficile.
5. Les flocons de neige empêchent l’utilisation des index sous forme de bitmaps (utiles pour les champs de faible cardinalité).

Les tables de dimensions doivent donc rester plates.

A éviter également : dépasser 25 dimensions. En général, on peut s’en sortir avec moins de 15 dimensions.

Toute jointure entre des tables de dimension et des tables de faits doit se baser sur des clés entières artificielles sans signification. Eviter les codes opérationnels qui prennent plus de place et peuvent ne pas être pérennes. Aussi l’absence d’une dimension n’a pas de code opérationnel associé. De plus les clés entières permettent de meilleures performances.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.

Un article alarmiste du Monde annonce une faille dans le système de cryptage actuel utilisé un peu partout sur Internet et en particulier pour le commerce en ligne. L’article est un peu confus, mais on y apprend tout de même qu’il existe un moyen de casser des codes asymétriques à partir de l’analyse des temps de calcul du processeur.

On peut résumer ainsi le principe de l’attaque : pour aller toujours plus vite, le processeur fonctionne en parallèle et dispose d’un système de prédiction du résultat de l’opération en cours. Si la prédiction est bonne, le processus est sensiblement accéléré. Si elle est erronée, il faut revenir en arrière et recommencer l’opération élémentaire. Il « suffit » de mesurer le temps de calcul lorsque le processeur égrène la chaîne de 0 et de 1 qui constitue la clé de cryptage pour en déduire celle-ci.

Cette menace, qui porte le nom d’ »analyse de prédiction de branche » (BPA), était déjà connue, mais elle nécessitait de très nombreux essais pour déduire de façon statistique la clé de cryptage. Ce qui la rendait impraticable. La percée de Jean-Pierre Seifert tient à ce qu’une seule écoute est désormais nécessaire. Et sa force réside dans le fait que le processus de prédiction, fondamental pour accélérer les performances du processeur, n’est pas protégé.

Un petit logiciel « taupe » pourrait donc écouter la puce en toute discrétion, et renvoyer la clé à des hackers, à des services de renseignement ou à des espions à la solde de concurrents.

Il est également intéressant de lire les commentaires des lecteurs de l’article du Monde.

L’analyse de prédiction de branche est présentée dans un article plus technique de Seifert.

Source :

Les puces ne garantissent pas la sécurité des échanges en ligne
LE MONDE | 18.11.06

©

Généralités sur l’entrepôt de données.

1. L’entrepôt de données doit faciliter l’accès aux données de l’entreprise ou organisation.
2. Il doit présenter l’information de l’entreprise de manière cohérente.
3. Il doit être adaptable et résistant aux changements.
4. Il rassemble une grande richesse informationnelle qui doit être protégée.
5. Il doit permettre de prendre des décisions.
6. Un entrepôt de données n’est réussi que s’il est accepté par les utilisateurs.

L’environnement de l’entrepôt de données se compose de 4 parties :

1. les applications opérationnelles sources, qui capturent les transactions de l’entreprise. Elles sont extérieures à l’entrepôt.
2. La zone de préparation des données. C’est une zone de stockage et de transformation des données. Elle prépare les données pour être présentée selon les besoins des utilisateurs. Les utilisateurs ne doivent en aucun cas avoir accès à cette zone. La base de données de cette zone n’est pas nécessairement normalisée.
3. La zone de présentation des données. C’est la base optimisée pour les requêtes des utilisateurs, pour les outils de reporting et autres applications d’analyse. Elle n’est pas normalisée en 3ième forme normale, mais comporte en général une table de faits entourée de tables de dimensions pour former un schéma en étoile. Les données doivent être dimensionnelles, atomiques et doivent adhérer à l’architecture de bus d’entrepôts de données.
4. Des outils d’accès aux données allant du SQL simple aux outils de reporting genre Business Objects.

Table de faits : C’est la table centrale dans laquelle figure toutes les mesures à un grain donné. Le grain étant la finesse à de la mesure. Les faits sont la plupart du temps numérique et additifs.

Tables de dimension : Elle sont le point d’entrée dans la table des faits. Elles décrivent un axe d’analyse (dimension date, dimension produit, dimension client…). Elles établissent l’interface homme/entrepôt de données.

Les tables de faits doivent contenir les plus petits détails d’une activité. Ce sont les plus grosses tables de l’entrepôt de données. Une ligne de cette table décrit un fait, par ex. le prix en caisse d’un article tel jour, avec telle promotion, dans tel magasin. Le prix est la quantité numérique qui nous intéressent et l’article, la promotion et le magasin sont les dimensions stockées dans leur propre table.

Le marché d’infos sert à présenter en général les données d’un processus de l’entreprise à l’aide du modèle dimensionnel dit en étoile.
La construction d’un modèle en étoile permet de facilement ajouter des dimensions, et la simplicité du schéma relationnel permet d’avoir des requêtes optimisées.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.

Je me lance dans une série de notes sur la modélisation dimensionnelle. Pour le moment, je suis en phase d’apprentissage, donc pour les experts, je ne vais rien présenter de neuf. Pour ceux qui ne connaissent pas, c’est le moment d’apprendre ; et pour ceux qui ont oublié, c’est le moment de réviser les bases
Dans cette série, je vais relever les points essentiels de la modélisation dimensionnelle selon Ralph Kimball et Margy Ross dans leur livre « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième édition.