Comprendre le schéma de la base de données de rapport

BETA : La base de données de rapport est actuellement en version bêta et peut encore évoluer. Elle est disponible sur opt-in uniquement. Pour rejoindre la bêta ou poser des questions, contactez support@azumuta.com.

Où vivent vos données

La base de données de rapport gérée stocke les données rapportables de votre espace de travail dans un schéma nommé company_<normalized-workspace-id>. Le nom utilise des lettres minuscules et remplace les autres caractères, à l'exception des chiffres, par des traits de soulignement. Une base de données personnalisée peut utiliser un nom de schéma différent. Utilisez le nom de schéma configuré dans les exemples ci-dessous.

Les tableaux principaux

L'activation de la base de données de rapport synchronise tous les tableaux ci-dessous. Vous ne pouvez pas sélectionner des tableaux individuels.

Enregistrements d'audit dans la base de données de rapport

Le tableau recording inclut uniquement les enregistrements avec une version d'instruction numérique. Un enregistrement sans version est exclu, même lorsque son statut est Terminé (FINISHED).

L'enregistrement n'a pas besoin d'être En cours (IN_PROGRESS) ou Terminé pour être inclus. Un téléchargement hors ligne peut lier une version d'instruction de travail tandis que le statut reste Planifié (IN_QUEUE). Après une synchronisation réussie de la base de données de rapport, cet enregistrement peut apparaître avec le statut IN_QUEUE.

Les téléchargements automatiques dépendent du contenu sélectionné et de la plage de dates de l'appareil. Ils peuvent se produire avant qu'un opérateur n'ouvre un audit. Voir Paramètres de l'appareil : Hors ligne.

Fermer un audit non commencé comme N/A (NOT_APPLICABLE) ne lie pas en soi une version d'instruction de travail. Si l'enregistrement n'a pas de version, la base de données de rapport continue à l'exclure. Le statut seul n'explique pas si un audit apparaît dans la base de données.

Le statut et le résultat sont différents

La colonne status contient la valeur stockée, telle que IN_QUEUE, et non l'étiquette d'affichage Planifié. Voir Statut, résultat et notes pour tous les étiquettes anglaises et les valeurs stockées.

Le tableau recording_status contient les changements de statut. Il ne contient pas les changements de résultat.

La colonne recording.result stocke le résultat sélectionné, tel que Succès (SUCCESS), Échoué (FAILED), N/A (NOT_APPLICABLE) ou Annulé (CANCELLED). Les nouveaux enregistrements commencent avec PLANNED. Cette valeur peut rester si aucun résultat n'est sélectionné. Si l'enregistrement source n'a pas de valeur de résultat, la colonne est NULL. Utilisez status, pas result, pour identifier l'état d'exécution.

La colonne is_failure est calculée à partir des vérifications, des événements et de la retouche. Elle peut être true en raison de :

• Une vérification échouée ou une double vérification échouée.
• Un résultat de couple de NOK.
• Un nombre en dehors des limites autorisées.
• Un événement Andon, qui signale un problème lors de l'exécution.
• Un statut Retouche (REWORK) actuel ou précédent.

La colonne is_defect utilise les mêmes vérifications mais exclut la retouche seule. Par exemple, une retouche sans vérification échouée ou événement Andon donne is_failure = true et is_defect = false. La retouche précédente peut maintenir is_failure = true après la fin de l'enregistrement. Voir Retouche pour le flux de travail.

Aucun calcul n'utilise le résultat sélectionné. Pour identifier N/A ou Succès, utilisez result, pas is_failure = false. Un enregistrement peut avoir is_failure = false sans résultat sélectionné.

Notes d'enregistrement

La colonne recording.notes contient les notes d'enregistrement, y compris les notes saisies avec un résultat. Vous pouvez filtrer sur notes = 'auto cleanup' pour identifier les enregistrements avec cette note exacte. Les notes manquantes ou vides apparaissent comme NULL.

Les lignes synchronisées avant l'ajout de result et notes peuvent toujours avoir NULL dans ces colonnes. Une synchronisation normale met à jour uniquement les enregistrements modifiés. Une resynchronisation complète est nécessaire pour remplir ces colonnes pour les enregistrements historiques inchangés.

