1. Centre d'aide aux systèmes d'Alchimie
2. Alchemy Manager
3. Rapports

Accès direct au Snowflake

Note: Cet article explique la structure et l'utilisation des modèles de données d'Alchemy Reporting. L'accès à Snowflake Direct vous offre des capacités de reporting supplémentaires en dehors d'Alchemy Manager pour ceux qui utilisent des opérations de business intelligence (BI) ou de business analytics (BA). Si vous êtes intéressé par l'utilisation de Snowflake, veuillez contacter votre gestionnaire de compte Alchemy pour obtenir des informations sur les prix. Pour en savoir plus sur les rapports intelligents, voir Qu'est-ce qu'un rapport intelligent?

À propos de Snowflake Direct Access

La plateforme Alchemy Training System utilise Snowflake, une solution d'entrepôt de données extrêmement performante. Pour les clients ayant des opérations sophistiquées de business intelligence (BI) ou de business analytics (BA), Alchemy offre la possibilité de se connecter directement à Snowflake, ce qui permet aux organisations de visualiser, d'interroger et d'analyser directement toutes leurs données de formation.

Snowflake Direct Access permet des analyses et des rapports uniques sur la formation qu'Intertek Alchemy vous aide à dispenser.

• Développez efficacement vos analyses
• Combiner facilement les données Alchemy avec des ensembles de données provenant d'autres systèmes
• Découvrir des informations et des tendances précieuses

Les clients peuvent accéder au nuage de données Snowflake d'Alchemy Manager de deux manières:

1. Compte client: cette option est destinée aux clients qui ont leur propre compte Snowflake et leur propre relation de facturation. Cette option exige que les données du client soient stockées dans la région AWS us-east-1.
2. Compte de lecteur Alchemy: cette option permet à Alchemy de créer et de gérer un compte de lecteur pour le client, et toute la facturation est gérée par Alchemy.

Que vous utilisiez l'une des interfaces web de Snowflake ou une connexion réseau directe à Snowflake, votre accès aux données s'effectue avec SQL, et vous aurez donc besoin d'une personne compétente pour l'utiliser. Le niveau d'expertise SQL dont vous aurez besoin sera déterminé par ce que vous essayez d'accomplir, mais il pourrait facilement nécessiter l'utilisation de plusieurs JOIN, de plusieurs clauses WHERE et d'une longue liste de champs SELECT.

Modèles de données

Les modèles de données (DM) sont les vues de vos données Alchemy auxquelles nous fournissons un accès direct. Vos Smart Reports et tableaux de bord utilisent ces DM pour générer les données. Ils fournissent une version des données de l'application qui simplifie la recherche et donne d'excellents résultats lors de l'analyse des données.

Les champs "clés" sont utilisés pour identifier les principaux objets de la base de données. Ils peuvent être utilisés pour identifier des objets uniques et sont également utilisés avec une "jointure" pour obtenir des données supplémentaires.

DM_STUDENT_DETAIL

Ce tableau contient des données détaillées sur chaque étudiant. Vous pouvez l'interroger directement comme suit :

    select user_full_name, user_id, user_worksite, date_of_hire, user_groups
    from dm_student_detail
    order by date_of_hire desc nulls last
    limite 20 ;

Les colonnes de la liste des groupes

Alchemy Manager peut être configuré pour prendre en charge jusqu'à 13 "classifications d'étudiants". Chaque classification a un champ dans DM_STUDENT_DETAIL qui contient le nom du groupe (ou des groupes) dont l'étudiant est membre. Les noms de groupes multiples sont séparés par des espaces et le symbole du tuyau (|). Seuls les 100 premiers noms de groupes seront répertoriés, car il s'agit d'un affichage "tel quel" plutôt que d'une manipulation ou d'une recherche.

Les colonnes sont nommées comme suit :

• STATUS_GROUPS
• GROUPES_DE_TYPE_DE_PAIE
• TYPES_DE_TEMPS_GROUPES
• EMP_TYPE_GROUPS
• REGION_GROUPS
• GROUPES_SOUS_RÉGION
• DIV_GROUPS
• GROUPES_UNITÉS_BUSS
• GROUPES_DÉPUTÉS
• CODES_EMPLOI_GROUPES
• GROUPES_TITRES_EMPLOIS
• GROUPES_DE_CATÉGORIE_D'EMPLOI
• SHIFT_GROUPS

