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

Mis à jour

Fonctionnalité bêta. La base de données de reporting est actuellement en bêta et peut encore évoluer. Elle est disponible uniquement sur inscription. Pour rejoindre la bêta ou poser des questions, contactez support@azumuta.com.

Où sont stockées vos données

Toutes les données de votre espace de travail se trouvent dans un seul schéma nommé company_<your-workspace-id>. Chaque table à l'intérieur correspond à un concept que vous connaissez déjà dans 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 au sein d'une version d'instruction.
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 l'historique de leur statut.
issue Tickets d'amélioration continue, avec des comptes 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 articles.
users, user_group, user_group_member Personnes et groupes de votre espace de travail.

Conventions utilisées

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.
  • Suppressions logiques. Les lignes ne sont jamais supprimées silencieusement. Lorsqu'un élément est supprimé dans Azumuta, sa ligne reçoit un horodatage deleted_at. Pour ne travailler qu'avec les données actuelles, ajoutez where deleted_at is null à vos requêtes.
  • Horodatages. Chaque table comporte 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.
  • Champs flexibles en JSON. Les données de forme variable (comme 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 totaux 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 possède une description lisible par l'humain qui lui est attachée. La plupart des clients SQL et outils BI l'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 n'aurez que rarement à deviner la signification d'une colonne — le schéma se documente lui-même.

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

Sur cette page
© Azumuta 2026