Conventions d'entrepôt de données Clarity PPM

ccppmop157
HID_admin_datawarehouse_conventions
Respectez les conventions et les normes suivantes au niveau de l'entrepôt de données pour la création des données de génération de rapports à l'aide des outils de votre choix :
2
Préfixes de la table d'entrepôt de données
Le schéma d'entrepôt de données utilise les préfixes indiqués dans le tableau suivant pour l'attribution d'un nom à ses tables.
Préfixe
Description de la table
DWH_CFG
Tables de configuration utilisées pour les informations de journal et d'audit
DWH_CMN
Objets de base de données communs utilisés dans la plupart des zones
DWH_CMP
Objets de base de données de la société
DWH_FIN
Objets de base de données de gestion financière
DWH_INV
Objets de base de données de gestion des investissements
DWH_LKP
Objets de base de données de recherche
DWH_META
Tables de métadonnées permettant de déterminer la structure de l'entrepôt de données
DWH_ODF
Objets de base de données spécifiques du client
DWH_PFM
Objets de base de données de gestion des portefeuilles
DWH_RES
Objets de base de données de gestion des ressources
DWH_RIM
Objets de base de données de gestion des risques et des problèmes
DWH_TME
Objets de base de données de gestion du temps
DWH_X
Objets de base de données internes utilisés pour le remplissage des tables de faits
Normes utilisées par l'entrepôt de données au niveau des éléments de recherche statiques
Dans l'entrepôt de données, chaque élément de recherche possède sa propre table. Les valeurs des éléments de recherche sont stockées séparément dans les langues sélectionnées pour l'entrepôt de données. Par exemple, si l'entrepôt de données est stocké en anglais et en espagnol, deux enregistrements sont créés pour chaque valeur d'élément de recherche.
Le tableau suivant indique la structure d'un élément de recherche statique dans le schéma.
Histogramme
Type de données
Description
[LOOKUP_NAME]_key
Valeur numérique ou caractère variable (30)
Valeur principale de l'élément de recherche. Si la clé masquée dans
Clarity PPM
est lookup_enum, la clé dans l'entrepôt de données est définie à partir de la clé lookup_enum. Ce comportement s'applique également à la clé lookup_code. Exemple : investment_status_key.
LANGUAGE_CODE_KEY
ID obtenu à partir de la table de langues
Clarity PPM
LANGUAGE_CODE
Varchar (30)
Code unique de la langue obtenu à partir de la table de langues
Clarity PPM
[LOOKUP_NAME]
Varchar (255)
Nom descriptif de l'élément de recherche, par exemple investment_status
SORT_ORDER
Nombre
Ordre d'affichage des valeurs
IS_ACTIVE
Nombre
Indique que la valeur de l'élément recherche actuel est active.
CLARITY_UPDATED_DATE
Date
Date de la dernière mise à jour de l'enregistrement dans
Clarity PPM
DW_UPDATED_DATE
Date
Date de la dernière mise à jour de l'enregistrement dans l'entrepôt de données
Normes utilisées par l'entrepôt de données au niveau des éléments de recherche dynamiques
Chaque élément de recherche dynamique possède sa propre table. Chaque structure de table varie en fonction de l'élément de recherche. Si l'élément de recherche est dépendant de la langue, les attributs langage_code_key et language_code sont stockés. S'il ne l'est pas, un enregistrement existe pour chaque valeur.
Le tableau suivant illustre la structure d'un élément de recherche dynamique dans le schéma.
Histogramme
Type de données
Description
[lookup_name]_key
...
Valeur principale de l'élément de recherche dynamique : dépend de la valeur NSQL masquée
Language_code_key
Nombre
ID obtenu à partir de la table de langues
Clarity PPM
, le cas échéant
Language_code
Varchar (30)
Code unique de la langue obtenu à partir de la table de langues
Clarity PPM
, le cas échéant
[lookup_name]
...
Nom descriptif de l'élément de recherche Exemple : investment_status
...
...
Diverses colonnes spécifiques de l'élément de recherche
Clarity_updated_date
Date
Date de la dernière mise à jour de l'enregistrement dans
Clarity PPM
DW_updated_date
Date
Date de la dernière mise à jour de l'enregistrement dans l'entrepôt de données
Tables de faits de l'entrepôt de données
Dans l'entrepôt de données, les tables de faits respectent les conventions suivantes :
  • Les noms des tables de faits se terminent par le suffixe
    _FACTS
    .
  • Les tables dont le nom inclut
    _PERIOD_
    stockent les faits en fonction des périodes définies.
  • Les tables dont le nom inclut
    _SUMMARY_
    stockent les faits récapitulatifs. Des tables récapitulatives existent pour un grand nombre de faits. Si vous faites correspondre les numéros de récapitulatif avec les faits de la période, qualifiez les faits de la période par type de période.
  • Les tables dont le nom inclut
    DWH_X_
    sont des tables de faits internes. Elles sont utilisées pour remplir la période et les tables de faits récapitulatives de la manière la plus efficace. Ces tables ne sont pas disponibles pour les utilisateurs.
  • Les clés des tables de faits présentent toutes une option d'intégrité référentielle.
  • Les faits calculés sont stockés dans les tables à des fins de cohérence.
  • L'entrepôt de données inclut des cumuls récapitulatifs. Les affectations sont cumulées au niveau des tâches et inversement.
  • Les créneaux masqués cumulent les données dans plusieurs périodes hebdomadaires, mensuelles et fiscales.