Travail terminé et commandes fermées

Le statut d'enregistrement et le statut de commande de production décrivent différents niveaux de travail :

Une commande peut rester En cours lorsque ses enregistrements sont terminés mais que sa quantité complétée ne correspond pas à sa quantité requise. Une commande active sans instructions de travail ou commandes enfants est Tout est complet. Voir Statut de la commande de production.

Forcer la fermeture d'une commande annule ses enregistrements inachevés. Ces enregistrements reçoivent le statut FINISHED et le résultat CANCELLED. Ainsi, la fermeture n'est pas la preuve d'une exécution réussie. product_order.finished_at enregistre la fermeture de la commande, pas nécessairement le moment où tout le travail a été complété.

Associations de zones et assignation

product_order_workinstruction_spot relie chaque élément de commande à ses zones. Le zone_type identifie la source :

• assigned : une zone assignée à l'élément de commande.
• accessed : une zone enregistrée lors de l'activité de l'opérateur, sauf si la même zone est déjà assigned.
• associated : une zone du placement de l'instruction de travail, utilisée uniquement lorsque l'élément n'a pas de zones assignées ou accédées.

Le tableau combine les zones assignées et accédées. Il conserve une ligne par élément et zone, avec assigned ayant la priorité. Une assignation verrouillée n'est pas un type de zone SQL séparé.

Par exemple, un élément est assigné à A, accédé à A et B, et a le placement par défaut C. Les lignes sont assigné A et accédé B, sans C. Un filtre sur zone_type = 'accessed' manque donc l'accès à A.

Le placement de secours utilise le nœud d'arbre parent direct de l'instruction de travail lorsque ce nœud est une zone. Il ne recherche pas les ancêtres arbitraires.

Les assignations peuvent changer. Les champs assigned_spot_id décrivent l'assignation, pas un emplacement d'exécution immuable. Le tableau d'association n'est pas un historique d'assignation. Ses règles ne correspondent pas non plus à tous les widgets intégrés. Voir Filtrage de zone pour les widgets de commande de production pour la configuration des widgets.

Joindre au niveau de l'élément de commande

Pour compter le travail planifié, commencez par product_order_workinstruction. Si vous avez besoin de détails d'enregistrement, utilisez une jointure gauche de son recording_id à recording.id. Cela conserve les éléments sans ligne de rapport pour un enregistrement.

Joignez les zones via product_order_workinstruction_spot.product_order_workinstruction_id = product_order_workinstruction.id. Ne joignez pas par workinstruction_id seul : plusieurs éléments de commande peuvent utiliser la même instruction de travail.

Plusieurs zones ou visites peuvent répéter la quantité d'un élément ou la durée d'un enregistrement dans un résultat joint. Utilisez EXISTS pour un filtre d'association, ou agrégez chaque source avant de joindre. Voir Compter les éléments de commande associés à une zone.

Utilisateurs planifiés et opérateurs réels

recording.planned_user_id et planned_group_id décrivent l'assignation. Ils n'identifient pas tous ceux qui ont effectué le travail. instruction_visit.user_id identifie l'opérateur pour cette visite.

Plusieurs opérateurs peuvent contribuer à un enregistrement. Comptez les ID d'enregistrement distincts pour chaque opérateur, pas les lignes de visite. Un enregistrement partagé compte alors pour chaque opérateur contributeur. Voir Enregistrements pour le flux de travail du rapport et la requête d'opérateur pour ce calcul.

Visites, tentatives et étapes applicables

• instruction_visit a une ligne lorsqu'un opérateur quitte une étape. Une visite qui est encore ouverte peut ne pas avoir de ligne pour le moment.
• type = 'normal' et type = 'double-check' sont des groupes de visite séparés. is_last_visit marque la dernière visite au sein de son groupe, pas nécessairement la dernière visite avec une réponse. Voir Double vérifications.
• Une vérification bloquée ou invalide compte comme une tentative mais ne fournit pas de réponse acceptée. instruction_total_visit.answer_attempts compte les visites avec une tentative après que l'opérateur quitte, pas les appuis sur bouton individuels.
• instruction_total_visit contient les totaux et la réponse enregistrée finale pour chaque enregistrement, étape et type de visite. Une réponse enregistrée n'est pas nécessairement une réponse réussie.
• recording_step.active = false signifie que les variantes excluent l'étape. Aucune visite n'est attendue. Les enregistrements plus anciens sans sélection de variante stockée traitent toutes les étapes comme actives. Voir Variantes et configuration de variante.