En outre, le champ USER_GROUPS agit de la même manière pour les "groupes de systèmes".

DM_*_REPORT

Il s'agit des principaux tableaux du rapport. En général, chaque Smart Report dans Alchemy Manager utilise une table de rapport, et chaque ligne de la table représente une ligne de sortie dans un Smart Report. Dans les cas les plus simples, on utilisera probablement une table de rapport et la table DM_STUDENT_DETAIL, une requête comme celle-ci fonctionnerait :

    select s.user_full_name, tr.training_end_date, tr.activity_code, tr.activity_title
    from dm_tr_report tr
    inner join dm_student_detail s
      on tr.student_key = s.student_key
    où date(tr.training_end_date) = current_date() ;

Les tableaux sont les suivants:

Tableau du rapport	Données fournies
DM_TR_REPORT	Contient des données de formation sur les activités individuelles des apprenants, telles que les cours Alchemy, les observations, les cours pour les joueurs, les cours intensifs, etc.
DM_LP_REPORT	Contient des informations sur l'état des abonnements des apprenants aux plans de formation. Pour chaque inscription d'un apprenant à un plan de formation, il y a une ligne pour chaque activité requise pour compléter ce plan de formation et le statut de l'apprenant pour cette exigence.
DM_OBSERVATION_REPORT	Il contient des détails sur les observations, tels que le résumé des commentaires, les informations de l'observateur, la cause première, le renforcement et les actions correctives. Notez que les images ne sont pas disponibles et que les détails des réponses individuelles doivent être joints à DM_ANSWER_DETAILS.
DM_QP_STATUS_REPORT	Détient le statut des affectations des apprenants aux plans de qualification. Il peut s'agir de qualifications manuelles ou d'expirations.

Notez que nous supprimons les champs "étudiant" des tables de rapport afin de simplifier les nouveaux rapports et d'obtenir des détails pour plusieurs étudiants (c'est-à-dire OBSERVED_BY_KEY, FACILITATOR_STUDENT_KEY, etc). Pour des raisons de compatibilité, vous devez récupérer les données relatives aux étudiants dans la table DM_STUDENT_DETAIL.

DM_LOCALE_*

Ces tableaux contiennent les différentes traductions des objets d'Alchemy Manager qui le supportent. Chaque tableau représente les traductions disponibles pour un seul champ de texte. Chaque ligne du tableau représente le texte qui serait affiché pour une seule locale. (Actuellement, le champ locale contient un nombre obtus. Ce point sera modifié ultérieurement.)

Notez qu'une traduction est présente dans chacune des langues supportées par l'interface utilisateur, même si aucune n'a été fournie. La traduction "en_US" sera utilisée dans ce cas.

Le contenu du cours peut être disponible dans une grande variété de langues, mais le titre parent est en DM_LOCALE_PARENT et uniquement dans les langues prises en charge par l'interface utilisateur. Par exemple, il existe des cours en swahili, en vietnamien, etc., dont les noms ne sont pas en anglais, mais leur titre principal comporte une traduction anglaise, telle que "Electrical Safety Swahili", et il se peut qu'il n'y ait pas de traduction espagnole du titre principal, de sorte que dans dm_locale_parent, il sera stocké avec le même titre anglais.