Le tableau suivant présente des exemples de tables de faits.
Description du fait
Nom de la table de faits
Cumul
Financial Transaction
DWH_FIN_TRANSACTION_FACTS
Quotidien(e)
Saisie de temps
DWH_TME_ENTRY_FACTS
Quotidien(e)
Bénéfice financier
DWH_FIN_BENEFIT_PERIOD_FACTS
Fiscal
Plan financier
DWH_FIN_PLAN_PERIOD_FACTS
Fiscal
Affectation de tâche
DWH_INV_ASSiGN_PERIOD_FACTS
Fiscal, hebdomadaire, mensuel
Tâche d'investissement
DWH_INV_TASK_PERIOD_FACTS
Fiscal, hebdomadaire, mensuel
Equipe d'investissement
DWH_INV_TEAM_PERIOD_FACTS
Fiscal, hebdomadaire, mensuel
Investissement
DWH_INV_PERIOD_FACTS
Fiscal, hebdomadaire, mensuel
Ressource
DWH_RES_PERIOD_FACTS
Fiscal, hebdomadaire, mensuel
Les quatre types de période suivants sont utilisés pour stocker des faits :
  • Quotidien(e)
  • Hebdomadaire
  • Mensuel(le)
  • Période fiscale
Exemple : noms des tables de faits récapitulatives
Le tableau suivant présente des exemples de noms de tables de faits récapitulatives.
Description du fait
Nom de la table de faits
Bénéfice financier
DWH_FIN_BENEFIT_SUMMARY_FACTS
Plan financier
DWH_FIN_PLAN_SUMMARY_FACTS
Affectation de tâche
DWH_INV_ASSIGN_SUMMARY_FACTS
Tâche d'investissement
DWH_INV_TASK_SUMMARY_FACTS
Equipe d'investissement
DWH_INV_TEAM_SUMMARY_FACTS
Investissement
DWH_INV_SUMMARY_FACTS
Exemple de requête d'entrepôt de données
Les requêtes au niveau de l'entrepôt de données sont plus simples que les requêtes au niveau de la base de données transactionnelle
Clarity PPM
, pour les raisons suivantes :
  • Il n'est pas nécessaire de les rattacher à des tables d'élément de recherche.
  • Les rattachements entre les tables sont cohérents. La clé correspond toujours à l'ID de ressource.
  • Les noms de colonnes sont cohérents entre les tables.
  • Les noms de tables respectent une convention de dénomination standard.
L'exemple suivant porte sur une nouvelle requête au niveau de l'équipe.
SELECT i.investment_manager, i.investment_name, t.resource_name, t.role_name, tl.booking_status, tl.request_status, p.period_start_date, tf.alloc_hours, tf.alloc_cost FROM   dwh_inv_team t INNER JOIN dwh_inv_team_ln tl ON t.team_key = tl.team_key INNER JOIN dwh_inv_investment i ON t.investment_key = i.investment_key INNER JOIN dwh_inv_team_period_facts tf ON t.team_key = tf.team_key INNER JOIN dwh_cmn_period p ON tf.period_key = p.period_key WHERE  SYSDATE BETWEEN p.year_start_date AND p.year_end_date AND p.period_type_key = 'MONTHLY' AND tl.language_code = 'en'
Intégrité référentielle
Pour améliorer la précision des données, les tables utilisent des clés primaires et étrangères.
  • Les tables de langue (se terminant par
    _In
    ) disposent de clés étrangères pour la table principale.
  • Les tables de faits présentent des clés étrangères pour les tables principales.
  • Les contraintes de clé étrangère se terminent par FK1.
  • Les contraintes de clé primaire se terminent par PK.
Cette convention permet de réduire les erreurs et d'éliminer les enregistrements orphelins (enregistrements de détail sans en-tête). Lorsqu’un enregistrement est supprimé, tous les enregistrements contenus dans d’autres tables qui possèdent une clé étrangère pour l’enregistrement en cours sont automatiquement supprimés.