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

Fonctionnalité Bêta. La base de données de rapport est actuellement en bêta et peut encore évoluer. Cette fonctionnalité n'est actuellement disponible que sur opt-in. Contactez votre contact Azumuta pour rejoindre la bêta et l'essayer.

Où vivent vos données

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

Les tableaux principaux

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

Tableau	Ce qu'il 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 travaille à travers une étape, plus les totaux par étape.
`recording`, `recording_status`	Les sessions d'exécution (un opérateur exécutant une instruction) et leur historique de statut.
`issue`	Les problèmes / 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 problème.
`issue_transition`	L'historique d'un problème se déplaçant entre les colonnes du tableau.
`product_order`, `product_order_item`, `product_order_item_spot`	Les commandes de production et leurs éléments.
`users`, `user_group`, `user_group_member`	Les personnes et les groupes dans votre espace de travail.

Conventions utilisées partout

Une fois que vous connaissez ces quelques règles, l'ensemble du schéma devient prévisible :

Clés principales. Chaque tableau a une clé principale de texte (par exemple recording_id, issue_id) qui correspond à l'id de l'enregistrement dans Azumuta. Vous pouvez l'utiliser pour joindre les tableaux connexes ensemble.
Suppressions logicielles. Les lignes ne sont jamais supprimées silencieusement. Quand quelque chose est supprimé dans Azumuta, sa ligne reçoit un horodatage deleted_at à la place. Pour travailler avec seulement les données actuelles, ajoutez where deleted_at is null à vos requêtes.
Horodatages. Chaque tableau porte created_at et modified_at (et deleted_at). Tous les horodatages sont stockés en UTC.
Les durées sont en millisecondes. Les champs tels que actual_duration ou rework_time sont stockés en millisecondes entières. Divisez par 1000 pour les secondes.
Les champs flexibles utilisent JSON. Les données qui varient en forme (telles que parameters ou une answer d'instruction) sont stockées en tant que jsonb, que vous pouvez interroger avec les opérateurs JSON de PostgreSQL.
Valeurs pré-calculées. Pour vous éviter des jointures supplémentaires, certains tableaux incluent des comptes 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 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;

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

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