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

Mis à jour

Bêta. La base de données de reporting est actuellement en bêta ; le schéma et les conventions décrits ici peuvent encore changer.

Où résident vos données

Toutes les données de votre espace de travail résident dans un seul schéma nommé company_<your-workspace-id>. Chaque table à l'intérieur correspond à un concept que vous connaissez déjà d'Azumuta.

Les tables principales

L'ensemble exact des tables dépend de ce que vous avez activé. Les plus courantes sont :

Table Ce qu'elle contient
workinstruction, workinstruction_version Vos instructions de travail et leurs versions publiées.
instruction_step Les étapes individuelles d'une version d'instruction de travail.
instruction_visit, instruction_total_visit Chaque fois qu'un opérateur parcourt une étape, plus les totaux par étape.
recording, recording_status Sessions d'exécution (un opérateur exécutant une instruction) et leur historique des statuts.
issue Problèmes / tickets d'amélioration continue, avec des totaux pré-calculés pratiques.
issue_task, issue_comment, issue_attachment, issue_signature, issue_checklist Les éléments attachés à un ticket.
issue_transition L'historique des déplacements d'un ticket entre les colonnes du tableau.
product_order, product_order_item, product_order_item_spot Ordres de production et leurs éléments.
users, user_group, user_group_member Les personnes et groupes de votre espace de travail.

Conventions utilisées dans tout le schéma

Une fois que vous connaissez ces quelques règles, tout le schéma devient prévisible :

  • Clés primaires. Chaque table possède une clé primaire de type texte (par exemple recording_id, issue_id) qui correspond à l'id de l'enregistrement dans Azumuta. Vous pouvez l'utiliser pour joindre les tables entre elles.
  • Suppression logique. Les lignes ne sont jamais supprimées silencieusement. Lorsqu'un élément est supprimé dans Azumuta, sa ligne reçoit un timestamp deleted_at. Pour ne travailler qu'avec les données actuelles, ajoutez where deleted_at is null à vos requêtes.
  • Horodatages. Chaque table contient created_at et modified_at (et deleted_at). Tous les horodatages sont stockés en UTC.
  • Les durées sont en millisecondes. Des champs tels que actual_duration ou rework_time sont stockés en millisecondes entières. Divisez par 1000 pour obtenir des secondes.
  • Les champs flexibles utilisent JSON. Les données dont la structure varie (telles que parameters ou une answer d'instruction) sont stockées en jsonb, que vous pouvez interroger avec les opérateurs JSON de PostgreSQL.
  • Valeurs pré-calculées. Pour vous éviter des jointures supplémentaires, certaines tables incluent des comptages et 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 table et chaque colonne dispose d'une description lisible par l'humain. La plupart des clients SQL et des outils BI les affichent automatiquement. Par exemple, dans psql :

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

Vous pouvez aussi 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;

Cela signifie que vous avez rarement à deviner ce qu'une colonne signifie — le schéma se documente lui-même.

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

Sur cette page
© Azumuta 2026