Les données manquantes seules ne prouvent pas l'échec. Vérifiez l'applicabilité, le statut d'enregistrement et si l'étape nécessite une réponse. Voir Comparer les étapes applicables avec les réponses enregistrées.

Contexte de version et de paramètre

Joignez recording.workinstruction_version_id à workinstruction_version.id pour lire la version liée à l'enregistrement. N'utilisez pas la version actuelle de l'instruction de travail pour interpréter les étapes historiques. L'approbation est une propriété séparée ; voir Historique de révision.

Pour les enregistrements de commande de production, lisez les paramètres de product_order.parameters via recording.product_order_id. Les autres paramètres d'enregistrement peuvent être dans recording.parameters. Voir Paramètres de commande de production et Introduction aux paramètres pour savoir ce qu'est un paramètre.

Les champs JSON peuvent contenir des listes ou des objets imbriqués, pas seulement des nombres ou du texte. Vérifiez le type de chaque valeur avant de la convertir. Un NULL SQL indique des données manquantes, pas zéro ou une réponse échouée.

Conventions utilisées partout

• Clés primaires. Chaque tableau a une clé primaire textuelle nommée id. Cela identifie un enregistrement source ou une ligne générée. Les colonnes associées utilisent des noms tels que recording_id et workinstruction_id. Par exemple, joignez recording.workinstruction_id à workinstruction.id.
• Suppressions. Lorsqu'une synchronisation détecte un enregistrement source supprimé, elle supprime les lignes de rapport correspondantes. Les définitions de tableau actuelles n'incluent pas deleted_at. Les bases de données plus anciennes peuvent conserver cette colonne car les mises à jour de schéma ne suppriment pas les anciennes colonnes. La synchronisation actuelle ne la maintient pas ; ne l'utilisez pas comme indicateur de suppression actuel. Les enregistrements archivés sont différents des enregistrements supprimés. Par exemple, issue.archived_at identifie les problèmes archivés.
• Horodatages de synchronisation. Chaque tableau a first_synced_at et last_synced_at. Ceux-ci enregistrent la première et la synchronisation la plus récente qui a écrit la ligne, pas l'heure de création ou de modification de l'enregistrement source.
• Horodatages source. Les colonnes telles que created_at, updated_at et started_at dépendent du tableau. PostgreSQL stocke ces horodatages comme des instants en UTC et les affiche dans le fuseau horaire de la session.
• Durées d'enregistrement. recording.actual_duration et recording.rework_time sont en secondes et peuvent contenir des fractions. Ne les divisez pas par 1000. Vérifiez la description de la colonne pour l'unité d'autres champs.
• Les champs flexibles utilisent JSON. Les données qui varient en forme (telles que parameters ou une answer d'instruction) sont stockées sous forme de jsonb, que vous pouvez interroger avec les opérateurs JSON de PostgreSQL.
• Valeurs pré-calculées. Pour vous épargner des jointures supplémentaires, certains tableaux incluent des comptages et des métriques prêts à l'emploi, par exemple issue.comment_count, issue.open_task_count ou recording.rework_time.

Le dictionnaire de données intégré

Chaque tableau et chaque colonne a une description lisible par l'homme qui y est attachée. La plupart des clients SQL et des outils BI les affichent automatiquement. Par exemple, dans psql :

\d+ "company_<your-workspace-id>".issue

Vous pouvez également les lire avec une requête :

select column_name, col_description(
    ('company_<your-workspace-id>.issue')::regclass,
    ordinal_position
) as description
from information_schema.columns
where table_schema = 'company_<your-workspace-id>'
  and table_name = 'issue'
order by ordinal_position;

Prêt à interroger ? Voir Exemples de requêtes analytiques.