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

Mis à jour

Fonctionnalité en 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ù se trouvent 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.

Principales tables

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 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 l'historique de leurs statuts.
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 ces quelques règles connues, l'ensemble du 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 travailler uniquement 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.
  • Les champs flexibles utilisent JSON. Les données dont la structure varie (par exemple 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 comptes 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. 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 via 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;

Ainsi, vous n'avez 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