Tables de faits
Mise à jour : novembre 2007
Chaque entrepôt de données inclut une ou plusieurs tables de faits. Centrale par rapport à un schéma en étoile ou en flocons, une table de faits capture les données qui mesurent les opérations de l'équipe. Les tables de faits contiennent habituellement de grands nombres de lignes, en particulier lorsqu'elles contiennent une ou plusieurs années d'historique pour un grand projet d'équipe.
Une caractéristique clé d'une table de faits est qu'elle contient des données numériques (faits) qui peuvent être résumées pour fournir des informations sur l'historique des opérations de la société. Chaque table de faits inclut également un index multipart qui contient, comme clés étrangères, les clés primaires de tables de dimension connexes qui contiennent elles-mêmes les attributs des enregistrements de faits. Les tables de faits ne doivent pas contenir d'informations descriptives ni de données autres que les champs de mesures numériques et les champs d'index qui relient les faits aux entrées correspondantes dans les tables de dimension.
Tables de faits dans le cube de données
Le tableau suivant décrit les tables de faits contenues dans la base de données relationnelle Team System.
Table |
Description |
|---|---|
Ensemble de modifications de build |
Contient une ligne pour chaque ensemble de modifications inclus dans cette build, mais non inclus dans une build précédente du même type. Cela permet la corrélation des informations de build avec les archivages, et également avec les éléments de travail associés aux archivages. |
Couverture de build |
Contient une ligne pour chaque code temporel lorsque les métriques ont été rassemblées pour une build. |
Détails de la build |
Contient une ligne pour chaque exécution de build. |
Projet de build |
Contient une ligne pour chaque génération de projet dans une build. |
Évolution du code |
Contient une nouvelle ligne pour chaque révision de fichier. |
Élément de travail en cours |
Contient une ligne pour chaque élément de travail se trouvant actuellement dans le système. |
Compteur de test de charge |
Informations résumées pour chaque valeur de compteur de performance lue pour chaque test de charge exécuté. Contient l'ID de compteur, la valeur et l'ordinateur d'origine. |
Détails du test de charge |
Contient une ligne pour chaque exécution de test de charge. |
Résumé de page de test de charge |
Contient une ligne pour chaque URL visitée pendant chaque test de charge. Résume les informations pour chaque page de niveau supérieur, mais n'inclut pas les informations détaillées pour les demandes dépendantes, telles que les images. |
Résumé du test de charge |
Contient une ligne pour chaque série de tests d'un test de charge. Contient le nombre de fois où le test a été exécuté, le nombre de fois où il a échoué, le temps moyen nécessaire à son exécution, etc. |
Transaction de test de charge |
Contient la durée moyenne de chaque transaction. Par exemple, si les tests unitaires sont exécutés sous charge, les minuteurs des tests font office de durée moyenne requise pour chaque transaction. |
Couverture de série |
Contient une ligne pour chaque exécution de série de tests qui rassemble des métriques de couverture du code. |
Résultat de test |
Contient une ligne pour chaque exécution de test. Contient le résultat du test, les heures de début et de fin ainsi que les métadonnées du test (catégorie, nœuds CSS, etc.) |
Ensemble de modifications d'élément de travail |
Contient une ligne pour chaque relation entre une révision d'élément de travail et un ensemble de modifications. |
Historique de l'élément de travail |
Fichier avec version d'éléments de travail qui utilise les nombres de transitions et d'enregistrements pour regrouper des informations à un moment donné. |
Cinq champs apparaissent dans toutes les tables de faits :
ID
ID de suivi logique
LastUpdatedTime
LastUpdatedBy
TrackingId
De plus, il existe un jeu de clés étrangères liées aux tables de dimension.
Suivi de l'historique dans la table de faits
Les éléments de travail comme les résultats des tests impliquent des faits qui évoluent avec le temps. Il est utile de regrouper des informations sur ces éléments et de consulter l'évolution des nombres avec le temps ou les éléments tels qu'ils existaient à un moment précis. L'entrepôt de données Team System capture chaque révision d'un élément de travail, ou chaque série d'un test de manière à permettre les calculs dans le cube OLAP pour regrouper des informations à n'importe quel moment donné. Le tableau suivant décrit les deux colonnes d'entiers de la base de données relationnelle qui effectue le suivi des modifications.
Colonne |
Description |
|---|---|
Nombre d'enregistrements |
Chaque fois qu'une modification a lieu sur un enregistrement (par exemple, lorsque la priorité d'un bogue change), deux enregistrements sont écrits dans la base de données. Le premier enregistrement, appelé enregistrement de compensation, affecte la valeur -1 au nombre d'enregistrements qui s'annule, ou se compense pour les événements précédents. Le second enregistre les nouvelles valeurs associées au fait et affecte la valeur 1 au nombre d'enregistrements. Dans le cube, le regroupement de tous les enregistrements entre deux points dans le temps aboutit à l'annulation effective de tous les enregistrements sauf du dernier effectué à ce moment donné. Le nombre d'enregistrements sert de base à l'affichage des totaux du jour. |
Nombre de modifications d'état |
Dans la mesure où les changements d'état constituent un aspect important de la création de rapports, chaque fois que l'état d'un élément de travail ou le résultat d'un test change, un indicateur spécial, appelé « Nombre de modifications d'état » prend la valeur true. Le Nombre de modifications d'état sert de base à l'affichage des activités du jour. |
Voir aussi
Autres ressources
Relations entre les tables de faits
Fonctionnement de la structure du cube de l'entrepôt de données