Par exemple, pour obtenir les noms des parents "es-US" (nous obtiendrons "en-US" si aucun "es-US" n'est disponible) pour une formation récente, une requête comme celle-ci fonctionnerait :

    select s.user_full_name, tr.training_end_date, tr.activity_code, p.name, tr.activity_title
    from dm_tr_report tr
    inner join dm_student_detail s
      on tr.student_key = s.student_key
    inner join dm_locale_parent p
      on p.parent_key=tr.parent_key and p.filter_locale=160
    where date(training_end_date) = current_date() limit 20 ;

Les tableaux sont les suivants :

Tableau de traduction	Clé d'objet	Données fournies
DM_LOCALE_CATEGORY_GROUP	COURSECAT_KEY	Contient les noms des catégories de cours
DM_LOCALE_PARENT	PARENT_KEY	Contient les noms des cours parents
DM_LOCALE_LP_GOAL	GOAL_KEY	Détient les noms des plans d'apprentissage
DM_LOCALE_QUALIFICATION	CLÉ DU PLAN DE QUALIFICATION	Détient les noms des plans de qualification

L'ID de la locale (filter_locale) pour les locales d'Alchemy UI sont :

Nom de la localité	ID de la localité
fr_US	1
es_US	160
fr_CA	186
my_MM	343
so_SO	442
fr_GB	116
pa_IN	380
zh_CN	538
vi_VN	522
de_DE	85
es_ES	149
pt_BR	389
es_MX	153
fr_FR	194
es_419	140

DM_ANSWER_DETAILS

Ce tableau contient les détails des réponses d'un élève à un test, une évaluation ou une observation. Certains champs sont remplis ou non en fonction du type d'objet. Cette table sera reliée à la table du rapport en utilisant la clé de session TEST_SESSION_KEY.

Remarque : les "évaluations anonymes" sont anonymes dans l'interface utilisateur mais pas dans les données. Pour préserver l'anonymat, toute utilisation des données doit masquer les détails.

DM_STUDENT_GROUP

Ce tableau comprend tous les groupes associés à un étudiant. Il est destiné à être utilisé uniquement pour le filtrage. Pour ce faire, il suffit d'ajouter une clause WHERE telle que :

    where student_key in (
        select distinct student_key from dm_student_group
        where group_name='A Status Name'
        et group_type='Status'
    )

DM_STUDENT_SECURITY

Ce tableau vous permet d'appliquer la sécurité de type superviseur d'Alchemy Manager. La sécurité du gestionnaire est entièrement basée sur l'accès à un étudiant. Les lignes de cette table doivent être filtrées par la clé ADMIN_STUDENT_KEY et reliées à la table du rapport à l'aide de la clé STUDENT_KEY. Le résultat est d'éliminer les lignes qui ne sont pas accessibles à l'administrateur. Pour obtenir la bonne clé ADMIN_STUDENT_KEY, recherchez la clé STUDENT_KEY de l'administrateur dans la table DM_STUDENT_DETAIL. Voici un exemple pour filtrer les résultats pour l'administrateur avec USER_ID='000001' :

    where student_key in (
        select distinct student_key from dm_student_security
        where admin_student_key=(
            select student_key from dm_student_detail where user_id='000001'
        )
    )

Note : Le tableau peut également être filtré par UNIQUEADMINID qui est composé de l'identifiant de l'étudiant et de votre DB_NAME. Cela ressemble à peu près à ceci :

    where student_key in (
        select distinct student_key from dm_student_security
        where uniqueadminid='12345@alchemy_clientname_live'
    )

Chargement incrémentiel

Si vous reproduisez les données du rapport dans votre propre système, le rechargement régulier des données peut s'avérer trop lent ou trop coûteux. La solution standard à ce problème consiste à ne charger que ce qui a été modifié. C'est ce qu'on appelle une charge incrémentale ou parfois une charge delta. Ce plan présente plusieurs difficultés :

• L'identification des lignes modifiées peut s'avérer difficile
• Les lignes modifiées doivent être fusionnées avec les anciennes données.
• Il n'y a aucun moyen de savoir si des lignes doivent être supprimées.

La façon la plus simple de gérer une charge de données importante est de procéder à des chargements incrémentiels chaque jour, puis de procéder à un rechargement complet une fois par semaine. En d'autres termes, un chargement incrémentiel est le meilleur moyen d'obtenir des données à jour, mais un rechargement complet permet de corriger les éléments qui ont été oubliés ou qui doivent être supprimés.

Nous nous efforçons de faciliter l'identification des lignes modifiées. Actuellement, chaque table dispose d'un champ CHANGE_DATE, mais il se peut que ce champ change trop souvent. Nous ajoutons un champ DM_LAST_MODIFIED pour indiquer uniquement lorsque des changements importants ont eu lieu. Si vous utilisez des jointures, vous devez également tenir compte des modifications apportées à ces tables. Pour être complet, vous devez rechercher toutes les dates supérieures à la date la plus élevée des données chargées précédemment.

Pour illustrer une stratégie visant à conserver une copie locale de DM_TR_REPORT, ce bloc de pseudocode suppose que votre "base de données locale" fonctionne exactement comme un autre compte Snowflake. L'objectif est de minimiser la quantité de données transférées d'Alchemy vers la base de données locale.

    -- Transfert des lignes modifiées d'Alchemy vers la BD locale
       SET last_previous_date = (
         SELECT COALESCE(MAX(DM_LAST_MODIFIED), '1980-01-01')
         FROM localdb.DM_TR_REPORT ) ;
       CREATE OR REPLACE localdb.changes AS
       SELECT vos_colonnes FROM ALCHEMY.DM_TR_REPORT
       WHERE DM_LAST_MODIFIED > $last_previous_date ;
    -- Mettre à jour localement les lignes existantes lorsqu'il y a des correspondances
       UPDATE localdb.DM_TR_REPORT SET your_columns
       FROM localdb.changes
       WHERE localdb.DM_TR_REPORT.transcript_key = localdb.changes.transcript_key ;
    -- Insérer des lignes lorsqu'il n'y a pas de correspondance
       INSERT INTO localdb.DM_TR_REPORT (vos_colonnes)
       SELECT vos_colonnes FROM localdb.changes
       LEFT JOIN localdb.DM_TR_REPORT
         ON localdb.DM_TR_REPORT.transcript_key = localdb.changes.transcript_key
       WHERE localdb.DM_TR_REPORT.transcript_key IS NULL ;

Notez que cela ne permet toujours pas de gérer les lignes supprimées.

Voici une liste des tables DM et de la (ou des) clé(s) à utiliser pour identifier les lignes uniques.

Tableau DM	Identification des clés
DM_TR_REPORT	TRANSCRIPT_KEY
DM_LP_REPORT	CLÉ_D'ABONNEMENT, CLÉ_DE_COURS
DM_STUDENT_DETAIL	CLÉ DE L'ÉTUDIANT
DM_STUDENT_SECURITY	ADMIN_TO_STUDENT_KEY ou ADMIN_STUDENT_KEY,STUDENT_KEY
DM_STUDENT_GROUP	GROUP_TO_STUDENT_KEY ou GROUP_KEY,STUDENT_KEY
DM_ANSWER_DETAILS	TEST_ANSWER_KEY
DM_LOCALE_CATEGORY_GROUP	CLÉ_DE_FILTRE_LOCAL_DE_GROUPE_DE_CATÉGORIE
DM_LOCALE_LP_GOAL	LP_GOAL_LOCALE_FILTER_KEY
DM_LOCALE_PARENT	CLÉ_DU_FILTRE_LOCAL_PARENT
DM_LOCALE_QUALIFICATION	QUALIFICATION_PLAN_LOCALE_FILTER_KEY
DM_OBSERVATION_REPORT	TRANSCRIPT_KEY
DM_QP_STATUS_REPORT	ASSIGNMENT_KEY

A l'heure actuelle, seul DM_TR_REPORT dispose d'un champ DM_LAST_MODIFIED. Les autres tables disposent d'un champ CHANGE_DATE qui peut être utilisé de la même manière, mais il ne sera pas aussi efficace pour réduire le nombre d'enregistrements considérés comme "nouveaux".

Rapports avancés

Certains de nos rapports sont plus complexes que les tableaux habituels. Vous ne pourrez pas recréer les résultats de ces rapports sans reproduire cette complexité supplémentaire.

Par exemple :

• Le rapport sur l'abonnement au plan de formation utilise le regroupement afin de simplifier les résultats lorsque les utilisateurs sont abonnés au même plan plusieurs fois.
• Les rapports "Matrice" utilisent plusieurs lignes et effectuent une opération de "pivot" pour convertir ces lignes supplémentaires en colonnes.
• Les tableaux de bord disponibles dans Manager regroupent les lignes en une ou deux dimensions et fournissent ensuite les données à une bibliothèque de graphiques.