Configuration des tables de dim et de faits pour un entrepôt de données

Question

Je suis chargé de créer un entrepôt de données pour un client. Les tables concernées ne suivent pas vraiment les exemples traditionnels (produits / commandes), j'ai donc besoin d'aide pour démarrer. Le client est essentiellement un centre de traitement des affaires (similaire à une affaire judiciaire). Chaque jour, de nouveaux cas sont entrés dans le DB sous les "cas". table. Chaque colonne contient des informations relatives au cas. Au fur et à mesure que l'affaire est en cours de traitement, des tables un à plusieurs supplémentaires sont renseignées avec des événements liés à l'affaire. Il existe un certain nombre de ces tables d'événements, par exemple des tables (case-open, case-dept1, case-dept2, case-dept3, etc.). Chacune de ces tables a un caséid qui renvoie aux "cas". table. Quelques tables de consultation sont également impliquées.

À l’heure actuelle, les besoins en matière de rapports concernent la mise en évidence de goulets d’étranglement aux différentes étapes et la granularité est au niveau des heures pour certains domaines du processus.

Je demande peut-être trop ici, mais je cherche des indications sur la manière dont je devrais configurer mes tables Dim et Fact ou toute autre suggestion que vous pourriez avoir.

Answer 1

Je vous suggère de consulter les livres de Kimball, en particulier celui-ci , qui Vous devriez avoir quelques exemples pour vous aider à penser aux applications de votre domaine problématique.

Dans tous les cas, vous devez décider si un modèle dimensionnel est même approprié. Il est tout à fait possible de traiter un "entrepôt de données d'entreprise" de base de données 3NF avec différents index ou résumés, ou autre.

Sans voir votre schéma actuel, c'est VRAIMENT difficile à dire. On dirait que vous allez vous retrouver avec plusieurs modèles étoiles avec des dimensions conformes les liant. Vous pouvez donc avoir une dimension de cas comme l'une de vos dimensions conformes. Les faits de chaque autre tableau seraient en fait des tableaux qui lient à la fois à la dimension conforme et à toute autre dimension appropriée aux faits. Ainsi, par exemple, si un identifiant d'employé est ouvert dans la casse, il serait lié à une dimension conforme à l'employé. , de la table de cas-fait ouvert. Cette dimension conforme peut être liée plusieurs fois à partir de plusieurs de vos tables de faits subsidiaires.

La méthode de modélisation de Kimball est assez simple et peut être suivie comme une recette. Vous devez commencer par identifier tous vos faits, en les regroupant dans des tables de faits, en identifiant des dimensions individuelles sur chaque table de faits, puis en les regroupant le cas échéant dans des tables de dimensions, puis en identifiant le type de chaque dimension.

Answer 2

La table de faits est l’événement de cas et elle n’est pas factuelle en ce sens qu’elle n’a aucune valeur numérique. Les dimensions seraient l'heure, le type d'événement, le cas et peut-être d'autres selon les autres données présentes dans le système.

Vous devez consolider les tables d'événements en une seule table de faits, étiquetée avec une dimension "type d'événement". Les rapports de débit / goulot d'étranglement calculent les différences entre les durées des événements pour des combinaisons spécifiques de types d'événements sur un cas donné.

Les rapports doivent calculer les heures des événements et éventuellement les regrouper dans un histogramme. Vous pouvez également étiqueter certains types de combinaisons d’événements et l’appliquer aux événements qui vous intéressent. Ces événements pourraient alors avoir le temps enregistré contre eux, ce qui permettrait des opérations slice-and-dés sur les temps avec un outil OLAP.

Si vous souhaitez analyser certaines étapes de la progression du cycle de vie, vous devez disposer d'un tableau indiquant le type de cas, le type d'événement 1, le type d'événement 2 et le temps de référence.

Avec un peu de massage, vous pourrez peut-être utiliser une boîte à outils d’exploration de données ou même une simple analyse de régression pour repérer les corrélations entre les attributs de cas et les heures d’événement sur événement (YMMV).

Answer 3

Comme pour toute autre facette du développement, vous devez aborder le problème à partir des exigences finales ("user stories" si vous le souhaitez) à l'envers. L’approche la plus prudente pour un entrepôt consiste simplement à représenter une copie de la base de données des transactions. À partir de là, guidées par les exigences, certaines optimisations peuvent être effectuées pour améliorer les performances de certains modèles d'accès aux données. Cependant, j'estime qu'il est important de considérer ces opérations comme des optimisations et de ne pas supposer qu'un entrepôt de données doit automatiquement constituer une explosion complexe de toutes les dimensions possibles et de tous les faits. Mon expérience est que dans la plupart des cas, une représentation directe est adéquate ou même idéale pour 90% des requêtes analytiques. Pour le reste, commencez par examiner les index, les vues indexées, les statistiques supplémentaires ou toute autre optimisation pouvant être effectuée sans affecter les structures. Ensuite, si une agrégation ou d'autres structures redondantes sont nécessaires pour améliorer les performances, envisagez de les séparer en un "magasin de données". (du moins conceptuellement) qui établit une distinction entre les faits primitifs et leurs redondances. Enfin, si les exigences sont trop fluides et que les contraintes d’agrégation sont trop lourdes pour fonctionner efficacement de cette manière, vous pouvez envisager des explosions massives de données, c’est-à-dire un schéma en étoile. Encore une fois, limitez-vous à la plus petite section possible des données.

Answer 4

Voici ce que je propose essentiellement. Thx NXC

Événements factuels

EventID TimeKey Identifiant de cas

Événements dim

EventID EventDesc

Dim Dim

TimeKey

Régions dim

ID de région RegionDesc

Cas

CaseID ID de région

Answer 5

Il peut s’agir de choisir une solution avant que vous ne considériez le problème. Tous les datawarehouses ne s'intègrent pas dans le modèle de schéma en étoile. Je ne vois pas que vous regroupez des données ici. Jusqu'à présent, nous avons une table de faits sans fait et au moins une dimension (cas) qui change rapidement.

En regardant ce que je vois jusqu'à présent, je pense que l'entité centrale de cette base de données devrait être le cas. Essayer de coller l'événement au milieu ne semble pas correct. Essayez de regarder les choses différemment. Peut-être, cas, événements et événements de cas à commencer.